AAM. AAM uses the same architecture as Co-StandbyServer AAdvanced but supports as many as 100 nodes and has many additional features. You can use a system of rules supported by triggers, sensors, and actuators to automate AAM responses to a variety of situations. A trigger can be fired according to a preset schedule, in response to a monitored event, in response to an event-log entry, or on demand. A sensor monitors some aspect of a system or application and fires a trigger. AAM includes a software development kit (SDK) that you can use to generate custom sensors and actuators. Actuators, modules invoked by rules, communicate with AAM through APIs included with the SDK and can control the clustered application.
Co-StandbyServer AAdvanced pricing starts at $5000 for a pair of servers; additional charges depend on the applications being protected. AAM starts at $3000 per server; additional charges depend on the applications being protected and the size of the servers.
LifeKeeper for Windows 2000
SteelEye Technology’s LifeKeeper for Windows 2000 has a venerable history. AT&T's Bell Labs developed the original version to support crucial telephone-related systems. NCR further developed the product and sold it to SteelEye. SteelEye markets versions of LifeKeeper for Linux as well as for Windows 2003, Win2K, and NT, including both server and workstation versions of Win2K and NT. I describe LifeKeeper for Windows 2000 4.2 in this article, but the various versions of LifeKeeper have similar feature sets. Note that all the nodes in a cluster must run the same LifeKeeper version and the Win2K GUI can monitor, but not control, clusters running other LifeKeeper versions.
LifeKeeper supports failover for SCSI and Fibre Channel shared-storage server configurations. When combined with LifeKeeper Data Replication (also known as Extended Mirroring), LifeKeeper supports both local and remote replicated-data failover configurations. In configurations with SCSI shared storage, LifeKeeper supports two- to four-node clusters. In configurations that use a Fibre Channel SAN, LifeKeeper supports clusters with as many as 32 nodes. When using replication, LifeKeeper supports two-node clusters. SteelEye supports LifeKeeper on any hardware on the Microsoft HCL—the hardware need not be Microsoft cluster certified.
LifeKeeper consists of several components: LifeKeeper Core Software includes failover support for volume, IP address, NetBIOS name, and generic application resources. Core Software uses a configuration database, which LifeKeeper replicates to other nodes in the cluster and in which LifeKeeper records information about protected resources, dependencies, recovery scripts, and the current state of cluster and node operation. A communications manager determines the status of servers in the cluster and signals a server’s failure when the manager loses all communication with the server. The Alarm interface triggers events when LifeKeeper detects a resource failure and works with the Recovery Action and Control interface to locate and run the appropriate recovery script.
Optional licensable Application Recovery Kits (ARKs) let you configure failover support for a variety of applications. An Application Protection Agent, supplied with each ARK, monitors the health of the application and the server resources required to support it. Kits are available for Microsoft IIS, SQL Server, Exchange, IBM's DB2, Oracle9i, and many other applications. When no recovery kit exists for your application and the Generic ARK that's included in the basic LifeKeeper license doesn’t meet your needs, a LifeKeeper SDK helps you create your own recovery kit.
Each node in a LifeKeeper cluster monitors other cluster nodes by using a heartbeat mechanism. SteelEye recommends that each node in a cluster have more than one communication path to the other cluster nodes. That way, when one path fails, the next priority path can take over. When a standby server receives no heartbeat from the primary server over any path, LifeKeeper performs a safety check to ensure that the primary server is actually down. Only after verifying that the primary server is down does LifeKeeper initiate failover.
A node can run multiple applications. From LifeKeeper’s perspective, each application is a group of resources ordered to form a resource hierarchy. Administrators can configure the various resource hierarchies on a node to failover to different standby servers—that is, LifeKeeper supports a one-to-many failover architecture.
SteelEye touts ease of use as a key product feature. A wizard guides you through the node configuration process, and the ARKs install the resource types that the application needs. The LifeKeeper GUI client, a Java application running on the cluster node or accessed remotely by using a Web browser, lets administrators manage clusters from any workstation. Figure 4 shows the status of SQL Server resources in a two-node cluster. The LifeKeeper Configuration Database (LCD) and LifeKeeper Configuration Database Interface (LCDI) commands let administrators script management functions.
LifeKeeper’s replication engine performs block-level mirroring and replication for specified logical volumes. The volumes on the source and target servers must be NTFS format, have the same drive letter, and reside on Basic, not Dynamic disks. LifeKeeper monitors I/O writes to the source volume and forwards updated blocks to the target volume. LifeKeeper lets you choose synchronous or asynchronous replication, lets you schedule asynchronous replication for a particular time of day, and provides scripts that support a disk-to-disk data backup strategy.
LifeKeeper starts at $3000 per server. A complete Exchange solution costs about $5900 per server.
VERITAS Storage Foundation HA 4.1 for Windows
VERITAS Storage Foundation HA 4.1 for Windows is an enhanced and repackaged product that incorporates the features of VERITAS Cluster Server and technology drawn from other VERITAS products. VERITAS supports four cluster configurations. For a pure high-availability solution, Storage Foundation HA supports local clusters that use shared storage, the architecture supported by Microsoft Cluster service. For what VERITAS describes as a metropolitan-area disaster-recovery solution, Storage Foundation HA supports cluster nodes that include SAN-based mirroring solutions such as those offered by EMC, Hitachi, and IBM. Storage Foundation HA also supports replication-based disaster-recovery configurations when implemented with VERITAS Volume Replicator. Combining local high availability with remote disaster recovery, Storage Foundation HA and VERITAS Global Cluster Manager connect two local clusters in different locations so that an application can fail over to another local node for high availability and fail over to a remote cluster when the primary site is down. Global Cluster supports configurations in which primary site data is replicated to the cluster at the backup site by using either the Volume Replicator or SAN-based storage mirroring systems. Storage Foundation HA supports clusters of as many as 32 nodes.
VERITAS supports any server hardware found on the Microsoft HCL—it doesn't require cluster-certified server configurations. VERITAS does require that customers use SAN systems that have passed its hardware testing to ensure that Storage Foundation HA's dynamic multipathing features will function properly and to ensure that Storage Foundation HA will work reliably when customers use SAN-switch–based multipathing features.
Storage Foundation HA uses a standard InstallShield interface for the initial installation and can push code out to other cluster nodes. Storage Foundation HA's incorporation of other VERITAS products has simplified the installation process for many configurations.
Register
