ワークロードを管理するためのスケーリング・ポリシーの定義

スケーリング・ポリシーは、構成可能メトリックに基づいて動的クラスター・メンバーを開始および停止するために使用されます。 全クラスターまたは特定クラスターのスケーリング・ポリシーを定義できます。ポリシーが定義されていない場合、組み込みポリシーが使用されます。

このタスクについて

スケーリング・コントローラーは、スケーリング・ポリシーを使用して、 ワークロード管理に関する決定を行います。デフォルトで、スケーリング・コントローラーには 1 つの組み込みスケーリング・ポリシーが組み込まれます。オプションで、 トップレベル・エレメントのデフォルト・スケーリング・ポリシーとスケーリング・ポリシーのいずれかまたは両方を定義することによって、 組み込みスケーリング・ポリシーをオーバーライドできます。組み込みスケーリング・ポリシーは次のとおりです。
  • 最小 2 つのクラスター・メンバー (使用可能な場合) をアクティブな状態に保つ。 一部またはすべてのメンバーがメトリックしきい値を超えていると、最小数が満たされない場合があります。
  • アクティブな全メンバーの CPU、ヒープ、またはメモリーの平均使用量が 90% を上回ると、 追加のクラスター・メンバーを 1 つ開始する。
  • CPU およびヒープの平均使用量が 30 % を下回ると、 クラスター・メンバーを 1 つ停止する。

デフォルト・スケーリング・ポリシーを使用して、全クラスターのスケーリング・ポリシーを定義できます。 デフォルト・スケーリング・ポリシーは、min および max のインスタンス値を含め、組み込みスケーリング・ポリシーのメトリックを継承します。ユーザーが指定してデフォルト・スケーリング・ポリシーに加えられた変更は、組み込み値をオーバーライドします。 デフォルト・スケーリング・ポリシーで指定されていない値は、組み込みスケーリング・ポリシーから継承されます。

デフォルト・スケーリング・ポリシーとは異なり、スケーリング・ポリシーのメトリックは、組み込みスケーリング・ポリシーおよび デフォルト・スケーリング・ポリシーのどちらからも継承されません。 ただし、minmax のインスタンス値は、組み込みポリシー値に初期化されます。スケーリング・ポリシーのメトリックは、オプション値と見なされるため、ポリシーに指定されたメトリックのみがスケーリングの決定に含まれます。スケーリング・ポリシーに含まれていないメトリックは、スケーリングの決定時には分析されません。

スケーリング・ポリシーには 2 つのレベルがあります。組み込みスケーリング・ポリシーは、いずれかまたは両方のトップレベル・エレメントを定義することによりオーバーライドできます。以下の 2 つのレベルが定義可能です。
  • デフォルト・スケーリング・ポリシー

    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 属性の値は、 クラスター名のコンマ区切りリストです。アスタリスクは名前の末尾にのみワイルドカードとして使用でき、 ゼロ個以上の文字との一致を表します。以下に例を示します。
    <bind clusters="west,south*"/>
    この例では、 スケーリング・ポリシーは、west という名前のクラスターと、 south で始まる名前のすべてのクラスターに適用されます。1 つのクラスター名が複数のポリシーに一致する場合、 スケーリング・コントローラーは、以下のルールを使用してポリシーを選択します。
    • ワイルドカードによる一致よりも、完全な一致の方が優先する。
    • ワイルドカードによる一致が複数ある場合、最長の接頭部が指定されているポリシーが使用される。

このポリシーは、デフォルトの min 値と max 値に基づいてスケーリングを行います。上記の例で、クラスターは、指定された CPU 値 (ここでは、min=10 および max=70) のみに基づいてスケーリングします。

メトリック・ベースのスケーリングの決定はクラスター・レベルで行われます。 各クラスター・メンバーは、独自のメトリックをモニターします。 サーバーの CPU およびメモリーのメトリック値は実際には、サーバー JVM プロセス、またはサーバーのホストの大きいほうです。 ヒープのメトリック値は、サーバー JVM プロセスからのみ取得されます。 モニター対象メトリックで測定可能な変化が検出されると、そのメトリックは、分析のためにコントローラーに送られます。 すべてのクラスター・メンバーのメトリックが集計され、クラスターの平均が各メトリックごとに計算されます。 次に、各メトリックの計算値を、定義されている上限しきい値または下限しきい値と比較して、スケーリングの決定を起動するかどうか判断します。

拡張」の決定は、個々のメトリック・ベースで行われます。該当クラスターでモニターされているすべてのメトリックが分析され、それらのメトリックのいずれかが、ポリシーの max しきい値を超えると、拡張イベントが起動されます。「縮小」の決定は、モニターされているすべてのメトリックに基づいて行われます。各モニター対象メトリックのクラスター平均を分析します。 すべてのメトリックがポリシーの min しきい値を下回っている場合、縮小イベントが起動されます。

スケーリングの決定が行われた後、スケーリング・コントローラーはスケーリング・ターゲットを選択します。スケーリング・ターゲットは、サーバーの停止 (縮小の場合) アクションまたはサーバーの開始 (拡張の場合) アクションが実行されるホストです。拡張アクションのターゲットを決定する際には、ホスト・レベルのメトリックが考慮されます。 ホスト・レベルのメトリックのいずれかが、そのメトリックのポリシーの max しきい値を超えると、スケーリング・コントローラーはそのホストを避け、別のホストを拡張アクションに選択します。

スケーリング・ポリシーは、スケーリング・ターゲットの選択に影響する可能性があります。ポリシーに scalingPreference="horizontal" が指定されている場合、スケーリング・コントローラーは、アクティブ・サーバーの数が最も少ない適格ホスト上のサーバーを開始し、アクティブ・サーバーの数が最も多いホスト上のサーバーを停止します。ポリシーに scalingPreference="vertical" が指定されている場合、スケーリング・コントローラーは、最もアクティブ・ホストの数が多い適格ホスト上のサーバーを開始し、アクティブ・サーバーの数が最も少ないホスト上のサーバーを停止します。スケーリング・コントローラーは、どの scalingPreference が選択されているかに関係なく、可能な場合、同じクラスター内のサーバーを異なるホストに入れようとします。

scalingPolicy メトリックについて詳しくは、スケーリング・コントローラーを参照してください。

hostGroup エレメントを使用して、新規サーバーのプロビジョンに選択できるホストを制限できます。 tags 属性は、管理メタデータ・タグのリストを指定します。 スケーリング・コントローラーは、サーバーをプロビジョンする必要がある場合、 少なくとも 1 つのタグが一致するホストのみを選択できます。 例えば、以下のポリシーでは、tag1 が関連付けられているホスト、または tag2 が関連付けられているホストでサーバーをプロビジョンできることが記述されています。
<scalingDefinitions>        
  <scalingPolicy id="provisionPolicy">           
   <bind clusters="defaultStackGroup.deployMember"/>           
   <hostGroup tags="tag1 tag2"/>        
 </scalingPolicy>    
</scalingDefinitions>
注: hostGroup エレメントを指定しない場合、 スケーリング・コントローラーは、集合に登録されたすべてのホストでサーバーをプロビジョンできます。

管理メタデータ・タグの設定について詳しくは、『Liberty リソースの管理メタデータの設定』を参照してください。

手順

  1. スケーリング・コントローラーの server.xml ファイルに、デフォルト・スケーリング定義を追加します。
    <scalingDefinitions>
     <defaultScalingPolicy enabled="true" min="1" max="2"/>
    </scalingDefinitions>
  2. スケーリング・ポリシーが変更されると、コントローラーの server.xml も変更されます。messages.log ファイルで以下のメッセージを探して、コントローラーが正常に更新されたことを検証できます。
    CWWKG0016I: Starting server configuration update.
    CWWKG0028A: Processing included configuration resource: /opt/IBM/Liberty/wlp/usr/
    CWWKG0017I: The server configuration was successfully updated in 0.052 seconds
    スケーリング・ポリシーに必要なメトリックしきい値が指定されていなかった場合、以下のエラー・メッセージが messages.log ファイルに記録されます。ユーザー処置に従って、エラーを訂正してください。
    CWWKV0126W: The configuration of scaling policy {0} does not contain a min or max threshold.
    CWWKV0127W: The configuration of scaling policy {0} does not contain a max threshold.
    CWWKV0128W: The configuration of scaling policy {0} does not contain a min threshold.

タスクの結果

これで、スケーリング・ポリシーが定義されました。


トピックのタイプを示すアイコン タスク・トピック

ファイル名: twlp_wve_definingscalingpolicies.html