This chapter introduces storage tiering and Transparent Cloud Tiering (TCT) with the
IBM DS8000 and its potential benefits for data storage needs.

Traditional management of data across tiers is available across several devices at your site. We included this topic to review what might already be in place in your environment and why you might want to use cloud object storage as a tiering option based on TCT.

This chapter includes the following topics:

Systems have a finite amount of resources that can be used to store data, whether online or with auxiliary storage. The use of different storage media and categorizing the data within each layer can be an efficient way to manage storage resources. This management allows critical data to be available in high-performance devices, and other data on lower-cost devices.

There are two solutions available for storage tiering: Hardware and software implementation. Each technique can be used alone, or combined, to provide improved data management, and storage efficiency.

The next two sections introduce the concepts behind hardware and software tiering.

The hardware layers consist of the following storage areas:

Storage media that is used in mainframe systems has changed dramatically, from drives that can store a few megabytes, to current drives that can store terabytes, or flash technologies that provide increased performance gains over spinning disk drives.

Former DS8000 systems might be configured with a mix of flash cards, SSD, Enterprise, and Nearline media and managed by IBM Easy Tier®. This approach enables the system hardware to constantly monitor data extents (or track group, for small extents). Recent models, such as some of the DS8880 and the DS8900F devices, come as all flash configurations only, but can still benefit from Easy Tier to take advantage of different flash tiers and rebalance extents within a rank.

Another layer that is available under storage hardware management includes offline media. Offline media includes any media that cannot be directly accessed by a computer, unless it is made available to the system.

Virtual and physical tapes are considered offline media, and can also be part of hardware storage layers. Although the direct access storage device’s hardware cannot directly migrate data to tapes, you can use software tiers to accomplish this migration. Also, Virtual Tape Libraries use disk storage to emulate tapes, which are offloaded to physical tapes when the cache is full. This process is known as pre-migration.

When the requested data is stored in physical tapes, they are mounted, and the virtual tape content is loaded into the Virtual Tape Library and made available for z/OS read. The process of recovering data from physical tapes to cache is also known as recall.

Unlike hardware tiers, there are two types of storage devices available from a z/OS perspective: disk and tape. It is necessary to have a storage management product, such as DFSMShsm, to enable the use of software tiers. DFSMShsm can manage data by migrating, recalling, backing up, and recovering data sets as required.

DFSMShsm can manage storage tiers by using the SMS Management Class construct to identify data sets that can be moved to other tiers based on time since last access or creation. The following tiers are available on DFSMShsm:

These SMS or non-SMS direct access storage device volumes store online data, and can be directly accessed by TSO users, Jobs, or applications. These volumes are managed by DFSMShsm, but are not owned by it.

These non-SMS direct access storage device volumes contain data that is migrated from L0 volumes based on Management Class attributes. The data in these volumes is owned by DFSMShsm and cannot be directly read by users or applications. If a read/write operation is required, the data set is recalled to L0 volumes before they can be read. To use a volume as ML1, an ADDVOL command must be included on DFSMShsm parmlib or dynamically added. If dynamically added, this configuration is reset during DFSMShsm restart.

This second level of DFSMShsm migration often is designated for large data sets or long retention periods. These volumes are a set of non-SMS tapes (physical or virtual) or low-performance direct access storage device volumes that are owned by DFSMShsm. The data in these volumes cannot be directly read by users or applications unless they are recalled to L0 volumes first.

A class transition is a change in the object's management class or storage class. Class transition was introduced in z/OS V2R1, which enables DFSMShsm to also manage and migrate data set laterally within L0 volumes. By implementing the use of class transition, you can create pools with different performance levels and move your data between these volumes as they age.

Newly created data sets might require high-performance levels. These performance requirements can decrease as the data ages, but the data still must be accessed. In this case, migrating the data to ML1 volumes is not an option because this data is still required by applications. However, leaving this data on high-performance direct access storage device for an extended period reduces the ROI on the high-performance direct access storage device and might deny access for other data with high-performance needs.

Using class transition provides a balanced approach to managing the change in performance needs of data by allowing DFSMShsm to migrate data sets between different Storage Groups.

DFSMShsm uses Management Class attributes to define the following migration policies:

Class transitioning can be started through Primary, Interval, or on-demand migrations. It can also be started by using a user-issued command. An example of this command would be:

After it is started, it references Management Class policies to select the data sets for transition. If it is eligible, DFSMShsm starts Automatic Class Selection (ACS) routines to assign a new Storage Class, Management Class, or Storage Group. If the Storage Group changes, DFSMShsm attempts to move the data set to the new pool.

Figure 1-1 shows the sample implementation of class transition. The data is first allocated in high-performance direct access storage device, and then it transitions to cost-efficient devices as the data ages and the data’s performance requirement drops. Later, you can migrate the data to even more cost-efficient levels (ML1/ML2).

The tiering capability adds depth to a storage management strategy. If your data storage consists of a “flat” structure, such as being held in a single large direct access storage device pool, your options for application quality are limited. A multi-tiered structure (as shown in Figure 1-1) provides opportunities to enrich your business applications through the following qualities of service:

DFSMShsm is the z/OS component responsible for performing the Information Lifecycle Management task. As such, it is responsible for moving data between the different storage tiers, including both Online and Offline media types, like direct access storage device and Tape respectively, based on predefined policies and data access availability needs.

Figure 1-2 shows how the data flows between these distinct technologies, through DFSMShsm, and the challenges related to lifecycle management.

To move the data between the tiers, Data Facility Storage Management Subsystem (DFSMS) uses Hierarchical Storage Manager (HSM) and Data Storage Services (DSS) Data Movers to read the data from the source storage and write the data to the target storage, through
IBM FICON connectivity. Online media access format is different than Offline media access format.

During the processing of the data movement from disk to tape, DSS reads the data from the source media, passes it to HSM, which converts the data into 16 KB blocks, and writes the data to tape. This movement of data from disk to tape flows through the mainframe, and consumes extra central processing unit (CPU) cycles.

As you can imagine to process all these operations, the system uses IBM zSystems CPU cycles that could be used for other important workloads, such as business applications.

Other challenges of migrating data to tape include the lack of colocation for the data sets, meaning data with different retention will be placed in the same tape, which will also create the need of a recycle process to increase tape usage efficiency. The serial access to tape also prevents the recall of multiple data sets that are stored on the same tape. Otherwise, the system tries to run those data sets concurrently.

TCT for IBM DS8000 was introduced to help customers use storage and IBM zSystems resources more efficiently. With its integration with z/OS through DFSMShsm, TCT allows clients to reduce CPU utilization by eliminating constraints that are tied to the original tape methodologies.

This improvement is accomplished by enabling direct data movement from IBM DS8000 to cloud object storage, without the need for the data to go through the host. DFSMS communicates with DS8000 through a Representational State Transfer (REST) API interface and issues commands for the DS8000 to move the data directly to and from the cloud, as shown in Figure 1-3.

In this way, TCT offloads all the actual data movement processing-related workload from z/OS. Significant CPU savings result, as compared with the traditional data movement methods, especially when considering large data sets.

The CPU savings that are expected are achieved by reducing or eliminating CPU processing for the following tasks:

This approach also gives organizations flexibility to choose the most appropriate Offline media option, depending on cost, performance, and availability requirements.

In addition to HSM, TCT also supports DFSMSdss data set level and full volume dump (FVD) and restore to cloud object storage.

With DS8900F Release 9.1 and later, TCT also supports encryption for data that is stored in storage cloud. TCT supports secure data transfer over Transport Layer Security (TLS) and optionally compression of data that is transferred to the TS7700 used as object storage.

With DS8900F R 9.2, TCT multi-cloud support was introduced. You can now define up to eight cloud storage targets. Each of them can be its own type and can be used for its own purpose, application, or type of data.