[z/OS]

WLM による HTTP 要求数の均等分散

z/OS® ワークロード管理 (WLM) コンポーネントは、サーバントのアフィニティーがなくても、着信する HTTP 要求をラウンドロビン方法でサーバント全体に分散する方法をサポートしています。 この機能は、メモリーに保持されて長く持続する HTTP セッション・オブジェクト、ステートレス・セッション Enterprise JavaBeans (EJB)、およびステートフル・セッション・エンタープライズ Bean の create メソッドを対象としていますが、これらに限定されているわけではありません。 現在インバウンド要求と同じ作業キューにバインドされているアクティブ・サーバント全体に HTTP 要求を分散させるため、この機能を使用するように製品を構成できます。

次の図は、クラスター・サーバー・インスタンスの一例です。azsr01 クラスターには、 azsr01a アプリケーション・サーバー・インスタンスが含まれています。アプリケーション・サーバー・インスタンスには、 コントローラー、ワークロード・マネージャー (WLM) キュー、および、 アプリケーションが実行されるサーバントがあります。コントローラーは、 HTTP および IIOP の終端ポイントです。 WLM キューは、コントローラーからいずれかのサーバントまでの作業の流れを制御します。 個々のサーバントには、WLM キューからの作業を選択するワーカー・スレッドが含まれています。

図 1. クラスター・サーバー・インスタンスの内容

着信要求は、
ワークロード・マネージャー・キューを経由して制御領域に入り、
特定のサーバント領域内のワーカー・スレッドに割り当てられます。

前述の図では、アプリケーション・サーバーは、 サーバントの最小および最大数を 3 に設定するように構成されています。

このクラスターには、アプリケーション・サーバー用の WLM 定義があります。 azsr01 クラスター内の任意のアプリケーション・サーバー・インスタンスに対する要求はすべて、 同じサービス・クラスに割り当てられます。WLM 分類規則では、 azsr01a アプリケーション・サーバーで実行中の別プログラムはすべて、 AZAMS1 サービス・クラスに割り当てられます。 次の図は、WLM サービス・クラス定義と分類規則の一例です。
図 2. WLM サービス・クラス定義
   Service-Class  Xref  Notes  Options  Help                                    
 --------------------------------------------------------------------------     
                           Modify a Service Class               Row 1 to 2 of 2 
 Command ===> ______________________________________________________________    
                                                                                
 Service Class Name . . . . . : AZAMS1                                          
 Description . . . . . . . . . WAS Enclave Work                                
 Workload Name  . . . . . . . . ONL_WKL   (name or ?)  Base Resource Group  . . . . . ________  (name or ?)  Cpu Critical . . . . . . . . . NO        (YES or NO)                           
                                                                                
 Specify BASE GOAL information.  Action Codes: I=Insert new period,               
 E=Edit period, D=Delete period.                                                                                 
         ---Period---  ---------------------Goal---------------------             
 Action  #  Duration   Imp.  Description                                        
   __                                                                           
   __    1              1    Execution velocity of 50                           
 ******************************* Bottom of data ********************************
図 3. WLM CB サブシステムの分類規則
   Subsystem-Type  Xref  Notes  Options  Help
 --------------------------------------------------------------------------
                  Modify Rules for the Subsystem Type    Row 11 to 20 of 20
 Command ===> ____________________________________________ SCROLL ===> CSR 
                                                                           
 Subsystem Type . : CB Fold qualifier names? Y  (Y or N)
 Description . . . Component Broker requests                                 
                                                                           
 Action codes:  A=After    C=Copy         M=Move     I=Insert rule
                 B=Before   D=Delete row   R=Repeat   IS=Insert Sub-rule
                                                              More ===>    
           --------Qualifier--------           -------Class--------
 Action    Type     Name     Start             Service     Report  
                                          DEFAULTS: AZAMS1      RBBDEFLT      
  ____  1  CN         AZSR01   ___                  AZAMS1      RAZAMS1       
  ____  1  CN         AZSR02   ___                  AZAMS2      RAZAMS2       
  ____  1  CN         AZSR03   ___                  AZAMS3      RAZAMS3    
****************************** BOTTOM OF DATA *****************************

この製品は、複数のサーバントがあるアプリケーション・サーバーの場合に、メモリー内の HTTP セッション・オブジェクト を使用すること (これは、ホット・サーバント戦略とも呼ばれます) を サポートしています。次の図では、2 人のユーザーが、 azsr01a アプリケーション・サーバー・インスタンス内のアプリケーションにアクセスしています。ユーザー 1 は、サーバント 3 で HTTP セッション・オブジェクトを設定しました。 ユーザー 2 は、サーバント 2 で HTTP セッション・オブジェクトを設定しました。

図 4. ユーザーによる HTTP セッション・オブジェクトの設定

ユーザー 1 は、
サーバント 3 で HTTP セッション・オブジェクトを設定し、
ユーザー 2 は、サーバント 2 で HTTP セッション・オブジェクトを設定します。

