ポリシーベースのリースを使用することで、リソースを再利用するの際の手動による作業を軽減します。リース ポリシーを定義して、ユーザーが展開を使用できる期間を制御できるようにします。この手順でのリース ポリシーの使用事例は、ポリシーを理解して組織で実装する上で役立ちます。
リース ポリシーを定義しない場合、展開は期限切れになりません。リソースを再利用するには、展開を手動で破棄する必要があります。
リース ポリシーが有効になるタイミング
- ポリシーの範囲が組織の場合、組織内のすべての展開は、定義されたポリシーに基づいて管理されます。
- ポリシーの範囲がプロジェクトの場合、そのプロジェクトに関連付けられている展開は、定義されたリースに基づいて管理されます。他のプロジェクトは影響を受けません。
リース ポリシーが適用されるタイミング
- リース ポリシーの更新または作成時。リース ポリシーは適用後、展開が定義されたリースに準拠するように、バックグラウンドでの評価を継続します。
- Automation Service Broker 内のカタログ アイテム、または Automation Assembler 内のクラウド テンプレートを申請します。展開が作成されると、最大リース値と最大合計リース値が有効になります。
- Automation Assembler にワークロードまたはリソースをオンボードして Automation Service Broker、Automation Assembler、Automation Pipelines を使用して管理できるようにしたとき。
リース固有のオプション
- 最大リース（日数）。展開リソースが更新されることなくアクティブである日数。更新されない場合、リースは期限が切れ、展開は破棄されます。猶予期間が指定されている場合、ユーザーは、リースがアクティブだった日数と同じ日数までリースを更新できます。
- 最大合計リース（日数）リースの更新期間を含め、展開がアクティブになれる日数を足し合わせた合計日数。それぞれの更新日数は最大リースを超えられず、更新日数の累積値は最大合計リースを超えられません。合計リース日数に達すると、展開は破棄され、その展開内のリソースは再利用されます。
- 猶予期間（日数）。期限が切れた後、展開が破棄されることなくユーザーがリースを更新できる日数。猶予期間は、合計リース日数には含まれません。猶予期間を定義しない場合、デフォルトでは 1 日に設定されます。
手順
この使用事例では、ポリシーの構築方法と適用結果を示すポリシー定義が 3 つあります。最後のポリシーは適用されていませんが、その理由はシナリオの結果で提供されています。
- の順に選択します。
- リース ポリシー 1 を構成します。
管理者は、すべての展開の開始リース時間を 30 日間に制限し、リースを合計 90 日間に更新できるオプションを提供してコストを制御したいと考えています。
- ポリシーを有効にするタイミングを定義します。
設定 サンプルの値 範囲 組織 このポリシーは、組織内の全員に適用されます。
基準 なし 適用タイプ ソフト この適用タイプでは、このポリシーをオーバーライドする、このリースに関連するその他のポリシーを作成できます。
- リースを定義します。
設定 サンプルの値 最大リース（日数） 30 最大合計リース（日数） 90 猶予期間（日数） 10
このシナリオでは、展開は 30 日後にシャットダウンし、ユーザーに E メールが送信されます。猶予期間の間に、ユーザーがリースを 30 日間延長します。リースの有効期限が再び切れると、ユーザーはさらに 30 日間リースを更新します。3 回目の延長が終了すると、リース期間の合計が最大 90 日間に達し、ユーザーはリース期間を延長できなくなります。展開はシャットダウンされ、10 日後に破棄されます。
- ポリシーを有効にするタイミングを定義します。
- リース ポリシー 2 を構成します。
管理者は、コストの大きいテンプレートのリース時間を 2 週間に制限することでコストを制御したいと考えています。この例では、テンプレート名は Multi-tier 5 machine with LB です。
- ポリシーを有効にするタイミングを定義します。
設定 サンプルの値 範囲 Project MT5 このポリシーは、このプロジェクトに関連付けられている展開に適用されます。
基準 Cloud Template equals Multi-tier 5 machine with LB
この条件式に基づき、参照先のテンプレートの展開のみがポリシー適用の対象と見なされます。
適用タイプ ソフト このソフト適用は、プロジェクト レベルでは値がより重要になるため、ポリシー 1 の 90 日の組織ポリシーをオーバーライドします。
- リース ポリシーを定義します。
設定 サンプルの値 最大リース（日数） 14 最大合計リース（日数） 28 猶予期間（日数） 3
このシナリオでは、両方のポリシーが適用されますが、ポリシー 2 がより限定的であるため、ポリシー 1 よりも優先されます。適用されると、展開は 14 日後にシャットダウンされます。ユーザーがリースを拡張しない場合、展開は 3 日後に破棄されます。ユーザーがリースをさらに 14 日間延長した場合、展開は 2 回目の延長の最終日にシャットダウンされ、3 日後に破棄されます。
- ポリシーを有効にするタイミングを定義します。
- リース ポリシー 3 の構成を確認します。
プロジェクト マネージャは、開発者の 1 人が複雑なアプリケーションで作業していることを認識しています。開発者には、ポリシー 2 で定義されているよりも長いリースに対して、テンプレート Multi-tier 5 Machines with LB および別のテンプレート Distributed Database Across Clouds が必要です。
ポリシーの定義内容と、ポリシーの処理過程を理解していないと、予期しない結果になることがあります。ポリシー 3 は、処理と優先順位が結果に与える影響の例です。
このポリシーは、指定されたとおりに適用されません。この例では、適用されるリースが複数ある場合のリースの適用方法について説明します。
- ポリシーを有効にするタイミングを定義します。
設定 サンプルの値 範囲 Project MT5 このポリシーは、このプロジェクトの展開に適用されます。
基準 (Cloud Template equals Multi-tier five machine with LB OR Catalog Item equals Distributed Database Across Clouds) AND Created By equals [email protected]Automation Assembler 以外のテンプレートであるため、カタログ アイテムを使用します。
適用タイプ ソフト このソフト適用は、プロジェクト レベルでは値がより重要になるため、ポリシー 1 の 90 日の組織ポリシーをオーバーライドします。
- リース ポリシーを定義します。
設定 サンプルの値 最大リース（日数） 21 最大合計リース（日数） 50 猶予期間（日数） 3 このシナリオでは、リース ポリシー 3 ではなく、リース ポリシー 2 が適用されます。- リース 3 には、21 日以内のリース時間があり、ポリシーが適用されます。リース 2 には、14 日以内のリース時間があり、ポリシーが適用されます。
- リース 2 は適用可能で、リース 3 ポリシーに違反しません。しかし、リース 2 の制限の方が厳しいため、優先されます。リース ポリシー 2 は、期間が短くなるため、制限がより厳しくなります。
- 両方のリース定義が true であり、適用可能な場合には、より制限の厳しいポリシーが適用されます。
- ポリシーを有効にするタイミングを定義します。
- リース ポリシー 3 の予期しない動作を解決するには、次のいずれかのソリューションを実装します。
- Jan に必要なポリシーを提供できるようにするには、適用タイプをハードに変更します。
- または、同一のリソースへのアクセス権があるプロジェクトを新規に作成し、そのプロジェクトに対してリース ポリシー 3 を作成することもできます。このソリューションでは、作業ポリシーが分離されますが、並行プロジェクトを維持する必要があります。コンテンツ ソースの設定と維持、コンテンツの共有などに必要な作業には、時間がかかり、エラーが発生する可能性があります。
次の手順
- リース ポリシーの処理方法と適用方法の例については、Automation Service Brokerポリシーの処理方法を参照してください。
- 組織およびプロジェクトに関連するポリシーを構成します。リース ポリシーを開始する場合は、組織レベルで 1 つのリース ポリシーから開始します。
- 展開するユーザーに E メールを送信するには、通知用のメール サーバを構成します。通知を送信するメール サーバの Automation Service Broker への追加を参照してください。
- Automation Orchestrator を使用すると、拡張性サブスクリプションを使用することにより、期限切れの展開とそのリソースを管理できます。拡張性サブスクリプションを使用した展開の有効期限の管理を参照してください。
