HAND: Highly Available Dynamic Deployment Infrastructure for Globus Toolkit 4

Transcription

1 HAND: Hghly Avalable Dynamc Deploymen Infrasrucure for Globus Toolk 4 L Q 1, Ha Jn 1, Ian Foser,3, Jarek Gawor 1 Huazhong Unversy of Scence and Technology, Wuhan, , Chna quck@chnagrd.edu.cn; hjn@hus.edu.cn Mahemacs and Compuer Scence Dvson, Argonne Naonal Laboraory, Argonne, IL 60439, U.S.A. {foser, gawor}@mcs.anl.gov 3 Deparmen of Compuer Scence, Unversy of Chcago, Chcago, IL 60637, U.S.A. Absrac Grd compung s becomng more and more aracve for coordnang large-scale heerogeneous resource sharng and problem solvng. Of parcular neres for effecve Grd compung s a sofware provsonng mechansm. We propose a hghly avalable dynamc deploymen nfrasrucure, HAND, based on he Java Web Servces Core of Globus Toolk 4. HAND provdes capably, avalably, and exensbly for dynamc deploymen of Java Web Servces n dynamc Grd envronmens. We denfy he facors ha can mpac dynamc deploymen n sac and dynamc envronmens. We also presen he desgn, analyss, mplemenaon, and evaluaon wo dfferen approaches o dynamc deploymen (servce level and conaner level). And examne he performance of alernave daa ransfer proocol for servce mplemenaons. Our resuls demonsrae ha HAND can delver sgnfcanly mproved avalably and performance relave o oher approaches. 1. INTRODUCTION A Grd s an Inerne-conneced compung envronmen n whch compung and daa resources are geographcally dsrbued n dfferen admnsrave domans, ofen wh separae polces for secury and resource use. Wh he nroducon of OGSA [11], he focus of Grd compung moved from legacy compung-nensve applcaons o servce-orened compung based on open sandards. Globus Toolk (GT) developmen has racked hs rend, wh GT4 [10, 1] buldng on he Web Servce Resource Framework (WSRF) specfcaons o provde an effcen, exensble, saeful, and flexble Grd mddleware. Experence whn ChnaGrd [1, 9] and elsewhere [, 17] has emphaszed he mporance of dynamc servce deploymen and managemen as an enabler of dynamcally exensble vrual organzaons (VOs) [8]. More specfcally, we denfy he followng requremens when servces are hosed on a dynamc managemen-enabled Grd: Servces mus adap a run me o changes of scale n VOs and o changes n he number of users. I mus be easy o reconfgure, redeploy, and undeploy servces, whou shung down he whole sysem. Grd sofware provsonng mus ake no accoun dynamc and unpredcable servce demand from VO members. The avalably of arge managemen uns for servce requess should be maxmzed. Dynamc feaures should resul n mnmal developmen and managemen coss; ha s, users mus no be requred o mplemen numerous nerfaces or rules for dynamc deploymen feaures. Dynamc deploymen s a bg challenge: frequen shung down and sarng up of servces for sofware upgrades or changes n resources or users can ncrease managemen coss. Some dynamc deploymen soluons have been proposed based on Apache Tomca s dynamc deploymen funconaly [, 3, 14]. However, ha nfrasrucure provdes poor performance and avalably, wh he consequence ha (for example) dynamc deploymen durng a workflow s execuon can cause a crcal ask o fal. In anoher scenaro, f a deploymen operaon s delayed or canceled because he arge conaner s unavalable, he dependen ask would also be delayed or canceled. Before dscussng he desgn and mplemenaon of our dynamc deploymen nfrasrucure, we nroduce some basc conceps: Conaners n a Web Servces-based sysem such as GT4 hos servces and execue user requess ssued by clens ha nvoke operaons defned by hose servces. The erm dynamc deploymen denoes he ably for remoe clens o reques he upload and deploymen of new servces no, or he undeploymen of exsng servces from, exsng conaners. Issues of correcness and performance are of parcular mporance when servce requess and deploymen requess occur concurrenly. We defne avalably n a dynamc deploymen nfrasrucure as he proporon of me a sysem s n a funconng condon. The meanng of funconng s dfferen for wo ypes of clens. End users of servces deployed n he conaner care abou he success rae of her requess and he response me of hose requess. Key ssues for hese users are he exen o whch a conaner becomes naccessble durng dynamc deploymen, and any overhead mposed on ordnary requess by he dynamc servce nfrasrucure (e.g., due o lockng). Users who deploy servces, ypcally admnsraors, care abou boh he success rae and average me cos of he dynamc deploymen requess hemselves. Based on hese consderaons, we adop as mercs he success rae of user requess, he average me cos for deploymen requess, and he deploymen avalably.

2 To mplemen hghly avalable and capable dynamc deploymen funconaly, we propose HAND (Hghly Avalable dynamc Deploymen). The desgn of HAND s nended o mee sx crera: 1. A conaner ha receves a dynamc deploymen requess should complee exsng user requess f possble, whle ensurng ha he dynamc deploymen reques s acceped as scheduled.. User requess receved durng execuon of a dynamc deploymen procedure should be handled correcly f possble. 3. When a dynamc deploymen procedure s fnshed, user requess for newly nsalled servces should be handled correcly. 4. The deploymen procedure should be decomposed no smaller seps o reduce he rsk of deadlock. Generally, deadlocks n he dynamc deploymen procedure arse when hreads use common runme resources (e.g., he common ClassLoaders) concurrenly. Smplfyng and decomposng he deploymen seps no smaller subseps can reduce he me ha he deploymen hreads and ordnary hreads occupy shared resources. 5. Mulple redundancy approaches should be provded o boh remoe and local users n order o reduce unavalably. If one approach proves o be unavalable, a user or conaner can adop oher approaches as backup o fnsh he deploymen. 6. The performance of he deploymen procedure should be opmzed o decrease he possbly of conflc beween ordnary and deploymen requess. In shor, he overhead caused by he dynamc deploymen nfrasrucure should be as small as possble o he ordnary requess. In he followng, we explore how our performance mercs can be maxmzed and hese crera me va wo dfferen approaches o dynamc deploymen: Servce-level deploymen (HAND-S), n whch we deacvae one or more exsng servces, nsall new servces, and re-acvae hose servces whou reloadng he whole conaner. Conaner-level deploymen (HAND-C), n whch he nsallaon of any new servce nvolves reloadng (renalzng and reconfgurng) he whole conaner. We shall descrbe mplemenaon echnques for boh approaches and presen expermenal resuls ha demonsrae ha when HAND works concurrenly n a dynamc nework envronmen, can delver capably and avalably ha are accepable and ha mee he crera descrbed above. The res of hs arcle s as follows. In Secon we descrbe he HAND archecure and mplemenaon. In Secon 3 we show how users can ulze he dfferen deploymen levels and approaches o mprove he avalably and capably of dynamc deploymen. In Secon 4 we presen our evaluaon of he mplemenaon. In Secon 5 we dscuss relaed work. In Secon 6 we conclude wh a bref dscusson of fuure research.. HAND DESIGN AND IMPLEMENTATION Provsonng s an mporan feaure n cluser compung and has been ncluded n he OGSA specfcaon [11]. However, he GT3 and GT4 releases of he Globus Toolk Java Web Servce Core have no addressed dynamc servce deploymen. Wessman e al. [] have mplemened dynamc deploymen n GT by buldng on he dynamc deploymen-enabled Apache Tomca server as he hosng envronmen. Wh hs approach, users package her servces wh he basc Java WS Core lbrares as a WAR fle and deploy no Tomca as a Web applcaon. Wh he help of Tomca Manager he user can redeploy hs applcaon dynamcally whou resarng Tomca or nerferng wh oher Web applcaons. An alernave approach (adoped here) s o refacor he kernel srucure of he Java WS Core sandalone conaner. Ths approach s more complcaed as requres low-level changes o he conaner. However, we gan he benef of a more lghwegh dynamc deploymen mplemenaon and smpler managemen. Wh hs approach, we can use he Grd archve (GAR) forma for servces and reuse GT s exsng deploymen mechansm. The resul, as we shall show, s a hghly avalable dynamc deploymen nfrasrucure. Weghng hese advanages and dsadvanages, we desgned and mplemened HAND n hree pars, as llusraed n Fgure 1. The shaded componens Servce Package Manager, Auo Deployer, and Local Drecory are oponal; hey are provded o suppor fuure advanced provsonng feaures. Fgure 1 Dynamc deploymen modules.1 Dynamc Deployer Core The Dynamc Deployer Core (DDC) s he kernel par o realze he dynamc deploymen n HAND and mee he crera descrbed n Secon 1. The challenge n he DDC s o resolve wo facors: 1. The deacvaon and acvaon of he servces and conaner.

