Method and apparatus for load balancing with server state change awareness

BACKGROUND OF THE INVENTION

00011. Field of the Invention

0002The present invention is related generally to a data processing system and in particular to an improved load balancer. More particularly, the present invention is directed to a computer implemented method, apparatus, and computer usable program code for a load balancing feedback controller enhanced by feed-forward control for reacting to server state changes.

00032. Description of the Related Art

0004A computer data center is a physical structure designed to house multiple computing devices, such as application servers. An application server is a computing device connected to a network that is wholly or partially dedicated to running one or more applications. An application is computer software that uses the resources of a computing device to perform a task or service for a user.

0005A computer data center may include multiple application servers loosely coupled together in a cluster. This cluster of connected servers may be a computer cluster or a server farm. Each application server in a cluster may deploy several applications providing one or more different services to users. An application providing a given service may be replicated on multiple application servers in the cluster. The replication of the application allows multiple requests to access a given application to be handled concurrently by two or more servers. In addition, replication of the application on multiple application servers also allows an application to remain available even if one server providing the application is down or unavailable. However, the various requests to access applications on the cluster need to be managed to enable optimal performance of the applications on the cluster.

0006Load balancing is a front-end process for managing and assigning work loads to two or more application servers in a cluster to optimize performance of the application and decrease execution time. Load balancing is typically performed by a load balancer. Typically, all requests to access an application on a cluster are routed to a back-end server by the load balancer. The load balancer receives a request for an application, selects a given server to run the application, and distributes the request to the selected back-end application server. The load balancer routes requests for a given application to a given server running that application to achieve similar performance to each request, independent of the particular server that is destined to execute the request. To achieve this result, the load balancer must take into account factors that affect application performance on each server.

0007The performance provided by a server depends on many factors, including the load on the server, the number of applications deployed on the server, and dynamic changes to the state of the server. The load refers to the amount of work currently being performed by the server. A state change refers to a change in the current operating state of the computing device. A server state change may be either a managed change or an unmanaged change. A managed change is a change that occurs at the direction or control of a user and/or a load balancer. Examples of managed state changes include starting execution of an application or stopping execution of an application. An unmanaged state change is a change that occurs without the control or direction of a user or load balancer. For example, an unmanaged state change may include, but is not limited to, periodic garbage collection, daemons, and/or other background workloads.

0008The impact of a server state change on the server performance can be quite significant. A server state change should result in the load balancer decreasing the amount of traffic destined to that server. However, currently available load balancers only detect server state changes through the measurement of current server performance. A change in state of a given server is not registered until after the change in state has affected the performance of the given server to a degree that the change in performance is measurable by a performance monitor.

0009Thus, the detection and reaction to server state changes may be slow and result in degraded application server performance for potentially lengthy periods of time. For example, when a new application begins executing on a given server, the load balancer may not become aware of the state change until the server processing time has already slowed due to the state change. A similar problem may occur when the server returns to its normal state, for example, when execution of the new application ends.

SUMMARY OF THE INVENTION

0010The illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code for load balancing in a cluster. In one embodiment, a weight adjustment value for a server is identified to form an identified weight adjustment in response to receiving a notification of an impending state change event in the server. An adjusted routing weight for the server is generated using the identified weight adjustment. An incoming service request is routed to a selected server in the cluster based on the adjusted routing weight for each server in the cluster.

BRIEF DESCRIPTION OF THE DRAWINGS

0011The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

0012<figref idref="DRAWINGS">FIG. 1</figref> is a pictorial representation of a network of data processing systems in which illustrative embodiments may be implemented;

0013<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of a cluster in which illustrative embodiments may be implemented;

0014<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of a data processing system in which illustrative embodiments may be implemented;

0015<figref idref="DRAWINGS">FIG. 4A</figref> is a block diagram illustrating a server state change event at a first time in accordance with an illustrative embodiment;

0016<figref idref="DRAWINGS">FIG. 4B</figref> is a block diagram illustrating a server state change event at a second time in accordance with an illustrative embodiment;

0017<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram illustrating a dataflow through a load balancer messaging system when a server state change event occurs in accordance with an illustrative embodiment;

0018<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram illustrating a weight adjuster in accordance with an illustrative embodiment;

0019<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart illustrating a process for a load balancer with feedback and feed-forward server state change awareness in accordance with an illustrative embodiment;

0020<figref idref="DRAWINGS">FIG. 8</figref> is a graph illustrating a prior art performance response time for executing an account management application instance on a cluster;

0021<figref idref="DRAWINGS">FIG. 9</figref> is a graph illustrating performance response time for executing the account management application instance on a cluster in accordance with an illustrative embodiment;

0022<figref idref="DRAWINGS">FIG. 10</figref> is a graph illustrating a prior art performance response time for executing a stock trade application instance on a cluster;

0023<figref idref="DRAWINGS">FIG. 11</figref> is a graph illustrating a performance response time for executing the stock trade application instance on a cluster in accordance with an illustrative embodiment;

0024<figref idref="DRAWINGS">FIG. 12</figref> is a graph illustrating a prior art performance response time for executing a financial application on a cluster; and

0025<figref idref="DRAWINGS">FIG. 13</figref> is a graph illustrating an average performance response time for executing a financial application on a cluster in accordance with an illustrative embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

