Oracle Database@Azure向けOracle Maximum Availability Architecture

Microsoft Azureは、戦略的なOracle Multicloudパートナです。Oracle Maximum Availability Architecture(MAA)では、Oracle Database@Azure上のMAAリファレンス・アーキテクチャが評価され、その結果がここに示されます。

MAA SilverおよびMAA Goldの評価と認定後のそれらのメリットの詳細は、「マルチクラウド・ソリューションに関するMAA評価」を参照してください。

Oracle MAAで、AzureにおけるOracleのソリューションを評価しました。Oracle MAAでは、想定されているすべてのメリットがそのソリューションで実現されていることを確認するためと、Oracle Database@Azure向けの新しいMAAによるメリットと機能を明らかにするために、定期的に再評価し続けています。認定は、MAA評価で要件が満たされた後にのみ与えられます。

Oracle MAAでは、次のことについてOracle Database@Azureを評価し承認しました:

• Exadata Database Service on Dedicated Infrastructure (ExaDB-D)上のMAA Silverリファレンス・アーキテクチャ
• スタンバイ・データベースが、同一または別々の可用性ゾーン(AZ)内、または別々のリージョン内の、別のExaDB-Dにある場合の、MAA Goldリファレンス・アーキテクチャ

評価環境:

• 米国バージニア州アッシュバーン地域とび英国ロンドン地域にまたがるクロスリージョン
• 米国バージニア州アッシュバーン地域内のクロス可用性ゾーン(AZ)

ネットワーク結果

ここに示す結果は、「Oracle MAAによるOracle Databaseマルチクラウド評価」で説明されているネットワーク・テストに基づいています。

ユースケース	観測されたRTT待機時間	ネットワーク帯域幅	MAAの推奨事項
アプリケーションVMからExadata VMクラスタへ(同一リージョン)	配置によって異なる 同じAZ内のクラスタ: 最大300マイクロ秒 複数のAZにまたがるクラスタ: 最大500マイクロ秒	配置とVMサイズに基づいて変化	必要なRTT待機時間がアプリケーション要件を満たしていることを確認します。 実装を十分にテストします。可変事項(VMのサイズや配置など)によって結果に影響がある可能性があります。 「Azure上のアプリケーション・ネットワーク層」を参照してください 近接配置グループとAzureでの仮想マシンのサイズも参照してください)
複数のAZにまたがる(米国バージニア州アッシュバーン)、Exadata VMクラスタ間で、次のことについて: REDO転送 データベース移行またはスタンバイ・データベースのインスタンス化	最大1.2ミリ秒(両方のピアリング・オプションの場合)	単一プロセスのスループット: OCI VCNピアリング(推奨): 11.7 GB/秒 Azureグローバル仮想ネットワーク: 2.97 GB/秒 最大並列度のスループット: OCI VCNピアリング(推奨): 41.5 GB/秒 Azureグローバル仮想ネットワーク: 41.5 GB/秒	ご使用の環境でMAA推奨のネットワーク・テストを繰り返します。例については、「ネットワーク評価」を参照してください。 より高い帯域幅(一部の例では最大600%)には、OCIピアリングの使用をお薦めします。 OCIピアリングについては、次を参照してください 同一リージョン: ローカル・ピアリング・ゲートウェイを使用したローカルVCNピアリング クロスリージョン: Oracle Database@AzureでのExadataデータベースのリージョン間障害時リカバリの実行 Azureピアリングについては、仮想ネットワーク・ピアリングを参照してください 可変事項によって帯域幅に影響がある場合があります。Azure仮想マシンの場合のネットワーク・スループットの最適化を参照してください
複数リージョンにまたがる(米国バージニア州アッシュバーンと英国ロンドン) Exadata VMクラスタ間で、次のことについて: REDO転送 データベース移行またはスタンバイ・データベースのインスタンス化	最大76ミリ秒(両方のピアリング・オプションの場合)	単一プロセスのスループット: OCI VCNピアリング(推奨): 1.57 GB/秒 Azureグローバル仮想ネットワーク: 0.197 GB/秒 最大並列度のスループット: OCI VCNピアリング(推奨): 25.5 GB/秒 Azureグローバル仮想ネットワーク: 2.81 GB/秒	ご使用の環境でMAA推奨のネットワーク・テストを繰り返します。「ネットワーク評価」のテスト例を参照してください OCIピアリングを使用して、より高い帯域幅を実現します(一部の例では最大600%) OCIピアリングについては、次を参照してください 同一リージョン: ローカル・ピアリング・ゲートウェイを使用したローカルVCNピアリング クロスリージョン: Oracle Database@AzureでのExadataデータベースのリージョン間障害時リカバリの実行 Azureピアリングについては、仮想ネットワーク・ピアリングを参照してください 可変事項によって帯域幅に影響がある場合があります。Azure仮想マシンの場合のネットワーク・スループットの最適化を参照してください

