Microsoft Cluster Service Alternatives

Matrix File Serving Solution Pack for CIFS. The Matrix File Serving Solution Pack for CIFS supports scalable and highly available Common Internet File System (CIFS) file shares in one of two modes: connection load balancing that uses Matrix File Shares or with failover support that uses Virtual File Servers. Either implementation allows access to file data stored on a Matrix Server PSFS cluster file system. A Virtual File Server, as the name implies, associates the CIFS share name and associated IP address with the active node of a Matrix Cluster, allowing the name and IP address to fail over to a standby server when necessary. When you use Matrix File Shares, each node of a cluster accesses the same shared PSFS file systems and clients access the data through each node’s name or IP address. In this mode, an administrator creates a DFS root that specifies a root share location on each of the nodes, and when clients access the data using the DFS share name, DFS balances the connections between the cluster nodes and detects when a node is no longer available. Clients must access a Virtual File Server by using the DNS host name or IP address—NetBIOS names are supported only by Matrix File Shares. Matrix Server costs $3,000 per physical CPU in the server.

LEGATO Co-StandbyServer AAdvanced and LEGATO Automated Availability Manager
LEGATO Software offers two similar clustering products. The bulk of this section describes LEGATO Co-StandbyServer AAdvanced, which provides application failover support for two-node clusters on standard server hardware (Microsoft-certified cluster hardware isn't required) running Window 2003 or server versions of Win2K. I discuss LEGATO Automated Availability Manager (AAM), which supports clusters that have as many as 100 nodes and other advanced features, later in this section.

Co-StandbyServer AAdvanced supports both shared storage and replicated data configurations. Nodes of a cluster belong to a cluster domain—a LEGATO concept unrelated to Windows domains. Agent software runs on each node. Primary agents maintain a copy of the replicated database containing information about the nodes, resources defined in the domain, and their current state. Both primary and secondary agents manage and monitor cluster resources on their node, with secondary agents sending the information to a primary agent. Because a functioning primary node is necessary for a cluster to work, LEGATO recommends that both nodes of a Co-StandbyServer AAdvanced domain run the primary agent and that you reserve secondary agents for some nodes of the larger cluster domains that AAM supports.

Co-StandbyServer AAdvanced monitors the health of an application by tracking services that the application uses. Both existence monitors (that simply verify that a service is running) and response monitors (that can query a service for an expected response) are supported. An Availability Tracking feature supports service level reporting for application uptime. Co-StandbyServer AAdvanced supports both active-passive cluster configurations (in which only one server is hosting applications and the other server is ready to accept failover) and active-active configurations (in which both servers are hosting applications which can fail over to the other server).

Like Microsoft Cluster service, Co-StandbyServer AAdvanced lets you define managed resource groups that comprise resource objects. Resource objects can include NetBIOS names used as node aliases, IP addresses, storage resources, and services. Co-StandbyServer AAdvanced supports several types of storage: shared disks, Co-StandbyServer AAdvanced mirrored volumes, LEGATO RepliStor replicated volumes, Windows shares, VERITAS VxVM volumes, and EMC's SRDF mirrored volumes. You can configure how Co-StandbyServer AAdvanced should attempt to recover when a resource group fails—for example, by attempting to restart a failed service or by moving an IP address to a backup NIC connected to the same subnet. You can also associate Perl scripts with resource groups to perform additional tasks when the resource group starts up or shuts down.

Three types of communications support Co-StandbyServer AAdvanced cluster operations: a domain network, a verification network, and isolation detection. Normal cluster communications occur over cluster domain networks, which LEGATO recommends be private networks dedicated to cluster communications. Co-StandbyServer AAdvanced uses a verification network to verify the state of the nodes when communications fail on the domain network.

Administrators can also configure other IP addresses on the public network that the agent on a node can ping to determine whether that node has been isolated from the network. In a replicated data cluster configuration, if a cluster mistakenly concludes that an active server has failed and starts an application on a secondary server while the primary server is still processing the application, updates to both copies of the data can occur. This circumstance, often called split-brain processing, can have serious consequences because neither copy of the data is complete. Co-StandbyServer AAdvanced’s isolation detection features protect against this condition. When a standby node realizes that it can't communicate with an active node, it pings other IP addresses on the network. If the pings fail, the standby node knows that it—not the active server—has a problem and doesn't initiate failover. The node can then run an isolation script, which might take actions to protect the application or attempt to recover the server.

Co-StandbyServer AAdvanced triggers failover when a primary agent fails to receive heartbeats from the active node for a user-specified length of time and the active node fails to respond to ping requests over the verification network. Administrators can optionally configure failover to occur when an unrecoverable failure occurs to a resource object.

LEGATO Availability Console (aka the management console) is a Java-based GUI that you use to monitor, configure, and manage Co-StandbyServer AAdvanced and AAM clusters. Figure 3 shows protected Microsoft Exchange Server resources in an AAM environment. Using the GUI, an administrator can grant other users access to management console functions at one of three levels: User-level access allows viewing of node status only, operator-level access authorizes a user to manage nodes and resource groups, and administrator-level access adds the ability to create and modify configurations. The administrator can also restrict the management console to run only from a particular Windows domain or workstation. A command-line interface program provides access to management console functions, with additional support for debugging and batch processing.

Co-StandbyServer AAdvanced performs block-level synchronous data mirroring between a FAT or NTFS volume on the source server and a volume of the same type and drive letter on the target server. Mirroring is bidirectional: Blocks written to either server are mirrored to the other. Co-StandbyServer AAdvanced intercepts writes to the source volume, writes the changed blocks to the target volume, and waits for the target write to finish before committing the write to the source volume. Because a write to a remote volume takes some time to finish (this lag time is known as the write latency), LEGATO recommends that the standby server be no more than 10km from the primary server. LEGATO recommends using a dedicated network link for replication traffic but doesn't require it.

   Previous  1  2  [3]  4  5  6  Next