Cost- and Energy-Aware Load Distribution Across Data CentersSlide 2MotivationsAssumptionsContributionsPrior ResearchRequest Distribution PoliciesPrinciples and GuidelinesOptimization Based Distribution (1/4)Optimization Based Distribution (2/4)Optimization Based Distribution (3/4)Optimization Based Distribution (4/4)Heuristic-Based Request Distribution (1/2)Heuristic-Based Request Distribution (2/2)Optimization-based vs Heuristics-basedEvaluationMethodology (1/4)Methodology (2/4)Methodology (3/4)Methodology (4/4)Result (1/4)Result (2/4)Result (3/4)Result (4/4)ConclusionDiscussionsCost- and Energy-Aware Load Distribution Across Data CentersPresented by Shameem AhmedKien Le, Ricardo Bianchini, Margaret Martonosi, and Thu D. Nguyen (HotPower 2009)Rutgers University and Princeton University2MotivationsLarge org has multiple Data Centers (DC)Business distributionHigh availability Disaster tolerance Uniform access times to widely distributed client sitesProblems Consumes lots of energyFinancial and environmental costHow can we exploit the geographical distribution of DCs for optimizing energy consumption? 1. Different & variable electricity prices (hourly pricing)2. Exploit DCs in different time zones (peak/off-peak demand price)3. Exploit DCs located near sites that produce “green” electricity 2AssumptionsMulti-DC Internet services (e.g. Google, iTunes)DCs are behind a set of front-end devices Each service has single SLA (Service Level Agreement) with customersSLA (L,P) = At least P% req must complete in <L timeReq can be served by 2 or 3 mirror DCFurther replication increases state-consistency trafficBut no meaningful benefit in availability or performance4Is it True? Is it True?Contributions Framework for optimization-based request distribution policyWhat % of client req should be directed to each DC Front-ends periodically solve optimization problem After % computation, front-ends abide by them until they are recomputed A greedy heuristic policy for comparisonSame goal and constraintsFirst exploits DC with best power efficiencyThen exploits DC with cheapest electricity 5Prior ResearchEnergy management on a single data centerA. Qureshi. HotNets 2008Shut down entire data centers when electricity costs are relatively highK. Le et al. Middleware 2007Did not address energy issues, time zones, or heuristics6Request Distribution Policies7Principles and GuidelinesOnly minimizing energy cost is not enoughMust also guarantee high performance and availabilityRespect these requirements by having the front-ends: Prevent DC overloadsMonitor response time of DCs and adjust req distribution accordinglyEach DC reconfigures itself byLeaving as many servers active as necessary + 20% slack for unexpected load increaseOther servers are turned off8“base” energy cost (servers are idle)energy cost of processing the client reqOptimization Based Distribution (1/4)Problem FormulationPolicy EPrice: Leveraging time zones & variable electricity pricesDoesn’t distinguish DCs based on energy source Doesn’t distinguish DCs based on energy source Symbol Meaningfi(t) % req to be forwarded to DC iLT(t) Expected total # of reqCosti(t) Avg cost ($) of a req at DC iBCosti(offeredi, t) Base energy cost ($) of DC i under offeredi loadLR(t) Expected Peak service rate (req/s)offerediLR(t) * fi(t)LCi Load Capacity (req/s) of DC iCDFiExpected % of req that complete within L time, given offeredi loadsatisfied bemust SLA i.e. )(/)),()()(( 1 0 PtLTofferedLCDFtLTtfLCiofferedit(t)ft(t)fittiiit iiiiiOptimization Based Distribution (2/4)Problem FormulationPolicy GreenDC: Leveraging DCs powered by green energy10energy cost of processing the client req “base” energy cost that is spent when active servers are idleotheriwse ),(),( and )()(GE consumpionenergy green if ),(),( and )()(itofferedbtof feredBCosttctCosttofferedbtofferedB CosttctCostiiiiiigreeniiigreeniiiAssumptions:1.DCs will increasingly be located near green energy source2.Green energy supply may not be enough to power DC entire period; Need backup (regular electricity) Assumptions:1.DCs will increasingly be located near green energy source2.Green energy supply may not be enough to power DC entire period; Need backup (regular electricity)Instantiating parameters Typical approach: front ends communicate & coordinateProposed approach:Each front end independently solves optimization problemLT(t), LR(t), and offeredi are defined for each front-end Load capacity (LC) of each DC is divided by # of front-ends CDFi instantiationCDFi = Expected % of req that complete within L timeEach Front end Collects recent history of response time of DCiMaintains a table of <offered load, %> for each DC Similar table for BCosti: <offered load, base energy cost>Symbol Meaningfi(t) % req to be forwarded to DC ICosti(t) Avg cost ($) of a req at DC IBCosti(offeredi, t) Base energy cost ($) of DC i under offeredi loadLCiLoad Capacity (req/s) of DC iLT(t) Expected total # of reqLR(t) Expected Peak service rate (req/s)offerediLR(t) * fi(t)CDFiExpected % of req that complete within L time, given offeredi loadOptimization Based Distribution (3/4)11Does this approach satisfy the constraints globally?Does this approach satisfy the constraints globally?Solving Optimization Problem Electricity price prediction: AmerenLoad intensity prediction: ARMACDFi prediction: Current CDFi tablesCan’t use LP solversSolving for entire day at once involves non-linear functions (e.g. BCosti, CDFi)Use Simulated Annealing Divide the day into six 4-hour epochsSolution recomputation (e.g. data center becomes unavailable)Optimization Based Distribution (4/4)12Heuristic-Based Request Distribution (1/2)Cost-aware but simpleFor each epoch (1 hr), each front-end computes R = P x E P = % of req must complete within L time (SLA)E = # of req front-end expects in next epoch (use ARMA)R = # of req that must complete within L timeEach front-end orders DCs that have CDFi(L, LCi)>= P according to from lowest to highest ratioRemaining DCs are ordered by same ratio Concatenate two lists of DC to create final list (MainOrder)13),()(iiiLCLCDFtCostHeuristic-Based Request Distribution (2/2)Request forward policyReq are forwarded to first DC in
View Full Document
Unlocking...