Users Guide

● Explicit ALUA - The storage processor changes the state of paths in response to commands (for example, the Set Target
Port Groups command) from the host (the metro node backend).
The storage processor must be explicitly instructed to change a path’s state.
If the active/optimized path fails, metro node issues the instruction to transition the active/non-optimized path to active/
optimized.
There is no need to failover the LUN.
● Implicit ALUA - The storage processor can change the state of a path without any command from the host (the metro
node back end).
If the controller that owns the LUN fails, the array changes the state of the active/non-optimized path to active/optimized
and fails over the LUN from the failed controller.
On the next I/O, after changing the path’s state, the storage processor returns a Unit Attention “Asymmetric Access State
Changed” to the host (the metro node backend).
Metro node then re-discovers all the paths to get the updated access states.
● Implicit/explicit ALUA - Either the host or the array can initiate the access state change.
Storage processors support implicit only, explicit only, or both.
Provisioning with metro node
Metro node allows easy storage provisioning among heterogeneous storage arrays. Use the web-based GUI to simplify everyday
provisioning or create complex devices.
There are two ways to provision storage in metro node:
● EZ provisioning
● Advanced provisioning
All provisioning features are available in the Unisphere for metro node UI.
Support for thin volumes and unmapping
Thin provisioning advertises the metro node virtual volumes as thin volumes to the hosts. Thin provisioning dynamically allocates
block resources only when they are required. It essentially allows efficient utilization of physical block resources from the
storage arrays.
Hosts gather the properties related to the thin provisioning feature of a metro node virtual volume and send SCSI commands
to free storage block resources that are not in use. If the blocks of the back end storage volumes are free, the blocks can be
mapped to other changed regions. Thin provisioning enables dynamic freeing of storage blocks on storage volumes for which
thin provisioning is supported.
NOTE:
The Dell EMC Simplified Support Matrix for metro node provides more information on the supported storage
volumes.
Metro node thin provisioning support includes the following features:
● Discovery of the back-end storage volumes capable for thin provisioning - During the back-end storage volume discovery,
metro node gathers all thin provisioning related storage volume properties. Metro node also performs a consistency check on
all the properties related to thin-provisioning.
● Reporting thin provisioning enabled metro node virtual volumes to hosts - metro node shares the details of the thin
provisioning-enabled virtual volumes with the hosts.
● Reclaiming the unused storage blocks - Through a command, metro node removes the mapping between a deleted virtual
machine and its storage volumes and reclaims the storage blocks corresponding to the VMFS blocks used by that virtual
machine.
● Handling storage exhaustion - The exhaustion of storage blocks on non-mirrored storage volumes are notified to the host
as a space allocation failure. This error notification is posted to the host and the VMware hosts stop the impacted virtual
machine.
To prevent potential mapping of all the blocks in the storage volumes that are thin capable, metro node uses thin rebuilds. Thin
rebuilds can be configured to be set or unset for any claimed storage volume on which metro node builds virtual volumes. This
property controls how metro node does its mirror rebuilding.
20
Features in metro node