3 . The updae of he runme conex n JVM, especally n case of dynamc and mulple ClassLoaders. To address me cos and safey ssues, we use wo ClassLoaders o solae manageable servces from sysem servces. The common ClassLoader s responsble for he basc lbrares used o run he conaner such as he XML parser, he SOAP engne, loggng, and secury; hs ClassLoader s no reloadable. The servce ClassLoader s responsble for loadng servce lbrares and s fully reloadable. As shown n Fgure 1, DDC s comprsed of seven pars. The GAR Deployer s n charge of nvokng he acual deploymen acons. In he HAND, a reloadng acon can be safely execued once all servces are shu down bu before a new servce ClassLoader s obaned. The Undeployer, Reloader, and Deployer are reloadng acons ha can be passed from he Deploy Approach Manager o he GAR Deployer. Reloadng acon can updae he servce lbrares, confguraon fles, and so forh. The Valdaer s responsble for checkng he correcness of he GAR fle ha s beng deployed. I prevens DCC from deployng nvald or malformed GAR fles. The Loggng module s used o record a dealed log of he execuon of he reloadng acons. Fnally, he Resorer s a smple backup mechansm. In case of an error can help he conaner o resore o s prevous workng sae.. Deploy Approach Manager The Deploy Approach Manager (DAM) akes as npu a GAR fle n Java archve forma. Ths fle consss of a Web Servce deploymen descrpor (WSDD), WSRF resource descrpor fles, and applcaon mplemenaons and subs. The GAR fle mgh conan zero or more servces. DAM addresses our desre for redundan approaches (Crera 5) by exendng GT4 o provde hree approaches o servce deploymen. The Auo Deployer s an expermenal componen ha allows users o deploy and undeploy a arge GAR fle no a conaner by copyng no a specfc drecory on he local fle sysem. Ths feaure s convenen for local admnsraors. The An Scrps are nended for he offlne approach of deployng and undeployng he GARs. Ths approach works only when he conaner s off. Ths resrcon s necessary n order o preven conflcs ha could arse when deployng no a runnng conaner. The Remoe Deployer s a sandard WSRF servce deployed n DDC. Named DeployServce, hs servce suppors fve operaons: upload, download, deploy, undeploy, and reload. The frs wo operaons provde wo dfferen approaches o ransferrng a GAR fle ha s o be deployed o he conaner: 1. Va SOAP wh aachmens usng he upload() funcon. The GAR fle s aached o he reques.. Va he download() funcon. The reques specfes a URL (HTTP/S, GrdFTP/FTP, ec.) for he GAR fle, and he DeployServce uses globus-url-copy o copy he GAR fle from ha URL locaon o he local fle sysem. 3 Once a GAR fle s ransferred, he DeployServce reurns an denfer for he GAR. The GAR fle can hen be deployed by callng he deploy() funcon wh ha denfer. Once a GAR fle s deployed, he DeployServce delees he fle auomacally. A deployed servce can be undeployed va he undeploy() operaon. In addon, a clen can reload he enre conaner by nvokng he reload() operaon, whch resars he conaner whou execung any deploymen acons. Ths operaon s useful when a servce or conaner confguraon has changed. The DeployServce publshes wo resource properes: 1. Undeployable: a ls of GAR denfers ha can be undeployed.. Deployable: a ls of GAR denfers ha have been ransferred o he servce bu no ye deployed. GSI auhencaon and auhorzaon are used o ensure ha only auhorzed clens can nvoke he DeployServce operaons..3 Servce Package Manager The oponal Servce Package Manager (SPM) provdes hgher-level managemen feaures. In parcular, he Package Lfecycle and Package Regsry Table manan nformaon necessary for he servce-level mplemenaon. Snce each GAR fle may conan several servces, servce-level managemen canno be based on a smple GAR fle managemen sysem. In our servce-level mplemenaon, SPM communcaes wh DDC o manage he arge servces dynamcally. The SPM also ncludes hree componens Verson Conrol, Cusomzed Deploymen, and Valdang Checker ha complee he complcaed servce-level Grd sofware verson conrol and onlne upgrades n dfferen VOs. Verson Conrol s responsble for he verson managemen of dfferen servces. I also provdes meadaa abou cross-dependences for he conaner sysem. I avods upgrades of dfferen applcaons JARs. Cusomzed Deploymen perms remoe users o subm her own deploymen scrps; for example a user can deploy an RPM package o a arge sysem. The Valdang Checker s smlar o he DDC Valdaer. A mnor dfference s ha focuses on more complcaed dependences and conflc checkng among dfferen servces before deploymen. 3. SERVICE-LEVEL VERSUS CONTAINER-LEVEL We defne wo approaches whch s also he effor o mee Crera-5 o dynamc deploymen: In conaner-level deploymen (HAND-C) he enre conaner s reloaded; ha s, all servces n he conaner are deacvaed and re-acvaed. In servce-level deploymen (HAND-S) a sngle servce ha s beng deployed or undeployed s deacvaed and re-acvaed. All oher servces are unaffeced.

4 We have mplemened boh approaches whn GT4. The conaner-level mplemenaon s complee and has been merged no he GT code reposory 1. The servce-level mplemenaon s a prooype, suable for performance sudes bu no ye for producon use. Boh approaches are mporan and useful n dfferen scenaros, as we now dscuss. Conaner-level deploymen works well when a global upgrade or confguraon s needed, whle servce-level deploymen s more flexble and avalable n dynamc envronmens. 3.1 HAND-C: Conaner-Level Deploymen Conaner-level deploymen proceeds as follows o reload a servce mplemenaon: 1. Pu he conaner n reloadng mode. The conaner wll hen reurn servce unavalable error o any reques ha he conaner receves durng he deploymen. Ths sep blocks unl all currenly execung requess fnsh or unl a specfed meou expres (whchever occurs frs).. Sop and deacvae all servces, resource homes, and so forh. 3. Perform cleanup operaons o flush caches ha mgh conan references o he resources and classes loaded by he orgnal deploymen. 4. Execue he deploymen or undeploymen scrps. 5. Reload he whole conaner. Confguraon descrpor fles, ec. are re-read, and all servces, resource homes, ec., are re-acvaed. 6. Reurn he conaner o he normal operang mode, and sar accepng new requess. Ths algorhm n parcular,he use of meous n Sep 1 seeks o balance he demands of Crera 1 above wh conaner sably. Seps and 3 are execued o address Crera 3. We noe ha hs algorhm does no address Crera : all user requess o a conaner are refused durng any dynamc deploymen operaon on ha conaner. The melne n Fgure depcs a ypcal deploymen operaon. In hs fgure, Servce Sesson denoes an execuon of an ordnary reques and Deploy Sesson he execuon of a deploymen reques. Movng from he op down, we see frs a reques ha s nerruped due o he Sep 1 meou; hen hree requess ha complee successfully agans he old servce verson; hen he deploymen reques; hen hree requess ha are refused because deploymen s n progress; and fnally wo requess ha execue successfully agans he new verson of he servce. Ths approach s smlar o ha used n he Tomca conaner. I has he followng advanages: I avods deadlock for does no care abou he dependences among he servces deployed n conaner. I jus reloads he whole conaner. I works well when we need o reload he whole servce conaner, ncludng he global confguraon, servce handlers, and provders. In case of a global 1 The sable mplemenaon can be checked ou from :pserver:anonymous@cvs.globus.org:/home/globdev/cvs/glo bus-packages wh module name wsrf. 4 nsallaon and confguraon ssued or servce-level reload operaon faled, he conaner-level reload s sgnfcan o promse he conaner keepng sable. I mnmzes memory and me coss n managemen, snce all servces share he same runme conex,.e. he common servce ClassLoader, unfed deacvang and acvang procedures, and GAR managemen. Fgure : Conaner-level deploymen avalable sequence On he oher hand, conaner-level deploymen has dsadvanages: (Re)deploymen of any servce resuls n he loss of nonperssen sae assocaed wh all servces. Whle arguably no servce mplemenaon should make any assumpons concernng he avalably of nonperssen sae, n pracce people ofen wre servces wh such assumpons n mnd. Thus, dynamc deploymen can resul n unpredcable behavors for clens. Deploymen me s unpredcable when several parallel hreads are nvolved (see Secon 4.3). 3. HAND-S: Servce-Level Deploymen Servce-level deploymen requres complee servce solaon (ncludng he servce JAR fles), a herarchcal ClassLoader ree (a separae ClassLoader for a se of servces assocaed wh a GAR fle), and an SPM o manage he separae servces. Ths approach allows us o address Crera of Secon 1: he reducon n reloadng granulary means ha he deploymen procedure need no mpac requess o oher servces unrelaed o hose ha are beng deployed. Our servce-level deploymen logc mees hese requremens as follows: 1. Check he requesed arge servce name. If maches he DeployngServce, hen swch he ClassLoader o sysem level, or use he normal servces own ClassLoader regsered n he SPM. If requess are beng processed ha nvolve he servces ha are o be deployed, hen suspend deploymen unl hose requess complee or a meou occurs.. Sop he servces ha are o be deployed f hey are already runnng. Durng hs perod, he conaner wll reurn servce unavalable o any reques o he servces n he GAR fle.

