1. 高可用性概要およびベスト・プラクティス
  2. Oracle Database Cloudのベスト・プラクティス
  3. Oracle Maximum Availability ArchitectureとOracle Autonomous Database

29 Oracle Maximum Availability ArchitectureとOracle Autonomous Database

Oracle Maximum Availability Architecture (MAA)は、Oracleの高可用性、データ保護および障害時リカバリ・テクノロジを統合して使用するために、Oracleのエンジニアが何年もかけて開発した一連のベスト・プラクティスです。

Oracle MAAの主な目的は、Oracle Cloud MAAアーキテクチャおよびソリューションを使用して、Oracleのシステムやデータベース・プラットフォームで実行されているOracleデータベースとアプリケーションのリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)を満たすことです。

MAAリファレンス・アーキテクチャおよびそれに関連する利点と潜在的なRTOおよびRPOターゲットの概要は、Oracle MAAリファレンス・アーキテクチャを参照してください。また、Autonomous Database CloudはExadata Cloudプラットフォームで実行されるため、差別化された固有のOracle Exadata Cloud HAおよびデータ保護の利点については、「Oracle Exadata Cloud SystemsにおけるOracle Maximum Availability Architecture」を参照してください。

最大可用性アーキテクチャでは、テストおよび開発ライフ・サイクルを通してカオス・エンジニアリングを活用することで、Oracle Cloudにおける障害やメンテナンス・イベントの際にアプリケーションとデータベースのエンドツーエンドの可用性を確保したり、最適なレベルに維持することを確実化します。カオス・エンジニアリングは、システムが本番環境で乱流状態に耐えることができるよう信頼性を高めるためにシステムで実験を行う分野です。具体的には、MAAでは様々な障害や計画メンテナンス・イベントを積極的に注入して、開発、ストレスおよびテスト・サイクルを通してアプリケーションとデータベースに対する影響を評価します。この実験により、ベスト・プラクティス、不具合および知見が導出され、その知識を応用してクラウドのMAAソリューションを進化および向上させます。

デフォルトの高可用性オプションを使用したOracle Autonomous Database (MAA Silver)

高可用性は、稼働時間の要件が厳しく、データ損失の許容範囲がゼロであるか小さいすべての開発、テストおよび本番データベースに適しています。デフォルトでは、Autonomous Databaseの可用性は高く、局所的なソフトウェアおよびハードウェア障害から保護するマルチノード構成が組み込まれています。

それぞれのAutonomous Databaseアプリケーション・サービスは、少なくとも1つのOracle Real Application Clusters (Oracle RAC)インスタンスに配置され、計画外停止または計画メンテナンス・アクティビティの際に別の使用可能なOracle RACインスタンスにフェイルオーバーするオプションを備えており、ゼロまたはゼロに近い停止時間を実現します。

Autonomous Databaseの自動バックアップはOracle Cloud Infrastructure Object Storageに格納され、別の可用性ドメイン(使用可能な場合)にレプリケートされます。障害発生時には、これらのバックアップを使用してデータベースをリストアできます。Exadata Cloud at Customerを使用するAutonomous Databaseの場合、NFSまたはZero Data Loss Recovery Appliance (ZDLRA)にバックアップするオプションがありますが、これらのバックアップのレプリケーションはお客様の責任です。

データベースのメジャー・アップグレードは自動化されています。Autonomous Database Serverlessの場合、停止時間は最小限です。

1か月当たりの稼働時間に関するサービス・レベル合意(SLA)は99.95% (1か月当たり最大22分の停止時間)です。ほとんどの月で停止時間がゼロになるアプリケーションの稼働時間SLAを達成するには、次の「アプリケーション稼働時間の確保」を参照してください。

次の表は、様々な停止のリカバリ時間目標およびリカバリ・ポイント目標(データ損失の許容範囲)を示しています。

