ライブ、再起動および手動移行: コンピュート・インスタンスの新しいホストへの移動
このトピックでは、インフラストラクチャ・メンテナンス・イベント中の仮想マシン(VM)およびベア・メタル・インスタンスの再配置に関連するメンテナンス・アクションについて説明します。使用可能なアクションを示します:
専用仮想マシン・ホストの移行:インフラストラクチャ・メンテナンス・イベント中に専用仮想マシン・ホストを再配置する方法の詳細は、「専用仮想マシン・ホストのメンテナンス再起動移行の管理」を参照してください。
Oracle Platform Services: For instances that were created with Oracle Platform Services and located in the compartment
ManagedCompartmentForPaaS, you must use the interface for the specific Platform Service to reboot the instances. ライブ移行
異常なインスタンスは、既存のインスタンスの実行中に正常なホストにコピーされます。実行中のインスタンスの中断は最小限です。
インフラストラクチャ・メンテナンス・イベント中に、Oracle Cloud Infrastructureは、メンテナンスが必要な物理VMホストから正常なVMホストに、実行中のインスタンスの中断を最小限にして、サポートされているVMインスタンスをライブ移行します。
インスタンスをライブ移行できない場合、Oracle Cloud Infrastructureは14日から16日以内に再起動移行の期日をスケジュールし、通知を送信します。期日までにインスタンスを事前に再起動しない場合、インスタンスは再起動移行されます。
デフォルトでは、Oracle Cloud Infrastructureは、今後のメンテナンスに関する通知を送信せずにインスタンスをライブ移行します。ライブ移行が開始および終了すると、インフラストラクチャ・メンテナンス・イベントが発行されます。自動化を使用してインフラストラクチャ・メンテナンス・イベントを追跡できます。
ライブ移行のサポート
インスタンスを作成する場合は、ライブ移行と互換性のある設定を選択します。既存のインスタンス(サポートされている場合)では、ライブ移行と互換性のある設定を使用するようにインスタンスを編集することで、ライブ移行を有効にできます。ライブ移行と互換性のない設定の中には、インスタンスの作成後に編集できないものがあります。
次の表に、インスタンスのライブ移行との互換性を設定する条件を示します。インスタンスがライブ移行をサポートするには、すべての基準を満たす必要があります。
| カテゴリ | ライブ移行をサポートする基準 | インスタンスの作成後に設定を編集できますか。 |
|---|---|---|
| レルム | テナンシは商用レルムにあります。 | いいえ。 |
| シェイプ |
インスタンスは、次のいずれかのシェイプを使用します:
専用仮想マシン・ホスト上の他のVMシェイプ、ベア・メタル・インスタンスおよびインスタンスはライブ移行をサポートしていません。 |
はい、いくつかのシェイプについてです。インスタンスのシェイプを変更して、サポートされているシェイプにします。 または、インスタンスを終了(削除)しますが、関連付けられたブート・ボリュームを削除しないでください。その後、ライブ移行をサポートするシェイプを使用して、ブート・ボリュームを使用して新しいインスタンスを作成します。 |
| イメージ |
LinuxまたはWindowsのプラットフォーム・イメージを使用するインスタンスは、ライブ移行をサポートします。 カスタム・イメージまたはOracle Cloud Infrastructure Marketplaceイメージを使用するインスタンスの場合、Oracle Cloud Infrastructureはインスタンスのライブ移行を試みます。 |
いいえ。 |
| ネットワーク起動タイプ | インスタンスは準仮想化ネットワークを使用します。 | はい、ネットワーク起動タイプを編集します。 |
| 保護インスタンス | サポートされません。 | いいえ。 |
| Windows Defender Credential Guardが有効です | サポートされません。 | いいえ。 |
| 仮想ネットワーク・インタフェース・カード(VNIC) | 接続されているVNICの最大合計数は6です。 | はい。合計6個以下のVNICが接続されるまで、セカンダリVNICをデタッチおよび削除します。 |
インスタンスがライブ移行をサポートするかどうかを確認するには:
- ナビゲーション・メニューを開き、「コンピュート」をクリックします。「コンピュート」で、「インスタンス」をクリックします。
- 関心のあるインスタンスをクリックします。
- インスタンスの「ライブ移行」フィールドを確認します。フィールドに「非互換性の表示」と表示されている場合、インスタンスはライブ移行をサポートしていません。
- (オプション)ライブ移行と互換性がない設定を確認するには、「非互換性の表示」をクリックします。
再起動移行
インスタンスが停止され、正常なホストに移行されてから再起動されます。移行中に短い停止時間が発生します。メンテナンス期日前にインスタンスを事前に再起動することで、停止時間が発生するタイミングを制御できます。
再起動移行は、標準、GPUおよびDense I/Oシェイプを使用するVMインスタンスと、標準シェイプを使用するベア・メタル・インスタンスでサポートされます。デフォルトのメンテナンス・アクションは、インスタンスのシェイプによって異なります。
-
VMインスタンス:
-
標準シェイプ: メンテナンス期日から24時間以内に、VMインスタンスは停止され、正常なホストに移行されて、再起動されます。移行中に短い停止時間が発生します。
メンテナンス期日前にインスタンスを事前に再起動することで、停止時間が発生するタイミングを制御できます。
-
Dense I/Oシェイプ: メンテナンス期日に、VMインスタンスは停止、再構築および再起動されます。メンテナンス・プロセス中に数時間の停止時間が発生します。
停止時間を最小限に抑え、ローカルにアタッチされたNVMeベースのSSDを削除する場合は、スケジュールされたメンテナンス時間までにインスタンスを事前に再起動できます。インスタンスは正常なホストに再起動移行され、SSDは完全に削除されます。移行中に短い停止時間が発生します。
-
-
ベア・メタル・インスタンス:
-
標準シェイプ: メンテナンス期日から24時間以内に、ベア・メタル・インスタンスは停止され、正常なホストに移行されて、再起動されます。移行中に短い停止時間が発生します。
メンテナンス期日前にインスタンスを事前に再起動することで、停止時間が発生するタイミングを制御できます。
再起動移行が失敗した場合、Oracle Cloud Infrastructureは通知を送信します。インスタンスを正常なホストに手動で移行する必要があります。
-
インスタンスを再起動移行すると、「メンテナンス再起動」フィールドがクリアされます。この変化は、インスタンスが正常に移動されたことを示します。
コンソール、CLIまたはSDKを使用して、VMインスタンスを再起動移行します。オペレーティング・システムからインスタンスを再起動しても、インスタンスは新しいハードウェアに移行されません。
移行後、デフォルトでは、インスタンスはメンテナンス・イベントの前と同じライフサイクル状態にリカバリされます。再起動移行後にインスタンスをリカバリする代替プロセスがある場合は、正常なハードウェアに移行した後もインスタンスが停止したままとなるように構成できます。移行後のインスタンスのライフサイクル状態などの移行オプションを構成する方法の詳細は、メンテナンス・イベント中のインスタンス可用性の設定を参照してください。
再起動移行の期限の延長
再起動移行がスケジュールされているインスタンスのメンテナンス期日を延長できます。標準シェイプを使用するVMおよびベア・メタル・インスタンスでは、期限の延長がサポートされています。Oracle Cloud Infrastructureは、期日を延長できる最遅の時間を決定します。
- ナビゲーション・メニューを開き、「コンピュート」をクリックします。「コンピュート」で、「インスタンス」をクリックします。
-
関心のあるインスタンスをクリックし、そのインスタンスの「メンテナンス再起動」フィールドを確認します。「期限の延長」ボタンがアクティブな場合は、メンテナンス期日を延長できます。
- 「期限の延長」をクリックします。
- 「新しい期限」ボックスで、新しい日時を選択します。
-
「変更の保存」をクリックします。
メンテナンス期日が延長されました。メンテナンス期日から24時間以内に、インスタンスは停止され、正常なホストに移行されて、再起動されます。移行中に短い停止時間が発生します。
- GetInstanceMaintenanceReboot操作を使用して、期日を延長できる最遅の時間を確認します。
-
次のいずれかを実行して、メンテナンス期日を延長します:
- VMおよびベア・メタル・インスタンス: InstanceAction操作を使用して、実行するアクションとして値
REBOOTMIGRATEを渡します。timeScheduled属性に更新された期日を指定します。 - VM: UpdateInstance操作を使用して、
timeMaintenanceRebootDue属性の更新された期日を渡します。
メンテナンス期日が延長されました。メンテナンス期日から24時間以内に、インスタンスは停止され、正常なホストに移行されて、再起動されます。移行中に短い停止時間が発生します。
- VMおよびベア・メタル・インスタンス: InstanceAction操作を使用して、実行するアクションとして値
再起動移行の前提条件
インスタンスを再起動移行のために準備します。
/etc/fstabに定義されているブロック・ボリュームで推奨オプションが使用されていることを確認します。- すべてのファイル・ストレージ・サービス(NFS)マウントで
nofailオプションが使用されていることを確認します。 - Oracle提供のスクリプトを使用してセカンダリVNICを構成する場合は、スクリプトが起動時に自動的に実行されることを確認します。
-
インスタンスでDense I/Oシェイプを使用している場合は、ローカルにアタッチされたNVMeベースのSSDをバックアップします:
再起動移行によるVMインスタンスの移動
前提条件の完了後:
- 実行中のアプリケーションを停止します。
-
コンソール、CLIまたはSDKを使用して、インスタンスを再起動します。再起動移行は、オペレーティング・システムからインスタンスを再起動するときに実行されません。
インスタンスがDense I/Oシェイプを使用する場合:
- コンソールの使用: 「インスタンスの再起動」ダイアログ・ボックスで、「NVMeベースのローカルSSDを削除し、正常なホストに再起動移行します」オプションを選択します。
- CLIまたはSDKの使用: InstanceAction操作で、
allowDenseRebootMigration属性をtrueに設定します。
注意
Dense I/Oインスタンスの場合、NVMeベースのSSDは完全に削除されます。次に進む前に、SSDのバックアップを作成することをお薦めします。 - 「メンテナンス再起動」フィールドに日付が表示されなくなったことを確認します。
- インスタンス上ですべてのアプリケーションを開始してテストします。
-
Dense I/Oインスタンスで、NVMeベースのSSDをリストアする場合:
- ローカルNVMeデバイスのバックアップに使用されるブロック・ボリュームをアタッチします。
- データを新しいインスタンスのNVMeストレージにコピーします。
- ブロック・ボリュームをデタッチし、オプションで削除します。
再起動移行によるベア・メタル・インスタンスの移動
前提条件の完了後:
- 実行中のアプリケーションを停止します。
-
コンソール、CLIまたはSDKを使用して、インスタンスを再起動します。再起動移行は、オペレーティング・システムからインスタンスを再起動するときに実行されません。
- コンソールの使用: 「インスタンスの再起動」ダイアログ・ボックスで、「インスタンスを正常なホストに再起動移行」オプションを選択します。
- CLIまたはSDKの使用: InstanceAction操作で、実行するアクションとして値
REBOOTMIGRATEを渡します。インスタンスをただちに再起動移行するには、timeScheduled属性を空のままにします。
- 移行後、「メンテナンス再起動」フィールドに日付が表示されなくなったことを確認します。
- インスタンス上ですべてのアプリケーションを開始してテストします。
手動移行によるインスタンスの移動
「メンテナンス再起動」フィールドに日付が表示されていないインスタンス(コンソール、CLIおよびSDKで確認できる)の場合は、インスタンスを手動で移動する必要があります。この方法では、インスタンスを削除(終了)した後で、保存されているブート・ボリュームから新しいインスタンスを起動する必要があります。追加のVNICを持つインスタンス、セカンダリIPアドレスを持つインスタンス、リモートでアタッチされたブロック・ボリュームを持つインスタンス、Trusted Platform Module (TPM)が有効になっているインスタンス、またはロード・バランサのバックエンド・セットに属しているインスタンスでは、追加のステップが必要です。
手動移行に関する制限事項と警告
手動移行を実行する場合は、次の制限事項と警告に注意してください:
- 予約済パブリック・プールからインスタンスに割り当てられたパブリックIPアドレスはすべて保持されます。予約済パブリックIPアドレス・プールから割り当てられていないものは変更されます。プライベートIPアドレスは変更されません。
- MACアドレス、CPUID、およびその他の一意のハードウェア識別子は、移行時に変更されます。インスタンスで実行されているアプリケーションが、ライセンスやその他の目的でこれらの識別子を使用している場合は、インスタンスを移行する前にこの情報をノートにとっておくと、変更の管理に役立ちます。
- 保護インスタンスには追加の制限があります。「保護インスタンスの移行」を参照してください。
手動移行の前提条件
-
インスタンスを移動する前に、重要な詳細事項をすべてドキュメント化します:
- インスタンスのリージョン、可用性ドメインおよびフォルト・ドメイン。
- インスタンスの表示名。
- すべてのプライベートIPアドレス、名前およびサブネット。インスタンスは複数のVNICを持つことができ、各VNICには複数のセカンダリIPアドレスがある可能性があることに注意してください。
- すべてのプライベートDNS名。インスタンスは複数のVNICを持つことができ、各VNICには複数のセカンダリIPアドレスがある可能性があります。それぞれのプライベートIPアドレスにDNS名がある可能性があります。
- 予約済パブリック・プールから割り当てられたパブリックIPアドレス。インスタンスは複数のVNICを持つことができ、各VNICには複数のセカンダリ・プライベートIPアドレスがある可能性があることに注意してください。それぞれのVNICおよびセカンダリ・プライベートIPアドレスには、パブリックIPアドレスがアタッチされていることがあります。
- インスタンスにアタッチされたブロック・ボリューム。
- インスタンスまたはアタッチされたリソースのタグ。
-
インスタンスを手動移行のために準備します。
/etc/fstabに定義されているブロック・ボリュームで推奨オプションが使用されていることを確認します。- すべてのファイル・ストレージ・サービス(NFS)マウントで
nofailオプションが使用されていることを確認します。 - MACアドレスを使用してセカンダリVNICに属するネットワーク・インタフェースを静的に定義していた場合(
/etc/sysconfig/network-scripts/ifcfg*に定義したインタフェースなど)、MACアドレスの変更のために、そのようなインタフェースは起動しなくなります。静的マッピングを削除します。 - Oracle提供のスクリプトを使用してセカンダリVNICを構成する場合は、スクリプトが起動時に自動的に実行されることを確認します。
インスタンスの手動移動
前提条件の完了後:
- 実行中のアプリケーションを停止します。
-
これらのアプリケーションが自動的に起動しないようにします。
注意
再配置されたインスタンスが最初に起動するとき、ブロック・ボリューム、セカンダリVNIC、またはそれらに依存するすべてのリソースは、アタッチされません。これらのリソースがないために、アプリケーションの問題が発生する可能性があります。 - ブロック・ボリュームまたはファイル・ストレージ・サービス(NFS)マウントをアンマウントします。
- すべてのブロック・ボリュームをバックアップします。
-
重要
Windowsインスタンスは汎用化または専用化しないでください。 -
終了したインスタンスのブート・ボリュームを使用して、新しいインスタンスを作成します。
インスタンス作成フローで、プライマリVNICにアタッチされていたプライベートIPアドレスを指定します。パブリックIPアドレスが予約済IPアドレス・プールから割り当てられていた場合は、必ず同じIPアドレスを割り当ててください。
- インスタンスの状態が「実行中」に変わったら、インスタンスを停止します。
- セカンダリVNICおよびセカンダリIPアドレスを再作成します。
-
ノート
このステップによって、ローカルNVMeデバイスのバックアップに使用されるすべてのボリュームが組み込まれます。データを新しいインスタンスのNVMeストレージにコピーしてから、ボリュームをデタッチします。 - インスタンスを起動します。
- インスタンス上ですべてのアプリケーションを開始してテストします。
- 必要に応じて、自動的に起動するようにアプリケーションを構成します。
- 必要なタグを再作成します。
- (オプション)インスタンスとアプリケーションが正常であることを確認した後で、ボリュームのバックアップを削除できます。