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

31 Oracle Database@Azure向けOracle Maximum Availability Architecture

Microsoft Azureのデータ・センター内で稼働するOracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)におけるOracle Maximum Availability Architecture(MAA)では、ソフトウェア更新およびエラスティック操作のためのデータベース停止時間がゼロになるなど、本来備わっている高可用性が確保されます。

Oracle Active Data Guardを使用してOracle Cloudスタンバイ・データベースを拡張した場合、このクラウドMAAアーキテクチャでは、包括的なデータ保護と障害時リカバが実現されます。最適化されたExadataハードウェア、Exadata Cloudソフトウェアの自動化、およびOracle MAAのベスト・プラクティスを統合したこの組合せでは、Oracle Exadata Cloudシステムを、ミッションクリティカルなエンタープライズ・データベースおよびアプリケーションに最適なクラウド・ソリューションにできます。

現在は、Oracle MAAソリューション・チームにより、同一Azureリージョン内の、または1つ以上のAzureリージョンにわたる、Oracle Database@Azureを使用したMAA SilverおよびGoldサービス・レベル・リファレンス・アーキテクチャが検証され動作保証されています。ExaDB-Dに存在するプライマリ・データベースにより、高可用性、データ保護、拡張度およびサービス品質(QoS)のパフォーマンスとスケーラビリティの利点がもたらされます。

このアーキテクチャを別のExaDB-Dクラスタを使用してスタンバイ・データベースで拡張すると、データベース障害やクラスタ障害に対する障害時リカバリ保護が提供されます。スタンバイが別のAzure可用性ゾーン(AZ)に存在する場合は、障害時リカバリ・ソリューションが拡張されてAZ全体の障害から保護されます。リージョン全体の障害時リカバリ保護が必要な場合は、スタンバイを別のリージョンで構成できます。

Oracle CloudのMAAアーキテクチャおよび機能の段階的な詳細説明は、Oracle Cloud: Maximum Availability Architectureを参照してください。

Oracle MAAによるOracle Database@Azureの評価

Oracle MAAでは、Exadata Database Service on Dedicated Infrastructure (ExaDB-D)上のMAA Silverアーキテクチャに関して、また、スタンバイ・データベースが同一または別個の可用性ゾーン(AZ)内または別のリージョン内の別のExaDB-Dに存在する場合のMAA Goldに関して、Oracle Database@Azureが評価され承認されています。

Oracleのお客様の確実な成功と一貫性の確保のために、Oracle MAAチームは、Oracle Database@AzureでのMAAリファレンス・アーキテクチャの継続的な評価を実施しています。これらの評価に基づいたMAAソリューションでは、お客様のデータベースを停止(インスタンス、ノード、ストレージ、ネットワーク、様々なデータの破損、データベース、クラスタ、Azure AZの障害など)から守り、それによって、ソフトウェアの更新、構成のエラスティック変更、またはストレージとコンピュートの追加の間のデータベース停止時間をゼロにできます。

Oracle MAAの評価対象

Oracle Database@AzureのMAA評価は、次の内容で構成されています。

  • Oracle Database@Azure AZ内の、またはExaDB-D VMクラスタがある1つ以上のAzureリージョンにわたる、MAA SilverおよびMAA Goldアーキテクチャのクラウド設定

  • 停止を100回以上挿入している間のアプリケーションのスループットおよびレスポンス時間の影響分析(Oracle MAAカオス評価)

  • Oracle Cloud Infrastructure (OCI) Object Storage Service (OSS@OCI)、またはOCI (RCV@OCI)内のAutonomous Recovery Serviceを使用した場合の、バックアップとリストアのパフォーマンス、スループットおよび主要なユースケース

  • 障害時リカバリのユースケースにおけるOracle Data Guardロール・トランジションのパフォーマンスとタイミング

  • ExaDB-Dクラスタのエラスティック操作に関するアプリケーションへの影響

  • ExaDB-Dターゲットへのソフトウェア更新に関するアプリケーションへの影響

MAA Silver

Oracle Database@AzureでのMAA Silverは、次のアーキテクチャからなります。

  • 1つ以上のデータベースをホストする、Azure内に存在するExaDB-Dクラスタ

  • 複数のAZにまたがる高可用性(HA)および冗長アプリケーション層

  • バックアップとリストアのためのKey Management Service、Autonomous Recovery Service (RCV@OCI)およびObject Storage Service (OSS@OCI)は、Oracle Cloud Infrastructure (OCI)にあります。

  • 事前構成済の冗長およびHAネットワーク・トポロジ

MAA Gold

Oracle Database@AzureでのMAA Goldは、次のアーキテクチャからなります。

  • 同一または別個のAzure可用性ゾーン(AZ)またはAzureリージョンに存在するExaDB-Dクラスタ(プライマリ・データベースとスタンバイ・データベース)。

    なお、プライマリ・データベースとスタンバイ・データベース、およびそれらのデータはすべて、Oracle Database@Azureに存在します。プライマリ・データベースとスタンバイ・データベースが同じAZにある場合、このMAA Goldアーキテクチャでは引き続きデータベース障害とクラスタ障害に関して、本来備わっているHAの利点に加え、DRフェイルオーバーのオプションが提供されますが、AZ全体の障害に対するDR保護は欠けています。スタンバイ・データベースが別のAzureリージョンに存在する場合、MAAアーキテクチャにはリージョンの障害保護があります

  • 複数のAZにまたがるHAおよび冗長アプリケーション層

  • Key Management ServiceとAutonomous Recovery ServiceまたはObject Storage Service (バックアップとリストア用)は、Oracle Cloud Infrastructure (OCI)にあります。

  • 事前構成済の冗長およびHAネットワーク・トポロジ

Oracle Maximum Availability Architectureの利点

次に、Oracle Database@AzureのOracle MAAリファレンス・アーキテクチャを実装する利点をいくつか示します。

Oracle Exadata Database MachineシステムにおけるOracle Maximum Availability Architectureの利点の包括的なリストは、Exadata Database Machine: Maximum Availability Architectureを参照してください。

デプロイメント

Oracle Exadata Database Service on Dedicated Infrastructureが稼動しているOracle Database@Azureは、Oracle Maximum Availability Architectureのベスト・プラクティス(ストレージ、ネットワーク、オペレーティング・システム、Oracle Grid InfrastructureおよびOracle Databaseについての構成のベスト・プラクティスを含む)を使用してデプロイされます。ExaDB-Dは、きわめて高いスケーラビリティ、可用性および拡張度でエンタープライズOracleデータベースを実行するように最適化されています。

