このページでは、Google Distributed Cloud コネクテッド インストールで高可用性を確保するためのベスト プラクティスについて説明します。Distributed Cloud Connected にはサービスレベル契約（SLA）はなく、このページで説明するサービスレベル目標（SLO）のみが提供されます。
可用性のレベルを選択して実装する
ビジネス要件に最適な Distributed Cloud 接続ワークロードの可用性レベルを選択する必要があります。たとえば、小売店のセルフチェックアウト アプリケーションは、モバイル ネットワーク事業者のエッジ RAN デプロイよりも可用性リスクがはるかに低くなります。
目標可用性は、緊急用に予約する Distributed Cloud の予備リソース容量に正比例します。次の表で、この関係について説明します。これらの見積もりには、メンテナンスの時間枠でスケジュールされたダウンタイムは含まれません。
Distributed Cloud コネクテッド ソフトウェアは、各物理マシンで一部のリソースを消費します。量は、Distributed Cloud 接続デプロイの特定の構成によって異なります。Google は、この量を測定し、ワークロードの分散を計画する際に考慮するために、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 connected の存続可能性モードをご覧ください。
ソフトウェア アップデートとメンテナンスの時間枠について
Google は、Distributed Cloud connected ソフトウェアを定期的に更新します。このソフトウェア更新は必須であり、無効にすることはできません。Distributed Cloud connected を使用すると、Distributed Cloud connected クラスタごとに個別のメンテナンス時間枠を指定できます。
メンテナンスの時間枠を使用すると、コントロール プレーンとノードの自動アップグレード実行のタイミングの管理が可能になり、ワークロードの一時的な中断を軽減できます。メンテナンスの時間枠は、次のような場合に役立ちます。
- オフピーク時: 自動アップグレードをトラフィックが減少するオフピーク時にスケジュールすることにより、ダウンタイムの可能性を最小限に抑えたい。
- オンコール: アップグレードをモニタリングして予期せぬ問題を管理できるように、アップグレードを勤務時間中に実行したい。
- 複数クラスタのアップグレード: 異なるリージョンの複数のクラスタに、指定した間隔で一度に 1 つずつアップグレードをロールアウトしたい。
Distributed Cloud Connected は、次のタイプのメンテナンス ウィンドウをサポートしています。
- メンテナンスの時間枠。Google が Distributed Cloud 接続クラスタでメンテナンスとソフトウェア アップグレードを実行できる時間枠を指定します。
- メンテナンスの除外の時間枠。Google が Distributed Cloud コネクテッド クラスタでメンテナンスやソフトウェア アップグレードを実行できない時間枠を指定します。メンテナンスの除外期間を構成するには、まずメンテナンスの時間枠を構成する必要があります。メンテナンス除外期間は、クラスタのメンテナンスの時間枠よりも優先されます。
自動アップグレードに加えて、Google は他のメンテナンス タスクを行うこともあります。このような場合、可能な限りクラスタのメンテナンスの時間枠が尊重されます。
タスクがメンテナンスの時間枠を超えて実行されると、Distributed Cloud Connected はタスクの一時停止を試みます。その後、次のメンテナンスの時間枠でこれらのタスクの再開を試みます。
Distributed Cloud connected は、メンテナンスの時間枠の外で予定外の緊急アップグレードをロールアウトする権限を有します。また、非推奨のソフトウェアや古いソフトウェアからの必須アップグレードがメンテナンス時間枠の外で自動的に行われることがあります。
クラスタはいつでも手動でアップグレードできます。手動のアップグレードは、メンテナンスの時間枠を無視してすぐに開始されます。
新規または既存のクラスタに対してメンテナンスの時間枠を設定する方法については、メンテナンスの時間枠の構成をご覧ください。
ソフトウェア アップデートの段階的リリース
ワークロードのダウンタイムを短縮するため、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 Connected を使用すると、Distributed Cloud Connected クラスタごとにメンテナンスの時間枠を指定できます。このウィンドウは、指定した時間と頻度でのみ Distributed Cloud ソフトウェアを更新するように Google に指示します。
次のルールは、Distributed Cloud 接続クラスタのメンテナンス ウィンドウに適用されます。
- Distributed Cloud コネクテッド クラスタのメンテナンスの時間枠を指定すると、Google は Distributed Cloud コネクテッド リリースノートで更新が発表されてから 48 時間後に、Distributed Cloud コネクテッド ソフトウェアを更新します。リリースノート ページで、Distributed Cloud Connected リリースノートの RSS フィードを購読すると、ソフトウェア アップデートがリリースされるたびに通知を受け取ることができます。
- メンテナンスの時間枠の最短時間は 5 時間です。Distributed Cloud 接続インストールとビジネス要件の複雑さに基づいて、より長い期間を指定できます。
- ソフトウェア アップデートの最小頻度は週 1 回です。メンテナンスの時間枠は、週単位または日単位で指定できます。特定の日付を含めたり除外したりできます。
- メンテナンスの時間枠がすでにスケジュールされている場合や、メンテナンスの時間枠が進行中の場合を除き、クラスタのメンテナンスの時間枠のスケジュールはいつでも変更できます。
- 指定した時間枠でソフトウェア アップデートが完了しない場合は、一時停止され、次のスケジュールされたメンテナンスの時間枠に再開されます。
詳細な手順については、クラスタのメンテナンスの時間枠を構成するをご覧ください。
故障したハードウェアの修理
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 Connected は、7 日ごとに Google Cloud に再接続して、セキュリティ トークンと暗号鍵を更新し、ロギング データと管理データを同期する必要があります。