Large-Scale Distributed Computing VL 2010S. Thomas Perl, Stefan Kögl. Bandwidth Allocation in Clouds. Bandwidth Allocation in Clouds

(1)

Bandwidth Allocation in Clouds

Large-Scale Distributed Computing

187.271 VL 2010S

(2)

Over view

●

Workflow

●

Motivation

●

Implementation

●

Test Setting

●

Evaluation

●

Findings

●

Further work

(3)

Workflow

1.

Negotiate

parameters in SLAs

2.

Allocate

bandwidth to applications

3.

Monitor

per-application bandwidth usage

(4)

Motivation

●

Usual approach for monitoring:

●

per network interface in/out

●

per service (e.g. all traffic to port 80, …)

●

per device (aggregated network interfaces)

●

No per-application monitoring solutions

(5)

Implementation (bwmon)

Bandwidth Monitor per Application

Two Methods for Monitoring

Group Processes to Applications

SLA Parameters as Input

(6)

(7)

Implementation

Comparison of methods

Monitor

●

Aggregates Data from

/proc/net/ip_conntrack

●

Accounting done by

Kernel

●

Linux-only

●

Non-invasive

●

Handles arbitrary

Connections

Pipe

●

Accounts Data

passed through it

●

Accounting happens

in User-Space

●

Portable

●

Invasive

●

Handles one

Connection per

Instance

(8)

Implementation

Aggregator Module

Receives Data from Monitors / Pipes

Groups Processes to Applications

Receives SLA Parameters

Issues Notifications

(9)

Implementation

(10)

Test Setting

●

Intel Core 2 DUO P8700 @ 2.53 Ghz

●

4 GB RAM

●

Linux Kernel 2.6.32

●

100 Mbit fully-switched LAN

●

8 Mbit DSL Internet downlink (768k up)

●

HTTP server: lighttpd 1.4.26

(11)

Evaluation

Simulated Browser Session

●

Pre-generated URL list of random URLs

●

Scripted browser using WebKit's WebView

●

Requesting URLs in list (+ assets) for 30 Minutes

●

Same Traffic Pattern as on a Web-Server

●

Measure Impact of Monitoring

●

CPU: 303s User / 50s System

●

Memory: ~25kB per monitored Process

●

Impact independant of actual traffic

(12)

Evaluation

HTTP File Transfer

●

Create 100 MB file (from /dev/random)

●

Randomness facilitates bad compression

●

Multiple measurements (4 sessions/variant)

●

Findings

–

No change in total transfer time (wall time)

–

Double User-Space CPU-Time

–

Additional User- and Kernel-Space CPU Time for Pipe

(13)

Evaluation

BitTorrent Session

●

700 MiB Ubuntu 10.04 amd64 „alternate“ ISO

●

qBittorrent 2.2.5, 50 connections max (2Mbit downlink)

●

Comparison of three measurement methods:

–

/proc/net/dev (per-interface)

–

ip_conntrack monitor (system-wide, filtering on „qbittorrent“)

–

In-application progress display (application-specific payload)

●

Measurement error: only constant factor

–

inbound: ~ 1.2

–

outbound: ~ 0.91

(14)

Findings

Monitor accuracy – inbound BitTorrent traffic

100000000 200000000 300000000 400000000 500000000 600000000 700000000 800000000 900000000 1000000000 eth1 in monitor in torrent in b yt e s

(15)

Findings

Monitor accuracy – outbound BitTorrent traffic

0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 18 18 19 19 20 20 21 21 22 23 23 24 24 25 25 26 26 27 27 28 28 29 29 30 30 31 31 32 32 33 33 34 34 35 35 36 36 37 37 38 38 39 39 40 40 41 41 42 42 43 43 44 44 45 45 46 46 47 47 48 48 49 49 50 50 51 51 52 52 53 53 54 54 55 55 56 56 57 57 58 58 59 59 60 60 61 61 62 0 10000000 20000000 30000000 40000000 50000000 60000000 eth1 out monitor out torrent out b yt e s

(16)

Findings

Monitor accuracy – total BitTorrent traffic

100000000 200000000 300000000 400000000 500000000 600000000 700000000 800000000 900000000 1000000000 1100000000 eth1 total monitor total b yt e s

(17)

Findings

Monitor accuracy – total BitTorrent bandwidth

0 1 2 3 4 5 6 7 8 910111213141516171819202123242526272829303132333435363738394041424344454647484950515253545556575859606162 0 50000 100000 150000 200000 250000 300000 350000 400000 eth1 total bw monitor total bw b a n d w id th ( b yt e s/ se co n d )

(18)

Findings

Best Solution depends on circumstances

ip_conntrack still has some rough edges

„Costs“ of measuring can be high (granularity

vs. performance trade-off)

(19)

Fur ther work

●

Controlled lab setup of BitTorrent swarm

●

Pipe-based method as middleware in existing

enterprise servers (Servlet containers, WSGI)

●

Scaling of per-application bandwidth to fit the

per-interface traffic:

●

Re-implementation of pipe monitor in C

t

_intf

=

t

app

⋅

T

intf

T

_app

t …. single measurement

(20)

Links and downloads

Implemented in Python

License: GPL v3 „or later“

Project Website:

http://thpinfo.com/2010/bwmon/