AIX > Storage > Disk

Pack Efficiently With SVC 4.3

Version 4.3 of the IBM System Storage SAN Volume Controller emphasizes space efficiency through three areas of innovation: space-efficient virtual disks, space-efficient FlashCopy and virtual disk mirroring.


Illustration by Alison Seiffer

In December 2007, IBM Systems Magazine, Open Systems edition explored Version 4.2.1 of the IBM* System Storage* SAN Volume Controller (SVC), a release that brought considerably more FlashCopy* capabilities than were previously available, further bringing the FlashCopy technology—once almost the sole domain of large enterprises—to the small- and mid-sized business (SMB) space.

Wasting little time, IBM announced in May SVC Version 4.3, which emphasizes space efficiency through three primary new areas of innovation, including space-efficient virtual (SEV) disks, space-efficient FlashCopy (SEFC) and virtual disk mirroring. These new SVC capabilities are designed to further SVC’s role in providing flexible virtual data-storage infrastructures free of many of the constraints imposed by physical data-storage devices.

Much like companies that use virtualization technology to partition servers to create virtual server infrastructures, SVC continues to innovate and expand virtualization into the data-storage space, essentially allowing organizations to virtualize more of their overall IT infrastructures.

“SVC really complements the server-virtualization capabilities many companies are deploying today—where they’re using tools like IBM logical partitions and VMware*—to take their physical servers and split them up into virtual servers,” says Chris Saul, IBM SVC marketing manager. “Companies build a virtual server infrastructure that better meets their business requirements that’s less limited by the physical characteristics of the servers they actually have installed. SVC does much the same thing for data-storage networks and now, with Version 4.3, we’re focusing on improved storage space efficiency, better application availability and improved performance.”

The Value of SVC

Customers familiar with SVC know it as a storage-virtualization system designed to remove some of the limitations of physical storage by providing a layer of separation that changes the way servers see storage devices. In particular, SVC hides differences in management and functional capabilities among different types of storage so that all storage can be managed more easily and used in the same manner.

SVC obscures the physical characteristics of storage devices and brings all available storage resources across all devices in a company and treats them as a single pool of storage. This can help drastically reduce complexity, improve utilization and considerably ease overall storage management and allocation.

“With SVC, you’re building a virtual-storage infrastructure to meet a company’s requirements, and that virtual-storage infrastructure should be fundamentally different from the physical-storage infrastructure, because SVC isn’t limited by the characteristics of the physical infrastructure,” says Saul. “In particular, it’s not limited by the facts that the physical-storage infrastructure happens to come in different disk boxes from different vendors. So the whole thrust of SVC is to provide customers with a lot more flexibility in the way they use their storage.”

Between a Rock and a Hard Place

In past releases, when defining virtual disks to meet given requirements, SVC required there to be physical disk capacity corresponding with the newly defined virtual capacity. If, for example, customers decided on 500 GB of virtual disk, they needed to have 500 GB of physical storage capacity as well. Because of this dual virtual disk/physical disk necessity, customers have had only a couple of options when looking ahead and planning to accommodate future database growth.

For example, a company with a fairly small database might plan to have that same database grow to 2 TB in a few years. As one option, they could acquire and allocate 2 TB of storage for that database today. The drawback with that solution is that the company doesn’t need that much capacity now, so it would be wasting space and buying storage before it was needed. With the price of storage continually falling, this wouldn’t be cost efficient.

An alternative approach—one taken by most customers—is to allocate much less storage to the database. For example, customers with an existing database that’s only a couple hundred gigabytes allocate 300 or 400 GB to it. Then, as that database fills up, they come back and reallocate a little more storage space to accommodate more incremental growth. A drawback to this approach is customers often have to reorganize the database so it can occupy the space that’s just been allocated. This can impact application performance and availability.

Similar concerns arise with file systems where a customer might allocate 500 GB to a file system that contains only 100 GB of data. The remaining 400 GB would be wasted, waiting for more files to be written.

“With a traditional way of managing storage, you’re just sort of stuck between two not-very-good positions,” says Saul. “Either you buy storage ahead of time, which is undesirable, or you keep expanding the storage, which requires manual intervention and possible reorganization of the database. That’s why we’ve come up with space-efficient virtual disks.”

SEVs

Using the SEV function, customers can define the capacity they think their database or file system will need in the future, depending on their long-term plans and aspirations. To take the example used previously, if customers believe their database will grow to 2 TB, they can allocate 2 TB of virtual capacity to that database today. When the database or the servers look at SVC, it appears as if they actually have 2 TB of physical capacity available, even though that’s not physically the case.

This is possible because the SEV function is designed to utilize physical storage only when data is actually written to virtual disks, rather than under the traditional method of dedicating physical capacity to the entire defined virtual capacity. In other words, while the database or servers are “seeing” 2 TB of virtual storage capacity, the actual physical capacity can be considerably less than that. This SEV capability allows customers to allocate virtual capacity in anticipation of future growth without requiring actual physical storage until it’s genuinely needed.

“SEV resolves the previous problem of having to reorganize a database after each incremental storage addition. You won’t need to reorganize the database because, as far as the database is concerned, it has all of the full virtual capacity it can occupy,” says Saul. “For customers who want more control, SEV also provides options to manage provisioning of additional capacity more closely.”

"SVC really complements the server-virtualization capabilities many companies are deploying today." -Chris Saul, IBM SVC marketing manager

Ryan Rhodes is a freelance writer for IBM Systems Magazine.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

AIX Makes Using RAM Easy

Using the mkramdisk command can create high-speed I/O

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters