仮想マシン（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 がインスタンスの再起動または終了を行うまで待機する最大時間を設定します。
- ローカル SSD の復元時間: ホストエラーの検出後、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 の手動でのライブ マイグレーションの詳細を見る。