VMware拆解超融合架構的最後一哩路：vSAN Max徹底解放VMware儲存應用架構

作為超融合基礎架構（HCI）奠基者之一的VMware vSAN，近2、3年來試圖擺脫超融合架構的束縛，透過推出一系列新功能，逐步拆解超融合應用最基本的「結合運算與儲存資源」概念，允許運算與儲存單元分離部署，進而提供更靈活的基礎資源建置與擴充方式。

VMware最初是利用在vSAN 7 Update 1引進、然後與vSAN 8 Update 1擴展的HCI Mesh功能，允許用戶建立只有運算功能的vSAN運算叢集（Compute Cluster）。接著透過今年8月發表、預定於明年正式推出的新產品vSAN Max，又提供了純儲存叢集（Storage Only Cluster）服務，終於實現了運算服務與儲存服務的徹底分離，構成完整的「非聚合」（Disaggregated）應用架構。

走向「非聚合式」架構的超融合領域

超融合領域正全面朝向「去融合」化發展，兩大領導平臺：VMware的vSAN與Nutanix的AOS，都在這2、3年內，藉由引進一系列新功能，提供了將運算與儲存單元分離的「非聚合」部署能力。由於這兩大平臺在超融合領域的壟斷地位——合計擁有2/3以上市占，因而兩大平臺共同朝向非聚合式架構的轉變，也代表這是超融合領域的大勢所趨。

而超融合產品轉向支援非聚合式架構的目的，是要克服超融合「運算與儲存合一」的架構，所衍生的種種問題。

原本「運算與儲存資源結合於單一機箱節點」，是超融合架構賴以成功的最大賣點，極有助於採購、部署與管理的簡便。但歷經十多年發展後，「運算與儲存合一」的特性，現在卻成為超融合產品進一步擴大應用的阻礙，儘管便於部署與管理，但運算與儲存負載結合在同一節點上，也帶來運算與儲存負載相互干擾、資源擴充缺乏靈活性等問題，難以適應複雜環境的需求。

至於克服這個問題的辦法，便是允許超融合架構的運算與儲存單元分離部署，構成「非聚合」超融合架構，以便更靈活、更精確地對應用戶環境的需求。

基於這樣的思路，促使VMware與Nutanix這2大超融合產品龍頭，這幾年紛紛走上「去融合」化的道路。

兩大超融合龍頭廠商的「非聚合」化發展

事實上，在「去融合」化的腳步上，Nutanix要比VMware快了一步。早在2015年中時，就在原有的超融合產品之外，推出了NX-6035C「純儲存節點」（Storage Only Node），只用於提供儲存空間，而不加入Hypervisor運算叢集。

接著在2019年初，Nutanix又推出「純運算節點」（Compute Only Node），只用於運行自身的AHV虛擬化平臺，而不加入儲存叢集，再加上先前的純儲存節點，Nutanix至此算是基本實現了運算與儲存單元的分離。

而在VMware方面，則是在2020年9月發布的vSAN 7 Update 1，才初步提供了運算與儲存單元的分離部署能力，透過引進HCI Mesh這項新功能，允許用戶建立只有運算功能的vSAN運算叢集，然後藉由掛載外部vSAN叢集的datastore來做為自身儲存空間。

到了2021年3月發布的vSAN 7 Update 2，則允許傳統vSphere叢集也能透過HCI Mesh功能，掛載遠端vSAN叢集的datastore來使用。

接著在2023年3月推出的vSAN 8 Update 1，又藉由新引進的「非聚合式儲存」（Disaggregated Storage）功能，將HCI Mesh功能的適用範圍，進一步擴展到vSAN 8全新的ESA儲存架構（Express Storage Architecture），以及跨遠端的拉伸式叢集（Stretched Clusters）環境中。到了這個階段，VMware主要的vSphere與vSAN版本，都能透過HCI Mesh功能，獲得掛載遠端vSAN datastore能力。

但比起Nutanix，VMware這時候的「非聚合」程度仍差了一個層次。Nutanix已能提供「純儲存節點」與「純運算節點」，徹底分離運算與儲存資源的部署。而VMware則只完成了「半套」，只提供「運算叢集」，而沒有提供專門的「純儲存叢集」。

直到不久前發布的vSAN Max，VMware才終於補上原本缺少的「純儲存叢集」服務。

