Oracle Database@Google Cloud向けOracle Maximum Availability Architecture

Googleは、戦略的なOracle Multicloudハイパースケーラ・パートナです。Oracle Maximum Availability Architecture (MAA)は、Oracle Database@Google Cloud上のOracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)のMAAリファレンス・アーキテクチャを評価します。その結果を次に示します。

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

Oracle MAAで、Google CloudにおけるOracleのソリューションを評価しました。目標は、少なくとも年に1回再評価して、想定されているすべての利点がそのソリューションで実現されていることを確認し、Oracle Database@Google Cloud向けの新しいMAAによる利点と機能を明らかにすることです。認定は、Oracle Database@Google Cloud向けのMAAの評価が要件を満たした後にのみ提供されます。

Oracle MAAは、MAA SilverおよびMAA Goldリファレンス・アーキテクチャに対して、スタンバイ・データベースが別のリージョンのExaDB-Dにのみ存在する場合のOracle Database@Google Cloud上のExaDB-Dを評価および承認しました。

  • テストされた環境は、ドイツのフランクフルトとイングランドのロンドンのリージョン間でした。
  • 異なるリージョンを含むOracle Database@Google Cloud上のActive Data Guard構成は、スループットと待機時間に関して異なる結果になります。

ネットワーク結果

一般的な省略形:

  • OCI - Oracle Cloud Infrastructure (Oracle Cloud)

  • VCN - 仮想クラウド・ネットワーク(Oracle)
  • VPC - 仮想プライベートクラウド(Google Cloud)
  • ExaDB-D - Exadata Database Service on Dedicated Infrastructure
  • VLAN - 仮想ローカル・エリア・ネットワーク
  • RCV - Oracle Database Autonomous Recovery Service

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

ユースケース 観測されたRTT待機時間 観測されたネットワーク・スループット MAAの推奨事項

アプリケーションVMからExadata VMクラスタへ(同一リージョン)

最大300マイクロ秒(同一リージョン/ゾーン)

配置によって異なるアプリケーションVMの待機時間要件を改善するには、Googleサポート・チケットを登録する必要があります。

VMシェイプに基づく変数。

マシン・シリーズの比較については、https://cloud.google.com/compute/docs/machine-resource#machine_type_comparisonを参照してください

例: n2-standard-4 (4 vCPU、16 GBメモリー) 10 Gbps。

必要なRTT待機時間がアプリケーション要件を満たしていることを確認します。

実装を十分にテストします。可変事項(VMのサイズや配置など)によって結果に影響がある可能性があります。

「Google Cloudでのアプリケーション・ネットワーク・レイヤー」のテスト例を参照してください。

次のExadata VMクラスタ間:

  • REDO転送
  • データベース移行またはスタンバイ・データベースのインスタンス化

例のデータは、イングランドのロンドン(LHR)とドイツのフランクフルト(FRA)の間の構成用です。結果は地域によって異なります。

12ミリ秒(FRA-LHR)

FRA-LHRの例

1プロセス(1.4 Gb/秒以上)

  • OCI VCNピアリング: 2.1 Gb/秒(250 MB/秒)
  • Google CloudのVPCネットワーキング*: 2.7 Gb/秒(300 MB/秒)

4プロセス:

  • OCI VCNピアリング: 9.1 Gb/秒(1137 MB/秒)
  • Google CloudのVPCネットワーキング*: 8.3 Gb/秒(1037 MB/秒)

10プロセス(最小8 Gb/秒):

  • OCI VCNピアリング: 22.6 Gb/秒(2825 MB/秒)
  • Google CloudのVPCネットワーキング*: 11.4 Gb/秒(1425 MB/秒)

*Google CloudのVPCネットワーキングのスループット結果は、10Gbps帯域幅(デフォルトは2Gbps)を持つ両方のリージョンのクラウド・インターコネクトVLANアタッチメントに大きく依存します。増加をリクエストするか、観測されたスループットが大幅に少ない場合は、Googleサポート・チケットを登録します。

ご使用の環境でMAA推奨のネットワーク・テストを繰り返します。「ネットワーク評価」を参照してください。

