Containerized service recovery method and system based on double-storage architecture and related equipment

Abstract

The invention provides a containerized service recovery method and system based on a double-storage architecture and related equipment. The method comprises the following steps: establishing a server comprising an SSD (Solid State Disk) main storage and an HDD (Hard Disk Drive) standby storage; setting a main operating system of the containerized service in the main storage and setting a standby operating system of the main operating system in the standby storage; a shared storage area which can be accessed by both the main operating system and the standby operating system is configured in the standby storage; constructing a timing task in the main operating system to collect mirror image information and configuration information of the containerized service, and storing the mirror image information and the configuration information to a shared storage area through an incremental backup mechanism; a system exception restart switching mechanism is preset in a management board of the server, when the main operating system fails to start, the standby operating system is switched to start, and the containerized service is reconstructed based on the mirror image information and the configuration information in the shared storage area. According to the method, the containerized service is recovered by utilizing a dual-storage architecture and an incremental backup technology, so that the method has higher disaster tolerance and lower storage overhead.

Description

Technical Field

[0001] The present invention relates to the technical field of server disaster recovery, and in particular to a containerized service recovery method, system and related devices based on a dual storage architecture. Background Art

[0002] Disaster recovery technology is an important measure to reduce losses caused by disasters and ensure the continuous operation of computer systems. It is the core of disaster prevention and mitigation. Its purpose is to protect the continuity of business systems after disasters and minimize unplanned downtime as much as possible.

[0003] Existing server disaster recovery solutions usually have the following technical defects: 1. Single point of failure risk: The architecture relying on a single storage medium, once this storage fails, it will lead to the risk of service interruption and data loss. 2. Backup efficiency and storage overhead: Traditional full backup mechanisms not only occupy a large amount of storage space, but also take a long time for the backup process. 3. Excessively long recovery time: After a failure occurs, the process of recovering services from backup data is complex and time-consuming, resulting in an excessively long service interruption time (RTO). 4. Incomplete configuration recovery: In a containerized environment, in addition to data, the recovery of container orchestration configurations (such as docker-compose files) and dependent images is also crucial. Traditional solutions may ignore this link or the recovery is incomplete.

[0004] Therefore, the existing technology still needs to be improved and developed. Summary of the Invention

[0005] The present invention provides a containerized service recovery method, system and related devices based on a dual storage architecture. The main purpose of the present invention is to solve the technical problems mentioned in the background art of the existing technology.

[0006] The first aspect of the present invention provides a containerized service recovery method based on a dual storage architecture, including: Building a server including an SSD main storage and an HDD backup storage; Setting a main operating system of the containerized service in the SSD main storage and setting a backup operating system of the main operating system in the HDD backup storage. Both the main operating system and the backup operating system are installed with a Docker engine and a Docker Compose tool; Configuring a shared storage area in the HDD backup storage that can be accessed by both the main operating system and the backup operating system; Constructing a timed task in the main operating system to collect image information and configuration information of the containerized service, and storing the image information and the configuration information in the shared storage area through an incremental backup mechanism; A system exception restart switching mechanism is preset in the management board of the server. When the main operating system fails to start, it switches to the standby operating system to start, and reconstructs the containerized service based on the mirror information and the configuration information in the shared storage area.

[0007] In an optional implementation manner of the first aspect of the present invention, the steps of constructing a timed task in the main operating system to collect the mirror information and configuration information of the containerized service, and storing the mirror information and the configuration information in the shared storage area through an incremental backup mechanism include: Create a Cron timed task in the main operating system to start a preset backup script at a preset period; Through the backup script, obtain the mirror information and configuration information used by the currently running containerized service in the main operating system based on the Docker API; Compare the current mirror information with the last backup metadata stored in the shared storage area to identify the newly added or changed mirror information; Export the newly added or changed mirror information as a mirror file through the gzip tool and store it in the shared storage area; Update the configuration information to the orchestration configuration file path list and save it to the shared storage area; Update the backup metadata in the shared storage area to reflect the latest mirror status after this backup.

