對於資料庫、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上,只需要一點點的記憶體,而且速度比過去快上好幾倍。

熱門新聞

Advertisement