by Hu Yoshida on Nov 5, 2008
Welcome to Tony Asaro who has just joined the HDS blogging community with his blog, Tony Asaro’s Blog Bytes. Tony is a storage expert and well-known blogger who has blogged for Computerworld, Searchstorage, virtualiron, and his very popular Stor Wars when he was an analyst with the Enterprise Strategy Group.
Tony’s recent blog on storage and the economy makes an excellent good point about the need to implement storage virtualization to increase storage utilization, especially in these economic times where it is critical to reduce capital spend and improve operational expenditures.
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.
Hitachi does storage virtualization, since we can take existing LUNs from different storage devices and service them as though they are Hitachi LUNs. 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. 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.
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.
SAN-based Virtualization approaches like IBM SVC and EMC Invista can not virtualize existing storage LUNs—you must remap the LUNs so that the LUNs are defined in the SAN. This is why I call this SAN virtualization and not storage virtualization.
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”. All this processing is being done by the same engines that are supporting the primary application. It is difficult and impactful to move or copy data with SAN-based storage virtualization.
Choose the right virtualization for storage if you want to reduce capital costs and operational expense.
Comments (3 )
Hu, I do hope you post this, as you need to correct your statements. They are factually incorrect, and misleading.
Everything you say “is Storage Virtualization in USP” can be done with SVC, and more.
“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”.”
ABSOLUTELY NOT TRUE.
Lets look at the use cases :
1. Initial “import” of an existing LUN. It is true that on day one, you need to temporarily halt an application, re-map the LUN from host to SVC, then create an “image mode virtual disk” that instantly makes the LUN accessible to the host as it was before. This does not require you to move data before its available, this is a 1-2-1 mapping of what was the old LUN to what is the virtual LUN – no copying, no migrating, its just there. With a script this could mean less than 5 seconds of application halt time, while the un-map, re-map, re-zone is done.
The same is true for USP – you have a LUN today on disk box X, now you are presenting it via USP, so that means you need to remap your host to view the USP exported LUN.
2. Migration of data from once controller to another once you have done 1. above. There is NO NEED TO STOP APPLICATIONS, as you suggest. Here the LUN is now virtual, and so the actual physical location is not known to the host, you simply move the data. I’m sure the same is true for USP.
3. Upgrading of the Virtualizer device itself. With SVC you can remove and replace each node in turn without any disruption and end up with a completely new model of device.
With USP you need to map the old USP to the new USP as a virtualised controller, then you need to re-map the LUNs to now been seen by the new USP… so surely here this is worse.
Anyway, with all that said, does that not completely destroy your argument about any differences, other than your lack of upgrade capability.
I suggest you read some of my early posts on my blog where I compared and contrasted the 3 approaches to storage virtualization which resulted in SVC and USP approaches being almost identical from a “feature function possibility” perspective. This may also give you the needed technical background on what SVC can and cannot do, how it does it and help you to provide more factually correct posts in the future.
As I said on your previous post, please don’t try and re-define existing terms.
Storage Virtualization, is SVC, Invista, USP, DataCore, StorageAge etc
SAN Virtualization is Cisco VSANs…
[...] Recently there has been quite a bit of back and forth between Barry Whyte and myself. In an effort to clear up any misconceptions and more clearly state our differing positions, I’ve outlined a few points that should help our understanding. As a recap, storage virtualization with the USP V can virtualize storage for direct attached servers and mainframes, as well as SAN attached servers. Based on Barry’s comments, there is no difference than what IBM does with a SAN Volume Controller. I believe there is a big difference between the USP V and the SVC and other virtualization examples that he cites since they can only provide virtualization for SAN attached storage and servers. Barry was good enough to give me some use cases in a comment to my last post. This helps to clarify our differences. Here are my comments on Barry’s use cases: [...]
Hello Barry, I appreciate your feed back as well as others. Please see my next post for a response