WO2014024279A1 - メモリ障害リカバリ装置、方法、及びプログラム - Google Patents

メモリ障害リカバリ装置、方法、及びプログラム Download PDF

Info

Publication number
WO2014024279A1
WO2014024279A1 PCT/JP2012/070250 JP2012070250W WO2014024279A1 WO 2014024279 A1 WO2014024279 A1 WO 2014024279A1 JP 2012070250 W JP2012070250 W JP 2012070250W WO 2014024279 A1 WO2014024279 A1 WO 2014024279A1
Authority
WO
WIPO (PCT)
Prior art keywords
recovery
memory
software
failure
memory area
Prior art date
Application number
PCT/JP2012/070250
Other languages
English (en)
French (fr)
Inventor
百々絵 齋藤
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2012/070250 priority Critical patent/WO2014024279A1/ja
Publication of WO2014024279A1 publication Critical patent/WO2014024279A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements

Definitions

  • the present invention relates to an apparatus, a method, and a program for performing recovery from a memory failure.
  • This virtualization function includes a dynamic partition function that makes the physical configuration of the virtual machine and hardware unaware.
  • a hypervisor has been used as one means for realizing a virtualization function.
  • FIG. 1 shows a configuration example of a system in which the virtualization function is realized by a hypervisor.
  • an operating system 1 (OS1) operates on a system board 1 and a system board 2 that are physically separated.
  • the system board 1 includes a memory 1, a CPU 1, and a CPU 2.
  • the system board 2 has a memory 2, a CPU 3, and a CPU 4.
  • the OS 2 is operating on the system board 3.
  • the system board 3 has a memory 3, a CPU 5, and a CPU 6.
  • the hypervisor provides an environment in which hardware such as a CPU and memory is managed and the OS 1 and OS 2 can operate as virtual machines.
  • the hypervisor centrally manages hardware and operating systems that are basic software. For this reason, it is extremely important to operate the hypervisor stably. For example, when an uncorrectable error (UE) occurs in the memory in which the hypervisor operates, the hypervisor may be in a recovery (restoration) impossible state. In this case, all virtual machines (logical domains) operating under the management of the hypervisor may be stopped. Such a system failure caused by the UE occurs not only in the hypervisor but also in the OS and application programs that run on the OS, and may lead to a system failure.
  • UE uncorrectable error
  • a failure spreads to a plurality of virtual machines managed by the piper visor.
  • the occurrence of a UE causes a serious problem not only in the hypervisor but also in the OS and application programs. Therefore, it is required to construct a fault tolerant system for such a UE.
  • the virtual machine monitor restores the state of the guest OS memory area to the time corresponding to the immediately preceding checkpoint, and the virtual machine monitor is not capable of error correction.
  • a free physical page in the alternate memory area at the time of failure is assigned to the virtual page address where no error occurred, and the page of the free physical page is assigned to the entry in the page table corresponding to the virtual page address where the error that is not error-correctable.
  • the present invention is directed to recovering from a memory failure.
  • An embodiment is an apparatus for recovering software existing in a memory when a failure occurs in the memory, and a recovery procedure corresponding to each of a plurality of memory areas loaded with the software
  • a recovery table for generating a recovery table, a fault table specifying unit for specifying a fault location, and a recovery procedure corresponding to a memory area including the fault location using the recovery table
  • an apparatus having a recovery specifying unit and a recovery executing unit that executes the specified recovery procedure.
  • recovery from a memory failure can be easily performed, and the reliability of the system can be improved.
  • the present invention includes cases where other programs such as BIOS and OS perform part or all of the actual processing and the functions of the embodiments are realized by the processing.
  • a hypervisor that functions between a hardware resource and an OS is taken up.
  • the hypervisor is not limited to this. It goes without saying that the hypervisor may be a hypervisor that operates under the management of a management program such as a specific OS.
  • the present invention is not limited to the memory failure related to the hypervisor. That is, it goes without saying that the present invention can be applied to various OSs (operating systems) and application programs. In addition, the embodiment of the present invention may be applied to recovery of data itself loaded on a memory. Therefore, it should be noted that the “software” used in this specification includes a hypervisor, an OS, an application program, data, and the like.
  • FIG. 2 is a diagram showing an outline of software recovery processing related to a memory failure according to an embodiment.
  • FIG. 2A is a flowchart showing an outline of software recovery processing related to a memory failure according to an embodiment.
  • This recovery process can be triggered by the occurrence of a memory failure (202). Detection of the occurrence of a memory failure may be triggered by, for example, an interrupt process based on a memory error detection by an ECC provided in hardware in the memory itself. Alternatively, the recovery process may be started by detecting an abnormality in information read from the memory by a CRC check detected by the hypervisor itself in software.
  • the fault location of the memory is specified.
  • the memory fault location may be a specific memory address.
  • a memory range may be specified as the fault location.
  • the key information 1150 is stored in the memory area.
  • Information that can identify the area ID 312 is stored, and a recovery procedure 316 corresponding to the area ID 312 of the identified memory area is searched from the recovery table 310 (FIG. 3B) described later. Then, the retrieved recovery procedure 316 may be executed (step 212 described later).
  • step 206 a predetermined recovery procedure corresponding to the memory failure position is specified.
  • a recovery table 310 (FIG. 3B) described later may be referred to.
  • step 208 it may be determined whether the memory failure is a fixed failure or an intermittent failure. For example, a past memory failure address is stored, and if a failure occurs a predetermined number of times at the same memory address (or the same area), it is determined that the memory at this memory address (or area) is a fixed failure. May be.
  • the determination as to whether or not the memory has a fixed fault may be a predetermined rule as a determination rule. The judgment rule may be different for each system (hardware or software). If this determination is “Yes”, the process proceeds to Step 210. If this determination is “NO”, the process proceeds to step 212.
  • step 210 Since it is determined in step 210 that the memory is a fixed failure, it is desirable to allocate an alternative memory area to a predetermined area including this address.
  • an address range to which the alternative memory area is allocated an area defined by the start address 314 and the area length 315 shown in the area designation information (314, 315) in the recovery table shown in FIG. 3B may be used. Then, when an alternative memory area is allocated, the corresponding start address 314 of the recovery table may be updated based on the address of the alternative memory area. Details of the recovery table shown in FIG. 3B will be described later.
  • step 212 the identified recovery procedure is executed.
  • the search for the recovery procedure will be described later with reference to FIG. A specific example of the recovery procedure will be described later using Table 1 below.
  • step 214 a series of recovery is completed.
  • the hypervisor may continue processing that should be executed.
  • a case where recovery is not successful is also assumed.
  • the entire system may be restarted as an abnormality process.
  • An example of a case where recovery cannot be performed in this embodiment will be described with reference to FIG.
  • the occurrence of a case where recovery cannot be performed for a memory failure can be reduced as much as possible, and the fault tolerance of the system can be improved.
  • FIG. 2B is a flowchart showing an outline of generation of a recovery table including information such as a recovery procedure.
  • step 222 software (for example, hypervisor program code) is loaded from the ROM or the like to the RAM in response to the instruction for starting the system.
  • software for example, hypervisor program code
  • the recovery table 310 is generated based on the address information of each element of the loaded software.
  • the recovery table 310 is a table used when the recovery procedure 316 is specified in step 206 of FIG.
  • step 2266 the software is started and executed.
  • the generation of the recovery table is preferably performed when the software code is loaded into the memory when the software (for example, hypervisor) is activated.
  • Table 1 shows the recovery types that can be applied to each element constituting the hypervisor.
  • the recovery type column a name for identifying the type of recovery is given.
  • the element column elements corresponding to the defined type among the elements constituting the hypervisor are shown.
  • the recovery procedure outlines the recovery procedure. The recovery procedure may be executed by, for example, a predetermined recovery routine.
  • the hypervisor's own code part is associated as an element of the hypervisor.
  • the recovery procedure for this element specifies that the corresponding element is read from the ROM and recovery is performed. That is, the program code part of the hypervisor itself is not rewritten. In this case, for example, the program code stored in the ROM can be read again and overwritten to perform recovery.
  • the hypervisor is updated, the program code portion is changed. The countermeasure in this case will be described with reference to FIG.
  • recovery type 2 it is associated with re-creatable data as a hypervisor element.
  • this example includes data that is not rewritten, such as a constant used by the hypervisor.
  • the hypervisor itself may create the data again.
  • the data may be recovered by the hypervisor initializing the data.
  • data that can be acquired from other components is associated as a hypervisor element.
  • the other components include an operating system, firmware, other software using a virtualization technology (for example, Ldom), a system monitoring mechanism (for example, XSCF), and the like.
  • data for example, OS version information, setting values for securing the OS physical memory, etc.
  • OS system monitoring mechanism
  • the specific procedure is as follows. (1) Prepare an interface between other components and the hypervisor. As this interface, for example, communication between programs with other components may be established. (2) The hypervisor designates data to the counterpart component and requests provision. (3) The counterpart component transmits the requested data to the hypervisor using the above interface. (4) The hypervisor recovers the target data using the acquired data.
  • the recovery may be performed as follows.
  • the hypervisor declares (recovery declaration) that recovery is being executed. It is desirable to suspend the CPU while the hypervisor is performing recovery. For example, it is desirable to avoid the spread of failures due to the execution of program code in the memory failure portion.
  • the hypervisor may operate on a plurality of logical CPUs. It is desirable that the CPU that detects the declaration during the execution of recovery in the hypervisor returns a busy response and performs an operation such as suspending until the recovery declaration is canceled.
  • a method of the recovery declaration for example, a global variable that can be commonly accessed by all CPUs may be defined as a recovery declaration flag. Check the variable when starting the hypervisor. A global variable may be used for managing the CPU suspend state. Alternatively, in the case where a CPU call function exists, a method of positively transitioning another CPU to the hypervisor space using this CPU call function may be used.
  • FIG. 3 is a diagram showing tables used in the recovery according to the embodiment.
  • FIG. 3A illustrates the software configuration information 300 used when generating the recovery table 310 (FIG. 3B).
  • the software configuration information 300 may be stored in a storage unit (eg, RAM, HDD, etc.) in a table format.
  • the software configuration information 300 shown in FIG. 3A indicates the configuration of specific software.
  • the software configuration information 300 may be generated, for example, when the software is compiled (or updated), and may include the following information.
  • the area ID in FIG. 3A may be assigned in association with an area having the same recovery type in Table 1 among consecutive parts constituting software (for example, hypervisor). With this area ID, each of a plurality of elements constituting the software can be uniquely specified on the memory.
  • the area ID may be a simple serial number.
  • a reserve 304 is a reserved entry. The reserve 304 may be omitted, but is provided to simplify the generation of the software configuration information 300 when generating a recovery table 310 (FIG. 3B) described later.
  • the area length 305 indicates the length of the software element. The area length 305 makes it possible to grasp the length of the area occupied by the software element specified by the area ID 302 in the memory.
  • the recovery procedure 306 may store the address of the recovery routine.
  • One or more arguments necessary for executing the recovery routine may be stored together with the address of the recovery routine.
  • a plurality of recovery procedure methods may be defined, and a predefined recovery procedure itself may be stored instead of the address of the recovery routine.
  • the recovery types shown in Table 1 may be stored.
  • information necessary for executing the recovery type (eg, component designation) may be stored together.
  • the recoverability flag 308 is information indicating whether recovery is possible. For example, if this value is “OK”, it indicates that recovery can be performed. If this value is “NG”, it indicates that recovery cannot be performed. Examples of cases where recovery cannot be performed include data that can be dynamically changed during the execution of a program, data without saved data, data that cannot be recreated, and the like.
  • the recovery possibility flag for such data may be set to “OK” or “conditional OK”. If the recovery possibility flag is “NG”, the corresponding recovery procedure entry may be “empty”.
  • FIG. 3B is a diagram illustrating the recovery table 310.
  • the recovery table is preferably generated when a program (eg, hypervisor) is loaded into the memory. Moreover, it is desirable to generate again when the hypervisor is updated.
  • the recovery table 310 is generated based on the software configuration information 300. An example of generating the recovery table will be described later with reference to FIG.
  • the same information as the software configuration information 300 shown in FIG. 3A can be stored for the area ID 312, the area length 315, and the recovery enable / disable flag 318.
  • the start address 314 stores the start address on the memory of the software element corresponding to the area ID. Based on the start address 314, the area length 315, and (area specifying information), it is possible to grasp in which area on the memory the software element corresponding to the area ID exists. Note that the end address calculated from the start address 314 and the area length 315 may be stored instead of the area length 315.
  • FIG. 4 shows a flowchart for generating the recovery table 310 in one embodiment.
  • the recovery table 310 may be generated based on the software configuration information 300.
  • step 402 first, the area of the recovery table 310 is acquired on the memory based on the number of entries (n) of the software configuration information 300.
  • step 404 the software configuration information 300 information is copied to the recovery table 310.
  • step 406 the first entry (first entry) of the recovery table 310 is set as the entry of interest.
  • the entry of interest means an entry for which the following steps are executed.
  • step 408 the top address on the memory of the software element corresponding to the entry of interest is acquired and registered as the start address 314.
  • the end address calculated from the start address 314 and the area length 315 may be stored instead of the area length 315.
  • step 10 the address of the recovery routine of the entry of interest is corrected.
  • the address of the recovery routine is expressed as a relative address
  • the relative address of the recovery routine is corrected to an appropriate value based on the difference between the head address of the software configuration information 300 and the head address of the recovery table 310.
  • the recovery routine address may be set to an appropriate physical address. If the address of the recovery routine is expressed as an absolute address, this correction is not necessary.
  • step 412 it is checked whether the entry of interest is the last entry. If this check result is “Yes”, this indicates that the processing of all entries in the recovery table has been completed, and the processing may be terminated. If the check result is “No”, the process proceeds to Step 414.
  • step 414 the next entry is set as the target address. Then, the process returns to step 408.
  • the recovery table 310 is generated by the above processing.
  • FIG. 5 shows a recovery flowchart in one embodiment.
  • This process may be triggered by an interrupt that detects a memory failure event.
  • step 502 the top entry of the recovery table 310 is set as a target entry.
  • step 504 it is checked whether or not the failure address is included in the area specifying information (314, 315) of the target entry. If the check result is “Yes”, the process proceeds to Step 508. If the check result is “No”, the process proceeds to Step 506.
  • step 508 it is checked whether recovery is possible. This check may be determined by referring to the recovery enable / disable flag of the recovery table 310. If the check result is “Yes”, the process proceeds to Step 510. If the check result is “No”, the process proceeds to Step 522.
  • step 510 the recovery procedure is executed. Specific examples of the recovery procedure have been described using Table 1 above. Thereafter, the process ends at step 521 (end 1). In this case, since the recovery was successful, the original processing of the software can be continued.
  • step 506 it is checked whether the entry of interest is the last entry. If this check is “Yes”, the process proceeds to Step 522. If the check result is “No”, the process proceeds to Step 512.
  • step 522 the process ends (end 2).
  • the termination in this case corresponds to the case where the recovery is unsuccessful. Therefore, for example, it is desirable to restart the program.
  • the program is a hypervisor, it is desirable to restart all the OSs operating on the hypervisor.
  • step 512 the next entry in the recovery table 310 is set as the entry of interest. Then, the process returns to step 514.
  • FIG. 6 shows a functional block diagram of an embodiment.
  • the system includes a recovery table generation unit 602, a failure detection unit 620, a failure location specification unit 630, a recovery specification unit 640, a recovery execution unit 650, software configuration information 300, and a recovery table 310.
  • the recovery table generation unit 602 may generate the recovery table 310 based on the software configuration information 300. Further, the recovery table generation unit 602 may further include a recovery table update unit 610. When the software is updated, it is desirable that the software configuration information 300 is also updated. Then, when the software is updated, the recovery table update unit 610 updates the recovery table based on the updated software configuration information 300.
  • the failure detection unit 620 may detect a memory failure and generate an interrupt.
  • the software eg, hypervisor itself may perform a CRC check to detect a memory failure.
  • the detection of the memory failure may be transmitted to the failure position specifying unit 630.
  • the fault location specifying unit 630 specifies the memory location where the fault has occurred. Alternatively, a memory area including an address where a failure has occurred may be detected. The detected failure position is sent to the recovery specifying unit 640.
  • the recovery specifying unit 640 searches the recovery table 310 using the failure position and specifies the recovery procedure 316. Further, the recovery specifying unit 640 may include a recovery possibility determination unit 642 and a fixed fault recognition unit 646. When the recovery table 310 is searched using the failure position, the recovery possibility determination unit 642 refers to the recovery possibility flag 318 and determines whether recovery is possible. If recovery is possible, the specified recovery information is passed to the recovery execution unit 650.
  • the fixed fault recognition unit 646 checks whether a fault has occurred at the same memory address a predetermined number of times. When a fixed memory failure is recognized, an alternative memory area is allocated by the alternative memory allocation unit 652 as described later.
  • the recovery execution unit 650 executes the specified recovery procedure.
  • the recovery procedure 316 may be executed by a recovery routine.
  • the recovery execution unit 650 may include an alternative memory allocation unit 652. When an alternative memory area is allocated, it is desirable to update the start address 314 (and end address) of the recovery table 310. Then, after the alternative memory area is allocated, recovery is executed.
  • FIG. 7 is a diagram showing processing of a recovery routine in one embodiment.
  • the maximum number of recovery routines for recovery may be as many as the number (n) of entries in the recovery table. As shown in Table 1, as many recovery routines as the number of recovery types may be prepared. In this case, the number of recovery routines is less than n.
  • step 702 based on the recovery routine address stored in the recovery procedure of the recovery table, the process is branched to the recovery routine.
  • FIG. 7 shows a recovery routine 1 (712), a recovery routine 3 (714), and a recovery routine n (716).
  • FIG. 8A is a diagram illustrating an example of a recovery table in one embodiment.
  • the recovery procedure 816 may store the addresses of recovery routines of recovery type 1 (862), recovery type 2 (864), and recovery type 3 (866), depending on the type of recovery.
  • information for identifying the type of recovery may be stored instead of the address of the recovery routine.
  • An appropriate recovery procedure may be executed using this identifying information. Note that the recovery table area ID 812, start address 814, area length 815, and recovery flag 818 are the same as in FIG.
  • FIG. 8B is a diagram showing the processing of the recovery routine in one embodiment.
  • a recovery routine address corresponding to the recovery type is designated. If the recovery routine address is set in the recovery procedure 816, the recovery type 1 recovery routine (862), the recovery type 2 recovery routine (864), and the recovery type 3 recovery routine (based on the address) 866), the process may be branched. Alternatively, when the recovery type is set in the recovery procedure 816, the recovery routine of the recovery type 1 (862), the recovery routine of the recovery type 2 (864), the recovery routine of the recovery type 3 (in accordance with the recovery type ( 866), the process may be branched.
  • FIG. 9 is a diagram showing an example of updating the recovery table at the time of software update.
  • the software configuration changes, so it is desirable to update the recovery table.
  • step 902 the software is updated.
  • step 904 the software configuration information 300 is updated in conformity with the software update. Note that the software configuration information 300 may be updated at the same time when the software is updated.
  • step 906 the recovery table 310 is updated in accordance with the software update.
  • a new area for the recovery table 310 may be secured and the recovery table 310 may be generated again.
  • FIG. 10 is a diagram illustrating a hardware configuration according to an embodiment.
  • the hardware includes a CPU 1002, a memory 1004, an input / output device 1006, a display device 1008, a hard disk 1010, and a recording medium driving device 1012. Each device is connected by a bus 1016. Further, the recording medium driving device 1012 can read and write the portable recording medium 1014.
  • This hardware may be implemented with the functions shown in FIG. Moreover, the process of each flowchart described in drawing may be performed by this hardware.
  • the portable recording medium 1014 refers to one or more non-transitory, tangible recording media having a structure.
  • Illustrative examples of the portable recording medium 1014 include a magnetic recording medium, an optical disk, a magneto-optical recording medium, and a nonvolatile memory.
  • Magnetic recording media include HDDs, flexible disks (FD), magnetic tapes (MT) and the like.
  • Examples of the optical disc include DVD (Digital Versatile Disc), DVD-RAM, CD-ROM (Compact Disc-Read Only Memory), CD-R (Recordable) / RW (ReWriteable), and the like.
  • Magneto-optical recording media include MO (Magneto-Optical disk). All or a part of the embodiments of the present invention can be implemented by reading a program stored in a portable recording medium and executing it by a processor.
  • FIG. 11 is a diagram illustrating a memory configuration according to an embodiment.
  • the memory 1100 shown in FIG. 11 employs a server architecture that can set the key information 1150 for each predetermined memory size unit.
  • key information 1151 corresponds to the memory unit 1101.
  • key information 1157 corresponds to the memory unit 1107.
  • the corresponding area ID 312 of the recovery table 310 may be stored in the key information 1150.
  • the area ID 312 stored in the corresponding key information 1151 may be acquired.
  • the recovery table 310 may be searched from the acquired area ID 312 and the corresponding recovery procedure 316 may be acquired.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)

Abstract

　本発明の実施形態は、メモリ障害からのリカバリを行うことを目的とする。　一実施形態は、メモリに障害が発生した場合に、前記メモリに存在するソフトウエアのリカバリを行う装置であって、前記ソフトウエアがロードされた複数のメモリ領域の各々に対応させて、リカバリ手順を定めたリカバリテーブルを生成する、リカバリテーブル生成部と、障害の位置を特定する、障害位置特定部と、前記リカバリテーブルを用いて、前記障害の位置を含むメモリ領域に対応したリカバリ手順を特定する、リカバリ特定部と、前記特定されたリカバリ手順を実行する、リカバリ実行部と、を有する装置を提供する。

Description

メモリ障害リカバリ装置、方法、及びプログラム
　本発明は、メモリ障害からのリカバリを行う装置、方法、及びプログラムに関する。
　近年のクラウドコンピューティングや、サーバ統合を支援する技術として、仮想化機能が活発に利用されている。この仮想化機能は、仮想マシンやハードウエアの物理構成を意識させないダイナミックパーティション機能が含まれる。仮想化機能を実現する一つの手段としてハイパーバイザが使用されてきた。
　図１は、仮想化機能をハイパーバイザで実現しているシステムの構成例を示している。図１に示されるように、オペレーティングシステム１（ＯＳ１）は、物理的に分離されたシステムボード１とシステムボード２の上で動作している。システムボード１は、メモリ１、ＣＰＵ１、及びＣＰＵ２を有している。また、システムボード２は、メモリ２，ＣＰＵ３、及びＣＰＵ４を有している。また、システムボード３の上でＯＳ２が動作している。システムボード３は、メモリ３、ＣＰＵ５、及びＣＰＵ６を有している。ハイパーバイザは、このようなシステムを構築するために、ＣＰＵやメモリなどのハードウエアを管理し、かつ、ＯＳ１及びＯＳ２が仮想マシンとして動作できる環境を提供している。
　ハイパーバイザは、ハードウエアと基本ソフトウエアであるオペレーティングシステムなどを集中的に管理している。このため、ハイパーバイザを安定的に動作させることは、極めて重要である。例えば、ハイパーバイザが動作するメモリで、訂正不可能な故障（UE:　Uncorrectable　Error）が発生すると、ハイパーバイザは、リカバリ（復旧）不能状態となることがある。この場合、そのハイパーバイザの管理の下で動作している全ての仮想マシン（論理ドメイン）が停止してしまう可能性がある。このようなＵＥに起因するシステム障害は、ハイパーバイザに限らず、ＯＳや、ＯＳ上で動作するアプリケーションプログラムにおいても同様に発生し、システムダウンにつながることもある。
　特に、ハイパーバイザにおけるＵＥの発生は、パイパーバイザが管理する複数の仮想マシンに障害が波及する。ハイパーバイザに限らず、ＯＳやアプリケーションプログラムにおいても、上述のようにＵＥの発生は深刻な問題を引き起こす。したがって、このようなＵＥに対してフォールトトレラントなシステムを構築することが求められている。
　ＵＥに係るハイパーバイザの障害を回避する手段の一つとして、ハイパーバイザで使用するメモリをミラーリングする技術がある。このミラーリングによりメモリにおけるＵＥに係るシステムダウンを抑止できる可能性を増大させることができる。なお、ミラーリングはメモリを２倍消費してしまう。ハイパーバイザがメモリを大量に消費してしまうことは、他のソフトウエアに利用できるメモリを減少させてしまうため、システム全体の性能低下に繋がる可能性がある。このために、メモリの消費を抑えつつ、ＵＥに係る障害に対してフォールトトレランスを高めることも望まれている。
　磁気ディスク等の記憶装置でプログラム及びデータをバックアップしている方式を利用し、主記憶装置で読出し障害が発生した場合、該当アドレスのプログラム又は読出し専用データを補助記憶装置から主記憶装置に読上げて再書き込みを行うことで、障害を修復し処理を継続する技術が存在する（例えば、特許文献1参照）。
　メモリに発生したＥＣＣエラーが誤り訂正可能なエラーでない場合、仮想マシンモニタが、ゲストＯＳのメモリ領域の状態を直前のチェックポイントに対応する時点に復元すると共に、仮想マシンモニタは、誤り訂正可能ではないエラーが発生した仮想ページアドレス用に、障害時代替用メモリ領域の空き物理ページを割り当て、誤り訂正可能ではないエラーが発生した仮想ページアドレスに対応するページテーブルのエントリに、空き物理ページのページアドレスを設定する技術が存在する（例えば、特許文献２参照）。
特開昭６１－１９３５９１号公報 特開２００９－２４５２１６号公報
　１つの側面では、本発明は、メモリ障害からのリカバリを行うことを目的とする。
　一実施形態は、メモリに障害が発生した場合に、前記メモリに存在するソフトウエアのリカバリを行う装置であって、前記ソフトウエアがロードされた複数のメモリ領域の各々に対応させて、リカバリ手順を定めたリカバリテーブルを生成する、リカバリテーブル生成部と、障害の位置を特定する、障害位置特定部と、前記リカバリテーブルを用いて、前記障害の位置を含むメモリ領域に対応したリカバリ手順を特定する、リカバリ特定部と、前記特定されたリカバリ手順を実行する、リカバリ実行部と、を有する装置を提供する。
　一態様によれば、メモリ障害からのリカバリを簡便に行うことができ、システムの信頼性を向上させることができる。
仮想化機能をハイパーバイザで実現しているシステムの構成例を示す図である。 一実施形態のメモリ障害に係るソフトウエアのリカバリ処理の概要を示す図である。 一実施形態のリカバリの際に用いられるテーブル類を示す図である。 一実施形態におけるリカバリテーブルを生成するためのフローチャートである。 一実施形態におけるリカバリを示す図である。 一実施形態の機能ブロック図である。 一実施形態におけるリカバリルーチンの処理を示す図である。 一実施形態におけるリカバリルーチンの処理の他の例を示す図である。 一実施形態におけるソフトエアのアップデートの際のリカバリテーブルの更新の例を示す図である。 一実施形態のハードウエアの構成を示す図である。 一実施形態のメモリ構成を示す図である。
　以下に、図面を用いて本発明の実施形態を詳細に説明する。なお、以下の実施形態は、発明を理解するためのものであり、本発明の範囲を限定するためのものではない点に留意すべきである。また、以下の複数の実施形態は、相互に排他的なものではない。したがって、矛盾が生じない限り、異なる実施形態の各要素を組み合わせることも意図されていることに留意すべきである。また、請求項に記載された方法やプログラムに係る発明は、矛盾のない限り処理の順番を入れ替えてもよく、あるいは、複数の処理を同時に実施してもよい。そして、これらの実施形態も、請求項に記載された発明の技術的範囲に包含されることは言うまでもない。
　また、コンピュータが読み出したプログラムコードを実行することにより、後述の実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働している管理ソフトウエア、ファームウエア、ＢＩＯＳ、ＯＳなどの他のプログラムが実際の処理の一部または全部を行ない、その処理によって実施形態の機能が実現される場合も、本発明に含まれることは言うまでもない。
　本明細書では、ハイパーバイザの例示として、ハードウエア資源とＯＳとの間で機能するハイパーバイザを取り上げている。しかしながら、ハイパーバイザはこれに限られるものではない。ハイパーバイザは、特定のＯＳなどの管理プログラムの管理の下で動作するハイパーバイザであってもよいことは言うまでもない。
　また、本発明は、ハイパーバイザに係るメモリ障害に限定されるものではない。すなわち、本発明は、種々のＯＳ（オペレーティングシステム）、アプリケーションプログラムにも適用できることは言うまでもない。加えて、本発明の実施形態は、メモリ上にロードされたデータそのもののリカバリに適用されてもよい。したがって、本明細書において、使用する「ソフトエア」は、ハイパーバイザ、ＯＳ、アプリケーションプログラム、データ等を含む点に留意すべきである。
　図２は、一実施形態のメモリ障害に係るソフトウエアのリカバリ処理の概要を示す図である。
　図２（Ａ）は、一実施形態のメモリ障害に係るソフトウエアのリカバリ処理の概要を示すフローチャートである。
　このリカバリ処理は、メモリ障害の発生（２０２）によって起動され得る。メモリ障害の発生の検知は、例えば、メモリ自体にハードウエア的に備えられたＥＣＣによるメモリエラー検出による割り込み処理を契機に開始させてもよい。あるいは、ハイパーバイザ自身がソフトウエア的に検出したＣＲＣチェックにより、メモリから読み出された情報の異常の検出により、このリカバリ処理が開始されてもよい。
　ステップ２０４において、メモリの障害位置を特定する。メモリの障害位置は、具体的なメモリアドレスであってもよい。上述のＣＲＣチェックによるソフトウエア的なメモリ障害のチェックの場合には、障害位置としてメモリの範囲が特定されてもよい。あるいは、メモリの所定のメモリサイズ単位毎にキー情報１１５０（メモリ情報保存部に対応する）を設定できるサーバアーキテクチャを採用している場合（図１１参照）には、キー情報１１５０として、メモリ領域の領域ＩＤ３１２（図３（Ｂ）参照）を識別できる情報を格納しておき、識別されたメモリ領域の領域ＩＤ３１２に対応するリカバリ手順３１６を後述のリカバリテーブル３１０（図３（Ｂ））から検索して、検索されたリカバリ手順３１６を実行してもよい（後述のステップ２１２）。
　ステップ２０６において、メモリ障害位置に対応する、所定のリカバリ手順を特定する。リカバリ手順の特定にあたっては、後述するリカバリテーブル３１０（図３（Ｂ））を参照してもよい。
　ステップ２０８において、メモリの障害が固定障害か、間欠障害かを判断してもよい。たとえば、過去のメモリ障害アドレスを記憶しておき、同一のメモリアドレス（又は同一の領域）において障害が所定の回数発生した場合、このメモリアドレス（又は領域）のメモリを固定障害であると判断してもよい。なお、メモリが固定障害であるか否かの判断は、判断規則として所定の規則を予め定めておいてもよい。判断規則は、システム（ハードウエア又はソフトウエア）毎に異なっていてもよい。この判断が「はい」であれば、ステップ２１０に進む。この判断が「いいえ」であれば、ステップ２１２に進む。
　ステップ２１０において、メモリが固定障害であると判断されているため、このアドレスを含む、予め定められた領域に対して、代替メモリ領域を割当てることが望ましい。代替メモリ領域を割り当てるアドレスの範囲として、図３（Ｂ）に示すリカバリテーブル内の領域指定情報（３１４，３１５）に示される開始アドレス３１４と領域長３１５で定義される領域を用いてもよい。そして、代替メモリ領域が割り当てられた場合には、代替メモリ領域のアドレスに基づいてリカバリテーブルの対応する開始アドレス３１４を更新してもよい。なお、図３（Ｂ）に示されるリカバリテーブルの詳細については後述する。
　ステップ２１２において、特定されたリカバリ手順が実行される。リカバリ手順の検索については、図５を用いて後述する。また、リカバリ手順の具体例については、下記表１を用いて後述する。
　ステップ２１４において、一連のリカバリが終了する。上述のステップにおいて、リカバリが成功すれば、ハイパーバイザは、本来実行すべき処理を継続してもよい。上述のステップにおいて、リカバリが成功しない場合も想定される。この場合には、異常処理としてシステム全体の再起動を行ってもよい。なお、再起動の際には、バックアップデータやスナップショットを活用し、可能な限り、リカバリは、メモリ障害前に近いシステムの状態にすることが望ましい。本実施例において、リカバリが行えないケースの例については、図３（Ａ）において説明する。本発明の実施例では、メモリ障害に対してリカバリが行えないケースの発生を極力減少させることができ、システムのフォールトトレランスを向上させることができる。
　図２（Ｂ）は、リカバリ手順等の情報を含むリカバリテーブルの生成の概略を示すフローチャートである。
　ステップ２２２において、システムの立ち上げの指示に応答して、ソフトウエア（例えばハイパーバイザのプログラムコード）が、ＲＯＭ等からＲＡＭにロードされる。
　ステップ２２４において、ロードされたソフトウエアの各要素のアドレス情報に基づいて、リカバリテーブル３１０が生成される。このリカバリテーブル３１０は、上述の図２（Ａ）のステップ２０６において、リカバリ手順３１６を特定する際に用いられるテーブルである。
　ステップ２２６において、ソフトウエアが起動され、実行される。
　上述のように、リカバリテーブルの生成は、ソフトウエア（例えば、ハイパーバイザ）の起動時において、ソフトウエアコードがメモリへロードされる際に行われることが望ましい。
　次に、ハイパーバイザを例にして、ハイパーバイザの複数の構成要素のリカバリのタイプ、及びリカバリの具体例について表１を用いて説明する。
Figure JPOXMLDOC01-appb-T000001
 　表１は、ハイパーバイザを構成する各要素に適用できるリカバリタイプを示している。リカバリ種別の欄には、リカバリのタイプを識別するための名前が付けられている。要素の欄には、ハイパーバイザを構成する要素のうち、定義されたタイプに対応する要素が示されている。リカバリ手順には、リカバリの手順の概要が示されている。リカバリ手順は、例えば、所定のリカバリルーチンで実行されてもよい。