[0008] In an optional implementation manner of the first aspect of the present invention, the steps of switching to the standby operating system to start when the main operating system fails to start, and reconstructing the containerized service based on the mirror information and the configuration information in the shared storage area include: After the standby operating system starts, execute a preset recovery script; Through the recovery script, read the latest backup metadata and the orchestration configuration file path list from the shared storage area; Through the recovery script, load the backed-up mirror file from the shared storage area into the container running environment of the standby operating system; Through the recovery script, according to the read orchestration configuration file path list, use the corresponding configuration file and the loaded mirror file to recreate and start the containerized service.

[0009] In an optional implementation manner of the first aspect of the present invention, the step of loading the backed-up mirror file from the shared storage area into the container running environment of the standby operating system through the recovery script includes: Traverse all the image IDs to be restored recorded in the backup metadata through the restoration script; For each of the image IDs, check whether the image file corresponding to the image ID exists in the shared storage area; If the image file corresponding to the image ID exists in the shared storage area, unzip the image file through the gunzip tool and load it into the container running environment of the standby operating system.

[0010] In an optional implementation manner of the first aspect of the present invention, the re-creating and starting the containerized service by the restoration script according to the read list of the arrangement configuration file paths includes: For each path in the list of the arrangement configuration file paths, execute the command to start the containerized service and run it in the background; Create a network and volumes according to the configuration file through the command to start the containerized service and run it in the background, and start the containerized service by using the loaded image file.

[0011] In an optional implementation manner of the first aspect of the present invention, the presetting of the system abnormal restart switching mechanism in the management board of the server includes: Set a monitoring agent program in the management board of the server; Send heartbeat data packets to the management interface of the SSD main storage regularly through the monitoring agent program; If the management board does not receive the response from the management interface, determine that the SSD main storage fails and restart the main operating system; When the main operating system fails to restart multiple times, switch to start the standby operating system in the HDD standby storage.

[0012] In an optional implementation manner of the first aspect of the present invention, the configuration of the shared storage area that can be accessed by both the main operating system and the standby operating system in the HDD standby storage includes: Partition a partition in the HDD standby storage as the shared storage area; Connect the main operating system and the standby operating system to the backup directory of the shared storage area through the mounting technology or the symbolic link technology.

[0013] The second aspect of the present invention provides a containerized service system based on a dual storage architecture, and the containerized service system based on the dual storage architecture includes: A server building module, which is used to build a server including an SSD main storage and an HDD standby storage; A system setting module, configured to set a main operating system of a containerized service in the SSD main storage and set a standby operating system of the main operating system in the HDD standby storage, wherein both the main operating system and the standby operating system are installed with a Docker engine and a Docker Compose tool; A shared storage area configuration module, configured to configure a shared storage area accessible to both the main operating system and the standby operating system in the HDD standby storage; An information collection and storage module, configured to build a timed task in the main operating system to collect image information and configuration information of the containerized service, and store the image information and the configuration information into the shared storage area through an incremental backup mechanism; A switching and reconstruction module, configured to preset a system abnormal restart switching mechanism in the management board of the server, switch to the standby operating system for startup when the main operating system fails to start, and reconstruct the containerized service based on the image information and the configuration information in the shared storage area.

[0014] A third aspect of the present invention provides a server, which includes: a memory and at least one processor, wherein instructions are stored in the memory, and the memory and the at least one processor are interconnected through a line; The at least one processor invokes the instructions in the memory to enable the server to execute the containerized service recovery method based on a dual storage architecture according to any one of the first aspects of the present invention.

[0015] A fourth aspect of the present invention provides a computer-readable storage medium, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the containerized service recovery method based on a dual storage architecture according to any one of the first aspects of the present invention.

