#vsphere 5

目前最熱門的話題當屬雲端運算，而虛擬化技術可讓雲端應用產生加乘的效用。在虛擬化領域內，VMware開發的技術眾所皆知，該公司已在7月正式發表vSphere 5，這個新版本到底又增加了那些強大的功能呢？以下將從版本授權方式、可創建巨型VM、儲存設備支援等等面向來詳細介紹。

虛擬化是雲端的基礎，領導廠商VMware於今年7月正式發表vSphere 5，並且在8月底開放下載試用。對於這新一代的雲端作業系統，相信大家都很想知道，多了哪一些新的、更進階的重要功能？vSphere每個世代躍進幅度都很大，筆者針對一些較重要與較受矚目的功能，在此向各位介紹、快速總覽vSphere 5。

vSphere 5版本授權方式 新的vSphere for Enterprise簡化為Standard、Enterprise、Enterprise Plus三種版本，移除了vSphere 4的Advanced Edition。至於for SMB環境，則還是維持了Essentials、Essentials Plus兩種版本。 除此之外，並新增了vRAM Licensing Model，新的授權模式將不限制伺服器實體內的中央處理器（CPU）核心數與總實體記憶體，任何版本的vSphere 5均含有vRAM Entitlements。

▲ vSphere 5各個授權版本所提供的功能。（圖片來源：VMware網站）

vSpher 5推出時，一併發布了vRAM Entitlements。由客戶所採購的vSphere Edition決定每個實體CPU可以有多少vRAM的配額，然後加總得出一個vRAM Pool（並非看總實體記憶體有多少），如果用戶的VMs開機後的vRAM用量超過這個Pool，那麼就必須再額外購買License添加於vRAM Pool裡才行。 由於一開始vRAM limit per CPU限制較嚴格，這使得高密度記憶體用量的設備，例如刀鋒或多記憶體插槽的伺服器會非常吃虧，購置授權許可的成本可能會因vRAM Entitlements而暴增，這馬上引發了許多用戶的抗議聲浪，認為有徵收vTax之嫌。

▲ 修正前後的vRAM Entitlement比較。（資料來源：VMware網站）

VMware隨後也從善如流，著手修改授權模式，在三周之後放寬了vRAM限制，並明定單一VM的vRAM使用授權在vRAM Pool裡計算最多算到96GB，大於此也不須付額外License費用。 值得注意的是，免費版vSphere Hypervisor能使用32GB記憶體限制，指的是實體記憶體，而非vRAM。另外用於桌面虛擬化（VMware View）的VMs，則沒有vRAM Entitlements的問題。 ESXi時代正式來臨 以下從ESXi Only、Image Builder等不同方向來加以探討。 ESXi Only vSphere 5已經不再有ESX版本，只剩下ESXi。ESX本身有含Service Console（或稱COS）提供管理者當作管理介面，而ESXi只有精簡的Hypervisor提供安裝，主要透過remote CLI來控管，兩者的配置指令並不相同，使用者轉換到ESXi平台需要時間來適應。 ESXi並非免費，ESX可以做到的事情，ESXi基本上都能做到。但是ESXi有免費的vSphere Hypervisor，只提供「單機」虛擬化，所以這個部分應該要個別分開來看。多個ESXi hosts要被vCenter所控管，進而達到企業級應用的功能，是要付費的。 Image Builder vSphere 5的Image Builder讓用戶可以客製化ESXi的安裝映像檔，為不同硬體類型的實體Server打造專屬的Installation Images，部署各式各樣不同配置的ESXi。 這一系列的VIBs（VMware Installation Bundles）由不同的軟體元件所組成，例如Patchs或Drivers，將不同的ESXi image套用於不同規格的硬體伺服器。與Auto Deploy的功能搭配使用，能在短期內快速、大量部署ESXi host至資料中心。 Auto Deploy Server Auto Deploy Server提供了靈活的部署環境，藉由PXE Server、DHCP Server以及TFTP Server所組成的群體帶動達到安裝自動化。伺服器可以從PXE網路啟動，由DHCP取得IP、導向TFTP Server下載鏡像（Image）至實體伺服器的記憶體來啟動運作程序。 短時間內即可部署數十、數百部ESXi hosts，並由vCenter套用不同的Host Profile給予不同的ESXi host，既不須硬碟，也不須存在於USB、SD記憶卡，完全在實體的RAM運作。 這種將ESXi與實體Server切割、分開的概念稱為Stateless，好處是重新部署、更新ESXi Hypervisor到任何一台伺服器上都非常地快速方便，只要伺服器重新開機，重新載入（Reload）Image後，彈指間就是另一種配置（等於重新安裝ESXi），快速應付任何一種所需要的環境，有助於雲端資料中心的資源配置，更加具備彈性。

▲Auto Deploy運作流程。（資料來源：VMware文件）

Firewall 新增的防火牆模組座落於vmnic與Virtual Switch之間，依據防火牆規則透過vmknic檢查數據封包，並提供類似舊版ESX Firewall的圖形化介面，讓管理者能以vSphere Client來設定防火牆（Firewall），避免從ESX轉換到ESXi的過渡期間不適應command設定，而造成規則錯誤或疏漏的問題。當然，若使用者十分熟悉ESXi，亦可直接使用CLI配置防火牆。 Shell 包含新的Command Line Interface，將以esxcli替換過時的esxcfg Command，這是由原先4.1版的TSM（Tech Support Mode）演進而來，主要用於維護及除錯用途，目前仍在發展之中，尚未完整。 VMware從vSphere 5開始嘗試整合為單一CLI，改善以往必須使用多種命令列工具，以及不同指令對管理者所造成的困擾。

▲esxcli命令範例。（資料來源：VMware文件）

SSD Swap Cache 將高比例的VM集中在實體伺服器，需要大量的實體記憶體。但因為實體記憶體資源有限，不可能永無止盡地供應給VM，因此VMware使用TPS、Memory Ballooning、Memory Compression（4.1版以後提供）等方式，讓VMs可超額使用記憶體，以便活化、有效率地運用記憶體資源。 如果上述方法都用盡，實體Memory依然不足，此時就必須由Hypervisor來做硬碟Swapping，因為虛擬機器並不曉得實際上記憶體已經不夠了，仍舊持續不斷地使用，此時VM自認為擁有的記憶體，其實全部或部分是來自硬碟，嚴重影響VM運作效能。 vSphere 5現在允許管理者將Swap檔案配置到SSD，藉由SSD讀寫效能比傳統硬碟優異的特性，增進VMkernel Swap的運作效能。

▲SSD Swap Cache。（資料來源：VMware文件）

可創建巨型VM 在可創建巨型VM方面，可從以下幾個方面來加以說明： ‧ Virtual Hardware 8： 單一虛擬機器的虛擬硬體擴充能力，更加往上延伸。最大可使用到32個Virtual CPUs以及1TB的記憶體，足以勝任、肩負大型的Mission Critical Application於虛擬化平台的運作。（vSphere 4的Virtual Hardware Version 7支援到8個Virtual CPUs，記憶體則為255GB。） ‧ 更好的3D繪圖加速，提供桌面端更優異的體驗。 ‧ VM支援USB 3.0裝置、讀卡機以及EFI： 這裡指的是將vSphere client所在的遠端USB裝置，交付讓VM讀取，而非將USB裝置接在ESXi host上。有支援EFI的Guest OS也可以在Boot Options裡選EFI或傳統BIOS。 ‧ 配置Multicore vCPUs的新使用者介面： 以往想要使用一個實體的多核心CPU運作，在Guest OS會被辨識成多個Virtual CPU（Virtual SMP），可能就會造成某些軟體授權額外收費的問題。假使VM使用一個vCPU，又會產生實際上只運用到多核心其中一核的問題。所以MultiCore Virtual CPUs可以讓VM知道它實際上正在使用一個實體的CPU，但上面有多個Cores。此功能在4.1版就有，但要到進階設定去調整，而vSphere 5新增了圖形配置介面。 ‧ vNUMA： 邁入多核心處理器的時代，為了解決CPU與記憶體匯流排間的資料存取瓶頸，NUMA設計將系統分割為數個節點，固定的處理器、記憶體為相同節點，加快存取速度。一旦要存取不同節點，則透過Inter-connect交換資料。vNUMA技術可將硬體底層的NUMA架構傳遞給Guest OS，讓具有NUMA感知的應用程式，能夠完全發揮效益。 ‧ Guest OS可選擇安裝Mac OS X Server v10.6（Snow Leopard）：僅限於Apple Xserve system 3.1上安裝。 ‧ 與舊版VMware Tools、Virtual Hardware相容： 可讓vSphere 4的VM使用原來的VMware Tools與Virtual Hardware，運行於ESXi 5的host下，除非想使用到新功能，否則VM不必升級。 vCenter管理、可用度部分 關於vCenter管理、可用度部分，可從vSphere Web Client、vCenter Appliance和vCenter Server Heartbeat 6.4三方面來加以說明。 vSphere Web Client 早期可以透過Web Access功能，以瀏覽器登入vCenter管理VM，但功能受限，虛擬機器之外的大部分工作均不能使用，例如新增vSwitch、執行vMotion等。 這次VMware以Adobe Flex架構改寫成全新的Web Client，相容於IE 7、Firefox 3.5以上的瀏覽器即可登入vCenter使用Web介面管理虛擬化架構，執行絕大部分的vSphere功能，管理的實用性與可移動性大幅提升。 vCenter Appliance VMware很早就在發展Linux版本的vCenter，直到vSphere 5正式以VA形式跟大家見面。vCenter Appliance的好處是部署簡單快速，只要OVF檔Import到ESXi，馬上就可以使用該vCenter來管理虛擬化環境，並且可以節省購買Windows OS的授權費用。 但目前限制為：Linux vCenter沒有Update Manager和vCenter Linked Mode且不支援vCenter Server Heartbeat、預設DB2的資料庫可使用5個hosts及50個VMs左右、採用Remote DB只能選擇Oracle。 vCenter Server Heartbeat 6.4 vCenter可說是vSphere的管理中心，在VMware虛擬化架構中的重要性不可言喻，一旦vCenter失效，雖然不會影響ESXi、VM的運作，但資料中心會立即陷入管理上的麻煩。 若希望vCenter Server停機時間能降到最低，則可以考慮使用vCenter Server Heartbeat。它能避免包括作業系統、網路、硬體與應用程式產生問題時，導致vCenter Downtime的發生。 vCenter Server Heartbeat 6.4可在Windows AD裡將Active、Passive Server當成唯一實體，配發單一Virtual IP，並與vCenter更進一步的整合，透過vSphere Client可監看Alerts與Events。 更細緻的網路資源監控與分配 以下針對NetFlow、Port Mirror、Network I/O Control Enhancement等三項來加以介紹。 NetFlow vSphere 5以後，在vDS中可以啟用NetFlow功能，提供第三方網路工具軟體（Collector）擷取網路流量、單獨分析VMs、hosts或兩者間的Traffic。支援Intra-host（內部VM對VM）、Inter-host VM Traffic（VM對其他host的VM）以及VM to Physical Traffic（VM對實體）。在虛擬化環境中，NetFlow可以定義到PortGroup Level、Port Level、Uplink Level。

▲NetFlow。（資料來源：VMware文件）

