[START_REF] Engelbrecht | Reflections on mathematical models of deformation waves in elastic microstructured solids[END_REF]; [START_REF] Chatzigeorgiou | Generalized interfacial energy and size effects in composites[END_REF]. In this context, it is also worth mentioning continuum bodies, characterized at micro scale, by interacting spins in a crystalline lattice (see e.g. [START_REF] Grimmett | Correlation inequalities for the Potts model[END_REF]; [START_REF] De Masi | Potts models in the continuum. uniqueness and exponential decay in the restricted ensembles[END_REF][START_REF] De Masi | Coexistence of ordered and disordered phases in Potts models in the continuum[END_REF] for some relevant results using the Potts model). As some other generalized models it can predict size-effect since it includes the characteristic length observed at the nanoscale and can describe dispersion for waves propagation in microstructured solids. The typical form of the strain energy density W under infinitesimal deformations can be represented as follows W = W (e, ∇e e) (15.1) or W = W (e, ∇∇u), (15.2)

where e e = 1 2 (∇u u + (∇u u u) T )

is the strain tensor, u u is the vector of displacements, and ∇ is the three-dimensional (3D) nabla-operator [START_REF] Lebedev | Tensor Analysis with Applications in Mechanics[END_REF][START_REF] Simmonds | Non-local dynamic behavior of linear fiber reinforced materials[END_REF]. In what follows for brevity we use form (15.2). The model was presented in the original works by [START_REF] Toupin | Elastic materials with couple-stresses[END_REF]; [START_REF] Mindlin | Micro-structure in linear elasticity[END_REF]; [START_REF] Mindlin | On first strain-gradient theories in linear elasticity[END_REF] and in simplified form by Aifantis (1992[START_REF] Aifantis | Update on a class of gradient theories[END_REF]; [START_REF] Askes | Gradient elasticity in statics and dynamics: An overview of formulations, length scale identification procedures, finite element implementations and new results[END_REF]; [START_REF] Askes | Reducible and irreducible forms of stabilised gradient elasticity in dynamics[END_REF].

The characteristic feature of (15.1) and (15.2) is that W depends on a set of all second derivatives of u. Considering small deformations we can transform W into a quadratic form

W = 1 2 e e : C C : e e + 1 2 ∇∇u . . . D . . . ∇∇u, (15.3)
where C C and D are forth-and six-order tensors of elastic moduli, respectively. The standard assumption is that C C and D are not singular. Moreover, C and D D are assumed to be positive definite, see, e.g., [START_REF] Healey | Injective weak solutions in second-gradient nonlinear elasticity[END_REF]; [START_REF] Mareno | Global continuation in second-gradient nonlinear elasticity[END_REF]

Structural Mechanics

First, let us recall that such inequality in spatial directions is well-known in the structural mechanics. For example, the strain energy density of an extensible beam under tension and in-plane bending is given by

W = 1 2 K e (u ) 2 + K b (w ) 2 , (15.7)
where K e > 0 and K b > 0 are the extensional and bending stiffness parameters, u = u(x) and w = w(x) are longitudinal and transverse displacements, respectively, x is the coordinate along the beam axis, and the prime stands for derivative with respect to x.

The same situation can be observed in the Kirchhof-Love theory of plates and shells [START_REF] Timoshenko | Theory of Plates and Shells[END_REF][START_REF] Lebedev | Tensor Analysis with Applications in Mechanics[END_REF]. For example, the strain energy density of an elastic homogeneous plate of thickness h is given by (15.8) where E and ν are Young's modulus and Poisson's ratio, respectively, u α and w are the in-plane and transverse displacements, x α is a Cartesian coordinates, α = 1, 2. Hereinafter indices after comma denote derivatives with respect to x α , so w ,α is the partial derivative of w with respect to x α ,

W = Eh 2(1 + ν) u α ,β u α ,β + ν 1 -ν u α ,α 2 + Eh 3 24(1 + ν) w ,αβ w ,αβ + ν 1 -ν (w ,αα ) 2 ,
w ,α = ∂ w ∂ x α .
So, considering beams, plates and shells as 1D and 2D continua embedded into 3D physical space we see a difference in order of used derivatives in different directions. Obviously, for beams the preferable direction is tangent to the beam axis whereas for plates and shells it is normal to the middle surface. Nevertheless, here the mentioned difference concerns different components of displacements. For example, (15.8) includes all derivatives of the deflection w. In what follows we demonstrate another situation.

Here K

(3) e is the stiffness related to pivots undergoing tension/compression. Comparing (15.12) with the general constitutive equation ( 15.3) we see that D D is rather degenerated. Thus, the presented above models belong to the class of constitutive relations of reduced strain gradient elasticity. The pantographic beam structures are not unique example of such materials, other examples one can find in the hydrostatics of liquid crystals.

Smectics and Columnar Liquid Crystals

Smectics are the particular class of liquid crystals with layered structure, see [START_REF] Chandrasekhar | Liquid Crystals[END_REF]; de Gennes and Prost (1993); [START_REF] Oswald | Smectic and Columnar Liquid Crystals: Concepts and Physical Properties Illustrated by Experiments. The Liquid Crystals Book Series[END_REF]. Each layer is a two-dimensional liquid. Nevertheless smectics demonstrate existence of non-hydrostatic stresses and resistance to bending. The schematic structure of smectic A is given in Fig. 15.3 (a) where ordered arrangements of molecules in each layer is shown. For small distortion of the initially plane layers of a smectic the main kinematical descriptor is the displacement field u u u = u(x, y, z)i i 3 . So, the kinematics of smectics is determined by one scalar function u.

The strain energy density of smectics A is given (15.13) where B and K are elastic moduli describing the longitudinal stiffness along zdirection and the bending stiffness of the smectic layers, respectively. Another type of liquid crystals are so-called columnar phases which structure is shown in Fig. 15.3 (b). From the physical point of view these liquid crystals look as set of flexible deformable tubes which can easily slide along each other. For small deformations of this class of liquid crystals we introduce the vector of displacements (x, y, z). The strain energy density is now given by de [START_REF] De Gennes | The Physics of Liquid Crystals[END_REF] as follows (15.14) where B, K 1 and K 2 are elastic moduli.

W = 1 2 B(u ,z ) 2 + 1 2 K (u ,xx + u ,yy ) 2 ,
u u = u 1 i i i 1 + u 2 i i i 2 + u 3 i i i 3 , u k = u k
W = 1 2 B(u 1,x + u 2,y ) 2 + 1 2 K 1 (u 1,x -u 2,y ) 2 + (u 1,y + u 2,x ) 2 + 1 2 K 2 u 2 1,zz + u 2 2,zz ,
The similarity between strain energies (15.13) and (15.14) of these liquid crystals and the form of strain energy densities of pantographic beam lattices (15.12) is obvious. Indeed, all these forms contains incomplete set of second spatial derivatives, so they belong to the class of materials described using the reduced strain gradient elasticity.

Other Spatially Non-Symmetric Models

Almost all models known in structural and continuum mechanics are symmetric in spatial directions in mentioned above sense. Nevertheless, non-symmetric models are also known. Let us mention few equations of such kind.

The Kadomtsev-Petwiashvili equation is a two-dimensional analog of the famous Korteweg-de-Vries equation, see [START_REF] Kadomtsev | On the stability of solitary waves in weakly dispersing media[END_REF]. It takes the form

(u ,t + 6uu ,x + u ,xxx ) ,x + 3λ u ,yy = 0, (15.15)
where u = u(x, y,t), x and y are Cartesian coordinates and λ = ±1. Eq. (15.15) cames originally from acoustics and found further applications in the nonlinear theory of dispersive waves, theory of solitons, theory of ferromagnetics, string theory, see, e.g., [START_REF] Ablowitz | Solitons and the inverse scattering transform. SIAM, Philadelphia Aifantis EC[END_REF]; [START_REF] Ablowitz | Solitons, Nonlinear Evolution Equations and Inverse Scattering[END_REF]; [START_REF] Maugin | Nonlinear Waves in Elastic Crystals[END_REF]. The Kadomtsev-Petviashvili equation describes also the evolution of the localized structures over a large-time scale of a quasi-continuum model deduced from a nonlinear lattice model, see [START_REF] Pouget | Non-linear lattice models: complex dynamics, pattern formation and aspects of chaos[END_REF].

The next example is the PDE arose in the analysis of gas centrifuges, nowadays known as Onsager's pancake equation [START_REF] Wood | Onsager's pancake approximation for the fluid dynamics of a gas centrifuge[END_REF][START_REF] Eastham | The finite element method in anisotropic Sobolev spaces[END_REF]. It is given by (15.16) where u = u(x, y), b and f are given. Both equations (15.15) and (15.16) were derived using some approximation techniques in which the preferable spatial direction was chosen a priori.

e x (e x u ,xx ) ,xx ,xx + bu ,yy = f (x, y),

Conclusions

We briefly discussed a new class of strain gradient elasticity models called the reduced or degenerated strain gradient elasticity. Among such continua there are continual models of pantographic beam lattices and smectic and columnar liquid crystals. The common peculiarity for both media is a layered structure and sensitivity to bending only in certain directions. From the mathematical point of view the corresponding systems of partial differential equations and natural boundary conditions requires special analysis, such as given in [START_REF] Eremeyev | Linear pantographic sheets: existence and uniqueness of weak solutions[END_REF] within the framework of anisotropic Sobolev spaces. Let us note that the considered model is obviously anisotropic with a special type of anisotropy. Usually, the anisotropic behavior of solids is determines by symmetries of the tensors of elastic moduli. Here, in addition to this symmetries we meet strong dependence of the material properties on the spatial directions since the strain energy density may be independent on some components of strain gradient tensor. In particular, for pantographic beam lattice as for smectic and columnar liquid crystals there is a preferable direction normal to the inner layers.

Here we are restricted ourselves by infinitesimal deformations, but the models can be easily extended for finite deformations. So, we can easily consider the reduced strain gradient elasticity for large deformations. Another common peculiarity observed for pantographic beam lattices and liquid crystals is the existence of non-trivial solutions with zero energy. The further analysis of such constitutive equations can be performed using the material symmetry group defined in [START_REF] Bertram | Compendium on Gradient Materials[END_REF] as was performed for shells in [START_REF] Eremeyev | Local symmetry group in the general theory of elastic shells[END_REF] and for micropolar media in (Eremeyev andPietraszkiewicz, 2012, 2016).

Fig

  Fig. 15.3: Structures of liquid crystals. a) smectic A, b) a columnar.


