Load Balancing in Distributed Objects Systems, an experience with COOL v2. P. Chatonnay
B. Herrmann
L. Philippe
F. Bourdony
Laboratoire d'Informatique de Besancon 16, route de Gray 25030 Besancon cedex - France tel : 81.66.64.64 email :
[email protected] http://comte.univ-fcomte.fr/www/PEOPLE/chatonnay/Chatonnay.html The aim of our study is to optimize the execution of distributed object-oriented applications, by positioning the component in a manner to optimize resources use. Placement of distributed applications is an open issue. In the context of distributed multiusers environments, where an application can not assume the behaviour of the others, placement must be directed by the system in order to optimize resources use. Indeed, the system can dynamically observe and compare the applications to propose a placement. Placement decisions must be driven from two main factors - computer and network load - to optimize distributed applications execution. In this paper we propose a model of distributed object-oriented applications execution and, using this model, an implementation of dynamic object placement for the COOL v2 system.
1 Context Most of the work done on load balancing or optimization to resources access, as been done on process granularity. Our work, on distributed object-oriented applications, is motivated by the following statements:
the conception of applications in distributed systems with object support is in full expansion
because the programming principles are well suited to the client-server approach (a client object makes call to methods of a server object present in the system). This concept assumes no reference to placement, which must be managed by the system. objects are small sized entities evolving in small sized contexts, thus allowing ne grained interventions on the applications. execution support for distributed object application allows two intervention level: at the language level (by code analysis) or/and at the execution level (by behaviour analysis). the OMG's standard [Con93] introduces the notion of IDL (Interface De nition Language) allowing standardisation of exchanges between objects. These interfaces facilitate collection of information on communication parameters. This is often a more dicult issue when load-balancing is based on processes [GHPS94]. Execution time of applications or reply time of servers can be minimized by providing to each object an environment where it could execute in the best conditions of resources access. Execution of LIB - Laboratoire d'Informatique de Besan con y SEPT - Service commun d'Etude de la Poste et
de France Telecoms
1
an object creates two consumption types: on the one hand the object consumes system resources (processor, memory, disc, network), on the other hand it consumes logical resources provided by other objects (servers). It seems important to take these two phenomenon into account to minimize the network trac and to balance the load between each site. For example, on sample client-server exchange, the server can be on the same site as its client (problem of processor load), or on a distant site (problem of communication network load). In these two cases it is necessary to manage the positioning to optimize the server answer time. In more complex application schemes, server objects can be clients of other servers. Targeted environments are composed of work stations and servers connected by network (heterogeneous and/or geographically wide).
2 The relational model The relational model is an observation system of dynamic systems, de ned from knowledge drift principles [Bou92]. Consider a dynamic system where entities communicate. It is possible to construct a relational space where each entity is represented by an object and where invocation between them is characterised by links joining object. These links are oriented - to show, in an invocation, the client entity and the server entity - and valued by the frequency and the volume of invocations - to take care of the importance of the relation. Note that the value evolves in functions of present invocations and also of anterior utilisation. In the following discussion, an analogy is made between arcs value and a notion of distance between objects of the model.
Object (mass)
Relational intensity
Altitude
Figure 1: Relational model. The relational space ( g. 1) contains an oriented, non connected, graph where nodes represent client or server entities and links represent interactions between these entities. All this space is under the action of entropy : links become looser if they are not \reactivated" by use (if no communication take place between client and server). By observing the relational space in a supposed stable initial state, it is possible to make emerge relational forms. A form is composed of an object and the totality of objects with which it is in relation in a stable manner. Because intensity of interactions between objects evolves, imbalances appear in relational forms. New balanced states are found by modifying (fusion or division) the relational forms. The relational space is oriented and each object in the space is characterised by an altitude and a mass. The altitude is calculated according to the current object altitude, its mass and the entropy. The mass is calculated according to the current object mass and the sum of mass of
object in relation pondered by the value of links between them. Globally, entities oat in a space. Entities that use each other come near from them, and, displace to the top of the space. Under the entropy action, links distend and entities derive to the bottom of the space. This model allows to envisage a short range prediction system of interaction between entities of the observed system. M. Tokoro proposes a similar model called computational eld model [Tok90]. In this model the author introduces notion of mass, distance, gravitational and repulsive force.
3 Overview of COOL v2. The COOL v2 system (Chorus Object Oriented Layer) [Jac94] provides an infrastructure to develop object oriented distributed applications above the Chorus micro-kernel. COOL is compliant with the OMG speci cation for the realisation of distributed object system. This layer adds notions of distribution, persistence and interoperability to the C++ language. The application space on the COOL system is structured by cluster, which are groups of objects build at the application level. A priori, objects allocated in a same cluster are strongly linked. In COOL v2, the location grain is the cluster and constitution of cluster is under the responsibility of the application programmer. So we are not sure that cluster are " well made " for our problem [Dic91]. Objects present inside a same cluster use normal method call to invoke mutually. To invoke an object allocated in an other cluster, it is necessary to have an interface object. An interface object is a local representative of the distant object, which contains a sub set of public methods of the represented object. An object can have several interfaces that are de ned by the programmer by used of the IDL. The method invocation can yet be done through the network: the system transforms the invocation of the interface object in a call to the server object. Interface objects o er an interesting observation point to determine communication needs of each object. COOL provides dynamic cluster migration, thus a support to dynamic cluster placement, fault tolerance and load balancing. This functionality is used by the load balancing service to get cluster closer or looser (on the same or on di erent sites).
4 Application environment We use the relational model as a base to the object positioning study. Each cluster of the system corresponds to a node of the model and link value is determined by observation of invocations between object through interface objects. Thus, the graph de nes a relational world which describe the real world where application are executed. Evolution of the real world entails modi cation of relational world and, therefore of relational forms de ned inside. If these modi cations became too important, this will lead to distortion between real world and relational forms. In this case, it is necessary to act on real world by displacing one or several objects. The displacement of these objects insures coherence between the relational and the real world. The relational model provides rules to adapt positioning of server objects and to get them closer to their most important clients. However, by limiting the observation to relations between objects, we would take in account just the consumption of logical resources. To take system constraints into account, we introduce new objects to describe hardware resources such as CPU, memory or disc, in the graph. To distinguish these two objects types we name \software objects" client or server objects and \system objects" hardware resources. Relation between a software object and a system object is de ned on the basis of the utilisation rate of the hardware resource by the software object. In a rst time, we use only limited information to calculate value on each link : frequency and volume of exchange. However, several information are interesting to introduce in this calculus. We
have planed to use more, but it is especially important to determine a good method to compose them and obtain a signi cant indicator, so we preferred to use sample values in a rst time. The value associated to a link is computed from the preceding value and the volume exchanged between the two objects during the last period. In our implementation, entropy is associated to a function of time and load of a site. It means that more a site is loaded more the value of links decrease rapidly. To collect information on objects, a server, called object manager, is loaded on each site of the network. The object manager maintains information about local clusters and their relations. Relation information are update directly by interface objects by call to a method of the object manager. The relational graph is shared between object servers. Periodically, object managers collect information on living clusters and their exchanges. Using these information, each server builds its part of the relational graph and analyse it. Then, object managers cooperate to balance load and place the clusters on the network. Decisions of migration are taken depending on relation variations. If an important variation is detected between a local cluster and a cluster on a distant site S, the object manager studies the ratio: LocalLoad(DistantCommunication ? LocalCommunication) DistantLoad If this ratio exceeds a threshold, the local cluster is migrated on the site S. In the case where a site is very lightly loaded, it is possible to send it a cluster realising few communications. By this way the load is balanced but the relational structure is not changed too much. This study is supported by the contract 95 1W 005, a common project between SEPT (Service d'Etude commun de la Poste et de France Telecom), the University of Franche-Comte (LIB) and the Chorus systems company.
References [Bou92]
Francois Bourdon. Un modele de derive des connaissances. PhD thesis, universite du Maine, Le Mans, Juillet 1992. [Con93] The OMG Consortium. The common object request broker: Architecture and speci cati on. Technical Report 93.12.29, Object Management Groupe, Farmington MA. USA, 1993. [Dic91] Peter Dickman. E ective load balancing in a distributed object-support operating system. IEEE, 1991. [GHPS94] Herve Guyennet, Benedicte Herrmann, Laurent Philippe, and Francis Spies. A performance study of dynamic load balancing algorithms for multicomputers. In IEEE Ed., editor, MPCS'94, Ischia, Italie, May 1994. [Jac94] Christian Jacquemot. Chorus/cool v2 reference manual. Technical Report CS/TR-9416, Chorus system, 1994. [Tok90] Mario Tokoro. Computational eld model: Toward a new computing model/methodology for open distributed environment. June 1990.
