HDFS高可用性記事抄訳

hdfs

HDFS HA 記事の抄訳

諸般の事情で下記コンテンツを訳したので貼っておきます。
https://docs.cloudera.com/documentation/enterprise/latest/topics/cdh_hag_hdfs_ha_intro.html#topic_2_1

実装

Cloudera ManagerとCDHは、HAの実装にクォーラムベースのストレージをサポートしています。

クォーラムベースのストレージとは、QJM(Quorum Journal Manager)を使用するHAの実装を指します。

この実装では、スタンバイNameNodeがアクティブなnameNodeとステートの同期を維持するために、JournalNodeと呼ばれる別のデーモンのグループと通信します。アクティブの NameNodeによって名前空間の変更が行われると、過半数のJournalNodeに変更のログが永続的に記録されます。スタンバイNameNodeはJournalNodeから編集ログを読み込むことができ、編集ログの変更を常にチェックしています。スタンバイノードは編集ログを確認すると、それを自身の名前空間に適用します。ファイルオーバーが発生した場合、スタンバイNameNodeは自信をアクティブな状態に昇格する前に、JournalNodeから全ての編集ログを読み取ることができます。これにより、フェイルオーバーが発生する前に名前空間の状態は完全に同期されます。

素早いフェイルオーバーを提供するためには、スタンバイNameNodeがクラスター内のブロックの場所に関する最新情報を持っていることも必要です。これを実現するためには、DataNodeが両方のNameNodeの場所を使用して構成され、ブロックのロケーション情報とハートビートの両を送信します。

HAクラスターが正しく動作するにはどちらか一つのNameNodeのみがアクティブであることが重要です。そうでなければ、名前空間の状態が2つの間で急激に分断し、データの損失やそれ以外の誤った結果が生じる危険性があります。このプロパティを保証し、いわゆるスプリットブレインのシナリオを避けるために、JournalNodeは一度に1つのNameNodeが書き手になることを許可します。アクティブになるNameNodeは、単にJournalNodeへの書き込みの役割を引き継ぎます。これにより他方のNameNodeがアクティブな状態を継続できなくなり、新しいアクティブなNameNodeが安全にフェイルオーバーできるようになります。

自動フェイルオーバー

自動フェイルオーバーは、HDFSの2つの追加コンポーネント、ZooKeeper クォーラムとZKFailoverControllerプロセス (ZKFC)に依存しています。Cloudera Manager では、ZKFC プロセスは HDFS Failover Contoller ロールにマップされています。

Apache ZooKeeperは、少しの量の調整データの維持、そのデータの変更をクライアントに通知、およびクライアントの障害を監視するための高可用性サービスです。HDFSの自動フェイルオーバーの実装は、次の機能について ZooKeeper に依存しています。

  • 障害検知: クラスター内の各NameNodeマシンは、ZooKeeper 内で永続セッションを維持します。マシンがクラッシュすると、ZooKeeperセッションは期限切れになり、フェイルオーバーをトリガーする必要があることを他方のNameNodeに通知します。
  • アクティブなNameNodeの選択: ZooKeepr は、アクティブとしてノードを排他的に選択する簡単なメカニズムを提供しています。現在アクティブなNameNodeがクラッシュした場合、他方のノードがZooKeeperに特別な排他ロックを取得し、次にアクティブなNameNodeになる必要があることを示します。

ZKFailoverController (ZKFC) は、NameNode の状態も監視および管理する ZooKeeper クライアントです。NameNode を実行する各ホストでは ZKFC も実行します。ZKFC は以下を担当します。

  • ヘルス監視: ZKFC はヘルスチェックコマンドを使用して、定期的にローカルのNameNodeにコンタクトします。NameNodeが正常なステータスで即座に応答する限り、ZKFC はNameNode が正常であるとみなします。NameNodeがクラッシュしたりフリーズしたり、あるいは異常になった場合、ヘルスモニターは、それを以上としてマークします。
  • ZooKeeper セッション監視: ローカルのNameNodeが正常な場合、ZKFC は ZooKeeper でオープンしているセッションを維持します。ローカルのNameNodeがアクティブの場合、特別なロックznodeも保持します。このロックは、エフェメラル(一時的な)ノードに対するZooKeeperのサポートを使用します。セッションの有効期限が過ぎると、ロックしたノードは自動的に削除されます。
  • ZooKeeperベースの選択: ローカルのNameNodeが正常であり、現在ロックznodeを保持している他方のNameNodeがないとZKFCが判断した場合、ZKFC???は自身がロックを獲得しようとします。ロックの取得に成功した場合は「選挙に勝った」ことになり、フェイルオーバーを実行してローカルのNameNodeをアクティブにします。フェイルオーバーのプロセスは、上記の手動フェイルオーバーと似ています。まず、必要に応じて以前のアクティブがフェンスされ、次にローカルのNameNodeがアクティブな状態に遷移します。

HDFS HA に関する一般的な質問

"Operation category READ/WRITE is not supported in state standby" というメッセージはどういう意味か?

HAが有効化されたクラスターでは、DFS クライアント(HDFSのクライアント)は、特定の時点でどのNameNodeがアクティブかを事前に知ることができません。そのため、クライアントがNameNodeにアクセスし、たまたまスタンバイになった場合、読み込みまたは書き込み操作は拒否されて、このメッセージがログに記録されます。その後、クライアントは自動的に他方のNameNodeに接続して操作を再試行します。クラスターに1つのアクティブNameNodeと1つのスタンバイNameNodeが有る限り、このメッセージは無失しても問題ありません。
アプリケーションが常に1つのNameNodeのみと通信するように設定されている場合、このメッセージは、アプリケーションが読み込み/書き込み操作に失敗しているということを示しています。このような状況では、クラスターのHA設定を使用するようにアプリケーションを変更する必要があります。JIRAのHDFS-3447では、ログのノイズを減らすためにこのメッセージ(と同様のメッセージ)の重要度をDEBUGに下げることを扱っていますが、現時点ではまだ未解決です。

コメント