鬆綁VMware vSAN的超融合架構：透過HCI Mesh分解vSAN與vSphere的運算與儲存資源

風行將近10年之後，超融合基礎架構（Hyper-converged infrastructure，HCI）開始出現轉變。

作為超融合領域奠基者之一的VMware vSAN，近2、3年來引進了一系列堪稱「解構」超融合應用概念的重要轉變，一反超融合應用最基本的「結合運算與儲存資源」概念，允許將運算與儲存單元分離運用。

運算與儲存合一的超融合架構

超融合架構的目的，是將提供運算資源管理能力的Hypervisor虛擬化平臺，與提供儲存空間管理的儲存叢集平臺，結合在一臺x86伺服器主機上，成為預先完成組裝、測試與調校的超融合機箱套件。

因而超融合架構的每臺機箱，就是一個含有運算與儲存資源的基礎「積木（Build Block）」單元，再透過Hypervisor與儲存平臺的叢集功能，可像堆疊積木般，將多臺超融合機箱組成適合不同應用情境的叢集。只要將更多節點加入叢集中，就能擴展整個叢集的效能、容量與可用性。

憑藉部署與擴展的便利性與靈活性，超融合架構經過10年發展，成為當前資料中心建置的主流形式之一。

而vSAN與vSphere的組合，便是典型的超融合架構，vSAN是基於vSphere叢集環境所建構的分散式儲存服務，可橫跨多臺vSphere主機，將這些主機的儲存空間組成兼具高擴展性、高可用性與高效能的叢集式儲存空間，也就是vSAN datastore。

由於vSAN是內嵌vSphere核心的一項功能，因而兩者的部署也是合而為一的，先透過vCenter建立一個vSphere叢集，然後便可為叢集啟用vSAN服務，再選擇將vSphere叢集中的個別節點加入vSAN叢集，接著vSAN便能跨這些節點，將這些節點的磁碟空間構成vSAN datastore。

這也意味著，啟用vSAN後，每一臺vSphere叢集節點，也同時是vSAN儲存叢集的節點，同時具備vSphere的運算資源，以及vSAN的儲存資源，只要增加節點，就能同時擴展運算與儲存資源。

超融合架構的2大局限

超融合系統「運算+儲存合一」的基本特性，最大優勢在於部署與擴展的簡便，但連帶也帶來兩大副作用：

首先，是運算與儲存負載間的互相干擾，上層的Hypervisor平臺，與底層的叢集儲存平臺，都使用相同的叢集節點硬體，導致運算與儲存兩種工作負載，將會互相影響對方的資源使用。

其次，資源擴充會受到「對稱式」架構的限制。在超融合架構下，每增加一個節點，運算與儲存資源便會同時增加，但戶實際環境的擴充需求，往往是「不對稱」的，有時只需要儲存空間，有時只需要運算資源。然而受限於超融合架構，無論用戶需求為何，擴充時都被迫以一整臺同時含有運算與儲存資源節點為單位，不能精確對應需求。

超融合架構的拆解

要克服超融合架構因「運算+儲存合一」組態所帶來的限制，解決辦法便是拆解「運算+儲存合一」的應用型態。這便是幾年前部分廠商推動的「非聚合式超融合」（Disaggregated HCI，dHCI）概念，將運算節點與儲存節點彼此分離，從而獲得更靈活的擴展能力。

先前便有一些超融合平臺允許不對稱的運算與儲存節點部署，例如Cisco HyperFlex。後來又有一些廠商推出完全分離運算與儲存節點的「非聚合式」產品，例如Datrium的DVX、NetApp HCI、HPE dHCI等。

vSAN的「非聚合化」演進

然而，對於vSAN這個市場上最重要的超融合平臺來說，要實現運算與儲存資源的解構，卻比其他超融合平臺更為困難，原因在於vSAN的架構，要比其他超融合平臺更加地「超融合」。

除了vSAN以外的其餘超融合平臺，都是將獨立的儲存叢集軟體平臺，以VM形式部署到Hypervisor環境中，藉此組成超融合架構，由於儲存叢集平臺與Hypervisor平臺本來就是兩套不同的獨立元件，只是部署在同一臺伺服器主機上而已，理論上也能相對容易地拆解兩者、各自獨立部署。

而vSAN則是內嵌vSphere核心的元件，是vSphere核心的一部分，因而也難以從vSphere分離出來。原本與vSphere之間深度、緊密的結合，是vSAN相較於其他超融合儲存平臺的最大優勢與賣點，卻也成為vSAN應用上的一大限制，無法脫離vSphere獨立存在，也導致vSAN儲存資源被綁死在vSphere叢集內。

面對這個問題，一個變通解決方式，是利用分別於vSAN 6.5與vSAN 7.0引進的iSCSI與NFS支援功能，將vSAN的儲存空間透過iSCSI與NFS協定匯出，再掛載到其他vSphere叢集的主機使用，藉此提供一定程度的跨叢集資源運用，與非對稱式擴充能力。但這種方式存在一系列局限，例如無法套用橫跨各個環節、End-to-End的儲存管理政策，消耗的硬體資源較大，也無法以此細部監控每個部位的I/O運作，以及必須另外管理iSCSI與NFS空間等。

