ORIGINALLY POSTED 8th November 2008

10,944 views on developerworks

Is it me? I was wondering, but I was glad to see ‘the bod’ agreed with me.

SAN Virtualization, now I’m sure Cisco would claim the term, VSAN’s, logical abstractions etc etc. Storage Virtualization, thats what I do for a living, thats what our customers know they are buying when they implement an SVC system, thats what the INDUSTRY thinks of SVC, USP, Invista (if its still around), DataCore, StoreAge, YY (if they make a re-appearance – maybe its the new Invista?)… or is it me?

I commented on Hu’s post earlier this week [loaded question] and I appreciate that he’s actually posted my comment, although he tried to suggest that I re-read his post and implied something about SVC not actually virtualizing existing storage… huh?

So Martin ‘the bod’ stepped in, and correct him, and what Martin said is correct. Without such an ability, how would we take an existing infrastructure and virtualize it… How do we do it…. With any system that changes the physical WWNN/WWPN that is presenting a LUN, you have to take an initial hit. But once you’ve done that, and are now virtualized, you’d better be darn sure you don’t ever have to take that hit again…

Well, here’s a step by step for SVC (and pretty close to what needs to happen with USP) (for Hu’s benefit) :

1. Queisce application.
2. At storage controller device, un-map the LUN from the host system that was using it.
3. Re-zone the fabric, so the storage controller now only sees SVC, and the host system only sees SVC.
4. At the storage controller, re-map the LUN so it is presented to SVC.
5. At SVC create an “image mode virtual disk” – this is a special virtual disk mode that exists to allow you to provide a 1-2-1 LBA mapping between the controller LUN (mdisk) and the host LUN (vdisk)
6. At SVC map the virtual disk to the host.
7. Re-scan disks, Re-start the application

Now, please show me here how this is ANY different to what you need to do when you do the same process using a USP. Hu is holding this as the difference between what he calls SAN and Storage Virtualization.

Hu says you cannot do this with SVC. He is wrong. From then on his latest post is, well, worthless. Almost every single thing he says about SVC is untrue, factually incorrect or just plain wrong. This is important. This isn’t just vendor or product bashing, this is incorrect supposidly technical content. Maybe he has been provided this incorrect information, and I’ll happily adjust this post if he corrects his mistakes. Everything he says about a Storage Virtualization solution, (USP), can be done with SVC. I’m not bashing his products at all, I’ve often said that the SVC and USP approaches can reap the same benefits, they are just done in a different way.

Lets go through this point for point, Hu’s comments in green, my reply in purple.

While I certainly agree that storage virtualization can increase utilization of storage, it is important to differentiate storage virtualization from SAN virtualization, where the SAN is virtualized to look like storage. With SAN-based virtualization, you may not see a significant increase in utilization and you may see an increase in operational expenditures.

We (SVC) are not virtualizing the SAN. We are virtualizing the storage. With SVC we frequently have customers telling us they have increased from maybe 30% utilization, up to over 75% utilization. So this paragraph is incorrect.

---

Hitachi does storage virtualization, since we can take existing LUNs from different storage devices and service them as though they are Hitachi LUNs.

Yup, I agree, and thats what SVC does too – only replace Hitachi, with SVC

---

With storage virtualization, which is done in the Hitachi Universal Storage Platform (USP) controller, Hitachi provides non disruptive data mobility, the ability to copy, move, migrate, and replicate volumes or LUNs, to optimize the placement of data and increase the utilization of existing storage space.

Yup, I agree, and again replace USP and Hitachi, with SVC and IBM and there is no difference.

---

This movement is done within the control unit between internal and external storage as well as between externally attached storage. There is no dependence on the SAN or host servers to move data.

The SVC data movement is done between one controller and another, so he does have one point here, yes we use the SAN to do I/O operations (?!) – we DO NOT use the host. – with SVC we are only limited by the IOPs of the external controller – NOT an IOPs limit on ports into our control system.

---

With storage virtualization, Hitachi can enhance the storage that it virtualizes with the performance and functionality of our USP without additional complexity. With SAN virtualization you add complexity to the SAN and limit the capabilities of the storage that sits behind the SAN.

I’d disagree here. Any virtualization generally simplifies things, but the abstraction it introduces can make things ‘different’ from before (think VMware etc). With SVC, you map all your hosts to the virtualizer, you map all your storage to the virtualizer, you provision from one place. SVC after all has more performance than USP-V (as benchmarked independently) and the functionality of both products is similar.

---

SAN-based Virtualization approaches like IBM SVC and EMC Invista can not virtualize existing storage LUNs—you must remap (added by BW: here Hu states in his comments to the previous post that to re-map is to change the LBA mapping of the LUN into something specific to SVC) the LUNs so that the LUNs are defined in the SAN. This is why I call this SAN virtualization and not storage virtualization.

As explained above, THIS IS FACTUALLY INCORRECT and MISLEADING. We can do this just as USP can. If this is his basis for calling them different things, then I rest my case. You have to perform the exact same steps I listed above to enable the virtualization of existing storage with USP.

---

With SAN virtualization, you have very limited data mobility. In order to move or copy data you must read it from one virtualized disk into the SVC or Invista and then write it out to another virtual disk. After the write you need to check the status to see that the write completed successfully. The application needs to be stopped during this movement to ensure integrity or a log is maintained to capture changes during the “move”.

Now this is the paragraph I object to most – WITH SVC WE HAVE ONE OF THE MOST COMPREHENSIVE ONLINE DATA MIGRATION SOLUTIONS AVAILABLE TODAY. I do hope Hu retracts this as he needs to get his facts correct before making such a wild and utterly un-true set of statements. Let me clarify, the virtual disk does not change at all. The host and application are un-aware of any change to the disk, so no application stop is needed, behind the virtual disk we migrate physical data extents, we don’t use a log, nor do we need to stop applications (he’s speculating here without knowledge of how we do this). This maybe complex to code, but its been shipping for over 5 years now and we have many many customers using these functions every day, during the day, during business hours without issue.

I have posted a summary of this on Hu’s blog, and if he corrects his post to reflect reality, truth, and fact (not fiction or speculation) then I will happily remove – or at least amend this post if he corrects..