擺脫既有超融合架構的束縛，提供更多樣化的部署型態組合──兩大主流HCI全面發展「去融合」

長期以來，超融合架構在企業IT領域成功的最大優勢——「運算與儲存結合於單一機箱節點」，現在已成了進一步擴大應用情境的阻礙，雖然HCI便於部署與管理，但也帶來運算與儲存負載相互干擾、資源擴充缺乏靈活性等問題，難適應複雜環境需求。

至於解決之道便是「去融合」化，讓超融合的運算與儲存單元能分離部署，也就是所謂的「非聚合式」超融合架構，以便更靈活、更精確地對應用戶環境的需求。

領導超融合架構的2大平臺：VMware的vSAN與Nutanix的AOS，都在這2、3年內，藉由引進一系列新功能，提供運算與儲存單元分離部署的能力，以補原本超融合架構的不足。而由於這兩大平臺在超融合應用領域具有壟斷地位——合計擁有超過三分之二的市場占有率，當這兩大平臺出現了共同的轉變趨勢，也代表超融合領域正全面朝向「去融合」化（de-Converges）發展。

因而，若了解VMware vSAN與Nutanix AOS的「非聚合式超融合」部署功能，也就等同於掌握這領域的去融合化發展情況。

兩大超融合應用平臺的「去融合」化進程

在「去融合」化的過程，Nutanix要比VMware快了一步。因為他們早在2015年中，就在原本的超融合節點產品外，推出NX-6035C「純儲存節點」（Storage Only Node），可單純提供儲存空間，而不加入Hypervisor叢集。

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

在VMware方面，直到2020年9月發布的vSAN 7 Update 1，才透過新導入的HCI Mesh功能，允許用戶建立只有運算功能的vSAN運算叢集（Compute Cluster），然後藉由掛載外部vSAN叢集的datastore來做為自身的儲存空間，初步提供了分離運算與儲存單元的分離。標準的vSAN叢集此時也能透過HCI Mesh掛載外部vSAN叢集datastore，實現跨叢集資源調度。

到了2021年3月發布的vSAN 7 Update 2，則允許傳統vSphere叢集也能透過HCI Mesh功能，掛載遠端vSAN叢集的datastore來使用。接下來的vSAN 7 Update 3，又進一步擴展了HCI Mesh功能的連接能力。

而在今年3月推出的vSAN 8 Update 1，VMware藉著新引進的「非聚合式儲存」（Disaggregated Storage）功能，將HCI Mesh適用範圍，擴展到vSAN 8全新的ESA儲存架構（Express Storage Architecture），以及跨遠端的拉伸式叢集（Stretched Clusters）環境中。

至此，VMware主要的vSphere與vSAN版本，都能透過HCI Mesh功能，提供純運算叢集，以及掛載遠端vSAN datastore能力。只要是vSAN Enterprise版或Enterprise Plus版以上，就能啟用HCI Mesh功能。

兩大平臺的「去融合化」架構差異

經過一系列版本與功能更新後，目前的Nutanix與VMware的超融合平臺，都支援拆分運算與儲存單元的「非聚合式」部署形式，但由於基本架構有別，兩大平臺之間存在微妙的差異。

以Nutanix而言，他們是透過新增2種新節點——「純儲存節點」與「純運算節點」，來提供運算與儲存單元分離部署與獨立擴充能力，整個部署架構是以個別節點為單位。

VMware則只新增了「運算叢集」，搭配HCI Mesh提供的掛載遠端vSAN叢集datastore功能，來分離運算與儲存單元，整個部署架構是以叢集為單位。

相較之下，Nutanix以個別「純儲存節點」與「純運算節點」作為擴展單位，這種作法顯然更易被理解，也更簡便。

VMware則認為以叢集為單位，更能確保可用性的需求，若以個別純運算或純儲存節點為擴展單位，叢集將會出現無法承擔失效節點重建工作的風險。

舉例來說，在叢集加入個別的純儲存節點，這些純儲存節點因本身集中了較多的儲存空間資源，一旦失效，叢集中其他節點可能沒有足夠儲存空間資源，來重建失效純儲存節點上的資料。

因而VMware採用整個叢集作為HCI Mesh的運作單位，叢集內各節點的資料負載是平衡分布的，具備承受個別節點失效的韌性。

針對這個問題，Nutanix方面也有相應的對策，以確保當「純儲存節點」與「純運算節點」加入叢集後，整個叢集具備承受這些節點失效的重建能力。