[0016] Beneficial effects: The present invention provides a containerized service recovery method, system and related devices based on a dual storage architecture. The method includes building a server including an SSD main storage and an HDD standby storage; setting a main operating system of a containerized service in the main storage and setting a standby operating system of the main operating system in the standby storage; configuring a shared storage area accessible to both the main and standby operating systems in the standby storage; building a timed task in the main operating system to collect image information and configuration information of the containerized service and storing them into the shared storage area through an incremental backup mechanism; presetting a system abnormal restart switching mechanism in the management board of the server, switching to the standby operating system for startup when the main operating system fails to start, and reconstructing the containerized service based on the image information and the configuration information in the shared storage area. The present invention utilizes a dual storage architecture and an incremental backup technology for containerized service recovery, and has stronger disaster tolerance ability and lower storage overhead. Description of the Drawings

[0017] Figure 1 Schematic diagram of an embodiment of a containerized service recovery method based on a dual - storage architecture according to the present invention; Figure 2 Interaction timing diagram of a containerized service recovery method based on a dual - storage architecture according to the present invention; Figure 3 Schematic diagram of an embodiment of a containerized service system based on a dual - storage architecture according to the present invention; Figure 4 Schematic diagram of an embodiment of a server according to the present invention. Detailed Embodiments

[0018] Terms such as "first", "second", "third", "fourth", etc. (if any) in the description, claims and above - mentioned drawings of the present invention are used to distinguish similar objects and do not necessarily need to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments described here can be implemented in an order different from that illustrated or described here. In addition, the terms "comprising" or "having" and any variations thereof are intended to cover non - exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these process, method, product or device.

[0019] For ease of understanding, the specific processes of the embodiments of the present invention are described below. Please refer to Figure 1 In the first aspect of the present invention, a containerized service recovery method based on a dual - storage architecture is provided, including: S100. Set up a server including an SSD main storage and an HDD backup storage; In the present invention, a dual - storage cooperation mechanism is used. Main storage (SSD): As the main running medium, it bears the daily operation of the operating system and container services, and uses its high read - write performance to ensure service efficiency. Backup storage (HDD): As the backup data storage medium and the backup system running medium, it utilizes its capacity and stability advantages.

[0020] S200. Set the main operating system of the containerized service in the main SSD storage and set the backup operating system of the main operating system in the backup HDD storage. Both the main operating system and the backup operating system are installed with Docker Engine and Docker Compose tools. An exemplary scenario for this step of the present invention can be to install a compatible operating system (such as a Linux distribution) in the main SSD storage and the backup HDD storage respectively, and install Docker Engine and Docker Compose tools in the primary and backup systems to deploy the running environment of the containerized service.

[0021] S300. Configure a shared storage area accessible to both the main operating system and the backup operating system in the backup HDD storage; in the present invention, this step mainly involves planning a partition in the backup HDD storage as the shared storage area (for example, formatting and mounting it to / opt), and through specific configurations (such as mounting (e.g., fstab) or symbolic links), enabling both the main operating system and the backup operating system to access the same shared directory (such as / opt) located on the HDD storage. This shared directory is used to store backup data, recovery scripts, and possibly shared application data. That is, in an alternative embodiment of the present invention, this step may include: partitioning a partition in the backup HDD storage as the shared storage area; connecting the main operating system and the backup operating system to the backup directory of the shared storage area through mounting technology or symbolic link technology.

[0022] S400. Build a timed task in the main operating system to collect the image information and configuration information of the containerized service, and store the image information and the configuration information to the shared storage area through an incremental backup mechanism; in an alternative embodiment of the present invention, this step may include: creating a Cron timed task in the main operating system to start a preset backup script at a preset period; obtaining the image information and configuration information used by the currently running containerized service in the main operating system based on the Docker API through the backup script; comparing the current image information with the last backup metadata stored in the shared storage area to identify the newly added or changed image information; exporting the newly added or changed image information as an image file through the gzip tool and storing it in the shared storage area; updating the configuration information to the list of paths of the orchestration configuration file and saving it to the shared storage area; updating the backup metadata in the shared storage area to reflect the latest image state after this backup.

[0023] Specifically, the technical solution of the present invention uses an intelligent incremental backup mechanism. When the main storage system (SSD) is running normally, the backup script is automatically triggered through a scheduled task (such as Cron). The backup script automatically collects key information of the currently running containers, including but not limited to the container image ID, image tag, and the path of the corresponding docker-compose configuration file.

