Disaster recovery methods, devices, software products, and media based on digital twin simulation

Abstract

This invention discloses a disaster recovery method, apparatus, program product, and medium based on digital twin simulation, relating to the field of disaster recovery technology. Addressing the issue that current disaster recovery solutions need further improvement in their ability to ensure business continuity, this invention provides a disaster recovery method based on digital twin simulation. By simulating the execution process of a recovery plan on the target component using a digital twin sandbox, it avoids the serious consequences of executing outdated or unsuitable recovery plans for the current scenario. Furthermore, this method sets up multiple recovery plans to adapt to the disaster recovery switching needs of different scenarios. Before performing a disaster recovery switch, the execution results of different recovery plans are simulated and simulated using a digital twin sandbox. The simulation results are quantified, and the recovery plan with the best execution result is selected as the optimal recovery plan for the disaster recovery switch of the target component, achieving the best recovery effect.

Description

Technical Field

[0001] This invention relates to the field of disaster recovery technology, and in particular to a disaster recovery method, apparatus, program product and medium based on digital twin simulation. Background Technology

[0002] As a core platform hosting mission-critical businesses, the continuity of private clouds, especially their disaster recovery capabilities, has become a key indicator of an enterprise's technological maturity and business resilience. Service outages can not only cause direct economic losses but also damage brand reputation and customer trust. Therefore, building an efficient and reliable disaster recovery system is crucial.

[0003] Current mainstream disaster recovery solutions typically revolve around three core components: data replication, health checks, and contingency plan execution. For data replication, synchronous or asynchronous replication technologies at the storage layer are used to transfer data copies to the disaster recovery site, enabling recovery from the copy should the primary site fail. For health checks, the health status of system components is monitored using methods such as heartbeat detection, application probes, or threshold alarms to determine if a failure has occurred. The contingency plan execution component triggers the execution of a pre-written recovery plan (Runbook) upon detecting a clear fault signal (such as server crash or network interruption). This plan is usually a series of fixed scripts or manual operation procedures designed to switch business operations to backup resources or the disaster recovery site.

[0004] Regardless of the form of the three steps mentioned above, they all involve executing a pre-written recovery plan after a fault has been diagnosed. These recovery plans are typically static scripts designed based on historical experience and idealized scenarios. They cannot be dynamically adjusted according to the actual system state at the time of the disaster (such as the resource load of backup sites, network bandwidth, and data consistency). Executing an outdated or unsuitable plan inherently carries significant risks, potentially leading to secondary disasters even more severe than the original fault.

[0005] Therefore, those skilled in the art urgently need a disaster recovery method based on digital twin simulation to address the issue that the current disaster recovery solutions need to further improve their ability to ensure business continuity. Summary of the Invention

[0006] The purpose of this invention is to provide a disaster recovery method, device, program product and medium based on digital twin simulation, so as to solve the problem that the current disaster recovery solution needs to further improve its ability to ensure business continuity.

[0007] To address the aforementioned technical problems, this invention provides a disaster recovery method based on digital twin simulation, comprising: simulating the execution process of multiple recovery plans using a digital twin sandbox; wherein the digital twin sandbox stores a digital twin model corresponding to the complete information technology environment of a target component; the target component is the component in the cloud platform targeted for disaster recovery protection; acquiring key parameters of each recovery plan during the simulation process; wherein the key parameters include: a recovery time target and a recovery point target; selecting the optimal recovery plan from among the recovery plans based on the key parameters, and achieving disaster recovery switching of the target component through the optimal recovery plan.

[0008] In an optional embodiment, before the execution process of multiple recovery plans is simulated through a digital twin sandbox, the method further includes: generating multiple different recovery plans based on the risk type of the target component using policy generation rules defined in a preset policy library and stored policy options.

[0009] In one optional embodiment, the strategy options include multiple strategy types: resource optimization, service degradation, site switching, and network isolation. The resource optimization strategy options include: hot-migrating virtual machines to a high-resource standby host and cold-migrating virtual machines to a low-cost standby host. The service degradation strategy options include: switching the application mode of the target component to read-only mode. The site switching strategy options include: switching the application service of the target component to a remote disaster recovery site. The network isolation strategy options include: prohibiting data migration of the target component and isolating the target component from the network. The generated recovery plan includes the strategy options of multiple different strategy types.

[0010] In an optional embodiment, after selecting the optimal recovery plan from the recovery plans based on the key parameters, the method further includes: determining the predicted benefit score of the optimal recovery plan based on the key parameters; determining the basic score of the optimal recovery plan based on preset expert rules; weighting the predicted benefit score and the basic score to obtain a comprehensive confidence level; and determining whether to perform disaster recovery switching of the target component using the optimal recovery plan based on the comprehensive confidence level.

[0011] In an optional embodiment, after the disaster recovery switch of the target component is achieved through the optimal recovery plan, the method further includes: obtaining the key parameters after the disaster recovery switch of the target component is achieved according to the optimal recovery plan, and comparing them with the key parameters obtained during the simulation of the optimal recovery plan to obtain the prediction error corresponding to each key parameter; if the prediction error meets the drift condition, then adjusting the parameters of the simulation prediction formula corresponding to the key parameter; wherein, the drift condition is: the prediction error corresponding to the key parameter above a preset proportion exceeds the tolerance threshold; the simulation prediction formula is used to predict the key parameter by using other data associated with the corresponding key parameter for some key parameters that cannot be directly obtained or statistically analyzed; if the prediction error still meets the drift condition, then lowering the weight coefficient of the prediction benefit score; if the prediction error still meets the drift condition, then recalibrating the digital twin sandbox.

[0012] In an optional embodiment, after recalibrating the digital twin sandbox, the method further includes: if the prediction error still satisfies the drift condition after N consecutive occurrences, then the upper limit of the weight coefficient of the prediction revenue score is limited to a preset limit value, and the step of determining whether to perform disaster recovery switching of the target component according to the comprehensive confidence level is restricted; wherein, N is any positive integer greater than 1; the disaster recovery switching of the target component is allowed only after receiving a confirmation instruction issued by the manual confirmation channel.

[0013] In an optional embodiment, the recovery time target and the recovery point target are business impact indicators among the key parameters; the key parameters further include: performance impact indicators, resource impact indicators, and cost impact indicators; wherein, the performance impact indicators include: business interruption duration, packet loss rate during the switching process, and changes in application response latency; the resource impact indicators include: time required for resource reconstruction and the expected resource consumption of the target component; the cost impact indicators include: direct and indirect overhead required to execute the recovery plan.

[0014] In an optional embodiment, before the execution process of multiple recovery plans is simulated using a digital twin sandbox, the method further includes: performing a bidirectional traversal of the dependency graph, starting from the target component, both upwards and downwards, to determine the influence radius of the target component; wherein the dependency graph is a graph pre-established based on the dependency relationships between the components in the cloud platform; then the simulation of the execution process of multiple recovery plans using a digital twin sandbox includes: determining the minimum set of objects required for simulation based on the influence radius corresponding to the target component; and simulating the process of executing the recovery plan on the minimum set of objects using the digital twin sandbox.

[0015] In an optional embodiment, the dependency graph establishment process includes: determining the call relationships between microservices, application instances, and the external interfaces of the application instances using inter-service call chain data captured by application performance management probes and extended Berkeley package filters; determining the runtime relationships between the application instances and virtual machines, and between the virtual machines and physical hosts, using static configuration information in the configuration management database and factual scheduling results obtained from the application programming interface of the container platform; and obtaining the usage relationships between the virtual machines and storage volumes, and the connection relationships between the virtual machines and virtual networks, by polling the application programming interface of the virtualization management platform. The process involves: determining the physical connection relationships between the physical server, the network device, and the storage device by using the link layer discovery protocol information of the network device and the configuration information of the storage array; binding the database's data volume and log volume according to a predefined storage policy to establish a consistency relationship; wherein, the data volume and log volume that establish the consistency relationship are considered as an atomic unit; parsing firewall and security group rules to convert access control policies into allowed access edges in the dependency graph; and establishing the dependency graph based on the obtained dependencies; wherein, the dependencies include: call relationships, run-on relationships, use relationships, connect-to relationships, consistency relationships, and allowed access edges.

[0016] In an optional embodiment, the disaster recovery switch of the target component through the optimal recovery plan includes: determining the disaster recovery operation sequence of the target component according to the dependency graph; and implementing the disaster recovery switch of the target component according to the disaster recovery operation sequence. The disaster recovery operation sequence includes disaster recovery operations for the target component and for nodes in the dependency graph that have dependencies on the target component. The execution order of the disaster recovery operations is determined based on the dependencies in the dependency graph.

[0017] In an optional embodiment, before the execution process of multiple recovery plans is simulated using a digital twin sandbox, the method further includes: monitoring the status data of each component in the cloud platform; predicting the risk score of the component based on the status data according to a pre-established prediction model; and when the risk score of any component exceeds a trigger risk threshold, designating the component as the target component and triggering the step of simulating the execution process of multiple recovery plans using a digital twin sandbox.

[0018] In an optional embodiment, the prediction model includes: a hardware failure prediction model, a resource congestion prediction model, a recovery point target default prediction model, and an application degradation and anomaly synthesis detection model; wherein, the hardware failure prediction model is used to predict the probability of the component failing; the resource congestion prediction model is used to predict the probability of the component experiencing a resource bottleneck; the recovery point target default prediction model is used to predict the probability of the component exceeding the business point target threshold set by the business; and the application degradation and anomaly synthesis detection model is used to predict the probability of the component exhibiting behavioral pattern deviation; then, predicting the risk score of the component based on the state data according to the pre-established prediction model includes: weighting the probabilities output by the hardware failure prediction model, the resource congestion prediction model, the recovery point target default prediction model, and the application degradation and anomaly synthesis detection model to obtain the risk score.

[0019] In one optional embodiment, the risk score is obtained by weighting the probabilities output by the hardware failure prediction model, the resource congestion prediction model, the recovery point target default prediction model, and the application degradation and anomaly synthesis detection model. This includes weighting the probabilities output by the hardware failure prediction model, the resource congestion prediction model, the recovery point target default prediction model, and the application degradation and anomaly synthesis detection model with a key score. The key score is positively correlated with the number of key services in the dependency graph that depend on the component.

[0020] In an optional embodiment, the method further includes: capturing kernel-level data transmitted between the operating system and external systems by running an extended Berkeley packet filter in the operating system kernel; obtaining network traffic copies by configuring mirror ports on the switch and sending them to application performance management probes for analysis to obtain network data; and obtaining container data by collecting logs and metrics from accompanying containers deployed for each application container in a containerized environment.

[0021] In an optional embodiment, the method further includes: scoring the data acquired by each data source in each collection cycle based on the completeness, timeliness, and consistency of the data acquired from each data source; wherein the data source includes: an extended Berkeley packet filter, a mirror port, and an accompanying container; if the quality score of any of the data sources is lower than a preset quality threshold, then the weight coefficient corresponding to the prediction model that provides data input from that data source is reduced when determining the risk coefficient.

[0022] In an optional embodiment, when there are multiple tenants on the cloud platform, the method further includes: labeling the acquired data with a unique tenant tag.

[0023] To address the aforementioned technical problems, this invention also provides a disaster recovery device based on digital twin simulation, comprising: a simulation module for simulating the execution process of multiple recovery plans using a digital twin sandbox; wherein the digital twin sandbox stores a digital twin model corresponding to the complete information technology environment of a target component; the target component is the component in the cloud platform targeted for disaster recovery protection; a result quantification module for acquiring key parameters of each recovery plan during the simulation process; wherein the key parameters include: a recovery time target and a recovery point target; and a disaster recovery decision module for selecting the optimal recovery plan from the recovery plans based on the key parameters, and realizing the disaster recovery switchover of the target component through the optimal recovery plan.

[0024] To address the aforementioned technical problems, the present invention also provides a computer program product, comprising a computer program / instructions, wherein when the computer program / instructions are executed by a processor, they implement the steps of the disaster recovery method based on digital twin inference as described above.

[0025] To address the aforementioned technical problems, the present invention also provides a disaster recovery device based on digital twin simulation, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the disaster recovery method based on digital twin simulation as described above.

[0026] To address the aforementioned technical problems, the present invention also provides a non-volatile storage medium storing a computer program, which, when executed by a processor, implements the steps of the disaster recovery method based on digital twin simulation as described above.

[0027] This invention provides a disaster recovery method based on digital twin simulation. The digital twin sandbox stores a digital twin model consistent with the complete IT environment of the target component. Therefore, executing a recovery plan within the digital twin sandbox is equivalent to executing it on the target component. The digital twin sandbox allows for simulation of the recovery plan's execution process on the target component. Thus, this method can predict the execution results of recovery plans, avoiding the serious consequences of executing an outdated or unsuitable recovery plan. Furthermore, this method sets up multiple recovery plans. Before disaster recovery switching, the execution results of different recovery plans are simulated using the digital twin sandbox, and the simulation results are quantified using key parameters, including at least recovery time and recovery point targets. This quantitative indicator directly reflects the quality of the recovery plan's execution results. Based on this, this method can further select the recovery plan with the best execution result from multiple recovery plans using key parameters as the optimal recovery plan. Using the optimal recovery plan for disaster recovery switching of the target component yields the best execution effect. Therefore, this solution, based on the setting of multiple recovery plans, can adapt to the disaster recovery switching needs in different scenarios. In practical application scenarios, simulation and deduction based on digital twin sandbox are used to determine the most suitable recovery plan for the current scenario, and this plan is selected as the optimal recovery plan for the final disaster recovery switching, resulting in the best recovery effect.

[0028] The disaster recovery device based on digital twin simulation and the non-volatile storage medium provided by this invention correspond to the above-mentioned methods and have the same effect. Attached Figure Description

[0029] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A flowchart illustrating a disaster recovery method based on digital twin simulation provided in an embodiment of the present invention.

[0031] Figure 2 This is an architecture diagram of a disaster recovery method based on digital twin simulation provided in an embodiment of the present invention.

[0032] Figure 3 This is a structural diagram of a disaster recovery device based on digital twin simulation provided in an embodiment of the present invention.

[0033] Figure 4 A structural diagram of another disaster recovery device based on digital twin simulation provided in an embodiment of the present invention. Detailed Implementation

[0034] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts belong to the protection scope of the present invention.

[0035] The core of the present invention is to provide a disaster recovery method, device, program product and medium based on digital twin deduction.

[0036] In order to enable those skilled in the art to better understand the solutions of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0037] In the related art, the mainstream disaster recovery technical solutions are usually constructed around three core links: data replication, health check and pre-plan execution. And those skilled in the art also improve the above three links in order to obtain better disaster recovery effects. However, for the disaster recovery solutions focusing on the above three links, no matter what form is adopted, they all execute the pre-written recovery plan after diagnosing the failure. And such recovery plans are usually static scripts designed based on historical experience and idealized scenarios. It cannot be dynamically adjusted according to the real system state at the time of the disaster (such as the resource load of the standby site, network bandwidth, data consistency situation). And executing a plan that is outdated or not suitable for the current scenario itself contains huge risks and even brings more serious secondary disasters than the original failure.

[0038] To solve the above problems, the present invention provides a disaster recovery method based on digital twin deduction, as Figure 1 shown, including: S11: Deduce the execution process of multiple recovery plans through a digital twin sandbox. Among them, the digital twin sandbox stores a digital twin model corresponding to the complete information technology environment of the target component; the target component is the component targeted for disaster recovery protection in the cloud platform this time.

[0039] S12: Obtain the key parameters of each recovery plan during the deduction process. Among them, the key parameters include but are not limited to: Recovery Time Objective (RTO) and Recovery Point Objective (RPO); RTO refers to the longest time limit for an information system or business function to resume normal operation from a standstill after a disaster occurs; RPO refers to a certain past time point to which the system and data must be restored after a disaster occurs, and RPO reflects the maximum data loss that the business can tolerate.

[0040] S13: Select the optimal recovery plan from the various recovery plans based on the key parameters, and achieve disaster recovery switching of the target component through the optimal recovery plan.

[0041] For step S11, the prerequisite for simulating the execution process of multiple recovery plans using a digital twin sandbox is the prior establishment of a digital twin sandbox. The digital twin sandbox of this invention is a digital twin environment highly similar to the IT environment of the target component (such as production environment topology, resource allocation, critical configurations, etc.). This digital twin sandbox is implemented through full-stack mapping of the target component and maintains real-time state synchronization with the target component. Full-stack mapping is not merely a simple amplitude of virtual machines, but a deep mapping of the entire technology stack, including compute instances, storage volumes, network topology, load balancing rules, firewall policies, and even dependencies between applications. Real-time state synchronization indicates that the digital twin sandbox is not static, but maintains consistency with the actual IT environment of the target component by (nearly) real-time loading of state snapshots of the production environment (such as virtual machine configuration, real-time load, network traffic characteristics). This ensures that all simulations are based on the latest IT environment, not outdated scenarios.

