ADEM: Automating Deployment and Management ... - Semantic Scholar

4 downloads 254671 Views 368KB Size Report
ADEM: Automating Deployment and Management of Application Software on the Open Science Grid .... user under the VO user account on each grid site. The.
ADEM: Automating Deployment and Management of Application Software on the Open Science Grid *

Zhengxiong Hou, * Jing Tie,# Xingshe Zhou,* Ian Foster,+# Mike Wilde+

Center for High Performance Computing, Northwestern Polytechnic University, Xi’an, China Computation Institute, University of Chicago and Argonne National Laboratory, Chicago, IL, USA # Department of Computer Science, University of Chicago, Chicago, IL, USA [email protected], [email protected], [email protected], [email protected], [email protected] +

applications, especially in scientific and engineering computing, require one or more application software packages or even entire software suites. Whether open source or commercial application software is required, the steps for deploying grid applications include development, installation, testing, debugging, before execution can take place [3]. Of these phases, execution – which entails scheduling and coordinating concurrent execution across a variety of diverse resources – has attracted the most attention. Far less attention has been paid to the important prerequisite process of software deployment. The lack of middleware support for application deployment presents a challenge to scientists using computational grids today [4]. In the grid environment, operating systems and grid middleware are typically deployed and managed by system administrators. But in most cases, end users or application administrators must deploy and manage domain-specific application software on these grids by themselves. In this paper, we define grid application deployment as installing and testing the application software on the numerous and diverse platforms that constitute a grid. The intrinsic nature of the grid—heterogeneous, dynamic, autonomous, and crossing administrative domains—makes the deployment and management of application software in the grid environment nontrivial. The main problems are as follows: 1. There is a wide disparity in operating systems, system architectures and runtime environments (CPU type, instruction set, software libraries, command arguments, directory structuring, etc.) Application software must be configured for these variations across different platforms among grid sites. 2. The aggregate number of grid sites is usually large and dynamic: typically in the range of 20 – 100. Grid site properties and availability status are also highly dynamic. 3. Application software must be deployed and managed remotely, often without the benefit of interactive login capabilities.

Abstract In grid environments, the deployment and management of application software presents a major practical challenge for end users. Performing these tasks manually is error-prone and not scalable to large grids. In this work, we propose an automation tool, ADEM, for grid application software deployment and management, and demonstrate and evaluate the tool on the Open Science Grid. ADEM uses Globus for basic grid services, and integrates the grid software installer Pacman. It supports both centralized “prebuild” and on-site “dynamic-build” approaches to software compilation, using the NMI Build and Test system to perform central prebuilds for specific target platforms. ADEM’s parallel workflow automatically determines available grid sites and their platform “signatures”, checks for and integrates dependencies, and performs software build, installation, and testing. ADEM’s tracking log of build and installation activities is helpful for troubleshooting potential exceptions. Experimental results on the Open Science Grid show that ADEM is easy to use and more productive for users than manual operation.

1. Introduction Production grids have emerged as a new-generation of computational infrastructure, supporting resource sharing and cooperative work for federated, distributed, high-throughput computing. Grids aggregate many diverse computing resources, and a broad range of application software (including traditional intramachine or intracluster applications) can be deployed, managed, and executed in grid environments. An application is said to be grid-enabled when it is able to run on the multiple heterogeneous resources that constitute a grid [1]. Grid-enabled applications usually have a coarse level of granularity and require minimal internode communication [2]. Grid

978-1-4244-5149-4/09/$26.00 © 2009 IEEE

130

10th IEEE/ACM International Conference on Grid Computing

clusters, such as Rocks [8, 6], Cfengine [6], OSCAR [6], and LCFGng [6]. Quattor [6] is a system administration toolkit for the installation, configuration, and management of operating systems and application software for computing fabrics. Its configuration management modules describe the desired configuration of all the nodes, and the installation management modules change the actual configuration of nodes to the desired state. Quattor mainly supports Unix derivatives, such as Linux and Solaris. Tank & Spark [7] is a client-server solution for deployment of application software for experiments of the Large Hadron Collider. It allows for centrally triggering and controlling software installations at many remote sites in a virtual organization. The gLite Packman [9] system is an alternative to Tank & Spark, but it does not tackle the problem of automatic installation on a farm of grid sites. For the ATLAS experiment, George et al. [10] interfaced CMT [11] and Pacman [12] with ATLAS software. Pacman provides a convenient mechanism to specify the transport and execution of an installation package for a variety of installers, but operates on only a single target system at a time. Additional tools were developed to extract files in common package formats and write the Pacman files. Pacman provides a convenient core “meta-installer” around which systems like ADEM can be built. Distributed ant [4] supports application deployment in the grid. It extends the ant build file description to provide a flexible procedural deployment description and implements a set of deployment services. Adage [13] is designed for automatic application deployment on grids. The main steps involve general application description, deployment planning and execution, and application configuration. Currently, MPI, JXTA, and CORBA Component Model applications are supported. Kecskemeti and Kacsuk [14] extended the Globus workspace service, creating virtual machine appliances for grid services and service deployment from a repository, and influencing the service schedules by altering execution planning services, candidate set generators, and information systems. Research in industry has led to the rBuilder product [15], which enables application vendors to combine their application with just enough operating system capabilities to create a software virtual appliance. Electric Cloud, Inc. [16] provides a distributed build system that refactors an application’s makefiles into parallel workloads executed on dedicated clusters.

4. Application software must typically be deployed and managed by end users or application administrators with limited resource authority (e.g., not a “superuser” with root permission) in different autonomous administrative domains. 5. Grid site access requires virtual organization (VO) membership and authorization. Manual deployment and management of an application software package usually require expertise about both the underlying system platforms and the application. Currently, however, deployment and management is performed manually, which is errorprone and does not scale to large grids. For example, to deploy an application across twenty grid sites, a user typically must login or submit remote commands and data management operations to each of the twenty sites, sequentially compiling, linking, installing, and testing the software (or perform such operations via a script). [3] A deployment may additionally encounter licensing and maintenance issues at each site. This lengthy list of obstacles suggests that research is needed in order to enable automatic deployment and management of application software for the grid. To meet this need, we have developed the ADEM Application Deployment Manager, an automation tool for application software deployment and management on the Open Science Grid (OSG) [5]. Currently, ADEM can perform both prebuild and dynamic-build approaches. Its workflow automatically determines the available grid sites, their resource configuration information, and their platform signatures, manages information gathering and application deployment on a set of grid sites in parallel, checks for and installs dependencies, and tests results. ADEM’s log recording – a form of provenance tracking – is helpful for troubleshooting any exceptions to successful deployment. The rest of this paper, in which we report on the design of ADEM and our experience with its usage, is organized as follows. In Section 2, we introduce related work in this area. Section 3 presents the design and architecture of ADEM for OSG. Section 4 discusses the implementation of the automatic workflow of ADEM. Section 5 presents some experimental results in using ADEM to deploy application packages on OSG. We conclude in section 6 and provide a brief list of future work.

2. Related Work One class of related tools are those specifically designed for the installation and management of Linux

131

about site name, gateway, application work directory, the path of Pacman, site signature, data directory, local resource manager, and the path of MPI will be automatically fetched and added to the grid sites cache. If no Pacman or MPI is available on a new grid site, it will be automatically installed during the updating process. Usually there is enough disk space for such of application software, so ADEM does not at the moment manage space concerns. Security is of particular concern in automated application management. On the OSG, ADEM uses Globus pre-WS GRAM grid services; it requires no additional daemon or firewall settings beyond those required for GRAM. Each grid site has a designated account for each VO to which it provides service. When executing deployment or management scripts by Globus GRAM on the OSG grid sites, an end user is mapped to the user ID for the particular VO that the ADEM end-user’s certificate belongs to. As shown in Figure 1, if multiple end users belong to the same VO, ADEM creates an individual work directory for each user under the VO user account on each grid site. The work directories for application deployment and execution are also separated.

Unlike the related work described above, our research is focused on fully automating the process of deployment and management of real, domain-specific application software on the Open Science Grid and other Globus-equipped grids such as TeraGrid. It automates the dynamic collection of grid site resource and service contact information needed for application deployment, and can be adapted to different build approaches, such as prebuild and dynamic build. With the prebuild function, users do not need to compile their source code on every grid site. ADEM requires no additional daemon program, and operates solely using the services of Globus and Pacman. ADEM supports the execution of applications by the Swift parallel scripting system [17] by automating the generation of the Swift application and grid site catalogs.

