Affoua Therese Aby
email: aby@esiee-amiens.fr

Marie-Françoise Servajean
email: m-francoise.servajean@uca.fr

Michel Misson
email: michel.misson@uca.fr

IMPACT OF THE SIMULATION PARAMETERS ON THE QUANTITATIVE RESULTS OF PROTOCOLS FOR WSNS

Keywords: WSNs, QoS, performance evaluation, radio propagation model, simulation parameters impact

Many protocols for wireless sensor networks are proposed in the literature. In most of this work, comparisons are made with existing protocols to show that the proposed protocol provides better overall performance without precise specifications of the simulation environment. In this paper we show that for a given propagation model, the value of its main parameters retained in the simulation process has very significant effects on the quantitative results. To do this, we use an asynchronous MAC protocol that we proposed which was compared with the reference MAC protocol specified in the standard IEEE 802.15.4 in beacon enabled mode. We use a realistic propagation model like log-Shadowing and we modify the parameters of this model. In this contribution, we also vary the capture threshold. We intuitively known that the asynchronous MAC protocol will ensure a better overall performance than the standard, we will try to show the diversity of results by intensive simulations. To the best of our knowledge, there are existing studies that show the impact of different propagation models on simulation results. However, no studies have shown this impact with such an important level of detail. From this study we estimate that when two communication protocols are compared, it is important to associate the performance curves with the precise and detailed conditions used for the simulation and to assess the global influence. According to this influence, a vigilance can be reported on the accuracy of results.

I. INTRODUCTION

Wireless sensor networks are a promising solution for the implementation of environmental monitoring applications such as the rapid detection of disasters as forest fires and floods [START_REF] Yu | Real-time forest fire detection with wireless sensor networks[END_REF], [START_REF] Hefeeda | Wireless sensor networks for early detection of forest fires[END_REF], or the understanding of natural phenomena as volcano eruptions [START_REF] Lee | Rfms: Real-time flood monitoring system with wireless sensor networks[END_REF] and landslides [START_REF] Ramesh | Wireless sensor network for disaster monitoring[END_REF]. That explains the many research studies carried out in this field. In most of these studies, comparisons are made with existing protocols to show that the proposed protocol provides overall better performance. In this paper we show that we must step back from the quantitative simulation results when comparing communication protocols. We used energy-saving MAC protocols for wireless sensor networks dedicated to environmental monitoring as an example. These MAC protocols are based on sequences of active periods (during which the radio module is on) and sleep periods (during which it is off) called duty cycle. The duty cycle represents the proportion of the active period over the total duration of the cycle. The lower the value of the node duty cycle, the more this node saves energy. At the moment, the design of MAC protocols with very low duty cycles are still a challenge. Many MAC protocols based on the duty cycle mechanism are proposed in the literature and compared with other protocols. They can be classified into two main categories: synchronous and asynchronous duty cycle MAC protocols. In synchronous duty cycle MAC protocols the nodes agree on a common schedule for their activity and sleep periods. This is the case of the standard IEEE 802.15.4 [START_REF]IEEE standard for local and metropolitan area networks -part 15.4: Low-rate wireless personal area networks (LR-WPANs)[END_REF] in beacon enabled mode, LO-MAC [START_REF] Nguyen | Low overhead MAC protocol for low data rate wireless sensor networks[END_REF], D-MAC [START_REF] Lu | An adaptive energy-efficient and low-latency MAC for tree-based data gathering in sensor networks[END_REF], and TreeMAC [START_REF] Song | TreeMAC: Localized TDMA protocol for real-time high-data-rate sensor networks[END_REF]. In asynchronous duty cycle MAC protocols, nodes do not have a common calendar for their activity and sleep periods. This is the case of X-MAC [START_REF] Buettner | X-MAC: A short preamble MAC protocol for duty-cycled wireless sensor networks[END_REF], OSX-MAC [START_REF] Kim | On-demand synchronous x-mac protocol[END_REF], RI-MAC [START_REF] Sun | RI-MAC: a receiverinitiated asynchronous duty cycle MAC protocol for dynamic traffic loads in wireless sensor networks[END_REF], HKMAC [START_REF] Tang | Low-latency asynchronous duty-cycle MAC protocol for burst traffic in wireless sensor networks[END_REF], AaaMAC [START_REF] Aby | Study of blind rendezvous in low power wireless sensor networks[END_REF] and SlackMAC [START_REF] Aby | Slack-MAC: Adaptive MAC protocol for low duty-cycle wireless sensor networks[END_REF], [START_REF]History-based MAC protocol for low duty-cycle wireless sensor networks: the Slack-MAC protocol[END_REF]. In these protocols quantitative results of simulations comparing them with other existing protocols are given. However, the comparison conditions are not fully defined. The detail level used in the comparison of simulation results is much more specific than the detail level used to describe the simulation process. We show in this paper that it is important and even necessary to associate the performance results with the precise and detailed conditions used for the simulation. Few articles specify how the topologies used for the simulations are generated and how the radio links range is regulated. Most commonly, the propagation model is evoked but the justification of the values of its parameters is often missing. Likewise, the transmission power, the sensitivity and the capture threshold are sometimes missing. This makes the simulation reproducibility quite difficult. To the best of our knowledge, there are existing studies that show the impact of different propagation models on simulation results as in [START_REF] Stepanov | On the impact of radio propagation models on manet simulation results[END_REF] and [START_REF] Kanthe | Effects of propagation models on aodv in mobile ad-hoc networks[END_REF]. However, no studies have shown this impact with such an important level of detail. We show, for instance that the value of the capture threshold and the main parameters (path loss exponent and the standard deviation) of a realistic propagation model as log-shadowing have significant effects on the quantitative results. To do this, we use an asynchronous MAC protocol that we proposed SlackMAC [START_REF] Aby | Slack-MAC: Adaptive MAC protocol for low duty-cycle wireless sensor networks[END_REF], [START_REF]History-based MAC protocol for low duty-cycle wireless sensor networks: the Slack-MAC protocol[END_REF] which was compared with the reference synchronous MAC protocol specified in the standard IEEE 802.15.4 [START_REF]IEEE standard for local and metropolitan area networks -part 15.4: Low-rate wireless personal area networks (LR-WPANs)[END_REF] in beacon enabled mode. This choice is justified by the fact that we intuitively know the result of this comparison, we will try to show the diversity of results by intensive simulations. The remainder of this paper is organized as follows. In section II, we perform a comparative study of a synchronous and asynchronous MAC protocol with precise and detailed conditions. In section III, we show simulation results from this comparative study. Finally, we conclude our work in the section IV.

II. COMPARATIVE STUDY

In this section we first describe the operating mechanism of the reference synchronous MAC protocol described in the standard IEEE 802.15.4 [START_REF]IEEE standard for local and metropolitan area networks -part 15.4: Low-rate wireless personal area networks (LR-WPANs)[END_REF] in beacon enabled mode and the asynchronous MAC protocol SlackMAC [START_REF] Aby | Slack-MAC: Adaptive MAC protocol for low duty-cycle wireless sensor networks[END_REF], [START_REF]History-based MAC protocol for low duty-cycle wireless sensor networks: the Slack-MAC protocol[END_REF]. Then we give the technical details of the implementation of our comparative study.

