v CRIB Virtual Cloud Rule Information Base Masoud
v. CRIB: Virtual Cloud Rule Information Base Masoud Moshref, Minlan Yu, Abhishek Sharma, Ramesh Govindan Hot. Cloud 2012
Introduction Datacenters use rules to to implement management policies • Accessof Anaction on on aa hypercube ofcontrol flow space An flow space Dst IP Src IP Examples: • Deny • Normal R 1 • Enqueue Introduction Motivation • Rate limiting • Traffic measurement • Traffic Flowengineering fields examples: • Src IP / Dst IP R 1=Accept • Protocol § Src. IP: 12. 0. 0. 0/8 Port / Dst Port § Dst. IP: • Src 10. 0/16 Architecture Evaluation 2 Conclusion
Current Practice Rules are saved on predefined fixed machines 1 Machines have limited resources 2 3 Datacenters have different resource constraints Multiple policies may compete for resources Introduction Motivation Architecture Evaluation 3 Conclusion
v. CRIB Goal: Flexible Rule Placement Find the best feasible rule placement based on resource constraints A B Introduction Motivation Architecture C Evaluation 4 Conclusion
Future Datacenters will have many fine-grained rules Regulating VM pair communication • Access control (Cloud. Police) • Bandwidth allocation (Seawall) 100 K – 1 M Per flow decision • Flow measurement for traffic engineering (Micro. TE, Hedera) 10 – 100 M VLAN per server • Traffic management (Net. Lord, Spain) Introduction Motivation Architecture Evaluation 1 M 5 Conclusion
Where to place rules? Hypervisors vs. Switches Hypervisor Switch Performance Software, Slow Hardware, Fast Flexibility Complex rules Open. Flow rules Entry point Close to VMs External traffic, Aggregate traffic Resources Limited CPU budget # TCAM entries Introduction Motivation Architecture Evaluation 6 Conclusion
Rule Location Trade-off (Resource vs. Bandwidth Usage) Storing rules at hypervisor incurs CPU processing overhead Introduction Motivation Architecture Evaluation 7 Conclusion
Rule Location Trade-off (Resource vs. Bandwidth Usage) Move the rules rule to switch and traffic Saving at. To. R hypervisor usesforward all CPU budget Introduction Motivation Architecture Evaluation 8 Conclusion
Can we reduce Open v. Switch CPU usage? CPU=100% CPU=50% # wildcard patterns 1000000 Rules 100000 1000 CPU usage 100 10 1 400 600 800 Wildcard Pattern 1024 # rules The setsame of ignore bits in Handle number of the newmask flows with lower R 1=Accept, Dst. IP: 10. 0/16, Src. IP: 12. 0. 0. 0/8 CPU budget 11111111********, 1111************ Introduction Motivation Architecture Evaluation 9 Conclusion
Rule Location Trade-off (Resource vs. Bandwidth Usage) If rule memory is limited in one switch Introduction Motivation Architecture Evaluation 10 Conclusion
Rule Location Trade-off (Resource vs. Bandwidth Usage) Can tradeoff bandwidth within the switch fabric, just move the rule tobandwidth another switch in addition to trading-off between hypervisors and switches Introduction Motivation Architecture Evaluation 11 Conclusion
Our Approach: v. CRIB, a Virtual Cloud Rule Information Base Flexible Proactive rule placement at hypervisors abstraction andlayer switches Allow operators to define-grained rules without worrying Optimize performance given resource constraints about placement Rules Introduction Motivation Architecture Evaluation 12 Conclusion
Challenges: Overlapping Rules Introduction Motivation Architecture Evaluation 13 Conclusion
Challenges: Overlapping Rules R 3 R 0 R 2 R 1 Dst IP Src IP R 4 Introduction Motivation Architecture Evaluation 14 Conclusion
Challenges: Overlapping Rules Partitions rules to reduce overlapping rules dependency R 8 R 5 R 7 R 6 R 3 R 1 R 0 R 2 R 4 Splitting rules covering multiple partitions causes inflation Introduction Motivation Architecture Evaluation 15 Conclusion
v. CRIB: Partitioning Recursively cut partitions to create a BSP tree Select a cut that • balances two partitions • creates fewest number of new rules R 3 R 4 R 5 R 7 Evaluation R 6 R 8 Architecture R 5 R 7 R 0 R 2 R 3 Motivation R 3 Introduction R 1 Stop whenever a resource at a node is exhausted R 4 R 1 Smaller partitions • are more flexible to place • match fewer communicating VMs R 0 R 2 R 4 16 Conclusion
Challenges: Placement Complexity Constraints • Functionality • Machine resources Goal • Minimize traffic overhead • Minimize delay • Minimize cost of bandwidth usage vs. saved CPU Motivation R 6 R 4 Architecture T 11 T 22 T 23 R 8 Introduction R 5 R 7 R 3 Generalized Assignment Problem R 1 • Different partition sizes • Different machine capacities • Different traffic overhead for each partition location R 0 R 2 T 33 Evaluation 17 Conclusion
v. CRIB: Placement (Branch and Bound) Select the largest unassigned partition Place it on a switch/hypervisor • Capable of handling its rules § Functionality § Resources • Make minimum traffic overhead Introduction Motivation Architecture Evaluation 18 Conclusion
v. CRIB Architecture v. CRIB Manager Partitions Traffic and Topology information Placement Partitioning R 3 R 1 R 0 R 2 R 4 Rules R 1 R 3 R 5 R 7 R 0 R 2 R 4 Architecture R 6 R 8 Motivation R 6 R 8 Introduction R 5 R 7 R 3 Rule Placement R 5 R 7 R 3 R 4 Evaluation 19 Conclusion
Evaluation: Goal Can partitioning algorithm achieve small partitions? Can placement algorithm leverage resource availability to decrease traffic overhead? Configuration • 100 VMs per machine • 10 K flows (10 KB) per machine • Class. Bench rules • 1 K rule capacity per switches Introduction Motivation Architecture Evaluation 20 Conclusion
Evaluation: Partitioning Maximum Partition Size 4 K 8 K 16 K 32 K 1000 10 1 2, 5 5 7, 5 10 Hypervisors Rule Capacity (K) Change rule capacitysize to of show the effect Maximum partitions goes of different budgets down as. CPU resources increase Introduction Motivation Architecture Evaluation 21 Conclusion
Evaluation: Placement Network Traffic (MB) Rnd-4 K R 3 R 5 R 7 Agg-4 K For each machine select VM addresses from a contiguous IP range 800 750 700 650 600 550 500 2, 5 5 7, 5 10 Hypervisor Rule Capacity (K) Traffic decreases as make Aggregated addresses resources increase lower traffic overhead Introduction Motivation Architecture No traffic decrease Replication Evaluation 22 Conclusion
Conclusion v. CRIB provides an abstraction layer for placement of rules in datacenters Places the rules on both hypervisors and switches to achieve the best performance given the resource constraints 23 Introduction Motivation Architecture Evaluation Conclusion
Future Work Exploit performance model of hypervisors & switches Online Algorithm adjusting to traffic changes Replication in the partitioning and placement algorithm 24 Introduction Motivation Architecture Evaluation Conclusion
v. CRIB: Virtual Cloud Rule Information Base Masoud Moshref, Minlan Yu, Abhishek Sharma, Ramesh Govindan Hot. Cloud 2012
- Slides: 25