Perfil de formación requerido

The basic redeployment algorithm described above may not perform well under certain conditions, primarily due to the distributed nature of the planning decisions. This section outlines a number of techniques that overcome these limitations.

6.2.1

Fluctuations

Since each engine independently carries out redeployment decisions concurrently based largely on local information, it is possible that two or more engines repeatedly alternate among a set deployment decisions.

A number of relatively simple constraints are applied during the redeployment algo- rithm to reduce the likelihood of such alternating decisions.

Two thresholds are used to avoid those redeployments that are likely to result in unstable behaviour. A benefit threshold Tbenef it is used to only move activities that will

provide a non-trivial benefit, and a duration thresholdTduration ensures that an activity is

hosted at an engine for a sufficiently long time before it can be redeployed. In addition, a random jitter is applied toTduration so that engines do not redeploy activities in lock-step.

This increases the chance of an engine observing the effect of the redeployments made by another engine before it makes its own decision.

In addition, during each planning phase, only the top k most beneficial redeployment opportunities are carried out. Again, this allows the effect of a few redeployments to be observed before more decisions are made.

6.2.2

Activity set redeployment

There are cases where the distributed redeployment algorithm may get stuck in a locally optimal configuration. One reason for this is that the algorithm considers the deployment of each activity individually. By considering the possibility of moving sets of activities, it may be possible to escape some of these local minima cases. The experiment in Section6.4.4 illustrates this point.

Algorithm 3 can be extended so that it estimates the SLA cost function when sets of activities are redeployed. However, given n activities deployed at an engine, there are 2n_{−1 subsets of these activities, and it is not feasible to estimate costs for each set.}

Instead, the algorithm restricts itself to activities that are contiguous in the workflow, and only to sets with no more thanTmaxsetactivities. These heuristics still leave the algorithm

vulnerable to locally optimal configurations, but substantially reduce the search space of the algorithm and make the problem tractable.

6.2.3

Configuration sensitivity

The redeployment manager makes activity placement decisions using activity and engine profiles gathered over a window of samples. For example, the activity profiler may com- pute the average number of invocations of an activity over a time window of duration

θ. The choice of θ represents a tradeoff between the responsiveness and accuracy of the profiler and ultimately of the redeployment decisions as well. Typically, a larger θ will, by gathering more samples, result in a more accurate reading of the profiled values. The larger sample window, however, also means that it will take longer for changes in the observed metrics to be reflected in the averaged results, and hence activity redeployment decisions may lag the optimal movement time. On the other hand, with a small θ, the profilers will be more responsive to changes in the sampled values, but are susceptible to short term perturbations in the samples. This can be a problem as it may result in

Chapter 6. Distributed activity placement 153

frequent activity movement decisions as the system reacts to transient disturbances in the environment or process flow. An example of this phenomenon is demonstrated in the evaluations in Section 6.4.6.

To increase the robustness of the deployment decisions, and tolerate short-term per- turbations in the system, the redeployment algorithm is extended to record the dis- tributions of observed values, and to only act on those values that occur with a high probability.

In particular, the activity profiler maintains a histogram of statistics Hsk(ai) on ac- tivities instead of a running average of these statistics over some window. The domain of these histograms is a predefined set of ranges over the value being measured. For example, for a metric that measures the message latencies, it would store a histogram of the number of messages whose latencies fall into certain latency ranges. Similarly, the engine profiler records a histogram of information Hp_k(ej) about known engines in the system. The metric estimator then computes a joint histogram Hc_k(ai, ej) on the two histograms accumulated by the activity and engine profilers.

Finally, the cost model applies the cost function to this distribution of metric costs to compute a distribution of total cost Hc(ai, ej) of deploying an activity ai at engine ej. Now, this histogram can be used to determine a more robust estimate of a particular

deployment alternative. For example, by looking up the 95% value in a cumulative distribution of Hc(ai, ej), the algorithm considers the cost of the deployment decision under all but the most unlikely set of conditions.