[z/OS]

コントローラーおよびサーバントの WLM 種別

アプリケーションは、サーバーまたはサーバーのクラスター上でデプロイされます。 各サーバーは、1 つのコントローラーと 1 つ以上のサーバントで構成されます。各コントローラーは、デプロイメント・マネージャーによって開始されるか、MVS 開始タスクとして、MVS オペレーター・コマンドによって開始されます。各サーバントは、必要に応じて、ワークロード・マネージャー (WLM) によって開始されます。

トランザクション・クラスを使用して、WLM のためにクライアント・ワークロードを分類することができます。トランザクション種別は、次の WLM 種別基準に基づきます。
  • サーバー名 (CN) - サーバーがクラスター化されている場合は、この値はクラスターのショート・ネームになります。 サーバーがクラスター化されていない場合は、この値はサーバー・カスタム・プロパティー ClusterTransitionName に指定された値です。
  • サーバー・インスタンス名 (SI) - これはサーバーのショート・ネームです。 これは、一般的にあまり有効ではありません。クラスター内でトランザクションを実行するサーバー・インスタンスを制御できないためです。
  • トランザクション・クラス (TC) に割り当てられるユーザー ID - トランザクション・クラス・マッピング・ファイルを使用して、サーバーがこの ID をトランザクションに割り当てられるようにします。
.

コントローラー種別

コントローラーは、システムでの作業の受け入れ、HTTP トランスポート・ハンドラーの管理、作業の分類、およびその他のハウスキーピング・タスク用の一定の処理を行うため、SYSSTC のコントローラーを分類するか、コントローラーに作業の重要度および速度を高く設定してください。

重要: BBO7ACR などのコントローラー開始プロシージャーのステップでは、BPXBATCH プログラムを呼び出して、サービス・レベルが配信済み、適用済み、処理中になっているかをチェックし、その結果を /properties/service/logs/applyPTF.log ファイルに記録します。 BPXBATCH プログラムは、開始プロシージャーのサービス種別を継承するのではなく、OMVS 規則に従って分類されるため、使用中のシステムで、BPXBATA2 が制御できるようになるまで数分かかる場合があります。OMVS 作業用 の WLM ワークロード分類規則を、より高いサービス目的に変更することによって、BPXBATCH ステップの影響を最小化することができます。 以下の例では、OMVS 作業に、重要度が 1 で速度が 50 の EBIZ_HI サービス・クラスが割り当てられます。
Subsystem Type . : OMVS
Description . . . E_Biz Classification Rule
--------Qualifier------ -------Class--------
Action    Type     Name     Start             Service     Report  
DEFAULTS: EBIZ_DEF ________
____ 1 TN FTPSERVE ___ EBIZ_HI ________
____ 1 UI OMVSKERN ___ SYSSTC ________
____ 1 TN WSSRV* ___ EBIZ_HI RPTACR <<==

サーバント種別

サーバント領域が開始すると、 WLM は、サーバント領域を開始済みタスクとして分類し、 WLM ポリシーに指定された分類規則に基づいていずれかのサービス・クラスおよびレポート・クラスに 入れます。WLM は、このサービス・クラスを使用して、アドレス・スペースの優先順位を決定します。アドレス・スペースの優先順位は、サーバント領域の初期化中にシステム・リソースへのアクセスを決定します。

コントローラー領域が受け取る各作業要求は、WLM エンクレーブに関連しています。これらのエンクレーブのそれぞれは、WLM サービス・クラスおよびレポート・クラスに関連しています。WLM が、コントローラー領域からさまざまなサーバント領域に、作業要求を分散する場合、同一のサービス・クラスに関連する作業要求をすべて一緒に保持しようとします。要求のこのグループ化は、 ある特定のサーバント領域で処理される作業要求は、通常は同一のサービス・クラスに関連するエンクレーブ に関連していることを意味します。エンクレーブのすべてが、同一サービス・クラスに関連している場合、サーバント領域はそのサービス・クラスに関連しているといえます。

サーバント領域 が初期化され、作業要求を受け取り始めると、それ以降は、 すべてのディスパッチ・スレッドおよび非ディスパッチ・スレッド (Java ガーベッジ・コレクション (GC) スレッドなど) は、 そのサーバントで実行する作業要求に関連するエンクレーブの WLM サービス・クラスと関連した目標に従って管理 されます。

ディスパッチ・スレッドが消費するすべてのリソースは、それらのスレッドに 関連しているエンクレーブがある場合、そのエンクレーブに関連する レポート・クラスに報告されます。関連するエンクレーブがないスレッドが消費する すべてのリソースは、サーバント領域の開始済みタスクに 関連するレポート・クラスに報告されます。

ベスト・プラクティス ベスト・プラクティス: サービス・クラス階層 内で、サーバント種別が、より重要な作業 (コントローラーおよび CICS、または IMS トランザクション・サーバーなど) よりも 高位にならないようにしてください。bprac

STC タイプの作業の WLM 分類規則

以下は、コントローラーとサーバントの始動済みタスクに関す る STC タイプの作業の WLM 分類規則の簡単な例です。
          --------Qualifier--------           -------Class--------
Action    Type     Name     Start             Service     Report  
                                    DEFAULTS: OPS_DEF     ________
_____  1  TN      %%DMN    ___                OPS_HIGH    RWSDMN _____  1  TN      T5SRV*   ___                OPS_MED     RT5SRV
_____  1  TN      WS%%%%   ___                SYSSTC      RWSCTLR 
_____  1  TN      WS%%%%S  ___                OPS_HIGH    RWSSRVR

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rweb_classervers
ファイル名:rweb_classervers.html