A. Description of the operating mechanism of IEEE 802.15.4 and SlackMAC

In the beacon enabled mode of the standard IEEE 802.15.4 the medium is accessed using the slotted CSMA/CA (Carrier-Sense Multiple Access with Collision Avoidance) algorithm. All nodes wake up periodically together and share a common activity throughout the SD (Superframe Duration) period and change to sleep mode the rest of the BI (Beacon Interval) period. Figure 2 shows an example of the activity and sleep mechanism in the standard IEEE 802.15.4 with a duty cycle of 10% ( S D BI × 100) for four nodes (n 1 , n 2 , n 3 and n 4 ) in range. It can be seen that all the activity of the nodes is concentrated on the period SD. This reduces the communication time given to each node and increases the risk of collision depending on the number of nodes in competition to access the medium.

In SlackMAC, the medium is also accessed using the slotted CSMA/CA algorithm. Unlike the standard in SlackMAC, initially all nodes choose their activation times uniformly at random in the cycle. Figure 2 be distributed over the whole cycle unlike the standard. Indeed, on average there are few active nodes at the same time, which reduces the risk of collision and allows a higher communication time per nodes than the standard for the same duty cycle as shown in [START_REF]History-based MAC protocol for low duty-cycle wireless sensor networks: the Slack-MAC protocol[END_REF]. According to such conditions, it is intuitively known that SlackMAC will ensure overall better performance than the standard.

However, what we are trying to show is the diversity of the quantitative values of these performance sets according to the chosen simulation parameters.

B. Technical details on the comparison implementation

In addition to the type of simulation model and its associated parameters, it is important to give the rules that allowed to generate the topology used for the simulation. In this paper and by way of example, the generated reference topologies have the following particularity:

• they are composed of N nodes; • all the nodes of this kind of topology have at least one neighbor which is located less than 30 meters away • all the neighbors of a node are located at least one meter away from one another. Once a reference topology is generated it is also important to specify the transmission power used. This one combined with the receiver sensitivity parameter will give us a notion of range and with the interference threshold parameter will give the notion of the size of interference zone (this particular point is out of the scoop of this paper). The range is defined from the set of points around the transmitter such as:

Pr = Sensitivit y T hreshold = P min (1)
The received power (Pr) depends on the transmission power, the distance that the signal travels and the transmission medium role which will be represented by the retained simulation model. The sensitivity threshold depends on the characteristics of receiver node radio transceiver. In our contribution this value is set to -85 dBm.

The realistic log-shadowing propagation model is often used in the literature. It is possible to add a random component to the path loss in order to take into account the diversity of measurements for the same path length. The log normal shadowing path loss model is formally expressed as follow:

PL dB = PL dB (d 0 ) + 10n log 10 d d 0 + X σ (2)
Where d 0 is the reference distance, n is the path loss exponent, PL dB (d 0 ) is the path loss at the reference distance d 0 and X σ a rule that produces the random correction. This random correction can increase or decrease the radio range. It is produced from a general Gaussian distribution of zero mean and standard deviation which is according to the diversity of measurements we want to represent (a few dB in general). When a random correction is associated to a propagation model, it is necessary to agree on what becomes the range. This raises the following question: for a given propagation conditions (represented by the model and its parameters) how does one adjust the transmission power so that a radio link between a transmitter and a receiver located at the range limit remains operational?

Maintaining a radio link always operational means that regardless of the value of random correction, the received power can exceed the sensitivity threshold. To simplify, it's necessary to consider that the most negative random corrective values ensure that the received power is equal to the sensitivity threshold. For a Gaussian distribution, this greatest negative value can be defined using a confidence interval of 95% (99.997%, respectively). This involves to take a safety of 2 standard deviations (3, respectively) relative to the mean value. For a low standard deviation of 3dB this leads to adding 6dBm (9dBm, respectively) to the transmission power. This increase leads to a power waste and a congestion which affects transmitter carrier spatial reuse. The notion of outage probability was introduced to make a good trade-off based on the distribution method used. A link is operational if the receiver receives statistically X% times of the cases with enough power (greater than the sensitivity threshold). (1-X%) represents the probability of failure. For these cases, the LLC layer of the WSNs will make the retransmission, thus the probability of nonreception will then be (1 -X%) 2 . Having an operational link in 95% of the cases leads to admit that 5% of the Gauss curve surface allows a received power below the threshold sensitivity. The use of the distribution function attached to a reduced centered normal law, it is possible to determine the minimum necessary power that allows the reception threshold to be reached or exceeded in 95% of the cases.

We remain in this contribution at the level of principles. The justification of the computations needed to evaluate the transmission power is given in the literature on outage probability as in [START_REF] Mezghanni | Performance study of ieee 802.15. 4/4g waveforms over the mobile underground mine radio-channel[END_REF] [START_REF] Simon | Outage performance of multiuser communication systems[END_REF].

These principles can be summarized as follows.

Let Q(Z ) the probability that a random variable X obtains a value of Q greater than Z, thus 1 -Q(Z ) is the probability that Q be less than Z.

Consider that: Z = P min -P t -P L dB (d) σ

(3) Where σ is the standard deviation.

(1) =⇒ p(P r (d)

≤ P min ) = 1 -Q(Z ) (4)
We thus obtained:

Q(Z ) = 1 -p(P r (d) ≤ P min ) (5)
There is a K such as:

Q(K ) = 1 -p(P r (d) ≤ P min ) (6)
(5) and ( 6) =⇒ Z = K ie, K = P min -P t -P L dB (d) σ whence, P t = P min -PL dB (d) -K * σ [START_REF] Lu | An adaptive energy-efficient and low-latency MAC for tree-based data gathering in sensor networks[END_REF] This relation [START_REF] Lu | An adaptive energy-efficient and low-latency MAC for tree-based data gathering in sensor networks[END_REF] allowed us to complete the table II. Moreover, the value set for the capture threshold, which represents the minimum power ratio in dB which enables the receiver in case of simultaneous reception to decode the strongest signal correctly, is sometimes missing. In this paper we also evaluate the impact of this parameter.

III. COMPARISON RESULTS

We carried out several simulations to show the results of this comparative study. We first describe the simulation environment and then compare the two MAC protocols in three different scenarios.

A. Simulation parameters

Our simulations are performed using the network simulator NS-2 [START_REF]Network simulator 2[END_REF]. Global simulation parameters are given in Table I. We use 10 random topologies of 100 nodes, with a maximum hops of 7. We generate a convergecast communication (from the nodes to the sink), for 30 source nodes located randomly in the network. These source nodes perform periodic measurements and route them via other nodes to the sink located at one corner of the network. Nodes have a duty-cycle of 1% and the global cycle is 5 s (that is, nodes are active during A=50 ms every C=5 s). The same gradient-based routing protocol is used to route packets hop by hop towards the sink for both MAC protocols. All presented results are averaged over 10 repetitions per topology of the 10 topologies.

B. Simulation results

