概況

  • Google Cloud のネットワーク設定の更新により、シドニー、メルボルン、フランクフルトにおける VMware Engine のストレッチクラスター（stretched clusters）が約12時間にわたり停止しました
  • コンピューティングとストレージサービスは利用可能な状態を維持したものの、クラスターゾーン間およびウィットネス（witness）との通信障害により、一部の仮想マシンが隔離状態になりました

障害の内容

7月14日、Google Cloud のネットワーク設定 of の更新により、シドニー、メルボルン、フランクフルトにおける VMware Engine のストレッチクラスターが停止しました。障害は11時間46分間続きました。Google は、設定を最後に正常稼働が確認されていた状態（ラストノウングッド）にロールバックすることでサービスを復旧させました。

Google によると、コンピューティングとストレージは利用可能なままであったとみられますが、クラスターゾーン間の接続が失われました。また、影響を受けたゾーンはウィットネスアプライアンス（witness appliance）との通信も切断され、クラスターが安全に状態を同期することができなくなりました。一部の仮想マシンは隔離状態となり、書き込み可能なデータがない状態になるリスクに直面しました。Google は、影響を受けたワークロードをクラスターの正常な側に移行する前に、サポートに相談するよう顧客にアドバイスしました。

評価

この障害は、ゾーンをまたいだ可用性を維持するためにストレッチクラスターを使用している顧客に影響を与えました。コンピューティングとストレージは動作を続けましたが、クラスターを調整するために必要なネットワークおよびウィットネスへの接続が失敗しました。企業のクラウドチームやビジネス継続性（BCP）チームにとって、これは両側の同期を維持するシステムが正常に機能しなくなっている一方で、ワークロード自体はアクティブなままであり得ることを意味していました。

VMware Engine のストレッチクラスターは、データノードを2つのゾーンに配置し、3つ目のゾーンにあるウィットネスを使用します。これらの一間の接続が失われると、一部の仮想マシンが隔離され、書き込み可能なデータへのアクセスを失うリスクが生じました。Google は可能であれば影響を受けたワークロードを正常な側に移行することを推奨しましたが、フェイルオーバーの失敗リスクやセカンダリゾーンの状態が不確実であることから、顧客に対してサポートに相談するよう強く求めました。このため、復旧はクラスターの設計と Google の運用的対応の両方に依存することになりました。

BTW の読者にとって、ワークロードを複数のゾーンに分散させることは、サービスのすべての部分を完全に独立させることを意味しません。顧客は依然として、これらのゾーンを単一のクラスターとして維持するために、プロバイダーのネットワークとウィットネスサービスに依存しています。事業継続計画には、この通信経路の損失を想定した対策を含めるべきであり、これにはワークロードの移行方法や、どの時点でプロバイダーのサポートが必要になるかが含まれます。

注視すべき事項

Google の根本原因分析に関する最終報告書、同社のネットワーク更新制御における変更、およびゾーン間接続やウィットネス接続に影響を与える障害に対する、改訂された復旧ガイダンスに注目してください。