専用Exadataインフラストラクチャ上のAutonomous AI Databaseでのコンピュート管理

専用Exadataインフラストラクチャ上のAutonomous AI Databaseは、Autonomous AI Databaseリソースの構成中に2つのコンピュート・モデルを提供します。これは次のとおりです:

ECPU: ECPUは、コンピュート・リソースの抽象化された尺度です。ECPUは、コンピュートおよびストレージ・サーバーのプールから柔軟なに割り当てられたコアの数に基づきます。Autonomous AI Databaseをプロビジョニングするには、少なくとも2つのECPUが必要です。

新しいデータベースのプロビジョニング、既存のデータベースのクローニングおよび既存のデータベースのCPUリソースのスケール・アップまたはスケール・ダウを行う場合、CPU数はデフォルトで2 ECPU (1単位)になります。たとえば、2を超える次の使用可能なECPU数は3です。

ECPUベースのコンテナ・データベースに開発者向けAutonomous AI Databaseインスタンスを作成できます。これらは、開発者が新しいアプリケーションの構築とテストに使用できる無料のAutonomous AI Databaseです。詳細は、開発者向けAutonomous AI Databaseを参照してください。
OCPU: OCPUは、コンピュート・リソースの物理的な尺度です。OCPUは、ハイパースレッドが有効なプロセッサの物理コアに基づきます。

ノート:
OCPUはレガシー請求メトリックであり、専用Exadataインフラストラクチャ上のAutonomous AI Databaseで廃止されました。Oracleでは、すべての新規および既存のAutonomous AI DatabaseデプロイメントにECPUを使用することをお薦めします。詳細は、Oracle Supportドキュメント2998755.1を参照してください。

新しいデータベースのプロビジョニング、既存のデータベースのクローニングおよび既存のデータベースのCPUリソースのスケール・アップまたはスケール・ダウンの場合:
- CPU数のデフォルトは1 OCPUで、単位は1です。たとえば、次に使用可能な1を超えるOCPUの数は2です。
- 全体OCPUを必要としないデータベースの場合、0.1から0.9までのOCPUを0.1 OCPU単位で割り当てることができます。これにより、CPUをオーバープロビジョニングし、各インフラストラクチャ・インスタンスでより多くのデータベースを実行できます。詳細は、CPUオーバープロビジョニングを参照してください。

Autonomous Exadata VMクラスタのコンピュート・タイプは、そのすべてのAutonomous Container DatabaseおよびAutonomous AI Databaseインスタンスに適用されます。

関連項目

専用Exadataインフラストラクチャ上のAutonomous AI Databaseの請求

コンピュート管理

Autonomous AI Databaseインスタンスは、Autonomous Exadata VMクラスタ(AVMC)およびその子Autonomous Container Database (ACD)のいずれかにデプロイされます。Exadataインフラストラクチャでは、複数のAVMCを実行できます。AVMCリソースのプロビジョニング中に割り当てるCPUは、そのAutonomous AI Databaseで使用可能な合計CPUになります。複数のAVMCを作成する場合、各AVMCは合計CPUに対して独自の値を設定できます

複数のVM Autonomous Exadata VMクラスタは、複数のVMAutonomous AI Database機能の起動前に作成されたExadataインフラストラクチャ(EI)リソースのOracle Public Cloudデプロイメントでは使用できません。複数AVMC機能の起動後に作成されたX8M生成以上のExadataインフラストラクチャ・リソースの場合、各AVMCは、選択したExadataシステム・シェイプのサーバーごとに1つのクラスタ・ノードを使用して作成されます。異なるユーザー・グループ間でこれらの合計CPUを制約する方法の詳細は、コンパートメント割当てがCPU管理に与える影響を参照してください。

ノート:

特定のExadataインフラストラクチャで作成できるAVMCおよびACDリソースの最大数は、ハードウェアの生成によって異なります。各世代の制約の詳細は、リソース制限およびインフラストラクチャ・シェイプの特性を参照してください。

