Fault-tolerant implementation method and device for redundancy of whole server

Abstract

The invention discloses a fault-tolerant implementation method and device for server whole machine redundancy, and relates to the technical field of servers. The method comprises the steps that when a first operation state changes, the first operation state is sent to a second subsystem for state synchronization, and when the second operation state changes, the second operation state is sent to a first subsystem for state synchronization; when the first subsystem does not receive the second running state beyond the preset duration, the second subsystem is changed to be in downtime, and the first shadow virtual machine is changed to be in the running state; or when the second subsystem does not receive the first running state beyond the preset duration, the first subsystem is changed to be down, and the second shadow virtual machine is changed to be in the running state. The technical problems that in the prior art, system operation is interrupted and shutdown maintenance is needed due to key component faults are solved, automatic switching under the key component fault condition is achieved, the continuity of system operation is ensured, and the technical effect that service stability is affected by shutdown maintenance is avoided.

Description

Technical Field

[0001] The present invention relates to the technical field of servers, and in particular to a fault-tolerant implementation method and device for server whole machine redundancy. Background Art

[0002] In modern server systems, as the business demands for high availability and continuity continue to increase, the system's fault tolerance and redundancy design have become key technologies. However, when key components of existing server systems fail, they often need to be shut down for maintenance or replacement, and the continuous operation of the system cannot be guaranteed. Especially in data centers or critical application scenarios, a brief interruption of the server system may have a serious impact on the stability and reliability of the business. Therefore, how to achieve rapid switching and seamless recovery through an effective fault tolerance mechanism when a system fails to ensure the high availability of the system and the continuity of the business has become an important problem in the existing technology. Summary of the invention

[0003] The present application provides a fault-tolerant implementation method and device for server whole machine redundancy, which solves the technical problem in the prior art that failure of key components leads to interruption of system operation and requires shutdown for maintenance.

[0004] In view of the above problems, the present application provides a method and device for implementing fault-tolerant redundancy of a server.

[0005] In a first aspect of the present application, a fault-tolerant implementation method for server whole machine redundancy is provided, the method comprising:

[0006] The first operating state of the first subsystem is collected through the first fault-tolerant management component of the first subsystem; the second operating state of the second subsystem is collected through the second fault-tolerant management component of the second subsystem; when the first operating state changes, the first operating state is sent to the second subsystem through the first subsystem for state synchronization, and when the second operating state changes, the second operating state is sent to the first subsystem through the second subsystem for state synchronization; when the first subsystem does not receive the second operating state for more than a preset time, the second subsystem is changed to downtime, and the first shadow virtual machine of the first subsystem is changed to operating state; or when the second subsystem does not receive the first operating state for more than the preset time, the first subsystem is changed to downtime, and the second shadow virtual machine of the second subsystem is changed to operating state; wherein, only one of the first virtual machine component and the second virtual machine component is in operating state at the same time, and the virtual machine component that is not in operating state is the shadow virtual machine.

[0007] A second aspect of the present application provides a fault-tolerant implementation device for server whole machine redundancy, the device comprising:

[0008] First state acquisition unit: collects the first operating state of the first subsystem through the first fault-tolerant management component of the first subsystem; second state acquisition unit: collects the second operating state of the second subsystem through the second fault-tolerant management component of the second subsystem; state synchronization unit: when the first operating state changes, the first operating state is sent to the second subsystem through the first subsystem for state synchronization; when the second operating state changes, the second operating state is sent to the first subsystem through the second subsystem for state synchronization; first state change unit: when the first subsystem does not receive the second operating state for more than a preset time, the second subsystem is changed to a downtime, and the first shadow virtual machine of the first subsystem is changed to a running state; second state change unit: or when the second subsystem does not receive the first operating state for more than the preset time, the first subsystem is changed to a downtime, and the second shadow virtual machine of the second subsystem is changed to a running state.

[0009] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0010] First, the first operating state of the first subsystem is collected through the first fault-tolerant management component of the first subsystem; and the second operating state of the second subsystem is collected through the second fault-tolerant management component of the second subsystem. Then, when the first operating state changes, the first operating state is sent to the second subsystem through the first subsystem for state synchronization, and when the second operating state changes, the second operating state is sent to the first subsystem through the second subsystem for state synchronization. Finally, when the first subsystem fails to receive the second operating state for more than a preset time, the second subsystem is changed to downtime, and the first shadow virtual machine of the first subsystem is changed to a running state; or when the second subsystem fails to receive the first operating state for more than a preset time, the first subsystem is changed to downtime, and the second shadow virtual machine of the second subsystem is changed to a running state; wherein, only one component of the first virtual machine component and the second virtual machine component is in a running state at the same time, and the virtual machine component that is not in a running state is a shadow virtual machine. The technical problem that the failure of key components in the prior art causes the interruption of system operation and requires shutdown for maintenance is solved, and automatic switching under the condition of failure of key components is realized, so as to ensure the continuity of system operation and avoid the technical effect of shutdown for maintenance affecting business stability. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] Figure 1 A flow chart of a method for implementing fault-tolerant server redundancy provided in an embodiment of the present application;

[0013] Figure 2 A schematic diagram of the structure of a fault-tolerant implementation device for server whole machine redundancy provided in an embodiment of the present application;

[0014] Figure 3 A schematic diagram of the structure of the first subsystem provided in an embodiment of the present application;

[0015] Figure 4 A logical structure diagram of a fault-tolerant implementation method for server redundancy provided in an embodiment of the present application.

[0016] Description of the accompanying drawings: first state acquisition unit 11, second state acquisition unit 12, state synchronization unit 13, first state change unit 14, second state change unit 15, first software module 31, first hardware module 32, first virtual machine component 33. DETAILED DESCRIPTION

[0017] The present application solves the technical problem in the prior art that failure of key components causes system operation interruption and requires shutdown for maintenance by providing a fault-tolerant implementation method and device for server whole machine redundancy.

[0018] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0019] It should be noted that the terms "including" and "having" are intended to cover non-exclusive inclusions. For example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules that are not explicitly listed or are inherent to these processes, methods, products or devices.

[0020] Embodiment 1, as Figure 1As shown, the present application provides a fault-tolerant implementation method for server whole machine redundancy, which is applied to a fault-tolerant implementation device for server whole machine redundancy, such as Figure 4 As shown, the device includes a first subsystem and a second subsystem, the first subsystem and the second subsystem are the same, the first subsystem has a first virtual machine component, the second subsystem has a second virtual machine component, the first subsystem and the second subsystem are connected via a direct path, wherein the method includes:

[0021] A first operating state of the first subsystem is collected through a first fault-tolerant management component of the first subsystem.

[0022] Through the first fault-tolerant management component of the first subsystem, the first operating status of the first subsystem is collected and monitored in real time, including but not limited to key operating parameters such as the processor load, memory usage, network connection status and fault indication signal of the subsystem, to ensure timely acquisition of its current status information and provide data support for subsequent status synchronization and fault switching.

[0023] Furthermore, collecting a first operating state of the first subsystem through a first fault-tolerant management component of the first subsystem includes:

[0024] The first subsystem includes a first software module, a first hardware module and a first virtual machine component; the first fault-tolerant management component collects the running status of the first hardware module, the running status of the first virtual machine component and the running status of the first software module; and the running status of the first hardware module, the running status of the first virtual machine component and the running status of the first software module are added to the first running status.

[0025] like Figure 3 As shown, the first subsystem includes a first software module, a first hardware module and a first virtual machine component. The first software module runs on the first hardware module. The first software module is responsible for managing and controlling the configuration information of all virtual machines running on the fault-tolerant server system, starting and stopping operations, etc.; the first hardware module includes physical hardware such as CPU, memory, disk, network interface card, etc., which is the physical basis for the operation of the subsystem; the first virtual machine component refers to the virtualization component running in the first subsystem, which is usually a virtual machine or containerized operating environment. The main function of the virtual machine component is to provide an isolated operating environment to ensure that it can switch to the shadow virtual machine when a fault occurs, so as to achieve seamless fault recovery and fault-tolerant operation.

[0026] The first fault-tolerant management component is the core module in the server's redundant fault-tolerant system. It is responsible for real-time monitoring and management of the operating status of the first subsystem, and triggering the corresponding fault-tolerant and switching mechanisms when an abnormality or failure is detected to ensure the stability and high availability of the system.

[0027] The first fault-tolerant management component collects the operating status of the first hardware module (including but not limited to power status, temperature, processor load, memory usage and network connection status to determine the stability of the hardware level and whether there are any abnormalities), the operating status of the first virtual machine component (the working status of the virtual machine, resource allocation status and whether the virtual machine is in active or standby status) and the operating status of the first software module (the health status of the operating system, the startup status of key services and abnormal log records); the above-collected operating status of the first hardware module, the operating status of the first virtual machine component and the operating status of the first software module are unified and integrated into the first operating status as the current comprehensive status information of the first subsystem, which is used for subsequent state synchronization, fault detection and fault-tolerant processing and other operations.

[0028] A second operating state of the second subsystem is collected through a second fault-tolerant management component of the second subsystem.

[0029] Through the second fault-tolerant management component of the second subsystem, the second operating status of the second subsystem, including status information of hardware modules, virtual machine components and software modules, is collected and monitored in real time to ensure that the current operating status of the subsystem is synchronized with the first subsystem and provide data support for fault switching.

[0030] When the first operating state changes, the first operating state is sent to the second subsystem through the first subsystem for state synchronization; when the second operating state changes, the second operating state is sent to the first subsystem through the second subsystem for state synchronization.

[0031] In order to ensure the real-time status consistency between the first subsystem and the second subsystem, a two-way status synchronization mechanism is set up. When the operating status of any subsystem changes, the changed status information will be immediately synchronized to the other subsystem through the corresponding fault-tolerant management component to achieve synchronous status update.

[0032] Specifically, when the operating state of the first subsystem changes (such as abnormal temperature of the hardware module, virtual machine switching or software service restart, etc.), the first fault-tolerant management component will capture the change immediately; the first fault-tolerant management component will send the updated first operating state data to the second subsystem through a direct path; after receiving the first operating state sent by the first subsystem, the second fault-tolerant management component of the second subsystem will immediately update the first operating state information recorded internally to keep it consistent with the state of the first subsystem. When the operating state of the second subsystem changes (such as hardware failure, network anomaly or virtual machine state change), the second fault-tolerant management component will monitor the state change; the second fault-tolerant management component will send the updated second operating state data to the first subsystem through a direct path; after receiving the second operating state sent by the second subsystem, the first fault-tolerant management component of the first subsystem will also update its internal second operating state information to ensure that the states of the two subsystems are synchronized.

[0033] Furthermore, when the first operating state changes, it includes:

[0034] Obtain a first status information log of the first subsystem, wherein the first status information log includes an initial operating state; when the first operating state is different from the initial operating state, it is deemed that the first operating state has changed; when the first operating state is the same as the initial operating state, it is deemed that the first operating state has not changed.

[0035] When the system is started or reset, the current operating state of the first subsystem is recorded as the initial operating state. The initial operating state usually includes the hardware state, virtual machine state, and initial state of the software module when the system is started, and is a benchmark for comparison. The first state information log is used to track the state changes of the first subsystem, including the current state of the hardware, virtual machine, and software. The initial operating state of the first subsystem is extracted from the first state information log; after each new first operating state is collected, the state is compared with the initial operating state to identify whether the state has changed; if the current first operating state is inconsistent with the initial operating state, it is deemed that the first operating state has changed, which may include hardware failure, significant changes in resource load, virtual machine switching, or software module abnormalities; if the current first operating state is consistent with the initial operating state, it is deemed that the first operating state has not changed.

[0036] Further, sending the first operating state to the second subsystem for state synchronization through the first subsystem includes:

[0037] When the second subsystem receives the first operating status, it updates the second status information log according to the first operating status; and simultaneously performs status synchronization according to the first operating status.

