3.3 Server Switching
3.3.2 Switching Policies
A switching policy is defined as an algorithm that when provided information on the current state of the system makes a decision on moving to another state. When doing this the policy must balance the potential improvement in QoS against the cost of performing the server switch. There are several examples of switching policies in the literature [42, 64]. Some of these policies are executed as a result of each arrival or departure of a request; while others are executed after a fixed time period and use statistics gathered over a time window to
inform the switching decision. A policy may also consider request arrivals as being on or off, which is dictated by any arrivals in a given time period. The work presented in [64] describes four possible switching policies, three of which are implemented in this chapter:
• TheAverage Flow Heuristic uses information on the arrival and comple-
tion rates of requests for each application in order to make a switching decision. This heuristic averages arrivals over the duration of the experi- ment and does not consider the distinct on/off periods for each application. This action requires that a weighted average arrival rate is calculated; this is shown in Equation 3.1, whereλ0 is the averaged arrival rate of the ar- rival rate (λ) in the busy periods (m) and the idle periods (n). Algorithm 2 is then used with the calculated average arrival rates. Line 1 of the algorithm initialises the total costs for each jobs queue to 0. The best de- cision cost is set to positive infinity on line 3. Both job types are checked to ensure that the completion rates are grater than zero (line 4) and an error is returned if they are not (line 5). The loop on line 7 starts from zero and iterates to the current number of servers allocated to job type 1. Lines 8 and 9 calculate the total costs for each job queue and if the overall cost for the new allocation is lower than the current best decision cost then the new allocation is stored (lines 11-12). Lines 15-22 execute the same steps for the second application. Finally the allocation with the best decision cost is returned on line 23.
The Total Cost algorithm first evaluates if any jobs exist in the queue (line 1), if no jobs exist on the queue then a total cost of 0 is returned (line 28). Where tasks exist in the queue, it is checked for stability (a completion rate greater than the arrival rate) on line 2. If the queue is unstable then a value of infinity is returned (line 25). An array of capacity to include all servers currently being migrated +1 is created and asigned tost on line 3. The number of migrating servers is iterated over and the rate at which
3. An Enterprise Testing Platform
migrating servers complete migration is stored at the relevant position in the arrayston line 5. The total cost is initialised to 0 on line 8. The rate of queue drainage is calculated at each possible migration rates between lines 12-22, and stops when the length of the queue would drain to zero. Finally the calculated total cost is returned on line 30.
λ0= λ×m
m+n (3.1)
• TheOn/Off Heuristicattempts to consider the “bursty” nature of requests
to each application. To do this it classifies each application’s requests as being on or off, and switches servers accordingly. To account for the on and off periods in the job streams, the arrival rate is calculated as in Equation 3.2; Algorithms 2 and 3 (explained above) are then used to calculate a new server allocation.
λ=
λ If the job stream is active.
0 Otherwise.
(3.2)
• TheWindow Heuristic uses statistics gathered over a sliding window of
time to calculate arrival and completion rates for each application within a time window. In so doing, the policy ignores the presence of any off periods in the time window. This algorithm is shown in Algorithm 4. The algorithm attempts to find teh lowest best decision cost by first initialis- ing the best decision cost to be positive infinity on line 2. A number of servers are initially assigned ton1 proportionally based on the job costs for job 1 (line 3), with the remainder of the servers being allocated to job type 2 (line 4). The algorithm then iterates from 0 to the number of total servers calculating the utilisation of servers in each pool for each allocation on lines 6-7. If the utilisation of each pool is less than 1 the cost of the switch is calculated (line 10) and compared against the current best decision cost on line 11. If a better configuration is found the cost
and allocations are stored on lines 12-14.New server allocations are then defined by comparing the current allocation with the calculated values on lines 18-19. The new allocation is returned on line 20. It should be noted that where the utilisation in either pool is grater than or equal to 1, no migrations occur under this policy.
3. An Enterprise Testing Platform
Algorithm 2Server allocation algorithm.
Input: Current server allocationS1, S2 Arrival Rates,λ1, λ2 Completion Rates,µ1, µ2 Queue Lengthsq1, q2 Switches in progressw1,2, w2,1 Switch Rater1,2, r2,1 Job costsc1, c2 Switch costssc1,2, sc2,1
Total costs for job queuestc1,tc2
Output: New server allocation,S10, S20
1: tc1, tc2←0
2: Letbdcbe best decision cost
3: bdc← ∞
4: if µ1= 0 andµ2= 0then
5: return error
6: end if
7: forsin S1 do
8: tc1←Call Algorithm 3 with parameterss, S, λ1, µ1, w2,1, r2,1, q1
9: tc2←Call Algorithm 3 with parameterss, S, λ2, µ2, w1,2, r1,2, q2
10: if (c1×tc1+c2×tc2+sc1,2×s)< bdc then 11: S0 1← −s 12: S20 ←s 13: end if 14: end for 15: forsin S2 do
16: tc1←Call Algorithm 3 with parameterss, S, λ1, µ1, w2,1, r2,1, q1
17: tc2←Call Algorithm 3 with parameterss, S, λ2, µ2, w1,2, r1,2, q2
18: if (c1×tc1+c2×tc2+sc2,1×s)< bdc then 19: S10 ←s 20: S20 ← −s 21: end if 22: end for 23: return S01, S20