Geographically Distributed Clustering

Double-Take responded with a quick failover process. After the failover timeout expired, the target server assumed the source server's identity, SQL Server services started up, and the target server started processing transactions. To fail back to the source server, I followed the same steps that I performed for file-server failback, except that this time I used the Restoration Manager to restore the entire replication set of data from the target system to the source. The software restored to the source server all file operations that weren't lost during the failover timeout period.

Exchange Failover
To configure the Exchange failover test for Octopus, I used the documentation and files from Legato's Application Script for Microsoft Exchange. Because the documentation discusses only the use of SASO without aliases, I used that method in my tests. Fortunately, the documentation's sample scripts matched the contents of the provided files. The process consists of creating several registry specifications to perform a one-time synchronization of Exchange-specific registry data between the two nodes and creating a File/Directory specification to synchronize and mirror Exchange data. You also need to configure before and after scripts to be executed on the target server during the failover and recovery phases. Carefully analyzing and implementing the lengthy list of steps took about an hour. The 1-minute failover went smoothly. I then needed to restart my mail client (Microsoft Outlook 2000) to reestablish communication with the stand-in mail server; after doing so, the failover was invisible from the user's perspective. The recovery process also works well—as long as you pay careful attention to the detail and order of the instructions.

To configure the Exchange failover tests in BrightStor High-Availability Manager, I referred to the accompanying Application Notes for Microsoft Exchange Server 5.5. In addition to outlining BrightStor High-Availability Manager's configuration process, the instructions provide details about installing and configuring Exchange on the target server. This process involves shutting down the source server and temporarily renaming the target server with the name of the source server. I could then use the source server's identity to install and configure Exchange on the target server. After I installed Exchange and the servers reassumed their original identities, I configured the Exchange replication task just as I had configured the SQL Server task. The Appli-
cation Notes instructed me to perform minor edits to the provided Exchange script template, save it, and configure BrightStor High-Availability Manager to execute the script before and after failover and reinstatement on both servers. The process of configuring the target server isn't overly complex or time-consuming, but it requires your source server (which is probably a production machine) to be offline for a significant amount of time. The manual failover process worked quite well and required just less than a minute for the target server to become the active Exchange system. Mail clients running Outlook 2000 needed to restart that application to reestablish a connection to the mail server. The reinstatement process was also easy and problem-free and finished in about 4 minutes.

For Double-Take's Exchange failover tests, I downloaded the High Availability for Exchange Server documentation and associated scripts from NSI Software's Web site and used them to configure my servers. Similarly to BrightStor High-Availability Manager, Double-Take requires that you install Exchange on the target server while it impersonates the source server, so the source server must be offline during installation. Double-Take includes a chngname.exe utility that you can use for this impersonation and during failover. After the Exchange installation and configuration are complete, the process is virtually identical to the configuration of Double-Take for SQL Server fail- over. The failover and failback procedures occurred quickly and without incident. The transition was so smooth during failover and failback that the Outlook 2000 mail client didn't require a restart to maintain connectivity with Exchange.

Which Is Right for You?
Octopus was somewhat more difficult to configure than the other two products, but as with most Legato products, the complexities are typically a trade-off for power and flexibility. The alias capability is a definite advantage in simplifying failover and recovery procedures. Octopus's limited methods for automating failover might seem inadequate, but Legato offers other products that integrate with Octopus for greater control over high-availability installations. And if you need to replicate registry subkeys, Octopus appears to be your only option. This capability's usefulness was apparent in how easily I configured the Exchange installation on the target server without needing to change its identity.

BrightStor High-Availability Manager is the easiest product to configure and manage, and it operated as expected throughout all phases of my testing—which is fortunate because the software's documentation is more of a pamphlet than a manual. The automatic handling of the source server during failover and reinstatement greatly reduces the chance of operator errors during these operations. BrightStor High-Availability Manager provides the most robust options for specifying and detecting failure conditions that trigger a failover. However, the product doesn't include bandwidth-management functionality to throttle the amount of bandwidth consumed during replication operations.

Double-Take boasted the fastest failovers and failbacks, and its Failover Control Center offers more flexibility for managing failovers than the other tested products. Double-Take's transmission-limiting options make the product an excellent choice for bandwidth-challenged environments. I experienced a fairly steep learning curve with Double-Take—mostly because of getting accustomed to the UI—but I had no trouble zooming around in it after a couple of days. The documentation is thorough and well organized. If you're considering replication between different platforms, Double-Take is your best bet because it supports the widest variety of OSs.

All three of these products achieve the common goals of mirroring and replicating data while enabling failover to a secondary server. Each supports command-line operations, which permit scripting and triggering of events through a separate monitoring application. The products' extended features and operational nuances will define the suitability of each solution to your environment.

End of Article

   Previous  1  2  3  4  [5]  Next