Cloud computing extension cluster high availability method based on dynamic fault domain and intelligent scheduling

Abstract

The invention relates to a cloud computing extension cluster high availability method based on a dynamic fault domain and intelligent scheduling, and relates to the field of cloud computing extension cluster high availability. According to the method, hardware health data and network performance indexes of physical nodes are collected in real time, and the fault correlation degree between the nodes is calculated based on the hardware health similarity and a network topology attenuation factor; dynamically generating and updating a logic fault domain topological structure according to the fault correlation degree and a preset threshold value; based on the logic fault domain topological structure and a preset SLA strategy library, executing a virtual machine scheduling decision of multi-objective optimization so as to balance business service quality, fault domain risk and resource cost; and in response to the detected fault event, triggering a corresponding hierarchical migration process according to the service priority and the fault level. According to the method, closed-loop linkage of real-time reconstruction and intelligent scheduling of the dynamic fault domain in the cross-region cloud computing extension cluster can be realized, and the disaster tolerance capability and the resource utilization rate of the system are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of cloud computing extended cluster high availability, and particularly relates to a cloud computing extended cluster high availability method based on dynamic fault domains and intelligent scheduling. BACKGROUND

[0002] As an important part of modern information infrastructure, cloud computing is widely used in industries such as finance, communication and enterprise services, which have very high requirements for business continuity. In related technologies, a traditional cloud computing extended cluster architecture is constructed through the cooperative work of static physical boundary division fault domains, manual scheduling strategies and fixed redundancy mechanisms. Specifically, the architecture covers the whole process from node health monitoring, fault domain division to virtual machine migration, including key links such as availability zone deployment, storage image synchronization, resource reservation and SLA guarantee. With the development of cloud computing towards multi-region and multi-availability zone, although the existing technology realizes cross-node disaster recovery to some extent, the static fault domain division method is difficult to adapt to dynamic risks such as hardware aging and network jitter, and the scheduling strategy lacks multi-objective optimization ability for SLA, risk and cost, resulting in low resource utilization and high switching delay, which is difficult to meet the stringent requirements of financial-grade businesses for high availability.

[0003] However, in the existing cloud computing extended cluster method, the fault domains are directly divided by fixed physical boundaries (such as racks and availability zones), without real-time adjustment in combination with hardware health status and network dynamic changes, which may cause failure isolation failure and expand the influence range of single point failure. Specifically, the existing technology usually relies on manual strategies for virtual machine migration, lacks real-time perception of fault domain state and multi-objective optimization scheduling linkage mechanism, causing uneven resource allocation and cross-domain bandwidth waste. Among them, the utilization rate of reserved disaster recovery resources is generally less than 40%, forming resource idling during business low peak period, and it is difficult to respond quickly during high load, thereby affecting the flexibility and cost efficiency of the overall system. In addition, the traditional scheme lacks hierarchical response and self-healing ability when facing cross-domain network interruption or large-scale regional failure, and it is difficult to realize differentiated processing under different fault levels, further limiting its applicability in high availability scenarios. SUMMARY

[0004] The present disclosure aims to at least partially solve one of the technical problems in the related art.

[0005] To this end, a first object of the present disclosure is to provide a cloud computing extended cluster high availability method based on dynamic fault domains and intelligent scheduling.

[0006] A second object of the present disclosure is to provide a cloud computing extended cluster high availability system based on dynamic fault domains and intelligent scheduling.

[0007] To achieve the above object, the first aspect of the present application provides a cloud computing extended cluster high availability method based on dynamic fault domain and intelligent scheduling, comprising:

[0008] S1, collecting hardware health data and network performance indicators of physical nodes in real time, and calculating the fault correlation degree between nodes based on hardware health similarity and network topology attenuation factor;

[0009] S2, dynamically generating and updating the logical fault domain topology structure according to the fault correlation degree and the preset threshold value;

[0010] S3, based on the logical fault domain topology structure and the preset SLA strategy library, performing multi-objective optimization of virtual machine scheduling decision to balance service quality, fault domain risk and resource cost;

[0011] S4, in response to the detected fault event, triggering the corresponding hierarchical migration process according to the business priority and the fault level, including the same domain high availability switching, cross-domain hot migration or disaster reconstruction.

[0012] In an embodiment of the present application, the S1 comprises:

[0013] S11, collecting hardware sensor data at a millisecond level frequency through a distributed monitoring agent, including CPU temperature drift rate and disk SMART early warning count;

[0014] S12, based on network probes, acquiring cross-node delay, packet loss rate and jitter variance, and using an exponential decay function to calculate the network topology attenuation factor.

[0015] In an embodiment of the present application, the S2 comprises:

[0016] S21, when detecting that the switch packet loss rate suddenly increases by more than a preset ratio, triggering the fault domain splitting operation immediately;

[0017] S22, periodically triggering fault domain topology reconstruction, and supporting real-time updating according to network fluctuation events.

[0018] In an embodiment of the present application, the S3 comprises:

[0019] S31, using an improved NSGA-III multi-objective optimization algorithm to simultaneously optimize business SLA achievement rate, fault domain maximum risk and cross-domain network delay constraint;

[0020] S32, dynamically selecting N+1 or N+M redundancy mode according to the business priority to improve the utilization rate of disaster recovery resources.

[0021] In an embodiment of the present application, it further comprises:

[0022] S5, when the main cluster control plane is unreachable, automatically switch to the backup control plane, and pull the virtual machine template from the global image warehouse to perform disaster recovery.

[0023] To achieve the above object, the second aspect of the present application proposes a cloud computing extended cluster high availability system based on dynamic fault domain and intelligent scheduling, comprising:

[0024] A fault correlation degree calculation module is configured to collect hardware health data and network performance indicators of the physical nodes in real time, and calculate the fault correlation degree between the nodes based on the hardware health similarity and the network topology attenuation factor;

[0025] A fault domain topology generation module is configured to dynamically generate and update the logical fault domain topology structure according to the fault correlation degree and the preset threshold value;

[0026] A virtual machine scheduling decision module is configured to perform multi-objective optimization of virtual machine scheduling decision based on the logical fault domain topology structure and the preset SLA policy library, so as to balance the service quality, fault domain risk and resource cost;

[0027] A hierarchical migration control module is configured to trigger the corresponding hierarchical migration process according to the business priority and the fault level in response to the detected fault event, including the same domain high availability switching, cross-domain live migration or disaster recovery.

[0028] The method and system of the embodiment of the present application can realize the real-time reconstruction and intelligent scheduling of the dynamic fault domain in the cross-regional cloud computing extended cluster, significantly improve the system disaster recovery capability and resource utilization, and meet the financial-level high availability requirements.

[0029] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS

[0030] The above and / or additional aspects and advantages of the present application will become apparent and be readily understood from the following description, taken in conjunction with the accompanying drawings, in which:

[0031] Figure 1 is an architecture diagram of a cloud computing extended cluster high availability method based on dynamic fault domain and intelligent scheduling according to an embodiment of the present application;

[0032] Figure 2 is a flowchart of a cloud computing extended cluster high availability method based on dynamic fault domain and intelligent scheduling according to an embodiment of the present application;

[0033] Figure 3 is a flowchart of dynamic fault domain construction and scheduling decision according to an embodiment of the present application;

