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.
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.
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 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 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.
CLB has two major parts:
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.
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.
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.
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.
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.
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.
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:
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.
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.
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
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. |
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:
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:
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.
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
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.