Hu's Blog

In a recent post I described the different forms of tiering. Today I’d like to discuss another form of tiering that is used in the mainframe: Hierarchical Storage Management or HSM. This is a licensed product that was originally called DFHSM and later renamed DFSMShsm when it was integrated with DFSMS.

While many people equate HSM with tiered storage, it is very different. In the case of HSM, a dataset can be moved to another set of storage devices based on frequency of access, or based on policy. Instead of calling these tiers, HSM identifies them as “Migration Levels.” Migration Level 0 (ML0) is the level for the active dataset. When the dataset becomes inactive it can be compressed and moved to Migration Level 1 (ML1), and after a specified period of activity it can be moved to Migration Level 2, which usually is tape. At some point, it can also be scheduled for deletion, including all its backup copies.

This all sounds very similar to tiering except for the fact that when the dataset needs to be accessed after it has been migrated to ML1 or ML2, it must be migrated back to ML0. With tiering, a volume can be accessed directly from any tier that it happens to be residing on at the time. Since most customers also compress the data when they migrate it, HSM must read the data from ML1, uncompress it, and then write it to ML0 before it can be accessed. Not only does this require some mainframe processor cycles, but it also requires additional capacity on the “from” and “to” Migration Levels.  Another major difference is that HSM is done by the mainframe software DFSMShsm, and not in the storage control unit where most tiering is done. While automate tiering is used to actively move data up and down tiers of storage based on usage, HSM is used more like an archive.

HSM compression was recommended in the early days when moving to ML1 since this was the only way to reduce the cost of storage when there was only one type of storage for mainframes. Mainframe storage was more expensive than open systems storage since it required a global cache architecture, so the use of processor cycles to compress and uncompress data, even when it was only a 2:1 compression factor, was cost effective. There is now a greater variety of mainframe disks at varying capacities and performance, but most customers still use compression when migrating a volume to ML 1.

Since Hitachi Data Systems’ storage virtualization can support FICON for mainframes, it can provide tiering for different types of storage including SSD, SAS and low cost SATA storage whether it is internal to Hitachi VSP or on lower cost external open systems frames. With storage virtualization for mainframes we can move a volume to a tier of storage and access it directly from that tier. This is the only storage virtualization solution that can deliver this since all other virtualization approaches are done with appliances that do not support mainframe channel ports.

While there are many other reasons for using DFSMShsm such as backup management and retention policies, Hitachi storage virtualization can provide automated tiering to further reduce costs for active data.