Network Load Balancing Administration | Microsoft Application Center 2000 Resource Kit 2001

The Application Center user interface enables you to work with the various aspects of load balancing on a cluster through properties dialog boxes at the cluster and member nodes level.

Setting a Server Offline or Online

Right-clicking an individual member node exposes the pop-up menu to take a member out of the load-balancing loop (Set Offline). If you haven't already drained the member's connections, you'll be prompted by the dialog box shown in Figure 5.4 earlier in this chapter. As previously noted, you can accept the default draining period of 20 minutes, enter your own one-off draining period, or take the member out of the load-balancing loop immediately. Unless you're working in a test environment, you should allow the member to drain its connections. This enables a cleaner NLB convergence by reducing the risk of disrupted user sessions.

NOTE
Even if the member being drained has no more connections coming in from NLB, the member is drained for the full draining period to ensure that any potential requests that are forwarded from other cluster members are handled.

Adding a member to the load-balancing loop is done in the same way as taking a member out of the loop. The only difference is that a draining period isn't required. After NLB receives a heartbeat message from the new member, convergence is initiated and a new load balancing membership list is calculated along with revised load distribution.

Configuring Load Balancing Weights

There are several scenarios where you might want to adjust the relative amount of traffic that an individual member handles:

You need to compensate for hardware-based performance differences. (This is the most common scenario.)
You have a cluster in which updates to the Web server occur frequently and a large volume of data is replicated throughout the day. In this instance, it would make sense to have the controller respond to fewer client requests and dedicate more resources to cluster synchronization. Alternatively, you could set the controller offline for load balancing during this replication period.
You have a cluster member that's also handling FTP and e-mail traffic. Once again, you can free up resources on this member by reducing the relative amount of HTTP requests to which it responds.

Regardless of the client affinity that's assigned to the cluster, you can adjust load-balancing weights on a per-server basis by using the membername Properties dialog box shown in Figure 5.9.

As you can see in Figure 5.9, a member's load balancing weight is adjusted by using a slider that operates on a scale from 1 through 20. By default, Application Center sets every member's weight at the mid-point in this scale when you create a cluster and add members.

NOTE
When you adjust the load balancing weight on a single member, the load mapping for the entire cluster is recalculated.

The weight scale's range does not represent a percentage of the client traffic distribution. In order to determine what percentage of the traffic every member receives, you have to do the following calculation:

Add up the total of the server weights for the cluster
Calculate each member's server weight as a percentage of the total weight for the cluster

Figure 5.9 ACDW518AS Properties dialog box for adjusting server weight

Table 5.6 shows how server weights can be expressed as a percentage of the cluster traffic in a cluster of five members.

NOTE
For this example, we arbitrarily decided that the weights represented in the scale ran from 1 through 100, and that the average load would have a value of 50.

Table 5.6 Sample Server Weight Calculation

Member	Weight	Total weight for cluster	Percentage of traffic
A	50	250	20
B	75	250	30
C	45	250	18
D	30	250	12
E	50	250	20

As the example in Table 5.6 illustrates, it takes a fairly significant difference in server weights to create a large difference in the percentage of the cluster traffic that each member receives; for example, the difference in weight between members A and B is 25, yet the traffic percentage difference is only 10. However, this weight-to-percentage ratio changes according to the size of the cluster. Let's assume that you have a cluster that consists of 10 members and that the total cluster weight is 500. In this scenario, members A and B have the same weights as in the five-member cluster. The new percentage of the load handled by each member is 10 and 15 percent, respectively. The gap between the two is reduced to 5 percent from 10 percent.

TIP
If you want to set load balancing weights on a per-member basis, you should do a similar calculation before establishing new load weights. This will enable you to get a better picture of the impact of these changes on load distribution across the cluster. Chapter 10, "Working with Performance Counters," provides an example of load-balancing weight adjustment on a cluster that has load applied to it (by using the Web Application Stress tool).

NOTE
You can also manually configure load-balancing weight for a member on a port rule basis.

Configuring Client Affinity

You can change a cluster's client affinity by opening the clustername Properties dialog box from the clustername node in the Application Center snap-in. By using the provided drop-down list, you can change the default affinity setting from Single to None or Class C.

TIP
If you decide that it's necessary to change a cluster's load-balancing algorithm by changing client affinity, you should consider doing this during a period when cluster traffic is at a minimum. Even with NLB's effectiveness, convergence can have an impact on your clients' connections. Remapping the cluster during off hours will help reduce the risk of having a negative impact on client sessions.

Configuring Request Forwarding

You can configure request forwarding, or state (a process described in detail in "Maintaining Session State with Network Load Balancing" earlier in this chapter), via the Request Forwarder tab on the RKWebCluster Properties dialog box, shown in Figure 5.10.

Figure 5.10 Request Forwarding tab on the RKWebCluster Properties dialog box, which is used for configuring request forwarding on a cluster

Let's examine the different elements of the advanced load balancing options configuration in more detail.

Your configuration options for advanced load balancing are as follows:

Enable Web request forwarding—Clearing this check box disables request forwarding for dynamic HTTP requests. In the request forwarding logic framework illustrated in Figure 5.6, this means that "Always Add Cookies" evaluates to false and "Ignore ASP Session States" evaluates to true. As a result, HTTP language-based administration (HTMLA), FrontPage, and DAV publishing requests could still be forwarded and Application Center Administration requests are forwarded.
Enable for Web sites using ASP session state only—When this option is clicked, forwarding is enabled for all sites that have the ASP Allow Session State Enabled property set to true. This is an inheritable property, which is true (the default) for all virtual directories when IIS is installed. This means that all sites have ASP session coherency enabled by default in the IIS space.
Enable for all Web sites—Clicking this option means that forwarding cookies will always be added to a client request. In terms of the process flow chart, "Always Add Cookies" evaluates to true.
Forward Distributed Authoring and Versioning (DAV) requests and Forward FrontPage publishing requests—These options enable you to specify the type of tool that you're using to publish content. If either of these check boxes are selected, these requests are automatically forwarded to the controller.

NOTE
The MD_RF_FORWARDING_ENABLED_FOR_VDIR property allows you to specify whether or not a virtual directory has forwarding disabled, or if the virtual directory requires all requests to be forwarded to the controller. If this property is set to 0 or 1, it enables or disables forwarding for the Vdir. If the property is set to 2, the request will be always forwarded to the controller.