Fast VP with SRDF

Please consider moving this question as-is (no need to recreate) to the proper forum for maximum visibility.  Questions written to the users' own "Discussions" space don't get the same amount of attention and can go unanswered for a long time.

You can do so by selecting "Move" under ACTIONS along the upper-right.  Then search for and select: "Symmetrix Support Forum".

Symmetrix Support Forum

There is a full writeup on FAST VP and SRDF, including considerations and recommendations, contained in the "FAST VP for Symmetrix VMAX Theory and Best Practices for Planning and Performance" technical note available on support.emc.com.

https://support.emc.com/docu31003_FAST_VP_for_Symmetrix_VMAX_Theory_and_Best_Practices_for_Planning_and_Performance.pdf?language=en_US

Basically, it is not required that you have the same policy.  The R2s have to be associated with a policy if you want to use SRDF coordination, however.

I did not expect to see any it is more in the way of confirmation thought there may have been some conflict between the policy set on the two different storage groups on the two sites with the SRDF VP coordination enabled and did not know if it was needed on both sides to enable the match

We are only using async between sites so the IO performance of the R2 is not directly effect IO performance to the source host

It is more a case of making sure I more fully understand what the setting does so as to make sure it is working properly

Does the remote site also have to have the SRDF VP coordination check box selected to make it work as well the document seem to indiocate it is only needed on the R1 side

If we enable the setting to an existing set of replicated data does this have any adverse impact if both sides are set to the same policy

SRDF coordination only needs to be enabled on the SG containing the R1 devices - the performance metrics are only sent in the R1 to R2 direction.  However, there is no harm in also enabling it on the SG containing the R2 devices. That setting will only take effect if there are ever R1 devices in the SG.  The recommendation is to enable it on the R2 as well.  In the case of a failover and personality swap, metrics can then be sent in the opposite direction - it's one less step to have to do as part of the failover.

If you enable the coordination on an existing replicated SG, the only thing you are likely to see is more movement of data on the R2 array as FAST VP is now taking into account the R1 read workload on the R2 devices. You may start to see some data belonging to the R2 devices start to get promoted to higher tiers.

What kind of adverse impact do you think might happen by enabling it on an existing set of R1s?

The purpose of FASTVP/SRDF coordination is to ensure that the R2 is tiered as best as it can be by FASTVP to maintain production level performance in the event of a failover.

Without coordination, the FASTVP engine on the R1 side tiers based on the production workload, but the R2 side tiers on only the workload it see's which is essentially just the incoming writes from the SRDF replication.  So you get tiering of the most written blocks up into SSD for example.  But the R2 has no idea how many reads are occurring on the production side, and it's quite possible (probable actually) that a whole bunch of heavy read blocks that sit in SSD on the R1 side are demoted to FC or SATA on the R2 side.

With Coordination, the R1 array sends the FASTVP stats that it is using over to the R2 array and the FASTVP engine on the R2 tiers the LUN based on those stats, rather than the workload it is seeing locally.

If you are using FASTVP and SRDF, you will most like want to enable coordination as it will provide the best possible performance during a failover event.

The question is really about does the fast VP coordination work whether the r2 is in a storage group on the R2 side or not or whether it is associated to a FAST VP pool on the R2 side

Would of thought that as long as I have the same tier structure on both sides the FAST VP would as you say work on the stats it is collecting from the R1 side and respond likewise for the R2 whether it was in a storage group or not with the coordination set

As Fast VP policy are assigned per storage group this raises a intresting scenerio here

The DR scenerios as set up here are to use a BCV for the actual mount to the DR host and leave the R2 unmounted

So for a DR we would effectively clone the R2 and restart the host using the BCV

In normal circumstances I would not need to put the R2 into a storage group at all for this scenerio as I have no intention of masking it to any host l just bind the R2 to a tier so as to set up the R1 - R2 relationship

I have enabled the  RDF FAST VP coordination on the R1 side but am unsure as to whether the R2 needs to have it own fast VP policy set on the storage group at the remote site with the FAST VP Coordination setting enabled

If the R2 are not in a storage group they are not set to be subject to a FAST VP policy on the R2 site  so would the RDF VP coordination still work

I have been putting the R2 into a storage group just for a way to keep track of the R2 and what they are used for but not assigning a FAST VP policy relying on the FAST VP coordination to maintain the correct balance based on the stats from the R1 site as this is the way I believed it worked

I would have thought that enabling a FAST VP policy at the R2 side would add an extra set site specific statsand second seperate policy to the layering  of the storage

Obviously if I need to have the R2 subject to the same FAST VP policy at the R2 site I can just add this to my storage groups at any piont

And as per ealier answer it would be easy to just enable teh RDF Coordiantion at any piont for a particular Storage group when R1 are added

SRDF coordination will only ensure that R2 site gets the performance sample of corresponding R1 devices and these perf stats are then merged with the perf stats of the R2 site.

Do you need the r2 devices to be part of a storage group (masking)? Only necessary when you would like to test failover and mask the devices to the DR host.

Do you need r2 devices to be part of stoage group( fast policy)? yes, i would put my devices on r2 in a separate SG which is associated with a fast policy.

Do you need to have the same policy or tiering as of R1? Not a compulsion, perf stats gathered (local stats + stats from r1 side) will promote/demote chunks as per the policy defined on the r2 side. But if you have plans to run the application from DR and expect the similar response time then configure your r2 same as r1.

Note: FAST VP SRDF coordination only shares the perf stats not the policies and tiering information.

regards,

Saurabh

Ok that clear it up for me

If all the SRDF VP coordination does is effectively share the perf stats from teh R1 side to the R2 side then The R2 will need to have a FAST VP policy enabled and for this it needs to be in a storage group

Would of thought that it would have been more effective if it did enforce the same tier level for each extent on to the two sites so maintaining parity but from teh above it looks like it just adds more details to the IO profile used by the R2 site to enforce promotion and demotion based on the policy set at this site

Thanks for the info  everybody

Yes, you got it Michael. Not all customers can afford r2 site same as r1 May be in future, EMC puts another checkbox to share the teiring information to r2 sites.

regards,

Saurabh

Saurabh

Actually that make a lot more sense

Regards

Michael Churchill

There is another piont here if we enable the same SRDF FAST VP Coordination setting on the R2 side  would we be effectively sending the per stats from the R2 to the R1 side

This would effectivly mean we would get a aggratate of the two side IO in terms of the tier it sets at the primary sight

This may not be ideal and may be why the documentation only say to set it on the Primary site

for example If r2 devices are not associated with out any fast policy.. Enabling the srdf coordination on r1 devices will move the r2 devices b/w tiers...??