最も高い稼働時間の要件を必要とする組織には、アベイラビリティ ゾーン (AZ) 全体の喪失といった重大な障害に対する耐性が必要です。 複数の AZ にまたがる Kubernetes クラスターのプロビジョニングはマネージド クラウド プロバイダーのわかりやすいタスクですが、ArcGIS Enterprise on Kubernetes ソフトウェアのデプロイメント、構成、操作フェーズ中に考慮しなければならない追加の管理要件があります。
次のセクションでは、検討すべき注意事項、組織を構成する前に満たしておくべき要件、AZ 内での機能の喪失による予想される影響、その AZ 内の機能を回復した後に管理者が基本となるシステムの健全性を確認する方法について説明します。
アプリケーションがデプロイされる Kubernetes クラスターは少なくとも、次の要件を満たしている必要があります。
- ワーカー ノード グループが 3 つ以上の AZ にまたがっている。
- ワーカー ノードのキャパシティが停電時にすべてのワークロードを 2 つの AZ に再調整するのに十分である。
デプロイメントと構成
ArcGIS Enterprise on Kubernetes を複数の AZ クラスターにデプロイする場合、ステートフル ワークロードの存在は、ブロック ストレージ デバイスを使用した場合に関連付けられたディスクの AZ 依存関係があることを意味します。
各 statefulset の関連付けられたレプリカが適切なトポロジ全体にまたがるようにするために、新しいプロパティ (K8S_AVAILABILITY_TOPOLOGY_KEY) がデプロイメント プロパティ ファイルに導入されました。これは、デプロイメント スクリプトを実行する前に更新する必要があります。 このプロパティを kubernetes.io/hostname 以外の値に更新すると、topologySpreadConstraint 仕様が statefulset に導入されます。これにより、調整が不均一であったり、1 つの AZ に複数のレプリカが含まれたりすることがなくなります。 ほとんどのクラウド プロバイダーの AZ ノード ラベル キーは topology.kubernetes.io/zone です。
組織の構成時に、最も高い可用性を確保するには、高い可用性アーキテクチャ プロファイルを使用して組織を構成します。 これは、AZ の障害時にすべてのステートフル ワークロードに対して適切なカバレッジを保証する唯一のプロファイルです。
高い可用性アーキテクチャ プロファイルを使用した場合でも、デプロイメントは特定の組織の要件によって大きく異なるため、1 つのレプリカに残るデプロイメントが多数あります。 ダウンタイムをさらに短縮するために、1 つのレプリカ上で次のデプロイメントを検討してください。
- arcgis-enterprise-apps
- arcgis-enterprise-manager
- arcgis-enterprise-portal
- arcgis-enterprise-web-style-app
- arcgis-help
- arcgis-javascript-api
- arcgis-service-api
- arcgis-service-lifecycle-manager
- arcgis-featureserver-webhook-processor
- arcgis-gpserver-webhook-processor
arcgis-enterprise-web-style-app を除く上記の各デプロイメントでは、リレーショナル データ ストアのフェイルオーバー プロセスに比べて、AZ 喪失後に再開する時間が短縮されます。 リストされたすべてのデプロイメントの追加レプリカに対するスケーリングでは、名前空間リクエストにおよそ 1 CPU と 0.5 GiB RAM、総名前空間制限に 5 CPU と 2.5 GiB RAM が追加されます。
サービスを公開するとき、スケジュールの再設定中に中断がないようにするため、最低 2 つ以上のポッドを実行するようにすべての専用サービスを設定します。 共有インスタンス デプロイメントも、同じ目的で少なくとも 2 つのレプリカにスケール処理します。
AZ 喪失の影響
AZ 喪失の意味と影響は、影響を受けるクラウド サービスによって異なります。 特定のサービス (計算やストレージなど) の喪失は実行しているワークロードに大きな影響をおよぼす可能性があり、他のネットワークベースの障害 (DNS 解決や遅延の急激な増加など) はマイクロサービスが相互に通信できる方法に影響する可能性があります。
リレーショナル ストアのフェイルオーバー時には、特定の機能 (サイン イン、ホスト フィーチャ サービスの編集、ホスト レイヤーの読み込みなど) が短時間だけ低下することがあります。 スタンバイ インスタンスがプライマリへの昇格を終了したら、すべての組織の機能が安定した状態に戻ります。
組織の健全性の確認
管理者は、統合されたヘルス チェック レポートを使用して、サイトの組織の健全性を評価できます。 ポッドの起動での問題や生じる可能性があるその他の課題について、名前区間のワークロードを確認することもできます。
AZ 喪失中
PV のブロック ストレージを使用しているときに AZ が失われた場合、ボリュームのアフィニティ要件により、statefulset ポッドを他の AZ にスケジュール変更できません。
このスケジュール変更を必要とするデータ ストアの場合、クォーラムが維持されるので、関連するサービスは劣化した状態で機能できます。 リレーショナル ストアは、他のいくつかのサービスが依存しているコア コンポーネントであるため、管理 API を使用してスタンバイをリセットすることができます。 このとき、statefulset と関連する PVC が削除され、新しいステートフル セットが作成されます。 これにより、スタンバイ インスタンスは、残りの AZ のいずれかに移動した後でプライマリと再同期することができます。
AZ 喪失後
障害が発生した AZ にサービスが復元された場合、保留状態にあった関連するワークロードが再開されます。これは、Kubernetes API を使用して確認できます。
既存の AZ にサービスを復元できない場合、クラスターに残りの AZ が 3 つ以上あることを確認してください。 3 つ以上ない場合には、クラスターを追加の AZ に拡張してください。 それを完了したら、バックアップを作成し、アンデプロイおよび再デプロイして、バックアップから復元操作を実行します。