Containerized service recovery method, system and related equipment based on dual storage architecture

Abstract

The present invention provides a containerized service recovery method, system, and related equipment based on a dual storage architecture. The method includes building a server including SSD primary storage and HDD backup storage; setting a main operating system of the containerized service in the main storage and setting a backup operating system of the main operating system in the backup storage; configuring a shared storage area accessible to both the main and backup operating systems in the backup storage; constructing a scheduled task in the main operating system to collect image information and configuration information of the containerized service and storing it in the shared storage area through an incremental backup mechanism; presetting a system abnormal restart switching mechanism in the server's management board, switching to the backup operating system when the main operating system fails to start, and rebuilding the containerized service based on the image information and configuration information in the shared storage area. The present invention utilizes the dual storage architecture and incremental backup technology to recover the containerized service, with stronger disaster recovery capabilities 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 equipment 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 a disaster and minimize unplanned downtime.

[0003] Existing server disaster recovery solutions often have the following technical flaws: 1. Single point failure risk: The architecture relies on a single storage medium. Once the storage fails, it will lead to service interruption and data loss risks. 2. Backup efficiency and storage overhead: The traditional full backup mechanism not only takes up a large amount of storage space, but the backup process also takes a long time. 3. Excessive recovery time: After a failure occurs, the process of restoring 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 orchestration configuration of the container (such as the docker-compose file) and the recovery of dependent images are also crucial. Traditional solutions may ignore this link or perform incomplete recovery.

