Managing High Availability › How to Implement HA Automatic Restart Management › Identify How to Manage an Alternate LPAR Failure

Identify How to Manage an Alternate LPAR Failure

Use this topic to determine your plan for failing to an alternate LPAR.

Consider the following scenarios:

1. If you use the Knowledge Center to index content only available on the LPAR where CA Chorus is running, this content is not available when the product switches to a different LPAR. Switching can occur when you have configured the product for High Availability (HA). After the product reverts to the LPAR where the content resides, the content is available.
2. Determine your LPAR configuration:
   • When an address space fails on a healthy LPAR, ARM automatically restarts the address space on the LPAR where it failed.
   • If ARM is configured for a sysplex environment with more than one LPAR and the LPAR where CA Chorus is running fails, ARM can automatically restart all started tasks in order on an alternate LPAR in the same sysplex. To accomplish this goal for the CA Chorus Application server, mount the product zFS file systems on the alternate LPAR before the CA Chorus Application Server can start. Review and identify the best option for this configuration:

     Important! To the mount the zFS file system, CHORADM requires an OMVS segment with READ access to BPX.SUPERUSER. For example, IBMFAC(BPX.SUPERUSER) ACCESS(READ).

     • Create a set of mirror file systems on the alternate LPAR for read/write.

       Of the file systems that are created during product installation, only CETJZFS0, CETJLOGS, and CETJDB are required to be mounted as read/write. All other file systems can be mounted read-only on both LPARs. You can then create alternate copies of the three read/write file systems so that each LPAR has its own copy of the file systems. You would then need to periodically synchronize the CETJDB file system between the systems. The disadvantage to this configuration is that the CETJDB file system does not contain updates that CA Chorus has made on the primary LPAR since the last synchronization.

     • Mount the file systems on both LPARs using zFS sysplex-aware file systems.

       Starting with z/OS v1.11, you can run zFS as sysplex-aware. The read/write file systems can be mounted simultaneously on the primary and alternate LPARs.

     • Add a step to CHORJBOS on the alternate LPAR to mount the file systems before the CA Chorus Application Server step.

       Because the CA Chorus Application Server only starts on the alternate LPAR when the primary LPAR fails, do not mount the file systems in another location when the alternate CA Chorus Application Server starts. If a step is added to the CHORJBOS started task to execute MOUNT commands for the necessary file systems, the CHORJBOS on the alternate LPAR continues using the data from the primary LPAR. This setup means that you cannot restart the CA Chorus Application Server on the primary LPAR until you shut down the server on the alternate LPAR. You must also unmount the file systems.

       Note: If you choose this option, implement it during Modify the Started Task JCL for the ARM Wrapper.

       So, a situation cannot arise where the server is running simultaneously on two different LPARs. This situation could occur with the other options.