If your applications require workload balance, and high
availability, and you want the ability to easily add new systems to
meet demand as your workload grows, you might want to migrate your
Application Server runtime and associated application servers from
a monoplex to a sysplex configuration.
Before you begin
After you install the server runtime and associated business
application servers on a monoplex, you should evaluate whether you
want to migrate the server runtime and associated application servers
to a sysplex configuration. If you decide to set up a sysplex environment
that consists of several z/OS images and workload management (WLM),
you must run the BBOWWPFA job in the z/OS image on which you are starting WebSphere® Application Server.
The BBOWWPFA
job is one of the jobs that are automatically generated when you initially
configure and customization WebSphere Application Server. You run this
batch of jobs to set up your z/OS environment. Typically these JCL
jobs are executed one by one in the first z/OS image that is available
on the sysplex. However, the BBOWWPFA job, which sets up the runtime
(configuration) file system for the product must run in the same z/OS
image as where you plan to start the product. To ensure that the BBOWWPFA
job runs in the proper image, add the following JCL statement, after
the BBOWWPFA job statement, within the batch of automatically generated
JCL statements, before you run the BBOWWPFA job.
/*JOBPARM SYSAFF=sxx
where sxx is
the name of z/OS image in which you are going to run the product.
About this task
A sysplex environment enables you to:
- Balance the workload across multiple systems, thus providing
better performance management for your applications.
- Add new systems to meet demand as your workload grows. This capability
provides a scalable solution to your processing needs.
- Replicate the runtime and associated business application servers.
This capability ensures that if a failure occurs on one system, other
systems are available to handle user requests.
- Upgrade the Application Server from one release or service level
to another without interrupting service to your users.
Avoid trouble: ![[aug2010]](../../delta.gif)
If you
are using a global resource serialization (GRS) ring to attach one
or more monoplexes to a sysplex environment, the cell name of any
servers running in any of the monoplexes must be unique within the
entire GRS environment. This requirement means that the cell name
of a server running in any of the monoplexes:
- Must be different than the cell name of any servers running in
the sysplex
- Must be different than the cell name of any servers running in
another monoplex that is attached to the sysplex
If you have servers with duplicate cell names within the GRS
environment,
WebSphere Application Server
cannot differentiate between the sysplex cell and the monoplex cell,
and treats both servers as part of the same cell, This inaccurate
cell association typically causes unpredictable processing results.
![[aug2010]](../../deltaend.gif)
aug2010
gotcha
Perform
the following tasks to setup the Application Server in a sysplex configuration.
Procedure
- Set up a sysplex environment if one is not already available.
The z/OS® publication z/OS MVS™ Setting
Up a Sysplex describes how to set up a z/OS sysplex. The directory
you set up should be similar to the following directory structure:
Figure 1. Directory structure for two Application Servers running in
a Sysplex

- Configure the Server runtime for a sysplex environment.
- Decide whether you want a single-system view of the
error log. If you want a single-system view of the error
log, and initially you set up the error log in the system logger and
used DASD for logging, you must now configure the error log in the
coupling facility.
- Decide how you will share application executables in
the cell.
- Set up ARM. This release does not support
cross-system restart, so you must set up your ARM policy accordingly.
Make sure you specify TARGET_SYSTEM for the system on which each element
runs (if you take the default TARGET_SYSTEM=*, you get cross-system
restart).
- Decide whether you will run all of the run-time servers
on every system in the cell.
Recommendations:
The following table provides recommendations and requirements for
running servers in a cell.
Table 1. Running servers in a cell. The following table
provides recommendations and requirements for running servers in a
cell.
Server |
Recommendations
and requirements for running servers in a cell |
location
service daemon and node agent |
- You must run both the location service daemon and the node agent
on each system in the sysplex in which you want the server runtime
to run. If the server runtime is not installed on some of the systems
in your sysplex, you do not have to run a location service daemon
and node agent on those systems.
- If a server indicates that PassTickets are desirable for interaction
with a client, you must run the location service daemon and node agent
on the system where the z/OS client resides.
|
deployment
manager |
Make
sure you follow the correct steps to configure a deployment manager
cell. |
- Prepare your security system.
- Set up data sharing. Refer to the DB2® Data
Sharing: Planning and Administration publication for the version
of DB2 that is running on your z/OS system.
- Customize z/OS functions on the other systems in the sysplex
to match the customization you performed as part of the initial server
runtime installation.
Complete customization information
for additional systems is contained in the generated customization
instructions.
- Change the TCP/IP settings. Each system in a
sysplex contains a location service daemon, node agent, and business
application servers. The location service daemon acts as a location
service agent and accepts locate requests with object keys in the
requests. Therefore it is important that the TCP/IP domain name server
(DNS) entries, and TCP/IP profile for each system in the cell include
the port for the location service daemon, and that port is associated
with the name of the new location service daemon server.
- Change DNS entries.
If you use a DNS implementation
that allows the use of generic IP names that dynamically resolve to
like-configured servers, you must adjust the IP names in your DNS.
You must keep the generic IP name of the location service daemon,
but add a new IP name for the second and subsequent location service
daemon servers. The additional IP names enable the DNS to direct work
to other servers if a failure occurs.
- In the TCP/IP profile for each additional system in
the cell, add a port for the location service daemon, and associate
that port with a new location service daemon server name.
By
default, the server runtime uses port 5655 for the location service
daemon. The server runtime also names the first location service daemon
server DAEMON01 and increments the suffix on that name for each new
location service daemon server; for example, DAEMON02, DAEMON03, and
so forth. Therefore, for the second system in the sysplex, you must
add a port and associate it with DAEMON02.
Example: 5655
TCP DAEMON02
Follow the same pattern for the third and subsequent systems
in the sysplexl.
- Define new application server clusters in the sysplex.
- Optional: Create deployment manager cells.
- Install the default application server on each node
in your sysplex.
- Install a deployment manager cell on one node in your
sysplex.
- Add default server nodes to the deployment manager cell.
Results
You can take advantage of all of the benefits of running your
applications on multiple systems in a sysplex.
What to do next
Migrate your applications to the sysplex.