Dell EMC Metro node 7.0.1 Administrator Guide

Handling storage exhaustion on thin volumes

A storage array can respond back to metro node with a storage exhaustion error on a write to a thin volume. The storage administrators who continuously monitor storage pool capacity takes necessary actions to avoid any storage block exhaustion in their datacenters.

There are mainly two types of storage block exhaustion errors that a storage array can notify. They are:

• 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.