A data risk perception assessment system for a data center

Abstract

The application relates to the technical field of data risk assessment, in particular to a data risk perception assessment system for a data center, which comprises a communication state mapping module, a weight dynamic configuration module, a behavior outlier identification module, a cause-effect gradient calibration module and a risk storage isolation module.In the application, by dynamically adjusting the node communication weight, the behavior outlier identification and the cause-effect gradient calibration, sudden abnormal behaviors are identified and the weight is dynamically adjusted, deep perception of data access behaviors is realized, the response speed of the sudden event is improved, the scheme clusters potential abnormal nodes by using the behavior outlier identification, accurately locates the behaviors deviating from the normal mode, and therefore the risk assessment precision is improved, the dynamic analysis of the event dependence relationship between nodes and the cause-effect change rate calculation ensure real-time adjustment and optimization of the data risk assessment, the adaptability of the system to the complex data environment is enhanced, and the perception and early warning capability of the data security risk is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of data risk assessment technology, and in particular to a data risk perception and assessment system for data centers. Background Technology

[0002] The field of data risk assessment technology involves the identification, analysis, and evaluation of various risks to data in information systems, such as leakage, tampering, and loss. This field includes data collection, data flow monitoring, risk modeling, risk indicator setting, assessment method construction, and risk level determination, and is widely used in scenarios with high data security requirements, such as finance, government affairs, healthcare, and energy.

[0003] Among them, the traditional data risk perception and assessment system for data centers refers to a system used to identify and assess data security risks in data centers in real time. The technical issue addressed by this system is how to effectively perceive and assess data anomalies, data leakage paths, and abnormal access behaviors in the large-scale and complex environment of data centers. Traditional data risk perception and assessment systems use methods such as rule matching, log statistical analysis, and threshold-based early warning mechanisms to accomplish this. Specifically, it involves collecting log files generated by various devices in the data center and extracting key fields, comparing the access behaviors in the logs according to preset rules to see if they trigger risk conditions, and then classifying and assessing the risk level according to the set risk factor weights. Alternatively, it can set thresholds for access frequency, operation commands, etc., and when the system detects abnormal behavior exceeding the threshold range, it marks it and adds it to the risk event list. The overall process focuses on matching and judging existing risk characteristics.

[0004] Existing technologies primarily assess data risk through rule matching, log analysis, and threshold-based alerts. These methods rely on pre-defined rules and thresholds, making them ill-equipped to handle unknown or sudden data security risks. This results in overly limited detection of abnormal behavior, particularly in complex and dynamic environments where they cannot adapt promptly to new attack patterns or behavioral changes. Furthermore, existing technologies focus on static analysis, failing to reflect real-time changes in the data center environment and effectively identifying potential correlations between data access behaviors. This leads to delayed assessment results and an inability to quickly detect data breaches or tampering. Traditional methods also lack dynamic tracking and adjustment of complex dependencies between nodes during risk perception, resulting in risk assessment failures or insufficient accuracy. Summary of the Invention

[0005] To address the technical problems existing in the prior art, embodiments of the present invention provide a data risk perception and assessment system for data centers. The technical solution is as follows:

[0006] On the one hand, a data risk perception and assessment system for data centers is provided, which includes:

[0007] The communication state mapping module calculates the communication changes of node pairs in adjacent time windows based on the traffic sequence of the server node and switch interface, identifies sudden communication behavior, divides low, medium and high disturbance areas, counts the node connection density in the area and performs spatial filtering to obtain the communication state partitioning results.

[0008] Based on the communication state partitioning results, the weight dynamic configuration module assigns high communication weights to node pairs in high-disturbance areas, performs periodic weight rotation on node pairs in medium-disturbance areas, and updates the weights of node pairs in low-disturbance areas only when the communication relationship undergoes a structural change, thereby generating a node communication weight dataset.

[0009] The behavior outlier identification module calls the node communication weight dataset, extracts the access operation type sequence and abnormal trigger record of the node per unit time, clusters the nodes according to the difference in operation distribution, filters the nodes that deviate from the cluster center, and constructs a node behavior outlier comparison table.

[0010] The causal gradient calibration module analyzes the event triggering sequence relationship between nodes based on the node behavior outlier comparison table, sets a causal change threshold, performs weight reallocation on event chains that exceed the causal change threshold, and outputs the data center operation risk evolution trend assessment result.

[0011] As a further aspect of the present invention, the communication state partitioning result includes a low-disturbance region, a medium-disturbance region, and a high-disturbance region; the node communication weight dataset includes a high communication weight region, a periodically rotating weight region, and a structurally updated weight region; the node behavior outlier lookup table includes operation type distribution offset node units, abnormal trigger frequency sudden increase node units, and access target concentration abnormal node units; and the data center operation risk evolution trend assessment result includes event dependency chain change trend, node communication weight evolution trajectory, causal change threshold, and high-risk event chain set.

[0012] As a further aspect of the present invention, the communication state mapping module includes:

[0013] The communication change calculation submodule obtains the number of communication packets and transmitted bytes of each pair of server nodes within the time window through the hardware monitoring unit, identifies the communication change in adjacent windows, determines the communication disturbance intensity based on the magnitude of the change, and generates node communication disturbance values.

[0014] The state region partitioning submodule calls the node communication disturbance value, sets a grade boundary according to the disturbance intensity, classifies node pairs with disturbance values ​​below the first boundary threshold into the low disturbance region, those between the first and second boundary thresholds into the medium disturbance region, and those above the second boundary threshold into the high disturbance region, counts the number of spatial connections of node pairs in the region, and forms the communication state partitioning result.

[0015] The density filtering submodule calls the communication state partitioning results, calculates the number of node pairs within a unit topological distance of the region, removes isolated node pairs in sparsely connected regions, retains regions with connection density higher than a preset density threshold, and outputs the communication state partitioning results.

[0016] As a further aspect of the present invention, the weight dynamic configuration module includes:

[0017] The weight level setting submodule calls the communication state partitioning results, assigns an initial high communication weight value to the high disturbance area, assigns a medium communication weight value to the medium disturbance area and binds a rotation cycle identifier, assigns a basic communication weight value to the low disturbance area and marks it as a static weight state, and generates a node communication weight level table.

[0018] The weight update execution submodule calls the node communication weight level table. At the beginning of each rotation cycle, it adjusts the communication weight values ​​of node pairs in the medium disturbance area. When the communication structure of node pairs in the low disturbance area changes, it recalculates their communication weight values. The communication weight values ​​of node pairs in the high disturbance area are accumulated in real time according to the amount of communication change, and the node communication weight dataset is output.

