Example, Clustered File or Print Server

Applies To: Windows Server 2008

In this example, the fictitious company A. Datum needs to make files available to thousands of employees doing critical work for the company. These files need to be available 99.99% of the time, that is, with no more than 1 hour of downtime per year. A. Datum creates a failover cluster and configures a file server in the cluster named “FileServer1.” This means that either of two physical servers (two nodes in the failover cluster) can act as FileServer1 at any given time. The two nodes in the failover cluster use very similar hardware, run the same version of Windows Server 2008, and have exactly the same software updates (patches). This topic also includes an illustration of a similar example with a print server named “PrintServer1.”
This topic illustrates the following:

• Clustered file server before failover
  
  
• Clustered file server when a node develops difficulties
  
  
• Clustered file server after failover
  
  
• Clustered print server after failover
  
  

For examples that illustrate other designs, see Evaluating Failover Cluster Design Examples.

Clustered file server before failover

When the failover cluster begins providing service, the clustered file server, called FileServer1, is owned by Node 1. This is shown in the following diagram.
Node 1 uses a shared bus or iSCSI connection to the cluster storage and has ownership of the disk (or LUN) assigned to FileServer1. Node 1 also uses a network to send regular signals, called “heartbeat” signals, to Node 2, and receives heartbeat signals from Node 2. In this way, both nodes have a way of determining whether the other node is functioning and whether it is able to communicate through the network. In addition, both nodes are also on at least one network that connects them to clients and to the administrator of the cluster.

Clustered file server when a node develops difficulties

At some point, Node 1 develops difficulties, and has almost stopped functioning. Node 1 loses the ability to send regular heartbeat signals across the network to Node 2. The following diagram shows the brief time just after Node 1 stops sending the signals.

Clustered file server after failover

Shortly after heartbeat signals stop arriving from Node 1, Node 2 begins an orderly process of taking over the functionality of FileServer1. It brings online an appropriate IP address and the network name “FileServer1” (so clients can communicate as expected with the file server) and obtains access to the appropriate disk (or LUN) in the cluster storage. Then it makes the appropriate shared files and folders available to clients. On clients, there is only a short interruption of service, not noticed by most users. The following diagram shows failover occurring.
A similar process can be initiated by a system administrator for scheduled downtime. For example, if Node 1 is running correctly and is the current owner of FileServer1, but software updates need to be applied to Node 1, the administrator can use the Failover Cluster Management snap-in to deliberately move FileServer1 to Node 2 so that the software updates can be applied. Of course, when applying software updates to a cluster node, it is important to apply the same updates to other cluster nodes as soon as possible. This ensures that all cluster nodes will consistently respond in the same way.

Clustered print server after failover

This example shows a two-node cluster supporting a clustered print server, similar in structure to the clustered file server illustrated earlier in this topic. The clustered print server is called PrintServer1, and very recently was supported by Node 1. However, Node 1 has failed and has stopped sending heartbeat signals to Node 2, which initiates an orderly failover process. Node 2 brings online an appropriate IP address and the network name “PrintServer1” (so clients can communicate as expected with the print server) and obtains access to the disk (or LUN) in the cluster storage that contains the printer drivers. When the failover process is complete, Node 2 begins responding to print requests sent by clients. On clients, there is only a short interruption of service, not noticed by most users. The following diagram shows failover occurring.
For a description of how a similar process can be initiated by a system administrator for scheduled downtime, see the paragraph at the end of the previous section, Clustered file server after failover.

Additional references

• Design for a Clustered File or Print Server
  
  
• Checklist: Clustered File or Print Server (Failover Cluster) (http://go.microsoft.com/fwlink/?LinkId=129121)