Oracle MAAデータベース・テンプレート

Oracle Cloudの自動化によって作成されたすべてのOracle Cloudデータベースでは、Oracle Database@Azure用に最適化された、Oracle Maximum Availability Architectureのデフォルト設定が使用されます。カスタム・スクリプトを使用してクラウド・データベースを作成することはお薦めしません。OracleデータベースをOracle Database@Azureに移行する場合は、Oracle Zero Downtime Migration (ZDM)を使用します。Zero Downtime Migrationのドキュメントを参照してください。

メモリーおよびシステム・リソースの設定を調整する以外に、以前のデータベース・パラメータ設定(特に文書化されていないパラメータ)を移行しないようにしてください。有益なプライマリ・データベース・データ保護パラメータの1つであるDB_BLOCK_CHECKINGは、それによりパフォーマンス・オーバーヘッドが発生する可能性があるため、デフォルトでは有効になっていません。クラウド自動化によって構成されたOracleスタンバイ・データベースでは、スタンバイに対してDB_BLOCK_CHECKINGが自動的に有効化されて、スタンバイ・データベースでのデータ保護および検出が最大限になります。MAAでは、アプリケーションのパフォーマンスへの影響を評価すること、およびパフォーマンスへの影響が合理的である場合は論理データ破損の防止と検出を最大限にするためにこの設定をプライマリ・データベースで適用できるようにすることをお薦めしています。Oracle Databaseバージョン19c以降では、Data Guard Brokerで、MAAのベスト・プラクティスを使用してデータ保護設定が維持されます。

バックアップとリストアの自動化

OCIでAutonomous Recovery ServiceまたはObject Storage Serviceへの自動バックアップを構成した場合は、バックアップ・コピーによってさらに保護が提供されます。Oracle Recovery Manager (RMAN)では、クラウド・データベースのバックアップに物理的な破損があるかどうかが検証されます。

データベースのバックアップは毎日行われ、完全バックアップが週に1回、増分バックアップが他のすべての日に行われます。アーカイブ・ログのバックアップは、データベース全体のリストアおよびリカバリが必要な場合のデータ損失の可能性を減らすために、頻繁に実行されます。アーカイブ・ログのバックアップ頻度は、デフォルトでは30分です。ただし、データ損失の可能性は、Oracle Data Guardによりゼロまたはほぼゼロになります。

Autonomous Recovery Serviceを使用すると、毎週のフル・バックアップが不要になり、それ固有の増分バックアップをずっと続けることができます。リアルタイム・データ保護が有効になっている場合は、バックアップからリストアするときに、データ損失がほぼゼロになる可能性があります。バックアップはプライマリ・データベースまたはスタンバイ・データベースで実行でき、様々な保存オプションがあります。

Oracle Exadata Database Machine固有の利点

Oracle Exadata Database Machineは、オラクルが提供する最良のOracle Maximum Availability Architectureデータベース・プラットフォームです。Exadataは、最もミッションクリティカルなエンタープライズ・アプリケーションをサポートする、ハードウェア、ソフトウェア、データベース、可用性、あらゆるワークロードでのきわめて高いパフォーマンス、およびスケーラビリティの技術革新を採用して設計されています。

具体的に言うと、Exadataには、Oracleを他のプラットフォーム・ベンダーやクラウド・ベンダーと差別化する独自の高可用性、データ保護およびサービス品質機能が用意されています。最高の可用性、安定性およびパフォーマンスを確保するには、アプリケーションおよびデータベース・システムのリソース・ニーズ(十分なCPU、メモリーおよびI/Oリソースなど)を満たすようにExadataクラウド・システムのサイズを設定することが非常に重要です。同一クラスタ上で多数のデータベースを統合している場合は、適切なサイズ設定とリソース管理が特に重要です。Exadataの利用時は、データベース統合が、非常に一般的な利点となります。

