A service migration disaster recovery processing method, system, device and storage medium

Abstract

This disclosure relates to the field of service migration and discloses a service migration disaster recovery processing method, system, device, and storage medium. The method includes: limiting the deployment of service instances communicating with the device to designated nodes; obtaining floating IP addresses and configuring the floating IP addresses to the designated nodes where the service instances are deployed; checking whether the status of the service instances has changed; when the status of the service instances changes, reconfiguring the floating IP addresses to the node where the service instance is located or the new node after migration. This disclosure retains the rapid migration characteristics of containers while providing reliable service-device communication; after service migration or service unhealthy status, the system handles it promptly, improving processing efficiency without human intervention, thus freeing up human resources; it has high scalability, and by configuring service instance tags, service instance health detection scripts or rules can be extended to be used for more services.

Description

Technical Field

[0001] This disclosure relates to the field of service migration technology, specifically to a service migration disaster recovery processing method, system, device, and storage medium. Background Technology

[0002] During the cloudification process, network management and control systems (hereinafter referred to as network management) are affected by factors such as node resource constraints, node failures, or human error. Service containers may migrate between different nodes, causing changes to the IP addresses that services listen on. This IP address change leads to communication problems between services that need to communicate with devices (devices record the IP address of the communicating service after communication, meaning that even after service migration, the device still records the IP address information from before the migration). Therefore, while containerization brings convenience to service operation and maintenance, it introduces communication problems with devices. The main problems are as follows:

[0003] 1) The uncertainty of service container migration makes it impossible to determine which node in the container cluster the service will be migrated to.

[0004] 2) After the service container is migrated, the IP address changes, causing communication abnormalities with the device (for example, the device cannot upload alarm information). In this scenario, the configuration needs to be updated manually.

[0005] 3) If the service is fixed and not allowed to migrate, then the container operation and maintenance features are lost, and once a node fails, it will become unavailable. Summary of the Invention

[0006] This disclosure provides a service migration disaster recovery processing method, system, device, and storage medium to solve or alleviate one or more of the above-mentioned technical problems in the prior art.

[0007] According to one aspect of this disclosure, a service migration disaster recovery processing method is provided, comprising:

[0008] The service instances that communicate with the device are deployed on the specified nodes;

[0009] Obtain a floating IP address and configure the floating IP address to the specified node where the service instance is deployed;

[0010] Check if the status of the service instance has changed;

[0011] When the status of the service instance changes, the floating IP address is reconfigured to the node where the service instance is running normally or to the new node after migration.

[0012] In one possible implementation, limiting the deployment of service instances that communicate with the device to specific nodes includes:

[0013] Identify the service instances that communicate with the device, and the nodes on which each service instance runs;

[0014] Each service instance is marked on a node to restrict the service instance to run on a specified node.

[0015] In one possible implementation, obtaining a floating IP address and configuring it to a specified node where the service instance is deployed includes:

[0016] Check if any instances of the specified service have been deployed successfully.

[0017] When it is detected that a service instance has been deployed, a available floating IP address is obtained from the available address pool;

[0018] Configure the obtained available floating IP address to the instance container running node;

[0019] After configuration, mark the floating IP address configured on the instance container running node as used.

[0020] In one possible implementation, when the state of the service instance changes, reconfiguring the floating IP address to the node where the service instance is running normally or to the new node after migration includes:

[0021] When a service instance is detected to have migrated, a floating IP deletion command is issued to the node where the service instance was located before the migration.

[0022] According to the floating IP deletion command, delete the floating IP of the node where the service instance was located before the migration;

[0023] After deletion, a floating IP configuration command is issued to the node where the migrated service instance is located;

[0024] Configure a floating IP in the node where the service instance is located after migration, according to the floating IP configuration instructions.

[0025] In one possible implementation, when the state of the service instance changes, reconfiguring the floating IP address to the node where the service instance is running normally or to the new node after migration includes:

[0026] When a service instance is found to be unhealthy, a floating IP deletion command is issued to the node where the service instance is currently located.

[0027] Delete the floating IP of the node where the service instance is currently located according to the floating IP deletion command;

[0028] After deletion, issue a floating IP configuration command to the node where the service is normal.

[0029] Configure a floating IP in the node where the instance is running normally, according to the floating IP configuration instructions.

[0030] According to one aspect of this disclosure, a service migration disaster recovery processing system is provided, comprising:

[0031] A limiting unit is used to restrict the deployment of service instances that communicate with the device to a specified node;

[0032] The deployment unit is used to obtain a floating IP address and configure the floating IP address to the specified node where the service instance is deployed;

[0033] The inspection unit is used to check whether the status of the service instance has changed.

[0034] The configuration unit is used to reconfigure the floating IP address to the node where the service instance is located when the status of the service instance changes, or to the new node after migration.

[0035] In one possible implementation, the limiting unit includes:

[0036] The determination module is used to determine the service instance that communicates with the device, and the node on which each service instance runs;

[0037] The tagging module is used to tag the node on which each service instance runs, thereby restricting the service instance to run on the specified node.

[0038] In one possible implementation, the configuration unit includes:

[0039] The detection module is used to detect whether a specified service instance has been deployed.

[0040] The acquisition module is used to obtain available floating IP addresses from the available address pool when it is detected that a service instance has been deployed.

[0041] The configuration module is used to configure the obtained available floating IP addresses onto the instance container runtime node;

[0042] The labeling module is used to mark the floating IP addresses that have been configured on the instance container's running node as used after configuration is complete.

[0043] According to one aspect of this disclosure, an apparatus is provided, comprising:

[0044] Processor and memory;

[0045] The memory is used to store computer programs, and the processor calls the computer programs stored in the memory to execute the service migration and disaster recovery processing method described above.

[0046] According to one aspect of this disclosure, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, the processor is able to perform the service migration and disaster recovery processing method described in any of the preceding claims.

[0047] This disclosure offers the following advantages: By managing predefined service instance tags and configuring floating IPs, combined with detection and arbitration modules, this disclosure makes the handling of service-device communication issues in the container domain more reliable and efficient in the disaster recovery domain. Furthermore, this disclosure supports both single-instance migration and primary / standby modes, making problem handling more dynamic, flexible, and scalable. The main advantages of this disclosure are: 1. It retains the rapid migration characteristics of containers while providing reliable service-device communication; 2. After service migration or service unhealthy status, the system handles the issue promptly, improving processing efficiency without requiring manual intervention and freeing up human resources; 3. It has high scalability; by configuring service instance tags, service instance health detection scripts or rules can be extended and applied to more services.

[0048] Details of one or more embodiments of this application are set forth in the following drawings and description. Other features and advantages of this application will become apparent from the accompanying drawings. It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not intended to limit this disclosure. Attached Figure Description

[0049] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0050] Figure 1 This is a flowchart of a service migration disaster recovery processing method according to an exemplary embodiment of the present invention;

[0051] Figure 2 This is an architecture diagram of an exemplary embodiment;

[0052] Figure 3 This is an operational flowchart of this exemplary embodiment;

[0053] Figure 4 This is a block diagram of a service migration disaster recovery processing system according to an exemplary embodiment of the present invention;

[0054] Figure 5 This is a schematic diagram of the structure of a device according to an exemplary embodiment of this invention. Detailed Implementation

[0055] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this disclosure more comprehensive and complete, and to fully convey the concept of the example embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more of the specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0056] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware units or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0057] The flowchart shown in the attached diagram is merely an illustrative example and does not necessarily include all steps. For example, some steps may be broken down, while others may be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0058] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein.

[0059] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or device that includes a series of steps or sub-modules is not necessarily limited to those steps or sub-modules that are explicitly listed, but may include other steps or sub-modules that are not explicitly listed or that are inherent to such process, method, product, or device.

[0060] Figure 1 This is a flowchart of a service migration and disaster recovery processing method according to an exemplary embodiment of the present invention, such as... Figure 1As shown, an exemplary embodiment of this disclosure provides a service migration disaster recovery processing method, including:

[0061] The service instances that communicate with the device are deployed on the specified nodes;

[0062] Obtain a floating IP address and configure the floating IP address to the specified node where the service instance is deployed;

[0063] Check if the status of the service instance has changed;

[0064] When the status of the service instance changes, the floating IP address is reconfigured to the node where the service instance is running normally or to the new node after migration.

[0065] In this embodiment, before service deployment, a specified floating IP is listened to and used to communicate with the device. After the service crashes, the service is only allowed to migrate to two or more specified nodes. After the service migrates to other nodes, there is a detection mechanism to detect whether the service has migrated. After the service detects the migration, the floating IP is moved to the migrated node to ensure that the service listening IP address does not change.