直到vSAN 7 Update 1（以下簡稱U1），引進的HCI Mesh功能，VMware才實現了基於原生vSAN協定的跨叢集共享能力。

利用HCI Mesh功能，可以讓本地端vSAN叢集掛載遠端其他vSAN叢集的datastore，橫跨不同vSAN叢集，掛載與分享vSAN datastore儲存空間。

提供vSAN跨叢集共享的HCI Mesh

利用HCI Mesh功能，用戶可以建立只有運算功能的vSAN Server叢集，然後將外部vSAN叢集的datastore掛載成為本身的儲存空間，這些提供儲存空間的外部vSAN叢集，則被稱為vSAN Client叢集。

也就是說，HCI Mesh能將多個vSAN叢集匯集成一個跨叢集的儲存池，然後將某些vSAN叢集閒置的datastore空間，掛載給需要datastore空間的vSAN叢集使用，藉此實現跨叢集的資源調配，同時也實現某種程度的運算與儲存資源分離，以及非對稱的資源擴展。

首先，HCI Mesh下的vSAN Server叢集，雖然啟用了vSAN，但沒有任何儲存功能，完全由遠端vSAN來提供儲存空間，這就形同於分離了運算與儲存節點；其次，當某個vSAN叢集的儲存空間不足時，可以利用HCI Mesh掛載其他vSAN叢集的空間來使用，而不需要為叢集增加整臺vSAN節點，等同於非對稱的擴充。

HCI Mesh功能的擴展

HCI Mesh可以串聯最多16個vSAN叢集與64臺主機，而每個vSAN叢集則能掛載最多5個遠端datastore。不過，在vSAN 7 U1的HCI Mesh仍存在一些限制，例如不適用於非vSAN的傳統vSphere叢集，也不適用於跨遠端的拉伸式叢集（Stretched Clusters）環境。

而到了vSAN 7 U2，允許傳統vSphere叢集也能透過HCI Mesh功能，掛載遠端vSAN叢集的datastore來使用。利用這個功能，用戶可以建立純運算型式的vSphere叢集，然後完全由遠端的vSAN儲存叢集來提供空間，同樣可以實現vSphere叢集與vSAN叢集的完全分離。更妙的是，其中的純運算vSphere叢集，不需要購買vSAN授權，就能利用HCI Mesh掛載使用遠端的vSAN儲存空間。

而到了vSAN 8 U1，又藉由新引進的「解構式儲存」、也可稱作「非聚合式儲存」（Disaggregated Storage）功能，將HCI Mesh功能的適用範圍，進一步擴展到vSAN 8全新的ESA儲存架構（Express Storage Architecture），以及遠端的拉伸式叢集環境中。

在ESA架構下，用戶可以在一般的非拉伸式叢集環境中使用解構式儲存架構（也就是HCI Mesh），在不同vSAN叢集間掛載遠端vSAN datastore空間，或是將ESA叢集當成其他vSphere叢集的外部儲存空間。

而解構式儲存架構對於拉伸式叢集的支援，則需搭配vSAN 8的OSA原有儲存架構（Original Storage Architecture）來運作，在OSA架構下也能支援跨不同vCenter環境的儲存資源共享。

未竟全功的架構轉型

從2020年10月跟著vSAN 7 U1推出的HCI Mesh功能起，到2023年4月vSAN 8 U1引進的解構式儲存架構，VMware算是以軟體的方式，完成了vSphere與vSAN超融合架構的解構，同時將這種應用型態推廣到OSA與ESA架構中，相當程度解開了過往vSAN與vSphere彼此綑綁的限制。

但另一方面，HCI Mesh實際上仍未徹底分離vSphere與vSAN，vSAN依舊不能脫離vSphere而獨立存在，透過HCI Mesh只是提供了關閉vSAN儲存功能的叢集選項，只是以軟體功能讓用戶建立沒有vSAN儲存能力的叢集，然後搭配遠端vSAN叢集來運作。因而HCI Mesh對超融合的「解構」，只是軟體功能層次上分離運算與儲存功能而已，而不像Datrium的DVX、NetApp HCI與HPE dHCI等產品，是在部署方面徹底分解了運算與儲存單元。

利用vSAN HCI Mesh分離運算與儲存資源

透過vSAN HCI Mesh功能，企業可建立只有運算功能的叢集，然後掛載遠端vSAN叢集的datastore作為儲存空間，藉此分離運算與儲存節點，避免兩者互相干擾，同時提高擴展彈性。

圖片來源：VMware

HCI Mesh的部署與啟用

目前HCI Mesh只適用於vSAN 7 U1以後的Enterprise與Enterprise Plus版，當用戶建立vSAN叢集時，只需選擇vSAN HCI Mesh項目即可啟用。

圖片來源：VMware