Azureネットワークに関する推奨事項および考慮事項

• Oracle Databaseのネットワーク・トポロジおよび接続
  • https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/oracle-iaas/oracle-network-topology-odaa#design-recommendations
• Data GuardのクロスリージョンAzureピアリング(OCIピアリング推奨)は、総スループットに影響されます
  • https://learn.microsoft.com/en-us/azure/virtual-wan/hub-settings#edit-virtual-hub-capacity

MAA Silverのネットワーク・トポロジおよび評価

次のMAA Silver HA図では、AzureまたはOCIにおいて実行されている自律型リカバリ・サービスへのバックアップを使用したExaDB-D上のOracle RACを示しています。

図33-1 Oracle Database@Azureの場合のMAA Silverアーキテクチャ

Oracle MAAで、MAA Silverリファレンス・アーキテクチャについてOracle Database@Azureを評価し承認し、次の結果を観測しました。

• アプリケーション待機時間は、データベース・サーバー・ターゲットへのアプリケーションVMの近接性によって影響を受ける場合があります。最短のレイテンシを実現するためには、アプリケーションVMをデータベースと同じ可用性ゾーン(AZ)に配置し、直接通信(Azureネットワーク仮想アプライアンス、ファイアウォールなど以外)を使用します。高可用性を実現するためには、可能な場合は複数のAZへの複数のアプリケーションVMの配置を評価します。次の「Azure上のアプリケーション・ネットワーク層」および「Network topology and connectivity for Oracle Database@Azure - Getting started」を参照してください。

• Autonomous Recovery Service@Azure、OCI上の自律型リカバリ・サービス、およびOCI上のOSSによるバックアップとリストアのパフォーマンスは、想定どおりです。後述の「バックアップとリストアの観測結果」を参照してください。
• アプリケーションとデータベースの稼働時間は、計画外ローカル停止の注入、データベースとシステム・ソフトウェアの更新、およびシステムとデータベースのエラスティック変更(CPU、ストレージの増加など)の間に、想定どおりに維持されています。評価されるテストについては「Oracle MAAによるOracle Databaseマルチクラウド評価」を、想定されている結果とメリットについては「Oracle Exadata Cloud SystemsにおけるOracle Maximum Availability Architecture」を参照してください。
• 構成ヘルス・チェック(Exachk実行など)は、確実なMAA準拠に役立ちます。データベース・サービスの"ヘルス"イベントを有効にし、毎月Exachk出力を確認することをお薦めします。

Azure上のアプリケーション・ネットワーク層

データベース・クラスタへのアプリケーション層の近接性は、アプリケーションのレスポンス時間に影響します。

待機時間が非常に短いレスポンス時間(200-400マイクロ秒など)にする必要がある場合は、アプリケーションVMを、データベース・クラスタと同じ可用性ゾーン(AZ)にデプロイします。アプリケーションおよびデータベース・サーバーが複数のVNetまたはAZをまたいで構成されている場合、待機時間は1ミリ秒以上に増えます。

