Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Only Constant is Change: Incorporating Time-Varying Bandwidth Reservations in Data Centers Di Xie, Ning Ding, Y. Charlie Hu, Ramana Kompella 1.

Similar presentations


Presentation on theme: "The Only Constant is Change: Incorporating Time-Varying Bandwidth Reservations in Data Centers Di Xie, Ning Ding, Y. Charlie Hu, Ramana Kompella 1."— Presentation transcript:

1 The Only Constant is Change: Incorporating Time-Varying Bandwidth Reservations in Data Centers Di Xie, Ning Ding, Y. Charlie Hu, Ramana Kompella 1

2 Cloud Computing is Hot 2 Private Cluster

3 Key Factors for Cloud Viability Cost Performance 3

4 Performance Variability in Cloud BW variation in cloud due to contention [Schad’10 VLDB] Causing unpredictable performance 4

5 Network performance variability Tenant Enterprise Map Reduce Job Results Data analytics on an isolated cluster Completion Time 4 hours

6 Network performance variability Tenant Enterprise Map Reduce Job Results Data analytics on an isolated cluster Completion Time 4 hours Data analytics in a multi-tenant datacenter Tenant Map Reduce Job Results Datacenter Completion Time 10-16 hours

7 Network performance variability Tenant Enterprise Map Reduce Job Results  Data analytics on an isolated cluster Completion Time 4 hours  Data analytics in a multi-tenant datacenter Tenant Map Reduce Job Results Datacenter Completion Time 10-16 hours Variable tenant costs Expected cost (based on 4 hour completion time) = $100 Actual cost = $250-400

8 Network performance variability Tenant Enterprise Map Reduce Job Results Data analytics on an isolated cluster Completion Time 4 hours Data analytics in a multi-tenant datacenter Tenant Map Reduce Job Results Datacenter Completion Time 10-16 hours Variable tenant costs Expected cost (based on 4 hour completion time) = $100 Actual cost = $250-400 Unpredictability of application performance and tenant costs is a key hindrance to cloud adoption Key Contributor: Network performance variation

9 Reserving BW in Data Centers SecondNet [Guo’10] – Per VM-pair, per VM access bandwidth reservation Oktopus [Ballani’11] – Virtual Cluster (VC) – Virtual Oversubscribed Cluster (VOC) 9

10 How BW Reservation Works 10... Virtual Cluster Model Time Bandwidth N VMs Virtual Switch 1. Determine the model 2. Allocate and enforce the model 0T B Only fixed-BW reservation Request

11 Network Usage for MapReduce Jobs Hadoop Sort, 4GB per VM 11

12 Network Usage for MapReduce Jobs Hadoop Sort, 4GB per VM Hadoop Word Count, 2GB per VM 12

13 Network Usage for MapReduce Jobs Hadoop Sort, 4GB per VM Hadoop Word Count, 2GB per VM Hive Join, 6GB per VM 13

14 Network Usage for MapReduce Jobs Hadoop Sort, 4GB per VM Hadoop Word Count, 2GB per VM Hive Join, 6GB per VM Hive Aggregation, 2GB per VM 14

15 Network Usage for MapReduce Jobs Hadoop Sort, 4GB per VM Hadoop Word Count, 2GB per VM Hive Join, 6GB per VM Hive Aggregation, 2GB per VM 15 Time-varying network usage

16 Motivating Example 4 machines, 2 VMs/machine, non-oversubscribed network Hadoop Sort – N: 4 VMs – B: 500Mbps/VM 1Gbps 500Mbps Not enough BW 16

17 Motivating Example 4 machines, 2 VMs/machine, non-oversubscribed network Hadoop Sort – N: 4 VMs – B: 500Mbps/VM 17 1Gbps 500Mbps

18 Under Fixed-BW Reservation Model 18 1Gbps 500Mbps Job3 Job2 Virtual Cluster Model Job1 Time 0 5 10 15 20 25 30 500 Bandwidth

19 Under Time-Varying Reservation Model 19 1Gbps 500Mbps TIVC Model Job1 Time 0 5 10 15 20 25 30 500 Job2 Job3 Job4 Job5 J1J2J3J4J5 Bandwidth Doubling VM, network utilization and the job throughput Hadoop Sort

20 Temporally-Interleaved Virtual Cluster (TIVC) Key idea: Time-Varying BW Reservations Compared to fixed-BW reservation – Improves utilization of data center Better network utilization Better VM utilization – Increases cloud provider’s revenue – Reduces cloud user’s cost – Without sacrificing job performance 20

21 Challenges in Realizing TIVC 21... Virtual Cluster Model Time Bandwidth N VMs Virtual Switch 0T B Request Time Bandwidth 0T B Request Q1: What are right model functions? Q2: How to automatically derive the models? Q1: What are right model functions? Q2: How to automatically derive the models?

22 Challenges in Realizing TIVC 22 Q3: How to efficiently allocate TIVC? Q4: How to enforce TIVC? Q3: How to efficiently allocate TIVC? Q4: How to enforce TIVC?

23 Challenges in Realizing TIVC What are the right model functions? How to automatically derive the models? How to efficiently allocate TIVC? How to enforce TIVC? 23

