Oracle Database@AWS向けOracle Maximum Availability Architecture

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

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

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

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

Oracle Exadata Database Service on Dedicated InfrastructureのMAA Silverリファレンス・アーキテクチャ
Oracle Exadata Database Service on Dedicated InfrastructureのMAA Goldリファレンス・アーキテクチャ。同一または別の可用性ゾーン(AZ)内、あるいは異なるリージョン内の、別のExadataインフラストラクチャにスタンバイ・データベースが存在する場合。なお、ネットワーク待機時間とネットワーク帯域幅は、ソースとターゲットの場所によって異なる場合があります。

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

次の図は、Exadata Database Service上のOracle RACを使用したMAA Silverリファレンス・アーキテクチャを示しており、OCI内で実行されているOracle Database Autonomous Recovery Serviceへ、またはAWS内のAmazon S3へのバックアップ・オプションを示しています。

図36-9 MAA Silverリファレンス・アーキテクチャでのOracle Database@AWS

「図36-9 MAA Silverリファレンス・アーキテクチャでのOracle Database@AWS」の説明

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

アプリケーションとデータベースの稼働時間は、計画外ローカル停止の注入、データベースとシステム・ソフトウェアの更新、およびシステムとデータベースのエラスティック変更(たとえば、CPU、ストレージの増加など)の間に、想定どおりに維持されています。評価されたテストについては、「マルチクラウド・ソリューションに関するMAA評価」を参照してください。
「Oracle Exadata Cloud SystemsにおけるOracle Maximum Availability Architecture」では、クラウドMAAのテンプレート、高い可用性と短時間のブラウンアウト、データ保護、レスポンス時間に関するサービス品質、計画外停止の場合の停止時間の短縮、計画メンテナンスの場合のアプリケーションへの影響の最小化、およびエラスティックなシステム操作を含め、すべてのメリットが説明されています。

AWSに固有のその他のMAAベスト・プラクティス

アプリケーションVMの配置と高可用性を慎重に考慮します。アプリケーション待機時間は、データベース・サーバー・ターゲットへのアプリケーションVMの近接性によって影響を受ける場合があります。

待機時間を最短にするためには、アプリケーションVMをデータベースと同じ可用性ゾーン(AZ)に配置し、直接通信(AWSネットワーク仮想アプライアンス、ファイアウォールなどではない)を使用します。高可用性を実現するためには、アプリケーションのレスポンス時間の要件に応じて、同じAZ内での、または複数のAZにわたる、複数のアプリケーションVMの配置を評価します。後述の「アプリケーション・ネットワーク・レイヤーとアプリケーション・フェイルオーバー」のトピックを参照してください。
後述するように、最良のデータ保護、バックアップおよびリカバリのメリットを実現するには、OCI上のAutonomous Recovery Serviceを使用します。

MAA評価では、OCI内のAutonomous Recovery ServiceとObject Storage Serviceが両方とも期待どおりであることがわかりました。AWS内のS3を使用したMAA評価はまだ進行中です。後述の「バックアップとリストアの観測結果」のトピックを参照してください。
アプリケーションVMが存在するネットワークからExadata VMクラスタ・クライアント・サブネットへの、TCPポート6200のイングレスを許可します。

TCPポート6200へのアクセスにより、Oracle Notification Services (ONS)で高速アプリケーション通知(FAN)イベントについて伝達できるようになります。これは、クラスタ・イベントとサービス・イベントの即時通知を提供して、計画メンテナンスと計画外停止の間に発生した変更内容にアプリケーションが迅速に対応できるようにするために必要です。TCPポート6200のイングレスを許可するためのお薦めの方法は、Oracle Cloudコンソールにログインし、「VMクラスタ情報」に移動し、クライアント・ネットワーク・セキュリティ・グループexa_1521_adjustable_nsgを編集し、次のようなセキュリティ・ルールを追加することです:
- 「方向」は「イングレス」
- 「ソース・タイプ」は「CIDR」
- 「ソースCIDR」は、自分のアプリケーション・ネットワークCIDR
- 「プロトコル」は「TCP」
- 「宛先ポート範囲」は6200
Exadata VMクラスタ・クライアント・サブネット内のICMPエコー・リクエストを許可します。

ICMPエコー・リクエストにより、Exadata仮想マシン間でのping(8)コマンドが可能になります。これは、patchmgrユーティリティによる仮想マシンOSの更新の間に必要になります。ICMPエコー・リクエストを許可するためのお薦めの方法は、Oracle Cloudコンソールにログインし、「VMクラスタ情報」に移動し、クライアント・ネットワーク・セキュリティ・グループexa_static_nsgを編集し、次のようなセキュリティ・ルールを追加することです:
- 「方向」は「イングレス」
- 「ソース・タイプ」は「NSG」
- 「ソースNSG」はexa_static_nsg
- 「プロトコル」は「ICMP」
- 「タイプ」は8
Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルールを参照してください。

アプリケーション・ネットワーク・レイヤーとアプリケーション・フェイルオーバー

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

レスポンス時間に制約があるアプリケーションの場合は、次の表に示す、レスポンス時間の観測結果に留意してください。実施されたテストについては、「マルチクラウド・ソリューションに関するMAA評価」を参照してください。

ユースケース	観測されたRTT待機時間	観測されたネットワーク・スループット	MAAの推奨事項
アプリケーションVMからExadata VMクラスタへ(同一リージョン)	配置によって異なる同じ可用性ゾーン(AZ)内の場合は676マイクロ秒から1.2ミリ秒複数のAZにまたがる場合は2.1ミリ秒以上	配置とVMサイズによって異なる単一プロセスのスループットの場合は5 Gbps 複数(64)のパラレル・プロセスのスループットの場合は25 Gbps	必要なRTT待機時間がアプリケーション要件を満たしていることを確認します。高可用性を実現するために複数のアプリケーションVMを用意し、アプリケーションVMの配置がアプリケーションのRTT待機時間の要件を満たし続けるようにします。実装を十分にテストします。可変事項(VMのサイズや配置など)によって結果に影響がある可能性があります。透過的アプリケーション・フェイルオーバーを有効にするには、「アプリケーションの継続的な可用性の構成」で説明されているステップに従います。

ユースケース

観測されたRTT待機時間

観測されたネットワーク・スループット

MAAの推奨事項

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

配置によって異なる

同じ可用性ゾーン(AZ)内の場合は676マイクロ秒から1.2ミリ秒
複数のAZにまたがる場合は2.1ミリ秒以上

配置とVMサイズによって異なる

単一プロセスのスループットの場合は5 Gbps
複数(64)のパラレル・プロセスのスループットの場合は25 Gbps

必要なRTT待機時間がアプリケーション要件を満たしていることを確認します。
高可用性を実現するために複数のアプリケーションVMを用意し、アプリケーションVMの配置がアプリケーションのRTT待機時間の要件を満たし続けるようにします。
実装を十分にテストします。可変事項(VMのサイズや配置など)によって結果に影響がある可能性があります。
透過的アプリケーション・フェイルオーバーを有効にするには、「アプリケーションの継続的な可用性の構成」で説明されているステップに従います。

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

OracleのAutonomous Recovery ServiceまたはObject Storage Serviceへの、Oracle Databaseのバックアップとリストアのスループットは、パフォーマンスが期待どおりでした。また、求められているすべての組込みバックアップおよびリストア構成とライフ・サイクルのベスト・プラクティスが、クラウド自動化に取り入れられていました。

RMANのnettestと実際のデータベース・バックアップ操作およびリストア操作の使用では、バックアップおよびリストアのパフォーマンスが期待どおりでした。たとえば、Exadata Database Serviceの2ノードのVMクラスタ(16以上のOCPUを使用)と3つのストレージ・セルでは、他のワークロードがない状態で、バックアップ速度が1.5 TB/時間、リストア速度が約2.2 TB/時間であることが観測される場合があります。

なお、RMANのデフォルトのバックアップおよびリストア・チャネルは、データベース・ノード当たりのECPU数によって異なります。dbaascliの使用によって、バックアップおよびリストアのスループットを向上させるためにRMANチャネルの数を増やすことができます。また、channelsPerNode値を変更できます(最大値は、Autonomous Recovery Serviceの場合はノード当たり32、他のターゲット・サービスの場合はそれ以上)。Oracle RMANチャネルごとに40 MB/秒の平均スループットであることが観測されました。このRMANチャネルのスループットは、別のリソース制限が最大値に達するまで、全体的なバックアップまたはリストアのスループットに寄与します。

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

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

