復元性に優れた Cloud Composer 環境のフェイルオーバー テストを実行する

Cloud Composer 1 | Cloud Composer 2

このページでは、復元性に優れた Cloud Composer 環境のデータベースとクラスタのフェイルオーバー テストを行う方法について説明します。

環境のフェイルオーバー テストでは、データセンターのゾーンの完全な停止がシミュレートされます。このようなシナリオでは、クラスタのゾーン停止とデータベースのゾーン停止が同時に発生する可能性があります。2 つのフェイルオーバー テストを行うことで、復元性に優れた環境でのフェイルオーバーの実行状況と DAG とタスクへの影響を確認できます。

始める前に

• フェイルオーバー テストを行うには、アカウントに次のロールと権限が必要です。

  • composer.environments.update 権限。この権限のあるロールの一覧については、IAM によるアクセス制御をご覧ください。

  • 環境のクラスタで kubectl コマンドを実行するための Kubernetes Engine Cluster 管理者（roles/container.clusterAdmin）ロール。別の方法としては、GKE で Kubernetes RBAC ロールを直接プロビジョニングすることもできます。

• 承認済みネットワークを使用する場合は、GKE クラスタのコントロール プレーン エンドポイントにアクセスできるマシンから kubectl コマンドを実行する必要があります。環境のコントロール プレーン エンドポイントへのアクセスを設定する方法に応じて、いくつかのオプションを使用できます。詳細については、プライベート IP 環境でのコマンドの実行をご覧ください。

環境が正常であることを確認する

データベースと環境のクラスタ フェイルオーバー テストは、必ず正常な環境でのみ行ってください。

環境が正常であることを確認するには:

1. Google Cloud コンソールで [環境] ページに移動します。

   [環境] に移動

2. 環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。

3. [Monitoring] タブに移動します。

4. すべての健全性指標が緑色であることを確認します。

データベース フェイルオーバー テストを実行する

ゾーンの停止をシミュレートするデータベース フェイルオーバー テストは、Google Cloud CLI コマンドを使用したトリガーによって実行できます。たとえば、環境のデータベースが別のゾーンに切り替わるまでの時間を測定できます。

重要: データベース フェイルオーバー テストは、環境のデータベースのみのゾーン停止を表します。ゾーンが停止している間、環境のクラスタも影響を受ける可能性があります。環境のクラスタに対してフェイルオーバー テストを別途実行できます。データベース フェイルオーバー テストは、トラブルシューティングを目的としたものではありません。フェイルオーバー テストでは、環境のデータベース コンポーネントの問題は修正できません。

ご使用の環境でデータベース フェイルオーバー テストを実行するには:

1. 環境が正常であることを確認します。

2. 環境のデータベースのプライマリ ゾーンを取得します。

   gcloud composer environments fetch-database-properties \
       ENVIRONMENT_NAME \
       --location LOCATION
   

   以下を置き換えます。

   • ENVIRONMENT_NAME: Cloud Composer 環境の名前。
   • LOCATION: 環境が配置されているリージョン。

   例:

   gcloud composer environments fetch-database-properties \
       example-environment \
       --location us-central1
   

3. データベース フェイルオーバー テストを開始します。

   gcloud composer environments database-failover \
       ENVIRONMENT_NAME \
       --location LOCATION
   

   以下を置き換えます。

   • ENVIRONMENT_NAME: Cloud Composer 環境の名前。
   • LOCATION: 環境が配置されているリージョン。

   例:

   gcloud composer environments database-failover \
       example-environment \
       --location us-central1
   

4. データベース フェイルオーバー テストが完了するまで待ちます。この処理には最長で 3 分ほどかかる場合があります。

5. 環境のデータベースのプライマリ ゾーンが変更されたことを確認します。

   gcloud composer environments fetch-database-properties \
       ENVIRONMENT_NAME \
       --location LOCATION
   

6. 環境の健全性指標を調べて、環境が正常であることを確認します。

7. フェイルオーバーに使用できるデータベース（composer.googleapis.com/environment/database/available_for_failover）環境指標が True になると、環境のデータベースが別のフェイルオーバーに対する準備が整います。Cloud Monitoring で環境の指標を表示する方法の詳細については、環境をモニタリングするをご覧ください。

環境のクラスタ フェイルオーバー テストを実行する

環境のクラスタに対してフェイルオーバー テストを実行できます。これは、ゾーンの停止をシミュレートします。たとえば、環境が別のゾーンに切り替わるまでの時間を測定できます。

重要: 環境のクラスタ フェイルオーバー テストは、環境のクラスタのみに対してゾーンの停止を表します。ゾーンが停止している間、環境のデータベースも影響を受ける可能性があります。環境のデータベース用のフェイルオーバー テストは個別に実行できます。

