17 Oracle Database Applianceでの仮想化プラットフォームからKVMへの移行
Oracle Database Applianceデプロイメントを仮想化プラットフォームからKVMに移行する方法を理解します。
- 仮想化プラットフォームからKVMへのOracle Database Applianceの移行について
仮想化プラットフォーム・デプロイメントをKVMに移行する方法を理解します。 - Oracle Database Applianceでの仮想化プラットフォームからKVMへの移行
Oracle Database Applianceで仮想化プラットフォームからKVMに移行する手順を理解します。
仮想化プラットフォームからKVMへのOracle Database Applianceの移行について
仮想化プラットフォーム・デプロイメントをKVMに移行する方法を理解します。
データ保存再プロビジョニング機能を使用して、Oracle Database Appliance仮想化プラットフォーム・デプロイメントをKVMに移行できます。
移行に関する考慮事項
移行に関する考慮事項は次のとおりです:
- 仮想化プラットフォーム(Oracle VM)のローカル・リポジトリは移行されません。VMやvdiskなどのローカル・リポジトリ内のオブジェクトは、移行後にバックアップして手動で移行する必要があります。
- リポジトリ(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テンプレートを削除できます。 - KVMのCPUプールには偶数のコアが必要であるため、コア数が奇数のCPUプールは移行されません。移行後にCPUプールを手動で作成し、影響を受けるVMにCPUプールを割り当てます。
- OVMのパブリック・ネットワークとして通常使用されるdom0の
net1
ブリッジおよびODA_BASEのプライベート・ネットワークとして使用されるpriv1
は、KVM vnetworkに移行されません。 - ブリッジがないVLANがアタッチされているVMは、pubnet vnetworkとして移行されます。
vm.cfg
で直接行われた手動のカスタマイズは移行されません。- デフォルトでは、移行後のVMはvirtioを使用します。以前のLinuxバージョンのVM (必要なvirtioサポートがないOracle Linux 5など)では、ブートストラップが正しく実行できません。バス・タイプを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、vmtemplateなどのインフラストラクチャ・リソースの移行中に移行が失敗した場合、作成されたリソースは元に戻されます。問題が修正されたら、移行のためにコマンド
odacli migrate-ovm2kvm
を再実行します。 -
VMの移行中に移行が失敗した場合、移行は続行され、失敗したVM移行ごとにコマンド
odacli describe-ovm2kvm
を実行するとエラーが表示されます。 - 移行後に、VM内の実際のデバイス名が変更される可能性があります。たとえば、仮想化プラットフォーム・デプロイメントの
/dev/xvda
は、KVMへの移行後に/dev/vda
に変更される可能性があります。たとえば、/dev/xvda
などのデバイス名がVM内の/etc/fstab
にリストされている場合は、移行後にデバイス名の変更によってVMが起動に失敗する可能性があります。仮想化プラットフォーム・デプロイメントで/etc/fstab
のデバイス名を使用する場合は、移行前にラベルまたはUUIDで名前を変更します。ファイル・システムのマウント表(/etc/fstab
)のラベルまたはUUIDを使用する方法の詳細は、『Oracle Linux 7ファイル・システムの管理』(https://docs.oracle.com/en/operating-systems/oracle-linux/7/fsadmin/ol7-fsadmin.html#ol7-s1-fsadmin)を参照してください。 - 移行後に、VMのネットワーク構成が変更される可能性があります。移行後にVMに接続できない場合は、コマンド
virsh console vm_name
を使用してコンソールからVMにログインし、必要に応じてネットワークを確認して再構成します。構成ステップは、オペレーティング・システムに固有です。詳細は、オペレーティング・システムのドキュメントを参照してください。 - Microsoft Windows VMを移行する前に、Windows用のvirtioドライバをインストールします。構成手順は、My Oracle Supportノート2773840.1『Steps for MS Windows guests on ODA Bare Metal』を参照してください。
移行プロセスのステップ
このプロセスのステップは次のとおりです:
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で仮想化プラットフォームからKVMに移行する手順を理解します。
警告:
移行プロセス中は、決してcleanup.plを実行しないでください。実行すると、ストレージのすべてのOracle ASMディスク・グループが消去され、Oracle仮想化プラットフォームのすべてのリソースがそのままの状態でOracle Database Applianceシステムを再プロビジョニングすることができなくなります。ノート:
移行後に、VM内の実際のデバイス名が変更される可能性があります。たとえば、仮想化プラットフォーム・デプロイメントの/dev/xvda
は、KVMへの移行後に/dev/vda
に変更される可能性があります。たとえば、/dev/xvda
などのデバイス名がVM内の/etc/fstab
にリストされている場合は、移行後にデバイス名の変更によってVMが起動に失敗する可能性があります。仮想化プラットフォーム・デプロイメントで/etc/fstab
のデバイス名を使用する場合は、移行前にラベルまたはUUIDで名前を変更します。ファイル・システムのマウント表(/etc/fstab
)のラベルまたはUUIDを使用する方法の詳細は、『Oracle Linux 7ファイル・システムの管理』(https://docs.oracle.com/en/operating-systems/oracle-linux/7/fsadmin/ol7-fsadmin.html#ol7-s1-fsadmin)を参照してください。
ノート:
まず、1つ目のノード(node0
)でODA_BASE
に対してodaupgradeutil
を実行します。node0
でステップ3から5が正常に完了したら、2つ目のノード(node1
)でODA_BASE
に対してステップ3から5を実行します。
次のステップに従います。コマンドは両方のノードで実行します。
ノート:
Oracle Database Appliance仮想化プラットフォームからベア・メタル・システムへのデータベースの移行が完了しました。Oracle Database Applianceベア・メタル・システムからDBシステムにデータベースを移行するには、My Oracle Supportノート2869506.1 (https://support.oracle.com/rs?type=doc&id=2869506.1)を参照してください。