A Load Balancing Model based on Load-aware for Distributed Controllers. Fengjun Shang, Wenjuan Gong

Transcription

1 4th International Conference on Machinery, Material and Computing Technology (ICMMCT 2016) A Load Balancing Model baed on Load-aware for Ditributed Controller Fengjun Shang, Wenjuan Gong College of Compute Science and Technology, Chongqing Univerity of Pot and Telecommunication, Chongqing , China Shangfj@cupt.edu.cn Keyword: Software-Defined Networking; Load-aware; Load Balancing; Failure Recovery Abtract. Software-Defined Networking (SDN) i a new paradigm that decouple the control plane from data plane. But with the continuou expanion of the network cale, a ingle controller face with calability iue and may trigger a ingle point of failure. It i important to take into account the calability of the control plane and how to balance the load of multiple controller. In thi paper, we tudy and analyzed the architecture model of multiple controller and then propoed a load balancing model baed on load-aware for ditributed controller which can flexibly adjut the flow-requet handled by each controller baed on the flow-requet, and reolved the ingle point of failure through fat recovery of failure. Introduction Recently with the continuou expanding of network cale and the increaing of network interconnection equipment and clae, traditional Internet face many challenge uch a controllability of management calability of cale and validation of innovative experiment[1]. Software-Defined Networking (SDN) architecture i currently een a one of the mot promiing paradigm where the network control i decoupled from data plane. Control plane i conited of a logically centralized controller which i reponible for making packet forwarding deciion and providing a programmatic interface to the application plane. Data plane, which i reponible for forwarding packet, i compoed of phyical device. In the SDN architecture, the data plane i controlled by the control plane through a well-defined API. SDN ha already ome concrete implementation. OpenFlow [2] i an open tandard protocol, pecifically deigned for the SDN network, that allow the communication between the control and data plane and permit the manipulation of the latter. At the beginning, the OpenFlow protocol wa developed at the Stanford Univerity around 2008 for enabling reearcher to run experimental protocol in the campu network, but now ha received wide attention from academia and indutry. In SDN architecture baed on OpenFlow, the OpenFlow witche end flow-requet to the controller via the OpenFlow protocol over a ecure channel and the controller et packet forwarding rule to witche via a global view of the network. The centralized control function of SDN ha reduced the complexity of network management and configuration, but with the continuou expanding of network cale and increaing demand for ervice, the centralized controller need to deal with maive flow-requet from witche and the calability problem of control plane i becoming more and more eriou [3]. The paper [4] point out that the NOX controller can handle 30K flow every econd and each flow need an average of 10m [5], however the data center including 100 witche can generate 10M flow-requet every econd which exceed the capability of controller [6]. So reearcher ha propoed many architecture model of ditributed controller. In 2010 the paper [3] propoed a ditribution of control plane called HyperFlow. HyperFlow i logically centralized but phyically ditributed. By paively ynchronizing network-wide view of OpenFlow controller, the witch i connected to the nearet controller, thu minimizing the control plane repone time to data plane requet. The paper [7] preent Onix, a ditributed ytem baed on control plane. Control plane written within Onix operate on a global view of the network, and ue The author - Publihed by Atlanti Pre 240

2 baic tate ditribution primitive provided by the platform. Onix provide a general API for control plane implementation, while allowing them to make their own trade-off among conitency, durability, and calability. In 2012, the paper [8] deigned a high calable mechanim named MSDN to balance the data flow initialization requet and then thoe requet were parallel proceed with a hare global network view. In the ame year, Yannan Hu propoed BalanceFlow [9], a controller load balancing architecture for OpenFlow network with by utilizing CONTROLLER X action extenion for OpenFlow witche. The uper controller can flexibly tune the flow-requet handled by each controller, without introducing unacceptable propagation latencie architecture. The Load Balancing Model baed on Load-aware for Ditributed Controller BalanceFlow architecture [9] ued uper controller to run flow-requet partition when controller load imbalance i detected. Once the uper controller ha a fault, the flow-requet partition function would be diable. So to reolve the above problem, we preent the load balancing model baed on load-aware for ditributed controller. In the model, each witch connect with multiple controller but at any moment i controlled by only one controller. And one controller can manage more than one witch. All controller are of the ame performance without uper controller, o the model reolve the problem of ingle point failure, improve the tability of the network; meanwhile we propoe load balancing algorithm baed on load-aware random aignment that enure that the network doe not trigger a larger tilt when partition the flow-requet. Beide in order to detect the failure of the controller, the controller will end heartbeat packet to each other. If a controller do not ent a heartbeat packet in the pecified time, then the other controller deem that the controller ha failed and will immediately run the load balancing algorithm to partition the flow-requet. The architecture model i hown in Fig.1. Fig.1 The Load Balancing Model Baed on Load-aware For Ditributed Controller Load Information Awarene. In the load balancing model preented by thi paper, the load information of the controller i mapped to the average number of flow-requet handled by it. The load information awarene point out that each controller can aware the load tatu autonomouly through calculating the ratio of average number of flow-requet to the total number of flow-requet in the network. And uing the flow-requet baed on witch pair i viable ince the total number of witch pair i uually limited with le torage pace. So every controller maintain an N* N order matrix Qavg which repreent the load information of controller, where N i the number of witche in the network. The element in the ith row, jth column denote the average number of flow-requet from witch i to witch j. When a 241

