Fig. 10.6  Performance over Grid5000, Amazon EC2, and resource mix

­execution over Grid5000; even with the balance of load by the partitioner, processes running on EC2 presented lower performance. Using both Grid5000 resources and Extra Large EC2 instances has proved to be more advantageous, presenting, on average, only 15% of overhead for such inter-domain execution when compared with the average of the best single domain ones. This is mainly due to high-latency communication and message tunneling, but this overhead could be further softened because of the possibility of adding extra resources to/from the grid/Cloud.

From a cost-performance point of view, previous performance evaluations of Amazon EC2 [10] showed that MFlops obtained per dollar spent decreases exponentially with increasing computing cores, and the cost for solving a linear system increases exponentially with the problem size. Our results indicate the same when using Cloud resources exclusively. Mixing resources, however, seems to be more feasible since a trade-off between performance and cost can be reached by the inclusion of in-house resources in computation.

10.5  Dynamic Mixing of Clusters, Grids, and Clouds

As we have seen, mixing Cloud and private resources can provide performance close to that of a larger private cluster. However, doing so in a static way can lead to a waste of resources if an application does not need the computing power during its complete lifetime. We will now present a tool that enables the dynamic use of Cloud resources.

10.5.1  The ProActive Resource Manager

The ProActive Resource Manager is a software for resource aggregation across the network, developed as a ProActive application. It delivers compute units represented

10.5.2  Cloud Bursting: Managing Spike Demand

Companies or research institutes can have a private cluster or use Grids to perform their daily computations. However, the provisioning of these resources is often done based on average usage for cost management reasons. When a sudden increase in computation arises, it is possible to offload some of them to a Cloud. This is often referred to as Cloud bursting.

Figure 10.7 illustrates a Cloud bursting scenario. In our example, we have an existing local network that is composed of a ProActive Scheduler with a Resource Manager. This resource manager handles computing resources such as desktop machines or clusters. In our figure, these are referred to as local computing nodes.

A common kind of application for a scheduler is a bag of independent tasks (no communication between the tasks). The scheduler will retrieve a set of free computing nodes through the resource manager to run pending tasks. This local network is protected from Internet with a firewall that filters connections.

When the scheduler experiences an uncommon load, the resource manager can acquire new computing nodes from Amazon EC2. This decision is based on a scheduling loading policy, which takes into account the current load of the scheduler and the Service Level Agreement provided. These parameters are directly set in the resource manager administrator interface. However, when offloading tasks to the Cloud, we have to pay attention to the boot delay that implies a waiting time of few minutes between a node request and its availability for the scheduler.

The Resource Manager is capable of bypassing firewalls and private networks by any of the approaches presented in Section 3.3.3.

10.5.3  Cloud Seeding: Dealing with Heterogeneous Hardware and Private Data

In some cases, a distributed application, composed of dependent tasks, can perform a vast majority of its tasks on a Cloud, while running some of them on a local

Fig. 10.7  Example of a Cloud bursting scenario