In modern distributed computer systems (clusters and computing GRIDs) a new class of problems, due to the increasing heterogeneity of users’ needs, have to be tackled by the administrators. One possible solution is to create ondemand virtual working environments tailored on the user’s requirements. Hence the need for an architecture to manage dynamically such environments. In this work we propose a possible solution based on the use of Virtual Machines (Xen), the implementation of a Virtual Machine Manager, capable of creation, destruction and migration of the virtualized working environments. The information will be collected using a client-server mechanism, to allow the manager to deploy preconfigured Virtual Machines on the available hardware resources. When a new execution

environment became active, it is automatically recognized by the Batch System Manager and is then ready to be used

Cefalà, M. R.

Mariotti, M.

Servoli, L.

English

Scientific Open-access Literature Archive and Repository

DOI 10.1393/ncc/i2009-10401-1Colloquia: CSFI 2008IL NUOVO CIMENTO Vol. 32 C, N. 2 Marzo-Aprile 2009A possible solution for dinamically managing virtual environmentsM. R. Cefala`(1), M. Mariotti(2) and L. Servoli(1)(1) INFN, Sezione di Perugia - Perugia, Italy(2) Dipartimento di Fisica, Universita` di Perugia - Perugia Italy(ricevuto il 22 Giugno 2009; pubblicato online il 16 Settembre 2009)Summary. — In modern distributed computer systems (clusters and computingGRIDs) a new class of problems, due to the increasing heterogeneity of users’ needs,have to be tackled by the administrators. One possible solution is to create on-demand virtual working environments tailored on the user’s requirements. Hencethe need for an architecture to manage dynamically such environments. In thiswork we propose a possible solution based on the use of Virtual Machines (Xen),the implementation of a Virtual Machine Manager, capable of creation, destructionand migration of the virtualized working environments. The information will becollected using a client-server mechanism, to allow the manager to deploy preconfig-ured Virtual Machines on the available hardware resources. When a new executionenvironment became active, it is automatically recognized by the Batch SystemManager and is then ready to be used.PACS 07.05.Bx – Computer systems: hardware, operating systems, computer lan-guages, and utilities.PACS 07.05.Kf – Data analysis: algorithms and implementation; data management.1. – IntroductionIn recent years the evergrowing need from several scientific communities for greatercomputing capability has led to the formation, at Departmental level of common clusters,often belonging to a computing GRID, where the hardware has been acquired by severalresearch groups, each one with its own requirements in terms of operating systems,compilers, libraries and applications.The drawback of this approach is the unavoidable growth of resources heterogeneitydue to both the geographically dispersed nature of the organizations, and their spe-cific needs, requirements and update schedules. Furthermore, there is the insurgenceof classes of applications requiring mutually incompatible execution enviroments. Thisproblem becomes much more difficult for those cases where resource management poli-cies are subjected also to centralized organization as in computing grids: the adoptionof operating systems and/or software packages and their updates are imposed by globalc© Societa` Italiana di Fisica 179180 M. R. CEFALA`, M. MARIOTTI and L. SERVOLIFig. 1. – Illustration of the resource partitioning problem: three groups (A, B, C) with mutuallyexclusive needs have put in a common infrastructure their statically partitioned resources toensure the availability at the expense of optimal use. Some limited management gains are stillpossible.policies, but these are often not compatible with local constraints. As an example, ap-plications developed by some of the local user groups may need long validation timesbefore being safely ported to a new operating system or use a new library version.The following use-case could be used to illustrate the architectural problem: threedifferent user groups have put into a common infrastructure all their computing resources,in order to gain in maintenance manpower. Because of mutually exclusive softwarerequests the resources have been assigned in a mutally exclusive way (fig. 1) into threesub-domains, managed by the same batch system. Since one class is not able to executethe tasks intended for another one, when there is an imbalanced workload, the resourcesassigned to this class are heavily loaded and can rapidly become insufficient, while theresources belonging to the other classes may be in an idle state. Beside the sub-optimaluse of shared resources, there are also the management complications due to the differentqueues that should be set-up for the different user groups.The desirable goal would then be to form a pool of resources that could be used byall the groups allowing them to have access to at least their share of resources and ifpossible, to a greater part because the time profile usage differs usually from one groupto another.2. – The Prototype’s ArchitectureFor the reasons described previously the possibility to implement a solution, usingthe Virtual Machine technology, assuring to each research group its own independentworking environment detached from the underlying operating system of the real machine,is becoming very attractive.From the system administrator point of view this solution offers also the possibilityto decouple the execution enviroments from the hardware resources, thus allowing tosolve the problem of installing new hardware in a computing grid site where the commonoperating system cannot be upgraded at will to a version containing the appropriatedrivers for the new harwdare.We propose to develop a Virtual Machine Manager able to monitor the system re-A POSSIBLE SOLUTION FOR DINAMICALLY MANAGING VIRTUAL ENVIRONMENTS 181Fig. 2. – Architecture of the prototype: the Clients collect information and send it to theManager (Server) who decides the actions to be performed, and will then send the appropriatecommands back to the Clients on the various cluster resources.sources status and to manage the Virtual Machines (create, destroy) in all the realmachines of the cluster [1].The prototype will work asynchronously in respect of the pre-existing Resource Man-agement System of the cluster in order to do not interfere with the already existingscheduling algorithm.In fig. 2 the Client/Server architecture of the prototype is described. The Clientcomponents will be installed on every resource, real or virtual, playing the double role ofgathering information, to be passed to the Server (Manager), and of executing commandscoming from the Manager. One of such resources will be the node where the BatchSystem/Scheduler is installed.The information will be received by the Manager either at scheduled times or triggeredby events. The information will then be analysed to check the current status of the systemand the subsequent needs in terms of jobs waiting in the various queues. At the end ofthis phase one or more decisions would then be taken and the relevant commands (orsequence of commands) would be sent to the Clients in order to be executed, e.g., thecreation of a Virtual Machine tailored for group A in a real node B, where other VirtualMachines may already be running.One last characteristic sought for the prototype is the use of OpenSource software,so we chose Xen [2] as the virtualization tool, Phyton as scripting language and SpreadToolkit [3] as communication system.3. – The Communication ProtocolA crucial role in this schema will be played by the protocol that links the Managerand the Clients, because it must be robust, capable of passing the information to allClients, with efficient and in-order guaranteed delivery capabilities.The last point is essential because the Manager could send a sequence of commands tothe same Client to have them executed in a specific order. Instead of developing ourselvesthe protocol we have decided to use an existing OpenSource group communication system,the Spread Toolkit, because of its properties that match nicely our requests. In fig. 3 a182 M. R. CEFALA`, M. MARIOTTI and L. SERVOLIFig. 3. – Schema of the Spread network implemented in the prototype.schema of the Spread network to be implemented is shown; several daemons could beused if it is needed to ensure the scalability of the architecture.Since the application is written in python, to implement the protocol we used theSpreadModule wrapper that allows an high level abstraction of the underlaying Spreadsub-system. Two sets of messages are provided by the protocol:– Membership messages generated by the Spread sub-system and received by theManager when a Client joins or leaves a group or when it disconnects. The Manageris then able to react to status changes.– Regular Messages used for properties and commands exchange. The semantic ofthe informative content is recognized from the msg type field of the message. TheManager is able to query the Clients which will then reply sending the requestedproperties or the return values of the issued commands.The content of a message (payload) could be anything that we want, allowing a highdegree of customization that could be exploited to accommodate for future unforeseenneeds.4. – The ManagerThe Manager is written in multithreaded python (fig. 4) and various threads areused to optimize the execution and avoid dead times: two threads for communication(Listener, Sender) and one for decision logic (TriggerWatch). The information extractionand the commands definition is done through property and command plugins, so there’sno limitation to the type of extracted information and commands.The Manager listens to the Spread network, and updates its data structures with thestatus of the Client groups; it also periodically sends to Clients requests for propertiesand aggregated data. Properties could be almost anything that we want to know; this ispossible because of the flexible implementation of the protocol we discussed above.A POSSIBLE SOLUTION FOR DINAMICALLY MANAGING VIRTUAL ENVIRONMENTS 183Fig. 4. – Architecturs of the Manager: the relations between the data repositories, the commu-nication parts and the core components are shown.An example of property definition, made of just few lines of code:[ram free]command = ramparameters = MemFreereturn type = intticks = 60Ticks is the time interval between two consecutive collections of that property. Anevent-based mechanism, implemented through the use of programmable Triggers, definesthe decision logic used by the Manager to choose the commands and the requests to besent to the Clients. A Trigger definition is made of two parts:– An event expression.– An event-handling command.An example:[client query]expr = { len(manager.clients) != 0 }cmd = { sender.send get property() }ticks = 30on update check = noThe Manager will base its decisions using the received data within a set of custom definedrules, again providing maximum flexibility to the system. The commands will then besent to the relevant Clients to be executed on their hosts.184 M. R. CEFALA`, M. MARIOTTI and L. SERVOLIFig. 5. – Architecture of the Client: the reletions between running environment, communicationpart and the two core components (Properties Fetching and Command Executor) are shown.5. – The ClientThe Client side is again written in python with a multithreaded architecture as shownin fig. 5; it is executed either in the Dom0 or DomU machines to collect all the relevantinformation. An interface module implements the communication protocol, while theRunner module allows the execution of commands issued by the manager and the asyn-cronous extraction of properties from the host system under the control of the Readermodule.6. – The TestbedThe prototype has been implemented on the University of Perugia Physics Depart-ment Computer Science Laboratory. The 35 diskless workstations (fig. 6) were equippedwith Xen 3.x using a shared NFS root filesystem hosted on the boot server virtdom.The Manager is set up to run on virtdom as well as the Spread Daemon. Eachworkstation is capable to run at least 50 Clients (depending on the size of RAM) fortesting purposes. The interconnecting network is a standard 100Mbit/s Ethernet.Fig. 6. – Schema of the testbed to be used for the performance tests.A POSSIBLE SOLUTION FOR DINAMICALLY MANAGING VIRTUAL ENVIRONMENTS 185Some tests have already been performed in order to evaluate:– the basic functionality of the messaging system and of the prototype;– the messaging protocol efficiency;The results presently obtained shows no problems in the architecture of the proto-type, all the basic functionalities having been tested. No signs of possible bottlenecks inresource usage due the communication protocol have been observed.7. – ConclusionA prototype to manage the creation of Virtual Environments in a middle-sized com-puting cluster with eterogeneous users has been designed and implemented. The drivingidea of having an asynchronous system with respect to the Batch System has been ex-plored, identifying the protocol system as one of the most important components. Animplementation using the Spread Toolkit has been carried out and some tests on thescalability of the system have been performed on a dedicated testbed. The main func-tionalities of the prototype have been tested and no bottlenecks or unforeseen problemshave been found.More exhaustive tests concerning the scalability of the prototype will be carried outduring the next months, followed by the definition of evaluation metrics in order to es-timate the impact on job queue times and on the aggregated throughtput of the batchsystem of the prototype. A fully working prototype will be implemented in the afore-mentioned INFN GRID site by the end of the year 2008.∗ ∗ ∗The authors would like to thank the Physics Department of Universita` degli Studi diPerugia for the use of the Computer Science Laboratory.REFERENCES[1] Cefala` M. R., Studio di un prototipo per la gestione dinamica di ambienti virtuali, Tesi diLaurea, Universita` degli Studi di Perugia (2008).[2] www.xen.org Official Xen web site.[3] www.spread.org Official Spread web site.

A possible solution for dinamically managing virtual environments

http://eprints.bice.rm.cnr.it/16540/1/ncc9408.pdf

A possible solution for dinamically managing virtual environments

Abstract

Similar works

Full text

Available Versions

Scientific Open-access Literature Archive and Repository