高可用性を確保するために、2つ以上のAZにわたりアプリケーション層をデプロイします。複数のAZにわたるデプロイメント・プロセスおよびソリューションは、アプリケーションのコンポーネント、Azureサービス、および関連するリソースによって異なります。たとえば、Azure Kubernetes Services (AKS)を使用する場合、ワーカー・ノードを別々のAZにデプロイできます。Kubernetes制御プレーンにより、ポッドとワークロードがメンテナンスおよび同期されます。

バックアップとリストアの観測結果

バックアップについてRMANのnettestを使用し、想定されている結果になりました。nettestの詳細は、My Oracle SupportのドキュメントID 2371860.1を参照してください。

Oracleの自律型リカバリ・サービスまたはオブジェクト・ストレージ・サービスへのOracle Databaseバックアップおよびリストアのスループットは、パフォーマンスの想定値以内でした。たとえば、ExaDB-Dの2ノードのクラスタ(16以上のOCPUを使用)および3つのストレージ・セルで、他のワークロードがない状態で、バックアップ速度が4 TB/時間、リストア速度が約8.7 TB/時間であることが確認されたとします。

RMANチャネルを増やすことで、使用可能なネットワーク帯域幅またはストレージ帯域幅を活用し、3つのExadataストレージ・セルの場合に、最大で42 TB/時間のバックアップ速度と8.7 TB/時間のリストア速度を実現できます。リストア速度は、Exadataストレージ・セルを追加すると増加する可能性があります。パフォーマンスは、共有インフラストラクチャ上の既存のワークロードおよびネットワーク・トラフィックによって異なります。

Autonomous Recovery Serviceにより、さらに次のような利点がもたらされます:

• リアルタイム・データ保護機能を活用してデータ損失を排除
• 独自の"永久増分"バックアップのメリットにより、本番データベースでのバックアップ処理のオーバーヘッドと時間を大幅に削減できます。
• ポリシー主導のバックアップ・ライフサイクル管理の実装
• 追加のマルウェア保護

MAA Goldのネットワーク・トポロジおよび評価

Azureにおけるお薦めのMAA Goldアーキテクチャは、次の内容で構成されています:

• Oracle Data Guardの使用時は、Oracle Exadataインフラストラクチャ(ExaDB-D)は、IP CIDR範囲が重複していない別々のVNetを使用して2つの異なる可用性ゾーン(AZ)またはリージョンにプロビジョニングされます。
• プライマリ・クラスタとスタンバイ・クラスタに割り当てられたバックアップ・ネットワーク・サブネットには、重複するIP CIDR範囲はありません。
• アプリケーション層は2つ以上のAZにまたがり、VNetは、プライマリおよびスタンバイVMクラスタからなる各VNetとピアリングされます。
• データベースのバックアップとリストアの操作では、Autonomous Recovery Service@Azure、OCI上の自律型リカバリ・サービスまたはOCIオブジェクト・ストレージについては、高帯域幅のネットワークが使用されます。

図33-2 同じAzureリージョン内のMAA Gold DRアーキテクチャ

「図33-2 同じAzureリージョン内のMAA Gold DRアーキテクチャ」の説明

図33-3 2つのAzureリージョンにわたるMAA Gold DRアーキテクチャ

「図33-3 2つのAzureリージョンにわたるMAA Gold DRアーキテクチャ」の説明

ネットワーク層

Oracle Data Guardでは、そのネットワーク全体にわたりすべてのデータ変更(REDO)をスタンバイ・データベースに送信(および適用)することでプライマリ・データベースの正確な物理コピーを保持して、実装の成功にとって重要な、ネットワーク・スループット(および場合によっては待機時間)を実現します。計画メンテナンスまたは障害時リカバリのテストには、Data Guardスイッチオーバーを使用します。プライマリ・データベースが使用不可になる場合は、Data Guardフェイルオーバーを使用してサービスを再開します。

