In-Depth

Balancing Act

Component Load Balancing, a feature of Application Center 2000 that works in the middle tier, can help your Web and other applications scale out in a new way.

• By Don Jones
• July 01, 2002

Microsoft Application Center 2000’s best-known feature is Network Load Balancing (NLB), which is also included with Windows 2000 Advanced Server (for more on NLB, see “Share the Load,” in the January 2002 issue). An equally important (although less well-known) feature is COM+ Load Balancing (CLB). Where NLB is designed to load balance client requests across front-end machines like Web servers, CLB is designed to provide that same capability for the middle tier of multi-tier applications. Sounds like a software developer’s problem, right? Wrong! While developers are certainly responsible for creating middle-tier components, configuring and maintaining CLB sits firmly in the administrator’s realm.

What’s a Middle Tier?
You’re probably familiar with client-server applications: A client application, often written in a language like Visual Basic, works with data that’s stored on a database server (such as Microsoft SQL Server or Oracle). Those applications are also referred to as two-tier applications. The client is usually responsible for doing most of the work, such as validating the data a user types in. In a multi-tier application, there’s a third layer between the client and database server. That third, middle tier handles the application’s business logic, such as validating business data. The client application can then be less complex, as the middle tier performs so much work. Because the middle tier includes the application’s real logic, it also allows developers to more easily change the way an application works: They simply change the middle tier. There’s no need to rewrite and re-deploy a complex client application to every desktop in the organization, as is the case in two-tier applications. Figure 1 illustrates the difference between a two-tier and three-tier application.

Figure 1. Two-tier vs. three-tier applications.

What’s a Component?
The middle tier of a three-tier application usually consists of dedicated servers running special applications called components. Components work just like any other application, but don’t include a user interface. Instead, they’re designed to provide a link between a client application and a server application, passing and validating data between the two. Programmers write components using a standard called COM+ Services, an extension of Microsoft’s original Component Object Model (COM). Believe it or not, you use components every day. Various COM+ objects provide the core functionality of products such as Microsoft Word, Internet Explorer and the Microsoft Management Console.

When you perform a spell check in Word, for example, Word fires up a COM+ object that performs the actual spell check. Excel, PowerPoint, Visio and a host of other applications use the same COM+ object, which allows them to share a common dictionary and spell check user interface (it saves a lot of disk space, too, as you only need one spell checker on your system for all those applications).

But COM+ isn’t limited to using the objects installed on the local computer. In fact, one of the coolest things COM+ can do is run objects on remote computers. Imagine, if you will, a super-powerful, dedicated server that hosts a spell check COM+ object. Anytime someone in your company needs a spell check, their computers use COM+ to execute the spell check object on the remote server. Every user in your company could share a common spell check dictionary and, most importantly, their desktop computers wouldn’t have to do the work of the spell check—the spell check server would do it for them.

Overloading the Middle Tier
Of course, if every person in your company performed a spell check at the same time, that poor spell check server would probably fall to its knees. What you really need is several spell check servers, with some way to evenly distribute user spell check requests across the group. That’s what CLB is all about.

OK, a spell check server probably isn’t at the top of your list for network improvements. But multi-tier applications (that’s any application with more than two tiers) rely heavily on the services provided by middle-tier servers, and it’s easy for those servers to become overburdened. CLB provides an answer by allowing you to create CLB clusters, which are groups of servers capable of running the exact same COM+ components. CLB distributes incoming requests evenly across the members of the cluster. If one cluster member crashes, CLB takes it out of the loop, redistributing incoming requests across the surviving members. In fact, from a functional point of view, CLB works a lot like its cousin, NLB. From an implementation viewpoint, though, CLB is a bit different.

Creating a CLB Cluster
First, remember that CLB is only available with Application Center 2000. That doesn’t mean you can only use it for Web sites, but it does mean you have to shell out for Application Center if you want to use CLB. You must install Application Center on the CLB cluster members, as well as the clients that’ll use the CLB cluster. The CLB software on each client computer works completely independently. First, you configure CLB with a routing list, which is simply a list of all the members of the CLB cluster. From then on, the CLB software continuously polls those servers, measuring their response time. The server with the fastest response time (theoretically the least busy server, because it responded so fast) is picked to receive the next COM+ request the client needs to send out. Figure 2 shows the CLB software configuration tab on a client computer that has Application Center 2000 installed.

Figure 2. Configuring the CLB routing list.