[0038] Optionally, when the first subsystem detects that its first operating state has changed, it will immediately send the updated first operating state to the second subsystem. The fault-tolerant management component of the second subsystem is responsible for receiving the transmission data and confirming successful reception to ensure the accuracy and timeliness of state synchronization. After receiving the first operating state, the fault-tolerant management component of the second subsystem will record the state data in the second state information log of the second subsystem; while updating the state information log, the second subsystem will synchronize its own related state data based on the received first operating state to keep the state consistent with that of the first subsystem.

[0039] Further, sending the first operating state to the second subsystem for state synchronization through the first subsystem includes:

[0040] Obtain the target operating state of the server; when the first operating state is different from the target operating state of the server, change the first virtual machine component of the first subsystem to a shutdown state; at the same time, send a first subsystem stop service signal to the second subsystem through the first subsystem, and when the second subsystem receives the first subsystem stop service signal, change the second shadow virtual machine of the second subsystem to a running state.

[0041] The server target operating state is the standard operating state that the system should maintain under normal circumstances, including the health and stability parameters of hardware, virtual machines, and software modules. The server target operating state is usually pre-set as a benchmark for judging whether the current operating state is abnormal.

[0042] After the first subsystem detects a change in its first operating state, it will compare the state with the server target operating state to determine whether the current operating state meets the normal operating requirements. If the first operating state is consistent with the server target operating state, the system will continue to operate normally without any change operations; when it is detected that the first operating state is different from the server target operating state, it means that the first subsystem may have a fault or deviate from the normal operating standard, and the fault tolerance mechanism needs to be triggered. The fault tolerance management component of the first subsystem will switch the first virtual machine component of the first subsystem to a shutdown state to avoid continuing to operate in an abnormal state and prevent further damage to the stability of the system; in the shutdown state, the first virtual machine component stops providing services to the outside, but its shadow virtual machine component will be activated in subsequent steps to ensure that the service is not interrupted. After changing the first virtual machine component to the shutdown state, the first subsystem sends a stop service signal to the second subsystem through the fault tolerance management component to inform the second subsystem that it is about to stop service and needs to take over. The stop service signal will be sent through a direct connection path and accompanied by a confirmation mechanism to ensure that the second subsystem receives the shutdown notification of the first subsystem. After receiving the stop service signal from the first subsystem, the fault-tolerant management component of the second subsystem confirms that the first subsystem can no longer provide services and needs to be taken over; after confirming that the first subsystem is shut down, the second subsystem immediately changes its second shadow virtual machine to a running state, thereby taking over the services of the first subsystem to ensure that the business is not affected.

[0043] Furthermore, when the first operating state is different from the target operating state of the server, changing the first virtual machine component of the first subsystem to a shutdown state further includes:

[0044] When the first operating state is different from the server target operating state, and the operating state deviation coefficient between the first operating state and the server target operating state is less than or equal to the operating state deviation coefficient threshold, the first operating state is sent to the second subsystem through the first subsystem for state synchronization; when the first operating state is different from the server target operating state, and the operating state deviation coefficient between the first operating state and the server target operating state is greater than the operating state deviation coefficient threshold, the first virtual machine component of the first subsystem is changed to a shutdown state.

[0045] The operation state deviation coefficient is used to quantify the difference between the first operation state and the target operation state of the server. The operation state deviation coefficient can be obtained by analyzing multiple indicators (such as hardware load, resource utilization, error rate, etc.) and performing weighted calculation. The deviation coefficient threshold is used to distinguish between normal deviation and severe deviation of the operation state.

[0046] When it is detected that the first running state is different from the server target running state, but the running state deviation coefficient is less than or equal to the state deviation coefficient threshold, it means that although there is a deviation, it has not reached a serious level, and the operation and synchronization state can continue. When it is detected that the deviation coefficient between the first running state and the server target running state exceeds the state deviation coefficient threshold, it means that the system deviation is large and there may be serious abnormalities or failures. At this time, the first virtual machine component of the first subsystem needs to be stopped immediately to protect the stability of the system.

[0047] When the deviation coefficient is less than or equal to the state deviation coefficient threshold, the first subsystem will not shut down immediately, but will send the current first operating state to the second subsystem through the state synchronization mechanism to ensure that the second subsystem synchronizes the mild abnormal state. When the deviation coefficient exceeds the state deviation coefficient threshold, the system determines that the abnormality is more serious, and the first fault-tolerant management component will immediately switch the first virtual machine component of the first subsystem to a shutdown state to prevent the abnormal state from further affecting the normal operation of the system; after the first virtual machine component is shut down, the first subsystem sends a stop service signal to the second subsystem, notifying the second subsystem to start its shadow virtual machine and take over the running task to achieve fast fault-tolerant switching.

[0048] Further, sending the first operating state to the second subsystem for state synchronization through the first subsystem includes:

[0049] The virtual disk file I / O status of the first virtual machine component is collected through the first fault-tolerant management component; the memory page I / O status of the first virtual machine component is collected through the first fault-tolerant management component; the virtual disk file I / O status and the memory page I / O status are sent to the second subsystem through the first subsystem and written into the second virtual machine component.

[0050] Optionally, the first fault-tolerant management component monitors the virtual disk file I / O status of the first virtual machine component in real time in the first subsystem, including key performance indicators such as disk read and write rate, read and write delay, and the number of currently ongoing read and write operations; the collected virtual disk I / O status data is extracted and recorded so that it can be transmitted to the second subsystem for synchronization at any time. The first fault-tolerant management component also collects the memory page I / O status of the first virtual machine component, which includes the page swapping status of the virtual machine memory, the memory read and write operation rate, and the allocation and release of memory pages. After collecting the virtual disk file I / O status and memory page I / O status, the first subsystem sends these data to the second subsystem through the status synchronization mechanism; after receiving the virtual disk file I / O status transmitted by the first subsystem, the second subsystem applies the status data to the second virtual machine component; the second subsystem also writes the memory page I / O status of the first virtual machine to the second virtual machine component.

[0051] By synchronizing the virtual disk file I / O status and the memory page I / O status, the second virtual machine component can accurately reflect the current running status of the first virtual machine in the second subsystem. In this way, when the first virtual machine component fails or shuts down, the shadow virtual machine component of the second subsystem can immediately take over and run seamlessly.

[0052] Furthermore, it also includes:

[0053] After the first subsystem receives the second subsystem service stop signal from the second subsystem, when the first subsystem receives the second operating state again, the first subsystem performs state synchronization according to the second operating state.

[0054] When the first subsystem receives a stop service signal from the second subsystem, it means that the virtual machine component of the second subsystem will be shut down, and the service status will be taken over by the first subsystem; after receiving the stop service signal from the second subsystem, the first subsystem will record the shutdown status of the second subsystem and ensure that the virtual machine component of the first subsystem is in the main running state to seamlessly take over the system service. After receiving the stop service signal, the first subsystem will continue to monitor the running status of the second subsystem and wait for the second running status update from the second subsystem; when the first subsystem receives the second running status again, the fault-tolerant management component of the first subsystem will synchronize the status based on the status information, thereby updating the first subsystem's record of the latest running status of the second subsystem to restore and maintain the state consistency of the dual systems.

[0055] When the first subsystem does not receive the second operating status for more than a preset period of time, the second subsystem is changed to a downtime state, and the first shadow virtual machine of the first subsystem is changed to a running state.

[0056] The first subsystem sets a preset duration to monitor the interval time for receiving the operating status from the second subsystem; when the first subsystem has not received the latest operating status from the second subsystem after the preset duration, the first fault-tolerant management component determines that the second subsystem may have failed; in the case of timeout detection, the first subsystem marks the second subsystem as down, which means that the second subsystem is no longer active and can no longer provide services. In order to ensure that the service is not interrupted, the fault-tolerant management component of the first subsystem will change the first shadow virtual machine to the main operating state; the shadow virtual machine was previously in a standby state and will only be activated when the main virtual machine is unavailable. After activation, the shadow virtual machine will immediately take over the service, thereby ensuring the continuity of the system and the integrity of the data, so that external users or services will hardly perceive the system failure.

[0057] or when the second subsystem does not receive the first operating state for more than the preset time, the first subsystem is changed to downtime, and the second shadow virtual machine of the second subsystem is changed to operating state;

[0058] A preset duration is set in the second subsystem to monitor the time interval for receiving the operating status from the first subsystem; when the second subsystem fails to receive the latest operating status from the first subsystem within the preset duration, the second fault-tolerant management component will determine that the first subsystem may have a fault; in the case of timeout detection, the second subsystem marks the first subsystem as downtime, indicating that the first subsystem is no longer active and cannot provide services normally. In order to avoid service interruption, the fault-tolerant management component of the second subsystem will change the second shadow virtual machine to the main operating state. The second shadow virtual machine is in the standby state under normal circumstances. It is automatically activated when the failure of the first subsystem is detected. The shadow virtual machine immediately takes over the system service after switching to the operating state to ensure business continuity.

[0059] Among them, only one of the first virtual machine component and the second virtual machine component is in a running state at the same time, and the virtual machine component that is not in a running state is a shadow virtual machine.

[0060] Only one of the first virtual machine component and the second virtual machine component is in operation at any time, while the other component is in standby state, namely, the shadow virtual machine. Specifically, under normal circumstances, only one virtual machine component (namely, the first virtual machine component or the second virtual machine component) is in the main operation state and is responsible for providing all services and operation tasks to the outside world; the other virtual machine component is in the shadow virtual machine state, namely, the standby state. The shadow virtual machine does not participate in the current operation task, but is in standby state, ready to take over the service at any time. This configuration ensures that when any virtual machine in the system fails, the shadow virtual machine can be activated immediately, ensuring seamless switching and high availability of the system.

[0061] In summary, the embodiments of the present application have at least the following technical effects:

[0062] First, the first operating state of the first subsystem is collected through the first fault-tolerant management component of the first subsystem; and the second operating state of the second subsystem is collected through the second fault-tolerant management component of the second subsystem. Then, when the first operating state changes, the first operating state is sent to the second subsystem through the first subsystem for state synchronization, and when the second operating state changes, the second operating state is sent to the first subsystem through the second subsystem for state synchronization. Finally, when the first subsystem fails to receive the second operating state for more than a preset time, the second subsystem is changed to downtime, and the first shadow virtual machine of the first subsystem is changed to a running state; or when the second subsystem fails to receive the first operating state for more than a preset time, the first subsystem is changed to downtime, and the second shadow virtual machine of the second subsystem is changed to a running state; wherein, only one component of the first virtual machine component and the second virtual machine component is in a running state at the same time, and the virtual machine component that is not in a running state is a shadow virtual machine. The technical problem that the failure of key components in the prior art causes the interruption of system operation and requires shutdown for maintenance is solved, and automatic switching under the condition of failure of key components is realized, so as to ensure the continuity of system operation and avoid the technical effect of shutdown for maintenance affecting business stability.

[0063] Embodiment 2 is based on the same inventive concept as the fault-tolerant implementation method for server whole machine redundancy in the above embodiment. Figure 2 As shown, the present application provides a fault-tolerant implementation device for server whole machine redundancy, wherein the device includes:

[0064] The first state acquisition unit 11: collects the first operating state of the first subsystem through the first fault-tolerant management component of the first subsystem; the second state acquisition unit 12: collects the second operating state of the second subsystem through the second fault-tolerant management component of the second subsystem; the state synchronization unit 13: when the first operating state changes, the first operating state is sent to the second subsystem through the first subsystem for state synchronization; when the second operating state changes, the second operating state is sent to the first subsystem through the second subsystem for state synchronization; the first state change unit 14: when the first subsystem does not receive the second operating state for more than a preset time, the second subsystem is changed to a downtime, and the first shadow virtual machine of the first subsystem is changed to a running state; the second state change unit 15: or when the second subsystem does not receive the first operating state for more than the preset time, the first subsystem is changed to a downtime, and the second shadow virtual machine of the second subsystem is changed to a running state.

[0065] Furthermore, the first state acquisition unit 11 is used to execute the following method:

[0066] The first subsystem includes a first software module, a first hardware module and a first virtual machine component; the first fault-tolerant management component collects the running status of the first hardware module, the running status of the first virtual machine component and the running status of the first software module; and the running status of the first hardware module, the running status of the first virtual machine component and the running status of the first software module are added to the first running status.