3. Design of ADEM ADEM’s automatic deployment and management of application software on the OSG is based on Globus [18] and Pacman [12]. These packages enable remote task execution and application package fetching and installation in distributed grid environments. Heterogeneity is a main concern in the grid environment. In ADEM, the concept of a “grid site signature” is used to identify the configuration features of heterogeneous platforms. Such features include the site’s CPU architecture, operating system and the version of its kernel, C library and compiler (glibc and gcc), and MPI installation. “Linux-2.6.9-i686glibc2.3.4-gcc3.4.6-mpich1.2.7” is an example of an ADEM site signature. Choosing the right prebuilt application binary packages for the various grid sites is critical. However, in some cases, application software prebuilt on a given machine cannot be migrated to other machines, even though they have the same signature. To address such cases, ADEM also supports an on-site dynamic-build approach. For the dynamic build, it is important to choose the right version of source codes for the various grid sites. With Pacman, pre-requisite application package dependencies needed for both build approaches can be checked and deployed automatically if they are unavailable. Dynamic status changes in site service availability is a fundamental concern in the grid environment. Dynamic information about grid site services is fetched by using VORS (Virtual Organization Resource Selector) [19] or ReSS (Resource Selection Service) [20]. ADEM maintains a cache of information about the grid sites, and checks and updates the detailed information in this cache as needed. If an old grid site cannot be used, it is removed from the grid site cache. When a new grid site is found, the new information

Figure 1. Mapping from end users to the designated user for a virtual organization.

The architecture of ADEM is presented in Figure 2, and includes the following components. 1. The NMI Build and Test System [21]. This system is used to pre-build applications, including the compiling, linking, testing, and packaging of application software for a broad range of heterogeneous platforms. For a new application, the Build and Test system requires a software source code tar file and a description of how to obtain, compile, link, install, and test the application on the NMI B&T system. ADEM end users or application administrators log in to the submitting machines of NMI B&T system to submit the software build and test jobs. To improve efficiency, the users can tailor their application software to the specific heterogeneous platforms representing the available OSG grid sites to be used.

132

automatically installed by ADEM. Automated scripts for the requested deployment or management operations are generated and transferred by ADEM from the invoke site to the grid sites at installation time. In addition to specific user home directories for each VO, ADEM creates an individual work directory at each target grid site for each end user, and for each application.

4. Implementation of ADEM’s Automatic Workflow ADEM is based on Globus, and integrates Pacman for automatic deployment and management of application software on the OSG. ADEM provides a few commands for automatic deployment and management functions; these are implemented as scripts written in Bash and Perl. ADEM implements a site signature-based application software packaging approach supporting both pre-built binary applications and on-site source code builds. Application administrators or end users can prepare the application software packaging and manage the default application software repository and Pacman cache, including adding, removing, modifying, or updating application software packages and Pacman files. Application administrators can also create their own repositories with Pacman caches for application software. If a repository is not set up while installing the ADEM tool, a default ADEM application repository will be used.

Figure 2. Logic architecture of ADEM for OSG.

2. ADEM Repository for application software and any additional packages the application software depends on. The application software package can be a source code tar file or prebuilt binary package from the NMI B&T system. Hence, there is a matched package for each grid site signature in this repository. A Pacman cache is also be placed in it, which contains Pacman files describing how to download and install the application software for different grid site signatures. The Pacman install file decides whether to use the prebuild or the dynamic-build approach. With the prebuilt binary package, the installation of application software just needs to be unpacked to the defined work directory in the grid sites. 3. ADEM invocation site to trigger application software automatic deployment or management to the available grid sites in parallel. Globus client tools must be installed on the ADEM invocation site, which can be any machine on which a user has grid credentials authorized for the target VO to which applications will be deployed. The ADEM script tools are downloaded and executed on the invocation site. From there the automatic ADEM workflow for application software deployment or management can be performed on a set of available grid sites in a given VO. 4. VORS [19] or ReSS [20] are required to provide dynamic, up-to-date information about grid services and directory names on the target sites of a VO. 5. Grid sites. Globus Toolkit 4 should be installed on each site. GSI – Grid Security Infrastructure – is used for grid use authentication and authorization. GridFTP is used to transfer the automated scripts required for deployment and management. GRAM is used for the execution of the scripts on the distributed, remote grid sites. If Pacman is not available, it will be

Figure 3. The dock-linux_2.6.9-x86_64.Pacman file.