[0024] Image backup: By comparing the images used by the currently running containers with the image information (such as image ID) recorded in the previous backup, only perform the docker save operation on the newly added or changed images, and compress and package them (such as.tar format) and store them in the shared storage area (HDD / opt).

[0025] Configuration backup: Record the list of paths of the docker-compose files on which the running containers depend, and store them in the shared storage area.

[0026] Secure storage: All backup data (image files, list of Compose file paths, metadata information) are stored in the shared area of the backup storage (HDD) with relatively high reliability to prevent backup loss due to the failure of the main storage (SSD).

[0027] S500. A system exception restart switching mechanism is preset in the management board of the server. When the main operating system fails to start, switch to the backup operating system to start, and reconstruct the containerized service based on the image information and the configuration information in the shared storage area.

[0028] In an optional implementation manner of the present invention, presetting the system exception restart switching mechanism in the management board of the server includes: setting a monitoring agent program in the management board of the server; regularly sending heartbeat data packets to the management interface of the SSD main storage through the monitoring agent program; if the management board does not receive a response from the management interface, it is determined that the SSD main storage fails and the main operating system is restarted; when the main operating system fails to restart multiple times, switch to the backup operating system in the HDD backup storage to start. Specifically, in the present invention, the fault detection mainly depends on the monitoring mechanism at the server hardware or BIOS level. For example, regularly send a heartbeat to the management interface of the storage through the monitoring agent program. If the heartbeat times out, the management board determines that the main system (SSD) fails and attempts to restart. After continuously failing to start from the SSD multiple times (for example, 3 times), the BIOS automatically switches the boot order to the backup storage (HDD).

[0029] In an alternative embodiment of the present invention, when the primary operating system fails to start, switching to the backup operating system for startup and reconstructing the containerized service based on the mirror information and the configuration information in the shared storage area includes: After the backup operating system starts, execute a pre-set recovery script; in the present invention, the BIOS automatically boots the backup operating system from the backup storage (HDD) according to a preset rule after the primary operating system (SSD) fails to start. After the backup operating system (HDD) starts, it automatically detects that it is currently running in the backup environment through a startup script or a specific service and triggers the recovery script (for example, the recovery mode of backup-images.py restore).

[0030] Read the latest backup metadata and the list of orchestration configuration file paths from the shared storage area through the recovery script; in this step, the recovery script will read the backup metadata in the shared storage area (HDD / opt), find the list of images to be restored, and read the list of paths of the docker-compose files backed up in the shared storage area.

[0031] Load the backed-up image files from the shared storage area to the container running environment of the backup operating system through the recovery script; in this step, the recovery script will execute the docker load command to load the image.tar file stored in the shared area into the current Docker environment. More specifically, this step may include: traversing all the image IDs to be restored recorded in the backup metadata through the recovery script; for each image ID, checking whether the image file corresponding to the image ID exists in the shared storage area; if the image file corresponding to the image ID exists in the shared storage area, then decompress the image file through the gunzip tool and load it into the container running environment of the backup operating system. For this step, the script will traverse all the image IDs recorded in info.json. For each image ID, check whether its corresponding.tar (or.tar.gz) file exists in the / opt / docker-images-backup / data / directory. If it exists, then execute docker load -i / opt / docker-images-backup / data / <image_id>.tar (or use gunzip | docker load to process the compressed package), and record the loading log.

[0032] According to the read list of the orchestration configuration file paths through the recovery script, recreate and start the containerized service using the corresponding configuration files and the loaded image files. Specifically, this step may include: for each path in the list of the orchestration configuration file paths, execute the command to start the containerized service and run it in the background; according to the command to start the containerized service and run it in the background, create a network and volumes based on the configuration file, and start the containerized service using the loaded image file. The script reads the list of the docker-compose file paths in compose_files.json. In this step, for each path in the list, the script will execute the command "docker-compose -f <compose_file_path> up -d". Docker Compose will automatically create a network and volumes (if required and configured) according to the configuration file, and start the containerized service using the loaded image. The interaction sequence diagram of the containerized service recovery method based on the dual storage architecture of the present invention can be as shown in Figure 2 shown.

[0033] To better understand the technical solution of the present invention, an exemplary embodiment of the present invention can be as follows: (I) System initialization and deployment phase Hardware preparation: Configure a server with at least one SSD and one HDD.

[0034] Operating system installation: Install a compatible operating system (such as a Linux distribution) on the SSD and the HDD respectively.

[0035] Shared storage area configuration: Plan a partition on the HDD as the shared storage area (for example, format and mount it to / opt). Configure the SSD system and the HDD system to ensure that they can both access (for example, mount through fstab) the shared partition on the HDD to the same mount point (such as / opt) when starting up.

[0036] Operating environment deployment: Install the Docker engine and the Docker Compose tool on both the SSD system and the HDD system.

[0037] Script and component deployment: Deploy the core backup and recovery script (such as backup-restore.py, including backup and recovery logic) and the initialization script (such as setup.sh) to the system (which can be distributed through an application component package or a configuration management tool). Deploy the monitoring agent program (for heartbeat detection, etc.) that may be required.

[0038] Initialization Execution (setup.sh): Execute setup.sh during the first deployment or when initialization is required. This script first detects the current running environment (SSD or HDD).

[0039] In the SSD environment: Create a directory structure for storing backup data (e.g., / opt / docker-images-backup / data and / opt / docker-images-backup / metadata) in the shared storage area (HDD / opt). tadata).

[0040] Set up a cron job (write to crontab) to periodically call the backup function of the backup and restore script (python3 / path / to / backup-image.py backup).

[0041] In the HDD environment: Configure the necessary startup services or scripts to automatically trigger the restore function of the backup and restore script (python3 / path / to / backup-restore.py restore) after the system starts up BIOS / Hardware Configuration: Configure the BIOS boot order to prioritize booting from the SSD by default. Enable or configure the hardware-level fault detection and boot switching mechanism.

[0042] (II) Runtime Backup Phase (SSD System Running) Timed Trigger: The Cron timed task on the SSD system starts the backup script (backup-restore.py --mode backup) at a preset interval (e.g., every day at midnight).

[0043] Information Collection: The script obtains the list of currently running containers and their used image IDs, Tags, and the paths of associated docker-compose files through the Docker API.

[0044] Incremental Image Backup: The script reads the metadata of the previous backup (e.g., the image list stored in / opt / docker- images-backup / metadata / info.json), and compares the current running image list with the previous backup list.

[0045] For newly added images or images with changed IDs, call docker inspect to obtain detailed information, and then use docker save <image_id> -o / opt / docker-images-backup / data / <image_id>.tar to save the image to the shared storage area.

[0046] If compression is adopted, the command is docker save <image_id> | gzip > / opt / docker-images -backup / data / <image_id>.tar.gz.

[0047] Configuration information backup: Update and save the list of all docker-compose file paths involved in this backup to the metadata file in the shared storage area (for example, / opt / docker-images-backup / metadata / compose_files.json).

[0048] Metadata update: Update the backup metadata file (info.json) to record the information of all active images at the completion of this backup.

[0049] Logging: Record key steps of the backup process, images successfully backed up, errors encountered, etc. to a log file (for example, stored in the shared area / opt / logs / backup.log).

[0050] (III) Fault recovery phase (after the HDD system starts) Fault detection and switching: As mentioned before, the SSD fault detection and startup switch to the HDD are completed by the hardware / BIOS layer.

[0051] Recovery trigger: After the HDD system starts, the preset startup script or service detects that the current environment is in the recovery mode and automatically executes the recovery command (backup-restore.py restore).

[0052] Read backup information: The recovery script accesses the shared storage area (HDD / opt), reads the latest backup metadata (info.json) and the Compose file list (compose_files.json).

[0053] Load images: The script traverses all the image IDs recorded in info.json. For each image ID, check whether its corresponding.tar (or.tar.gz) file exists in / opt / docker-images-backup Under the / data / directory. If it exists, execute docker load -i / opt / docker-images-backup / data / <image_id>.tar (or use gunzip|docker load to process the compressed package), and record the loading log.

[0054] Rebuild the service: The script reads the list of docker-compose file paths in compose_files.json. For each path in the list, execute the command docker-compose -f <compose_file_path> up -d. Docker Compose will automatically create networks, volumes (if needed and configured), and start the containerized service using the loaded images according to the configuration file.

[0055] Service verification: After the recovery script finishes execution, it is possible to confirm whether the core service has been successfully started and is running through a simple health check or monitoring system.

[0056] Recovery completed: The containerized service resumes operation on the HDD backup system and provides services externally. Subsequently, it can be decided whether to repair / replace the SSD and migrate the service back according to the policy.

[0057] Generally speaking, compared with the prior art, the present invention has the following beneficial effects: 1. High availability: Through the dual storage architecture and automatic switching mechanism, the risk of service interruption caused by single-point storage failure is significantly reduced.

[0058] 2. Fast recovery: By using the incremental backup and pre-loaded image mechanism, as well as the automated service rebuilding process, the mean time to recover (RTO) is greatly shortened.

[0059] 3. Efficient backup: The incremental backup mechanism only backs up the changed images, significantly reducing the storage space and time overhead required for backup.

[0060] 4. Recovery integrity: Not only the container images are backed up, but also the service orchestration configuration (Compose file) is backed up to ensure that the service can resume operation with the correct configuration and dependencies.

[0061] 5. Strong adaptability: It is particularly suitable for scenarios such as edge computing that have high requirements for service continuity and deployment environment (which may have hardware limitations).

[0062] See Figure 3, the second aspect of the present invention provides a containerized service system based on a dual - storage architecture. The containerized service system based on the dual - storage architecture includes: A server building module 10 for building a server including an SSD main storage and an HDD backup storage; A system setting module 20 for setting the main operating system of the containerized service in the SSD main storage and setting the backup operating system of the main operating system in the HDD backup storage. Both the main operating system and the backup operating system are installed with Docker engines and Docker Compose tools; A shared storage area configuration module 30 for configuring a shared storage area in the HDD backup storage that can be accessed by both the main operating system and the backup operating system; An information collection and storage module 40 for constructing a timed task in the main operating system to collect the image information and configuration information of the containerized service, and storing the image information and the configuration information into the shared storage area through an incremental backup mechanism; A switching and reconstruction module 50 for presetting a system abnormal restart switching mechanism in the management board of the server, switching to the backup operating system for startup when the main operating system fails to start, and reconstructing the containerized service based on the image information and the configuration information in the shared storage area.

[0063] In an optional implementation manner of the second aspect of the present invention, the information collection and storage module includes: A task setting unit for creating a Cron timed task in the main operating system and starting a preset backup script at a preset period; An information acquisition unit for obtaining the image information and configuration information used by the currently running containerized service in the main operating system through the backup script based on the Docker API; An image comparison unit for comparing the current image information with the last backup metadata stored in the shared storage area to identify the newly added or changed image information; An image storage unit for exporting the newly added or changed image information as an image file through the gzip tool and storing it in the shared storage area; A configuration update unit for updating the configuration information to the orchestration configuration file path list and saving it to the shared storage area; A metadata update unit for updating the backup metadata in the shared storage area to reflect the latest image state after this backup.

[0064] In an optional implementation manner of the second aspect of the present invention, the switching and reconstruction module includes: A recovery script execution unit, configured to execute a preset recovery script after the standby operating system is started; A data list acquisition unit, configured to read the latest backup metadata and the list of orchestration configuration file paths from the shared storage area through the recovery script; An image loading unit, configured to load the backed-up image file from the shared storage area into the container running environment of the standby operating system through the recovery script; A service start unit, configured to recreate and start a containerized service according to the read list of orchestration configuration file paths, using the corresponding configuration file and the loaded image file through the recovery script.

[0065] In an optional implementation manner of the second aspect of the present invention, the image loading unit includes: An ID traversal subunit, configured to traverse all image IDs to be recovered recorded in the backup metadata through the recovery script; A file check subunit, configured to check whether the image file corresponding to each image ID exists in the shared storage area; A file loading subunit, configured to, if the image file corresponding to the image ID exists in the shared storage area, unzip the image file through a gunzip tool and then load it into the container running environment of the standby operating system.

[0066] In an optional implementation manner of the second aspect of the present invention, the service start unit includes: A service command start subunit, configured to execute a command to start a containerized service and run it in the background for each path in the list of orchestration configuration file paths; A service reconstruction subunit, configured to create a network and volumes according to a configuration file through the command to start a containerized service and run it in the background, and start the containerized service using the loaded image file.

[0067] In an optional implementation manner of the second aspect of the present invention, the switching and reconstruction module further includes: An agent program setting unit, configured to set a monitoring agent program in the management board of the server; A heartbeat sending unit, configured to periodically send heartbeat data packets to the management interface of the SSD main storage through the monitoring agent program; A system restart unit, configured to determine that the SSD main storage fails and restart the main operating system if the management board does not receive a response from the management interface; A system switching unit, configured to switch to start the standby operating system in the HDD standby storage when the main operating system fails to restart multiple times.

[0068] In an optional implementation manner of the second aspect of the present invention, the shared storage area configuration module includes: A partition division unit, configured to divide a partition in the HDD standby storage as the shared storage area; A directory linking unit, configured to connect the main operating system and the standby operating system to a backup directory of the shared storage area through a mounting technology or a symbolic link technology.

[0069] Figure 4 FIG. is a schematic structural diagram of a server provided by an embodiment of the present invention. The server may vary greatly due to different configurations or performances, and may include one or more processors 60 (central processing units, CPUs) (for example, one or more processors) and a memory 70, and one or more storage media 80 for storing application programs or data (for example, one or more mass storage devices). Among them, the memory and the storage media may be transient storage or persistent storage. The program stored in the storage media may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Further, the processor may be configured to communicate with the storage media and execute a series of instruction operations in the storage media on the server.

[0070] The server of the present invention may further include one or more power supplies 90, one or more wired or wireless network interfaces 100, one or more input / output interfaces 110, and / or one or more operating systems, such as Windows Serve, Mac OS X, Unix, Linux, FreeBSD, and so on. Those skilled in the art can understand that Figure 4 The server structure shown does not limit the server, and may include more or fewer components than shown, or combine certain components, or arrange different components.

[0071] The present invention further provides a computer-readable storage medium. The computer-readable storage medium may be a non-volatile computer-readable storage medium, or may also be a volatile computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions run on a computer, the computer is caused to execute the steps of the containerized service system based on a dual storage architecture.

[0072] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems or system and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0073] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0074] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments or equivalently replace some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A containerized service recovery method based on a dual storage architecture, characterized in that, Including: Set up a server including an SSD main storage and an HDD backup storage; Set up the main operating system of the containerized service in the SSD main storage and set the backup operating system of the main operating system in the HDD backup storage. Both the main operating system and the backup operating system are installed with Docker Engine and Docker Compose tools; Configure a shared storage area accessible to both the main operating system and the backup operating system in the HDD backup storage; Build a timed task in the main operating system to collect the image information and configuration information of the containerized service, and store the image information and the configuration information in the shared storage area through an incremental backup mechanism; Pre-set a system abnormal restart switching mechanism in the management board of the server. When the main operating system fails to start, switch to the backup operating system to start, and reconstruct the containerized service based on the image information and the configuration information in the shared storage area.

2. The method for restoring containerized services based on a dual storage architecture according to claim 1, wherein The building a timed task in the main operating system to collect the image information and configuration information of the containerized service, and storing the image information and the configuration information in the shared storage area through an incremental backup mechanism includes: Create a Cron timed task in the main operating system and start a pre-set backup script at a preset period; Obtain the image information and configuration information used by the currently running containerized service in the main operating system based on the Docker API through the backup script; Compare the current image information with the last backup metadata stored in the shared storage area to identify the newly added or changed image information; Export the newly added or changed image information as an image file through the gzip tool and store it in the shared storage area; Update the configuration information to the list of paths of the orchestration configuration files and save it in the shared storage area; Update the backup metadata in the shared storage area to reflect the latest image status after this backup.