後述の「プライマリ・クラスタとスタンバイ・クラスタ間のネットワーキング」の「スループットのテスト」の項の説明に従って両方のネットワーク・オプションをテストし、ネットワーク・スループットが最小要件およびピークREDO率を超えるようにします。

リージョン間のOCIピアリングについては、Google CloudでのExadata Database Serviceのリージョン間の障害時リカバリの実行を参照してください。

Googleネットワーキングの場合、両方のExaDB-Dクラスタは次のようにする必要があります:

  • 同じVPCネットワークで作成します(追加のネットワークは必要ありません)
  • VPCネットワークでは、MTUをジャンボ・フレーム(8896)に設定する必要があります。
  • Active Data GuardのREDO転送およびスタンバイ・データベースのインスタンス化で許容可能な結果を得るには、両方のリージョンのクラウド・インターコネクトVLANアタッチメント(リージョンごとに4つ)を10Gbpsネットワーク帯域幅以上に設定する必要があります。

変数が帯域幅に影響する可能性があります。Googleのドキュメントhttps://cloud.google.com/compute/docs/network-bandwidthを参照してください。

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

MAA Silverリファレンス・アーキテクチャでは、ハードウェアまたはソフトウェアに障害が発生した場合にデータベースの高可用性が提供されます。MAA Silverの詳細は、ドキュメントを参照してください。

図33-6 Oracle Database@Google向けMAA Silverアーキテクチャ


Google CloudまたはOCIで実行されているOracle Database Autonomous Recovery Serviceへのバックアップを使用した、ExaDB-D上のRACを示すMAA Silver HA図。

Oracle MAAは、MAA Silverに対してOracle Database@Google Cloud上のExaDB-Dを評価および承認し、次のことが観測されました:

  • アプリケーション待機時間は、ターゲット・データベース・サーバーへのアプリケーションVMの近接性によって影響を受ける場合があります。Googleサポート・チケットを登録して、データベースへの待機時間が最短である必要があるアプリケーションが近接するように要求する必要があります。アプリケーション自体の高可用性については、障害から分離された複数のアプリケーションVMを評価します。
  • Google CloudのRCV (デフォルト)、OCIのRCV、OCIのオブジェクト・ストレージ・サービスによるバックアップおよびリストアのパフォーマンスは、MAA Silverの期待を満たしています。後述のバックアップ/復元<リンクを追加>を参照してください。
  • アプリケーションおよびデータベースの可用性は、MAA Silverの期待を満たしており、その際に計画外のローカル停止の挿入、データベースおよびシステム・ソフトウェアの更新、およびシステムとデータベースの柔軟な変更(CPU、ストレージの増加など)が行われました。関連するテストについては「マルチクラウド・ソリューションに関するMAA評価」、および予想される結果と利点については「Oracle Exadata Cloud SystemsにおけるOracle Maximum Availability Architecture」を参照してください。
  • 構成ヘルス・チェック(Exachkなど)は、MAAに確実に準拠するのに役立ちます。MAAでは、データベース・サービスのヘルス・イベントを有効にし、毎月Exachk出力を確認することをお薦めします。

Google Cloudのアプリケーション・ネットワーク・レイヤー

データベース・クラスタへのアプリケーション層の近接性は、アプリケーションのレスポンス時間に影響します。待機時間が非常に短いレスポンス時間(300マイクロ秒)にする必要がある場合は、データベース・クラスタに近接するVPCネットワークにアプリケーションVMをデプロイします。Googleサポート・チケットを登録して、アプリケーションVMがデータベース・クラスタに近接するようにします。

高可用性を実現するために十分な障害分離を備えた複数のアプリケーションVMを使用してアプリケーション層をデプロイします。デプロイメントのプロセスとソリューションは、アプリケーションのコンポーネント、Googleサービス、および関連するリソースによって異なります。たとえば、Google Kubernetes Engine (GKE)では、ワーカー・ノードを異なる場所にデプロイできます。Kubernetes制御プレーンにより、ポッドとワークロードがメンテナンスおよび同期されます。

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

RMANのnettestの結果は期待どおりでした。nettestの詳細は、My Oracle SupportのドキュメントID 2371860.1を参照してください。

Oracle Database Autonomous Recovery ServiceまたはOCIオブジェクト・ストレージ・サービスへのOracleデータベースのバックアップおよびリストアのスループットは、パフォーマンスの期待の範囲内でした。たとえば、ExaDB-Dの2ノードのクラスタ(16以上のOCPUを使用)および3つのストレージ・セルでは、他のワークロードがない状態で、バックアップ速度が4 TB/時間、リストア速度が約8.7 TB/時間と観測されることがあります。RMANチャネルを増やすことで、使用可能なネットワーク帯域幅またはストレージ帯域幅を活用し、3つのExadataストレージ・セルの場合に、最大で42 TB/時間のバックアップ速度と8.7 TB/時間のリストア速度を実現できます。リストア速度は、Exadataストレージ・セルを追加すると増加する可能性があります。パフォーマンスは、共有インフラストラクチャ上の既存のワークロードおよびネットワーク・トラフィックによって異なります。

Oracle Database Autonomous Recovery Serviceには、さらに次のような利点があります:

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

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

MAA Goldのリファレンス・アーキテクチャでは、障害発生時にアクティブにできるデータベースのリモート同期コピーを使用して、ミッションクリティカルなデータベースが保護されます。MAA Goldの詳細は、ドキュメントを参照してください。

Google Cloudで推奨されるMAA Goldアーキテクチャは、次の内容で構成されています:

  • Oracle Active Data Guardを使用する場合、Oracle Exadataインフラストラクチャ(ExaDB-D)は2つの異なるリージョンにプロビジョニングされる。
  • プライマリ・クラスタとスタンバイ・クラスタに割り当てられたネットワーク・サブネットには、重複するIP CIDR範囲がない。
  • アプリケーション層は、プライマリ・アプリケーションVMクラスタとスタンバイ・アプリケーションVMクラスタで構成される複数のアプリケーション・サーバーにまたがる。
  • データベースのバックアップおよびリストアの操作では、Oracle Database Autonomous Recovery Service (Google CloudまたはOCI)またはOCIオブジェクト・ストレージに高帯域幅ネットワークが使用される。

MAA Goldの評価は、MAA Silverの評価に加え、次の内容で構成されています:

  • OCIピアリング・ネットワークまたはマルチクラウド・パートナ・ピアリング・ネットワークを使用したプライマリ・データベース・クラスタとスタンバイ・データベース・クラスタの間のネットワーク・テストによる、ラウンドトリップ待機時間と帯域幅の評価。
  • 障害時リカバリのユースケースにおけるOracle Active Data Guardロール・トランジションのパフォーマンスとタイミング。
  • Active Data Guardを使用したOracle Databaseローリング・アップグレード。

次のアーキテクチャ図は、2つのGoogleリージョン内のアプリケーションを示しています。データ保護のために、データベースは、Oracle Active Data Guardを使用してExadata VMクラスタ内でプライマリ/スタンバイ・モードで実行されています。データベースの透過的データ暗号化(TDE)キーはOCI Vaultに格納され、リージョン間でレプリケートされます。自動バックアップは、Oracle Database Autonomous Recovery Service (Google CloudまたはOCI)にあります。

図33-7 Oracle Database@Googleの場合のMAA Goldアーキテクチャ


2つのGoogleリージョンにわたるMAA Gold DRアーキテクチャ

