SVC and XIV
orbist 060000HPM5 Comments (17) Visits (16536)
The interop just keeps growing. As you would expect you can today attach the new IBM Storage products behind SVC, running the latest 4.3.0 software.
SVC has actually supported XIV since August, we completed the controller qualification during our last SVT cycle, and the IBM Storage teams in the US completed the qualification of the DS5000 on our behalf.
Why would you want to put XIV behind SVC? Well the same reasons you would put any storage devices behind SVC. You gain all the advanced functions that SVC can provide on the backend storage. The ability to migrate data into XIV in a non-disruptive way as usual, the ability to backup, archive, migrate, replicate data from the XIV to other controllers. The performance enhancements over normal SATA based controllers allows for a much larger capacity pool to be attached to SVC while maintaining the performance of enterprise disks. The simplicity and ease of use of the interface means you can get this storage up and running behind SVC in next to no time.
The has been a lot of FUD over the last few weeks - coming from those that feel they need to spread such tales.
On the other hand there are positive articles, I think Steve Duplessie's article is a great read.
Here are a couple of the more important un-truths/comments that have been spread
I'm sure I've missed a few more, I need to read back through various posts as I'm sure I've seen a few 'artistic license' comments out there :)
The interop support details for SVC and XIV are available on our SVC support pages : http
It's worth noting that when running XIV behind SVC, we don't support the thin provisioning or copy services functions down at the XIV level - this is for the same reason we don't in general support these functions on other controllers.
Copy services are simple to explain, as only SVC knows the allocation of a vdisk to physical storage, so copy services need to be above the storage pooling laye. Similarily it would require a flush of the SVC cache in conjunction with the controller cache to ensure the data on disk was a consistent image. The alternative is to go for something like Invista's approach and provide volume level virtualization with no cache. This doesn't get the best out of virtualization however, as you can't stripe for performance, you are limited to the performance of the single volume. Nor can you perform sub-volume level migrations, hot-spot management, enhance performance with caching etc.
Thin provisioning behind SVC is an interesting one. Because we split the capacity into extents, and we stripe over these extents across multiple volumes, we expect there to be capacity. If you happen to run out of space on the thin provisioned disks (missing the alerts etc) then you risk taking a lot of vdisks offline. Since SVC provides Space-efficient Vdisks anyway, its not an issue.
Anyway, I know we've had lots of interest from existing SVC customers regarding XIV support, and a number prospective SVC and XIV sales are in the pipeline.
I'll cover some more details of the DS5000 and its future-proofing interface technology, the jump in performance and the increased drive support over the next couple of days.