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
熱門新聞
2024-12-08
2024-12-08
2024-12-08
2024-11-29