ワークロードを管理するためのスケーリング・ポリシーの定義
スケーリング・ポリシーは、構成可能メトリックに基づいて動的クラスター・メンバーを開始および停止するために使用されます。 全クラスターまたは特定クラスターのスケーリング・ポリシーを定義できます。ポリシーが定義されていない場合、組み込みポリシーが使用されます。
このタスクについて
- 最小 2 つのクラスター・メンバー (使用可能な場合) をアクティブな状態に保つ。 一部またはすべてのメンバーがメトリックしきい値を超えていると、最小数が満たされない場合があります。
- アクティブな全メンバーの CPU、ヒープ、またはメモリーの平均使用量が 90% を上回ると、 追加のクラスター・メンバーを 1 つ開始する。
- CPU およびヒープの平均使用量が 30 % を下回ると、 クラスター・メンバーを 1 つ停止する。
デフォルト・スケーリング・ポリシーを使用して、全クラスターのスケーリング・ポリシーを定義できます。 デフォルト・スケーリング・ポリシーは、min および max のインスタンス値を含め、組み込みスケーリング・ポリシーのメトリックを継承します。ユーザーが指定してデフォルト・スケーリング・ポリシーに加えられた変更は、組み込み値をオーバーライドします。 デフォルト・スケーリング・ポリシーで指定されていない値は、組み込みスケーリング・ポリシーから継承されます。
デフォルト・スケーリング・ポリシーとは異なり、スケーリング・ポリシーのメトリックは、組み込みスケーリング・ポリシーおよび デフォルト・スケーリング・ポリシーのどちらからも継承されません。 ただし、min と max のインスタンス値は、組み込みポリシー値に初期化されます。スケーリング・ポリシーのメトリックは、オプション値と見なされるため、ポリシーに指定されたメトリックのみがスケーリングの決定に含まれます。スケーリング・ポリシーに含まれていないメトリックは、スケーリングの決定時には分析されません。
- デフォルト・スケーリング・ポリシー
1 つのデフォルト・スケーリング・ポリシーを定義して、 もっと細かいスケーリング・ポリシーの定義を必要としないすべてのクラスターを管理できます。
以下の例は、 アクティブなクラスター・メンバーの最小数を 3 に設定する、デフォルト・スケーリング・ポリシーの定義方法を示します。<scalingDefinitions> <defaultScalingPolicy min="3"/> </scalingDefinitions>
- スケーリング・ポリシー
スケーリング・ポリシーを定義することで、スケーリング・ポリシーで指定された目標基準を使用して 1 つ以上のクラスターを管理できます。スケーリング・ポリシーの定義はメトリックしきい値を継承しないため、指定されたメトリックしきい値のみがモニターされます。スケーリングの決定に関して、そのほかのすべてのしきい値は無視されます。 min および max のインスタンスの組み込みスケーリング・ポリシー値は、それらが指定されていない場合、引き続き使用されます。
以下の例で定義しているスケーリング・ポリシーでは、 cluster1 という名前のクラスターにあるサーバーを開始または停止する基準となる CPU 使用量のしきい値を変更しています。<scalingDefinitions> <scalingPolicy id="cluster1Policy"> <bind clusters="cluster1"/> <metric name="CPU" min="10" max="70"/> </scalingPolicy> </scalingDefinitions>
bind エレメントの clusters 属性の値は、 クラスター名のコンマ区切りリストです。アスタリスクは名前の末尾にのみワイルドカードとして使用でき、 ゼロ個以上の文字との一致を表します。以下に例を示します。
この例では、 スケーリング・ポリシーは、west という名前のクラスターと、 south で始まる名前のすべてのクラスターに適用されます。1 つのクラスター名が複数のポリシーに一致する場合、 スケーリング・コントローラーは、以下のルールを使用してポリシーを選択します。<bind clusters="west,south*"/>
- ワイルドカードによる一致よりも、完全な一致の方が優先する。
- ワイルドカードによる一致が複数ある場合、最長の接頭部が指定されているポリシーが使用される。
このポリシーは、デフォルトの min 値と max 値に基づいてスケーリングを行います。上記の例で、クラスターは、指定された CPU 値 (ここでは、min=10 および max=70) のみに基づいてスケーリングします。
メトリック・ベースのスケーリングの決定はクラスター・レベルで行われます。 各クラスター・メンバーは、独自のメトリックをモニターします。 サーバーの CPU およびメモリーのメトリック値は実際には、サーバー JVM プロセス、またはサーバーのホストの大きいほうです。 ヒープのメトリック値は、サーバー JVM プロセスからのみ取得されます。 モニター対象メトリックで測定可能な変化が検出されると、そのメトリックは、分析のためにコントローラーに送られます。 すべてのクラスター・メンバーのメトリックが集計され、クラスターの平均が各メトリックごとに計算されます。 次に、各メトリックの計算値を、定義されている上限しきい値または下限しきい値と比較して、スケーリングの決定を起動するかどうか判断します。
「拡張」の決定は、個々のメトリック・ベースで行われます。該当クラスターでモニターされているすべてのメトリックが分析され、それらのメトリックのいずれかが、ポリシーの max しきい値を超えると、拡張イベントが起動されます。「縮小」の決定は、モニターされているすべてのメトリックに基づいて行われます。各モニター対象メトリックのクラスター平均を分析します。 すべてのメトリックがポリシーの min しきい値を下回っている場合、縮小イベントが起動されます。
スケーリングの決定が行われた後、スケーリング・コントローラーはスケーリング・ターゲットを選択します。スケーリング・ターゲットは、サーバーの停止 (縮小の場合) アクションまたはサーバーの開始 (拡張の場合) アクションが実行されるホストです。拡張アクションのターゲットを決定する際には、ホスト・レベルのメトリックが考慮されます。 ホスト・レベルのメトリックのいずれかが、そのメトリックのポリシーの max しきい値を超えると、スケーリング・コントローラーはそのホストを避け、別のホストを拡張アクションに選択します。
スケーリング・ポリシーは、スケーリング・ターゲットの選択に影響する可能性があります。ポリシーに scalingPreference="horizontal" が指定されている場合、スケーリング・コントローラーは、アクティブ・サーバーの数が最も少ない適格ホスト上のサーバーを開始し、アクティブ・サーバーの数が最も多いホスト上のサーバーを停止します。ポリシーに scalingPreference="vertical" が指定されている場合、スケーリング・コントローラーは、最もアクティブ・ホストの数が多い適格ホスト上のサーバーを開始し、アクティブ・サーバーの数が最も少ないホスト上のサーバーを停止します。スケーリング・コントローラーは、どの scalingPreference が選択されているかに関係なく、可能な場合、同じクラスター内のサーバーを異なるホストに入れようとします。
scalingPolicy メトリックについて詳しくは、スケーリング・コントローラーを参照してください。
<scalingDefinitions>
<scalingPolicy id="provisionPolicy">
<bind clusters="defaultStackGroup.deployMember"/>
<hostGroup tags="tag1 tag2"/>
</scalingPolicy>
</scalingDefinitions>
管理メタデータ・タグの設定について詳しくは、『Liberty リソースの管理メタデータの設定』を参照してください。
手順
タスクの結果
これで、スケーリング・ポリシーが定義されました。