JP2006178552A - Virtual computer system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent the reduction in reliability of a virtual computer using a software emulation system, compared with a conventional computer using exclusive hardware. <P>SOLUTION: In the virtual computer using a software emulation system, an active emulation program and a standby emulation program are arranged on a single OS to carry over processing to a standby system in the event of failure of the active system. The standby emulation program which took over the processing becomes active, and automatically generates the standby emulation program. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a virtual machine system, and more particularly to a method for implementing emulation software for a virtual machine system.

  Conventionally, in the field of mainframes and the like that require reliability and speed, dedicated hardware developed according to the application has been used. However, in recent years, the performance of general-purpose computers has become higher, and the reliability has also increased due to improvements in manufacturing technology. Therefore, opportunities for using general-purpose computers in this field have increased.

  When a new system based on a general-purpose computer is constructed, software / hardware assets normally owned by users cannot be effectively used as they are. Therefore, a method has been used in which a virtual system equivalent to a conventional system using software emulation technology is mounted on a general-purpose computer by software, and customer assets are effectively used on the latest hardware.

  FIG. 1 shows an example of a computer configuration using dedicated hardware. FIG. 2 shows an example of a computer configuration using a software emulation method. In FIG. 1 using dedicated hardware, it is composed of dedicated hardware (14), firmware (13), host operation system (hereinafter referred to as host OS) (12), and user program (11). On the other hand, in FIG. 2 using the software emulation method, the general-purpose hardware (26) and the firmware (25), the host OS (24), the emulation program (23), which are in the hierarchy above the general-purpose hardware, It has a guest OS (22) and a user program (21). In FIG. 2 using the software emulation method, the guest OS (22) corresponds to the host OS (12) of FIG. 1 using dedicated hardware, and the host OS (24) and the emulation program (23) are added. Takes the form.

  FIG. 3 shows an example of an emulation program in a configuration using a software emulation method. Each module takes a form simulating a configuration using dedicated hardware. An IP (instruction execution processor) (231) that executes instructions, an SVP (service processor) (232) that performs system monitoring, and general I / O processing An IOP (I / O processor) (234) for controlling and an IOC (I / O control processor) (235) for controlling I / O devices are included. Further, a virtual register area (2351) and a virtual memory area (2352) are arranged in the heap memory (236) secured by the emulation program. The program of the guest OS (22) is loaded into the virtual main memory (2352), and the IP (231) receives these instructions via the IOP (234). The IP (231) converts the received instruction into a format compatible with the host OS and general-purpose hardware, executes arithmetic processing, and writes the arithmetic result into the virtual register (2351) and the virtual main memory (2352). With these processes, the guest OS realizes a function equivalent to conventional dedicated hardware without being aware of the execution environment.

  A method for improving the reliability by making the system hardware redundant is described in JP-A-10-240556.