5 3. Sop any servces on whch he pre-deployed servces depend, and deacvae any relaed resources. Typcally, hese servces are named n he pre-deployed GAR fle. 4. Perform cleanup operaons o flush caches ha mgh conan references o he classes loaded by he orgnal deploymen (jus for redeploy). 5. Execue he deploymen or undeploymen scrps. 6. Creae or updae he workng space conex for he new servces, and hen regser o he SPM regsry. 7. Inalze, acvae, and sar he new servces. The man dfference beween hs approach and he conaner-level approach s ha he reloadng un here s he servce raher han he conaner as n HAND-C. Fgure 3 shows wha happens when requess arrve durng dynamc deploymen n HAND-S. Requess 1,, 3, 4, 6, and 8 are o servces oher han he servces beng deployed, and can hus proceed whou nerrupon. Only he 7h and 10h requess are o a servce ha s beng deployed, and hus hese wo requess fal and succeed, respecvely, as hey occur durng and afer deploymen. Servce-level deploymen has he followng advanages relave o conaner-level deploymen: The me requred o reload a servce s more predcable as depends prmarly on characerscs of ha servce, no oher componens deployed n he same conaner. Because here s no need o wa for and deacvae all servces n he conaner, servce-level deploymen s much faser n mos cases. 5 If he regsry srucure s desroyed or he global confguraon s updaed, we mus use conaner-level deploymen o renalze he whole conaner. 3.3 Tme Cos Analyss We now dscuss he coss assocaed wh he wo deploymen approaches. We use he symbols n Table 1. TABLE 1 SYMBOLS USED IN THIS PAPER Noaon Defnon oal Toal me requred o deploy a arge GAR fle. ransfer Tme requred o ransfer he GAR fle. pendng deploy reload lm sysem Tme requred o wa for he conaner o become avalable. Deploymen me for scrp processng durng deploymen. Tme requred o resar conaner or servces. Reload meou lmaon for a runnng servce. Sysem cos o reload he conaner self. Tme o sop and deacvae arge servce. Tme o acvae and sar arge servce. s Execuon me lef for unfnshed reques. R Runnng servces ha are requesed durng dynamc deploymen and are beng processed on he conaner. D Deployed servces on he arge conaner; hese are he aggregae of all he servces deployed on he arge conaner, wheher acvaed or deacvaed. D Servces ha are prepared o be deployed. To mee Crera 4, as shown n Fgure 4, he deploymen procedure n HAND consss of several phases: deploymen preparaon, physcal deploymen, and sysem reloadng. The dashed Pendng box ndcaes ha depends on he concree approach (HAND-S or HAND-C) chosen o ssue he reloadng. Fgure 3: Servce-level deploymen avalable sequence Servce-level deploymen also has lmaons: There s a need for addonal nernal synchronzaon n he conaner, whch can be cosly. The conaner should swch among dfferen ClassLoaders o mach he varous servce requess, and mus also manan conssency wh perssen sorages (a XML fle n our mplemenaon), JNDI resources, and Caches exsng n servce nsances. Furhermore, HAND-S canno handle crcular dependences among servces well. (The dependency of servce composon s anoher crcal challenge n Grd whch wll be dscussed n our fuure papers.) The need for a more dealed regsry resuls n ncreased memory usage and execuon me coss. Fgure 4: Three-phase deploymen procudure The oal dynamc deploymen me consss of four pars: = (1) oal ransfer pendng deploy reload The deploy and ransfer componens are deermned by he deploymen mehods used n he preparaon phase and he complexy of he ANT scrps ha mplemen deploymen acons, boh of whch are ndependen of he deploymen procedure.

6 For HAND-C, pendng and reload are as follows. = mn(max(s ), R ) () pendng lm R n reload = ( + ) + sysem, n = D = 1 (3) Based on he dscusson n Secon 3., we conclude ha he pendng me s manly spen wang for compleon of exsng requess. Hence, he oal me s he mnmum of he maxmum remanng me of he currenly execung requess and he me requred o nerrup for all runnng hreads. The reloadng me s equal o he sysem reloadng me plus he deacvaon and acvaon me for all deployed servces. For HAND-S, he pendng me s he me spen wang for compleon of exsng requess for he arge servce and any relaed servces. (However, we noe ha he problem of servce dependency s complcaed; we wll nvesgae and dscuss n fuure papers.) Here, we assume ha relaed servces D are jus he servces defned n he GAR s Web Servce Deploymen Descrpor (WSDD) fle. The reloadng me shrnks o he sum of he deacvang me and acvang me of he relaed servces. = mn( max( s ), D I R ) (4) pendng reload = D R D IR + D lm I (5) We defne oal (HAND-S) and oal (HAND-C) as he me cos for wo approaches, and we assume ha boh approaches use he same deployng mehod and he same GAR fle. The relaonshp beween runnng servces, predeployed servces, and deployed servces s D I R R D (6) If he processng requess fnshed a he same me, hen pendng (servce) pendng (conaner). Smlarly, we can acheve reload (servce) reload (conaner).. Hence, s no oo dffcul o conclude ha oal (servce) oal (conaner) n a dynamc nvocaon envronmen. 4. EVALUATION A comprehensve evaluaon of dynamc deploymen s challengng because of he dffculy of capurng he complexes of a realsc Grd envronmen. Thus, we focus on mcro-benchmarks desgned o capure specfc aspecs of dynamc deploymen behavor, namely, deploymen me, capably and avalably, and fle ransfer performance. 4.1 Dynamc Deploymen Expermens As dscussed n Secon 3, he servce conaner becomes unavalable durng dynamc deploymen. Thus, we frs measured deploymen me as a funcon of boh he sze of he fle beng deployed and he number of servces n he conaner. The expermenal seup was as follows. We nsalled and esed he HAND conaners a wo ses: a local se wh hree PC servers, powered by Penum 4.4 GHz wh GB 6 RAM and 37 GB hard dsk n a cluser; and a remoe se equpped wh one PC server, powered by Penum III 1 GHz wh 104 MB RAM. The wo ses were conneced by a.5 G fabrc WAN shared wh oher CERNET applcaons. The local cluser was conneced wh 100 Mb Eherne. All ess ran on Fedora 3 wh Lnux kernel The Java verson was JSDK 1.4._08-b03, and we used Xms64m and Xmx104m parameers o enlarge he maxmum JVM memory. We consruced a se of Grd Archve (GAR) fles for use n our expermens, as summarzed n Table. The frs fve fles ranged n szes from 4 KB o 100 MB, a range ypcally encounered n Grd applcaons. We also consruced a large number of dencal servces, esservce_clone0 o esservce_clonen, for evaluang he mpac of he number of deployed servces on performance. The Jar Scale column n Table denoes how many JAR fles were n he package; he Compresson Rae s he rao of compressed fle sze o he orgnal. TABLE TEST PACAKGES USED IN OUR EXPERIMENTS Id Package Name Fle Sze (KB) Jar Scale Compresson Rae (%) 1 esservce1.gar 4 63 esservce.gar 1, esservce3.gar 1, esservce4.gar 4, esservce5.gar 98, n esservce_clone N.gar We measured he me requred o deploy each of fles 1-5 of Table no a conaner runnng nne servces he basc servce se deployed by defaul by GT. The only reques made durng he dynamc deploymen procedure was ha o DeployServce. Each deploymen was repeaed 40 mes. We presen he deploymen and reloadng mes (as dscussed n Secon 3.3); he pendng me s zero n hs case. Fgure 5 gves our resuls. Tmers n our mplemenaon allow us o break down he oal deploymen me no he followng caegores: Deploy (D), whch ncludes he physcal deploymen me (D-D) and reloadng me (D-R) as dscussed n Secon 3.3. Redeploy (R), whch ncludes he physcal redeploymen me (R-D) and reloadng me (R-R). Undeploy (U), whch also ncludes he physcal undeploymen me (U-D) and reloadng me (U-R). The me requred o execue physcal deploymen scrps s he bgges cos n he Deploy operaon (D); he physcal redeploymen me (R-D) cos s slghly greaer han ha. Each redeploy operaon consss of a sequence of undeploy and deploy operaons. In HAND-C, he frs sep of deploymen s o check wheher or no he new GAR s already deployed. Undeploy smply delees all deployed fles and reloads he conaner; he me cos s decded manly by U-D, whch naurally ncreases wh GAR fle sze. Thus, we can deermne ha he reloadng me, equal o he dfference beween he operaon mes (D/R/U) and he physcal deploymen mes (D-D/R-D/U-D), ncreases slowly as he

