A distributed data storage exception identification system for server operation and maintenance security

Abstract

The application relates to the technical field of distributed storage, and discloses a distributed data storage exception identification system for server operation and maintenance safety, which comprises a storage gateway node, a data calculation node, a cluster controller and a replica node. The storage gateway node is used for receiving an external client write request and generating an authorized write credential. The data calculation node is combined with the authorized write credential and extracted physical and network characteristic data to execute state calculation and generate a state isolation signal. In response to the signal, an unauthorized overwrite operation is redirected to a shadow snapshot branch, an isolation synchronization queue is generated, and a node isolation event is submitted when the isolation synchronization queue is subjected to safety analysis and continuously meets a risk judgment condition. The cluster controller receives the event to generate a node isolation and service redirection instruction. The replica node responds to the instruction to take over business data read-write traffic. The application realizes real-time identification and isolation of underlying abnormal writing, prevents data tampering under the premise of not blocking normal business, and guarantees service continuity of a storage cluster.

Description

Technical Field

[0001] This invention relates to the field of distributed storage technology, specifically to a distributed data storage anomaly identification system for server operation and maintenance security. Background Technology

[0002] In the daily operation and maintenance of servers in distributed data storage systems, security measures for storage clusters are mostly focused on network perimeter defense and access control for front-end business applications. As the scale of the storage cluster expands, internal vulnerabilities or unauthorized access leading to unauthorized write operations pose internal risks that could compromise data integrity.

[0003] For this type of internal security threat at the operational level, existing protection methods typically involve deploying log auditing systems or relying on front-end traffic characteristics for monitoring. These methods focus on post-event recording and analysis. When unauthorized overwrite operations bypass front-end verification and directly affect the underlying physical space, existing systems cannot identify and block them in real time before the data is tampered with.

[0004] Meanwhile, existing protection mechanisms typically intercept requests or sever node network connections when abnormal writes are detected. This approach blocks normal read and write requests as well, causing read and write timeouts in upper-layer applications, corruption of the underlying data structure of the storage volume, and inconsistencies in cross-node data synchronization. When a single storage node experiences continuous internal write anomalies, existing mechanisms struggle to simultaneously isolate the problematic node and schedule other healthy replica nodes to take over the read and write traffic, resulting in compromised service continuity of the storage cluster. Summary of the Invention

[0005] The technical problem addressed by this invention is that existing distributed data storage systems lack real-time detection and isolation mechanisms for underlying storage write anomalies when facing internal server security threats. Traditional security protection relies on routine log analysis or boundary traffic monitoring. When unauthorized overwrite operations bypass front-end verification and directly affect the underlying storage, it is difficult to block them before data corruption occurs, and direct interception strategies can lead to business interruption or compromised data consistency.

[0006] To address the above problems, the present invention provides the following technical solution:

[0007] This invention provides a distributed data storage anomaly identification system for server operation and maintenance security, comprising:

[0008] The storage gateway node is used to receive write requests from external clients and generate authorized write credentials.

[0009] The data computing node is used to combine the authorized write credential with the extracted physical and network feature data to perform state calculations and generate a state isolation signal; in response to the state isolation signal, it redirects the unauthorized overwrite operation to the shadow snapshot branch and generates an isolation synchronization queue; and submits a node isolation event to the outside world when the isolation synchronization queue is subjected to security analysis and the security risk judgment conditions are continuously met.

[0010] The cluster controller is used to receive the node isolation event and generate node isolation and service redirection instructions;

[0011] The replica node is used to take over business data read and write traffic in response to the node isolation and service redirection instructions.

[0012] The core principle of this invention is to perform correlation verification calculations between the authorization credentials issued by the front-end gateway and the physical and network characteristics extracted from the underlying storage nodes. When the underlying write status does not match the authorization status, a state isolation signal is triggered, and a shadow snapshot branch is established using copy-on-write technology. The system redirects unauthorized overwrite operations to this branch and generates a queue for asynchronous security review in the isolated state. If the review continuously meets the security risk assessment conditions, the problematic node is isolated by the cluster controller, and the normal replica takes over the business data read and write traffic. This mechanism achieves the identification and environmental isolation of abnormal writes at the underlying level, while maintaining the continuous operation of the cluster's services.

[0013] Preferably, the data computing node is equipped with a probe acquisition module, an authorization ledger module, an anomaly detection module, a snapshot management module, a routing scheduling module, and a fault tolerance and recovery module. The data computing node stores the authorization write credentials through the authorization ledger module, extracts the physical and network feature data through the probe acquisition module, performs state calculations to generate the state isolation signal through the anomaly detection module, establishes the shadow snapshot branch through the snapshot management module, redirects the unauthorized overwrite operation and generates the isolation synchronization queue through the routing scheduling module, and performs the security analysis and submits the node isolation event to the outside world through the fault tolerance and recovery module.

[0014] Furthermore, the probe acquisition module is used to extract physical and network feature data:

[0015] Monitor the underlying physical space within a fixed time window and collect underlying status indicators generated by cross-network synchronization tasks.

[0016] The equivalent redundancy amplification factor is calculated by calling the storage policy configuration parameters at the cluster level and combining them with the underlying status indicators using the equivalent redundancy calculation formula.

[0017] The underlying state indicators are encapsulated and output as physical and network feature data, and the equivalent redundancy amplification coefficient is also output.

[0018] Furthermore, the anomaly detection module is used to combine the authorized writing credential with the extracted physical and network feature data to perform state calculations and generate a state isolation signal:

[0019] The overwrite allocation surge rate is calculated by combining the aggregated authorized write rate of the authorized write credential with the physical and network characteristic data using the overwrite allocation surge rate calculation formula;

[0020] The redundant synchronous back pressure difference is calculated using the redundant synchronous back pressure difference state equation by combining the physical and network characteristic data with the equivalent redundancy amplification factor.

[0021] The state isolation signal is triggered when the overwrite allocation surge rate is greater than a preset surge safety threshold and the redundant synchronization back pressure difference is greater than a preset back pressure safety threshold.

[0022] The surge security threshold and the back pressure security threshold are threshold conditions for determining that a data computing node has an unauthorized internal write anomaly.

[0023] Furthermore, the snapshot management module is used to establish a shadow snapshot branch in response to a state isolation signal:

[0024] In response to the state isolation signal, a write fence is set in the managed write path to record the current frozen epoch;

[0025] The underlying storage engine solidifies the mapping structure of the current frozen epoch to form a protected reference root pointer;

[0026] The shadow snapshot branch is created using copy-on-write technique, based on the protected reference root pointer.

[0027] Furthermore, the routing and scheduling module is used to redirect unauthorized overwrite operations to the shadow snapshot branch and generate an isolated synchronization queue:

[0028] For write requests attempting to enter the authoritative commit path of the primary data volume, perform authorization matching to identify the unauthorized overwrite operation;

[0029] The unauthorized overwrite operation is redirected to the shadow snapshot branch to generate an isolated transaction identifier;

[0030] Based on the isolation transaction identifier, the corresponding cross-network synchronization task is stripped and transformed into an interception task;

[0031] The interception task is pushed into the isolation synchronization queue.

[0032] Furthermore, the routing scheduling module is further used for the isolated synchronization queue to:

[0033] Extract the intercepted tasks from the isolation synchronization queue and calculate the local isolation completion waiting time using the isolation state local completion delay formula;

[0034] After the local isolation completion waiting time has expired, a local isolation completion signal is sent to the isolation transaction manager of the shadow snapshot branch;

[0035] The local isolation completion signal causes the corresponding isolated write transaction to enter a pending verification state.

[0036] Furthermore, the fault-tolerant recovery module is used to perform security analysis on the isolated synchronization queue:

[0037] After the preset observation window ends, read the records in the isolation synchronization queue to extract the intercepted records to be reviewed;

[0038] The interception record to be reviewed is compared with the updated authorization writing credential in a second asynchronous comparison to generate comparison and verification parameters.

[0039] Based on the comparison and verification parameters, the confidence score of the current isolation batch is calculated using the confidence verification formula.

[0040] Furthermore, the fault-tolerant recovery module is further used based on the verification confidence score for:

[0041] The verification confidence score is compared with a preset judgment threshold, and the verification conclusion is output.

[0042] When the verification result is that the merging condition is met, the metadata increments that have passed the authorization verification in the shadow snapshot branch are merged into the root pointer structure of the primary data volume;

[0043] When the verification result indicates that the merging conditions are not met, cancel the entry address of the shadow snapshot branch and delete the corresponding isolated transaction index;

[0044] The preset judgment threshold is used to determine whether the current isolated batch meets the merging conditions.

[0045] Furthermore, the module collaboration relationship for submitting node isolation events and having replica nodes take over business data read / write traffic when the security risk assessment conditions are continuously met is as follows:

[0046] The fault tolerance and recovery module submits the node isolation event to the cluster controller when it determines that the security risk determination condition is continuously met.

[0047] The cluster controller receives the node isolation event and generates the node isolation and service redirection instructions by updating the data shard ownership relationship according to the authoritative replica status.

[0048] The replica node responds to the node isolation and service redirection command to exclude illegal write transactions in the isolation synchronization queue and take over the business data read and write traffic.

[0049] The security risk determination conditions include: isolation batches failing to meet merging conditions within multiple consecutive observation windows, unauthorized write anomalies continuously occurring, or the capacity status and network transmission status of the data computing node continuously exceeding a preset risk threshold.

[0050] This invention provides a distributed data storage anomaly identification system for server operation and maintenance security. It has the following beneficial effects:

[0051] 1. This invention correlates the authorized write credentials generated by the storage gateway node with the physical and network feature data extracted by the data computing node to obtain the overwrite allocation surge rate and the redundant synchronization back pressure difference, thereby triggering a state isolation signal when the underlying write state and authorized status are inconsistent. This mechanism changes the traditional system's reliance on delayed log analysis or boundary monitoring, and achieves real-time identification of unauthorized overwrite operations that bypass front-end verification and directly affect the underlying layer.

[0052] 2. Upon responding to the state isolation signal, this invention establishes a shadow snapshot branch based on the baseline root pointer, redirects unauthorized overwrite operations to this branch, and generates an isolated synchronization queue for asynchronous review. This method isolates suspicious requests from the main data path without blocking normal business writes, avoiding data structure damage or state inconsistencies caused by direct interception strategies, and completing operation blocking before data tampering occurs.

[0053] 3. This invention performs confidence verification on the isolated synchronization queue. When it is determined that the data computing node continuously meets the security risk assessment conditions, it submits a node isolation event, and the cluster controller schedules replica nodes to take over the business read and write traffic. When the underlying storage node faces internal operation and maintenance security threats, this process can promptly separate the problematic node from the authoritative data shard ownership relationship, relying on healthy replica nodes to maintain data access, thus ensuring the service continuity of the storage cluster. Attached Figure Description

[0054] Figure 1 This is a diagram of the distributed data storage anomaly identification system for server operation and maintenance security according to the present invention.

[0055] Figure 2 This is a flowchart illustrating the overall workflow of the present invention;

[0056] Figure 3 This is a data flow interaction diagram for state acquisition and feature extraction in this invention;

[0057] Figure 4 This is a timing interaction diagram of the state calculation and anomaly joint determination of the present invention;

[0058] Figure 5 This is a pipeline diagram of the architecture reconstruction and interception isolation state of the present invention;

[0059] Figure 6 This is a flowchart of the verification closed-loop and fault-tolerant recovery process of the present invention;

[0060] Figure 7 This is a simulation data relationship diagram of the system anomaly identification and fault-tolerant recovery of the present invention. Detailed Implementation

[0061] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] See attached document Figure 1 This invention provides a distributed data storage anomaly identification system for server operation and maintenance security, including a storage gateway node, a data computing node, several replica nodes, and a cluster controller. Data computing nodes and replica nodes establish data synchronization connections through a data plane network, while data computing nodes, replica nodes, and the cluster controller establish management and control connections through a control plane network.

[0063] The storage gateway node receives write requests from external clients and generates authorized write credentials for write links that pass the verification after completing identity token verification, access permission verification, or session validity verification.

[0064] The data computing node is internally deployed with a probe acquisition module, an authorization ledger module, an anomaly detection module, a snapshot management module, a routing scheduling module, and a fault tolerance and recovery module. The data computing node receives and stores authorization write credentials through the authorization ledger module, and continuously extracts physical and network feature data of the underlying physical space within a fixed time window through the probe acquisition module.

[0065] The anomaly detection module combines physical and network feature data with the execution status calculation of the authorized write credential and generates a status isolation signal when the calculated value exceeds a preset threshold condition.

[0066] The snapshot management module freezes the current master data volume root pointer structure in response to the status isolation signal and uses this to create a shadow snapshot branch;

[0067] The routing and scheduling module, deployed in the storage service write path, volume management layer write path, or block device filter driver path of the data compute node, performs authorization matching for underlying write requests that can still be identified as pending write transactions by the data compute node. For write transactions that lack valid authorization matching and have not yet entered the authoritative commit log of the primary data volume, the routing and scheduling module marks them as isolated write transactions and forces their write target to be rewritten from the primary data volume to the shadow snapshot branch. At the same time, the routing and scheduling module removes the replica synchronization task associated with the isolated write transaction from the regular replica sending path and pushes it into an isolated synchronization queue that does not participate in the authoritative consistency commit of the primary data volume.

[0068] The fault tolerance and recovery module performs security analysis on the records in the isolation synchronization queue and generates verification conclusions after the preset observation window ends. When the verification conclusion is valid, it merges the metadata increments that have passed authorization verification in the shadow snapshot branch into the root pointer structure of the primary data volume and writes them into the authoritative commit log of the primary data volume. When the verification conclusion is invalid, it deletes the metadata references of the shadow snapshot branch and cleans up the corresponding isolation transaction indexes. When the data computing nodes continuously meet the security risk judgment conditions, it submits node isolation events to the cluster controller.

[0069] After the cluster controller issues node isolation and service redirection instructions, the replica node updates the data shard ownership relationship, read / write service endpoint or replica set master node status according to the authoritative replica status stored in the replica node, so that the replica node takes over the business data read / write traffic originally carried by the data computing node; among them, illegal write transactions in the isolation synchronization queue are not used as the authoritative data source when the replica node takes over.