Port Mirror Port Mirror用途在於來源端傳送網路封包，透過Switch Port時會複製一份，傳送到連接網路監控裝置目的端的Switch Port。 可監測來源端任何vSwitch port的Ingress、Egress或所有Traffic，目的端可以是VM、vmknic或uplink port，使管理者在虛擬化架構的網路問題時，便於除錯與分析。與NetFlow相同，須vDS才能設定。 Network I/O Control Enhancement 隨著各式各樣的Network Traffic越來越多，在有限的實體網路卡情況下，網路資源如何管控與分配，就顯得很重要。 NetIOC可將網路資源從Network Resource Pool分配給不同類型的使用，包含VM Traffic、Management Traffic、iSCSI Traffic、NFS Traffic、FT Traffic、vMotion Traffic、User-defined Traffic、Replication Traffic等，都可以由Network I/O Control依照Limits、Shares來分派管理。 全面性的儲存設備支援 vSphere 5提供全面性的儲存設備支援，包括VMFS-5、Storage vMotion、Storage DRS、Storage I/O Control、FCoE Software Initiator、iSCSI Software Initiator Enhancements、vStorage API for Array Integration Enhancements等等。 VMFS-5 與上一版本VMFS-3相較之下，單一VMFS Volume已經可以達到64TB（不須額外Extend），單一VMDK仍舊維持2TB限制，而Pass-through RDM也可大於2TB，Unified Files Block Size在創建超大檔案時可使用1MB file block size。 此外，從VMFS-3升級到VMFS-5是非破壞性的線上工作，可以不用擔心VM運作或是存放，受到檔案系統升級的影響。不過線上升級VMFS，有些舊的特性還是會保留，例如file block size會沿用舊版、無法使用8k sub-blocks等新的格式，所以如果可以，VMware建議建立全新的VMFS-5 Volume，再將VM搬移過來。 Storage vMotion Storage vMotion可讓VM檔案從原先所在的儲存設備，線上轉移到另一儲存設備，過程中不會有停機時間。原先若含有Snapshot的VM則不能Storage vMotion，而此限制在vSphere 5中已經解除。也因為如此，Storage DRS的功能得以實現。 Storage DRS 這是vSphere 5相當受到矚目的一項功能，如同各位所理解的DRS，能在Cluster裡將VM自由地線上搬遷移動，從此不用擔心VM身處何方。 而CPU與Memory資源夠不夠的問題，DRS會自動調度VM到硬體資源較充足的地方。Storage DRS已經將自動化負載平衡的功能，延伸到了儲存設備的層級。 由於虛擬機器是以檔案形式存放於儲存設備上運作，如果儲存設備的空間資源I/O資源利用率過高或過剩，配置不佳，對於VM Virtual Disk將有嚴重影響。 Storage DRS提供Initial Placement與Ongoing Balacing，依條件設置不同，再以Storage vMotion的方式，在不停機的狀況下，於Datastore Cluster內自動將VM檔案轉移至不同的儲存設備，改善儲存設備等級不同、空間利用率與I/O瓶頸的問題。 Storage I/O Control 以往，在沒有SIOC的情況下，VM的Disk Shares是在個別的ESX(i) Server競爭，這種情形會造成I/O queue的表現與希望的結果不符，因為Host Level儲存資源分配的問題並沒解決。 從vSphere 4.1開始正式有SIOC，可針對VM存取Datastore設定整體I/O Shares與Limits，達到真正QoS優先順序。到了vSphere 5，則是連NFS Datastore都可以設SIOC。

▲有無SIOC的比較。（資料來源：VMware網站）

FCoE Software Initiator vSphere 4推出以後，新增了支援硬體式FCoE Adapter（Fibre Channel over Ethernet），而vSphere 5現在又更進一步，支援了FCoE Software Initiator。這意味著如果使用者的網路卡有部分FCoE卸載功能的話，即可當成軟體式FCoE Adapter，低成本地享用FCoE所帶來的好處。 iSCSI Software Initiator Enhancements vSphere 4支援iSCSI MPIO來達成Storage Multipathing，但需要以Command Line的方式來啟用iSCSI Port Binding，這對想要在vSphere實施iSCSI多重路徑存取的人造成困擾。 vSphere 5現在改採圖形配置，簡化操作。管理者只要透過vSphere Client，即可在GUI圖形介面中設定vSphere的iSCSI Multipathing。 vStorage API for Array Integration Enhancements VAAI也是vSphere 4.1之後的功能，可大幅增進Storage vMotion、FT轉換（因啟用Fault Tolerence時，VM儲存格式須為eagerzeroedthick），以及VM provisioning時的效能，降低CPU、Memory的使用率，但儲存設備須有支援此協定，才能發揮效用。 vSphere 5.0後的VAAI則新增NFS Full Copy的功能，特定的NFS儲存設備已支援VAAI，由Storage Array來Offload處理器與ESXi hosts之間的I/O，對於NFS複製、移動VM的效能幫助非常大。 VASA vStorage API for Storage Awareness讓儲存設備的詳細資訊可透過vCenter展列出來，不必依賴各種不同廠牌的Storage管理工具來取得資訊。這有助於管理者或Storage DRS在移動VM檔案時，作為理想的判斷依據。 儲存設備廠商可將Storage相關各類資訊，依循VASA讓vCenter讀取，在兩者緊密搭配的狀況下，雲端世界的自動化運作、判讀與決策，才能更加順暢地接軌。 Profile Driven Storage 當產生一個VM的時候，必須選擇要存放VM files的Datastore，這時候就必須知道VM應該放置於哪一個合適的Datastore。 但是，資料中心所配置、共享的LUNs通常很複雜，有時候不容易知道虛擬機器應該放置於何處，隨便產生、隨便放置的結果，造成日後管理非常的困難。 此時，如果可以預先定義好不同層級的Datastore，將之分類固定，以後在創建VM或Storage DRS在自動搬遷VM檔案時，套用定義好的Storage Profile，就會很輕易找出符合該VM存放的棲身之所，解決VM與Datastore間的管理困擾。 Profile Driven Storage搭配Storage DRS功能，可達成事先依屬性簡化，事後自動重分配規畫，不用再費心於VM與儲存裝置間的最佳化安排。

▲Profile-Driven Storage。（資料來源：VMware網站）

備份、可用度更上層樓 vSphere 5的備份、可用度更上層樓，其中包括了vDR 2.0、vSphere Storage Appliance、vSphere HA等等，以下分別加以說明。 vDR 2.0 VMware Data Recovery是以VA形式部署於虛擬化環境的Appliance，定位於中小企業環境的備份與回復方案。新版vDR已完全改為64bit Virtual Appliance，擁有E-mail Report與更好的資料重複刪除效能。另外須注意的是，vDR即使沒有vCenter，也可以做資料復原的工作。只需重新部署新的vDR到ESXi，將備份空間連結回來（VMDK、NFS或CIFS形式），便可載入舊的設定，執行資料回復的工作。 vSphere Storage Appliance 對於中小企業環境來說，專屬的SAN儲存設備可能價格偏高，如果要達成Storage層級的HA更是一大負擔。若沒有FC SAN、iSCSI或NFS這些Shared Storage，也沒有辦法運用vMotion、vSphere HA、DRS等功能。VSA（目前為1.0版）可讓中小企業將ESXi host本機硬碟由Local端的VMFS-5走NFS協定，搖身一變為每部ESXi hosts都能存取的Shared Storage。 配置VSA可分為2個Nodes或3個Nodes運作模式，透過網路每個節點的NFS Datastore都會產生鏡像副本，同步到另一host，這樣即使因實體故障或網路斷線，Shared Storage功能依然可以正常運作。但VSA定位在SMB使用環境，提供低成本共享儲存資源、高可用度的解決方案，對於要求儲存效能、空間或區塊存取的企業，並非合適的選擇。

▲VSA架構。（資料來源：VMware文件）

vSphere HA 不同於前面版本，VMware重新改寫HA架構。新的vSphere HA改採一個Master host，其餘均為Slave hosts，移除以往需要5個Primary hosts的架構，避免客戶採用刀鋒伺服器時可能讓所有Primary hosts在同一機箱，而導致全面離線的情形。 vSphere HA的Heartbeat除了透過Network，也新增Heartbeat Datastore來互相溝通。另外配置、執行vSphere HA也不再需要透過DNS名稱解析，避免DNS額外的故障造成無法執行vSphere HA的狀況出現。 Fault Tolerance 因為vSphere HA是重新啟動VMs負載於其他hosts，會有短暫的停機時間，如果VM不允許任何因實體故障產生停機時間，便可啟用Fault Tolerance來達成零停機、沒有資料遺失的服務。FT為vSphere 4開始有的功能，因對於CPU與Guest OS有所限制，使用者必須先參閱相容性列表。vSphere 5的FT支援更多的處理器與作業系統。 由於FT是Primary VM與Secondary VM分別於不同ESXi host同步的關係，擁有隨時啟用與關閉、不限特定作業系統（在Support List上的Windows與Linux版本皆可使用FT）、配置簡單、沒有特定應用程式不能支援的限制，只要OS Level不當機，就可以達到不擔心實體損壞，保護任何應用程式的效果。 Application Monitoring API 使用Fault Tolerance不能完全取代MSCS之類的叢集服務，因為它並非Application-aware的解決方案，沒有保護至應用程式等級。為了不讓應用程式當機而產生停止服務的情形，藉由Application Monitoring API，開發廠商可依循發展Application監控軟體，整合到vSphere架構，確保Guest OS的應用程式層級也能受到保護。 SRM 5 SRM（Site Recovery Manager）用途在於異地備份與測試計畫，透過vCenter SRM Plug-in管理，底層是執行儲存設備廠商的遠端複製功能。 以往兩端需要同廠牌、同系列的Storage，而SRM 5新增了vSphere Replication功能，由Hypervisor透過網路即可進行遠端複製，這相當於Host Based就能提供異地災難復原方案，不用考慮Storage廠牌型號與等級。雖然效能無法與專有儲存設備相比，但對於有成本考量的企業來說是好消息。