An Overview of CORBA-Based Load Balancing

Transcription

1 An Overview of CORBA-Based Load Balancing Jian Shu, Linlan Liu, Shaowen Song, Member, IEEE Department of Computer Science Nanchang Institute of Aero-Technology,Nanchang, Jiangxi, P.R.China Department of Physics and Computing Wilfrid Laurier University,Waterloo, On, Canada N2L 3C5 Abstract. The Common Object Request Broker Architecture (CORBA) compliant load balancing mechanism has caught the attention of many researchers in recent years. Load balancing is an issue, which has to be concerned in CORBA architecture. In this paper, we provide an overview of CORBA-based load balancing mechanism. We discuss its requirements, policies, strategies, as well as the pros and cons. We address these issues from the aspects of design, load monitoring, load balancing algorithm, and load migrating. 1 Introduction 1 The fast increasing of data management and processing in distributed computing environment (DCE), including the Internet based distributed computing, has resulted in tremendous amount of computing tasks in the system. In many circumstances, the loads on the nodes are not well distributed, which leads to the overloading of some processors, while other nodes may well be in ideal status. This situation results in low system performance and throughput. In order to improve the overall performance and increase in the system throughput, a popular and cost-effective way is to employ some kind of load-balancing mechanism in distributed systems. The load balancing algorithms can reallocate the workload based on system state information so that each node in the system gets approximately equal amount of workload. In general, load balancing can be implemented in three configurations [1]: 1) network-based load balancing -- it can be implemented via the DNS (Domain Name Service), a proxy server, or an address switching gateway; 2) operating system based load balancing -- workload can be redistributed through clustering, load sharing, or process migration mechanisms; 3) middleware-based load balancing -- an objectoriented approach that the computing for load balancing can be performed at any node 1 The paper is supported by Jiangxi Nature Science Funding and Jiangxi Testing and Control Funding.

2 Jian Shu, Linlan Liu, Shaowen Song, Member, IEEE in the system., CORBA is one of the major software architectures of this kind. Load balancing discusses in this paper is middleware-based. This paper is organized into 6 sections. Following this introduction, in Section 2, the requirements of CORBA-based load balancing are discussed. The load monitoring, load balancing algorithms, and load migrating are addressed in Sections 3, 4, and 5 respectively. Finally, we present some concluding remarks in Section 6. 2 The requirements of CORBA-based load balancing CORBA was proposed by OMG in It offers a complete object-oriented, interoperable, platform-independent environment. Load balancing implemented in CORBA should satisfy the following requirements [2]: Object-oriented: Because CORBA is a complete object-oriented, the load balancing mechanism based on CORBA should comply with object-oriented convention. Low latency: Latencies occur in many situations, such as the response for collecting information of objects, clients, and servers, as well as communicating among objects. A satisfied load balancing mechanism should minimize these latencies in order to preserve the performance of the system. Transparent: A CORBA load balancing service should keep transparent, that is, it has to interfere as little as possible with the execution of client applications and server applications. And it can comply with clients and servers without the requirement of changes. Heterogeneous: CORBA supports heterogeneous computing architectures. Therefore, load balancing in CORBA has to have the ability to deal with heterogeneous loads and hosts. Also, different types of applications may have different definition of workload. Therefore, CORBA load balancing should be able to evaluate different loads without any restrictions to the clients. This is also the requirement of transparency. Scalable: Load balancing in CORBA should maximize the system scalability through fully utilizing the resources of group servers whose resources have not been made use of efficiently. The information should be accessible from any host. For the reason of scalability, CORBA load balancing should not depend on the extensions to GIOP/IIOP, and on the extensions to an ORB as well. Fair: The balancing algorithm should be fair, as much as possible, to all objects. Adaptive: Load-balancing service should allow new replicas to be added to or removed from the system. These changes also result in the change of the whole system. CORBA load balancing should be adaptive to these changes automatically. Request independent: There are different request patterns from the clients. Some requests arrive at deterministic or stochastic rates with the duration of execution being known. While some others are dynamic with the duration being unknown known before the execution. A good load balancing service should support these various client request patterns, without any or minimal limitations to the clients.

