Modeling Resilience in Cloud-Scale Data Centers John - - PowerPoint PPT Presentation

Modeling ¡Resilience ¡in ¡ ¡ Cloud-­‑Scale ¡Data ¡Centers ¡

John ¡Cartlidge ¡ School ¡of ¡Computer ¡Science ¡ University ¡of ¡Bristol, ¡UK ¡ john.cartlidge@bristol.ac.uk ¡

The ¡work ¡presented ¡here ¡was ¡performed ¡with ¡Ilango ¡Sriram ¡at ¡the ¡University ¡of ¡Bristol, ¡ UK, ¡and ¡was ¡funded ¡by ¡HP-­‑Labs ¡and ¡EPSRC ¡grant ¡EP/H042644/1 ¡as ¡part ¡of ¡the ¡naRonal ¡ Large-­‑Scale ¡Complex ¡IT ¡Systems ¡(LSCITS) ¡iniRaRve ¡headed ¡by ¡Professor ¡Dave ¡Cliff. ¡

Outline ¡

• Background: ¡Cloud ¡CompuRng ¡
• Problem: ¡Ultra-­‑large ¡scale ¡data ¡centres ¡(DCs) ¡

in ¡producRon ¡with ¡insufficient ¡pre-­‑tesRng ¡

• Long-­‑Term ¡Research ¡Aim: ¡To ¡create ¡a ¡robust ¡

simulaRon ¡modelling ¡framework ¡for ¡cloud ¡DCs ¡

• Today: ¡Modelling ¡failure ¡resilience ¡
• Demonstrate ¡resilience ¡and ¡efficiency ¡of ¡

different ¡redundancy ¡scheduling ¡algorithms ¡

2 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Cloud ¡CompuRng: ¡“the ¡next ¡step” ¡

The ¡commercial ¡provision ¡of ¡IT ¡has ¡undergone ¡“step” ¡ changes ¡every ¡10 ¡years ¡or ¡so… ¡

1960s: ¡Mainframes ¡-­‑ ¡physically ¡huge, ¡housed ¡in ¡air-­‑con ¡rooms ¡ Early ¡70s: ¡Mini-­‑computers ¡-­‑ ¡more ¡robust, ¡compact, ¡affordable ¡ Late ¡70s: ¡PCs ¡-­‑ ¡cheaper ¡& ¡smaller, ¡single-­‑user ¡ 1980s: ¡Communica3on ¡LANs: ¡Client-­‑server ¡model ¡first ¡used. ¡ Sun’s ¡slogan: ¡“the ¡network ¡is ¡the ¡computer” ¡ Mid ¡90s: ¡Widespread ¡adopRon ¡of ¡the ¡Internet ¡ Now: ¡Cloud: ¡online ¡provision ¡of ¡centralised ¡uRlity ¡compuRng ¡

3 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

CompuRng ¡as ¡a ¡URlity ¡

19th ¡Century: ¡Electricity ¡in ¡Manufacturing ¡

• Electricity ¡generaRon ¡as ¡important ¡to ¡

manufacturing ¡as ¡the ¡factory ¡itself, ¡with ¡ each ¡factory ¡having ¡its ¡own ¡generator ¡

• Economies ¡of ¡scale ¡by ¡uRlity ¡providers ¡made ¡

local ¡factory-­‑generaRon ¡uneconomic ¡ Today: ¡CompuRng ¡in ¡Business ¡and ¡the ¡Home ¡

• IT ¡is ¡a ¡necessity, ¡but ¡no ¡longer ¡offers ¡any ¡

parRcular ¡advantage ¡since ¡hardware ¡and ¡ sogware ¡is ¡ubiquitous ¡and ¡standardized ¡ ¡

• IT ¡can ¡be ¡provided ¡remotely ¡“in ¡the ¡cloud”, ¡

making ¡in-­‑house ¡data ¡centres ¡uneconomic ¡

