Configuring z/OSMF for availability
In a z/OSMF context, availability refers to the ability to restart z/OSMF on another system in the sysplex, in the event of a failure in z/OSMF on the original system. Restarting the server is accomplished manually, though the START command. This topic describes how to configure z/OSMF for availability in a sysplex environment. Some considerations described here are applicable to any application that you might want to deploy in a sysplex environment.
Make the z/OSMF user directory shareable
Each active instance of z/OSMF requires its own user directory, which contains the persisted data for the instance. By default, the z/OSMF configuration process creates the user directory at the non-sharable mount point /var/zosmf, but you might have selected another mount point for it when you installed z/OSMF. The user directory is specified on the USERDIR= parameter of the START command for z/OSMF.
Generally, you should configure z/OSMF so that one instance can be started on any system in the sysplex. To allow the same instance z/OSMF to be started on other systems in the sysplex, ensure that the user directory mount point is shared by all of the systems on which you might want to start z/OSMF. Or, you can specify a common, root directory for this mount point, such as /sharedapps (with a shared mount point and volume) that is read/write accessible from other systems in the sysplex. Then, you can simply restart the z/OSMF server on another system. If you use a shared security database, this procedure is further simplified because the backup instance can use the same user IDs and groups as your primary instance. For information about mounting file systems, see z/OS UNIX System Services Planning.
If you plan to run more than one instance of z/OSMF in a sysplex, you require a unique user directory (and file system name) for each instance. Consider using the system name to qualify the name of the file system. For example: IZU.<system-name>.SIZUUSRD.
Ensure that the z/OSMF host name is unique
When using z/OSMF in a multi-system environment, each instance of z/OSMF must have a unique host name. Otherwise, users cannot log in to z/OSMF. This topic describes a technique for using system symbols to create unique host names for cloned z/OSMF configurations.
In the IZUPRMxx parmlib member, you can define a host name for your configuration. You can specify an installation-specific value, or accept the default, HOSTNAME(*), which instructs z/OSMF to do a host name lookup on the system.
In addition to using system symbols, you can use the z/OS Communications Server dynamic VIPA (DVIPA) function to create a DVIPA address for your sysplex, and use the DVIPA address as the z/OSMF host name. This approach allows users to connect to z/OSMF using the same IP address, regardless of which system is running z/OSMF. In a multiple sysplex environment, you might still use symbols, perhaps to represent a different DVIPA address for each sysplex. For considerations, see Use a DVIPA address for the z/OSMF host name .
Use a DVIPA address for the z/OSMF host name
You can use the z/OS Communications Server TCP/IP sysplex networking dynamic VIPA (DVIPA) function to help ensure the availability of z/OSMF. Along with your primary z/OSMF instance, you can create a backup instance in your installation. The backup z/OSMF instance can be started if the primary instance becomes unavailable. With DVIPA, your installation can use the same connection information when your active instance moves from the primary system to the backup system. This action allows z/OSMF to bind again to the same DVIPA address, and resume operation at the same location.
VIPADYNAMIC
VIPADEFINE MOVE IMMEDIATE 255.255.252.0 10.12.5.39 ; z/OSMF
VIPADISTRIBUTE DEFINE
SYSPLEXPORTS
10.12.5.39
PORT 443
DESTIP 10.1.100.74 10.1.100.75
ENDVIPADYNAMIC
In this example, the VIPADEFINE statement includes the subnet mask 255.255.255.255, which is used as the mask for the single DVIPA that is being defined. You can also define a larger, less-specific, subnet mask. However if you only specify one DVIPA on the VIPADEFINE statement and its corresponding VIPADISTRIBUTE statements, then that DVIPA is the only IP address that is defined and distributed. The PORT parameter included in this example is used to bind the port reserved for the z/OSMF instance that you are configuring to the specified DVIPA. This binding enables z/OSMF to become eligible to receive connection requests.
For an overview of TCP/IP sysplex networking, see z/OS Communications Server IP Configuration Guide. For a description of the VIPADYNAMIC statement, see z/OS Communication Server IP Configuration Reference.