服務器虛擬化項目實戰六步曲
發布時間：2010-12-22 18:43:53
摘 要：毫無疑問，服務器虛擬化已經在IT行業刮起了一場風暴。這項技術為顯著減少停機時間、增強靈活性、大幅提高硬件利用效率提供了一種經濟高效的方式。不過，中小型企業常常發現很難評...
第三個階段：規劃容量。
在第三個階段，IT團隊發現，服務器虛擬化規劃并非易事。
測試了服務器虛擬化軟件、了解是否滿足性能要求后，Fergenschmeir的幾位IT主管隨后要進行詳細的部署規劃。基礎架構經理Eric Brown和CTO Brad Richter需要解決規劃階段的兩個基本問題：首先，他們希望服務器扮演哪些角色？其次，可以對哪些服務器進行虛擬化處理？
Brad先讓他的團隊給出一份清單，列出每個基于服務器的應用軟件以及安裝了應用軟件的每臺服務器。Eric由此畫出了一份依賴關系樹（dependency tree），表明哪些服務器和應用系統依賴對方。
·評估服務器角色
Eric在畫依賴關系樹時清楚地發現，他們可不想為服務器分配與原來同樣的應用軟件。在數據中心的約60臺服務器當中，只有4臺直接負責約20個應用軟件的連續運行。這主要是由于幾臺SQL數據庫服務器被當作了"垃圾傾倒地"，許多不同應用軟件的數據庫都在上面，有時迫使某應用軟件使用比它支持的更新或更舊的SQL版本。
此外還存在有風險的依賴關系。比方說，五個重要的應用軟件都安裝在一臺服務器上。反過來，Eric和Brad也發現存在效率很低的現象，比如五臺服務器都用于部門級文件共享，純屬多余。
Eric認為部署的虛擬化系統要避免這些缺陷，于是新架構必須消除不必要的冗余，同時把任務關鍵型應用軟件分配到多臺物理服務器上，盡量降低任何一臺服務器出現故障的風險。這就意味著服務器數量從60臺增至72臺，服務器許可證的數量也相應增加。
·確定適合使用虛擬化的對象
由于現已確定了架構，Eric要弄清楚哪些服務器可以使用虛擬化、哪些保持原狀。弄清楚這個問題比他起先預料的來得困難。
一個關鍵問題就是每臺服務器的負荷，這個關鍵因素決定了需要多少個物理虛擬化主機。很明顯，沒有必要對正在充分利用硬件平臺的應用負荷采用虛擬化。最初的測試表明，VMware虛擬機管理程序占用主機服務器約10%的原始性能，所以任何虛擬化主機的實際功能只有專用、非虛擬化物理主機的90%。利用率超過90%的任何應用軟件都可能出現性能下降，也不適合服務器整合。
但是獲得利用率方面的這些數字并非易事。雖然在Windows系統上使用Perfmon系統監視器，或者在Linux系統上使用SAR等工具，很容易顯示某服務器在自己的小環境中有多繁忙，但要表明這個小環境與另一個小環境有怎樣的關系就不那么容易了。
比方說，Thanatos（運行該公司醫療賠償和福利管理軟件的服務器）是時鐘頻率為2.8GHz的雙插座、單核英特爾奔騰4系統，負荷平均只有4%。同時，Hermes（語音郵件系統）運行在時鐘頻率為2.2GHz的雙插座、雙核AMD皓龍275系統上，負荷平均為12%。這不但是兩種完全不同的處理器架構，Hermes的處理器核心數量還是Thanatos的兩倍。讓問題更復雜的是，處理器的利用率不是惟一需要考慮的基本資源；在規劃虛擬化基礎架構時，內存、磁盤和網絡的利用率顯然同樣重要。
Eric很快明白，這就是為什么市面上有那么多的軟件用于進行容量評估。如果他只有一二十臺服務器要考慮，可能比較簡單，他只要打開Excel、自己分析即可。那樣他可以逐步對負荷進行虛擬化處理，看看實際利用率如何。但他知道，如果拿不出確切的預算方案，CEO Bob Tersitan和CFO Craig Windham不會有興趣。
于是經過一番研究后，Eric向Brad建議從外面請一家咨詢公司來進行容量規劃。Eric請當地的一個VMware合作伙伴進行評估，結果得知需要一兩個月才能完成評估。咨詢顧問表示，如果對服務器不進行至少一個月的監測，不可能得出服務器利用率方面完整而準確的分析結果。不然，分析結果將無法體現并非總是活動的流程（比如周末和月末的報告分析）的負荷。
這樣的延遲完全有必要，但這確實意味著Eric和Brad無法趕在Bob給實施方案所定的最后期限之前。幸好，Craig覺得有必要讓方案盡可能準確，于是他的支持最終讓Bob對延遲表示了理解。
結果證明，這次延遲對Eric和 Bob有利無弊，因為還有其他許多規劃任務根本沒有完成，比如選擇系統運行所需的軟硬件。這段分析時期讓他們有了喘息之機，可設法弄清楚自己不知道的方面。
一段時間后最初的容量規劃分析終于完成后，結果表明Fergenschmeir的應用服務器利用率大多數在10%或以下，這樣可以對預計部署的72臺服務器進行大規模整合。合理的配置需要八九個雙插座、四核ESX主機，以便從容運行現有的應用軟件，留出一定的增長空間，并且控制某個主機出現故障時的停機時間。
（責任編輯：ZaneXu 來源：IT168 ）
