This post is more than 5 years old
19 Posts
0
16989
August 14th, 2015 08:00
Replication - presync before moving SAN
I was told by Compellent support that if a replication link is broken, or if the SAN is re-IPed, replication must be setup again from scratch. Is that the case? If so there's no point is trying to presync a SAN before sending it to the DR site. It's almost hard to believe the system re-sends every bit of data if a link goes down or if you re-IP one of the SANs.
Every other replication tech I've used would rescan but that doesn't necessarily mean all data would be resent.
Also, they never answered this - if I used Async replication does the SAN use separate replays for that or does it use the regularly scheduled replays?
No Events found!
BVienneau
115 Posts
1
August 14th, 2015 12:00
That's not true, you can definitely move a SAN and have the replications continue from where they left off. Search the Compellent knowledge center for "CSTA - Preparing and Moving a Compellent DR Site". That walks you through the process of RE-IPing, etc.
If you use Async anytime there is a Replay of a replicating volume, it queues that up to be replicated. There are not separate Replays to accomplish this.
cpetry
19 Posts
0
August 14th, 2015 12:00
Yeah, I guess in my mind I'd rather have a chance at having the latest data vs no chance and only having a past replay available at the DR site. My company is fine with 24 hour old data but if there's a chance I can be a hero and have something newer that would be great.
I certainly don't have the WAN for real synchronous replication. It would impact the performance of my production SAN since the WAN wouldn't be able to keep up (45 Mbps link w/ maximum ping of 50 ms or so). I don't like the idea of my writes waiting on the copy to be acknowledged.
I downloaded a copy of that document you described. That's some good information.
Thank you! I'll mark your post as the answer.
cpetry
19 Posts
0
August 14th, 2015 12:00
Yeah, I really don't think a lot of the engineers understand replication. I found a great document describing all of the supported replication methods and modes. I'm going to use semi-synchronous, which is really asynchronous with "replicate active replay" enabled.
Right now I have a single daily replay being taken, and it's kept for 25 hours, long enough to overlap the next one and permit data progression (it's an all flash array). I'm going to change this to a more standard schedule so we can have options in the event of a DR situation. Esp since the active replay isn't guaranteed to be consistent with semi-synchronous. This shouldn't eat up much space considering we on average write 25 GB/day to all of our volumes...
BVienneau
115 Posts
0
August 14th, 2015 12:00
Yes, basically the only difference between syncronous and the async with replicate active replay is the lack of guarantee that the most recent block writes will be in DR if PROD goes offline.
If you are at all concerned about bandwidth constraints I would try offsetting some replication start times from others so you don't end up queuing up to much data at once for replication. Also, before you move the system, you can also change the QOS to match to what it will be like in DR to see if you will be able to keep up. That'll account for the pipe but not necessarily the latency but it'll give you a halfway decent idea if you'll be able to keep up. It's better to test that out before it's moved because it's easier to recover/catch up replications at that point than when the system is remote.
CamaraTokpa
2 Posts
0
October 14th, 2015 10:00
Hello cpetry,
Can you share your great document ??