Arnaud Bonnaffoux

Eddy Caron

Hadrien Croubois

Olivier Gandrillon

A Cloud-aware autonomous workflow engine and its application to Gene Regulatory Networks inference

Keywords: Auto-Scaling, Resource Management, Workflow, Cloud, Scientific applications, HPC

With the recent development of commercial Cloud offers, Cloud solutions are today the obvious solution for many computing use-cases. However, high performance scientific computing is still among the few domains where Cloud still raises more issues than it solves. Notably, combining the workflow representation of complex scientific applications with the dynamic allocation of resources in a Cloud environment is still a major challenge. In the meantime, users with monolithic applications are facing challenges when trying to move from classical HPC hardware to elastic platforms. In this paper, we present the structure of an autonomous workflow manager dedicated to IaaS-based Clouds (Infrastructure as a Service) with DaaS storage services (Data as a Service). The solution proposed in this paper fully handles the execution of multiple workflows on a dynamically allocated shared platform. As a proof of concept we validate our solution through a biologic application with the WASABI workflow.

Introduction

Scientists in fields like biology and physics tend to rely more and more on High Performance Computing (HPC) resources both to perform large scale simulations and to analysis the huge amount of data produced by said simulations as well as other experiments. For example, new generation DNA sequencers can now produce a large amount of data, in the terabyte range, at a very low cost. Analyzing these required the development of computing tools for large scale sequence alignment, which relies upon HPC resources [START_REF] Das | Large-scale parallel genome assembler over cloud computing environment[END_REF][START_REF] Yu | Rapid protein alignment in the cloud: Hamond combines fast diamond alignments with hadoop parallelism[END_REF]. Similarly, the reconstruction of Gene Regulatory Networks (GRNs) from high-throughput experimental data comes with a high computational cost, leading to the development of parallel algorithms [START_REF] Xiao | A new asynchronous parallel algorithm for inferring large-scale gene regulatory networks[END_REF][START_REF] Zheng | Cmip: a software package capable of reconstructing genome-wide regulatory networks using gene expression data[END_REF][START_REF] Lee | Designing a parallel evolutionary algorithm for inferring gene networks on the cloud computing environment[END_REF].