4 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Ultra-­‑large ¡“cloud-­‑scale” ¡data ¡centres ¡

• Cloud ¡compuRng ¡offers ¡the ¡provision ¡of ¡IT ¡resources ¡in ¡

every ¡home ¡and ¡business ¡“as ¡a ¡Service” ¡

– Infrastructure ¡(IaaS), ¡Plajorm ¡(PaaS), ¡Sogware ¡(SaaS) ¡ – Enables ¡companies ¡to ¡focus ¡on ¡what ¡they ¡should ¡be ¡doing ¡ (their ¡core ¡business), ¡rather ¡than ¡running ¡data-­‑centres ¡

• Providing ¡cloud ¡services ¡requires ¡ultra-­‑large ¡DCs ¡

– Tens ¡of ¡thousands ¡of ¡servers, ¡and ¡growing ¡… ¡

• Unlike ¡HPC, ¡cloud ¡providers ¡use ¡commodity ¡hardware ¡

– Advantage ¡comes ¡from ¡scale-­‑out ¡(massive ¡parallelisaRon) ¡ not ¡scale-­‑up ¡(increasing ¡power ¡and ¡performance) ¡

5 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

“Normal” ¡Failure ¡

• In ¡a ¡DC ¡with ¡300,000 ¡servers, ¡each ¡with ¡an ¡average ¡life ¡of ¡

3 ¡years, ¡we ¡expect ¡+10 ¡deaths ¡/ ¡hour ¡

• Failures ¡and ¡outages ¡in ¡such ¡large ¡complex ¡systems ¡are ¡

normal: ¡not ¡unexpected ¡or ¡rare ¡

• However, ¡for ¡the ¡cloud ¡to ¡work, ¡providers ¡must ¡guarantee ¡

availability ¡(ogen ¡“triple ¡9”, ¡99.9%, ¡or ¡more) ¡ ¡

• Cloud ¡providers ¡need ¡to ¡build ¡resilience ¡into ¡their ¡systems ¡

“an ¡applica0on ¡running ¡across ¡thousands ¡of ¡ machines ¡may ¡need ¡to ¡react ¡to ¡failure ¡condi0ons ¡

• n ¡an ¡hourly ¡basis” ¡(Barosso ¡& ¡Hölzle, ¡Google, ¡2009) ¡

6 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Where ¡is ¡the ¡(simulaRon) ¡model? ¡

• Many ¡mature ¡engineering ¡fields ¡have ¡robust ¡industry-­‑

standard ¡simulaRon ¡frameworks ¡for ¡design ¡and ¡tesRng ¡

– E.g., ¡SPICE ¡for ¡integrated ¡circuit ¡design, ¡CFD ¡for ¡automoRve ¡

• For ¡cloud-­‑scale ¡DC ¡design ¡no ¡simulaRon ¡model ¡exists ¡ ¡
• DCs ¡are ¡going ¡into ¡service ¡without ¡sufficient ¡pre-­‑tesRng ¡
• At ¡UoBristol ¡we ¡are ¡arempRng ¡to ¡build ¡a ¡set ¡of ¡

simulaRon ¡tools ¡for ¡the ¡design ¡and ¡tesRng ¡of ¡cloud ¡DCs ¡ ¡ ¡

• Here, ¡we ¡present ¡a ¡preliminary ¡model ¡of ¡resilience ¡

7 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Redundancy ¡Scheduling ¡for ¡Resilience ¡

• Redundancy ¡can ¡be ¡used ¡to ¡counter-­‑act ¡

hardware ¡and ¡sogware ¡failures ¡

– MulRple ¡instances ¡running ¡in ¡parallel ¡ ¡

• However, ¡redundancy ¡is ¡costly ¡ ¡

– Increased ¡computaRon ¡and ¡network ¡ communicaRon ¡

8 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Data ¡Centre ¡Design ¡

