Method for evaluating health degree of cloud resource pool and related equipment

Abstract

The embodiment of the application discloses a kind of health degree evaluation methods of cloud resource pool and related equipment, to solve the problem that in the prior art, only focus on the performance index of single resource or equipment is monitored and evaluated, lack of comprehensive analysis on the overall topology structure of cloud resource pool and the dependence relationship between resource nodes, leading to the health degree evaluation result of cloud resource pool is one-sided, inaccurate, difficult to truly reflect the overall operation state of resource pool.The method comprises the following steps: obtaining the node health degree of resource node in cloud resource pool and the dependence relationship data between different resource nodes;Based on the dependence relationship data, a network topology model of the cloud resource pool is constructed;Determine the node importance index of the resource node based on the topological attribute characteristics of the network topology model;Based on the node importance index of the resource node and the node health degree of the resource node, weighted aggregation is carried out to obtain the health degree of the cloud resource pool.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and related equipment for assessing the health of a cloud resource pool. Background Technology

[0002] With the widespread adoption of cloud computing technology, cloud resource pools, as the infrastructure supporting business computing, storage, and network capabilities, are directly affected by their operational status in terms of business continuity and service quality. Therefore, assessing and providing early warnings regarding the health of cloud resource pools is a crucial task in resource operation and capacity planning.

[0003] Existing methods for assessing the health of cloud resource pools primarily rely on monitoring and evaluating the performance metrics of individual resources or devices, such as CPU utilization, memory usage, and network bandwidth, to determine the overall operational status of the cloud resource pool.

[0004] However, since the above methods only focus on monitoring and evaluating the performance of individual resources or devices during the cloud resource pool performance evaluation process, and lack a comprehensive understanding of the entire cloud resource pool and the interrelationships between resources, the health assessment results of the cloud resource pool obtained are easily one-sided and inaccurate.

[0005] Therefore, how to accurately assess the health of cloud resource pools is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] This application provides a method for assessing the health of a cloud resource pool, which addresses the problem in the prior art that focuses only on monitoring and evaluating the performance indicators of a single resource or device, lacking a comprehensive analysis of the overall topology of the cloud resource pool and the dependencies between resource nodes. This results in a one-sided and inaccurate assessment of the cloud resource pool's health, making it difficult to truly reflect the overall operating status of the resource pool.

[0007] This application also provides a cloud resource pool health assessment device, an electronic device, a computer-readable storage medium, and a computer program product.

[0008] The embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a method for assessing the health of a cloud resource pool, including: Obtain the node health status of resource nodes in the cloud resource pool and the dependency relationship data between different resource nodes; Based on dependency data, construct a network topology model for the cloud resource pool; The importance index of resource nodes is determined based on the topological attribute characteristics of the network topology model. The health score of the cloud resource pool is obtained by weighted aggregation of the node importance index and the node health score of the resource nodes.

[0009] Optionally, obtain the node health status of resource nodes in the cloud resource pool, including: Obtain the running status data of resource nodes, which includes at least one of CPU utilization, memory usage, disk I / O rate, and network throughput; The health of resource nodes is calculated based on the operational status data and the dynamic baseline threshold of the operational status data. The dynamic baseline threshold is adaptively adjusted based on the periodic fluctuation characteristics of the historical operational status data of resource nodes.

[0010] Optionally, based on dependency data, a network topology model for the cloud resource pool is constructed, including: Map resource nodes to topology nodes in the network topology model; Dependency relationships between different resource nodes are determined based on dependency data. Dependency relationships include at least one of the following: call relationships, data flow relationships, resource consumption relationships, or configuration dependencies. Map the dependencies between different resource nodes as directed edges connecting topology nodes; Based on the topological nodes and directed edges, the network topology model of the cloud resource pool is obtained.

[0011] Optionally, the node importance index of resource nodes can be determined based on the topological attribute characteristics of the network topology model, including: Simulated faults are injected sequentially into each topology node in the network topology model; For each injected simulated fault, the topology node where the fault occurred is taken as the source node. The set of reachable nodes of the source node in the network topology model is determined, and the propagation path of the simulated fault is recorded. Based on the node quantization parameters of each topological node in the reachable node set and the edge quantization parameters of each directed edge in the propagation path, the propagation path and impact range of the simulated fault are determined. The importance index of each resource node is determined based on the propagation path and the scope of influence; The node quantization parameters include at least one or more of the processing capability parameters and reliability parameters, and the edge quantization parameters include at least one or more of the bandwidth parameters, latency parameters, and packet loss parameters.

[0012] Optionally, simulated faults are injected sequentially into each topology node in the network topology model, including: Generate a queue of nodes to be injected based on the topology nodes in the network topology model; Select topology nodes sequentially from the queue of nodes to be injected as the current injection targets, and perform the following operations until all topology nodes in the queue of nodes to be injected have been selected: Select a fault injection strategy that matches the current injection object from the preset fault mode library. The fault injection strategy shall include at least the injection scope, injection timing, injection location, type of simulated fault injected, and duration of simulated fault. Simulated fault injection is performed on the current injection object based on the fault injection strategy. Optionally, the node importance index of resource nodes can be determined based on the topological attribute characteristics of the network topology model, including: The nominal flow of resource nodes is determined based on the topological attribute characteristics of the network topology model. The nominal flow is the maximum flow of the resource node under normal working conditions. Determine the actual traffic flow when a resource node fails; The network health at the time of resource node failure is determined based on the actual traffic and the nominal traffic of the resource node. The importance of resource nodes is determined based on network health.

[0013] Secondly, embodiments of this application provide a health assessment device for a cloud resource pool, comprising an acquisition module, a construction module, a determination module, and an assessment module, wherein: The acquisition module is used to acquire the node health status of resource nodes in the cloud resource pool and the dependency relationship data between different resource nodes; The building module is used to construct the network topology model of the cloud resource pool based on dependency data; The determination module is used to determine the node importance index of resource nodes based on the topological attribute characteristics of the network topology model; The evaluation module is used to perform weighted aggregation based on the node importance indicators and node health of resource nodes to obtain the health of the cloud resource pool.

[0014] Thirdly, embodiments of this application provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the cloud resource pool health assessment method as described above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the cloud resource pool health assessment method as described above.

[0016] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the cloud resource pool health assessment method as described above.

