Users Guide

Table 4. How metro node Metro HA recovers from failure (continued)
Failure description Failure handling
Inter-cluster link failure
● If the cross-connects use different physical links from
those used to connect the metro node clusters,
applications are unaffected. Every volume continues to be
available in one data center or the other.
● If the cross-connect links use the same physical links
as those used to connect the metro node clusters, an
application restart is required.
Storage array failure Applications are unaffected. Metro node dynamically redirects
I/O to the mirrored copy on the surviving array.
NOTE: This example assumes that all distributed volumes
are also mirrored on the local cluster. If not, then the
application remains available because the data can be
fetched or sent from or to the remote cluster. However,
each read/write operation now incurs a performance cost.
Failure of
metro node Witness
Both clusters call home. As long as both clusters continue to
operate and there is no inter-cluster link partition, applications
are unaffected.
CAUTION: If either cluster fails or if there is an
inter-cluster link partition, the system is at a risk
of data unavailability. If the metro node Witness
outage is expected to be long, disable the metro
node Witness functionality to prevent the possible
data unavailability.
Metro HA without cross-connect failure management
This section describes the failure scenarios for metro node Metro HA without cross-connect.
Metro node cluster failure
In the event of a full metro node cluster outage at one site:
● Metro node Witness guides the surviving cluster to continue.
● VMware at the surviving cluster is unaffected.
● VMware restarts the virtual machines at the site where the outage occurred, redirecting I/O to the surviving cluster.
VMware can restart because the second metro node cluster has continued I/O without interruption.
Inter-cluster link failure - non-preferred site
If an inter-cluster link outage occurs, the preferred cluster continues, while the non-preferred cluster suspends. If a virtual
machine is located at the preferred cluster, there is no interruption of service. If a virtual machine is located at the non-
preferred cluster, the storage associated with the virtual machine is suspended. In such a scenario, most guest operating
systems will fail. The virtual machine will be restarted at the preferred cluster after a short disruption.
NOTE: The preferred cluster is determined by consistency group detach rules.
If an inter-cluster link outage occurs:
● Metro node Witness guides the preferred cluster to continue.
● VMware at the preferred cluster is unaffected.
● VMware restarts the virtual machines at the non-preferred (suspended) cluster, redirecting I/O to the preferred
(uninterrupted) cluster.
VMware can restart because the second metro node cluster has continued I/O without interruption.
Integrity and resiliency
31