[0066] It is worth noting that this embodiment focuses on a different area than existing technologies. Existing cloud disaster recovery technologies concentrate on high availability and backup of cloud data, with services being stateless or storing data on highly available cloud storage devices. This disclosure focuses on the communication between services and devices, employing a service IP migration scheme; this embodiment differs from existing service disaster recovery principles. Existing technologies require services to support multi-instance methods, i.e., multiple service instances running simultaneously to ensure high availability. This embodiment supports high availability in single-instance scenarios, as well as cold standby for two instances (i.e., only one instance provides functionality externally at a time, while the other service instance does not provide services). Overall, existing technologies emphasize high availability and backup of data, and support multi-instance service scenarios, but are less supportive of existing single-instance or partitioned single-instance scenarios. This embodiment focuses on the communication scenario between services and devices after cloudification; it emphasizes single-instance services or cold standby scenarios for two service instances.

[0067] like Figure 2 As shown, the core components of this embodiment mainly include four parts: instance tag management module, floating IP configuration management module, service instance registration and health check execution module (hereinafter referred to as execution module); and arbitration module.

[0068] like Figure 3 As shown, this embodiment includes the following steps:

[0069] Instance tag management determines which nodes the service instances communicating with the device run on, and assigns specific tags to the nodes that a service instance can run on. This restricts the service instance to only running on the specified nodes.

[0070] Floating IP configuration management detects that after the service instance is deployed, it obtains an available floating IP address from the pool of available floating IP addresses and configures the floating IP address to the node where the service instance is deployed.

[0071] The service instance registration and health check execution module (hereinafter referred to as the execution module) periodically observes the status information of service instances and reports the service instance status information to the arbitration module. The arbitration module then takes corresponding actions based on the service status information.

[0072] The arbitration module receives information uploaded by the execution module and determines whether floating IP migration needs to be performed.

[0073] Specifically, limiting the deployment of service instances that communicate with devices to specific nodes includes:

[0074] Identify the service instances that communicate with the device, and the nodes on which each service instance runs;

[0075] Each service instance is marked on a node to restrict the service instance to run on a specified node.

[0076] In this embodiment, the instance tag management module mainly completes the following steps:

[0077] Identify which services communicate with the device, how many instances of each service are running, and on which specified nodes each instance of the service will run.

[0078] Each instance of a service can be labeled with the same tag for all hosts it can run on, while different instances can run on different hosts with different tags. Taking the service manager (assuming manager is a service) as an example, the manager-1 (service 1) instance can only run on the first and second nodes, so the first and second nodes can be labeled manager-node-1 (service node 1): manager-instance-1 (service instance 1). The manager-2 (service 2) instance can only run on the third and fourth nodes, so the third and fourth nodes can be labeled manager-node-2 (service node 2): manager-instance-2 (service instance 1). In this way, each instance of the service can be restricted to run only on the specified nodes.

[0079] Specifically, obtaining a floating IP address and configuring it to a specified node in the service instance deployment includes:

[0080] Check if any instances of the specified service have been deployed successfully.

[0081] When it is detected that a service instance has been deployed, a available floating IP address is obtained from the available address pool;

[0082] Configure the obtained available floating IP address to the instance container running node;

[0083] After configuration, mark the floating IP address configured on the instance container running node as used.

[0084] Specifically, checking whether the status of a service instance has changed includes: periodically checking whether the service instance is healthy; or periodically checking whether the service instance has been migrated.

[0085] In this embodiment, the floating IP configuration management module mainly completes the following steps:

[0086] Check if a specified service instance is deployed;

[0087] When a service instance deployment is detected, the configuration management module obtains an available floating IP address from the available address pool and configures it on the node where the instance container is running.

[0088] Once configured, the IP address will be marked as used to prevent other instances from misusing it.

[0089] Specifically, when the state of the service instance changes, reconfiguring the floating IP address to the node where the service instance is running normally or to the new node after migration includes:

[0090] When a service instance is detected to have migrated, a floating IP deletion command is issued to the node where the service instance was located before the migration.

[0091] According to the floating IP deletion command, delete the floating IP of the node where the service instance was located before the migration;

[0092] After deletion, a floating IP configuration command is issued to the node where the migrated service instance is located;

[0093] Configure a floating IP in the node where the service instance is located after migration, according to the floating IP configuration instructions.

[0094] In this embodiment, the execution module is mainly used to complete the following steps:

[0095] Retrieve the service instances and their information that need to be continuously monitored from the instance tag management module;

[0096] When a running service instance is detected on a node, the service instance, tag, node IP address, floating IP address information (if it exists), and service instance status are registered with the arbitration module so that the arbitration module can make a subsequent judgment and use it.

