WO2014114119A1

WO2014114119A1 - Redundant server operation by a software defined network controller

Info

Publication number: WO2014114119A1
Application number: PCT/CN2013/086066
Authority: WO
Inventors: Yonggang Zeng
Original assignee: Hangzhou H3C Technologies Co., Ltd.
Priority date: 2013-01-23
Filing date: 2013-10-28
Publication date: 2014-07-31
Also published as: CN103944746A; CN103944746B

Abstract

According to an example, in a method for redundant server operation by a software defined network (SDN) controller, a processor implementing the SDN controller may determine whether a current active server in a cluster of servers is communicating over a network properly, in which the servers in the cluster of servers are to provide redundant server operations with respect to each other on the network. In addition, in response to a determination that the current active server is not communicating over the network properly, selecting, by the processor, another server in the cluster of servers to be a next active server, closing a connection of the current active server to the network, and opening the connection of the selected another server to the network.

Description

REDUNDANT SERVER OPERATION BY A SOFTWARE DEFINED NETWORK

CONTROLLER

BACKGROUND

[0001] Servers, particularly servers that perform operations requiring high availability, are known to be implemented in a redundant manner. That is, a plurality of servers that are to perform similar server operations with respect to each other are implemented in a network, in which one of the servers is a currently active server and another server is a backup server. In addition, if the currently active server fails or is otherwise unable to perform the server operations, the backup server takes over the functionalities of failed currently active server and becomes the currently active server. Typically, the switchover from the failed active server to the backup server occurs as quickly as possible to substantially minimize disruptions in the performance of the server operations.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Features of the present disclosure are illustrated by way of example and not limited in the following figure(s), in which like numerals indicate like elements, in which:

[0003] FIG. 1 is a simplified diagram of a network, according to an example of the present disclosure;

[0004] FIG. 2 is a simplified block diagram of a computing device containing the SDN controller depicted in FIG. 1 , according to an example of the present disclosure;

[0005] FIGS. 3 and 4, respectively, are flow diagrams of methods for redundant server operation by a SDN controller, according to two examples of the present disclosure;

[0006] FIG. 5 is a flow diagram of a method for controlling an operational status of a server, according to an example of the present disclosure; and

[0007] FIG. 6 is schematic representation of a computing device, which may be employed to perform various functions of the computing device depicted in FIG. 2, according to an example of the present disclosure.

DETAILED DESCRIPTION

[0008] For simplicity and illustrative purposes, the present disclosure is described by referring mainly to an example thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be readily apparent however, that the present disclosure may be practiced without limitation to these specific details. In other instances, some methods and structures have not been described in detail so as not to unnecessarily obscure the present disclosure. As used herein, the term "includes" means includes but not limited to, the term "including" means including but not limited to. The term "based on" means based at least in part on.

[0009] Disclosed herein are methods and apparatuses for redundant server operation by a software defined network (SDN) controller. In the methods and apparatuses disclosed herein, the SDN controller may determine whether a current active server in a cluster of servers is communicating over a network properly, in which the servers in the cluster of servers are to provide redundant server operations with respect to each other on the network. In addition, in response to a determination that the current active server is not communicating over the network properly, the SDN controller may select another server in the cluster of servers to be a next active server. The SDN controller may also close a connection of the current active server to the network and may open the connection of the selected another server to the network. In response to a determination that the current active server is communicating over the network properly, the SDN controller may maintain the current active server.

[0010] According to an example, the methods and apparatuses disclosed herein enable for redundant operation of the servers in the cluster of servers by the SDN controller. In one regard, the methods and apparatuses disclosed herein may not rely upon the redundant servers themselves to correctly determine whether the current active server is communicating properly over a network and to switchover to a backup server if the current active server is not communicating properly over the network. That is, for instance, if there is a problem in a component other than the currently active server that prevents or disrupts communications to and/or from the current active server, the current active server may not be aware that a problem exists. As discussed herein, however, the SDN controller, which is separate from the servers in the cluster of servers and operates under the software-defined networking approach, may make a determination as to whether communications with the current active server are not functioning properly and may thus determine that a problem exists in the communications network of the active server, even in instances where the problem lies outside of the current active server. As such, for instance, the methods and apparatuses disclosed herein allow for redundant server operations to be provided in a manner that may generally be more stable than conventional techniques for providing redundant server operations, which rely upon the current active server itself to determine whether to switch to a backup server.

[0011] Through implementation of the SDN controller disclosed herein, therefore, disruptions in the performance of services provided by the servers in a cluster of servers caused by network connection and/or other errors may substantially be minimized. In addition, because the SDN controller may operate under SDN, the SDN controller may deploy network services relatively quickly and more efficiently than techniques that require hardware deployment of services.

[0012] With reference first to FIG. 1 , there is shown a simplified diagram of a network 100, according to an example. It should be understood that the network 100 depicted in FIG. 1 may include additional elements and that some of the elements depicted therein may be removed and/or modified without departing from a scope of the network 100.

[0013] The network 100 in FIG. 1 is depicted as including a SDN controller 1 10, a network switch 120, a plurality of SDN switches 130a-130n, and a plurality of servers 140a-140m. The SDN switches 130a-130n are also depicted as each including a respective port 132a-132n to which a respective server 140a-140m is connected. The variables "n" and "m" may each represent an integer greater than 1 and need not be equal to each other. The SDN controller 1 10 may communicate with each of the servers 140a-140m through the switch 120 and at least one of the SDN switches 130a-130n. In addition, the SDN controller 1 10 may communicate with a server 140a through multiple SDN switches 130a-130n. In this regard, multiple ones of the SDN switches 130a-130n may be in communication with each other, i.e., some or all of the SDN switches 130a-130n may have forwarding links among each other. Moreover, the network switch 120 may be connected to the servers 140a-140m through respective connections, as indicated by the dashed lines. Thus, for instance, the SDN controller 1 10 may communicate with the servers 140a-140m through any of a number of connections.

[0014] According to an example, the SDN controller 1 10 supports the OpenFlow protocol, which gives access to the forwarding plane of a network switch or router over a network, and is managed by the Open Networking Foundation, and may thus be construed as being an OpenFlow controller. The SDN switches 130a-130n may also support the OpenFlow protocol and communications between the SDN controller 1 10 and the SDN switches 130a-130n may comply with OpenFlow standards. Generally speaking, SDN allows network services to be managed through abstraction of lower level functionality, for instance, by decoupling the system that makes decisions about where traffic is sent, i.e., the control plane, from the underlying systems that forward the traffic, i.e., the data plane. In one regard, the OpenFlow protocol provides a method for the control plane to communicate with the data plane. In the present disclosure, the SDN controller 1 10 may communicate with the SDN switches 130a-130n through implementation of the OpenFlow protocol. It should, however, be clearly understood that the SDN controller disclosed herein need not be limited to implementation of the OpenFlow protocol and may thus communicate with the SDN switches 130a-130n through implementation of other suitable protocols that enable communications between the SDN controller 1 10 and the SDN switches 130a-130n.

[0015] Each of the SDN switches 130a-130n may be connected to the SDN controller 1 10 through an independent channel, e.g., an OpenFlow management channel. In addition, the SDN switches 130a-130n may, upon receiving messages, report the messages to the SDN controller 1 10 and the SDN controller 1 10 may communicate instructions to the SDN switches 130a-130n as to how the SDN switches 130a-130n are to process the messages. Particularly, the SDN controller 1 10 may perform computations on the messages to determine how the SDN switches 130a-130n are to handle the messages. For instance, the SDN controller 1 10 may perform the computations to determine whether the SDN switches 130a-130n are to discard a message, limit the communication of a message, send a message via a particular port, etc. [0016] The network switch 120 may be a computer networking device that links different devices in a network together and may process and route data in the network 100. According to an example, the network switch 120 operates under Ethernet standards. The SDN switches 130a-130n may also be computer networking devices that operate under Ethernet standards.

[0017] The servers 140a-140m may each be machine readable instructions stored on a computer readable storage medium and/or a hardware device storing the machine readable instructions. In addition, each of the servers 140a-140m, or the devices on which the servers 140a-140m are stored, may be connected to a respective SDN switch 130a-130n through a respective port 132a-132n of the SDN switches 130a-130n. In addition or alternatively, multiple ones of the servers 140a-140m may be connected to respective ports on a common SDN switch 130a. Although not shown, each of the servers 140a-140m may be implemented by a respective hardware processor.

