CN108027805B - Load distribution in a data network - Google Patents

Abstract

Methods and systems for load distribution in a data network are provided. A method for load distribution in a data network may include retrieving network data associated with the data network and service node data associated with one or more service nodes. The method may further include analyzing the retrieved network data and service node data. A service policy may be generated based on the analysis. Upon receiving one or more service requests, the one or more service requests may be distributed among the service nodes according to the service policy.

Description

Load distribution in a data network

Cross Reference to Related Applications

The present application claims priority to U.S. provisional patent application No.61/705,618, filed on 25/9/2012, the disclosure of which is incorporated herein by reference.

Technical Field

The present disclosure relates generally to data processing, and more particularly to load distribution in a Software Driven Network (SDN).

Background

The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Accordingly, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

In a typical load balancing scenario, a Load Balancer (LB) (also referred to herein as an LB appliance) acts as a front-end to a service hosted by a server farm, representing the service as a virtual service to clients. A client that needs the service can use a virtual Internet Protocol (IP) address and a virtual port to address its packets to the virtual service. For example, www.example.com: 80 are services being load balanced and there is a server farm hosting the service. LB may be configured with a virtual IP (vip) (e.g., 100.100.100.1) and a virtual port (VPort) (e.g., port 80) which are in turn mapped to the IP address and port number of the server handling the service. A Domain Name Service (DNS) server handling the domain may be configured to distribute packets to the VIP and Vport associated with this LB.

The LB will examine incoming packets and based on these policies/algorithms will select a particular server from the server farm, modify the packet if necessary, and forward the packet to the server. On the way back from the server (optional), the LB will get the packet, modify it if necessary, and forward it back to the client.

The LB service is usually required to be scaled up or down. For example, LB services may need to be scaled up or down based on the time of day (e.g., day or night, weekday or weekend). For example, fixed interval software updates may result in predictable network congestion, so LB services may need to be scaled up to handle bursty congestion and then scaled down. The popularity of this service may necessitate the need to scale up the service. While the performance characteristics of the LB service may handle the required scaling adjustments, these cases may be handled within the LB.

However, in many cases, it is desirable to increase this performance beyond what a single load balancing device can handle. Typical approaches to this situation include physical rack-based solutions where cards can be inserted and removed to handle these service requirements. These approaches have a number of disadvantages including the need to reserve space, power and price for the rack for future needs. Furthermore, a single chassis can only be scaled up to the maximum capacity of its cards. To eliminate this deficiency, one may attempt to stack LB devices and send traffic between these devices as needed. However, this approach may also have drawbacks such as the link between these devices becoming a bottleneck, increased latency, etc., since each packet must traverse multiple LBs to reach the entity that will eventually process the requests.

Another existing solution is to add multiple LB devices, create separate VIPs on each device for the same server at the back end, and use DNS to distribute the load among the servers. When another LB needs to be added, another entry is added to the DNS database. When an LB needs to be removed, the corresponding entry is removed from the DNS database. However, this method has the following problems. DNS records are cached and thus the addition/removal of LBs can be time consuming before they are valid. This is particularly problematic when removing an LB, as data directed to that LB may be lost. The distribution across the LBs is very coarse and not traffic aware, e.g., one LB may be overwhelmed while other LBs may be idle, some clients may be heavier users but ultimately send requests to the same LB, and so on. The distribution between LBs may not be LB capacity aware, e.g., LB1 may be a much more powerful device than LB 2. Therefore, the existing solutions for solving this problem all have their drawbacks.

SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

The present disclosure relates to a method for load distribution in a data network. In particular, a method for load distribution in a data network may include retrieving network data associated with the data network and service node data associated with one or more service nodes. The method may further include analyzing the retrieved network data and service node data. Based on the analysis, a service policy may be generated. The generated service policies may be provided to devices associated with the data network. Upon receiving one or more service requests, distributing the one or more service requests among the one or more service nodes according to the service policy.

According to another method of the present disclosure, a system for data distribution in a data network is provided. The system may include a cluster master (master). The cluster master may be configured to retrieve and analyze network data associated with the data network and service node data associated with one or more service nodes. Based on the analysis, the cluster master may generate a service policy and provide the generated service policy to devices associated with the data network. The system may further include a traffic classification engine. A traffic classification engine may be configured to receive the service policy from the cluster master. Upon receiving one or more service requests, the traffic classification engine may distribute the service requests among one or more service nodes according to the service policies. Further, the system may include the one or more service nodes. The service node may be configured to receive the service policy from the cluster master and the one or more service requests from the traffic classification engine. The service node may process the one or more service requests according to the service policy.

In another method of the present disclosure, a cluster master may reside in the traffic classification engine layer or the service node layer. Further, a traffic classification engine may in turn reside in the traffic node layer.

In further example embodiments of the present disclosure, the method steps are stored on a machine-readable medium comprising instructions, which when implemented by one or more processors, perform the recited steps. In still other example embodiments, a hardware system or device may be adapted to perform the recited steps. Other features, examples, and embodiments are described below.

Brief Description of Drawings

The embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

fig. 1 illustrates an environment in which methods and systems for service load distribution in a data network may be implemented, according to an example embodiment.

Fig. 2 is a process flow diagram illustrating a method for service load distribution in a data network according to an example embodiment.

Fig. 3 is a block diagram illustrating various modules of a system for service load distribution in a data network, according to an example embodiment.

Fig. 4 is a diagram of service load distribution of a data network, according to an example embodiment.

Fig. 5 illustrates a schematic representation of a computing device of a machine in the example electronic form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.

Detailed Description

The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. These drawings show diagrams in accordance with example embodiments. These example embodiments (also referred to herein as "examples") are described in sufficient detail to enable those skilled in the art to practice the inventive subject matter. These embodiments may be combined, other embodiments may be utilized, or structural, logical, and electrical changes may be made without departing from the scope of what is claimed. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents. The terms "a" and "an" (as is common in the patent documents) are used herein to include one or more than one. Herein, the term "or" is used to refer to a non-exclusive "or" such that "a or B" includes "a but not B", "B but not a" and "a and B", unless otherwise indicated.

The present disclosure relates to an efficient way to achieve load balancing by having LB services and data networks (such as SDN) together used to deliver packets to multiple LBs. Since SDN is aware of the requirements of LB services, it can efficiently distribute traffic to LBs. This approach allows the same virtual service to be hosted on multiple LBs without any DNS changes. There is minimal or no latency impact since packets are delivered directly to the LB processing the packets. Fine-grained distribution of flows to LBs may be achieved based on LB capabilities, network capabilities, and current load. The method also supports scale-up/scale-down on demand services and facilitates management and operation of load balancing for administrators.

In some example embodiments, a protocol may be running between the LB and SDN elements that causes the SDN and LB to exchange information about how traffic is distributed, dynamically inserting forwarding rules to affect packet path selection for devices capable of performing such forwarding. The LB controlled algorithm may be implemented on a router, switch, or other device to affect traffic control.

To ensure distribution of data streams in heterogeneous switch networks from multiple vendors, additional techniques may be used. The techniques may utilize a controller to calculate a path between a source and a destination and program a stream on a network device between the source and the destination. This property can be exploited to intelligently program streams to scale up/down load balancing implementations in a network based on demand, resource availability, and the like.

As LBs are activated and deactivated based on requirements such as, for example, load increases or configuration changes, the LBs may update the controller and cause the controller to make changes to the flows in the network. In an example embodiment, the LB itself may act as a controller and may make changes directly to the flow in the network in the absence of a suitable external controller. Similarly, the controller may work with the LB to inform the LB of network loads and other inputs, health of devices in the network, etc. to assist the LB in making decisions.

The techniques of the embodiments disclosed herein may be implemented using various techniques. For example, the methods described herein may be implemented in software executing on a computer system or in hardware utilizing a combination of microprocessors or other specially designed Application Specific Integrated Circuits (ASICs), programmable logic devices or various combinations thereof. In particular, the methods described herein may be implemented by a series of computer executable instructions residing on a storage medium (such as a hard disk drive) or computer readable medium. It should be noted that the methods disclosed herein may be implemented by a computer (e.g., desktop, tablet, laptop, or server), a game console, a handheld gaming device, a cellular telephone, a smart phone, a smart television system, or the like.

As summarized in the summary, embodiments of the present disclosure are directed to load distribution in an SDN. As referred to herein, an SDN is a network that allows management of network services via abstraction of lower layer functions by decoupling a control plane that makes decisions about where to send a service request (e.g., traffic from a client to a server) from a data plane that is responsible for forwarding the service request to a selected destination based on the decisions of the control plane. The data plane may reside on a network hardware or software device, and the control plane may be executed by software. This separation of planes of the SDN may allow network virtualization since commands or control rules may be executed by software. SDNs may be configured to deliver client service requests or host service requests to virtual machines and physical devices (e.g., servers).

The control plane may be configured to ascertain health and other data associated with the SDN and virtual machines, for example, by a real-time data network applet. The control plane may utilize real-time data network applets and other devices to measure service responsiveness on the virtual machines, monitor overall connections, central processing unit utilization and memory, and network connectivity on the virtual machines, and use this information to influence load distribution decisions and forwarding on the data plane.

Further, the control plane may include a service policy engine configured to analyze the collected health data and convert the health data into a service policy based on the analysis. The service policies may include policies to enhance (i.e., scale up or scale down) the number of virtual machines, traffic classification engines, or backend servers, policies to remedy or repair failed virtual machines, policies to protect virtual machines, policies to introduce new virtual machines, policies to remove virtual machines, and so forth. These service policies may effectively affect load balancing, high availability, and programming SDN networks. Thus, based on these service policies, SDN may scale up or down the use of traffic distribution devices through periodic or dynamic loading and thereby optimize each network resource separately. The traffic distribution device may be scaled up or down based on, for example, the time of day. Furthermore, fixed interval software updates may cause predictable network congestion, and load balancing may need to be scaled up to handle sudden congestion and then scaled down. Furthermore, the popularity of the service may necessitate a need to scale up the service.

SDNs may include controllers that allow programmable control of routing service requests, such as network traffic, without physical access to network switches. In other words, the controller may be configured to control traffic across the network to a server pool or a virtual machine pool. The service policy engine may communicate with the controller and inject the service policy into the controller. The controller, in turn, may control traffic across network devices (such as servers or virtual machines) according to these service policies.

In an example embodiment, a service data plane of the SDN may be configured as an Application Delivery Controller (ADC). The control plane may communicate with the ADCs by managing a set of service policies that map service requests to one or more ADCs. The ADC may then relay the service request to a backend server over a physical or logical network (i.e., through a server pool or virtual machine pool).

Referring now to the drawings, fig. 1 illustrates an environment 100 in which methods and systems for load distribution in an SDN may be implemented. Environment 100 may include a network 110, clients 120, a system 300 for load distribution, and a server 140. Client 120 may include a user or host associated with network 110.

Network 110 may include the internet or any other network capable of communicating data between devices. Suitable networks may include or interface with any one or more of the following: e.g. local intranet, PAN (personal area network), LAN (local area network), WAN (Wide area network)) MAN (metropolitan area network), Virtual Private Network (VPN), Storage Area Network (SAN), frame relay connection, Advanced Intelligent Network (AIN) connection, Synchronous Optical Network (SONET) connection, digital T1, T3, E1, or E3 line, Digital Data Service (DDS) connection, DSL (digital subscriber line) connection, ethernet connection, ISDN (integrated services digital network) line, dial-up port (such as a v.90, v.34, or v.34bis analog modem connection), cable modem, ATM (synchronous transport mode) connection, or FDDI (fiber distributed data interface) or CDDI (copper distributed data interface) connection. Further, the communication may also include a link to any of a variety of wireless networks including WAP (Wireless application protocol), GPRA (general packet radio service), GSM (Global System for Mobile communications), CDMA (code division multiple Access) or TDMA (time division multiple Access), cellular telephone network, GPS (Global positioning System), CDPD (cellular digital packet data), RIM (research and movement Co., Ltd.) duplex paging network, Bluetooth radio, or an IEEE 802.11 based radio frequency network. The network 110 may further include or interface with any one or more of the following: RS-232 serial connection, IEEE-1394 (firewire) connection, fibre channel connection, IrDA (Infrared) port, SCSI (Small computer System interface) connection, USB (Universal Serial bus) connection or other wired or wireless, digital or analog interface or connection, grid or network

And (5) networking. Network 110 may include a network of data processing nodes interconnected for the purpose of data communication. Network 110 may include an SDN. SDN may include one or more of the above network types. In general, the network 110 may include a plurality of similar or dissimilar devices connected together by a transmission medium that allows communication between the devices by using a predefined protocol. Those skilled in the art will recognize that the present disclosure may be implemented within a variety of network configuration environments and on a variety of computing devices.

As shown in fig. 1, client 120 may send a service request 150 to back-end server 140. The server request 150 may include an HTTP request, a video streaming request, a file download request, a transaction request, a conference request, and so forth. Server 140 may include a web server, a wireless application server, an interactive television server, and so forth. The system 200 for load distribution may balance the flow of service requests 150 among traffic forwarding devices of the network 110. The system for load distribution 300 may analyze the flow of service requests 150 and determine which and how many traffic forwarding devices in the network 110 are needed to deliver the service requests 150 to the server 140.

Fig. 2 is a process flow diagram illustrating a method 200 for load distribution in an SDN, according to an example embodiment. Method 200 may be performed by processing logic that may comprise hardware (e.g., decision logic, dedicated logic, programmable logic and microcode), software (such as that run on a general purpose computer system or a dedicated machine), or a combination of both.

The method 200 may begin with receiving network data associated with an SDN at operation 202. In an example embodiment, network data associated with the SDN may indicate health of the SDN, processing unit utilization, total number of connections, memory state, network connectivity, backend server capacity, and so forth. At operation 204, the method may include retrieving service node data associated with one or more service nodes. In an example embodiment, one or more service nodes may include a virtual machine and a physical device. The service node data may indicate the health of the node, dynamic state, node processing unit utilization, node memory state, network connectivity of the service node, responsiveness of one or more service nodes, and so forth.

At operation 206, the retrieved network data and service node data may be analyzed. At operation 208, a service policy may be generated based on the analysis. The service policies may include one or more of the following: service addresses, service node addresses, traffic distribution policies, service node load policies, and the like. The method may further include providing (i.e., pushing) the generated service policy to a device associated with the data network. A device associated with a data network may include a service node and a traffic classification engine.

The method 200 may continue by providing the generated service policy to a device associated with the data network at operation 210. Upon receiving the one or more service requests at operation 212, the one or more service requests may be distributed among the one or more service nodes according to a service policy at operation 214. In an example embodiment, the method 200 may include developing further service policies based on the analysis. Further service policies may be associated with: zoom in, zoom out, remedy, remove services associated with one or more service nodes, introduce new services associated with one or more service nodes, and so on.

In an example embodiment, the method 200 may include performing, by a device associated with a data network, a health check of a backend server. In a further example embodiment, the method 200 may include scaling up or down the service nodes, backend servers, traffic classification engines, and cluster masters in a graceful manner with minimal or no disruption to traffic flows. Further, these services may be scaled up or down in a graceful manner with minimal or no disruption to the traffic flow. In the case of a zoom-in or zoom-out of a service node, the service request may be redirected to one or more other service nodes to continue processing data associated with the service request. In a further example embodiment, method 200 may include optimizing reverse traffic from a back-end server to a service node handling the service.

Fig. 3 shows a block diagram illustrating various modules of an exemplary system 300 for service load distribution in an SDN. System 300 may include a cluster of devices adapted to act as a cluster master. The system 300 may include a cluster master 305 selected from these devices. The cluster master 305 may be configured to track the SDN and retrieve network data associated with the SDN. In an example embodiment, the network data may include one or more of: total number of connections, processing unit utilization, memory state, network connectivity, backend server capacity, and the like. Further, the cluster master 305 may be configured to track service nodes and retrieve service node data associated with one or more service nodes. The service node data may include one or more of: health, dynamic status, responsiveness of one or more service nodes, and the like. In other words, the cluster master 305 can track the health of the network and each service node associated with the system 300. The cluster master 305 may analyze the retrieved network data and service node data. Based on this analysis, the cluster master 305 may generate a service policy. The service policies may include service addresses, service node load policies, traffic distribution policies (also referred to as traffic maps), and so forth. The cluster master 305 may provide the generated service policies to devices associated with the data network (such as service nodes and traffic classification engines).

In an example embodiment, the cluster master 305 may be further configured to develop further service policies based on the analysis. This further policy may be associated with: scale up, scale down, remedy, remove devices (such as service nodes, traffic classification engines, back-end servers, etc.), introduce new service nodes, traffic classification engines, back-end servers, etc.

In an example embodiment, the cluster master 305 may be further configured to facilitate an application programmable interface (not shown) for a network administrator to allow the network administrator to develop further service policies based on the analysis using the retrieved network data and service node data and analysis. This approach may allow application developers to write directly to a network without having to manage or understand the full underlying complexity and subsystems that make up the network.

In a further example embodiment, the cluster master 305 may comprise a backup unit (not shown) configured to replace the cluster master in case of a failure of the cluster master 305.

System 300 may include a traffic classification engine 310. The traffic classification engine 310 may be implemented as one or more software modules, hardware modules, or a combination of hardware and software. Traffic classification engine 310 may include an engine configured to monitor data flows and classify the data flows based on one or more attributes associated with the data flows (e.g., Uniform Resource Locators (URLs), IP addresses, port numbers, etc.). Each resulting data flow class may be specifically designed to implement a particular service for the client. In an example embodiment, the cluster master 305 may send the service policy to the traffic classification engine 310. The traffic classification engine 310 may be configured to receive a service policy from the cluster master 305. Further, the traffic classification engine 310 may be configured to receive one or more incoming service requests 315, such as incoming data traffic from a router or switch (not shown). In general, data traffic may be distributed evenly from a router or switch to each traffic classification engine 310. In an example embodiment, the router may perform simple Equal Cost Multipath (ECMP) routing to distribute traffic evenly to all traffic classification engines 210. The traffic classification engine 310 may distribute one or more service requests among one or more service nodes 320 according to a service policy. Traffic may be distributed to one or more serving nodes 320 in an asymmetric manner. Traffic to service node 320 may be direct or through tunneling (IP-in-IP or other overlay). The traffic classification engine 310 may be stateless or stateful, may act on a per packet basis, and direct each packet of traffic to a corresponding service node 320. When there is a change in service node status, the cluster master 305 may send a new service policy (such as a new traffic map) to the traffic classification engine 310.

System 300 may include one or more service nodes 320. The one or more service nodes 320 may include virtual machines or physical devices that may provide the respective virtual service to which the traffic is directed. The cluster master 305 may send the service policy to the service node 320. Service node 320 may be configured to receive service policies from cluster master 305. Further, service node 320 may receive one or more service requests 315 from traffic classification engine 310 based on the service policy. One or more service nodes 320 may process the received one or more service requests 315 according to the service policy. Processing of the one or more service requests 315 may include forwarding the one or more service requests 315 to one or more back-end destination servers (not shown). Each service node 320 may provide one or more virtual services. The service node 320 may be configured to send service node data to the cluster master 305.

According to a further example embodiment, an existing serving node may redirect packets of an existing flow to another serving node (if the other serving node is the new owner of the flow) based on the redistribution of the flow to the serving node. Furthermore, for situations where the flow state needs to be constrained by the original owner to maintain service continuity, the service node that takes over the flow may redirect packets to the service node that is the original owner of the flow under consideration.

Further, in an example embodiment, the cluster master 305 may periodically health check the service nodes 320 and update these service nodes 320 with service policies (such as traffic maps). When there is a change in the traffic allocation and a packet of data traffic in the flow arrives at serving node 320, serving node 320 may redirect the packet to another serving node. Redirection may be direct or through tunneling (e.g., IP-in-IP (IP-in-IP) or other overlay techniques).

It should be noted that if each device clustered in the network performs a backend server health check, it may result in a large number of health check packets being sent to the individual devices. In view of this, the backend server health check may be performed by several devices in the cluster, and the results may be shared among the remaining devices in the cluster. The health check may include a service check and a connectivity check. The service check may include determining whether the application or backend server is still available. As already mentioned above, not every device in the cluster needs to perform the check. The check may be performed by several devices and the results propagated to the rest of the devices in the cluster. The connectivity check includes determining whether the service node is reachable to the backend server. The path to the back-end server may be service node specific, so the path may not be distributed across service nodes, and each device in the cluster may perform its own check.

In an example embodiment, the system 300 may include an organizer 325. The organizer 325 may be configured to add and remove service nodes 320, traffic classification engines 310, and back-end servers. The organizer 325 may detect the presence of one or more service nodes 320 and transmit data associated with the presence of one or more service nodes 320 to the cluster master 305. Further, the organizer 325 may inform the cluster master 305 of the addition or removal of the service node 320. The organizer 325 may communicate with the cluster master 305 and the service nodes 320 using one or more Application Programming Interfaces (APIs).

In an example embodiment, a centralized or distributed network database may be used and shared among all devices in the cluster of system 300, such as the cluster master, traffic classification engine, and other service nodes. Each device may connect to a network database and update the table according to its role. The relevant database records may be copied to devices that are part of the cluster. The distributed network database may be used to store the configuration and state of the devices, such as data associated with the cluster master, the traffic classification engine, the one or more service nodes, the backend server, and service policy data. The data stored in the distributed network database may include network data and service node data. The distributed network database may include tables with information about service types, resource availability, traffic classifications, network mappings, and the like. The cluster master 305 may be responsible for maintaining this distributed network database and replicating it to the devices. The network database may be copied to the traffic classification engine 310 and the service node 320. In an example embodiment, the network database may replicate data internally across the participating nodes.

In the above-described embodiment, system 300 may include a dedicated cluster master 305, a dedicated traffic classification engine 310, and a dedicated service node 320. In other words, a particular device may be responsible for acting as a cluster master, traffic classification engine, and service node. In further example embodiments, system 300 may not include a dedicated device that acts as a cluster master. In this case, the cluster master functionality may be provided by the traffic classification engine or by the service node. Thus, one of the traffic classification engines or one of the service nodes may act as a cluster master. In the event that a traffic classification engine or service node acting as a cluster master fails, another traffic classification engine or service node may be selected as the cluster master. Traffic classification engines and service nodes that are not selected as cluster masters can be configured as backup cluster masters and synchronized with the current cluster master. In an example embodiment, a cluster master may include multiple active devices that may act as a single master by sharing responsibilities among them.

In a further example embodiment, system 300 may include a dedicated cluster master without a dedicated device acting as a traffic classification engine. In this case, traffic classification may be performed by one of the upstream router or switch. Likewise, the service nodes may distribute traffic among themselves. In an example embodiment, the cluster master and the service node may be configured to act as a traffic classification engine.

In further example embodiments, system 300 may not include dedicated devices that act as cluster masters and traffic classification engines. In this case, one of the service nodes may also act as a cluster master. Traffic classification may be done by an upstream router or switch. The cluster master may program the upstream routers with traffic mapping. Further, the service nodes may distribute traffic among themselves.

It should be noted that adding a new serving node when the load increases and removing a serving node when the load becomes normal can be performed gracefully without impacting existing data traffic and connections. When the serving node appears, traffic distribution may change from being distributed to n serving nodes to (n +1) serving nodes.

When a serving node is about to be removed, traffic to that serving node may be redirected to other serving nodes. For this purpose, a redirection policy associated with the service node to be removed may be created by the cluster master and sent to the traffic distribution engine and/or the service node. Upon receiving the redirection policy, the traffic distribution engine may direct the traffic to another service node.

In an example embodiment, the system 300 may include, for example, a plurality of traffic distribution engines, each of which may provide traffic to a plurality of services. Each traffic distribution engine may communicate with a different set of service nodes. In the event of a failure of one of the traffic distribution engines, another traffic distribution engine may be configured to replace the failed traffic distribution engine and distribute traffic of the failed traffic distribution engine to the corresponding service node. Thus, each traffic distribution engine may include addresses of all service nodes, not just addresses associated with the service nodes currently in communication with the traffic distribution engine.

Fig. 4 illustrates a block diagram 400 for load distribution for SDN. As shown, diagram 400 includes a client 120, such as a computer connected to network 110. Network 110 may include an SDN. The client may send one or more service requests for services provided by one or more servers in the virtual machine/server pool 405. These servers may include web servers, wireless application servers, interactive television servers, and so forth. These service requests may be load balanced by the system for load distribution described above. In other words, service requests of clients 120 may be intelligently distributed among virtual machines or physical server pools 405 of the SDN.

A system for load distribution may include a service control plane 410. The service control plane 410 may include one or more data network applets 415, such as real-time data network applets. Data network applet 415 may check health and other data associated with SDN 110 and virtual machine 405. For example, the data network applet 415 can determine the responsiveness of the virtual machine 405. Further, the data network applet 415 may monitor overall connectivity, central processing unit utilization, memory, network connectivity with the virtual machine 405, and so forth. Thus, the data network applet 415 may retrieve fine-grained integrated information about the SDN and virtual machine service infrastructure.

The retrieved health data may be communicated to the service policy engine 420. In an example embodiment, the cluster master 305 described above may serve as the service policy engine 420. The service policy engine 420 may analyze the health data and, upon such analysis, generate a set of service policies 430 for zooming in/out of services, protecting services, introducing new services, removing services, remediating or repairing failed devices, and so forth. The system for load distribution may further include an organizer (not shown) configured to add more virtual machines as needed. Thus, to deliver a smooth client experience, service requests may be load balanced across virtual machines 405.

Further, service policies 430 may be provided to SDN controller 435. In turn, SDN controller 435 may control service requests (i.e., data traffic) across network devices in the SDN. Effectively, these policies may affect load balancing, high availability, and programming SDN networks to add or remove services.

In general, the described infrastructure may allow a feedback loop between the underlying infrastructure and applications to improve network optimization and application responsiveness by unlocking data associated with the network, service nodes and servers/virtual machines from within the network, transforming the data into relevant information and service policies 430, and then presenting these service policies 430 to an SDN controller 435 for configuring SDN 110.

The service control plane 410 working in conjunction with the controller 435 and the service policy engine 420 may create multiple deployment possibilities that may provide an array of base and advanced load distribution features. In particular, to provide simple load balancing functionality, SDN controller 435 and service control plane 410 may provide some load balancing of their own by leveraging the capabilities of SDN 110, or alternatively work in conjunction with ADC 440 (also referred to as a service data plane included in SDN 110) to optionally provide advanced additional functionality.

In an example embodiment, while the service control plane 410 may be stand alone (i.e., without an ADC), the virtual machine 405, when enlarged, may be programmed with a virtual network protocol (VIP) address relating to the loopback interface of the virtual machine 405. Thus, for data traffic requiring simple service fulfillment, the service control plane 410 may establish simple policies for distributing service requests and instruct the SDN controller 435 to program network devices to distribute the service requests directly to different virtual machines/physical servers 405. This step may be performed over a physical or logical network.

In an example embodiment, when the service control plane 410 may work in conjunction with the ADC 440 to implement more complex ADC functions typically provided by a purpose-built ADC device, the service control plane 410 may manage a set of service policies that map service requests to one or more ADC devices. Service control plane 410 may instruct SDN controller 435 to program the network device so that service requests (i.e., traffic) may reach one or more ADCs 440. The ADC 440 may then relay the service request to a backend server over a physical or logical network.

In the described embodiments, there may be several traffic flow scenarios. In an example embodiment, only forward traffic may travel through the ADC 440. If simple functionality of the ADC 440 is desired (e.g., speed limits, bandwidth limits, scripted policies), forwarding traffic may pass through the ADC 440. The loopback interface on the server may be programmed with the VIP address. Response traffic from virtual machine 405 may bypass the ADC 440.

In a further example embodiment, forward and reverse traffic may pass through the ADC 440. If an ADC 440 is needed that provides higher level functionality (e.g., Transmission Control Protocol (TCP) flow optimization, Secure Socket Layer (SSL) decryption, compression, caching, etc.), the service control plane 410 may need to ensure that both forward and reverse traffic pass through the ADC 440 by appropriately programming the SDN 110.

Fig. 5 shows a schematic representation of a machine in the example electronic form of a computer system 500 within which computer system 500 a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In example embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other devices. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a PC, a tablet PC, a set-top box (STB), a cellular telephone, a portable music player (e.g., a portable hard drive audio device such as a moving picture experts group audio layer 3(MP3) player), a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the singular term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system 500 includes a processor or processors 502 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or both), a main memory 504 and a static memory 506, which communicate with each other via a bus 508. The computer system 500 may further include a video display unit 510 (e.g., a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT)). The computer system 500 may also include an alphanumeric input device 512 (e.g., a keyboard), a cursor control device 514 (e.g., a mouse), a disk drive unit 516, a signal generation device 518 (e.g., a speaker), and a network interface device 520.

The disk drive unit 516 includes a non-transitory computer-readable medium 522 on which is stored one or more sets of instructions and data structures (e.g., instructions 524) embodying or utilized by any one or more of the methodologies or functions described herein. These instructions 524 may also reside, completely or at least partially, within the main memory 504 and/or within the processor 502 during execution thereof by the computer system 500. The main memory 504 and the processor 502 may also constitute machine-readable media.

The instructions 524 may also be transmitted or received over a network 526 using any one of a number of well-known transfer protocols, such as the hypertext transfer protocol (HTTP), via the network interface device 520.

While the computer-readable medium 522 is shown in an example embodiment to be a single medium, the term "computer-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present application, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. Accordingly, the term "computer readable medium" shall be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. Such media may also include, but is not limited to, hard disks, floppy disks, flash memory cards, digital video disks, Random Access Memories (RAMs), Read Only Memories (ROMs), and the like.

The example embodiments described herein may be implemented in an operating environment that includes computer-executable instructions (e.g., software) installed on a computer, in hardware, or in a combination of software and hardware. The computer-executable instructions may be written in a computer programming language or may be embodied in firmware logic. If written in a programming language conforming to a recognized standard, such instructions may be executed on a variety of hardware platforms and for interface to a variety of operating systems. Although not so limited, computer software programs for implementing the methods of the present invention may be written in any number of suitable programming languages, such as, for example, Hypertext markup language (HTML), dynamic HTML, extensible markup language (XML), extensible stylesheet language (XSL), Document Style Semantics and Specification Language (DSSSL), hierarchical stylesheets (CSS), synchronized multimedia integration Semantics (SMIL), Wireless Markup Language (WML), JavaTM, Jini, C + +, Perl, UNIX Shell, Visual Basic or Visual Basic script, Virtual Reality Markup Language (VRML), ColdFusionTM or other compiler, assembler, interpreter, or other computer language or platform.

Accordingly, methods and systems for load distribution in SDN are disclosed. Although the various embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these example embodiments without departing from the broader spirit and scope of the application. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (36)

1. A method for service load distribution in a data network, the method comprising:

generating a service policy for distributing network service requests among a plurality of load balancing devices in the data network, wherein the plurality of load balancing devices comprises a plurality of routers, a plurality of traffic classification engines, and a plurality of service nodes;

providing the service policy to the plurality of load balancing devices associated with the data network;

receiving, by the plurality of routers, one or more service requests;

asymmetrically distributing, by one or more of the plurality of traffic classification engines, the one or more service requests to one or more of the plurality of service nodes according to the service policy; and

distributing, by the plurality of routers, the one or more service requests to one or more back-end servers according to the service policies, wherein the service policies are generated based at least on responsiveness of each of the plurality of service nodes and reachability of the one or more back-end servers to the one or more of the plurality of service nodes.

2. The method of claim 1, further comprising:

retrieving network data associated with the data network;

retrieving service node data associated with one or more service nodes; and

analyzing the network data and the service node data, wherein the service policy is generated based on the analysis of the network data and the service node data.

3. The method of claim 2, further comprising pushing the service policy to the plurality of load balancing devices associated with the data network.

4. The method of claim 2, wherein the network data comprises at least one of: health of the service node, total number of connections, processing unit utilization, memory state, backend server capacity, and network connectivity.

5. The method of claim 2, wherein the serving node data comprises at least one of: dynamic state, node processing unit utilization, node memory state, and responsiveness of each of the plurality of service nodes.

6. The method of claim 2, further comprising developing a further service policy based on the analysis, wherein the further service policy is associated with: zoom in, zoom out, remedy, and remove or introduce one or more new service nodes, traffic classification engines, or back-end servers.

7. The method of claim 1, wherein the data network comprises a Software Driven Network (SDN) comprising at least one of a traffic classification engine, a service node, and an application delivery controller.

8. The method of claim 1, wherein the service policies comprise at least one of traffic distribution policies and service node load policies.

9. The method of claim 2, wherein the plurality of service nodes comprise virtual machines and physical devices.

10. The method of claim 1, further comprising:

facilitating an application programmable interface to a network administrator; and

developing a further service policy based on the analysis, the further service policy being for the network administrator via the application programmable interface.

11. The method of claim 1, further comprising performing, by the plurality of load balancing devices associated with the data network, a health check of the one or more back-end servers.

12. The method of claim 1, further comprising scaling up the plurality of service nodes, the one or more backend servers, the plurality of traffic classification engines, cluster masters, and other devices in the SDN network while reducing disruption to traffic flows.

13. The method of claim 1, further comprising scaling down the plurality of service nodes, the one or more backend servers, the plurality of traffic classification engines, cluster masters, and other devices in the SDN network while reducing disruption to traffic flows.

14. The method of claim 1, further comprising scaling up or scaling down services while reducing disruption to traffic flow.

15. The method of claim 6, wherein the one or more service requests are redirected to one or more of the plurality of service nodes to continue processing data associated with the one or more service requests as the service nodes are scaled up or down.

16. The method of claim 2, further comprising facilitating reverse traffic from a backend server to one or more of the plurality of service nodes.

17. The method of claim 1, further comprising an organizer that:

detecting one or more of the plurality of serving nodes; and

transmitting data associated with one or more of the plurality of service nodes to the cluster master.

18. The method of claim 1, further comprising a network database that:

storing data associated with at least one of a cluster master, the plurality of traffic classification engines, the one or more service nodes, the one or more backend servers, and a service policy; and

allowing sharing of the data between the cluster master, the plurality of traffic classification engines, and the plurality of service nodes.

19. A system for service load distribution in a data network, the system comprising:

a cluster master, the cluster master:

retrieving network data associated with the data network;

retrieving service node data associated with one or more service nodes;

analyzing the network data and the service node data;

generating a service policy for distributing network service requests among a plurality of load balancing devices in the data network based on the analysis, wherein the plurality of load balancing devices comprises a plurality of routers, a plurality of traffic classification engines, and a plurality of service nodes; and

providing the service policy to the plurality of load balancing devices associated with the data network;

the plurality of routers:

receiving one or more service requests; and

uniformly distributing the one or more service requests to one or more traffic classification engines of the plurality of traffic classification engines;

the plurality of traffic classification engines, wherein at least one or more of the plurality of traffic classification engines is configured to:

receiving the service policy;

receiving the one or more service requests from the plurality of routers; and

asymmetrically issuing the one or more service requests to one or more of the plurality of service nodes according to the service policy; and

the plurality of service nodes, wherein at least one or more service nodes of the plurality of service nodes are configured to distribute the one or more service requests to the one or more backend servers according to the service policy;

wherein the service policy is generated based at least on responsiveness of each of the plurality of service nodes and reachability of the one or more back-end servers to the one or more of the plurality of service nodes.

20. The system of claim 19, wherein the plurality of service nodes and the plurality of traffic classification engines act as a cluster master, and wherein the cluster master and the plurality of service nodes act as traffic classification engines.

21. The system of claim 19, further comprising an organizer that:

detecting the one or more of the plurality of serving nodes; and

transmitting data associated with the one or more of the plurality of service nodes to the cluster master.

22. The system of claim 19, further comprising a network database, the network database to:

storing data associated with at least one of the cluster master, the plurality of traffic classification engines, the plurality of service nodes, the one or more back-end servers, and a service policy; and

allowing sharing of the data between the cluster master, the plurality of traffic classification engines, and the plurality of service nodes.

23. The system of claim 22, wherein the stored data comprises the network data and the service node data.

24. The system of claim 19, wherein each of the plurality of service nodes is further configured to send the service node data to the cluster master.

25. The system of claim 19, wherein the network data comprises at least one of a total number of connections, processing unit utilization, memory state, and network connectivity.

26. The system of claim 19, wherein the service node data comprises at least one of a health of the service node, a dynamic state, and a responsiveness of each of the plurality of service nodes.

27. The system of claim 19, wherein the service policies include at least one of service addresses, service node addresses, traffic distribution policies, and service node load policies.

28. The system of claim 19, wherein the cluster master comprises a backup unit configured to replace the cluster master in the event of a failure of the cluster master.

29. The system of claim 19, wherein the cluster master performs at least one of:

developing a further service policy based on the analysis, wherein the further service policy is associated with: scaling down, scaling up, and removing services associated with the plurality of service nodes, or introducing new services associated with the plurality of service nodes; and

facilitating providing an application programmable interface to a network administrator to enable the network administrator to develop further service policies based on the analysis.

30. The system of claim 19, further comprising performing a health check of the one or more back-end servers by the plurality of load balancing devices associated with the data network.

31. The system of claim 19, further comprising scaling up the plurality of service nodes, the one or more backend servers, the plurality of traffic classification engines, cluster masters, and other devices in the SDN network while reducing disruption to traffic flows.

32. The system of claim 19, further comprising scaling down the plurality of service nodes, the one or more backend servers, the plurality of traffic classification engines, cluster masters, and other devices in the SDN network while reducing disruption to traffic flows.

33. The system of claim 19, further comprising scaling up or scaling down services while reducing disruption to traffic flow.

34. The system of claim 29, wherein when a service associated with a service node of the plurality of service nodes is scaled up or down, the one or more service requests are redirected to one or more service nodes of the plurality of service nodes to continue processing data associated with the one or more service requests.

35. The system of claim 19, further comprising facilitating reverse traffic from the one or more back-end servers to the plurality of service nodes.

36. A non-transitory processor-readable medium having instructions stored thereon, which when executed by one or more processors causes the one or more processors to:

retrieving network data associated with a data network;

retrieving service node data associated with a plurality of service nodes;

analyzing the network data and the service node data;

generating a service policy for distributing network service requests among a plurality of load balancing devices in the data network based on the analyzed network data and service node data, wherein the plurality of load balancing devices includes a plurality of routers, a plurality of traffic classification engines, and the plurality of service nodes;

providing the service policy to a plurality of load balancing devices associated with the data network;

receiving, by the plurality of routers, one or more service requests;

distributing, by the plurality of routers, the one or more service requests evenly to one or more traffic classification engines of the plurality of traffic classification engines;

asymmetrically distributing, by one or more of the plurality of traffic classification engines, the one or more service requests to one or more of the plurality of service nodes according to the service policy;

distributing, by one or more of the plurality of service nodes, the one or more service requests to the one or more back-end servers according to the service policy, wherein the service policy is generated based at least on responsiveness of each of the plurality of service nodes and reachability of the one or more back-end servers to one or more of the plurality of service nodes;

developing a first further service policy based on the analysis, wherein the further service policy is associated with: scale up, scale down, remedy, or remove services associated with the plurality of service nodes, and introduce new services associated with the plurality of service nodes;

facilitating providing the application programmable interface to a network administrator;

developing, by the network administrator via the application programmable interface, a second further service policy based on the analysis;

performing, by the plurality of load balancing services associated with the data network, a health check of the one or more back-end servers;

scale up or scale down at least one of the plurality of service nodes, the one or more back-end servers, the plurality of traffic classification engines, and a cluster master while reducing disruption to traffic flows;

scale up or down services while reducing disruption to the traffic flow;

facilitating reverse traffic from the one or more back-end servers to one or more of the plurality of service nodes; and

redirecting the one or more service requests to one or more of the plurality of service nodes to continue processing data associated with the service request when at least one of the plurality of service nodes has been scaled up or down.

Images