[0067] Furthermore, the state synchronization unit 13 is used to execute the following method:

[0068] Obtain a first status information log of the first subsystem, wherein the first status information log includes an initial operating state; when the first operating state is different from the initial operating state, it is deemed that the first operating state has changed; when the first operating state is the same as the initial operating state, it is deemed that the first operating state has not changed.

[0069] Furthermore, the state synchronization unit 13 is used to execute the following method:

[0070] When the second subsystem receives the first operating status, it updates the second status information log according to the first operating status; and simultaneously performs status synchronization according to the first operating status.

[0071] Furthermore, the state synchronization unit 13 is used to execute the following method:

[0072] Obtain the target operating state of the server; when the first operating state is different from the target operating state of the server, change the first virtual machine component of the first subsystem to a shutdown state; at the same time, send a first subsystem stop service signal to the second subsystem through the first subsystem, and when the second subsystem receives the first subsystem stop service signal, change the second shadow virtual machine of the second subsystem to a running state.

[0073] Furthermore, the state synchronization unit 13 is used to execute the following method:

[0074] When the first operating state is different from the server target operating state, and the operating state deviation coefficient between the first operating state and the server target operating state is less than or equal to the operating state deviation coefficient threshold, the first operating state is sent to the second subsystem through the first subsystem for state synchronization; when the first operating state is different from the server target operating state, and the operating state deviation coefficient between the first operating state and the server target operating state is greater than the operating state deviation coefficient threshold, the first virtual machine component of the first subsystem is changed to a shutdown state.

[0075] Furthermore, the state synchronization unit 13 is used to execute the following method:

[0076] The virtual disk file I / O status of the first virtual machine component is collected through the first fault-tolerant management component; the memory page I / O status of the first virtual machine component is collected through the first fault-tolerant management component; the virtual disk file I / O status and the memory page I / O status are sent to the second subsystem through the first subsystem and written into the second virtual machine component.

[0077] Furthermore, the state synchronization unit 13 is used to execute the following method:

[0078] After the first subsystem receives the second subsystem service stop signal from the second subsystem, when the first subsystem receives the second operating state again, the first subsystem performs state synchronization according to the second operating state.

[0079] It should be noted that the above-mentioned sequence of the embodiments of the present application is only for description and does not represent the advantages and disadvantages of the embodiments. And the above-mentioned specific embodiments of this specification are described. The processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0080] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

[0081] This specification and drawings are merely exemplary illustrations of the present application and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, a person skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the present application and its equivalents, the present application intends to include these modifications and variations.

Claims

1. A fault-tolerant implementation method for server whole machine redundancy, characterized in that: A fault-tolerant implementation device for server whole machine redundancy, the device comprising a first subsystem and a second subsystem, the first subsystem and the second subsystem being identical, the first subsystem having a first virtual machine component, the second subsystem having a second virtual machine component, the first subsystem and the second subsystem being connected via a direct path, comprising: collecting a first operating state of the first subsystem through a first fault-tolerant management component of the first subsystem; collecting a second operating state of the second subsystem through a second fault-tolerant management component of the second subsystem; When the first operating state changes, the first operating state is sent to the second subsystem through the first subsystem for state synchronization; when the second operating state changes, the second operating state is sent to the first subsystem through the second subsystem for state synchronization; When the first subsystem does not receive the second operating state for more than a preset period of time, the second subsystem is changed to a downtime state, and the first shadow virtual machine of the first subsystem is changed to a running state; or when the second subsystem does not receive the first operating state for more than the preset time, the first subsystem is changed to downtime, and the second shadow virtual machine of the second subsystem is changed to operating state; Among them, only one of the first virtual machine component and the second virtual machine component is in a running state at the same time, and the virtual machine component that is not in a running state is a shadow virtual machine.