AVMCまたはACCレベルで、データベースの作成に使用可能なCPUの合計数を使用可能なCPUと呼びますAVMCリソース・レベルでは、最初のACCを作成するまで、使用可能なCPUはCPU合計と等しくなります。ACDを作成すると、ノード当たり8 ECPUまたは2 OCPUがAVMCで使用可能なCPUから新しいACCに割り当てられます。したがって、AVMCリソース・レベルで使用可能なCPUは、それに応じて減少します。そのACCで最初のAutonomous AI Databaseを作成すると、新しいデータベースは、最初に割り当てられたCPU (ノード当たり8 ECPUまたは2 OCPU)を使用します新しいデータベースに必要なECPUが2を超える場合、親AVMCの使用可能なCPUから割り当てられるため、親AVMCレベルで使用可能なCPUは少なくなる。ACDをさらに作成し、各ACC内でAutonomous AI Databaseをプロビジョニングすると、それに従って使用可能なCPU値が変わります。

Autonomous Exadata VMクラスタ・レベルで使用可能なCPUは、そのすべてのAutonomous Container Databaseに適用されます。自動スケーリング時のCPU割当てで説明されているように、自動スケーリング機能を使用している場合、コンテナ・データベースで使用可能なこのCPU数は重要です。

同様に、Autonomous AI DatabaseのCPUを手動でスケール・アップすると、CPUは親のAVMCレベルで使用可能なCPUから消費され、それに応じて値が変更されます。

Autonomous AI Databaseを作成すると、デフォルトでは、Oracleにより追加のCPUが予約され、ノード障害が発生してもデータベースが50%以上の容量で実行されるようになります。ACDのプロビジョニング中に、ノード間で予約されているCPUの割合を0%または25%に変更できます。手順については、Autonomous Container Databaseの作成のノード・フェイルオーバーの予約を参照してください。これらの追加CPUは、請求に含まれません。

Autonomous AI Databaseが実行されている場合、初期作成時に指定されたか、手動スケーリング操作によって後で指定されたかに関係なく、データベースに現在割り当てられているCPUの数に対して請求されます。また、データベースの自動スケーリングが有効になっている場合は、自動的にスケール・アップした結果としてデータベースで使用されている追加CPUの秒ごとに請求されます。請求の測定および計算方法の詳細は、CPU請求の詳細を参照してください。

Autonomous AI Databaseが停止している場合、請求されません。ただし、割り当てられたCPUの数は、デプロイメント全体の親AVMCレベルの使用可能なCPUに戻されません。

Autonomous AI Databaseが終了またはスケール・ダウンされると、そのCPUに割り当てられているCPUの数は、デプロイメント全体について、親AVMCレベルの使用可能なCPUにすぐに戻されるわけではありません。親コンテナ・データベースが再起動されるまでは、引き続き親コンテナ・データベースで使用可能なCPUの数に含まれます。これらのCPUは、再利用可能なCPUと呼ばれます。親AVMCレベルの再利用可能なCPUは、そのすべてのACDの再利用可能なCPUの合計です。ACDが再起動すると、すべての再利用できるCPUが親AVMCレベルの使用可能なCPUに戻されます。

Autonomous Container Database (ACD)の再起動は、クラスタ全体でローリング方式で実行されるオンライン操作であり、透過的アプリケーション・コンティニュイティを使用するためのベスト・プラクティスに従って構成されている場合、アプリケーションの停止時間は発生しません。

ヒント :

この記事で説明する様々なコンピュート(CPU)属性は、Autonomous Exadata VMクラスタ(AVMC)またはAutonomous Container Database (ACD)の「詳細」ページから追跡できます。ガイダンスは、リソース使用状況トラッキングを参照してください。

自動スケーリング時のCPU割当て

自動スケーリング機能により、自律型AIデータベースは、割り当てられたCPU数よりも最大3倍のCPUおよびIOリソースを使用できます。CPUオーバープロビジョニングの場合、CPU数の3倍で値が1未満になると、次の整数に丸められます。CPUオーバープロビジョニングは、OCPUでのみサポートされています。詳細は、CPU Overprovisioningを参照してください。

単一のAutonomous AI Databaseが、デプロイメント全体に対してプールで使用可能なすべてのCPUを消費するように自動スケール・アップできないようにするために、Oracle Autonomous AI Database on Dedicated Exadata Infrastructureでは、Autonomous Container Databaseを制限制御として使用します。

