Micro load balancing in data centers with DRILL

Transcription

1 Micro load balancing in data centers with DRILL Soudeh Ghorbani (UIUC) Brighten Godfrey (UIUC) Yashar Ganjali (University of Toronto) Amin Firoozshahian (Intel)

2 Where should the load balancing functionality live?

3 Why load balancing in data centers?

4 Data center apps have demanding network requirements.

5 Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google s Datacenter Network, Google, SIGCOMM Data center topologies provide high capacity. Core Aggregation Edge Pod Pod 1 Pod 2 Pod 3 VL2: a scalable and flexible data center network, C. Kim et al., SIGCOMM 2009 A scalable, commodity data center network architecture, M. Al-Fares et al., SIGCOMM 2008 Jellyfish: Networking Data Centers Randomly., A. Singla et al., NSDI 2012

6 But we are still not using the capacity efficiently! Networks experience high congestion drops as utilization approached 25% [1]. Further improving fabric congestion response remains an ongoing effort [1]. [1] Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google s Datacenter Network, Google, SIGCOMM 2015.

7 The gap: High bandwidth provided via massive multipathing. Balancing load among many paths in real time seems too hard for our fast and dumb data center fabric. Congestion happens even when there is spare capacity to mitigate it elsewhere [2]. [2] Network Traffic Characteristics of Data Centers in the Wild, T. Benson et al., IMC 2010.

8 ECMP is not the answer. Select among equal-cost paths by a hash of 5-tuple Problems: Coarse grained Stateless and local A B D C

9 Rethinking the problem:... Hedera [NSDI'10] Mahout [INFOCOM'11] FastPass [SIGCOMM'14] Plank [SIGCOMM'14] Presto [SIGCOMM'15] MPTCP [NSDI 11] CONGA [SIGCOMM'14]

10 Rethinking the problem Let s move the load balancing functionality out of the core!

11 Central Controller Moving LB from fabric to:... Hedera [NSDI'10] Mahout [INFOCOM'11] FastPass [SIGCOMM'14] Planck [SIGCOMM'14] Presto [SIGCOMM'15] MPTCP [NSDI 11] CONGA [SIGCOMM'14] Controller

12 Hosts Moving LB from fabric to:... Hedera [NSDI'10] Mahout [INFOCOM'11] FastPass [SIGCOMM'14] Planck [SIGCOMM'14] Presto [SIGCOMM'15] MPTCP [NSDI 11] CONGA [SIGCOMM'14] Controller

13 Edge Moving LB from fabric to:... Hedera [NSDI'10] Mahout [INFOCOM'11] FastPass [SIGCOMM'14] Planck [SIGCOMM'14] Presto [SIGCOMM'15] MPTCP [NSDI 11] CONGA [SIGCOMM'14] Controller

14 Packet LB granularity Flowcell/ flowlet Flow Micro bursts Elephant flow Scalable LB design space Hedera Planck ECMP CONGA Presto O(µs) O(1ms) O(10ms) O(100ms) O(1s) Oblivious Control loop latency

15 Packet LB granularity Flowcell/ flowlet Flow Elephant flow Micro load balancing Microsecond timescales Microscopic, i.e., local to each switch port O(µs) O(1ms) O(10ms) O(100ms) O(1s) Control loop latency

16 Micro LB A plausible architecture Symmetric topologies dst port A 4,5,6 B 4,5,6 C 4,5,6 Fabric 1. Discover topology. 2. Compute multiple shortest paths. 3. Install into FIB ~ ECMP, so far...

17 Inside a switch dst port A 4,5,6,7 B 4,5,6,7 C 4,5,6

18 The power of 2 choices Random n bins and n balls Each ball choosing a bin independently and uniformly at random Max load: Optimal log n θ( log log n ) Y. Azar, A. Z. Broder, A. R. Karlin, and E. Upfal. Balanced allocations. SIAM Journal on Computing, 1994.

19 The power of 2 choices n bins and n balls Balls placed sequentially, in the least loaded of d 2 random bins Max load: log log n θ( log d ) d=1 d=2 Optimal Y. Azar, A. Z. Broder, A. R. Karlin, and E. Upfal. Balanced allocations. SIAM Journal on Computing, 1994.

20 What we want: Queues instead of bins. Each ball chooses a bin independently, no coordination.

21 What we want: Queues instead of bins. Each ball chooses a bin independently, no coordination. dropped

22 Simulation methodology OMNET++, INET framework Linux 2.6 TCP Leaf/spine topologies Datacenter traces from DevoFlow [SIGCOMM 11]

23 Queue lengths [STDV] The pitfalls of choice d=1 Balls and bins d=2 d=40 Setting parameters Stability d

24 Packet LB granularity Flowcell/ flowlet Flow Elephant flow DRILL Decentralized Randomized In-network Local Load balancing O(µs) O(1ms) O(10ms) O(100ms) O(1s) Control loop latency

25 Substantial improvement over prior work.

26 Substantial improvement over prior work. An incast application

27 Thou shalt not split flows! Splitting flows Reordering Throughput degradation

28 Splitting flows Reordering Throughput degradation DRILL splits flows along many paths USED PATHS 120% 100% 97% 98% 80% 73% 60% 40% 20% 0% DRILL Presto Random

29 Splitting flows Reordering Throughput degradation DRILL splits flows along many paths yet causes little reordering! USED PATHS OUT OF ORDER PACKETS 120% 100% 97% 98% 0.30% 0.25% 0.24% 80% 73% 0.20% 60% 0.15% 40% 0.10% 20% 0.05% 0.02% 0.04% 0% DRILL Presto Random 0.00% DRILL Presto Random

30 Splitting flows Reordering Throughput degradation DRILL splits flows along many paths yet causes little reordering! USED PATHS BUFFERING DELAY [MICRO SEC] 120% % 97% 98% % 73% 15 60% 10 40% % 0% DRILL Presto Random 0 DRILL Presto Random

31 Splitting flows Latency variance Reordering Throughput degradation

32 Splitting flows Latency variance Reordering Throughput degradation 00% 0% DRILL splits flows along many paths U S E D PAT H S 97% 73% 98% DRILL Presto Random but has low queueing delay variance QUEUE LENGTH [ STDV] and therefore causes little reordering! DRILL Presto Random Insight: Queueing delay variance is so small that it doesn t matter what path the packet takes B U F F E R I NG D E L AY [ M I C R O S E C ] DRILL Presto Random

33 Ongoing and future work Efficient handling of asymmetry Failures Irregular topologies with non-equal cost paths Converged Ethernet

34 Micro Load Balancing with DRILL: Conclusion Microscopic, microsecond decisions yield lowest latency load balancing Splitting flows is splitting hairs Strong candidate for augmenting data center switching hardware