如何進行ECS對象存儲技術架構剖析

這篇文章給大家介紹如何進行ECS對象存儲技術架構剖析，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

今天，我們來講講歷史悠久的EMC家族的對象存儲ECS，這里ECS可不是二傳手的意思，而是指Elastic Cloud Storage。

為什么說ECS歷史悠久呢，因為EMC在2001年就推出了內容存儲Centera，后來在2008年推出Atmos，到2014年推出的ECS已經是第三代對象存儲了。由于2014年以后，S3已經成為對象存儲的事實標準，因此，EMC從ECS才支持S3協議的。但由于現網中有眾多的Centera和Atmos的用戶，因此，ECS被迫支持原來的很多API，可以想象，ECS的歷史包袱還是很重的。

ECS的產品架構層次還是比較清晰的，從上到下依次是：

1. ECS門戶和供應服務- 基于Web的GUI，允許自我服務，自動化，報告和管理ECS節點。它還處理許可，身份驗證，多租戶和配置服務。

2. 數據服務- 支持對象，HDFS和NFSv3協議的服務，工具和API。

3. 存儲引擎- 負責數據存儲和檢索，管理事務，數據保護和復制。

4. Fabric - 提供群集，運行狀況，軟件和配置管理，升級功能和警報。

5. 基礎架構- ECS的基本操作系統是SUSE Linux Enterprise Server 12或更高版本，用于交鑰匙設備或用于商用硬件的合格Linux風格操作系統。

6. 硬件- 交鑰匙設備或合格的商品硬件。

   
   

在數據服務上，前面我們講過，ECS除了支持S3外，還向下兼容CAS和Atmos，而且，也支持Swift。不過，如果是新用戶，肯定只用S3，不會選擇那些過氣的協議了。還有，ECS也支持HDFS和NFS協議，這個我們后面再講。

不過，ECS在對HDFS的支持這塊，沒有和其他對象存儲一樣，采用社區的S3A協議，而是自己做了一個專用的ECS HDFS Client。

這樣的好處就是自己來實現HDFS語義對自己對象的訪問，一般都會比S3A有更好的性能和更多的功能。業界對象存儲采用專用HDFS Client來連接對象存儲除了EMC外，還有華為和XSKY，也是這個思路。

由于對象存儲大部分都具有多站點的能力，因此，Hadoop用戶一般采用ECS對象存儲來做災備，也可以實現多個數據中心同時分析。

采用存算分離，好處很多，特別是EC（糾刪碼）在對象存儲里面非常成熟，但是在Hadoop里面算是比較新的特性，很少看到用戶在生產系統里部署，主要是硬盤故障的時候重構時間太長，運維比較復制。生產系統用三副本，造成幾乎所有的Hadoop項目都面臨空間不足的問題，但如果一直擴容容量，則有HCI一樣的問題，計算也要跟著做無謂的擴容，造成資源的大量浪費。

ECS內置了對NFS協議的支持，并且支持8個站點的統一命名空間，支持全局鎖，支持NFS|HDFS|S3之間的互訪。

ECS的Chunk是固定的128M，管理的粒度有點大。我們知道Ceph的缺省Chunk大小是4M。

ECS的數據管理采用B+樹，支持用戶自定義屬性反查，但是限制比較多，每個桶只能有5個索引段，而且創建完成后就不能修改了。（原來的版本手冊寫了這些限制，但最近ECS今年又發布了新版本，不知道是否還是有這些限制，大家測試一下就知道了）。

由于ECS不支持SSD做寫緩存，和其他SDS很不一樣，它用內存做寫緩存。但由于內存沒有掉電保護，因此，ECS需要和Oracle數據庫一樣，在回應寫完成前，必須完成日志的落盤。這種機制造成了數據雙寫，性能比較差。因此，EMC也打算在今年的新版本也要支持SSD做寫緩存了。

ECS的索引數據采用3副本的方式來保證其安全性。

但數據保存全部采用EC（不支持副本）。寫之前數據會壓縮，如果對象大約128MB（Chunk的大小），就直接EC。如果不是，就先寫三副本，然后異步做EC。這樣做的好處就是提高小文件的性能。

而讀嘛，接受讀請求的節點先找索引所在的節點，然后再找數據所在節點讀取數據，返回給host。因此，一般情況，一個讀流程需要經過三個節點處理，IO訪問路徑長，請求訪問一個對象需要做多次重定向磁盤訪問，雖然可以借助于緩存元數據改善，但大規模隨機訪問情況下，緩存效果可能一般。

ECS還支持跨站點做EC，這種情況雖然空間利用率上升了，但對站點的帶寬時延都有比較高的要求，特別是某個站點故障的情況下。因此，國內我了解很少這樣的部署方式。

后來，EMC也認識到這樣的問題，在3.1版本推出了第三站點容災only特性，解決用戶想花比較少的錢實現三站點容災的問題。

ECS的數據復制雖然是異步的，但是元數據復制是同步的。這樣，從用戶角度看，數據是強一致的。但在這種方式如果主站點故障，還是會丟數據的。

Box-Carting是ECS的小文件歸并功能，ECS在內存里把小文件歸并為2MB大小再落盤，提高寫性能。

至于本地數據保護，ECS只支持12+4和10+2兩種保護方式，靈活性比較差。

ECS也支持和IBM一樣的緊湊型EC，減少初始節點數。不過，ECS要求4節點起，而一般分布式存儲都是三節點起。

由于ECS支持跨站點EC，因此，站點越多，利用率反而越高，這和一般傳統存儲數據復制的弊端正好是反過來的。不過，前面也講過，中國好像這樣部署的企業客戶不多（公有云比較多）。

ECS的數據可用性只宣傳3個9，太實在了，實在是泥石界的一股清流啊。其他的廠商恨不得都宣傳6個9以上。不過，難得EMC不怕友商拿來控標的嗎？O(∩_∩)O哈哈~

ECS的組件都是封裝成容器，采用容器的方式部署。

ECS雖然支持純SDS的方式，但銷售更喜歡推廣一體機，這樣銷售額比較大啦。ECS沒有內置負載均衡功能，而且5節點起步，價格有點小貴。

ECS在擴容這塊特性不是太豐富，重平衡的時間可能比較長。

我們看到，ECS今年有兩個小版本，在3.3支持SSD做Cache等重要特性，3.4支持新硬件。我前面的分析都是基于去年的版本，新版本我還沒有拿到太多資料。

從長遠來說，ECS未來會支持全閃，支持混合云等特性。

ECS都是Gartner和IDC相關象限的領導者。

Gartner對ECS的UI和容器架構比較欣賞，但還是指出一些問題。

在產品關鍵能力得分上，只有管理能力做到了業界最佳。

整體來說，我感覺ECS功能還是比較豐富的，比如在跨站點EC和數據強一致這塊做了不少工作，但是，由于國外廠商一般把對象存儲定位在保存溫冷數據上，其對性能不夠重視。比如ECS剛剛才支持SSD做Cache，小文件歸并策略太簡單了，不支持副本做數據保護，不支持整池擴容和重構QoS等。

關于如何進行ECS對象存儲技術架構剖析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。