剛發表的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儲存」


Advertisement

更多 iThome相關內容