為何採行伺服器虛擬化？

透過伺服器合併，可以協助解決伺服器使用率過低的問題（根據IDC在2007年初的研究，顯示業界廣泛認同的平均使用率為7%）。儘管每台伺服器的使用率不一樣，但他們同樣必須進行採購、建置，以及消耗電力。要解決這些問題，第一步也是最簡單的一步，就是將在所有不同伺服器上執行的作業系統與應用程式，集中到單一平台上執行。這種作法的主要好處是降低採購成本，以及減少耗電量。

第二個階段的重點是效率，旨在讓多部虛擬化伺服器能機動管理各種資源、將虛擬機器在各部伺服器之間轉移、自動處理容錯移轉作業、和以透明化模式進行預定時程的停機、升級、維護等動作。這個階段非常注重降低平台的管理成本與營運費用，而硬體與軟體的技術均沿著類似的發展途徑－第一個建置的方案採用標準硬體，使用像是二位元更新修正檔等軟體技巧，來建構虛擬層。之後再加入像是Intel VT-x 與VT-i 技術，以及AMD-V等硬體元件，協助從客戶端作業系統中進行CPU與記憶體提取的複雜作業。

下一步驟，首先處理的也是軟體：將虛擬機器監視器（Hypervisor）基礎架構，從二位元更新修正檔轉移到模擬與半虛擬化，藉以改進底層虛擬化架構的效率並降低系統的負荷。最後一步是降低虛擬化環境所佔用的空間，從GB降低到數十MB，減少軟體所耗用的資源。

被遺忘的I/O

由於初期的焦點大多數是軟體基礎架構，因此所有的心力都聚焦於改進常見的軟體瓶頸，但其中大多數問題其實來自CPU與記憶體。

I/O通常被視為一個經常使用的資源，即使虛擬機器監視器將I/O從作業系統（稱為Guest OS或GOS）中抽離，還是會讓每一個動作看起來彷彿I/O仍然存在。事實上，這種解決方案仍相當實用，尤其是在最近有顯著進步的模擬與半虛擬化技巧輔助之下。但這意謂I/O硬體仍屬於單一元件，本身擁有許多先天的限制。例如其仍會被虛擬機器監視器所“欺騙”，假裝自己是在服務單一作業系統，而不是同時服務多個虛擬化的GOS。

由於I/O與GOS缺乏“相互認知的能力”，因此雖然能簡化部署的過程（由於作業系統與I/O都不知悉對方，因此並不需要任何變更），但卻衍生出本身的效率問題，還有安全方面的疑慮。

基本上，虛擬機器監視器是所有元件的守護者，而每個GOS的每次I/O要求，都必須由虛擬機器監視器來處理。虛擬機器監視器提供抽離服務、處理GOS佇列、岔斷服務、以及管理異常狀況。

從好的一面來看，目前的模式提供許多能改進I/O及儲存功能的機會。最顯而易見的例子，就是虛擬機器監視器擁有一個內部檔案系統（例如VMware中的VMFS），能從軟體面著手，作為儲存虛擬化的彙整點，然後再將軟體重新分配給GOS。

上述模式支援許多以往向來和SAN有關的功能：諸如隨需分配儲存、建立快照、以及透過資料群聚（Pooling）或其他技術，進行抽象儲存。一組連結至儲存區域網路的伺服器，成為與虛擬機器監視器檔案系統的GOS儲存連結，而這樣的儲存系統仍舊位在實體機殼的內部。但這也形成許多限制，包括：

效能：

相較著重於MB/sec或IO/sec的非虛擬化伺服器來說，這部分的問題比較嚴重。因為虛擬機器監視器會運用系統CPU來管理抽象作業（進而降低生產力應用所能掌握的CPU運算週期），且資料在傳到發出要求的GOS之前，必須透過虛擬機器監視器進行轉移。這會對每個GOS產生冗長的延遲，進而降低GOS的生產力。對於依賴快速反應來提高生產力的交易型應用，這方面的問題會更加嚴重。效能不必非得取決於將MB/sec或IO/sec維持在可接受的範圍，其他如延遲（指令從作業系統傳送到儲存裝置，以及儲存裝置回應到原始作業系統所耗費的時間）和系統CPU使用率（處理每個I/O須耗費的資源）亦為重要因素。

安全性：

當所有資料都匯入虛擬機器監視器時，他們就變得必須跟其同生共死。虛擬機器監視器上的臭蟲（Bugs）、操作人員的管理疏失、以及病毒等，都會影響在平台上的所有資料與作業系統與應用程式，而不是僅影響單一個體。安全防護由虛擬機器監視器軟體來統括執行，這雖然對某些應用程式來說非常安全，但對其他程式來說可能是一個嚴重的安全漏洞。

服務品質（QoS）：

同樣的，服務品質也跟虛擬機器監視器有關。透過虛擬機器監視器，系統必須執行更多程式碼來加強服務品質（運用系統資源），但這類程式碼僅能執行虛擬機器監視器所提供的功能。在I/O控制器的層級上進行虛擬化服務品質的調整是不可能的，但I/O卻對此事一無所知，因此其與成為最佳導入方案還有一大段距離。

即使它們無法察覺虛擬化元件層，但虛擬化仍為DAS磁碟陣列控制器提供類似儲存區域網路的優點。最明顯的證據就是儲存匯整功能，因為這向來都是SAN型磁碟陣列最重要的特色之一。在效能與可靠度的考量之下，使用者通常須為非虛擬化伺服器提供超額的儲存資源，而這導致了資源使用率過低與部署成本昂貴的問題。虛擬化伺服器僅需如同SAN所需的資源數量，並可視情況匯整儲存空間，以及建立LUN（Logic Unit Number）給每個GOS（或虛擬機器監視器自己的檔案系統），並以所有常見的SAN技術來支援。

最後要提的就是I/O，特別是DAS儲存系統，有侷限於本地端平台的特色，這是說使用者可以將儲存資源抽離至某一伺服器上所運行的GOS，但不影響另一部伺服器上的GOS。因為伺服器間並無有效的溝通管道，因此可以避免若某一台伺服器故障，所有本地端儲存檔案跟著毀損，導致沒有任何伺服器可供使用的窘境。因此，目前的VM行動建置方案，都要求將儲存系統連結至SAN。

但上述缺點都只是在伺服器虛擬化第一階段，完全聚焦於CPU與記憶體管理下所造成的結果，因為在此階段虛擬機器監視器必須在沒有任何硬體的協助下，獨力解決抽離儲存空間的問題。隨著虛擬化日趨普遍，I/O的虛擬化也越來越重要。各種新技術推陳出新，不僅將排除虛擬化系統I/O面臨的各種限制，還能維持所有的優點。這方面前景最看好的技術，就是Single-Root IO 虛擬化（SrIOV）與Multi-Root IO 虛擬化（MrIOV）。

虛擬機器與IO的關聯

從CPU與記憶體方面開始，探究伺服器虛擬化需要解決的各項問題，包括其中受影響較大的地方，應該是一個合理的切入角度。但目前的情況是，當新型虛擬化CPU/記憶體基礎架構所構成的運算元件，正要開始如預期般發揮效益之際，I/O的發展腳步卻落在後頭，因此將成為未來發展的焦點。儲存子系統在上述限制下所受的影響尤其深遠，且因其在主系統中的地位特殊，因此將成為本文另一個探討重點。

目前伺服器虛擬化架構中，所有問題的根本來源，就是IO本身完全沒有被虛擬化─最多僅是透過虛擬機器監視器，提供一個簡單但缺乏效率的IO虛擬化模擬環境。

更明確的說，一方面虛擬機器監視器會「欺騙」每個虛擬機器，讓它以為自己完全擁有每個IO資源，但實際上這些資源卻是和其他虛擬機器分享；另一方面則是「欺騙」IO控制器，讓這些控制器以為只從一個虛擬機器接收指令，但實際上指令是從系統中所有的虛擬機器發出。這種解決方案的價值在於簡單且不需要對IO子系統進行任何異動，但代價是缺乏效率以及上述的種種限制。

為解決這些問題，最近業界提出一個IO虛擬化（IOV）模型，並將其加入PCI Express標準中。這個模型主要有兩種衍生版本，分別稱為單根IO虛擬化（SrIOV）與多根IO虛擬化（MrIOV）。蘊含其中的觀念相當簡單：與其讓虛擬機器監視器作為虛擬機器與IO控制器的中介，不如讓IOV直接建立一個環境，讓每個虛擬機器可直接存取IO控制器，不需要虛擬機器監視器的介入。此外，IO控制器能提供一個與虛擬機器溝通的獨特管道，以維持每個IO執行緒不受干擾。

SrIOV將該控制器協定完全收錄在單一伺服器（稱為一個「PCIe根」）平台上，而MrIOV則將該解決方案延伸，想像儲存控制器被移出伺服器，並同時為多部伺服器平台提供服務。對於刀鋒型與磚塊型電腦來說，這是一種有趣的解決方案，但它更適合支援未來各種新應用。

