Cloud Provisioning
This section, when the appropriate plug-ins are installed, describes the z/OSMF tasks that you can use to perform software provisioning for IBM Cloud Provisioning and Management for z/OS. This includes creating instances of z/OS or IBM® middleware, such as IBM CICS® (CICS), IBM Db2®, IBM Information Management System (IMS), IBM MQ, z/OS Connect, and IBM WebSphere® Application Server, and creating middleware resources, such as MQ queues, CICS regions, and Db2 databases.
Cloud provisioning makes it possible for consumers to quickly provision and deprovision an environment as needed.
Getting started
To provide access to the Cloud Provisioning function, a security administrator defines the IDs and roles that are required, such as the domain administrator (typically a middleware system programmer), network administrator, approvers, and consumers.
1. Define access and roles (Security administrator)
A security administrator is responsible for the security of the cloud configuration, including the various roles that are required, such as the provisioning administrator, domain administrator, network administrator, approvers, and consumers. For more information about setting up security for cloud provisioning, see Configure the Cloud Provisioning services in IBM z/OS Management Facility Configuration Guide.
2. Process a request for a development environment (Domain administrator)
The domain administrator, typically a middleware system programmer, processes a request for a new environment, which might come from an application development team. This request starts the efforts to use cloud provisioning to make the environment available.
The domain administrator can take advantage of cloud provisioning to make environments available to a development team when they are needed, while the z/OS system programmer (the provisioning administrator, described in the next step) retains control over what is provisioned and how many instances are provisioned.
3. Define a domain (Provisioning administrator)
Software services templates are associated with a domain, which defines a system or set of systems. A domain can include systems from more than one sysplex.
A provisioning administrator, typically a z/OS system programmer, decides which system or systems (LPARs) are used for provisioning and creates a domain. If the domain extends beyond one sysplex, the provisioning administrator configures a primary z/OSMF system for communicating with secondary z/OSMF systems.
The provisioning administrator identifies the domain administrator. The domain administrator is typically a middleware system programmer for the middleware that is to be provisioned. For more information about defining the provisioning administrator and domain administrator, see Configure the Cloud Provisioning services in IBM z/OS Management Facility Configuration Guide.
Tenants that are associated with a domain define users or classes of users of the domain.
To help you get started quickly, a default domain is provided. The default domain is fully operational without any further configuration, and is accessible to any z/OSMF administrator. A default tenant is associated with the default domain.
The systems in the domain must be included in the group of systems that are named IYUCLOUD in the Systems task of the z/OSMF Settings category. So, you might begin by verifying that the IYUCLOUD group contains the systems that you need.
- The systems that are to be used as potential targets for provisioning
- How the target system should be selected when the software service is provisioned: either automatically, by z/OSMF, or manually, by the consumer
- That the instance can be relocated to a system in the domain other than the system it was originally provisioned on. The instance can run on only one system at a time.
In a multiple-sysplex domain, creating and modifying objects is controlled from the primary z/OSMF system. From this system, the domain administrator can provision templates on other, secondary z/OSMF systems. For more information, see Rules for a multiple sysplex environment.
4. Create a software services template and define the tenant for the line of business (Domain administrator)
To make an environment available to consumers as a software service, a domain administrator creates and configures a software services template. The template describes what is provisioned. For example, a template might request that a Db2 subsystem be deployed onto a z/OS® system with three databases, or might create a set of CICS regions.
To provision the software, templates start and run z/OSMF workflows. A template includes a workflow definition file, along with other files, including a file that defines input variables for the workflow, and a file that defines actions that can be used against the provisioned software.
The domain administrator also defines a tenant for the development team, so that they can control how many instances of the software can be provisioned by that team, and the networking resources that they can use.
5. Customize the template and connect the template to resources (Domain administrator)
- Adds the software services template to a tenant.
- Connects the template to network, storage, and WLM resource pools. Resource pools are sets of z/OS resources that are required by the z/OS software service, for example, ports, IP addresses, or APPLIDs.
6. Create the pools of resources for the network and WLM (Network and WLM resource pool administrators)
When a template requires resource pools, for example, when you want to dynamically allocate ports to provisioned software instances, the network and WLM resource pool administrators (typically z/OS system programmers) use the appropriate z/OSMF tasks to complete the resource pools.
7. Approve the template
Offering self-service provisioning to a development team might require that some steps in the template, or certain actions, run under automation IDs. Any use of these user IDs in a template must be approved. Approval records are created for a template when a workflow or action definition file contains an element that identifies a user ID under which a workflow step or action is to be performed. (The workflow element is runAsUser ID, and the ID is sometimes referred to as a runAsUser ID). Approval records can also be defined for the template in general, and for a domain. Approval records must be approved by the approvers (typically identified by user ID) before the template can be tested or published.
8. Test and publish the software services template (Domain administrator)
The domain administrator tests the template to ensure that it successfully provisions the software, that is, creates the environment. Software that is provisioned from a template is known as a software services instance. (Note that this is different than a software instance that you manage with the Software Management task. A software instance is a collection of data sets containing installed software, and other data sets that may be associated with that installed software.) You manage a software services instance by using actions such as Remove and deprovision.
Publishing the template makes it available to consumers in the tenant – the application developers who require the new environment.
Use a marketplace to make software services available to consumers
The Cloud Provisioning tasks include a sample marketplace of software services and a sample function for administering the marketplace. From the marketplace, consumers such as application developers can use the software services to quickly create a software environment. You might use the samples as inspiration to build your own software services marketplace.
Tailored Fit Pricing for IBM Z
You can define a tenant as a container for Tailored Fit Pricing for IBM Z by specifying a solution ID for the tenant. Then, any software that you provision for that tenant is treated as part of the solution. This approach simplifies the setup that is required for Tailored Fit Pricing for IBM Z, because the Resource Management task does the z/OSMF Workload Management work for you, including creating the tenant resource group, tenant report class, and classifications.
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.
- 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.
- Each sysplex has its own default domain. A primary sysplex cannot manage the default domain in a secondary sysplex.
- 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.
- 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.
Summary of terms
The following are the key terms that you should be familiar with to exploit the Cloud Provisioning tasks.Resources
| Resource | Description |
|---|---|
| Domain | Defines the management scope for tenants, services, and resource pools. A domain consists of one or more z/OS systems. A domain can include z/OS systems from more than one sysplex. A z/OS system can be in a single domain or in multiple domains that are managed by a single instance of z/OSMF. A cloud domain is defined by a z/OS system programmer who acts as the provisioning administrator. Each cloud domain is assigned one or more middleware system programmers who act as domain administrators. A base z/OSMF configuration includes one domain by default — the default domain. |
| Resource pool | Identifies the z/OS resources that are required by a z/OS software service. In a cloud domain
with multiple tenants, the resource pool defines the scope of resource sharing and resource
isolation. For example, a resource pool can define a range of dedicated IP addresses or ports for
each tenant. A base z/OSMF configuration includes one resource pool by default — the default domain shared resource pool. |
| Tenant | Defines the group of users who have the authority to provision software instances. A tenant consists of a user or group of users that have contracted for the use of specified services and pooled z/OS resources that are associated with the services in a domain. A base z/OSMF configuration includes one tenant by default — the default tenant. |
User roles
| Role | Performer | Description |
|---|---|---|
| Provisioning administrator | z/OS system programmer | Defines the cloud domains and the associated system resources for the cloud. The provisioning administrator also designates one or more users as domain administrators. |
| Domain administrator | Middleware system programmer | Manages a domain. The domain administrator is responsible for defining services, tenants, and resource pools for the domain, and managing the relationship across tenants, services, and resource pools. |
| Resource pool networking administrator | Network administrator | Manages the resource pool for the networking resources in the cloud, such as network configuration policies. |
| Resource pool WLM administrator | Performance administrator | Manages the resource pool for the WLM resources in the cloud, such as WLM policies. |
| Security administrator | Security administrator | Maintains the installation's security manager, such as RACF. |
| Template approver | System programmer or security administrator | Responsible for approving the pending approval records that are associated with the template. |
| Consumer | Application programmer | Has access to the software services and resource pools for a tenant. This user can provision a software services instance by using a software services template, and can manage the lifecycle of a software services instance. |
Objects
| Object | Description |
|---|---|
| Instance, or software services instance | Represents software that is provisioned by using templates. |
| Template, or software services template | Represents z/OS or z/OS middleware, or a z/OS middleware resource service. A template consists of workflows and input variables that can be used to provision z/OS software, actions that can be used with the provisioned software (the instance), and documentation. |