[0019] As a further aspect of the present invention, the adjustment of the communication weight value of the node pair in the disturbance region refers to linearly increasing or decreasing the communication weight value based on the communication change of the previous cycle at the beginning of each rotation cycle, while keeping the adjustment range within 20% of the basic communication weight value, to obtain the communication weight value of the node pair in the disturbance region.

[0020] As a further aspect of the present invention, the behavior outlier identification module includes:

[0021] The operation sequence extraction submodule reads the access instruction type, resource request identifier and abnormal interruption flag within a unit time from the operation log buffer of the server node according to the node communication weight dataset, arranges them in chronological order, removes the same instruction segments in the sequence, and obtains the effective behavior segments.

[0022] The outlier clustering submodule calls the effective behavior fragment, calculates the Euclidean distance between the node and the node at the same level on the frequency distribution of operation type, marks the node with a distance exceeding the clustering radius threshold as an outlier, and classifies it according to operation type offset class, abnormal trigger surge class, and access target set class, and generates a node behavior outlier comparison table.

[0023] The lookup table optimization submodule calls the node behavior outlier lookup table to perform merging processing on outlier nodes in adjacent topological positions within the same category, eliminating misjudgments caused by local communication jitter, and outputting the node behavior outlier lookup table.

[0024] As a further aspect of the present invention, the causal gradient calibration module includes:

[0025] The event chain parsing submodule calls the node behavior outlier lookup table, extracts the event trigger timestamp, resource usage identifier and execution completion status from the operation logs of outlier nodes and related nodes, and constructs a multi-level event dependency chain in chronological order.

[0026] The rate of change calculation submodule calls the multi-level event dependency chain to count the change in the frequency of the same event pair in the dependency chain within adjacent periods, analyzes the multi-level event pairs, and generates a set of event dependency rate of change.

[0027] The weight reallocation submodule calls the event dependency change rate set, sets the causal change threshold, and when the change rate of any event pair exceeds the preset threshold for two consecutive periods, it performs incremental adjustment on its weight in the event dependency matrix. The increment is proportional to the change rate, and outputs the data center operation risk evolution trend assessment result.

[0028] As a further aspect of the present invention, the system also includes a risk storage isolation module:

[0029] Based on the data center operation risk evolution trend assessment results, the risk storage isolation module extracts the physical location information of nodes in the high-risk event chain, identifies the deployment coordinates of nodes in the rack, divides the risk isolation storage area according to the coordinate proximity, adjusts the logical mapping path of the storage device, and generates a data center risk data isolation storage solution.

[0030] As a further aspect of the present invention, the data center risk data isolation storage scheme includes risk isolation storage area division, logical mapping path adjustment, node physical location information extraction, and deployment coordinate identification.

[0031] As a further aspect of the present invention, the risk storage isolation module includes:

[0032] The location information extraction submodule calls the data center operation risk evolution trend assessment results, queries the rack number, U-position height and network port number of the risk event chain related nodes from the data center asset management, and combines them to generate the physical location coordinates of the nodes;

[0033] The isolation zone division submodule calls the physical location coordinates of the nodes, calculates the three-dimensional spatial distance between any two high-risk nodes, and assigns nodes whose distance is less than the isolation radius threshold to the same risk isolation storage zone to obtain an independent storage logical volume identifier.

[0034] The path adjustment submodule calls the independent storage logical volume identifier, modifies the LUN mapping table in the storage controller, redirects the log writing path of high-risk nodes to the logical volume of the corresponding isolation zone, prohibits cross-zone data merging operations, and outputs a data center risk data isolation storage solution.

[0035] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0036] By introducing methods such as dynamic weight configuration, outlier identification, and causal gradient calibration, this system effectively addresses the insufficient adaptability of existing technologies to unknown risks in complex environments. Through real-time calculation of perturbation changes in inter-node communication, it identifies sudden abnormal behaviors and dynamically adjusts node communication weights, achieving deep perception of data access behavior and improving response speed to emergencies. Outlier identification of node behavior allows for cluster analysis of potential abnormal nodes, accurately locating behaviors deviating from normal patterns and further improving the accuracy of risk assessment. With dynamic analysis of node behavior dependencies and calculation of causal change rates, the system can promptly identify and adjust data risk assessment results, optimizing its adaptability to complex and dynamic data environments and effectively enhancing its data security risk perception and early warning capabilities. Attached Figure Description

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

[0038] Figure 1 This is a schematic diagram of a data risk perception and assessment system for a data center provided in an embodiment of the present invention;

[0039] Figure 2 This is a schematic diagram of the system framework of the present invention;

[0040] Figure 3 This is a flowchart of the communication state mapping module in this invention;

[0041] Figure 4 This is a flowchart of the weight dynamic configuration module in this invention;

[0042] Figure 5 This is a flowchart of the behavior outlier identification module in this invention;

[0043] Figure 6 This is a flowchart of the causal gradient calibration module in this invention;

[0044] Figure 7 This is a flowchart of the risk storage isolation module in this invention. Detailed Implementation

[0045] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0046] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0047] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0048] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0049] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0050] This invention provides a data risk perception and assessment system for data centers, such as... Figure 1-2 The diagram shown illustrates a data risk perception and assessment system for a data center. This system includes:

[0051] The communication state mapping module calculates the communication changes of node pairs in adjacent time windows based on the traffic sequence of the server node and switch interface, identifies sudden communication behaviors by combining the original communication patterns, divides low, medium and high disturbance areas, counts the node connection density in the area and performs spatial filtering to obtain the communication state partitioning results.

[0052] The dynamic weight configuration module sets the node communication weight level based on the communication status partitioning results. It assigns high communication weights to node pairs in high-disturbance areas, performs periodic weight rotation on node pairs in medium-disturbance areas, and updates the weights of node pairs in low-disturbance areas only when the communication relationship undergoes structural changes, thereby generating a node communication weight dataset.

[0053] The outlier behavior identification module calls the node communication weight dataset, extracts the sequence of access operation types and abnormal trigger records of nodes within a unit of time, clusters nodes according to the difference in operation distribution, filters nodes that deviate from the cluster center, and constructs a node behavior outlier comparison table.

