We used to have 1 single large group for SRDF/A which involved ALL replicated symdevs. The downside of this is when we needed to expand the group, the whole group needed to be suspended during the expansion. If we had devided the group in smaller groups, not all of the replication had to be brought down.

You'll always learn down the road, which is good

I guess the main reason for having 4 "tiny" SRDF/A groups is simply for ease of management. With SRDF/A all devices belonging to a rdfg, will be managed as a whole thing: you must split/failover/set async/set sync/set acp_disk all devices belonging to the same rdfg (as you noted).

Since you have different clusters on the R1 side (and possibly hosts on R2 site able to "see" and use R2 devices in case you need) having different RDFG (one for each cluster) allows you to failover a single clustero on the R2 box without affecting all other clusters.

Unfortunatly there aren't only "best practices" .. we have also customer requirements that we must meet.

Message was edited by:
Stefano Del Corno

Rob it depends also on how many groups you need.. Old codes had limits (64 RDFG for each box) that recently grew up to 256. When we built our first STAR we had 100+ hosts on R1 side and only 64 RDFG .. That becomes only 32 since STAR requires 2 groups for every box. Thus we throw all devices in a single RDFG

Now with a much higher limit (and also few hosts) we may choose a different approach .. Now.. 3 years (and 2 major release of code) later

So with our shiny new DMX-4 on 5773 code we could essentially setup our srdf/a groups at a failry granular level. Allowing us to perform actions on indivudal servers if necessary. I guess its like using the async rdf groups like device groups in many ways.

So what would our limit be on a DMX-4 running 5773 microcode? We currently use 2 FA's (one in each fabric) for replication.

16 RDFG max without an RPQ.

RPQ = long and boring process that your sales team will carry on to qualify (and support) configurations outside allowed boundaries

thanks for the prompt reply Stefano, so I guess we can't be that granular with the async RDF groups (e.g. a group for each cluster). I figure we'll have to lump them into larger groups and then if an indvidual cluster needs to be failed over we move it into it's own group temporarily.

RPQ?

RPQ = Request for Product Qualification

Just about the same

Having 1 large group with many devices from different hosts is bad idea.

Best Practice is to have at least one group per host / custer system. That way you can enable "cosistency" protection for that SRDF/A group:

symrdf -g group_name -enable -nop

Whole point about SRDF/A replication is to have "consistent" state of all devices inside that group. That way you will be sure that application is consistent and recovery can be performed.

For larger applications, you can create even several groups per each host. Everything depends on application itself.

Danail, welcome to the forums. Be sure to introduce yourself in the coffee break area when you get a chance.