虛擬化基礎設施運維雜談

現如今，以虛擬化技術來架構企事業(yè)單位的核心IT系統(tǒng)已經越來越普遍，對虛擬化技術的運用也從懷疑走向信任，從陌生走向熟悉。伴隨著虛擬化技術的不斷演進，虛擬化技術本身已經不再是用戶擔心的首要問題，取而代之的是如何更好地規(guī)劃虛擬化架構，如何讓虛擬化技術更好地服務IT服務，以及與運維場景相關聯的個性化技術細節(jié)。

本文以vSphere為例，從虛擬化基礎設施運維所涉及的各個方面出發(fā)，探討運維的問題及合理性。

從服務器說起

無論虛擬化如何水平或垂直構建資源池，物理服務器始終是所有計算資源的承載單元，其整個x86架構的制造工藝和設計水平都真真切切影響著整個虛擬化架構的穩(wěn)定和高效。以一個常見的比喻來說，物理服務器就是裝雞蛋的籃子，雖然是個“籃子”都可以拿來放雞蛋，但“籃子”是否結實耐用、孔洞大小是否便于排列雞蛋等細節(jié)，則決定了雞蛋的命運。因此，一個多路處理器、大內存的服務器，并不能簡單地像DIY一樣拼裝高配的零件就可以成為好的“籃子”，還需要兼顧虛擬化可以發(fā)揮優(yōu)勢的一些特征，比如機箱的物理散熱和雙電源，支持SD卡來安裝Hypervisor，磁盤的數量和型號滿足vSAN的部署條件，是選用光口還是電口的網卡、網卡的數量、網卡是否支持FCoE、交換機上千兆和萬兆接口剩余的數量，選擇FCSAN的存儲以及IPSAN如何接入等，缺少這些考量的服務器，則難免在未來部署或使用中面臨各種擴展性或性能的問題。

在CPU和內存的容量配比上值得注意的是，物理內存若配置得較大，比如128GB，甚至256GB，則CPU也應考慮選擇同檔次里較高的一款，因為消耗CPU的虛機和大量不消耗CPU卻占用內存的虛機都需要物理的CPU去調度和處理，我們既不希望看見CPU負載75%，內存負載85%的場景，也不希望CPU負載僅10%，內存負載就90%的不均衡。針對這個矛盾，可以考慮初期配置較高的CPU和適量的內存，后期根據運行情況對內存進行擴容，因為內存的擴充較為便宜和方便。

ESXi是安裝在物理服務器上的底層操作系統(tǒng)，該系統(tǒng)可以說也是“籃子”的一部分，從操作系統(tǒng)的角度來說，ESXi已經是較為極致的，可以安裝在機架服務器1G的SD卡存儲器，也可以通過USB來引導運行，還可以通過網絡自動部署服務加載到內存，只要裝好了ESXi，后期的運維幾乎都不用再進機房面對服務器裸機（有遠程管理或KVM例外）。對于具備HBA卡虛擬化特性的服務器，則建議以boot from san的方式安裝ESXi，因為當單個計算節(jié)點故障時，可以直接關聯虛擬HBA卡及其相關硬件信息到備用的計算節(jié)點，實現快速而完整的故障恢復，即縮短RTO，也便于技術人員維修或更換。此外，還有HP、Cisco、Fujitsu、Hitachi等幾個廠商的服務器，ESXi都封裝了OEM定制版，定制版無疑在驅動的支持上要優(yōu)于通用版介質，使用這些廠商設備時也應盡可能使用OEM版介質。

對舊服務器，只要支持VT-x或AMD-v，內存大于等于4GB，也是可以考慮部署為ESXi底層的，因為它即使只能裝一個虛機，也可以讓這個虛機具備可遷移的能力，當故障來臨或業(yè)務重要性提升時，可以從容地遷移到其他服務器。

配置虛擬機

承接前文的比喻，虛擬機就是裝在“籃子”中的一只只“雞蛋”，雞蛋的數量在更多的場景中取決于內存的大小，強烈建議在重要生產環(huán)境中，同一物理機分配給虛機內存總和不宜超過物理內存大小，雖然虛擬化環(huán)境具備內存精簡算法，能夠對相同的操作系統(tǒng)共同的內存部分采用共享的方式來節(jié)約內存使用，但既然是算法，就會消耗CPU調度，就會帶來一定的延遲，這些損耗在稍舊的服務器上表現更為明顯。反之，對于計算資源拮據的環(huán)境，或對運行效率沒有較高要求的環(huán)境，還是可以利用此技術優(yōu)勢來節(jié)約經費投入的。

