M Spezzapria
email: mattia.spezzapria@dii.unipd.it

M Forzan

F Dughiero

Multiphysical-Multiscale FEM Simulation of Contour Induction Hardening on Aeronautical Gears

Keywords: Induction hardening, Phase transformation, Coupled problems

Since many years, induction hardening has been successfully applied for the heat treatment of components, mainly in the aeronautical and automotive sectors, because of its peculiar advantages like high quality and repeatability of process and its easy automation. A multi-scale multiphysical finite element (FE) analysis is presented in this paper for the prediction of microstructural evolution during induction hardening processes. An ad hoc code has been developed in order to calculate the metallurgical phase changes that occur during heating and cooling steps. This routine has been coupled with commercial FEM codes able to solve the coupled electromagnetic and thermal problem that typically describes the induction heating processes. During the heating, the magnetic field generated by the coil induces currents in the workpiece and as consequence the heating of conductive material by Joule effect. In induction hardening of steels, an external layer of the piece is heated up to the austenitization temperature, then it is cooled down to obtain a layer of martensite. In thermo-metallurgical model, material properties depend on the temperature distribution but also on the microstructure since the material is a mixture of different phases. From the solution of the coupled steady-state, at a given frequency, electromagnetic and transient thermal problem, temperature distribution as well as heating and cooling rates are used for the evaluation of the existing metallurgical phases at every time step. The effect of latent heat of solid-solid phase transformations has been also considered.The model developed has been applied on a real complex case,e.g. an aeronautical spur gear, in order to predict the phase transformation during the whole process.The numerical results will be verified through experimental validation.

Introduction

Heat treatments are used in order to improve the mechanical properties of steel parts. In the case here presented, superficial heat treatments permit to modify only the superficial layer of a work-piece, maintaining unchanged the core of the material. Nowadays Contour Induction Hardening (CIH) process is increasingly applied instead of carburizing process, due to its repeatability and easy automation. During induction hardening, the magnetic field generated by a coil induces current in the work-piece, which is heated by Joule effect. During the process, solid-solid phase transformations occur in the material. These transformations depend on the thermal history, i.e. on the evolution of temperature distribution during the time. Due to its multiphysical nature, simulation tools become essential for the prediction of phase transformations. Many studies have been carried out in the field of heating by induction [START_REF] Dughiero | A 3DNumerical FEMModel for the Simulation of Induction Welding of Tubes[END_REF][START_REF] Dughiero | ATraslational Coupled Electromagnetic and Thermal Innovative Model for Induction Welding of Tubes[END_REF] and for some specific cases of induction hardening [START_REF] Schwenk | Experimental Determination of Process Parameters and Material Data for Numerical Modeling of Induction Hardening[END_REF][START_REF] Candeo | Multiphysical Modeling of Induction Hardening of Ring Gears for the Aerospace Industry[END_REF], but the multiphysical simulation of all the phenomena that occur during the whole process is still an open task.

Electromagnetic Formulation

The mathematical analysis of coupled electromagnetic and thermal problem has been carried out by solving Maxwell and Fourier equations. The computation of magnetic flux density and induced current density is obtained by solving a time-harmonic eddy-current problem at a prescribed frequency.The numerical solution of the EM problem has been carried out by means of the well-known Magnetic Vector Potential formulation where the Coulomb gauge has been imposed in order to guarantee the uniqueness of magnetic vector potential 𝑨:

∇ × 1 𝜇 ∇ × 𝑨 + 𝜎 𝑗𝜔𝑨 + ∇𝑉 = 0 ∇ • 𝜎 𝑗𝜔𝑨 + ∇𝑉 = 0
In which 𝜎 is the electrical conductivity, 𝑉 the electric scalar potential and 𝜔 the angular frequency. When the current density distribution is known in the conductive body, the distribution of power densities by Joule effect can be evaluated as follow:

𝑤 𝑝 = 𝜌 𝐽 2 = 𝜌𝜔 2 𝐴 2
where 𝜌 is the electrical resistivity.

Thermo-Metallurgical Formulation

The nodal power densities calculated in the EM step for each time step are used as the internal heat sources in a coupled thermo-metallurgical model.

In the thermo-metallurgical model the material can be described as a mixture of different phases, each one with different physical properties. The global material properties can be extimated through a linear rule of mixture:

𝑃 𝑇, 𝜉 𝑘 = 𝑃 𝑘 (𝑇)𝜉 𝑘 𝑁 𝑘=1
where 𝑃 𝑘 (𝑇) is the value of the physical property, temperature dependent and 𝜉 𝑘 is the volume fraction of the k-th phase. During phase transformations latent heat is absorbed or released by the body and this effect must be included in the calculations for an accurate extimation of temperature distribution. The temperature distribution within the workpiece is determined by the modified heat conduction equation:

∇ 𝜆∇𝑇 + 𝑤 𝑝 + ∆𝐻 𝑘 𝑑𝜉 𝑘 𝑑𝑡 𝑁 𝑘=1 = 𝛾𝐶 𝑝 𝑑𝑇 𝑑𝑡
where ∆𝐻 𝑘 is the enthalpy change due to phase tranformation. The thermal exchange by convection and radiation have been taken into account during the heating stage on the external surfaces of contact between the trated body and the air:

Φ 𝑇 𝑆 , 𝑇 ∞ = ℎ 𝑇 𝑆 -𝑇 ∞ + 𝑘 𝐵 𝜀 𝑇 𝑆 4 -𝑇 ∞ 4
where ℎ is the coefficient of heat exchange by convection, 𝑘 𝐵 the Stephan-Boltzmann constant and 𝜀 the emissivity of the surface. During the induction heating process the initial microstructure (generally made of pearlite, ferrite and carbides) changes when austenitization temperatures are reached: below the Ac1 temperature, the microstructure is composed by ferrite and pearlite, between Ac1 and Ac3 it is a mixture of ferrite, pearlite and austenite and above Ac3 the microstructure is typically inhomogeneous austenite. These temperatures are affected by the chemical composition, heating rate and also by microstructure. The kinetics of transformation during high heating rate processes can be calculated through the use of Continous Heating Transformation (CHT) Diagrams, which provideanindication of thetransformation temperaturesat differentheating rates. In this study, the CHT diagram has been derived from the literature and the austenite transformation kinetic has been treated by using a linear interpolation.

During quenching several types of microstructures are generated by the decomposition of austenite (pearlite, ferrite, bainite and martensite), depending on the cooling rate. The microstructure can be evaluated starting from the thermal history using Isothermal (IT) diagrams. These diagrams can be drawn through a numerical method developed by Kirkaldy and reviewed by Victor Li [START_REF] Victor | A Computational Model for the Prediction of Steel Hardenability[END_REF]. The numerical method is based upon Zener and Hillert formulas which are derived from kinetic-chemical equations. Once the IT diagram hasbeen calculated, an analytical procedure has been developed for the calculation of microstructure evolution during quenching. Considering isothermal conditions, the kinetics of diffusional transformation can be expressed through the Johnson-Mehl-Avrami-Kolmogorov (JMAK) equation:

𝜉 𝑘 = 1 -exp (-𝑏 𝑘 𝑡 𝑛 𝑘 )
where 𝜉 𝑘 is the total ammount of transformed phase, 𝑡 is the time, 𝑏 𝑘 and 𝑛 𝑘 coefficients directly deduced from IT diagram. Diffusive transformations always require an incubation time before starting and this can be explained through Scheil's additivity rule:

𝑆 = ∆𝑡 𝑖 𝜏 𝑠 𝑡 𝑖 = 1 𝑛 𝑖=1
in which 𝜏 𝑠 𝑡 𝑖 is the incubation time at a current temperature and ∆𝑡 𝑖 is the time increment.

Transformation begins when Scheil's sum is equal to unity.During quenching the material is never subjected to isothermal conditions and also sometimes the austenite is not the only metallurgical phase existing in the material. To solve this problem the thermal history during the quenching needs to be discretized into isothermal steps. The effective elapsed time must be corrected, because of the different kinetics of transformation that occur during each step and can be calculated as the sum of the time step and a fictitious time evaluated from the IT diagrams [START_REF] Denis | Coupled Temperature, Stress, Phase Transformation Calculation Model Numerical Illustration of the Internal Stresses Evolution During Cooling of a Eutectoid Carbon Steel Cylinder[END_REF]:

𝑡 𝑘 * = -𝑙𝑛 -𝜉 𝑘-1 𝑏 𝑘 1 𝑛 𝑘
where 𝜉 𝑘 -1 is the transformed phase in the previous step. Once the fictitious time is known a fictitious volume fraction 𝜉 𝑖 * can be calculated through the JMAK equation:

𝜉 𝑘 * = 1 -𝑒𝑥𝑝 𝑏 𝑘 𝑡 𝑘 * + ∆𝑡 𝑛 𝑘
Hence the practical transformad volume fraction is:

𝜉 𝑘 = 𝜉 𝑘 -1 𝐴 -𝜉 𝑘-1 𝜉 𝑚𝑎𝑥 in which 𝜉 𝑘 -1 𝐴
and 𝜉 𝑘 -1 are respectively the austenite volume fraction and the transformed phase in the previous step and 𝜉 𝑚𝑎𝑥 is the maximum possible transformed fraction.The equation considers that a part of the whole microstructure may not transform because it has been already transformed or it was not austenitized. This is the case of coexistence of different phases due to a partial austenitization that occurs where Ac3 temperature has not been reached.A different formulation is used to model the martensitic transformation that describes this process as a diffusionless (or displacive) transformation.The martensite volume fraction is generally evaluated through the Koistinen-Marburger (KM) model [START_REF] Koistinen | A General Equation Prescribing the Extent of the Austenite-Martensite Transformation in Pure Iron-Carbon Alloys and Plain Carbon Steels[END_REF], but it tends to underextimate the transformed part in low-alloy steels.In this model, the martensite volume fraction has been calculated through a semi-empirical model proposed by Lee [START_REF] Lee | Comparison of Two Finite Element Simulation Codes Used to Model the Carburizing of Steel[END_REF]:

𝜉 𝑀 = 𝜉 𝐴 • 1 -exp -𝐾 𝐿𝑉 𝑀 𝑆 -𝑇 𝑛 𝐿𝑉
in which 𝜉 𝑀 is the total ammount of martensite, 𝜉 𝐴 the volume of parent phase, 𝐾 𝐿𝑉 and 𝑛 𝐿𝑉 are two coefficients dependent by the chemical composition

3D FEM model and Results

In this study the numerical simulation havebeen divided in two main steps: the first one is the electromagnetic and thermal coupled calculation solved by means of the commercial FEM software Flux 3D and the second one is a thermometallurgical simulation developed in Comsol with ad hoc MATLAB sub-routine for the evaluation phase transformations kinetics. The developed model has been applid to a 56-teeth, 2.5 mm modulus spur gear made of AISI 4340, a low alloy steel used in the aeronautical sector due to its mechanical properties and high hardenability. Only a partof the entire geometry of the gear, drawn with CAE packages, has been modeled in order to exploit the symmetries of the model and reduce drastically the number of degrees of freedom of the problem.Current in the coil is generated by the voltage drop assigned between the radial-symmetrical faces of the coil. Non-linear behavior of thermal and magnetic properties of material has been considered. For this specific type of gear, the process starts with a long lasting low-power preheating at MF (10 kHz) followed by 10 second dwell time in order to reach a uniform temperature on the gear tooth (c.a. 280°C). Then, a high-power high-frequency shot (185 kHz -0.23 s) is applied.The tests have been carried out with an industrial induction hardening machine fed by two IGBT converters (10 kHz -600 kW and 150-250 kHz -350 kW). The frequency cannot be tuned because the capacitor bank is not modifiable and, as consequence, resonance frequency depends only upon the inductor-load system.At the end of the high frequency heating stage the gear is moved down in the shower. The spray quenching consists of 30 second of 12% aqueous polyalkylenglycole (PAG) solution.During quenching the Heat Convection Coefficient, which controls the cooling rate, is not constant but varies significantly with the temperature. The results obtained from the simulation have been validated through experimental tests and compared in Fig. 1, in which the martensite distribution along the tooth profile and along the vertical section of the root is shown. These results show a very good accordance between the experiments and numerical models.

