Abstract:
A system comprises a front-stage center for directly receiving a request from a client through a network, and a back-stage center for receiving the request from the client through the front-stage center. The front-stage and back-stage centers have stand-by servers, respectively. The front-stage center provides a service using a normal server. When detecting that a load on the server increases, a first system control device provides a server for providing the service the load of which increases from the stand-by server commonly provided for a first service and a second service. If the load cannot be supported even by the provision of the server, the first system control device issues an instruction to a second system control device of the back-stage center to support the provision of the service. If the back-stage control device cannot support the load using a normal server, it supports the load using the stand-by server.

Description:
CROSS REFERENCE TO RELATED APPLICATION  
       [0001]     This application is a continuation of an International Application No. PCT/JP03/03273, which was filed on Mar. 18, 2003. 
     
    
     BACKGROUND OF THE INVENTION  
       [0002]     1. Field of the Invention  
         [0003]     The present invention relates to a load distribution system by inter-site co-operation.  
         [0004]     2. Description of the Related Art  
         [0005]     Due to the explosive popularity of the Internet, enormous resources, such as servers, networks and the like have been needed on the service providing side. It is known that the amount of their demand from users largely varies depending on time and conditions. Therefore, if such resources are secured based on the maximum demand, excessive resources must also be normally maintained. However, if resources incapable of meeting the maximum demand incur the degradation of service quality to give discomfort to users. Furthermore, with the increase of the numbers of users, it has become difficult to predict the upper limit of required resources, and a system for allocating resources as requested has become necessary. However, since excessive resources incur an increase in their management cost, a system for efficiently utilizing the excessive resources has also been necessary.  
         [0006]      FIG. 1  shows one example of the conventional load distribution system.  
         [0007]     In the configuration shown in  FIG. 1 , a client  10  accesses a data center  12  through a network  11  and receives services. A plurality of servers  14  is connected to a load distribution device  13 .  
         [0008]     If one server is not sufficient, as shown in  FIG. 1 , a plurality of servers is installed. In this case, a load is distributed to the plurality of servers by disposing the load distribution device  13  in the front stage to improve service quality. However, the addition determination of the server  14 , the actual addition of the server  14 /load distribution device  13 , and design modifications must be almost made by human power. Furthermore, the maximum number of servers must be always secured. Therefore, it requires a high cost.  
         [0009]     Patent Document  1  defines how to add servers and how to distribute requests from users. However, in that case, a mechanism for selecting a server must be incorporated on the user side, and accordingly, it is not suitable for application to a service for many and unspecified users. It has also a problem that the transmission/reception of management information other than a request is also necessary.  
         [0010]     The method of Patent Document 2 can be applied only to the case where static information is distributed, and cannot be applied to the case where different information must be returned each time, such as service provision, depending on a request from a user.  
         [0011]     Furthermore, Patent Document 3 also assumes static information, and the case where the load of a file server or the like becomes excessive is not considered. 
    Patent Document 1: Japanese Patent Application Publication No. H9-106381     Patent Document 2: Japanese Patent Application Publication No. H9-179820     Patent Document 3: Japanese Patent Application Publication No. 2002-259354    
 
       SUMMARY OF THE INVENTION  
       [0015]     It is an object of the present invention to provide a load distribution system for distributing a service provision load and capable of flexibly coping with the change of a request from a user.  
         [0016]     The method of the present invention is used to distribute the load of a device provided with a plurality of servers for providing clients with services through a network. The method comprises the step of providing a plurality of stand-by servers in which no service is initially set in order to distribute the load of a server for providing normal services, and the control step of anticipating the increase in load of the servers for providing regular services, setting application for the services in the stand-by servers, specifying the plurality of stand-by servers as servers for providing the services and sharing their loads with the servers for providing regular services.  
         [0017]     In the present invention, a plurality of stand-by servers is provided in the device of a data center or the like, in addition to the servers for providing regular services. If the load of the server for providing regular services increases, an application capable of providing such a service can be installed in a stand-by server, and the load for providing the relevant service of the server can be distributed.  
         [0018]     In another preferred embodiment, according to the present invention, devices provided with stand-by servers are connected to a network, and stand-by servers are shared between the devices. In this case, even if one data center cannot temporarily handle its load, the interruption of service provision due to a heavy load can be avoided by coping with the load by a plurality of devices co-operating through the network. Thus, the number of stand-by servers to be provided for one device can be reduced, and accordingly, there is no need for each device to have hardware redundantly. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0019]      FIG. 1  shows one example of the conventional load distribution system;  
         [0020]      FIG. 2  shows the basic configuration of the preferred embodiment of the present invention;  
         [0021]      FIG. 3  shows the network arrangement of a center in the basic configuration shown in  FIG. 2 ;  
         [0022]      FIG. 4  shows the first preferred embodiment of the present invention;  
         [0023]      FIG. 5  explains the operation of the first preferred embodiment of the present invention;  
         [0024]      FIG. 6  shows data for calculating the load and capacity of a server;  
         [0025]      FIG. 7  shows data for selecting a server according to the size of a load;  
         [0026]      FIG. 8  shows the relationship between the respective predicted values of the capacity and load of an added server;  
         [0027]      FIG. 9  shows a configuration for sharing a stand-by server with a plurality of services;  
         [0028]      FIG. 10  shows a configuration for sharing a stand-by server with different centers;  
         [0029]      FIG. 11  shows the operation of a preferred embodiment of the present invention;  
         [0030]      FIG. 12  explains how to secure a network band when co-operating with another center;  
         [0031]      FIG. 13  shows an application example of the preferred embodiment in a Web server;  
         [0032]      FIG. 14  shows an application example of the preferred embodiment in a Web service;  
         [0033]      FIG. 15  shows an application example of the preferred embodiment of the present invention in the case where resources are shared with equal centers;  
         [0034]      FIG. 16  shows an application example of the preferred embodiment of the present invention in the case where a front-stage center is not provided with a stand-by server;  
         [0035]      FIGS. 17 through 24  are flowcharts showing the operation of the preferred embodiment in the case where databases do not co-operate in a center; and  
         [0036]      FIGS. 25 through 30  are flowcharts showing the processes of the preferred embodiment of the present invention in the case where databases are in co-operation. 
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0037]     The present invention seeks to predict a change in the amount of requests from a user, to guarantee service quality by dynamically adding and deleting servers in the same data center or a co-operation destination center, according to the prediction, and also to reduce costs by sharing surplus servers with a plurality of services.  
         [0038]      FIG. 2  shows the basic configuration of the preferred embodiment of the present invention.  
         [0039]     A client  10  accesses a Web server  15 - 1  through a load distribution device  13 - 1  at the front-stage center  12 - 1  and through a network  11 . In this case, according to the result of the data processing in the Web server  15 - 1 , the client  10  accesses either a database server  14 - 1  or a file server  14 - 2 , and receives a service. A back-stage center  12 - 2  has almost the same configuration as the front-stage center  12 - 1 . The back-stage center  12 - 2  receives a request from the client  10  through the load distribution device  13 - 1 , and leads the client  10  to a Web server  15 - 2  while distributing load by a load distribution device  13 - 2 . Then, the client  10  accesses a database server  14 - 3  or  14 - 4  through the Web server  15 - 2  and receives the service.  
         [0040]     In this case, the front-stage center  12 - 1  and the back-stage center  12 - 2  mean a center for directly receiving users&#39; requests and a center for processing users&#39; requests through the front-stage center  12 - 1 , respectively. Servers are allocated among data centers multi-to-multi. In this case, sometimes a specific data center uses the servers of a plurality of data centers, and sometimes a specific data center simultaneously responds to server requests from a plurality of data centers. System control devices  16 - 1  and  16 - 2  total/determine/distribute the loads of servers and the loads of clients, and set the result in the servers  14 - 1  through  14 - 4  and load distribution devices  13 - 1  and  13 - 2 . If server resources are insufficient, the system control devices  16 - 1  and  16 - 2  sets required functions in stand-by servers  17 - 1  and  17 - 2  and add the stand-by servers for their services. Thus, their capacity is increased.  
         [0041]      FIG. 3  shows the network arrangement of the center in the basic configuration shown in  FIG. 2 .  
         [0042]     All servers are physically connected under a single switch group  20  in a network, and a plurality of logically independent networks (VLAN 0 , VLAN 11 , VLAN 12  and VLAN 21 ) is constituted. By such an arrangement, servers can be automatically added to necessary positions.  
         [0043]     When a server is added or deleted, server capacity is calculated based on server specifications, such as a CPU function, a network configuration and the like, the required number of servers is calculated and servers are appropriately allocated. Simultaneously, the traffic of the server is calculated, and a network band is secured or arbitrated.  
         [0044]     By estimating a future load from load measurement and load change prediction, servers can be added prior to the occurrence of an excess load, and service quality can be guaranteed.  
         [0045]      FIG. 4  shows the first preferred embodiment of the present invention.  
         [0046]     In  FIG. 4 , the same reference numerals are attached to the same components as those in  FIG. 2 , and their detailed descriptions are omitted.  
         [0047]     When a user&#39;s request exceeds the capacity of the allocated server, a response time increases or no response occurs to give discomfort to the user. If the load further increases in that state, sometimes a server failure occurs. In order to prevent this situation, the system control device  16  predicts the loads of servers. If it is determined that the current number of servers incurs a problem, a stand-by server  17  is added, and the setting of application, services, data to be used, and the like are set and introduced. Then, by updating the settings of dependent devices, servers and the like, they are incorporated in the service.  
         [0048]      FIG. 5  explains operation of the first preferred embodiment of the present invention. In  FIG. 5 , the same reference numerals are attached to the same components as those in  FIG. 4 , and their detailed descriptions are omitted.  
         [0049]     When the amount of requests from users decreases, a surplus server occurs. Even if this surplus server is deleted, service quality does not degrade. From the viewpoints of the improvement of a running cost and a used rate, it is rather preferable to release it as a stand-by server and to use it for another service. Thus, by deleting the related settings from the dependent devices, the link to the service is released. Then, the actual release of the settings is performed and the server is returned as a stand-by server  17 .  
         [0050]      FIG. 6  shows data for calculating the load and capacity of a server.  
         [0051]     In order to add/delete a server according to requested capacity, information about the service capacity of each server is necessary. In data centers and the like, service capacity per unit varies depending on the combination of used servers and devices, and application and services. When a plurality of data centers co-operate, it is practically impossible to prepare uniform servers. Therefore, the capacity of each server must be calculated based on the specifications of devices, such as a central processing unit (CPU), memory and the like. Thus, a method for predicting its capacity from capacity in a typical configuration, taking into consideration its CPU capacity and the like, is utilized.  
         [0052]      FIG. 7  shows data for selecting a server according to the size of a load.  
         [0053]     In this case, information how to utilize each server from the viewpoint of not only its service capacity but also its characteristic is stored. As described above, since the capacity of each used server is not uniform, it is necessary to prepare a configuration so as to provide requested capacity, by combining their capacities. Thus, highly recommended servers are selected and used with priority based on the capacity and characteristic calculated in  FIG. 6  and the requested capacity, until the amount of requests is satisfied.  
         [0054]      FIG. 8  shows the relationship between the respective predicted values of the capacity and load of an added server.  
         [0055]     Only adding resources simply when the measured amount of requests exceeds the service capacity does not guarantee service quality when the load is rapidly increasing. Therefore, in order to prevent the degradation of service quality, the tendency of the load must be determined, and if the amount of requests is predicted to increase, service capacity that meets the predicted amount of requests must be added in advance. As such a prediction method, linear extrapolation or the like can be used.  
         [0056]      FIG. 9  shows a configuration for sharing stand-by servers with a plurality of servers. When looking at the loads of a plurality of services at a specific data center, it is very rare for all the services to have heavy loads. Therefore if stand-by resources are secured for each service, there will be always surplus resources. In this case, if stand-by resources are shared with a plurality of services, requested service capacity can be satisfied by less stand-by resources as a whole. If stand-by resources are shared with a plurality of services, its maintenance cost can also be distributed. A center  12  is installed with services  1  and  2 , and the load distribution devices  13 - 1  and  13 - 2  are provided for each. The service  1  is provided further with 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 . Stand-by servers  17  are shared by the services  1  and  2 , and a system control device  16  assigns a server to the service  1  or  2  according to their loads.  
         [0057]      FIG. 10  shows a configuration for sharing stand-by servers with different centers. In  FIG. 10 , the same reference numerals are attached to the same components as those in  FIG. 2 , and their descriptions are omitted.  
         [0058]     Depending on the scale of a data center  12 - 1 , sometimes, a sufficient stand-by server  17 - 1  cannot be secured physically or in terms of a cost, for example, even when a stand-by server is shared by different services. Additionally, even when sufficient stand-by servers are secured, sometimes stand-by servers in the data center cannot handle a sudden load. In such a case, another data center  12 - 2  connected to the network can be used as a back-stage center, and its stand-by server  17 - 2  can be used through the network.  
         [0059]      FIG. 11  shows the operation of a preferred embodiment of the present invention. In  FIG. 11 , the same reference numerals are attached to the same components as those in  FIG. 9 , and their descriptions are omitted.  
         [0060]     A specific service requires a server for not only directly transmitting/receiving information to/from a user but also operation in co-operation with a database or the like. In the case of such a service, performance cannot be improved unless capacity and load are checked for each function and a server is added to the appropriate function. Therefore, the system control device  16  increases/reduces the capacity by checking a load for each layer and modifying the setting of a co-operation destination server when adding/deleting.  
         [0061]      FIG. 12  explains how to secure a network band when co-operating with another center. In  FIG. 12 , the same reference numerals are attached to the same components as those in  FIG. 10 .  
         [0062]     If a plurality of services operates simultaneously, or in co-operation is needed, in order to obtain sufficient capacity as a whole, not only a server is added, but also the traffic between services and functions must be arbitrated. In this case, a band required by each part must be calculated, and each band of the network must be secured taking its ratio into consideration.  
         [0063]     By adopting the above-mentioned configuration, a load from a user and server capacity can be monitored, and necessary and sufficient resources can be allocated within the data center or by a co-operating data center. Accordingly, service quality can be guaranteed against a request from a user. Since simultaneously necessary stand-by servers can be widely shared, the total number of necessary servers can be reduced as a whole. Since a server can be; added to a bottlenecked function even if a service requires the co-operation of servers with a plurality of functions, its scale can be sufficiently expanded. Furthermore, the entire process can be automated, a change in the amount of requests from a user can be quickly followed.  
         [0064]      FIG. 13  shows an application example of the preferred embodiment to a Web server. In  FIG. 13 , the same reference numerals are attached to the same components as those in  FIG. 12 , and their descriptions are omitted.  
         [0065]     In the case of a light load, only the front-stage center  12 - 1  handles it. When the load increases, stand-by server  17 - 1  in the front-stage center  12 - 1  is added as a Web server  15 - 1 . When the load further increases, a Web server group  15 - 2  is generated in the back-stage center  12 - 2 , and the back-stage center  12 - 2  also shares the load.  
         [0066]      FIG. 14  shows an application example of the preferred embodiment to a Web service. In  FIG. 14 , the same reference numerals are attached to the same components as those in  FIG. 12 , and their descriptions are omitted.  
         [0067]     In this example, a Web service is served by the combination of a Web server  15 - 1 , a database server  14 - 1  and a file server  14 - 2 . In the case of a light load, only the front-stage center  12 - 1  handles it. As the load increases, a stand-by server  17 - 1  is added to a bottlenecked part one after another. If the front-stage center  12 - 1  cannot handle the load alone, the back-stage center  12 - 2  co-operates. In this example, the database server  14 - 1  also synchronizes data between the front-stage center  12 - 1  and the back-stage center  12 - 2  during co-operation. This can be realized by generating VLANs crossing the centers and securing a band for them.  
         [0068]      FIG. 15  shows an application example of the preferred embodiment of the present invention in the case where resources are shared by equal centers.  
         [0069]     If the capacity of the service  1  in the center  1  together with a stand-by server  30 - 1  in the center  1  cannot handle the load, the center  1  requests the center  2  to co-operate and a server (a meshed portion and a stand-by server  30 - 2 ) in the center  2  is also used. If the server capacity in the center  2  cannot also handle the load (including the stand-by server  30 - 2 ), the center  1  requests another center  3  to co-operate and a server (a meshed portion and a stand-by server  30 - 3 ) in the center  3  is used.  
         [0070]      FIG. 16  shows an application example of the preferred embodiment of the present invention in the case where a front-stage center comprises no stand-by server.  
         [0071]     If in the front-stage center  12 - 1 , the system control unit  16 - 1  determines that servers are insufficient against a service provision, the front-stage center  12 - 1  requests the back-stage center  12 - 2  to co-operate and a server in the back-stage center is used. In this example, a load distribution device and a Web server are provided for the services  1  and  2 , respectively. The servers of services  1 ′ and  2 ′ provide services  1  and  2 , respectively. Furthermore, if in the back-stage center  12 - 2 , server capacity is insufficient, a necessary number of stand-by servers  17  are added to each service. The determination of addition and the co-operation with the back-stage center  12 - 2  are made by the system control unit  16 - 2 .  
         [0072]      FIGS. 17 through 24  are flowcharts showing the operations of the preferred embodiment of the present invention in the case where databases installed in a center do not co-operate.  
         [0073]      FIG. 17  is a flowchart showing the entire process of the system control device.  
         [0074]     Firstly, in step S 10 , a load is measured. In step S 11 , it is determined whether the predicted capacity exceeds an allocated capacity. If the determination in step S 11  is yes, in step S 12 , the capacity is added, an the process proceeds to step S 15 . In step S 15 , the process waits for  10  seconds, which a designer should design properly.  
         [0075]     If the determination in step S 11  is no, in step S 13 , it is determined whether the current capacity is the half or less of the allocated capacity. If the determination in step S 13  is yes, in step S 14 , the capacity id reduced, and the process proceeds to step S 15 . If the determination in step S 13  is no, the process proceeds to step S 15 .  
         [0076]     After step S 15 , the process returns to step S 10  again.  
         [0077]      FIG. 18  shows the details of the load measurement in step S 10  of  FIG. 17 .  
         [0078]     In step S 20 , the average number of processes for  10  seconds is collected from used servers. These  10  seconds should be matched with the value in step S 15  of  FIG. 17 . In step S 21 , the overall average number of processes is calculated, and is added to its measurement history. In step S 22 , it is determined whether there are four or more items in the measurement history. If the determination in step S 22  is no, in step S 23 , the latest history is designated as an estimation value after  30  seconds, and the process proceeds to step S 25 . If the determination in step S 22  is yes, in step S 24 , anestimation value after 30 seconds is calculated using four latest histories by least squares approximation, and the process proceeds to step S 25 . This means to calculate a regression curve using the four latest histories and to obtain an estimation value after  30  seconds. In step S 25 , the estimation value after  30  seconds is set. In step S 26 , the latest history is set to the current value, and the process returns to the flow shown in  FIG. 17 .  
         [0079]      FIG. 19  the details of the capacity addition process in step S 12  of  FIG. 17 .  
         [0080]     In step S 30 , an additional capacity is obtained by subtracting the currently allocated value from the estimation value. In step S 31 , it is determined whether there are stand-by servers in the center. If the determination in step S 31  is yes, in step S 32 , an addition server is selected in the center. In step S 33 , it is determined whether the additional capacity can be satisfied. If the determination in step S 33  is no, the process proceeds to step S 34 . If the determination is yes, the process proceeds to step S 38 . If the determination in step S 31  is no, the process proceeds to step S 34 .  
         [0081]     In step S 34 , it is determined whether there is a co-operation destination center with a stand-by capacity. If the determination in step S 34  is yes, in the step S 36 , a co-operation source center allocates capacity. In step S 37 , it is determined whether the additional capacity is satisfied. If the determination in step S 37  is no, the process proceeds to the step S 34 . If the determination in step S 37  is yes, the process proceeds to step S 38 . If the determination in step S 34  is no, in step S 35 , the dis-satisfaction of the additional capacity is notified to a manager, and the process proceeds to the step S 38 . In step S 38 , VLANs are set in such a way as to include the selected server. In step S 39 , application is set in the selected server, and the process proceeds to step S 40 .  
         [0082]     In step S 40 , it is determined whether centers are in co-operation. If the determination in step S 40  is no, the process proceeds to step S 43 . If the determination in step S 40  is yes, in step S 41 , the load distribution ratio of the co-operation destination center is determined and a server to which the load is distributed is selected. In step S 42 , a communication band is set between the co-operation source center and the co-operation destination center and the process proceeds to step S 43 . In step S 43 , the load distribution ratio of the co-operation source center is determined and servers to which the load is distributed are selected. Then, the process returns to the flow shown in  FIG. 17 .  
         [0083]      FIG. 20  shows the details of the additional server selection process in step S 32  shown in  FIG. 19 .  
         [0084]     In step S 50 , it is determined whether there is a server for a requested usage. If the determination in step S 50  is no, the process proceeds to step S 54 . If the determination in step S 50  is yes, in step S 51 , it is determined whether there is a server that can satisfy the additional capacity alone among the servers for the requested usage. If the determination in step S 51  is no, in step S 51 , a server with the maximum capacity is selected from the servers for the requested usage, and the process returns to step S 50 . If the determination in step S 51  is yes, a server with the minimum capacity is selected from servers for the requested usage that can satisfy the additional capacity, and the process proceeds to step S 58 .  
         [0085]     In step S 54 , it is determined whether there is an available server. If the determination in step S 54  is no, the process proceeds to step S 58 . If the determination in step S 54  is yes, in step S 55 , it is determined whether there is a server that can satisfy the additional capacity alone. If the determination in step S 55  is no, in step S 56 , a server with the maximum capacity is selected, and the process returns to step S 54 . If the determination in step S 55  is yes, in step S 57 , a server with the minimum capacity is selected from the servers that can satisfy the additional capacity alone, and the process proceeds to step S 58 . In step S 58 , a list of allocated servers is generated, and the process returns to the flow shown in  FIG. 19 .  
         [0086]      FIG. 21  shows the co-operation destination center capacity process in step S 36  of  FIG. 19 .  
         [0087]     In step S 60 , it is determined whether the upper limit of capacity due to a band is lower than desired capacity to be allocated. If the determination in step S 60  is no, the process proceeds to step S 62 . If the determination in step S 60  is yes, in step S 61 , the upper limit of the allocated capacity is designated as the upper limit of a band, and the process proceeds to step S 62 .  
         [0088]     In step S 62 , the selection of the additional server is requested to the co-operation destination center. In step S 63 , the additional server is selected in the co-operation destination center. In step S 64 , a list of the allocated servers is generated, and the process returns to the flow shown in  FIG. 19 .  
         [0089]      FIG. 22  shows the details of the application setting process in step S 39  of  FIG. 19 .  
         [0090]     In step S 70 , it is determined whether the centers are in co-operation. If the determination in step S 70  is no, the process proceeds to step S 74 . If the determination in step S 70  is yes, in step S 71 , it is determined whether application archives are already transferred. If the determination in step S 71  is yes, the process proceeds to step S 73 . If the determination in step S 70  is no, in step S 72 , the application archives are transferred to the co-operation destination center, and the process proceeds to step S 73 . In step S 73 , the application is installed in the additional server, and the process proceeds to step S 74 . In step S 74 , the application is installed in the additional server in the co-operation source center, and the process returns to the flow shown in  FIG. 19 .  
         [0091]      FIG. 23  shows the capacity reduction process in step S 14  of  FIG. 17 .  
         [0092]     In step S 80 , reduction capacity is determined by subtracting the current measured capacity from the allocated capacity. In step S 81 , there is a co-operation destination center. If the determination in step S 81  is yes, in step S 82 , a server which should be deleted is determined in the co-operation destination server. In step S 83 , it is determined whether the all servers in the co-operation destination center are deleted. If the determination in step S 83  is yes, the process returns to step S 81 . If the determination in step S 83  is no, the process proceeds to step S 85 . If the determination in step S 81  is no, in step S 84 , a server whose capacity is reduced is determined in the co-operation source center, and the process proceeds to step S 85 .  
         [0093]     In step S 85 , the load distribution ratio of the co-operation source center is determined, and servers to which the load is distributed are set for operation. In step S 86 , the load distribution ratio of the cooperation destination center is determined, and a server to which the load is distributed is set for operation. Then, in step S 87 , the completion of the user request process is awaited. In step S 88 , application is deleted from the server which is deleted. In step S 89 , the VLAN is set in such a way as to include only the remaining servers (a co-operation network communication line is set). In step S 90 , it is determined whether the co-operation should be released. If the determination in step S 90  is yes, in step S 91 , the band for communication between the co-operation source and destination centers, and the process returns to the flow shown in  FIG. 17 . If the determination in step S 90  is no, the process also returns to the flow shown in  FIG. 17 .  
         [0094]      FIG. 24  shows the reduction-target server selection process in step S 82  or S 84  shown in  FIG. 23 .  
         [0095]     In step S 100 , it is determined whether there is a server that can be used for another usage. If the determination in step S 100  is no, the process proceeds to step S 103 . If the determination in step S 100  is yes, in step S 101 , it is determined whether there is a server with capacity lower than the remaining capacity to be reduced. If the determination in step S 101  is no, the process proceeds to step S 103 . If the determination in step S 101  is yes, in step S 102 , the server with the maximum capacity lower than the remaining capacity to be reduced is deleted, and the process proceeds to step S 100 .  
         [0096]     In step S 103 , it is determined whether there is a server that is currently used. If the determination in step S 103  is no, the process proceeds to step S 106 . If the determination in step S 103  is yes, in step S 104 , it is determined whether there is a server with capacity lower than the remaining capacity to be reduced. If the determination in step S 104  is no, the process proceeds to step S 106 . If the determination in step S 104  is yes, in step S 105 , a server with the maximum capacity, of the servers with capacity lower than the remaining capacity to be reduced is deleted, and the process returns to step S 103 .  
         [0097]     In step S 106 , a list of deleted servers is generated and the process returns to the flow of  FIG. 23 .  
         [0098]      FIGS. 25 through 30  are flowcharts showing the processes of the preferred embodiment of the present invention in the case where databases are in co-operation.  
         [0099]      FIG. 25  shows the entire process of the co-operation source center that requests for co-operation.  
         [0100]     Instep S 110 , the load of a Web server is measured. In step S 111 , it is determined whether the predicted capacity is higher than the allocated capacity. If the determination in step S 111  is yes, in step S 112 , the Web capacity is added, and the process proceeds to the step S 115 . If the determination in step S 111  is no, in step S 113 , it is determined whether the current capacity is lower than the half of the allocated capacity. If the determination in step S 113  is yes, in step S 114 , the Web capacity is reduced, and the process proceeds to step S 115 . In step S 115 , the load of the database in the center is predicted. In step S 116 , it is determined whether the predicted capacity is higher than the allocated capacity. If the determination in step S 116  is yes, in step S 117 , the capacity of the database is added, and the process proceeds to step  120 . If the determination in step S 116  is no, in step S 118 , it is determined whether the current capacity is lower than the half of the allocated capacity. If the determination in step S 116  is yes, in step S 119 , the capacity of the database is reduced, and the process proceeds to step S 120 . In step S 120 , the process waits for  10  seconds. A designer should properly set this waiting time. After step S 120 , the process returns to step S 110  again.  
         [0101]      FIG. 26  shows the entire process of the co-operation destination center.  
         [0102]     In step S 130 , the load of the database in the center is measured. In step S 131 , it is determined whether the predicted capacity is higher than the allocated capacity. If the determination in step S 131  is yes, in step S 132 , the capacity of the database is added, and the process proceeds to step S 135 . If the determination in step S 131  is no, in step S 133 , it is determined whether the current capacity is lower than the half of the allocated capacity. If the determination in step S 133  is no, the process proceeds to step S 135 . If the determination in step S 133  is yes, in step S 134 , the capacity of the database is reduced, and the process proceeds to step S 135 . In step S 135 , after waiting for 10 seconds, the process returns to step S 130 . This waiting time is not limited to 10 seconds, and a designer should properly set it.  
         [0103]      FIG. 27  shows the details of the Web/database load prediction processes in each center.  
         [0104]     In step S 140 , the average number of processes for 10 seconds is collected from each used server. This time should be the same as the waiting time in step S 120  of  FIG. 25  and step S 141  of  FIG. 26 . In step S 141 , an overall average number of processes is calculated, and is added to the measurement history. Instep  142 , it is determined whether there are four or more items in the measurement history. If the determination in step S 142  is no, in step  143 , the latest history is designated as its prediction value after 30 seconds, and the process proceeds to step S 145 . If the determination in step S 142  is yes, in step S 144 , a prediction value after 30 seconds is calculated by least squares approximation using the latest four histories, and the process proceeds to step S 145 . This calculation method is already described with reference to  FIG. 18 .  
         [0105]     In step S 145 , a prediction value after 30 seconds is set. In step S 146 , the latest history is set as the current value, and the process returns to the flows shown in  FIGS. 25 and 26 .  
         [0106]      FIG. 28  shows the details of Web capacity addition process in step S 112  of  FIG. 25 .  
         [0107]     In the flowchart shown in  FIG. 28 , when another co-operation destination center is added, the process starts from step S 154 .  
         [0108]     Firstly, in step S 150 , additional capacity is determined by subtracting the current value from the predicted value. In step S 151 , it is determined whether there is a stand-by server in the center. If the determination in step S 151  is no, the process proceeds to step S 154 . If the determination in step S 151  is yes, in step S 152 , an additional server is selected in the center. The details of this process are as shown in  FIG. 20 . Then, in step S 153 , it is determined whether the additional capacity is satisfied. If the determination in step S 153  is no, the process proceeds to step S 154 . If the determination in step S 153  is yes, the process proceeds to step S 158 .  
         [0109]     In step S 154 , it is determined whether there is a co-operation destination center with stand-by capacity. If the determination in step S 154  is yes, in step S 156 , capacity is allocated in the co-operation source center. The details of this process are as shown in  FIG. 21 . in step S 157 , it is determined whether the additional capacity is satisfied. If the determination in step S 157  is no, the process returns to step S 154 . If the determination in step S 157  is yes, the process proceeds to step S 158 . If the determination in step S 154  is no, in step S 155 , the unsatisfactory additional capacity is notified to the manager, and the process proceeds to step S 158 .  
         [0110]     In step S 158 , the VLAN is set in such a way as to include the selected server. In step S 159 , an application is set in the selected server. The setting of the application is as shown in  FIG. 22 . In step S 160 , it is determined whether the centers are in co-operation. If the determination in step S 160  is yes, in step S 161 , the load distribution ratio of the co-operation destination center is determined, and a server to which the load is distributed is set for operation. In step S 162 , a communication band is set between the co-operation source and destination centers, and the process proceeds to step S 163 .  
         [0111]     If the determination in step S 160  is no, the process proceeds to step  163  without any process. In step S 163 , the load distribution ratio of the co-operation source center is determined, and servers to which the load is distributed are set for operation. Then, the process returns to the flow shown in  FIG. 25 .  
         [0112]      FIG. 29  shows the details of the database capacity addition process in step S 117  of  FIG. 25  and step S 132  of  FIG. 26 .  
         [0113]     In step S 170 , additional capacity is determined by subtracting the current value from the predicted value. In step S 171 , it is determined whether there is a stand-by server in the center. If the determination in step S 171  is no, in step S 177 , available Web capacity is calculated based on the current database. In step S 178 , the shortage of Web capacity is filled in the co-operation destination center. The process in step S 178  is as shown in  FIG. 28 . Then, the process returns to the flow shown in  FIG. 25  or  26 .  
         [0114]     If the determination in step S 171  is yes, in step S 172 , an additional server is selected in the center. Then, in step S 173 , it is determined whether the additional capacity is satisfied. If the determination in step S 173  is no, the process proceeds to step S 177 . If the determination in step S 173  is yes, in step S 174 , the VLAN is set in such a way as to include the selected server. In step S 175 , a database is set in the selected server. In step S 176 , the database list of the Web server in the center is updated, and the process returns the flow shown in  FIG. 25  or  26 .  
         [0115]      FIG. 30  shows the details of the process of selecting an additional server common to the Web server and database.  
         [0116]     In step S 180 , it is determined whether there is a server for a requested usage. If the determination in step S 180  is yes, in step S 181 , it is determined whether there is a server for the requested usage that can satisfy the additional capacity alone. If the determination in step S 181  is no, in step S 182 , a server for the requested usage with the maximum capacity is selected, and the process returns to step S 180 . If the determination in step S 181  is yes, a server with the minimum capacity, of the servers that can satisfy the additional capacity alone is selected, and the process proceeds to step S 188 .  
         [0117]     If the determination in step S 180  is no, in step S 184 , it is determined whether there is an available server. If the determination in step S 184  is yes, in step S 185 , it is determined whether a server can satisfy the additional capacity alone. If the determination in step S 185  is no, in step S 186 , a server with the maximum available capacity is selected, and the process proceeds to step S 184 . If the determination in step S 185  is yes, in step S 187 , a server with the minimum capacity is selected from the servers that can satisfy the additional capacity alone, and the process proceeds to step S 188 . If the determination in step S 184  is no, the process proceeds to step S 188  without any process.  
         [0118]     In step S 188 , a list of allocated servers is generated, and the process returns to the flow shown in  FIG. 28  or  29 .  
         [0119]     By the present invention, high service quality can be achieved by dynamically allocating servers as requested without securing sufficient stand-by servers for each service and for each data center. Even in a small-scaled data center, service quality can be guaranteed by co-operating with another data center when a load rapidly increases and is concentrated. Furthermore, by sharing stand-by servers, facilities investment can be reduced, and also facilities can be efficiently used.