Data stream distribution method and device, storage medium and electronic equipment

Abstract

The invention discloses a data flow distribution method and device, a storage medium and electronic equipment, and relates to the technical field of distributed storage networks, and the method comprises the steps: analyzing a storage access request data packet under the condition that the storage access request data packet sent by a client through a virtual address is received, and obtaining a data flow; calculating a hash value corresponding to the data stream, calculating a target weight of each physical network card, and dividing a hash interval for each physical network card according to the target weight; and the target physical network card can be allocated to the data stream according to the hash value and the hash interval. The target physical network card is selected through the Hash strategy and the weight strategy, and then the same data flow is bound to the single physical network card, so that the problem that cross-network-card aggregation cannot be avoided while multi-network-card flow balance cannot be realized in the RoCE network in the related technology is solved.

Description

Technical Field

[0001] The present application relates to the field of distributed storage network technology, and in particular to a data stream distribution method and device, a storage medium, and an electronic device. Background Art

[0002] In data center networks, high-performance Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCE) offers low-latency, high-throughput transmission performance, making it the mainstream network architecture for connecting servers and storage devices. RoCE transmits Remote Direct Memory Access (RDMA) packets over Ethernet, enabling direct communication between hosts, bypassing the traditional Transmission Control Protocol / Internet Protocol (TCP / IP) stack and significantly improving network efficiency. However, in actual deployments, RoCE networks face challenges, such as the inability to balance traffic across multiple network adapters (NICs) while avoiding cross-NIC aggregation.

[0003] Therefore, the problem in related technologies of being unable to achieve multi-NIC traffic balancing in a RoCE network while avoiding cross-NIC aggregation has not yet been effectively solved. Summary of the Invention

[0004] The present application provides a data flow distribution method and device, a storage medium, and an electronic device to at least solve the problem in the related art that it is impossible to achieve multi-network card traffic balancing in a RoCE network while avoiding cross-network card aggregation.

[0005] The present application provides a method for allocating data streams, comprising: upon receiving a storage access request data packet sent by a client via a virtual address, parsing the storage access request data packet to obtain a data stream corresponding to the storage access request data packet, and calculating a hash value corresponding to the data stream; determining a target weight of each physical network card based on a preset weight of each physical network card bound to the virtual address and a load value of each physical network card, and dividing a hash interval for each physical network card based on the target weight; and allocating a target physical network card to the data stream based on the hash value and the hash interval.

[0006] The present application also provides a data stream distribution device, including: a parsing module, which is used to parse the storage access request data packet sent by the client through a virtual address to obtain the data stream corresponding to the storage access request data packet and calculate the hash value corresponding to the data stream; a determination module, which is used to determine the target weight of each physical network card bound to the virtual address and the load value of each physical network card, and divide the hash interval for each physical network card according to the target weight; and an allocation module, which is used to allocate a target physical network card to the data stream according to the hash value and the hash interval.

[0007] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned data stream distribution methods when executing the computer program.

[0008] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned data stream distribution methods are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned data stream distribution methods when executed by a processor.

[0010] Through this application, when a storage access request data packet is received from a client through a virtual address, the storage access request data packet is parsed, the data stream is obtained, and the hash value corresponding to the data stream is calculated; the target weight of each physical network card is determined based on the preset weight of each physical network card bound to the virtual address and the load value of each physical network card, and the hash interval is divided for each physical network card according to the target weight; the target physical network card is assigned to the data stream according to the hash value and the hash interval. In other words, this application first calculates the hash value corresponding to the data stream, and secondly, calculates the target weight of each physical network card, and then divides the hash interval for each physical network card according to the target weight; and then the target physical network card can be assigned to the data stream according to the hash value and the hash interval. That is, this application selects the target physical network card through both the hash strategy and the weight strategy, and then binds the same data stream to a single physical network card, thereby solving the problem in the related art that it is impossible to achieve multi-network card traffic balancing in the RoCE network while avoiding cross-network card aggregation. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 This is a hardware structure block diagram of a computer terminal for a data stream distribution method according to an embodiment of the present application;

[0013] Figure 2 is a flow chart of a data stream allocation method according to an embodiment of the present application;

[0014] Figure 3 is a flow chart of a traffic distribution strategy according to an optional embodiment of the present application;

[0015] Figure 4 is a flowchart of a failover according to an optional embodiment of the present application;

[0016] Figure 5 It is a structural block diagram of a data stream distribution device according to an embodiment of the present application. DETAILED DESCRIPTION

[0017] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0018] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0019] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0020] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the data stream distribution method depends, the specific application environment architecture or specific hardware architecture is described herein.

[0021] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a hardware structure block diagram of a computer terminal of a data stream distribution method according to an embodiment of the present application. Figure 1 As shown, the computer terminal may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor or a processing device such as a programmable logic device FPGA) and a memory 104 for storing data. The computer terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal may also include Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0022] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for determining the interactive state in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0023] The transmission device 106 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a computer terminal's communications provider. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0024] The embodiments of the present application provide a method for allocating data streams. The following is an explanation of the technical terms involved in the embodiments of the present application:

[0025] Priority Flow Control (PFC): A sophisticated flow control mechanism that can meet the zero-packet-loss requirement of Ethernet traffic transmission and provide lossless services over Ethernet.

[0026] Figure 2 This is a flow chart of a data flow distribution method according to an embodiment of the present application, which can be applied to Figure 1 In a computer terminal, such as Figure 2 As shown, the process includes the following steps:

[0027] Step S202: upon receiving a storage access request data packet sent by the client via a virtual address, parsing the storage access request data packet to obtain a data stream corresponding to the storage access request data packet, and calculating a hash value corresponding to the data stream;

[0028] The above data flow may be one data flow or multiple data flows, and each data flow is only allowed to match one physical network card to avoid cross-network card aggregation.

[0029] Step S204: determining a target weight of each physical network card according to a preset weight of each physical network card bound to the virtual address and a load value of each physical network card, and dividing a hash interval for each physical network card according to the target weight;

[0030] The hash intervals for each physical network card may be divided into, for example: there are physical network card 1, physical network card 2 and physical network card 3, the hash interval for physical network card 1 is 0-39; the hash interval for physical network card 2 is 40-69; the hash interval for physical network card 3 is 70-99.

[0031] Step S206: Allocate a target physical network card for the data flow according to the hash value and the hash interval.

[0032] According to the data flow distribution method of the present application, when a storage access request data packet sent by a client through a virtual address is received, the storage access request data packet is parsed to obtain the data flow and calculate the hash value corresponding to the data flow; the target weight of each physical network card is determined according to the preset weight of each physical network card bound to the virtual address and the load value of each physical network card, and the hash interval is divided for each physical network card according to the target weight; the target physical network card is allocated to the data flow according to the hash value and the hash interval. That is, the present application first calculates the hash value corresponding to the data flow, and secondly, calculates the target weight of each physical network card, and then divides the hash interval for each physical network card according to the target weight; and then the target physical network card can be allocated to the data flow according to the hash value and the hash interval. That is, the present application selects the target physical network card through the two aspects of hash strategy and weight strategy, and then binds the same data flow to a single physical network card, thereby solving the problem in the related art that it is impossible to achieve multi-network card traffic balancing in the RoCE network while avoiding cross-network card aggregation.

[0033] Optionally, the calculation of the hash value corresponding to the data flow in the above step S202 includes: obtaining a five-tuple corresponding to the data flow, wherein the five-tuple includes: the source address, source port, destination address, destination port and transmission protocol corresponding to the data flow; and calculating the hash value corresponding to the data flow based on the five-tuple.

[0034] It's understandable that in network load balancing and multipath selection, a hash algorithm can be used to calculate the hash value of a data flow to ensure that all packets in the same data flow are transmitted through the same network path, thereby avoiding the complexity and performance loss caused by out-of-order packet arrival. The hash value is then used to determine which physical network card or network path the data flow should be transmitted through.

[0035] The five-tuple of a data stream may include: source IP address (i.e. source address), source port number (i.e. source port), destination IP address (i.e. destination address, also known as virtual address), destination port number (i.e. destination port) and transport layer protocol type (i.e. transport protocol).

[0036] Assume that client A is initiating an NFS file read request to the virtual IP: 192.168.1.100 on server B. The data flow quintuple of the request is: source IP address (S_IP): 10.0.0.1, source port number (S_Port): 54321, destination IP address (D_IP): 192.168.1.100 (i.e. virtual address), destination port number (D_Port): 2049 (NFS protocol default port), transport layer protocol type (Proto): TCP.

[0037] Wherein, calculating the hash value corresponding to the data stream according to the quintuple includes: calculating the hash value corresponding to the data stream through a target formula, wherein the target formula is: Hash=CRC32(S_IP, S_Port, D_IP, D_Port, Proto)%100, Hash is the hash value, S_IP is the source address, S_Port is the source port, D_IP is the destination address, D_Port is the destination port, and Proto is the transmission protocol.

[0038] It is understood that after obtaining the quintuple, a hash value can be calculated using CRC32 (cyclic redundancy check 32 bits) or other similar hash algorithms, using the quintuple information as input. Taking CRC32 as an example, the quintuple is converted into a byte sequence, and then the hash value is calculated using the CRC32 function, that is, the hash function is calculated using the target formula.

[0039] Finally, the calculated hash value is modulo-mapped to a specific physical network card. For example, if the hash calculation result is 65 and N=3, then 65%3 equals 2, which means that the data flow should be transmitted through NIC2.

[0040] The above technical solution ensures that all data packets of the same data stream always pass through the same physical network card in subsequent communications. Even if there are multiple paths in the network, data packets will not be disordered or lost. At the same time, the network load can be evenly distributed, improving the efficiency and reliability of network transmission.

[0041] Optionally, the above-mentioned step S206 determines the target weight of each physical network card based on the preset weight of each physical network card bound to the virtual address and the load value of each physical network card, including: determining whether the load value of each physical network card is greater than the preset load value of each physical network card; when it is determined that the load value of the first physical network card among multiple physical network cards is greater than the preset load value of the first physical network card, adjusting the preset weight of the first physical network card according to the load value of the first physical network card to determine the target weight of the first physical network card, wherein the preset weight of the first physical network card is greater than the target weight of the first physical network card.

[0042] It is understandable that the embodiment of the present application can also adjust the weight of each physical network card, specifically:

[0043] Continuously monitor the real-time load value of each physical network interface card (NIC). This can be accomplished by monitoring metrics such as CPU usage, network throughput, and queue depth. For example, assume that the preset load value of a physical network interface card (NIC1) is 80% CPU utilization. When it is detected that the load value (e.g., CPU utilization) of NIC1 reaches or exceeds 80%, the preset weight of NIC1 is automatically reduced to reduce the proportion of subsequent data flows allocated to this NIC. Weight adjustment can be accomplished through a formula or policy. For example, reducing the preset weight from 100 to 70 means that the traffic allocated to NIC1 will be reduced to reduce its load and avoid overload. The adjusted target weight (for NIC1) is intended to ensure that its traffic distribution in the network is more reasonable and avoid performance bottlenecks caused by overload. Adjustment policies may include: load-based dynamic weight allocation algorithms to ensure that the load of all physical network interfaces remains within a safe and acceptable range.

[0044] Optionally, after allocating a target physical network card for the data flow according to the hash value and the hash interval in step S206, the method further includes:

[0045] 1) detecting the link status of each physical network card based on a first period, and monitoring a flow control counter in each physical network card, so as to determine, according to the flow control counter, a duration during which the network link corresponding to each physical network card is in a congested state; and determining that the operating status of any physical network card is a failure state when it is determined that the link status of any physical network card is a link failure state within a first time period, and / or when it is determined that the network link corresponding to any physical network card is in a congested state within a second time period.

[0046] It is understandable that after assigning a target physical network card to a data flow, you can troubleshoot the physical network card. Specifically:

[0047] Link status detection: Periodically (i.e., based on the first cycle, for example, every 10 milliseconds) obtains link status information of each physical network card through an RDMA driver (such as libibverbs) or SNMP protocol, such as whether the link is up or down, and the link speed.

[0048] Flow control counter monitoring: For network cards that support lossless networking, you can monitor flow control counters (such as PFC counters) to measure the level of congestion on the network link. When congestion begins to occur on the network link, such as when packets are lost or latency increases, the PFC mechanism is triggered, and the flow control counter value increases. By comparing the changes in the counters, you can determine the duration of the network link congestion.

[0049] Fault status judgment:

[0050] Link failure judgment: If the link status of any physical network card (such as NIC1) is detected as Down within the first continuous time period (for example, three consecutive detection cycles, a total of 30 milliseconds), it is considered that a link failure has occurred on the network card.

[0051] Network congestion judgment: At the same time, if the flow control counter of any physical network card shows that the network link is in a continuous congested state for more than the second time period (for example, there is a high PFC count for 100 milliseconds continuously), it is considered that the operating status of the physical network card is abnormal, that is, a soft fault has occurred.

[0052] The above strategy based on periodic monitoring and continuous status evaluation can identify network card failures at the first time, whether it is a hardware failure (link down) or a soft failure (persistent congestion), and immediately execute the failover strategy to transfer the traffic of the faulty network card to the healthy network card to ensure service continuity and data integrity.

[0053] 2) when it is detected that the operating state of a second physical network card among the multiple physical network cards is a fault state, determining whether there are other available physical network cards in the first storage node where the multiple physical network cards are deployed; when it is determined that there are other available physical network cards in the first storage node, determining the other available physical network cards as standby physical network cards; when it is determined that there are no other available physical network cards in the first storage node, determining a second storage node that is operating normally among other storage nodes in the same storage cluster as the first storage node, and determining any available physical network card in the second storage node as the standby physical network card; disabling the first flow table corresponding to the second physical network card, and The method maps the hash value corresponding to the data flow to the standby physical network card to activate the second flow table corresponding to the standby physical network card, wherein the first flow table is used to indicate the matching relationship between the second physical network card and the first data flow, and the second flow table is used to indicate the matching relationship between the standby physical network card and the first data flow; releases the binding relationship between the virtual address and the access address corresponding to the second physical network card, and binds the virtual address to the access address corresponding to the standby physical network card to allow the client to access the storage resource corresponding to the virtual address through the access address corresponding to the standby physical network card; updates the kernel routing table, wherein the kernel routing table is used to record the physical network card that has a binding relationship with the virtual address.

[0054] It is understandable that when a fault is detected on the second physical network card, a faulty network card switching mechanism may be executed, specifically:

[0055] When the second physical network interface card (NIC) (e.g., NIC2) is marked as failed by the system due to a link failure or prolonged congestion, the failover mechanism immediately initiates. First, a check is performed to see if there are other available physical network interfaces in the first storage node (i.e., the current server). If there are, such as NIC3 being in normal operation, NIC3 is marked as a standby physical network interface card to receive data streams transferred from the failed NIC.

[0056] Disable the first flow table of the faulty network card (NIC2), which contains the matching relationship between the faulty network card and the first data flow. At the same time, map the hash value corresponding to the first data flow to the second flow table of the backup network card (NIC3), and activate NIC3's hardware flow table to process the data flow originally assigned to NIC2. The binding relationship between the virtual address and the faulty network card (NIC2) is released, and the virtual address is re-bound to the access address of the backup network card (NIC3), allowing the client to continue to access the storage resources pointed to by the VIP through the new MAC address.

[0057] If there are no other available physical network cards in the first storage node, you can search for other normally running storage nodes (such as the second storage node) in the same storage cluster and select an available network card of one of the nodes as a standby physical network card for failover.

[0058] To ensure that the client can access the backup network card that is processing data through the virtual address, the system also needs to update the kernel routing table to record the binding relationship between the virtual address and the new backup network card so that the client's traffic can be correctly directed to the backup network card.

[0059] By quickly selecting and activating a backup physical network card locally or across nodes, seamless service switching can be achieved, ensuring that the client is almost unaware of network card failures and maintaining the continuity of storage services.

[0060] 3) broadcasting the binding relationship between the virtual address and the standby physical network card to the client, so that the client sends all subsequent traffic of the first data flow to the standby physical network card, specifically:

[0061] An address message is constructed according to the binding relationship between the virtual address and the access address of the backup physical network card; the address message is sent to the client based on the second cycle within a third time period, so that the client updates the access address table corresponding to the client through the address message, and sends subsequent traffic of the first data flow to the backup physical network card according to the access address table, wherein the access address table is used to record the access address that has a binding relationship with the virtual address.

[0062] It is understandable that, in addition, it is also necessary to broadcast the binding relationship between the virtual address and the standby physical network card, specifically:

[0063] After the backup physical NIC is determined (for example, switching from the failed NIC2 to the backup NIC3), an address message can be constructed, which contains the latest binding relationship between the virtual address and the access address (MAC address) of the backup physical NIC. For example, if the virtual address is 192.168.1.100 and the MAC address of the backup physical NIC (NIC3) is AA:BB:CC:DD:EE:FF, then the address message will contain this information.

[0064] A free ARP address message is sent to the client based on the second period (for example, every 1 millisecond) to ensure that the client can quickly receive the notification of network card switching.

[0065] After receiving the address message, the client updates its local access address table, also known as the ARP cache table. This table records the correspondence between VIPs and MAC addresses. Once the update is complete, the client will send all subsequent traffic corresponding to the VIP to the new MAC address, which is the MAC address of the backup power card (NIC3).

[0066] By constructing and sending address messages in a timely manner, it is possible to ensure that the client quickly updates its access address table, thereby redirecting traffic to the backup physical network card in a very short time, shortening the fault recovery time.

[0067] In order to better understand the process of the above-mentioned data stream allocation method, the implementation process of the above-mentioned data stream allocation method is described below in combination with optional embodiments, but it is not used to limit the technical solution of the embodiments of this application.

[0068] Most RoCE network card vendors don't support cross-NIC aggregation in their drivers or firmware because their design targets single-link optimization for high throughput and low latency. Furthermore, lossless network configurations (such as Data Center Bridging Extensions (DCBX) and PFC) require meticulous port-by-port tuning. Cross-NIC aggregation significantly increases configuration complexity and makes it difficult to ensure end-to-end consistency.

[0069] RoCE was originally designed to achieve high performance by simplifying the protocol stack and relying on lossless networks. However, the multipathing and potential out-of-order traffic introduced by cross-NIC aggregation conflicts with these core requirements. Therefore, in RoCE networks, it is generally recommended to avoid cross-NIC aggregation and instead use high-bandwidth single ports or network-layer multipathing (which requires careful configuration) to meet scalability requirements.

[0070] The related art has the following problems:

[0071] 1) RoCE relies on lossless networks:

[0072] RoCE relies on lossless transmission (guaranteed by zero packet loss through the PFC mechanism). Cross-NIC aggregation can cause packets to be transmitted over different physical paths, leading to out-of-order transmission and potential packet loss, undermining RoCE's lossless nature. PFC requires congestion management based on fixed physical paths. Dynamic path allocation for cross-NIC aggregation can interfere with PFC's localized control, causing flow control failure.

[0073] 2) Hardware binding features of the RDMA protocol stack:

[0074] RDMA communication entities (such as queue pairs and memory regions) are directly associated with physical network adapters (NICs). Cross-NIC aggregation requires upper-layer protocols to coordinate multi-NIC resources, but the RDMA protocol stack design does not provide such an abstraction. RDMA assumes a single logical path from end to end, bypassing traditional network protocol stacks (such as TCP / IP). The multipath introduced by cross-NIC aggregation requires additional routing and reordering mechanisms, which violates the original low-latency design principle of RDMA.

[0075] 3) Packet out-of-order problem:

[0076] Remote Direct Memory Access over Converged Ethernet version 2 (RoCEv2) is based on the User Datagram Protocol / Internet Protocol (UDP / IP), which does not guarantee packet order. If the same data stream is distributed across multiple network cards for transmission, out-of-order transmission may occur at the receiving end. Traditional TCP / IP protocol stacks can handle out-of-order transmission, but RDMA relies on hardware offload and lacks such error correction capabilities. Even if aggregation technologies maintain stream consistency (such as hash-based load balancing), RoCE network cards may still need to independently process data from each physical port, increasing processing complexity.

[0077] That is, the optional embodiments of the present application can solve the following problems: how to achieve multi-network card traffic balancing in the RoCE network while avoiding cross-network card aggregation; how to achieve seamless switching of business traffic through virtual IP and give priority to the shortest path within the same device; how to optimize the fault detection and switching mechanism in combination with the lossless network characteristics of RoCE.

[0078] The optional embodiment of the present application provides a method and system for load balancing and failover of multiple network interface card virtual Internet Protocol addresses (IP) based on a RoCE network, specifically:

[0079] (1) The technical methods involved in the optional embodiments of this application include:

[0080] Virtual IP and multi-NIC traffic balancing architecture: Configuring virtual IPs (VIPs) on physical NICs allows dynamic traffic allocation (e.g., based on service type, flow hash, or weight) to distribute Network Attached Storage (NAS) service traffic to different physical NICs, circumventing the limitations of RoCE cross-NIC aggregation. A lightweight load balancing model that binds virtual IPs to multiple physical NICs is used, implementing traffic distribution through kernel modules and user-mode drivers, eliminating the network overhead of traditional aggregation protocols.

[0081] Shortest Path Failover Mechanism: Prioritizes switching based on the local NIC status of the device. When a physical NIC fails, the virtual IP is preferentially bound to other available NICs within the same device, ensuring the shortest path (avoiding cross-switch or cross-node switching). Combined with RoCE's lossless network status awareness (such as PFC congestion signals and NIC health status), it dynamically adjusts switching priorities, shortening fault recovery time to milliseconds.

[0082] Lossless network compatibility design: Traffic distribution strategies work in conjunction with RoCE's lossless forwarding mechanism (PFC) to ensure that traffic for the same data flow is transmitted only through a single physical network interface card (NIC), preventing out-of-order transmission and packet loss. Hardware-offloaded flow table management (such as steering technology) enables static binding of virtual IP traffic to physical NICs, reducing CPU overhead.

[0083] Dynamic traffic redirection technology: When a network card fails, traffic is quickly redirected to the backup network card through a pre-configured backup flow table. At the same time, the Address Resolution Protocol / Neighbor Discovery (ARP / ND) table is updated to notify the client of the Media Access Control address (MAC) change of the virtual IP address, achieving seamless switching.

[0084] (2) The hardware configuration involved in the optional embodiment of this application includes:

[0085] The server is configured with multiple network cards that support Remote Direct Memory Access over Converged Ethernet (RoCE), and each network card is connected to the same Top of Rack Switch (TOR switch).

[0086] RoCE is a network technology that allows the use of Ethernet networks.

[0087] Client: Accesses the NAS service through a virtual IP address, such as 192.168.1.100.

[0088] Storage nodes: Deploy multiple RoCE-supported physical network cards (e.g., NIC1, NIC2, and NIC3), each connected to the same Top of Rack (TOR) switch. Each physical NIC is assigned a unique IP address (e.g., 10.1.1.1, 10.1.1.2, and 10.1.1.3) and is bound to the same virtual IP address (192.168.1.100). The NIC hardware supports RoCEv2 and flow table offload (e.g., steering flow table).

[0089] Among them, the network interface controller (Network Interface Controller, referred to as NIC).

[0090] TOR switches: Support lossless network features (i.e., Priority Flow Control, PFC for short) and configure multipath forwarding (such as Equal Cost Multi-Path Routing, ECMP for short).

[0091] Storage system: Provides file storage services through the Network File System (NFS) protocol.

[0092] (3) The software architecture involved in the optional embodiments of this application includes:

[0093] Virtual IP management module:

[0094] Function: Responsible for virtual IP configuration, traffic distribution strategy and failover decision making.

[0095] Implementation: Through Linux (an operating system) kernel modules and user-mode tools such as the Data Plane Development Kit (DPDK).

[0096] Traffic distribution: Distributes traffic to different physical network cards based on quintuple hashing, service priority, or weighted algorithms.

[0097] Stream binding: The same data stream (such as a Transmission Control Protocol / User Datagram Protocol (TCP / UDP) connection) is fixedly bound to a single physical network interface card to avoid RoCE out-of-order issues.

[0098] Lossless network status perception module:

[0099] Function: Monitor the health status of the physical network card (such as link status, PFC congestion signal).

[0100] Implementation: Get the network card status by interacting with the RDMA driver (such as the InfiniBand Verbs Library (libibverbs)) or the Simple Network Management Protocol (SNMP).

[0101] Hardware flow table control module:

[0102] Function: Dynamically configure the hardware flow table of the physical network card to achieve traffic redirection.

[0103] Implementation method: Call the manufacturer's software development kit (SDK, such as NVIDIAMLNX_OFED (a type of network software)) to operate the steering flow table.

[0104] Failover and Address Resolution Protocol (ARP) synchronization module:

[0105] Function: Updates the ARP table and broadcasts Gratuitous ARP when a network card fails, notifying the client of the MAC address change of the virtual IP.

[0106] (4) The data flow logic of the optional embodiment of the present application includes:

[0107] 1) Normal traffic distribution process:

[0108] Figure 3 This is a flow chart of the traffic distribution strategy according to an optional embodiment of the present application, such as Figure 3 As shown:

[0109] Step S301: The client requests a data stream.

[0110] The client initiates a NAS access request (such as NFS / CIFS) through the virtual IP (192.168.1.100).

[0111] Request a data flow and obtain a five-tuple consisting of the source IP address, source port number, destination IP address, destination port number, and protocol number. Bind the same data flow to a single physical network interface card to avoid out-of-order routing issues caused by multipathing in RoCE.

[0112] Step S302: Hash function calculation.

[0113] Hash=CRC32(S_IP, S_Port, D_IP, D_Port, Proto)%100, Hash is the hash value, S_IP is the source IP, S_Port is the source port, D_IP is the destination IP, D_Port is the destination port, and Proto is the protocol.

[0114] Step S303: Hash interval mapping.

[0115] The traffic ratio is dynamically allocated according to the preset weights of the physical network cards (the preset weights can be determined based on the bandwidth ratio, processing power, etc.). For example, if the preset weights are NIC1:NIC2:NIC3=4:3:3, the hash ranges allocated according to the preset weights are: NIC1: 0-39; NIC2: 40-69; NIC3: 70-99.

[0116] Step S304: Distribute traffic to the target network card according to the hash value.

[0117] NIC1: 40%; NIC2: 30%; NIC3: 30%.

[0118] In step S305 , it is determined whether the NIC load is greater than a threshold.

[0119] When the NIC load (i.e., load value) is greater than the threshold (i.e., preset load value), the preset weight of the NIC is reduced to obtain a target weight, and step S303 is executed;

[0120] When the NIC is less than or equal to the threshold, the process ends.

[0121] The traffic distribution strategy is shown in Table 1:

[0122] Table 1

[0123] Traffic characteristics (quintuple) Target physical network card Weight Source IP:Port+Destination IP:Port NIC1 40％ Source IP:Port+Destination IP:Port NIC2 30％ Source IP:Port+Destination IP:Port NIC3 30％

[0124] Data packets can be forwarded to the storage backend through NIC1's hardware flow table; RoCE transmission: Storage response data is returned to the client through NIC1's RoCE protocol (based on UDP / IP), ensuring single-path transmission to avoid disorder.

[0125] 2) Failover process.

[0126] Failure switching mainly includes the following steps: detecting a network card failure → disabling the flow table of the failed network card → activating the flow table of the backup network card → sending a free ARP to update the client MAC address. Specifically, Figure 4 This is a flowchart of a failover according to an optional embodiment of the present application, such as Figure 4 As shown:

[0127] Step S401 , status detection stage (for example, a failure of the network card NIC1 is detected (NIC1 is the first physical network card)).

[0128] Hardware link interruption: The physical network card port status changes to Down (notified through driver events).

[0129] Soft faults: Continuous packet loss on the network card, PFC congestion exceeding the threshold, or RDMA queue timeout (monitored through polling).

[0130] Lossless network status awareness module: Periodically (e.g., every 10ms) obtains network card health status from the RDMA driver (libibverbs) (e.g., ibv_query_port API). It also parses PFC congestion counters (i.e., flow control counters) via SNMP or vendor tools such as mlxlink.

[0131] Fault determination rules:

[0132] If the NIC link status is detected as Down three times in a row, or if PFC congestion lasts for more than 100ms (i.e., the second time period), it is marked as a fault and a fault event is generated: {NIC_ID: NIC1, Fault Type: Hardware Interrupt, Timestamp: T0}.

[0133] Step S402, flow table update phase (selecting a standby network card, disabling the flow table of NIC1, and activating the pre-configured flow table of NIC2 (standby network card)).

[0134] Redirect the traffic of the failed network card to the backup network card within 20ms, ensuring that the RoCE flow is not disordered and there is no packet loss.

[0135] Select a backup network card: Select other network cards in the same server according to the priority strategy (such as NIC2>NIC3, that is, when it is determined that there are other available physical network cards in the first storage node, the other available physical network cards are determined as the backup physical network cards). If there are no available network cards on the local machine, cross-node switching is triggered (the global load balancing module needs to intervene, that is, when it is determined that there are no other available physical network cards in the first storage node, a second storage node that is operating normally is determined from other storage nodes in the same storage cluster as the first storage node, and any available physical network card in the second storage node is determined as the backup physical network card).

[0136] Disable the faulty NIC flow table: Delete the flow table entry of NIC1 through the NVIDIA MLNX_OFFED SDK: mlx_steer_del -d mlx5_1 --flow_id 0x123.

[0137] Activate the backup network card flow table: Directly enable the pre-configured backup flow table (avoiding real-time configuration delays):

[0138] mlx_steer_add-d mlx5_2--flow "src_ip=192.168.1.100action=forward".

[0139] Flow table binding rules: The five-tuple hash value of the same data flow is fixedly mapped to the backup network card to ensure flow continuity.

[0140] Virtual IP binding switch: Switch the MAC address of the virtual IP 192.168.1.100 from NIC1 (AA:BB:CC:11) to NIC2 (AA:BB:CC:22).

[0141] Update the kernel routing table (the binding relationship between the virtual IP and the physical network card): ip addr del 192.168.1.100 dev enp1s0f0 # Uninstall the faulty network card binding; ip addr add 192.168.1.100 devenp1s0f1 # Bind to the backup network card.

[0142] Step S403, ARP broadcast phase (constructing a free ARP message, broadcasting through NIC2, the client updates the ARP table, and the TOR switch updates the MAC port).

[0143] Notify the client and network devices to update the MAC address mapping of the virtual IP within 10ms.

[0144] Generate Gratuitous ARP, including:

[0145] Construct an ARP message (i.e., address message): source IP / MAC: 192.168.1.100 (virtual IP) + NIC2's MAC (AA:BB:CC:22).

[0146] Target IP / MAC: broadcast address (255.255.255.255) + FF:FF:FF:FF:FF:FF:FF.

[0147] The message content states that the MAC address of the virtual IP has changed.

[0148] Broadcast Gratuitous ARP: Send gratuitous ARP packets through the standby network card (NIC2), overwriting the switch MAC table and the client ARP cache. Use a high-speed packet transmission library (such as DPDK rte_eth_tx_burst) to ensure low latency: rte_eth_tx_burst(port_id, queue_id, arp_packets, num_packets).

[0149] Client response: After receiving the gratuitous ARP, the client updates the local ARP table and sends subsequent traffic directly to the MAC address of NIC2.

[0150] The switch updates the MAC-port mapping to ensure that traffic enters and exits from NIC2.

[0151] Fault-tolerance mechanism: retransmission strategy. If the first broadcast does not cover all clients, it triggers periodic retransmission (e.g., every 1ms), up to 3 times.

[0152] Switch collaboration: Some switches (such as Cisco Nexus) support fast convergence protocols (such as FabricPath), further shortening the MAC table (i.e., access address table) update delay.

[0153] In summary, the optional embodiments of the present application have the following advantages: Performance improvement: multiple network cards carry traffic in parallel, and the single-node NAS throughput is increased to the sum of the physical network card bandwidths (such as 4×100Gbps). High availability: Network card failover time ≤50ms, and no perceived service interruption. Compatibility: Supports RoCEv1 / v2 protocols, and there is no need to modify existing network equipment and client configurations. That is, the optional embodiments of the present application circumvent the disadvantage that RoCE network cards do not support aggregation through the combination of virtual IP and multi-network card traffic balancing architecture, and realizes high-performance concurrency and fast fault switching of distributed storage networks under the constraints of RoCE networks. It is suitable for distributed storage scenarios that require high performance and are sensitive to latency.

[0154] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0155] In this embodiment, a data stream distribution device is also provided, which is used to implement the above embodiments and preferred implementations. Details that have been described are not repeated here. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

[0156] Figure 5 is a structural block diagram of a data stream distribution device according to an embodiment of the present application, such as Figure 5 As shown, the device includes:

[0157] a parsing module 52 configured to, upon receiving a storage access request data packet sent by a client via a virtual address, parse the storage access request data packet to obtain a data stream corresponding to the storage access request data packet and calculate a hash value corresponding to the data stream;

[0158] a determination module 54, configured to determine a target weight of each physical network card according to a preset weight of each physical network card bound to the virtual address and a load value of each physical network card, and divide a hash interval for each physical network card according to the target weight;

[0159] The allocation module 56 is configured to allocate a target physical network card to the data flow according to the hash value and the hash interval.

[0160] Through the data flow distribution device of the present application, when receiving the storage access request data packet sent by the client through the virtual address, the storage access request data packet is parsed to obtain the data flow and calculate the hash value corresponding to the data flow; the target weight of each physical network card is determined according to the preset weight of each physical network card bound to the virtual address and the load value of each physical network card, and the hash interval is divided for each physical network card according to the target weight; the target physical network card is allocated to the data flow according to the hash value and the hash interval. That is, the present application first calculates the hash value corresponding to the data flow, and secondly, calculates the target weight of each physical network card, and then divides the hash interval for each physical network card according to the target weight; and then the target physical network card can be allocated to the data flow according to the hash value and the hash interval. That is, the present application selects the target physical network card through the two aspects of hash strategy and weight strategy, and then binds the same data flow to a single physical network card, thereby solving the problem in the related art that it is impossible to achieve multi-network card traffic balancing in the RoCE network while avoiding cross-network card aggregation.

[0161] In an exemplary embodiment, the parsing module 52 is also used to obtain a five-tuple corresponding to the data flow, wherein the five-tuple includes: the source address, source port, destination address, destination port and transmission protocol corresponding to the data flow; and calculate the hash value corresponding to the data flow based on the five-tuple.

[0162] In an exemplary embodiment, the parsing module 52 is further used to calculate the hash value corresponding to the data stream through a target formula, wherein the target formula is: Hash = CRC32(S_IP, S_Port, D_IP, D_Port, Proto) % 100, Hash is the hash value, S_IP is the source address, S_Port is the source port, D_IP is the destination address, D_Port is the destination port, and Proto is the transmission protocol.

[0163] In an exemplary embodiment, the allocation module 56 is further configured to determine whether the load value of each physical network card is greater than a preset load value of each physical network card;

[0164] When it is determined that a load value of a first physical network card among multiple physical network cards is greater than a preset load value of the first physical network card, a preset weight of the first physical network card is adjusted according to the load value of the first physical network card to determine a target weight of the first physical network card, wherein the preset weight of the first physical network card is greater than the target weight of the first physical network card.

[0165] In an exemplary embodiment, the allocation module 56 is further used to determine whether there are other available physical network cards in the first storage node where the multiple physical network cards are deployed when it is detected that the operating status of the second physical network card among the multiple physical network cards is a fault state; when it is determined that there are other available physical network cards in the first storage node, determine the other available physical network cards as standby physical network cards; when it is determined that there are no other available physical network cards in the first storage node, determine a second storage node that is operating normally among other storage nodes in the same storage cluster as the first storage node, and determine any available physical network card in the second storage node as the standby physical network card; disable the first flow table corresponding to the second physical network card, and map the hash value corresponding to the first data flow allocated to the second physical network card to the standby physical network card, so as to Activate the second flow table corresponding to the standby physical network card, wherein the first flow table is used to indicate the matching relationship between the second physical network card and the first data flow, and the second flow table is used to indicate the matching relationship between the standby physical network card and the first data flow; release the binding relationship between the virtual address and the access address corresponding to the second physical network card, and bind the virtual address to the access address corresponding to the standby physical network card to allow the client to access the storage resource corresponding to the virtual address through the access address corresponding to the standby physical network card; update the kernel routing table, wherein the kernel routing table is used to record the physical network card that has a binding relationship with the virtual address; broadcast the binding relationship between the virtual address and the standby physical network card to the client, so that the client sends subsequent traffic of the first data flow to the standby physical network card.

[0166] In an exemplary embodiment, the allocation module 56 is also used to detect the link status of each physical network card based on the first period, and monitor the flow control counter in each physical network card to determine the duration of the network link corresponding to each physical network card in the congested state according to the flow control counter; when it is determined that the link status of any physical network card is a link failure state within the first time period, and / or when it is determined that the network link corresponding to any physical network card is in a congested state within the second time period, it is determined that the operating status of any physical network card is a failure state.

[0167] In an exemplary embodiment, the allocation module 56 is also used to construct an address message based on the binding relationship between the virtual address and the access address of the backup physical network card; and send the address message to the client based on the second cycle within a third time period, so that the client updates the access address table corresponding to the client through the address message, and sends subsequent traffic of the first data flow to the backup physical network card according to the access address table, wherein the access address table is used to record the access address that has a binding relationship with the virtual address.

[0168] For the description of the features in the embodiment corresponding to the data stream distribution device, reference can be made to the relevant description of the embodiment corresponding to the data stream distribution method, which will not be repeated here.

[0169] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned data stream distribution method embodiments.

[0170] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned data stream distribution method embodiments when running.

[0171] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0172] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned data stream distribution method embodiments are implemented.

[0173] An embodiment of the present application further provides another computer program product, comprising a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned data stream distribution method embodiments are implemented.

[0174] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0175] The above is a detailed introduction to a data stream distribution method provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only intended to help understand the method and core concept of the present application. It should be noted that, for those skilled in the art, without departing from the principles of the present application, several improvements and modifications may be made to the present application, and such improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for allocating data streams, characterized in that: include: Upon receiving a storage access request data packet sent by a client through a virtual address, parsing the storage access request data packet to obtain a data stream corresponding to the storage access request data packet, and calculating a hash value corresponding to the data stream; Determining a target weight of each physical network card according to a preset weight of each physical network card bound to the virtual address and a load value of each physical network card, and dividing a hash interval for each physical network card according to the target weight; A target physical network card is allocated to the data flow according to the hash value and the hash interval.

2. The data stream distribution method according to claim 1, characterized in that: Calculating a hash value corresponding to the data stream includes: Obtaining a quintuple corresponding to the data flow, wherein the quintuple includes: a source address, a source port, a destination address, a destination port, and a transmission protocol corresponding to the data flow; A hash value corresponding to the data stream is calculated according to the quintuple.

3. The data stream distribution method according to claim 2, characterized in that: Calculating a hash value corresponding to the data stream according to the quintuple includes: The hash value corresponding to the data stream is calculated by a target formula, wherein the target formula is: Hash=CRC32(S_IP, S_Port, D_IP, D_Port, Proto)%100, Hash is the hash value, S_IP is the source address, S_Port is the source port, D_IP is the destination address, D_Port is the destination port, and Proto is the transmission protocol.

4. The data stream distribution method according to claim 1, characterized in that: Determining a target weight of each physical network card according to a preset weight of each physical network card bound to the virtual address and a load value of each physical network card includes: Determining whether the load value of each physical network card is greater than a preset load value of each physical network card; When it is determined that a load value of a first physical network card among multiple physical network cards is greater than a preset load value of the first physical network card, a preset weight of the first physical network card is adjusted according to the load value of the first physical network card to determine a target weight of the first physical network card, wherein the preset weight of the first physical network card is greater than the target weight of the first physical network card.

5. The data stream distribution method according to claim 1, characterized in that: After allocating a target physical network card for the data flow according to the hash value and the hash interval, the method further includes: When it is detected that the operating state of a second physical network card among the multiple physical network cards is a fault state, determining whether there are other available physical network cards in the first storage node where the multiple physical network cards are deployed; In the case of determining that there are other available physical network cards in the first storage node, determining the other available physical network cards as standby physical network cards; When it is determined that no other available physical network cards exist in the first storage node, determining a second storage node that is operating normally among other storage nodes in the same storage cluster as the first storage node, and determining any available physical network card in the second storage node as the standby physical network card; disabling a first flow table corresponding to the second physical network card, and mapping a hash value corresponding to the first data flow assigned to the second physical network card to the standby physical network card, so as to activate a second flow table corresponding to the standby physical network card, wherein the first flow table is used to indicate a matching relationship between the second physical network card and the first data flow, and the second flow table is used to indicate a matching relationship between the standby physical network card and the first data flow; Unbinding the virtual address from the access address corresponding to the second physical network card, and binding the virtual address to the access address corresponding to the standby physical network card, so as to allow the client to access the storage resource corresponding to the virtual address through the access address corresponding to the standby physical network card; Updating a kernel routing table, wherein the kernel routing table is used to record a physical network card having a binding relationship with the virtual address; The binding relationship between the virtual address and the standby physical network card is broadcasted to the client, so that the client sends all subsequent traffic of the first data flow to the standby physical network card.

6. The data stream distribution method according to claim 5, characterized in that: Before determining whether there are other available physical network cards in the first storage node where the multiple physical network cards are deployed, the method further includes: Detecting the link status of each physical network card based on the first cycle, and monitoring the flow control counter in each physical network card to determine the duration of the network link corresponding to each physical network card being in a congested state according to the flow control counter; When it is determined that the link status of any physical network card is a link failure state within a first time period, and / or when it is determined that the network link corresponding to any physical network card is in a congested state within a second time period, it is determined that the operating status of any physical network card is a failure state.

7. The data stream distribution method according to claim 5, characterized in that: Broadcasting the binding relationship between the virtual address and the standby physical network card to the client includes: Constructing an address message according to a binding relationship between the virtual address and the access address of the standby physical network card; The address message is sent to the client based on the second cycle within a third time period, so that the client updates the access address table corresponding to the client through the address message, and sends subsequent traffic of the first data flow to the backup physical network card according to the access address table, wherein the access address table is used to record the access address that has a binding relationship with the virtual address.

8. A data stream distribution device, characterized in that: include: a parsing module, configured to, upon receiving a storage access request data packet sent by a client via a virtual address, parse the storage access request data packet to obtain a data stream corresponding to the storage access request data packet, and calculate a hash value corresponding to the data stream; a determination module, configured to determine a target weight of each physical network card according to a preset weight of each physical network card bound to the virtual address and a load value of each physical network card, and divide a hash interval for each physical network card according to the target weight; An allocation module is configured to allocate a target physical network card to the data flow according to the hash value and the hash interval.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the data stream distribution method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the data stream distribution method according to any one of claims 1 to 7 are implemented.

Images