Conclusions

A FEM based mathematical method has been developed in order to predict the phase transformations kinetics during the whole process of induction hardening. In particular:

-A non-linear magnetic behavior has been considered for the given steel, taking into account both magnetic saturation and Curie temperature. -Both heating and quenching process have been simulated, calculating the complete thermal history and the microstructure at every time step that discretizes the process time. -Different physical models have been weakly coupled in order to properly take into account the mutual dependences of material properties. Through experimental procedure on a complex shape geometry the model implemented has been validated, showing a great accordance between the results.

Fig. 1 :

 1 Fig. 1: Comparison between experimental martensite distribution on the top face of the tooth (etching Nital 3%) and the temperature distribution evaluated with the numerical method


Cyril Séguin
email: cyril.seguin@u-picardie.fr

Gaël Le Mahec
email: gael.le.mahec@u-picardie.fr

Benjamin Depardon
email: b.depardon@gmail.com

Dynamic Elasticity in Distributed File Systems

In IaaS Cloud Computing platforms, elasticity offers to users the possibility to adjust the number of resources to the current workload, taking into account peak and trough periods (high and low activity) by powering down/up some resources. In previous work, we solved the challenges raised by the extension of elasticity to storage resources in the context of static data popularities. In this paper, we address the same challenges in the context of dynamic data popularities. We propose 3 solutions that estimate the data popularities, and an algorithm that reduces or increases the number of used server according to the period activity. Based on the platform cost (the resources are paid for the time they are used), our simulations on top of SimGrid show that we could either improve HDFS' performance by up to 99% while providing similar cost, or we could reduce cost up to 50% while providing similar performance.

Introduction

Since about a decade, Cloud Computing platforms have become very popular. At their beginning, they were mainly used for business or commercial applications, but they have quickly extended to almost all IT activities. From Customers Relation Management to High Performance Computing, Cloud Computing is now an unavoidable technology. Among the different Cloud models, Infrastructure as a Service (IaaS) is one of the most used for High Performance Computing. Indeed, these platforms can punctually offer very large computing infrastructures to researchers who do not have the needs or the funds to acquire their own computing resources. On these platforms it is possible to get access to thousands of resources for some hours, paying exactly what is needed for a particular problem to solve. An essential characteristic of this kind of platform is the elasticity, i.e., the capability to be dynamically extended or reduced by adding or removing resources. Applications take into account these variations of resources availability and distribute computing tasks among the computing resources to achieve a good load balancing. Cloud elasticity offers to users the possibility to adapt the computing platform to workloads with peak (high activity) and trough periods (low activity) by powering down/up some resources.

Today, data growth being a major concern that administrators of datacenters have to deal with, the main challenge for large scale computing platforms is to give access to efficient and reliable storage systems. Some frameworks have been developed to deal with such data intensive applications. Nowadays, the main storage solution used by supercomputers, clusters and datacenters is Distributed File System (Ceph [START_REF] Weil | Ceph: reliable, scalable, and high-performance distributed storage[END_REF], Gluster [START_REF] Gluster | An Introduction to Gluster Architecture[END_REF], HDFS [START_REF] Shvachko | The hadoop distributed file system[END_REF], . . . ). However, extending elasticity to the DFSs represents some challenges. Indeed, these DFSs allow for voluntarily adding or removing resources but it usually implies data movements, introducing delays, bandwidth consumption, and sometimes loss of data.

In what follows, we call popularity of a data the number of requests on this data for a given time interval. In our previous work [START_REF] Séguin | Towards elasticity in distributed file systems[END_REF], we addressed these challenges in a context of static data popularity, that is the number of requests on each data is known and regular during the workload. In this context, we were able to remove or add storage resources to face with a workload activity while maintaining data availability and good performance. In this paper, we address the same challenges in a context of dynamic data popularity, that is we cannot make assumption about the number of requests on each data before the requests' submissions. We focus on reducing the number of used resources and on increasing read access performance facing with data popularities variations. These two conflicting goals are grouped into the notion of platform cost that we aim to minimize. Our solutions rely on a dynamic adaptation of the replication factor (number of replicas per data) to the data popularities. We provide several algorithms that create or remove replicas that are distributed across the fewest possible servers.

Related work

Distributed file systems, such as Ceph [START_REF] Weil | Ceph: reliable, scalable, and high-performance distributed storage[END_REF], HDFS [START_REF] Shvachko | The hadoop distributed file system[END_REF], Gluster [START_REF] Gluster | An Introduction to Gluster Architecture[END_REF], Lustre [START_REF] Lustre | A scalable, high-performance file system[END_REF], divide data into fixed-size blocks and replicate them across multiple storage resources. Each data has the same replication factor and each storage resource almost stores the same amount of data. These systems provide good performance by using as many servers as possible and by aggregating their throughput. However, they are not compatible with the cloud platform's elasticity. The data placement allows them to safely remove only r -1 servers, where r is the replication factor, without loss of data. Removing more servers is possible but is likely to be hard. Indeed, it is a special case of the set covering problem which is an NP-complete problem [START_REF] Thereska | Sierra: a power-proportional, distributed storage system[END_REF]. Moreover, the data placement and the replication factor are not based on data popularities. Multiple data with a lot of requests may be stored on the same server and may have the same replication factor as data with fewer requests. This server can quickly become a performance bottleneck.

Some DFSs, such as ERMS [START_REF] Cheng | Erms: An elastic replication management system for hdfs[END_REF], address this last problem. They focus on adapting the replication factor to the data popularities that they try to estimate based on historic popularities. Based on these popularities, data are ranked into two sets: hot and cold. ERMS respectively add or remove replicas of hot or cold data. However these systems focus on performance and fault tolerance but not on platform cost (i.e. the number of resources used and how long they are used). Moreover they do not provide a data placement based on their popularities. It exists some DFSs that address the problem of distributed file system elasticity in a context of dynamic resources extension/reduction (Rabbit [START_REF] Amur | Robust and flexible power-proportional storage[END_REF], Sierra [START_REF] Thereska | Sierra: a power-proportional, distributed storage system[END_REF], SpringFS [START_REF] Xu | Springfs: Bridging agility and performance in elastic distributed storage[END_REF]). But, they address this problem by ensuring the power proportionality. That is the power used by the platform should be proportional to the performance at any time. These systems try to estimate the future load based on historic load. According to this future load, they add or remove resources to keep the proportionality. However, they do not take into account the popularities of the data to adapt their placements and replication factors.

Challenges

Data intensive applications frequently and concurrently request data. These requests can concern the same data on different servers or different data on the same server. According to data popularities and to reach good performance, the replication factor of each data can differ. In peak periods, by creating several replicas, the requests can be distributed among these replicas to balance the servers load. In trough periods, by removing replicas, some servers can be stopped. For our problem, defining peak and trough periods, and choosing the replicas to be created or removed is critical. But removing and/or creating replicas is not always a good solution. Reducing the number of active servers may have impact on performance, as well as performance improvements may have impact on the number of active servers. So, one of our challenges is to find a good trade-off between reducing the number of storage servers and improving the platform responsivity by adding more replicas. Finally, data popularities change over time. Estimating these data popularities variations is critical to get close to optimal performance while using the fewest possible servers. In the next sections, we introduce the solutions we propose to rise to these challenges.

Assumptions

In a DFS, data are divided into fixed-size blocks. For the rest of this paper, let the term data denotes a data block. We consider the DFSs are deployed on a cloud platform composed of homogeneous resources (same cpu, memory, storage capacity, network bandwidth. . . ). Clients applications and servers are all located inside the platform (no access from the outer world). Each machine have a unique network interface and they are all connected to a unique network switch. So, the bandwidth available for the communications depends only on the number of concurent accesses to the same server. We use the same definition of data popularity that in ERMS [START_REF] Cheng | Erms: An elastic replication management system for hdfs[END_REF].

In cloud platform, the resources are paid for the time they are used. This is what we call platform cost. Different platform cost models exist: per secondbased billing, per minute-based billing or per hour-based billing. The platform cost differs depending on the billing model. In the rest of this paper, we consider the per second-based billing model. Our goal is to minimize this platform cost. In other words, our goal is to find a trade-off between performance, and the number of servers used to reach this performance. Optimal performance can be reached by using as many servers and by creating as many replicas as there are requests. Our goal can be defined again as: get as close as possible to optimal performance by using the fewest possible servers.

Let denote tw the time window representing the billing model, and T w exec the number of time windows needed to complete all the requests. Let denote S i the number of active servers (servers that are powered on) during a time window i. Let define the platform cost to minimize:

M inimize : C = T wexec i=1 (S i × tw)
The platform cost can be minimized in two ways: reducing the number of servers in trough periods or reducing the number of time windows in peak periods.

Trough and peak periods

Trough periods are the periods in which all the requests can be completed in only one time window tw. Peak periods are the periods that need more than one time window tw to complete all the requests. Using the ERMS notation [START_REF] Cheng | Erms: An elastic replication management system for hdfs[END_REF], we define a cold server as a server that can complete the requests it received in one time window. And we define a hot server as a server that needs several time windows to complete its requests. To minimize the platform cost, we try to remove the cold servers, and relieve the hot servers by creating new replicas.

Replicas removal

The cold set and the hot set are respectively the set of cold servers and the set of hot servers. At trough periods, once the cold set is created, we try to remove the servers one by one. To maintain the data availability, we prevent from removing the last remaining data's replica.

Formally, let denote D a set of fixed-size t data and S a the set of active servers (servers that are powered up). Let denote r d the data d replication factor, and d i the i th replica of d. Let denote δ di s ∈ {0, 1} a distribution function that output 1 if replica i of data d is on server s, 0 otherwise. The data availability (1) challenge, called DAv, can be formalize as the following constraint:

∀d ∈ D, s∈Sa r d i=1 δ di s ≥ 1 (1)
Removing a server implies removing data's replica. But removing a data's replica can increase the number of requests on other servers that store the data, impacting on their performance to serve the requests. So, a server can be shut down only if it does not hold the last replica of a data, and if the servers impacted by this removal can complete their requests during the same number of time windows as before the removal.

Let denote Rold tw s and Rnew tw s the number of time windows needed for a server s to complete its requests respectively before and after the removal. The performance removal challenge (2), called PRC, can be formalized as the following constraint:

∀s ∈ S a , Rnew tw s ≤ Rold tw s (2)

Replicas creation

Creating replicas to relieve hot servers allows to distribute the data's requests across more replicas. So, a replica is created if the number of time windows needed by a hot server to complete its requests after the creation is less than before the creation. So, we ensure that adding a server always have a positive impact on the general performance of the platform. Let denote Aold tw s and Anew tw s the number of time windows needed for the hot server s to complete its requests respectively before and after the creation. The performance creation challenge (2), called PCC, can be formalize for each hot server s as the following constraint:

Anew tw s < Aold tw s (3)
New replicas must be stored either on an active server or on a new server (i.e. a server that was inactive before the replica creation). Storing a new replica on an active server impacts its performance. Storing a replica on an inactive server impacts the number of active servers. To use the fewest possible servers, we choose as a priority to create a new replica on an existing server. This must respect the following constraints: first, there is enough storage capacity on the destination server; second, the number of time windows needed by the destination server to complete its request after the creation is the same as before the creation. Otherwise, a server is activated and the replica is stored on this server. Furthermore, a new replica must be created by copying the data from an active server. This impacts the source server performance. Consequently, we choose to copy the data from the less loaded server holding it. This must respect the following constraint: the number of time windows needed by the source server to complete its request after the creation is the same as before the creation.

