Scalable and Crash-Tolerant Load Balancing for OpenFlow Controllers

Scalable and Crash-Tolerant Load Balancing based on Switch Migration for Multiple OpenFlow Controllers Chu LIANG Ryota KAWASHIMA Hiroshi MATSUO Nagoya Institute of Technology, Japan 1/22

Research Background The spread of Software-Defined Networking Easier management and faster innovation A centralized controller and programmable network devices The complication of controller is increasing Load balancing, QoS controlling, Security The size of networks continues to increase The growing number of OpenFlow-enabled devices A centralized controller has a potential bottleneck Distributed control plane has been proposed 2/22

Distributed OpenFlow Controllers OpenFlow : one of the mostly representative protocol for SDN Packet-in : not match any forwarding rule forward to controller OpenFlow Controller OFC 1 OFC 2 OpenFlow controller cluster Packet-in OpenFlow switches Group B Group A physically distributed controllers achieve better scalability 3/22

Problems in Distributed Controllers Load imbalance results in suboptimal performance Topology change Variety user traffic Elastic resources, VMs migration, Variety utilizations OFC 1 OFC 2 OpenFlow controller cluster High loaded Low loaded Static mapping configuration OpenFlow switches Dynamic load balance among the controllers is required Group B Group A 4/22

Problems in OpenFlow Controllers Multiple Controllers in OpenFlow Roles : Master/ Slave/ Equal Master Slave Switch S1 S2 S3 OFC 1 Master OFC 2 Slave OFC1 OFC2 Master Slave Master Slave Each controller only has one role S1 S2 S3 The coordination of role changing is not provided 5/22

Related Work Scalable OpenFlow Controller Redundancy Tackling Local and Global Recoveries Keisuke Kuroki, Nobutaka Matsumoto, Michiaki Hayashi, The Fifth International Conference on Advances in Future Internet. 2013. Proposed a crash-tolerant method based on with multiple controllers of OpenFlow1.3 Do not support load balancing among the controllers Role-Management server can be single point of failure Towards an Elastic Distributed SDN Controller Advait Dixit, Fang Hao, Sarit Mukherjee, T.V. Lakshman, Ramana Kompella, ACM SIGCOMM HotSDN, 2013 Proposed a switch migration protocol according to controller load Be complex and do not support the crash-tolerant for master controller 6/22

Proposed Method Dynamically shift the load across the multiple controllers different controllers can be set master for individual switch switch migration Support the crash-tolerant for controllers distributed architecture automatic failover in the event of a failure JGroups based communication Simplification of the switch management by grouping each controller only manage switches in the same group switch migration is performed in group 7/22

Proposed Architecture Global DB Local controller cluster Local DB Global controller cluster OpenFlow switch Group B Group A Group C 8/22

Global controller cluster Global DB Global controller cluster t Based on the global JGroups channel Share global data tenant information, user data etc. Provide global view of network to upper controller can be considered as a logically centralized controller plane 9/22

Local controller cluster Local controller cluster reduce network delay reduce communicate traffic Synchronize network status switch-controller mapping, link, port Perform controller load scheduling Coordinate switch migration set master/slave role for switches Local DB Dynamically shift the load across the multiple controllers 10/22

Implementation Controller structure (OpenDaylight based) Application Application Distributed Key-Value Store (Infinispan) Event Notification (JGroups) OpenDaylight APIs Collect and calculate controllers load A : Load Monitoring Module A : Load Monitoring Module B : Load Scheduling Module B : Load Scheduling Module Selected master controller C : Switch Migration Module Perform switch migration Link Switch Manger Host Manger Discovery OpenDaylight Core OpenFlow Driver 11/22

A. Load Calculation Coordinator : collecting and computing load information Controller Load : switch metric and server metric the number of active switches, packets requests rate (switch metric ) usage of cpu, memory, network bandwidth (server metric) coordinator OFC1 OFC2 Local Controller Cluster OFC3 OFC4 12/22