[0017] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By employing the method provided in this application embodiment, dependency relationship data between different resource nodes in the cloud resource pool is obtained, and a network topology model is constructed. Then, the importance of each resource node in the overall architecture can be quantified based on topology attribute features. In this way, during the health assessment of the cloud resource pool, the node health of resource nodes can be correlated with their node importance indicators, thereby comprehensively reflecting the interdependence between resource nodes and the impact of important nodes on the health assessment of the cloud resource pool. This effectively overcomes the problem of assessment bias and distortion caused by relying solely on isolated devices / indicators in the prior art, and achieves accurate assessment of the health of the cloud resource pool. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A schematic diagram illustrating the implementation process of a cloud resource pool health assessment method provided in this application embodiment; Figure 2 This application provides a flowchart illustrating a method for determining the node importance index of resource nodes. Figure 3 This application provides a schematic diagram of the specific structure of a cloud resource pool health assessment device. Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0021] To address the problem that existing technologies focus solely on monitoring and evaluating the performance indicators of individual resources or devices, lacking a comprehensive analysis of the overall topology of the cloud resource pool and the dependencies between resource nodes, resulting in biased and inaccurate cloud resource pool health assessments that fail to accurately reflect the overall operational status of the resource pool, this application provides a cloud resource pool health assessment method.

[0022] The execution subject of this method can be various types of computing devices, or it can be an application or app installed on the computing device. The computing device can be a user terminal such as a mobile phone, tablet computer, or smart wearable device, or it can be a server.

[0023] For ease of description, this application uses a server as the execution subject of the method in its embodiments to illustrate the method. Those skilled in the art will understand that this embodiment uses a server as an example to describe the method, which is merely an illustrative example and does not limit the scope of protection of the corresponding claims.

[0024] Specifically, the implementation flow of the method provided in this application embodiment is as follows: Figure 1 As shown, it includes the following steps: Step 102: Obtain the node health status of resource nodes in the cloud resource pool and the dependency relationship data between different resource nodes.

[0025] In this embodiment of the application, a cloud resource pool refers to a collection of resources consisting of various types of resources such as computing, storage, network, and middleware, which provides unified service capabilities to the outside world.

[0026] Resource nodes can be understood as all physical or virtual entities that make up a cloud resource pool, including but not limited to computing servers, storage devices, network switches / routers, virtual machines (VMs), containers, and critical software service instances.

[0027] Node health is a quantitative indicator used to characterize the current operating status of a resource node.

[0028] In some embodiments, when obtaining the node health of resource nodes in a cloud resource pool, the running status data of the resource nodes can be obtained, including at least one of CPU utilization, memory usage, disk I / O rate, and network throughput; then, the node health of the resource nodes is calculated based on the running status data and a dynamic baseline threshold of the running status data.

[0029] The dynamic baseline threshold is a standard calculated based on the historical operational status data and behavioral patterns of resource nodes, used to determine whether the current behavior of a resource node is normal. This dynamic baseline threshold can be adaptively adjusted based on the periodic fluctuation characteristics of the historical operational status data of resource nodes.

[0030] Specifically, firstly, by using a monitoring agent deployed in the cloud environment, calling the API interface provided by the cloud platform, or directly accessing the device management interface, the performance indicators, configuration status, and log information of resource nodes, such as system logs, application logs, and audit logs, can be continuously and in real time collected.

[0031] Performance metrics reflect the real-time operational status of resource nodes. Optionally, configuration status may include information such as the hardware specifications, software version, and security policy compliance of the resource nodes.

[0032] In some embodiments, in order to improve the quality and consistency of the collected data and reduce the impact of noise and redundancy on subsequent modeling and health assessment, after obtaining information such as the performance indicators, configuration status, and log information of resource nodes, these data can be preprocessed. This can effectively eliminate noise and redundancy in the data, ensure the quality and consistency of the input data, and enable the preprocessed data to more clearly and realistically reflect the actual operating status of the cloud resource pool, providing a high-quality data foundation for subsequent health calculations.

[0033] Optionally, preprocessing may include, but is not limited to: cleaning outliers and duplicate records, completing or interpolating missing fields, aligning timestamps and unifying sampling granularity for data from different sources, converting and structuring data from different formats, and normalizing and unifying the definitions of multi-source indicators. After obtaining preprocessed performance metrics, configuration status, and log information, the configuration status and log information can be structured and feature extracted. For example, text logs can be parsed into structured records containing fields such as timestamps, event types, error codes, call chain identifiers, and time consumption. The current node's operating mode or change events, such as scaling up or down, version upgrades, and parameter adjustments, can be identified in conjunction with the configuration status. Then, the operating status data of the resource node can be determined by combining the performance metrics.

[0034] Finally, the node health of resource nodes can be calculated based on the operational status data and its dynamic baseline threshold. Specifically, statistical methods, machine learning algorithms, or time series analysis can be used to determine the degree of deviation between the operational status data and the dynamic baseline threshold; then, the node health of resource nodes can be calculated based on this deviation.

[0035] Alternatively, in some embodiments, the health scores of multiple operational status items can be determined based on operational status data; then, the health scores of each indicator are weighted and summed based on the indicator weights corresponding to each health score to obtain the node health of each resource node; wherein, the indicator health score is determined by the degree of deviation of the operational status data from the dynamic baseline threshold. The greater the deviation, the lower the indicator health score.

[0036] In some embodiments, each metric can be normalized to obtain a normalized value, and weights can be assigned to each metric to obtain the node health score.

[0037] in, Represents resource nodes i Node health; Indicators j The weights; This represents the number of metrics used to calculate the health of resource nodes; Represents resource nodes i Indicators j The normalized value is a value between 0 and 1. Specifically, it is the normalized value of each indicator multiplied by its weight, and then these products are added together to get the node health score.

[0038] For positive metrics (such as CPU idle rate), the closer the normalized value is to 1, the better the condition; for negative metrics (such as error rate), the closer the normalized value is to 0, the better the condition. For example, taking CPU as an example, its calculation method is as follows:

[0039] In some embodiments, the dynamic baseline threshold can be determined as follows: A time series of the same operational status item for the same resource node is constructed based on historical operational status data; in each update cycle, the actual value of the operational status item at the current time point is weighted and fused with the dynamic baseline threshold of the previous update cycle according to a preset smoothing weight coefficient to obtain the dynamic baseline threshold for the current update cycle. The calculation expression for the dynamic baseline threshold is as follows:

[0040] in, Indicates the current time point t The dynamic baseline threshold; Indicates the current time point t The dynamic baseline threshold of the previous time point. This represents the smoothing weighting coefficient. Indicates the current time pointt The actual value of the running status item.

