Design Reccommendation for replication traffic between two Data Centers

[dtran]

Hi all, hope everyone is well !!

I am looking for best recommendations on how to handle replication traffic between two data centers. Here is what I got in place currently. I have a data center in CA and a backup data center in TX. Two data centers are connected via two separate MPLS providers (see attached diagram). I am currently using PBR to route replication traffic over to Verizon MPLS and the Sprint link is mainly used for normal production traffic. And what had happened in the past is that when my Verizon link goes down replication traffic would failover to the Sprint link and causes production issues.

I am thinking about separating replication traffic to its own dedicated link. Is it a best practice to have replication traffic on its own link ? Has anyone able to use the internet for replication ? please share your topology if you don't mind. What's the most economical, easy to manage solution for this ?

Thanks all in advance !!

Danny

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Has anyone able to use the internet for replication ?

Yes; I've also used it for all kinds of traffic, including VoIP (concurrently).

What's the most economical, easy to manage solution for this ?

Use both providers for all traffic concurrently, but configure QoS and provide replication "background" priority.

Well configured QoS allows usage of the same link for things like VoIP, replication, etc., concurrently.

[dtran]

Thanks Joseph for your replying !!

I just think it's not a good practice to have bulk traffic like replication to ride on the same link as other production traffic. Is my thinking wrong ?

Thanks !!

Danny

[Joseph W. Doherty · Accepted solution]

I just think it's not a good practice to have bulk traffic like replication to ride on the same link as other production traffic.

Why do think that?

I can say, I've run production links carrying VoIP traffic, SAP traffic, mail traffic, web traffic, video traffic and replication traffic all concurrently w/o issue.  Such links were often also running at 100% bandwidth all during business hours.

Again, the key is effective QoS, so things like VoIP aren't delayed by other traffic while things like replication traffic take advantage of any "left over" bandwidth.

[dtran]

Hi Joseph, I believe I got the idea from an engineer I met at CiscoLive a while back.

Do you have a sample QoS config you can share with me ? some QoS best practices ?

Thanks Joseph !!

Danny

[Joseph W. Doherty · Accepted solution]

If I have a router that supports CBWFQ, I'll often use a policy like:

policy-map sample
class real-time
priority percent 33
class foreground
bandwidth remaining 81 percent
fair-queue
class background
bandwidth remaining 1 percent
fair-queue
class class-default
bandwidth remaining 9 percent
fair-queue

Things like VoIP bearer go to the real-time class.

Things like replication go to the background class.

Most traffic goes to class-default, where FQ, alone, often keeps bandwidth heavy flows from impacting light flows.  Foreground and background class are for when you really need to guarantee better service to that traffic (foreground) or not be adverse to other classes traffic (background).