United States
Site Map Contacts Hitachi Global Community
Hu's Blog - Data Storage and Virtualization Thought Leader Hitachi - Inspire the Next

Hu Yoshida's Blog - Vice President | Chief Technology Officer

Home > Corporate > HDS Blogs > HDS Bloggers > Hu's Blog
Products, Solutions and more

Hu's Blog

VSP Meets System Z – New Storage Features for a New Age

by Hu Yoshida on Sep 2, 2011

Mark Twain once wrote, “The reports of my death are greatly exaggerated.”

The same may be said for mainframes—or System Z, as it is known today.

Jean Bozman of IDC reports on a zSummit held by IBM for analysts back in March of this year, where the company disclosed its plans for growing the mainframe market—which has been the platform foundation for enterprise data centers for the last 40 years. It was obvious to IDC that IBM plans to continue investing to grow this market. This opens an opportunity for growth in mainframe storage.

When it comes to I/O performance, the mainframes can drown out open systems I/O if they happen to be sharing the same storage system. This is because the mainframes have separate processors, called channels, which can drive a much higher I/O workload than an open systems platform using the same processors for compute and I/O. Hitachi solves this problem of sharing by logical partitioning within the VSP/USP/USPV, which manages the amount of storage systems resources that can be shared between open systems and mainframe servers.

While the mainframe was far ahead of its time in many ways, it has some legacy issues that limit its ability to use modern intelligent storage technologies. Direct Access Storage Devices [DASD] were very expensive and small, with capacities measured in gigabytes compared to today’s multi-terabyte disks. Each disk required a Unit Control Block in the software, which is identified by four hex digits limiting the number of disks that can be attached to 64K. The volume size had to be limited to 65,520 cylinders, and the track size had to map to an IBM 3390 track format of 56,664 bytes.

IBM introduced Extended Address Volume to increase the number of cylinders to 262,668 and Parallel Access Volumes to address the problem of multiple concurrent I/O operations on very large volumes. However, the number of UCBs and the 3390 track format basically remains the same. IBM also added Dynamic Volume Expansion to enable capacity increases to existing volumes to meet application demands without requiring additional UCBs.

In order to support these capabilities, HDS has made Hitachi Dynamic Provisioning available for mainframe storage. Because of the 3390 formatting differences of the mainframe, the page size for a mainframe HDP pool is 38 MB for optimum performance. Therefore, separate HDP pools will be required for mainframes and open systems which use a 42 MB page size.

While IBM supports EAV and DVE on their storage systems, the advantages of using HDP with EAV and DVE are:

1. Simplified volume design and operation. A virtual volume can be expanded without stopping the host.

2. Optimized costs for storage implementation with virtual capacity volumes.

3. Automated wide stripe performance with rebalancing when the pool size is expanded.

In addition to HDP, VSP can also use lower cost external storage for creation of the mainframe HDP pools. The IBM SVC does not support storage virtualization for mainframe storage.

So, while EAV and DVE are great new features from IBM for increasing the scalability of mainframe storage, VSP can additionally enhance mainframe performance, cost and usability with the addition of HDP and storage virtualization.


Related Posts Plugin for WordPress, Blogger...

Comments (7 )

Josh Krischer on 08 Sep 2011 at 3:15 am

Hu some additions:
2Q11 Revenues from System z mainframe server products increased 61 percent compared with the year-ago period. Total delivery of System z computing power, as measured in MIPS (millions of instructions per second), increased 86 percent.
The Dynamic Channel Subsystems (DCS) is one of the biggest differences between the IBM mainframe and other platforms. The instruction processors issuing Start SubChannel Instruction, setting the parameters and disconnecting from the I/O activity which is performed by the DCS. It will select the path (up to 8 available), execute the I/O and notify the IP by I/O interrupt upon completion of the I/O. If the IP is not ready to accept the I/O interrupt, the DCS will queue it and after some time retry. The IP overhead in I/O operation is negligible.

Hu Yoshida on 08 Sep 2011 at 8:46 am

Hello Josh, thanks for the update. This week I have been in Thailand and Philippines, and am finding a lot of mainframe users. Looks like the mainframes are resurgent.

Josh Krischer on 08 Sep 2011 at 9:44 am

You welcome, Hu. The biggest growth is in the BRIC countries and in particular in the finance sector.There is also a growth in the “old world”. I wanted to paste a PowerPoint graph to this comment but could not.

Sergey Pospelov on 13 Sep 2011 at 6:36 am

Why would we need HDP on mainframe when we already have SMS? Datasets represent actual data and storage groups represent pool of volumes. Sysprog can add volumes at any time. In advantage we are not limited by one volume. We can store datasets in size as 2-10 EAV. HDP is limited by size of one volume from user perspective.

Hu Yoshida on 13 Sep 2011 at 12:55 pm

While an HDP volumes looks like a normal 3390-A, the data allocated to this logical volume is distributed in pages of 38MB size across what we call an HDP-Pool. And an HDP-Pool can span dozens of array groups or hundreds of physical disk drives. This results in a performance benefit which we call wide striping. DFSMS pools are great for driving high capacity utilization and can very neatly and transparently be combined with HDP-Pools (up to 128 are currently supported).

Sergey Pospelov on 14 Sep 2011 at 9:35 am

Thank you, Mr Yoshida-san. Performance is a good point. From MVS I can still allocate extended striped datasets and will achieve like the same. One dataset will be served by several volumes, cpu, channels. Another thing worrying me, using HDP we should probably spend more time for writing, as we need to find/allocate next free block in HDP pool. Definitely good for reading, not sure about writing. Any comments?

In general I see more benefits for open systems than for a mainframe. Or could be for new mainframe users that don’t think what and how they allocate.

Hu Yoshida on 18 Sep 2011 at 9:28 am

Hello Sergey, yes you can do striping manually, but HDP does it automatically. Striping for extended format datasets only occurs at initial allocation time. HDP wide striping however is always active and works for any type of datasets. When an HDP-Pool is expanded (or even reduced) automatic restriping occurs which ensures that all pages belonging to a single dataset are distributed across the entire pool. HDP does this automatically in the background. Striping is good for random reading as well as writing. I do agree that open systems users will appreciate this more than mainframe users since they have not had the benefit of DFSMS.

Hu Yoshida - Storage Virtualization Thought LeaderMust-read IT Blog

Hu Yoshida
Vice President and Chief Technology Officer

Connect with Us


Recent Videos

Switch to our mobile site