We do see customers who – for whatever reason – are seeing slow throughput on the Double-Take or Livewire connections between two servers and/or sites. It can be difficult to figure out if the problem lies with the replication engine or the network itself. There are several great network telemetry tools you can obtain to help you find out, but the most available one is also the one most users don’t think to try.
If Double-Take is running slowly across a link that you believe should support faster throughput, the best first step is to stop the Double-Take connection and test the link. The easiest way to do that? Simple, take a 100MB file and drag and drop it from a folder on the Source to a folder on the Target. See how fast it can go across the network between the two servers. Believe it or not, this simple test has helped more than a few of our clients find out they were not getting the network throughput they thought they were – and in some cases less than they were paying for.
Here’s a real-world example: A client was having trouble because Double-Take was only transmitting data at a maximum throughput of 3.6Mb/sec over a link between New York and London. The ISP that provided the link had rated it at 45Mb/sec, and since they were not even close to 50% saturation on the link, they were rightfully concerned with the slow throughput they were seeing. Double-Take was queuing a large amount of data, so we definitely had more than 3.6Mb/sec of data change, and none of us could figure out why they were seeing such slow connectivity.
Finally, one of our Tech Support Engineers noticed that other data was also moving slowly across that link, and decided to check things out. Not having a network management tool handy, he simply dropped a file from a NY server onto a folder on a London server. The resulting transfer only moved at 3.5Mb/sec – slower than Double-Take was moving data! As it turns out, the ISP was single-thread limiting connections over that link (which turns out to be a somewhat common practice on inter-continental links). This meant that anything transmitting with a single thread – like both Double-Take and standard NTFS file transfers – would be limited to at most 3.7Mb/sec no matter what.
In this particular case, a WAN optimizer fixed the problem, but the point is that while we were attempting to troubleshoot a Double-Take issue for several days, the problem was actually a network hiccup. If we’d tried the transfer to start with, it would have been apparent that the Double-Take transmission system was working properly.
Truth be told, we do occasionally find instances where Double-Take isn’t transmitting as fast as it could for one reason or another. We can get those fixed up quickly, but first we have to confirm that the limiting factor isn’t actually the infrastructure. Simple tests like checking file transfer times can go a long way to clearing up issues quickly. In Server 2000 and 2003 you will need to do a little math to figure out the transfer rate, but in Server 2008 you can see how fast the file is moving right in the UI. If it’s a lot slower than the line speed, then there may be an underlying networking issue that’s keeping us from moving at top speed.
Filed under: Best Practices, Double-Take Availability, Double-Take Backup, Double-Take Move, GeoCluster | Tagged: LiveWire, Double-Take Backup, Double-Take Best Practices, network throughput
