Active/active configuration: In an active/active cluster configuration, both servers perform meaningful work all the time. For example, an active/active cluster might have Microsoft SQL Server running on both nodes, or SQL Server on one and Exchange on the other. Active/active clusters let you fully utilize your server resources and can support load balancing.
Active/standby configuration: In an active/standby cluster configuration, one server functions as a cold standby (i.e., it performs no meaningful work) to an active server, or one server performs meaningful work but does not run the same application at the same time as the other server. For example, an active/standby cluster might have Microsoft SQL Server installed on both nodes, but running on only one node at a time; when a failover occurs, the database moves to the other system.
Alias: When you create a cluster, you create an alias that users connect to. From the cluster's standpoint, the alias refers to the server that owns the service at a particular time. From the users' standpoint, the alias refers to the service they connect to (e.g., SQL Server), regardless of which server the service resides on. When a failover occurs, users reconnect (unless the application or client operating system handles reconnection for them) to the alias (not to a server) and continue working. If users connect directly to the primary server rather than to the alias, they cannot reestablish their connections when the primary server fails.
Application recovery kit: Most clustering solutions have application recovery kits (DLLs, services, etc.) for specific server-side applications, such as Microsoft SQL Server, Microsoft Exchange Server, and Lotus Notes. The kit enables the clustering software to fail over all resources (files, IP addresses, disk drives) associated with an application from one node to the other.
Client agent software: In the past, some NT clustering solutions (most notably, Digital Clusters for Windows NT 1.0) required agent software to run on the client side. This software let users access cluster aliases, and even let some client applications understand and handle the service disruption when the primary node failed. Client agent software provided a way to easily create cluster-aware applications.
Cluster objects and groups: Most clustering solutions employ cluster objects and groups (services). An application, a disk drive (for database volumes, files, or directories), an IP address, and so forth are examples of cluster objects. A cluster group is a collection of related objects that make up a cluster resource such as SQL Server.
Clustering APIs: Most clustering vendors provide APIs so that you can design recovery kits for applications not covered by the basic clustering software. These APIs let you program to an established (possibly proprietary) standard; several vendors will support the Microsoft Wolfpack API standard.
Clustering DLLs: Clustering solutions have specific DLLs that provide cluster-aware functionality to let programmers create applications that fail over gracefully from one node to the other on system failure.
Distributed lock management (DLM): Distributed lock management (DLM) enables two servers to access the same physical disk at the same time without corrupting the data. If a device is updating a particular file or piece of data, the device gets locked so that another controller can't seize ownership and overwrite the data. NT does not currently support DLM, so disks are dedicated to one node or the other.
Failback: Failback switches the service or object from the secondary node back to the primary node after a failover has occurred, and resets ordinary operating conditions. Failback is usually a manual process, but can be automatic.
Failover: Failover occurs when a node in the cluster or a component of the cluster configuration fails. Cluster services or resources from the faulty node relocate to the operational node. You can also trigger failover manually (e.g., by turning off a system to upgrade it), taking one server offline and shifting the work to the secondary server. System failover capability means that only the entire system can fail over; individual objects (such as applications, disk volumes, etc.) cannot. The secondary system assumes the identity and workload of the primary system (only on system failure) in addition to its identity and workload. Application failover capability means that the systems administrator can fail over one application or object at a time, keeping all other services and users intact on the nodes.
Previous
Register
