DB2 and Disk Storage Virtualization: Part 2
Why disk storage virtualization is so important
This article is continued from Part 1.
Solid-state drives break the IOPS density downward spiral
This quantum change is already here in the form of solid-state drives (SSDs). A 200 GB SSD can provide about 25 IOPS/GB—100 times the IOPS density of a 600 GB spinning drive.
While still expensive, SSDs are coming down in price thanks to competition among multiple vendors and the introduction of enterprise-ready MLC drives. With the IOPS density trend continuing downward, it is hard to see how any enterprise-class array can be deployed without some SSDs in the future. The only challenge then will be how to use them effectively.
It’s difficult to map volumes as seen by z/OS to their actual back-end storage array instantiation; that is, what appears to z/OS as two physically separate volumes may actually be rendered on the same physical disk. Any attempt to separate a table and its indexes for performance may unknowingly place them on the same disk, causing contention. There is no easy solution for this issue in today’s arrays.
Asymmetric layouts arise because we don’t live in a perfect world where the storage array would be completely filled with drives on day one. This is an extremely rare occurrence due to the associated CAPEX. For the most part, arrays ship with many open drive slots and even empty drive bays. Usually, companies plan to purchase and incrementally grow the storage controller as needed. But growing an array incrementally creates unavoidable asymmetry, preventing the array from performing at its peak.
Enterprise-class storage arrays work best when all the applications are balanced across all the resources of the array. While you can still prioritize your most important applications, optimal operation requires good balance.
Based on hundreds of performance analyses, it has been confirmed that most workloads are skewed. A typical workload distribution shows 20 percent of the DB2 volumes are doing 80 percent of the I/Os. The most disconcerting aspect of this ratio is that, from day to day, it’s not always the same volumes that are busy. Further, within a given DB2 volume, the 80/20 rule often applies: 80 percent of the workload to that volume is directed to 20 percent of the space on the volume. This type of workload skew cannot be managed easily by any of the tools available today—creating bottlenecks at the storage subsystem layer, and hindering the ability to use the system’s full capabilities.
Virtualized storage: The old way
You could argue that modern enterprise arrays already provide a minimal level of virtualization, and you would be right. Among some of the aspects that are virtualized to z/OS are the volume size, its formatting (3380, 3390), its RAID protection, and its emulation (CKD). This kind of virtualization follows a rigid structure and does not lend itself to any management flexibility. Consider the task of dissolving 3 MOD-3s to create a single MOD-9 and imagine how difficult that might be!
Thin provisioning: The new virtualization
A new virtualized storage paradigm—which uses a technology known as thin provisioning—solves many of the problems I just described. Thin provisioning has the advantage of using pools of storage to support storage-on-demand for DB2 subsystems. These pools provide storage to thin devices only when the storage is actually written. Otherwise, storage is not consumed from the pool, leaving it available for other applications. Applications that do not format their table spaces or datasets by writing copious amounts of non-data (metadata, low-values, and so on) can be considered “thin-friendly.”
DB2 for z/OS is a thin-friendly application. When DB2 V9 or V10 creates a table space, if the PRIQTY is greater than 16 cylinders, only 16 cylinders are actually written. This means that if you create a 3,000-cylinder table space, while the 3,000 cylinders appear to be consumed from a z/OS perspective, only 16 cylinders are allocated from the storage pool. If the table spaces are inadvertently oversized, the additional storage in the table space that is not yet written is available for use by other applications. This reduces the total cost of ownership of the configuration by optimizing the use of the storage capacity.
Another key benefit of thin provisioning is that the layer of abstraction allows the storage controller to decide where data is to be placed. This capability enables the data to be striped across the pool of devices that support the thin device; in turn, striping allows many more disks to service I/Os for a given DB2 volume, which also helps to remove bottlenecks in the storage layer. Wide striping helps to maximize disk utilization levels by eliminating I/O skewing. And since SSDs drive I/O to even higher levels, the combination of SSDs and wide striping creates the ultimate in DB2 storage layouts: balanced performance and balanced capacity.
Oversubscription of a thin storage pool occurs when more thin-device capacity is created than there is actual storage in the physical pool. This is a useful method to offset over-allocation of DB2 table spaces as described earlier. But it can also help prevent some of the pain of traditional storage provisioning.
Suppose you created 100 thin MOD27s (about 2,500 GB) but provided a storage pool of only 1,000 GB. You would be oversubscribed on the pool. This situation is fine until you try to consume more than 1,000 GB—at which point you get an I/O error. Careful monitoring is necessary to ensure that this does not occur.
When the pool storage used capacity approaches 1,000 GB, you can add more storage to the pool dynamically to avoid the out-of-space condition. Adding capacity to the pool in this way is analogous to traditional storage provisioning, except there is absolutely no host work required. No changes are needed to IODF, SMS, ACS, Copy Pools, or even remote array-based replication. This method considerably reduces the change-control work that is necessary and shortens the time for the storage provisioning.
Disk storage virtualization using thin provisioning realizes the SMS promise of balanced performance management. It also delivers better capacity utilization due to oversubscription, and it eases the pain of storage provisioning. Consider using your vendor’s thin provisioning solution to save money, save time, and increase your DB2 performance.