Instructions on how to fetch and install software are described in script within a Pacman file; docklinux_2.6.9-x86_64.Pacman is an example for a DOCK application with a binary code package (Figure 3). The operating system and CPU features from the grid site’s signature are used to name the Pacman file. When necessary, glibc or gcc can be dealt with as dependencies. On the ADEM invocation site, after the application software packaging, any VO-authorized user can trigger an automatic workflow to deploy or manage a given application software package on the available

133

grid sites of the VO in parallel and get the results automatically. The specific ADEM commands for this include “auto-deploy-app,” “auto-update-app,” and “auto-rm-app.” Users can specify the VO, sites-list file, and application software name. The sites-list file can also be automatically generated from VORS or ReSS information. ADEM will automatically check the repository to show the packaged application software. The general automatic workflow for the application software deployment and management on OSG is described in Figure 4. The three key steps of this process are as follows. Step 1: Get the available grid sites automatically and dynamically. Based on the dynamic grid sites information from VORS [19] or ReSS [20], ADEM discovers the available grid sites for a VO and automatically generates a grid sites file to describe them. A cache file for the grid sites information is maintained to improve performance and is updated after every use. If this is the first time the available grid sites information is fetched for an end user, an individual work directory for application deployment and execution will be created. In order to support the execution of grid workflow by Swift [17], a Swiftformat sites file (sites.xml) will be automatically generated for the specific users. Step 2: Deploy the application software on the selected grid sites in parallel. With a loop for launching deployment, ADEM automatically generates the deployment script for each grid site and transfers the scripts to the grid sites using GridFTP. These scripts are then executed in parallel in the background. Pacman is invoked in the automatic deployment script to transport the application package to the grid site and install it. Using the grid site’s signatures, ADEM can choose the right application software packages for different grid platforms from the repository. For the prebuild approach, Pacman simply unpacks the binary codes package for the installation. The described dependencies in the Pacman file are automatically checked in the grid sites. If required packages are not present, they will be installed automatically. Limited error handling can also be added into the Pacman file; thus, ADEM can automatically correct known installation pitfalls. The standard output and standard error information for each deployment operation on each grid site is recorded and returned to the ADEM invocation site for auditing and troubleshooting. Step 3: Automatic deployment result checking. The deployment results on all of the available grid sites will be automatically fetched. If there are errors on some grid sites, the specific sites can be automatically cleaned and redeployed from scratch. In order to support the execution of grid workflow by Swift [17], an application deployment catalog (the Swift-format

tc.data file) is automatically created, which records the successfully deployed application software and the paths of its executables. The automatic workflow for application software management is similar to that for deployment. From the ADEM invocation site, an authorized VO user can use the ADEM tools “auto-rm-app” and “auto-updateapp” to trigger automatic removal or update of a given application software on a set of grid sites. These tools are executed in parallel in the background. The results of management requests can also be checked and fetched automatically. After the completion of automatic deployment or management of the application software, all of the executed commands and deployment or management results are automatically recorded in log files which capture all of the standard output and error information. These logs can be used for provenance tracking and for troubleshooting potential exceptions in the grid environment.

Figure 4. Automatic workflow of ADEM.

5. Experiments The Open Science Grid [5] is a distributed computing grid for multidisciplinary research in the United States and several other nations, consisting at the time of our tests of over 70 grid sites shared by 30 virtual organizations (VOs). We tested ADEM in the large general-purposed “OSG” VO as well as the much smaller “OSGEDU” education VO.

134

5.2 Time Cost

In our tests, more than 10 applications were automatically deployed and managed on 20 Linux grid sites, whose predominant CPU architectures are i686 and x86-64. We show results here for 8 of these applications. The application domains included molecular dynamics, biology, and computer science. DOCK [22], NAB [23], and BLAST [24] were the primary software applications that we worked with, although we tested installation of several others as well. At the ADEM client invocation site, automatic deployment and management of the application software on a set of grid sites was initiated by a user with a valid X509 proxy registered in the OSG VO. In our tests, the ADEM client machine was a dual-core Intel Pentium® 2.80 GHz CPU with 3 GB of RAM.

To perform automatic deployment of application software on a set of grid sites, ADEM first generates a deployment script for each grid site. Then the automatic deployment scripts are transported to the remote grid sites and executed in parallel. Figure 6 shows an average launching time of 2 seconds for automatic deployment on 20 grid sites. The different applications showed little difference. In the execution loop for a set of grid sites, the launching time for automatic deployment of application software increases with the number of grid sites, but is relatively fast: for a simulation of 100 grid sites, the time was approximately 8 seconds. This cost is almost negligible for the scale of current production grids.

5.1 Installation Success Rate and Scalability Manual deployment of diverse application software is error-prone and not scalable to large grids. In fact, if the application software has to be built on each grid site, installation errors commonly occur on various sites for most of the application software. Most of these failures are due to missing dependencies or compilation errors caused by environmental differences between OS platforms. With the site signature-based prebuild approach, we do not need to compile the source code on the grid sites. The installation success rate was greatly improved because we were able to get the right version of the application’s binary code package for the specific platform, which was prebuilt on a reliably configured and well-tested machine within the NMI Build and Test system [21] with the same signature as the target machine. For the 20 grid sites we tested ADEM on within the OSG VO, Figure 5 compares the success rate of automatic prebuilt application software deployment using ADEM to manual deployment. Failures in ADEM install operations were often manifested as Pacman installation script errors. We note that because the BLAST application was downloaded in binary package form, it did not need a prebuild. Hence, the success rates for BLAST were 100% with both manual and ADEM deployment.

Figure 6. Average launching time for automatic deployment of applications for 20 grid sites.

Figure 7. Average completion time for automatic deployment of applications with the prebuild-based approach.

The deployment completion time to a set of grid sites includes the launching time and the time for the execution of installation and tests. The average completion time of the prebuild approach is shown in Figure 7. For this approach, usually ADEM needs only to unpack the binary package for installation; sometimes, dependencies also must be installed. For different application software, the average deployment completion time depends mainly on the unpacking time and network performance. We noted an obvious variation among the grid sites. Although we could deploy an application on all of the

Figure 5. Comparison of success rate between ADEM and manual deployment for 20 grid sites.

135

available grid sites in parallel, the overall deployment completion time was limited by the slowest grid site. Thus the average deployment completion time tends to increase with the number of grid sites. However, compared to the manual deployment or dynamic build on each grid site, the prebuild-based approach for automatic deployment provides much better performance. For example, for a user to log in to each grid site to deploy DOCK can take, based on casual measurements, over 290 minutes for the 16 grid sites (with no errors involved). With the dynamic build on each grid site, the average time for successful deployment of the DOCK application to 16 grid sites, was about 45 minutes. With the prebuild approach, the average prebuild time was 15 minutes, and the average successful deployment to 16 grid sites was 3.5 minutes, so the overall deployment time was reduced to approximately 18.5 minutes. For the automatic management functions of application software, such as removal and updating, the launching process is similar to that of deployment. The completion time for removal is fast compared with the deployment completion time (as would be expected). And the completion time for update is approximately the sum of removal and deployment. For example, the times for various applications on 16 grid sites are shown in Figure 8. The prebuild of the Octave application, which generated a binary package of more than 200 MB, took a comparatively long time. On the other hand, BLAST did not need a prebuild, because it was downloaded from its provider as a binary package.

Grid. It provides both a fast, convenient prebuild approach, which yields a high installation success rate, as well as a dynamic on-site build approach, which is necessary in circumstances where prebuild is not feasible. The prebuild function utilizes the NMI Build and Test system and the technique of matching an environment signature of the build system to that of the target system for deployment. ADEM is based on basic Globus grid middleware, which provides remote execution capabilities, and Pacman, which provides for installation package transport and deployment. ADEM determines grid site configuration information automatically and dynamically, triggers automatic deployment or management of a given application package on a set of available grid sites in parallel, and automatically fetches the results of deployment and validation tests. Our experiments on the OSG show that ADEM significantly reduces manual efforts for the deployment and management of application software. It is easy to use, much faster than manual operation, and is readily scalable to large grids. Future enhancements to ADEM include scaling to very large numbers of grid sites, VO-based application management, and a web interface for end users. To ensure ADEM scalability, repository mirrors and caches can be used to spread the application distribution load for huge numbers of grid sites; throttling of the degree of parallelism can also be employed at the expense of overall installation time.

Acknowledgments

Afni Octave

This research is supported in part by NSF grant OCI721939 and by the U.S. Dept. of Energy under Contract DE-AC02-06CH11357. It was made possible by the resources of the Open Science Grid and the Build and Test System of the National Middleware Initiative. We thank Glen Hocky for end-user testing and feedback.

MpiBlast ave. Pre-build time

Blast

ave. deployment time

Angle

ave. remove time

R Nab Dock 0

10

20

30

40

50

60

70

80

Time(min.)

Figure 8. Prebuild-based time statistics on 16 grid sites.

