vSphere深化SSD固態儲存虛擬化運用，新增更多硬體支援

對於資料庫、Exchange這類關鍵應用系統，企業之所以遲遲不敢導入虛擬化，原因往往在於系統本身的I/O負擔已經很沈重，廠商也再三保證轉移到伺服器虛擬化平臺運作後，效能足以負荷，例如在2011、2012連續兩年的VMworld大會上，VMware就實機展示以單臺ESXi主機，甚至單臺VM，來支援1百萬IOPS的存取能力，以1百萬IOPS的VM的例子來說，之所以能有這麼好的存取效能，與當中特別搭配了2臺Flash儲存陣列，有很大的關係。

這樣的儲存設備，至今價格仍相當高昂，一般企業負荷不起，退而求其次，在伺服器端使用固態儲存來加速I/O的存取，似乎機會越來越大，因為SSD的價格日漸下降，容量也越來越大，在每臺伺服器上裝個幾臺SSD來用用，企業還比較負擔得起，而vSphere從5.0版開始，後續對於固態儲存應用都有所著墨，5.5版也不例外。

虛擬化平臺的系統效能要好，能夠承載的網路吞吐量（Throughput）也必須要有一定水平，而虛擬化平臺本身的規格也都有所支援。例如VMware在vSphere 5.0之後，ESXi主機本身能夠支援的10GbE網路連接埠數量，有8個之多，到了5.5版又增加了對於40GbE這項新的網路規格支援，單臺ESXi主機可存取4個40GbE的網路連接埠。

除了就儲存、網路個別來看效能需求，虛擬化平臺對高速儲存區域網路（SAN）的支援，同樣有助於提升I/O，vSphere 5.1已開始支援16Gb的光纖通道網路規格，到了5.5版，真正做到了貫穿交換器、磁碟陣列、主機等端點，全程都能用16Gb/s速度存取。

由於桌面虛擬化日益普及，對於影像、視訊、3D等繪圖運算較密集的應用效能，也逐漸受到重視，作為更底層執行的伺服器虛擬化平臺，近年來對於硬體GPU支援越來越積極。像vSphere在5.1版就開始正式內建對Nvidia vGPU硬體支援，5.5版則擴大支援更多廠牌、型號的繪圖處理器。

不只記憶體快取，固態儲存裝置也能虛擬化，化為共用資源
隨著SSD這類固態儲存的市場接受度越來越高，vSphere近期版本陸續支援了功能，例如，5.0版開始新增以SSD作為記憶體不足時的置換快取功能（SSD Swap Cache），5.1版加入了SSD監控、分析與回報機制，可收集13種使用狀態的屬性，到了最新推出的5.5版，對於固態儲存應用有更大幅度的支援，其中最重大的改變，就是當vSphere要讀取Flash儲存裝置時，系統可啟動快取機制的支援，這項技術稱為vSphere Flash Read Cache（vFRC），它同樣整合在vSphere內運作。

vFRC除了字面上的快取機制之外，更重要的意義是可以讓vSphere主機端的Flash儲存裝置，能更直接地運用在虛擬化環境，它可統合不同ESXi主機連接的多個Flash儲存裝置，化為單一共用的vSphere Flash Resource。

形成這個Flash儲存資源池後，最大好處是可供VM運用和管理，支配這類儲存資源的方式，就如同vSphere目前可跨越多臺硬體伺服器，共用運算核心與記憶體容量一般。

將伺服器端Flash儲存裝置加以虛擬化後，也等於為建置在VM內的應用系統，提供一個大幅降低延遲、高效能的快取層，而且VM內不需再安裝代理程式，就可以更直接地存取這些虛擬的Flash資源。

vFRC對於讀取密集式的應用，以及經常需存取伺服器本機磁碟的資料處理作業，有顯著的加速效果，VMware認為適合導入這項技術的應用系統型態，包括資料倉儲、網站代理伺服器、監控用的伺服器；此外，像是桌面虛擬化也相當合用，vFRC可作為記憶體與存設備端磁碟之間的快取層，就記憶體資源的配置而言，若遇到需超量供應VM的情況，搭配這項機制可發揮很大作用。

基本運作架構
要達到這樣的應用，VMware是基於兩大主要元件：基礎架構vSphere Flash Read Cache Infrastructure，以及軟體vSphere Flash Read Cache Software，透過它們的合作，將每一臺vSphere主機所連接的Flash裝置，整合到vSphere儲存架構中（vFRC不支援遠端的Flash裝置）。