7 GAR sze changes. Inally, he bgges me cos of an aomc operaon s jus less han 0 seconds, whch we beleve s olerable for mos Grd applcaons. 7 Fgure 7: Leas Quadrac fng curve for reload operaon Fgure 5: Operaon comparsons To deny addonal mpac facors on deploymen and reloadng coss, we enlarged he deployed servce scale from nne o 879 servces. Fgure 6 shows he resuls of hs new expermen. In hs fgure, he z axs expresses he me cos for reloadng he conaner. The resuls show ha reloadng me ncreases wh he number of servces. In he servce scale, he reloadng me of dfferen-szed GAR fles s nearly he same when he GAR fle sze s less han 4 MB. However, he me ncreases rapdly when he GAR fle sze ncreases o abou 100 MB. The resuls show nearly he same lneary n smaller GAR fles (4 KB o 4 MB), bu become bumpy when he GAR fle sze ncreases o abou 100 MB. The reason s ha he JVM s garbage collecor runs n he background randomly. When he deployed servce sze s bg enough, garbage collecon shares he reloadng me wh he HAND core. Generally, he rend should be ncreasng. Even n he verex, he reloadng me s beneah 30 seconds, whch wll sasfy he requremens of mos Grd applcaons n a sac envronmen. Accordngly, our servce-level mplemenaon s affeced less by garbage collecon, even for he bgges GAR fle. In addon, coss less me o fnsh he reload operaon. Fgure 6: Scaled comparson on reload Based on he resuls from Fgure 6, we dscard he bumpy conaner-level daa and hen aemp o f a curve o our wo ses of daa. As descrbed n [1], we defne x as he deployed servce scale and y as he reload me cos, and assume kh degree polynomal as: y = a (7) k 0 a1x a kx The resdual s gven by n k R = y ( a + a x a x )] = 0 [ 0 1 k (8) By usng leas quadrac fng echnque, we flled n our daa, and fnally acheved when k equals, we could ge he fes polynomal for wo levels. As formulas ls below, y c s he conaner-level me cos polynomal and y s s he servce-level. y y = x x , R (9) c = = x x ,R = (10) s. Fgure 7 denoes our f curves. We see ha servce-level reloads are less expensve han conaner-level reloads n all crcumsances. Ths resul confrms our earler analyses and maches our conclusons n prevous secons. We noe ha he avalably of suffcen memory for servce-level deploymen s an mporan precondon for hs resul. From formula 9 and 10, we see ha f no servces are deployed, boh approaches ncur a reload cos of around 300ms. And n boh cases, he polynomal me are all O(x ). To enable drec comparson wh oher dynamc deploymen enabled conaners, we repeaed our expermens on he Apache Tomca conaner (verson ), as used by Wessman e al. [, 3] and Mahew e al. [17]. (However, we noe ha we use GT4, no GT3 as used by hose auhors.) Also, we ncreased he JVM memory o 1G by addng he -Xms64m Xmx104m parameer. Fgure 6 presens he expermenal resuls n he dfferen servce-level (10, 00, 400, and 600 servces) envronmen. In hs fgure, HAND-C s our conaner-level mplemenaon, HAND-S s he servce-level mplemenaon, and TOMCAT denoes he Apache Tomca hosng envronmen.

8 Fgure 8: Comparsons agans he Tomca conaner We see n Fgure 8 ha boh HAND-C and HAND-S use less me o reload han does Tomca, parcularly when few servces are deployed. (The one excepon s n 8(B), when HAND-C s slghly slower han Tomca for he larges fle.) Ths effec s parcularly evden n he case of our servce-level mplemenaon (Tomca s a conaner-level mplemenaon), bu s also evden n he case of he conaner-level mplemenaon, presumably because Tomca ypcally deacvaes or acvaes more componens, ncludng Apache Axs self, cluser componens, Jasper, and he lke. The HAND core, however, manly nvolves only Apache Axs and jus reloads he ClassLoader and updaes he JNDI ree appropraely. In 8-D, Tomca ssues an ou of memory excepon for he larges GAR fle, whch s parcularly concernng our desre for conaner sably. As shown above, f suppor for massve dynamc deploymen-enabled applcaons s needed, one should use he HAND conaner nsead of Tomca o guaranee capably, usably, and relably. 4. Capably and Avalably n Dynamc Envronmen Our nex expermens were desgned o sudy neracons beween servce deploymen operaons and oher requess o a conaner. We desgned hese expermens as follows: 1) We frs dynamcally deployed egh cloned servces ha ake, respecvely, 0, 30, 60, 90, 10, 180, 40, and 330 seconds o process a user reques. ) We hen sared four clen hreads, each of whch ssued a seres of 1,000 nvocaons, each o one of he egh servces sared n #1. These hreads also logged boh faled and successful nvocaons. 3) We also sared a hread ha ssued a seres of 100 deploy requess a random nervals durng he perod of Sep. Each such reques deployed, redeployed, and undeployed one of a second se of 10 cloned servces. We ran expermens on boh HAND-C and HAND-S, and used four parallel hreads o do our expermens, whch s he hgh waer mark of he GT4 Java core conaner (.e., he 8 medum overhead of GT conaner). We confgured he GT4 conaner wh 35 deployed servces, whch means (based on he resuls of Secon 4.1) ha HAND-C should ncur a reloadng cos of 875ms and HAND-S a cos of 36ms. Fnally, we noe ha al deployed servces are unrelaed n logc:.e., servces n dfferen GARs do no nvoke he ohers ClassLoaders. Fgure 9 shows ha he deploymen me ncreases rapdly wh servce servng me for HAND-C, due o he need o wa for he compleon of servce nvocaons ha are already n progress. When servce servng me s long enough (he cross mark n he fgure), namely, greaer han he reloadng med-ou lmaon (defaul 5 mnues n HAND-C), he deploymen operaon s canceled, due o he clen meou of 10 mnues. In conras, whle HAND-S deploymen me s nally slghly hgher han for HAND-C, hen says farly consan as servce servng me ncreases. Fgure 10 shows ha HAND-S also acheves conssenly hgh success raes. Ths resul s as expeced, gven ha he reload of one servce does no effec oher servces n he same conaner. In conras, he HAND-C success rae s low and unpredcable. When he servce servng me grows above he reload med-ou lmaon, mos clen nvocaons are canceled because of clen meou. Fgure 9: Deploymen me n a dynamc envronmen Fgure 10: Success rae n a dynamc envronmen

