10 An Efficient Framework for Running Applications on Clusters, Grids, and Clouds |
171 |
10.4 Moving HPC Applications from Grids to Clouds
It is not yet clear how much impact Clouds will have on HPC in the future. In fact, it is very unlikely that highly optimized clusters will be replaced by Cloud resources in a near future. Considering that most enterprises and public institutes that require them already have in-house HPC resources, which could provide processing power at lower costs, the notion of private Clouds or a mix between Clouds and cluster/grids resources seems more cost-effective to solve the problem of providing resources.
Scientific applications require sophisticated middleware because they usually present complex multi-point interactions and strong processing and network requirements, which necessitate performance. Porting such applications to heterogeneous environments increases the importance of middleware support.
In this section, we present a versatile GCM/ProActive-based lightweight framework that supports distributed and parallel scientific applications, so that porting of legacy applications is possible and easy for any kind of distributed computing environment or even a mixture of them. To illustrate this, we also present performance results obtained with a scientific PDE-based application in different contexts, including an experimental Grid, a public Cloud, and the mixture of these infrastructures.
10.4.1 HPC on Heterogeneous Multi-Domain Platforms
From the development point of view, the usage of resources spread across multidomain platforms as if it were a single infrastructure requires an integrated middleware. Such middleware should provide users with clear abstractions to develop applications that could be easily adapted to be deployed with different resource providers, despite different underlying characteristics of resources.
In the next section, we present in more detail a component-based integrating middleware, which emphasizes a clear separation between application development and the execution platform. This middleware eases the transition from clusters to grids and Clouds by providing seamless deployment and multi-protocol point-to- point and multi-point communication in multi-domain environments.
10.4.2 The Hierarchical SPMD Concept and Multi-level Partitioning of Numerical Meshes
The traditional way of designing domain decomposition-based simulations is to adopt an SPMD technique combining mesh-partitioning and the message-passing programming model. The hierarchical SPMD is an evolution of the traditional flat SPMD parallel programming paradigm toward a heterogeneous hierarchical approach. The hierarchical SPMD concept consists in assigning hierarchical identifiers to processes and treating collective communications in a topology-aware manner.
172 |
B. Amedro et al. |
Heterogeneity in network and resources is a challenging issue for domain decomposition based scientific applications. The main reason comes from the fact that these applications rely upon a bulk synchronous iterative approach and applications loop at the pace of the slowest process. The hierarchical network topology and computing power heterogeneity must therefore be considered in the mesh-partitioning and communication process.
We propose a multi-level partitioning approach to balance load among processors and optimize the communication process. The multi-level partitioner is capable of taking into account the characteristics of the resources (CPU power and amount of memory) and their topology to partition a global mesh in a way such that each process presents an equivalent processing time, yet minimizing communication through slower links [9]. The different levels defining the physical hierarchy are mapped into the communication process, which is configured depending on the effective location of communicating processes and the available communication protocols. The runtime also takes topology into account to stage the communication operations so that communication over slower networks (e.g. Internet) is avoided.
10.4.3 The GCM/ProActive-Based Lightweight Framework
The GCM/ProActive-based lightweight framework takes the form of a componentbased infrastructure that offers support to multi-protocol communication. This infrastructure is composed according to the hierarchy of resources and gives the applications a view of a unique global computing infrastructure, despite the localization and access restrictions of resources.
Figure 10.5 shows an example of such composition, which reflects a single global application deployed upon a resources set onto two separate but interconnected administrative domains. On the left, we run a standalone MPI application on a Cloud (e.g. a set of Amazon EC2 instances) and on the right, another standalone MPI application
runs over a multi-cluster based grid (e.g. the Grid5000). Each of the MPI processes is wrapped by a GCM primitive component that is connected to the external
Proxy Component Router Component
p0:1 |
p1:0 |
p1:2 |
p0:0 |
|
p1:1 |
|
|
|
Router 0 |
|
Router 1 |
MxN Interface
Fig. 10.5 Typical GCM/ProActive based multidomain runtime support for HPC
10 An Efficient Framework for Running Applications on Clusters, Grids, and Clouds |
173 |
router component representing the next level up in the infrastructure. Owing to the hierarchical composition and the routing interfaces associated with higher levels, all the nodes are logically connected, even if indirectly, to every other in the multi-domain. Hence, the independent MPI executions are coupled to form a single parallel application along the Hierarchical SPMD concept.
Collective communications profit from the topology, enabling them to be staged and parallelized. Besides, and whenever possible, for optimization purposes we can create on-demand direct bindings to perform point-to-point communications, thus bypassing the hierarchy.
10.4.4 Performance Evaluation
We evaluate the component-based framework and the hierarchical SPMD model through a nontrivial simulation of electromagnetic-wave propagation in three-space dimensions. This simulation is based on a finite element method working on arbitrarily unstructured tetrahedral meshes for solving a system of Maxwell equations.
From the computational point of view, the execution is characterized by two types of operations: purely local operations on the tetrahedra for computing integral values and a calculation involving neighbor subdomains, which involves a gather-compute- scatter sequence. Formulations are described in more detail in [5].
In [9], we highlighted performance improvements for applications developed along the Hierarchical SPMD concept when compared with pure “flat” MPI implementations including grid-aware ones (as Grid-MPI). The experimental results we present here focus on the comparison among three scenarios: a multi-cluster grid, Amazon EC2, and a multi-domain environment that couple both setups.
The experiments we present here were conducted in one cluster (grelon, located in Nancy, France) of the Grid5000 testbed and the Amazon EC2 platform with two instance sizes: Small instances and High-CPU Extra Large instances. Grid5000 resources present Dual Core Intel Xeon 5110 (1.6 GHz) with 2 GB of memory and Gigabit Ethernet interconnection. Small Amazon EC2 instances represent one compute unit with 1 GB of memory, and High-CPU Extra Large represent 20 compute units (eight virtual cores with 2.5 EC2 Compute Units each) with 7 GB of memory. The software involved in these experiments are Java Sun SDK v1.6.0_07, ProActive v3.91, and GridMPI v2.1.1.
Figure 10.6 presents the overall execution times and MFlops/s obtained in the different scenarios. With the application being networkand CPU-intensive, both CPU and network affect the overall performance. On average, Small Amazon EC2 instances present a performance four times smaller than one using the standard cluster of Grid5000. High-CPU Extra Large instances present a better CPU performance than Grid5000 machines, but provide a slower network interconnection which results in a comparable global performance. A mix of Grid5000 resources and Small Amazon EC2 does not perform well when compared with single-site