マルチクラウド・ソリューションに関するMAA評価

Oracle Maximum Availability Architecture(MAA)では、MAA Silver、MAA GoldおよびMAA Platinumリファレンス・アーキテクチャをそのOracle Multicloudパートナとともに検証します。

  • MAA Silver - 検証済MAA Silverソリューションでは、最良の高可用性(HA)データベース・プラットフォームが網羅されています。これには、Oracleデータベースの作成、エラスティック操作、ソフトウェア更新、およびバックアップとリストアについての、構成とライフサイクルのベスト・プラクティスが含まれています。すべてのアプリケーションで、変更なしでこのソリューションを利用できます。

  • MAA Gold - 検証済MAA Goldソリューションでは、Oracle Active Data Guardとともに構成されているOracle Cloudスタンバイ・データベースで拡張されている場合に、包括的なデータ保護および障害時リカバリ(DR)が実現されます。MAA Goldは、ミッションクリティカルなエンタープライズ・データベースおよびアプリケーションで、アプリケーション変更の必要なく、ローカルまたは広範囲に想定外の停止が発生した場合の最大限の回復性を実現するための、最良かつ最も簡単なクラウド・ソリューションです。

  • MAA Platinum - Oracle GoldenGateまたはOCI GoldenGate Marketplace、およびMAAライフ・サイクル・ベスト・プラクティスで拡張されている場合、検証済MAA Platinumソリューションでは、どのような停止シナリオの場合も、使用可能な論理GoldenGateレプリカのいずれかにアプリケーションを誘導できるため、NeverDownオプションが実現されます。MAA Platinumは、論理的トランザクション競合を回避し論理的競合解決をまれなケースにするためのルーティング作業以外は、最小限のアプリケーション変更により実装できます。

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

Oracle MAAによるOracle Databaseマルチクラウド評価

Oracleのお客様の成功と一貫性を確保するために、Oracle MAAソリューション・チームは、マルチクラウド環境内の実際のOracle DatabaseでMAAリファレンス・アーキテクチャと主要なライフサイクル操作を評価しています。この目的は、カオス・エンジニアリングの検証方法を使用して保証を提供することです。

  • 何百もの様々な計画外停止(中間的な障害と複雑な障害)および計画メンテナンス・アクティビティで、想定されているRTOおよびRPOを達成している
  • ソフトウェア更新とエラスティック操作で観測された、パフォーマンスへの影響があるブラウンアウトが想定内である
  • 構成のベスト・プラクティスがデプロイメント時に実施されており、構成ヘルス・チェックが想定どおりに機能し続けている
  • 主要なライフサイクル・プラクティスが想定どおりに機能している

マルチクラウド環境におけるMAAソリューションの検証で最小要件を満たしていた場合は、Oracle MAAにより、MAAアーキテクチャ、RTOおよびRPOの観測結果、ネットワークとパフォーマンスに関する考慮事項が文書化されます。

ネットワーク評価

Oracle Databaseマルチクラウド・ソリューションのMAAネットワーク評価は、次の内容で構成されています:

ネットワークに関する考慮事項

OCIピアリング・ネットワークまたはマルチクラウド・ピアリング・ネットワークを使用したネットワーク帯域幅とネットワーク待機時間などの、ネットワークに関する考慮事項

  • アプリケーションからデータベースVMへ
  • 同じ可用性ドメイン(AD)または可用性ゾーン(AZ)内のデータベースVMからデータベースVMへ
  • ADまたはAZをまたいでデータベースVMからデータベースVMへ
  • リージョンをまたいでデータベースVMからデータベースVMへ
  • 可用性ドメインか可用性ゾーンをまたいで、またはリージョンをまたいでデータベースVMからデータベースVMへ

ネットワーク・テストの前提条件

レイテンシおよびスループットは、iperf3およびqperf (デフォルトではExadataにインストール)によって測定されます。

  • 各OCI VCNのイングレスおよびエグレス・セキュリティ・ルールで、ポート5201 (iperf3のデフォルト・ポート)が許可されていることを確認します。これは、これらのテストでqperfにも使用されます。セキュリティ・ルールの詳細は、「セキュリティ・リストの更新」を参照してください。

  • テスト対象となるデータベース・サーバーVMの仮想IPアドレス(VIP)を記録します。

    テスト対象の各データベース・サーバーVMで次を実行します:

    as grid (sudo su - grid from opc user):

$ srvctl config vip -n $(hostname -s)
VIP exists: network number 1, hosting node <hostname>
VIP Name: <VIP name>
VIP IPv4 Address: <VIP> ← record this IP address for each host involved in the tests
VIP IPv6 Address: 
VIP is enabled.
VIP is individually enabled on nodes: 
VIP is individually disabled on nodes: 

ネットワーク・テスト

  • 一貫性を確保するために、次のテストを複数回実行します。
  • 全体を通して一貫性を確保するために、テストを1日の異なる時間に実行することをお薦めします。
  • データベース・サーバーVMの場合、これらのテストは最低限、プライマリ・クラスタの1つのVMとスタンバイ・データベース・クラスタの1つのVMの間で実行する必要があります。一貫性を確保するために、すべてのデータベース・サーバーで追加のテストを実行できます。
  • iperf3およびqperfコマンドはすべて、root (sudo su - from opc user)として実行する必要があります。
  • iperf3テストでは、必要に応じて-f Mパラメータを使用してビットレート結果(MB/秒)を表示できます。

単一プロセスのスループット・テスト

  1. スタンバイ・データベース・サーバーVMで次を実行します:
    # iperf3 -s
  2. プライマリ・データベース・サーバーVMで、一貫性を確保するために次のテストを複数回実行します。
    # iperf3 -c <remote VIP>
  3. 各実行の最後に送信者の合計を記録します。

サンプル出力:

Connecting to host <remote VIP>, port 5201
[  5] local <local IP> port 49230 connected to <remote VIP> port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   474 MBytes  3.97 Gbits/sec  1656   2.70 MBytes       
[  5]   1.00-2.00   sec   235 MBytes  1.97 Gbits/sec    0   3.06 MBytes       
[  5]   2.00-3.00   sec   266 MBytes  2.23 Gbits/sec    0   3.44 MBytes       
[  5]   3.00-4.00   sec   264 MBytes  2.21 Gbits/sec   61   2.73 MBytes       
[  5]   4.00-5.00   sec   240 MBytes  2.01 Gbits/sec    0   3.09 MBytes       
[  5]   5.00-6.00   sec   268 MBytes  2.24 Gbits/sec    0   3.43 MBytes       
[  5]   6.00-7.00   sec   266 MBytes  2.23 Gbits/sec   76   1.87 MBytes       
[  5]   7.00-8.00   sec   169 MBytes  1.42 Gbits/sec    0   2.25 MBytes       
[  5]   8.00-9.00   sec   199 MBytes  1.67 Gbits/sec    0   2.61 MBytes       
[  5]   9.00-10.00  sec   229 MBytes  1.92 Gbits/sec    0   2.99 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.55 GBytes  2.19 Gbits/sec  1793             sender  <---- USE THIS VALUE
[  5]   0.00-10.01  sec  2.54 GBytes  2.18 Gbits/sec                  receiver

マルチプロセスのスループット・テスト

複数のプロセスの場合、異なる並列度4、10および16を評価します。

  1. スタンバイ・データベース・サーバーVMで次を実行します:
    # iperf3 -s
  2. プライマリ・データベース・サーバーVMで、一貫性を確保するために次のテストをそれぞれ複数回実行します。
    # iperf3 -c <remote VIP> -P 4

# iperf3 -c <remote VIP> -P 10

# iperf3 -c <remote VIP> -P 16
  3. 各実行の最後に送信者の合計を記録します。たとえば:
    <...>

[SUM]   0.00-10.00  sec  10.1 GBytes  8.71 Gbits/sec  2159             sender
  4. スループットを確保するために、これらのテストを両方向(プライマリVM上のサーバー)で繰り返します。

ノート:

高い並列度(たとえば、16超え)では、iperf3を使用したスループットの典型的な測定値は示されません。テストで高い並列度を使用することはお薦めしません。

レイテンシ・テスト

  1. スタンバイ・データベース・サーバーVMで次を実行します:
    # qperf -lp 5201
  2. プライマリ・データベース・サーバーVMで、一貫性を確保するために次のテストを複数回実行します。
    # qperf 10.255.0.118 -lp 5201 tcp_lat

ノート:

qperfは、レイテンシを一方向のみで測定します。このテストを両方向で実行し、ラウンドトリップ時間(RTT)の値を合計します。