2. The fault-tolerant implementation method for server whole machine redundancy according to claim 1, characterized in that: Collecting a first operating state of the first subsystem through a first fault-tolerant management component of the first subsystem includes: The first subsystem includes a first software module, a first hardware module and a first virtual machine component; Collecting the running status of the first hardware module, the running status of the first virtual machine component and the running status of the first software module through the first fault-tolerant management component; The first hardware module running state, the first virtual machine component running state and the first software module running state are added into the first running state.

3. The fault-tolerant implementation method for server whole machine redundancy according to claim 1, characterized in that: When the first operating state changes, it includes: Obtaining a first state information log of the first subsystem, wherein the first state information log includes an initial operating state; When the first operating state is different from the initial operating state, it is considered that the first operating state has changed; When the first operating state is the same as the initial operating state, it is considered that the first operating state has not changed.

4. The fault-tolerant implementation method for server whole machine redundancy according to claim 2, characterized in that: Sending the first operating state to the second subsystem through the first subsystem for state synchronization includes: When the second subsystem receives the first operating status, updating a second status information log according to the first operating status; At the same time, state synchronization is performed according to the first operating state.

5. The fault-tolerant implementation method for server whole machine redundancy according to claim 4, characterized in that: Sending the first operating state to the second subsystem through the first subsystem for state synchronization includes: Get the server target running status; When the first operating state is different from the target operating state of the server, changing the first virtual machine component of the first subsystem to a shutdown state; At the same time, a first subsystem service stop signal is sent to the second subsystem through the first subsystem. When the second subsystem receives the first subsystem service stop signal, the second shadow virtual machine of the second subsystem is changed to a running state.

6. The fault-tolerant implementation method for server whole machine redundancy according to claim 5, characterized in that: When the first operating state is different from the target operating state of the server, changing the first virtual machine component of the first subsystem to a shutdown state further includes: When the first operating state is different from the target operating state of the server, and the operating state deviation coefficient between the first operating state and the target operating state of the server is less than or equal to an operating state deviation coefficient threshold, the first operating state is sent to the second subsystem through the first subsystem for state synchronization; When the first operating state is different from the server target operating state, and the operating state deviation coefficient between the first operating state and the server target operating state is greater than the operating state deviation coefficient threshold, the first virtual machine component of the first subsystem is changed to a shutdown state.

7. The fault-tolerant implementation method for server whole machine redundancy according to claim 1, characterized in that: Sending the first operating state to the second subsystem through the first subsystem for state synchronization includes: Collecting the virtual disk file I / O status of the first virtual machine component through the first fault-tolerance management component; Collecting the memory page I / O status of the first virtual machine component through the first fault-tolerance management component; The virtual disk file I / O status and the memory page I / O status are sent to the second subsystem through the first subsystem and written into the second virtual machine component.

8. The fault-tolerant implementation method for server whole machine redundancy according to claim 1, characterized in that: Also includes: After the first subsystem receives the second subsystem service stop signal from the second subsystem, when the first subsystem receives the second operating state again, the first subsystem performs state synchronization according to the second operating state.

9. A fault-tolerant implementation device for server whole machine redundancy, characterized in that: The method for implementing the fault-tolerant implementation of server whole machine redundancy according to any one of claims 1 to 8, the device comprising a first subsystem and a second subsystem, the first subsystem and the second subsystem being the same, the first subsystem having a first virtual machine component, the second subsystem having a second virtual machine component, the first subsystem and the second subsystem being connected via a direct path, and the device further comprising: A first state collection unit: collecting a first operating state of the first subsystem through a first fault-tolerant management component of the first subsystem; A second state collection unit: collecting a second operating state of the second subsystem through a second fault-tolerant management component of the second subsystem; A state synchronization unit: when the first running state changes, the first running state is sent to the second subsystem through the first subsystem for state synchronization; when the second running state changes, the second running state is sent to the first subsystem through the second subsystem for state synchronization; A first state changing unit: when the first subsystem does not receive the second running state for a preset period of time, changing the second subsystem to a downtime state, and changing the first shadow virtual machine of the first subsystem to a running state; The second state changing unit: or when the second subsystem does not receive the first running state for more than the preset time period, the first subsystem is changed to downtime, and the second shadow virtual machine of the second subsystem is changed to running state.

Images