0026With reference now to the figures and in particular with reference to <figref idref="DRAWINGS">FIGS. 1-3</figref>, exemplary diagrams of data processing environments are provided in which illustrative embodiments may be implemented. It should be appreciated that <figref idref="DRAWINGS">FIGS. 1-3</figref> are only exemplary and are not intended to assert or imply any limitation with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environments may be made.

0027With reference now to the figures, <figref idref="DRAWINGS">FIG. 1</figref> depicts a pictorial representation of a network of data processing systems in which illustrative embodiments may be implemented. Network data processing system <b>100</b> is a network of computers in which embodiments may be implemented. Network data processing system <b>100</b> contains network <b>102</b>, which is the medium used to provide communications links between various devices and computers connected together within network data processing system <b>100</b>. Network <b>102</b> may include connections, such as wire, wireless communication links, or fiber optic cables.

0028In the depicted example, server <b>104</b> and server <b>106</b> connect to network <b>102</b> along with storage unit <b>108</b>. In addition, clients <b>110</b> and <b>112</b> connect to network <b>102</b>. These clients <b>110</b> and <b>112</b> may be, for example, personal computers or network computers. In the depicted example, server <b>104</b> provides data, such as boot files, operating system images, and applications to clients <b>110</b> and <b>112</b>. Clients <b>110</b> and <b>112</b> are clients to server <b>104</b> in this example.

0029Network data processing system <b>100</b> also includes data center <b>114</b> connected to network <b>102</b>. Data center <b>114</b> may be a single physical building or multiple physical buildings designed to house two or more application servers. In other words, data center <b>114</b> is a location at which two or more application servers are loosely connected to provide application services to users. Clients <b>110</b> and <b>112</b> send requests to access and/or execute an application to data center <b>114</b> through network <b>102</b>. A load balancer located at data center <b>114</b> routes each request to access and/or execute an application to a selected application server. A request to access an application may be received from client <b>110</b> or <b>112</b>, as well as from server <b>104</b> or <b>106</b>.

0030For example, a request from client <b>110</b> received at data center <b>114</b> is routed by a load balancer to an application server. After execution of the application is complete, the service response or result of application execution is sent back to the requesting client from data center <b>114</b> via network <b>102</b>.

0031In this example, network data processing system <b>100</b> includes a single data center. However, network data processing system <b>100</b> may be connected to multiple data centers. Network data processing system <b>100</b> may also include additional application servers, clients, and other devices not shown.

0032In the depicted example, network data processing system <b>100</b> is the Internet with network <b>102</b> representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, governmental, educational and other computer systems that route data and messages. Of course, network data processing system <b>100</b> also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). <figref idref="DRAWINGS">FIG. 1</figref> is intended as an example, and not as an architectural limitation for different embodiments.

0033Currently available load balancers only detect server state changes through the measurement of current server performance. A change in state of a given server is not registered until after the change in state has affected the performance of the given server to a degree that the change in performance is measurable by a performance monitor. Thus, the detection and reaction to server state changes may be slow and result in degraded application server performance for potentially lengthy periods of time.

0034The illustrative embodiments recognize a need for load balancers with direct awareness of server state changes to anticipate server state changes before the state change occurs or at the time the server state change occurs in an application server. In this manner, the load balancer can assign application requests to cluster servers based on more accurate server state change information to avoid degraded server performance due to state changes. In other words, the illustrative embodiments recognize the need for a load balancing feedback controller enhanced by feed-forward control for reacting to notifications of changes in the system.

0035Thus, the illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code for load balancing in a cluster. In one embodiment, a weight adjustment value for a server is identified in response to receiving a notification of an impending state change event in the server. The weight adjustment is communicated to a load balance controller. The load balance controller generates an adjusted routing weight for the server using the weight adjustment. An incoming service request is routed to a selected server in the cluster based on the adjusted routing weight for each server in the cluster.

0036<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of a cluster in which illustrative embodiments may be implemented. Cluster <b>200</b> is a cluster in which two or more servers are loosely coupled together to provide access to one or more applications. Cluster <b>200</b> may be a computer cluster, a server farm, web services servers, or any other group of servers coupled together to provide application services to users. Cluster <b>200</b> may be located in a data center, such as data center <b>114</b> in <figref idref="DRAWINGS">FIG. 1</figref>.

0037A client, such as client <b>202</b> or client <b>204</b>, sends requests to access one or more applications on cluster <b>200</b>. Clients <b>202</b> and <b>204</b> may be any type of computing device, including but not limited to, a personal computer, a laptop computer, a personal digital assistant (PDA), an iPod®, a tablet PC, or any other type of computing device. In this example, clients <b>202</b> and <b>204</b> are examples of a client, such as client <b>110</b> in <figref idref="DRAWINGS">FIG. 1</figref>.

0038Each request to access an application on the cluster is received by load balancer <b>206</b>. In these embodiments, load balancer <b>206</b> is a front-end software component for managing the load on each server on the computer cluster, such as application servers <b>208</b>-<b>212</b>.

0039Application servers <b>208</b>-<b>212</b> are any type of known or available server computers. Application servers <b>208</b>-<b>212</b> may be servers dedicated to executing one or more applications. Applications servers <b>208</b>-<b>212</b> may also be servers that perform one or more other functions in addition to hosting applications. For example, applications servers <b>208</b>-<b>212</b> may also function as web servers hosting web pages and/or advertising servers providing advertising content to clients <b>202</b>-<b>204</b> in addition to providing application services. As used herein, an application server is any server hosting an application. In these examples, an application server is not required to be a dedicated application server whose sole purpose is hosting applications.