プライマリとスタンバイの間のネットワークのピアリング

これは、スタンバイが遅れずついていけるようにするための最も重要な決定です。ネットワークに、シングルプロセスのREDOスループットをサポートするための十分な帯域幅がない場合は、スタンバイの転送ラグが大きくなります。

プライマリおよびスタンバイのExadataクラスタは、別々のネットワークにデプロイされます。Oracle Database@AzureのExadataクラスタは、必ず、OCI内の別個の仮想クラウド・ネットワーク(VCN)を使用してデプロイされます。これらの別個のVCNを接続して、それらの間をトラフィックが通過できるようにする必要があります。つまり、それらを、Oracleクラウド自動化によってData Guardが有効になる前に、"ピアリング"する必要があります。このため、それらのネットワークでは、重複しない別個のIP CIDR範囲が使用されている必要があります。

複数の可用性ゾーン(AZ)にわたるピアリングは、OCIまたはAzureネットワークを使用して実行できます。お薦めのオプションは、複数のOCI VCNをピアリングし、REDOトラフィックにそのOCIネットワークを使用することです。OCI VCNピアリングでは、データベース・クラスタ間での、より高いシングルプロセス・ネットワーク・スループット(最大11.7 Gビット/秒を観測済)が、低コストで提供されます。Azureネットワークを使用したピアリングでは、観測された単一プロセス・スループットは2.97 GB/秒であり(これは、REDO率が350 MB/秒を超えるOLTPまたはバッチ・ジョブがあるアプリケーションの場合は不十分)、VNet間トラフィックに対するチャージバックがあります。なお、Azure VNetは、OCI VCN (仮想クラウド・ネットワーク)と同様の仮想ネットワークです。

クロスリージョンのネットワーク・ピアリングの場合は、OCIが、データベース・インスタンス当たり197 Mビット/秒または25 MB/秒を超えるエンタープライズ・アプリケーションおよびデータベースのための、成功できる唯一の選択肢です。OCI VCNピアリングでは、Oracle RACデータベース・インスタンス当たりの、より高いシングルプロセス・ネットワーク・スループット(最大1.57 Gビット/秒または最大196MB/秒を観測済)が提供されます。データベース・クラスタ間の待機時間は、物理的な場所とネットワーク・トポロジによって異なります。最初の10TB/月では、リージョン間のトラフィックに対するチャージバックはありません。なお、シングル・プロセスのスループット、最大ネットワーク・スループットおよび待機時間は、データ・センターの場所によって異なる場合があります。

Oracle Database@Azureサービス・ネットワークは、Oracleに管理されている動的ルーティング・ゲートウェイ(DRG)によってExadataクライアント・サブネットに接続されます。DRGは、複数リージョン間でVCNをピアリングするためにも必要であり、OCI内のVCNごとにDRG 1つのみが許可されます。したがって、プライマリVCNとスタンバイVCNを接続するには、通信で、各リージョン内にそれ固有のDRGがある2番目のVCNを介した転送が必要になります。

Data Guardでのお薦めのOCI VCNピアリング

• AzureでのData Guardのクロス可用性ゾーン構成については、「複数の可用性ゾーンにわたるネットワーキングの設定」の手順に従ってください。
• AzureでのData Guardのクロスリージョン構成については、「複数リージョンにわたるネットワーキングの設定」の手順に従ってください。
  • Azure Virtual WANハブ・モデルとネットワークに関する推奨事項: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/oracle-iaas/oracle-network-topology-odaa#design-recommendations
  • ネットワーク帯域幅ベースの仮想ハブ設定: https://learn.microsoft.com/en-us/azure/virtual-wan/hub-settings#edit-virtual-hub-capacity

Data GuardのためのAzure VNetピアリングの代替オプション

このオプションは、データベース・ワークロードおよびREDO生成率がシングル・プロセスのネットワーク帯域幅の結果よりはるかに低い場合のみ選択します。Data GuardのREDOトラフィックのためにAzure VNetをピアリングするには、仮想ネットワーク・ピアリングを参照してください。

複数のネットワークがAzureを介してピアリングされている場合は、シングルプロセスのネットワーク・スループットが、Oracle OCIでピアリングされているネットワークよりも大幅に低くなる可能性があります。これは、Data GuardのREDO転送が、データベース・インスタンスごとのシングル・プロセスであるためです。このため、1つのインスタンスでREDOがより高い率で生成された場合、転送ラグが増えて累積される可能性があります。ネットワークがAzureを介してピアリングされている場合は、各VNetで、イングレスおよびエグレス・ネットワーク・トラフィックの追加コストが発生します。

Data Guardの有効化

前述のいずれかのオプションによってネットワークをピアリングした後は、Data Guardを有効にできます(Exadata Cloud InfrastructureでのOracle Data Guardの使用を参照)。

Data Guardロール・トランジション

Data Guardスイッチオーバーおよびフェイルオーバーのタイミングは、Oracle OCIでの同様の設定に比べて想定内でした。Data Guardスイッチオーバーおよびフェイルオーバーの実行時のアプリケーション停止時間は、30秒から数分までの範囲である可能性があります。Data Guardロール・トランジションのタイミングのチューニングに関するガイダンス、またはロール・トランジションのタイミングの例は、「Oracle Data Guardのチューニングおよびトラブルシューティング」を参照してください。

複数の可用性ゾーンにわたるネットワーキングの設定

Oracle MAAでは、障害時リカバリ設定での、複数の可用性ゾーンにまたがるネットワーキングに関するベスト・プラクティスをお薦めしています。

次のことを確認してください

• Oracle Exadataインフラストラクチャ(ExaDB-D)が、2つの可用性ゾーン(AZ)においてプロビジョニングされている。各Exadataインフラストラクチャで、プライマリ環境とスタンバイ環境を形成するために、少なくとも1つのExadata VMクラスタが別個の仮想ネットワーク(VNet)にデプロイされている。
• プライマリ・クライアントとスタンバイ・クライアントおよびバックアップ・サブネットが、IP CIDR範囲が重複することなく、別々のVNetであることを確認してください。
• Azure Kubernetes Servicesが少なくとも2つのAZにまたがり、VNetが、プライマリおよびスタンバイVMクラスタの各VNetとピアリングされている。
• データベースのバックアップとリストアの操作が、高帯域幅のネットワークを介してOCIオブジェクト・ストレージに対して実行される。

図33-4 同じAzureリージョン内のMAA Gold DRアーキテクチャ

「図33-4 同じAzureリージョン内のMAA Gold DRアーキテクチャ」の説明

Azureでのアプリケーション層の構成

1. 少なくとも2つのAZにわたりアプリケーション層をデプロイします。

   複数のAZにわたりデプロイするためのプロセスとソリューションは、アプリケーションのコンポーネント、Azureサービス、および関連するリソースによって異なります。たとえば、Azure Kubernetes Services (AKS)を使用する場合、ワーカー・ノードを別々のAZにデプロイできます。Kubernetes制御プレーンにより、ポッドとワークロードがメンテナンスおよび同期されます。

2. 「アプリケーションの継続的な可用性の構成」で説明されている手順に従ってください。

OCIでのデータベース層の構成

ExadataクラスタがAzure内で作成されている場合、各クラスタはOCI内の異なる仮想クラウド・ネットワーク(VCN)にあります。Data GuardびREDO転送には、VCN間の接続が必要です。AzureでData Guardを有効にする前に、この接続(つまり、ピアリング)を構成する必要があります。Data Guardで求められているように、別々のVCN内のリソースが相互に通信するには、それらのVCNをピアリングする手順と、IPアドレス範囲を相互にアクセス可能にするための手順がさらに必要になります。

