BCDR (事業継続とディザスター リカバリー) を最適化する
Oracle リソースを Azure に移行する場合は、データベースの信頼性と、仮想マシン (VM)、仮想ネットワーク サブネット、ストレージ コンポーネント上の層の信頼性も考慮してください。
サービスとしての Azure インフラストラクチャ (IaaS) 上の Oracle は、最も要求の厳しい Oracle ワークロードの必要な回復性の目標を満たすことができます。 この記事のガイダンスを効果的に使用するには、まず、ビジネス要件に基づいて回復性の主要業績評価指標 (KPI) を定義します。 目標復旧時間 (RTO) と回復ポイントの目標 (RPO) の要件をベースライン KPI として使用して、Azure 上の Oracle ワークロードに最適なアーキテクチャを決定します。
RTO は、障害、障害、または同等のイベントの後にアプリケーションが使用できなくなる最大時間です。
RPO は、障害、障害、または同等のイベントの後のデータ損失の最大量です。
データ保護のためのバックアップ方法
Azure IaaS 上の Oracle ワークロードの 3 つの Oracle データベース バックアップ方法は次のとおりです。
ストリーミング バックアップ。 この方法には Oracle Recovery Manager (RMAN) を使用します。 RMAN は、バックアップをシーケンシャル テープ メディアにストリーム配信します。
Azure のバックアップ先は次のとおりです。
- Microsoft 以外の仮想テープ ライブラリ。Azure Marketplace で見つけることができます。
- ネットワーク ファイル システム プロトコル、Azure Files、Azure NetApp Files を使用した Azure Blob Storage などのローカルおよびリモートのファイル共有。
ストレージレベルのスナップショット。 この方法には Azure Backup を使用します。 このメソッドは、データベース ファイルに使用するストレージの種類に依存します。 たとえば、Azure Premium SSD などの Azure マネージド ディスクを使用する場合、Azure Backup は Oracle データベースと統合されます。 Azure NetApp Files を使用する場合は、Azure NetApp Files のバックアップやリージョン間レプリケーションなど、Azure NetApp Files のデータ保護機能を使用できます。
VM レベルのバックアップ。 この方法には Azure Backup を使用します。
注意事項
バックアップ環境内の VM が、サポート可能な OS を実行していることを確認します。 サポートされている OS について確認します。
大規模なデータベースのバックアップをストリーミングする場合、データをコピーして復元するのにかかる時間が、RTO 要件を超える可能性があります。 ストレージ レベルのスナップショットは、そのシナリオに最適なオプションです。
推奨事項
ストリーミング、ストレージ レベルのスナップショット、または両方の戦略に基づくバックアップ戦略を実装するかどうかを慎重に検討してください。
バックアップ戦略が RTO と RPO の要件に与える影響を評価します。
各オプションの文書化されたスループット制限に基づいて、RMAN バックアップで使用可能なストレージの宛先を分析します。 要件を満たすオプションを選択します。
ストレージレベルのスナップショットに Azure Backup を使用することを検討し、追加の保護のために、ペアのリージョンまたは可用性ゾーン内にスナップショットを配置することを検討します。
データベースの復旧に必要なアーカイブ ログ バックアップを格納するには、さまざまなストレージ オプションを検討してください。 各オプションのパフォーマンス、レプリケーション、コストに関する考慮事項を考慮してください。
バックアップと復元の計画を開発して定期的にテストし、運用環境での望ましくない出来事を防ぎます。
サービス保護とビジネス継続性
このセクションでは、サービス保護とビジネス継続性 (BC) に関する考慮事項を実装することで、Azure IaaS 上の Oracle ワークロードの全体的な高可用性 (HA) とディザスター リカバリー (DR) を改善する方法について説明します。
アーキテクチャの冗長性を向上させ、最終的にはサービスを利用できる時間を最大化するために、次の推奨事項を組み込みます。 修正プログラム、更新プログラム、アップグレードなどの計画的な停止や、障害などの計画外の停止によるサービスのダウンタイムを最小限に抑えるようにします。 Azure と Oracle の機能を使用して、地理的な障害からの復旧を向上させます。
Azure には、Oracle on IaaS アーキテクチャの個々のコンポーネントの高可用性に関する多くのオプションが用意されています。 たとえば、次のようなことができます。
- 柔軟な仮想マシン スケール セットを使用して VM をデプロイします。これは、VM を障害ドメイン間で自動的に分散します。
- 可用性ゾーンを作成して、データセンターの障害から保護します。
- リージョン全体の障害から保護するために、さまざまなリージョンにデプロイを配置します。
さまざまな Azure ストレージ機能により、ローカル冗長ストレージ、ゾーン冗長ストレージ、geo 冗長ストレージなど、さまざまなストレージ冗長性レベルが提供されます。 Azure IaaS での Oracle ワークロードのデプロイを計画するときは、各オプションを検討してください。
Oracle Data Guard を使用することもできます。これは、Oracle データベース サービス保護のセットアップのツールです。 Data Guard は、トランザクション ログを転送し、1 つ以上のスタンバイ データベースに適用します。 このプロセスでは、計画メンテナンスまたは障害シナリオがある場合に、フェールオーバーできるプライマリ データベースの正確なコピーが保持されます。
Data Guard には、最大保護、最大可用性、最大パフォーマンスの 3 つのデータ レプリケーション モードがあります。 各レプリケーション モードでは、ログ トランスポート モードと、セカンダリ データベース上のアプリケーションに対する各種トランザクション保証のさまざまな組み合わせが用意されています。
ゼロ待機時間やゼロ データ損失戦略などの戦略に応じて、同期構成または非同期構成を選択できます。 また、ダウンタイムの最大要件に応じて、高速開始フェールオーバーを実装することもできます。 1 分未満または 5 分未満で最大 4 時間の回復を提供する参照アーキテクチャを使用できます。 Oracle Database の Enterprise Edition には Data Guard が含まれています。
Oracle GoldenGate は、2 つのデータベース間でデータをレプリケートし、マルチプライマリ シナリオを有効にできるもう 1 つのツールです。 GoldenGate は別途購入する必要があります。
推奨事項
Azure IaaS 実装上の Oracle のさまざまなインフラストラクチャ コンポーネントの高可用性を実現するために、Azure に用意された機能をご検討ください。
DATA Guard for HA と DR を使用する場合は、要件を満たすデータベース保護モードを慎重に選択してください。 たとえば、最大パフォーマンス モードはソースへの影響を最小限に抑えますが、データ損失の可能性が最も高くなります。 詳細については、Azure Virtual Machines ランディング ゾーン アクセラレータ上の Oracle に対する BCDR および Oracle Data Guard の保護モードに関する記事を参照してください。
フェールオーバー プロセスを自動化することを検討します。 たとえば、高速開始フェールオーバーを使用できます。
フェールオーバー プロセスのテスト手順を確立し、問題を回避するために定期的なテストを実行します。
HA と DR の要件を満たすために、可用性ゾーンなどの Azure ネイティブ機能と、Data Guard などの Oracle ネイティブ ツールを使用して、ソリューションを総合的に設計します。 次の 2 つの例では、Azure ネイティブコンポーネントと Oracle ネイティブ コンポーネントを使用します。
パッシブ スタンバイを使用してフェールオーバーを作成する
このセクションでは、パッシブ スタンバイを使用した 2 可用性ゾーン デプロイにおけるビジネスクリティカルな Oracle アプリケーションのフェールオーバー シナリオの例について説明します。
Oracle E-Business Suite などのビジネスクリティカルな Oracle アプリケーションには、障害防止が必要であるため、包括的なアーキテクチャが必要です。
この例では:
2 可用性ゾーンのデプロイがある。 アプリケーション層では、パッシブ セカンダリ VM で Azure Site Recovery を使用します。
Data Guard の高速開始フェールオーバー機能を利用する。 高可用性を実現するには、2 つのオブザーバーをインストールすることをお勧めします。 プライマリ オブザーバーは可用性ゾーン 1 にあり、セカンダリ オブザーバーは可用性ゾーン 2 にあります。 オブザーバーはトラフィックを監視し、ダイレクトします。 プライマリ データベースが使用できない場合、オブザーバーは自動的にセカンダリ データベースにフェールオーバーします。 Data Guard は再実行同期を実行します。再実行同期の期間は、再実行の構成によって異なります。
最大可用性、最大パフォーマンス、最大保護など、データ保護モードに Data Guard が構成されている。 ワークロード要件のモードの選択の詳細については、「Oracle Data Guard 保護モード」を参照してください。
次のアーキテクチャは、5 分未満のダウンタイムしきい値を目指しています。
アクティブ スタンバイを使用してフェールオーバーを作成する
このセクションでは、アクティブ スタンバイを使用した 2 可用性ゾーン デプロイにおけるビジネスクリティカルな Oracle アプリケーションのフェールオーバー シナリオの例について説明します。
次の点に注意してください。
Web サーバー層、アプリケーション層、およびデータベース層は、独自の仮想ネットワーク サブネットに存在します。
プライマリ データベースは可用性ゾーン 1 に存在します。
Active Data Guard を使用してプライマリ データベースをアクティブ スタンバイにレプリケートするデータベースは、可用性ゾーン 3 に存在します。
Note
このセットアップには、Active Data Guard ライセンスが必要です。
次のアーキテクチャは、1 分未満のダウンタイムしきい値を目指しています。 このフェールオーバー シナリオにはアクティブ スタンバイ構成がありますが、読み取り専用の機能があります。
