17 Oracle Database Appliance上の仮想プラットフォームからKVMへの移行
Oracle Database Applianceデプロイメントを仮想化プラットフォームからKVMに移行する方法を理解します。
- 仮想化プラットフォームからKVMへのOracle Database Applianceの移行について
仮想化されたプラットフォーム・デプロイメントをKVMに移行する方法を理解します。 - Oracle Database Appliance上の仮想プラットフォームからKVMへの移行
Oracle Database ApplianceのVirtualized PlatformからKVMに移行する手順について理解します。
仮想化プラットフォームからKVMへのOracle Database Applianceの移行について
仮想化されたプラットフォーム・デプロイメントをKVMに移行する方法を理解します。
データ保存再プロビジョニング機能を使用して、Oracle Database Appliance仮想化プラットフォーム・デプロイメントをKVMに移行できます。
移行に関する考慮事項
移行に関する考慮事項は次のとおりです:
- 仮想化されたプラットフォーム(Oracle VM)のローカル・リポジトリは移行されません。 VMやvdisksなどのローカル・リポジトリ内のオブジェクトは、移行後にバックアップして手動で移行する必要があります。
- リポジトリのマウント・ポイント(Oracle ACFSファイル・システム)は、
/u01/app/sharedrepo
から/u05/app/sharedrepo
に変更されます。 - VMテンプレートはオフラインVMとして移行されます。 次のコマンドを使用してVMをクローニングするテンプレートとして使用できます:
odacli clone-vm -n source_vm_name -cn cloned_vm_name
移行後に必要ない場合、コマンド
odacli delete-vm -n vm_name
を使用してこれらのVMテンプレートを削除できます。 - コア数が奇数のCPUプールは、KVMのCPUプールにはコア数が偶数である必要があるため、移行されません。 移行後にCPUプールを手動で作成し、影響を受けるVMにCPUプールを割り当てます。
- dom0上の
net1
ブリッジ(通常はOVMおよびpriv1
上のパブリック・ネットワークとして使用)は、ODA_BASEのプライベート・ネットワークとして使用され、KVM vnetworkに移行されません。 - ブリッジなしでアタッチされたVLANを持つVMは、pubnet vnetworkとして移行されます。
vm.cfg
で直接行った手動カスタマイズは移行されません。- デフォルトでは、移行後のVMではvirtioが使用されます。 必要なvirtioサポートがないOracle Linux 5などの以前のLinuxバージョンVMでは、ブートストラップが正しく行われません。 バス・タイプをvirtioからIDEに変更してから、VMを再起動できます。
odacli modify-vm -n vm_name -dev bus=ide
これをデフォルトのvirtioに戻すには:odacli modify-vm -n vm_name -dev bus=virtio
この問題は、virtioが設置されていないMicrosoft Windows VMでも発生する可能性があります。
- repo、cpu pool、vlan、vdisk、vmtテンプレートなどのインフラストラクチャ・リソースの移行中に移行が失敗した場合、作成されたリソースは元に戻されます。 問題が修正されたら、移行のためにコマンド
odacli migrate-ovm2kvm
を再実行します。 -
VMの移行中に移行が失敗した場合、移行は続行され、失敗した各VM移行に対してコマンド
odacli describe-ovm2kvm
を実行するとエラーが表示されます。 - 移行後、VM内の実際のデバイス名が変更される可能性があります。 たとえば、仮想化プラットフォーム・デプロイメントの
/dev/xvda
は、KVMへの移行後に /dev/vda
に変更される可能性があります。 たとえば、VM内の/etc/fstab
に/dev/xvda
などのデバイス名がリストされている場合、移行後にデバイス名の変更のためにVMの起動に失敗することがあります。 仮想化されたプラットフォーム・デプロイメントで/etc/fstab
のデバイス名を使用する場合は、移行前にラベルまたはUUIDで名前を変更します。 ファイル・システム・マウント表のラベルまたはUUIDの使用方法(/etc/fstab
)の詳細は、https://docs.oracle.com/en/operating-systems/oracle-linux/7/fsadmin/ol7-fsadmin.html#ol7-s1-fsadminの「Oracle Linux 7ファイル・システムの管理ガイド」を参照してください。 - VMのネットワーク構成は移行後に変更される可能性があります。 移行後にVMに接続できない場合は、コマンド
virsh console vm_name
を使用してコンソールからVMにログインし、必要に応じてネットワークを確認して再構成します。 構成ステップはオペレーティング・システムに固有です。 詳細は、オペレーティング・システムのドキュメントを参照してください。 - Microsoft Windows VMを移行する前に、Windows用のvirtioドライバを設置します。 構成手順については、My Oracle Supportノート2773840.1 「ODAベア・メタルでのMS Windowsゲストのステップ」を参照してください。
移行プロセスのステップ
このプロセスのステップは次のとおりです:
odaupgradeutil.sh
ユーティリティを実行します。- 両方のノードでアプライアンスを再イメージします。
- コマンド
odacli restore-node -g
を実行してOracle Gridインフラストラクチャで再プロビジョニングし、odacli restore-node -d
を実行して保存されたデータベースを再プロビジョニングします。 odacli migrate-ovm2kvm
コマンドを実行して、仮想化プラットフォームからKVMに移行します。- コマンド
odacli describe-ovm2kvm
を実行し、移行レポートでエラーを確認します。 問題を修正し、操作を再試行してください。
Oracle Database Appliance上の仮想プラットフォームからKVMへの移行
Oracle Database ApplianceのVirtualized PlatformからKVMに移行する手順について理解します。
警告:
移行プロセス中にいつでもcleanup.plを実行しないでください。 これにより、ストレージ上のすべてのOracle ASMディスク・グループが消去され、すべてのOracle仮想化プラットフォーム・リソースを保持してOracle Database Applianceシステムを再プロビジョニングすることはできません。ノート:
移行後、VM内の実際のデバイス名が変更される可能性があります。 たとえば、仮想化プラットフォーム・デプロイメントの/dev/xvda
は、KVMへの移行後に / dev/vda
に変更される可能性があります。 たとえば、VM内の/etc/fstab
に/dev/xvda
などのデバイス名がリストされている場合、移行後にデバイス名の変更のためにVMの起動に失敗することがあります。 仮想化されたプラットフォーム・デプロイメントで/etc/fstab
のデバイス名を使用する場合は、移行前にラベルまたはUUIDで名前を変更します。 ファイル・システム・マウント表のラベルまたはUUIDの使用方法(/etc/fstab
)の詳細は、https://docs.oracle.com/en/operating-systems/oracle-linux/7/fsadmin/ol7-fsadmin.html#ol7-s1-fsadminの「Oracle Linux 7ファイル・システムの管理ガイド」を参照してください。
ノート:
最初のノード(node0
)でODA_BASE
でodaupgradeutil
を実行します。 node0
でステップ3から5が正常に完了した後、2番目のノード(node1
)でODA_BASE
でステップ3から5を実行します。
次のステップを実行します。 両方のノードでコマンドを実行します。
ノート:
Oracle Database Appliance仮想化プラットフォームからベア・メタル・システムへのデータベースの移行が完了しました。 データベースをOracle Database Applianceベア・メタル・システムからDBシステムに移行するには、https://support.oracle.com/rs?type=doc&id= 2869506.1にあるMy Oracle Supportノート2869506.1を参照してください。