Is a Server Cluster Right for Your Organization?

Take advantage of the benefits a server cluster can bring: high-application availability, scalability, and simplified network management.

By Brien M. Posey | Posted Sep 28, 2000
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

With the size of enterprise networks constantly increasing, more and more demand is being placed on application servers. It's not at all uncommon to have thousands of people simultaneously accessing a single database application. Even with the most high-performance hardware the world has to offer, single server solutions often are simply not enough. Fortunately, Windows 2000 offers a way to combine the power of several servers. In this article, I'll introduce you to the concept of server clustering. As I do, I'll discuss some of the issues that you need to consider when planning a cluster.

What is a server cluster?

Before I begin talking about planning your cluster environment, let's address the question of what a server cluster is: a group of servers that function as one. By doing so, client machines see the service or application processed by the cluster as though it were coming from a single machine. There are three basic advantages to running a server cluster:
  • Server clusters offer scalability. This means that if you've got an application that requires two servers today, you can simply bring another server online tomorrow when demand on the application grows. Any time your application starts to bog down, you can plug in another server and watch the application's performance improve.

  • Clustered servers offer high availability. For example, suppose you had a cluster of three servers running a critical business application. Now, imagine that one of the servers experienced a critical failure. In the old days, your application would have been down for the count, and your business wouldn't have been able to function until the server was brought back up. In a cluster environment, the two servers still running detect the failure and adjust themselves to pick up some of the slack. The application may run a little more slowly, but it will never go down--it will continue to function normally. When the problem server is repaired, it can be brought back on line and resume its old workload.

  • Clustering makes managing the network easier. For example, how many times have you had to schedule system maintenance for 3 A.M. because that was the only time you could get away with bringing the server down? In some environments I've worked in, management didn't even like the idea of bringing down the network at that hour because the business functioned 24 hours a day. In such an environment, clustering is absolutely wonderful. An administrator can manually shift a portion of the workload to a different server so that they can perform maintenance on any given server without the application ever going off line. That's right: You can do your maintenance during the day! Once the maintenance is done, simply shift the workload back to the server you just tweaked and begin on the next one.

Hardware considerations

Before you can begin to plan a clustering environment, it's important to know up front what types of hardware and software you'll need. Let's begin by looking at the hardware. You can't cluster just any server. Windows 2000 clustering requires servers that designed for clustering together. Unfortunately, at the time this article was written, very few hardware vendors manufacture such equipment. Those who do offer such a product charge a premium price.

As you shop for servers that can be clustered, keep in mind that just because a server was designed to be clustered doesn't mean the server will work with Windows 2000. Windows 2000 has very specific requirements. The best way to see if a server meets these requirements before you buy is to check out the hardware compatibility list. You can find a copy of this list at http://www.microsoft.com/hcl/default.asp.

Software considerations

"When planning a server cluster environment, you must decide how much processor time each application receives. You must also decide how to handle a server failure. "

Now that you know about the hardware requirements, it's time to consider the software requirements. For starters, you need to know that Windows 2000 Server can't be clustered. If you're looking for cluster capability, you'll have to spring for some copies of Windows 2000 Advanced Server. Only Windows 2000 Advanced Server includes the Windows Load Balancing Service, which is the key clustering component.

Another consideration is that having the correct hardware and operating system isn't enough. The application itself must also be cluster-aware in order to take full advantage of clustering features. It is possible to cluster applications that aren't cluster-aware, but doing so involves some complications.

You can use two different methods to cluster noncluster-aware applications. The easiest method is simply to install the application on one of the servers within the cluster. However, doing so doesn't offer true clustering, because for the application to function, the server you installed it on must also continue to function. If you have to take down that server for any reason, the application becomes unavailable.

The other option is to install a copy of the noncluster-aware application into the same path on each server within the cluster. By doing so, you regain the ability for any machine to go down and the application to remain functional. You also lighten the load placed on the application, because clients run copies from several different computers. The down side to this method is that you run into some issues with opened files. For example, suppose the application was a database interface. If you installed separate copies of the application on each server, you'd likely end up with separate and inconsistent copies of the database on each server. Even if you could point all the copies to the same database, the database would be limited to existing on a single server, and you'd be right back to the application going down when the server fails.

Keeping a hot spare

As I mentioned earlier, it's possible for the administrator to control which services or application a server within the cluster is working on at any given time. As I'll explain later, this is an essential skill. This functionality offers one really big advantage: Because you can control each machine, it's possible to have a machine be part of the cluster and not work on anything. Such a machine becomes a hot spare available for use at a moment's notice, should another machine fail. When a failure occurs, simply allow the idle machine to do the job of the failed machine. Your clients will never know there was a problem.

Juggling applications

The main reason to regulate the amount of processor time each machine dedicates to each task is that in many environments, more than one application or service is clustered. This means deciding how important each application truly is. When planning a server cluster environment, you must decide how much processor time each application receives. You must also decide how to handle a server failure. Do you dedicate all remaining processing power to your most critical application? Perhaps, you just allow everything to run a little slower. Another option is to decrease the speed of one application to maintain the previous speed of the other.

Figuring out how to juggle applications during a failure situation is a big part of planning a server cluster. Doing so is called developing a fail-over and fail-back policy. The fail-over policy refers to what happens when a failure occurs. The fail-back policy is how the cluster reacts when the failed machine comes back online. I'll discuss these policies in Part 2 of this series. //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter