HDFS Supportaiblity Improvements

HDFS におけるサポータビリティ (保守性) の
改善について
Daisuke Kobayashi

2 © Cloudera, Inc. All rights reserved.
自己紹介
• 小林大輔 (d1ce__)
• Cloudera 入社 7 年目
• Hadoop エコシステムのテクニカルサポート
• 社内のエンジニアへの技術トレーニング、エスカレーション対応

対象となる聴講者
• HDFS を運用している人
• HDFS を運用する予定がある人
• HDFS のベンダーサポートがやっていることに興味がある人

今日話さないこと
• HDFS パフォーマンスチューニングの話
• HDFS アーキテクチャの話
• Erasure Coding の話
• Federation の話
• Ozone の話

今日話すこと
• なぜサポータビリティについて考えるのか
• HDFS のサポータビリティ向上の紹介
• Cloudera サポートで取り組んでいること
資料は後日公開予定です

© Cloudera, Inc. All rights reserved.
なぜサポータビリティについて考えるのか

サポータビリティ
https://en.wikipedia.org/wiki/Serviceability_(computer)
• 拙訳
• 運用担当者が、製品のインストール、設定、監視を行い、問題を特定し、
根本原因特定のために障害をデバッグし、サービス提供するために
ハードウェアあるいはソフトウェアのメンテナンスを行えること

システムは運用・障害から逃れられない
• 運用者視点
• 問題が起こりにくい製品が望ましいが、、、
• 問題が起きたとしても解決までの時間が短ければ、システムの信頼性も向上する
• ベンダーサポート (開発) 視点
• 運用性の向上や解決時間の短縮は、サポートや製品の満足度向上につながる

サポータビリティを向上するとは・・・
• 障害が起こりにくい製品
• 障害発生時にトラブルシューティングしやすい製品
にするということ

サポータビリティ向上のためのアクション
• 問題が発生しやすい機能を改善する
• トラブルシューティングしやすい環境を整える
• 調査に必要な管理コマンドの用意
• わかりやすいログメッセージ
• ドキュメントの整備
• 適切なメトリクス

HDFS のサポータビリティについて
• HDFS の障害は影響範囲が大きい
• オンプレミス環境でビッグデータ処理を行う上でデファクトスタンダードの分散ストレージ
• HDFS が [止まる, 遅い] と全てのアプリケーションに影響が出る
• サポートでは顧客によって環境がまるで違う
• バージョンは？適用済みのパッチは？ノード数は？
• ファイル数やブロック数は？ハンドラの数は？
• そもそも顧客が知らない
• いろんなワークロードを流していると、管理者が全てを把握するのは難しい
• どのログに着目すればいいのかを判断するのに、ある程度の経験値が求められる
• サポータビリティの向上はサポート、開発チームにとって最優先事項

HDFS のサポータビリティについて
どこで改善するか・・・
1. HDFS の機能として改善を実装？
2. Cloudera Manager などの管理ソフトでカバー？
3. それ以外: 社内ツールとして実装、運用？

NameNode の機能によるサポータビリティ向上例

NameNode Client RPC の問題
背景
• NameNode はクライアントからのリクエストを単一の FIFO キューに入れる
• あるユーザーが一度に大量のリクエストを送ると、他のユーザーからの
リクエストの処理が遅延する
https://www.ebayinc.com/stories/blogs/tech/quality-of-service-in-hadoop/

TopUserOpCounts – 誰がキューを食いつぶしているのか？
• HDFS-6982 で追加されたメトリクス
• クライアントから NameNode へのオペレーションをトラッキングする
Hadoop:service=NameNode,name=FSNamesystemState::TopUserOpCounts

FairCallQueue - Client RPC の公平なキューイング
• ユーザー毎のリクエストに優先度をつけ、リクエストの処理が特定の
ユーザーに偏らないようにキューイング、処理する (HADOOP-9640)
• デフォルトで無効

FairCallQueue - 登場人物
• スケジューラ - RpcScheduler (DecayRpcScheduler)
• キュー – FairCallQueue
• マルチプレクサ - Multiplexer (WeightedRoundRobinMultiplexer)
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/site/markdown/FairCallQueue.md

• 各ユーザーからのリクエストにランクづけをし、優先度ごとに
4 つのキューに割り当てる (5秒毎に更新)
• リクエストが多いユーザーの優先度は低く、リクエストが
少ないユーザーの優先度は高く設定
• 全体の 50% のリクエストを占めているユーザーは最低
優先度のキューへ
• 全体の 25% から 50% のリクエストを占めているユーザー
は二番目に優先度が低いキューへ
• 全体の 12.5% から 25% のリクエストを占めているユーザーは
二番目に優先度が高いキューへ
• その他の全てのユーザーのリクエストは一番優先度が
高いキューへ
• リクエストを割り当てるキューが満杯になるとバックオフできる

• デフォルトで 4 つあるキューは、重み付けされている
• 各キューは従来の FIFO で実装されている

• キューからリクエストを取り出し、ハンドラに渡す
• 優先度の高いキューから順に、8, 4, 2, 1 ずつリクエストを取り出して
処理させる

DataNode の機能によるサポータビリティ向上例 1

DataNode のメンテナンスモード
背景
• ホストのメンテナンスを実施したい
• OS アップグレード
• セキュリティパッチの適用など
• 従来のメジャーなやり方はデコミッション
• 全てのレプリカを他ノードに逃すため時間がかかる（日オーダー）
• 単に DataNode を停止すると 10 分 30 秒後に NameNode が複製を始める
• 10 分 30 秒の間隔を広げれば良い？
• NameNode の再起動が必要
• 設定を戻し忘れるリスクもある

• デコミッションしなくても、一時的に DataNode をクラスタから
切り離すことができるようになった (HDFS-7877)
NameNode
1
2
3
4
5
0
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4

NameNode
1
2
3
4
5
0
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
{
"hostName": "dn1.cloudera.com",
"Port": "50010",
"adminState": "IN_MAINTENANCE",
"maintenanceExpireTimeInMS": 1492543534000
}
DataNode名
待機時間:1時間
(エポックタイム)
dn1 dn2
dn3 dn4

NameNode
1
2
3
4
5
0
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
{
"Port": "50010",
}
hdfs dfsadmin -refreshNodes
dn1 dn2
dn3 dn4

NameNode
1
2
3
4
5
0
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4
{
"Port": "50010",
}
dn1を1時間
メンテナンスモード
にします

NameNode
1
2
3
4
5
0
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4
{
"Port": "50010",
}
1時間以上経過するとNameNodeは
dn1のレプリカを別ノードに複製
し始める(通常の動作)

NameNode
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4
1時間以内にメンテが終わったら...
1
2
3
4
5
0

NameNode
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4
{
"Port": "50010",
"adminState": ”NORMAL",
}
1
2
3
4
5
0

NameNode
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4
{
"Port": "50010",
}
hdfs dfsadmin -refreshNodes
1
2
3
4
5
0

NameNode
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4
{
"Port": "50010",
}
1
2
3
4
5
0
dn1のメンテナンス
モードを解除します

NameNode
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4
1
2
3
4
5
0
めんどくさい！

NameNode
1
2
9
4
7
0
5
6
7
8
9
0
7
8
3
4
5
6
dn1 dn2
dn3 dn4
1
2
3
4
5
0それCloudera Managerで
できるよ！

一連の操作を全て自動でやってくれる
https://www.cloudera.com/documentation/enterprise/5-15-x/topics/cm_mc_host_maint.html

DataNode の機能によるサポータビリティ向上例 2

SendPacketDownstreamAvgInfo - パイプライン DataNode のメトリクス
• パイプラインの最後の DataNode への転送時間をトラッキング(HDFS-10917)
• 全ての DataNode は、パイプラインの最後から二番目となった時に
最後の DataNode への転送にかかった時間を移動平均で記録
dn1 dn2 dn3
dn2はdn3への
転送時間を記録
"name" : "Hadoop:service=DataNode,name=DataNodeInfo",
"SendPacketDownstreamAvgInfo" : "{
"[172.31.112.242:9864]RollingAvgTime":0.8711560381546584,
"[172.31.113.53:9864]RollingAvgTime":0.4051608579088472}",
自身以外の
DataNode

周辺ツールでサポータビリティを向上する
〜 Cloudera サポートで取り組んでいること〜

診断データの解析
• Cloudera Manager が収集する診断データを解析する社内ツールの紹介
• 診断データには何が含まれているか
• ホスト名、IPアドレス
• 各サービスのログ、設定、使用しているバージョンとパッチ番号
• などなど https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_data_collection.html

• 設定レビュー例
• NameNode や DataNode には独立したディスクが割り当てられているか確認
• 平均ファイルサイズの確認、small files problem が発生していないか
• 一定以上のデータ量になると、スナップショットをとっているか確認

• ログ出力の解析例
• o.a.h.hdfs.server.datanode.DataNode. Slow flushOrSync took
• OS キャッシュあるいはディスクへの書き込みに問題がある可能性

• o.a.h.hdfs.server.datanode.ReplicaNotFoundException. Replica not found for BP
• バランサーが実行されていたり、アクセス中に他のユーザーからファイルが削除された可能性

• o.a.h.security.Groups. Potential performance problem
• Active Directory などの ID 管理製品のパフォーマンスに影響されている可能性

まとめ
• サポータビリティの重要性について説明しました
• HDFS のサポータビリティ向上について三つの観点から紹介しました
• HDFS の機能自体の改善
• Cloudera Manager で HDFS の機能をカバー
• 周辺ツールで HDFS が提供する情報の解析
• HDFS の機能を使いこなして、Happy HDFS ライフを！

HDFS Supportaiblity Improvements

More Related Content

What's hot

Similar to HDFS Supportaiblity Improvements

More from Cloudera Japan

HDFS Supportaiblity Improvements

Editor's Notes