0040In this illustrative embodiment, load balancer <b>206</b> uses feedback controllers and feed-forward controllers to react to performance measurements from servers in the computer cluster. Load balancer <b>206</b> is aware of server state changes before or at the time that the server state changes occur. In this manner, load balancer <b>206</b> is able to manage the load on application servers <b>208</b>-<b>212</b> based on current load and anticipated future load to optimize server performance and reduce application performance deterioration when server state changes occur.

0041With reference now to <figref idref="DRAWINGS">FIG. 3</figref>, a block diagram of a data processing system is shown in which illustrative embodiments may be implemented. Data processing system <b>300</b> is an example of a computer, such as server <b>104</b> or client <b>110</b> in <figref idref="DRAWINGS">FIG. 1</figref> or application server <b>208</b> or client <b>204</b> in <figref idref="DRAWINGS">FIG. 2</figref>, in which computer usable code or instructions implementing the processes may be located for the illustrative embodiments.

0042In the depicted example, data processing system <b>300</b> employs a hub architecture including a north bridge and memory controller hub (MCH) <b>302</b> and a south bridge and input/output (I/O) controller hub (ICH) <b>304</b>. Processing unit <b>306</b>, main memory <b>308</b>, and graphics processor <b>310</b> are coupled to north bridge and memory controller hub <b>302</b>. Processing unit <b>306</b> may contain one or more processors and even may be implemented using one or more heterogeneous processor systems. Graphics processor <b>310</b> may be coupled to the MCH through an accelerated graphics port (AGP), for example.

0043In the depicted example, local area network (LAN) adapter <b>312</b> is coupled to south bridge and I/O controller hub <b>304</b> and audio adapter <b>316</b>, keyboard and mouse adapter <b>320</b>, modem <b>322</b>, read only memory (ROM) <b>324</b>, universal serial bus (USB) ports and other communications ports <b>332</b>, and PCI/PCIe devices <b>334</b> are coupled to south bridge and I/O controller hub <b>304</b> through bus <b>338</b>, and hard disk drive (HDD) <b>326</b> and CD-ROM drive <b>330</b> are coupled to south bridge and I/O controller hub <b>304</b> through bus <b>340</b>. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM <b>324</b> may be, for example, a flash binary input/output system (BIOS). Hard disk drive <b>326</b> and CD-ROM drive <b>330</b> may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A super I/O (SIO) device <b>336</b> may be coupled to south bridge and I/O controller hub <b>304</b>.

0044An operating system runs on processing unit <b>306</b> and coordinates and provides control of various components within data processing system <b>300</b> in <figref idref="DRAWINGS">FIG. 3</figref>. The operating system may be a commercially available operating system such as Microsoft® Windows® XP (Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both). An object oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system <b>300</b>. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

0045Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive <b>326</b>, and may be loaded into main memory <b>308</b> for execution by processing unit <b>306</b>. The processes of the illustrative embodiments may be performed by processing unit <b>306</b> using computer implemented instructions, which may be located in a memory such as, for example, main memory <b>308</b>, read only memory <b>324</b>, or in one or more peripheral devices.

0046The hardware in <figref idref="DRAWINGS">FIGS. 1-3</figref> may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in <figref idref="DRAWINGS">FIGS. 1-3</figref>. Also, the processes of the illustrative embodiments may be applied to a multiprocessor data processing system.

0047In some illustrative examples, data processing system <b>300</b> may be a personal digital assistant (PDA), which is generally configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data. A bus system may be comprised of one or more buses, such as a system bus, an I/O bus and a PCI bus. Of course the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture. A communications unit may include one or more devices used to transmit and receive data, such as a modem or a network adapter. A memory may be, for example, main memory <b>308</b> or a cache such as found in north bridge and memory controller hub <b>302</b>. A processing unit may include one or more processors or CPUs. The depicted examples in <figref idref="DRAWINGS">FIGS. 1-3</figref> and above-described examples are not meant to imply architectural limitations. For example, data processing system <b>300</b> also may be a tablet computer, laptop computer, or telephone device in addition to taking the form of a PDA.

0048<figref idref="DRAWINGS">FIG. 4A</figref> is a block diagram illustrating a server state change event at a first time in accordance with an illustrative embodiment. Network data processing system state <b>400</b> illustrates a current state of three servers at time <b>1</b>. The current states of the servers on network data processing system state <b>400</b> may be stored in a data storage device, such as storage <b>108</b> in <figref idref="DRAWINGS">FIG. 1</figref>. The current state of the servers may be monitored and updated by a system configuration and monitoring component associated with network data processing system state <b>400</b>. The system configuration and monitoring component is discussed in more detail in <figref idref="DRAWINGS">FIG. 5</figref> below.

0049The three servers in these example are node <b>1</b><b>402</b>, node <b>2</b><b>404</b>, and node <b>3</b><b>406</b>. Each node has available an instance of applications FA, application ST, and application AM. At time <b>1</b>, node <b>1</b><b>402</b> is not running application instance FA <b>408</b>. Node <b>1</b><b>402</b> is running instances of applications ST <b>406</b> and AM <b>408</b>. Node <b>2</b><b>404</b> is not running an instance of application FA <b>414</b>. Node <b>2</b><b>404</b> is running instances of applications ST <b>416</b> and AM <b>418</b>. Node <b>3</b><b>406</b> is not running application instance ST <b>420</b>, but is running instances of applications FA <b>422</b> and AM <b>424</b>.

