link from 蕃薯的筆記本
從Hadoop到OpenStack Swift 再到Ceph
蕃薯最近想建置一套分散式文件系統，於是花了4個多月的時間study, 先是Hadoop的HDFS, 再到OpenStack 的Swift, 最後選擇了Ceph。
需求如下:
1. 不要有單點失效。
2. 能自由擴充。
3. 儲存節點失效時能自動轉移資料。
以下列出其優缺點:
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做測試，存取時可明顯感受到延遲，只有一種感覺~~~慢。
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
需求如下:
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
