Disaster recovery switching method and device, computer device and computer readable storage medium

Abstract

The application relates to a disaster recovery switching method and device, computer equipment and a computer readable storage medium. The method comprises the following steps: synchronizing data with a first platform; the first platform interacts with a front-end device through binding a virtual network address; if it is detected that the running state of the first platform is abnormal, the virtual network address is re-bound to a second platform, and a communication connection is established with the front-end device in response to a re-registration request sent by the front-end device to the virtual network address, and the communication connection is used for realizing the service interaction between the second platform and the front-end device. In this way, through the data synchronization and state detection mechanism between the second platform and the first platform, the front-end device can directly initiate re-registration to the virtual network address, manual modification of configuration information of each front-end device is not needed, the service interruption time is effectively shortened, the efficiency of disaster recovery switching is improved, and the continuous and stable operation of related services is ensured.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a disaster recovery switching method, apparatus, computer equipment, and computer-readable storage medium. Background Technology

[0002] In video surveillance and other business systems, a backup server can be configured to back up and synchronize data from the primary server. When the primary server fails, the backup server will switch to provide services to the front-end devices, thus ensuring the stability and continuity of the business.

[0003] However, this traditional disaster recovery switching method relies on manual modification of the configuration information of the front-end devices to switch the business from the primary server to the backup server, which can easily lead to a long business interruption time. Summary of the Invention

[0004] Therefore, it is necessary to provide a disaster recovery switching method, apparatus, computer equipment, and computer-readable storage medium to address the aforementioned technical problems, so as to avoid relying on manual modification of configuration information and shorten business interruption time.

[0005] Firstly, this application provides a disaster recovery switching method applied to a second platform, wherein:

[0006] Data is synchronized with the first platform via a dedicated network line; the first platform interacts with the front-end device by binding a virtual network address, and the first platform and the second platform are deployed in different locations.

[0007] If the operating status of the first platform is detected to be abnormal, the virtual network address is re-bound to the second platform, and in response to the re-registration request sent by the front-end device to the virtual network address, a communication connection is established with the front-end device. The communication connection is used to realize business interaction between the second platform and the front-end device.

[0008] In one embodiment, the step of rebinding the virtual network address to the second platform includes:

[0009] The virtual network address is added to the network card of the second platform, and an Address Resolution Protocol (ARP) message is broadcast. The ARP message is used to instruct the virtual network address to establish a mapping relationship with the network address of the second platform.

[0010] In one embodiment, the step of establishing a communication connection with the front-end device in response to a re-registration request sent by the front-end device to the virtual network address includes:

[0011] In response to the re-registration request sent by the front-end device to the virtual network address, a verification message is sent to the front-end device;

[0012] The system receives signature information returned by the front-end device, which is generated by signing the verification message using the private key of the front-end device.

[0013] The signature information is authenticated using the pre-stored public key of the front-end device. If the authentication is successful, a registration success message is sent to the front-end device, which indicates that a communication connection has been successfully established with the front-end device.

[0014] In one embodiment, the method further includes:

[0015] When the first platform is detected to meet the preset backhaul conditions, the virtual network address is unbound and a redirection instruction is sent to the front-end device. The redirection instruction is used to instruct the front-end device to send a re-registration request to the virtual network address.

[0016] Secondly, this application provides a disaster recovery switching method applied to front-end devices, including:

[0017] Interact with a first platform that has a pre-bound virtual network address;

[0018] If the operating status of the first platform is detected to be abnormal, a re-registration request is sent to the virtual network address. The re-registration request is used to request the second platform to establish a communication connection with the front-end device. When the operating status of the first platform is abnormal, the virtual network address is re-bound from the first platform to the second platform. The first platform and the second platform are deployed in different locations, and the second platform synchronizes data with the first platform through a dedicated network line.

[0019] In one embodiment, the method further includes:

[0020] Receive the verification message sent by the second platform;

[0021] Based on the private key of the front-end device, the verification message is signed to generate signature information;

[0022] The signature information is sent to the second platform, and a registration success message is received from the second platform.

[0023] The registration success message is verified based on the pre-stored public key of the second platform. If the verification is successful, business interaction is initiated with the second platform.

[0024] Thirdly, this application also provides a disaster recovery switching device for use on a second platform, the device comprising:

[0025] The data synchronization module is used to synchronize data with the first platform; the first platform interacts with the front-end device by binding a virtual network address.

