FAST_VP Storage Group Admin

i assigned policy directly to storage group, the only time i create dedicated storage group for FAST is when i need to assign devices to different policies. You can look at cascaded storage groups to simplify some of that assignment.

We ended up doing the same thing. We have one masking view to the host , two storage groups associated with two FAST policies, which will give us a chance to move devices to different tiers. By doing this we will have three storage groups per host.

You may want to look into cascaded storage groups (as dynamox mentioned)... They were introduced for this use case. Create two child storage groups containing two different sets of devices, and associate them to two different fast policies. Then create a parent storage group and put the two child storage groups into the parent. Then put the parent into a masking view. That way you don't have to deal with adding the same devices to two different groups.

Sent from my iPhone

The issue with this concept is: if you need to move a LUN from child SG A to child SG B just because of a different FAST policy - this cannot be done online: removing the LUN from SG A makes it unavailable to servers.  And you cannot add the LUN to SG B first and remove it from SG A afterwards. So this does not make sense to me. My expectation was to use a child SG for mapping and a parent SG for the FAST policy. So this way I will be able to remove the child SG from a parent SG and add it to another parent SG (=FAST policy) online. But for any reason: you cannot apply a FAST policy to a parent SG.

Also: if you think about a cluster, server A with local LUNs, server B with local LUNs and some shared LUNs for A and B. You can have a SG for A, a SG for B and just add the shared LUNs to both SG's. Using cascaded SG's you will need three child SG's: one for A, one for B, one for shared LUNs as you cannot have a LUN in two child SG's of a parent SG. Does this simplify my life? No, it does not.

So my personal point of view: I see no advantage in using cascading SG's.

We're a new EMC customer, moving from HDS storage. In our environment, I'm just not anticipating the need for this capability. We very seldom have a need to to provide multiple tiers of storage to one host. Of course I understand why it's done sometimes, such as making DB logs higher performing than DB files storage. Our normal use case is moving all of host storage from one tier to another. In the HDS world, we simply do an online pool to pool migration. With the VMAX, we'll just associate a different FAST policy. If we ever have a legitimate reason to provide multiple tiers to a host we'll just remove the FAST policy from the SG in the masking view and create separate SGs with appropriate LUNs and policies. Also, as a work-around to the problem of moving a lun in a cascaded SG from one tier to another, I think I would just provision new luns in the appropriate tier and ask the host admin to migrate to it using a host side technique. For virtually all of my UNIX hosts. that would be non-disruptive and a trivial operation. Once the host is on the new tier, I could reclaim the old luns. That way, the outage wasn't my requirement.

The issue for me is that this would be such a rare requirement, it makes no sense to manage 3000+ SGs when I could manage 1500.

Not sure if this will work at all: you will need a masking view with child SG for A, another MV with child SG for B and a 3rd MV with the parent SG. Can I use a child SG for a masking view? In other words: can a child SG be used for a masking view?

I have a similar question and I am not 100% sure it has been answered here.  I am visual so I have pictures.  The first option I see is nested SGs.  In this model the child SGs have the FAST policy assigned.  That looks like this.....

But to change a LUN's FAST policy, the LUN needs to be removed from one child SG and then added to another.  This is disruptive.

I am also considering this second option, where access is assigned via the SG with no FAST policy.  And the FAST policy is assigned with stand-alone SGs.  Because the LUNs are assigned to both SGs, I can move a LUN from one stand-alone SG to another without losing access from the host.

This makes more sense to me.

You are a 100% correct. Option #2 is more easy and make more sense. Option #1 does not make any sense to me.

We have created additional 3 SGs strictly for fast vp purpose and each is assigned to a fast policy (gold,silver,bronze). So if you have to provision 1500 hosts, u only need to have 1500 + 3 FAST SGs.

I find it easier and less complicated than cascaded SGs or other solutions.

regards,

Saurabh

Thank you both.  I wanted to tag the question answered, but since I did not write the original post, I cannot. 

In our environment, no more than a handfull out of 1500 hosts asks for multiple levels of pwerformance. The vast majority will be all GOLD, SILVER or BRONZE and we never get requests to change the FAST policy for a single LUN. So for us, the simplest thing is to assign the policy to the SG in the MV. If the host needs another tier of storage later we'd just create another SG and MV for the new tier(Policy) as required. We just don't want to create additional configurations for 100% of hosts when only 2% will ever need it. We prefer simplification.

One problem with option 2 above is that it complicates provisioning. If new luns are added, the storage admin must add the lun to the correct SG for the host and then remember to add the lun to the other SG in the MV. I can see this extra step being missed. Option 2 might also cause complications if you're using automation via ViPR or similar.

Why don't we think of cascaded storage groups in this scenario?