可用性に関するベスト プラクティス

このページでは、Google Distributed Cloud コネクテッドのインストールで高可用性を確保するためのベスト プラクティスについて説明します。 Distributed Cloud コネクテッドにはサービスレベル契約（SLA）はなく、このページで説明するサービスレベル目標（SLO）のみが提供されます。

可用性のレベルを選択して実装する

ビジネス要件に最適な Distributed Cloud コネクテッド ワークロードの可用性レベルを選択する必要があります。たとえば、小売店のセルフレジ アプリケーションは、モバイル ネットワーク キャリアのエッジ RAN デプロイよりも可用性のリスクがはるかに低くなります。

目標可用性は、緊急用に予約する Distributed Cloud の予備リソース容量に正比例します。次の表に、この関係を示します。これらの 見積もりには、 メンテナンスの時間枠でスケジュールされたダウンタイムは含まれていません。

Distributed Cloud コネクテッド ソフトウェアは、各物理マシンで一部のリソースを消費します。量は、Distributed Cloud コネクテッド デプロイの特定の構成によって異なります。この量を測定し、ワークロードの分散を計画する際に考慮するために、Distributed Cloud コネクテッド デプロイのベンチマークを実施することをおすすめします。

GDC コネクテッド フォーム ファクタ 使用中の容量 予約済み容量 目標可用性
GDC コネクテッド ラック
（6 台のマシンで構成される単一クラスタ）		 83.33% 16.67% 99.9%
GDC コネクテッド ラック
（6 台のマシンで構成される単一クラスタ）		 100% 0% 93.5%
GDC コネクテッド サーバー
（3 台のマシンで構成される単一クラスタ）		 66.6% 33.3% 99.9%

ハードウェア障害や再起動が必要なノードが原因で、容量が突然失われる可能性があります。これに備えて、選択した可用性レベルを満たす使用可能な容量が各 Distributed Cloud コネクテッド ノードに常に確保されるように、リソース割り当てを考慮してワークロードを設計する必要があります。

たとえば、Distributed Cloud コネクテッド ラック デプロイで 99.9% の目標可用性を実現するには、各 Distributed Cloud コネクテッド クラスタの 6 台の物理マシンのうち 1 台をバックアップとして使用できるようにワークロードを構成する必要があります。

Distributed Cloud ゾーンを地理的に分散させる

管理プレーンの障害による影響を最小限に抑えるため、Distributed Cloud ゾーンを近隣の複数のリージョンに分散させることを強くおすすめします。

サバイバビリティ モードを使用する

Distributed Cloud クラスタは、Distributed Cloud コネクテッド ハードウェアで実行されるローカル コントロール プレーンを使用します。への接続が失われても、ワークロードは引き続き実行されます。 Google Cloud 詳細については、 Distributed Cloud コネクテッドのサバイバビリティ モードをご覧ください。

ソフトウェア アップデートとメンテナンスの時間枠について

Google は定期的に Distributed Cloud コネクテッド ソフトウェアを更新します。 このソフトウェア更新は必須であり、無効にすることはできません。 Distributed Cloud コネクテッドでは、Distributed Cloud コネクテッド クラスタごとに個別のメンテナンスの時間枠を指定できます。

メンテナンスの時間枠を使用すると、コントロール プレーンとノードの自動アップグレード実行のタイミングの管理が可能になり、ワークロードの一時的な中断を軽減できます。メンテナンスの時間枠は、次のような場合に役立ちます。

  • オフピーク時: 自動アップグレードをトラフィックが減少するオフピーク時にスケジュールすることにより、ダウンタイムの可能性を最小限に抑えたい。
  • オンコール: アップグレードをモニタリングして予期せぬ問題を管理できるように、アップグレードを勤務時間中に実行したい。
  • 複数クラスタのアップグレード: 異なるリージョンの複数のクラスタに、指定した間隔で一度に 1 つずつアップグレードをロールアウトしたい。

Distributed Cloud コネクテッドは、次のタイプのメンテナンスの時間枠をサポートしています。

  • メンテナンスの時間枠。Google が Distributed Cloud コネクテッド クラスタでメンテナンスとソフトウェア アップグレードを実行できる時間枠を指定します。
  • メンテナンス除外の時間枠。Google が Distributed Cloud コネクテッド クラスタでメンテナンスやソフトウェア アップグレードを実行できない時間枠を指定します。 メンテナンス除外の時間枠を構成するには、まずメンテナンスの時間枠を構成する必要があります。 メンテナンス除外の時間枠は、クラスタのメンテナンスの時間枠よりも優先されます。

自動アップグレードに加えて、Google は他のメンテナンス タスクを行うこともあります。その場合は、可能な限りクラスタのメンテナンスの時間枠を尊重します。

タスクがメンテナンスの時間枠を超えて実行されると、Distributed Cloud コネクテッドはタスクの一時停止を試みます。その後、次のメンテナンスの時間枠でタスクの再開を試みます。

Distributed Cloud コネクテッドは、メンテナンスの時間枠の外で予定外の緊急アップグレードをロールアウトする権限を有します。また、メンテナンスの時間枠の外で、非推奨のソフトウェアや古いソフトウェアからの必須のアップグレードが自動的に行われることがあります。

クラスタはいつでも手動でアップグレードできます 。手動のアップグレードは、メンテナンスの時間枠を無視してすぐに開始されます。

新規または既存のクラスタに対してメンテナンスの時間枠を設定する方法については、 メンテナンスの時間枠の構成をご覧ください。

ソフトウェア アップデートの段階的リリース

