A data management method, apparatus, device, and computer-readable storage medium

Abstract

This invention discloses a data management method, apparatus, device, and computer-readable storage medium, relating to the field of distributed storage technology. The method, applied to a distributed network device, includes: receiving traffic data packets of a target data block sent by a distributed storage node; determining the forwarding path of the traffic data packet based on the target flow label in the traffic data packet; if the forwarding path is a secondary verification path corresponding to cross-tenant traffic, accessing a metadata server to obtain the owner tenant identifier from the metadata of the target data block; and discarding the traffic data packet when the requesting tenant identifier in the traffic data packet differs from the owner tenant identifier in the metadata. This invention, by setting the target flow label in the payload header of the traffic data packet, enables the distributed network device to parse the target flow label to detect cross-tenant traffic, thereby triggering secondary verification of cross-tenant traffic, solving the problem of cross-node traffic mixing, and avoiding additional bandwidth overhead.

Description

Technical Field

[0001] This invention relates to the field of distributed storage technology, and in particular to a data management method, apparatus, device, and computer-readable storage medium. Background Technology

[0002] Distributed storage systems, as the mainstream large-scale storage systems, are widely used in cloud storage and big data scenarios, supporting multi-tenant sharing of storage resources. In multi-tenant scenarios, network isolation is required to ensure that data flows from different tenants do not interfere with each other, preventing cross-tenant data leakage or unauthorized access.

[0003] In related technologies, isolation schemes for distributed networks often rely on overlay technologies such as VLANs (Virtual Local Area Networks) and VXLANs (Virtual Extensible Local Area Networks), or access control lists (ACLs) based on IP (Internet Protocol) / ports. However, operations such as replica synchronization and data repair in distributed storage generate a large amount of traffic across OSD (Object Storage Device) nodes. Conventional network isolation strategies, based only on IP or ports, cannot accurately identify "tenant-specific traffic," resulting in mixed cross-tenant traffic and making it difficult to achieve "data-level" isolation, thus making cross-node traffic uncontrollable. Furthermore, tunneling technologies such as VXLAN require adding extra headers (such as an 8-byte VXLAN header) to data packets, which leads to packet bloat in distributed storage protocols and increases transmission latency.

[0004] Therefore, how to solve the problem of cross-node traffic mixing and avoid additional bandwidth overhead is an urgent issue that needs to be addressed. Summary of the Invention

[0005] The purpose of this invention is to provide a data management method, apparatus, device, and computer-readable storage medium to solve the problem of cross-node traffic mixing and avoid additional bandwidth overhead.

[0006] To address the aforementioned technical problems, this invention provides a data management method applied to distributed network devices, comprising:

[0007] Receive traffic data packets of target data blocks sent by distributed storage nodes; wherein, the traffic data packets include target flow tags, the target flow tags include the tenant identifier of the data block, and the target flow tags are flow tags on the payload header of the traffic data packets configured by the distributed storage nodes according to the metadata of the target data blocks;

[0008] The forwarding path of the traffic data packet is determined based on the target flow label in the traffic data packet;

[0009] If the forwarding path is a secondary verification path corresponding to cross-tenant traffic, then access the metadata server to obtain the owner tenant identifier in the metadata of the target data block; wherein, the cross-tenant traffic is a data packet requesting access to a data block that is not belonging to this tenant;

[0010] If the requesting tenant identifier in the traffic data packet is different from the home tenant identifier in the metadata, the traffic data packet is discarded.

[0011] On the other hand, determining the forwarding path of the traffic data packet based on the target flow label in the traffic data packet includes:

[0012] The forwarding path of the traffic data packet is determined based on the target flow label and the tenant allowed path policy table in the traffic data packet; wherein, the tenant allowed path policy table includes the allowed path corresponding to each tenant identifier, and the allowed path corresponding to the home tenant identifier of the target data block generated by the distributed storage node based on the target metadata of the target data block, network context and tenant behavior baseline.

[0013] On the other hand, determining the forwarding path of the traffic data packet based on the target flow label and the tenant allowed path policy table in the traffic data packet includes:

[0014] If the tenant identifier belonging to the target flow label is different from the tenant identifier requesting the traffic data packet, then the forwarding path is determined to be the secondary verification path;

[0015] If the home tenant identifier in the target flow label is the same as the requesting tenant identifier in the traffic data packet, then the forwarding path is determined as a target allowed path according to the target flow label in the traffic data packet and the tenant allowed path policy table; wherein, the target allowed path is any allowed path in the tenant allowed path policy table;

[0016] After determining the forwarding path of the traffic data packet based on the target flow label in the traffic data packet, the method further includes:

[0017] If the forwarding path is the target allowed path, then the traffic data packet is forwarded according to the target allowed path.

[0018] On the other hand, the target flow label also includes the operation type of the data block, and the tenant allowed path policy table includes the allowed paths corresponding to each tenant operation group, and each tenant operation group includes a tenant identifier and an operation type.

[0019] On the other hand, the method also includes:

[0020] The mapping relationship between high-frequency stream tags and corresponding allowed paths is cached; wherein, the high-frequency stream tag is the stream tag corresponding to the owner tenant whose access frequency is greater than a threshold within a preset time.

[0021] On the other hand, determining the forwarding path of the traffic data packet based on the target flow label in the traffic data packet includes:

[0022] The target flow tag is extracted from the traffic data packet using a hardware-accelerated regular expression engine.

[0023] On the other hand, determining the forwarding path of the traffic data packet based on the target flow label in the traffic data packet includes:

[0024] Based on the migration identifier in the target flow label, the forwarding path is determined to be a dedicated migration channel; wherein, the dedicated migration channel is a preset data forwarding channel outside the service traffic queue;

[0025] After determining the forwarding path of the traffic data packet based on the target flow label in the traffic data packet, the method further includes:

[0026] If the forwarding path is the dedicated migration channel, then the traffic data packets are forwarded through the dedicated migration channel.

[0027] On the other hand, the target stream label also includes the data block operation type and extended reserved field; the operation type is any preset operation type identifier, the preset operation type identifier includes read identifier, write identifier, delete identifier and replica synchronization identifier, the extended reserved field is empty or at least one preset extended identifier, the preset extended identifier includes the migration identifier.

[0028] On the other hand, the target flow label is 16 bytes long and also includes a data block type. The tenant identifier occupies 4 bytes, the data block type occupies 2 bytes, the operation type occupies 2 bytes, the extended reserved field occupies 8 bytes, and the data block type is any preset type.

[0029] The present invention also provides a data management device for use in distributed network equipment, comprising:

[0030] A data receiving module is used to receive traffic data packets of a target data block sent by a distributed storage node; wherein, the traffic data packet includes a target flow label, the target flow label includes the tenant identifier of the data block, and the target flow label is a flow label on the payload header of the traffic data packet configured by the distributed storage node according to the metadata of the target data block;

