Insights into Rule Implementation in Cloud Datacenters

Slide Note

Cloud datacenters utilize rules to manage policies such as access control, rate limiting, and traffic engineering. This study explores the placement of rules considering resource constraints, machine limitations, and competition for resources. It highlights the need for flexible rule placement and future trends in fine-grained rule regulation in datacenters.

aki_871 Follow

Uploaded on Sep 30, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript

vCRIB: Virtual Cloud Rule Information Base Masoud Moshref, Minlan Yu, Abhishek Sharma, Ramesh Govindan HotCloud 2012

Introduction Datacenters use rules to implement management policies Datacenters use rules to implement management policies Datacenters use rules to implement management policies Access control Rate limiting Traffic measurement Traffic engineering Flow fields examples: Src IP / Dst IP Protocol Src Port / Dst Port An action on a hypercube of flow space An actionon a hypercube of flow space Src IP Examples: Deny Dst IP Normal Enqueue R1=Accept SrcIP: 12.0.0.0/8 DstIP: 10.0.0.0/16 R1 2 Introduction Motivation Architecture Evaluation Conclusion

Current Practice Rules are saved on predefined fixed machines Agg2 Agg1 R3 R3 Agg2 Agg1 R4 R4 R0 R0 1 Machines have limited resources ToR1 ToR2 ToR3 ToR1 ToR2 ToR3 R3 R3 R3 R4 R4 R4 R0 R0 R0 2 Datacenters have different resourceconstraints R3 R3 R3 R3 R3 R3 R4 R4 R4 R4 R4 R4 R0 3 R0 R0 R0 R0 R0 Multiple policies may compete for resources 3 Introduction Motivation Architecture Evaluation Conclusion

vCRIB Goal: Flexible Rule Placement Find the best feasible rule placement based on resource constraints Agg2 Agg1 ToR1 ToR2 ToR3 R3 A R4 R0 R3 R3 B C R4 R4 R0 R0 4 Introduction Motivation Architecture Evaluation Conclusion

Future Datacenters will have many fine-grained rules Regulating VM pair communication Access control (CloudPolice) Bandwidth allocation (Seawall) 100K 1M Per flow decision Flow measurement for traffic engineering (MicroTE, Hedera) 10 100M VLAN per server Traffic management (NetLord, Spain) 1M 5 Motivation Introduction Architecture Evaluation Conclusion

Where to place rules? Hypervisors vs. Switches Hypervisor Switch Software, Slow Hardware, Fast Performance Complex rules OpenFlow rules Flexibility External traffic, Aggregate traffic Close to VMs Entry point Limited CPU budget # TCAM entries Resources 6 Motivation Introduction Architecture Evaluation Conclusion

Rule Location Trade-off (Resource vs. Bandwidth Usage) Agg2 Agg1 ToR1 ToR2 ToR3 Storing rules at hypervisor incurs CPU processing overhead 7 Motivation Introduction Architecture Evaluation Conclusion

Rule Location Trade-off (Resource vs. Bandwidth Usage) Agg2 Agg1 ToR1 ToR2 ToR3 Move the rule to ToR switch and forward traffic Saving the rules at hypervisor uses all CPU budget 8 Motivation Introduction Architecture Evaluation Conclusion

Can we reduce Open vSwitch CPU usage? CPU=100% CPU=50% # wildcard patterns 1000000 100000 10000 Rules 1000 CPU usage 100 10 1 # rules 400 600 800 1024 Wildcard Pattern The set of ignore bits in the mask R1=Accept, DstIP: 10.0.0.0/16, SrcIP: 12.0.0.0/8 1111111111111111****************, 11111111************************ Handle same number of new flows with lower CPU budget 9 Motivation Introduction Architecture Evaluation Conclusion

Rule Location Trade-off (Resource vs. Bandwidth Usage) Agg2 Agg1 ToR1 ToR2 ToR3 If rule memory is limited in one switch 10 Motivation Introduction Architecture Evaluation Conclusion

Rule Location Trade-off (Resource vs. Bandwidth Usage) Agg2 Agg1 ToR1 ToR2 ToR3 Can tradeoff bandwidth within the switch fabric, just move the rule to another switch in addition to trading-off bandwidth between hypervisors and switches 11 Motivation Introduction Architecture Evaluation Conclusion

Our Approach: vCRIB, a Virtual Cloud Rule Information Base Proactive rule placement abstraction layer Flexible rule placement at hypervisors and switches Allow operators to define fine-grained rules without worrying about placement Optimize performance given resource constraints Network State Agg2 Agg1 Rules ToR1 ToR2 ToR3 vCRIB R1 R2 R3 R4 12 Architecture Introduction Motivation Evaluation Conclusion

Challenges: Overlapping Rules R1 Agg1 R2 R4 Network State R3 Agg2 Rules ToR1 ToR2 ToR3 vCRIB R1 R2 R3 R4 13 Architecture Introduction Motivation Evaluation Conclusion

Challenges: Overlapping Rules Src IP ToR1 Dst IP R1 R1 R3 R0 R2 R1 R2 R3 R4 R4 14 Architecture Introduction Motivation Evaluation Conclusion

Challenges: Overlapping Rules Partitions rules to reduce overlapping rules dependency R1 R1 R1 R3 R3 R3 R0 R0 R5 R7 R6 R5 R7 R0 R2 R2 R2 ToR1 R8 R8 R6 R4 R4 R4 Splitting rules covering multiple partitions causes inflation 15 Architecture Introduction Motivation Evaluation Conclusion

vCRIB: Partitioning Recursively cut partitions to create a BSP tree Select a cut that balances two partitions creates fewest number of new rules R1 R3 R0 R2 R4 R3 R5 R7 R1 Smaller partitions are more flexible to place match fewer communicating VMs R0 R2 R4 R8 R6 R3 R5 R7 Stop whenever a resource at a node is exhausted R4 16 Architecture Introduction Motivation Evaluation Conclusion

Challenges: Placement Complexity Constraints Functionality Machine resources Goal Minimize traffic overhead Minimize delay Minimize cost of bandwidth usage vs. saved CPU R1 R0 R2 T11 Different partition sizes Different machine capacities Different traffic overhead for each partition location ToR1 T21 T22 R3 R5 R7 T23 T32 T33 R8 R6 Generalized Assignment Problem R4 17 Architecture Introduction Motivation Evaluation Conclusion

vCRIB: 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 18 Architecture Introduction Motivation Evaluation Conclusion

vCRIB Architecture vCRIB Manager Traffic and Topology information Partitions Placement Partitioning R1 R3 R0 R2 R1 R0 R2 ToR1 R4 Rules R3 R5 R7 R1 R0 R2 R3 R5 R7 R4 Rule Placement R8 R6 R8 R6 R3 R5 R7 R4 R4 19 Architecture Introduction Motivation Evaluation Conclusion

Evaluation: Goal Can partitioning algorithm achieve small partitions? Can placement algorithm leverage resource availability to decrease traffic overhead? Configuration 100 VMs per machine 10K flows (10KB) per machine ClassBench rules 1K rule capacity per switches Agg2 Agg1 ToR1 ToR2 ToR3 20 Evaluation Introduction Motivation Architecture Conclusion

Evaluation: Partitioning 4K 8K 16K 32K 1000 Maximum Partition Size 100 10 1 2.5 Hypervisors Rule Capacity (K) 5 7.5 10 Change rule capacity to show the effect of different CPU budgets down as resources increase Maximum size of partitions goes 21 Evaluation Introduction Motivation Architecture Conclusion

Evaluation: Placement R3 R5 R7 Agg2 Agg1 Rnd-4K Agg-4K For each machine select VM addresses from a contiguous IP range 800 Network Traffic (MB) ToR1 ToR2 ToR3 750 700 650 600 550 500 2.5 Hypervisor Rule Capacity (K) 5 7.5 10 No traffic decrease Traffic decreases as resources increase lower traffic overhead Aggregated addresses make Replication 22 Evaluation Introduction Motivation Architecture Conclusion

Conclusion vCRIB 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 Conclusion Introduction Motivation Architecture Evaluation

Future Work Exploit performance model of hypervisors & switches Online Algorithm adjusting to traffic changes Replication in the partitioning and placement algorithm 24 Conclusion Introduction Motivation Architecture Evaluation