[0026] The disaster recovery switching module is used to rebind the virtual network address to the second platform if the operating status of the first platform is detected to be abnormal, and to establish a communication connection with the front-end device in response to the re-registration request sent by the front-end device to the virtual network address. The communication connection is used to realize business interaction between the second platform and the front-end device.

[0027] Fourthly, this application also provides a disaster recovery switching device applied to front-end equipment, the device comprising:

[0028] The business interaction module is used to interact with the first platform that has been pre-bound to a virtual network address.

[0029] The re-registration module is used to send a re-registration request to the virtual network address if the operating status of the first platform is detected to be abnormal. The re-registration request is used to request the second platform to establish a communication connection with the front-end device. When the operating status of the first platform is abnormal, the virtual network address is re-bound from the first platform to the second platform.

[0030] Fifthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in any of the above method embodiments.

[0031] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps described in any of the above method embodiments.

[0032] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps described in any of the above method embodiments.

[0033] The aforementioned disaster recovery switching method, apparatus, computer equipment, and computer-readable storage medium achieve data synchronization and status detection mechanisms through a dedicated network line between the second and first platforms. The second platform can maintain data synchronization with the geographically deployed first platform, and when an anomaly is detected in the first platform, it automatically establishes a communication connection with the second platform by rebinding the virtual network address to the second platform. Front-end devices can then directly initiate re-registration to this virtual network address. Therefore, the front-end devices are unaware of the switch between the second and first platforms, and there is no need for manual modification of the configuration information of each front-end device, effectively shortening service interruption time, improving disaster recovery switching efficiency, and ensuring the continuous and stable operation of related services. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a flowchart of a disaster recovery switching method applied to a second platform in one embodiment;

[0036] Figure 2 This is a flowchart of a disaster recovery switching method applied to a front-end device in one embodiment;

[0037] Figure 3 This is a timing interaction diagram of a disaster recovery switching method in one embodiment;

[0038] Figure 4 This is a structural block diagram of a disaster recovery switching device applied to a second platform in one embodiment;

[0039] Figure 5 This is a structural block diagram of a disaster recovery switching device applied to a front-end device in one embodiment;

[0040] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0042] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0043] The disaster recovery switching method provided in this application can be applied to a second platform, which can be a server with data computing and processing capabilities. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud servers, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The server can be a backend server for the aforementioned target application, used to provide backend services to the client of the target application.

[0044] Specifically, such as Figure 1 As shown, this disaster recovery switching method can achieve the following process:

[0045] Step 101: Data synchronization with the first platform is performed via a dedicated network line; the first platform interacts with the front-end device by binding a virtual network address, and the first platform and the second platform are deployed in different locations.

[0046] In this embodiment, both the second platform and the first platform can provide target business services to the business system, while the front-end device is a terminal device that communicates with the second platform and the first platform to implement the target business. For example, if the target business is a video surveillance business, then the second platform and the first platform can be video surveillance platform servers, and the front-end device can be an IPC (Internet Protocol Camera).

[0047] In the initial state, both the second platform and the first platform are running normally. The first platform interacts with the front-end devices by binding to a virtual network address. This means that each front-end device sends a service request to the virtual network address, and the first platform can obtain these service requests sent to the virtual network address and respond to and process them.

[0048] At this point, the first platform serves as the primary platform for the business system, while the second platform acts as the backup platform. Through the data synchronization mechanism between the second and first platforms, the second platform can synchronize data with the first platform, acquire business data from the first platform, and prepare for possible disaster recovery switching in the future. This avoids problems such as business anomalies and data loss after disaster recovery switching due to data differences.

[0049] It should be noted that the second platform and the first platform in this application embodiment can be deployed in different locations, in different data centers. In this way, even if the data center where the first platform is located encounters a catastrophic event such as a power outage, network outage or natural disaster, the second platform can still achieve disaster recovery switching and avoid long-term interruption of business systems.

[0050] In one implementation, the second platform and the first platform can synchronize data via a dedicated network line. This dedicated network line is a private network connection service used to establish a high-speed, stable, and secure network channel between the geographically deployed second and first platforms. Therefore, data synchronization between the second and first platforms can be completed in a very short time, ensuring minimal data discrepancies between the primary and backup platforms. This allows the second platform to take over operations in the shortest possible time in the event of a failure.

