A private cloud core service support node deployment method and system

Abstract

The application relates to the technical field of node deployment, and provides a private cloud core business support node deployment method and system. A business analysis module deeply disassembles core business, and dynamically generates a business weight matrix. A facility perception module processes performance indexes of physical resource nodes based on a long short-term memory network to predict a failure risk probability, generates a risk heat map to intuitively present risk distribution of global nodes. A decision judgment module generates a deployment cost matrix based on the business weight matrix, combines the risk heat map to construct a penalty term to complete matrix correction, constructs an optimization function taking total cost and resource balance as targets, and outputs a deployment strategy scheme after solving. A deployment evolution module continuously monitors running data of core business and state data of infrastructure after executing the deployment strategy scheme to link and update the business weight matrix and the risk heat map, and re-outputs the deployment strategy scheme to guarantee stability of core business running and continuous optimization of resource utilization.

Description

Technical Field

[0001] This application relates to the field of node deployment technology, and in particular to a method and system for deploying core business support nodes in a private cloud. Background Technology

[0002] With its high data security and strong business adaptability, private cloud has become the infrastructure for carrying core businesses in different fields. The stable operation of core businesses depends heavily on the reasonable deployment of physical resource nodes.

[0003] At the business level, existing technologies can perform basic deconstruction of core businesses, identify basic functions and simple call relationships, and some solutions can preliminarily count the frequency of interactions between businesses and form static relationship tables. At the facility monitoring level, mainstream technologies can collect basic indicators such as CPU load, memory usage, and network bandwidth of physical resource nodes, and achieve basic fault early warning through threshold alarms. At the deployment decision level, existing solutions can build a single-dimensional deployment cost model based on business interaction data or hardware resource status, and output basic deployment strategies in combination with intelligent algorithms. At the deployment execution level, most systems can complete the implementation and deployment of strategies and have basic operational status monitoring capabilities.

[0004] However, existing business parsing technologies are mostly limited to identifying static call relationships of businesses, and cannot dynamically reflect business operation requirements. The business-related data they generate are mostly fixed values, which are difficult to adapt to changes in dynamic scenarios such as peak transactions and process iterations in core businesses, resulting in a disconnect between subsequent deployment strategies and actual business needs. Existing facility monitoring technologies mostly use simple threshold comparisons to achieve fault warnings, without combining time-series data characteristics to make forward-looking predictions of node fault risks, and without considering the risk transmission effect between nodes in the private cloud topology. Existing decision-making technologies only focus on explicit costs such as hardware resource consumption, without incorporating infrastructure risks into the cost quantification system, and the construction of optimization functions mostly focuses on the single objective of minimizing total cost or maximizing resource balance, making it difficult to achieve a dynamic balance of multiple objectives.

[0005] In view of the shortcomings of the existing technology, the technical problem to be solved by this application is how to deeply analyze the core business in the process of complex operation in order to achieve accurate deployment and dynamic evolution of support nodes. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides a method and system for deploying core business support nodes in a private cloud.

[0007] In the first aspect, this application provides a private cloud core business support node deployment system, which includes: a business parsing module, a facility awareness module, a decision-making module, and a deployment evolution module;

[0008] The business parsing module deconstructs the core business to identify and analyze the data flow, call relationships and transaction associations between business components, and dynamically generates a business weight matrix that reflects the communication tightness between business components;

[0009] The facility perception module acquires the performance indicators of physical resource nodes in the private cloud infrastructure in real time, predicts the failure risk probability of different physical resource nodes based on the performance indicators of the long short-term memory network, and generates a risk heat map of the infrastructure simultaneously.

[0010] The decision-making module generates a deployment cost matrix representing the deployment of business components on the same physical resource node based on the business weight matrix, generates a penalty term based on the risk heat map and weights and corrects the deployment cost matrix, constructs and solves an optimization function with the total cost and resource balance of the corrected deployment cost matrix as the objective, and outputs a deployment strategy scheme.

[0011] The deployment evolution module executes the deployment strategy and, after deployment, continuously acquires the operational data of core businesses and the status data of infrastructure, compares them with the expected indicators of the deployment strategy, and updates the business weight matrix and risk heat map and re-outputs the deployment strategy after the comparison deviation exceeds the preset threshold.

[0012] As an optional implementation method, dynamically generating the business weight matrix includes:

[0013] The core business is deconstructed into business components at different functional levels, and the functional attributes and core status of the business components are clarified in order to classify and label the business components.

[0014] Real-time acquisition of communication data between business components, extraction of interaction features of communication data, and parsing of transaction logs of core business to identify transaction relationships between business components;

[0015] The weighting coefficients are determined based on the coreness of the business components and the transactional relationships between them. The initial weights reflecting the communication tightness between the business components are then calculated by combining the weighting coefficients with the interaction characteristics.

[0016] The initial weights are dynamically adjusted based on the operational scenarios of the core business to dynamically generate a business weight matrix.

[0017] As an optional implementation, the risk heatmap for the generated infrastructure includes:

[0018] Real-time acquisition of operational data, full lifecycle data, and environmental correlation data of physical resource nodes in private cloud infrastructure; after preprocessing, performance indicators characterizing the status of physical resource nodes are formed.

[0019] Based on the performance metrics of long short-term memory networks, the failure risk probability of different physical resource nodes is predicted. The propagation risk probability is determined based on the dependency relationship of physical resource nodes in the physical topology of the private cloud, and then weighted and fused with the failure risk probability according to the preset weight to obtain the risk probability.

[0020] By combining the core level of the business components to be deployed with the risk threshold, and based on the physical topology of the private cloud, a risk heat map is generated according to the risk probability.

[0021] As an optional implementation, generating the deployment cost matrix includes:

[0022] The core level of the business components, the transactional relationships between business components, and the interaction characteristics of communication data are called. Combined with the risk threshold corresponding to the core level of the business components to be deployed, the deployment constraints of business components, including resource exclusivity, transactional coordination, and communication requirements, are marked.

[0023] Based on the business weight matrix, cost factors for resource competition cost, transaction coordination cost and communication cost are constructed. Dynamic weights are assigned to the cost factors and weighted calculation is performed in combination with deployment constraints to form the initial deployment cost between business components deployed on the same physical resource node.

[0024] Adjust the initial deployment cost based on the core business operation scenarios and integrate them to generate a deployment cost matrix.

[0025] As an optional implementation, the weighted modified deployment cost matrix includes:

[0026] The risk probability of physical resource nodes constitutes the fault penalty item, the coreness of the business component constitutes the business penalty item, the deployment constraints of the associated business component constitute the deployment penalty item, and the penalty items are generated by weighting and integrating them according to a preset ratio.

[0027] Based on the transactional relationships between business components, the dependencies between physical resource nodes, and the operational scenarios of core businesses, coupling weights are assigned to penalty terms.

[0028] The deployment cost matrix is ​​then adjusted by layering and weighting based on the combination of business components and physical resource nodes, combined with coupling weights, and the adjusted deployment cost matrix is ​​then normalized and calibrated.

[0029] As an optional implementation, the deployment strategy scheme output includes:

[0030] With the total cost and resource balance of the revised deployment cost matrix as the target, the target priority of total cost and resource balance is dynamically adapted based on the operation scenario of the core business and the coreness of the business components.

[0031] Constraints are formed by combining transactional relationships between business components, deployment constraints, and penalty terms, and then embedded into objectives. Optimization functions are constructed by combining objective priorities.

[0032] The communication cost is processed by clustering algorithm to cluster business components into component clusters. Physical resource nodes are pre-matched for component clusters based on risk heat map, and the optimization function is solved based on genetic algorithm.

[0033] The solution results are verified based on risk thresholds and cost factors. Once the verification is successful, a deployment strategy scheme including the mapping relationship between business components and physical resource nodes is output.

[0034] As an optional implementation method, the execution deployment strategy includes:

[0035] Before deployment, the component cluster is verified by combining real-time updated risk heat maps and deployment constraints to determine whether backup nodes are matched based on the dependencies of physical resource nodes.

[0036] Based on the core nature of the business components and the division of component clusters, deployment is carried out in the hierarchical order of core assurance layer, business support layer and auxiliary operation and maintenance layer;

[0037] After deployment, continuously acquire core business operation data, infrastructure status data, and risk heat map change trends to adjust the deployment location of business components;

[0038] The system receives operational data from core business operations and status data from infrastructure, compares them with the expected metrics of the deployment strategy, and updates the business weight matrix and risk heat map and re-outputs the deployment strategy when the comparison deviation exceeds a preset threshold.

[0039] As an optional implementation, updating the risk heatmap includes:

[0040] The update scope of the risk heat map is determined based on the type of comparison deviation and the core nature of the business components.

[0041] An updated data pool is formed by performance indicators, changes in the deployment location of business components, and operational data of core businesses and status data of infrastructure, and the cause of deviation is marked for comparison discrepancies.

[0042] Based on the bias attribution labeled in the updated data pool, the input weights of performance indicators in the long short-term memory network and the preset weights in the risk probability are dynamically adapted to generate the updated risk probability after deployment.

[0043] The risk heat map is updated by iterating through the physical resource nodes in the data pool in the order of core security layer, business support layer and auxiliary operation and maintenance layer.

[0044] The compatibility of the updated risk heatmap with the pre-matching results of deployment constraints and component clusters is verified, and the input weights and preset weights in the risk probabilities are iteratively optimized based on the verification results.

[0045] As an optional implementation, the redeployment strategy includes:

[0046] The updated business weight matrix and risk heat map are calibrated together, and the coupling weights of the penalty terms in the deployment constraint and deployment cost matrix are corrected simultaneously.

[0047] Based on the type of comparison deviation, the target priority of the optimization function and the parameters of the genetic algorithm are matched, and a hierarchical strategy is generated according to the corresponding levels of the core security layer, business support layer and auxiliary operation and maintenance layer.

[0048] By combining the operational scenarios of core businesses with the changing trends of risk heat maps, we can simulate and evaluate whether business components meet deployment constraints, re-cluster them to correct the mapping relationship between business components and physical resource nodes, and output a new deployment strategy plan after accumulating simulation experience.

[0049] Secondly, this application provides a method for deploying core business support nodes in a private cloud. The method includes: deconstructing the core business to identify and analyze the data flow, call relationship and transaction correlation between business components, and dynamically generating a business weight matrix that reflects the communication tightness between business components.

[0050] Real-time acquisition of performance metrics of physical resource nodes in private cloud infrastructure; prediction of failure risk probability of different physical resource nodes based on long short-term memory network processing performance metrics; and simultaneous generation of risk heat map of infrastructure.

[0051] A deployment cost matrix representing the deployment of business components on the same physical resource node is generated based on the business weight matrix, and a penalty term is generated based on the risk heat map and the deployment cost matrix is ​​weighted and corrected.

[0052] With the total cost and resource balance of the revised deployment cost matrix as the objectives, an optimization function is constructed and solved to output a deployment strategy scheme;

[0053] Execute the deployment strategy and plan, and after deployment, continuously acquire core business operation data and infrastructure status data, and compare them with the expected indicators of the deployment strategy and plan;

[0054] When the comparison deviation exceeds the preset threshold, update the business weight matrix and risk heat map and re-output the deployment strategy plan.

[0055] Compared with existing technologies, the beneficial effects of this application are: by deeply deconstructing the core business through the business parsing module, a business weight matrix reflecting the communication tightness between business components is dynamically generated, which accurately adapts to the dynamic changes in the operating status of the core business and provides a practical basis for subsequent deployment; the facility perception module processes the performance indicators of physical resource nodes based on the long short-term memory network to predict the probability of failure risk and generate a risk heat map to intuitively present the risk distribution of nodes across the entire domain, thereby reducing the risk of core business deployment.