Diagram ¡of ¡a ¡small ¡cluster ¡with ¡a ¡cluster-­‑level ¡Ethernet ¡ switch/router. ¡ ¡From ¡Barosso ¡& ¡Hölzle, ¡Google, ¡2009. ¡

9 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Data ¡Centre ¡Model ¡

S SSS SSS SSS SSS SSS S S SS S S S S SSS S S SS SSS SSS S S

Aisle

Rack Rack Rack C C C C B B B B B B B B

SSS

Data Centre

Aisle

Rack

S S S S S

C C C C B B B B B B B B

S

Hierarchical ¡network-­‑tree ¡model ¡of ¡DC. ¡ ¡Cloud ¡ Services ¡run ¡on ¡Blade ¡servers, ¡which ¡are ¡mounted ¡

• n ¡Chassis ¡in ¡Racks, ¡arranged ¡in ¡Aisles ¡within ¡a ¡DC ¡ ¡

10 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Model ¡AssumpRons ¡

• Failure ¡can ¡occur ¡at ¡any ¡level ¡in ¡the ¡hierarchy ¡tree ¡
• Network ¡costs ¡are ¡greater ¡when ¡“higher” ¡in ¡the ¡tree ¡

– Bandwidth ¡and ¡latency ¡is ¡greater ¡between ¡racks/aisles ¡ than ¡between ¡services ¡running ¡on ¡the ¡same ¡server ¡

• Jobs ¡consist ¡of ¡a ¡set ¡of ¡parallelizable ¡tasks ¡
• Fixed ¡DC ¡size ¡with ¡< ¡100% ¡uRlisaRon ¡
• Tasks ¡are ¡scheduled ¡using ¡3 ¡simple ¡algorithms: ¡

– Random ¡(distribute ¡tasks ¡randomly ¡across ¡DC) ¡ – Pack ¡(pack ¡all ¡tasks ¡into ¡the ¡smallest ¡region ¡possible) ¡ ¡ – Cluster ¡(pack ¡all ¡tasks ¡within ¡a ¡redundancy ¡group ¡together, ¡ distribute ¡groups ¡randomly ¡across ¡the ¡DC) ¡

11 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Redundancy ¡Scheduling ¡

Chassis

group 1 group 2

Job 1

group 1 group 2

Job 2

Random Pack Cluster Blade Blade Blade Blade Blade Blade Rack Chassis

Example: ¡2 ¡jobs, ¡each ¡with ¡3 ¡parallel ¡tasks, ¡using ¡ redundancy ¡2. ¡Total ¡tasks ¡= ¡2 ¡* ¡3 ¡* ¡2 ¡= ¡12. ¡

12 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

CommunicaRon ¡Networks ¡

3 1 2

Blade 1

3 1 2 3 1 2 3 1 2

S

C CS CS

S

C CS

S

C CS CS CB

B

C

S

C CS

Blade 2 Blade 2 Blade 1

Communication network after service failure Initial communication network

Tasks ¡communicate ¡with ¡ the ¡nearest ¡copy ¡of ¡every ¡

• ther ¡task. ¡Here, ¡all ¡

communicaRon ¡is ¡intra-­‑ server ¡(on ¡the ¡same ¡ physical ¡hardware). ¡ When ¡task ¡2 ¡fails, ¡ communicaRon ¡costs ¡ increase ¡from ¡6CS ¡to ¡4Cs +2CB. ¡ ¡We ¡now ¡have ¡more ¡ expensive ¡inter-­‑server ¡

• communicaRon. ¡

13 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Random ¡Scheduling ¡

Initialisation

2 1 2

Service Fail Blade Fail

1 1 2 1 3 3 3 3 2 2 1 3 3 2 1 1

Lots ¡of ¡long-­‑distance ¡(costly) ¡communicaRons, ¡ but ¡some ¡resilience ¡to ¡localised ¡failure ¡