● vSphere Flash Read Cache Infrastructure：在這樣的架構下，vSphere Flash Read Cache Infrastructure將負責管理與協調 Virtual Flash Resource，並且可實施控管政策。這個虛擬Flash資源之所以能夠做到跨多臺主機共享、運用，主要是透過Virtual Flash Host Swap Cache for VMware vSphere Hypervisor，以及Virtual Flash Read Cache for Virtual Machines。

以Virtual Flash Host Swap Cache來說，主要是用於ESXi主機端的記憶體快取，它的出現，也取代了vSphere 5.0開始支援的SSD Swap Cache機制。以目前vSphere 5.5版所提供的功能來說，ESXi Hypervisor最多能利用4TB的虛擬Flash資源，作為記憶體置換的快取，經過管理者設定需要的容量後，系統就會保留下來，而不讓VM運用。

● vSphere Flash Read Cache Software：這項機制是以原生方式內建在ESXi Hypervisor中，提供直接寫入的快取模式（write-through cache mode），可強化VM的效能，而且用戶不需修改或調整應用程式與作業系統的組態。

vFRC軟體對VM的效能有所改善，主要是和vFRC運作位置有關——它是直接坐落在VM存取虛擬磁碟的路徑上，由於Flash儲存具有高速I/O的特性，而能加速vSphere環境中密集的工作負載處理，所以可強化VM效能。

然而，因為Flash儲存裝置已經虛擬化了，VM本身也無法偵測vFRC的行為與配置，因此，vFRC軟體還有另一個作用，是管理ESXi主機上VM所提出的I/O存取請求，它會採用適合的演算法來進行控制。

運用虛擬Flash資源時，不論是透過讀取模式或直接寫入模式，vFRC的工作集（working sets）都是根據每個VMDK檔來配置，而不是根據每臺VM的層級，VM只有在開機的狀態下，才能運用vFRC工作集。

與vSphere緊密整合的vFRC，也不單只是用於VM日常的開機運作，它也相容於VM即時線上遷移相關的vMotion、HA（High Availability）和DRS（Distributed Resource Scheduler）功能。也就是說，啟用這個快取機制下的VM，一樣能照常移轉至其他ESXi主機上，若用DRS，vSphere將會根據可用的資源來自動放置相關的VM。

管理者也可透過vSphere Web Client來設定進階選項，例如是否在遷移VM到其他主機時，將快取內容一起搬移過去或丟棄。

若啟用vFRC，當管理者在VM上執行特定作業時，會影響快取內容。例如快照、複製、遷移、快速暫停∕回復時，vFRC會保留快取內容；當進行暫停、調整大小、變更、刪除、修改、套用還原點回復，以及VM、 ESXi主機重新啟動，vFRC會丟棄快取內容。

vSphere Flash Read Cache的運作架構

在vSphere 5.5版中，增加了ESXi主機端固態儲存虛擬化的機制vSphere Flash Read Cache（vFRC），它是一個基於Hypervisor的軟體定義式Flash儲存層，能匯聚ESXi主機上的多個Flash儲存裝置，成為一個Flash資源供VM運用，並且也能以記憶體快取的方式，用於加速ESXi主機的資料存取。

VMware為固態儲存虛擬化，提供專用檔案系統

既然Virtual Flash Resource是一種跨不同ESXi主機所共用的儲存資源，不免讓人想到vSphere的叢集檔案系統VMFS（Virtual Machine File System）。

的確，在vFRC應用下，VMware從VMFS衍生出新的專屬檔案系統VFFS（Virtual Flash File System），Virtual Flash Resource會存放在VFFS這個邏輯容器內，這是針對固態儲存最佳化，以及將多臺SSD結合成單一的快取資源池等用途所設計的，然而，這個資源池並非持續存在的，因此無法在當中存放VM。

想要建立VFFS格式的固態儲存資源池，伺服器端所採用的SSD連接介面可以不同，目前不論SAS、SATA或PCIe的SSD，VFFS一律視為同樣的Flash裝置，並不做區分。VMware也提醒，混用多臺SSD時，須注意各裝置之間的讀寫速度差異，若想要追求高I/O效能，裝置的讀寫速度應盡可能地一致。

以vFRC的使用規模來看，目前1臺ESXi主機可將8臺Flash儲存裝置用於vFRC，最大可支援到32TB的容量。若要使用Virtual Flash Host Swap Cache，最大可配置4TB。每個VMDK能搭配的vFRC工作集預設最大值為200GB，但可上調到400GB。