確立済み HTTP セッション・オブジェクトのないサーバント領域にアクセスすると、 サーバント領域のアフィニティーは存在しません。 そのため、要求は、使用可能な任意のサーバントにディスパッチされます。 以下の条件がすべて満たされると、 WLM は、新規サーバントを開始することがあります。
  • 構成が新規サーバントの作成を許可する場合。
  • ワークロード・マネージャー・ロジックが、 システムで追加サーバントを維持できると判断した場合。
  • 別のサーバントを追加することにより、キューの遅延が少なくなり、 別プログラムを指定した目標内で完了できる場合。

複数のサーバントが同じサービス・クラスにバインドされている場合、 WLM は新規要求をホット・サーバントにディスパッチしようとします。 ホット・サーバントは、 最近の要求をディスパッチされ、使用可能なスレッドを持っています。 ホット・サーバントに手持ち作業が残っている場合、 WLM は作業を別のサーバントへディスパッチします。

ホット・サーバントは、必要なページがすべてストレージ内にあり、 ジャストインタイム (JIT) でコンパイルされたアプリケーション・メソッドが近くに保存されていて、 迅速なデータ検索用のデータが十分に入ったキャッシュがあると考えられるため、 通常、このホット・サーバント・ストラテジーの実行は適しています。 しかし、以下の状況の場合、このストラテジーは問題を起こします。

最後の状況の場合、結果として、 HTTP セッション・オブジェクトの分散における望ましくないスキューが起こります。 次の図では、HTTP セッション・オブジェクトのほとんどが、 サーバント 1 に割り当てられています。
図 5. ホット・サーバントに割り当てられる HTTP セッション・オブジェクト

HTTP セッション・オブジェクトは、
ホット・サーバント (サーバント 1) に割り当てられます。

たいていの場合、 多くのサーバントに作業をディスパッチするのに十分な要求が WLM キューに存在しないため、 HTTP セッション・オブジェクトの大部分が 1 つまたは 2 つのサーバント内に存在しています。 この振る舞いが、次のような望ましくない結果につながることがあります。
  • アプリケーションが単一サーバント内に多数のオブジェクトを作成すると、 ガーベッジ・コレクションの時間が長くなる場合があります。
  • HTTP セッション・オブジェクトがすべて 1 つのサーバントにバインドされると、 作業が WLM によって管理できず、任意のサーバントにディスパッチできないため、 要求が長時間キュー内に保留されることがあります。
  • すべての HTTP セッション・オブジェクトが 1 つまたは 2 つのサーバント内にある場合は、 HTTP セッション・オブジェクトが複数のサーバントに均等に分割されている場合と比べて、 単一サーバント内のタイムアウトがより多くのユーザーに影響を与える可能性があります。

お客様の構成で、 ホット・サーバント・ストラテジーでの問題の原因となる上記の状況のいずれかが生じる場合、 サーバントのアフィニティーなしで着信 HTTP 要求をサーバント全体に分散させることをサポートするように、 アプリケーション・サーバーを構成することができます。 この機能を使用可能にすると、アプリケーション・サーバーは、 サーバントに対して HTTP 要求のラウンドロビン分散を使用します。

次の例では、アプリケーション・サーバーが、 サーバント間の HTTP 要求でラウンドロビン分散を使用するように構成され、 同じサービス・クラスが割り当てられた作業キュー要求に対して、 複数のサーバントが開始されることを想定しています。

アフィニティーのない新規 HTTP 要求が作業キュー上に着信すると、WLM は、 作業を待機しているワーカー・スレッドが少なくとも 1 つはあるサーバントが存在するかどうかを確認します。 どのサーバントにも使用できるワーカー・スレッドがない場合、WLM は、 いずれかのサーバントのワーカー・スレッドが使用可能になるまで、要求をキューに入れます。 使用可能なワーカー・スレッドがある場合、WLM は、アフィニティーの数が最も小さいサーバントを検出します。 アフィニティーの数が等しいサーバント領域が存在する場合は、 WLM は、使用中のサーバー・スレッド数が少ない方のサーバント領域に、 作業をディスパッチします。

このアルゴリズムの目的は、WLM が、変化する条件を考慮しながら、 待機サーバント間でサーバント・アフィニティーのない着信要求のバランスを取るということです。 このアルゴリズムは、 厳密なラウンドロビン方法でやみくもに要求をサーバーに割り当てるのではありません。 次の図では、HTTP セッション・オブジェクトがサーバント間で均等に分散される様子を示しています。

図 6. アフィニティーのないサーバントに割り当てられる HTTP セッション・オブジェクト

各サーバントは、
ほぼ同数の HTTP セッション・オブジェクトを受信します。

この分散メカニズムは、アフィニティーのないすべてのインバウンド要求に使用できます。 HTTP セッション・オブジェクトが作成された後、 すべてのクライアント・リクエストは、HTTP セッション・オブジェクトが除去されるまでは、 そのサーバントに送信されます。

サーバントのアフィニティーのない着信 HTTP 要求の分散を使用可能にする場合は、 分類マッピング・ファイルを変更する必要があります。 製品が提供する管理対象ラウンドロビン・サポートのマッピング規則で、複数のトランザクション・クラスを指定するように分類マッピング・ファイルをセットアップしている場合は、分類マッピング・ファイルからこのセクションを除去してください。


トピックのタイプを示すアイコン 概念トピック



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