Storage edge or fabric centre?
Where should you virtualise storage?
By Chris Mellor | Published: 10:55, 04 January 2005
Hitachi Data Systems' Tagmastore Universal Storage Platform - USP - does storage virtualisation in the disk array storage controller area. IBM's SAN Volume Controller - SVC - does it in the storage fabric via a specific box or appliance. HDS and iBM have their own opinions about each approach.
For example, HDS says its approach is better on the grounds of mainframe support, long-distance replication and simplification.
It points out that IBM's SVC does not support mainframe storage. An HDS spokesperson says, "The SVC only virtualises storage for open systems platforms. Hitachi Data Systems’ Universal Storage Platform can virtualise external storage devices including SATA storage and present it to a mainframe sever as well as open systems platforms."
HDS promotes the concept of one virtual storage pool for all SAN accessing servers.
IBM's chief virtualisation architect, Steve Legg, says that IBM's decision to exclude mainframe servers was deliberate and that mainframe stirage systems are more advanced and mature than open server's storage systems; "IBM's SVC does not support mainframe storage that is accessed via CKD. This was a deliberate choice to target the benefits of virtualisation in the open systems area where the problems associated with storage capacity growth were having the most impact. In the mainframe environment, the mature storage management tools that are in use have already driven utilisation and manageability up to levels that are very much higher than in the open systems platforms."
Another factor affecting this is that open systems' SAN storage is beginning to use Serial ATA storage. The situation is different with mainframes, according to Legg; "There is little demand so far to deploy low cost S-ATA storage in high-end mainframe environments. IBM will continue to monitor this area as it matures."
HDS claims that it's replication is synchronous across WAN distances whereas IBM's is not. The spokesperson explains; "The SVC only appears to support synchronous Peer-to-Peer Remote Copy. Hitachi handles the virtualisation inside the USP using TrueCopy Asynchronous and Hitachi’s Universal Replicator to replicate both internal disk and virtualised external disk storage without the need for any additional appliances."
Steve Legg says that IBM customers can indeed enjoy synchronous replication over long distances: "SVC currently offers metro mirror replication which indeed is synchronous so is best deployed over distances of less than 100km. For longer distances SVC is qualified with third party async replication technology."
Thirdly HDS says that its approach is simpler; you need fewer boxes. The spokesperson offers this view: "The SVC being a SAN based appliance/solution introduces additional complexity into the management of the SAN (the FC zoning is absolutely critical). With the virtualisation being handled inside the USP using its scalable connectivity capability, it is possible to avoid this complexity by building external storage configurations which are only attached to the USP and not potentially accessible to other directly via the SAN servers."
This claim is countered by Steve Legg, who suggests that basing a judgenent of simplicity on pure box-counting is, perhaps, simplistic. You need to take a bigger picture into account:
"Arguably SVC reduces, not increases complexity by homogenising storage that is atached to the SAN and by offering LU management at the SVC layer. In this sense the HDS USP does a similar thing, though it happens to have packaged the virtualisation piece (similar to IBM's first generation SVC offering in 2003) together with a RAID controller."
"IBM has chosen to keep these two elements separate it its portfolio to maximise flexibility and to obviate the need to deploy IBM RAID storage in wholly non-IBM SANs. SVC technology is as applicable in non-IBM SAN environments as it is in mixed or all-IBM SANs."
"Using USP as a pseudo-switch by attaching application servers directly seems a retrograde step in terms of SAN deployment since it mixes the switch management (zoning, etc.) function with the LU management."