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.
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).