3 controller receive a flow-requet, it check the detination addre and ource addre and locate the correponding egre witch for that flow and the relevant element in the matrix i updated periodically. The average number of flow-requet from witch i to witch j i calculated uing the following Eq. 1. qavg (, i j) (1 ) qpre(, i j) p(, i j ) (1) Where i a weighted coefficient, qpre(, i j) i the average flow-requet number of previou cycle and p(, i j) i the number of flow-requet from witch i to witch j in a certain cycle. Load Balancing Algorithm baed on Load-aware Random Aignment. Thi paper propoe the load balancing algorithm baed on load-aware random aignment where all controller publih average flow-requet information to each other periodically, calculate the total number of flow-requet. If the average number of flow-requet handled by any controller contribute more than ome threhold of the total flow-requet rate in the network, the controller will aware that the load i imbalanced. Then the controller of load imbalance run the load balancing algorithm which reallocate flow-requet to multiple controller via allocation probability. Related Concept Decription. (1) load degree of witch pair to controller Firtly we uppoe the ditributed controller model ha k controller ( k 2 ), L ( ) i the ratio the average number of flow-requet of controller to the total number of flow-requet Q in the networkr total, calculated by Eq. 2. L ( ) Q / R 1, 2,, k (2) total So when L () exceed the given threhold, controller run the load balancing algorithm. On thi bai, we propoe the concept of the load degree of witch pair to controller L (, i j ), which denote the load of witch pair( i, j ) to controller, uing the Eq. 3. L (, i j) ( Q p(, i j))/ R total i, j 1, 2,, n (3) Where p(, i j) i the flow-requet that i about to be handled by the controller. The algorithm aume that every controller ha ame performance and elect average number of flow-requet and the flow-requet which i about to be handled to meaure the load of witch pair( i, j ) to controller. (2) load weight and load difference We define W (, i j ) a the load weight of witch pair( i, j ) to the controller, uing Eq. 3 to calculate: W ( i, j) (1 ) L( i, j) d( i, ) / d avg i, j 1,2,, n, 1, 2,, k (3) Where i a contant parameter, adjuting the weight between controller load and propagation latencie. When etting too mall, we ignore the benefit of reducing latencie. When etting too large, however, we do not require the load to be balanced. We empirically found that between and 0.15 give a good reult. d avg i the average node-to-controller latencie. Then we define W ( i, j ) a the load difference of witch pair ( i, j ) to the controller, which denote the difference between the um of all load weight of witch pair ( i, j ) to controller and the load weight of witch pair ( i, j ) to the controller, calculated by Eq. 4. k c c 0 W (, i j) W (, i j) W (, i j ) i, j 1,2,, n c 1, 2,, k (4) (3) allocation probability of witch pair to controller We define P ( i, j ) a the allocation probability of witch pair ( i, j ) to the controller. P ( i, j ) denote that the probability of flow-requet from witch pair ( i, j ) allocated to the controller, calculated according to Eq