0050<figref idref="DRAWINGS">FIG. 4B</figref> is a block diagram illustrating a server state change event at a second time in accordance with an illustrative embodiment. Server state at time <b>2</b><b>430</b>, node <b>1</b><b>402</b> begins running application instance FA <b>408</b>. The change in state of node <b>1</b><b>402</b> when node <b>1</b> begins running application instance FA <b>408</b> is a state change event. A load balancer in accordance with the illustrative embodiments monitors a set of servers, such as nodes <b>402</b>-<b>406</b> for server state change events, such as is illustrated in <figref idref="DRAWINGS">FIG. 4</figref>. As used herein, a set of servers includes two or more servers.

0051The load balancer of the illustrative embodiments is aware of and reacts to application placement changes in a cluster, such as a server cluster. Managed server state changes are application placement changes. Events, such as server_start and server_stop, are detected through a messaging system. The load balancer uses a proportional integral derivative (PID) feedback controller to equalize the service times of requests destined to the same application. A significant performance improvement during application placement changes may be achieved using the load balancer of the illustrative embodiments, as shown in <figref idref="DRAWINGS">FIGS. 9</figref>, <b>11</b>, and <b>13</b> below.

0052<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram illustrating a dataflow through a load balancer messaging system when a server state change event occurs in accordance with an illustrative embodiment. Load balancer <b>500</b> is a front-end component for controlling and managing the loads on two or more servers. Load balancer <b>500</b> performs load balancing based on state information for the two or more servers connected to load balancer <b>500</b>. Load balancer <b>500</b> may be a software component, a hardware component, or a combination of hardware and software. Load balancer Load balancer <b>500</b> may be located in a data center, such as data center <b>114</b> in <figref idref="DRAWINGS">FIG. 1</figref>. Load balancer <b>500</b> may be a load balancer in a cluster, such as cluster <b>200</b> in <figref idref="DRAWINGS">FIG. 2</figref>.

0053Load balancer <b>500</b> receives client service request <b>502</b> from a client, such as client <b>110</b> in <figref idref="DRAWINGS">FIG. 1</figref> or client <b>202</b> in <figref idref="DRAWINGS">FIG. 2</figref>. Client service request <b>502</b> is a request to access an application, such as application <b>504</b>. Application <b>504</b> is replicated on multiple servers in the cluster. In this example, application <b>504</b> is replicated on both server <b>506</b> and <b>508</b>. In other words, in this example, there are two instances of application <b>504</b>. One instance is available on server <b>506</b> and the other instance is available on server <b>508</b>. Thus, client service request <b>502</b> requesting access to an instance of application <b>504</b> may be routed to either server <b>506</b> or <b>508</b>.

0054Servers <b>506</b> and <b>508</b> are nodes in a computer cluster. Each node is a host to an application. In other words, each node provides a runtime environment for execution of applications. In this example, the computer cluster is depicted as including only two servers. However, a computer cluster may include any number of servers in accordance with the illustrative embodiments. In addition, in this example, server <b>506</b> and <b>508</b> are application servers. However, in accordance with the illustrative embodiments, the computer cluster may include any type of server, including but not limited to, an application server, a web server, a domain name server (DNS), an advertising server, or any other type of server.

0055In this example, servers <b>506</b> and <b>508</b> are application servers hosting one or more different applications. However, servers <b>506</b> and <b>508</b> may include two or more different applications. For example, server <b>506</b> may include an instance of application A, application B, and application C. Server <b>508</b> may include an instance of application A, application C, and application D. Thus, each server is not required to include the same applications as any other server in the cluster. However, in another embodiment, all the servers in the cluster could include an identical set of applications.

0056Client service request <b>502</b> is sent to router <b>510</b>. Router <b>510</b> is software component for handling message transfers between computing devices. In this example, router <b>510</b> is a component for routing application requests, such as client service request <b>502</b>, to servers on the cluster associated with load balancer <b>500</b>.

0057System configuration and monitoring <b>512</b> is a software component for monitoring the configuration of the network data processing system on which the computer cluster is located. The configuration is the arrangement of computing devices in the network data processing system. The configuration includes the hardware, software, firmware, and/or documentation associated with the network data processing system. The configuration includes an identification of which application are located on which servers. The configuration also includes the processing speed of each server.

0058System configuration and monitoring <b>512</b> also monitors changes in the network data processing system. For example, system configuration and monitoring <b>512</b> monitors background processes, new applications that begin execution, application instances that stop execution, and any other information regarding a current state of servers <b>506</b> and <b>508</b>.

0059The system state information gathered by system configuration and monitoring <b>512</b> is sent to server state change notifier <b>514</b>. Server state change notifier <b>514</b> is a software component for determining if a change in load balance is needed based on the current configuration and state changes in the given server. For example, when an instance of application <b>504</b> begins running on server <b>506</b>, the execution of application <b>504</b> places a heavy load on the resources of server <b>506</b>. In other words, server <b>506</b> will be less able to perform other tasks due to the drain on the processor, memory, and other resources of server <b>506</b> that may be expended to execute application <b>504</b>. Therefore, server state change notifier <b>514</b> makes a determination as to whether or not additional tasks or application requests should be routed to server <b>506</b> while application <b>504</b> is still executing. Server state change notifier <b>514</b> may determine that application <b>504</b> will take approximately one and a half minutes to complete execution. Consequently, server state change notifier <b>514</b> will decide if service requests should not be routed to server <b>506</b> during that one and a half minute time period during which application <b>504</b> is executing.

