Oracle Cloud Migrationsの基本

この項では、Oracle Cloud Migrationsを使用した移行の基本を理解し、理解する方法について説明します。

テスト移行および本番移行の理解

Oracle Cloud Migrationsサービス機能では、テスト目的と本番目的でのVM移行は区別されません。ただし、移行の計画および実行機能では、テストおよび本番の目的でVM移行が異なって処理されます。そのため、まずテスト移行を計画してから本番移行を実行することをお薦めします。

このような移行機能では、同じ移行プロジェクト内に2つの個別の移行計画を作成することをお薦めします。1つはテスト移行用で、もう1つは本番移行用です。

テスト移行計画の要件

テスト移行計画を作成するときは、次の要件を満たしていることを確認してください。

  • 仮想マシンとアプリケーションを運用可能にする: テスト移行の目的は、移行する仮想マシンとアプリケーションまたはサービスが、OCIへの移行後に完全に動作できるようにすることです。これらを運用可能にするためにさらに多くの変更が必要であると判断した場合は、このような変更を自動化するか、またはノートにとります。このアクションにより、本番の移行中に迅速かつ確実に再現できます。
  • 必要なネットワーク接続を構築: 移行したインスタンスに必要なネットワーク接続を宛先環境で構築していることを確認します。ネットワーク構成で必要な変更を行うには、移行計画内で生成されたterraformスタックを変更します。
  • 複数のVMを使用するアプリケーション全体の確認: 複数のVMを使用するサービスまたはアプリケーションを移行する場合は、テスト移行中にアプリケーション全体を確認します。つまり、個別のVMで実行されている個々のコンポーネントのみでなく、複数のVMを使用してアプリケーション全体の移行および起動を確認する必要があります。
  • ソースを停止して不整合を検証します: ソースVMのスナップショットを使用してテスト移行を実行できますが、これらのVMは元のデプロイメントで実行されたままです。

    また、異なるVMのスナップショットは同時に取得されないことに注意してください。したがって、様々なサーバー上のデータを同期にとどめる必要がある複雑なアプリケーションには不整合がある場合があります。このようなシナリオでは、本番の移行と同様に、ソースが停止しているテスト移行を実行します。ただし、このオプションにはソース環境の停止時間が必要です。したがって、テスト移行を適切に計画していることを確認してください。

  • 本番移行に必要なテスト範囲の計画: 本番移行のテスト範囲を事前に計画してください。使用可能なメンテナンス・タイム・スロット中に、計画テストを正常に完了できます。
  • 追加の構成変更の完了: 移行のために実行する必要がある追加の構成がすべて完了していることを確認します。ファイアウォールの変更、DNSの更新、クライアント構成などが可能です。
  • ロールバック計画を便利に保持: テスト移行が計画どおりに進まない場合は、一部または完全に変更された構成のロールバックに使用できるステップのリストが存在することを確認します。移行の試行が失敗したかどうかに応じて、構成の一部または全部をロールバックできます。元の機能をすばやく復元する必要があります。

アセットごとに1つのレプリケーションが完了したらすぐにテスト移行を実行できます。通常、最初のレプリケーションには完全なデータ転送が必要です。したがって、最初のレプリケーションが最長になります。

本番移行計画の要件

本番移行計画を作成するときは、次の要件を満たしていることを確認してください。

  • サービス停止の軽減: 移行中のサービス停止を軽減するには、停止のメンテナンス・ウィンドウを計画します。
  • トランザクションが失われないようにする: 移行中にトランザクションが失われないようにするには、ソース・アセットを停止し、追加のレプリケーションを実行します。そのため、最新の状態がターゲット・アセットに転送されます。

    移行メンテナンス・ウィンドウへの追加のレプリケーションの実行に必要な時間を考慮してください。

  • 識別しやすいようにソース・アセットにタグ付け: 管理コンソールで(タグ付けまたは同様の方法で)ソース・アセットを簡単に識別できる方法があることを確認してください。そのため、最後のレプリケーション・セッションの前にオフにする必要があるこれらのアセットを迅速かつ確実に識別できます。
  • 自動化に依存: メンテナンス・ウィンドウ間隔中に移行を完了する時間は制限されています。自動化スクリプトを活用し、テスト移行中にレコードを保守してください。後で、特定の時間にアクション・プランを設定し、メンテナンス・ウィンドウ間隔に対して進捗を追跡できます。
  • アクション・プランの準備ができている: 本番移行の試行の成功は保証されませんが、本番移行の試行に基づいて決定する準備をしてください。その後、成功シナリオと失敗シナリオの両方に対するアクション・プランを作成します。

    移行の試行が失敗した場合は、構成をロールバックし、ソース・アセットを再起動します。予想どおりに進まなかったことに注意し、次の試行で移行の試行に対処する予定です。

    本番の移行が成功し、サービスがOCIで動作するようになった場合は、データ・レプリケーションが停止するように、移行プロジェクトを完了としてマークします。通常、移行エラーが発生したときにソース・アセットを再起動できるように、ソース・データをしばらく使用可能にしておくことをお薦めします。ただし、Oracle Cloud Migrationsはリバース・レプリケーションをサポートしていないことに注意してください。したがって、逆移行はより複雑になる可能性があり、アプリケーションのバックアップまたはリストアのために手動のデータ転送を実行する必要があります。このような場合は、最小限の労力が必要になる可能性があるため、宛先環境の問題を最初に修正することを検討してください。

移行後のソース環境のリストア

移行が完了したら、ソース環境をクリーンアップし、移行が完了し、新しいOCI環境で操作できるように、移行されたすべてのアセットの電源を切断する必要があります。ソース環境のクリーン・アップに失敗した場合、古いリソースに接続されたまま、古いデータに対して操作を実行するクライアントが存在する可能性があります。

ソース環境をクリーン・アップするには、次のステップを実行します。

  1. OCIに移行されたすべての移行済VMを停止します。
  2. 組織のポリシーに従って、VMware vCenterのすべてのスナップショットを消去します。
  3. VMware vCenterから移行されたすべてのVMを削除し、vCenterサーバーをクリーンアップします。
  4. 必要に応じて、不要なネットワーク・ルートをすべて廃止します。