例如當在叢集中加入純儲存節點後，必須視節點數量，相應地增加資料複製的數量與失效容限設定，最好成對地加入純儲存節點，以便叢集有足夠資源，可以因應純儲存節點失效時的資料重建需求。而在應用純運算節點時，Nutanix也對叢集中包含的純運算節點與HCI節點的比例，有一定的限制，以確保叢集擴展後仍具備足夠的失效容限。

運算單元的差異

在分解之後的HCI運算單元方面，Nutanix與VMware採取相似的做法。

例如，Nutanix的「純運算節點」，是省略儲存叢集相關元件與功能的節點，可將硬體的運算力都供給Hypervisor，用來運行用戶端VM與應用程式，至於VM與應用程式需要的資料儲存空間，則由Nutanix叢集中的其他HCI節點或純儲存節點來提供。

VMware的「運算叢集」，同樣也是關閉了vSAN儲存叢集功能，因而可將叢集節點的運算資源集中供應vSphere，用來運行用戶端VM與應用程式，至於VM需要的儲存空間，則透過HCI Mesh掛載外部vSAN叢集的datastore來獲得。

也就是說，Nutanix的「純運算節點」與VMware的「運算叢集」，基本上，都是由省略或關閉儲存叢集功能的節點構成，藉此可避開儲存叢集相關負載的干擾，把更多的運算資源保留給用戶端VM與應用程式執行。

簡而言之，兩個HCI平臺去融合化的最大差別是：Nutanix的「純運算節點」支援多種Hypervisor平臺，包括Nutanix的AHV或VMware的ESXi，而VMware的「運算叢集」則只提供自身的ESXi。

儲存單元的差異

關於分拆後的HCI儲存單元，Nutanix與VMware採取完全不同的做法。

例如，Nutanix提供「純儲存節點」，這是一種省略了運行用戶端VM能力，只保留儲存叢集功能的HCI節點。

實際上，「純儲存節點」雖然也含有Hypervisor，但採用的是Nutanix平臺內含的AHV平臺，用戶不需要另外付費。至於「純儲存節點」當中的AHV平臺，只是為Nutanix儲存叢集的控制器VM提供運作環境而已，不能夠用於運行用戶端VM。

因而Nutanix的「純儲存節點」不需要太高的運算資源，處理器規格與記憶體容量都可大幅降低，而這些運算資源也將集中於處理儲存叢集的I/O負載，不會被用戶端VM所干擾。

至於VMware超融合平臺，並未提供專門的「純儲存叢集」，HCI Mesh遠端datastore掛載功能所需的datastore空間，是由標準的vSAN叢集來提供。

相較於可提供「純儲存節點」的Nutanix，VMware的「非聚合」部署架構在儲存單元方面，可能會出現效能與成本的劣勢。

原則上，為HCI Mesh提供遠端data store的vSAN叢集，仍具備運行用戶端VM的能力，因而有影響與干擾這些vSAN叢集I/O效能的疑慮。當然用戶可以主動停用這些vSAN叢集的用戶端VM，以便將資源集中供應vSAN服務，促使這些叢集扮演單純的「純儲存用」角色。

Nutanix的純儲存與純運算節點

提供獨立儲存空間與運算資源擴展能力，改善靈活性與成本效益

目前Nutanix一共可提供3種類型的節點，可以在叢集中相互搭配使用：

● 超融合節點（HCI Node）：同時擁有運算能力、記憶體與資料儲存空間，可以運行3種Hypervisor平臺，包括VMware ESXi、微軟Hyper-V，以及Nutanix自身的AHV等。

● 純儲存節點（Storage Only Node）：只能運行Nutanix AHV 平臺，且只具備最低限度的運算能力與記憶體容量，但可提供大量儲存空間。

● 純運算節點（Compute Only Node）：運行Nutanix AHV或VMware ESXi 平臺，只擁有最低限度資料儲存空間，但能提供較高運算能力的處理器，以及較大的記憶體容量。

｜Nutanix純運算節點與純儲存節點的應用情境｜上圖為Nutanix提出的純運算與純儲存節點應用範例。標準的HCI節點可用於運行VM與提供儲存空間，純運算節點用於運行按處理器計費的Oracle應用程式VM，而不會將運算資源用於叢集儲存處理，以便更充分地發揮軟體授權效益，純儲存節點則專門負責提供儲存空間，不用於運行用戶端VM。圖片來源／Nutanix

