Intelligent and Modular Load-Balancing CORBA Naming Service

Transcription

1 Intelligent and Modular Load-Balancing CORBA Naming Service Brecht Vermeulen, Christophe Gardelein, Bart Dhoedt, and Piet Demeester Ghent University, Department of Information Technology, Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium Abstract. In today s distributed systems, some challenges keep on returning in various applications and environments. Two of them, loadbalancing of requests and fault tolerance can partly be tackled by the proposed load-balancing CORBA Naming Service. This Naming Service can dynamically load new load-balancing algorithms which can also be intelligent, e.g. interact with the object servers to determine the best object reference before returning an object reference to the client. Four algorithms are already implemented: Round-Robin, Random and also two intelligent algorithms which determine the roundtrip time or hopcount between object server and client and return the object reference of the closest object to the client. 1 Introduction and Motivation Distributed systems are today widespread in a lot of domains and various applications. Different software techniques are used to cope with the different demands, but some problems and challenges keep on returning in all those environments. Two of them, load-balancing of requests and fault tolerance are issues which are tackled by the proposed load-balancing CORBA Naming Service, in particular then for a CORBA based distributed system. The CORBA Naming Service is a kind of central database which contains references to distributed objects which can be looked up by the use of names. Typically when a distributed system starts up, objects register themselves at the Naming Service and clients request initially references to those objects and then send their requests directly to those objects. In the Object Management Group (OMG) standardized CORBA Naming Service, there is a one-one relation between object names and object references. By extending the Naming Service for load-balancing however, multiple objects can be related to one (group) name. If a client (which is unaware of the load-balancing) then requests the object reference for a particular name, the Naming Service has to choose to return a particular object reference. For this choice, different methodologies are possible. The most well-known algorithms for chosing an object reference to return are round-robin and random

2 2 which can be found in several implementations ([4] and [5]) of a load-balancing CORBA Naming Service. Both will tend, in the limit, to an equal number of choices for each separate object reference. This research however, is focussed on making the load-balancing of object references more intelligent and generic. The first goal is being accomplished by making interaction possible between the Naming Service and the objects and as such make it possible to return an object reference to a client based on more complex decisions, e.g. the object which is closest to the client. To provide more generic load-balancing, new algorithms with new functionality can be plugged in and removed from a running Naming Service. As such also automatic failover can be implemented if clients are slightly adapted (e.g. if their design currently not foresees into this exception handling) to request for a new object reference when a certain object is unreachable. The intelligent Naming Service can be as smart to continuously check the status of the objects as such only returns valid references to the clients. Keeping the state of the different objects synchronized is however not the task of the Naming Service as it is object specific and can be done in various ways. The paper is further organized as follows. Section 2 describes shortly the IDL interfaces of the OMG standardized CORBA Naming Service. Section 3 elaborates in detail on the proposed load-balancing Naming Service framework while Section 4 discusses the performance of the prototype. The last sections discuss applications, related work and Section 7 concludes the paper. 2 Standard CORBA Naming Service To outline the context and to make the differences with the existing standard functionality of the CORBA Naming Service more clear, a short overview of the CORBA Naming Service as currently standardized by the OMG will be given. The basic structure of the CosNaming IDL interface is shown in Figure 1. The basic structure is rather simple and similar to a tree-based directory structure of an operating system. There are NamingContexts (which are actually also CORBA objects themselves) which can contain object references or other NamingContexts. As such, a tree is created of which the leaves are object references. Generally, one can speak of Bindings 1 which are then either object references or NamingContexts. The operational interfaces NamingContext and BindingIterator exist of a number of operations. On a NamingContext one can bind and unbind object references and NamingContexts and of course also resolve object references. The BindingIterator interface is used when browsing a particular NamingContext to list all of the bindings. Almost all existing CORBA implementations include also a Naming Service and we chose omniorb [2] for our implementation, as it has been tested several times as one of the fastest and smallest ORBs around [3] and because it is Open 1 In struct Binding, binding name is incorrectly defined as a Name instead of a Name- Component. This definition is unchanged for compatibility reasons.

