Last week I was reading one of Steve Chambers posts about his first quarter at VCE when I was struck by the similarities of IBM XIV and the VCE Vblock…..
Let me quote a few lines from Steve’s blog and compare them to IBM XIV.
“Before VCE came along with their Vblock product, it was really hard, slow and expensive to deploy converged infrastructure.
Why is it different at VCE?
Sit down with me and we can create a bill of materials from your requirements in less than 15 minutes. If you press the Buy Now button then thirty days later it will be shipped to your datacenter loading bay on one or more pallets……
Then a VCE guy turns up in a taxi and in one day will have the whole thing running for you. The day after that you can do your testing and launch your services and start making money. Time to value and time to cash after making these kind of investments is what keeps the senior managers awake at night.”
Comparing IBM XIV to the above statement is as simple as substituting a few words in the text above. Seriously. Replace the following words –
VCE –> IBM
Vblock –> XIV
Converged Infrastructure –> Storage
Stay with me on this….
Steve goes on to say –
“What would the business prefer? To be earning revenue from your new infrastructure in sixty days, or be still sitting in a room looking at a whiteboard and still doing the low level design and still working out which product firmware is compatible? Been there, done that, now it’s up there with ITIL for me. It is of value only to the professional services teams that charge customers for it. It’s boring. It’s dead, dead, dead.”
You could say the same about XIV.
I for one used to love designing storage arrays. In fact in some respects I still do. RAID Groups, RAID configurations, drive geometries and rotational velocities, port groupings, number of ports per CPU, cache partitions, cache write-through vs write-back, cache slot sizes, backend loop isolation, short stroking, concat or striped LUNs, is the LDEV from the inner or outer tracks of a disk…. whiteboarding… Mmmm donuts!!!
If I’m honest, as a contractor, my higher rates were often on the more complicated configurations. Complicated storage configurations made me a lot of money.
But to use Steve’s words, are these days dead dead dead?
XIV and Vblock – Making the Case
Last time I checked, Vblock comes in certain pre-defined configurations. Think of them as small medium and large (I’m somewhat oversimplifying but the principle remains) and there is precious little you can flex within the Vblock. Same goes for XIV, it effectively comes in a small choice of pre-canned configurations, small medium and large.
With such limited configuration options, be it Vblock or XIV, there are pro’s and cons.
Simplicity. And simplicity is king these days. With any given XIV, it is relatively easy to know what it can and cannot do. Capacity is probably the simplest. XIV grows to a certain size and that’s it. Need more capacity? Buy another one.
Similar story for IOPs and MB/sec. XIV will do so many and no more. Need more? Buy another one. Simple, reliable, predictable.
No hours of whiteboarding, or days of PS consultancy to decide between RAID This or RAID That. No guessing the mix of SATA, SAS and SSD, how much cache to buy, how many front end ports, which licenses, matching business hours with data movement windows, aggresiveness of data movements.
Life is terribly simple –
- Choose which one you want, small medium or large.
- Make the order.
- Several days later it arrives shrink wrapped
- Take a stanley knife to it, plug it in to the power and your SAN and an hour or so later you are provisioning from it.
As with Vblock, XIV and the cookie cutter approach has its drawbacks too.
You can easily end up with stranded capacity or IOPs if your workload doesn’t fit nicely within what an XIV can do (all equally sized SATA drives with a common protection level). While this is true, this is also true of the vast majority of storage I’ve ever seen. As storage arrays grow, despite of the efforts of highly skilled storage admins and architects, the arrays tend to become unbalanced, both on the backend and on the front end. So this is arguable as a drawback in many cases.
Thin Provisioning, or more correctly overprovisioning, on the other hand is definitely a strange one with XIV, and one you must be careful with. If you buy the biggest model, overprovision it and then have a subsequent bank-run on your storage you can be in a world of hurt. This is because you cannot simply add more shelves to it, there is no easy central bank ready to print you more storage and bail you out. So be careful.
If you have a huge environment, then you could easily end up with XIV-sprawl – lots of islands of XIV storage each requiring you to log on locally and manage it. Again though, while this is clearly a drawback in many scenarios, many people are cautious about how big they want their storage arrays to grow. The more capacity and IOPs you array has, the more of each you will use. This naturally leads to having more and more customers and business units relying on it. Which in turn makes scheduling firmware upgrades and hardware upgrade more challenging, not to mention the impact should the service ever go down :-S
Oh and if you like deep diving, whiteboarding and having lots of buttons to press, then XIV is downright boring 😉
Just my thoughts. I can see the pros and cons of both approaches and Im not advocating either. I just thought the comparison of fundamental principles between Vblock and XIV was interesting.
Courteous comments welcome, and please disclose if you work for a vendor.
You can follow me on Twitter and talk to me about technology semi-realtime – @nigelpoulton
Oh and finally, let’s all be grown up about this. These are my personal opinions and observations, and not the opinions of any of my employers, past present or future. So please don’t get upset and spit your dummy out.