Advice: RepliStor vs DoubleTake vs Storage Replicator
-
Does anybody here use one of these products:
VERITAS Storage Replicator
DoubleTake
LEGATO RepliStor
All 3 companies have products to replicate{and/or} cluster across a LAN/WAN. I've not found anybody yet who use it in a production environement? Having been burned before - I still have nigthmares of wolfpack clustering on alpha with NT4
- I'm chicken and would prefer real comments from production people over white papers and magazine reviews).MS clustering is OK, and we sometimes use it, but not an option in this case.
Thanks,
Eric
-
We are currently using Double-Take in production to replicate both databases and application files for Active/Passive failover. Our average latency between our current main and DR sites about 10 km apart is about 30-50 seconds.
D-T provides some built-in functionality for failovers, but this did not do all that we needed in our shop. We exploited the D-T command line interface to allow automation of failovers just as we need it to be.
The main limitation in D-T is the time it takes to process each file when re-synchronising after an outage. One of our replication sets contains about 150,000 application files as well as a few databases, and takes about 2 hours to re-sync even though only a few MB of data has changed. This is due purely to the fixed time overhead for each file processed.
Another replication set contains just a few highly volatile database files and re-synchronises in a few minutes with many GB transferred.
Once synchronisation is complete, D-T seldom gives us any problems. When we did need some support, with an older version of D-T, their support staff were helpful and responsive. As far as we are concerned, D-T does what it says it will do, 24x7.
Having said all this, we are about to implement HDS 9970v SANs, partly as our DR site is moving to the other side of the Atlantic, and we will use SAN-based replication instead of D-T when this is live.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
-
Thanks Ed,
>about 2 hours to re-sync even though only a few MB of data has changed.
Oops. We also have a few dbs but also about 1.3 million files to keep in sync. Outage is not a problem (ups + emergency generator), but hours offline is unthinkable. Seconds yes, 30 minutes at most if there is an extremely good reason
Is there any other case where a resync can occur with D-T? Did you try other products and, if yes, did they have the same limitations? And does it perform well under load? Bandwitdh is not a problem.
Thanks, your opinion is really appreciated.
Eric
-
The evaluation was done before I joined the organisation. We have done mini-evaluations since then, and confirmed that no other Windows-based replication tool offers superior facilities to D-T. Some match it, while others are inferior. We did not move away from D-T to one of its peers because there was no point doing a sideways move. Other people may think the same about moving from their product to D-T.
D-T is also packaged within some other replication and geographic clustering products. It is maybe worth digging a bit wit hthese products to find out what is the underlying replication engine.
In general a full resync is needed only when one of the servers has to be rebuilt. Otherwise a differential mirror is all that is needed.
After we fail over or fail back, we need to resync the differential mirror. This is wher we have performance problems with D-T and large numbers of files. It appears ther is a fixed-time overhead for each new file, regardless if it is 1KB or 1GB. We are not aware that alternative Windows-based products gives major improvements in this area.
One of the justifications for moving to the SAN was the replication problem. SAN-based replication works at the LUN level (equivalent to physical disk level to Windows folks) so it is dependant solely on data volume, not number of files.
It was the considered view of both internal and external consultants working on the US data centre project that we had pushed Windows-based replication to it limits in terms of resync time with large numbers of files. We had little confidence that as file numbers grew we would be able to meet resync SLAs with Windows-based products, even if we were not moving our DR site over the Atlantic.
If you have 1.5M files to replicate, you should get your potential vendors to give good estimates for the time to re-sync this volume. You may find that Windows-based tools are not up to the job.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
-
In a larger environment, we use MirrorView to mirror SANs, but in the past I have seen Legato Octopus mirroring work well with SQL Server 7.0...
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply