Mais conteúdo relacionado
Semelhante a Hadoop Operations #cwt2013 (20)
Mais de Cloudera Japan (17)
Hadoop Operations #cwt2013
- 2. ⾃自⼰己紹介
⼩小林林 ⼤大輔
• カスタマーオペレーションズエンジニア
• 主に国内外のテクニカルサポート業務を担当
• email:
daisuke@cloudera.com
• twi3er:
d1ce_
•
2
- 7. ハードウェア選定:スレーブノード
•
コスト対効果の⾼高いコモディティサーバーを使う
•
•
コモディティ = 各部品がどこでも調達可能という意味
低スペックの安いサーバーではない
Hadoopクラスタ構成時のハードウェア選定の⽬目安
•
ブログ:
h3p://www.cloudera.co.jp/blog/how-‐to-‐select-‐the-‐right-‐hardware-‐
for-‐your-‐new-‐hadoop-‐cluster.html
•
⼀一般的な選定の範囲
•
•
•
•
7
ディスク:1-‐‑‒4TB の HDD を 12-‐‑‒24 台積む (JBOD)
CPU:2-‐‑‒2.5GHz の 4/6/8コア CPU × 2
RAM:64-‐‑‒512GB
(Impala を利利⽤用する場合は 128GB 以上を推奨)
ネットワーク:10Gbit (20台以下であれば 1Gbit)
- 10. ハードウェア選定:マスターノード
ハイエンドのサーバーを使う
• 電源⼆二重化、NIC ボンディング、RAID1
• ⼀一般的な選定
•
•
•
•
•
10
ディスク:1TB の HDD を 4-‐‑‒6台積む
OS ⽤用(1台) + fsimage ⽤用(2台:RAID1) +
ZooKeeper (1台) + JournalNode (1台)
CPU:2-‐‑‒2.5GHz の 4/6/8コア CPU × 2
RAM:64-‐‑‒128GB
ネットワーク:10Gbit (20台以下であれば 1Gbit)
- 13. ソフトウェア選定:HA構成
必ず HA 構成を組む
• ⾼高可⽤用性ネームノード (NFS は不不要)
•
•
•
•
アクティブ/スタンバイネームノード
JournalNode (edits の保存先として) × 3
⾃自動フェイルオーバー⽤用
•
•
•
5⽉月に開催したHDFS HAセミナーの資料料も参照
•
13
ZooKeeper × 3
ZooKeeperFailoverController (ZKFC) × 2
http://www.slideshare.net/Cloudera_̲jp/hdfs-‐‑‒ha
- 20. 運⽤用時の注意点:OS編
•
Transparent Huge Page
•
全ノードで無効にすること
•
•
•
•
#
echo
‘never’
>
sys/kernel/mm/redhat_transparent_hugepage/defrag
RHEL 6.2 and 6.3
CentOS 6.2 and 6.3
SLES 11 SP2
対象 OS は以下
•
•
•
参考 http://structureddata.org/2012/06/18/linux-‐‑‒6-‐‑‒transparent-‐‑‒
huge-‐‑‒pages-‐‑‒and-‐‑‒hadoop-‐‑‒workloads/
vm.swappiness
•
全ノードでデフォルト 60 から 0 に変更更すること
•
•
20
#
sysctl
-‐w
vm.swappiness=0
どちらも、デフォルト設定では致命的なパフォーマンス劣劣化を
招くことが報告されています
- 21. 運⽤用時の注意点:HDFS編
•
ネームノード
•
•
ヒープサイズは、100万ブロックで 1GB が⽬目安
ブロックサイズは 128MB を推奨
•
•
•
fsimage を保存する dfs.namenode.name.dir は
複数ドライブを指定し、ミラーリングすること
RAID1 も推奨
JournalNode
•
•
21
small files problem に注意する
dfs.journalnode.edits.dir をひとつ指定
RAID1 上に構成することを推奨
- 22. 運⽤用時の注意点:HDFS編
•
データノード
•
•
•
ブロック数はノードあたり最⼤大でも 30 万が⽬目安
ヒープサイズは 1-‐‑‒4GB 間で調整
バランサーによるブロック転送量量の調整
•
•
•
デコミッション/障害時のブロック転送量量の調整
•
•
•
22
dfs.datanode.balance.bandwidthPerSec
下記コマンドで動的に変更更可
$ sudo
-‐u
hdfs
hdfs
dfsadmin
-‐setBalancerBandwidth
…
dfs.namenode.replicaKon.work.mulKplier.per.iteraKon
をデフォルトの
2
から変更更する
(最⼤大でも
5)
ネームノードの再起動が必要
あくまでも⼀一時的な変更更とすること
- 23. 運⽤用時の注意点:HDFS編
•
Hive の HA 対応
1.
2.
3.
•
23
Hive サービスの停⽌止
metatool の 実⾏行行
$
hive
-‐-‐service
metatool
-‐listFSRoot
$
hive
-‐-‐service
metatool
-‐updateLocaKon
hdfs://nameservice1
hdfs://oldnamenode.com
Hive サービスの起動
HA <-‐‑‒> non-‐‑‒HA どちらに移⾏行行しても実施する
こと
- 25. 運⽤用時の注意点:HDFS編
•
実際にあった話1
•
事象
•
•
原因
•
•
•
•
25
実ブロックが存在しているにもかかわらず、ネームノードか
ら⾒見見えなくなっており、missing replica のアラートがあ
がった
実ブロックを格納しているディレクトリが、あるひとつの
DN の hdfs-‐‑‒site.xml
から削除されていた
プロパティ:dfs.datanode.data.dir
注意:HDFS
⾃自⾝身に耐性はあるので致命的ではありません
このようなヒューマンエラーは Cloudera
Manager を利利⽤用す
ることで回避できます
- 27. 運⽤用時の注意点:HDFS編
•
実際にあった話2
•
事象
•
•
スタンバイネームノード側の ZKFC が起動しない。アク
ティブ側は起動しており、ネームノードも正常動作している。
この状態でアクティブ側に障害が発⽣生すると、フェイルオー
バーできずクラスタダウンにつながる
原因
•
•
ZKFC <-‐‑‒> ZK 間の通信に失敗していた
ZK が許容する最⼤大接続数が低すぎたことが原因 (60)
•
27
プロパティ:maxClientCnxns
- 28. 運⽤用時の注意点:HDFS編
•
実際にあった話2
•
事象
•
•
スタンバイネームノード側の ZKFC が起動しない。アク
ティブ側は起動しており、ネームノードも正常動作している。
この状態でアクティブ側に障害が発⽣生すると、フェイルオー
バーできずクラスタダウンにつながる
原因
•
•
ZKFC <-‐‑‒> ZK 間の通信に失敗していた
ZK が許容する最⼤大接続数が低すぎたことが原因 (60)
•
•
28
プロパティ:maxClientCnxns
教訓:原因⾃自体は単純でも、思いがけないミス、設定
不不備がクラスタに影響をあたえます!
- 33. 運⽤用時の注意点:MapReduce編
•
ジョブトラッカー WebUI は、実際に消費中のヒープは表⽰示しない
•
前者は、現在および将来のオブジェクトに利利⽤用可能な現在のメモリの総容量量
•
後者は、仮想マシンが使⽤用できる最⼤大メモリ容量量
http://docs.oracle.com/javase/jp/6/api/java/lang/Runtime.html#totalMemory%28%29
http://docs.oracle.com/javase/jp/6/api/java/lang/Runtime.html#maxMemory%28%29
•
消費中のヒープは Hadoop が提供するメトリクスから確認
1.
2.
33
http://<ジョブトラッカーのホスト名>:50030/jmx
“java.lang:type=Memory” -‐‑‒> "used"
- 35. 運⽤用時の注意点:HBase編
HMaster のヒープサイズは 2-‐‑‒4GB で調整
• 問題はリージョンサーバー (RS)
•
•
パフォーマンス劣劣化を招く問題は 3 つ
1.
2.
3.
GC によるタイムアウト
-‐‑‒> ZK とのセッションが維持できないと、RS は⾃自ら停⽌止
OutOfMemoryError
-‐‑‒> ヒープサイズは最⼤大 16GB を推奨
ホットスポット発⽣生
-‐‑‒> 特定の RS に書き込みが集中していないか、ログや
HMaster の WebUI から確認する。スキーマ設計につい
ては嶋内の資料料も参考
http://www.slideshare.net/Cloudera_̲jp/hbase-‐‑‒hcj13w
35
- 36. 運⽤用時の注意点:HBase編
•
ZK との通信について
•
•
(再掲) RS は ZK との通信が維持できないと⾃自ら停⽌止
最⼤大コネクション数
hbase.zookeeper.property.maxClientCnxns
•
•
•
•
ヘルスチェック
•
•
36
CDH4 のデフォルト値は 300
CDH3 では 30 だったので設定ミスに注意すること
300 -‐‑‒ 1000 の範囲で調整する
hbase
hbck
-‐details
2>&1
|
tee
filename.txt
echo
"scan
'.META.'"
|
hbase
shell
>
META-‐output.txt
- 38. 運⽤用時の注意点:HBase編
•
実際にあった話
•
原因 (ジョブA)
•
•
•
•
原因 (ジョブB)
•
•
•
•
RS 間でネットワーク障害が発⽣生し、ZK への接続に失敗
その結果、RS が停⽌止
RS が停⽌止したことで、MR のタスクも失敗
教訓
•
38
RS でスワップが発⽣生し、ZK への接続に失敗
その結果、RS が停⽌止
RS が停⽌止したことで、MR のタスクも失敗
表⾯面的な事象は同じでも、根本原因はまったく異異なっていた。
さらに、クラスタ全体を監視しなければ特定できない問題
だった
- 44. We
are
Hiring!
•
Clouderaは貴⽅方を求めています!!
•
ソリューションアーキテクト
•
•
カスタマーオペレーションズエンジニア
(サポート)
•
•
•
Hadoopを使ったコンサルティングやモデリング
世界中のお客様のHadoopを守る!
インストラクター
セールス
興味のある⽅方は
info-‐jp@cloudera.com
にご連絡下さい!
44