在有了vSAN Max之後，HCI Mesh功能也繼續保留，但VMware已不再使用HCI Mesh這個名稱，更名為「使用vSAN HCI叢集的跨叢集容量共享」（cross-cluster capacity sharing using vSAN HCI clusters）。

提供純儲存服務的vSAN Max

VMware先前提供的HCI Mesh功能，是建立關閉vSAN儲存服務的純運算用叢集，只提供VM相關服務，而沒有vSAN儲存空間服務。

新發表的vSAN Max則與之相反，是以vSAN 8的ESA儲存架構為基礎，所打造的純儲存用叢集，只提供儲存空間服務，而沒有VM相關服務，可看做vSAN 8 ESA架構的「純儲存化」衍生版本。

vSAN Max是vSAN家族中新的獨立成員，雖然底層是基於vSAN 8的ESA架構，但採用獨立的授權，只需vSAN Max本身的授權即可啟用，而不需要vSphere或標準vSAN的授權。

vSAN Max主要的應用目的，是提供具備PB等級擴展能力的儲存叢集服務，可作為傳統vSphere叢集的主儲存空間，或是為vSAN HCI叢集提供額外的儲存空間。

VMware目前提出幾種適用於vSAN Max的應用場合，包括：

●幫助降低基礎設施成本。透過vSAN Max，可以讓儲存服務與運算服務彼此分離部署，然後視需求建立vSAN Max儲存叢集，因而運算叢集不再需要考慮儲存服務的需求，從而減少運算叢集的資源消耗與授權費用。

●提供管理簡便的通用共享儲存服務。vSAN Max可以作為VMware環境的集中式共享儲存設備，不僅擴充容易，也能與VMware環境的其他服務共同由vCenter整合管理。

●為雲端原生應用服務，提供可以迅速、方便與漸進擴展的儲存空間服務。

vSAN Max的基本架構

vSAN Max是以vSAN 8 ESA架構為基礎，所建構而成的「純儲存用叢集」（Storage-Only Cluster），可將空間掛載給vSAN HCI或傳統vSphere從即使用，藉此提供兼具高效能與高擴展性，且與運算叢集完全獨立的「非聚合式」儲存空間服務。

圖片來源：VMware

vSAN Max的授權方式

vSAN Max採用與既有vSAN分離的獨立授權，無須與其他產品的授權搭配。

在授權計費上，vSAN Max是以TB容量為單位，而容量計算則是以原生容量（raw storage）為基準，例如500TB原生容量的vSAN Max叢集，需要購買500TB的授權。

但授權容量不等同於真正的使用容量。在實際應用中，不同等級的高可用性設定，與資料縮減技術的使用，會影響資料真正使用容量。例如採用較高的失效容許數量（Failure to Tolerate，FTT）設定，會讓資料實際占用比原生容量高出許多的容量，而啟用壓縮、重複資料刪除等容量縮減技術，則會減少資料實際使用容量。

vSAN Max的部署

vSAN Max的部署，需要經過專門針對vSAN Max認證的vSAN ReadyNode主機，而不能使用既有的vSAN ReadyNode主機，且不支援從其他類型vSAN授權，轉為vSAN Max的就地升級與轉換。

這也就是說，用戶必須額外購買vSAN Max授權，並重新建置vSAN Max的節點，而無法透過既有的vSAN授權或vSAN節點，直接升級轉換為vSAN Max。

目前VMware設定了4種等級的vSAN Max節點規格，分別是：vSAN-Max-XS、vSAN-Max-XM、vSAN-Max-Med、vSAN-Max-Lrg，提供的容量與效能依序增加。

vSAN Max的個別節點與叢集部署需求，都要比標準的vSAN高出不少。

在個別節點方面，每臺節點要求配置最少8臺SSD，並視節點等級配置256GB到1TB記憶體，以及2組25GbE或100GbE的網路埠。相較下，同樣基於ESA架構的vSAN 8節點，最低只需要4臺SSD， 512GB記憶體，以及25GbE網路。

在叢集方面，vSAN Max最低部署規模是7臺主機節點，相對的，vSAN標準的最小規模是3節點，也能在特定要求下，支援2節點組態。

而在部署站點（site）的形式方面，vSAN Max則和vSAN一樣，都可支援單站點部署組態，也支援跨2個站點的拉伸式（Stretched）叢集部署方式，以提供跨站點的備援能力。

4種等級的vSAN Max節點規格

VMware目前設定4種等級的vSAN Max節點硬體規格，每節點的容量從75TB起跳，最高可達300TB，但處理器核心數、記憶體與網路規格要求也隨之提高，其中值得注意的是，較高的2種等級都要求配置100GbE網路。

圖片來源：VMware

vSAN Max的應用環境需求

vSAN Max是專門提供vSphere與vSAN環境使用的儲存服務，可支援下列這幾種類型的Client端叢集，包括：傳統的vSphere叢集，vSAN HCI叢集，以及跨遠端的拉伸式（Stretched）2站點叢集，或2節點叢集。

對於Client端叢集來說，並不需要任何vSAN授權，也不需要特別的硬體組態（只需一般VMware相容硬體組態即可），就能存取vSAN Max提供的datastore儲存空間。

不過，要特別注意的是，掛載使用vSAN Max datastore儲存空間的vSphere叢集，必須是vSphere 8以後的版本。

至於vSAN Max與Client端之間的存取，是透過vSAN原生協定來進行，基本上等同於以往掛載遠端vSAN datastore的方式。

對於沒有vSAN的傳統vSphere叢集，在設定連結vSAN Max時，則會在vSphere主機上安裝vSAN Thin Layer元件，然後由這個元件透過vSAN原生協定來存取vSAN Max的datastore空間。

VMware認為，透過vSAN原生協定來連結vSAN Max與Client端叢集，既能在Client端保留使用vSAN原有的儲存政策設定與管理介面，且避免了經由iSCSI或NFS等協定掛載遠端空間時，所帶來的複雜堆疊轉換。

vSAN Max的部署與應用

vSAN Max本身可以支援單節點部署，以及跨2站點的拉伸式叢集部署（如上圖下方所示）。

而vSAN Max的datastore儲存空間，則可掛載給這3種叢集使用，包括標準的vSAN叢集、vSAN純運算叢集或傳統vSphere叢集，以及拉伸式的vSAN叢集（如上圖上方所示）。

圖片來源：VMware

vSAN Max的擴展與連接限制

如同標準的vSAN HCI叢集，vSAN Max叢集亦可逐步擴展，以提供更多的容量與效能，包括縱向擴展（Scale-Up），以及橫向擴展（Scale-Out）等2種方式，前者是為個別vSAN Max節點主機增加更多儲存裝置（更多或更大容量的SSD），後者則是為vSAN Max叢集增加更多節點主機。

對於縱向擴展來說，必須考慮到每臺節點主機實際可用的datastore容量，會受到vSAN Max的高可用性設定所影響。目前vSAN Max預設要求採用失效容許數量（FTT）為2與 RAID-6的高可用性設定，所以資料會佔用比原生容量多出1.5倍的空間，在為節點主機擴充容量時，必須考慮到這方面造成的折損。

而在橫向擴展方面，考慮到可用性與系統重建能力的要求，目前的vSAN Max初始版本，建議的最小部署規模是7節點，允許的最大叢集規模是32個節點，不過VMware官方建議使用的最大叢集規模是24節點。

理論上，只需6臺節點主機便可滿足vSAN Max預設的FTT=2與RAID-6組態，不過此時如果發生個別整臺主機的持續故障，雖然資料不致損失，但剩餘的主機數量，將不足以讓叢集以vSAN Max要求的可用性等級恢復運作（只剩5臺主機，將不能維持FTT=2與RAID-6的可用性組態要求）。而在7節點組態下，則能避免這個問題，即便任一節點主機持續失效，vSAN Max也能自動讓叢集恢復運作。

除此之外，若用戶在叢集容量管理設定中，啟用「預留重建主機」功能（Host Rebuild Reserve，HRR），7臺節點主機也是RAID-6這個保護層級所需的最小叢集規模。

如果讓vSAN Max採用跨2站點的拉伸式叢集部署，那麼每個站點都需要最少7臺節點主機，所以，整個拉伸式叢集的最小需求合計是14節點。

而在Client端主機與vSAN Max之間的連接方面，每個vSAN Max叢集可以將自身的datastore儲存空間，同時掛載給最多10個用戶端叢集。而每個Client端叢集，則能同時掛載最多5個遠端的vSAN datastore，包括vSAN Max的datastore，這些連接規模限制都與HCI Mesh相同。

