Create a Cluster to Balance the Network Load - Page 2

By Drew Bird | Posted Apr 27, 2004
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn
Continued From Page 1

What Can You Use NLB for?
NLB is not suited to every application or environment. NLB is a form of clustering, but unlike server clustering it does not necessarily employ a shared data store. In other words, each server in an NLB cluster can be a fully self-contained server in its own right. This self-contained approach brings with it one major issue that dictates where NLB can be implemented — that of the "state" of the applications hosted on the cluster.

The optimal application for an NLB cluster in which there is no shared data storage, is one that is almost totally read-only, and whose data does not change on a frequent basis. Such an application is said to be stateless, as opposed to stateful. A good example of a stateless application would be a Web server that provided static information, and that had very little dynamic content.

“NLB is not suited to every application or environment. NLB is a form of clustering, but unlike server clustering it does not necessarily employ a shared data store.”

A corporate Intranet with perhaps a searchable database of product information is one application that comes to mind. A relational database like SQL Server, on the other hand, is a good example of a stateful application because the data on the server is likely to be changing on an ongoing basis.

NLB is not suited to stateful applications because, as was mentioned earlier, the data store is not necessarily shared among the servers. As a result, if NLB is used on servers that are each hosting a separate copy of a stateful applications, it would likely not be long before the data stores on each server became out of sync with each other. This is because, although servers in an NLB cluster communicate heartbeat information with each other, they do not communicate data.

Running a stateful application on an NLB cluster would likely result in a query run against one server yielding a different result than one run against another server in the cluster at the same time. The issue of whether or not an application is stateless is perhaps the biggest factor in deciding how you can use NLB on your network.

What Do You Need to Make NLB Work?
NLB is included with all versions of Windows Server 2003 including the Web Edition. In all cases, NLB clusters of up to 32 nodes can be created. From a hardware perspective, the only addition you will need to consider is an extra network card for each system in the cluster. The extra NIC allows servers to communicate normal network traffic with each other without impacting the performance of the network links in the cluster. If an additional network card is not available, you can still create a cluster with only one network card per system, but you will need to make sure that your network cards support multicast mode (which most do). You will also need to ensure that any routers you have on the network support multicast MAC addresses (which not all do).

While the additional hardware requirements for NLB may be minimal, it is also worth mentioning some of the other, non-Windows, considerations that you should think about before implementing NLB. Specifically, this refers to the network infrastructure surrounding the servers in the cluster. For example, there is little point in creating an NLB cluster of three servers with a view to providing fault tolerance, if those three servers are all connected to the same network switch. Doing so would create a single point of failure at the switch, and although switches are generally resilient, the ideal of eliminating single points of failure should still be a priority.

In part two of this article, we will look at the process of implementing NLB on a Windows Server 2003 system and at some of the tools used to create and monitor a cluster.

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