[0097] The execution module runs on the node specified for each service instance, and periodically checks whether the service instance is healthy or whether the service instance has been migrated. If the service instance has been migrated, the information of the migrated service container instance is registered with the arbitration module; if the service instance is unhealthy, the service instance and its status information are uploaded to the arbitration module for arbitration.

[0098] After receiving the arbitration result, the execution module removes the original floating IP from its original node and switches the floating IP to the node where the new migrated instance is located or the node where the standby instance is located.

[0099] Specifically, when the state of the service instance changes, reconfiguring the floating IP address to the node where the service instance is running normally or to the new node after migration includes:

[0100] When a service instance is found to be unhealthy, a floating IP deletion command is issued to the node where the service instance is currently located.

[0101] Delete the floating IP of the node where the service instance is currently located according to the floating IP deletion command;

[0102] After deletion, issue a floating IP configuration command to the node where the service is normal.

[0103] Configure a floating IP in the node where the instance is running normally, according to the floating IP configuration instructions.

[0104] In this embodiment, the arbitration module is mainly used to complete the following steps:

[0105] Receive information such as the service instance and status registered by the execution module;

[0106] Receive service instance health and floating IP information reported periodically by the execution module;

[0107] Based on the service instance information reported by the execution module, determine whether the service instance has been migrated or whether the service instance is unhealthy. If the service instance has been migrated, issue a floating IP switching command, that is, issue a floating IP deletion command to the execution module of the node where the original instance is located. After deletion, issue a floating IP configuration command to the execution module of the node where the migrated instance is located. If the service instance is unhealthy, issue a floating IP switching command, that is, issue a floating IP deletion command to the execution module of the node where the original instance is located. After deletion, issue a floating IP configuration command to the execution module of the node where the standby instance is located.

[0108] In summary, this embodiment limits the deployment of service instances that communicate with the device to designated nodes, and configures floating IPs on the nodes where the service instances run. Then, it periodically checks these designated service nodes to ensure the service instances are functioning correctly and have not migrated. If a service instance is detected to be malfunctioning or has migrated, an arbitration module resolves the issue, reconfiguring the floating IP address to either the node where the service instance is functioning correctly or the new node after migration. This embodiment retains the desirable characteristics of cloud-based services and ensures high availability for service-device communication without requiring any modifications to the service itself.

[0109] Figure 4 This is a block diagram of a service migration and disaster recovery processing system according to an exemplary embodiment of this invention, such as... Figure 4 As shown, an exemplary embodiment of this disclosure provides a service migration disaster recovery processing system, including:

[0110] A limiting unit is used to restrict the deployment of service instances that communicate with the device to a specified node;

[0111] The deployment unit is used to obtain a floating IP address and configure the floating IP address to the specified node where the service instance is deployed;

[0112] The inspection unit is used to check whether the status of the service instance has changed.

[0113] The configuration unit is used to reconfigure the floating IP address to the node where the service instance is located when the status of the service instance changes, or to the new node after migration.

[0114] Specifically, the limiting unit includes:

[0115] The determination module is used to determine the service instance that communicates with the device, and the node on which each service instance runs;

[0116] The tagging module is used to tag the node on which each service instance runs, thereby restricting the service instance to run on the specified node.

[0117] Specifically, the configuration unit includes:

[0118] The detection module is used to detect whether a specified service instance has been deployed.

[0119] The acquisition module is used to obtain available floating IP addresses from the available address pool when it is detected that a service instance has been deployed.

[0120] The configuration module is used to configure the obtained available floating IP addresses onto the instance container runtime node;

[0121] The labeling module is used to mark the floating IP addresses that have been configured on the instance container's running node as used after configuration is complete.

[0122] In summary, this disclosure specifies that service instances communicating with the device are deployed on designated nodes, and floating IP addresses are configured on the nodes where the service instances run. Then, these designated service nodes periodically check whether the service instances are functioning correctly and whether migration has occurred. If a service instance is detected as abnormal or has been migrated, an arbitration module decides whether to reconfigure the floating IP address to either the node where the service instance is functioning correctly (hereinafter referred to as the standby service instance node) or the new node after the service instance has been migrated. This ensures both the characteristics of the service after cloudification and the ability to maintain normal communication between the service and the device after migration, enabling rapid recovery.

