OpenStack Sahara (2)

在進一步介紹Sahara之前, 我們要先了解hadoop的設計原理,
hadoop是一開始雲端的平行運算平台, 基於Google提出的MapReduce架構所設計,
在一開始雲端的環境中, 儲存的虛擬化比較成熟, VM的概念並不盛行,
因此, hadoop是基於實體機的架構進行設計,
在hadoop的架構下, 分成兩個主要的部份:
HDFS, 一個分散式資料儲存系統; MapReduce: 基於HDFS的平行運算,

(來自: https://cvw.cac.cornell.edu/MapReduce/locality)

在上圖中, 藍色方塊代表HDFS中的資料鏡像,
MapReduce基於資料鏡像的位置, 進行資料的運算, 也就是所謂: 搬程式不搬資料,
這樣的架構假設了資料大小遠大於程式, 適合於大資料平行化處理,
考慮到硬碟的讀取速度, 通常要至少大於1TB的資料較有效率,

注意: hadoop事先設計HDFS, 在設計基於HDFS的平行運算架構,
因此, MapReduce的平行運算天生就是為了處理大資料, 容錯, 以及實體機而設計,
基於這樣的先天設計,
hadoop適用於TB以上的資料平行運算, 本身自帶容錯機制,
而且對於運算資源的調控極為笨拙.

當Sahara要把hadoop移植到OpenStack時, 也面臨了相同的限制,
有一部分功能是OpenStack已經做了, 如Swift已經有了fault tolerance,
有一部分功能則是OpenStack無法提供, 例如: 對節點的容錯,
為此, Sahara並不只是單純移植hadoop, 同時提供了一些基於OpenStack的特有功能,
我們將選取一部分作為說明:

1. scaling:
   和heat結合, Sahara提供scaling的功能 不過此處的scaling只對於tasktracker/datanode,
   也就是只有hadoop本身應用,若是我們要對hbase支援或是某些原生程式,
   我們則要特別處理資料消失與load balancing的功能
2. Anti-affinity:
   Sahara將datanode分配在不同compute node上, 避免資料遺失,
   此功能是針對複數VM可能分配在同一個實體機 (compute node)上,
   導致原本對於節點失效的容錯機制失效,
3. Data locality:
   是指將datanode (以及其附屬的cinder資料) 配置到相同的compute node或是機櫃上,
   增進資料交換的速度, 這是考量平行運算中communication cost的做法,
   在原有的實體機環境中, hadoop並沒有特別考慮communcation cost,
   因為hadoop本身設計上是在一個扁平的區域網路內,
   不必考慮雲端環境中複雜的網路組織與實體機架構,

當然, 我們可以發現(2)和(3)的目標是相悖離的, 

是Sahara在移植hadoop中在reliability和efficiency中做取捨,

這些功能與配置, 都可以藉由設定, 來使Sahara實作/不實作 這些功能,

完整的功能列表如下:

http://docs.openstack.org/developer/sahara/userdoc/features.html

這也增加了Sahara布建的困難,
或者說, 透過Sahara建立一個hadoop cluster並不困難,
困難的反而是要讓該cluster有效率的發揮hadoop的優點,
並能兼容OpenStack易於擴充, 便於使用的好處.