表29-1 デフォルトの高可用性ポリシーのリカバリ時間(RTO)およびリカバリ・ポイント(RPO)に関するサービス・レベル目標

障害およびメンテナンス・イベント データベースの停止時間 サービス・レベルの停止時間(RTO) 潜在的なサービス・レベルのデータ損失(RPO)

次のものを含む、局所的なイベント:

  • Exadataクラスタ・ネットワーク・トポロジの障害
  • ストレージ(ディスクおよびフラッシュ)の障害
  • データベース・インスタンスの障害
  • データベース・サーバーの障害
  • ソフトウェアおよびハードウェアの定期的なメンテナンス更新
 ゼロ ほぼゼロ ゼロ

スタンバイ・データベースが存在しないため、バックアップからのリストアを必要とするイベント:

  • データ破損
  • データベース全体の障害
  • 全面的なストレージ障害
  • マルチADリージョンの可用性ドメイン(AD)

数分から数時間

(Autonomous Data Guardなし)

数分から数時間

(Autonomous Data Guardなし)

Oracle Autonomous Database on Dedicated Exadata Infrastructureの場合、15分

Autonomous Database Serverlessの場合、1分

(Autonomous Data Guardなし)

非ローリング・ソフトウェア更新またはデータベース・アップグレードを必要とするイベント

Autonomous Database Serverlessの場合、10分未満

Autonomous Database on Dedicated Infrastructureの場合、数分から数時間

(Autonomous Data Guardなし)

Autonomous Database Serverlessの場合、10分未満

Autonomous Database on Dedicated Infrastructureの場合、数分から数時間

(Autonomous Data Guardなし)

 ゼロ

上の表において、バックアップからのリストアを必要とするイベントの停止時間は、障害の性質によって異なります。最も楽観的なケースでは、物理的なブロック破損が検出され、ブロック・メディア・リカバリを使用してブロックが数分で修復されます。この場合、影響を受けるのはデータベースのごく一部のみであり、データ損失はゼロです。より悲観的なケースでは、データベースまたはクラスタ全体で障害が発生し、すべてのアーカイブを含む最新のデータベース・バックアップを使用して、データベースがリストアおよびリカバリされます。

データ損失は、最後に成功したアーカイブ・ログ・バックアップによって制限されます。この頻度は、Autonomous Database on Dedicated Infrastructureの場合に15分ごと、Autonomous Database Serverlessの場合に1分ごとです。アーカイブまたはREDOは、今後のリカバリ目的でOracle Cloud Infrastructure Object Storageまたはファイル・ストレージ・サービスにバックアップされます。データ損失は数秒間、または最悪の場合、最後に成功したアーカイブ・ログと、外部ストレージにアーカイブされなかったオンラインREDOログの残りのREDOの前後における数分間のデータ損失となります。

Autonomous Data Guardオプションを使用したOracle Autonomous Database (MAA Gold)

Autonomous Data Guardは、データの破損による障害やデータベースまたはサイトの障害に対する稼働時間の要件がより厳しく、同時にAutonomous Databaseの高可用性オプションの利点も求められるミッションクリティカルな本番データベースについて有効化します。

また、読取り専用のスタンバイ・データベースは、レポート作成、問合せおよび一部の更新をオフロードするための拡張アプリケーション・サービスを提供します。読取り専用のスタンバイ・データベースは、Autonomous Data Guard on Dedicated Infrastructureでのみ使用可能です。

Autonomous Data Guardを有効にすると、同じ可用性ドメイン、別の可用性ドメインまたは別のリージョンに配置されたExadataラックに、対称スタンバイ・データベースが1つ追加されます。プライマリ・データベース・システムとスタンバイ・データベース・システムは、Data Guardのロール・トランジション後にパフォーマンス・サービス・レベルが維持されるように、対称的に構成されます。Autonomous Database Serverlessでは2つのスタンバイ・データベースの構成がサポートされており、Autonomous Database on Dedicated Infrastructureは、現時点では単一のデータベースに制限されています。Autonomous Database Serverlessの場合、複数スタンバイ構成は、同じリージョン内のローカル・スタンバイ・データベースとリージョン間スタンバイ・データベースで構成されます。

Oracle Autonomous Data Guardでは、アプリケーション・パフォーマンスへの影響をゼロにするために、デフォルトで非同期REDO転送(最大パフォーマンス・モード)が提供されます。スタンバイ・データベースは、同じ可用性ドメイン内に配置することも、複数の可用性ドメインやリージョンにわたって配置することもできます。MAAでは、最適な障害分離のために、スタンバイを別々の可用性ドメインまたは別のリージョンに配置することをお薦めします。Data Guardのデータ損失ゼロの保護は、同期REDO転送(最大可用性モード)を構成することで実現できます。ただし、同期REDO転送による最大可用性データベース保護モードは、Autonomous Database on Dedicated Infrastructureでのみ使用でき、スタンバイ・データベースは、通常、同じリージョン内の異なる可用性ドメインに配置されます。あるいは、リージョン間のラウンド・トリップ待機時間が最小(5ミリ秒未満)の場合は、複数リージョン間に配置され、障害分離を提供しながらアプリケーションのレスポンス時間とスループットへの影響が無視できる程度になります。さらに、ローカルおよびリモートの仮想クラウド・ネットワーク・ピアリングによって、プライマリ・サーバーとスタンバイ・サーバーの間のあらゆるトラフィックについて、複数の可用性ドメインおよびリージョンにわたってセキュアで高帯域幅のネットワークが提供されます。

バックアップはプライマリ・データベースとスタンバイ・データベースの両方で自動的にスケジュールされ、Oracle Cloud Infrastructure Object Storageに格納されます。Exadata Cloud at Customerを使用するAutonomous Databaseの場合、NFSまたはZero Data Loss Recovery Applianceにバックアップするオプションがありますが、これらのバックアップのレプリケーションはお客様の責任です。プライマリ・データベースとスタンバイ・データベースの両方が失われる二重障害が発生したときには、これらのバックアップを使用してデータベースをリストアできます。

1か月当たりの稼働時間に関するサービス・レベル合意(SLA)は99.995% (1か月当たり最大132秒の停止時間)で、下の表に記載されているように、リカバリ時間目標(停止時間)とリカバリ・ポイント目標(データ損失)は低くなっています。ほとんどの月で停止時間がゼロになるアプリケーションの稼働時間SLAを達成するには、「アプリケーション稼働時間の確保」(XREF)を参照してください。

Autonomous Database Serverlessでの自動Data Guardフェイルオーバーでは、データ損失しきい値サービス・レベルがサポートされており、データ損失がそのしきい値を下回った場合にスタンバイ・データベースへの自動フェイルオーバーが開始されます。Autonomous Database Serverlessではデータ損失ゼロのフェイルオーバーは保証されませんが、プライマリ・データベースに障害が発生し、プライマリ・システム・コンテナおよびインフラストラクチャが使用可能な状態で、残りのREDOをスタンバイ・データベースに送信して適用できる場合には可能です。Autonomous Database on Dedicated Infrastructureによる自動Data Guardフェイルオーバーでは、データ損失ゼロまたはデータ損失しきい値の低いサービス・レベルがサポートされます。いずれの場合も、プライマリ・データベース、クラスタまたはデータ・センターの障害に対して、データ損失のサービス・レベルを保証できる場合、自動Autonomous Data Guardフェイルオーバーが発生します。ターゲット・スタンバイが新しいプライマリ・データベースになり、すべてのアプリケーション・サービスが自動的に有効になります。OCIコンソールには、手動のデータ・フェイルオーバー・オプションが用意されています。手動Data Guardフェイルオーバー・オプションの場合、稼働時間SLAの計算停止時間は、Data Guardフェイルオーバー操作を実行した時点で開始され、新しいプライマリ・サービスが有効化されると終了します。

