Server Load Balancing with Path Selection in Virtualized Software Defined Networks

Transcription

1 Volume 114 No , ISSN: (printed version); ISSN: (on-line version) url: ijpam.eu Server Load Balancing with Path Selection in Virtualized Software Defined Networks Nalinadevi K 1 Sriram S 2, Raahul C 2, HarshavardanRaaj 2 and Sangeetha B 2 Department of Computer Science and Engineering Amrita School of Engineering, Coimbatore Amrita Vishwa Vidyapeetham, Amrita University, India. 1 k nalinadevi@cb.amrirta.edu 2 ssriram570, vishnov3, harshavardanb65, bsangee08@gmail.com June 23, 2017 Abstract Network virtualization in a data center network offers a promising solution to address the resource latency demands imposed by load balancing applications. Load balancing traffic in virtualized Software Defined Networks enables us to optimize resource utilization, maximize throughput, minimize response time and avoid overloading of a single resource. In this paper, we have used a network virtualization platform, OpenVirteX, to implement server load balancing algorithms with path selection to achieve minimum latency. Random, round robin, and least connections algorithms are implemented to balance the load on servers. A path selection algorithm to compute the minimum latency path is implemented. The experiments performed on the virtual network show that the least connections algorithm with path selection does efficient server load balancing with minimum latency than the random and round robin server load balancing with path selection. 715

2 AMS Subject Classification: 94C15 Key Words: SDN, load balancing, OpenVirteX, virtualization 1 Introduction In data center networks, Network Virtualization [1]enables network resources such as link bandwidth, topology, hardware devices, and address spaces to be allocated and used efficiently, allowing its tenants to frame cus-tomized network policies, isolate addresses between different virtual networks and manage these resources productively. Network Virtualization (NV) is the logical creation of a network that is decoupled from the underlying hardware. In other words, it is the ability to initiate the hardware platform in a software which permits the service provider to deploy multiple heterogeneous virtual networks on a single hardware. The virtual networks which provide an abstraction of the hardware are used to manage the network services and resources while the physical network is responsible for forward-ing the packets. Therefore, it is more scalable and more cost effective than the traditional hardware used. Software Defined Network (SDN) [2] is a network architecture which provides a global view of the network by separating the control plane, the decision maker, from the data plane consisting of network devices which forward data according to the decisions made by the control plane. In traditional networks, a dedicated hardware is used for load balancing. The specialized hardware is expensive and cannot be customized by network administrators. SDN offers customizability and uses simple, inexpensive computing devices as a controller. The real challenge lies in integrating the network virtualization in SDN architecture. This is achieved using network virtualization platform discussed in [13] which takes the abstraction of physical networks in hardware like switches, network resources and connects them with the controller. With such virtualization platforms, multiple virtual networks can be deployed on a hardware, thus maximizing the resource utilization. Load balancers in traditional networks have dedicated vendor specific hardware which act as resource managers and split the traf- 716

3 fic among the available servers and paths. SDN-NV can have a resource manager that allows multiple network operators to share the underlying physical resource and have a centralized controller for each network operator that implements a load balancing algorithm to maximize the resource utilization. In this paper, we present the implementation of load balancing algorithms in virtual networks using SDN architecture. The load balancing algorithms are implemented as applications in the controller which control the virtual network switches. The server load balancing algorithms are used to provide efficient server utilization by balancing the load across servers. Three server load balancing algorithms: Random, Round-Robin and Least Connections are used to balance the load across servers. Once the server is chosen, the packets are sent along the path which has the least latency - computed using Dijkstras al-gorithm [6]. The significance of this work is the computation of latencies of the links using the Open- Flow [7] message sequence discussed in Section IV. Thus, the path load balancing algorithm in the virtual network ensures mini-mum response time for clients by directing traffic along paths with least latency and the server load balancing algorithms ensure efficient server utilization by directing traffic to a pool of backend servers. The paper has been structured as follows. Section II presents the relevant background, Section III discusses research proposals related to load balancing and virtualization in SDN, Section IV elaborates the algorithms used, Section V presents the system design, Section VI presents the implementation and experimental results, and Section VII concludes the paper. 2 Background 2.1 Software-Defined Networking It is an evolving network technology in which a centralized controller monitors and controls the behavior of the entire network. For fault tolerance, multiple controllers can be used to operate the network, each having its own view of the network. In SDN, network devices predominantly use OpenFlow protocol, a south-bound API, to communicate with the controllers. Flow tables present in the OpenFlow-enabled switches contain all the routing, forwarding 717

4 and other related information. The controller uses this information to forward packets through the network, i.e. when an incoming packet matches the flow table entry, an action is applied, and if there is no match, the packet is directed to the controller which reactively determines if it should insert, update or delete the flow entries in the switchs flow table. 2.2 OpenVirteX (OVX) OVX is a network virtualization platform [13] which virtualizes the underly-ing Software Defined Network. Each virtual SDN can be customized in terms of addressing scheme and topology. It is similar to FlowVisor [10] as it acts as a proxy which sits between the physical network system and the tenant s NOS where each tenant can get the desired topology of their choice by giving a map between the current static topology and their desired virtual network. Virtualized topology can be either the same topology or the subset of the physical topology depending upon the tenants decision as shown in Figure1. [14] Figure 1: OpenVirteXs generic architecture 3 Related Work In the past decade, extensive research work was undertaken to develop load balancing techniques in SDN. For instance, Plug-n-Serve [3] is a load balancing model which deals with a heap of servers as well as the blockage of the network. The response time of web services is reduced by having a control over the load on the servers and networks. It captures three main aspects of the system, namely 718

5 (1) Up-to-date state of the overall system: The load on the servers and the congestion of the network links and switches (2) The average response time for the requests as a time series (3) The effect of dynamically adding or removing servers and network links on response time. It consists of three major components namely (a) Flow Manager - an OpenFlow controller module which uses specific load balancing algorithms to manage and route flow, here, LOBUS algorithm is used, (b) Net Manager - this module is responsible for monitoring and probing the network periodically to obtain link statistics from the switches, (c) Host Manager the load on servers and their state information are monitored here and these particulars are reported to Flow Manager for further processing. In spite of offering high adaptability in adjusting to high traffic requirements, this model has not proposed an architectural extension to virtualized environments. These days, network virtualization and function virtualization are important concepts that havent been incorporated into their architecture. There are very few works that focus on virtualizing the underlying SDN infrastructure. In our architecture, we used a virtualized network in OVX to implement load balancing schemes and thus overcome its shortcoming. In terms of a network virtualization application, FlowVisor is a virtual layer which creates different instances of a virtual network from an underlying physical infrastructure. It acts as an intermediary between the physical hard-ware and the controller. This course of action permits different OpenFlow controllers to operate on the created virtual instances. Its drawback is that it just slices the entire flow space between the tenants. We use OpenVirteX to overcome this shortcoming of FlowVisor. This paper uses latency as a primitive for finding the optimized path to reach the selected server. As a result, it offers less overhead and with OpenVirteX, each tenant will have control over a virtualized network topology with full address space. 4 Algorithm This section elaborates the algorithms used for computing the overall latency of the multiple paths available to the server and chooses the best possible path to the server which is chosen by either ran- 719

6 dom, round robin or least con-nections algorithms. 4.1 Server Selection The three standard server load balancing algorithms used are: 1. Random: client requests are directed to a random server chosen from the configured pool of servers. 2. Round robin: requests made by clients are distributed across a pool of backend servers in a sequential order. 3. Least connections: a new request is directed to the server which currently has the least number of client connections. In this algorithm, the load balancing module decides the appropriate server based on the number of live flows handled by each server. Lesser the number of flows handled by a server, the lesser it is loaded. Thus, the server handling the least number of flows is chosen. 4.2 Link Latency Computation Computing the link latencies is based on the concept specified in floodlight [4] to discover links and check the activeness of network devices [7]. On that basis, the OpenFlow messages and protocols used by the algorithm to compute the latency of each link in the network are: PACKET_IN: A switch sends this message to the controller to enable further processing of the packet received by the switch. PACKET_OUT: The controller uses this message to instruct a switch to transmit a data packet through one or more of its ports. Link Layer Discovery Protocol (LLDP) packets: LLDP packets are sent from one switch to its neighbor to discover a link between them. ECHO_REQUEST and ECHO_REPLY: To ensure connectivity between the controller and the OpenFlow switches, every switch periodically exchanges these messages with the controller. 720

7 4.2.1 Sequence of steps in calculating total Round Trip Time (RTT) for link dis-covery: For illustration, let us take the link discovery process between switches S1 and S2 as shown in Figure2. 1. Initially, the controller C sends a PACKET_OUT message to S1 and instructs it to send LLDP packets to S2. Time taken for this is denoted by t S1. 2. Then, S1 sends an LLDP packet to S2. Time taken for this is denoted by t S1 S2. 3. Once S2 receives the LLDP packet, it sends a PACKET_IN message to C. Time taken for this is denoted by t S2. Figure 2: Overall RTT The link discovery module compares both the PACKET_IN and PACKET_OUT messages and checks if a link exists between S1 and S2. The overall time taken for this process is calculated as TOTAL_RTT (C, S1, S2) represented as equation 1: total RT T t s1 + t S1 S2 + t S2 (1) Calculating RTT between switches and controller: 1. In Figure3, C sends ECHO_REQUEST to S1. Time taken for this event is denoted by t echo req. 2. S1 sends ECHO_REPLY to C. Time taken for this event is denoted by t echo reply. 721

8 Figure 3: Switch Controller RTT The OpenFlow message handler module calculates RTT for a switch-controller connection based on the timestamp of above two events and represents the overall SWITCH_RTT (C, S1) as in equation 2: Assigning links latencies: t S1 t echo req + t echo reply (2) We need to subtract the one way latency of both the switches from the total RTT to obtain the latency between switches S1 and S2 which is represented as LATENCY (S1, S2) in equation 4: Oneway latency SW IT CH RT T S1 + SW IT CH RT T S2 2 (3) Latency S1 S2 T OT AL RT T (S1, S2) Oneway latency (4) 4.3 Path Selection The objective of this algorithm is to choose the path which has minimum latency. Minor modifications are made to Dijkstras algorithm and the link latency between each pair of switches is used as cost of the edges in the modified Dijkstras algorithm. The algorithm then chooses the path with least latency from source switch S1 to destination switch Sn, n hops apart. The overall latency of the chosen path is obtained using equation 5: Latency S1 Sn Latency S1 S2 +Latency S2 S3 + +Latency S(n 1) Sn (5) 722

9 5 System Design 5.1 Topology The implementation uses Mininet [8], a network emulator that supports SDN architecture, for creating the Internet2 Wide Area Network (WAN) on which OVX was deployed. This Internet2 NDDI topology [11] shown in Figure4 consists of 11 core switches and two hosts are attached to each of these core switches. Evaluation is done on the performance of random, round-robin and least connection server selection algorithms in a virtualized instance of this multipath topology and a path with the least latency to the selected server is chosen. Figure 4: Switch Controller RTT 5.2 Floodlight modules The floodlight modules extended and created are: 1. Link discovery: link discovery manager in this module detects links in the topology and obtains the round trip time of LLDP packets. 2. OpenFlow message handler: calculates the latency between the switches and controller using echo messages (Echo Request and Echo Reply) sent from the controller to the switches and vice versa to check if they are alive and connected to each other. 3. Server load balancer: this is an extension of the basic load balancing ser-vice provided by floodlight and it chooses a server from a pool of backend servers using either random, roundrobin or least connections algorithm. 723

10 4. Path selection module: uses an extended version of Dijkstra s algorithm having link latencies as cost and computes a route to the chosen server by selecting a path which has the least latency. 5.3 Architecture The architecture shown in Figure5 consists of 3 major components: 1. The NDDI Internet2 physical topology emulated using Mininet. 2. The switches in the data plane listening to OVX. OVX is used to configure multiple virtual instances of the underlying physical topology. 3. Floodlight sits on top of OVX and implements all the load balancing algorithms and the path selection algorithm on these virtualized network instances. As a result, client requests are load balanced to different backend servers in a virtualized network and the best possible path to the server is chosen. Figure 5: Load balancing architecture 6 Implementation and experimental results In this experiment, two virtual networks are configured, each consisting of 6 switches and 12 hosts. As OVX enables us to have each 724

11 virtual network controlled by its own controller, a controller is assigned for each of these virtual networks. The switches created in Mininet start listening on port 6633 for connecting to OVX. The configuration of the virtual networks is done using OVXs Tenant API [9]. Each virtual network listens to its respective controller on an assigned port number. Floodlight controllers listen on port and port to the virtual networks created using OVX. Then, the aforementioned floodlight mod-ules perform their respective functions on the virtualized instances. By default, floodlight controller uses a Quantum plug-in of OpenStack to configure any desired host in the network as a server via the REST API implemented in floodlight. Floodlights REST service runs on port The REST commands used are shown in Figure6. Figure 6: REST API CALLS All client requests in the virtual network are directed to the Virtual IP The controller then runs the load balancing algorithms to choose the appropriate virtual server and computes a route using the path se-lection algorithm. The experiment is conducted with 6 virtual servers and the LLDP_TO_ALL_INTERVAL and ECHO_REQEST frequency values are set to 20 so as to keep the latency of each link varying every 20 seconds. iperf [12], a network Performance tool, is used to measure the average throughput performance of these servers for the three load balancing algorithms. Figure7 depicts the average throughput of the 6 servers for a time duration of 20 seconds. The virtualized server with least connections was observed to have a higher and stable throughput than the other two over the stipulated time. The average delay taken by the virtual servers for each of the least connections, round robin, and random algorithms is shown in 725

12 Figure 7: Average Server throughput Figure8. As the least connections algorithm takes into consideration the server state, it offered the least latency and responded quickly to the client requests. Figure 8: Average latency in the three algorithms 7 Conclusion This paper showcases the implementation of the load balancing techniques in a virtual network built on the underlying SDN ar- 726

13 chitecture. The load balancer ensures minimum response time and efficient server utilization. Server utilization is achieved by directing traffic to a pool of backend servers using server load balancing algorithms like random, round robin and least connections and the minimum response time is achieved by directing traffic to paths with least latency. This work can further be expanded and integrated with multiple virtual networks and a resource manager could be used to allocate resources and provide customized network services to each of the tenants. Further, mul-tiple network virtualization allows migration from one virtual network to another virtual network when there is a failure. References [1] N. M. M. K. Chowdhury and R. Boutaba, A survey of network virtualization, Computer Networks, 54(5), (2010), [2] B. A. A. Nunes, M. Mendonca, X.-N. Nguyen, K. Obraczka, and T. Turletti, A survey of software-defined networking: past, present, and future of programmable networks, IEEE Communications Surveys Tutorials, 16(3), (2014), [3] N. Handigol, S. Seetharaman, M. Flajslik, N. McKeown, and R. Johari, Plug-n-serve: Load-balancing web traffic using openflow, In: ACM SIGCOMM Demo, (2009). [4] Floodlight controller, Floodlight documentation [online], [Nov. 10, 2015]. [5] Open Networking Foundation, OpenFlow [online]. [Nov. 11, 2015]. [6] Dijkstras Algorithm [online], wiki/dijkstra algorithm [Dec. 14, 2015]. [7] Openflow, OpenFlow Echo Messages [online]. [Dec. 5, 2015]. 727

14 [8] Mininet, Mininet Documentation [online], [Nov. 7, 2015]. [9] OVX, Current API Calls (Methods) [online], [Dec. 11, 2015]. [10] Rob Sherwood, Glen Gibb, Kok-Kiong Yap, Guido Appenzeller, Martin Casado, Nick McKeown, Guru Parulkar, FlowVisor: A Network Virtualization Layer, Technical Report: openflow-tr flowvisor.pdf [11] ONRC Research, Internet2 NDDI Topology [online], [Dec. 12, 2015]. [12] iperf, iperf 3 user documentation [online], [Feb. 20, 2016]. [13] Ali Al-Shabibi, Marc De Leenheer, Ayaka Koshibe, Guru Parulkar, Bill Snow, Matteo Ger-ola, and Elio Salvadori, Open- VirteX: Make Your Virtual SDNs Programmable, In: ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN), Chicago, IL, USA, (2014). [14] OVX Architecture, Network Virtualization [online], [Dec. 15, 2015]. 728

15 729

16 730