Thanks to our friends at EMC, I was recently given the chance to attend a session on EMC’s new storage acquisition, ScaleIO. This acquisition generated a lot of interest (and perhaps some confusion) as VMware Virtual SAN product seemed to play in that same storage area. My good friend Chad Sakac over at EMC wrote about this some 6 months ago in his evocatively titled blog post VSAN vs. ScaleIO fight! Chad explains where, in his opinion, each product can be positioned and how EMC/VMware customers have a choice of storage options. His article is definitely worth a read. I wanted to learn more about the ScaleIO product and share this with you.
I’ve been presenting at a number of conferences over the past number of weeks/months, both internal and external. While a lot of my sessions have focused around Virtual SAN (VSAN), I got a number of questions around whether or not the new Software Defined Storage product from EMC, ViPR, competes with or complements Virtual SAN. Since ViPR 1.0 is now available (since September), and a new release of ViPR is due out before the end of the year, I thought I’d take a closer look at what ViPR is all about and try to answer that question.
Hmm, it seems to be the week that’s in it for storage issues. After publishing the DELL EQL & VMFS issue earlier this week, I have now been given a heads-up on an EMC VNXe & iSCSI issue. The symptoms are ESXi hosts being unable to boot from an iSCSI LUN on the VNXe or ESXi hosts losing connectivity to iSCSI datastores.
I just got a notification about this myself today. Apparently there is some interoperability issues with VAAI (vSphere APIs for Array Integration) & EMC RecoverPoint on EMC VNX arrays. It looks like the VNX Storage Processor (SP) may reboot with Operating Environment Release 32 P204 in a RecoverPoint environment.
EMC have just released today a technical advisory – ETA emc327099 – which describes the issue in more detail but is basically advising customers to disable VAAI on all ESXi hosts in the RecoverPoint environment while they figure this out. Hopefully it won’t take too long to come up with a solution to allow VAAI run in these environments once again.
There is no doubt that Flash is hot right now. Over the past number of months, we have seen IBM acquire Texas Memory Systems (TMS), HDS unveil their own flash strategy and HP launch their all flash 3PAR P1000 array. Of course regular readers of my blog will have seen my posts about newer all flash array vendors such as Pure Storage, Violin Memory & Nimbus Data. The purpose of this post is to highlight XtremIO’s flash storage solution which was recently acquired by EMC.
In this post, I want to call out two important matters related to the vSphere 5.1 release & EMC storage. The first is related to Round Robin Path Policy changes, and the second relates to a VMFS5 volume creation issue.
EMC Isilon are providing even further vSphere integration features in their upcoming ‘Mavericks’ release of their OneFS operating system. This is great to see. The integration is in the area of vSphere APIs, both for Array Integration (VAAI) & Storage Awareness (VASA).
Let’s have a look at the VAAI enhancements first.
1. VAAI NAS integration
- Full File Clone/NFS File Copy – The Full File Clone primitive calls the storage array’s replication facility. In Isilon’s case, a writeable snapshot of the file is created, saving space since it does not need to clone the whole VM’s disk. This is very similar to the VAAI block primitive XCOPY. One difference I do need to call out however between block and NAS primitives is that the NAS Full File Clone primitive will only work with VMs that are not running. In other words, Storage vMotion operations do not use the Full File Clone primitive at this time, unlike Storage vMotion on block devices which support VAAI. I want to highlight that this is not a limitation in Isilon’s implementation; rather it is a limitation on the vSphere side. It is definitely something I want to see in a future implementation of VAAI.
- NFS Extended Stats – With NFS, vSphere only gets generic information about space consumption on Thin Provisioned datastores. The full details around the amount of space that is being consumed by an actual file on an NFS datastore at the back-end is not visible. This can lead to some space-management administration overhead as vSphere administrators may need to contact the storage admin for detailed information. In vSphere 5, all extended file and filesystem information are available via this primitive. For example, how much actual space is being consumed by a VMDK on the back-end can now be retrieved.
- NFS Reserve Space – In earlier versions of vSphere, there was no way for NFS datastores to create the equivalent of an “eager-zeroed thick” VMDK. In vSphere 5, with VAAI NAS support, you now have the ability to reserve the entire space for a VMDK on an NFS datastore with this Reserve Space primitive.
These primitives, of course, require the EMC Isilon VAAI NAS plugin, but this is easily installed via VUM, the VMware Update Manager. After watching some of the tests, the improvement is significant. An offline clone operation of a 120GB VM took about 7 minutes 15 seconds without VAAI. With VAAI, it took 1 minute and 29 seconds. This was almost 5 times faster. Nice!
vSphere Storage APIs for Storage Awareness, commonly referred to as VASA, is a set of APIs that permits storage arrays to integrate with vCenter for management functionality.
Isilon are now surfacing up a bunch of device capabilities with VASA. These are now visible in the vSphere client when examining datastores.
|ARCHIVE||Datastore resides on Isilon NL-series hardware|
|CAPACITY||Datastore resides on Isilon X-Series hardware|
|HYBRID||Datastore resides on a mixed Isilon hardware configuration|
|INVALID||Datastore resides on a mixed Isilon hardware configuration|
|PERFORMANCE||Datastore resides on Isilon S-Series hardware or SSD accelerated storage|
|ULTRA_PERFORMANCE||Datastore resides on Isilon S-Series hardware with SSD acceleration|
|UNKNOWN||The Storage Capability for this object is Unknown|
This is great to see. Isilon customers who deploy the VASA plugin along with upgrading to the Mavericks release can now reap the full benefits of VMware’s Profile Driven Storage feature. What this means is that deployments of VMs will always be error free, allowing you to select the correct datastore for your VM each & every time. The other benefit is that you can constantly check the compliance state of your VMs storage throughout its life-cycle (e.g. detect if someone inadvertently migrated to a lower tier of backing storage). You can learn more about Storage Profile but this blog post I did on the vSphere Storage Blog.
We don’t have enough vendors doing offloading with VAAI NAS, so it is a welcome sign to see Isilon introduce this. And I certainly like the VASA capability descriptions that they are surfacing up – I think this make it nice and clear to Isilon customers what sort of device(s) are backing their respective datastores.
EMC are a diamond sponsor at this years VMworld 2012 in San Francisco. I’m sure Jay, James and the rest of the Isilon team would be delighted to show you these new features. You’ll find those guys at booth 1203.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @CormacJHogan