[0042] The target component in step S11 is the object that triggers the disaster recovery protection in steps S11-S13 of this method. The target component can be any component (such as a storage volume, physical host, etc.) in the cloud platform (or other scenarios with disaster recovery protection requirements) that needs disaster recovery switching. Therefore, to enable the digital twin sandbox to simulate and extrapolate the target component, either a corresponding digital twin sandbox can be established after the target component is determined, or a digital twin sandbox of the complete IT environment of the cloud platform can be established in advance. While the former requires the establishment of the digital twin sandbox, its efficiency in the simulation and extrapolation phase is significantly higher than the latter, resulting in higher overall efficiency. However, the latter does not require determining the corresponding IT environment based on the target component, making it simpler to implement. Especially to ensure the execution result of the recovery plan throughout the entire cloud platform, the dependencies between the target component and other components must be considered when simulating the target component, which is more difficult to implement.

[0043] Furthermore, regarding the recovery plans in step S11, these multiple recovery plans can be static scripts designed based on historical experience and idealized scenarios, similar to related technologies. However, it should be noted that different recovery plans should target different scenarios to meet the needs of different disaster recovery switchover scenarios. In addition, this invention also provides an automated recovery plan generation scheme. Before step S11, the above method further includes: S14: generating multiple different recovery plans based on the risk type of the target component using policy generation rules defined in a preset policy library and stored policy options.

[0044] It should be noted that the risk type is primarily determined by the type of the target component (e.g., if the target component is a physical host, then the risk type is that the physical host is about to fail). However, for some target components that may experience multiple different types of failures, the risk type can also be determined by combining the failure type; this embodiment does not impose any restrictions on this.

[0045] This embodiment generates a corresponding recovery plan by matching the policy generation rules pre-defined in the policy library (DR-DSL) with the policy options corresponding to the risk type of the target component. This embodiment provides an automated dynamic recovery plan generation scheme, which saves manpower and can adapt to the actual scenario to provide the most suitable recovery plan, thus better ensuring the disaster recovery switchover effect.

[0046] Furthermore, regarding the policy options and policy generation rules in the above embodiments, the present invention also provides a further embodiment: the policy options include multiple policy types, namely: resource optimization type, service degradation type, site switching type, and network isolation type.

[0047] The resource optimization strategy options include: hot migration of virtual machines to a high-resource standby host and cold migration of virtual machines to a low-cost standby host; the service degradation strategy options include: switching the application mode of the target component to read-only mode; the site switching strategy options include: switching the application service of the target component to an off-site disaster recovery site; the network isolation strategy options include: prohibiting data migration of the target component and isolating the target component from the network; the generated recovery plan includes strategy options of various different policy types.

[0048] For example, taking the resource-optimized strategy option of hot-migrating virtual machines to a high-resource standby host as an example, a specific recovery action 1 that may occur in practical applications is: if host A is at risk of failure, take the recovery action of hot-migrating all virtual machines (VMs) on host A to host B. And, for example, there is also recovery action 2: migrate critical VMs from host A to host C, and shut down non-critical VMs.

[0049] As described above, this embodiment provides multiple types of strategy options and ensures that the generated recovery plan includes at least two strategy types, thus forming a more complex but better disaster recovery plan. It should be noted that this embodiment's ability to provide complex combined strategies is based on the fact that the above method can simulate and extrapolate the execution results of the recovery plan using a digital twin sandbox. That is, complex recovery plans are more difficult to predict their actual execution results, thus posing greater unknown risks. This method, based on step S11, can predict the execution results of the recovery plan, thereby turning the unknown into the known and making the implementation of more complex recovery plans possible.

[0050] Next, the simulation and deduction of multiple recovery plans in step S11 are performed. This can be done separately for different recovery plans, but it is better to conduct independent and parallel simulation and deduction of multiple recovery plans to improve the efficiency of the simulation and deduction.

[0051] The purpose of step S12 is to quantify the simulation results of step S11. This transforms the vague description of whether the recovery plan's execution result is "good" or "bad" into precise quantitative indicators. Step S12 achieves this through key parameters, including but not limited to RTO and RPO. RTO and RPO primarily reflect the impact of the recovery plan on the target components' business operations. Other key parameters can also be added based on performance impact, resource impact, and cost impact; this embodiment does not impose limitations on this.

[0052] For example, this embodiment provides a further solution for key parameters: the recovery time target and the recovery point target are business impact indicators among the key parameters; the key parameters also include: performance impact indicators, resource impact indicators and cost impact indicators; wherein, the performance impact indicators include: service interruption duration, packet loss rate during the switching process, and the change in application response latency; the resource impact indicators include: the time required for resource reconstruction, and the expected consumption of resources (such as CPU, memory, bandwidth, etc.) of the target components; the cost impact indicators include: the direct and indirect costs (such as time costs, power costs, etc.) required to execute the recovery plan.

[0053] Furthermore, some of the performance metrics in the above examples can be directly obtained or statistically obtained, while others cannot be directly obtained and need to be predicted through certain means. For example, consider the migration time parameter, which may need to be quantified during simulated hot migration. Its calculation logic is as follows: the migration time T_migration is approximately equal to the remaining unsynchronized memory size (total virtual machine memory VM_memory_size minus pre-copied memory) divided by the actual available network bandwidth Effective_bandwidth, plus the fixed overhead VM_resume_overhead required for the virtual machine to resume operation on the target end. Therefore, the migration time estimation model can be obtained as: T_migration ≈ (VM_memory_size - Pre_copied_memory) / Effective_bandwidth + VM_resume_overhead.

[0054] Based on the above, this embodiment also provides a possible example of how to simulate and extrapolate the above recovery action: Taking recovery action 1 given in the above embodiment as an example, the simulation will be carried out in a "transaction" or "snapshot" in the digital twin sandbox; first, the node attributes of host machine B are checked to determine whether its remaining resources are sufficient; then, a migration time estimation function is called, which takes into account parameters such as the memory size and network bandwidth of the VM, and calculates the expected RTO according to the formula T_migration ≈ (VM_memory_size-Pre_copied_memory) / Effective_bandwidth + VM_resume_overhead. At the same time, the expected RPO is calculated based on the status of the storage replication link (obtained from the twin data). After the simulation is completed, a report containing indicators such as expected RTO, RPO, performance impact, and resource consumption is output as the final quantitative simulation result.

[0055] By acquiring the key parameters in step S12, the simulation results of each recovery plan can be quantified, facilitating the selection of the optimal recovery plan in subsequent step S13. After determining the optimal recovery plan, in addition to directly using the optimal recovery plan for disaster recovery switching of the target component, this embodiment also provides another optional implementation scheme. The above method further includes: S151: Determining the predicted benefit score of the optimal recovery plan based on the key parameters. S152: Determining the basic score of the optimal recovery plan based on preset expert rules. S153: Weighting the predicted benefit score and the basic score to obtain a comprehensive confidence level. S154: Determining whether to perform disaster recovery switching of the target component using the optimal recovery plan based on the comprehensive confidence level.

[0056] After steps S11-S13, the optimal recovery plan can be obtained. At this point, this embodiment provides a hybrid decision-making arbitration mechanism. In this embodiment, the execution of disaster recovery switching no longer blindly relies on a single simulation model, but instead adopts a weighted evidence fusion mechanism, incorporating expert rules into the evaluation scope. This embodiment uses the predicted benefits generated by simulation as dynamic evidence; and uses hard rules based on the experience of Site Reliability Engineering (SRE) experts (such as capacity limits and link status) as static baselines; through weighted processing, the two are organically combined, taking into account their advantages and compensating for their disadvantages, to achieve better, data-driven decision-making. This method can fundamentally avoid secondary disasters caused by erroneous disaster recovery operations, greatly improving the scientific nature and reliability of business continuity assurance.

[0057] In addition, based on the scoring scheme provided in this embodiment, in the above step S13 of selecting the optimal recovery plan, it can also be achieved through the scoring obtained in this embodiment. For example, it can be selected based on the predicted revenue score that directly reflects the quality of the simulation推演 result, or it can be selected based on the comprehensive confidence level after weighted processing. This embodiment does not limit this.

[0058] Further, based on the scoring scheme provided in the above embodiment, this embodiment also provides a further implementation scheme. After step S13: achieving disaster recovery switching of the target component through the optimal recovery plan, the method further includes: S21: obtaining the key parameters after achieving disaster recovery switching of the target component according to the optimal recovery plan, and comparing them with the key parameters obtained during the推演 process of the optimal recovery plan to obtain the prediction error corresponding to each key parameter. S22: If the prediction error meets the drift condition, adjust the parameters of the simulation prediction formula corresponding to the key parameter.

[0059] The drift condition is that the prediction errors corresponding to more than a preset ratio (such as 95%) of the key parameters exceed the tolerance threshold; the simulation prediction formula is for some key parameters that cannot be directly obtained or statistically analyzed (such as the migration time T_migration shown in the above embodiment, and the parameter to be adjusted at this time can specifically be the actually available network bandwidth Effective_bandwidth), and is used to predict the key parameter through other data associated with the corresponding key parameter. It should be noted that this embodiment does not limit the specific value of the preset ratio, and the above example of 95% is only an optional scheme. Its purpose is to statistically analyze the error through the P95 quantile, which can effectively avoid being interfered by a single extreme accidental event.

[0060] S23: If the prediction error still meets the drift condition, lower the weight coefficient of the predicted revenue score.

[0061] The prediction error in this step still meets the drift condition, that is, after adjusting the parameters of the simulation prediction formula in step S22 above, the prediction error still meets the drift condition. Similarly, in the following step S24, it means that after the adjustment in this step S23, the prediction error still meets the drift condition.

[0062] S24: If the prediction error still meets the drift condition, recalibrate the digital twin sandbox.

[0063] Therefore, this embodiment introduces an adaptive calibration mechanism. This mechanism continuously compares the differences between simulation results and actual execution results, enabling the simulation model to continuously self-correct and evolve. Simultaneously, to avoid interference from single extreme and occasional events, this embodiment uses a preset proportion to statistically analyze prediction errors. This means that only when prediction errors exceeding the preset proportion generally exceed a tolerable threshold will the simulation model be considered to have "drifted," meaning its predictive ability has deviated from reality and become unreliable. After determining that the model is inaccurate, this embodiment also provides a three-level progressive correction scheme. First, once the model is determined to be inaccurate, this embodiment automatically fine-tunes the core parameters in the simulation prediction formula (such as the actual available network bandwidth, Effective_bandwidth); second, if the above adjustments are ineffective, the trust weight of the simulation result in decision-making is reduced; finally, if the adjustments are still ineffective, a comprehensive recalibration of the sandbox environment is triggered to rebuild the simulation model. Through the above three-level progressive correction scheme, reliable and accurate self-optimization of the simulation model is achieved, ensuring that the simulation model can adapt to the dynamic changes of actual application scenarios and provide reliable simulation results.

[0064] Furthermore, in practical applications, there may be anomalies that cannot be resolved even by the three-level progressive correction scheme provided in the above embodiments. To address this, this embodiment further provides an implementation scheme. After step S24, the method further includes: S25: If N consecutive prediction errors still satisfy the drift condition, then the upper limit of the weight coefficient of the prediction return score is limited to a preset limit value, and the step of determining whether to perform disaster recovery switching of the target component based on the comprehensive confidence level is restricted. Wherein, N is any positive integer greater than 1 (e.g., 2). The preset limit value is not limited in this embodiment; an optional implementation scheme is 0.6.

[0065] S26: Disaster recovery switching of the target component is permitted only upon receiving a confirmation command from the manual confirmation channel. The manual confirmation channel allows users to perceive the current optimal recovery plan through human-computer interaction devices, and after manual confirmation, a command is issued indicating whether to perform the disaster recovery switch using this optimal plan. This is done manually before the target component's disaster recovery switch. Furthermore, the restrictions in this step can be lifted via commands, such as re-validating the simulation model after the administrator confirms the problem has been resolved by performing a unique name error (UNE) check.

[0066] This embodiment provides a final safety defense against persistent failures. If the adaptive calibration mechanism provided in the above embodiment is ineffective, it indicates that the simulation system may have serious systemic biases. In this case, the safety circuit breaker mechanism provided in this embodiment provides protection. Specifically, this embodiment forcibly limits the influence of simulation in the entire decision-making process, restricting the upper limit of the weight coefficient of the predicted return score to a preset limit value (e.g., 0.6), fundamentally limiting the influence of an unreliable model. Furthermore, this embodiment immediately suspends the fully automated decision-making capabilities related to simulation, forcing all subsequent disaster recovery operations to go through a "manual confirmation channel." This means that before the simulation system is fully repaired and re-verified, any high-risk switching action must be reviewed and approved by the administrator before execution. This ensures that automated decisions can be manually taken over in case of anomalies, guaranteeing the safety of disaster recovery switching under extreme circumstances.

[0067] On the other hand, the above embodiments address the prediction of whether problems will occur in the recovery plan. Subsequently, determining which components will be affected if problems do occur is also a key issue that needs to be considered when actually implementing disaster recovery switching. To address the above issues, the present invention provides an optional embodiment. After step S11, the above method further includes: S16: Performing a bidirectional traversal of the dependency graph, starting from the target component, both upwards and downwards, to determine the influence radius of the target component.

[0068] The dependency graph is a pre-built graph based on the dependency relationships between various components in the cloud platform. It should be noted that this embodiment does not specifically limit the aforementioned dependency relationships, which may include, but are not limited to: dependencies between application instances and services, dependencies between application instances and underlying physical devices, dependencies between virtualization layers, and dependencies between physical layers.

[0069] Step S11 specifically includes: S111: Determine the minimum set of objects required for the simulation based on the influence radius corresponding to the target component. S112: Simulate the process of executing the recovery plan on the minimum set of objects using a digital twin sandbox.

[0070] Regarding the establishment of the dependency graph in step S16 above, there are multiple optional implementation schemes after the dependency relationships are determined, and this embodiment does not limit this. However, the present invention provides an optional specific embodiment in which the dependency graph establishment process includes: S31: Determining the call relationships between microservices, application instances, and the external interfaces of application instances by using inter-service call chain data captured by the Application Performance Management (APM) probe and the Extended Berkeley Packet Filter (eBPF).

[0071] S32: Determine the runs-on relationships between application instances and virtual machines, and between virtual machines and physical hosts, by using static configuration information in the configuration management database (CMDB) and factual scheduling results obtained from the application programming interface (API) of the container platform (such as Kubernetes).

[0072] S33: By polling the application programming interface of the virtualization management platform (such as vCenter), obtain the uses relationship between virtual machines and datastores, and the connections to relationships between virtual machines and virtual networks (vSwitch).

[0073] S34: Determine the physical connection relationships between physical servers, network devices, and storage devices by using link layer discovery protocol information (such as LLDP / CDP protocol) of network devices (such as switches and routers) and configuration information of storage arrays.

[0074] S35: Bundle the database's data volumes and log volumes according to a predefined storage strategy to establish a consistent relationship; whereby the data volumes and log volumes that establish a consistent relationship are treated as an atomic unit.

[0075] S36: Parse firewall and security group rules, and convert access control policies (ACLs) into allowed-to-access edges in the dependency graph.

[0076] S37: Build a dependency graph based on the obtained dependencies. Dependencies include: call relationships, run-on relationships, use relationships, connect-to relationships, maintain-consistency relationships, and allowed edges.

[0077] Specifically, step S31 corresponds to obtaining the dependencies between the aforementioned applications and services; step S32 corresponds to obtaining the dependencies between the aforementioned application instances and the underlying physical devices; step S33 corresponds to obtaining the aforementioned virtualization layer dependencies; and step S34 corresponds to obtaining the aforementioned physical layer dependencies. Further, steps S35 and S36 correspond to the consistency and constraint relationships between nodes. Step S35 addresses the consistency relationship by binding database volumes and log volumes into a consistent_with relationship based on best practices from storage vendors or predefined policies from database administrators (DBAs), ensuring that these volumes are treated as an indivisible atomic unit during any disaster recovery operation. Step S36 addresses the constraint relationship by parsing firewall and security group rules, transforming access control policies into weighted edges of allowed_to_access in the dependency graph, providing a basis for security-related simulations.

[0078] It should also be noted that the dependency graph established in this embodiment is not static. Changes in the aforementioned data sources (such as new service launches, virtual machine migrations, and configuration changes) should be continuously monitored, and the dependency graph should be incrementally updated within a time window of seconds to minutes to ensure its timeliness.

[0079] The core of this embodiment is a graph database (such as Neo4j), namely the dependency graph mentioned above. It stores a digital twin model of the entire IT environment. This model is kept up-to-date by periodically synchronizing the CMDB, virtualization platform API, and application topology data (APM topology data). Nodes in the dependency graph represent entities such as physical machines, VMs, applications, and storage volumes, while edges represent relationships such as "running on," "connected to," and "dependent on." Each node and edge is associated with attributes, such as the node's CPU capacity and memory size, and the edge's network bandwidth. These attributes are updated in near real-time by data from the observation layer.

[0080] After obtaining the dependency graph through this embodiment, efficient causal inference and influence range quantification can be performed. For example, in the above embodiment, the scope of simulation and deduction of the target component is determined based on the dependency graph, avoiding resource waste and efficiency reduction caused by simulating and deducing too large a scope.

[0081] Specifically, determining the impact radius in step S111 involves two main traversals: upward tracing and downward diffusion. For upward tracing, the process follows dependency chains such as runs_on, uses, and calls to identify all upper-layer components that directly or indirectly depend on the risk node. For example: storage volume A -> virtual machine B -> service C -> business D. For downward diffusion, the process primarily analyzes dependencies to determine whether a node failure will affect its downstream components or associated components. For example, a core switch failure will affect all physical servers with connects_to relationships to it.

[0082] Therefore, based on the dependency graph established in this embodiment, step S111 in the above embodiment can accurately delineate the "influence radius" of a risk event occurring in the target component by aggregating all nodes affected by the target component. Furthermore, it can clearly report the consequences in business language. For example, the RPO default risk of the underlying storage volume LUN-05 is expected to lead to a decrease in the database performance of the "order system" and may affect the stability of the "user payment" function.

[0083] In addition, based on the above dependency graph, the present invention also provides an optional embodiment for completing disaster recovery switching. The above step S13 further includes: S131: Determine the disaster recovery operation sequence of the target component according to the dependency graph. S132: Implement the disaster recovery switching of the target component according to the disaster recovery operation sequence. Among them, the disaster recovery operation sequence includes disaster recovery operations for the target component and for the nodes in the dependency graph that have a dependency relationship with the target component; the execution order between the disaster recovery operations is determined based on the dependency relationship in the dependency graph.

[0084] Thus, in this embodiment, after finally determining the optimal recovery plan, a blueprint for specific execution steps (Runbook) is generated through the dependency relationship provided by the dependency graph. This embodiment can automatically generate a parallelized operation sequence based on topological sorting according to the dependency order defined in the dependency graph, ensuring that disaster recovery is performed in the most efficient and secure manner (for example, first shutting down the application and then uninstalling the storage).

[0085] Furthermore, the dependency graph can also be used for generating the recovery plan in step S14. For example, when migrating a database VM belonging to a storage consistency group (i.e., the data volume or log volume bound with the above consistent_with relationship), all associated VMs must be included in the same migration plan.

[0086] On the other hand, this embodiment also provides another optional implementation for the dependency graph: calculating all nodes in the dependency graph through graph algorithms (such as PageRank or Betweenness Centrality) to quantify the "criticality" of each component. Among them, the criticality is mainly reflected in the following two aspects: 1. Criticality Score: The more critical services a node is depended on, the higher its criticality score. This enables the system to automatically identify "single points of failure" or vulnerable components on the critical path. 2. Vulnerability Analysis: Identify those services that depend on components known to have vulnerabilities or in a high-risk state, and give early warnings of potential cascading failure risks.

[0087] On the other hand, the above embodiments illustrate that the target component is the component targeted during this disaster recovery switch. However, the above embodiments do not limit how to determine that this component needs a disaster recovery switch. Currently, a common approach is to monitor the health status of each component, and trigger a disaster recovery switch for that component when a component is found to be faulty. However, this approach has a lag, as disaster recovery protection can only be performed after a fault occurs, resulting in insufficient protection effectiveness. To address this, the present invention also provides a further embodiment, in which the above method further includes the following steps before step S11: S41: Monitoring the status data of each component in the cloud platform. S42: Predicting the risk score of the component based on the status data according to a pre-established prediction model. S43: When the risk score of any component exceeds the trigger risk threshold, the component is designated as the target component, and step S11 is triggered.

[0088] In this embodiment, the specific value of the trigger risk threshold is not limited. In one optional embodiment, the maximum risk score is 1 (corresponding to a 100% probability that the component will fail), then the trigger risk threshold can be 0.75.

[0089] As described above, this embodiment predicts the probability of each component failing using a predictive model and quantifies this probability using a risk score. Furthermore, the quantified parameters can also serve as data support for triggering disaster recovery switching. Specifically, when the risk score of a component exceeds the trigger risk threshold, step S11 and subsequent steps are triggered.

[0090] Furthermore, the above embodiments do not limit the prediction model; various commonly used machine learning models can be adopted. The prediction model is obtained by learning from the sample data of historical operating data of each component and corresponding failure results. In addition, the prediction model can be a single model or a composite model containing multiple models; this invention does not limit this. However, this invention provides an optional embodiment of a composite prediction model.

[0091] The predictive models include: a hardware failure prediction model, a resource congestion prediction model, a recovery point target default prediction model, and an application degradation and anomaly synthesis detection model. Specifically, the hardware failure prediction model predicts the probability of component failure; the resource congestion prediction model predicts the probability of a component encountering a resource bottleneck; the recovery point target default prediction model predicts the probability of a component exceeding the business point target threshold set by the business; and the application degradation and anomaly synthesis detection model predicts the probability of a component exhibiting behavioral pattern deviations.

[0092] Specifically, step S42 involves weighting the probabilities output by the hardware failure prediction model, resource congestion prediction model, recovery point target default prediction model, and application degradation and anomaly synthesis detection model to obtain a risk score.

[0093] Specifically, the implementations of the above prediction models are shown below.

[0094] 1. Hardware Failure Prediction Model: Based on historical hardware failure records and real-time SMART data, temperature, power consumption and other indicators, the model uses sequence models such as Long Short-Term Memory (LSTM) networks to predict the failure rate of hardware such as servers and hard drives in the future.

[0095] 2. Resource congestion prediction model: By analyzing the historical usage patterns (such as periodicity and trend) of resources such as CPU, memory, and network bandwidth, and using time series prediction models such as ARIMA (autoregressive integral moving average model) or Prophet, potential future resource bottlenecks can be predicted.

[0096] 3. RPO Default Prediction Model: Employing a multivariate LSTM time-series prediction architecture. This model not only monitors the current replication status but also uses the Data Change Rate (DCR) as a stress input and link bandwidth and network quality as constraints to construct a multi-dimensional feature space. By analyzing the supply and demand relationship over a past period through a sliding window, the model can learn the time lag pattern between "write surges" and "latency accumulation," thereby accurately plotting the replication latency trend curve for a future period (e.g., 30 minutes). Once the prediction curve shows a tendency to exceed the RPO threshold, the system can issue an early warning and calculate the exact remaining safety buffer time.

[0097] 4. Application Degradation and Anomaly Synthesis Detection Model: This model is more complex, combining application performance metrics (such as response time and error rate) with underlying server metrics. It uses unsupervised learning algorithms such as Variational Autoencoders (VAEs) or Isolation Forests to detect deviations in the overall system behavior pattern. This is particularly effective in detecting "slow-onset" performance degradation caused by code defects, configuration errors, or unknown attacks.

[0098] It should be noted that the four prediction models described above in this embodiment operate independently, and their outputs are integrated into a single quantitative parameter, namely the risk score, through weighted processing. Optionally, this weighted processing can be implemented using an Evidence Fusion Engine. The Evidence Fusion Engine can comprehensively evaluate the prediction results of multiple models to obtain a single, more reliable risk score. Its core calculation formula is: RiskScore = σ( Σk αk•logit(pk)).

