INFO: How Microsoft Transaction Server 2.0 Handles Load Balancing

ID: Q230330


The information in this article applies to:


SUMMARY

Microsoft Transaction Server (MTS) 2.0 does not support dynamic load balancing. As an alternative, the more rudimentary form of static load balancing can be indirectly implemented for MTS components.


MORE INFORMATION

Load balancing schemes fall into two classifications: Dynamic and Static.

Dynamic load balancing implies the operating system or MTS uses an applicable algorithm at runtime to dynamically determine which MTS server to route clients request based on current load. This is the preferred mechanism as it provides the most flexibility and accuracy, but it is currently not implemented in the operating system nor in MTS.

In contrast, static load balancing does not make routing decisions based on dynamic load information. Rather, routing criteria are preset ahead of time and are based upon entitities more static in nature, such as a user's name, IP address, client machine name.

Static load balancing is the only choice available today. There is no set way with which to implement it because it's an application dependent decision that must be made ahead of time based on crude usage data. Below are some suggestions of how it could be done.

First let's look at DCOM clients. Suppose there are two MTS servers on which you want to distribute the client load. Each server exports the (same) MTS package to generate a client configuration utility executable for each of the two server machines into the \clients subdirectory of the exported package. This executable is then distributed to (possibly via e-mail or the Web) each client machine. When run on the client, the proper DCOM registry entries are made to allow the client program to instantiate the remote object on the correct server.

Assume DCOM client machines 1 through 10 run the client configuration utility for MTS Server1 and client machines 11 through 20 do so for MTS Server2. When the DCOM application is run on clients 1-10, the remote component will be instantiated on MTS Server 1, and 11-20 on MTS Server 2 in a transparent fashion.

Another alternative is to do the routing via an Active Server Pages (ASP) page. Using the Request.ServerVariables collection, script code can route users requests to different MTS servers based on certain application specific criteria, or in a round robin fashion.

At a higher level, User1 could be directed to a Web page that instantiates components on MTS Server1 and User2 would be directed to a Web page that instantiates them to MTS Server 2.

Microsoft development is considering dynamic load balancing as a feature in future releases.

© Microsoft Corporation 1999, All Rights Reserved.
Contributions by Paul Bates, Microsoft Corporation

Additional query words:


Keywords          : kbMTS200 kbWinDNA kbGrpSIE 
Version           : winnt:2.0
Platform          : winnt 
Issue type        : kbinfo 

Last Reviewed: June 25, 1999