When You Can't Afford a Second Chance... : 'A Review of NSI Software's Double-Take Mirror/Replication/Failover Software'

Mar 27, 2000

Part II

by John Cesta

In the second part of this review, John Cesta discusses some of the features of the Double-Take Mirror/Replication/Failover solution. See the previous issue of this News Alert for Part I of this article:

Failover...

Let's regress for a moment and quickly review a basic concept. Since both the source and target are on the same network, they cannot contain the same IP numbers. If they did, there would be a conflict in the TCP/IP protocol and both servers would come to a screeching halt. But, if the target is going to assume the duties of the source (in our case the target becomes the IIS4.0 Web server) it must contain the same IP numbers as the source. So, how does Double-Take accomplish this? That's the key question we asked. Here's the answer:

When defining a server as a target, Double-Take asks how many IP place holders you require. Let's say your webserver is serving 20 sites and all are IP-bound. The answer to the question would then be 20 place holders. What Double-Take does now is diabolical. In the Advanced tab portion of Network > Protocols > TCP/IP, DT writes 20 place holders in the form:

IP Address 0.0.0.0
Subnet mask 0.0.0.0

This clever manipulation fools NT into accepting the fact that there are 20 IP numbers in the NIC card. When it's time for the target machine to go into failover mode, DT replaces the place holder values of 0.0.0.0 with the real IP numbers from the source machine.

The configuration setup for the target's Failover mode is performed through a GUI called the Failover Control Center. Some of the options presented are:

Add Monitor
Remove Monitor
Edit Monitor
Failover
Failback

In Add Monitor, after selecting the source machine you wish to monitor, a graphical display shows the source machine and its IP numbers. You then select the IP numbers you wish to monitor and set the criteria for failover. You may:

Set the monitor interval in seconds (how often a signal is sent to check the source)
Choose when to trigger failover (i.e., When all monitored IP numbers fail, or when one monitored IP fails)
Perform failover of: (1) Monitored IP numbers or (2) All IP numbers
Set the failover server name and shares

Other Failover options include Pre and Post failover scripts. (After the failover process, you may need to restart DNS, Web services, and run some bat files.) The entire failover process depends on how many IP numbers you need to failover. If you provide, for example, IP-Less hosting and your IP numbers don't exceed, say 10, it will take less than two minutes for the target machine to completely assume the duties of the source. A blink of an eye.

A typical failover scenario...

The source fails, the target senses this and assumes the duties of the source.
The source is removed from the network and repaired.
When the source is ready to go back into service, clicking the failback button on the target instructs the target to set its IP numbers back to the 0.0.0.0 format and assume its original identity.
When the target is ready, it prompts if you would like to continue monitoring the source. Connect the source to the network (plug it back into the hub) and the target assumes its role as failover monitor. The data the target has amassed during its role as source may then be mirrored to the source. Or, before you reconnect the source you may restore the data manually. It's very clean and simple.

Mirroring and Replication...

The server designated as the source is the heart of the mirroring and replication process. In the GUI Management Console you define replication sets, as many as required. By clicking on the source machine icon, and opening up a Windows Explorer metaphor, you select which directories or files you want to synchronize to the target machine. You have the option of syncing data All-To-One (All the directories and files selected on the source will be copied to one directory on the target) or One-To-One (Each directory or file selected on the source will be copied to that same location on the target). If the target machine will be configured to monitor and failover the source server -- such is the case of failing over a webserver -- One-to-One is the option you would use.

Double-Take can be configured to automatically remirror on a disconnect. Mirroring options include:

Full mirror: Each time the source and target connect a Full Mirror will be performed.
File differences: Files are compared on source and target and copied to target only if different. Important NOTE: The File Differences option, while less bandwidth intensive, does not delete files on the target which are no longer on the source. This makes the file differences option almost impossible to use for anything but databases.

The data which has been selected for replication is initially stored in a queue on the source. Double-Take creates a configurable pagefile on the hard disk to assist with this. When an application creates, deletes, or modifies data on the source machine, the file requests are filtered by the Double-Take file system driver. After the data is written to the source disk, Double-Take converts the file request into replication packets. The Double-Take source then sends the packets, which are identified by the replication sets, to the target.

Bandwidth throttling...

DT allows you to limit the bandwidth it uses during data transmission. Your options are straightforward. You may specify the percentage of bandwidth to be used of the total bandwidth capacity available (i.e., 75 % of T1, or, 20% of 100mbs). The total bandwidth options range from 28.8kbs to 1 Gigabyte.

Security...

Double-Take offers multilevel security using native O/S-provided security features.

The Text client...

Double-Take includes a full blown text client which features all the functions of the GUI interface in a scripting language. Included are over 70 commands. Here's a short example of a Double-Take script that will start a Double-Take connection by creating a replication set named Exchange and connecting to the machine Thor. The script also sets up failover :

source odin;
repset create Exchange;
repset rule add c:\exchsrvr include, recursive;
repset rule add d:\exchsrvr include, recursive;
repset save;
connect Exchange to thor map exact;
target thor;
monitor create odin;
monitor move 205.31.4.193 to nic 3 interval 5 timeout 25;
monitor start odin;

These commands may also be run from the DOS command line.

What's So Great About It?
Relatively low cost of entry and administration Very easy to implement Works in addition to your existing configuration rather than designing your system around it Works in almost any network configuration and with almost any application

What Needs Improvement!
Text client needs tighter integration with the GUI Console (i.e., if a logon session is created in the text client, it should be seen upon launching the GUI Console ... Currently, it isn't. In order to reconnect a previously disconnected replication set, all the parameters must be re-entered. It seems as though these parameters could be saved as the default set. There is not much, really, that Double-Take doesn't provide. And, the new 3.1 version -- I've been told by tech-support -- has much better performance.
A small- to medium-size hosting company not experiencing a huge demand in traffic, and therefore not requiring a load balancing configuration, will benefit immensely from using Double-Take for data mirroring, replication, monitor and failover. A hosting company that does require a load balancing configuration can use Double-Take as an additional data backup solution. Also, we use Double-Take in our development labs to mirror/replicate, monitor, and failover our development machines. We're happy!

For more information about Double-Take, you can visit NSI's website at http://www.nsisoftware.com/, or email John Cesta, the reviewer.