Information Technology News.

HDS integrates with VMware's vStorage API

February 8, 2011

Add to     Digg this story Digg this    Get a great Ubuntu Linux dedicated server for less than $3 a day!

Share on Twitter

Click here to order the best dedicated server and at a great price.

Earlier this morning, Hitachi Data Systems (HDS) said it is the first virtualised storage array vendor to fully integrate with VMware's new vStorage API (application programming interface) and relieve the hypervisor of storage maintenance work.

The VMware storage API is called VAAI (vStorage APIs for Array Integration) and the intent is that ESX can offload many storage-related operations to a storage array, freeing up server CPU cycles for application-related work instead, greatly contributing to an overall increase in computing and storage performance.

The microcode in HDS' VSP enterprise array now fully supports VAAI and its 3 primitives (basic operations) of full copy, block zeroing and scalable lock management.

The VSP can be told by vSphere to clone virtual machines (VMs) using the full copy primitive, write zeroes into empty blocks in virtual disk files with block zeroing, and to lock virtual machine files with a SCSI reservation lock instead of VMware having to lock such files itself.

File locking is necessary to prevent multiple, conflicting accesses to the same files which can often lead to file corruptions and similar unwanted events.

HDS says that block zeroing can speed up provisioning of new virtual machines by a factor of up to 85 percent, while full copy can accelerate virtual machine cloning by up to 18 percent. The VM locking is claimed to improve VM performance through the removal of SCSI reservation conflicts by up to 35 percent.

HDS's Roberto Basilio, storage platforms product management vice president says that updating array microcode was a serious affair. So far, he didn't know how much of a lead HDS had over other manufacturers-- it could be days, weeks or even months, but the fact is that he was upbeat about it.

Basilio added that some legacy file arrays could be incapable of having their storage controller code updated to support VAAI. If those arrays were virtualised behind a VSP controller then that managed their storage resources and presented them to server hosts as if they were native VSP storage arrays and therefore VAAI-capable as well.

If a customer wants to fully adopt VAAI across its storage estate but some arrays are not VAAI-capable, then add one VSP controller and bring these older arrays into the VAAI fold. HDS says that about one-hundred or more third-party arrays are supported as virtualisation targets behind the VSP.

The amount of extra server CPU cycles released to more productive application-related work through the VAAI support in the VSP depends upon the amount of storage overhead work the server was doing before the VAAI-VSP interface is implemented.

However, there is no absolute rule of thumb that applies here, and basically a lot of scenarios are possible depending on each specific implementation. But basic intuition says it would be in the one to ten percent area, perhaps a bit more.

But of course the storage array controller needs to have sufficient resources to carry out the extra duties coming its way through the VAAI. That's a given-- there is no question here.

Existing and supported HDS customers will soon receive the VAAI-capable microcode via their normal update process.

Add to     Digg this story Digg this    Get a great Ubuntu Linux dedicated server for less than $3 a day!

Share on Twitter

Source: High Tech News Today.

IT News Archives | Site Search | Advertise on IT Direction | Contact | Home

All logos, trade marks or service marks on this site are the property of their respective owners.

Sponsored by Sun Hosting, by Sure Mail™, Avantex and by Montreal Server Colocation.

       © IT Direction. All rights reserved.