リアルタイム・データ保護機能を活用してデータ損失を排除
独自の"永久増分"バックアップのメリットにより、本番データベースでのバックアップ処理のオーバーヘッドと時間を大幅に削減できます。VMクラスタのシェイプとサイズ、データベース・サイズ、およびデータファイルの数に応じて、実効バックアップ速度が20 TB/時間以上に増す可能性があります。
ポリシー主導のバックアップ・ライフサイクル管理の実装
追加のマルウェア保護
データ保護のヘルス・ステータス
長期バックアップ保持。
Autonomous Recovery Serviceデプロイメント用の組込みの高可用性

前述のすべてのメリットから、Oracle MAAでは常に、Autonomous Recovery Serviceが推奨されています。Autonomous Recovery Serviceを有効にするには、Autonomous Recovery Serviceのドキュメントを参照し、必要なセキュリティ・ルールを有効にし、クラウド・コンソールを使用してAutonomous Recovery Serviceオプションを選択します。

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

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

Oracle Data Guardの使用時は、Oracle Exadata VMクラスタは、IP CIDR範囲が重複していない別々のネットワークを使用して、同じリージョン内の複数の可用性ゾーン(AZ)にわたるか、複数のリージョンにわたる、2つの異なる独立したExadataインフラストラクチャにプロビジョニングされます。
プライマリおよびスタンバイExadata VMクラスタに割り当てられたバックアップ・ネットワーク・サブネットには、重複するIP CIDR範囲はありません。
データベースのバックアップ操作とリストア操作では、OCI内のAutonomous Recovery ServiceかObject Storage Service、またはAmazon S3オブジェクト・ストレージについては、高帯域幅のネットワークが使用されます。

次の図は、Exadata Database Service上のOracle RACを使用したMAA Goldリファレンス・アーキテクチャを示しており、OCI内で実行されているOracle Database Autonomous Recovery Serviceへ、およびAWS内のAmazon S3へのバックアップを示しています。1つ目の図は、単一のAWSリージョン内の2つの可用性ゾーンにわたり実装されたアーキテクチャを示しています。2つ目の図は、2つのAWSリージョンにわたりデプロイされたアーキテクチャを示しています。

図36-10 2つのAZがある1つのAWSリージョン内のMAA Goldアーキテクチャ

「図36-10 2つのAZがある1つのAWSリージョン内のMAA Goldアーキテクチャ」の説明

図36-11 2つのAWSリージョン内のMAA Goldアーキテクチャ

「図36-11 2つのAWSリージョン内のMAA Goldアーキテクチャ」の説明

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

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

Data Guardに関する考慮事項とネットワーク・ピアリング

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

計画メンテナンスまたは障害時リカバリのテストには、Data Guardスイッチオーバーを使用します。プライマリ・データベースが使用不可になる場合は、Data Guardフェイルオーバーを使用してサービスを再開します。

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

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

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

複数の可用性ゾーン(AZ)にまたがるスタンバイ・データベースを作成する場合は、次の点を考慮してください

データ損失ゼロがビジネス要件である場合は、RTT待機時間を短くすると、アプリケーションへの影響を軽減できます。
スタンバイの転送ラグとデータ損失の可能性を減らすには、ピーク時のアプリケーション・ワークロードとデータベース・ワークロードに対応するのに十分なネットワーク帯域幅が必要です。ピーク時変更率(たとえば、データベースのREDO率)を評価します。

複数のリージョンにまたがるスタンバイ・データベースを作成する場合は、次の点を考慮してください

複数リージョンにまたがるRTT待機時間は長いため、ほとんどのData Guard構成では、それらのクロス・リージョン・スタンバイ・データベースに非同期REDO転送が使用されます。これにより、そのスタンバイにREDOを送信する際のパフォーマンス・オーバーヘッドが本質的になくなります。
スタンバイの転送ラグとデータ損失を減らすには、ピーク時のアプリケーション・ワークロードとデータベース・ワークロードに対応するのに十分なネットワーク帯域幅が必要です。データベース・インスタンスごとにピーク時変更率(たとえば、データベースのREDO率)を評価し、それをiperfなどのツールの単一プロセス・スループットと比較します。

Data Guardとスタンバイ・データベースの設定前にOCIまたはAWSとピアリングする必要があるかどうかを判断するために役立つように、次の表にある推奨事項を活用できます。ピアリング後とスタンバイの構成前に独自のネットワーク実験を実施することもできます。この動作保証の一環として実施されたテストについては、「マルチクラウド・ソリューションに関するMAA評価」を参照してください。

Data Guardのユースケース	観測されたRTT待機時間	観測されたネットワーク・スループット	MAAの推奨事項
複数のAZにまたがる、複数のExadata VMクラスタ間で、次のことについて: REDO転送データベース移行またはスタンバイ・データベースのインスタンス化	AZによって異なる OCIピアリングでは1700マイクロ秒であることが観測された AWSピアリングでは2200マイクロ秒であることが観測された	配置とVMサイズによって異なる OCIピアリングでの単一プロセスのスループットの場合は33 Gbps OCIピアリングでの複数(64)のパラレル・プロセスのスループットの場合は90 Gbps AWSピアリングでの単一プロセスのスループットの場合は4.9 Gbps AWSピアリングでの複数(64)のパラレル・プロセスのスループットの場合は45 Gbps	ピーク時のデータベース・ワークロードのスループットをサポートできるネットワーク・ピアリング・オプションを選択します。今日のOCIピアリングでは、スループットが大幅に向上しています。 OCIピアリングについては、ローカル・ピアリング・ゲートウェイを使用したローカルVCNピアリングを参照してくださいクロスAZについては、Oracle Database@AWS上のクロスゾーンData Guardを使用した障害時リカバリの実装を参照してください
複数のリージョンにまたがる複数のExadata VMクラスタ間で、次のことについて: REDO転送データベース移行またはスタンバイ・データベースのインスタンス化	リージョンによって異なるリージョンはバージニア州アッシュバーンからオレゴン州ボードマンまでを使用 OCIピアリングでは93ミリ秒であることが観測された AWSピアリングでは65ミリ秒であることが観測された	配置とVMサイズによって異なる OCIピアリングでの単一プロセスのスループットの場合は1.3 Gbps OCIピアリングでの複数(64)のパラレル・プロセスのスループットの場合は35 Gbps AWSピアリングでの単一プロセスのスループットの場合は0.7 Gbps AWSピアリングでの複数(64)のパラレル・プロセスのスループットの場合は20 Gbps	ピーク時のデータベース・ワークロードのスループットをサポートできるネットワーク・ピアリング・オプションを選択します。今日のOCIピアリングでは、スループットが大幅に向上しています。 OCIピアリングについては、動的ルーティング・ゲートウェイを使用したリモートVCNピアリングを参照してください。 OCIでは、ネットワーク帯域幅の向上、ネットワーク・スループットの向上、コストの削減が実現されます(最初の10TB/月は無料)。クロスリージョンについては、Oracle Database@AWS上のクロスリージョンActive Data Guardを使用した障害時リカバリの実装を参照してください

Data Guardのユースケース

観測されたRTT待機時間

観測されたネットワーク・スループット

MAAの推奨事項

複数のAZにまたがる、複数のExadata VMクラスタ間で、次のことについて:

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

AZによって異なる

OCIピアリングでは1700マイクロ秒であることが観測された
AWSピアリングでは2200マイクロ秒であることが観測された

配置とVMサイズによって異なる

OCIピアリングでの単一プロセスのスループットの場合は33 Gbps
OCIピアリングでの複数(64)のパラレル・プロセスのスループットの場合は90 Gbps
AWSピアリングでの単一プロセスのスループットの場合は4.9 Gbps
AWSピアリングでの複数(64)のパラレル・プロセスのスループットの場合は45 Gbps

ピーク時のデータベース・ワークロードのスループットをサポートできるネットワーク・ピアリング・オプションを選択します。今日のOCIピアリングでは、スループットが大幅に向上しています。

OCIピアリングについては、ローカル・ピアリング・ゲートウェイを使用したローカルVCNピアリングを参照してください

クロスAZについては、Oracle Database@AWS上のクロスゾーンData Guardを使用した障害時リカバリの実装を参照してください

複数のリージョンにまたがる複数のExadata VMクラスタ間で、次のことについて:

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

リージョンによって異なる

リージョンはバージニア州アッシュバーンからオレゴン州ボードマンまでを使用

OCIピアリングでは93ミリ秒であることが観測された
AWSピアリングでは65ミリ秒であることが観測された

配置とVMサイズによって異なる