Formally, let denote T the storage capacity of the destination server. Using Aold tw s and Anew tw s for the destination server or the source server s, the performance source and destination challenge , called PSDC, can be formalized as the following constraints:

d∈D r d i=1 δ di s × t ≤ T (4)
Anew tw s ≤ Aold tw s

Removal and creation processes are described in Algorithm 1 and Algorithm 2.

Data popularity variations

Data popularity can change over time, and depends on the workload generated by data intensive applications. In some workloads, number of requests to the data can be constant, while in other workloads, these number can vary. These variations can be predictable or not. So, the replication factor of each data should be dynamically updated. This implies that replicas removal/creation process should be applied several times during the workloads execution. A workload execution can be split into several periods of requests. For each period tw i the data popularity pop twi d is computed and can be used to define the data popularity for the next periods. Consequently, we have defined 3 functions, that estimate the popularities of each data that are likely to be the data popularities for the next periods. The first one called current uses the data popularities measured during the current period. The second one called mean computes for each data the average popularity of all completed periods. Finally, the last function called median computes for each data the median popularity of all completed periods.

Algorithm 1 REMOVE SERVER

Evaluation

Our goal is to minimize the platform cost. Consequently, our solutions are analyzed comparing the platform cost but also comparing the platform cost components: the average access time and the number of used server per time window . Our solutions rely on the functions used to estimate the data popularities. These solutions are evaluated facing with data access patterns composed of different data popularities evolutions. Our solutions are also evaluated using workload traces provided by the Statistical Workload Injector for MapReduce (SWIM) [START_REF] Chen | The case for evaluating mapreduce performance using workload suites[END_REF].

Experimental setup

To evaluate our solutions, we simulate an homogeneous cloud platform using the SimGrid 3.11 framework [START_REF] Casanova | Versatile, scalable, and accurate simulation of distributed applications and platforms[END_REF], a "Versatile Simulation of Distributed Systems". This platform is composed of 60 storage servers, each offering 700GB of storage capacity. To simulate multiple requesters, we use one client linked to each storage server with a 2GB/s bandwidth. Two requests on two different servers use two distinct links. Two requests on two different servers are processed in parallel, but two requests on a single server are sequentially processed using a FIFO queue. Finally, we use 30 seconds time windows.

To compare our algorithms with the existing solutions, we have reproduced the HDFS behaviour. HDFS is one of the most popular DFS and is especially used with map-reduce by the data intensive applications. When using only one rack of servers, HDFS distributes the replicas among the servers in such a way that each server stores almost the same amount of data.

Data sets

To evaluate our algorithms, we built different patterns of data popularities. In the constant pattern all the data have the same popularity during the workload. In the increasing and decreasing patterns the data popularities respectively constantly increase/decrease during the workload. In the random pattern the data popularities are varying randomly. In the gaussian pattern, the data popularities are varying following a gaussian distribution along the time (starting low, quickly increasing to reach a peak, then quickly decreasing). To simulate a perfect periodical variation of requests number for each data, we define a sinusoidal pattern where data popularities gradually increase then gradually decrease and so on. We also defined a pattern with sinusoidal variation of the popularity of each data but with a different phase for each data (singap pattern). These data sets are composed of 50 data requested during 33 time windows and are shown in Figure 1. To confront our algorithms to real world, we have used the workload traces provided by the Statistical Workload Injector for MapReduce (SWIM) [START_REF] Chen | The case for evaluating mapreduce performance using workload suites[END_REF]. These workloads consist of a one month job trace of a Facebook production cluster (3000 machines). These workloads are composed of about 2,000 data, and are shown in Figure 2. To correspond to the other patterns and make easier the comparisons, the popularity of each data have been multiplied by 3 and the workload have been repeated as required to reach the same amount of time windows.