9 In Table 3, we show he average deploymen me for boh HAND-S and HAND-C across hese expermens. Our resuls ndcae ha he capably of dynamc deploymen a he conaner level s unpredcable n a complcaed dynamc Grd envronmen. The cos sems from promsng he success rae of he requess before dynamc deploymen and prevenng deadlock durng conaner resar. Moreover, he success rae of normal servce requess also decreases when deploymen s rggered. Ths level s suable for clens ha ncorporae some faul olerance logc. 9 TABLE 3 COMPARISON OF EXPERIMENTAL RESULTS HAND-S HAND-C Average Deploymen Tme, ms Average Success Rae, % We conclude ha servce-level deploymen s more capable and more avalable han conaner-level deploymen for dynamc and complcaed Grd envronmens. 4.3 GAR Fle Transfer Performance Our hrd se of expermens focused on he performance of he DAM fle ransfer funcon. We evaluae he performance of hree ransfer proocols n LAN and WAN envronmens. The es packages used he fve GAR fles, whch were nvoked 0 mes each. Fgures 11 and 1 show ha n boh he LAN and WAN, he SOAP aachmen n DIME forma approach coss more han HTTP or FTP. When he GAR fle sze s near o or less han 10 MB, he SOAP aachmen s convenen for users o ransfer he arge fles drecly from he clen. For larger fles, s advsable o choose GrdFTP, FTP, or HTTP. Especally n a WAN envronmen, ransferrng bg GAR fles by SOAP aachmen wll cos more me and more server memory, and may even cause he server o run ou of memory. Compared wh HTTP, FTP may provde beer access conrol and flow conrol. For secure and relable ransfers, he GT4 GrdFTP [15] and Relable Fle Transfer (RFT) servce [16] are recommended, alhough we noe ha s GrdFTP use of publc key auhencaon mposes a sarup overhead relave o radonal FTP. Fgure 11: Transfer me comparson, n LAN Fgure 1: Transfer me comparson, n WAN 5. RELATED WORK Dynamc servce deploymen funconaly has been explored and developed n many dfferen conexs, ncludng JEE [18, 19] and Web Servces [0]. Rauch e al. [6] mplemened paron clonng and paron reposores as well as a se of OS-ndependen ools for sofware manenance usng enre parons, hus provdng a clean absracon of operang sysem confguraon saes. However, hs approach s no suable for servce-orened archecures. Moreover, he deploymen of an enre OS mage s expensve, and he deploymen self wll serously mpac sysem avalably. Chase e al. explore relaed deas n her Cluser on Demand projec []. Keahey e al. [4, 5] use vrual machne echnology (e.g., Xen, VMware) o buld vrual workng envronmens and o provde for he dynamc managemen of he Grd job lfe cycle. Ther use of vrual machnes raher han JVMs o hos user compuaons leads o somewha dfferen soluons from our servce-orened approach. ROST [7], deployed n he CROWN Grd, focuses on dynamc and remoe deploymen for WSRF core wh secure access. The developers evaluaed remoe deploymen n he load balancng of local clusers. However, hey dd no dscuss n deal he capably and avalably of deploymen. Wessman e al. presen an archecure and mplemenaon for a dynamc Grd servce archecure based on Tomca ha exends GT3 o suppor dynamc servce hosng (hosng and rehosng a servce whn he Grd n response o servce demand and resource flucuaon) [, 3]. Ther mplemenaon allows new servces o be added or replaced whou akng down a se for reconfguraon and allows a VO o respond effecvely o dynamc resource avalably and demand. Bu he mplemenaon s based compleely on Tomca s conaner-level deploymen capably, whch suffers from poor performance. These and a few oher projecs [14, 17] are he man dynamc deploymen effors for Grd applcaons. Some of hem clearly are no nended for a WSRF-enabled servce-orened archecure. Moreover, alhough some have mplemened servce-orened dynamc deploymen, hey do no address n deal he cos, namely, he capably brough

