Configuring and Planning a Windows Server Cluster
Setting up a cluster can be a great way to protect your data or to increase the speed of a Web site.
In the first three installments of this series ( Is a Server Cluster Right for Your Organization? , Choosing the Cluster Type that's Right For You , and Network Load Balancing Clusters ), I discuss the concepts involved in setting up a server cluster. As I do, I discuss some of the differences between the Network Load Balancing (NLB) model and the server cluster model. In this final article in the series, I'll discuss the server cluster model in greater detail.
|"If you're the type who wants it all, you'll be happy to know that you can have high availability with load balancing. "|
A Quick Cluster Refresher
Keep in mind that not all configurations keep the servers mirrored. Instead, the server cluster model relies on something called a fail-over policy. The fail-over policy dictates the behavior of the cluster during a failure situation. For example, suppose that the first CPU in a cluster were to fail. The fail-over policy on the second CPU would dictate which applications from the failed first CPU would temporarily run on the second CPU. The fail- over policy can also shut down non-critical services and applications on the functional CPU to make way for the extra load it must endure during a failure situation.
Configuring a Server Cluster
There are several different ways to configure a server cluster. Which method is right for you depends largely on what you're trying to accomplish. For example, are you more worried about high availability, load balancing, or both?
If you're the type who wants it all, you'll be happy to know that you can have high availability with load balancing. To do this, you'll have to set the cluster's policies to run some applications or services on one CPU and the remaining applications and services on the other CPU. You must then set the cluster's fail-over policy in such a way that if any of the applications or services fail, they will be run on the other CPU. Obviously, during a failure situation, the functional CPU may become bogged down, because it's performing twice the usual workload. Therefore, you might set the fail-over policy so that if either machine has to take over for a failed CPU, the unnecessary services or applications will be temporarily suspended until the failed unit comes back online. Although this method is tedious to configure, it provides a great mix of performance and availability.
If the idea of having a server bog down during a failure or the thought of shutting down unnecessary services bothers you, there are alternatives. One such alternative is to implement high availability without load balancing. In this implementation, one server basically runs everything. The other server in the cluster is on constant standby as a hot spare. If the first CPU fails, the fail-over policy shifts control of all applications and services to the second CPU. By using this method, your end users will probably never even notice when a problem occurs. When the failed CPU is brought back online, it takes over control of all of the services and applications, and the second CPU goes back into standby mode.