Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane - Slides
•Download as PPTX, PDF•
1 like•620 views
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (11)
Similar to Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane - Slides
Similar to Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane - Slides (20)
Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane - Slides
- 1. Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane Supervisor: Prof. Francesco Delli Priscoli Tutor: Letterio Zuccaro Candidate: Daniel Gheorghita
- 2. • Co-funded by the European Commission under the Seventh Framework Programme for Research(FP7) • It promotes and supports Network Functions Virtualization(NFV) • Partners: – Universities: Rome, Milan, Zurich – Companies: Intel, HP Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane 2
- 3. 3 Software Defined Networking SDN • Decoupled control logic and forwarding logic • Logically centralized control • Network devices programmability using APIs OpenFlow • The most used standard and southbound API • Install flow entries in all network devices – What to do when a specific packet arrives OVSDB • Management and configuration of network devices Control Plane Data Plane Application Plane API(e.g. OpenFlow) API(e.g. REST) Other Network Device Basic functionalities – Abstraction layer Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane
- 4. 4 Software Defined Network: Example Control Plane Data Plane Packet-in OpenFlow Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane Problem: Asynchronous messages
- 5. 5 Software Defined Network: Example OpenFlow Inconvenience: • overprovisioning Control Plane Data Plane Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane
- 6. Load Balancing Algorithm. Dynamic Assignment 6 • Compute average CPU load of the entire cluster (AVG) • Divide controllers in overloaded and non overloaded • Divide the switches connected to the overloaded controllers in classes of load • “Fill” every non overloaded controller up to AVG – Best fit switches • One cluster controller collects statistics from all controllers about the last interval of time(e.g. 4 sec) – Average CPU load – Number of messages received from every switch Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane The main steps:
- 7. Pagina 7 Load balancing algorithm: Running example Sw8(15 ) Sw6(30 ) Sw9(20 ) Sw10(10 ) 30: Sw3, Sw6 25: Sw7 15: Sw1, Sw2, Sw5 10: Sw446.25 Sw11(10 )Sw1(15 ) Sw2(15 ) Sw5(15 ) 11.25 26.25 Sw3(30 ) Sw7(25 ) Sw4(10 ) C1 Output: {(Sw4, C1, C3), (Sw7, C2, C4)} Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane C2 C3 C4
- 8. Pagina 8 Migration for OpenFlow 1.0 and successive versions Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane Goal: • Avoid losing messages • Avoid duplicated responses Problem: • In OF 1.0 the switch X sends the packet-in messages to both controllers X : A X BA The main steps of the migration algorithm: • Connect X to B and install a migration signaling entry in X • Freeze roles(do not use the distributed cache content for X) • Change cache entry for X • A removes the migration signaling entry from switch X • Both controllers receive the notification and resume the use of the distributed cache • Disconnect X from A Do not reply Do reply X : B
- 9. 9 Why OpenDaylight controller: • Open platform • Developed under the Linux Foundation. • Supported by 44 members. Some of them: Brocade, Cisco, Dell, HP, IBM, Intel, Juniper, Microsoft, Redhat, NEC, vmware, Oracle • Promising future. It aims to support multiple vendor southbound interfaces – In the industry there is not fully agreement about the southbound protocol • Supports clustering and has a distributed cache My contribution in OpenDaylight: • Fairness in the initial (switch : controller) mapping • Dynamic load balancing service • Extended OVSDB Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane Implementation details
- 10. Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane 10 Testing environment Mininet S1 S2 Sn-1 Sn H1 H2 Hn-1 Hn A B Open vSwitch Gigabit Switch A B Mininet
- 11. 11 The benefits of load balancing Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane Packet-in/s (104) w/o load balancing with load balancing 95-percresponsetime(ms) 6 - 2 imbalance
- 12. 12 Conclusion and future works Conclusion: • Designed, implemented(in OpenDaylight) a load balancing and switch migration algorithms • Developed support tools: – a traffic generator application – a network control application – test scripts that measure the performances Future works: • Deal with the failure of switches and controllers Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane
- 13. 13 Thank you for your attention! Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane
- 14. Pagina 14 The benefits of multiple controller. Test scenarios Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane S1 H1 S1 3 H13 S2 H2 S1 2 H12 S1 4 H14 S2 6 H26 S1 5 H15 S2 5 H25 C1 C2 S1 H1 S1 3 H13 S2 H2 S1 2 H12 S1 4 H14 S2 6 H26 S1 5 H15 S2 5 H25 C1 C2 S1 H1 S1 3 H13 S2 H2 S1 2 H12 S1 4 H14 S2 6 H26 S1 5 H15 S2 5 H25 C1 Single: All: Selective:
- 15. Pagina 15 The benefits of multiple controller. Results Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane Packet-in/s (104) 95-percresponsetime(104)ms Single All Selective
- 16. Pagina 16 Tests: Migration timing Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane Averagemigrationtime(ms) All Selective Packet-in/s (104)
- 17. Pagina 17 Migration for OF 1.0 and successive versions Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane X’s Master Contr.Controller BController A Switch X X : A X : {A} X : {A,B} X : BChange map X : {B} X’s controllers
Editor's Notes
- Good morning. My name is … I am goning to present…. My supervisor is professor
- My thesis is part of TNOVA project co-funded by the European Commission under the Seventh Framework Program TNOVA promotes supports the Network Functions Virtualization that make use of SDN architetecture. Some of the partners involved in the proj are Our University, University of Milan, University of Zurich and big companies like HP and Intel
- What is Software Defined Networking? It is an architecture that decouples the control logic and the forwarding logic. Thanks to that a single controller may control multiple network devices, in this way the the control becomes centralized. The network devices are programmed using specific API. On the right side there are the main components of the SDN architecture. The data plane contains all the network devices. The control plane provides basic functionalities and abstracts the undelaying layer. Finally, in the application plane there are the applications that make use of the functionalities provided by the control plane to provide enhanced network serviced. These applications may communicate with the control plane using RESTfull APIs. one of the most used standard and southbound API is OpenFlow. It is mainly used to install flow entries in all network devices. Every entry instructs the device what to do when it receives a data packet. While Openflow ……OVSDB is an example of management protocol that is able to create, remove and configure virtual devices.
- This is an example of use of SDN. All switches may connect to a single controller using OpenFlow. In this example suppose that the host in the red box sends a packet to another host. Suppose that the switch it is connected to does not know what to do with the packet. Hence it encapsulates the packet in a control packet called packet-in and sends it to the controller. This one sends to the some application that wants to receive this kind of asynchronous messages and then that application will answer with a message that requests the install of a entry that will be used for data forwading. We may have a problem because these asynchronous messages are often unpredictable and may overload the controller. For this reason
- We may want to have multiple controllers. A solution could be a static assignment of the switches based on some statistics. However overprovisioning may be need, and a better solution that avoids this is to move one switch(and its generated load) from one controller to another one. For this reason I devise a load balancing algorithm.
- The following will be the main steps of my balancing algorithm. Initially one cluster controller collects statistics from all controllers about the last interval of time(e.g 4 sec). The statistics about one controller include: the average CPU load and the number of messages received from every switch connected to it. Next the algorithms computes the average CPU load of the entire cluster. Using this avg divides the controller in overloaded and non overloaded. After this it divides all switches connected to the overloaded controllers in classes of load. Finally, it fills every non overloaded controller up to the cluster average load with the best switches that fit that space. I used 2 thresholds to minimize the number of migrations . “Threshold minimum transferred load” is used to block the migration of switches that generate a load smaller than the threshold. “Threshold imbalance margin” is used to increase the avg cluster load when the controller are divided in overloaded and non overloaded.
- For a better understanding this is an running example. Here there are 4 controllers. For the sake of simplicity I assume that all controllers have the same computational resources. This is not a requirement since load conversions are not difficult. The blocks inside each controller represent the switches connected to it. The block size and the number between parenthesis indicate the load generated by that switch to its controller. The cluster average load is about 46 and c1 and c2 are the overloaded controllers. The switches connected to them are divided in classes of load: for example in the class 30 there is the sw3 and sw6. In the next step for c3 the algorithm finds the best fit class load. This is 10. Hence sw4 will be moved to c3. In the same way for the lack of c4 25 is the best class and Sw7 will be moved to c4. The output of this algorithm are the migration that have to be executed. For this reason we need a good migration algorithm.
- I propose a migration algorithm for OF 1.0 that is the most diffused version. We want a seamless migration of a switch X from controller A to controller B. This means that we want to avoid message losses and don’t want that the switch receives duplicated responses. X is initially connected to A that is also its master(namely the one that should replay to its packet-in messages). Since we want to migrate X to B, X should connect to B. The problem is that in OpenFlow 1.0 X sends the packet-in to all controllers it is connected to. The default default behavior of the controller is to answer to the request. But this generates duplicated responses. To solve this I used a distributed cache that stores the master controller for every switch. Here the master of X is A. Changing the cache entry is not enough because we may have both losses and duplicates. Here are the main step of my migration algorithm.
- This is the testing environment. I use 3 quad core computers and a gigabit switch. A and B have been used to run OpenDaylight controller and Mininet to emulate a network. Here there is the logical topology. I created an application that generates data packets. It runs on every host. Each data packet triggers a packet-in message that is sent to the controller. In the upper layer there is a controlling application that answers to packet-in messages.
- Here I measured the benefits of load balancing. For the sake of simplicity, every switch sends the same number of packet-in. I choose a 6 – 2 imbalance because this is common. In the test I vary the number of messages and I measure the 95-percentile response time before balancing and after balancing. The black line is the response time before activation and the blue one after activation.
- In a future work I should deal with
- Add a new controller
- Selective ,all