Administrator Guide

● Temporary exhaustion: Occurs when a storage array is in the process of freeing up space and cannot immediately respond
back with a success to the write. In such a case, metro node retries I/O for short period of time, before failing the write
and marking the storage volume hardware-dead. A call home is issued in such a case and metro node tries to automatically
recover the storage volume when it responds successfully to its health tests. If the storage volume is protected by a healthy
mirror, the host does not see any disruption to the services as the healthy mirror leg continues to service I/Os to the host.
● Permanent exhaustion: Occurs when there are no more available storage blocks to map to the address to which the host has
issued a write command. metro node handles this error differently for mirrored and non-mirrored devices.
For permanent block-resource exhaustion on a non-mirrored storage volume, the requested write is responded with an
indication to metro node that the storage volume is write protected because space allocation has failed. metro node virtual
volumes also return the same error for the write command back to the host. When VMware hosts receive this error for a write
request, they stop the virtual machine that made the write request and allow other virtual machines to continue their operation.
Other virtual machines can successfully read and write to the blocks that are already mapped. But, if they make a write request
to an unmapped storage block, and that write also gets a resource exhaustion error, they are also stopped.
In a non-mirrored volume, Storage administrators can try reclaiming storage using the UNMAP command and recover from the
out of space error condition. If the reclaimed storage is not sufficient, add free block storage to storage arrays to address the
space allocation failed error conditions, and then start the virtual machines that are suspended or stopped.
For mirrored volumes, metro node masks the error that occurred on a mirror leg for a host write, like any other I/O error. metro
node completes the host request with success when the I/O succeeds on at least one mirror leg. metro node marks the mirror
leg Out-Of-Date (OOD) and does not try to rebuild (resurrect) automatically. A storage administrator has to allocate space on
the array and to make it available to this storage volume, and then manually recover the mirror leg by following the procedures
that are documented in Solve Desktop. Once the mirror has been recovered metro node rebuilds the leg.
If the permanent storage exhaustion occurs on the last leg of a mirrored volume, metro node propagates that error to the host
requesting the write as with a non-mirrored volume.
Setting thresholds to the thin storage usage
An administrator can set a soft limit or threshold to certain thinly provisioned storage, which indicates the storage space for
the thinly provisioned device is diminishing. This threshold is configured on the host or on the arrays, and not on metro node.
The message indicates that the device reached the set threshold. Currently, on receiving such a notification from a storage
device, metro node retries the I/O after sending a call home. Such notifications can be received once on an I/O, and the
I/O must eventually succeed, unless the thin device runs out of space. On receiving such a call home notification, the metro
node administrator can notify the host administrator to either free up space or request the storage administrator to add more
capacity.
Thin mirroring and migration
Metro node supports the mirroring of thin volumes and the migration of the thin volumes to different arrays.
During the rebuild of a thin leg, metro node preserves the thin nature of the leg. To do this, metro node issues the SCSI UNMAP
command to the arrays that support these commands and writes zeros to the blocks on the arrays that do not support the
UNMAP feature. Rebuilds for thin provisioned storage provides you additional information on thin rebuilds.
Performing thin mirroring
If you attach a mirror to a thin-capable device and that mirror is not thin, the resulting RAID 1 device loses its thin-capability.
When you run the device attach-mirror -d command to attach a thick mirror leg to a thin-capable device, a warning
stating that the device is not thin-capable is displayed. You are also prompted to confirm that you want to continue. You can use
the --force option to bypass the confirmation, but the resulting device is not thin.
VPlexcli:/clusters/cluster-1/storage-elements/extents> device attach-mirror -d myDevice
-m extent_TOP_101_1
The top-level device 'myDevice' is thin-capable. After attaching the mirror, the new
top-level device will not be thin-capable. Do you wish to proceed? (Yes/No) no
device attach-mirror: Evaluation of <<device attach-mirror -d myDevice -m
extent_TOP_101_1>> failed.
cause: Failed to attach mirror.
Thin support in metro node
27