24 How to Model Time-Varying BW? 24 Hadoop Hive Join

25 TIVC Models 25 Virtual Cluster T 11 T 32

26 Hadoop Sort 26

27 Hadoop Word Count 27 v

28 Hadoop Hive Join 28

29 Hadoop Hive Aggregation 29

30 Challenges in Realizing TIVC What are the right model functions? How to automatically derive the models? How to efficiently allocate TIVC? How to enforce TIVC? 30

31 Possible Approach “White-box” approach – Given source code and data of cloud application, analyze quantitative networking requirement – Very difficult in practice Observation: Many jobs are repeated many times – E.g., 40% jobs are recurring in Bing’s production data center [Agarwal’12] – Of course, data itself may change across runs, but size remains about the same 31

32 Our Approach Solution: “Black-box” profiling based approach 1.Collect traffic trace from profiling run 2.Derive TIVC model from traffic trace Profiling: Same configuration as production runs – Same number of VMs – Same input data size per VM – Same job/VM configuration 32 How much BW should we reserve to the application?

33 Impact of BW Capping 33 No-elongation BW threshold

34 Choosing BW Cap Tradeoff between performance and cost – Cap > threshold: same performance, costs more – Cap < threshold: lower performance, may cost less Our Approach: Expose tradeoff to user 1.Profile under different BW caps 2.Expose run times and cost to user 3.User picks the appropriate BW cap 34 Only below threshold ones

35 From Profiling to Model Generation Collect traffic trace from each VM – Instantaneous throughput of 10ms bin Generate models for individual VMs Combine to obtain overall job’s TIVC model – Simplify allocation by working with one model – Does not lose efficiency since per-VM models are roughly similar for MapReduce-like applications 35

36 Generate Model for Individual VM 1.Choose B b 2.Periods where B > B b, set to B cap 36 BW Time B cap BbBb

37 Challenges in Realizing TIVC What are the right model functions? How to automatically derive the models? How to efficiently allocate TIVC? How to enforce TIVC? 37

38 TIVC Allocation Algorithm Spatio-temporal allocation algorithm – Extends VC allocation algorithm to time dimension – Employs dynamic programming – Chooses lowest level subtree Properties – Locality aware – Efficient and scalable 99 th percentile 28ms on a 64,000-VM data center in scheduling 5,000 jobs 38

39 Challenges in Realizing TIVC What are the right model functions? How to automatically derive the models? How to efficiently allocate TIVC? How to enforce TIVC? 39

40 Enforcing TIVC Reservation Possible to enforce completely in hypervisor – Does not have control over upper level links – Requires online rate monitoring and feedback – Increases hypervisor overhead and complexity Enforcing BW reservation in switches – Most small jobs will fit into a rack – Only a few large jobs cross the core – Avoid complexity in hypervisors 40

41 Challenges in Realizing TIVC What are the right model functions? How to automatically derive the models? How to efficiently allocate TIVC? How to enforce TIVC? 41

42 Proteus: Implementing TIVC Models 42 1. Determine the model 2. Allocate and enforce the model

43 Evaluation Large-scale simulation – Performance – Cost – Allocation algorithm Prototype implementation – Small-scale testbed 43

44 Simulation Setup 3-level tree topology – 16,000 Hosts x 4 VMs – 4:1 oversubscription Workload – N: exponential distribution around mean 49 – B(t): derive from real Hadoop apps 44 50Gbps 10Gbps … … … 1Gbps … 20 Aggr Switch 20 ToR Switch 40 Hosts ………

45 Batched Jobs Scenario: 5,000 time-insensitive jobs 45 42%21%23%35% 1/3 of each type Completion time reduction All rest results are for mixed

46 Varying Oversubscription and Job Size 46 25.8% reduction for non-oversubscribed network

47 Dynamically Arriving Jobs Scenario: Accommodate users’ requests in shared data center – 5,000 jobs arrives dynamically with varying loads 47 Rejected: VC: 9.5% TIVC: 3.4% Rejected: VC: 9.5% TIVC: 3.4%

48 Analysis: Higher Concurrency Under 80% load 48 7% higher job concurrency 28% higher VM utilization Rejected jobs are large 28% higher revenue Charge VMs VM

49 Testbed Experiment Setup – 18 machines Real 30 MapReduce jobs – 10 Sort – 10 Hive Join – 10 Hive Aggre. 49

50 Testbed Result 50 TIVC finishes job faster than VC, Baseline finishes the fastest TIVC finishes job faster than VC, Baseline finishes the fastest Baseline suffers at variability of completion time, TIVC achieves similar performance as VC

51 Conclusion Network reservations in cloud are important – Previous work proposed fixed-BW reservations – However, cloud apps exhibit time-varying BW usage They propose TIVC abstraction – Provides time-varying network reservations – Uses simple pulse functions – Automatically generates model – Efficiently allocates and enforces reservations Proteus shows TIVC benefits both cloud provider and users significantly 51


Download ppt "The Only Constant is Change: Incorporating Time-Varying Bandwidth Reservations in Data Centers Di Xie, Ning Ding, Y. Charlie Hu, Ramana Kompella 1."

Similar presentations


Ads by Google