[0056] The decision-making module generates a deployment cost matrix based on the business weight matrix, and then constructs a penalty term to complete the matrix correction by combining the risk heat map. It constructs and solves an optimization function with the total cost and resource balance as the objectives, so as to achieve a synergistic consideration of business communication needs, deployment costs, facility risks and resource balance. This avoids the limitations of traditional single-objective decision-making. The output deployment strategy can control the overall deployment cost, ensure the balance of resource utilization and the controllability of risks, and achieve the global optimization of core business deployment.

[0057] After executing the deployment strategy, the deployment evolution module continuously monitors the operational data of core businesses and the status data of infrastructure to update the business weight matrix and risk heat map in a coordinated manner, and outputs a new deployment strategy adapted to the new operational status. This enables dynamic optimization of deployment, monitoring, feedback and iteration, adapting to the dynamic changes of core businesses and infrastructure in the long term, ensuring the stability of core business operations and the continuous optimization of resource utilization, and improving the overall adaptability and intelligence level of the deployment of private cloud core business support nodes. Attached Figure Description

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

[0059] Figure 1 A system flowchart of a private cloud core business support node deployment system provided in this application embodiment;

[0060] Figure 2 This is a flowchart illustrating the logic of generating a deployment cost matrix, as provided in an embodiment of this application.

[0061] Figure 3 A logical flowchart of the output deployment strategy scheme provided in the embodiments of this application;

[0062] Figure 4 This is a flowchart illustrating a method for deploying a core business support node in a private cloud, as provided in an embodiment of this application. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of the embodiments of this application more apparent and understandable, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0064] Example 1:

[0065] like Figure 1 The diagram shown is a system flowchart of a private cloud core business support node deployment system provided in this application embodiment. The system includes a business parsing module, a facility awareness module, a decision-making module, and a deployment evolution module.

[0066] This embodiment takes the resource management and allocation business of enterprise private cloud as the application scenario. The core business refers to the resource management business that directly determines the efficiency of private cloud resource scheduling, the stability of business systems and the rationality of resource utilization, and plays a key supporting role in the continuity of enterprise business. The goal of this business is to achieve a precise match between business needs and resource supply, while ensuring the security, balance and efficiency of resource allocation.

[0067] The business analysis module deconstructs core business processes to identify and analyze data flow, call relationships, and transaction associations between business components, and dynamically generates a business weight matrix that reflects the communication tightness between business components.

[0068] Specifically, the dynamic generation of the business weight matrix includes:

[0069] The core business is deconstructed into business components at different functional levels, and the functional attributes and core status of the business components are clarified in order to classify and label the business components.

[0070] Real-time acquisition of communication data between business components; extraction of interaction features including data flow direction, call relationship, interaction frequency and communication latency from the communication data; and parsing of transaction logs of core business to identify transaction relationships between business components.

[0071] The weighting coefficients are determined based on the coreness of the business components and the transactional relationships between them. The initial weights reflecting the communication tightness between the business components are then calculated by combining the weighting coefficients with the interaction characteristics.

[0072] The initial weights are dynamically adjusted based on the operational scenarios of the core business to dynamically generate a business weight matrix.

[0073] The business weight matrix, guided by resource scheduling, quantifies the strength of communication relationships between business components. Without first deconstructing the architecture of resource services and clarifying the impact of each component on resource allocation, subsequent communication data will lack value anchors for resource scheduling. A full-process analysis of resource management and dynamic allocation is conducted, reconstructing the link from the initiation of resource requests by business nodes to the completion and monitoring of resource allocation. Core businesses are decomposed into business components based on their functional responsibilities in resource flow, including request receiving components, status monitoring components, scheduling decision components, allocation execution components, resource reclamation components, and report statistics components. The interruption of each business component is simulated to disrupt resource scheduling, clarifying the functional attributes and core importance of each component. Interruptions to the scheduling decision component and the allocation execution component directly lead to the inability to allocate resources. As core components, the scheduling decision component is responsible for calculating resource allocation schemes, and the allocation execution component is responsible for allocating resources to business nodes.

[0074] Interruptions to the request receiving and status monitoring components will cause scheduling delays but will not directly block allocation. As important components, the request receiving component receives resource requests from business nodes, and the status monitoring component obtains the CPU and memory usage of physical nodes. Interruptions to the resource reclamation and report statistics components can be manually re-processed without affecting real-time scheduling. As auxiliary components, the resource reclamation component reclaims idle resources, and the report statistics component generates resource usage analysis reports. Business components are bound with component identifiers, functional attributes, core status, and physical resource association labels to form classification labels for business components. This clearly defines the boundaries and value levels of each business component in the scheduling chain, avoiding subsequent data acquisition deviations due to overlapping component functions. The labels provide an identification benchmark for business components, ensuring consistent identification of business components.

[0075] The communication tightness between business components is a quantitative reflection of the interaction frequency and business necessity during resource scheduling. The classification and labeling of business components alone cannot reflect the relationship. Based on the classification and labeling of business components, port filtering is used in the private cloud to filter the communication data between business components, eliminate invalid cross-network segment traffic and port scanning traffic, and analyze the communication data to extract interaction features including data flow, call relationship, interaction frequency and communication latency. The data flow is the flow of resource status data from the status monitoring component to the scheduling decision component. The call relationship is the call of the scheduling decision component to the resource mounting interface of the allocation execution component. The interaction frequency is the number of calls between the decision and status monitoring components during peak periods. The communication latency is the time taken from the initiation of the decision instruction to the response of the allocation execution component, so as to form a mapping relationship between business components and interaction features.

[0076] Real-time capture of core business operation logs, with a focus on filtering scheduling logs for resource allocation transactions, and tracing the full-link component call records corresponding to the same transaction. This identifies the transactional relationships between business components: business components that must be called consecutively within the same resource allocation transaction are marked as having strong transactional relationships, such as the scheduling decision component and the allocation execution component, and the status monitoring component and the scheduling decision component; business components that are not called consecutively but have data dependencies are marked as having weak transactional relationships, such as the request receiving component and the scheduling decision component; and business components that have no direct data dependencies but only periodic data synchronization are marked as having non-transactional relationships, such as the resource reclamation component and the report statistics component. This enables the acquisition of data on dynamic interactive behaviors and business transaction logic, providing quantifiable and traceable data for subsequent weight calculations, ensuring that the weights reflect the strength of component relationships during resource scheduling.

[0077] Different interaction characteristics contribute differently to resource scheduling. If equal weights are used, the weights of strongly correlated core components and weakly correlated auxiliary components will be the same, deviating from the requirement of ensuring the core link and resulting in insufficient communication resources for the core link during subsequent resource allocation. Based on coreness, transaction correlation, and interaction characteristics, a weighted coefficient for resource scheduling and transaction correlation is constructed, with the weighted coefficient ranging from [0.1, 1]. For strong transaction correlations between core components, the highest weighted coefficient (value 1) is assigned; for weak transaction correlations between core components and important components, a medium weighted coefficient (value 0.6) is assigned; and for non-transactional correlations between auxiliary components, the lowest weighted coefficient (value 0.1) is assigned. Considering the sensitivity of resource scheduling to interaction characteristics, higher base coefficients are assigned to interaction frequency and communication latency. The base coefficient for interaction frequency is 0.8, reflecting the real-time communication requirement, and the base coefficient for communication latency is 0.7, reflecting the communication stability requirement. Lower base coefficients are assigned to data flow direction and call relationship, with a base coefficient of 0.4 for data flow direction and 0.3 for call relationship.

[0078] Multiply the interaction feature value by the corresponding basic coefficient, and then add the weighted coefficients determined by the transaction correlation and coreness between the business components, performing a second weighted sum to obtain the initial weight W, which reflects the communication tightness between components. ij =w ij ×Σ k (a k ×H ijk ), where business component i and business component j form a business component pair (i,j), k traverses four interaction feature dimensions (k=1 corresponds to interaction frequency, k=2 corresponds to communication delay, k=3 corresponds to data flow direction, k=4 corresponds to call relationship), a k w represents the fundamental coefficient of the k-th interaction feature dimension. ijH is a weighting coefficient determined by the coreity and transaction relevance of business components i and j, taking values ​​[0.1, 1]. ijk The eigenvalues ​​are normalized to [0,1]. For example, the weighted coefficients of the scheduling decision component and the status monitoring component are 1, and the basic coefficients are a1=0.8, a2=0.7, a3=0.4, a4=0.3, respectively. The measured normalized eigenvalues ​​H ij1 =0.9 (interaction frequency), H ij2 =0.85 (communication delay), H ij3 =0.7 (data flow direction), H ij4 =0.6 (call relationship), initial weight = 1×(0.8×0.9+0.7×0.85+0.4×0.7+0.3×0.6)=1.775; This step ensures that the initial weight calculation is integrated into the value orientation of resource scheduling, and the initial weight of each business component pair can be verified through the traceability link, solving the subjectivity problem of weight calculation.

[0079] The operational scenarios for resource allocation fluctuate significantly, and the communication density between business components varies greatly under different operational scenarios. If a fixed initial weight is used, it will be unable to adapt to the demand fluctuations caused by changes in scenarios. The pre-set operational scenarios for resource allocation include peak business expansion scenarios, regular scheduling scenarios, and nighttime idle resource recovery scenarios. Peak business expansion scenarios refer to the situation where multiple business nodes apply for resources in a concentrated manner when a new product is launched, resulting in an abnormal increase in the amount of resource requests. Regular scheduling scenarios refer to the situation where the amount of resource requests is stable during normal working hours. Nighttime idle resource recovery scenarios refer to the situation where idle resources are recovered in a concentrated manner at night. The current operational scenario is automatically matched by obtaining indicators such as the amount of resource requests, the resource utilization rate of physical resource nodes, and the success rate of scheduling transactions.

[0080] Based on scenario requirements, a mapping system is constructed between operational scenarios and initial weight adjustments. During peak business expansion scenarios, the initial weights of two types of business component pairs—scheduling decision components and status monitoring components, as well as scheduling decision components and allocation execution components—are increased to ensure more communication bandwidth and computing resources are allocated during deployment, guaranteeing the real-time nature of scheduling decisions. During nighttime idle resource reclamation scenarios, the initial weights of resource reclamation components and status monitoring components are increased to prioritize reclamation efficiency, while the initial weights of reporting and statistics components and other business components are decreased to reduce the resource consumption of non-core communication. In regular scheduling scenarios, the initial weights remain unchanged. After adjustment, a business weight matrix is ​​output, with each cell indicating the initial weight and adjustment magnitude of the business component pair. This upgrades the business weight matrix from a static baseline to dynamic adaptation, ensuring that the weight results always align with current resource scheduling needs—ensuring core links are protected during peak times and optimizing resource utilization during off-peak times. Targeted adjustments significantly reduce the computing power consumption of weight updates, adapting to the lightweight scheduling requirements of private cloud resources and providing crucial support for the dynamic evolution of the entire deployment system.

[0081] The facility awareness module acquires the performance metrics of physical resource nodes in the private cloud infrastructure in real time, and processes the performance metrics based on the long short-term memory network to predict the failure risk probability of different physical resource nodes, and simultaneously generates a risk heat map of the infrastructure.

[0082] Specifically, generating a risk heatmap for infrastructure includes:

[0083] Real-time acquisition of operational data, full lifecycle data, and environmental correlation data of physical resource nodes in private cloud infrastructure; after preprocessing, performance indicators characterizing the status of physical resource nodes are formed.

[0084] Based on the performance metrics of long short-term memory networks, the failure risk probability of different physical resource nodes is predicted. The propagation risk probability is determined based on the dependency relationship of physical resource nodes in the physical topology of the private cloud, and then weighted and fused with the failure risk probability according to the preset weight to obtain the risk probability.

[0085] By combining the core level of the business components to be deployed with the risk threshold, and based on the physical topology of the private cloud, a risk heat map is generated according to the risk probability.

[0086] Risk heatmaps can accurately reflect the risk status of physical resource nodes. However, the judgment of risk status must rely on comprehensive and reliable node status. If only single data is obtained, potential risks such as equipment aging and abnormal environmental temperature and humidity will be missed. If the data is used directly without processing, abnormal data caused by sensor failure and format conflicts of data from different sources will make subsequent risk analysis lose its accurate basis and will not be able to form effective performance indicators to characterize the node status. Taking the physical servers, storage devices and core switches of the private cloud data center as monitoring objects, the system acquires the operational data, full life cycle data and environmental correlation data of the physical resource nodes in the private cloud infrastructure in real time. The operational data is acquired in real time through monitoring, covering the computing load, memory usage, disk read and write status and data transmission capacity of physical servers, the read and write response efficiency of storage devices, and the port data loss of core switches.

[0087] Full lifecycle data is extracted from the private cloud's operation and maintenance management system, including equipment procurement information, historical fault records, maintenance status, and firmware update history. Environmental data is acquired through temperature and humidity sensors and power supply monitoring modules deployed in the data center, including the temperature, humidity, and power supply stability of the cabinet where the node is located. Abnormal data, such as instantaneous environmental changes caused by sensor failures, is cleaned and removed. Data of different formats is uniformly converted into structured information containing status descriptions and change trends to form performance indicators characterizing the status of each physical resource node. This comprehensively covers the three types of risk-related data: operation, full lifecycle, and environment, ensuring the consistency and reliability of the input data for subsequent risk analysis.

[0088] Risk heatmaps require quantitative data support, but single-fault risk assessment has significant limitations. There are clear dependencies between physical resource nodes, and assessing the fault risk of only a single node will ignore the problem of risk propagation and diffusion through dependent links. The performance indicators of each physical resource node are input into a trained Long Short-Term Memory network. This network has been trained with historical fault data and can identify the correlation between performance indicator changes and fault occurrence. By analyzing the real-time status and trend of performance indicators, the fault risk probability of different physical resource nodes can be determined. For example, servers with stable performance indicators are predicted to have low fault risk, while switches with port packet loss, old equipment, and high humidity are predicted to have high fault risk.

[0089] The structure of the Long Short-Term Memory (LSTM) network is as follows: The input layer receives a 12-dimensional performance index vector, including processor load, memory usage, disk read / write speed, network bandwidth utilization, hardware operating temperature, power supply stability, equipment age, historical failure count, firmware version, ambient temperature, ambient humidity, and port packet loss rate. It includes two hidden layers, each with 64 LSTM units. The output layer is a fully connected layer with a Sigmoid activation function to output the failure risk probability in the range [0,1]. The loss function is the binary cross-entropy loss function, and the optimizer uses the Adam algorithm (learning rate 0.001). The training data comes from the historical performance indexes and failure records of the private cloud management system for the past 3 years, totaling approximately 50,000 samples. The ratio of the training set to the validation set is 8:2. Training stops when the validation set loss no longer decreases after 10 consecutive rounds.

[0090] Based on the physical topology of the private cloud, the dependencies between physical resource nodes are labeled, such as the links between the core scheduling server and the backup server, and between the server and the core switch. Combined with the performance indicators of the physical resource nodes, the probability of propagation risk (CRP) is determined. m =1-Π n (1-R n ×D mn ), R n D represents the failure risk probability of node n, which has a direct dependency on node m.mn Let be the dependency strength coefficient between node m and node n. The dependency strength coefficient for primary / standby redundancy is 0.8, for switch association is 0.5, for power supply association within the same rack is 0.3, and for cross-rack no-direct-association dependency is 0.1. n Iterate through all nodes that have a direct dependency on node m; CRP m The probability of transmission risk for node m is denoted by , which takes the value [0,1]. The higher the value, the greater the risk of being affected by the transmission of failures of associated nodes. If a high-risk node m has direct dependencies on multiple nodes, the probability of transmission risk increases accordingly.

[0091] Preset weights are assigned based on the focus of the business scenario. Nodes directly supporting core scheduling operations have a higher preset weight for fault risk probability; network transmission nodes have a higher preset weight for propagation risk probability. The risk probability RP is obtained by combining the risk assessment results with the preset weights. m =α×FRP m +(1-α)×CRP m FRP m To predict the failure risk probability of physical resource node m using LSTM, CRP m To transmit the probability of risk, α is a preset weight; for nodes that directly support core scheduling services, α=0.6; for network transmission nodes, α=0.4; for ordinary computing nodes, α=0.5; thus, by transmitting risk analysis, the potential risks between nodes are covered, making the risk assessment fit the actual operating logic of the private cloud and ensuring that the risk assessment results are closely related to the business needs of resource scheduling.

[0092] Risk heatmaps are used to guide business deployment and resource scheduling. However, business components of different core levels have varying tolerances for node risks. Deploying core components on high-risk nodes can affect business continuity, while auxiliary components can tolerate risks more readily. Using a uniform threshold would not meet the deployment needs of different business components. The system retrieves the classification labels of business components and matches risk thresholds to components of different core levels. Core components are fitted with low-risk thresholds, with a risk probability not exceeding 0.15, and are only allowed to be deployed on physical resource nodes with low risk probabilities. Important components are fitted with medium-risk thresholds, with a risk probability not exceeding 0.4. Auxiliary components are fitted with higher-risk thresholds, with a risk probability not exceeding 0.7. Based on the physical topology of the private cloud, the system labels the risk probability and risk threshold at the location of each physical resource node, using dashed lines to mark the risk propagation links, clearly showing the potential impact of high-risk nodes on related nodes.

[0093] The risk levels of nodes are marked using a three-color gradient of red, yellow, and green. Red represents high-risk nodes whose risk exceeds the corresponding risk threshold, yellow represents medium-risk nodes that are at the critical state of the risk threshold, and green represents low-risk nodes that meet the risk threshold. Threshold warning boxes are superimposed on the areas where core components are deployed to clearly indicate the maximum allowable risk threshold for that area, forming a risk heat map that integrates physical topology, coreness, risk transmission links, and risk thresholds. This achieves a deep binding between the risk heat map and business deployment requirements, enabling the risk heat map to guide the matching decisions between business components and physical resource nodes, intuitively identify high-risk areas and their impact range, and provide a basis for risk avoidance during resource scheduling.

[0094] The decision-making module generates a deployment cost matrix representing the deployment of business components on the same physical resource node based on the business weight matrix. It generates a penalty term based on the risk heat map and weights and corrects the deployment cost matrix. With the total cost and resource balance of the corrected deployment cost matrix as the objective, it constructs and solves the optimization function and outputs a deployment strategy scheme that includes the mapping relationship between business components and physical resource nodes.

[0095] Furthermore, such as Figure 2 As shown, the generated deployment cost matrix includes:

[0096] The core level of the business components, the transactional relationships between business components, and the interaction characteristics of communication data are called. Combined with the risk threshold corresponding to the core level of the business components to be deployed, the deployment constraints of business components, including resource exclusivity, transactional coordination, and communication requirements, are marked.

[0097] Based on the business weight matrix, cost factors for resource competition cost, transaction coordination cost and communication cost are constructed. Dynamic weights are assigned to the cost factors and weighted calculation is performed in combination with deployment constraints to form the initial deployment cost between business components deployed on the same physical resource node.

[0098] Adjust the initial deployment cost based on the core business operation scenarios and integrate them to generate a deployment cost matrix.

[0099] The deployment cost matrix is ​​used to quantify the cost of business deployment, and the composition of the cost is directly constrained by the operational requirements and risk thresholds of the business components. The coreness of the business components, the transactional relationships between business components, the interaction characteristics, and the risk thresholds of the business components are used to mark deployment constraints including resource exclusivity, transactional coordination, and communication requirements. Because core components need to ensure operational stability, they are marked as resource exclusivity, meaning they need to independently occupy a portion of hardware resources and not share them with other core components. Auxiliary components are marked as resource sharing, meaning they can share idle resources with similar components. For business component pairs with strong transactional relationships, mandatory collaborative deployment is marked, requiring deployment on the same or adjacent low-latency nodes to ensure the continuity of the transaction chain. Business component pairs with weak transactional relationships are marked as elastic coordination, meaning they can be deployed in a distributed manner.

[0100] For business component pairs that are sensitive to communication latency, they are marked as low-latency communication and must be deployed on physical resource nodes with short network links. Non-real-time communication component pairs are marked as ordinary communication, with no mandatory requirements on link latency. Deployment constraints are then bound to component identifiers to form an association between business components and deployment constraints, and the business basis for the deployment constraints is marked. For example, the resource exclusivity constraint for scheduling decision components is based on ensuring that there is no resource contention for core scheduling. This step ensures that subsequent costs always revolve around ensuring the operation of core businesses and meeting transaction coordination requirements, and allows cost calculation to be located at the component combination, providing a constraint basis for subsequent cost calculations between business components on the same physical resource node.

[0101] Once deployment constraints are clearly defined, these abstract constraints need to be transformed into quantifiable cost factors. Different deployment constraints have varying degrees of impact on these cost factors. Calculating the initial deployment cost directly using a fixed ratio ignores the business logic where core components have higher constraints than auxiliary components, resulting in the initial deployment cost failing to reflect business value orientation. Based on a business weight matrix and deployment constraints as weights, the initial deployment cost is constructed and calculated. Based on the communication tightness between business components in the business weight matrix and the characteristics of each business component, the cost factors are broken down into resource competition cost, transaction coordination cost, and communication cost. Resource competition cost reflects the degree of competition for resources among business components on the same physical resource node. Business components with high communication tightness and belonging to the same core component have higher resource competition requirements. Transaction coordination cost reflects the coordination cost arising from transactional relationships between business components. If strongly transactionally related components are deployed on different physical resource nodes, transaction coordination costs will arise due to data synchronization; deployment on the same physical resource node reduces transaction coordination costs.

[0102] Communication cost reflects the network overhead of communication between business components. For business component pairs that are sensitive to communication latency or have high interaction frequency, the communication cost is high when deployed across nodes, and low when deployed within the same node. Dynamic weights are assigned based on the association between business components and deployment constraints. The dynamic weights range from [0.1, 1]. The dynamic weight of the resource competition cost of core components (value 0.8) is higher than that of important components (value 0.5) and auxiliary components (value 0.2). The dynamic weight of the transaction coordination cost of strongly transaction-related components (value 0.7) is higher than that of weakly transaction-related components (value 0.4) and non-transaction-related components (value 0.1). The dynamic weight of the communication cost of communication latency-sensitive business component pairs (value 0.9) is higher than that of ordinary business component pairs (value 0.3). The sum of the dynamic weights of the three cost factors after normalization is 1.

[0103] For each pair of service components planned to be deployed on the same physical resource node, the initial deployment cost of the service component pair on the target node is calculated; the initial deployment cost is calculated based on the IDC (Internet Data Center) value. ij =W R ×RCC ij +W T ×TCC ij +W C ×CCC ij Resource competition cost (RCC) ij =W matrix_ij ×(Q cpu,i +Q cpu,j ) / C cpu Q cpu,i Q cpu,j W represents the CPU resource requirements of business components i and j, respectively. matrix_ij C represents the communication tightness between business components i and j in the business weight matrix. cpu Total CPU capacity of the target physical resource node; Transaction Coordination Cost (TCC) ij =T assoc_ij ×H ij2 T assoc_ij Let T be the transaction correlation coefficient between business components i and j, and T be the strong transaction correlation coefficient. assoc =1, Weak Transaction Association T assoc =0.5, non-transactional association T assoc =0.1.

[0104] Communication cost CCC ij =H ij2 ×H ij1 H ij2 H represents the normalized communication delay value between service components i and j; ij1 W represents the normalized interaction frequency value between business components i and j. R W T WC These are the normalized dynamic weights of resource competition cost, coordination cost, and communication cost, respectively, with values ​​ranging from [0.1, 1], determined by the deployment constraints of the business components. The W of the core component... R A value of 0.8 is higher than that of important components (0.5) and auxiliary components (0.2); the W value for strongly transaction-related components... T A value of 0.7 is higher than 0.4 for weak transaction associations and 0.1 for non-transactional associations; W is a parameter for communication latency-sensitive service component pairs. C The value of 0.9 is higher than that of 0.3 for ordinary business components, and the sum of the three weights after normalization is 1. This step is in line with the business logic of private cloud resource scheduling, so that the initial deployment cost accurately reflects the business priority and provides a benchmark for subsequent cost optimization.

[0105] The operational scenarios for resource allocation vary significantly, and the priority requirements for cost factors differ across these scenarios. If a fixed initial deployment cost is used to generate the deployment cost matrix, the matrix will fail to adapt to scenario fluctuations and lose its guiding value for deployment decisions. Therefore, a deployment cost matrix is ​​dynamically adjusted and integrated based on the initial deployment cost and the operational requirements of core business scenarios. When a sudden surge in resource requests is identified as a peak expansion scenario, the dynamic weights of communication costs and transaction coordination costs are increased to prioritize ensuring the real-time communication and transaction continuity between core components, while appropriately reducing the dynamic weight of resource contention costs. When resource requests are stable and identified as a normal scheduling scenario, the dynamic weight of the initial deployment cost remains unchanged.

[0106] When low resource utilization is identified as a nighttime idle recovery scenario, the dynamic weight of resource competition costs is increased to prioritize the integration of idle resources, while the dynamic weight of communication costs is reduced. The initial deployment cost is dynamically weighted and optimized based on the current operating scenario to obtain the scenario deployment cost. A deployment cost matrix is ​​constructed with physical resource nodes as rows and business component pairs as columns. The scenario deployment cost of each business component pair on the corresponding physical resource node is filled into the matrix cells to generate the deployment cost matrix. Scenario-based adjustments transform the deployment cost matrix from a static baseline to a dynamically adaptable one, ensuring that the deployment cost matrix always remains consistent with current business needs.

[0107] Specifically, the weighted adjusted deployment cost matrix includes:

[0108] The risk probability of physical resource nodes constitutes the fault penalty item, the coreness of the business component constitutes the business penalty item, the deployment constraints of the associated business component constitute the deployment penalty item, and the penalty items are generated by weighting and integrating them according to a preset ratio.

[0109] Based on the transactional relationships between business components, the dependencies between physical resource nodes, and the operational scenarios of core businesses, coupling weights are assigned to penalty terms.

[0110] The deployment cost matrix is ​​then adjusted by layering and weighting based on the combination of business components and physical resource nodes, combined with coupling weights, and the adjusted deployment cost matrix is ​​then normalized and calibrated.

[0111] The deployment cost matrix only quantifies three explicit costs: resource competition, transaction coordination, and communication. It does not cover implicit costs such as failure costs caused by node risks, loss costs due to differences in the coreness of business components, and adaptation costs due to constraint violations. If these are directly used for optimization, deployment schemes with low explicit costs but high risks and high constraint violations may be misjudged as optimal. To address this, we retrieve the risk probability of each physical resource node, the coreness of business components, and the relationship between business components and deployment constraints. Corresponding penalty items are generated for each. Failure penalty items are constructed based on the risk probability of physical resource nodes. High-risk nodes, due to their high risk probability, have high failure penalty levels for deploying business components. For example, core switches have a high risk probability, so any business component deployed there will have a high failure penalty level. Low-risk nodes have low failure penalties, directly binding to the risk status of physical resource nodes. Similarly, business penalty items are constructed based on the coreness of business components. Failures or constraint violations of core components directly cause resource scheduling service interruptions and are set to high business penalties. Failures of important components only affect scheduling efficiency and are set to medium business penalties. Failures of auxiliary components can be delayed and are set to low business penalties, fully reflecting the differences in business value.

[0112] Deployment constraints of related business components constitute deployment penalty items. If scheduling decision and status monitoring components with strong transactional relationships are deployed on non-adjacent nodes, or if core components share resources with other core components, it is considered a violation of deployment constraints and is set as a high deployment penalty. Cases that meet deployment constraints but are close to the critical value are set as medium deployment penalties, and cases that fully meet deployment constraints are set as low deployment penalties. The three types of penalty items are weighted and integrated according to a preset ratio: 0.4 for fault penalty items, 0.35 for business penalty items, and 0.25 for deployment penalty items. This forms the penalty items corresponding to the combination of each business component and the physical resource node, and the triggering reason of the penalty item is marked. For example, a high penalty corresponds to a high risk of physical resource node and the deployment of core components. In this way, risk loss, business interruption cost, and constraint adaptation cost are included in the cost system, making the quantification of deployment costs more in line with the actual operational logic of private cloud deployment, and providing a precise and traceable correction basis for subsequent layered corrections.

[0113] The priority of the impact of faults, business operations, and deployments in the penalty items is not fixed. Their weight ratios need to be dynamically adjusted according to the transactional relationships between business components, the dependencies of physical resource nodes, and the operating scenarios of core businesses. If a fixed weight allocation is adopted, the focus of correction will deviate from the actual risks and business needs, reducing the adaptability of the deployment cost matrix to different operating scenarios. The transactional relationships between business components, the dependencies of physical resource nodes, and the operating scenarios of core businesses are retrieved. Coupling weights are allocated according to the principle of operating scenario dominance and correlation strength as an auxiliary factor. In peak expansion scenarios, the collaborative deployment of strongly transactionally related components directly affects scheduling efficiency, so the coupling weight of deployment penalty items is increased. At the same time, the risk of faults increases due to high load on physical resource nodes, so the coupling weight of fault penalty items is appropriately increased.

[0114] In emergency fault scenarios, the risk transmission effect of physical resource nodes is significant. Therefore, it is crucial to increase the coupling weight of fault penalty items, especially the coupling weight of fault penalty items for core nodes. In regular scheduling scenarios, coupling weights are allocated based on the strength of transaction association. The coupling weight of deployment penalty items for strongly associated component combinations is higher than that for weakly associated combinations, and the coupling weight of fault penalty items for core nodes is higher than that for ordinary nodes. Then, the allocated coupling weights are bound to the combination of business components, physical resource nodes, and penalty items, forming a mapping of associations between combinations, nodes, penalty items, and weights. The scenario and basis for weight allocation are also labeled. This achieves a deep binding between the coupling weight of penalty items and the operational scenario of core business and the associated logic of business components, making cost adjustments more aligned with the dynamic operational needs of private cloud resource scheduling. The basis for coupling weight allocation is traceable, enhancing the interpretability of the adjustment process.

[0115] The required correction accuracy differs fundamentally between different business component combinations and physical resource node types. A uniform correction approach would lead to insufficient accuracy in core component combinations or inefficient correction in auxiliary component combinations. Furthermore, the different quantification dimensions of deployment costs and penalty items result in data incomparability when directly superimposed, making them unsuitable for subsequent optimization function solutions. Therefore, a layered correction and normalization calibration process is implemented based on the correlation mapping between deployment cost matrices, combinations, nodes, penalty items, and weights. Layered weighted correction divides the correction levels according to the combination of business components and physical resource nodes. High-precision correction is used when core component combinations are deployed on core nodes. The matching relationship between each business component combination and physical resource node is checked one by one, retrieving the corresponding penalty item and coupling weight. The penalty item is then calculated based on the coupling weight and superimposed on the deployment cost. Batch correction is used when auxiliary component combinations are deployed on ordinary nodes. The same weighting rules are reused for combinations of the same type of business components and physical resource nodes of the same level, completing the batch superposition of deployment costs.

[0116] After correction, normalization calibration begins. Employing a business value-driven calibration logic, the corrected deployment cost of core component combinations deployed on optimal low-risk nodes is used as the benchmark. The corrected deployment costs of all business component combinations and physical resource nodes are converted into relative cost coefficients within a unified range, eliminating data incomparability issues caused by different quantitative dimensions such as resource occupancy and risk probability. The normalized calibration result is NC. ij =(DC ij -DC min ) / (DC max -DC min ), where DC ij DC represents the revised deployment cost of the business component (i,j) on the physical resource node. min DC is the minimum of all revised deployment costs. max The maximum of all revised deployment costs; NC ij The normalized relative cost coefficient reflects the relative cost level of the business component deployed on the physical resource node, with a value of [0,1]. Finally, the corrected deployment cost matrix is ​​output. Layered correction ensures the correction accuracy of the running scenario and the correction efficiency of the auxiliary running scenario, avoiding resource waste. Normalization calibration solves the problem of incomparability of data in different dimensions, so that the corrected deployment cost matrix has a unified quantitative standard. The annotation of the correction basis enhances the feasibility of the deployment cost matrix, making it easier for operation and maintenance personnel to understand the cost composition and providing a clear reference for subsequent deployment decisions.

[0117] Specifically, such as Figure 3 As shown, the output deployment strategy scheme includes:

[0118] With the total cost and resource balance of the revised deployment cost matrix as the target, the target priority of total cost and resource balance is dynamically adapted based on the operation scenario of the core business and the coreness of the business components.

[0119] Constraints are formed by combining transactional relationships between business components, deployment constraints, and penalty terms, and then embedded into objectives. Optimization functions are constructed by combining objective priorities.

[0120] The communication cost is processed by clustering algorithm to cluster business components into component clusters. Physical resource nodes are pre-matched for component clusters based on risk heat map, and the optimization function is solved based on genetic algorithm.

[0121] The solution results are verified based on risk thresholds and cost factors. Once the verification is successful, a deployment strategy scheme including the mapping relationship between business components and physical resource nodes is output.

[0122] The core of the optimization function is to clarify the optimization direction. There is a natural trade-off between minimizing total cost and maximizing resource balance. If a fixed priority is adopted, it will lead to deviations in the adaptation of the solution to the operating scenario. For example, if cost control is prioritized during peak business expansion, scheduling interruptions will occur due to overload of core nodes. If resource balance is prioritized during idle recovery at night, it will lead to resource waste. The revised deployment cost matrix, the operating scenario of the core business, and the coreness of the business components are retrieved to dynamically set the target priority. In peak expansion scenarios, the load of core nodes is prone to exceed the limit. It is necessary to prioritize ensuring resource balance to avoid scheduling interruptions. The target priority of resource balance is set higher than that of total cost, and the resource balance in core components is further improved.

[0123] In nighttime idle recycling scenarios, resource utilization is low, and total cost control should be prioritized to drive resource integration. That is, the target priority of total cost is higher than resource balance, and the total cost of auxiliary components is further increased. In regular scheduling scenarios, the target priorities of both are taken into account, and the target priorities are allocated according to the differentiated principle of prioritizing resource balance for core components and total cost for auxiliary components. This clarifies the optimization orientation of each business component pair, thereby avoiding the imbalance of deployment schemes caused by a single orientation. It ensures that the optimization direction is always matched with the business operation status and the value of business components, so as to ensure the stable operation of core business and take into account the cost optimization of auxiliary business.

[0124] The optimization function is the core function for solving deployment strategy solutions. Simply specifying the target priority is insufficient to generate feasible solutions. Without embedded constraints, the solution will violate business logic, rendering the deployment strategy unworkable. Using the target priority as the core, the optimization function integrates transactional relationships between business components, deployment constraints, and penalty terms to form constraints. The total cost and resource balance after dynamic adaptation are used as the core objectives of the optimization function, and weights are allocated according to the target priority and incorporated into the optimization function. The optimization function is F. deploy =λ1×C total +λ2×(1-E balance )+ΣP constraint C total E represents the total cost of matching all business components with physical resource nodes in the corrected deployment cost matrix. balance For resource balance, E balance = 1 - (Maximum node load - Minimum node load) / Average node load, with a value of [0, 1]. A value of 1 indicates perfect load balance. constraintTo constrain the penalty for violations, λ1 and λ2 are weight coefficients determined by the target priority. During peak expansion scenarios, λ1=0.3 and λ2=0.7; during nighttime idle scenarios, λ1=0.7 and λ2=0.3; and during normal scenarios, λ1=0.5 and λ2=0.5. The constraints include that strongly transaction-related components must be deployed on the same or adjacent nodes, and core components must satisfy resource exclusivity and be deployed on nodes with a risk probability lower than the risk threshold.

[0125] Constraints are embedded into the optimization function. Strongly transactional components must satisfy the constraint of mandatory deployment on the same or adjacent nodes, while weakly transactional components must satisfy the constraint of flexible deployment. Core components must satisfy the constraints of resource exclusivity and deployment on low-risk nodes, while auxiliary components must satisfy the constraint of resource sharing. Penalty terms are embedded as the cost of constraint violation. If the solution result violates the constraint, the corresponding penalty term is triggered, increasing the cost, thus forming a complete optimization function. The business meaning of each parameter in the optimization function is marked. For example, the parameter of resource balance reflects the degree of difference in node load. This ensures that the optimization function has both optimality orientation and feasibility constraint, giving the optimization function the ability to quantify constraints and guiding the solution process to converge in a direction that meets the constraints.

