CN117112313B - Service disaster tolerance switching method, device, equipment and storage medium - Google Patents

Service disaster tolerance switching method, device, equipment and storage medium Download PDF

Info

Publication number
CN117112313B
CN117112313B CN202311373025.1A CN202311373025A CN117112313B CN 117112313 B CN117112313 B CN 117112313B CN 202311373025 A CN202311373025 A CN 202311373025A CN 117112313 B CN117112313 B CN 117112313B
Authority
CN
China
Prior art keywords
operating system
standby server
server
target operating
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202311373025.1A
Other languages
Chinese (zh)
Other versions
CN117112313A (en
Inventor
程方全
董勇
代青松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Clerware Technology Co ltd
Original Assignee
Shenzhen Clerware Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Clerware Technology Co ltd filed Critical Shenzhen Clerware Technology Co ltd
Priority to CN202311373025.1A priority Critical patent/CN117112313B/en
Publication of CN117112313A publication Critical patent/CN117112313A/en
Application granted granted Critical
Publication of CN117112313B publication Critical patent/CN117112313B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments

Abstract

The invention relates to the technical field of computer service disaster recovery, and discloses a service disaster recovery switching method, a device, equipment and a storage medium, wherein the method comprises the following steps: the method and the system have the advantages that the target operating system of the main server is corrected based on the hardware configuration information of the standby server, and because the device is automatically corrected, compared with the existing manual correction mode, the efficiency is higher, and then the standby server starts the operating system according to the corrected target operating system, so that the consistency of the kernels of the operating systems of the main server and the standby server can be ensured, and the subsequent service can be smoothly switched; the real-time backup data of the main server are sent to the standby server, so that the service data of the main server and the standby server are ensured to be consistent in real time; and finally, sending a service switching instruction to the standby server so that the standby server completes the initialization of the operating system, and the service can be switched to the standby server more quickly because the configuration of the standby server is corrected before switching and the service data are consistent.

Description

Service disaster tolerance switching method, device, equipment and storage medium
Technical Field
The present invention relates to the field of computer service disaster recovery technologies, and in particular, to a service disaster recovery switching method, device, equipment, and storage medium.
Background
The work of many companies is advanced nowadays and depends on the informatization system seriously, if the informatization service system fails, the work cannot be carried out, so that the continuity of the service system greatly influences the operation efficiency of the company service. To ensure service continuity, it is common practice to prepare a backup server for each service system and then synchronize all disk data on the service system to the backup server in real time. When the main service fails, the service is switched to the standby server so as to quickly recover the service. Since the hardware configurations of the main server and the standby server are different in many cases, if the driver and the system configuration above the standby server are not modified, the standby server is difficult to start successfully, so that the service of the service system on the standby server is not available. If these configurations are manually revised, the time for the business system to switch is long, resulting in a long disruption of the business of the company.
Disclosure of Invention
The invention mainly aims to provide a service disaster recovery switching method, device, equipment and storage medium, and aims to solve the technical problems of long switching time and low efficiency in the prior art that when service disaster recovery is carried out by switching service from a main server to a standby server, the host configuration of the standby server is manually corrected.
In order to achieve the above object, the present invention provides a service disaster recovery switching method, which includes the following steps:
acquiring backup point data of a main server, and correcting a target operating system of the backup point data of the main server based on hardware configuration information of the standby server to obtain a corrected target operating system;
transmitting the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system;
transmitting the real-time backup data of the main server to the standby server so that the standby server writes the real-time backup data into a disk;
and sending a service switching instruction to the standby server so that the standby server completes initialization of an operating system, and switching the service supported by the main server to be supported by the standby server.
Optionally, the sending the modified target operating system to a standby server, so that the standby server starts the operating system based on the modified target operating system, including:
and sending the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system and blocks the initialization behavior of the operating system before the real root directory is mounted.
Optionally, the sending the modified target operating system to a standby server, so that the standby server starts the operating system based on the modified target operating system, and blocks an initialization behavior of the operating system before the real root directory is mounted, including:
and sending the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system and blocks the initialization behavior of the operating system by the corrected target operating system before the real root directory is mounted, wherein the corrected target operating system is an operating system which can not finish the initialization of the operating system by itself.
Optionally, the sending the modified target operating system to a standby server, so that the standby server starts the operating system based on the modified target operating system, and blocks an initialization behavior of the operating system before the real root directory is mounted, including:
transmitting the corrected target operating system to a standby server, so that the standby server starts the operating system based on the corrected target operating system, and blocks the initialization behavior of the operating system through an initialization blocking identifier in the corrected target operating system before the real root directory is mounted, wherein the corrected target operating system comprises the initialization blocking identifier;
Correspondingly, the sending a service switching instruction to the standby server so that the standby server completes initialization of an operating system, and switches the service supported by the main server to be supported by the standby server, including:
and sending a service switching instruction to the standby server so that the standby server deletes the initialization blocking identifier, completes initialization of an operating system, and switches the service supported by the main server to be supported by the standby server.
Optionally, the target operating system of the backup point data of the main server includes: configuration data, device drivers, and initialization scripts;
the obtaining backup point data of the main server, correcting a target operating system of the backup point data of the main server based on hardware configuration information of the backup server, and obtaining a corrected target operating system includes:
acquiring backup point data of a main server, modifying configuration data in a target operating system of the backup point data of the main server, and determining a device driver based on hardware configuration information of a standby server;
modifying an initialization script in a target operating system of backup point data of the main server, and setting loading time of the device driver in the initialization script before the real root directory is mounted so that the standby server corrects a configuration file in the real root directory before the real root directory is mounted;
And generating a modified target operating system based on the modified configuration data, the device driver and the modified initialization script.
Optionally, the obtaining backup point data of the primary server, modifying configuration data in a target operating system of the backup point data of the primary server, and determining a device driver based on hardware configuration information of the backup server includes:
and acquiring backup point data of a main server, modifying a platform-related device name of a volume device in configuration data in a target operating system of the backup point data of the main server into a platform-independent device name, and determining device drivers corresponding to a network card controller and a disk controller based on hardware configuration information of a standby server, wherein the hardware configuration information of the standby server is PCI information of the standby server.
Optionally, after the sending a service switching instruction to the standby server to enable the standby server to complete initialization of an operating system and switch the service supported by the main server to be supported by the standby server, the method further includes:
and sending the modified configuration data and the device driver in the modified target operating system to the standby server so that the standby server can restart the operating system according to the modified configuration data and the device driver.
In addition, in order to achieve the above objective, the present invention further provides a service disaster recovery switching device, where the service disaster recovery switching device includes:
the system correction module is used for acquiring backup point data of the main server, correcting a target operating system of the backup point data of the main server based on hardware configuration information of the standby server, and acquiring a corrected target operating system;
the system sending module is used for sending the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system;
the data sending module is used for sending the real-time backup data of the main server to the standby server so that the standby server writes the real-time backup data into a disk;
and the service switching module is used for sending a service switching instruction to the standby server so that the standby server finishes the initialization of an operating system and switches the service supported by the main server to be supported by the standby server.
In addition, in order to achieve the above objective, the present invention further provides a service disaster recovery switching device, where the device includes: the system comprises a memory, a processor and a service disaster recovery switching program stored on the memory and capable of running on the processor, wherein the service disaster recovery switching program is configured to realize the steps of the service disaster recovery switching method.
In addition, in order to achieve the above object, the present invention further provides a storage medium, on which a service disaster recovery switching program is stored, the service disaster recovery switching program implementing the steps of the service disaster recovery switching method as described above when executed by a processor.
The invention discloses a method for acquiring backup point data of a main server, which comprises the steps of correcting a target operating system of the backup point data of the main server based on hardware configuration information of a standby server, wherein the method comprises the steps of automatically correcting a program, and then sending the corrected target operating system to the standby server, so that the standby server starts the operating system based on the corrected target operating system, thereby ensuring that the operating system cores of the standby server and the main server are consistent, and facilitating smooth switching of subsequent services; the real-time backup data of the main server is sent to the standby server, so that the standby server writes the real-time backup data into a disk, and the service data of the standby server and the service data of the main server are ensured to be consistent in real time; and finally, sending a service switching instruction to the standby server so that the standby server completes the initialization of the operating system, and the service data of the standby server are consistent as the configuration of the standby server is corrected before switching, so that the service supported by the main server can be switched to the service supported by the standby server more quickly.
Drawings
FIG. 1 is a schematic diagram of a service disaster recovery switching device in a hardware operating environment according to an embodiment of the present invention;
FIG. 2 is a flowchart of a service disaster recovery switching method according to a first embodiment of the present invention;
FIG. 3 is a schematic diagram showing the interaction of the service disaster recovery switching device according to the present invention;
FIG. 4 is a flowchart of a second embodiment of a service disaster recovery switching method according to the present invention;
FIG. 5 is a flowchart of a third embodiment of a service disaster recovery switching method according to the present invention;
fig. 6 is a block diagram of a first embodiment of a service disaster recovery switching device according to the present invention.
The achievement of the objects, functional features and advantages of the present invention will be further described with reference to the accompanying drawings, in conjunction with the embodiments.
Detailed Description
It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
Referring to fig. 1, fig. 1 is a schematic structural diagram of a service disaster recovery switching device in a hardware operating environment according to an embodiment of the present invention.
As shown in fig. 1, the service disaster recovery switching device may include: a processor 1001, such as a central processing unit (Central Processing Unit, CPU), a communication bus 1002, a user interface 1003, a network interface 1004, a memory 1005. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display, an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a Wireless interface (e.g., a Wireless-Fidelity (WI-FI) interface). The Memory 1005 may be a high-speed random access Memory (Random Access Memory, RAM) or a stable nonvolatile Memory (NVM), such as a disk Memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above.
Those skilled in the art will appreciate that the architecture shown in fig. 1 is not limiting of a service disaster recovery switching device and may include more or fewer components than shown, or may combine certain components, or may be a different arrangement of components.
As shown in fig. 1, an operating system, a data storage module, a network communication module, a user interface module, and a service disaster recovery switching program may be included in the memory 1005 as one type of storage medium.
In the service disaster recovery switching device shown in fig. 1, the network interface 1004 is mainly used for performing data communication with a network server; the user interface 1003 is mainly used for data interaction with a user; the processor 1001 and the memory 1005 in the service disaster recovery switching device of the present invention may be disposed in the service disaster recovery switching device, where the service disaster recovery switching device invokes a service disaster recovery switching program stored in the memory 1005 through the processor 1001, and executes the service disaster recovery switching method provided by the embodiment of the present invention.
An embodiment of the present invention provides a service disaster recovery switching method, and referring to fig. 2, fig. 2 is a flow chart of a first embodiment of the service disaster recovery switching method of the present invention.
In this embodiment, the service disaster recovery switching method includes the following steps:
Step S10: and acquiring backup point data of the main server, and correcting a target operating system of the backup point data of the main server based on hardware configuration information of the standby server to obtain a corrected target operating system.
It should be noted that, the execution body of the method of the embodiment may be a computing service device with functions of service disaster recovery, network communication and program operation, such as a mobile phone, a tablet computer, a personal computer, etc.; the service disaster recovery switching device or the backup integrated machine with the same or similar functions can also be used. This embodiment and the following embodiments will be described by taking a backup integrated machine as an example.
It can be understood that when disaster recovery is performed on the service system, two targets are generally pursued, firstly, data consistency of the main service and the standby service is guaranteed to the greatest extent, namely, data changed on a disk of the main server is striven for being synchronized to the standby server as soon as possible; and secondly, the service of the main server fails, and the time for switching the service to the standby server is as short as possible. In order to achieve the two objectives, referring to fig. 3, fig. 3 is an equipment interaction schematic diagram of the service disaster recovery switching between the main server and the standby server through the backup integrated machine, and all data on the main server can be backed up to the standby server through the backup integrated machine.
In the specific implementation, the invention firstly makes a whole-level backup on the side of the main server, wherein the whole-level backup refers to that metadata such as an operating system, an application program, service data, a partition of a disk, a volume, a file system and the like of the main server are backed up into a backup integrated machine, and the data backed up each time is called a backup point. Original data and subsequently changed data of the disk of the main server can be continuously backed up into the backup integrated machine through continuous data protection backup (Continuous Data Protection, CDP), so that backup point data is formed, and the number of the disk in the backup point data is the same as that of the main server. The operation process of backup can be to enumerate the number of disks on the host where the main server is located, obtain the effective data on each disk, and then backup to the backup integrated machine for storage. In addition, the platform dependent device names (e.g., "/dev/sda1", "/dev/disk/by-path/pcb-0000: 01:00.0-scsi-0:2: 0-part 1") and the corresponding platform independent device names (e.g., "uuid=1da 9387d-bf51-40be-83a3-e13766cb32c 0") of all volumes (logical partitions) on the system may be enumerated, which may be needed for subsequent revising the system configuration file. The platform-related device name is that the device name exists only on the primary server and not necessarily on the standby server. The platform independent device name is a device name that exists on the primary server, the backup server, or other servers. In addition, the platform independent device names of the root partition and the boot partition are acquired, the volume device corresponding to the root directory and/or the boot directory can be queried through a mount command, and then the platform independent device name corresponding to the volume device is acquired.
It will be appreciated that the hardware configuration information of the standby server may also be obtained, and the hardware driver that needs to be used by the target operating system is obtained according to the hardware configuration information and added to the boot loader initialization RAM disk (boot loader initialized RAM disk, initrd). The initrd file is a temporary root file system which is mounted in the system before an actual root file system is available, the initrd is bound with a kernel, as a part of initialization of the Linux system, the initrd can load an operating system key driver module (such as a disk controller driver), initiate a core configuration file, complete basic initialization of the operating system, and therefore the actual root file system can be mounted after the basic initialization, and the actual root file system can be used. initrd contains the directory and the minimum set of executable programs, drivers needed to achieve this basic initialization of the operating system. The target operating system of the backup point data of the primary server may be modified by the information related to the device controller in the hardware configuration information of the backup server to adapt to the hardware configuration of the provisioning server.
It should be noted that, based on backup point data of a main server at a certain moment, disk data may be mounted, and then a program, data and configuration needed for starting an operating system may be modified. The Linux operating system is described here as an example, but the present invention is not limited thereto. In Linux operating systems, these programs, data, and configurations are typically stored in a boot partition and a root partition. The boot configuration file, fstab configuration file, device configuration file, etc. of the mounted boot partition may be modified. The initrd file of the mounted boot partition can be decompressed to a temporary directory (for example,/tmp/initrd-xxx), a hardware driver (such as a driver of a disk controller or a network card controller) needed for starting is copied to the temporary directory based on hardware configuration information of the standby server, an initialization script of the system is modified, and related drivers are loaded after the initialization of the system kernel is completed. The modified boot configuration file, fstab configuration file, device configuration file, etc. may also be copied to the temporary directory (e.g.,/tmp/initrd-xxx/config directory), and the decompressed temporary directory is recompressed into an initrd file, replaced into the boot partition, and the initrd file is cached in a portion for later use. And after the correction is finished, the target operating system after the correction of the backup point data of the main server can be obtained.
Step S20: and sending the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system.
It will be appreciated that the boot program is the first piece of software in the computer boot process and is responsible for loading the operating system kernel into memory and executing. The boot program typically loads initrd into memory and passes control to initrd to complete the system initialization and load the actual root file system. A Root File System (Root File System), also called Root partition, is the highest-level File System in the Linux System, and contains the core files and directory structures of the operating System. During the boot process, initrd is loaded as a temporary root file system that is used to initialize the system and load the actual root file system (also referred to as the true root directory below).
It should be appreciated that the modified target operating system includes data associated with system boot, system start-up, and therefore, data associated with system boot, system start-up may be pushed to disk of the standby server. The data comprise a partition table of a hard disk, boot partition data, file system metadata of the boot partition and the like, and the data quantity of the boot and start related data is not large and generally does not exceed 2GB, so that the whole pushing time is not required to be too long. After the pushing is finished, the standby server can restart the operating system and boot the operating system from the hard disk, so that the system started on the standby server is based on the target operating system corrected by the main server, and the standby server is completely consistent with the system kernel of the main server. After the kernel is loaded, the initial initialization can be carried out through the initrd, the driver of the equipment controller is loaded through the initialization script, and the standby server can be configured into a network through an Agent after loading and is connected to the backup integrated machine through the network. The backup server Agent may be an application program running on the backup server, and configured to receive the disk data sent by the backup integrated machine, and write the disk data into a disk of the backup server.
Step S30: and sending the real-time backup data of the main server to the standby server so that the standby server writes the real-time backup data into a disk.
It can be understood that after the driver of the device controller is loaded, the Agent program can be connected to the backup integrated machine through a network, and the backup integrated machine receives real-time backup data of the main server, including the basic backup data and the subsequent CDP stream data, and writes the real-time backup data on a disk of the backup server. In this case, the data pushed previously on the disk of the standby server (i.e., the data pushed by the backup all-in-one machine before the standby server is restarted) will be covered. Because the main server performs CDP backup, all written data of the disk can be continuously backed up to the backup integrated machine, the backup integrated machine can forward the data to an Agent program of the standby server and write the data on the disk, real-time synchronization of the disk data of the main server and the disk data of the standby server is ensured, and the data are consistent as much as possible during service switching.
Step S40: and sending a service switching instruction to the standby server so that the standby server completes initialization of an operating system, and switching the service supported by the main server to be supported by the standby server.
It should be understood that the backup integrated machine may send a service switching instruction to the backup server when the service of the primary server fails. When the standby server receives the service switching instruction, an Agent program of the standby server can mount the root partition to a temporary directory (for example, mount to/sysroot directory) through a platform-independent equipment name (for example, "uuid=1da 9387d-bf51-40be-83a3-e13766cb32c 0") of the root partition, copy a configuration file (for example, fstab configuration file, equipment configuration file … … and the like) in the modified target operating system to the temporary directory mounted on the root partition, unload the root partition in the temporary directory after copying is completed, and then inform an initrd script to release the initialization behavior of the operating system to complete the subsequent starting flow of the operating system. The subsequent process (i.e. normal operating system start-up process) will mount the real root partition, then switch to the real root partition, and mount each volume through the fstab configuration file, thus completing the initialization of the operating system.
It can be understood that in this embodiment, the configuration file required for switching the root directory is stored in the initrd first, then before switching to the real root directory, the root directory is mounted in a temporary directory, the corrected configuration file is placed in a corresponding position of the real root directory, then the root directory in the temporary directory is unloaded, and then the original system initialization process (that is, mounting the root partition and switching to the root partition) is performed, so that the normal initialization of the system is ensured. After the volume is mounted, the initialization script of the operating system can also start up each service program of the system, and after the service program is started up, the service can be provided to the outside, so that the service switching is completed. Before service switching, the operating system is started to a certain stage (normal hardware initialization and operation system starting may consume time), then the operating system is stopped and receives disk synchronous data of the main server, and after receiving a switching instruction, the initialization of the operating system and the operation system starting can be completed quickly, and service switching can be completed in a short time.
In the embodiment, the method and the system for acquiring the backup point data of the main server are disclosed, and the target operating system of the backup point data of the main server is corrected based on the hardware configuration information of the standby server; the real-time backup data of the main server is sent to the standby server, so that the standby server writes the real-time backup data into a disk, and the service data of the standby server and the service data of the main server are ensured to be consistent in real time; and finally, sending a service switching instruction to the standby server so that the standby server completes the initialization of the operating system, and the service data of the standby server are consistent as the configuration of the standby server is corrected before switching, so that the service supported by the main server can be switched to the service supported by the standby server more quickly.
Referring to fig. 4, fig. 4 is a flow chart of a second embodiment of the service disaster recovery switching method of the present invention.
Further, since the real-time backup data of the main server needs to be received before the standby server switches the service, and the service switching is performed when the service switching instruction is received, the initialization behavior of the operating system can be blocked before the real root directory is mounted, so that the data of the standby server and the data of the main server are ensured to be consistent in real time, and the time for facilitating the subsequent service switching is as short as possible.
Therefore, based on the first embodiment, in the present embodiment, the step S20 includes:
step S201: and sending the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system and blocks the initialization behavior of the operating system before the real root directory is mounted.
It can be appreciated that, since the standby server needs to receive the real-time backup data of the primary server before switching services, and the service switching is performed when a service switching instruction is received, the initialization behavior of the operating system can be blocked before the real root directory is mounted. Specifically, when the target operating system is corrected, a system initialization script of the target operating system can be set, so that the corrected target operating system can block the initialization behavior of the operating system before the real root directory is mounted, so as to receive synchronous data pushed by the main server, and the operation system of the standby server is initialized when a service switching instruction is received.
Further, in order to make the standby server block the initialization behavior of the operating system more simply and quickly, the operating system which cannot finish the initialization of the operating system by itself may be sent to the standby server, so as to block the initialization behavior of the operating system. Therefore, the step S201 further includes: and sending the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system and blocks the initialization behavior of the operating system by the corrected target operating system before the real root directory is mounted, wherein the corrected target operating system is an operating system which can not finish the initialization of the operating system by itself.
It should be appreciated that 2 initrd may be prepared when the target operating system is modified, one is initrd-1 blocking operating system initialization (the timing of blocking initialization may also be set in initrd-1 before the real root directory is mounted), and one is initrd-2 not blocking operating system initialization. When the operating system is pushed to start data, the initrd-1 initialized by the blocking operating system can be pushed, after the data synchronization is completed and the service is switched, the agent program acquires the initrd-2 when acquiring the initrd from the backup integrated machine, and thus, when the subsequent operating system is started, the initrd script can not block the operating system from starting. The operating system that cannot automatically complete the operating system initialization may be sent to the standby server, so that the standby server starts the operating system based on the modified target operating system. Since the modified target operating system cannot complete the operating system initialization by itself, the standby server cannot perform the operating system initialization before the real root directory is mounted.
Further, in order to make the standby server block the initialization behavior of the operating system more simply and rapidly, an initialization blocking identifier may be added when the target operating system is corrected, and then the target operating system including the initialization blocking identifier is sent to the standby server, so as to block the initialization behavior of the operating system. Correspondingly, when the subsequent standby server receives the service switching instruction, the initialization blocking identifier is deleted, and then the initialization of the operating system can be performed. Therefore, the step S201 further includes: transmitting the corrected target operating system to a standby server, so that the standby server starts the operating system based on the corrected target operating system, and blocks the initialization behavior of the operating system through an initialization blocking identifier in the corrected target operating system before the real root directory is mounted, wherein the corrected target operating system comprises the initialization blocking identifier; correspondingly, the sending a service switching instruction to the standby server so that the standby server completes initialization of an operating system, and switches the service supported by the main server to be supported by the standby server, including: and sending a service switching instruction to the standby server so that the standby server deletes the initialization blocking identifier, completes initialization of an operating system, and switches the service supported by the main server to be supported by the standby server.
It should be appreciated that blocking the initialization behavior of the operating system prior to mounting the real root directory may also be accomplished by setting an initialization blocking flag. The initialization script may be modified and an initialization blocking identification may be added to the initialization script. An initialization blocking identifier (or an identifier that may be called waiting for data synchronization) may also be added to a special area (e.g., a boot sector, a partition table, etc.) of the disk, to inform the system of an initialization script that needs to block the system's initialization behavior, waiting for synchronization data and service switching instructions.
Accordingly, since the initialization behavior of the operating system is blocked according to the initialization blocking identification before the real root directory is mounted, to wait for the synchronization data and the service switching instruction. After receiving the synchronous data and the service switching instruction, the standby server can delete the initialization blocking identifier from the initialization script or a special area of the disk, and the initialization script will not block the initialization behavior of the system when the server is restarted subsequently.
In this embodiment, sending the modified target operating system to a standby server is disclosed, so that the standby server starts the operating system based on the modified target operating system, and blocks the initialization behavior of the operating system before the real root directory is mounted. Because the embodiment blocks the initialization behavior of the operating system before the real root directory is mounted, the data of the standby server and the data of the main server are ensured to be consistent in real time, and the time for switching the service subsequently is convenient to be as short as possible.
Referring to fig. 5, fig. 5 is a flow chart of a third embodiment of a service disaster recovery switching method according to the present invention.
Further, when the target operating system of the backup point data of the main server is corrected, programs, data, configuration and the like which are needed for starting the operating system, such as configuration data, a device driver, an initialization script and the like, can be corrected, so that the operating system of the standby server can normally use hardware resources of the standby server, and the problem of starting failure of the standby server is avoided.
Therefore, based on the first embodiment, in this embodiment, the target operating system of the backup point data of the primary server includes: configuration data, device drivers, and initialization scripts; the step S10 includes:
step S101: and acquiring backup point data of the main server, modifying configuration data in a target operating system of the backup point data of the main server, and determining a device driver based on hardware configuration information of the standby server.
It can be understood that the backup point data of the main server can be virtualized into a hard disk through the virtual hard disk technology, a root partition and a boot partition are found, and the root partition and the boot partition are mounted; and then correcting the configuration files, including boot configuration files of boot, in the catalogues of grub, grub2 and llo of the boot, and also correcting the roll device names, udev rule files, network card device names, network card configuration and the like in the fstab configuration files according to the hardware configuration information of the standby server. And selecting a driver of the corresponding equipment controller from the root partition according to the hardware configuration information of the standby server.
Further, since the names of the volume devices used in many operating systems (e.g., "/dev/sda1", "/dev/vdb1" … …, etc.) may vary from hardware platform to platform, such device names are platform dependent device names; some volume device names may be independent of the hardware platform, such as "/dev/mapper/vg1-lv1". That is, the platform-related device name is that the device name exists only on the primary server, not necessarily on the backup server. The platform independent device name is a device name that exists on the primary server, the backup server, or other servers. When synchronizing the operating system of the primary server to the backup server, if the device name is not modified, the operating system may not find the device name, resulting in a system startup error. Therefore, the device names of the volumes can be corrected to be the device names irrelevant to the platform, and the situation that the device names cannot be found when the volumes of the standby servers are mounted can be avoided. Therefore, the step S101 further includes: and acquiring backup point data of a main server, modifying a platform-related device name of a volume device in configuration data in a target operating system of the backup point data of the main server into a platform-independent device name, and determining device drivers corresponding to a network card controller and a disk controller based on hardware configuration information of a standby server, wherein the hardware configuration information of the standby server is PCI information of the standby server.
It should be understood that, after the backup point data of the main server is obtained, the platform-related device name of the volume device in the configuration data in the target operating system of the backup point data of the main server may be modified to be a platform-independent device name, specifically, a boot configuration file of a boot in a directory of grub, grub2, and llo of the director may be found, and the platform-related volume device name in the configuration file may be modified to be a platform-independent device name; in addition, the roll device names in the fstab configuration file are replaced by the device names irrelevant to the platform; in addition, the udev rule file, the device name of the network card, and the network card configuration … … are also modified correspondingly according to the target hardware platform. Because the device names of the volumes in the fstab configuration file are all corrected to be the device names irrelevant to the platform, if the device names of the volumes are not corrected, the device names cannot be found, and the system is started to be in error, so that the situation that the device names cannot be found in the process of subsequently switching to the real root partition cannot occur in the process of volume mounting.
It should be understood that before correcting the target operating system of the backup point data of the main server, the WinPE and LiveCD system may also be run on the host of the backup server, and the application program of the system collects the hardware configuration information of the backup server and sends the hardware configuration information to the backup integrated machine. The hardware configuration information may include information of peripheral component interconnect standards (Peripheral Component Interconnect, PCI) of all network card controllers and disk controllers on the host, such as Vendor ID, device ID, subsystem Vendor ID, subsystem Device ID, etc., and may select a corresponding network card and disk controller driver from the operating system of the backup point according to the obtained PCI information of the backup server, and copy the driver into the decompression directory of the previous initrd.
Step S102: and modifying an initialization script in a target operating system of backup point data of the main server, and setting loading time of the device driver in the initialization script before the real root directory is mounted so that the standby server corrects a configuration file in the real root directory before the real root directory is mounted.
It should be understood that the initialization script in the target operating system of the backup point data of the main server may be modified, and the loading time of the device driver is set before the real root directory is mounted, so that the backup server loads the drivers early in the system start (i.e. before the real root directory is mounted), and after the loading, the system may configure the network card, send and receive data, and read and write the hard disk.
Step S103: and generating a modified target operating system based on the modified configuration data, the device driver and the modified initialization script.
It should be understood that the modified configuration data and the device driver may be added to initrd, specifically, the boot configuration file, the fstab file, the network card configuration file, the network card controller driver, the disk controller driver, and other data may be added to the decompressed directory, and the initrd may be recompressed into an initrd file, and replaced into a boot partition, and the initrd file may be cached in a portion, which is still needed after the subsequent service is successfully switched to the standby server.
Further, since the data in the standby server is real-time backup data from the primary server before the service system is switched to be supported by the standby server, the data of the modified operating system is covered, and thus, when the subsequent standby server system is restarted, the startup fails because the data is already covered as unmodified data on the primary server. Therefore, the modified configuration data and the device driver in the modified target operating system need to be sent to the standby server again, and the subsequent standby server can be started normally. Therefore, after the step S40, the method further includes: and sending the modified configuration data and the device driver in the modified target operating system to the standby server so that the standby server can restart the operating system according to the modified configuration data and the device driver.
It can be understood that, after the service system is started, the Agent program on the standby server is connected to the backup integrated machine again, so as to obtain the cached initrd file. In the above steps, the backup server receives the real-time backup data of the main server pushed by the backup integrated machine through the Agent program, writes the real-time backup data into the disk, and covers the original corrected data related to the target operating system on the disk, so that the guide data pushed in front is covered, and when the subsequent backup server system is restarted, the startup fails, because the initrd is already covered to be the initrd on the main server, the previously cached initrd (including the driver and the configuration data required for starting the backup server) needs to be acquired from the backup integrated machine and is replaced into the boot directory, so that the subsequent backup server can be started normally.
In this embodiment, it is disclosed to acquire backup point data of a primary server, modify configuration data in a target operating system of the backup point data of the primary server, and determine a device driver based on hardware configuration information of a standby server; modifying an initialization script in a target operating system of backup point data of a main server, and setting loading time of a device driver in the initialization script before the real root directory is mounted so that a standby server corrects a configuration file in the real root directory before the real root directory is mounted; and generating a modified target operating system based on the modified configuration data, the device driver and the modified initialization script. In this embodiment, when the target operating system of the backup point data of the main server is modified, the program, data, configuration, and the like required for starting the operating system are modified, for example, the configuration data, the device driver, and the initialization script are configured, so that the configuration data, the device driver, and the initialization script of the operating system of the standby server are adapted to the hardware resources of the standby server, and the problem of failure in starting the operating system of the standby server is avoided.
In addition, the embodiment of the invention also provides a storage medium, wherein the storage medium stores a service disaster recovery switching program, and the service disaster recovery switching program realizes the steps of the service disaster recovery switching method when being executed by a processor.
Referring to fig. 6, fig. 6 is a block diagram illustrating a first embodiment of a service disaster recovery switching device according to the present invention.
As shown in fig. 6, the service disaster recovery switching device provided in the embodiment of the present invention includes:
the system correction module 601 is configured to obtain backup point data of a main server, correct a target operating system of the backup point data of the main server based on hardware configuration information of a standby server, and obtain a corrected target operating system;
a system sending module 602, configured to send the modified target operating system to a standby server, so that the standby server starts an operating system based on the modified target operating system;
a data sending module 603, configured to send real-time backup data of the primary server to the standby server, so that the standby server writes the real-time backup data into a disk;
and the service switching module 604 is configured to send a service switching instruction to the standby server, so that the standby server completes initialization of an operating system, and switches a service supported by the main server to be supported by the standby server.
According to the embodiment, the target operating system of the backup point data of the main server is corrected based on the hardware configuration information of the backup server, and because the backup point data of the main server is automatically corrected through the program, compared with the existing manual correction mode, the efficiency is higher, and then the corrected target operating system is sent to the backup server, so that the backup server starts the operating system based on the corrected target operating system, the consistency of the backup server and the operating system kernel of the main server can be ensured, and the subsequent service can be smoothly switched; the real-time backup data of the main server is sent to the standby server, so that the standby server writes the real-time backup data into a disk, and the service data of the standby server and the service data of the main server are ensured to be consistent in real time; and finally, sending a service switching instruction to the standby server so that the standby server completes the initialization of the operating system, and the service data of the standby server are consistent as the configuration of the standby server is corrected before switching, so that the service supported by the main server can be switched to the service supported by the standby server more quickly.
Based on the first embodiment of the service disaster recovery switching device of the present invention, a second embodiment of the service disaster recovery switching device of the present invention is provided.
In this embodiment, the system sending module 602 is further configured to send the modified target operating system to a standby server, so that the standby server starts the operating system based on the modified target operating system, and blocks an initialization behavior of the operating system before the real root directory is mounted.
As an implementation manner, the system sending module 602 is further configured to send the modified target operating system to a standby server, so that the standby server starts the operating system based on the modified target operating system, and blocks, by the modified target operating system, an initialization behavior of the operating system before the real root directory is installed, where the modified target operating system is an operating system that cannot automatically complete the initialization of the operating system.
As an implementation manner, the system sending module 602 is further configured to send the modified target operating system to a standby server, so that the standby server starts an operating system based on the modified target operating system, and blocks an initialization behavior of the operating system by using an initialization blocking identifier in the modified target operating system before the real root directory is mounted, where the modified target operating system includes the initialization blocking identifier.
As an implementation manner, the system modification module 601 is further configured to obtain backup point data of a main server, modify configuration data in a target operating system of the backup point data of the main server, and determine a device driver based on hardware configuration information of a standby server; modifying an initialization script in a target operating system of backup point data of the main server, and setting loading time of the device driver in the initialization script before the real root directory is mounted so that the standby server corrects a configuration file in the real root directory before the real root directory is mounted; and generating a modified target operating system based on the modified configuration data, the device driver and the modified initialization script.
As an implementation manner, the system correction module 601 is further configured to obtain backup point data of a primary server, modify a platform-related device name of a volume device in configuration data in a target operating system of the backup point data of the primary server to a platform-independent device name, and determine a device driver corresponding to a network card controller and a disk controller based on hardware configuration information of a standby server, where the hardware configuration information of the standby server is PCI information of the standby server.
As an implementation manner, the system modification module 601 is further configured to send modified configuration data and a device driver in the modified target operating system to the standby server, so that the standby server subsequently restarts an operating system according to the modified configuration data and the device driver.
Other embodiments or specific implementation manners of the service disaster recovery switching device of the present invention may refer to the above method embodiments, and are not described herein again.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.
From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) as described above, comprising instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the method according to the embodiments of the present invention.
The foregoing description is only of the preferred embodiments of the present invention, and is not intended to limit the scope of the invention, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.

