JPWO2004084085A1 - Load balancing system by inter-site cooperation - Google Patents

Load balancing system by inter-site cooperation Download PDF

Info

Publication number
JPWO2004084085A1
JPWO2004084085A1 JP2004569568A JP2004569568A JPWO2004084085A1 JP WO2004084085 A1 JPWO2004084085 A1 JP WO2004084085A1 JP 2004569568 A JP2004569568 A JP 2004569568A JP 2004569568 A JP2004569568 A JP 2004569568A JP WO2004084085 A1 JPWO2004084085 A1 JP WO2004084085A1
Authority
JP
Japan
Prior art keywords
server
step
load
service
spare
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
Application number
JP2004569568A
Other languages
Japanese (ja)
Inventor
励 河合
励 河合
哲 土屋
哲 土屋
泰廣 國生
泰廣 國生
Original Assignee
富士通株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2003/003273 priority Critical patent/WO2004084085A1/en
Publication of JPWO2004084085A1 publication Critical patent/JPWO2004084085A1/en
Application status is Granted legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/1002Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers, e.g. load balancing

Abstract

In a system comprising a front-stage center 12-1 that directly receives a request from the client 10 via the network 11 and a back-stage center 12-2 that receives a request from the client 10 via the front-stage center 12-1, Servers 17-1 and 17-2 are included. First, the pre-stage center 12-1 provides a service using a normal server. The system control device 16-1, which has detected that the load on the server has increased, provides a server for providing a service with an increased load from the spare server 17-1 provided in common for the service 1 and the service 2. . If the load still cannot be supported, the system control device 16-1 instructs the system control device 16-2 of the post-stage center 12-2 to provide the service. The rear stage center 12-2 also supports the load using the spare server 17-2 when the load cannot be supported by the normal server.

Description

  The present invention relates to a load distribution system by inter-site cooperation.

With the explosive spread of the Internet, resources such as servers and networks required on the service provider side have become enormous. However, it is known that the amount of requests from users varies greatly depending on time and conditions, and if resources are secured according to the time of concentration, it is necessary to maintain wasteful resources during normal times. If the resource cannot be used, the service quality is degraded and the user is uncomfortable. Furthermore, it is difficult to estimate the upper limit of necessary resources as the number of users increases, and a system for allocating resources as necessary becomes necessary. At the same time, excessive resources lead to an increase in management costs, so a mechanism for effectively using unnecessary resources is also required.
FIG. 1 is an example of a conventional load distribution system.
In the configuration of FIG. 1, the client 10 accesses the data center 12 via the network 11 and receives a service. A plurality of servers 14 are connected to the load balancer 13.
If a single server cannot handle the processing, a plurality of servers are installed as shown in FIG. 1, and the load distribution device 13 is arranged at the preceding stage to distribute the load to the plurality of servers and improve the service quality. The addition of the server 14, the addition of the server 14 and the load balancer 13, and the operation of changing the settings are often performed manually, and a large cost is required because it is necessary to always secure a server that matches the maximum load.
Patent document 1 defines a method for adding servers and distributing requests from users, but it is necessary to incorporate a mechanism for server selection on the user side, which is suitable for application to services for unspecified majority. Not. In addition, there is a problem that management information other than the request needs to be exchanged.
Further, the method of Patent Document 2 can be applied only when static information is distributed, and cannot be applied when different information is returned each time according to a request from a user such as service provision.
Further, Patent Document 3 also assumes the case of static information, and does not consider the case where the load on the file server or the like becomes excessive.
Japanese Patent Laid-Open No. 9-106381 Japanese Patent Laid-Open No. 9-179820 JP 2002-259354 A

An object of the present invention is to provide a load distribution system that distributes a load for providing a service and can flexibly cope with a change in a request from a user.
The method of the present invention is a load balancing method for a device having a plurality of servers that provide services to clients via a network. In the initial state for sharing the load of servers that provide normal services, A step of providing a plurality of spare servers for which no service is set, and an increase in the load on the server that provides the normal service, setting an application for the service to be provided to the spare server, A providing server, comprising a server that provides a normal service and a control step that shares a load.
According to the present invention, in addition to a server that provides a normal service, a plurality of spare servers are provided in a device such as a data center, and when the load on a server that provides a normal service increases, An application is installed so that the service can be provided, and the load of the server for providing the service is shared.
In another form, according to the present invention, a temporary load is supported in one data center by connecting devices provided with spare servers via a network and controlling each other so as to provide spare servers. Even if the processing capability cannot be obtained, it is possible to avoid interruption of service provision due to a large load by cooperating with the load by a plurality of devices via the network. In addition, this makes it possible to reduce the number of spare servers provided in one device, and eliminates the need to provide each device with redundant hardware.