However, accessibility to these HPC resources is limited and Cloud-based platforms have emerged as good solution for people with these use-cases that might not have access to large computing infrastructures. Using the virtual resources offered by Cloud providers, anyone can build its own computing platform without having to bear the initial investment cost and the necessary maintenance that comes with own-ing the hardware. However, while HPC applications are moving toward the Cloud, the deployment mechanisms used are generally trying to replicate the existing paradigm rather than using the full elasticity the Cloud has to offer.

The approach most commonly used is to deploy Cloud instances such to have a platform similar to what users are familiar with, and use the batch scheduling mechanisms they are familiar with. While this approach requires minimal changes, the tools used were designed for a fixed platform, and do not benefit from the dynamicity of Cloud solutions. We, on the other hand, believe that using the dynamicity of Cloud infrastructures to modify the platform deployment in real time can help users achieve better performances at a lower cost. Managing such deployment is a complex task, which requires constant awareness of the platform and of the workload. In order to achieve that, we need the (re)deployment mechanisms to work autonomously. Rather than asking the user to dive into the details of the platform deployment, we have to build a solution that releases them from all interactions with this deployment process.

Unlike task placement, which is a well-studied issue, little work deals with the automation of Cloud platform deployment.

Our goal in this paper is to evaluate the efficiency of our framework, which contains mechanisms that automate the deployment of Cloud ressources into a self adapting, shared, computing platform, as well as scheduling scientific applications on top of it. As a proof of concept we validate our solution through a biologic application with the WASABI workflow. We provide a tool that contribute to the convergence of HPC applications and Cloud resources, thus providing easy access to HPC resources to all users.

Related work

Many scientific and industrial applications from various disciplines are structured as workflows [START_REF] Bharathi | Characterization of scientific workflows[END_REF]. A workflow can be seen as a structured set of operations which, given an input data set, produce the expected result. For a long time, the development of complex middleware with workflow engine [START_REF] Couvares | Workflow Management in Condor[END_REF][START_REF] Deelman | Pegasus: a Framework for Mapping Complex Scientific Workflows onto Distributed Systems[END_REF][START_REF] Caron | Workflow-based comparison of two distributed computing infrastructures[END_REF] automated workflow management. Infrastructure as a Service (IaaS) Clouds raised a lot of interest recently thanks to an elastic resource allocation and pay-as-you-go billing model. A Cloud user can adapt the execution environment to the needs of their application on a virtually infinite supply of resources. While the elasticity provided by IaaS Clouds gives way to more dynamic application models, it also raises new issues from a scheduling point of view. An execution now corresponds to a certain budget, which imposes certain constraints on the scheduling process.

Solutions to dynamically-scaled Cloud computing instances exist. For example in [START_REF] Mao | Cloud autoscaling with deadline and budget constraints[END_REF] the solution is based on deadline and budget information. In [START_REF] Kailasam | Optimizing service level agreements for autonomic cloud bursting schedulers[END_REF] the solution deals with Cloud bursting. Another autonomous auto-scaling controller, which maintains the optimal number of resources and responds efficiently to workload variations based on the stream of measurements from the system, is introduced in (Londoño-Peláez and Florez-Samur, 2013). This paper shows the benefits of an auto-scaling solution for Cloud deployments. However, these solutions do not handle workflow applications. Likewise in [START_REF] Nikravesh | Towards an autonomic auto-scaling prediction system for cloud resource provisioning[END_REF], authors gave a suitable prediction technique based on the performance pattern, which led to more accurate prediction results. Unfortunately, all these papers fail to consider the delays resulting from communications between the different tasks of a workflow.

In [START_REF] Mao | Scaling and scheduling to maximize application performance within budget constraints in cloud workflows[END_REF], authors show the benefit of auto-scaling to deal with unpredicted workflow jobs. They also show that scheduling-first and scaling-first algorithms have different advantages over each other within different budget ranges. The auto-scaling mechanism is introduced as a promising research direction for future work.

Nevertheless, some solutions provide an autonomous workflow engine. In [START_REF] Heinis | Design and evaluation of an autonomic workflow engine[END_REF], altering the cluster configuration helps the authors build an autonomous controller that responds to workload variations. Authors introduce a mechanism of self-healing that reacts to changes in the cluster configuration. This solution shows some benefits for cluster architecture but does not work well for Cloud architecture. Workflow engines for Cloud environments dealing with dynamic scalable runtimes are given in [START_REF] Pandey | An autonomic cloud environment for hosting ecg data analysis services[END_REF].

A comparative evaluation of several auto-scaling algorithms is given in [START_REF] Ilyushkin | An experimental performance evaluation of autoscaling policies for complex workflows[END_REF]. However, the policies discussed in the review solely focus on auto-scaling, thus missing on issues like data locality and tasks clustering. Our approach is different in that it considers a more complex issue where workflow optimizations can induce cycles in their clustered representation. This representation ask for more complex task placement and demand analysis mechanisms. Last but not least, our approach differs in that parts of the resource manager and of the scheduler are decentralized and rely on the nodes to take decisions by themselves in order to improve scalability.

Infrastructure

Our objective in this paper is to describe and evaluate the architecture of a middleware that uses resources from Cloud providers to build a computing infrastructure for the execution of scientific workflows.

IaaS Cloud platforms

Among the many offers Cloud providers propose, IaaS (Infrastructure as a Service) is arguably one of the most versatile. Through the use of virtualization technologies, it allows anyone to get access to remote resources and use them just as if they owned their own server. These resources are seen as virtual machines and they can run any system the user needs. This enables anyone to build their own computing infrastructure without the initial investment cost or the burden of maintenance that comes with owning hardware.

The main advantage of Cloud solutions, which explains their development over the past few years, is the versatility and dynamicity of these solutions. Not only can a user deploy a custom platform in just minutes, but the deployment can be modified to match any change in the workload. As such, users only have to pay for what is really needed, and not bear the cost of platform when not in use.

The allocation problem

It is easy to deploy a large platform using current Cloud technologies. However, knowing how many resources are really needed is a completely different problem. There might be many options, each one resulting in different performances and costs. While cost per unit of time is easy to compute, estimating performances and tasks completion time is extremely difficult. Consequently, the total deployment cost can also be hard to predict as it depends on completion time.

A common practice is to distribute the budget along a specific duration and get as many resources as one can afford during this period. This simple approach, which tries to maximize performances within a given cost constraint, has major drawbacks. Not only is the user committing all his budget, but there are no warranties to have enough resources during peak hours, and resources are very likely to be wasted during off-peak hours.

A more elegant and efficient solution would be to modify the deployment in real time so that it matches the needs. Estimating the needs is a very complex task, and adjustment should be performed 24/7, which would require too many actions to be realistically performed by a human. For it to be efficient, we need this process to be fully autonomous and not require any human input.

An autonomic solution

In order to automate the deployment of the platform, we have to design a control loop that could drive the allocation mechanisms. According to the MAPE-K [START_REF] Kephart | The vision of autonomic computing[END_REF] Such design is already part of common schedulers and is used to control the placement of the interdependent tasks in a workflow. However, unlike dependency control, the issue of platform deployment control is complex and still unsolved. This is this issue that our approach (Figure 1) tries to solve in the context of homogeneous IaaS Clouds.

In addition to the traditional mechanisms used to control the task flow (scheduling loop), we added fea- tures to the existing agents, as well as new agents, to implement a deployment control loop. More precisely, we built these such that two distinct mechanisms work in coordination to achieve the automation of both up-scaling and down-scaling.

Data locality Data locality is a major concern in the scheduling of workflows. While parallelization is expected to reduce the completion time of workflows, data transfer can produce undesirable side effect that reduces the overall performances.

In our previous work [START_REF] Caron | Communication aware task placement for workflow scheduling on daasbased cloud[END_REF]) we discussed the possibility to solve this issue using an off-line scheduling mechanism. The static analysis step described in this paper left us with blocks of tasks that already handle the issue of data locality and can therefore be scheduled without requiring the scheduler to solve this optimization issues at runtime.

Down-scaling control

The down-scaling is decentralized and controlled by the nodes themselves. Each node has its own work queue, and requests work from the scheduler when it has free resources in term of CPU (ability to start new work) or Down-link (ability to prefetch data). When a node requests work, the scheduler is to provide it with a block that can be executed on this node without breaking the deadline constraints. However, if the platform is oversized, the nodes will end up executing all the tasks up to the point where the scheduler cannot provide work to the requesting node. In addition to requesting work, when a node work queue is empty, the node starts a suicide timer. Once this timer is initiated, and if no work has been received by then, the node will automatically deallocate itself before the beginning of the next billing hour. This mechanism helps reduce the dimension of oversized platforms during off-peak hours thus enabling a more efficient platform deployment that decreases infrastructure cost.

Up-scaling control Unlike the down-scaling, the up-scaling mechanism is not decentralized, and requires a global knowledge of the platform. It relies on a new agent, the deployer. When the workload changes, for example with the addition of new jobs by the users, the scheduler will inform the deployer of these changes, and provide it with a description of the work queues and nodes status. This monitoring of the platform means that the deployer is able to use simple list scheduling algorithms to simulate jobs placement, analyze it, and plan for the deployment of new nodes if required.

If new nodes have to be deployed, the deployer will do so according to the last computed deployment schedule. This schedule can be overridden by new, updated, runs of the analysis and planning steps. This control mechanism ensures new nodes are deployed when required, such that QoS is achieved (deadlines are meet).

Gene Regulatory Networks Inference

WASABI

Gene Regulatory Networks (GRN) play an important role in many biological processes, such as cell differentiation, and their identification has raised great expectations for understanding cell behaviors. Many computational GRN inference approaches are based on bulk expression data, and they face common issues such as data scarcity, high dimensionality or population blurring [START_REF] Chai | A review on the computational approaches for gene regulatory network construction[END_REF]. We believe that recent high-throughput single cell expression data (see [START_REF] Pina | Inferring rules of lineage commitment in haematopoiesis[END_REF]) acquired in time-series will allow to overcome these issues and give access to causality, instead of "simple" correlations, to dissect gene interactions. Causality is very important for mechanistic model inference and biological relevance because it enables the emergence of cellular decisionmaking. Emergent properties of a mechanistic model of a GRN should then match with multi-scale (molecular/cellular) and multi-level (single cell/population) observations. The WASABI (WAves Analysis Based Inference) framework is based upon the idea of an iterative inference method. This will allow to adopt a divide-and-conquer type of approach, where the complexity of the problem is broken down to a "one gene at a time" much simpler problem, which can be parallelized.

The whole process can be decomposed along the following steps:

1. Gene Ordering. We order all the 94 genes from time-series single cell gene expression data from chicken erythrocyte progenitors acquired during their differentiation process [START_REF] Richard | Single-cell-based analysis highlights a surge in cell-to-cell molecular variability preceding irreversible commitment in a differentiation process[END_REF]. These data have been analyzed using a stochastic mechanistic model of gene expression, the Random Telegraph model [START_REF] Peccoud | Markovian modelling of gene product synthesis[END_REF].

2. Iterative inference. For each step of the inference process a new gene is added to a set of GRN candidates inferred in the previous iterations. It creates new extended GRN candidates to be assessed, though all possible combinations with the previously conserved networks. For each new network, its behavior will be simulated using a recently described mathematical formalism [START_REF] Herbach | Inferring gene regulatory networks from single-cell data: a mechanistic approach[END_REF] and the resulting gene expression values will be compared to the experimental one. Should the fit between the two genes expression be acceptable, the networks will be kept and carried to the next step. If, on the contrary, the network should be too different, then it will be pruned and will not participate in future attempts.

At the beginning of the process, one would expect (and an initial assessment confirmed) that the number of suitable networks will sharply increase. In this growth phase, an efficient parallelization will be of essence. In a second phase, one expects that most of the "bad" networks will have accumulated so many errors that they will diverge from the experimental reality, and it will in the end result in the generation of a manageable amount of networks.

The use of Design of Experiment approaches [START_REF] Kreutz | Systems biology: experimental design[END_REF] should finally help us to get to the most probable network.

WASABI workflow description

WASABI, as an application, is composed of many steps, each one divided into many instances of the same elements. The control flow, which links these many elements into the complete application, can express this iterative structure through a DAG of successive fork-join patterns. The WASABI workflow contains 9 fork-join steps of width 5, 6, 36, 252, 1000, 1000, 1000, 1000, 1000. This adds up to a total 5309 tasks (including synchronization tasks) and 10598 control flow dependencies. Total runtime for all these tasks is 4250.1 hours. All these informations, as well as details about individual tasks, such as runtime) were extracted from traces of the previous runs. This allowed us to build a descriptions of WASABI as a workflow. While our middleware is not based on the Pegasus engine, for the sake of clarity, our inputs file are compliant with the well-known Pegasus workflow syntax. It is this workflow that we will be using to compare our deployment solution to existing approaches.

Evaluation

Comparison to fixed deployment for a single workflow execution

In order to estimate the efficiency of our deployment, we will compare it to a more traditional "fixed deployment" method. In a fixed deployment, the user books a given amount of resources which are then used by a batch scheduler. Whenever a task is ready to run and a node is available, the task will be placed on the node to be computed. It is clear that, with this approach, the more resources there are, the faster the workflows will be executed, up to the point where the sequential dimension of the workflow prevents the user from achieving any more parallelism. Still, having more resources also means that more cpu time is wasted during the synchronization parts of the workload. Once all computation is done, the user has to release the resources.

Assessing total cost and runtime of a workflow for a specific deployment is a hazardous operation which requires trial and error. Simulation can help with this process, but it requires knowledge of the platform specifications and time, which users non familiar with computer science might not have. What our framework offers is a platform where users can specify their workflows and the required wall time for each of them. The platform is then automatically deployed in order to meet the expected QoS while achieving the lowest cost possible.