接下來，我們把重點放在純儲存節點與純運算節點的配置。

純儲存節點

純儲存節點有時也稱為「輕運算節點」（Light Compute Nodes），只能運行Nutanix自身AHV Hypervisor平臺，但這個Hypervisor不用於運行用戶端VM（guest VM），只為Nutanix自身控制器VM（CVM）提供運作環境。至於CVM，則是Nutanix儲存叢集核心，用於處理節點內部與對外的I/O，管理節點內部的磁碟存取，以及節點對外的節點間互連傳輸。

純儲存節點的目的是為Nutanix叢集擴展儲存空間，純儲存節點的儲存空間可無縫地加入到既有叢集的儲存空間中，不僅能增加容量，也能提高I/O效能。

雖然純儲存節點運行的是AHV平臺，但可相容於運行ESXi、Hyper-V與AHV平臺的Nutanix叢集環境，為這些叢集增加儲存容量。另一方面，AHV是Nutanix AOS平臺內含元件的一部分，無須另外計費，所以增加純儲存節點時，用戶無須額外支付Hypervisor費用。

早先只有特定的Nutanix NX系列節點硬體可作為純儲存節點使用，然而，自Nutanix Foundation 4.1版起，所有Nutanix NX系列節點硬體，都可透過部署映像檔的方式，作為純儲存節點使用。當搭配AOS 6.1版以後使用時，用戶在擴展叢集節點時，可選擇將HCI節點轉為純儲存節點，或是將純儲存節點轉為HCI節點。

另外要特別注意的是，不可將純儲存節點與「儲存重節點」（Storage Heavy Node）混淆，儲存重節點只是一種擁有較大儲存空間的HCI節點，可運行用戶端VM，與純儲存節點有本質上的區別。

純運算節點

純運算節點的目的，是為Nutanix叢集提供無縫擴展運算能力，也就是處理器與記憶體資源。

一開始，純運算節點只能運行Nutanix自身的AHV Hypervisor，且不含CVM元件，只含有運行AHV所需的最低限度儲存媒體配置。自AOS 6.6.2版起，用戶也能建立運行ESXi的純運算節點，同樣也不含CVM。

由於純運算節點沒有CVM，因而無法將節點內部的儲存空間加入到Nutanix叢集中，不能為Nutanix叢集提供儲存空間資源，而只能利用AHV來運行用戶端VM，至於這些用戶端VM所需的vDisk儲存空間，則可由Nutanix叢集中的其他HCI節點或純儲存節點來提供。

但另一方面，由於純運算節點沒有CVM，這也意味著的所有運算資源，都只會被用在用戶端VM的應用程式上，能讓某些依照處理器核心數計費的應用程式，獲得更好的成本效益，而不會像一般HCI節點必須將相當一部分的運算能力，消耗在運行CVM上。依照Nutanix的手冊，一臺CVM至少需要使用8到12個vCPU，以及20GB以上vRAM的資源，因而純運算節點省下CVM消耗的資源後，將能讓上層的用戶端VM多出不少資源。

目前所有Nutanix原廠的NX系列節點，或是其他OEM廠商的節點硬體，都可作為純運算節點使用，也能將既有的HCI節點轉為純運算節點。

不過比起純儲存節點，純運算節點的部署條件相對比較嚴苛。例如純運算節點只能加入到已擁有至少3個節點的Nutanix叢集中，且該叢集中純運算節點與一般HCI節點的數量比例不能超過1比2，另外，ESXi版的純運算節點還有特別的限制，只能加入基於AHV平臺純儲存節點組成的叢集，而無法與HCI節點混合使用。

VMware的HCI Mesh

提供跨叢集儲存資源共享能力，實現運算與儲存資源分離擴展

從vSAN 7.0 U1開始引進、並延伸到最新vSAN 8 U1的HCI Mesh功能，可以讓用戶建立純運算功能的vSAN叢集，然後將外部vSAN叢集的datastore掛載起來，而成為本身的儲存空間。

其中為其他叢集提供datastore儲存空間的vSAN叢集，被稱為HCI Mesh Server叢集。而匯入外部vSAN datastore儲存空間的叢集，則稱為HCI Mesh Client叢集。

｜透過HCI Mesh的運算與儲存分離部署｜藉由HCI Mesh提供的功能，用戶可以建立只提供運算能力的運算叢集（Compute Cluster），作為HCI Mesh的Client端叢集，然後由外部vSAN叢集扮演HCI Mesh Server端叢集角色，將vSAN叢集的datastore儲存空間，掛載給運算叢集作為儲存空間。

