Test/demo FAST

Question

Hello,

I have a client who is migrating from a DMX to a VMAX, and would like to see FAST in action. The plan is to migrate 10 hosts (which have say 5 LUNs each on the DMX) to the VMAX - but migrate only 1 LUN for each host. The remaining 4 LUNs for each host would remain on the DMX.

The intent is to see if having a total of 10 LUNs beloning to 10 different servers on the VMAX would trigger FAST to perform any relocation, and see the reports and relocation process, etc.

Is this a good way to test FAST? If not, what would be the best way to demonstrate FAST to the client with the current architecture?

Thanks

Prasad.

Quincy561 · Accepted Answer

If the LUNs have backend activity, they should trigger FAST movements.  Chances are the active parts of these LUNs would all fit in EFD, so it should show that we can move active stuff to EFD.  You may also see demotion to SATA if they bind to the FC tier.  Seems like a reasonable demo to me, however without the full capacity and workload, it will probably be more optimistic than when everything is on the VMAX.

PrasadCS · Answer

Right, so we'd need to research and ensure  the LUNs chosen to be placed on the VMAX have at least moderate to heavy I/O. Thanks for the input.

PrasadCS · Answer

Ok...so after migration, we see EFD tier heavily used, and so is SAS, and the SATA tier is occupied too (not as much as EFD). So this is just as described above. The issue is - the SAS and EFD tiers are completely filled up, and there is not enough space for provisioning new LUNs. The current LUNs on SAS or EFD don't have nearly the I/O that other yet to be migrated LUNs would have. So will these ever tier-down so we can enough space to provision othere hosts? It has been over 10 days now since we first started FAST VP.

Kleanthis76 · Answer

Dear PrasacCD,

There are many ways to demonstrate FAST. You can choose to use a very small Initial Workload Analysis period f.e. 2h and the same for Performance Analysis Period f.e. 2h. Then your box regarding FAST will respond to spike workload.

You need to understand the type of workload that you have (OLTP, DSS etc) to identify if FAST is good or not for you. FAST friendly workloads are the ones that are skewed workloads. For example: DSS systems are not FAST "friendly" because they are not skewed.

Another parameter that you have to check is the PRC (Pool Reserve Capacity) value which is the percentage of the pool that FAST will be able to use. By default is 10% and that means that FAST will use the pool up to 90% so you are still be able to bind LUNs to the rest of 10%. If the LUNs that are newly bound are part of a storage group that is associated with a FAST policy then FAST controller and Allocation Compliance Algorithm will apply the necessary changes so the SG is compliant based on the FAST VP policy. If your microcode is 5876 then you can enable "VP Allocation by FAST policy" so you can bind the LUNs on any tier but then FAST will allocate extents from other pools of the available tiers in order to avoid any full pool condition.

Regards,

Kl.

VMAX

Test/demo FAST

Was this post helpful?