　リカバリタイプ１では、ハイパーバイザの要素として、ハイパーバイザ自身のコード部が対応付けられている。そして、この要素に対するリカバリ手順は、ＲＯＭから対応する要素を読み出してリカバリを行うことが明記されている。すなわち、ハイパーバイザ自身のプログラムコード部は、書き換えられることがないからである。この場合には、例えばＲＯＭに格納されているプログラムコードを再度読み出して上書きすることにより、リカバリを行うことができる。なお、ハイパーバイザがアップデートされる場合には、プログラムコード部分が変更される。この場合の対処については、図９を用いて説明する。
　リカバリタイプ２では、ハイパーバイザの要素として、再作成可能なデータに対応付けられている。例えば、この例としては、ハイパーバイザが用いる定数など、書き換わることがないデータが挙げられる。このような、書き換わることがないデータに関しては、例えば、ハイパーバイザ自身が、データを再度作成すればよい。例えば、ハイパーバイザがデータを初期化することによって、データのリカバリを行ってもよい。
　リカバリタイプ３では、ハイパーバイザの要素として、他コンポーネントから取得可能なデータが対応付けられている。他コンポーネントとは、例えば、オペレーティングシステム、ファームウエア、仮想化技術を使っている他のソフトウエア（例：Ｌｄｏｍ）、システム監視機構（例：ＸＳＣＦ）などが挙げられる。このような他のコンポーネントが持っているデータ（例えば、ＯＳのバージョン情報、ＯＳの物理メモリ確保のための設定値等）を取得して、ハイパーバイザが利用している場合、そのデータが破壊された場合には、そのデータを、そのコンポーネント（ＯＳ）から再度取得することにより、障害のあるデータのリカバリが可能である。例えば、具体的な手順は以下の通りである。
（１）他コンポーネントとハイパーバイザ間のインタフェースを用意する。このインタフェースとしては、例えば、他のコンポーネントとの間のプログラム間通信を確立してもよい。
（２）ハイパーバイザから相手先コンポーネントにデータを指定して提供を要求する。
（３）相手先コンポーネントは要求されたデータを上記のインタフェースを使用してハイパーバイザに送信する。
（４）ハイパーバイザは取得したデータを使って対象データのリカバリが行われる。
　リカバリは、以下のような処理を行ってもよい。
（ｉ）リカバリ実行の宣言
　リカバリ実行の開始にあたって、リカバリ実行中であることを、ハイパーバイザが宣言（リカバリ宣言）することが望ましい。ハイパーバイザがリカバリ実行中は、ＣＰＵをサスペンドさせることが望ましい。例えば、メモリ障害の部分のプログラムコードの実行による障害の波及を避けることが望ましい。なお、ハイパーバイザは、複数の論理ＣＰＵ上で動作していることもある。ハイパーバイザ内でリカバリ実行中の宣言を検出したＣＰＵは、ビジー応答を返し、リカバリ宣言解除までサスペンドする等の動作を行わせることが望ましい。リカバリ宣言の方法としては、例えば、全ＣＰＵが共通にアクセスできるグローバル変数を、リカバリ宣言用のフラグとして定義しておいてもよい。ハイパーバイザ起動時にその変数を確認する。そして、ＣＰＵサスペンド状態の管理にグローバル変数を用いてもよい。或いは、ＣＰＵ呼び出し機能が存在する場合には、このＣＰＵ呼び出し機能を使用して積極的に他ＣＰＵをハイパーバイザ空間に遷移させる方法を用いてもよい。
　リカバリが完了したら、ログを取得してもよい。また、リカバリの完了によって、リカバリ宣言を解除する。そして、本来の処理を再開させる。
　図３は、一実施形態のリカバリの際に用いられるテーブル類を示す図である。
　図３（Ａ）は、リカバリテーブル３１０（図３（Ｂ））の生成の際に用いられるソフトウエア構成情報３００を例示している。ソフトウエア構成情報３００は、テーブル形式で記憶部（例：ＲＡＭ、ＨＤＤ等）に格納されてもよい。図３（Ａ）に示すソフトウエア構成情報３００は、特定のソフトウエアの構成を示したものである。ソフトウエア構成情報３００は、例えば、ソフトウエアがコンパイルされる際（又はアップデートされる際）に生成されてもよく、以下の情報を含んでもよい。
　図３（Ａ）における領域ＩＤは、ソフトウエア（例えばハイパーバイザ）を構成する連続した部分のうち、表１のリカバリ種別が同じである領域に対応付けて付与されてもよい。この領域ＩＤによって、ソフトウエアを構成する複数の要素の各々を、メモリ上で一意に特定することができる。領域ＩＤは、単純な連続番号であってもよい。リザーブ（Ｒｅｓｅｒｖｅ）３０４は、リザーブされたエントリである。リザーブ３０４は、無くてもよいが、後述するリカバリテーブル３１０（図３（Ｂ））の生成の際に、ソフトウエア構成情報３００の生成を単純化させるために設けられたものである。領域長３０５は、ソフトウエアの要素の長さを示す。領域長３０５によって、領域ＩＤ３０２で特定されるソフトウエアの要素がメモリ上で占める領域の長さを把握することができる。リカバリ手順３０６は、リカバリルーチンのアドレスが格納されてもよい。なお、リカバリルーチンのアドレスと共に、リカバリルーチンの実行に必要な１つ以上の引数が格納されてもよい。あるいは、複数のリカバリ手順の方法を定義しておき、リカバリルーチンのアドレスに代えて、予め定義されたリカバリ手順そのものが格納されてもよい。また、例えば、表１に示したリカバリタイプが格納されてもよい。加えて、リカバリタイプを実行するために必要な情報（例：コンポーネントの指定）を併せて格納してもよい。リカバリ可否フラグ３０８は、リカバリが可能か否かを示す情報である。例えば、この値が「ＯＫ」であれば、リカバリが行えることを示す。この値が「ＮＧ」であれば、リカバリが行えないことを示す。リカバリが行えないケースとしては、プログラムの実行中に動的に変更さ得るデータ、待避データがないデータ、再作成が不可能なデータ等が挙げられる。なお、このようなデータは、バックアップ又はスナップショットなどのデータからリカバリできる可能性がある。すなわち、バックアップ又はスナップショット取得時期と、この取得時期以降に該当するデータが変更されたか否かの情報から、リカバリが成功する場合がある。このようなアーキテクチャを持つハイパーバイザの場合には、このようなデータに対するリカバリ可否フラグを「ＯＫ」又は「条件付ＯＫ」に設定してもよい。なお、リカバリ可否フラグが「ＮＧ」であれば、対応するリカバリ手順のエントリは「空」であってもよい。
　図３（Ｂ）は、リカバリテーブル３１０を例示する図である。リカバリテーブルは、プログラム（例：ハイパーバイザ）が、メモリにロードされる際に生成されることが望ましい。また、ハイパーバイザがアップデートされる際に、再度生成されることが望ましい。リカバリテーブル３１０は、ソフトウエア構成情報３００を基にして生成される。なお、リカバリテーブルを生成する例については、図４を用いて後述する。
　図３（Ｂ）において、領域ＩＤ３１２、領域長３１５、リカバリ可否フラグ３１８については、図３（Ａ）に示したソフトウエア構成情報３００と同じ情報が格納され得る。開始アドレス３１４は、領域ＩＤに対応するソフトウエアの要素のメモリ上での開始アドレスが格納される。開始アドレス３１４と領域長３１５と（領域特定情報）に基づいて、領域ＩＤに対応するソフトウエアの要素が、メモリ上のどの領域に存在するかが把握できる。なお、開始アドレス３１４と領域長３１５から計算される終了アドレスを、領域長３１５の代わりに格納してもよい。
　図４は、一実施形態におけるリカバリテーブル３１０を生成するためのフローチャートを示している。図３を用いて説明したように、リカバリテーブル３１０は、ソフトウエア構成情報３００に基づいて生成されてもよい。
　ステップ４０２において、まず、ソフトウエア構成情報３００のエントリ数（ｎ）に基づいて、メモリ上にリカバリテーブル３１０の領域を取得する。
　ステップ４０４において、ソフトウエア構成情報３００の情報をリカバリテーブル３１０にコピーする。
　ステップ４０６において、リカバリテーブル３１０の先頭エントリ（第１のエントリ）を注目エントリとする。注目エントリとは、以下のステップを実行する対象のエントリを意味する。
　ステップ４０８において、注目エントリに対応するソフトウエアの要素の、メモリ上での先頭アドレスを取得し、開始アドレス３１４として登録する。なお、上述のように、開始アドレス３１４と領域長３１５から計算される終了アドレスを、領域長３１５の代わりに格納してもよい。
　ステップ１０において、注目エントリのリカバリルーチンのアドレスを修正する。リカバリルーチンのアドレスが、相対アドレスで表現されている場合には、ソフトウエア構成情報３００の先頭アドレスとリカバリテーブル３１０の先頭アドレスの差に基づいて、リカバリルーチンの相対アドレスを適切な値に修正する。或いは、リカバリルーチンのアドレスを適切な物理アドレスに設定してもよい。なお、リカバリルーチンのアドレスが絶対アドレスで表現されているのであれば、この修正は行う必要がない。
　ステップ４１２において、注目エントリが最終エントリか否かがチェックされる。このチェック結果が「はい」であれば、リカバリテーブルの全てのエントリの処理が終わったことを示しているため、処理を終了してもよい。このチェック結果が「いいえ」であれば、ステップ４１４に進む。
　ステップ４１４において、次のエントリを注目アドレスとする。そして、ステップ４０８に戻る。
　以上の処理によって、リカバリテーブル３１０が生成される。
　図５は、一実施形態におけるリカバリのフローチャートを示している。
　この処理は、メモリの障害のイベントを検知した割り込みにより起動されてもよい。
　ステップ５０２において、リカバリテーブル３１０の先頭のエントリを注目エントリとする。
　ステップ５０４において、障害アドレスが、注目エントリの領域特定情報（３１４，３１５）の中に含まれるか否かがチェックされる。このチェック結果が「はい」であれば、処理は、ステップ５０８に進む。このチェック結果が「いいえ」であれば、処理は、ステップ５０６に進む。
　ステップ５０８において、リカバリ可能か否かがチェックされる。このチェックは、リカバリテーブル３１０のリカバリ可否フラグを参照することによって、判断されてもよい。このチェック結果が「はい」であれば、処理は、ステップ５１０に移る。このチェック結果が「いいえ」であればステップ５２２に移る。
　ステップ５１０において、リカバリ手順の実行がなされる。リカバリ手順の具体例については、上記表１を用いて説明した。その後、処理は、ステップ５２１において終了する（終了１）。この場合には、リカバリが成功したため、ソフトウエアの本来の処理を続行することができる。
　ステップ５０６において、注目エントリが最終エントリであるか否かがチェックされる。このチェックが「はい」であれば、ステップ５２２に移る。チェック結果が「いいえ」であれば、ステップ５１２に移る。
　ステップ５２２において、処理は終了する（終了２）。この場合の終了は、リカバリが不成功に終わった場合に該当する。したがって、例えば、プログラムの再起動を行うことが望ましい。また、プログラムがハイパーバイザである場合には、ハイパーバイザ上で動作している全てのＯＳの再立ち上げを併せて行うことが望ましい。或いは、バックアップ又はスナップショットが保存されているシステムにおいては、これらを利用して、リストアを行い、メモリ障害の影響を最小限に止めることが望ましい。なお、本実施例では、終了２（ステップ５２２）に至る可能性を少なくし、リカバリを行うケースを増大させ、低コストでメモリ障害からのリカバリを行うことができるという利点がある。
　ステップ５１２において、リカバリテーブル３１０の次のエントリを注目エントリとする。そして、処理はステップ５１４に戻る。
　図６は、一実施形態の機能ブロック図を示している。
　一実施形態のシステムは、リカバリテーブル生成部６０２、障害検知部６２０、障害位置特定部６３０、リカバリ特定部６４０、リカバリ実行部６５０、ソフトウエア構成情報３００、及びリカバリテーブル３１０を有する。
　リカバリテーブル生成部６０２は、ソフトウエア構成情報３００に基づいて、リカバリテーブル３１０を生成してもよい。また、リカバリテーブル生成部６０２は、リカバリテーブル更新部６１０を更に含んでもよい。ソフトウエアが更新された場合には、ソフトウエア構成情報３００も併せて更新されることが望ましい。そして、リカバリテーブル更新部６１０は、ソフトウエアが更新された場合に、更新されたソフトエア構成情報３００に基づいて、リカバリテーブルを更新する。
　障害検知部６２０は、メモリの障害を検知し、割り込みを発生させてもよい。或いは、ソフトウエア（例：ハイパーバイザ）自身がＣＲＣチェックを行い、メモリ障害を検出してもよい。メモリ障害の検出は、障害位置特定部６３０に伝達されてもよい。
　障害位置特定部６３０は、障害の発生したメモリ位置を特定する。或いは、障害の発生しているアドレスを含むメモリ領域が検出されてもよい。検出された障害位置は、リカバリ特定部６４０に送られる。
　リカバリ特定部６４０は、障害位置を用いて、リカバリテーブル３１０を検索し、リカバリ手順３１６を特定する。また、リカバリ特定部６４０は、リカバリ可否判断部６４２及び固定障害認定部６４６を含んでもよい。リカバリ可否判断部６４２は、故障位置を用いてリカバリテーブル３１０を検索した際に、リカバリ可否フラグ３１８を参照し、リカバリの可否を判断する。リカバリが可能であれば、特定されたリカバリの情報をリカバリ実行部６５０に渡す。また、固定障害認定部６４６は、所定の回数同じメモリアドレスで障害が発生したか否かをチェックする。メモリの固定障害が認定された場合には、後述のように代替メモリ領域の割当が代替メモリ割当部６５２で行われる。メモリの固定障害ではない場合（間欠障害）と判定された場合には、障害の検出されたアドレスのメモリは、その後も利用されてもよい。リカバリ実行部６５０は、特定されたリカバリ手順を実行する。リカバリ手順３１６は、リカバリルーチンにより実行されてもよい。リカバリ実行部６５０は、代替メモリ割当部６５２を含んでもよい。代替メモリ領域が割り当てられた場合には、リカバリテーブル３１０の開始アドレス３１４（及び終了アドレス）を更新することが望ましい。そして、代替メモリ領域が割り当てられた後に、リカバリの実行を行う。
　図７は、一実施形態におけるリカバリルーチンの処理を示す図である。リカバリのためのリカバリルーチンの数は、最大で、リカバリテーブルのエントリ数（ｎ）だけ存在してもよい。表１に示すように、リカバリのタイプの数だけ、リカバリルーチンを用意してもよい。この場合、リカバリルーチンの数は、ｎよりも少なくなる。
　ステップ７０２において、リカバリテーブルのリカバリ手順に記憶されているリカバリルーチンアドレスに基づいて、リカバリルーチンに処理を分岐させる。図７には、リカバリルーチン１（７１２）、リカバリルーチン３（７１４）、及びリカバリルーチンｎ（７１６）が示されている。
　図８（Ａ）は、一実施形態におけるリカバリテーブルの例を示す図である。リカバリ手順８１６には、リカバリのタイプに応じて、リカバリタイプ１（８６２）、リカバリタイプ２（８６４）、及びリカバリタイプ３（８６６）のリカバリルーチンのアドレスが格納されてもよい。或いは、リカバリルーチンのアドレスに代えて、リカバリのタイプを識別する情報が格納されてもよい。この識別する情報を用いて、適切なリカバリ手順を実行すればよい。なお、リカバリテーブルの領域ＩＤ８１２、開始アドレス８１４、領域長８１５，リカバリフラグ８１８は、図３（Ｂ）と同じである。
　図８（Ｂ）は、一実施形態におけるリカバリルーチンの処理を示す図である。
　ステップ８５２において、リカバリタイプに応じたリカバリルーチンアドレスの指定が行われる。リカバリ手順８１６にリカバリルーチンのアドレスが設定されている場合には、そのアドレスに基づいて、リカバリタイプ１のリカバリルーチン（８６２）、リカバリタイプ２のリカバリルーチン（８６４）、リカバリタイプ３のリカバリルーチン（８６６）のいずれかに、処理を分岐させればよい。或いは、リカバリ手順８１６にリカバリタイプが設定されている場合には、リカバリタイプに応じて、リカバリタイプ１のリカバリルーチン（８６２）、リカバリタイプ２のリカバリルーチン（８６４）、リカバリタイプ３のリカバリルーチン（８６６）のいずれかに、処理を分岐させればよい。
　図９は、ソフトエアのアップデートの際のリカバリテーブルの更新の例を示す図である。ソフトウエアが更新された場合には、ソフトエアの構成が変化するため、リカバリテーブルを更新することが望ましい。
　ステップ９０２において、ソフトウエアのアップデートがなされる。
　ステップ９０４において、ソフトウエアのアップデートに適合させて、ソフトウエア構成情報３００の更新を行う。なお、ソフトウエアのアップデートの際にソフトウエア構成情報３００の更新が同時になされてもよい。
　ステップ９０６において、ソフトウエアのアップデートに応じてリカバリテーブル３１０の更新を行う。なお、リカバリテーブル３１０の更新において、リカバリテーブルの容量が増える場合には、新たにリカバリテーブル３１０の領域確保を行い、リカバリテーブル３１０を再度生成し直してもよい。
　図１０は、一実施形態のハードウエアの構成を示す図である。ハードウエアは、ＣＰＵ１００２、メモリ１００４、入出力装置１００６、表示装置１００８、ハードディスク１０１０、記録媒体駆動装置１０１２、が含まれる。そして、それぞれの機器は、バス１０１６によって接続されている。また、記録媒体駆動装置１０１２は、可搬記録媒体１０１４を読み書きすることができる。
　本ハードウエアは、図６に示す各機能が実装されてもよい。また、本ハードウエアによって、図面に記した各フローチャートの処理が実行されてもよい。
　なお、本実施形態の全部又は一部はプログラムによってインプリメントされ得る。このプログラムは、可搬記録媒体１０１４に格納することができる。可搬記録媒体１０１４とは、構造（ｓｔｒｕｃｔｕｒｅ）を有する１つ以上の非一時的（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）な、有形（ｔａｎｇｉｂｌｅ）な、記録媒体を言う。例示として、可搬記録媒体１０１４としては、磁気記録媒体、光ディスク、光磁気記録媒体、不揮発性メモリなどがある。磁気記録媒体には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ（ＭＴ）などがある。光ディスクには、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ－Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＣＤ－Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）などがある。また、光磁気記録媒体には、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ　ｄｉｓｋ）などがある。可搬型記録媒体に格納されたプログラムが読み込まれ、プロセッサによって実行されることにより、本発明の実施形態の全部又は一部が実施され得る。
　図１１は、一実施形態のメモリ構成を示す図である。図１１に示すメモリ１１００は、メモリの所定のメモリサイズ単位毎にキー情報１１５０を設定できるサーバアーキテクチャを採用している。例えば、メモリ単位１１０１には、キー情報１１５１が対応している。また、メモリ単位１１０７には、キー情報１１５７が対応している。例えば、キー情報１１５０に、リカバリテーブル３１０の対応する領域ＩＤ３１２を格納してもよい。この場合、例えば、メモリ単位１１０１においてメモリ障害が発生した場合、対応するキー情報１１５１に格納されている領域ＩＤ３１２を取得してもよい。この取得された領域ＩＤ３１２から、リカバリテーブル３１０を検索し、対応するリカバリ手順３１６を取得してもよい。

Claims (24)

  1. 　メモリに障害が発生した場合に、前記メモリに存在するソフトウエアのリカバリを行う装置であって、
    　前記ソフトウエアがロードされた複数のメモリ領域の各々に対応させて、リカバリ手順を定めたリカバリテーブルを生成する、リカバリテーブル生成部と、
    　障害の位置を特定する、障害位置特定部と、
    　前記リカバリテーブルを用いて、前記障害の位置を含むメモリ領域に対応したリカバリ手順を特定する、リカバリ特定部と、
    　前記特定されたリカバリ手順を実行する、リカバリ実行部と、
    　を有する装置。
  2. 　前記リカバリテーブルは、前記リカバリ手順を実行するリカバリルーチンの実行アドレスを含む、請求項１記載の装置。
  3. 　前記リカバリテーブル生成部は、前記ソフトウエアが更新された場合に、前記リカバリテーブルを更新する、リカバリテーブル更新部を含む、請求項１又は２記載の装置。
  4. 　前記リカバリテーブルは、複数のメモリ領域の各々に対応させて、リカバリが可能か否かを表す情報を含む、請求項１ないし３のうちいずれか１項記載の装置。
  5. 　前記リカバリ特定部は、同一のメモリ領域において、障害が所定の回数発生した場合に、前記メモリ領域を固定障害と認定する、固定障害認定部を含み、
    　前記リカバリ実行部は、前記固定障害認定部の認定した前記メモリ領域に対する代替メモリ領域を、前記ソフトウエアに割り当てる、代替メモリ割当部を含み、前記代替メモリ領域を割り当てた後に、前記リカバリ手順を実行する、
    　請求項１ないし４のうちいずれか１項記載の装置。
  6. 　前記リカバリ特定部は、
    　前記メモリ領域を識別する情報を、前記メモリの所定のサイズのメモリの各々に設けられたメモリ情報保存部に格納することにより、前記所定のサイズのメモリにおいて障害が発生した場合、障害の発生した所定のサイズのメモリに対応する前記メモリ情報保存部に格納された前記メモリ領域を識別する情報を用いて、前記リカバリテーブルを検索することにより、対応するリカバリ手順を特定する、請求項１ないし５のうちいずれか１項記載の装置。
  7. 　前記ソフトウエアは、ハイパーバイザである、請求項１ないし６のうちいずれか１項記載の装置。
  8. 　前記リカバリ手順は、前記ソフトウエアとは異なる他のコンポーネントから情報を取得する、請求項１ないし７のうちいずれか１項記載の装置。
  9. 　メモリに障害が発生した場合に、前記メモリに存在するソフトウエアのリカバリを行う方法であって、
    　前記ソフトウエアがロードされた複数のメモリ領域の各々に対応させて、リカバリ手順を定めたリカバリテーブルを生成し、
    　障害の位置を特定し、
    　前記リカバリテーブルを用いて、前記障害の位置を含むメモリ領域に対応したリカバリ手順を特定し、
    　前記特定されたリカバリ手順を実行する、
    　処理を有する方法。
  10. 　前記リカバリテーブルは、前記リカバリ手順を実行するリカバリルーチンの実行アドレスを含む、請求項９記載の方法。
  11. 　前記リカバリテーブルを生成する処理は、前記ソフトウエアが更新された場合に、前記リカバリテーブルを更新する処理を含む、請求項９又は１０記載の方法。
  12. 　前記リカバリテーブルは、複数のメモリ領域の各々に対応させて、リカバリが可能か否かを表す情報を含む、請求項９ないし１１のうちいずれか１項記載の方法。
  13. 　前記リカバリ手順を特定する処理は、同一のメモリ領域において、障害が所定の回数発生した場合に、前記メモリ領域を固定障害と認定する処理を含み、
    　前記リカバリ手順を実行する処理は、前記固定障害を認定する処理が認定した前記メモリ領域に対する代替メモリ領域を、前記ソフトウエアに割り当てる処理を含み、前記代替メモリ領域を割り当てた後に、前記リカバリ手順を実行する、
    　請求項９ないし１２のうちいずれか１項記載の方法。
  14. 　前記リカバリ手順を特定する処理は、
    　前記メモリ領域を識別する情報を、前記メモリの所定のサイズのメモリの各々に設けられたメモリ情報保存部に格納することにより、前記所定のサイズのメモリにおいて障害が発生した場合、障害の発生した所定のサイズのメモリに対応する前記メモリ情報保存部に格納された前記メモリ領域を識別する情報を用いて、前記リカバリテーブルを検索することにより、対応するリカバリ手順を特定する、請求項９ないし１３のうちいずれか１項記載の方法。
  15. 　前記ソフトウエアは、ハイパーバイザである、請求項９ないし１４のうちいずれか１項記載の方法。
  16. 　前記リカバリ手順は、前記ソフトウエアとは異なる他のコンポーネントから情報を取得する、請求項９ないし１５のうちいずれか１項記載の方法。
  17. 　メモリに障害が発生した場合に、前記メモリに存在するソフトウエアのリカバリを行う方法であって、
    　前記ソフトウエアがロードされた複数のメモリ領域の各々に対応させて、リカバリ手順を定めたリカバリテーブルを生成し、
    　障害の位置を特定し、
    　前記リカバリテーブルを用いて、前記障害の位置を含むメモリ領域に対応したリカバリ手順を特定し、
    　前記特定されたリカバリ手順を実行する、
    　処理をコンピュータに実行させるプログラム。
  18. 　前記リカバリテーブルは、前記リカバリ手順を実行するリカバリルーチンの実行アドレスを含む、請求項１７記載のプログラム。
  19. 　前記リカバリテーブルを生成する処理は、前記ソフトウエアが更新された場合に、前記リカバリテーブルを更新する処理を含む、請求項１７又は１８記載のプログラム。
  20. 　前記リカバリテーブルは、複数のメモリ領域の各々に対応させて、リカバリが可能か否かを表す情報を含む、請求項１７ないし１９のうちいずれか１項記載のプログラム。
  21. 　前記リカバリ手順を特定する処理は、同一のメモリ領域において、障害が所定の回数発生した場合に、前記メモリ領域を固定障害と認定する処理を含み、
    　前記リカバリ手順を実行する処理は、前記固定障害を認定する処理が認定した前記メモリ領域に対する代替メモリ領域を、前記ソフトウエアに割り当てる処理を含み、前記代替メモリ領域を割り当てた後に、前記リカバリ手順を実行する、
    　請求項１７ないし２０のうちいずれか１項記載のプログラム。
  22. 　前記リカバリ手順を特定する処理は、
    　前記メモリ領域を識別する情報を、前記メモリの所定のサイズのメモリの各々に設けられたメモリ情報保存部に格納することにより、前記所定のサイズのメモリにおいて障害が発生した場合、障害の発生した所定のサイズのメモリに対応する前記メモリ情報保存部に格納された前記メモリ領域を識別する情報を用いて、前記リカバリテーブルを検索することにより、対応するリカバリ手順を特定する、請求項１７ないし２１のうちいずれか１項記載のプログラム。
  23. 　前記ソフトウエアは、ハイパーバイザである、請求項１７ないし２２のうちいずれか１項記載のプログラム。
  24. 　前記リカバリ手順は、前記ソフトウエアとは異なる他のコンポーネントから情報を取得する、請求項１７ないし２３のうちいずれか１項記載のプログラム。
PCT/JP2012/070250 2012-08-08 2012-08-08 メモリ障害リカバリ装置、方法、及びプログラム WO2014024279A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/070250 WO2014024279A1 (ja) 2012-08-08 2012-08-08 メモリ障害リカバリ装置、方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/070250 WO2014024279A1 (ja) 2012-08-08 2012-08-08 メモリ障害リカバリ装置、方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2014024279A1 true WO2014024279A1 (ja) 2014-02-13

Family

ID=50067560

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/070250 WO2014024279A1 (ja) 2012-08-08 2012-08-08 メモリ障害リカバリ装置、方法、及びプログラム

Country Status (1)

Country Link
WO (1) WO2014024279A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017091497A (ja) * 2015-11-09 2017-05-25 エーオー カスペルスキー ラボＡＯ Ｋａｓｐｅｒｓｋｙ Ｌａｂ ハイパーバイザモードにおけるコードの安全な実行システムおよび方法
CN111630550A (zh) * 2018-01-02 2020-09-04 斯纳普公司 生成具有异步媒体内容的交互式消息
JP2021108174A (ja) * 2020-05-29 2021-07-29 ベイジン バイドゥ ネットコム サイエンス アンド テクノロジー カンパニー リミテッド メモリ故障処理の方法、装置、電子機器及び記憶媒体

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05265876A (ja) * 1992-03-19 1993-10-15 Fujitsu Ltd エラー報告処理方式
JPH10222757A (ja) * 1997-02-07 1998-08-21 Tec Corp 商品販売データ処理装置
JP2011238278A (ja) * 2011-07-22 2011-11-24 Hitachi Ltd 仮想計算機の制御方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05265876A (ja) * 1992-03-19 1993-10-15 Fujitsu Ltd エラー報告処理方式
JPH10222757A (ja) * 1997-02-07 1998-08-21 Tec Corp 商品販売データ処理装置
JP2011238278A (ja) * 2011-07-22 2011-11-24 Hitachi Ltd 仮想計算機の制御方法

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017091497A (ja) * 2015-11-09 2017-05-25 エーオー カスペルスキー ラボＡＯ Ｋａｓｐｅｒｓｋｙ Ｌａｂ ハイパーバイザモードにおけるコードの安全な実行システムおよび方法
US10162964B2 (en) 2015-11-09 2018-12-25 AO Kaspersky Lab System and method for protection of memory pages using a hypervisor
US11269996B2 (en) 2015-11-09 2022-03-08 AO Kaspersky Lab System and method for protecting memory pages
CN111630550A (zh) * 2018-01-02 2020-09-04 斯纳普公司 生成具有异步媒体内容的交互式消息
CN111630550B (zh) * 2018-01-02 2024-03-12 斯纳普公司 生成具有异步媒体内容的交互式消息
JP2021108174A (ja) * 2020-05-29 2021-07-29 ベイジン バイドゥ ネットコム サイエンス アンド テクノロジー カンパニー リミテッド メモリ故障処理の方法、装置、電子機器及び記憶媒体
JP7168833B2 (ja) 2020-05-29 2022-11-10 ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッド メモリ故障処理の方法、装置、電子機器及び記憶媒体

Similar Documents

Publication Publication Date Title
US8666938B1 (en) Installed application cloning and failover to virtual server
JP5715566B2 (ja) キャッシュデータおよびメタデータの管理
JP4363676B2 (ja) コンピュータシステム
KR101994811B1 (ko) 전자 장치, ｍｂｒ 복원 방법 및 컴퓨터 판독가능 기록매체
JP4903244B2 (ja) 計算機システム及び障害復旧方法
US9507671B2 (en) Write cache protection in a purpose built backup appliance
US9053064B2 (en) Method for saving virtual machine state to a checkpoint file
JP2011060055A (ja) 仮想計算機システム、仮想マシンの復旧処理方法及びそのプログラム
JP2014530393A (ja) 不揮発性媒体のダーティー領域追跡
JP5786955B2 (ja) メモリ縮退方法及び情報処理装置
KR20140118093A (ko) 메모리 가상화 기반 스냅샷 부트 장치 및 방법
US9977740B2 (en) Nonvolatile storage of host and guest cache data in response to power interruption
US10503620B1 (en) Parity log with delta bitmap
US11803412B2 (en) Containerized application management system and management method
US7574621B2 (en) Method and system for identifying and recovering a file damaged by a hard drive failure
WO2022193768A1 (zh) 内存读写指令的执行方法及计算设备
US20090013167A1 (en) Computer device, method for booting the same, and booting module for the same
KR101999617B1 (ko) 전자 장치, ｇｐｔ 복원 방법 및 컴퓨터 판독가능 기록매체
WO2014024279A1 (ja) メモリ障害リカバリ装置、方法、及びプログラム
CN105549985A (zh) 一种增强Linux应用系统可靠性的方法与系统
US9959278B1 (en) Method and system for supporting block-level incremental backups of file system volumes using volume pseudo devices
JP6802484B2 (ja) ストレージ制御装置、ストレージ制御プログラムおよびストレージ制御方法
US20140372806A1 (en) Virtual machine system and information storing processing method
US20160004607A1 (en) Information processing apparatus and information processing method
US10592329B2 (en) Method and electronic device for continuing executing procedure being aborted from physical address where error occurs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12882666

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014529198

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12882666

Country of ref document: EP

Kind code of ref document: A1