FIG. 1 is an example of a conventional load distribution system.
FIG. 2 is a diagram showing a basic configuration of the embodiment of the present invention.
FIG. 3 is a diagram showing a network arrangement configuration in the center in the basic configuration of FIG.
FIG. 4 is a diagram showing a first embodiment of the present invention.
FIG. 5 is a diagram showing the operation of the first exemplary embodiment of the present invention.
FIG. 6 is a diagram illustrating data for calculating the load and capacity of the server.
FIG. 7 is a diagram illustrating data for selecting a server according to the magnitude of the load.
FIG. 8 is a diagram showing the relationship between the capacity of the server to be added and the predicted load value.
FIG. 9 is a diagram showing a configuration in which a spare server is shared by a plurality of services.
FIG. 10 is a diagram showing a configuration in the case of providing a spare server between different centers.
FIG. 11 is a diagram for explaining the operation of the embodiment of the present invention.
FIG. 12 is a diagram for explaining the securing of the network bandwidth in the case of cooperating with other centers.
FIG. 13 is a diagram illustrating an application example of the embodiment of the present invention in a web server.
FIG. 14 is a diagram illustrating an application example of the embodiment of the present invention in a web service.
FIG. 15 shows an application example of the embodiment of the present invention when resources are exchanged between equal centers.
FIG. 16 is a diagram illustrating an example in which the embodiment of the present invention is applied to a front-stage center that does not have a spare server.
17 to 24 are flowcharts for explaining the operation of the embodiment of the present invention when there is no cooperation between databases provided in the center.
FIG. 25 to FIG. 30 are flowcharts showing the flow of processing according to the embodiment of the present invention when there is database cooperation.

