Question about managing FAST on a VMAX. We're being told by EMC to create duplicate storage groups for groups to which we assign a FAST policy. One group goes in a masking view and the other just gets the FAST policy assignment. The issue I have with this is that if our storage administrators add storage for the host, they have to remember to also add it to the FAST storage group. We also end up with twice as many storage groups as we would otherwise need. Seems like an ugly solution to me. If you're using FAST on a VMAX, how do you manage the policies and storage groups?
Solved! Go to Solution.
Just to mark this question answered, I'll summarize answers and when they are appropriate.
1. If you anticipate that only a small percentage of hosts will need storage with multiple policies and if you do not anticipate the need to move a single lun from one policy to another, the simplest thing to do is just associate a FAST policy with the SG in the masking view. When storage from a 2nd policy is needed, just create another SG and MV with appropriate policy associated.
2. If you frequently need multiple FAST policies for the same host but never anticipate moving a single lun from policy to policy, then cascaded SGs are probably the best bet.
3. If you anticipate needing multiple FAST policies for the same host frequently, and if you also expect to have to move individual luns from policy to policy, then see SANMAN386 comment above and reference the seconf option in that comment.
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.
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.