Real-time data protection is quickly becoming one of the most important aspects of IT. To help keep datacentres and disaster recovery sites in synch, some companies are turning to high-availability products designed to kick in with synchronized replicas should a database or application server go down.
XOsoft’s latest version of WANSyncHA takes on this challenge with byte-level replication and automatic fail-over for SQL Servers, file servers, Exchange servers, and Oracle databases, and it does a good job with data recovery.
Installing WANSyncHA 3.71 was very easy, but getting it configured to replicate took a combination of study, trial, and error. Some of the concepts aren’t documented very well, leaving you guessing at the best options to pick for the type of data protection you want.
WANSyncHA provides a choice of two scenarios: Disaster Recovery, which provides data replication only, and HA (high availability), which provides replication and automatic fail-over.
Regardless of which data replication method you select, you can configure your replication scenario to suit your specific needs. For example, you can adjust the heartbeat between your two servers and select whether to re-IP a replicated server or just redirect the DNS when a server goes down. You can define your own scripts to run on redirection or on stop and start of the database; set rules for data compression, port number, synchronization type (block, raw, and file), spool size, and directory; and specify custom scripts to run before and after synchronization, maintain write order, and even replicate certain NTFS attributes.
WANSyncHA’s command line interface doesn’t disappoint, allowing you to create your own scripts and change replication variables based on certain conditions — such as when the synch directory is moving too many resources — or incorporate them into existing monitoring/alerting solutions.
WANSyncHA also offers Data Rewind, which allows you to restore to a previous point in time on a replica. The system creates time-stamped checkpoints for each I/O event, and rewinds to any checkpoint.
Sensitive synching I started by creating a disaster recovery SQL Server scenario, and WANSyncHA discovered my data and log files without any intervention. Synchronizing the servers is simple, and WANSyncHA performs the synch quickly.
Despite its synchronization prowess, the application seems to be sensitive to certain types of changes. For example, during my first test, I left WANSyncHA to replicate changes on its own in a long-term test. After a couple of weeks, I was forced to change the IP of my master server, and my replication scenario was wiped clean — forcing me to rebuild it from scratch.
After I set it up, it blew up on me, and I had to create a completely new scenario and re-synch both servers. Afterward, things were perfectly fine. Changing server IPs shouldn’t be a regular event, but the blow-up did require some extra effort and time to set it straight.
WANSyncHA does send event notifications; you receive alerts via e-mail or have them logged to the NT event log. What WANSyncHA doesn’t do is provide a way to test your configuration to make sure the e-mail process is configured correctly: You just have to keep an eye on it to make sure you’re receiving the alerts you’re supposed to. That’s not a good thing — you could be missing alerts for weeks and only find out about the incorrect configuration when something has gone horribly wrong.
In subsequent scenarios, I tested Oracle, Exchange, and plain old file system replication. Thanks to the lessons learned from my earlier IP address incident, I configured the scenarios quickly and kept them running with little trouble. I tested real-time and queued replication, fail-back and Data Rewind, reversed the replication scenarios on fail-over, and tested for data loss.
Time for a tune-up I tested real-time replication and fail-over under a moderate user load of 50 users. When I brought the master server down and WANSyncHA failed over, I stopped the scenario to check the level of data loss. There were quite a few missing transactions, but once I tuned the scenario and ran the test again, the data loss was minimal. I also initially had problems with fail-over time, where WANSyncHA was taking up to five minutes to fail over. Again, once I tuned the scenario, that problem disappeared, and fail-over took under a minute.
The lesson here? Be aware that you’ll need to tune WANSyncHA out of the box — not a difficult endeavor — to get the best protection level.
WANSyncHA doesn’t have the richest reporting options I’ve seen, but they’re adequate. You have the choice of text, HTML, or XML reports, and you can set up external processes to post reports on your intranet.
For the most part, I’m pleased with the way WANSyncHA performs under pressure. However, I suggest you test thoroughly and get your environment stable before implementing WANSyncHA in production.
WANSyncHA is much like its competitors, including NSI Software’s Double-Take and Neverfail Group’s Neverfail product, but it sets itself apart by its ability to replicate anything on your server, versus some of the others that specialize only in certain products.
QuickLink: 059328
