仮想マシン（VM）インスタンスまたはベアメタル インスタンスの存続期間中、インスタンスが実行されているホストマシンで複数のホストイベントが発生する可能性があります。ホストイベントには、Compute Engine インフラストラクチャの定期メンテナンスや、まれにホストエラーが含まれます。ホスト メンテナンス ポリシーを構成することで、ホストイベントの発生中または発生後に VM インスタンスとベアメタル インスタンスがどのように応答するかを選択できます。
デフォルトでは、ほとんどのインスタンスはホスト イベント中にライブ マイグレーションするように設定されています。この動作をオーバーライドして、インスタンスを終了し、必要に応じて再起動するように明示的に設定できます。一部のマシンタイプ（ベアメタル インスタンスや GPU が接続された VM など）は、ライブ マイグレーションをサポートしていません。これらのインスタンスは、ホストイベント中に終了します。詳細については、メンテナンスと再起動の動作をご覧ください。
ホストイベントの種類
ホストイベントには次の 2 種類があります。次のセクションで詳しく説明します。
インスタンスが応答しなくなった場合、インスタンスの再起動または終了がトリガーされることもあります。
メンテナンス イベント
メンテナンス イベントは、Compute Engine が VM をホストサーバーから移動する必要があるメンテナンスまたは修理アクティビティを実行する必要がある場合です。サポートされているインスタンスタイプでライブ マイグレーションのホスト メンテナンス ポリシーを有効にすると、Compute Engine によってインスタンスが新しいホストに移動されるため、アプリケーションの中断は最小限に抑えられます。
メンテナンス イベント中のインスタンスの動作は、インスタンスのテナンシーとマシンタイプによって異なる場合があります。次の表に、計画されたメンテナンス イベントの動作をまとめます。
| ホスト テナンシー | メンテナンス イベントの頻度 |
ライブ マイグレーションのサポート | ホストの選択 |
|---|---|---|---|
| マルチテナント（共有） | 隔週 | ○ | Compute Engine |
| 単一テナント | 4～6 週間ごと | ホスト メンテナンス ポリシーによって異なる | ホスト メンテナンス ポリシーによって異なる |
| X4 | 最小 90 日 | × | Compute Engine |
| C3 | 30 日以上 | × | Compute Engine |
また、Compute Engine は、同じホストにインスタンスを保持することで、軽量のハイパーバイザとネットワークのアップグレードをバックグラウンドで無停止で適用します。
ホストエラー
ホストエラー（compute.instances.hostError）は、コンピューティング インスタンスをホストしている物理マシンまたはデータセンター インフラストラクチャで、インスタンスがクラッシュするようなハードウェアまたはソフトウェアの問題が発生したことを意味します。ハードウェア全体の障害やその他のハードウェアの問題でホストエラーが発生すると、インスタンスのライブ マイグレーションが停止することがあります。インスタンスが自動的に再起動するように設定されている場合（デフォルト設定）、Compute Engine は通常、エラーが検出されてから 3 分以内にインスタンスを再起動します。問題により、再起動には最大 5.5 分かかります。
ホストエラーが通知される前に、コンピューティング インスタンスが応答しなくなることがあります。ホストエラー回復タイムアウト（プレビュー）を設定することで、Compute Engine がインスタンスの再起動または終了を待機する時間を短縮できます。詳細については、可用性ポリシーを設定するをご覧ください。
物理的なハードウェアとソフトウェアの障害は、発生する可能性はありますが、まれな現象です。起こりうる破壊的なシステム イベントからアプリケーションやサービスを保護するため、次の方策を確認してください。
Google は、App Engine や App Engine フレキシブル環境などのマネージド サービスも提供しています。
ホスト メンテナンス ポリシーの概要
インスタンスのホスト メンテナンス ポリシーは、次のイベント中にインスタンスがどのように動作するかを決定します。
- メンテナンス イベント
- ホストエラー イベントまたはインスタンスが応答しない
Compute Engine が別のホストへのライブ マイグレーションを行っている間、ホストのメンテナンス中もインスタンスの実行を継続するように構成できます。また、インスタンスの停止を選択することもできます。
インスタンスのホスト メンテナンス ポリシーを変更するには、次の設定を構成します。
- メンテナンスの動作: メンテナンス イベントが発生した場合にインスタンスをライブ マイグレーションするか、または停止するかを設定します。
- 再起動の動作: インスタンスがクラッシュした場合、ホストエラーが発生した場合、または応答しなくなった場合に、Compute Engine がインスタンスを再起動するか停止するかを設定します。
- ホストエラーの検出時間: インスタンスが応答していないことを検出した後、Compute Engine がインスタンスの再起動または終了を行うまで待機する最大時間を設定します。
- Local SSD recovery time: ホストエラーの検出後、Compute Engine がローカル SSD ディスクのデータの復元に費やす最大時間。復元が正常に実行されないまま指定時間が経過すると、ローカル SSD データは失われます。
インスタンスのホスト メンテナンス ポリシーはインスタンスの動作を定義します。このポリシーは、必要なときにいつでも更新できます。
メンテナンスと再起動の動作
ホストイベントが発生すると、コンピューティング インスタンスはライブ マイグレーションを使用するか、インスタンスを終了できます。インスタンスが終了した場合は、インスタンスを手動で再起動するか、Compute Engine に自動的に再起動させるかを選択できます。
次のマシンシリーズはライブ マイグレーションをサポートしておらず、ホストイベント中に終了します。
- Z3 インスタンスと X4 インスタンスは、その場で再起動します。
- C3 ベアメタル インスタンスは終了して再起動します。つまり、別のホストで再起動される可能性があります。
- GPU を使用するインスタンス
- TPU を使用するインスタンス
ライブ マイグレーション
デフォルトでは、ほとんどのインスタンスタイプはライブ マイグレーションに設定されています。ただし、次のインスタンスタイプは除きます。
- GPU と TPU が接続されたインスタンス
- C3 ベアメタル インスタンスまたは X4 インスタンス
- Z3 インスタンス
ライブ マイグレーション中、Compute Engine はインスタンスをインフラストラクチャのメンテナンス イベントから自動的に移行します。インスタンスは移行中も実行されます。通常、ほとんどのインスタンスのパフォーマンスには大きな影響は出ませんが、まれにインスタンスのパフォーマンスが一時的に低下する場合があります。これは、継続的な稼働を必要とし、一時的なパフォーマンスの低下に対応できるインスタンスに適しています。
インスタンスを移行する際、Compute Engine はゾーン オペレーションのリストとシステム イベントログに公開されるシステム イベントを報告します。このイベントを確認するには、特定のゾーンに対する Compute Engine のオペレーションを表示します。ライブ マイグレーション イベントには、次のオペレーション タイプがあります。
compute.instances.migrateOnHostMaintenance
終了して再起動
インスタンスをライブ マイグレーションしない場合や、インスタンスタイプがライブ マイグレーションをサポートしていない場合は、代わりに、ホスト イベントが発生したときに Google Cloud がインスタンスを停止できるようにします。この構成では、ホストイベントが発生すると、Compute Engine はソフト電源オフ シグナルを送信してインスタンスをシャットダウンします。その後、インスタンスが完全にシャットダウンするまで 60 秒間待機し、インスタンスのステータスを TERMINATED に設定します。インスタンスが 60 秒以内に正常にシャットダウンしない場合、インスタンスは強制的に終了されます。
このオプションは、インスタンスが常に最大限のパフォーマンスを要求し、アプリケーション全体がインスタンス障害や再起動に対処するように構築されている場合に最適です。
ホストイベントが原因で Compute Engine がインスタンスを停止すると、ゾーン オペレーションのリストとシステム イベントログに公開されるシステム イベントが報告されます。このイベントを確認するには、特定のゾーンに対する Compute Engine のオペレーションを表示します。インスタンスの終了イベントには、次のオペレーション タイプがあります。
compute.instances.terminateOnHostMaintenance
自動再起動
メンテナンス イベントが発生したときにインスタンスを停止するように構成されている場合、または基盤となるハードウェアの問題でインスタンスがクラッシュした場合、Compute Engine はインスタンスを自動的に再起動できます。インスタンスは、同じホストサーバーで再起動するか、メンテナンス イベントに参加していない同じゾーンの別のサーバーに移動されます。
デフォルトでは、Compute Engine は、アタッチされたローカル SSD ディスクを使用してインスタンスの復元を 1 時間試みます。時間制限に達すると、Compute Engine は同じゾーンの別のホストサーバーでインスタンスの再起動を試みます。 Z3 インスタンスと X4 インスタンスのデフォルトの待機時間は異なります。これらのインスタンス タイプは、インスタンスの終了後に同じホストサーバーで再起動されます。
自動再起動を構成するには、ホスト メンテナンス ポリシー フィールド automaticRestart を true に設定します。この設定は、ゾーンの停止が原因でインスタンスがオフラインになった場合、またはゲスト OS 内で sudo shutdown を呼び出すなどのユーザー操作によってインスタンスがオフラインになった場合には適用されません。
インスタンスを自動的に再起動する際、Compute Engine はゾーン オペレーションのリストに公開されているシステム イベントを報告します。このイベントを確認するために、特定のゾーンに対する Compute Engine のオペレーションが表示されます。自動再起動イベントには、次のオペレーション タイプがあります。
compute.instances.automaticRestart
インスタンスの終了後のディスクの永続性
Persistent Disk とHyperdisk はネットワーク接続ストレージであるため、インスタンスの再起動時に、Compute Engine はブートディスクとセカンダリ ディスクをインスタンスに再アタッチします。これらのディスク上のデータは、ライブ移行とインスタンスの再起動後も維持されます。
Compute Engine は、可能であれば、ホストイベントの後にローカル SSD ディスク上のデータを保持します。ただし、Compute Engine はローカル SSD データの永続性を保証しません。ローカル SSD ディスクは、次の場合に保持されます。
- インスタンスをライブ マイグレーション用に構成し、インスタンスにホスト メンテナンス イベントが発生した場合。
- ホストエラーが発生し、Compute Engine がタイムアウト制限内にインスタンスをローカル SSD ディスクに再接続します。
- 終了と自動再起動のみをサポートするローカル SSD ディスクがアタッチされたコンピューティング インスタンスは、メンテナンス イベントを実行します。インスタンスは、新しいホストに移行せずに、ローカル SSD データを保持したまま、その場で再起動します。
次の場合に、ローカル SSD ディスクは保持されません。
- ゲスト オペレーティング システムをシャットダウンし、インスタンスを強制的に停止します。
- ホスト メンテナンス イベントで停止するようにインスタンスを構成し、インスタンスにホスト メンテナンス イベントが発生した場合。
- ホストエラーが発生し、タイムアウトになる前に Compute Engine がディスクをインスタンスに再接続できない。この場合、ローカル SSD ディスクが復元されずにインスタンスが再起動されます。インスタンスが再起動すると、Compute Engine は再起動されたインスタンスに空のローカル SSD ディスクをアタッチします。インスタンスでこれらのディスクを使用するには、ディスクをフォーマットしてマウントする必要があります。元のローカル SSD ディスク上のデータは復元できません。
Google Cloud は、ローカル SSD データがそのまま残るように最善を尽くします。ただし、タイムアウトの場合など、データが復元できない場合があります。ローカル SSD ディスクが保持されるタイミングの詳細については、ローカル SSD データの永続性をご覧ください。
ローカル SSD の復元タイムアウト
ホストエラーが発生すると、Compute Engine はインスタンスにアタッチされているローカル SSD ディスクの復元を試みます。Compute Engine がデータの復元を試みる時間は、ホストポリシー localSsdRecoveryTimeout の設定で制御できます。
デフォルトでは、Compute Engine がデータの復元に費やす時間は 1 時間に設定されますが、この設定の有効な値は 0 ～ 168 で、1 時間単位で増やすことができます。Z3 インスタンスのデフォルト値は 6 です。つまり、Z3 インスタンスはタイムアウトの上限に達するまで 6 時間ローカル SSD データを復元しようとします。
ローカル SSD の復元タイムアウトを 0 に設定すると、Compute Engine はアタッチされているローカル SSD ディスクの復元を試行しません。インスタンスはできる限り早く再起動され、ローカル SSD データは復元できません。ローカル SSD データの復元よりもワークロードの再開の方が重要な場合は、この構成を使用します。
復元タイムアウトが 0 に設定されておらず、ローカル SSD データが復元される前に時間制限に達した場合、Compute Engine はローカル SSD ディスクなしでインスタンスを再起動します。Compute Engine は、再起動されたインスタンスに新しい空のローカル SSD ディスクをアタッチします。インスタンスでこれらのディスクを使用するには、ディスクをフォーマットしてマウントする必要があります。
Compute Engine がローカル SSD ディスクの復元を試行している間、インスタンスは REPAIRING 状態になります。この間、インスタンスとローカル SSD ディスクを使用できません。
ローカル SSD の復元タイムアウトを最大値の 168 に設定すると、Compute Engine がローカル SSD ディスクの復元を試みる間、インスタンスは最大 7 日間 REPAIRING 状態のままになります。
ローカル SSD ディスクの復元を停止する
Compute Engine が復元タイムアウトの上限に達する前に、ローカル SSD ディスクの復元プロセスを中断できます。これを行うには、--discard-local-ssd=True フラグを指定して gcloud compute instances stop コマンドを使用します。
このコマンドは、復元プロセスを停止し、コンピューティング インスタンスを停止し、ローカル SSD データを破棄します。その後、インスタンスを再起動できます。詳細については、ローカル SSD を使用してインスタンスを停止するをご覧ください。
ローカル SSD の復元タイムアウトの設定については、インスタンス ホスト メンテナンス ポリシーを設定するをご覧ください。
メンテナンスのスケジュール設定
Google Cloud には、メンテナンスをより厳密に管理できる機能が用意されています。特定のマシンファミリーを使用すると、メンテナンス設定を指定し、Cloud Logging、インスタンスのメタデータ サーバー、gcloud CLI compute instances describe コマンド、または REST instances.describe メソッドから今後のメンテナンス イベントの通知を受け取ることができます。通知を受け取ったら、スケジュールされたメンテナンスの開始時間を任意で選択できます。スケジュール設定されたメンテナンスをトリガーしない場合、メンテナンス イベントは通知時間の終了時に発生します。これは、通知に記載されているスケジュール時間です。
これらの機能とホスト メンテナンス ポリシーを組み合わせて、ワークロードに適したメンテナンス スケジュールをカスタマイズできます。
次のステップ
- ライブ マイグレーションの詳細を見る。
- 詳しくは、インスタンス ホスト メンテナンス ポリシーの設定をご覧ください。
- ライブ マイグレーションの通知取得の詳細を見る。
- ホスト メンテナンスのシミュレーションの詳細を確認する。 + GPU ホスト メンテナンス イベントの処理の詳細を確認する。
- 単一テナント VM の手動でのライブ マイグレーションの詳細を見る。