Data access pattern

We use the different patterns to first identify our best solution facing with different data popularities evolutions. The results are shown from Figure 3 to Figure 7. The current method is our best solution. It has a cost lower than or equal to the mean and median methods and provides lower or equal data access time for all the patterns except the gaussian one. It relies on the current time period to estimate the future data popularities and is adapted to a gradual evolution. It reduces the platform cost by removing servers in trough periods and by reducing data access time in peak periods. But, it is vulnerable when this evolution quickly increases or decreases (as our gaussian pattern Figure 6) because it acts with one period delay. In that case, the mean and median methods are more adapted. They slowly reduce or increase the number of servers as seen in the decreasing pattern (Figure 4) and the increasing pattern (Figure 5). They are also more adapted to periodic patterns (Figure 7).

Then, we compare our current method to the HDFS that has similar results: the one which uses 20 servers. Two cases can be noted. First, our current method has similar cost, between -2% and +3%, and better data access time, up to -99% (constant and sinus gap). It also has better cost, up to 20%, and either similar data access time, which represents about 1/6 of the time window (sinus and beginning of increasing), or better data access time, up to 99% (decreasing and end of increasing). Second, facing with the gaussian pattern, the current method has better cost, about 50%, but has higher data access time in peak periods. The first patterns gradually evolve, and as seen before, our current method is able to quickly remove and add servers facing with this kind of patterns. With the gaussian pattern, data popularities quickly increase and quickly decrease, and as seen before, the current method is not adapted to this kind of pattern. The constant and sinus gap patterns provide similar results. Consequently, only the constant results are shown. About the random pattern, results are similar whatever the used solution. So, we do not show the results we obtained.

These results show that in trough periods the current solution is able to reduce the platform cost by removing servers without impacting data access time. In peak periods, this method is able to reduce data access time by adding servers without impacting the platform cost. However, in case of patterns with which data popularities quickly increase and then quickly decrease, the current method is able to reduce the platform cost but data access times are impacted. With this kind of patterns, the mean and median method are more adapted. than HDFS, about -50%. The current and the mean methods have data access time similar to HDFS, whereas the median method have higher data access time. These workloads have few requests per time window, it explains the low data access time. These results confirm that in trough periods our solutions can reduce the platform cost by removing servers without impacting data access time.

Conclusion and future works

Deploying a DFS on a cloud platform can provide high performance computing applications with quick data access. Extending cloud elasticity at a storage level is still a challenge: powering down or up resources in trough or peak periods, while maintaining high I/O performance is a complex task.

In this paper, we show that dynamically adapting the replication factor to the data popularities by removing or adding replicas and servers allows to obtain either better performance (up to 99%) while keeping cost similar, or obtain better cost (up to 50%) while keeping performance similar. The platform cost is reduced in trough periods whereas performance are improved in peak periods. We also show that the method used to estimate the data popularities evolution, are impacted by the kind of evolution. A method based on the current popularities to estimate the future popularities is efficient in case of gradual evolution while methods based on the mean or median popularities are more adapted with patterns where data popularities quickly increase and then decrease.

For our future works, we plan to take into account the agility of the platform (i.e. its capabilities to react quickly to the changes). In our current model, we did not take into account the time needed to start a new instance (considered negligible comparing to the time to access the data) of storage server and the possibility to stop a server without deleting all the data it stored. Indeed, the public cloud platforms generally offer the possibility to attach a persistent block storage image to a running instance. As the cost to store data on such a service is a fraction of the cost of a running instance, it should be possible to increase the agility and to reduce the data transfers when starting a new server without impacting negatively the total cost.

Fig. 1 :Fig. 2 :

 12 Fig. 1: Total number of requests occurring at each time window for different pattern

Fig. 3 :Fig. 4 :Fig. 5 :Fig. 6 :Fig. 7 :

 34567 Fig. 3: Platform cost, number of used servers and average time for constant

Fig. 8 :

 8 Fig. 8: Platform cost, number of used servers and average time for fb1