In the present invention, a change in a request amount from a user is predicted, and a server in a data center or another linked data center is dynamically added or deleted in accordance with the change, so that service quality is guaranteed and surplus at the same time. It aims to reduce costs by sharing the server with multiple services.
FIG. 2 is a diagram showing a basic configuration of the embodiment of the present invention.
The client 10 accesses the Web server 15-1 via the network 11 via the load balancer 13-1 of the upstream center 12-1. As a result of data processing in the Web server 15-1, the client 10 accesses the database server 14-1 or the file server 14-2 and receives a service. The post-stage server 12-2 has substantially the same configuration as the pre-stage center 12-1, receives a request from the client 10 via the load distribution apparatus 13-1, and performs load distribution by the load distribution apparatus 13-2. Then, the client 10 is guided to the Web server 15-2. Then, the client 10 accesses the database server 14-3 or 14-4 via the Web server 15-2 and receives a service.
Here, the upstream center 12-1 indicates a center that directly receives a user request, and the downstream center 12-2 indicates a center that processes the user request through the upstream center 12-1. The allocation of servers between data centers is a many-to-many relationship, and when a data center uses servers from multiple data centers or when a data center responds to server requests from multiple data centers at the same time. is there. The server control state and the load state from the client are aggregated, determined, and applied by the system control devices 16-1 and 16-2, and the results are sent to the servers 14-1 to 14-4 and the load distribution devices 13-1 and 13-. Set to 2. When the server resources are insufficient, the servers 17-1 and 17-2 in the spare server are set as servers having necessary functions, added to the service, and the capability is improved.
FIG. 3 is a diagram showing a network arrangement configuration in the center in the basic configuration of FIG.
In the physical network configuration, all servers are connected directly under a single switch group 20, and a plurality of logically independent networks (VLAN0, VLAN11, VLAN12, VLAN21) are formed thereon. With this arrangement, it is possible to automate server addition processing at a required position.
When adding or deleting servers, the server performance is derived from the server specifications such as CPU performance and network configuration, and necessary servers are calculated even in an environment where various types of hardware are mixed. Assign a server. At the same time, the traffic for the server is calculated and the network bandwidth is secured or arbitrated.
In addition, by predicting the future load from load measurement and load fluctuation prediction, a server is added before the load becomes excessive, thereby guaranteeing service quality.
FIG. 4 is a diagram showing a first embodiment of the present invention.
In the figure, the same components as those in FIG. 2 are denoted by the same reference numerals and detailed description thereof is omitted.
When the request from the user exceeds the allocated server capacity, an increase in response time or no response occurs, which causes discomfort to the user. If the load further increases in this state, a server failure may be caused. In order to prevent this, the system control device 16 measures the load state of the server, and if it is determined that there is a problem with the current number of servers, a server is added from the spare server 17 to use applications, services, and the like. Set and introduce data. Then, the settings of the devices and servers in the dependency relationship are updated and incorporated into the service.
FIG. 5 is a diagram showing the operation of the first exemplary embodiment of the present invention.
In the figure, the same components as those in FIG.
When the request amount from the user decreases, a surplus server is generated. Even if the surplus server is deleted, the service quality does not deteriorate. Rather, it is desirable to open it as a spare server and use it for other services from the viewpoint of improving the operation cost and the utilization rate. For this reason, the linkage with the service is canceled by deleting the related setting from the devices having the dependency relationship, and then the processing such as the cancellation of the setting is performed, and the processing is returned to the spare server 17.
FIG. 6 is a diagram illustrating data for calculating the load and capacity of the server.
In order to add and delete service capabilities as needed, information on how much service capability a server provides is necessary. In a data center or the like, service capacity per unit varies depending on a combination of servers and devices to be used, applications, and services. It is practically impossible to arrange the servers to be used in a uniform manner, for example, when a plurality of data centers are linked, and therefore it is necessary to calculate the service capability from the specifications of the devices such as CPU and memory. For this reason, a method of estimating the performance value from the performance value in a typical configuration in consideration of a difference in CPU capability or the like is used.
FIG. 7 is a diagram illustrating data for selecting a server according to the magnitude of the load.
Here, not only the service capability but also information indicating what kind of use is preferable as a characteristic of the server unit is held. Since the performance values for each server that can be used as described above are not uniform, it is necessary to create a configuration that can provide necessary capabilities by combining them. For this reason, servers are selected and used from the performance values and characteristics obtained in FIG. 6 and the required performance values until a server with a high recommendation level is preferentially satisfied.
FIG. 8 is a diagram showing the relationship between the capacity of the server to be added and the predicted load value.
If the measured request amount exceeds the service capability, the service quality cannot be guaranteed only by adding a resource when the load is rapidly increasing. For this reason, the load tendency is grasped, and when an increase in the request amount is expected, a service capability corresponding to the predicted request amount is added in advance to prevent deterioration in service quality. As a prediction method, linear extrapolation or the like can be considered.
FIG. 9 is a diagram showing a configuration in which a spare server is shared by a plurality of services.
When looking at the load status of multiple services in a data center, it is extremely rare for all services to be loaded at the same time, and it is considered that there are always resources that are not used if spare resources are secured for each service. It is done. By sharing spare resources among a plurality of services, it is possible to add necessary service capability with fewer spare resources as a whole. Moreover, the maintenance cost can be dispersed by sharing. Service 1 and service 2 are installed in the center 12, and load distribution devices 13-1 and 13-2 are provided respectively. The service 1 includes a Web server 15-1, a database server 14-1, and a file server 14-2. The service 2 is provided with a server 25. The spare server 17 is provided in common for the service 1 and the service 2, and the system controller 16 introduces an additional server from the spare server 17 to the service 1 or the service 2 by checking the load state.
FIG. 10 is a diagram showing a configuration in the case of providing a spare server between different centers.
In the figure, the same components as those in FIG.
Depending on the scale of the data center 12-1, there may be a case where a spare server 17-1 that is physically or costly sufficient cannot be secured even if the spare server is shared between different services. In addition, even if it is intended to ensure enough, there may be a case where a spare server in the data center cannot be covered by a sudden load. In such a case, another data center 12-2 connected by a network is used as a subsequent center, and the spare server 17-2 is used via the network.
FIG. 11 is a diagram for explaining the operation of the embodiment of the present invention.
In the figure, the same components as those in FIG.
Some services require a server that operates in cooperation with a database in addition to a server that directly exchanges information with a user. In the case of such a service, improvement in performance cannot be expected unless the processing capability and load state are confirmed for each function and a server is added to an appropriate function. Therefore, the system control device 16 checks the load for each layer, and increases or decreases the capacity by changing the setting of the linked server when adding or deleting.
FIG. 12 is a diagram for explaining the securing of the network bandwidth in the case of cooperating with other centers.
In the figure, the same components as those in FIG. 10 are denoted by the same reference numerals.
When a plurality of services operate simultaneously or when linkage processing is necessary, sufficient processing capability cannot be obtained unless a server is added and traffic between the services and functions is not arbitrated. The bandwidth required for each part is calculated, and after considering the ratio, each band is secured to the network so that sufficient performance can be obtained as a whole.
With the above configuration, it is possible to monitor the load from the user and the status of the server capacity, and allocate necessary and sufficient resources from within the data center or from the linked data center before the load exceeds the server capacity. It is possible to guarantee the quality of service for a request from a user. Since necessary spare servers can be shared in a wide range at the same time, the total amount of necessary servers can be reduced as a whole. In addition, even for a service in which servers having a plurality of functions cooperate with each other, a server can be added to a function that is a bottleneck, so that the scale can be sufficiently increased. Furthermore, since the entire process can be automated, it is possible to quickly follow changes in the amount requested by the user.
FIG. 13 is a diagram illustrating an application example of the embodiment of the present invention in a web server.
In the figure, the same components as those in FIG.
When the load is light, only the front center 12-1 is operated. When the load increases, the spare server 17-1 in the upstream center 12-1 is added as the web server 15-1. When the load further increases, a web server group 15-2 is created in the latter stage center 12-2, and the latter center 12-2 is also responsible for the load.
FIG. 14 is a diagram illustrating an application example of the embodiment of the present invention in a web service.
In the figure, the same components as those in FIG.
In this example, the web service is composed of a combination of a web server 15-1, a database server 14-1, and a file server 14-2. When the load is light, only the front center 12-1 is operated. As the load increases, the spare servers 17-1 are sequentially added to the bottleneck portion, and when the front center 12-1 can not be cut, the cooperation with the rear center 12-2 is performed. The database server 14-1 in this example synchronizes data between the front center 12-1 and the rear center 12-2 even during cooperation. This is realized by creating a VLAN across the centers and securing the bandwidth.
FIG. 15 shows an application example of the embodiment of the present invention when resources are exchanged between equal centers.
When the processing capability of the service 1 in the center 1 cannot be covered by the spare server 30-1 in the center 1, the center 2 is requested to cooperate and the server in the center 2 (shaded portion and the spare server 30-3) Is used. Further, when the server capacity in the center 2 is also depleted (when the capacity including the spare server 30-2 is depleted), the other center 3 is requested to cooperate and the servers in the center 3 (shaded part and spare server). 30-3) is used.
FIG. 16 is a diagram illustrating an example in which the embodiment of the present invention is applied to a front-stage center that does not have a spare server.
If the system control unit 16-1 determines that there is a shortage of servers for service provision in the pre-stage center 12-1, the post-center 12-2 is requested to cooperate with the servers in the post-center 12-2. Use. Here, the load distribution device and the Web server are provided to the service 1 and the service 2. The service 1 ′ and service 2 ′ servers perform service 1 and service 2, respectively. Further, when the server capacity becomes insufficient in the rear stage center 12-2, the spare server 17 is added as necessary for each service. The system control unit 16-2 performs additional determination and cooperation with the upstream center 12-1.
17 to 24 are flowcharts for explaining the operation of the embodiment of the present invention when there is no cooperation between databases provided in the center.
FIG. 17 is a flowchart showing the overall flow of the system control apparatus.
First, in step S10, load measurement is performed. In step S11, it is determined whether the predicted processing capacity exceeds the allocated processing capacity. If the determination in step S11 is yes, processing capacity is added in step S12, and the process proceeds to step S15. In step S15, the process waits for 10 seconds. This numerical value should be set appropriately by the designer.
If the determination in step S11 is NO, in step S13, it is determined whether or not the current processing capacity is equal to or less than half of the allocated processing capacity. If the determination in step S13 is yes, processing capacity is reduced in step S14, and the process proceeds to step S15. If the determination in step S13 is no, the process proceeds to step S15.
After step S15, the process returns to step S10 again.
FIG. 18 is a diagram showing details of load measurement in step S10 of FIG.
In step S20, the average number of processes for 10 seconds is collected from the use server. This 10 seconds should coincide with the value in step S15 in FIG. In step S21, the total average number of processes is calculated and added to the measurement history. In step S22, it is determined whether there are four or more measurement histories. If the determination in step S22 is no, in step S23, the latest history is set as the predicted value after 30 seconds, and the process proceeds to step S25. If the determination in step S22 is yes, in step S24, a predicted value after 30 seconds is calculated from the latest 4 histories by least square approximation, and the process proceeds to step S25. This is to obtain a regression curve from the latest four histories and obtain a predicted value after 30 seconds using the regression curve. In step S25, a predicted value after 30 seconds is set. In step S26, the latest history is set to the current value, and the flow returns to the flow of FIG.
FIG. 19 is a diagram showing details of the processing capability addition processing in step S12 of FIG.
In step S30, an additional processing capacity amount is determined by subtracting the current assigned value from the predicted value. In step S31, it is determined whether there is a spare server in the center. If the determination in step S31 is YES, an additional server in the center is selected in step S32. In step S33, it is determined whether or not the additional processing capacity is satisfied. If the determination in step S33 is NO, the process proceeds to step S34. If the determination is YES, the process proceeds to step S38. If the determination in step S31 is no, the process proceeds to step S34.
In step S34, it is determined whether there is a cooperation destination center having a preliminary processing capability. If the determination in step S34 is yes, in step S36, the processing capability is assigned at the cooperation center. In step S37, it is determined whether or not the additional processing capacity is satisfied. If the determination in step S37 is no, the process proceeds to step S34. If the determination in step S37 is yes, the process proceeds to step S38. If the determination in step S34 is no, in step S35, the administrator is warned that the additional processing capacity cannot be satisfied, and the process proceeds to step S38. In step S38, the VLAN is set so as to include the selected server. In step S39, an application is set in the selected server, and the process proceeds to step S40.
In step S40, it is determined whether there is cooperation between the centers. If the determination is NO, the process proceeds to step S43. If the determination in step S40 is YES, in step S41, the cooperation center load distribution ratio is determined and the allocation device is set. In step S42, the communication band between the own center and the cooperation center is set, Proceed to step S43. In step S43, the load distribution ratio of the own center is determined, the allocation device is determined, and the flow returns to the flow of FIG.
FIG. 20 is a flowchart showing in detail the additional server selection process in step S32 of FIG.
In step S50, it is determined whether there is a server for a required application. If the determination in step S50 is no, the process proceeds to step S54. If the determination in step S50 is YES, in step S51, it is determined whether there is a server that can satisfy the additional processing capacity amount in one server for the required application. If the determination in step S51 is no, in step S52, the server with the maximum performance for the required application is selected, and the process returns to step S50. If the determination in step S51 is yes, the server with the lowest performance is selected from the servers for the necessary use among the servers that can provide the additional processing capacity, and the process proceeds to step S58.
In step S54, it is determined whether there is an available server. If the determination in step S54 is no, the process proceeds to step S58. If the determination in step S54 is yes, it is determined in step S55 whether or not there is a server that can satisfy the additional processing capacity amount by one unit. If the determination in step S55 is no, the server with the maximum performance is selected in step S56, and the process returns to step S54. If the determination in step S55 is YES, in step S57, the server with the lowest performance is selected from the servers that can satisfy the additional processing capacity amount by one unit, and the process proceeds to step S58. In step S58, the allocated server list is constructed, and the process returns to the process of FIG.
FIG. 21 is a flowchart showing the flow of the cooperation center processing capability assignment process in step S36 of FIG.
In step S60, it is determined whether or not the upper limit of processing capacity due to the bandwidth is smaller than the desired allocation value. If the determination in step S60 is no, the process proceeds to step S62. If the determination in step S60 is yes, in step S61, the allocated amount upper limit is set as the bandwidth upper limit, and the process proceeds to step S62.
In step S62, the cooperation destination center is requested to select a server. In step S63, an additional server is selected in the cooperation destination center. In step S64, the assigned server list is constructed, and the process returns to the process of FIG. .
FIG. 22 is a detailed flow of the application setting in step S39 of FIG.
In step S70, it is determined whether there is cooperation between the centers. If the determination in step S70 is no, the process proceeds to step S74. If the determination in step S70 is yes, it is determined in step S71 whether the application archive has been transferred. If the determination in step S71 is yes, the process proceeds to step S73. If the determination in step S71 is no, in step S72, the application archive is transferred to the cooperation destination center, and the process proceeds to step S73. In step S73, the application is installed on the additional server, and the process proceeds to step S74. In step S74, the application is installed in the own center additional server, and the process returns to the process of FIG.
FIG. 23 is a flowchart showing processing capacity reduction processing in step S14 of FIG.
In step S80, the current measured value is subtracted from the assigned value to determine the reduction processing capacity amount. In step S81, it is determined whether there is a cooperation center. If the determination in step S81 is yes, a reduction server is determined in the cooperation center in step S82, and it is determined in step S83 whether all the servers in the cooperation center have been reduced. If the determination in step S83 is yes, the process returns to step S81. If the determination in step S83 is no, the process proceeds to step S85. If the determination in step S81 is no, in step S84, a reduction server is determined in the own center, and the process proceeds to step S85.
In step S85, the determination of the load distribution ratio of the own center and the allocation device are set. In step S86, the load distribution ratio of the cooperation center is determined and the allocation device is set. In step S87, the process waits for completion of the user request process. In step S88, the application is deleted from the reduction server. In step S89, a VLAN is set so as to include only the remaining server (a network communication path for cooperation is set). In step S90, whether or not cooperation is released. Judging. If the determination in step S90 is yes, in step S91, the bandwidths of the local center and the cooperation center are released, and the process returns to the process of FIG. When the determination in step S90 is NO, the process returns to the process of FIG.
FIG. 24 is a flowchart showing the selection processing of the reduction server in step S82 or step S84 in FIG.
In step S100, it is determined whether there is a server that can be used for other purposes. If the determination in step S100 is no, the process proceeds to step S103. If the determination in step S100 is YES, in step S101, it is determined whether there is a server with performance lower than the remaining reduction performance. If the determination in step S101 is no, the process proceeds to step S103. If the determination in step S101 is yes, in step S102, the server having the highest performance is reduced among the servers whose performance is lower than the remaining reduction performance, and the process proceeds to step S100.
In step S103, it is determined whether there is a server currently in use. If the determination in step S103 is no, the process proceeds to step S106. If the determination in step S103 is YES, in step S104, it is determined whether there is a server whose performance is lower than the remaining reduction performance. If the determination in step S104 is no, the process proceeds to step S106. If the determination in step S104 is YES, in step S105, the servers with the highest performance among the servers with lower performance than the remaining reduction performance are reduced, and the process returns to step S103.
In step S106, the deleted server list is generated, and the process returns to the process of FIG.
FIG. 25 to FIG. 30 are flowcharts showing the flow of processing according to the embodiment of the present invention when there is database cooperation.
FIG. 25 is a flowchart showing the overall processing flow of the own center which makes a cooperation request.
In step S110, the load of the Web server is measured. In step S111, it is determined whether the predicted processing capacity is larger than the allocated processing capacity. If the determination in step S111 is yes, in step S112, web processing capability is added, and the process proceeds to step S115. If the determination in step S111 is no, it is determined in step S113 whether or not the current processing capacity is smaller than half of the allocated processing capacity. If the determination in step S113 is no, the process proceeds to step S115. If the determination in step S113 is yes, in step S114, the web processing capability is reduced, and the process proceeds to step S115. In step S115, the load on the in-center database is measured. In step S116, it is determined whether the predicted processing capacity is greater than the allocated processing capacity. If the determination in step S116 is yes, in step S117, database processing capacity is added, and the process proceeds to step S120. If the determination in step S116 is NO, it is determined in step S118 whether the current processing capacity is smaller than half of the allocated processing capacity. If the determination in step S118 is no, the process proceeds to step S120. If the determination in step S118 is yes, in step S119, the database processing capacity is reduced, and the process proceeds to step S120. In step S120, 10 seconds are waited. This waiting time should be appropriately set by the designer. After step S120, the process returns to step S110 again.
FIG. 26 is a flowchart showing the overall processing flow of the cooperation destination center.
In step S130, the database load in the center is measured. In step S131, it is determined whether the predicted processing capacity is greater than the allocated processing capacity. If the determination in step S131 is yes, in step S132, database processing capability is added, and the process proceeds to step S135. If the determination in step S131 is no, in step S133, it is determined whether or not the current processing capacity is smaller than half of the allocated processing capacity. If the determination in step S133 is no, the process proceeds to step S135. If the determination in step S133 is yes, in step S134, the database processing capacity is reduced, and the process proceeds to step S135. In step S135, the process waits for 10 seconds and returns to step S130. The 10 seconds should not be limited to this, but should be set appropriately by the designer.
FIG. 27 is a flowchart showing detailed processing of web load measurement or database load measurement performed at each center.
In step S140, the average number of processes for 10 seconds is collected from the use server. This 10 seconds should be the same value as the waiting time in step S120 in FIG. 25 and step S135 in FIG. In step S141, the total average number of processes is calculated and added to the measurement history. In step S142, it is determined whether there are four or more measurement histories. When the determination in step S142 is NO, in step S143, the latest history is set as a predicted value after 30 seconds, and the process proceeds to step S145. If the determination in step S142 is yes, in step S144, a predicted value after 30 seconds is derived from the latest four histories by least square approximation, and the process proceeds to step S145. This derivation method is as described in FIG.
In step S145, a predicted value after 30 seconds is set. In step S146, the latest history is set to the current value, and the processing returns to the processing of FIGS.
FIG. 28 is a detailed flow of the web processing capability addition process in step S112 of FIG.
The flow of FIG. 28 performs the processing from step S154 when a cooperation center is added.
First, in step S150, the current assigned value is subtracted from the predicted value to determine an additional processing capacity amount. In step S151, it is determined whether there is a spare server in the center. If the determination in step S151 is no, the process proceeds to step S154. When the determination in step S151 is YES, an additional server in the center is selected in step S152. Details of this processing are as shown in FIG. In step S153, it is determined whether or not the additional processing capacity has been satisfied. If the determination in step S153 is no, the process proceeds to step S154. If the determination in step S153 is yes, the process proceeds to step S158.
In step S154, it is determined whether there is a cooperation destination center having a preliminary processing capability. If the determination in step S154 is yes, in step S156, processing capabilities are assigned at the cooperation center. Details of this processing are as shown in FIG. In step S157, it is determined whether or not the additional processing capacity is satisfied. If the determination in step S157 is no, the process returns to step S154. If the determination in step S157 is yes, the process proceeds to step S158. If the determination in step S154 is no, in step S155, the administrator is warned that the additional processing capacity cannot be satisfied, and the process proceeds to step S158.
In step S158, the VLAN is set to include the selected server, and in step S159, an application is set to the selected server. The application settings are as shown in FIG. In step S160, it is determined whether there is cooperation between the centers. If the result of determination in step S160 is YES, in step S161, the cooperation center load distribution ratio is determined and the apparatus is set. In step S162, the communication band between the local center and the cooperation center is set, and the process proceeds to step S163. .
If the determination in step S160 is no, the process proceeds directly to step S163. In step S163, the load distribution ratio of the own center is determined, the apparatus is set, and the process returns to the process of FIG.
FIG. 29 is a detailed flow of the database processing capability addition process in step S117 in FIG. 25 and step S132 in FIG.
In step S170, the current assigned value is subtracted from the predicted value to determine the additional processing capacity amount. In step S171, it is determined whether there is a spare server in the center. If the determination in step S171 is no, in step S177, the possible web capabilities are calculated from the current database, and in step S178, the shortage web capabilities are added in the cooperation center. The processing in step S178 is as shown in FIG. Then, the processing returns to the processing of FIG. 25 or FIG.
If the determination in step S171 is YES, an additional server in the center is selected in step S172. In step S173, it is determined whether or not the additional processing capacity has been satisfied. If the determination in step S173 is no, the process proceeds to step S177. If the determination in step S173 is YES, in step S174, the VLAN is set to include the selected server, in step S175, the database is set in the selected server, and in step S176, the Web server in the center is set. The database list is updated, and the processing returns to the processing of FIG. 25 or FIG.
FIG. 30 is a flowchart showing details of an additional server selection process common to the Web server and the database.
In step S180, it is determined whether there is a necessary application server. If the determination in step S180 is yes, in step S181, it is determined whether there is a server that can satisfy the additional processing capacity amount in the server for the required application. If the determination in step S181 is no, in step S182, a server with the maximum performance for the required application is selected, and the process returns to step S180. If the determination in step S181 is yes, in step S183, the server with the lowest performance is selected from the servers that can satisfy the additional processing capacity amount by one unit, and the process proceeds to step S188.
If the determination in step S180 is no, it is determined in step S184 whether there is an available server. If the determination in step S184 is yes, in step S185, it is determined whether or not there is a server that can satisfy the additional processing capacity amount. If the determination in step S185 is no, in step S186, a server with the maximum performance that can be used is selected, and the flow advances to step S184. If the determination in step S185 is YES, in step S187, the server having the lowest performance is selected from the servers that can satisfy the additional processing capacity amount by one unit, and the process proceeds to step S188. If the determination in step S184 is no, the process proceeds directly to step S188.
In step S188, the allocated server list is constructed, and the process returns to the process of FIG.

  According to the present invention, it is possible to achieve service quality by dynamically allocating a spare server for each service and each data center when it is necessary without securing sufficient spare servers. Even in a small data center, it is possible to guarantee service quality even in the event of sudden load concentration by cooperating with other data centers. Furthermore, the equipment investment can be reduced by sharing the spare server, and at the same time, the equipment can be used effectively.

