z/OS ワークロード管理 (WLM) コンポーネントは、サーバントの類縁性がなくても、 サーバント全体にラウンドロビン方法で 着信する HTTP 要求を分散する方法をサポートしています。 この機能は、メモリーに保持されて長く持続する HTTP セッション・オブジェクト、 ステートレス・セッション Enterprise JavaBeans (EJB)、 およびステートフル・セッション Enterprise Bean の create メソッドを対象としていますが、 これらに限定されているわけではありません。 現在、インバウンド要求として同じ作業キューにバインドされている アクティブ・サーバント全体に HTTP 要求を分散させるためにこの機能を使用するよう、 WebSphere Application Server for z/OS を構成することができます。
バックグラウンド
次の図は、クラスター・サーバー・インスタンスの一例です。azsr01 クラスターには、 azsr01a アプリケーション・サーバー・インスタンスが含まれています。アプリケーション・サーバー・インスタンスには、 コントローラー、ワークロード・マネージャー (WLM) キュー、および、 アプリケーションが実行されるサーバントがあります。コントローラーは、 HTTP および IIOP の終端ポイントです。 WLM キューは、コントローラーからいずれかのサーバントまでの作業の流れを制御します。 個々のサーバントには、WLM キューからの作業を選択するワーカー・スレッドが含まれています。
前述の図では、アプリケーション・サーバーは、 サーバントの最小および最大数を 3 に設定するように構成されています。
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 ********************************
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 *****************************
ホット ・サーバント・ストラテジー
WebSphere Application Server for z/OS は、 複数のサーバントを備えたアプリケーション・サーバーのメモリーにおける HTTP セッション・オブジェクトの使用をサポートしています。 次の図では、2 人のユーザーが、 azsr01a アプリケーション・サーバー・インスタンス内のアプリケーションにアクセスしています。ユーザー 1 は、サーバント 3 で HTTP セッション・オブジェクトを設定しました。 ユーザー 2 は、サーバント 2 で HTTP セッション・オブジェクトを設定しました。
複数のサーバントが同じサービス・クラスにバインドされている場合、 WLM は新規要求をホット・サーバントにディスパッチしようとします。 ホット・サーバントは、 最近の要求をディスパッチされ、使用可能なスレッドを持っています。 ホット・サーバントに手持ち作業が残っている場合、 WLM は作業を別のサーバントへディスパッチします。
ホット・サーバントは、必要なページがすべてストレージ内にあり、 ジャストインタイム (JIT) でコンパイルされたアプリケーション・メソッドが近くに保存されていて、 迅速なデータ検索用のデータが十分に入ったキャッシュがあると考えられるため、 通常、このホット・サーバント・ストラテジーの実行は適しています。 しかし、以下の状況の場合、このストラテジーは問題を起こします。
サーバントの類縁性のない着信 HTTP 要求の分散
お客様の構成で、 ホット・サーバント・ストラテジーでの問題の原因となる上記の状況のいずれかが生じる場合、 サーバントの類縁性なしで着信 HTTP 要求をサーバント全体に分散させることをサポートするように、 アプリケーション・サーバーを構成することができます。 この機能を使用可能にすると、アプリケーション・サーバーは、 サーバントに対して HTTP 要求のラウンドロビン分散を使用します。
次の例では、アプリケーション・サーバーが、 サーバント間の HTTP 要求でラウンドロビン分散を使用するように構成され、 同じサービス・クラスが割り当てられた作業キュー要求に対して、 複数のサーバントが開始されることを想定しています。
類縁性のない新規 HTTP 要求が作業キュー上に着信すると、WLM は、 作業を待機しているワーカー・スレッドが少なくとも 1 つはあるサーバントが存在するかどうかを確認します。 どのサーバントにも使用できるワーカー・スレッドがない場合、WLM は、 いずれかのサーバントのワーカー・スレッドが使用可能になるまで、要求をキューに入れます。 使用可能なワーカー・スレッドがある場合、WLM は、類縁性の数が最も小さいサーバントを検出します。 類縁性の数が等しいサーバント領域が存在する場合は、 WLM は、使用中のサーバー・スレッド数が少ない方のサーバント領域に、 作業をディスパッチします。
このアルゴリズムの目的は、WLM が、変化する条件を考慮しながら、 待機サーバント間でサーバント類縁性のない着信要求のバランスを取るということです。 このアルゴリズムは、 厳密なラウンドロビン方法でやみくもに要求をサーバーに割り当てるのではありません。 次の図では、HTTP セッション・オブジェクトがサーバント間で均等に分散される様子を示しています。
この分散メカニズムは、類縁性のないすべてのインバウンド要求に使用できます。 HTTP セッション・オブジェクトが作成された後、 すべてのクライアント要求は、HTTP セッション・オブジェクトが除去されるまでは、 そのサーバントに送信されます。
サーバントの類縁性のない着信 HTTP 要求の分散を使用可能にする場合は、 分類マッピング・ファイルを変更する必要があります。 分類マッピング・ファイルを、 WebSphere Application Server の管理対象ラウンドロビン・サポートのマッピング規則で 複数のトランザクション・クラスを指定するようにセットアップしている場合は、 分類マッピング・ファイルからこのセクションを除去してください。