Strategies for CORBA Middleware-Based Load Balancing
(来源：http://computer.org)


Ossama Othman, Carlos O'Ryan, and Douglas C. Schmidt
University of California, Irvine

The growth of online Internet services during the past decade has increased the demand for scalable and dependable distributed computing systems. E-commerce and online stock trading systems are examples. These systems concurrently serve many clients that transmit a large, often "bursty," number of requests and have stringent quality of service requirements. To protect hardware investments and avoid overcomitting resources, such systems scale incrementally by connecting servers through high-speed networks.

An increasingly popular and cost effective technique to improve networked server performance is load balancing, where hardware or software mechanisms determine which server will execute each client request. Load balancing helps improve system scalability by ensuring that client application requests are distributed and processed equitably across a group of servers. Likewise, it helps improve system dependability by adapting dynamically to system configuration changes that arise from hardware or software failures. Load balancing also helps ensure all resources are used efficiently and that new servers are purchased or cycles are leased only when necessary.

This article describes the strategies and architectures for CORBA load balancing, introduces a CORBA load balancing service we designed, and provides performance benchmarks. A second installment of this article (appearing in the April 2001 issue of DS Online) provides more detail regarding the specific load balancing service we designed using TAO?he ACE (Adaptive Communication Environment) ORB.

Load balancing for distributed systems
Load balancing mechanisms distribute client workload equitably among back-end servers to improve overall system responsiveness. These mechanisms can be provided in any or all of the following layers in a distributed system:

Network-based load balancing: IP routers and domain name servers that service a pool of host machines provide this type of load balancing. For example, when a client resolves a hostname, the DNS can assign a different IP address to each request dynamically based on current load conditions. The client then contacts the designated back-end server, unaware that a different server could be selected for its next DNS resolution. Routers can also bind a TCP flow to any back-end server based on the current load conditions and then use that binding for the duration of the flow. High volume Web sites often use network-based load balancing at the network layer (layer 3) and transport layer (layer 4). Layer 3 and 4 load balancing (referred to as switching1) use the IP address/hostname and port, respectively, to determine where to forward packets. Load balancing at these layers is somewhat limited, however, because they do not take into account the content of client requests. Instead, higher-layer mechanisms?he so called layer 5 switching described below?erform load balancing in accordance with the content of requests, such as pathname information within a URL.
OS-based load balancing: Distributed OSs provide this type of load balancing through clustering, load sharing (load sharing should not be confused with load balancing; for example, processing resources can be shared among processors but not necessarily balanced), and process migration2 mechanisms. Clustering is a cost effective way to achieve high availability and high performance by combining many commodity computers to improve overall system processing power. Processes can then be distributed transparently among computers in the cluster. Clusters generally employ load sharing and process migration. Process migration mechanisms balance load across processors?r, more generally, across network nodes?y transferring the state of a process between nodes.3 Transferring process states requires significant platform infrastructure support to handle platform differences between nodes. It can also limit applicability to programming languages based on virtual machines, such as Java.
Middleware-based load balancing: This type of load balancing is performed in middleware, often on a per-session or per-request basis. For example, layer 5 switching1 has become a popular technique to determine which Web server should receive a client request for a particular URL. This strategy can also detect "hot spots"?requently accessed URLs?o that additional resources can be allocated to handle the large number of requests for such URLs.
Advantages of middleware-based load balancing
Network-based and OS-based load balancing architectures suffer from several limitations including lack of flexibility and adaptability. The lack of flexibility arises from the inability to support application-defined metrics at run time when making load balancing decisions. The lack of adaptability occurs due to the absence of load-related feedback from a given set of replicas (duplicate instances of a particular object on a server that is managed by a load balancer), as well as the inability to control if and when a given replica should accept additional requests. Neither network-based nor OS-based load balancing solutions provide as straightforward, portable, and economical a means of adapting load balancing decisions based on application-level request characteristics, such as content and duration, as middleware-based load balancing does.

In contrast, middleware-based load balancing offers several advantages over network- or OS-based load balancing. Middleware-based load balancing architectures?articularly those based on standard CORBA4?ave the following advantages:

Middleware-based load balancing can be used in conjunction with specialized network-based and OS-based load balancing mechanisms.
It can also be applied on top of commodity-off-the-shelf networks and OSs, which helps reduce cost.
In addition, it can provide semantically-rich customization hooks to perform load balancing based on a wide range of application-specific load balancing conditions, such as runtime I/O versus CPU overhead conditions.
This article focuses on middleware-based load balancing supported by CORBA object request brokers. ORB middleware lets clients invoke operations on distributed objects without concern for object location, programming language, OS platform, communication protocols and interconnects, and hardware.5 Moreover, ORBs can determine which client requests to route to which object replicas on which servers.

An example of CORBA middleware-based load balancing
To illustrate the benefits of middleware-based load balancing, consider the following CORBA-based online stock trading system (see Figure 1). A distributed online stock trading system creates sessions through which trading is conducted. This system consists of multiple back-end servers (replicas) that process the session creation requests that clients send over a network. A replica is an object that can perform the same tasks as the original object. Server replicas that perform the same operations can be grouped together into back-end server groups, which are also known as replica groups or object groups.




Figure 1. A distributed online stock trading system places heavy demands on resources while requiring instantaneous scalability and 24-7 dependability.

Figure 1 replicates a session factory6 in an effort to reduce the load on any given factory. The load in this case is a combination of the average number of session creation requests per unit time and the total amount of resources employed currently to create sessions at a given location. Loads are then balanced across all replicas in the session factory replica group. The replicas need not reside at the same location.

The sole purpose of session factories is to create stock trading sessions. Therefore, factories need not retain state, (they are stateless). Moreover, in this type of system, client requests arrive dynamically?/FONT>not deterministically?nd the duration of each request many not be known a priori.

These conditions require that the distributed online stock trading system redistribute requests to replicas dynamically. Otherwise, one or more replicas might become overloaded while others will be underutilized. In other words, the system must adapt to changing load conditions. In theory, applying adaptivity in conjunction with multiple back-end servers can

increase the system's scalability and dependability;
reduce the initial investment when the number of clients is small; and
let the system scale up gracefully to handle more clients and processing workload in larger configurations.
In practice, achieving this degree of scalability and dependability requires a sophisticated load balancing service. Ideally, this service should be transparent to existing online stock trading components. Moreover, if incoming requests arrive dynamically, a load balancing service might not benefit from a priori QoS specifications, scheduling, or admission control and must therefore adapt dynamically to changes in runtime conditions.