ワークロードを統合するためのワークロード・マネージャーの構成

ワークロード・マネージャー (WLM) を使用すると、システム上のジョブによって使用されるリソースを制御できます。

デフォルトの WLM 構成テンプレートは、インストールされているすべての AIX® オペレーティング・システムに存在します。以下の手順では、WLM 構成テンプレートを更新して、共用サーバー上にリソース管理ポリシーをインプリメントします。更新した構成は、テストの開始ポイントとして使用できます。 WLM の具体的な構成方法は、使用する環境のワークロードおよびポリシーの要件によって異なります。

注:

WLM を有効に使用するには、既存システムのプロセスおよびパフォーマンスについての幅広い知識が必要です。ワークロードに適応できる構成を開発するには、テストおよびチューニングを繰り返し行うことが必要になるでしょう。極端な値や不正確な値を使用して WLM を構成すると、システム・パフォーマンスが著しく低下する場合があります。
プロセスの種別属性 (例えば、ユーザー名、グループ名、またはアプリケーション名) を事前に 1 つ以上知っていると、WLM の構成プロセスは簡単になります。リソースの現在の使用に慣れていない場合は、 topas などのツールを使用して、1 次リソース・ユーザーであるプロセスを識別し、結果の情報をクラスおよび規則の定義の開始点として使用します。
以下のシナリオでは、ワークロード管理の概念で説明されているワークロード・マネージャーの基本概念に精通していることを前提としています。

WLM 構成ファイルは、/etc/wlm/ConfigurationName ディレクトリーにあります。各スーパークラスの個々のサブクラスは、/etc/wlm/ConfigurationName/SuperClassName という名前の構成ファイルで定義されています。これらのファイルの詳細については、ファイル・リファレンスを参照してください。

次の手順では、2 つの別個の部門サーバーのワークロードを、より大規模な 1 つのサーバーに統合します。この例では構成ファイルを編集しますが、SMIT (smit wlmconfig_create 高速パス) を使用して、構成することもできます。要約すると、この手順では以下のことを行います。

統合したいアプリケーションのリソース要件を識別する。これにより、大規模サーバーに移動できるアプリケーションの数を知ることができます。
統合したワークロードのテストを開始するために、tier、リソース share および制限を定義する。
期待した結果を得られるまで、構成を微調整する。

このハウツー・シナリオの情報は、AIXの特定のバージョンを使ってテストされた。得られる結果は、AIXのバージョンとレベルによって大きく異なるかもしれない。

ステップ 1. アプリケーション要件の識別

このシナリオでのワークロードは、データベース・サーバーで典型的にみられるものです。ジョブは、以下の一般的なカテゴリーに分類されるものとします。

Listeners: ここに含まれるジョブは、ほとんどの時間スリープしていて、要求に応えて定期的にウェイクアップするプロセスです。これらのプロセスは、リソースをそれほど消費しませんが、応答時間が重要になります。
Workers: ここに含まれるジョブは、ローカル側から、または、リモート側からの要求に応えて作業を行うプロセスです。これらのプロセスは、多くの CPU 時間およびメモリーを使用します。
Reporters: ここに含まれるジョブは、自動化タスクを実行するプロセスです。これらのプロセスでは、多くの CPU 時間またはメモリーが必要となりますが、応答時間が遅くても問題ありません。
モニター: ここに含まれるジョブは、通常、システムまたはアプリケーションの状態を検査するために、定期的に実行されるプロセスです。これらのプロセスは、大量のリソースを使用しますが、時間は短時間です。
コマンド: ここに含まれるジョブは、システム・ユーザーが任意の時間に実行するコマンドまたはその他のアプリケーションです。それらのリソース要件は予測することができません。

上記の作業以外に、スケジュール化されたジョブは、次のどちらかのカテゴリーに分類されます。

SysTools: ここに含まれるジョブは、自動化タスクを実行するプロセスです。これらのジョブは、システム操作では重要でありませんが、定期的であり、特定の制約された時間内に実行される必要があります。
SysBatch: ここに含まれるジョブは、頻繁には実行されないプロセスです。また、システム操作では重要でなく、一定時間内に終了する必要もありません。

構成を作成する最初のステップは、クラスおよびルールを定義することです。以下の手順では、上記にリストした一般ジョブ・カテゴリーを使用してクラスを定義します。次の手順を使用してください。