Oracle Data Guardにより、プライマリ・データベースからREDOデータを転送し適用することで、スタンバイ・データベースがメンテナンスされます。計画メンテナンスまたは障害時リカバリのテストには、Data Guardスイッチオーバーを使用します。プライマリ・データベースが使用不可になる場合は、Data Guardフェイルオーバーを使用してサービスを再開します。

OCIはパフォーマンス(待機時間、スループット)のためのお薦めのネットワークであり、エグレスまたはイングレス・コストは発生しません。ExadataクラスタがAzure内で作成されている場合、各クラスタは、異なるOCI仮想クラウド・ネットワーク(VCN)内で構成されます。Data Guardで必要な場合は、さらにステップを実行してVCNをピアリングし、様々なVCN内のリソースの相互通信のためにそのIPアドレス範囲に相互アクセスを可能にする必要があります。

次のステップでは、OCI管理対象ネットワークを使用して複数のAZにわたりData Guardを有効にするプロセスを説明します。

1. OCIコンソールにログインし、プライマリおよびスタンバイExadata VMクラスタのVCNにローカル・ピアリング・ゲートウェイ(LPG)を作成します。

   詳細は、ローカル・ピアリング・ゲートウェイの作成を参照してください。

2. プライマリLPGとスタンバイLPGの間にピア接続を確立し、スタンバイVCNで、ピアリングされていないピア・ゲートウェイを選択します。

   詳細は、別のLPGへの接続を参照してください。

   各VCNに設定できるローカル・ピアリング・ゲートウェイ(LPG)は1つのみです。特定のExadataクラスタに複数のデータベースがあり、異なるExadataクラスタにスタンバイ・データベースが存在することになる場合は、ハブVCNを構成する必要があります。ハブVCN内の転送ルーティングを参照してください

3. インバウンドおよびアウトバウンド・データ転送コストを発生させずにOCIネットワークを介してプライマリ・データベースとスタンバイ・データベースの間のトラフィックをルーティングするように、デフォルトのルート表を更新します。

   ノート:

   デフォルトのルート表を更新するには、現在は、テナンシ名および動的ルーティング・ゲートウェイ(DRG)のOCIDを提供してサポート・チケットSRを作成する必要があります。

   「認可に失敗したか、リクエストされたリソースが見つかりません」というエラーが発生した場合は、次の情報を指定してサービス・チケットをオープンします:

   • チケットのタイトル: "VCNルート表更新の権限が必要"
   • 各VNCおよびそのDRGアタッチメントの情報(リージョン、テナンシOCID、VCN OCID、DRG OCID)を含める

4. プライマリおよびスタンバイのネットワーク・セキュリティ・グループを更新して、TCPポート1521のプライマリおよびスタンバイ・クライアント・サブネット・イングレスを許可するセキュリティ・ルールを作成します。

   オプションで、データベース・サーバーへの直接SSHアクセス用のSSHポート22を追加できます。

5. プライマリ・データベースに対してData GuardまたはOracle Active Data Guardを有効にします。

   Oracle Databaseの詳細ページで、「Data Guardアソシエーション」リンク、「Data Guardの有効化」の順にクリックします。

   「Data Guardの有効化」ページ内:

   1. Azure AZにマップされたスタンバイ可用性ドメインを選択します。
   2. スタンバイExadataインフラストラクチャを選択します。
   3. 目的のスタンバイVMクラスタを選択します。
   4. 「Data Guard」または「Active Data Guard」を選択します(MAAでは、データ破損の自動ブロック修復、およびレポートのオフロード機能のためにActive Data Guardをお薦めしています)。
   5. ご自分のRTOおよびRPOを満たす保護モードおよびREDO転送タイプを選択します。

   6. 既存のデータベース・ホームを選択するか、新しいデータベース・ホームを作成します。

      プライマリ・データベースの同じカスタム・データベース・ソフトウェア・イメージをスタンバイ・データベース・ホーム用に使用して両方で同じパッチを使用できるようにすることをお薦めします。

   7. SYSユーザーのパスワードを入力し、Data Guardを有効にします。

   オプションで、障害発生時のリカバリ時間を短縮するために、Data Guardオブザーバを別のVM(できれば別の場所またはアプリケーション・ネットワーク内)にインストールすることで自動フェイルオーバー(ファスト・スタート・フェイルオーバー)を有効にします。詳細は、Oracle Data Guard Brokerガイド内のファスト・スタート・フェイルオーバーおよびバインドされたRTOおよびRPOへのファスト・スタート・フェイルオーバーの構成(MAA Gold要件)を参照してください。現在は、これらの手順はクラウド自動化に含まれておらず手動です。

   Data Guardを有効にすると、スタンバイ・データベースが「Data Guardアソシエーション」セクションにリストされます。

