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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to HDFS Supportaiblity Improvements

Similar to HDFS Supportaiblity Improvements (20)

More from Cloudera Japan

More from Cloudera Japan (20)

HDFS Supportaiblity Improvements

Editor's Notes