3 3 typedef string Istring; struct NameComponent { Istring id; Istring kind; } typedef sequence<namecomponent> Name; enum BindingType { nobject, ncontext struct Binding { Name binding_name; BindingType binding_type; } typedef sequence<binding> Bindinglist; interface NamingContext {... } interface BindingIterator {... } Fig. 1. Part of the OMG standardized CosNaming.idl, see [1] Source. omniorb has extended the CosNaming.idl definition with an extra, omniorb specific, interface called NamingContextExt which contains operations which convert strings to NameComponents and vice versa. 3 Load-Balancing CORBA Naming Service 3.1 Object Groups The basic idea of introducing load-balancing functionality is by defining the concept of Object groups which can contain multiple object references bound to the same group name. This idea can also be found in other solutions as e.g. Iona Orbix [4]. As such, there are now three types of bindings one can find in a Context (see Figure 2): object references, NamingContexts and Object Groups. Because of this new functionality and the design requirement to be backwards compatible (a.o. to make it possible that clients are unaware of the load-balancing) a new IDL interface NamingContextLoadBalancing is defined which inherits from the omniorb specific NamingContextExt interface. This new interface has of course the same functionality as a NamingContext but adds the load-balancing specific variables and operations (see Figure 3). The operations create group and delete group add or delete a load-balancing group to this NamingContext. The name of the algorithm for the load-balancing can also be specified for this group. list available algorithms is used to get an overview of all registered load-balancing algorithms in the Naming Service. list groups, find group and LBlist are used to browse the NamingContext while supporting Object groups. The Object group itself is defined in the interface LBgroup (Figure 4) and the operations make it possible to do the management of the object references

4 4 Fig. 2. Example of a load-balancing Naming tree with Naming Contexts, Object Groups and object references within an Object group and also to change the used load-balancing algorithm for this particular group. The operation pick returns an object reference out of the group chosen by the current algorithm. This operation is a.o. called if resolve is called by a client on a NamingContextLoadBalancing for a name related to an Object group. The interfaces LBBindingIterator and ObjectIdIterator are used similarly as the BindingIterator interface in the standard Naming Service. 3.2 Intelligent Load-balancing algorithms As described in the previous section, for each Object group a different loadbalancing algorithm can be specified. The following algorithms have been developed so far. Round-Robin which runs in a cyclic way through the list of object references. The Random algorithm choses randomly references out of the group. Also two intelligent algorithms have been implemented. When IP-based- RoundTrip is defined for a certain Object group, each CORBA object in the group (in parallel) gets the order to ping (an ICMP request and reply) to the IP number of the client and to report back the roundtrip delay to the Naming Service, so that the algorithm can return the object reference of the object which is closest (in delay) to the client. IP-based-hops is similar but here the number of hops between object and client (based on the Time-to-Live field of the ICMP reply packets) instead of roundtrip delay is used as a distinguishing parameter. It is obvious that these intelligent algorithms are much more complex than the simple Random or Round-Robin algorithms as they require interaction between the Naming Service and the CORBA objects before an object reference can be returned to the client. Figure 5 shows this interaction: 1. The client asks the Naming Service for an object reference.

5 5 module CosNaming { typedef string Algorithm; typedef sequence<algorithm> AlgoList; interface NamingContextLoadBalancing : NamingContextExt { enum LBBindingType {nobject, ncontext, ngroup struct LBBinding { Name binding_name; LBBindingType binding_type; typedef sequence <LBBinding> LBBindingList; LBgroup create_group( in Algorithm AId, in NameComponent nc ); void delete_group( in NameComponent nc ); AlgoList list_available_algorithms(); void list_groups (in unsigned long how_many, out LBBindingList bl, out LBBindingIterator bi); LBgroup find_group(in NameComponent nc); void LBlist (in unsigned long how_many, out LBBindingList bl, out LBBindingIterator bi); Fig. 3. The extended NamingContextLoadBalancing. For clarity exception definitions are omitted module CosNaming { interface LBgroup { typedef string ObjectId; typedef sequence<objectid> ObjectIdList; typedef sequence<any> ParameterList; void add_member(in ObjectId id, in ParameterList pl, in Object ob); void remove_member(in ObjectId id); void list_members (in unsigned long how_many, out ObjectIdList oil, out ObjectIdIterator oii); Object find_member(in ObjectId oid); Object pick (); void set_selection_algorithm(in Algorithm algo); Algorithm get_selection_algorithm(); Fig. 4. Interface LBgroup. For clarity exception definitions are omitted

6 6 2. The Naming Service sends a request to the PollObject interface of each CORBA server for the needed parameters (dependent of the algorithm, these can be e.g. current CPU load, roundtrip delay to the client,... ). When the CORBA servers register their objects, they give a reference to their local PollObject interface to the Naming Service (in the ParameterList of the add member operation of the LBgroup). 3. If needed, the object server pings the client machine to know e.g. roundtrip delay or number of hops between server and client. 4. The object servers report the result back to the CallBackObject interface of the Naming Service. 5. The Naming Service choses the best object reference based on the algorithm and the parameters and returns the object reference to the client. Fig. 5. Mechanism of intelligent load-balancing algorithm This interaction needs of course some detailed explanation. The PollObject interface is listed in Figure 6 and contains only one operation used to give the order for the start of a measurement. The parameters are the OperationName (there is only one or a few PollObject objects for each object server, so they can support multiple tests.). The ObjectServerID which is assigned by the Naming Service uniquely for each PollObject and has to be used to report the results back to the CallBackObject of the Naming Service. The ParameterList is used dependent on the used algorithm, e.g. for the IP-based-RoundTrip and IP-basedhops it contains the IP address of the machine where the client runs 2. The last 2 In fact one of the features of CORBA is making network addressing transparant for the programmer, but by using the Server Receive Request CORBA interceptor

7 7 argument is the reference to the CallBackObject in the Naming Service. This CallBackObject interface (also listed in Figure 6) is very simple and has one operation to report the results of the tests. Differentiation between the different CORBA servers is done by the ObjectServerID. To make these interactions as generic as possible, the parameters and results are defined as sequence<any> which makes it possible to use any data. E.g. other algorithms that could be implemented are weighted round-robin or CPU-load based load-balancing. For the first algorithm, servers could specify a weight in the ParameterList of the add member operation for their object(s) when registering, so that the Naming Service can use weighted round-robin. For this algorithm no further interaction is needed between Naming Service and object servers. A CPU-load based algorithm would be similar to the IP-based algorithms, except that for step 3 (see above) no ping action to the client would be done, but a CPU-load measurement on the CORBA server machine. It could even be improved and made more scalable by making the Naming Service algorithm polling the CPU-loads on a regular basis, so that the best object reference could be returned immediately by the Naming Service. This improvement is not immediately possible with the IP-based algorithms because the clients are not known on beforehand. interface PollObject { typedef string OperationName; typedef unsigned short ObjectServerID; typedef sequence<any> ParameterList; void StartTest ( in OperationName name, in ObjectServerID id, in ParameterList pl, in Object callback_object ); interface CallBackObject { typedef sequence<any> ValueList; typedef unsigned short ObjectServerID; void CommitResult ( in ValueList vlist, in ObjectServerID id ); Fig. 6. Interfaces PollObject and CallBackObject used for the intelligent algorithms in omniorb, a CORBA server can detect the IP address of the client issuing the request.

8 8 3.3 Dynamic loading of algorithms To make it easy to develop and install new load-balancing algorithms, the framework is based on dynamic loading of algorithms. To accomodate this, Dynamic C++ classes [6] are used because they are platform independent, C++ oriented and targeted to performance-critical applications. Dynamic classes allow run-time updates of an executing C++ program at the class level. As such, all algorithms are a new implementation of the class Algorithm which has a fixed interface. Of this class, various versions (the different algorithms) can exist next to each other in the running Naming Service and can be loaded and unloaded dynamically. Therefore an extra CORBA interface AlgorithmServer has been specified for the Naming Service which is listed in Figure 7. The operations RegisterAlgorithm and UnregisterAlgorithm can be called by command line applications (even remote as this is also a CORBA interface) to install or remove algorithms. module CosNaming { interface AlgorithmServer { typedef string Filename; void RegisterAlgorithm (in Filename f1); void UnregisterAlgorithm (in Algorithm al); AlgoList list_available_algorithms (); Fig. 7. Interface AlgorithmServer to dynamically load new algorithms The framework with all the defined CORBA IDL interfaces which are involved with these intelligent algorithms is depicted in Figure 8. 4 Performance A CORBA Naming Service is not that performance critical as object references are only bound and resolved on rare occasions. However, it is interesting to have an idea about the performance of this service as it can give an idea about the applications which are proposed in the next section where the resolving of object references is more frequent, e.g. for better load-balancing and fault tolerance. In particular also the performance differences with and without our extensions were studied. In the measurements (Figure 9), 3 different versions of the Naming Service were under test: the original standard omniorb Naming Service, the non-optimized load-balancing Naming Service (based on linked lists) and the optimized load-balancing Naming Service (based on STL hash-maps and vectors).

9 9 Fig. 8. Complete framework with all object interfaces. The first test done was registering 1000 object references and then resolving the 0th, the 500th and the 1000th object reference. We see clearly that for the optimized version the response time is around 330µs independent of the request reference. The second test studied the influence of the number of clients (while doing continuously resolves on the Naming Service) while the third test shows the memory use in relation to the number of objects which are registered. This last test shows a memory use which is around 1650 kb higher for the loadbalancing Naming Service. This is mostly related to the use of the CORBA any datatype which needs an extra library in omniorb. 5 Applications A load-balancing Naming Service can have different applications. The IP-based algorithms that were implemented are being used in a CORBA based network management where a big layer network can be managed by logically one component, which is physically embodied by multiple components. Neighboring domains can then contact the right CORBA object which is closest [7]. Other applications include of course load-balancing, but instead of only resolving object references initially, clients can regularly resolve object references so that the load-balancing gets better. As such, the Naming Service can also detect via the PollObject interface of the object servers, if the servers are still running or if they are unreachable, and adapt the object groups accordingly.

10 10 Fig. 9. Performance of the standard and the extended Naming Service (optimized and not optimized). This last application can also be used in the direction of fault tolerance by making clients resolve new object references if operations on existing object references fail or time-out. 6 Related work Orbix [4] and TAO [5] contain both (related) load-balancing extensions to their Naming Service, but these are only Round-Robin and Random algorithms of which the parameters are specified in the IDL interfaces. These implementations are thus not developed in a generic way and as such new algorithms cannot be loaded easily in those Naming Services. Intelligent algorithms, as described in this paper, are also not available. 7 Conclusion This paper describes a generic framework for dynamically plugging in intelligent load-balancing algorithms in a CORBA Naming Service (the prototype was based on the omniorb Naming Service). Intelligent means that there can be interaction between the Naming Service and the CORBA servers, e.g. to measure the CPU load of the CORBA servers before an object reference is returned to a client. To prove the working prototype, four algorithms were already

11 11 developed: a Round Robin and Random algorithm and also two intelligent algorithms which check the distance between CORBA objects and clients (based on roundtrip time and hop count) before returning an object reference to a client. Also different applications were highlighted. Acknowledgments Part of this work has been supported by the European Community through the IST research program in the IST project HARMONICS. References 1. Object Management Group (OMG): CosNaming.idl. formal/ idl 2. omniorb: 3. Distributed Systems Research Group: CORBA Comparison Project, ms.mff.cuni.cz/~bench/, Charles University, Prague. 4. Orbix: 5. TAO: 6. Hjalmtysson, G., Gray, B.: Dynamic C++ classes: A lightweight mechanism to update code in a running program. Proceedings of the USENIX Annual Technical Conference (NO 98) New Orleans, Louisiana, June Vermeulen, B., Vanhastel, S., Wellen, J., Mas, C., Dhoedt, B., Demeester, P.: A Generic End-to-end Distributed QoS Management Architecture and its Application to IP-DiffServ over a WDM Access Feeder Network. NOMS 2002, Florence, April 2002.