Autonomous Database Serverlessでの自動Data Guardフェイルオーバーでは、データ損失しきい値サービス・レベルがサポートされています。これにより、データ損失がそのしきい値を下回った場合にスタンバイ・データベースへの自動フェイルオーバーが開始されます。Autonomous Database Serverlessではデータ損失ゼロのフェイルオーバーは保証されていませんが、プライマリ・データベースに障害が発生し、プライマリ・システム・コンテナおよびインフラストラクチャが使用可能な状態で、残りのREDOをスタンバイ・データベースに送信して適用できる場合には可能です。Autonomous Database on Dedicated Infrastructureによる自動Data Guardフェイルオーバーでは、データ損失なし、または構成可能な低いデータ損失しきい値のサービス・レベルがサポートされています。

どのような場合でも、プライマリ・データベース、クラスタまたはデータ・センターの障害に対して、データ損失のサービス・レベルを保証できるときは、自動Autonomous Data Guardフェイルオーバーが発生します。ターゲット・スタンバイが新しいプライマリ・データベースになり、すべてのアプリケーション・サービスが自動的に有効になります。OCIコンソールには、手動のデータ・フェイルオーバー・オプションが用意されています。手動Data Guardフェイルオーバー・オプションの場合、稼働時間SLAの計算停止時間は、Data Guardフェイルオーバー操作を実行した時点で開始され、新しいプライマリ・サービスが有効化されると終了します。

アプリケーションやビジネスの要件とデータ・センターの可用性に応じて、データベース・フェイルオーバー・サイトを、同じ可用性ドメイン、同じリージョン内の別の可用性ドメイン、または別のリージョンに配置するかを選択できます。

表29-2 Autonomous Data Guardのリカバリ時間(RTO)およびリカバリ・ポイント(RPO)に関するサービス・レベル目標

障害およびメンテナンス・イベント サービス・レベルの停止時間(RTO)1 潜在的なサービス・レベルのデータ損失(RPO)

次のものを含む、局所的なイベント:

  • Exadataクラスタ・ネットワーク・ファブリックの障害
  • ストレージ(ディスクおよびフラッシュ)の障害
  • データベース・インスタンスの障害
  • データベース・サーバーの障害
  • ソフトウェアおよびハードウェアの定期的なメンテナンス更新

ゼロまたはほぼゼロ

ゼロ

次のものを含む、Autonomous Data Guardを使用してスタンバイ・データベースにフェイルオーバーする必要があるイベント:

  • データ破損(Data Guardには物理的な破損用の自動ブロック修復があるため2、フェイルオーバー操作は、論理的な破損または広範囲に及ぶデータ破損についてのみ必要です)
  • データベース全体の障害
  • 全面的なストレージ障害
  • 可用性ドメインまたはリージョンの障害3

数秒から2分4

最大可用性保護モード(同期REDO転送を使用)ではゼロ。リージョン内スタンバイ・データベースで最もよく使用されます。これはAutonomous Data Guard on Dedicated Infrastructureで使用できます。

最大パフォーマンス保護モード(非同期REDO転送を使用)ではほぼゼロ。リージョン間スタンバイ・データベースで最もよく使用されます。リージョン内スタンバイ・データベースにも、アプリケーションへの影響をゼロにするために使用されます。これは、Autonomous Data Guard on Dedicated InfrastructureとAutonomous Database Serverlessの両方に適用されます。RPOは、通常は10秒未満です。RPOは、プライマリ・クラスタとスタンバイ・クラスタの間のネットワーク帯域幅およびスループットによって影響を受ける可能性があります。

1 サービス・レベルの停止時間(RTO)では、自動フェイルオーバーの開始前にソースにアクセスできないようにするために、複数のハートビートを含む検出時間が除外されます。