自動スケーリング対応のAutonomous AI DatabaseをACDにプロビジョニングする際に、そのACDの使用可能なCPUが新しいデータベースの3X CPU値より小さい場合、そのACDに追加のCPUが予約されます。これらのCPUは、予約済CPUと呼ばれます。予約済CPUでは、ACDレベルで使用可能なCPUが、そのACD内の最大の自動スケーリングが有効なデータベースの3x CPU値以上であることを確認します。これらの予約済CPUは、このACDでAutonomous AI Databaseを作成または手動でスケーリングするために使用できます。

Autonomous AI Databaseを自動的にスケール・アップすると、Oracle Autonomous AI Database on Dedicated Exadata Infrastructureは、親コンテナ・データベースでアイドルCPUを探します。アイドルCPUが使用可能な場合は、Autonomous AI Databaseがスケール・アップされます。それ以外の場合はスケール・アップされません。データベースには本質的にアイドル時間が多いため、自動スケーリングは、コストを制御しながらリソース使用率を最大化し、他のAutonomous Container Database内のデータベースから適切な分離を維持する方法です。

Autonomous AI Databaseの自動スケーリングに使用されるCPUが、負荷が軽く、割り当てられたCPUをすべて使用していない別のAutonomous AI Databaseから発生した場合、Oracle Autonomous AI Database on Dedicated Exadata Infrastructureは、他のデータベースで負荷が増大し、割り当てられたCPUが必要になった場合に、自動スケーリングされたデータベースを自動的にスケール・ダウンします。

4CPUのAutonomous AI Databaseが稼働し、すべて自動スケーリングが有効な4つのAutonomous Container Databaseをホストする例を考えてみます。このコンテナ・データベースで自動スケーリング目的に使用できるCPUの数は12です。負荷の増加により、これらのデータベースのうちの1つを4 CPUを超えて自動スケールする必要がある場合、Oracle Autonomous AI Database on Dedicated Exadata Infrastructureは、負荷が軽く、割り当てられたすべてのCPUを使用していないデータベースで他に1つ以上ある場合にのみ、自動スケール操作を実行します。4つの4 CPUデータベースが常に実行されているため、この例の請求コストは少なくとも16 CPUです。

対照的に、4つの2 CPU Autonomous AI DatabaseをホスティングするAutonomous Container Databaseの例を考えてみましょう。すべて自動スケーリングが有効になっており、1つは8 CPU Autonomous AI Databaseを停止しました。この場合も、コンテナ・データベースで自動スケーリング目的に使用できるCPUの数は16です。2 CPUを超える負荷のために実行中のデータベースの1つを自動スケーリングする必要がある場合、Oracle Autonomous AI Database on Dedicated Exadata Infrastructureは、停止した8 CPUデータベースに割り当てられたCPUを使用して操作を実行できます。この例では、4つの実行中データベースは、相互に割り当てられたCPUを使用しなくても、同時に合計8個の追加CPUを消費できます。4つの2 CPUデータベースのみが常に実行されているため、この例の請求コストは少なくとも8 CPUです。

Autonomous Data Guardサービス・インスタンス(ローカルまたはクロスリージョン)の場合、追加価格は、自動スケーリングが有効かどうかに関係なく、プライマリ・サービス・インスタンスを作成または明示的にスケーリングしたときに予約したECPUまたはOCPUの数になります。プライマリ・サービス・インスタンスでの自動スケーリング関連のECPUまたはOCPU消費は、Autonomous Data Guardスタンバイ・サービス・インスタンスでは発生しません。

CPU管理へのコンパートメント割当て制限の影響

通常、Autonomous AI Databaseを作成またはスケール・アップする場合、リクエストを満たすOracle Autonomous AI Database on Dedicated Exadata Infrastructureの機能が依存するのは、デプロイメント全体のCPUの単一プール内の未割当てCPUの可用性のみです。

ただし、Oracle Cloud Infrastructureのコンパートメント割当て機能を使用すると、コンパートメントごとに、各ワークロード・タイプ(Autonomous AI LakehouseまたはAutonomous AI Transaction Processing)のAutonomous AI Databaseを個別に作成、手動でスケーリングおよび自動スケーリングするために使用できるCPUの数をさらに制限できます。

簡単に言うと、コンパートメントの割当て制限の機能を使用するには、set、unsetおよびzeroポリシー・ステートメントを作成して、特定のコンパートメント内の特定のリソースの可用性を制限します。詳細および手順は、コンパートメントの割当て制限を参照してください。

VMクラスタ・ノードのCPU管理への影響

前述のCPU管理および割当て状態の説明では、AVMCリソースのプロビジョニング中にノード当たりのCPU数を選択することで、複数のAutonomous Exadata VMクラスタ(AVMC)リソースを作成できます。

この項では、Oracle Cloud InfrastructureがVMクラスタ・ノードにAutonomous AI Databaseを配置する方法、および自動スケーリングおよびパラレル処理におけるこのような配置の結果について詳細に説明します。

次の属性は、Autonomous AI Databaseを複数のノードに配置するタイミングと方法を決定します:

分割しきい値: Oracle Cloud Infrastructureが複数のノードにわたって自律型AIデータベースを開くCPU値。デフォルトの分割しきい値は、ECPUの場合は64、OCPUの場合は16ですが、CPUノード数がデフォルト値より小さい状態でVMクラスタが作成された場合、デフォルトはVMクラスタ・ノード数のサイズにオーバーライドされます。Autonomous Container Database (ACD)のプロビジョニング中に「しきい値の分割」属性を使用して分割値を明示的に設定することもできます。

分割値より小さいCPU値で作成されたAutonomous AI Databaseは、クラスタ内の1つのノードでオープンし、分割しきい値より大きいCPU値で作成されたものが複数のノードでオープンします。
- AVMCにデフォルト分割しきい値(64個のECPU)を持つACDを、2つのノードと40個のECPU/ノードとともに作成するとします。40が64より小さいため、CPU要件が40を超えるAutonomous AI Databaseは複数のノードに分割およびオープンされ、それらのノード間でDMLリクエストが可能になります。ただし、AVMCが2つのノードおよびノード当たり80 ECPUで作成された場合、ECPU要件が64を超えるデータベースは分割され、複数のノードにわたってオープンされます。
- VMクラスタに、ノードごとに2つのノードと40個のECPUを持つACDを作成し、分割しきい値をはるかに小さい値(20個のECPUなど)に明示的に設定するとします。CPU要件が20を超えるAutonomous AI Databaseは、複数のノードに分割およびオープンされ、CPU要件が20未満のデータベースが単一のノードでオープンされます。
  
  分割しきい値をデフォルト値よりもはるかに小さい値に設定すると、複数のノードでCPU数が小さいデータベースが開いている可能性が高くなります(CPU数が設定された分割値より大きい場合)。データベースが作成されるか、この分割値より大きいサイズにスケーリングされるたびに、複数のノードでオープンされます。これは、複数のノードでデータベースをオープンして、ノード障害または計画メンテナンスの場合のパフォーマンス低下を制御する場合に便利です。大きいRACクラスタ内の複数のノードにデータベースを分割すると、1つのノードに障害が発生した場合や、スケジュールされたメンテナンスが発生した場合でも、パフォーマンス・プロファイルを50%に低下させるのではなく、パフォーマンスを引き続き向上させることができます。
- 2つのノードと40個のECPUを持つAVMCで、分割しきい値をデフォルト(80個のECPUなど)よりもはるかに高い値に明示的に設定するとします。CPU要件が40を超えるAutonomous AI Databaseは、複数のノードに分割およびオープンされ、CPU要件が40未満のデータベースが単一のノードでオープンされます。
  
  分割しきい値をデフォルトよりはるかに高い値に設定すると、データベースDMLは単一のRACノードにとどまり、クラスタ待機競合が発生する可能性がなくなります。