We compare the standard IEEE 802.15.4 [START_REF]IEEE standard for local and metropolitan area networks -part 15.4: Low-rate wireless personal area networks (LR-WPANs)[END_REF] in beacon enabled mode which is the main synchronous duty cycle MAC protocol with the asynchronous MAC protocol SlackMAC [START_REF] Aby | Slack-MAC: Adaptive MAC protocol for low duty-cycle wireless sensor networks[END_REF], [START_REF]History-based MAC protocol for low duty-cycle wireless sensor networks: the Slack-MAC protocol[END_REF] in three different scenarios. In the first scenario, we evaluate the impact of the capture threshold, then in the second one the shadowing path loss exponent impact and finally the impact of shadowing standard deviation. We opted for a simulation process driven by a constant radio range (not by a constant transmission power) to ensure the maintenance of the links. Thus, for a given value of shadowing path loss exponent (which is 2.0, 2.5, or 3.0) and a given value of shadowing standard deviation (which varies from 2 dB to 8 dB), we determined the associated transmission power using the outage probability method described in section II-B. Table II, contains the various parameters with the associated transmission power (in dBm) to allow a stability of the radio links ensuring 95% of the reception between two nodes with transmission range of 30 m. 1) Scenario 1: Capture threshold impact: In this scenario we vary the value of capture threshold from 2 dB to 10 dB and set the shadowing standard deviation to 4 dB then we perform the tests for a shadowing path loss exponent of 2.0 and 3.0. Figures 3 and4 show the delivery ratio and the endto-end delay of data frames, respectively, as a function of the capture threshold (from 2 dB to 10 dB) with shadowing standard deviation of 4 for IEEE 802.15.4 and SlackMAC, when shadowing path loss exponent equal to 2.0 and 3.0.

For IEEE 802.15.4, the delivery ratio decreases from 69% to almost 51% for a shadowing path loss exponent of 2.0 and decreases from 73% to almost 56% for a shadowing path loss exponent of 3.0. The average delay remains around 8 s for a shadowing path loss exponent of 2.0 and between 11 s and 12 s with a shadowing path loss exponent of 3.0.

For SlackMAC, the delivery ratio is 99.9% both for a shadowing path loss exponent of 2.0 and 3.0 regardless of the capture threshold. The average delay remains around 6 s for a shadowing path loss exponent of 2.0 and between 20 s and 21 s with a shadowing path loss exponent of 3.0.

The average delay varies little with the capture threshold for a given shadowing path loss exponent value with both protocols. The high delay in both protocols when the shadowing path loss exponent is equal to 3.0 is explained by the fact that when the value of shadowing path loss exponent increases, the interference area is reduced and the network becomes less meshed. This will require more hops to route data toward the sink, increasing the average end-to-end delay. Although the results of SlackMAC in terms of delivery ratio are generally better than those of the standard, these results can be compared with a difference of nearly 20% according to the capture threshold value set. The results in terms of delivery ratio of the standard are better when the capture threshold is low and less important when this value is high, this is due to the collision rates induced by a high capture threshold. This parameter has shown an important impact on the results of one of the two protocols, whereas its value is almost never mentioned in the simulations carried out comparing protocols in the literature.

2) Scenario 2: Shadowing path loss exponent impact: In this scenario we vary the value of shadowing path loss exponent from 2.0 to 3.0 and the shadowing standard deviation still set to 4 dB then we perform the tests for a the capture threshold of 2 dB and 10 dB. of the shadowing path loss exponent, with shadowing standard deviation of 4 dB for IEEE 802.15.4 and SlackMAC, when the capture threshold equal to 2 dBm and 10 dBm.

For IEEE 802.15.4, the delivery ratio increases from 69% to 73% for a capture threshold of 2 dB and increases from almost 51% to 56% with a capture threshold of 10 dB. The average delay increases from 8 s to 11 s for a capture threshold of 2 dB and from 8 s to 12 s with a capture threshold of 10 dB.

For SlackMAC, the delivery ratio decreases from 99.9% to 99.5% for a capture threshold of 2 dB and increases from 99.9% to almost 99.5% with a capture threshold of 10 dB. The average delay increases from 6 s to 20 s for a capture threshold of 2 dB and from 6 s to 21 s with a capture threshold of 10 dB.

We note that, for both protocols the delivery ratio varies little with the shadowing path loss exponent. For the standard, the delivery ratio remains higher for a low capture threshold than when it's high. The average delay increases for both protocols according to the shadowing path loss exponent, as in previous scenario. This is also due to the fact that when the value of the shadowing path loss exponent increases, the network is less meshed and requires more hops to route data toward the sink. There is also a reversal of performance in terms of average delay beyond the shadowing path loss exponent of 2.25 between the two protocols, the delay of the standard is better than in SlackMAC.

3) Scenario 3: Shadowing standard deviation impact: In this scenario we vary the value of the shadowing standard deviation from 2 dB to 8 dB and set the shadowing path loss exponent to 2.5 then we perform the tests for a the capture threshold of 2 dB and 10 dB.

Figures 7 and8 show the delivery ratio and the end- to-end delay of data frames, respectively, as a function of the standard deviation, with shadowing path loss exponent of 2.5 for IEEE 802.15.4 and SlackMAC, when the capture threshold equal to 2 dB and 10 dB.

For IEEE 802.15.4, the delivery ratio increases from 69% to 71% for a capture threshold of 2 dB and increases from 51% to almost 58% with a capture threshold of 10 dB. The average delay decreases from 12 s to 6 s for a capture threshold of 2 dB and from 12 s to 7 s with a capture threshold of 10 dB.

For SlackMAC, the delivery ratio increases from 99.4% to 99.9% for a capture threshold of 2 dB and increases from 99.4% to 99.9% with a capture threshold of 10 dB. The average delay decreases from 27 s to almost 4 s for a capture threshold of 2 dB and from 24 s to almost 4 s with a capture threshold of 10 dB.

We observe that, for both protocols the delivery ratio varies little with the shadowing standard deviation. For the standard, the delivery ratio remains higher (with a difference of almost 20%) when the capture threshold is low as in the scenario 2. Unlike scenario 2, here the average delay decreases for both protocols as a function of the shadowing standard deviation. This is due to the fact that when the value of the shadowing standard deviation is large, the fugitive existence of a link beyond the reference area is more probable, which reduce virtually the number of hops to route data toward the sink. As in scenario 2, there is also a reversal of performance of the two protocols when the shadowing standard deviation is greater than 5, the delay of SlackMAC is better than in the standard.

Through the results of scenarios 1, 2 and 3, it can be noted that, if we just allocate values to the simulation parameters, we can have a limited analysis. For example, if the value of the shadowing path loss exponent is set to 2.5, the standard deviation to 4 dB and the capture threshold to 10 dB, SlackMAC has a delivery ratio of 99.85% and the average delay is 10.6 seconds. While for the same parameters the standard has a delivery ratio of 52.32% and an average delay of 9.08 seconds. It will be concluded that the performance of SlackMAC is globally better compared to the standard. However, with another set of parameters as the value of the shadowing path loss exponent is 3.0, the standard deviation still set at 4 dB and the capture threshold set at 2 dB, the standard has a delivery ratio of 73.17% and an average delay of 11.25 seconds. While for the same parameters, SlackMAC keeps almost the same delivery ratio (ie 99.5%) and an average delay of 20.6 seconds. We observe the large differences in performance as a function of a simple set of parameters. While very often in the studies which are carried out comparing protocols proposed to those of the existing it is found that:

• not only, the main simulation parameters we have specified in this paper are not defined enough; • but the variance between the performances are often less important than those shown in this paper.

IV. CONCLUSION