[0051] Step 102: If the operating status of the first platform is detected to be abnormal, the virtual network address is re-bound to the second platform, and a communication connection is established with the front-end device in response to the re-registration request sent to the virtual network address by the front-end device. The communication connection is used to realize business interaction between the second platform and the front-end device.

[0052] The second platform can continuously monitor the operational status of the first platform. When it detects and determines that the first platform's operational status is abnormal and it cannot provide normal business services, it triggers a disaster recovery switchover mechanism, unbinding the virtual network address from the first platform and rebinding the virtual network address to the second platform. A heartbeat detection mechanism can be used between the second and first platforms. Specifically, the second platform actively sends heartbeat probe messages to the first platform at preset time intervals. Upon receiving the heartbeat probe message during normal operation, the first platform can return a response message to the second platform. If the second platform does not receive a response message from the first platform within a preset timeout period, it determines that the first platform's operational status is abnormal.

[0053] At this time, the front-end device will also detect and determine that the first platform is in an abnormal operating state and cannot provide business services normally. Then, without manual triggering, it will automatically trigger the re-registration mechanism and send a re-registration request to the virtual network address.

[0054] After the virtual network address is re-bound, the second platform can listen for and respond to the re-registration requests from the front-end devices, and complete the registration and authentication with each front-end device according to the preset authentication process, thereby establishing a communication connection. This communication connection is used to realize business interaction between the second platform and the front-end devices. That is, the second platform can take over from the first platform and provide target business services to the front-end devices, thereby realizing automated disaster recovery switching after the failure of the first platform.

[0055] As can be seen from the above, the solution provided in this application, through the data synchronization and status detection mechanism between the second platform and the first platform, allows the second platform to maintain data synchronization with the first platform. When an anomaly is detected in the first platform, the virtual network address is re-bound to the second platform, and the front-end device can directly initiate re-registration to that virtual network address, automatically establishing a communication connection with the second platform. Therefore, the front-end device is unaware of the switch between the second and first platforms, and there is no need for manual modification of the configuration information of each front-end device, effectively shortening the service interruption time, improving the efficiency of disaster recovery switching, and ensuring the continuous and stable operation of related services.

[0056] In an exemplary embodiment, step 102, which involves transferring the virtual network address to the second platform, includes:

[0057] The virtual network address is added to the network card of the second platform, and an Address Resolution Protocol (ARP) message is broadcast. The ARP message is used to instruct the virtual network address to establish a mapping relationship with the network address of the second platform.

[0058] Specifically, when the second platform performs the virtual network address rebinding operation, it first calls the network interface card (NIC) configuration interface of the high-availability cluster software to add the virtual network address to its own NIC, enabling the second platform's NIC to recognize and receive data sent to that virtual network address. The high-availability cluster software is a management program specifically designed to ensure uninterrupted business operations.

[0059] Then, the second platform can broadcast Address Resolution Protocol (ARP) messages to network devices within the same broadcast domain. These ARP messages instruct the virtual network address to establish a mapping relationship with the network address of the second platform. Upon receiving the ARP message, these network devices can update the physical address corresponding to the virtual network address to the network address of the second platform. In this way, subsequent requests, data, and messages sent to the virtual network address will be forwarded to the second platform instead of the first platform, thus achieving the rebinding of the virtual network address from the first platform to the second platform.

[0060] By directly adding the virtual network address to the network card of the second platform and broadcasting the address resolution protocol message, the virtual network address can be automatically and quickly re-bound. During the re-bound process, the front-end device does not need any configuration changes, and its service requests sent to the same virtual network address can be automatically routed to the second platform, thereby significantly reducing service interruption time during device failure switching.

[0061] In an exemplary embodiment, step 102, in response to a re-registration request sent by the front-end device to the virtual network address, establishes a communication connection with the front-end device, including:

[0062] In response to the re-registration request sent by the front-end device to the virtual network address, a verification message is sent to the front-end device;

[0063] Receive the signature information returned by the front-end device. The signature information is generated by signing the verification message with the private key of the front-end device.

[0064] The signature information is authenticated using the pre-stored public key of the front-end device. If the authentication is successful, a registration success message is sent to the front-end device, indicating that a communication connection has been successfully established with the front-end device.

[0065] Specifically, after the second platform completes the virtual network address rebinding operation, it can use the SIP (Session Initiation Protocol) signaling interaction mechanism specified in GB35114 "Technical Requirements for Information Security of Public Security Video Surveillance Network" to re-register the front-end device and establish a communication connection with the front-end device.

[0066] First, after receiving a re-registration request from the front-end device sent to the virtual network address, the second platform can proactively send a verification message to the front-end device. This verification message can be a random number. Upon receiving the verification message from the second platform, the front-end device will use its pre-stored private key to sign the message, generating a unique signature, and then send this signature back to the second platform. Since the front-end device's private key is held exclusively by the front-end device itself, this signature uniquely proves the front-end device's legitimate identity.

[0067] Then, after the second platform obtains the signature information returned by the front-end device, it can retrieve the public key of the front-end device that is stored locally in advance to authenticate the signature information. The authentication process can use an asymmetric encryption authentication mechanism. First, the public key of the front-end device is used to perform a signature verification operation on the signature information, and then the signature verification operation result is verified to see if it matches the verification message.

[0068] If the signature verification result matches the verification message, it indicates that the front-end device does indeed possess the private key paired with the public key, meaning the signature information authentication is successful, and the front-end device's identity is authentic and valid. Subsequently, the second platform can push a registration success message to the front-end device. This message indicates that the second platform and the front-end device have successfully established a communication connection, after which both parties can conduct business interactions based on this connection.

[0069] If the signature verification result does not match the verification message, the signature authentication fails, indicating that the front-end device may not be the legitimate device it claims to be, or that the signature information has been tampered with during transmission. In this case, the second platform can reject the re-registration request and may choose to return a registration rejection message to the front-end device to notify it of the authentication failure. After receiving the rejection message, the front-end device can decide whether to re-initiate the registration request according to the preset retry policy. If authentication fails multiple times consecutively, the second platform can also record anomaly event logs for maintenance personnel to investigate potential security threats or device configuration errors.

[0070] By introducing a public-private key-based signature authentication mechanism during the re-registration process, the second platform can reliably verify the legitimate identity of front-end devices, preventing unauthorized devices from accessing the system. Furthermore, identity authentication requires no manual review or configuration, ensuring system access security while maintaining the automated disaster recovery switching process. This enables rapid and automatic connection establishment between the front-end devices and the second platform after a failover, further shortening business recovery time.

[0071] In one exemplary embodiment, the method further includes:

[0072] When the first platform is detected to meet the preset return conditions, the virtual network address is unbound and a redirection instruction is sent to the front-end device. The redirection instruction is used to instruct the front-end device to send a re-registration request to the virtual network address.

[0073] Specifically, the second platform can continuously monitor the operational status of the first platform to determine whether the first platform has met preset return flow conditions. These preset return flow conditions may include, but are not limited to, the time it takes for the first platform to resume normal operation reaching a preset threshold, receiving a primary / backup switchover command, and the link quality of the first platform meeting preset standards. For example, the second platform can proactively send heartbeat probe messages to the first platform at preset time intervals. After receiving the heartbeat probe message during normal operation, the first platform can return a response message to the second platform. If the second platform receives three consecutive response messages from the first platform within a preset timeout period, it is determined that the first platform's operational status has returned to normal, and at this point, it can be determined whether the first platform has met the preset return flow conditions.

[0074] When the second platform detects that the first platform meets the preset backhaul conditions, it can proactively perform a virtual network address unbinding operation. This involves using the high-availability cluster software to release the binding between its own network interface card (NIC) and the virtual network address, ceasing to respond to data, requests, and messages sent to that virtual network address. Simultaneously, the first platform can also add the virtual network address to its own NIC and broadcast the corresponding address resolution protocol message when it determines that it meets the preset backhaul conditions.

[0075] After unbinding the virtual network address, the second platform can proactively send a redirection command to the connected front-end device. This redirection command carries the virtual network address. Upon receiving the redirection command, the front-end device can re-initiate a re-registration request to the virtual network address according to the instructions. At this point, since the virtual network address has been rebound back to the first platform, the re-registration request will be routed to the first platform, which will then complete the re-registration process with the front-end device and re-establish a communication connection.

[0076] By sending a redirection command to the front-end device while unbinding the virtual network address on the second platform, the system can avoid prolonged service interruption caused by the front-end device passively waiting for connection timeout after the first platform returns to normal. This makes the service switchback process faster and more controllable, and also achieves the effect of gradually switching new services back to the main platform, ensuring the stability and continuity of the system during the fault recovery process.