The results in this section have be achieved through simulation. Details about the WASABI workflow were extracted from traces of runs on existing HPC structures (IN2P3). Estimation of the deployment cost for those simulations were obtained assuming their deployment on Amazon EC2 instances of similar performance. The down-scaling mechanism was tunned to match Amazon EC2 billing policy.

Our first results show platforms performance and cost for deploying a single WASABI workflow. This workflow contains 5309 tasks for a total of 4250 core-hours. Ideally, we would like to pay only for these 4250 hours of computation, but the billing policy of Cloud providers is such that we will also be charged for some unused time when we cannot perfectly use the hours allocated to each node. For example, a node used to compute a task that lasts 1 hour and 48 minutes will be billed for 2 hours, and we are thus wasting 12 minutes of CPU time. The critical path in this workflow is about 17 hours, meaning that no matter how many resources we have, we will not be able to get results faster than that using the type of node considered here.

For this experiment, we run simulations with fixed platforms of sizes varying from 100 to 400 nodes. This gives us a base line of what current approaches achieve. The results in Table . 1b and Figure 1a show a Pareto front which comes from the conflict between two contradictory objectives: maximizing platform performance and minimizing deployment cost. This confirms the idea that there is not ideal value for the size of a fixed platform. Selecting the size of a fixed platform results in a choice between performance and cost on this non-optimal front.

However, the dynamicity offered by the deployment control loop implemented in our framework leads to better results. By efficiently allocating and deallocating nodes we manage to free ourselves from this Pareto efficiency and we achieve good results in term of deployment cost even when facing tight QoS constraints.

Multi-tenant/multi-workflows

deployment: Example of a small lab using WASABI

In the previous section, we saw how our approach can efficiently deploy a computing platform to execute a single instance of the WASABI workflow. However, this context still requires quite many human interventions as the platform was dedicated to this workflow. This means that in order to execute their workflow, the user first has to deploy the platform manager. Even worse, in the case of a fixed allocation, the user has to deploy the fixed platform, selecting the number of nodes they want and to be there at the end of the run to shut down the platform.

We believe that the platform should be maintenance-free, and users should be able to submit workflows to an already existing platform manager. This perpetually running tool would be the entry where any user can submit their workflows. The platform would be handled automatically, allocating new nodes when needed, sharing nodes between workflows of different users and shutting nodes down when they are no longer necessary. Sharing a computing platform today, using the fixed deployment approach and a batch scheduler, is simple but very inefficient. In addition to the waste we could already witness when running a single workflow, we also have to consider all the wasted resources which are allocated during off-peak hours.

We simulated such a context at the scale of a small laboratory. In this example, we consider a research team who uses the WASABI application to analyze their results. Over a one week period, our imaginary lab produces data requiring 10 runs of WASABI. Researchers in this team submit the data for analysis when available. As such, the submissions are not distributed evenly throughout the week. In particular, we assume that all submissions will be performed during work days. While no new jobs are submitted during the week-end, computation can still be performed during the week-end. When using the autonomous approach, they ask the results to be available 24 hours after submission.

Statistics for this simulated workload is reported in Table . 2. Gantt diagrams for both deployment methods are shown in Figure 2. Once again, we see that the dynamic allocation of node has major advantages over the previous approach.

The most obvious advantage to our method is cost. Having a platform with 500 t2.small instances running for a whole week would cost $1932.00, with an efficiency of 50.60% with this particular workload. For the same work, our approach would reduce deployment cost by 44.57%.

The second advantage to our method is the ease of maintenance and the efficiency of the elastic deployment. Some might argue that the fixed platform does not have the right size, and using 500 nodes is an empirical choice, and they would be right. However, as discussed previously, choosing which platform size to use is not an obvious choice. While having a 500 nodes platform leads to wasted resources, it is also not enough to ensure that sufficient resources are available to all users. During rush periods, workflows are fighting for resources. This is visible around the middle of Figure 2a when all nodes are busy. During this period, no resources are wasted but work does not progress as users would expect, causing some workflows to finish with delays. While users would require the workflows to be computed within 24 hours, some took over 33 hours due to the limited number of resources available.

Unlike the fixed platform approach, the autonomous deployment allocates resources when needed which limits waste during off-peak hours and guarantees that the user will have the results they expect with minimal delays. This is visible in Figure 2b. The burst in the workload causes the nodes to be allocated and deallocated in blocks. When many resources are required, the platform manager deploys many nodes. Once the work has been done, nodes start to suffer work shortage and start deallocating. We can see that the burst that caused the fixed platform to saturate is here triggering the allocation of many nodes. These nodes execute tasks from all active workflows and contribute to meeting the QoS users expect. In our example, this elastic allocation process helped limiting delays to at most 7 minutes 12 second.

We also notice that the efficiency achieved by our method in the multi-tenants context is slightly bet- Note: Cost were computed assuming Amazon EC2 t2.small instances for an on-demand price of $0.023/hour.

Table 2: Platforms statistics for the multi-tenants execution of WASABI workflows. 10 workflows are executed over a 1 week period, for a total of 42501.0 core-hours of computation. ter than in a single workflow context. On a fixed platform, having multiple workflows causes conflicts and decreases the QoS. However, with our elastic deployment manager, having multiple workflows on the same platform is a good thing as the workflows can share nodes to maximize their use and reduce waste. QoS is maintained by the allocation of new resources when required.

Last but not least, the autonomous deployment makes the results availability more predictable. This is more comfortable for users who might require these results for specific deadlines or just to be part of a broader pipeline. With a fixed platform, users are affected by each other's submissions which might lead to frustration and conflicts.

Conclusion

In this paper, we presented the outlines of a fully autonomous platform manager. We also described the WASABI application, and how it can benefit from this platform management. Comparing this approach to more traditional ones, we showed that not only do we achieve the QoS required by the users through deadlines, but we also achieve substantial savings in deployment cost.

So far this approach is restricted to homogeneous infrastructures, and further work is required to make this solution more versatile. Other optimization objectives, such as minimizing a workflow execution time with a constrained budget, also require some work. Still, our multi-tenants example showed that using our platform to deploy existing scientific workloads can result in cost savings of 40% while avoiding the need for human intervention in the management of the platform.

In conjunction with previous work on the static clustering of workflows for DaaS-based Cloud execution, we now have a comprehensive solution. While the modular nature of this framework means the components could be improved, the current state of this solution is already effective and we hope to apply it soon in the context of an easy-to-use, all-in-one solution for scientific and industrial users.

  model, such a loop requires 4 features: (1) Monitoring the platform, both in terms of platform status and workload; (2) Analyzing the needs in term of platform allocation; (3) Planning actions to modify platform allocation towards what is required; (4) Executing the plan.

Figure 1 :

 1 Figure 1: Outlines of our middleware with autonomous platform deployment capabilities.

Figure 2 :

 2 Figure2: Gantt diagram of VMs during the multi-tenants execution of WASABI workflows. 10 workflows are executed over a one week period, for a total of 42501.0 corehours of computation. For each VM (line) computation time is shown in red and idle time in grey. Figure2ashows results for fixed deployment of 500 VMs running for the fun weeks while Figure2bshows result for an autonomous deployment that spawned 4698 VMs over the week, some of which only ran for a single hour.

Table 1 :

 1 Workflow runtime in hours (lower is better) Details for different runs of the WASABI workflow on various platforms. The workflow contains 5309 tasks for a total of 4250.1 core-hours

		200	350 VMs 400 VMs	fixed platform autonomic platform
						Platform	#VMs	Walltime	VM duration	Total usage	Cost	Efficiency
	$ (lower is better) Platform cost in	140 160 180 120	250 VMs 200 VMs target: 20h target: 24h target: 28h target: 32h 300 VMs target: 18h	150 VMs	Fixed (100) Fixed (150) Fixed (200) Fixed (250) Fixed (300) Fixed (350) Fixed (400) Autonomous (18h) Autonomous (20h) Autonomous (24h) Autonomous (28h)	100 150 200 250 300 350 400 851 711 653 676	47:10:51 35:04:51 28:00:49 27:17:42 24:16:44 23:24:56 21:48:05 18:09:14 20:08:05 24:06:05 28:05:46	48h 36h 28h 28h 25h 24h 22h Variable Variable Variable Variable	4800 core-hours 5400 core-hours 5600 core-hours 7000 core-hours 7500 core-hours 8400 core-hours 8800 core-hours 4915 core-hours 4734 core-hours 4811 core-hours 4726 core-hours	$110.400 $124.200 $128.800 $161.000 $172.500 $193.200 $202.400 $113.045 $108.882 $110.653 $108.698	88.54% 78.71% 75.89% 60.72% 56.67% 50.60% 48.30% 86.47% 89.78% 88.34% 89.93%
						Autonomous (32h)	663	32:03:59	Variable	4676 core-hours	$107.548	90.89%
						Note: Cost were computed assuming Amazon EC2 t2.small instances for an on-demand price of $0.023/hour.
			(a) Cost/Makespan front					(b) Statistics