[0041] The smoothing weight coefficient can be adaptively set according to the fluctuation range of the time series, so that when the fluctuation range is large, the weight of the current actual value is increased, and when the fluctuation range is small, the weight of the previous dynamic baseline threshold is increased. For example, in some embodiments, if the change of the time series is relatively stable, a smaller smoothing weight coefficient (such as 0.1 or 0.2) can be selected to make the baseline more stable; or, if the change of the time series is relatively drastic, a larger smoothing weight coefficient (such as 0.5 or higher) can be selected so that the baseline can adapt to new changes more quickly.

[0042] The following describes in detail, with examples, the method for determining the dynamic baseline threshold provided in the embodiments of this application.

[0043] For example, suppose we use the CPU utilization of resource nodes as a certain running status item, and form a time series with a fixed update cycle (e.g., 1 minute). Let's assume at time point... t The actual observed CPU utilization is (Unit: %), dynamic baseline threshold is (Unit: %), smoothing weighting coefficient is a The value range is 0 < a <1, used to adjust the sensitivity to the latest observations. Among them, a The larger the value, the more sensitive the dynamic baseline is to short-term fluctuations; a The smaller the value, the smoother and more stable the dynamic baseline.

[0044] For example, the first update cycle ( t= 1) The dynamic baseline threshold is set to the first observation value Y1 or the historical mean. For example, assume that the dynamic baseline threshold for the first update period is the first observation value Y1, i.e., S1=Y1.

[0045] Secondly, assuming that monitoring reveals the following CPU utilization observations for a resource node over six consecutive update cycles (1 minute per cycle): Y1=50%, Y2=60%, Y3=55%, Y4=70%, Y5=65%, Y6=58%, and the smoothing weight coefficient is a=0.3, then the dynamic baseline threshold can be calculated recursively based on the update cycle: S1=Y1=50.00% S² = 0.3 × 60 + 0.7 × 50 = 53.00% S3 = 0.3 × 55 + 0.7 × 53.00 = 53.60% S4 = 0.3 × 70 + 0.7 × 53.60 = 58.52% S5 = 0.3 × 65 + 0.7 × 58.52 = 60.464% S6=0.3×58+0.7×60.464=59.7248% Therefore, the dynamic baseline threshold It will be updated according to the current actual value in each update cycle. Compared with the baseline of the previous period Weighted fusion is performed to maintain smooth following even when there are fluctuations (such as a sudden increase from 55% to 70%), thus achieving an adaptive baseline for the runtime status items of resource nodes.

[0046] After collecting and preprocessing the node health status of each resource node in the cloud resource pool, in order to further characterize the relationship structure between resource nodes and provide basic data support for subsequent network topology model construction, key node identification and fault propagation analysis, this embodiment of the application also needs to further obtain the dependency relationship data of resource nodes in the cloud resource pool.

[0047] Among them, dependency data is used to characterize the degree of dependency between different resource nodes in dimensions such as business calls, data transmission, resource competition and configuration references, thereby reflecting the actual operation link and coupling relationship of the cloud resource pool.

[0048] In this embodiment of the application, the dependency data includes at least the data used to determine the calling relationship, data flow relationship, resource occupation relationship or configuration dependency relationship between each resource node.

[0049] In some embodiments, when obtaining dependency data of resource nodes in a cloud resource pool, the resource nodes in the cloud resource pool can first be uniformly identified and asset-modeled. Each resource node is assigned a node identifier (e.g., host ID, container ID, instance ID, or service name / interface name), and raw data related to dependencies is collected, including but not limited to: request chain data reported by the call chain tracing component or service mesh (e.g., trace / span, caller / callee identifier, interface name, number of calls, latency and error codes, etc.), connection and traffic data obtained by the network observation component (e.g., 5-tuple, port, traffic size, direction, session duration, etc.), access and transmission records exported by the storage / message / database middleware (e.g., read / write operation type, topic / queue, table / database name, throughput and latency, etc.), and configuration association information output by the resource orchestration and configuration management system (e.g., environment variable references, service discovery configurations, routing / load balancing rules, dependency lists, configuration item reference relationships, etc.).

[0050] Based on the original data, structured parsing and time alignment are performed, and dependency edges are determined through rule matching and statistical aggregation. For example, if resource node A continuously calls the span record of resource node B within a preset time window and the number of calls exceeds a threshold, it can be determined that there is a call relationship between A and B.

[0051] Alternatively, when network traffic data indicates that there is stable unidirectional data transmission from resource node A to resource node B and the traffic volume meets the conditions, it can be determined that there is a data flow relationship between A and B.

[0052] Alternatively, when it is detected that resource node A's occupation of shared resources (such as shared storage volumes, database connection pools, GPU / bandwidth quotas, etc.) and resource node B's significant competition (such as quota exhaustion, queue waiting, IO jitter, etc.) occur within the same time window, it is determined that there is a resource occupation relationship between A and B; Alternatively, if configuration management data indicates that a configuration item of resource node A references the service address, certificate key, Topic / Queue, or dependency manifest entry of resource node B, it is determined that there is a configuration dependency relationship between A and B.

[0053] Finally, the above dependencies are output in a structured form as dependency data, such as a record set consisting of fields such as source resource node identifier, target resource node identifier, dependency type, dependency strength (call frequency / traffic / contention intensity / reference count), timestamp, and confidence level, thereby providing reliable input for subsequent network topology model construction and fault propagation analysis.

[0054] It should be noted that the methods listed above for obtaining the node health status of resource nodes in the cloud resource pool and the dependency relationship data between different resource nodes are merely illustrative examples of the embodiments of this application and do not impose any limitations on the embodiments of this application.

[0055] Step 104: Based on the dependency relationship data, construct the network topology model of the cloud resource pool.

[0056] In this embodiment, abstraction techniques can be used to simplify the actual physical devices in the cloud resource pool and the complex relationships between them into nodes and connections in the model, forming a preliminary network topology. Then, through comparative verification and actual testing, the model parameters of the network topology model are continuously adjusted and optimized to ensure that the network topology model of the cloud resource pool can truly reflect the actual operating status and characteristics of the cloud resource pool. Finally, the network topology model of the cloud resource pool can be formally described and documented for subsequent analysis, management and maintenance.

[0057] In practice, each resource node can be mapped to a topology node in the network topology model. Then, based on the collected dependency data, the specific dependency type and direction between different resource nodes are determined. For example, if there is a call relationship where service A calls service B, it indicates that service A depends on service B. This directed dependency is mapped to a directed edge connecting the two topology nodes, with its direction pointing from the dependent (service A) to the dependent (service B).

[0058] By traversing all known dependencies, all topological nodes and directed edges are integrated to form a complete directed graph structure G=(V,E), where V is the set of all topological nodes and E is the set of all directed edges. This graph structure is the network topology model of the cloud resource pool referred to in this invention.