- Autonomous AI Databaseを手動でスケーリングする場合、新しいCPU値が既存の分割モデルに適用されます。つまり、新しい値が分割しきい値より小さい場合、1つのノードでオープンし、値が分割しきい値より大きい場合、複数のノードでオープンします。
分散アフィニティ: 自律型AIデータベースが分割しきい値を超えた場合にオープンされるノードの数を決定します。
たとえば、ノードごとに4つのノードと80個のECPUを持つAVMCリソースを作成し、データベースの「分割しきい値」を64に設定してこのAVMCにACDを作成したとします。ECPU要件が120のAutonomous AI Databaseを作成すると、64を超える120 (分割しきい値)としてデータベースが複数のノードに分割およびオープンされます。
- ディストリビューション・アフィニティが「最小ノード」に設定されている場合、Oracle Cloud Infrastructureは、各ノードに60 ECPUの2つのノードでデータベースを作成しようとします。これが不可能な場合は、それぞれ40 ECPUの3つのノードに分割されます。これも不可能な場合、Oracle Cloud Infrastructureは、それぞれ30 ECPUの4つのノードでデータベースをオープンしようとします。
- 最大ノードへの分散アフィニティを指定すると、Oracle Cloud Infrastructureは、それぞれ30 ECPUの4つのノードすべてに分割されたデータベースを作成しようとします。これが不可能な場合は、それぞれ40 ECPUの3つのノードに分割されます。これも不可能な場合、Oracle Cloud Infrastructureは、それぞれ60 ECPUの2つのノードでデータベースをオープンしようとします。
ノード・フェイルオーバー予約(%): ローカライズされた障害およびメンテナンス・イベントのために、AVMC内の隣接するノード(データベース・ソフトウェアが存在するがオープンしていないノード)に確保されるCPUの数。ノード・フェイルオーバーの予約は、分割されていないデータベース・デプロイメントに適用されます。デフォルトでは、50%の予約があります。つまり、障害イベントまたはメンテナンス中は引き続き実行されますが、割り当てられたCPUの50%で実行されます。
- 非常に使用率が低いクリティカルでないデータベースまたはデータベースの場合、ノード・フェイルオーバー予約を小さい値に設定して、最終的に専用Exadataインフラストラクチャ上に多数のデータベースを作成して統合できます。
- メンテナンス中の停止時間が許容される開発環境およびデータベースでは、この値をゼロに設定できます。
- ノード・フェイルオーバー予約は、分割しきい値および分散アフィニティを使用して、データベースを2つ以上のノードに分割することで制御することもできます。Autonomous AI Databaseが4つのノードに分割されているシナリオを考えてみます。メンテナンス・アクティビティの進行中に一度に1つのノードをローリング方式で削除すると、常に3つのノードが稼働し、トラフィックを受け取っており、通常の50%ではなくパフォーマンスを効果的に75%維持できます。大規模なクラスタでは、この予約をさらに増やすことができます。たとえば、8ノード・クラスタでは87.5%の予約になります。

Autonomous AI DatabaseのCPU割当てがVMクラスタ・ノード間でどのように分散されるかは、次の操作に影響します:

自動スケーリング:
- 自動スケーリングは、パラレル化不可能なDMLの場合は単一のVMクラスタ・ノード内で、DMLがパラレル化可能な場合はVMクラスタ・ノード間で発生する可能性があります。
- パラレル化不可能な問合せを含む複数の同時セッションをクラスタ内のすべてのノードにルーティングできるため、マルチノード・データベースのすべてのノードを効率的に自動スケーリングできます。
パラレル処理:
- SQL文のパラレル処理は、オープンされているAutonomous Exadata VMクラスタ・ノード内で、最初に単一ノード内で、次に隣接するオープン・ノードで発生します。前述のように、Autonomous Exadata VMクラスタのサイズによって異なります。

各ノードのリソース使用率に基づいて、使用可能なCPUのすべての値を使用してAutonomous AI Databaseをプロビジョニングまたはスケールできるわけではありません。たとえば、AVMCレベルで使用可能なCPUが20個ある場合、ノード・レベルのリソースの可用性に応じてAutonomous AI Databaseをプロビジョニングまたはスケールするために1から20のすべての値を使用できるわけではありません。Autonomous AI Databaseのプロビジョニングまたはスケーリングに使用できるCPU値のリストは、プロビジョニング可能なCPUと呼ばれます。

OCIコンソールから自律型AIデータベースをプロビジョニングまたはスケーリングしようとすると、「CPU」フィールドに、プロビジョニング可能なCPUのリストを含むドロップダウンが表示されます。または、次のAPIを使用して、暫定CPU値のリストを取得できます。

GetAutonomousContainerDatabaseは、指定された自律型コンテナ・データベースで新しいAutonomous AI Databaseを作成するために使用できる、プロビジョニング可能なCPU値のリストを返します。詳細については、GetAutonomousContainerDatabaseを参照してください。
GetAutonomousDatabaseは、特定のAutonomous AI Databaseのスケーリングに使用できるプロビジョニング可能なCPU値のリストを返します。詳細については、GetAutonomousDatabaseを参照してください。

タイトルおよび著作権情報

Oracle and/or its affiliates.