傳統的綠皮火車，只有一個火車頭在跑，加容量只是不停的在后面一節一節的掛火車皮，它的性能無法得到線性的增長。可是掛的越多，***平均下來整個系統運行的效率越慢。這就好比傳統的集中式塊存儲計算能力主要由控制器提供，計算力是受限的。而云環境的塊存儲需要自己的架構支持，這好比云向傳統的存儲捅了一刀，必須重構，而私有云用戶無緣塊存儲。

[[255573]]

傳統存儲瓶頸塊存儲對

存儲主要可以分為塊存儲、文件存儲、對象存儲。當然今天主要講的是塊存儲，傳統SAN存儲是過去人們經常在討論的一種集中式塊存儲，其交付給客戶的時候通常是以一種雙控架構的形式出現，可理解為背板專有硬件集成了兩個控制節點，緊密耦合在一起，這使得在業務部署的時候會以“成對”的形式出現，并且一對雙控和另一對雙控之間要互相通信，企業不同業務部門的存儲系統難以發揮協同作用。

局限于硬件成本

此外，其需要專有的硬件設計以及專業的硬件架構，這也造成了其本身擁有的硬件成本明顯高于x86服務器，運維起來也比較復雜。一般這種存儲出問題的話，基本上需要專業廠商派專業的服務人員來解決。由此可以看到，傳統的存儲如果想適應云時代的需求，面臨著比較明顯的局限。如何破解這種問題呢?

云時代需要分布式存儲

那么要想讓存儲滿足云時代的要求，要滿足哪些特點?首先，要基于標準x86硬件、軟件/硬件冗余設計，整體架構高可用，存儲是數據的一個終點，要通過計算、網絡最終把數據保存在存儲上。其次，根據業務架構與規模進行存儲架構的調整。存儲能夠根據業務架構的調整、業務規模的變化相應的做靈活的調整。

節點性能容量同步長

再有，容量和性能擁有完整的Scale Out能力，讓性能和容量可以隨著節點線性增長。同時，開放的API、支持與業務耦合。需要做到軟件定義，需要提供開放的API，可以為不同的業務做耦合，不需要綁得那么緊。此外，統一管理、統一運維。在管理和運維方面，一定盡量簡化運維人員參與的復雜度，降低運維成本，盡量讓存儲系統自己去運維。

數據庫成為推動力

對于企業的核心業務系統來講，數據庫算是典型的應用場景之一，這里面包括了傳統的業務系統，比如Oracle、SQL Server、SAP，大部分的金融行業客戶或者傳統企業一定會用這種數據庫，當然也有一些面向分布式的解決方案，比如基于MySQL的分布式數據庫，MySQL是目前比較流行的或者大多數客戶在業務系統部署時候使用的開源數據庫。

核心業務受傳統存儲牽絆

舉個例子，某家保險巨頭需要的存儲系統要具備足夠的穩定性、足夠的性能，才放心讓它支撐核心業務系統。核心業務系統里面數據庫是最關鍵的，比如最常見的Oracle數據庫，傳統企業用什么跑Oracle?基本上都是國外廠商的品牌，比如EMC、IBM或者Oracle一體機來跑Oracle數據庫。

為什么數據庫非常關鍵呢?又比如說這個保險客戶，所有的保單，客戶支付的保費、賠付的金額，都要放在這個數據庫里面。如果這個數據庫出現任何問題，哪怕丟一筆數據，如果這個客戶要做理賠，服務商不清楚他到底繳了多少錢、需要賠付他多少錢，這個產生的問題就非常大了。銀行更是一樣，存一筆錢進去之后，這個數據丟了，對銀行和客戶都有很嚴重的影響。另外一個層面來講，業務系統要能夠基于當前較為流行的Serverless、服務網格、容器K8S，可以將業務系統采用新的架構來做承載和部署。

存儲架構正在改變

如果剖析一些分布式存儲架構的網絡拓撲，可以看到前端的業務集群沒有任何變更，數據庫的服務集群，比如說三節點的Oracle RAC系統，也沒有太大的變化。變化在哪?在整個萬兆網絡和存儲服務集群。傳統業務里，存儲是基于FC的存儲，網絡是兩套網絡，一套網絡是基于業務的傳統萬兆以太網絡或者千兆以太網絡;另一套網絡是專門跑存儲的FC網絡。

統一網絡運維度變低

當做了存儲技術架構的變更之后，從網絡層面來看就是統一架構了，基于一套萬兆的以太網絡來實現的。存儲的網絡和業務的網絡整合，對運維來說復雜度降低了，因為它是同一套架構。此外，在存儲服務集群上可以看到網絡拓撲相對比較復雜，因為一個節點上面有四根網線來做業務的傳輸和網絡的傳輸，不過網絡的流量是可以做平均分配的，因為其沒有一個統一的入口，不像傳統的集中式存儲，而是有兩個存儲網關，所有的流量都要通過存儲網關與后端存儲來做通信。

流量均勻分布存儲節點

分布式存儲的網絡流量、業務流量是均勻分布到所有存儲節點的，會將網絡流量和網絡壓力做了平均分配，可以實現對業務流量的分擔，具備很大的容量擴展和網絡并發能力的。可以說，是一個比較典型的傳統金融行業客戶對存儲和數據庫的使用架構。

結語

以上是云時代分布式存儲需要具備的特性，而這一刀無疑將捅向傳統式管理的架構模式。