Oracle ワークロードを Azure に移行する
クラウド導入の取り組みの一環として、既存のワークロードをクラウドに移行する必要があります。 Oracle ワークロードは他のワークロードと似ていますが、移行を成功させるためには、方法論的なアプローチが必要です。 移行方法の詳細については、Azure向けクラウド導入フレームワークでのクラウド移行の
Oracle 移行シナリオ
Oracle ワークロードを移行する場合は、データベースとアプリケーションを移行する必要があります。 この記事では、アプリケーションとデータベースの移行に関するリフト アンド シフトアプローチについて説明します。 リフト アンド シフト アプローチには、Azure Virtual Machines への Oracle アプリケーションのデプロイが含まれます。 データベースの移行では、いくつかのオプションを使用できます。 この記事では、Oracle Database@Azureに適用されるガイダンスを提供します。
仮想マシン上の アプリケーション: Oracle エンタープライズ アプリケーション (Siebel、PeopleSoft、JD Edwards、E-Business Suite、Azure インフラストラクチャ上のカスタマイズされた WebLogic Server アプリケーションなど) を実行します。
仮想マシン上の Oracle Standard Edition または Enterprise Edition データベース: このシナリオでは、Oracle データベースを仮想マシンにデプロイします。 セルフマネージド データベースからマネージド データベースまで、いくつかのオプションを使用できます。 マネージドデータベースソリューションをお求めの場合は、テセルをご確認ください。
Oracle Database@Azure: Oracle Database@Azureは、Oracle クラウド インフラストラクチャ (OCI) 上で実行され、Microsoft データセンターに併置される Oracle データベース サービスです。
手記
特定のデータベース バージョンでサポートされているオペレーティング システムを確認するには、サポートされているデータベースとオペレーティング システムの
Oracle 移行プロセス
関連する種類のワークロード用サービスを使用してパフォーマンスを向上させ、コストを削減するために、インフラストラクチャの要件を継続的に再評価する必要があります。 たとえば、前に説明したすべてのシナリオで、移行に十分な帯域幅が使用可能であることを確認します。 概念実証 (PoC) を実施する際に必要な帯域幅を確認することを強くお勧めします。
仮想マシン上の Oracle にワークロードを移動する場合は、仮想マシン (VM) のサイズが要件を満たしていることを確認します。 詳細については、「Oracle ワークロードを Azure ランディング ゾーンに移行するための容量計画」を参照してください。
移行リソースを確認して、Oracle から Azure への移行プロセスを定義します。 次のこともできます。
- Azure サブスクリプションのクォータ制限を確認する: 仮想マシン上の Oracle に移行する場合に選択したターゲット VM サイズに、Azure サブスクリプションのクォータ制限が対応できることを確認します。
手記
Oracle Database@Azureでワークロードをホストしていて、クォータの引き上げが必要な場合は、Oracle の担当者にお問い合わせください。
デプロイ モデルを特定する: コードとしてのインフラストラクチャ、継続的インテグレーションおよび継続的デリバリー パイプライン、およびその他の DevOps プラクティスを使用して、ソリューション コンポーネントのデプロイを可能な限り自動化します。
アプリケーションの依存関係を決定する: 移行アクティビティができるだけ中断されないようにします。
データ容量の識別: オンプレミス環境から Azure に現在使用可能なネットワーク接続容量を移行して評価するデータの量を特定します。 この情報を使用して、オンプレミス環境から Azure にデータを直接コピーできるかどうかを判断します。 初期データ読み込みに Azure Data Box などの物理データ転送アプライアンスが必要になる場合があります。
可用性の要件を決定する: 使用できる移行ツールに影響を与える可能性があるため、ワークロードの可用性要件を決定します。 許容される最大ダウンタイムを定義します。 このメトリックは、移行ツールとアプローチを定義するのに役立ちます。
この考慮事項は、アプリケーションにも同様に適用されます。 日常業務の中断を受け入れられない場合は、オンライン移行を実行する必要があります。
- Azure 仮想マシン上の Oracle にワークロードを移行するためのツールを決定します。 2 つのプライマリ移行パスはオフラインとオンラインです。
| オフライン移行 | オンライン移行 |
|---|---|
| データベースの 1 回限りの直接コピー。 | 移行中のデータベースの最初のコピーの後に変更データ キャプチャが続きます。 |
| 移行中に影響を受けるアプリケーションをオフラインにする必要があります。 | 移行中もアプリケーションはオンラインのままです。 |
| 使用される ツール: Data Box、DataPump、Oracle Recovery Manager (RMAN) | 使用される ツール: DataGuard、Oracle Recovery Manager (RMAN)、GoldenGate |
手記
オンライン移行を実行する場合は、データ転送を許可するようにファイアウォール規則を構成してください。
Oracle 移行ワークロード固有のアクティビティ
以下のセクションでは、移行プロセスついて詳しく説明します。 手順は必ずしも連続していません。 いくつかの手順を並行で実行できます。
ソースと移行先のシステムのバージョンを評価する: オンプレミスのオペレーティング システム (OS) のバージョン、アプリケーションのバージョン、およびデータベースのバージョンがオンプレミスと Azure で同じかどうかを評価します。
1 つ以上のリソースを更新する必要がある場合は、移行の前にそれらを更新して、移行プロセスを簡略化します。
オンプレミスのデータベースが Oracle Solaris、IBM Advanced Interactive eXecutive、Hewlett Packard Unix などのビッグ エンディアン OS 上で実行されている場合、データベース移行プロセスにはエンディアン変換が含まれます。 Azure では、リトル エンディアンのオペレーティング システムのみがサポートされます。 この制限により、移行に使用できるツールの数も限定されます。 具体的には、Oracle Data Guard またはその他のファイル コピー方法を使用することはできません。 エンディアン変換と互換性のある移行方法には、Oracle Data Pump Export または Oracle Data Pump Import、Oracle クロスプラットフォームのトランスポート可能なテーブルスペース (XTTS)、または Oracle GoldenGate、Quest SharePlex、Striim などのデータ レプリケーション ユーティリティが含まれます。
要件と互換性に応じて、オンプレミスのアプリケーション サーバーを最新化または移行できます。 詳細については、「クラウド導入シナリオ」を参照してください。
移行プロセス中にワークロードの可用性要件を評価します。 ワークロードのダウンタイムを最小限に抑える必要がある場合は、Data Pump Export や Data Pump Import などの移行方法がワークロードに適していない可能性があります。 その場合は、次の 4 つの手順に従います。
RMAN を使用してバックアップし、Azure 内のデータベース全体を復元します。 必要に応じて、XTTS を使用してエンディアン変換を実行します。 結果として、オンプレミスのソース データベースのポイントインタイム コピーであるデータベースが作成されます。 詳細については、「プラットフォーム全体でのデータの転送」を参照してください。
両方のソースがリトル エンディアン形式の場合は、Oracle Data Guard を使用して、Azure で新しく復元されたデータベースをソース データベースと同期します。 移行にビッグ エンディアンからリトル エンディアンへの変換が含まれている場合は、Data Guard を使用できません。 代わりに、Oracle GoldenGate、Quest SharePlex、Striim などの SQL ベースのデータ レプリケーション ユーティリティを使用して、Azure で新しく復元されたデータベースをソース データベースと同期します。
Azure のターゲット データベースがオンプレミスのソース データベースと同期されると、カットオーバー をスケジュールできます。 カットオーバーにより、ソースのオンプレミス データベースがシャットダウンされ、最後のいくつかのトランザクションが Azure のターゲット データベースにフラッシュされます。 その後、新しいソース データベースとして Azure でターゲット データベースを開くことができます。 使用する同期方法によっては、カットオーバーに数分かかる場合があります。
アプリケーション サービスに対して選択した移行方法によっては、アプリケーションを Azure に完全に移行する前にいくつかのアプリケーション サービス タスクを完了することが必要になる場合があります。
必要なライセンスを評価する: 移行ツールによっては、データベースにさまざまなライセンスが必要になる場合があります。 次に例を示します。
Oracle DataGuard には Oracle Database Enterprise Edition が必要です。
Oracle GoldenGate には Oracle GoldenGate ライセンスが必要です。
Azure 上の Oracle ライセンス付与の詳細については、「クラウド コンピューティング環境における Oracle ソフトウェアのライセンス付与」を参照してください。
Oracle Database@Azure 移行ガイダンス
ソリューションをデプロイするリージョンで Oracle Database@Azure ソリューションが使用可能であることを確認します。 詳細については、「利用可能なリージョン」を参照してください。
移行プロセスに Oracle Zero Downtime Migration を使用することを検討してください。 各移行戦略を評価して、特定の移行要件に最も適したアプローチを決定します。 詳細については、「ダウンタイムなし移行 (ZDM)を参照してください。 ZDM には、論理移行シナリオまたは物理移行シナリオのいずれかを選択する機能が用意されています。 詳細については、ZDM 移行
を参照してください。
手記
自律データベース サービス (ADB-S) を選択した場合は、論理移行シナリオのみがサポートされることに注意してください。
その他のガイダンス
次のセクションは、要件とデータ サイズに適した移行オプションを選択するのに役立ちます。
ExpressRoute を利用した移行期間の参照
次の表は、ベースラインとしてのみ機能します。 同じ Azure ExpressRoute 接続を介して実行される他の運用ワークロードは考慮されません。
VMware では、指定されたよりも多くの帯域幅が必要になる場合があります。 PoC フェーズ中に帯域幅のニーズを評価します。 サポートが必要な場合は、お近くの連絡先にお問い合わせください。
| データ サイズ | 1 Gpbs の帯域幅 | 10 Gbps の帯域幅 |
|---|---|---|
| 1 TB | 3 時間 | 15 分 |
| 10 テラバイト (TB) | 1 日 | 3 時間 |
| 35 TB | 4 日 | 9 時間 |
| 80 TB（テラバイト） | 8 日間 | 20 時間 |
| 100 TB | 11 日 | 1 日 |
| 200 TB | 21 日 | 2 日 |
| 500 TB | 53 日 | 5 日 |
移行に ExpressRoute を使用する予定の場合は、その の回復性が要件を満たしていることを確認します。