Lesson 3: Designing CLB Clusters

CLB allows COM+ components to be load balanced. COM+ components are compiled software objects that are usable from a variety of different languages including VBScript (VBS), ASP, Visual Basic, and C++. They provide a useful way of bundling software into convenient and reusable entities. In CLB, the COM+ components are located on servers in a separate COM+ application cluster. Calls to activate COM+ components are load balanced to different servers within the COM+ cluster. The decision-making elements of the CLB software run on the Web tier, although some information-gathering CLB software does run on the COM+ cluster. In this lesson you’ll learn how CLB works and how you can implement it in your network environment.

After this lesson, you will be able to

• Describe CLB and how it’s integrated into Application Center clusters
• Design multitiered clusters that allow you to load balance your COM+ applications

Estimated lesson time: 30 minutes

CLB

CLB is an Application Center feature that provides dynamic load balancing for COM+ application components. In order to enable CLB, an Application Center COM+ application cluster must activate components when requests are received from either a General/Web cluster, COM+ routing cluster, or clients running the Win32 API. Functionally, an Application Center Web cluster and COM+ routing cluster are the same; both support CLB and can route requests to a COM+ application cluster.

Only COM+ object activation is load balanced by CLB. Queued components can’t be load balanced.

COM

At the root of CLB is the component architecture that comprises the Component Object Model (COM). When object-based software is written to this standard, it provides a generic mechanism by which software services can be made available. It allows software to be written in varying languages and operating systems. Key to this flexibility is the COM interface.

A COM component exposes functionality through one or more interfaces. To use a COM component, client software has to be written in a language that can communicate with the interface. Languages such as Visual Basic, ASP, VBS, JavaScript, and Visual C++ can all do this. The interface itself is simply a table of numbers that hold the address of the methods supported by the interface, as shown in Figure 6.8.

Figure 6.8 - Interfaces on a COM component

COM components are typically housed within dynamic-link libraries (DLLs) or executable (.exe) files. They can be installed on the client or located on a remote computer. When used remotely, the call is made through a mechanism called Distributed COM (DCOM) that’s based upon Remote Procedure Calls (RPCs).

COM+ Services

COM+ Services is supplied as part of the Windows 2000 operating system and provides a suite of services based on COM and MTS. COM+ Services provides enterprise functionality such as transaction support, object lifetime services, security services, events, and queued components.

COM+ Components

COM+ components are COM components that can take advantage of COM+ Services. One of the requirements for a COM+ component is that it carry configuration information, which is a set of attributes that allows the underlying COM architecture to discover whether a particular COM+ Service is supported— for example, transaction support or load balancing.

COM+ components are grouped together into packages known as applications, which aren’t the same as Application Center applications. A COM+ application is a grouping of COM+ components, whereas an Application Center application is a list of resources that are used in a business solution.

How CLB Works

CLB has two major parts:

• CLB software Used to load balance a COM+ cluster
• COM+ application cluster An Application Center cluster that activates and runs COM+ components

CLB Software

The CLB software is responsible for determining the order in which COM+ cluster members are used for activating COM+ components.

The business logic that creates the COM+ component runs on the Web-tier cluster. This will typically be a Visual Basic ASP script that calls CreateObject when a COM+ component is required. (Internally this translates to a call to CoCreateInstance.) With CLB, instead of creating the component on the local server, a routing list and server response timetable is used to help pass the COM+ component activation request through to a load-balanced COM+ cluster. A COM+ cluster member then creates the component and returns an interface to the client. CLB has no further active involvement with the component once it’s been created.

Routing List

The routing list exists on each member of the Web-tier cluster and contains a list of the COM+ cluster members to be load balanced, as shown in Figure 6.9. The routing list can also exist on the COM+ routing cluster, which is used solely for routing purposes and has no Web-tier functionality.

Figure 6.9 - Routing lists and response times

The routing list is initially created by the administrator on the Web-tier cluster controller and then automatically synchronized to each cluster member. It’s therefore impossible to have cluster members with routing lists containing different COM+ cluster members. One big advantage of having the routing list on each Web-tier cluster member is that there’s no single point of failure. If a given Web-tier cluster member stops—by design or not—other members will continue to load balance the COM+ cluster through their own routing lists.

Response Timetable

Every 200 milliseconds, the CLB software running on each host in the Web-tier cluster polls each member on its routing list. From the polling responses, it builds an in-memory table listing the COM+ cluster members ranked by response time. The faster the member’s response, the higher its position in the table. The Web-tier member uses the response timetable in a round-robin manner to pass incoming activation requests to the COM+ cluster members. As activation requests are received, the fastest, least busy COM+ cluster member is used first, followed by the next (slower) member for subsequent requests. Once the table has been exhausted, the next request is routed through the first table entry. Further activations proceed through the table as before. This continues until the next scheduled response time update occurs, and activation is reset to the beginning of the freshly load-balanced table.

Each Web-tier cluster member maintains a COM+ cluster member response timetable. No attempt is made to synchronize these values across the Web-tier cluster as the list wouldn’t be replicated fast enough to keep up with changing COM+ cluster load.

COM+ Application Cluster

As with the Web-tier cluster, the administrator creates the COM+ cluster with the New Cluster Wizard in Application Center. Each member of the cluster has to have the same copy of the COM+ component installed. A deployment wizard is available for installing the components. Once it’s created, the component needs to be aware of its existence within a CLB cluster.

Cluster-Aware COM+ Components

To use CLB, COM+ components must be written to be cluster-aware. In COM+, components shouldn’t retain per-component state information because this adversely affects scalability and transaction management. Components can’t be recycled unless they’re stateless; per-component state information can’t cross transaction boundaries. Component state needs to be stored either in persistent state, such as a database management system, where it can be accessed from any cluster member, or it should be stored with the client, such as cookie information stored on an Internet client’s computer.

When to Use CLB

Although CLB is a very effective tool for building distributed solutions, sometimes it might not be the best solution. The key issues are performance, manageability, and security. Understanding these issues will help you build better cluster topologies.

Performance

However attractive or functional a Web site is, it won’t succeed if users don’t get satisfactory performance from it. Two issues are important to an effective Web site:

• Throughput The work done by Web site
• Response time The time taken to give feedback to a user

CLB can have an impact on both throughput and response time.

Throughput Throughput performance declines when an application or service makes a call across a network. Using CLB will obviously affect throughput performance, which you need to account for in making cluster architecture decisions. Table 6.5 shows the number of calls per second on a single threaded Visual Basic COM component that returns "Hello, world" as string property. The client is early bound and doesn’t release references between calls to retrieve the property.

Table 6.5 COM Component Throughput

Scenario	Calls per Second	Relative Speed
COM+ server application, run over a 10Base-T network	625	1.0x
COM+ server application, Out Proc, same box	1,923	3.08x
COM+ library application, In Proc, same box	3,333	5.33x

It’s clear that calls over the network yield slower throughput than calls to software installed on the same computer. This is true in all software communication, whether it’s through Microsoft software or something else. For this reason, CLB isn’t an effective solution where throughput is absolutely critical. In this case it’s better to install the COM+ components locally on the Web-tier cluster members (as shown in Figure 6.10), thus avoiding cross-network calls. CLB support is lost, but load balancing is still available through NLB.

Figure 6.10 - COM+ components on the Web tier

Response Time Ensuring that users have a fast response to Web site visits is obviously very important, and Web site architecture greatly affects this. COM+ components running on the Web-tier cluster may perform work that perceptively degrades the Web site’s response. If response time for non-COM+ component work is more important than component throughput, one solution is to move the COM+ components to a COM+ cluster tier, as shown in Figure 6.11.

Figure 6.11 - Two-tier cluster model with NLB and COM+ application clusters

Having a separate tier for COM+ applications lightens the workload for the Web-tier cluster because service time for clients not using COM+ components is improved—for example, clients accessing static Web pages. Obviously, when COM+ component work is required, you won’t see response time improvement. In fact, performance will probably degrade since cross-network calls will be taking place.

Another option for implementing CLB is to move the routing lists onto a separate COM+ routing cluster, as shown in Figure 6.12. This configuration makes the workload for the Web-tier even lighter because no CLB-specific work takes place on it.

Figure 6.12 - A three-tier cluster with load balancing across all tiers

This configuration is good for non-COM+ component work on the Web tier, but it introduces even more performance degradation for COM+ components as a result of cross-network calls. However, one advantage of having a third tier is that the middle routing cluster can handle Win32 client requests as well as front-end Web requests.

Manageability

Using a separate COM+ cluster helps improve manageability. It allows the differing needs of a Web site’s COM+ components and IP requests to be easily and separately managed. For example, many organizations house their COM+ components on servers in different physical locations. Using a separate COM+ cluster allows independent management of the cluster. It’s also possible to have a COM+ cluster that’s shared across multiple Web-tier clusters or vice versa.

Security

A common use for CLB is to enhance Web site security. When used as the means to access data, COM+ components can use their role-based, or programmatic, security mechanisms to safeguard data. This potentially could be compromised if the components are placed on the Web-tier cluster. Calls received by the Web-tier cluster may come from an untrustworthy client looking to take illegal advantage of the COM+ components installed on the cluster member. CLB allows you to avoid this problem by moving the COM+ components off the Web-tier cluster onto a COM+ cluster. The COM+ cluster is often protected by a firewall (Fire-wall B in Figure 6.13), and it allows components to be created only from calls that have originated within the Web-tier cluster and not from the client. Figure 6.13 also shows a perimeter network protecting the Web tier through two encompassing firewalls.

