IBM has announced the sixth version of SAN Volume Controller (SVC), a product that continues to outsell any other virtualization technology on the market, despite some architectural restrictions.
However, some users have pointed out that the design of SVC actually limits its provisioning capabilities, and they are looking elsewhere. Digging into the details, SAN Volume Controller is a collection of up to eight clustered servers or nodes. These eight nodes are managed as a set, and present a single point of control to the administrator for configuration and service activity.
For I/O purposes, the SVC nodes within the cluster are grouped into pairs, called I/O groups, with a single pair being responsible for serving I/O on a given virtualized disk or vDisk. Each node of an SVC cluster may only be in one I/O group and by design each I/O group only has two nodes. This means that I/O groups within an SVC cluster do not share access to virtual volumes. In other words, each I/O group controls, or is limited to, a particular set of assigned virtualized disks.
Randy Kerns, partner and senior analyst at the Evaluator Group, said that SVC is deliberately designed this way for isolation purposes. "It's easier to do a consolidation of a particular storage environment by isolating the storage, usually for a particular application, to a node pair that gives you not only access isolation but the controls for management of those specific resources."
Kerns added that there is still some key functionality lacking in SVC. At different points in time he said there will be more I/O going through one node pair than the other three, for example. "It would be nice to be able to move the volumes around and keep all nodes equally busy, but this is tricky to do."
One user testing the software felt that SVC's design hampered the product's scalability. For privacy reasons, he requested anonymity. "IBM recommended only placing two high performance arrays behind an SVC I/O Group ... We have five as well as two mid-tier arrays we wish to put behind an SVC cluster," he said. "In this case we would still have 'islands' of storage."
A spokesman for SVC said that any of the SVC nodes within a cluster can have access to all of the storage arrays in the backend pool. "You can allocate all two petabytes of backend storage to a single I/O group if you wish," said Roger Wofford, SVC marketing manager at IBM. He added that there are over 800 customers using SAN Volume Controller and some of the large installations are managing greater than 130 TB.
Kurt Anderson, vice president of IT at wholesale food distributor J&B Group in Minnesota, is also an SVC user. He explained that if IBM had designed SVC to support sharing across I/O groups, it would have had to design a more complicated distributed caching algorithm to handle the variety of situations that could result when multiple (or more than two nodes) share access to any one disk. "The simpler design was ultimately the more reliable," he said. And not only that, it was readily available. IBM has used this design in its server clustering software for years.
William Hurley, senior analyst with Enterprise Strategy Group, said SVC has performed well in benchmark tests but could always be improved. "Is it perfect? That's why you continue to upgrade," he said.
Version 2.1 of SVC introduces a new pricing model for the software. It used to be sold in tiers of capacity, and once users reached a certain capacity they had to jump to the next tier for a lot more money. Under the new pricing scheme, SVC will be sold on a per terabyte basis, providing a more granular approach. Entry-level pricing now starts at $47,000, down from $60,000 previously and is generally around $7,000 per terabyte.
IBM has also added support for more operating systems in Version 2.1, including Novell Netware, Sun Solaris, HP UX, Linux on IBM pSeries servers and AIX on pSeries blades. On the storage side, SVC now supports Sun 9910 and 9980 arrays as well as the majority of Hewlett-Packard Co., Hitachi Data Systems Inc. and EMC arrays.