Claims (14)

  1. A load balancing method for a device including a plurality of servers that provide services to clients via a network,
    Providing a plurality of spare servers for sharing the load of the server providing the normal service, in which none of the services are set in the initial state;
    In anticipation of an increase in the load of the server that provides the normal service, an application for the service to be provided to the spare server is set to be a server for providing the service, and the load is shared with the server that provides the normal service Control steps;
    A method comprising the steps of:
  2. When a plurality of the devices are connected via a network and one device cannot support the load, a server that is normally used to provide a required service of another device is provided. The method of claim 1, wherein the method is provided for one device.
  3. 3. The method according to claim 2, wherein the other apparatus has a spare server, and provides the spare server when the server provided for the one apparatus cannot support the load. .
  4. The method according to claim 2, wherein when a load is shared among the plurality of devices, a communication band is secured between the plurality of devices.
  5. The control step determines whether or not to use a spare server for providing a service by predicting the magnitude of a load after a predetermined time from the number of requests processed in the past server. The method according to 1.
  6. The method according to claim 1, wherein when a spare server is used for a specific service, the spare server is used from a spare server suitable for providing the specific service based on hardware characteristics of the spare server.
  7. 2. The method according to claim 1, wherein when a spare server is used for a specific service, the processing capacity to be replenished is used in preference to a spare server that can be replenished by a single machine.
  8. 8. The method according to claim 7, wherein a spare server that can replenish a processing capacity to be replenished by one unit is used in preference to a spare server having the lowest performance.
  9. 2. When a call server is used for a specific service, if there is no spare server capable of replenishing the processing capacity to be replenished by one unit, a spare server having the maximum performance is used. The method described.
  10. When the load becomes low enough to be supported without a spare server, the control step deletes the application for providing the service from the spare server used to provide the service with a reduced load. The method according to claim 1, wherein the use of the spare server is stopped.
  11. The method according to claim 10, wherein when the use of the spare server is stopped, the use is stopped in consideration of the hardware characteristics of the spare server.
  12. 11. The use of the spare server having the maximum performance is stopped when the use of the spare server is stopped within a range in which the load of the specific service can be continuously supported by the remaining servers and the spare server. the method of.
  13. A device having a plurality of servers for providing services to clients via a network,
    A plurality of spare servers that do not have any services set up in the initial state to share the load of servers that provide normal services;
    In anticipation of an increase in the load of the server that provides the normal service, an application for the service to be provided to the spare server is set to be a server for providing the service, and the load is shared with the server that provides the normal service And a control means.
  14. A load balancing method for a device including a plurality of servers that provide services to clients via a network,
    Providing a plurality of spare servers for sharing the load of the server providing the normal service, in which none of the services are set in the initial state;
    In anticipation of an increase in the load of the server that provides the normal service, an application for the service to be provided to the spare server is set to be a server for providing the service, and the load is shared with the server that provides the normal service Control steps;
    A program for causing a computer to implement a method characterized by comprising:
JP2004569568A 2003-03-18 2003-03-18 Load balancing system by inter-site cooperation Granted JPWO2004084085A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2003/003273 WO2004084085A1 (en) 2003-03-18 2003-03-18 Load distributing system by intersite cooperation

Publications (1)

Publication Number Publication Date
JPWO2004084085A1 true JPWO2004084085A1 (en) 2006-06-22

Family

ID=33018146

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004569568A Granted JPWO2004084085A1 (en) 2003-03-18 2003-03-18 Load balancing system by inter-site cooperation

Country Status (2)

Country Link
JP (1) JPWO2004084085A1 (en)
WO (1) WO2004084085A1 (en)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4558740B2 (en) * 2004-10-20 2010-10-06 富士通株式会社 Application management program, application management method, and application management apparatus
JP4874807B2 (en) * 2004-10-20 2012-02-15 富士通株式会社 Server management program, server management method, and server management apparatus
JP2006259793A (en) * 2005-03-15 2006-09-28 Hitachi Ltd Shared resource management method, and its implementation information processing system
JP4650203B2 (en) * 2005-10-20 2011-03-16 株式会社日立製作所 Information system and management computer
JP4377369B2 (en) 2005-11-09 2009-12-02 株式会社日立製作所 Resource allocation arbitration device and resource allocation arbitration method
US7675854B2 (en) 2006-02-21 2010-03-09 A10 Networks, Inc. System and method for an adaptive TCP SYN cookie with time validation
JP2007264794A (en) * 2006-03-27 2007-10-11 Fujitsu Ltd Parallel distributed processing program and system
WO2008007435A1 (en) * 2006-07-13 2008-01-17 Fujitsu Limited Resource management program, resource management method, and resource management device
US8584199B1 (en) 2006-10-17 2013-11-12 A10 Networks, Inc. System and method to apply a packet routing policy to an application session
US8312507B2 (en) 2006-10-17 2012-11-13 A10 Networks, Inc. System and method to apply network traffic policy to an application session
JP5315128B2 (en) * 2009-05-25 2013-10-16 株式会社日立製作所 Process request destination management apparatus, process request destination management program, and process request destination management method
US9960967B2 (en) 2009-10-21 2018-05-01 A10 Networks, Inc. Determining an application delivery server based on geo-location information
JP2011138202A (en) * 2009-12-25 2011-07-14 Fujitsu Ltd Server device, server load distribution device, server load distribution method, and program
US9215275B2 (en) 2010-09-30 2015-12-15 A10 Networks, Inc. System and method to balance servers based on server load status
US9609052B2 (en) 2010-12-02 2017-03-28 A10 Networks, Inc. Distributing application traffic to servers based on dynamic service response time
US8897154B2 (en) 2011-10-24 2014-11-25 A10 Networks, Inc. Combining stateless and stateful server load balancing
US9386088B2 (en) 2011-11-29 2016-07-05 A10 Networks, Inc. Accelerating service processing using fast path TCP
US9094364B2 (en) 2011-12-23 2015-07-28 A10 Networks, Inc. Methods to manage services over a service gateway
US10044582B2 (en) 2012-01-28 2018-08-07 A10 Networks, Inc. Generating secure name records
US8782221B2 (en) 2012-07-05 2014-07-15 A10 Networks, Inc. Method to allocate buffer for TCP proxy session based on dynamic network conditions
US10021174B2 (en) 2012-09-25 2018-07-10 A10 Networks, Inc. Distributing service sessions
CN108027805A (en) 2012-09-25 2018-05-11 A10网络股份有限公司 Load distribution in data network
US10002141B2 (en) 2012-09-25 2018-06-19 A10 Networks, Inc. Distributed database in software driven networks
US9843484B2 (en) 2012-09-25 2017-12-12 A10 Networks, Inc. Graceful scaling in software driven networks
US9338225B2 (en) 2012-12-06 2016-05-10 A10 Networks, Inc. Forwarding policies on a virtual service network
US9531846B2 (en) 2013-01-23 2016-12-27 A10 Networks, Inc. Reducing buffer usage for TCP proxy session based on delayed acknowledgement
US9900252B2 (en) 2013-03-08 2018-02-20 A10 Networks, Inc. Application delivery controller and global server load balancer
WO2014144837A1 (en) 2013-03-15 2014-09-18 A10 Networks, Inc. Processing data packets using a policy based network path
US10027761B2 (en) 2013-05-03 2018-07-17 A10 Networks, Inc. Facilitating a secure 3 party network session by a network device
US10038693B2 (en) 2013-05-03 2018-07-31 A10 Networks, Inc. Facilitating secure network traffic by an application delivery controller
US10230770B2 (en) 2013-12-02 2019-03-12 A10 Networks, Inc. Network proxy layer for policy-based application proxies
US9942152B2 (en) 2014-03-25 2018-04-10 A10 Networks, Inc. Forwarding data packets using a service-based forwarding policy
US9942162B2 (en) 2014-03-31 2018-04-10 A10 Networks, Inc. Active application response delay time
US9906422B2 (en) 2014-05-16 2018-02-27 A10 Networks, Inc. Distributed system to determine a server's health
US9986061B2 (en) 2014-06-03 2018-05-29 A10 Networks, Inc. Programming a data network device using user defined scripts
US10129122B2 (en) 2014-06-03 2018-11-13 A10 Networks, Inc. User defined objects for network devices
US9992229B2 (en) 2014-06-03 2018-06-05 A10 Networks, Inc. Programming a data network device using user defined scripts with licenses
JP2016045505A (en) * 2014-08-19 2016-04-04 日本電信電話株式会社 Service providing system and service providing method
US10243791B2 (en) 2015-08-13 2019-03-26 A10 Networks, Inc. Automated adjustment of subscriber policies
WO2018097058A1 (en) * 2016-11-22 2018-05-31 日本電気株式会社 Analysis node, method for managing resources, and program recording medium

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3754481B2 (en) * 1996-02-02 2006-03-15 富士通株式会社 Compound computer system
JP2000298637A (en) * 1999-04-15 2000-10-24 Nec Software Kyushu Ltd System and method for load distribution and recording medium
JP2001007844A (en) * 1999-06-24 2001-01-12 Canon Inc Network status server, information distribution system, and its control method and storage medium storing its control program
JP2002163241A (en) * 2000-11-29 2002-06-07 Ntt Data Corp Client server system
JP2002259354A (en) * 2001-03-01 2002-09-13 Hitachi Ltd Network system and load distributing method