0060Server state change notifier <b>514</b> sends a notification of the state change event to weight adjuster <b>516</b> notifying weight adjuster <b>516</b> as to whether an adjustment in the routing weights for servers <b>506</b> and <b>508</b> are needed. Routing weights are the weights or factors used to determine which server should receive a client service request. For example, if the computer cluster includes three nodes, the routing weights could indicate that fifteen percent (15%) of incoming service requests should be sent to node <b>1</b>, forty-five percent (45%) of service requests should be sent to node <b>2</b>, and forty percent (40%) of incoming service requests should be sent to node <b>3</b>.

0061Weight adjuster <b>516</b> calculates an adjustment to a routing weight for a given node based on state changes in each node either before the changes occur or at the time the changes occur. Weight adjuster <b>516</b> sends the routing weight adjustment to load balance controller <b>518</b>. Load balance controller <b>518</b> adjusts the routing weight for each node based on the routing weight adjustment for each node received from weight adjuster <b>516</b>.

0062Thus, if server <b>508</b> begins running an instance of application <b>504</b>, this change in the state of server <b>508</b> may result in weight adjuster <b>516</b> sending a weight adjustment to load balance controller <b>518</b> to lower the routing weight for server <b>508</b> so that router <b>510</b> will route fewer incoming service requests to server <b>508</b>. When the instance of application <b>504</b> stops or completes execution, weight adjuster <b>516</b> may send an adjustment to load balance controller <b>518</b> to raise the routing weight for server <b>508</b> so that router <b>510</b> will route more incoming service requests to server <b>508</b>.

0063Performance metrics <b>520</b> are measurements obtained from each node regarding the performance of the node. The performance of the node includes the amount of time required for each node to complete a task or execution of an application. Performance metrics <b>520</b> are sent from servers <b>506</b> and <b>508</b> to load balancer <b>500</b> for use in determining the current performance of servers <b>506</b> and <b>508</b>.

0064Load balance controller <b>518</b> is a software component for controlling the amount of load or client service requests routed to each server. Load balance controller <b>518</b> uses routing weight adjustments from weight adjuster <b>516</b> and performance metrics <b>520</b> to adjust or update the routing weights for each node. Load balance controller <b>518</b> sends adjusted routing weights <b>522</b> to router <b>510</b>.

0065Thus, in this example shown in <figref idref="DRAWINGS">FIG. 5</figref>, the process begins when a client sends client service request <b>502</b> to access an instance of application <b>504</b> on the computer cluster. Load balancer <b>500</b> receives client service request <b>502</b> and sends the request to router <b>510</b>. Router <b>510</b> receives adjusted routing weights <b>522</b> from load balance controller <b>518</b>. In this example, adjusted routing weights <b>522</b> indicates fifty-five percent (55%) of incoming requests should be routed to server <b>508</b> and forty-five (45%) of incoming requests should be routed to server <b>506</b>. Router <b>510</b> selects server <b>508</b> in the computer cluster to route client service request <b>502</b> based on adjusted routing weights <b>522</b> for server <b>506</b> and <b>508</b>. Server <b>508</b> executes an instance of application <b>504</b> in response to receiving client service request <b>502</b> from router <b>510</b>.

0066System configuration and monitoring <b>512</b> monitors the new instance of application <b>504</b>. System configuration and monitoring <b>512</b> sends system state change data to server state change notifier <b>515</b> indicating that a new application instance is running on server <b>508</b>. Server state change notifier <b>516</b> determines that a change in load balance on server <b>506</b> and <b>508</b> is needed in response to the change in state that occurred as a result of server <b>508</b> executing a new instance of application <b>505</b>.

0067Server state change notifier <b>516</b> sends state change event information to weight adjuster <b>518</b>. Weight adjuster <b>518</b> calculates a weight adjustment for the routing weights of server <b>506</b> and <b>508</b>. Weight adjuster <b>516</b> sends the weight adjustments to load balance controller <b>518</b>. Load balance controller <b>518</b> receives the weight adjustments from weight adjuster <b>516</b>. Load balance controller <b>518</b> also receives performance metrics <b>520</b> indicating the current performance of servers <b>506</b> and <b>508</b>. Based on the weight adjustments and current performance metrics, load balance controller <b>518</b> sends adjusted routing weights <b>522</b> to router <b>510</b>. For example, adjusted routing weights <b>522</b> may indicate that only forty percent (40%) of incoming service requests should now be routed to server <b>508</b>. Thus, if a new service request is received, router <b>510</b> may route the new service request to server <b>506</b> rather than server <b>508</b> based on the new routing weights.

0068In this example, system configuration and monitoring <b>512</b>, server state change notifier <b>514</b>, and weight adjuster <b>516</b> forms a feed-forward controller that adjusts routing weights based on changes in state of one or more servers before the change in state occurs or as the state in change is occurring. Load balance controller <b>518</b> and router <b>510</b> form a feedback controller that controls and adjusts server loads based on feedback performance metrics and feed-forward state change information. Feedback performance metrics indicate current changes in performance in each server as a result of changes in server state that have already occurred and resulted in server performance either improving or deteriorating. In other words, feedback control measures changes after a change in state has affected the given server's performance. Feed-forward state change information monitors changes in server state before or at the time the change in state occurs. Feed-forward state change information can be obtained before the state change affects performance. Thus, weight adjuster <b>516</b> can calculate a weight adjustment that takes into account an increased load on server <b>508</b> before the processing performance of server <b>508</b> begins to deteriorate or slow. Thus, load balancer <b>500</b> can control routing weights to compensate for changes in state based on feed-forward state changes and feedback performance metrics indicating changes in server state. In this manner, load balancer <b>500</b> can optimize server performance.

0069In this example, components <b>510</b>-<b>522</b> are located on a single hardware device. However, in accordance with the illustrative embodiments, components <b>510</b>-<b>522</b> may be located on one or more hardware devices. In addition, one or more of components <b>510</b>-<b>522</b> may be located on a server in the cluster, such as servers <b>506</b> and <b>508</b>.

0070Turning now to <figref idref="DRAWINGS">FIG. 6</figref>, a block diagram illustrating a weight adjuster is depicted in accordance with an illustrative embodiment. Weight adjuster <b>600</b> is a component for calculating a routing weight adjustment based on state change event information in a network data processing system. Weight adjuster <b>600</b> is a weight adjuster, such as weight adjuster <b>516</b> in <figref idref="DRAWINGS">FIG. 5</figref>.

0071Weight adjuster <b>600</b> receives state change event <b>602</b> information from a server state change notifier, such as server state change notifier <b>514</b> in <figref idref="DRAWINGS">FIG. 5</figref>. State change event <b>602</b> is an event that changes a state of a server, such as beginning execution of an application and/or ending execution of an application. In other words, state change event <b>602</b> is an event that may affect the performance of a server. Thus, weight adjuster <b>600</b> needs to be made aware of state change event <b>602</b> to calculate a weight adjustment and balance the load on each server to optimize server performance.

0072A state change may be associated with a policy. A policy associated with a state change specifies a weight adjustment to be made in response to the state change. The policy is a predetermined or pre-generated set of parameters, protocols, rules, and/or formulas for calculating a weight adjustment for a given state change event. For example, if a business application “X” is executed on a given server, a policy associated with the state change event for executing business application “X”, is associated with a policy, the policy could specify a downward weight adjustment of ten percent (10%) for the given server on which the state change event took place.

0073Weight adjuster <b>600</b> makes a determination as to whether state change event <b>602</b> is associated with a policy by checking policy repository <b>604</b> for policy <b>606</b> associated with state change event <b>602</b>. In response to locating policy <b>606</b>, weight adjuster <b>600</b> calculates weight adjustment <b>608</b> based on the weight adjustment parameters included in policy <b>606</b>.

0074However, if weight adjuster <b>600</b> cannot locate a policy associated with state change event <b>602</b>, performance modeler <b>610</b> makes a determination as to the predicted impact of state change event <b>602</b>. Performance modeler <b>610</b> includes a set of one or more models of the network data processing system in which weight adjuster <b>600</b> is a part. The set of models include information regarding the current network data processing system configuration, the number of applications on each server, the processor speeds of each server, and/or any other data regarding the data processing system configuration. The set of models is used to determine performance impact <b>612</b> of server state change event <b>602</b> on the network data processing system.

0075Performance impact <b>612</b> is information regarding the predicted impact of state change event <b>602</b> on one or more servers in the network data processing system. For example, performance impact <b>612</b> could include information predicting a decrease in processor performance in node <b>1</b> and/or an increase in processor performance in node <b>2</b> as a result of state change event <b>602</b>.

0076Performance impact <b>612</b> is sent to weight calculator <b>614</b>. Weight calculator <b>614</b> calculates a weight change or weight adjustment that should be made to a routing weight for one or more nodes in the data processing system based on performance impact <b>612</b>. In this example, weight calculator <b>614</b> may be implemented as any type of known or available software component for calculating a routing weight adjustment based on performance impact data associated with a state change in one or more servers. Weight calculator <b>614</b> calculates weight adjustment <b>608</b>. Weight adjustment <b>608</b> is sent to a component for generating an adjusted routing weight for one or more nodes based on weight adjustment <b>608</b>, such as load balance controller <b>518</b> in <figref idref="DRAWINGS">FIG. 5</figref>.

0077<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart illustrating a process for a load balancer with feedback and feed-forward server state change awareness in accordance with an illustrative embodiment. The process in <figref idref="DRAWINGS">FIG. 7</figref> is performed by a software and/or hardware component for managing loads on a set of servers based on server state information. In this example, the process is performed by a load balancer, such as load balancer <b>500</b> in <figref idref="DRAWINGS">FIG. 5</figref>.

0078The process begins by monitoring for server state changes in a set of servers (step <b>702</b>). The process makes a determination as to whether a server state change is detected (step <b>704</b>). If a server state change is not detected, the process returns to step <b>702</b> until a server state change in one or more servers is detected. When a server state change is detected in step <b>704</b>, the process sends a state change event notification to a weight adjuster (step <b>706</b>). The process makes a determination as to whether a policy associated with the state change event is found (step <b>708</b>). If a policy is found, the process obtains a weight adjustment from the policy (step <b>710</b>). The process sends the weight adjustment to a load balance controller (step <b>712</b>), such as load balance controller <b>518</b> in <figref idref="DRAWINGS">FIG. 5</figref>. The process generates routing weights for one or more servers in the set of servers based on the weight adjustments (step <b>714</b>).

0079Next, the process makes a determination as to whether a service request is received from a user (step <b>716</b>). If a service request is not received, the process returns to step <b>716</b> until a service request is received. When a service request is received at step <b>716</b>, the process sends the service request to a server based on the routing weights for the set of servers (step <b>718</b>). The process then makes a determination as to whether to continue monitoring the network data processing system for server state changes (step <b>720</b>). If a determination is made to continue monitoring for server state changes, the process returns to step <b>702</b>. However, if a determination is made to discontinue monitoring for server state changes at step <b>720</b>, the process terminates thereafter.

0080Returning now to step <b>708</b>, if a policy associated with the server state change event is not found, the process assess a performance impact of the state change event (<b>722</b>). Next, the process calculates a weight adjustment due to the performance impact (step <b>724</b>). The process then sends the weight adjustment to a load balance controller (step <b>712</b>), such as load balance controller <b>518</b> in <figref idref="DRAWINGS">FIG. 5</figref>. The process generates routing weights for one or more servers in the set of servers based on the weight adjustments (step <b>714</b>). The process makes a determination as to whether a service request is received from a user (step <b>716</b>). If a service request is not received, the process returns to step <b>716</b> until a service request is received. When a service request is received at step <b>716</b>, the process sends the service request to a server based on the routing weights for the set of servers (step <b>718</b>). The process then makes a determination as to whether to continue monitoring the network data processing system for server state changes (step <b>720</b>). If a determination is made to continue monitoring for server state changes, the process returns to step <b>702</b>. However, if a determination is made to discontinue monitoring for server state changes at step <b>720</b>, the process terminates thereafter.

0081<figref idref="DRAWINGS">FIG. 8</figref> is a graph illustrating a prior art performance response time for executing an account management application instance on a cluster. Graph <b>800</b> is illustrating a performance response time for an application instance AM executing on nodes <b>402</b>-<b>406</b> in <figref idref="DRAWINGS">FIG. 4</figref> when a currently available load balancer is used to route service requests to servers.

0082Line <b>802</b> is illustrating the performance of node <b>1</b><b>402</b> in <figref idref="DRAWINGS">FIG. 4</figref> when server state change event occurs. As discussed above, the server state change was an instance of application FA <b>408</b> that began running on node <b>1</b><b>402</b>. Line <b>804</b> illustrates the performance of node <b>2</b><b>404</b> when the server state change occurred on node <b>1</b><b>402</b> in <figref idref="DRAWINGS">FIG. 4</figref>. Line <b>806</b> illustrates the performance of node <b>3</b><b>406</b> when the server state change occurred in node <b>1</b><b>402</b> in <figref idref="DRAWINGS">FIG. 4</figref>. As can be seen in graph <b>800</b> in <figref idref="DRAWINGS">FIG. 8</figref>, when an instance of application FA begins running in node <b>1</b> at approximately time <b>1100</b>, the performance of application instance AM in node <b>1</b> begins to deteriorate dramatically in comparison to the performance of application instance AM on nodes <b>2</b> and <b>3</b> shown in lines <b>804</b> and <b>806</b>.

0083Turning now to <figref idref="DRAWINGS">FIG. 9</figref>, a graph illustrating performance response time for executing the account management application instance on a cluster is shown in accordance with an illustrative embodiment. Graph <b>900</b> illustrates an average performance response time for an application instance AM executing on nodes <b>402</b>-<b>406</b> in <figref idref="DRAWINGS">FIG. 4</figref>. Line <b>902</b> shows the average performance response time in the set of nodes when a prior art load balancer is used. Line <b>904</b> shows an average performance response time when a load balancer with state change awareness, in accordance with the illustrative embodiments, is used to route service requests. As can be seen, when the instance of application FA begins executing at approximately time <b>1100</b>, the average response time for executing application instance AM shown in line <b>904</b> remains more constant and shows a shorter average response time than the prior art load balancer.

0084<figref idref="DRAWINGS">FIG. 10</figref> is a graph illustrating a prior art performance response time for executing a stock trade application instance on a cluster. Graph <b>1000</b> is illustrating a performance response time for an application instance ST executing on nodes <b>402</b> and <b>404</b> in <figref idref="DRAWINGS">FIG. 4</figref> when a currently available load balancer is used to route service requests to servers.

0085Line <b>1002</b> is illustrating the performance of node <b>1</b><b>402</b> in <figref idref="DRAWINGS">FIG. 4</figref> when a server state change event occurs. As discussed above, the server state change was an instance of application FA <b>408</b> that began running on node <b>1</b><b>402</b>. Line <b>1004</b> illustrates the performance of node <b>2</b><b>404</b> when the server state change occurred on node <b>1</b><b>402</b> in <figref idref="DRAWINGS">FIG. 4</figref>. As can be seen in graph <b>1000</b> in <figref idref="DRAWINGS">FIG. 10</figref>, when an instance of application FA begins running in node <b>1</b> at approximately time <b>1100</b>, the performance of application instance ST in node <b>1</b> begins to deteriorate dramatically in comparison to the performance of application instance ST on node <b>2</b> shown in line <b>1004</b>.

