Dell EMC Metro node 7.0.1 Release Notes

Expected behaviors

This section describes expected behaviors in metro node.

• System volumes such as metadata and logging volumes are supported on thin devices. However, metro node relies on these volumes for system operations. All extents should be pre-allocated, to prevent out-of-space conditions.
• While the clusters are in contact, metro node prevents the same storage volume from being claimed at each cluster. However, if the clusters are partitioned, metro node cannot prevent the same storage volume from being claimed at both clusters. If this happens, once metro node detects this, a call home is sent. This issue should be corrected when it is detected.
• When one leg of a distributed device within a consistency group is unhealthy and marked for a rebuild, you are prevented from removing the unhealthy leg. A distributed consistency group requires two-legged distributed device members. To avoid this issue:
  1. Use the attach mirror command to attach a new mirror to the healthy leg.
  2. Detach the old unhealthy mirror.
• If the metadata usage at a cluster exceeds 90%, metro node triggers a call home event. If the metadata on the other cluster also exceeds 90% within 8 hours of the first cluster, metro node does not trigger a call home event. This is by design and occurs in metro node Metro configurations.
• In Unisphere, Provision by pools and Provision by Storage volumes wizards allow you to select only consistency groups that have a value set for storage-at-clusters property.
• If host I/O performance is impacted during a data migration or during a rebuild, then lower the rebuild transfer-size setting for the devices, or reduce the number of concurrent migrations/rebuilds. For more information, see the Admin guide for metro node feature available at www.dell.com/support.
• Ensure that the host resources are sufficient to handle the number of paths provisioned for the metro node system.
• Poor QoS on the WAN-COM link in a Metro configuration could lead to undetermined behavior and data unavailability in extreme cases. Please follow the Best Practices to configure and monitor WAN-COM links.
• Metro node in Metro configurations does not provide native encryption over the IP WAN COM link. Customers should deploy an external appliance to achieve data encryption over the IP WAN links between clusters.
• When a claimed storage volume becomes hardware dead metro node automatically probes the storage volume within 20s. If the probe succeeds, metro node removes the “dead” status from the volume, thus returning it to a healthy state.
  CAUTION: While the device is hw-dead, do not perform operations that change data on the storage volumes underneath metro node RAID 1 (through maintenance or replacing disks within the array). If such operations are required, first detach the storage volumes from the metro node RAID 1, perform the data changing operations, and then re-add the storage volumes to the metro node RAID 1 as necessary to trigger a rebuild. Failure to follow these steps changes data underneath metro node without its knowledge. Without a data rebuild, the RAID 1 legs might be inconsistent and this may lead to data corruption on resurrection.
• Storage volumes that are used as system volumes (metro node metavolume RAID 1 mirror legs, logging volumes, and backups for the metavolume) must be formatted/zeroed out before being used by metro node as a system volume.
• There are two types of failure handling for back-end array interactions.
  • The unambiguous failure responses, such as requests rejected by storage volume or port leaving the back-end fabric.
  • The condition where storage arrays enter fault modes such that one or more of its target ports remained on the fabric, while all SCSI commands sent to it by the initiator (metro node) timed out.

  Metro node isolates the paths which remain on the fabric but stay unresponsive. In this case, I/O requests sent by a host initiator to metro node virtual volumes are redirected away from unresponsive paths to the back-end array, onto paths that are responsive. At the time of isolation, metro node issues a call home event.

• The export port summary of a front-end port with no-link status has the export status as suspended.