[0054] The causal gradient calibration module analyzes the event triggering sequence relationship between nodes based on the node behavior outlier comparison table, calculates the change rate of the event dependency chain, sets the causal change threshold, performs weight reallocation on the event chain that exceeds the causal change threshold, and outputs the data center operation risk evolution trend assessment results.

[0055] Based on the assessment results of the evolution trend of data center operation risks, the risk storage isolation module extracts the physical location information of nodes in the high-risk event chain, identifies the deployment coordinates of nodes in the rack, divides risk isolation storage areas according to the proximity of coordinates, adjusts the logical mapping path of storage devices, and generates a data center risk data isolation storage solution.

[0056] The communication state partitioning results include low-disturbance regions, medium-disturbance regions, and high-disturbance regions. The node communication weight dataset includes high communication weight regions, periodically rotating weight regions, and structurally updated weight regions. The node behavior outlier comparison table includes node units with operation type distribution offset, node units with sudden increase in abnormal trigger frequency, and node units with abnormal concentration of access targets. The data center operation risk evolution trend assessment results include event dependency chain change trends, node communication weight evolution trajectories, causal change thresholds, and high-risk event chain sets. The data center risk data isolation storage scheme includes risk isolation storage area division, logical mapping path adjustment, node physical location information extraction, and deployment coordinate identification.

[0057] Specifically, such as Figure 2 , 3 As shown, the communication state mapping module includes:

[0058] The communication change calculation submodule obtains the number of communication packets and transmitted bytes of each pair of server nodes within the time window through the hardware monitoring unit, identifies the communication change in adjacent windows, determines the communication disturbance intensity based on the magnitude of the change, and generates node communication disturbance values.

[0059] The hardware monitoring unit acquires the number of communication packets and bytes transmitted for each pair of server nodes within a time window. For example, regarding communication between server A and server B, the hardware monitoring unit records the number of communication packets and bytes transmitted from server A to server B every preset time window T (e.g., 5 seconds), and simultaneously records the number of communication packets and bytes transmitted from server B to server A. (For example, 00:00:00-00:00:05), the number of communication packets between the server node pair (Node1, Node2) is 1200, and the number of bytes transmitted is 2.5MB, in the next adjacent time window. (For example, from 00:00:05 to 00:00:10), the number of communication packets between the nodes becomes 1500, and the number of transmitted bytes becomes 3.2MB. The submodule identifies the communication changes in adjacent windows. The change in communication packets is calculated as |1500-1200|=300, and the change in the number of transmitted bytes is calculated as |3.2MB-2.5MB|=0.7MB. The communication disturbance intensity is determined based on the magnitude of the change. The communication disturbance intensity judgment rule is set. When the change in communication packets is greater than 100 and the change in the number of transmitted bytes is greater than 0.5MB, it is judged as medium disturbance intensity. When the change in communication packets is greater than 500 and the change in the number of transmitted bytes is greater than 2MB, it is judged as high disturbance intensity. The communication packet change of Node1 and Node2 is 300, and the change in the number of transmitted bytes is 0.7MB. According to the judgment rule, the communication disturbance intensity of this node pair is determined to be medium, and the node communication disturbance value is finally generated.

[0060] The state region partitioning submodule calls the node communication disturbance value, sets the grade boundary according to the disturbance intensity, classifies the node pairs with disturbance values ​​below the first boundary threshold into the low disturbance region, those between the first and second boundary thresholds into the medium disturbance region, and those above the second boundary threshold into the high disturbance region. It also counts the number of spatial connections of node pairs in the region to form the communication state partitioning result.

[0061] By calling the node communication disturbance value, a data center detected server node communication disturbances. The perturbation value is 15, and the node pair The perturbation value is 60, and the node pair The disturbance value is 120. Graded boundaries are set according to the disturbance intensity, with the first boundary threshold being... Set to 30, second boundary threshold The threshold is set at 80, determined through long-term analysis and statistical regression of historical communication data. For example, under normal operating conditions, 95% of nodes have communication disturbance values ​​below 30. During initial performance degradation, the disturbance value is between 30 and 80. During severe communication anomalies, the disturbance value is generally above 80. After a month of continuous monitoring and verification, the threshold's rationality was confirmed. Based on this boundary threshold, the node... The disturbance value of 15 is lower than the first boundary threshold of 30, so it is classified as a low-disturbance region. The disturbance value 60 is between the first boundary threshold 30 and the second boundary threshold 80, and is classified as a medium disturbance region. If the disturbance value of 120 is higher than the second boundary threshold of 80, it is classified as a high disturbance region. The submodule counts the number of spatial connections between node pairs in the region. In the low disturbance region, 500 pairs of nodes are found to be physically adjacent or connected by a small number of network hops, forming 1200 spatial connections. In the medium disturbance region, 150 pairs of nodes are found, forming 350 spatial connections. In the high disturbance region, 10 pairs of nodes are found, forming 20 spatial connections. This results in a communication state partitioning result, for example, low disturbance region (500 pairs of nodes, 1200 connections), medium disturbance region (150 pairs of nodes, 350 connections), and high disturbance region (10 pairs of nodes, 20 connections).

[0062] The density filtering submodule calls the communication status partitioning results, calculates the number of node pairs within a unit topological distance of the region, removes isolated node pairs in sparsely connected regions, retains regions with connection density higher than a preset density threshold, and outputs the communication status partitioning results.

[0063] The communication state partitioning results are retrieved, including low-disturbance, medium-disturbance, and high-disturbance regions, along with the number of node pairs and spatial connections. For example, a low-disturbance region contains 500 node pairs and 1200 spatial connections, a medium-disturbance region contains 150 node pairs and 350 spatial connections, and a high-disturbance region contains 10 node pairs and 20 spatial connections. The number of node pairs per unit topological distance within each region is calculated. The unit topological distance is defined as the number of network hops between node pairs. All node pairs within each region are traversed, counting the number of node pairs within a topological distance of 1 and the number within a topological distance of 2. The number of node pairs at each topological distance is summed and divided by the total topological distance to obtain the average number of node pairs per unit topological distance. For example, in a low-disturbance region with 500 node pairs and an average topological distance of 1.5 hops, the number of node pairs per unit topological distance is 500 / 1.5 = 333.3. For each hop, the network density is calculated as follows: Medium disturbance area: 150 node pairs, average topology distance: 2.0 hops, number of node pairs per unit topology distance: 150 / 2.0 = 75 pairs / hop; High disturbance area: 10 node pairs, average topology distance: 3.0 hops, number of node pairs per unit topology distance: 10 / 3.0 = 3.3 pairs / hop. A preset density threshold of 5 pairs / hop is set, determined by subtracting 10% from the average network connection density during normal data center operation. This threshold is verified using experimental data over a one-week period. Areas below this threshold include isolated node pairs with abnormal disconnections or misconfigurations. High disturbance area (3.3 pairs / hop) is below 5 pairs / hop and is considered a sparsely connected area; isolated node pairs are removed. Low disturbance area (333.3 pairs / hop) and medium disturbance area (75 pairs / hop) are both above 5 pairs / hop and are retained. The communication status partitioning results are output, for example, low disturbance area (333.3 pairs / hop) and medium disturbance area (75 pairs / hop).

