Load Balancing COM+ Components

  • Article
On This Page

Introduction
Introducing COM+ Components
Application Center and Load Balancing
IP Load Balancing
Component Load Balancing
Cluster-aware COM+ Components
Deploying COM+ Components
Secure COM+ Components
Cross Network Performance
Load Balancing Topologies
Conclusion
Appendix 1 – Setting Up Topologies
Component Load Balancing in Action
Resources

Introduction

Microsoft® Application Center 2000 (Application Center) is part of the Microsoft .NET Enterprise Servers offering that comprise the Microsoft .NET initiative. Some of the other .NET Enterprise Servers offering include Microsoft Commerce Server 2000 (Commerce Server), Microsoft BizTalk™ Server 2000 (BizTalk Server), and Microsoft SQL Server™ 2000 (SQL Server). For more information on the Microsoft .NET initiative, see https://www.microsoft.com/net/.

The role of Application Center within .NET Enterprise Servers is to provide content deployment and management facilities for Web sites built on the Microsoft Windows® 2000 operating system and Microsoft Internet Information Services 5.0 (IIS). Application Center makes scalable, robust, easy-to-administer, and secure Web sites. The central theme is a cluster of Web servers that appear as a single Web site to the client. Coupled with this is the idea of a single application image that is replicated to all cluster members. The application image consists of all the parts needed for a business solution. This includes Web sites, registry settings, files, COM+ components, and so on. You can monitor cluster health easily by using events, performance counters, and monitors that reflect the current cluster state.

Figure 1: Typical Application Center Topology

Figure 1: Typical ApplicationCenter Topology

A key aspect of Application Center is the ability to scale and manage reusable software entities called COM+ components. This white paper discusses load balancing COM+ components via network load balancing (NLB) and component load balancing (CLB) as a means to provide scaleable, secure, high-performance and robust clusters. It describes a number of possible topologies, provides setup hints, and compares the advantages and disadvantages of NLB and CLB.

Introducing COM+ Components

COM+ components are compiled software objects that are usable from a variety of different languages including VBS, ASP, Visual Basic, and C++. They provide a useful way of bundling software into convenient and reusable entities. Historically, COM+ components evolved from Component Object Model (COM) components, which is an earlier object technology developed by Microsoft. COM+ builds on the COM object technology to provide a service-based solution for enterprise-quality applications.

Component Object Model

At the root of COM and COM+ is the component architecture that comprises the COM object technology. When you write object-based software to this standard, it provides a generic mechanism by which software services are made available. It allows you to write software in varying languages and operating systems. The key to this flexibility is the COM interface.

