Requirement of Fast Fault Detection for IP-based Network

For a long time, the key storage applications and high performance requirements are mainly based on FC networks. With the increase of transmission rates, the medium has evolved from HDDs to solid-state storage and the protocol has evolved from SATA to NVMe. The emergence of new NVMe technologies brings new opportunities. With the development of the NVMe protocol, the application scenario of the NVMe protocol is extended from PCIe to other fabrics, solving the problem of NVMe extension and transmission distance. The block storage protocol uses NoF to replace SCSI, reducing the number of protocol interactions from application hosts to storage systems. The end-to-end NVMe protocol greatly improves performance. Fabrics of NoF include Ethernet, Fibre Channel and InfiniBand. Comparing FC-NVMe to Ethernet- or InfiniBand-based Network alternatives generally takes into consideration the advantages and disadvantages of the networking technologies. Fibre Channel fabrics are noted for their lossless data transmission, predictable and consistent performance, and reliability. Large enterprises tend to favor FC storage for mission-critical workloads. But Fibre Channel requires special equipment and storage networking expertise to operate and can be more costly than IP-based alternatives. Like FC, InfiniBand is a lossless network requiring special hardware. IP-based NVMe storage products tend to be more plentiful than FC-NVMe-based options. Most storage startups focus on IP-based NVMe. But unlink FC, The Ethernet switch does not notify the change of device status. When the device is faulty, relying on the NVMe link heartbeat message mechanism, the host takes tens of seconds to complete service failover.

This section describes the application scenarios and capability requirements of the IP-based NVMe storage that implements fast fault detection similar to FC. The NVMe over RDMA or IP-based network in storage includes three types of roles: an initiator (referred to as a host), a switch, and a target (referred to as a storage device). Initiators and targets are also referred to as endpoint devices.

Hosts and storage devices are connected to the network separately and in order to achieve high reliability, each host and storage device are connected to dual network planes simultaneously. The host can read and write data services when an NVMe connection is established between the host and the storage device. When a storage device link is faulty during running, the host cannot detect the fault status of the indirectly connected device at the transport layer. Based on the IP-based NVMe protocol, the host uses the NVMe heartbeat to detect the status of the storage device. The heartbeat message interval is 5s. Therefore, it takes tens of seconds to determine whether the storage device is faulty and perform service switchover using the multipath software. Failure tolerance time for core applications cannot be reached. In order to obtain the best customer experience and business reliability requirement, we need to enhance fault detection and failover for IP-based NVMe. The storage system has an active-active solution. The proposal, the second active path can be used to transfer faults to drive the switchover of the source node, is going on in NVMe. However, this can only solve the local link faults of the storage node, but cannot solve the problem of unconverged network faults. In storage application deployment scenarios, independent dual-plane networking maybe used. In this deployment, a single-plane device may be faulty. In this case, network convergence cannot be performed completely. In this proposal, a fast fault detection solution with switch participation is proposed. This scheme utilizes the ability of switches to detect faults quickly at the physical layer and link layer, and allows the switch to synchronize the detected fault information in the IP network, and then notify the fault status to the endpoint devices. Fault detection procedure: The host can detect the fault status of the storage device and quickly switch to the standby path. If a storage fault occurs, the access switch detects the fault at the storage network layer or link layer. The switch synchronizes the status to other switches on the network. The switch notifies the storage fault information to the hosts. Quickly disconnect the connection from the storage device and trigger the multipathing software to switch services to the redundant path. The fault should be detected within 1s.

| | | | | Figure 3: Switches interact with hosts and storage devices ]]>

Distributed storage cluster devices are interconnected through a network (back-end IP network) to establish a cluster. When a link fault on a node or node fault occurs in the storage cluster, other nodes in the storage cluster cannot detect the fault status of the indirectly connected devices through the transport layer. Based on the IP protocol, management or master nodes in a storage cluster use heartbeats to detect the status of storage nodes. It takes 10 seconds or more to determine whether a storage device is faulty and switch services to another normal storage node. Services cannot be accessed during the fault. To achieve the best customer experience and service reliability, we need to enhance the fault detection and failover of IP-based cluster nodes.

The fast fault detection solution in this proposal can be used in this scenario. This solution takes advantage of the switch's ability to quickly detect faults at the physical layer and link layer, and allows the switch to synchronize fault information detected on the IP network. Then, the system notifies the storage cluster management node or the primary node of the fault status. Fault detection procedure: If a storage fault occurs, the access switch detects the fault at the storage network layer or link layer. The switch synchronizes the status to other switches on the network. The switch notifies the storage fault information to the storage management or master node. The fault should be detected within 1s.

In cluster computing scenarios, for example, HPC cluster applications and AI cluster applications, cluster node faults and failures may occur on any node at any time. However, for a high-performance computing task, once a fault occurs, the entire task needs to be re-scheduled. However, It takes several minutes for the management node to detect the node fault status. During this period, new jobs may be scheduled to the faulty node, causing task execution failure. The fast fault detection solution in this proposal can be used in this scenario. The fault can be detected within seconds.

Fault detection procedure is similar to that of distributed storage like figure 6.