HDFS Supportaiblity Improvements
Mar. 15, 2019•0 likes•2,597 views
Download to read offline
Report
Engineering
http://hadoop.apache.jp/hcj2019-program での講演資料です
Cloudera JapanFollow
More Related Content
What's hot
Kuduを調べてみた #dogenzakaltToshihiro Suzuki
Apache Impalaパフォーマンスチューニング #dbts2018Cloudera Japan
Cloudera Manager 5 (hadoop運用) #cwt2013Cloudera Japan
「新製品 Kudu 及び RecordServiceの概要」 #cwt2015Cloudera Japan
CDHの歴史とCDH5新機能概要 #at_tokubenCloudera Japan
C5.2 (Cloudera Manager + CDH) アップデート #cwt2014Cloudera Japan
![[db tech showcase Tokyo 2016] A32: Oracle脳で考えるSQL Server運用 by 株式会社インサイトテクノロジー...](https://cdn.slidesharecdn.com/ss_thumbnails/tehahj7vqmsswpgrzrq6-signature-4c7632456c9c538ff9d2a30431910153be9e17d570b88fac06692ab02f11f222-poli-160725043205-thumbnail.jpg?width=1600&height=908&fit=bounds)
Similar to HDFS Supportaiblity Improvements
基礎から学ぶ超並列SQLエンジンImpala #cwt2015Cloudera Japan
Cloudera Manager4.0とNameNode-HAセミナー資料Cloudera Japan
Troubleshooting Using Cloudera Manager #cwt2015Cloudera Japan
Cloudera大阪セミナー 20130219Cloudera Japan
Open stack reference architecture v1 2Dell TechCenter Japan
HDFS Router-based federationNTT DATA OSS Professional Services
More from Cloudera Japan
機械学習の定番プラットフォームSparkの紹介Cloudera Japan
分散DB Apache Kuduのアーキテクチャ DBの性能と一貫性を両立させる仕組み 「HybridTime」とはCloudera Japan
Cloudera のサポートエンジニアリング #supennightCloudera Japan
Train, predict, serve: How to go into production your machine learning modelCloudera Japan
Apache Kuduを使った分析システムの裏側Cloudera Japan
先行事例から学ぶ IoT / ビッグデータの始め方Cloudera Japan
Recently uploaded
onewedge_companyguideONEWEDGE1
今さら聞けない人のためのDevOps超入門VirtualTech Japan Inc./Begi.net Inc.
爆速！DBチューニング超入門 〜DB性能の基礎とGPU活用による高速化〜VirtualTech Japan Inc./Begi.net Inc.
OSCのこれまでを振り返るとしたらこんな感じ？VirtualTech Japan Inc./Begi.net Inc.
ハッカソン秋の陣.pdfssuser1bc638
限界ORM！BOOTHとギフトとライブラリ【PIXIV MEETUP 2023 LT】RND cpp
HDFS Supportaiblity Improvements
- 1. HDFS におけるサポータビリティ (保守性) の 改善について Daisuke Kobayashi
- 2. 2 © Cloudera, Inc. All rights reserved. 自己紹介 • 小林大輔 (d1ce__) • Cloudera 入社 7 年目 • Hadoop エコシステムのテクニカルサポート • 社内のエンジニアへの技術トレーニング、エスカレーション対応
- 3. 3 © Cloudera, Inc. All rights reserved. 対象となる聴講者 • HDFS を運用している人 • HDFS を運用する予定がある人 • HDFS のベンダーサポートがやっていることに興味がある人
- 4. 4 © Cloudera, Inc. All rights reserved. 今日話さないこと • HDFS パフォーマンスチューニングの話 • HDFS アーキテクチャの話 • Erasure Coding の話 • Federation の話 • Ozone の話
- 5. 5 © Cloudera, Inc. All rights reserved. 今日話すこと • なぜサポータビリティについて考えるのか • HDFS のサポータビリティ向上の紹介 • Cloudera サポートで取り組んでいること 資料は後日公開予定です
- 6. © Cloudera, Inc. All rights reserved. なぜサポータビリティについて考えるのか
- 7. 7 © Cloudera, Inc. All rights reserved. サポータビリティ https://en.wikipedia.org/wiki/Serviceability_(computer) • 拙訳 • 運用担当者が、製品のインストール、設定、監視を行い、問題を特定し、 根本原因特定のために障害をデバッグし、サービス提供するために ハードウェアあるいはソフトウェアのメンテナンスを行えること
- 8. 8 © Cloudera, Inc. All rights reserved. システムは運用・障害から逃れられない • 運用者視点 • 問題が起こりにくい製品が望ましいが、、、 • 問題が起きたとしても解決までの時間が短ければ、システムの信頼性も向上する • ベンダーサポート (開発) 視点 • 運用性の向上や解決時間の短縮は、サポートや製品の満足度向上につながる
- 9. 9 © Cloudera, Inc. All rights reserved. サポータビリティを向上するとは・・・ • 障害が起こりにくい製品 • 障害発生時にトラブルシューティングしやすい製品 にするということ
- 10. 10 © Cloudera, Inc. All rights reserved. サポータビリティ向上のためのアクション • 問題が発生しやすい機能を改善する • トラブルシューティングしやすい環境を整える • 調査に必要な管理コマンドの用意 • わかりやすいログメッセージ • ドキュメントの整備 • 適切なメトリクス
- 11. 11 © Cloudera, Inc. All rights reserved. HDFS のサポータビリティについて • HDFS の障害は影響範囲が大きい • オンプレミス環境でビッグデータ処理を行う上でデファクトスタンダードの分散ストレージ • HDFS が [止まる, 遅い] と全てのアプリケーションに影響が出る • サポートでは顧客によって環境がまるで違う • バージョンは？適用済みのパッチは？ノード数は？ • ファイル数やブロック数は？ハンドラの数は？ • そもそも顧客が知らない • いろんなワークロードを流していると、管理者が全てを把握するのは難しい • どのログに着目すればいいのかを判断するのに、ある程度の経験値が求められる • サポータビリティの向上はサポート、開発チームにとって最優先事項
- 12. 12 © Cloudera, Inc. All rights reserved. HDFS のサポータビリティについて どこで改善するか・・・ 1. HDFS の機能として改善を実装？ 2. Cloudera Manager などの管理ソフトでカバー？ 3. それ以外: 社内ツールとして実装、運用？
- 13. © Cloudera, Inc. All rights reserved. NameNode の機能によるサポータビリティ向上例
- 14. 14 © Cloudera, Inc. All rights reserved. NameNode Client RPC の問題 背景 • NameNode はクライアントからのリクエストを単一の FIFO キューに入れる • あるユーザーが一度に大量のリクエストを送ると、他のユーザーからの リクエストの処理が遅延する https://www.ebayinc.com/stories/blogs/tech/quality-of-service-in-hadoop/
- 15. 15 © Cloudera, Inc. All rights reserved. TopUserOpCounts – 誰がキューを食いつぶしているのか？ • HDFS-6982 で追加されたメトリクス • クライアントから NameNode へのオペレーションをトラッキングする Hadoop:service=NameNode,name=FSNamesystemState::TopUserOpCounts
- 16. 16 © Cloudera, Inc. All rights reserved. FairCallQueue - Client RPC の公平なキューイング • ユーザー毎のリクエストに優先度をつけ、リクエストの処理が特定の ユーザーに偏らないようにキューイング、処理する (HADOOP-9640) • デフォルトで無効 https://www.ebayinc.com/stories/blogs/tech/quality-of-service-in-hadoop/
- 17. 17 © Cloudera, Inc. All rights reserved. FairCallQueue - Client RPC の公平なキューイング • ユーザー毎のリクエストに優先度をつけ、リクエストの処理が特定の ユーザーに偏らないようにキューイング、処理する (HADOOP-9640) • デフォルトで無効 https://www.ebayinc.com/stories/blogs/tech/quality-of-service-in-hadoop/
- 18. 18 © Cloudera, Inc. All rights reserved. FairCallQueue - 登場人物 • スケジューラ - RpcScheduler (DecayRpcScheduler) • キュー – FairCallQueue • マルチプレクサ - Multiplexer (WeightedRoundRobinMultiplexer) https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/site/markdown/FairCallQueue.md
- 19. 19 © Cloudera, Inc. All rights reserved. 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% のリクエストを占めているユーザーは 二番目に優先度が高いキューへ • その他の全てのユーザーのリクエストは一番優先度が 高いキューへ • リクエストを割り当てるキューが満杯になるとバックオフできる
- 20. 20 © Cloudera, Inc. All rights reserved. FairCallQueue - 登場人物 • スケジューラ - RpcScheduler (DecayRpcScheduler) • キュー – FairCallQueue • マルチプレクサ - Multiplexer (WeightedRoundRobinMultiplexer) • デフォルトで 4 つあるキューは、重み付けされている • 各キューは従来の FIFO で実装されている https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/site/markdown/FairCallQueue.md
- 21. 21 © Cloudera, Inc. All rights reserved. FairCallQueue - 登場人物 • スケジューラ - RpcScheduler (DecayRpcScheduler) • キュー – FairCallQueue • マルチプレクサ - Multiplexer (WeightedRoundRobinMultiplexer) • キューからリクエストを取り出し、ハンドラに渡す • 優先度の高いキューから順に、8, 4, 2, 1 ずつリクエストを取り出して 処理させる https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/site/markdown/FairCallQueue.md
- 22. © Cloudera, Inc. All rights reserved. DataNode の機能によるサポータビリティ向上例 1
- 23. 23 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード 背景 • ホストのメンテナンスを実施したい • OS アップグレード • セキュリティパッチの適用など • 従来のメジャーなやり方はデコミッション • 全てのレプリカを他ノードに逃すため時間がかかる（日オーダー） • 単に DataNode を停止すると 10 分 30 秒後に NameNode が複製を始める • 10 分 30 秒の間隔を広げれば良い？ • NameNode の再起動が必要 • 設定を戻し忘れるリスクもある
- 24. 24 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に 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
- 25. 25 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に 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 { "hostName": "dn1.cloudera.com", "Port": "50010", "adminState": "IN_MAINTENANCE", "maintenanceExpireTimeInMS": 1492543534000 } DataNode名 待機時間:1時間 (エポックタイム) dn1 dn2 dn3 dn4
- 26. 26 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に 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 { "hostName": "dn1.cloudera.com", "Port": "50010", "adminState": "IN_MAINTENANCE", "maintenanceExpireTimeInMS": 1492543534000 } hdfs dfsadmin -refreshNodes dn1 dn2 dn3 dn4
- 27. 27 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に 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 { "hostName": "dn1.cloudera.com", "Port": "50010", "adminState": "IN_MAINTENANCE", "maintenanceExpireTimeInMS": 1492543534000 } dn1を1時間 メンテナンスモード にします
- 28. 28 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に 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 { "hostName": "dn1.cloudera.com", "Port": "50010", "adminState": "IN_MAINTENANCE", "maintenanceExpireTimeInMS": 1492543534000 } 1時間以上経過するとNameNodeは dn1のレプリカを別ノードに複製 し始める(通常の動作)
- 29. 29 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に DataNode をクラスタから 切り離すことができるようになった (HDFS-7877) 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
- 30. 30 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に DataNode をクラスタから 切り離すことができるようになった (HDFS-7877) NameNode 1 2 9 4 7 0 5 6 7 8 9 0 7 8 3 4 5 6 dn1 dn2 dn3 dn4 { "hostName": "dn1.cloudera.com", "Port": "50010", "adminState": ”NORMAL", } 1 2 3 4 5 0
- 31. 31 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に DataNode をクラスタから 切り離すことができるようになった (HDFS-7877) NameNode 1 2 9 4 7 0 5 6 7 8 9 0 7 8 3 4 5 6 dn1 dn2 dn3 dn4 { "hostName": "dn1.cloudera.com", "Port": "50010", "adminState": ”NORMAL", } hdfs dfsadmin -refreshNodes 1 2 3 4 5 0
- 32. 32 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に DataNode をクラスタから 切り離すことができるようになった (HDFS-7877) NameNode 1 2 9 4 7 0 5 6 7 8 9 0 7 8 3 4 5 6 dn1 dn2 dn3 dn4 { "hostName": "dn1.cloudera.com", "Port": "50010", "adminState": ”NORMAL", } 1 2 3 4 5 0 dn1のメンテナンス モードを解除します
- 33. 33 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に DataNode をクラスタから 切り離すことができるようになった (HDFS-7877) 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 めんどくさい！
- 34. 34 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード • デコミッション しなくても、一時的に DataNode をクラスタから 切り離すことができるようになった (HDFS-7877) 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で できるよ！
- 35. 35 © Cloudera, Inc. All rights reserved. DataNode のメンテナンスモード 一連の操作を全て自動でやってくれる https://www.cloudera.com/documentation/enterprise/5-15-x/topics/cm_mc_host_maint.html
- 36. © Cloudera, Inc. All rights reserved. DataNode の機能によるサポータビリティ向上例 2
- 37. 37 © Cloudera, Inc. All rights reserved. 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
- 38. © Cloudera, Inc. All rights reserved. 周辺ツールでサポータビリティを向上する 〜 Cloudera サポートで取り組んでいること 〜
- 39. 39 © Cloudera, Inc. All rights reserved. 診断データの解析 • Cloudera Manager が収集する診断データを解析する社内ツールの紹介 • 診断データには何が含まれているか • ホスト名、IPアドレス • 各サービスのログ、設定、使用しているバージョンとパッチ番号 • などなど https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ag_data_collection.html
- 40. 40 © Cloudera, Inc. All rights reserved. 診断データの解析 • 設定レビュー例 • NameNode や DataNode には独立したディスクが割り当てられているか確認 • 平均ファイルサイズの確認、small files problem が発生していないか • 一定以上のデータ量になると、スナップショットをとっているか確認
- 41. 41 © Cloudera, Inc. All rights reserved. 診断データの解析 • ログ出力の解析例 • o.a.h.hdfs.server.datanode.DataNode. Slow flushOrSync took • OS キャッシュあるいはディスクへの書き込みに問題がある可能性
- 42. 42 © Cloudera, Inc. All rights reserved. 診断データの解析 • ログ出力の解析例 • o.a.h.hdfs.server.datanode.ReplicaNotFoundException. Replica not found for BP • バランサーが実行されていたり、アクセス中に他のユーザーからファイルが削除された可能性
- 43. 43 © Cloudera, Inc. All rights reserved. 診断データの解析 • ログ出力の解析例 • o.a.h.security.Groups. Potential performance problem • Active Directory などの ID 管理製品のパフォーマンスに影響されている可能性
- 44. 44 © Cloudera, Inc. All rights reserved. まとめ • サポータビリティの重要性について説明しました • HDFS のサポータビリティ向上について三つの観点から紹介しました • HDFS の機能自体の改善 • Cloudera Manager で HDFS の機能をカバー • 周辺ツールで HDFS が提供する情報の解析 • HDFS の機能を使いこなして、Happy HDFS ライフを！
- 45. THANK YOU
Editor's Notes
- 小林大輔と言います。Clouderaに入社して七年目になりますが、HDFSやHBaseといったストレージ周りの技術サポートを担当しています。具体的には国内外の同僚からのエスカレーション対応や、トレーニングも行なっています
- まず、この中でHDFSの運用をしている人ってどれぐらいいますか？このセッションで対象としているオーディエンスは、今現在HDFSを運用している人、これから運用する予定の人、そして、我々のようなベンダーサポートがやっていることに興味がある人となります
- 逆に、今日話さないこと、ですけども、NameNodeのスケーリングみたいなパフォーマンスチューニングの話や入門的なアーキテクチャの話はしません。そして、Erasure CodingやFederation、Ozoneの話も一切ありません
- どういうことを話すかというと、HDFSについてある程度ご存知であることを前提に、なぜサポータビリティをテーマにするのかというところから入ろうと思います。で、なぜHDFSのサポータビリティなのか。HDFSのコミュニティがどのように製品改善を進めているかを紹介します。最後に、実際にサポートを提供する現場でどのような取り組みがあるのかを紹介しようと思っています
- それでは、なぜサポータビリティについて考えるのか、ですけども
- サポータビリティ、サービサビリティとも言うみたいですが、Wikipediaからの引用を簡単に訳しますと、サポータビリティとは運用担当者が製品をインストールしたり、設定、監視をして問題を特定したり、原因解明のためにデバッグやメンテナンスを行えること、と言う定義になっています
- もっというと、そこにソフトウェアがある以上、運用や障害から逃れられないのは現時点で紛れもない事実なわけです。となると、運用者の視点では問題が起こらないに越したことはないわけですけれども、問題が起きたとしても解決するまでの時間が短ければシステムの信頼性は向上しますよね。サポータビリティが高ければ、調査をして問題特定までの時間が短縮できるという話です。一方でソフトウェアの開発者、我々のようなベンダーサポートも含め、運用性を向上したり解決時間を短縮できることは、直接サポートや製品の満足度の向上につながることになります。つまり、障害発生時にサポータビリティが高いと、調査がスムーズに進むのでサポータビリティを高めるモチベーションがあるんですね。
- つまり、サポータビリティを向上する、と言うのは障害が起こりにくい製品にすること、そして障害発生時にトラブルシューティングしやすい製品にする、と言うことになります。まあ、当たり前の話ですよね
- では、サポータビリティを向上するために考えられるアクションですが、まずは製品の問題が発生しやすい箇所をアーキテクチャを変えるなりなんなりでどうにかして発生しにくくする、と言うのはあります。トラブルシューティングしやすい環境とはどういうものでしょう。例えば、調査に必要なコマンドを用意したり、ログメッセージをわかりやすいものにする、ステップバイステップで追えるドキュメントを用意したり、メトリクスを出して製品挙動を追いやすいようにする、というアプローチも考えられます
- ではHDFSについても考えてみます。HDFSはオンプレ環境でビッグデータの分散処理を行う上では、デファクトスタンダードといってもいいと思います。いろんなエコシステムのアプリケーションがHDFSを一時的にしろ最終にしろデータ保存先として想定して動いていることに異論はないと思います。つまり、HDFSが止まったり遅くなると、全てのアプリケーションに影響が出ることになります。当然障害報告を受ける我々も、HDFSの障害はクリティカルなことが多く、そのためしょっちゅう急かされたり復旧後の根本原因の追究もよく要求されます。それに、数千単位でクラスタをサポートしていると、お客様によって環境がまるで違います我々がサポートしてる環境はなので、HDFSのサポータビリティを向上するというのは、サポートや開発チームにとって最優先事項なわけですね
- では、具体的にどのようなアプローチで改善するか、ですけれども、当然HDFSの機能として何かしら実装するというのはあります。物によっては、Cloudera Managerなどの管理ソフトでフォローすることでより使いやすくなるということもありますね。また、三つ目ですけれども製品そのものではなく、外部のツールとして作って運用するようなやり方もあります。以降では、それぞれのアプローチについて少しずつ紹介していきたいと思います ここまでで7分
- では、まずはネームノードのサポータビリティ向上例についてみてみましょう
- ネームノードにはRPCサーバーがいて、クライアントからのリクエストをさばいています。デフォルトで8020ポートですね。ここで、RPCサーバーは全てのリクエストを一つのキューに入れる仕組みになってます。ハンドラがある程度の数走ってますんで、ハンドラはキューからリクエストをプルして処理するわけです。キューがFIFOなので、あるユーザーが山のようにリクエストを送ってしまった場合、そのリクエストが処理されるまでそれ以降のユーザーのリクエストっていうのは処理されないことになります。余談ですけれども、ネームノードはクライアントからのアクセスを処理するRPCサーバーと、データノードとかフェイルオーバーコントローラーからのリクエストを処理するRPCサーバーを分離することができます。ここにお集まりの皆さんは、当然二つのRPCサーバーを使い分けてますよね。
- ではこのようなケースでどういったアプローチがあるのかというと、まずはネームノードのメトリクスに出てくるアクセスユーザーに関する傾向をみます。ここで、明らかにアクセス過剰なユーザがいれば、そのユーザーが何をしているのかという確認を進めることで、解消されるかもしれません。一方で、特定のユーザーによる負荷が避けられないケースももちろんあると思います
- そこで実装されたのが、FairCallQueueというリクエストを公平に処理する新しいキューイングの仕組みです
- FairCallQueueにはいくつかの登場人物がいるので紹介します
- 大きく三つで、スケジューラ、キューそのもの、そしてマルチプレクサです
- まずスケジューラですけれども、スケジューラはクライアントからのリクエストをランクづけするために存在しています。優先度ごとに四つのキューに放り込むんですが、5秒ごとにユーザーのランクを更新しています。ざっくりいうと、リクエストの少ないユーザーの優先度を高く、リクエストが多いユーザーの優先度を低くするような動作をします。デフォルトでは、全体の半分のリクエストを占めているユーザーの優先度は最低ランクになります。次は25%から50%のリクエストを占めているユーザー、12.5%から25％、そしてその他の全てのユーザーという順に優先度が高くなっていきます キューサイズはデフォルトで dfs.namenode.handler.count x ipc.server.handler.queue.size (100)。これをだいたい四分割する
- 次にFairCallQueueですが、これはもうFIFOのキューがデフォルトで四つ並んでるだけですね
- 最後にマルチプレクサですけども、これがキューからリクエストを取り出して、実際に処理をするハンドラに渡す役割です。優先度の高いキューから順に重み付けしてリクエストを取り出して処理させていくわけですね。この実装により、悪質、意図がなかったとしても結果として悪質なリクエストを送ってしまっているユーザーによってネームノードがサチらないようにすることが期待できると思います。設定方法の詳細は、リンクを貼ってあるドキュメントを参考にしてみてください。ここまでで11分
- さて、次にDataNodeの方ではどのようにサポータビリティが向上しているのかをみてみたいと思います
- DataNodeに追加されたメンテナンスモードをご紹介します。例えばホストのメンテナンスをしたいようなケースを考えてみてください。OSのアップグレードや、セキュリティパッチの適用などがあると思うんですが、従来の典型的、安全なやり方としてはデコミッションです。しかし皆さんご存知と思いますが、デコミッション は全てのレプリカを他のノードに逃す必要があるので、かなりの時間がかかります。デコミッション のパフォーマンスはある程度チューニングできるんですが、それでも時間はかかってしまいます。単にDataNodeを停止するとどうなるかというと、10分30秒後にNameNodeがそのDataNodeを死んだとみなしてレプリカの複製を始めてしまいます。じゃあ、この間隔を延ばせばいいんですけれども、NameNodeの再起動が必要だったり、その後設定を戻し忘れるリスクもありますよね。
- そこで導入されたのがメンテナンスモード、メンテナンスステートとも呼びますが、DataNodeに新しい状態を追加するものです。これにより、デコミッション しなくてもブロックを余計に複製しなくてもクラスタから一時的に切り離せるようになりました
- まず、ユーザーはどのDataNodeをメンテナンスモードにするのかを定義するJSONファイルを用意します。ここには、DataNode名や状態の名前、IN_MAINTENANCEですね、そしてどれぐらいの時間切り離しておくのかをエポックタイムで定義します
- で、これを元にNameNodeにrefreshNode コマンドを発行します
- NameNodeはコマンドを受け取ると、対象のDataNode、ここではdn1ですが、メンテナンスモードに移行します。この時、原則としてブロックの複製は発生しません。複製が発生するケースは、最低限の複製数に満たないブロックがdn1にあった場合に、それを別のノードにコピーするだけです
- もし、メンテナンスモードに移行して1時間以上経過したら、NameNodeはdn1のブロックを別のノードに複製し始めます。ようはデコミッション してる時と同じですね
- 指定した1時間以内にメンテ作業が終わればメンテナンスモードは無事解除できます
- 先ほどのJSONファイルの状態をノーマルに戻して
- refreshNodes を発行すると
- NameNodeはdn1のメンテナンスモードを解除する、と。このような仕組みです
- が、見てわかりますがどう考えてもめんどくさいですよね。
- こういったものは、Cloudera Managerのような管理ソフトにやらせることで楽に運用できます
- Cloudera Managerを使えば、ホストを選択してメンテナンスモードに移行するというのを選べば今まで説明した操作を全部自動でやってくれます。もちろん、時間の指定も分単位でできるので圧倒的にわかりやすいと思います。こういった形で、HDFSに実装された機能を管理ツール側で補うことで、クラスタの運用性、サポータビリティをよくするように取り組んでいるわけですね。ここまでで17分
- さて、DataNodeの機能としてもう一つ、地味なやつを紹介したいと思います
- それは、書き込みパイプラインで遅くなりがちなDataNodeを特定するために使える新しいメトリクスです。書き込み中のブロックの複製はシリアルに実行されるので、そのどこかでディスク書き込みやネットワーク遅延が発生すると全体に影響を与えるんですよね。で、どこが悪いのかを特定するために明確な基準となる情報がなかったという問題がありました。このメトリクスを見れば、遅いDataNodeが一目瞭然です。具体的には、全てのDataNodeが、自分がパイプラインの最後から二つ目になった時に、最後のDataNodeへの転送時間を記録しておくという仕組みになってます。で、その移動平均がメトリクスに出ますんで、そこを見てやることで遅いDataNodeを特定しやすくなっているというわけです。すごく地味な話なんですが、こういうメトリクスを出せてるかどうかでトラブルシューティングの時間が大きく変わるので、すごく重要でいい機能だと思ってます。ここまでで19分
- さて、HDFSの機能や管理ツールでサポータビリティを向上する例を紹介してきました。製品機能としてできることがある一方で、周辺ツールでトラブルシューティングの手間を補うことができます。ここからは、Clouderaのサポートでどのように障害調査をしているのか、サポータビリティの向上を進めているのかを紹介してみたいと思います
- 我々が日々山のようにくるHDFSの障害調査をする上で使っているのが、診断データというものです。これはCloudera Managerという管理ソフトが自動、あるいは手動で収集してClouderaまで送ってくれるものでして、収集したデータが、社内ではこのように見えています。具体的にどのような情報が含まれているかというと、クラスタの全ホストのホスト名やIPアドレスといった基本情報から、CPUやメモリ、ディスクの情報、シスログなんかも収集しています。また、HDFSやYARNといったエコシステムのログや全ての設定、今使っているバージョンやパッチ番号なんかも収集しています。顧客環境がまるで違うという話をしましたが、診断データの情報をざっと見るだけでどのようなクラスタか、というオーバービューは把握することができます。で、こいつをどう使うかですが、サポータビリティ向上という観点では、二つの側面から動いている自動解析ツールがとても役立っています。設定レビューと、ログの解析ですね
- 例えば、NameNodeやDataNodeに独立したディスクが割り当てられているか、ですとかクラスタ内の平均ファイルサイズの確認をして small files problem が発生していないかを確認してくれます。あるいは、障害が発生しやすい設定がされていないか、JVMのオプションで推奨されないものが設定されていないか、といったレビューも自動で走っています。それに、ある程度のデータ量のクラスタでは、スナップショットがとられているかどうかもチェックしてくれます。万が一オペミスでデータを削除してしまったようなケースは冗談のように思うかもしれませんけど定期的に上がってくる障害報告でして、そのようなケースでもスナップショットを取っていればデータロストは避けられるわけです。なので、スナップショットを取っているかいないかでサポートの負荷が全然違いますので、こういったチェックも行っているわけです。で、この結果はサポートや開発だけじゃなくて、営業SEやコンサルのメンバーも見れるので、お客様とのミーティング中にアドバイスに使ったりもできるわけですね
- 設定の自動レビューの紹介をしましたけど、次はログの自動解析です。これは、これまでのサポートの経験から問題の兆候とみられるログの出力をあらかじめ定義しておいて、それが出ているかどうか、出ていればどれぐらいの頻度なのか、そして、そのログが何を意味するのかを教えてくれる仕組みです。これはもちろん、まだ経験の浅いエンジニアのトラブルシューティングを支援するというのは大きいんですが、ある程度経験を積んだエンジニアでも、調査を急かされていたりストレスの多い環境で調査をしていればどうしても抜けが出てきてしまうんですね。もうこれは人間ですから仕方ないです。いつもであればチェックする項目も、うっかり忘れてしまうことはあると。そのようなヒューマンエラーをカバーするためにこのような自動チェックはすごく役に立っていて、まず最初にざっと眺めるという使い方をしてもいいし、回答を出す前に漏れがないかをチェックするために念押しでチェックするわけです。あるいは、どうしても行き詰った時に自動解析の結果を眺めて、何かヒントがないかを探るという使い方もしてます。この例では、DataNodeがディスクへの書き込みに問題がある可能性があることを示すログが出ている、と。で、それがどのホストで出ているのかというのを示してくれています
- この例では、DataNodeでブロックのレプリカが見つからないという例外を検知しています。この原因は複数考えられるのでそれはまた別途調査が必要なわけですが、どこでどれぐらい出ているのか、というのをとっかかりにして前に進めることができるわけです
- 最後にこちらは問題が発生していなかった、という例ですけれども、検知されなければこのようにPASSと出るので、ああ、これは大丈夫なんだなという切り分けができます。切り分けもトラブルシューティングのステップの一環なので、このような情報はすごく貴重なわけです。このように、HDFSそれ自身ですとか、Cloudera Managerのような管理ツールでやるにはちょっと大変だったり、実装や変更のためのリードタイムを考えるとあまり現実的じゃないようなものは、インターナルのツールとして開発することでサポータビリティの向上を目指しているという話でした。ここまでで26分
- さて、駆け足で紹介してきましたが、最後にまとめです。この講演では、サポータビリティがなぜ重要なのか、について紹介しました。次に、なぜHDFSのサポータビリティに力を入れるのか、具体的にどういったアプローチで向上させているのか、を三つの観点から紹介しました。最後の周辺ツールというのはCloudera社内でのみ使える機能なんですが、その他の機能は今のHDFSやCloudera Managerで使えるようになっているので、もし今運用しているクラスタで使えそうであれば試してみてください。