Remote Task Submission and Publishing in BeesyCluster : Security and Efficiency of Web Service Interface

Remote Task Submission and Publishing in BeesyCluster : Security and Efficiency of Web Service Interface Paweł Czarnul, Michał Bajor, Marcin Fraczak, Anna Banaszczyk, Marcin Fiszer and Katarzyna Ramczykowska Faculty of Electronics, Telecommunications and Informatics Gdansk University of Technology, Poland pczarnul@eti.pg.gda.pl http://fox.eti.pg.gda.pl/ pczarnul Abstract. We present a new system BeesyCluster which can be seen as an easyto-use access portal to an expandable network of services deployed and published on clusters or PCs with virtual payments for the use of services. Administrators/users can attach their clusters/pcs available via SSH with a click of the button without any need for further configuration on the provider s machine. Further, users can publish console, queued applications or files from their accounts. Services run on the provider s account but access to the services is granted through BeesyCluster either via WWW or Web Services with proper authorization. Providers earn points for their services invoked by users which allows them to use services offered by others. We compare the set of features to other systems, especially grid systems, pointing out the proposed security concept, interfaces and API. We also benchmark the Web Service interface in BeesyCluster by measurement of latency and remote task submission times on large 32-bit 128-processor and 64-bit 256-processor clusters available in the ACC network, Gdansk, Poland. We compare the results to the performance of standard Web Services with HTTP Basic Authentication and HTTPS deployed on Tomcat/AXIS. 1 Introduction Publishing services for remote clients and remote task invocation are well known concepts in the literature. CORBA, RMI allow for the client-server interaction via remote calls ([1]) as do multi-tier applications with thin/thick clients and servers like J2EE or Tomcat. For Web Services ([2]) input/output arguments are wrapped in SOAP and carried over protocols like HTTP(S) or SMTP. While conceptually equivalent to COR- BA/RMI (remote procedure call), SOAP/HTTP enables interaction between parties via usually unblocked HTTP ports making Web Services more versatile and accessible than the other technologies. available on three servers at http://beesycluster[1,2].eti.pg.gda.pl calculations were carried out at the Academic Computer Center, Gdansk, Poland work partially sponsored by the Polish National Grant KBN No. 4 T11C 005 25

2 Related Work vs. Our Contribution Controlled resource sharing between, usually large, universities and institutions, has become possible thanks to grid systems ([3]) examples of which are CrossGrid ([4]), CLUSTERIX ([5]) and EuroGrid ([6]). It must be assured that the client can neither overuse the remote resources allocated to them nor succeeds in an attempt to gain unauthorized access to other resources. Furthermore, secure data transmission, accounting and resource discovery must also be supported. Globus Toolkit ([7]) provides grid system developers with many of these functions allowing to focus on the higher level, the actual grid implementation. Legion allows users to spawn tasks remotely on a unified virtual metacomputer ([8]). H2O ([9]) is a component-level distributed system in which components can be deployed in containers, also by authorized external entities and made available to clients. While large grid systems allow the user to run tasks remotely, even via complex and easy-to-use interfaces like Migrating Desktop ([10]), still the configuration of remote sites, often difficult and time-consuming ([11] includes configuration of Worker Nodes for CrossGrid, [8] for Legion), is required. We see the above as an obstacle in building large, open systems of services with easily configurable, detachable remote sites which could very well be single PCs or clusters offering unique applications or services. We addressed these goals in a new system BeesyCluster, the continuation of our PVMWebCluster initiative ([12], [13]), which offers the following features: 1. ease of addition of a remote site (cluster/pc) to the system (requires only an account with SSH access with no additional configuration on the access node), 2. one-click service publishing from the provider s account on a cluster/pc (support for queuing systems like PBS, LSF), 3. one-click service (application, files etc.) rental capability from the provider s account(s) by any user of BeesyCluster, 4. accounting for the use of resources the provider earns points for offering services which can be spent on services offered by others, 5. access through both WWW and Web Services and discovery through BeesyCluster s own UDDI server (based on soapuddi). 3 New Concept BeesyCluster 3.1 Access Portal to HPC Facilities On the one hand, BeesyCluster can be thought of as an easy-to-use access portal to HPC facilities allowing the user to run/publish their own applications and edit files on the registered clusters/pcs via WWW (Figures 1 and 2) and Web Services with single sign-on for all clusters/pcs. It is the high-level middleware that executes commands on clusters/pcs on behalf of authorized users. BeesyCluster aims at making powerful ACC 1 clusters available via WWW and Web Services and allow inexperienced users to invoke published MPI/PVM applications with a mere click of the button (Figure 1). 1 http://www.task.gda.pl/english/kdm.html