[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 equipment based on a dual storage architecture. The main purpose of the present invention is to solve the technical problems mentioned in the background technology of the existing technology.

[0006] A first aspect of the present invention provides a containerized service recovery method based on a dual storage architecture, comprising:

[0007] Build a server with SSD primary storage and HDD backup storage;

[0008] Setting a main operating system of a containerized service in the SSD main storage and setting a backup operating system of the main operating system in the HDD backup storage, wherein both the main operating system and the backup operating system are installed with a Docker engine and a Docker Compose tool;

[0009] Configuring a shared storage area in the HDD backup storage that is accessible to both the primary operating system and the backup operating system;

[0010] Constructing a scheduled 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;

[0011] A system abnormal restart switching mechanism is preset in the management board of the server. When the main operating system fails to start, it switches to the backup operating system for startup, and rebuilds the containerized service based on the image information and the configuration information in the shared storage area.

[0012] In an optional implementation of the first aspect of the present invention, constructing a scheduled 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 includes:

[0013] Creating a Cron scheduled task in the main operating system to start a preset backup script according to a preset period;

[0014] Obtaining, through the backup script and based on the Docker API, the image information and configuration information currently used by the main operating system to run the containerized service;

[0015] Comparing the current mirror information with the last backup metadata stored in the shared storage area to identify newly added or changed mirror information;

[0016] Exporting the newly added or changed image information into an image file through the gzip tool and storing it in the shared storage area;

[0017] Updating the configuration information into the orchestration configuration file path list and saving it to the shared storage area;

[0018] The backup metadata in the shared storage area is updated to reflect the latest mirror status after the backup.

[0019] In an optional implementation of the first aspect of the present invention, when the primary operating system fails to start, switching to the backup operating system for startup, and rebuilding the containerized service based on the image information and the configuration information in the shared storage area includes:

[0020] When the standby operating system is started, a preset recovery script is executed;

[0021] Reading the latest backup metadata and the orchestration configuration file path list from the shared storage area through the recovery script;

[0022] Loading the backed-up image file from the shared storage area to the container operating environment of the standby operating system through the recovery script;

[0023] The recovery script recreates and starts the containerized service based on the read orchestration configuration file path list using the corresponding configuration file and the loaded image file.

[0024] In an optional implementation of the first aspect of the present invention, loading the backed-up image file from the shared storage area to the container runtime environment of the standby operating system through the recovery script includes:

[0025] Traverse all image IDs that need to be restored recorded in the backup metadata through the recovery script;

[0026] For each of the image IDs, checking whether the image file corresponding to the image ID exists in the shared storage area;

[0027] If the image file corresponding to the image ID exists in the shared storage area, the image file is decompressed by the gunzip tool and then loaded into the container operating environment of the backup operating system.

[0028] In an optional implementation of the first aspect of the present invention, recreating and starting the containerized service using the corresponding configuration file and the loaded image file according to the read orchestration configuration file path list by the recovery script includes:

[0029] For each path in the orchestration configuration file path list, execute a command to start the containerized service and run it in the background;

[0030] By starting the containerized service and running the command in the background, a network and volume are created according to the configuration file, and the loaded image file is used to start the containerized service.

[0031] In an optional implementation of the first aspect of the present invention, the presetting of a system abnormal restart switching mechanism in the management board of the server includes:

[0032] Setting a monitoring agent program in the management board of the server;

[0033] Sending heartbeat data packets to the management interface of the SSD primary storage regularly through the monitoring agent program;

[0034] If the management board does not receive a response from the management interface, it determines that the SSD primary storage is faulty and restarts the main operating system;

[0035] When the main operating system fails to restart multiple times, it switches to the backup operating system in the HDD backup storage to start.

[0036] In an optional implementation manner of the first aspect of the present invention, configuring a shared storage area accessible to both the primary operating system and the backup operating system in the HDD backup storage includes:

[0037] Dividing a partition in the HDD backup storage as the shared storage area;

[0038] The primary operating system and the backup operating system are connected to the backup directory of the shared storage area through a mounting technology or a symbolic link technology.

[0039] A 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 comprising:

[0040] Server construction module, used to build a server with SSD primary storage and HDD backup storage;

[0041] a system setting module, configured to set a primary operating system of the containerized service in the SSD primary storage and a backup operating system of the primary operating system in the HDD backup storage, wherein both the primary operating system and the backup operating system are installed with a Docker engine and a Docker Compose tool;

[0042] A shared storage area configuration module, configured to configure a shared storage area in the HDD backup storage that is accessible to both the primary operating system and the backup operating system;

[0043] An information collection and storage module is used to construct a scheduled 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;

[0044] A switching and reconstruction module is used to pre-set a system abnormal restart switching mechanism in the management board of the server, switch to the backup operating system for startup when the main operating system fails to start, and rebuild the containerized service based on the image information and the configuration information in the shared storage area.

[0045] A third aspect of the present invention provides a server, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line;

[0046] The at least one processor calls the instructions in the memory to enable the server to execute the containerized service recovery method based on dual storage architecture as described in any one of the first aspects of the present invention.

[0047] The fourth computer-readable storage medium of the present invention stores a computer program, and is characterized in that when the computer program is executed by a processor, it implements the containerized service recovery method based on dual storage architecture as described in any one of the first aspects of the present invention.

[0048] Beneficial effects: The present invention provides a containerized service recovery method, system and related equipment based on a dual storage architecture, the method comprising building a server including SSD primary storage and HDD backup storage; setting a main operating system of the containerized service in the main storage and setting a backup operating system of the main operating system in the backup storage; configuring a shared storage area accessible to both the main and backup operating systems in the backup storage; constructing a scheduled task in the main operating system to collect image information and configuration information of the containerized service and storing it in 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 backup operating system to start when the main operating system fails to start, and rebuilding the containerized service based on the image information and configuration information in the shared storage area. The present invention utilizes a dual storage architecture and incremental backup technology to recover containerized services, and has stronger disaster recovery capabilities and lower storage overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 This is a schematic diagram of an embodiment of a containerized service recovery method based on a dual storage architecture according to the present invention;

[0050] Figure 2 This is an interactive sequence diagram of a containerized service recovery method based on a dual storage architecture according to the present invention;

[0051] Figure 3 A schematic diagram of an embodiment of a containerized service system based on a dual storage architecture according to the present invention;

[0052] Figure 4 The figure is a schematic diagram of an embodiment of a server of the present invention. DETAILED DESCRIPTION

[0053] The terms "first," "second," "third," "fourth," and so on (if any) in the description and claims of the present invention and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that shown or described herein. In addition, the terms "including" or "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus that includes a series of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, product, or apparatus.

[0054] For ease of understanding, the specific process of the embodiment of the present invention is described below. Figure 1 The first aspect of the present invention provides a containerized service recovery method based on a dual storage architecture, comprising:

[0055] S100. Build a server with SSD primary storage and HDD backup storage. This invention utilizes a dual-storage collaboration mechanism. The primary storage (SSD) serves as the primary operating medium, carrying the daily operations of the operating system and container services, leveraging its high read and write performance to ensure service efficiency. The backup storage (HDD) serves as a backup data storage medium and backup system operating medium, leveraging its capacity and stability.

[0056] S200: Setting a primary operating system for the containerized service in the SSD primary storage and a backup operating system for the primary operating system in the HDD backup storage, wherein both the primary and backup operating systems have the Docker engine and Docker Compose tool installed. An exemplary scenario for this step of the present invention is to install compatible operating systems (e.g., Linux distributions) in the SSD primary storage and HDD backup storage, respectively, and to install the Docker engine and Docker Compose tool in the primary and backup systems to deploy the operating environment for the containerized service.

[0057] S300, configuring a shared storage area in the HDD backup storage that is accessible to both the primary operating system and the backup operating system; in the present invention, this step is mainly performed by planning a partition in the HDD backup storage as a shared storage area (for example, formatting and mounting it to / opt), and through specific configuration (such as mounting (for example, fstab) or symbolic linking), enabling both the primary operating system and the backup operating system to access the same shared directory (for example, / opt) located on the HDD storage. The shared directory is used to store backup data, recovery scripts, and possible shared application data. That is, in an optional embodiment of the present invention, this step may include: dividing a partition in the HDD backup storage as the shared storage area; connecting the primary operating system and the backup operating system to the backup directory of the shared storage area through mounting technology or symbolic linking technology.

[0058] S400, constructing a scheduled task in the main operating system to collect the image information and configuration information of the containerized service, and storing the image information and configuration information in the shared storage area through an incremental backup mechanism; in an optional embodiment of the present invention, this step may include: creating a Cron scheduled task in the main operating system to start a preset backup script according to a preset period; obtaining the image information and configuration information used by the main operating system to run the containerized service currently 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 orchestration configuration file path list and saving it to the shared storage area; updating the backup metadata in the shared storage area to reflect the latest image status after this backup.

[0059] Specifically, the technical solution of this invention uses an intelligent incremental backup mechanism. When the primary storage system (SSD) is running normally, a backup script is automatically triggered by a scheduled task (such as Cron). The backup script automatically collects key information about the currently running container, including but not limited to the container image ID, image tag, and the corresponding Docker-Compose configuration file path.

[0060] Image backup: By comparing the image used by the currently running container with the image information (such as the image ID) recorded in the last backup record, the docker save operation is performed only on the newly added or changed images, and the compressed package (such as .tar format) is stored in the shared storage area (HDD / opt).

[0061] Configuration backup: Record the path list of docker-compose files that the running container depends on and store it in a shared storage area.

[0062] Secure storage: All backup data (image files, Compose file path lists, and metadata) is stored in a shared area on a relatively reliable secondary storage device (HDD), preventing backup loss due to primary storage (SSD) failures.

[0063] S500. Preset a system abnormal restart switching mechanism in the management board of the server, switch to the backup operating system to start when the main operating system fails to start, and rebuild the containerized service based on the image information and the configuration information in the shared storage area.

[0064] In an optional embodiment of the present invention, the system abnormal restart switching mechanism pre-set 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 primary storage through the monitoring agent program; if the management board does not receive a response from the management interface, it determines that the SSD primary storage is faulty and restarts the main operating system; when the main operating system fails to restart multiple times, it switches to the backup operating system in the HDD backup storage for startup. Specifically, in the present invention, fault detection mainly relies on the monitoring mechanism at the server hardware or BIOS level. For example, a heartbeat is regularly sent 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) is faulty and attempts to restart. After multiple consecutive (for example, 3) failures to boot from the SSD, the BIOS automatically switches the boot sequence to the backup storage (HDD).