[0059] Step 106: Determine the node importance index of resource nodes based on the topological attribute characteristics of the network topology model.

[0060] Optionally, topological attributes may include, but are not limited to: reachability, connectivity, critical path coverage, bottleneck degree, betweenness / in-out degree, and fault propagation sensitivity.

[0061] The node importance index of resource nodes is a quantitative indicator determined based on the network topology model. It can reflect the criticality of resource nodes in the topology structure, such as whether they are located at the intersection of multiple dependency paths or in a downstream core position. It can also characterize the degree of cascading impact that their failure may cause on the service availability of the entire cloud resource pool. Among them, resource nodes that are located upstream of more dependency chains and are directly or indirectly depended on by more other nodes have higher node importance indices.

[0062] Topological attribute features refer to quantitative indicators extracted from the constructed cloud resource pool dependent network that reflect the position, connectivity, and impact on the overall stability of each resource node in the network structure. These topological attribute features include at least one or more of the following: centrality indicators, reachability and connectivity features, path-related features, and weighted topological features after introducing node or edge weights.

[0063] Centrality metrics are used to measure how critical a node is as a hub for information or service flows. These metrics can include, for example, betweenness centrality, proximity centrality, PageRank value, in-degree / out-degree, etc.

[0064] Reachability and connectivity features are used to assess the cascading impact range that may be triggered by the failure of a resource node; for example, the number of downstream nodes that can be affected when a fault simulation is performed with a certain node as the source point, whether it is an cut point, and its strongly connected component.

[0065] Path-related features are used to characterize their participation in the core service chain; for example, the frequency with which a resource node appears in the critical business call path, the average shortest path length to other nodes, and other information.

[0066] Weighted topology features refer to topology features that incorporate node or edge weights, such as processing capacity, call frequency, and link bandwidth. These include, for example, weighted betweenness and influence scores of fused performance weights.

[0067] In an alternative implementation, some topological attribute features can also be obtained by performing fault injection simulations on the network topology model. For example, a graph traversal algorithm can be used to simulate the propagation process of a fault along dependent edges after a node fails, statistically analyze the set of affected nodes and propagation paths, and combine this with the aforementioned graph theory metrics for comprehensive calculation. Through these multi-dimensional topological attribute features, the structural criticality of each resource node in the overall cloud resource pool architecture can be more comprehensively and accurately characterized.

[0068] like Figure 2 As shown, in one embodiment, the node importance index of a resource node can be determined through the following steps 202 to 208: Step 202: Inject simulated faults into each topology node in the network topology model in sequence.

[0069] In some embodiments, simulated faults can be injected sequentially into each topology node in the network topology model in the following manner: First, a queue of nodes to be injected can be generated based on the topology nodes of the network topology model. Specifically, topology nodes can be uniformly identified, such as node ID / service name / instance identifier, and a queue Q of nodes to be injected can be generated according to preset queue generation rules. These queue generation rules may include, but are not limited to: sorting by topology node number, sorting by topology level (upstream to downstream or downstream to upstream), sorting by business criticality, grouping by node type, or using random shuffling with a seed to ensure the reproducibility of the experiment.

[0070] Optionally, to avoid duplicate injections or omissions, queue elements can use node ID and injection round as unique keys, and record the basic node attributes of resource nodes in the queue, including node type, number of dependencies, business domain, etc., for subsequent fault injection strategy matching.

[0071] Then, select topological nodes sequentially from the queue of nodes to be injected Q as the current injection objects, and perform injection operations on each current injection object until all topological nodes in the queue have been selected.

[0072] The so-called sequential selection refers to taking topology nodes one by one as fault injection targets in the same round of evaluation according to the queue order, so as to ensure that the fault injection of different topology nodes does not overlap in time or only occurs under controllable overlap rules, thereby improving the comparability and interpretability of the evaluation results.

[0073] Optionally, to ensure the fault injection process is controllable, preconditions can be set for each fault injection, such as: the current topology model is in a stable state, key indicators are within the baseline range, and the disturbance from the previous round of injection has been restored to the threshold range; otherwise, the current injection will be paused or delayed.

[0074] Next, a fault injection strategy matching the current injection object can be selected from a preset fault mode library. This fault mode library stores injectable simulated fault types, their applicable conditions, and execution methods. Fault types may include, but are not limited to: node unreachability / process crash, CPU / memory resource exhaustion, disk I / O limitation, increased network latency, increased packet loss, bandwidth limitation, connection pool exhaustion, configuration errors / version inconsistencies, etc. Specifically, matching can be performed based on the node type and attributes of the current injection object. For example: when the injection object is a database node, priority is given to matching connection pool exhaustion and disk I / O limitation; when the injection object is a network device or link abstraction node, priority is given to matching latency / packet loss / bandwidth limitations; when the injection object is a microservice node, priority is given to matching process crash, increased error rate, rate limiting triggering, etc.

[0075] In some embodiments, the fault mode library may include a variety of possible hardware, software, and network failures. The failure modes for these failures may be defined based on historical data, industry standards, and expert knowledge; for example, they may include hardware failures, software crashes, and network latency.

[0076] In some embodiments, a fault injection strategy matching the current injection object is selected to determine when, where, and how to inject the fault. When selecting a fault injection strategy, several factors may be considered, such as the test objective, the importance of the system, and the potential impact of the fault.

[0077] A fault injection strategy should include at least the following: injection target, injection scope, injection timing, injection location, simulated fault type, and simulated fault duration. Optionally, it may further include parameters such as injection intensity, latency increase, packet loss ratio, CPU utilization target value, injection frequency, recovery method, and rollback operation.

[0078] Injection target: Used to specify the target of injection, such as a specific hardware component, software module, or network segment.

[0079] The injection scope is used to limit the objects affected by the fault. For example, it can only affect the current injected object itself, or extend to a certain port / interface / container instance, or affect its outbound / inbound links, such as only perturbing the edges of a certain dependent node.

[0080] Injection timing is used to specify the time point or triggering condition for starting injection, such as injecting during a business slump, injecting after detecting that the indicator has entered a stable range, or injecting after completing preheating sampling.

[0081] Injection location is used to determine the point where the fault is applied, such as injecting on the resource node side (process / container / host), or injecting on the link side, or injecting on the configuration side.

[0082] Simulated fault types are used to specify the fault category and its mechanism of action.

[0083] Simulate the duration of the fault to specify the duration of the fault, such as 30 seconds, 1 minute, or 5 minutes, to ensure that the propagation effect can be observed.

[0084] Finally, simulated fault injection can be performed on the current injection object based on the fault injection strategy. For example, specialized fault injection tools or platforms can be used to perform simulated fault injection operations.

[0085] After performing simulated fault injection on the current injection object, the behavior and performance of the node can be monitored, and key indicators and data can be recorded to analyze the impact of the fault on the system.

[0086] Optionally, to ensure the repeatability and controllability of the test, the system state can be backed up before the fault is injected and the system can be restored to its original state after the test.

[0087] In one implementation, if injection is performed at the topology model layer, changes can be applied to the node quantization parameters of the currently injected object. For example, the processing capacity parameter can be reduced to 30% of its original value, or the reliability parameter can be temporarily set to a low value. Alternatively, changes can be applied to the edge quantization parameters of its adjacent directed edges. For example, the latency parameter of a certain outgoing edge can be increased by 100ms, the packet loss parameter can be increased to 2%, and the bandwidth parameter can be limited to 50% of its original value. This creates an effect in the model that is consistent with the actual fault.

[0088] In another implementation, if injection is performed in a simulation / sandbox environment, a fault injection executor can be invoked to apply corresponding fault actions to the target node, such as triggering process restart, simulating network jitter, applying rate limiting / packet loss rules, creating resource contention, etc. During the injection duration, key indicators and propagation path data are continuously collected. After the injection is completed, recovery and rollback operations are performed, such as canceling rate limiting / packet loss rules, restoring configuration, releasing resource pressure, and waiting for the node indicators to return to the dynamic baseline threshold before taking the next topology node from the queue to continue the injection, so as to complete the injection evaluation of all topology nodes in the network topology model one by one.

[0089] By using the above-mentioned queued, node-by-node injection method, the simulated fault injection can be guaranteed to have the characteristics of full coverage, repeatability, comparability, and controllable recovery, thereby providing reliable input for subsequent calculation of reachable node sets, recording propagation paths, quantifying the scope of influence, and determining node importance indicators.

[0090] Step 204: For each injected simulated fault, take the topology node where the fault occurred as the source node, determine the set of reachable nodes of the source node in the network topology model, and record the propagation path of the simulated fault.

[0091] In some embodiments, for each injected simulated fault, the faulty topological node can be identified as the source node, and a graph traversal algorithm, such as Depth-First Search (DFS) or Breadth-First Search (BFS), can be initiated to perform forward propagation analysis along the direction of the directed edges. Since dependencies are directed (e.g., A → B means A depends on B), faults typically propagate backward from the dependent (B) to the dependent (A). Therefore, in practical implementations, a reverse dependency graph (i.e., all edges are reversed) can be pre-constructed, so that forward traversal from the source node in the reverse graph can naturally simulate the propagation process of the fault to the upstream dependent. During the traversal, all visited nodes constitute the set of reachable nodes for this fault; these nodes are the services or components that may be directly or indirectly affected by the source node's fault.

[0092] Simultaneously, the complete sequence of edges traversed from the source node to each reachable node can be recorded, forming one or more propagation paths. These propagation paths can not only be used to identify the affected area, but also provide a structural basis for subsequent refined impact assessments combined with link quality parameters.

[0093] Step 206: Based on the node quantization parameters of each topological node in the reachable node set and the edge quantization parameters of each directed edge in the propagation path, determine the propagation path and impact range of the simulated fault. The node quantification parameters characterize the service capabilities and stability of the resource nodes themselves, and include at least processing capacity parameters and reliability parameters. Processing capacity parameters may include the number of CPU cores, memory capacity, and transactions per second (TPS). Reliability parameters include historical mean time between failures (MTBF), service level agreement (SLA) compliance rate, and recent alarm frequency.

[0094] Edge quantization parameters are used to characterize the carrying capacity and transmission quality of links between nodes, and include at least one or more of the following: bandwidth parameters (maximum link throughput), latency parameters (average network latency), and packet loss parameters (packet loss rate).

[0095] In some embodiments, propagation strength / propagation probability can be calculated for each propagation path. For example, lower edge bandwidth and higher latency / packet loss are considered to be greater propagation risk, and lower node reliability is considered to be more susceptible to propagation impact. Thus, the degree of impact (e.g., 0 to 1 impact score) can be calculated for each reachable node.

[0096] Optionally, nodes with influence scores higher than a threshold can be included in the influence range, or the subgraph formed by the influence scores on the topology can be considered as the influence range. Simultaneously, influence range metrics can be output, such as the number of affected nodes, the number of affected critical nodes, the cumulative influence score, and the cumulative performance loss, thereby obtaining quantitative results of the propagation path and influence range.

[0097] In some embodiments, when determining the scope of impact, a weighted impact assessment of each propagation path can be performed by combining the aforementioned parameters. For example, the propagation cost of a propagation path can be defined as a function of the sum of the delays of all edges on the path multiplied by the packet loss rate; simultaneously, the degree of impact on a reachable node can be determined by its own reliability parameter (lower values ​​indicate greater vulnerability) and the cost of the shortest weighted path to that node. Ultimately, the comprehensive impact scope of this simulated failure can be quantified as the sum of the degree of impact on all reachable nodes, or a weighted business impact value (such as the number of affected users, the amount of interrupted transactions, etc., if associated with business metadata). This approach upgrades impact assessment from quantitative statistics to qualitative perception, making it closer to real-world operational scenarios.

[0098] Step 208: Determine the node importance index of each resource node based on the propagation path and the scope of influence.

[0099] In some embodiments, after simulating fault injection for each source node and obtaining the corresponding propagation path and impact range, the node importance index of each resource node can be determined based on the propagation path and the impact range. Specifically, the impact range can be quantified into at least one or more impact metrics, such as the number of affected nodes, the number of affected critical nodes, the cumulative impact score of affected nodes, the cumulative performance loss (throughput decrease, latency increase, error rate increase), and the duration of the impact.

[0100] At the same time, the propagation path is quantified into at least one or more path metrics, such as path length, critical path coverage, cumulative values ​​of edge quantization parameters on the path (bandwidth bottleneck level, latency / packet loss accumulation level), and path redundancy (whether there are alternative paths).

[0101] Then, the impact metric and the path metric are combined to calculate the node importance index corresponding to the source node. For example, the scale and intensity of the impact range are used as the main term, and the criticality and vulnerability of the propagation path are used as the correction term: when the failure of a source node leads to a larger impact range, a higher impact intensity, and the propagation path traverses more bottleneck edges or critical edges, the importance index of the source node is higher; when there are multiple alternative paths in the propagation path or the impact range is limited to non-critical nodes, the importance index of the source node is relatively low.

