This post is more than 5 years old
40 Posts
0
4363
A device cannot belong to more than one storage group in use by FAST
I do know that A device cannot belong to more than one storage group in use by FAST. I understand this is by design my question is to the wizards to find out how you handle the following situation.
I have two storage groups, LTCSIGECIZVH01-LTCSIGECIZVH04_CIG & LTCSIGECDZVH01-LTCSIGECDZVH02)_CIG (the CIG stands for cascaded initiator group).
I added one device to the LTCSIGECIZVH01-LTCSIGECIZVH04_CIG & associated it with a FAST VP policy. I then added the device to the LTCSIGECDZVH01-LTCSIGECDZVH02_CIG, and when I tried to associate this storage group to a FAST VP policy is when I got the above mentioned error.
I understand that I cannot do this, but I need to know how everyone else is handling this. Do you just associate one of the storage groups with a fast VP policy, and leave the other storage groups unassociated? How do you keep track of this? Are there any options I am not understanding or thinking of?
Please help?
deykau
18 Posts
0
February 1st, 2012 08:00
2 policies cannot work on a single device simultaneously. This is what we have done in our environment:
Grouped together the devices that should be under the same FAST policy (e.g. all SQL server log drives should have almost same performance requirement and can be covered under one policy) and create a different storage group and apply the policy on this storage group. This way, the devices are in 2 storage groups: one that is associated with the corresponding masking view of the server, the other one that is associated with a FAST policy, but no masking view.
Amita2
93 Posts
1
February 1st, 2012 07:00
Hi,
You are correct! One device can only belong to 1 storage Group that being controlled by FAST.
However, you can associate the same FAST policy with different Storage Groups. 1 storage Group can be associated with only 1 FAST policy.
If you multiple storage groups associated with same FAST policy, you can give priority value between 1 to 3. 1 being the highest.
deykau
18 Posts
0
February 1st, 2012 08:00
Yes we do use cascaded initiator groups for our ESX and cluster environments, not seen any issues implementing FAST VP though. Dont think the 2 have any connection (cascaded IG and FAST VP on a different storage group). The only road-block was to group together similar performance devices.
1thumb
40 Posts
0
February 1st, 2012 08:00
Thank you this looks like a good option. I will talk it over with my team. Are there any drawbacks to this approach that you have run into. Do you use cascaded initiator groups?