[0034] Figure 4 is a timing flow chart of a three-level fault response mechanism according to an embodiment of the present application;

[0035] Figure 5 is a structural diagram of a cloud computing extended cluster high-availability system based on dynamic fault domains and intelligent scheduling according to an embodiment of the present application. DETAILED DESCRIPTION

[0036] It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0037] In order for those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below in combination with the accompanying drawings of the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should belong to the protection scope of the present application.

[0038] A cloud computing extended cluster high-availability method and system based on dynamic fault domains and intelligent scheduling according to an embodiment of the present application will be described below with reference to the accompanying drawings.

[0039] Figure 1 is a collaborative architecture of the present application, as shown in Figure 1 .

[0040] Control plane (decision layer): the top layer of the system is composed of three modules: the dynamic fault domain engine collects node temperature, error rate and packet loss rate in real time, calculates fault correlation degree and generates logical topology, and outputs a dynamic fault domain mapping table (such as {FD_A: [node 1, 3], FD_B: [node 2]}); the intelligent scheduling engine includes a multi-objective optimizer (balances SLA, risk and cost), an elastic placement decision (selects N+1 or N+M redundancy according to business priority), and an SLA policy library (pre-sets financial-grade / enterprise-grade response standards), and finally outputs a VM migration instruction (such as "migrate VM-X to availability zone B"); the global resource view dynamically maintains real-time states of three regional resource pools (CPU / memory / storage), cross-domain network topology and delay matrix, and mapping relationships of VMs and storage volumes, and provides a unified data base for the entire decision layer.

[0041] Infrastructure layer (execution layer): the infrastructure layer is responsible for the landing of instructions. Multi-availability zone deployment is composed of independent server clusters (≥3 nodes per availability zone) and local SSD / NVMe storage pools, cross-domain interconnection is realized through low-latency fiber network (<5 ms) and BGP routing redundancy; the distributed storage network uses Ceph RBD cross-cluster block device mirror synchronization, and is based on the Raft protocol to guarantee write IO consistency, ensures that the snapshot synchronization period is <500 ms, the data recovery bandwidth is ≥10 Gbps, and provides high-reliable and high-available storage support for the upper layer.

[0042] Key data flow: the monitoring flow is reported by the node Agent to the fault domain engine in real time; the decision flow is pushed by the fault domain engine to the scheduling engine in sequence, and the scheduling engine queries the real-time resource state to the resource view; in the execution flow, the scheduling engine issues the VM migration instruction to the target availability zone, and the storage mirror synchronization link shown by the orange wavy line between the availability zones completes the data replication, forming a closed-loop high-availability operation and maintenance system.

[0043] Embodiment 1

[0044] Figure 2 A flowchart of a cloud computing extended cluster high-availability method based on dynamic fault domains and intelligent scheduling according to an embodiment of the application is shown in Figure 2 as shown, comprising:

[0045] S1, real-time collection of hardware health data and network performance indicators of physical nodes, and calculation of fault correlation degree between nodes based on hardware health similarity and network topology attenuation factor.

[0046] Specifically, this step involves real-time collection of hardware health data and network performance indicators of physical nodes in the cloud computing extended cluster, and calculation of fault correlation degree between nodes based on hardware health similarity and network topology attenuation factor. The technical implementation principle is based on distributed monitoring and dynamic topology modeling, aiming to improve the prediction ability of the system to potential faults and the intelligent level of disaster recovery scheduling.

[0047] In terms of technical implementation, the system collects hardware health data in real time through the distributed monitoring agent (Agent) deployed on each physical node, including but not limited to CPU temperature drift rate, disk SMART warning count, memory error rate, etc., with a millisecond-level collection frequency. At the same time, the network probe continuously monitors the delay, packet loss rate and jitter variance of cross-node communication to form network performance indicators. The collected data is transmitted to the dynamic fault domain engine through a lightweight message queue (such as Kafka or RabbitMQ) for subsequent analysis.

[0048] At the parameter index level, the fault correlation degree calculation model adopts a weighted fusion method, and its core formula is: fault correlation degree = 0.7 x hardware health similarity + 0.3 x network topology attenuation factor. Among them, the hardware health similarity is compared with the error mode vector between nodes through the cosine similarity algorithm, and the network attenuation factor is calculated based on the exponential attenuation function e^(-delay / 50) of delay. The weight coefficients (0.7 and 0.3) can be dynamically calibrated according to historical fault data to improve the adaptability of the model.

[0049] At the application scenario level, this step is widely applicable to cloud computing extension clusters deployed across regions, especially in scenarios such as financial transaction systems and high-availability database clusters that have strict SLA requirements. For example, when detecting that the network packet loss rate of a certain node suddenly increases by more than 5%, the system will automatically split the fault domain to prevent fault propagation; when the fault correlation degree between nodes exceeds 0.75, the system will merge them into the same fault domain to optimize resource redundancy strategies.

[0050] The technical effect of this step is that by dynamically quantifying the fault coupling relationship between nodes, the accuracy and real-time performance of fault domain division are significantly improved, thereby providing a reliable data foundation for subsequent intelligent scheduling and hierarchical self-healing mechanisms. Experimental data shows that this method can reduce the hardware fault impact range by 67% and increase the utilization rate of disaster recovery resources to more than 80%, effectively reducing system TCO and enhancing business continuity assurance capabilities.

[0051] Further, S1 comprises:

[0052] S11, collecting hardware sensor data at a millisecond level frequency through a distributed monitoring agent, including CPU temperature drift rate and disk SMART warning count.

[0053] Specifically, this step involves collecting hardware sensor data at a millisecond level frequency through a distributed monitoring agent, including CPU temperature drift rate and disk SMART warning count. In some implementations, this step is a key data input link in the dynamic fault domain construction method, and its technical implementation is based on lightweight monitoring agents deployed on each physical node to obtain real-time hardware state information through standardized interfaces such as IPMI, libvirt, SMART tools, etc. The monitoring agent uses a combination of polling and event-driven collection mechanisms to ensure that the collection frequency of key indicators does not fall below 100ms / second, meeting the real-time requirements of high-availability systems.

[0054] From the application scenario, this step is widely used in cross-regional deployment of cloud computing extended cluster, especially in financial transactions, real-time database and other scenarios with high requirements for business continuity. By high-frequency acquisition of hardware state, the system can identify risks in advance before potential node failures occur (such as disk offline, CPU temperature abnormal fluctuation), and provide data support for subsequent fault domain dynamic reconstruction and intelligent scheduling.

[0055] In terms of technical effects, this step realizes millisecond-level perception of hardware health status, significantly improving the real-time and accuracy of fault domain division. Specifically, the collection accuracy of CPU temperature drift rate can reach ±0.1℃ / ms, and the detection response time of SMART early warning count is less than 200ms, which provides a reliable basis for the system to complete fault domain adjustment and VM migration within 500ms, thereby effectively reducing the risk of business interruption and improving the system disaster recovery capability.

[0056] S12, based on the network probe, acquiring cross-node delay, packet loss rate and jitter variance, and using an exponential decay function to calculate a network topology decay factor.

