users to lease remote resources by deploying virtual machines on those resources. Using the Nimbus Cloud, the requested resources can be dynamically adjusted as a function of the application needs.

10.2.2  Cloud Computing Middleware

In order to run applications on a Cloud, one needs a flexible middleware that eases the development and the deployment process. GridGain [8] provides a middleware that aims to develop and run applications on both public and private Clouds without any changes in the application code. It is also possible to write dedicated applications based on the map/reduce programming model. Although GridGain provides mechanism to seamlessly deploy applications on a grid or a Cloud, it does not support the deployment of the infrastructure itself. It does, however, provide protocols to discover running GridGain nodes and organize them into topologies (Local Grid, Global Grid, etc.) to run applications on only a subset of all nodes.

Elastic Grid [7] infrastructure provides dynamic allocation, deployment, and management of Java applications through the Cloud. It also offers a Cloud virtuali­ zation layer that abstracts specific Cloud computing provider technology to isolate applications from specific implementations.

10.3  Deploying Applications in the Cloud

In the rest of our study, we will focus on the Amazon EC2 Web Service. Initially, we seek to determine the performance that can be expected. Then, we propose solutions to facilitate the deployment of applications in this context and to enable the usage of hybrid grid/Cloud environments. To reach this goal, we will use the ProActive Parallel Suite [3]. This framework is composed of three parts: (1) ProActive Programming offers a Java API for parallel and distributed computing, (2) ProActive Resource Manager gathers heterogeneous computing resources (parallel machines, clouds, grids, etc.) into an unified access mechanism (further details are given in Sections 3 and 5.1). ProActive Scheduler runs any kind of tasks (native, Java, Matlab, etc.) on a set of nodes acquired by the resource manager.

10.3.1  Benchmarking the Cloud

In order to assess the worthiness of using Amazon EC2 cloud as an HPC platform, we have deployed a series of benchmarks well known in the world of HPC, the MPI NAS Parallel Benchmarks. We have launched them on four different architectures, described in Table 10.1: a private cluster and three types of Amazon EC2 instances. To provide consistent and predictable CPU capacity, Amazon describes the CPU

Fig. 10.1  I/O performance comparison between a private cluster and EC2 instances

capacity of its instances in terms of an EC2 Compute Unit, and claims that it is the equivalent CPU capacity of a 1.0–1.2 GHz 2007 Opteron.

The chart presented in Fig. 10.1 shows that the Small and the Medium instances share the same throughput and latency, describing Moderate EC2 I/O performance, while the XLarge instance reflects High EC2 I/O performance. When compared with the Gigabit Ethernet connectivity provided by our own private cluster, there is a large gap, especially for latency.

Figure 10.2 shows the performance (Mflops) of three of the NAS Parallel Benchmarks on each architecture by varying the number of processes. Results average ten runs, and variation does not exceed 6%. Up to 32 processes, we run one process per machine; and then we increase the number of processes per machine.

•EP is an embarrassingly parallel problem that involves almost no communication between the processes. It is a strong test for pure computational speed. This test clearly shows the speed difference between all the instances. The XL instance is

Fig. 10.2  NAS parallel benchmarks

roughly equivalent to our private architecture (eight cores at 2.3 GHz), whereas the medium instance runs at the same rate, but with only two cores. Similarly, we see that the small instance is about 2.5–3 times slower than the others.

•CG computes a conjugate gradient involving a large number of small messages, and is a strong test for communication performance. It confirms the results shown in Fig. 10.1. Amazon EC2 performance is well below what we get with our private cluster.

•FT is a Fourier transformation benchmark. It is a test for both computation and communication speed involving large data transfers. With such a problem, the gap between our private architecture with medium and XL instances narrows.

As shown by the previous experiments, EC2 does not offer good performance for communication-intensive applications when compared with a local cluster. However, CPU-intensive application do not present a significant performance hit. When dealing with a complex application mixing communications and computations, it might be interesting to have a part on a Cloud and another on a cluster, depending on the application characteristics and the possibility to decompose the application in such a way. This, however, makes deploying such application more complex.

We now present different mechanisms that simplify the execution of applications over heterogeneous environments.

10.3.2  The ProActive GCM Deployment

The ProActive middleware provides an abstract descriptor-based deployment model and framework [4], giving users the capability to deploy an application on different platforms without changing the source code. The idea behind the ProActive GCM Deployment is to perform the discovery of resources, creation of remote processes, and data-handling externally to the application, completely

Deployment Descriptor (GCMD)

Fig. 10.3  GCM descriptor based deployment model

­separating the business code and deployment. In addition to these activities, the definition of the deployment can also encompass security, tunneling of communications, fault tolerance, and support of portable file transfer operations.

The whole deployment process (Fig. 10.3) and environment configuration is defined by means of XML descriptors that depict the application requirements and deployment process. The deployment of ProActive/GCM applications depends on two types of descriptors:

•GCM Application Descriptors (GCMA): the GCMA descriptors define application-related properties, such as localization of libraries, file transfer, application parameters, and nonfunctional services (logging, security, checkpoint, and fault tolerance). GCMA descriptors expose the resulting physical environment as a logical network of virtual nodes (VNs) that are used by applications as an abstract representation of computing nodes. The GCMA also defines with or multiple resource providers.

•GCM Deployment Descriptors (GCMD): the GCMD descriptors define access protocols to reach the resources (e.g. SSH, RSH, GSISSH, etc.), acquisition protocols and tools which are required to access the resources (e.g. Amazon EC2, PBS, LSF, Sun Grid Engine, OAR, etc.), creation protocols that have a relation with how to launch processes (e.g. SSH, OAR, gLite, Globus), and communication protocols (e.g. RMI, RMISSH, HTTP, SOAP, etc.).

The advantages of this model are clear: on one side, if the users want to add a new resource provider (e.g. a private cluster, production grid, or Cloud), the application code does not change and a single line is enough to add the resource provider to the application descriptor (GCMA). On the other side, the definition of the deployment process happens just once for each resource and can be reused for different applications.