How-To Use Failover Clustering for High Availability on Server 2008

Server 2008 comes with many new features that make it easier to manage. It also comes with a few that make it an even more robust server computing platform for the enterprise. One of these features is Failover Clustering.

Server clusters in Windows 2003 were so complicated to setup and manage that many companies opted instead for third-party solutions, or ended up with specialized administrators just for cluster management. For Server 2008, Microsoft has put the task of cluster setup and management back in the capable hands of all systems admins.

Note: One of the major differences between Windows Server Enterprise Edition and Standard Edition is that Failover Clustering is not available in the Windows Server 2008 Standard edition.

What Are Failover Clusters?

In Windows Server 2003, failover clusters were called server clusters. The new name provides a clearer picture of what is actually being setup and keeps it from getting confused with Computer Cluster Servers.

A cluster is a group of computers that operate independently yet communicate and operate more closely than other computers linked together via networks.

Each server in a cluster is called a node and they are hard-wired together. If one of the nodes in a cluster fails, the other nodes provide the service in their place. The best case scenario is that the user doesn’t even know that a server is down.

What’s New in Server 2008 Clustering?

  • GUID partition table disks are now supported. These disks can have partitions which exceed 2 terabytes and can have redundant partition tables unlike regular disks with a single master boot record. This allows for very large partition sizes and eliminates a single point of failure at the MBR.
  • Like in the rest of Server 2008 no legacy NetBIOS support is required, so no WINS or name-resolution broadcasts are necessary either for communication between cluster nodes, or for communications from clients that are properly configured.
  • Heartbeats are now sent as the more reliable TCP rather than UDP.
  • Clustered servers can be on different subnets. This greatly aids the ability to cluster nodes in multiple locations providing not just server system redundancy, but also eliminating site-wide problems such as power failures or other emergencies.
  • Failover clusters and their nodes have fully implemented support for DHCP on both the cluster itself and for the resources.
  • A cluster can have support for up to 16 nodes per cluster. That is double the number supported in Server 2003.
  • A huge plus for enterprises who want to enable clustering via storage area networks, or SASs, failover clusters no longer use commands which cause SCSI Bus Resets. So, now you can use storage area networks (SAN) without fear of those issues.
  • No Single Point of Failure at Quorum. Failover clusters can be configured so that if the quorum disk, which has been renamed the witness disk, goes down, the cluster can keep running as long as a copy of the cluster configuration database is still accessible.

How-To Setup Failover Clustering

Creating and deploying server clusters was a source of much frustration in Windows Server 2003. The process has been streamlined and simplified in Windows Server 2008.

In contrast to Windows Server 2003, failover services are not installed by default in 2008. Instead, they are a feature that can be added to the server (and thus can exist regardless of server role).

A new and improved Validation Tool helps ensure that there are no configuration issues or incompatibilities lurking in the server nodes. Plus, the Validation Tool can be run at any time without taking the cluster offline, so if changes are made to a server’s configuration or if a hardware upgrade takes place, the cluster can be re-checked to ensure it still meets the necessary requirements.

Once the servers have been blessed by the Validate Configuration wizard, creating the cluster is now an easy process. The new Failover Cluster wizard eliminates the need for manually setting up groups and dependencies.

In fact, the only thing the cluster must have to get started is a name and the list of servers that will be part of the cluster. If DHCP will be supplying IP configuration, then not even an IP is required.

After the cluster has been created, then it can be configured for the appropriate services. Configuring a failover cluster for a full server product like a SQL database, or Exchange Email server obviously take some specific steps, but for regular server-based systems like DHCP, File Servers, Print Servers, and the like configuration can be handled with the Failover Cluster Management snap-in.

From the Failover Cluster Management tool in Administrative Tools, right clicking the cluster name brings up a context menu. Select Manage a Cluster and then Configure a Service or Application.

The wizard then guides the administrator through configuring the failover of the selected service or function. For example, a file server failover cluster would require parameters defining which volumes to use and which shares to maintain.

The cluster management snap-in can also be accessed as CluAdmin.msc.

With the cluster up and running, management has been simplified via a much improved wizard interface. Many resources, including new disks, can be added to clusters now without the need to take the cluster offline.

Additionally, manually triggering the cluster to allow for system maintenance is easier, and can be tested prior to taking the system down by re-running the Validate Configuration wizard.

More in-depth information on failover clustering can be found in the new Server 2008 Applications Infrastructure Training Course for Exam 70-643.


This site uses Akismet to reduce spam. Learn how your comment data is processed.