此前寫過一篇“不要被軟件定義存儲說暈了”的文章，主要從構(gòu)成上對概念進行了梳理，有些是基于x86 Scale Out的分布式存儲，有些是基于傳統(tǒng)SAN/NAS的軟件和硬件的分離，有的是從存儲數(shù)據(jù)層面出發(fā)，有的是強調(diào)存儲的管理控制。應(yīng)該說，ServerSAN、超融合(HCI)、存儲虛擬化，大的概念區(qū)分的差不多了。
但新的問題又來了。都是ServerSAN、HCI彼此之間如何區(qū)分水平的高低，品質(zhì)的優(yōu)劣呢?有專家指出，如今市場上超融合/軟件定義存儲的產(chǎn)品眾多(12月10日，北京悠唐假日，中國存儲數(shù)據(jù)峰會，應(yīng)該可以見證有多么活躍……，呵呵，小小的廣告嫌疑，但說的也是實情)，專家指出，很多產(chǎn)品都是在開源的基礎(chǔ)上修改的，利用Linux通用文件系統(tǒng)存儲數(shù)據(jù)，缺乏整體構(gòu)架，水平有限。
專家的指點，也讓我滿腹狐疑。所謂Linux通用文件系統(tǒng)是判別超融合的依據(jù)。他們會強調(diào)自主知識產(chǎn)權(quán)。但我怎么知道開源的好，還是專家自主創(chuàng)新的好呢?一句話，標準是什么?
支持存儲節(jié)點的數(shù)量會是一個標準嗎?很巧，最近接觸到擁有7年AWS云計算核心架構(gòu)師工作經(jīng)歷的陳靚博士，歸國創(chuàng)業(yè)歷時3年推出了ZettaStor分布式塊設(shè)備存儲(DBS)產(chǎn)品。據(jù)說，ZettaStor DBS在AWS云上搭建的測試環(huán)境中，通過了由1 020個存儲節(jié)點組成的集群長時間、穩(wěn)定運行能力驗證。按照設(shè)計，ZettaStor DBS能支持百萬存儲節(jié)點。
我確實聽說過Scale Out達到一定數(shù)量之后，性能不會線性增長了。如果從支撐存儲節(jié)點的數(shù)量是不是可以判別呢?
但似乎也沒有這么簡單。一來，很多超融合都說沒有節(jié)點限制。二來，專業(yè)的說法是，通過對不同位置數(shù)據(jù)的讀寫統(tǒng)一調(diào)配，數(shù)據(jù)被并發(fā)分派到不同的數(shù)據(jù)節(jié)點上，整個分布式構(gòu)架中，系統(tǒng)的所有存儲節(jié)點都參加I/O操作，形成大規(guī)模并行的I/O處理方式，從而幾何級數(shù)提高I/O處理能力，減少了系統(tǒng)的I/O瓶頸。隨著存儲節(jié)點及存儲介質(zhì)的增加，IOPS和吞吐能力的增長近乎線性。
其實，傳統(tǒng)陣列的條帶化，就是采用并行化來解決I/O的問題。理論來說，磁盤越多，IOPS越好。只是傳統(tǒng)陣列的控制器或者稱機頭處理能力會成為瓶頸，限制了所支持磁盤數(shù)量。在超融合，沒有機頭瓶頸。情況自然不一樣。但這個原理很簡單啊。我做編輯的都明白，開源的也好，自主研發(fā)的也好，有多難啊?會有很大的區(qū)別嗎?
再有就是可靠性的問題。超融合，無一例外會采用副本技術(shù)，副本被分別存放在不同存儲節(jié)點上，其中任一份丟失，新的副本隨即自動生成。所謂丟失，其實可以等同磁盤失效，AWS號稱百萬節(jié)點，磁盤數(shù)量幾千萬塊應(yīng)該不夸張，壞個把節(jié)點，應(yīng)該是天天發(fā)生的事情，這就涉及到重建。這個重建和以往RAID有所不同，甚至不用增加新的硬盤，就可以重建副本，參與重建的磁盤越多，速度越快。這也不難理解。有意思的是，軟件定義網(wǎng)絡(luò)中經(jīng)常強調(diào)東西流量劇增，有人說就是副本重建造成，規(guī)模越大，流量越大。似乎有道理，但沒有更多的佐證。
所以，副本也不難理解。似乎技術(shù)比較成熟了。那么，這么多超融合，如何區(qū)分呢?
其實，也有一個簡單的辦法，實際測一下，看似可行。但恐怕也未必客觀，這還有一個使用水平的問題。
天啊，我又暈了!但我們逐漸清楚概念區(qū)分以后，我們需要的其實是一個技術(shù)的標準。別再給我講趨勢了，講講技術(shù)吧!
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。