經過幾年的推廣後,超融合架構已成為企業IT基礎建設主要的選擇之一,但隨著應用的普及,與用戶應用規模的擴張,超融合架構的先天限制也開始突顯出來。

我們近期接觸用戶與廠商的經驗顯示,在規模較大的應用環境中,超融合架構存在著難以適切配合用戶擴充需求的問題,關鍵在於超融合架構的運算+儲存對稱擴充架構,往往遇上了用戶端不對稱的擴充需求。

「對稱式架構」vs.「不對稱擴充需求」  

超融合系統的標準型態,是ㄧ個包含了運算與儲存資源的標準化節點機箱,擴充時,則透過堆疊更多這種標準化節點機箱來組成叢集,只要增加節點,運算與儲存資源也將對稱地同步擴展。

「運算+儲存合一」,以及「對稱的擴充能力」這2個特性,讓超融合系統的擴充變得十分簡單,當資源不夠時,堆疊更多節點即可。

然而,這樣的特性,許多時候卻也帶來不便,用戶實際環境的運算與儲存擴充需求,往往是不對稱的,但是在超融合架構下,用戶即使只是單純需要更多儲存空間,卻也被迫買進一整臺節點,而這臺節點所帶來的額外的運算能力,是用戶不需要的,反而形成浪費。在這種情況下,隨著擴充的節點數量越多,造成的資源浪費也越多。

也就是說,超融合架構標準的「對稱式擴充」模式,無法適切配合用戶端不對稱的擴充需求。然而「對稱式擴充」這個局限,又是源自超融合「運算+儲存合一」這個基本特性。

考慮到超融合架構在擴充時,存在資源浪費的問題,也制約了在用戶端的應用規模。小規模的應用環境,還可容忍「對稱式擴充」導致的資源浪費,但中、大型的應用環境,這就成為不能忽視的問題。

以我們的經驗顯示,大多數實際用戶環境的超融合架構應用規模,大多在16個節點以下。在一些案例中,當用戶的應用規模超過4個節點時,就會對於超融合架構對應擴充需求的適切性感到疑慮,而考慮改用融合式架構。在融合式架構下,運算與儲存是分離的,可個別擴展,所以不會有超融合架構的問題。

另一方面,也有一些廠商試圖打破超融合系統的常規,例如NetApp HCI、Cisco HyperFlex,以及Pivot3 Acuity都支援非對稱擴充,也就是運算能力與儲存容量可以各自獨立地擴展,用戶需要運算能力時,可以只擴充提供運算能力的節點;若只需要儲存空間,也能單獨擴充個別節點的儲存空間,這樣的做法,比標準的超融合架構更靈活,但也脫離了超融合架構的原始框架,為超融合這種產品型式帶來新的涵義。

熱門新聞

Advertisement