Big Data + SDNSDN Abstractions

The Story Thus Far

• Different types of traffic in clusters

• Background Traffic– Bulk transfers– Control messages

• Active Traffic (used by jobs)– HDFS read/writes– Partition-Aggregate traffic

The Study Thus Far

• Specific communication patterns in clusters– Patterns used by Big Data Analytics– You can optimize specifically for theses

Map Map Map Reduce Reduce

HDFS

Map Map Map

HDFS

Reduce Reduce

ShuffleBroadcast Incast

The Story Thus Far

• Helios, Hedera, MicroTE, c-thru improve utilization– Congestion leads to bad performance– Eliminate congestion

Gather NetworkDemand

Determine paths with minimal congestion

Install New paths

Draw Backs

• Demand gather at network is ineffective– Assumes that past demand will predict future– Many small jobs in cluster so ineffective

• May Require expensive instrumentation to gather– Switch modifications– Or endhost modification to gather information

Application Aware Networking

• Insight– Application knows every the network need• So application can in fact instruct the network

– Small number of big data paradigms• So only a small number of applications need to be

changed• Map-reduce/hadoop, sharp, dyrad

– Application has a central entity controlling everything

Important Questions

• What information do you need?– Size of a flow– Source+destination of the flow– Start time of the flow– Deadline of the flow

• How should the application inform the network?– Reactively or proactively– Modified applications or unmodified applications

Challenges Getting InformationFlow Size

• Insight– Data that is transferred is data that is stored in a file

• Input data– Query HDFS for file size

• Intermediate data/Output Data– Reactive methods: wait for map to finish writing to temp file

• Asking the file system for size• Checking the Hadoop logs for file size• Checking the Hadoop web-API

– Proactive methods: predict size using prior history• Jobs run the same code over and over• Learn the ratio between input data and intermediate data• Learn the ratio between intermediate data and output data

Challenges Getting InformationEnd points

• Reactively– Job tracker places the task; it knows the locations• Check the hadoop logs for the locations• Modify the job tracker to directly inform you of location

• Proactively– Have the SDN controller tell the job tracker where

to place the end-points• Rack aware placement: reduce inter-rack transfers• Congestion aware placement: reduce loss

Challenges getting information:Flow start time

• Hadoop specific details obscure the start time– Reducer transfers data from only 5 map at at time• Tries to reduce unfairness

– Reducers randomly pick the mappers to start from– Reducers start transfer at random times• Tries to reduce incast – and synchronization between

flows

• Logs store when transfer starts

FloxBox: Simple Approach

• Insight: many types of traffic exist in N/W– We only care about map-reduce more than other traffic

• Solution: prioritize map-reduce traffic– Place them highest priority queue– Other traffic can’t interfere

• How about control messages?– Should prioritize those too.

Reactive Approach: FlowComb

• Reactive attempt to integrate bigdata + SDN– No changes to application

– Learn information by looking at logs and determine file size and end-points

– Learn information by running agents on the endhost that determines start times

FlowComb: Architecture

• Agents on servers– Detect start/end of map– Detect start/end transfer

• Predictor– Determines size of

intermediate data• Queries Map Via API

– Aggregates information from agents sends to scheduler

FlowComb: Architecture

• Scheduler– Examines each flow

that has started– For each flow what is

the ideal rate– Is the flow currently

bottlenecked?• Move to the next

shortest path with available capacity

Open Questions

• How about non map-reduce traffic?– Only focus on the active transfers ignores control msgs and

background

• How about HDFS reads and writes– Only focus on intermediate data

• Sub optimal control loop

• Benefits for small jobs?

CoFlows : Proactive Approach

• Modify the applications– Have them directly inform network of intent

• Application inform network of co-flow– Co-flow: Group of flows bound by app level

semantics– Challenges:• End-points not known at the beginning of transfer• Start times of the different flows not know• File-sizes not known but can be estimated

Interactions between Coflows

17

Sharing:»Sharing the cluster network among multiple

coflows: How to allocate»Reservation»Max-min faireness

Prioritization:»Using priorities as weights»Per job/application

We Want To…Better schedule the network

»Intra-coflow»Inter-coflow

Write the communication layer of a new application

»Without reinventing the wheel

Add unsupported coflows to an application, orReplace an existing coflow implementation

»Independent of applications18

Coflow APIs

19

Get+put operations allow you to overcome the limitation of unknown start times. The network determines when to do the transfer.You can call put, without specifying an endpoint. The network determines where to temporarily store. When the receiver calls a get, the network determines when to transfer the file, what rate and which replica.

20

CoflowAPI

Shuffle finishe

s

MapReduce

Job finishe

s

create(SHUFFLE) handle

put(handle, id, content)

get(handle, id) content

terminate(handle)

Driver

Summary• Applications know a lot about the transfers

– We can reactively learn by using logs– Or modify the application to inform us of these things

• Tricky information to obtain include:– Transfer start time– Transfer end-points

• CoFlows: proactive– Controls network path, transfer times, and transfer rate

• FlowComb: reactive– Controls network paths based on app knowledge

21

ToDo• Need more images from the infobox guys– Maybe improvements and why skethcy– Maybe graphs from flowcomb also

• Extensive discussion of pro-active versus reactive.

• Discussion on orchester should also include patterns from co-flow

• Add IBM talk.