VMware虛擬儲存二部曲：VVOL

剛發表的Virtual SAN，讓VMware實現了「VM導向」虛擬化儲存的第一步，可依照個別VM的需求，設定不同的儲存效能與可用性，儲存服務等級可精細到以個別VM為單位，靈活的滿足各式各樣的VM需求，而且整個操作設定都是透過vCenter的政策統一驅動，管理介面單純，也不涉及複雜的LUN、Volume與映射等設定。

不過Virtual SAN在硬體架構上存在著很大局限，要求直接存取與控制磁碟機，在磁碟機與Hypervisor核心之間不能存在由I/O控制器建構的RAID層，這也意味著，Virtual SAN基本上僅能使用Hypervisor主機的本機內接磁碟機，來作為儲存空間，這雖然也是一種可行的選擇，透過叢集擴充，這種架構也能提供不錯的容量擴展能力，但顯然不能涵蓋所有的VMware應用環境，許多用戶依舊希望在VMware中使用第三方的外接儲存設備。

於是接下來的重點，便在於將Virtual SAN這種「VM導向」、政策趨動的虛擬化儲存架構，推廣到外接儲存，甚至是雲端儲存上。

VM儲存與底層儲存的隔閡問題

過去在使用外接儲存設備、或內接RAID來提供VMware儲存應用時，一個老問題就是VM的儲存，與底層的儲存區設定是彼此分離、相互不對應的。

在VM這個層級，是以VMDK格式的虛擬磁碟作為儲存容器，在Hypervisor上操作的儲存對象也是VMDK檔案，無論Clone、快照（snapshot）還是備份都是以VMDK為目標。

而在儲存系統這個層級，提供的儲存容器則是LUN或Volume，所有儲存功能包括I/O效能等級設定、或Clone、快照與遠端複製等進階資料服務功能，也都是以LUN或Volume為對象來操作。

所以在VMware環境中最普遍使用的VMFS datastore，是以間接的方式來使用底層儲存設備的空間，先將磁碟設備的LUN格式化為VMFS datastore後，掛載給指定的ESX主機使用，然後ESX主機再於VMFS datastore上，建立VM的VMDK磁碟。

在這樣的架構下，底層儲存設備的LUN/Volume與VM的VMDK是彼此不對應的，設定與操作的粒度也不同，以致底層儲存所建立的LUN或Volume，無法依照上層個別VM的需要進行精細的設定與調整。所以這樣的儲存架構是「非VM導向」的，管理者必須使用多個管理工具才能完成設定，而且儲存架構的設定也是粗略、不靈活的。

用戶雖然可使用RDM這種可讓VM直接連接底層儲存設備LUN的模式，讓VM與底層LUN直接對應，但問題是RDM模式會增加儲存架構複雜性，也無法運行許多VMware的進階功能。

為解決這個問題，VMware在2012年時提出了稱為Virtual Volume的架構。

透過VVOL融合VM與外接儲存

Virtual Volume（VVOL）目前仍在開發階段，目的是透過一個可與外部儲存設備協調的API介面，讓VMware管理者能針對個別VM的需要，在外部儲存設備上建立需要的儲存空間。

在VVOL架構下，多臺不同廠牌、等級的外接儲存設備可構成一個儲存容器（Storage Container，SC）統一管理，其中每一個儲存設備都透過一個協定端點（Portocol Endpoint，PE）來處理與VM的儲存路徑映射。而每臺儲存設備則透過個別廠商提供的Vendor Provider嵌入套件，來與vCenter溝通。

我們可把VVOL理解為VM與儲存設備之間的中介虛擬儲存容器，VM的VMDK等儲存元件，對應到儲存設備上成為VVOL。

當管理者建立一個VM時，先選擇要在哪一個儲存容器（SC）建立儲存空間，然後vCenter會將管理者為個別VM設定的儲存效能與可用性政策，透過Vendor Provider元件發給底層儲存設備，而儲存設備將會依照Vendor Provider元件所收到的vCenter政策要求，建立符合需要的VVOL。

以政策驅動、為VM量身訂作需要的儲存空間

透過VVOL這樣的中介虛擬儲存機制，管理者就能從個別VM的需求出發，利用vCenter設定政策，然後在底層儲存設備上建立符合需求的儲存區。而儲存設備廠商則能在自身儲存設備的實體LUN，以及VM的VMDK之間，利用VVOL建立虛擬的對應。

藉由這種方式，Hypervisor主機不再只是被動的接受後端儲存設備建立的LUN，管理者可反過來，依照個別VM的需求，透過vCenter的政策向後端儲存設備「量身訂做」需要VVOL，從而在外部儲存設備上，建立由vCenter政策統一驅動、粒度更精細、管理更靈活的「VM導向」儲存、或者也可稱為「VM感知（VM-Aware）」儲存。

宣稱要支援VVOL的廠商包括了Dell、HP、NetApp、EMC、IBM、NEC等老牌大廠，以及Nimble Storage、SolidFire、Pure Storage與Nutanix等新創廠商，而支援VVOL的儲存設備則可稱為VVOL Ready儲存設備。

VMware主導虛擬儲存架構發展的願景

從VSAN與Virtual Volume等技術的發展，可明顯看出VMware積極主導虛擬平臺儲存架構發展的企圖心，企圖將原先由儲存廠商主導的儲存架構發展，扭轉成為以VM為核心的「VM導向」儲存架構。

這也就是說，VMware平臺不再是像以往般，只是被動地接受後端儲存設備提供的儲存空間，而是要反過來，轉為以VM的需求為核心，要求後端的儲存設備提供專為VM「量身打造」的儲存空間。

目前剛推出的VSAN是實現這個構想的第一步，開發中的Virtual Volume則能讓這個構想更趨完整，可實現從Hypervisor本機儲存到外接儲存設備，涵蓋完整、由vCenter政策驅動的「VM導向」儲存，屆時VMware使用者可無須顧慮後端使用的儲存設備廠牌、型號，只要透過VMware的VSAN或Virtual Volume，就能針對VM需求建構出符合要求的儲存環境，靈活性與便利性都有顯著提高。

不過當虛擬平臺的儲存架構發展到這個階段時，也將開始發生變質。

原本VMware在儲存設備方面，只要求使用標準的FC/iSCSI SAN或NFS協定儲存設備，沒有額外的特殊需求。

然而當VMware開始強勢主導虛擬平臺儲存架構發展、並提出專屬的新架構後，雖然一方面可透過儲存虛擬化與軟體定義儲存方式，讓用戶擺脫特定儲存硬體的制肘，但另一方面，由於VMware主導了虛擬平臺的儲存架構，未來任何應用在VMware環境的儲存設備，都需遵循VMware的專屬架構與API，才能配合VMware的「VM導向」儲存，不像現在只需遵循通用的SAN或NFS協定即可。

這也意味著，隨著伺服器虛擬化應用的普及，以及VMware在伺服器虛擬化領域中的領導地位，當VMware提出了自身的專屬儲存架構後，將迫使儲存廠商除了支援標準的通用架構外，還需特別支援VMware的專屬架構，才能在VMware環境中提供完整功能。此後VMware用戶的儲存環境建置，雖不再受制於個別儲存硬體廠商，但也從此落入了VMware的掌控。

而從VMware環境的儲存應用發展前景來看，隨著VMware主導推出越來越多新架構，同時也有越來越多儲存與資料保護功能被挪到Hypervisor端運行，第三方儲存廠商也有逐步失去自身特性、甚至邊緣化之虞。

相關報導請見：「VSAN翻轉SAN儲存」