このページでは、Anthos clusters on VMware（GKE On-Prem）の高可用性（HA）オプション、HA 用に特定の Anthos clusters on VMware コンポーネントを設定する方法、障害から復旧する方法について説明します。
コア機能
Anthos clusters on VMware には、1 つの管理クラスタと 1 つ以上のユーザー クラスタがあります。
管理クラスタは、ユーザー クラスタのライフサイクル（ユーザー クラスタの作成、更新、アップグレード、削除など）を管理します。管理クラスタでは、管理マスターが管理ワーカーノードを管理します。管理ワーカーノードには、ユーザー マスター（管理対象ユーザー クラスタのコントロール プレーンを実行するワーカーノード）とアドオンノード（アドオン コンポーネントを実行して管理クラスタの機能をサポートするノード）が含まれています。
ユーザー クラスタごとに、管理クラスタの 1 つの非 HA ノードまたは 3 つの HA ノードでコントロール プレーンが実行されます。コントロール プレーンには、Kubernetes API サーバー、Kubernetes スケジューラ、Kubernetes コントローラ マネージャー、ユーザー クラスタの重要なコントローラが含まれています。
ユーザー クラスタのコントロール プレーンの可用性は、ワークロードの作成、スケールアップとスケールダウン、終了などのワークロード オペレーションにとってきわめて重要です。つまり、コントロール プレーンが停止しても、実行中のワークロードは影響を受けませんが、既存のワークロードはコントロール プレーンを失うため、Kubernetes API サーバーによる管理機能を利用できなくなります。
コンテナ化されたワークロードとサービスは、ユーザー クラスタのワーカーノードにデプロイされます。複数のワーカーノード間でスケジュールされた冗長 Pod でアプリケーションをデプロイされていれば、1 つのワーカーノードがアプリケーションの可用性に重大な影響を及ぼすことはありません。
Anthos clusters on VMware は、障害を可能な限り機能領域に隔離し、ビジネス継続性にとって不可欠な機能を優先するように設計されています。
Anthos clusters on VMware のコア機能には次のカテゴリがあります。
アプリケーションのライフサイクル
既存のワークロードを継続的に実行できます。これは、確実にビジネスを継続させるために最も重要な機能です。
ワークロードを作成、更新、削除できます。トラフィック増加時、Anthos clusters on VMware によりワークロードがスケーリングされる必要があるため、これは 2 番目に重要な機能になります。
ユーザー クラスタのライフサイクル
ユーザー クラスタを追加、更新、アップグレード、削除できます。ユーザー クラスタを変更できなくても、ユーザー ワークロードには影響を与えないことから、重要度は少し下がります。
管理クラスタのライフサイクル
管理クラスタを更新、アップグレードできます。管理クラスタはユーザー ワークロードをホストしないため、重要度は最も低くなります。
障害モード
以下では、Anthos clusters on VMware クラスタのパフォーマンスに影響を与える可能性がある障害について説明します。
ESXi ホストの障害
Kubernetes ノードをホストする仮想マシン（VM）インスタンスを実行する ESXi ホストが機能しなくなったか、ネットワークが分断された可能性があります。
| 既存のワークロード | 作成中、更新中、削除中のワークロード | ユーザー クラスタのライフサイクル | 管理クラスタのライフサイクル |
|---|---|---|---|
| 中断の可能性あり + 自動復旧 |
中断の可能性あり + 自動復旧 |
中断 + 自動復旧 |
中断 + 自動復旧 |
障害が発生したホストの VM 上で稼働する Pod は中断され、別の正常な VM に自動的に再スケジュールされます。 ユーザー アプリケーションが予備のワークロード容量を持ち、複数のノードに分散されている場合、再試行を行うクライアントは中断を検知しません。 |
ホストの障害が、HA 以外のユーザー クラスタ内のコントロール プレーン VM または HA ユーザー クラスタ内の複数のコントロール プレーン VM に影響する場合は、中断が発生します。 | ホストの障害が、管理クラスタのコントロール プレーン VM またはワーカー VM に影響する場合は、中断が発生します。 | ホストの障害が、管理クラスタ内のコントロール プレーン VM に影響する場合は、中断が発生します。 |
| vSphere HA は、正常なホストで VM を自動的に再起動します。 | vSphere HA は、正常なホストで VM を自動的に再起動します。 | vSphere HA は、正常なホストで VM を自動的に再起動します。 | vSphere HA は、正常なホストで VM を自動的に再起動します。 |
| 高可用性を実現できる方法でワークロードをデプロイし、中断の可能性を最小限に抑えます。 | HA ユーザー クラスタを使用して、中断が発生する可能性を最小限に抑えます。 |
VM の障害
VM が予期せず削除されたか、ブートディスクが壊れた可能性があります。また、オペレーティング システムの問題が原因で、VM がセキュリティ侵害された可能性もあります。
| 既存のワークロード | 作成中、更新中、削除中のワークロード | ユーザー クラスタのライフサイクル | 管理クラスタのライフサイクル |
|---|---|---|---|
| 中断の可能性あり + 自動復旧 |
中断の可能性あり + 自動復旧 |
中断 + 自動 / 手動復旧 |
中断 + 手動復旧 |
障害が発生したワーカー VM で実行される Pod は中断され、Kubernetes によって他の正常な VM に自動的に再スケジュールされます。 ユーザー アプリケーションが予備のワークロード容量を持ち、複数のノードに分散されている場合、再試行を行うクライアントは中断を検知しません。 |
HA 以外のユーザー クラスタ内のコントロール プレーン VM または HA ユーザー クラスタ内の複数のコントロール プレーン VM に障害が起こると、中断が発生します。 | 管理クラスタ内のコントロール プレーン VM またはワーカー VM で障害が起こると、中断が発生します。 | 管理クラスタ内のコントロール プレーン VM で障害が起こると、中断が発生します。 |
| ユーザー クラスタでノードの自動修復が有効になっている場合は、障害が発生した VM は自動的に復旧します。 | 管理クラスタでノードの自動修復を有効にすると、障害が発生した VM は自動的に復旧します。 | 管理クラスタでノードの自動修復を有効にすると、管理クラスタ内の障害が発生したワーカー VM は自動的に復旧します。 管理クラスタのコントロール プレーン VM を復旧するには、管理クラスタのコントロール プレーン VM の修復をご覧ください。 |
管理クラスタのコントロール プレーン VM を復旧するには、管理クラスタのコントロール プレーン VM の修復をご覧ください。 |
| 高可用性を実現できる方法でワークロードをデプロイし、中断の可能性を最小限に抑えます。 | HA ユーザー クラスタを使用して、中断が発生する可能性を最小限に抑えます。 |
ストレージの障害
VM の電源が突然切れたことにより、VMDK ファイル内のコンテンツが壊れている可能性があります。また、データストアの障害により etcd データと PersistentVolume（PV）が失われている可能性があります。
etcd の障害
| 既存のワークロード | 作成中、更新中、削除中のワークロード | ユーザー クラスタのライフサイクル | 管理クラスタのライフサイクル |
|---|---|---|---|
| 中断なし | 中断の可能性あり + 手動復旧 |
中断 + 手動復旧 |
中断 + 手動復旧 |
| HA 以外のユーザー クラスタ内の etcd ストアまたは HA ユーザー クラスタ内の複数の etcd レプリカで障害が起こると、中断が発生します。 | HA 以外のユーザー クラスタ内の etcd ストアまたは HA ユーザー クラスタ内の複数の etcd レプリカで障害が起こると、中断が発生します。 管理クラスタ内の etcd レプリカに障害が起こると、中断が発生します。 |
管理クラスタ内の etcd レプリカに障害が起こると、中断が発生します。 | |
| Anthos clusters on VMware では、障害から復旧するための手動プロセスが用意されています。 | Anthos clusters on VMware では、障害から復旧するための手動プロセスが用意されています。 | Anthos clusters on VMware では、障害から復旧するための手動プロセスが用意されています。 |
ユーザー アプリケーション PV の障害
| 既存のワークロード | 作成中、更新中、削除中のワークロード | ユーザー クラスタのライフサイクル | 管理クラスタのライフサイクル |
|---|---|---|---|
| 中断の可能性あり | 中断なし | 中断なし | 中断なし |
障害が発生した PV を使用するワークロードが影響を受けます。 高可用性を実現できる方法でワークロードをデプロイし、中断の可能性を最小限に抑えます。 |
ロードバランサの障害
ロードバランサの障害は、LoadBalancer タイプの Service を公開するユーザー ワークロードに影響を与える可能性があります。
| 既存のワークロード | 作成中、更新中、削除中のワークロード | ユーザー クラスタのライフサイクル | 管理クラスタのライフサイクル |
|---|---|---|---|
| 中断 + 手動復旧 |
|||
|
スタンバイ ロードバランサによって管理コントロール プレーンの VIP 接続が復旧されるまで、数秒間の中断が発生します。 サービスの中断は、Seesaw を使用する場合には最大 2 秒、F5 を使用すると最大 300 秒になる可能性があります。 Seesaw HA は障害を自動的に検出し、バックアップ インスタンスを使用するようにフェイル オーバーします。 Anthos clusters on VMware では、Seesaw の障害から復旧するための手動プロセスが用意されています。 |
|||
高可用性の有効化
vSphere と Anthos clusters on VMware では、高可用性（HA）に役立つ多くの機能を利用できます。
vSphere HA と vMotion
Anthos clusters on VMware クラスタをホストする vCenter クラスタで次の 2 つの機能を有効にすることをおすすめします。
これらの機能によって、ESXi ホストで発生する障害に対して可用性と復元性が向上します。
vCenter HA は、クラスタとして構成された複数の ESXi ホストを使用して、仮想マシンで稼働するアプリケーションに対し、停止からの迅速な復旧と費用対効果の高い HA を可能にします。追加のホストを使用して vCenter クラスタをプロビジョニングし、Host Failure Response を Restart VMs に設定して vSphere HA ホスト モニタリングを有効にすることをおすすめします。そうすると、ESXi ホストで障害が発生した場合、VM は他の利用可能なホストで自動的に再起動されます。
vMotion を使用すると、ダウンタイムなしで ESXi ホスト間での VM のライブ マイグレーションが可能になります。計画されたホスト メンテナンスに対しては、vMotion ライブ マイグレーションを使用してアプリケーションのダウンタイムを完全に回避し、ビジネスの継続性を確保できます。
管理クラスタ
Anthos clusters on VMware では、管理クラスタの複数のコントロール プレーンの実行はサポートされていません。ただし、管理コントロール プレーンが使用不能になっても、既存のユーザー クラスタ機能やユーザー クラスタで実行中のワークロードには影響しません。
管理クラスタには 2 つのアドオンノードがあります。1 つが停止しても、もう一方で管理クラスタの操作を実行できます。冗長性を確保するため、Anthos clusters on VMware では kube-dns などの重要なアドオン サービスが両方のアドオンノードに分散されます。
管理クラスタの構成ファイルで antiAffinityGroups.enabled を true に設定すると、Anthos clusters on VMware はアドオンノード用の vSphere DRS アンチアフィニティ ルールを自動的に作成するため、HA 用の 2 つの物理ホストにそれぞれが分散されます。
ユーザー クラスタ
ユーザー クラスタの構成ファイルで masterNode.replicas を 3 に設定すると、ユーザー クラスタの HA を有効にできます。これにより、管理クラスタの 3 つのノードが作成されます。各ノードでは、ユーザー クラスタのコントロール プレーンが実行されます。これらのノードは、etcd レプリカも実行します。1 つのコントロール プレーンと etcd クォーラムが存在する限り、ユーザー クラスタは引き続き機能します。etcd のクォーラムでは、3 つの etcd レプリカのうち 2 つが機能している必要があります。
管理クラスタの構成ファイルで、true を antiAffinityGroups.enabled に設定した場合、Anthos clusters on VMware は、それら 3 つのノード用に、ユーザー クラスタ管理プレーンを実行する vSphere DRS アンチアフィニティ ルールを自動作成します。これにより、それらの VM は 3 つの物理ホストに分散されます。
また、Anthos clusters on VMware は、ユーザー クラスタ内のワーカーノード用に vSphere DRS アンチアフィニティ ルールを作成します。これにより、これらのノードが少なくとも 3 つの物理ホストに分散されます。ノード数に基づいて、ユーザー クラスタ ノードプールごとに複数の DRS 反アフィニティ ルールが使用されます。これにより、ホストの数が、ユーザー クラスタのノードプール内の VM の数より少ない場合でも、ワーカーノードが実行先のホストを見つけることができます。vCenter クラスタに追加の物理ホストを含めることをおすすめします。また、ホストが使用不能になった場合に、DRS が VM の反アフィニティ ルールに違反することなく、使用可能な他のホスト上の VM を自動的に再起動できるよう、DRS が完全に自動化されるように構成します。
Anthos clusters on VMware は、特別なノードラベル onprem.gke.io/failure-domain-name を保持しています。このラベルの値は、基になる ESXi ホスト名に設定されます。高可用性を必要とするユーザー アプリケーションでは、topologyKey としてこのラベルを使用して podAntiAffinity ルールを設定し、アプリケーション Pod が複数の VM と物理ホストに分散されるようにします。異なるデータストアと特別なノードラベルを使用してユーザー クラスタに複数のノードプールを構成することもできます。同様に、特別なノードラベルで podAntiAffinity ルールを topologyKey として設定すると、データストアで障害が発生した場合に高可用性を実現できます。
ユーザー ワークロードに対して高可用性を確保するには、ユーザー クラスタが nodePools.replicas の配下に十分な数のレプリカを持つようにします。これにより、実行中のユーザー クラスタ ワーカーノードの数が適切な状態で維持されます。
管理クラスタとユーザー クラスタに別々のデータストアを使用して、障害を隔離できます。
ロードバランサ
高可用性を確保するために使用できるロードバランサには次の 2 種類があります。
バンドル型 Seesaw ロードバランサ
バンドル型 Seesaw ロードバランサの場合、クラスタ構成ファイルで loadBalancer.seesaw.enableHA を true に設定することで HA を有効にできます。また、ロードバランサのポートグループで、MAC ラーニング、偽装転送、プロミスキャス モードを組み合わせて使用する必要があります。
HA では、アクティブパッシブ モードで 2 つのロードバランサが設定されています。アクティブ ロードバランサに問題がある場合、トラフィックはパッシブ ロードバランサにフェイルオーバーします。
ロードバランサのアップグレード中はダウンタイムが発生します。ロードバランサで HA が有効になっている場合、ダウンタイムは最大 2 秒です。
統合型 F5 BIG-IP ロードバランサ
F5 BIG-IP プラットフォームでは、アプリケーションのセキュリティ、可用性、パフォーマンスを向上させるさまざまな Service が利用できます。Anthos clusters on VMware の場合、BIG-IP は外部アクセスと L3 / 4 負荷分散 Service を提供します。
詳細については、BIG-IP の高可用性をご覧ください。
壊れたクラスタの復旧
以降のセクションでは、壊れたクラスタの復旧方法について説明します。
ESXi ホストの障害からの復旧
Anthos clusters on VMware では、ESXi ホストの障害からの復旧に vSphere HA を利用します。vSphere HA は、ESXi ホストを継続的にモニタリングして、必要な場合は他のホスト上で VM を自動的に再起動できます。これを Anthos clusters on VMware ユーザーが意識することはありません。
VM の障害からの復旧
VM の障害には、次のようなものがあります。
VM が予期せず削除された。
VM ブートディスクの破損（たとえば、スパムログが原因でブートディスクが読み取り専用になるなど）。
ディスクのパフォーマンス低下やネットワーク設定の問題により、VM の起動に失敗する（たとえば、なんらかの理由で IP アドレスを割り振ることができず、VM を起動できない場合など）。
Docker オーバーレイ ファイル システムの破損
アップグレードの失敗による管理コントロール プレーン VM の消失。
オペレーティング システムの問題。
このセクションで説明する VM 障害には、VM にアタッチされた PV または etcd データディスクのデータの破損や消失は含まれません。これらについては、ストレージ障害からの復旧をご覧ください。
Anthos clusters on VMware では、管理者アドオンノード、ユーザー コントロール プレーン、ユーザーノード用の自動復旧メカニズムが用意されています。このノードの自動復旧機能は、管理クラスタとユーザー クラスタごとに有効にできます。
管理コントロール プレーン VM は、Kubernetes クラスタによって管理されていないという点で特別なもので、その可用性がビジネス継続性に影響することはありません。管理コントロール プレーン VM の復旧については、Google サポートにお問い合わせください。
ストレージ障害からの復旧
一部のストレージ障害は、vSphere HA と vSAN を使用することで、Anthos clusters on VMware に影響を与えることなく軽減できます。ただし、特定のストレージ障害は、vSphere レベルから表面化し、さまざまな Anthos clusters on VMware コンポーネントで、データの破損や消失につながる可能性があります。
クラスタとユーザー ワークロードのステートフル情報は、次の場所に保存されます。
etcd
各クラスタ（管理クラスタとユーザー クラスタ）には、クラスタの状態（Kubernetes オブジェクト）を保存する etcd データベースがあります。
PersistentVolume
システム コンポーネントとユーザー ワークロードの両方で使用されます。
etcd データの破損や消失からの復旧
etcd は、ユーザー アプリケーション マニフェストを含むすべてのクラスタの状態を保存するために Kubernetes が使用するデータベースです。ユーザー クラスタの etcd データベースが破損または消失すると、アプリケーションのライフサイクル オペレーションは機能しなくなります。管理クラスタの etcd データベースが破損または消失すると、ユーザー クラスタのライフサイクル オペレーションは機能しなくなります。
etcd は、データの破損を検出する確実な仕組みを備えていません。etcd のデータが破損または消失している疑いがある場合は、etcd Pod のログを調べる必要があります。
保留中 / エラー / クラッシュ ループの etcd Pod が、常に etcd のデータの破損や消失を意味しているとは限りません。etcd Pod をホストする VM のエラーが原因で発生している可能性があります。次の etcd の復旧は、データが破損や消失した場合にのみ実施してください。
etcd データの破損や消失から復旧する（最新のクラスタ状態に戻す）には、クラスタ内でのライフサイクル操作（作成、更新、アップグレードなど）の後、常に etcd データをバックアップする必要があります。etcd のデータをバックアップするには、管理クラスタのバックアップとユーザー クラスタのバックアップをご覧ください。
etcd のデータを復元すると、クラスタは以前の状態になります。つまり、アプリケーションのデプロイ前にバックアップが取得され、そのバックアップを使用してクラスタを復元すると、復元されたクラスタではアプリケーションが実行されなくなります。たとえば、ユーザー クラスタを作成する前に作成された管理クラスタの etcd のスナップショットを使用すると、復元された管理クラスタには、ユーザー クラスタ コントロール プレーンがありません。したがって、重要なクラスタ オペレーションそれぞれの後で、クラスタをバックアップすることをおすすめします。
etcd データの破損 / 消失は、次のような状況で発生します。
3 ノード etcd クラスタ（HA ユーザー クラスタ）のノードの 1 つが、データの破損や消失が原因で恒久的に壊れる。この場合、1 つのノードのみが使用できなくなっているため、etcd クォーラムは満たされています。これは、いずれかの etcd レプリカのデータが破損または消失した HA クラスタで発生する可能性があります。この問題は、失敗した etcd レプリカをクリーン状態で新しいレプリカに置き換えることで、データを消失することなく解決できます。詳細については、障害が発生した etcd レプリカを置き換えるをご覧ください。
3 ノード etcd クラスタ（HA ユーザー クラスタ）のノードの 2 つが、データの破損や消失が原因で恒久的に壊れる。クォーラムが失われているため、障害が発生した etcd レプリカを新しいレプリカに置き換えても解決しません。バックアップ データからクラスタの状態を復元する必要があります。詳細については、バックアップ（HA）からユーザー クラスタを復元するをご覧ください。
単一ノードの etcd クラスタ（管理クラスタまたは HA 以外のユーザー クラスタ）が、データの破損や消失が原因で恒久的に壊れる。クォーラムがなくなったため、バックアップから新しいクラスタを作成する必要があります。詳細については、バックアップ（HA 以外）からユーザー クラスタを復元するをご覧ください。
ユーザー アプリケーションの PV の破損または消失からの復旧
Anthos clusters on VMware のお客様は、ユーザー アプリケーションの PersistentVolume をバックアップおよび復元するために、相応のパートナー ストレージ ソリューションを使用できます。
Anthos clusters on VMware で認定されているストレージ パートナーのリストについては、Anthos Ready ストレージ パートナーをご覧ください。
ロードバランサの障害からの復旧
バンドル型負荷分散（Seesaw）の場合は、ロードバランサを再作成することで障害から復旧できます。ロードバランサを再作成するには、管理クラスタのロードバランサのアップグレードの説明に沿って、Seesaw を同じバージョンにアップグレードします。
管理クラスタのロードバランサに障害が発生した場合、コントロール プレーンが離れている可能性があります。そのため、コントロール プレーンにアクセスできる管理コントロール プレーン VM でアップグレードを行う必要があります。
統合ロードバランサ（F5）については、F5 サポートにお問い合わせください。
障害復旧に複数のクラスタを使用する
複数の vCenter または Anthos プラットフォームにまたがって複数のクラスタにアプリケーションをデプロイすると、全体の可用性が向上し、サービス停止時の中断の影響を回避できます。
この設定では、新しいデータセンターではなく、セカンダリ データセンターにある既存の Anthos クラスタを使用して障害復旧を行います。手順の概要は次のとおりです。
セカンダリ データセンターに別の管理クラスタとユーザー クラスタを作成します。このマルチクラスタ アーキテクチャでは、各データセンターに 2 つの管理クラスタを用意し、各管理クラスタでユーザー クラスタを実行する必要があります。
セカンダリ ユーザー クラスタには最小限のワーカーノード（3 つ）があり、ホット スタンバイ（常時稼働）の状態です。
アプリケーションのデプロイは、Anthos Config Management を使用して 2 つの vCenter 間でレプリケートできます。または、既存のアプリケーション DevOps（CI / CD、Spinnaker）ツールチェーンの使用をおすすめします。
大規模障害が発生した場合、ユーザー クラスタをそのノード数に変更できます。
また、クラスタ間でのトラフィックをセカンダリ データセンターに転送するために、DNS のスイッチオーバーも必要です。