この記事では、Oracle Zero Downtime Migration (ZDM) を使用して、オンプレミスの Exadata システムから Oracle Database@Azure (OD@A) Exadata Database Service に Oracle データベースを移行する方法について説明します。 この記事では、OD@Aと Oracle ZDM に関する基本的な理解があることを前提としています。 このシナリオは、 Oracle データベース ワークロードを Azure に移行するのシナリオに基づいています。
Architecture
以下の図はこのシナリオの例を示したものです。
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ
次のシナリオの詳細について考えてみましょう。
選択した Azure リージョンOD@A Exadata Database Service をデプロイし、2 つのデータベース サーバーと 3 つのストレージ セル ノードを持つ仮想マシン クラスターを構成しました。
委任されたOD@Aサブネットは、ハブ仮想ネットワークとピアリングするOD@A仮想ネットワーク内にあります。 OD@A サブネットの IP アドレス範囲は 10.42.1.0/24 です。 詳細については、 IP アドレス空間の計画を参照してください。
ハブ仮想ネットワークでは、トラフィックは、FortiGate、Check Point、Cisco などの Microsoft 以外のネットワーク仮想アプライアンス (NVA) を通過する必要があります。 NVA はルーティング デバイスとして機能します。これにより、OD@Aクラスター ノードがインフラストラクチャ内で完全にルーティング可能になります。 オンプレミスとの間で送受信されるすべてのトラフィックを検査するように NVA を構成します。 ハブ NVA の IP アドレスは 10.0.0.5 です。
ハブ仮想ネットワークでハイブリッド接続を構成するには、オンプレミス ネットワークへの Azure ExpressRoute 接続を使用します。
オンプレミス ネットワークには既存の Exadata 実装があり、いずれかのデータベースをOD@Aに移行する必要があります。 データベースは 2 TB で、Exadata X8M-2 で実行されます。 データベースのバージョンは Oracle Database 19c、Enterprise Edition です。 オンプレミスの IP アドレス範囲は 192.168.0.0/16 です。
データベースで Real Application Clusters (RAC) を有効にしました。 ディザスター リカバリーでは、Oracle Data Guard を使用して、プライマリ データベースの場所から地理的に離れた別のデータセンターにデータベースをレプリケートします。
最小限のダウンタイムでデータベースをOD@Aに移行する必要があります。 Oracle ZDM ツールを使用して移行を調整することにします。
ネットワーク接続を確立する
移行に ZDM を使用するには、ソース データベースとターゲット データベースが相互に通信できるようにする必要があります。
- Azure ルート テーブルを作成し、OD@A サブネットに関連付けます。
- Azure ルート テーブルを、オンプレミスにルーティングするハブ NVA の IP アドレスをポイントします。
- オンプレミスと OD@A サブネットの間でトラフィックをルーティングするようにハブ NVA を構成します。
ルート テーブルを構成する
次の構成を使用して Azure ルート テーブルを作成し、OD@A サブネットに関連付けます。
- アドレス プレフィックス: 192.168.0.0/16
- ネクスト ホップの種類: 仮想アプライアンス
- 次ホップ IP アドレス: 10.0.0.5
- 名前: <Route テーブル名>
次の図は、更新されたネットワーク構成を示しています。
接続を確認するには、次の手順を実行します。
- OD@A データベース ノードにサインインします。 Secure Shell (SSH) プロトコルを使用して、オンプレミスのデータベース サーバーへの接続を確立できることを確認します。
- オンプレミスのデータベース サーバーにサインインします。 SSH プロトコルを使用して、OD@A データベース ノードへの接続を確立できることを確認します。
移行アクティビティを実行する
移行を準備します。 詳細については、「 物理データベースの移行の準備を参照してください。
Note
このガイダンスでは、ソース データベースとターゲット データベースの間に、オンライン移行をサポートするのに十分な帯域幅があることを前提としています。 最初に、オフライン移行やOD@Aのバックアップの復元を行う必要はないと想定しています。
移行を実行します。 詳細については、「 ZDM を使用してデータベースをアップグレードするを参照してください。
最小限のダウンタイムを確保するために、データベース移行と並行して次のアプリケーション移行アクティビティを実行します。
- 計画とディスカッションに従ってアプリケーション サービスを移行します。
- 接続文字列、Transparent Network Substrate (TNS) エントリ、その他の必要な構成など、新しいデータベースを指すアプリケーション サービスを更新します。
- アプリケーション サービスが期待どおりに動作することを確認します。
次の図は、ZDM 移行ノードを含む、更新された構成を示しています。
移行後のアクティビティを実行する
OD@A データベースの自動バックアップ を構成します。
自動 Data Guard を構成。 このガイダンスでは、別の可用性ゾーンまたはリージョンに別のインスタンスを既に作成していることを前提としています。
オンプレミス データベースをセカンダリ Data Guard レプリカとして一定期間実行し、移行が成功したことを確認します。
まとめ
Oracle ZDM を使用して、オンプレミスからOD@Aにデータベースを移行するには、上記の構成変更を行います。 構成の変更は、ソース データベースとターゲット データベースが相互に通信できることと、最小限のダウンタイムで移行を実行できるようにするために役立ちます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
- ヤン・フォールスコフ |クラウド ソリューション アーキテクト
- Moises Gomez-Cortez |クラウド ソリューション アーキテクト
- グエル・カヤリ・サリカン |クラウド ソリューション アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
次の記事を確認して、実装が推奨されるプラクティスに従っていることを確認します。