UNSOLVED
diffirent fast for same server
Hello,
I have to allocate 3 differents classes of LUNs to a server. so i have to assign three types of discs (in the vmax i have already 3 different Fast Policys C1, C2, and C3, ...)
i think that we have to ways to do it :
WAY 1:
3 Masking Views with 3 differents fast policy for our server; like this :
M_Server_C1 = S_Server_fastC1 + P_Ports_Server + I_Initiator_Server
M_Server_C2 = S_Server_fastC2 + P_Ports_Server + I_Initiator_Server
M_Server_C3 = S_Server_fastC3 + P_Ports_Server + I_Initiator_Server
WAY 2:
M_server = S_Server_No fast + P_Ports_Server + I_Initiator_Server
i add Lun's twice , a first time to the storage masked with no fast and a second time to the appropriate specified Storage with the policy but not masked anywere :
+ S_Server_fastC1 (not masked but with the fastC1)
+ S_Server_fastC2 (not masked but with the fastC2)
+ S_Server_fastC3 (not masked but with the fastC3)
what's the way the most accurate, knowing that sometimes we have to pass a lun from a class to another ?
thank you in adveace for your help....
chirswilson
34 Posts
683
0
Posted February 13th, 2013 08:00
I'd go with WAY 2, Logically simpler in my view.
What microcode are you using? I believe 5876.159.102 allows you to have child storage groups but i have not personally tried it yet.
Kleanthis76
1 Rookie
•
27 Posts
683
0
Posted February 14th, 2013 05:00
As long as your server does not have more than 32 different types of LUNs you should use cascaded storage groups (as dynamox said) and you can assign to each child storage group a different fast policy. If you want to change fast policy to a child storage group you have the option to re-associate fast policy to a storage group without loosing any fast information for the specific storage group (of course the compliance algorithm will take over to make sure that the storage group is compliant based on the fast policy settings).
Using cascaded storage groups is a nice option but since the storage group is part of the masking view you cannot change the policy assignment for inidividual volumes as you can only operate at the storage group level.
For this reason I prefer using storage groups that are not part of a masking view for the policy assignment. This provides the flexibility to move individual volumes if needed.
I agree with AranH , cascaded storage groups is a nice solution for LUN that need a fix policy assignement throughout their lives.
in my case the problem comes from the fact that i have to move individual LUNs from a fast policy to another depending on the characteristics that the customer wishes.
in my opinion we have only 2 ways to do it as I described above and without reboot the server (with microcode 5876),
Before migrating à LUN from a fast to an other we have juste to dissociate the fast from the source storage group , add the LUN (symaccess add devs -LUN_id) to the second storage group remove it from the first storage group (symaccess remove devs LUN_id) reassociate the first storage group to his fast policy.
My question focuses on the most healthy way to do all that (WAY 1 , or WAY 2), to be honest I have not tested WAY 2 and I do not know if it works. according to you what's the best way ??!! and why ?
dynamox
11 Legend
•
20419 Posts
•
87439 Points
683
0
Posted February 13th, 2013 08:00
i remember hearing something where you can use cascaded storage groups and assigned different FAST policies to child storage groups.