Emc IP Holding Company LLC

Emp IP Holding Company LLC

Mukesh Gupta

Dmitry Nikolayevich Tylik

David Lionel Black

Marina Shem Tov

Arthur Otis Harris

Daniel E Cummins

Chen Reichbach

Vasiliy Mihailovich Tolstoy

Philippe Armangau

Jean-Pierre Bono

John Forecast

Frederic Corniquet

Alexey Vladimirovich Shusharin

Yuri Alexandrovich Stotski

Sathya Krishna Murthy

Robert Evan Frazier

Pascal Donette

Sergey Alexandrovich Kovalev

A method, computer program product, and computer system for dividing a physical Ethernet port is provided. The method may include dividing, by a computing device, a first physical Ethernet port of a plurality of physical Ethernet ports into a plurality of partitions. A first partition of the plurality of partitions for the first Ethernet port may be assigned to a N-virtual distributed switch. A second partition of the plurality of partitions for the first Ethernet port may be assigned with a plurality of functions. Ethernet packets may be switched between the plurality of functions in the second partition.

System and method for dividing a physical ethernet port

A command is received from a host regarding accessing an NVMe dispersed namespace in a metro cluster configuration of storage arrays. A namespace group state corresponding to the host and the port is determined and returned to the host. The namespace group state indicates whether the specific communication path between the host and the port is optimized or non-optimized. The namespace group state indicates that the communication path is non-optimized where the host is not located at the same location as the storage array, and that the communication path is optimized where the host is located at the same location as the storage array and the node of the storage array is a preferred node for processing I/O directed to the NVMe dispersed namespace from hosts located in the same location as the storage array.

Indicating optimized and non-optimized paths to hosts using NVMe-oF in a metro cluster storage system

A method, computer program product, and computing system for generating, at a first storage appliance of a plurality of storage appliances, a first volume that is configured to be managed by the first storage appliance, wherein data within the first volume is accessible by the first storage appliance. In response to generating the first volume, a protocol identifier representation of the first volume may be generated at each other storage appliance of the plurality of storage appliances and may be configured to be managed by a respective storage appliance of the plurality of storage appliances.

System and method for migrating volumes between storage appliances

Discovery service contact information is provided from a data storage system to administration logic of a virtualization environment, and distributed within the virtualization environment to hypervisor hosts, enabling the hypervisor hosts to discover logical ports within the data storage system, and then establish logical communication paths between the hypervisor hosts and the ports. In response to determining that the data storage system supports virtual volumes, the hypervisor hosts indicate hypervisor capability of using virtual volumes to the data storage system, and the data storage system exposes virtual volumes to hypervisors in response to indications of the ability of those hypervisors to use virtual volumes.

Configuring host access for virtual volumes

A method, computer program product, and computing system for defining a vVol NVMe subsystem for a plurality of vVol NVMe namespaces within a storage system; and enabling an Asymmetric Namespace Access (ANA) group that aggregates two or more vVol NVMe namespaces defined within the plurality of vVol NVMe namespaces and communicates ANA group information in-band, thus eliminating the need for out-of-band communication of vVol protocol endpoint information.

Virtual disk container and NVMe storage management system and method

Migrating a source volume from a source appliance to a destination appliance, wherein the source volume is assigned to an asymmetric namespace access (ANA) group and initially exposed to a host computer as accessible at the source appliance, includes creating a destination volume on the destination appliance and expanding the ANA group to include the destination volume, with the ANA group initially exposing the destination volume as inaccessible to the host computer at the destination appliance. Subsequently, the destination volume is synchronized to the source volume and then a cutover is performed that includes (i) copying volume metadata including host reservations from the source volume to the destination volume, and (ii) changing the ANA group to expose the source volume as inaccessible at the source appliance and the destination volume as accessible at the destination appliance.

Volume migration using cross-appliance asymmetric namespace access group

A data storage system (DSS) in a cluster provides virtual-volume data storage to virtual-computing (VC) hosts using NVMe-oF storage interconnect. A DSS creates protocol endpoints (PEs) and corresponding namespace groups, each being a grouping of namespaces corresponding to virtual volumes (vVols) to be bound for access by a respective VC host, and each namespace being mapped to corresponding underlying physical storage. Each namespace group is initially created with a corresponding in-band discoverable dummy namespace. In response to in-band storage discovery commands from the VC hosts, and based on the existence of the dummy namespaces, the DSS responds with responses identifying the namespace groups. Then in response to subsequent vVol creation commands from the VC hosts, the DSS creates new namespaces in respective namespace groups and provides namespace identifiers for the new namespaces to the VC hosts for use in accessing data of the vVols.

Data storage system employing dummy namespaces for discovery of NVMe namespace groups as protocol endpoints

An aspect of volume migration includes establishing a connection between hosts and a non-volatile memory over fabric (NVMeoF) controller for appliances, and creating and exposing a volume as a namespace to hosts. The namespace forms part of an asymmetric namespace access (ANA) group in which optimized paths are exposed to the hosts. Upon receiving a request to migrate the volume from a source appliance to a destination appliance, an aspect further includes creating a namespace on the destination, and configuring the ANA group of the namespace as inaccessible. Through the connection, an aspect includes initiating an asynchronous event notification (AEN) to the host to connect ports on the destination and, upon connecting to the ports, discovering by the hosts on the destination, the namespace created, verifying the hosts have connected to the ports and have discovered the namespace, and migrating data to the destination and performing input/output cutover.

Volume migration in a federated storage array with non-volatile memory express over fabric (NVMeoF) host attachment

Techniques of operating a server computer running an application for clients operating in multiple network namespaces involve multiplexing communications streams from clients hosted in different network namespaces into a single communication stream to present the requests to an application as if they originated from a single network namespace. Along these lines, a server computer commences operation by initiating a network namespace driver for each network namespaces and a multiplexing driver to multiplex network namespace communication streams received from the network namespace drivers. When the multiplexing driver receives an application access request from a network namespace driver within a network namespace communication stream, the multiplexing driver provides the request and a network namespace identifier identifying the network namespace driver to a stream head within a multiplexed communication stream that includes requests from other network namespace drivers.

Multiplexing traffic from multiple network namespaces to a single listener in a stream-based server application

Improved techniques of running multitenant applications involve opening sockets in multiple network namespaces through which respective tenants may access a monolithic application thread. A server running such an application may assign tenants network bandwidth through one or more network namespaces. Each network namespace has its own independent set of network addresses that may overlap or even be identical to another namespace's set of network addresses. The server may then identify a request to access application data with a particular tenant by network identifiers such as virtual local area network (VLAN) identifiers attached to the request. Thus, even though two established sockets may include identical source and destination addresses, data may be exchanged between the server and the intended tenants.

Network address sharing in a multitenant, monolithic application environment

Techniques for routing network traffic in a storage processor involve providing per-IP routing tables for each IP address of a virtual server and a per-server routing table. These per-IP and per-server routing tables specify its own interface(s) with external network(s). The storage processor assigns each outbound protocol data unit (PDU), generated by a particular virtual server, to either a per-IP routing table or a per-server routing table provided for that virtual server. The assignment of the routing table is based on source IP address or a connection mark associated with an outbound PDU. The per-IP or per-server routing table(s) identifies an interface through which the packet is routed to the destination IP address.

Separating network traffic among virtual servers

A multi-core processor of a network attached storage system processes requests from host computers for services of a file system service. Each core maintains endpoints of respective connection-layer connections to the hosts to affine respective streams of network traffic with the core, and dynamically and preferentially assigns execution threads of the core to process file system service requests of the streams affined with the core. Each core also co-operates with the other cores to dynamically and non-preferentially (a) assign execution threads of the core to process file system service requests of the streams affined with the other cores, and (b) assign execution threads of the other cores to process file system service requests of the streams affined with the core, promoting efficient use of the cores for the processing workload of the file system service.

Growing community of inventors

Shrewsbury, MA, United States of America

Mukesh Gupta