Towards Grid Monitoring and deployment in Jade, using ProActive

HAL Id: inria-00182554

https://hal.inria.fr/inria-00182554v2

Submitted on 29 Oct 2007

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

ProActive

Cristian Ruz, Françoise Baude, Virginie Legrand Contes

To cite this version:

Cristian Ruz, Françoise Baude, Virginie Legrand Contes. Towards Grid Monitoring and deployment

in Jade, using ProActive. [Research Report] RR-6340, INRIA. 2007, pp.20. �inria-00182554v2�

inria-00182554, version 2 - 29 Oct 2007

a p p o r t

d e r e c h e r c h e

9

-6

3

9

9

IS

R

N

IN

R

IA

/R

R

--6

3

4

0

--F

R

+

E

N

G

Thèmes COM et NUM

Towards Grid monitoring and deployment in Jade,

using ProActive

Cristian Ruz — Françoise Baude — Virginie Legrand-Contes

N° 6340

Cristian Ruz

∗

†

†

ThèmesCOMet NUMSystèmes ommuni antset Systèmesnumériques ProjetAutoman/OASIS

Rapportdere her he n°6340Septembre200720pages

Abstra t: This do umentdes ribesour urrenteortto gridify Jade, ajava-based envi-ronmentfortheautonomi managementof lusteredJ2EEappli ationservers,developedin theINRIASARDESresear hteam. Towardsthisobje tive,weusethejavaProA tivegrid te hnology. Werstpresentsomeofthe hallengestoturnsu hanautonomi management systeminitiallydedi ated to distributedappli ations runningon lustersof ma hines, into onethat an provideself-management apabilities to large-s alesystems, i.e. deployedon grid infrastru tures. This leadsus to a briefstate of the art ongrid monitoringsystems. Then, we re all the ar hite ture of Jade, and onsequently propose to reorganize it in a potentiallymores alableway. Pra ti alexperimentspertainto theuseofthegrid deploy-mentfeature oeredby ProA tiveto easily ondu t thedeploymentoftheJade systemor itsrevisedversiononanysortofgrid.

Key-words: grid monitoring, grid deployment, ProA tive, autonomi management of distributedsystems

∗

Thedes ribedresear hworkand resultshavebeen obtainedduringCristianRuz'sinternshipat IN-RIASophia-Antipolis, o-fundedbyaCONICYT/INRIAs holarshipandthe INRIAARCAutomanfrom De ember2006toApril2007

†

Résumé: Cedo umentdé ritnoseortsa tuelspourgridierJade,unenvironnementJava destinéàl'administrationdesserveursd'appli ationJ2EE lusterisés(répliqués),développé dans l'équipe de re her he INRIA SARDES. An d'atteindre et obje tif, nous utilisons late hnologieJavaProA tive. Dans unpremiertemps, nousprésentonsquelquesétapesà fran hirandetransformeruntelsystèmed'administrationinitialementdédiéauxappli ations répartiessurdes lustersdema hines,enunsystèmequipeutfournirdesfon tionsd'administration autonomique auxsystèmes à largeé helle, .a.d. déployésur des infrastru turesde grille. Dans et obje tif, nousprésentonsunbrefétatdel'artsurlessystèmes desupervisiondes systèmes distribués sur la grille. Dans un deuxième temps, nous rappelons l'ar hite ture de Jade, et nous proposons en onséquen e de la réorganiser de façon à e qu'elle passe potentiellement plus à l'é helle. Enn, des expérimentations pratiques se réfèrent à la fon tionnalité dedéploiementoerte par ProA tivedans lebut de fa iliterle déploiement deJadeoudesesversions réviséessurn'importequeltypedegrille.

Mots- lés : supervision de grilles, deploiement sur grille, ProA tive, administration autonomedesystèmesrépartis

1 Introdu tion

This report des ribessome resear h eortand resultsobtained in the ontext of the Au-toManproje thttp://sardes.inrialpes.fr/resear h/AutoMan/, anINRIA funded re-sear h ollaborationbetweenOASIS,SARDES teams,andLSDteam fromUPM,Spain.

Theobje tivesofAutoManaretostudytheautonomi managementofgrid-based enter-priseservi es. Inthis ontext,Jade,aframeworkforautonomi managementofdistributed appli ations, developed by the SARDES team is onsidered. Spe i ally, one of the Au-toman purposes is to evaluate the burden for su h an autonomi management system to extenditsappli abilityandusabilityfrom a lusteredto agridsetofma hines.