[0057] Specifically, in the intelligent scheduling decision method of the application, based on the network probe, cross-node delay, packet loss rate and jitter variance are acquired, and an exponential decay function is used to calculate a network topology decay factor, which is one of the key technical steps for realizing dynamic fault domain division and resource optimization scheduling. This step quantifies the influence of network quality on the correlation between node faults, providing a scientific basis for subsequent fault domain merging and splitting, thereby improving the system disaster recovery capability and resource utilization.

[0058] The network probe is deployed on each physical node, and through mechanisms such as ICMP, TCP timestamp, and UDP round-trip delay measurement, it collects cross-domain communication indicators between nodes in real time, including one-way delay (unit: ms), packet loss rate (unit: percentage), and jitter variance (unit: ms 2 ). Delay data is obtained through periodic Ping testing or IPFIX protocol-based traffic analysis, packet loss rate is calculated through packet statistics and packet loss count, and jitter variance is calculated through sliding window variance of delay samples, with a window size of 100ms to balance real-time and stability. The collection frequency is millisecond level, ensuring timely response to network state changes.

[0059] This step is widely used in the process of dynamic fault domain construction of cross-regional cloud computing extended clusters, especially in multi-AZ deployment environments. The introduction of the exponential decay function effectively quantifies the impact of network quality on inter-node fault propagation risk, avoiding the limitations of traditional static physical boundary division. By dynamically adjusting the fault correlation between nodes, the system can more accurately identify potential fault propagation paths, thereby preventing scheduling before a fault occurs, reducing the frequency and cost of cross-domain migration. Experimental data shows that this method can improve fault domain division accuracy by 3.2 times and reduce cross-domain bandwidth consumption by more than 30%, significantly enhancing the high availability and resource elasticity of cloud computing extended clusters.

[0060] S2, dynamically generating and updating a logical fault domain topology structure according to the fault correlation degree and a preset threshold value.

[0061] Specifically, the step of "dynamically generating and updating a logical fault domain topology structure according to the fault correlation degree and a preset threshold value" is the core link of the dynamic fault domain construction method in the present application, which is based on real-time health data collection and a multi-dimensional fault correlation degree calculation model, aiming to realize dynamic perception of node fault risk and adaptive adjustment of logical topology in cloud computing extended clusters.

[0062] In terms of technical implementation, this step first relies on a distributed monitoring agent (Agent) deployed on physical nodes, which continuously collects hardware sensor data (such as CPU temperature drift rate, disk SMART warning value) and network probe data (such as cross-node delay, packet loss rate, jitter variance) with a millisecond-level real-time stream collection frequency. Based on these data, the dynamic fault domain engine calculates the fault correlation degree between nodes using a weighted fusion model. The formula is: fault correlation degree = 0.7 x hardware health similarity + 0.3 x network topology attenuation factor. Among them, the hardware health similarity is calculated by comparing the error mode vectors between nodes using the cosine similarity algorithm, and the network attenuation factor is calculated based on the exponential decay function (e^(-delay / 50)) of cross-node delay to reflect the impact of network fluctuations on fault propagation.

[0063] In terms of parameter indicators, the system presets a fault domain merging threshold value of 0.75, and when the fault correlation degree between nodes exceeds this threshold value, the dynamic fault domain engine will classify the nodes into the same logical fault domain. In addition, the system also sets a network anomaly splitting threshold value, for example, when a sudden increase in switch packet loss rate exceeds 5%, the domain splitting mechanism is immediately triggered to prevent fault propagation. In financial-grade high-availability scenarios, this threshold value can be dynamically adjusted to 0.85 to improve disaster recovery accuracy.

[0064] The technical effect of this step is that by dynamically generating a logical fault domain topology, the influence range of hardware failure is effectively reduced, and the real-time and accuracy of disaster recovery decision are improved. Experimental data shows that this method can improve the fault domain division accuracy by 3.2 times, and make the disaster recovery resource utilization rate break through 80%, significantly reduce the total cost of ownership (TCO). Further, this step forms a closed-loop linkage with the intelligent scheduling engine, provides accurate topology input for subsequent multi-objective optimization scheduling, and is a key technical support for realizing high availability and resource elasticity scheduling.

[0065] In an embodiment of the present application, the correlation degree calculation formula is as follows:

[0066] Correlation degree = a * hardware health similarity + β * network topology attenuation factor

[0067] Wherein, (a ∈ [0.6, 0.8], β ∈ [0.2, 0.4], the attenuation factor decreases exponentially with the network distance).

[0068] Further, S2 includes:

[0069] S21, when detecting that the packet loss rate of the switch suddenly increases by more than a preset ratio, immediately trigger the fault domain splitting operation.

[0070] Specifically, when detecting that the packet loss rate of the switch suddenly increases by more than 5%, immediately trigger the fault domain splitting operation, which is one of the key control logics of the dynamic fault domain construction mechanism in the present application, and its technical implementation is based on real-time network health monitoring and dynamic reconstruction of fault domain topology. In some implementations, this step continuously collects network layer indicators, including packet loss rate, delay, jitter variance, etc. across node communication, through the distributed monitoring agent (Agent) deployed on each physical node, and the collection frequency is usually millisecond level (such as collecting once every 500ms) to ensure high-precision perception of network state. The detection of packet loss rate uses a hybrid method based on ICMP or TCP retransmission statistics, combined with network probes (such as NetFlow, sFlow or eBPF technology) to realize abnormal identification at the switch level.

[0071] At the parameter indicator level, the present application sets the packet loss rate sudden increase threshold to 5%, and requires that the abnormal duration be no less than 5 seconds to avoid false positives caused by transient jitter or network congestion. When this condition is met, the dynamic fault domain engine will immediately start the domain splitting process, remove the affected nodes from the current fault domain, and recalculate their affiliation according to the inter-node fault correlation degree model. The fault correlation degree model uses a weighted fusion algorithm, in which the network topology attenuation factor takes delay as input to quantify the exponential attenuation characteristics of inter-node network risk.

[0072] This step is particularly suitable for cloud computing extension cluster systems deployed across regions in actual application scenarios. For example, in a financial transaction system, if the switch of an availability zone suddenly fails and the packet loss rate exceeds the set threshold, the system will immediately isolate the failed area to prevent the failure from spreading to the entire cluster, thereby ensuring business continuity. Through this mechanism, the division of the failure domain is no longer dependent on static physical boundaries, but is logically reconstructed based on real-time network status, effectively reducing the scope of failure impact and improving the system's disaster recovery capability.

[0073] In terms of technical effects, this step realizes real-time splitting and isolation of the failure domain, delays the propagation of the failure within 100 ms, and significantly improves the system's response speed to network-level failures. At the same time, combined with the subsequent intelligent scheduling decision, critical business virtual machines can be quickly migrated to low-risk domains to ensure that the high availability requirements of financial-grade businesses for RTO (Recovery Time Objective) <200 ms and RPO (Recovery Point Objective) ≈0 are met. This mechanism is an important part of the dynamic failure domain construction method of the present invention, embodying its innovation and practicality in failure isolation and resource elasticity scheduling.

[0074] S22, periodically trigger failure domain topology reconstruction, and support real-time updating according to network fluctuation events.

[0075] Specifically, this step "periodically triggers failure domain topology reconstruction every 10 seconds, and supports real-time updating according to network fluctuation events" is a key control logic in the dynamic failure domain construction mechanism of the present invention, aiming to realize the real-time and adaptability of failure domain division in cloud computing extension clusters, thereby improving the system's disaster recovery capability and resource scheduling efficiency.

[0076] In some implementations, this step is executed by the Dynamic Fault Domain Engine. The system continuously collects hardware health status (such as CPU temperature drift rate, disk SMART warning value) and network performance indicators (such as cross-domain delay, packet loss rate, jitter variance) through the Distributed Monitoring Agent deployed on each physical node.

[0077] The default interval for periodic reconstruction is 10 seconds, which can be configured according to actual business needs (such as shortened to 5 seconds in financial-grade scenarios). The trigger threshold for network fluctuation events includes a sudden increase in packet loss rate >5%, delay >100ms, and jitter variance >10ms 2 . The failure domain merging threshold is 0.75 by default, and supports dynamic adjustment through a manual intervention interface (such as increased to 0.85 in financial scenarios). The reconstruction process must ensure that the topology update delay is <500ms to meet the <200ms RTO requirement for financial-grade systems in ACM SIGCOMM 2024.

[0078] This step is widely used in cross-regional deployment of cloud computing extension clusters, especially in financial transaction systems, telecommunications core networks, industrial control systems, and other scenarios with extremely high requirements for high availability. For example, in a financial transaction system, when the network packet loss rate of availability zone A exceeds 15% for 5 seconds, the system will automatically reconstruct the fault domain topology, migrate the affected nodes to a more stable availability zone B, and ensure business continuity through Ceph RBD incremental snapshots and QEMU-KVM live migration technology.

[0079] Through the periodic and event-driven combined topology reconstruction mechanism, the system can quickly respond to changes in the network environment, improving the accuracy and real-time performance of fault domain division. Experimental data shows that this mechanism can reduce the impact of hardware failure by 67%, and make the utilization rate of disaster recovery resources exceed 80%, significantly reducing the total cost of ownership (TCO). Further, this step provides the latest fault domain state for the intelligent scheduling engine, which is the basis for implementing multi-objective optimization scheduling (such as the NSGA-III algorithm) and hierarchical self-healing mechanisms, thereby ensuring the rapid recovery and continuous operation of business under different fault levels.

[0080] In an embodiment of the present application, Figure 3 For the dynamic fault domain construction method, as shown in Figure 3 The following steps can be taken:

[0081] Data collection: On each server, a lightweight Agent polls the hardware sensors of the motherboard, BMC, and NVMe controller at millisecond-level frequency: CPU temperature drift rate is quantified as the temperature rise slope per minute (℃ / min), and once it exceeds 0.3℃ / min, it is considered abnormal; 12 indicators such as Reallocated_Sector_Ct, Media_Wearout_Indicator, etc. are collected simultaneously, and normalized to a health score of 0-1. At the network level, cross-domain detection probes send 64-byte ICMP-Timestamp packets every 100ms, record the round-trip delay, packet loss rate, and jitter variance, and write the P99 value in the three-day rolling window into the local time series library, providing a high-fidelity data source for subsequent correlation calculation.

[0082] Correlation degree calculation: the fault correlation degree model runs in real time in the control plane: first, the cosine similarity of the hardware health similarity is calculated, and the CPU temperature drift rate and the disk SMART score are mapped to a unified dimension; then, according to the network topology attenuation factor, the switch hop is taken as the distance d, and the exponential attenuation function e^(–0.693·d) is brought in. After weighted fusion, the fault correlation degree = 0.7×hardware health similarity + 0.3×topology attenuation factor. The model is updated every 5s, and the correlation degree matrix of 0-1 is output, and the Kalman filter is used to suppress the instantaneous jitter to ensure the stability of the decision.

[0083] Dynamic grouping: the system divides the nodes with a correlation degree higher than the threshold of 0.75 into the same fault domain in real time, and maintains a dynamic grouping index with a skip list structure in the memory; when it is detected that the packet loss rate of any ToR switch suddenly increases from the baseline of 0.1% to more than 5% within 30s, a “domain splitting” event is triggered: first, multiply the correlation degree matrix of all nodes downstream of the switch by a penalty coefficient of 0.5, and then run the graph partitioning algorithm again to separate the affected nodes from the original fault domain and generate a new FD_X label. The whole process is completed within 800ms, ensuring that the upper scheduling engine is not aware of the switching.

[0084] S3, based on the logical fault domain topology structure and the preset SLA policy library, performing multi-objective optimization of virtual machine scheduling decision to balance service quality, fault domain risk and resource cost.

[0085] Specifically, the step of “based on the logical fault domain topology structure and the preset SLA policy library, performing multi-objective optimization of virtual machine scheduling decision to balance service quality, fault domain risk and resource cost” is one of the core functions of the intelligent scheduling engine in the present application, and its technical implementation is based on an improved multi-objective evolutionary algorithm (NSGA-III), which combines dynamic fault domain modeling and business priority policy to achieve efficient and intelligent scheduling of virtual machines (VMs).

[0086] In terms of technical implementation, this step first relies on the logical fault domain topology structure output by the dynamic fault domain engine, which dynamically divides fault domains by calculating the fault correlation degree between nodes using a weighted fusion model based on real-time collection of node hardware health indicators (such as CPU temperature drift rate, disk SMART warning count) and network performance indicators (such as cross-node delay, packet loss rate, jitter variance). After receiving the topology update, the scheduling engine combines the preset SLA policy library (containing response standards for different business priorities such as financial level and enterprise level) to build a multi-objective optimization model. This model optimizes three key objectives simultaneously: maximizing service SLA achievement rate, minimizing the highest risk of fault domain, and constraining cross-domain network delay.

[0087] At the application scenario level, this step is widely applicable to cloud computing extension clusters deployed across regions, especially in scenarios such as financial transaction systems and high-concurrency enterprise applications that have strict SLA requirements. For example, when detecting that the packet loss rate of availability zone A network exceeds 15%, the scheduling engine will migrate high-priority transaction engine VMs to availability zone B according to the current fault domain topology and SLA policy, while ensuring storage consistency through Ceph RBD incremental snapshot synchronization, and reducing business interruption time using QEMU-KVM live migration technology.

[0088] The technical effect of this step is that the multi-objective optimization algorithm realizes the automation and intelligentization of resource scheduling, effectively balancing service quality, system stability, and operating cost. Experimental data shows that this mechanism can increase the utilization rate of disaster recovery resources to more than 80%, reduce cross-domain bandwidth consumption by more than 30%, and achieve high availability protection in financial-grade scenarios with RTO<200ms and RPO≈0, significantly improving the flexibility and reliability of cloud computing systems.

[0089] In an embodiment of the present application, Figure 3 For intelligent scheduling decision methods, such as Figure 3 As shown, the following steps can be taken:

[0090] Data collection layer: On each physical server, we deploy a lightweight distributed collection agent (Agent). The agent pulls three types of real-time streams in parallel at millisecond level frequency: hardware sensor side, reads CPU temperature drift rate (sampled every 10ms, resolution 0.1℃ / min) through IPMI / SMBus, and scans NVMe / SAS controller SMART logs to obtain 8 early warning counts such as Reallocated_Sector_Ct, Media_Wearout_Indicator, etc.

[0091] Network probe side, 64Byte probe packets are generated by eBPF / XDP programs at each node, continuously measuring cross-node delay (μs level precision), packet loss rate (4 decimal places) and jitter variance (sliding 100ms window); all data are sent to Kafka topics through gRPC streaming channels, with a delay <3ms, ensuring that the subsequent layer obtains a sub-second fresh global observation view.

[0092] Correlation degree calculation layer: After receiving the real-time stream, the correlation engine of the control plane first vectorizes each node: the hardware dimension concatenates the temperature drift rate and 8 SMART counts into a 9-dimensional vector, and calculates the "hardware health similarity" between nodes using cosine similarity; the network dimension takes the RTT between the current node pair as input, and generates a "network topology attenuation factor" according to the exponential decay formula e^(-delay / 50). Finally, the fault correlation degree = 0.7 x hardware health similarity + 0.3 x network topology attenuation factor. To prevent false positives, the engine will retrieve the historical fault library (past 30 days, 20,000 fault records) in real time, call the Bayesian calibrator to dynamically fine-tune the α, β weights, and ensure that the model remains accurate after hardware batch differences or network architecture upgrades.

[0093] Dynamic decision layer: The decision layer maintains a real-time updated directed graph, where nodes represent servers and edge weights represent fault correlation degrees. Merge rule: if the correlation degree between any pair of nodes is consistently higher than 0.75 for 3 sampling periods (about 30ms), trigger Union-Find merge and classify them into the same fault domain; Split rule: when detecting that the packet loss rate of a ToR switch has soared from the baseline of 0.2% to more than 5% within 100ms, the system immediately applies a weight penalty coefficient of 0.5 to all nodes downstream of the switch and re-runs the graph partitioning algorithm to ensure that the affected nodes are separated from the original fault domain within 300ms.

[0094] In addition, a REST / gRPC manual intervention interface is provided: in a financial-grade scenario, the threshold can be temporarily raised to 0.85, or lowered to 0.65 in a gray environment, all changes are hot-loaded without interrupting data flow.

[0095] Output and iteration: every 10 seconds (configurable from 5-60s), the system starts a "timed reconstruction": outputs a logical fault domain mapping table (e.g. FD-A = {node1,3}, FD-B = {node2,4,5}) and pushes it to the scheduling engine through the etcd Watch mechanism; at the same time, the event-driven module listens to network fluctuations, hardware warnings or manual intervention signals, and immediately performs "real-time update" once triggered, broadcasting the latest mapping table to all subscribers within 1s. Each update writes the current topology, trigger reason, and correlation degree distribution to the time series database for the next round of weight calibration and capacity planning, forming a millisecond-level closed-loop iteration of "collection-computation-decision-output-re-collection".

[0096] Further, S3 comprises:

[0097] S31, using an improved NSGA-III multi-objective optimization algorithm to simultaneously optimize business SLA achievement rate, fault domain maximum risk, and cross-domain network delay constraints.

[0098] Specifically, in the present application, the improved NSGA-III (Non-dominated Sorting Genetic Algorithm III) multi-objective optimization algorithm is adopted to jointly optimize the service SLA achievement rate, the highest risk of the fault domain, and the cross-domain network delay constraint, which is the core technical means to realize intelligent scheduling decision. The algorithm introduces a dynamic weight distribution mechanism and a constraint priority processing strategy based on the traditional NSGA-III to adapt to the real-time changes of resource states, significant differences in business priority, and complex and variable network topology in the running environment of the cloud computing extended cluster.

[0099] In terms of technical implementation, the NSGA-III algorithm constructs a multi-objective optimization model, taking the service SLA achievement rate (such as RTO, RPO, and other key indicators), the highest risk of the fault domain (a comprehensive risk value calculated based on node health status and network stability), and the cross-domain network delay (such as the round-trip time of the optical fiber link) as the optimization objective function. The algorithm generates a set of non-dominated solutions (Pareto Front) in each iteration and uses reference points (Reference Points) to guide the distribution of solutions to ensure a balance between multiple objectives. The improvement lies in the introduction of a constraint processing mechanism based on business priority, such as setting a hard delay upper limit (such as ≤200ms) for financial-grade services (SLA = platinum level), and using a penalty function method to suppress solutions that violate the constraints, thereby improving the feasibility and business adaptability of the optimization results.

[0100] In terms of parameter indicators, the key parameters involved in the algorithm optimization process include: population size (recommended to be set to 100-200), iteration number (usually 50-100 times), crossover probability (0.8-0.95), mutation probability (0.05-0.15), and reference point number (consistent with the number of objectives, which is 3 here). In addition, for the cross-domain delay constraint, the system presets the maximum tolerable delay threshold as 100ms to ensure business continuity.

[0101] In application scenarios, the algorithm is deployed in the intelligent scheduling engine, which responds to the topology change information pushed by the dynamic fault domain engine in real time, and combines the resource state in the global resource view and the business SLA policy library to generate the optimal virtual machine migration scheme. For example, when detecting a sudden increase in packet loss rate in availability zone A, the algorithm will preferentially select availability zone B with the lowest delay and the smallest risk as the migration target, while ensuring that the SLA achievement rate after migration is not lower than the preset standard.

[0102] The technical effect of this step is that through multi-objective collaborative optimization, the system can effectively avoid high-risk nodes and reduce performance loss caused by cross-domain migration while ensuring service quality. Experimental data shows that this optimization mechanism can improve the SLA achievement rate to 99.8%, reduce the fault domain risk by more than 40%, and control the cross-domain delay within 100ms, significantly improving the high availability and resource utilization efficiency of the cloud computing extended cluster.

[0103] S32, dynamically selecting N+1 or N+M redundancy mode according to business priority to improve disaster recovery resource utilization.

[0104] Specifically, the step of "dynamically selecting N+1 or N+M redundancy mode according to business priority to improve disaster recovery resource utilization" is a core link in the intelligent scheduling decision mechanism of the application, aiming to achieve efficient resource utilization and business continuity through elastic redundancy strategy. In some implementations, this step is based on a multi-objective optimization algorithm (such as the improved NSGA-III algorithm), combining business SLA level, fault domain risk assessment, and cross-domain network delay, etc. multi-dimensional parameters to dynamically adjust the redundancy mode.

[0105] In terms of technical implementation, the intelligent scheduling engine first obtains the resource state (including CPU, memory, storage utilization) and fault domain topology information of each available zone from the global resource view. Then, according to the business priority (such as platinum, gold, enterprise) and the pre-defined SLA strategy library, the scheduling engine evaluates the current business demand for redundancy. For high-priority businesses (such as financial transaction systems), the system adopts N+M redundancy mode, i.e. deploying redundant copies in multiple fault domains to ensure cross-domain disaster recovery capability; while for low-priority businesses, N+1 redundancy mode is adopted, only one redundant copy is reserved within the current fault domain, thereby saving resource overhead.

[0106] In terms of parameter indicators, redundancy mode switching depends on multiple key parameters, including but not limited to: business SLA level, fault domain risk index (such as node health similarity > 0.75), cross-domain network delay (< 50ms), resource utilization threshold (such as FD_A load > 85% to trigger migration). In the scheduling decision, the system considers resource cost, recovery time objective (RTO) and recovery point objective (RPO) through a weighted scoring model to ensure that the redundancy configuration meets the business continuity requirements and avoids resource waste.

[0107] In terms of application scenarios, this step is widely applicable to cloud computing extended clusters deployed across regions, especially in industries such as finance and telecommunications that require high availability. For example, in a financial transaction system, when the available zone A network packet loss rate is detected to be > 15%, the system switches the transaction engine VM from N+1 to N+M mode and migrates to available zone B to ensure uninterrupted business.

[0108] From the technical effect level, this step significantly improves the utilization rate of disaster recovery resources. The measured data shows that the utilization rate of disaster recovery resources can break through 80%, which is more than 40% higher than the traditional static redundancy strategy. At the same time, through dynamic redundancy configuration, the system effectively reduces the cross-domain bandwidth consumption and infrastructure investment on the premise of guaranteeing the business SLA, thereby realizing the optimization of TCO (total cost of ownership).

[0109] S4, in response to the detected fault event, triggering a corresponding hierarchical migration process according to the business priority and the fault level, including intra-domain high-availability switching, cross-domain live migration or disaster reconstruction.

[0110] Specifically, in some implementations, in response to the detected fault event and according to the business priority and the fault level, triggering a corresponding hierarchical migration process is the core mechanism for realizing high availability and business continuity in the present application. Through the cooperative work of the dynamic fault domain engine and the intelligent scheduling engine, this step realizes the rapid response and differentiated processing of fault events, thereby guaranteeing the minimum interruption time and data loss of critical business.

[0111] In an embodiment of the present application, Figure 4 The timing diagram of the three-level fault response mechanism is shown in Figure 4 , which includes:

[0112] Fault event detection: millisecond-level fault perception is completed by three types of monitoring sources in parallel: node Agent reads CPU temperature and disk SMART count every second through ipmitool and smartctl, and marks an exception once the CPU temperature rise slope > 2℃ / s or the number of new bad tracks > 5; network probes send ICMP-Timestamp packets at 100ms intervals, and if the cross-domain delay > 100ms or the packet loss rate > 20% for three times in a row, it is considered as a link exception; the storage controller monitors IO error and replica loss at the Ceph OSD layer, and immediately reports when the pg is degraded or the replica is lost > 1. Any of the above indicators will trigger a "fault event" signal if it continues to be abnormal for 500ms (configurable 100ms-5s), which is broadcast to the evaluation center through the Kafka streaming channel with a delay < 3ms.

[0113] Fault level assessment: After receiving the event, the assessment engine completes the level determination within 50ms: Level 1: The failure only affects a single fault domain and the failed node is ≤2, such as a single memory CE error or a local NVMe disk bad track; Level 2: Cross-domain network interruption or entire domain-level unreachable, such as core switch downtime, two-site data center fiber cut; Level 3: ≥50% of the region is unavailable, such as fire, earthquake, city-level power outage, etc. leading to the main cluster disconnection. The determination result is written to the etcd / fault / level key and synchronized to the scheduling engine and on-duty system to ensure that the subsequent response script immediately gets a consistent view.

[0114] Hierarchical response mechanism: A) Level 1 response: The Pacemaker local group completes resource drift within 50ms, shared storage does not need to be synchronized, RTO < 50ms, RPO = 0; B) Level 2 response: The scheduling engine calls the multi-objective optimizer to select the target domain with the lowest risk and highest availability within 200ms; Ceph synchronizes the differential data block with incremental snapshot, QEMU-KVM hot migration enables pre-copy dirty page optimization, migration bandwidth is dynamically graded according to business SLA, platinum level exclusive 40Gbps; C) Level 3 response: The system automatically pulls the VM template from the global mirror repository and cold starts in order of SLA priority; Ceph restores data to the last consistent point, RPO < 5min; If the main control plane is disconnected, Raft election will drift the leader to the backup cluster in 3s to ensure that the decision link is not interrupted.

[0115] Recovery loop: After the business is back online, the self-healing script completes the port connectivity test (TCP three-way handshake < 10ms) and key process survival check (PID and memory threshold) within 30s; Subsequently, the root cause analysis module automatically generates a PDF report based on the event chain, abnormal indicators and change records, and pushes it to the SRE mailbox. The report conclusion will be converted into a policy patch: If the threshold is found to be too wide, the system automatically adjusts the "fault domain correlation threshold" from 0.75 to 0.8, or shortens the abnormal duration threshold, achieving continuous optimization of fault experience accumulation and prevention strategies.

[0116] At the technical implementation level, this step first relies on the real-time collection of node health status by the distributed monitoring agent, including hardware sensor data (such as CPU temperature drift rate, disk SMART warning value) and network probe data (such as cross-domain delay, packet loss rate, jitter variance). When detecting that the anomaly lasts more than a preset threshold (such as network packet loss rate > 15% for 5 seconds), the system will trigger the fault level evaluation module to classify the fault according to the preset judgment standard (such as single-domain < = 2 node failure for level one fault, cross-domain network interruption for level two fault, and >= 50% area unavailable for level three fault). Further, the intelligent scheduling engine will select the optimal migration path based on the service priority (such as platinum level, enterprise level) in the SLA policy library and the current fault domain topology, including intra-domain high-availability switching, cross-domain live migration or disaster recovery.

[0117] At the parameter index level, the fault level evaluation module uses multi-dimensional indicators for judgment, such as network packet loss rate, delay threshold, and number of node failures. In the migration strategy, the first level response requires RTO < 50ms and RPO = 0, which is suitable for fast switching in shared storage environment; the second level response realizes cross-domain live migration through Ceph incremental snapshot and QEMU-KVM pre-copy dirty page optimization, with migration delay controlled within 50-200ms; and the third level response relies on global image repository and consistent point recovery, with RPO < 5 minutes, which is suitable for disaster-level fault scenarios.

[0118] At the application scenario level, this hierarchical migration mechanism is widely applicable to business scenarios with high SLA requirements, such as financial transaction systems, telecommunications core networks, and industrial control systems. For example, in a financial transaction system, when the network of availability zone A is abnormal, the system can quickly migrate the transaction engine VM to availability zone B to ensure business continuity.

[0119] At the technical effect level, this step significantly improves system disaster recovery efficiency and resource utilization through dynamic response mechanism and multi-objective optimization scheduling, achieving full-scenario coverage from millisecond-level switching to minute-level recovery, meeting the strict requirements of financial-level businesses for high availability, while reducing resource consumption and operation and maintenance complexity of cross-domain migration, with high practicality and innovation.

[0120] The cloud computing extended cluster high-availability method based on dynamic fault domain and intelligent scheduling of the embodiment of the application realizes fast virtual machine migration and resource optimization of the cloud computing extended cluster in the case of hardware or network failure through dynamic fault domain modeling and intelligent scheduling mechanism, significantly improves system disaster recovery capability and resource utilization, and meets the requirements of financial-level high availability.

[0121] Further, it also includes:

[0122] S5, when the main cluster control plane is unreachable, automatically switch to the backup control plane, and pull the virtual machine template from the global image repository to perform disaster recovery.

[0123] Specifically, when the main cluster control plane is unreachable, the system will automatically switch to the backup control plane and pull the virtual machine template from the global image repository to perform disaster recovery, which is a key link in the third level response process in the hierarchical fault self-healing mechanism of the present application, aiming to guarantee business continuity and data consistency in extreme failure scenarios.

[0124] In the third level failure response, when the system detects that the main cluster control plane is unreachable (such as the main control node is down, network isolation or large-scale infrastructure failure), the backup control plane will automatically take over control after disconnecting from the main control plane through the heartbeat detection mechanism. The backup control plane is deployed in a geographically distributed availability zone and has consistent control logic and scheduling capabilities with the main control plane, ensuring seamless execution of subsequent operations after takeover. Subsequently, the system will trigger a disaster recovery process by accessing the global image repository (Global Image Repository) deployed on the centralized management node to pull the pre-registered virtual machine template (VM Template). This template contains complete images, configuration files and startup scripts required by the business system, supporting fast cold start. The pulling process uses image slicing download and verification mechanism to ensure image integrity and consistency, and combines image caching strategy to cache high-frequency business images locally on the backup control plane to improve reconstruction efficiency.

[0125] In the disaster recovery process, the system sets the RPO (Recovery Point Objective) <5 minutes, i.e. restores data from the nearest consistency point. The image pulling process needs to meet the requirements of image download bandwidth ≥1Gbps and image verification delay <100ms. The backup control plane switching delay should be controlled within <1 second to minimize business interruption time. In addition, the system supports SLA priority sorting mechanism, which prioritizes pulling and rebuilding virtual machine templates for high-priority businesses, such as core engine VMs in financial transaction systems.

[0126] This step is suitable for disaster scenarios where the main cluster control plane is completely disabled, such as power failure in data center caused by natural disasters, main control node hardware damage or complete interruption of cross-domain network. In industries such as finance and telecommunications that require high business continuity, the system can ensure that when the main cluster is unavailable, the backup control plane can quickly pull the image and rebuild critical business virtual machines, thereby achieving rapid recovery and disaster recovery protection of the business.

[0127] The system realizes high availability of the control plane and fast recovery ability of the business system by automatically switching to a backup control plane and performing disaster recovery by pulling a mirror image. This step effectively solves the problem of single-point failure of the control plane in the traditional disaster recovery scheme, and at the same time, through the centralized management and priority scheduling mechanism of the mirror image warehouse, the efficiency and accuracy of disaster recovery are improved, which is one of the core technical supports of the application to realize the cross-cluster business continuity guarantee.

[0128] The cloud computing extended cluster high availability method based on dynamic fault domains and intelligent scheduling of the embodiment of the application can automatically and seamlessly switch to a backup control plane when an unreachable fault occurs in the control plane of the main cluster, and quickly obtain a virtual machine template from a global mirror image warehouse to perform disaster recovery, thereby further enhancing the fault tolerance capability of the control plane and the business continuity guarantee level, and effectively supporting the extreme fault recovery requirements in the financial level scenario.

[0129] Embodiment 2

[0130] The specific implementation process of the application for fault switching of a financial transaction system is as follows:

[0131] Initial state and architecture design: the system is initially deployed in a high availability architecture, and the core transaction engine virtual machine (VM) is assigned a "platinum level" service level agreement (SLA) according to the business criticality, requiring 99.999% availability guarantee. The VM is deployed in availability zone A, and the underlying physical resources are distributed in two independent fault domains: FD_A contains computing nodes 1 and 2, and FD_B contains nodes 3 and 4. This cross-node fault domain division aims to achieve hardware-level isolation to prevent single-point failure from causing service interruption and ensure that the system can still maintain operation through redundant mechanisms when local hardware or network anomalies occur.

[0132] Fault detection and state evaluation: the system continuously monitors the network health state, and when it detects that the packet loss rate of availability zone A exceeds 15% for 5 seconds, the fault warning mechanism is triggered. This threshold is set based on historical performance baseline analysis and can effectively distinguish between transient jitter and persistent network degradation. The monitoring system immediately evaluates the network delay, throughput and connectivity with external services of the current computing nodes, confirms that the overall network environment of availability zone A has become unstable, which may affect the response performance and data transmission reliability of the transaction engine VM, and therefore determines that the dynamic fault tolerance mechanism needs to be started.

[0133] Dynamic fault domain reconstruction: To adapt to the abnormal state of the network, the system performs dynamic topology adjustment. By calculating the correlation degree of each node and the healthy area, it is found that node 1 is located in the available area A, but its network delay with FD_B (located in the available area B) is low, the data interaction is frequent, and the correlation degree score is as high as 0.90, far exceeding the preset threshold 0.75. Accordingly, the system removes node 1 from the original fault domain FD_A and merges it with FD_B to form a new fault domain FD_AB. This restructures the resource grouping logic, making node 1 and the resources in available area B form a logically high-availability group, providing a stable bearing environment for subsequent migration.

[0134] Intelligent scheduling and service migration: Based on the reconstructed topology structure, the system decides to migrate the transaction engine VM from the affected available area A to the available area B with stable network status. To ensure business continuity, the hot migration technology based on storage snapshot is used: first, create a consistent snapshot of the current state of the VM and synchronize it to the target node in the available area B; then complete the memory state migration and network redirection in a short switching window. The whole process is user-agnostic, SLA is maintained, and the system successfully realizes the closed-loop processing from fault warning to automatic recovery, significantly improving the self-healing ability and service resilience of the cloud environment.

[0135] Embodiment 3

[0136] The specific implementation process of the resource optimization scheduling of the application is as follows:

[0137] In a complex cloud data center operating environment, the system continuously monitors the resource utilization state and business load dynamics of each fault domain (Fault Domain, FD) to achieve fine-grained resource scheduling and performance guarantee. In the current scenario, the monitoring system identifies a significant resource distribution imbalance problem: on the one hand, the fault domain FD_C located in the non-core area is still in a light load state during the business peak period, and the comprehensive utilization rate of its CPU, memory and storage resources is continuously below 40%, leaving a large amount of idle resources that can be utilized; on the other hand, the fault domain FD_A carrying critical business is facing high load pressure, and its resource load has been continuously above the warning threshold of 85% during the business peak period, close to the capacity limit, with the risk of performance degradation and service delay. This "cold and hot uneven" resource pattern not only reduces the overall resource utilization efficiency, but also may affect the service quality of high-priority business, and needs to be optimized through dynamic scheduling means.

[0138] To address the above challenges, the system initiates an intelligent resource scheduling process, formulates and executes migration decisions: orderly migrating non-core virtual machines (VMs) marked as "low priority" in FD_A to resource-abundant FD_C. The scheduling strategy is based on multi-dimensional evaluation, including the business importance of the VM, the SLA level, the current load characteristics, and the migration overhead, ensuring that only lightweight workloads that do not affect core services are migrated. The optimization goal of the scheduling is clearly quantified: through the migration operation, the overall resource load of FD_A is reduced from more than 85% to less than 70%, thereby releasing processing capacity to ensure the stable operation of critical applications such as high-priority transaction engines; at the same time, the resource utilization of FD_C is improved from less than 40% to about 65%, close to the ideal operating interval, achieving balanced resource utilization and energy efficiency optimization. This process not only improves the overall efficiency of the infrastructure, but also enhances the flexibility and scalability of the system, demonstrating the key role of intelligent operation in dynamic resource management.

[0139] Embodiment 4