[0031] The path determination module is used to determine the forwarding path of the traffic data packet based on the target flow label in the traffic data packet;

[0032] The secondary verification module is used to access the metadata server and obtain the owner tenant identifier in the metadata of the target data block if the forwarding path is a secondary verification path corresponding to cross-tenant traffic; wherein, the cross-tenant traffic is a data packet requesting access to a data block that is not of the current tenant.

[0033] The traffic blocking module is used to discard the traffic data packet when the requesting tenant identifier in the traffic data packet is different from the home tenant identifier in the metadata.

[0034] This invention also provides a data management method applied to distributed storage nodes, comprising:

[0035] Receive an access request for a target data block sent by a client device; wherein the access request includes a request tenant identifier;

[0036] Based on the metadata of the target data block stored in the metadata server, configure the traffic data packet corresponding to the access request; wherein, the payload header of the traffic data packet includes a target flow label, and the target flow label includes the tenant identifier of the data block;

[0037] The traffic data packets are sent to a distributed network device so that the distributed network device blocks cross-tenant traffic based on the target flow label.

[0038] On the other hand, after receiving the access request for the target data block sent by the client device, the method further includes:

[0039] The allowed path corresponding to the home tenant identifier of the target data block is generated based on the target metadata, network context, and tenant behavior baseline of the target data block.

[0040] The allowed path is sent to the distributed network device so that the distributed network device can configure a tenant allowed path policy table based on the allowed path.

[0041] On the other hand, the target metadata includes the tenant identifier of the data block and historical anomaly records; the network context includes the authorized device detection results of the traffic source media access control address and the process surge detection results; the tenant behavior baseline includes historical access periods and common operation types.

[0042] On the other hand, the method also includes:

[0043] Based on the historical traffic information corresponding to the current tenant identifier, determine the high traffic time period corresponding to the current tenant identifier;

[0044] Based on the high-traffic period, adjust the allowed path corresponding to the current tenant identifier; wherein, during the high-traffic period, the bandwidth of the allowed path corresponding to the current tenant identifier is greater than the bandwidth of the allowed path corresponding to the current tenant identifier outside the high-traffic period.

[0045] On the other hand, the method also includes:

[0046] Obtain the migration event of the target data block;

[0047] Based on the migration event, a migration allowed path corresponding to the target home tenant identifier is configured and sent to the distributed network device, so that the distributed network device updates the allowed path corresponding to the target home tenant identifier in the tenant allowed path policy table; wherein, the target home tenant identifier is the home tenant identifier corresponding to the target data block, and the allowed path corresponding to the target home tenant identifier in the updated tenant allowed path policy table includes the migration allowed path, and the migration allowed path is the dedicated migration channel corresponding to the migration identifier;

[0048] Based on the metadata of the target data block stored in the metadata server, configure the traffic data packet corresponding to the migration event; wherein, the target flow tag in the traffic data packet corresponding to the migration event includes the tenant identifier and migration identifier of the data block;

[0049] The traffic data packet corresponding to the migration event is sent to the distributed network device, so that the distributed network device forwards the traffic data packet through the dedicated migration channel according to the target flow label.

[0050] On the other hand, the acquisition of the migration event of the target data block includes:

[0051] Receive the migration event of the target data block sent by the metadata server.

[0052] In another aspect, prior to receiving the migration event of the target data block sent by the metadata server, the method further includes:

[0053] After a cluster monitoring node detects that a target distributed storage node has lost connection, it determines a migration strategy for the target data block; wherein, the target distributed storage node is a replica node that stores the target data block, and the migration strategy includes the migration replica node information and the new replica node information of the target data block;

[0054] The migration strategy is sent to the metadata service, so that the metadata server updates the metadata of the target data block and generates a migration event for the target data block according to the migration strategy, and sends the migration event to the distributed storage node; wherein, the distributed storage node is the replica node that stores the target data block corresponding to the migration replica node information.

[0055] The present invention also provides a data management device applied to a distributed storage node, comprising:

[0056] A receiving module is used to receive an access request for a target data block sent by a client device; wherein the access request includes a request tenant identifier;

[0057] The configuration module is used to configure the traffic data packet corresponding to the access request based on the metadata of the target data block stored in the metadata server; wherein, the payload header of the traffic data packet includes a target flow label, and the target flow label includes the tenant identifier of the data block;

[0058] The forwarding module is used to send the traffic data packets to the distributed network device so that the distributed network device can block cross-tenant traffic according to the target flow label.

[0059] The present invention also provides a data management device, comprising:

[0060] Memory, used to store computer programs;

[0061] A processor, used to execute the computer program, implements the steps of the data management method described above for use in distributed network devices or distributed storage nodes.

[0062] In addition, the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the data management method described above for use in distributed network devices or distributed storage nodes.

[0063] This invention provides a data management method applied to a distributed network device, comprising: receiving a traffic data packet of a target data block sent by a distributed storage node; wherein the traffic data packet includes a target flow label, the target flow label includes the tenant identifier of the data block, and the target flow label is a flow label on the payload header of the traffic data packet configured by the distributed storage node according to the metadata of the target data block; determining the forwarding path of the traffic data packet according to the target flow label in the traffic data packet; if the forwarding path is a secondary verification path corresponding to cross-tenant traffic, then accessing the metadata server to obtain the tenant identifier of the target data block from the metadata; wherein cross-tenant traffic is a data packet requesting access to a data block of a non-tenant; and discarding the traffic data packet when the requesting tenant identifier in the traffic data packet is different from the tenant identifier in the metadata.

[0064] As can be seen, this invention enables distributed network devices to parse target flow tags in traffic data packets to detect cross-tenant traffic, thereby triggering secondary verification of cross-tenant traffic and solving the problem of cross-node traffic mixing. Furthermore, setting the target flow tag in the payload header of the traffic data packet avoids additional bandwidth overhead. In addition, this invention also provides a data management device for distributed network devices, a data management method, apparatus, device, and computer-readable storage medium for distributed storage nodes, which also have the aforementioned beneficial effects. Attached Figure Description

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

[0066] Figure 1 A flowchart illustrating a data management method provided in an embodiment of the present invention;

[0067] Figure 2 This is a schematic diagram of a target flow label configuration process provided in an embodiment of the present invention;

[0068] Figure 3 This is a flowchart illustrating a data block migration method provided in an embodiment of the present invention;

[0069] Figure 4 This is a flowchart illustrating a data block verification method provided in an embodiment of the present invention;

[0070] Figure 5 A flowchart illustrating another data management method provided in an embodiment of the present invention;

[0071] Figure 6 This is a structural block diagram of a data management device provided in an embodiment of the present invention;

[0072] Figure 7 This is a structural block diagram of another data management device provided in an embodiment of the present invention;

[0073] Figure 8 This is a schematic diagram of the structure of a data management device provided in an embodiment of the present invention. Detailed Implementation

