2014年4月18日 星期五

從Hadoop到OpenStack Swift 再到Ceph

蕃薯最近想建置一套分散式文件系統,於是花了4個多月的時間study, 先是Hadoop的HDFS, 再到OpenStack 的Swift, 最後選擇了Ceph。

需求如下:
1. 不要有單點失效。
2. 能自由擴充。
3. 儲存節點失效時能自動轉移資料。

以下列出其優缺點:

Hadoop

優點:
1. 能配合MapReduce架構進行資料分析,相關的套件也很齊全,如: HBASE,HIVE等。
2. 儲存節點失效時會自動轉移資料。
3. 安裝較簡單,只要設定7個設定檔。

缺點:
1. 存在單點失效的疑慮,雖然新的架構把儲存設備與Namenode分開,但其實它只不過是把單點失效從Namenode轉移出去而已。
2. Namenode存在效能瓶頸,雖然新的HA架構將不同的資料拉到不同的Namenode,但單一Namenode還是存在效能瓶頸。
3. Namenode使用大量的記憶體,一個目錄/檔案/block會佔用約150byte的空間,因此一個佔用1 block的檔案大約用了900byte記憶體空間,計算方式: (一個檔案150byte + 一個block150byte) * 3份。一台32GB的RAM作為Namenode只能存放約3000多萬個檔案,擴充性受限,不適合存放小檔案。
4. 必須非常大量的資料與許多主機才看得出效益。蕃薯以4台PC做測試,存取時可明顯感受到延遲,只有一種感覺~~~慢。

Swift:

優點:
1. Metadata存放於各儲存節點,不存在單點失效與效能瓶頸的問題。
2. 搭配Keystone認證,提高安全性。
3. 不用在記憶體中存放block對應,記憶體使用與擴充性較Hadoop好。
4. 使用RESTful介面,號稱相容Amazon S3。
5. 反應速度比hadoop快。

 缺點:
1. 一開始就要決定叢集的規模而決定建立的partition數量,到頂後就無法擴充。雖然蕃薯可能永遠也遇不到這個狀況。
2. 新增節點時必須手動rebalance。
3. 節點失效時不會自動轉移資料,因此必須趕快修復,否則就要先移除節點並rebalance。
4. 單一檔案大小限制5GB,因為Swift會將整個檔案對應到某個節點,為預防造成單一節點Loading特別重。
5. 定時檢查Replication一致性,會佔用CPU資源。
6. 安裝步驟複雜。

以上2套雖然都有不少商業使用,但都不太符合蕃薯的需求,最後找到Ceph這套,幾乎就是我要的,以下大概介紹它的特點:
1.Metadata 主機可以多台,不存在單點失效。
2. 新增/移除節點時會自動rebalance。
3. 不會像Swift一樣定時檢查一致性而佔用CPU資源。
4. 支援POSIX,可以mount 到某個目錄,檔案存取像平常操作檔案一樣,如: ls, rm等指令。
5. Linux 從2.6.34已內建Ceph client, 但有點問題,使用3.4.20或3.6.6以後的核心才沒問題。

Ceph目前唯一比較算是缺點的,就是還沒有太多商轉的廠商,穩定性還需要經過更多的檢驗。

選擇了Ceph的另一個原因是Ceph受到OpenStack青睞,打算用它來作後端儲存系統,顯示它至少有一定的水準。

因為還在學習,以上列出項目如果有錯誤,歡迎指正。蕃薯很看好Ceph,會持續學習、關注它,希望未來能用它來做一些應用, 並不定期po上學習心得跟大家分享。

這陣子在Google找相關資料,台灣應用比較多的就只有Hadoop,OpenStack較少,Ceph更是少得可憐,該網站可查詢來自世界各地的瀏覽量:
http://www.revolvermaps.com/?target=enlarge&i=1lzi710tj7s&color=80D2DC&m=0

台灣在2014/04/18排名第14名,而中國已經是第2名了。

最後,覺得有點感慨,open source在台灣的發展真的有如荒漠。台灣的軟體人員要再加把勁多學習,不要想一套系統(語言)能用到永久(很多蕃薯的朋友只會Oracle PL/SQL),否則總有一天會被淘汰。

2014/05/05更新: Red Hat於2014/04/30以1.75億美元買下了Ceph的公司Inktank, 這讓蕃薯對Ceph的前景更加看好,希望Red Hat能以它的實力加速Ceph的開發與提高穩定性。

收購新聞發佈於此: http://www.redhat.com/about/news/press-archive/2014/4/red-hat-to-acquire-inktank-provider-of-ceph


沒有留言:

張貼留言