[0064] Specifically, such as Figure 2 , 4 As shown, the weight dynamic configuration module includes:

[0065] The weight level setting submodule calls the communication status partitioning results, assigns an initial high communication weight value to the high disturbance area, assigns a medium communication weight value to the medium disturbance area and binds a rotation cycle identifier, assigns a basic communication weight value to the low disturbance area and marks it as a static weight state, and generates a node communication weight level table.

[0066] The communication state partitioning results are retrieved, including high-disturbance regions (after removing sparse connections), as well as low-disturbance and medium-disturbance regions. For example, the low-disturbance region has a topology density of 333.3 pairs / hop, and the medium-disturbance region has a topology density of 75 pairs / hop. An initial high communication weight of 1.0 is assigned to the high-disturbance region, a medium communication weight of 0.6 is assigned to the medium-disturbance region, and a rotation cycle identifier (e.g., "Cycle A") is bound to it. A basic communication weight of 0.2 is assigned to the low-disturbance region and it is marked as a static weight state. The weight values ​​are determined based on historical system failure frequency and communication impact through expert experience and the AHP (Analytic Hierarchy Process). Historical data shows that the node failure probability in the high-disturbance region is 5 times that in the low-disturbance region, and in the medium-disturbance region it is 3 times that in the low-disturbance region. The weight settings of 1.0, 0.6, and 0.2 reflect potential risks. For nodes identified as high-disturbance and passing density screening... For each node pair, an initial high communication weight value of 1.0 is assigned. For node pairs in the medium disturbance region, a medium communication weight value of 0.6 is assigned, and a rotation cycle identifier is bound. For node pairs in the low disturbance region, a basic communication weight value of 0.2 is assigned, and they are marked as static weight states. For example, if a node pair N1N2 is in the medium disturbance region, its initial communication weight is set to 0.6 and it is marked with a "cycle A" rotation identifier. If another node pair N3N4 is in the low disturbance region, its communication weight is set to 0.2 and it is marked as static, a node communication weight level table is generated. This table contains each server node pair and its corresponding initial communication weight value and weight state. For example, node pair (Node1, Node2) has a weight of 1.0 (high disturbance), node pair (Node3, Node4) has a weight of 0.6 (medium disturbance, cycle A), and node pair (Node5, Node6) has a weight of 0.2 (low disturbance, static).

[0067] The weight update execution submodule calls the node communication weight level table. At the beginning of each rotation cycle, it adjusts the communication weight values ​​of node pairs in the medium disturbance area. When the communication structure of node pairs in the low disturbance area changes, it recalculates their communication weight values. The communication weight values ​​of node pairs in the high disturbance area are accumulated in real time according to the amount of communication change, and the node communication weight dataset is output.

[0068] Adjusting the communication weight value of node pairs in the middle disturbance area refers to linearly increasing or decreasing the communication weight value based on the communication change of the previous period at the beginning of each rotation cycle, while keeping the adjustment range within 20% of the basic communication weight value, to obtain the communication weight value of node pairs in the middle disturbance area.

[0069] The node communication weight level table is invoked. For example, the node pair (Node3, Node4) has a weight of 0.6 and is identified as "Period A", while the node pair (Node5, Node6) has a weight of 0.2 and is identified as "Static". At the beginning of each rotation period (e.g., every 5 minutes), the communication weight values ​​of the node pairs in the disturbance area are adjusted. For example, for the node pair (Node3, Node4), its communication weight is adjusted at the beginning of the current period. The adjustment is based on the linear increase or decrease of the communication change in the previous period. Assuming that the communication packet change in the previous period was 350 and the number of transmitted bytes changed by 0.8MB, the comprehensive index of communication change is calculated by weighting the communication packet change and the number of transmitted bytes proportionally. If the comprehensive index of communication change in the previous period was 0.7, the adjustment amount is set to 0.08. The medium communication weight value of 0.6 increases by 0.08, becoming 0.68. The adjustment range is limited to 20% of the basic communication weight value (0.2), that is, the adjustment range does not exceed 0.04. The actual adjustment amount is limited to... The adjusted weight is 0.6 + 0.04 = 0.64, yielding the communication weight value for node pairs in the medium disturbance region. When the communication structure of node pairs in the low disturbance region changes, for example, the number of communication packets in node pair (Node5, Node6) increases sharply from 100 per second to 1000 per second, and the number of transmitted bytes increases from 0.1 MB / s to 1.5 MB / s, the submodule recalculates its communication weight value. If the evaluation result causes it to move from the low disturbance region to the medium disturbance region, the weight will be adjusted from the basic weight of 0.2 to the medium weight of 0.6. The communication weight value of node pairs in the high disturbance region is accumulated in real time according to the amount of communication change. For example, if a high disturbance node pair (Node1, Node2) detects a new abnormal traffic peak (for example, the number of communication packets instantly reaches 1000), its weight will be accumulated in real time based on the original weight of 1.0, with the increment set to 0.1, and the weight becomes 1.1. The accumulation process continues, and an accumulation is performed every time a significant change is detected, outputting the node communication weight dataset.

[0070] Specifically, such as Figure 2 , 5 As shown, the outlier behavior detection module includes:

[0071] The operation sequence extraction submodule reads the access instruction type, resource request identifier, and abnormal interruption flag within a unit of time from the operation log buffer of the server node based on the node communication weight dataset, arranges them in chronological order, removes identical instruction segments from the sequence, and obtains the effective behavior segments.

