NLB works by enabling you to specify a virtual IP address. This virtual IP address works just like a real IP address, except that it doesn’t represent an individual computer. Instead, the virtual IP address represents the entire cluster. Any network traffic sent to the virtual IP address will be handled by NLB. NLB also creates a virtual MAC address, and reprograms the load balanced adapter on each cluster member to use that MAC address rather than its own. The effect of this reprogramming is that all cluster members can see all of the traffic sent to the virtual IP address. NLB then decides which server will respond to each incoming request.

Every second or so, NLB builds a routing list by querying each cluster member for information on how busy it is at the moment. The routing list is simply a list of all cluster members, with the least-busy member at the top, then the next-least-busy member, and so forth. The routing list also takes into account a server weight, which you can configure to represent computers which are physically capable of handling more traffic than others. For example, you might configure your oldest Web servers with a weight of 10, while configuring your brand-new Web server—which is twice as powerful as the older ones—with a weight of 20. Weights ensure that incoming traffic will be load balanced according to each server’s relative capabilities. The routing list also accounts for servers which are unresponsive, or which have been temporarily removed from NLB routing for maintenance purposes. These servers are left off of the routing list, ensuring that they won’t be expected to handle any incoming client traffic.

Each cluster member maintains a copy of the so-called routing list. When traffic comes into the cluster, each cluster member sees the traffic, but only the server currently designated as the least busy actually responds to the traffic. Since the routing list is updated constantly, the least busy server will almost always be the one to handle new incoming traffic.

While NLB provides very responsive load balancing capabilities, it can actually cause problems in some cases. The most common problem is caused by ASP session variables. A session variable is a software programming object that Web developers can use to store information about a Web user in the server’s memory. Session variables make it easier to write dynamic, interactive Web applications, but they store information entirely in the server’s memory. By default, NLB ignores session variables, which can cause an inconsistent user experience for Web users. To see why, I’ll walk you through how NLB works on a Web site that uses session variables:

In a real-world context, imagine that you’re visiting an e-commerce Web site. You click on an item to add it to your shopping cart. However, when your shopping cart is displayed, it’s empty. The cause might be that the first server you connected to, which accepted your click to add a product, is a different server than the one that displayed your shopping cart. Because the two servers have no way to share session variables, you have a confusing shopping experience to deal with.

The best solution, of course, is to not use session variables at all. Experienced Web developers will instead store user information in a single back-end database, which is equally accessible to all of the Web servers in a cluster. That way, no matter which server a user connects to, their user data will be available, creating a consistent experience. Unfortunately, if your Web site already uses ASP session variables, converting them to another storage method can be complex. For that reason, NLB contains a feature called client affinity, which enables you to partially defeat load balancing to maintain session variable compatibility. Client affinity can be set to three modes, including “off.” In single client mode, NLB ensures that the same server always handles requests from a particular client IP address. The first request from a new IP address is load balanced normally, while all subsequent requests are handled by the same server that handled the first request. Although this technique partially defeats load balancing by only balancing the first request, it ensures that the server containing a user’s session variable data will be the one that user connects to.

Unfortunately, single client mode only works well in intranet environments, where a relatively small number of IP addresses are in use, and where each client accesses the Web cluster directly. On the Internet, clients are far more likely to access the Web cluster through a corporate or ISP firewall, which probably performs Network Address Translation (NAT). NAT allows a large number of clients to access the Internet by sharing a small number of IP addresses. The firewall (or other network device) translates the client’s private IP addresses into a small pool of public IP addresses. The effect of NAT is that thousands of clients can access your Web site, yet appear to only be using a handful of IP addresses. Even worse, NAT may select different translation IP addresses each time a client sends a request to the Internet. So, on the first connection to your Web site, a client may appear to be using the IP address 64.12.34.5; a subsequent connection from the same client might appear to be coming from 64.12.34.6. NAT defeats NLB’s single client affinity mode, because a single user may appear as multiple IP addresses. NLB’s solution is Class C affinity, which uses a single Web cluster member to handle the requests from an entire range of about 250 IP addresses.

The most obvious downside to Class C affinity is load. Suppose, for example, that an America Online user accesses your Web site. NLB might load balance the request to one of your least-powerful servers, if it happens to be the least busy server at the time. With Class C affinity turned on, that poor server will wind up handling the majority of traffic from America Online users, which can be quite significant. This situation applies to any ISP or corporation: Because ISPs and corporations generally configure NAT to use a range of addresses from the same Class C range (which includes about 250 addresses), NLB’s Class C affinity has the effect of dedicating one server to entire ISPs and corporations, effectively defeating the whole point of load balancing.

NLB requires that you consider a number of factors in your design:

That last point is especially important for cluster administration: All cluster administration must be done on the cluster controller. If you try to connect to the cluster controller’s load balanced adapter, your traffic will be load balanced normally, and may not reach the controller at all. NLB does include a Request Forwarder feature, which detects incoming administrative traffic and forces it to the cluster controller, but the Request Forwarder can significantly reduce the performance of NLB and your Web servers. Instead, simply direct all administrative traffic to the back-end adapter of the cluster controller, which isn’t load balanced. Your network design should accommodate this use, enabling any administrators to easily connect to the cluster’s back end. Figure 6.1 shows a sample network design that illustrates this design technique.

Figure 6.1. Real-world designs should also include firewalls if your cluster will serve Internet-based clients.

Application Center enables you to form CLB clusters, in much the same way that you form NLB clusters. CLB clusters must all have the same COM+ components installed, and they must all share a network connection. Unlike NLB, CLB cluster members are not required to have two network adapters. The CLB clients—the computers that will be sending COM+ requests to the CLB cluster—must also have Application Center installed. That’s usually not a problem, because your Web servers will usually be the CLB cluster’s clients, and the Web servers will run Application Center for other reasons anyway.

You configure each Web server with the list of servers that belong to the CLB cluster. This list is dynamic, enabling you to easily add or remove servers from the CLB cluster if necessary. You also have to install the COM+ components on the Web servers, so that the servers’ registries contain the correct class information to handle the components. Finally, you use Windows’s Component Services console to mark the appropriate COM+ components as load balanced, which means they’ll send their requests to the CLB cluster. Each Web server contacts each CLB cluster member about once a second, and measures the respond time from each member. When the Web server needs to access a load balanced COM+ component, it simply contacts the CLB cluster that’s at the top of the list.

You may not always want to install Application Center on every COM+ client, though. For example, consider the network shown in Figure 6.4. In this diagram, a number of Web servers act as COM+ clients to a CLB cluster. However, suppose a number of internal desktop computers also need to access the same components. Does that mean you have to install Application Center on each desktop computer? That would be pretty expensive, so it’s fortunate that you don’t have to. Instead, you can create a COM+ routing cluster. This is a special cluster that runs both NLB and CLB (and therefore has the requirements of both, including having two network adapters in each member). The routing cluster accepts COM+ requests from the desktop clients, and then uses CLB to pass the request on to the CLB cluster. In effect, the routing cluster acts as a middleman for COM+ requests. You can even point the Web servers at the routing cluster, if you want to, instead of using CLB on the Web servers. Figure 6.5 shows how the network would look with the routing cluster in place.

Figure 6.4. Having the Web servers and desktop clients use the same components is a great idea, since it reuses valuable programming and reduces code maintenance.

Figure 6.5. Including at least two servers in the routing cluster ensures that a server failure won’t prevent access to the CLB cluster that sits behind the routing cluster.

CLB has a number of requirements and caveats that you need to consider in your design:

In general, you also need to decide when the additional expense of a CLB cluster is necessary. After all, CLB means additional servers, additional Application Center licenses, and an additional level of maintenance and administration to deal with. The only way to make this decision is to decide how many extra users your Web servers could support of they weren’t running COM+ components locally. Often, you’ll find CLB clusters to be cost-effective only when the Web servers are running especially complex, long-running COM+ components. In many cases, it may simply be cheaper to buy additional Web servers to handle the load, rather than implementing an entire CLB cluster infrastructure.

Application Center defines content in terms of applications, where an application is everything—Web pages, registry keys, data source names (DSNs), digital certificates, and so forth—that is required for a Web site to function properly. Deploying is the process of copying an application from one Application Center Web cluster, such as a testing cluster, to another, such as a production Web cluster. Synchronizing is the automatic (or semi-automatic) process of ensuring that every Web cluster member has the same application content.

Deployment is perhaps the easiest to understand, and occurs only on an on-demand basis. So, when you’re ready to deploy a bunch of new Web pages from your testing cluster to your production cluster, you simply command a deployment of the appropriate application from one cluster to the other. Deployment can only occur between Application Center Web clusters, although it’s possible to create a cluster with only one member, which prevents you from having to make a major hardware investment for a development or testing cluster. Deployment always occurs from one cluster’s controller to another cluster’s controller, and never to non-controllers. That’s because synchronization (which I’ll discuss next) is responsible for copying content from a cluster’s controller to all other cluster members. In fact, if you do change the content directly on a cluster member, the cluster controller may overwrite that change at any time with its own, authoritative copy of the application content.

Synchronization can be set up to occur automatically whenever content changes on the cluster controller, or on a scheduled basis. I like to use both methods. Automatic synchronization usually works fine, but if you dump a lot of changes onto the cluster controller at once, the automatic synchronization process sometimes misses a page or two. A scheduled synchronization can be relied upon to catch anything that falls between the cracks, keeping your member servers constantly up to date. Like deployments, synchronization can copy anything that’s included in an application definition, including registry keys, files and folders, and even IIS metabase configuration settings.

Synchronization does not include applications that distribute COM+ components. If you have a new COM+ component to distribute, you’ll have to manually distribute it to each server in the Web cluster.

Another neat thing that synchronization lets you do is add new servers to your Web farm with very little hassle. If your Web farm can no longer handle your current user demand, simply get a new server that has two network adapters. Install Windows and Application Center, and add the server to your Web cluster. Application Center can automatically copy all of the application content from the cluster’s controller to the new server, and then place the new server into the NLB load balancing loop.

Deployment and synchronization are fairly easy to design for. The biggest caveats are that content is deployed and synchronized without encryption of any kind. Web developers sometimes encode database passwords and other sensitive information into Web pages, and Application Center won’t do anything to protect that information. If you’re deploying over a wide-area network (such as from your office to an offsite hosting facility), consider using a virtual private network (VPN) to encrypt the stream of data Application Center sends.

Speaking of over-the-WAN deployments, Application Center doesn’t offer any kind of data compression, either. That means large deployments may take a long time, especially if you have a slow WAN connection. Microsoft includes the Content Deployment Service (CDS) with Application Center, which is meant to address the problem. CDS was originally a part of Site Server 3.0, and Microsoft has made no changes to the version included with Application Center. CDS does do compression for over-the-WAN deployments, but it’s a completely standalone product—there’s no integration with Application Center. CDS doesn’t recognize Application Center clusters, so you’ll have to manually configure the deployment path from one cluster controller to another.

Another design consideration is your content: Application Center is designed to deploy and synchronize entire applications, not pieces of them. Imagine that you’ve set up a development cluster, a testing cluster, and a production cluster. At any given time, your development cluster may have pages in various stages of completion. When you’re ready to deploy, you may want to deploy only a portion of the pages on the cluster to the testing cluster, and then to the production cluster. The way to do that is to configure applications on the development cluster that represent only the bits you want to deploy at that time. Deploy those applications to your testing cluster. There, configure an application that represents the entire functional Web application, and deploy that to your production cluster. Figure 6.6 shows this design technique in action.

Figure 6.6. You can configure applications on an ad-hoc basis on the development cluster, and use a single application definition on the testing and production clusters.

Health Monitor works by collecting performance information from a number of providers. A provider is simply a piece of software capable of delivering performance data. Most of Windows’s various subsystems—processor, memory, disk, and so forth—deliver performance data to Health Monitor through the Windows Management Instrumentation (WMI) provider. Health Monitor includes some additional providers, which allow it to measure things like the response time for a ping command, whether or not a response can be received from a particular URL, and so forth. A single performance item—such as processor utilization—is called a performance counter.

You define monitors, which are collections of specific performance counters, thresholds, and actions. For example, you might configure a monitor that examined processor utilization, with thresholds of 0% to 60% for good, 61% to 75% for warning, and 76% to 100% for critical. For each threshold, you can also configure actions, which are automated responses that occur when a counter enters a threshold. For example, when the monitor enters the critical threshold, you might have an action that sends you an email message or pages you on your mobile phone, so that you can analyze the situation and take action.

Health Monitor also stores performance data in a local database. That local database is self-maintaining, and includes performance data for various periods of time (last 10 minutes, last 24 hours, last week, and so on). Using the Health Monitor console, you can query and consolidate the logged performance data from a number of servers, enabling you to view the health of a single server or your entire Web farm all at once. The logged data is also useful for performance trending, enabling you to determine, for example, when your Web site’s growth will outstrip its capacity, and to do something about it before it becomes a problem.

In order for Health Monitor’s local performance logging to work, each server must run the Microsoft Data Engine (MSDE), which Health Monitor will install by default. The MSDE is basically a junior version of Microsoft SQL Server 2000. Because SQL Server 2000 is designed to run multiple copies of itself on a single computer, the MSDE installed by Health Monitor will not conflict with any version of SQL Server 2000 that you’ve already installed (although you should reinstall the latest SQL Server service pack after installing Application Center). Health Monitor preloads the MSDE database with stored procedures and SQL Server Agent jobs that keep the database self-maintaining, so you should never have to deal with it. If you’re really concerned about performance, you can deselect the MSDE installation option. I don’t recommend doing so, because the performance hit of the MSDE is barely measurable, and it provides you with a wealth of invaluable performance trending information.

Health Monitor is a convenient addition to Application Center that does give you centralized monitoring of multiple servers—the sort of “many servers as easy as one” philosophy that is the whole point of Application Center. However, if you’re after enterprise-class, all-in-one monitoring, then you want Microsoft Operations Manager (MOM). MOM features most of the same features as Application Center, only on a larger scale. Experts replace monitors, and provide preconfigured thresholds and other features.

Perhaps the most important design consideration for Health Monitor is network bandwidth. If you want to gather consolidated information from a dozen Web servers, and they’re located on the other side of a WAN link from your workstation, then you’ll need to be prepared to wait a while for the information to come over. The best solution to this problem is to keep the data on one side of the WAN link. One way to do that is to run the Health Monitor console on one of your Web servers, or on another computer that’s on the same local network as your Web servers. You can use Terminal Services in Remote Admin mode to control remote servers as easily as if you were standing right in front of them.