JP7564191B2 - クラウドインフラストラクチャ環境におけるコンパートメント割り当てのためのシステムおよび方法 - Google Patents

Description

著作権通知
この特許文献の開示の一部は、著作権保護の対象となる資料を含む。著作権保有者は、この特許文献または特許開示の、それが特許商標庁の特許ファイルまたは記録に現れているとおりの、何人による複写複製にも異議を唱えないが、それ以外の場合にはすべての著作権をどのようなものであろうと所有する。

関連出願に対する優先権主張および相互参照：
本出願は、２０１９年８月９日に出願された「SYSTEM AND METHOD FOR COMPARTMENT QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題される米国仮特許出願第６２／８８４，９３６号；２０１９年８月９日に出願された「SYSTEM AND METHOD FOR SUPPORTING A QUOTA POLICY LANGUAGE IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題される米国仮特許出願第６２／８８４，９９４号；および２０１９年８月９日に出願された「SYSTEM AND METHOD FOR SUPPORTING A USAGE CALCULATION PROCESS IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題される米国仮特許出願第６２／８８４，９９８号に対する優先権の利益を主張し、上記の出願の各々は、参照によりその全体が本明細書に組み込まれる。

本出願はまた、２０２０年８月５日に出願された「SYSTEM AND METHOD FOR COMPARTMENT QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題される米国特許出願第１６／９８６，１６２号；２０２０年８月５日に出願された「SYSTEM AND METHOD FOR SUPPORTING A QUOTA POLICY LANGUAGE IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題される米国特許出願第１６／９８６，１６３号；および２０２０年８月５日に出願された「SYSTEM AND METHOD FOR SUPPORTING A USAGE CALCULATION PROCESS IN A CLOUD INFRASTRUCTURE ENVIRONMENT」と題される米国特許出願第１６／９８６，１６４号に対する優先権の利益も主張し、上記の出願の各々は、参照によりその全体が本明細書に組み込まれる。

技術分野
本明細書で説明される実施形態は、概して、サービスとしてのインフラストラクチャ（Infrastructure as a Service）（ＩａａＳ）等のクラウドインフラストラクチャ環境に関し、特に、そのようなクラウドインフラストラクチャ環境内でリソース制約を設けるためのシステムおよび方法を提供するためのシステムならびに方法に関する。

背景：
クラウドインフラストラクチャ環境は、ユーザおよびクライアント（本明細書を通して、「クライアント」および「顧客」という用語は互換的に用いることができる）が、高度に利用可能なホストされた環境において広範囲のアプリケーションおよびサービスを構築ならびに実行することを可能にする、補完的クラウドサービスのセットを備えることができる。

年々、ますます多くの事業および組織が、ミッションクリティカルなアプリケーションおよびシステムをクラウドインフラストラクチャ環境に移行させている。このシフトの理由は様々である。例えば、多くの事業は、オンプレミスインフラストラクチャを運用し、維持し、増築するコストおよび複雑さを低減するために、クラウドに移動している。同様に、クラウドインフラストラクチャは、より迅速な情報技術（ＩＴ）配信機構も可能にする。いくつかの事業および組織は、さらに、クラウドインフラストラクチャ環境を、より敏捷なシステムに適合することによって、競争で優位に立つ手段として見る。

ＩａａＳ（Infrastructure as a Service）モデル内では、クラウドプロバイダは、従来の設定では、各顧客／クライアントの場所においてオンプレミスとなるであろうインフラストラクチャ構成要素を提供、ホスト、および管理することができる。そのような従来的にオンプレミスの構成要素は、ハードウェア、例えば、データウェアハウスおよびデータセンター、サーバ、ストレージ、ネットワーキングハードウェア、ならびに仮想化ソフトウェア等のソフトウェアを含むことができる。

ＩａａＳプロバイダは、従来ではオンプレミスであろうハードウェアおよびソフトウェアを提供することに加えて、それらのクライアントおよび顧客にサービスを提供することもできる。例として、クライアントおよび顧客は、彼らのＩａａＳサブスクリプションを彼らのニーズに適合するように調整することを可能にされ得、次いでこれは、詳細で分解された課金および請求を可能にする。ＩａａＳは、負荷分散、冗長性、複製、回復などの機能もサポートできる。そのようなサービスは、（顧客ではなく）ＩａａＳプロバイダによって提供およびサポートされるため、これは、クライアントおよび顧客を、彼らのサービスのための自動化およびオーケストレーションにさらにプッシュすることによって、彼らの事業を改善することに、より集中させる。

クラウドインフラストラクチャは、ユーザおよびクライアントが、従来の企業アプリケーションを、クラウドネイティブアプリとともに、すべて同じプラットフォーム上でシームレスに実行することを可能にし、運用オーバーヘッドを低減し、両方のタイプのワークロード間の直接接続性を可能にする。

概要：
ある実施形態に従うと、クラウドインフラストラクチャ環境のためにコンパートメント割り当てを提供するためのシステムおよび方法が本明細書に記載される。ある実施形態に従うと、クラウド管理者は一般に、既存のクラウドにおけるリソース使用を制限する能力を有していない。ユーザにリソースを作成するための許可を与えることにより、ユーザは、事前定義されたアカウント限度まで任意の数のリソースを作成することが可能になる。コンパートメント割り当ては、管理者が、ユーザのリソース使用を適切なレベルに制限することができ、微調整されたコスト制御が可能になる。

ある実施形態に従うと、顧客は、アカウント作成時にクラウドインフラストラクチャ環境によって定義されるサービスレベル制限を割り当てられることができる。これらのサービスレベル制限は、顧客がテナンシ全体にわたって（例えば、複数のコンパートメントを伴う複数のリージョンにわたって）作成することができるリソースの総数を制限する。テナンシおよびコンパートメント管理者は、コンパートメント割り当てを利用して、リソース固有の制限を設定することができる。そのようなコンパートメントの制限がなければ、インスタンスを起動することを承認されたユーザは、テナンシ全体においてすべての利用可能な容量を消費し得る。コンパートメントリソース制限は、この問題を解決し、サービス制限とは異なり、例えば、コンソール、ＳＤＫ、またはＡＰＩを介して、クライアントおよび顧客によって設定ならびにカスタマイズされる。コンパートメント制限は、サービス制限の上に適用され、ネスト化されたコンパートメント階層を通して継承され得る。これは、コンパートメント管理者が、リソース消費を制限し、許容可能なリソース使用の周りに境界を設定することを可能にする。

ある実施形態に従うと、クラウドインフラストラクチャ環境において割り当てポリシー言語をサポートするためのシステムおよび方法が本明細書に記載される。割り当てポリシーは、ステートメントシンタックスを設定することによって構成され得る。割り当てを設定するために、割り当ては、いくつかの要素を確立することができる。各割り当ては、サービスファミリ（例えば、計算）内で一意であり得、したがって、各割り当ては、割り当て名とともにターゲットサービスを定義することができる。次に、割り当ては、割り当てを設定する値、および割り当てがターゲットとするコンパートメントを定義することができる。割り当てがいつ適用されるかを決定するために含まれ得る条件のセットが存在し得る。

ある実施形態に従うと、クラウドインフラストラクチャ環境において使用計算プロセスまたはアルゴリズムをサポートするためのシステムおよび方法が本明細書に記載される。使用計算プロセスは、コンパートメントのツリー構造内のコンパートメントをターゲットとする要求されたトランザクションが、ツリー構造内の親コンパートメント内の任意のコンパートメント割り当てまたは制限に違反するかどうかを判定するために用いることができる。

ある実施形態に係る、クラウドインフラストラクチャ環境を提供するためのシステムを示す図である。 ある実施形態に係る、クラウドインフラストラクチャ環境内にクラウドインフラストラクチャリージョンを提供するためのシステムを示す図である。 ある実施形態に係る、クラウドインフラストラクチャ環境内においてクラウドインフラストラクチャリージョンに跨がるコンパートメント内にコンパートメントポリシーを提供するためのシステムを示す図である。 ある実施形態に係る、クラウドインフラストラクチャ環境内でのコンパートメント移動のためのシステムを示す図である。 クラウドインフラストラクチャ環境内のコンパートメント移動中のポリシー管理および施行のためのシステムを示す図である。 一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割当てをサポートするためのシステムを示す図である。 一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割当てをサポートするためのシステムを示す図である。 一実施形態による、コンパートメント割り当てを作成するための方法のフローチャートである。 一実施形態による、コンパートメント割り当てを修正するための方法のフローチャートである。 一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割り当てを実施するためのシステムのためのアーキテクチャを示す図である。 一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割当てをサポートする方法のフローチャートである。 ある実施形態に係る、例示的なコンパートメント割り当てポリシーステートメントを示す図である。 ある実施形態に係る、例示的なコンパートメント割り当てポリシーステートメントを示す図である。 ある実施形態に係る、例示的なコンパートメント割り当てポリシーステートメントを示す図である。 ある実施形態に係る、割り当てポリシーステートメントの例を示す図である。 ある実施形態に係る、割り当てポリシーステートメントの例を示す図である。 ある実施形態に係る、割り当てポリシーステートメントの例を示す図である。 ある実施形態に係る、割り当てポリシーステートメントの例を示す図である。 ある実施形態に係る、割り当てポリシーステートメントの例を示す図である。 ある実施形態に係る、クラウドインフラストラクチャ環境において割り当てポリシー言語をサポートするための方法のフローチャートである。 一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割り当てを実施するためのシステムのためのアーキテクチャを示す図である。 一実施形態による、クラウドインフラストラクチャ環境において使用計算プロセスをサポートするための方法のフローチャートである。 一実施形態による、クラウドインフラストラクチャ環境において使用計算プロセスをサポートするための方法のフローチャートである。

詳細な説明：
本明細書の実施形態によれば、「ベアメタルホスト」、「ベアメタルインスタンス」、または「ベアメタル計算インスタンス」という用語は、クラウドインフラストラクチャ環境による使用のために提供される物理ホスト（「ベアメタル」）マシンを指し得る。ベアメタル計算インスタンスは、ハイパーバイザなしでベアメタルサーバ上で直接動作する。ベアメタルインスタンスがプロビジョニングされると、ユーザ／クライアントは、物理ＣＰＵ、メモリ、およびネットワークインターフェイスカード（ＮＩＣ）の唯一の制御を維持することができる。ユーザ／クライアントは、あたかも自分自身のデータセンターで動作するハードウェアであるかのように、各物理マシンの全能力を構成し利用することができる。ユーザ／クライアントは、物理マシンを他のテナントと共有しない。

本明細書の実施形態によれば、クラウドインフラストラクチャ環境は、リージョンおよび可用性ドメインにおいて物理的にホストされ得る。用語「リージョン」は、局所化された地理的エリアを指すことができる。用語「可用性ドメイン」は、あるリージョン内に位置する１つ以上のデータセンターを意味することができる。リージョンは、１つ以上の可用性ドメインから構成される。クラウドインフラストラクチャは、仮想クラウドネットワークのようにリージョン固有、または計算インスタンスのように可用性ドメイン固有であり得る。可用性ドメインは、互いに隔離され、フォールトトレラントであり、同時に故障したり、別の可用性ドメインの故障によって影響を受ける可能性が低い。ユーザ／クライアントが自分のクラウドサービスを構成すると、ユーザ／クライアントは、複数の可用性ドメインを用いて、高い可用性を保証し、リソース障害から保護することができる。いくつかのリソースは、インスタンスおよびそれに付随するストレージボリューム等、同じ可用性ドメイン内で作成されなければならない。

本明細書の実施形態によれば、「レルム」という用語は、リージョンの論理的な集まりを指すことができる。レルムは互いに隔離されており、いかなるデータも共有しない。クライアントのテナンシは、単一のレルム内に存在し、そのレルムに属するリージョンの各々へのアクセスを有することができる。レルムは、例えば、商業的リージョンおよび行政クラウドリージョンのために提供されることができる。

本明細書の実施形態によれば、「コンソール」という用語は、ユーザ／クライアントがクラウドインフラストラクチャ環境にアクセスし、それを管理するために用いることができる（たとえば、ウェブベースの）ユーザインターフェイスを指すことができる。

本明細書の実施形態によれば、「テナンシ」という用語は、クラウドインフラストラクチャ環境内の安全かつ隔離されたパーティションを指すことができる。クライアント／ユーザがクラウドインフラストラクチャ環境についてサインアップすると、クラウドインフラストラクチャ環境は、そのユーザ／クライアント（または彼らの会社）のためにテナンシを作成することができる。テナンシは、ユーザ／クライアントが自分のクラウドリソースを作成、編成、および管理する場所であり得る。

本明細書の実施形態によれば、「コンパートメント」という用語は、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりを指すことができる。コンパートメントは、クライアント／ユーザが、彼らのクラウドリソースを編成し、それらへのアクセスを制御することを可能にする。クライアント／ユーザがコンソールにおいてリソースで作業し始めると、コンパートメントは、クライアント／ユーザが見ているものについてフィルタを提供することができる。

本明細書の実施形態によれば、「テナンシ」という用語は、テナントのクラウドリソースのすべてを含むルートコンパートメントを指すことができる。テナンシ（ルートコンパートメント）および対応するポリシー内に追加のコンパートメントを作成して、各コンパートメント内のリソースへのアクセスを制御することができる。ユーザ／クライアントが、インスタンス、ブロックボリューム、またはクラウドネットワーク等のクラウドリソースを作成すると、ユーザ／クライアントは、リソースがどのコンパートメントに属するべきかを指定することができる。

本明細書の実施形態によれば、「仮想クラウドネットワーク」という用語は、インスタンスが動作する、サブネット、ルートテーブル、およびゲートウェイを含む、従来のネットワークの仮想バージョンを指すことができる。クラウドネットワークは、単一のリージョン内に存在するが、そのリージョンのすべての可用性ドメインを含む。クラウドネットワークにおいて定義される各サブネットは、単一の可用性ドメイン内にあるか、またはそのリージョン内のすべての可用性ドメインにわたるかのいずれかであり得る。少なくとも１つの少なくとも１つのクラウドネットワークは、インスタンスが起動され得る前にセットアップされ得る。

本明細書の実施形態によれば、「インスタンス」という用語は、クラウド内で動作する計算ホストを指すことができる。クラウドインフラストラクチャ環境インスタンスは、ユーザ／クライアントが、従来のソフトウェアベースの仮想マシンとは対照的に、ホストされた物理ハードウェアを利用することを可能にし、それによって、増加したセキュリティおよび性能を提供することができる。

本明細書の実施形態によれば、「イメージ」という用語は、例えば、ＬＩＮＵＸ（登録商標）など、インスタンスのためにオペレーティングシステムおよび他のソフトウェアを定義する仮想ハードドライブのテンプレートを指すことができる。インスタンスが起動されると、そのイメージを選択することによって、その特性を定義することができる。イメージのセットを提供することができ、同じソフトウェアおよびカスタマイズでインスタンスを用いるために、（例えば、テンプレートとして）すでに構成されている既存のインスタンスからイメージを用いることができる。

本明細書の実施形態によれば、「シェイプ」という用語は、インスタンスに割り当てられるＣＰＵの数およびメモリの量の仕様を指すことができる。負荷分散において、シェイプは、入口＋出口トラフィックのためのロードバランサの予めプロビジョニングされた合計最大容量（帯域幅）を決定することができる。利用可能なシェイプは、例えば、１００Ｍｂｐｓ、４００Ｍｂｐｓ、および８０００Ｍｂｐｓを含むことができる。

