Microsoft Application Center 2000 Component Load Balancing Technology Overview

By Chris Rees

This technology overview describes Microsoft Application Center 2000 (Application Center) Component Load Balancing (CLB).

On This Page

Introduction
Application Center Clusters
Network Load Balancing
Component Load Balancing
How Component Load Balancing Works
Setting Up Component Load Balancing
Component Load Balancing in Action
When to Use CLB
Conclusion
Resources

Introduction

Microsoft Application Center 2000 (Application Center) is part of the Enterprise Server offerings that make up the .NET initiative offered by Microsoft. Some of the other Enterprise Server offerings include Commerce Server 2000, BizTalk Server 2000, and SQL Server 2000. For more information on .NET see https://www.microsoft.com/net .

The role of Application Center within .NET is to provide content deployment and management facilities for Web sites built on Windows 2000 and Internet Information Services 5.0. Application Center makes Web sites that are scalable, robust, easy to administer, and secure. 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. Cluster health can be easily monitored through events, performance counters, and monitors that reflect the current cluster state.

Application Center Clusters

Application Center allows multi-tiered clusters to be built that can use various load balancing techniques. Load Balancing helps Application Center provide scalability and robustness. Two types of load balancing are supported:

  • Network Load Balancing (NLB)

  • Component Load Balancing (CLB)

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 Web-tier cluster for serving content to the client. It is the Web-tier cluster that uses IIS and Network Load Balancing (NLB) to satisfy incoming IP requests.

Figure 1: Typical Application Center Cluster Topology

Figure 1: Typical Application Center Cluster Topology

Software on the Web-tier (ASP pages, and so on) can create and use COM+ components on the local computer or remotely, by using Distributed COM, on a different computer. Without CLB, remote activation would be static as it doesn't account for the workload already placed upon the remote server. This is the purpose behind CLB—to provide failsafe, scalable, load-balanced activation of COM+ components installed on a separate cluster of servers.

Network Load Balancing

Network Load Balancing (NLB) is the IP load balancing that is provided as part of Windows 2000 Advanced Server and Windows 2000 Data Center. With NLB, incoming TCP traffic, User Datagram Protocol (UDP) traffic, and Generic Routing Encapsulation (GRE) traffic requests are distributed 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 servers from the cluster without affecting clients. NLB is robust as it can detect a server 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 servers to be easily added, removed, and placed on/offline within the cluster.

For more information on NLB see
https://www.microsoft.com/windows2000/library/howitworks/cluster/nlb.asp .

Component Load Balancing

Component Load Balancing allows COM+ components to be load balanced. 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. In CLB, the COM+ components are maintained on servers in a separate COM+ cluster. Calls to activate COM+ components are load balanced to different servers within the COM+ cluster. As shown in Figure 1, the decision-making elements of the CLB software run on the Web-tier. Some information-gathering CLB software does run on the COM+ cluster.

Component Object Model

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 knows how to deal 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.

Figure 2: Interfaces on a COM Component

Figure 2: Interfaces on a COM Component

Typically, COM components are housed within dynamic-link libraries (DLL) or executables (.exe) files. They can be installed on the client or located on 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

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

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 find out if a particular COM+ Service is supported, for example, transaction support or, as we shall see later, load balancing.

COM+ components are grouped together into packages known as Applications, which are not 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. Examples of these are Web sites, files, COM+ components, and registry keys among others.

How Component Load Balancing Works

There are two major parts to CLB:

  • CLB software used to load balance a COM+ cluster.

  • COM+ cluster. (An Application Center managed cluster of servers 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 Time table 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 has 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. See Figure 3. Alternatively, there is another location for the routing lists on what is called a COM+ routing cluster. This is used solely for routing purposes and has no Web-tier functionality. This paper concentrates on the Web-tier scenario.

Bb734922.clbovr03(en-us,TechNet.10).gif

Figure 3: 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 is therefore not possible, or indeed advisable, to have cluster members with routing lists containing differing COM+ 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 Web-tier cluster member stops, whether by design or not, other members will continue to load balance the COM+ cluster through their own routing lists.

Response Time Table

Every 200 milliseconds, the CLB software running on each Web-tier cluster member polls every member of its routing list. From this an in-memory table is built 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 time table in a round robin manner to pass incoming activation requests to the COM+ cluster members. This means that 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 to 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 its own COM+ cluster member response time table. No attempt is made to synchronize these values across the Web-tier cluster as the list would not be replicated fast enough to keep up with changing COM+ cluster load.

COM+ Cluster

As with the Web-tier cluster, the administrator creates the COM+ cluster with the Application Center cluster creation wizard. 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 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 acknowledge the 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 CLB requires further considerations. In essence, do not make assumptions about member node locality, because the component creation could occur on any member of the CLB cluster. For example, in COM+, process-wide storage can be used to store information useful to multiple components running on a server. Using this in a COM+ cluster needs to be carefully managed because there is no guarantee as to which member a component will be created on. Thus, subsequent re-activation of a component instance may 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.

Setting Up Component Load Balancing

The following steps are required to set up a COM+ cluster. They are based upon the functionality found in Application Center Beta 2.

  1. Set up the clusters.

    Two clusters are required for CLB. One cluster holds the routing lists. This typically, and as described previously, is on the Web-tier cluster. The second cluster is the COM+ cluster. See "Creating a Cluster" in the online Help.

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

    By using the deployment wizard, you can deploy Application Center Applications to other clusters. This is useful for staging clusters that are used to deploy updated content to production clusters. See Figure 4. Typically, you will run the deployment wizard from a stager that has the COM+ components wrapped up in an Application Center Application. See "Synchronizing and Deploying Content" in the online Help.

    Figure 4: Stagers in Application Center

    Figure 4: Stagers in Application Center

    Note: By default COM+ components are not deployed, because component deployment requires that the target IIS Service is restarted and may also result in the computer being restarted. However, the deployment wizard provides an option to force COM+ component deployment.

    It is therefore important to avoid bringing the entire cluster down during component deployment. This requires a phased deployment in which cluster members are taken offline, updated, and then brought back online. See the Microsoft Application Center 2000 Resource Kit for further information on this issue.

  3. Deploy the COM+ components to the Web-tier cluster

    CLB requires that the COM+ component be installed on each Web-tier cluster member. Again the deployment wizard can be used to do this. The COM+ component can be wrapped up in the Application Center Application being deployed to the Web site. Remember though, COM+ component deployment will require the IIS Service to be restarted. So, to ensure a Web site is always available, it is important to phase component deployment. Another point to note is that the Web-tier cluster component deployment needs to be synchronized with the COM+ cluster. Otherwise the Web-tier and COM+ clusters may have different versions of the component installed while the Web site is live. See the Microsoft Application Center 2000 Resource Kit for further information.

  4. Mark the Web-tier COM+ components as supporting CLB.

    The COM+ components on the Web-tier cluster need to be marked as supporting CLB. This is done through the Component Services Explorer, readily available through the Application Center snap-in. Mark the component by drilling to it through its containing COM+ application, selecting the Activation tab on the property page, and then selecting the Component supports dynamic load balancing check box.

  5. Build the routing list

    The routing list is created on the Web-tier cluster controller and automatically synchronized throughout the Web-tier cluster. The list of COM+ cluster members can be added via the component Services tab on the Web-tier cluster property page within Application Center.

And that's it. Once everything has been installed, Web-tier software running on behalf of clients will use your COM+ components oblivious to their location within the COM+ cluster.

Component Load Balancing in Action

These instructions allow CLB to be quickly seen in action. They assume that a stager is used to deploy the content to the Web-tier and COM+ clusters. A working knowledge of Visual Basic, ASP, and HTML is also assumed.

  1. Using Visual Basic on the stager, create a COM+ component that exports the following function.

Public Function GetName() As String Set WS = CreateObject("wscript.network") GetName = WS.Computername Set WS=nothing End Function

  1. Wrap the component in a COM+ Application by using the COM+ Services Explorer.

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

  3. Deploy the COM+ component to the COM+ cluster. Remember to select Deploy COM+ applications in the deployment wizard, otherwise the component will not be deployed.

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

<script language=vbscript runat="server"> for n=1 to 50 set x=createobject ("YourComponent.YourClass") Response.Write "Component created on: " Response.Write x.GetName Response.write "<br>" set x=nothing next </script>

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

  2. Create an Application Center Application on the stager that includes the Default.asp file from step 5 and the COM+ component from step 1.

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

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

  5. Run Default.asp from a client computer. If it doesn't work initially, it may be the result of the IIS Service being restarted during component deployment. Wait a short while before trying again.

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

When to Use CLB

CLB is a great technology for building distributed solutions. However, there are times when using CLB may not be the best solution. The key issues are performance, scalability, and security. Understanding these issues will help build better cluster topologies.

Performance

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 give feedback to a user.

Both of these are related and CLB has its own issues related to them.

Throughput

Throughput performance declines when making any kind of call across a network. Using CLB obviously incurs this cost and this needs to be accounted for in making cluster architecture decisions. To give some perspective on this, the following data shows the number of calls per second on a single threaded Visual Basic 6 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.

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 be it through Microsoft software or otherwise. For this reason, CLB does not make a great solution where throughput is absolutely critical. In this case, it is better to install the COM+ components locally on the Web-tier cluster members, thus avoiding cross-network calls. CLB support is lost but load balancing is still available through NLB.

Figure 5: COM+ Components on the Web-tier

Figure 5: 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, then one solution is to move the COM+ components to a COM+ cluster tier. This will lighten the workload for the Web-tier cluster such that service time for clients not using COM+ components will be improved. For example, clients accessing static Web pages. 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 is to move the routing lists onto a separate COM+ routing cluster. This makes the workload for the Web-tier even lighter because no CLB-specific work will take place on it. Again, this is good for non-COM+ component work on the Web-tier but introduces even more performance degradation for COM+ components as a result of cross network calls.

It is clear that high performance & CLB do not necessarily go hand in hand and it is critical that Web site designers are aware of these limitations.

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 differing physical locations. Using a separate COM+ cluster allows independent management of the cluster. It is also possible to have a COM+ cluster that is 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 could potentially 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 seeking to take illegal advantage of the COM+ components installed on the cluster member. CLB allows this problem to be avoided by moving the COM+ components off of the Web-tier cluster onto a COM+ cluster. The COM+ cluster is usually protected by a firewall (Firewall B in Figure 6) and only allows components to be created from calls that have originated within the Web-tier cluster and not from the client. Figure 6 also shows a Demilitarized Zone (DMZ) protecting the Web tier through two encompassing firewalls.

Figure 6: COM+ Cluster behind a firewall

Figure 6: COM+ Cluster behind a firewall

Conclusion

CLB is a great technology for building distributed solutions, however care must be taken when using it. Throughput performance will be adversely affected by using it, but other advantages such as security, scalability, ease of set up, and load balancing make it a valuable tool. Used wisely it will help make great .NET-based solutions.

Resources

https://go.microsoft.com/fwlink/?linkid=591 - Latest information on Application Center.

Microsoft Application Center 2000 Resource Kit – Contains an in-depth look at Application Center. Gives further information on CLB, particularly deployment scenarios. Available soon.

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

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

https://www.microsoft.com/windows2000/library/howitworks/cluster/nlb.asp - Further information on Network Load Balancing.