これらの利点の例は次のとおりです。

  • 高い可用性と短時間のブラウンアウト: 十分な冗長性を備えたフォルト・トレラントなハードウェアがストレージ、ネットワークおよびデータベース・サーバーに存在します。Oracle Real Application Clusters (Oracle RAC)、Oracle Clusterware、Oracle Database、Oracle Automatic Storage Management (ASM)、Oracle Linux、Oracle Exadata Storage Serverなど、リジリエンスがある可用性の高いソフトウェアを使用すると、アプリケーションで、計画外停止や計画メンテナンス・イベントの間にアプリケーションのサービス・レベルを維持できます。

    たとえば、Exadataには即時障害検出が用意されています。この機能では、データベース・ノード、ストレージ・サーバーおよびネットワークの障害を2秒未満で検出し修復して、アプリケーションおよびデータベース・サービスの稼働時間とパフォーマンスを回復できます。他のプラットフォームでは、同じタイプの障害について、30秒あるいは数分に及ぶブラックアウトと長期のアプリケーション・ブラウンアウトが発生することがあります。アプリケーションとデータベースのエンドツーエンドのブラウンアウトおよびブラックアウトを評価するための広範囲にわたる計画外停止および計画メンテナンス・テストを提供しているのは、Exadataプラットフォームのみです。

  • データ保護: Exadataは、物理的および論理的なブロック破損の防止と検出に加えて、場合によっては自動修正をOracle Databaseに提供します。

    Exadata Hardware Assisted Resilient Data (HARD)チェックには、サーバー・パラメータ・ファイル、制御ファイル、ログ・ファイル、OracleデータファイルおよびOracle Data Guard Brokerファイルのサポートが含まれています(これらのファイルがExadataストレージに格納されている場合)。このインテリジェントなExadataストレージ検証では、HARDチェックが失敗すると、破損したデータがディスクに書き込まれなくなるため、データベース業界で以前は防止できなかった大規模なクラスの障害が排除されます。

    Exadata HARDチェックの例は次のとおりです。

    • REDOおよびブロック・チェックサム
    • 正しいログ順序
    • ブロック・タイプの検証
    • ブロック番号の検証
    • ブロック・マジック番号、ブロック・サイズ、順序番号、ブロック・ヘッダーおよびテール・データ構造などのOracleデータ構造

    Exadata HARDチェックは、Exadataストレージ・ソフトウェア(セル・サービス)から開始され、データベースのDB_BLOCK_CHECKSUMパラメータを有効にした後(クラウドではデフォルトで有効になっている)、透過的に機能します。Exadataは、HARDイニシアチブを現在サポートしている唯一のプラットフォームです。

    さらに、Oracle Exadata Storage Serverには、非侵入型の自動ハード・ディスク・スクラブおよび修復が用意されています。この機能では、アイドル時間の間にハード・ディスクが定期的に検査され修復されます。ハード・ディスクで不良セクターが検出されるとします。その場合は、Oracle Exadata Storage Serverで自動的にOracle Automatic Storage Management (ASM)に対して、別のミラー・コピーからデータを読み取ることで不良セクターを修復するようにリクエストが送信されます。

    最終的には、ExadataおよびOracle ASMで、データ・ブロックがバッファ・キャッシュに読み込まれるときに破損が検出され、後続のデータベース書込みでデータ・ブロックの良好なコピーを使用してデータ破損が自動的に修復されます。この固有のインテリジェントなデータ保護により、Exadata Database MachineとExaDB-Dは、Oracleデータベースに最適なデータ保護ストレージ・プラットフォームになります。

    包括的なデータ保護のための最大可用性アーキテクチャのベスト・プラクティスは、別個のExadataインスタンス上のスタンバイ・データベースを使用して、Exadataのみで対処できない破損の検出、防止および自動修復を行うことです。また、スタンバイ・データベースによって、サイト、クラスタおよびデータベースの障害に起因する障害時の停止時間とデータ損失も最小限に抑えられます。

  • レスポンス時間に関するサービス品質: レスポンス時間を確実に短く最適に保つためのエンドツーエンドのサービス品質機能を備えているのは、Exadataのみです。データベース・サーバーのI/Oレイテンシ制限とExadataストレージのI/Oレイテンシ制限により、レスポンス時間が特定のしきい値を超えた場合に、読取りまたは書込みI/Oをパートナ・セルにリダイレクトできます。さらに重要なのは、メモリーとフラッシュが、様々なメンテナンス・イベント、および問題のあるコンポーネントの停止("グレー・ゾーンの停止")のためにインテリジェントに事前にウォームされて、アプリケーションのレスポンス時間とパフォーマンスが維持されることです。このようにエンドツーエンドのパフォーマンスに全体論的に取り組んでいる点は、アプリケーションでの一貫したレスポンス時間と高いスループットを必要とする、オラクルのエンタープライズ分野のお客様にとって大きな利点です。

    パフォーマンスが低く予測不可能であるためストレージの信頼性がなくなる(ただし、障害は発生していない)とします。その場合は、ディスクまたはフラッシュ・キャッシュをオフラインに限定し、後でI/Oパフォーマンスが許容可能レベルに戻ったことが経験則で判明したときにオンラインに戻すことができます。リソース管理は、最適化されたレベルでアプリケーションおよびデータベースが動作するように重要なデータベース・ネットワークまたはI/O機能を優先するために役立ちます。

    たとえば、データベース・ログの書込みは、Exadataネットワークおよびストレージでのバックアップ・リクエストよりも優先されます。さらに、パートナ・フラッシュ・キャッシュがウォームされてフラッシュ・ミスが最小限に抑えられるようにすることで、ストレージ・ソフトウェアの更新中に迅速なレスポンス時間が維持されます。

  • エンドツーエンドのテストと全体的なヘルス・チェック: オラクルはOracle Exadata Cloud Infrastructure全体を所有しているため、エンドツーエンドのテスト、および最適化によって、オンプレミスとクラウドのどちらでホストされているかに関係なく、Exadataを使用する世界中のすべてのお客様に利点がもたらされます。ミッション・クリティカルなシステムを実行するために必要な検証済の最適化および修正が、厳密なテストの後に一律に適用されます。ヘルス・チェックは、スタック全体を評価するように設計されています。

    Exadataのヘルス・チェック・ユーティリティEXACHKは、Exadataクラウド対応であり、顧客の変更によって発生した可能性がある構成およびソフトウェアのアラートを強調表示します。現在、他のクラウド・プラットフォームでは、このようなエンドツーエンドのヘルス・チェックは提供されていません。少なくとも月に1回と、ソフトウェア更新の前後にEXACHKを実行して、新しいベスト・プラクティスおよびアラートを評価してください。

  • 稼働時間の改善: 1か月当たりの稼働時間に関するサービス・レベル合意は95% (1か月当たり最長22分の停止時間)ですが、継続的なサービスのためのMAAベスト・プラクティスを使用すると、ほとんどの月で停止時間がゼロになります。Gold MAAを使用すると、スタンバイ・データベースの配置に応じて、データベース、クラスタ、データ・センター(またはAZ)の障害などの様々な障害イベントの発生時にスタンバイ・データベースにフェイルオーバーできます。なお、Data Guardファスト・スタート・フェイルオーバーを使用したターゲット・スタンバイへの自動フェイルオーバーの設定は、手動による設定です(「ファスト・スタート・フェイルオーバーの構成」を参照)。

計画外停止の間の予想される影響

次の表に、様々な計画外停止イベントと、それに関連する、考えられるデータベース停止時間、アプリケーション・レベルのリカバリ時間目標(RTO)、およびデータ損失の可能性またはリカバリ・ポイント目標(RPO)を示します。

Oracle Data Guardアーキテクチャ(MAA Gold)の場合、データベースの停止時間やサービス・レベルの停止時間には、検出時間や、お客様がクラウド・コンソールのData Guardフェイルオーバー操作を開始するまでに要した時間は含まれません。

停止イベント データベースの停止時間 サービス・レベルの停止時間(RTO) 潜在的なサービス・レベルのデータ損失(RPO)

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

Exadataクラスタ・ネットワーク・トポロジの障害

ストレージ(ディスク、フラッシュおよびストレージ・セル)の障害

データベース・インスタンスの障害

データベース・サーバーの障害

 ゼロ ほぼゼロ ゼロ

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

データ破損

データベース全体の障害

全面的なストレージ障害

可用性ゾーンの障害

数分から数時間

(Data Guardなし)

数分から数時間

(Data Guardなし)

Autonomous Recovery Serviceとリアルタイム・データ保護が有効になっている場合はほぼゼロ

Autonomous Recovery ServiceとReal-Time Data Protectionが無効になっている場合、またはクラウド・バックアップ用のObject Storage Serviceがある場合は30分

(Data Guardなし)

Data Guardを使用してフェイルオーバーするイベント:

データ破損

データベース全体の障害

全面的なストレージ障害