雖然這種建置方案看似簡單且直接，但實際上卻十分複雜，尤其是針對儲存控制器而言。同時，它也替儲存子系統與相關服務，創造一種全新類型的機會（以及各種挑戰）。

同樣地，我們就虛擬機器監視器所能解決的問題，分三方面討論：

效能：

虛擬機器監視器可以完全被繞過，以建立一條無論在延遲或CPU使用率方面的效能，都足以媲美處於最佳情況下非虛擬化伺服器的線路。

安全性：

每個虛擬機器都擁有自己的IO執行緒，這些執行緒在進入儲存控制器之前，都不會進行合併或共用資源。因此，在這邊不會有資料污染、毀損、或安全入侵的危機－或至少優於共用儲存控制器的非虛擬化獨立伺服器。

服務品質：

儲存控制器現在能感應到每個虛擬機器，並能針對每個虛擬機器甚至是每個IO套用服務品質策略，建構一個可支援每個層級服務品質的環境。

儲存控制器的特性與限制

但是，事情總是不像一開始所想的那麼簡單，尤其是對於共用資源的儲存控制器而言。為說明這種情況，我們來看另外一個常見的IO子系統：區域網路控制器。區域網路會藉由TCP/IP或是類似的通訊協定，來為每個本地端虛擬機器與遠端系統之間各建立一條連線。這種方法最大的好處是，所有執行緒都是獨立且分開的，不會共用任何通用目標元件（也就是說，他們共用一個傳輸管道，將不同的虛擬機器連結到不同的目標上）。在這個環境下，IOV的用途變的相當單純，並且因為目前已有數個區域網路控制器的支援，虛擬化伺服器可以發揮完全的效益。

儲存控制器的情況則不相同，因為「目標」裝置通常並不完全屬於所連結的虛擬伺服器。例如，一個RAID控制器可把兩個虛擬磁碟配置給兩部虛擬機器，而這些虛擬機器可將自己設定為唯一的擁有者，但事實上，這些虛擬磁碟是來自同一個實體磁碟的RAID抽象單元。

這造成了一個管理上的問題以及需求，因為以往受限於SAN的技術現在被導入伺服器域中，逐漸使子系統的組態變得更像外部RAID控制器，而非傳統上應有的DAS。

若從更高的抽象層面來看，SrIOV為伺服器（若為刀鋒伺服器，則需MrIOV）建立一個「內部SAN」，讓使用者可充分利用伺服器儲存的小型化（與低成本！），及SAN控制器的可調整性與彈性。但如此一來，所需付出的代價是IO子系統新架構的投資，而上述過程一般被稱為「進化」。

這些革命性的解決方案總是會挑戰現有的其他相關技術，但同時也為其創造了進一步創新的機會。例如，虛擬機器監視器不僅為IO提供“漏斗”功能，還提供一個本地端檔案系統（像是Vmware VMFS），可用來建立各種服務如快照、資源隨需分配等。SrIOV則允許系統繞過虛擬機器監視器，可以有效避免上述資料被操作的問題。這類問題有許多解決方法，但目前看來可能性最高的是轉移儲存控制器內的這類服務，造成越來越多像是「伺服器內SAN」的情況，例如類SAN組態、類SAN連結，以及各種類似SAN的服務，包括快照與資源隨需分配。

展望未來，我們必須著眼於多重伺服器虛擬化的關鍵，也就是虛擬機器的機動性。虛擬機器機動性要求SAN必須保證能為每部伺服器提供充裕的儲存資源，而MrIOV則為DAS儲存提供相同的功能與虛擬機器機動性。

結論

在上述文章中，我們詳細闡述為何需要伺服器虛擬化、儲存控制器的衝擊、以及虛擬化IO控制器如何支援新類型的解決方案。最後我們提到當這波轉移趨勢完成後，DAS儲存控制器將扮演類似SAN儲存控制器的角色。兩者唯一的差別是，DAS採用PCIe來傳輸，而SAN則採用全部類型的儲存協定（光纖通道、GbE、SAS、IB、FCoE等）。但未來情況會更加複雜，更多儲存控制器將透過虛擬化技術來提供許多服務，而伺服器將嵌入更多的儲存裝置。

未來數年內，我們的焦點很可能不會全部放在DAS伺服器儲存以及SAN平台，而是轉移到通用運算平台上，因為它可以自由被調整為通用伺服器或儲存伺服器。伺服器虛擬化技術，包括IOV技術在內，將成為推動這波匯整趨勢的基礎。

-- 作者為LSI企業策略總監--