Hadoop with 38 nodes

38ノードでHadoop を評価

[summary] Prior to my hard work for CEC2008, I worked for Hadoop with bunch of nodes. This time, I configured 36 DataNodes + 2 NameNodes and succeeded benchmarking testing.

(Translate to English)

11月上旬に開催されたCEC2008の準備のために9・10月は非常に忙しかったのですが、そうした中、複数の顧客の要望で、HadoopをSunのサーバを使って評価することとなりました。

  • 最新の0.18.1を使用
  • 36 DataNode + 2 NameNode の計38台を最大として構成(仮想環境上のノードも含む)
  • テキスト・データを500MB 〜 数十GBまで順次に利用
  • LocalファイルがHDFSに分散される経過を6 〜36 DataNodeで検証
  • replication の数による動作の変化を検証
  • 耐障害性検証を目的とした、DataNode ならびにNameNodeを止めて処理継続性をテスト
  • Map/Reduce のスケーラビリティ検証

上記の中でも、多くの方が興味を持つのは、「Map/Reduce のスケーラビリティ」でしょう。これは6 〜36 DataNodeで順次検証しました。いろいろなDemoプログラムや自作のものを試してみましたが、結局、wordcountでスケーラビリティを検証することとなりました。「Solaris でMap/Reduceを38台で稼働させている」証拠のスクリーンショットが下図です。


このタイミングでは、Map が18%まで進行していますが、各ノード共処理が正常に行われていることがおわかりいただけると思います。ここではSolaris上での稼働状況を可視するためにperfbar(日本語紹介はこちら)を使っています。上の3列のグラフがDataNodeで、下2つがNameNodeです。DataNode上ではperfbar の緑色が示す通り、アプリケーションが「よくまわっている」状態です。もし赤が多いと、I/O等のシステム側のオーバヘッドが多いことになりますがそれもなく、非常に上手くいっているようです。

さて、DataNodeを6〜36と増やしていった時のパフォーマンスの変化をグラフにしたのが下図です。


上図を見るとほぼ 6 nodeから21 node まではリニアに伸びていっているのがわかります。しかしながら、それ以降は横ばいもしくは伸びが鈍化しています。これは以下の理由によると思われます。

  • 一部仮想環境があるために、ボトルネックが発生した
  • DataNodeの数に比べてデータの大きさが十分でないために、データをHDFS空間へコピーする際に的確な分散がされてなく、Mapプロセスによる処理が均質化されていない
前述したエントリでも書きましたように、Hadoop は小規模で動かすことはそれほど難しくありません。しかしながら、ある程度の規模を超えると、構成やチューニングポイント等、考えなければならない箇所が数多く出てきて、大規模な構成で構築するには、中規模構成での検証の経験等ある程度のknow-howは必須だと感じました。
投稿されたコメント:

コメント
コメントは無効になっています。
About

Takashi Shitamichi(下道高志)

Chief Technologist
GSE Japan, Sun Microsystems

Spokes Person/Secretary@SIG-Japan,Liberty Alliance
Chair of Edu-committee, ISACA Tokyo
CISA,CISM
中小企業診断士

Search

Archives
« 4月 2014
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今日