A COM/COM+ component exposes functionality through one or more interfaces. To use a COM/COM+ component, the language that you use to write your client software must know how to deal with a COM interface. Languages such as Microsoft Visual Basic® (Visual Basic), Active Server Pages (ASP), Visual Basic Scripting Edition (VBScript), JavaScript, and Microsoft Visual C++® (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.

Figure 2: Interfaces on a COM Component

Figure 2: Interfaces on a COM Component

Typically, COM/COM+ components are housed within dynamic-link libraries (DLL) or executables (.exe) files. You can install them on the client or a remote computer. When used remotely, the call is made by a mechanism called Distributed COM (DCOM) that is based upon Remote Procedure Calls (RPC).

COM+ Services and COM+ Components

COM+ Services is supplied as part of the Windows 2000 operating system and provides a suite of services based on COM and Microsoft Transaction Server (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 carries configuration information. This is a set of attributes that allow the underlying COM architecture to determine if a particular COM+ Service is supported (for example, transaction support or, as discussed later in this white paper, load balancing).

COM+ components are grouped into packages known as applications, which are not the same as Application Center applications:

  • A COM+ application is a grouping of COM+ components.

  • An Application Center application is a list of resources that are used in a business solution. Examples of these are Web sites, files, COM+ components, and registry keys, among others.

Calling COM and COM+ Components Remotely

COM and COM+ components use DCOM, which is based on RPC, to provide distributed calling of COM/COM+ components across a network. DCOM can work on top of a variety of network protocols, such as NetBIOS Enhanced User Interface (NetBEUI), Sequenced Package Exchange (SPX), User Datagram Protocol/Internet Protocol (UDP/IP), and Transmission Control Protocol/Internet Protocol (TCP/IP). It provides the backbone upon which to load balance COM+ components.

Figure 3: Calling components via DCOM

Figure 3: Calling components via DCOM

A piece of software, installed on the client, known as a proxy contains the location of the remote computer. It also contains code to allow calling of remote interface methods.

A part of COM known as the Service Control Manager (SCM) is responsible for activating COM components. As components are required, the SCM on the client contacts the SCM on the server to request the activation of the component. Once the server SCM creates the component, it returns a COM interface to the client via the SCM. Via the proxy, a client can call the interface methods on the remote component.

The SCM resides at a well-known endpoint that identifies the channel through which communication takes place. There is an endpoint for each network protocol. For example, port 135 is used for connection-oriented communication over TCP/IP.

COM, COM+, and the Internet

Remote client applications need to be able to activate and call remote COM and COM+ components over the Internet. In this scenario, the SCM uses port 135 to initiate remote requests over TCP/IP. However, once initiated, conversation takes place on a different port number that is selected dynamically by COM+ (in the range from 1024 through 65535). This is fine for intranet scenarios but represents a problem for Internet clients where firewalls are generally used to limit the ports that can be accessed by clients. The Component Services Explorer provides administration tools to limit which ports DCOM can use.

As another option for Internet usage, COM also supports the tunneling TCP/IP protocol. This protocol uses HTTP on port 80 to set up a client/server connection. This is useful for internet COM/COM+ clients as almost all firewalls already have port 80 open for HTTP clients. The Web server needs to use IIS and COM Internet Services for this approach to work.

A further, more recent, option is SOAP. SOAP uses two existing technologies, HTTP and XML, to facilitate interoperability among a wide range of programs and platforms. HTTP provides a RPC-like protocol for remote calls while XML is used to represent the parameters of the remote call. Again, because HTTP is being used, connection issues are largely overcome as firewalls normally have port 80 open for other HTTP clients. XML is an excellent way to describe data (parameters in this case). CLB does not support SOAP.

Another alternative is to place the components on a server that cannot be accessed by Internet clients. The components are created and manipulated on behalf of Internet clients by server-side code, such VBScript. Application Center is ideal for managing this scenario.

Application Center and Load Balancing

Load Balancing Options

Regardless of which method is used to gain access to Internet/intranet COM+ components; they are an excellent candidate for load balancing within a Web site. You can install COM+ components on customer-facing, Web-tier servers or on their own discrete servers. They can also be load balanced to serve clients running applications based on the Microsoft Win32® application-programming interface (API), such as applications written in Visual Basic or Visual C++. When organized as part of an embracing cluster, Application Center servers to greatly simplify load balancing and its management.

Within Application Center, a cluster is a set of servers that work together to provide a uniform solution. For example, a Web cluster provides Internet/intranet clients with a single view of a Web site. As part of a cluster's scaling and robustness capabilities, Application Center allows you to use various load-balancing techniques, as follows:

  • IP load balancing

  • CLB

IP load balancing is the load balancing of incoming IP traffic to cluster members. The activation of COM+ components installed on the cluster members are load balanced based on where IP traffic is routed.

Application Center supports two forms of IP load balancing:

  • NLB

  • Third-party hardware/software load balancing

Windows 2000 provides NLB as its native, software based, IP load balancing solution. You can also use other third-party hardware/software solutions.

CLB provides a means by which activating COM+ components is load balanced across a separate cluster. CLB is supplied as part of Application Center.

Cluster Types

Application Center supports three basic types of clusters:

  • General/Web cluster

  • COM+ application cluster

  • COM+ routing cluster

Each of these cluster types is discussed in the following sections.

General/Web Cluster

A general/Web cluster is any standard cluster that uses a group of servers to process client requests. These clusters can include:

  • Web servers

  • Database servers

  • E-mail servers

  • Staging/deployment servers

  • COM+ load-balanced routing servers

  • COM+ component servers

  • Stand-alone servers (clusters with one member only)

Incoming IP traffic can be load balanced across the cluster by either NLB or a third-party load balancing solution.

COM+ Application Cluster

The COM+ application cluster is a cluster of servers that manages a set of COM+ components. Each COM+ component in the set of components to be load balanced is installed on each member of the COM+ application cluster.

COM+ application clusters cater for two types of applications:

  • Server applications: these are clients running on a limited number of servers, such as those contained in a general/Web cluster. These are load balanced via CLB.

  • Client applications: these are multiple, independent clients that are typically Win32-based applications. These are load balanced by NLB.

It is also perfectly feasible to load balance COM+ components without using a dedicated COM+ application cluster. The COM+ components are simply installed at the general/Web-tier cluster and load balanced by the IP load balancer, which routes incoming IP requests to the cluster members.

Whether or not to use a dedicated COM+ application cluster depends on a number of issues, including performance, security, and manageability. These issues, coupled with the choice of two load-balancing mechanisms (NLB and CLB), mean that you must consider carefully the cluster architecture.

COM+ Routing Cluster

A less commonly used cluster is the COM+ routing cluster. The COM+ routing cluster is used principally to create a routing mechanism through to a COM+ application cluster for Win32-based client applications and general/Web cluster server applications in a three-tier topology.

Managing Clusters

The primary administrative interface for Application Center is the Microsoft Management Console (MMC), which is a Windows 2000 tool that you can use to create, save, and open collections of administrative tools, called snap-ins. You can create, manage, monitor, and otherwise administrate multiple clusters through the Application Center snap-in. Figure 4. shows a view of the Application Center snap-in managing three clusters. Note that the Application Center snap-in also allows direct access to the IIS, Microsoft Health Monitor 2.1, and Component Services snap-ins.

Bb734927.lbcm03(en-us,TechNet.10).gif

Figure 4: A typical ApplicationCenter MMC view

IP Load Balancing

Network Load Balancing

NLB is the IP load balancing software that is provided as part of Windows 2000 Advanced Server and Windows 2000 Datacenter. NLB also ships with Application Center for installation on Windows 2000 Workstation, which does not have NLB installed.

NLB distributes incoming TCP traffic, UDP traffic, and Generic Routing Encapsulation (GRE) traffic requests among the cluster members. This distribution is by a statistical algorithm based on server-load percentage settings. NLB provides dynamic scaling by automatically accommodating the addition and removal of cluster members without affecting clients. NLB is robust as it can detect a member failure and remove it from the working cluster gracefully.

Application Center greatly simplifies administration of NLB-based clusters. The Application Center Cluster Creation wizard automatically configures NLB settings. This is significantly simpler than the steps required when using Windows 2000 alone. Application Center also allows you to add, remove cluster members and place cluster members online and offline.

Note: NLB requires two network adapters in all clusters members and a static IP address for the load-balanced adapter on the controller.

Third-party IP Load Balancing

You can monitor and manage third-party IP load balancing devices with Application Center to provide a complete cluster administration solution. With third-party load balancing integration, Application Center monitors cluster member status, sets members online and offline, and synchronizes content and configuration for all Web sites, including IP addresses bound to Web sites.

Using NLB to Load Balance COM+ Components

As stated previously, you can install COM+ components on the Web cluster or create a COM+-dedicated cluster (COM+ application cluster). You can use NLB to load balance in either scenario. In fact, there are three types of Application Center cluster, for which you can use NLB to load balance COM+ components:

  • General/Web-tier

  • Routing cluster

  • Client application COM+ application cluster

Each of these cluster types are discussed later in this white paper but they all have the same basic property of having the set of COM+ components installed on each cluster member.

Figure 5: Load balancing with an NLB cluster

Figure 5: Load balancing with an NLB cluster

NLB has some advantages over CLB:

  • It requires no special configuration for the COM+ components (CLB requires you to create special routing lists)

  • There is no COM+ specific polling overhead (CLB regularly pings the CLB services on the cluster members).

On the other hand, NLB requires session affinity in order to route subsequent client requests to the same instance of the COM+ component. In practice, this means:

  • Intranet clients – Single affinity

  • Internet clients – Class C affinity

If proxy farms are being used, it might not be possible to use IP load balancing.

NLB is not able to account for the workload on the server upon which the component is being created. CLB, through its regular pinging of cluster members, is able to build a picture of the cluster workload and apportion component creation accordingly.

In general, performance with NLB is not great if the number of active clients is small (say, less than 10 times the number of servers) since you must use either Single affinity or Class C affinity. These settings lock each client to a single server.

Finally, NLB is not sensitive to the failure of the COM+ system on a given cluster member. This means calls are routed to cluster members even if their COM+ Services have failed. IP load balancing only requires the member to be running with a functional network adapter.

Using NLB to Configure COM+ Component Support for Clusters

If you install COM+ components for use on a cluster that is using NLB, it is important to ensure that CoCreateInstance calls from the client (either a Win32-based client, or possibly a server application on a different Application Center cluster) are forwarded to the cluster IP address of the NLB cluster; not to individual cluster members. If calls to create COM+ components are forwarded to individual members, the calls will not be load balanced.

Figure 6: NLB based load balancing

Figure 6: NLB based load balancing

This affects the three NLB cluster types described earlier; that is:

  • Routing cluster

  • Client application COM+ application cluster

  • General/Web cluster (if Win32-based clients are also supported)

Setting Up the Client NLB Cluster Address for COM+ Components

To ensure load balancing occurs for component creation the COM+ application proxy installed on the Win32-based client, or client/Web-tier, must point to the cluster's IP address.

To point the COM+ application proxy to the cluster's IP address:

  1. On the NLB cluster controller, open Component Services.

  2. Click Computers.

  3. Right-click My Computer, and then on the pop-up menu, click Properties.

  4. Click the Options tab, and then under Export, set Application proxy RSN to the cluster name or cluster IP address.

    This is available, via Application Center, by selecting the properties of the cluster.

  5. Export the component's COM+ application as an application proxy.

    The resulting Windows Installer package can be installed on any client (Web-tier or Win32-based) and will automatically point the proxy at the cluster. Calls to CoCreateInstance on the Web tier, or Win32-based client, are then forwarded to the NLB cluster.

To configure previously installed COM+ application proxies:

  1. On the computer with the proxy installed, open Component Services.

  2. Click Computers, click My computer, click COM+ Applications, and then right-click the name of the COM+ application proxy.

  3. Select Properties, and then click the Activation tab.

  4. In the Remote server name box, enter the cluster name or IP address, and then click OK.

Component Load Balancing

The CLB software provided as part of Application Center enables load-balanced remote activation of COM+ components on a separate cluster.

There are two major parts to CLB:

  • CLB management software, which is used to load balance a COM+ application cluster.

  • COM+ application cluster, which is an Application Center—managed cluster of servers that activates and runs COM+ components.

    Figure 7: Typical CLB topology

    Figure 7: Typical CLB topology

CLB Management Software

The CLB management software determines the order in which COM+ cluster members are used to activate COM+ components. The decision-making elements of the CLB software run at the general/Web or routing cluster. Some information-gathering CLB software also runs on the COM+ application cluster.

The General/Web-tier and the COM+ Routing Cluster

As noted previously the general/Web cluster is the all-purpose cluster type for managing the bulk of client work. This includes running the CLB management software. The COM+ routing cluster is typically used to manage multiple Win32-based clients that require the use of a CLB load-balanced cluster. The COM+ routing cluster is also used to route activation requests from a general/Web-tier cluster to a COM+ application cluster in a three-tier topology. (For more information about the COM+ routing cluster topologies, see "Load Balancing Topologies," later in this white paper). Accordingly, the CLB management software also runs on the COM+ routing cluster.

A copy of the COM+ components to be load balanced on the COM+ application cluster is also installed on the general/Web cluster and COM+ routing cluster (if it is being used). The COM+ component must support dynamic load balancing. The dynamic load balancing property of the component is available via the COM+ Services Explorer (accessible from Component Services within the Application Center snap in).

The business logic that requests the creation of a COM+ component runs on the general/Web cluster. Typically, this is a Visual Basic ASP script that calls CreateObject when a COM+ component is required (internally this translates to a call to CoCreateInstance). For a COM+ routing cluster the component creation request comes from either a Win32-based client or general/Web cluster.

With CLB, instead of creating the component on a general/Web or COM+ routing cluster member, a routing list and server Response Time Table is used to help pass the COM+ component activation request through to a load-balanced COM+ application cluster. Then, a COM+ application cluster member creates the component and returns an interface to the client. Once a component has been created, CLB has no further active involvement with the component.

Note: In the following sections ("Routing List" and "Response Time Table"), references to Response Times Tables and general/Web clusters also apply to COM+ routing clusters.

Routing List

As shown in the following figure, the routing list exists on each general/Web cluster member and contains a list of the COM+ application members to be load-balanced.

Bb734927.lbcm07(en-us,TechNet.10).gif

Figure 8: Routing lists and Response Time Tables

Initially, the administrator creates the routing list on the general/Web cluster controller. Then, the Application Center software automatically synchronizes the routing list to each cluster member. For this reason, it is not possible, nor is it advisable, to have cluster members with routing lists that contain differing COM+ application cluster members. One big advantage with having the routing list on each Web-tier cluster member is that there is no single point of failure. If a given general/Web cluster member stops, whether or not by design, other members will continue to load balance the COM+ application cluster through their own routing lists.

Response Time Table

Every 800 milliseconds, the CLB software running on each general/Web cluster member polls every member in its routing list (the COM+ application cluster members). At the routing list member, the COM+ infrastructure calculates the response time for each load balanced COM+ component (CLSID). This calculation involves the interception of COM+ component method calls, including the component activation. The data is collected from all routing list members to build a Response Time Table. The table holds a list of response time ordered by routing list computers for each type of COM+ component. Each general/Web cluster member will have its own unique version of this table. These values are not synchronized across the general/Web cluster because the list would not be replicated fast enough to keep up with changing COM+ application cluster load.

To provide further robustness, a COM+ application cluster member is not considered for load balancing a given CLSID during a polling period, if the CLSID fails to meet a predetermined response threshold. When the CLSID meets the required response threshold during subsequent polls, the member once again becomes available for load balancing.

The response threshold is the number of method call failures, meaning that if a COM+ application cluster member reports method call failures for a CLSID, no more activations are sent to that member, for that CLSID, for a period of time (approximately four seconds). After that, the member is added again to the routing list for that CLSID.

The general/Web cluster member uses the Response Time Table to pass incoming activation requests for COM+ components to the COM+ application cluster members. When a COM+ component activation request is first received its CLSID is located in the Response Time Table and the fastest, least busy, COM+ application cluster member is used first, followed by the next slower member for subsequent requests. Once the list of members has been exhausted, the next request is routed to the first table entry. Further activations proceed through the table as before. This round-robin process continues until the next scheduled response time poll occurs after 800 milliseconds. After the response time poll occurs, activation is reset to the beginning of the freshly load-balanced table.

COM+ Application Cluster

For CLB the COM+ application cluster type is a server application. The result is a cluster that is designed to meet the needs of server applications running on general/Web-tier clusters or other servers. Typically, the code running on the client cluster/server will be ASP script but server applications written in Visual Basic or Visual C++ are equally valid.

Each COM+ application cluster member will have a copy of each load-balanced COM+ component that you install on the member. A Deployment wizard is available for installing the COM+ components.

The CLB software running on the COM+ application cluster members collects the response time information required by the CLB management software running on the general/Web, or routing, cluster.

Failure and COM+ Component Activation

If a COM+ application cluster member fails, it is not considered for CLB load-balanced activation. To determine if the cluster member is alive the call from the general/Web or routing cluster to retrieve the response time indicates the cluster member state. If an error is returned, the member is considered down and is therefore not eligible for CLB load-balancing. Once a failed member successfully rejoins the cluster, it will again be eligible for CLB load balancing.

If the activation of a COM+ component fails on an otherwise functional COM+ application cluster member, the client will receive an error. The client can determine whether or not to retry the activation. CLB will not automatically retry the activation on behalf of the client. One approach to ensuring that a COM+ component can be activated is to have Health Monitor periodically create an instance of the COM+ component.

Cluster-aware COM+ Components

You must write COM+ components so that they acknowledge the load balanced situation they are in. The key issue is that of component state. In COM+, components should not retain per-component state information because this adversely affects scalability and transaction management. Scalability is affected because components cannot be recycled unless they are stateless. Transaction management is made more complex because per-component state cannot cross transaction boundaries. Using load balancing requires further considerations. In essence, do not make assumptions about member node locality, because the component creation could occur on any member of the cluster. For example, in COM+, you can use process-wide storage to store information that is useful to multiple components running on a server. If you chose to use this in a cluster, you must manage it carefully because there is no guarantee as to which member a component will be created on. Thus, subsequent re-activation of a component instance could occur on a different cluster member. This results in the component losing access to the process-wide storage on the previous member.

Component state needs to be stored either in persistent state, such as a DBMS, 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.

Deploying COM+ Components

Application Center provides a means by which you can deploy COM+ components within a cluster and from one cluster to another. This is useful for setting up cluster content and, when coupled with a staging cluster, it simplifies updating COM+ components installed on production clusters. A staging cluster is typically a one-member general/Web cluster that contains the final content for the production clusters (see the following figure). You deploy final COM+ components, installed on the staging cluster, via the Deployment wizard to the production clusters. For more information, see "Synchronizing and Deploying Content" in the Application Center online Help.

Bb734927.lbcm08(en-us,TechNet.10).gif

Figure 9: Stagers in Application Center

The Deployment wizard deploys Application Center applications. However, by default, COM+ components that are part of an application are not deployed because component deployment requires a restart of IIS on the target. Because this can result in the computer being restarted, it is important to avoid bringing the entire cluster down during component deployment. This requires a phased deployment wherein you take cluster members offline, update the members, and then bring the members back online.

Another point to note is that in a CLB topology you must synchronize component deployment between the general/Web, or routing, cluster and the COM+ application cluster. Otherwise, the two tiers might have different versions of the installed component while the Web site is active. For more information on COM+ component deployment, see the Microsoft Application Center 2000 Resource Kit.

To gain access to the Deployment wizard, in the Application Center span-in, right-click the Applications node. The Deployment wizard allows you to force COM+ component deployment.

Secure COM+ Components

A common scenario 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 could potentially be compromised if the components are placed on the general/Web cluster. Calls received by the Web-tier cluster might come from an untrustworthy client seeking to take illegal advantage of the COM+ components installed on the cluster member. CLB enables you to avoid this by instantiating the COM+ components not on the general/Web cluster but on a COM+ application cluster. The COM+ application cluster is usually protected by a firewall (Firewall B in the following figure) and only allows components to be created from calls that have originated from within the Web-tier cluster and not from the client. The following figure also shows a Demilitarized Zone (DMZ) protecting the Web tier through two encompassing firewalls.

Figure 10: Securing COM+ components

Figure 10: Securing COM+ components

One caveat to this two-tier solution is that in order for CLB to work, you must install the COM+ component DLLs on the general/Web cluster. They do not run on the general/Web cluster as this is the purpose of the unexposed COM+ application cluster but they do act as a proxy. But, if simply having the COM+ component DLLs installed on the Internet-accessible Web tier is considered too high a risk, consider securing the components behind a three-tier solution that uses COM+ proxies on the Web tier to hide direct access to the COM+ component DLLs. You will need to ensure that the proxies point to the cluster IP address of an unexposed routing cluster. For details on how to do this, see the procedures in "Using NLB to Configure COM+ Component Support," earlier in this white paper.

Cross Network Performance

Both CLB and NLB are great technologies for building distributed solutions. However, understanding the network performance implications of using either is critical to building efficient cluster topologies.

However attractive or functional a Web site is, it will not succeed if users do not get satisfactory performance from it. Two issues are important:

  • Throughput: the work done by a Web site

  • Response time: the time taken to return information to a user.

Both of these are related and CLB/NLB both have their issues related to them.

Throughput

Throughput performance declines when making any kind of call across a network. Using CLB obviously incurs this cost and you need to account for this when making cluster-architecture decisions. To give some perspective on this, the data in the following table shows the number of calls per second on a single threaded Visual Basic version 6.0 COM component that returns "Hello, world" as a string property. The client is early bound and does not release references between calls to retrieve the property.

Scenario

Calls per second

Relative speed

COM+ server application, run over a 10BaseT network

625

1.0x

COM+ server application, out proc, same box

1923

3.08x

COM+ Library application, in proc, same box

3333

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, Microsoft software or otherwise. For this reason, CLB does not make a great solution when throughput is absolutely critical. In this case, it is better to install the COM+ components locally on the general/Web cluster members, thus avoiding cross-network calls. CLB support is lost but load balancing is still available through NLB. As noted earlier however, NLB performance is poor when the number of clients is low (less than 10 times the number of servers). For this reason, it is important to know what load you expect when designing your site and to plan accordingly.

Furthermore, when run in process on a local server, COM+ components can be called much faster than when called from another process. Installing COM+ components on the general/Web cluster as part of Library applications will allow them to be called in process. This is great for performance but introduces stability concerns as the component cannot easily be isolated if problems occur. A crashing COM+ Library component will most likely bring down its host process. Hosting the COM+ component in its own process as a server application increases stability because client programs can more readily survive the results of a crashed COM+ component. However, this will degrade the component performance as cross process calls will be made.

Response Time

Ensuring that users receive 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 might perform work that perceptively degrades the response time for the Web site. If response time for non-COM+ component work is more important than component throughput, one solution, as described earlier, is to move the COM+ components to a COM+ application cluster tier. This will decrease the workload for the Web-tier cluster and service time for clients that are not using COM+ components (for example, clients accessing static Web pages) will be improved. Obviously, when COM+ component work is required, no response time improvement will be seen. In fact, performance will probably degrade because cross network calls will be taking place. Another option, again described earlier, is to move the routing lists onto a separate COM+ routing cluster. This decreases the workload for the Web-tier cluster because no CLB-specific work will take place on it. Again, this is good for non-COM+ component work on the general/Web cluster but introduces even more performance degradation for COM+ components because of cross network calls.

It is clear that the high performance distribution of COM+ components requires careful planning. This is particularly true for CLB, which relies on cross network calls for its implementation.

Load Balancing Topologies

The topology of Application Center clusters is fundamental to how load balancing is supported. A typical Application Center cluster topology is based on an n-tier solution that includes a general/Web cluster for serving content to the client. The general/Web cluster uses IIS and IP load balancing to satisfy incoming IP requests. A separate COM+ application cluster can be used for load balancing COM+ components. With this in mind IP and CLB load balancing both allow for a rich and varied set of COM+ component topologies to be built. Issues of security, management, and performance all play a vital role in deciding which topology is most suitable.

One-tier NLB Cluster

In this topology COM+ components are installed on the general/Web cluster. COM+ component load balancing occurs as a result of the incoming IP traffic being load balanced to cluster members via NLB. At the cluster member, local COM+ components are created as required. No further load balancing takes place.

Figure 11: One-tier NLB cluster

Figure 11: One-tier NLB cluster

This topology provides the highest performance (usually) and manageability. The components are created locally and therefore no cross network performance degradation occurs. However, if the COM+ components are processor intensive or require a long load time (greater than 500ms), overall system performance can be affected. Also, if the number of active clients is relatively small (fewer than 10 times the number of servers), performance will suffer as the statistical nature of NLB load balancing does not efficiently deal with few clients.

Management is simplified because deployment is to a single tier and CLB set up is not required. Security is a concern for this topology as there is no way to isolate the COM+ components separately via a firewall.

Two-tier CLB Cluster

This, the simplest CLB topology, has two tiers – a Web tier and a COM+ application tier. As requests for COM+ component creation occur on the Web tier, CLB load balances the requests to the COM+ application cluster members (see the following figure).

Figure 12: Two-tier CLB cluster

Figure 12: Two-tier CLB cluster

From a performance and management perspective this most likely the most efficient CLB topology – creation of remote COM+ components is only one network step away and COM+ components can be easily deployed to the single COM+ application cluster. However, this simplicity does come at a cost to flexibility - it is not possible to address multiple COM+ application clusters as the Web-tier routing list can only reference one COM+ application cluster.

Three-tier CLB Cluster

In this topology, the introduction of a COM+ routing cluster provides routing of COM+ component activation from the general/Web tier cluster to the COM+ application cluster. This allows you to build the classic three-tier Windows DNA application and offers better security management (as discussed in "Secure COM+ Components," earlier in this white paper). The major disadvantage is the performance degradation incurred in stepping from the general/Web cluster to the COM+ application cluster via an intermediary step.

Bb734927.lbcm12(en-us,TechNet.10).gif

Figure 13: Three-tier CLB Cluster

As shown in the preceding figure, the typical routing cluster will have two or more members. You can use this to provide failover or load balancing support for the cluster.

COM+ component proxies installed on the general/Web cluster member forward creation requests to the COM+ routing cluster. After NLB passes the request to one of the routing cluster members, CLB ultimately creates the COM+ component on a COM+ application cluster member and a reference is passed back to the general/Web cluster member. The proxies need to be set up to point to the NLB driven COM+ routing cluster. For details on how to do this, see the procedures in "Using NLB to Configure COM+ Component Support," earlier in this white paper.

Win32-based Client Support

Win32-based clients of load balanced COM+ components are best supported in one of two ways:

  • As a COM+ routing cluster.

  • As a client application COM+ application cluster.

Each of these methods is described in the following two sections.

COM+ Routing Cluster

This is essentially the same as a general/Web cluster; however, the COM+ routing cluster is designed for the scenario where you have hundreds to thousands of Win32-based clients, instead of a few Web servers, wanting to instantiate load balanced COM+ components. In that case, because it is not practical to install Application Center on every Win32-based client computer and use CLB, you can set up a routing cluster in which incoming Win32-based client calls to create component instances are routed to a CLB driven COM+ application cluster. The routing cluster is typically two servers that are load-balanced with NLB. This provides scaling and fail-safe operation through load balancing.

Bb734927.lbcm13(en-us,TechNet.10).gif

Figure 14: Supporting Win32-based clients with a COM+ routing cluster

Application Center provides wizard support for creating a COM+ routing cluster.

Note: In the standard n-tier application scenario, where browser clients are communicating with a tier of Web servers, which are in turn communicating with a tier or COM+ application servers, there is no need for a COM+ routing cluster.

Client Application COM+ Application Cluster

This is a one-tier topology similar to the 1-tier topology described in the preceding section. The client application COM+ application cluster uses NLB to load balance many Win32-based clients. Again, the Cluster Creation wizard provides support for creating this type of cluster. The following figure illustrates this topology.

Bb734927.lbcm14(en-us,TechNet.10).gif

Figure 15: Supporting Win32-based clients with a client application COM+ application cluster

Note: Because both the COM+ routing cluster and the client application COM+ application cluster use NLB, you must configure their clients to call the cluster's own IP address. For details on how to do this, see the procedures in "Using NLB to Configure COM+ Component Support," earlier in this white paper.

Conclusion

By using CLB and/or NLB, Application Center provides a high performance, scalable, secure, and robust mechanism for load balancing COM+ components across a cluster. The choice of topology very much depends on the Web site requirements and you must take great care during design to ensure appropriate technologies are used. Used wisely, the CLB and NLB technologies will help you develop great .NET-based solutions.

Appendix 1 – Setting Up Topologies

This appendix provides examples that explain the main steps for setting up several of the major topology scenarios.

1. Using CLB for Two-Tier Load Balancing

The following steps describe the setting up of a two-tier topology that employs a general/Web and COM+ application cluster. It also uses a staging cluster as a deployment source for content to both cluster tiers.

  1. Set up the clusters.

    Three clusters are required for this CLB topology. One cluster holds the routing lists. Typically, as described in "Two-tier CLB Cluster" earlier in this white paper, the routing lists are on the general/Web cluster. The second-tier cluster is the COM+ application cluster. A third cluster acts as the staging cluster.

    • Create the client-facing, first-tier cluster as a General/Web cluster with support for NLB.

    • Create the staging cluster as a General/Web cluster with no load balancing support and only one member (including the cluster controller).

    • Create the second-tier COM+ application cluster as a COM+ Application cluster.

      The type of client for this cluster is server application. This ensures CLB is used for load balancing.

    For more information, see "Creating a Cluster" in the Application Center online Help.

  2. Set up the stager.

    Install the COM+ components to be load balanced on the staging cluster. You must add the components as a resource to an existing application or to a new application.

    To add components to an existing application or a new application

    In the Application Center snap-in, click the Applications node.

    To add the components to an existing application, click the application, and then click Add.

    To create a new application for the components, in the Applications view, click New.

  3. Deploy the COM+ components to the COM+ application cluster.

    Use the Deployment wizard to deploy the Application Center applications to the COM+ application cluster.

    Remember to phase the deployment if you are updating components while the cluster is active to avoid bringing down the entire cluster. If you are building the topology for the first time, phased deployment is not a concern.

    To start the Deployment wizard

    In the Application Center snap-in, in the Console pane, right-click the Applications node.

  4. Deploy the COM+ components to the general/Web cluster.

    Use the Deployment wizard to deploy the Application Center applications to the general/Web cluster.

    Remember to phase the deployment to avoid bringing down the entire cluster. Additionally, to prevent inconsistent component versioning between the clusters, be sure to synchronize the components on the two tiers.

  5. Mark the general/Web cluster COM+ components as supporting CLB.

    You must mark the COM+ components on the general/Web cluster as supporting CLB.

    To mark a COM+ component

    In the Application Center snap-in, in the Console pane, double-click Component Services.

    Locate the COM+ application that contains the COM+ component, right-click the component, click Properties, click the Activation tab, and then select the Component supports dynamic load balancing check box.

  6. Build the routing list.

    The routing list is created on the general/Web cluster controller and is synchronized automatically throughout the Web-tier cluster.

    To add the list of COM+ application cluster members

    In the Application Center snap-in, in the Console pane, right-click the general/Web cluster, click Properties, and then click the component Services tab.

Once you have completed the installation, the general/Web cluster software running on behalf of clients will use your COM+ components oblivious to their location within the COM+ cluster.

2. Three-tier CLB

Setting up a three-tier CLB topology is essentially the same as the two-tier CLB topology, described in the preceding section, except you add one other tier.

  1. Set up the clusters.

    Four cluster are required:

    • General/Web cluster: the client-facing first-tier cluster.

      You install COM+ component proxies here; not the actual components.

    • COM+ routing cluster: the second-tier cluster that routes incoming activation requests to the COM+ application cluster.

    • COM+ application cluster: the third-tier cluster that creates the components.

      The cluster client type is server application.

    • Staging cluster: the cluster that deploys the COM+ component proxies.

  2. Set up the stager.

    Install the COM+ components on both the COM+ routing cluster and the COM+ application cluster. To do this, use Step 2 in the preceding section, "Using CLB for Two-tier Load Balancing."

  3. Deploy the COM+ components to the COM+ application cluster and COM+ routing cluster.

    To do this, use Step 3 and Step 4 in the preceding section, "Using CLB for Two-tier Load Balancing."

    Note: Step 4 refers to the general/Web cluster. In this topology the COM+ routing cluster is used to load balance the COM+ application cluster. Therefore, you must install the COM+ components on the COM+ routing cluster; not the general/Web cluster.

  4. Mark the COM+ routing cluster COM+ components as supporting CLB.

    The COM+ components on the routing cluster need to be marked as supporting CLB. To do this, use Step 5 in the preceding section, "Using CLB for Two-tier Load Balancing."

  5. Build the routing list.

    The routing list is created on the COM+ routing cluster controller and is synchronized automatically throughout the routing cluster.

    To add the list of COM+ application cluster members

    In the Application Center snap-in, in the Console pane, right-click the COM+ routing cluster, click Properties, and then click the component Services tab.

  6. Create the COM+ component proxies.

    You use the COM+ components installed on the COM+ routing cluster to create proxies for installation on the general/Web cluster.

    To create the COM+ component proxies

    • On the routing cluster controller, open Component Services, click Computers, right-click My Computer, and then click Properties.

    • Click the Options tab, and then under Export set Application proxy RSN to the routing cluster name or IP address

    • Export the COM+ application containing the COM+ component as an application proxy:

      1. In the Application Center snap-in, in the Console pane, open Component Services, locate the COM+ application, right-click the COM+ application, and then click Export .

      2. Enter a name for the export, and then for the export type, select Application Proxy.

      3. Click Next.

        This creates the proxy installer .msi file.

  7. Install the COM+ component proxies on the general/Web-tier

    Manually install the proxy .msi installer file on each general/Web cluster member.

Once this scenario is running, the server code running on the general/Web cluster will instantiate load-balanced COM+ components via the routing cluster.

3. Using NLB for One-tier Load Balancing

This, the simplest topology, uses a general/Web cluster to load balance COM+ component creation via NLB.

  1. Set up the cluster

    • Two clusters are required:

      General/Web cluster: the client-facing first-tier cluster.

      Staging cluster: create the staging cluster as a General/Web cluster with no load balancing support and only one member (including the cluster controller).

  2. Deploy the components.

    Use the Deployment wizard to deploy the Application Center applications that contain the COM+ components to the general/Web cluster.

Once set up, COM+ components instantiation will be load balanced across the general/Web cluster as a result of NLB distribution of incoming IP traffic.

4. Two-tier CLB for Win32-based Clients

In this scenario, COM+ components are load balanced for use by Win32-based client applications. You use a routing cluster to route incoming requests for components to a CLB-managed COM+ application cluster.

  1. Set up the clusters.

    Three clusters are required:

    • A staging cluster.

    • A COM+ routing cluster: you can use NLB, a third-party load balancing solution or none at all.

    • COM+ application cluster: this needs to be a server application cluster.

  2. Deploy the COM+ components to the COM+ application cluster.

    To do this, use Step 3 in "Using CLB for Two-tier Load Balancing," earlier in this white paper.

  3. Deploy the COM+ components to the COM+ routing cluster.

    To do this, use Step 4 in "Using CLB for Two-tier Load Balancing," earlier in this white paper.

    Important: Use the routing cluster; not the general/Web cluster.

  4. Mark the COM+ routing cluster components as supporting CLB.

    To do this, use Step 5 in "Using CLB for Two-tier Load Balancing," earlier in this white paper.

    Important: Use the routing cluster; not the general/Web cluster.

  5. Build the routing list on the routing cluster.

    To do this, use Step 6 in "Using CLB for Two-tier Load Balancing," earlier in this white paper.

    Important: Create the routing lists on the routing cluster.

  6. Configure the Win32-based clients.

    Do the following to ensure CoCreateInstance calls from Win32-based clients for a load balanced COM+ component are routed to the cluster IP address of the COM+ routing cluster (and thus supporting load balancing).

    • On the routing cluster controller, open Component Services.

    • Click Computers.

    • Right-click My Computer, and then click Properties.

    • Click the Options tab, and then under Export, set Application proxy RSN to the cluster name or cluster IP address

    • Export the COM+ application containing the COM+ component as an application proxy:

      1. In Component Services, locate the COM+ application, right-click the application, and then click Export .

      2. Enter a name for the export, for the export type, select Application Proxy, and then click Next.

Install the resulting Windows Installer package on any computer running the Win32-based client. This will point the proxy at the routing cluster automatically. Calls to CoCreateInstance on the Win32-based client will be forwarded to the routing cluster.

5. One-tier NLB for Win32-based Clients

In this scenario, Win32-based clients use a client application COM+ application cluster to load balance, via NLB, COM+ components.

  1. Set up the clusters.

    Two cluster are required:

    • A client application COM+ application cluster. Use the Cluster Creation wizard to create this cluster.

      Note: Choose NLB as the load balancer.

    • A staging cluster to deploy COM+ components to the client application cluster. As described in "One-tier NLB," earlier in this white paper, this is a one-member general/Web cluster with no load balancing support.

  2. Deploy the COM+ components.

    On the stager, create a COM+ application and add your COM+ components to it. The COM+ application needs to be a server application.

    On the stager, create an Application Center application to hold the COM+ application.

    Use the Deployment Wizard to deploy the Application Center application to the client application cluster.

  3. Set up the cluster address for the COM+ application proxy.

  4. On the client application COM+ application cluster, open Component Services.

    • Right-click My Computer, and then click Properties.

    • Click the Options tab, and then under Export set Application proxy RSN to the cluster name or cluster IP address.

    • Export the application as an application proxy.

Once you have installed the COM+ application proxy on a Win32-based client, calls to create COM+ components referenced within will be load balanced across the cluster via the cluster's virtual IP address.

Component Load Balancing in Action

The instructions in this section allow you to see CLB in action. The instructions assume that you are using a stager to deploy the content to the Web-tier and COM+ clusters. Additionally, a working knowledge of Visual Basic, ASP, and HTML is assumed.

  1. On the stager, use Visual Basic to create a COM+ component that exports the following function:

    2. 



Public Function GetName() As String
Set WS = CreateObject("wscript.network")
if not (WS is nothing) then
GetName = WS.Computername
else
GetName="Error getting computer name"
end if
Set WS=nothing
End Function



    

  1. Use COM+ Services to wrap the component in a COM+ application.
    

    2. 

  2. On the stager, create an Application Center application that includes the COM+ component.
    

    3. 

  3. Deploy the COM+ component to the COM+ application cluster.
    

    Important: In the Deployment wizard, select Deploy COM+ applications; otherwise, the component will not be deployed.
    

    4. 

  4. Create an ASP file called Default.asp with the following script:
    

    5. 



<script language=vbscript runat="server">
for n=1 to 50
set x=createobject ("YourComponent.YourClass")
if not (x is nothing) then
Response.Write "Component created on: "
Response.Write x.GetName
Response.write "<br>"
set x=nothing
else
Response.Write "Error creating component"
end if
next
</script>



    

  1. Replace ProgID "YourComponent.YourClass" with the ProgID of the component built in step 1.
    

    2. 

  2. On the stager, create an Application Center application that includes the Default.asp file from step 5 and the COM+ component from step 1.
    

    3. 

  3. Deploy the application to the Web-tier cluster.
    

    4. 

  4. Ensure that the Web-tier routing lists are set up and the COM+ component is marked to support load balancing.
    

    5. 

  5. Run Default.asp from a client.
    

    If it doesn't work initially, it may be the result of IIS being restarted during component deployment. Wait a short while before trying again.
    

    6. 



If successful, you will see a list of the COM+ cluster members that were used to create instances of the component.


Resources


https://www.Microsoft.com/ApplicationCenter - Latest information on Application Center.


https://www.microsoft.com/technet/prodtechnol/acs/default.mspx - Downloadable Microsoft Reader version of the Microsoft Application Center 2000 Resource Kit.


Pre-flight check list – Available on the Microsoft Application Center 2000 CD. The checklist provides comprehensive instructions for setting up and validating cluster configuration.


https://www.microsoft.com/com/ - Information on COM and COM+.


https://www.microsoft.com/net/ - Authorative information on the .NET initiative.


https://msdn.microsoft.com/library/backgrnd/html/CIS.htm - Information on COM Internet Services (CIS)


https://www.microsoft.com/com/wpaper/dcomfw.asp - Information on DCOM and firewalls.