Abstract:
A server apparatus includes a virtual server control unit for generating a virtual client OS for each module to be started stored in a storing device on the basis of a file start instruction; a boot control unit for loading the module to be started into a main memory and starting the module to be started; an IP address/module name conversion DB managing unit for controlling assignment of an IP address to each module to be started, registering a relation between a module name of the module and the IP address in a first table, and performing conversion between the module name and the IP address; and a routing control unit for routing a message to a module started by a different virtual client OS on the basis of an IP address of the module, the IP address being registered in the first table.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to a server apparatus having a function of loading a new file into a main memory and changing over from an old module to a new module. 
     2. Description of the Related Art 
     A server or the like changes over from an old file to a new file for an upgrade, addition of a new module, or the like.  FIGS. 11 to 17  are diagrams representing a conventional method of changing over to a new file. As shown in  FIGS. 11 to 17 , servers  2 # 0  and  2 # 1  have a duplexed configuration to replace files. The server  2 # 0  is an operational system and the server  2 # 1  is a standby system, for example. In the server  2 #i, a plurality of applications (modules)  16 #iA 00 ,  16 #iB 10 ,  16 #iC 30 , . . . operate on a basic Operating System (OS)  4 #i. Messages are communicated between the applications  16 #iA 00 . . . and another node  3  via the basic OS  4 #i. A conventional file update method is as follows. 
     In response to each new operation instruction, a message event is notified in a form of a maintenance command to the server  2 #i (i=0, 1), and operation is performed by software of the server  2 #i (i=0, 1) receiving the notification. In this case, suppose that the applications B 10  and C 30  are files to be updated to applications B 80  and C 90 . 
     (1) Loading of New File 
     As shown in  FIG. 11 , new system files for an upgrade, for example application programs B 80  and C 90  for providing service are transferred from an external medium such as a Digital Audio Tape (DAT) or the like or a remote terminal onto disk devices  10 #i (i=0, 1) of all the servers  2 #i (i=0, 1) that are to update files, so that new files  12 #i are created. 
     (2) Setting of File Update State 
     In order to regulate processing that may interfere with update operation, a system state retained on the software is changed from “normal” to “file update.” 
     (3) Booting of New File 
     As shown in  FIG. 12 , the standby server  2 # 1  is separated from the duplexed state, and stopped. A reboot program  14 # 1  is executed to load the new files into a memory. After the reboot, the application programs B 80  and C 90  stored as the new files  12 # 1  and a necessary application program A 00  that is not to be updated are LM-loaded from the disk  10 # 1  onto the memory, whereby processes  16 # 1 B 80 ,  16 # 1 C 90 , and  16 # 1 A 00  are generated. The server  2 # 1  is brought into a standby state. As shown in  FIG. 13 , the server  2 # 1  starts operation of the processes  16 # 1 A 00 ,  16 # 1 B 80 , and  16 # 1 C 90 , and is brought into a temporary operational state. 
     (4) Change to New File 
     As shown in  FIG. 14 , in order to change from the old files to the new files, the standby server  2 # 1  is set as an operational server, and the operational server  2 # 0  is set as a standby server and is stopped. 
     (5) Establishment of New File 
     As shown in  FIG. 15 , to ensure operation of the new file  4 # 1  of the server  2 # 1 , the system state is monitored for a certain time. Thereafter, in order to change the old file environment of the server  2 # 0  to a new file environment, the server  2 # 0  is rebooted by a reboot program  14 # 0 . After the reboot, the application programs B 80  and C 90  stored as the new files  12 # 0  and the necessary application program A 00  that is not to be updated are LM-loaded from the disk  10 # 0  onto a memory, whereby processes  16 # 0 B 80 ,  16 # 0 C 90 , and  16 # 0 A 00  are generated. As shown in  FIG. 16 , the server  2 # 0  starts operation of the processes  16 # 0 B 80 ,  16 # 0 C 90 , and  16 # 0 A 00  and is brought into a temporary operational state. As shown in  FIG. 17 , after the operation of the server  2 # 0  is monitored for a certain time, the server  2 # 0  is brought into a standby state. 
     Prior art literature includes the following Patent Literature 1. 
     Patent Literature 1 discloses a technique for changing over from an active server to a reserve server without changing setting in a client computer. 
     Patent Literature 1
         Japanese Patent Laid-Open No. Hei 10-23074       

     However, the conventional file update method has the following problems. 
     (1) When of the plurality of application load modules A 00 , B 10 , and C 30 , the module A 00  is not changed and the modules B 10  and C 30  are changed to add service functions (B 10  is changed to B 80 , and C 30  is changed to C 90 ), because a new LM is also created for the module (A 00 ) not capturing the IF and modules are loaded after a reboot, replacement of the files including the old module (A 00 ) needs to be performed. That is, even when only the modules B 80  and C 90  are necessary, all the modules to be substituted including not only the necessary modules B 80  and C 90  but also the unnecessary module A 00  need to be loaded. 
     (2) As a condition for performing a file update, the duplexed server configuration is essential. This presents a problem in that investment cost and maintenance cost are increased because of the duplexed configuration. 
     (3) Changeover from an old file to a new file involves switchover between the servers of the duplexed configuration, thus causing a service interruption time. Also, there is a risk of not being able to change to the new file because of hardware abnormality. 
     Patent Literature 1 only discloses changeover between an active server and a reserve server in a duplexed configuration and is therefore not able to solve the above problem in the duplexed configuration. 
     SUMMARY OF THE INVENTION 
     It is accordingly an object of the present invention to provide a server apparatus that can continue service as it is without file replacement of a module not changed between a new and an old file, perform file replacement of only a module for adding new service, and perform a file update without involving processor changeover. 
     In accordance with an aspect of the present invention, there is provided a server apparatus having a function of loading a new module stored in a storing device into a main memory and changing over from an old module to the new module. The server apparatus includes a virtual server control unit disposed in a virtual server OS, for generating a virtual client OS for each module to be started stored in the storing device on the basis of a file start instruction; a boot control unit disposed in the virtual client OS, for loading the module to be started into the main memory and starting the module to be started; an identifier/module name conversion database (DB) managing unit disposed in the virtual server OS, for controlling assignment of an identifier to each module to be started, registering a relation between a module name of the module and the identifier in a first table, and performing conversion between the module name and the identifier; a routing control unit disposed in the virtual server OS, for routing a message to a module started by a different virtual client OS on the basis of an identifier of the module, the identifier being registered in the first table; and a file update control unit disposed in the virtual server OS, for requesting the routing control unit to stop communication to an old module of a module name identical with the module name of the module to be started and instructing the routing control unit to save a message to the old module and sweep out the message to the new module, on the basis of a file change instruction. 
     Preferably, the server apparatus further includes a communication control unit disposed in the virtual client OS, for adding to a message to a module started by another client OS an identifier of the module and sending the message to the routing control unit, and controlling reception of a message to a corresponding module on the basis of an identifier added to the message received from the routing control unit. 
     Further, preferably, the file update control unit instructs the identifier/module name conversion DB managing unit to change from an old identifier to a new identifier for a message to the module of the module name identical with the module name of the started module on the basis of an instruction to change to a new file, the identifier/module name conversion DB managing unit notifies all client OSes of the new identifier of the module, and the client OSes transmit a message to the module to the new module. 
     The above and other objects, features and advantages of the present invention and the manner of realizing them will become more apparent, and the invention itself will best be understood from a study of the following description and appended claims with reference to the attached drawings showing some preferred embodiments of the invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a diagram of assistance in explaining principles of the present invention; 
         FIG. 2  is a diagram of configuration of a server apparatus according to an embodiment of the present invention; 
         FIG. 3  is a diagram of structure of an Internet Protocol (IP) address/module name conversion DB in  FIG. 2 : 
         FIG. 4  is a diagram of inter-process communication; 
         FIG. 5  is a diagram of transfer of new files; 
         FIG. 6  is a diagram of starting of the new files; 
         FIG. 7  is a diagram of starting of the new files; 
         FIG. 8  is a diagram of change to the new files; 
         FIG. 9  is a diagram of change to the new files; 
         FIG. 10  is a diagram of establishment of the new files; 
         FIG. 11  is a diagram of conventional loading of new files; 
         FIG. 12  is a diagram of conventional booting of the new files; 
         FIG. 13  is a diagram of conventional booting of the new files; 
         FIG. 14  is a diagram of conventional change to the new files; 
         FIG. 15  is a diagram of conventional establishment of the new files; 
         FIG. 16  is a diagram of conventional establishment of the new files; and 
         FIG. 17  is a diagram of conventional establishment of the new files. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Principles of the present invention will be described prior to description of an embodiment of the present invention.  FIG. 1  is a diagram of assistance in explaining principles of the present invention. As shown in  FIG. 1 , a server apparatus  30  has a virtual server OS  32  loaded and operated on a main memory  31 . The virtual server OS  32  includes a virtual server control unit  40 , an IP address/module name conversion DB managing unit  42 , and a routing control unit  44 . The virtual server control unit  40  generates a virtual client OS  34 #i for modules to be started  36   a ,  36   b , . . . stored in a storing device  34  on the basis of a file start instruction. The virtual client OS  34 #i includes a boot control unit  50 #i. The boot control unit  50 #i loads the modules to be started  36   a , . . . on the main memory  31  and starts processes  60 #ia, . . . . Thus, client OSes  34 #i (i=1, . . . ) are generated on the main memory  31  on the basis of file start instructions. 
     On the basis of a module name converted by the IP address/module name conversion DB managing unit  42  from a destination IP address set in a message from the process  60 #ia started by the client OS  34 #i to the process  60 #jb started by another client OS  34 #j (j≠i), the routing control unit  44  routes the message to the client OS  34 #j where the module is generated. The client OS  34 #j sends the message to the module on the basis of the destination IP address, whereby inter-process communication is performed and each of the processes  60 #ia. . . Operates. Suppose that a new module  60 # 2   a  is an upgraded version of an old module  60 # 1   a  and that a new module  60 # 2   b  is an additional module. 
     On the basis of a file change instruction, a file update control unit  46  requests the routing control unit  44  to stop communication to the old module  60 # 1   a  of a module name identical with that of the module  60 # 2   a  to be started and instructs the routing control unit  44  to save messages to the old module  60 # 1   a  and sweep out the messages to the new module  60 # 2   a . According to the instruction from the file update control unit  46 , the routing control unit  44  saves messages to the old module  60 # 1   a  and then sweeps out the messages to the new module  60 # 2   a . Thus, since the messages to the old module  60 # 1   a  are delivered to the new module  60 # 2   a , the new module  60 # 2   a  can be continued without stopping operation of the old module  60 # 1   a.    
       FIG. 2  is a diagram of configuration of a server according to an embodiment of the present invention. As shown in  FIG. 2 , the server includes a main unit apparatus  100  and peripheral devices such as a disk device  102  and the like. The main unit apparatus includes a Control Processing Unit (CPU), a main memory, a Read Only Memory (ROM), and the like. A basic OS  120  and a virtual server OS  122  are loaded on the main memory and are executed by the CPU. A virtual host  124 #i (i=A, B, . . .) Is generated for each application group, which operates on the server, to be started. The application group to be started refers to one or a plurality of application modules specified by a maintenance server  114  as modules to be started at a time of a start of a file. The basic OS  120  is an operating system for performing process management, file management, window control, and the like. The server  100  is connected with a Dynamic Host Configuration Protocol (DHCP) server  110  as well as the maintenance server  114  and another node  116  via a communication device such as a HUB/router  112  or the like. The virtual server OS  122  includes a virtual server control unit  130 , a routing control unit  132 , an IP address/module name conversion DB managing unit  134 , a file update control unit  136 , and a message buffer managing unit  138 . The virtual server control unit  130  and the like are program modules. 
     The virtual server control unit  130  has the following functions. (i) When receiving a message to “start a new file” from the file update control unit  136 , the virtual server control unit  130  constructs an environment of a new virtual host  124 #i to start a module included in the new file. Specifically, the virtual server control unit  130  loads and starts a module including functional blocks such as a BOOT control unit  150 #i, an IP address/module name conversion control unit  152 #i, a server message transmission control unit  154 #i, and the like constituting a virtual client OS  140 #i. The virtual server control unit  130  further copies an IP address/module name conversion DB  135  and thereby generates an IP address/module name conversion table  153 #i. (ii) The virtual server control unit  130  notifies the virtual client OS  140 #i of the name of the module to be started included in the new file. (iii) When receiving a response to “start the new file” from the virtual client OS  140 #i, the virtual server control unit  130  notifies the file update control unit  136  of the response. (iv) When receiving a request to delete an IP address of an old module from the file update control unit  136 , the virtual server control unit  130  deletes a process of the old module. Also, the virtual server control unit  130  determines whether only one old module is present within the virtual host, and when only one old module is present within the virtual host, the virtual server control unit  130  deletes the virtual host. 
     The routing control unit  132  has the following functions. (i) When receiving a message from a virtual host  124 #i, the routing control unit  132  extracts a destination IP address in an IP header of the message, inquires of the IP address/module name conversion DB managing unit  134  about a module corresponding to the IP address, and then sends the message to a virtual host corresponding to the module. (ii) When receiving a request to inhibit communication to an IP address of an old module from the file update control unit  136 , the routing control unit  132  saves messages to the IP address to the message buffer managing unit  138 . (iii) When receiving a notification of “sweep out the messages” from the file update control unit  136 , the routing control unit  132  reads the messages saved to the message buffer managing unit  138  and requests the IP address/module name conversion DB managing unit  134  to convert from the old IP address to a new IP address. Receiving a new IP address from the IP address/module name conversion DB managing unit  134 , the routing control unit  132  updates the destination address in IP headers of the read messages to the new IP address. The routing control unit  132  outputs the messages to a virtual host corresponding to the IP address. 
     The IP address/module name conversion DB managing unit  134  has the following functions. (i) When receiving a destination IP address from the routing control unit  132 , the managing unit  134  converts the IP address to a module name and then notifies the routing control unit  132  of the module name. (ii) When receiving a request to give an IP address to a module to be started from a virtual client OS, the managing unit  134  requests the DHCP server  110  to dispense an IP address. On the basis of the dispensed IP address, the managing unit  134  stores the IP address, a name of the module to be started, and a state “new” in the IP address/module name conversion DB  135 . The managing unit  134  notifies the requesting virtual client OS of a correspondence between the dispensed IP address and the name of the module to be started. (iii) When receiving a “notification to change an IP address” from the file update control unit  136 , the managing unit  134  notifies all virtual hosts to transmit messages to the new IP address rather than an old IP address regarding a module of the module name identical with that of the module to be started. (iv) When receiving a notification of “establish the new IP address” from the file update control unit  136 , the managing unit  134  changes the state of the new IP address in the IP address/module name conversion DB  135  from “new” to “current.” The managing unit  134  deletes old IP address/module name correspondence data from the IP address/module name conversion DB  135 . The managing unit  134  returns a response to the file update control unit  136 . 
       FIG. 3  is a diagram of structure of the IP address/module name conversion DB  135  in  FIG. 2 . As shown in  FIG. 3 , the IP address/module name conversion DB  135  includes IP address, module name, and state fields. The IP address is an IP address of a module of a corresponding module name. The state is a state of a corresponding module and is “new”/“current.” “Current” indicates that the module is currently operational. “New” indicates a state during a period from a “start of a new file” to “establishment of the new file.” If a defective condition occurs in the started module during this period, the started module is stopped and deleted to return to a state before the start of the started module. 
     The file update control unit  136  has the following functions. (i) When receiving a message to “start a new file” from the maintenance server  114 , the file update control unit  136  refers to the new file (module to be started) stored in the disk device  102  and notifies the virtual server control unit  130  of the module to be started. (ii) When receiving a response to the start of the “new file” from the virtual server control unit  130 , the file update control unit  136  returns a response to the maintenance server  114 . (iii) When receiving a message to “change to the new file” from the maintenance server  114 , the file update control unit  136  refers to the new file (module to be started) stored in the disk device  102  and requests the IP address/module name conversion DB managing unit  134  to convert from an old module name to an old IP address of a module with a module name identical with that of the module to be started. The file update control unit  136  makes a “request to inhibit communication due to file replacement” of messages to the converted IP address to the routing control unit  132 . The file update control unit  136  makes a “request to stop communication due to file replacement” to a virtual client OS of the old module of the IP address. (iv) The file update control unit  136  provides an “IP address change notification” regarding the old IP address to the IP address/module name conversion DB managing unit  134 . (v) When receiving a response from the IP address/module name conversion DB managing unit  134 , the file update control unit  136  provides a “notification of sweep out messages” to the routing control unit  132 . When receiving a response from the routing control unit  132 , the file update control unit  136  returns a response to the message to “change to the new file” to the maintenance server  114 . (vi) When receiving a notification of a message to “establish the new file” from the maintenance server  114 , the file update control unit  136  notifies the IP address/module name conversion DB managing unit  134  of “establish the new IP address”. When receiving a response from the IP address/module name conversion DB managing unit  134 , the file update control unit  136  requests the virtual server control unit  130  to “delete” the IP address of the old module. (vii) When receiving a response from the virtual server control unit  130 , the file update control unit  136  returns a response to the message to “establish the new file” to the maintenance server  114 . 
     The message buffer managing unit  138  has the following functions. (i) When receiving a message from the routing control unit  132 , the message buffer managing unit  138  stores the message in a buffer. (ii) When receiving a request to read the message from the routing control unit  132 , the message buffer managing unit  138  reads the message stored in the buffer. 
     A virtual client OS  140 #i includes a BOOT control unit  150 #i, an IP address/module name conversion control unit  152 #i, a server message transmission control unit  154 #i, a server message reception control unit  156 #i, and an IP communication control unit  158 #i. 
     The BOOT control unit  150 #i has the following functions. (i) According to a notification from the virtual server OS  122 , the BOOT control unit  150 #i reads a module to be started from the disk device  102  and loads the module to be started into a space within the virtual host  124 #i. (ii) The BOOT control unit  150 #i notifies the IP address/module name conversion control unit  152 #i of a name of the loaded module to be started. After completion of the operations (i) and (ii), the BOOT control unit  150 #i returns a response to the file update control unit  136  via the virtual server control unit  130 . 
     The IP address/module name conversion control unit  152 #i has the following functions. (i) When receiving a notification of a module to be started from the BOOT control unit  150 #i, the IP address/module name conversion control unit  152 #i notifies the IP address/module name conversion DB managing unit  134  of a name of the module to be started. The module to be started is an additional module, an upgraded module, or the like. When a module of the same name is present in another virtual host, there may be no module of the same name such as an additional module in another virtual host. When there is already such a module, a new IP address is given to change communication to the module. When there is no such module, an IP address is given to a new additional module. (ii) When receiving IP address/module name correspondence data from the IP address/module name conversion DB managing unit  134 , the IP address/module name conversion control unit  152 #i stores the data in the IP address/module name conversion table  153 #i. (iii) When receiving an instruction for an update to a new IP address from the IP address/module name conversion DB managing unit  134 , the IP address/module name conversion control unit  152 #i deletes old module name/old IP address correspondence data of a module identical with a module corresponding to the new IP address so that communication is performed to the new module of the new IP address. 
     The IP address/module name conversion table  153 #i is substantially the same as the IP address/module name conversion DB  135  shown in  FIG. 3 . The server message transmission control unit  154 #i has the following functions. (i) When receiving a name of a destination module and a message from a module, the server message transmission control unit  154 #i inquires of the IP address/module name conversion control unit  152 #i about whether the destination module is present within the virtual host  124 #i to which the server message transmission control unit  154 #i belongs. (ii) When the destination module is present within the virtual host  124 #i, the server message transmission control unit  154 #i sends the data packet to the module within the virtual host. (iii) When the destination module is not present within the virtual host  124 #i, the server message transmission control unit  154 #i sends the data packet to the IP communication control unit  158 #i. 
     The IP communication control unit  158 #i has the following functions. (i) When receiving a name of a destination module and a message from the server message transmission control unit  154 #i, the IP communication control unit  158 #i inquires of the IP address/module name conversion control unit  152 #i about an IP address corresponding to the name of the destination module. The IP communication control unit  158 #i adds the destination IP address to the message and then transmits the message to the routing control unit  132 . (ii) When receiving a message from the routing control unit  132 , the IP communication control unit  158 #i inquires of the IP address/module name conversion control unit  152 #i about a name of a destination module corresponding to a destination IP address in the message. The IP communication control unit  158 #i sends the name of the destination module and the message to the server message reception control unit  156 #i. 
     The server message reception control unit  156 #i has the following functions. When receiving the name of the destination module and the message from the IP communication control unit  158 #i, the server message reception control unit  156 #i notifies the destination module of the message receiving event and sends the data packet to the destination module. Each module within the virtual host  124 #i operates as a process under control of the above-described virtual client OS  140 #i in communication with the basic OS  120  and other modules. 
     The DHCP server  110  dynamically assigns an IP address to a module according to a request to give an IP address. The HUB/router  112  routes a message at a data link layer or IP layer level. The maintenance server  114  transfers a new file to the server, transmits messages to “start the new file,” “change to the new file,” and “establish the new file” to the server, and receives responses to these messages from the server. 
     Operations of  FIG. 2  will be described in the following. 
     (1) Inter-Process Communication 
       FIG. 4  is a diagram showing inter-process communication. Suppose that as shown in  FIG. 4 , virtual hosts  124 #A and  124 #B are started by a new file start method to be described later. Description will be made by taking as an example a case of communication from a process  180 #A 00  in the virtual host  124 #A to a process  180 #B 00  in the virtual host  124 #B. As indicated by ( 10 ), the process  180 #A 00  outputs a destination module name B 00  and a message to a server message transmission control unit  154 #A. As indicated by ( 12 ), the server message transmission control unit  154 #A inquires of an IP address/module name conversion control unit  152 #A about whether the module B 00  is present within the virtual host  124 #A. The IP address/module name conversion control unit  152 #A searches an IP address/module name conversion table  153 #A and then notifies the server message transmission control unit  154 #A that the module B 00  is not present within the virtual host  124 #A. As indicated by ( 14 ), the server message transmission control unit  154 #A outputs the module name B 00  and the message to an IP communication control unit  158 #A. As indicated by ( 16 ), the IP communication control unit  158 #A inquires of the IP address/module name conversion control unit  152 #A about an IP address of the module name B 00 . The IP address/module name conversion control unit  152 #A notifies the IP communication control unit  158 #A of the IP address 10. 22. 34. 10 of the module name B 00 . The IP communication control unit  158 #A adds the IP address 10. 22. 34. 10 to the message and then sends the message to the routing control unit  132 , as indicated by ( 18 ). 
     As indicated by ( 20 ), the routing control unit  132  inquires of the IP address/module name conversion DB managing unit  134  about a virtual host where the module B 00  of the IP address 10. 22. 34. 10 is present. The IP address/module name conversion DB managing unit  134  notifies the routing control unit  132  that the module B 00  of the IP address 10. 22. 34. 10 is controlled by a virtual client OS  140 #B. As indicated by ( 22 ), the routing control unit  132  sends the IP packet with the destination IP address 10. 22. 34. 10 to an IP communication control unit  158 #B of the virtual client OS  140 #B. As indicated by ( 24 ), the IP communication control unit  158 #B inquires of an IP address/module name conversion control unit  152 #B about the module name of the IP address 10. 22. 34. 10. The IP address/module name conversion control unit  152 #B notifies the IP communication control unit  158 #B that the module name is B 00 . As indicated by ( 26 ), the IP communication control unit  158 #B sends the module name B 00  and the message to a server message reception control unit  156 #B. As indicated by ( 28 ), the server message reception control unit  156 #B sends the message to the module  180 #B 00 . 
     (2) Transfer of New File 
       FIG. 5  is a diagram showing transfer of a new file. In this case, suppose that virtual hosts  124 #B 20 ,  124 #A 00 , and  124 #B 10  are started by a new file start to be described later, and that data such as IP address 10.20.30.30/module A 00 /“current” and the like is registered in the IP address/module name conversion DB  135 . As indicated by ( 100 ), the maintenance server  114  transfers new files, for example B 00  and B 10  to a new file storing area on the disk device  102  of the server  100  via the HUB/router  112 . 
     (3) Starting of New Files 
       FIG. 6  and  FIG. 7  are diagrams showing starting of new files. In this case, suppose that virtual hosts  124 #A 00 ,  124 #B 10 , and  124 #B 20  for modules  180 #A 00 ,  180 #B 10 , and  180 #B 20  are already started, and that the modules to be started B 00  and B 10  stored on the disk device  102  will be started. Suppose that the module to be started B 00  is an additional module and that the module B 10  is an upgraded version of the module  180 #B 10 . 
     As indicated by ( 200 ), the maintenance server  114  notifies the file update control unit  136  of a “new file starting” message for the new files B 00  and B 10 . As indicated by ( 202 ), the file update control unit  136  notifies the virtual server control unit  130  of the modules to be started B 00  and B 10  stored on the disk device  102 . As indicated by ( 204 ), the virtual server control unit  130  constructs an environment of a virtual host  124 #B′. 
     As indicated by ( 206 ), the virtual server control unit  130  notifies a BOOT control unit  150 #B′ of the modules to be started (B 00  and B 10 ). The BOOT control unit  150 #B′ reads the new modules to be started B 00  and B 10  from the disk device  102 , loads the new modules to be started B 00  and B 10  into a space within the virtual host  124 #B′, and generates processes  180 #B′ 00  and  180 #B′ 10 , as indicated by ( 250 ) in  FIG. 7 . 
     As indicated by ( 252 ), the BOOT control unit  150 #B′ notifies an IP address/module name conversion control unit  152 #B′ of the started modules B 00  and B 10 . As indicated by ( 254 ), the IP address/module name conversion control unit  152 #B′ makes a request to give an IP address to the started modules B 00  and B 10  to the IP address/module name conversion DB managing unit  134 . As indicated by ( 256 ), the IP address/module name conversion DB managing unit  134  requests the DHCP server  110  to dispense an IP address to the started modules B 00  and B 10 . The DHCP server  110  notifies the IP address/module name conversion DB managing unit  134  of IP addresses 10.20.30.60 and 10.20.30.70 of the started modules B 00  and B 10 . As indicated by ( 258 ), the IP address/module name conversion DB managing unit  134  registers started modules B 00  and B 10 /IP addresses 10.20.30.60 and 10.20.30.70/“new” and “new” in the IP address/module name conversion DB  135 . 
     As indicated by ( 260 ), the IP address/module name conversion DB managing unit  134  notifies the IP address/module name conversion control unit  152 #B′ of started modules B 00  and B 10 /IP addresses 10.20.30.60 and 10.20.30.70/“new” and “new”. The IP address/module name conversion control unit  152 #B′ registers started modules B 00  and B 10 /IP addresses 10.20.30.60 and 10.20.30.70/“new” and “new” in an IP address/module name conversion table  153 #B′. As indicated by ( 262 ), the BOOT control unit  150 #B′ returns a response to the file update control unit  136  via the virtual server control unit  130 . As indicated by ( 264 ), the file update control unit  136  returns a response to “new file starting” to the maintenance server  114 . 
     (4) Change to New Files 
       FIG. 8  and  FIG. 9  are diagrams showing change to the new files. As indicated by ( 300 ) in  FIG. 8 , the maintenance server  114  notifies the file update control unit  136  of a message to “change to the new files”. The file update control unit  136  refers to the disk device  102  and inquires of the IP address/module name conversion DB managing unit  134  about the IP address of the already started module B 10  as a module of the identical name with that of the module to be started B 00  or B 10 . As indicated by ( 304 ), the IP address/module name conversion DB managing unit  134  refers to the IP address/module name conversion DB  135 , and then notifies the file update control unit  136  of the IP address 10.20.30.55 of the module name B 10 . 
     As indicated by ( 306 ), the file update control unit  136  requests the routing control unit  132  to inhibit communication regarding the IP address 10.20.30.55. As indicated by ( 308 ), the file update control unit  136  requests the process  180 #B 10  corresponding to the IP address 10.20.30.55 to stop operation due to file change. 
     As indicated by ( 310 ), the routing control unit  132  saves messages having the IP address 10.20.30.55 as destination to the message buffer managing unit  138 . The process  180 #B 10  stops operation. As indicated by ( 312 ), the file update control unit  136  notifies the IP address/module name conversion DB managing unit  134  of change of IP addresses of the started modules B 00  and B 10 . The IP address/module name conversion DB managing unit  134  notifies all virtual client OSes  140 #i (i=B, A 00  . . . ) of the IP addresses 10.20.30.60 and 10.20.30.70 of the started modules B 00  and B 10  and gives an instruction to update the module B 10  of the identical module name with that of the started module to the new IP address 10.20.30.70 to all virtual client OSes  140 #i (i=B, A 00  . . . ). The virtual client OS  140 #i registers IP addresses 10.20.30.60 and 10.20.30.70/started modules B 00  and B 10  correspondence data and performs an update to the new IP address 10.20.30.70 by deleting IP address/module name correspondence data of the old module B 10 . A response is returned to the file update control unit  136 . 
     As indicated by ( 350 ) in  FIG. 9 , the file update control unit  136  notifies the routing control unit  132  of “weep out messages.” As indicated by ( 352 ), the routing control unit  132  reads IP packets saved to the message buffer managing unit  138 . As indicated by ( 354 ), the routing control unit  132  makes an IP address conversion request to the IP address/module name conversion DB managing unit  134  to have the IP address/module name conversion DB managing unit  134  dispense the new IP address 10.20.30.70 of the destination IP address of the IP packets. As indicated by ( 356 ), the routing control unit  132  sets the new IP address in the messages and sends the messages to an IP communication control unit  158 #B′ within an virtual client OS  140 #B′ for the started module B 10  of the new IP address 10.20.30.70. 
     The IP communication control unit  158 #B′ inquires of the IP address/module name conversion control unit  152 #B′ about the module name corresponding to the destination IP address 10.20.30.70 of the messages. The IP address/module name conversion control unit  152 #B′ notifies of the module name B 10  corresponding to the IP address 10.20.30.70. The IP communication control unit  158 #B′ sends the module name B 10  and the messages to a server message reception control unit  156 #B′. The server message reception control unit  156 #B′ sends the messages to the process  180 #B′ 10 . 
     When completing processing indicated by ( 352 ) and ( 356 ) on all the messages saved to the message buffer managing unit  138 , the routing control unit  132  returns a response to the file update control unit  136 . As indicated by ( 358 ), the file update control unit  136  returns a response to the message to “change to the new files” to the maintenance server  114 . 
     (5) Establishment of New Files 
       FIG. 10  is a diagram showing establishment of the new files. As indicated by ( 400 ), the maintenance server  114  notifies the file update control unit  136  of a message to “establish the new files”. As indicated by ( 402 ), the file update control unit  136  notifies the IP address/module name conversion DB managing unit  134  of “establish the IP addresses.” As indicated by ( 404 ), the IP address/module name conversion DB managing unit  134  changes IP address/module name correspondence data in the state of “new” in the IP address/module name conversion DB  135  to “current” and deletes IP address/module name correspondence data (B 10 /10.20.30.55) in the state of “current” corresponding to the same module name as a module name of the changed IP address/module name correspondence data. The IP address/module name conversion DB managing unit  134  returns the IP address of the deleted data to the DHCP server  110  and returns a response to the file update control unit  136 . 
     As indicated by ( 406 ), the file update control unit  136  requests the virtual server control unit  130  to delete the old module B 10  of the IP address 10.20.30.55. As indicated by ( 408 ), the virtual server control unit  130  deletes the module of the IP address 10.20.30.55. Also, the virtual server control unit  130  determines whether there is only one module within the virtual host, and when there is only one module within the virtual host, the virtual server control unit  130  deletes the virtual host environment. In this case, since only the module B 10  is present within the virtual host  124 #B 10  of the old module B 10 , the virtual host  124 #B 10  is deleted. As indicated by ( 410 ), the virtual server control unit  130  returns a response to the file update control unit  136 . As indicated by ( 412 ), the file update control unit  136  returns a response to the message to “establish the new files” to the maintenance server  114 . Thus, the module B 10  is changed to the new module, and the module B 00  is added. It is thus possible to load and start only modules to be started. 
     If a defective condition occurs in the started module of a new file before establishment of the new file so that service cannot be continued normally, the maintenance server  114  notifies the file update control unit  136  of a message to “restore a file”. The file update control unit  136  notifies the IP address/module name conversion DB managing unit  134  to restore the file. The IP address/module name conversion DB managing unit  134  notifies all virtual hosts  124 #i to make an update to an old IP address of the module of an identical module name with that of the new module, gives an instruction to resume operation to the old module, and deletes data in the state of “new” from the IP address/module name conversion DB  135 . The file update control unit  136  instructs the virtual server control unit  130  to delete a virtual host of the started module. The virtual server control unit  130  deletes the virtual host. In this case, the routing control unit  132  saves messages to the new module to the message buffer managing unit  138 , reads the messages from the message buffer managing unit  138 , and then transmits the messages to the old module. Thereby the old module resumes operation. 
     As described above, according to the present invention, it is possible to replace only a module changed between a new and an old file, and minimize effects on replacement operation. Further, the present invention enables file replacement without involving processor changeover. It is therefore possible to realize file updates in a server environment of a single configuration without requiring a duplexed configuration, and thus reduce cost of hardware and software, reduce maintenance cost, and prevent service interruption or occurrence of defective conditions due to changeover. 
     The present invention is not limited to the details of the above described preferred embodiments. The scope of the invention is defined by the appended claims and all changes and modifications as fall within the equivalence of the scope of the claims are therefore to be embraced by the invention.