3. The method for restoring containerized services based on a dual storage architecture according to claim 2, wherein, The switching to the backup operating system to start when the main operating system fails to start, and reconstructing the containerized service based on the image information and the configuration information in the shared storage area includes: When the backup operating system starts, execute a pre-set recovery script; Read the latest backup metadata and the list of paths of the orchestration configuration files from the shared storage area through the recovery script; Load the backed-up image files from the shared storage area into the container running environment of the backup operating system through the recovery script; Re-create and start the containerized service according to the list of paths of the orchestration configuration files read through the recovery script, using the corresponding configuration files and the loaded image files.

4. The method for restoring containerized services based on a dual storage architecture according to claim 2, wherein The loading the backed-up image files from the shared storage area into the container running environment of the backup operating system through the recovery script includes: Traverse all the image IDs to be restored recorded in the backup metadata through the recovery script; For each of the mirror IDs, check whether the mirror file corresponding to the mirror ID exists in the shared storage area; If the mirror file corresponding to the mirror ID exists in the shared storage area, use the gunzip tool to decompress the mirror file and then load it into the container running environment of the standby operating system.

5. The method for restoring containerized services based on a dual storage architecture according to claim 2, wherein The step of using the recovery script to recreate and start the containerized service according to the read list of the arrangement configuration file paths, using the corresponding configuration files and the loaded mirror files includes: For each path in the list of the arrangement configuration file paths, execute the command to start the containerized service and run it in the background; According to the command to start the containerized service and run it in the background, create a network and volumes according to the configuration file, and start the containerized service using the loaded mirror file.

6. The method for restoring containerized services based on a dual storage architecture according to claim 1, wherein The step of presetting a system abnormal restart switching mechanism in the management board of the server includes: Set a monitoring agent program in the management board of the server; Use the monitoring agent program to periodically send heartbeat data packets to the management interface of the SSD main storage; If the management board does not receive a response from the management interface, determine that the SSD main storage fails and restart the main operating system; When the main operating system fails to restart multiple times, switch to start the standby operating system in the HDD standby storage.

7. The method for restoring containerized services based on a dual storage architecture according to claim 6, wherein The step of configuring a shared storage area in the HDD standby storage that can be accessed by both the main operating system and the standby operating system includes: Partition a partition in the HDD standby storage as the shared storage area; Use the mounting technology or symbolic link technology to connect the main operating system and the standby operating system to the backup directory of the shared storage area.

8. A containerized service system based on a dual storage architecture, characterized in that, The containerized service system based on the dual-storage architecture includes: A server building module, which is used to build a server including an SSD main storage and an HDD standby storage; A system setting module, which is used to set the main operating system of the containerized service in the SSD main storage and set the standby operating system of the main operating system in the HDD standby storage, and both the main operating system and the standby operating system are installed with Docker engines and Docker Compose tools; A shared storage area configuration module, which is used to configure a shared storage area in the HDD standby storage that can be accessed by both the main operating system and the standby operating system; An information collection and storage module, which is used to build a timed task in the main operating system to collect the mirror information and configuration information of the containerized service, and store the mirror information and the configuration information into the shared storage area through an incremental backup mechanism; A switching and reconstruction module, which is used to preset a system abnormal restart switching mechanism in the management board of the server, switch to start the standby operating system when the main operating system fails to start, and reconstruct the containerized service based on the mirror information and the configuration information in the shared storage area.

9. A server, characterized in that, The server includes: a memory and at least one processor, instructions are stored in the memory, and the memory and the at least one processor are interconnected by a line; The at least one processor invokes the instructions in the memory to cause the server to execute the containerized service recovery method based on a dual storage architecture according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the containerized service recovery method based on a dual storage architecture according to any one of claims 1-7.

Images