![[z/OS]](../images/ngzos.gif)
WLM による HTTP 要求数の均等分散
z/OS® ワークロード管理 (WLM) コンポーネントは、サーバントのアフィニティーがなくても、着信する HTTP 要求をラウンドロビン方法でサーバント全体に分散する方法をサポートしています。 この機能は、メモリーに保持されて長く持続する HTTP セッション・オブジェクト、ステートレス・セッション Enterprise JavaBeans (EJB)、およびステートフル・セッション・エンタープライズ Bean の create メソッドを対象としていますが、これらに限定されているわけではありません。 現在インバウンド要求と同じ作業キューにバインドされているアクティブ・サーバント全体に HTTP 要求を分散させるため、この機能を使用するように製品を構成できます。
次の図は、クラスター・サーバー・インスタンスの一例です。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 *****************************
この製品は、複数のサーバントがあるアプリケーション・サーバーの場合に、メモリー内の HTTP セッション・オブジェクト を使用すること (これは、ホット・サーバント戦略とも呼ばれます) を サポートしています。次の図では、2 人のユーザーが、 azsr01a アプリケーション・サーバー・インスタンス内のアプリケーションにアクセスしています。ユーザー 1 は、サーバント 3 で HTTP セッション・オブジェクトを設定しました。 ユーザー 2 は、サーバント 2 で HTTP セッション・オブジェクトを設定しました。
- 構成が新規サーバントの作成を許可する場合。
- ワークロード・マネージャー・ロジックが、 システムで追加サーバントを維持できると判断した場合。
- 別のサーバントを追加することにより、キューの遅延が少なくなり、 別プログラムを指定した目標内で完了できる場合。
複数のサーバントが同じサービス・クラスにバインドされている場合、 WLM は新規要求をホット・サーバントにディスパッチしようとします。 ホット・サーバントは、 最近の要求をディスパッチされ、使用可能なスレッドを持っています。 ホット・サーバントに手持ち作業が残っている場合、 WLM は作業を別のサーバントへディスパッチします。
ホット・サーバントは、必要なページがすべてストレージ内にあり、 ジャストインタイム (JIT) でコンパイルされたアプリケーション・メソッドが近くに保存されていて、 迅速なデータ検索用のデータが十分に入ったキャッシュがあると考えられるため、 通常、このホット・サーバント・ストラテジーの実行は適しています。 しかし、以下の状況の場合、このストラテジーは問題を起こします。
- メモリーの HTTP セッション・オブジェクトが使用され、アフィニティーがディスパッチされます。
- HTTP セッション・オブジェクトが長時間または幾日も持続する。
- メモリー内に保持する必要のある HTTP セッション・オブジェクトを含んだ多数のクライアント。
- セッション・オブジェクトの喪失は、クライアントまたはサーバーに悪影響を及ぼし、 HTTP セッションを作成する要求間の時間が長くなります。
- アプリケーションが単一サーバント内に多数のオブジェクトを作成すると、 ガーベッジ・コレクションの時間が長くなる場合があります。
- HTTP セッション・オブジェクトがすべて 1 つのサーバントにバインドされると、 作業が WLM によって管理できず、任意のサーバントにディスパッチできないため、 要求が長時間キュー内に保留されることがあります。
- すべての HTTP セッション・オブジェクトが 1 つまたは 2 つのサーバント内にある場合は、 HTTP セッション・オブジェクトが複数のサーバントに均等に分割されている場合と比べて、 単一サーバント内のタイムアウトがより多くのユーザーに影響を与える可能性があります。
お客様の構成で、 ホット・サーバント・ストラテジーでの問題の原因となる上記の状況のいずれかが生じる場合、 サーバントのアフィニティーなしで着信 HTTP 要求をサーバント全体に分散させることをサポートするように、 アプリケーション・サーバーを構成することができます。 この機能を使用可能にすると、アプリケーション・サーバーは、 サーバントに対して HTTP 要求のラウンドロビン分散を使用します。
次の例では、アプリケーション・サーバーが、 サーバント間の HTTP 要求でラウンドロビン分散を使用するように構成され、 同じサービス・クラスが割り当てられた作業キュー要求に対して、 複数のサーバントが開始されることを想定しています。
アフィニティーのない新規 HTTP 要求が作業キュー上に着信すると、WLM は、 作業を待機しているワーカー・スレッドが少なくとも 1 つはあるサーバントが存在するかどうかを確認します。 どのサーバントにも使用できるワーカー・スレッドがない場合、WLM は、 いずれかのサーバントのワーカー・スレッドが使用可能になるまで、要求をキューに入れます。 使用可能なワーカー・スレッドがある場合、WLM は、アフィニティーの数が最も小さいサーバントを検出します。 アフィニティーの数が等しいサーバント領域が存在する場合は、 WLM は、使用中のサーバー・スレッド数が少ない方のサーバント領域に、 作業をディスパッチします。
このアルゴリズムの目的は、WLM が、変化する条件を考慮しながら、 待機サーバント間でサーバント・アフィニティーのない着信要求のバランスを取るということです。 このアルゴリズムは、 厳密なラウンドロビン方法でやみくもに要求をサーバーに割り当てるのではありません。 次の図では、HTTP セッション・オブジェクトがサーバント間で均等に分散される様子を示しています。
この分散メカニズムは、アフィニティーのないすべてのインバウンド要求に使用できます。 HTTP セッション・オブジェクトが作成された後、 すべてのクライアント・リクエストは、HTTP セッション・オブジェクトが除去されるまでは、 そのサーバントに送信されます。
サーバントのアフィニティーのない着信 HTTP 要求の分散を使用可能にする場合は、 分類マッピング・ファイルを変更する必要があります。 製品が提供する管理対象ラウンドロビン・サポートのマッピング規則で、複数のトランザクション・クラスを指定するように分類マッピング・ファイルをセットアップしている場合は、分類マッピング・ファイルからこのセクションを除去してください。