次のコマンドを実行して、/etc/wlm ディレクトリー内に MyConfig という名前の新規構成を作成します。
```
mkdir /etc/wlm/MyConfig
```
次のコマンドを実行して、テンプレート・ファイルを /etc/wlm/MyConfig ディレクトリーにコピーします。
```
cp -pr /etc/wlm/template/* /etc/wlm/MyConfig
```
スーパークラスを作成するには、任意のエディターを使用し、/etc/wlm/MyConfig/classes ファイルを編集して以下の内容を含めます。
```
System:

Default:

DeptA:

DeptB:

SysTools:

SysBatch:
```
まず始めに、それぞれの部門ごとに 1 つのスーパークラスを定義します (2 つの部門がサーバーを共有するため)。 SysTool スーパークラスおよび SysBatch スーパークラスは、上記の一般カテゴリーで説明した、スケジュールされたジョブを処理します。 System スーパークラスおよび Default スーパークラスは、常に定義されます。
MyConfig ディレクトリー内に、DeptA および DeptB のそれぞれのスーパークラスごとに 1 つのディレクトリーを作成します。 (構成を作成する際には、サブクラスをもつ各スーパークラスに 1 つのディレクトリーを作成する必要があります。) 以下の手順では、各部門のスーパークラスに 5 つのサブクラス (各作業カテゴリーに 1 つ) を定義します。
ジョブの一般カテゴリーごとにサブクラスを作成するには、 /etc/wlm/MyConfig/DeptA/classes ファイルと /etc/wlm/MyConfig/DeptB/classes ファイルを編集して以下を含めます。
```
Listen:
        
Work:
        
Monitor:
        
Report:
        
Command:
        
```
注: classes ファイルの内容は、スーパークラスごとに異なる場合があります。

クラスを指定した後に、以下のステップで、スーパークラスおよびサブクラスのレベルで、プロセスを分類する際に使用する分類ルールを作成します。簡単のため、すべてのアプリケーションは既知の場所から実行され、ある部門からのすべてのプロセスはdeptA UNIXグループの下で実行され、他の部門からのプロセスはdeptB UNIXグループの下で実行されると仮定する。
スーパークラス割り当てルールを作成するために、/etc/wlm/MyConfig/rules ファイルを編集して、以下の項目を含めます。
```
DeptA - - deptA - -
DeptB - - deptB - -
SysTools - root,bin - /usr/sbin/tools/* -
SysBatch - root,bin - /usr/sbin/batch/* -
System - root - - -
Default - - - - -
```
注: 同じアプリケーションの複数のインスタンスを実行でき、すべての種別属性 (タグ以外) が同じである場合は、 wlmassign コマンドまたは wlm_set_tag サブルーチンを使用して、それらを異なるクラスに割り当てることによって区別してください。
より具体的なサブクラス・ルールを作成するため、次の内容をもった /etc/wlm/MyConfig/DeptA/rules ファイルおよび /etc/wlm/MyConfig/DeptB/rules ファイルを作成します。
```
Listen - - - /opt/myapp/bin/listen* -
Work - - - /opt/myapp/bin/work* -
Monitor - - - /opt/bin/myapp/bin/monitor -
Report - - - /opt/bin/myapp/report* -
Command - - - /opt/commands/* -
```
各クラスのリソース消費動作を判別するため、次のコマンドを実行して、WLM をパッシブ・モードで開始します。
```
wlmcntrl -p -d MyConfig
```
WLM をパッシブ・モードで開始したら、まず、各アプリケーションを別々に実行し、個別アプリケーションのリソース要件の詳細な見通しを得ることができます。次に、すべてのアプリケーションを同時に実行して、すべてのクラス間での相互作用をより正確に確認することができます。

アプリケーション・リソース要件を確認する別の方法として、統合するアプリケーションの存在する個別のサーバー上で、まず WLM をパッシブ・モードで実行することもできます。この方法の欠点は、大規模システムで構成を再作成しなければならない点、およびリソースの所要パーセンテージが、大規模システムで異なる可能性がある点です。

ステップ 2. 層、共有、および制限を定義します

WLM の構成とは、リソース管理ポリシーをインプリメントすることです。 WLM をパッシブ・モードで実行すると、特定のワークロードに対して、リソース管理ポリシーが合理的であるかどうかを判別するための情報を得ることができます。これを行えば、tier、share、および制限を定義して、リソース管理ポリシーに基づいてワークロードを調整できるようになります。

このシナリオでは、以下の要件を満たしているものとします。

System クラスは最高の優先順位をもっており、いつでも、一定パーセントのシステム・リソースを利用することが保証されている。
SysTools クラスは、いつでも一定のパーセントのリソースを利用できるが、DeptA および DeptB で実行されているアプリケーションに大きな影響がでるほど多くのリソースは利用できない。
SysBatch クラスは、システム上のその他の作業に干渉することはない。
DeptA は使用可能なリソース (つまり、share をもったクラスが使用できるリソース) の 60% を受け取り、DeptB は 40% を受け取る。 DeptA および DeptB の中では、以下のとおりです。
- Listen クラス内のプロセスは、短い待ち時間で要求に応答しなければならないが、多くのリソースを消費することはできない。
- Work クラスはほとんどのリソースを消費できなければならない。 Monitor クラスおよび Command クラスは、一定のリソースを消費できるが、Work クラスより多くのリソースは消費できない。
- Report はその他の作業に干渉することはない。

以下の手順では、tier、share、および制限を定義します。

スーパークラス tier を作成するには、任意のエディターを使用し、/etc/wlm/MyConfig/classes ファイルを編集して以下の内容を含めます。
```
System:

Default:

DeptA:
        localshm = yes
        adminuser = adminA
        authuser = adminA
        inheritance = yes

DeptB:
        localshm = yes
        adminuser = adminB
        authuser = adminB
        inheritance = yes

SysTools:
        localshm = yes

SysBatch:
        tier = 1
        localshm = yes 
```
SysBatch スーパークラスは tier 1 に置きます。このクラスには、システム上の他の作業に干渉してほしくない、非常に低い優先順位のジョブが含まれるからです。 (tier を指定しないと、クラスは tier 0 のデフォルト設定になります。) 各部門のスーパークラスの管理は、adminuser および authuser の属性で定義します。 DeptA および DeptB で継承属性を使用可能にします。継承属性をもったクラスで開始されたすべての新規プロセスは、そのクラスのまま変わりません。
各ジョブ・グループのサブクラス tier を作成するには、/etc/wlm/MyConfig/DeptA/classes ファイルおよび /etc/wlm/MyConfig/DeptB/classes ファイルを編集して、以下の内容を含めます。
```
Listen:
        
Work:
        
Monitor:
        
Report:
        tier = 1
Command:
        
```
スーパークラスに初期 share を割り当てるには、/etc/wlm/MyConfig/shares ファイルを編集して以下の内容を含めます。
```
DeptA:
        CPU = 3
        memory = 3

DeptB:
        CPU = 2
        memory = 2 
```
CPU に合計 5 share を割り当てることにしたので、DeptA プロセスは、CPU の合計リソース 5 share のうちから 3 share (60%) を利用できます。DeptB プロセスは、5 share のうちから 2 share (40%) を利用できます。 SysTools、System、および Default の各クラスには share を割り当てなかったので、それらの消費目標値は、アクティブな share 数の影響を受けません。このため、それらのクラスは、制限に達するまでは、DeptA および DeptB より高い優先順位でリソースにアクセスできます。 SysBatch クラスだけは tier 1 のスーパークラスであるため、share を 1 つも割り当てませんでした。したがって、share を割り当てることはできません。 SysBatch クラスのジョブが消費できるのは、tier 0 のどのクラスによっても使用されないリソースだけです。
サブクラスの初期共有を割り当てるには、 /etc/wlm/MyConfig/DeptA/shares ファイルと /etc/wlm/MyConfig/DeptB/shares ファイルを編集して以下を含めます。
```
Work:
        CPU = 5
        memory = 5

Monitor:
        CPU = 4
        memory = 1

Command:
        CPU = 1
        memory = 1 
```
Listen クラスには share を割り当てなかったので、このクラスがリソースを要求した場合は、スーパークラスの中では最も高い優先順位でリソースにアクセスします。 Work クラスのリソース要件が最大なので、このクラスに最大数の share を割り当てました。それぞれ、クラスの監視された動作および相対的な重要度に基づいて、Monitor および Command の各クラスに share を割り当てました。 Report クラスだけは tier 1 のサブクラスであるため、share を割り当てませんでした。したがって、share を割り当てることはできません。 Report クラスのジョブが消費できるのは、tier 0 のサブクラスに使用されないリソースだけです。
この例の以下のステップでは、share を割り当てなかったクラスに制限を割り当てます。 (share をもったクラスに制限を割り当てることもできます。詳しくは、 WLM を使用したリソースの管理を参照してください。)
スーパークラスに制限を割り当てるには、 /etc/wlm/MyConfig/limits ファイルを編集して以下を含めます。
```
Default:
        CPU = 0%-10%;100%
        memory = 0%-10%;100%

SysTools:
        CPU = 0%-10%;100%
        memory = 0%-5%;100%

System:
        CPU = 5%-50%;100%
        memory = 5%-50%;100% 
```
System、SysTools、および Default の各クラスが、システム上のその他の作業に著しく干渉しないようにするために、これらのクラスにソフト最大制限を割り当てました。 System クラスには、CPU およびメモリーに関して、最小制限を割り当てました。このクラスには、システム操作で重要になるプロセスが含まれていること、また、このクラスが保証されたリソース量を消費できなければならないからです。
サブクラスに制限を割り当てるには、 /etc/wlm/MyConfig/DeptA/limits ファイルと /etc/wlm/MyConfig/DeptB/limits ファイルを編集して以下を含めます。
```
Listen:
        CPU = 10%-30%;100%
        memory = 10%-20%;100%

Monitor:
        CPU = 0%-30%;100%
        memory = 0%-30%;100% 
```
注: サブクラス・ファイルごとに制限が異なる場合があります。

Listen および Monitor の各クラスが、同じスーパークラス内のその他のサブクラスに著しく干渉しないようにするために、これらのクラスにソフト最大制限を割り当てました。特に、Work クラスが、クラス内のジョブを処理するためのリソースを利用できない場合は、システムがジョブ実行の要求を受け続ける状況は望ましくありません。また、応答時間を速くするために、Listen クラスに最小制限を割り当てました。メモリーの最小制限によって、このクラスによって使用されるページがページ置き換えによってスチールされることがなくなります。このため、実行時間が高速になります。 CPU の最小制限によって、プロセスを実行できるときに、それらのプロセスが、スーパークラスの中で CPU リソースに対する最高の優先順位アクセス権をもてるようになります。

ステップ 3. ワークロード・マネージャー構成の微調整

wlmstat コマンドを使用してシステムをモニターし、WLM による規制がゴールに沿ったものかどうか、および一部のアプリケーションが必要以上にリソースを獲得している一方で、不当にリソースを奪われているアプリケーションがないかどうかを検証します。この場合、Share を調整し、WLM をリフレッシュします。
Share、制限、および Tier 番号をモニターして調整しながら、一部またはすべてのスーパークラスについて、サブクラスの管理を委任するかどうかを決定します。次に、管理者はサブクラスの Share、制限、および Tier 数をモニターしてセットアップすることができます。

それぞれのサブクラスの管理者は、それぞれのスーパークラスのサブクラスについてこのプロセスを繰り返すことができます。相違点は、パッシブ・モードでは、サブクラス・レベルのみで WLM を実行することはできないという点だけです。サブクラス構成とチューニングは、WLM を使用してアクティブ・モードで実行しなければなりません。スーパークラスのユーザーおよびアプリケーションに影響を与えないようにする方法の 1 つには、サブクラスの Tier 数と、Share および制限にデフォルト値 (Share には '-' (ハイフン)、最小に 0%、ソフトおよびハード最大 (%) に 100%) を使用して開始することがあります。これらの設定値を指定した場合、WLM がサブクラス間のリソース割り当てを調整することはありません。

詳細情報

ワークロード・マネージャー。
ワークロード管理。
「 Performance Management」の「Workload Management Diagnosis」。
ファイル・リファレンス」の「classes、「limits、「rules、「sharesファイルの説明。
topas、 wlmassign、 wlmcheck、 wlmcntrl、および wlmstat。
WLM サブルーチンの説明 (特に wlm_set_tag)。