Abstract: A technique is disclosed for ending metro-clustering on metro volumes. The technique includes collecting a plurality of metrics that indicate respective characteristics associated with a metro volume. In response to receiving a request to end metro on the metro volume, the technique includes comparing the plurality of metrics with a database that associates multiple permutations of metrics with respective procedures for ending metro. The technique further includes identifying, based on the comparison, a target procedure having a permutation of metrics that matches the plurality of metrics and implementing the target procedure.

Abstract: A technique is disclosed for managing abort tasks in a metro cluster that includes a first array and a second array. The technique includes receiving, by the first array, a write request from a host, the write request specifying a range of data to be written to a stretched volume. The technique further includes receiving an abort task from the host for aborting the write request. In response to receipt of the abort task, the technique further includes the first array delaying a successful response to the abort task back to the host until the first array receives a notification that the second array has locked the range of data specified by the write request.

Abstract: A method of creating a clone, on a second data storage appliance of a federation, of a source storage object stored on a first data storage appliance of the federation, includes creating a snapshot (point-in-time copy) of the source storage object at the first appliance, and then performing a full copy of the snapshot from the first appliance to the second appliance to produce a copy snapshot on the second appliance. At the second appliance, the clone is created from the copy snapshot and incorporated into a federation-wide family association of the source storage object. Specific use cases include (1) creating a clone on a different appliance from a base volume, (2) migrating a clone to a different appliance from a base volume, (3) refreshing a clone from a base volume, and a base volume from a clone, across appliances.

Abstract: A technique for managing communications between a server and multiple clients includes configuring the server to support multiple sets of certificates for respective clients having respective root certificates. The technique further includes determining an indicator associated with a client root certificate during an initial handshake between a client and the server and providing the client with a server certificate associated with the indicator.

Abstract: A technique of managing virtual volumes includes receiving, by a storage system, instructions to create specified virtual volumes in the storage system, the instructions including virtual volume metadata that identifies virtual machines to which the specified virtual volumes are assigned, and providing a database that associates such virtual volumes with the virtual machines identified by the virtual volume metadata. The technique further includes performing a storage activity on a virtual machine by identifying, from the database, multiple virtual volumes that the database associates with the virtual machine and performing the storage activity on all of the identified virtual volumes together as a group.

Abstract: 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.

Abstract: In a protective quorum service, during an initial period of normal operation in which a clustered pair of data storage nodes provide host I/O access to a data storage object and replicate write-type requests to each other, the nodes are first registered to the quorum service. Subsequently, based on the registration and in response to a first auto promote request from a first-requesting node, a success response is returned and the service enters an auto promoted condition, the success response indicating that the first-requesting node is to continue providing the host I/O access to the data storage object without write replication. In response to receiving a subsequent auto promote request from the other node when in the auto promoted condition, a failure response is returned indicating that the other node is to cease providing host I/O access to the data storage object.

Abstract: A technique for maintaining synchronization between two arrays includes assigning one array to be a preferred array and the other array to be a non-preferred array. When write requests are received at the preferred array, the writes are applied locally first and then applied remotely. However, when write requests are received at the non-preferred array, such writes are applied remotely first and then applied locally. Thus, writes are applied first on the preferred array and then on the non-preferred array, regardless of whether the writes are initially received at the preferred array or the non-preferred array.

Abstract: In a protective quorum service, during an initial period of normal operation in which a clustered pair of data storage nodes provide host I/O access to a data storage object and replicate write-type requests to each other, the nodes are first registered to the quorum service. Subsequently, based on the registration and in response to a first auto promote request from a first-requesting node, a success response is returned and the service enters an auto promoted condition, the success response indicating that the first-requesting node is to continue providing the host I/O access to the data storage object without write replication. In response to receiving a subsequent auto promote request from the other node when in the auto promoted condition, a failure response is returned indicating that the other node is to cease providing host I/O access to the data storage object.

Abstract: 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.

Abstract: A technique of managing virtual volumes includes receiving, by a storage system, instructions to create specified virtual volumes in the storage system, the instructions including virtual volume metadata that identifies virtual machines to which the specified virtual volumes are assigned, and providing a database that associates such virtual volumes with the virtual machines identified by the virtual volume metadata. The technique further includes performing a storage activity on a virtual machine by identifying, from the database, multiple virtual volumes that the database associates with the virtual machine and performing the storage activity on all of the identified virtual volumes together as a group.

Abstract: A technique for deploying virtual volumes in a metro cluster across first and second arrays includes impersonating a third array that purports to host single-site virtual volumes. The technique further includes mapping the single-site virtual volumes purportedly hosted by the third array to respective pairs of actual virtual volumes. Each pair includes a first virtual volume in the first array and a second virtual volume in the second array and realizes a stretched virtual volume, with writes being mirrored between the virtual volumes of each pair.

Abstract: A technique for maintaining synchronization between two arrays includes assigning one array to be a preferred array and the other array to be a non-preferred array. When write requests are received at the preferred array, the writes are applied locally first and then applied remotely. However, when write requests are received at the non-preferred array, such writes are applied remotely first and then applied locally. Thus, writes are applied first on the preferred array and then on the non-preferred array, regardless of whether the writes are initially received at the preferred array or the non-preferred array.

Abstract: 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.

Abstract: 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.

Abstract: A clustered pair of data storage nodes employs a time-to-live (TTL) mechanism by which a preferred node communicates permission for continued operation to a non-preferred node. During non-errored TTL operation, host I/O requests to a data storage object are serviced, with write-type requests being replicated to the other node. Upon a failure as indicated by errored TTL operation or failure of replication, a polarization operation selects a surviving node to transition to single-node access to the data storage object. The polarization process includes: (1) each node contacting a witness node to request survivor status, (2) the witness node granting survivor status to the first node requesting it and denying survivor status to a later-requesting node, (3) at the node granted survivor status, continuing to service the host I/O requests without replication, and (4) at the other node based on being denied survivor status, discontinuing servicing of the host I/O requests.

Abstract: A technique for managing communications between a server and multiple clients includes configuring the server to support multiple sets of certificates for respective clients having respective root certificates. The technique further includes determining an indicator associated with a client root certificate during an initial handshake between a client and the server and providing the client with a server certificate associated with the indicator.

Abstract: 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.

Abstract: 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.

Abstract: A hierarchy of multiple levels of storage resources and associated QOS (quality of service) limits and buckets of tokens may be specified. A different QOS limit may be applied to each individual storage resource. The buckets may denote current amounts of tokens available for consumption in connection with servicing I/O operations. Each bucket may denote a current amount of available tokens for a corresponding storage resource of included in the hierarchy. Processing may include receiving a first I/O operation directed to a first storage resource, and determining, in accordance with the buckets of available tokens, whether to service the first I/O operation.