After deployment, several of the application software packages were used for real grid applications. We have executed large-scale parameter-sweep studies with ADEM-deployed DOCK and BLAST applications.

References [1] P. V. Coveney, R. S. Saksena, S. J. Zasada, M. McKeon, and S. Pickles. The Application Hosting Environment: Lightweight Middleware for Grid-based Computational Science. Computer Physics Communications 176 (2007) 406-418.

6. Conclusion

[2] A. Krishanan. A Survey of Life Sciences Application on the Grid. New Generation Computing 22 (2004) 111-126. 2004.

We have developed and evaluated ADEM, a tool that automates the task of application software deployment and management on the Open Science

136

[3] D. Abramson. Applications Development for the Computational Grid. In Proceedings of Frontiers of WWW Research and Development (APWeb 2006), LNCS 3841, pp. 1-12, 2006.

http://vors.grid.iu.edu/cgi-bin/index.cgi, 2009. [20] Resource Selection Service (ReSS). http://twiki.grid.iu.edu/bin/view/ResourceSelection/WebHom e, 2009.

[4] W. Goscinski and D. Abramson. Distributed Ant: A System to Support Application Deployment in the Grid. In Proceedings of the Fifth IEEE/ACM International Workshop on Grid Computing (GRID’04), 2004.

[21] A. Pavlo, P. Couvares, R. Gietzel, A. Karp, I. D. Alderman, M. Livny, and C. Bacon. The NMI Build & Test Laboratory: Continuous Integration Framework for Distributed Computing Software. In 20th Large Installation System Administration Conference (LISA ’06). 2006.

[5] OSG (Open Science Grid). http://www.opensciencegrid.org/, 2009.

[22] D.T. Moustakas et al. Development and Validation of a Modular, Extensible Docking Program: DOCK 5, J. Comput. Aided Mol. Des. 20, 2006, pp. 601-619

[6] R. García Leiva, M. Barroso López, G. Cancio Melia, B. Chardi Marco, L. Cons and P. Poznanski. Quattor: Tools and Techniques for the Configuration, Installation and Management of Large-Scale Grid Computing Fabrics. Journal of Grid Computing 2 (2004) 313–322.

[23] T. Macke and D.A. Case. Modeling unusual nucleic acid structures. In Molecular Modeling of Nucleic Acids, N.B. Leontes and J. SantaLucia, Jr., eds. (Washington, DC: American Chemical Society, 1998), pp. 379-393.

[7] R. Santinelli, F. Donno. Installing and Configuring Application Software on the LHC Computing Grid. In Proceedings of the First International Conference on eScience and Grid Computing (e-Science’05), 2005.

[24] S. Altschul, W. Gish, W. Miller, E. Myers, D. Lipman (1990). "Basic local alignment search tool". J Mol Biol 215 (3): 403–410.

[8] P. Papadopoulos, M. Katz, G. Bruno, NPACI Rocks: Tools and Techniques for Easily Deploying Manageable Linux Clusters. Concurrency and Computation: Practice and Experience Special Issue: Cluster 2001. [9] Alien/gLite Packman. http://glite.web.cern.ch/glite, 2009. [10] S. George, C. Arnault, M. Gardner, R. Jones, S. Youssef, and L. Orsay. Automated Software Packaging and Installation for the ATLAS Experiment, 2003. [11] CMT. http://www.cmtsite.org/, 2009. [12] Pacman. http://physics.bu.edu/~youssef/Pacman/, 2009. [13] Adage. http://www.irisa.fr/paris/ADAGE/, 2009. [14] G. Kecskemeti and P. Kacsuk. Automatic Service Deployment Using Virtualization. In 16th Euromicro Conference on Parallel, Distributed and Network-Based Processing. 2008. [15] rBuilder. http://www.rpath.com/corp/products, 2009. [16] Electric cloud. http://www.electric-cloud.com, 2009. [17] Y. Zhao, M. Hategan, B. Clifford, I. Foster, G. von Laszewski, V. Nefedova, I. Raicu, T. Stef-Praun, and M. Wilde. Swift: Fast, Reliable, Loosely Coupled Parallel Computation. In IEEE International Workshop on Scientific Workflows, 2007. [18] I. Foster. Globus Toolkit Version 4: Software for Service-Oriented Systems. Journal of Computer Science and Technology 21 (2006) 513-520. [19] VORS (Virtual Organization Resource Selector).

137