可用性ゾーンの障害

リージョン全体の障害

数秒から数分1

自動ブロック修復機能により、物理的な破損については停止時間ゼロ

数秒から数分1

自動ブロック修復を完了する間、物理的な破損を検出するフォアグラウンド・プロセスは一時停止されます

最大可用性(SYNC REDO転送)の場合はゼロ

最大パフォーマンス(ASYNC REDO転送)の場合はほぼゼロ

1MAA Goldの場合は、データベースをリージョン障害から保護するために、プライマリ・データベースとは異なるリージョンでスタンバイ・データベースをインスタンス化します。このMAA評価では、スタンバイ・データベースは別のAZに存在していました。また、自動データベース・フェイルオーバーを実行するには、Data Guardファスト・スタート・フェイルオーバーおよびそのData Guardオブザーバを手動で設定する必要があります。Oracle Real Application Clusterインスタンスごとに300 MB/秒のアプリケーション・ワークロードであることが確認されました。スタンバイ・データベースは最新状態であり、ラグはほぼゼロでした。ワークロードによっては、極端なワークロードのためにスタンバイ・データベースのチューニングが必要になる場合があります(「Oracle Data Guardのチューニングおよびトラブルシューティング」を参照)。

計画メンテナンスの間の予想される影響

次の表に、Oracle Database@Azure上のOracle Exadata Database Service on Dedicated Infrastructureに対する、様々な計画メンテナンス・イベントの影響を示します。

Exadata Cloudのソフトウェア更新の影響

次の表に、様々なソフトウェア更新と、関連するデータベースおよびアプリケーションに対するそれらの影響を示します。これは、Oracle Database@Azure上のOracle Exadata Database Service on Dedicated Infrastructureに当てはまります。

ソフトウェア更新 データベースへの影響 アプリケーションへの影響 スケジュール作成者 実行者

Exadataネットワーク・ファブリック・スイッチ

 データベースの再起動なしで停止時間ゼロ

ゼロから数秒(1桁台)のブラウンアウト

 お客様の優先傾向に基づいてOracleによってスケジュールされ、お客様が再スケジュールできる

Oracle Cloudの操作

Exadataストレージ・サーバー

 データベースの再起動なしで停止時間ゼロ

ゼロから数秒(1桁台)のブラウンアウト

Exadataストレージ・サーバーは、冗長性を維持しながらローリング方式で更新されます。

Oracle Exadata System Softwareにより、フラッシュ・キャッシュに、最も頻繁にアクセスされるOLTPデータのセカンダリ・ミラーがプリフェッチされて、ストレージ・サーバーの再起動中にアプリケーションのパフォーマンスが維持されます。

データベース・バッファ用のExadataスマート・フラッシュは、ストレージ・サーバーの再起動をまたいでも維持されます。

Exadata 21.2ソフトウェアでは、永続ストレージ索引および永続列キャッシュ機能により、ストレージ・サーバーのソフトウェア更新後に一貫した問合せパフォーマンスを実現できます

お客様の優先傾向に基づいてOracleによってスケジュールされ、お客様が再スケジュールできる

Oracle Cloudの操作

Exadataデータベース・ホスト

月次インフラストラクチャ・セキュリティ・メンテナンス

 ホストまたはデータベースの再起動なしで停止時間ゼロ

停止時間ゼロ

Oracleによってスケジュールされ、お客様が再スケジュールできる

Oracle Cloudの操作

Exadataデータベース・ホスト

四半期ごとのインフラストラクチャ・メンテナンス

 Oracle RACローリング更新により停止時間ゼロ

停止時間ゼロ

計画メンテナンスが完了するまでExadata Databaseのコンピュート・リソースが減少します。

 お客様の優先傾向に基づいてOracleによってスケジュールされ、お客様が再スケジュールできる

Oracle Cloudの操作

Exadataデータベース・ゲスト

 Oracle RACローリング更新により停止時間ゼロ

停止時間ゼロ

計画メンテナンスが完了するまでExadata Databaseのコンピュート・リソースが減少します。

 お客様

Oracle CloudコンソールまたはAPIを使用しているお客様

Oracle Databaseの四半期更新またはカスタム・イメージ更新

 Oracle RACローリング更新により停止時間ゼロ

停止時間ゼロ

計画メンテナンスが完了するまでExadata Databaseのコンピュート・リソースが減少します。

データベースOJVMを使用するアプリケーションでは、四半期ごとのデータベースのローリング更新中に特別な考慮事項あります(My Oracle SupportのドキュメントID 2217053.1を参照)。

お客様

Oracle Cloudコンソール、APIまたはdbaascliユーティリティを使用しているお客様

データベース・ホーム・パッチによるインプレース、およびデータベース移動によるアウトオブプレース(推奨)

Data Guardおよびスタンバイ・データベースの場合に有効(My Oracle SupportのドキュメントID 2701789.1を参照)

Oracle Grid Infrastructureの四半期更新またはアップグレード

 Oracle RACローリング更新により停止時間ゼロ

停止時間ゼロ

計画メンテナンスが完了するまでExadata Databaseのコンピュート・リソースが減少します。

 お客様

Oracle Cloudコンソール、APIまたはdbaascliユーティリティを使用しているお客様

停止時間を伴うOracle Databaseのアップグレード

 数分から数時間の停止時間

数分から数時間の停止時間

 お客様

Oracle Cloudコンソール、APIまたはdbaascliユーティリティを使用しているお客様

Data Guardおよびスタンバイ・データベースの場合に有効(My Oracle SupportのドキュメントID 2628228.1を参照)

停止時間がほぼゼロのOracle Databaseアップグレード

 DBMS_ROLLING、Oracle GoldenGateレプリケーション、またはプラガブル・データベースの再配置により最小限の停止時間 DBMS_ROLLING、Oracle GoldenGateレプリケーション、またはプラガブル・データベースの再配置により最小限の停止時間 お客様

DBMS_ROLLINGを利用してdbaascliを使用するお客様(My Oracle SupportのドキュメントID 2832235.1を参照)

一般的な最大可用性アーキテクチャのベスト・プラクティスを使用する顧客

Exadataのエラスティック操作による影響

Exadataクラウド・システムには、データベースおよびアプリケーションのパフォーマンス・ニーズを調整するために使用できるエラスティック機能が多数用意されています。必要に応じてリソースを再配置することで、ターゲット・データベースおよびアプリケーションのシステム・リソースを最大限にし、コストを最小限にできます。

