Patent Publication Number: US-7716447-B2

Title: System, method and program for supporting a computer sizing having N level hierarchical resources

Description:
BACKGROUND OF THE INVENTION 
   1. Field of the Invention 
   The present invention relates to a sizing of hierarchical computer resources. More particularly, the present invention relates to a sizing support system, method and program for supporting the sizing for hierarchical computer resources of 3 hierarchy levels or more. 
   2. Description of the Related Art 
   The prices of the information processors such as the personal computer, workstation and the like (hereafter, referred to as nodes), which has one or more CPUs, memories and communication devices, have been reduced recently. As a result, the cluster constructed by combining (or clustering) a plurality of nodes to operate as one system becomes popular. In the cluster, the nodes are connected to and communicate with each other. The cluster is excellent in the cost performance and in the scalability. 
   The excellent scalability results from the characteristic that the cluster is hierarchical computer resources. The hierarchical resources are constructed from the computer resources provided with a plurality of hierarchy levels, and a resource of higher level (the higher level resource) is constituted by the combination of the resources of lower hierarchy level (the low level resources). The performance of a high level resource can be enhanced by increasing the number of low level resources or improving the performance of low level resources. For example, by increasing the number of the nodes constituting a cluster or improving the performance of the node, the performance of the cluster is enhanced. Thus, a cluster is hierarchical resources, and the nodes constituting the cluster are also hierarchical resources. This is because the increase in the number of the CPUs constituting a node or the improvement of the performance of the CPU improves the performance of the nodes. 
   Also, hierarchical resources having a uniform configuration are called as uniform hierarchical resources. For example, a cluster provided with only the nodes of the same kind is uniform hierarchical resources. Each of the nodes of the same kind is composed of the CPUs of the same kind and the same number. The actually used clusters are in many cases the uniform hierarchical resources. 
   It is important to consider the type of the resources to be employed and to determine the configuration of the hierarchical construction before constructing or enhancing the hierarchical resources. That is, in order to attain the processing performance necessary for the system, it is important to consider the types of the resources to be employed and to determine the configuration of the resource hierarchy. Such a process is called as sizing. The system which cannot provide the sufficient processing performance cannot provide sufficient services to clients. Thus, it is very important to execute the sizing at a high precision. 
   Typically, the sizing plan is experientially made on the basis of the sense and experience of skilled technicians. The processing performance of the hierarchical resources constituted in accordance with the sizing plan is estimated and compared with the processing performance required for the system. If the processing performance does not agree with the requirement, the sizing planning is executed again. 
   It is required that a technique which makes it possible to quantitatively execute the sizing of the hierarchical resources independently from the experience of technicians before construction or enhancing the hierarchical system. In particular, in many cases, clusters are the uniform hierarchical resources. Thus, the technique which supports the quantitative execution of the sizing of the uniform hierarchical resources is desired. 
   As the conventional technique related to the control and performance estimation of the computer resources after a computer system is constructed, the following techniques are known. 
   In Japanese Laid Open Patent Application (JP-P 2003-223335A), a virtual stand-alone outsourcing system is described. According to the virtual stand-alone outsourcing system, the computer resources are divided into a plurality of partitions, and the respective partitions are used by clients. Also, correspondingly to the performance information for each partition, the configuration of the partition is dynamically changed. 
   In Japanese Laid Open Patent Application (JP-P 2004-288183A), a method for automatically allocating computing resources in a partition server is described. According to the method, priorities are set for partitions. In accordance with the priority, the competition between the resources (CPUs) is solved, and the resource amount assigned to the partition is determined. 
   In Japanese Laid Open Patent Application (JP-P 2004-302525A) a performance balance evaluating apparatus of a computer system is described. A performance estimation index obtaining means individually transmits and receives a test application to and from each apparatus constituting an estimation target computer system. Then, the performance estimation index obtaining means changes the number of the test applications and obtains a transaction density and a performance estimation index of each apparatus. A use rate obtaining means transmits the test application to the estimation target computer system and instructs each apparatus to process such as a usual service application and obtains a use rate of each apparatus. A capacity calculating means divides the performance estimation index of each apparatus by each use rate and calculates the capacity of each apparatus. A performance balance evaluating means defines any one of the apparatuses as a standard apparatus and calculates a performance balance from a ratio between the capacity of a different apparatus and the allowable amount of the standard apparatus. 
   In Japanese Laid Open Patent Application (JP-P 2000-29753A), a performance evaluating method of a system having a hierarchical resource competition is described. In the hierarchical resources, a layer of a software resource is a higher order layer, and a layer of a hardware resource is a lower order layer. At first, the hardware configuration of the lower order layer is inputted. Next, a transaction data of a transaction using the software resource of the higher order layer is inputted. Next, a process data of a process constituting the software resource is inputted. Next, the restriction condition of the process is inputted. Next, the setting which shows what type of a performance estimation value is displayed in what type of a format is carried out. Next, whether or not the given data is sufficient for calculating the performance estimation value is checked. If it is sufficient, the performance estimation value to be determined under the restriction condition of the process of the higher order layer is calculated. Finally, a displaying means indicates those performance estimation values to a user. 
   In Japanese Laid Open Patent Application (JP-P 2004-78947A, having a counterpart U.S. Pat. No. 7,389,435), a method for satisfying the demanded capacity in a blade-based computer system is described. In the blade-based computer system, the number of loaded blades in the system is determined. Next, an optimal performance configuration for each of the individual blades is determined. The optimal performance configuration is based at least in part on the number of the blades loaded in the chassis and the overall thermal and power envelope. Then an individual frequency for at least one of the individual blades is set creating a more efficiently run system. 
   In Japanese Laid Open Patent Application (JP-P 2006-331135A, a performance prediction apparatus of a cluster system is described. The cluster system has nodes which share the data in a main storage device. The performance prediction apparatus calculates the frequency of block copy between the nodes, by which the data is copied by the unit of the memory block of the storage device per unit time. The clustering overhead occurred in the cluster system is calculated based on the frequency of the block copy and the information of the CPU load per block copy. 
   In a textbook (Kameda, H. (1998) The Elements and Applications of Performance Assessment, ISBN: 9784320026650, KYORITSU SHUPPAN CO., LTD. 28-30 (in Japanese)), the queuing theory for performance analysis is described. 
   SUMMARY OF THE INVENTION 
   The object of the present invention is to provide a technique for supporting a quantitative sizing of hierarchical resources before a system construction or enhancement. 
   According to the present invention, prior to the system construction or enhancement, the performance and cost of the hierarchical resources can be quantitatively estimated. Thus, prior to the system construction or enhancement, it is possible to execute the optimal sizing of the hierarchical resources at the good precision. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a block diagram showing the configuration of a sizing support system according to an embodiment of the present invention; 
       FIG. 2  is a block diagram showing a conceptual flow of data in the sizing support system according to an embodiment of the present invention; 
       FIG. 3  is a flowchart showing a sizing supporting method according to an embodiment of the present invention; 
       FIG. 4  is a conceptual view showing a hierarchy structure of a cluster which is a sizing target in the first example of an operation; 
       FIG. 5  is a view showing an example of lower level resource data; 
       FIG. 6  is a view showing an example of scalability data; 
       FIG. 7  is a view showing an example of unit performance data; 
       FIG. 8  is a view showing an example of cost data; 
       FIG. 9  is a flowchart showing a step S 10  in detail; 
       FIG. 10  is a view showing an example of a generated table frame; 
       FIG. 11  is a flowchart showing a step S 20  in detail; 
       FIG. 12  is a view showing an example of a generated scale table; 
       FIG. 13  is a flowchart showing a step S 30  in detail; 
       FIG. 14  is a view showing an example of a generated performance table; 
       FIG. 15  is a flowchart showing a step S 40  in detail; 
       FIG. 16  is a view showing an example of a generated cost table; 
       FIG. 17  is a view showing an example of a representation of a user view data; 
       FIG. 18  is a conceptual view showing a hierarchy structure of a cluster which is a sizing target in the second example of operation; 
       FIG. 19  is a view showing an example of lower order resource data; 
       FIG. 20  is a view showing an example of scalability data; 
       FIG. 21  is a view showing an example of unit performance data; 
       FIG. 22  is a view showing an example of cost data; 
       FIG. 23  is a view showing an example of a generated scale table; 
       FIG. 24  is a view showing an example of a generated performance table; 
       FIG. 25  is a view showing an example of a generated cost table; 
       FIG. 26  is a flowchart showing a step S 60  in detail; 
       FIG. 27  is a view showing an example of representation of a user view data; 
       FIG. 28  is a view showing an example of a performance table generated in a third operation example; and 
       FIG. 29  is a view showing an example of a cost table generated in the third example of operation. 
   

   DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   A sizing support system, a sizing supporting method and a sizing support program according to the embodiments of the present invention will be described below with reference to the attached drawings. The target system of the sizing is a uniform hierarchical resources of n hierarchy levels (n is an integer of 3 or more). The cluster system is exemplified as the target system of the sizing. For example, in the case of a cluster system of 3 hierarchy levels, a resource of the first hierarchy (top hierarch level) is the cluster system itself, resources of the second hierarchy are nodes, and resources of the third hierarchy are CPUs. The cluster system may be a virtual cluster system. Also, the target of the sizing may be a multiprocessor system, a virtual server or a blade server. 
   1. Sizing support system 
   The system of the sizing target may have the configuration of various patterns depending on the kinds of employed hardware. The sizing support system according to this embodiment quantitatively calculates the performances and costs of the entire system, with regard to the various patterns. Moreover, the sizing support system according to this embodiment indicates the relation between the performances and costs for the various patterns for supporting the user&#39;s estimation and selection. 
     FIG. 1  is a block diagram showing the configuration of the sizing support system  1  according to this embodiment. The sizing support system  1  contains a storage device  2 , a processor  3 , an input device  4 , a display  5 , a network interface  6  and a media drive  7 . 
   As the storage device  2 , the random access memory and hard disc are exemplified. The storage device  2  stores lower level resource data  10 , scalability data  20 , unit performance data  30  and cost data  40 . Those data may be inputted by the input device  4 , or provided through the network interface  6 . Or, those data may be recorded in a computer-readable recording medium and are read by the media drive  7 . The storage device  2  further stores a table frame T 10 , a scale table T 20 , a performance table T 30 , a cost table T 40  and a user view data  70 . Those tables and data are mainly generated by the sizing support system  1 . 
   The processor  3  includes CPU and carries out various processes and also controls the operations of each apparatus and each device. Also, the processor  3  executes a sizing support program  100  and attains the sizing support process in accordance with a command from the sizing support program  100 . 
   The sizing support program  100  is recorded in, for example, the computer-readable recording medium and read by the media drive  7 . Or, the sizing support program  100  may be provided through the network interface  6 . The sizing support program  100  provides a table definition module  110 , a scale estimation module  120 , a performance estimation module  130 , a cost estimation module  140 , a processing level decrementing module  160  and a user view generating module  170 , in linkage with the processor  3 . 
   As the input device  4 , the keyboard and the mouse are exemplified. As the display  5 , a liquid crystal display is exemplified. The user, while referring to the information displayed on the display  5 , can use the input device  4  and input the various data and commands. 
     FIG. 2  schematically shows the flow of the data in the sizing support system  1 . The table definition module  110  reads the lower level resource data  10  from the storage device  2  and generates the table frame T 10  in accordance with the lower level resource data  10 . The table frame T 10  is a frame of a table, and the generation of a table frame T 10  corresponds to a definition of an array. The respective elements of the array, namely, the modules for calculating the respective fields of the table are the scale estimation module  120 , the performance estimation module  130  and the cost estimation module  140 . The scale estimation module  120 , the performance estimation module  130  and the cost estimation module  140  are totally referred to as the field calculation module  150 . 
   The scale estimation module  120  reads the table frame T 10  and scalability data  20  from the storage device  2  and generates the scale table T 20  in accordance with the read data. The performance estimation module  130  reads the scale table T 20  and the unit performance data  30  from the storage device  2  and generates the performance table T 30  in accordance with the read data. The cost estimation module  140  reads the table frame T 10  and cost data  40  from the storage device  2  and generates the cost table T 40  in accordance with the read data. 
   The generated tables T 20  to T 40  may be directly outputted from the sizing support system  1 . Or, those tables T 20  to T 40  may be sent to the user view generating module  170 . The user view generating module  170  correlates those tables T 20  to T 40  to each other and generates the user view data  70 . The user view data  70  is displayed on the display  5 . In the user view data  70 , for example, the performance and cost of the entire system of the sizing target are correlated. The user can easily determine the proper hierarchical resource configuration by considering the relation between the performance and the cost which are displayed on the display  5 . 
   2. Details of the Process 
   The operations of the sizing support system  1  according to this embodiment will be described below in detail with reference to the flowchart shown in  FIG. 3 . The target of the sizing is a uniform sizing supporting of n hierarchies (n is an integer of 3 or more). As described later, the process is sequentially executed in which 3 hierarchies are treated as one unit. The 3 hierarchies of the process target will be referred to as the K-th hierarchy, the (K+1)-th hierarchy and the (K+2)-th hierarchy (K=1 to n−2). The process starts from the case of K=n−2 and is continued until K=1 is repeatedly carried out. 
   2-1. First Operation Example 
   As the first example of the operation according to the present invention, the sizing of the cluster of the computer system having 3 hierarchy levels (n=3) is described. In this case, as shown in  FIG. 4 , the resource group of the first (top) hierarchy level includes only the cluster itself, the resource group of the second hierarchy level includes nodes, and the resource group of the third hierarchy level includes the CPUs. With reference to resources included in a resource group of a certain reference hierarchy level, a resource in the level one rank higher than the reference level is referred to as the higher level resource, and a resource in the level one rank lower than the reference level is referred to as the lower level resource. For example in this case, a node is a lower level resource of the cluster, and a CPU is a higher level resource of a node. In this example, the cluster is constituted by the nodes of the same kind. Also, each of the nodes is constituted by the CPUs of the same kind and the same number. Namely, the sizing target cluster in this embodiment consists of uniform hierarchical resources. Depending on the kinds of the employed CPUs and nodes, the clusters of the various patterns are consisted. The sizing support system  1  according to this embodiment enables to calculate the performances and costs of clusters of various patterns. 
   Step S 1 : Provision of Basic Information 
   At first, the basic information used in the process is inputted to the sizing support system  1  and stored in the storage device  2 . The basic information includes the data indicating parameters with regard to the resources of the respective hierarchy levels and includes the lower level resource data  10 , the scalability data  20 , the unit performance data  30  and the cost data  40 , which will be described below. 
   (Lower Level Resource Data  10 ) 
     FIG. 5  shows an example of the lower level resource data  10 . The lower level resource data  10  indicates the possible kinds (or types) and maximum number of the 1-rank lower level resources which constitute the higher level resource for respective hierarchy levels. Specifically, with regard to the resources of each hierarchy, the kinds and maximum number of the lower level resources which can be possessed by the higher level resource are recorded. 
   For example, a lower level resource data  10 - 1  for the first hierarchy (K-th hierarchy) indicates the kind (identified by R K+1 ) of the node that can constitute the cluster (R K ) and the maximum number (M K+1 ) of the nodes. As the lower level resources of the cluster, two kinds of “2-way Node” and “4-way Node” are listed. The lower level resource data shown in  FIG. 5  shows that a maximum of 8 2-way nodes or a maximum of 7 4-way nodes can be set in a cluster. A lower level resource data  10 - 2  for the second hierarchy level ((K+1)-th hierarchy) indicates the kind R K+2  of the CPU that can constitute the node R K+1  and the maximum number M K+2  of the CPUs. The 2-Way node can possess a maximum of 2 CPU-A (CPU of type A). The 4-Way node can possess a maximum of 4 CPU-B. The lower level resource data  10 - 3  for the third hierarchy is not recorded since the third hierarchy level ((K+2)-th hierarchy) is the lowest layer. 
   (Scalability Data  20 ) 
     FIG. 6  shows an example of the scalability data  20 . Scalability implies the change rate of the performance with regard to the addition of each of the resources. In this embodiment, the scalability is defined as the value calculated by dividing the value which shows the performance of a resource by the N times the value which shows the performance of each of the N lower level resources which can be set in the higher level resource. For example, in the case that the a node process 100 requests per second and the cluster having 4 that kind of nodes process 350 requests per second, the scalability is 0.875(=350/(4×100)). The scalability indicates the rate of change of the performance per resource in response to the number of the resources in a certain hierarchy. 
   For example, a scalability data  20 - 2  for the second hierarchy ((K+1)-th hierarchy level) indicates the relation between the kind R K+1  of the node and the scalability based on the number (i: i=1 to M K+1 ) of the nodes. The scalability of the 2-way node is given as a one-dimensional array data s K+1  [1:8], and the scalability of the 4-way node is also given as a one-dimensional array data s K+1  [1:7]. Also, a scalability data  20 - 3  for the third hierarchy ((K+2)-th hierarchy) indicates the relation between the kind R K+2  of the CPU and the scalability based on the number (j: j=1 to M K+2 ) of the CPUs. The scalability of CPU-A is given as a one-dimensional array data s K+2  [1:2], and the scalability of CPU-B is given as a one-dimensional array data s K+2  [1:4]. The kind and the maximum number is consistent with the lower level resource data  10  shown in  FIG. 5 . A scalability data  20 - 1  for the first hierarchy (K-th hierarchy level) is not recorded because it is the sole constituent of the top level. 
   (Unit Performance Data  30 ) 
     FIG. 7  shows an example of the unit performance data  30 . This unit performance data  30  is given only to the third hierarchy level ((K+2)-th hierarchy) that is the lowest layer, and indicates unit performance (p K+2 ) with regard to the kind R K+2  of CPUs. The unit performance indicates the number of the requests that can be processed by the CPU in one second. In the example shown in  FIG. 7 , the unit performances of CPU-A and CPU-B are both 100. 
   (Cost Data  40 ) 
     FIG. 8  shows an example of the cost data  40 . This cost data  40  indicates the cost with regard to the resources of each hierarchy level. The cost includes the price of hardware, the license price of software. A cost data  40 - 2  for the second hierarchy level ((K+1)-th hierarchy) indicates the kinds R K+1  and costs c K+1  of the nodes. A cost data  40 - 3  for the third hierarchy level ((K+2)-th hierarchy) indicates the kinds R K+2  and the costs (c K+2 ) of the CPUs. Also, a cost data  40 - 1  for the first hierarchy level (K-th hierarchy) indicates the kinds (R K ) and the costs (c K ) of the nodes. However, in this embodiment, since the K-th hierarchy level is the highest, the cost thereof c K  is set to zero. The cost of the first hierarchy, namely, the cost of the cluster itself is one of the targets to be determined through the sizing support method. 
   Step S 2 : Execution of Program 
   Next, the sizing support program  100  is executed by the processor  3 . Consequently, the respective modules shown in  FIG. 2  are provided, and the processes are executed. 
   Step S 3 : Initial Setting of Process Hierarchy 
   The process is repeated with the 3 hierarchies (the (K to K+2)-th hierarchies) as one unit. Hereafter, the 3 hierarchies that are the process targets are referred to as “process hierarchy”. The process hierarchy is shifted in turn from the lower level (K=n-2) to the higher level (K=1). A processing level decrementing module  160  sets K to “n-2” as the initial setting of the process hierarchy level. In this example, since the sizing target has the 3 hierarchy levels, the process is repeated only one time. The hierarchy levels to be processed are the first hierarchy, the second hierarchy and the third hierarchy (K=1). 
   Step S 10 : Generation of Table Frame 
   The cluster of the sizing target may have the various configuration patterns, depending on the kinds and number of the employed nodes and CPUs. Thus, before estimating the performance and cost of the cluster, it is necessary to know the pattern types that may be possessed by the cluster. The patterns are defined in the table frame T 10 . The kinds and maximum number of the nodes that may be possessed by the cluster and the kinds and maximum number of the CPUs that may be possessed by the respective nodes are indicated in the lower level resource data  10  (shown in  FIG. 5 ). Thus, by referring to the lower level resource data  10 , it is possible to recognize the possible patterns of the cluster. 
   As shown in  FIG. 2 , the table definition module  110  generates the table frame T 10  in accordance with the lower level resource data  10 . The flow is shown in  FIG. 9  in more detail. At first, the table definition module  110  reads the lower level resource data  10  from the storage device  2  (Step S 11 ). Next, the table definition module  110  generates table frames T 10 - a , T 10 - b , which are shown in  FIG. 10 , for each resource kind R K+1  of the second hierarchy level (Step S 12 ). The table frame T 10 - a  indicates the pattern when the 2-way node is employed in the cluster, and the table frame T 10 - b  indicates the pattern when the 4-way node is employed in the cluster. 
   Each table frame T 10  is the frame of a two-dimensional table, and its column indicates the number of each kind of node i (i=1 to M K+1 ) of the second hierarchy level ((K+1)-th hierarchy), and its row indicates the number of each kind of CPU j (j=1 to M K+2 ) of the third hierarchy level ((K+2)-th hierarchy). For example, when the 2-way node is employed, the 2-way node may be constituted by a maximum of 2 CPU-A (refer to  FIG. 5 ). Thus, the column of the table frame T 10 - a  indicates the number i (=1 to 8) of the 2-way nodes, and its row indicates the number j (j=1, 2) of the CPU-A. Similarly, the column of the table frame T 10 - b  indicates the number i (=1 to 7) of the 4-way nodes, and its row indicates the number j (j=1 to 4) of the CPU-Bs. 
   In this way, the table frame T 10  indicates the configuration of the possible  44  configuration of the cluster. On the actual computer, the generation of the table frame T 10  corresponds to the definition of the data array. As each of the elements of the array (namely, each of the fields of the table), the performance and the cost are calculated. That is, for each of the possible configuration of the cluster, the properties of the performance and the cost are calculated. The calculation is carried out by the field calculation module  150  (consisting of the scale estimation module  120 , the performance estimation module  130  and the cost estimation module  140 ) which is described below. 
   Step S 20 : Generation of Scale Table 
   As shown in  FIG. 2 , the scale estimation module  120  generates the scale table T 20  in accordance with the table frame T 10  and scalability data  20 . The scale table T 20  is the table indicating performance magnification with regard to each of the possible configuration of the cluster. The performance magnification is the parameter indicating the magnification of the performance of the configuration, as compared with the case where the number of the lower level resources is 1. This performance magnification is calculated from the scalability and number of the lower level resources. 
   The flow is shown in  FIG. 11  in more detail. At first, the scale estimation module  120  reads the table frame T 10  and the scalability data  20  from the storage device  2  (Step S 21 ). Next, the scale estimation module  120  selects one table frame T 10  (Step S 22 ). Next, the scale estimation module  120  calculates a performance magnification S ij  for each field (each pattern) of the selected table frame T 10  (Step S 23 ). Its performance magnification S ij  is given by the following equation.
 
 S   ij   =s   K+1   [i]×i×s   K+2   [j]×j  
 
   Here, i is the node number (1 to M K+1 ) of the second layer, and j is the CPU number (1 to M K+2 ) of the third layer. Also, S K+1 [i] is the scalability of the node based on the number i and is obtained from the scalability data  20 - 2  shown in  FIG. 6 . Similarly, S K+2 [j] is the scalability of the CPU based on the number j, and is obtained from the scalability data  20 - 3  shown in  FIG. 6 . 
   With such a calculation, the scale table T 20  corresponding to the selected table frame T 10  is generated.  FIG. 12  shows an example of the scale table T 20  generated in this example. The scale tables T 20 - a , T 20 - b  correspond to the table frames T 10 - a , T 10 - b , respectively. When the processes with regard to all of the table frames T 10  have been completed (Step S 24 ; Yes), the generating process for the table frame T 10  is finished (Step S 25 ) 
   Step S 30 : Generation of Performance Table 
   As shown in  FIG. 2 , the performance estimation module  130  generates the performance table T 30  in accordance with the scale table T 20  and unit performance data  30 . The performance table T 30  is the table indicating performance with regard to each of the possible configuration of the cluster. 
     FIG. 13  shows the flow in more detail. At first, the performance estimation module  130  reads the scale table T 20  and the unit performance data  30  from the storage device  2  (Step S 31 ). Next, the performance estimation module  130  selects one scale table T 20  (Step S 32 ). Next, the performance estimation module  130  calculates the performance P ij  for each field (each pattern) of the selected scale table T 20  (Step S 33 ). The performance P ij  is given by the following equation.
   P   ij   =S   ij   ×p   K+2    
   Here, i is the node number (1 to M K+1 ) of the second level, and j is the CPU number (1 to M K+2 ) of the third level. Also, P K+2  is the unit performance of the CPU, and is obtained from the unit performance data  30  shown in  FIG. 7 . 
   With such a calculation, the performance table T 30  corresponding to the selected scale table T 20  is generated.  FIG. 14  shows the performance table T 30  generated in this example. The performance tables T 30 - a , T 30 - b  correspond to the scale tables T 20 - a , T 20 - b , namely, the table frames T 10 - a , T 10 - b , respectively. When the processes with regard to all of the scale tables T 20  have been completed (Step S 34 ; Yes), the generating process for the performance table T 30  is finished (Step S 35 ). 
   Step S 40 ; Generation of Cost Table 
   As shown in  FIG. 2 , the cost estimation module  140  generates the cost table T 40  in accordance with the table frame T 10  and cost data  40 . The cost table T 40  is the table indicating cost with regard to each of the possible configuration of the cluster. 
     FIG. 15  shows the flow in more detail. At first, the cost estimation module  140  reads the table frame T 10  and the cost data  40  from the storage device  2  (Step S 41 ). Next, the cost estimation module  140  selects one table frame T 10  (Step S 42 ). Next, the cost estimation module  140  calculates a cost C ij  for each field (each pattern) of the selected table frame T 10  (Step S 43 ). The cost C ij  is given by the following equation.
   C   ij   =c   K   +c   K+1   ×i+c   K+2   ×i×j    
   Here, i is the node number (1 to M K+1 ) of the second level, and j is the CPU number (1 to M K+2 ) of the third level. Also, c K , c K+1  and c K+2  are the costs of the nodes of the respective levels and are obtained from the cost data  40  shown in  FIG. 8 . 
   With such a calculation, the cost table T 40  corresponding to the selected table frame T 10  is generated.  FIG. 16  shows the cost table T 40  generated in this example. The cost tables T 40 - a , T 40 - b  correspond to the table frames T 10 - a , T 10 - b , respectively. When the processes with regard to all the table frames T 10  have been completed (Step S 44 ; Yes), the generating process for the cost table T 40  is finished (Step S 45 ). 
   Also, in order to cope with the price change factor such as a temporal discount and the like, the cost table T 40  may be directly given from outside. In such a case, the user uses the input device  4  for inputting the cost table T 40 . Or, the cost table T 40  may be provided through a network or computer readable medium. The given cost table T 40  has a format as shown in  FIG. 16  and is stored in the storage device  2 . 
   Step S 50 : 
   When K is 2 or more, namely, when the process hierarchy does not include the highest hierarchy level, a step S 60  which will be described later is executed. In this operational example, since K=1 (Step S 50 ; Yes), the process proceeds to a next step. 
   Steps S 70 , S 80 : Output of Result 
   All of the scale table T 20 , the performance table T 30  and the cost table T 40 , which are generated by the above mentioned processes, indicate the important parameters quantitatively when the proper cluster configuration is selected. Those tables T 20  to T 40  may be displayed in their original states on the display  5  or may be recorded onto the recording medium by the media drive  7 . The user can refer to those tables T 20  to T 40  and determine the cluster configuration which enables the desirable system. 
   Also, those tables T 20  to T 40  may be indicated to the user while they are correlated to each other. The user view generating module  170  correlates them. As shown in  FIG. 2 , the user view generating module  170  generates the user view data  70  by correlating the tables T 20  to T 40  to each other. For example, the user view data  70  indicates the relation between the performance and the cost, for each of the possible configuration of the cluster. The user view data  70  is given in a graph format or table format. The user view generating module  170  displays the user view data  70  on the display  5 . 
     FIG. 17  shows an example of the user view data  70  displayed on the display  5 . In  FIG. 17 , the relation between the performance and cost of the cluster is shown in the graph format. The vertical axis of the graph indicates the cost of the cluster, and the horizontal axis indicates the performance of the cluster. The vertical axis may alternatively indicate the cost per performance (the value calculated by dividing the cost the performance). The points in the graph correspond to the field values of the tables T 20  to T 40 . The points in the graph are linked through lines so that each kind of nodes are shown in series. For example, the relation of the case where the cluster is defined by the 4-way node having 2 CPU-B is represented by a group “4-way (2CPU)”. In each group, the leftmost point indicates the case where the number of the nodes is 1, and the number of the nodes increases by one each moving to the rights. 
   The user can easily judge the kind of the node to be employed in order to constitute a desirable cluster, by referring to this graph. For example, if firstly a cluster having the performance of processing 500 requests per second is constructed and the enhancement to 1000 requests per second is scheduled, the user may employ any of 2-way (2CPU), 4-way (2CPU), 4-way (3CPU) and 4-way (4CPU). Also, if desiring to constitute the cheapest cluster, the user may employ the 2-way (2CPU). 
   Also, if desiring to enhance the cluster so as to be able to process 1500 requests per second, the user may employ any of the 4-way (3CPU) and the 4-way (4CPU). If desiring further to enhance the cluster cheaply, the user may select the 4-way (4CPU). Because, with regard to the 4-way (4CPU), although the initial expense is high, the future enhancement is easy in cost. On the other hand, with regard to the 2-way (1CPU), it is understood that, although the initial expense is cheap, the price becomes in a neck when this will be enhanced in future. 
   The representation for indicating the relation between the performance and the cost as mentioned above is also possible in the case of the hierarchical resource of 2 levels. In that case, as compared with the representation shown in  FIG. 17 , only the number of the lines is reduced. 
   As explained above, it is possible to easily determine the hierarchical resource configuration required to attain a desirable system. Before constituting the cluster, the user can estimate the future enhancement and determine the optimal cluster configuration from the viewpoint of the initial expense and the future extensibility. Thus, it is possible to avoid the lack of the providing capacity of the services caused from the increase of the number of requests in future. 
   2-2. Second Operation Example 
   Next, let us consider the case where the hierarchical resources of the sizing target has the 4 or more hierarchy levels. As an example, the sizing of the cluster of the 4 hierarchy levels (n=4) is explained. In this case, as shown in  FIG. 18 , the resource of the first hierarchy level is the cluster, the resources of the second hierarchy level is the nodes, the resources of the third hierarchy level is the CPUs, and the resources of the fourth hierarchy level is cores. The cluster is constituted by the nodes of the same kind, and the respective nodes are constituted by the CPUs of the same kind and the same number, and the respective CPUs are constituted by the cores of the same kind and the same number. The sizing target cluster in this example is the uniform hierarchical resources. Depending on the kinds of the employed resources, the clusters of the various patterns may be constructed. In the explanation in this example, the explanation for the operations essentially same to the first operation is omitted. 
   The basic information inputted to the sizing support system  1  firstly at a step S 1  is explained below.  FIG. 19  shows an example of the lower level resource data  10 . The lower level resource data  10  includes the lower level resource data  10 - 1  to  10 - 4  for the respective hierarchy levels. The lower level resource data  10 - 4  for the fourth hierarchy level which is the lowest level is not recorded.  FIG. 20  shows an example of the scalability data  20 . The scalability data  20  includes the scalability data  20 - 1  to  20 - 4  for the respective hierarchy levels. The scalability data  20 - 1  for the first hierarchy level that is the highest level is not recorded.  FIG. 21  shows an example of the unit performance data  30 . This unit performance data  30  is given only to the fourth hierarchy level which is the lowest level.  FIG. 22  shows an example of the cost data  40 . The cost data  40  includes the cost data  40 - 1  to  40 - 4  for the respective levels. The cost c 1  of the first hierarchy level that is the highest level is set to “0”. 
   At the initial setting (Step S 3 ), K is set to 2 (=n-2). Thus, the process hierarchy levels in the first process are the second hierarchy level (K-th hierarchy), the third hierarchy level ((K+1)-th hierarchy) and the fourth hierarchy level ((K+2)-th hierarchy). After that, the processes similar to the first operation example are executed (Steps S 10 , S 20 , S 30  and S 40 ). As a result, the scale table T 20 , the performance table T 30  and the cost table T 40 , with regard to the k-th hierarchy (second hierarchy), are generated. 
     FIG. 23  shows the scale table T 20  generated by the first process. A scale table T 20 - a  corresponds to the case where the resources of the third hierarchy level are CPU-As. Its column indicates the number of CPU-As in the third hierarchy level, and the row indicates the number of core-As in the fourth hierarchy level. On the other hand, a scale table T 20 - b  corresponds to the case where the resources of the third hierarchy level are CPU-Bs. The column indicates the number of CPU-Bs in the third hierarchy level, and the row indicates the number of core-B in the fourth hierarchy. Each table indicates the performance magnification calculated for each of the various patterns. 
   Similarly,  FIG. 24  shows the performance table T 30  generated by the first process. Performance tables T 30 - a , T 30 - b  correspond to the cases where the resources of the respective third hierarchy level are CPU-A and CPU-B, respectively. Each of the tables indicates the performances calculated for each of the various patterns. Also,  FIG. 25  shows the cost table T 40  generated by the first process. Cost tables T 40 - a , T 40 - b  correspond to the cases where the resources of the third hierarchy level are CPU-A and CPU-B, respectively. Each of the tables shows the costs calculated for each of the various patterns. 
   Next, the step S 50  is executed. At the step S 50 , k is not 1. That is, the processing hierarchy does not include the highest level (Step S 50 ; No). In that case, the processing level decrementing module  160  changes the process hierarchy level (Step S 60 ).  FIG. 18  shows the flow at the step S 60  in detail. 
   At the second process, the process hierarchy proceeds to the first to third hierarchies. The third hierarchy level is the lowest in the processing hierarchy, and the unit performance data  30  with regard to the third hierarchy level is required. Thus, according to this embodiment, the unit performance of the CPU in the third hierarchy level is extracted from the performance table T 30  shown in  FIG. 24 . Specifically, from the performance table T 30  shown in  FIG. 24 , the values of fields P 11  to P 1MK+2  (the portions surrounded with the dotted lines in  FIG. 24 ) are referred. Those field values indicate the performances in the case where the number of the CPUs in the third hierarchy level is 1, namely, the unit performance of the third hierarchy level. Thus, the field values P 11  to P 1MK+2  of 3 kinds may be set as the unit performance data  30  for the third hierarchy level. The unit performance data  30  indicates the respective unit performances of the 3 kinds of (CPU-A, 1core-A), (CPU-B, 1core-B) and (CPU-B, 2core-B) (Step S 61 ). 
   Similarly, the cost of the CPU in the third hierarchy level is extracted from the cost table T 40  shown in  FIG. 25 . Specifically, from the cost table T 40  shown in  FIG. 25 , the values of fields C 11 to C 1MK+2  (the portions surrounded with the dotted lines in  FIG. 25 ) are referred. Those field values indicate the costs in the case where the number of the CPUs in the third hierarchy level is 1. Thus, the field values C 11  to C 1MK+2  of 3 kinds may be set as the cost data  40 - 3  for the third hierarchy level. The cost data  40 - 3  indicates the respective costs of the 3 kinds of (CPU-A, 1core-A), (CPU-B, 1core-B) and (CPU-B, 2core-B) (Step S 62 ). 
   In this way, the processing level decrementing module  160  refers to the performance table T 30  and the cost table T 40 , which are generated by the certain unit process, and consequently extracts the unit performance data  30  and the cost data  40 - 3  which are used by the next unit process. When the cost table T 40  is given from outside, the processing level decrementing module  160  refers to the performance table T 30  generated by the certain unit process and consequently extracts the unit performance data  30  that is used by the next unit process. In this way, the data generated by the certain unit process is fed back to the next unit process. 
   Next, the processing level decrementing module  160  carries out the decrement of K (Step S 63 ). As a result, K becomes 1, and the process hierarchy level is shifted to the first to third hierarchy levels. 
   Next, the second process is performed on the first hierarchy level (K-th hierarchy), the second hierarchy level ((K+1)-th hierarchy) and the third hierarchy level ((K+2)-th hierarchy) which are the new process hierarchy level. Here, as the data with regard to the third hierarchy level which is the lowest level, the extracted data are used. The second process is also executed similarly to the foregoing operation examples (Steps S 10 , S 20 , S 30  and S 40 ). As a result, the scale table T 20 , the performance table T 30  and the cost table T 40  with regard to the first hierarchy level are generated. Since K is 1 (Step S 50 ; Yes), the repetition of the process is finished. Then, in accordance with the finally-obtained tables T 20  to T 40 , the user view data  70  is generated (Step S 70 ), and its result is outputted to the display  5  (Step S 80 ). 
     FIG. 27  shows an example of the displayed screen image in this example. In  FIG. 27 , the relation of the performances and costs of the cluster are indicated in a graph format. In the graph, for each node kind, the groups of 10 kinds of [1. node-A, 1CPU-A, 1core-A], [2. node-A, 2CPU-A, 1core-A], [3. node-B, 1CPU-B, 1core-B], [4. node-B, 2CPU-B, 1core-B], [5. node-B, 1CPU-B, 2core-B], [6. node-B, 3CPU-B, 1core-B], [7. node-B, 4CPU-B, 1core-B], [8. node-B, 2CPU-B, 2core-B], [9. node-B, 3CPU-B, 2core-B] and [10. node-B, 4CPU-B, 2core-B] are indicated. 
   Even in the case where the sizing target is 5 hierarchy levels or more, the similar process is performed. The data obtained by a certain process is fed back as the data with regard to the lowest hierarchy level (the (K+2)-th hierarchy) in a next process. The repetition of the processes enables the estimation of the entire performance and cost of the n hierarchy levels. 
   2-3. Third Operation Example 
   The calculations of the performance and the cost are not required to be performed on all of the patterns that may be employed to constitute the cluster. The performance and the cost may be calculated only for a part of the configuration patterns of the cluster. For example, in the case where the excellent performance is required, the system where the number of the resources is small is considered to be unable to attain the required performance. Thus, in order to reduce the calculation, the calculation of the pattern where the number of the resources is small can be skipped for deriving enough information.  FIG. 28  shows an example of the performance table T 30  generated in this operation example, and this corresponds to  FIG. 14  illustrated in the first operation example. In  FIG. 28 , the performance where the number of the CPUs in the third hierarchy level is 1 is not calculated. The user obtains only the pattern where the performance is relatively high. 
   Also, in the case where the system of the relatively low cost is required, the calculation of the pattern where the cost becomes excessively high can be skipped. For example, if the cost exceeds a predetermined target value during the calculation, the calculation for that group is finished.  FIG. 29  shows an example of the cost table T 40  generated in this operation example and corresponds to  FIG. 16  illustrated in the first operation example. In  FIG. 29 , the pattern where the cost exceeds 8,000,000 yens is not shown. According to the third operation example, the calculation can be reduced. Moreover, the plot with regard to the pattern far away from the required system is not indicated. Thus, the user can easily view the result and determine the optimal configuration. 
   3. Effect 
   As explained above, according to this embodiment, it is possible to quantitatively estimate the performance and cost of the uniform hierarchical resources of the 3 hierarchies or more. Thus, it is possible to precisely execute the sizing estimation of the hierarchical resources before constructing the hierarchical computer system. Also, according to this embodiment, the relation between the performance and cost of the hierarchical resources can be provided to the user simply and easily. The user can easily determine the configuration of the proper hierarchical resources by considering the provided information. The user can determine the optimal configuration from the viewpoint of the initial cost and the future extensibility before constructing the cluster system. Hence, it is possible to avoid the lack of the provision capacity for coping with the requirements which may be increased in future. In this way, the sizing is supported. 
   In the above-mentioned embodiments, the cost data  40  indicating the price of each resource is used. The heat amount data indicating the heat amount discharged by each resource may be used instead of the cost data  40 . The format of the heat amount data is similar to the cost data  40 , and the processing can be carried out similarly. In this case, the relation between the performance and heat amount of the hierarchical resources of the cluster can be quantitatively provided to the user. The user can create the cluster which satisfies the required performance and is small in heat discharge. Other than the heat amount, the various sizing supports can be attained by introducing an index other than the performance.