Google Distributed Cloud は、障害の範囲を限定し、ビジネスの継続性に不可欠な機能を優先するように設計されています。このドキュメントでは、障害が発生した際にクラスタの機能がどのような影響を受けるかを説明します。この情報は、問題が発生した場合にトラブルシューティングを行う部分の優先順位を決めるのに役立ちます。
さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。Google Distributed Cloud のコア機能には次のカテゴリがあります。
- ワークロードの実行: 既存のワークロードを継続して実行できます。これは、ビジネスの継続性を維持するための最も重要な考慮事項です。クラスタに問題が発生しても、既存のワークロードは中断されることなく引き続き実行できます。
- ワークロードの管理: ワークロードの作成、更新、削除を行うことができます。これは、クラスタに問題が発生した場合でも、トラフィックが増加した際にワークロードを拡張するために 2 番目に重要な考慮事項です。
- ユーザー クラスタの管理: ノードの管理、ユーザー クラスタの更新、アップグレード、削除を行うことができます。これは、アプリケーションのライフサイクルの考慮事項よりも重要度が低くなります。既存のノードに使用可能な容量があれば、ユーザー クラスタを変更できなくても、ユーザーのワークロードには影響しません。
- 管理クラスタを管理する: 管理クラスタを更新、アップグレードできます。管理クラスタはユーザーのワークロードをホストしないため、この考慮事項の重要度は最も低くなります。管理クラスタに問題がある場合でも、アプリケーション ワークロードは中断されることなく引き続き実行されます。
以下のセクションでは、これらのコア機能のカテゴリを使用して、特定のタイプの障害シナリオの影響について説明します。
障害モード
次のタイプの障害は、Google Distributed Cloud クラスタのパフォーマンスに影響する可能性があります。
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 レプリカに障害が起こると、停止が発生します。 |
| 予防策 | — | Google Distributed Cloud には、障害から復旧するための手動プロセスが用意されています。 | Google Distributed Cloud には、障害から復旧するための手動プロセスが用意されています。 | Google Distributed Cloud には、障害から復旧するための手動プロセスが用意されています。 |
ユーザー アプリケーション PV の障害
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止 | 停止の可能性あり | 停止なし | 停止なし | 停止なし |
| 説明 | 障害が発生した PV を使用するワークロードが影響を受けます。 高可用性を実現できる方法でワークロードをデプロイし、停止の可能性を最小限に抑えます。 |
— | — | — |
ロードバランサの障害
この障害シナリオでは、ロードバランサの障害が、LoadBalancer タイプの Service を公開するユーザー ワークロードに影響を与える可能性があります。
| ワークロードを実行する | ワークロードを管理する | ユーザー クラスタを管理する | 管理クラスタを管理する | |
|---|---|---|---|---|
| 停止と手動復旧 | ||||
| 説明 |
スタンバイ ロードバランサによって管理コントロール プレーンの VIP 接続が復旧されるまで、数秒間の停止が発生します。 サービスの停止は、Seesaw を使用する場合には最大 2 秒、F5 を使用すると最大 300 秒になる可能性があります。 ロードバランサ ノードの数が増えると、MetalLB のフェイルオーバーの停止期間が長くなります。5 ノード未満であれば、停止は 10 秒以内です。 |
|||
| 復旧 | Seesaw HA は障害を自動的に検出し、バックアップ インスタンスを使用するようにフェイルオーバーします。 Google Distributed Cloud には、Seesaw の障害から復旧するための手動プロセスが用意されています。 |
|||
壊れたクラスタの復旧
以降のセクションでは、壊れたクラスタの復旧方法について説明します。
ESXi ホストの障害からの復旧
Google Distributed Cloud では、ESXi ホストの障害からの復旧に vSphere HA を利用します。vSphere HA は、ESXi ホストを継続的にモニタリングして、必要な場合は他のホスト上で VM を自動的に再起動できます。これは Google Distributed Cloud ユーザーにとって透過的です。
VM の障害からの復旧
VM の障害には、次のようなものがあります。
VM が予期せず削除された。
VM ブートディスクの破損（スパム ジャーナルログが原因で読み取り専用になるブートディスクなど）。
ディスクのパフォーマンス低下やネットワーク設定の問題により、VM の起動に失敗する（たとえば、IP アドレスを割り振ることができず、VM を起動できない場合など）。
Docker オーバーレイ ファイル システムの破損
アップグレードの失敗による管理コントロール プレーン VM の消失。
オペレーティング システムの問題。
Google Distributed Cloud では、管理者アドオンノード、ユーザー コントロール プレーン、ユーザーノード用の自動復旧メカニズムが用意されています。このノードの自動復旧機能は、管理クラスタとユーザー クラスタごとに有効にできます。
管理コントロール プレーン VM は、Kubernetes クラスタによって管理されていないという点で特別なもので、その可用性がビジネス継続性に影響することはありません。管理コントロール プレーン VM の障害の復旧については、Cloud カスタマーケアにお問い合わせください。
ストレージ障害からの復旧
一部のストレージ障害は、vSphere HA と vSAN を使用することで、Google Distributed Cloud に影響を与えることなく軽減できます。ただし、特定のストレージ障害は、vSphere レベルから表面化し、さまざまな Google Distributed Cloud コンポーネントで、データの破損や消失につながる可能性があります。
クラスタとユーザー ワークロードのステートフル情報は、次の場所に保存されます。
- etcd: 各クラスタ（管理クラスタとユーザー クラスタ）には、クラスタの状態（Kubernetes オブジェクト）を保存する etcd データベースがあります。
- PersistentVolumes: システム コンポーネントとユーザー ワークロードの両方で使用されます。
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 の破損または消失からの復旧
お客様は、ユーザー アプリケーションの PersistentVolume をバックアップおよび復元するために、相応のパートナー ストレージ ソリューションを使用できます。Google Distributed Cloud で認定されているストレージ パートナーのリストについては、Anthos Ready ストレージ パートナーをご覧ください。
ロードバランサの障害からの復旧
バンドル型 Seesaw ロードバランサの場合、ロードバランサを再作成することで障害から復旧できます。ロードバランサを再作成するには、管理クラスタのロードバランサのアップグレードの説明に沿って、Seesaw を同じバージョンにアップグレードします。
管理クラスタのロードバランサに障害が発生した場合、コントロール プレーンが離れている可能性があります。コントロール プレーンにアクセスできる管理コントロール プレーン VM でアップグレードを行います。
統合ロードバランサ（F5）については、F5 サポートにお問い合わせください。
バンドル型 MetalLB ロードバランサの場合、クラスタノードをロードバランサとして使用します。ロードバランサの問題では、ノードの自動修復はトリガーされません。手動プロセスに沿ってノードを修復できます。