[0065] In an optional embodiment of the present invention, when the primary operating system fails to start, switching to the backup operating system for startup, and rebuilding the containerized service based on the image information and the configuration information in the shared storage area includes:

[0066] When the backup operating system is started, a preset recovery script is executed. In the present invention, the BIOS automatically boots the backup operating system from the backup storage (HDD) according to preset rules 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 a backup environment through a startup script or a specific service, and triggers a recovery script (for example, the recovery mode of backup-images.py restore).

[0067] The latest backup metadata and the orchestration configuration file path list are read from the shared storage area through the recovery script. In this step, the recovery script reads the backup metadata in the shared storage area (HDD / opt), finds the image list to be restored, and reads the docker-compose file path list backed up in the shared storage area.

[0068] The backed-up image file is loaded from the shared storage area to the container runtime environment of the backup operating system through the recovery script; in this step, the recovery script executes 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 that need 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, decompressing the image file through the gunzip tool and loading it into the container runtime environment of the backup operating system. For this step, the script traverses all the image IDs that need to be restored 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, 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.

[0069] The recovery script uses the corresponding configuration file and the loaded image file to recreate and start the containerized service according to the orchestration configuration file path list read. Specifically, this step may include: for each path in the orchestration configuration file path list, executing the start containerized service and background run command; creating a network and volume according to the configuration file through the start containerized service and background run command, and starting the containerized service using the loaded image file. The script reads the docker-compose file path list 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 the network and volume (if necessary and configured) according to the configuration file, and start the containerized service using the loaded image. The interactive sequence diagram of the containerized service recovery method based on the dual storage architecture of the present invention can be shown as follows: Figure 2 shown.

[0070] In order to better understand the technical solution of the present invention, an exemplary embodiment of the present invention can be as follows:

[0071] (1) System initialization and deployment phase

[0072] Hardware preparation: Configure a server with at least one SSD and one HDD.

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

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

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

[0076] Script and component deployment: Deploy core backup and recovery scripts (e.g., backup-restore.py, which contains backup and recovery logic) and initialization scripts (e.g., setup.sh) to the system (distributable via application component packages or configuration management tools). Deploy any monitoring agents that may be needed (for heartbeat detection, etc.).

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

[0078] In an SSD environment: Create a directory structure for storing backup data in the shared storage area (HDD / opt) (for example, / opt / docker-images-backup / data and / opt / docker-images-backup / me

[0079] tadata).

[0080] Set up a scheduled task (write it to crontab) and regularly call the backup function of the backup and recovery script (python3 / path / to / backup-image.py backup).

[0081] In HDD environment: Configure the necessary startup services or scripts to automatically trigger the restore function of the backup restore script after the system starts (python3 / path / to / backup-restore.py restore)

[0082] BIOS / Hardware Configuration: Configure the BIOS boot order, with SSD boot priority by default. Enable or configure hardware-level fault detection and boot switching mechanisms.

[0083] (2) Runtime backup phase (SSD system operation)

[0084] Scheduled triggering: The Cron scheduled task on the SSD system starts the backup script (backup-restore.py --mode backup) at a preset period (for example, every morning).

[0085] Information collection: The script obtains the list of currently running containers and their image IDs, tags, and associated docker-compose file paths through the Docker API.