0086<figref idref="DRAWINGS">FIG. 11</figref> is a graph illustrating a performance response time for executing the stock trade application instance on a cluster in accordance with an illustrative embodiment. Graph <b>1100</b> illustrates an average performance response time for an application instance ST executing on nodes <b>402</b> and <b>404</b> in <figref idref="DRAWINGS">FIG. 4</figref>. Line <b>1102</b> shows the average performance response time in the set of nodes when a prior art load balancer is used. Line <b>1104</b> shows an average performance response time when a load balancer with state change awareness, in accordance with the illustrative embodiments, is used to route service requests. As can be seen, when the instance of application FA begins executing at approximately time <b>1100</b>, the average response time for executing application instance ST shown in line <b>1104</b> shows a shorter average response time than the prior art load balancer.

0087<figref idref="DRAWINGS">FIG. 12</figref> is a graph illustrating a prior art performance response time for executing a financial application on a cluster. Graph <b>1200</b> is illustrating a performance response time for an application instance FA executing on nodes <b>402</b> and <b>406</b> in <figref idref="DRAWINGS">FIG. 4</figref> when a currently available load balancer is used to route service requests to servers.

0088Line <b>1202</b> is illustrating the performance of node <b>1</b><b>402</b> in <figref idref="DRAWINGS">FIG. 4</figref> when a server state change event occurs. As discussed above, the server state change is an instance of application FA <b>408</b> starting to execute on node <b>1</b><b>402</b>. Line <b>1204</b> illustrates the performance of node <b>3</b><b>406</b> when the server state change occurred on node <b>1</b><b>402</b> in <figref idref="DRAWINGS">FIG. 4</figref>. As can be seen in graph <b>1200</b> in <figref idref="DRAWINGS">FIG. 12</figref>, when an instance of application FA begins running in node <b>1</b> at approximately time <b>1100</b>, the performance of application instance FA in node <b>1</b> begins to deteriorate dramatically in comparison to the performance of application instance FA running on node <b>2</b> shown in line <b>1204</b>.

0089Referring now to <figref idref="DRAWINGS">FIG. 13</figref>, a graph illustrating an average performance response time for executing a financial application on a cluster is shown in accordance with an illustrative embodiment. Graph <b>1300</b> illustrates an average performance response time for an application instance FA executing on nodes <b>402</b> and <b>406</b> in <figref idref="DRAWINGS">FIG. 4</figref> when a state change event occurs. Line <b>1302</b> shows the average performance response time in the set of nodes when a prior art load balancer is used. Line <b>1304</b> shows an average performance response time when a load balancer with state change awareness in accordance with the illustrative embodiments is used to route service requests. As can be seen, when the instance of application FA begins executing at approximately time <b>1100</b>, the average response time for executing application instance FA across all nodes currently executing application FA shows a shorter or faster average response time than the prior art load balancer, as can be seen in shown in line <b>1304</b>. In other words, the illustrative embodiments can equalize the average service performance time for service requests destined to the same application across a server cluster.

0090Thus, the illustrative embodiments detect the change in state before the peak in line <b>1302</b> indicating a decrease in performance. The illustrative embodiments detect the change through feedback and feed-forward control and adjust routing weights for the servers to compensate for the anticipated performance impact on the servers. Thus, line <b>1304</b> showing the average performance in the nodes using a load balancer, in accordance with the illustrative embodiments, does not show a peak slow down in response time as in the prior art method. Rather, the illustrative embodiments avoid the performance declines by adjusting routing weights to maintain processing performance in all nodes closer to the mean or average response time.

0091Thus, the illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code for load balancing in a computer cluster. In one embodiment, a weight adjustment value for a server is identified in response to receiving a notification of an impending state change event in the server. The weight adjustment is communicated to a load balance controller. The load balance controller generates an adjusted routing weight for the server using the weight adjustment. An incoming service request is routed to a selected server in the cluster based on the adjusted routing weight for each server in the cluster.

0092Thus, the illustrative embodiments provide direct awareness of load balancers of server state changes in a computer data center. Load balancers use feedback controllers for reacting to performance measurements from the set of servers in the data center. The load balancer is also aware of feed-forward server state changes. Thus, managed server state changes are communicated to the load balancer directly from the appropriate manager ahead of the time of the server state change event or at the time of the server state change event.

0093The load balancer also detects events from the messaging system. This allows the load balancer to be provided with information about managed server state changes, such as duration and performance impact estimation. The load balancer is able to specify load change policies corresponding to the server state change events, such as decreasing traffic to a given server by fifty percent (50%) when a new application starts running on that server and/or increase traffic by twenty percent (20%) to a server when an application completes execution on that server. The load balancer also includes a load balance controller to implement load change policies after the weights are computed by a weight adjuster feedback controller in the load balancer.

0094In this manner, the illustrative embodiments use feedback and feed-forward control to equalize the service times of requests destined to the same application. As shown in <figref idref="DRAWINGS">FIGS. 8-13</figref>, a significant performance improvement during application placement changes can be achieved when using the improved load balancer of the illustrative embodiments.

0095The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

0096The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

0097Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any tangible apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

0098The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.

0099A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

0100Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.

0101Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

0102The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.