Also Published As

Publication number Publication date
WO2004084085A1 (en) 2004-09-30

Similar Documents

Publication Publication Date Title
KR100427143B1 (en) Method for Transmitting and Dowloading Streaming Data
CA2211774C (en) Load balancing method and apparatus
JP4068473B2 (en) Storage device, assignment range determination method and program
US6671724B1 (en) Software, systems and methods for managing a distributed network
KR100985619B1 (en) Apparatus, system, and method for on-demand control of grid system resources
US6400681B1 (en) Method and system for minimizing the connection set up time in high speed packet switching networks
US7593321B2 (en) Method and system for a local and fast non-disruptive path switching in high speed packet switching networks
EP1074913B1 (en) File server load distribution system and method
JP3627005B2 (en) System and method integrating load distribution and resource management in an Internet environment
US20020174227A1 (en) Systems and methods for prioritization in information management environments
US7558859B2 (en) Peer-to-peer auction based data distribution
US20020095400A1 (en) Systems and methods for managing differentiated service in information management environments
US20050052998A1 (en) Management of peer-to-peer networks using reputation data
AU2005314690B2 (en) System and method for scalable data distribution
US8191068B2 (en) Resource management system, resource information providing method and program
US8396957B2 (en) System and method for routing service requests
US20120173709A1 (en) Seamless scaling of enterprise applications
US20020049841A1 (en) Systems and methods for providing differentiated service in information management environments
US7680897B1 (en) Methods and systems for managing network traffic
EP1010102B1 (en) Arrangement for load sharing in computer networks
US20040100909A1 (en) Node system, dual ring communication system using node system, and communication method thereof
US7313659B2 (en) System and method for managing storage and program for the same for executing an operation procedure for the storage according to an operation rule
US20050086338A1 (en) Adaptive bandwidth throttling for network services
US20020065864A1 (en) Systems and method for resource tracking in information management environments
US8230438B2 (en) Dynamic application placement under service and memory constraints

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061121

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070118

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070522