[0086] Incremental image backup: The script reads the metadata of the last backup (for example, stored in / opt / docker-

[0087] The image list in images-backup / metadata / info.json is used to compare the currently running image list with the list in the last backup.

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

[0089] If compression is used, the command is docker save<image_id> |gzip> / opt / docker-images

[0090] -backup / data / <image_id> .tar.gz.

[0091] Configuration information backup: Update and save the path list of all docker-compose files involved in this backup to the metadata file in the shared storage area (for example, / opt / docker-images-backup / metadata

[0092] / compose_files.json).

[0093] Metadata update: Update the backup metadata file (info.json) to record the information of all active images when the backup is completed.

[0094] Logging: Records key steps of the backup process, successfully backed up images, encountered errors, and other information in a log file (for example, stored in the shared area / opt / logs / backup.log).

[0095] (3) Fault recovery phase (after HDD system startup)

[0096] Fault detection and switching: As mentioned above, SSD fault detection and boot switching to the HDD are completed by the hardware / BIOS layer.

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

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

[0099] Loading image: The script traverses all the image IDs that need to be restored recorded in info.json. For each image ID, check whether its corresponding .tar (or .tar.gz) file exists in / opt / docker-images-backup

[0100] / data / directory. If it exists, execute docker load-i / opt / docker-images-backup / data /

[0101] <image_id> .tar (or use gunzip|docker load to process the compressed package) and record the loading log.

[0102] Rebuild service: The script reads the docker-compose file path list in compose_files.json. For each path in the list, execute the command docker-compose -f<compose_file_path>

[0103] up-d. Docker Compose automatically creates the network and volume (if necessary and configured) according to the configuration file, and starts the containerized service using the loaded image.

[0104] Service verification: After the recovery script is executed, you can use a simple health check or monitoring system to confirm whether the core services have been successfully started and running.

[0105] Recovery Complete: The containerized service is back up and running on the HDD backup system, providing services externally. A policy can be used to determine whether to repair or replace the SSD and restore the service.

[0106] In general, compared with the prior art, the present invention has the following beneficial effects:

[0107] 1. High availability: The dual storage architecture and automatic switching mechanism significantly reduce the risk of service interruption caused by single point storage failure.

[0108] 2. Fast recovery: Utilizing incremental backup and pre-loaded image mechanisms, as well as automated service reconstruction processes, the recovery time to failure (RTO) is greatly shortened.

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

[0110] 4. Recovery integrity: Not only the container image is backed up, but also the service orchestration configuration (Compose file) is backed up to ensure that the service can be restored with the correct configuration and dependencies.

[0111] 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).

[0112] See also Figure 3 A second aspect of the present invention provides a containerized service system based on a dual storage architecture, the containerized service system based on a dual storage architecture comprising:

[0113] A server building module 10 is used to build a server including SSD primary storage and HDD backup storage;

[0114] A system setting module 20 is configured to set a main operating system of the containerized service in the SSD primary storage and a backup operating system of the main operating system in the HDD backup storage, wherein both the main operating system and the backup operating system are installed with a Docker engine and a Docker Compose tool;

[0115] A shared storage area configuration module 30, configured to configure a shared storage area in the HDD backup storage that is accessible to both the primary operating system and the backup operating system;

[0116] An information collection and storage module 40 is configured to construct a scheduled task in the main operating system to collect image information and configuration information of the containerized service, and store the image information and configuration information in the shared storage area through an incremental backup mechanism;

[0117] The switching and reconstruction module 50 is used to pre-set the system abnormal restart switching mechanism in the management board of the server, switch to the backup operating system to start when the main operating system fails to start, and rebuild the containerized service based on the image information and the configuration information in the shared storage area.

[0118] In an optional implementation of the second aspect of the present invention, the information collection and storage module includes:

[0119] A task setting unit, configured to create a Cron scheduled task in the main operating system and start a preset backup script according to a preset period;

[0120] An information acquisition unit, configured to acquire, through the backup script and based on the Docker API, image information and configuration information used by the main operating system currently running the containerized service;

[0121] an image comparison unit, configured to compare the current image information with the last backup metadata stored in the shared storage area, and identify the newly added or changed image information;

[0122] An image storage unit, configured to export the newly added or changed image information as an image file through a gzip tool and then store it in the shared storage area;

[0123] A configuration updating unit, configured to update the configuration information into the orchestration configuration file path list and save the updated configuration information into the shared storage area;

[0124] The metadata updating unit is used to update the backup metadata in the shared storage area to reflect the latest mirror status after the backup.

[0125] In an optional implementation of the second aspect of the present invention, the switching and reconstruction module includes:

[0126] A recovery script execution unit, configured to execute a preset recovery script after the standby operating system is started;

[0127] a data list acquiring unit, configured to read the latest backup metadata and the orchestration configuration file path list from the shared storage area through the recovery script;

[0128] An image loading unit, configured to load the backed-up image file from the shared storage area to the container runtime environment of the standby operating system through the recovery script;

[0129] A service startup unit is used to recreate and start the containerized service using the corresponding configuration file and the loaded image file according to the read orchestration configuration file path list through the recovery script.

[0130] In an optional implementation of the second aspect of the present invention, the image loading unit includes:

[0131] An ID traversal subunit, configured to traverse all image IDs that need to be restored recorded in the backup metadata using the recovery script;

[0132] A file checking subunit, configured to check, for each image ID, whether the image file corresponding to the image ID exists in the shared storage area;

[0133] The file loading subunit is used to decompress the image file using the gunzip tool and then load it into the container operating environment of the backup operating system if the image file corresponding to the image ID exists in the shared storage area.

[0134] In an optional implementation of the second aspect of the present invention, the service initiation unit includes:

[0135] A service command startup subunit, configured to execute a command to start a containerized service and run it in the background for each path in the orchestration configuration file path list;

[0136] The service reconstruction subunit is used to create a network and volume according to the configuration file by starting the containerized service and running the command in the background, and start the containerized service using the loaded image file.

[0137] In an optional implementation of the second aspect of the present invention, the switching and reconstruction module further includes:

[0138] An agent program setting unit, configured to set a monitoring agent program in the management board of the server;

[0139] A heartbeat sending unit, configured to periodically send a heartbeat data packet to the management interface of the SSD primary storage through the monitoring agent program;

[0140] a system restart unit, configured to determine that the SSD primary storage is faulty and restart the main operating system if the management board does not receive a response from the management interface;

[0141] The system switching unit is used to switch to the backup operating system in the HDD backup storage to start up when the main operating system fails to restart multiple times.

[0142] In an optional implementation of the second aspect of the present invention, the shared storage area configuration module includes:

[0143] A partition division unit, configured to divide a partition in the HDD backup storage as the shared storage area;

[0144] The directory link unit is used to connect the primary operating system and the backup operating system to the backup directory of the shared storage area through a mounting technology or a symbolic link technology.

[0145] Figure 4 The figure is a schematic diagram of the structure of a server provided by an embodiment of the present invention. This server may vary significantly depending on its configuration or performance. It may include one or more processors (central processing units, CPUs) 60 (e.g., one or more processors), memory 70, and one or more storage media 80 (e.g., one or more mass storage devices) for storing application programs or data. The memory and storage media may be either transient or persistent. The program stored on the storage medium may include one or more modules (not shown), each of which may include a series of instructions for operating on the server. Furthermore, the processor may be configured to communicate with the storage medium to execute the series of instructions stored on the storage medium on the server.

[0146] 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 and output interfaces 110, and / or one or more operating systems, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. It will be understood by those skilled in the art that Figure 4 The server structure shown does not constitute a limitation to the server, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0147] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the steps of the containerized service system based on a dual storage architecture.

[0148] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working process of the above-described system or system or unit can refer to the corresponding process in the aforementioned method embodiment and will not be repeated here.

[0149] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0150] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that the technical solutions described in the above embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A containerized service recovery method based on dual storage architecture, characterized in that: include: Build a server with SSD primary storage and HDD backup storage; Setting a main operating system of a containerized service in the SSD main storage and setting a backup operating system of the main operating system in the HDD backup storage, wherein 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 is accessible to both the primary operating system and the backup operating system, and deploying the backup and recovery script and the initialization script to the system by distributing them using an application component package or a configuration management tool; Constructing a scheduled 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 abnormal restart switching mechanism is pre-set in the management board of the server, and when the main operating system fails to start, the system switches to the backup operating system for startup, and rebuilds the containerized service based on the image information and the configuration information in the shared storage area; The step of constructing a scheduled 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: Creating a Cron scheduled task in the main operating system to start a preset backup script according to a preset period; Obtaining, through the backup script and based on the Docker API, the image information and configuration information currently used by the main operating system to run the containerized service; Comparing the current mirror information with the last backup metadata stored in the shared storage area to identify newly added or changed mirror information; Exporting the newly added or changed image information into an image file through the gzip tool and storing it in the shared storage area; Updating the configuration information into the orchestration configuration file path list and saving it to the shared storage area; Updating the backup metadata in the shared storage area to reflect the latest mirror status after the backup; The system abnormal restart switching mechanism pre-set in the management board of the server includes: Setting a monitoring agent program in the management board of the server; Sending heartbeat data packets to the management interface of the SSD primary storage regularly through the monitoring agent program; If the management board does not receive a response from the management interface, it determines that the SSD primary storage is faulty and restarts the main operating system; When the main operating system fails to restart multiple times, it switches to the backup operating system in the HDD backup storage to start.

