The IBM Z hardware I/O configuration process with z/OS HCD

Hardware I/O configuration is the process to describe and implement the virtualization of a IBM Z server. For example, the latest IBM z16 server allows up to 40 TB of memory, roughly 200 processor cores, and nearly more than 200 physical and virtual adapters. There is no operating system today that can effectively utilize all of these resources. That’s why the server can be virtually divided into up to 85 customer logical partitions. A logical partition, or partition for short, is a virtual image describing the environment for an operating system instance. Like for a real server, the operating system needs to deal with devices, for example disks or adapters for network access. The I/O configuration describes the name of each partition and which of the hardware adapters and devices attached to the physical server are visible to the partition.

A very important operating systems supported on IBM Z servers is z/OS. z/OS is built for high availability of business workload. Some customers run their workload for decades without ever shutting it down. Therefore, the I/O configuration of the server is not static. While the workload continues to run, there are many reasons to change the I/O configuration. In general, there are two drivers for change. The primary ones are those driven by the workload. While applications and their usage grow or new applications are introduced, this can require additional I/O resources, for example more disks, new physical or logical networks, or even higher bandwidth.

Another driver for I/O configuration updates is change is in the infrastructure. While the workload continues for decades, the underlying hardware usually has a life span of only a few years. Then, it is usually replaced by newer hardware. The replaced hardware can affect the IBM Z server themselves, storage server, network infrastructure, cabling, or any other hardware. To accommodate for that, a controlled change process is necessary.

This article describes the overall change process for I/O configuration changes as it is today implemented by many customers using IBM z/OS Hardware Configuration Definition (HCD). HCD is the component of the z/OS operating system that is used to plan, validate, and activate I/O configurations. The I/O configuration change process is iterative and consists of multiple steps:

· Planning

· Implementation

· Activation

· Post-processing

All these steps will be described in more details in the following sections and how HCD is involved in these processes.

I/O configuration planning

Whenever you need to change the I/O configuration, you start with planning the changes. There are changes that usually do not need to too much effort in this step, for example, if you just add some existing disks to a existing z/OS partition. Others, like replacing an entire IBM Z server with a newer generation is a considerable large effort. Most of the planning is done without HCD involvement. It contains efforts to plan for space in the data center, energy, cabling, capacity, workload, operating system configuration, operations involvement, and many more. It it necessary to coordinate all the involved parties to make sure that change can be done with as few disruptions of the workload as possible. If you replace infrastructure, such as a storage server, you need to make sure the workload can always continue to run.

Getting directly from the currently active I/O configuration to the final target I/O configuration sometime would be disruptive. In this case, you need to plan changes in multiple steps with intermediate target I/O configurations. These intermediate configurations need to make sure that at any time, there is at least one path to the devices available so that the workload continues to run.

Implementation

Once you have planned the changes and how to process it in a way that is non-disruptive to your workload, you can start with the implementation. For I/O configuration with HCD, this means that you can start defining your target I/O configuration. You usually start with the current configuration and apply the changes you need. That can be done in any sequence in a so-called work IODF. An I/O Definition File (IODF) is HCDs repository to store the I/O configuration. Only at the end, you validate the complete target configuration whether it still fits the physical and logical limitation of the IBM Z server. If it does, the validation ends with a so-called production IODF. Once you have such an IODF, you could activate it. Nevertheless, for any larger change, you probably first want to make sure that what you entered in HCD is really what you want. HCD allows you to create some different configuration report, e.g., to allow you to verify your input, or to discuss with other people, whether this what they want to define or plug. That leads to an agreement that the target configuration fits the requirements. In addition to the infrastructure, you may also want to verify that the change can be implemented from an operational point of view. HCD allows you to test that with a so call test activation. More about I/O configuration activation can be found in the next section. In seldom cases, the test activate detects problems with the planning process, and you need to go back to the previous step and correct the problem.

Activation of I/O configuration changes

Having a validated target configuration (production IODF) and a list of operational per-requisites makes you ready to finally apply the I/O configuration changes.

Configuration changes are usually applied at a time when the amount of work in your system is reduced. The main reason is, that any error might disrupt the workload and you probably want to limit the effects of a problem. Such times of reduced work are usually some-when at night on a weekend. And also, the time to apply the changes is limited. Therefore, the target configuration should be applied with as few changes as possible. The I/O configuration changes are applied while the systems remain running. That’s why this is usually called dynamic activation.

Many changes are non-disruptive by their nature. For example, adding something is usually never problematic. In case that you change I/O configuration object or delete them, it’s often required that these elements are not active when applying the I/O configuration change. This needs to be prepared by operations. In simpler cases, you just take some I/O paths offline. In more complex changes it requires that you need to move workload, or even move coupling structure. In those case, the activation starts with some operational pre-processing.

Pre-processing are those operational tasks, that have been identified in the previous step. Usually, this means stopping application, taking devices offline, configuring paths offline, and alike. To validate that all operational pre-conditions have been done and are sufficient, you usually do a test activation. A test activation is like an activate as described in the next paragraph without actually implementing the change in hardware. If this reveals that there is still something in the way of a successful dynamic activation, then it needs to be checked whether this can be solved by operational means, or whether you must get back to the planning step.

If all pre-processing is done, you can start to apply the I/O configuration to your IBM Z server. In HCD this is called activating an IODF. In this step HCD calculates the minimal changes necessary to get from the active configuration to the target configuration. z/OS then checks whether these changes can be applied non-disruptively. Because you already did all pre-processing, there should not be any complains. Therefore, z/OS applies all the changes to the server. The I/O configuration of a server is maintained in it’s Hardware System Area (HAS) an server owned memory to store internal data. Once this is done, the activation is complete.

Post-Processing after a dynamic activation

A dynamic activation updates the server internal state, so that the new target configuration is active. You may want that these changes also apply in case you need to restart (Power-On Reset/POR) you server. Therefore, you need to store the newly activated configuration in a so called I/O Configuration Data Set (IOCDS) on the server. This operation can be initiated from within HCD.

Other post-processing might be to configure those hardware elements online that you configured offline in the pre-processing of the activation. If you added new devices, you make take them online. If the configuration added new hardware, for example new adapters, you may add them concurrently and take the online. This then completes the I/O configuration change.