[0070] In this embodiment, unauthorized overwrite behavior refers to a write request that bypasses the authorization link of the storage gateway node but still enters the storage service write path, volume management layer write path, or block device filter driver path of the data compute node, and can be identified by the data compute node as a write transaction to be processed. For offline physical media overwriting, raw disk random writing, or hardware-level media anomalies that are completely detached from the managed write path of the data compute node, this system can supplement the processing through media integrity verification, replica consistency verification, or offline recovery procedures. However, such behaviors are not the main focus of authorization credential matching and isolation synchronization queue processing in this embodiment.

[0071] See attached document Figure 2 The distributed data storage anomaly identification method for server operation and maintenance security provided by this invention includes the following processing stages:

[0072] S1, Status Acquisition Phase: The storage gateway node processes compliant link write requests and generates authorized write credentials, while the probe acquisition module monitors the underlying status of the data computing node in parallel and extracts physical and network feature data.

[0073] S2, Anomaly Detection Phase: The anomaly detection module combines the authorized writing credential with physical and network characteristic data to perform state calculations. When the calculated value exceeds a preset threshold, a state isolation signal is triggered.

[0074] In S3, during the architecture refactoring phase, the snapshot management module responds to the state isolation signal by freezing the metadata of the primary data volume and creating a shadow snapshot branch. The routing scheduling module intercepts unauthorized overwrite operations and imports them into the shadow snapshot branch, while generating interception tasks and pushing them into the isolation synchronization queue.

[0075] S4, the fault tolerance and recovery phase: The fault tolerance and recovery module performs security analysis on the isolated synchronization queue and obtains the verification conclusion. When the verification conclusion is valid, the isolated write transactions that have passed the authorization verification are merged into the primary data volume and regular replica synchronization is restored. When the verification conclusion is invalid, the metadata reference of the shadow snapshot branch is deleted and the primary data volume namespace is rolled back. When the data computing node continuously meets the security risk judgment conditions, the fault tolerance and recovery module submits a node isolation event to the cluster controller, which triggers the replica node to take over the business traffic.

[0076] See attached document Figure 3 The status acquisition phase is step S1, which includes the following sub-steps.

[0077] S11, Establish the authorization context.

[0078] During the status acquisition phase, when processing distributed storage services, the data computing node, through its internally deployed probe acquisition module, collaborates with the external storage gateway node to monitor the underlying physical allocation status and network synchronization status.

[0079] Data compute nodes and replica nodes can be built based on Ceph, GlusterFS, or other distributed storage architectures. In such architectures, the input and output streams processed by the underlying block devices typically do not directly carry identity tokens or authorization contexts from higher-level application network protocols. Therefore, the underlying storage engine finds it difficult to distinguish between external compliant writes and internal unauthorized overwrites based solely on block-level write requests. To ensure that underlying write requests have verifiable authorization basis, this embodiment constructs an authorization context sinking mechanism.

[0080] Upon receiving a write request from an external client, the storage gateway node parses the application layer payload using the network protocol stack and verifies the identity token carried by the external client. After successful authentication, the storage gateway node generates an authorized write credential for this compliant write request. The authorized write credential includes an object identifier, fragment identifier, logical address range, request timestamp, credential validity period, write data length, request sequence number, and credential authentication fields.

[0081] As a preferred approach, after receiving the authorization write credential, the data computing node generates or supplements the physical allocation unit mapping digest based on the mapping relationship between the logical address range and the physical allocation unit maintained locally, and writes the physical allocation unit mapping digest into the authorization ledger module.

[0082] The credential authentication field is a signature information generated by the storage gateway node based on a shared key, asymmetric private key, or message authentication code algorithm. It is used to verify the source and integrity of the authorized write credential. The specific implementation of signature generation, signature verification, and key management can be configured by those skilled in the art based on existing security protocols; its specific implementation is well-known in the field and will not be elaborated upon here.

[0083] The storage gateway node distributes the authorization write credentials to the corresponding data compute node. The data compute node uses the authorization ledger module to build a searchable authorization index based on the object identifier, fragment identifier, logical address range, and request sequence number, so as to match it with the underlying write request later.

[0084] S12, calculate the aggregated authorized write rate.

[0085] To cover legitimate write traffic from multiple service entry points, the authorization ledger module obtains the authorized write rates of legitimate entry points such as storage gateway nodes, backup agent nodes, and management console within the current time window, and sums the scalar values ​​of each authorized write rate to obtain the aggregated authorized write rate of the data computing node within the current time window.

[0086] In scenarios where object storage, block storage, and file storage coexist, the authorization ledger module converts authorization write credentials generated at different entry points into a unified authorization write index based on the mapping relationships maintained by the data computing nodes from objects to shards, shards to logical address ranges, and logical address ranges to allocation units. This allows subsequent underlying write requests to perform consistency matching according to the unified index structure.

[0087] S13, collect underlying physical allocation characteristics.

[0088] The probe acquisition module is deployed at a bypass location on the managed write path of the data compute node. The managed write path includes at least one of the following: kernel volume management layer, block device filter driver layer, object write path of storage service process, storage engine allocator path, and replica synchronization task generation path. When the data compute node processes the underlying write transactions entering the managed write path, the storage engine maintains the original data state according to its configured write-time redirection mechanism, write-time replication mechanism, or object allocation mechanism.

[0089] In managed write paths employing write-time redirection, write-time replication, or object append allocation mechanisms, the storage engine typically requests new physical allocation units or updates differential mapping records before updating data corresponding to existing logical addresses. Therefore, unauthorized overwrite behavior entering the managed write path of a data compute node without matching valid authorization write credentials will manifest as an abnormal increase in the number of new allocation units or differential mapping updates within the corresponding time window.

[0090] For storage paths employing in-situ overwrite mechanisms, the probe acquisition module can use block mapping update counts, write amplification statistics, or media integrity verification results as alternative features. For raw disk random writes or offline media rewriting behaviors that completely bypass the managed write path of the data computing node, the system can treat them as media integrity anomalies or replica consistency anomalies and handle them separately. Such behaviors are not considered as overwrite transactions based on authorized credential matching in this step.

[0091] The probe acquisition module listens for allocation unit request events, object extent update events, snapshot differential mapping update events, or block device mapping table update events within a fixed time window through kernel tracing hooks, user-space storage service probes, storage engine allocator callback interfaces, or block device filter drivers, and extracts the number of new allocation units in the underlying physical space. The number of new allocation units is used to represent the actual number of times the underlying physical storage resources are consumed within this fixed time window due to write transactions entering the managed write path.

[0092] S14, Collect network synchronization characteristics.

[0093] The probe acquisition module monitors the underlying network protocol stack of the data computing nodes in parallel. Under the set distributed multi-replica strategy, each compliant logical write will generate cross-node synchronization traffic of a corresponding scale according to the storage pool configuration. If a partial overwrite occurs within the data computing node that enters the managed write path but does not match a valid authorized write credential, the storage engine may identify the partial overwrite as a pending write transaction before performing isolation processing, and generate a corresponding replica synchronization task, thereby creating internal synchronization backpressure that does not match the external authorized write rate.