2. The containerized service recovery method based on dual storage architecture according to claim 1 is characterized in that: The switching to the backup operating system to start when the main operating system fails to start, and rebuilding the containerized service based on the image information and the configuration information in the shared storage area includes: When the standby operating system is started, a preset recovery script is executed; Reading the latest backup metadata and the orchestration configuration file path list from the shared storage area through the recovery script; Loading the backed-up image file from the shared storage area to the container operating environment of the standby operating system through the recovery script; The recovery script recreates and starts the containerized service based on the read orchestration configuration file path list using the corresponding configuration file and the loaded image file.

3. The containerized service recovery method based on dual storage architecture according to claim 1 is characterized in that: The step of loading the backed-up image file from the shared storage area to the container operating environment of the standby operating system through the recovery script includes: Traverse all image IDs that need to be restored recorded in the backup metadata through the recovery script; For each of the image IDs, 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, the image file is decompressed by the gunzip tool and then loaded into the container operating environment of the backup operating system.

4. The containerized service recovery method based on dual storage architecture according to claim 1 is characterized in that: The re-creation and startup of the containerized service using the corresponding configuration file and the loaded image file according to the read orchestration configuration file path list by the recovery script includes: For each path in the orchestration configuration file path list, execute a command to start the containerized service and run it in the background; By starting the containerized service and running the command in the background, a network and volume are created according to the configuration file, and the loaded image file is used to start the containerized service.

5. The containerized service recovery method based on dual storage architecture according to claim 1 is characterized in that: The configuration of a shared storage area in the HDD backup storage that is accessible to both the primary operating system and the backup operating system includes: Dividing a partition in the HDD backup storage as the shared storage area; The primary operating system and the backup operating system are connected to the backup directory of the shared storage area through a mounting technology or a symbolic link technology.

6. A containerized service system based on a dual storage architecture, characterized in that: The containerized service system based on the dual storage architecture includes: Server building module, used to build a server with SSD primary storage and HDD backup storage; a system setting module, configured to set a primary operating system of the containerized service in the SSD primary storage and a backup operating system of the primary operating system in the HDD backup storage, wherein both the primary operating system and the backup 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 in the HDD backup storage that is accessible to both the primary operating system and the backup operating system, and to deploy backup and recovery scripts and initialization scripts to the system by means of application component packages or configuration management tool distribution; An information collection and storage module is used to construct a scheduled 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; a switching and reconstruction module, configured to pre-set a system abnormal restart switching mechanism in the management board of the server, switch to the backup operating system for startup when the primary operating system fails to start, and rebuild the containerized service based on the image information and the configuration information in the shared storage area; The information collection and storage module includes: A task setting unit, configured to create a Cron scheduled task in the main operating system and start a preset backup script according to a preset period; An information acquisition unit, configured to acquire, through the backup script and based on the Docker API, image information and configuration information used by the main operating system currently running the containerized service; an image comparison unit, configured to compare the current image information with the last backup metadata stored in the shared storage area, and identify the newly added or changed image information; An image storage unit, configured to export the newly added or changed image information as an image file through a gzip tool and then store it in the shared storage area; A configuration updating unit, configured to update the configuration information into the orchestration configuration file path list and save the updated configuration information into the shared storage area; Metadata update unit for updating the backup metadata in the shared storage area to reflect the latest mirror status after this backup; The switching reconstruction module also 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 a heartbeat data packet to the management interface of the SSD primary storage through the monitoring agent program; a system restart unit, configured to determine that the SSD primary storage is faulty and restart the main operating system if the management board does not receive a response from the management interface; The system switching unit is used to switch to the backup operating system in the HDD backup storage to start up when the main operating system fails to restart multiple times.

7. A server, characterized in that: The server 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 via a line; The at least one processor calls the instructions in the memory to enable the server to execute the containerized service recovery method based on the dual storage architecture according to any one of claims 1 to 5.

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

Images