High-performance Finite State Machine on FPGA

Download Report

Transcript High-performance Finite State Machine on FPGA

Sharing the Data Center Network
Alan Shieh, Srikanth Kandula, Albert Greenberg,
Changhoon Kim, Bikas Saha
Microsoft Research, Cornell University, Windows Azure,
Microsoft Bing
NSDI’11
Outline





Introduction
Seawall Design
Evaluation
Discussion
Summary
NSLab, RIIT, Tsinghua Univ
2
Introduction

Data Center



Provide compute and storage resources for web
search, content distribution and social networking
Achieve cost efficiencies and on-demand scaling
Highly-multiplexed shared environments


VMs and tasks from multiple tenants coexisting in the
same cluster
Network performance interference and denial of
service attacks is high
NSLab, RIIT, Tsinghua Univ
3
Introduction

Problem with network sharing in datacenters

Performance interference in infrastructure cloud
services




Network usage is a distributed resource
Large number of flows
Higher rate UDP flows
Poorly-performing schedules in Cosmos (Bing)

Poor sharing of the network leads to poor performance
and wasted resources
NSLab, RIIT, Tsinghua Univ
4
Introduction

Poor sharing of the network leads to poor performance
and wasted resources
Map-Reduce workloads (5 maps and 1 reduce)
* Optimal bandwidth shares is non-goal
Require perfect knowledge about client demands
NSLab, RIIT, Tsinghua Univ
5
Introduction

Magnitude of scale and churn

The number of classes to share bandwidth among is
large and varies frequently

Cloud datacenters traffic is even harder to predict
NSLab, RIIT, Tsinghua Univ
6
Introduction

Requirements




Traffic Agnostic, Simple Service Interface
Require no changes to network topology or
hardware
Scale to large numbers of tenants and high churn
Enforce sharing without sacrificing efficiency
NSLab, RIIT, Tsinghua Univ
7
VM 1
VM 2
VM 3 (weight = 2)
VM 2 flow 2
VM 2 flow 3
VM 3:
~50%
VM 2 flow 1
VM 2:
~25%
VM 1:
~25%
NSLab, RIIT, Tsinghua Univ
8
Existing mechanisms are insufficient
In-network queuing and rate limiting
Not scalable. Can underutilize links.
Guest
Guest
HV
HV
Network-to-source congestion control (Ethernet QCN)
Requires new hardware. Inflexible policy.
Guest
Guest
Detect
congestion
HV
Throttle send rate
HV
End-to-end congestion control (TCP)
Poor control over allocation. Guests can change TCP
stack.
Guest
Guest
HV
HV
NSLab, RIIT, Tsinghua Univ
Seawall Design

Congestion controlled hypervisor-tohypervisor tunnels
Guest
HV
Guest
HV
NSLab, RIIT, Tsinghua Univ
10
Seawall Design

Bandwidth Allocator
Weighted additive increase, multiplicative
decrease (AIMD) derived from TCP-Reno
Decrease:
Increase:
 Three improvements




Combine feedback from multiple destinations
Modify the adaptation logic to converge quickly and
stay at equilibrium longer
Nest traffic
NSLab, RIIT, Tsinghua Univ
11
Seawall Design

Step 1 : Using distributed control loops to
determine per-link, per-entry share

Lacking of XCP, QCN, SideCar
NSLab, RIIT, Tsinghua Univ
12
Seawall Design
Orange entity has demands (2x, x, x) to the three destinations

Step 2 : Convert per-link, per-entity shares to perlink, per-tunnel shares


Use β=0.9, allocates β fraction of the link bandwidth
proportional to current usage and the rest evenly across
destinations
The allowed share of the first destination converges to
within 20% of its demand in four iterations
NSLab, RIIT, Tsinghua Univ
13
Seawall Design

Improving the Rate Adaptation Logic

Use control laws from CUBIC to achieve faster
convergence, longer dwell time at the equilibrium
point, and higher utilization than AIMD
If switches support ECN, Seawall also incorporates the
control laws from DCTCP
Smoothed multiplicative decrease

Concave or convex increase


NSLab, RIIT, Tsinghua Univ
14
Seawall Design

Less than goal, concave increase

Above goal, convex increase
NSLab, RIIT, Tsinghua Univ
15
Seawall Design

Nesting traffic – deferring congestion control



If a sender always sends less than the rate allowed by
Seawall, she can launch a short overwhelming burst of
traffic
UDP and TCP flows behave differently: full burst UDP
flow immediately uses all the rate and a set of TCP
flows can take several RTTs to ramp up
TCP flow queries rate limiter
NSLab, RIIT, Tsinghua Univ
16
Evaluation

Traffic-agnostic network allocation

Selfish traffic = Full-burst UDP
NSLab, RIIT, Tsinghua Univ
17
Evaluation

Selfish traffic = Many TCP flows
NSLab, RIIT, Tsinghua Univ
18
Evaluation

Selfish traffic = Arbitrarily many destinations
NSLab, RIIT, Tsinghua Univ
19
Discussion

Seawall and cloud data centers

Sharing policies




System architecture



Work-conserving, max-min fair
Achieve higher utilization
Dynamic weight changes
Support rate- and window-based limiters
Based on both hardware and software
Partitioning sender/receiver functionality

Receiver-driven approach customized for map-reduce
NSLab, RIIT, Tsinghua Univ
20
Summary


Seawall is a first step towards providing data
center administrators with tools to divide their
network across the sharing entities without
requiring any cooperation from the entities
Well-suited to emerging hardware trends in
data center and virtualization hardware
NSLab, RIIT, Tsinghua Univ
21
NSLab, RIIT, Tsinghua Univ
22