[0072] Based on the node communication weight dataset, operation records within a unit time (e.g., 1 second) are read from the server node's operation log buffer. For example, for server NodeA, during the time period from 00:01:00 to 00:01:01, the following log entries are read: access command type "file read", resource request identifier " / data / file1.txt", no exception interruption flag; next, access command type "database query", resource request identifier "DB_query_001", no exception interruption flag; followed by access command type "file write", resource request identifier " / logs / log_001.log", exception interruption flag "IO_error". The read operation command type, resource request identifier, and exception interruption flag are arranged according to the precise timestamp, for example: file read @00:01:00.123 → database query @00: 01:00.456 → File write @00:01:00.789. After sorting, the submodule removes consecutively identical instruction segments from the sequence. For example, if the log sequence shows "file read → file read → file read", only one "file read" instance is kept, and its repetition count is recorded. For example, if the server NodeA log shows "access file X → access file X → modify file Y", it becomes "access file X → modify file Y" after removal. This avoids interference with subsequent analysis due to repeated operations. Finally, the effective behavior segment of the server node NodeA within a unit of time is obtained. This segment is a concise operation sequence arranged in chronological order, such as: ["file read / data / file1.txt", "database query DB_query_001", "file write / logs / log_001.log(IO_error)"].

[0073] The outlier clustering submodule calls the effective behavior fragments, calculates the Euclidean distance between the node and the node at the same level on the frequency distribution of operation type, marks the node with a distance exceeding the clustering radius threshold as an outlier, and classifies it according to operation type offset class, abnormal trigger surge class, and access target set class, and generates a node behavior outlier comparison table.

[0074] Based on valid behavioral segments, such as the valid behavioral segments for server NodeA being ["file read", "database query", "file write (IO_error)"], to identify abnormal behavior, the Euclidean distance between server NodeA and its peer nodes in terms of the frequency distribution of operation types is calculated. Peer nodes refer to a set of servers with similar functions, deployment locations, or workloads in a data center topology. For example, in a data center cluster, several nodes providing web services are defined as peer nodes. The submodule first statistically analyzes the valid behavioral segments of NodeA and its peer nodes (e.g., NodeB, NodeC) to obtain their frequency distribution of operation types within a unit of time. Assuming that NodeA's "file read" frequency is 20 times, "database query" frequency is 10 times, and "file write" frequency is 5 times in the past minute, while the frequencies for peer node NodeB are 22 times, 11 times, and 4 times respectively, and the frequencies for NodeC are 5 times, 3 times, and 20 times respectively, then the Euclidean distance between NodeA and NodeB is calculated. The Euclidean distance calculation method is as follows: ,in and Representing NodeA and NodeB respectively in the th... Frequency of operation type This represents the total number of operation types. For example, the Euclidean distance between NodeA and NodeB in terms of frequency distribution across the three operation types of file reading, database querying, and file writing is calculated as follows:

[0075] ;

[0076] The Euclidean distance between NodeA and NodeC is calculated as follows:

[0077] ;

[0078] Set a cluster radius threshold The threshold of 5.0 was determined by statistically analyzing the differences in behavior between nodes at the same level under normal operating conditions, taking the maximum distance within the 99% confidence interval as the benchmark, and adding a 10% margin on this basis. After a week of actual operation verification, this threshold can effectively distinguish between normal fluctuations and abnormal outlier behavior. Based on this threshold, the distance between Node A and Node B is 2.45, which is less than 5.0, indicating that their behavior patterns are similar. The distance between Node A and Node C is 22.34, which is greater than 5.0. Therefore, Node C is marked as an outlier node. After identifying outlier nodes, they are classified according to their behavioral characteristics.

[0079] The specific classification rules are as follows:

[0080] Operation type offset category: If the frequency of an outlier node in one or several types of operations deviates significantly from the average value of nodes at the same level, for example, the file write frequency of NodeC is 20 times, which is much higher than the average level of NodeA and NodeB ((5+4) / 2=4.5), but the abnormal interruption flag is not prominent, it is classified into this category.

[0081] Abnormal trigger surge category: If the frequency of abnormal interruption flags (such as "IO_error" or "Network_timeout") in the behavior segment of an outlier node is significantly higher than that of nodes at the same level, for example, if NodeA has "IO_error" and its frequency is higher than that of other nodes at the same level, then it is classified into this category.

[0082] Access Target Concentration Category: If the access requests of outlier nodes to a specific resource or target appear abnormally concentrated within a unit of time, such as NodeA frequently accessing a single database table in a short period of time, then it is classified into this category. NodeC is classified as "Operation Type Offset Category" due to its significant offset in file write frequency.

[0083] Finally, a node behavior outlier comparison table is generated, which records outlier nodes, their outlier types, and related behavioral characteristics.

[0084] The lookup table optimization submodule calls the node behavior outlier lookup table, performs merging processing on outlier nodes in adjacent topological positions within the same category, eliminates misjudgments caused by local communication jitter, and outputs the node behavior outlier lookup table.

[0085] The system invokes a node behavior outlier lookup table, which lists nodes marked as outliers and their outlier categories. For example, if the lookup table shows that NodeC is identified as an outlier node of the "Operation Type Offset" category, NodeD is also identified as an outlier node of the "Operation Type Offset" category. It iterates through each outlier node in the lookup table, searching for outliers belonging to the same outlier category and being topologically adjacent. Topologically adjacent nodes are defined as having a network hop count of less than or equal to 2 between the two nodes, or sharing the same physical switch / router. For example, NodeC and NodeD both belong to the "Operation Type Offset" category. A query using the data center topology information shows that NodeC is located in rack R1-U10, network port eth0, and NodeD is located in rack R1-U11, network port eth1. They are physically adjacent and share the same access switch, thus being topologically adjacent. If NodeC and NodeD are topologically adjacent and have the same outlier category, the submodule performs a combined operation on the two outlier nodes. The two are then processed and analyzed as a whole, recorded in a lookup table with a unified identifier (e.g., "NodeC-D_Group"). The outlier characteristics will be an aggregation of the behavioral characteristics of the two nodes. The merging process eliminates misjudgments caused by brief fluctuations in local network links, sudden surges in traffic, or competition for shared resources. Factors that cause adjacent nodes to exhibit similar "outlier" characteristics in a short period of time are not independent fundamental anomalies. For example, a momentary failure of a network switch can cause multiple server nodes connected to it to simultaneously exhibit "access target concentration" outlier behavior. Through merging, it is identified that the linkage effect is caused by a single network device failure. An optimized node behavior outlier lookup table is output. This table records outlier nodes or outlier node groups, reflecting the actual abnormal behavior patterns in the data center. For example, the output results are: outlier node group (NodeC-D_Group, operation type offset class), outlier node (Node_E, abnormal trigger surge class).