Claims (9)

1. The service disaster recovery switching method is characterized by comprising the following steps:
Acquiring backup point data of a main server, and correcting a target operating system of the backup point data of the main server based on hardware configuration information of the standby server to obtain a corrected target operating system;
transmitting the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system;
transmitting the real-time backup data of the main server to the standby server so that the standby server writes the real-time backup data into a disk;
sending a service switching instruction to the standby server so that the standby server completes initialization of an operating system and switches the service supported by the main server to be supported by the standby server;
the target operating system of the backup point data of the main server comprises: configuration data, device drivers, and initialization scripts;
the obtaining backup point data of the main server, correcting a target operating system of the backup point data of the main server based on hardware configuration information of the backup server, and obtaining a corrected target operating system includes:
acquiring backup point data of a main server, modifying configuration data in a target operating system of the backup point data of the main server, and determining a device driver based on hardware configuration information of a standby server;
Modifying an initialization script in a target operating system of backup point data of the main server, and setting loading time of the device driver in the initialization script before the loading time is the loading time of the root directory, so that the standby server corrects a configuration file in the root directory before the loading time of the root directory;
and generating a modified target operating system based on the modified configuration data, the device driver and the modified initialization script.
2. The service disaster recovery switching method according to claim 1, wherein said sending the modified target operating system to a standby server to cause the standby server to start up an operating system based on the modified target operating system includes:
the corrected target operating system is sent to a standby server, so that the standby server starts the operating system based on the corrected target operating system and mounts the operating systemRoot directoryThe initialization behavior of the operating system was previously blocked.
3. The service disaster recovery switching method according to claim 2, wherein said sending said modified target operating system to a standby server causes said standby server to start up an operating system based on said modified target operating system and to mount said operating system Root directoryPreviously blocking the initialization behavior of the operating system, including:
transmitting the corrected target operating system to a standby server so thatThe standby server starts the operating system based on the corrected target operating system and mounts the operating systemRoot directoryAnd blocking the initialization behavior of the operating system by the corrected target operating system, wherein the corrected target operating system is an operating system which can not finish the initialization of the operating system by itself.
4. The service disaster recovery switching method according to claim 2, wherein said sending said modified target operating system to a standby server causes said standby server to start up an operating system based on said modified target operating system and to mount said operating systemRoot directoryPreviously blocking the initialization behavior of the operating system, including:
the corrected target operating system is sent to a standby server, so that the standby server starts the operating system based on the corrected target operating system and mounts the operating systemRoot directoryBlocking the initialization behavior of the operating system by the initialization blocking identifier in the modified target operating system before, wherein the modified target operating system comprises the initialization blocking identifier;
Correspondingly, the sending a service switching instruction to the standby server so that the standby server completes initialization of an operating system, and switches the service supported by the main server to be supported by the standby server, including:
and sending a service switching instruction to the standby server so that the standby server deletes the initialization blocking identifier, completes initialization of an operating system, and switches the service supported by the main server to be supported by the standby server.
5. The service disaster recovery switching method according to any one of claims 1 to 4, wherein the obtaining backup point data of a primary server, modifying configuration data in a target operating system of the backup point data of the primary server, and determining a device driver based on hardware configuration information of a backup server, includes:
and acquiring backup point data of a main server, modifying a platform-related device name of a volume device in configuration data in a target operating system of the backup point data of the main server into a platform-independent device name, and determining device drivers corresponding to a network card controller and a disk controller based on hardware configuration information of a standby server, wherein the hardware configuration information of the standby server is PCI information of the standby server.
6. The service disaster recovery switching method according to claim 5, wherein said sending a service switching instruction to said standby server to cause said standby server to complete initialization of an operating system and to switch services supported by said main server to services supported by said standby server, further comprises:
and sending the modified configuration data and the device driver in the modified target operating system to the standby server so that the standby server can restart the operating system according to the modified configuration data and the device driver.
7. The service disaster recovery switching device is characterized by comprising:
the system correction module is used for acquiring backup point data of the main server, correcting a target operating system of the backup point data of the main server based on hardware configuration information of the standby server to obtain a corrected target operating system, wherein the target operating system of the backup point data of the main server comprises: configuration data, device drivers, and initialization scripts;
the system sending module is used for sending the corrected target operating system to a standby server so that the standby server starts the operating system based on the corrected target operating system;
The data sending module is used for sending the real-time backup data of the main server to the standby server so that the standby server writes the real-time backup data into a disk;
the service switching module is used for sending a service switching instruction to the standby server so that the standby server can complete initialization of an operating system and switch the service supported by the main server to be supported by the standby server;
the system correction module is further used for acquiring backup point data of the main server, modifying configuration data in a target operating system of the backup point data of the main server, and determining a device driver program based on hardware configuration information of the standby server; modifying an initialization script in a target operating system of backup point data of the main server, and setting loading time of the device driver in the initialization script before the loading time is the loading time of the root directory, so that the standby server corrects a configuration file in the root directory before the loading time of the root directory; and generating a modified target operating system based on the modified configuration data, the device driver and the modified initialization script.
8. A service disaster recovery switching device, the device comprising: a memory, a processor and a service disaster recovery switching program stored on the memory and operable on the processor, the service disaster recovery switching program being configured to implement the steps of the service disaster recovery switching method according to any one of claims 1 to 6.
9. A storage medium, wherein a service disaster recovery switching program is stored on the storage medium, and the service disaster recovery switching program, when executed by a processor, implements the steps of the service disaster recovery switching method according to any one of claims 1 to 6.
CN202311373025.1A 2023-10-23 2023-10-23 Service disaster tolerance switching method, device, equipment and storage medium Active CN117112313B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311373025.1A CN117112313B (en) 2023-10-23 2023-10-23 Service disaster tolerance switching method, device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311373025.1A CN117112313B (en) 2023-10-23 2023-10-23 Service disaster tolerance switching method, device, equipment and storage medium