3 An Overview of CORBA-Based Load Balancing 3 Load Monitoring Workload monitoring is to collect the load information from a distributed system. The data collected are used for evaluating load distribution to determine whether the workloads are off the balance. As mentioned in Section 1, the load balancing service discussed in this paper is a middleware-based. Usually, there are two ways to monitor middleware [3]: 1) interception -- the monitor intercepts the middleware data and analyze the contents. This approach can increase transparency; and 2) integration -- hooks are added into the middleware itself to inform the monitoring runtime of some events. This approach will impact the transparency of load balancing. In the ORB-based load balancing, load monitoring can be achieved by either integrating the function into ORB itself or adding hooks to it. For example, in [4], the load balancing service is implemented by replacing the default locator with another one which has load balancing functionalities. An ORB-based monitoring is also presented in [5], in which hooks are added into the ORB to intercept invoke calls. The advantage of ORB-based approach is that the overhead of communication is reduced. The disadvantage is that the load distribution depends on a specific ORB. Therefore, the transparency in this scenario is impacted. In the service-based scenario, load monitoring is usually fulfilled by naming service or event-service. If it is name service-based, each servant objects registers with name service. Every request has to get an object reference via name service, that is, it asks the name service for the reference to the service. Therefore, the monitoring can be done by supervising the request. A CORBA naming service based monitoring is presented in [6], while [7] and IONA's Orbix are based on extended naming service. When event service-based monitoring is used, CORBA event service defines a framework for decoupled and asynchronous message passing between distributed objects [8]. In this case, an event channel is established which is responsible for the communication between consumer objects (clients) and supplier objects(servers). The load is monitored by supervising the event channel. An example of using extended CORBA event service to achieve load monitoring is presented in [9]. The information collected in load monitoring is used for load evaluating. Usually, a threshold policy is adopted to determine the status of load distribution. The thresholds are expressed in units of load [10]. When workload exceeds its threshold, a loadbalancing algorithm is triggered in order to re-balance workload among the stations. 4 Load Balancing Algorithms When designing load-balancing algorithms, many factors, such as load distribution area and control mode, need to be considered. We discuss the policies and strategies [10] which should be taken into account in load balancing algorithms in this section. Global algorithm or local algorithm. In local algorithms, object loads are redistributed among hosts in the neighborhood when workload related to a certain object exceeds its threshold. In global algorithms, object loads are redistributed in the

4 Jian Shu, Linlan Liu, Shaowen Song, Member, IEEE entire system rather than the ones in the neighborhood. The objective, in this case, is to achieve the whole system load balancing after computing loads on entire system. Centralized algorithm or decentralized algorithm. In centralized algorithms, there is a central controller which is responsible for collecting system status information and making the load balancing. The implementation presented in [1] falls into this category. In decentralized algorithms, there is no central load balancer, while the load balancing mechanism is distributed. The implementation presented in [9] falls into this category. Adaptive algorithm and non-adaptive algorithm. In adaptive algorithms, loadbalancing policies vary with the changes of system state. When imbalance occurs, according to this load change, the load balancer will request replica redirect clients back to it, and then it redirects the clients to a less load replica. Load balancing policies leave unchanged when system state changes in non-adaptive algorithm. Selection policy. In order to balance the load, load balancer has to select a most suitable request to a proper object. The simplest way is to select the newly generated request which causes the host over load, because the overhead to transfer this kind of request is relative low. There is another approach, such as the one mentioned in [1], which redirects a running request to a proper replica. Profitability policy. Let Φ(t) denote the imbalance factor at time t, and φ(t) denote the balancing overhead. Φ(t) is the function of the difference between the maximum object load before and after load balancing. Therefore, when Φ(t) is great than φ(t), we consider that the load balancing is profitable. Location policy. This policy is to determine which object or replica is the suitable one to share the client request when unbalance happens. A popular method to find a suitable object is polling. For local polling, only objects on neighboring hosts are candidates. For global polling, all objects on system are polling candidates. Another way is to broadcast a query to see if any object or replica is available for load sharing. Load balancing algorithm is usually studied with graph coloring method. Generally speaking, there are two kinds of load balancing algorithm: nearest neighbor and direct approaches [10]. Nearest neighbor approach is based on successive approximation by exchanging load among neighboring hosts to achieve the whole system load redistribution. The challenger of this method is to design a fast iterative scheme. The direct approach exchanges load after it figures out senders and receivers. The challenger of this method is to match potential senders and receivers quickly. Some common load balancing algorithms, such as diffusion, dimension exchange, and gradient are addressed in detail in [10]. 5 Load Migrating Load migration is to transfer the extra load from an overloaded node to its proper destination. There are two issues needed to be dealt with in this procedure--initiation and granularity: Initiation: Usually, there are two methods to initiate the migration [10]--senderinitiated and receiver-initiated. In the case of sender-initiated migration, the overloaded party is in charge of searching potential object or server replica. There are

