Load Balancing | Microsoft Application Center 2000 Resource Kit 2001

Application Center provides several alternatives for implementing load balancing on a cluster. (See "Cluster Type" in "Table 2.2, New Cluster Wizard Pages.") In addition to the controller configuration, the type of application that will be hosted on the cluster will determine which of the following load balancing options you should select:

Integrated NLB
CLB
No load balancing

For detailed information about this feature, see Chapter 5, "Load Balancing."

Let's start by examining integrated NLB.

Integrated NLB

With this option, load balancing is actually carried out by the NLB that's part of Microsoft Windows 2000 Advanced Server. Application Center only provides an interface that's integrated with NLB.

NOTE
NLB is a distributed IP-level load-balancing solution that works by having cluster members see the packets sent to the virtual IP (VIP) addresses associated with a cluster. Which member actually processes a particular packet depends on the load-balancing rules that are in effect.

The Application Center user interface serves to make load balancing configuration for a cluster easier by removing much of the configuration detail and, through the use of a wizard, by reducing the number of user decision points. The wizard also conducts hardware and software diagnostics to ensure that a minimal workable platform is available to support load balancing (for example, it checks for the correct number of network adapters and IP addresses).

The main element of the NLB configuration for your cluster is selecting an appropriate load-balancing algorithm for the cluster. This algorithm, or affinity, is based on the source of the bulk of the incoming client requests. Application Center integrated NLB uses three types of affinity (described in Table 2.5) settings to identify the algorithm that will be used.

Table 2.5 Load Balancing Affinity Settings

Affinity	Description
None	Multiple requests from the same client can access any cluster member. The IP address and port number identifies the client.
Single	Multiple requests from the same client must access the same cluster member. This is the default setting for intranet clients. The IP address identifies the client.
Class C	Multiple requests from the same TCP/IP Class C address range must access the same cluster member. This is the default setting for Internet clients because it provides optimum support for "sticky sessions".¹

^{1. "Sticky sessions" are sessions in which a client request establishes a server-side state that is used in subsequent requests during the same session. Sticky sessions, or session coherency, are covered in detail in Chapter 5, "Load Balancing."}

After you've created a cluster, you can use the MMC console to change the affinity setting for a cluster that's using integrated NLB.

Another load balancing configuration option that's provided by Application Center is the ability to adjust individual server weights in response to performance data or to accommodate different classes of members. You can do this by opening a dialog box, shown in Figure 2.4, from the pop-up menu for a cluster member.

Figure 2.4 Dialog box for adjusting server load balancing

Finally, you can take any server offline. The Set Offline option removes a server from the load-balancing loop. This is usually done in situations where you've deployed a new application and you want to test it before adding it to the cluster. After testing is finished you can push the content to the controller for replication, and then put the server back online. The Set Offline option is also used for a removing server that is experiencing problems.

Component Load Balancing

CLB is an Application Center service. The decision to use CLB should be based on a thorough analysis of your application requirements before hosting components on back-end servers. There is an inherent system overhead associated with client requests that traverse the network as well as in the process of selecting a server to satisfy the client request. Some scenarios where CLB should be considered are as follows:

Security is a major concern and you want to segregate COM objects behind an additional firewall.
COM objects are relatively "heavy weight" and the fastest server has to be found on which to run them.
Applications are partitioned into n-tiers, either for development or design reasons.

INFORMATION
If you're using NLB for your front-end servers and want to route component requests to a back-end COM+ server, the Application Center user interface easily lets you specify a target.

Scaling is important—a single cluster can use multiple COM+ clusters to service component requests.

NOTE
For applications that use a limited number of, or "light weight," components, instantiating COM objects locally on a front-end Web server may provide the best performance.

No Load Balancing

There may be situations in which you do not need, or do not want to have, load balancing enabled; for example, it is not necessary for application testing and staging or controller redundancy.

Application Testing and Staging

You can create a cluster for testing and staging that consists of a single server or a small number of members. In this scenario, load balancing isn't really necessary.

Controller Redundancy

In environments where a cluster is quite small, say two or three servers, you may want to have a completely redundant member on standby to serve as a backup controller. You would keep its content synchronized to the active controller, but you wouldn't have it responding to client requests.