2 物理的な破損用のActive Data Guard自動ブロック修復機能は、Autonomous Data Guard on Dedicated Infrastructureでのみ使用可能です。

3リージョン障害保護を使用できるのは、スタンバイが複数のリージョンにまたがって配置されている場合のみです。

4 バックエンドのAutonomous Data Guardロール・トランジションのタイミングは、クラウド・コンソールのリフレッシュ率で示されるタイミングよりもはるかに高速です。

Autonomous Database on Dedicated InfrastructureとAutonomous Database Serverlessの両方がMAA Goldの検証と認定を受けています。Autonomous Database on Dedicated Infrastructureは、同じリージョン内のスタンバイ・データベース、および別のリージョンのスタンバイ・データベースで検証され、スタンバイ・ターゲットがプライマリと対称であったときに前述のSLAが満たされました。RTOおよびRPO SLAは、最大1000 MB/秒のREDO率で満たされました。Autonomous Database Serverlessは、同じリージョン内のスタンバイ・データベースでのみ検証および認定され、スタンバイ・ターゲットに対称リソースがあるときに前述のSLAを満たしました。RTOおよびRPO SLAは、ターゲットのAutonomous Data Guardプラガブル・データベースが存在するコンテナ・データベース(CDB)全体に対して最大300 MB/秒のREDO率で満たされました。

Autonomous Data GuardオプションおよびOracle GoldenGateを使用したAutonomous Database (MAA Platinum)

Autonomous Database on Dedicated Infrastructureを使用したMAA Platinumは構成可能です。GoldenGateおよびアプリケーション・フェイルオーバーの構成は手動であるため、保証されたSLAは提供されません。

MAA PlatinumやNever-Down Architectureでは、ほぼゼロのリカバリ時間目標(RTO、つまり、停止中に発生した停止時間)と、ゼロである可能性があるかほぼゼロのリカバリ・ポイント目標(RPO、つまり、データ損失の可能性)が提供されます。

Autonomous Database on Dedicated Infrastructureを使用したMAA Platinumでは、次のことが実現されます:

  • RTO = すべてのローカル障害に対してゼロまたはほぼゼロ
  • RTO = データベース、クラスタまたはサイト障害などの障害に対してゼロまたはほぼゼロ。Autonomous Data GuardまたはOracle GoldenGateレプリカを使用するAutonomous Databaseにアプリケーションをリダイレクトすることで実現されます
  • ソフトウェア更新とハードウェア更新のための停止時間ゼロのメンテナンス
  • 別のAutonomous Database on Dedicated Infrastructureに存在するアップグレード済のOracle GoldenGateレプリカにアプリケーションをリダイレクトすることで停止時間ゼロでデータベースまたはアプリケーションをアップグレード
  • RPO = Autonomous Data Guardを使用したAutonomous Databaseで同期REDO転送ありのOracle Data Guard最大可用性保護モードを選択したか最大パフォーマンス保護モードを選択したかに応じてデータ損失ゼロまたはほぼゼロ
  • Cloud MAA GoldenGate HubおよびOracle GoldenGateのベスト・プラクティスを使用して障害発生後にOracle GoldenGateソース・データベースとターゲット・データベースの間で高速で再同期されRPOがゼロまたはほぼゼロ
  • データベース障害の発生後に、そのスタンバイ・データベースへの自動フェイルオーバーが、統合されたData Guardファスト・スタート・フェイルオーバー(FSFO)を使用して自動的に実行されます。その後、ロール・トランジションの後に新しいプライマリからOracle GoldenGateソース・データベースとターゲット・データベースの間の自動再同期が再開されます。同期トランスポートの場合、これにより、データ損失は最終的にゼロになります。

前提条件:

  • GoldenGate競合解決をサポートするには、Autonomous Database on Dedicated InfrastructureでOracle Databaseソフトウェア・リリース19.20以降が実行されている必要があります
  • Autonomous Data Guardおよび自動フェイルオーバーを使用するAutonomous Databaseは、障害発生後の高速GoldenGate再同期用に構成する必要があります
  • GoldenGate設定は、Cloud MAAのベスト・プラクティスに従って手動で行う必要があります
  • 使用可能なGoldenGateレプリカまたは新しいプライマリ・データベースへのアプリケーション・フェイルオーバーを構成する必要があります。現在、グローバル・データ・サービス(GDS)は、このアーキテクチャではAutonomous Databaseとともに使用できません。

MAA Platinumソリューションの実装

MAA Platinumソリューションを実現するには、次の手順において参照されている技術概要およびドキュメントを確認し活用します。

  1. Oracle ExadataのOracle MAA Platinum層を確認して、MAA Platinumの利点とユースケースについて理解してください。
    1. アプリケーションのニーズに基づいてプライマリ・データベースの場所を決定します。プライマリ・データベースは、Autonomous Database on Dedicated Infrastructure内に配置されます。
    2. 障害分離の要件に基づいてスタンバイ・データベースの場所を決定します。
    3. Autonomous Data Guardを有効にします。
    4. RPOの許容範囲に基づいてAutonomous Data Guard保護モードを選択し、自動フェイルオーバーを設定します。
  2. OracleクラウドでMAA GoldenGate Hubを設定します。
    1. 「クラウド: MAA Platinum用Oracle GoldenGate Hubの構成」の手順に従います。
    2. 双方向レプリケーションと自動競合検出および解決。「Oracle GoldenGate Microservices Architectureの双方向レプリケーションの設定」または最新のOracle GoldenGate 21cドキュメントを参照してください。
  3. データベース、クラスタまたはサイト障害が発生した場合にアプリケーションを自動的にフェイルオーバーできるように、アプリケーション・フェイルオーバー・オプションを構成します。

アプリケーション稼働時間の確保

テナンシのAutonomous Databaseリソースにアクセスできるように、Oracle Cloud Infrastructureへのネットワーク接続の信頼性が高いことを確認します。

ガイドラインに従ってAutonomous Databaseに接続します(Autonomous Database ServerlessまたはAutonomous Database on Dedicated Exadata Infrastructureを参照)。アプリケーションは、事前定義されたサービス名に接続し、適切なtnsnsames.oraファイルおよびsqlnet.oraファイルを含むクライアント資格証明をダウンロードする必要があります。要件に合うように、特定のアプリケーション・サービスのdrain_timeout属性を変更することもできます。

計画停止および計画外停止を通して継続的なアプリケーション・サービスを実現する方法の詳細は、「アプリケーションの継続的な可用性の構成」を参照してください。Validating Application Failover Readiness (Doc ID 2758734.1)に従って、アプリケーションの準備状況をテストすることをお薦めします。

データベース・インスタンスの再起動が必要なOracle Exadata Cloud Infrastructureの計画メンテナンス・イベントの場合、Oracle RACインスタンスをすべて停止する前に、Oracleにより自動的に、サービスおよび排出セッションが別の使用可能なOracle RACインスタンスに再配置されます。MAAチェックリストに準拠するOLTPアプリケーションについては、サービスの排出および再配置によってアプリケーションの停止時間がなくなります。

実行時間が長いバッチ・ジョブやレポートなど、一部のアプリケーションでは、排出タイムアウトを長くしても、排出および再配置を正常に行うことができない場合があります。そうしたアプリケーションについては、これらのタイプのアクティビティを除外してソフトウェアの計画メンテナンス・ウィンドウをスケジュールするか、計画メンテナンス・ウィンドウの前にこれらのアクティビティを停止することをお薦めします。たとえば、バッチ・ウィンドウ外になるように計画メンテナンス・ウィンドウを再スケジュールしたり、計画メンテナンス・ウィンドウの前にバッチ・ジョブを停止できます。