[0086] Specifically, such as Figure 2 , 6 As shown, the causal gradient calibration module includes:

[0087] The event chain parsing submodule calls the node behavior outlier lookup table, extracts the event trigger timestamp, resource usage identifier and execution completion status from the operation logs of outlier nodes and related nodes, and constructs a multi-level event dependency chain in chronological order.

[0088] The system calls an outlier lookup table for node behavior, such as outlier node groups (NodeC-D_Group, operation type offset class) and outlier nodes (Node_E, abnormal trigger surge class). For each outlier node or outlier node group, it extracts event trigger timestamps, resource usage indicators, and execution completion status from its own operation logs and those of its related nodes with direct or indirect communication or resource dependencies. Related nodes refer to nodes that have communicated with, shared resources with, or have a parent-child process relationship with outlier nodes in the recent past. For example, NodeC-D_Group is a web server, and related nodes include the backend database server NodeDB1 and the file storage server Node_FS1. The extracted event information includes event trigger timestamps (accurate to milliseconds), resource usage indicators (e.g., CPU utilization, memory usage, disk I / O, network bandwidth), and event execution completion status (e.g., success, failure, timeout). For example, the event "File write @2025-12-08_1" can be extracted from the NodeC operation log. 0:30:15.123, Resource usage: CPU 80%, Memory 60%, Status: Success, Extracted event from the associated node NodeDB1 log: Database Insert @2025-12-08_10:30:15.345, Resource usage: CPU 70%, Memory 50%, Status: Success. After extracting all relevant events, the submodule strictly follows the order of event triggering time to construct a multi-level event dependency chain. This dependency chain is an ordered sequence of events, reflecting the temporal and causal relationships between events. By analyzing the event trigger timestamp, resource usage identifier, and execution completion status, for example, if the NodeC file write event (high resource usage) is followed by the NodeDB1 database insert event, and the CPU utilization of NodeDB1 also increases accordingly, a dependency relationship of "NodeC file write → NodeDB1 database insert" is constructed. The dependency chain can be multi-level, such as "user request → Web server processing → application server call → database query → file storage", forming a refined multi-level event dependency chain.

[0089] The rate of change calculation submodule calls the multi-level event dependency chain to count the change in the frequency of the same event pair in the dependency chain within adjacent periods, analyzes the multi-level event pairs, and generates a set of event dependency rate of change.

[0090] Invoke a multi-level event dependency chain, which records the precise timing and dependencies of events between outlier nodes and their associated nodes, such as within the current monitoring period. Within, there exist events... , indicating an event Caused the incident For example, events such as (NodeC file writing, NodeDB1 database insertion) occur, and the submodule statistics are collected in two adjacent monitoring periods. and In this context, the frequency of a specific event pair occurring in the dependency chain, such as in a cycle... In the previous cycle, the event pair (NodeC file write, NodeDB1 database insert) occurred 150 times. In this context, the event pair occurs 100 times. Based on frequency, the change in frequency of the same event pair in the dependency chain is calculated. This change is determined by the absolute value of the difference between the frequency of the event pair in the current period and the frequency in the previous period. For example, for the event pair (NodeC file write, NodeDB1 database insert), its frequency in the current period... The frequency of occurrence within the period is 150, in the previous period If the frequency of occurrence within a given element is 100, then the change in its frequency is: This means that the frequency of the event pair increased by 50 times between the two periods, and the dependency became active. The submodule performs the same analysis process on all multi-level event pairs, calculating their frequency change within adjacent periods. For example, for an event chain (NodeC file write, NodeDB1 database insert, NodeFS1 file synchronization), if its frequency changes within the two periods... It appeared 30 times. If it occurs 20 times, then its change is: The frequency changes of all calculated event pairs are aggregated to form the event-dependent rate of change set. The results show that a large change in the frequency of event pairs indicates potential changes in behavioral patterns or risks.

[0091] The weight reallocation submodule calls the event dependency change rate set, sets the causal change threshold, and when the change rate of any event pair exceeds the preset threshold for two consecutive periods, it performs incremental adjustment on its weight in the event dependency matrix. The increment is proportional to the change rate, and outputs the data center operation risk evolution trend assessment result.

[0092] The event-dependent rate of change set is invoked, which contains the frequency change of each event pair within adjacent periods. For example, the rate of change for the event pair (NodeC file write, NodeDB1 database insert) is 50, and the rate of change for the event pair (NodeA service call, NodeB response) is 10. A causal rate of change threshold is set. The threshold of 40 is determined through backtracking analysis of historical data center failure events and expert experience. It is found that when the rate of change of an event pair exceeds 40 for two consecutive periods, it indicates an impending service degradation or failure in 90% of cases. The threshold has undergone three months of actual operational testing and verification to ensure its effectiveness under different business loads. The submodule iterates through each event pair in the event dependency rate of change set, checking whether its rate of change exceeds the preset causal rate threshold for two consecutive periods. For example, for event pairs (NodeC file write, NodeDB1 database insert), if in the current cycle The rate of change is 50, and in the previous cycle The rate of change is 45. Since 50 is greater than 40 and 45 is greater than 40, this event's rate of change exceeds the threshold for two consecutive periods. Therefore, its weight in the event dependency matrix is ​​adjusted incrementally. The increment is proportional to the rate of change, and is calculated as a proportionality coefficient multiplied by the rate of change. Set to 0.01, this proportional coefficient is calibrated based on historical weight adjustment effects and system response sensitivity. At that time, the weight adjustment reflects the changes promptly and without being too drastic. The event pair (NodeC file write, NodeDB1 database insert) has an original weight of 0.7 in the event dependency matrix, a current rate of change of 50, and an incremental adjustment value of [value missing]. The adjusted new weights are This indicates that the causal strength of the event has significantly increased. For an event pair (NodeA calls the service, NodeB responds), if its current periodic change rate is 10 and does not exceed the threshold of 40, the weight remains unchanged. Dynamic adjustment makes the weights in the event dependency matrix reflect the strength and evolution trend of the causal relationship in real time, and outputs the data center operation risk evolution trend assessment results. The results include the updated event dependency matrix, in which high-weight event pairs indicate potential risk points or abnormal evolution paths. For example, the assessment results show that the dependency strength between "NodeC file writing" and "NodeDB1 database insertion" has increased, indicating abnormal database load.

[0093] Specifically, such as Figure 2 , 7 As shown, the risk storage isolation module includes:

[0094] The location information extraction submodule calls the data center operation risk evolution trend assessment results, queries the rack number, U-position height and network port number of the risk event chain related nodes from the data center asset management, and combines them to generate the physical location coordinates of the nodes;

[0095] The system retrieves the data center operational risk evolution trend assessment results, which identify high-risk event chains and their associated nodes. For example, the assessment identifies a high-risk event chain of "NodeC file write → NodeDB1 database insertion," involving two associated nodes: NodeC and NodeDB1. The submodule then queries the data center asset management system (AMS) to retrieve the physical location information of the nodes associated with the risk event chain. The AMS is a database that centrally stores detailed information about all hardware devices. For instance, for node NodeC, the query reveals its rack number as "R1-05," its unit height as "12U," and its network... The port number is "eth0 / 0 / 1". For node NodeDB1, its rack number is "R1-06", U-position height is "20U", and network port number is "eth0 / 0 / 2". The extracted rack number, U-position height, and network port number are combined. For example, the physical location coordinates of NodeC are represented as (R1-05, 12U, eth0 / 0 / 1), and the physical location coordinates of NodeDB1 are represented as (R1-06, 20U, eth0 / 0 / 2). The coordinate information is stored in a structured form for subsequent risk isolation zone division, and the physical location coordinates of the nodes are output.

[0096] The isolation zone division submodule calls the physical location coordinates of the nodes, calculates the three-dimensional spatial distance between any two high-risk nodes, and assigns nodes whose distance is less than the isolation radius threshold to the same risk isolation storage zone, thus obtaining an independent storage logical volume identifier.

[0097] The module retrieves the physical coordinates of the nodes, which identify the physical locations of nodes associated with the high-risk event chain. For example, NodeC's physical coordinates are (R1-05, 12U, eth0 / 0 / 1), and NodeDB1's physical coordinates are (R1-06, 20U, eth0 / 0 / 2). Assuming another high-risk node, NodeA, has physical coordinates of (R1-05, 10U, eth0 / 0 / 0), the submodule calculates the three-dimensional spatial distance between any two high-risk nodes. This calculation considers rack number, U-position height, and network port number. If the two nodes are in the same rack, the distance calculation primarily considers the U-position height difference. If they are not in the same rack, the physical distance between racks and network hop count are introduced. The U-position distance between NodeC (R1-05, 12U) and NodeA (R1-05, 10U) is... If 1U is considered the standard height unit, and assuming the U-bay spacing within the rack is equivalent to 0.05 meters, then the physical distance is... The height difference at the U-position between NodeC and NodeDB1 (R1-06, 20U) is... Considering the physical distance between adjacent cabinets is 1 meter, the calculated three-dimensional spatial distance is approximately 1.077m. The submodule sets an isolation radius threshold of 0.5 meters. This threshold is determined comprehensively based on factors such as electromagnetic interference, heat diffusion effects, and physical safety distances within the data center. Multiple simulation experiments and actual tests have shown that nodes with a distance of less than 0.5 meters have a risk of physical coupling, such as cable crossings or poor heat dissipation leading to cascading failures. A week of experiments verified that this threshold effectively identifies node groups that require physical isolation. According to the threshold, the distance between NodeC and NodeA is less than 0.5 meters (0.1 meters), so they are classified into the same risk isolation storage area. The distance between NodeC and NodeDB1 is greater than 0.5 meters (1.077 meters), so they are not classified into the same isolation storage area. For nodes classified into the same risk isolation storage area, an independent storage logical volume identifier is assigned to them. For example, NodeC and NodeA are assigned to the logical volume "LV-RISK-001". Their logs and other critical data are written to this independent storage space, achieving physical and logical isolation from other normal storage areas in the data center, resulting in an independent storage logical volume identifier, such as (LV-RISK-001).

[0098] The path adjustment submodule calls the independent storage logical volume identifier, modifies the LUN mapping table in the storage controller, redirects the log writing path of high-risk nodes to the logical volume of the corresponding isolation zone, prohibits cross-zone data merging operations, and outputs a data center risk data isolation storage solution.

[0099] The module calls the independent storage logical volume identifier, such as "LV-RISK-001," which corresponds to a group of high-risk nodes, such as NodeC and NodeA. It then calls the LUN (Logical Unit Number) mapping table in the storage controller. The LUN mapping table records how server storage requests are mapped to backend physical storage resources. For example, the original mapping instructs NodeC logs to be written to " / var / log / nodeC / ," corresponding to LUNID100. LUNID100 maps to a physical disk in the shared storage pool. The submodule modifies the LUN mapping table, redirecting the log write path for high-risk nodes (such as NodeC and NodeA) to the "LV-RISK-001" independent isolation logical volume. It updates the NodeC log write path, changing it from the original " / var / log / nodeC / " to a subdirectory under the new isolation logical volume "LV-RISK-001," such as " / LV-RISK-001 / nodeC_logs / ." Finally, it updates the storage controller configuration to ensure that NodeC and... NodeA log data is written to this isolated logical volume. High-risk node log data is physically separated from normal node data. At the same time, any cross-isolation zone data merging operation is prohibited. For example, any attempt to merge or share data in "LV-RISK-001" with data in normal logical volumes in the data center will be rejected by the storage controller. The prohibition measures ensure the independence of data within the isolation zone and prevent potential malicious behavior or erroneous operations from causing risky data to be mixed with normal data. For example, even if an application attempts to merge NodeC log data with data from a public analytics platform, this operation will not be completed because cross-zone data merging is prohibited. The data center risk data isolation storage solution is output. This solution details the high-risk nodes, the corresponding isolated logical volume identifiers, and the specific LUN mapping modification rules and data merging prohibition policies. For example, the solution specifies that NodeC and NodeA log data are redirected to "LV-RISK-001", and this logical volume is prohibited from being merged with normal logical volumes such as "LV-NORMAL-001".

[0100] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A data risk perception and assessment system for data centers, characterized in that, The system includes: The communication state mapping module calculates the communication changes of node pairs in adjacent time windows based on the traffic sequence of the server node and switch interface, identifies sudden communication behavior, divides low, medium and high disturbance areas, counts the node connection density in the area and performs spatial filtering to obtain the communication state partitioning results. Based on the communication state partitioning results, the weight dynamic configuration module assigns high communication weights to node pairs in high-disturbance areas, performs periodic weight rotation on node pairs in medium-disturbance areas, and updates the weights of node pairs in low-disturbance areas only when the communication relationship undergoes a structural change, thereby generating a node communication weight dataset. The behavior outlier identification module calls the node communication weight dataset, extracts the access operation type sequence and abnormal trigger record of the node per unit time, clusters the nodes according to the difference in operation distribution, filters the nodes that deviate from the cluster center, and constructs a node behavior outlier comparison table. The causal gradient calibration module analyzes the event triggering sequence relationship between nodes based on the node behavior outlier comparison table, sets a causal change threshold, performs weight reallocation on event chains that exceed the causal change threshold, and outputs the data center operation risk evolution trend assessment result.