5 An Overview of CORBA-Based Load Balancing two widely used approaches for sender to select its destination: one is randomly and the other is sequentially. Fig. 1 shows a sender-initiated migration scenario. In the case of a receiver-initiated migration, the underloaded party is responsible for selecting overloaded ones to accept their extra load. Once the load on receiver is less than a certain amount, it will send request to other objects to see if there is any extra load to receive. In some cases, a tradeoff approach, symmetrically-initiated, is employed, which is a combination of sender-initiated and receiver-initiated. Fig. 1. Sender-initiated migration Granularity: The granularity of migration can fall into two categories: strong migration and weak migration. Strong migration means that both the entity and its state are transferred to their destination together. Weak migration means that only the executable part and some related data are transferred. When designing migrating mechanism, there are two important factors which should be taken into account-- atomicity and consistency. Atomicity means that the migrated request can be restored if the transfer is failure. Consistency means that the execution of the migrated request on destination should keep unchanged when compared with the one on original server. 6 Concluding Remarks CORBA is a prominent software architecture. It has been used in many applications and shows its great benefit. In this paper, we provide an overview of CORBA

6 Jian Shu, Linlan Liu, Shaowen Song, Member, IEEE compliant load balancing mechanisms, including general requirements, load monitoring and evaluation, load balancing algorithm, and load migrating. Although many researches have been accumulated in the literature, CORBA-based load balancing is still in development stage. Reference 1. Ossama Othman, Carlos O'Ryan, and Douglas C. Schmidt: An Efficient Adaptive Load Balancing Service for CORBA, 2. Ossama Othman, Carlos O'Ryan, and Douglas C. Schmidt: The Design of an adaptive CORBA Load Balancing Service, IEEE Distributed Systems Online, vol. 2, (2001) 3. Erik Putrycz, Guy Bernard: Client Side Reconfiguration on Software Components for Load Balancing, In Proc. International Workshop on Distributed Dynamic Multiservice Architecture, in conjunction with IEEE International Conference on Distributed Computing Systems (ICDCS'2001), Phoenix, Arizona, (2001) Gebauer,C.: Load Balancer LB-a CORBA component for load balancing, Diploma thesis, University of Frankfurt(1997) 5. C.Grant, P.Merle, and Geib J. Goodewatch: Supervision of Corba Applications. In ECOOP'99 Workshop, Lisbon, Portugal(1999) E.Damiani: An Intelligent Load distribution System for CORBA-compliant Distribution Environments, 1999 IEEE International Fuzzy System Conference Proceedings, Seoul,Korea(1999) T.Barth, G. Flender, B. Freisleben, F. Thilo: Load Distribution in a CORBA Environment, Proceedings of the International Symposium on Distributed Objects and Applications (DOA'99), Edinburgh, Scotland(1999) Object Management Group. CORBA services: Common Object Services Specification, Kei Shiu Ho, Hong Va Leong: An Extended CORBA Event Service with Support for Load Balancing and Fault-Tolerance, International Symposium on Distributed Objects and Applications, Antwerp, Belgium(2000) Jie Wu, " Distributed System Design", CRC Press(1999)