10 from dynamc deploymen self and he avalably n dynamc Grd envronmens. 6. CONCLUSION AND FUTURE WORK We have descrbed HAND, a hghly avalable dynamc deploymen nfrasrucure for use n he Globus Toolk Java Web Servces conaner. HAND addresses dynamc servce deploymen a boh he conaner level and he servce level, and hus suppors dfferen granulares wh dfferen sesson lock characerscs, applcable for dfferen Grd applcaons and scenaros. HAND can be adaped o dynamc condons and changng user requremens. Three facors ha affec HAND performance are he sze of he predeployed GAR fles, he number of servces deployed n he conaner, and he runme nvocaons and servce servng me durng deploymen. Expermens show ha HAND provdes good capably, exendbly, and avalably. We plan o complee a robus mplemenaon of our prooype servce-level deploymen. We would lke o desgn a mechansm o handle he dependency conflcs among deployed servces. Usng HAND o enhance Grd sofware provsonng s a major challenge n he Grd communy. We wll focus on negrang HAND wh he GT nformaon sysem and workflow, n order o buld a real self-confgurng, self-curng, and self-propagang Grd sysem. ACKNOWLEDGEMENTS The work of IF and JG was suppored n par by he Mahemacal, Informaon, and Compuaonal Scences Dvson subprogram of he Offce of Advanced Scenfc Compung Research, Offce of Scence, U.S. Deparmen of Energy, under conrac W Eng-38, and by he NSF NMI program. 10 Servces: A Comparson of Fve WS-Resource Framework and WS-Nofcaon Implemenaons, 14h Inernaonal Symposum on Hgh Performance Dsrbued Compung (HPDC14), 005. [11] Global Grd Forum. Open Grd Servce Archecure, Verson 1.0. hp:// [1] I. Foser, Globus Toolk Verson 4: Sofware for Servce-Orened Sysems, IFIP Inernaonal Conference on Nework and Parallel Compung, 005, Sprnger-Verlag LNCS 3779, -13. [13] Apache Axs Group. Developer Gudes. hp://ws.apache.org/axs/java/developers-gude.hml [14] P. Wason and C. Fowler, An Archecure for he Dynamc Deploymen of Web Servces on a Grd or he Inerne, Techncal Repor Seres, CS-TR-890, Unversy of Newcasle upon Tyne [15] W. Allcock, J. Bresnahan, R. Kemuhu, M. Lnk, C. Dumrescu, I. Racu, and I. Foser, The Globus Srped GrdFTP Framework and Server, SC'005, 005. [16] W. Allcock, I. Foser, and R. Maddur, Relable Daa Transpor: A Crcal Servce for he Grd, Buldng Servce-Based Grds Workshop, 004, Global Grd Forum 11. [17] M. Smh, T. Frese, and B. Fresleben. Towards a Servce-Orened Ad Hoc Grd, 3rd Inernaonal Symposum on Parallel and Dsrbued Compung/Thrd Inernaonal Workshop on Algorhms, Models and Tools for Parallel Compung on Heerogeneous Neworks (ISPDC/HeeroPar'04), 004, pp [18] F. Reverbel, B. Burke, and M. Fleury. "Dynamc Deploymen of IIOP-Enabled Componens n he JBoss Server," Componen Deploymen: Second Inernaonal Workng Conference, CD 004, Ednburgh, UK, May 0-1, 004. pp [19] N. Srdhar, J. O. Hallsrom, and P. A. Svlo. Conaner-based componen deploymen: A Case Sudy, Techncal Repor OSU-CISRC-/04-TR08, Compuer Scence and Engneerng, The Oho Sae Unversy, Columbus, OH, February 004. [0] B. Benaallah, M. Dumas, Q. Z. Sheng, and A. H.H. Ngu. "Declarave Composon and Peer-o-Peer Provsonng of Dynamc Web Servces,". In 18h In. Conference on Daa Engneerng (ICDE), pages , San Jose, CA, February 00. IEEE Compuer Socey. [1] Erc W. Wessen. "Leas Squares Fng--Polynomal." From MahWorld--A Wolfram Web Resource. hp://mahworld.wolfram.com/leassquaresfngpolynomal.hml [] Chase, J., Gr, L., Irwn, D., Moore, J. and Sprenkle, S. Dynamc Vrual Clusers n a Grd Se Manager. In 1h Inernaonal Symposum on Hgh Performance Dsrbued Compung (HPDC-1) REFERENCES [1] H. Jn. ChnaGrd: Makng Grd Compung a Realy, Proceedngs of ICADL 04, Lecure Noes n Compuer Scence, (004), 3334, [] J. Wessman, S. Km, and D. England. Supporng he Dynamc Grd Servce Lfecycle, CCGrd04, 004. [3] J. Wessman, S. Km, and D. England. A Framework for Dynamc Servce Adapaon n he Grd: Nex Generaon Sofware Program Progress Repor, 19h IEEE Inernaonal Parallel and Dsrbued Processng Symposum (IPDPS'05), 005. [4] K. Keahey, I. Foser, T. Freeman, X. Zhang, and D. Galron. Vrual Workspaces n he Grd, Europar 005, Lsbon, Porugal, Sepember, 005. [5] K. Keahey, I. Foser, T. Freeman, and X. Zhang, Vrual Workspaces: Achevng Qualy of Servce and Qualy of Lfe n he Grd, Scenfc Programmng [6] F. Rauch, C. Kurmann, and T. M. Srcker, Paron Reposores for Paron Clonng OS Independen Sofware Manenance n Large Clusers of PCs, IEEE Inernaonal Conference on Cluser Compung, 000, [7] H. Sun, Y. Zhu, C. Hu e al. Early Experence of Remoe and Ho Servce Deploymen wh Trusworhness n CROWN Grd, APPT 005: [8] I. Foser, C. Kesselman, S. Tuecke, The Anaomy of he Grd: Enablng Scalable Vrual Organzaons, Inernaonal J. Supercompuer Applcaons, 15(3), 001. [9] Y. Wu, S. Wu, H. Yu e al. CGSP: An Exensble and Reconfgurable Grd Framework, APPT 005, pp [10] M. Humphrey, G. Wasson, J. Gawor, e al., Sae and Evens for Web