2. The data risk perception and assessment system for data centers according to claim 1, characterized in that: The communication state partitioning results include low-disturbance regions, medium-disturbance regions, and high-disturbance regions. The node communication weight dataset includes high communication weight regions, periodically rotating weight regions, and structurally updated weight regions. The node behavior outlier comparison table includes operation type distribution offset node units, abnormal trigger frequency sudden increase node units, and access target concentration abnormal node units. The data center operation risk evolution trend assessment results include event dependency chain change trends, node communication weight evolution trajectories, causal change thresholds, and high-risk event chain sets.

3. The data risk perception and assessment system for data centers according to claim 1, characterized in that: The communication state mapping module includes: The communication change calculation submodule obtains the number of communication packets and transmitted bytes of each pair of server nodes within the time window through the hardware monitoring unit, identifies the communication change in adjacent windows, determines the communication disturbance intensity based on the magnitude of the change, and generates node communication disturbance values. The state region partitioning submodule calls the node communication disturbance value, sets a grade boundary according to the disturbance intensity, classifies node pairs with disturbance values ​​below the first boundary threshold into the low disturbance region, those between the first and second boundary thresholds into the medium disturbance region, and those above the second boundary threshold into the high disturbance region, counts the number of spatial connections of node pairs in the region, and forms the communication state partitioning result. The density filtering submodule calls the communication state partitioning results, calculates the number of node pairs within a unit topological distance of the region, removes isolated node pairs in sparsely connected regions, retains regions with connection density higher than a preset density threshold, and outputs the communication state partitioning results.

4. The data risk perception and assessment system for data centers according to claim 3, characterized in that: The weight dynamic configuration module includes: The weight level setting submodule calls the communication state partitioning results, assigns an initial high communication weight value to the high disturbance area, assigns a medium communication weight value to the medium disturbance area and binds a rotation cycle identifier, assigns a basic communication weight value to the low disturbance area and marks it as a static weight state, and generates a node communication weight level table. The weight update execution submodule calls the node communication weight level table. At the beginning of each rotation cycle, it adjusts the communication weight values ​​of node pairs in the medium disturbance area. When the communication structure of node pairs in the low disturbance area changes, it recalculates their communication weight values. The communication weight values ​​of node pairs in the high disturbance area are accumulated in real time according to the amount of communication change, and the node communication weight dataset is output.

5. The data risk perception and assessment system for data centers according to claim 4, characterized in that: The adjustment of the communication weight value of the node pair in the disturbance area refers to the linear increase or decrease of the communication weight value based on the communication change of the previous cycle at the beginning of each rotation cycle, while keeping the adjustment range within 20% of the basic communication weight value, to obtain the communication weight value of the node pair in the disturbance area.

6. The data risk perception and assessment system for data centers according to claim 4, characterized in that: The behavior outlier identification module includes: The operation sequence extraction submodule reads the access instruction type, resource request identifier and abnormal interruption flag within a unit time from the operation log buffer of the server node according to the node communication weight dataset, arranges them in chronological order, removes the same instruction segments in the sequence, and obtains the effective behavior segments. The outlier clustering submodule calls the effective behavior fragment, calculates the Euclidean distance between the node and the node at the same level on the frequency distribution of operation type, marks the node with a distance exceeding the clustering radius threshold as an outlier, and classifies it according to operation type offset class, abnormal trigger surge class, and access target set class, and generates a node behavior outlier comparison table. The lookup table optimization submodule calls the node behavior outlier lookup table to perform merging processing on outlier nodes in adjacent topological positions within the same category, eliminating misjudgments caused by local communication jitter, and outputting the node behavior outlier lookup table.

7. The data risk perception and assessment system for data centers according to claim 6, characterized in that: The causal gradient calibration module includes: The event chain parsing submodule calls the node behavior outlier lookup table, extracts the event trigger timestamp, resource usage identifier and execution completion status from the operation logs of outlier nodes and related nodes, and constructs a multi-level event dependency chain in chronological order. The rate of change calculation submodule calls the multi-level event dependency chain to count the change in the frequency of the same event pair in the dependency chain within adjacent periods, analyzes the multi-level event pairs, and generates a set of event dependency rate of change. The weight reallocation submodule calls the event dependency change rate set, sets the causal change threshold, and when the change rate of any event pair exceeds the preset threshold for two consecutive periods, it performs incremental adjustment on its weight in the event dependency matrix. The increment is proportional to the change rate, and outputs the data center operation risk evolution trend assessment result.

8. The data risk perception and assessment system for data centers according to claim 1, characterized in that: The system also includes a risk storage isolation module: Based on the data center operation risk evolution trend assessment results, the risk storage isolation module extracts the physical location information of nodes in the high-risk event chain, identifies the deployment coordinates of nodes in the rack, divides the risk isolation storage area according to the coordinate proximity, adjusts the logical mapping path of the storage device, and generates a data center risk data isolation storage solution.

9. The data risk perception and assessment system for data centers according to claim 8, characterized in that: The data center risk data isolation and storage solution includes risk isolation storage area division, logical mapping path adjustment, node physical location information extraction, and deployment coordinate identification.

10. The data risk perception and assessment system for data centers according to claim 8, characterized in that: The risk storage isolation module includes: The location information extraction submodule calls the data center operation risk evolution trend assessment results, queries the rack number, U-position height and network port number of the risk event chain related nodes from the data center asset management, and combines them to generate the physical location coordinates of the nodes; The isolation zone division submodule calls the physical location coordinates of the nodes, calculates the three-dimensional spatial distance between any two high-risk nodes, and assigns nodes whose distance is less than the isolation radius threshold to the same risk isolation storage zone to obtain an independent storage logical volume identifier. The path adjustment submodule calls the independent storage logical volume identifier, modifies the LUN mapping table in the storage controller, redirects the log writing path of high-risk nodes to the logical volume of the corresponding isolation zone, prohibits cross-zone data merging operations, and outputs a data center risk data isolation storage solution.

Images