[0094] The probe acquisition module identifies deviations from the authorized write baseline by monitoring the generation rate, queuing rate, or sending rate of replica synchronization tasks. After completing the local block data write, the data compute node pushes the data synchronization task to several replica nodes according to the distributed consistency protocol. The probe acquisition module extracts statistical information from the replica synchronization task queue, storage service network sending queue, message transport layer queue, kernel flow control queue, or local network card sending queue to calculate the redundant synchronization queuing rate of cross-network synchronization tasks within the same fixed time window.

[0095] The redundancy synchronization queuing rate is used to characterize the actual network bandwidth usage of data computing nodes outputting data copies to the external network. The probe acquisition module defines the number of newly allocated units and the redundancy synchronization queuing rate as low-level status indicators, and encapsulates these low-level status indicators as physical and network feature data to the anomaly detection module.

[0096] S15, determine the equivalent redundancy amplification factor.

[0097] The underlying synchronization scale of a single compliance logic write varies depending on the storage pool configuration. To ensure that subsequent anomaly detection can adapt to replicated storage pools, erasure coding storage pools, compression and deduplication scenarios, and background recovery scenarios, the data computing node retrieves the cluster-level storage policy configuration parameters and uses the equivalent redundancy calculation formula to calculate the equivalent redundancy amplification factor in the current operating environment. The equivalent redundancy calculation formula is as follows:

[0098] ;

[0099] in, Indicates the equivalent redundancy amplification factor;

[0100] This represents the basic synchronization factor, and its value is determined based on the redundant synchronization enqueue rate. The statistical scope is determined. When When only counting the cross-node synchronization traffic output from the compute node to the remote replica node, if the total number of replicas in the replica storage pool is... ,but Values ;when When calculating the equivalent replication workload resulting from local writes and synchronization with remote replicas, Values For erasure coding storage pools, The number of data slices that need to be sent across nodes in each stripe can be determined, and the additional synchronization overhead caused by erasure coding verification slices is determined by... Make corrections;

[0101] This represents the deduplication and compression loss factor, and its value ranges from 0 to 1 (positive real number). The data compute node reads the storage engine's capacity statistics, calculates the ratio between the physical occupied capacity and the logical write capacity, and uses this ratio as the deduplication and compression loss factor; when the ratio is greater than 1, it will... Cut off to 1;

[0102] This represents the state recovery correction factor, and its value is a positive real number greater than or equal to 1. When the distributed cluster is in a healthy state, the data computing nodes will... Set to 1; when a failed disk repair, data rebalancing, or replica rebuild thread is detected to be active, the data compute node determines the ratio of input / output bandwidth used by the background recovery task. As a preferred method, Determined according to the following formula:

[0103] ;

[0104] in, This indicates the input / output bandwidth used by the background recovery task within the current time window. This indicates the input / output bandwidth used by foreground service writes within the current time window; when When the value is 0, the data calculation node is determined using a preset upper limit value or the valid value of the previous time window. ;

[0105] This represents the erasure coding check slice penalty factor, and its value is a positive real number greater than or equal to 1. For a conventional replicated storage pool, the data compute node will... The value is 1; for a storage pool with erasure coding enabled, if each stripe includes Data slices and For each verification slice, the data computation node is determined according to the following formula. :

[0106] ;

[0107] in, The number of data slices in each erasure code stripe. The number of parity slices in each erasure code stripe; Indicates the basic transmission loss; This indicates the amount of penalty correction in the background.

[0108] See attached document Figure 4 The anomaly determination stage is step S2, which specifically includes the following sub-steps.

[0109] S21, calculate the overwrite allocation surge rate.

[0110] The anomaly detection module receives physical and network characteristic data transmitted by the probe acquisition module and calls the aggregated authorization write rate provided by the authorization ledger module to jointly calculate the underlying allocation status and network synchronization status of the data computing node within the current time window.

[0111] The anomaly detection module reads the minimum allocation granularity based on the storage configuration of the currently running data compute node. When the data compute node hosts a data volume based on a local file system, the minimum allocation granularity can be the block size configured for the XFS or EXT4 file system; when the data compute node hosts a data volume based on an object storage engine or a block storage engine, the minimum allocation granularity can be the object extent size, the storage pool allocation unit size, or the block device logical allocation unit size.

[0112] The anomaly detection module will aggregate the authorized write rate. Divide by minimum allocation granularity Obtain compliant allocation rate Simultaneously, the number of newly allocated units within the current time window is extracted from physical and network characteristic data. and will Divide by the time window length To obtain the actual allocation rate Subsequently, the anomaly detection module determines the overwrite allocation surge rate according to the overwrite allocation surge rate calculation formula. :

[0113] ;

[0114] in, Indicates the rate of overwrite allocation surge; This indicates the number of newly allocated units within the current time window; Indicates the length of the time window; Indicates the aggregated authorized write rate; Indicates the smallest allocation granularity; This indicates the operation of taking the larger value.

[0115] Through the above calculations, the anomaly detection module can obtain the degree of deviation between the actual allocation frequency of the underlying physical space and the upper-layer compliant authorized write baseline.

[0116] S22, calculate the redundant synchronous back pressure difference.

[0117] In a distributed storage environment, there is a correspondence between the amount of legitimate logical writes at the upper layer and the replication synchronization traffic. This correspondence is affected by replication policies, erasure coding policies, compression and deduplication policies, and network protocol overhead. Therefore, when performing anomaly detection, the anomaly detection module calculates not only the degree of deviation in the underlying physical allocation but also the network backpressure state in the replication synchronization path.

[0118] The anomaly detection module extracts redundant synchronization enqueue rates from physical and network feature data. And combined with the equivalent redundancy amplification factor obtained by the data computing node during the status acquisition phase. Calculate the redundant synchronous back pressure difference according to the state equation of the redundant synchronous back pressure difference. The state equation for redundant synchronous back pressure difference is:

[0119] ;

[0120] in, Indicates redundant synchronous back pressure difference; Indicates the redundant synchronization enqueue rate; Indicates the aggregated authorized write rate; Indicates the equivalent redundancy amplification factor; Indicates the proportion of network protocol header overhead; This indicates the theoretically compliant synchronization rate.

[0121] As a preferred method, the anomaly detection module counts the total length of replica synchronization messages within the current time window. and payload length The network protocol header overhead ratio is determined according to the following formula. :

[0122] ;

[0123] in, Indicates the total length of replica synchronization messages within the current time window; This indicates the total length of the payload in the replica synchronization messages within the current time window. The range of values ​​for is a real number greater than or equal to 1. When When the value is 0, the anomaly detection module does not update the current time window. The value is set, and the calculation of redundant synchronous back pressure difference within that time window is stopped, or the value of the previous valid time window is used. The value is calculated.

[0124] S23, Execute joint judgment of abnormality.

[0125] The anomaly detection module will overwrite the allocation surge rate. Compare with a preset surge safety threshold and use redundant synchronous back pressure differential. The result is compared with a preset back pressure safety threshold. To reduce the impact of system jitter on the judgment result during low-flow periods, the anomaly judgment module only... and If all values ​​are positive, an over-threshold determination is performed.

[0126] When the overwrite allocation rate surges The voltage difference exceeds the surge safety threshold and is redundant synchronous back pressure difference. When the back pressure exceeds the safety threshold, the anomaly detection module determines that the data computing node has an unauthorized internal write anomaly and triggers a state isolation signal.