[0099] In the formula, k represents an index, indicating the k-th prediction model participating in the evaluation. For example, k=1 represents a hardware failure prediction model, and k=2 represents a resource congestion prediction model. Pk represents the risk probability output by the k-th prediction model, a value between 0 and 1. For example, p1 = 0.7 indicates that the first model judges the current risk probability to be 70%. logit(pk) represents a mathematical transformation function, namely the logit function. This function is used to map a probability value pk in the interval [0, 1] to the entire real number range (negative infinity to positive infinity). It can be understood as "unlocking" the probability and converting it into a "score" that is easier to add and subtract. Wk represents the confidence level of the k-th prediction model in its own output; the higher this value, the more reliable the prediction model believes its prediction is. αk represents the weighting coefficient of the k-th prediction model in the final risk score generation. The risk score can be calculated using αk = wk / Σj (where j is a variable distinct from k, and its maximum value is also the total number of prediction models), which is the confidence score wk of the current prediction model divided by the sum of the confidence scores of all prediction models. This ensures that the weight coefficients of all models add up to exactly 100%. Σ is the summation symbol in mathematics, representing the sum of the calculation results of all prediction models (k=1,2,3...). σ is the inverse function of the logit function, which remaps any value in the entire real number range (i.e., the summation result of Σk) back to the interval [0, 1], making it a standardized probability value. RiskScore is the risk score finally calculated by the above formula, which is also a value between 0 and 1, representing the final risk judgment obtained after the system integrates the opinions of all parties.

[0100] As described above, the calculation process of the risk score formula can be broken down into the following three steps (equivalent to an expert consultation involving multiple experts): 1. Opinion Transformation: First, logit(pk) transforms the limited-range risk probability pk given by each prediction model (equivalent to an expert) into a base score that can be accumulated infinitely. 2. Weighted Summarization: Next, Σk αk•logit(pk) is the core weighting step. It multiplies the base score (logit(pk)) of each model by the corresponding weight coefficient (αk), and then sums the results of all models to obtain a total score. The higher the confidence level (wk) of a model, the larger its weight coefficient αk, and the greater the weight of its opinion in the risk score. 3. Result Standardization: Finally, the σ(...) function transforms the total score obtained in the previous step back into a standard risk score between 0 and 1, making it easy to understand and use. In summary, the above formula scientifically combines the wisdom of multiple models through a process of "conversion-weighting-reconversion," while taking into account the confidence level of each model, ultimately arriving at a risk assessment conclusion that is more robust and credible than any single model.

[0101] On the other hand, as can be seen from the above embodiments, whether it is the simulation and deduction of the recovery plan based on the simulation model, the establishment of the dependency map, or the prediction of the risk probability of each component based on the prediction model, all of these require the acquisition of data from the entire system. In particular, the composite prediction model provided in the above embodiments of the present invention requires the use of data from multiple dimensions to achieve more accurate prediction and disaster recovery switching effects. It should be noted that the present invention does not limit the specific data types acquired, and can be determined according to the needs of the above embodiments. Based on the above embodiments, an optional multi-dimensional data acquisition scheme is involved.

[0102] 1. Computation Layer Metrics: Collect core performance metrics for each physical host machine and its hosted virtual machines, such as CPU utilization, load, memory consumption, disk I / O wait, and context switch count. These data are the direct basis for judging the health of computing resources.

[0103] 2. Storage Layer Metrics: For distributed or centralized storage arrays, the focus is on monitoring the status of the storage replication link. This includes: data replication latency (reflecting potential Recovery Point Objective (RPO) risk), consistency markers for data at both ends, read / write rates of storage volumes, IOPS (Input / Output Operations Per Second), and Self-Monitoring, Analysis and Reporting Technology (SMART) data for bad blocks or disks.

[0104] 3. Network Layer Metrics: Monitor network traffic within the data center (east-west direction) and externally (north-south direction). By collecting data such as port traffic, packet loss rate, network latency, and connection count from switches, routers, or virtual switches, network congestion or link anomalies can be detected.

[0105] 4. Application Layer Metrics: Delving into the internal business logic, this involves collecting application service logs (such as error logs and warning logs), transaction success rates, average interface response times, and other application performance management (APM) metrics. It also includes security-related compliance audit logs to detect abnormal access or potential internal threats.

[0106] 5. Environmental indicators: Collect environmental data from the data center, such as rack temperature, humidity, and server power consumption. Extreme environmental changes are a major cause of hardware failures.

[0107] Furthermore, since the aforementioned data is collected from multiple dimensions, and the original data is noisy and isolated, it cannot be directly used for accurate prediction models. Therefore, this embodiment also provides a further implementation scheme, which includes the following data processing procedure after the data acquisition.

[0108] A. Time series alignment: Time series data from different sources and with varying collection frequencies are aligned to a unified time grid using methods such as interpolation or aggregation. This is the foundation for cross-domain correlation analysis.

[0109] B. Outlier suppression: Statistical methods (such as the 3-sigma rule) or algorithms such as the Local Outlier Factor (LOF) are used to identify and smooth invalid abnormal data caused by monitoring system jitter or instantaneous pulses, preventing the model from making misjudgments.

[0110] C. Online Feature Generation: This step transforms the raw data into input knowledge that the prediction model can understand. This step is not simply a pass-through of the raw data, but rather dynamically calculates a series of derived features with higher information density, for example...

[0111] C-1 Window Statistical Features: For various indicators such as computing, networking, and storage, based on a unified sampling period (e.g., 5–15 seconds), calculate their incremental statistical features within multiple sliding time windows (e.g., 1 minute, 5 minutes, 30 minutes), including but not limited to mean, variance, slope, kurtosis, etc., to capture trends and volatility at different time scales.

[0112] C-2. Spectrum and Abrupt Change Characteristics: By applying signal processing techniques such as Fourier transform or wavelet transform, the periodicity of indicators can be analyzed or abrupt changes in non-stationary signals can be detected. The first K principal components of the spectrum can be extracted as stable features, which is very effective in discovering hidden periodic faults or abrupt changes in system state.

[0113] C-3, Service Topology Embedding: This method transforms the call dependencies between applications (service topology graph) into a numerical vector representation using techniques such as Graph Neural Networks (GNNs). This embedded vector can quantify the importance of services within the entire system and their proximity relationships, enabling the model to understand risk propagation along the "critical path."

[0114] Furthermore, since the aforementioned data acquisition involves multi-dimensional and large-volume data, this invention also provides a further embodiment to minimize the performance impact on actual production operations. The method includes: S51: Capturing kernel-level data transmitted between the operating system and external systems by running an extended Berkeley packet filter in the operating system kernel. S52: Obtaining network traffic copies by configuring the mirror port of the switch and sending them to the application performance management probe for analysis to obtain network data. S53: Obtaining container data by collecting logs and capturing metrics from accompanying containers deployed for each application container in a containerized environment.

[0115] Step S51 utilizes kernel-level observation technology, namely the Extended Berkeley Packet Filter (eBPF). By executing controlled and secure microprograms within the operating system kernel, it efficiently captures fine-grained data such as system calls, network connections, and I / O operations without modifying application code or the kernel, with extremely low overhead. Step S52 corresponds to a network traffic mirroring method. By configuring the switch's mirror port (SPAN / RSPAN), a copy of the production network traffic is losslessly sent to the analysis probe, achieving non-intrusive monitoring of network communication. Step S53 corresponds to the Sidecar mode. In a containerized environment, a lightweight accompanying container (i.e., a Sidecar) is deployed for each application container, specifically responsible for observation tasks such as log collection and metric capture, decoupling the observation logic from the business logic. Therefore, this embodiment provides a bypass data collection scheme, collecting various types of data, including kernel-level data, network data, and container data, in a lightweight and bypassed manner, thereby covering the data collection needs of the above embodiments and ensuring no adverse impact on normal production operations.

[0116] Furthermore, a primary application scenario addressed by this invention is cloud platforms. Current private clouds often involve multi-tenancy scenarios, where data isolation and security are paramount. Therefore, this embodiment also provides an optional implementation scheme, further comprising S54: assigning a unique tenant label to the acquired data. This embodiment ensures data isolation and security by assigning a unique tenant label to the collected data and maintaining this label throughout the entire data processing chain, thus meeting the needs of multi-tenant private cloud scenarios.

[0117] Furthermore, the present invention also provides an optional embodiment based on the above embodiments, wherein the method further includes: S54: scoring the quality of data acquired by each data source in each acquisition cycle based on the completeness, timeliness, and consistency of the data acquired from each data source. The data sources include: an extended Berkeley packet filter, a mirror port, and an accompanying container. S55: If the quality score of any data source is lower than a preset quality threshold, the weight coefficient corresponding to the risk coefficient in determining the prediction model that provides data input from that data source is reduced.

[0118] This embodiment continuously monitors the integrity, timeliness, and consistency of input data and generates a quality score for each batch of data. When data quality deteriorates or data distribution shifts significantly (i.e., the current data features differ greatly from the data features used during model training), the system can automatically issue an alarm. It then correspondingly reduces the confidence weight of the prediction model based on data collected from that data source, thereby further improving the accuracy of risk assessment based on the aforementioned prediction model.

