Happy VMAXhumpday!  Hope everyone is just doing fine.  Is it almost May already?  I don’t know about you, but I’m ready for Summertime now!  Can’t wait to be out on the beach, sitting in the sand…dreaming about storage…..*record screech* Whaaat whaat?  No way.  I like storage but I’m not one of those geeks (although I will admit to reading a book about Unix shell scripting once-upon-a-time).

Anyway, last week I talked to you about masking views and I mentioned that some of these things can be cascaded.  What does cascaded mean?  Well it applies to two different areas on a VMAX.  One being storage groups and the other being initiator groups as I covered before in last week’s post.

For Storage Groups – This offers a way to combine multiple groupings of child storage groups into a separate ‘parent’ storage group.  Since a masking view can only contain one storage group, one initiator group and one port group, it is sometimes beneficial to do this.  Two examples come to mind.  One being different FAST VP policies applying to different luns in your array.  I haven’t covered FAST VP yet, but basically you can set differing storage tiering policies for things like log luns, data luns and others such as dev/test luns on an individual storage group basis.  Say you have an ESX Cluster and you want to present a few RDM’s to one virtual machine, some datastores to the whole cluster, and some archival datastores also.  You can create three separate storage groups and assign differing policies for FAST VP amongst them. In addition you can also have a storage group with no FAST policy assigned as well.  It would like something like this:

ESX_Cluster_SG (parent):

ESX_Cluster_RDMs_SG (Child Associated to 100:50:50 FASTVP Policy)

ESX_Dev_Datastores_SG (Child Associated to 0:50:100 FASTVP Policy)

ESX_General_Datastores_SG (Child Associated to 100:100:100 FASTVP Policy)

ESX_NoFast_Datastores_SG (Child Associated to NO FASTVP Policy)

What this allows you to do is to present “a bunch of stuff” under one consistent masking view.  It also allows you to keep things not only clean in Unisphere but easy to follow.

Like cascading storage groups, you can do the same thing with initiator groups.  This is really nice to have for clustered servers and very commonly used with VMware ESX clusters.  They look a little like this:

ESX_Cluster_IG (parent):

ESX_Cluster_Node1_IG (Child containing initiators for Node1 of your cluster)

ESX_Cluster_Node2_IG (Child containing initiators for Node3 of your cluster)

ESX_Cluster_Node3_IG (Child containing initiators for Node3 of your cluster)

This comes in super handy when say you scale out to more nodes in the cluster, etc. You can just create another initiator group for the new cluster node and add it as a child to the main cluster’s initiator group.  This way you don’t have to worry so much about multiple masking views, inconsistent lun ordering, etc for nodes in the cluster and makes everything much cleaner.

Another topic or good to know piece of information is that for ESX, or clustered systems when using cascading initiators, it is a really good to ‘set consistent lun’ to enabled within the parent initiator group.  In fact, if you don’t it can cause huge issues with lun addressing in ESX and Recoverpoint.  Here is a screenshot of what it looks like in Unisphere when you right click on your initiator group and hit ‘view details’.  You want to make sure you hit the ‘set flags’ button and make sure that the Consistent LUNs on the bottom is checked.

Of course there are some other use cases for cascading groups, but these are the most common we see in normal environments involving VMware ESX and other clustered servers.

Thanks for reading!

-sangeek