Geographically Distributed Clustering

Clustering solutions let you boost the availability, reliability, and scalability of Windows-based servers. A typical clustering configuration that addresses availability consists of two or more like nodes, typically connected to a shared storage subsystem. When these nodes function in an active-active configuration, the workload is distributed between the cluster nodes; however, the typical purpose of a cluster is to permit failover in the event of an application or hardware failure—an active- passive configuration.

A variation on the active-passive clustering configuration uses data replication instead of shared storage. Data replication offers the possibility of clustering across a wide-area link. Products that support this type of cluster offer many appealing benefits beyond the disaster tolerance that geographically dispersed data affords. For example, the ability to specify different hardware configurations for each node decreases hardware costs. Additionally, the existence of a replicated data source can be extremely useful when you're performing data backup, application testing, and OS migration and testing.

I gathered three sample products that accommodate replication-based clustering with failover—Computer Associates' (CA's) Bright-Stor High-Availability Manager (formerly known as SurviveIT 2000); NSI Software's Double-Take for Windows 2000/NT 4.1; and Legato Systems' Legato Octopus for Windows NT and 2000 4.2. (Legato has since renamed its Octopus product Legato RepliStor and released version 5.0.) I tested these products' ability to maintain recoverability and high availability in a variety of failure situations. I also looked at unique capabilities that might make each product more suitable for a given application. VERITAS Software's VERITAS Cluster Server 2.0 for Windows 2000 and SteelEye Technology's LifeKeeper for Windows 2000 4.0 offer similar capabilities but were unavailable for testing.

The Test Environment
For the test environment, I used SHUNRA Software's SHUNRA\
Cloud to emulate a T1 frame relay circuit between the two cluster nodes. The primary node was a Hewlett-Packard HP NetServer LT 6000r with six 550MHz Pentium III Xeon processors running Win2K Advanced Server as an application and file server. The secondary node was a 2-way 550MHz Pentium III server, also running Win2K AS.

To test failover capabilities, I used three unique scenarios for the server: that of a typical file server, that of a Microsoft Exchange Server 5.5 server, and that of a Microsoft SQL Server 7.0 server. For each scenario, I removed network connectivity to cause a node failure, then performed a manual failover (typically a button or menu option). During failover, I monitored the time each product required to detect and act on a failed node and evaluated the effectiveness of each product's procedures for recovering from a failure and starting a manual failover.

Installation and Configuration
As part of its simple installation process, BrightStor High-Availability Manager prompts you to select which of the software's four components—Server, Console, Alert, Application Notes—you want to install. (The product documentation recommends that you install all four components.) After the 2-minute installation on my primary node, I needed to restart the server. I then repeated the installation process on my secondary node.

Double-Take's installation was equally straightforward, but the software also prompted me to answer a few optimization-related questions. I specified the size and location of a pagefile that Double-Take would use to buffer data during heavy replication traffic, and I specified that I would be using transactional applications (SQL Server and Exchange). The installation process created security groups for Double-Take administration and quickly installed the necessary files before prompting for a required reboot. I repeated the procedure on the secondary node.

Octopus's installation process was quick and easy, letting me install the software on the local and remote servers from one location in a matter of minutes. The process required minimal configuration and didn't require a server restart.