環境が正常であることを確認する

テストを開始する前に、環境が正常であることを確認してください。

環境のクラスタの認証情報を構成する

クラスタの認証情報を取得するには:

1. Google Cloud コンソールで [環境] ページに移動します。

   [環境] に移動

2. 環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。

3. [環境の設定] タブに移動します。

4. [クラスタの詳細を表示] をクリックします。

5. [Connect] をクリックします。

6. 表示された Google Cloud CLI コマンドをコピーして実行します。

   次に例を示します。

   gcloud container clusters get-credentials \
     us-central1-exam-db23ee12-gke \
     --region us-central1 \
     --project example-project
   

環境のクラスタを検査する

環境のクラスタ内でワークロードが実行されているゾーンとノードを確認します。この情報は、後でゾーン停止をシミュレーションするために使用します。また、フェイルオーバー テストの実行中にこれらのコマンドを再度実行し、環境のクラスタがフェイルオーバーを実行する方法を確認することもできます。

1. ノードとゾーンを確認します。

   kubectl get nodes \
     -o=custom-columns=NAME:.metadata.name,NODE:.metadata.labels.topology\\.gke\\.io/zone
   

2. Pod を確認します。

   kubectl get pods --all-namespaces \
   -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName \
   --field-selector metadata.namespace!=kube-system
   

3. Pod の詳細情報を表示します。

   kubectl get pods --all-namespaces -o wide \
   --field-selector metadata.namespace!=kube-system
   

ノードをドレインする

停止をシミュレートするゾーンを選択します。データベース フェイルオーバー テストとともにクラスタのフェイルオーバー テストを行う場合は、環境の高可用性 Cloud SQL インスタンスのプライマリ ゾーンを選択することをおすすめします。たとえば、プライマリ Cloud SQL インスタンスが us-central1-a で実行されている場合、最初にデータベース フェイルオーバー テスト、次に us-central1-a でのクラスタのフェイルオーバー テストを行い、us-central1-a ゾーン全体が停止した場合のシミュレーションを行うことができます。

次のコマンドは、特定のゾーンで使用不能になる一連のノードをシミュレートします。指定したゾーン内のノードから Pod が強制排除され、それらのノード上の Pod の再スケジューリングが防止されます。新しい Pod はスケジュールできないため、新しいノードがクラスタに追加されます。

重要: クラスタに追加された新しいノードが障害をシミュレートするゾーンに配置される場合があります。その場合でもフェイルオーバー手順は無効にはなりません。フェイルオーバー手順は、一部のクラスタノードが使用できなくなっても環境が引き続き機能するかどうかをテストします。実際のゾーン障害が発生した場合、GKE では、運用ゾーンに新しいノードが追加されます。

このコマンドは、composer-system 名前空間で実行されるワークロードには影響しません。コマンドの出力に、関連するエラー メッセージが表示されることがあります。これは、フェイルオーバー テストには影響しません。選択したゾーンに存在するノードが引き続きスケジュール不可に設定されます。

選択したゾーンのクラスタゾーンの障害をシミュレートするには:

kubectl get nodes -o name -l "topology.gke.io/zone=ZONE" | \
xargs kubectl drain \
--ignore-daemonsets --delete-emptydir-data --force --disable-eviction

以下を置き換えます。

• ZONE: クラスタゾーンの障害をシミュレートするゾーン。

環境の指標を確認する

図 1.シミュレートされたゾーンの停止時の環境指標（クリックして拡大）

1. Google Cloud コンソールで [環境] ページに移動します。

   [環境] に移動

2. 環境のリストで、ご利用の環境の名前をクリックします。[環境の詳細] ページが開きます。

3. [Monitoring] タブに移動します。

4. フェイルオーバー オペレーション中は、次の指標が「緑色」になっているか、最大数分間「赤色」のままになっていることを確認します。

   • 環境のヘルス
   • スケジューラのハートビート
   • ウェブサーバーのヘルス
   • データベースのヘルス
   • アクティブ ワーカー数
   • アクティブなスケジューラ
   • アクティブなウェブサーバー
   • アクティブなトリガー

   シミュレートされた停止は、「クラスタのメンテナンス オペレーション」としてマークされます。

5. テスト後に環境のクラスタを Failover readiness に戻すには、追加のアクションを行う必要はありません。テスト中に、環境のクラスタは、シミュレートされた停止の影響を受けるノードを置き換える新しいノードを自動的に追加します。

次のステップ

• 環境を作成する
• 環境をモニタリングする
• 環境のスナップショットを使用した障害復旧を確認する。