[0127] As a preferred approach, the anomaly detection module can require the above two indicators to meet the threshold condition within multiple consecutive time windows before triggering the state isolation signal, in order to reduce the probability of misjudgment caused by short-term jitter, instantaneous retransmission, or instantaneous queue accumulation.

[0128] S24, Execute capacity warning auxiliary judgment.

[0129] In scenarios involving continuous unauthorized overwrites, if the managed write path employs write-time redirection, write-time replication, or object append allocation mechanisms, the remaining space in the underlying physical storage pool may decrease within a short period. Therefore, the anomaly detection module also obtains the current used capacity and remaining available capacity of the storage pool through the system kernel interface, storage engine capacity statistics interface, or cluster management interface, and compares them with preset capacity warning conditions.

[0130] Capacity warning conditions include: used capacity exceeding 80% to 90% of the total physical capacity, or remaining available capacity falling below 10% to 20% of the total physical capacity. These numerical ranges can be configured based on storage pool type, peak business write speeds, and background recovery strategies.

[0131] When the capacity warning condition is met and the overwrite allocation surge rate is reached... Or redundant synchronous back pressure difference When the corresponding safety threshold is exceeded within multiple consecutive time windows, the anomaly detection module outputs a status isolation signal and sends a network rate limiting request command to the cluster controller through the control plane network.

[0132] Network rate limiting request commands are used to restrict the outbound bandwidth of suspicious replica synchronization tasks that have not yet completed authorization verification, abnormally growing network sending queues, or pending tasks associated with isolated write transactions in data compute nodes. For normal write transactions that have passed authorization verification, data compute nodes still perform replica synchronization according to the cluster replica policy; for interception tasks that have entered the isolated synchronization queue and do not participate in the regular network sending path, the routing scheduling module maintains their isolation status and no longer treats them as outbound rate limiting targets.

[0133] See attached document Figure 5 The architecture refactoring phase is step S3, which includes the following sub-steps.

[0134] S31, set the write fence and solidify the frozen epoch.

[0135] During the architecture refactoring phase, the snapshot management module and routing scheduling module deployed within the data computing node isolate the metadata status of the primary data volume and subsequent write paths after receiving the status isolation signal triggered by the anomaly judgment module.

[0136] After responding to the state isolation signal, the snapshot management module first sets a write barrier on the managed write path of the data compute node, causing new write transactions to wait for authorization verification by the routing scheduling module before entering the authoritative commit path of the primary data volume. For write transactions that have entered the commit path but have not yet been completed, the snapshot management module performs transaction marking, log emptying, or isolation transfer processing.

[0137] The snapshot management module records the current freeze epoch of the primary data volume and reads the current root pointer of the B+ tree, LSM-Tree, object mapping table, or snapshot differential mapping structure maintained in the underlying storage engine, thus solidifying it into a base root pointer corresponding to that freeze epoch. The base root pointer is marked as protected and used to create shadow snapshot branches and perform subsequent rollbacks; this base root pointer does not restrict legitimate write transactions that have passed authorization verification from continuing to commit on the new primary data volume's active root pointer.

[0138] S32, create a shadow snapshot branch.

[0139] The snapshot management module creates shadow snapshot branches based on a protected base root pointer using copy-on-write technology. These shadow snapshot branches physically share the original data blocks prior to the freeze point, but logically have independent metadata mapping spaces and isolated transaction logs.

[0140] Writes made in the shadow snapshot branch are not written to the authoritative commit log of the primary data volume until they have completed security verification and been confirmed as mergingable by the fault tolerance and recovery module. They do not serve as the authoritative data source when replica nodes take over operations, nor do they appear as a committed state of the primary data volume. Therefore, subsequent write transactions that have not completed authorization verification can be imported into a separate branch without changing the baseline state of the primary data volume corresponding to the frozen epoch.

[0141] S33, Perform authorization verification on write requests.

[0142] After the shadow snapshot branch is established, the routing and scheduling module intervenes in the managed write path of the data compute node, performing authorization verification on write requests attempting to enter the authoritative commit path of the primary data volume. For read requests, the routing and scheduling module determines whether to allow them based on whether the accessed object belongs to the authoritative namespace of the primary data volume; by default, the isolated write results in the shadow snapshot branch are not visible to external clients.

[0143] The routing and scheduling module extracts matching fields from intercepted write requests based on their deployment location. When deployed on a storage service write path or a volume management layer write path, it extracts the object identifier, fragment identifier, logical address range, write length, request timestamp, and request sequence number. When deployed on a block device filter driver path, it looks up the corresponding object identifier or fragment identifier based on the volume identifier, logical block address, block length, and the address mapping table maintained by the data compute node.

[0144] For underlying write requests where the object identifier cannot be retrieved, the routing and scheduling module uses the volume identifier, logical address range, and write length as the authorization matching primary key. The authorization matching process includes address range coverage verification, credential validity verification, request sequence number continuity verification, credential authentication field verification, and write length consistency verification.

[0145] When the routing scheduling module is deployed on the block device filter driver path and cannot directly obtain the request sequence number or object identifier, the routing scheduling module performs reverse index matching in the authorization ledger module based on the volume identifier, logical block address, block length, and time window. When the corresponding field cannot be reverse looked up or the reverse lookup result is not unique, the routing scheduling module marks the write request as a request to be isolated for verification and imports it into the shadow snapshot branch.

[0146] S34, redirect unauthorized write transactions.

[0147] When the verification result shows that at least one of the following fails the verification: address range, write length, credential validity period, request sequence number, or credential authentication field of the underlying write request, the routing scheduling module identifies the write request as an unauthorized overwrite operation.

[0148] For write requests identified as unauthorized overwrite operations, the routing scheduling module calls the mapping redirection interface provided by the snapshot management module, or updates the snapshot differential mapping table of the storage engine, to map the logical address corresponding to the write request to the isolated allocation unit in the shadow snapshot branch, so that it is stored on disk in the shadow snapshot branch.

[0149] S35, strip the replica synchronization task and build an isolated synchronization queue.

[0150] In distributed storage systems, local write operations typically trigger remote replica synchronization based on the system's configured consistency protocol or replica synchronization strategy. To prevent isolated write transactions from entering the regular replica synchronization path of the primary data volume, the routing and scheduling module generates an isolated transaction identifier for the write request when redirecting it to the shadow snapshot branch. The isolated transaction identifier is associated with at least the volume identifier, logical address range, write length, request timestamp, and shadow snapshot branch identifier.

[0151] The routing and scheduling module identifies the corresponding cross-network synchronization task based on the isolation transaction identifier and removes the cross-network synchronization task from the regular network sending queue. As an optional implementation, the routing and scheduling module can construct an isolated synchronization queue independent of the regular network plane in the kernel reserved memory, paged memory, shared memory ring buffer, BPF mapping structure, or storage service process-in-process isolated queue of the data computing node.

[0152] The stripped cross-network synchronization tasks are converted into intercept tasks and pushed into the isolation synchronization queue. The intercept tasks in the isolation synchronization queue are only used for subsequent security verification and state recovery decisions. They are not written to the authoritative replica log of the primary data volume, do not participate in the commit confirmation between replica nodes, and are not seen as committed write results by external clients.

[0153] S36, Perform speculative local maintenance confirmation.

[0154] To reduce the long-term occupation of waiting resources by isolated write transactions within the shadow snapshot branch, the routing and scheduling module implements a speculative local maintenance and acknowledgment mechanism adapted for isolated write transactions. This mechanism is only used to release waiting resources within the shadow snapshot branch and push isolated write transactions into a pending verification state; it does not constitute a write completion acknowledgment to external clients.

[0155] After detecting that the interception task has entered the isolation synchronization queue, the routing scheduling module does not send a path submission feedback confirmation of replica persistence to the primary data volume authority, nor does it declare to external clients that the write transaction has completed multi-replica commit; the routing scheduling module only generates a local isolation completion flag for the isolation write transaction within the shadow snapshot branch, which is used to release waiting resources within the isolation branch.

[0156] To ensure that the scheduling rhythm of isolated write transactions within the shadow snapshot branch is similar to that of the normal replica synchronization path, and to reduce the impact of isolation processing on local thread scheduling and queue statistics, the data compute node uses the isolated-state local completion delay formula to calculate the local isolation completion waiting time of the currently intercepted task. The isolated-state local completion delay formula is as follows:

[0157] ;

[0158] in, Indicates the waiting time for local quarantine to be completed; Indicates the average network round-trip time; This represents the time delay fluctuation characteristic operator, whose value range is a positive real number greater than 0 and less than or equal to 1; This represents the jitter of a single synchronization task, which is obtained by the data computing node within the most recent normal synchronization windows. It can be the standard deviation, mean absolute deviation, or preset quantile difference of the network round-trip delay of the synchronization task. This represents the speculative state correction.

[0159] Based on the calculated local isolation completion wait time, the routing scheduling module only sends a local isolation completion signal to the isolation transaction manager of the shadow snapshot branch after the corresponding wait time has expired, causing the isolation write transaction to transition from the waiting state to the pending verification state. The local isolation completion signal is not equivalent to the primary data volume write completion confirmation, nor is it equivalent to the replica node's persistence confirmation, nor does it change the primary data volume state visible to external clients.

[0160] See attached document Figure 6 The fault-tolerant recovery phase is step S4, which specifically includes the following sub-steps.

[0161] S41, determine the observation window and perform a second comparison.

[0162] During the fault tolerance and recovery phase, the fault tolerance and recovery module deployed within the data computing node asynchronously reviews the interception tasks in the isolated synchronization queue and drives the metadata merging or namespace rollback of the shadow snapshot branch based on the review results.

[0163] After the preset observation window ends, the fault-tolerant recovery module reads the interception task records from the isolation synchronization queue. Considering the potential arrival order discrepancies between authorized packets and data packets in a distributed network, the length of the observation window is determined based on historical network latency and latency fluctuations. As a preferred approach, the observation window length... Determined according to the following formula:

[0164] ;

[0165] in, This represents the average arrival time difference between grant messages and data messages within a few recent normal synchronization windows. The standard deviation of the time difference of arrival. This represents the magnification factor of the observation window, and its value is a real number greater than 0.

[0166] Within the observation window, the fault tolerance and recovery module receives the updated authorization write credential from the authorization ledger module and uses the records in the isolated synchronization queue as intercept records to be reviewed. The fault tolerance and recovery module performs a secondary asynchronous comparison between the intercept records to be reviewed and the updated authorization write credential to generate comparison verification parameters; the comparison verification parameters include object identifier, fragment identifier, logical address range, write length, request timestamp, request sequence number, and credential authentication field.

[0167] S42, Calculate the verification confidence score.

[0168] The fault tolerance and recovery module uses a confidence verification formula to calculate the verification confidence score of the current isolation batch. The confidence verification formula is:

[0169] ;

[0170] in, This indicates the confidence score of the test. This indicates the total number of tasks contained in the isolation synchronization queue; Indicates the first Authorization matching operator for the task; Indicates the first Weight of the number of data blocks or the length of data written for each task; Indicates the first The time validity weighting coefficient for each task.

[0171] When the When the task and the authorization write credential match successfully, The value is 1; when the first When no authorized write credential is matched for the task, The value is 0. A successful match means that the object identifier, fragment identifier, logical address range, write length, request timestamp, request sequence number, and credential authentication field of the task meet the verification conditions of the corresponding authorized write credential in the authorization ledger module.

[0172] when At this time, the fault tolerance and recovery module does not perform confidence calculation and marks the current isolation batch as an empty batch, or waits for the next observation window to recalculate.

[0173] In the confidence level verification formula above, This indicates the size of the isolated data after authorization matching and time validity correction. This represents the total size of all data corresponding to the tasks awaiting verification in the isolation synchronization queue.

[0174] Time validity weighting coefficient The value of is a real number greater than or equal to 0 and less than or equal to 1. When the ... When a task matches the corresponding authorized write credential, the fault tolerance and recovery module calculates the absolute time offset between the task's timestamp and the corresponding authorized write credential generation time. Sure As a preferred method, Determined according to the following formula:

[0175] ;

[0176] in, Indicates the first The absolute time offset between the task timestamp and the corresponding authorized write credential generation time. Indicates the length of the observation window. This indicates the operation of taking the larger value. When the first... When no authorized write credential is matched for the task, If the value is 0, this task will not be included in the effective authorized data scale.

[0177] S43, Generate verification conclusion.

[0178] The fault-tolerant recovery module will calculate the verification confidence score. Compare with a preset judgment threshold. If If the value is greater than or equal to the judgment threshold, a verification conclusion is generated that the current isolation batch meets the merging conditions; in subsequent merging processes, only the isolation write transactions that have passed the authorization verification are allowed to be merged into the primary data volume.

[0179] like If the value is less than the judgment threshold, a verification conclusion is generated that the current isolated batch does not meet the merging conditions, and the process proceeds to the shadow snapshot branch rollback.

[0180] S44, perform metadata merging when the merging conditions are met.

[0181] When the current isolation batch meets the merge conditions, the fault tolerance and recovery module verifies whether there is any logical overlap between the physical block address range corresponding to the write transaction to be merged in the shadow snapshot branch and the latest metadata status of the primary data volume. If there is logical overlap or index conflict, the corresponding write transaction will not enter the merge process.

[0182] After confirming that there are no index conflicts, the fault tolerance and recovery module calls the atomic swap interface of the underlying storage engine to merge the metadata increments that have passed authorization verification in the shadow snapshot branch into the root pointer structure of the primary data volume, and writes the corresponding write transactions into the authoritative commit log of the primary data volume. For isolated write transactions that have not passed authorization verification, even if there is no address conflict with the primary data volume, they are not merged into the primary data volume.

[0183] After the merge is complete, the fault tolerance and recovery module re-marks the isolation tasks that have passed authorization verification and have been written to the authoritative commit log of the primary data volume as legitimate synchronization tasks. Subsequently, the routing and scheduling module pushes the legitimate synchronization task into the regular replica send queue according to the current replica policy to execute subsequent replica synchronization.

[0184] S45 performs a namespace rollback if the merge conditions are not met.

