Considerations for a multiple sysplex domain

A domain can be defined to include systems from more than one sysplex. With a multiple sysplex domain, you can provision middleware across more than one sysplex in your enterprise, which allows your cloud provisioning environment to scale beyond the scope of a single sysplex.

In this configuration, you create the domain from a sysplex that you designate as the primary z/OSMF system. The objects that you create on the primary z/OSMF system are managed domain objects on the z/OSMF systems for the secondary sysplexes that are included in the domain.

Specifically:
  • Tenants and templates that are created in the domain are managed tenant and template objects on the secondary z/OSMF systems.
  • Resource pools that are created in the domain are managed resource pool objects on the secondary z/OSMF systems that are included in the resource pool system list.
  • Registry instances that are created in the domain are managed registry instances on the secondary z/OSMF systems.

Managed domain objects can be viewed and used on any system in the domain. However, they are typically modified and removed only from the primary system.

Planning the systems for the domain

To participate in a multi-sysplex domain, the primary and secondary systems must be defined in the Systems table of the z/OSMF Systems task, configured to communicate with each other, and enabled for single sign-on.

For information about how to perform these setup actions, see the following:

For example, assume that your enterprise has three sysplexes and nine systems that are configured as shown in Figure 1. In this configuration, the z/OSMF instance in sysplex A is the primary z/OSMF instance. It manages sysplexes B and C by communicating (through HTTPS requests) with the secondary z/OSMF instances in sysplexes B and C.

Figure 1. A multiple sysplex configuration includes one primary z/OSMF system and one or more secondary z/OSMF systems
Depicts an example sysplex and system configuration.

The primary z/OSMF system is the one to which your web browser is connected, and it is the system that you use to create and modify objects in the domain. The other z/OSMF instances are referred to as secondary z/OSMF instances.

How provisioning is performed

In a multiple system configuration, creating and modifying templates and other objects is done from the sysplex that you designate as the primary z/OSMF system. Objects that are created on the secondary systems are managed by the primary z/OSMF system. To define the domain, templates and other objects, you use the Cloud Provisioning Resource Management and Software Services tasks. In the user interface, the objects that are created on the secondary sysplex are shown as managed. Managed objects are viewable and usable on the sysplex where they reside, but they should be modified and removed only from the primary system.

Table 1 shows the types of created objects that are managed from the primary system.
Table 1. Managed object types in a secondary sysplex
Object Description
Domain Domain for provisioning. When a domain is created in Cloud Provisioning the systems that are part of the domain are included in the definition. During domain creation, for each system in the domain that resides in a secondary sysplex, a managed domain is created in the Cloud Provisioning image in the secondary sysplex.
Tenant Tenant for provisioning. When a tenant is created in Cloud Provisioning, for each system in the domain that resides in a secondary sysplex where a managed domain exists, a managed tenant is created in the managed domain in the secondary sysplex.
Resource pool Resource pool for provisioning. A resource pool is created to define the resources in a template-to-tenant relationship. When a resource pool is created in a primary sysplex and the systems in the resource pool specify a secondary sysplex, the creation of the resource pool in the primary sysplex causes a managed resource pool to be created in the secondary sysplex.
  • If a template requires network resources, the network administrator must complete the network resource pool from each sysplex for the systems that are specified in the resource pool.
  • Start of changeIf a template requires WLM resources, the WLM administrator must complete the WLM resource pool from each sysplex for the systems that are specified in the resource pool. End of change
Template Template for provisioning. When a template is created in Cloud Provisioning, for each system in the domain that resides in a secondary sysplex where a managed domain exists, a managed template is created in the managed domain in the secondary sysplex.

Templates can be run only from the primary z/OSMF system.

Registry instance Registry instance for provisioning. When a template run or test run operation is performed on a template, if the target system is in a secondary sysplex, the provisioning workflow runs on the secondary sysplex. In this case, a managed registry instance is created on the secondary sysplex and the registry instance on the primary sysplex is updated to state of provisioning on the secondary sysplex.

Registry instance actions must be performed on the primary z/OSMF system. Besides Deprovision, these actions can include Start, Stop, and Check Status.

Rules for a multiple sysplex environment

Observe the following rules for a multiple sysplex environment:
  • Multiple sysplex domains, tenants, templates, and resource pools can be created and modified only from the primary sysplex. These objects should be removed from a secondary sysplex only in the event of an error, if they cannot be removed from the primary sysplex. Only the domain administrator can perform these actions.
  • Start of changeFrom z/OSMF on a secondary sysplex, do not create template, tenant, or resource pools in any "managed" domains. Templates, tenants, and resource pools for the managed domain must be created from the z/OSMF instance that is running in the primary sysplex. End of change
  • The primary sysplex and the secondary sysplexes must use the same cloud security mode: automatic or manual. A mix of automatic and manual cloud security modes between the primary and secondary sysplex is not supported.
  • User IDs and group IDs that are used within the domain must exist in both the primary and the secondary sysplex. If the sysplexes have separate security databases, the user and group IDs must be defined in each security database. For example, consider consumer user IDs.
  • Start of changeEach sysplex has its own default domain. A primary sysplex cannot manage the default domain in a secondary sysplex. The multiple sysplex capability is not applicable to the default" domain. A default domain includes systems from the local sysplex only.End of change
  • Lower-level network resources to be used in the secondary sysplex must be configured by using the z/OSMF Network Configuration Assistant task in the secondary sysplex, not the primary sysplex.
  • Start of changeLower-level WLM resources to be used in the secondary sysplex must be configured by using the z/OSMF Workload Management task in the secondary sysplex, not the primary sysplex.End of change
  • A multiple sysplex domain in a secondary sysplex includes only the z/OS systems in its local sysplex.
  • The z/OSMF system settings in the primary sysplex must contain system definitions for all of the systems in the multiple sysplex domain. The z/OSMF system settings in the secondary sysplex must contain the system definitions for the systems in the secondary sysplex. The system definition for a system in the z/OSMF system settings in the secondary sysplex must match the system definition for a system in the z/OSMF system settings in the primary sysplex. That is, the system nicknames, systems, and sysplex names must be identical in the primary sysplex and the secondary sysplex.
  • No more than one primary sysplex can be used to manage other secondary sysplexes.