次の表に、Oracle Exadata Cloud InfrastructureおよびVMクラスタのエラスティック更新、およびそれらの更新に関連する、データベースおよびアプリケーションへの影響を示します。特に指定されていないかぎり、これらの操作はすべて、Oracle CloudコンソールまたはAPIを使用して実行できます。

VMクラスタの変更 データベースへの影響 アプリケーションへの影響
VMクラスタ・メモリーのスケール・アップまたはスケール・ダウン Oracle RACローリング更新により停止時間ゼロ ゼロから数秒(1桁台)のブラウンアウト
VMクラスタCPUのスケール・アップまたはスケール・ダウン データベースの再起動なしで停止時間ゼロ

停止時間ゼロ

使用可能なCPUリソースはアプリケーションのパフォーマンスおよびスループットに影響する可能性があります
データベース使用状況に応じたASMストレージのスケール・アップまたはスケール・ダウン(サイズ変更) データベースの再起動なしで停止時間ゼロ

停止時間ゼロ

アプリケーションのパフォーマンスへの影響は最小限に抑えられる可能性があります
VMのローカル/u02ファイル・システム・サイズのスケール・アップ(Exadata X9M以降のシステム) データベースの再起動なしで停止時間ゼロ 停止時間ゼロ
VMのローカル/u02ファイル・システム・サイズのスケール・ダウン スケール・ダウンについてはOracle RACローリング更新により停止時間ゼロ ゼロから数秒(1桁台)のブラウンアウト
Exadataストレージ・セルの追加 データベースの再起動なしで停止時間ゼロ

ゼロから数秒(1桁台)のブラウンアウト

アプリケーションのパフォーマンスへの影響は最小限に抑えられる可能性があります
Exadataデータベース・サーバーの追加 データベースの再起動なしで停止時間ゼロ

ゼロから数秒(1桁台)のブラウンアウト

Oracle RACインスタンスおよびCPUリソースを追加すると、アプリケーションのパフォーマンスおよびスループットが向上する可能性があります
仮想マシン(VM)クラスタでのデータベース・ノードの追加 データベースの再起動なしで停止時間ゼロ

ゼロから数秒(1桁台)のブラウンアウト

Oracle RACインスタンスとCPUリソースを追加または削除すると、アプリケーションのパフォーマンスとスループットが向上または低下する可能性があります

Exadataのエラスティック操作による影響の計画

前述のエラスティック変更の中にはかなりの時間を要するものがあり、それらはアプリケーションの使用可能リソースに影響するため、計画が必要です。

スケール・ダウンおよび削除による変更では、使用可能なリソースが減少します。リソースが減少してデータベースおよびアプリケーションの安定性に必要な量を下回ることがないように、また、アプリケーション・パフォーマンス目標を満たすように注意を払う必要があります。次の表では、これらの変更について、推定所要時間と計画の推奨事項を示します。

VMクラスタの変更 データベースへの影響 アプリケーションへの影響
VMクラスタ・メモリーのスケール・アップまたはスケール・ダウン

サービスを排出する時間およびOracle RACローリング再起動

通常はノード当たり15-30分ですが、アプリケーションの排出によって異なる場合があります

アプリケーションの排出についての理解

メモリーをスケール・ダウンする前に「アプリケーションの継続的な可用性の構成」を参照し、データベースのSGAを引き続きhugepagesに格納できることと、アプリケーション・パフォーマンスが引き続き許容範囲にあることを確認します。

予測可能なアプリケーション・パフォーマンスおよび安定性を確保するには:

  • 監視して、重要な高ワークロード・パターンでメモリー・リソースが必要になる前にスケール・アップします
  • 新しいメモリー・サイズにデータベースのSGAおよびPGAメモリーすべてが収まり、システムのhugepagesにすべてのSGAが収まる場合を除き、メモリーのスケール・ダウンは避けてください。
VMクラスタCPUのスケール・アップまたはスケール・ダウン

オンライン操作は、通常は、VMクラスタごとに5分未満です

非常に小さい値から非常に大きい値へのスケール・アップ(10以上のOCPUの増加)には、10分かかる場合があります。

予測可能なアプリケーション・パフォーマンスおよび安定性を確保するには:

  • 監視し、重要な高ワークロード・パターンでCPUリソースが必要になる前や、常に許容時間内にOCPUしきい値に到達しているときはスケール・アップします。
  • 負荷平均が少なくとも30分間しきい値を下回る場合にのみスケール・ダウンするか、固定ワークロード・スケジュールに基づいてスケール・ダウンします(たとえば、営業時間は60 OCPU、営業時間外は10 OCPU、バッチは100 OCPU)
  • 2時間以内にスケールダウン・リクエストを複数発行しないでください
データベース使用状況に応じたASMストレージのスケール・アップまたはスケール・ダウン(サイズ変更)

通常は数分から数時間

時間は、使用されているデータベース・ストレージ容量およびデータベース・アクティビティによって異なります。使用されているデータベース・ストレージの割合が高くなるほど、サイズ変更操作(ASMリバランスを含む)にかかる時間が長くなります。

Oracle ASMリバランスは自動的に開始されます。ストレージの冗長性は保持されます。非侵入型のASM指数制限を使用する固有のベスト・プラクティスにより、アプリケーション・ワークロードへの影響は最小限になります。

サイズ変更およびリバランス操作を最適化できるように、非ピーク・ウィンドウを選択します。

時間は大きく異なる可能性があるため、操作の完了までに数時間かかると想定して計画します。VMクラスタ当たりの既存のサイズ変更またはリバランス操作に必要な時間を推定するには、GV$ASM_OPERATIONを問い合せます。たとえば、30分ごとに次の問合せを実行して、どれくらいの作業が必要になる可能性があるか(EST_WORK)と、どれくらいの時間がさらに必要になる可能性があるか(EST_MINUTES)を評価できます。

select operation, pass, state, sofar, est_work, est_minutes from gv$asm_operation where operation='REBAL';

リバランスが進行するにつれて、推定された統計はより正確になる傾向がありますが、同時ワークロードによって異なる場合があることに注意してください。
VMのローカル/u02ファイル・システム・サイズのスケール・アップ(Exadata X9M以降) オンライン操作は、通常は、VMクラスタごとに5分未満です

VMのローカル・ファイル・システム領域は、ローカル・データベース・ホスト・ディスク上で割り当てられます。それは、そのデータベース・ホスト上でプロビジョニングされているVMクラスタすべてのVMゲストすべてによって共有されます。

ローカル/u02ファイル・システムのスケール・ダウンはOracle RACローリング方式で実行する必要があり、それによってアプリケーションの中断が起こる可能性があるため、1つのVMクラスタ上でローカル/u02ファイル・システムの領域を不必要にスケール・アップして、同じExadataインフラストラクチャ上の他のVMクラスタ上でスケール・アップするための領域がなくなるようなことはしないでください。
VMのローカル/u02ファイル・システム・サイズのスケール・ダウン

サービスを排出する時間およびOracle RACローリング再起動

通常はノードごとに15-30分ですが、アプリケーションの排出設定によって異なる場合があります。

 計画するには、「アプリケーションの継続的可用性の構成」でアプリケーションの排出について学習してください
Exadataストレージ・セルの追加

管理者が分散方法を選択するための、より多くの使用可能領域を作成するオンライン操作。

VMクラスタの数、データベース・ストレージの使用状況およびストレージ・アクティビティに応じて、通常は、操作当たり3-72時間。非常にアクティブなデータベースであり負荷が大きいストレージ・アクティビティの場合は、最長で72時間かかることがあります。

ストレージ・セル追加操作の一部として、この操作には次の2つの部分があります。

  1. ストレージ追加操作の一部として、ストレージがExadataシステムに追加されます。
  2. 管理者は、別の操作として、どのVMクラスタのASMディスク・グループを拡張するかを決める必要があります。

この操作の完了には数日かかる場合があるため、ストレージ容量の使用率が1か月以内に80%に達したときにストレージを追加することを計画します。

Oracle ASMリバランスは自動的に開始されます。ストレージの冗長性は保持されます。非侵入型のASM指数制限を使用する固有のベスト・プラクティスにより、アプリケーション・ワークロードへの影響は最小限になります。

この所要時間は大きく異なる可能性があるため、この操作の完了までに数日かかり、その後にストレージが使用可能になると想定して計画します。

VMクラスタごとの、既存のサイズ変更またはリバランス操作にかかる時間を推定するには、GV$ASM_OPERATIONを問い合せます。たとえば、30分ごとに次の問合せを実行して、どれくらいの作業が必要になる可能性があるか(EST_WORK)と、どれくらいの時間がさらに必要になる可能性があるか(EST_MINUTES)を評価できます。

Select operation, pass, state, sofar, est_work, est_minutes from gv$asm_operation where operation='REBAL';

リバランスが進行するにつれて、推定された統計はより正確になる傾向がありますが、同時ワークロードによって異なる場合があることに注意してください。
Exadataデータベース・サーバーの追加

VMクラスタを拡張するオンライン操作

データベース・コンピュートをExadataインフラストラクチャに追加してからVMクラスタを拡張する1ステップ・プロセス。

Exadataデータベース・サーバーごとに約1から6時間

データベース・リソースの使用率が1か月以内に80%に達したときにデータベース・コンピュートを追加することを計画します。この操作には数時間から1日かかることに注意して計画してください。

データベース・コンピュート追加操作をより短時間で完了できるように、ピーク以外のウィンドウを選択します。

Oracle Clusterwareによって登録され、Oracle Cloudコンソールに表示される各Oracle RACデータベースが拡張されます。データベースは、Oracle Cloudコンソール外で、またはdbaascliを使用せずに構成されていた場合は拡張されません。
仮想マシン(VM)クラスタでのデータベース・ノードの追加または削除

VMクラスタでデータベース・ノードを追加するときは、データベースの停止時間はゼロです。通常は、VMクラスタ内のデータベースの数に応じて、3-6時間かかります。

VMクラスタでデータベース・ノードを削除するときは、データベースの停止時間はゼロです。通常は、VMクラスタ内のデータベースの数に応じて、1-2時間かかります。

追加操作や削除操作は即時ではなく、操作が完了するまでに数時間かかる場合があることを理解しておいてください。

削除操作によって、データベース・コンピューティング、OCPUおよびメモリー・リソースが減少するため、アプリケーション・パフォーマンスに影響がある可能性があります。

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

Oracle Database@Azure上のお薦めのMAA Goldアーキテクチャは、次の内容で構成されています。

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

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


図31-1の説明が続きます
「図31-1 同じAzureリージョン内のMAA Gold DRアーキテクチャ」の説明

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


図31-2の説明が続きます
「図31-2 2つのAzureリージョンにわたるMAA Gold DRアーキテクチャ」の説明

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

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

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

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

データベース・ネットワーク層

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

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

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

AZ間ネットワーク・ピアリングの場合、ピアリングはOCIネットワークまたはAzureネットワークを使用して実行できます。お薦めのオプションは、複数のOCI VCNをピアリングし、REDOトラフィックにそのOCIネットワークを使用することです。OCI VCNのピアリングでは、シングルプロセス・ネットワーク・スループットが高まり(最大14 Gビット/秒であることを確認済)、データベース・クラスタ間の待機時間が短くなります。また、このトラフィックにはチャージバックはありません。Azureネットワークを使用したピアリングでは、3 Gビット/秒であることを確認済のシングル・プロセス・スループット(300 MB/秒を超える高いREDO生成率のデータベース・インスタンスに関連)が提供され、待機時間が約20%長くなり、VNet間トラフィックにはチャージバックがあります。

リージョン間ネットワーク・ピアリングの場合、OCIは、エンタープライズ・データベースに必要になる潜在的な高REDOスループットをサポートするための、唯一実行可能な選択肢です。OCI VCNピアリングでは、Oracle RACインスタンスごとのシングルプロセス・ネットワーク・スループットが高まります(最大1.5 Gビット/秒または190 MB/秒であることを確認済)。データベース・クラスタ間の待機時間は、物理的な場所とネットワーク・トポロジによって異なります。最初の10TB/月では、リージョン間のトラフィックに対するチャージバックはありません。なお、シングル・プロセス・スループット、最大ネットワーク・スループットおよびネットワーク待機時間は、データ・センターの場所によって異なる場合があります。

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

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

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

Data GuardのREDOトラフィックのためにAzure VNetをピアリングするには、https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overviewを参照してください。

ネットワークがAzureを介してピアリングされている場合は待機時間が約20%長くなり、シングルプロセス・ネットワーク・スループットが約3 Gビット/秒(最大375 MB/秒)に制限されることに注意してください。これは、Data GuardのREDO転送が、データベース・インスタンスごとのシングル・プロセスであるためです。このため、1つのインスタンスでREDOがより高い率で生成されると、転送ラグが生じる可能性があります。ネットワークがAzureを介してピアリングされている場合は、各VNetで、イングレスおよびエグレス・ネットワーク・トラフィックの追加コストが発生します。

