ORIGINALLY POSTED 5th February 2008

10,102 views on developerworks

One of my regular blog stops is over at Techworld where Chris Mellor discusses all things storage. I spotted an interesting post from Chris today comparing SVC to USP and coming up with the conclusion that the two are almost the same in what they can achieve, what they do and at a 40,000ft view, how they do it.

I came to a similar conclusion last year in my multi-part-work discussing Storage Virtualization (as we know it today).

I’d agree that the differences between what an appliance and what a virtualizing controller can do – when it comes to features – are pretty much the same. Assuming the controller can virtualize external storage (as is the case with USP) then you can apply the feature set across all your storage – unless of course you limit what people can do, due to either testing limitations or fundamental limits on the system – again as is the case with USP. One of the many benefits of virtualizing is the ability to extract old hardware while maintaining server access – again here USP has missed a trick – just how do you upgrade the USP to a USP-V… However these are all implementation details and not generic flaws of a virtualizing controller methodology.

However, where I do seriously disagree is with the ‘on-switch’ virtualization – as implemented by Invista. Here the very limited processing power, problems with global namespaces – fast meta-data updates across many blades – scale out issue across many blades – and so on do seriously limit the functions that can be performed on single instance blades. Hence why EMC need a separate Kashya blade to do replication, and why their Flash-copy is really just a simple split-mirror implementation.

For this reason, if Chris had left it at just a comparison between SVC and USP, I’d probably totally agree with him. Neither of these models technically limit the functionality and general ‘comoditization’ of the underlying storage devices. Thats one of the things we set out to do with SVC. Why have 10 controllers that all implement the same sort of copy services, advanced function, with 10 GUI interfaces and all subtly different. Turn them off, don’t license them all, just use a single implementation – as in SVC or USP and then license what you need on the storage you want.

Chris ends by saying :

Unlike real estate the three most important things for a virtualising SAN storage product are not location, location and location. Let’s forget about SAN location and concentrate on three far more important things: functionality, performance and price.

So if we exclude Invista or other switch based solutions I’d agree. In the open side of the world, SVC pretty much matches USP for functionality – or will do later this year when Thin Provisioning is available. Performance – since we both submit results to the Storage Performance Council (SPC) – not everyones favourite, but none the less, SVC can squeeze that bit more – but again both systems are as capable… However note that USP was with internal storage only – as I understand it there are quite hefty IOPs limits on the ports attaching downstream controllers – I’d love to see the comparative external attached storage benchmark. As for price, well SVC has a major edge on that one!

For those that missed my part work you can read via the following links :

• Part 1 : The Approach War
• Part 2 : Copy Services
• Part 3 : Performance
• Part 4 : Interoperability
• Part 5 : Upgrades