Dell Products Inc.

Claudio Desanti

Erik P Smith

Joseph LaSalle White

David Lionel Black

Douglas L Farley

Pawan Kumar Singal

Martin Gilbert Belanger

Anoop Ghanwani

Raja Sathianarayan Jayakumar

Sakti Lakshmiy R Paulchamy

Embodiments presented herein solve issues related to non-volatile memory express (NVMe®) protocol differences from other protocols, such as Fibre Channel Common Transport, which is the protocol used for Zoning management in Fibre Channel. Fibre Channel Common Transport supports bidirectional transfers of data. However, NVMe® commands support transfer of data either with the command (e.g., host-to-controller data transfer (e.g., a 'write' operation)) or with the response (e.g., controller-to-host data transfer (e.g., a “read” operation)), but not both creates a problem related to zoning in NVMe® networks. Furthermore, data size limits for submission queue entries and completion queue entries for NVMe® commands add other obstacles. Embodiments herein address these limitations.

Storage subsystem-driven zoning in a non-volatile memory express environment

A multiple independent storage fabric SAN system includes a storage system. A first storage fabric includes a first switch device that is directly connected to the storage system, and first host devices that are directly connected to the first switch device and each configured to transmit storage data traffic via the first switch device with the storage system. A second storage fabric is independent from the first storage fabric and includes a second switch device that is directly connected to the storage system and that is not configured to transmit storage data traffic with the first switch device, and second host devices that are directly connected to the second switch device and each configured to transmit storage data traffic via the second switch device with the storage system. The storage system is configured to provide first storage services to each of the first storage fabric and the second storage fabric.

Multiple independent storage fabric SAN system

A headroom-based result determination system includes first and second ports connected via a link, and a buffer for the first port. A headroom-based result determination subsystem monitors data stored in the buffer that was received in data packets each having a worst-case data packet size and transmitted at a maximum packet rate for a link speed of the link, determines that a buffer threshold is reached and, in response, generates a pause instruction. The headroom-based result determination subsystem then transmits the pause instruction to the second port, measures a first amount of data stored in the buffer subsequent to generating the pause instruction, and generates a headroom-based result by adding the first amount of data, a second amount of data equal to a maximum transmission size of the first port, and a third amount of data equal to a maximum transmission size of a class of the data received at the first port.

Buffer headroom-based result determination system

Two main methods exist today to enforce access control in a network fabric: soft zoning and hard zoning. However, each of these approaches has some significant drawbacks. Accordingly, presented herein are new and improved systems and methods to perform access control enforcement, which is stronger than soft zoning, and does not need to interact with the fabric switches, as required by hard zoning. In one or more embodiments, an authentication verification entity (AVE) is provided with access control or authorization information. In one or more embodiments, the AVE uses this information to cause an authentication verification failure for connections between hosts and subsystems that are not allowed according to configurations (e.g., zoning configurations) of the fabric.

Access enforcement through authentication verification entity (AVE)

Embodiments presented herein enable non-volatile memory express (NVMe®) subsystem-driven zoning. By configuring subsystems as pull devices, subsystems can request a centralized discovery controller to perform fabric zoning operations. Embodiments may leverage a command execution request architecture to achieve the subsystem-driven pull registration functionality. In one or more embodiments, a zone group identifier is used to identify the specific zone group of interest, and a transaction identifier may be used for correlating various communications to the fabric zoning operation. In one or more embodiments, locking may be performed on zone groups to maintain control of changes to zone groups.

Systems and methods for storage subsystem-driven zoning for pull model devices

Embodiments presented herein enable non-volatile memory express (NVMe®) subsystem-driven command execution requests. By configuring subsystems as pull model devices, subsystems can request a centralized discovery controller to perform one or more operations. Embodiments may leverage a command execution request architecture to achieve the subsystem-driven pull model functionality.

Systems and methods for command execution request for pull model devices

A traditional storage platform performs many basic functions, such as storage partitions allocation (i.e., namespace masking) and many advanced functions, such as deduplication or dynamic storage allocation. These functions need to be managed and this results in a multiple management system paradigm in which a fabric management application manages the fabric connectivity policies (i.e., zoning), while a storage management application manages the storage namespace mappings and advanced functions. Embodiments herein provide for centralized management for both connectivity and storage namespace mapping, among other advanced features. Namespace zoning information may comprise namespace zone groups, namespace zones, namespace zone members, namespace zone aliases, and namespace zone alias members, which expand the Non-Volatile Memory Express (NVMe) over Fabrics (NVMe-oF) zoning framework from just connectivity control to full namespace allocation.

Systems and methods for NVMe over fabric (NVMe-oF) namespace-based zoning

Storage subsystem-driven zoning protocol embodiments in a nonvolatile memory express environment

Currently, there is no scalable methodologies defined to locate a namespace on an NVMe-oF fabric. Therefore, it is necessary to configure a host with the NVMe™ Qualified Name (NQN) and transport information of the storage subsystem where the boot namespace is located or discover and enumerate all namespaces available to the host on an NVMe-oF fabric. With the current protocols, a host may need to perform many operations to locate the proper namespace and boot from the NVMe-oF fabric, making booting in a SAN environment an extremely slow operation and computationally expensive process. Embodiments herein support discovery, via a discovery controller, to provide a namespace resolution service able to facilitate a host to efficiently resolve a given namespace identifier to the corresponding subsystem port(s) through which that namespace is accessible.

Discovery controller-based nonvolatile memory express namespace resolution services

Centralized quality-of-service (QoS) policies administration in a storage area network (SAN) is a problem without meaningful solutions. Current implementations require explicit administration of end points, which is error-prone and not scalable. Zoning for NVMe-oF is defined as a method to specify connectivity access control information on the Discovery Controller (DC) of an NVMe-oF fabric, not as a way to specify QoS policies. Embodiments comprise centrally specifying one or more QoS parameters as part of NVMe-oF zoning definitions maintained at an NVMe-oF DC to centrally controlled QoS parameters. Accordingly, embodiments provide mechanisms to specify QoS parameters in a centralized manner to eliminate requiring a system administrator having to perform per-connection QoS provisioning.

Scalable quality of service (QoS) for a nonvolatile memory express™ environment

A scalable EBOF storage system identifies its storage devices and external physical interfaces, and respective public IP addresses assigned to each external physical interface. The scalable EBOF storage system assigns a respective private IP address to each storage device, private port identifier(s) to the storage devices, and respective public port identifier(s) to each storage device. The scalable EBOF storage system then generates an EBOF NAT table by mapping, for each storage device: each respective public IP address assigned to the external physical interfaces to the public port identifier assigned to that storage device to provide a public connection information combination for that storage device, the private IP address assigned to that storage device to the private port identifier assigned to that storage device to provide a private information connection combination for that storage device, and the public information connection combination to the private information connection combination for that storage device.

Scalable ethernet bunch of flash (EBOF) storage system

Systems and methods provide modern storage networks, such as those utilizing a non-volatile memory express over Fabric (NVMe-oF) system, with connectivity options that meet low-latency and high-throughput demands. In certain embodiments, this is accomplished by enabling network entities to acquire and utilize network information, including discovery information, to dynamically manage routing tables and build routes, e.g., to allow a host to send out frames through desired interfaces to reach target destinations. An automated IP routing update service allows for dynamically creating, reading, updating, and deleting functions of otherwise static IP routing table entries to streamline functions in the storage fabric.

Automated internet protocol (IP) route update service for ethernet layer 3 (L3) IP storage area networks (SANs)

Systems and methods provide zero-configuration provisioning for modern storage networks such as those utilizing a non-volatile memory express over Fabric (NVMe-oF) system. In various embodiments, this is accomplished by leveraging discovery information, such as multicast Domain Name System (mDNS) information, to locate subsystems in a network and to explicitly and dynamically specify target destinations without a Centralized Discovery Controller (CDC) client having to modify its routing table.

Automated ethernet layer 3 (L3) connectivity between non-volatile memory express over fabric (NVMe-oF) hosts and NVM-oF subsystems using bind

Embodiments herein comprise a centralized NVMe-oF namespace masking and configuration repository, which may be referenced for convenience herein as a distributed configuration service (DCS). By centralizing the functionality, there is no longer a requirement that each host, network element, and subsystem have its own user interface (UI). DCS embodiments provide a single UI for a number of features, including but not limited to: (1) viewing the list of Host interfaces that are attached to the network and are registered; (2) viewing the list of Subsystem interfaces that are attached to the IP Network and are registered with the DCS; (3) viewing the storage capacity available behind each subsystem interface; and (4) allowing a user to define the Host to Subsystem interface relationships as well as define how much storage should be allocated to each Host.

Centralized discovery controller storage provisioning

An NVMe-oF authentication system includes an authentication verification entity coupled to an NVMe subsystem that is coupled to an NVMe host device. The NVMe subsystem transmits a first challenge to the NVMe host device and, in response, receives a first challenge reply from the NVME host device. The NVMe subsystem then generates a first authentication verification request communication that includes a first response that was provided in the first challenge reply by the NVMe host device using a first instance of a first secret that is stored in the NVMe host device, and transmits the first authentication verification request communication to the authentication verification entity. The authentication verification entity receives the first authentication verification request communication, verifies the first response using a second instance of the first secret that is stored in the authentication verification entity and, in response, transmits a first authentication verification response communication to the NVMe subsystem.

Growing community of inventors

Santa Cruz, CA, United States of America

Claudio Desanti