In this work, we carried out a comparative study of two protocols according to different simulation parameters to show the need to clearly specify the simulation environment when comparing protocols. We used an asynchronous MAC protocol with the reference MAC protocol specified in the standard IEEE 802.15.4 in beacon enabled mode. We knew intuitively that the asynchronous MAC protocol would provide better overall performance than the standard. However, we showed the diversity of the quantitative values of the performances according to the chosen simulation parameters. We evaluated the impact of different parameters such as shadowing path loss exponent, shadowing standard deviation and capture threshold. In each scenario, we modified one parameter and fixed the others. The results show that for different values given to the main parameters of the shadowing propagation model and also to the capture threshold, there is a significant impact on simulation results. From this study we estimate that when two communication protocols are compared, it would be more insightful to specify the parameters used and to justify the choice of their value. It is imperative to reconcile the results with the parameters used in the simulation in order to judge their accuracy and also to allow their reproducibility. In this study we considered a simulation process for topologies using constant length of radio links. We intend to present a complementary analysis to this work which will be based on a simulation process with constant range vs constant transmission power.

4 Fig. 3 .Fig. 4 .

 434 Fig. 3. Delivery rate as a function of the capture threshold with shadowing standard deviation of 4 dB for IEEE 802.15.4 and SlackMAC, when shadowing path loss exponent equal to 2.0 and 3.0.

Fig. 5 .

 5 Fig. 5. Delivery rate as a function of the shadowing path loss exponent, with shadowing standard deviation of 4 dB for IEEE 802.15.4 and SlackMAC, when the capture threshold equal to 2 dB and 10 dB.

Figures 5 Fig. 6 .

 56 Figures5 and 6show the delivery ratio and the endto-end delay of data frames, respectively, as a function

Fig. 7 .

 7 Fig. 7. Delivery rate as a function of the shadowing standard deviation, with shadowing path loss exponent of 2.5 for IEEE 802.15.4 and SlackMAC, when the capture threshold equal to 2 dB and 10 dB.

Fig. 8 .

 8 Fig. 8. Average delay as a function of the shadowing standard deviation, with shadowing path loss exponent of 2.5 for IEEE 802.15.4 and SlackMAC, when the capture threshold equal to 2 dB and 10 dB.


Julio C S Anjos
email: jcsanjos@inf.ufrgs.br

Kassiano J Matteussi
email: kjmatteussi@inf.ufrgs.br

Paulo R R De Souza

Claudio F R Geyer
email: geyer@inf.ufrgs.br

Alexandre S Veith
email: alexandre.veith@ens-lyon.fr

Gilles Fedak
email: gilles.fedak@inria.fr

Jorge Luis

Victória Barbosa
email: jbarbosa@unisinos.br

Enabling Strategies for Big Data Analytics in Hybrid Infrastructures

Keywords: Big Data, MapReduce, Hybrid Infrastructures, Distributed System, Data-intensive Computing

A huge volume of data is produced every day by social networks (e.g. Facebook, Instagram, Whatsapp, etc.), sensors, mobile devices and other applications. Although the Cloud computing scenario has grown rapidly in recent years, it still suffers from a lack of the kind of standardization that involves the resource management for Big Data applications, such as the case of MapReduce. In this context, the users face a big challenge in attempting to understand the requirements of the application and how to consolidate the resources properly. This scenario raises significant challenges in the different areas: systems, infrastructure, platforms as well as providing several research opportunities in Big Data Analytics. This work proposes the use of hybrid infrastructures such as Cloud and Volunteer Computing for Big Data processing and analysis. In addition, it provides a data distribution model that improves the resource management of Big Data applications in hybrid infrastructures. The results indicate the feasibility of hybrid infrastructures since it supports the reproducibility and predictability of Big Data processing by low and high-scale simulation within Hybrid infrastructures.

I. INTRODUCTION

Mankind is producing an ever-increasing amount of data. According to the National Security Agency (NSA) 1 , by 2020 there will be around 40 Zettabytes (40,000,000 Petabytes) of data that will require processing of some sort. This volume of data requires processing capabilities beyond those that the current IT infrastructure can provide. In addition, the data input can originate from different sources, such as social interaction, scientific research, business activities and government decisions [START_REF] Chen | Data-intensive applications, challenges, techniques and technologies: A survey on big data[END_REF].

Although, Cloud Computing (Cloud) has grown rapidly in recent years, it still suffers from a lack of standardization and the availability of management resources [START_REF] Toosi | Interconnected cloud computing environments: Challenges, taxonomy, and survey[END_REF]. Private clouds are used exclusively by a single organization, that is able to keep careful control of its performance, reliability and security, but might have low scalability for Big Data processing 1 The Next Wave, Vol. 20, No. 4, November 2014 requirements. Public clouds, on the other hand, have an infrastructure that is based on a particular Service Level Agreement which provides services and quality assurance requirements with resources regarding processing, storage and bandwidth. The Cloud Service Provider (CSP) manages its own physical resources. This interface might vary depending on the provider, but maintains properties like elasticity, isolation and flexibility [START_REF] Rista | Proceedings of the International Conference on High Performance Computing Simulation (HPCS), title=Improving the Network of a Container-Based Cloud Environment for Hadoop Systems[END_REF].

MapReduce (MR) [START_REF] Dean | MapReduce -a flexible data processing tool[END_REF] is a programming framework proposed by Google that is currently adopted by many large companies and has been employed as a successful solution for data processing and analysis. The most popular open-source implementation of MR is the Hadoop [START_REF] White | Hadoop -The Definitive Guide[END_REF], [START_REF] Meddah | Parallel distributed patterns mining using hadoop mapreduce framework[END_REF], which is used for deploying Hadoop clusters as the basis for several Big Data analytics.

The emerging systems are highly heterogeneous environments with variable structures, where resources can be added or removed if necessary [START_REF] Vasile | Resource-aware hybrid scheduling algorithm in heterogeneous distributed computing[END_REF]. The hybrid infrastructure in this work can be defined as a mix of public or private Cloud with Volunteer Computing (VC), similar to the environment explored by [START_REF] Tang | HybridMR: a new approach for hybrid MapReduce combining desktop grid and cloud infrastructures[END_REF]. This work proposes the use of hybrid infrastructures such as Cloud and Volunteer Computing for Big Data processing and analysis. In addition, the work provides a data distribution model to improve resource management for Big Data applications in hybrid infrastructures. Further, a new platform for the hybrid infrastructures, proposed in previous work [START_REF] Anjos | SMART: An Application Framework for Real Time Big Data Analysis on Heterogeneous Cloud Environments[END_REF], called SMART, enables the deployment of VC and Cloud. Besides, a simulator called BIGhybrid [START_REF] Anjos | BIGhybrid: a simulator for mapreduce applications in hybrid distributed infrastructures validated with the grid5000 experimental platform[END_REF] was designed by the features required for this infrastructure. It can be considered as a toolkit for Big Data analytics. Hence, a set of strategies will be defined and evaluated for the use of VC and Cloud in hybrid infrastructures.

This work is structured as follows. Section II carries out a review of related works. Section III describes the proposed model and its structure. In addition, the strategies for data and task distribution are discussed. Section IV describes the methodology, the experiments and the obtained results. The conclusions and suggetions for future work are outlined in Section V.

II. RELATED WORK