複数リージョンにわたるネットワーキングの設定

Oracle MAAでは、Oracle Database@Azure DR構成での複数のAzureリージョンにわたるネットワーキングについて、これらのベスト・プラクティスをお薦めしています。

次のアーキテクチャ図では、2つのAzureリージョン内のコンテナ化されたAzure Kubernetes Service (AKS)アプリケーションを示しています。コンテナ・イメージはAzureコンテナ・レジストリに格納され、プライマリ・リージョンとスタンバイ・リージョンの間でレプリケートされます。ユーザーは、パブリック・ロード・バランサを介して外部からアプリケーションにアクセスします。データ保護のために、データベースは、Oracle Data Guardを使用してExadata VMクラスタ内でプライマリ/スタンバイ・モードで実行されています。データベースのTDE暗号化キーは、OCI Private Vaultに格納され、リージョン間でレプリケートされます。自動バックアップは、各リージョン内のOCIオブジェクト・ストレージにあります。

図33-5 2つのAzureリージョンにわたるMAA Gold DRアーキテクチャ

「図33-5 2つのAzureリージョンにわたるMAA Gold DRアーキテクチャ」の説明

複数リージョンにわたるOracle Database@Azureの場合のネットワーク原則

Oracle MAAでは次のことをお薦めしています:

• Exadataインフラストラクチャを各リージョン、プライマリおよびスタンバイにデプロイします。
• 各Exadataインフラストラクチャで、Azure仮想ネットワーク(VNet)の委任先サブネット内にExadata VMクラスタをデプロイします。
• Oracle Real Application Clusters (RAC)データベースをそのクラスタ上でインスタンス化できます。同じVNet内で、別のサブネットにAKSをデプロイします。
• リージョンをまたいであるOracle Databaseから別のOracle Databaseにデータをレプリケートするように、Oracle Data Guardを構成します。
• 複数のExadata VMクラスタがOracle OCI子サイト内に作成されるときは、それぞれが、それ固有のOCI仮想クラウド・ネットワーク(VCN)内に作成されます。Data Guardでは、複数のデータベースで相互に通信してREDOが送信されロール・トランジションが実行される必要があります。この通信を可能にするには、VCNをピアリングする必要があります。
• OCIは、ネットワーク帯域幅の向上、ネットワーク・スループットの向上、コストの削減のためのお薦めのネットワークです(最初の10 TB/月は無料)。

その他の詳細と設定手順は、Oracle Database@AzureでのExadataデータベースのリージョン間障害時リカバリの実行を参照してください。

ノート:

構成後は、障害発生時のリカバリ時間を短縮するために、Data Guardオブザーバを別のVM(できれば別の場所またはアプリケーション・ネットワーク内)にインストールすることで自動フェイルオーバー(ファスト・スタート・フェイルオーバー)を有効にできます。詳細は、ファスト・スタート・フェイルオーバー、およびOracle Data Guardの構成とデプロイに関するドキュメントを参照してください。(これらは、現在は手動の手順であり、クラウド自動化に含まれていません。)