Jade is designed using the Fra tal omponent model, and implemented as a Java ap-pli ationusingJuliaandFra talRMIforsupporting remoteintera tions betweentheJade omponentsthatmaybedistributedondierentma hinesofthe luster. Inordertobe au-tonomi allymanaged,alega yappli ation,forexampleaJ2EEappli ationserver,mustbe wrappedinsideaFra tal omponent. Thus,a ommoninterfa eisprovidedtomanagethese lega yappli ationsfromtheJadeframework[2,3℄. Jadedeploysthemodulesthat onstitute thear hite tureofthewrappedlega yappli ationandmirrorsthisar hite tureinorderto furthermonitorit. AsJadeneedsto deployandremovelega ymodules,appli ations have tobedeployedas bundlesonOSGiplatforms. TheJadesystemitselfisdeployedasOSGi bundles. Thus,thisrequiresthepreviousdeploymentofOSGigateways. The urrentlyused supportforJadeisOs ar,http://os ar.obje tweb.organopensour eimplementationof OSGi. Indeed,theuseofOSGipermitsveryeasilytheautonomi (re)deploymentof (repli- ated)modulesin aseoffailureorpoorperforman es,bysimplyuploadingOSGibundles onavailableOSGigatewaysalreadyrunningtheJade system.

Enabling Jade to applyits autonomi managementstrategiesat agridlevelinsteadof justa lusterofma hines hasthefollowingunderlyingaims:

ˆ togivebetterperforman es alabilityofthedeployedlega yappli ation,asthenumber ofrepli a anbein reasedaswill(nottakinginto onsiderationotheraspe tssu has databaserepli ationwhi hmaynotwellapplyatagrids alethisisanothermatter, alsostudied inAutoman),

ˆ to in rease exibility, as all repli a are not onstrained to be lo ated on the same lusterand anbemigratedorrestartedonotherma hinestoe.g. betterbalan ethe overallloadofthe lustersordesktopma hinesformingthegrid.

These aimsposerequirementsonthemanagementsystem,i.e. Jade:

ˆ apabilitytodeployitselfandtheappli ativemodulesonany omputingenvironment. Forthis, theProA tivegridmiddlewaredeveloped withintheOASISteam [1,4℄ an berelevantasitsupportsa ompletelyopen, ongurabledeploymentmodel: through XML-baseddeploymentdes riptors,theuser anabstra tawayproto ols,job submis-sionsystems,and laun horgeta esstoapro ess(a nativepro essoraJVM).

ˆ apabilitytoenableJade-levelandappli ation-level ommuni ationbetweenany par-ti ipating entity, whateverits lo ation. Here again, the use of ProA tive ould be relevant. Both inter ProA tive runtimes and ProA tive a tive obje ts or software omponents ommuni ationstakegrid onstraintsinto onsideration(laten yhiding through asyn hronous with future remote single or multipoint method invo ation, on-demandse urisationof ommuni ationsauthenti ation,nonrepudiation, en ryp-tion). The onstraints in order to get immediate advantage of su h properties (at leastwithinJadeitself)wouldbetorelyonProA tiveinsteadofFra talRMIforthe intera tionsbetweentheFra talJade omponents.

ˆ apabilityto shareand distributethemanagementrelatedoperationsandasso iated messaginga ordingtothewaythemanagedsystemisdeployed(amountandlo ation oftherepli as).

Thismeansthatthear hite tureoftheJadesystemitselfmustbeexibleenough,to berepli atedatagrids ale. [2℄previouslydevisedarepli atedversionoftheJade ar- hite tureforthepurposeofmakingJadeitselfaself-repairingsystem. Consequently, the eort was put on the needed proto ols for the various Jade repli ated modules (Manager omponent) to alwaysmaintain a oherent opy of theglobal stateof the managedsystemandgloballysyn hronizetheiroperations. Here,ouraimisdierent be ause we aim at proposing a mores alable and grid-enabled version of the Jade ar hite turetobetteradheretotheee tivedeploymentofthemanagedappli ation. Indeed, Jademaybein hargeofabig numberofwidely distributed appli ative en-tities or omponents at on e. So, the Jade monitoringoperations (get sensed data, triggera tions,...) mustalsobes alableandgridaware. Thisiswhywerststudied thestateoftheartaboutgridmonitoring: withtheaimtogetinsightonhowa mon-itoringsystemshouldbedesignedandoperateontoeitherthesetofgridresour esor thesetofappli ationsdeployedonthisset.

Thisreportrstpresentsashortstateoftheartwe olle tedaboutGridMonitoring,with theintentiontogetinsightontohowtomakeJademoregrid-aware,i.e.,mores alable. The followingse tionsshowsomeissuesaboutthear hite tureofJade,des ribeshowProA tive anbeused to deploy itonagrid, andnally suggestsahierar hi alorganisation ofJade forittobettersuits alabilityrequirements.

2 State of the art on Grid monitoring

Inthis se tion, webriey present andanalyse someof therelevantworks regarding ar hi-te turesforprovidings alableande ientGridMonitoring.

2.1 Grid Information Servi es for Distributed Resour es Sharing 2.1.1 Paper referen e

K.Czajkowski,S.Fitzgerald,I.Foster,C.Kesselman,GridInformationServi esforDistributed Resour esSharing,10thIEEEInt. Symposium onHigh-Performan eDistributed Comput-ing(HPDC-10),2001

2.1.2 Brief summaryof the proje t des ribed in the paper

Thisworkdes ribesanar hite turetobuildaninformationservi eontopofdierentVirtual Organizations(VOs)

1

,inordertoshareitsresour eswithotherVOs. Gridappli ations an benetfromtheseservi estoknowwhi hresour esareavailable,sin ethisavailability ould bedynami .

Someoftheservi esrequiredbygridappli ations in lude:

ˆ Servi edis overyservi e,toknowaboutnewresour esavailable.

ˆ Appli ationadaptationagent,tomonitorandmodifyappli ationbehavior.

ˆ Supers heduler, for routing requests to the 'best' resour es (where 'best' must be dened).

ˆ Repli a sele tionservi e,torequest'best' opiesofrepli atedresour es.

ˆ Troubleshootingservi e,tomonitorandlook foranormalousbehavior.

ˆ Performan ediagnosistools,whenananormalousbehavior anbeidentied.

Theproposedar hite tureis omposedofInformationProviders,andAggregatedire tory servi es. Information providersform a ommon, neutralinfrastru tureprovidinga ess to dynami information aboutgridentities. Aggregate dire toriesobtaininformation through theproviders,andanswerqueriesaboutthem(likeasear hengine). Thedire tories stru -turesarebasedonthatoftheLDAPones,tosolves alabilityissues.

Both ommuni atethroughdenedproto ols(GRIP)fordis overy(sear h)andenquiry (lookup). Thes hemafollowedisthatoftheLDAP one,usingahierar hi alnamespa e,in ordertoaimats alabilityissues. Theauthorsalsodeneanoti ationme hanism(GRRP) formaintainingasoft-stateoftheresour es. Thestatemaybedis ardedifitisnotrefreshed forsometime,sotheprovidersmustimplementaheartbeat.

1

Thewayaninformationproviderknowswhomitmustregisterwithisnot learlystated. Theauthorssaymanual onguration anbeused,but itwouldnotbedesirablein an au-tonomi management ontext. An alternativeistouseanotherdis overyservi epreviously existent.

2.2 Autopilot: Adaptive Control of Distributed Appli ations 2.2.1 Paper referen e

R.L.Ribler, J.S.Vetter, H.Simit i, D.A.Reed, Autopilot: Adaptive Control of Distributed Appli ations. 7th IEEE Int. Symposimum on High Performan e Distributed Computing (HPDC-7),1998.

2.2.2 Brief summaryof the proje t des ribed in the paper

Thisarti ledes ribesamonitoringframeworkthatisfurtherusedfordynami allyadapting

thebehaviorofa(distributed)appli ation(seeGrADSproje thttp://www.hipersoft.ri e.edu/grads), inparti ularwiththeaimtomaximisetheperforman esoftheappli ation.

Theframeworkin ludes:

ˆ Distributedperforman esensors,tomonitorappli ationandsystemperforman e,and generatequalitativeandquantitativedes riptions.

ˆ A tuators,tomodifytheappli ationbehaviorthroughthemanipulationofparameter values.

ˆ Distributed nameservers,that works asregistriesof sensors and a tuators: a lient anthensubs ribeto agivensensorora tuatora ordingtothekindof monitoring information it is interested in (i.e. to read or set a variable or parameter of the appli ation)

ˆ De ision me hanisms (like Jade rea tors are): they implement the algorithm that readstheinformationfromthesensors,andde idesa tionstobeimplementedviathe a tuators. Inthegeneral ase,this partishardtoa omplish.

Bothsensorsanda tuatorsarerepresentedthroughpropertylists,whi harepairs prop-erty(orvariablename)/value. Theeventsarerepresentedinaparti ular dataformat.

2.3 A S alable Wide-Area Grid Resour es Management F rame-work

2.3.1 Paper referen e

M.El-Darieby,D.Krishnamurthy,AS alableWide-AreaGridResour eManagement Frame-work. International onferen eonNetworkingandServi es(ICNS'06).

2.3.2 Brief summary ofthe proje t des ribed in the paper

This arti ledes ribes aframework designed to attains alable resour emanagement. The s hemaproposedishierar hi al,deningvariouslevelsofResour eManagers.

At the lowest levels, ea h resour e has an Individual Resour e Manager (IRM), ea h lusterhasaClusterResour eManager(CRM).Groupsof luster anbegroupedinvirtual lusters, with anotherCRM representingthem, and onstru tingmorelevelsof hierar hy. Inthetop-levelthereareGridResour eManagers(GRM)whi hmanageresour esfortheir lowerlevels,and also an ommuni ate with theirpeers(other GRMs) in orderto submit jobstoappropiatelo ations.

Themorethelevelin reases,themoretheinformation maintainedbyea hmanageris abstra t:

ˆ IRMsmaintaininformationaboutresour estateandavailability.

ˆ CRMsmaintainaggregatedinformationabouttheresour esin ludedinthemanaged luster.

ˆ CRMs athigherlevelsmaintaininformationaboutthe lusters managed.

ˆ GRMsmaintainsummaryinformationaboutthe lusters.

Lower level managersin lude more detailed information about the resour es. This is doneinordertoavoidredundan yandimproves alability. Otherwise,GRMswouldhavea hugeamountofinformation, andshouldhaveto maintainitup-to-date, too.

Theassignmentsare propagatedto thelowerlevels. Re overies,andother a tionsthat anbelo allyhandled,neednottobepropagated tohigherlevels.

Notes Although no implementation is presented, the ideas t well to our goal. Su h hierar hi alapproa h ouldbetakeninJadetobuildahierar hyofmanagers: nextpartof thereportpresentsareorganisationofJade followingthisdire tion.

2.4 A Grid Monitoring Ar hite ture 2.4.1 Paper referen e

B.Tierny, R. Aydt, D. Gunter,W. Smith, M. Swany, V. Taylor, R.Wolski, A Grid Mon-itoring Ar hite ture. Te h. Rep. GWD-PERF-16-2, Global Grid Forum, January 2002. iteseer.ist.psu.edu/arti le/tierney02grid.html.

2.4.2 Brief summary ofthe proje t des ribed in the paper

Thisarti ledes ribestheGridMonitoringAr hite ture,developedbytheGlobalGridForum Performan eWorking Group.

They list some onsiderations that have to be taken into a ount when designing a monitoringar hite ture:

ˆ Performan edatahasaxed,andoftenshortlifetimeutility. Long-termstorageisno needed, unlessa ountingisgoingto bedone. Readings,onthe otherhand,haveto bequi k.

ˆ Updatesarefrequent. Performan einformationis updatedmorefrequentlythanitis read. Itis importanttooptimizeupdates,ratherthanqueries.

ˆ Performan einformation is oftensto hasti . Rawdata may haveto be pro essed in orderto getrelevantinformation.

Agridmonitoringar hite tureshould meetthefollowingrequirements:

ˆ Lowlaten yin thetransmissionfromsensorsto onsumers.

ˆ Highdata ratetransmission,astheperforman e information ouldbegeneratedat a highrate.

ˆ Minimal measurementoverhead.

ˆ Se ure.

ˆ S alable.

TheGridMonitoringAr hite tureisbuiltusing3typesof' omponents':

ˆ Dire tory Servi e: supports information publi ation, and dis overy. May be dis-tributedto improves alability.

ˆ Produ er: makesperforman edataavailable (eventsour e)

ˆ Consumer: re eivesperforman edata(eventsink)

Produ ersand onsumersregisterwith theDire tory Servi e (publish/sus ribe intera -tion). The Dire tory Servi e is used to lo ate produ ers and onsumers, i.e. maintains registryofavailableprodu ersand onsumers,andanswersqueriesaboutthem. Afterthat, eventsow dire tlybetween them. It does notstore event data, that is, the information resultingfrommonitoring. ThisallowstheseparationofDataDis overyandDataTransfer. Consumers make queriesto produ ers,requesting events (query/response intera tion), andre eivesthem. They analsomakequeriestotheDire toryServi e,in ordertolo ate appropriateprodu ers.

Produ ersregisterwiththeDire toryServi e, a eptqueriesfrom onsumersandmake theresponses. They analsonotifyeventstosubs ribed onsumers.

A omponentmayimplementoneorbothof theprodu eror onsumerinterfa es. This way,a omponent ana tasprodu er, onsumer,orboth.

Notes Inordertoprovides alability,aset of omponentsthat implementbothprodu er and onsumer interfa esmay be implemented. In the ontext of Jade, those omponents ouldbetheonesthatservetheroleofsensorora tuatoronthewrappedlega yappli ation module. For example su h a Jade Fra tal omponent ould re eive input from multiple produ ersthroughits onsumerinterfa e, aggregatesit orderivesomeother metri sfrom them, andthen sendthat resultto another onsumerthroughitsprodu erinterfa e. This way,thehierar hy ouldbebuilt.

2.5 A taxonomy of grid monitoring systems 2.5.1 Paper referen e

S.Zanikolas, R.Sakellariou, A taxonomy of grid monitoring systems. Future Generation ComputerSystems21(2005),Elsevier

2.5.2 Brief summaryof the proje t des ribed in the paper

This paper presents ataxonomy for lassifyinggrid monitoringsystems. The riteriaare takenfromthe' omponents'implementedin thesystem.

RequirementstheylistforaGridMonitoringSystemare:

ˆ S alability: Goodperforman eonmonitoring,andlowintrusivenessonthemonitored resour es.

ˆ Extensibility: Extensibledataformat,extensibleprodu er- onsumerproto ol.

ˆ Data deliverymodels: For example, measurement poli ies ould be periodi or on-demand.

ˆ Portability.

ˆ Se urity.

The' omponents',bywhi hthetaxonomyisbuilt, arebasedonthose proposedbythe GMA(GridMonitoringAr hite ture),andin lude:

ˆ Sensors. Pro essesthatmonitoranentityandgenerateevents. Maybemerelypassive, ormakeestimations(moreintrusive).

ˆ Produ ers. Pro esses that read data from sensors, and implement an interfa e to omuni ate with dire tories(to registeritself), and with onsumers. Produ ers may alsolterorsummarizedata.

ˆ Republishers. Componentsthat animplementbothprodu erand onsumerinterfa e.

ˆ Hierar hyofrepublishers. A stru ture ontainingoneormorerepublishers hierar hi- allyorganized.

ˆ Consumers. Pro essesthatread datafromprodu ersthroughadenedinterfa e.

Additionally,there isanother omponent alled theRegistry,whi h a tsasadis overy servi e. Produ ersand onsumerssubs ribeto it,inorderto dis overea hother. Itisalso possible to request spe i typesof data, and, in this way, asso iate one onsumerto the 'best'produ er(s).

Thetaxonomyproposedisbuiltaroundthenumbersof omponentsin ludedina mon-itoringsystem,andthesystemsare lassieda ordingly:

ˆ Level 0systems implement only Sensors and Consumers, whi h ommuni ate in an appli ation-spe i way.

ˆ Level1systemsimplementSensors,Produ ersandConsumers, ommuni atingthrough dened interfa es,allowingmultiple onsumers onne tingto them.

ˆ Level2systemsimplementRepublishersinsteadofjustProdu ers. Republishersmay be entralizedordistributedand supportdierentfun tionalities.

ˆ Level3systemsimplement Hierar hiesofRepublishers, whi h arere ongurable, al-lowingfor(potential) s alability.

The y leof monitoringen ompassesthe following phases,whi h anbe a omplished byoneormoredierent omponentsofthesystem:

ˆ Generationofevents. Atsensorsorprodu ers.

ˆ Pro essing. Atsensors, produ ersorrepublishers.

ˆ Distribution. Atprodu ers,republishers,or onsumers.

ˆ Presentationand onsumption. At onsumers.

Notes Thear hite ture in whi h thetaxonomyis baseddoesnot addressthe re ongu-ration of the resour es, nor some omponent that would be in harge of 'rea ting' to the monitoring. Thisisreasonable,aslongasthefo usisin monitoring,andnotinautonomi management. Ifany,theautonomi managementalgorithmtode idewhi ha tionshaveto betakenonthesystem,shouldbe onne tedto the onsumers.

2.6 Synthesis and General remarks

ˆ Thesensorpro essshouldbealowinvasivepro ess.

ˆ All olle ted information will surely be outdated, as it hanges dynami ally. So, it doesn'tmakemu h senseto storelargeamountsofdata, in urringin highoverheads tomaintainthisdataup-to-date.

ˆ As a onsequen e,itis ne essarytotransmit lessamountof data throughthe moni-toringentities,orwell,useaparti ularformattomakethepro essingeasier.

ˆ The hierar hi al approa hesproposed in the various studied papersseem to provide themostpromising basisfors alability. Dierentlevelsofthehierar hymaymanage dierent kind of information. Higherlevelsmay onlyre eive summarized data, and lowerlevels(neartoresour es), managethedetails.

ˆ Inthe ontextoftheJadesystemwhi hisbuiltuponthehierar hi alFra talsoftware omponentmodel, it ould be possible to build ahierar hy forsensors, and also for a tuators.

ˆ The way to build the hierar hy of omponents in order to attain s alability should bedone arefullyandautomati allyatdeploymenttimeofthemonitoredappli ation. Theanalysed worksdo notstatehow todo it, andsomeof them talkabouta man-ually onguredhierar hy. As theavailabilityof theresour esisdynami , amanual ongurationdoesnotsoundappropriate,evenlessinanautonomi managed ontext.

3 Jade ar hite ture

3.1 Presentation

TheJade ar hite tureisbasedontheFra tal omponentmodel. Itisimplementedin Java usingJuliaandFra talRMI.ThemainelementsoftheJadear hite turearetheJadeBoot and JadeNodes. A node (a ma hine) must host a JadeNode in order to be managed by Jade. OnenodemusthostaJadeBoot,whi hisa omponent ontainingasetof omponents oeringservi esthatallowtoimplementtheautonomi behavior.

installer

node

discovery

resource

deployer

node

allocator

jms

registry

fractal rmi

registry

system

representation

server

jms

controllers

managed resources

Figure1: Ar hite tureofaJadeBoot

As shown in Figure 1, the JadeBoot omponent in ludes several Common Servi es in ordertoprovidetheautonomi behavior:

ˆ Node Dis overyServi e. Re eivesHeartBeatsfrom a set of JadeNodes and keeps a dynami list of available nodes. A node that takestoo mu h ( ongurable) time to answerismarkedasfailed.

ˆ Resour e Deployer. Communi ates with a remote installer and deploys and starts omponents ontainingawrapped lega yappli ation in aJadeNodeprovidedbythe Allo ator omponent.

ˆ Allo ator. Manages alist of available JadeNodes, and keeps amappingof deployed appli ationsand nodes. This omponent animplementanallo ationpoli yin order toprovidethe'best'nodea ordingtosome riteria.

ˆ JMSServer,andJMSRegistry. Implementsamessagingservi eto beread byother nodesandnotieseventslikenodeavailability,ornodefailure.

ˆ Fra talRMIregistry. Anamingservi etolo ate omponentslo atedonremotenodes.

ar-installer

factory

managed resources

heartbeat

controllers

Figure2: Ar hite tureofaJadeNode

the deployed appli ations and nodes, whi h anbe useful to handle the failure of a node ontainingaset ofdeployedappli ations.

TheJadeNode omponentFigure(2)in ludesasmallersetof omponents,andisableto install omponents ontainingwrappedlega yappli ations, andmakethemselvesavailable toaJadeBoot:

ˆ Fa tory. A Generi InstallingFa tory to reate new Fra tal omponents ontaining wrapped lega y appli ations. The appli ation itself is deployed and installed as an OSGibundlefromaBundleRepository,throughaOSGiInstaller omponent.

ˆ HeartBeat. Sends periodi allymessagestotheJadeBootinordertomakeitself avail-abletotheJadear hite ture.

3.2 S alability issues

AstheJadear hite turewasdevelopedtoworkinsideasingle lusterofma hinesproviding someservi es,itla ksfeaturesabletoworkoveramorelarge-s aledistributedinfrastru ture (e.g. amulti- lusterbasedgridorevenadesktopgrid).

ˆ Thear hite ture omprisesoneJadeBoot ontrollingseveralJadeNodes. Anapproa h that workswellinside small lusters,butthat isnots alabletoagrid ontext.

ˆ Noautomati me hanismis providedto deploythe JadeBoot andJadeNodesonthe luster. Infa t,ea h omponentmustbemanuallystartedonea hnode.

4 S alable monitoring within Jade

This se tionpresentsboth aninitial eortto deploy theJade systemusing theProA tive deploymentme hanism,andapropositionforanewar hite tureforJade.

4.1 ProA tive-based deployment

InordertodeployJadenodesonseveralma hines, weuseanutilitysoftwarenamed Com-mandLaun herbasedonProA tiveDeploymentDes riptors. The ommandLaun heraims atexe utinga ommand(e.g. startasoftware)onagivensetoftargetswhi hare omputing resour esa quiredthroughaProA tiveDeploymentDes riptor. Morepre isely,the om-mandlaun hersystemdeploysProA tiveruntimesontowhi hCommandLaun herobje ts (i.e. A tiveObje ts)arelaun hedand havetheabilityto exe utethegiven ommand.

A ProA tiveDeploymentDes riptorhasbeendened (Figure3), and anthenbeused (transparentlytotheuser)bythe ommandlaun hertoautomati allydeployaJade ar hi-te tureoverasetofphysi alnodes. Itisjustamatterofmodifyingthisdes riptorinorder togeta essto anothergridinfrastru tureorsetofma hines,a ordingtotheadvo ated jobsubmissionproto ol. InthegivenexampleonFigure3,weusesshtogeta esstohosts inthegridGrid5000;sosimplyrepla ing,inthepro essdenition,sshbyoarissu ient togeta esstothesamegridbut usingadierentjob submissionproto ol.

The syntax to use the ommand laun her is given in Figure 4. We also provide as an example, thespe i ommand line that the Jade user hassimply to provide in order to triggerthe remoteinstallation ofJadeNodes onsomenodesof thegrid. Inthis spe i example,weexpli itlynamethe3hostsonwhi ha ommand(hereas riptnamedjadeNode) has to be exe uted. But ommand laun her analso be given a list of NODES in aless expli itway(e.g. just requesting3ma hinesofagiven lusterorgrid). Throughsu hkind of ommand,onea hma hineanOs arframeworkislaun hed,whi hinstallsandstartsthe JadeBootorthe JadeNode. On e theJadeBoot and theJadeNodeare deployed, alega y appli ation,forexampleaJ2EE appli ation, anbedeployed andmanaged from within a Jadear hite ture.

4.2 Towards a hierar hi al organisation of Jade 4.2.1 JadeMirror

IntheJadear hite ture,monitors anbeaddedas omponents. Amonitoring y leofJade onsists ofSensors, Rea tors andA tuators. Sensors anbelo ated on theJadeNode (or theJadeBoot depending onwhat isgoing to besensed), and transmit senseddata to the Rea tors. TheRea torsimplementthede isionme hanism,basedonthesensedinformation, andthrowa tionsthat aregoingto beimplementedthroughtheA tuators.

TheJadeframework onsidersthatseveralmonitoringdomains an oexist. Forexample, there anbearepair monitoring y lethatwillrea twhensomenodefailsandwillrepla e thefailednodeforanotherprovidingthesameservi es; oranoptimization y le,that will

<?xmlversion="1.0"en oding="UTF-8"?> <ProA tiveDes riptorxmlns:xsi="http://www.w3.org/2001/XMLS hema-instan e" xsi:noNamespa eS hemaLo ation="Des riptorS hema.xsd"> <variables> <des riptorVariablename="NODES" /> </variables> < omponentDefinition> <virtualNodesDefinition>

<virtualNodename="grid" timeout="${timeout}"property="multiple"/> </virtualNodesDefinition> </ omponentDefinition> <deployment> <mapping> <map virtualNode="grid"> <jvmSet> <vmName value="g5k"/> </jvmSet> </map> </mapping> <jvms> <jvm name="g5k"> < reation> <pro essReferen erefid="ssh_g5k_0"/> </ reation> </jvm> </jvms> </deployment> <infrastru ture> <pro esses> <pro essDefinitionid='g5k'> <pro essListbyHost lass='org.obje tweb.proa tive. ore.pro ess.ssh.SSHPro essList' hostlist='{$NODES}'> <pro essReferen erefid='g5k'/> </pro essListbyHost> </pro essDefinition> </pro esses> </infrastru ture> </ProA tiveDes riptor>

Figure3: Thegeneri ProA tiveDeploymentDes riptorusedtodeployJadenodes

java CommandLaun her-DNODES={targets} ommand

java CommandLaun her-DNODES="sidonie.inria.frmeije.inria.frnaruto.inria.fr" jadeNode

Figure4: TheuseofCommandLaun her

modifysomeparametersofthe appli ationsin orderto optimizetheresponse time, orthe resour esutilization.

installer

node

discovery

resource

deployer

node

allocator

jms

registry

fractal rmi

registry

system

representation

server

jms

controllers

managed resources

monitor

s

r

a

Figure5: Ar hite tureofaJadeBootfeaturingmonitoring apabilities

Fora hieving these goals, the entralized approa h where all the JadeNodes send the senseddata(throughthesensors)totheJadeBoot,isnotsuitable. Forthat,weareproposing tointrodu eanintermediate omponent, alledJadeMirror.

TheJadeMirrorrepli atesthea tionsoftheJadeBoot,anda tsasamanagerforallthe nodes onne tedto it.

4.2.2 JadeMirror designand asso iatedimplementation

The ar hite ture of both the JadeBoot and the JadeNode have been modied to in lude a Monitor omponent among their servi es. In the ase of the JadeNode, it in ludes a Lo alMonitor omponent, whi h is omposed of a Lo alSensor and a Lo alA tuator. As an example, the Lo alSensor periodi ally reads CPU utilization, and sends a message to the JadeBoot. The JadeBoot also in ludes a Monitor omponent, whi h is omposed of aSensor, a Rea tor and an A tuator,whi h behavesin theprevious des ribed way. The Sensorre eivesthe messagefrom theLo alSensorintheJadeNode,andfeedstheRea tor, whi h an takeade isionwith that data and, possibly, alltheA tuatorto exe utesome a tion. Thata tion ouldbeexe uteddire tlybytheA tuator(forexample,ifsomebinding between omponentshas to be hanged, orifsomenodehas to be stopped), orbetterby delegatingtheexe utionofthisa tiontotheLo alA tuatorontheJadeNode(forexample, ifsomeparameterhastobetunedonthenodeinordertooptimizesomeresponse).

Thisstepwhi hhas onsistedintheadditionofamonitoringparttotheJadear hite ture isdepi tedinFigures5and6.

For a hieving s alable monitoring, the addition of JadeMirror nodes is proposed. A JadeMirror in ludes almost the same omponentsof aJadeBoot. Inparti ular, the Node Dis overyServi e,theFra talRMI registry,JMSServer,JMSRegistryandSystem Repre-sentation, anbein luded,oeringthesamefun tionalityastheJadeBoot. TheJadeMirror, asit must a tlike aJadeNode too,must in lude also the HeartBeat omponent. Forthe monitoring,the JadeMirror in ludes theLo alMonitor, to behaveasany other JadeNode:

installer

factory

controllers

managed resources

heartbeat

localMonitor

local

sensor

local

actuator

Figure6: Ar hite tureof aJadeNodefeaturingmonitoring apabilities

it will send noti ations to a remote JadeBoot; but it must also in lude a Monitor that re eivesdatafromitssetofJadeNodes(here, theJadeMirrorisa tinglikeaJadeBoot).

Some omponentsmustbemodiedinorder tobehave orre tlyunder thehierar hi al s heme. For example, the Resour e Deployer must try to allo ate a node from a set of JadeNodes, butif thereis nooneavailable,itshould forwardtherequestto ahigherlevel JadeBoot(oranotherJadeMirrorhigherinthehierar hy),lettingittotakethede isionand possibly onsultingotherJadeMirrorsmanagedbysomeotherJadeMirrors.

Inthe urrentstate,theJadeMirrorisimplementedin ludingthe omponentsofbotha JadeBootandaJadeNode. Thepra ti alexperimentswe ondu teda tually omprisedthe deploymentof1JadeBoot,2JadeMirrors,and2JadeNodes onne tedtoea hJadeMirror, using a total of 7 nodes. In this s heme, the JadeNodes send information about CPU utilizationtotheir"master"JadeMirror,andthisonesendsdatatothe entralJadeBoot.

Our urrent experimental hierar hi al Jade system does notyet in lude the ne essary modi ationstotheResour eDeployer omponents,andAllo ator: that is,allowingthem to send answersto theirJadeBoot stating, for example, that there are no more available nodesorthat somea tion annotbefullledandthatahigherlevelnodemusttake areof it.

5 Summary and next steps

Inthiswork,wehavestartedtointrodu esomes alablemonitoring apabilitiesintheJade autonomi managementsystem. Theimplementationisnot omplete,butthe urrentstate it has rea hed is su ient to serveas a proof-of- on ept about the building of hierar hy of Jade omponents (Boot, Mirror, Nodes). Onthis basis, weare expe ting that s alable monitoring an bea heived.

Thegridi ationofJadeisaddressedby onsideringdeployingtheJadear hite tureusing ProA tivedeploymentdes riptors. Moreover,weare onvin ed that animplementationof Jadeusing theProA tive/GCMimplementationof theFra tal omponentmodel [5℄ ould improve the grid awareness of Jade: indeed, it would allow for intera tions between the Fra talJade omponentstaking into a ount grid onstraintsashigh-laten y, dynami ity, non-se ure ommuni ation hannels.

Contents

1 Introdu tion 3

2 State of the arton Grid monitoring 5

2.1 GridInformationServi esforDistributedResour esSharing. . . 5

2.1.1 Paperreferen e . . . 5

2.1.2 Briefsummary oftheproje tdes ribedin thepaper . . . 5

2.2 Autopilot: AdaptiveControlofDistributedAppli ations . . . 6

2.2.1 Paperreferen e . . . 6

2.2.2 Briefsummary oftheproje tdes ribedin thepaper . . . 6

2.3 AS alableWide-AreaGridResour esManagementFramework . . . 6

2.3.1 Paperreferen e . . . 6

2.3.2 Briefsummary oftheproje tdes ribedin thepaper . . . 7

2.4 AGridMonitoringAr hite ture. . . 7

2.4.1 Paperreferen e . . . 7

2.4.2 Briefsummary oftheproje tdes ribedin thepaper . . . 7

2.5 Ataxonomyofgridmonitoringsystems . . . 9

2.5.1 Paperreferen e . . . 9

2.5.2 Briefsummary oftheproje tdes ribedin thepaper . . . 9

2.6 SynthesisandGeneralremarks . . . 10

3 Jade ar hite ture 12 3.1 Presentation. . . 12

3.2 S alabilityissues . . . 13

4 S alable monitoringwithinJade 14 4.1 ProA tive-baseddeployment. . . 14

4.2 Towardsahierar hi alorganisationof Jade . . . 14

4.2.1 JadeMirror . . . 14

4.2.2 JadeMirrordesignandasso iatedimplementation . . . 16

Referen es

[1℄ L.Baduel,F. Baude,D. Caromel,A. Contes, F.Huet, M.Morel, andR. Quili i. Grid Computing: Software Environments andTools, hapter Programming,Composing, De-ploying,fortheGrid. SpringerVerlag,2005.

[2℄ S. Bou henak,F.Boyer,D. Hagimont,S. Krakowiak,N. dePalma,V. Quéma,and J.-B.StefaniD. Ar hite ture-basedautonomousrepairmanagement: Appli ationto J2EE lusters. InIEEEInternational Conferen eon Autonomi Computing(ICAC'05), short paper, 2005.

[3℄ S. Bou henak, N. D. Palma, D. Hagimont, and C. Taton. Autonomi Management of Clustered Appli ations. In IEEE International Conferen e on Cluster Computing (Cluster2006), Bar elona,Spain,Sept. 2006.

[4℄ D.Caromel,C.Delbé,A.diCostanzo,andM.Leyton.ProA tive: anintegratedplatform for programmingand runningappli ations on grids and P2P systems. Computational MethodsinS ien eandTe hnology, 12(1):6977,2006.

[5℄ CoreGRIDProgrammingModelVirtualInstitute. Basi featuresofthegrid omponent model (assessed),2006. Deliverable oftheCoreGRIDNetworkofEx ellen e, Program-mingModelVirtualInstitute,D.PM.04.

2004, route des Lucioles - BP 93 - 06902 Sophia Antipolis Cedex (France)

Unité de recherche INRIA Futurs : Parc Club Orsay Université - ZAC des Vignes

4, rue Jacques Monod - 91893 ORSAY Cedex (France)

Unité de recherche INRIA Lorraine : LORIA, Technopôle de Nancy-Brabois - Campus scientifique

615, rue du Jardin Botanique - BP 101 - 54602 Villers-lès-Nancy Cedex (France)

Unité de recherche INRIA Rennes : IRISA, Campus universitaire de Beaulieu - 35042 Rennes Cedex (France)

Unité de recherche INRIA Rhône-Alpes : 655, avenue de l’Europe - 38334 Montbonnot Saint-Ismier (France)

Unité de recherche INRIA Rocquencourt : Domaine de Voluceau - Rocquencourt - BP 105 - 78153 Le Chesnay Cedex (France)