[0123] Figure 5 This is a schematic diagram of the structure of a device according to an exemplary embodiment of this invention. Figure 5 As shown, corresponding to the service migration and disaster recovery processing method provided above, this disclosure also provides a device. Since the embodiment of this device is similar to the above method embodiment, the description is relatively simple; relevant details can be found in the description of the above method embodiment section. The device described below is merely illustrative. The device may include: a processor 1, a memory 2, a communication bus (i.e., the aforementioned device bus), and a lookup engine. The processor 1 and memory 2 communicate with each other via the communication bus and communicate with external systems via a communication interface. The processor 1 can invoke logical instructions in the memory 2 to execute the service migration and disaster recovery processing method.

[0124] Furthermore, the logical instructions in the aforementioned memory 2 can be implemented as software functional units and sold or used as independent products, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a 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 to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as memory chips, USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0125] On the other hand, this disclosure also provides a processor-readable storage medium storing a computer program 3, which, when executed by a processor 1, is implemented to perform the service migration and disaster recovery processing method provided in the above embodiments.

[0126] The processor-readable storage medium can be any available medium or data storage device that the processor 1 can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0127] The above are merely preferred embodiments of this disclosure. The scope of protection of this disclosure is not limited to the above embodiments. All technical solutions falling within the scope of this disclosure are protected. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of this disclosure should be considered within the scope of protection of this disclosure.

Claims

1. A service migration disaster recovery processing method, characterized in that, include: The service instances that communicate with the device are deployed on the specified nodes; Obtain a floating IP address and configure the floating IP address to the specified node where the service instance is deployed; Check if the status of the service instance has changed; When the status of the service instance changes, the floating IP address will be reconfigured to the node where the service instance is running normally or to the new node after migration. The service instance that limits communication with the device is deployed on a designated node, specifically including: Identify the service instances that communicate with the device, and the nodes on which each service instance runs; Each service instance is marked on a specific node, thus restricting the service instance to run on a designated node. The step of obtaining the floating IP address and configuring the floating IP address to the specified node where the service instance is deployed specifically includes: Check if any instances of the specified service have been deployed successfully. When it is detected that a service instance has been deployed, a available floating IP address is obtained from the available address pool; Configure the obtained available floating IP address to the instance container running node; After configuration, mark the floating IP address configured on the instance container running node as used.

2. The service migration and disaster recovery processing method according to claim 1, characterized in that, When the status of the service instance changes, the floating IP address is reconfigured to the node where the service instance is running normally or to the new node after migration. This specifically includes: When a service instance is detected to have migrated, a floating IP deletion command is issued to the node where the service instance was located before the migration. According to the floating IP deletion command, delete the floating IP of the node where the service instance was located before the migration; After deletion, a floating IP configuration command is issued to the node where the migrated service instance is located; Configure a floating IP in the node where the service instance is located after migration, according to the floating IP configuration instructions.

3. The service migration and disaster recovery processing method according to claim 1, characterized in that, When the status of the service instance changes, the floating IP address is reconfigured to the node where the service instance is running normally or to the new node after migration. This specifically includes: When a service instance is found to be unhealthy, a floating IP deletion command is issued to the node where the service instance is currently located. Delete the floating IP of the node where the service instance is currently located according to the floating IP deletion command; After deletion, issue a floating IP configuration command to the node where the service is normal. Configure a floating IP in the node where the instance is running normally, according to the floating IP configuration instructions.

4. A service migration and disaster recovery system, characterized in that, include: A limiting unit is used to restrict the deployment of service instances that communicate with the device to a specified node; The deployment unit is used to obtain a floating IP address and configure the floating IP address to the specified node where the service instance is deployed; The inspection unit is used to check whether the status of the service instance has changed. The configuration unit is used to reconfigure the floating IP address to the node where the service instance is running normally or to the new node after migration when the status of the service instance changes. The limiting unit includes: The determination module is used to determine the service instance that communicates with the device, and the node on which each service instance runs; The tagging module is used to tag the node on which each service instance runs, thereby restricting the service instance to run on the specified node; The configuration unit includes: The detection module is used to detect whether a specified service instance has been deployed. The acquisition module is used to obtain available floating IP addresses from the available address pool when it is detected that a service instance has been deployed. The configuration module is used to configure the obtained available floating IP addresses onto the instance container runtime node; The labeling module is used to mark the floating IP addresses that have been configured on the instance container's running node as used after configuration is complete.

5. A device, characterized in that, include: Processor and memory; The memory is used to store computer programs, and the processor calls the computer programs stored in the memory to execute the service migration and disaster recovery processing method according to any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, enables the processor to perform the service migration and disaster recovery processing method according to any one of claims 1 to 3.

Images