[0119] In addition, based on the above embodiments, this method is as follows: Figure 2 As shown, it can be divided into the following stages: data observation and collection, corresponding to the acquisition of the five indicators mentioned above, data processing flow, lightweight bypass data collection, and data quality assurance; risk assessment and dependency analysis, corresponding to the joint risk assessment based on the composite prediction model, the generation of dependency graphs, and dependency analysis based on dependency graphs in the above embodiments; digital twin and counterfactual simulation, corresponding to the simulation of recovery plans through digital twin sandboxes, the automated generation of recovery plans, and the quantification of simulation results; adaptive calibration and security assurance, corresponding to the adaptive calibration mechanism, security circuit breaker scheme, and closed-loop feedback optimization scheme in the above embodiments.

[0120] In addition to the above-described embodiment of a disaster recovery method based on digital twin simulation, this invention also provides an embodiment corresponding to a computer program product. A computer program product includes a computer program / instructions, which, when executed by a processor, can implement the steps of the disaster recovery method based on digital twin simulation as described in any of the above embodiments.

[0121] Since the embodiments of the computer program product portion correspond to the embodiments of the method portion, please refer to the description of the embodiments of the method portion for the embodiments of the computer program product portion, which will not be repeated here.

[0122] In the above embodiments, a disaster recovery method based on digital twin simulation has been described in detail. This invention also provides an embodiment of a disaster recovery device based on digital twin simulation. It should be noted that this invention describes the device embodiment from two perspectives: one based on functional modules, and the other based on hardware.

[0123] From the perspective of functional modules, such as Figure 3 As shown, this embodiment provides a disaster recovery device based on digital twin simulation, including: a simulation module 11, used to simulate the execution process of multiple recovery plans through a digital twin sandbox; wherein, the digital twin sandbox stores a digital twin model corresponding to the complete information technology environment of the target component; the target component is the component in the cloud platform for which disaster recovery protection is being performed. A result quantification module 12 is used to obtain key parameters of each recovery plan during the simulation process; wherein, the key parameters include: recovery time target and recovery point target. A disaster recovery decision module 13 is used to select the optimal recovery plan from each recovery plan based on the key parameters, and to achieve disaster recovery switching of the target component through the optimal recovery plan.

[0124] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0125] Figure 4 A structural diagram of a disaster recovery device based on digital twin simulation, provided for another embodiment of the present invention, is shown below. Figure 4 As shown, a disaster recovery device based on digital twin simulation includes: a memory 20 for storing computer programs.

[0126] The processor 21 is used to implement the steps of a disaster recovery method based on digital twin simulation as described in the above embodiment when executing a computer program.

[0127] The disaster recovery device based on digital twin simulation provided in this embodiment may include, but is not limited to, mobile terminals, personal computers, workstations, etc.

[0128] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array. The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0129] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of a disaster recovery method based on digital twin simulation disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, etc., and the storage method may be temporary storage or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, a disaster recovery method based on digital twin simulation.

[0130] In some embodiments, a disaster recovery device based on digital twin simulation may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0131] Those skilled in the art will understand that Figure 4 The structure shown does not constitute a limitation on a disaster recovery device based on digital twin simulation and may include more or fewer components than shown.

[0132] The present invention provides a disaster recovery device based on digital twin simulation, including a memory and a processor. When the processor executes the program stored in the memory, it can implement the following method: a disaster recovery method based on digital twin simulation.

[0133] Finally, the present invention also provides an embodiment corresponding to a non-volatile storage medium. A computer program is stored on the non-volatile storage medium, and when executed by a processor, the computer program implements the steps described in the above method embodiments.

[0134] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0135] The foregoing has provided a detailed description of a disaster recovery method, apparatus, program product, and medium based on digital twin simulation provided by this invention. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this invention without departing from the principles of this invention, and these improvements and modifications also fall within the protection scope of this invention.

[0136] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A disaster recovery method based on digital twin simulation, characterized in that, include: The execution process of multiple recovery plans is simulated using a digital twin sandbox; wherein, the digital twin sandbox stores a digital twin model corresponding to the complete information technology environment of the target component; the target component is the component in the cloud platform for which disaster recovery protection is being carried out in this instance. Obtain the key parameters of each recovery plan during the simulation process; wherein, the key parameters include: recovery time target and recovery point target; Based on the key parameters, the optimal recovery plan is selected from the recovery plans, and the disaster recovery switch of the target component is achieved through the optimal recovery plan; Before the simulation of the execution process of multiple recovery plans using a digital twin sandbox, the following steps are also included: Starting from the target component, a bidirectional traversal of upward and downward directions is performed in the dependency graph to determine the influence radius of the target component; wherein, the dependency graph is a graph pre-established based on the dependency relationships between the components in the cloud platform; The simulation of the execution process of multiple recovery plans using a digital twin sandbox includes: Based on the influence radius corresponding to the target component, determine the minimum set of objects required for the deduction; The process of executing the recovery plan on the minimum set of objects is simulated using the digital twin sandbox; The process of establishing the dependency graph includes: By capturing inter-service call chain data using application performance management probes and extended Berkeley package filters, the call relationships between microservices, application instances, and the external interfaces of the application instances are determined. By using static configuration information in the configuration management database and factual scheduling results obtained from the application programming interface of the container platform, the runtime relationship between the application instance and the virtual machine, and between the virtual machine and the physical host machine, is determined. By polling the application programming interface of the virtualization management platform, the usage relationship between the virtual machine and the storage volume, as well as the connection relationship between the virtual machine and the virtual network, can be obtained. By using the link layer discovery protocol information of the network device and the configuration information of the storage array, the physical connection relationship between the physical server, the network device, and the storage device is determined; The database's data volumes and log volumes are bundled according to a predefined storage strategy to establish a consistency relationship; wherein, the data volume and log volume that establish the consistency relationship are considered as an atomic unit; Parse firewall and security group rules to convert access control policies into allowed access edges in the dependency graph; The dependency graph is constructed based on the obtained dependencies; The dependencies include: invocation relationships, running relationships, usage relationships, connection relationships, consistency relationships, and allowed access edges. The dependency graph is implemented based on a graph database, which stores digital twin models corresponding to the complete information technology environment. The digital twin models are kept up-to-date by periodically synchronizing CMDB, virtualization platform APIs, and application topology data. Nodes in the dependency graph represent entities, and edges represent the dependencies. The entities include: physical machines, VMs, applications, and storage volumes. Each node and edge is assigned attributes, including: the node's CPU capacity and memory size, and the edge's network bandwidth. These attributes are updated in near real-time by data from the observation layer. Achieving disaster recovery switching of the target component through the optimal recovery plan includes: The disaster recovery operation sequence of the target component is determined based on the dependency graph; The disaster recovery operation sequence is used to switch the target component to disaster recovery. The disaster recovery operation sequence includes disaster recovery operations for the target component and for nodes in the dependency graph that have dependencies on the target component; the execution order of the disaster recovery operations is determined based on the dependencies in the dependency graph.

2. The disaster recovery method based on digital twin simulation according to claim 1, characterized in that, Before the simulation of the execution process of multiple recovery plans using a digital twin sandbox, the following steps are also included: Based on the risk type of the target component, multiple different recovery plans are generated using the policy generation rules defined in the preset policy library and the stored policy options.

3. The disaster recovery method based on digital twin simulation according to claim 2, characterized in that, The policy options include several policy types: resource optimization, service degradation, site switching, and network isolation. The resource-optimized strategy options include: hot-migrating virtual machines to high-resource standby hosts and cold-migrating virtual machines to low-cost standby hosts; The service degradation strategy options include: switching the application mode of the target component to read-only mode; The site switching strategy options include: switching the application service of the target component to an off-site disaster recovery site; The network isolation type of policy options includes: prohibiting data migration to the target component and network isolating the target component; The generated recovery plan includes policy options of various different policy types.

4. The disaster recovery method based on digital twin simulation according to claim 1, characterized in that, After selecting the optimal recovery plan from the recovery plans based on the key parameters, the process further includes: The predicted benefit score of the optimal recovery plan is determined based on the key parameters. The baseline score for the optimal recovery plan is determined based on preset expert rules; The predicted return score and the basic score are weighted to obtain a comprehensive confidence level; Based on the comprehensive confidence level, determine whether to perform disaster recovery switching of the target component according to the optimal recovery plan.

