Geographically Distributed Clustering

The Octopus client also lets you perform manual failover. Two failover methods, as well as a variant, are available. Automatic Switch Over (ASO) replaces the target machine's identity with that of the source, and Super Automatic Switch Over (SASO) adds the source's identity to the target machine while maintaining the target's identity. The variant, SASO - Alias, passes an alias, or virtual identity (consisting of a computer name and IP address), between the source and target. This method accommodates failover between source and target computers that exist on separate subnets and simplifies the process of recovering from a failover.

In Double-Take, the target system monitors the source system for a failure by sending requests at a user-specified interval. When the source system is alive and well, it sends a reply. If the target system doesn't receive a reply, it counts a missed packet. (This functionality is similar to that of the Ping command.) The user-supplied value for the allowable number of missed packets multiplied by the monitor interval equals the failover timeout. On the Connection Manager's Failover tab, I set these values to three missed packets and a 5-second monitor interval—similar parameters to those of the other products I tested. Double-Take's Failover Control Center (which Figure 2 shows, along with the Double-Take Management Console) displays monitoring statistics and lets you control how and when failovers occur. You can specify additional IP addresses to monitor and make failover contingent on the failure of one or all of the monitored addresses. You can also require user intervention before the software initiates a failover.

Compared with the other two products, BrightStor High-Availability Manager offers the most options for detecting problems and initiating failovers. The intelligent failover option permits participating servers to ping a known device (e.g., a router) to determine the location of a communication problem and act accordingly. Additionally, low disk space or a bad disk can initiate failovers. You can alter these settings in the Task Editor by editing parameters under the Failure Detection icon. During a failover, the software transfers the primary server's IP address to the secondary server, and the primary server assumes a user-defined name and IP address until it's ready for reinstatement.

File-Server Failover
For each product, I performed network file operations against the primary file server while testing manual failover and loss-of-connectivity functionality. Manual and loss-of-connectivity failovers worked as expected on Octopus, each requiring about 40 seconds for the target server to stand in for the source. The time the software required to detect a connection failure amounted to 10 seconds of that time. During a failover, a stream of file copies flows to the file server. Any file-copy operations that time out—or fail to execute—during this period are considered lost. Octopus lets you specify a Max Wait Time value in the Switchover menu's Target Options option. I set this value to 10 seconds—if the target system can't contact the source in 10 seconds, the target system concludes that the source has failed. This value worked in my test environment, but if you use only Octopus's built-in failover-trigger mechanism, an unreliable real-world WAN link could compromise the dependability of your solution. Manual or scripted failovers are probably a safer bet.

To return to original server definitions following a SASO - Alias failover, you remove the source system name from the target system's Added Names list, then reenable and synchronize appropriate specifications on the source system. This process is much simpler than the SASO and ASO recovery processes, which require more configuration of names and IP addresses.

BrightStor High-Availability Manager performed well with a manual failover, losing one file operation, but the loss-of-connectivity test resulted in an approximately 40-second delay before the secondary server took over from the primary server. The timing for detecting communication failures is a component of the replication task's link speed setting. CA warns against exaggerating the link speed because doing so can cause false failure detection. To reinstate the servers to their original roles, you access the main BrightStor High-Availability Manager screen on the target system, go to the Server menu, and run the Reinstate Wizard. The wizard asks you to specify which server you want to reinstate. Then, you can choose to schedule the operation, warn users before the operation, and restart the replication task after the reinstatement is finished.

   Previous  1  2  [3]  4  5  Next