[0102] Optionally, to improve the stability of the assessment, the node importance indicators calculated under different fault types (such as crashes, increased latency, increased packet loss, limited bandwidth, etc.) can be aggregated. For example, the expected value can be calculated by weighting the probability of occurrence of fault type or business weight, or the maximum value can be taken to represent the worst case, so as to obtain the final node importance index of each resource node, thereby realizing the quantitative determination of the importance of resource nodes based on propagation path and impact range.

[0103] In some embodiments, considering that relying solely on topology centrality may overlook the differences in the actual service carrying capacity of nodes, when determining node importance indicators, network health can first be determined by comparing the actual traffic of resource nodes in a fault state with their nominal traffic determined based on topology attribute characteristics. Then, the node importance indicator can be calculated based on the reciprocal of the network health or the traffic loss ratio. This ensures that the calculated node importance indicator not only reflects the structural criticality of a node in the network but also incorporates its traffic carrying value in real business scenarios, thereby more accurately identifying the core nodes that have the greatest impact on user experience and business continuity.

[0104] The nominal traffic refers to the maximum service traffic value that a resource node can stably handle under normal historical conditions. Its unit can be requests per second (RPS), transactions per second (TPS), or network bandwidth (such as Gbps). This value is not fixed but dynamically derived by analyzing the node's topological attributes in the network topology model. In some embodiments, the nominal traffic can be determined as follows: First, based on historical monitoring data, the peak traffic of the node during fault-free, low-latency periods is statistically analyzed; second, the peak traffic is weighted and corrected according to its topological location to obtain a more structurally based nominal traffic value.

[0105] Network health can be defined as the ratio of the actual traffic when a resource node fails to the nominal traffic of that resource node under normal conditions. For each resource node... i Its network health status during normal operation is:

[0106] Where R represents a value between 0 and 1, where 1 indicates that the network is completely healthy and 0 indicates that the network is completely unavailable; This indicates the network health of resource node i when it is in normal working condition. This indicates the working state, which is the sum of the output edges of this resource node. This refers to the nominal flow rate.

[0107] When resource nodes i When a malfunction occurs, its operating state changes to ,in The network health status at this time is:

[0108] in, This represents the network health when resource node i fails. The closer this ratio is to 1, the smaller the impact of the failure on traffic and the higher the network health; conversely, the closer it is to 0, the more likely the service is to be interrupted.

[0109] After performing simulated fault injection on a resource node, the actual traffic of that node under fault conditions can be estimated using the traffic simulation module or historical fault replay data. Typically, if a node is completely down, its actual traffic will approach zero; if it is a performance degradation fault (such as high latency), the actual traffic may drop to a certain percentage of the nominal traffic.

[0110] The network health at the time of resource node failure is then determined by the ratio of the actual traffic at the time of the resource node failure to the nominal traffic of the resource node.

[0111] Finally, the node importance index of resource nodes is determined based on network health.

[0112] In some embodiments, to more comprehensively assess the overall importance of resource nodes in a cloud resource pool, it is necessary to consider multiple dimensions of key performance indicators, such as the processing power and reliability of resource nodes, rather than being limited to the impact of network topology or fault propagation. Therefore, when calculating the node importance indicators of resource nodes, in addition to the impact of network topology or fault propagation and network health described above, key performance factors of the node can be further incorporated into the consideration, and weighting factors can be introduced to quantify and integrate these factors.

[0113] Specifically, suppose there exists a containing j Vector of key performance factors ,in, Indicates the first j The weighting factors of each key performance factor, satisfying the normalization condition:

[0114] The key performance factors mentioned here refer to the evaluation factors used to assess the importance of nodes. Optionally, the key performance factors used to assess the importance of nodes may include, but are not limited to, one or more of the following: The processing capacity of resource nodes; Reliability of resource nodes; The business criticality of a resource node; this business criticality characterizes whether the service carried by the resource node belongs to the core business chain (such as user login, payment transactions, order creation, etc.). It can be quantified through preset business priority tags (such as P0 / P1 level services) or their associated potential revenue impact weights; Service availability history of resource nodes; This service availability history refers to the actual availability rate of nodes based on historical monitoring data statistics, such as an availability rate of 99.95% in the past 30 days, which is used to reflect its long-term operational stability. The traffic load level of a resource node is used to represent the scale of business traffic processed by the resource node under normal operating conditions, including queries per second (QPS), transactions per second (TPS), or network throughput (Gbps). The data role attributes of resource nodes; for example, if the resource node is the primary database instance, the primary replica of the distributed storage system, or undertakes strong consistency write tasks, then it has higher value in ensuring data integrity. Resource node recovery time objective (RTO) and recovery point objective (RPO); that is, the maximum acceptable recovery time and data loss after the failure of the node as defined by the operation and maintenance strategy. The stricter the RTO / RPO requirements, the more critical their supporting role in business continuity. Security sensitivity of resource nodes; specifically, if a resource node is involved in user privacy data processing, key management, or is located at the network security boundary (such as a DMZ gateway), its anomalies may trigger compliance risks or large-scale security incidents, and should be given higher importance. The cross-domain dependency characteristic of resource nodes; this cross-domain dependency characteristic is used to characterize whether the resource node is connected to multiple availability zones or geographical regions. If such a resource node fails, it may cause regional service interruption, with a wider impact. The breadth and depth of dependencies of a resource node; where breadth of dependency refers to the number of downstream services that directly depend on the resource node, and depth of dependency refers to the furthest level at which a fault can propagate along the dependency chain.

[0115] In practical applications, for each resource node in the network topology model i In the above j The scores on each key performance factor can be represented as a multidimensional feature vector. ,in, Represents resource nodes i In the j The quantitative score for each key performance factor typically ranges from [0, 1]. A higher value indicates that the resource node performs better in terms of that key performance factor.

[0116] Based on this, resource nodes can be i Final node importance index Defined as the weighted sum of the factor scores of each key performance factor and the product of the degree of network health degradation caused by the failure of the resource node, as follows:

[0117] The node importance index determined by this method This not only reflects the ability of resource nodes to cause fault propagation in the network structure, but also fully considers their basic performance in terms of multiple key performance factors such as processing power and reliability. It can break through the limitations of traditional technologies that rely solely on topology centrality or a single performance indicator, and achieve a business-aware and risk-oriented comprehensive assessment of the importance of resource nodes, thereby providing more accurate technical support for the health assessment of cloud resource pools.

[0118] Step 108: Perform weighted aggregation based on the node importance index and node health of resource nodes to obtain the health of the cloud resource pool.

[0119] In some embodiments, in order to ensure that the health of the cloud resource pool can simultaneously reflect the operational health status and importance of each resource node, the health of the cloud resource pool can be calculated by weighted aggregation based on the node importance index and node health of the resource nodes. The specific implementation process is as follows:

[0120] in, Indicator representing the importance of resource node i; Indicates the health status of resource node i; This indicates the number of resource nodes in the cloud resource pool.

[0121] In some optional embodiments, after obtaining the health status of the cloud resource pool, a comprehensive analysis can be performed by combining the propagation path and impact range of the simulated fault determined in step 206 and the node importance index determined in step 208, so as to effectively identify the vulnerabilities in the cloud resource pool and optimize its performance, so as to ensure that the cloud resource pool can maintain efficient and stable operation under various workloads.

[0122] Specifically, during the vulnerability assessment phase, a series of performance metrics can be defined and collected, such as response time, throughput, and resource utilization (CPU, memory, disk I / O, network bandwidth). Optionally, these metrics can be collected in real time using dedicated monitoring tools (such as Auvik, Prometheus, Zabbix, etc.) and stored in a time-series database. Resource utilization can be expressed as a percentage, calculated using the following formula:

[0123] Taking CPU utilization as an example, it can be specifically expressed as:

[0124] Optionally, to ensure the accuracy and validity of the data, the monitoring tools can be calibrated and verified periodically to ensure coverage of all critical components. By comparing the differences between current performance metrics and dynamic baseline thresholds or historical data, performance anomalies or system bottlenecks can be identified, and performance trends and patterns under different time periods and loads can be analyzed to discover potential performance problems (such as resource contention, improper configuration, etc.).

[0125] Secondly, during the performance optimization phase, corresponding optimization strategies can be formulated based on the performance analysis results. Optimization measures may include: adjusting system configuration parameters (such as JVM heap size and connection pool size), optimizing application code logic (such as reducing the number of database queries), increasing hardware resources (such as expanding CPU and memory), or introducing caching mechanisms. Before implementing any optimization strategy, thorough testing and verification must be conducted to ensure its effectiveness and safety. Through continuous performance optimization, not only can the overall system performance be improved and the user experience enhanced, but operating costs can also be reduced, achieving efficient resource utilization.

[0126] In some embodiments, after obtaining the health status of the cloud resource pool, resource management strategy formulation steps can also be performed, that is, dynamically and efficiently allocating, scheduling and reclaiming various resources such as computing, storage, and network according to changes in business needs, so as to maximize the utilization of cloud resource pool resources and ensure the stable operation of the system.

[0127] Specifically, based on the health assessment results, performance analysis reports, and business prediction models of the cloud resource pool, strategies such as resource scaling, load balancing adjustments, and resource migration can be automatically triggered. For example, when the health of a resource node is detected to be continuously declining and approaching the threshold, its traffic can be proactively transferred to a backup node, and a fault recovery process can be initiated; when peak business periods arrive, virtual machine instances can be scaled up as needed to ensure that service quality is not degraded.

[0128] By organically combining health assessment, performance analysis, optimization decision-making, and resource scheduling, an end-to-end intelligent operation and maintenance closed loop for cloud resource pools can be achieved. This enables a shift from passive alarms to proactive prevention and from experience-driven to data-driven approaches, significantly improving the stability, reliability, and operational efficiency of the cloud platform.

[0129] The method provided in this application obtains dependency data between different resource nodes in the cloud resource pool and constructs a network topology model. Then, based on topology attribute features, the importance of each resource node in the overall architecture can be quantified. In this way, during the health assessment of the cloud resource pool, the node health of resource nodes can be correlated with their node importance indicators, thereby comprehensively reflecting the interdependence between resource nodes and the impact of important nodes on the health assessment of the cloud resource pool. This effectively overcomes the problem of assessment bias and distortion caused by relying only on isolated devices / indicators in the prior art, and achieves accurate assessment of the health of the cloud resource pool.

[0130] To address the problem that existing technologies focus solely on monitoring and evaluating the performance indicators of individual resources or devices, lacking a comprehensive analysis of the overall topology of the cloud resource pool and the dependencies between resource nodes, resulting in biased and inaccurate cloud resource pool health assessments that fail to accurately reflect the overall operational status of the resource pool, this application provides a cloud resource pool health assessment device. A schematic diagram of the device's specific structure is shown below. Figure 3 As shown, it includes an acquisition module 31, a construction module 32, a determination module 33, and an evaluation module 34. The functions of each module are as follows: The acquisition module 31 is used to acquire the node health status of resource nodes in the cloud resource pool and the dependency relationship data between different resource nodes; Module 32 is used to build a network topology model for the cloud resource pool based on dependency data; Module 33 is used to determine the node importance index of resource nodes based on the topological attribute characteristics of the network topology model. Evaluation module 34 is used to perform weighted aggregation based on the node importance indicators and node health of resource nodes to obtain the health of the cloud resource pool.

[0131] Optionally, module 31 is used for: Obtain the running status data of resource nodes, which includes at least one of CPU utilization, memory usage, disk I / O rate, and network throughput; The health of resource nodes is calculated based on the operational status data and the dynamic baseline threshold of the operational status data. The dynamic baseline threshold is adaptively adjusted based on the periodic fluctuation characteristics of the historical operational status data of resource nodes.

[0132] Optional, building module 32, used for: Map resource nodes to topology nodes in the network topology model; Dependency relationships between different resource nodes are determined based on dependency data. Dependency relationships include at least one of the following: call relationships, data flow relationships, resource consumption relationships, or configuration dependencies. Map the dependencies between different resource nodes as directed edges connecting topology nodes; Based on the topological nodes and directed edges, the network topology model of the cloud resource pool is obtained.

[0133] Optionally, module 33 is defined, including: The injection unit is used to inject simulated faults into each topology node in the network topology model in sequence. The first determining unit is used to determine the set of reachable nodes of the source node in the network topology model for each injected simulated fault, taking the topology node where the fault occurred as the source node, and record the propagation path of the simulated fault. The second determining unit is used to determine the propagation path and impact range of the simulated fault based on the node quantization parameters of each topological node in the reachable node set and the edge quantization parameters of each directed edge in the propagation path. The third determining unit is used to determine the node importance index of each resource node based on the propagation path and the scope of influence. The node quantization parameters include at least one or more of the processing capability parameters and reliability parameters, and the edge quantization parameters include at least one or more of the bandwidth parameters, latency parameters, and packet loss parameters.

