Azure HDInsight でサポートされている高可用性サービス

分析コンポーネントに最適な可用性レベルを提供するために、HDInsight は、重要なサービスの高可用性 (HA) を保証するための独自のアーキテクチャを使用して開発されました。 このアーキテクチャの一部のコンポーネントは、自動フェールオーバーを提供するために Microsoft が開発しました。 その他のコンポーネントは、特定のサービスをサポートするためにデプロイされる標準の Apache コンポーネントです。 この記事では、HDInsight の HA サービス モデルのアーキテクチャ、HDInsight で HA サービスのフェールオーバーをサポートする方法、および他のサービス中断から復旧するためのベストプラクティスについて説明します。

高可用性インフラストラクチャ

HDInsight では、次の 4 つのプライマリ サービスが、自動フェールオーバー機能を備えた高可用性となるように、カスタマイズされたインフラストラクチャが提供されます。

• Apache Ambari サーバー
• Apache YARN 用アプリケーション タイムライン サーバー
• Hadoop MapReduce 用ジョブ履歴サーバー
• Apache Livy

このインフラストラクチャは、多数のサービスとソフトウェア コンポーネントで構成され、その一部は Microsoft によって設計されています。 次のコンポーネントは、HDInsight プラットフォームに固有です。

• スレーブ フェールオーバー コントローラー
• マスター フェールオーバー コントローラー
• スレーブ高可用性サービス
• マスター高可用性サービス

また、他の高可用性サービスもあり、これらはオープンソースの Apache 信頼性コンポーネントによりサポートされています。 次のコンポーネントも HDInsight クラスターに存在します。

• Hadoop ファイル システム (HDFS) の NameNode
• YARN ResourceManager
• HBase Master

以下のセクションでは、これらのサービスの連携について詳しく説明します。

HDInsight の高可用性サービス

Microsoft では、HDInsight クラスターの次の表に示す 4 つの Apache サービスのサポートを提供しています。 Apache のコンポーネントでサポートされている高可用性サービスと区別するために、これらは "HDInsight HA サービス" と呼ばれます。

アーキテクチャ

各 HDInsight クラスターには、アクティブ モードとスタンバイ モードそれぞれに 2 つのヘッドノードがあります。 HDInsight HA サービスはヘッドノードでのみ実行されます。 これらのサービスは、常にアクティブなヘッドノードで実行され、スタンバイ ヘッドノードで停止されメンテナンス モードにされる必要があります。

HA サービスの正しい状態を維持し、高速フェールオーバーを実現するために、HDInsight では Apache ZooKeeper を利用しています。これは分散型アプリケーションの調整サービスであり、アクティブなヘッドノードの選択を行います。 HDInsight では、いくつかのバックグラウンド Java プロセスもプロビジョニングされます。これにより、HDInsight HA サービスのフェールオーバー手順が調整されます。 これらのサービスは、マスター フェールオーバー コントローラー、スレーブ フェールオーバー コントローラー、つまり "master-ha-service"、と "slave-ha-service" です。

Apache ZooKeeper

Apache ZooKeeper は、分散型アプリケーション用の高パフォーマンスの調整サービスです。 実稼働環境では、ZooKeeper は通常、レプリケート モードで実行されます。このモードでは、ZooKeeper サーバーのレプリケートされたグループがクォーラムを形成します。 各 HDInsight クラスターには、3 つの ZooKeeper サーバーがクォーラムを形成できるようにする 3 つの ZooKeeper ノードがあります。 HDInsight の 2 つの ZooKeeper クォーラムが互いに並列に実行されています。 一方のクォーラムによって、HDInsight HA サービスを実行するクラスター内のアクティブなヘッドノードが決定されます。 もう一方のクォーラムを使用して、Apache によって提供される HA サービスが調整されます。詳細については、後のセクションで説明します。

スレーブ フェールオーバー コントローラー

スレーブ フェールオーバー コントローラーは、HDInsight クラスター内のすべてのノードで実行されます。 このコントローラーは、各ノードで Ambari エージェントと "slave-ha-service" を起動する役割を担います。 アクティブなヘッドノードに関して最初の ZooKeeper クォーラムが定期的に照会されます。 アクティブなヘッドノードとスタンバイ ヘッドノードが変更されると、スレーブ フェールオーバー コントローラーは次のステップを実行します。

1. ホスト構成ファイルを更新します。
2. Ambari エージェントを再起動します。

"slave-ha-service" は、スタンバイ ヘッドノード上の HDInsight HA サービス (Ambari サーバーを除く) を停止する役割を担います。

マスター フェールオーバー コントローラー

マスター フェールオーバー コントローラーは、両方のヘッドノードで実行されます。 どちらのマスター フェールオーバー コントローラーも、最初の ZooKeeper クォーラムと通信して、アクティブなヘッドノードとして実行されているヘッドノードを指名します。

たとえば、ヘッドノード 0 のマスター フェールオーバー コントローラーが選択される場合、次の変更が行われます。

1. ヘッドノード 0 がアクティブになります。
2. マスター フェールオーバー コントローラーにより、ヘッドノード 0 で Ambari サーバーと "master-ha-service" が起動されます。
3. その他のマスター フェールオーバー コントローラーにより、ヘッドノード 1 で Ambari サーバーと "master-ha-service" が停止されます。

master-ha-service は、アクティブなヘッドノードでのみ実行されます。HDInsight HA サービス (Ambari サーバーを除く) がスタンバイ ヘッドノードで停止され、アクティブなヘッドノードで起動されます。

フェールオーバー プロセス

ヘルス モニターは、マスター フェールオーバー コントローラーと共に各ヘッドノードで実行され、ハートビート通知が ZooKeeper クォーラムに送信されます。 このシナリオでは、ヘッドノードは HA サービスと見なされます。 ヘルス モニターにより、各高可用性サービスが正常であるかどうか、およびリーダーシップの選択に参加する準備ができているかどうかが確認されます。 そうである場合、このヘッドノードは選択に加えられます。 そうでない場合は、再度準備が整うまで選択を停止します。

(前のアクティブ ノードで障害が発生した場合などに) スタンバイ ヘッドノードが選択されてアクティブになると、そのマスター フェールオーバー コントローラーにより、そのノード上のすべての HDInsight HA サービスが開始されます。 マスター フェールオーバー コントローラーにより、他のヘッドノードでこれらのサービスの停止が行われます。

サービスがダウンしている、異常な状態など、HDInsight HA サービスのエラーの場合、マスター フェールオーバー コントローラーでは、ヘッドノードの状態に応じてサービスを自動的に再起動または停止する必要があります。 ユーザーが、両方のヘッド ノードで HDInsight HA サービスを手動で起動することはできません。 代わりに、自動または手動のフェールオーバーを許可して、サービスを回復できるようにします。

不注意による手動介入

HDInsight HA サービスは、アクティブなヘッドノードでのみ実行され、必要に応じて自動的に再起動されます。 個々の HA サービスには独自のヘルス モニターがないため、個々のサービスのレベルでフェールオーバーをトリガーすることはできません。 フェールオーバーは、サービス レベルではなく、ノード レベルで保証されます。

既知の問題

• スタンバイ ヘッドノードで HA サービスを手動で開始すると、次のフェールオーバーが発生するまで停止しません。 HA サービスが両方のヘッドノードで実行されている場合に発生する可能性がある問題には次のものがあります: Ambari UI にアクセスできない、Ambari でエラーが発生する、YARN、Spark、Oozie のジョブが停止する可能性がある。

• アクティブなヘッドノードで HA サービスが停止すると、次のフェールオーバーが発生するか、マスター フェールオーバー コントローラー/master-ha-service が再開されるまで、再起動されません。 アクティブなヘッドノードで 1 つ以上の HA サービスが停止した場合、特に Ambari サーバーが停止した場合は、Ambari UI にアクセスできず、YARN、Spark、Oozie のジョブ エラーなど、他の問題が発生する可能性があります。

Apache の高可用性サービス

Apache では、HDFS NameNode、YARN ResourceManager、および HBase Master の高可用性を提供し、これは HDInsight クラスターでも使用できます。 HDInsight HA サービスとは異なり、これらは ESP クラスターでサポートされています。 Apache HA サービスでは、2 番目の ZooKeeper クォーラム (前のセクションで説明) と通信して、アクティブ/スタンバイ状態を選択し、自動フェールオーバーを実行します。 以下のセクションでは、これらのサービスのしくみについて詳しく説明します。

Hadoop 分散ファイル システム (HDFS) の NameNode

Apache Hadoop 2.0 以降に基づく HDInsight クラスターでは、NameNode 高可用性を提供します。 ヘッドノードで実行されている NameNode は 2 つあり、自動フェールオーバー用に構成されています。 NameNode では、"ZKFailoverController" を使用して、ZooKeeper と通信し、アクティブ/スタンバイ状態を選択します。 両方のヘッドノードで "ZKFailoverController" が実行され、マスター フェールオーバー コントローラーと同じように動作します。

2 番目の ZooKeeper クォーラムは、最初のクォーラムから独立しているため、アクティブな NameNode が、アクティブなヘッドノードで実行されない可能性があります。 アクティブな NameNode が動作していない、または異常な状態にある場合は、スタンバイ NameNode が選択され、アクティブになります。

YARN ResourceManager

Apache Hadoop 2.4 以降に基づく HDInsight クラスターでは、YARN ResourceManager の高可用性をサポートします。 rm1 と rm2 の 2 つの ResourceManager があり、それぞれヘッドノード 0 とヘッドノード 1 で実行されています。 NameNode と同様、YARN ResourceManager も自動フェールオーバー用に構成されています。 現在のアクティブな ResourceManager がダウンしたり応答しなくなったりすると、別の ResourceManager がアクティブになるように自動的に選択されます。

YARN ResourceManager では、その埋め込み "ActiveStandbyElector" がエラー検出とリーダー選択に使用されます。 HDFS NameNode とは異なり、YARN ResourceManager は個別の ZKFC デーモンを必要としません。 アクティブな ResourceManager により、その状態が Apache ZooKeeper に書き込まれます。

YARN ResourceManager の高可用性は、NameNode やその他の HDInsight HA サービスからは独立しています。 アクティブな ResourceManager がアクティブなヘッドノード、またはアクティブな NameNode が実行されているヘッドノードで実行されない可能性があります。 YARN ResourceManager の高可用性の詳細については、「ResourceManager の高可用性」を参照してください。

HBase Master

HDInsight HBase クラスターでは、HBase Master 高可用性がサポートされます。 ヘッドノードで実行される他の HA サービスとは異なり、HBase Master は 3 つの ZooKeeper ノードで実行されます。そのうちの 1 つがアクティブなマスター、他の 2 つがスタンバイです。 NameNode と同様に、HBase Master では、リーダー選択のために Apache ZooKeeper との調整が行われ、現在のアクティブなマスターに問題がある場合は自動フェールオーバーが行われます。 アクティブな HBase Master は、常に 1 つだけ存在します。

次のステップ

• HDInsight における Apache Hadoop クラスターの可用性と信頼性
• Azure HDInsight 仮想ネットワーク アーキテクチャ