本明細書の実施形態によれば、「キーペア」という用語は、クラウドインフラストラクチャ環境で用いられる認証機構を指すことができる。キーペアは、秘密鍵ファイルと公開鍵ファイルとからなる。公開鍵はアップロードされることができ、一方秘密鍵はユーザ／クライアントのデバイス上に保持される。秘密鍵は、パスワードのように、ユーザ／クライアントに秘密である。キーペアは、インスタンスＳＳＨキーペアおよびＡＰＩ署名キーペアなどの異なる仕様に従って生成され得る。インスタンスＳＳＨキーペアは、インスタンスへのセキュアシェル（ＳＳＨ）接続を確立するために用いられる。インスタンスがプロビジョニングされると、公開鍵が提供され得、公開鍵は、インスタンスの承認されたキーファイルに保存される。インスタンスにログオンするために、秘密鍵が提供され、それは公開鍵で検証される。ＡＰＩ署名キーペアは、ＰＥＭ（プライバシー拡張メール）フォーマットであり、ＡＰＩ要求を提出するときにユーザ／クライアントを認証するために用いられる。

本明細書の実施形態によれば、「ブロックボリューム」という用語は、クラウドインフラストラクチャ環境インスタンスのために永続的ブロックストレージを提供する仮想ディスクを指すことができる。ブロックボリュームは、例えばデータおよびアプリケーションを記憶するために、例えばコンピュータ上の物理ハードドライブと同様の方法で、用いることができる。ボリュームは、データの損失なしに、あるインスタンスから分離され、別のインスタンスにアタッチされることができる。

本明細書の実施形態によれば、「オブジェクトストレージ」という用語は、データをオブジェクトとして記憶および管理するために用いられ得るストレージアーキテクチャを指し得る。データファイルは任意のタイプであり得る。データがオブジェクトストレージにアップロードされると、それは任意の場所からアクセスすることができる。オブジェクトストレージは、大量のデータを記憶する必要があり、そのデータがあまり頻繁に変化しないときに、用いることができる。オブジェクトストレージのための典型的な使用は、データバックアップ、ファイル共有、非構造化データ（例えば、ログおよびセンサ生成データ）の記憶を含むが、これらに限定されない。

本明細書の実施形態によれば、「バケット」という用語は、データおよびファイルを記憶するための論理コンテナを指すことができる。バケットは、無制限の数のオブジェクトを含むことができる。

上述のように、クラウドインフラストラクチャ環境は、ユーザおよびクライアントが、高度に利用可能なホストされた環境において広範囲のアプリケーションおよびサービスを構築ならびに実行することを可能にする、補完的クラウドサービスのセットを備えることができる。

図１は、一実施形態による、クラウドインフラストラクチャ環境を提供するためのシステムを示す。

ある実施形態に従うと、いくつかのハードウェアおよびソフトウェアリソース１１２上で実行することができるクラウドインフラストラクチャ環境１００は、コンソールインターフェイス１０２とＡＰＩ１０４とを備えることができる。加えて、クラウドインフラストラクチャ環境１００は、いくつかのガバナンスサービス１１０と、アイデンティティおよびアクセス管理（ＩＡＭ）サービス１２０と、プロビジョニングサービス１３０とをサポートすることができる。クラウドインフラストラクチャ環境１００はまた、たとえば、コンピュータリソース層１５０、ネットワークリソース層１６０、およびストレージリソース層１７０などの層において、いくつかのリソース１４０をサポートすることができる。

ある実施形態に従うと、デバイスハードウェア（プロセッサ、メモリなど）１２を有するコンピューティングデバイス１０などのクライアントデバイスは、たとえばワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、またはインターネットなどのネットワークを介してクラウドインフラストラクチャ環境と通信することができる。クライアントデバイスは、管理者アプリケーション１４を備えることができ、それは、ユーザインターフェイス１６を備えることができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境内では、テナンシをサポートすることができる。登録および展開時に、クライアント／顧客ごとにテナンシを作成することができ、これは、クラウドインフラストラクチャ内に、クライアントが自分のクラウドリソースを作成、編成、および管理することができるセキュアかつ隔離されたパーティションを備えることができる。

ある実施形態に従うと、コンソールインターフェイス１０２およびＡＰＩ１０４は、クライアントに、インフラストラクチャ環境のそれぞれの部分に対するアクセスおよび制御を与える。ある実施形態に従うと、コンソールインターフェイスは、クライアントに、リソース、インスタンス、クラウドネットワーク、およびストレージボリュームを作成ならびに管理させるとともに、クライアントに関連付けられるユーザを管理させ、クライアント範囲内に許可を設定させる、直感的なグラフィカルインターフェイスを含むことができる。同様に、ＡＰＩ１０４は、例えばＨＴＴＰＳ（ハイパーテキスト転送プロトコルセキュア）を利用するＲＥＳＴ ＡＰＩを含み得る。

ある実施形態に従うと、コンソールインターフェイスまたはＡＰＩの一例は、構成管理ツール（たとえばAnsible）とすることができる。構成管理ツールは、クラウドインフラストラクチャプロビジョニング、オーケストレーション、および構成管理のために用いることができる。構成管理ツールは、クライアントが、クラウドインフラストラクチャの構成およびプロビジョニング、ソフトウェアアセットの展開および更新、ならびに複雑な動作プロセスのオーケストレーションを自動化することを可能にすることができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境のガバナンスサービス１１０は、クライアントが単純なリソース管理を可能にし、コストを管理し、クラウドインフラストラクチャへのアクセスを制御するのを助けるツールをクライアントに提供する。例として、ガバナンスサービスはタグ付けを提供し、このタグ付けは、クライアントが情報上または動作上の理由で彼らのリソースにタグを適用することを可能にすることができる。定義済みタグは、正しくないタグがリソースに適用されることを回避するように制御され得る。タグはまた、管理スクリプトのために柔軟なターゲット化機構を提供することもできる。同様に、ガバナンスサービスは、予算管理を可能にし、実費および予測費をすべて１つの場所から追跡することができる。これにより、クライアントは、費用分析ダッシュボードで使用の上に留まり、コンパートメントおよびタグによってフィルタリングして、部門、チーム、およびプロジェクトによる支出を分析することができる。そのようなデータは、詳細なリソース利用報告ならびに既存のクラウド管理およびビジネスインテリジェンスツールとの統合のためにエクスポートすることもできる。ガバナンスサービスはまた、クラウドインフラストラクチャエンタイトルメントならびにコンパートメントにわたるセキュリティ、コンプライアンス、およびリソース最適化のために後で検索され、記憶され、分析され得るイベントを記録することもできる。

ある実施形態に従うと、アイデンティティおよびアクセス管理（ＩＡＭ）サービス１２０は、ＩＡＭサービスにおける各クライアント／顧客／ユーザについて、ユーザクレデンシャル（たとえばユーザ名およびパスワード）に関連付けられて、ユーザプロファイルを作成することができる。クライアントは、ＩＡＭサービスを介してクラウドインフラストラクチャにおいて管理者特権も付与され得る。

ある実施形態に従うと、アイデンティティおよびアクセス管理サービスは、クラウドインフラストラクチャ環境と統合することができる。クライアント登録で、ＩＡＭサービスは、アイデンティティサービスにおいて別のユーザクレデンシャルを作成することができ、それは、次いで、クラウドインフラストラクチャサービスへのシングルサインオンおよび追加のクラウドサービスへのアクセスを可能にすることができる。

ある実施形態に従うと、プロビジョニングサービス１３０は、たとえばリソース１４０内などのクラウドインフラストラクチャサービス内にテナンシをプロビジョニングすることができる。プロビジョニングサービスは、例えば、コンソールインターフェイスを通して、またはＡＰＩ１０４等の１つ以上のＡＰＩを介して、アクセスおよび制御することができる。プロビジョニングサービスは、クライアントに、インスタンスと称され得る計算ホストをプロビジョニングおよび管理させることを可能にし得る。クライアントは、計算およびアプリケーション要件を満たすために必要に応じてインスタンスを起動することができる。クライアントがインスタンスを起動した後、プロビジョニングされたインスタンスは、例えば、クライアントデバイスからアクセスされることができる。プロビジョニングサービスはまた、インスタンスの再起動、インスタンスからのボリュームのアタッチおよびデタッチ、ならびにインスタンスの終了を提供することができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境によって提供されるリソース１４０は、計算リソース層１５０、ネットワークリソース層１６０、およびストレージリソース層１７０などの複数の層に分割することができる。

ある実施形態に従うと、計算リソース層１５０は、たとえばベアメタルインスタンス１５２、仮想マシン１５４、エッジサービス１５６、およびコンテナ１５８などのいくつかのリソースを含み得る。計算リソース層は、例えば、ベアメタル計算インスタンスをプロビジョニングおよび管理し、オンプレミスデータセンターと同様に、アプリケーションを展開および実行するために必要に応じてインスタンスをプロビジョニングするために用いることができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、計算リソース層内の１つ以上の物理ホスト（「ベアメタル」）マシンの制御を提供することができる。ベアメタル計算インスタンスは、ハイパーバイザなしでベアメタルサーバ上で直接動作する。ベアメタル計算インスタンスがプロビジョニングされると、クライアントは、物理ＣＰＵ、メモリ、およびネットワークインターフェイスカード（ＮＩＣ）の唯一の制御を維持することができる。ベアメタル計算インスタンスは、構成され、各物理マシンの全能力を、あたかもそれがオンプレミスの自身のデータセンターで動作するハードウェアであるかのように、利用することができる。したがって、ベアメタル計算インスタンスは、一般に、テナント間では共有されない。

ある実施形態に従うと、ベアメタル計算インスタンスは、ソフトウェアベースの仮想環境とは対照的に、関連付けられた物理ハードウェアを介して、高レベルのセキュリティおよびパフォーマンスを提供することができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、計算リソース層内においていくつかの仮想マシンの制御を提供することができる。仮想マシン計算ホストは、例えば、仮想マシン動作システムおよび他のソフトウェアを決定することができるイメージから起動することができる。仮想マシンインスタンスに利用可能なリソースのタイプおよび量は、例えば、仮想マシンが起動されたイメージに基づいて判断され得る。

ある実施形態に従うと、仮想マシン（ＶＭ）計算インスタンスは、物理ベアメタルハードウェアの上で動作する独立したコンピューティング環境を含み得る。仮想化は、互いに隔離された複数のＶＭを実行することを可能にする。ＶＭは、例えば、物理マシン全体の性能およびリソース（ＣＰＵ、メモリ、ネットワーク帯域幅、ストレージ）を必要としないアプリケーションを実行するために用いることができる。

いくつかの実施形態では、仮想マシンインスタンスは、ベアメタルインスタンスと同じハードウェア上で実行することができ、これは、同じクラウド最適化ハードウェア、ファームウェア、ソフトウェアスタック、およびネットワーキングインフラストラクチャを用いることに影響を及ぼすことができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、計算リソース層内にいくつかのグラフィカル処理ユニット（ＧＰＵ）計算インスタンスを提供することができる。高速化される計算は、あらゆるサービスにわたって一貫して高速なインフラストラクチャを必要とする。ＧＰＵインスタンスを用いて、クライアントは、より効率的に大量のデータセットを処理および分析することができ、それらを、複雑な機械学習（ＭＬ）、人工知能（ＡＩ）アルゴリズム、および多くの産業用ＨＰＣアプリケーションに対して有用にする。ＧＰＵ計算インスタンスは、仮想化された計算インスタンス（複数のＧＰＵ計算インスタンスが同じベアメタルハードウェアを共有する）として、または各ＧＰＵ計算インスタンスについて専用ハードウェアを提供するベアメタルインスタンスとして、プロビジョニングすることができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、計算リソース層内にいくつかのコンテナ化された計算インスタンスを提供することができる。スタンドアロンコンテナエンジンサービスを用いて、コンテナ化されたアプリケーションを構築し、クラウドに起動することができる。コンテナサービスは、例えば、クラウドネイティブアプリケーションを構築、展開、および管理するために用いることができる。コンテナサービスは、コンテナ化されたアプリケーションが必要とする計算リソースを指定することができ、次いで、コンテナエンジンは、プロビジョニングサービスを介して、（例えば、テナンシのコンテキストにおいて）クラウドインフラストラクチャ環境内で用いるために必要とされる計算リソースをプロビジョニングすることができる。

ある実施形態に従うと、用いることができるそのようなコンテナサービスエンジンの１つは、ホストのクラスタにわたるコンテナ化されたアプリケーションの展開、スケーリング、および管理を自動化するためのオープンソースシステムであるKubernetesである。そのようなコンテナサービスは、アプリケーションを構成するコンテナを、容易な管理および発見のために、論理ユニットにグループ化することができる。

ある実施形態に従うと、ネットワークリソース層１６０は、たとえば仮想クラウドネットワーク（ＶＣＮ）１６２、ロードバランサ１６４、エッジサービス１６６、および接続サービス１６８などのいくつかのリソースを含み得る。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、ネットワーキングリソース層において、いくつかの仮想クラウドネットワーク１６２を提供することができる。仮想クラウドネットワークは、クライアントインスタンスが動作できる、サブネット、ルートテーブル、およびゲートウェイを含む、従来のネットワークの仮想バージョンを含むことができる。クラウドネットワークは、単一のリージョン内に存在するが、そのリージョンのすべての可用性ドメインを含む。クラウドネットワークにおいて定義される各サブネットは、単一の可用性ドメイン内にあるか、またはそのリージョン内のすべての可用性ドメインにわたる（推奨）かのいずれかであり得る。少なくとも１つのクラウドネットワークを、インスタンスを起動する前に構成することができる。ある実施形態では、ＶＣＮは、公衆トラフィック、ＶＰＮ接続、または高速接続サービスを処理して、オンプレミスネットワークを安全に拡張するよう、インターネットゲートウェイを介して構成することができる。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、ネットワーキングリソース層において、いくつかのロードバランサ１６４を提供することができる。負荷分散サービスは、１つのエントリポイントから、仮想クラウドネットワーク（ＶＣＮ）から到達可能な複数のサーバへの、自動化されたトラフィック分配を提供することができる。様々な負荷分散が、パブリックまたはプライベートＩＰアドレス、およびプロビジョニングされた帯域幅を提供することができる。

ある実施形態に従うと、ロードバランサは、リソース利用、スケーリングを改善し、高い可用性を確保するのを助けることができる。複数の負荷分散ポリシーを構成することができ、アプリケーション固有の健全性チェックを提供して、ロードバランサがトラフィックを健全なインスタンスにのみ向けることを確実にすることができる。ロードバランサは、不健全なアプリケーションサーバが保守のためにサービスから取り除かれる前に不健全なアプリケーションサーバからトラフィックを排出することによって、保守ウィンドウを縮小することができる。

ある実施形態に従うと、負荷分散サービスにより、ＶＣＮに関連したパブリックまたはプライベートロードバランサの作成が可能になる。パブリックロードバランサは、インターネットからアクセス可能なパブリックＩＰアドレスを有する。プライベートロードバランサは、ＶＣＮ内でのみ可視であるホスティングサブネットからのＩＰアドレスを有する。複数のリスナが、ＩＰアドレスについて、異なるトラフィックの層（例えば、層４および層７（ＴＣＰおよびＨＴＴＰ）トラフィック）を負荷分散トランスポートするよう、構成され得る。パブリックおよびプライベートの両方のロードバランサは、ＶＣＮから到達可能な任意のバックエンドサーバにデータトラフィックをルーティングすることができる。

ある実施形態に従うと、パブリックロードバランサは、インターネットからトラフィックを受け入れることができ、着信トラフィックのためのエントリポイントとしての役割を果たすパブリックアドレスを割り当てられるパブリックロードバランサを作成することができる。

ある実施形態に従うと、パブリックロードバランサは範囲がリージョナルである。リージョンが複数の可用性ドメインを含む場合、パブリックロードバランサは、例えば、リージョナルサブネット、または各々が別個の可用性ドメインにある２つの可用性ドメイン固有（ＡＤ固有）サブネットを有することができる。リージョナルサブネットでは、ロードバランサは、一次ロードバランサおよびスタンバイロードバランサを、各々異なる可用性ドメインにおいて作成して、可用性ドメイン機能停止中であってもアクセス可能性を保証することができる。負荷分散が複数のＡＤ固有サブネットにおいて形成される場合、一方のサブネットは一次ロードバランサをホストすることができ、他方のサブネットはスタンバイロードバランサをホストすることができる。一次ロードバランサが故障した場合、パブリックＩＰアドレスは二次ロードバランサに切り替わることができる。サービスは、２つのロードバランサを等価物として扱う。

ある実施形態に従うと、リージョンが１つの可用性ドメインのみを含む場合、サービスは、一次ロードバランサおよびスタンバイロードバランサの両方をホストするために、リージョナルであれＡＤ固有であれ、１つのサブネットのみを必要とする。一次ロードバランサおよびスタンバイロードバランサは、各々、割り当てられたフローティングパブリックＩＰアドレスに加えて、ホストサブネットからのプライベートＩＰアドレスを有することができる。可用性ドメイン機能停止がある場合、ロードバランサはフェイルオーバを有さない。

ある実施形態に従うと、プライベート負荷分散はまた、ロードバランサをインターネットから隔離し、セキュリティ姿勢を単純化するようにも提供され得る。ロードバランササービスは、着信トラフィックのためのエントリポイントとして機能するプライベートアドレスをロードバランサに割り当てることができる。

ある実施形態に従うと、プライベートロードバランサは、あるサービスによって、１つのサブネットのみに対応して一次ロードバランサとスタンバイロードバランサとの両方をホストするよう、作成され得る。ロードバランサは、ホストサブネットの範囲に応じて、リージョナルであり得るかまたはＡＤ固有であり得る。ロードバランサは、ホストサブネットを含むＶＣＮ内からのみ、またはセキュリティルールによってさらに制限されるとおりに、アクセス可能である。

ある実施形態に従うと、割り当てられたフローティングプライベートＩＰアドレスは、ホストサブネットに対してローカルである。一次ロードバランサおよびスタンバイロードバランサは、各々、ホストサブネットから追加のプライベートＩＰアドレスを必要とする。

ある実施形態に従うと、可用性ドメイン機能停止がある場合、マルチＡＤリージョン内のリージョナルサブネットにおいて作成されたプライベートロードバランサは、フェイルオーバ能力を提供する。ＡＤ固有サブネットにおいて、または単一の可用性ドメインリージョン内のリージョナルサブネットにおいて作成されたプライベートロードバランサは、可用性ドメイン機能停止に応答してフェイルオーバ能力を有さない。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、ネットワーキングリソース層においていくつかのエッジサービス１６６を提供することができる。概して、エッジサービスは、クライアントがドメインおよびエンドポイントを管理、セキュリティ保護、および維持することを可能にする、いくつかのサービスを備える。これらは、例えば、ＤＮＳ（ドメイン名システム）、ＤＤｏＳ（分散型サービス妨害）保護、電子メール配信などを含む。これらのサービスは、クライアントが性能を最適化し、サイバー攻撃を阻止し、通信をスケール変更することを可能にする。

ある実施形態に従うと、クラウドインフラストラクチャ環境は、ネットワーキングリソース層においていくつかの接続サービス１６８を提供することができる。そのような接続サービスは、クライアントデータセンターまたは既存のネットワークとクラウドインフラストラクチャ環境との間に専用のプライベート接続を作成するための容易な方法を提供することができる。接続サービスは、広帯域幅、および信頼できる一貫したネットワークを提供することができる。

ある実施形態に従うと、ストレージリソース層１７０は、たとえばブロックボリューム１７２、ファイルストレージ１７４、オブジェクトストレージ１７６、およびローカルストレージ１７８などのいくつかのリソースを含み得る。

ある実施形態に従うと、ブロックボリューム１７２は、広範囲のＩ／Ｏ集約的ワークロードをサポートする高性能ネットワークストレージ容量を提供する。クライアントは、ブロックボリュームを用いて、計算インスタンスの記憶容量を拡張し、計算インスタンスにわたって移行することができる耐久性のある永続的なデータストレージを提供し、大きなデータベースをホストすることができる。

ある実施形態に従うと、ファイルストレージ１７４により、クライアントは、スケーラブルで分散型の企業グレードのネットワークファイルシステムを作成することができる。ファイルストレージは、セマンティクス、スナップショット能力、およびデータ保存時の暗号化をサポートする。

ある実施形態に従うと、オブジェクトストレージは、非構造化データに対して高スループットストレージを提供する。オブジェクトストレージサービスは、大量の分析データ、または画像および映像のような豊富なコンテンツのための、ほぼ無制限の記憶容量を可能にする。ブロックボリュームは、追加の耐久性のためにオブジェクトストレージにバックアップされることができる。

ある実施形態に従うと、ローカルストレージ１７８は、たとえば、Ｉ／Ｏ集約型アプリケーション用のソリッドステートドライブの形態で高速かつ信頼性のあるストレージを提供することができる。これらは、例えば、ベアメタルインスタンス内に設けることができる。ローカルストレージは、ＶＭおよびベアメタル計算インスタンスに対して高いストレージ性能を提供する。いくつかの例は、リレーショナルデータベース、データウェアハウス、ビッグデータ、分析、ＡＩ、およびＨＰＣアプリケーションを含む。

図２は、ある実施形態に係る、クラウドインフラストラクチャ環境内にクラウドインフラストラクチャリージョンを提供するためのシステムを示す図である。

ある実施形態に従うと、図１において上述したクラウドインフラストラクチャ環境のインスタンスは、クラウドインフラストラクチャリージョン２２０と呼ばれる異なるリージョンにおいてホストされることができる。これらは、上述のように、コンソール、ＳＤＫ、またはＡＰＩを介して、インターネット２１０などのネットワークを介して顧客ネットワーク２００によってアクセスすることができる。各クラウドインフラストラクチャリージョンは、管理サービス２２２と、計算サービス２２４と、ストレージサービス２２６と、エッジサービス２２８と、ネットワークサービス２３０と、物理インフラストラクチャ２３２とを備えることができる。

ある実施形態に従うと、クラウドインフラストラクチャは、リージョンおよび可用性ドメインにおいてホストされることができる。リージョンは、局所化された地理的エリアとすることができ、可用性ドメインは、リージョン内に位置する１つ以上のデータセンターとすることができる。リージョンは、１つ以上の可用性ドメインから構成される。大抵のクラウドインフラストラクチャリソースは、仮想クラウドネットワークなどのリージョン固有であるか、または計算インスタンスなどの可用性ドメイン固有のいずれかであり得る。可用性ドメイン間およびリージョン間のトラフィックは暗号化される。

ある実施形態に従うと、可用性ドメインは、互いに隔離され、フォールトトレラントであり、障害が同時に生ずる可能性が非常に低い。可用性ドメインは、電力もしくは冷却などのインフラストラクチャ、または内部可用性ドメインネットワークを共有しないので、リージョン内の１つの可用性ドメインにおける障害は、同じリージョン内の他のものの可用性に影響を及ぼす可能性が低い。

ある実施形態に従うと、同じリージョン内の可用性ドメインを低レイテンシの広帯域幅ネットワークによって互いに接続することができ、これにより、インターネットおよびオンプレミスへの高可用性接続性を提供し、高可用性および災害復旧の両方のために複数の可用性ドメインにおいて複製されたシステムを構築することができる。

ある実施形態に従うと、リージョンは他のリージョンから独立しており、地理的に（たとえば国または大陸にわたって）分離されることができる。これは、次いで、あるアプリケーションが最も頻繁に利用される可能性が最も高いリージョン内における当該アプリケーションの展開につながる。

しかしながら、ある実施形態に従うと、アプリケーションは、さまざまな理由により、異なるリージョンにおいて展開されもし得る。これは、例えば、気象システムなどのイベントがリージョンをオフラインで取るときのリスク軽減を含むことができる。加えて、アプリケーションは、課税ドメインまたは他の事業もしくは社会的基準などの戦略的な理由で他のリージョンに展開されることができる。

ある実施形態に従うと、リージョンにわたって利用可能ないくつかのサービスがある。これらは、例えば、管理サービス２２２、計算サービス２２４、ストレージサービス２２６、エッジサービス２２８、およびネットワークサービス２３０を含む。

ある実施形態に従うと、コンパートメントにより、クライアントは、クラウドリソースを編成し、それに対するアクセスを制御することが可能になる。コンパートメントは、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりである。コンパートメントは、物理的なコンテナではなく、論理的なグループと考えることができる。コンソール内で作業するとき、コンパートメントは、見られることを可能にされるものについてのフィルタとして作用することができる。

ある実施形態によると、コンパートメントは、いくつかの層を有することができる。例えば、テナンシは、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。ルートコンパートメント（テナンシ）内に追加のコンパートメントを作成することができ、対応するポリシーを作成して、各コンパートメント内のリソースへのアクセスを制御することができる。クライアントが、インスタンス、ブロックボリューム、またはクラウドネットワークなどのクラウドリソースを作成するとき、そのようなリソースは、特定のあるコンパートメントまたは複数のコンパートメントに向けられ得る。コンパートメントは、リージョンに跨がることができる。

障害ドメイン
ある実施形態に従うと、障害ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループ化を含むことができる。各可用性ドメインは、３つの障害ドメインを含むことができる。障害ドメインは、インスタンスが単一の可用性ドメイン内の同じ物理ハードウェア上にないように、インスタンスが分散されることを可能にする。ある障害ドメインに影響を及ぼすハードウェア障害または計算ハードウェア保守は、他の障害ドメインにおけるインスタンスに影響を及ぼさない。

ある実施形態に従うと、計算、ベアメタルＤＢシステム、または仮想マシンＤＢシステムインスタンスなどのリソースの配置は、任意で、起動時に障害ドメインまたは新たなインスタンスを指定することができる。リソースは、配置後に、リソースを現在の障害ドメインで終了し、リソースの新たなインスタンスを別の障害ドメインで起動することによって、障害ドメインを追加的に変更することができる。

ある実施形態に従うと、障害ドメインは、予期せぬハードウェア障害からの保護および保守による計画された機能停止からの保護といった多くの理由で利用することができる。

可用性
ある実施形態に従うと、サービス可用性を提供することができる。クラウドインフラストラクチャ環境内のリージョンは、以下を含むコアインフラストラクチャサービスおよびリソースを提供することができる：
・計算：計算（ベアメタルおよびＶＭ，DenseIOおよびStandard）、Kubernetesのためのコンテナエンジン、レジストリ．．．
・ストレージ：ブロックボリューム、ファイルストレージ、オブジェクトストレージ、アーカイブストレージ
・ネットワーキング：仮想クラウドネットワーク、負荷分散、高速接続
・データベース：データベース、Exadataクラウドサービス、自律データウェアハウス、自律トランザクション
・処理
・エッジ：ＤＮＳ
・プラットフォーム：アイデンティティおよびアクセス管理、タグ付け、監査
ある実施形態に従うと、上記サービスおよびリソースは一般に利用可能であり得るが、他のサービスおよびリソースも（例えば、リージョナルな需要または顧客要求に基づいて）追加的に利用可能であり得る。例として、新たなクラウドサービスは、リージョナルな顧客需要、適用可能な場合には規制遵守を達成する能力、リソース可用性、および他の要因を含む様々な考慮事項に基づいて、リージョンにおいてできるだけ迅速に利用可能にされ得る。低レイテンシの相互接続バックボーンのため、顧客は、クラウドサービスが自分の本拠リージョンで利用可能でないときに、それらを他の地理的リージョンで効果的な結果を伴って用いることができるが、ただし、データレジデンシー要件がそうすることを妨げないことを条件とする。

ある実施形態に従うと、リソース可用性は、グローバルな可用性、リージョナルな可用性、単一リージョン可用性、およびドメイン可用性のコンテキストにおいて考慮することができる。概して、ＩＡＭリソースは、グローバルに利用可能であり、ＤＢシステム、インスタンス、およびボリュームは、実行可能性ドメインに固有である。他のほとんどのリソースはリージョナルである。

ある実施形態に従うと、グローバルに利用可能なリソースの例には、ＡＰＩ署名キー、コンパートメント、動的グループ、フェデレーションリソース、グループ、ポリシー、タグ名前空間、タグキー、およびユーザを含むことができる。

ある実施形態に従うと、リージョナルに利用可能なリソースの例には、アラーム、アプリケーション、バケット（バケットはリージョナルなリソースであるが、ＡＰＩコールのための正しいリージョン固有のオブジェクトストレージＵＲＬを用いると、バケットは任意の位置からアクセスできる）、クラスタ、クラウドイベントルール、顧客構内機器（ＣＰＥ）、ＤＨＣＰオプションセット、動的ルーティングゲートウェイ（ＤＲＧ）、暗号化キー、関数、イメージ、インターネットゲートウェイ、ジョブ、キーボールト、ロードバランサ、ローカルピアリングゲートウェイ（ＬＰＧ）、メトリック、ＮＡＴゲートウェイ、ネットワークセキュリティグループ、ノードプール、ons-subscriptions、ons-topics、リポジトリ、予約されたパブリックＩｐ、ルートテーブル、セキュリティリスト、サービスゲートウェイ、スタック、サブネット（サブネットが作成されると、それはリージョナルまたは可用性ドメインに固有であると宣言され得る）、仮想クラウドネットワーク（ＶＣＮ）、およびボリュームバックアップ（ボリュームバックアップは、新たなボリュームとして、それらが格納される同じリージョン内の任意の可用性ドメインに復元することができる）などが含まれ得る。

ある実施形態に従うと、可用性ドメイン固有リソースの例は、ＤＢシステム、一過性のパブリックＩｐ、インスタンス（インスタンスは、同じ可用性ドメイン内のボリュームにアタッチすることができる）、サブネット（サブネットが作成されると、それはリージョナルまたは可用性ドメインに固有であると宣言され得る）、およびボリューム（ボリュームは、同じ可用性ドメイン内のインスタンスにアタッチすることができる）を含み得る。

コンパートメント
ある実施形態に従うと、管理者は、クラウドインフラストラクチャ環境内においてコンパートメントを管理することができる。

ある実施形態に従うと、タグを、コンパートメント内のリソースに適用することができる。タグは、例えば、事業ニーズスキーマなどのスキーマに従ってリソースを編成するために用いることができる。タグはリソースの作成時にリソースに適用されることができ、またはタグは既存のリソース上で更新されることができる。

ある実施形態に従うと、コンパートメントは、クラウドインフラストラクチャの構築および編成にとって重要である。リソースをコンパートメント間で移動させることができ、（例えば、ユーザインターフェイスを介して）表示し、現在のリージョン内でコンパートメントによって編成することができる。リソースで作業し、およびリソース管理する場合、まずコンパートメントを選択することができる。

ある実施形態に従うと、コンパートメントはテナンシ幅であり、リージョンに跨がることができる。コンパートメントが作成されると、コンパートメントは、テナンシが加入されるあらゆるリージョン内で利用可能にされることができる。

ある実施形態に従うと、コンパートメントを削除することができる。コンパートメントを削除するために、コンパートメントは、削除に先立って、その中のすべてのリソースを除去されることができる。

ある実施形態に従うと、コンパートメントを削除するアクションは、非同期とすることができ、ワーク要求を開始する。コンパートメントの状態は、ワーク要求の実行中に「削除」に変わる。ワーク要求が失敗した場合、コンパートメントは削除されず、アクティブ状態に戻る。

ある実施形態に従うと、クラウドインフラストラクチャ環境内に作成される各コンパートメントは、あるプロパティを有することができる。例えば、各コンパートメントに、一意の識別子（ＩＤ）を割り当てることができ、加えて、随意に、変更可能な記述および名前を提供することができる。ある実施形態に従うと、サブコンパートメントは、ベースコンパートメントの下に階層的に定義することができる。