[0074] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of 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, 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.

[0075] Please refer to Figure 1 , Figure 1 A flowchart illustrating a data management method provided in an embodiment of the present invention. This method is applied to a distributed network device and may include:

[0076] Step 101: Receive the traffic data packet of the target data block sent by the distributed storage node; wherein, the traffic data packet includes a target flow label, the target flow label includes the tenant identifier of the data block, and the target flow label is the flow label on the payload header of the traffic data packet configured by the distributed storage node according to the metadata of the target data block.

[0077] It is understood that the distributed network device in this embodiment can be a network device responsible for data transmission and management in a distributed storage system, such as a switch (e.g., Figure 4The edge switches in the network, such as ToR (Top of Rack) switches, can be used to access (e.g., read or write) the target data block. This can be storage protocol packets, such as iSCSI (Internet Small Computer System Interface) PDU (Protocol Data Unit) requests or RGW (Rados Gateway) HTTP (Hypertext Transfer Protocol) requests. In this embodiment, the payload header of the traffic packets can contain flow tags (i.e., target flow tags) configured on the distributed storage nodes. In other words, the distributed network devices can be deployed at the access layer of the distributed storage cluster, responsible for parsing the flow tags in the traffic packets to forward them based on the parsing results. When suspicious traffic (e.g., cross-tenant access) is detected, secondary verification is performed to prevent cross-tenant data leakage or unauthorized access.

[0078] Correspondingly, the distributed storage node in this embodiment can be a storage device in a distributed storage system, such as a device running an OSD (Object Storage Daemon). In this embodiment, the Metadata Server (MDS) can store metadata for each data block in the distributed storage system, such as the tenant identifier (e.g., code ID), data block identifier, data block type, access permissions, current distributed storage node, replica distribution node, and historical anomaly records. This allows the distributed storage node to configure the target flow label for traffic data packets based on the metadata of the target data block stored in the metadata server. For example, the metadata server can record the metadata of each data block in real time and synchronize it to the metadata interface module of the policy management platform via a message queue (e.g., the distributed messaging system Kafka). When encapsulating storage protocol data packets (i.e., traffic data packets), the distributed storage node embeds the target flow label into the payload header of the data packet, not the IP (Internet Protocol) or TCP (Transmission Control Protocol) header, avoiding additional bandwidth overhead. For example, the reserved field in the Command Descriptor Block (CDB) of the SCSI (Small Computer System Interface, a communication protocol applied to storage devices) command of iSCSI is used to store the flow label.

[0079] Accordingly, the specific content of the target flow label in this embodiment can be set by the designer according to the practical scenario and user needs. For example, the target flow label may include the tenant identifier of the data block (i.e., the target data block), such as the tenant identifier in the metadata of the target data block stored in the metadata server. The target flow label may also include the operation type of the data block, such as read, write, delete, or copy synchronization, to facilitate further traffic segmentation and corresponding forwarding paths; for example, the distributed storage system can configure the operation type in the target flow label of the target data block's traffic data packet according to the received access request (such as a read request or a write request) of the target data block. The target flow label may also include the data block type, such as the data block type in the metadata of the target data block stored in the metadata server, to distinguish whether the target data block is object data, block data, or file data. The target flow label may also include extended reserved fields to facilitate subsequent expansion.

[0080] For example, the target flow label may include the tenant identifier of the data block, the operation type, the data block type, and an extended reserved field; the operation type can be any preset operation type identifier, which may include a read identifier, a write identifier, a delete identifier, and a replica synchronization identifier; the data block type can be any preset type, which may include an object data identifier, a block data identifier, and a file data identifier; the extended reserved field is empty or has at least one preset extended identifier, which may include at least one of a migration identifier, a timestamp identifier, and a priority identifier. For example, the target flow label may be 16 bytes long, including: a 4-byte tenant identifier, used to uniquely identify the tenant; a 2-byte data block type, used to distinguish between object data, block data, and file data; a 2-byte operation type, used to distinguish between read (0x01), write (0x02), delete (0x03), and replica synchronization (0x04); and an 8-byte extended reserved field for subsequent expansion.

[0081] Correspondingly, the method provided in this embodiment may further include the process of configuring a distributed storage node and sending traffic data packets of a target data block to a distributed network device, such as the distributed storage node receiving an access request for the target data block sent by a client device; wherein, the access request includes a request tenant identifier (e.g., Figure 2The process involves configuring the traffic data packet corresponding to the access request based on the tenant ID in the write request, and the metadata of the target data block stored in the metadata server (such as metadata corresponding to the data block identifier in the access request). The traffic data packet's payload header includes a target flow label, which includes the tenant identifier of the data block. The traffic data packet is then sent to a distributed network device, such as via OpenFlow (a network communication protocol) rules, so that the distributed network device can block cross-tenant traffic based on the target flow label. Figure 2 As shown, the storage node (i.e., the distributed storage node) can obtain the metadata of the corresponding data block from the metadata server according to the write request sent by the client device. In the process of configuring the traffic data packet corresponding to the access request, a 16-byte stream label (i.e., the target stream label) is injected into the storage protocol extension header (i.e., the payload header) by customizing the data packet header.

[0082] Step 102: Determine the forwarding path of the traffic data packet based on the target flow label in the traffic data packet.

[0083] In this embodiment, the distributed network device is responsible for parsing the target flow tag in the traffic data packet, determining the forwarding path of the traffic data packet, and forwarding the traffic data packet. For example, it can use a hardware-accelerated regular expression engine (such as the P4 programmable pipeline) to extract the target flow tag in the traffic data packet, such as matching a fixed position of 16 bytes.

[0084] Correspondingly, the specific method for determining the forwarding path of traffic data packets based on the target flow label in the traffic data packets in this step can be set by the designer according to the usage scenario and user requirements. For example, the distributed network device can determine the forwarding path of traffic data packets based on the target flow label in the traffic data packets and the tenant allowed path policy table. The tenant allowed path policy table includes the allowed paths corresponding to each tenant identifier, and also includes the allowed paths corresponding to the home tenant identifier of the target data block generated by the distributed storage node based on the target metadata of the target data block, the network context, and the tenant behavior baseline. The distributed network device can also directly detect whether the home tenant identifier in the target flow label is the same as the requesting tenant identifier in the traffic data packet; if they are the same, the traffic data packet is forwarded according to the forwarding method in related technologies; if they are different, the forwarding path is determined to be a secondary verification path. This embodiment does not impose any restrictions on this.

[0085] Similarly, this embodiment does not limit the specific process of determining the forwarding path of a traffic data packet based on the target flow label and the tenant allowed path policy table in the traffic data packet. If the tenant allowed path policy table includes the path (i.e., allowed path) corresponding to each tenant identifier for forwarding traffic data packets, the distributed network device can determine the forwarding path as a secondary verification path when the home tenant identifier in the target flow label is different from the requesting tenant identifier in the traffic data packet; when the home tenant identifier in the target flow label is the same as the requesting tenant identifier in the traffic data packet, the forwarding path is determined as a target allowed path based on the target flow label and the tenant allowed path policy table in the traffic data packet; wherein, the target allowed path is any allowed path in the tenant allowed path policy table. The tenant allowed path policy table also includes the path corresponding to each tenant identifier for triggering secondary verification (i.e., the secondary verification path). When the distributed network device directly determines the forwarding path as the target path based on the target flow label in the traffic data packet and the tenant allowed path policy table, the target path can be any allowed path (i.e., the target allowed path) or the secondary verification path in the tenant allowed path policy table. In other words, when the distributed storage node detects that the owner tenant identifier in the configured target flow label is different from the request tenant identifier in the traffic data packet, or other scenarios that require triggering secondary verification for cross-tenant traffic, it can adjust the forwarding path corresponding to the owner tenant identifier in the tenant allowed path policy table so that the distributed network device can directly determine the forwarding path corresponding to the traffic data packet as the secondary verification path.

[0086] In other embodiments, the distributed network device may further determine the forwarding path as a secondary verification path when the home tenant identifier in the target flow label is different from the requesting tenant identifier in the traffic data packet; and when the home tenant identifier in the target flow label is the same as the requesting tenant identifier in the traffic data packet, determine the forwarding path as the target path according to the target flow label in the traffic data packet and the tenant allowed path policy table; wherein, the target path is any allowed path or secondary verification path in the tenant allowed path policy table.

[0087] Accordingly, in this embodiment, after determining the forwarding path of the traffic data packet based on the target flow label in the traffic data packet, it may further include: if the forwarding path is a target allowed path, then forwarding the traffic data packet according to the target allowed path to complete the forwarding of legitimate traffic.

[0088] For example, the target flow label can also include the operation type of the data block, and the tenant allowed path policy table includes the allowed paths corresponding to each tenant operation group. Each tenant operation group includes a tenant identifier and an operation type. Distributed network devices can match the corresponding forwarding path from the tenant allowed path policy table based on the tenant operation group in the target flow label of the traffic packet. That is, after querying the locally cached tenant allowed path policy table, distributed network devices (such as switches) can select a forwarding path based on the tenant ID (i.e., the owner tenant identifier) ​​and operation type in the flow label. For example: write operation traffic of tenant A → directed to a low-latency dedicated queue (e.g., ... Figure 4 (High-priority queue in the queue); read operation traffic from tenant B → directed to the normal queue; cross-tenant traffic (such as tenant C attempting to access a data block from tenant A) → triggers the "secondary verification" process. Figure 4 As shown, after the edge switch determines that the traffic packet is legitimate traffic (i.e., not cross-tenant traffic) by parsing the target flow label in the traffic packet, it can use the tenant allowed path policy table to execute the Quality of Service (QoS) policy and select the appropriate forwarding path for the traffic packet, such as forwarding it through the corresponding smart NIC queue.

[0089] Correspondingly, after receiving an access request for a target data block from a client device, the distributed storage node can generate the allowed path corresponding to the home tenant identifier of the target data block based on the target metadata, network context, and tenant behavior baseline. This allowed path is then sent to the distributed network device, enabling the distributed network device to configure a tenant allowed path policy table based on the allowed path. For example, the distributed storage node can use its policy engine to generate allowed paths corresponding to each home tenant identifier based on the target metadata, network context, and tenant behavior baseline, thus completing the isolation policy. The SDN (Software Defined Network) controller in the distributed network device then configures and generates the corresponding tenant allowed path policy table based on the allowed path generated by its policy engine sent by the distributed storage node.

[0090] Step 103: If the forwarding path is the secondary verification path corresponding to the cross-tenant traffic, then access the metadata server to obtain the owner tenant identifier in the metadata of the target data block; where cross-tenant traffic is a data packet requesting access to a data block that is not belonging to this tenant.

[0091] Step 104: If the requesting tenant identifier in the traffic packet is different from the home tenant identifier in the metadata, discard the traffic packet.

[0092] Understandably, distributed network devices can use a metadata server to perform secondary verification on traffic that matches the secondary verification path. For example, the DPU (Data Processing Unit) in a distributed network device can receive suspicious traffic redirected by the switch (such as...). Figure 4 (High-risk traffic); call the MDS API (Application Programming Interface) to verify the ownership of traffic packets for secondary verification, thereby blocking illegal traffic (i.e., cross-tenant traffic), and can also feed the results back to the distributed storage node to update the policy engine in the distributed storage node.

[0093] Furthermore, to facilitate the distributed network devices' query of the target allowed paths corresponding to each traffic data packet, in this embodiment, the distributed network devices can cache the mapping relationship between high-frequency flow labels and their corresponding allowed paths. The high-frequency flow label is the flow label corresponding to the tenant whose access frequency exceeds a preset threshold within a given time period. For example, the switch can cache the target flow label and allowed path mapping for high-frequency tenants (e.g., with a capacity of 100,000 entries) to reduce real-time parsing overhead. Moreover, for duplicate tenant-operation type combinations, the MDS can periodically compress the labels to reduce space usage, such as merging "Tenant A - Read - Object Data" into a short label. For example, the MDS can compress the target tenant-operation type combination at a preset compression time interval to obtain the corresponding short label. The target tenant-operation type combination is a tenant-operation type combination whose quantity exceeds a quantity threshold or whose access frequency exceeds a threshold. Each tenant-operation type combination includes a tenant identifier, an operation type, and a data block type.

[0094] Furthermore, the allowed paths in the tenant allowed path policy table can also include dedicated migration channels. For example, determining the forwarding path of a traffic data packet based on the target flow label in the traffic data packet can include: determining the forwarding path as a dedicated migration channel based on the migration identifier in the target flow label; wherein, the dedicated migration channel is a preset data forwarding channel outside the service traffic queue; correspondingly, after determining the forwarding path of the traffic data packet based on the target flow label in the traffic data packet, the traffic data packet can also be forwarded through the dedicated migration channel when the forwarding path is a dedicated migration channel. Figure 3 As shown, when an OSD failure causes a data block replica migration, the MDS updates the node information in the metadata, and the policy engine triggers the SDN controller to adjust the forwarding path of the affected traffic (such as switching the traffic originally pointing to the failed OSD to the new replica OSD) to ensure the continuity of the isolation policy.

[0095] In this embodiment, the present invention enables distributed network devices to parse the target flow label in the traffic data packet to detect cross-tenant traffic by setting the target flow label, thereby triggering secondary verification of cross-tenant traffic and solving the problem of cross-node traffic mixing; and the target flow label is set in the effective payload header of the traffic data packet, which can avoid additional bandwidth overhead.

[0096] Based on the above-described data management method for distributed network devices, this invention also provides a method for use in distributed network devices. For details, please refer to... Figure 5 , Figure 5 A flowchart illustrating another data management method provided in an embodiment of the present invention. This method is applied to distributed storage nodes and may include:

[0097] Step 201: Receive an access request for the target data block sent by the client device; wherein the access request includes the request tenant identifier.

[0098] It is understood that the access request for the target data block in this step can be a request sent by the client device for accessing (such as reading or writing) the target data block.

[0099] Step 202: Configure the traffic data packet corresponding to the access request based on the metadata of the target data block stored in the metadata server; wherein, the payload header of the traffic data packet includes a target flow label, and the target flow label includes the tenant identifier of the data block.

[0100] Step 203: Send the traffic data packet to the distributed network device so that the distributed network device blocks cross-tenant traffic based on the target flow label.

[0101] Furthermore, in this embodiment, after receiving the access request for the target data block sent by the client device, the distributed storage node can also generate the allowed path corresponding to the home tenant identifier of the target data block based on the target metadata, network context, and tenant behavior baseline of the target data block; and send the allowed path to the distributed network device so that the distributed network device can configure the tenant allowed path policy table according to the allowed path. For example, the distributed storage node can use the policy engine to generate the allowed path corresponding to each home tenant identifier based on the target metadata, network context, and tenant behavior baseline to complete the isolation policy.

[0102] Correspondingly, in other embodiments, the distributed storage node may also generate the allowed path and secondary verification path corresponding to the owner tenant identifier of the target data block based on the target metadata of the target data block, the network context, and the tenant behavior baseline.

[0103] In this embodiment, the specific content of the target metadata, network context and tenant behavior baseline is not limited. For example, the target metadata may be part of the metadata of the target data block stored in the metadata server. For example, the target metadata may include the tenant identifier of the data block. It may also include historical anomaly records, such as the tenant identifier, operation type and / or traffic source media access control address (traffic source MAC) of the previously failed access request. According to the historical anomaly records, the corresponding forwarding path is configured as a secondary verification path or discarded to avoid invalid forwarding.

[0104] Correspondingly, the network context may include the authorized device detection result of the traffic source media access control address, so that when the MAC of the traffic source of the access request is not an authorized device, the forwarding path corresponding to the access request is configured as a secondary verification path or dropped; the network context may also include the process surge detection result, so that when the process surge detection result corresponding to the access request is a traffic surge, the forwarding path corresponding to the access request is adjusted to a permitted path with greater bandwidth.

[0105] Accordingly, the tenant behavior baseline may include historical access periods and / or common operation types. If the tenant behavior baseline includes historical access periods and common operation types, the distributed storage node may adjust the forwarding path corresponding to the common operation type to a more bandwidth-capacity allowed path during the high-traffic period in the historical access period.

[0106] Furthermore, in this embodiment, the distributed storage node can also determine the high-traffic time period corresponding to the current tenant identifier based on the historical traffic information obtained. Based on the high-traffic time period, the allowed path corresponding to the current tenant identifier is adjusted. Specifically, the bandwidth of the allowed path corresponding to the current tenant identifier is greater during the high-traffic time period than when it is outside the high-traffic time period. In other words, the distributed storage node can utilize a policy engine to analyze historical traffic information through machine learning models and optimize long-term strategies, such as increasing the bandwidth quota for hot data tenants.

[0107] For example, the policy engine can analyze network performance data and flow label data to identify a clear daily traffic pattern for tenant A: traffic peaks occur daily between 10:00-12:00 AM and 8:00-10:00 PM, during which time bandwidth utilization approaches 95%, network latency increases significantly, and application performance is affected. The machine learning model derives a predictive insight: "Based on historical patterns, it is predicted that tenant A's bandwidth demand will peak again at 10:00 AM on the next workday. The current fixed bandwidth allocation policy will become its performance bottleneck." Based on this prediction, the policy engine automatically performs the following actions: At 9:55 AM, the policy engine notifies the SDN controller in the distributed network devices in advance: "During the 10:00-12:00 period, twice the guaranteed bandwidth will be dynamically allocated to tenant A's traffic path." Correspondingly, the SDN controller adjusts the tenant allowed path policy table to ensure that tenant A's traffic receives higher priority and more resources. At 12:05 PM, the system detects that tenant A's traffic has decreased, and the policy engine triggers an instruction to restore the bandwidth quota to the default level, releasing resources to other tenants.

[0108] Furthermore, the method provided in this embodiment may also include a replica migration process, such as the distributed storage node obtaining the migration event of the target data block; configuring and sending the migration allowed path corresponding to the target home tenant identifier to the distributed network device according to the migration event, so that the distributed network device updates the allowed path corresponding to the target home tenant identifier in the tenant allowed path policy table; wherein, the target home tenant identifier is the home tenant identifier corresponding to the target data block, and the allowed path corresponding to the target home tenant identifier in the updated tenant allowed path policy table includes the migration allowed path, which is the dedicated migration channel corresponding to the migration identifier; configuring the traffic data packet corresponding to the migration event according to the metadata of the target data block stored in the metadata server; wherein, the target flow label in the traffic data packet corresponding to the migration event includes the home tenant identifier and the migration identifier of the data block; sending the traffic data packet corresponding to the migration event to the distributed network device, so that the distributed network device forwards the traffic data packet through the dedicated migration channel according to the target flow label.

[0109] Correspondingly, distributed storage nodes can receive migration events for target data blocks sent by the metadata server, as well as migration events for target data blocks sent by cluster monitoring nodes. For example, when a distributed storage node acts as a cluster monitoring node, it can determine the migration strategy for the target data block after detecting that the target distributed storage node has lost connection. Here, the target distributed storage node is a replica node storing the target data block, and the migration strategy includes the migration replica node information and the new replica node information for the target data block. The migration strategy is then sent to the metadata service, enabling the metadata server to update the metadata of the target data block according to the migration strategy and generate a migration event for the target data block. This migration event is then sent to the distributed storage node, where the distributed storage node is the replica node storing the target data block corresponding to the migration replica node information.

[0110] For example, after the cluster monitoring node detects that OSD1 has lost connection through the heartbeat mechanism, it can make a decision based on the CRUSH (Controlled Replication Under Scalable Hashing) algorithm and the current cluster state: promote OSD2 to become the new primary replica of data block P, and restore a complete replica on OSD3 to maintain the required number of replicas; this migration decision is sent to the relevant OSDs (OSD2 and OSD3) and the metadata server (MDS). After receiving the monitor's decision, the MDS updates the entry for data block P in its metadata table; and sends a migration event message to the policy engine in the distributed storage node through a message queue or direct API call, so that all traffic used to restore data block P can have a migration identifier set in its target flow label, and the target address is OSD2.

[0111] Correspondingly, OSD2 (i.e., distributed storage node) can send traffic data packets of data block P to OSD2 based on the received migration event; when encapsulating the data packet, OSD2's network driver injects the target flow label according to the rules issued by the policy engine. The distributed network device receives the traffic data packet, parses the target flow label, matches it with the temporary flow table entry in the tenant allowed path policy table issued by the SDN controller, and then guides it to the dedicated migration channel for forwarding.

[0112] In this embodiment, the present invention configures the traffic data packet corresponding to the access request according to the metadata of the target data block stored in the metadata server, so that the distributed network device can parse the target flow label to detect cross-tenant traffic, thereby triggering secondary verification of cross-tenant traffic and solving the problem of cross-node traffic mixing; and the target flow label is set in the effective payload header of the traffic data packet, which can avoid additional bandwidth overhead.

[0113] Corresponding to the above method embodiments for distributed network devices, this invention also provides a data management device for distributed network devices. The data management device for distributed network devices described below and the data management method for distributed network devices described above can be referred to in correspondence.

[0114] Please refer to Figure 6 , Figure 6 This is a structural block diagram of a data management device provided in an embodiment of the present invention. The device is applied to a distributed network device and may include:

[0115] The data receiving module 10 is used to receive traffic data packets of target data blocks sent by the distributed storage node; wherein, the traffic data packet includes a target flow label, the target flow label includes the tenant identifier of the data block, and the target flow label is the flow label on the payload header of the traffic data packet configured by the distributed storage node according to the metadata of the target data block;

[0116] The path determination module 20 is used to determine the forwarding path of the traffic data packet based on the target flow label in the traffic data packet;

[0117] The secondary verification module 30 is used to access the metadata server and obtain the owner tenant identifier in the metadata of the target data block if the forwarding path is the secondary verification path corresponding to the cross-tenant traffic; wherein, the cross-tenant traffic is a data packet that requests access to a data block that is not of the current tenant.

[0118] The traffic blocking module 40 is used to discard traffic packets when the requesting tenant identifier in the traffic packet is different from the home tenant identifier in the metadata.

[0119] In some embodiments, the path determination module 20 may be specifically used to determine the forwarding path of the traffic data packet based on the target flow label in the traffic data packet and the tenant allowed path policy table; wherein, the tenant allowed path policy table includes the allowed path corresponding to each tenant identifier, and the tenant allowed path policy table includes the allowed path corresponding to the home tenant identifier of the target data block generated by the distributed storage node based on the target metadata of the target data block, the network context and the tenant behavior baseline.

[0120] In some embodiments, the path determination module 20 may include:

[0121] The secondary verification determination submodule is used to determine the forwarding path as the secondary verification path if the owner tenant identifier in the target flow label is different from the request tenant identifier in the traffic data packet.

[0122] The allowed path determination submodule is used to determine the forwarding path as the target allowed path based on the target flow label in the traffic data packet and the tenant allowed path policy table if the home tenant identifier in the target flow label is the same as the requesting tenant identifier in the traffic data packet; wherein, the target allowed path is any allowed path in the tenant allowed path policy table.

[0123] The device may also include:

[0124] The traffic forwarding module is used to forward traffic data packets according to the target allowed path if the forwarding path is the target allowed path.

[0125] In some embodiments, the target flow label also includes the operation type of the data block, and the tenant allowed path policy table includes the allowed paths corresponding to each tenant operation group. Each tenant operation group includes a tenant identifier and an operation type.

[0126] In some embodiments, the device may further include:

[0127] The caching module is used to cache the mapping relationship between high-frequency flow tags and their corresponding allowed paths; where high-frequency flow tags are the flow tags corresponding to the tenant whose access frequency exceeds a preset threshold within a certain time.

[0128] In some embodiments, the path determination module 20 may include:

[0129] The extraction submodule is used to extract target flow tags from traffic data packets using a hardware-accelerated regular expression engine.

[0130] In some embodiments, the path determination module 20 may include:

[0131] The migration determination submodule is used to determine the forwarding path as a dedicated migration channel based on the migration identifier in the target flow label; wherein, the dedicated migration channel is a preset data forwarding channel outside the service traffic queue;

[0132] The device may also include:

[0133] The migration forwarding module is used to forward traffic data packets through a dedicated migration channel if the forwarding path is a dedicated migration channel.

[0134] In some embodiments, the target stream label further includes the operation type of the data block and an extended reserved field; the operation type is any preset operation type identifier, which includes a read identifier, a write identifier, a delete identifier, and a replica synchronization identifier; the extended reserved field is empty or at least one preset extended identifier, which includes a migration identifier.

[0135] In some embodiments, the target flow label is 16 bytes long. The target flow label also includes a data block type, a tenant identifier occupying 4 bytes, a data block type occupying 2 bytes, an operation type occupying 2 bytes, an extended reserved field occupying 8 bytes, and the data block type being any preset type.

[0136] In this embodiment, the present invention enables distributed network devices to parse the target flow label in the traffic data packet to detect cross-tenant traffic by setting the target flow label, thereby triggering secondary verification of cross-tenant traffic and solving the problem of cross-node traffic mixing; and the target flow label is set in the effective payload header of the traffic data packet, which can avoid additional bandwidth overhead.

[0137] Corresponding to the above method embodiments applied to distributed storage nodes, this invention also provides a data management device applied to distributed storage nodes. The data management device applied to distributed storage nodes described below can be referred to in correspondence with the data management method applied to distributed storage nodes described above.

[0138] Please refer to Figure 7 , Figure 7 This is a structural block diagram of another data management device provided in an embodiment of the present invention. The device is applied to a distributed storage node and may include:

[0139] The receiving module 50 is used to receive an access request for a target data block sent by a client device; wherein the access request includes a request tenant identifier;

[0140] The configuration module 60 is used to configure the traffic data packet corresponding to the access request based on the metadata of the target data block stored in the metadata server; wherein, the payload header of the traffic data packet includes a target flow label, and the target flow label includes the tenant identifier of the data block.

[0141] Forwarding module 70 is used to send traffic data packets to a distributed network device so that the distributed network device can block cross-tenant traffic based on the target flow label.

[0142] In some embodiments, the device may further include:

[0143] The policy generation module is used to generate the allowed path corresponding to the home tenant identifier of the target data block based on the target metadata, network context and tenant behavior baseline of the target data block.

[0144] The policy sending module is used to send allowed paths to the distributed network device so that the distributed network device can configure the tenant allowed path policy table according to the allowed paths.

[0145] In some embodiments, the target metadata includes the tenant identifier of the data block and historical anomaly records; the network context includes the authorized device detection results of the traffic source media access control address and the process surge detection results; and the tenant behavior baseline includes historical access periods and common operation types.

[0146] In some embodiments, the device may further include:

[0147] The historical analysis module is used to determine the high-traffic time period corresponding to the current tenant identifier based on the historical traffic information obtained.

[0148] The path adjustment module is used to adjust the allowed path corresponding to the current tenant identifier based on the high traffic period. Specifically, the bandwidth of the allowed path corresponding to the current tenant identifier is greater during the high traffic period than the bandwidth of the allowed path corresponding to the current tenant identifier outside the high traffic period.

[0149] In some embodiments, the device may further include:

[0150] The event acquisition module is used to acquire migration events for the target data block;

[0151] The migration configuration module is used to configure and send the migration allowed path corresponding to the target home tenant identifier to the distributed network device according to the migration event, so that the distributed network device updates the allowed path corresponding to the target home tenant identifier in the tenant allowed path policy table; wherein, the target home tenant identifier is the home tenant identifier corresponding to the target data block, and the allowed path corresponding to the target home tenant identifier in the updated tenant allowed path policy table includes the migration allowed path, which is the dedicated migration channel corresponding to the migration identifier.

[0152] The traffic configuration module is used to configure the traffic data packets corresponding to the migration event based on the metadata of the target data block stored in the metadata server; wherein, the target flow label in the traffic data packet corresponding to the migration event includes the tenant identifier and migration identifier of the data block;

[0153] The traffic sending module is used to send the traffic data packets corresponding to the migration event to the distributed network device, so that the distributed network device can forward the traffic data packets through a dedicated migration channel according to the target flow label.

[0154] In some embodiments, the event acquisition module may be specifically used to receive migration events of target data blocks sent by the metadata server.

[0155] In some embodiments, the device may further include:

[0156] The strategy determination module is used as a cluster monitoring node to determine the migration strategy of the target data block after detecting that the target distributed storage node has lost connection. The target distributed storage node is a replica node that stores the target data block, and the migration strategy includes the migration replica node information and the new replica node information of the target data block.

[0157] The policy sending module is used to send the migration policy to the metadata service, so that the metadata server updates the metadata of the target data block and generates a migration event for the target data block according to the migration policy, and sends the migration event to the distributed storage node; wherein, the distributed storage node is the replica node that stores the target data block corresponding to the migration replica node information.

[0158] In this embodiment, the configuration module 60 configures the traffic data packet corresponding to the access request based on the metadata of the target data block stored in the metadata server, so that the distributed network device can parse the target flow label to detect cross-tenant traffic, thereby triggering secondary verification of cross-tenant traffic and solving the problem of cross-node traffic mixing; and the target flow label is set in the effective payload header of the traffic data packet, which can avoid additional bandwidth overhead.

[0159] Corresponding to the above method embodiments, this invention also provides a data management device. The data management device described below and the data management method described above can be referred to each other.

[0160] Please refer to Figure 8 , Figure 8 This is a schematic diagram of a data management device provided in an embodiment of the present invention. The electronic device may include:

[0161] Memory D1 is used to store computer programs;

[0162] The processor D2 is used to execute a computer program to implement the steps of the data management method for distributed network devices or distributed storage nodes provided in the above method embodiments.

[0163] The data management device provided in this embodiment can be a distributed network device, such as a switch; or it can be a distributed storage node, such as a host device or a server.

[0164] Corresponding to the above method embodiments, this invention also provides a computer program product. The computer program product described below can be referred to in conjunction with the data management method described above.

[0165] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the data management method for distributed network devices or distributed storage nodes provided in the above-described method embodiments.

[0166] Corresponding to the above method embodiments, this invention also provides a computer-readable storage medium. The computer-readable storage medium described below can be referred to in conjunction with the data management method described above.

[0167] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the data management method for distributed network devices or distributed storage nodes provided in the above-described method embodiments.

[0168] The computer-readable storage medium can specifically be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

[0169] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatuses, devices, computer program products, and computer-readable storage media disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant details can be found in the method section.

[0170] The foregoing has provided a detailed description of the fault handling method, apparatus, and equipment for a metadata retrieval system provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of the present invention. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A data management method characterized by, The application is applied to a distributed network device deployed in an access layer of a distributed storage cluster, comprising: Receiving a traffic data packet of a target data block sent by a distributed storage node; wherein, a payload header of the traffic data packet carries a target flow label, the target flow label comprising a home tenant identifier of the data block, an operation type, a data block type and an extended reserved field, the target flow label being a flow label on a payload header of the traffic data packet configured by the distributed storage node according to metadata of the target data block; Determining a forwarding path of the traffic data packet according to the target flow label in the traffic data packet; If the forwarding path is a secondary check path corresponding to cross-tenant traffic, accessing a metadata server to obtain the home tenant identifier in the metadata of the target data block; wherein, the cross-tenant traffic is a data packet requesting to access a data block of a non-home tenant; Discarding the traffic data packet when the request tenant identifier in the traffic data packet is different from the home tenant identifier in the metadata; Wherein, the determining of the forwarding path of the traffic data packet according to the target flow label in the traffic data packet comprises: If the home tenant identifier in the target flow label is different from the request tenant identifier in the traffic data packet, determining that the forwarding path is the secondary check path; If the home tenant identifier in the target flow label is the same as the request tenant identifier in the traffic data packet, determining the forwarding path to be a target allowed path according to the target flow label in the traffic data packet and a tenant allowed path strategy table; wherein, the target allowed path is any allowed path in the tenant allowed path strategy table; the tenant allowed path strategy table comprises allowed paths corresponding to respective tenant identifiers, the allowed paths corresponding to the home tenant identifier of the target data block being generated by the distributed storage node according to target metadata of the target data block, a network context and a tenant behavior baseline, the tenant allowed path strategy table comprising allowed paths corresponding to respective tenant operation groups, each of the tenant operation groups comprising a tenant identifier and an operation type; After the determining of the forwarding path of the traffic data packet according to the target flow label in the traffic data packet, the method further comprises: if the forwarding path is the target allowed path, forwarding the traffic data packet according to the target allowed path; Wherein, the determining of the forwarding path of the traffic data packet according to the target flow label in the traffic data packet comprises: Determining the forwarding path to be a dedicated migration channel according to a migration identifier in the target flow label; wherein, the dedicated migration channel is a preset data forwarding channel outside a service traffic queue; After the determining of the forwarding path of the traffic data packet according to the target flow label in the traffic data packet, the method further comprises: If the forwarding path is the dedicated migration channel, forwarding the traffic data packet through the dedicated migration channel.

2. The data management method according to claim 1, characterized by, Further comprising: The mapping relationship between a high-frequency flow label and a corresponding allowed path, wherein the high-frequency flow label is a flow label corresponding to a home tenant that is accessed more than a threshold number of times within a preset time.

3. The data management method of claim 1, wherein, The operation type is any preset operation type identifier, the preset operation type identifier includes a read identifier, a write identifier, a delete identifier, and a copy synchronization identifier, the extension reserved field is empty or at least one preset extension identifier, and the preset extension identifier includes the migration identifier. The target flow label has a length of 16 bytes, and the target flow label further includes a data block type, the home tenant identifier occupies 4 bytes, the data block type occupies 2 bytes, the operation type occupies 2 bytes, the extension reserved field occupies 8 bytes, and the data block type is any preset type.

4. The data management method of claim 1, wherein, The distributed network device is deployed at an access layer of a distributed storage cluster, and includes:

5. The data management method according to claim 4, characterized by, A data receiving module configured to receive a traffic data packet of a target data block sent by a distributed storage node, wherein a payload header of the traffic data packet carries a target flow label, and the target flow label includes a home tenant identifier of the data block, an operation type, a data block type, and an extension reserved field, the target flow label being a flow label on the payload header of the traffic data packet configured by the distributed storage node according to metadata of the target data block; 6. A data management apparatus characterized by comprising: A path determining module configured to determine a forwarding path of the traffic data packet according to the target flow label in the traffic data packet; A secondary verification module configured to, if the forwarding path is a secondary verification path corresponding to cross-tenant traffic, access a metadata server to obtain a home tenant identifier in metadata of the target data block, wherein the cross-tenant traffic is a data packet requesting to access a data block of a non-home tenant; A blocking traffic module configured to, if a request tenant identifier in the traffic data packet is different from the home tenant identifier in the metadata, discard the traffic data packet. The path determining module includes: A migration determining submodule configured to determine, according to a migration identifier in the target flow label, that the forwarding path is a special migration channel, wherein the special migration channel is a preset data forwarding channel outside a service traffic queue; The device further includes a migration forwarding module configured to, if the forwarding path is the special migration channel, forward the traffic data packet through the special migration channel; A secondary verification determining submodule configured to, if the home tenant identifier in the target flow label is different from a request tenant identifier in the traffic data packet, determine that the forwarding path is the secondary verification path. ​ ​ The path determination submodule is configured to determine the forwarding path as a target allowed path according to a target flow label in the traffic data packet and a tenant allowed path policy table, if a home tenant identifier in the target flow label is the same as a request tenant identifier in the traffic data packet; the target allowed path is any allowed path in the tenant allowed path policy table; the tenant allowed path policy table comprises allowed paths corresponding to respective tenant identifiers, and the allowed path corresponding to the home tenant identifier of the target data block is generated by the distributed storage node according to target metadata of the target data block, a network context and a tenant behavior baseline; the tenant allowed path policy table comprises allowed paths corresponding to respective tenant operation groups, and each tenant operation group comprises a tenant identifier and an operation type; The device further comprises a traffic forwarding module configured to forward the traffic data packet according to the target allowed path, if the forwarding path is the target allowed path.

7. A data management method characterized by, The application is applied to a distributed storage node, and comprises the following steps: receiving an access request of a target data block sent by a client device; wherein the access request comprises a request tenant identifier; configuring a traffic data packet corresponding to the access request according to metadata of the target data block stored in a metadata server; wherein a target flow label is included in a payload header of the traffic data packet, and the target flow label comprises a home tenant identifier of a data block, an operation type, a data block type and an extended reserved field; sending the traffic data packet to a distributed network device, so that the distributed network device implements the steps of the data management method according to the target flow label, as claimed in any one of claims 1 to 5.

8. The data management method of claim 7, wherein, After the step of receiving the access request of the target data block sent by the client device, the following steps are further included: generating an allowed path corresponding to a home tenant identifier of the target data block according to target metadata of the target data block, a network context and a tenant behavior baseline; sending the allowed path to the distributed network device, so that the distributed network device configures a tenant allowed path policy table according to the allowed path.

9. The data management method of claim 8, wherein, The target metadata comprises a home tenant identifier of a data block and a historical exception record, the network context comprises an authorized device detection result of a traffic source media access control address and a flow surge detection result; and the tenant behavior baseline comprises a historical access time period and a commonly used operation type.

10. The data management method of claim 8, wherein, The following steps are further included: determining a high traffic time period corresponding to the current home tenant identifier according to historical traffic information corresponding to the current home tenant identifier obtained; adjusting the allowed path corresponding to the current home tenant identifier according to the high traffic time period; wherein a bandwidth of the allowed path corresponding to the current home tenant identifier when in the high traffic time period is greater than a bandwidth of the allowed path corresponding to the current home tenant identifier when out of the high traffic time period.

11. The data management method according to any one of claims 7 to 10, characterized by, The following steps are further included: obtaining a migration event of the target data block; According to the migration event, a migration allowed path corresponding to a target home tenant identifier is configured and sent to the distributed network device, so that the distributed network device updates the allowed path corresponding to the target home tenant identifier in the tenant allowed path policy table; wherein the target home tenant identifier is a home tenant identifier corresponding to the target data block, and the allowed path corresponding to the target home tenant identifier in the updated tenant allowed path policy table includes the migration allowed path, and the migration allowed path is a special migration channel corresponding to a migration identifier; According to the metadata of the target data block stored in the metadata server, a traffic data packet corresponding to the migration event is configured; wherein a target flow label in the traffic data packet corresponding to the migration event includes a home tenant identifier and a migration identifier of a data block; The traffic data packet corresponding to the migration event is sent to a distributed network device, so that the distributed network device forwards the traffic data packet through the special migration channel according to the target flow label.

12. The data management method of claim 11, wherein, The migration event of the target data block is obtained, including: Receiving the migration event of the target data block sent by the metadata server.

13. The data management method of claim 12, wherein, Before receiving the migration event of the target data block sent by the metadata server, further including: After detecting that a target distributed storage node is lost as a cluster monitoring node, determining a migration strategy of the target data block; wherein the target distributed storage node is a replica node storing the target data block, and the migration strategy includes migration replica node information and new replica node information of the target data block; Sending the migration strategy to the metadata service, so that the metadata server updates the metadata of the target data block according to the migration strategy and generates the migration event of the target data block, and sends the migration event to the distributed storage node; wherein the distributed storage node is a replica node storing the target data block corresponding to the migration replica node information.

14. A data management apparatus characterized by comprising: Applied to a distributed storage node, including: The receiving module is configured to receive an access request of a target data block sent by a client device; wherein the access request includes a request tenant identifier; The configuration module is configured to configure a traffic data packet corresponding to the access request according to the metadata of the target data block stored in the metadata server; wherein a target flow label is included in a payload header of the traffic data packet, and the target flow label includes a home tenant identifier of a data block, an operation type, a data block type, and an extension reserved field; The forwarding module is configured to send the traffic data packet to a distributed network device, so that the distributed network device implements the steps of the data management method according to the target flow label.

15. A data management device, characterized by comprising: Including: A memory for storing a computer program; A processor for executing the computer program to implement the steps of the data management method according to any one of claims 1 to 5 or any one of claims 7 to 13.

16. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the data management method in any one of claims 1 to 5 or any one of claims 7 to 13.

Images