14 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Pack ¡Scheduling ¡

Initialisation Service Fail Blade Fail

2 2 1 1 2 2 1 3 1 1 3 3 1 2 3 3 2 3

Localised ¡(cheap) ¡communicaRon, ¡but ¡vulnerable ¡ to ¡localised ¡hardware ¡failure ¡

15 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Cluster ¡Scheduling ¡

Initialisation Service Fail Blade Fail

2 1 1 3 2 3 1 2 3 2 1 1 3 3 2 3 1 2

Mainly ¡localised ¡(cheap) ¡communicaRon, ¡with ¡ some ¡resilience ¡to ¡localised ¡failure ¡

16 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

DefiniRon: ¡Job ¡Failure ¡

J = j

1 ,1

j

1 , 2

 j

1 , r

… j

1 , R

j2,1 j2, 2  j2, r  j2, R       jt,1 jt, 2  jt, r  jt, R       jT,1 jT, 2  jT, r  jT, R ⎛ ⎝ ⎜ ⎜ ⎜ ⎜ ⎜ ⎜ ⎜ ⎞ ⎠ ⎟ ⎟ ⎟ ⎟ ⎟ ⎟ ⎟

fails J

( ) ⇔ ∃t ∈T , ∀r ∈ R, fails jt, r

(

)

{ }

A ¡job ¡fails ¡if ¡all ¡redundant ¡copies ¡of ¡a ¡task ¡fail ¡ ¡

17 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Results: ¡Resilience ¡

• ¡Increase ¡in ¡failure ¡rate ¡-­‑> ¡decrease ¡in ¡resilience ¡
• ¡Increase ¡in ¡tasks ¡per ¡job ¡-­‑> ¡decrease ¡in ¡resilience ¡
• ¡Overall, ¡Cluster ¡is ¡the ¡most ¡resilient ¡algorithm ¡

20,000 ¡servers ¡

18 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

CommunicaRon ¡Costs ¡of ¡Redundancy ¡

• ¡Random ¡& ¡Pack: ¡costs ¡scale ¡linearly ¡with ¡R ¡
• ¡Cluster: ¡communicaRon ¡costs ¡invariant ¡(R>1) ¡
• ¡Pack ¡most ¡efficient, ¡Random ¡least ¡efficient ¡

19 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

Conclusion ¡& ¡Future ¡Work ¡

• DemonstraRon ¡of ¡how ¡simulaRon ¡models ¡of ¡cloud-­‑

scale ¡DCs ¡can ¡be ¡used ¡to ¡determine ¡the ¡resilience ¡ and ¡cost ¡of ¡redundancy ¡scheduling ¡algorithms ¡

• Models ¡will ¡enable ¡cloud ¡providers ¡to ¡tune ¡their ¡

schedulers ¡based ¡on ¡expected ¡failure ¡and ¡demand ¡

• Future ¡work: ¡To ¡create ¡an ¡open-­‑source, ¡extensible ¡

simulaRon ¡framework ¡for ¡modeling ¡cloud ¡DCs ¡ ¡

• CloudSim: ¡to ¡be ¡open-­‑sourced ¡in ¡2012

¡ ¡

• Will ¡include ¡Resilience, ¡Pricing, ¡Power ¡Efficiency, ¡Cooling, ¡etc. ¡

20 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡

QuesRons? ¡

Contact: ¡ Dr ¡John ¡Cartlidge ¡ ¡ john.cartlidge@bristol.ac.uk ¡ hrp://www.cs.bris.ac.uk/~cszjpc/ ¡ Collaborators: ¡ Ilango ¡Sriram, ¡Prof. ¡Dave ¡Cliff ¡ LSCITS: ¡hrp://lscits.cs.bris.ac.uk/ ¡

21 ¡ john.cartlidge@bristol.ac.uk ¡ ¡ EMSS ¡Rome ¡ ¡Sep ¡2011 ¡ ¡