At VMworld various people asked me why VMware did not support the use of Storage DRS and Storage IO Control in a VPLEX Metro environment. This was something new to me and when someone pointed me to a KB article I started digging.
When discussing it with the various teams the following is what we concluded for EMC VPLEX, this is what I drafted up. I have requested the KB to be updated in a more generic fashion (text all the way down below) so that the support statement will apply for all vMSC configurations. Hopefully will be published soon. The EMC specific statement, which I provided to the EMC VPLEX team, will look roughly as follows:
EMC VPLEX supports three different configurations, namely VPLEX Local, VPLEX Metro and VPLEX Geo. This KB article describes the supported configurations for VPLEX Local and VPLEX Metro with regards to Storage DRS (SDRS) and Storage I/O Control (SIOC). VMware supports Storage DRS and Storage IO Control on EMC VPLEX in each of the two configurations with the restrictions described below.
VPLEX Local:
In a VPLEX Local configuration VPLEX volumes are contained within site/location. In this configuration the following restrictions apply:
– Storage IO Control is supported
– Storage DRS is supported
– A Datastore Cluster should only be formed out of similar volumes
– It is recommended to run Storage DRS in “Manual Mode” to control the point in time migrations occurVPLEX Metro:
In a VPLEX Metro configuration VPLEX volumes are distributed across locations/sites. In this configuration the following restrictions apply:
– Storage IO Control is not supported
– Storage DRS is only supported when “IO Metric” is disabled
– It is recommended to run Storage DRS in “Manual Mode” to control the point in time migrations occur
– Each location/site should have a Datastore Cluster formed only out of dvols (Distributed VPLEX volumes) which are part of the same consistency groups, and only with site bias to that particular location / site!
– Example: Site A will have Datastore Cluster A which contains all dvols with bias to Site A.
The more generic support statement will roughly look like this:
This KB article describes the supported configurations for vSphere Metro Storage Cluster (vMSC) environments with regards to Storage DRS (SDRS) and Storage I/O Control (SIOC). VMware supports Storage DRS and Storage IO Control with the restrictions described below.
In a vMSC configuration volumes are distributed across locations/sites. In both uniform and non-uniform configurations the following restrictions apply:
– Storage IO Control is not supported
– Storage DRS is only supported when “IO Metric” is disabled
– It is recommended to run Storage DRS in “Manual Mode” to control the point in time migrations occur
– Each location/site should have a Datastore Cluster formed only out of stretched datastore and only with site bias to that particular location / site
– Example: Site A will have Datastore Cluster A which contains all stretched datastores with bias to Site A.
Hopefully this will help the folks implementing vMSC today to make the decision around the usage of SDRS. KB team has informed me they are working on the update and as soon as it has been published I will update this article.
** KB Article has been updated: http://kb.vmware.com/kb/2042596 **
Thanks Duncan, good to have this clearly defined.
Why is SIOC not supported with VPLEX Metro or across metro distance?
Michael,
After a PDL state occurs SIOC prevents the automatic recovery of the datastore. SIOC “locks” the datastore, to recover SIOC needs to be disabled, this is descibred in http://kb.vmware.com/kb/2032690
Do we need really to use Storage DRS if EMC FAST VP is used?
Definitely not from performance perspective but DRS can be also used for capacity balancing. Let’s assume you have several LUNs on top of single FAST VP disk pool. DRS can balance vmdks across LUNs in particular datastore cluster when particular LUN is over defined capacity usage threshold.
Funny, we use VPLEX since a few months. Right now there are only 500m between the sites. But in future the distance will be ~10-20 Km with at RTT of ~1ms. EMC told us that we can use SIOC and all the other things the same way we use it in our other clusters right now. We implemented the cluster together with EMC and with uniform access. We were told that with uniform access there is no need to split the datastore cluster in two parts, one for each site. So right now we have one datastore cluster with VPLEX vVols Volumes. Is this wrong?
In both the old situation (described in this KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2042596) and the new situation (described above) this is indeed wrong.
Is this also true with Fixed Path configuration? I can see that SIOC with IO Metrics could be a bad thing, but why do I have to create 2 datastore clusters with the dvVOLs. I don’t get this. But maybe I just don’t understand the article.
I still don’t see why “Each location or site needs a datastore cluster formed from stretched datastores and with site bias to that particular location or site.” is necessary if the hosts use Uniform Host Access (Cross-Connect) + witness VM. That’s the way EMC implemented the VPLEX here. Cross connect + fixed paths + witness.
It is a recommendation to avoid VMs to be migrated from a Datastore with affinity to Site-A to a datastore with affinity to Site-B. It is not a hard requirement. I would recommend it though from an operational aspect, especially if you also use DRS affinity rules.
Maybe the key here is there is only one rule set for the VPLEX distributed raid-1 volumes: “cluster-1-detaches”. We have just one single DRS cluster with 10 hosts and one sDRS cluster with all distributed volumes. No affinity rules at all. AFAIR this was the way EMC told us to set up everything. At the moment the 2 sites are on the same campus with a distance of only 500m, but in the future one site will move to a second location that is 10 Km away. The RTT will still be under 1 ms. I wish I had a proper HowTo, the documents I found do not cover everything and also seem to be a bit outdated.