而且，每臺ESXi主機只能設定1個VFFS，擴增到叢集時，每個叢集可橫向擴充的最大幅度，是32臺ESXi主機使用VFFS（只能以ESXi主機的層級管理，不能以叢集層級來管理）。

支援PCIe SSD熱插拔，有助於2.5吋高速固態儲存應用
在當前伺服器的本機儲存配備上，除了傳統硬碟，能夠搭配固態硬碟的機型越來越多，在vSphere的虛擬化平臺上，原本就已支援SAS與SATA介面硬碟的熱插拔。有了這項功能，若需要更換硬碟，不需要將ESXi主機關機即可進行，可降低VM因此停機的時間。

到了5.5版，vSphere正式支援SSD的熱插拔，該機制也擴及對PCIe介面SSD的支援，在已經開機運作的vSphere主機上，現在可以隨時插拔SSD裝置，Hypervisor底層的儲存堆疊會偵測到這樣的變動而加以調配。當然，這麼做的前提是，ESXi主機本身的硬體和BIOS，需支援PCIe介面裝置的熱插拔。

不過，vSphere這項新支援，很多人特別對PCIe SSD是否有需要支援熱插拔，感到不解，因為多數人的印象中，PCIe SSD的形式大多是內含許多Flash記憶體的介面卡，也有一些是可插上Flash記憶卡的擴充模組介面卡（Disk On Module，DOM）、針對機架式伺服器有限空間所特製的介面卡（Rackmount SSD）。

但是，2012年開始，市面上出現一種新興的2.5吋規格PCIe SSD，這種固態儲存裝置外型近似2.5吋硬碟，而且已經有伺服器支援。例如，Dell PowerEdge 12代伺服器產品當中，目前有R820、R720、R620、T620、M620、M820機型，可配備PCIe SSD（Dell稱這樣的搭配方案為PowerEdge PCIe Express Flash SSD）。而PCIe SSD以這樣的方式在硬體伺服器使用時，實務上就會有熱插拔的需求出現，因此， vSphere 5.5對這項規格的支援，其實並無不合理之處。

事實上，目前市面上是有2.5吋的SSD，但大多是採用SATA或SAS介面，並無法完全發揮SSD的真正實力。第一批2.5吋PCIe SSD是由美光（Micron）在2012年3月推出的P320h，去年則接續推出容量可達1.4TB的P420m，而且兩個系列都是定位在企業級應用的產品。

以目前來看，這類固態儲存選擇性似乎不多，但在最近剛落幕的CES 2014大展上，威剛、金士頓等廠商都展出了2.5吋PCIe SSD，雖然不確定接下來他們是否會將這些產品推入企業應用，但似乎有機會讓2.5吋PCIe SSD變得更普及。

主機端電源管理整合新機制，可運用處理器C-State節電

在vSphere 5.1版以前，VMware對ESXi主機施行電源管理的要求時，主要是利用處理器的P-state（performance state）的技術，它能讓主機的處理器以低時脈和低電壓狀態運作。到了vSphere 5.5，VMware開始運用另一種更深層的處理器省電技術C-State，能節省更多伺服器端的用電。在ESXi採用的電源管理機制中，系統預設的平衡電源管理政策已經採用了C-State，如果你想要讓伺服器減少更大幅度電量，還可以選擇低耗電的電源管理政策，相對地，系統就會更積極利用該技術來省電。

C-State除了能進一步減少主機耗電量之外，有趣的是，它同時也會帶來伺服器運算效能增加的好處。因為在同一顆實體處理器的部分核心一旦進入深層的C-State休眠，處理器本身會更快進入加速運作的模式，因為對其他核心而言，可超頻的時脈額度就會相對增加，而透過這樣的加速模式，可以讓系統藉此達到更高的運作效率。

對於vSphere 5.5可運用處理器的C-State來節電，一般人可能覺得還好，對長期維運企業資料中心的IT人員，卻是很感興趣，因為這可以省下大筆電費支出。

趨勢科技全球資訊服務技術部技術經理林澤成，就提到該公司對這功能的想法。在趨勢科技的資料中心環境裡面，往往執行虛擬化平臺的主機一建置起來，就是以高效能的模式在運作，然而高效能意味著高耗電，而且伺服器在這種狀態下所散發的熱量也很大。但並不是每一臺主機都需要持續維持這樣的效能狀態，因此，他說，若能進一步驗證vSphere對C-State支援的省電成效，他們就會考慮使用趨勢。

擴充vGPU繪圖處理加速的硬體支援，並延伸至Linux作業系統的VM

VMware在vSphere推出5.1版時，正式支援了硬體3D繪圖處理加速，自此VM配置的虛擬顯示卡，不只是能支援3D繪圖加速，對於3D演算繪製（Renderer）的支援除了透過軟體，在vSphere 5.1的環境中，也可選擇用硬體方式來支援。

而支援這種vGPU的硬體產品主要是Nvidia的繪圖卡，包含Grid系列的K1、K2， Quadro 系列的4000、5000、6000，以及Tesla M2070Q。而使用上述產品的用戶，有兩種運用GPU資源的作法：一種是選擇用GPU pass-through的方式，也就是將每一顆實體GPU配置給專屬的VM，這種方式稱為vDGA（Virtual Dedicated Graphics Adapter）；另一種則是GPU Sharing，將GPU的運算資源透過軟體來虛擬化，讓多臺VM得以共享，這種方式稱為vSGA（Virtual Shared Graphics Adapter）。

到了vSphere 5.5版，VMware對vGPU的支援可擴展到其他廠商的繪圖處理器產品，AMD的GPU繪圖卡確定支援，包含FirePro S7000、S9000和S10000，以及FirePro v7800P、V9800P，但vSphere 5.5原本預定支援Intel的GPU產品，至今沒有看到VMware和Intel公布相關的支援清單。

若根據上述Nvidia和AMD產品的同樣定位，來看VMware對Intel產品的支援，似乎應該是Xeon Phi處理器入列，但Xeon Phi本身並非繪圖處理器。在伺服器、工作應用領域中，似乎只有Xeon Processor E3-1200系列，內建了Intel HD Graphics P3000、P4000系列的GPU，但性能是否足以支應單臺專屬或多臺VM共用的方式，就很難說了。

在vSphere 5.5的環境下設定vGPU時，系統提供3D繪圖運算繪製模式，有自動、硬體、軟體等3種。除了應用效能差異之外，當VM執行線上遷移時，不同模式會有影響。

一般來說，在混合運用不同vGPU的環境下，執行vMotion將VM遷移到其他ESXi主機時，不論你所選的模式，都不會造成VM當機或故障。因為，若管理者啟用的是自動繪製模式，且目的vSphere主機沒有GPU時，軟體繪製模式會自動啟用；如果設定為硬體模式，目的vSphere主機卻沒有GPU時，vMotion就無法進行。

在vSphere要讓硬體vGPU支援產生功效，通常須透過vSphere Web Client和VMware Horizon View來設定，VM的部分也要配合，只有限定的作業系統能支援。以微軟平臺來說，需使用Windows 7和8；若為Linux，VMware在vSphere 5.5環境才開始支援這個作業平臺的硬體GPU加速，用戶需在VM安裝Fedora 17、Ubuntu 12之後的版本，以及Red Hat Enterprise Linux（RHEL）7。

採用上述這些Linux作業系統的VM，現在能存取vSphere主機上的GPU，改善繪圖相關作業整體的效能與延展性，並且支援一些3D應用規格標準，像是OpenGL 2.1，以及Linux環境特有的設定，例如直接演算繪圖管理員（Direct Rendering Manager，DRM）的核心模式設定，改變X Window環境的桌面大小和螢幕頻率的指令Xrandr（X Resize, Rotate and Reflect Extension）、硬體加速XRender，還有X Window的影片輸出方式Xv（Xvideo，X video extension）。

除了上述三種Linux版本之外，其他Linux版本未來也將有機會支援VM環境中的3D硬體加速機制，因為VMware趁這次機會為VM環境中的Linux作業系統，開發了新的驅動程式，並且將原始碼貢獻給開放原碼社群。

對於16Gb光纖通道協定的運用，提供更完整支援

在網路儲存應用的領域中，對於光纖通道（FC）協定的存取能力，也是虛擬化平臺必須具備的。目前雖然16Gb FC還未普及，但應該會逐漸取代目前8Gb FC的規格，而vSphere從5.0版就已支援16Gb FC的HBA卡，不過，這些HBA的存取頻寬通常都只到8Gb，之後就上不去了。

5.1版之後，vSphere雖然讓這些HBA卡提升到16Gb的工作模式，但還是無法做到全程（主機端到磁碟陣列端）以16Gb連接的程度，為了要獲得完整的頻寬，在交換器到磁碟陣列之間，須同時建立多個8Gb連線才行。

到了vSphere 5.5，VMware終於讓虛擬化平臺做到全程支援16Gb存取頻寬的程度，條件是Initiator端和Target端之間的光纖通道交換器能支援這項規格。此時，不論是HBA端或是磁碟陣列的控制器，都可以用16Gb的模式連線。

突破10GbE應用，首度支援40Gb規格網卡
在過往的版本，vSphere系統所支援的最高速網路介面是10GbE規格，在vSphere 5.5中開始支援40Gb規格的網路卡，Mellanox ConnextX-3 40GbE網卡驅動程式已經整合在vSphere 5.5內。

而且在Mellanox所公布的效能測試結果中，配備ConnextX-3網卡的伺服器搭配SwitchX 40GbE的網路交換器，以及QSFP+纜線，所得到的持續吞吐量可超過37Gb/s，相較於10GbE網路，這樣的解決方案增加了可負荷的流量，可讓單臺伺服器承載4倍數量的VM。

在5.5版中，vSphere也簡化了支援SR-IOV（Single-root I/O virtualization）標準的網路卡設定流程，並且具有另一項新功能，讓使用者能夠與網路埠群組溝通，而相關內容是在vSphere標準交換器或分散式交換器來設定的，以便執行網路卡的虛擬功能。

建置經驗談－ 趨勢伺服器搭SSD改善DB虛擬化效能

去年11月，趨勢科技在VMware Solutions Symposium研討會上，分享了導入VMwae虛擬化平臺的建置經驗，並披露該公司現行採用的混合雲架構，他們的目標是將資料中心應用系統全面虛擬化，而目前他們有幾個工作重點：提升虛擬化平臺的I/O性能、將資料庫系統虛擬化，以及讓一些採用老舊版本作業系統的伺服器虛擬化。

其中最令人好奇的是，他們的資料庫系統虛擬化所使用的硬體伺服器，都會搭配SSD固態儲存，希望可以透過這類裝置本身的高速存取I/O特性，使資料庫系統移植到虛擬化平臺執行後，效能不會因此而打結。

若使用vSphere 5.5之後，雖然可以享受到62TB VMDK的好處，但在趨勢科技的IT應用環境中，幾乎每一個資料庫的檔案都會需要超過2TB的空間，而且目前單臺SSD的容量目前還比不上傳統硬碟，是否要用更多臺SSD，或與傳統硬碟搭配使用，才能達到足夠的空間需求，在虛擬化平臺上全部都用SSD，划算嗎？

對此，趨勢全球資訊服務技術部資深經理陳凌旭表示，目前他們所採用的伺服器硬體設備，一臺就可以容納24臺SSD固態儲存裝置，所以，對他們來說，主機用SSD作為儲存，容量並不是太大的問題。

他提到，這些資料庫系統的儲存位置，原本是位於網路共用儲存設備的SAS磁碟上，當他們將資料庫的儲存位置移轉到已經裝載SSD的伺服器時，發現一個有趣的現象：當資料庫執行在這樣的新環境中，其實所需要的記憶體容量反而是降低的，而且速度比過去快上好幾倍。過去的資料庫系統執行的伺服器硬體組態是16核心的實體處理器，搭配192GB實體記憶體和SAS磁碟，但現在SSD的伺服器上運用虛擬化平臺執行DB時，他們只需2顆虛擬處理器，搭配32GB虛擬記憶體和SSD就可以達到目標。因此就整體持有成本來說，改用SSD仍是比較低的。

陳凌旭說，他們目前正在作的部分，就是讓所有實體伺服器能夠整個虛擬化，其中一項工作，就是把資料庫的負擔從網路共用儲存的架構，卸載到伺服器本機的SSD上，也因此，對於16Gb FC的SAN應用，趨勢以後應該是不會考慮。他預期，公司未來對Shared Storage的效能要求會大大降低。而在VMware虛擬化環境中，若用伺服器本機儲存的架構，就能做到vMotion的即時遷移，將是他們很期待的新功能，而能符合這項要求的技術，他說就是VMware Virtual SAN。

趨勢全球資訊服務技術部資深經理陳凌旭表示，若將資料庫系統的儲存裝置改為伺服器本機的SSD上，只需要一點點的記憶體，而且速度比過去快上好幾倍。