而包括Client端叢集與vSAN Max叢集在內，整個應用環境所有互連的節點主機數量，則不能超過128個，這個應用規模限制也與HCI Mesh相同。

在128節點的限制下，若vSAN Max叢集規模為24節點，那麼前端Client端運算節點最大數量便是104個節點。而在vSAN Max的32節點最大叢集規模下，Client端允許的運算節點數量是最多96節點，此時仍保有3比1的運算與儲存節點比例，VMware官方認為這算是相當理想的比例。

存在較高建置門檻，影響vSAN Max吸引力

某種程度上來看，vSAN Max的推出，算是VMware在儲存架構發展上的「返祖」或「回歸傳統」。vSphere平臺原本就能提供非聚合式的儲存架構，可由外部獨立的SAN或NAS儲存設備，來為ESXi主機提供datastore儲存空間，一直到了2014年推出vSAN後，VMware才開始提供聚合了運算與儲存資源的超融合式架構。

但即便同樣是非聚合式儲存架構，比起傳統的外部儲存設備，VMware認為vSAN Max具備3項優勢：

首先，採用分散式架構，具備容量與效能擴展的優勢。

其次，儲存系統與政策管理，與vSphere環境完全整合。

第三，是基於通用伺服器硬體的純軟體定義架構，沒有專屬硬體負擔。

但以我們來看，當前採用分散式架構的第3方軟體定義儲存產品，已經不在少數，vSAN Max架構上已不具備優勢，只有與vSphere平臺完全整合的管理這項優勢。

除了對於第3方儲存產品的優勢有限，vSAN Max較高的部署門檻，以及較窄的應用範圍，也會影響這款產品的吸引力。

如同前面提到的，vSAN Max儘管是以vSAN 8 ESA打造而成，但VMware將其定位為新產品，不像先前的HCI Mesh是內含於vSAN的功能（如vSAN 8的Enterprise與Enterprise Plus版都內含HCI Mesh功能），因而vSAN Max的授權與硬體認證都不與原來的vSAN相通，用戶必須專門為vSAN Max購買新的授權，並建置新的硬體，無法由既有的vSAN環境升級轉換。

此外，vSAN Max的部署門檻也較高，最低需要7節點，雖然一般來說，分散式儲存的部署門檻都比較高，但7節點仍算相對較高的要求。

而且，vSAN Max是採用vSAN原生協定來與Client端連結，而非iSCSI、NFS等標準的通用傳輸協定，這也將vSAN Max的使用範圍，限定在VMware應用環境之內。

vSAN Max的額外授權購買需求、較高的部署門檻，但又僅限於在VMware環境中使用，這都會影響用戶的導入意願。

最後，依照我們目前獲得的公開資訊來看，儘管VMware是在今年8月發表vSAN Max，正式上市卻必須等到明年（2024）的下半，跨距超過3個季度，這樣長的等待時間，也讓這款產品的發展存在著一些變數，同樣也會讓用戶有所疑慮。

發展非聚合並不意味放棄超融合

儘管存在一些疑慮，vSAN Max的推出，仍可算是VMware儲存架構發展歷程的一個里程碑，讓vSAN具備完整的非聚合式應用型態。

但另一方面，VMware也沒有放棄原有的超融合架構，並非要以vSAN Max的非聚合架構，來取代超融合架構的vSAN，這兩種產品之間並不是取代關係，而是相輔相成。將超融合與非聚合式這兩種部署型態，結合在同一個平臺後，能夠兼顧兩種架構的長處，為用戶提供最大的部署與擴展彈性。

vSAN的3種儲存架構

在引進vSAN Max之後，讓vSAN形成了3種儲存架構。

上圖最左邊是標準的vSAN HCI架構，運算與儲存資源結合在機箱節點內。

中間是跨叢集容量共享架構，也就是以前的HCI Mesh，可以將標準vSAN叢集的儲存空間，掛載給其他vSAN叢集，或是純運算的vSAN叢集共享使用。

右邊是vSAN Max提供的非聚合式儲存架構，可以將vSAN Max的純儲存叢集，掛載給純運算的vSAN叢集，構成完全非聚合式的應用架構，也能掛載給一般vSAN或vSphere叢集。

圖片來源：VMware