Hi GozCom08,

actually your question is good but the same is very generic because you have to keep in mind somethings in order to implement a FAST VP Policy.

When you want to accomplish a FAST VP Policy try to keep i mind:

Criticality of Applications

Reliability considerations

Current challenges and risks

Requirements for applications

Undrestand the I/O Profile

Determine Skew (Very important)

Replication technology

Identify Flash Candidates

Estimate Host Response Time (Very important)

To add a host or an application to the FAST VP Policy the host or the application must have SKEW.

Heavy skew enables a high percentage of SATA drives, (lowering cost)

The higher the skew the more likely you can eliminate the middle FC tier

Moderate skew is serviced very well by a 3 Tier solution with FAST VP

Low skew favors a 2 Tier design (mostly FC, with some EFD)

Regarding Policies:

Must add up to 100% for all tiers

Policy of 100% 100% 100% gives FAST VP unrestricted movement between tiers.

Separate performance classes can be established via policies (as you said gold, silver, bronze)

All of the above as i mentioned has to do with your enviroment profile.

You can have, let's say two policies, that those policies includes two policies of 3 differents tiers (FC, SATA, EF)

I mean one policy for Open Systems (FC, SATA, EFD) and one policy for ESX hosts using different Thin Pools for tiering.

I hope that this will help some how.

Hi,

I am currently Out of the Office. For any Centera related issues, please contact EMC Services Number at 1800 782 4362 or email: ahuja_directs@emc.com, for further assistance.

Thank you.

Regards,

Bashanta Phukon

EMC Global Services

PREM Centera

EMC²

where information lives

Hours: 7:00 - 15:00 IST M-F

Email: Phukon_bashanta@emc.com

E-Service at your fingertips: http://powerlink.emc.com

I've read your question a few times and I think I'm starting to wrap my head around what you are asking but I'm not entirely sure. So I'm going to reword it as I understand it and answer that question. If I'm on the wrong track maybe you can clarify the question a bit.

I think you are asking if you take a VMAX with three FAST policies created on it already (Gold, Silver, & Bronze) if you should associate each individual Storage Group you create for each host to a Policy. So each FAST VP policy would have multiple Storage Groups associated.

The alternative you suggest would be to create three additional Storage Groups and associate each one with one of the FAST VP policies. Then every time you add devices to a Storage group for a host you would also add the devices to whichever SG matched the policy you wanted for the devices.

I don't have the best practices information in front of me, but I can tell you that in our environment we go with the first approach. Each device is only ever in one Storage Group and each FAST VP policy has many SGs associated. We have not had any problems with administrative overhead as far as the array is concerned. And the administrative overhead for the Storage Admins is significantly reduced from your alternative. We ran this approach by the EMC experts when we were implementing and they didn't suggest that we were breaking any best practices.

Does that answer the question you were trying to ask?

Allen, thanks for your response.  I think you've answered the question based on your implementation which is to associate every Masking SG to a respective FAST VP policy.

The alternative would be, and I'm trying to understand the drawbacks, is having a single FAST VP SG (e.g GOLD_FVP - 10%, 100%, 100%).  ALL devices would be placed in this single SG.  (There can be different policies and devices would be added accordingly).  FAST VP would tally 10% of this entire SG for EFD, 100% for FC, & 100% for SATA, which would be the same outcome if it made these calculations for individual SGs.

Why the fuss?

After standing up a few multi-node clusters, with shared devices in a single SG, and non-shared devices in non-shared SGs, on more than one occasion, devices were added to the correct Masking SG - (storage add), but then were added in error to another FAST VP SG.  No big deal, since the FAST VP policy was the same for both FAST SGs.

In large shops with many hands in the pot, it's inevitable that devices will be incorrectly added to the wrong FAST VP SG. My point is, if this is going to happen anyway, why not design this way from the start?

You can still use symmigrate to move SGs within teirs.  You do use the ability to set FAST VP priorities - however 2 is the recommended best practice accross the board.

Sorry for the long response, however, I think this approach requires some consideration by engineering.

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....