Data Guardの有効化

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

ネットワークのスループットおよび待機時間の評価

ネットワーク間のスループットと待機時間を比較する場合は、次の方法をお薦めします。

Data Guardのスループット

エンドポイント間のスループットの測定には、iperfを使用することをお薦めします。

例:

サーバー側(rootとして):

# iperf -s

クライアント側(rootとして):

シングル・プロセス: iperf -c <ip address of VIP>

  • これにより、1つのOracle RACインスタンスからスタンバイOracle RACインスタンスへの最大REDOスループットが測定されます。
  • シングルプロセス・ネットワーク・スループットはOCI VCNピアリングでは14 Gビット/秒であると推定されている
  • シングルプロセス・ネットワーク・スループットはAzure VNetピアリングでは3 Gビット/秒であると推定されている

パラレル・プロセス: iperf -c <ip address of VIP> -P 32

  • これにより、Data Guardのインスタンス化および大きなREDOギャップの解決に使用できる最大ネットワーク帯域幅が測定されます。

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

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

バックアップ

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

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

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

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

待機時間

VMエンドポイント間のTCP待機時間をテストするための最適なツールは、sockperfです。待機時間は、バックアップについてはテストされません。sockperfは、デフォルトではインストールされていないため、RPMまたはYUMからインストールする必要があります。

サーバー: sockperf sr -i <IP of VIP> --tcp

クライアント: sockperf pp -i <IP of VIP> --tcp --full-rtt

別々のAZにあるクラスタ間の出力例(クライアント):

# sockperf pp -i <IP> --tcp --full-rtt
  sockperf: Summary: Round trip is 1067.225 usec
  sockperf: Total 516 observations; each percentile contains 5.16 observations
  sockperf: ---> <MAX> observation = 1194.612
  sockperf: ---> percentile 99.999 = 1194.612
  sockperf: ---> percentile 99.990 = 1194.612
  sockperf: ---> percentile 99.900 = 1137.864
  sockperf: ---> percentile 99.000 = 1112.276
  sockperf: ---> percentile 90.000 = 1082.640
  sockperf: ---> percentile 75.000 = 1070.377
  sockperf: ---> percentile 50.000 = 1064.075
  sockperf: ---> percentile 25.000 = 1059.195
  sockperf: ---> <MIN> observation = 1047.373

ノート:

結果は、サンプリングされリージョンおよびAZによって異なります。

ICMPパケットは非常に低い優先度に設定されており、TCPパケットの待機時間を正確に表さないため、pingコマンドをAzureで使用しないでください。

トレース・ルート

適切なルートが取られていることを確認するために、エンドポイント間でtracerouteを実行します。

観察結果

  • Data GuardでOCI VCNピアリングが使用されている場合は、ExaDB-Dクラスタ間に1つの'ホップ'
  • Data GuardでAzure VNetピアリングが使用されている場合は、ExaDB-Dクラスタ間に6つの'ホップ'
  • 同じAZ内のアプリケーションVMとExaDB-Dクラスタの間に4つの'ホップ'

アプリケーションの継続的な可用性の実現

Oracle Database@Azure上のOracle Exadata Database Service on Dedicated Infrastructureの一部として、すべてのソフトウェア更新(非ローリング・データベース・アップグレードまたは非ローリング・パッチを除く)をオンラインで、あるいはOracle RACローリング更新を使用して行うことで、継続的なデータベース稼働時間を実現できます。

さらに、ストレージ、ExadataネットワークまたはExadataデータベース・サーバーのローカルな障害が自動的に管理され、データベース稼働時間が維持されます。

Oracle RACのスイッチオーバーまたはフェイルオーバー・イベント中に継続的なアプリケーション稼働時間を実現するには、次に示すアプリケーション構成のベスト・プラクティスに従ってください。

  • Oracle Clusterware管理データベース・サービスを使用してアプリケーションを接続します。Oracle Data Guard環境では、ロールベースのサービスを使用します。
  • タイムアウト、再試行および遅延が組み込まれた、推奨されている接続文字列を使用して、停止中に着信接続要求でエラーが表示されないようにします。
  • 高速アプリケーション通知を使用して接続を構成します。
  • サービスを排出および再配置します。下の表で示す、排出をサポートする推奨されているベスト・プラクティスを使用してください(借用時または作業のバッチの開始時に接続をテストし、使用と使用の間に接続をプールに返却するなど)。
  • アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを利用して、障害後に、実行中のコミットされていないトランザクションを透過的にリプレイします。

詳細は、「アプリケーションの継続的な可用性の構成」を参照してください。アプリケーション・フェイルオーバーの準備状況の検証(My Oracle SupportのドキュメントID 2758734.1)に従って、アプリケーションの準備状況をテストしてください。

Oracle Exadata Database Serviceの計画メンテナンス・イベントに応じて、Oracleでは、Oracle RACインスタンスを停止する前にデータベース・サービスを自動的に排出および再配置しようと試みます。OLTPアプリケーションについては、サービスの排出および再配置が通常は非常に適切に機能し、アプリケーションの停止時間がなくなります。

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

データベースOJVMを使用するアプリケーションのデータベースを四半期ごとにローリング更新する際には、特別な考慮事項が必要になります。詳細は、My Oracle SupportのドキュメントID 2217053.1を参照してください。

次の表に、Oracle RACインスタンスのローリング再起動を実行する計画メンテナンス・イベント、およびアプリケーションに影響を与える可能性がある、関連サービスの排出タイムアウト変数を示します。

Exadata Cloudのソフトウェア更新またはエラスティック操作 排出タイムアウト変数
Oracle DBHOMEパッチ適用およびデータベース移動

クラウド・ソフトウェアの自動化により、データベース・サービス構成(srvctlなど)によって定義されたDRAIN_TIMEOUT設定を保持したままデータベース・サービスが停止/再配置されます。1

サービスで定義されているDRAIN_TIMEOUTは、コマンドライン操作dbaascli dbHome patchまたはdbaascli database moveでオプションdrainTimeoutInSecondsを使用してオーバーライドできます。

サポートされているOracle Cloud内部の最大排出時間は2時間です。
Oracle Grid Infrastructure (GI)パッチ適用およびアップグレード