アプリケーションおよびデータベースのワークロードおよびアーキテクチャに対するネットワーク結果の影響

  • アプリケーション・パフォーマンスとネットワーク・ラウンドトリップ待機時間: アプリケーションがOLTPであるか、またはアプリケーションVMとデータベースVMの間の待機時間が短いことに依存している場合は、アプリケーションVMとデータベースVMを同じ場所に配置し、必ずRTT待機時間がレスポンス時間の要件を満たすようにします。

  • ローカル・スタンバイ・データベースとネットワーク・ラウンドトリップ待機時間: 同じリージョン内のプライマリとスタンバイの間の、データ損失ゼロのSYNC転送構成を検討している場合は、3ミリ秒を超えるラウンドトリップ(RTT)ネットワーク待機時間(1ミリ秒未満が望ましい)だと、アプリケーションのレスポンス時間およびスループットに影響する可能性があります。

    SYNC転送を使用するほとんどのスタンバイ・データベースでは、RTTネットワーク待機時間は1ミリ秒未満です。グローバル分散データベース(シャード・データベース)は、データベース・シャード間のRTT待機時間が短いことによるメリットもあります。

  • スタンバイのピーク時データベース変更率をサポートするための十分な単一プロセス・ネットワーク・スループット: 拡大に対応するために、単一プロセスiperfスループット・テストで、各データベース・インスタンスのピークREDO率の最大スループットを上回っている必要があります(できれば20%以上)。

    このスループットに満たない場合は、スタンバイが、構成後、ピーク時間の間にプライマリ・データベースに遅れずについていくことができない場合があります。Oracle Golden GateおよびGlobally Distributed Databaseの構成の場合は、単一プロセスのスループットも重要です。

    単一プロセスのスループットは、2.4 GB/秒(300 MB/秒)以上である必要があります。そうでない場合は、マルチベンダー・パートナにサービス・リクエストを記録します。OCIピアリングでは、スループットは前述の最小値よりはるかに高くなることが期待されます。

  • 大量のデータ転送のための十分なマルチプロセス・ネットワーク・スループット: パラレルiperfテストでは、テストされたプロセス数でデータベースをインスタンス化できる、おおよその速度が示されます。

    たとえば、50 TBのデータベースの場合、並列度8でのこのテストで1GB/秒を達成すると、8つのプロセスがあるデータベースはインスタンス化に14時間以上かかることになります。デフォルトのインスタンス化では、4つのチャネルが使用されます。Oracle Supportでサービス・リクエストを1つオープンして、インスタンス化の並列度を高めることができます。

    複数プロセスのスループットは、8 GB/秒(1000 MB/秒)以上である必要があります。そうでない場合は、マルチベンダー・パートナにサービス・リクエストを記録します。OCIピアリングでは、スループットは前述の最小値よりはるかに高くなることが期待されます。レイテンシが高いほど、データ伝送の遅延が長くなり、ネットワーク速度が高くてもスループットが低下する可能性があります。スループットが低下するその他の要因には、パケットの損失と輻輳があります。

MAA Silverのアーキテクチャと評価

マルチクラウド・ソリューションにおけるOracle Database上のMAA Silverは、次のアーキテクチャからなります:

  • マルチクラウド・パートナのデータ・センターに存在するOracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)クラスタ

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

  • バックアップとリストアのための、キー管理サービス、自律型リカバリ・サービス(マルチクラウド・データ・センター内またはOCI内)およびオブジェクト・ストレージ・サービス(OCI内)

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

MAA Silverの評価は次の内容で構成されています:

  • アプリケーションVMからデータベースVMへ、その後、データベースVMからバックアップ・ターゲット・ソリューションへのネットワーク・テスト

  • Oracle Cloud Infrastructure(OCI)オブジェクト・ストレージ・サービス(OCI内)、または自律型リカバリ・サービス(マルチクラウド・データ・センター内またはOCI内)を使用した、バックアップとリストアのパフォーマンス、スループットおよび主要ユースケースのテスト

  • 何百もの様々な計画外(ブラックアウトとブラウンアウト)停止をシミュレートするためのアプリケーション・ワークロードおよびMAAフレームワークの設定

  • ローカル障害についてRTOとRPOが満たされていることの確認

  • システムおよびデータベースのエラスティック変更またはソフトウェア更新の場合に停止時間ゼロであるか想定内の短いアプリケーション・ブラウンアウトであることの確認

  • exachkまたは構成ヘルス・チェックが想定どおりに機能しており、デプロイされたシステムがMAAに準拠していることの確認

MAA Goldのアーキテクチャと評価

マルチクラウド・ソリューションにおけるOracle Database上のMAA Goldは、次のアーキテクチャからなります:

  • Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) VMクラスタ(プライマリ・データベースとスタンバイ・データベース)が、同一または別々の可用性ドメイン(AD)か可用性ゾーン(AZ)、あるいは別々のマルチクラウド・リージョンに存在する。

    なお、プライマリ・データベースとスタンバイ・データベース、およびそれらのデータはすべて、Oracleのマルチクラウド・パートナのデータ・センターに存在します。プライマリ・データベースとスタンバイ・データベースが同じADまたはAZにある場合、このMAA Goldアーキテクチャでは引き続き、データベースとクラスタの障害に関して、本来備わっているHAのメリットに加え、DRフェイルオーバーのオプションが提供されます。ただし、この構成では、ADまたはAZサイト全体の障害(地域の停電など)に対するDR保護が不足しています。このMAAアーキテクチャでは、スタンバイ・データベースが別のリージョンに存在する場合のみ、リージョンの障害保護が提供されます。

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

  • バックアップとリストアのための、キー管理サービス、自律型リカバリ・サービス(マルチクラウド・データ・センター内またはOCI内)およびオブジェクト・ストレージ・サービス(OCI内)

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

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

  • OCIピアリング・ネットワークまたはマルチクラウド・ピアリング・ネットワークを使用したプライマリ・データベース・クラスタとスタンバイ・データベース・クラスタの間のネットワーク・テストによる、ラウンドトリップ待機時間と帯域幅の評価

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

  • Data GuardによるOracleデータベースのローリング・アップグレード

Oracle Maximum Availability Architectureの利点

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

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

Oracle Cloud自動化によって作成されたすべてのOracle Cloudデータベースでは、マルチクラウド環境内のOracle Database用に最適化された、Oracle Maximum Availability Architectureのデフォルト設定が使用されます。カスタム・スクリプトを使用してクラウド・データベースを作成することはお薦めしません。Oracleデータベースをマルチクラウド・ソリューション内のOracle Databaseに移行するには、Oracle Zero Downtime Migration (ZDM)を使用します。ゼロ・ダウンタイム移行の概要(oracle.com)を参照してください。

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

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

バックアップ・コピーにより、Azure、Google CloudまたはOCIにある自律型リカバリ・サービス、またはOCIにあるオブジェクト・ストレージ・サービスへの自動バックアップを構成するときにさらに保護が提供されます。Oracle Recovery Manager (RMAN)では、クラウド・データベースのバックアップに物理的な破損があるかどうかが検証されます。

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

自律型リカバリ・サービスを使用すると、毎週の完全バックアップが不要になり、バックアップ期間が短縮され、その独自の永久増分バックアップのメリットを享受できます。リアルタイム・データ保護が有効になっている場合は、バックアップからリストアするときに、データ損失がほぼゼロになる可能性があります。バックアップはプライマリ・データベースまたはスタンバイ・データベースで実行でき、様々な保存オプションがあります。

Oracle Exadata Database Machine固有の利点

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

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

詳細は、「Oracle Exadata Cloud SystemsにおけるOracle Maximum Availability Architecture」を参照してください

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

次の表に、様々な計画外停止イベントと、それに関連する、考えられるデータベース停止時間、アプリケーション・レベルのリカバリ時間目標(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のマルチクラウド・ソリューション(Oracle Database@Azure、Oracle Database@Google CloudおよびOracle Database@AWS)にあるOracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D)に対する、様々な計画メンテナンス・イベントの影響を示します。

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

次の表に、様々なソフトウェア更新と、関連するデータベースおよびアプリケーションに対するそれらの影響を示します。これは、Oracleのマルチクラウド・ソリューションにあるExaDB-Dに適用されます。

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

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およびメモリー・リソースが減少するため、アプリケーション・パフォーマンスに影響がある可能性があります。

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

マルチクラウド・ソリューション内のOracle Database上の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ツール・ソフトウェアです