Oracle MAAは、MAA Goldに対してGoogle Cloud上のExaDB-Dを評価および承認し、次のことが観測されました:

  • プライマリ・データベースとスタンバイ・データベースに選択されたリージョンは、リカバリ・ポイント目標(RPO)をサポートするために重要です。「プライマリ・クラスタとスタンバイ・クラスタ間のネットワーキング」で説明されているように、ネットワーク・スループットが十分である必要があります。
    • ロンドンからフランクフルトへの1つのプロセスでの単一ノードのスループットは2 Gb/秒で、マルチプロセスの最大スループットは最大47 Gb/秒でした。これらのスループットでは、ほとんどのデータベース・ワークロードをサポートできます。
  • 同じリージョン内のアプリケーションVMとデータベース・サーバー間の待機時間は、MAA Goldの期待を満たす300マイクロ秒未満であることが確認されました。
  • データベース・サーバーへのアプリケーションVMのスループットは、VMのサイズによって異なります。VMシェイプごとに割り当てられる帯域幅の詳細は、Google Cloudのドキュメントを参照してください。
  • Oracle Active Data Guardのライフサイクル操作、スイッチオーバー、フェイルオーバーおよび回復は、OCIコンソール(Google Cloud Consoleからアクセスできます)から開始します。これらの操作のパフォーマンスは、MAA Goldの期待に沿っています。
  • OCI VCNピアリングが評価され、帯域幅とレイテンシがMAAの基準を満たしていました。リージョン間のGoogle Cloud VCPネットワーキングの場合、Google VPCアタッチメント帯域幅はネットワーク接続のスループットに大きく影響します。MAAでは、リージョンごとに4つのこれらのアタッチメントに対して少なくとも10 Gb/秒の帯域幅を推奨しています(デフォルトは2 Gbps)。デフォルトから値を増やす場合、またはスループットが期待値を大幅に下回っている場合は、Googleサポート・チケットを開くことができます。https://cloud.google.com/oracle/database/docs/get-supportを参照してください
  • VPCネットワークのMTU設定は8896 (デフォルトは1460)である必要があります。この値を変更するには、Google Cloudのドキュメントを参照してください。

Google Cloud構成でのExaDB-DのOracle Active Data Guardの原則

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

  1. プライマリおよびスタンバイ用に選択したリージョンにExadataインフラストラクチャをデプロイします。
  2. Google Cloud Consoleから、各Exadataインフラストラクチャの適切なVPCにExadata VMクラスタをデプロイします。
    • Google Cloud VPCネットワーキング・オプションの場合、両方のVMクラスタが同じVPC内にある必要があります。OCI VCNピアリングの場合、各VMクラスタに使用されるVPCは異なる場合があります。
    • プライマリおよびスタンバイ・クライアントおよびバックアップ・ネットワークのCIDR範囲は、重複できません。
  3. OCIコンソールを使用して、VMクラスタにOracle Real Application Clusters (RAC)データベースを作成します。
    1. OCIコンソールには、Google Cloud ConsoleのExadataインフラストラクチャの詳細ページから「OCIでの管理」をクリックしてアクセスできます。
    2. 適切なVMクラスタをクリックします。
    3. 「データベースの作成」をクリックし、ウィザードを完了します。
  4. アプリケーション層では、VMクラスタと同じVPCネットワークの別のサブネットにGoogle Kubernetes Engine (GKE)をデプロイします。
    • ノート: VMクラスタのCIDR範囲はGoogle Consoleには表示されませんが、GKEサブネットのCIDRと重複しないようにしてください。
  5. OCIコンソールを使用して、1つのOracle Databaseから別のOracle Databaseにリージョン間でデータをレプリケートするようにOracle Active Data Guardを構成します。
    1. ターゲット・データベースのデータベース・ページで、左側の列のData Guardグループをクリックします。
    2. 「スタンバイの追加」ボタンをクリックして、ウィザードを完了します。
    3. データベースのサイズによっては、スタンバイの作成に30分から数時間かかる場合があります。進捗は、作業リクエスト・リソースを使用してモニターできます。
  6. 複数のExadata VMクラスタがOracle OCI子サイト内に作成されるときは、それぞれが、それ固有のOCI仮想クラウド・ネットワーク(VCN)内に作成されます。Active Data Guardでは、データベースが相互に通信してREDOが送信され、ロール・トランジションが実行される必要があります。
  7. フル・スタックの災害復旧フェイルオーバーを検討する場合は、DNSフェイルオーバーを検討し、(Data Guardスイッチオーバーまたはフェイルオーバーの後の)新しいプライマリ・データベースへのアプリケーション・フェイルオーバーを調整する必要があります。

詳細および設定手順は、Google CloudでのExadata Database Serviceのリージョナル間障害時リカバリの実行を参照してください。

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

Oracle Active Data Guardは、すべてのデータ変更(REDO)をネットワーク全体のスタンバイ・データベースに送信(および適用)することで、プライマリ・データベースの正確な物理コピーを保持します。これにより、ネットワーク・スループット、および場合によっては待機時間が実装の成功のために重要になります。