[0126] Directly solving the optimization function for all combinations of business components and physical resource nodes will result in excessive computing power consumption and low solution efficiency due to the large number of combinations. Furthermore, the lack of prior screening will lead to ineffective combination traversal in the solution process. By retrieving the interaction characteristics of communication data and the corrected deployment cost matrix, and using the lowest communication cost as the clustering objective, the K-means clustering algorithm is employed to cluster all business components. The value of K is determined using the silhouette coefficient method, and the search range of K is [2, N represents the total number of business components. The K value is selected when the contour coefficient is maximized. Euclidean distance is used as the distance metric. The K-means++ method is used to initialize the cluster centers. The maximum number of iterations is 100. The convergence criterion is that the change in cluster centers is less than 0.001. Business components that are sensitive to communication latency and have high interaction frequency are clustered into core clusters. Important components and auxiliary components with weak correlations are clustered into ordinary clusters. Independent auxiliary components are clustered into independent clusters to form component clusters and label the core constraints of the component clusters. For example, the core cluster is characterized by low latency and low risk.

[0127] Based on the risk heatmap, physical resource nodes are pre-matched to component clusters. Core clusters prioritize low-risk, high-configuration physical resource nodes, such as core server clusters; ordinary clusters match medium-risk, moderately configured physical resource nodes; independent clusters match idle or low-load physical resource nodes, excluding high-risk and high-load nodes to narrow the scope of the solution. Finally, using the pre-matching results as the initial solution, a genetic algorithm is employed to solve the optimization function. The matching relationship between component clusters and physical resource nodes is used as chromosomes, and iterative optimization is achieved through selection, crossover, and mutation operations. The genetic algorithm parameters are: population size 50, maximum number of generations 200, crossover probability 0.8, mutation probability 0.1, roulette wheel selection, and the fitness function is the optimization function F. deploy The reciprocal of F, i.e., 1 / F deploy The iteration terminates when the change in optimal fitness is less than 0.001 for 20 consecutive generations or when the maximum number of iterations is reached.

[0128] Each iteration calculates fitness based on target priority. For example, in peak expansion scenarios, solutions with better balance have higher fitness. After iteration until fitness stabilizes, the solution results are output, which is the initial mapping relationship between component clusters and physical resource nodes. This step integrates scattered business components into component clusters, significantly reducing the number of variables to be solved and reducing computing power consumption. Physical resource nodes are selected based on risk heatmaps and configurations to improve solution efficiency. Iterative optimization of the genetic algorithm ensures that the results fit the target priority, balancing cost and balance.

[0129] The genetic algorithm's solution may have a local optimum, meaning it satisfies the optimization function objective but violates actual operational constraints or has potential risks. The risk thresholds of business components, the corrected deployment cost matrix, and the correlation between business components and deployment constraints are retrieved. The initial mapping relationships are verified one by one. Risk verification focuses on the core cluster, checking whether the risk probability of matching physical resource nodes is less than the risk threshold. The risk of deploying physical resource nodes in the core cluster must not exceed the low-risk threshold, and the risk in ordinary clusters must not exceed the medium-risk threshold. Cost verification checks whether the total cost of deploying each component cluster meets the scenario expectations; in nighttime idle recovery scenarios, the total cost must not exceed the benchmark value. Constraint verification checks whether the component cluster deployment meets core constraints, such as whether the core cluster satisfies resource exclusivity and whether strongly transaction-related components are deployed on adjacent nodes.

[0130] If the verification passes, the output includes a deployment strategy scheme that maps business components to physical resource nodes, clearly defining the correspondence between each business component and a physical resource node. If the verification fails, the process is fed back to the clustering pre-matching stage to adjust the component cluster division or the range of pre-matched nodes, and the solution and verification process is re-executed until it passes and is output. This step ensures that the output deployment strategy scheme meets the optimization function objective and complies with the risk control and constraint requirements of actual operation. The backtracking adjustment when the verification fails improves the feasibility of the deployment strategy scheme and directly supports the dynamic evolution closed loop of the entire private cloud deployment system.

[0131] The deployment evolution module executes the deployment strategy and plan. After deployment, it continuously acquires the core business operation data and infrastructure status data, compares them with the expected indicators of the deployment strategy and plan, and updates the business weight matrix and risk heat map and re-outputs the deployment strategy and plan when the comparison deviation exceeds the preset threshold.

[0132] Specifically, the deployment strategy includes:

[0133] Before deployment, the component cluster is verified by combining real-time updated risk heat maps and deployment constraints to determine whether backup nodes are matched based on the dependencies of physical resource nodes.

[0134] Based on the core nature of the business components and the division of component clusters, deployment is carried out in the hierarchical order of core assurance layer, business support layer and auxiliary operation and maintenance layer, and the deployment cost of physical resource nodes is controlled based on the revised deployment cost matrix.

[0135] After deployment, continuously acquire operational data of core businesses, status data of infrastructure, and trends in risk heatmaps to predictively adjust the deployment location of business components;

[0136] The system receives operational data from core business operations and status data from infrastructure, compares them with the expected metrics of the deployment strategy, and updates the business weight matrix and risk heat map and re-outputs the deployment strategy when the comparison deviation exceeds a preset threshold.

[0137] The deployment strategy is based on historical and recent data. However, the risk status of private cloud physical resource nodes fluctuates in real time. If the original plan is followed directly, the core cluster will be deployed on a high-risk node, and the failure of the primary physical resource node will cause service interruption. The latest updated risk heat map is retrieved to focus on the real-time risk probability of the primary physical resource node to be deployed in the core cluster. At the same time, the correlation between business components and deployment constraints is retrieved. The matching relationship between component clusters and primary physical resource nodes is double-checked. On the one hand, it is checked whether the risk probability of the primary physical resource node meets the corresponding risk threshold. On the other hand, it is checked whether the primary physical resource node meets the deployment constraints, such as the resource exclusivity requirement of the core cluster. If the risk probability of the primary physical resource node does not exceed the standard and meets the deployment constraints, the primary physical resource node is directly locked.

[0138] If the risk probability of the primary physical resource node approaches the critical value or there is a temporary warning, based on the dependency relationship of the physical resource nodes, a backup node with a redundant link to the primary physical resource node is matched to ensure that the backup node has the same resource configuration as the primary physical resource node and a lower risk probability, and that the communication latency between the two meets the constraints; the primary physical resource node and the backup node are bound to the component cluster, and the activation trigger conditions of the backup node are marked, such as the risk probability of the primary physical resource node exceeding the risk threshold and the node load exceeding the standard; thereby reducing the risk of business interruption due to sudden failure of the primary physical resource node and improving the risk resistance of the deployment strategy.

[0139] The business value and deployment urgency of different business components vary significantly. Disorderly deployment can lead to resource occupation during the deployment of core components, affecting business startup efficiency. Furthermore, failure to manage costs in real time during deployment can result in total costs exceeding expectations due to over-allocation of resources. Therefore, the hierarchical order of business components is clearly defined based on their core importance and the division of component clusters. The core assurance layer includes core components such as scheduling decision-making components and allocation execution components; the business support layer includes important components such as request receiving components and status monitoring components; and the auxiliary operation and maintenance layer includes auxiliary components such as resource reclamation components. Deployment is initiated in the hierarchical order of core assurance layer → business support layer → auxiliary operation and maintenance layer. Core components are first deployed to the locked primary physical resource node, and exclusive resource permissions are configured to ensure that no other components occupy core resources.

[0140] After the core components are deployed and verified to be running normally, the business components of the business support layer are deployed next, prioritizing idle resources of the core assurance layer nodes or adjacent low-latency nodes to meet transaction coordination constraints. Finally, the business components of the auxiliary operation and maintenance layer are deployed, reusing remaining idle resources to achieve resource sharing. During the deployment process, the revised deployment cost matrix is ​​retrieved in real time to monitor the deviation between the actual deployment cost of each layer of components and the preset cost of the matrix. If the deployment of auxiliary operation and maintenance layer components causes the cost of a node to exceed the standard, it is promptly adjusted to other low-load nodes. This step ensures that the core business components are deployed first and occupy high-quality resources, ensuring the rapid start-up and stable operation of resource scheduling services. Real-time deployment cost monitoring avoids cost overruns caused by over-allocation of resources, achieving accurate matching between deployment costs and the deployment cost matrix, taking into account both business needs and cost optimization.

[0141] After deployment, the private cloud's operating environment will dynamically change. Passive adjustments after a failure can lead to business interruptions or performance degradation. The process involves acquiring core business operation data, infrastructure status data, and risk heatmap trends. Core business operation data includes scheduling decision response time and resource allocation success rate. Infrastructure status data includes CPU / memory load, communication latency, and hardware operating temperature for each node. Risk heatmap trends include node risk level increases / decreases and risk area spread. Trend analysis is performed on the data. If the load of physical resource nodes in the core protection layer shows a continuous upward trend, it is predicted that resource overload constraints will be triggered in the future. Some auxiliary operation and maintenance layer business components are migrated to idle nodes in advance to free up resources for the core protection layer. If the risk heat of a physical resource node in a business support layer increases, it is predicted that it will reach the risk threshold. The component cluster on that node is migrated to a matching backup node in advance. During the adjustment process, the principle of prioritizing core cluster protection and ensuring that adjustments do not affect business operations is followed. A gradual switchover using a gray-scale migration method is adopted to avoid interruptions. This step significantly reduces the probability of business interruption and performance loss. The gray-scale migration method ensures business continuity during the adjustment process, achieving the goal of dynamic adjustments without affecting operation.

[0142] While predictive adjustments can mitigate most potential risks, omissions or sudden significant changes may still occur. The solution involves retrieving expected metrics from the deployment strategy, such as core cluster scheduling response time, node load limits, and risk thresholds. Continuously acquired core business operational data and infrastructure status data are then compared against these expected metrics. Analysis of the comparison results reveals that if core business operational data exceeds expected metrics, infrastructure status data consistently exceeds the expected metric limit, or the node risk probability in the risk heatmap exceeds the risk threshold, the comparison deviation is considered to exceed a preset threshold. Specifically, the preset thresholds for various expected metrics are: a core cluster scheduling response time deviation threshold of 120% of the expected value; a node load deviation threshold of 110% of the expected upper limit; a risk probability deviation threshold of 10% exceeding the corresponding risk threshold; and a resource allocation success rate deviation threshold of 90% below the expected value.

[0143] If any indicator exceeds its corresponding threshold, it is determined that the comparison deviation exceeds the preset threshold, triggering the update process. Based on the operational data, the business weight matrix is ​​recalibrated and updated, such as adjusting the communication density weight of the core cluster and updating the risk heat map based on the latest risk status. The updated business weight matrix is ​​then input into the policy generation process, which re-outputs a deployment policy scheme adapted to the current status, synchronously overriding the original scheme and initiating a new round of deployment execution. This step ensures the accurate triggering of the deployment policy scheme update, accurately adapts to the current business needs and infrastructure status, realizes the dynamic evolution of the deployment policy scheme, and forms a complete closed loop of deployment execution, monitoring, adjustment, and update optimization for the entire private cloud deployment system.

[0144] Furthermore, updating the business weight matrix includes:

[0145] Based on the type of comparison deviation and the core nature of the business components, the update range of the business weight matrix is ​​determined, and an adjustment data pool is constructed using interaction characteristics, changes in the deployment location of business components, and operational data of core businesses and status data of infrastructure to label the deviation attribution of the comparison deviation.

[0146] Based on the deviation attribution marked in the adjusted data pool, the weighting coefficients are dynamically adapted and the initial weights are corrected. In combination with the operation scenarios of the core business, the initial weights between business components in the adjusted data pool are updated in a hierarchical manner according to the order of core assurance layer, business support layer and auxiliary operation and maintenance layer.

[0147] Verify the compatibility of the updated business weight matrix with the deployment cost matrix and the clustering logic of the component cluster, and iteratively optimize the weighting coefficients based on the verification results.

[0148] If the business weight matrix adopts a full update mode, it will not only generate computing power redundancy due to the invalid calculation of irrelevant nodes, but also cause the weight focus between core components to be obscured due to the excessive dispersion of weight information. In fact, different types of comparison deviations have different impact ranges on the initial weights, and the related links for weight adjustment are also different for business components of different core levels. The interaction deviation of core components involves the initial weights of multiple related components, while the slight operational deviation of auxiliary components usually only affects the weights of themselves and directly interacting components. It is necessary to clarify the types of comparison deviations, such as abnormal interaction delays between core components, decreased transaction collaboration efficiency of auxiliary components, and changes in communication links after component deployment and migration.

[0149] The core importance of each business component is determined, clarifying its importance and the direct and indirect relationships between interacting components. If the discrepancy originates from core support layer components, such as increased interaction latency between scheduling decision components and status monitoring components, the update scope should cover the business component pair and directly interacting allocation execution components, as well as indirectly related backup scheduling components, since the interaction weight of such components directly affects the core scheduling link. If the discrepancy belongs to auxiliary operation and maintenance layer components, such as slight fluctuations in the collaborative efficiency between reporting statistics components and resource recovery components, the update scope should be limited to these two sets of business components and directly interacting physical resource nodes.

[0150] An adjustment data pool is constructed with the update scope as the boundary to acquire interaction characteristics, changes in the deployment location of business components, core business operation data, and infrastructure status data. Deployment location changes include core component cluster migration and auxiliary component expansion deployment. Core business operation data and infrastructure status data include scheduling transaction success rate, component response efficiency, and communication link stability of physical resource nodes. These various data are integrated into the adjustment data pool, and then the deviation attribution is labeled and compared. If the core component interaction delay occurs simultaneously with the component deployment location migration, and the interaction frequency does not change significantly, the deviation attribution is that the deployment location change caused the communication link extension. If the increased interaction delay is accompanied by a significant increase in interaction frequency, the deviation attribution is that the business peak caused an increase in the interaction intensity between components. This step focuses computing resources on core interaction links and deviation nodes, ensuring that the input data is strongly correlated with the weight adjustment requirements. The clarification of deviation attribution transforms subsequent weight adjustment from blind adaptation to targeted optimization, providing a clear direction for weight correction.

[0151] The weighting coefficients of the business weight matrix are set based on historical data and cannot adapt to new deviations after deployment. If fixed weighting coefficients are used, the weight adjustments will deviate from actual business needs. To address this, we retrieve the adjustment data pool with deviation attribution and the business weight matrix, and dynamically adjust the weighting coefficients according to the deviation attribution. If the deviation attribution is due to a change in deployment location leading to an extended communication link, we increase the weighting coefficient related to communication costs between business components to enhance the sensitivity of the initial weights to changes in communication links. If the deviation attribution is due to increased interaction intensity caused by business peaks, we increase the weighting coefficient related to transaction collaboration frequency to highlight the weight priority of high-interaction-intensity component pairs. If the deviation attribution is due to resource contention among auxiliary components leading to inefficient collaboration, we decrease the transaction collaboration weighting coefficient for such component pairs to prevent non-core weights from excessively consuming resources.

[0152] Based on the operational scenarios of core businesses, iterative updates are performed in a hierarchical order: core assurance layer → business support layer → auxiliary operation and maintenance layer. Core assurance layer components are updated pairwise with precision, adjusting initial weights based on adapted weighting coefficients and simultaneously annotating the attribution basis for weight adjustments. Business support layer components are updated in batches, reusing the same weighting coefficient rules for component pairs within the same interactive component cluster to batch adjust weights. Auxiliary operation and maintenance layer components are updated in batches periodically, integrating interactive data at fixed intervals and uniformly adjusting weights. The initial weights after layered updates are integrated to form a preliminary updated business weight matrix. This step ensures that weight adjustments accurately match the root causes of deviations, guaranteeing the accuracy of initial weights for core components. Batch updates improve the adjustment efficiency of non-core components, achieving a balance between weight update accuracy and efficiency. This ensures the business weight matrix always aligns with the business operation status, enhancing the matrix's adaptability to dynamic scenarios.

[0153] The initially updated business weight matrix may have issues with the technical weights being out of sync with business implementation requirements, or the clustering logic of component clusters and the interaction tightness reflected by the weights may conflict after the initial weight adjustments. Directly using this matrix will lead to distorted deployment cost calculations and invalid clustering results. The solution involves retrieving the initially updated business weight matrix, deployment cost matrix, and component cluster clustering logic. The clustering logic explicitly states rules such as prioritizing high-interaction-weight component pairs to cluster into the same cluster and matching core components to high-configuration clusters. Cost adaptability verification focuses on checking the correlation between initial weights and cost factors. For example, after increasing the initial weight of communication latency for core component pairs, does the corresponding communication cost in the deployment cost matrix adapt synchronously? If the initial weight increases but the communication cost does not adjust accordingly, adaptation is considered a failure. Clustering logic adaptability verification focuses on checking the consistency between initial weights and clustering results. For example, if high-interaction-weight core component pairs are not clustered into the same cluster, or the cluster configuration matched to the core components does not meet the requirements, adaptation is considered a failure.

[0154] If an imbalance between the initial weights and cost factors is caused by excessively high weighting coefficients, such as an excessive increase in the initial weight of communication latency leading to cost distortion, the corresponding weighting coefficients are lowered. If clustering logic conflicts are caused by inaccurate weighting coefficient adaptation, such as insufficient reflection of interaction-related weights resulting in scattered clustering of highly collaborative components, the interaction-related weighting coefficients are readjusted. Based on the optimized weighting coefficients, the business weight matrix is ​​revised, and the verification process is repeated until the business weight matrix simultaneously satisfies the correlation with the deployment cost matrix and the consistency with the clustering logic, and the updated business weight matrix is ​​output. This step ensures that the updated business weight matrix meets the technical accuracy requirements, aligns with the subsequent deployment cost calculation and component clustering implementation needs, continuously improves the adaptability of the business weight matrix, and provides weight support for subsequent business links.

[0155] Furthermore, the updated risk heatmap includes:

[0156] The update scope of the risk heat map is determined based on the type of comparison deviation and the core nature of the business components.

[0157] An updated data pool is formed by performance indicators, changes in the deployment location of business components, and operational data of core businesses and status data of infrastructure, and the cause of deviation is marked for comparison discrepancies.

[0158] Based on the bias attribution labeled in the updated data pool, the input weights of performance indicators in the long short-term memory network and the preset weights in the risk probability are dynamically adapted to generate the updated risk probability after deployment.

[0159] The risk heat map is updated by iterating through the physical resource nodes in the data pool in the order of core security layer, business support layer and auxiliary operation and maintenance layer.

[0160] The compatibility of the updated risk heatmap with the pre-matching results of deployment constraints and component clusters is verified, and the input weights and preset weights in the risk probabilities are iteratively optimized based on the verification results.

[0161] If the risk heatmap is updated using a full-coverage mode, it will not only generate a large amount of redundant computing power due to the invalid updates of irrelevant nodes, but also cause the risk focus of core nodes to be obscured due to the excessive dispersion of risk information. In fact, different types of comparison deviations have different impact ranges on physical resource nodes, and the physical resource node levels associated with business components of different core levels are also different. The performance deviation of core components will be transmitted to multiple associated nodes through dependencies, while the slight operational deviation of auxiliary components is usually limited to their own deployment nodes. It is necessary to clarify the types of comparison deviations, such as the performance degradation of core components, abnormal resource load of auxiliary components, and hardware status warnings of physical resource nodes. At the same time, the core level of business components and the physical topology of the private cloud should be retrieved to clarify the deployment nodes of each business component and the direct and indirect dependent node links.

[0162] If the discrepancy originates from core security layer components, such as abnormal response latency in scheduling decision components, the update scope must cover the main physical resource node of the component deployment, all directly dependent nodes, and indirectly related resource nodes, since the main physical resource node of such business components is directly associated with critical nodes such as backup servers and core network switches. If the discrepancy is due to minor operational anomalies caused by auxiliary operation and maintenance layer components, such as slight fluctuations in resource usage of the report statistics cluster, the update scope is limited to the deployment node of that component, without extending to other nodes, and the defined update scope is marked with boundaries. This concentrates computing resources on high-value, high-risk associated nodes, ensures the accuracy of risk assessment for core business associated nodes, simplifies the update process for auxiliary component associated nodes, and achieves a balance between update accuracy and efficiency.

[0163] The accuracy of risk heatmap updates directly depends on the quality of input data and the clarity of bias attribution. If the data acquisition scope lacks control and includes data from non-updating nodes, it will lead to significant noise in the data pool, affecting the accuracy of network analysis. Without clearly identifying the root cause of the bias, subsequent adjustments to network input weights will lack a clear basis, resulting in blind adaptation. Using the risk heatmap update scope as a boundary, performance indicators, changes in the deployment location of business components, and operational data of core businesses and infrastructure status data are acquired in a targeted manner. Performance indicators include processor load trends, memory usage stability, hardware operating temperature, and network link transmission status. Changes in the deployment location of business components include migration of component clusters, component scheduling records between nodes, and resource allocation adjustment records. Operational data of core businesses and infrastructure status data include resource scheduling response efficiency, transaction processing success rate, and node power supply stability. All acquired data are correlated and integrated to form an updated data pool.

[0164] Based on the data's changing trends and deployment location changes, the causes of deviations are traced, compared, and labeled. If the load of a core node abnormally increases and is synchronized with recent records of scheduling decision components migrating to that node, and the hardware status indicators are normal, the deviation is labeled as resource contention caused by the adjustment of the business component's deployment location. If the node load does not fluctuate significantly but the hardware operating temperature continues to rise, the deviation is labeled as the natural degradation of infrastructure hardware performance. This step ensures a strong correlation between the input data and update requirements, providing optimization directions for subsequent network weight adjustments and improving the adaptability of risk assessment to real-world scenarios.

[0165] The input weights and preset weights for risk probabilities in the Long Short-Term Memory (LSTM) network are generated based on historical data training. Their parameter configuration cannot adapt to newly added bias types after deployment. Using fixed weights would lead to biased risk probability calculations, failing to accurately reflect the risk status of nodes. By retrieving the updated data pool with bias attribution and the trained LSM network, the network weights are adjusted according to the bias attribution. If the bias attribution is related to resource contention, such as increased load due to component deployment migration, the input weights of performance indicators like processor load and memory usage are increased to enhance the network's ability to identify resource contention-related risk characteristics. If the bias attribution is related to hardware degradation, such as increased hardware temperature and decreased power supply stability, the input weights of hardware operation-related indicators are increased.

[0166] Simultaneously, the preset weights of risk probabilities are adjusted based on the dependencies of physical resource nodes. For physical resource nodes deployed in core business components, the preset weight of fault risk probability in risk calculation is increased because their failures have a higher impact on business. For dependent nodes in the core link, such as server nodes associated with core switches, the preset weight of propagation risk probability is increased. The adjusted preset weights are applied to update the data pool. By analyzing the real-time status and changing trends of each node's performance indicators through network analysis, the fault risk probability of nodes in the future is predicted. The propagation path and probability of risk between nodes are analyzed based on the dependencies of physical resource nodes to determine the propagation risk probability of each node. The two types of risk probabilities are integrated according to the adjusted preset weights to generate the updated risk probability of each node. This step accurately identifies the risk characteristics corresponding to the newly added deviation types. The risk probability takes into account both fault risk and propagation risk, fully reflecting the actual risk level of nodes in the private cloud topology, and improving the comprehensiveness and accuracy of risk assessment.

[0167] Different levels of nodes have significantly different supporting value and risk sensitivity to core business. The risk status of core assurance layer nodes needs to be presented in real time and accurately, while the requirements for the real-time and accuracy of risk presentation for auxiliary operation and maintenance layer nodes are relatively lower. If a unified update is adopted, it will lead to the lag in the update of core nodes or the waste of computing power for the update of auxiliary nodes. Differentiated iterative updates are implemented according to the hierarchical order of core assurance layer → business support layer → auxiliary operation and maintenance layer. For core assurance layer nodes, node-by-node accurate updates are adopted, mapping the risk probability of each node after the update to the corresponding risk level, and accurately marking it in the risk heat map. At the same time, risk attribution explanations are added, such as the high risk level being due to resource competition caused by the migration of business components.

[0168] For business support layer nodes, cluster batch updates are used, and risk levels are uniformly mapped to nodes deployed for the same business component. Only nodes with abnormal risk levels are annotated with attribution explanations. For auxiliary operation and maintenance layer nodes, periodic batch updates are used, and the risk levels are uniformly updated after integrating node risk probabilities at fixed time intervals. The node risk information in the original risk heat map is then overlaid layer by layer to form a preliminary updated risk heat map. This step achieves a balance between update accuracy and efficiency, ensuring the accurate presentation of the risk status of core protection layer nodes. Batch updates improve the update efficiency of the business support layer and auxiliary operation and maintenance layer, and differential attribution annotations enable operation and maintenance personnel to quickly focus on the root causes of node risks, improving the efficiency of risk handling.

[0169] The initial updated risk heatmap may have a disconnect between technical risk assessment and business needs. Directly using this risk heatmap to adjust deployment strategies could lead to adjusted deployment strategies violating business logic or failing to be implemented. The following steps are taken: retrieve the initial updated risk heatmap, deployment constraints for business components, and pre-matching results between component clusters and physical resource nodes. Deployment constraints clearly define rules such as core protection layer nodes needing to meet low-risk requirements and strongly transaction-related component clusters needing to be deployed on adjacent low-risk nodes. Pre-matching results define the target node range for each component cluster. Constraint compatibility verification focuses on checking whether the risk level of core protection layer nodes meets the corresponding risk threshold (0.15 for core components, 0.4 for important components, and 0.7 for auxiliary components) and whether the resource status of each node meets the deployment requirements of the corresponding component. Pre-matching compatibility verification focuses on checking whether the target nodes pre-matched to the core component clusters are low-risk and whether the pre-matched nodes for strongly transaction-related component clusters are adjacent nodes.

[0170] If the verification passes, the optimized risk heatmap is output directly. If the verification fails, the root cause of the problem is analyzed. If the risk level calculation deviation is due to unreasonable network weight adaptation, such as the load index weight being too low leading to an underestimation of the risk of core nodes, the input weights of the Long Short-Term Memory network and the preset weights of the risk probability are readjusted. If the risk assessment deviation is due to incomplete data acquisition, such as the lack of hardware maintenance records for nodes, the relevant data is acquired and the risk probability is recalculated. Based on the optimized input weights and risk probabilities, the risk heatmap is updated a second time and the verification process is repeated until the verification passes. Finally, an updated risk heatmap with satisfactory adaptability is output. This step ensures that the updated risk heatmap meets the accuracy requirements of technical risk assessment, aligns with the actual needs of business deployment, and forms a closed-loop mechanism for continuous improvement, thereby continuously improving the adaptability of risk assessment and gradually increasing the accuracy of subsequent risk calculations.

[0171] Specifically, the redeployment strategy options include:

[0172] The updated business weight matrix and risk heat map are calibrated together, and the coupling weights of the penalty terms in the deployment constraint and deployment cost matrix are corrected simultaneously.

[0173] Based on the type of comparison deviation, the target priority of the optimization function and the parameters of the genetic algorithm are matched, and a hierarchical strategy is generated according to the corresponding levels of the core security layer, business support layer and auxiliary operation and maintenance layer.

[0174] By combining the operational scenarios of core businesses with the changing trends of risk heat maps, we can simulate and evaluate whether business components meet deployment constraints, re-cluster them to correct the mapping relationship between business components and physical resource nodes, and output a new deployment strategy plan after accumulating simulation experience.

[0175] The updated business weight matrix and risk heat map are independently iterated technical results, and there is a potential problem of data logic disconnect between the two. At the same time, the penalty terms of the original deployment constraints and deployment cost matrix are coupled with weights, which are still based on historical settings and cannot adapt to the updated state of the two matrices. Directly using them will cause a mismatch between the strategy and actual business and risk requirements. The updated business weight matrix and risk heat map are retrieved. In the business weight matrix, the communication tightness weight between core security layer components has been increased. In the risk heat map, the risk level of some previously low-risk core nodes has been increased due to increased hardware load. The business weight of core components is bound to the risk level of the corresponding physical resource nodes. If the interaction feature weight of a core component increases, the risk threshold of its intended deployment node is simultaneously reduced to ensure that high-weight core components are preferentially matched with low-risk nodes. If the risk level of a node increases due to the deterioration of infrastructure status, the business weight adaptation priority of the corresponding business component of that node is reduced to avoid risk transmission to the core interaction link.

[0176] After completing the dual-matrix linkage calibration, the coupling weights of deployment constraints and penalty items in the deployment cost matrix are simultaneously corrected. For deployment constraints, the resource exclusivity of core protection layer components is strengthened and the resource sharing restrictions of auxiliary operation and maintenance layer components are relaxed, based on the calibrated weights and risk status. For penalty items in the deployment cost matrix, the coupling weights of penalty items for high-risk nodes are increased according to the risk transmission trend of the risk heatmap, and the coupling weights of penalty items for strongly transaction-related components are increased according to the interaction strength of the business weight matrix, ensuring that penalty items can accurately reflect the current risk and business interaction costs. This achieves precise binding between business interaction priority and node risk status. The synchronously corrected coupling weights of deployment constraints and penalty items allow the constraints and cost quantification basis generated by subsequent deployment strategy solutions to dynamically adapt to the current business and risks.

[0177] The original optimization function's objective priority and genetic algorithm parameters are fixed, making it unable to adapt to different types of comparison deviations. If a unified generation strategy for all components is adopted, issues arise such as auxiliary components consuming core resources and core component requirements being diluted. To address this, the types of comparison deviations must be clearly defined. If the deviation is core node resource overload, it indicates insufficient resource balance in the existing deployment strategy. If the deviation is excessive communication latency between core components, it indicates unreasonable communication link planning in the existing deployment strategy. The objective priority of the optimization function should be adapted based on the type of comparison deviation. In the resource overload deviation scenario, the objective priority of resource balance should be increased, and the objective priority of reducing total cost should be increased. In the communication latency deviation scenario, the objective priority of total cost should be increased, strengthening the low-latency deployment orientation between core components. The parameters of the genetic algorithm should be adapted simultaneously. For resource overload deviations, the mutation probability of the genetic algorithm should be adjusted to broaden the search range for resource allocation and avoid getting trapped in local optima of concentrated resource configuration. For communication latency deviations, the crossover probability of the genetic algorithm should be adjusted to retain low-latency deployment links between core components, ensuring that tightly integrated component clusters are not split.

[0178] After parameter adaptation is completed, a layered strategy is generated in the order of core assurance layer → business support layer → auxiliary operation and maintenance layer. The strategy of the core assurance layer adopts high-precision customization, planning low-risk, high-configuration, and low-latency deployment nodes separately for scheduling decision components and allocation execution components, and clarifying the exclusive scope of resources and redundancy backup schemes. The strategy of the business support layer adopts incremental optimization, planning collaborative deployment nodes for status monitoring components and request receiving components based on the remaining resources of the core assurance layer strategy, to meet transaction association requirements. The strategy of the auxiliary operation and maintenance layer adopts resource reuse, deploying report statistics components and resource reclamation components on idle resource nodes to maximize resource utilization, and integrating them to form a preliminary layered strategy. This step achieves the goal of prioritizing core business and efficiently reusing resources for auxiliary business, solves the resource allocation imbalance problem of the full deployment strategy solution, and improves the business adaptability of the deployment strategy solution.

[0179] The tiered strategy is generated based on the current static state and does not consider changes in operating scenarios or trends in risk heatmaps, posing potential risks. To address this, the strategy is imported into a simulation platform deployed on the private cloud, analyzing the changing trends of core business operating scenarios and risk heatmaps. This simulation includes: monitoring resource load changes and transaction processing response efficiency of core components during peak expansion scenarios; assessing the impact of risk transmission from nodes on business component operations during rising risk heatmaps; and simulating resource integration efficiency of auxiliary components during nighttime idle recovery scenarios. The simulation process is then evaluated to ensure compliance with deployment constraints, verifying whether core components meet resource exclusivity and low-risk deployment constraints, whether strongly transaction-related components meet collaborative deployment constraints, and whether auxiliary components meet resource reuse constraints. If the evaluation finds that core components exceed load limits during peak expansion scenarios, or that the risk of the proposed deployment node will exceed the risk threshold, the mapping relationship between business components and physical resource nodes is corrected. This involves re-clustering and adjusting cluster partitioning, migrating overloaded core components to backup low-load nodes, and migrating components from high-risk nodes to adjacent low-risk nodes, ensuring that all components comply with deployment constraints.

[0180] After completing the mapping relationship correction, the optimization actions in the pre-drilling and correction process are reviewed, and reusable deployment experience is accumulated. For example, core components need to reserve 20% redundant resources in peak expansion scenarios, and components in high-risk transmission links need to be deployed redundantly across nodes. Finally, a new deployment strategy solution with long-term optimization value is generated. By pre-drilling scenarios, potential operational risks of the strategy are identified and avoided in advance. The corrected mapping relationship ensures the accuracy of matching between business components and nodes. The experience accumulation makes the deployment strategy solution output no longer limited to the current scenario, providing a reusable optimization basis for subsequent deployment strategy solution iterations. This promotes the formation of a complete closed loop of strategy output, execution monitoring, experience accumulation, matrix update, and strategy re-iteration in the entire system.

[0181] Example 2:

[0182] like Figure 4 The diagram shows a flowchart of a method for deploying a private cloud core business support node, as provided in this application embodiment. The method includes:

[0183] Deconstruct the core business to identify and analyze the data flow, call relationships and transaction associations between business components, and dynamically generate a business weight matrix that reflects the communication tightness between business components;

[0184] Real-time acquisition of performance metrics of physical resource nodes in private cloud infrastructure, and processing of performance metrics based on long short-term memory network to predict the failure risk probability of different physical resource nodes, and synchronous generation of risk heat map of infrastructure.

[0185] A deployment cost matrix representing the deployment of business components on the same physical resource node is generated based on the business weight matrix, and a penalty term is generated based on the risk heat map and the deployment cost matrix is ​​weighted and corrected.

[0186] With the total cost and resource balance of the revised deployment cost matrix as the objectives, an optimization function is constructed and solved to output a deployment strategy scheme that includes the mapping relationship between business components and physical resource nodes;

[0187] Execute the deployment strategy and plan, and after deployment, continuously acquire the core business operation data and infrastructure status data, compare them with the expected indicators of the deployment strategy and plan, and when the comparison deviation exceeds the preset threshold, update the business weight matrix and risk heat map and re-output the deployment strategy and plan.

[0188] Since the principle of the method in this application embodiment is similar to that of the system described in this application embodiment, the implementation of the method is the same as that of the system, and the repeated parts will not be described again.

Claims

1. A private cloud core business support node deployment system, characterized in that, include: The module comprises a business analysis module, a facility awareness module, a decision-making module, and a deployment evolution module. The business parsing module deconstructs the core business to identify and analyze the data flow, call relationships and transaction associations between business components, and dynamically generates a business weight matrix that reflects the communication tightness between business components; The facility perception module acquires the performance indicators of physical resource nodes in the private cloud infrastructure in real time, predicts the failure risk probability of different physical resource nodes based on the performance indicators of the long short-term memory network, and generates a risk heat map of the infrastructure simultaneously. The decision-making module generates a deployment cost matrix representing the deployment of business components on the same physical resource node based on the business weight matrix, generates a penalty term based on the risk heat map and weights and corrects the deployment cost matrix, constructs and solves an optimization function with the total cost and resource balance of the corrected deployment cost matrix as the objective, and outputs a deployment strategy scheme. The deployment evolution module executes the deployment strategy and, after deployment, continuously acquires the operational data of core businesses and the status data of infrastructure, compares them with the expected indicators of the deployment strategy, and updates the business weight matrix and risk heat map and re-outputs the deployment strategy when the comparison deviation exceeds the preset threshold.

2. The private cloud core business support node deployment system as described in claim 1, characterized in that, Dynamically generating the business weight matrix includes: The core business is deconstructed into business components at different functional levels, and the functional attributes and core status of the business components are clarified in order to classify and label the business components. Real-time acquisition of communication data between business components, extraction of interaction features of communication data, and parsing of transaction logs of core business to identify transaction relationships between business components; The weighting coefficients are determined based on the coreness of the business components and the transactional relationships between them. The initial weights reflecting the communication tightness between the business components are then calculated by combining the weighting coefficients with the interaction characteristics. The initial weights are dynamically adjusted based on the operational scenarios of the core business to dynamically generate a business weight matrix.

3. The private cloud core business support node deployment system as described in claim 2, characterized in that, The risk heatmap for the generated infrastructure includes: Real-time acquisition of operational data, full lifecycle data, and environmental correlation data of physical resource nodes in private cloud infrastructure; after preprocessing, performance indicators characterizing the status of physical resource nodes are formed. Based on the performance metrics of long short-term memory networks, the failure risk probability of different physical resource nodes is predicted. The propagation risk probability is determined based on the dependency relationship of physical resource nodes in the physical topology of the private cloud, and then weighted and fused with the failure risk probability according to the preset weight to obtain the risk probability. By combining the core level of the business components to be deployed with the risk threshold, and based on the physical topology of the private cloud, a risk heat map is generated according to the risk probability.

4. The private cloud core business support node deployment system as described in claim 3, characterized in that, Generating the deployment cost matrix includes: The core level of the business components, the transactional relationships between business components, and the interaction characteristics of communication data are called. Combined with the risk threshold corresponding to the core level of the business components to be deployed, the deployment constraints of business components, including resource exclusivity, transactional coordination, and communication requirements, are marked. Based on the business weight matrix, cost factors for resource competition cost, transaction coordination cost and communication cost are constructed. Dynamic weights are assigned to the cost factors and weighted calculation is performed in combination with deployment constraints to form the initial deployment cost between business components deployed on the same physical resource node. Adjust the initial deployment cost based on the core business operation scenarios and integrate them to generate a deployment cost matrix.

5. A private cloud core business support node deployment system as described in claim 4, characterized in that, The weighted modified deployment cost matrix includes: The risk probability of physical resource nodes constitutes the fault penalty item, the coreness of the business component constitutes the business penalty item, the deployment constraints of the associated business component constitute the deployment penalty item, and the penalty items are generated by weighting and integrating them according to a preset ratio. Based on the transactional relationships between business components, the dependencies between physical resource nodes, and the operational scenarios of core businesses, coupling weights are assigned to penalty terms. The deployment cost matrix is ​​then adjusted by layering and weighting based on the combination of business components and physical resource nodes, combined with coupling weights, and the adjusted deployment cost matrix is ​​then normalized and calibrated.

6. The private cloud core business support node deployment system as described in claim 5, characterized in that, The deployment strategy scheme output includes: The total cost and resource balance of the revised deployment cost matrix are used as the target, and the target priority of total cost and resource balance is dynamically adapted based on the operation scenario of the core business and the coreness of the business components. Constraints are formed by combining transactional relationships between business components, deployment constraints, and penalty terms, and then embedded into objectives. Optimization functions are constructed by combining objective priorities. The communication cost is processed by clustering algorithm to cluster business components into component clusters. Physical resource nodes are pre-matched for component clusters based on risk heat map, and the optimization function is solved based on genetic algorithm. The solution results are verified based on risk thresholds and cost factors. Once the verification is successful, a deployment strategy scheme including the mapping relationship between business components and physical resource nodes is output.

7. A private cloud core business support node deployment system as described in claim 6, characterized in that, The execution deployment strategy includes: Before deployment, the component cluster is verified by combining real-time updated risk heat maps and deployment constraints to determine whether backup nodes are matched based on the dependencies of physical resource nodes. Based on the core nature of the business components and the division of component clusters, deployment is carried out in the hierarchical order of core assurance layer, business support layer and auxiliary operation and maintenance layer; After deployment, continuously acquire core business operation data, infrastructure status data, and risk heat map change trends to adjust the deployment location of business components; The system receives operational data from core business operations and status data from infrastructure, compares them with the expected metrics of the deployment strategy, and updates the business weight matrix and risk heat map and re-outputs the deployment strategy when the comparison deviation exceeds a preset threshold.

8. A private cloud core business support node deployment system as described in claim 7, characterized in that, Updating the risk heatmap includes: The update scope of the risk heat map is determined based on the type of comparison deviation and the core nature of the business components. An updated data pool is formed by performance indicators, changes in the deployment location of business components, and operational data of core businesses and status data of infrastructure, and the cause of deviation is marked for comparison discrepancies. Based on the bias attribution labeled in the updated data pool, the input weights of performance indicators in the long short-term memory network and the preset weights in the risk probability are dynamically adapted to generate the updated risk probability after deployment. The risk heat map is updated by iterating through the physical resource nodes in the data pool in the order of core security layer, business support layer and auxiliary operation and maintenance layer. The compatibility of the updated risk heatmap with the pre-matching results of deployment constraints and component clusters is verified, and the input weights and preset weights in the risk probabilities are iteratively optimized based on the verification results.

9. A private cloud core business support node deployment system as described in claim 8, characterized in that, The redeployment strategy includes: The updated business weight matrix and risk heat map are calibrated together, and the coupling weights of the penalty terms in the deployment constraint and deployment cost matrix are corrected simultaneously. Based on the type of comparison deviation, the target priority of the optimization function and the parameters of the genetic algorithm are matched, and a hierarchical strategy is generated according to the corresponding levels of the core security layer, business support layer and auxiliary operation and maintenance layer. By combining the operational scenarios of core businesses with the changing trends of risk heat maps, we can simulate and evaluate whether business components meet deployment constraints, re-cluster them to correct the mapping relationship between business components and physical resource nodes, and output a new deployment strategy plan after accumulating simulation experience.

10. A method for deploying a core business support node in a private cloud, implemented based on a private cloud core business support node deployment system according to any one of claims 1-9, characterized in that, include: Deconstruct the core business to identify and analyze the data flow, call relationships and transaction associations between business components, and dynamically generate a business weight matrix that reflects the communication tightness between business components; Real-time acquisition of performance metrics of physical resource nodes in private cloud infrastructure; prediction of failure risk probability of different physical resource nodes based on long short-term memory network processing performance metrics; and simultaneous generation of risk heat map of infrastructure. A deployment cost matrix representing the deployment of business components on the same physical resource node is generated based on the business weight matrix, and a penalty term is generated based on the risk heat map and the deployment cost matrix is ​​weighted and corrected. With the total cost and resource balance of the revised deployment cost matrix as the objectives, an optimization function is constructed and solved to output a deployment strategy scheme; Execute the deployment strategy and plan, and after deployment, continuously acquire core business operation data and infrastructure status data, and compare them with the expected indicators of the deployment strategy and plan; When the comparison deviation exceeds the preset threshold, update the business weight matrix and risk heat map and re-output the deployment strategy plan.

Images