This section aims to examine the infrastructure initiatives for implementing Big Data in homogeneous and heterogeneous environments. Some of these initiatives lead to hybrid infrastructures in private and public Cloud. However, it is very unusual to find an evaluation of hybrid environments which include a Volunteer Computing platform, in the context to Big Data and particularly that of Geo-distributed environments. Thus, the strategies adopted for different Big Data platforms are summarized and evaluated regarding the related work, which is closer to the presented hybrid model.

A. MapReduce in a Heterogeneous Environment

The MapReduce model was originally conceived for large homogeneous cluster environments. As a result, some simplifications were made to the model aiming to optimizing the task distribution. However, these adjusts may entail system degradation in heterogeneous environments. The work of of Zaharia et al. [START_REF] Zaharia | Improving MapReduce performance in heterogeneous environments[END_REF] was the first study to detect these problems. Their study points out that there are some concerns over the changes of the MapReduce model since it may lead to an excessive number of speculative tasks. To overcome this problem, the authors proposed LATE (Longest Approximate Time to End), which is a new task scheduler. Although LATE does not completely avoid speculative tasks, it considerably reduces performance degradation in heterogeneous environments.

Some works focus on adapting MapReduce algorithms to volatile and heterogeneous environments. One of the first proposals was the MOON project (MapReduce On Opportunistic eNvironments) [START_REF] Lin | MOON: MapReduce on opportunistic environments[END_REF], a hybrid model for voluntary computing which assumes that the system consists of volatile and reliable non-volatile machines. The aim of the authors was to investigate whether there was a hybrid design which would be able to provide a high degree of data availability in volatile environments. Their solution involves applying the LATE algorithm and loss of data from the volatile machines is overcome by replicating data in reliable machines.

BitDew-MapReduce (BitDew-MR) [START_REF] Lu | Assessing MapReduce for internet computing: A comparison of Hadoop and BitDew-MapReduce[END_REF] is a MapReduce implementation adapted to a volatile environment, that has already been combined with Cloud like a hybrid infrastructure to improve performance and reduce costs through the bag-oftasks application. The fault-tolerance system needs a synchronization schema, as pointed out by [START_REF] Tang | Analysis of data reliability tradeoffs in hybrid distributed storage systems[END_REF], where transient and permanent failures can be handled. A barrier-free computation is implemented to mitigate the host churn behavior [START_REF] Lu | Assessing MapReduce for internet computing: A comparison of Hadoop and BitDew-MapReduce[END_REF].

MRA++ (MapReduce with Adapted Algorithms for Heterogeneous Environments) adapted MapReduce algorithms to heterogeneous environments with the aim of addressing the main problems originating from the simplification of the MapReduce model [START_REF] Anjos | MRA++: Scheduling and data placement on MapReduce for heterogeneous environments[END_REF]. Thus, the developed algorithms allow the use of data-intensive applications in large-scale environments through the use of the Internet. The strategy adopted in this work is to examine three areas of the MapReduce implementation: grouping, data distribution and task scheduling.

The data is distributed in accordance with the heterogeneity of the machines to prevent a large increase of execution time. The machines are grouped according to their computational capabilities.

B. MapReduce across Multiple Clouds

Organizations are increasingly relying on an infrastructure from multiple providers as a means of increasing fault tolerance and avoiding provider lock-in. When multiple Clouds (hereafter also described as Multi-Cloud) are involved, the application deployment becomes complex. A Multi-Cloud infrastructure contains various configuration choices and can change its requirements and workloads dynamically at the time of execution. In this context, multiple cloud infrastructures, like clouds in heterogeneous environments, need different levels of configuration, such as the operational system, service containers and configuration capabilities [START_REF] Le | SALSA: A framework for dynamic configuration of cloud services[END_REF].

The study of Tudoran et al. [START_REF] Tudoran | Bridging data in the clouds: An environment-aware system for geographically distributed data transfers[END_REF] argues that there are two methods for modeling complex infrastructures. The analytical model uses low-level details like workloads and characterizes their ability to predict performance. The sampling method as an active approach which does not require any previous knowledge of the infrastructure of the users in public clouds. Because of this, the authors introduce the GEO-DMS a samplebased category for modeling that monitors the environment through agents. The model registers the correlation between performance (execution time) and cost-effectiveness (finance), and imposes budgetary constraints in the interests of safety.

The system used for the geo-distributed data analytics in the work of Ji and Li [START_REF] Ji | Wide area analytics for geographically distributed datacenters[END_REF] involves adopting a centralized approach where a significant amount of bandwidth is consumed, which leads to a poor performance. In addition, this approach must be subject to new constraints, such as concerns about privacy. The distributed execution is a strategy that transfers computations to local data centers and then aggregates the intermediate results for further processing. Thus, this execution method can lead to low latency since it involves a distributed execution, although several approaches fail to take account of the constraints in data movement.

C. Big Data in Hybrid Systems

In a Hybrid Cloud environment, the data centers are interconnected by means of slow links. The data is moved from the private to public Cloud when a new VM allocation is required to improve a task performance. The data locality and data movement are a challenge for accelerating iterative MapReduce in Hybrid Clouds because iterative applications reuse invariant input data [START_REF] Chacko | Improving execution speed of incremental runs of mapreduce using provenance[END_REF]. Furthermore, since the extra resources represent an additional cost for data movement, the trade-off between performance gains and benefits must be evaluated.

These issues are evaluated in the work by Clement et al. [START_REF] Clemente-Castelló | Enabling big data analytics in the hybrid cloud using iterative MapReduce[END_REF] which addresses iterative MapReduce problems in a Hybrid IaaS Cloud environment. The authors argue that it is essential to improve data locality in a hybrid Cloud environment. The aim of the strategy is to extend the original fault-tolerance mechanism of HDFS and deploy data replicas from an onpremise VM in a private Cloud to another allocated offpremise VM in a public Cloud as if it were an external rack in the HDFS.

In the work of Tang et al. [START_REF] Tang | HybridMR: a new approach for hybrid MapReduce combining desktop grid and cloud infrastructures[END_REF] the authors implement a layer to create a hybrid distributed file system (HybridDFS) with reliable data storage clusters in Cloud and unreliable data storage in desktop grid. Each data chunk in volatile nodes has at least one replica distributed for different volunteer PCs or cluster nodes. This means, it is possible to check the feasibility of using hybrid infrastructures such as Cloud and VC.

A next generation data processing engine has been designed that is based on Lambda Architecture [START_REF] Wu | Book chapter: Big Data analytics = machine learning + cloud computing[END_REF]. This architecture makes it possible to build Big Data systems as layers that can satisfy the properties of getting low latency readings and updates without impairing the robustness of the system.

The Apache Flink, previously called Stratosphere, is a data analytic framework that follows the Lambda Architecture and enables the extraction, analysis and integration of heterogeneous datasets [START_REF] Alexandrov | The stratosphere platform for big data analytics[END_REF]. Flink has a flexible pipeline that enables several map-reduce and extended functions.

Although there have been several works that address this issue, there are still many open-ended problems about Big Data in Cloud environments. In addition, the geographically distributed environment has not been explored yet in hybrid infrastructures. The combination of VC resource allocation with Cloud environments for data-intensive applications, is a possible line of inquiry that could be explored to allow the available resources to be freely exploited. This work seeks to explore this and define what the reasonable constraints are for the development of a hybrid Infrastructure model that can make it possible to achieve this goal.

III. THE HYBRID INFRASTRUCTURE MODEL

The Cloud infrastructure is comprised of providers with heterogeneous hardware and the environments may need the specifications of configuration parameters at several levels such as the operating systems, service containers, and network capabilities [START_REF] Le | SALSA: A framework for dynamic configuration of cloud services[END_REF]. When there are many cloud providers with heterogeneous environments and configurations, a hybrid infrastructure often has to use an orchestrator to manage the results and data input from users. This infrastructure enables highly heterogeneous machines to be used.

On the basis of previous work carried out in MR for hybrid infrastructures [START_REF] Anjos | BIGhybrid: a simulator for mapreduce applications in hybrid distributed infrastructures validated with the grid5000 experimental platform[END_REF], Figure 1 illustrates the solution proposed here that involves a hybrid model which depicts a Global Dispatcher and Global Aggregator. This concept can be used as an infrastructure for services that rely on multiple data abstractions. The Global Dispatcher that is located outside the cloud, is a layer that handles task assignments and the management of user-provided data. The layer decouples the data storage system and manages policies for splitting and distributing data in accordance with each system. The Global Aggregator obtains data output from both systems and merges them to obtain the final dataset. The Global Dispatcher handles the task assignments and input data from users. It is a centralized data-driven subsystem that manages remote data localization, and policies for the splitting and distribution of data, in accordance with the needs of each system. The working principle is similar to the publish/subscribe service where the system obtains data and publishes the computing results. This approach is simple, but risks causing a network bottleneck.

Concerning the proposed hybrid infrastructure, we modeled strategies based on off-the-shelves frameworks (e.g., Apache Flink, BitDew-MR, and Hadoop) which establish a feasible platform to evaluate data distribution and task allocation. For instance, BitDew-MR improves computational performance with the use of VC in a hybrid infrastructure. This means the hybrid environment will be simulated through the features from the Flink for the Cloud and BitDew-MR for the Volunteer Computing. The Flink framework and BitDew-MR are considered like subsystems from the hybrid infrastructure. This environment must make it possible to evaluate the best strategies for data distribution and task allocation, and hence make it feasible to establish the platform for Big Data executions.

A. Model of strategies for data and task distribution

This section provides a conceptual basis for strategies to use hybrid infrastructures. The evaluation is presented in Section IV. The hybrid infrastructures have several features that are related to distinct resources. So, consider that a user must launch his applications in an infrastructure where himself must choose the best resources for Cloud and Volunteer Computing (VC) for composing a hybrid infrastructure.Thus, each resource can have a different abstract specification, the user will be able to know which resource is faster, through a simulated environment, before choosing the resource, as follows.

A CSP offers resources that represent VM instances of a hardware H V m (i), where i ∈ VM. Each VM represents a set of heterogeneous resources that are related to a number of CPU cores, memory, and storage. Each resource, called r c , represents a VM and the total amount of the available resources represent a vector Rc (n r ) = {r c 1 ,r c 2 ,...,r c n } where n r is the number of available resources, i.e., n r = [1,2,...,n] resources. The resource allocation defines the computational capacity in Flops/s of the machine set. The resources are homogeneous from the standpoint of the user, because the CSP only enables access to the virtual instances of machines. However, the hardware of the CSPs might be heterogeneous and in general, the user does not have any knowledge of them.

Hence, an allocated resource may have a poorer performance than a single hardware component, when two or more users are running their applications on virtual machines with the same leased hardware. The performance may have a different time rate of execution for each VM, called ρ, that is caused by the hardware contention. Its value can be between an interval of (0,1). Thus, the resource allocation (A V m ⊆ Rc ) of a user (u) in Cloud can be expressed in the Equation III.1, where n ≤ n r .

A V m (u) = n i=1 (1 -ρ i )r ci (III.1)
In VC, a donor offers a hardware H l (t) that will be dedicated to the processing of tasks for an unspecified time period (t), where the number of offers to a volunteer resource pool are defined by l = [1,2,3,....,m] resources. Any free hardware is related to heterogeneous resources that represent the number of CPU cores, memory, and storage available within a time period. The pool is a set of stable and unstable nodes. The volunteer resources are a vector Rv (H l (t)) = {h 1 t 1 ,h 2 t 2 ,...,h m t k } where t k is the time availability in each machine for the users to make use of a free hardware resource in the resource pool. The user cannot define the availability time for a resource because this issue is handled for the user internally by the fault-tolerance mechanism of the platform in a transparent way. However, the user can define a variable ξ which determines the number of unstable nodes in the pool. The variable ξ is within the range of an interval (0,1). The VC maintains connections through the Internet. In addition, data transference will depend on the bandwidth β l between these nodes and the total bandwidth β ch available in the CSP channel. The allocation of VC resources (A VC ⊆ Rv ) of a user (u) is represented by Equation III.2.

A VC (u) = m k=1 (1 -ξ )h k (III.2)
The performance model has a component that represents the Cloud Allocation with stable VMs and a VC allocation that depends on a rate corresponding to ξ that defines the ratio of the unstable nodes and might be influenced by the available bandwidth ratio. This model shows the effects of the job execution on the data-intensive applications. Choosing the best features of the platform and data distribution for the environment are crucial factors that are required to mitigate these effects. Thus, the performance of an allocation P(A u ) of a user u is defined by Equation III.3.

P(A u ) = n i=1 (1 -ρ i )r ci Cloud allocation + m k=1 (1 -ξ )h k VC allocation (III.3)
The hybrid infrastructure scenario in this study consists of five key components: workers, orchestrators, the dispatcher, aggregators and CSPs. Figure 2 represents these components and shows the data flow for this scenario. The workers are grouped according to their computational capacity to integrate a VC that provides a pool of computational resources for a user in a private mode. This private mode means that no other user can employ the allocated resources until the user himself releases them to the resource pool.

An orchestrator (built in the dispatcher module) receives the data which is assigned as user tasks and transformed into a "job". After this, the dispatcher partitions the data and tasks on the basis of their computational capacities and assigns them to VC and Cloud. In a hybrid infrastructure, each system processes its own data by grouping the intermediate data in a last Reduce phase within the Cloud to produce a single result in the aggregation stage. The Shuffle occurs in parallel with the Map phase. This begins when the Map tasks that have been completed achieve at least 5% (a Hadoop standard) and in the case of Cloud, assume that the execution of Reduce begins after all the Map tasks have been fulfilled. The time T t (in Equation III.4) of a MapReduce job in a hybrid infrastructure (inspired by the equations of Ohnaga et al. [START_REF] Ohnaga | Performance of Hadoop application on hybrid cloud[END_REF] and Khan et al. [START_REF] Khan | Hadoop performance modeling for job estimation and resource provisioning[END_REF]) consists of a maximum value between the execution time in Cloud (T c ) and VC (T d ) added to the time of the data integration (called T i ). The T i time includes the transfer of intermediate data (T ε ) from the VC to Cloud through an Internet link, and the time of the additional Reduce phase to produce a single Reduce. Our system is different from other approaches because it includes the integration time to produce a single and consistent result for Big Data processing.

T t = max(T c ,T d ) + T i (III.4)
The user submits a job (J) that will execute a workload across a set of selected resources (S) from all of the available resources in Cloud and VC (R) (where S ⊆ R). When pending tasks occur for a job launch, the system scheduling allocates one free slot per time to each machine in the whole resource pool, and after this, will allocate the other pending tasks in one free slot for each machine and so on. This process sets off execution waves (w j ) which are limited to the maximum number of allocated resources since the workload is larger than the computation resources available. These waves are rounds of successive executions G = {1,2,3,4,5,...,n} that continue until all the n tasks have been completed. The execution waves are defined as follows w j ⊆ G ⊆ J.

The concurrent tasks define execution spaces, called slots, in each machine and the number of free slots determines the amount of parallel work. As discussed previously, the Shuffle phase occurs at the same time as the Map phase if there is more than one execution wave. Thus, the time spent on data transfer (called T S ) must be reduced to the max time of the last Map phase in the last wave. Therefore, the sum of the max time for the Map and Reduce phase in each wave is added to the T S time.

The strategy of data distribution, in the Global Dispatcher module seeks to maximize the use of the VC resources, while at the same time, reducing the Cloud allocation resources. This is carried out without increasing the execution time when compared with a single Cloud implementation and the datasplit will include the execution waves in the dispatcher to achieve this aim.

The MapReduce execution occurs in waves because the machines begin the tasks and finish almost at the same time. Then, the total resources (R T c ) are the sum of Vm instances (V m c ) multiplied by the Map free slots of a machine (τ Mc ). Slots represent the simultaneous execution tasks on the machine. The Equation III.5 introduces the Φ relation that is the result of the total workload in Cloud (W c ) (equivalent to chunk numbers) divided by the available resources in Cloud (R c ). When Φ C = 1, then all the resources are busy, and there is a full execution wave. That is, Φ relation summarizes the workload for each infrastructure.

Φ C = W c R c ,where R c = M i V m c (i) and R c ⊆ R T c (III.5)
In finding the best data distribution, it is necessary to take half of the machines to Cloud and VC. The job in hybrid systems has two executions and to achieve a good load balance the Φ Ch relation in Cloud must be balanced to Φ VC relation. The best strategy is to use Equation III.5 to find the load balancing. Equation III.6 reflects the Φ relation in Cloud hybrid and VC, where Ck Ch and Ck VC are the chunk size in Cloud hybrid and VC respectively, and Ck c the chunk size for a single execution in Cloud.

Φ Ch = Ck Ch Ck c * W Ch ∑ M i V m c (i) Φ VC = Ck VC Ck c * W VC ∑ M i M VC (i) (III.6)
Finally, the best load balance is achieved when Equation III.7 is verified, this relation defines the data distribution related to the number of Cloud and VC resources which is the goal of the data load balance strategy.

Φ Ch ≤ Φ C ⇐⇒ Φ VC ≤ Φ C (III.7)
IV. EVALUATION

This section provides the evaluation of data distribution model strategy for Big Data processing and analysis in hybrid infrastructures.

The strategies seek a minimal rate ξ to define the ratio between VC and Cloud nodes, also the data load balance to improve the computation resource allocation in a hybrid infrastructure. The workloads are real-world executions that have their origin in Big Data applications of companies like Yahoo (YH) and Facebook (FB) [START_REF] Chen | Workload-driven design and evaluation of large-scale data-centric systems[END_REF]. The YH and FB clusters have 2,000 and 3,000 machines respectively. Although the type of jobs at Facebook can change significantly from one year to another, the purpose of this scenario is to cover real-world environments. On the basis of this scenario, around 1,800 simulated experiments were conducted with the BIGhybrid simulator with the aims of finding compatible low and largescale patterns in hybrid infrastructures.

A. Simulated Experiments in Hybrid Infrastructures

This subsection describes a simulated environment setup to validate strategies in hybrid infrastructures. The evaluation of the strategies for the use of hybrid infrastructures in Big Data is divided into low-scale, middle-scale and high-scale experiments.

The computational capacity of the processors in the simulated experiments is equivalent to an Intel Xeon E5506 -2 Cores, 4M Cache, 2.13 GHz ≈ 5 GFlops and the computational capacity in a volatility environment represents a distributed value between 4 to 6 GFlops, for all of the experiments. The configuration is similar to what was found in Yahoo and Facebook by the evaluation made by Yanpei [START_REF] Chen | Workload-driven design and evaluation of large-scale data-centric systems[END_REF]. For analytical purposes, the computational consumption is defined by workloads of 64, 32 and 16 MB chunk size. The network, workload and the machines numbers vary in each experiment. The number of the Reduce tasks is equal to twice the machine number.

The first experiment has more tasks than resources (T > R) with a workload of 512 tasks (chunk size 64 MB) and 128 machines. The hardware and task configurations are the same as in the earlier experiment. The aim of this experiment is to consolidate the observations with regard to the relation of data distribution between Cloud and VC. Figure 3 shows eight executions ranging from A to H at the top of the chart. The chunk size and input data are described in the graph for each execution for Cloud (C) and VC. The red line indicates the time for a single Cloud deployment, equivalent to 1,232 seconds. The concurrent task execution in the yaxis is measured in seconds, and the number of the machines for Cloud and VC (Cloud/VC) in the x-axis is measured in units. The experiment shows that the data distribution for this scenario achieves the best load balancing when Equation III.7 is true. The A, B, C and D executions shown in Figure 3 have a performance that is acceptable in this case.

However, when there is more resources than tasks (R > T ) a lower limit (Φ C = 1) is established, this makes sense if we imagine that all tasks are running in a single wave. Table I shows that is possible to establish an upper limit for the Φ relation for Cloud and VC which is independent of the time execution and has a value of Φ ≤ Φ C . Thus, the relationship for the resource distribution can be summarized as 1 ≤ Φ ≤ Φ C . This relation enables the machine quantities to be defined in a hybrid infrastructure through an initial simulation of Cloud execution and then to determine the data distribution for the hybrid infrastructure. This means both load balance from the Cloud and Volunteer Computing are bound by the Φ relation. Figure 4 shows the impact of volatility on performance for the same execution profile of Figure 3. The letters (a) and (b) correspond to the A and B executions in Figure 3 respectively. The y-axis measures the time in seconds and the x-axis represents the percentage of volatile machines. The first time execution on the left (for all the Figures) represents an implementation without volatility, for comparative purposes, which is the basis of the incremental volatility nodes made in the offsets of 5% to 35%. The experiments show the behavior of the task executions with a networking of 10 Mbps bandwidth. The line red represents the execution time of 1,232 seconds in a single Cloud.

The impact of volatility is sensitive for tasks with a chunk size ranging from 32 to 64 MB due to the overhead of data copy when a machine has a shutdown. The low bandwidth of the network affects the data transfers considerably. The experiments suggest there is an operational flexibility in volatile environments when 20% to 25% of machines have a shutdown without any serious degradation of performance. The chunk sizes for this scenario is 32. However, losing 1 4 of machines in VC can produce a high latency in a slow Internet link. The VC environments can remain relatively stable in some Another factor is that is necessary to evaluate the strategy of the mechanism to improve the performance of Big Data in a hybrid infrastructure, as discussed earlier. In a volatile environment, the machines may have an overhead with a data copy to rebuild replicas, since they might experience long timeout periods, which can allow for the Fault-Tolerance Mechanism (FTM) to take account of false-negatives in the execution behavior. The FTM was detailed in previous work [START_REF] Anjos | BIGhybrid: a simulator for mapreduce applications in hybrid distributed infrastructures validated with the grid5000 experimental platform[END_REF].

Figure 5 shows several VC job executions with the aim of determining the behavior in a high-scale and Table II shows the number of machines and workloads. The executions run with a 64 MB chunk size. The experiment in a single Cloud runs in 901 seconds on 2000 machines and a workload of 9088 chunks. The red line in the Figure 5 The experiment in high scale shows that the behavior is different between operations of medium and low-scale. This can be explained by the large number of machines in the network and the administrative overhead needed to manage the This scenario demonstrates that a slight variation in workload can lead to behavioral changes in the VC environment. Thus, hybrid infrastructure with high workloads require orchestrators to control data transfers and the task synchronization.

B. Discussion

The results of the simulated experiments established strategies for using hybrid infrastructures based on behavior patterns of job executions in Cloud and VC.

Since an optimal allocation is difficult to achieve, strategies to obtain an approximation can be accepted, as argued by Mashayekhy et.al. [START_REF] Mashayekhy | A PTAS mechanism for provisioning and allocation of heterogeneous cloud resources[END_REF]. The Φ Ch and Φ VC parameters used to find Cloud and VC resources, establish a suitable number of machines to achieve an acceptable performance and good approximation. As well as this, these settings help inexperienced users to locate the number of Cloud and VC machines without the need for a previous knowledge of the CSP infrastructure, which can be considered to be one of the benefits of this study.

The relation between workload, number of machines and load balance can be viewed as a significant contribution to providing a data load balance and reducing the data transfers between machines from 39.1% to 57.14% in the worst and best case scenarios, respectively. These values are compatible with the work of Tudoran et.al. [START_REF] Tudoran | Bridging data in the clouds: An environment-aware system for geographically distributed data transfers[END_REF] who achieved a reduction of 50% with a relative error from 10% to 15%. The relation where 1 ≤ Φ ≤ Φ C is particularly stable in all the scales regardless of bandwidth.

V. CONCLUSIONS Cloud computing has changed the way applications are developed and ported in geographically distributed infrastructures. Clouds can offer several services, by providing dynamic features as well as being a suitable scenario for building Big Data applications and their range of components. However, the resource management for intensive applications, such as MapReduce applications, remains an opened topic due to the wide use of resources at run time [START_REF] Xavier | A performance isolation analysis of disk-intensive workloads on container-based clouds[END_REF], [START_REF] Xavier | Understanding performance interference in multi-tenant cloud databases and web applications[END_REF]. This problem can be even worse if the users do not manage their application resources properly, and can leading to problems of cost effectiveness.

The proposed evaluation found behavioral patterns which enable their deployment in hybrid infrastructures (in low and high scale) and established a set of strategies such as: i) The relationship between the execution time and the number of volatile nodes; ii) The relationship between resource distribution in Cloud and VC; iii) The relationship Φ between Cloud and VC; iv) The relationship between the load balance and number of machines; The results are summarized in Table III and suggest that the hybrid infrastructures have an operational continuity in an environment with up to 25% of unstable nodes in the worst case scenario without a loss of performance and with 3 replicas which is the Hadoop standard.

The Φ Ch and Φ VC parameters designed to find Cloud and VC resources, established that there were a number of suitable machines that could achieve an acceptable performance. The Φ relationship between Cloud and VC can help the users to find resources that are adapted to their workloads. In future works, several activities are needed to build the SMART platform in a real-world environment. First, it is necessary to complete the cost model analysis and the I/O interference of the strategies defined in this work. The mechanism of the decision engine can assist some strategies of this work when deployed as a decision heuristic model.

Fig. 1 .

 1 Fig. 1. Hybrid infrastructure from a high-level view

Fig. 2 .

 2 Fig. 2. An example of the data flows in the hybrid infrastructure

Fig. 3 .

 3 Fig. 3. Low Scale -128 Machines -10 Mbps -Tasks > Resources

Fig. 4 .

 4 Fig. 4. Impact of Volatility on Performance -10 Mbps -Tasks > Resources

  indicates the time of this execution in a high-scale. The y-axis measures the parallel tasks in a VC environment in seconds for each execution and the x-axis measures the bandwidth. The different jobs are represented with colors, as indicated in the caption. The different jobs are represented with colors as indicated in the caption of the Figure, and each Job shows its Φ relation to Cloud and VC respectively. The Φ VC relation (VC relation) is maintained according to the earlier estimate.

Fig. 5 .

 5 Fig. 5. Simulation in High-Scale (2,000 machines)

TABLE I THE

 I Φ RELATIONSHIP FOR DATA DISTRIBUTION IN HYBRID

				INFRASTRUCTURES
	Relation	Cloud	A	B	C	D	E	F	G	H
	Φ Ch Φ VC		4/4 4/4	4/4	4/4	4/5	3/6	3/7	3/7
	Φ Ch Φ VC	4

TABLE II RELATION

 II WORKLOAD VS. NUMBER OF MACHINES Relation (Φ Ch Φ VC ) #Chunks (C/VC) Machine (C/VC)

	VC JOB (4.04/4.54)	7270/1818	1800/400
	VC JOB (4.03/2)	7270/1818	1800/909
	VC JOB (3.88/2)	7000/2088	1800/1044
	VC JOB (3.88/1.91)	7000/2088	1800/1800
	VC JOB (3.88/1.02)	7000/2088	1800/2044
	VC JOB (2.97/2)	5000/4088	1680/2044
	data transference in the Internet. In some case, the execution
	is possible from 50 MHz to 300 MHz bandwidth, but the best
	performance occurs with 300 MHz bandwidth. However, a
	thorough cost analysis can determine other data distributions
	where the borderline for the Cloud execution may be exceeded
	without any loss of quality in the solution. The results indicate
	a cost reduction ranging from 10% to 50% in the worst and
	best case scenarios respectively, in comparison with a single
	Cloud execution.

  Ch ≤ Φ C ⇐⇒ Φ VC ≤ Φ C Achieved

		TABLE III
	STRATEGIES AND ACHIEVED AIMS
	Parameters	Strategies		Aim
	Volunteer hosts	5% < ξ < 25%	Achieved
	Cloud resources VC resources Φ relation between Cloud and VC	Φ Ch = Φ VC = 1 ≤ Φ ≤ Φ C Ck Ch Ckc * Ck VC Ckc *	W Ch ∑ M i V mc(i) W VC ∑ M i M VC (i)	Achieved Achieved Achieved
	Data load balance	Φ

ACKNOWLEDGMENT

This work was partly sponsored by CAPES, PROPESQ-UFRGS and by projects: "GREEN-CLOUD: Computac ¸ão em Cloud com Computac ¸ão Sustentável" (#16/2551-0000 488-9) and SmartSent (#17/2551-0001 195-3) from FAPERGS and CNPq Brazil, program PRONEX 12/2014. The experiments in this paper were carried out using the Grid'5000 experimental testbed, ans conducted under the INRIA ALADDIN development scheme with the support of CNRS, RENATER and several Universities as well as other funding bodies (see https://www.grid5000.fr).