“ElasticTree: Saving energy in data center networks“

by Brandon Heller, Seetharaman, Mahadevan,Yiakoumis, Sharma, Banerjee, McKeown

presented by Nicoara Talpes, Kenneth Wade

About the paper

•Published in April 2010 at Networked Systems Design & Implementation (NSDI)

Motivation 1•Efforts spend so far on servers and cooling. Our focus is on the network (10-20% total power)•Environmental Protection Agency: estimate that in 2011 networks in data centers will consume 12 B kWh•This is 6.542.640 tons CO21

Motivation 2•Goal: energy proportionality

Motivation 3•Cannot get to green line using the hardware•Common network goal is to balance traffic evenly among all links: power is constant regardless of load •‘Data centers provisioned to run at peak workload, below capacity most of the time’•Today’s network elements not energy proportional: switches, transceivers waste power at low loads•Switches consume 70% of full power when idle

Existing networks•2N: fault tolerant

Wasted power•Servers draw constant power independent of traffic•time varying demands, provisioned for peak

ElasticTree

• Goal: build network that has energy proportionality even if switches don’t

• By using traffic management and control of switches: turning on switch consumes most of the power; 8%: going from zero to full traffic; turning off switch saves most power

• Careful: minimizing effects on performance and fault tolerance

• Has to work at scale to make an impact• With ET, we do opposite than balanced networks: only

use a few links, lower power at low loads (ex: middle night)

Existing networks: scale-out•Ex: Fat-tree; incremental degradation

Existing networks: scale-out

Implementation 1

• Optimizer: find minimum power network subset which satisfies current traffic. Inputs: topology, traffic matrix, switch’s power models, fault tolerance constraints. Outputs new topology

• Continually re-computes subset as traffic changes• Power control: toggles power states of ports,

linecards, entire switches• Routing: chooses paths for all flows, pushes routes

into network

Implementation

Optimizer methods: formal model• outputs subset & flow assignments• Evaluates solution quality of other optimizers• optimal• (con) scales to number of hosts ^ 3.5

Optimizer methods: formal model• Doesn’t scale

Optimizer methods: Greedy-Bin packing

Optimizer methods: Greedy-Bin packing

Optimizer methods: Greedy-Bin packing

Optimizer methods: Greedy-Bin packing

Power savings: data centers• 30 % traffic inside dc, greedy-bin packet optimizer,

scaled, reductions of 25-60%: energy elastic!

Need for redundancy• Nice propriety: cost drops with increase of network

size since MST is smaller fraction

Optimizer methods: Greedy-Bin packing• Scales better, optimal solution not guaranteed, not

all flows can be assigned• Understand power savings for larger topologies

Optimizer methods: topology aware heuristic• Quickly find subsets in networks with regular

structure (fat tree)• Requires less information: only need the cross-layer

totals, not the full traffic matrix• Routing independent: does not compute set of flow

routes, (con) assumes divisible flows; can be applied with any fat tree routing algorithm (Portland); any full-bisection-bandwidth topologies with any nr layers (ex 1gb at edge, 10 gb core)

• Simple additions to this lead to quality solutions in a fraction of time

Optimizer methods: topology aware heuristic

Optimizer comparison

Optimizer comparison • formal model intractable for large topologies greedy• Un-optimized single-core python implementation: 20s

Control software• ET requires traffic data and control over flow paths.

we use Open Flow: generate traffic? and push application level flow routes to switches

Implementation

Implementation 2

• Openflow: measure traffic matrix, control routing flows

• Open flow: vendor neutral so no need to change code when use HP/ECR switches

• Experiments show savings 25-40% feasible: 1 bill KWhr annual savings; then we have proportional reduction in cooling costs

Experiments

• Topologies: two 3-layer k=4 fat tree; one 3-layer k=6 fat tree

• Measurements: NetFPGA traffic generator: each emulates four servers

• Latency monitor

Experiments

3 Power savings results• Formal method. Savings depend on network utilization• traffic all inside. near traffic at low utilization: 60%

reduction

Power savings: sine-wave demand• Reduction up to 64%

Robustness: safety margins• MSTs disadvantages: renounces path redundancy and fault

tolerance• Added cost of fault tolerance insignificant for large networks

Performance• Uniform traffic shows spikes, large delays for packets

Safety margins• safety margins defer points of loss, degrade latency• Margins are adjustable

Topology aware optimizer• Better robustness by tweaks: setting the link rate

utilization in equations to absorb overloads and reduce delay

• setting the switch degree to add redundancy for improving fault tolerance

• Solves constraints: Response times dominated by switch boot time (30sec - 3 min)

• Fault tolerance: move topology-aware optimizer to separate host to prevent crashes to affect routing.

• Traffic prediction experiments encouraging; can use greedy algorithm

7 Discussion• During low to mid-utilization, it respects the

constraints while lowering the costs

ReferencesSome images borrowed from the author’s presentation

available at his website or online at http://www.usenix.org/events/nsdi10/tech/

1-http://www.nef.org.uk/greencompany/co2calculator.htm