4 k c c 0 P( i, j) W ( i, j)/ W ( i, j ) 1, 2,, k k 0 P(, i j ) 1 (5) In order to further reduce the probability of the occurrence of tilt in the network when traffic burt, we introduce random probability to divide the flow-requet. Through judging the random number [0, 1] fall on which ection of the allocation probability of witch pair to controller, elect the correponding controller. Procedure of Load Balancing Algorithm baed on Load-aware Random Aignment. After introducing the related concept of algorithm propoed by thi paper, the complete operation proce of load balancing algorithm baed on load-aware random aignment i a follow: 1) Initializing the network tate, divide the witche of the controller management. 2) Setting the controller load imbalance threhold ( 0.1)* k 1. 3) Controller update the repective average flow-requet matrix every cyclet m. 4) Controller end the repective average flow-requet information to each other every cyclet. Calculate L () of each controller. When L (), the controller occur load imbalance, run the load balancing algorithm, then kip to tep 5; when L (), the ditributed controller ytem i in a tate of balancing and kip to tep 3. 5) Calculate allocation probability of witch pair ( i, j ) to the controller, P( i, j ). Then repartition flow-requet from witch pair ( i, j ) to pecified controller according to P ( i, j ) via random probability. Evaluation In order to verify the feaibility of our ditributed controller model, we built an experimental environment. We evaluate our model on Abilene topology, which contain 10 node and 13 link. In our experimental, each witch connect ten hot and three controller (denote a A, B and C for implicity in illutrating) are deployed in the network. We et T m to 10m and T to 1 and the controller load imbalance threhold i calculated according the number of controller. The initial tatu of the network i hown in Fig.1. The default behavior of each witch i to forward it flow-requet to the nearet controller to achieve quick repone, o controller A, B and C will receive the flow-requet from 4, 3 and 3 witche repectively. At time 0 econd, we aume that the network ha been in a baic teady tatu. Each hot tart to end a packet flow to a randomly-choen hot. After that a hot randomly wait between 1 and 10m before ending a new flow. At time 40 econd, we intentionally increae the load of controller A ( by raiing the rate of ending new flow which are handled by controller A). We repeated the tet 20 time, and Fig.2 (a) plot the average load of the three controller over time when all controller are running normally, Fig.2 (b) plot the average load of the three controller over time when ome controller malfunction. Average number of flow-requet to controller Controller A Controller B Controller C Time() Average number of flow-requet to controller Controller A Controller B Controller C Time() (a) All controller are running normally (b) ome controller i broken Fig.2 the average number of flow-requet handled by three controller 243

5 According Fig.2, we can ee, that a the hot tart ending traffic, the average flow-requet received by each controller ramp up, the diviion of load i relatively cloe to the 4:3:3. In Fig.2 (a),after 20 encond, a expected, the load on controller A increae draamatically, and at time 44 econd the load of controller A exceed the controller load imbalance thehold 45%, o controller A run the load balancing algorithm to reallocate the flow-requet. And then the load of each controller i well under imbalance triggering threhold. In Fig.2 (b), at time 40 econd, the controller C i broken, o after 3 cycle of updating, the load balancing i invoked immediately and reallocate flow-requet to controller A and B. Then the load of the ret of controller i well under imbalance triggering threhold. Concluion Thi paper analyze the calability problem of SDN architecture and tudie the architecture model of multiple controller. And then propoe a load balancing model baed on load-aware for ditributed controller which can run the load balancing algorithm to reallocate the load of each controller. Our experiment how that the model can flexibly adjut the load of each controller and ucceed in avoiding the ingle point of failure and guarantee that the function of load balancing algorithm i run normally whether controller ha fault or not. Acknowledgement Thi work wa upported in part by the Chongqing Natural Science Foundation under Grant No.ctc2012jjA40038, the Chongqing Baic and Frontier Reearch Project under Grant No.ctc2013jcyjA40023, the Minitry of Indutry and Information Technology for the pecial funde of Development of the Internet of thing( ) and the Special Foundation for Young Scientit of Chongqing(NO.ctc2014kjrc-qnrc40002). Reference [1]Zhang C K, Yong C, Tang H Y, et al. State-of-the-art urvey on oftware-defined networking (SDN) [J]. Journal of Software, [2] Mckeown N, Anderon T, Balakrihnan H, et al. OpenFlow: Enabling Innovation in Campu Network[J]. Acm Sigcomm Computer Communication Review, 2008, 38(2): [3] Tootoonchian A, Ganjali Y. HyperFlow: a ditributed control plane for OpenFlow[C]// Proceeding of the 2010 internet network management conference on Reearch on enterprie networking. USENIX Aociation, 2010:3-3. [4] Gude N, Koponen T, Pettit J, et al. NOX: Toward an operating ytem for network[j]. Acm Sigcomm Computer Communication Review, 2008, 38(3): [5] Tavakoli A, Caado M, Koponen T, et al. Applying NOX to the Data center[j]. Hotnet, [6] Curti A R, Mogul J C, Tourrilhe J, et al. Devoflow: Scaling flow management for high-performance network[j]. Acm Sigcomm, 2011, 41(4): [7] Koponen T, Caado M, Gude N, et al. Onix: A Ditributed Control Platform for Large-cale Production Network.[J]. Proc Odi, 2010: [8] LIN Pingping, BI Jun, HU Hongyu, JIANG Xiaoke. MSDN:a Mechanim for Scalable Intra-domain Control Plane in SDN[J].Journal of Chinee Computer Sytem,2013,34(9): [9] Hu Y, Wang W, Gong X, et al. BalanceFlow: Controller load balancing for OpenFlow network[c]// Cloud Computing and Intelligent Sytem (CCIS), 2012 IEEE 2nd International Conference on. IEEE, 2012: