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.

The following example shows the TCP/IP configuration profile statements for the primary and backup systems on which z/OSMF is running. The statements should be identical for both systems. The IP addresses specified in these examples are for illustration purposes only. You should work with your network team to obtain the appropriate host name that resolves to the DVIPA address for your installation.

PORT 443

In this example, the VIPADEFINE statement includes the subnet mask, 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.