[0185] When the current isolation batch does not meet the merge conditions, the fault recovery module performs shadow snapshot branch reference deletion and namespace rollback processing. Since the base root pointer corresponding to the frozen epoch has been marked as protected, and the isolated write transactions in the shadow snapshot branch have not been written to the authoritative commit log of the primary data volume, the fault recovery module unregisters the entry address of the shadow snapshot branch and deletes the corresponding isolation transaction index through the file system metadata manager, object mapping manager, or snapshot differential mapping manager, thereby restoring the logical namespace to the protected state at the time the state isolation signal was triggered.

[0186] The rollback process described above does not require synchronous erasure of physical data blocks in the shadow snapshot branch. For any remaining physical blocks after the rollback, the data compute nodes perform asynchronous scanning and capacity release via a background garbage collection thread.

[0187] During the rollback process, the fault tolerance and recovery module issues a cleanup command to the routing scheduling module to clear the isolation task records that have not passed authorization verification and cancel the corresponding isolation transaction index in the shadow snapshot branch.

[0188] For tasks that have matched authorized write credentials but were not merged into the primary data volume because the overall confidence level of the current isolation batch is below the judgment threshold, the fault tolerance and recovery module records the object identifier, logical address range, write length, request sequence number, and credential index before deregistering the shadow snapshot branch entry address, and marks it as a task to be replayed. When the storage gateway node has the corresponding write payload or request replay log, the storage gateway node reissues it according to the request sequence number; when the storage gateway node does not have the corresponding write payload, the client re-initiates the write request according to the business protocol. Such tasks are not considered committed data on the primary data volume until they are re-authorized and verified and written to the primary data volume's authoritative commit log.

[0189] S46 triggers node isolation and business takeover.

[0190] When the fault tolerance and recovery module determines that the data computing node continuously meets the security risk assessment conditions, it submits a node isolation event to the cluster controller through the control plane network. The continuous meeting of security risk assessment conditions includes: isolation batches failing to meet merging conditions within multiple consecutive observation windows, unauthorized write anomalies continuously occurring, or the capacity status and network transmission status of the data computing node continuously exceeding a preset risk threshold.

[0191] The cluster controller updates the service status of data compute nodes based on the current replica distribution status, authoritative replica logs, and data shard ownership, and triggers replica set re-election, server endpoint redirection, or data shard migration.

[0192] When the authoritative and consistent replicas stored on the replica nodes meet the takeover conditions, the replica nodes take over the business data read and write traffic originally carried by the data compute nodes, according to the takeover instructions issued by the cluster controller. Illegal write transactions in the isolation synchronization queue do not participate in this takeover process, nor are they considered the authoritative data source during replica node takeover. Through this process, the system can shorten the downtime for external client access in abnormal write scenarios and improve the business continuity of the storage cluster.

[0193] Specific application examples:

[0194] See attached document Figure 7 To further illustrate the feasibility and effectiveness of the technical solution in this embodiment, the following description is provided in conjunction with specific simulation test scenarios and numerical calculation processes:

[0195] In this embodiment, a distributed storage cluster with 50 data nodes is selected as the simulation test environment. It is assumed that the system is in a stable operating period, and the aggregated authorized write rate received by the storage gateway node is... The speed is 100MB / s. At this point, the underlying physical storage pool employs a 3-replica strategy, with redundant synchronization of the enqueue rate. The statistical definition is the cross-node synchronization traffic output from the primary replica node to the remote replica node, therefore the base synchronization multiple. The value is 2.

[0196] Combined with deduplication and compression loss factor State recovery correction factor and erasure coding verification slice penalty factor The equivalent redundancy amplification factor is obtained by using the equivalent redundancy calculation formula. for:

[0197] ;

[0198] Considering the proportion of network protocol header overhead The theoretical compliant synchronization rate at this point is estimated to be 168 MB / s using the redundant synchronization back pressure difference state equation. If the probe acquisition module detects the redundant synchronization enqueue rate at this time... The speed was increased to 400MB / s, and the actual underlying allocation rate deviated from the compliance benchmark. The anomaly detection module calculated the redundant synchronous back pressure difference. for:

[0199] ;

[0200] When the difference exceeds the preset back pressure safety threshold, the system immediately triggers a state isolation signal.

[0201] After entering the isolation phase, the routing scheduling module performs shadow snapshot branch redirection for captured unauthorized overwrite operations. To reduce the long-term resource consumption of isolated transactions within data computing nodes, the system performs speculative local maintenance confirmation. Assume the current average network round-trip latency... The time delay fluctuation characteristic operator is 2ms. The jitter value is 0.5, representing the jitter of a single synchronization task. The value is 0.4ms. Substituting this into the formula for the local completion delay in isolated state, we obtain the local isolation completion waiting time. for:

[0202] ;

[0203] After a delay of 2.2ms, the system sends a local isolation completion signal to the isolation transaction manager of the shadow snapshot branch. Monitoring data shows that during this period, the waiting queue depth inside the isolation branch remains within the normal range, and there is no risk of resource exhaustion due to long-term suspension of isolation transactions.