5. The disaster recovery method based on digital twin simulation according to claim 4, characterized in that, After achieving disaster recovery switching of the target component through the optimal recovery plan, the following is also included: The key parameters after the disaster recovery switch of the target component is implemented according to the optimal recovery plan are obtained and compared with the key parameters obtained during the simulation of the optimal recovery plan to obtain the prediction error corresponding to each key parameter. If the prediction error meets the drift condition, the parameters of the simulation prediction formula corresponding to the key parameter are adjusted; wherein, the drift condition is: the prediction error corresponding to the key parameter above a preset proportion exceeds the tolerance threshold; the simulation prediction formula is used to predict the key parameter by using other data associated with the corresponding key parameter for some key parameters that cannot be directly obtained or statistically analyzed. If the prediction error still meets the drift condition, then the weighting coefficient of the prediction return score is reduced. If the prediction error still meets the drift condition, the digital twin sandbox is recalibrated.

6. The disaster recovery method based on digital twin simulation according to claim 5, characterized in that, After recalibrating the digital twin sandbox, the following is also included: If the prediction error occurs N times consecutively and still satisfies the drift condition, the upper limit of the weight coefficient of the prediction return score is limited to a preset limit value, and the step of determining whether to perform disaster recovery switching of the target component based on the comprehensive confidence level is restricted; where N is any positive integer greater than 1; Disaster recovery switching of the target component is permitted only upon receiving a confirmation instruction from the manual confirmation channel.

7. The disaster recovery method based on digital twin simulation according to claim 1, characterized in that, The recovery time target and the recovery point target are business impact indicators among the key parameters; the key parameters also include: performance impact indicators, resource impact indicators, and cost impact indicators. The performance impact metrics include: service interruption duration, packet loss rate during switching, and changes in application response latency. The resource impact indicators include: the time required for resource reconfiguration and the estimated resource consumption of the target component; The cost impact indicators include: the direct and indirect expenses required to implement the recovery plan.

8. The disaster recovery method based on digital twin simulation according to claim 1, characterized in that, Before the simulation of the execution process of multiple recovery plans using a digital twin sandbox, the following steps are also included: Monitor the status data of each component in the cloud platform; The risk score of the component is predicted based on the state data according to a pre-established prediction model; When the risk score of any of the components exceeds the trigger risk threshold, the component is designated as the target component, and the step of simulating the execution process of multiple recovery plans through a digital twin sandbox is triggered.

9. The disaster recovery method based on digital twin simulation according to claim 8, characterized in that, The prediction models include: hardware failure prediction model, resource congestion prediction model, recovery point target default prediction model, and application degradation and anomaly synthesis detection model. The hardware failure prediction model is used to predict the probability of component failure; the resource congestion prediction model is used to predict the probability of component encountering resource bottlenecks; the recovery point target default prediction model is used to predict the probability of component exceeding the business point target threshold set by the business; and the application degradation and anomaly synthesis detection model is used to predict the probability of component exhibiting behavioral pattern deviation. The step of predicting the risk score of the component based on the state data according to the pre-established prediction model includes: The probabilities output by the hardware failure prediction model, the resource congestion prediction model, the recovery point target default prediction model, and the application degradation and anomaly synthesis detection model are weighted to obtain the risk score.

10. The disaster recovery method based on digital twin simulation according to claim 9, characterized in that, The probabilities output by the hardware failure prediction model, the resource congestion prediction model, the recovery point target default prediction model, and the application degradation and anomaly synthesis detection model are weighted to obtain the risk score, which includes: The probabilities output by the hardware failure prediction model, the resource congestion prediction model, the recovery point target default prediction model, and the application degradation and anomaly synthesis detection model are weighted with the key scores to obtain the risk score. The key score is positively correlated with the number of key business functions in the dependency graph that depend on the component.

11. The disaster recovery method based on digital twin extrapolation according to claim 10, characterized in that, Also includes: By running an extended Berkeley packet filter within the operating system kernel, kernel-level data transmitted between the operating system and external systems can be captured. By configuring the mirror port of the switch to obtain a copy of the network traffic, and sending it to the application performance management probe for analysis, network data can be obtained. Container data is obtained by collecting logs and metrics from accompanying containers deployed for each application container in a containerized environment.

12. The disaster recovery method based on digital twin extrapolation according to claim 11, characterized in that, Also includes: Based on the completeness, timeliness, and consistency of the data obtained from each data source, a quality score is assigned to the data obtained from each data source in each collection cycle; wherein, the data sources include: extended Berkeley package filter, mirror port, and accompanying container; If the quality score of any of the data sources is lower than a preset quality threshold, then the weighting coefficient corresponding to the determination of the risk score is reduced for the prediction model that provides data input from that data source.

13. The disaster recovery method based on digital twin simulation according to claim 11, characterized in that, When the cloud platform has multiple tenants, it also includes: Each acquired data is labeled with a unique tenant tag.

14. A disaster recovery device based on digital twin simulation, characterized in that, include: The simulation and deduction module is used to simulate the execution process of multiple recovery plans through a digital twin sandbox; wherein, the digital twin sandbox stores a digital twin model corresponding to the complete information technology environment of the target component; the target component is the component in the cloud platform for disaster recovery protection in this case; The result quantification module is used to obtain the key parameters of each recovery plan during the simulation process; wherein, the key parameters include: recovery time target and recovery point target; The disaster recovery decision module is used to select the optimal recovery plan from each of the recovery plans based on the key parameters, and to realize the disaster recovery switch of the target component through the optimal recovery plan; Before the simulation of the execution process of multiple recovery plans using a digital twin sandbox, the following steps are also included: Starting from the target component, a bidirectional traversal of upward and downward directions is performed in the dependency graph to determine the influence radius of the target component; wherein, the dependency graph is a graph pre-established based on the dependency relationships between the components in the cloud platform; The simulation of the execution process of multiple recovery plans using a digital twin sandbox includes: Based on the influence radius corresponding to the target component, determine the minimum set of objects required for the deduction; The process of executing the recovery plan on the minimum set of objects is simulated using the digital twin sandbox; The process of establishing the dependency graph includes: By capturing inter-service call chain data using application performance management probes and extended Berkeley package filters, the call relationships between microservices, application instances, and the external interfaces of the application instances are determined. By using static configuration information in the configuration management database and factual scheduling results obtained from the application programming interface of the container platform, the runtime relationship between the application instance and the virtual machine, and between the virtual machine and the physical host machine, is determined. By polling the application programming interface of the virtualization management platform, the usage relationship between the virtual machine and the storage volume, as well as the connection relationship between the virtual machine and the virtual network, can be obtained. By using the link layer discovery protocol information of the network device and the configuration information of the storage array, the physical connection relationship between the physical server, the network device, and the storage device is determined; The database's data volumes and log volumes are bundled according to a predefined storage strategy to establish a consistency relationship; wherein, the data volume and log volume that establish the consistency relationship are considered as an atomic unit; Parse firewall and security group rules to convert access control policies into allowed access edges in the dependency graph; The dependency graph is constructed based on the obtained dependencies; The dependencies include: invocation relationships, running relationships, usage relationships, connection relationships, consistency relationships, and allowed access edges. The dependency graph is implemented based on a graph database, which stores digital twin models corresponding to the complete information technology environment. The digital twin models are kept up-to-date by periodically synchronizing CMDB, virtualization platform APIs, and application topology data. Nodes in the dependency graph represent entities, and edges represent the dependencies. The entities include: physical machines, VMs, applications, and storage volumes. Each node and edge is assigned attributes, including: the node's CPU capacity and memory size, and the edge's network bandwidth. These attributes are updated in near real-time by data from the observation layer. Achieving disaster recovery switching of the target component through the optimal recovery plan includes: The disaster recovery operation sequence of the target component is determined based on the dependency graph; The disaster recovery operation sequence is used to switch the target component to disaster recovery. The disaster recovery operation sequence includes disaster recovery operations for the target component and for nodes in the dependency graph that have dependencies on the target component; the execution order of the disaster recovery operations is determined based on the dependencies in the dependency graph.

15. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the disaster recovery method based on digital twin simulation as described in any one of claims 1 to 13.

16. A disaster recovery device based on digital twin simulation, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the disaster recovery method based on digital twin simulation as described in any one of claims 1 to 13 when executing the computer program.

17. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, which, when executed by a processor, implements the steps of the disaster recovery method based on digital twin simulation as described in any one of claims 1 to 13.

Images