Figure 6.13 - COM+ cluster behind a firewall

Making a Decision

When deciding whether to implement a COM+ application cluster, you should take into account performance, manageability, and security. Table 6.6 lists the factors that you should consider when making a decision.

Table 6.6 Implementing a COM+ Application Cluster

Consideration	Factors
Performance	You should consider throughput and response time when determining whether to use CLB. Throughput can decline when calls must be made over a network, although response time can sometimes be improved.
Manageability	Using a separate tier for a COM+ application cluster provides for independent management of COM+ applications. You can manage components and IP requests easily and separately.
Security	You can enhance security through the use of a separate tier for a COM+ application cluster. Security can sometimes be compromised when COM+ components are placed on the Web-tier cluster.

Recommendations

Although Application Center supports multi-tier scenarios, you shouldn’t implement these scenarios simply as de facto models for distributing application components. There are good reasons for distributing applications across tiers as well as for keeping everything on a single tier. You have to analyze your technical and business requirements fully before making this decision. This question has no single correct answer.

The main reasons for setting up separate Web and COM+ application server tiers include the following:

• Security You can place an additional layer of firewalls between one tier and the other.
• Administrative partitioning Different groups of developers and administrators are responsible for the HTML/ASP and COM+ applications. Putting the two groups on different tiers prevents problems between the groups.
• Cluster sharing Sharing a single COM+ application cluster among multiple Web clusters can better utilize resources.
• Increasing response time In some scenarios (for example, a low-throughput environment where each request is very expensive), sending multiple costly COM+ requests from a single Web request to a COM+ application cluster will increase response time—but not throughput.

In a high-throughput environment, this benefit is muted, because load will be balanced evenly around the cluster whether or not it’s multitiered.

The main reasons for choosing not to set up separate Web and COM+ application server tiers include the following:

• Performance Remote access is more expensive than running locally, and overall performance degrades if you split a single front-end cluster into two clusters without adding more hardware.
• Administrative complexity Managing two clusters is more complex than managing one.
• Difficulty making full use of the hardware You must carefully balance hardware between the Web cluster and COM+ application cluster. Adding capacity becomes more complex, and it’s likely that one tier or the other will end up with less capacity. This causes a bottleneck that requires more hardware to maintain optimal headroom; in addition, more monitoring is necessary to balance hardware utilization.
• Dependency maintenance Whenever you add a member to the COM+ application cluster, you must update the cluster on the front end with the new membership list of the back-end component members.

You also can use a COM+ routing cluster, but this has its own set of problems and you have an additional tier to manage, with its inherent monitoring and throughput problems.

It’s clear that high performance and CLB don’t necessarily go hand-in-hand and that it’s critical that Web site designers be aware of these limitations. CLB is a great tool for building distributed solutions; however, you must be careful using it. Although using it will adversely affect throughput performance, other advantages, such as security, manageability, ease of setup, and load balancing, make it a valuable tool.

Example: A CLB Cluster for Consolidated Messenger

The Consolidated Messenger company is implementing a multitiered network to support their Web site. The Web portion of the network will include three tiers. The front-end tier will contain an NLB cluster. Each computer in the cluster will support Web services. The middle tier will contain a COM+ application cluster. The Web cluster and COM+ application cluster each will include three Windows 2000 Advanced Server computers. CLB will run on the Web cluster to support the COM+ application cluster. The network will also include a back-end tier that will contain a data cluster. The data cluster will contain two Windows 2000 Advanced Server computers, and the Microsoft Windows Cluster service will be used to provide highly available data services.

Figure 6.14 shows the topology of the Web portion (perimeter network) of Consolidated Messenger’s network. Notice how COM+ applications are separated out from the Web tier.

Figure 6.14 - A multitiered network environment that uses NLB, CLB, and the Cluster service

Lesson Summary

CLB provides dynamic load balancing for COM+ application components. At the root of CLB is the component architecture that comprises the Component Object Model. CLB has two major parts: CLB software, which is used to load balance a COM+ cluster, and the COM+ cluster, an Application Center cluster that activates and runs COM+ components. A routing list exists on each member of the Web-tier cluster and contains a list of the COM+ cluster members to be load balanced. Each Web-tier cluster member maintains a COM+ cluster member response timetable. As with the Web-tier cluster, the administrator creates the COM+ cluster with the New Cluster Wizard in Application Center. When deciding whether to use CLB, you must take into consideration performance, manageability, and security. High performance and CLB don’t necessarily go hand-in-hand. Although using CLB will adversely affect throughput performance, other advantages, such as security, manageability, and ease of setup, might offset the effects on throughput.