在虛機的vCPU方面，應盡量采用單插槽多內核的方式，因為設定多個插槽的vCPU在運行中，會跨物理CPU插槽運行，這將增加CPU調度的損耗，而單個虛擬插槽的vCPU配置，則會在同一顆物理CPU內來虛擬，使得虛機在使用CPU資源時調度效率更高，這一細節(jié)對運算量較大的虛機還是較為重要的。

虛機的磁盤主要是vmdk文件，該文件是虛機的本源，假設虛機其他文件都遭到破壞或丟失，但只要vmdk完好，就能夠恢復虛機運行。眾所周知，vmdk采用厚置備可以獲得更好的磁盤效率，采用精簡置備方式可以在劃分時超出物理LUN的大小上限，但在重要的生產環(huán)境中，本文則建議按需分配，首先對于虛機磁盤的使用比率，可以在周期性巡檢維護中獲知，利用操作系統(tǒng)的擴盤特性，如Windows的跨區(qū)卷、Linux的lvm等，待空間不足時新增vmdk來擴充是較為合理的。其次，對于vmdk容量總和超出物理LUN大小，一旦某個虛機因未知的事件快速填充過多預留的vmdk空間，容易使整個物理LUN在管理員無防備的情況下被寫滿，此時，該物理LUN上的所有虛機都會因物理LUN的磁盤滿而停機，后果是可想而知的。vmdk經過配置，也可以作為虛擬的共享磁盤為兩個或多個虛機所共用，利用這一特性也可以搭建出Oracle rac之類的集群環(huán)境，并且效率并不差，所需注意的是共享的vmdk不要進行存儲位置的遷移，否則會在遷移中被當作每個虛機私有的磁盤復制為多個，進而破壞了共享的集群配置。

與vmdk相關聯的一個實用功能是快照，它可以保持vmdk在某一個時間點的狀態(tài)，后繼運行對磁盤產生的變化則用差分的vmdk去記錄，對存在風險的虛機調試特別方便，但也常常被錯誤地當作備份工具去使用。首先快照產生的差異vmdk存在于生產的LUN，過多的創(chuàng)建快照浪費昂貴的LUN空間。其次，快照數量過多潛在影響虛機運行效率，因為很可能存在連續(xù)讀取的I/O分布在多個快照vmdk中，而查詢多個vmdk文件內在關聯性是需要消耗資源的；再次，較多的快照文件在vmdk遷移時，更容易出現失敗。

有不少管理員認為，既然是虛擬的，每個虛機分配的計算資源可以多一些，反正用不到的部分是可以被其他虛機使用的。誠然，單臺物理服務器的CPU資源是按照已開機虛機分配的vCPU數量去平均的，但還有內存和磁盤I/O的優(yōu)先級呢？本文依然建議，每個虛機盡可能按需分配，這個需應是平峰負載所需的計算資源。若將分配虛擬硬件的資源當作預留計算資源，則是對虛擬化管理的誤區(qū)。

比如某個虛機偶爾占滿資源，但因為程序不好而不釋放資源，比如新建虛機數量較多，則整個硬件資源池，可能是CPU也可能是內存也會較快達到飽和，此時再從已分配的虛機里去擠資源就較難了，即使新采購硬件也可能時間周期長或經費不足。我們可以按照不同應用劃分資源池，由資源池預留這些應用在負載高峰期所需的計算能力，包括CPU資源、物理內存占用的優(yōu)先級、vmdk對I/O的優(yōu)先級，從而使資源池的虛擬硬件分配和占用更趨合理。

虛機模版是許多管理員喜愛的工具，最顯著的優(yōu)勢就是快速批量部署虛機，但使用此功能一定不能偷懶，尤其對于Windows模版要配置好封裝工具，以使SID在每次快速部署中得到更換，否則很容易埋下SID相同帶來的隱患問題。

如果說vmdk是虛機存活在vmfs中的唯一形式，那么ovf則是虛機跨越文件系統(tǒng)和虛機格式的一個開放形態(tài)，將虛機導出為ovf/ova格式，ovf文件完整的封裝當前虛機的所有文件和虛擬硬件配置，使虛機以文件的形式保存在常見的文件系統(tǒng)中，進而可以再導入其他虛擬化平臺，實現更靈活的可遷移能力。與ovf靜態(tài)轉換相對應的是Converter工具，它能夠將在線狀態(tài)的物理機轉換為虛機，將較早前版本的虛機轉換為新的虛機版本，將不同vCenter中虛機進行復制傳送，并在轉換過程中實現磁盤格式在精簡與厚置備之間的轉換，利用此靈活性，有文件反復寫入的虛機也可以在轉換中將vmdk文件按順序重新生成，換言之相當于對vmdk做了磁盤碎片整理，從而提高vmdk的讀寫效率。

圍繞vCenter去架構

虛擬化基礎設施的中央控制單元vCenter是運維必不可少的利器，它自身由單點登錄組件、數據庫、清單組件以及vCenter服務等多個部分構成，許多部署環(huán)境也將這些組件分別安裝在多個虛機里，以支撐較大規(guī)模的部署。但現實中，什么樣的規(guī)?？梢苑Q之為大呢？以清單組件安裝時提供的選項可以作為一個參考，即100主機、1000虛機以內，都可以作為小規(guī)模，以此為標準，我們身邊大部分的虛擬化環(huán)境都是小規(guī)模。

界定這一標準，我們大可不必逐項給每個組件新建Windows虛機，取而代之的是用 vCenter的 Appliance，該Appliance以SUSE12為基礎，整合了 vCenter Server、SSO、Inventory Service、Database、Web Client、Log Browser、ESXi Dump Collector、Syslog Collector、Auto Deploy等幾乎全套的組件，較高的整合度帶來了完整的功能。此外，相對于多個Windows來搭建，僅一個Linux系統(tǒng)也能給vCenter帶來更多的穩(wěn)定性和安全性，官方預置的環(huán)境相對不熟練的管理員，也能避免自行配置中一知半解的不恰當配置，在硬件資源緊缺的環(huán)境中，Appliance能夠帶來集中且可靠的中央控制服務。同時，Appliance可以直接升級打補丁，這比分散搭建環(huán)境進行升級要容易許多。

提到升級，不得不說Update Manager這個組件，它能夠方便地對集群中的ESXxi打補丁或跨版本升級，可以對虛機的vmtools進行批量更新，強烈建議在每個vCenter中都部署它，因為安全問題無小事，每一個ESXi都承載了太多的虛機，存在安全或健壯性短板的ESXi無疑給上層運行的虛機帶來了太多意料之外的可能性。并且，通過它對ESXi進行跨版本升級也能保留原有ESXi上關于網絡和其他插件的配置，極大簡化跨版本升級時瞻前顧后的各種考慮。目前的UM沒有OVA版，需要自行安裝Windows環(huán)境去搭建。作為vCenter插件，難免在vCenter做了調整后遇到UM被禁用的情況，此時可以使用UM安裝路徑下的VMwareUpdate ManagerUtility.exe工具，重新注冊到vCenter以解決問題。

伴隨著虛機數量的增加，Operations Manager（以下簡稱 vcops）和 Data Protection（以下簡稱vdp）是兩個不可或缺的常見工具。

vcops收集從服務器到虛機的性能指標，通過算法將各個層面的性能狀態(tài)轉化為可視化的圖表值。通常，需要連續(xù)采集2個月的運行狀態(tài)，才能較為準確地反映出CPU、內存負載、網絡和磁盤吞吐率等情況的健康度，管理員依靠此工具，可以關注每個虛機和虛擬化整體的健康度，因為健康值是根據一長段時間的積累分析計算出來的，并不是單純地從當前和上一個時間段的負載去簡單比較，尤其對于磁盤I/O的負載，從SAN的管理端也只能看到哪個LUN的I/O較高，在vcops中能夠準確地知道是哪個虛機造成了較大的I/O。

與開源的Cacti或Nagios監(jiān)控工具相比，第三方監(jiān)控是對具體對象的監(jiān)控，每一個物理機、虛機的CPU、磁盤、網絡都可看到，是針對點的狀態(tài)反映，而vcops則將所有的對象關聯起來進行監(jiān)控和分析，得到的是針對面的狀態(tài)反映，這更有利于管理員掌握虛擬化基礎設施的綜合運行情況。

vdp是虛機的備份和恢復工具，備份的主要對象就是vmdk，與快照類似，利用差異化的vmdk文件實現增量備份，但卻獨立在生產LUN之外，能夠更好地管理vmdk，可以根據備份的策略實現不同粒度的備份需求，重復數據刪除也有效節(jié)省實際所需的備份空間消耗。在vdp虛機啟動過程中，可以觀察到許多avamar字樣，可以想象，vdp與avamar有著不淺的聯系，但與avamar相比，它們都是作為插件集成，vdp與vCenter結合的緊密度更高，avamar作為第三方插件，功能比vdp更為全面，收費也不低，而vdp總的備份空間限定在2TB之內，可以免費使用。

當然，vCenter可用的組件不僅限于上述，還有用于vSphere整體安全的vCNS，用于容災的SRM等，在近些年的快速發(fā)展中，一些組件逐漸消失，一些組件不斷得到加強而成為新的產品，這也正是虛擬化技術對IT持續(xù)散發(fā)的魅力所在。

將被變革的存儲

在服務器虛擬化發(fā)展的上一階段，CPU和內存一直是池化的主要對象，存儲還只是拿來就用的設備，與普通服務器系統(tǒng)相比，最大的區(qū)別就是將磁盤格式化為vmfs這個文件系統(tǒng)，這個文件系統(tǒng)與vmdk文件是相輔相成的，比如精簡置備、虛擬機集群等特性都是基于vmfs實現的。值得注意的是，vmfs也是有版本的，我們很可能會將vSphere環(huán)境跨版本升級到一個新的版本號，卻遺忘了檢查和升級vmfs的版本。一方面，vmfs版本升級可以修復一定的漏洞，另一方面，低版本的vmfs運行在高版本的虛機上，很容易引發(fā)虛機內I/O問題。

當前，存儲的池化成了本階段新的發(fā)展重點，vSAN就是利用服務器直連磁盤而創(chuàng)建的高可用存儲，它組網要求至少一塊萬兆網卡，擁有SATA/SAS HBA或直通模式下使用的RAID控制器，用于存儲容量的磁盤至少有1塊SSD和1塊 HDD（SATA/SAS），SSD與HDD裸盤容量的比例不少于1:10，每個主機可以創(chuàng)建不超過5個磁盤組，每個磁盤組的HDD不超過6塊，至少3臺滿足上述條件的主機組成集群。

符合上述要求的vSAN舉例來說，SSD的70%用于讀加速，30%用于寫加速，HDD是主要的容量供給，若單臺服務器可裝6塊3TB的HDD和2塊240GB的SSD，3臺服務器可獲取近50TB存儲空間，每臺400GB的磁盤緩存對于提升IOPS也能較好應用在大多應用場景，即減少了存儲的購置經費，也在一套技術體系內真正統(tǒng)管并池化了所有計算資源，減輕了存儲系統(tǒng)維護復雜度。

不過，vSAN更大的優(yōu)勢還在故障冗余，每個運行在vSAN集群中的虛機，可以設置為允許多個故障數，即設置虛機文件的冗余份數，在這樣一個3節(jié)點環(huán)境中，假設故障數設置為2，則可達到2臺服務同時壞掉，這一虛機仍可存活在僅有一臺服務器上，因為它在每個服務器的存儲上都具有了副本，這在以FCSAN/IPSAN為存儲的架構里則是難以達到的。當然，高可用的特性，也是以損耗總的存儲空間為代價的，但反過來，用代價不菲的存儲雙活技術所投入的經費和消耗的存儲空間會更多。從這個視角來看，vSAN就是顛覆傳統(tǒng)存儲的神器。

展望下一階段，新的vVOL技術將架起聯系vmdk與存儲LUN的橋梁，打破LUN不知道 有 vmdk，vmdk不 知 vmfs下是什么存儲的割裂局面，虛機成為存儲管理和存儲策略的基本對象。我們可以假想這樣的場景：給一個新建的虛機定義了高可用的策略，存儲就給該虛機創(chuàng)建多個互為克隆的vVOL，從而保證了虛擬機的可用性，甚至這多個vVOL放置在不同的存儲設備上，且互為鏡像，保證了無論是存儲設備還是服務器掛掉都無法阻止虛擬機的運行。

行進中的網絡虛擬化

原本一臺服務器接入幾個網絡就用幾塊網卡是件簡單明了的事情，而自虛擬化使用以來，一個物理服務器承載數十甚至上百的虛機也不是難事，于是，物理的網卡由單一的網絡接口一下子提升到承載上百端口，多個VLAN，甚至不同的個性化端口策略的需求上，儼然擔當了一個交換機的功能。再將視線擴展到多個服務器組成的虛擬化集群，服務器的網卡順理成章地成為了上連交換機的級聯口，其下對應著數以百計虛擬的網卡，于是，分布式虛擬交換機就這么誕生了，它將聯網的范圍從單個ESXi的標準虛擬交換機擴展到了整個vCenter的范圍，提供集中化的管理端口以及高級特性。

經過多年的發(fā)展，目前能用到的分布式虛擬交換仍然只有廠商提供的Virtual Distribution Switch（以 下簡稱VDS）和Cisco Nexus 1000V（以下簡稱N1K）兩個選擇。VDS原生在vSphere內部，具有圖形界面，部署配置更為簡便易用；N1K與VDS一樣首先是具備分布式虛擬交換的功能，其次，它具備Cisco網絡所具備的交換管理特性，能夠像對待直連交換機的服務器一般配置端口策略和訪問控制，并且這些配置在網絡遷移時也會隨之移動。同時，也使網絡管理能夠跨越vSphere層面回歸到傳統(tǒng)的管理習慣上，命令行的管理界面也更貼近網絡管理員的親切感。

伴隨著技術演進，各大網絡設備廠商陸續(xù)推出了與虛擬化環(huán)境相融合的新設備或新協議，以期適應以虛擬化為基礎的數據中心網絡管理。作為VDS的提升，NSX是新發(fā)布的網絡虛擬化平臺，它通過編程方式提供分布式路由、分布式防火墻等服務，在現有物理網絡上創(chuàng)建一個覆蓋現有IP網絡的靈活邏輯層，在滿足東西向和南北向通信的同時，租戶之間也保持相互隔離，在虛擬網絡內提供全面的流量管理、監(jiān)控和故障排除的工具，如端口鏡像、NetFlow/IPFIX、配置備份和還原、網絡運行狀況檢查、QoS和LACP等。簡單來說，基于服務器自身，NSX就構建了完整的數據中心網絡。

場景決定高可用程度

虛擬化的誕生，將每個操作系統(tǒng)所依賴的物理硬件特征全部虛化成了標準的虛擬硬件，那么，只要虛機文件還在，任何物理故障都不能阻擋服務快速恢復，因為標準的虛擬硬件可以不重裝系統(tǒng)就運行到另一個物理載體上，這也是虛擬化環(huán)境具備高可用性的重要基礎。虛擬化集群環(huán)境的這一資源切換技術由vMotion來實現。vMotion在線將CPU和內存的狀態(tài)從一個物理機復制到另一個，保持業(yè)務連續(xù)的同時，也改變了虛機的計算載體，這是多么不可思議的能力。

但這項能力也存在制約因素——CPU的指令集。集群中的服務器并不會是一成不變的一次性采購，而不同年份購置的服務器，其VPUu也會或多或少有指令集的更新，新增的指令集也就決定了虛機不能從新服務器漂移到舊服務器。為了應對集群內CPU之間存在的差異，我們可以啟用EVC功能，該功能需要指定集群內CPU系列的兼容度，也就是指定所有虛機都只在這一款CPU型號的指令集基礎上運行，從而滿足最大的兼容性，實現虛機從低配置CPU到高配置CPU的漂移。這樣一來，擁有更多指令集的CPU特性就不會在任何虛機上體現，其實質是放棄了部分高性能能力。本文是覺得特別可惜的，因此，是否啟用EVC也應由應用場景決定，或者放棄由新CPU向舊CPU漂移的能力，或者放棄新指令集的性能特征，亦或者將新舊CPU物理機編組到不同的集群。

有了vMotion做基礎，HA不間斷地檢測群集中所有的ESXi主機，監(jiān)控群集中是否有足夠的可用資源，以便在檢測到ESXi故障時能自動在其他ESXi上重啟虛機，當檢測到ESXi主機負載達到閾值，DRS將vMotion和HA融合在一起，根據ESXi主機的CPU或內存資源負載，動態(tài)地遷移虛機至較負載較輕的ESXi主機上。在此基礎上，DPM更進一步偵測集群負載，在整體負載較低時選擇ESXi主機并遷移其上的虛機到其他ESXi，繼而關閉空閑的ESXi主機達到節(jié)能降耗的效果，當集群負載升高，DPM利用iLO、IPMI或LAN喚醒來增加ESXi節(jié)點。

除了上述主機和虛機層面的高可用，虛機之上的應用層也可通過FT來實現，Fault Tolerance會創(chuàng)建一個虛機完全相同的副本，主虛機和輔虛機執(zhí)行相同順序的x86指令，任一虛機發(fā)生故障則進行透明的故障切換，從而最大限度地延長該虛機應用的正常運行時間。不過，FT在實際使用中并不像想象中那么完美，實現FT的虛機只能有一個單核vCPU，承載兩個虛機的物理機也必須一模一樣，不能有虛擬光驅等設備，限制條件較多，而且多次FT切換之后，可能出現輔助虛機不能自動啟動，有時重做FT提示配置跟FT不兼容等細節(jié)問題，實際使用時應多做測試驗證以適應場景需求。