RDF different RAID levels

In a word .. YES

RDF creates relations between LOGICAL volumes, regardless of their protection.

Enjoy !!

PS Dave I'm going straight to my bed .. even a serie 9000 system have to sleep from time to time

I did my homeworks.. And I've been able to create a new "question" thread.

However if somebody else experienced similar issues, please post your experiences here. We'll cut this branch away later.

Just a Check...;)
If we have different Raid for RDF R1 & R2 , doesn't it give failure since it will have different device configuration ?

I get failure when the R1 devices are created with stripped and R2 in concatenated , so am wondering if Raid will not have that effect.

Cool Stuff
Thanks..

You are right .. RDF does care about metavolumes (since they are built at logical level). When you want to form a pair, you must have identical volumes on both R1 and R2 side. When I say "identical" I mean that must have the same number of members, striping must be the same and each R2 member must be same size as R1 members.
The reason for those restriction is that from code point of view, metavolumes simply do not exist. When you create a pair between metavolumes, the code will create different relations for every and each metamembers. You can check with "syrmdf list" command. It will show both metahead AND metamembers in its output. You MUST manage them (with Solution Enabler) issuing commands only against metahead. But if you look at the symapi.log you can clearly see that Solution Enabler translates your commands in commands against all metamembers, just like what happens with symmir, symclone and so on.
Coming back to the original question .. Since protection is done at a lower level, it's invisible to RDF so you can mix and match different protection types.
Just to name a simple example, we built a STAR configuration with 2-way-mir R1 devices, R5 3+1 at sync target and R5 7+1 at async target. And it's working since 2 years flawless

Message was edited by:
Stefano Del Corno

It's allowed (although not suggested) to have R2 members bigger then R1 members... Usually you have such configuration only when you have to migrate from smaller to larger devices. Even if allowed, it must be carefully planned since you have to verify first that the OS is able to use the new (added) space.. Usually with striped meta everything works fine .. With concat meta it's almost impossible for the host to use new space since it will appear as holes in the middle of previously contiguous data (not good at all)

And also note that using bigger R2 devices won't allow you to restore (or failback) from R2 to R1 devices.

Message was edited by:
Stefano Del Corno

Can you please clarify what you mean by "You will see performance issues in the future".

This is a somewhat broad statement that doesn't really take any customer designs or plans into account. We have some situations in our environment where we are mirroring data over SRDF/A that doesn't have specific performance requirements at the target site... it just has to get there and be available.

I agree that in certain situations this configuration MIGHT allow for performance problems, but I don't think we can say it WILL.

If it is SRDF/A then best practice is R2 volumes should be equal or better with respect to RAID protecttion or drive speed. It is not recommended for SRDF/A to have slow devices at R2 side. You can configuire slow devices at R2 and this will work but it is not best practice. You will see performance issue in future.

Best regards,

Majid Ali

Allen I agree with you .. It's suggested (just to avoid any potential issue in the future) to have same protection for both R1 and R2 devices when it comes to SRDF/A ... IMHO even with SRDF/S it's better if both R1 and R2 have same protection.

To make a complex thing easy, exp with SRDF/S any performance issue on R2 side will hit also on R1 side .. that's why EMC suggests to have same protection on both sides.

But when you think in real world terms, it happens to have completly different boxes on R1 and R2 side.. In our experience a DMX3, protected with R5 7+1 using 146Gb@15K with a lot of cache (and when I say a lot, I mean a lot) was a good R2 partner for a DMX3000, mirrored volumes, 146Gb@10K. A lot of variable means a lot of different answers to the same question

In a word .. we are not sure (so it's better to say "might" as you noted) that something bad will happen in the future. However we strongly suggest to have same protection

It is best practice your R2 should be same or better. You can put a poor design replication by putting slow speed devices at R2 side. Slow devices will take longer time to destage the tracks and this might impact your cache and in result SRDF/A session will drop. If you need more information go abck to documentation you will find some best practice SRDF/A design document and you will see additional detail.

Best regards,

Majid Ali

I wasn't disagreeing that this was a general best practice. I've just had some trouble with EMC technical staff lately (no one here on the Forums) providing advice without taking all the factor into account.

For example, I had a tech tell me that I had to downgrade the firmware on my Brocade 5000 switches from 6.0.0c to 5.3.1 He didn't read all the details of the case though as following his recommendation would have segmented my mixed McData/Brocade fabric.

I'm not trying to be argumentative, just trying to point out the we all have to be careful of making absolute statements without taking all the factors into account. I think this is especially critical for those Forum participants with the EMC logo on attached to their profiles as someone new may take their word as "gospel" without considering all the factors.

I hope this makes more sense now.

Should I call 911 and ask a fire brigade for this thread ??

Allen as I said the main point here is that "it depends" .. As you noted, it's not trivial to say what's bad and what's good .. However I think Ali was simply trying to underline that EMC strongly suggests to have faster R2 devices then R1 devices (even if it sounds silly since you usually work with R1 devices, not with R2 devices) ..

Sorry Stefano,

I was just trying to better explain why I was being picky on this point. It wasn't anything against Ali, just more of a general reminder to everyone how important it is to be careful (especially for EMC employees and regular contributors) how we phrase suggestions and best practices.

Ali, apologize if you got the impression this was in any way "personal". Maybe I'm just too sensitive right now (I'm oncall and running on no more than 4 hours sleep at any one time for four days now )

Sorry Allen .. maybe I've been too harsh with you ..

Let me say that I totally agree with you ..

While talking here, in front of our customers, we (EMCers) should be very carefull at what we say... I was simply trying to explain you Ali wants to underline that EMC strongly suggests to follow the best practice.

However a best practice is a suggestion, is someone else experience that worked fine elsewhere. Now it's up to you (we) to translate the experience in our real world, made of existing storages and hosts.

Cheers !! I hope you'll fix your probs soon !!

I do not want to argue with you this was the reason I asked you go back to documentation and you will understand what I am trying to say. If you do not like my answer then just ignore my posting but do not blame that I am posting something without knowing what I am posting. There are so many things you can implement this might work but if you saw any issue and open case with support and if they findout what wrong thing you did then you have to fix the design otherwise they will not support. For example we have also LCFD devices you may build SRDF/A using these devices but LCFD are not designed for SRDF/A so what I am trying ot say if something you can build this is not necessarily it is the best design.

Regards,

Majid Ali