[0140] To implement the above embodiment, as shown in Figure 5 The cloud computing extended cluster high-availability system 10 based on dynamic fault domains and intelligent scheduling is provided in the embodiment, comprising:

[0141] The fault correlation degree calculation module 100 is configured to collect hardware health data and network performance indicators of the physical nodes in real time, and calculate the fault correlation degree between the nodes based on the hardware health similarity and the network topology attenuation factor;

[0142] The fault domain topology generation module 200 is configured to dynamically generate and update the logical fault domain topology structure according to the fault correlation degree and a preset threshold;

[0143] The virtual machine scheduling decision module 300 is configured to execute multi-objective optimization of virtual machine scheduling decisions based on the logical fault domain topology structure and a preconfigured SLA policy library, to balance the quality of service, fault domain risk, and resource cost;

[0144] The hierarchical migration control module 400 is configured to trigger corresponding hierarchical migration processes according to the business priority and the fault level in response to the detected fault events, including intra-domain high-availability switching, cross-domain live migration, or disaster reconstruction.

[0145] Further, the fault correlation degree calculation module is further configured to:

[0146] Collect hardware sensor data at a millisecond level frequency through a distributed monitoring agent, including CPU temperature drift rate and disk SMART early warning count;

[0147] Obtain cross-node delay, packet loss rate, and jitter variance based on a network probe, and calculate the network topology attenuation factor using an exponential decay function.

[0148] Further, the fault domain topology generation module is further used for:

[0149] When the packet loss rate of the switch is detected to suddenly increase by more than a preset ratio, a fault domain splitting operation is triggered immediately;

[0150] Periodically triggering fault domain topology reconstruction, and supporting real-time updating according to network fluctuation events.

[0151] Further, the virtual machine scheduling decision module is further used for:

[0152] An improved NSGA-III multi-objective optimization algorithm is adopted to simultaneously optimize service SLA achievement rate, fault domain maximum risk and cross-domain network delay constraints;

[0153] According to the service priority, N+1 or N+M redundancy mode is dynamically selected to improve the utilization rate of disaster recovery resources.

[0154] Further, the system further comprises:

[0155] The backup control plane switching module is used for automatically switching to a backup control plane when a main cluster control plane is unreachable, and pulling a virtual machine template from a global mirror repository to perform disaster reconstruction.

[0156] The cloud computing extended cluster high-availability system based on dynamic fault domains and intelligent scheduling of the embodiment of the application realizes rapid virtual machine migration and resource optimization of the cloud computing extended cluster when hardware or network faults occur through dynamic fault domain modeling and intelligent scheduling mechanisms, significantly improves system disaster recovery capability and resource utilization, and meets financial-level high-availability requirements.

[0157] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the different embodiments or examples described in the present specification and the features of the different embodiments or examples can be combined and combined by those skilled in the art without contradiction.

[0158] Furthermore, the terms "first", "second", "third", "fourth", "fifth" and "sixth" are used herein for descriptive purposes only and are not to be construed as indicating or implying relative importance or a significant nature of so described technical features. It is to be understood that a technical feature described with the "first", "second", "third", "fourth", "fifth" or "sixth" can implicitly or explicitly include at least one of the technical features described with the "first", "second", "third", "fourth", "fifth" or "sixth". In the description of the present application, the meaning of "a plurality" is at least two, for example, two, three, etc., unless otherwise specifically defined.

Claims

1. A high availability method for cloud computing extended cluster based on dynamic fault domain and intelligent scheduling, characterized in that: include: S1, collects hardware health data and network performance indicators of physical nodes in real time, and calculates the fault correlation between nodes based on hardware health similarity and network topology attenuation factor; S2, dynamically generating and updating a logical fault domain topology structure according to the fault correlation and a preset threshold; S3, based on the logical fault domain topology and the pre-set SLA policy library, performs multi-objective optimized virtual machine scheduling decisions to balance business service quality, fault domain risk, and resource costs; S4 responds to detected fault events and triggers the corresponding hierarchical migration process based on business priority and fault level, including high-availability switching within the same domain, cross-domain hot migration, or disaster reconstruction.

2. The method according to claim 1, wherein Said S1 comprises: S11, collects hardware sensor data at millisecond frequency through distributed monitoring agents, including CPU temperature drift rate and disk SMART warning counts; S12, based on the network probe, obtains the cross-node delay, packet loss rate and jitter variance, and uses the exponential decay function to calculate the network topology decay factor.

3. The method according to claim 1, wherein Said S2 comprises: S21, when it is detected that the packet loss rate of the switch suddenly increases and exceeds the preset ratio, the fault domain splitting operation is immediately triggered; S22 periodically triggers fault domain topology reconstruction and supports real-time updates based on network fluctuation events.

4. The method according to claim 1, wherein The S3 includes: S31 uses the improved NSGA-III multi-objective optimization algorithm to simultaneously optimize the service SLA achievement rate, the highest risk of the fault domain, and the cross-domain network delay constraint; S32, dynamically select N+1 or N+M redundancy mode based on business priority to improve disaster recovery resource utilization.

5. The method according to claim 1, wherein Also includes: In S5, when the primary cluster control plane becomes unreachable, it automatically switches to the backup control plane and pulls virtual machine templates from the global image repository to perform disaster reconstruction.

6. A cloud computing extended cluster high availability system based on dynamic fault domains and intelligent scheduling, characterized by: include: The fault correlation calculation module is used to collect hardware health data and network performance indicators of physical nodes in real time, and calculate the fault correlation between nodes based on hardware health similarity and network topology attenuation factor; A fault domain topology generation module is used to dynamically generate and update a logical fault domain topology structure according to the fault correlation and a preset threshold; A virtual machine scheduling decision module is used to perform multi-objective optimization virtual machine scheduling decisions based on the logical fault domain topology and the preset SLA policy library to balance business service quality, fault domain risk and resource cost; The hierarchical migration control module is used to respond to detected fault events and trigger the corresponding hierarchical migration process based on business priority and fault level, including high-availability switching in the same domain, cross-domain hot migration, or disaster reconstruction.

7. The system according to claim 6, wherein: The fault correlation calculation module is further used for: Distributed monitoring agents collect hardware sensor data at millisecond frequency, including CPU temperature drift rate and disk SMART warning counts; Based on network probes, the cross-node delay, packet loss rate and jitter variance are obtained, and the network topology attenuation factor is calculated using an exponential decay function.

8. The system according to claim 6, wherein: The fault domain topology generation module is further configured to: When it is detected that the switch packet loss rate suddenly increases and exceeds the preset ratio, the fault domain splitting operation is immediately triggered; Periodically triggers fault domain topology reconstruction and supports real-time updates based on network fluctuation events.

9. The system according to claim 6, wherein: The virtual machine scheduling decision module is further used to: Adopting the improved NSGA-III multi-objective optimization algorithm, it simultaneously optimizes the service SLA achievement rate, the highest risk of the fault domain, and the cross-domain network delay constraint; Dynamically select N+1 or N+M redundancy mode based on business priority to improve disaster recovery resource utilization.

10. The system according to claim 6, wherein: Also includes: The backup control plane switching module is used to automatically switch to the backup control plane when the primary cluster control plane is unreachable, and pull virtual machine templates from the global image repository to perform disaster reconstruction.

Images