Oracle ワークロードを Azure VM に移行する
この記事では、Oracle ワークロードをオンプレミス環境から Azure 仮想マシン (VM) ランディング ゾーンに移行する方法について説明します。 Azure の Oracle Database 用のランディング ゾーンを使用し、Azure IaaS での Oracle 移行に関する設計上のアドバイスとベスト プラクティスを提供します。 全体的な移行戦略とそれに続くデータ移行およびカットオーバーに対しては、実証された検出、設計、デプロイのアプローチが推奨されます。
検出
移行は、Oracle 製品ポートフォリオの詳細な評価から始まります。 Oracle データベースとアプリ、データベース バージョン、Oracle データベースを使用するアプリケーションの種類をサポートする現在のインフラストラクチャは、Oracle (EBS、Siebel、People Soft、JDE など) と、SAP やカスタム アプリケーションなどの Microsoft 以外のパートナー オファリングです。 既存の Oracle データベースは、サーバー、Oracle Real Application Clusters (RAC)、または Microsoft 以外のパートナー RAC 上で動作している可能性があります。 アプリケーションに関しては、Azure Migrate ベースの検出を使用して簡単に実行できるインフラストラクチャのサイズを検出する必要があります。 データベースに関するアプローチは、ピーク負荷に関する制限の自動ワークロード リポジトリ (AWR) レポートを使用して、設計段階に進むための許可をもらうことです。
デザイン
アプリケーションに関しては、Azure Migrate が検出結果に基づいてインフラストラクチャとアプリケーションの Azure IaaS へのリフト アンド シフトを実行します。 Oracle ファースト パーティ アプリケーションに関しては、Azure Migrate ベースの移行を判断する前に、アーキテクチャの要件を参照してください。 データベース設計は、生成されたピーク負荷に関する AWR レポートから始まります。 AWR が用意できたら、AWR レポートを入力として使用して Azure Oracle Migration Assistance Tool (OMAT) を実行します。 OMAT ツールは、Azure IaaS 上の Oracle Database に必要な適切な VM サイズとストレージ オプションを推奨します。 ソリューションは、災害発生時の高い信頼性と回復性を備えている必要があり、これは回復ポイントの目標 (RPO) と回復時間の目標 (RTO) というパラメーターによって決定されます。 Oracle ランディング ゾーンには、RPO と RTO の要件に基づいて最適なソリューション アーキテクチャを選択するためのアーキテクチャ ガイダンスが用意されています。 RPO と RTO のアプローチは、Oracle Data Guard を使用して RAC インフラストラクチャを高可用性 (HA) アーキテクチャとディザスター リカバリー (DR) アーキテクチャに分離するために適用できます。
展開
OMAT ツールは、AWR レポートを分析して、必要なインフラストラクチャに関する情報 (適切な VM サイズと容量を持つストレージに関する推奨事項) を提供します。 その情報に基づいて、Oracle on Azure ランディング ゾーンを使用して事業継続とディザスター リカバリー (BCDR) を提供する回復性があるアーキテクチャを提供するために適切な HA および DR (RPO/RTO) 要件を選択します。 Ansible を使用して、インフラストラクチャとアーキテクチャをコードとしてのインフラストラクチャ (IaC) として記述し、Terraform または Bicep を使用してランディング ゾーンを起動します。 デプロイを自動化するために利用できる GitHub アクションを使用します。
データ移行の種類
データ移行プロセスには、オンラインとオフラインの 2 種類があります。 オンラインでは、実行時にソースから移行先にデータが転送されます。 オフラインでは、ソースからデータが抽出され、それが後で移行先に転送されます。 どちらの方法も不可欠なものです。 オフラインは、ソースと移行先の間で大きなデータを転送するのに適していますが、オンラインでは、ソースから移行先データベースに移行する前に段階的にデータを転送できます。 両方の種類のアプローチを合わせて使用することで、データ移行を成功させるための効率的なソリューションを提供できます。
データ移行のアプローチ
Oracle on Azure インフラストラクチャを設定した後、Oracle データベースをインストールし、関連するアプリケーションを移行します。次の手順では、オンプレミスの Oracle データベースから Azure 上の新しい Oracle データベースにデータを転送します。 以下の Oracle ツールを参照してください。
Azure は、データ移行に対して以下の Azure 機能を利用する適切なネットワーク接続、帯域幅、コマンドを使用して、Oracle ツールを強化します。
データ移行用の Oracle ツール
次の図は、移行ポートフォリオ全体を図形式で表したものです。
適切なソリューション アーキテクチャをデプロイしてデータを移行するには、Oracle ツールのいずれかに加えて Azure インフラストラクチャが必要です。 以下のリファレンス ソリューション シナリオを確認してください。
シナリオ 1: RMAN: RMAN のバックアップと復元を Azure 機能と合わせて使用します。RMAN ベースのリカバリ用のセットアップです。 重要なものは、オンプレミスと Azure の間のネットワークです。
シナリオ 2: RMAN バックアップのアプローチ
シナリオ 3: または、次のシナリオに示すように、複数の異なる方法でセットアップを変更できます。
シナリオ 4: Data PumpàAzCopy - Azure 機能を使用する Data Pump のバックアップと復元を使用する簡単かつ直接的なアプローチ。
シナリオ 5: Data Box - ストレージ デバイスと物理的な移動を使用して場所間でデータが移動される特殊なシナリオ。
カットオーバー
これでデータが移行され、Oracle データベース サーバーとアプリケーションが稼働しています。 以下の手順を使って、オンプレミスで実行されているビジネス運用を、Azure IaaS 上の新しい Oracle ワークロードとアプリケーションに移行します。
- ユーザーにとっての中断時間を最小限に抑えるようにメンテナンス期間をスケジュールします。
- ソースの Oracle データベース上のデータベース アクティビティを停止します。
- 最終的なデータ同期を実行して、すべての変更がキャプチャされていることを確認します。
- 新しい Azure VM を指すように DNS 構成を更新します。
- Azure VM 上の Oracle データベースを起動し、接続を確認します。
- カットオーバー プロセス中に何らかの問題が起きていないかシステムを注意深く監視します。
移行後のタスク
カットオーバー後、すべてのビジネス アプリケーションが想定どおりに機能し、オンプレミスとの連携でビジネス運営が提供されていることを確認します。
- 検証チェックを実行して、データの整合性とアプリケーションの機能を確認します。
- ネットワーク図、構成の詳細、ディザスター リカバリー計画などのドキュメントを更新します。
- Oracle データベースをホストしている Azure VM の継続的な監視およびメンテナンス プロセスを実装します。
移行プロセス全体を通じて、アプリケーション所有者、IT 運用チーム、エンド ユーザーなどの利害関係者と効果的にコミュニケーションを取り、要望を管理し、中断を最小限に抑えることが重要です。 さらに、スムーズな移行を成功させるには、Oracle から Azure への移行に特化した経験豊富な専門家やコンサルティング サービスと連携することを検討してください。