ライブ、再起動および手動移行: コンピュート・インスタンスの新しいホストへの移動
このトピックでは、インフラストラクチャ・メンテナンス・イベント中の仮想マシン(VM)およびベア・メタル・インスタンスの再配置に関連するメンテナンス・アクションについて説明します。使用可能なアクションを示します:
専用仮想マシン・ホストの移行:インフラストラクチャ・メンテナンス・イベント中に専用仮想マシン・ホストを再配置する方法の詳細は、「専用仮想マシン・ホストのメンテナンス・リブート移行の管理」を参照してください。
Oracle Platform Services: Oracle Platform Servicesで作成され、コンパートメント
ManagedCompartmentForPaaSにあるインスタンスの場合、特定のPlatform Serviceのインタフェースを使用してインスタンスを再起動する必要があります。 ライブ移行
ライブ移行は、VMの実行中にVMを物理サーバーから別の物理サーバーに移動するメカニズムです。ライブ移行中は、コンピュート・サービスがメモリーおよびすべての仮想コンポーネントを新しいターゲットVMインスタンスにコピーするときに、ソースVMインスタンスは引き続き実行されます。コピーが完了すると、システムが新しいVMに切り替わったときに、通常は数十ミリ秒単位で測定されるわずかな一時停止のみが発生します。
インフラストラクチャ・メンテナンス・イベント中に、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インスタンス:
-
標準/GPUシェイプ(フレックスを含む):メンテナンス期日から24時間以内に、VMインスタンスは停止され、正常なホストに移行および再起動されます。移行中に短い停止時間が発生します。
メンテナンス期日前にインスタンスを事前に再起動することで、停止時間が発生するタイミングを制御できます。
-
DenseIOシェイプ(フレックスを含む):メンテナンス期日に、VMインスタンスは停止、再構築および再起動されます。メンテナンス・プロセス中に数時間の停止時間が発生します。
停止時間を最小限に抑え、ローカルにアタッチされたNVMeベースのSSDを削除する場合は、スケジュールされたメンテナンス時間までにインスタンスを事前に再起動できます。インスタンスは正常なホストに再起動移行され、SSDは完全に削除されます。移行中に短い停止時間が発生します。
-
-
ベア・メタル・インスタンス:
-
標準シェイプ: メンテナンス期日から24時間以内に、ベア・メタル・インスタンスは停止され、正常なホストに移行されて、再起動されます。移行中に短い停止時間が発生します。
メンテナンス期日前にインスタンスを事前に再起動することで、停止時間が発生するタイミングを制御できます。
再起動移行が失敗した場合、Oracle Cloud Infrastructureは通知を送信します。インスタンスを正常なホストに手動で移行する必要があります。
-
インスタンスを再起動移行すると、「メンテナンス再起動」フィールドがクリアされます。この変化は、インスタンスが正常に移動されたことを示します。
コンソール、CLIまたはSDKを使用して、VMインスタンスを再起動移行します。オペレーティング・システムからインスタンスを再起動しても、インスタンスは新しいハードウェアに移行されません。
移行後、デフォルトでは、インスタンスはメンテナンス・イベントの前と同じライフサイクル状態にリカバリされます。再起動移行後にインスタンスをリカバリする代替プロセスがある場合は、正常なハードウェアに移行した後もインスタンスが停止したままとなるように構成できます。移行後のインスタンスのライフサイクル状態などの移行オプションを構成する方法の詳細は、メンテナンス・イベント中のインスタンス可用性の設定を参照してください。
再起動移行の前提条件
インスタンスを再起動移行のために準備します。
/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のバックアップを作成することをお薦めします。 - 「メンテナンス」タブのメンテナンス・イベントが
Succeeded状態であることを確認します。(Succeeded、Canceled、Failedの3つの可能な最終状態があります。 - インスタンス上ですべてのアプリケーションを開始してテストします。
-
Dense I/Oインスタンスで、NVMeベースのSSDをリストアする場合:
- ローカルNVMeデバイスのバックアップに使用されるブロック・ボリュームをアタッチします。
- データを新しいインスタンスのNVMeストレージにコピーします。
- ブロック・ボリュームをデタッチし、オプションで削除します。
再起動移行によるベア・メタル・インスタンスの移動
前提条件の完了後:
- 実行中のアプリケーションを停止します。
-
コンソール、CLIまたはSDKを使用して、インスタンスを再起動します。再起動移行は、オペレーティング・システムからインスタンスを再起動するときに実行されません。
- コンソールの使用: 「インスタンスの再起動」ダイアログ・ボックスで、「インスタンスを正常なホストに再起動移行」オプションを選択します。
- CLIまたはSDKの使用: InstanceAction操作で、実行するアクションとして値
REBOOTMIGRATEを渡します。インスタンスをただちに再起動移行するには、timeScheduled属性を空のままにします。
- 「メンテナンス」タブのメンテナンス・イベントが
Succeeded状態であることを確認します。(Succeeded、Canceled、Failedの3つの可能な最終状態があります。 - インスタンス上ですべてのアプリケーションを開始してテストします。
手動移行によるインスタンスの移動
「メンテナンス再起動」フィールドに日付が表示されていないインスタンス(コンソール、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ストレージにコピーしてから、ボリュームをデタッチします。 - インスタンスを起動します。
- インスタンス上ですべてのアプリケーションを開始してテストします。
- 必要に応じて、自動的に起動するようにアプリケーションを構成します。
- 必要なタグを再作成します。
- (オプション)インスタンスとアプリケーションが正常であることを確認した後で、ボリュームのバックアップを削除できます。