(zos)

Set up the Server Runtime on multiple systems in a sysplex

If the applications require workload balance, and high availability, and we want the ability to easily add new systems to meet demand as the workload grows, you might want to migrate your Application Server runtime and associated application servers from a monoplex to a sysplex configuration.

After you install the server runtime and associated business application servers on a monoplex, you should evaluate whether to migrate the server runtime and associated application servers to a sysplex configuration. If we 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 we 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 the 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 running the BBOWWPFA job.

/*JOBPARM SYSAFF=sxx

where sxx is the name of z/OS image in which we are going to run the product.

A sysplex environment enables you to:

• Balance the workload across multiple systems, thus providing better performance management for the applications.

• Add new systems to meet demand as the workload grows. This capability provides a scalable solution to the 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 the users.

Avoid trouble: For 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 we 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.gotcha

Perform the following tasks to setup the Application Server in a sysplex configuration.

1. 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

   

2. Configure the Server runtime for a sysplex environment.

   1. Decide whether we want a single-system view of the error log. If we 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.

   2. Decide how you will share application executables in the cell.

   3. Set up ARM. This release does not support cross-system restart, so set up the ARM policy accordingly. Make sure specified TARGET_SYSTEM for the system on which each element runs (if you take the default TARGET_SYSTEM=*, you get cross-system restart).

   4. 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.

      provides recommendations and requirements for running servers in a

      Server	Recommendations and requirements for running servers in a cell
      location service daemon and node agent	We must run both the location service daemon and the node agent on each system in the sysplex in which we want the server runtime to run. If the server runtime is not installed on some of the systems in the sysplex, we 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.

3. Prepare the security system.

4. Set up data sharing. Refer to the DB2 Data Sharing: Planning and Administration publication for the version of DB2 running on the z/OS system.

5. 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.

6. 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.

   1. Change DNS entries.

      If we 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 the DNS. We 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.

   2. 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, 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.

7. Define new application server clusters in the sysplex.

8. Optional: Create deployment manager cells.

   1. Install the default application server on each node in the sysplex.

   2. Install a deployment manager cell on one node in our sysplex.

   3. Add default server nodes to the deployment manager cell.

Results

We can take advantage of all of the benefits of running the applications on multiple systems in a sysplex.

What to do next

Migrate the applications to the sysplex.

Related tasks

Add members to a cluster