Oracle ワークロードを Azure に移行する

クラウド導入の取り組みの一環として、既存のワークロードをクラウドに移行する必要があります。 Oracle ワークロードは、他のワークロードと同様で、移行を確実に成功させるために方法論的なアプローチが必要です。 移行方法の詳細については、「クラウド導入フレームワークでのクラウド移行」を参照してください。 この記事では、Oracle ワークロードに固有の一意の制約と考慮事項について説明します。

Oracle 移行プロセス

関連する種類のワークロード用サービスを使用してパフォーマンスを向上させ、コストを削減するために、インフラストラクチャの要件を継続的に再評価する必要があります。 たとえば、ワークロードを Oracle Database@Azure に移行する場合は、選択した SKU が要件を満たしていることを確認します。 同様に、Azure Virtual Machines の Oracle にワークロードを移動する場合は、仮想マシン (VM) のサイズが要件を満たしていることを確認します。 詳細については、「Oracle ワークロードを Azure ランディング ゾーンに移行するための容量計画」を参照してください。

移行リソースを確認して、Oracle から Azure への移行プロセスを定義します。 次のこともできます。

• Azure サブスクリプションのクォータ制限を確認する: Azure サブスクリプションのクォータ制限が、Oracle on Azure Virtual Machines に移行するかを選択したターゲット VM サイズに対応していることを確認します。

• デプロイ モデルを特定する: コードとしてのインフラストラクチャ (IaaS)、継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン、およびその他の DevOps プラクティスを使用して、ソリューション コンポーネントのデプロイを可能な限り自動化します。

• アプリケーションの依存関係を決定する: 移行アクティビティによる破壊的な影響が最小限になるようにします。

• データ容量を特定する: 移行するデータの量を特定し、オンプレミス環境から Azure への現在利用可能なネットワーク接続容量を評価します。 この情報を使用して、オンプレミス環境から Azure にデータを直接コピーできるかどうかを判断します。 初期データ読み込みに Azure Data Box などの物理データ転送アプライアンスが必要になる場合があります。

• 可用性要件を決定する: 使用できる移行ツールに影響を与えるため、ワークロードの可用性要件を決定します。

Oracle Database@Azure の場合は、次のことを確認します:

• ソリューションをデプロイするリージョンで Oracle Database@Azure ソリューションが使用可能であることを確認します。 詳細については、「利用可能なリージョン」を参照してください。

• オンプレミス環境から Oracle Database@Azureに移行する場合は、必要なデータベースの変更を検討してください。 移行には、データベースのテーブルスペースとスキーマにいくつかの変更が含まれる場合があります。 詳細については、「Exadata Cloud Service への Oracle のデータベースの移行」をご覧ください。

Oracle 移行ワークロード固有のアクティビティ

以下のセクションでは、移行プロセスついて詳しく説明します。 手順は必ずしも連続していません。 いくつかの手順を並行で実行できます。

• 移行元と移行先のシステムのバージョンを評価する: オンプレミスのオペレーティング システムのバージョン、アプリケーションのバージョン、データベースのバージョンが Azure で使用される予定のバージョンと同じかどうかを評価します。

  • 1 個以上のリソースを更新する必要がある場合は、移行プロセスが複雑にならないように、移行前にそれらを更新します。

  • オンプレミスのデータベースが Oracle Solaris、IBM Advanced Interactive Executive (AIX)、Hewlett Packard Unix (HP-UX) などの大規模なエンディアン オペレーティング システムで実行されている場合、データベースの移行プロセスにはエンディアン変換が含まれます。 Azure では、リトル エンディアンのオペレーティング システムのみがサポートされます。 ツールの観点から、これは、移行に使用するツールを検討する際のオプションの数の制限をサポートしています。 具体的には、Oracle Data Guard、Azure Migrate and Modernize、またはその他のファイル コピー方法を使用することはできません。 エンディアン変換と互換性のある移行方法には、Oracle DataPump Export、Oracle Data Pump Import、Oracle Cross Platform Transportable Tablespaces (XTTS)、Oracle GoldenGate、Quest SharePlex、Striim などのデータ レプリケーション ユーティリティがあります。

  • 要件や互換性に応じて、オンプレミスのアプリケーション サーバーを最新化または移行できます。 詳細については、「クラウド導入シナリオ」を参照してください。

• 移行プロセス中にワークロードの可用性要件を評価する: ワークロードのダウンタイムを最小限に抑える必要がある場合は、DataPump Export 機能、Data Pump Import 機能や Azure の移行と最新化などの移行方法がワークロードに適していない可能性があります。 その場合は、次の 3 つの手順を実行できます:

  • Oracle Recovery Manager (RMAN) を使用して、Azure でデータベース全体をバックアップして復元します。 必要に応じて、XTTS を使用してエンディアン変換を実行します。 結果として、オンプレミスのソース データベースのポイントインタイム コピーであるデータベースが作成されます。 詳細については、「プラットフォーム全体でのデータの転送」を参照してください。

  • どちらのリソースもリトル エンディアン形式である場合は、Oracle DataGuard を使用して、Azure に新しく復元されたデータベースをソース データベースと同期します。 前に説明したように、移行にビッグ エンディアンからリトル エンディアンへの変換が必要な場合は、DataGuard を使用できません。 代わりに、Oracle GoldenGate、Quest SharePlex、Striim などの SQL ベースのデータ レプリケーション ユーティリティを使用して、Azure で新しく復元されたデータベースをソース データベースと同期します。

  • Azure のターゲット データベースがオンプレミスのソース データベースと同期されると、カットオーバー をスケジュールできます。 カットオーバーにより、ソースのオンプレミス データベースがシャットダウンされ、最後のいくつかのトランザクションが Azure のターゲット データベースにフラッシュされます。 その後、新しいソース データベースとして Azure でターゲット データベースを開くことができます。 カットオーバーは、使用される同期方法に応じて、わずか数分で発生する可能性があります。

  • アプリケーション サービスに対して選択した移行方法によっては、アプリケーションを Azure に完全に移行する前にいくつかのアプリケーション サービス タスクを完了することが必要になる場合があります。

  • 移行プロセスに Oracle Zero Downtime Migration (ZDM) を使用することを検討してください。 詳細については、「ダウンタイムなしのデプロイ」を参照してください。

• 必要なライセンスを評価する: データベースには、移行ツールに応じてさまざまなライセンスが必要な場合があります。 次に例を示します。

  • Oracle DataGuard には Oracle Database Enterprise Edition が必要です。

  • Oracle GoldenGate には Oracle GoldenGate ライセンスが必要です。

  Azure 上の Oracle ライセンス付与の詳細については、「クラウド コンピューティング環境における Oracle ソフトウェアのライセンス付与」を参照してください。

次のステップ