而一般的vSAN叢集也能作為HCI Mesh的Client端叢集，透過HCI Mesh掛載外部vSAN叢集的datastore，來擴展本身的儲存空間。圖片來源／VMware

藉由HCI Mesh這項功能，可以實現下列兩個目的。

橫跨多個vSAN儲存叢集之間的datastore空間共享

多個vSAN叢集之間，能藉由HCI Mesh的連結，匯集成一個跨叢集的儲存池，然後將某些vSAN叢集閒置的datastore空間，掛載給需要datastore空間的vSAN叢集使用。

非vSAN型式的傳統ESXi叢集，現在也適用於HCI Mesh，可藉此掛載遠端的vSAN datastore空間，而且用戶還不需要為這些傳統ESXi叢集購買vSAN相關授權。就能透過HCI Mesh的遠端掛載能力，讓傳統ESXi叢集也能使用vSAN的儲存服務，

利用HCI Mesh的跨叢集遠端掛載datastore能力，不僅能實現跨叢集的儲存資源調配，改善資源利用效率，同時也能突破ESXi與vSAN既有的擴展能力限制，除了叢集本身內含的datastore空間外，還能利用HCI Mesh功能，掛載其他叢集的datastore空間。

實現運算、儲存分離，以及非對稱擴展

用戶可以利用HCI Mesh建立關閉了vSAN儲存功能的「純運算用叢集」，藉此將更多運算資源用於vSphere上運行的用戶端VM，而不會消耗在vSAN上。

舉例來說，一臺啟用了vSAN、基於全快閃儲存組態的ESXi主機，vSAN通常需要占用20GB至30GB或更多的實體記憶體。而這也意味著，如果這臺主機將vSAN關閉，就能讓ESXi多出20GB至30GB以上的可用實體記憶體，等於多了8至10%的記憶體資源（以伺服器典型的256GB到384GB主機記憶體容量為計算基準）。

至於這些運算用叢集需要的儲存空間，則可透過HCI Mesh掛載其他vSAN叢集的datastore空間來提供。所以，這也等同於分離了運算與儲存單元。

另一方面，既有的vSAN叢集，也能利用HCI Mesh掛載外部vSAN的datastore，藉此擴展自身的可用儲存空間，而不需要增加一整臺節點，這也等同於讓這些SAN叢集只擴展儲存資源，而不擴展運算能力，形同於非對稱的資源擴展。

HCI Mesh的應用形式

VMware針對HCI Mesh的應用，設想了下列幾個典型的情境：

● 應用程式的重構（refactor）、需要為日誌記錄保留，提供大量額外儲存空間。

● 因為組織或業務調整，導致儲存資源需求存在很大的不確定性。

● 儲存擴展需求急迫，但運算資源仍有餘裕。

● 啟用與部署NSX網路虛擬化，需要遷移原有叢集資料。

● 業務分析作業將占用大量運算資源，以致會衝擊底層vSAN的運作。

上述這4種情境都出現了臨時的額外儲存空間需求，此時，用戶可以透過HCI Mesh掛載外部vSAN叢集的datastore，來因應這些臨時性的儲存空間需求，而不需要急著為叢集增加節點。

最後1種情境則是出現了臨時的額外運算能力需求，可能會影響底層vSAN服務的運作，此時也能透過HCI Mesh，改由外部vSAN叢集來提供datastore空間，免除自身叢集的vSAN服務負載，也就是將儲存服務負載，利用HCI Mesh卸載給外部vSAN叢集來承擔。

值得注意的是，vSAN 7與vSAN 8在HCI Mesh功能的應用規格，略有差異。

以vSAN 7平臺而言，每一個HCI Mesh Client叢集環境，最多能夠掛載5個遠端datastore，每個HCI Mesh Server叢集能為5個Client叢集提供datastore空間，而且，Client與Server叢集最多能包含64臺ESXi主機，到了vSAN 7 U2以後，增加為128臺ESXi主機。

而在vSAN 8平臺方面，每一個HCI Mesh Client叢集環境，同樣最多只能掛載5個遠端datastore，Client與Server叢集同樣也能包含最多128臺ESXi主機，不過，每個HCI Mesh Server叢集，能為10個Client叢集提供datastore空間，比起vSAN 7增加一倍，能將datastore分享給更多Client端叢集使用，大幅擴充了HCI Mesh Server叢集的儲存共享規模。