RA-groups setup versus performance

I have a further question for you: how's your bandwidth ?

Ok, so bandwidth is no issue here. Hmmm.... I've run SRDF/S in simply 1 RA group and had no issues, but then again, the bandwidth we have between the 2 sites is only 1.5Gb or so.

We have 4 x 2Gb from dmx to each of the 2 swithces ( fabirc 1 and 2 ) and between the switches 4 x 2Gb via DWDM connections (over 42 km )

Hope this te info you needed ?

It depends: if the quality of the fiber is good, then latency can be low, but this isn't always the case. 40km can be bad, just like snow can be yellow...

41 km is a "short" distance .. however remember that SRDF/S will be heavily impacted due to link latency.. The shorter, the better

Having that said, 40 km is good.

I think that if you have been told to split your 40 Tb in at least 6 different RDF groups, you should .. Unfortunatly there isn't an easy "rule" that works for everyone .. I think that my collegues already did their math and choose to tell you to split the workload between 6 different RA groups. It depends on the workload, on the distance, on a lot of different variables that my collegues hopefully already considered.



That's right .. if you have to manage all the 40 Tb as a single big "group" (i.e. you have a big database that spans all the 40 Tb) you have to use Composite Groups



AFAIK the main difference is that a CG can be populated with devices from different RDFg or even different boxes, while a plain DG may contain devices from a single RDFg. Having that said, I can see no further differences. Using a CG gives more options since the consistency of a single RDFg is managed even with a single DG while the consistency of multiple RDFg can be handled only with a CG.

Do you really need to manage 40 Tb as a single big object ?? Is it a single big database as in my example ??

ok thanks for those remarks but what i realy want to know is this:

EMC says that we are reaching a limit of threads which can be handled by one RA group. Our boxes has about 40TB SRDF'd in one RA group and they said that we reached the border where this will impact performance. they said 6 RA groups would be optimal for the machine, but didn't gave us any counts how much this will impact performance.

and offcourse the initial questions.

You are right .. I forgot to mention retransmissions ...

But I hate retrans .. and when I have a poor link I put pressore on my provider since I pay for a good link and not for retrans

I hope you dont have a single DB with 40TB....That is why Dataware House comes in to picture.

We uses 7 rdfg groups which are divided for different DBs which we use often use for DR test. It is an advange by NOT keeping different DB together

But some of the rdfg group does have more DB devices invloved where DB size are smaller.

Differnt rdfg groups help to put a schedule on different time frame and load balancing cross differnt time window. We sync each of the groups on every four hour widnow.

No, we dont have a 40TB database with srdf.

The 40TB is spread over several production database on different servers.

As the unix team is responsible for the failover things, they need to create SYMDG's to be able to issue the symcli cmd's...

If we start using more RA-groups we have extra administration because we need to know for which RA group the need extra storage...

Or we advise the unix team to start using SYMCG groups as these are able to have disks from different RA-groups.

Mee too

But unfortunatly we can't modify Ferry's environment So let's wait an answer to our questions

Message was edited by:
Stefano Del Corno

ThX Ferry ... your answer is usefull since if you can break your 40 TB into different (smaller) containers, you can use 6 smaller DG instead of a single big CG. You'll have obviously to modify your failover procedures (instead of failig over a single DG/CG, you'll failover one at a time the 6 differend smaller DGs) but you can put the 6 "symrdf failover" commands in a single script and run this single script instead of a "symcg failover" .. What I don't really understand is the need for "extra storage". But maybe I misunderstood what you wrote. Could you please explain in a different way what do you mean ?? Maybe we can find answers to your doubts and fears

Stefano,

I will try to explain via an example:

Say we have one server connected to the dmx with 4 production databases which needs srdf protection for DR reasons.

In time these databases grow and need extra disks.

So the unix team requests extra devices and they are masked out to that server.

They will add those disks in veritasdg's and symld the new disks in symdg's which they use for failover purposes.

If we start using more RA-groups we need to know which RA-group is used for that specifiek database disks. As they are not able to symld disks with different in one symdg (which the use to failover that database(s) ).

I was woundering if they could start using symcg groups (as to my knowledge these symcg groups contain disks with different RA-groups)

I think that the main issue you have is that you have static pairs between ALL devices in source box and R2 devices in the target box. You have an RDF pair even if the disk is unused.

That's (IMHO) the main issue.

Do you already use Dynamic RDF features ?? With DynRDF you can modify pairing between R1 and R2 devices at your will, without changing the binfile. With DynRDF you can protect only the data you need to protect. And when an host needs some more space, you create new RDF pairs between the new volumes used on the source box and their corresponding counterpart, using the RDFG you already used for your host.

Stefano,

We use dynamic srdf, so we create and pair the devices ourselves (bin's are much to expensive IMHO )

But thats what i meant with extra administration I need to keep track of where the want there disk for, and the corresponding RA-group, thus leading to the question can i let them start using SYMCG groups and in the back use different RA-groups.