ある実施形態に従うと、コンパートメントおよびサブコンパートメントに対するアクセスならびに制御は、管理者または充分なクレデンシャルを有する他のユーザに限定することができる。クレデンシャルは、異なるレベルのコンパートメントアクセスに関連付けることができる。例えば、管理者は、すべてのコンパートメントを閲覧し、およびそれらにアクセスし、ならびにテナンシの任意のコンパートメント内のリソースで作業する許可を有することができるが、アクセスがより制限されたユーザは、そのようなレベルのアクセスおよび制御を有さない。

図３は、ある実施形態に係る、クラウドインフラストラクチャ環境内においてクラウドインフラストラクチャリージョンに跨がるコンパートメント内にコンパートメントポリシーを提供するためのシステムを示す図である。

ある実施形態に従うと、上述したように、図１において上述したクラウドインフラストラクチャ環境３００のインスタンスは、クラウドインフラストラクチャリージョン３２０、３３０、３４０、３５０などの異なるリージョンにおいてホストされ得る。これらは、上述のように、コンソール、ＳＤＫ、またはＡＰＩを介して、インターネット等のネットワーク３０２を介して顧客ネットワーク３０１によってアクセスされることができる。

ある実施形態に従うと、顧客ネットワーク３０１は、たとえば単一のコンピュータ、顧客コンピュータのネットワーク、または他のそのようなネットワークを含み得る。

ある実施形態に従うと、図には示されていないが、各クラウドインフラストラクチャリージョンはいくつかのサービスを含み得、各サービスは、管理サービス、計算サービス、ストレージサービス、エッジサービス、ネットワークサービス、および物理インフラストラクチャなどのいくつかのリソースを含む。

ある実施形態に従うと、クラウドインフラストラクチャは、リージョンおよび可用性ドメインにおいてホストされることができる。リージョンは、局所化された地理的エリアとすることができ、可用性ドメインは、リージョン内に位置する１つ以上のデータセンターとすることができる。リージョンは、１つ以上の可用性ドメインから構成される。大抵のクラウドインフラストラクチャリソースは、仮想クラウドネットワークなどのリージョン固有であるか、または計算インスタンスなどの可用性ドメイン固有のいずれかであり得る。可用性ドメイン間およびリージョン間のトラフィックは暗号化される。

ある実施形態に従うと、可用性ドメインは、互いに隔離され、フォールトトレラントであり、障害が同時に生ずる可能性が非常に低い。可用性ドメインは、電力もしくは冷却などのインフラストラクチャ、または内部可用性ドメインネットワークを共有しないので、リージョン内の１つの可用性ドメインにおける障害は、同じリージョン内の他のものの可用性に影響を及ぼす可能性が低い。

ある実施形態に従うと、同じリージョン内の可用性ドメインを低レイテンシの広帯域幅ネットワークによって互いに接続することができ、これにより、インターネットおよびオンプレミスへの高可用性接続性を提供し、高可用性および災害復旧の両方のために複数の可用性ドメインにおいて複製されたシステムを構築することができる。

ある実施形態に従うと、リージョンは他のリージョンから独立しており、地理的に（たとえば国または大陸にわたって）分離されることができる。これは、次いで、あるアプリケーションが最も頻繁に利用される可能性が最も高いリージョン内における当該アプリケーションの展開につながる。

しかしながら、ある実施形態に従うと、アプリケーションは、さまざまな理由により、異なるリージョンにおいて展開されもし得る。これは、例えば、気象システムなどのイベントがリージョンをオフラインで取るときのリスク軽減を含むことができる。加えて、アプリケーションは、課税ドメインまたは他の事業もしくは社会的基準などの戦略的な理由で他のリージョンに展開されることができる。

ある実施形態に従うと、リージョンにわたって利用可能ないくつかのサービスがある。これらは、例えば、管理サービス、計算サービス、ストレージサービス、エッジサービス、およびネットワークサービスを含む。

ある実施形態に従うと、コンパートメントにより、クライアントは、クラウドリソースを編成し、それに対するアクセスを制御することが可能になる。コンパートメントは、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりである。コンパートメントは、物理的なコンテナではなく、論理的なグループと考えることができる。コンソール内で作業するとき、コンパートメントは、見られることを可能にされるものについてのフィルタとして作用することができる。

ある実施形態によると、コンパートメントは、いくつかの層を有することができる。例えば、テナンシ３０５は、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。コンパートメントは、コンパートメント３６０がテナンシコンパートメントの下のレベルであり、サブコンパートメント３７０がコンパートメント３６０の下の追加の層であるように、階層的態様で編成することができる。ある実施形態に従うと、各コンパートメントは、コンパートメントポリシー３６５およびサブコンパートメントポリシー３７５などの１つ以上のコンパートメントポリシーに関連付けることができる。テナントコンパートメントポリシーは、図に示されていない。

ある実施形態に従うと、コンパートメントまたはサブコンパートメント、たとえばコンパートメント３６０およびサブコンパートメント３７０の作成中、作成時、または作成後に、コンパートメントポリシー３６５およびサブコンパートメントポリシー３７５などのポリシーを、各コンパートメントおよびサブコンパートメントについて記述／作成することができる。コンパートメントポリシーは、例えば、どのユーザがコンパートメント内のリソースおよびサービスにアクセス／利用することを許可されるかを制限することができる。ポリシーが適所にない場合、コンパートメントおよび／またはサブコンパートメントへのアクセスは、テナンシ３０５レベルにおいて許可を有するユーザに制限され得る。

ある実施形態に従うと、コンパートメント内におけるコンパートメント（すなわち、サブコンパートメント）の作成時に、サブコンパートメントは、その階層の上位のコンパートメントからアクセス許可を継承する。

ある実施形態に従うと、コンパートメントまたはサブコンパートメントポリシーを作成すると、そのポリシーは、それがどのコンパートメントにアタッチするかを示す仕様を含み得る。そのような仕様は、ポリシーのサブシーケンス制御、修正、または削除のためのアクセスを制限する制御を含み得る。いくつかの実施形態では、ポリシーは、テナンシ、親コンパートメント、またはポリシーが向けられる特定のコンパートメントにアタッチされ得る。

ある実施形態に従うと、リソースをコンパートメントに配置することができる。これは、リソースの作成時にターゲットとされるコンパートメントを指定することによって達成することができる（コンパートメントは、リソースを作成するために必要な情報の１つである）。これは、コンソールインターフェイスを介して達成することができる。

ある実施形態に従うと、既存のリソースを異なるコンパートメントに移すこともできる。ほとんどのリソースは、それらが作成された後に移動され得る。

ある実施形態に従うと、いくつかのリソースはアタッチされたリソース依存関係を有し、いくつかはアタッチされたリソース依存関係を有さない。親リソースが移動するとき、すべてのアタッチされた依存関係が同じように振る舞うわけではない。

ある実施形態に従うと、いくつかのリソースについて、アタッチされた依存関係は親リソースとともに新たなコンパートメントに移動する。親リソースは直ちに移動するが、場合によっては、アタッチされた依存関係は非同期的に移動し、移動が完了するまで新たなコンパートメント内においては可視ではない。

ある実施形態に従うと、他のリソースについては、アタッチされたリソース依存関係は新たなコンパートメントには移動しない。このようなアタッチされたリソースは、独立して移動させることができる。

ある実施形態に従うと、リソースが新たなコンパートメントに移動された後、その新たなコンパートメントを管理するポリシーが即座に適用され、そのリソースへのアクセスに影響を与える。コンパートメント編成の構造に応じて、メータリング、課金、および警報も影響を受ける可能性がある。

ある実施形態に従うと、作成後、コンパートメントを、たとえば同じテナンシ内の異なる親コンパートメントに移動させることができる。コンパートメントを移動させると、コンパートメントのコンテンツ（サブコンパートメントおよびリソースを含む）のすべてがコンパートメントとともに移動する。

図４は、ある実施形態に係る、クラウドインフラストラクチャ環境内でのコンパートメント移動のためのシステムを示す図である。

ある実施形態に従うと、上述したように、図１において上述したクラウドインフラストラクチャ環境４００のインスタンスは、異なるリージョンにおいてホストされ得る。テナンシ４０５、コンパートメントＡ４６０およびコンパートメントＢ４７０などのコンパートメントは、クラウドインフラストラクチャ環境内に画定することができ、これらのコンパートメントは、リージョンに跨がることができる。そのようなコンパートメントは、上述のように、コンソール、ＳＤＫ、またはＡＰＩを介して、インターネット等のネットワーク４０２を介して顧客ネットワーク４０１によってアクセスされることができる。

ある実施形態に従うと、顧客ネットワーク４０１は、たとえば単一のコンピュータ、顧客コンピュータのネットワーク、または他のそのようなネットワークを含み得る。

ある実施形態に従うと、コンパートメントにより、クライアントは、クラウドリソースを編成し、それに対するアクセスを制御することが可能になる。コンパートメントは、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりである。コンパートメントは、物理的なコンテナではなく、論理的なグループと考えることができる。コンソール内で作業するとき、コンパートメントは、見られることを可能にされるものについてのフィルタとして作用することができる。

ある実施形態によると、コンパートメントは、いくつかの層を有することができる。例えば、テナンシ４０５は、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。コンパートメントは、コンパートメントＡ４６０およびコンパートメントＢ４７０がテナンシコンパートメントの下のレベルであり、サブコンパートメントＡ４６５がコンパートメントＡの下に画定され、サブコンパートメントＢ４７５がコンパートメントＢの下に画定されるように、階層的様式で編成することができる。ある実施形態に従うと、各コンパートメントは、１つ以上のコンパートメントポリシー（図示せず）に関連付けることができる。

ある実施形態に従うと、たとえばテナンシ内に画定されたコンパートメントは、たとえばコンパートメントまたはサブコンパートメントを再画定することによって移動させることができる。

ある実施形態に従うと、コンパートメントを移動させるために、充分な許可を有する要求を受け取ることができる。すなわち、当該要求は、例えば、現在のコンパートメントおよび移動コンパートメントの宛先コンパートメントに対する最も低い層で共有された親コンパートメントに関する「全リソース管理」許可を有するグループに属するユーザからの要求である。

すなわち、例えば、サブコンパートメントＡ４６５をコンパートメントＡ４６０からコンパートメントＢ４７０に移動する（４６５から４７６に移動する）要求は、ユーザから充分な許可とともに受信されなければならない。テナンシ４０５は、送信元コンパートメントであるコンパートメントＡ４６０および宛先コンパートメントであるコンパートメントＢ４７０の両方の最も低い層で共有された親コンパートメントであるため、図に示されるように、サブコンパートメントＡを移動させる要求は、テナンシ４０５のコンパートメント内で「全リソースを管理する」許可を有するユーザから受信されなければならない。

ある実施形態に従うと、別の例では、サブコンパートメントＡ４６５をコンパートメントＡからコンパートメントＢに移動させる要求が、コンパートメントＡ内の「全リソースを管理する」許可のみを有するユーザから受信された場合、その要求は失敗し得、なぜならば、ユーザからの要求は、宛先コンパートメント、すなわちコンパートメントＢ内のリソースを管理することができないからである。

ある実施形態に従うと、コンパートメントを新たな親コンパートメントに移動させると、新たな親コンパートメントのアクセスポリシーが有効となり、前の親コンパートメントのポリシーはもはや適用されない。場合によっては、階層を指定するポリシーとともに入れ子にされたコンパートメントを移動させるとき、それらのポリシーは整合性を保証するために自動的に更新され得る。

したがって、ある実施形態によると、以前にサブコンパートメントＡに適用されたコンパートメントＡ４６０のコンパートメントポリシーは、サブコンパートメントＡのコンパートメントＢへの移動にはもはや適用されないであろう。次いで、コンパートメントＢのコンパートメントポリシーが、代わりにサブコンパートメントＡに適用される。これは、以下の図でさらに説明される。

図５は、クラウドインフラストラクチャ環境内のコンパートメント移動中のポリシー管理および施行のためのシステムを示す。

一実施形態によれば、より具体的には、図５は、コンパートメントが移動されるコンパートメント階層と、異なるポリシーに関する結果とを示す。

ある実施形態に従うと、上述したように、図１において上述したクラウドインフラストラクチャ環境５００のインスタンスは、異なるリージョンにおいてホストされ得る。テナンシ５０５、コンパートメントＡ５６０およびコンパートメントＢ５６５、ならびにコンパートメントＤ５６６等のコンパートメントは、クラウドインフラストラクチャ環境内で画定することができ、これらのコンパートメントは、リージョンに跨がることができる。そのようなコンパートメントは、上述のように、コンソール、ＳＤＫ、またはＡＰＩを介して、インターネット等のネットワーク５０２を介して顧客ネットワーク５０１によってアクセスされることができる。

ある実施形態に従うと、顧客ネットワーク５０１は、たとえば単一のコンピュータ、顧客コンピュータのネットワーク、または他のそのようなネットワークを含み得る。

ある実施形態によると、コンパートメントは、いくつかの層を有することができる。例えば、テナンシ５０５は、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。コンパートメントは、コンパートメントＡ５６０がテナンシの下のレベルであるように、階層的に編成することができる。次いで、コンパートメントＢ５６５およびコンパートメントＤ５６６は、コンパートメントＡ５６０の下のさらに別のレベルとして編成されるが、コンパートメントＣ５７０は、最初はコンパートメントＢの下のレベルとして示される。ある実施形態に従うと、各コンパートメントは、コンパートメントＢポリシー５８２、コンパートメントＡポリシー５８０、およびコンパートメントＤポリシー５８３などの１つ以上のコンパートメントポリシーに関連付けることができる。そのようなポリシーは、例えば、コンパートメントへのアクセスのためのユーザ／クライアント許可、ならびに任意の所与のコンパートメント内のリソースへのアクセスおよびそれらリソースの制御のための許可を管理することができる。上述のように、コンパートメントポリシーは、コンパートメントＢ５６５にアクセスするユーザが、コンパートメントＡポリシー５８０に加えてコンパートメントＢポリシー５８２によって管理／制限されているコンパートメントＢ５６５との対話を有するように、互いに追加（すなわち「スタック」）することができる。

ある実施形態に従うと、たとえば、コンパートメントＢポリシー５８２が、あるグループ、グループ１がコンパートメントＡ－Ｂ内のインスタンスファミリーを管理することを可能にすると仮定する（コンパートメント階層は、コンパートメントＡのサブコンパートメントであるコンパートメントＢを含む）。

ある実施形態に従うと、コンパートメントＤポリシー５８３は、別のグループ、グループ２がコンパートメントＡ－Ｄ内のインスタンスファミリーを管理することを可能にすることも仮定する（コンパートメント階層は、コンパートメントＡのサブコンパートメントであるコンパートメントＤを含む）。

ある実施形態に従うと、コンパートメントＣがコンパートメントＢからコンパートメントＤに移動されると、グループ１のメンバーは、もはやコンパートメントＣ内のインスタンスファミリーを管理することはできず、グループ２のメンバーが、今度は、コンパートメントＣ内のインスタンスファミリーを管理することができる。

ある実施形態に従うと、ある状況において、コンパートメントを移動させると、あるポリシーを自動的に更新することができる。例えば、移動されるコンパートメントまでのコンパートメント階層を指定するポリシーは、ポリシーが現在のターゲット親の共有先祖にアタッチされると、自動的に更新され得る。

再び図５を参照すると、例えば、一実施形態によれば、コンパートメントＡポリシーは、あるグループ、グループＸのメンバーがコンパートメントＢ：Ｃ内のバケットを管理することを可能にすると仮定する。コンパートメントＣをコンパートメントＤに移動すると、コンパートメントＢとコンパートメントＤとの間の共有先祖（コンパートメントＡ）のため、コンパートメントＡポリシーは、グループＸのメンバーがコンパートメントＤ：Ｃ内のバケットを管理することを可能にするように、自動的に更新され得る。

ある実施形態に従うと、テナンシにアタッチされたポリシーは同様に、コンパートメントがテナンシ内を移動すると、自動的に更新されることができる。