Fig. 1: BeesyCluster s File Manager Fig. 2: Tasks (Queued) by the User and Tasks Rented from His/Her Account 3.2 Open, Distributed Network of Services On the other hand, BeesyCluster offers a truly open network of services offered by providers to clients (Figure 3) with the following features: Fig. 3: Client-Server Interaction in BeesyCluster COMPUTING MODEL : many providers, many clients, the client may also offer services as a provider; users can access and manage their accounts/files, run tasks through WWW or Web Services. SETTING UP AN ACCOUNT : a new user-provider sets up a BeesyCluster account by submitting logins/passwords of accounts available through SSH on the selected cluster/pc and is able to log in via BeesyCluster just after the administrator has granted access. It is only required that the account(s) are accessible via SSH. No other configuration is necessary which is possible thanks to the BeesyCluster security model explained in Paragraph 3.3. This gives BeesyCluster an advantage over the often complex process of deployment of new sites in grid systems ([11], [8]). The user can set up a BeesyCluster account without any cluster/pc accounts for use of free services published by others.

PUBLISHING SERVICES : The user can publish any of the applications (both run from the shell and to be submitted to the queue like LSF/PBS) or files from any of the registered accounts of any of the PCs/clusters registered to other users/groups (e.g. student groups) in BeesyCluster. The user-provider who grants access to a resource can allow right delegation to other users. Publishing a service does not give shell access and thus does not sacrifice security (Paragraph 3.3). RUNNING SERVICES : 1. The user has full access to any of the files/applications on their registered accounts on the registered PCs/clusters, can: access/edit files, run commands via an easy-to-use WWW interface (Figure 1) or Web Services (Figure 6). 2. For every published service, users see a link in the WWW interface. By clicking the user-client invokes the service which runs on the provider s account as may require a proper environment (libraries etc.). The Web Service interface is meant for more advanced users for integration of BeesyCluster services into their programs, the WWW interface for novice users. In the latter case, a sample scenario may involve clicking on a link corresponding to a climate modelling application, uploading files with input data (to a special directory for the client user on the provider account) and either running the task or specification of the queue, email notification, exact number of processors etc. for LSF or PBS. Afterwards, the user can check the status of the task and upon completion view results in File Manager and download or copy them to their own accounts. BeesyCluster was designed as a J2EE application with the following components (Figure 4): KC (Cluster Commander) WWW front-end, TS (Team Support) module, AS (Authorization), RA (Run Anywhere for SSH communication with PCs/ clusters), PS (Payment Service for accounting of rented services each user has a virtual wallet to which points are added after other users executed paid services or subtracted after the user has used others services), Web Service front-end which are proper EJBs deployed as Web Services in JBoss/AXIS. Fig. 4: BeesyCluster s Architecture