クラウド・ソフトウェアの自動化により、データベース・サービス構成(srvctlなど)によって定義されたDRAIN_TIMEOUT設定を保持したままデータベース・サービスが停止/再配置されます。1

サービスで定義されているDRAIN_TIMEOUTは、コマンドライン操作dbaascli grid patchまたはdbaascli grid upgradeでオプションdrainTimeoutInSecondsを使用してオーバーライドできます。

サポートされているOracle Cloud内部の最大排出時間は2時間です。
仮想マシン・オペレーティング・システムのソフトウェア更新(Exadataデータベース・ゲスト)

Exadataのpatchmgr/dbnodeupdateソフトウェア・プログラムによって、排出オーケストレーション(rhphelper)がコールされます。

排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、My Oracle SupportのドキュメントID 2385790.1を参照)。

  • DRAIN_TIMEOUT - サービスにDRAIN_TIMEOUTが定義されていない場合は、デフォルト値である180秒が使用されます。
  • MAX_DRAIN_TIMEOUT - データベース・サービス構成によって定義されている、より大きいDRAIN_TIMEOUT値をオーバーライドします。デフォルト値は300秒です。最大値はありません。

データベース・サービス構成によって定義されているDRAIN_TIMEOUT設定は、サービスの停止/再配置の間に適用されます。

Exadata X9M以降のシステム

VMのローカル・ファイル・システム・サイズのスケール・ダウン

Exadata X9M以降のシステムによって、排出オーケストレーション(rhphelper)がコールされます。

排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、My Oracle SupportのドキュメントID 2385790.1を参照)。

  • DRAIN_TIMEOUT - サービスにDRAIN_TIMEOUTが定義されていない場合は、デフォルト値である180秒が使用されます。
  • MAX_DRAIN_TIMEOUT - データベース・サービス構成によって定義されている、より大きいDRAIN_TIMEOUT値をオーバーライドします。デフォルト値は300秒です。

データベース・サービス構成によって定義されているDRAIN_TIMEOUT設定は、サービスの停止/再配置の間に適用されます。

この操作でサポートされているOracle Cloud内部の最大排出時間は300秒です。

Exadata X9M以降のシステム

VMクラスタ・メモリーのスケール・アップまたはスケール・ダウン

Exadata X9M以降のシステムによって、排出オーケストレーション(rhphelper)がコールされます。

排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、My Oracle SupportのドキュメントID 2385790.1を参照)。

  • DRAIN_TIMEOUT - サービスにDRAIN_TIMEOUTが定義されていない場合は、デフォルト値である180秒が使用されます。
  • MAX_DRAIN_TIMEOUT - データベース・サービス構成によって定義されている、より大きいDRAIN_TIMEOUT値をオーバーライドします。デフォルト値は300秒です。

データベース・サービス構成によって定義されているDRAIN_TIMEOUT設定は、サービスの停止/再配置の間に適用されます。

この操作でサポートされている、Oracle Cloud内部の最大排出時間は900秒です。
Oracle Exadata Cloud Infrastructure (ExaDB)のソフトウェア更新

ExaDB-Dデータベース・ホストによって、排出オーケストレーション(rhphelper)がコールされます。

排出オーケストレーションには、次の排出タイムアウト設定があります(詳細は、My Oracle SupportのドキュメントID 2385790.1を参照)。

  • DRAIN_TIMEOUT - サービスにDRAIN_TIMEOUTが定義されていない場合は、デフォルト値である180秒が使用されます。
  • MAX_DRAIN_TIMEOUT - データベース・サービス構成によって定義されている、より大きいDRAIN_TIMEOUT値をオーバーライドします。デフォルト値は300秒です。

データベース・サービス構成によって定義されているDRAIN_TIMEOUT設定は、サービスの停止/再配置の間に適用されます。

この操作でサポートされている、Oracle Cloudの内部の最大排出時間は500秒です。

拡張インフラストラクチャ・メンテナンス制御:

Oracle Cloudの内部最大値より長い排出時間を実現するには、拡張インフラストラクチャ・メンテナンス制御のカスタム・アクション機能を利用します。これにより、次のデータベース・サーバー更新の開始前にインフラストラクチャ・メンテナンスを一時停止し、データベース・サーバーで実行中のデータベース・サービスを直接停止/再配置してから、次のデータベース・サーバーに進むためにインフラストラクチャ・メンテナンスを再開できます。詳細は、Oracle Cloud InfrastructureドキュメントのOracle管理のインフラストラクチャ・メンテナンスの構成を参照してください。

1このサービス排出機能を実現するための最小ソフトウェア要件は、Oracle Databaseリリース12.2以降、および最新のクラウドDBaaSツール・ソフトウェアです

Oracle Exadata CloudでのOracle MAAリファレンス・アーキテクチャ

Oracle Database@Azure上のOracle Exadata Database Service on Dedicated Infrastructureでは、固有の高可用性、データ保護および障害時リカバリのサービス・レベル合意に関係なく、すべてのOracle MAAリファレンス・アーキテクチャがサポートされており、すべてのOracleデータベースについてサポートが提供されます。

Oracle Exadata CloudにおけるOracle MAAの詳細は、「Oracle CloudのMAAベスト・プラクティス」を参照してください。

複数の可用性ゾーンにわたるOracle@Azure障害時リカバリ用のネットワーキングの設定

Oracle MAAでは、ExaDB-D@Azure DR設定での複数の可用性ゾーンにわたるネットワーキングについて、次のベスト・プラクティスをお薦めしています。

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

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

図31-3 同じリージョン内のソリューションのDR機能


図31-3の説明が続きます
「図31-3 同じリージョン内のソリューションのDR機能」の説明

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

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

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

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

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

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

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

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

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

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

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

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

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

  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@Azure用のネットワーキングの設定

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

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

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


図31-4の説明が続きます
「図31-4 2つのAzureリージョンにわたるMAA Gold DRアーキテクチャ」の説明

複数のリージョンにわたるOracle@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 Database@Azure OCI子サイトに作成されると、それぞれが、それ固有のOCI仮想クラウド・ネットワーク(VCN)内に作成されます。Data Guardでは、複数のデータベースで相互に通信してREDOが送信されロール・トランジションが実行される必要があります。この通信を可能にするには、VCNをピアリングする必要があります。
  • OCIは、パフォーマンス(待機時間、スループット)とコスト削減(最初は10 TB/月が無料)のためのお薦めのネットワークです。

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

ノート:

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