しかしながら、ある実施形態に従うと、コンパートメントの移動で、すべてのポリシーが自動的に更新されるわけではない。例えば、図５を参照すると、コンパートメントＣがコンパートメントＢからコンパートメントＤに移動される状況において、コンパートメントＢポリシーは、（移動前に）コンパートメントＣ内のバケットの管理を可能にすると仮定する。コンパートメントＣが移動される場合、コンパートメントＢポリシーは自動的に更新されない。代わりに、ポリシーは、もはや有効ではなく、（例えば、手動または自動で）除去され得る。

ある実施形態に従うと、クラウド管理者は一般に、既存のクラウドにおけるリソース使用を制限する能力を有していない。ユーザにリソースを作成するための許可を与えることにより、ユーザは、事前定義されたアカウント限度まで任意の数のリソースを作成することが可能になる。コンパートメント割り当ては、コンパートメント内でリソースを作成または使用する能力に、微調整されたコスト制御を可能にする適切なレベルへの制限を課すことを可能にする。

ある実施形態に従うと、顧客は、アカウント作成時にクラウドインフラストラクチャ環境によって定義されるサービスレベル制限を割り当てられることができる。これらのサービスレベル制限は、顧客がテナンシ全体にわたって（例えば、複数のコンパートメントを伴う複数のリージョンにわたって）作成することができるリソースの総数を制限する。テナンシおよびコンパートメント管理者は、コンパートメント割り当てを利用して、リソース固有の厳しい制限を設定することができる。そのようなコンパートメント制限がなければ、インスタンスを起動することを承認されたユーザは、テナンシ全体においてすべての利用可能な容量を消費し得る。コンパートメントリソース制限は、この問題を解決し、サービス制限とは異なり、例えば、コンソール、ＳＤＫ、またはＡＰＩを介して、クライアントおよび顧客によって設定ならびにカスタマイズされる。コンパートメント制限は、サービス制限の上に適用され、ネスト化されたコンパートメント階層を通して継承され得る。これは、コンパートメント管理者が、リソース消費を制限し、許容可能なリソース使用の周りに境界を設定することを可能にする。

ある実施形態に従うと、コンパートメント割り当ては、テナントおよびコンパートメント管理者に、クラウドインフラストラクチャ環境においてリソースがどのように消費されるかをよりよく制御させ、管理者が、たとえばコンソール、ＳＤＫ、もしくはＡＰＩを用いて、コンパートメントにリソースを容易に割り当てることを可能にする。コンパートメント割り当ては、テナント内でのクライアントの支出を管理するための強力なツールセットである。

図６は、一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割当てをサポートするためのシステムを示す。

ある実施形態に従うと、上述したように、図１において上述したクラウドインフラストラクチャ環境６００のインスタンスは、クラウドインフラストラクチャリージョン６２０、６６０、６４０、６５０などの異なるリージョンにおいてホストされ得る。これらは、上述のように、コンソール６０３、ＳＤＫ、またはＡＰＩを介して、インターネット等のネットワーク６０２を介して顧客ネットワーク６０１によってアクセスされることができる。

ある実施形態に従うと、顧客ネットワーク６０１は、たとえば単一のコンピュータ、顧客コンピュータのネットワーク、または他のそのようなネットワークを含み得る。

ある実施形態に従うと、図には示されていないが、各クラウドインフラストラクチャリージョンはいくつかのサービスを含み得、各サービスは、管理サービス、計算サービス、ストレージサービス、エッジサービス、ネットワークサービス、および物理インフラストラクチャなどのいくつかのリソースを含む。

ある実施形態に従うと、クラウドインフラストラクチャは、リージョンおよび可用性ドメインにおいてホストされることができる。リージョンは、局所化された地理的エリアとすることができ、可用性ドメインは、リージョン内に位置する１つ以上のデータセンターとすることができる。リージョンは、１つ以上の可用性ドメインから構成される。大抵のクラウドインフラストラクチャリソースは、仮想クラウドネットワークなどのリージョン固有であるか、または計算インスタンスなどの可用性ドメイン固有のいずれかであり得る。可用性ドメイン間およびリージョン間のトラフィックは暗号化される。

ある実施形態に従うと、可用性ドメインは、互いに隔離され、フォールトトレラントであり、障害が同時に生ずる可能性が非常に低い。可用性ドメインは、電力もしくは冷却などのインフラストラクチャ、または内部可用性ドメインネットワークを共有しないので、リージョン内の１つの可用性ドメインにおける障害は、同じリージョン内の他のものの可用性に影響を及ぼす可能性が低い。

ある実施形態に従うと、同じリージョン内の可用性ドメインを低レイテンシの広帯域幅ネットワークによって互いに接続することができ、これにより、インターネットおよびオンプレミスへの高可用性接続性を提供し、高可用性および災害復旧の両方のために複数の可用性ドメインにおいて複製されたシステムを構築することができる。

ある実施形態に従うと、リージョンは他のリージョンから独立しており、地理的に（たとえば国または大陸にわたって）分離されることができる。これは、次いで、あるアプリケーションが最も頻繁に利用される可能性が最も高いリージョン内における当該アプリケーションの展開につながる。

しかしながら、ある実施形態に従うと、アプリケーションは、さまざまな理由により、異なるリージョンにおいて展開されもし得る。これは、例えば、気象システムなどのイベントがリージョンをオフラインで取るときのリスク軽減を含むことができる。加えて、アプリケーションは、課税ドメインまたは他の事業もしくは社会的基準などの戦略的な理由で他のリージョンに展開されることができる。

ある実施形態に従うと、コンパートメントにより、クライアントは、クラウドリソースを編成し、それに対するアクセスを制御することが可能になる。コンパートメントは、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりである。コンパートメントは、物理的なコンテナではなく、論理的なグループと考えることができる。コンソール内で作業するとき、コンパートメントは、見られることを可能にされるものについてのフィルタとして作用することができる。

ある実施形態に従うと、コンパートメントは、階層的に配置されたいくつかの層またはレベルを有することができる。例えば、テナンシ６０５は、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。コンパートメントは、コンパートメント６６０がテナンシコンパートメントの下のレベルであり、サブコンパートメント６７０がコンパートメント６６０の下の追加の層であるように、階層的態様で編成することができる。ある実施形態に従うと、各コンパートメントは、テナンシリソース割り当て６８０（すなわち、上述したサービス制限）、コンパートメントリソース割り当て６８２、およびサブコンパートメントリソース割り当て６８４など、１つ以上のコンパートメントリソース割り当てに関連付けることができる。

ある実施形態によると、コンパートメント６６０およびサブコンパートメント６７０等のコンパートメントまたはサブコンパートメントの作成中、作成時、または作成後に、各対応するコンパートメントリソース割り当ては、例えば、コンソール６０３を介して生成されることができる。

ある実施形態に従うと、コンパートメントの階層的性質により、コンパートメントリソース割り当てセットをルート／ベースレベルコンパートメントに設定することができる。管理者（ルートコンパートメント内のリソース割り当てを管理および作成するのに充分なアクセスレベルを有する）は、ルートコンパートメントおよび任意のネスト化されたコンパートメントまたは「子」コンパートメントに割り当てを設定することができる。親／ルートコンパートメントに設定されたコンパートメントリソース割り当ては、子コンパートメントに設定されたコンパートメントリソース割り当てをオーバーライドする。このようにして、親コンパートメントの管理者は、子コンパートメント上に、子によってオーバーライドすることができない割り当てを作成することができる。

ある実施形態に従うと、割り当ては、異なるスコープを有し、可用性ドメイン、リージョンで、またはグローバルに働くことができる。コンパートメント割り当てで作業するときのスコープについて理解するためのいくつかの重要な事柄がある。可用性ドメイン（ＡＤ）レベルで割り当てを設定する場合、割り当ては各ＡＤに割り当てられる。したがって、例えば、コンパートメント上に２×７のＶＭの割り当てを設定することは、実際にはＡＤ当たり２ＶＭの限度を設定する。割り当ては、特定のＡＤをターゲットとするような方法で書くことができる。同様に、リージョナルな割り当てを、各リージョンに適用することができる。例えば、コンパートメントに１０個の機能の割り当てが設定されている場合、リージョンごとに１０個の機能が割り当てられることになる。特定のリージョンをターゲットとするために、割り当ては、リージョンパラメータを使用することができる。

ある実施形態に従うと、コンパートメント割り当ての階層的性質により、（たとえばリソースの）使用、サブコンパートメントのリソース使用は、メインコンパートメントに向かうリソース使用としてカウントする。すなわち、例えば、３レベルコンパートメントネスト（親コンパートメント、子コンパートメント、孫コンパートメント）において、各コンパートメントおよびサブコンパートメントにコンパートメント割り当てポリシーがアタッチされている場合、孫コンパートメントによるリソース使用は、子コンパートメントおよび親コンパートメントの両方のコンパートメント割り当てに対してカウントする。

例えば、コンパートメントリソース割り当て６８２が、コンパートメント幅で、コンパートメント６６０がタイプＸの１０個の仮想マシンしか利用できないことを指定すると仮定する。サブコンパートメント６７０の作成時に、サブコンパートメントリソース割り当て６８４は、サブコンパートメント幅で、サブコンパートメント６７０がタイプＸの８つの仮想マシンしか利用できないことを指定する。次いで、サブコンパートメント６７０がタイプＸの仮想マシンの最大容量（すなわち８）を利用する場合、コンパートメント６６０およびその任意の他のサブコンパートメント（例えば、図に示されていないサブコンパートメント）は、タイプＸの追加の２つの仮想マシンのみを利用することができる。上記の例は、追加的に、テナンシリソース割り当て６８０（すなわち、サービス制限）に同様に適用される。

ある実施形態に従うと、これらのガイドラインに従ってコンパートメント割当てを評価することができる。ポリシー内では、割り当てステートメントを順番に評価することができ、後のステートメントは、同じリソースをターゲットとする、以前のステートメントに取って代わることができる。同じリソースに対して複数のポリシーが設定される場合、最も制限的なポリシーを適用することができる。サービス制限は常に割り当てよりも優先される。あるリソースについて、そのリソースに対するサービス制限を超える割り当てを指定することは可能であるが、そのサービス制限は依然として実施されることになる。

図７は、一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割当てをサポートするためのシステムを示す。

より具体的には、図７は、リージョン内におけるコンパートメント割り当ての作成／修正／削除後における異なるリージョンへのコンパートメント割り当ての複製を示す。

ある実施形態に従うと、上述したように、図１において上述したクラウドインフラストラクチャ環境７００のインスタンスは、クラウドインフラストラクチャリージョン７２０、７３０、７４０、７５０などの異なるリージョンにおいてホストされ得る。これらは、上述のように、コンソール７０３、ＳＤＫ、またはＡＰＩを介して、インターネット等のネットワーク７０２を介して顧客ネットワーク７０１によってアクセスされることができる。

ある実施形態に従うと、顧客ネットワーク７０１は、たとえば単一のコンピュータ、顧客コンピュータのネットワーク、または他のそのようなネットワークを含み得る。

ある実施形態に従うと、図には示されていないが、各クラウドインフラストラクチャリージョンはいくつかのサービスを含み得、各サービスは、管理サービス、計算サービス、ストレージサービス、エッジサービス、ネットワークサービス、および物理インフラストラクチャなどのいくつかのリソースを含む。

ある実施形態に従うと、クラウドインフラストラクチャは、リージョンおよび可用性ドメインにおいてホストされることができる。リージョンは、局所化された地理的エリアとすることができ、可用性ドメインは、リージョン内に位置する１つ以上のデータセンターとすることができる。リージョンは、１つ以上の可用性ドメインから構成される。大抵のクラウドインフラストラクチャリソースは、仮想クラウドネットワークなどのリージョン固有であるか、または計算インスタンスなどの可用性ドメイン固有のいずれかであり得る。可用性ドメイン間およびリージョン間のトラフィックは暗号化される。

ある実施形態に従うと、可用性ドメインは、互いに隔離され、フォールトトレラントであり、障害が同時に生ずる可能性が非常に低い。可用性ドメインは、電力もしくは冷却などのインフラストラクチャ、または内部可用性ドメインネットワークを共有しないので、リージョン内の１つの可用性ドメインにおける障害は、同じリージョン内の他のものの可用性に影響を及ぼす可能性が低い。

ある実施形態に従うと、同じリージョン内の可用性ドメインを低レイテンシの広帯域幅ネットワークによって互いに接続することができ、これにより、インターネットおよびオンプレミスへの高可用性接続性を提供し、高可用性および災害復旧の両方のために複数の可用性ドメインにおいて複製されたシステムを構築することができる。

ある実施形態に従うと、リージョンは他のリージョンから独立しており、地理的に（たとえば国または大陸にわたって）分離されることができる。これは、次いで、あるアプリケーションが最も頻繁に利用される可能性が最も高いリージョン内における当該アプリケーションの展開につながる。

しかしながら、ある実施形態に従うと、アプリケーションは、さまざまな理由により、異なるリージョンにおいて展開されもし得る。これは、例えば、気象システムなどのイベントがリージョンをオフラインで取るときのリスク軽減を含むことができる。加えて、アプリケーションは、課税ドメインまたは他の事業もしくは社会的基準などの戦略的な理由で他のリージョンに展開されることができる。

ある実施形態に従うと、コンパートメントにより、クライアントは、クラウドリソースを編成し、それに対するアクセスを制御することが可能になる。コンパートメントは、管理者によって許可が与えられた特定のグループによってのみアクセスされ得る関連リソース（インスタンス、仮想クラウドネットワーク、ブロックボリュームなど）の集まりである。コンパートメントは、物理的なコンテナではなく、論理的なグループと考えることができる。コンソール内で作業するとき、コンパートメントは、見られることを可能にされるものについてのフィルタとして作用することができる。

ある実施形態に従うと、コンパートメントは、階層的に配置されたいくつかの層またはレベルを有することができる。例えば、テナンシ７０５は、クライアントのクラウドリソースのすべてを保持するルートコンパートメントと見なすことができる。コンパートメントは、コンパートメント７６０がテナンシコンパートメントの下のレベルであり、サブコンパートメント７７０がコンパートメント７６０の下の追加の層であるように、階層的態様で編成することができる。ある実施形態に従うと、各コンパートメントは、テナンシリソース割り当て７８０（すなわち、上述したサービス制限）、コンパートメントリソース割り当て７８２、およびサブコンパートメントリソース割り当て７８４など、１つ以上のコンパートメントリソース割り当てに関連付けることができる。

ある実施形態によると、コンパートメント７６０およびサブコンパートメント７７０等のコンパートメントまたはサブコンパートメントの作成中、作成時、または作成後に、各対応するコンパートメントリソース割り当ては、例えば、コンソール７０３を介して生成されることができる。

ある実施形態に従うと、コンパートメントの階層的性質により、コンパートメントリソース割り当てセットをルート／ベースレベルコンパートメントに設定することができる。管理者（ルートコンパートメント内のリソース割り当てを管理および作成するのに充分なアクセスレベルを有する）は、ルートコンパートメントおよび任意のネスト化されたコンパートメントまたは「子」コンパートメントに割り当てを設定することができる。親／ルートコンパートメントに設定されたコンパートメントリソース割り当ては、子コンパートメントに設定されたコンパートメントリソース割り当てをオーバーライドする。このようにして、親コンパートメントの管理者は、子コンパートメント上に、子によってオーバーライドすることができない割り当てを作成することができる。

ある実施形態に従うと、割り当ては、異なるスコープを有し、可用性ドメイン、リージョンで、またはグローバルに働くことができる。コンパートメント割り当てで作業するときのスコープについて理解するためのいくつかの重要な事柄がある。可用性ドメイン（ＡＤ）レベルで割り当てを設定する場合、割り当ては各ＡＤに割り当てられる。したがって、例えば、コンパートメント上に２×７のＶＭの割り当てを設定することは、実際にはＡＤ当たり２ＶＭの限度を設定する。割り当ては、特定のＡＤをターゲットとするような方法で書くことができる。同様に、リージョナルな割り当てを、各リージョンに適用することができる。例えば、コンパートメントに１０個の機能の割り当てが設定されている場合、リージョンごとに１０個の機能が割り当てられることになる。特定のリージョンをターゲットとするために、割り当ては、リージョンパラメータを使用することができる。

ある実施形態に従うと、コンパートメント割り当ての階層的性質により、（たとえばリソースの）使用、サブコンパートメントのリソース使用は、メインコンパートメントに向かうリソース使用としてカウントする。すなわち、例えば、３レベルコンパートメントネスト（親コンパートメント、子コンパートメント、孫コンパートメント）において、各コンパートメントおよびサブコンパートメントにコンパートメント割り当てポリシーがアタッチされている場合、孫コンパートメントによるリソース使用は、子コンパートメントおよび親コンパートメントの両方のコンパートメント割り当てに対してカウントする。

ある実施形態に従うと、割り当ては、単一のリージョンにおいて集中的に管理し、グローバルに複製することができる。これは、割り当てを管理するために必要とされる労力を低減する。例えば、図７を見ると、サブコンパートメントリソース割り当てポリシー７８４およびコンパートメントリソース割り当て７８２は、まず、リージョン７２０内で定義されることができる。作成されると、リソース割り当て７８２および７８４の各々は、リージョン７３０，７４０，および７５０に複製され得る。そのような複製は、割り当てポリシーを各データセンター内の割り当てデータプレーンにグローバルに複製する非同期プロセスであり得る。

ある実施形態に従うと、コンパートメント割り当ては、個々のサービスを完全にオフにする能力を提供する。同様に、リソースコンパートメントの階層に亘ってリソース使用を計算するためのアルゴリズムが提供される。割り当ては、いくつかの主要な構成要素、すなわち、割り当てユーザインターフェイス、割り当て制御プレーン、割り当てデータプレーン、および割り当てクライアントＳＤＫから成り得る。

ある実施形態に従うと、管理者は、ユーザインターフェイスを介してコンパートメント割り当てポリシーを管理することができ、ユーザインターフェイスは、シーンの背後で、ポリシーが記憶される割り当て制御プレーンを呼び出す。非同期プロセスは、各データセンター内の割り当てデータプレーンにデータをグローバルに複製する。他のクラウドサービスは、サービスの永続的ストレージ層から使用データを、および割り当てデータプレーンから割り当て値をフェッチすることができる、クライアントＳＤＫと統合する。そして、リソースの作成を許可するか否かの判断を行う。

ある実施形態に従うと、コンパートメント割り当てを開始するために設定可能ないくつかの条件がある。これらは、以下を含むが、それらに限定はされない：コンパートメントレベルリソース割り当てを作成／更新／削除／リスト化する；コンパートメントリソース使用を閲覧すること；コンパートメント割り当ては、すべてのリージョン／ＡＤに適用されるようにグローバルに設定することができる；リージョン／ＡＤ固有コンパートメント割り当てを設定し、グローバルに定義された割り当てをオーバーライドすることができる；コンパートメント割り当ては、適用可能な場合、既存のサービス割り当てに対応することができる；コンパートメント割り当ての設定および閲覧は、コンソールを通して可能であり得る；各それぞれの制御プレーンによって割り当てを厳密に実施することができる；割り当てを設定することは、現在のリソースカウントまたは親コンパートメント値に基づいて失敗するべきではない；コアサービス計算、ＤＢａａＳ（サービスとしてのデータベース）およびブロックストレージと統合する；get/list動作に対する強力な書き込み後読み出し整合性を達成する；オンボードできないチームに対して無料でゼロ割り当てを実施する能力；ポリシーを介した宣言的割り当てステートメント；ならびにホワイトリストまたはブラックリストのいずれかとして作用する（すなわち、割り当てによって設定されないすべてを拒否するかまたは許可する）コンパートメント割り当てを定義する。

ある実施形態に従うと、制御プレーンを拡張して、コンパートメントリソース制限をサポートすることができる。

図８は、一実施形態による、コンパートメント割り当てを作成するための方法のフローチャートである。

ある実施形態によると、コンソール８００は、コンパートメント割り当てを作成する、テナント対話のユーザを示す命令を受信すると、コンソールは、ＡＰＩを介して、コンパートメント割り当てを作成するよう、（例えば、テナントの本拠リージョン内において）制限制御プレーン８０５を呼び出すことができる。

ある実施形態に従うと、呼び出しは、コンパートメント割り当てが向けられるコンパートメントＩＤを含み得る。

ある実施形態に従うと、制限制御プレーン８０５は、（例えば、テナントの本拠リージョン内で）アイデンティティデータプレーン８１０と通信することができる。通信は、ターゲットコンパートメントのコンパートメントＩＤを含むことができ、制限制御プレーンは、ターゲットとされたコンパートメントと関連付けられるテナントを要求することができる。アイデンティティ制御プレーンは、テナントを返すことができる。

ある実施形態に従うと、テナントを受信すると、制限制御プレーンは、コンパートメント割り当てを作成する要求が充分に承認されている（例えば、テナントのユーザは、ターゲットとされたコンパートメント上でそのようなコンパートメント割り当てをインスタンス化するのに充分な許可を有する）かどうかを調べることができる。制限制御プレーンは、アイデンティティ制御プレーンと再び通信することによって、これを行うことができる。

ある実施形態に従うと、要求が承認されると判定すると、制限制御プレーンは、（例えば、テナントの本拠リージョン内において）データベース８１５（たとえばKiev）内に割り当てエンティティを作成することができる。次いで、コンパートメント割り当ての成功裏の作成をコンソールに返すことができる。

ある実施形態に従うと、データベース８１５は、テナント（または複数のテナント）に関連付けられるすべての割り当てを記憶するように構成されることができ、そして記憶することができる。すなわち、例えば、（テナンシ全体に適用される）両方のサービスレベル制限、および複数のコンパートメントレベル割り当ての各々は、完全な制限が１つのテナントによって所有される状態で、１つのデータベース（例えば、Kiev）に記憶され得る。

図９は、一実施形態による、コンパートメント割り当てを修正するための方法のフローチャートである。

ある実施形態に従うと、コンソール９００は、コンパートメント割り当てを取得、更新、または削除するよう、テナント対話のユーザを示す命令を受け取ると、データベース９１５を呼び出して、要求に含まれる割り当てＩＤによって、要求されたターゲットとされたコンパートメント割り当てを取得することができる。

ある実施形態に従うと、呼び出しは、割り当ての取得／更新／削除動作が向けられる割り当てＩＤを含み得る。

ある実施形態に従うと、制限制御プレーン９０５は、（例えば、テナントの本拠リージョン内で）アイデンティティデータプレーン９１０と通信することができる。通信は、ターゲットコンパートメントのコンパートメントＩＤを含むことができ、制限制御プレーンは、ターゲットとされたコンパートメントと関連付けられるテナントを要求することができる。アイデンティティ制御プレーンは、テナントを返すことができる。

ある実施形態に従うと、テナントを受信すると、制限制御プレーンは、コンパートメント割り当てを作成する要求が充分に承認されている（例えば、テナントのユーザは、ターゲットとされたコンパートメント上でそのようなコンパートメント割り当てをインスタンス化するのに充分な許可を有する）かどうかを調べることができる。制限制御プレーンは、アイデンティティ制御プレーンと再び通信することによって、これを行うことができる。

ある実施形態に従うと、要求が承認されると判定すると、制限制御プレーンは、（例えば、テナントの本拠リージョン内において）データベース９１５（たとえばKiev）内においてコンパートメント割り当てを取得／更新／削除することができる。次いで、コンパートメント割り当ての成功裏の作成をコンソールに返すことができる。

ある実施形態に従うと、データベース８１５は、テナント（または複数のテナント）に関連付けられるすべての割り当てを記憶するように構成されることができ、そして記憶することができる。すなわち、例えば、（テナンシ全体に適用される）両方のサービスレベル制限、および複数のコンパートメントレベル割り当ての各々は、完全な制限が１つのテナントによって所有される状態で、１つのデータベース（例えば、Kiev）に記憶され得る。

図１０は、一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割り当てを実施するためのシステムのためのアーキテクチャを示す。

ある実施形態に従うと、図１０は、１つ以上のコンパートメントリソース割り当てに対するチェックを必要とするインスタンスを起動するユーザに関するアーキテクチャフローを示す。

ある実施形態に従うと、ステップ１において、たとえばユーザ１００１から命令を受け取ることができる。命令は、リージョン１０００内のインスタンスを起動する要求を示すことができ、要求は、リージョン内において、あるコンパートメントを指定する。

ある実施形態に従うと、ステップ２において、ロードバランサ１０２０（たとえばFlamingo）は、パブリックＡＰＩプロキシのようなＡＰＩに要求を転送することができる。

ある実施形態に従うと、ステップ３において、ＡＰＩは、アイデンティティデータプレーン１０３５において認証を実行することができる。そのような認証ステップは、ユーザが正しいクレデンシャル（例えば、ユーザ名およびパスワードなどのユーザクレデンシャル、ワンタイムパスワード、または他の認証方法）を有することと、ユーザ１００１がターゲットとされたコンパートメント内のインスタンスの要求された起動を実行するのにリージョン内で充分な承認を有することとの両方をチェックすることができる。例えば、ユーザ１００１が、ターゲットとされたコンパートメントでインスタンスを起動するのに充分な承認を有していない場合（例えば、ユーザ１００１は、ターゲットとされたコンパートメントの子コンパートメントで同様のインスタンスを起動する承認のみを有する場合）、ＡＰＩ１０２５は要求を拒否することができる。ユーザが充分な承認を有する場合、ＡＰＩは、要求を進めることを可能にすることができる。

ある実施形態に従うと、ステップ４において、インスタンスを起動する要求は、計算制御プレーン（ＣＣＰ）１０３０に転送することができる。次いで、ＣＣＰは、ステップ５において、アイデンティティデータプレーンにおいて要求をさらに認証することができる。

ある実施形態に従うと、ステップ６において、計算制御プレーンは、アイデンティティデータプレーン１０３５を呼び出して、要求が向けられるコンパートメントに関連付けられるコンパートメントツリー、または要求が向けられるテナンシ全体のコンパートメントツリーをフェッチすることができる。

ある実施形態に従うと、ステップ７において、計算制御プレーンは、コンパートメント割り当てマップ１０４１を含む制限サービスデータプレーン１０４０から、テナンシまたはコンパートメントツリーのすべてのコンパートメント割り当てをフェッチすることができる。これは、要求が向けられる特定のコンパートメントについてのある数のコンパートメント割り当て、およびその特定のコンパートメントの上方のツリー全体についてのコンパートメント割り当てを含むことができる。

ある実施形態に従うと、ステップ８において、計算制御プレーンは、コンパートメントに対するリソース使用をデータベース１０４５から取得することができるとともに、要求された使用が、要求が向けられる特定のコンパートメントを含むツリーに沿った任意のコンパートメントに対するコンパートメントの割り当てのいずれかに違反するかどうかをチェックすることができる。要求された使用がいかなるコンパートメント割り当てにも違反しない場合、要求を処理することができる。要求された使用がコンパートメントツリーに沿ったコンパートメント割り当てのいずれかに違反する場合、要求はドロップされ得、ユーザに通知すべくメッセージが送信され得る。

ある実施形態に従うと、コンパートメント割り当ては、テナンシ内の特定のコンパートメントに適用される。コンパートメントツリーがすべての関連付けられるコンパートメント割り当てとともにフェッチされると、ＣＣＰは使用を取得し、要求に基づいて使用を更新することができる。データベースから、ステップ８の一部として、ＣＣＰは、各コンパートメントにおける実際の使用を得ることができる。コンパートメントテナンシ全体について、ＣＣＰは、各コンパートメントＩＤをある数のカウント（使用）にマッピングすることができる。次いで、ＣＣＰは、コンパートメントツリーレイアウト全体および存在する割り当てをマッピングすることができる。次いで、ＣＣＰは、新たな要求が割り当てのいずれにも違反しないことを保証することができる。要求が割り当てを超える場合、ＣＣＰは要求を落とすことができる。

図１１は、一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割当てをサポートする方法のフローチャートである。

ある実施形態に従うと、ステップ１１１０において、本方法は、１つ以上のマイクロプロセッサを含むコンピュータを提供することができる。

ある実施形態に従うと、ステップ１１２０において、本方法は、コンピュータにおいてクラウドインフラストラクチャ環境を提供することができ、クラウドインフラストラクチャ環境は複数のリージョンを含み、複数のリージョン内でテナンシが定義される。

ある実施形態に従うと、ステップ１１３０において、本方法は、テナンシの複数のコンパートメントを提供することができる。

ある実施形態に従うと、ステップ１１４０において、本方法は、クラウドインフラストラクチャ環境内において、複数のコンパートメントリソース割り当てを記憶するデータベースへのアクセスを有する制限サービスデータプレーンを提供することができる。

ある実施形態によると、ステップ１１５０では、本方法は、複数のコンパートメントリソース割り当てのうちのあるコンパートメントリソース割り当てを複数のコンパートメントのうちのあるコンパートメントと関連付けることができ、コンパートメントリソース割り当ては、コンパートメント内の少なくとも１つのタイプのリソースを制限する。

ある実施形態に従うと、ステップ１１６０において、本方法は、コンパートメントにおいてリソースがプロビジョニングされるよう求める要求を受信することができ、要求されたリソースは、リソース割り当てによって制限されたタイプのリソースである。

ある実施形態に従うと、ステップ１１７０において、本方法は、要求されたリソースのプロビジョニングがコンパートメントリソース割り当てに違反するかどうかを判断することができる。

ある実施形態に従うと、ステップ１１８０において、本方法は、コンパートメントリソース割り当てに違反しないとの判定に基づいて、要求されたリソースをプロビジョニングすることができる。

ある実施形態に従うと、ステップ１１９０において、本方法は、コンパートメントリソース割り当てに違反するとの判定に基づいて、要求に対する異議を唱えることができる。

割り当てポリシー言語
ある実施形態に従うと、上記のように、クラウドインフラストラクチャ環境は、顧客がコンパートメント上にリソース割り当てを設定する能力を提供することができる。割り当ては、クラウドインフラストラクチャ環境によってではなく、顧客によって、顧客自身の使用を制限するように設定されることを除いて、既存のサービス制限のように働く。サービスチームは、これらの割り当てをそれらの制御プレーンにおいてチェックし、割り当てを超える要求を厳しくブロックすることができる。割り当ては、記憶され、制限サービスからアクセスされ、コンソールまたはＲＥＳＴ ＡＰＩを介してクライアントによって設定され得る。加えて、クラウドインフラストラクチャ環境は、そのようなコンパートメント割り当ての作成に使用される、宣言的であり人間可読割り当てポリシー言語をサポートすることができる。

ある実施形態に従うと、コンパートメントリソース割り当ては、たとえばアイデンティティポリシーを書き込むのと同様に設定することができる。両方ともコンパートメント内に生きており、異なるコンパートメントをターゲットとするように書くことができる。リソース割り当てはまた、たとえば、リージョン、可用性ドメイン、および重複など、適用され得る条件のセットに関連付けられ得る。

ある実施形態に従うと、リソース割り当ては、ステートメントシンタックスを設定することによって構成することができる。割り当てを設定するために、割り当ては、いくつかの要素を確立することができる。各割り当ては、サービスファミリー（例えば、計算）内で一意であり得、したがって、各割り当ては、割り当て名とともにターゲットサービスを定義することができる。次に、割り当ては、割り当てを設定する値、および割り当てがターゲットとするコンパートメントを定義することができる。最後に、この割り当てがいつ適用されるかを決定するために含めることができる条件のセットがある。

ある実施形態に従うと、コンパートメント割り当てポリシーは、表現的な人間可読ポリシー言語を用いて記述することができる。ポリシー言語は、ステートメントオーバーライドを通じてホワイトリストまたはブラックリストリソース使用の両方の能力を含む豊富な表現性を可能にする。ホワイトリストは、明示的に拒否されるリソースを除いて、すべてのリソースが作成されることを可能にする。ブラックリストは、明示的に許可されるリソースを除いて、リソースが作成されることを可能にしない。

ある実施形態に従うと、コンパートメント割り当ては、単純な宣言型言語で書かれたポリシーステートメントを用いて設定することができる。一般に、３つのタイプの割り当てポリシーステートメントがある：１）設定－コンパートメントに使用できるクラウドリソースの最大数を設定する；２）未設定－割り当てをデフォルトサービス制限に戻すようにリセットする；３）ゼロ－コンパートメントについてクラウドリソースへのアクセスを除去する。

図１２ａ、図１２ｂ、および図１２ｃは、ある実施形態に係る、例示的なコンパートメント割り当てポリシーステートメントである。

図１２ａは、ある実施形態に係る、設定された割り当てポリシーを示す。
図１２ｂは、ある実施形態に係る、未設定の割り当てポリシーを示す。

図１２ｃは、ある実施形態に係る、ゼロ割り当てポリシーを示す。
ある実施形態に従うと、各割り当てポリシーステートメントの言語コンポーネントは、以下のコンポーネントを含む：１）アクションキーワード－アクションキーワードは、定義されている割り当てのタイプに対応することができる。これは、例えば、設定、未設定、またはゼロとすることができる；２）サービスファミリーの名前。これは、例えば、計算とすることができる；３）割り当てまたは割り当てキーワード；４）サービスファミリーによって異なる割り当ての名前。例えば、計算ファミリーにおける有効な割り当ては、「vm-standard2-16-count」であり得る。加えて、ワイルドカードを用いて、名前の範囲を指定することができる。例えば、「/vm-*/」は、文字「vm」で始まるすべての計算シェイプと一致する；５）割り当ての値を設定する「for」設定ステートメント；６）および割り当てがカバーするコンパートメント；７）任意選択の条件を提供することもできる。例えば、request.region = 'us-phoenix-1’である。そのような条件は、request.regionおよびrequest.adを含むことができる。

図１３は、ある実施形態に係る、割り当てポリシーステートメントの例を示す図である。

ある実施形態に従うと、図１３のステートメントは設定された（set）１３０１ステートメントであり、これはファミリー（family）１３０２に適用される。割り当て（quota）１３０３は、名前（name）１３０４（例えば、リソース）に適用され、割り当ては、それを、値（value）１３０６に（to）１３０５に設定する。割り当ては、ある位置（location）１３０８に（in）１３０７に適用され得、次いで、条件（conditions）１３０９も同様に設定され得る。

ある実施形態に従うと、いくつかの例示的な割り当てポリシーステートメントが以下で提供され、各割り当てポリシーの説明とともにいくつかの例が以下に提供される。

ある実施形態に従うと、割り当てポリシーは以下のとおりである：
Set compute quotas to 0 in compartment My Compartment
（コンパートメントMy Compartmentにおいて計算割り当てを０に設定する）
実施形態によれば、上記の割り当てポリシーは、「MyCompartment」においてすべての計算割り当てを０に設定し、それによって、いかなるさらなるリソースも作成されないようにする。

ある実施形態に従うと、割り当てポリシーは以下のとおりである：
Set block-storage quota ‘volume-count’ to 10 in compartment My Compartment
（コンパートメントMy Compartmentにおいてブロック－ストレージ割り当て「ボリュームカウント」を１０に設定する）
ある実施形態に従うと、上記の割り当てポリシーは、「My Compartment」において、ボリュームカウントに対するブロックストレージ割り当てを１０に設定するであろう。

ある実施形態に従うと、割り当てポリシーは以下のとおりである：
Set compute quota ‘VM.Dense101.16’ to 10 in compartment MyCompartment where request.region = ‘phx’
（コンパートメントMy Compartmentにおいて計算割り当て「VM.Dense101.16」を１０に設定し、ここで、request.region = 'phx'である）
ある実施形態に従うと、上記の割り当てポリシーは、VM.DenseIO1.16 計算シェイプについての割り当てを、ＰＨＸにおいて、「My Compartment」において、１０に設定するであろう。

ある実施形態に従うと、割り当てポリシーは以下のとおりである：
Set compute quota /VM.*/ to 10 in compartment MyCompartment
（コンパートメントMy Compartmentにおいて計算割り当て/VM.*/ を１０に設定する）
ある実施形態に従うと、ワイルドカード表現を用いて、多くの名前を一度にマッチさせることもできる。上記の割り当てポリシーは、各ＶＭシェイプに対する割り当てを１０に設定し、組み合わされた割り当てを１０には設定しない。

ある実施形態に従うと、割り当てポリシーフォーマットは、割り当てファミリーの仕様を、オプションの名前または名前のリストとともに要求することができる。

ある実施形態に従うと、割り当て位置１００８は、割り当てが適用されるターゲットコンパートメントを含み得る。これは、割り当てが存在するコンパートメントとは異なることが多く、その子孫であり得る。割り当て位置は、ルートコンパートメントを特定することと等価である「テナンシ」でもあり得る。

ある実施形態に従うと、割り当てポリシーステートメントの別の例はゼロステートメントである。

図１４は、ある実施形態に係る、割り当てポリシーステートメントの例を示す。
ある実施形態に従うと、図１４のステートメントは、ファミリー１４０２に適用されるゼロ（zero）１４０１ステートメントである。割り当て（quota）１４０３は、名前（name）１４０４（例えば、リソース）に適用される。ゼロ割り当ては、ある位置（location）１４０６に（in）１４０５適用され得、次いで、条件（conditions）１４０７も同様に設定され得る。

ある実施形態に従うと、いくつかの例示的な割り当てポリシーステートメントが以下で提供され、各割り当てポリシーの説明とともにいくつかの例が以下に提供される。

ある実施形態に従うと、割り当てポリシーは以下のとおりである：
Zero compute quota ‘VMStandard2.32’ in compartment MyCompartmen
（コンパートメントMyCompartmentにおいて計算割り当て'VMStandard2.32'をゼロにする）
ある実施形態に従うと、上記の割り当てポリシーステートメントは、MyCompartmentにおけるＶＭ標準２．３２インスタンスタイプに当てはまる。この割り当てが設定されると、ユーザは、そのコンパートメント内でこれらのインスタンス（例えば、ＶＭ標準２．３２）のいずれも起動することはできないであろう。

ある実施形態に従うと、割り当てポリシー言語は、ホワイトリストをさらにサポートすることができる。言い換えれば、ファミリー内のすべての割り当てを０に設定し、これの上に明示的にリソースを割り当てる。これは、単純なステートメント優先順位ルールを確立することによって実現されることができ、すなわち、２つ以上のステートメントが同じポリシー内で真であると評価する場合、セット内の最後のステートメントが制御することになる。

ある実施形態に従うと、ホワイトリストをサポートするためにどのように優先順位が働くかを調べるために、以下の２つの割り当てポリシーを考える。
Zero compute quotas in tenancy
（テナンシにおいて計算割り当てをゼロにする）
Set compute quota 'VM.DenseIO1.16' to 10 in tenancy
（テナンシにおいて計算割り当て'VM.DenseIO1.16'を１０に設定する）
ある実施形態に従うと、すべての計算割り当てを０に削減するベースステートメントを書くことができる。これに加えて、１０まで許可したいVM.DenseIO1.16に対して第２のステートメントを書くことができる。重要なことに、このオーバーライドは、同じポリシーで書かれたステートメントにのみ適用される。異なるポリシーからのステートメント間には優先順位はなく、それらはすべて満足されなければならない。これは、子コンパートメント管理者が親コンパートメント内の割り当てをオーバーライドすることを不可能にする。管理者は、子コンパートメント管理者に子の「全リソース管理」を安全に与え、適切な割り当てを維持することができる。子コンパートメント管理者は、親コンパートメント内に既に存在している割り当てをさらに低減することしかできない。

ある実施形態に従うと、割り当てポリシーステートメントの別の例は未設定ステートメントである。図１５は、ある実施形態に係る、割り当てポリシーステートメントの例を示す。

ある実施形態に従うと、図１５のステートメントは未設定（unset）ステートメント１５０１であり、これはファミリー（family）１５０２に適用される。割り当て（quota）１５０３は、ある位置（location）１５０６において（in）１５０５、オプションの条件（conditions）１５０７とともに、名前（name）１５０４（例えば、リソース）に未設定である。

ある実施形態に従うと、優先順位に関して上記の例を再度行うと、VM DenseIO1.16上に割り当てが存在しないように、第２の割り当てポリシーを未設定にすることができる。
Zero compute quotas in tenancy
（テナンシにおいて計算割り当てをゼロにする）
Unset compute quota 'VM.DenseIO1.16' to 10 in tenancy
（テナンシにおいて１０への計算割り当て'VM.DenseIO1.16'を未設定とする）
ある実施形態に従うと、前の例と同様に、未設定は異なる割り当てポリシーに亘って機能しない。

ある実施形態に従うと、各サービスの制御プレーン内には、データベーストランザクションがオープンのままであるクリティカルセクション（たとえば時間）がある。この期間が長くなるほど、競合および障害が忍び込み始める。この起こり得る問題を最小限に抑えるために、約５ミリ秒の範囲で割り当てポリシーを考慮し、適用することができる。

ある実施形態に従うと、上述したように、コンパートメントレベルで割り当てを施行することができる。このため、ユーザ、グループおよびタグなどの、コンパートメント内の追加のエンティティに割り当てを設定するよう、割り当てをさらに指定することができる。例えば、以下の割り当てステートメントを考える：
Set compute quota 'VM.DenseIO1.16' to 20 in tenancy where request.user
=
ocid1.user.dev..aaaaaaaan4xh2xpvzcmabc5m7pd7ioaovc2ktt56fvbhfy77y4v
（テナンシにおいて計算割り当て'VM.DenseIO1.16'を２０に設定し、request.user = ocid1.user.dev..aaaaaaaan4xh2xpvzcmabc5m7pd7ioaovc2ktt56fvbhfy77y4vである）
上記は、割り当てがユーザ上に部分的に置かれることを可能にするが、割り当てはユーザではなくコンパートメント上にあるので、ユーザが２０のインスタンスを得ることを保証しない。代わりに、現在のコンパートメント使用にかかわらず、ユーザのために割り当てを設定する割り当てが指定され得る。

図１６は、ある実施形態に係る、割り当てポリシーステートメントの例を示す。
より具体的には、図１６は、スコープをさらに含む割り当てポリシーステートメントを示す。

ある実施形態に従うと、図１６のステートメントは設定された（set）１６０１ステートメントであり、これはファミリー（family）１６０２に適用される。割り当て（quota）１６０３は、名前（name）１６０４（例えば、リソース）に適用され、割り当ては、それを、値（value）１６０６に（to）１６０５設定する。割り当ては、位置（location）１６１０において（in）１６０９、スコープ（scope）１６０８に対して（for）１６０７適用され得、その場合（where）１６１１、条件（conditions）１６１２も同様に設定され得る。上記のコンパートメント割り当てを取り、図１６のステートメント言語を用いてそれを書き直すと、割り当てポリシーは以下のようになる：
Set compute quota 'VM.DenseIO1.16' to 10 for user MyUser in tenancy
（テナンシにおいてユーザMyUserに対して計算割り当て 'VM.DenseIO1.16' を10に設定する）
ある実施形態に従うと、割り当てポリシー言語は、この割り当てがコンパートメントではなくMyUserに適用されることを明確に表現する。これは、コンパートメント割り当てとは完全に別個の割り当てであり、リソースを作成するときにすべての割り当てスコープ（上記の割り当てポリシーおよび任意のコンパートメント割り当てポリシーの両方）を満たす必要がある。

図１７は、ある実施形態に係る、割り当てポリシーステートメントの例を示す。
より具体的には、図１７は、オーバーライド割り当てポリシーを示す。

ある実施形態に従うと、コンパートメント割り当てに関連付けられる優先順位ルールは、あるポリシーにおけるステートメントが異なるポリシーからのステートメントをオーバーライドすることを許容しない。これは、ホワイトリストを実現するために、システムおよび方法は、単一のポリシーにおけるステートメントの最大数によって制限されることを意味する。これに対処するために、明示的なオーバーライドステートメントを利用することができる。このステートメントは、あるポリシーが別のポリシーよりも優先されることを確立する。これは、ステートメントを１つの長いポリシーの一部として一緒に書き込んだことと等価である。オーバーライドステートメントを適用するために、ポリシーは同じコンパートメントにおいて生きていなければならない。

一実施形態によれば、オーバーライドステートメントは、オーバーライドステートメント１７００、override１７０１、一つ以上の他のquatas１７０３、in１７０４、policy１７０４，およびname１７０５を含むことができる。

ある実施形態に従うと、以下のオーバーライドステートメントを考える：
Override quotas in policy BasePolicy
（ポリシー「ベースポリシー」において割り当てをオーバーライドする）
ある実施形態に従うと、上記オーバーライドステートメントは、このポリシーにおける任意のステートメントがベースポリシーにおけるステートメントをオーバーライドすることを規定する。なお、オーバーライドは推移的である。ａがｂをオーバーライドし、ｂがｃをオーバーライドする場合、ａはｃをオーバーライドする。

図１８は、ある実施形態に係る、クラウドインフラストラクチャ環境において割り当てポリシー言語をサポートするための方法のフローチャートである。

ある実施形態に従うと、ステップ１８１０において、本方法は、１つ以上のマイクロプロセッサを含むコンピュータを提供することができる。

ある実施形態に従うと、ステップ１８２０において、本方法は、複数のリージョンを含むクラウドインフラストラクチャ環境を提供することができ、テナンシが複数のリージョン内で定義される。

ある実施形態に従うと、ステップ１８３０において、本方法は、テナンシの複数のコンパートメントを提供することができる。

ある実施形態によると、ステップ１８４０において、本方法は、命令を示す入力を受信するように適合されるコンソールインターフェイスを提供することができる。

ある実施形態に従うと、ステップ１８５０において、本方法は、クラウドインフラストラクチャ環境内において、複数のコンパートメントリソース割り当てを記憶するデータベースへのアクセスを有する制限サービスデータプレーンを提供することができる。

ある実施形態に従うと、ステップ１８６０において、本方法は、テナンシのコンパートメントを、複数のコンパートメント割り当てのうちのあるコンパートメント割り当てと関連付けることができる。

ある実施形態に従うと、ステップ１８７０において、本方法は、割り当てポリシーを、設定ポリシー、未設定ポリシー、またはゼロ割り当てポリシーのうちの１つとなるように構成することができる。

使用計算プロセス（アルゴリズム）
ある実施形態に従うと、システムおよび方法は、使用計算プロセスまたはアルゴリズムをサポートして、要求されたトランザクションがコンパートメントに関する何らかの制限または割り当てに違反するかどうかを判断することができる。

ある実施形態に従うと、使用計算方法は、割り当てまたは制限を評価することと、コンパートメントあたりのリソースをカウントすることとの両方のために、ＳＤＫを提供することができる。

ある実施形態に従うと、このプロセスは、クラウドインフラストラクチャ環境内においていくつかのシステムおよびサブシステムに分散させることができる。

ある実施形態に従うと、図１０は、１つ以上のコンパートメントリソース割り当てに対するチェックを必要とするインスタンスを起動するユーザについてのアーキテクチャフローを示す。

図１９は、一実施形態による、クラウドインフラストラクチャ環境においてコンパートメント割り当てを実施するためのシステムのためのアーキテクチャを示す。

ある実施形態に従うと、ステップ１において、たとえばユーザ１９０１から命令を受け取ることができる。命令は、リージョン１９００内のインスタンスを起動する要求を示すことができ、要求は、リージョン内において、あるコンパートメントを指定する。

ある実施形態に従うと、ステップ２において、ロードバランサ１９２０（たとえばFlamingo）は、パブリックＡＰＩプロキシのようなＡＰＩに要求を転送することができる。

ある実施形態に従うと、ステップ３において、ＡＰＩは、アイデンティティデータプレーン１９３５において認証を実行することができる。そのような認証ステップは、ユーザが正しいクレデンシャル（例えば、ユーザ名およびパスワードなどのユーザクレデンシャル、ワンタイムパスワード、または他の認証方法）を有することと、ユーザ１９０１がターゲットとされたコンパートメント内のインスタンスの要求された起動を実行するのにリージョン内で充分な承認を有することとの両方をチェックすることができる。例えば、ユーザ１９０１がターゲットとされたコンパートメントでインスタンスを起動するのに充分な承認を有していない場合（例えば、ユーザ１９０１は、ターゲットとされたコンパートメントの子コンパートメントで同様のインスタンスを起動する承認のみを有する場合）、ＡＰＩ１９２５は要求を拒否することができる。ユーザが充分な承認を有する場合、ＡＰＩは、要求を進めることを可能にすることができる。

ある実施形態に従うと、ステップ４において、インスタンスを起動する要求は、計算制御プレーン（ＣＣＰ）１９３０に転送することができる。次いで、ＣＣＰは、ステップ５において、アイデンティティデータプレーンにおいて要求をさらに認証することができる。

ある実施形態に従うと、ステップ６において、計算制御プレーンは、アイデンティティデータプレーン１９３５を呼び出して、要求が向けられるコンパートメントに関連付けられるコンパートメントツリー、または要求が向けられるテナンシ全体のコンパートメントツリーをフェッチすることができる。

ある実施形態に従うと、ステップ７において、計算制御プレーンは、コンパートメント割り当てマップ１９４１を含む制限サービスデータプレーン１９４０から、テナンシまたはコンパートメントツリーのすべてのコンパートメント割り当てをフェッチすることができる。これは、要求が向けられる特定のコンパートメントについてのある数のコンパートメント割り当て、およびその特定のコンパートメントの上方のツリー全体についてのコンパートメント割り当てを含むことができる。

ある実施形態に従うと、ステップ８において、計算制御プレーンは、系統における各コンパートメントについての総使用を計算することができる。この総使用は、コンパートメントの使用と階層を再帰的に下る各子コンパートメントの総使用との合計に等しい。

ある実施形態に従うと、ＣＣＰ１９３０は、各制限／割り当てをそのコンパートメントの総使用と比較することができる。いずれかの制限／割り当てに違反する場合、ＣＣＰは、予想されるリソースがどの割り当ておよび／または制限を超えるかを示す異議を返すことができる。異議に加えて、ＣＣＰは、予想されるリソースが割り当てを超えるであろう量を返すこともできる。

ある実施形態に従うと、予想されるリソースが許可されるとＣＣＰが判断した場合、ステップ９において、トランザクションをデータベース１９４５においてコミットすることができる。

図２０は、一実施形態による、クラウドインフラストラクチャ環境における使用計算プロセスをサポートするための方法のフローチャートである。

ある実施形態に従うと、ステップ２００１において、プロセスは、たとえばアイデンティティデータプレーンからコンパートメントツリー階層をフェッチすることができる。これは、コンパートメントの数とともに直線的に増加する返されるデータの量を伴う単一の要求（例えば、ＨＴＴＰ）を含むことができる。

ある実施形態によると、ステップ２００２において、本プロセスは、ターゲットコンパートメントの系統（すなわち、トランザクションが向けられるコンパートメント）を判定することができる。系統は、コンパートメントツリーの高さとともに直線的に成長することができる。

ある実施形態に従うと、ステップ２００３において、本方法は、制限サービスデータプレーンを呼び出すことによって、ターゲットコンパートメント上で実施される割り当てポリシー／サービス制限をフェッチすることができる。そうする際に、プロセスは、単一の制限サービスデータプレーン要求内で割り当ておよびサービス制限要求の両方をフェッチすることができる。

ある実施形態に従うと、ステップ２００４において、データベーストランザクションを開始することができる。

ある実施形態に従うと、ステップ２００５において、データベースバケットからの、影響を受けた各割り当てのリソースカウントを、フェッチすることができる。各割り当てについて、プロセスは、データベースからのオブジェクトを、その割り当てについてのテナント使用データ全体と照合することができる。返されるデータは、そのリソース／割り当ての使用を有するそのテナント内のコンパートメントの数とともに線形に増加し得る。

ある実施形態に従うと、ステップ２００６において、プロセスは、系統内の各コンパートメントの総使用を算出することができる。総使用は、当該コンパートメントの使用と、ツリーを再帰的に下るすべての子の総使用との総計であり得る。この操作は、ツリー内のコンパートメントの数に関して線形である。プロセスは、再帰的な深度の第１のツリートラバースを、カウントがツリーを上る状態で、実行することができる。

ある実施形態に従うと、ステップ２００７において、プロセスは、各制限／割り当てをそのコンパートメントの総使用と比較することができる。制限／割り当てに違反する場合、プロセスは、どの割り当てまたは制限が違反されたか、およびどれだけ違反されたかを示す結果オブジェクトを返すことができる。

ある実施形態に従うと、ステップ２００８において、プロセスは、トランザクションをデータベースにコミットすることができる。

図２１は、一実施形態による、クラウドインフラストラクチャ環境において使用計算プロセスをサポートするための方法のフローチャートである。

ある実施形態に従うと、ステップ２１１０において、本方法は、１つ以上のマイクロプロセッサを含むコンピュータを提供することができる。

ある実施形態に従うと、ステップ２１２０において、本方法は、複数のリージョンを含むクラウドインフラストラクチャ環境を提供することができ、テナンシが複数のリージョン内で定義される。

ある実施形態に従うと、ステップ２１３０において、本方法は、テナンシのコンパートメントを提供することができ、コンパートメントは、複数のコンパートメントのツリー構造に属し、コンパートメントは、コンパートメント割り当てポリシーに関連付けられる。

ある実施形態に従うと、ステップ２１４０において、本方法は、要求されたトランザクションを受け取ることができ、要求されたトランザクションはコンパートメントをターゲットとしている。

ある実施形態に従うと、ステップ２１５０において、本方法は、要求されたトランザクションがコンパートメント割り当てポリシーに違反するかどうかを判断することができる。

ある実施形態に従うと、要求されたトランザクションは、あるタイプのリソースを要求することができる。

ある実施形態に従うと、ステップ２１５０で説明する判断は、追加のステップを含み得、それらのステップは、ターゲットとされたコンパートメントを含むコンパートメントツリー階層をフェッチすることと、ターゲットとされたコンパートメントの系統を判断することと、制限サービスデータプレーンを呼び出すことによって、ターゲットとされたコンパートメント上で実施される複数のコンパートメント割り当てをフェッチすることとを含み、複数のコンパートメント割り当ては、コンパートメント割り当てポリシーを含み、複数のコンパートメント割り当ての各々は、コンパートメントツリー階層内のコンパートメントに属し、上記ステップはさらに、要求されたトランザクションをデータベースで開始することと、データベースから複数のコンパートメント割り当ての各々についてリソースカウントをフェッチすることとを含み、各リソースカウントは、要求されたリソースタイプのカウントを含み、上記ステップはさらに、判断された系統において、各コンパートメントについて、要求されたリソースタイプの総使用を計算することを含み、各コンパートメントについての総使用は、コンパートメントの使用と各子コンパートメントの総使用との総計を含み、上記ステップはさらに、複数のコンパートメント割り当ての各々を各コンパートメントの総使用と比較する。

様々な実施形態によれば、本明細書の教示は、本開示の教示に従ってプログラミングされた１つ以上のプロセッサ、メモリ、および／またはコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用または専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを使用して都合よく実現されてもよい。適切なソフトウェアコーディングは、ソフトウェア技術の当業者には明らかなように、本開示の教示に基づいて熟練したプログラマーによって容易に準備することができる。

いくつかの実施形態では、本開示の教示は、コンピュータ可読媒体を用いて、１つ以上のプログラマブルプロセッサまたはコンピュータが本教示のプロセスのいずれかを実行するための命令を伝達する（たとえば、記憶するまたは搬送する）ことができるコンピュータプログラム製品を含むことができる。コンピュータ可読媒体の一例は、本教示のプロセスのいずれかを実行するようにコンピュータをプログラムするために用いられ得る命令が記憶された非一時的コンピュータ可読記憶媒体である。そのような記憶媒体の例は、ハードディスクドライブ、ハードディスク、ハードドライブ、固定ディスク、もしくは他の電気機械データストレージデバイス、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム、または命令および／もしくはデータの非一時的な格納に適した他のタイプの記憶媒体もしくはデバイスを含み得るが、それらに限定はされない。コンピュータ可読媒体の別の例は、コンピュータシステム間または所与のコンピュータシステムのコンポーネント間でそのような命令を伝達する過渡的媒体である。過渡媒体の例は、搬送波および伝送信号を含むことができるが、これらに限定されない。

したがって、ある観点から、クラウドインフラストラクチャ環境においてコンパートメント割り当てをサポートするシステムおよび方法が説明された。クラウド管理者は、概して、既存のクラウドにおいてリソース使用を制限する能力を有していない。ユーザにリソースを作成するための許可を与えることにより、ユーザは、事前定義されたアカウント限度まで任意の数のリソースを作成することが可能になる。コンパートメント割り当ては、管理者が、ユーザのリソース使用を適切なレベルに制限することができ、微調整されたコスト制御が可能になる。

前述の説明は、例示および説明を目的として提供された。それは、網羅的であること、または保護の範囲を開示された厳密な形態に限定することを意図するものではない。多くの修正および変形が当業者には明らかであろう。例えば、本開示で提供される例のいくつかは、Oracle Fusion Applicationsなどの企業ソフトウェアアプリケーションコンポーネント、Oracle Cloud Infrastructureなどのクラウド環境、およびOracle Fusion Analyticsなどのクラウドサービスとの使用を例示するが、様々な実施形態によれば、本開示に記載のシステムおよび方法は、他のタイプの企業ソフトウェアアプリケーション、クラウド環境、クラウドサービス、クラウドコンピューティング、または他のコンピューティング環境とともに用いることができる。

実施形態は、本教示の原理およびそれらの実際の適用を最もよく説明するために選択および記載されており、それにより、当業者は、企図される特定の使用に適した様々な実施形態および様々な修正を理解することができる。その範囲は、特許請求の範囲およびそれらの均等物によって規定されることが意図される。

Claims (15)

1. クラウドインフラストラクチャ環境においてコンパートメント割り当てをサポートするためのシステムであって、
   １つ以上のマイクロプロセッサを含むコンピュータと、
   複数のリージョンを含むクラウドインフラストラクチャ環境とを備え、テナンシが前記複数のリージョン内で定義され、前記システムはさらに、
   前記テナンシの複数のコンパートメントと、
   前記クラウドインフラストラクチャ環境内の制限サービスデータプレーンとを備え、前記制限サービスデータプレーンは複数のコンパートメントリソース割り当てを記憶するデータベースへのアクセスを有し、
   前記複数のコンパートメントリソース割り当てのうちのコンパートメントリソース割り当ては、前記複数のコンパートメントのうちのコンパートメントに関連付けられ、前記コンパートメントリソース割り当ては、前記コンパートメント内の少なくとも１つのタイプのリソースを制限し、
   前記コンパートメントにおいてリソースがプロビジョニングされるよう求める要求が受信され、前記要求されたリソースは、前記リソース割り当てによって制限された前記タイプのリソースであり、
   前記要求されたリソースの前記プロビジョニングが前記コンパートメントリソース割り当てに違反するかどうかの判断が行われ、
   前記コンパートメントリソース割り当てに違反しないであろうという判断に基づいて、前記要求されたリソースをプロビジョニングし、
   前記コンパートメントリソース割り当てに違反するであろうという判断に基づいて、前記要求に対する異議を唱える、システム。
2. 前記複数のコンパートメントは階層的態様で配置され、
   階層的態様で配列された前記複数のコンパートメントの前記配置のマッピングが、前記制限サービスデータプレーンによってアクセス可能な場所に記憶される、請求項１に記載のシステム。
3. 前記複数のコンパートメントリソース割り当ては、前記複数のコンパートメントの前記階層配置に対応する階層的態様で配置される、請求項２に記載のシステム。
4. 前記クラウドインフラストラクチャ環境は複数のリージョンを含み、前記テナンシは前記複数のリージョンに亘って定義される、請求項１から３のいずれか１項に記載のシステム。
5. 前記複数のコンパートメントの各々は、前記複数のリージョンに亘って定義される、請求項４に記載のシステム。
6. 前記コンパートメントリソース割り当ては、前記複数のリージョンのうちの第１のリージョン内で定義される、請求項５に記載のシステム。
7. 前記コンパートメントリソース割り当てが前記複数のリージョンのうちの前記第１のリージョン内で定義されると、前記コンパートメントリソース割り当ては、前記複数のリージョンのうちの他の各リージョン内で複製される、請求項６に記載のシステム。
8. クラウドインフラストラクチャ環境においてコンパートメント割り当てをサポートするための方法であって、
   １つ以上のマイクロプロセッサを含むコンピュータを提供することと、
   前記コンピュータにおいてクラウドインフラストラクチャ環境を提供することとを含み、前記クラウドインフラストラクチャ環境は複数のリージョンを含み、前記複数のリージョン内でテナンシが定義され、前記方法はさらに、
   前記テナンシの複数のコンパートメントを提供することと、
   前記クラウドインフラストラクチャ環境内に制限サービスデータプレーンを設けることとを含み、前記制限サービスデータプレーンは複数のコンパートメントリソース割り当てを記憶するデータベースへのアクセスを有し、前記方法はさらに、
   前記複数のコンパートメントリソース割り当てのうちのコンパートメントリソース割り当てを、前記複数のコンパートメントのうちのコンパートメントに関連付けることを含み、前記コンパートメントリソース割り当ては、前記コンパートメント内の少なくとも１つのタイプのリソースを制限し、前記方法はさらに、
   前記コンパートメントにおいてリソースがプロビジョニングされるよう求める要求を受信することを含み、前記要求されたリソースは、前記リソース割り当てによって制限された前記タイプのリソースであり、前記方法はさらに、
   前記要求されたリソースの前記プロビジョニングが前記コンパートメントリソース割り当てに違反するかどうかを判断することと、
   前記コンパートメントリソース割り当てに違反しないであろうという判断に基づいて、前記要求されたリソースをプロビジョニングすることと、
   前記コンパートメントリソース割り当てに違反するであろうという判断に基づいて、前記要求に対する異議を唱えることとを含む、方法。
9. 前記複数のコンパートメントを階層的態様で配置することをさらに含み、
   階層的態様における前記複数のコンパートメントの前記配置のマッピングを配置することは、前記制限サービスデータプレーンがアクセス可能な場所に記憶される、請求項８に記載の方法。
10. 前記複数のコンパートメントリソース割り当てを、前記複数のコンパートメントの前記階層配置に対応する階層的態様で配置することをさらに含む、請求項９に記載の方法。
11. 前記クラウドインフラストラクチャ環境は複数のリージョンを含み、前記テナンシは前記複数のリージョンに亘って定義される、請求項８から１０のいずれか１項に記載の方法。
12. 前記複数のコンパートメントの各々を前記複数のリージョンに亘って定義することをさらに含む、請求項１１に記載の方法。
13. 前記コンパートメントリソース割り当てを前記複数のリージョンのうちの第１のリージョン内で定義することをさらに含む、請求項１２に記載の方法。
14. 前記コンパートメントリソース割り当てが前記複数のリージョンのうちの前記第１のリージョン内で定義されると、前記コンパートメントリソース割り当ては、前記複数のリージョンのうちの他の各リージョン内で複製される、請求項１３に記載の方法。
15. 請求項８～１４のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。

Images