[0134] Optional, injection unit, used for: Generate a queue of nodes to be injected based on the topology nodes in the network topology model; Select topology nodes sequentially from the queue of nodes to be injected as the current injection targets, and perform the following operations until all topology nodes in the queue of nodes to be injected have been selected: Select a fault injection strategy that matches the current injection object from the preset fault mode library. The fault injection strategy shall include at least the injection scope, injection timing, injection location, type of simulated fault injected, and duration of simulated fault. Simulated fault injection is performed on the current injection object based on the fault injection strategy. Optionally, module 33 is used for: The nominal flow of resource nodes is determined based on the topological attribute characteristics of the network topology model. The nominal flow is the maximum flow of the resource node under normal working conditions. Determine the actual traffic flow when a resource node fails; The network health at the time of resource node failure is determined based on the actual traffic and the nominal traffic of the resource node. The importance of resource nodes is determined based on network health.

[0135] By using the apparatus provided in this application embodiment, dependency relationship data between different resource nodes in the cloud resource pool is obtained, and a network topology model is constructed. Then, the importance of each resource node in the overall architecture can be quantified based on topology attribute features. In this way, during the health assessment of the cloud resource pool, the node health of resource nodes can be correlated with their node importance indicators, thereby comprehensively reflecting the interdependence between resource nodes and the impact of important nodes on the health assessment of the cloud resource pool. This effectively overcomes the problem of assessment bias and distortion caused by relying only on isolated devices / indicators in the prior art, and achieves accurate assessment of the health of the cloud resource pool.

[0136] Figure 4 To illustrate the hardware structure of an electronic device according to various embodiments of this application, the electronic device may include a processor 401 and a memory 402 storing computer program instructions. Specifically, the processor 401 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of this application.

[0137] Memory 402 may include mass storage for data or instructions. For example, and not limitingly, memory 402 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 402 may include removable or non-removable (or fixed) media. Where appropriate, memory 402 may be internal or external to an electronic device. In a particular embodiment, memory 402 may be a non-volatile solid-state memory.

[0138] In one embodiment, memory 402 may be read-only memory (ROM). In one embodiment, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0139] The processor 401 reads and executes computer program instructions stored in the memory 402 to implement any of the cloud resource pool health assessment methods in the above embodiments.

[0140] In one example, the electronic device may also include a communication interface 403 and a bus 410. For example, Figure 4 As shown, the processor 401, memory 402, and communication interface 403 are connected through bus 410 and complete communication with each other.

[0141] The communication interface 403 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0142] Bus 410 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 410 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0143] Furthermore, in conjunction with the cloud resource pool health assessment method in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the cloud resource pool health assessment methods in the above embodiments.

[0144] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0145] The above description is merely a specific implementation example of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0146] Secondly, those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0147] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0148] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0149] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0150] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0151] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0152] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0153] It should also be noted that 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 limitation, 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.

[0154] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for assessing the health of a cloud resource pool, characterized in that, include: Obtain the node health status of resource nodes in the cloud resource pool and the dependency relationship data between different resource nodes; Based on the dependency data, a network topology model of the cloud resource pool is constructed; The node importance index of the resource node is determined based on the topological attribute characteristics of the network topology model. The health of the cloud resource pool is obtained by weighted aggregation based on the node importance index and the node health of the resource nodes.

2. The method as described in claim 1, characterized in that, The process of obtaining the node health status of resource nodes in the cloud resource pool includes: Obtain the running status data of the resource node, the running status data including at least one of CPU utilization, memory usage, disk I / O rate and network throughput; The node health of the resource node is calculated based on the operational status data and the dynamic baseline threshold of the operational status data, wherein the dynamic baseline threshold is adaptively adjusted based on the periodic fluctuation characteristics of the historical operational status data of the resource node.

3. The method as described in claim 1, characterized in that, The process of constructing the network topology model of the cloud resource pool based on the dependency data includes: Map the resource nodes to topology nodes in the network topology model; The dependency relationships between the different resource nodes are determined based on the dependency relationship data, and the dependency relationships include at least one of the following: call relationship, data flow relationship, resource occupation relationship or configuration dependency relationship; The dependencies between the different resource nodes are mapped as directed edges connecting the topology nodes; Based on the topological nodes and the directed edges, the network topology model of the cloud resource pool is obtained.

4. The method as described in claim 1, characterized in that, The determination of the node importance index of the resource node based on the topological attribute features of the network topology model includes: Simulated faults are injected sequentially into each topology node in the network topology model; For each injected simulated fault, the topology node where the fault occurred is taken as the source node. The set of reachable nodes of the source node in the network topology model is determined, and the propagation path of the simulated fault is recorded. Based on the node quantization parameters of each topological node in the reachable node set and the edge quantization parameters of each directed edge in the propagation path, the propagation path and impact range of the simulated fault are determined. The node importance index of each resource node is determined based on the propagation path and the scope of influence; The node quantization parameters include at least one or more of processing capability parameters and reliability parameters, and the edge quantization parameters include at least one or more of bandwidth parameters, latency parameters, and packet loss parameters.

5. The method as described in claim 4, characterized in that, The step of sequentially injecting simulated faults into each topology node in the network topology model includes: A queue of nodes to be injected is generated based on the topology nodes in the network topology model. From the queue of nodes to be injected, select topology nodes sequentially as the current injection targets, and perform the following operations until all topology nodes in the queue of nodes to be injected have been selected: Select a fault injection strategy that matches the current injection object from a preset fault mode library. The fault injection strategy includes at least the injection range, injection timing, injection location, type of simulated fault, and duration of simulated fault. Based on the fault injection strategy, simulated fault injection is performed on the current injection object.

6. The method as described in claim 1, characterized in that, The determination of the node importance index of the resource node based on the topological attribute features of the network topology model includes: The nominal flow of the resource node is determined based on the topological attribute characteristics of the network topology model. The nominal flow is the maximum flow of the resource node under normal operating conditions. Determine the actual traffic flow when the resource node fails; The network health at the time of the resource node failure is determined based on the actual traffic and the nominal traffic of the resource node. The node importance index of the resource node is determined based on the network health status.

7. A health assessment device for a cloud resource pool, characterized in that, It includes an acquisition module, a construction module, a determination module, and an evaluation module, among which: The acquisition module is used to acquire the node health status of resource nodes in the cloud resource pool and the dependency relationship data between different resource nodes; A building module is used to construct a network topology model of the cloud resource pool based on the dependency relationship data; The determination module is used to determine the node importance index of the resource node based on the topological attribute characteristics of the network topology model; The evaluation module is used to perform weighted aggregation based on the node importance index and node health of the resource nodes to obtain the health of the cloud resource pool.

8. An electronic device, characterized in that, include: The memory, the processor, and the computer program stored on the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the cloud resource pool health assessment method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the cloud resource pool health assessment method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the cloud resource pool health assessment method according to any one of claims 1 to 6.

Images