Abstract:
A system for and a method of empirically measuring the capacity of multiple servers in a cluster including at least one capacity prober for measuring the load capacity of each server and for forwarding the relative weights to a load balancer for the cluster. During off peak operating hours, one at a time each server in the cluster is taken off line and stress tested to measure the capacity of the server. The remaining servers in the cluster remain on line to service customers. The relative weights for each of the servers are collected and updated in the load balancer. In this way, the operation of the cluster is better optimized.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of Invention 
     The present invention relates generally to the field of network server clusters and pertains more particularly to a system for and a method of empirically measuring the capacity of multiple servers in a cluster and forwarding the relative weights for each server to a load balancer for the cluster. 
     2. Discussion of the Prior Art 
     Since at least as early as the invention of the first computer system, people have endeavored to link computers together. Linking computers together in a network allows direct communication between the various points of the network and sharing of resources, such as servers, among the points of the network. This was especially desirable early on because computers were very large and very expensive. Today, computers are far more prevalent, but the desire to link them together is still strong. This is most readily demonstrated by the explosive growth of the Internet. 
     Servers are commonly employed for sharing of information among large numbers of computer systems or similar devices. A computer system that communicates with a server is usually referred to as a client of the server and the server is often part of a host system. A client and a host typically exchange messages via a communication network using a predetermined protocol. Such protocols are usually arranged in a client/host model in which a requesting client transfers a request message to a host and the host in turn takes an appropriate action depending on the content of the request message. Typically, the appropriate action for the request message includes the transfer of a response message to the requesting client. 
     Current protocols typically do not allow for the establishment of a persistent session between the client and the host in the traditional sense in which a local terminal establishes a session on a computer system. Instead, any session-like information is usually implied in the content of the messages exchanged between the client and the host. Such a communication protocol may be referred to as a “stateless” protocol. Such stateless protocols include protocols associated with Internet communication including the Internet Protocol (IP), the User Datagram Protocol (UDP), the Simple Mail Transfer Protocol (SMTP), and the Hypertext Transfer Protocol (HTTP), as well as the Network File System (NFS) Protocol. 
     A client that accesses a host commonly engages in an extended transaction with the host. Such an extended transaction typically involves the exchange of multiple messages between the client and the host. For example, an NFS client typically issues multiple request messages to an NFS server while retrieving a file from the NFS server. Similarly, an HTTP client typically issues multiple request messages to an HTTP server while browsing through web pages contained on the HTTP server. Such transactions that involve the exchange of multiple messages between a client and a server are hereinafter referred to as sessions. 
     Servers commonly have a large pool of potential clients which may issue request messages. For example, an HTTP server connected to the world-wide-web has potentially millions of clients from which it may receive request messages. Current servers that are adapted for stateless protocols typically respond to each request message in the order in which it is received, that is, on a first-come-first-served basis regardless of the source of the request message. 
     In the present context, the term “quality of service” refers both a host&#39;s ability to provide quick response to a message and to complete an entire session. As a particular host becomes more popular, and due to that popularity receives more messages, the processing resources of the host can become stretched. For example, due to heavy traffic, a host may not be able to respond to a message at all, or the host may not provide a timely response which can cause a client to “time-out” and generate an error. Poor quality of service can have significant results, as users may become frustrated and simply give up trying to reach a particular host, or the sponsor of the host may lose sales or fail to communicate needed information to any or all clients. 
     One technique that is generally used to alleviate quality of service problems is to add more processing capacity to the host. This can be done typically by either replacing the host with another, more powerful computer, or by providing multiple computers in parallel as a server cluster and delegating new messages to different ones of the multiple servers. When multiple servers are used in a cluster a load balancer is used to allocate the demand to the various servers. Demand is allocated by assigning each server a value called a relative weight. The relative weight determines what proportion of the traffic each server in the cluster carries. Generally, it is the case that the higher the relative weight then the higher the load. When the cluster is made up of identical servers, then the relative weights are typically equal to one another. This is because the servers should theoretically be able to handle equal loads. 
     When the cluster is made up of different servers, then the situation becomes more complicated. The use of a heterogeneous cluster of servers is common because demand on the host grows over time. The problem is that, when one goes to add a server to the cluster, the state of the art in computers has changed. Either one can no longer get the same computer as before or one chooses not to. Few can afford to replace the entire cluster just to add one new computer. The result is that different servers are used. The complication lies in determining what relative weights to assign the servers in the cluster. Conventionally, two techniques have been used. First, the servers are theoretically modeled based on design parameters and the relative weights are calculated based on the models. Second, the relative weights are determined based on ad hoc cluster operation. This means that the relative weights are set to an initial value and the cluster is put into operation. Later, if and when the operator of the cluster notices that a problem exists, then the relative weights are adjusted based on an educated guess of what would help to alleviate the problem. Neither technique is ideal. 
     A definite need exists for a system having an ability to empirically measure the capacity of multiple servers and forward the relative weights to the load balancer. In particular, a need exists for a system which is capable of performing a capacity test on each server in the cluster. Ideally, such a system would operate by measuring a server&#39;s load capacity and assigning a relative weight accordingly. With a system of this type, load balancing would provide a reliable means of fairly sharing network resources. A primary purpose of the present invention is to solve this need and provide further, related advantages. 
     SUMMARY OF THE INVENTION 
     A system for and a method of empirically measuring the capacity of multiple servers in a cluster is disclosed including at least one capacity prober for measuring the load capacity of each server and for forwarding the relative weights to a load balancer for the cluster. During off peak operating hours, one at a time each server in the cluster is taken off line and stress tested to measure the capacity of the server. The remaining servers in the cluster remain on line to service customers. The relative weights for each of the servers are collected and updated in the load balancer. In this way, the operation of the cluster is better optimized. 
    
    
     BRIEF DESCRIPTION OF THE DRAWING 
     The above and other objects and advantages of the present invention will be more readily appreciated from the following detailed description when read in conjunction with the accompanying drawing, wherein: 
     FIG. 1 is a block diagram of a system for empirically measuring the capacity of multiple servers in a cluster having a capacity prober which is centralized; 
     FIG. 2 is a block diagram of a system for empirically measuring the capacity of multiple servers in a cluster having a capacity prober which is distributed; and 
     FIG. 3 is a flow diagram of the method of empirically measuring the capacity of multiple servers in a cluster according to one embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     A purpose of the present invention is to provide a reliable means of fairly sharing network resources. Turning first to FIG. 1, a block diagram of a system  10  for empirically measuring the capacity of multiple servers in a cluster  12  having a capacity prober  14  which is centralized is shown. The system includes the cluster  12 , the capacity prober  14 , and a load balancer  16 . The cluster  12  includes a network  18  and in this case four servers  20 ,  22 ,  24 ,  26 . Four was chosen for exemplary purposes only, the cluster will contain at least two servers and may contain more as is desired and practical. The four servers can be any conventional hardware running any conventional server software. The network  18  can operate according to any of a number of conventional protocols. The load balancer  16  can be any conventional hardware and utilizes the relative weights  28  provided to it. Here, since there are four servers, there are four relative weights. Initially, the relative weights  28  will each have a value that will be referred to as weight old . The source and actual value of the initial weights does not affect the present invention. 
     The capacity prober  14  may be hardware, software, or a combination of both. The capacity prober  14  may be a separate or stand alone device as shown or it may be integral to one of the four servers  20 ,  22 ,  24 ,  26  or to the load balancer  16 . The capacity prober will access the four servers and the load balancer via the network  18  as necessary. The functions of the capacity prober will be further outlined with respect to FIG. 3 below. 
     Turning now to FIG. 2, a block diagram of a system  30  for empirically measuring the capacity of multiple servers in a cluster  12  having a capacity prober which is distributed is shown. The system  30  of FIG. 2 is the same as the system  10  of FIG. 1 except that each server  20 ,  22 ,  24 ,  26  includes a capacity prober  14 A,  14 B,  14 C,  14 D, respectively. One of the capacity probers, in this case a master capacity prober  14 B, directs and coordinates the other capacity probers  14 A,  14 C,  14 D, respectively. In system  10  of FIG. 1, the capacity prober  14  performs a capacity test for each server over the network. This has the benefit of being easy to retrofit to an existing system through the addition of one device including the capacity prober. In system  30 , the capacity probers each test their respective server only and report their results to the master capacity prober. This has the benefit, over system  10 , of reducing network traffic during testing of the servers. The cost is purchasing or updating to servers which include the capacity probers. A combination of systems  10  and  30  is also possible, but coordination of the capacity probers becomes more complex. For this reason, such a combination is not presently preferred. 
     Turning now to FIG. 3, a flow diagram of the method of empirically measuring the capacity of multiple servers in a cluster according to one embodiment of the present invention is shown. The process begins at START. At block  32 , the capacity prober selects one of the servers in the cluster for capacity testing. At block  34 , the capacity prober performs a capacity test on the selected server. First, the capacity prober notes the initial relative weight for the selected server, that is, weight old , and sets the relative weight for the selected server to zero in the load balancer. This has the effect of taking the selected server out of service as far as the cluster is concerned. This is why it is necessary to run the capacity tests at off peak times to avoid serious overload of the cluster. Second, the capacity prober stresses the selected server. This can be accomplished by running any of a number of workload sets. For more concrete results, a workload set derived from the log of actual requests for an earlier time period can be used. Third, the capacity prober measures the performance of the selected server to determine the respective ability of the selected server to handle a workload. Fourth, the capacity prober sets the relative weight for the selected server back to weight old . in the load balancer. This has the effect of putting the selected server back into service. At decision block  36 , the capacity prober determines if all of the servers in the cluster have been selected. The blocks  32 ,  34 , and  36  are repeated until all of the servers have been selected and tested. Eventually, the process proceeds to block  38  where the capacity prober sets the respective weights for all of the servers in the cluster to the new relative weight, that is, weight new , in the load balancer. The value of weight new  will vary with each server in the cluster and is based on the findings of the testing. The result is better load balancing which provides a reliable means of fairly sharing network resources. 
     As an example, apply the flow diagram of FIG. 3 to system  10  of FIG.  1 . At block  32 , the capacity prober  14  might select server  1  (reference numeral  20 ). At block  34 , the capacity prober performs the capacity test on server  1 . First, the capacity prober notes the initial relative weight for server  1 , that is, weight 1   old , and sets the relative weight for server  1  to zero in the load balancer  16 . Second, the capacity prober stresses server  1 . Third, the capacity prober measures the performance of server  1  to determine the respective ability of server  1  to handle a workload. Fourth, the capacity prober sets the relative weight for server  1  back to weight 1   old  in the load balancer. At decision block  36 , the capacity prober determines that all of the servers in the cluster have not been selected. The process then returns to block  32  where server  2  (reference numeral  22 ) is selected. Then blocks  32 ,  34 , and  36  are repeated until all of the servers have been selected and tested. Eventually, the process proceeds to block  38  where the capacity prober sets the respective weights for all of the servers in the cluster to the new relative weight, that is, weight new , in the load balancer. 
     As a further example, apply the flow diagram of FIG. 3 to system  30  of FIG.  2 . At block  32 , the master capacity prober  14 B might select server  1  (reference numeral  20 ). At block  34 , the master capacity prober  14 B and capacity prober  14 A perform the capacity test on server  1 . First, the master capacity prober  14 B notes the initial relative weight for server  1 , that is, weight 1   old , and sets the relative weight for server  1  to zero in the load balancer  16 . Second, the capacity prober  14 A stresses server  1 . Third, the capacity prober  14 A measures the performance of server  1  to determine the respective ability of server  1  to handle a workload and reports the findings to the master capacity prober  14 B. Fourth, the master capacity prober  14 B sets the relative weight for server  1  back to weight 1   old  in the load balancer. At decision block  36 , the master capacity prober determines that all of the servers in the cluster have not been selected. The process then returns to block  32  where server  2  (reference numeral  22 ) is selected. Since the master capacity prober resides in server  2 , it performs the capacity test of server  2  itself. Then blocks  32 ,  34 , and  36  are repeated until all of the servers have been selected and tested. Eventually, the process proceeds to block  38  where the master capacity prober sets the respective weights for all of the servers in the cluster to the new relative weight, that is, weight new , in the load balancer. 
     It is important to note that, under either of the examples above, while one server is undergoing capacity testing, the other servers in the cluster are still available to service client requests. In this way, the entire cluster does not have to be taken down to perform the method of the present invention. 
     While the invention has been illustrated and described by means of specific embodiments, it is to be understood that numerous changes and modifications may be made therein without departing from the spirit and scope of the invention as defined in the appended claims and equivalents thereof.