[0204] After the isolation observation period ends, the fault tolerance and recovery module extracts a total of 1000 data blocks of interception tasks from the isolation synchronization queue (i.e., After two asynchronous verifications, 200 tasks with a data block size found corresponding credentials in subsequent authorization messages, and the average time validity weighting coefficient for these tasks was 0.9; the remaining 800 tasks with a data block size did not find matching authorization write credentials. Substituting these values ​​into the confidence verification formula, the following was calculated:

[0205] ;

[0206] Since the verification confidence score of 0.18 is lower than the preset judgment threshold of 0.95, the fault tolerance and recovery module generates an illegal verification conclusion, triggers the metadata unchaining operation, causes the main data volume status to roll back, and blocks the abnormal data generated by the unauthorized overwrite request.

[0207] Figure 7 This illustrates the relationship between security verification confidence and the ratio of authorized matching and the weighting coefficient of time validity. Figure 7 In the diagram, the 3D surface at the bottom represents the verification confidence score, which fluctuates with the authorized matching ratio and the time validity weighting coefficient. This value is calculated using the confidence verification formula. The transparent horizontal plane above the surface represents the preset judgment threshold. The grayscale depth in the diagram characterizes the system's recognition range for abnormal behavior, and the intersection boundary between the surface and the threshold plane defines the critical point for judging legitimate operations and illegal tampering.

[0208] according to Figure 7As can be seen from the above simulation data, when the authorization matching ratio decreases and the time validity weight decreases, the verification confidence score decreases accordingly; when the verification confidence score is lower than the preset judgment threshold, the fault tolerance and recovery module generates an illegal verification conclusion and triggers the metadata unchaining process of the shadow snapshot branch.

[0209] In the verification test targeting unauthorized overwrite behavior within the system, the architecture refactoring mechanism of this embodiment can identify abnormal write transactions based on the authorization credential matching results, physical allocation characteristics, and redundant synchronous back pressure difference. When the test program attempts to bypass the authorization link of the storage gateway node and submits an unauthorized overwrite request through the local managed write path of the data compute node, the volume management layer interface, or the block device filtering path, the verification confidence score quickly drops below the judgment threshold because such requests cannot complete compliant authorization write credentials within the preset time window, thus triggering a rapid rollback based on metadata unlinking. In the test environment, this rollback process mainly involves the cancellation of the shadow snapshot branch entry address and the cleanup of the isolated transaction index. It does not require synchronous erasure of physical data blocks in the shadow snapshot branch. Therefore, the rollback time mainly depends on the metadata operation time and the scheduling cycle. For offline raw disk tampering behavior that completely bypasses the managed write path, the system can identify it separately through media verification, object verification, and replica consistency verification processes.

[0210] Compared to traditional architectures that rely solely on access control lists, this system uses a shadow snapshot branch as the carrier for suspicious write transactions when it detects an unauthorized overwrite operation. It also employs a speculative local maintenance and confirmation mechanism to release waiting resources within the isolated branch, effectively avoiding the problem of local threads or queues being occupied for a long time due to the interception of the synchronization link.

[0211] Simulation tests show that when unauthorized overwrite traffic of 50MB / s is continuously injected into the managed write path, the resource consumption of the data computing nodes remains stable within safe thresholds. Because this solution employs a joint judgment rule based on both physical allocation and network backpressure, it accurately intercepts abnormal writes at the underlying level. Unauthorized modified data is completely confined to the shadow snapshot branch, effectively avoiding the risk of contamination of the primary data volume's authoritative namespace. Furthermore, thanks to the dynamic evaluation of the verification confidence score and the secondary verification mechanism via the observation window, the system can effectively tolerate packet out-of-order delivery and delayed arrival caused by network jitter, significantly suppressing false positives and improving the distributed storage system's defense and self-healing capabilities against unauthorized internal network tampering or unexpected underlying overwrites.

Claims

1. A distributed data storage anomaly identification system for server operation and maintenance security, characterized in that, include: The storage gateway node is used to receive write requests from external clients and generate authorized write credentials. A data computing node is used to combine the authorized writing credential with the extracted physical and network feature data to perform state calculations and generate a state isolation signal; In response to the state isolation signal, the unauthorized overwrite operation is redirected to the shadow snapshot branch and an isolation synchronization queue is generated; When the isolation synchronization queue is subjected to security analysis and the security risk determination conditions are continuously met, a node isolation event is submitted to the outside. The cluster controller is used to receive the node isolation event and generate node isolation and service redirection instructions; The replica node is used to take over business data read and write traffic in response to the node isolation and service redirection instructions.

2. The distributed data storage anomaly identification system for server operation and maintenance security according to claim 1, characterized in that, The data computing node is equipped with a probe acquisition module, an authorization ledger module, an anomaly detection module, a snapshot management module, a routing scheduling module, and a fault tolerance and recovery module. The data computing node stores the authorization write credentials through the authorization ledger module, extracts the physical and network feature data through the probe acquisition module, performs state calculations to generate the state isolation signal through the anomaly detection module, establishes the shadow snapshot branch through the snapshot management module, redirects the unauthorized overwrite operation and generates the isolation synchronization queue through the routing scheduling module, and performs security analysis and submits the node isolation event to the outside world through the fault tolerance and recovery module.

3. The distributed data storage anomaly identification system for server operation and maintenance security according to claim 2, characterized in that, The probe acquisition module is used to extract physical and network feature data: Monitor the underlying physical space within a fixed time window and collect underlying status indicators generated by cross-network synchronization tasks. The equivalent redundancy amplification factor is calculated by calling the storage policy configuration parameters at the cluster level and combining them with the underlying status indicators using the equivalent redundancy calculation formula. The underlying state indicators are encapsulated and output as physical and network feature data, and the equivalent redundancy amplification coefficient is also output.

4. The distributed data storage anomaly identification system for server operation and maintenance security according to claim 3, characterized in that, The anomaly detection module is used to combine the authorized writing credential with the extracted physical and network feature data to perform state calculations and generate a state isolation signal: The overwrite allocation surge rate is calculated by combining the aggregated authorized write rate of the authorized write credential with the physical and network characteristic data using the overwrite allocation surge rate calculation formula; The redundant synchronous back pressure difference is calculated using the redundant synchronous back pressure difference state equation by combining the physical and network characteristic data with the equivalent redundancy amplification factor. The state isolation signal is triggered when the overwrite allocation surge rate is greater than a preset surge safety threshold and the redundant synchronization back pressure difference is greater than a preset back pressure safety threshold.

5. A distributed data storage anomaly identification system for server operation and maintenance security according to claim 2, characterized in that, The snapshot management module is used to establish a shadow snapshot branch in response to a state isolation signal. In response to the state isolation signal, a write fence is set in the managed write path to record the current frozen epoch; The underlying storage engine solidifies the mapping structure of the current frozen epoch to form a protected reference root pointer; The shadow snapshot branch is created using the protected base root pointer as a basis through copy-on-write technology.

6. A distributed data storage anomaly identification system for server operation and maintenance security according to claim 5, characterized in that, The routing and scheduling module is used to redirect unauthorized overwrite operations to the shadow snapshot branch and generate an isolated synchronization queue. For write requests attempting to enter the authoritative commit path of the primary data volume, perform authorization matching to identify the unauthorized overwrite operation; The unauthorized overwrite operation is redirected to the shadow snapshot branch to generate an isolated transaction identifier; Based on the isolation transaction identifier, the corresponding cross-network synchronization task is stripped and transformed into an interception task; The interception task is pushed into the isolation synchronization queue.

7. A distributed data storage anomaly identification system for server operation and maintenance security according to claim 6, characterized in that, The routing scheduling module is further used for the isolated synchronization queue to: Extract the intercepted tasks from the isolation synchronization queue and calculate the local isolation completion waiting time using the isolation state local completion delay formula; After the local isolation completion waiting time has expired, a local isolation completion signal is sent to the isolation transaction manager of the shadow snapshot branch; The local isolation completion signal causes the corresponding isolated write transaction to enter a pending verification state.

8. A distributed data storage anomaly identification system for server operation and maintenance security according to claim 2, characterized in that, The fault-tolerant recovery module is used to perform security analysis on the isolated synchronization queue. After the preset observation window ends, read the records in the isolation synchronization queue to extract the intercepted records to be reviewed; The intercepted record to be reviewed is compared with the updated authorization writing credential in a second asynchronous comparison to generate comparison and verification parameters. Based on the comparison and verification parameters, the confidence score of the current isolation batch is calculated using the confidence verification formula.

9. A distributed data storage anomaly identification system for server operation and maintenance security according to claim 8, characterized in that, The fault-tolerant recovery module is further used based on the verification confidence score for: The verification confidence score is compared with a preset judgment threshold, and the verification conclusion is output. When the verification result is that the merging condition is met, the metadata increments that have passed the authorization verification in the shadow snapshot branch are merged into the root pointer structure of the primary data volume; When the verification result indicates that the merging conditions are not met, the entry address of the shadow snapshot branch is cancelled and the corresponding isolated transaction index is deleted.

10. A distributed data storage anomaly identification system for server operation and maintenance security according to claim 2, characterized in that, The module collaboration relationship is as follows: When the security risk assessment conditions are continuously met, the node isolation event is submitted externally and the replica node takes over the business data read and write traffic: The fault tolerance and recovery module submits the node isolation event to the cluster controller when it determines that the security risk determination condition is continuously met. The cluster controller receives the node isolation event and generates the node isolation and service redirection instructions by updating the data shard ownership relationship according to the authoritative replica status. The replica node responds to the node isolation and service redirection command to exclude illegal write transactions in the isolation synchronization queue and take over the business data read and write traffic.

Images