B. Load Scheduling When and Which controller should be elected as master The lightest-load controller Which switches should be selected to migrate Dynamic round-trip time feedback based switch selection OFC1 OFC2 Perform Switch Migration OFC3 Controller failover Add new switches 13/22

C. Switch Migration Initial heaviest-load Controller A OpenFlow Switch T Initial lightest-load Controller B Slave for T Master for T Switch T migration Reply Slave for T Master for T 14/22

C. Switch Migration Initial heaviest-load Controller A OpenFlow Switch T Initial lightest-load Controller B Slave for T Master for T Switch T migration Reply Slave for T Master for T Failover time Master for T 15/22

Preliminary evaluation (1/2) The switch migration process The migration process takes about 2ms Initial heaviest-load Controller A OpenFlow Switch T Initial lightest-load Controller B 2ms Slave for T Master for T Switch T migration Reply Slave for T Master for T 16/22

Preliminary evaluation (2/2) The controller failover process The failover process takes about an average of 20ms mostly affected by the failure detection provided by JGroups. Initial heaviest-load Controller A OpenFlow Switch T Initial lightest-load Controller B Slave for T Master for T Failure detection Failover time 20ms 17/18 17/22

Evaluation environment Host 3 Iperf client VM1 Host 1 Host 2 (OFC A) (OFC B) Iperf server VM2 SW 1 SW 2 SW 3 SW 4 SW 5 SW 6 SW 7 SW 8 Host Host Host Host Host Host Host Host (Mininet Network) Host 4 (Traffic Generator) 18/22

Evaluation Three kind of workloads Switch Workload A Workload B Workload C switch 1 2 1000 pps 1000 pps 1000 pps switch 3 4 2000 pps 2000 pps 2000 pps switch 5 6 2000 pps 4000 pps 6000 pps switch 7 8 4000 pps 6000 pps 8000 pps Load Machine specifications Controller Node Traffic Generator Evaluation Node OS Ubuntu-server 12.04 Centos 6.5 64bit Core i5(4 core) CPU Core i5(4 core) Core i7(1 core) Memory 16GB 8GB Network 100Mbps Ethernet OpenFlow Switch - Open vSwtich-1.10.0 19/22

Results : Throughput static : existing ( static switch-controller mapping) proposal : dynamically switch migration 0 5 10 15 20 25 30 35 40 1 0 5 10 15 20 25 30 35 40 1 40 0.9 0.9 0.8 35 0.8 0.7 0.7 Throughput (Mbit/sec) 30 0.6 Load Difference 0.6 OFC A:6 switches OFC B:2 switches OFC A:5 switches OFC B:3 switches 0.5 0.5 25 static OFC A:7 switches OFC B:1 switches proposal 0.4 0.4 20 0.3 0.3 OFC A:6 switches OFC B:2 switches 0.2 0.2 15 Workload A Workload B Workload C 0.1 0.1 0 0 10 0 20 40 60 80 100 120 140 160 180 20/22 Run Time (in sec)

Results : Response Time Response Time: VM OFC B (Ping) 1 0.9 Packets loss cumulative distribution function (CDF) 0.8 0.7 0.6 0.5 0.4 0.3 workload A (static) workload A (proposal) workload B (static) workload B (proposal) workload C (static) workload C (static) workload C (proposal) workload B (proposal) workload B (static) workload A (static) workload A (proposal) workload C (proposal) 0.2 0.1 0 0 5 10 15 20 25 30 35 21/22 Response Time (in msec)

Conclusion & Future Work Conclusion & Future Work Conclusion Proposed a scalable and crash-tolerant load balancing based on switch migration for multiple OpenFlow controllers Enable the controllers coordinate actions to dynamically shift the load across the multiple controllers Improve the throughput and response time of control plane Future Work Optimize of the load scheduling modules Implement a topology aware switch migration algorithms to improve the scalability in the real large scale network Evaluate the performance in vary applications and topologies with more practical traffics 22/22