Balancing workloads

You should use server clusters and cluster members to monitor and manage the workloads of application servers.

You should understand the options for configuring application servers. To assist you in understanding how to configure and use clusters for workload management, consider this scenario. Client requests are distributed among the cluster members on a single machine. A client refers to any servlet, Java application, or other program or component that connects the end user and the application server that is being accessed.

(dist) In more complex workload management scenarios, we can distribute cluster members to remote machines.

(zos) In more complex workload management scenarios, we can distribute cluster members within the same sysplex.

Perform the following steps if you decide to use clusters to balance the workload.

1. Decide which application server to cluster.

2. Decide whether to replicate data. Replication is a service that transfers data, objects, or events among application servers.

   We can create a replication domain when creating a cluster.

3. Deploy the application onto the application server.

4. Create a cluster.

   After configuring the application server and the application components exactly as we want them to be, create a cluster. The original server instance becomes a cluster member that is administered through the cluster.

5. Create one or more cluster members.

6. Configure a backup cluster.

   Avoid trouble: If we have clients running in an environment:

   • That includes Java thin clients,

   • Where requests are being routed between multiple cells, or

   • Where requests are being routed within a single cell that includes nodes from earlier versions of the product,

   they might suddenly encounter a situation where the port information about the cluster members of the target cluster has become stale.

   This situation most commonly occurs when all of the cluster members have dynamic ports and are restarted during a time period when no requests are being sent. The client process in this state will eventually attempt to route to the node agent to receive the new port data for the cluster members, and then use that new port data to route back to the members of the cluster.

   If any issues occur that prevent the client from communicating with the node agent, or that prevent the new port data being propagated between the cluster members and the node agent, request failures might occur on the client. In some cases, these failures are temporary. In other cases we need to restart one or more processes to resolve a failure.

   To circumvent the client routing problems that might arise in these cases, we can configure static ports on the cluster members. With static ports, the port data does not change as a client process gets information about the cluster members. Even if the cluster members are restarted, or there are communication or data propagation issues between processes, the port data the client holds is still valid. This circumvention does not necessarily solve the underlying communication or data propagation issues, but removes the symptoms of unexpected or uneven client routing decisions. gotcha

   A backup cluster handles requests if the primary cluster fails.

7. Start the cluster.

   When you start the cluster, all of the application servers that are members of that cluster start. Workload management automatically begins after the cluster members start.

8. After the cluster is running, we can perform the following tasks:

   • Stop the cluster.

   • Upgrade the applications that are installed on the cluster members.

   • Detect and handle problems with server clusters and their workloads.

   • Change how frequently the workload management state of the client refreshes.

     The default timeout value for the com.ibm.CORBA.RequestTimeout JVM property is 0, which means wait forever. This default value is not a good setting to have for failover situations. If the application is experiencing problems with timeouts, or if we have configured the system for failover situations, use the -CCD option on the LaunchClient command to set an appropriate non-zero value for this property.

     If the workload management state of the client refreshes too soon or too late, change the interval setting of the JVM custom property com.ibm.websphere.wlm.unusable.interval.

(iseries)(dist)

What to do next

For stand-alone Java clients, define a bootstrap host. Stand-alone Java clients are clients that are located on a different machine from the application server and have no administrative server. Add the following line to the Java virtual machine (JVM) arguments for the client:

-Dcom.ibm.CORBA.BootstrapHost=machine_name

where machine_name is the name of the machine on which the administrative server is running.

Subtopics

• Clusters and workload management
  Clusters are sets of servers managed together and participate in workload management. Clusters enable enterprise applications to scale beyond the amount of throughput capable of being achieved with a single application server. Clusters also enable enterprise applications to be highly available because requests are automatically routed to the running servers in the event of a failure. The servers that are members of a cluster can be on different host machines. In contrast, servers that are part of the same node must be located on the same host machine. A cell can include no clusters, one cluster, or multiple clusters.

• (zos) Workload management (WLM) for z/OS
  Workload management optimizes the distribution of incoming work requests to the application servers, enterprise beans, servlets, and other objects that can most effectively process the requests. Workload management also provides failover when servers are not available, improving application availability.

• (zos) Set up a highly available sysplex environment
  Setting up a highly available sysplex environment enables you to control application rollout and workload routing.

• (zos) Enable multiple servants on z/OS
  Use this task to enable multiple servants on the system. Enable multiple servants improves the performance of the product on z/OS..

• (zos) Classifying z/OS workload
  Use a common workload classification document to classify inbound HTTP, IIOP, Session Initiation Protocol(SIP), optimized local adapter, and message-driven bean (MDB) work requests for the z/OS workload manager.

• Create clusters
  A cluster is a set of application servers that you manage together as a way to balance workload.

• (iseries)(dist) Create backup clusters
  Use this task to configure a backup cluster that handles EJB requests if the primary cluster fails.

• Start clusters
  We can start all members of a cluster at the same time by requesting that the state of a cluster change to running. That is, we can start all application servers in a server cluster at the same time.

• Add members to a cluster
  Use clusters to balance workload in an environment containing multiple application servers.

• Replicating data across application servers in a cluster
  Use this task to configure a data replication domain to transfer data, objects, or events for session manager, dynamic cache, or stateful session beans. Data replication domains use the data replication service (DRS), which is an internal component that performs replication services, including replicating data, objects, and events among application servers.

• Delete clusters
  Use this task to remove a cluster and all of its cluster members.

• Tune a workload management configuration
  We can set values for several workload management client properties to tune the behavior of the workload management runtime.

• Troubleshooting workload management
  

Related concepts

Introduction: Clusters

Cluster member settings

Cluster member collection

Server cluster settings

Server cluster collection