Geographically Distributed Clustering

Both the failover and reinstatement procedures automatically perform a reboot of the primary server—not a concern in the case of a failover, but note that following reinstatement, no server will act as primary server until the original primary server is completely rebooted. In my environment, the reinstatement and reboot finished in less than 4 minutes. BrightStor High-Availability Manager's failover and reinstatement process is more automated and user-friendly than those of Octopus and Double-Take.

Double-Take's manual failover process occurs almost instantaneously. The automatic loss-of-connectivity failover involves a fairly long Time to Fail value, but if you know failover is imminent, you can click the Failover button to shorten the wait. During a manual failover, the source computer's name and IP address don't change and the computer isn't removed from the network. Therefore, IP address and name conflicts occur. To return to normal after a failover, I clicked Failback in the Failover Control Center. Doing so immediately removed the source server's identity from the target, and the software prompted me to restart or stop monitoring of the source server. After restarting the source server, I instructed Double-Take to restart server monitoring. At this point, two different sets of data existed on the source and target systems, and I could either copy individual files manually from the target to the source or use Double-Take's Restoration Manager to restore the entire replication set. I chose the manual copy method, which restored all file operations that weren't lost during the failover timeout period from the target server to the source server.

SQL Server Failover
Legato's Web site offers application scripts that facilitate failover configuration for servers running SQL Server or Exchange. I downloaded a self-extracting executable file that contained the necessary scripts and documentation for configuring both SQL Server and Octopus. I followed the documentation's recommendations for configuring the SQL Server machines, customizing the scripts, and creating a new specification for mirroring SQL Server data directories to enable effective failover. After discovering discrepancies between the scripts and the documentation's script examples, I called Legato support for clarification. A Legato support engineer sent me a simplified set of instructions and an upgrade to Octopus 4.2, build 330b, which let me use SASO - Alias to accomplish the SQL Server failover. After the 30-second manual failover process, an error message informed me that certain files were open during the failover and therefore warranted inspection before using them in production. The process of failing over and reverting back seemed easy after I repeated the process a few times, but I recommend significant testing and documentation of the procedures specific to your environment to ensure success.

As I mentioned in the Installation and Configuration section, BrightStor High-Availability Manager loads Application Notes on the server during a typical installation. To configure the servers for SQL Server failover tests, I referred to Application Notes for Microsoft SQL Server 6.5 and 7.0. I ran the Replication Task Wizard to establish initial parameters for a task (i.e., select replicated folders and enable IP failover), then clicked Advanced Edit to open the Editing Task window and the BrightStor High-Availability Manager console, which Figure 3 shows. In the Task Editor, I set up a Workload to replicate my SQL Server data directory, specified destination paths for the data, and assigned the provided SQL Server script to failover and reinstatement actions on both servers. (The script includes code for both failover and reinstatement.) Failover times were similar to those in the file server tests, but the loss-of-connectivity test resulted in a few more missed transactions than the manual failover test. The failover and reinstatement processes for SQL Server performed flawlessly, requiring little preparation or intervention.

To configure SQL Server and Double-Take in my test environment, I downloaded the High Availability for Microsoft SQL Server Using Double-Take 4.x application notes and associated scripts from NSI Software's Web site and simply followed instructions. Configuring Double-Take's SQL Server failover and failback required more manual operations than BrightStor High-Availability Manager did, but the steps were straightforward and easy. However, I would have found the documentation easier to use if it had more clearly described which server I needed to perform certain actions on. I opened the Failover Control Center and clicked Edit Monitor. In the Monitor Settings window, I edited the two downloaded scripts and specified when Double-Take should execute them.

   Previous  1  2  3  [4]  5  Next