(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 add new systems to meet demand as your workload grows, we might want to migrate your Application Server runtime and associated application servers from a monoplex to a sysplex configuration.

After installing the server runtime and associated business application servers on a monoplex, we should evaluate whether we want 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), 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 WAS. 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 we 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 us to:

• Balance the workload across multiple systems, thus providing better performance management for the 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.

If we 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 we have servers with duplicate cell names within the GRS environment, WAS 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.

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

Tasks

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 we 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. To have a single-system view of the error log, and initially we set up the error log in the system logger and used DASD for logging, we must now configure the error log in the coupling facility.
   2. Decide how we will share application executables in the cell.

   3. Set up ARM. This release does not support cross-system restart, so we must set up your ARM policy accordingly. Make sure we specify TARGET_SYSTEM for the system on which each element runs (if you take the default TARGET_SYSTEM=*, we get cross-system restart).
   4. Decide whether we 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.

      Server	Recommendations and requirements for running servers in a cell
      location service daemon and node agent	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 your 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, 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 your z/OS system.

5. Customize z/OS functions on the other systems in the sysplex to match the customization we 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, we must adjust the IP names in your 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 your sysplex.
   2. Install a deployment manager cell on one node in your sysplex.

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

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.

Add members to a cluster