Testing Mirroring and Failover
For testing, I created several small database files (420KB) to replicate from the PDC to the BDC and started mirroring. From DTClient, I could monitor the initial mirroring of the files. I started the Failover utility on the target by typing in the domain name of the source machine and the interval at which I wanted the program to check the status of the source.
From the two other workstations, I ran a SQL program that would continuously increase the size of the database. I monitored the growth of the file size by opening the file folder on both the PDC and BDC and selecting the Details view. Process monitoring through DTClient provides only a snapshot, not cumulative information.
When the files had reached 5MB, I made the PDC fail so I could observe the failover capabilities. I immediately received network error messages on the workstations and continued to monitor failover from the BDC. After two minutes, the BDC reported that failover was complete. According to documentation, the workstations can log on to the BDC and access the files. But the documentation didn't explain how network users or systems administrators access the replicated data. NSI's technical support told me to use the journal functions of SQL Server or Oracle. Enterprise database programs, such as Oracle and Sybase, maintain transaction logs, and the restore process involves accessing those logs.
NSI's tech support didn't respond to the question about whether you have to run DT with SQL Server or Oracle. The documentation didn't cover what steps you follow to bring the PDC back online or whether you can resynchronize the database.
I came up with a workaround after two hours of troubleshooting. The BDC had assumed the name and role of the PDC. But even as Administrator, I couldn't manage user accounts. The system wouldn't let any workstations log on with user accounts. I created a shared file for the replicated files on the BDC and logged on to each workstation as the system administrator. This strategy let the workstations access the data, but I lost file security. The replicated data, however, was accurate to the moment the PDC failed.
I conducted another trial to see whether the BDC could be in an active state with users and still retain the role of target machine. Again, I did a clean reinstall of NT and DT to achieve the original domain configuration. I made the connection between PDC and BDC and initiated mirroring and failover. At first, mirroring from the PDC to the BDC operated well. I had configured one workstation to access a separate database on the BDC, independent of any DT software. When the mirrored databases reached 10MB, the entire network slowed down noticeably, and CPU usage on the BDC increased to maximum and stayed there. Time to complete queries to the database increased from 20 seconds to several minutes. The documentation notes that the more RAM, the faster the service operates.
When I made the PDC fail, I immediately received network errors for the workstations using the PDC. The workstation using the BDC locked up completely. Eleven minutes after I initiated failover, the BDC reported that failover was complete, and the BDC assumed the name and role of the PDC. I rebooted the workstation connected to the BDC, and the workstation logged on to the domain with its original user account. The BDC let the two original PDC workstations log on to the domain using their original user accounts, but the workstations could not access the database. As Administrator, I was able to create a file share on the BDC for the target folder, and then the workstations could access the database. Again, the data was complete up to the time of server failure.
The Report Card
DT has a 90-day warranty--including upgrades and fixes--from date of purchase, and the NSI offers yearly maintenance of DT at $300 per server. NSI also offers free, customized classes and training at its Indianapolis facility.
Because I tested the first NT version of NSI's NetWare product, I guess I had to expect some growing pains. The software mirrors data to the exact moment of server failure; however, DT doesn't make data immediately available on the backup system.
Installation would have been much smoother if I hadn't had to reinstall the NOS several times for DT to work. After I installed the program, I had only to choose which files or volumes to replicate and then connect the source and target systems.
The Automatic Failover Utility worked to a degree, but it doesn't support immediate data availability. The backup file server assumes the functions of the file server; however, the administrator has to re-create shares manually before failover. NSI's testing has shown that both servers must run the same NOS, NOS version, application version, database version, and utilities. DT's documentation warns that synchronization of the original data and the backup data can absorb all available network resources, leaving few resources for user operations; but the documentation doesn't explain how to perform synchronization. When the system is supporting many-to-one target configurations in a heavily used network, a large volume of data can overload the target and slow down the system.
Because I tested a beta version of DT, any recommendation would be premature. NSI is venturing into the NT market with this product, which has had years of success with Novell NetWare. I suggest waiting for a later product release so NSI can work out the bugs. (NSI planned to ship Double-Take 1.4 in May.) If NSI fixes the problems I encountered with the beta version, DT has good potential as a clustering backup solution. The Lab will keep you posted.