CLB is most useful in an application with four or more tiers, such as a typical Web application. Figure 3 shows the architecture of a Web application, including the first tier (the Web browser), the second tier (Web servers in an NLB cluster), the third tier (COM+ servers in a CLB cluster), and the fourth tier (a SQL Server computer). Incoming first-tier requests are load- balanced across the second tier, and the second tier’s COM+ requests are load-balanced across the third tier.

Figure 3. A four-tier Web application.

CLB for Legacy Applications
You can still make good use of CLB, even if you’re not building a Web application architecture. For example, in traditional three-tier applications, clients talk directly to the middle tier. You don’t want to have to buy Application Center licenses for every desktop in your organization, but that’s what you’d have to do to use CLB, right? Nope! You can use Application Center to create a special COM+ routing cluster. That cluster’s whole job is to accept incoming requests from non-Application Center clients and then pass those requests on to a CLB cluster. Figure 4 shows how it works: Clients send their requests to a virtual IP address shared by all members of the routing cluster, which usually includes two servers (This is for redundancy; you could use just one if you wanted to). Each routing cluster server includes two NICs. One NIC communicates with client computers and uses Application Center’s NLB software to load balance incoming requests across the routing cluster members. The second NIC communicates with the CLB cluster members and uses CLB to load balance outgoing requests across the available CLB cluster members. Your desktop computers won’t need the CLB software at all, because they’re just sending COM+ requests to a plain, old IP address. The routing cluster picks up those requests and uses CLB to perform the load balancing.

Figure 4. Figure 4. Using a COM+ routing cluster.

The only downside to the whole routing cluster scheme is that it only works with TCP/IP (remember, Application Center was designed mainly for Web-based solutions, so it only works with TCP/IP). If your network isn’t using TCP/IP (which is still possible, even these days), then routing clusters, CLB and everything else in Application Center is useless to you.

Why Bother?
As corporate applications become more complex, developers are trying to find more ways to spread the workload over a number of computers, a technique called distributed processing. As client applications became too complex, developers pulled some of the applications’ tasks into middle-tier components. When middle-tier servers couldn’t handle the workload generated by their clients, developers got stuck because it wasn’t easy to just throw another middle-tier server into the mix. CLB provides the perfect solution: When the middle tier can’t keep up, just add another server to the CLB cluster. CLB makes the middle tier more scalable, which means it can be easily expanded to meet growing needs.

Where Do Developers Fit in?
Developers still have a place in all of this component stuff, of course. Client applications have to be written to take advantage of remote COM+ components, or they’ll try and use locally installed components. The COM+ components themselves require special designs, as no client requests can be guaranteed to “hit” a specific CLB cluster member. In other words, components can’t try to “remember” anything about the client, because the client’s next request might be sent to a different cluster member, which wouldn’t contain the “remembered” information. Instead, components must store information in the database server, which is equally accessible to all CLB cluster members.

Finally, someone—you or a developer—has to flag the components to be run on a CLB cluster. That step is performed in the Component Services console on each client computer (in the Administrative Tools folder on the Start menu). Select the appropriate check box and the CLB software kicks in the next time that component’s used. Remember, this has to be done on every computer that will pass off COM+ requests directly to a CLB cluster, including the members of a COM+ routing cluster.

Occasional Administration
Fortunately, for us busy administrators, CLB is one of those things that basically works fine once you set it up. The big hassle comes when you need to permanently remove a server from a CLB cluster or (more likely) when you need to add a new server to handle increased demands on the cluster.

With NLB, adding and removing a server is easy: You just modify the cluster configuration on the cluster controller and you’re done. With CLB, the clients of the cluster maintain a list of members in the cluster, so it’s the clients you’ll have to reconfigure. In many cases, your CLB clients will be Web servers, which will also be part of an Application Center NLB cluster. That means you just have to reconfigure the CLB routing list on the NLB cluster controller, and your changes will automatically propagate to the other members of that cluster.

If you’re using CLB in a non-Web application, though, your CLB clients might not be using Application Center’s other features. In that case, you’ll have to manually reconfigure the CLB routing list on each client. The good news is that, in most cases, non-Web applications will make use of CLB through a COM+ routing cluster; routing clusters work just like Web server clusters, meaning you’ll only have to change the CLB routing list on the routing cluster’s controller.

A Great Solution
Application Center’s CLB software provides a great solution for application scalability. CLB, which provides scalability for an application’s middle tier, complements NLB, which provides scalability for the applications’ front-end tier (generally Web servers). Through the clever use of COM+ routing clusters, you can even use CLB to provide better scalability for non-Web, multi-tier applications, making it appropriate in almost any environment. If there’s any disadvantage to CLB, it’s that you can only find it in Application Center (unlike NLB, which is also available in Win2K Advanced Server).