You should use server clusters and cluster members to monitor and manage the workloads of
application servers.
Before you begin
You should understand your 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.
In more complex workload management scenarios, you can distribute cluster members
to remote machines.
In more complex workload management scenarios, you can distribute cluster members
within the same sysplex.
About this task
Perform the following steps if you decide to use clusters to balance your
workload.
Procedure
- Decide which application server you want to cluster.
- Decide whether you want to replicate data. Replication is a service that transfers data,
objects, or events among application servers.
You can create a replication domain when creating a cluster.
- Deploy the application onto the application server.
- Create a cluster.
After configuring the application server and the application components exactly as you want them
to be, create a cluster. The original server instance becomes a cluster member that is administered
through the cluster.
- Create one or more cluster members.
- Configure a backup cluster.
Avoid trouble: If you 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 you need to restart one or more processes to resolve a failure.
To
circumvent the client routing problems that might arise in these cases, you 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.
A backup cluster handles requests if the primary cluster fails.
- 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.
- After the cluster is running, you 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. Therefore,
if your application is experiencing problems with timeouts, or if you have configured your 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.
What to do next
For stand-alone Java clients, you must 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.