Publications (2)

Publication Number Publication Date
CN117112313A CN117112313A (en) 2023-11-24
CN117112313B true CN117112313B (en) 2024-02-13

Family

ID=88798742

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311373025.1A Active CN117112313B (en) 2023-10-23 2023-10-23 Service disaster tolerance switching method, device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN117112313B (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1746855A (en) * 2005-10-26 2006-03-15 北京启明星辰信息技术有限公司 Method and system for backuping applied layer transparent fault-tolerant based on pseudo block
US10592354B2 (en) * 2018-03-20 2020-03-17 Microsoft Technology Licensing, Llc Configurable recovery states
CN112579359A (en) * 2020-12-24 2021-03-30 深圳市科力锐科技有限公司 Business system reconstruction method, device, equipment and storage medium
CN112631831A (en) * 2020-12-22 2021-04-09 苏州柏科数据信息科技研究院有限公司 Bare computer recovery method and system of service system
CN114625575A (en) * 2022-05-16 2022-06-14 深圳市科力锐科技有限公司 Business system synchronization method, device, equipment and storage medium

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1746855A (en) * 2005-10-26 2006-03-15 北京启明星辰信息技术有限公司 Method and system for backuping applied layer transparent fault-tolerant based on pseudo block
US10592354B2 (en) * 2018-03-20 2020-03-17 Microsoft Technology Licensing, Llc Configurable recovery states
CN112631831A (en) * 2020-12-22 2021-04-09 苏州柏科数据信息科技研究院有限公司 Bare computer recovery method and system of service system
CN112579359A (en) * 2020-12-24 2021-03-30 深圳市科力锐科技有限公司 Business system reconstruction method, device, equipment and storage medium
CN114625575A (en) * 2022-05-16 2022-06-14 深圳市科力锐科技有限公司 Business system synchronization method, device, equipment and storage medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
空管区域管制中心席位互备的容灾备份系统;祁伟，等;指挥信息系统与技术;第9卷(第3期);28-31 *

Also Published As

Publication number Publication date
CN117112313A (en) 2023-11-24

Similar Documents

Publication Publication Date Title
US10503532B2 (en) Creating a virtual machine clone of the host computing device and handling of virtual machine clone requests via an I/O filter
JP5113700B2 (en) Firmware update apparatus and method
US8527728B2 (en) Management of multiple software images with relocation of boot blocks
US20160378528A1 (en) Propagating changes from a virtual machine clone to a physical host device
US9384094B2 (en) Method and system for instant restore of system volume from a backup image
US20080126792A1 (en) Systems and methods for achieving minimal rebooting during system update operations
US8056072B2 (en) Rebootless display driver upgrades
US20080098381A1 (en) Systems and methods for firmware update in a data processing device
EP3769224B1 (en) Configurable recovery states
JPH03278126A (en) Computer system starting system
US20140122860A1 (en) Cloud system and boot deployment method for the cloud system
CN109002346B (en) Conversion method of Windows virtual machine bootstrap program
CN110209525B (en) Operating system restoration method and device
CN104572354A (en) Backup and restoration method for operating system based on restoration service and equipment thereof
CN111090546A (en) Method, device and equipment for restarting operating system and readable storage medium
CN108958814B (en) Multimode redundant embedded operating system starting method
CN112579361B (en) Backup data reconstruction method, device, equipment and storage medium
TWI764454B (en) Firmware corruption recovery
CN117112313B (en) Service disaster tolerance switching method, device, equipment and storage medium
CN116880877A (en) Virtual machine enhancement tool upgrading method and device, computer equipment and storage medium
US7506115B2 (en) Incremental provisioning of software
US8612737B2 (en) System and method for supporting multiple hardware platforms with a single disk image
KR101143909B1 (en) Dual backup system based on cloud computing
KR102423056B1 (en) Method and system for swapping booting disk
KR101552580B1 (en) Method for system recovery including mobile device and backup supporting multi operation system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant