A method and device for repairing and restoring an operating system

Abstract

The present invention provides an operating system repair and recovery method and device, which are applied to a cluster environment. The method includes: deploying a control node, a working node and a standby node in a cluster; the control node is connected to the working node and the standby node respectively; the working node is used to run user services, and the standby node is a standby working node; in response to a working node failure, the faulty node is determined; the control node schedules the standby node as the working node and repairs the faulty node; after the faulty node is repaired, the control node schedules the repaired faulty node as a standby node. The method provided by the scheme reduces the interruption time of services and data when a fault occurs in a cluster environment, improves the repair and recovery efficiency, and ensures the safe and effective operation of the operating system.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an operating system repair and recovery method and device. Background Art

[0002] In the application scenarios of the prior art, the user terminal needs to install the operating system before it can be used by the user. After the operating system is installed on the terminal device, in order to ensure the normal operation of the user's business, it is also necessary to make disaster recovery reserves in the data, business software and operating environment to reduce the interruption time and loss of business and data. However, for the damaged system environment, different systems have different priorities and different repair methods. When using a virtual environment, existing large-scale business systems often use the snapshot function provided by the virtual engine for backup and recovery. However, due to performance requirements, such business systems will use the operating system on the host server and associate it to arrange it into a computing cluster to meet business needs while reducing performance loss; once such a system environment is damaged, it is necessary to reinstall the operating system, and perform business configuration, data recovery and other processes. In addition, in a cluster environment, it is impossible to reinstall the system on a single machine with a damaged operating system kernel, which will result in a longer interruption time and higher losses when a failure occurs. Summary of the invention

[0003] The present invention provides an operating system repair and recovery method and device, which reduces the interruption time of business and data when a failure occurs in a cluster environment, improves the repair and recovery efficiency, and ensures the safe and effective operation of the operating system.

[0004] In a first aspect, the present invention provides an operating system repair and recovery method, which is applied to a cluster environment and comprises:

[0005] A control node, a working node and a standby node are deployed in the cluster; the control node is connected to the working node and the standby node respectively; the working node is used to run user services, and the standby node is a standby working node;

[0006] In response to a failure of the working node, determining a failed node;

[0007] The control node schedules the standby node as the working node and repairs the faulty node;

[0008] After the faulty node is repaired, the control node schedules the repaired faulty node as the standby node.

[0009] Optionally, the repairing the faulty node includes:

[0010] The control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node;

[0011] The control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal, and the faulty node recovers based on the received first rescue recovery instruction and updates the recovery identifier of the faulty node in real time;

[0012] After sending the rescue recovery instruction, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current state of the faulty node;

[0013] The control node determines whether the faulty node has been repaired according to the current state and the recovery flag.

[0014] Optionally, the control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal, the faulty node recovers based on the received first rescue recovery instruction, and updates a recovery identifier of the faulty node in real time, including:

[0015] The control node sends the first rescue recovery instruction to the faulty node based on the preparation completion signal;

[0016] The faulty node enters the recovery preparation phase, the target IP address configuration phase, and the recovery phase in sequence based on the received first rescue recovery instruction; wherein the target IP address is the same as the IP address of the control node;

[0017] Among them, the recovery preparation phase includes, in sequence, restarting the system, entering the rescue mode, adding a recovery flag and setting a first recovery status code of the recovery flag, wherein the first recovery status code is used to indicate that the faulty node is in recovery; the recovery phase includes, in sequence, mounting NFS based on the mounting external kernel, restoring the system, rolling back the relevant business files to the last backup before the failure, and setting a second recovery status code of the recovery flag, wherein the second recovery status code is used to indicate that the faulty node has been repaired.

[0018] Optionally, after sending the rescue recovery instruction, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current state of the faulty node, including:

[0019] After the faulty node is configured with the target IP address, the control node establishes a connection with the faulty node based on the connection request and obtains the recovery identifier;

[0020] The current state of the faulty node is determined according to the recovery identifier and the connection state between the control node and the faulty node.

[0021] Optionally, the control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node, including:

[0022] The external kernel adopts the rescue mode of the faulty node and takes the rescue mode as the first priority startup mode; and determines whether the faulty node has a recovery mark, and if so, removes the recovery mark, and the faulty node feeds back a preparation completion signal to the control node.

[0023] Optionally, the control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node, including:

[0024] The external kernel uses an external device, and after the faulty node mounts the external device, it feeds back a preparation completion signal to the control node.

[0025] Optionally, the control node scheduling the faulty node that has completed repair as the standby node includes:

[0026] After the faulty node is repaired, the control node sends a second rescue and recovery instruction to the faulty node;

[0027] The faulty node restarts the system based on the received second rescue and recovery instruction, and schedules the restarted faulty node as the standby node.

[0028] In a second aspect, the present invention provides an operating system repair and recovery device, which is applied to a cluster environment and includes:

[0029] A deployment module, used to deploy a control node, a working node and a standby node in a cluster; the control node is connected to the working node and the standby node respectively; the working node is used to run user services, and the standby node is a standby working node;

[0030] A detection and repair module is used to determine the faulty node when a fault is detected in the working node; schedule the standby node as the working node based on the control node and repair the faulty node; and after the faulty node is repaired, the control node schedules the repaired faulty node as the standby node.

[0031] In a third aspect, an embodiment of the present invention further provides a computing device, comprising a memory and a target processor, wherein the memory stores a computer program, and when the target processor executes the computer program, the method described in any first aspect of this specification is implemented.

[0032] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, enables the computer to execute the method described in any first aspect of this specification.

[0033] In a fifth aspect, an embodiment of the present invention further provides a computer program product, comprising computer instructions, which, when executed by a processor, implement the steps of the method described in any first aspect of this specification.

[0034] The present invention provides an operating system repair and recovery method and device, which is applied in a cluster environment. By deploying a control node, a working node and a standby node for running user services in the cluster environment, when a working node sends a fault and becomes a faulty node, the control node schedules the standby node as a working node for continuing to run the user service, and repairs the faulty node. After the faulty node is repaired, the control node schedules the repaired faulty node as a standby node. In this way, redundant standby nodes always exist in the cluster environment of the present invention. Once a faulty node appears, it is immediately replaced by the standby node to ensure the safe operation of the entire cluster service in time, thereby reducing the interruption time of the service and data and improving the recovery efficiency; at the same time, the control node actively repairs the faulty node to avoid affecting the safety and controllability of the recovery work due to the instability of the faulty node itself. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0036] Figure 1 is a flow chart of an operating system repair and recovery method provided by an embodiment of the present invention;

[0037] Figure 2 is a hardware architecture diagram of a computing device provided by an embodiment of the present invention;

[0038] Figure 3 The present invention is a schematic diagram of the structure of an operating system repair and recovery device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0040] like Figure 1 As shown, an embodiment of the present invention provides an operating system repair and recovery method, which is applied to a cluster environment. The method includes:

[0041] Step 100, deploying a control node, a working node and a standby node in a cluster; the control node is connected to the working node and the standby node respectively; the working node is used to run user services, and the standby node is a standby working node;

[0042] Step 102, in response to a working node failure, determining a failed node;

[0043] Step 104, the control node schedules the standby node as the working node and repairs the faulty node;

[0044] Step 106: After the faulty node is repaired, the control node schedules the repaired faulty node as a standby node.

[0045] In the present invention, firstly, a control node, a working node and a standby node for running user services are deployed in a cluster environment. When a working node sends a fault and becomes a faulty node, the control node schedules the standby node as a working node for continuing to run the user service and repairs the faulty node. After the faulty node is repaired, the control node schedules the repaired faulty node as a standby node. In this way, redundant standby nodes always exist in the cluster environment of the present invention. Once a faulty node appears, it is immediately replaced by a standby node to ensure the safe operation of the entire cluster service in a timely manner, thereby reducing the interruption time of services and data and improving recovery efficiency. At the same time, the control node actively repairs the faulty node to avoid affecting the safety and controllability of the recovery work due to the instability of the faulty node itself.

[0046] It should be noted that the number of control nodes is at least one, and the control node is used to schedule working nodes, backup nodes and faulty nodes. It is also used to detect whether a working node has a fault, and when a working node has a fault, schedule it as a faulty node; and schedule a backup node as a working node to repair the faulty node; and schedule a repaired faulty node as a backup node, thereby realizing a cyclic scheduling of working node-faulty node-backup node-working node.

[0047] For step 100, the control node, the working node, and the standby node can all be virtual machines or physical machines. In the cluster environment provided by the present invention, the nodes are in a redundant state, and the working node is located in the working cluster of the business network, the standby node is located in the node resource pool of the internal network, the faulty node is located in the faulty node processing area of ​​the internal network, and the control node is located in the management network, so that different nodes are isolated using different network domains to achieve the purpose of data security. Therefore, in this cluster environment, the standby node is first dispatched from the node resource pool of the internal network to the working cluster to run the user business, and the standby node is dispatched as a working node. Once the working node is found to be abnormal, the abnormal working node is determined as a faulty node and returned to the faulty node processing area, and a new standby node is dispatched as a working node. At the same time, the faulty node is repaired, and rejoined to the node resource pool after the repair is completed. This cycle ensures that the entire cluster runs safely and stably.

[0048] With respect to step 102, when the control node detects that an abnormality occurs in a working node, it determines that a fault occurs in the working node and determines it as a faulty node.

[0049] With respect to step 104, repairing the faulty node includes:

[0050] The control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a readiness completion signal to the control node;

[0051] The control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal, and the faulty node recovers based on the received first rescue recovery instruction and updates the recovery identifier of the faulty node in real time;

[0052] After sending the rescue and recovery command, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current status of the faulty node;

[0053] The control node determines whether the faulty node has been repaired based on the current status and recovery flag.

[0054] It should be noted that the recovery flag is used to indicate the repair status of the faulty node.

[0055] In the present invention, after the control node sends the mounted external kernel corresponding to the faulty node, the faulty node performs recovery preparations and feeds back a preparation completion signal to the faulty node. After the control node receives the preparation completion signal fed back by the faulty node, it can make a manual judgment or it can be automatically triggered based on the customer equipment environment security level and actual needs to send a first rescue recovery instruction to the faulty node. After receiving the first rescue instruction, the faulty node recovers and updates the recovery identifier of the faulty node in real time, so that when the control node sends a connection request and the connection is successful, the recovery identifier and current status of the faulty node can be obtained in real time, thereby further determining whether the faulty node has been repaired.

[0056] In a preferred embodiment, in step 104, the control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node, including two methods:

[0057] The first method: the external kernel adopts the rescue mode of the faulty node and takes the rescue mode as the first priority startup mode; and determines whether the faulty node has a recovery flag. If so, the recovery flag is removed, and the faulty node feeds back a preparation completion signal to the control node.

[0058] The second method: The external kernel uses an external device. After the faulty node mounts the external device, it feeds back a readiness completion signal to the control node.

[0059] It should be noted that when the first method is adopted, the faulty node can still run basic functions, for example, the basic functions may include at least one of network connection, data transmission, system upgrade, etc. Specifically, the faulty node switches grube to select rescue mode as the first priority startup item, and removes the recovery flag if a recovery flag is found.

[0060] In the present invention, when the second method is adopted, the faulty node cannot be turned on due to severe damage, and its system kernel file or even boot file is damaged, so it is necessary to directly mount the prepared basic kernel externally as the basic system of the rescue mode to support the system components. At the same time, since the upper-layer application of the system is closed in the rescue mode at this time, but the application configuration and data are all there, the workload of restoring data can still be greatly reduced. At the same time, since the second method mounts the pre-prepared virtual device as the running kernel of the recovery process, it will occupy the virtual recovery node resources and is limited to use in severe damage scenarios.

[0061] In a preferred embodiment, in step 104, the control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal, and the faulty node recovers based on the received first rescue recovery instruction and updates the recovery identifier of the faulty node in real time, including:

[0062] The control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal;

[0063] Based on the received first rescue recovery instruction, the faulty node enters the recovery preparation phase, the target IP address configuration phase, and the recovery phase in sequence; wherein the target IP address is the same as the IP address of the control node;

[0064] Among them, the recovery preparation stage includes restarting the system, entering the rescue mode, adding a recovery flag and setting the first recovery status code of the recovery flag. The first recovery status code is used to indicate that the faulty node is in recovery; the recovery stage includes mounting NFS based on mounting the external kernel, restoring the system, rolling back the relevant business files that were last backed up before the failure, and setting the second recovery status code of the recovery flag. The second recovery status code is used to indicate that the faulty node has been repaired.

[0065] Specifically, for the first method of mounting an external kernel, after the faulty node receives the first rescue recovery instruction, the system is restarted. Since the rescue mode has been configured as the first priority startup mode before, it will enter the rescue mode by default after waiting for the input time. At this time, the operating system only runs the most basic functions, and most application functions are closed to ensure that the recovery process will not cause abnormal recovery due to the running of business software. It should be noted that after setting the recovery flag, the first recovery status code and the second recovery status code are assigned according to the specified fault recovery status code.

[0066] In a preferred embodiment, in step 104, after sending the rescue recovery instruction, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current state of the faulty node, including:

[0067] After the target IP address is configured on the faulty node, the control node establishes a connection with the faulty node based on the connection request and obtains the recovery identifier;

[0068] The current state of the failed node is determined based on the recovery identifier and the connection state between the control node and the failed node.

[0069] In the present invention, the target IP address is configured only after the faulty node is restarted. When the target IP address is configured successfully, a connection channel between the control node and the faulty node can be established based on the connection request. At this time, the control node can obtain the recovery identifier, and then determine the current status of the faulty node based on the recovery identifier and the current connection status of the two, so that users can know the repair progress of the faulty node in real time.

[0070] In step 106, the control node schedules the repaired faulty node as a standby node, including:

[0071] After the faulty node is repaired, the control node sends a second rescue recovery instruction to the faulty node;

[0072] The faulty node restarts the system based on the received second rescue and recovery instruction, and schedules the restarted faulty node as a standby node.

[0073] In the present invention, after the faulty node is repaired, the system needs to be restarted again. After the restart, it means that the faulty node has been started and can be put into use again. At this time, the repaired faulty node after restart is included in the standby node, and the recovery mark is deleted.

[0074] In a preferred embodiment, the control node periodically sends a connection request to the faulty node after sending the rescue and recovery instruction, and the current status of the faulty node obtained includes the following six situations:

[0075] The first type: After the control node periodically sends a connection request, it cannot connect to the faulty node within the timeout period. This may be because the target IP address is not configured, and the current status of the faulty node is starting. The control node needs to connect again after the next connection interval.

[0076] The second type: after the control node periodically sends a connection request, it cannot connect to the faulty node within the timeout period. The faulty node is not configured with a target IP address, and the current state of the faulty node is abnormal startup. The control node needs to send a shutdown command to the faulty node and use the second method of mounting an external kernel to repair it again.

[0077] The third type: After the control node periodically sends a connection request, it successfully connects to the faulty node, but fails to find the recovery flag. The faulty node may not have entered the rescue mode, and may not have placed the recovery flag. The current state of the faulty node is that it has not entered the recovery phase normally. The control node needs to send a shutdown command to the faulty node and use the second method of mounting an external kernel to repair it again.

[0078] Fourth: After periodically sending connection requests, the control node successfully connects to the faulty node and obtains a recovery identifier as the first recovery status code; the current status of the faulty node is recovering, the control node turns off the timeout, and continues to periodically send connection requests, and obtains the recovery identifier after connecting to the faulty node again in the next connection interval;

[0079] The fifth type: after the control node periodically sends a connection request, it successfully connects to the faulty node and obtains the recovery identifier as the second recovery status code, but the timer is not started; the current status of the faulty node is that the file recovery work is completed but not restarted. The control node needs to issue a restart instruction (i.e., the second rescue recovery instruction) and obtain the recovery identifier after connecting to the faulty node again in the next connection interval;

[0080] The sixth type: After periodically sending connection requests, the control node successfully connects to the faulty node, obtains the recovery identifier as the second recovery status code, and starts its own timer; then the current status of the faulty node is to complete the recovery work. The control node needs to convert the node into a backup node and put it into the node resource pool, and delete the recovery identifier at the same time.

[0081] In the present invention, the entire repair and recovery process is completed by the control node, including the current state of the faulty node and normal repair actions. It does not actively communicate with the outside world at all, but is acquired by the control node passively by placing a recovery identifier. This can avoid the entire process from affecting the safety and controllability of the recovery work due to the instability of the faulty node itself. In other words, the present invention treats the faulty node of the full recovery cycle as a "static file that cannot perform any function", which is actively detected by the control node, and its possible current state is judged from different results, and corresponding measures are taken.

[0082] In the present invention, a method of restoring upper-layer applications, configurations or data in rescue mode is used instead of creating nodes to import backed-up data, which greatly reduces the workload caused by full copying of data, thereby speeding up the node recovery response time, and further providing better conditions and lower node reserve costs for reducing the recovery time objective (RPO) and recovery point objective (RPO) of user business systems.

[0083] In a specific embodiment, an operating system repair and recovery method includes:

[0084] Step 200: deploying a control node, a working node, and a standby node in the cluster; the control node is connected to the working node and the standby node respectively; the working node is used to run user services, and the standby node is a standby working node;

[0085] Step 201: In response to a working node failing, determining a failed node;

[0086] Step 202: The control node sends the mounted external kernel corresponding to the faulty node to the faulty node. The external kernel adopts the rescue mode of the faulty node and takes the rescue mode as the first priority startup mode. It is also determined whether there is a recovery flag on the faulty node. If so, the recovery flag is removed, and the faulty node feeds back a preparation completion signal to the control node.

[0087] or,

[0088] The control node sends the external kernel corresponding to the faulty node to the faulty node. The external kernel uses an external device. After mounting the external device, the faulty node feeds back a ready completion signal to the control node.

[0089] Step 203: The control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal; based on the received first rescue recovery instruction, the faulty node sequentially enters the recovery preparation phase (in sequence including restarting the system, entering the rescue mode, adding a recovery flag and setting a first recovery status code of the recovery flag), configuring the target IP address and the recovery phase (in sequence including mounting NFS based on mounting the external kernel, restoring the system, rolling back to the last backup of the relevant business files before the failure and setting a second recovery status code of the recovery flag);

[0090] At the same time, after sending the rescue recovery command, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current status of the faulty node; after the faulty node is configured with the target IP address, the control node establishes a connection with the faulty node based on the connection request and obtains the recovery identifier; according to the recovery identifier and the connection status between the control node and the faulty node, the current status of the faulty node is determined;

[0091] The target IP address is the same as the IP address of the control node; the first recovery status code is used to indicate that the faulty node is recovering; the second recovery status code is used to indicate that the faulty node has been repaired;

[0092] Step 204: when the recovery identifier is the second recovery status code and the control node is successfully connected to the faulty node, it is determined that the faulty node has been repaired;

[0093] Step 205: the control node sends a second rescue recovery instruction to the faulty node; the faulty node restarts the system based on the received second rescue recovery instruction, schedules the restarted faulty node as a standby node, and deletes the recovery flag.

[0094] like Figure 2 , Figure 3 As shown, an embodiment of the present invention provides an operating system repair and recovery device. The device embodiment can be implemented by software, or by hardware or a combination of software and hardware. From the hardware level, Figure 2 As shown in FIG. 1 , a hardware architecture diagram of a computing device where an operating system repair and recovery device provided by an embodiment of the present invention is located is shown in FIG. Figure 2 In addition to the processor, memory, network interface, and non-volatile memory shown in the figure, the computing device in which the device is located in the embodiment may also generally include other hardware, such as a forwarding chip responsible for processing messages, etc. Taking software implementation as an example, Figure 3 As shown, as a device in a logical sense, the CPU of the computing device in which it is located reads the corresponding computer program in the non-volatile memory into the memory and runs it. This embodiment provides an operating system repair and recovery device, which includes:

[0095] A deployment module 300, used to deploy a control node, a working node and a standby node in a cluster; the control node is connected to the working node and the standby node respectively; the working node is used to run user services, and the standby node is a standby working node;

[0096] The detection and repair module 302 is used to determine the faulty node when a fault is detected in the working node; schedule the backup node as the working node based on the control node and repair the faulty node; and after the faulty node is repaired, the control node schedules the repaired faulty node as the backup node.

[0097] In some specific implementations, the deployment module 300 may be used to execute the above step 100 , and the detection and repair 302 may be used to execute the above steps 102 to 106 .

[0098] In one embodiment of the present invention, the detection and repair module 302 is further configured to perform the following operations:

[0099] The control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node;

[0100] The control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal, and the faulty node recovers based on the received first rescue recovery instruction and updates the recovery identifier of the faulty node in real time;

[0101] After sending the rescue recovery instruction, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current state of the faulty node;

[0102] The control node determines whether the faulty node has been repaired according to the current state and the recovery flag.

[0103] In one embodiment of the present invention, the detection and repair module 302 is further configured to perform the following operations:

[0104] The control node sends the first rescue recovery instruction to the faulty node based on the preparation completion signal;

[0105] The faulty node enters the recovery preparation phase, the target IP address configuration phase, and the recovery phase in sequence based on the received first rescue recovery instruction; wherein the target IP address is the same as the IP address of the control node;

[0106] Among them, the recovery preparation phase includes, in sequence, restarting the system, entering the rescue mode, adding a recovery flag and setting a first recovery status code of the recovery flag, wherein the first recovery status code is used to indicate that the faulty node is in recovery; the recovery phase includes, in sequence, mounting NFS based on the mounting external kernel, restoring the system, rolling back the relevant business files to the last backup before the failure, and setting a second recovery status code of the recovery flag, wherein the second recovery status code is used to indicate that the faulty node has been repaired.

[0107] In one embodiment of the present invention, the detection and repair module 302 is further configured to perform the following operations:

[0108] After the faulty node is configured with the target IP address, the control node establishes a connection with the faulty node based on the connection request and obtains the recovery identifier;

[0109] The current state of the faulty node is determined according to the recovery identifier and the connection state between the control node and the faulty node.

[0110] In one embodiment of the present invention, the detection and repair module 302 is further configured to perform the following operations:

[0111] The external kernel adopts the rescue mode of the faulty node and takes the rescue mode as the first priority startup mode; and determines whether the faulty node has a recovery flag, and if so, removes the recovery flag, and the faulty node feeds back a preparation completion signal to the control node;

[0112] or,

[0113] The external kernel uses an external device, and after the faulty node mounts the external device, it feeds back a preparation completion signal to the control node.

[0114] In one embodiment of the present invention, the detection and repair module 302 is further configured to perform the following operations:

[0115] After the faulty node is repaired, the control node sends a second rescue and recovery instruction to the faulty node;

[0116] The faulty node restarts the system based on the received second rescue and recovery instruction, and schedules the restarted faulty node as the standby node.

[0117] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on an operating system repair and recovery device. In other embodiments of the present invention, an operating system repair and recovery device may include more or fewer components than those illustrated, or combine certain components, or split certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0118] The information interaction, execution process and other contents between the modules in the above-mentioned device are based on the same concept as the embodiment of the method of the present invention. For specific contents, please refer to the description in the embodiment of the method of the present invention, and no further description is given here.

[0119] An embodiment of the present invention further provides a computing device, including a memory and a target processor, wherein a computer program is stored in the memory, and when the target processor executes the computer program, an operating system repair and recovery method in any embodiment of the present invention is implemented.

[0120] An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the processor executes an operating system repair and recovery method in any embodiment of the present invention.

[0121] An embodiment of the present application also provides a computer program product, which includes a computer program. A processor of a computer device reads the computer program from a computer-readable storage medium, and the processor executes the computer program, so that the computer device executes an operating system repair and recovery method described in any of the above embodiments.

[0122] Specifically, a system or device equipped with a storage medium can be provided, on which software program code that implements the functions of any of the above-mentioned embodiments is stored, and a computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.

[0123] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.

[0124] The storage medium embodiments for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Alternatively, the program code can be downloaded from a server computer by a communication network.

[0125] In addition, it should be clear that the functions of any of the above embodiments can be implemented not only by executing the program code read by the computer, but also by enabling the operating system on the computer to complete part or all of the actual operations based on the instructions of the program code.

[0126] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or to a memory provided in an expansion module connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or expansion module is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned embodiments.

[0127] It should be noted that, in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical factors in the process, method, article or device including the elements.

[0128] A person of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiments can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiments; and the aforementioned storage medium includes: ROM, RAM, magnetic disk or optical disk, etc., various media that can store program codes.

[0129] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for repairing and restoring an operating system, characterized in that: Applicable to cluster environments, including: A control node, a working node and a standby node are deployed in the cluster; the control node is connected to the working node and the standby node respectively; the working node is used to run user services, and the standby node is a standby working node; In response to a failure of the working node, determining a failed node; The control node schedules the standby node as the working node and repairs the faulty node; After the faulty node is repaired, the control node schedules the repaired faulty node as the standby node; The repairing of the faulty node includes: The control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node; The control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal, and the faulty node recovers based on the received first rescue recovery instruction and updates the recovery identifier of the faulty node in real time; After sending the rescue recovery instruction, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current state of the faulty node; The control node determines whether the faulty node has been repaired according to the current state and the recovery flag.

2. The method according to claim 1, characterized in that The control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal, and the faulty node recovers based on the received first rescue recovery instruction and updates the recovery identifier of the faulty node in real time, including: The control node sends the first rescue recovery instruction to the faulty node based on the preparation completion signal; The faulty node enters the recovery preparation phase, the target IP address configuration phase, and the recovery phase in sequence based on the received first rescue recovery instruction; wherein the target IP address is the same as the IP address of the control node; Among them, the recovery preparation phase includes, in sequence, restarting the system, entering the rescue mode, adding a recovery flag and setting a first recovery status code of the recovery flag, wherein the first recovery status code is used to indicate that the faulty node is in recovery; the recovery phase includes, in sequence, mounting NFS based on the mounting external kernel, restoring the system, rolling back the relevant business files to the last backup before the failure, and setting a second recovery status code of the recovery flag, wherein the second recovery status code is used to indicate that the faulty node has been repaired.

3. The method according to claim 2, characterized in that After sending the rescue recovery instruction, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current state of the faulty node, including: After the faulty node is configured with the target IP address, the control node establishes a connection with the faulty node based on the connection request and obtains the recovery identifier; The current state of the faulty node is determined according to the recovery identifier and the connection state between the control node and the faulty node.

4. The method according to claim 1, characterized in that: The control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node, including: The external kernel adopts the rescue mode of the faulty node and takes the rescue mode as the first priority startup mode; and determines whether the faulty node has a recovery mark, and if so, removes the recovery mark, and the faulty node feeds back a preparation completion signal to the control node.

5. The method according to claim 1, characterized in that: The control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node, including: The external kernel uses an external device, and after the faulty node mounts the external device, it feeds back a preparation completion signal to the control node.

6. The method according to any one of claims 1 to 5, characterized in that: The control node scheduling the repaired faulty node as the standby node includes: After the faulty node is repaired, the control node sends a second rescue and recovery instruction to the faulty node; The faulty node restarts the system based on the received second rescue and recovery instruction, and schedules the restarted faulty node as the standby node.

7. An operating system repair and recovery device, characterized in that: Applicable to cluster environments, including: A deployment module, used to deploy a control node, a working node and a standby node in a cluster; the control node is connected to the working node and the standby node respectively; the working node is used to run user services, and the standby node is a standby working node; A detection and repair module, configured to determine a faulty node when a fault is detected in the working node; schedule the standby node as the working node based on the control node, and repair the faulty node; and after the faulty node is repaired, schedule the repaired faulty node as the standby node by the control node; The detection and repair module is also used to perform the following operations: The control node sends the mounted external kernel corresponding to the faulty node to the faulty node, and the faulty node feeds back a preparation completion signal to the control node; The control node sends a first rescue recovery instruction to the faulty node based on the preparation completion signal, and the faulty node recovers based on the received first rescue recovery instruction and updates the recovery identifier of the faulty node in real time; After sending the rescue recovery instruction, the control node periodically sends a connection request to the faulty node to obtain the recovery identifier and the current state of the faulty node; The control node determines whether the faulty node has been repaired according to the current state and the recovery flag.

8. A computing device, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that The method comprises computer instructions, which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 6.

Images