ワークロードのダウンタイムを短縮するため、Distributed Cloud コネクテッド ソフトウェアのアップデートは段階的に行われます。つまり、Google は各 Distributed Cloud コネクテッド クラスタのワーカーノードを段階的にアップグレードします。ソフトウェア アップグレードのステージにあるすべてのワーカーノードが同時に停止します。

ソフトウェア アップグレードのステージにあるノードの数は、次のように決定されます。

  • 最大 3 ラックのデプロイ: 各ステージは、すべてのラックのマシンの合計数を 6 で割り、次の整数に切り上げた数です。
  • 4 ラック以上のデプロイ: 各ステージは、デプロイ内のすべてのラックのマシンの合計数を、デプロイ内のラック数で割った数です。

独自のソフトウェア アップグレード ステージ サイズを設定することもできます。つまり、Distributed Cloud コネクテッド クラスタでソフトウェア アップグレードのために同時に停止できるノードの数を指定できます。手順については、 ソフトウェア アップグレード中のノードのダウンタイムを管理するをご覧ください。

制限事項

メンテナンスの時間枠には次の制限があります。

  • クラスタごとに 1 つのメンテナンスの時間枠。メンテナンスの時間枠は、クラスタごとに 1 つだけ構成できます。新しいメンテナンスの時間枠を構成すると、以前のメンテナンスの時間枠が上書きされます。

  • メンテナンスの時間枠のタイムゾーン。メンテナンスの時間枠を構成および表示する場合、使用しているツールによって表示される時間が異なります。詳細については、次のセクションをご覧ください。

メンテナンスの時間枠を構成する場合

より一般的な --maintenance-window フラグを使用してメンテナンスの時間枠を構成する場合は、タイムゾーンを指定できません。Google Cloud CLI または API を使用する場合は、UTC で時刻が表示されます。コンソールでは、ローカル タイムゾーンを使用して時刻が表示されます。Google Cloud

--maintenance-window-start など、より詳細なフラグを使用する場合は、値の一部としてタイムゾーンを指定できます。タイムゾーンを省略すると、ローカル タイムゾーンが使用されます。時間は常に UTC で保存されます。

メンテナンスの時間枠を表示する場合

クラスタの情報を表示するとき、情報の表示方法に応じて、メンテナンスの時間枠のタイムスタンプは UTC またはローカル タイムゾーンで表示されます。

  • コンソールを使用してクラスタの情報を表示する場合、時刻は常にローカル タイムゾーンで表示されます。 Google Cloud
  • gcloud CLI を使用してクラスタの情報を表示する場合、時刻は常に UTC で表示されます。

どちらの場合も、RRULE は常に UTC です。たとえば、曜日を指定すると、日付は UTC で表示されます。

クラスタのメンテナンスの時間枠を構成する

Distributed Cloud コネクテッドでは、Distributed Cloud コネクテッド クラスタごとにメンテナンスの時間枠を指定できます。この時間枠は、指定した時間と頻度でのみ Distributed Cloud ソフトウェアを更新するように Google に指示します。

Distributed Cloud コネクテッド クラスタのメンテナンスの時間枠には、次のルールが適用されます。

詳細な手順については、 クラスタのメンテナンスの時間枠を構成するをご覧ください。

失敗したハードウェアの修理

Google が Distributed Cloud コネクテッド ハードウェアの障害を検出した場合、次のいずれかを行います。

  • Google 所有の Distributed Cloud ハードウェアの場合、Google は 3 営業日以内に訪問日をスケジュールしようとします。Google 認定の技術者が必要な診断と修理を行うには、Distributed Cloud コネクテッド ハードウェアへのアクセス権を付与する必要があります。

  • お客様所有の Distributed Cloud ハードウェアの場合、Google はお客様と Google 認定の SI に問題について通知します。Distributed Cloud コネクテッド ハードウェアを提供した SI と協力して、技術者の訪問をスケジュールし、必要な診断と修理を行う必要があります。

Distributed Cloud コネクテッド ハードウェアの障害が発生した場合、Distributed Cloud コネクテッド ハードウェアが自己暗号化ディスク（SED）ストレージを使用しているかどうかに応じて、次のいずれかのシナリオが適用されます。

  • Distributed Cloud コネクテッド ラック は、SED 以外のドライブにデータを保存します。Google または Google 認定の SI がオンサイト修理を行う場合、サービスを開始する前に、影響を受ける Distributed Cloud コネクテッド マシンからすべてのディスク ドライブが取り外され、修理期間中はお客様が保管します。

  • Distributed Cloud コネクテッド サーバー は、SED ドライブにデータを保存します。マシンに障害が発生した場合、Google または Google 認定の SI がマシン全体を交換します。マシンがお客様の施設から取り外される前に、Google はすべてのドライブからデータが安全に消去されていることを確認します。

その他の障害点

Google の管理外であり、Distributed Cloud コネクテッドの可用性に影響する可能性がある Distributed Cloud インストールの次の側面を維持する責任はお客様にあります。

  • Distributed Cloud コネクテッド ハードウェアに保存することを選択したすべてのデータ。これには、機能する冗長バックアップと、Distributed Cloud コネクテッド ハードウェアを Google に返却する前のデータのエクスポートが含まれます。
  • 電源。
  • 周囲温度、湿度、冷却。
  • 物理ハードウェアのセキュリティ。
  • ローカル ネットワークのセキュリティ。
  • ローカル ネットワークとインターネット接続。Distributed Cloud コネクテッドは、 7 日ごとに 再接続して、セキュリティ トークンと暗号鍵を更新し、 ロギング データと管理データを同期する必要があります。 Google Cloud

次のステップ