The z/OS workload management (WLM) component in z/OS 1.4 and later supports distributing incoming HTTP requests without servant region affinity in a round robin manner across the servant regions. This functionality is intended for, but not limited to long lasting HTTP session objects that are maintained in memory, stateless session Enterprise JavaBeans (EJB), and the create method for stateful session enterprise beans. You can configure WebSphere Application Server for z/OS to use this functionality to spread HTTP requests among active servant regions that are currently bound to the same work queue as the inbound requests.
Background
The following diagram represents one clustered server instance. The azsr01 cluster contains the azsr01a application server instance. In the application server instance is a controller region, the workload manager (WLM) queue, and the servant regions where applications run. The controller region is the HTTP and IIOP termination point. The WLM queue controls the flow of work from the controller region to one of the servant regions. Each of the servant regions contains worker threads that select work from the WLM queue.
In the preceding diagram, the application server is configured to have the minimum and maximum number of servant regions set to three. For information about configuring the number of servant regions, see Controlling the number of servant regions.
There are WLM definitions for the application servers in this cluster. All of the requests for any application server instance in the azsr01 cluster are assigned to the same service class. The WLM classification rules assign all enclaves that are running in the azsr01a application server to the AZAMS1 service class. See the following diagrams for an example of the WLM service class definition and the classification rules.
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 *****************************
The hot server strategy
WebSphere Application Server for z/OS supports the use of HTTP session objects in memory for application servers with multiple servant regions. In the following diagram, two users accessed an application in the azsr01a application server instance. User 1 established an HTTP session object in servant region 3. User 2 established an HTTP session object in servant region 2.
When a user accesses a servant region without an established HTTP session object , no servant region affinity exists. Therefore, the request can be dispatched to any servant region that is available. WLM might start a new servant region if all of the following conditions exist:
When multiple servant regions are bound to the same service class, WLM attempts to dispatch the new requests to a hot servant region. A hot servant region has a recent request dispatched to it and has threads available. If the hot region has a backlog of work, WLM dispatches the work to another servant region.
Normally running this hot servant strategy is good because the hot servant region likely has all its necessary pages in storage, has the just-in-time (JIT) compiled application methods saved close by, and has a cache full of data for fast data retrieval. However, this strategy presents a problem in the following situations:
In the last situation, an undesired skew in the distribution of HTTP session objects is the result. In the following diagram, most of the HTTP session objects were assigned to servant region 1.
A large percentage of HTTP session objects reside in one or two servant regions because most of the time, there are not enough requests in the WLM queue to warrant dispatching work among many servant regions. This behavior can lead to the following undesirable results.
Distribute incoming HTTP requests without servant region affinity
If your configuration experiences one of the described situations that cause a problem with the hot servant region strategy, you can configure your application server to support the distribution of incoming HTTP requests across servant regions without servant region affinity. When you enable this functionality, the application server uses a round-robin distribution of HTTP requests to the servant regions.
In the following example, assume that the application server was configured to use the round-robin distribution of HTTP requests among the servant regions and multiple servant regions are started for the work queue requests that have the same service class assigned.
When a new HTTP request without affinity arrives on a work queue, the WLM checks to see if there is a servant region that has at least one worker thread waiting for work. If there are no available worker threads in any servant regions, WLM queues the request until a worker thread in any of the servant regions becomes available. If there are available worker threads, WLM finds the servant region with the smallest number of affinities. If there are servant regions with equal number of affinities, then WLM dispatches the work to the servant region with the smaller number of busy server threads.
The goal of this algorithm is for WLM to balance the incoming requests without servant affinity among waiting servant regions while considering changing conditions. The algorithm does not blindly assign requests to servers in a true round-robin manner. The following diagram shows the balanced distribution of HTTP session objects across servant regions.
This distribution mechanism works for all inbound requests without affinity. After the HTTP session object is created, all the client requests are directed to that servant region until the HTTP session object is removed the affinity.
If you decide to enable the distribution of incoming HTTP requests without servant region affinity, you might need to make some changes to your classification mapping file. If you have set up your classification mapping file to specify more than one transaction class on a mapping rule for WebSphere Application Server managed round robin support, you should remove this section from your classification mapping file.
For more information about configuring an application server to enable the distribution of incoming HTTP requests across servant regions without servant region affinity, see Configuring an application server to use the WLM even distribution of HTTP requests function.