3.3 Security Concept In Globus ([7]) and Legion ([8]) the authorization of the user is actually done by the resource provider/resources. In H2O proxy-objects authorize the user based on the policies given by the kernel owner or the user who loaded the pluglet ([9]). The BeesyCluster server itself acts as a centralized proxy which both authenticates and authorizes the user to invoke a given service. It is assumed the provider trusts BeesyCluster invokes services on their account only for the users they granted access to or for the account owner. Thus the attachment of a new cluster/pc and a user-provider account requires just database entries with the IP of the cluster and the account login/password. The commands are issued on the clusters via SSH by module RA (Figure 4). Transmission from the client to BeesyCluster uses HTTP or HTTPS which requires proper configuration ([14]) and the keystore file for the Web Service client. The authentication and authorization are implemented within BeesyCluster and require actions presented in Figure 5 for both the Web Service and WWW front-ends. For the Web Service access, after having obtained ids of login (handle logins) and signer modules (handle various encryption algorithms), the client must login with a password and obtain an authenticator which contains the id of the user, expiration date and is digitally signed by the system. The authenticator can be used to launch a command on a cluster the user has access to. Based on the authenticator, the user can obtain a ticket valid to use the given resource. Both the authenticator and the ticket are valid for a definite period of time thus it is safer to use them rather than login/password pairs. Web Service interface WWW Interface client bc/as bc/kcws BeesyCluster WWW lid = get login agent id () sid=get signer id () auth=login(login,password,lid,sid) run (auth,cluster,command) ticket=get ticket to resource(auth,res) run resource(ticket) run a command through the login, file manager, available resources web pages run a rented resource Fig. 5: Sequence to Invoke an Application in BeesyCluster via Web Services and WWW 3.4 Interfaces and API BeesyCluster offers an easy-to-use WWW interface which allows the user to: manage files/directories through an interface similar to Midnight Commander (Figure 1) including (de)compression, editing files, one-click task launch (interactively or queued on a

cluster), browsing available resources, publishing own resources with a single mouse click, viewing task results from queued tasks (own and rented tasks) Figure 2, delegating rights to other users and managing personal data. BeesyCluster allows FTP from the BeesyCluster server to any location where FTP is available. All file operations on the accounts registered in BeesyCluster are executed through a Java SSH library. For a rented task, a unique directory is created by BeesyCluster before running to which the task can print output (this can be assured by the programmer-provider). The task can read the directory name from an environment variable set by BeesyCluster. In fact, application could also be copied to this directory before execution in effect releasing the programmer from using the variable, just writing output to the directory where the application was spawned. The user-client can view the task results, copy them but does not see other directories nor has access to the shell on the provider s account. import p l. gda. pg. e t i. b e e s y c l u s t e r 2. ; 2 import as. i n t e r f a c e s. a u t h. ; import as. i n t e r f a c e s. s i g n. ;... 4 ASService s e r v i c e = new A S S e r v i c e L o c a t o r ( ) ; AS p o r t = s e r v i c e. getas ( ) ; t r y { / / f i r s t g e t l o g i n a g e n t and s i g n e r module i d s 6 L o g i n A g e n t D e s c r i p t i o n [ ] l a d = p o r t. l i s t L o g i n A g e n t s ( ) ; S i g n e r D e s c r i p t i o n [ ] sd= p o r t. l i s t S i g n e r s ( ) ; 8 S t r i n g [ ] a u t h = p o r t. l o g I n ( new S t r i n g [ ] { <l o g i n>, <password> }, l a d [ 0 ]. getid ( ), sd [ 0 ]. getid ( ) ) ; / / t r y t o l o g i n now 10 / / now t r y t o c a l l a method from t h e KCWS i n t e r f a c e KCWSService s e r v i c e 1 =new KCWSServiceLocator ( ) ;KCWS p o r t 1 = s e r v i c e 1. getkcws ( ) ; 12 System. o u t. p r i n t l n ( p o r t 1. runcommand ( auth, 2, a r g s [ 0 ] ) ) ; / / run t h e g i v e n command } catch ( IOException e ) {... Fig. 6: Client Code to Invoke a Command on a Cluster via BeesyCluster/Web Services The code for running a given command on the cluster via Web Services is shown in Figure 6. Apart from the account owner, the client user would only run one of resources previously made available to them (include predefined paths to the execution file, maximum number of processors on which the user can run the task etc.). 4 Performance Tests For benchmarking Web Services, we used the following configurations: 1. Standard Web Services, No Security. The client calls a service deployed as a JWS (Java Web Service) file on the Tomcat 4.1.18/AXIS 1.1 server. 2. Standard Web Services, Basic Authentication, HTTPS. Configuration as above. 3. Web Services in BeesyCluster. The user logs in and runs the command (Figures 5 and 6). We measure times for the latter call which validates the authenticator and invokes the command on the cluster via SSH. Case 2 indicates the HTTPS overhead when added to this scenario. BeesyCluster uses JBoss 3.2.3/AXIS 1.1. For the server, we used a Pentium4, 2GHz, 1GB RAM machine, for the client a Pentium4 2.8GHz, 1GB RAM laptop, both running Fedora 1. We have measured:

Web Service latency : measured by running the String getstring(string) method with a 3-char String given as input and returned as output. Figure 7 shows the latencies measured on the client and server on a single node, through LAN and WAN (Internet via ADSL) for all three configurations above. For BeesyCluster, we measured just the getstring method of the KCWS (Figure 6) interface. time required to run a task on the server : for configurations 1 and 2 the command is run on the Tomcat/AXIS server. For BeesyCluster it is run on a cluster account registered for the given user (actually on an access node for 128-processor galera and 256-processor holk at ACC, Gdansk, Poland). We run command cat <filename> which prints the contents of files of varying sizes to the standard output. Figure 8 presents the task run times (until calls return on the client side) on BeesyCluster and Tomcat/AXIS through LAN and WAN for both servers. For BeesyCluster, the login phase costs as much as the times of returning the string of the authenticator size (around 512 bytes). #$ ") #$ $ #$ & ") & $ & $ #$'!!( #$'!!( ") #$'!!( Fig. 7: Latency for 3-char String Used as Input/Output Web Service Parameter &'( #$! #$! Fig. 8: Task Submission/Run Times via Web Service on Local Node, LAN, WAN (Internet) It is important to note that BeesyCluster can serve client requests from many servers, in fact implementing clustering thanks to a distributed database with replication, used by all BeesyCluster servers. The client authenticator or ticket are passed in the request for both WWW and Web Service interfaces. We have three servers running at beesycluster[1,2].eti.pg.gda.pl. Analysis of latency of SOAP implementations, including AXIS, can be found in [15]. Our times for AXIS are slightly shorter (understandable given the faster hardware). We also present the latency for SOAP over HTTPS which is around 5 times larger than for HTTP (for small message sizes). We conclude that for latency, the BeesyCluster Web Services (KCWS.getString on JBoss/AXIS) are slightly slower than pure Tomcat/AXIS, both of which are faster than HTTPS on Tomcat/AXIS.

For remote task submission, BeesyCluster s call is slightly slower than pure Tomcat/AXIS but implements security and runs a command and fetches standard output from the remote cluster. 5 Conclusions and Future Work We have explained the main ideas and the security concept of BeesyCluster which offers an access portal to an expandable network of distributed clusters/pcs with easy resource publishing and interface. We have shown that the performance of the Web Service interface is comparable to that of pure Web Services deployed on Tomcat/AXIS. We are currently deploying the system for the ACC users as an access point for the HPC resources in Gdansk, Poland. We plan on testing the clustering features of BeesyCluster, especially under the large number of incoming requests. References 1. Buyya, R., ed.: High Performance Cluster Computing, Programming and Applications. Prentice Hall (1999) 2. Streicher, M.: Creating Web Services with AXIS: Apache s Latest SOAP Implementation Bootstraps Web Services. Linux Magazine (2002) http://www.linuxmag.com/2002-08/axis 01.html. 3. Foster, I., Kesselman, C., Tuecke, S.: The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of High Performance Computing Applications 15 (2001) 200 222 http://www.globus.org/research/papers/anatomy.pdf. 4. CrossGrid: (http://www.crossgrid.org/) 5. R. Wyrzykowski, coordinator: (Clusterix) http://clusterix.pcz.pl. 6. EuroGrid: (http://www.eurogrid.org) 7. Globus System: (http://www.globus.org) 8. The Legion Group: Legion 1.8. System Administrator Manual. (University of Virginia, VA, USA) http://legion.virginia.edu/documentation/sysadmin 1.8.pdf. 9. Kurzyniec, D., Wrzosek, T., Drzewiecki, D., Sunderam, V.: Towards self-organizing distributed computing frameworks: The h2o approach. Parallel Processing Letters 13 (2003) 273 290 10. CrossGrid: (Migrating Desktop - User Guide, Portals and Roaming Access, WP3) wp3.crossgrid.org/cg3.1-d3.6-v2.1-psnc-mduserguide.doc. 11. Floros, V., Markou, C., Mastroyiannopoulos, N.: LCFGng Cluster Installation Guide Version 2.0 (LCG-2). (2004) http://cgi.di.uoa.gr/ xgrid/ cgfiles/lcfgng v2.0.pdf. 12. Czarnul, P.: Pvmwebcluster: Integration of pvm clusters using web services and corba. In: Proceedings of the 10th European PVM/MPI Users Group conference EuroPVM/MPI 2003. Volume LNCS 2840., Venice, Italy (2003) 268 275 13. Czarnul, P.: Architecture and implementation of distributed data storage using web services, corba and pvm. In: Proceedings of the 5th International Conference on Parallel Processing and Applied Mathematics. Volume LNCS 3019., Czestochowa, Poland (2003) 360 367 14. Gopalakrishnan, U., Ravi, R.K.: Web services security, Part I (2003) www-106. ibm.com/developerworks/webservices/library/ws-sec1.html. 15. Davis, D., Parashar, M.P.: Latency Performance of SOAP Implementations. In: 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGRID 02), Berlin, Germany (2002) 407 412