プライマリ・データベース・クラスタとスタンバイ・データベース・クラスタを接続するには、2つのネットワーク・オプションがあります。OCI VCNピアリングとGoogle Cloud VPCのネットワーキング。選択したネットワーク・オプションに関係なく、各クラスタのCIDRブロックが重複することはできません。

OCI VCNピアリング

各Exadata VMクラスタは、Google Cloudリージョン内の独自のOCI仮想クラウド・ネットワーク(VCN)にデプロイされます(これらのインフラストラクチャに使用されるGoogle Cloud VPCに関係なく)。OCIバックボーン(一貫したスループット結果のためにMAAが推奨)を介してトラフィックをルーティングするために、VCNはハブVCNおよび関連するゲートウェイを介してピアリングされます。後述のOCIピアリングのステップを参照してください。

Google CloudのVPCネットワーキング

Exadata VMクラスタをGoogle Cloudネットワーキングに接続する場合は、各クラスタが同じVPCネットワークに作成されるようにします(ただし、リージョン間構成の場合は異なるリージョンに)。これらのクラスタが通信できるようにするための追加の手順はありません。

スループットのテスト

両方のオプションで構成をテストすることをお薦めします(マルチクラウド・ソリューションに関するMAA評価を参照)。1つのインフラストラクチャに複数のVMクラスタを作成できますが、2つのVMクラスタのペア間のネットワークは、テスト目的で異なる方法で構成できます。各VMクラスタは同じサイズである必要があります。

図33-8 複数のVMクラスタが2つの異なる方法でピアリングされた2つのExadataインフラストラクチャを使用したテスト・シナリオ


複数のVMクラスタが2つの異なる方法でピアリングされた2つのExadataインフラストラクチャを使用したテスト・シナリオ

フランクフルトとロンドンの観測されたネットワーク・スループットの比較

実装を成功させるには、スループットの2つの測定が重要です。

  1. パラレル・プロセスのスループットは、スタンバイ・データベースのインスタンス化(作成)にかかる時間を示します。デフォルトでは、並列度はプライマリ・データベース・ノードごとに4つのプロセスに設定されます。

  2. 単一プロセスのスループットは、REDO転送でスタンバイ・データベースにREDOが送信される速度を示す指標です。各プライマリ・データベース・インスタンスでは、独自のREDOのスレッドを作成し、単一のプロセスによってスタンバイに送信します。いずれかのインスタンスのREDO生成率が単一のデータベース・ノードの単一プロセスのスループット能力を超えると、トランスポート・ラグが発生し、データベースのRPOに影響する可能性があります。

表33-1 ネットワーク・スループットの例(FRA-LHR)

プロセス数 OCI VCNピアリング Google CloudのVPCネットワーキング 最低限の期待値
1 2.1 Gb/秒(260 MB/秒) 2.7 Gb/秒(300 MB/秒) 2 Gb/秒(250 MB/秒)
4 9.1 Gb/秒(1137 MB/秒) 8.3 Gb/秒(1037 MB/秒)  
10 22.6 Gb/秒(2825 MB/秒) 11.4 Gb/秒(1425 MB/秒) 8 Gb/秒(1000 MB/秒)

ノート:

リージョンのペアごとにスループットは異なります。Active Data Guard構成の前にテストを実行して、選択したリージョンに選択されたネットワーク・オプションの機能を理解することが重要です。

OCIピアリングの設定

Google CloudでのExadata Database Serviceのリージョン間の障害時リカバリの実行のOCI VCNピアリングを使用したData Guardのデプロイおよび構成の詳細な手順を参照してください。

Google CloudのVPCネットワーク設定

関連するOracle Database@Google Cloud Exadataインフラストラクチャを同じVPCネットワーク内の異なるサブネットに作成します。

Active Data Guardの有効化

前述のいずれかのオプションを使用してネットワークを構成およびテストしたら、Active Data Guardを有効にできます。詳細は、Exadata Cloud InfrastructureでのOracle Data Guardの使用を参照してください。

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

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

自動フェイルオーバー

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