US20050050198A1 - Computer system and method for service load distributing - Google Patents
Computer system and method for service load distributing Download PDFInfo
- Publication number
- US20050050198A1 US20050050198A1 US10/926,310 US92631004A US2005050198A1 US 20050050198 A1 US20050050198 A1 US 20050050198A1 US 92631004 A US92631004 A US 92631004A US 2005050198 A1 US2005050198 A1 US 2005050198A1
- Authority
- US
- United States
- Prior art keywords
- service
- computers
- computer
- execution
- parallel
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
Definitions
- the present invention relates to a computer system including a plurality of computers and executing a plurality of services (works). More particularly, the present invention relates to a computer system and method for service load distributing in asymmetrical resource environments.
- Server load distributing systems are well known in which service execution requests issued from a number of client terminals are distributed to a plurality of computers to efficiently process the requests.
- Server load distributing systems of this type are described in, for example, Rajkumar Buyya, “High Performance Cluster Computing: Architecture and Systems (Vol. 1)”, Prentice-Hall, Inc., 1999, pp. 340 - 363 and in Tony Bourke, “Server Load Balancing”, O'Relly & Associates, Inc., pp. 3 - 31 , December 2001.
- These server load distributing systems generally comprise a plurality of sever computers having symmetrical (uniform) resource environments and a load distributing unit.
- the load distributing unit receives a request to execute a service from a client terminal via a network (external network). Upon receiving the request, the load distributing unit determines which one of the server computers should execute the service designated by the client terminal. Selection is performed to avoid concentration of load on a particular server computer. That is, the load distributing unit distributes the execution of services of the same type to a plurality of computers.
- the server load distributing system employs one of the following methods to determine which computer should execute a service, i.e., to schedule services: (1) round-robin scheduling, (2) weighted round-robin scheduling, (3) a minimum connection method and (4) a fastest method.
- Round-robin scheduling is a method for uniformly selecting each server computer in a certain order.
- Weighted round-robin scheduling is a method based on round-robin scheduling, in which the frequency of selection of each server computer is determined in accordance with the capacity of each server computer. Accordingly, in weighted round-robin scheduling, a weight (selection frequency) corresponding to its capacity is assigned to each computer.
- the minimum connection method is for selecting a computer that has been connected a minimum number of times (for a minimum session) so far.
- the fastest method is for selecting a computer of a fastest response at the present stage.
- the load distributing unit determines which server computer should execute a service, using one of the above methods (1) to (4). Subsequently, the load distributing unit sends a request to execute the service, issued from a client computer, to the selected server computer via a network (internal network). Upon receiving the request, the selected server computer executes the service, and sends a response to the load distributing unit. The load distributing unit returns the response from the server computer to the client terminal, i.e., the request issuer.
- the load distributing unit monitors a response from each server computer.
- the load distributing unit detects a timeout that occurs when no response is returned from a server computer even after a predetermined time elapses. When detecting it, the load distributing unit determines that a failure has occurred in the server computer.
- the server computer failure includes a failure in a server computer itself, and a failure related to execution of a service by a server computer. When the load distributing unit detects a failure in a server computer, it does not allocate a service to the server computer, thereby realizing a pared-down operation of the system.
- cluster systems comprise a plurality of computers having asymmetrical resource environments.
- services different in function i.e., different types of services
- This allocation is beforehand closely planned by a user.
- Computers in a cluster system access each other via a network to detect any failure in computers currently executing services.
- the cluster system Upon detection of a failure, the cluster system executes re-scheduling (fail-over), i.e., reallocates, to another computer, the service that is being executed by the computer from which the failure has been detected. This can reduce the service (work) interruption time, thereby realizing high availability (server operation rate, business execution rate) called “HA”.
- HA cluster system This type of cluster system is called an “HA cluster system”.
- a cluster system re-allocates a service to a standby computer. In this case, the loads on computers are not considered for scheduling services.
- cluster systems of a static ticket type are also well known. In cluster systems of this type, a user sets a processing capacity (ticket) for each computer in the cluster system. Further, a processing capacity (ticket) needed for executing a service is set in units of services.
- Cluster systems of a static ticket type perform control, by setting a ticket, so as not to allocate, to a particular computer, services that exceeds the processing capacity of the computer.
- the conventional server load distributing systems can perform dynamic load distributing to a plurality of server computers having symmetrical resource environments.
- the conventional server load distributing systems cannot perform dynamic load distributing to a plurality of server computers having complex asymmetrical resource environments, i.e., cannot perform reliable control of execution of services that operate in complex asymmetrical resource environments.
- the conventional server load distributing systems cannot promptly detect a failure in a computer since they perform failure detection upon timeout of a response from the computer.
- load distributing is realized by user's close planning of functional load distributing.
- it is realized by a static ticket system in which a predetermined ticket is allocated in units of services. Accordingly, conventional cluster systems having asymmetrical resource environments cannot perform dynamic load distributing. Further, in the static ticket system, service allocation that is not suitable for the present status of loading may be performed.
- a computer system including a plurality of computers and executing a plurality of types of services.
- This computer system comprises service load monitor means, node load monitor means and service optimal allocation means.
- the service load monitor means measures, as a service load, a load required to execute services in each of the computers.
- the node load monitor means measures, as a node load, a load on each of the computers.
- the service optimal allocation means determines an optimal computer included in the computers to execute services, and a service to be reallocated to the optimal computer, based on measurement results of the service load monitor means and the node load monitor means, and reallocates the determined service to the determined optimal computer.
- FIG. 1 is a block diagram illustrating the configuration of a cluster system according to an embodiment of the invention
- FIG. 3 is a flowchart useful in explaining the procedure of adjusting the number of executions of a parallel-execution-type service PSVC used in the embodiment.
- FIG. 4 is a flowchart useful in explaining the procedure of optimally arranging services (HA type services or parallel-execution-type services).
- FIG. 1 is a block diagram illustrating the configuration of a cluster system according to the embodiment of the invention.
- the cluster system of FIG. 1 comprises four computers (server computers) 10 - 1 to 104 .
- the computers 10 - 1 to 10 - 4 are connected to each other via a network (internal network) 20 used for communication between them.
- a network (external network) used for communication between the computers 10 - 1 to 10 - 4 and client terminals (not shown) is not shown.
- a request to execute a service i.e., an application for realizing a service
- a service i.e., an application for realizing a service
- a single network may be used for communication between the computers 10 - 1 to 10 - 4 and between each computer 10 - 1 to 10 - 4 and each client computer. However, in this case, the communication traffic volume of the network is inevitably increased.
- a cluster control machine 12 operates in the cluster system formed of the computers 10 - 1 to 10 - 4 .
- the cluster control machine 12 is a virtual machine realized by the united (synchronous) operation of the respective cluster control units (not shown) of the computers 10 - 1 to 10 - 4 . Therefore, it can be considered that the cluster control machine 12 exists between the computers 10 - 1 to 10 - 4 .
- Each cluster control unit is realized when the corresponding computer 10 - i reads and executes a cluster control program (cluster software) including a service load distributing program.
- the cluster control program (cluster software) can be prestored in a computer-readable storage medium (e.g., a magnetic disk represented by a floppy (trademark) disk, an optical disk represented by a CD-ROM, DVD, etc., and a semiconductor memory represented by a flash memory), and can be distributed in the form of the storage medium. Further, this program may be downloaded (distributed) via a network.
- the cluster control machine 12 can promptly detect any failure in the computers when the cluster control units of the computers 10 - 1 to 10 - 4 operate in synchronism with each other while accessing each other.
- the cluster control machine 12 comprises a service optimal allocation machine 121 and service control machine 122 .
- the service optimal allocation machine 121 is realized when service optimal allocation units (not shown) provided in the computers 10 - 1 to 10 - 4 operate in synchronism with each other while accessing each other.
- the service optimal allocation machine 121 has a function for determining an optimal computer for execution of a service when a failure has occurred in a computer that is executing the service, or when the load of the service has changed.
- the service optimal allocation machine 121 also has a function for reallocating a service to the determined optimal computer.
- the service optimal allocation machine 121 further has a function for adjusting, to an optimal value, the number of executions of a service (parallel-execution-type service PSVC) executed in parallel by a parallel-execution-type service executing machine 13 , described later.
- the service control machine 122 is realized when service control units (not shown) provided in the computers 10 - 1 to 10 - 4 operate in synchronism with each other while accessing each other.
- the service control machine 122 has a function for switching a service over to the computer determined by the service optimal allocation machine 121 , under the control of the service optimal allocation machine 121 .
- the parallel-execution-type service executing machine 13 operates.
- the parallel-execution-type service executing machine 13 is controlled by the cluster control machine 12 .
- the parallel-execution-type service executing machine 13 is a virtual machine realized by the computers 10 - 1 to 10 - 4 , and can be considered to exist therebetween.
- the parallel-execution-type service executing machine 13 has a function for executing a service PSVC in parallel on some of the computers 10 - 1 to 10 - 4 (nodes).
- Such a service PSVC as can be executed in parallel by the parallel-execution-type service executing machine 13 is called a parallel-execution-type service.
- FIG. 1 shows a case where the number of parallel executions of the parallel-execution-type service PSVC (the number of services simultaneously executed in the computers used) is 2. That is, in the case of FIG. 1 , concerning the execution of the service PSVC, the computers 10 - 3 and 10 - 4 are operating, while the computers 10 - 1 and 10 - 2 are in a standby state. In other words, in the case of FIG. 1 , the parallel-execution-type service executing machine 13 is executing a parallel-execution-type service PSVC in parallel in the computers 10 - 3 and 10 - 4 .
- a parameter value called static service ticket value SST PSVC is preset for a parallel-execution-type service PSVC (an application for realizing a parallel-execution-type service PSVC).
- Static service ticket value SST PSVC indicates the amount of resources pre-estimated to be needed for executing the parallel-execution-type service PSVC in the computer 10 - i .
- the resource amount indicates a static load required by the service PSVC.
- a user presets a minimum number N min of services.
- the minimum number N min indicates a minimum number of parallel executions of the parallel-execution-type service PSVC.
- the minimum number N min also indicates a minimum number of computers (nodes) used to execute the parallel-execution-type service PSVC in parallel.
- the parallel-execution-type service executing machine 13 includes service load monitors 131 - 1 to 131 - 4 operable in the computers 10 - 1 to 10 - 4 .
- Each service load monitor 131 - i measures the use of resources while the corresponding computer 10 - i is executing the parallel-execution-type service PSVC. Based on the currently measured resource use, each service load monitor 131 - i estimates the amount of resources needed for completing the execution of the parallel-execution-type service PSVC. The estimated amount of resources indicates a dynamic load required by the service PSVC. From the estimated amount of resources, each service load monitor 131 - i acquires dynamic service ticket value DST PSVCi that indicates a dynamic load required by the service PSVC, and sends it to the cluster control machine 12 .
- HA-type service execution units 141 - 1 to 141 - 4 for executing HA-type services SVC 1 are operable.
- HA-type service execution units 142 - 1 to 142 - 4 for executing HA-type services SVC 2 are also operable.
- the HA-type service execution units 141 - 1 to 141 - 4 and 142 - 1 to 142 - 4 are controlled by the cluster control machine 12 .
- HA-type services are services (applications) to be subjected to fail-over under the control of the cluster control machine 12 .
- Each of HA-type services can be executed by only one of the computers 10 - 1 to 10 - 4 in a single time zone.
- FIG. 1 concerning the execution of the HA-type service SVC 1 , only the HA-type service execution unit 141 - 1 of the computer 10 - 1 is operating, and the other HA-type service execution units 141 - 2 to 141 - 4 of the computers 10 - 2 to 10 - 4 are in the standby state.
- static service ticket values SST SVC1 and SST SVC2 are preset, respectively.
- the static service ticket values SST SVC1 and SST SVC2 are parameter values indicating the respective amounts of resources needed for the HA service execution units 141 - i and 142 - i of the computer 10 - i to execute the HA services SVC 1 and SVC 2 .
- the HA service execution units 141 - 1 to 141 - 4 and 142 - 1 to 142 - 4 include service load monitors 151 - 1 to 151 - 4 and 152 - 1 to 152 - 4 , respectively.
- the service load monitors 151 - i and 152 - i measure respective resource use when the computer 10 - i is executing the services SVC 1 and SVC 2 .
- the monitors 151 - i and 152 - i estimate the amounts of resources needed for the computer 10 - i to execute the services SVC 1 and SVC 2 .
- the estimated resource amounts indicate the dynamic loads required by the services SVC 1 and SVC 2 .
- the service load monitors 151 - i and 152 - i acquire the dynamic service ticket values DST SVC1i and DST SVC2i indicating the dynamic loads required by the services SVC 1 and SVC 2 , respectively.
- the service load monitors 151 - i and 152 - i report the dynamic service ticket values DST SVC1i and DST SVC2i to the cluster control machine 12 , respectively.
- node load monitors 16 - 1 to 16 - 4 operate, respectively.
- static node ticket values SNT 1 to SNT 4 indicating the processing capacities (resource amounts) of the computers (nodes) 10 - 1 to 10 - 4 , respectively, are preset.
- the computers 10 - 1 to 10 - 4 have asymmetrical resource environments. Therefore, the computers 10 - 1 to 10 - 4 have different static node ticket values SNT 1 to SNT 4 .
- the node load monitors 16 - 1 to 16 - 4 calculate dynamic node ticket values DNT 1 to DNT 4 from the sums TST 1 to TST 4 (hereinafter referred to as the “total service ticket value”) of the ticket values of all services executed in the computers 10 - 1 to 10 - 4 , and static node ticket values SNT 1 to SNT 4 .
- the calculation of dynamic node ticket values DNT 1 to DNT 4 is carried out each time a preset inspection time is reached.
- Dynamic node ticket values DNT 1 to DNT 4 indicate resource amounts that can be newly used by the computers 10 - 1 to 10 - 4 .
- the node load monitors 16 - 1 to 16 - 4 report dynamic node ticket values DNT 1 to DNT 4 to the cluster control machine 12 .
- the corresponding service load monitor 131 - i operates, for example, periodically each time a preset inspection time is reached.
- the service load monitor 131 - i measures the amount of resources used by the computer 10 - i when it is executing the service PSV thereon.
- the service load monitor 131 - i calculates dynamic service ticket value DST PSVCi that indicates an estimated resource amount needed for the computer 10 - i to execute the parallel-execution-type service PSVC.
- three estimation functions f(x), g(y) and h(z) are used for the calculation of dynamic service ticket value DST PSVCi .
- the three estimation functions f(x), g(y) and h(z) are functions for acquiring the use of three resources in the computer 10 - i , e.g., the amount x of use of a CPU, the amount y of use of a memory and a response time z.
- the response time z is a period ranging from the time at which the computer 10 - i receives, from a client terminal, a request to execute a service s, to the time at which it returns, to the client terminal, a response indicating the result of the execution.
- Dynamic service ticket value DST PSVCi calculated by each service load monitor 131 - i is reported to the cluster control machine 12 .
- the service load monitors 151 - i and 152 - i operates, for example, periodically each time a preset inspection time is reached, when the HA-type service execution units 141 - i and 142 - i are executing HA-type services SVC 1 and SVC 2 , respectively.
- the service load monitors 151 - i and 152 - i calculate, like the service load monitors 131 - i , dynamic service ticket values DST SVC1i and DST SVC2i based on the current resource use. Dynamic service ticket values DST SVC1i and DST SVC2i indicate the estimated amounts of resources needed for the computer 10 - i to execute the services SVC 1 and SVC 2 .
- Dynamic service ticket values DST SVC1i and DST SVC2i are given by the equation (1), like dynamic service ticket values DSTpSvCi. In this case, however, s in the equation (1) represents SVC 1 or SVC 2 . Dynamic service ticket values DST SVC1i and DST SVC2i calculated by the service load monitors 151 - i and 152 - i , respectively, are reported to the cluster control machine 12 .
- the program proceeds to step S 3 .
- Total service ticket value TST i indicates the maximum resource amount that may be used by all services currently executed in the computer 10 - i , i.e., the entire load on the computer 10 - i (the entire node load).
- the node load monitor 16 - i After the node load monitor 16 - i acquires total service ticket value TST i for all services currently executed in the computer 10 - i , the program proceeds to step 64 .
- dynamic node ticket value DNT i is calculated by subtracting total service ticket value TST i from static node ticket value SNT i .
- the node load monitor 16 - i repeats periodically (i.e., at regular intervals) the above-described processing (steps S 1 to S 4 ).
- the service optimal allocation machine 121 calculates the number (hereinafter referred to as the “optimal number of services”) OSN of parallel executions of the parallel-execution-type service PSVC (step S 11 ).
- the optimal number OSN is calculated, in the manner described below, based on dynamic service ticket value DSTpSVCi in each computer (node) 10 - i , static service ticket value SST PSVC and the minimum number N min of services.
- the service optimal allocation machine 121 determines whether computers 10 - j (j is 1, 2, 3 or 4) that can newly execute the parallel-execution-type service PSVC are included in the computers 10 - 1 to 10 - 4 of the system (step S 13 ). If such computers 10 - j are included, the service optimal allocation machine 121 proceeds to step S 14 . At step S 14 , the service optimal allocation machine 121 selects one of the computers 10 - j in which the difference between static and dynamic node ticket values SNT j and DNT j is largest, and makes the selected computer execute the service PSVC. After that, the service optimal allocation machine 121 returns to step S 11 .
- the machine 121 selects a computer from the service-executable computers 10 - j in the order beginning from the largest difference between static and dynamic node ticket values SNT j and DNT j , and makes the selected computer start to execute the service PSVC. This operation is repeated until the optimal number OSN reaches the current number CSN. On the other hand, if there is no service-executable computer 10 - j (step S 13 ), the machine 121 sleeps for a predetermined time (step S 15 ), and then returns to step S 11 .
- the service optimal allocation machine 121 determines whether computers 10 - j (j is 1 , 2 , 3 or 4 ) that can stop the currently executed parallel-execution-type service PSVC are included in the computers 10 - 1 to 10 - 4 of the system (step S 17 ). If such computers 10 - j are included, the service optimal allocation machine 121 proceeds to step S 18 . At step S 18 , the service optimal allocation machine 121 selects one of the computers 10 - j in which the difference between static and dynamic node ticket values SNT j and DNT j is smallest, and makes the selected computer stop the execution of the service PSVC.
- the service optimal allocation machine 121 returns to step S 11 .
- the machine 121 selects a computer from the service-executable computers 10 - j in the order beginning from the smallest difference between static and dynamic node ticket values SNT j and DNT j , and makes the selected computer stop the execution of the service SVC. This operation is repeated until the optimal number OSN reaches the current number CSN.
- the machine 121 sleeps for a predetermined time (step S 15 ), and then returns to step S 11 .
- the optimal number OSN indicating the optimal number of parallel executions of the parallel-execution-type service PSVC executed in parallel in the cluster system is calculated based on dynamic service ticket value DST PSVCi in each computer 10 - i , static service ticket value SST PSVC and minimum number N min .
- the number of executions of the parallel-execution-type service PSVC is adjusted in accordance with the difference between the calculated optimal number OSN and the current number CSN (the number of the parallel-execution-type service PSVC currently executed in parallel).
- the number of executions of parallel-execution-type services can be adjusted appropriately even in the cluster system as shown in FIG. 1 and even if the computers 10 - 1 to 10 - 4 of the cluster system have asymmetrical environments.
- the service optimal allocation machine 121 searches the computers 10 - 1 to 10 - 4 for the computer 10 - j in which the value of (DNT j ⁇ ) is a preset value or less, i.e., in which dynamic node ticket value DNT j may be a preset value or less (step S 21 ).
- “ ⁇ ” indicates a margin for searching a computer 10 - j having dynamic node ticket value DNT j that is actually higher than the preset value but may well become the preset value or less.
- the preset value is zero.
- a computer 10 - j in which dynamic node ticket value DNT j may become a value less than the preset value may be searched for.
- step S 21 If it is determined at step S 21 that there is no corresponding computer 10 - j in which dynamic node ticket value DNT j may become the preset value or less, the service optimal allocation machine 121 sleeps for a predetermined time (step S 22 ), and then returns to step S 21 . If an event, such as a failure in a computer, occurs, the service optimal allocation machine 121 returns to step S 21 without sleeping.
- the service optimal allocation machine 121 selects, from the computers 10 - j , a computer 10 - j that is executing a service s of the lowest priority, and selects this service s (step S 23 ). Subsequently, the service optimal allocation machine 121 determines whether the selected service s can be switched over to another computer in the system (step S 24 ).
- services that can be switched over are preset. In other words, concerning each service, it is predetermined whether switching over is possible. In this case, the determination at step S 24 is achieved by determining whether the selected service s is included in the preset ones.
- the determination as to whether switching over is possible may be made in accordance with the execution state of the service s, for example, depending upon whether the service s is being processed in its critical area.
- Processing in a critical area means, for example, processing in which high response performance is required, or processing in which consistency (atomicity) is required, that is, processing that costs a lot for backtracking. Specifically, transaction processing, database updating processing, etc. are included.
- the service optimal allocation machine 121 searches the computers 10 - k for an optimal computer to which the selected service s is switched over in the manner described below (step S 25 ). Firstly, the service optimal allocation machine 121 searches for a computer 10 - k in which dynamic node ticket value DNT k is higher than MAX (SST s , DST sk ), based on dynamic node ticket value DNT k , static service ticket value SST s and dynamic service ticket value DST sk .
- MAX (SST s , DST sk ) indicates the higher one of the values SST s and DST sk . If a plurality of computers 10 - k are detected, the service optimal allocation machine 121 selects one of the computers 10 - k as an optimal computer to which the selected service s is switched over. It is advisable to select, as the optimal computer, a computer 10 - k that has the highest dynamic node ticket value DNT k . Alternatively, a computer 10 - k having DNT k that exceeds MAX (SST s , DST sk ) and closest to MAX (SST s , DST sk ) may be selected.
- the service optimal allocation machine 121 After an optimal computer, to which the selected service s is switched over, is detected (step S 26 ), the service optimal allocation machine 121 makes the optimal computer start to execute the service s (step S 27 ), and then returns to step S 21 . If no optimal computer can be detected (step S 26 ), the service optimal allocation machine 121 selects a computer 10 - j , which is executing a service s of the next lowest priority, from the computers 10 - j in which dynamic node ticket value DNT j may be the preset value or less, and selects this service s (step S 28 ). After that, the service optimal allocation machine 121 returns to step 24 .
- the service optimal allocation machine 121 determines whether the execution of the selected service s can be stopped (step S 29 ).
- services that can be stopped are preset. In other words, concerning each service, whether it can be stopped is preset. Alternatively, the determination as to whether the selected service s can be stopped may be performed depending upon the execution state of the service s.
- the service optimal allocation machine 121 stops its execution (step S 30 ). After that, the machine 121 returns to step S 21 . If, on the other hand, the execution of the selected service s cannot be stopped, the machine 121 selects a computer 10 - j , which is executing a service s of the next lowest priority, from the computers 10 - j in which dynamic node ticket value DNT j may be the preset value or less, and selects this service s (step S 31 ). After that, the machine 121 returns to step 24 .
- the service s executed in a computer 10 - j in which dynamic node ticket value DNT j may be a preset value or less, can be switched over to and executed by a computer 10 - k in which dynamic node ticket value DNT k is more than the higher one of the static service ticket value SST s and dynamic service ticket value DST sk .
- optimal load distributing is realized. That is, in the embodiment, if a failure occurs in a computer or a significant change occurs in service or node load, the service optimal allocation machine 121 automatically performs reallocation of services.
- FIG. 4 does not show the case where an optimal computer to which the selected service s is switched over is not detected even after steps S 24 , 25 , 26 and 28 are repeated. Similarly, FIG. 4 does not show the case where no stoppable service s is detected even after steps S 24 , 29 and 31 are repeated. In these cases, a user may perform setting in which, for example, other service s is switched over or stopped. If there is no optimal computer, the selected service may be stopped until an optimal computer is detected, or nothing may be done.
- a cluster system which can execute parallel-execution-type services as well as HA-type services.
- the present invention is not limited to such cluster systems, but is also applicable to a computer system (load distributing system) that can execute only parallel-execution-type services.
Abstract
Description
- This application is based upon and claims the benefit of priority from prior Japanese Patent Application No. 2003-306616, filed Aug. 29, 2003, the entire contents of which are incorporated herein by reference.
- 1. Field of the Invention
- The present invention relates to a computer system including a plurality of computers and executing a plurality of services (works). More particularly, the present invention relates to a computer system and method for service load distributing in asymmetrical resource environments.
- 2. Description of the Related Art
- Server load distributing systems are well known in which service execution requests issued from a number of client terminals are distributed to a plurality of computers to efficiently process the requests. Server load distributing systems of this type are described in, for example, Rajkumar Buyya, “High Performance Cluster Computing: Architecture and Systems (Vol. 1)”, Prentice-Hall, Inc., 1999, pp. 340-363 and in Tony Bourke, “Server Load Balancing”, O'Relly & Associates, Inc., pp. 3-31, December 2001. These server load distributing systems generally comprise a plurality of sever computers having symmetrical (uniform) resource environments and a load distributing unit. The load distributing unit receives a request to execute a service from a client terminal via a network (external network). Upon receiving the request, the load distributing unit determines which one of the server computers should execute the service designated by the client terminal. Selection is performed to avoid concentration of load on a particular server computer. That is, the load distributing unit distributes the execution of services of the same type to a plurality of computers.
- In general, the server load distributing system employs one of the following methods to determine which computer should execute a service, i.e., to schedule services: (1) round-robin scheduling, (2) weighted round-robin scheduling, (3) a minimum connection method and (4) a fastest method. Round-robin scheduling is a method for uniformly selecting each server computer in a certain order. Weighted round-robin scheduling is a method based on round-robin scheduling, in which the frequency of selection of each server computer is determined in accordance with the capacity of each server computer. Accordingly, in weighted round-robin scheduling, a weight (selection frequency) corresponding to its capacity is assigned to each computer. The minimum connection method is for selecting a computer that has been connected a minimum number of times (for a minimum session) so far. The fastest method is for selecting a computer of a fastest response at the present stage.
- The load distributing unit determines which server computer should execute a service, using one of the above methods (1) to (4). Subsequently, the load distributing unit sends a request to execute the service, issued from a client computer, to the selected server computer via a network (internal network). Upon receiving the request, the selected server computer executes the service, and sends a response to the load distributing unit. The load distributing unit returns the response from the server computer to the client terminal, i.e., the request issuer.
- The load distributing unit monitors a response from each server computer. The load distributing unit detects a timeout that occurs when no response is returned from a server computer even after a predetermined time elapses. When detecting it, the load distributing unit determines that a failure has occurred in the server computer. The server computer failure includes a failure in a server computer itself, and a failure related to execution of a service by a server computer. When the load distributing unit detects a failure in a server computer, it does not allocate a service to the server computer, thereby realizing a pared-down operation of the system.
- On the other hand, a computer system called a cluster system has come to be available, as is disclosed in “Cluster Software” by Tetsuo Kaneko and Ryoya Mori in Toshiba Review, Vol. 54, No. 12 (1999), pp. 18-21. In general, cluster systems comprise a plurality of computers having asymmetrical resource environments. In cluster systems, services different in function (i.e., different types of services) are allocated to a plurality of computers having asymmetrical resource environments. This allocation is beforehand closely planned by a user. Computers in a cluster system access each other via a network to detect any failure in computers currently executing services. Upon detection of a failure, the cluster system executes re-scheduling (fail-over), i.e., reallocates, to another computer, the service that is being executed by the computer from which the failure has been detected. This can reduce the service (work) interruption time, thereby realizing high availability (server operation rate, business execution rate) called “HA”. This type of cluster system is called an “HA cluster system”.
- In general, a cluster system re-allocates a service to a standby computer. In this case, the loads on computers are not considered for scheduling services. Further, cluster systems of a static ticket type are also well known. In cluster systems of this type, a user sets a processing capacity (ticket) for each computer in the cluster system. Further, a processing capacity (ticket) needed for executing a service is set in units of services. Cluster systems of a static ticket type perform control, by setting a ticket, so as not to allocate, to a particular computer, services that exceeds the processing capacity of the computer.
- As described above, the conventional server load distributing systems can perform dynamic load distributing to a plurality of server computers having symmetrical resource environments. However, the conventional server load distributing systems cannot perform dynamic load distributing to a plurality of server computers having complex asymmetrical resource environments, i.e., cannot perform reliable control of execution of services that operate in complex asymmetrical resource environments. Furthermore, the conventional server load distributing systems cannot promptly detect a failure in a computer since they perform failure detection upon timeout of a response from the computer.
- On the other hand, in conventional cluster systems that have asymmetrical resource environments, load distributing is realized by user's close planning of functional load distributing. Alternatively, it is realized by a static ticket system in which a predetermined ticket is allocated in units of services. Accordingly, conventional cluster systems having asymmetrical resource environments cannot perform dynamic load distributing. Further, in the static ticket system, service allocation that is not suitable for the present status of loading may be performed.
- In accordance with an embodiment of the invention, there is provided a computer system including a plurality of computers and executing a plurality of types of services. This computer system comprises service load monitor means, node load monitor means and service optimal allocation means. The service load monitor means measures, as a service load, a load required to execute services in each of the computers. The node load monitor means measures, as a node load, a load on each of the computers. The service optimal allocation means determines an optimal computer included in the computers to execute services, and a service to be reallocated to the optimal computer, based on measurement results of the service load monitor means and the node load monitor means, and reallocates the determined service to the determined optimal computer.
- The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention, and together with the general description given above and the detailed description of the embodiments given below, serve to explain the principles of the invention.
-
FIG. 1 is a block diagram illustrating the configuration of a cluster system according to an embodiment of the invention; -
FIG. 2 is a flowchart useful in explaining the procedure of calculation of dynamic node ticket value DNTi by a node load monitor 16-i (i=1, 2, 3, 4); -
FIG. 3 is a flowchart useful in explaining the procedure of adjusting the number of executions of a parallel-execution-type service PSVC used in the embodiment; and -
FIG. 4 is a flowchart useful in explaining the procedure of optimally arranging services (HA type services or parallel-execution-type services). - An embodiment of the invention will be described in detail with reference to the accompanying drawings.
FIG. 1 is a block diagram illustrating the configuration of a cluster system according to the embodiment of the invention. The cluster system ofFIG. 1 comprises four computers (server computers) 10-1 to 104. The computers 10-1 to 10-4 are connected to each other via a network (internal network) 20 used for communication between them. InFIG. 1 , a network (external network) used for communication between the computers 10-1 to 10-4 and client terminals (not shown) is not shown. A request to execute a service (i.e., an application for realizing a service) issued from a client terminal is transmitted to the cluster system ofFIG. 1 via the external network. The computer 10-i (i=1, 2, 3, 4) of the cluster system executes a service designed by a request from a client computer. After executing the service, the computer 10-i returns a response indicating the execution result to the client terminal via the external network. A single network may be used for communication between the computers 10-1 to 10-4 and between each computer 10-1 to 10-4 and each client computer. However, in this case, the communication traffic volume of the network is inevitably increased. - In the computers 10-1 to 10-4, their respective operating systems (OSs) 11-1 to 11-4 operate. In the cluster system formed of the computers 10-1 to 10-4, a
cluster control machine 12 operates. Thecluster control machine 12 is a virtual machine realized by the united (synchronous) operation of the respective cluster control units (not shown) of the computers 10-1 to 10-4. Therefore, it can be considered that thecluster control machine 12 exists between the computers 10-1 to 10-4. Each cluster control unit is realized when the corresponding computer 10-i reads and executes a cluster control program (cluster software) including a service load distributing program. The cluster control program (cluster software) can be prestored in a computer-readable storage medium (e.g., a magnetic disk represented by a floppy (trademark) disk, an optical disk represented by a CD-ROM, DVD, etc., and a semiconductor memory represented by a flash memory), and can be distributed in the form of the storage medium. Further, this program may be downloaded (distributed) via a network. Thecluster control machine 12 can promptly detect any failure in the computers when the cluster control units of the computers 10-1 to 10-4 operate in synchronism with each other while accessing each other. - The
cluster control machine 12 comprises a serviceoptimal allocation machine 121 andservice control machine 122. The serviceoptimal allocation machine 121 is realized when service optimal allocation units (not shown) provided in the computers 10-1 to 10-4 operate in synchronism with each other while accessing each other. The serviceoptimal allocation machine 121 has a function for determining an optimal computer for execution of a service when a failure has occurred in a computer that is executing the service, or when the load of the service has changed. The serviceoptimal allocation machine 121 also has a function for reallocating a service to the determined optimal computer. The serviceoptimal allocation machine 121 further has a function for adjusting, to an optimal value, the number of executions of a service (parallel-execution-type service PSVC) executed in parallel by a parallel-execution-typeservice executing machine 13, described later. Theservice control machine 122 is realized when service control units (not shown) provided in the computers 10-1 to 10-4 operate in synchronism with each other while accessing each other. Theservice control machine 122 has a function for switching a service over to the computer determined by the serviceoptimal allocation machine 121, under the control of the serviceoptimal allocation machine 121. - In the cluster system of
FIG. 1 , the parallel-execution-typeservice executing machine 13 operates. The parallel-execution-typeservice executing machine 13 is controlled by thecluster control machine 12. Like thecluster control machine 12, the parallel-execution-typeservice executing machine 13 is a virtual machine realized by the computers 10-1 to 10-4, and can be considered to exist therebetween. The parallel-execution-typeservice executing machine 13 has a function for executing a service PSVC in parallel on some of the computers 10-1 to 10-4 (nodes). Such a service PSVC as can be executed in parallel by the parallel-execution-typeservice executing machine 13 is called a parallel-execution-type service. The number of parallel executions of a parallel-execution-type service PSVC, i.e., the number of services simultaneously executed in the computers used (=the number of nodes), is determined by the serviceoptimal allocation machine 121 of thecluster control machine 12 based on a service ticket value, described later.FIG. 1 shows a case where the number of parallel executions of the parallel-execution-type service PSVC (the number of services simultaneously executed in the computers used) is 2. That is, in the case ofFIG. 1 , concerning the execution of the service PSVC, the computers 10-3 and 10-4 are operating, while the computers 10-1 and 10-2 are in a standby state. In other words, in the case ofFIG. 1 , the parallel-execution-typeservice executing machine 13 is executing a parallel-execution-type service PSVC in parallel in the computers 10-3 and 10-4. - A parameter value called static service ticket value SSTPSVC is preset for a parallel-execution-type service PSVC (an application for realizing a parallel-execution-type service PSVC). Static service ticket value SSTPSVC indicates the amount of resources pre-estimated to be needed for executing the parallel-execution-type service PSVC in the computer 10-i. The resource amount indicates a static load required by the service PSVC. In the parallel-execution-type
service executing machine 13, a user presets a minimum number Nmin of services. The minimum number Nmin indicates a minimum number of parallel executions of the parallel-execution-type service PSVC. The minimum number Nmin also indicates a minimum number of computers (nodes) used to execute the parallel-execution-type service PSVC in parallel. - The parallel-execution-type
service executing machine 13 includes service load monitors 131-1 to 131-4 operable in the computers 10-1 to 10-4. Each service load monitor 131-i (i=1, 2, 3, 4) operates only when the corresponding computer 10-i executes the parallel-execution-type service PSVC. Each service load monitor 131-i measures the use of resources while the corresponding computer 10-i is executing the parallel-execution-type service PSVC. Based on the currently measured resource use, each service load monitor 131-i estimates the amount of resources needed for completing the execution of the parallel-execution-type service PSVC. The estimated amount of resources indicates a dynamic load required by the service PSVC. From the estimated amount of resources, each service load monitor 131-i acquires dynamic service ticket value DSTPSVCi that indicates a dynamic load required by the service PSVC, and sends it to thecluster control machine 12. - In the computers 10-1 to 10-4, HA-type service execution units 141-1 to 141-4 for executing HA-type services SVC1 are operable. Further, in the computers 10-1 to 10-4, HA-type service execution units 142-1 to 142-4 for executing HA-type services SVC2 are also operable. The HA-type service execution units 141-1 to 141-4 and 142-1 to 142-4 are controlled by the
cluster control machine 12. - HA-type services are services (applications) to be subjected to fail-over under the control of the
cluster control machine 12. Each of HA-type services can be executed by only one of the computers 10-1 to 10-4 in a single time zone. In the case ofFIG. 1 , concerning the execution of the HA-type service SVC1, only the HA-type service execution unit 141-1 of the computer 10-1 is operating, and the other HA-type service execution units 141-2 to 141-4 of the computers 10-2 to 10-4 are in the standby state. Further, concerning the execution of the HA-type service SVC2, only the HA-type service execution unit 141-2 of the computer 10-2 is operating, and the other HA-type service execution units 141-1, 14-3 and 141-4 of the computers 10-1, 10-3 and 10-4 are in the standby state. - For the HA-type services SVC1 and SVC2 (applications for realizing the HA-type services SVC1 and SVC2), static service ticket values SSTSVC1 and SSTSVC2 are preset, respectively. The static service ticket values SSTSVC1 and SSTSVC2 are parameter values indicating the respective amounts of resources needed for the HA service execution units 141-i and 142-i of the computer 10-i to execute the HA services SVC1 and SVC2.
- The HA service execution units 141-1 to 141-4 and 142-1 to 142-4 include service load monitors 151-1 to 151-4 and 152-1 to 152-4, respectively. The service load monitors 151-i and 152-i (i=1, 2, 3, 4) operate only when the HA service execution units 141-i and 142-i of the computer 10-i execute the HA services SVC1 and SVC2, respectively. The service load monitors 151-i and 152-i measure respective resource use when the computer 10-i is executing the services SVC1 and SVC2. Based on the measured resource use, the monitors 151-i and 152-i estimate the amounts of resources needed for the computer 10-i to execute the services SVC1 and SVC2. The estimated resource amounts indicate the dynamic loads required by the services SVC1 and SVC2. From the estimated resource amounts, the service load monitors 151-i and 152-i acquire the dynamic service ticket values DSTSVC1i and DSTSVC2i indicating the dynamic loads required by the services SVC1 and SVC2, respectively. The service load monitors 151-i and 152-i report the dynamic service ticket values DSTSVC1i and DSTSVC2i to the
cluster control machine 12, respectively. - In the computers 10-1 to 10-4, node load monitors 16-1 to 16-4 operate, respectively. In the computers 10-1 to 10-4, static node ticket values SNT1 to SNT4 indicating the processing capacities (resource amounts) of the computers (nodes) 10-1 to 10-4, respectively, are preset. In the embodiment, it is assumed that the computers 10-1 to 10-4 have asymmetrical resource environments. Therefore, the computers 10-1 to 10-4 have different static node ticket values SNT1 to SNT4. The node load monitors 16-1 to 16-4 calculate dynamic node ticket values DNT1 to DNT4 from the sums TST1 to TST4 (hereinafter referred to as the “total service ticket value”) of the ticket values of all services executed in the computers 10-1 to 10-4, and static node ticket values SNT1 to SNT4. The calculation of dynamic node ticket values DNT1 to DNT4 is carried out each time a preset inspection time is reached. Dynamic node ticket values DNT1 to DNT4 indicate resource amounts that can be newly used by the computers 10-1 to 10-4. The node load monitors 16-1 to 16-4 report dynamic node ticket values DNT1 to DNT4 to the
cluster control machine 12. - The operation of the cluster system shown in
FIG. 1 will now be described. When the parallel-execution-typeservice executing machine 13 is executing the parallel-execution-type service PSVC on the computer 10-i (i=1, 2, 3, 4), the corresponding service load monitor 131-i operates, for example, periodically each time a preset inspection time is reached. As a result, the service load monitor 131-i measures the amount of resources used by the computer 10-i when it is executing the service PSV thereon. Based on the measured current resource use, the service load monitor 131-i calculates dynamic service ticket value DSTPSVCi that indicates an estimated resource amount needed for the computer 10-i to execute the parallel-execution-type service PSVC. In the embodiment, three estimation functions f(x), g(y) and h(z) are used for the calculation of dynamic service ticket value DSTPSVCi. The three estimation functions f(x), g(y) and h(z) are functions for acquiring the use of three resources in the computer 10-i, e.g., the amount x of use of a CPU, the amount y of use of a memory and a response time z. The response time z is a period ranging from the time at which the computer 10-i receives, from a client terminal, a request to execute a service s, to the time at which it returns, to the client terminal, a response indicating the result of the execution. In the embodiment, dynamic service ticket value DSTPSVCi is given by
DST si =f(x)+g(y)+h(z) (1)
where s represents PSVC. Dynamic service ticket value DSTPSVCi calculated by each service load monitor 131-i is reported to thecluster control machine 12. - On the other hand, the service load monitors 151-i and 152-i operates, for example, periodically each time a preset inspection time is reached, when the HA-type service execution units 141-i and 142-i are executing HA-type services SVC1 and SVC2, respectively. The service load monitors 151-i and 152-i calculate, like the service load monitors 131-i, dynamic service ticket values DSTSVC1i and DSTSVC2i based on the current resource use. Dynamic service ticket values DSTSVC1i and DSTSVC2i indicate the estimated amounts of resources needed for the computer 10-i to execute the services SVC1 and SVC2. Dynamic service ticket values DSTSVC1i and DSTSVC2i are given by the equation (1), like dynamic service ticket values DSTpSvCi. In this case, however, s in the equation (1) represents SVC1 or SVC2. Dynamic service ticket values DSTSVC1i and DSTSVC2i calculated by the service load monitors 151-i and 152-i, respectively, are reported to the
cluster control machine 12. - Referring to the flowchart of
FIG. 2 , the operation of the node load monitor 16-i (i=1, 2, 3, 4) for calculating dynamic node ticket value DNTi. The node load monitor 16-i acquires service ticket value STsi for each of the services s currently executed in the computer 10-i, using the following formula (steps S1 and S2):
ST si=MAX (SST s ,DST si) (2)
Service ticket value STsi indicates the resource amount used by each of the services s currently executed in the computer 10-i, or the maximum resource amount estimated to be used by each of the services s (i.e., the maximum amount of resources that may be used by each of the services s). - After the node load monitor 16-i acquires service ticket values STsi for each of the services s currently executed in the computer 10-i, the program proceeds to step S3. At step S3, the node load monitor 16-i calculates the sum of service ticket values STsi, i.e., total service ticket value TSTi, using the following equation:
TSTi=ΣSTsi (3)
Total service ticket value TSTi indicates the maximum resource amount that may be used by all services currently executed in the computer 10-i, i.e., the entire load on the computer 10-i (the entire node load). - After the node load monitor 16-i acquires total service ticket value TSTi for all services currently executed in the computer 10-i, the program proceeds to step 64. At step S4, the node load monitor 16-i calculates a ticket value indicating a resource amount that can be newly used at present in the computer 10-i, i.e., dynamic node ticket value DNTi, using the following equation:
DNT i =SNT i −TST i (4)
Thus, dynamic node ticket value DNTi is calculated by subtracting total service ticket value TSTi from static node ticket value SNTi. The node load monitor 16-i repeats periodically (i.e., at regular intervals) the above-described processing (steps S1 to S4). - Referring then to the flowchart of
FIG. 3 , a description will be given of the operation of a serviceoptimal allocation machine 121, incorporated in thecluster control machine 12, for adjusting, to an optimal value, the number of parallel executions of the parallel-execution-type service PSVC. The serviceoptimal allocation machine 121 calculates the number (hereinafter referred to as the “optimal number of services”) OSN of parallel executions of the parallel-execution-type service PSVC (step S11). The optimal number OSN is calculated, in the manner described below, based on dynamic service ticket value DSTpSVCi in each computer (node) 10-i, static service ticket value SSTPSVC and the minimum number Nmin of services. - Firstly, the service
optimal allocation machine 121 calculates, using the following equation, the sum of dynamic service ticket values DSTPSVC1 to DSTPSVC4 in the computers 10-1 to 10-4, i.e., total dynamic service ticket value TDST (step Slla):
TDST=ΣDSTPSVCi (5)
Subsequently, the serviceoptimal allocation machine 121 calculates, as a temporal number TSN of services, the number of the parallel executions of the parallel-execution-type service PSVC currently needed, based on total dynamic service ticket value TDST and static service ticket value SSTPSVC for the parallel-execution-type service PSVC. In other words, the serviceoptimal allocation machine 121 calculates the temporal number TSN using the following formula (step S11 b):
TSN=the integer part of (TDST/SST PSVC) (if the remainder is zero)
TSN=the integer part of (TDST/SST PSVC)+1 (if the remainder is not zero) (6)
After that, the serviceoptimal allocation machine 121 calculates the optimal number OSN based on the temporal number TSN and preset minimum number Nmin of services. In other words, the serviceoptimal allocation machine 121 calculates the optimal number OSN using the following equation (step Sllc):
OSN=MAX (TSN, N min) (7)
Thereafter, the serviceoptimal allocation machine 121 compares the optimal number OSN with the number CSN (hereinafter referred to as “the current number of services”) of the parallel-execution-type service PSVC currently executed in parallel by the parallel-execution-typeservice executing machine 13. If the optimal number OSN is larger than the current number CSN (step S12), the serviceoptimal allocation machine 121 determines whether computers 10-j (j is 1, 2, 3 or 4) that can newly execute the parallel-execution-type service PSVC are included in the computers 10-1 to 10-4 of the system (step S13). If such computers 10-j are included, the serviceoptimal allocation machine 121 proceeds to step S14. At step S14, the serviceoptimal allocation machine 121 selects one of the computers 10-j in which the difference between static and dynamic node ticket values SNTj and DNTj is largest, and makes the selected computer execute the service PSVC. After that, the serviceoptimal allocation machine 121 returns to step S11. Thus, themachine 121 selects a computer from the service-executable computers 10-j in the order beginning from the largest difference between static and dynamic node ticket values SNTj and DNTj, and makes the selected computer start to execute the service PSVC. This operation is repeated until the optimal number OSN reaches the current number CSN. On the other hand, if there is no service-executable computer 10-j (step S13), themachine 121 sleeps for a predetermined time (step S15), and then returns to step S11. - Further, if the optimal number OSN is smaller than the current number CSN (step S16), the service
optimal allocation machine 121 determines whether computers 10-j (j is 1, 2, 3 or 4) that can stop the currently executed parallel-execution-type service PSVC are included in the computers 10-1 to 10-4 of the system (step S17). If such computers 10-j are included, the serviceoptimal allocation machine 121 proceeds to step S18. At step S18, the serviceoptimal allocation machine 121 selects one of the computers 10-j in which the difference between static and dynamic node ticket values SNTj and DNTj is smallest, and makes the selected computer stop the execution of the service PSVC. After that, the serviceoptimal allocation machine 121 returns to step S11. Thus, themachine 121 selects a computer from the service-executable computers 10-j in the order beginning from the smallest difference between static and dynamic node ticket values SNTj and DNTj, and makes the selected computer stop the execution of the service SVC. This operation is repeated until the optimal number OSN reaches the current number CSN. On the other hand, if there is no service-execution-stoppable computer 10-j (step S17), themachine 121 sleeps for a predetermined time (step S15), and then returns to step S11. - As described above, in the embodiment, the optimal number OSN indicating the optimal number of parallel executions of the parallel-execution-type service PSVC executed in parallel in the cluster system (computer system) is calculated based on dynamic service ticket value DSTPSVCi in each computer 10-i, static service ticket value SSTPSVC and minimum number Nmin. After that, the number of executions of the parallel-execution-type service PSVC is adjusted in accordance with the difference between the calculated optimal number OSN and the current number CSN (the number of the parallel-execution-type service PSVC currently executed in parallel). As a result, the number of executions of parallel-execution-type services can be adjusted appropriately even in the cluster system as shown in
FIG. 1 and even if the computers 10-1 to 10-4 of the cluster system have asymmetrical environments. - It is assumed that the system shown in
FIG. 1 can execute only one kind of parallel-execution-type services (i.e., services PSVC). However, two or more kinds of parallel-execution-type services can be executed. In this case, it is sufficient if respective optimal numbers OSN are set for different kinds of parallel-execution-type services. - Referring then to the flowchart of
FIG. 4 , a description will be given of optimal allocation of HA-type services or parallel-execution-type services by the serviceoptimal allocation machine 121. The serviceoptimal allocation machine 121 searches the computers 10-1 to 10-4 for the computer 10-j in which the value of (DNTj−Δ) is a preset value or less, i.e., in which dynamic node ticket value DNTj may be a preset value or less (step S21). “Δ” indicates a margin for searching a computer 10-j having dynamic node ticket value DNTj that is actually higher than the preset value but may well become the preset value or less. In the embodiment, the preset value is zero. Alternatively, a computer 10-j in which dynamic node ticket value DNTj may become a value less than the preset value may be searched for. - If it is determined at step S21 that there is no corresponding computer 10-j in which dynamic node ticket value DNTj may become the preset value or less, the service
optimal allocation machine 121 sleeps for a predetermined time (step S22), and then returns to step S21. If an event, such as a failure in a computer, occurs, the serviceoptimal allocation machine 121 returns to step S21 without sleeping. - On the other hand, if there are one or more computers 10-j in which dynamic node ticket value DNTj may be the preset value or less, the service
optimal allocation machine 121 selects, from the computers 10-j, a computer 10-j that is executing a service s of the lowest priority, and selects this service s (step S23). Subsequently, the serviceoptimal allocation machine 121 determines whether the selected service s can be switched over to another computer in the system (step S24). In the embodiment, services that can be switched over are preset. In other words, concerning each service, it is predetermined whether switching over is possible. In this case, the determination at step S24 is achieved by determining whether the selected service s is included in the preset ones. The determination as to whether switching over is possible may be made in accordance with the execution state of the service s, for example, depending upon whether the service s is being processed in its critical area. Processing in a critical area means, for example, processing in which high response performance is required, or processing in which consistency (atomicity) is required, that is, processing that costs a lot for backtracking. Specifically, transaction processing, database updating processing, etc. are included. - Assume here that the selected service s can be switched over to another computer. Further, assume that computers 10-k (k is 1, 2, 3 or 4) can execute the selected service s. In this case, the service
optimal allocation machine 121 searches the computers 10-k for an optimal computer to which the selected service s is switched over in the manner described below (step S25). Firstly, the serviceoptimal allocation machine 121 searches for a computer 10-k in which dynamic node ticket value DNTk is higher than MAX (SSTs, DSTsk), based on dynamic node ticket value DNTk, static service ticket value SSTs and dynamic service ticket value DSTsk. MAX (SSTs, DSTsk) indicates the higher one of the values SSTs and DSTsk. If a plurality of computers 10-k are detected, the serviceoptimal allocation machine 121 selects one of the computers 10-k as an optimal computer to which the selected service s is switched over. It is advisable to select, as the optimal computer, a computer 10-k that has the highest dynamic node ticket value DNTk. Alternatively, a computer 10-k having DNTk that exceeds MAX (SSTs, DSTsk) and closest to MAX (SSTs, DSTsk) may be selected. - After an optimal computer, to which the selected service s is switched over, is detected (step S26), the service
optimal allocation machine 121 makes the optimal computer start to execute the service s (step S27), and then returns to step S21. If no optimal computer can be detected (step S26), the serviceoptimal allocation machine 121 selects a computer 10-j, which is executing a service s of the next lowest priority, from the computers 10-j in which dynamic node ticket value DNTj may be the preset value or less, and selects this service s (step S28). After that, the serviceoptimal allocation machine 121 returns to step 24. - On the other hand, if the selected service s cannot be switched over to any other computer, the service
optimal allocation machine 121 determines whether the execution of the selected service s can be stopped (step S29). In the embodiment, services that can be stopped are preset. In other words, concerning each service, whether it can be stopped is preset. Alternatively, the determination as to whether the selected service s can be stopped may be performed depending upon the execution state of the service s. - If the execution of the selected service s can be stopped, the service
optimal allocation machine 121 stops its execution (step S30). After that, themachine 121 returns to step S21. If, on the other hand, the execution of the selected service s cannot be stopped, themachine 121 selects a computer 10-j, which is executing a service s of the next lowest priority, from the computers 10-j in which dynamic node ticket value DNTj may be the preset value or less, and selects this service s (step S31). After that, themachine 121 returns to step 24. - Thus, in the embodiment, the service s, executed in a computer 10-j in which dynamic node ticket value DNTj may be a preset value or less, can be switched over to and executed by a computer 10-k in which dynamic node ticket value DNTk is more than the higher one of the static service ticket value SSTs and dynamic service ticket value DSTsk. As a result, optimal load distributing is realized. That is, in the embodiment, if a failure occurs in a computer or a significant change occurs in service or node load, the service
optimal allocation machine 121 automatically performs reallocation of services. - The flowchart of
FIG. 4 does not show the case where an optimal computer to which the selected service s is switched over is not detected even after steps S24, 25, 26 and 28 are repeated. Similarly,FIG. 4 does not show the case where no stoppable service s is detected even after steps S24, 29 and 31 are repeated. In these cases, a user may perform setting in which, for example, other service s is switched over or stopped. If there is no optimal computer, the selected service may be stopped until an optimal computer is detected, or nothing may be done. - In the above-described embodiment, a cluster system is assumed which can execute parallel-execution-type services as well as HA-type services. However, the present invention is not limited to such cluster systems, but is also applicable to a computer system (load distributing system) that can execute only parallel-execution-type services.
- Additional advantages and modifications will readily occur to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details and representative embodiments shown and described herein. Accordingly, various modifications may be made without departing from the spirit or scope of the general inventive concept as defined by the appended claims and their equivalents.
Claims (13)
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003306616 | 2003-08-29 | ||
JP2003-306616 | 2003-08-29 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20050050198A1 true US20050050198A1 (en) | 2005-03-03 |
US7668935B2 US7668935B2 (en) | 2010-02-23 |
Family
ID=34214101
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/926,310 Active 2026-10-16 US7668935B2 (en) | 2003-08-29 | 2004-08-26 | Computer system and method for service load distributing |
Country Status (2)
Country | Link |
---|---|
US (1) | US7668935B2 (en) |
CN (1) | CN1316363C (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080189718A1 (en) * | 2007-02-02 | 2008-08-07 | The Mathworks, Inc. | Scalable architecture |
US20080222642A1 (en) * | 2007-03-08 | 2008-09-11 | Oracle International Corporation | Dynamic resource profiles for clusterware-managed resources |
US20090172086A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US20100223385A1 (en) * | 2007-02-02 | 2010-09-02 | The Mathworks, Inc. | Scalable architecture |
US20110265081A1 (en) * | 2010-04-26 | 2011-10-27 | Vmware, Inc. | Droplet execution engine for dynamic server application deployment |
US8444827B2 (en) | 2011-02-02 | 2013-05-21 | Voith Patent Gmbh | Structured fabric |
US8843517B1 (en) * | 2011-06-03 | 2014-09-23 | Narus, Inc. | System and method for scalable high speed distributive data storage and retrieval |
US9384057B2 (en) | 2012-04-16 | 2016-07-05 | International Business Machines Corporation | Programmatic load-based management of processor population |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101098308B (en) * | 2007-06-26 | 2012-04-25 | 华为技术有限公司 | Node load sharing method and system in network |
CN102437958A (en) * | 2011-12-16 | 2012-05-02 | 北京邮电大学 | Method and system for scheduling service |
CN114338696B (en) * | 2022-03-14 | 2022-07-15 | 北京奥星贝斯科技有限公司 | Method and device for distributed system |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6266335B1 (en) * | 1997-12-19 | 2001-07-24 | Cyberiq Systems | Cross-platform server clustering using a network flow switch |
US20030123424A1 (en) * | 2001-12-29 | 2003-07-03 | Lg Electronics Inc. | Mobile communication system and method of selecting server in mobile communication system |
US20030172145A1 (en) * | 2002-03-11 | 2003-09-11 | Nguyen John V. | System and method for designing, developing and implementing internet service provider architectures |
US20040103194A1 (en) * | 2002-11-21 | 2004-05-27 | Docomo Communicatios Laboratories Usa, Inc. | Method and system for server load balancing |
US20050060558A1 (en) * | 2003-04-12 | 2005-03-17 | Hussain Muhammad Raghib | Apparatus and method for allocating resources within a security processing architecture using multiple queuing mechanisms |
US6886035B2 (en) * | 1996-08-02 | 2005-04-26 | Hewlett-Packard Development Company, L.P. | Dynamic load balancing of a network of client and server computer |
US6986139B1 (en) * | 1999-10-06 | 2006-01-10 | Nec Corporation | Load balancing method and system based on estimated elongation rates |
US6993762B1 (en) * | 1999-04-07 | 2006-01-31 | Bull S.A. | Process for improving the performance of a multiprocessor system comprising a job queue and system architecture for implementing the process |
US7284051B1 (en) * | 1998-12-28 | 2007-10-16 | Fujitsu Limited | Relaying apparatus for use in a network system |
US20090024868A1 (en) * | 2002-05-31 | 2009-01-22 | Joshi Darshan B | Business continuation policy for server consolidation environment |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07234847A (en) | 1994-02-25 | 1995-09-05 | Hitachi Ltd | Scheduling method for job |
JP3006551B2 (en) | 1996-07-12 | 2000-02-07 | 日本電気株式会社 | Business distribution system between plural computers, business distribution method, and recording medium recording business distribution program |
JP2000137692A (en) | 1998-10-30 | 2000-05-16 | Toshiba Corp | Inter-distributed node load distribution system |
JP2002082926A (en) * | 2000-09-06 | 2002-03-22 | Nippon Telegr & Teleph Corp <Ntt> | Distributed application test and operation management system |
EP1459176A2 (en) * | 2001-09-10 | 2004-09-22 | British Telecommunications Public Limited Company | Distributed service component systems |
-
2004
- 2004-08-26 US US10/926,310 patent/US7668935B2/en active Active
- 2004-08-27 CN CNB2004100579608A patent/CN1316363C/en active Active
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6886035B2 (en) * | 1996-08-02 | 2005-04-26 | Hewlett-Packard Development Company, L.P. | Dynamic load balancing of a network of client and server computer |
US6266335B1 (en) * | 1997-12-19 | 2001-07-24 | Cyberiq Systems | Cross-platform server clustering using a network flow switch |
US7284051B1 (en) * | 1998-12-28 | 2007-10-16 | Fujitsu Limited | Relaying apparatus for use in a network system |
US6993762B1 (en) * | 1999-04-07 | 2006-01-31 | Bull S.A. | Process for improving the performance of a multiprocessor system comprising a job queue and system architecture for implementing the process |
US6986139B1 (en) * | 1999-10-06 | 2006-01-10 | Nec Corporation | Load balancing method and system based on estimated elongation rates |
US20030123424A1 (en) * | 2001-12-29 | 2003-07-03 | Lg Electronics Inc. | Mobile communication system and method of selecting server in mobile communication system |
US20030172145A1 (en) * | 2002-03-11 | 2003-09-11 | Nguyen John V. | System and method for designing, developing and implementing internet service provider architectures |
US20090024868A1 (en) * | 2002-05-31 | 2009-01-22 | Joshi Darshan B | Business continuation policy for server consolidation environment |
US20040103194A1 (en) * | 2002-11-21 | 2004-05-27 | Docomo Communicatios Laboratories Usa, Inc. | Method and system for server load balancing |
US20050060558A1 (en) * | 2003-04-12 | 2005-03-17 | Hussain Muhammad Raghib | Apparatus and method for allocating resources within a security processing architecture using multiple queuing mechanisms |
Cited By (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8549096B2 (en) | 2007-02-02 | 2013-10-01 | The Mathworks, Inc. | Scalable architecture |
WO2008097836A2 (en) * | 2007-02-02 | 2008-08-14 | The Mathworks, Inc. | Scalable architecture |
WO2008097836A3 (en) * | 2007-02-02 | 2009-05-28 | Mathworks Inc | Scalable architecture |
US8918511B2 (en) | 2007-02-02 | 2014-12-23 | The Mathworks, Inc. | Scalable architecture |
US20100223385A1 (en) * | 2007-02-02 | 2010-09-02 | The Mathworks, Inc. | Scalable architecture |
US20080189718A1 (en) * | 2007-02-02 | 2008-08-07 | The Mathworks, Inc. | Scalable architecture |
US8380880B2 (en) | 2007-02-02 | 2013-02-19 | The Mathworks, Inc. | Scalable architecture |
US20080222642A1 (en) * | 2007-03-08 | 2008-09-11 | Oracle International Corporation | Dynamic resource profiles for clusterware-managed resources |
US8209417B2 (en) * | 2007-03-08 | 2012-06-26 | Oracle International Corporation | Dynamic resource profiles for clusterware-managed resources |
US8738567B2 (en) | 2007-09-28 | 2014-05-27 | Xcerion Aktiebolag | Network file system with enhanced collaboration features |
US9071623B2 (en) | 2007-09-28 | 2015-06-30 | Xcerion Aktiebolag | Real-time data sharing |
US8615531B2 (en) | 2007-09-28 | 2013-12-24 | Xcerion Aktiebolag | Programmatic data manipulation |
US8620863B2 (en) | 2007-09-28 | 2013-12-31 | Xcerion Aktiebolag | Message passing in a collaborative environment |
US8688627B2 (en) | 2007-09-28 | 2014-04-01 | Xcerion Aktiebolag | Transaction propagation in a networking environment |
US11838358B2 (en) | 2007-09-28 | 2023-12-05 | Xcerion Aktiebolag | Network operating system |
US8843942B2 (en) | 2007-09-28 | 2014-09-23 | Xcerion Aktiebolag | Interpreting semantic application code |
US9621649B2 (en) | 2007-09-28 | 2017-04-11 | Xcerion Aktiebolag | Network operating system |
US20090172086A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US8954526B2 (en) | 2007-09-28 | 2015-02-10 | Xcerion Aktiebolag | Network operating system |
US8959123B2 (en) | 2007-09-28 | 2015-02-17 | Xcerion Aktiebolag | User interface framework |
US8996459B2 (en) * | 2007-09-28 | 2015-03-31 | Xcerion Aktiebolag | Offline and/or client-side execution of a network application |
US20110265081A1 (en) * | 2010-04-26 | 2011-10-27 | Vmware, Inc. | Droplet execution engine for dynamic server application deployment |
US9772831B2 (en) * | 2010-04-26 | 2017-09-26 | Pivotal Software, Inc. | Droplet execution engine for dynamic server application deployment |
US10817273B1 (en) | 2010-04-26 | 2020-10-27 | Pivotal Software, Inc. | Droplet execution engine for dynamic server application deployment |
US11604630B2 (en) | 2010-04-26 | 2023-03-14 | Pivotal Software, Inc. | Droplet execution engine for dynamic server application deployment |
US8444827B2 (en) | 2011-02-02 | 2013-05-21 | Voith Patent Gmbh | Structured fabric |
US8843517B1 (en) * | 2011-06-03 | 2014-09-23 | Narus, Inc. | System and method for scalable high speed distributive data storage and retrieval |
US9384057B2 (en) | 2012-04-16 | 2016-07-05 | International Business Machines Corporation | Programmatic load-based management of processor population |
US9384055B2 (en) | 2012-04-16 | 2016-07-05 | International Business Machines Corporation | Programmatic load-based management of processor population |
Also Published As
Publication number | Publication date |
---|---|
US7668935B2 (en) | 2010-02-23 |
CN1591340A (en) | 2005-03-09 |
CN1316363C (en) | 2007-05-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Yu et al. | Stochastic load balancing for virtual resource management in datacenters | |
US7117499B2 (en) | Virtual computer systems and computer virtualization programs | |
US7877755B2 (en) | Dynamic application placement with allocation restrictions and even load distribution | |
EP3161632B1 (en) | Integrated global resource allocation and load balancing | |
US7099814B2 (en) | I/O velocity projection for bridge attached channel | |
US20180246771A1 (en) | Automated workflow selection | |
US7610425B2 (en) | Approach for managing interrupt load distribution | |
US6249800B1 (en) | Apparatus and accompanying method for assigning session requests in a multi-server sysplex environment | |
US5881238A (en) | System for assignment of work requests by identifying servers in a multisystem complex having a minimum predefined capacity utilization at lowest importance level | |
US8463971B2 (en) | Approach for distributing interrupts from high-interrupt load devices | |
US20070300239A1 (en) | Dynamic application instance placement in data center environments | |
US7856572B2 (en) | Information processing device, program thereof, modular type system operation management system, and component selection method | |
US20040143664A1 (en) | Method for allocating computer resource | |
US8024737B2 (en) | Method and a system that enables the calculation of resource requirements for a composite application | |
US7668935B2 (en) | Computer system and method for service load distributing | |
US8813087B2 (en) | Managing a workload in a cluster of computing systems with multi-type operational resources | |
JP4476307B2 (en) | Virtual computer system and program | |
JP2007200347A (en) | Virtual computer system and program | |
Ali et al. | Perspectives on robust resource allocation for heterogeneous parallel and distributed systems | |
Garg et al. | Optimal virtual machine scheduling in virtualized cloud environment using VIKOR method | |
JP3884427B2 (en) | Computer system and resource allocation program | |
JP3910982B2 (en) | Computer system, service load balancing method and program | |
CN103188159A (en) | Management method for hardware performance and cloud computing system | |
Zheng et al. | Energy-efficient statistical live virtual machine placement for big data information systems in cloud computing environments | |
Nain et al. | Optimizing service stipulation uncertainty with deep reinforcement learning for internet vehicle systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: KABUSHIKI KAISHA TOSHIBA, JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MIZOGUCHI, KENICHI;REEL/FRAME:015742/0624 Effective date: 20040818 Owner name: KABUSHIKI KAISHA TOSHIBA,JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MIZOGUCHI, KENICHI;REEL/FRAME:015742/0624 Effective date: 20040818 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
AS | Assignment |
Owner name: TOSHIBA DIGITAL SOLUTIONS CORPORATION, JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KABUSHIKI KAISHA TOSHIBA;REEL/FRAME:048547/0187 Effective date: 20190228 |
|
AS | Assignment |
Owner name: KABUSHIKI KAISHA TOSHIBA, JAPAN Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ADD SECOND RECEIVING PARTY PREVIOUSLY RECORDED AT REEL: 48547 FRAME: 187. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:KABUSHIKI KAISHA TOSHIBA;REEL/FRAME:050041/0054 Effective date: 20190228 Owner name: TOSHIBA DIGITAL SOLUTIONS CORPORATION, JAPAN Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ADD SECOND RECEIVING PARTY PREVIOUSLY RECORDED AT REEL: 48547 FRAME: 187. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:KABUSHIKI KAISHA TOSHIBA;REEL/FRAME:050041/0054 Effective date: 20190228 |
|
AS | Assignment |
Owner name: TOSHIBA DIGITAL SOLUTIONS CORPORATION, JAPAN Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE RECEIVING PARTY'S ADDRESS PREVIOUSLY RECORDED ON REEL 048547 FRAME 0187. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KABUSHIKI KAISHA TOSHIBA;REEL/FRAME:052595/0307 Effective date: 20190228 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 12 |