割当て制限ポリシーの構文
次のトピックでは、コンパートメント割当てポリシーの構文について説明します。
割当てポリシー・ステートメントの3つのタイプを使用できます:
set: コンパートメントに使用できるクラウド・リソースの最大数を設定します。unset: 割当て制限をデフォルトのサービス制限にリセットします。zero: コンパートメントのクラウド・リソースへのアクセス権を削除します。
割当てポリシー・ステートメントの言語コンポーネントは次のとおりです:
- 定義されている割当てのタイプに対応する
actionキーワード。キーワードは、set、unsetまたはzeroです。 - サービス・ファミリの名前。例:
compute-core。 quotaまたはquotasキーワード- 割当ての名前。これはサービス・ファミリによって異なります。たとえば、
compute-coreファミリの有効な割当てはstandard-e4-core-countです。- ワイルドカードを使用して、名前の範囲を指定することもできます。たとえば、
"/standard*/"は、フレーズ"standard"で始まるすべてのコンピュート割当てに一致します。
- ワイルドカードを使用して、名前の範囲を指定することもできます。たとえば、
- setステートメントの場合は、割当ての値です。
- 割当ての対象コンパートメント。
- オプションの条件。たとえば、
where request.region = 'us-phoenix-1'です。現在サポートされている条件は、request.regionおよびrequest.adです。
一般的な使用例については、サンプル目標も参照してください。
スコープ
割当てには様々なスコープがあり、可用性ドメイン、リージョン、またはグローバルで使用できます。コンパートメント割当てを操作する際のスコープについて理解する重要なポイントを次に示します:
-
可用性ドメイン(AD)レベルで割当てを設定する場合、その割当ては各ADに割り当てられます。そのため、たとえば、コンパートメントに120 OCPUの割当てを設定すると、実際にはAD当たり120 OCPUの制限が設定されます。特定のADをターゲットにするには、
where句でrequest.adパラメータを使用します。 -
リージョンの割当てが各リージョンに適用されます。地域目標の例については、Sample Quotasを参照してください。
- サブコンパートメントの使用量は、メイン・コンパートメントの使用量に対してカウントされます。
詳細は、リージョンおよび可用性ドメインを参照してください。
権限とネスト
コンパートメント割当てはルート・コンパートメントで設定できます。(ルート・コンパートメント上の割当てを管理できる必要がある)管理者は、独自のコンパートメントおよび任意の子コンパートメントに割当てを設定できます。親コンパートメントに設定されている割当ては、子コンパートメントに設定されている割当てをオーバーライドします。これにより、親コンパートメントの管理者は、子によってオーバーライドできない割当てを子コンパートメントに作成できます。
ネストされたコンパートメントをターゲットとするポリシーは、次のように記述されます:
set compute quota standard-e4-core-count to 10 in compartment parent:child:another_child割当ての評価および優先度
- ポリシー内では、割当てステートメントが順番に評価され、後のステートメントは同じリソースをターゲットとする前のステートメントに置換されます。
- 同じリソースに複数のポリシーを設定すると、最も制限が厳しいポリシーが適用されます。
- サービス制限は常に割当て制限よりも優先されます。リソースのサービス制限を超える割当て制限をそのリソースに指定できますが、サービス制限は引き続き適用されます。
ワイルドカード
一部の割当て制限ファミリには多数のリソースがあります。たとえば、データベース割当て制限ファミリは多くの割当て制限で構成されます。このような場合、割り当て制限名 wildcardsを使用して名前の範囲を指定できます。
この例では、ワイルドカードを使用してすべてのexadataリソースをProductionAppコンパートメントに割り当てます。
zero database quota /*exadata*/ in tenancy
unset database quota /*exadata*/ in compartment ProductionApp