對于企業的IT部門來說，虛擬化技術是一種很有效的工具，可以大大提高基礎架構的效率。但要是沒有經過合理規劃，你很容易因無法合理地擴展系統而受挫。

那么，該如何規劃虛擬化系統所需的容量，以便最后不會出現開支過度或資源不足的情況呢?下面是需要考慮的一些關鍵方面。

采用單一架構

許多公司會犯的其中一個最嚴重的錯誤就是，試圖在沒有合并的網絡上運行合并后的系統。針對諸如存儲設備和服務器之類的特定部件分開建立數據中心網絡再也不合適了。

隨著許多公司遷移到私有云計算——在這種環境下，系統合并到了數量較少的設備上，網絡管理起來必須更加簡單，還要支持龐大的流量。

融合網絡構成了下一代數據中心的基礎;而融合網絡的特點是，存儲設備流量和服務器流量在統一架構上傳送。

融合網絡協議大戰基本上塵埃落定;現在可以買到與廠商無關的萬兆連接設備，這種設備對服務器和存儲設備的支持足夠好，可以幫助你避免啟動風暴(bootstorm)之類的問題。

在單一網絡架構上管理虛擬化系統可以大大簡化管理員們的工作，在確保系統正常運行時間的同時，降低管理成本。

全面摸底

在你擴大試點項目的規模之前，有必要了解一下目前的系統在處理什么負載。使用管理工具了解系統活動的基本情況是關鍵的一步，但是從中了解的情況不一樣。

Glasshouse Technologies公司的虛擬化服務主管Erwin Vollering提醒：“十有八九，你的客戶以為自己摸清楚了情況，但是他們了解的只是安裝在工作站上的應用程序而已，對于那些應用程序的具體使用情況所知不多。”

使用網絡探測器或客戶端代理來估量這方面的情況后，就可以了解你的桌面虛擬化系統從15個機器擴大到1500個機器后，預計會出現什么樣的局面。

別忘了對你的系統進行抽樣測試，了解你的計算需求會出現劇烈的變化。然后，你就可以計劃模擬峰值負載。

與廠商交流

規劃擴展系統時，有必要全面了解所用硬件的功能。向存儲廠商盡量多打探一些信息，了解他們的系統在某些負載下運行情況如何。

在以應用為中心的環境下，你必須確保軟件也考慮在內。面對龐大的工作負載，軟件運行起來如何?你的關系數據庫行不行?還是說需要遷移到大型的多節點數據庫?

在大數據當道的時代，這成了一個關鍵的決策。你可能需要完全重新考慮交付應用程序的方式，如果這是一種為不同的基礎架構設計的遺留應用程序，更是如此。

加強集成

你的所有硬件都有效地集成起來后，合并后的虛擬化系統工作起來要高效得多。

下一代數據中心的特點之一就是支持集成環境的統一網絡架構;在這種環境中，存儲設備、服務器和網絡設備都經過了優化，以便協同運行。

這提供了更好的性能，還讓系統管理工具更容易全面了解硬件基礎架構的情況，因而更容易全面了解在基礎架構上運行的軟件。應考慮構建讓合并后的系統更順暢運行的下一代數據中心架構。

注意故障點

設計的系統可能是為了滿足在特定的時間段處理特定數量的交易這一要求。

系統面臨的交易量增加后，單一故障點就成了一個切實存在的問題。如果你試點系統中的交換機出現故障，起到故障切換作用的交換機也許能夠接過重任。但是如果交易量增加一個數量級后，還會是這種情況嗎?

設計多個故障區是個好主意——故障區在系統的不同部分隔離開來，那樣基礎架構的任何部分都不會在任何一個時間點受到危及。

理想情況下，你還需要設計應對系統全部峰值負載的那些系統，以便萬一出現故障，它們就能夠接過重任。

系統規模擴大后，這一步很難做到。亞馬遜建在都柏林的彈性塊存儲(Elastic Block Store)系統最近之所以過了那么久之后才恢復如初，一個原因是由于變壓器出現了故障，結果數量眾多的服務器同時出現了停運。

其余還在運行的服務器不斷試圖復制所發現的一切數據，這導致了客戶的交易“陷入停滯”。亞馬遜只好用卡車運來更多的設備，以增加容量。

亞馬遜稱：“之所以出現了延誤，是因為故障發生在都柏林的晚間;用卡車運送設備需要從離數據中心有一段距離的地方運過來。”

IT管理服務公司Adapt的架構主管John Soanes說：“要規劃和測試重新啟動。”

“由于你面臨爭奪資源的情況，因而接連出現故障。所以，有節制地努力打造一個龐大系統確實很重要。”

結論

“如果進去的是垃圾，那么出來的也是垃圾”這句格言滲透到了從代碼編寫到系統設計的IT的方方面面，它同樣適用于虛擬化。

一開始獲得高質量的信息，就能避免以后出現問題。還要考慮自下而上地設計各個方面，以便融合架構可以提升性能、簡化管理。

譯文來源： http://www.theregister.co.uk/2011/09/26/network_virtualisation_plan_for_growth/

原文鏈接：http://virtual.51cto.com/art/201109/294831.htm