OCIピアリングでの単一プロセスのスループットの場合は1.3 Gbps
OCIピアリングでの複数(64)のパラレル・プロセスのスループットの場合は35 Gbps
AWSピアリングでの単一プロセスのスループットの場合は0.7 Gbps
AWSピアリングでの複数(64)のパラレル・プロセスのスループットの場合は20 Gbps

OCIピアリングについては、動的ルーティング・ゲートウェイを使用したリモートVCNピアリングを参照してください。

OCIでは、ネットワーク帯域幅の向上、ネットワーク・スループットの向上、コストの削減が実現されます(最初の10TB/月は無料)。

クロスリージョンについては、Oracle Database@AWS上のクロスリージョンActive Data Guardを使用した障害時リカバリの実装を参照してください

Gold MAAアーキテクチャへの道

Gold Maximum Availability Architecture (MAA)を実現するために、Oracleでは、クロスリージョン・デプロイメントについて次の原則をお薦めしています:

インフラストラクチャのデプロイ: プライマリ・リージョンとスタンバイ・リージョンの両方で、Exadataインフラストラクチャをデプロイします。
VMクラスタの作成: 各インフラストラクチャで、ODBネットワーク内にExadata VMクラスタを作成します。
データベースのインスタンス化: Exadata VMクラスタにOracle Real Application Clusters (RAC)データベースをデプロイします。
データ・レプリケーションの構成: その複数のリージョンにわたる2つのデータベースの間でデータをレプリケートするようにOracle Data Guardを設定します。

Data Guardのネットワーキング

複数のExadata VMクラスタがAWS内に作成されたときは、それぞれが、それ固有のOracle Cloud Infrastructure (OCI) Virtual Cloud Network (VCN)内に存在します。Data Guard通信(REDOログの送信とロール・トランジションの実行に不可欠)を有効にするには、これらのVCNをピアリングする必要があります。固有のニーズに基づいてOCIピアリングまたはAWSピアリングを柔軟に選択できます。

Data Guardの有効化

前述のオプションのいずれかを使用してネットワークをピアリングすると、Data Guardを有効にできます(Exadata Cloud InfrastructureでのOracle Data Guardの使用を参照)。Data GuardおよびMAAのすべてのベスト・プラクティスが組み込まれています。Data Guardにより、包括的なデータ保護が追加され、データベース、クラスタ、さらにはリージョンの障害について、データ損失と停止時間が最小限に抑えられます。

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

Data Guardスイッチオーバーおよびフェイルオーバーのパフォーマンスは、Oracle OCIでの同様の設定に比べ、期待どおりでした。Data Guardスイッチオーバーおよびフェイルオーバーの実行時のアプリケーション停止時間は、30秒から数分までの範囲である可能性があります。

Data Guardロール・トランジションのタイミングのチューニングに関するガイダンス、またはロール・トランジションのタイミングの例は、「Oracle Data Guardのチューニングおよびトラブルシューティング」を参照してください。Oracle Cloudコンソールのタイミングは、実際のデータベース停止時間を反映していないことに注意してください。停止時間を最小限に抑え、数秒から数分の短いRTOを実現するには、自動Data Guardフェイルオーバーが必要です。Data Guardファスト・スタート・フェイルオーバーの設定は、手動によるステップです。ファスト・スタート・フェイルオーバーおよびOracle Data Guardの構成およびデプロイに関するドキュメントを参照してください。

可用性の向上と障害時のRTOの短縮

停止時間を最小限に抑え、数秒から数分の短いRTOを実現するには、自動Data Guardフェイルオーバーが必要です。

ファスト・スタート・フェイルオーバー(FSFO)機能では、フェイルオーバーが自動的に開始され、Data Guardオブザーバを別のVMにインストールする必要があります。最適な結果を得るには、オブザーバVMをプライマリ・データベースとスタンバイ・データベースとは異なる場所に配置します。その他の場所を使用できない場合は、プライマリ・データベース・サイト(できればアプリケーション・ネットワーク内)にオブザーバを配置します。

ノート:

これは手動による構成ステップであり、標準のクラウド自動化の一部ではありません。

詳しい設定手順については、Oracle Database@AWS上のクロスリージョンActive Data Guardを使用した障害時リカバリの実装を参照してください。

その他の詳細は、ファスト・スタート・フェイルオーバーおよびOracle Data Guardの構成とデプロイに関するドキュメントを参照してください。