[0018] As discussed in greater detail herein below, the servers 140a-140m may be part of a cluster of servers 150 that are to provide redundant server operations on the network 100 with respect to each other. That is, each of the servers 140a-140m may include the same or similar sets of instructions to provide the same or similar computing services to client devices. In addition, at any given time, one of the servers 140a-140m in the cluster of servers 150 may be selected to perform the server operations for the client devices. The selected server 140a may be considered to be a current active server and the remaining servers 140b-140m may be considered to be backup servers. Thus, for instance, if the current active server 140a fails or is otherwise unable to perform the server operations in the network 100, the current active server 140a may be removed from operating as the current active server and another one of the servers 140b-140m may be promoted to perform the server operations in the network 100.

[0019] According to an example, the SDN controller 1 10 may select one of the servers 140a-140m to operate as the current active server. The SDN controller 1 10 may also determine whether the server 140a-140m selected to operate as the current active server is operating properly. The SDN controller 1 10 may further select another server to operate as the current active server in response to a determination by the SDN controller 1 10 that the currently active server is not communicating over the network properly. As discussed in greater detail below, the SDN controller 1 10 may also control the connections to the servers 140a-140m to control which of the servers 140a-140m is the current active server.

[0020] Turning now to FIG. 2, there is shown a simplified block diagram 200 of a computing device 202 containing the SDN controller 1 10 depicted in FIG. 1 , according to an example. It should be understood that the computing device 202 depicted in FIG. 2 may include additional elements and that some of the elements depicted therein may be removed and/or modified without departing from a scope of the computing device 202 containing the SDN controller 1 10.

[0021] As shown in FIG. 2, the computing device 202 is depicted as including the SDN controller 1 10, a processor 210, an input/output interface 212, and a data store 214. The SDN controller 1 10 is also depicted as including a server cluster establishing module 220, an access port position tracking module 222, an active server selecting module 224, a connection opening/closing module 226, a message sending/receiving module 228, and a server status determining module 230.

[0022] The processor 210, which may be a microprocessor, a micro-controller, an application specific integrated circuit (ASIC), or the like, is to perform various processing functions in the computing device 202. One of the processing functions may include invoking or implementing the modules 220-230 of the SDN controller 1 10 as discussed in greater detail herein below. According to an example, the SDN controller 1 10 is a hardware device, such as, a circuit or multiple circuits arranged on a board. In this example, the modules 220-230 may be circuit components or individual circuits.

[0023] According to another example, the SDN controller 1 10 is a hardware device, for instance, a volatile or non-volatile memory, such as dynamic random access memory (DRAM), electrically erasable programmable read-only memory (EEPROM), magnetoresistive random access memory (MRAM), memristor, flash memory, floppy disk, a compact disc read only memory (CD-ROM), a digital video disc read only memory (DVD-ROM), or other optical or magnetic media, and the like, on which software may be stored. In this example, the modules 220-230 may be software modules, e.g., sets of machine readable instructions, stored in the SDN controller 1 10. According to a further example, the modules 220-230 may be a combination of hardware and software modules.

[0024] The processor 210 may store data in the data store 214 and may use the data in implementing the modules 220-230. The data store 214 may be volatile and/or non-volatile memory, such as DRAM, EEPROM, MRAM, phase change RAM (PCRAM), memristor, flash memory, and the like. In addition, or alternatively, the data store 214 may be a device that may read from and write to a removable media, such as, a floppy disk, a CD-ROM, a DVD-ROM, or other optical or magnetic media.

[0025] The input/output interface 212 may include hardware and/or software to enable the processor 210 to communicate with devices in the network 100 (FIG. 1 ), such as the network switch 120, through a wired and/or wireless connection. The input/output interface 212 may also include hardware and/or software to enable the processor 210 to communicate with various input and/or output devices (not shown), such as a keyboard, a mouse, a display, etc., through which a user may input instructions into the computing device 202 and may view outputs from the computing device 202.

[0026] Various manners in which the SDN controller 1 10 in general, and the modules 220-230 in particular, may be implemented are discussed in greater detail with respect to the methods 300 and 400 depicted in FIGS. 3 and 4 respectively. Particularly, FIGS. 3 and 4, respectively, depict flow diagrams of methods 300 and 400 for redundant server operation by a SDN controller 1 10, according to two examples. It should be apparent to those of ordinary skill in the art that the methods 300 and 400 represent generalized illustrations and that other operations may be added or existing operations may be removed, modified or rearranged without departing from the scopes of the methods 300 and 400. Generally speaking, the SDN controller 1 10 may implement the methods 300 and 400 in the network 100 depicted in FIG. 1 . Particularly, for instance, the processor 210, which may implement or execute the modules 220-230 of the SDN controller 1 10 may implement or execute the methods 300 and 400.

[0027] With reference first to FIG. 3, at block 302, the SDN controller 1 10 may start the method 300. The SDN controller 1 10 may start the method 300 in response to receipt of a manual instruction from a user or may automatically start the method 300 at a predetermined time. In addition, prior to implementing the method 300, the SDN controller 1 10 may perform additional operations as discussed in greater detail herein below with respect to the method 400 depicted in FIG. 4.

[0028] At block 304, the SDN controller 1 10, and more particularly, the server status determining module 230, may determine whether a current active server 140a in a cluster of servers 150 is communicating over the network 100 properly. That is, the server status determining module 230 may determine whether the current active server is properly sending and receiving data over the network 100. In one regard, the current active server 140a may be unable to properly send and receive data over the network 100 if there is a failure in the current active server 140a, if there is a failure in the SDN switch 130a or access port 132a to which the current active server 140a is connected, if there is a failure in a connection between the SDN controller 1 10 and the current active server 140a, etc. Various manners in which the server status determining module 230 may make this determination are discussed in greater detail herein below with respect to the method 400.

[0029] At block 306, in response to a determination that the current active server 140a is not communicating over the network 100 properly, the SDN controller 1 10 may select another server 140b in the cluster of servers 150 to be a next active server, may close a connection of the current active server 140a to the network 100, and may open a connection of the selected another server 140b to the network 100. Particularly, for instance, the active server selecting module 224 of the SDN controller 1 10 may select one of the servers 140b-140m other than the current active server 140a to be the next active server. The active server selecting module 224 may select the another server to be the next active server through any suitable selection technique. For instance, the active server selecting module 224 may select the another server in a round robin fashion, randomly, based upon a unique identification of the servers, etc.

[0030] In addition, the connection opening/closing module 226 may close the connection of the current active server 140a to the network 100. That is, for instance, the connection opening/closing module 226 may instruct the SDN switch 130a to close the access port 132a to which the current active server 140a is connected. Moreover, the connection opening/closing module 226 may open the connection of the next active server 140b to the network 100. That is, for instance, the connection opening/closing module 226 may instruct the SDN switch 130b to which the next active server 140b is connected to open the connection through the access port 132b.

[0031] Following block 306, the SDN controller 1 10 may determine whether the next active server 140b, which is now the current active server, is communicating over the network 100 properly at block 304. In response to a determination that the current active server 140b is not communicating over the network 100 properly, the SDN controller 1 10 may select another server 140c to be the next active server as indicated at block 306. The SDN controller 1 10 may also close the connection of the current active server 140b to the network 100 and may open the connection of the selected another server 140c to the network 100, as also indicated at block 306.

[0032] However, at block 304, in response to a determination that a current active server is communicating properly over the network 100, the SDN controller 1 10 may maintain the connection of the current active server 140a to the network 100, as indicated at block 308. In addition, the SDN controller 1 10 may iterate through blocks 304-308 in a continuous and/or periodic manner to change the active server if the SDN controller 1 10 determines that a currently selected active server is not communicating properly over the network 100. That is, the SDN controller 1 10 may cause a backup server to become active in response to a determination that the currently active server is not communicating properly over the network to thus prevent or reduce disruptions due to the failure in the communication of the active server.

[0033] Turning now to FIG. 4, at block 402, the server cluster establishing module 220 of the SDN controller 1 10 may establish a cluster of servers 150 in a network 100, in which the servers 140a-140m in the cluster of servers 150 are to provide redundant server operations with respect to each other in the network 100. The server cluster establishing module 220 may establish the cluster of servers 150 in any of a variety of ways. For instance, the server cluster establishing module 220 may access previously stored information pertaining to the identification of the servers 140a-140m that are to be included in the cluster of servers 150. As another example, the server cluster establishing module 220 may identify a feature, such as an identification, of each of the servers 140a-140m and may determine that the servers 140a-140m either belong or do not belong in the cluster of servers 150 based upon the identified feature. That is, for instance, the server cluster establishing module 220 may compare the features of the servers 140a-140m with previously stored information that indicates which of the servers 140a-140m are to be included in the cluster of servers 150.

[0034] The server cluster establishing module 220 may also store the identifications of each of the servers 140a-140m in the cluster of servers 150, for instance, in the data store 214. In addition, the server cluster establishing module 220 may select a virtual Internet Protocol (IP) address for the cluster of servers 150, which may be used as the IP address for each of the servers 140a-140m in the cluster of servers 150.

[0035] At block 404, the access port position tracking module 222 of the SDN controller 1 10 may track the access ports 132a-132n to which each of the servers 140a-140m in the cluster of servers 150 is connected. That is, the access port position tracking module 222 may determine which of the access ports 132a-132n in which of the SDN switches 130a-130n each of the servers 140a-140m in the cluster of servers 150 is connected. According to an example, the access port position tracking module 222 may determine which SDN switch 130a-130n each of the servers 140a-140m accesses by broadcasting a ping message to the servers 140a-140m in the cluster of servers 150, receiving ping messages from the servers 140a-140m, and analyzing the access port information contained in the received ping messages. In addition, the access port position tracking module 222 may store that access port positions in the data store 214.

[0036] At block 406, the active server selecting module 224 of the SDN controller 1 10 may select one of the servers 140a in the cluster of servers 150 to be a current active server. As discussed above, the active server selecting module 224 may select the server 140a through implementation of any suitable selection technique.

[0037] As discussed above, the servers 140a-140m in the cluster of servers 150 may provide redundant server operations with respect to each other on the network 100. That is, for instance, the servers 140a-140m in the cluster of servers 150 may perform the same or similar functions with respect to each other such that, in the event one of the servers malfunctions or operates improperly, another one of the servers may take over the functions of the improperly functioning server. Generally speaking, the server 140a of the cluster of servers 150 selected to be the current active server may operate as a master or principal server and the other servers 140b-140m may operate as backup servers to the current active server. That is, the current active server 140a may provide services to client devices while the other servers 140b-140m provide a backup function to the current active server 140a.

[0038] At bock 408, the connection opening/closing module 226 of the SDN controller 1 10 may disconnect from a network 100, the servers 140b-140m in the cluster of servers 150 other than the current active server 140a. The connection opening/closing module 226 may disconnect the servers 140b-140m in the cluster of servers 150 other than the current active server 140a through a communication of instructions to the SDN switches 130a-130m to which the servers 140b-140m are connected to close the access ports 132b-132n to which those servers 140b-140m are connected. As such, the SDN controller 1 10 may maintain the connection of the current active server 140a to the network 100 through the access port 132a in the SDN switch 130a.

[0039] At block 410, the message sending/receiving module 228 of the SDN controller 1 10 may send a status checking message to the current active server 140a. The status checking message may be a heartbeat message to test whether the current active server 140a is communicating over the network 100 properly. That is, the status checking message, if properly received by the current active server 140a, may cause the current active server 140a to send a response message back to the SDN controller 1 10.

[0040] At block 412, the server status determining module 230 of the SDN controller 1 10 may determine whether the current active server 140a is communicating over the network 100 properly. That is, the server status determining module 230 may determine that the current active server 140a is communicating over the network 100 properly if the SDN controller 1 10 receives a responding message back from the current active server 140a within a predetermined amount of time, e.g., a few miliseconds or seconds. Alternatively, the server status determining module 230 may determine that the current active server 140a is not communicating over the network 100 properly if the SDN controller 1 10 does not receive a responding message back from the current active server 140a within the predetermined amount of time.

[0041] In response to a determination that the current active server 140a is not communicating over the network 100 properly, the SDN controller 1 10 may select another server 140b in the cluster of servers 150 to be a next active server, may close a connection of the current active server 140a to the network 100, and may open a connection of the selected another server 140b to the network 100, as indicated at block 414. Particularly, for instance, the active server selecting module 224 of the SDN controller 1 10 may select one of the servers 140b-140m other than the current active server 140a to be the next active server as discussed above.

[0042] The connection opening/closing module 226 may close the connection of the current active server 140a to the network 100. That is, for instance, the connection opening/closing module 226 may instruct the SDN switch 130a to close the access port 132a to which the current active server 140a is connected. Moreover, the connection opening/closing module 226 may open the connection of the next active server 140b to the network 100. That is, for instance, the connection opening/closing module 226 may instruct the SDN switch 130b to which the next active server 140b is connected to open the connection through the access port 132b.

[0043] Each of the servers 140a-140m may be connected to the SDN controller 1 10 through a data forwarding channel and a management channel. In one example, the current active server 140a may be unable to communicate data properly over the data forwarding channel but may be able to communicate data properly over the management channel. In this example, the current active server 140a may continue to receive the status checking messages over the management channel. The SDN controller 1 10 may still determine that the current active server 140a is not communicating properly by sensing an abnormality of the data channel of the current active server through polling or receiving interface Down events. In this case, if the current active server 140a does not have other data forwarding channels, the access interface of the current active server 140a may be closed and a backup server may be selected from the cluster of servers 150. In addition, an access interface of the selected backup server may be opened and the SDN controller 1 10 may send a status checking message to the selected backup server. In response to receipt of the status checking message, the selected backup server may begin operating as the current active server.

[0044] In another example, the current active server 140a may be unable to communicate data properly over the management channel and thus, communication of the status checking messages may be interrupted. In this example, the SDN controller 1 10 may detect the abnormal state of the management channel between the SDN controller 1 10 and the current active server 140a through any of the following techniques. In a first technique, the SDN controller 1 10 may determine that the management channel between the SDN controller 1 10 and the current active server 140a is abnormal if the SDN controller 1 10 does not receive a status checking message (e.g., heartbeat message) from the current active server 140a. In a second technique, the SDN controller 1 10 may be directly connected to an interface DOWN TRAP of a common switch via a SDN switch 130a and, if the SDN controller 1 10 receives the DOWN TRAP of a port, the SDN controller 1 10 may determine that the management channel between the SDN switch 130a that is directly connected to the port and the SDN controller 1 10 is abnormal. In a third technique, the SDN controller 1 10 may periodically read the UP/DOWN state of the interface of the common switch that is directly connected to the SDN switch 130a and if the SDN controller 1 10 that the state of a port is DOWN, the SDN controller 1 10 may determine that the management channel between the SDN controller 1 10 and the SDN switch 130a that is directly connected to the port and the SDN controller 1 10 is abnormal.

[0045] Following block 414, the message sending/receiving module 228 may send a status checking message to the next active server 140b, which is now the current active server, as indicated at block 410. In addition, the server status determining module 230 may determine whether the current active server 140b is communicating over the network 100 properly. In response to a determination that the current active server 140b is not communicating over the network 100 properly, the SDN controller 1 10 may select another server 140c to be the next active server as indicated at block 414. The SDN controller 1 10 may also close the connection of the current active server 140b to the network 100 and may open the connection of the selected another server 140c to the network 100, as also indicated at block 414 [0046] However, at block 412, in response to a determination that a current active server 140a or 140b is communicating properly over the network 100, the SDN controller 1 10 may maintain the connection of the current active server 140a or 140b to the network 100, as indicated at block 416. In addition, the SDN controller 1 10 may iterate through blocks 410-416 in a continuous and/or periodic manner to change the active server if the SDN controller 1 10 determines that a currently selected active server is not communicating properly over the network 100. That is, the SDN controller 1 10 may cause a backup server to become active in response to a determination that the current active server is not communicating properly over the network to thus prevent or reduce disruptions due to the failure in the communication of the active server. To substantially reduce or limit the amount of down time caused by an improperly communicating active server, the SDN controller 1 10 may iterate through blocks 410-416 every few milliseconds or seconds.

[0047] Turning now to FIG. 5, there is shown a flow diagram of a method 500 for controlling an operational status of a server 140a, according to an example. It should be apparent to those of ordinary skill in the art that the method 500 represents a generalized illustration and that other operations may be added or existing operations may be removed, modified or rearranged without departing from the scope of the method 500. Any of the servers 140a-140m in a cluster of servers 150 may implement the method 500. Thus, although particular reference is made to the server 140a, it should be clearly understood that the remaining servers 140b-140m may implement the method 500.

[0048] Generally speaking, a server 140a in the cluster of servers 150 may implement the method 500 to determine whether the server 140a is operating as an active server or as a backup server. Particularly, for instance, a processor, such as a microprocessor, a micro-controller, an ASIC, or the like, that implements the server 140a, may implement or execute the method 500. At block 502, a server 140a may start the method 300. The server 140a may start the method 500 in response to receipt of a manual instruction from a user, may automatically start the method 500 at a predetermined time, or in response to receipt of a signal, for instance, from the SDN controller 1 10. [0049] At block 504, the server 140a may determine whether the server 140a received a status checking message from the SDN controller 1 10. In response to a determination that the server 140a has not received a status checking message, the server 140a may operate as a backup server in the cluster of servers 150, as indicated at block 506. That is, the server 140a may be disconnected from the network 100 and may stay in a fully operational mode. Alternatively, the server 140a may enter into a lower power mode, such as a sleep or a standby mode.

[0050] In response to a determination that the server 140a has received a status checking message from the SDN controller 1 10, the server 140a may operate as a current active server, as indicated at block 508. In one regard, the server 140a, when operating as the current active server, may provide services to clients for the cluster of servers 150.

[0051] As depicted in FIG. 5, blocks 504-508 may be repeated by the server 140a to continually determine whether the server 140a is to operate as the current active server or as a backup server and to continually update the operational status of the server 140a.

[0052] Some or all of the operations set forth in the methods 300, 400, and 500 may be contained as utilities, programs, or subprograms, in any desired computer accessible medium. In addition, the methods 300, 400, and 500 may be embodied by computer programs, which may exist in a variety of forms both active and inactive. For example, they may exist as machine readable instructions, including source code, object code, executable code or other formats. Any of the above may be embodied on a non-transitory computer readable storage medium.

[0053] Examples of non-transitory computer readable storage media include conventional computer system RAM, ROM, EPROM, EEPROM, and magnetic or optical disks or tapes. It is therefore to be understood that any electronic device capable of executing the above-described functions may perform those functions enumerated above.

[0054] Turning now to FIG. 6, there is shown a schematic representation of a computing device 600, which may be employed to perform various functions of the computing device 202 depicted in FIG. 2, according to an example. The device 600 may include a processor 602, a display 604, such as a monitor; a network interface 608, such as a Local Area Network LAN, a wireless 802.1 1 x LAN, a 3G mobile WAN or a WiMax WAN; and a computer-readable medium 610. Each of these components may be operatively coupled to a bus 612. For example, the bus 612 may be an EISA, a PCI, a USB, a FireWire, a NuBus, or a PDS.

[0055] The computer readable medium 610 may be any suitable medium that participates in providing instructions to the processor 602 for execution. For example, the computer readable medium 610 may be non-volatile media, such as an optical or a magnetic disk; volatile media, such as memory. The computer-readable medium 610 may also store a redundant server operation application 614, which may perform the methods 300 and/or 400 and may include the modules 220-230 of the SDN controller 1 10 depicted in FIGS. 1 and 2. In this regard, the redundant server operation application 614 may include a server cluster establishing module 220, an access port position tracking module 222, an active server selecting module 224, a connection opening/closing module 226, a message sending/receiving module 228, and a server status determining module 230.

[0056] Although described specifically throughout the entirety of the instant disclosure, representative examples of the present disclosure have utility over a wide range of applications, and the above discussion is not intended and should not be construed to be limiting, but is offered as an illustrative discussion of aspects of the disclosure.

[0057] What has been described and illustrated herein is an example of the disclosure along with some of its variations. The terms, descriptions and figures used herein are set forth by way of illustration only and are not meant as limitations. Many variations are possible within the spirit and scope of the disclosure, which is intended to be defined by the following claims - and their equivalents - in which all terms are meant in their broadest reasonable sense unless otherwise indicated.

Claims

What is claimed is:

1 . A method for redundant server operation by a software defined network (SDN) controller, said method comprising:

determining, by a processor implementing the SDN controller, whether a current active server in a cluster of servers is communicating over a network properly, wherein the servers in the cluster of servers are to provide redundant server operations with respect to each other on the network; and

in response to a determination that the current active server is not communicating over the network properly, selecting, by the processor, another server in the cluster of servers to be a next active server, closing a connection of the current active server to the network, and opening the connection of the selected another server to the network.

2. The method according to claim 1 , further comprising:

selecting a server in the cluster of servers to be the current active server; and disconnecting from the network, the servers in the cluster of servers other than the current active server.

3. The method according to claim 2, further comprising, in response to the determination that the current active server is not communicating over the network properly:

sending a status checking message to the next active server;

determining whether the next active server is communicating properly over the network;

in response to a determination that the next active server is communicating properly over the network, maintaining the connection of the next active server to the network; and

in response to a determination that the next active server is not communicating properly over the network, closing the connection of the next active server to the network, selecting a further server in the cluster of servers to be a further active server, closing a connection of the next active server to the network, and opening the connection of the selected further server to the network.

4. The method according to claim 2, wherein disconnecting, from the network, the servers in the cluster of servers other than the current active server further comprises disconnecting the servers in the cluster of servers other than the current active server by closing the access ports to which the servers in the cluster of servers other than the current active server are connected.

5. The method according to claim 1 , further comprising:

sending a status checking message to the current active server;

determining whether a response message is received from the current active server; and

wherein determining whether the current active server is communicating properly over the network further comprises determining that the current active server is communicating properly over the network in response to a determination that the response message is received from the current active server.

6. The method according to claim 5, wherein determining whether the current active server is communicating properly over the network further comprises determining that the current active server is not communicating properly over the network in response to a determination that the response message is not received from the current active server within a predetermined amount of time from when the status checking message was sent.

7. The method according to claim 1 , further comprising:

storing information pertaining to the servers in the cluster of servers; and assigning the servers in the cluster of servers with a same virtual internet protocol (IP) address.

8. The method according to claim 1 , further comprising:

establishing the cluster of servers; and

tracking locations of access ports in a plurality of network switches to which the servers in the cluster of servers are connected.

9. A non-transitory computer readable storage medium on which is stored machine readable instructions that when executed by a processor cause the processor to:

send a status checking message to a current active server in a cluster of servers, wherein the servers in the cluster of servers are to provide redundant server operations with respect to each other on the network;

determine whether a response message is received from the current active server within a predetermined amount of time;

determine that the current active server is communicating properly over the network in response to a determination that the response message is received within the predetermined amount of time; and

determine that the current active server is not communicating properly over the network in response to a determination that the response message is not received within the predetermined amount of time.

10. The non-transitory computer readable storage medium according to claim 9, wherein the machine readable instructions are further to cause the processor to: in response to a determination that the current active server is not communicating properly over the network, select another server in the cluster of servers to be a next active server, close a connection of the current active server to the network, and open the connection of the selected another server to the network.

1 1 . The non-transitory computer readable storage medium according to claim 9, wherein the machine readable instructions are further to cause the processor to: select a server in a cluster of servers to be the current active server; and disconnect from the network, the servers in the cluster of servers other than the current active server.

12. The non-transitory computer readable storage medium according to claim 9, wherein, to disconnect the servers from the network, the machine readable instructions are further to cause the processor to communicate instructions to a plurality of network switches to close access ports on the plurality of network switches to which the servers other than the current active server are connected.

13. The non-transitory computer readable storage medium according to claim 9, wherein the machine readable instructions are further to cause the processor to: store information pertaining to the servers in the cluster of servers; and assign the servers in the cluster of servers with a same virtual internet protocol (IP) address.

14. The non-transitory computer readable storage medium according to claim 9, wherein the machine readable instructions are further to cause the processor to: establish the cluster of servers; and

track locations of access ports in a plurality of network switches to which the servers in the cluster of servers are connected.

15. An apparatus comprising:

a processor; and

a memory storing machine readable instructions that when executed by the processor cause the processor to:

determine whether a status checking message was received;

in response to a determination that the status checking message was received, operating the apparatus as a current active server of cluster of servers, wherein the servers in the cluster of servers are to provide redundant server operations with respect to each other; and

in response to a determination that the status checking message was not received, operating the apparatus as a backup server in the cluster of servers.