Frequently Asked Question: How Much Bandwidth Do I Need for Replication?
I have been working on replication and disaster recovery solutions for over 20 years, and this has been a common question throughout. One of my colleagues used to reply with another question: “How long is a piece of string?”. The truth is that you can only know by measuring it. I once created a handy table showing data set sizes and daily rates of data change and, from that table, calculated a relevant size of bandwidth needed. This became a popular tool used by my fellow systems engineers at the time.
Networking has evolved since I created that table. For a point of reference, I believe that table topped out at 100Mb/sec available bandwidth. Obviously, both data and network speeds have grown a lot since then, but many of the relevant ideas behind measuring how much bandwidth you need still apply.
Here are some of the considerations I have encountered over the course of my career.
What is your daily rate of change?
This can be expressed as an absolute number or as a percentage of your data set size. For example, the data that you wish to replicate may be 20TB. If your rate of data change is 5%, then your effective rate of daily change is 1TB. There are 86,400 second in a day. This translated to roughly 100Mb/sec.
1TB -> 8Tb -> 8,000,000 Mb -> for a day: 8,000,000 Mb / 86,400 s = 92.6Mbps
This simple calculation is only a starting point. Let’s ask a few more questions.
Is your replication real-time or periodic?
Real-time replication will send data over the network as it changes, while periodic replication will send it in batches, sometimes hours apart. Sending that entire 1TB of data at once in a single batch, for example, would take well over two hours, saturating a 1Gb/sec connection. A real-time replication solution would use any available bandwidth to send only what is changing at any time, thus minimizing traffic over the network while still ensuring you have the most recent replica of the data for recovery.
1TB -> 8Tb -> 8,000 Gb -> Time to be transmitted over a 1Gbps connection: 8,000Gb / (1Gb/1 s) = 8,000 s -> 8,000/ 3,600 = 2.22 hours (~ 2 hours and 13 minutes)
Is your rate of change uniform throughout the day?
It is highly unlikely that your data change is uniform. You likely have peak time periods such as during normal business hours or other “prime time” periods of the day where other periods have a much lower rate of change. So, even with real-time replication, you are not simply experiencing 100Mb/sec of change. Most of that change may happen during shorter periods of the day, so the rate at that time may be much higher (3-5x, possibly during peaks). During these periods of time, there can also be more competition on the network, which leads to the next question.
Is there competition on the network for the available bandwidth?
If you do not have a dedicated connection just for replication, other processes are likely consuming bandwidth. This may not only affect how much data can be replicated, but any other processes on the network connection may be affected by constrained bandwidth, particularly during peak periods.
Is there in-line compression to reduce the amount of data being transmitted?
Network compression is common in replication solutions (or at least should be), but it does require extra processing to perform, so it may or may not impact production depending on where the compression takes place. Compression rates may vary depending on the type of data. You might expect a 40-60% rate of compression, depending on the data.
Are you using in-line deduplication?
Deduplication is a great tool for reducing data storage footprint, but it is more difficult to do in-line and in real-time during replication. It is typically more effective as a post-processing operation after data has been transmitted, but if your system can afford the extra processing for in-line deduplication, it can further reduce bandwidth needed.
Are you using WAN acceleration?
WAN acceleration is perhaps the best way to make the optimal use of bandwidth. It can combine compression, deduplication, and other optimizations to overcome latency and packet loss on your network that can affect bandwidth. WAN accelerators, such as HPE Aruba EdgeConnect, are typically physical appliances that reside on the network and offer the advantages of offloading all the processing of compression, deduplication, and other types of application acceleration, as well as optimizing the network for all traffic, not just a specific application or replication stream.
Do you have bandwidth throttling or Quality of Service (QoS) in place?
As mentioned earlier, your rate of data change may vary throughout the data, or if you are sending replication in periodic batches. During these times, you may need to throttle replication with restricted bandwidth to free up bandwidth for other applications or processes. This can be done with scheduled throttling techniques or more automatically with a QoS solution that prioritizes some applications or processes over others. During such times, replication can often queue until bandwidth is available.
In Summary
Taking all these considerations into account helps you get a much clearer view of what your bandwidth requirements may be. Also, there are many tools out there that can help analyse your data and network to determine what your rate of change is or what your actual available bandwidth really is. A tool like Zerto Analytics Predictive Infrastructure Planning can help you analyse your protected data and rate of change for real-time replication.
Taking advantage of analysis tools, replication features like compression, throttling, and prioritization, as well as WAN accelerators like HPE Arube EdgeConnect can help you get the most out of your network bandwidth.
Increase your knowledge about DR with our Disaster Recovery Guide!
David Paquette 
