Patent Publication Number: US-2006010031-A1

Title: System and method for computer resource marketing

Description:
The present application is a continuation of application Ser. No. 10/046,482, filed Jan. 16, 2002, the contents of which are incorporated herein by reference. 
    
    
     BACKGROUND OF THE INVENTION  
      The present invention relates to a computer system in which resources are shared among a plurality of computers interconnected through a network.  
      There is a known technology that divides one physical computer resource into logical partitions and uses them as a plurality of virtual computers, as disclosed, for example, in patent documents JP-A-103092/1994 and U.S. Pat. No. 5,659,786. Specific implementations of this technology are known by such names as hypervisor and LPAR (logical partition).  
      With recent advances in use of the Internet and intranets and a quantum leap in performance of personal computers, a type of technology for sharing or lending resources among a plurality of networked computers has been proposed. Known as peer-to-peer computing, this technology lends available computer resources by the hour and uses the partial resources of a plurality of personal computers to carry out processing that has conventionally been executed by supercomputers.  
      According to this technology, as shown in  FIG. 17 , a lending resource manager (resource management software)  91  is preinstalled on a lending computer  90 . A client that shares the resources of the computer  90  uses hardware  100 , comprising a CPU, a memory, and a disk drive, via the resource manager  91  and an operating system (referred to as OS below)  92  to submit a job (client application  93 ) for execution.  
      The example shown in  FIG. 17 , however, presents a problem in that the resource manager  91  installed on the computer  90  for lending resources is implemented as an application running on the shared OS  92  or as a built-in function of the OS  92 , so that, if the OS  92  stops (hangs up) under the influence of a lender&#39;s application  94  running on the computer  90 , resource lending services stop, resulting in poor service quality and performance.  
      Another problem, from the viewpoint of the lender (such as the owner) of the resources of the computer  90  is that the lender&#39;s application  94  may also stop if the OS  92  is hung up by the client application  93  running on a lent resource, and if a computer virus or worm is present in the client application  93 , it may destroy data in the computer  90  that lends the resource, or impair security, such as by allowing data to leak.  
      The former example (disclosed in JP-A-103092/1994 and U.S. Pat. No. 5,659,786) has another problem in that, although it can allocate logical partitions for lending, the resources allocated to the logical partitions can be changed while they are being lent, so that it is difficult to offer assured performance to the users.  
     SUMMARY OF THE INVENTION  
      An object of the present invention is to provide an improved processing capability and fault tolerance, to assure the quality of lent resources, and to provide adequate security for both the lender and the borrower, thereby making resource sharing more reliable.  
      Other objects of the present invention will become apparent in the description of the embodiments of the invention.  
      A computer resource marketing system according to the present invention comprises a computer with a logical partition control means for dividing resources of the computer into a plurality of logical partitions and designating at least one logical partition as lendable; a client system that can submit a job to the computer; a resource database which stores lending conditions and certification information of the logical partitions of the computer; and a management means that searches the resource database according to use requirements (borrowing requirements) defined by the client system, finds a logical partition that meets the use requirements, notifies the client system of the logical partition found by the search, and grants the client system permission to use the logical partition.  
      The logical partition control means comprises a means for storing allocation information indicating resources that have been allocated to the computer for lending to a client system, an altering means for changing logical partitions according to the allocation information, and a locking means for disabling a change of the logical partition at least while the client is using it, and, in a more preferable configuration, comprises a plurality of computers (logical partitions) in which different operating systems are bootable.  
      As described above, in a computer resource marketing system according to the present invention, in order to borrow one of a plurality of logical partitions generated in a computer, a client system sends use requirements to a management means that manages the lendable resources, and the management means references the resource database to determine the logical partition to be lent, whereby the client system on the borrowing side can quickly find resources that meet the use requirements and are available, and, in peer-to-peer computing that shares resources among a plurality of computers, quick acquisition of required performance and OSs is possible, enabling the lending side to ensure the processing capability, fault tolerance, and security by using logical partitions. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
      In the attached drawings:  
       FIG. 1  is a schematic block diagram of a resource marketing system according to a first embodiment of the present invention;  
       FIG. 2  is a table illustrating the data structure of an exemplary logical partition database of a lending server;  
       FIG. 3  is a table illustrating the data structure of an exemplary resource database of a management server;  
       FIG. 4  is a schematic block diagram showing the main data flow in a resource marketing system;  
       FIG. 5  is a flow diagram showing an example of logical partition generation processing executed by a lending server;  
       FIG. 6  is a flow diagram showing an example of the process of registering a lendable logical partition in a management server;  
       FIG. 7  is a flow diagram showing an example of the process of changing the allocated resources of a lendable logical partition;  
       FIG. 8  is a flow diagram of an example of processes performed in a management server and a client system when a borrowing request is made by the client system;  
       FIG. 9  is a flow diagram of an example of processes executed by a client system to borrow the resources of a lending server;  
       FIG. 10  is a table showing the data structure of a logical partition database according to a second embodiment;  
       FIG. 11  is a schematic diagram showing how the resources of one lending server are managed by a plurality of management servers;  
       FIG. 12  is a flow diagram showing an example of a process executed in a lending server to generate logical partitions;  
       FIG. 13  is a flow diagram showing an example of a process of registering a lendable logical partition in a management server;  
       FIG. 14  is a flow diagram showing an example of a process of changing the allocated resources of a lendable logical partition;  
       FIG. 15  is a flow diagram showing an example of a process for the borrowing of resources of a lending server by a client system;  
       FIG. 16  is a schematic block diagram of a resource marketing system representing a third embodiment of the present invention; and  
       FIG. 17  is a schematic diagram showing the prior art. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
      Embodiments of the invention will be described with reference to the attached drawings.  
       FIG. 1  shows an exemplary structure of a computer system representing for an embodiment of the present invention, comprising a plurality of lending servers (computers)  1   a  to  1   n  that provide computer resources (simply referred to as resources below), a plurality of client systems (computers)  20   a  to  20   m  that use resources provided by the plurality of lending servers  1   a  to  1   n,  and a management server (management means)  10  that manages resources of the plurality of lending servers  1   a  to  1   n  on the provider side, searches among the plurality of lending servers  1   a  to  1   n  for lending servers available to the plurality of client systems  20   a  to  20   m  and notifies the client systems  20   a  to  20   m,  which are attaches to a network  30 , of the search result, thereby forming a computer resource marketing system.  
      1. System configuration  
      The lending servers  1   a  to  1   n  each comprise a logical partition control unit  3  that divides one physical resource into a plurality of logical partitions and controls and manages the plurality of logical partitions, a logical partition management database  4  that stores the status (conditions, performance, and other properties) and operating conditions (lending conditions) of resources of the logical partitions, and a lender&#39;s interface control unit  5  that controls submission of jobs to lendable logical partitions, in which the jobs run.  
      The lending servers  1   a  to  1   n  are configured similarly, so the following description will be confined to the lending server  1   a;  and the client systems  20   a  to  20   m  used as user systems are configured similarly, so the following description will focus on the client system  20   a.    
      The logical partition control unit  3  divides a physical resource of the lending server  1   a  into a plurality of logical resources based on information in the logical partition management database  4 , assumes them to be the logical partitions, and allows an arbitrary OS (operating system) to start running on each of the logical partitions.  
      As in the technology disclosed by JP-A-103092/1994 and JP-A-295841/1995, the logical partition control unit  3  divides one physical computer resource into a plurality of logical partitions (virtual computers) and allows each of the logical partitions to function as an independent virtual computer.  
      In addition, the logical partition control unit  3  controls the plurality of logical partitions by separating them into lending partitions  2 A to  2 L that are provided to the client system  20   a  and a non-lendable logical partition  2 P. There may be only one lending partition, or there may be a plurality of non-lendable logical partitions.  
      The logical partition control unit  3  ensures the performance (resource bandwidth) of the lendable logical partitions  2 A to  2 L, references the logical partition management database  4  and the management server  10  to authenticate the client system  20   a  to which a logical partition is provided, and, as will be described later, ensures the performance to be provided by locking the logical partition while it is being lent to prevent changes of allocated resources. Ensuring performance means ensuring the processing capability of CPUs allocated to a lending partition (the number of CPUs or percentage of their time), and ensuring memory space and hard disk space.  
      The data structure of the logical partition management database, as shown in  FIG. 2 , comprises a logical partition ID (# 1  to #L)  41  of the available lendable logical partition  2 A to  2 L, information about resources allocated to the lendable logical partitions  2 A to  2 L and a non-lendable logical partition  2 P (allocated resource information  42 ), a lending key  44  for authenticating the client system  2   a  (described later) and determining IDs of lendable logical partitions  2 A to  2 L that have been requested for lending, and a lending flag  43  as information for identifying lending registrations of the lendable logical partitions  2 A to  2 L (registration requests) made to the management server  10  (or identifying whether they are being lent or not).  
      The allocated resource information  42  comprises information including the types and number of CPUs, the upper limit of performance (or processing capability) that can be allocated, the upper limit of resources that can be provided, such as memory space and hard disk space, and available OSs.  
      The lending flag  43  indicates “lending registered” after the management server  10  has received notification of lending, or otherwise, indicates “lending unregistered”.  
      A lending key  44  is set for each of the lendable logical partitions  2 A to  2 L and is not set for the non-lendable logical partition  2 P that is not available to other computers.  
      The management server  10 , which is attached to the network  30 , stores information about lendable logical partitions of the lending servers  1   a  to  1   n,  searches for a lending server and a lendable logical partition that meet the requirements of a borrowing request (a request to use) from one of the client systems  20   a  to  20   m,  and, if there is a logical partition meeting the requirements, lends the lending key to that one of the client systems  20   a  to  20   m,  thereby marketing computer resources.  
      The management server  10  mainly comprises a resource database  12  that stores information about the lendable logical partitions  2 A to  2 L of each of the lending servers  1   a  to  1   n,  a control unit  11  (control means) that performs processing in response to the lending registration from the lending servers  1   a  to  1   n  and borrowing requests or searching requests from the client systems  20   a  to  20   m,  and a billing information database  13  that calculates the bill for the lending of resources that the client systems  20   a  to  20   m  have used and the consideration to be paid to the lending servers  1   a  to  1   n  and stores the results.  
      The data structure of the resource database  12 , shown in  FIG. 3 , in which information based on registration requests from the lending servers  1   a  to  1   n  is stored, comprises a lending server ID  101  (# 1  to #N) of the lending servers  1   a  to  1   n,  a logical partition ID  102  (# 1  to #L) of the lendable logical partitions  2 A to  2 L that are set (or can be set) for each lending server, lending conditions  103  that are set for each lendable logical partition, a lending key  104  for each lendable logical partition, and the lending status  105  of each lendable logical partition.  
      The lending server ID  103  is a field that comprises, for example, information such as IP addresses and MAC addresses by NIC as information by which lending servers can be identified. The logical partition ID  102  is a field that stores information that identifies logical partitions set for each lending server.  
      The lending conditions  103  include information (upper limit of CPU processing capability, memory amount, and hard disk space) that is stored in the allocated resource information  42  of the logical partition management database  4  in each of the lending servers  1   a  to  1   n  and rate information, such as the lending charge per unit time.  
      The lending key  104  is used for authentication when the associated logical partition is used, and it comprises, in the resource database  12 , for example, information by which a lending server ID  101  and a logical partition ID  102  can be identified.  
      The lending status  105  is a field that stores the ID (# 1  to #M) of one of the client systems  20   a  to  20   m  if the logical partition is being used thereby, and remains empty if the logical partition is not being used.  
      The client systems  20   a  to  20   m  that use the lendable logical partitions  2 A to  2 L of the lending servers  1   a  to  1   n  request borrowing of the resources from the management server  10  and the lending servers  1   a  to  1   n;  and, each comprises a user interface control unit  25  for submitting jobs to the lending servers  1   a  to  1   n.    
      The OSs running on the client systems  20   a  to  20   m  need not be of the same type; any type of OS may be used.  
      2. System Overview  
      An overview of the resource marketing system using the management server  10 , the lending server  1   a,  and the client system  20   a  will now be described with reference to  FIG. 4 .  
      In the lending server  1   a,  a non-lendable OS (such as an OS of the owner of the computer)  21 P and a lender&#39;s application  22 P are running on the non-lendable logical partition  2 P (refer to  FIGS. 1 and 2 ); the partition control unit  3 , when there are spare resources or in response to a command from a server manager, references the logical partition management database  4  and requests the management server  10  to register information on available lendable logical partition  2 A; and, the management server  10  registers the information.  
      The client system  20   a  sends a request to borrow (use) a logical partition on given conditions to the management server  10 ; then the management server  10  searches the resource database  12  based on the borrowing request conditions; and, if the contents of the lending conditions  103  of the lendable logical partition  2 A in the lending server  1   a  meet the use requirements of the request and the lending status field  105  is blank, indicating that the partition is not in use, the management server  10  sends the allocated resource information determined from the lending server ID  101 , the logical partition ID  102 , and the lending key  104  or the lending conditions  103  in the resource database  12  to the client system  20   a,  whereby the borrowing contract is concluded.  
      After the contract is concluded, the client system  20   a  sends the lending key  104 , lendable logical partition ID  102  (in this case # 1 ), and allocated resource information (lending conditions  103 ) to the lending server  1   a  to request borrowing of the lendable logical partition  2 A.  
      Then, the lending server la checks the lending key  104 , lendable logical partition ID  102 , and allocated resource information that have been sent against the corresponding information of the lending key  44  and other items stored in the logical partition database  4  for certification. This certification can also be carried out using only the lending key  104 . The minimum information required for certification (certification information) is the lending key  104 , but preferably, certification should be carried out using the lending key  104 , the lending server ID  101 , the logical partition ID  102 , and the allocated resource information (lending conditions  103 ).  
      After the certification, the logical partition control unit  3  divides or generates the lendable logical partition  2 A, and then starts an OS according to the borrowing request from the client system  20   a;  and, the lending interface control unit  5  executes a job (application  22 A) submitted by the client system  20   a.    
      The logical partition control unit  3 , at least while the lendable logical partition  2 A is provided to the client system  20   a,  locks the logical partition, forbids the supervisor (a system administrator or personnel with highest authorization) of the lending server  1   a  to change the logical partition while it is being lent, and disables alteration of resources that have been allocated to the lendable logical partition, thereby assuring the quality of resources to be provided, or their processing capability (or computing power). A lendable logical partition may be locked after the lending is registered in the management server  10 .  
      Since the lendable logical partition  2 A generated on the lending server ia starts running a lending-dependent OS  21 A, and this OS runs in a logical partition different from the non-lendable logical partition  2 P in which OS  21 P running in, even if one of these two OSs or one of its applications hangs up, the other OS can continue executing its own applications without being affected; and, even if the client application  22 A and other applications of the lendable logical partition  2 A are infected with computer viruses and worms, the OS  21 P and lender&#39;s application  22 P of the non-lendable logical partition  2 P cannot be affected by them, whereby adequate security on both the lending and borrowing sides of the logical partitions can be provided.  
      On completion of the job from the client system  20   a,  the logical partition control  3  notifies the client system  20   a  of the completion of the job; and, the client system  20   a  notifies the management server  10  of the termination of the lending of the resource.  
      When the client system  20   a  terminates the loan, the management server  10  restores the lending status  105  in the resource database  12  to blank, stores a lending charge based on the rate information in the lending conditions in the billing information database  13 , charges the client system  20   a  (or the owner thereof and other persons) for using the resources, and pays the lending server  1   a  (or the owner thereof) a consideration for the loan.  
      3. Details of the System  
      The details of resource marketing performed by the management server  10 , the lending server la, and the client system  20   a  will now be described.  
      3-1. Process of Generating Lendable Logical Partitions in a Lending Server  
      The lending servers  1   a  to in generate lendable logical partitions  2 A to  2 L based on borrowing requests from the client systems  20   a  to  20   m,  and allocate them to the client systems. The lendable logical partitions  2 A to  2 L are dynamically changed by the logical partition control unit  3 , so they do not always exist.  
      Therefore, if there is a requested logical partition among the lendable logical partitions  2 A to  2 L, the lending key  44  is checked against the lending key  104 , and then the logical partition is allocated; however, if there is not a requested logical partition among the lendable logical partitions  2 A to  2 L, it is generated.  
      A process of generating lendable logical partitions  2 A to  2 L that is carried out in the lending server  1   a  will be described with reference to the flow diagram in  FIG. 5 .  
       FIG. 5  shows a process flow in the lending server  1   a  from acceptance of borrowing requests from the client systems  20   a  to  20   m  to generation and allocation of the lendable logical partitions.  
      The lending server, on reception of a borrowing request from the client system  20   a  at the lender&#39;s interface control unit  5 , sends the logical partition ID  102 , allocated resource information and the lending key  104  that have been received from the client system  20   a  to the logical partition control unit  3  (Step S 1 ).  
      The logical partition control unit  3  obtains the lending flag  43 , indicating use of a lendable logical partition, associated with the logical partition ID  102  that has been sent to the logical partition database unit  4  and allocates resource information  42  (Steps S 2  and S 3 ).  
      Next, the logical partition control  3  determines whether the lendable logical partition of concern is unallocated or on loan (Step S 4 ).  
      If the lendable logical partition of concern is already lent or the lending key  104  does not match, the logical partition control unit  3  notifies the lender&#39;s interface control unit  5  of the inability to generate the lendable logical partition.  
      If the lendable logical partition of concern is not in use and the lending key  104  received from the client system  20   a  matches the lending key  44  in the logical partition database  4 , the logical partition control unit  3  allocates the lendable logical partition for lending to the client system  20   a.    
      If the lendable logical partition of concern does not exist, the logical partition control unit  3  generates a lendable logical partition based on the allocated resource information  42 , and, if the resources allocated to the non-lendable logical partition  2 P are insufficient, it requests the logical partition database  4  to alter the contents of the allocated resource information  42  (Steps S 6  and S 7 ).  
      On completion of generation and allocation of the lendable logical partition, the logical partition control unit  3  notifies the lender&#39;s interface control unit  5  (Step S 8 ).  
      After notification in Step S 8 , the lender&#39;s interface control unit  5  waits for a job (application  22 A shown in  FIG. 4 ) to be submitted.  
      3-2. Process of Registering a New Lendable Logical Partition in the Management Server  
      The contents of the resource database  12  in the management server  10  is generated, updated, or deleted based on a registration request from the lending servers  1   a  to  1   n,  in which the resource information of the lendable logical partition determined by the lending server is stored.  
      The flow of registration in the resource database  12  will be described with reference to the flow diagram in  FIG. 6 .  
       FIG. 6  shows the process of registering new lending resource information in the management server  10  by the lending server la.  
      Defining a logical partition of the lending server  1   a  as a new lendable logical partition to enable it to be used by the client systems  20   a  to  20   m  on the network  30  first requires registration in the management server  10 .  
      Therefore, in the lending server  10 , the lender&#39;s interface control unit  5  must request new lending registration of a logical partition to the logical partition control unit  3  (Step S 11 ).  
      The lender&#39;s interface control unit  5  sends to the logical partition control unit  3  the lending information comprising the lending conditions, including the ID, allocated resource information, and charge information and lending key of the new lendable logical partition to be provided. The lending information comprises information set or entered by the administrator or other personnel of the lending server  1   a.    
      On reception of this lending information, the logical partition control unit  3  requests the logical partition database  4  to register a new lendable logical partition, and writes the lendable logical partition ID  41 , allocated resource information  42 , and lending key  44  therein (Step S 12  and S 13 ).  
      On completion of the registration in the logical partition database  4 , the logical partition control unit  3  requests the lending server  10  to register the new lendable logical partition, and sends information (lending registration information) comprising the server ID  101 , ID of the lendable logical partition, lending conditions, and lending key thereto (Step S 14 ).  
      On reception of the registration request from the lending server la, the control unit  11  of the management server  10  sends a command to write the ID of the lending server  1   a  and the received lending information registration into the resource database  12  (Step S 15 ).  
      On completion of writing the new lending registration information, the resource database  12  notifies the control unit  11  of the completion of the registration (Step S 16 ); and, the management server  10  notifies the lending server  1   a  of the completion of registration of the new lendable logical partition (Step S 17 ).  
      On reception of this notification of the completion of registration, the lending server  1   a  requests the logical partition database unit  4  to set the lending flag  43  for the logical partition ID  41 , the registration of which is requested from the logical partition control unit  3  (Step S 18 ); and, the logical partition database unit  4  sets the lending flag  43  of the lendable logical partition concerned to “lending registered” (Step S 19 ).  
      This lendable logical partition is locked starting from the time point when the lending flag  43  is set to “lending registered”.  
      On completion of the registration of the new lendable logical partition to the logical partition database  4 , the logical partition control unit  3  notifies the lender&#39;s interface control unit  5  of the completion of the registration, and terminates the process (Step S 2 G).  
      3-3 Process of Altering Registered Information of a Lendable Logical Partition  
      When the lending server  1   a  changes the providable lendable logical partitions, it must always change the contents of the resource database  12  of the management server  10 . This is because, if the performance of the lendable logical partitions of the lending server  1   a  differs from the information of lending conditions stored in the resource database  12 , it becomes impossible to assure the performance of the lendable logical partitions for the client systems  20   a  to  20   m  using them.  
      The flow of a process of altering the registered information of the lendable logical partition will be described with reference to the flow diagram in  FIG. 7 .  
       FIG. 7  shows a process of altering the information about a lendable logical partition registered to the management server  10  by the lending server  1   a.    
      To alter the information about a logical partition of the lending server that has been registered in the resource database  12  of the management server  10 , the information to be altered, comprising the logical partition ID  41 , the allocated resource information  42 , the lending conditions including charge information, and the lending key  44  of the logical partition of concern, is sent from the lender&#39;s interface control unit  5  to the logical partition control unit  3  (Step S 21 ). The information to be altered is set or entered by the administrator or other personnel of the lending server  1   a.    
      On reception of the information to be altered, the logical partition control unit  3  notifies the management server  10  of the alteration request for the lendable logical partition, and sends the new logical partition ID, lending conditions, lending key, and server ID  101  to the management server  10  (Step S 22 ).  
      The control unit  11  of the management server  10  searches the resource database  12  based on the received alteration request, server ID  101 , and logical partition ID for the current lending status  105  to determine whether the logical partition is being lent or not (Steps S 23  and S 24 ).  
      If one of the IDs of the client systems  20   a  to  20   m  has been stored in the lending status  105 , the lendable logical partition of concern is being used, so the control unit  11  notifies the logical partition control unit  3  that the contents of the lending conditions  103  and other items cannot be altered; and, the logical partition control unit  3  sends the response from the management server  10  to the lender&#39;s interface control unit  5  (Steps S 25  and S 26 ).  
      On the contrary, if the field of the lending status  105  is concern is blank, the lendable logical partition is not in use, so the control unit  11  alters (updates) the information of the logical partition ID  102 , lending conditions  103 , and lending key  104  in the resource database  12  according to the altering information received from the lending server  1   a  (Steps S 27  and S 28 ).  
      On completion of alteration of the resource database  12 , the control unit  11  of the management server  10  notifies the lending server  1  a that the alteration has been completed (Step S 29 ).  
      On reception of the completion of the alteration of the resource database  12 , the logical partition control unit  3  of the lending server  1   a  alters the information of the logical partition ID  41 , allocated resource information  42 , and lending key  44 , and after the completion of this alteration, notifies the lender&#39;s interface control unit  5  of the completion of the alteration and terminates the process (Steps S 30  to S 32 ).  
      3-4 Process of Concluding a Borrowing Contract With a Client System  
      In order to borrow the resources of the lending server  1   a,  the client systems  20   a  to  20   m  must first make a query about the available lending server  1  a and the lendable logical partitions thereof, and, if there is a resource meeting its requirements, make a borrowing contract and obtain the lending key.  
      The process of concluding a borrowing contract with a client system will be described with reference to the flow diagram in  FIG. 8 .  
       FIG. 8  shows an example of a borrowing contract concluded between client system  20   a  and the management server  10 .  
      The client system  20   a  exchanges data with the management server  10  via the user interface control unit  25 . First, it sends borrowing requirements comprising required performance (required processing capability) and rate information of a desired resource to the management server  10  (Step S 41 ). The borrowing requirements are previously set or entered.  
      On reception of the borrowing requirements, the control unit  11  of the management server  11  searches the resource database  12  for a logical partition that meets the borrowing requirements, obtains the lending conditions for the logical partition (Step S 42  and S 43 ), and sends the search result to the client system  20   a  (Step S 44 ).  
      The client system  20   a  borrows resources based on the received lending conditions  103  by making a borrowing contract request to the management server  10  (Step S 45 ).  
      In response to the resource borrowing contract request, the control unit  11  of the management server  10  sends a request to borrow the intended logical partition to the resource database  12  by using the lending server ID, lendable logical partition ID and the ID of the client system  20   a  obtained in Step S 43  as the borrower ID; and, the resource database  12  stores the borrower ID in the lending status  105  field, and passes the lending key  104  associated with the lending server ID and lendable logical partition ID to the control unit  11  (Step S 46  and S 47 ).  
      The control unit  11  sends to the lending server ID, lendable logical partition ID, and lending key  104  to the client system  2 G a,  whereby the borrowing contract is concluded (Step S 48 ).  
      The management server  10  stores the time when the lending server ID, lendable logical partition ID and lending key  104  are sent to the client system  20   a,  or the time when the borrowing contract is concluded, and sets this time as a starting time for computing charges to (use by) the client system  20   a  based on the rate information.  
      3-5 Job Submission by Client Systems  
      On conclusion of the borrowing contract in Step S 48 , the client system  20   a  becomes able to execute a job (processing) using the borrowed resources defined by the lendable logical partition ID in the lending server ID that has been sent to it by the management server  10 . On completion of the job, the client system  20   a  requests the management server  10  to delete the borrowing registration and terminates the borrowing contract.  
      The flow of a process from submittal of the job to the end of resource borrowing, which is executed among the client system  20   a,  the lending server  1   a  and the management server  10 , will be described with reference to the flow diagram in  FIG. 9 .  
      The client system  20   a  is notified of the lendable logical partition  2 A to be lent in the lending server  1   a  by the management server  10 , and is given the associated lending key.  
      The client system  20   a  sends the lending server  1   a  a job submittal request comprising the logical partition ID, lending key  104 , and job information (Step S 51 ). The job information comprises, for example, the type of OS to be booted in the lendable logical partition  2 A, and the types of applications to be executed.  
      In response to the job submittal request from the client system  20   a,  the logical partition control unit  3  of the lending server ia determines whether the received lending key  104  matches the lending key  44  in the logical partition database  4  or not, and if the lending key  104  does not match the lending key  44 , notifies the client system  20   a  that the job submittal request is rejected (Step S 52  to S 54 ).  
      If the lending key  104  and  44  match, the logical partition control unit  3  accepts the jog submittal request and executes the job from the client system  20   a  in the designated lendable logical partition  2 A (Step S 55 ).  
      On completion of the job, the lendable logical partition  2 A notifies the logical partition control unit  3  that the job has been completed; and, the logical partition control unit  3  in turn notifies the client system  20   a  (Steps S 56  and S 57 ).  
      On reception of the notification of job completion, the client system  20   a  notifies the management server  10  of the termination of the borrowing contract (Step S 58 ). Specifically, the notification of termination of the borrowing contract is made by sending the lending server ID, logical partition ID, and lending key to the management server  10 .  
      The management server  10  receives this borrowing contract termination notification at the control unit  11 , searches the resource database  12  with the ID of the client system  20   a  as the borrower ID, and based on the received lending server ID, logical partition ID, and lending key, and deletes the borrower ID from lending status  105  in which it was stored during the loan (see  FIG. 3 ) to indicate not-in-use status, thereby deleting the borrowing registration of the resource (Step S 59  and S 60 ).  
      The management server  10  notifies the client system  20   a  of the termination of the borrowing of the resource, thereby ending the series of resource marketing and borrowing processes (Step S 61 ). On termination of the resource borrowing contract, the management server  10  sets the time point when the client system  20   a  sent the resource borrowing termination request as the end point of the time for calculating the charge (end point of use), calculates the charge from the starting point described above to the end point as billing information, and stores the result in the billing information database.  
      4. Actions  
      For simplification, the example described above uses a single lending server  1   a  and client system  20   a,  but the client systems include a plurality of computers, as shown in  FIG. 1 .  
      The plurality of client systems  20   a  to  20   m  can borrow the plurality of lendable logical partitions  2 A to  2 L generated in the plurality of lending servers  1   a  to in by referencing the management server  10  that manages the lending resources to speedily identify available resources that meet the borrowing requirements, enabling quick acquisition of required performance and OSs in peer-to-peer computing in which resources are shared among a plurality of computers.  
      At least while the lendable logical partition  2 A is being provided to the client system  20   a,  the logical partition control unit  3  of the lending server  1   a  to  1   n  that provides resources locks this logical partition and disables alteration of this logical partition while it is being lent, by operations on the lending server side, thereby enabling the quality of resources to be provided, or the processing capability (or the computing capability or bandwidth), to be assured.  
      In the embodiment described above, a lending server using a logical partition control unit  3 , such as an LPAR or hypervisor unit, generates lendable logical partitions and non-lendable logical partitions, so that the lendable logical partition  2 A to  2 L are logical partitions different from the OS  21  P of the non-lendable logical partition and an independent lending OS  21 A is run thereon; consequently, if one of the applications or OSs hangs up, the other OS is not affected thereby and can continue executing applications, whereby fault tolerance can be improved. Even if an application executed in one logical partition is infected by computer viruses or worms, OSs or the application P executed in other logical partitions cannot be infected, so adequate security can be provided for both the lenders and borrowers of the logical partitions; and, in peer-to-peer computing in which a plurality of client systems  20   a  to  20   m  share the use of logical partitions of a plurality of lending servers  1   a  to  1   n,  lending conditions can be assured, adequate fault tolerance and security can be provided, and higher quality services can be provided, thereby implementing resource marketing systems suitable for execution of mission-critical operations such, as IDC (Internet Data Canter) and ASP (Application Service Provider).  
      In a preferred configuration, a plurality of logical partitions can each run a different OS, so the logical partitions do not affect each other. Therefore, if processing or an OS in one logical partition hangs up, processing in other logical partitions can be continued, and the services provided can be made fault tolerant. In addition, infection of computer viruses and worms among the logical partitions cannot occur, so that it is possible to provide adequate security and a higher-quality resource marketing system.  
      The logical partition control means (the logical partition control unit  3 ) of a computer (lending server) that offers resources disables alteration of a logical partition, at least while the client is using the logical partition, so it becomes possible to prevent the logical partition from being altered by operations on the computer side while it is being lent, whereby the quality of resources provided, or the processing capability (or computing capability, or bandwidth), can be assured.  
       FIGS. 10 and 11  show a second embodiment of the invention, in which the hardware structure is the same as in the first embodiment of the invention, but the lending flag  43  of the logical partition database of the lending servers  1   a  to  1   n  that was used in the first embodiment of the invention is eliminated, while a field for external reference information  45  comprising externally referenced management server IDs is provided, thereby enabling the allocated resource information  42  of the lendable logical partitions (# 1  to #L) to be referenced from a resource database  12  that is provided outside the lending server (in the management server  10 ), and enabling control of the allocated resource information  42  with the resource database  12  of the lending servers  10  to  10   i  for each lendable logical partition.  
      The logical partition database  4 ′ that manages logical partitions of each of the lending servers  1   a  to  1   n  comprises the following fields: a logical partition ID  41  (# 1  to #P) that identifies logical partitions, the externally referenced information  45  that stores the ID of any of the external management servers  10  to  10   i  to be referenced, the allocated resource information  42 , and lending key  44 .  
      In the logical partition database  4 ′, logical partitions, the management server IDs of which are stored in the field of the externally referenced information  45 , are handled as lendable logical partitions; at the same time, the allocated resource information  42  and lending key  44  are managed by the resource database  12  of the external management servers  10  to  10   i.    
      Therefore, the fields of the allocated resource information  42  and lending key  44  associated with the lendable logical partitions  2 A to  2 L are left blank; the information is stored in the resource database of external management servers  10  to  10   i  designated by management server IDs in the fields of the externally referenced information  45 .  
      While the first embodiment of the present invention makes a distinction between lendable logical partitions and non-lendable logical partitions depending on the information in the lending flags  43  stored in the logical partition database  4 , the logical partition database  4 ′ can distinguish between them more easily by the presence or absence of the information of the externally referenced information  45 .  
      On the other hand, in this embodiment, a logical partition with a blank field in the corresponding externally referenced information  45  is handled as a non-lendable logical partition; allocated resource information of a partition to be used thereby is stored in the allocated resource information  42 ; and, since the logical partition is not being lent, the field of the lending key  45  has no reference information.  
      In this case, only the contents of the allocated resource information  42  for a lendable logical partition to be lent are placed on the management server  10  to  10   i,  whereby the allocated resource information to be lent is reliably prevented from being altered without being recognized by the management servers  10  to  10   i,  enabling further improvement of the quality of lending resources.  
      In addition, it becomes possible to control the operations of a plurality of lendable logical partitions on the management servers  10  to  10   i;  and, the management servers  10  to  10   i  can alter allocated resource information stored in the lending conditions  103  to suit market trends among the client systems  20   a  to  20   m  to quickly provide lending resources tailored to market needs. The allocated resource information can be altered, for example, by adjusting the balance of CPU performance, I/O performance, and memory performance of lendable logical partitions of the plurality of the lending servers  1   a  to  1   n.    
      The relationships between the information of the logical partition database  4 ′ of the lending server  1   a  and the information stored in the resource database  12  of the management servers  10  to  10   i  will now be described with reference to  FIG. 11 .  
      In this drawing, the logical partition database  4 ′ of the lending server  1   a  stores logical partition IDs, these being the management server IDs associated with the logical partition IDs # 1  to #L, in the fields of the externally referenced information  45 , thereby indicating that these are lendable logical partitions.  
      On the other hand, the externally referenced information  45  associated with the logical partition with logical partition ID #P is left blank, indicating that this logical partition is a non-lending partition.  
      If the management server ID associated with logical partition ID # 1  indicates management server  10 , the content of the allocated resource information  42  and lending key  44  of lendable logical partition # 1  ( 2 A in  FIG. 1 ) is stored in the lending conditions  103  and lending key  104  stored in the resource database  12  of the management server  10 .  
      On the other hand, if the management server ID associated with logical partition ID #L indicates management server  10   i,  the content of the allocated resource information  42  and lending key  44  of #L lendable logical partition ( 2 L in  FIG. 1 ) is stored in the lending conditions  103  and lending key  104  stored in the resource database  12  of the management server  10   i.    
      Therefore, when the logical partition control unit  3  of the lending server  1   a  generates a lendable logical partition with ID # 1 , it references the resource database  12  of the management server  10  based on the ID of the lending server  1   a  and logical partition ID (# 1 ), and generates a lendable logical partition based on the allocated resource information stored in the lending conditions  103 .  
      Similarly, when the logical partition control unit  3  of the lending server  1   a  generates a lendable logical partition with ID # 1 , it references the resource database  12  of the management server  10   i  based on the ID of the lending server  1   a  and logical partition ID (# 1 ), and generates a lendable logical partition based on the allocated resource information stored in the lending conditions  103 .  
      That is, the right to alter the allocated resource information to be generated rests with the management servers  10  to  10   i;  and, as described above, the management servers  10  to  10   i  can alter the lending conditions stored in the resource database  12 , according to the needs of the client systems  20   a  to  20   m,  and can keep the lending resources of the plurality of lending servers ia to in always optimized, thereby enabling more flexible resource marketing.  
      Specifically, the resource database  12  of the management servers  10  to  10   i  can alter resources of the lendable logical partitions  2 A to  2 L of the lending servers  1   a  to  1   n,  in response to borrowing requests from the client system  20   a  to  20   m,  and alter information in the lending conditions  103  to meet the requirements of the client systems  20   a  to  20   m.    
      The management servers  10  to  10   i  send lending server ID  101 , logical partition ID  102 , and lending key  104  to the client systems  20   a  to  20   m;  and, at the points of time at which the client systems  20   a  to  20   m  make borrowing requests to the lending server  10  to  10   i,  the lending servers  1   a  to  1   n  search the resource database  12  to alter the allocated resources of the lendable logical partitions and then lock the lendable logical partitions and accept jobs from the client systems  20   a  to  20   m.    
      The lending server  1   a  generates a non-lendable logical partition #P for its own use based on the allocated resource information  42  stored in the logical partition database  4 ′ therein, so that the non-lendable partition #P will not be affected by alteration of the allocated resources for lendable logical partitions made by the management servers  10  to  10   i.    
      The details of resource marketing by the management server  1 G, the lending server  1   a,  and the client system  20   a  will now be described.  
      3-1b Process of Generating Lendable Logical Partitions in Lending Servers (the Second Embodiment)  
      The process of generating the lendable logical partitions  2 A to  2 L as performed in the lending server  1   a  will be described with reference to the flow diagram in  FIG. 12 .  
       FIG. 12  shows the flow of the process carried out in the lending server  1   a  from the time of the reception of borrowing requests from the client systems  20   a  to  20   m  to the time of the generation and allocation of lendable logical partitions, in which processes similar to like processes in the first embodiment are indicated by like reference characters, and the descriptions thereof will be omitted.  
      Steps S 1  and S 2  of generation of lendable logical partitions are the same as in  FIG. 5  for the first embodiment, but the operation of searching the logical partition database  4  in Step S 3 ′ differs from that of Step S 3  for the first embodiment.  
      Specifically, in Step S 3 ′, the logical partition database  4  references the allocated resource information  42  and lending status from the lending condition  103  and lending status  105  in the resource database  12  of the management server  10 , and then it responds to the logical partition control unit  3 .  
      If the lending status  105  does not include a borrower client ID, indicating that the logical partition is not in use, the logical partition control unit  3  proceeds to Step S 6 ′ to generate a lendable logical partition; while, if the lending status  105  includes a borrower client ID, indicating that the logical partition is being used, the logical partition control unit  3  notifies the lender&#39;s interface control unit that a lendable logical partition cannot be generated.  
      The operation in Step S 6 ′ differs from the first embodiment in that lendable logical partitions are generated by using allocated resource information  42  as the result of reference of the lending condition  103  of the resource database  12 .  
      The other operations are the same as in the first embodiment.  
      3-2b Process of Registering New Lendable Logical Partitions in the Management Server (the Second Embodiment)  
      Generating new lendable logical partitions includes registration thereof in the resource database  12  of the management server  10  in response to registration requests from the lending servers  1   a  to  1   n.    
      The flow of operations of registration in the resource database  12  will be described with reference to the flow diagram in  FIG. 13 .  
       FIG. 13  shows operations performed by the lending server  1   a  when registering lending resource information in the management server  10 . Operations similar to the operations shown in  FIG. 6  for the first embodiment are indicated by the same reference characters as in  FIG. 6 . The description thereof will be omitted.  
      In Step S 11 , the lender&#39;s interface control unit  5  sends lending information, such as a lendable logical partition ID, lending conditions including allocated resource information and rate information, and a lending key to the logical partition control unit  3 , and requests new lending registration of a newly provided logical partition.  
      On reception of the lending information, the logical partition control unit  3  externally references the resource database of the management server  10  via the logical partition database  4 , writes the externally referenced information  45  for registration of a new lendable logical partition into the logical partition database  4 , and on completion of the writing thereof, notifies the logical partition control unit  3  (Steps S 12 ′ and S 13 ′).  
      In Step  14 , as in Step  14  in  FIG. 6  for the first embodiment, the logical partition control unit  3  makes a registration request to the control unit  10  of the management server  10 ; and, then, the server ID, logical partition ID, lending conditions (allocated resource information  42 ), and lending key are registered in the resource database  12  (Step S 15 ′). The second embodiment differs from the first embodiment in that the information concerning the lending conditions  103 , including the allocated resource information  42  and the lending key  104 , is stored in the resource database  12 , and the logical partition database  4  of the management server  1   a  includes only referenced information thereof.  
      The other operations are the same as in the first embodiment shown in  FIG. 6 .  
      On completion of registration in the logical partition database  4 , the logical partition control unit  3  requests new registration of a lendable logical partition to the control unit  11  in the management server  10 , and sends information (lending registration information) comprising the server ID, the ID of the logical partition for new lending, lending conditions, and the lending key (Step S 14 ).  
      On reception of a registration request from the lending server la at the control unit  11 , the management server  10  sends a command to write the ID of the lending server  1   a  and the received lending registration information in the resource database  12  (Step S 15 ).  
      The resource database  12  completes the writing of new lending registration information, and notifies the control unit  11  (Step S 16 ); and, the management server  10  notifies the lending server  1   a  of the completion of new registration of the lendable logical partition (Step S 17 ).  
      On reception of the notification of the completion of registration, the lending server  1   a  requests the logical partition database  4  to set the lending flag  43  corresponding to the logical partition ID  41  of the logical partition, for which the logical partition control unit  3  made a registration request (Step S 18 ); and, the logical partition database  4  sets the lending flag  43  of the lendable logical partition of concern to “lending registered” (Step S 19 ).  
      From the point of time the lending flag  43  is set to lending registered”, the lendable logical partition is kept locked.  
      On completion of registration in the logical partition database  4 , the logical partition control unit  3  notifies the lender&#39;s interface control unit  5  of the completion of the new registration of the lendable logical partition, and terminates the operation (Step S 20 ).  
      3-3b Process of Altering the Registered Information of Lendable Logical Partitions (the Second Embodiment)  
      The lending server ia cannot alter information about lendable logical partitions to be provided by the lending server  1   a  without requesting alteration of the contents of the resource database  12  to the management server  10 .  
      The flow of operations for altering the registered contents of the lendable logical partition to be provided will be described with reference to the flow diagram in  FIG. 14 .  
      In  FIG. 14 , operations similar to like operations in  FIG. 7  for the first embodiment are indicated by like reference characters, and a description of them will be omitted.  
      In Step S 21 , the lender&#39;s interface control unit  5  sends the logical partition ID  41  and altered information about lending conditions comprising allocated resource information  42  and rate information and the lending key  44  to the logical partition control unit  3 .  
      The logical partition control unit  3  queries the logical partition database  4  about a management server ID having allocated resource information  42  associated with the logical partition ID  41  of the logical partition concerned to (Step S 122 ); and, the logical partition database  4  finds and returns the management server ID that references the allocated resource information  42  and the lending key  44  associated with the logical partition ID of the logical partition of concern (Step S 123 ).  
      The logical partition control unit  3  sends a request for alteration of the lendable logical partition to any of the management servers  10  to  10   i  having the ID of concern (Step S 22 ′).  
      Subsequently, as in  FIG. 7  of the first embodiment, the management server  10  alters the contents of the resource database  12  and, on completion of the alteration, notifies the logical partition control unit  3  that the alteration has been completed (Step S 23  to S 29 ).  
      After that, the logical partition control unit  3  of the lending server  1   a  returns the completion of alteration to the lender&#39;s interface control unit  5  and terminates the operation (Step  32 ).  
      In this case, the difference from the operations in  FIG. 7  of the first embodiment is that notification of the completion of alteration from the management server does not cause the contents of the logical partition database  4  to be updated; just the update of the resource database  12  for external reference completes the alteration of lendable logical partitions.  
      3-4b Process of Concluding a Borrowing Contract With a Client System (the Second Embodiment)  
      This process is the same as in the first embodiment, so a description thereof will be omitted.  
      3-5b Submittal of Jobs by Client Systems (the Second Embodiment)  
      The flow of operations from submittal of jobs to termination of resource borrowing that are performed by the client system  20   a,  lending server  1   a,  and management server  10  will be described with reference to the flow diagram in  FIG. 15 . In  FIG. 15 , operations similar to like operations in  FIG. 9  for the first embodiment are indicated by like reference characters, the description thereof will be omitted.  
      The client system  20   a  sends a job submittal request comprising a logical partition ID, lending key  104 , and job information to the lending server  1   a  (Step S 51 ).  
      The logical partition control unit  3  of the lending server  1   a  searches the logical partition database  4  for the received logical partition ID, based on the job submittal request from the client system  20   a,  and obtains the management server ID that manages the information about the logical partition (Step S 52 ′ and S 53 ′).  
      Next, the logical partition control unit  3  reports the lending server ID and the logical partition ID to the control unit  11  of the management server  10  and requests that the lending key  104  be stored in the resource database  12  (Step S 154  to S 156 ).  
      The control unit  11  sends the lending key  104  from the resource database  12  to the logical partition control unit  3  (Step S 157 ), which performs certification of the lending key sent from the client system  20   a  and the lending key  104  sent from the control unit  11  of the management server  10  (Step S 158 ). The subsequent operations are the same as in the first embodiment: after the certification, the client system  20   a  submits a job (application); and, on completion thereof, resource borrowing registration is deleted, whereby use of the lendable logical partition of the lending server  1   a  is terminated.  
      As described above, when a plurality of client systems  20   a  to  20   m  borrow a plurality of lendable logical partitions # 1  to #L generated in a plurality of lending servers  1   a  to  1   n,  both the lending servers and client systems can reference the management servers  10  to  10   i,  and the management servers  10  to  10   i  can alter the allocated information  42  of the lending conditions  103 , so that it is possible to adjust the balance of the lending resources to market demands, and thereby to quickly provide the borrower client systems  20   a  to  20   m  with resources that meet their borrowing requirements, enabling quick acquisition of required performance and OSs in peer-to-peer computing that shares resources among a plurality of computers.  
      In addition, the logical partition control unit  3  (logical partition control means) of a computer that lends the resources alters the logical partitions by referencing the allocated resource information  42  stored in the external resource database  12 , whereby arbitrary alteration of the lendable logical partition can be prevented in the lending servers (computers)  1   a  to  1   n,  resulting in a reliably assured processing capability (bandwidths) for borrower client systems.  
       FIG. 16  shows a third embodiment, which has a network  30  as in the first and second embodiments and comprises a file server  50  that stores a plurality of OS images  51 .  
      The lending server  1   a  to  1   n,  on establishment of given lending conditions, starts the OSs requested by the client systems  20   a  to  20   m  in the lendable logical partitions.  
      At this time, if the lending servers  1   a  to  1   n  lack the requested OSs, it opens the OS image  51  from the file server  50 , and starts the OSs through the network  30  (so-called network boot).  
      Therefore, it eliminates the need for the lending servers  1   a  to  1   n  to store the OSs to be lent to the client systems and enables the OS images  51  to be run by network booting.  
      This eliminates the need for the management server  10 , when searching for lending servers  1   a  to  1   n  on requests from the client systems  20   a  to  20   m  for allocation, to take the type of OS into consideration, making the operations from reception of borrowing requests by client systems to conclusion of borrowing contracts faster, and it becomes possible for the lending servers  1   a  to  1   n  to provide lendable logical partitions regardless of OS types, making it possible to provide client systems with more suitable resources.  
      In the first embodiment described above, the client systems  20   a  to  20   m  determine resources to borrow through the management server  10 ; and, if the network  30  is a LAN or a WAN and the lendable logical partitions are provided without charge within an organization, the client system  20   a  or other system may directly reference the logical partition database  4  of the lending servers  1   a  to  1   n,  and use available lendable logical partitions among those stored therein.  
      In this case, the client systems  20   a  to  20   m  should previously obtain the lending keys of the lending servers  1   a  to  1  n they intend to use.  
      Although the first embodiment uses a management server  10  in which the control unit  11  and resource database  12  are included, the control unit  11  and resource database  12  may be run on different computers.  
      It is to be understood that the embodiments described herein are illustrative in every point and not restrictive. The scope of the invention is defined by the appended claims rather than by the preceding description, and all variations that fall within the bounds of the claims, or are equivalent subject matter within those bounds, are therefore intended to be embraced by the claims.