Japanese Patent Laid-Open No. 10-240556

  In a virtual computer system combining a general-purpose computer / general-purpose OS and software emulation, the software emulation / general-purpose OS is interposed between the general-purpose hardware and the computer system using the dedicated hardware. I will lower it. In order to improve reliability by system redundancy, an additional system is required, which greatly affects the introduction cost of the user.

  An object of the present invention is to improve reliability with a single hardware and a single OS.

  In the present invention, a normal active software emulation program and a standby emulation program are arranged on one OS. Depending on the superiority or inferiority of each attribute, the active system or standby system is selected. These emulation programs monitor each other's status, and immediately take over the processing to the standby emulation program when an abnormality is detected. The standby system emulation program changes the attribute at that time to become the active system emulation program, and when it takes over the activation, generates a standby system emulation program for its own program. The emulation target OS is placed in the shared memory area, and the processing can be continued by acquiring the execution start address when switching to the standby system.

  By applying to a virtual computer using the software emulation method, when a failure occurs in the active emulation program, it is possible to take over the processing to the standby emulation program, and further avoid a system down. Further, it is possible to improve the reliability in a virtual machine using a software emulation method.

  Hereinafter, an embodiment of the present invention will be specifically described with reference to the drawings.

  FIG. 4 is a system configuration diagram showing an embodiment of the present invention. It comprises general-purpose hardware (37), firmware (36), host OS (35), emulation program A (33), emulation program B (34), guest OS (32), and user software (31). Compared with FIG. 2 which has been described as the prior art, it is characterized in that two emulation programs are arranged.

  These two emulation programs will be described with reference to FIG.

  The emulation layer used in this embodiment has an emulation program A (33), an emulation program B (34), and a host OS shared heap memory (39). The two emulation programs are executed in separate processes, and an emulation program B (34) is generated from the emulation program A (33). As a difference from the conventional system, a process synchronization control unit SNC (335) (345) is provided. The SNCs mutually monitor the emulation program and generate an operation takeover process and a backup program when the emulation program is abnormal. Further, the virtual main memory and virtual register that have been conventionally arranged in the heap memory 236 of the emulation program are arranged in the shared heap memory (39) of the host OS, and the virtual main memory (392) and virtual register ( 391) can be accessed.

  Operations of the emulation program A (33) and the emulation program B (34) will be described with reference to FIG.

  When the host OS (35) is activated, the emulation program A (33) is first activated as the active system. Each module in the emulation program starts as a thread and starts the initial setting. When the setting is completed, the SVP (332) loads the guest OS (32) into the virtual main memory (392), and executes a startup process. In this embodiment, the SVP (332) notifies the SNC (335) of the start preparation completion before executing the start process, and starts executing the guest OS (32) in response to the start instruction from the SNC (335). The SNC (335) uses the OS system call fork () to create the emulation program B (34) as a copy of the emulation program A (33) as a standby system.

  The operation of the SNC in this case will be described with reference to FIG. FIG. 6 is a flowchart showing the operation of the SNC. The active emulation program (33) is started (401), and the start preparation completion notification from the SVP is received (402). The SNC first determines whether the own program is the active emulation program or the standby emulation program. Check (403). This is determined by the attribute of each program. That is, a determination is made based on whether the process performed by the own program is a parent process or a child process. If the process is a parent process, the active emulation program is used, and if the process is a child process, a standby emulation program is used. Here, if it is identified as a parent process that is an active emulation program, it is checked whether a standby emulation program that is a child process exists (404). If the standby emulation program does not exist, a copy of the own program is created by using the fork () function that is a system call of the host OS, and is set as a standby emulation program (405).

  At this time, the standby emulation program is a complete copy of the active emulation program, and two processes that perform the same operation are executed. Therefore, the process attribute is determined again (406), and if it is a parent process, the operation mode setting (407) as the active system emulation program and the emulation start notification (408) to the SVP are performed. If it is a child process, an operation mode setting (413) as a child process is performed, and an emulation standby notification is sent to the SVP. It should be noted that after the standby emulation program is created, the emulation standby notification sent from the standby SNC to the SVP is immediately notified to each module, and each module is stopped before a new process is executed.

  Next, processing when the process attribute determination (403) identifies a child process and when the child process determination processing (404) includes a child process will be described. This is a failure monitoring process, in which inter-process communication is performed between the active SNC and the standby SNC to check the execution state and the presence / absence of the opposite process. If it is determined that the current system emulation program (parent process) is abnormal (409), the parent process abnormality process (410) is executed by the standby system emulation program (child process). If the standby emulation program (child process) is determined to be abnormal (411), the child emulation process (412) is executed by the active emulation program (parent process).

  This process abnormality process will be described with reference to FIGS. FIG. 7 shows parent process abnormality processing in a standby emulation program (child process). If the parent process is being executed (4092), a stop process for the active emulation program (parent process) is requested using the inter-process communication function between the active SNC and standby SNC used for the health check (4092). 4096). After the stop process is executed, if it is still being executed (4094), the parent process is forcibly stopped (kill) (4095), and the abnormal process is terminated. At this point, there is no working emulation program, the standby emulation program becomes the working emulation program (parent process), and the process returns to the loop of FIG. Process attribute determination unit (403), presence / absence determination of child process (404), generation of standby emulation process (child process) (405), process attribute determination (407), operation mode setting (407), start of emulation to SVP Following the notification (408), a child process for backup of the own program is generated and emulation is executed. At this time, the data in the virtual register (391) and the virtual memory (392) is taken over, and the emulation is restarted from the value of the program counter stored in the virtual register (391). With this function, even if the active emulation program that is executing the emulation stops, processing can be taken over by the standby emulation program, and the function can be continued. In addition, since the current system emulation program automatically creates a backup (standby system emulation program) of its own program, it is possible to make the system in which the process is continued and the system is unlikely to be down even in the event of an abnormality.

  FIG. 9 describes these mechanisms focusing on each process. When the active emulation program A (33) is activated (501) and the SNC (335) receives an activation preparation completion notification from the SVP (332) (502), the SNC (335) indicates whether there is a standby emulation program B process. Is confirmed (503). Since the standby system emulation program is not generated at the first activation, the emulation program B (child process) (34) is generated as a copy of the own program (504). The emulation program (504) (511) sets the operation mode from the state of the attribute (parent process, child process) of each process (505) (512), sends an emulation start instruction (506) to the SVP, and sends an emulation standby instruction (513). Here, it is assumed that a failure has occurred in the active emulation program (33). It is assumed that a failure has occurred at (508), the health check has failed, and the process has been left as it is (515). In this case, the SNC (345) first issues an emulation program end command to the SNC (335) (516). If the process is not terminated, the emulation program is forcibly terminated (518). After the active system emulation program A (33) ends, the standby system emulation program B (34) becomes the active system emulation program B (519), and the standby system emulation program C, which is a backup of its own program, is generated (520) (523). ). Thereafter, the same process is repeated each time a failure occurs.

  Next, the health check performed in FIGS. 6 (409) and (411) will be described. This health check is executed as interprocess communication between SNCs (335)-(345) of each emulation program.

  FIG. 10 shows a data format used for the health check. The health check data (60) consists of 16 bits, and consists of an operation (601), a status (602), and a time stamp (603). The operation field (601) consists of 1 bit and indicates whether the health check data is a normal health check or stop request data when the emulation program is abnormal. The status field (602) indicates the execution state of the emulation program on the health check data transmission side, 0: waiting for execution (normal state of standby system emulation program), 1: executing instruction, 2: waiting, 3: stopping (emulation) Indicates a non-program failure). The time stamp field is made up of 13 bits, and a minute or less of the system clock time on the transmission side is converted into millisecond units to obtain field data.

  In the present embodiment, when the system is operating normally, the health check is executed at a cycle of “200 [ms] + time required for health check”. At this time, the SNC (335) (345) throws the health check data to the opposite process, and at the same time, reaps the received health check data and updates the data reception time stamp. When this time stamp exceeds 1 second, it is considered as a health check abnormality.

  As described above, the present invention has the following configuration.

  First, in a virtual machine system that implements a single virtual machine by software emulation on a single OS, the current system emulation software and standby system emulation software are placed, and if the current system emulation software fails, the standby system emulation software is processed. To continue operation in the standby system.

  Furthermore, the status emulation is monitored between the active emulation software and the standby emulation software, and the virtual machine is operated based on the monitoring result.

  Alternatively, after the active emulation software is switched to the standby emulation software due to a failure, the standby emulation software becomes the active emulation software, and the active emulation software automatically activates the standby emulation software.

  By detecting abnormalities early with these functions and taking over the functions to the standby emulation program, the system downtime is reduced, and as a result, the reliability can be improved.

Example of a computer configuration using conventional dedicated hardware Configuration example of a computer using a conventional software emulation method Example of computer emulation program configuration using conventional software emulation method It is a structural example of the computer which mounted the duplication of the emulation program. It is an example of the emulation program structure in the computer which implemented the duplication of the emulation program. It is an example of the control flow of the process synchronization part SNC in the computer which mounted the duplication of the emulation program. It is an example of the parent process abnormal termination processing control flow in the process synchronization unit SNC. It is an example of a child process abnormal termination process control flow in the process synchronization unit SNC. It is an example of the operation | movement for every process from an emulation program start to failure recovery. It is an example of a health check data format.

Explanation of symbols

21 ... User program, 22 ... Guest OS. 23 ... Emulation program, 24 ... Host OS, 25 ... Firmware, 26 ... General-purpose hardware, 231 ..., 232 ... SVP, 234 ... IOP, 235 ... IOC , 2351 ... virtual register, 2352 ... virtual main memory, 236 ... heap memory

Claims (1)

In a virtual machine system that realizes a virtual machine by software emulation,
An operating system assigned to the shared memory area;
A first emulation software and a second emulation software installed on the operating system, each having different attributes;
The first and second emulation software execute fault monitoring on each other's software,
A virtual computer system characterized in that, when a failure occurs during software processing in any one software, the attribute is changed, and the other software takes over the software processing in which the failure has occurred.

Images