[0077] In another exemplary embodiment, when the first platform recovers from a failure and goes back online, the backhaul mechanism is not triggered. At this time, the first platform detects that the virtual network address is currently bound to the second platform, and no longer attempts to preempt the virtual network address. Instead, it maintains data synchronization and heartbeat monitoring with the second platform, waiting to take over the service when the second platform fails. In other words, the primary and backup roles of the second and first platforms have been swapped.

[0078] This avoids the jitter and brief interruptions that may be caused by frequent switching between the second and first platforms, reduces operational complexity and failure risk, and the recovered first platform serves as a new backup node to synchronize data in real time, which also provides a guarantee for subsequent disaster recovery and maintains the high availability of the business system.

[0079] like Figure 2 As shown, the disaster recovery switching method provided in this application embodiment can also be applied to front-end devices, and the disaster recovery switching method can implement the following process:

[0080] Step 201: Conduct business interactions with the first platform that has a pre-bound virtual network address.

[0081] Front-end devices implement target services based on virtual network addresses. In the initial state, the first platform binds to the virtual network address. This means that each front-end device sends service requests to the virtual network address, and the first platform can obtain these service requests sent to the virtual network address and respond to and process them. Therefore, the front-end devices conduct service interactions with the first platform through the virtual network address.

[0082] Step 202: If the operating status of the first platform is detected to be abnormal, a re-registration request is sent to the virtual network address. The re-registration request is used to request the second platform to establish a communication connection with the front-end device. When the operating status of the first platform is abnormal, the virtual network address is re-bound from the first platform to the second platform. The first platform and the second platform are deployed in different locations, and the second platform synchronizes data with the first platform through a dedicated network line.

[0083] The front-end device can continuously monitor the operational status of the first platform. When it detects and determines that the first platform's operational status is abnormal and it cannot provide normal business services, it automatically triggers a re-registration mechanism, sending a re-registration request to the virtual network address. Specifically, a heartbeat detection mechanism can be used between the front-end device and the first platform. The front-end device actively sends heartbeat probe messages to the virtual network address at preset time intervals. Upon receiving the heartbeat probe message during normal operation, the first platform can return a response message to the second platform. If the front-end device does not receive a response message from the first platform within a preset timeout period, it determines that the first platform's operational status is abnormal.

[0084] At this time, the second platform will also detect and determine that the first platform is in an abnormal operating state and cannot provide normal business services, thereby triggering the disaster recovery switching mechanism, removing the binding relationship between the virtual network address and the first platform, and rebinding the virtual network address to the second platform.

[0085] After the virtual network address is re-bound, the second platform can listen for and respond to the re-registration requests from the front-end devices, and complete the registration and authentication with each front-end device according to the preset authentication process, thereby establishing a communication connection. This communication connection is used to realize business interaction between the second platform and the front-end devices. That is, the second platform can take over from the first platform and provide target business services to the front-end devices, thereby realizing automated disaster recovery switching after the failure of the first platform.

[0086] It should be noted that the second platform and the first platform in this application embodiment can be deployed in different locations, in different data centers, and synchronize data through a dedicated network line. In this way, even if the data center where the first platform is located encounters a catastrophic event such as a power outage, network outage, or natural disaster, the second platform can still achieve disaster recovery switching and avoid long-term interruption of business systems.

[0087] As can be seen from the above, the solution provided in this application, through the data synchronization and status detection mechanism between the second platform and the first platform, allows the second platform to maintain data synchronization with the first platform. When an anomaly is detected in the first platform, the virtual network address is re-bound to the second platform, and the front-end device can directly initiate re-registration to that virtual network address, automatically establishing a communication connection with the second platform. Therefore, the front-end device is unaware of the switch between the second and first platforms, and there is no need for manual modification of the configuration information of each front-end device, effectively shortening the service interruption time, improving the efficiency of disaster recovery switching, and ensuring the continuous and stable operation of related services.

[0088] In one exemplary embodiment, the method further includes:

[0089] Receive verification messages sent by the second platform;

[0090] Based on the private key of the front-end device, the verification message is signed to generate signature information;

[0091] Send the signature information to the second platform and receive a registration success message from the second platform;

[0092] The system verifies the registration success message based on the pre-stored public key of the second platform. If the verification is successful, it then engages in business interactions with the second platform.

[0093] Specifically, firstly, after receiving a re-registration request from the front-end device sent to the virtual network address, the second platform can proactively send a verification message to the front-end device. This verification message can be a random number. Upon receiving the verification message from the second platform, the front-end device will use its pre-stored private key to sign the message, generating a unique signature, and then send this signature back to the second platform. Since the front-end device's private key is held solely by the front-end device, this signature uniquely proves the front-end device's legitimate identity.

[0094] Then, after the second platform obtains the signature information returned by the front-end device, it can retrieve the public key of the front-end device that is stored locally in advance to authenticate the signature information. The authentication process can use an asymmetric encryption authentication mechanism. First, the public key of the front-end device is used to perform a signature verification operation on the signature information, and then the signature verification operation result is verified to see if it matches the verification message.

[0095] If the signature verification result matches the verification message, it indicates that the front-end device does indeed possess the private key paired with the public key, meaning the signature information authentication is successful, and the front-end device's identity is authentic and valid. Subsequently, the second platform can push a registration success message to the front-end device. This message indicates that the second platform and the front-end device have successfully established a communication connection, after which both parties can conduct business interactions based on this connection.

[0096] If the signature verification result does not match the verification message, the signature authentication fails, indicating that the front-end device may not be the legitimate device it claims to be, or that the signature information has been tampered with during transmission. In this case, the second platform can reject the re-registration request and may choose to return a registration rejection message to the front-end device to notify it of the authentication failure. After receiving the rejection message, the front-end device can decide whether to re-initiate the registration request according to the preset retry policy. If authentication fails multiple times consecutively, the second platform can also record anomaly event logs for maintenance personnel to investigate potential security threats or device configuration errors.

[0097] By introducing a public-private key-based signature authentication mechanism during the re-registration process, the second platform can reliably verify the legitimate identity of front-end devices, preventing unauthorized devices from accessing the system. Furthermore, identity authentication requires no manual review or configuration, ensuring system access security while maintaining the automated disaster recovery switching process. This enables rapid and automatic connection establishment between the front-end devices and the second platform after a failover, further shortening business recovery time.

[0098] like Figure 3 The diagram shown is a timing interaction diagram of the disaster recovery switching method provided in this application embodiment. The first platform and the second platform are deployed in different locations. In the initial state, the first platform is bound to a virtual network address, and the front-end devices continuously interact with the first platform based on this virtual network address. Simultaneously, the second platform synchronizes data with the first platform via a dedicated network line to prepare data reserves for possible disaster recovery switching.

[0099] The second platform monitors the operational status of the first platform. If it detects an anomaly in the first platform, it performs a virtual network address rebinding operation, migrating the virtual network address to its own network interface card (NIC). When a front-end device detects a link interruption or service anomaly with the first platform, it automatically initiates a re-registration request to the virtual network address. Upon receiving the re-registration request from the front-end device, the second platform processes and responds to the request, re-establishing a communication connection with the front-end device. Subsequently, the second platform takes over the business interactions of the front-end device, automatically completing the primary / backup node disaster recovery switchover. The entire process requires no manual modification of the front-end device's access configuration, ensuring uninterrupted business operation.

[0100] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0101] Based on the same inventive concept, this application also provides a disaster recovery switching device for implementing the disaster recovery switching method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more disaster recovery switching device embodiments provided below can be found in the limitations of the disaster recovery switching method described above, and will not be repeated here.

[0102] In one exemplary embodiment, such as Figure 4 As shown, a disaster recovery switching device is provided for use on a second platform, comprising:

[0103] The data synchronization module 401 is used to synchronize data with the first platform via a dedicated network line; the first platform interacts with the front-end device by binding a virtual network address, and the first platform and the second platform are deployed in different locations.

[0104] The disaster recovery switching module 402 is used to rebind the virtual network address to the second platform if the operating status of the first platform is detected to be abnormal, and to establish a communication connection with the front-end device in response to the re-registration request sent by the front-end device to the virtual network address. The communication connection is used to realize business interaction between the second platform and the front-end device.

[0105] In another exemplary embodiment, such as Figure 5 As shown, another disaster recovery switching device is provided, applied to front-end equipment, including:

[0106] The business interaction module 501 is used to interact with the first platform that has been pre-bound to a virtual network address.

[0107] The re-registration module 502 is used to send a re-registration request to the virtual network address if the operating status of the first platform is detected to be abnormal. The re-registration request is used to request the second platform to establish a communication connection with the front-end device. When the operating status of the first platform is abnormal, the virtual network address is changed from the first platform to the second platform. The first platform and the second platform are deployed in different locations, and the second platform synchronizes data with the first platform through a dedicated network line.

[0108] Each module in the aforementioned disaster recovery switching device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0109] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores operating computer programs and a database. The internal memory provides an environment for the operating system and computer programs stored in the non-volatile storage media. The database stores measurement data and / or positioning information. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a disaster recovery switching method.

[0110] Those skilled in the art can understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0111] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in any of the above method embodiments.

[0112] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps described in any of the above method embodiments.

[0113] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps described in any of the above method embodiments.

[0114] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0115] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0116] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0117] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A disaster recovery switching method, characterized in that, Applied to a second platform, the method includes: Data is synchronized with the first platform via a dedicated network line; the first platform interacts with the front-end device by binding a virtual network address, and the first platform and the second platform are deployed in different locations. If the operating status of the first platform is detected to be abnormal, the virtual network address is re-bound to the second platform, and in response to the re-registration request sent by the front-end device to the virtual network address, a communication connection is established with the front-end device. The communication connection is used to realize business interaction between the second platform and the front-end device.

2. The method according to claim 1, characterized in that, The step of changing the binding of the virtual network address to the second platform includes: The virtual network address is added to the network card of the second platform, and an Address Resolution Protocol (ARP) message is broadcast. The ARP message is used to instruct the virtual network address to establish a mapping relationship with the network address of the second platform.

3. The method according to claim 1, characterized in that, The step of responding to the re-registration request sent by the front-end device to the virtual network address and establishing a communication connection with the front-end device includes: In response to the re-registration request sent by the front-end device to the virtual network address, a verification message is sent to the front-end device; The system receives signature information returned by the front-end device, which is generated by signing the verification message using the private key of the front-end device. The signature information is authenticated using the pre-stored public key of the front-end device. If the authentication is successful, a registration success message is sent to the front-end device, which indicates that a communication connection has been successfully established with the front-end device.

4. The method according to claim 1, characterized in that, The method further includes: When the first platform is detected to meet the preset backhaul conditions, the virtual network address is unbound and a redirection instruction is sent to the front-end device. The redirection instruction is used to instruct the front-end device to send a re-registration request to the virtual network address.

5. A disaster recovery switching method, characterized in that, Applied to front-end devices, including: Interact with a first platform that has a pre-bound virtual network address; If the operating status of the first platform is detected to be abnormal, a re-registration request is sent to the virtual network address. The re-registration request is used to request the second platform to establish a communication connection with the front-end device. When the operating status of the first platform is abnormal, the virtual network address is re-bound from the first platform to the second platform. The first platform and the second platform are deployed in different locations, and the second platform synchronizes data with the first platform through a dedicated network line.

6. The method according to claim 5, characterized in that, The method further includes: Receive the verification message sent by the second platform; Based on the private key of the front-end device, the verification message is signed to generate signature information; The signature information is sent to the second platform, and a registration success message is received from the second platform. The registration success message is verified based on the pre-stored public key of the second platform. If the verification is successful, business interaction is initiated with the second platform.

7. A disaster recovery switching device, characterized in that, Applied to a second platform, the device includes: The data synchronization module is used to synchronize data with the first platform via a dedicated network line; the first platform interacts with the front-end device by binding a virtual network address, and the first platform and the second platform are deployed in different locations. The disaster recovery switching module is used to rebind the virtual network address to the second platform if the operating status of the first platform is detected to be abnormal, and to establish a communication connection with the front-end device in response to the re-registration request sent by the front-end device to the virtual network address. The communication connection is used to realize business interaction between the second platform and the front-end device.

8. A disaster recovery switching device, characterized in that, Applied to a front-end device, the device includes: The business interaction module is used to interact with the first platform that has been pre-bound to a virtual network address. The re-registration module is used to send a re-registration request to the virtual network address if the operating status of the first platform is detected to be abnormal. The re-registration request is used to request the second platform to establish a communication connection with the front-end device. When the operating status of the first platform is abnormal, the virtual network address is re-bound from the first platform to the second platform. The first platform and the second platform are deployed in different locations, and the second platform synchronizes data with the first platform through a dedicated network line.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4, or the steps of the method according to any one of claims 5 to 6.

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 steps of the method according to any one of claims 1 to 4, or the steps of the method according to any one of claims 5 to 6.

Images