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

Autonomous AI Database on Dedicated Exadata Infrastructureは、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データベースです。詳細は、Autonomous AI Database for Developersを参照してください。

• OCPU: OCPUは、コンピュート・リソースの物理的な尺度です。OCPUは、ハイパースレッドが有効なプロセッサの物理コアに基づきます。

  ノート: OCPUは従来の請求メトリックであり、Autonomous AI Database on Dedicated Exadata Infrastructureでは廃止されました。Oracleでは、新規および既存のすべてのAutonomous AI DatabaseデプロイメントにECPUを使用することをお薦めします。詳細は、Oracle Support Document 2998755.1を参照してください。

  新しいデータベースのプロビジョニング、既存のデータベースのクローニングおよび既存のデータベースのCPUリソースのスケール・アップまたはスケール・ダウンの場合:

  • CPU数のデフォルトは1 OCPUで、増分単位は1です。たとえば、1を超えるOCPUの次に使用可能な数は2です。

  • OCPU全体を必要としないデータベースの場合は、OCPUを0.1から0.9までの範囲で(0.1のOCPUで)割り当てることができます。これにより、CPUをオーバープロビジョニングし、各インフラストラクチャ・インスタンスでより多くのデータベースを実行できます。詳細は、CPU Overprovisioningを参照してください。

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

コンピュート管理

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

複数のVM Autonomous Exadata VMクラスタは、複数のVM Autonomous AI Database機能の起動前に作成されたExadata Infrastructure (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から新しいACPに割り当てられます。したがって、AVMCリソース・レベルで使用可能なCPUは、それに応じて減少します。そのACPで最初のAutonomous AIデータベースを作成すると、新しいデータベースは、最初に割り当てられたCPU(ノード当たり8 ECPUまたは2 OCPU)を使用します新しいデータベースに8個を超えるECPUまたは2個のOCPUが必要な場合、それらは親AVMCの使用可能なCPUから割り当てられ、親AVMCレベルで使用可能なCPUが減少します。ACDをさらに作成し、各ACC内でAutonomous AIデータベースをプロビジョニングすると、それに従って使用可能なCPU値が変わります。

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

同様に、Autonomous AI DatabaseのCPUを手動でスケール・アップすると、親AVMCレベルで使用可能なCPUから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の数は、デプロイメント全体について、親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割当て

自動スケーリング機能により、Autonomous AI Databaseでは、割り当てられた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が新しいデータベースの3倍CPU値より小さい場合、そのACDに追加のCPUが予約されます。これらのCPUは、予約済CPUと呼ばれます。予約済CPUにより、ACDレベルで使用可能なCPUは常に、そのACD内の最大自動スケーリング対応データベースの3倍以上のCPU値になります。これらの予約済CPUは、このACDでAutonomous AIデータベースを作成または手動でスケーリングするために引き続き使用できます。

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

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

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

対照的に、2 CPU Autonomous AI Databaseを実行している4つ(すべて自動スケーリングが有効で、1つは8 CPU Autonomous AI Databaseを停止)をホストするAutonomous Container Databaseの例を考えてみます。この場合も、コンテナ・データベースで自動スケーリング目的に使用できるCPUの数は16です。CPUを2つ超える負荷増加のために実行中のデータベースのいずれかを自動スケーリングする必要がある場合、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 Standbyサービス・インスタンスでは発生しません。

コンパートメント割当てが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データベースの作成、手動でのスケーリングおよび自動スケーリングに使用できるCPUの数を個別に制限できます。

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

VMクラスタ・ノードがCPU管理に与える影響

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

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

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

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

  分割値より小さいCPU値で作成されたAutonomous AIデータベースは、クラスタ内の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つのノードでオープンし、その値が分割しきい値より大きい場合、複数のノードでオープンします。

• 分散アフィニティ: 分割しきい値を超えると、Autonomous AIデータベースがオープンされるノードの数を決定します。

  たとえば、4ノードおよびノード当たり80 ECPUのAVMCリソースを作成し、データベースの「分割しきい値」を64に設定してACDをこのAVMCに作成したとします。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クラスタ・ノード間でどのように分散されるかは、次の操作に影響します。

• 自動スケーリング:

  • 自動スケーリングは、1つのVMクラスタ・ノード内(パラレル化不可DMLの場合)およびVMクラスタ・ノード間(DMLがパラレル化可能の場合)で発生する可能性があります。

  • 非パラレル化問合せを使用する複数の同時セッションは、クラスタ内のすべてのノードにルーティングされる可能性があるため、マルチノード・データベース内のすべてのノードを効率的に自動スケーリングできます。

• パラレル処理:

  • SQL文のパラレル処理は、開いているAutonomous Exadata VMクラスタ・ノード内で、最初に単一ノード内で、次に隣接するオープン・ノードで行われます。前述のように、Autonomous Exadata VMクラスタのサイズによって異なります。

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

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

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

• GetAutonomousDatabaseは、指定されたAutonomous AI Databaseのスケーリングに使用できるプロビジョニング可能なCPU値のリストを返します。詳細については、GetAutonomousDatabaseを参照してください。

関連コンテンツ

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