Users Guide

￭ If half of the operational directors with quorum fail, then the remaining directors will check the operational status of
the failed directors over the management network and remain alive.
After recovering from this failure, a cluster can tolerate further similar director failures until only one director is
remaining. In a single engine cluster, a maximum of one director failure can be tolerated.
○ Intra-cluster communication failure
￭ If there is a split in the middle, that is, half of the operational directors with quorum lose communication with the
other half of the directors, and both halves are running, then the directors detect the operational status over the
management network and instruct half with the director with the lowest UUID to keep running and the directors
without the lowest UUID to operationally stop.
● Quorum loss - An operational metro node cluster seeing failures stops operating in the following scenarios:
○
If more than half of the operational directors with quorum fail at the same time.
○ If half of the operational directors with quorum fail, and the directors are unable to determine the operation status of the
other half of the directors (whose membership includes a low UUID).
○ In a dual or quad engine cluster, if all of the directors loose contact with each other.
Metadata volumes
Meta-volumes store metro node metadata, including virtual-to-physical mappings, data about devices, virtual volumes, and
system configuration settings.
Metadata is stored in cache and backed up on specially designated external volumes called meta-volumes.
After the meta-volume is configured, updates to the metadata are written to both the cache and the meta-volume when the
metro node configuration is modified.
Each metro node cluster maintains its own metadata, including:
● The local configuration for the cluster.
● Distributed configuration information shared between clusters.
At system startup, metro node reads the metadata and loads the configuration information onto each director.
When you make changes to the system configuration, metro node writes these changes to the metadata volume.
If metro node loses access to the metadata volume, the metro node directors continue uninterrupted, using the in-memory copy
of the configuration. Metro node blocks changes to the system until access is restored or the automatic backup meta-volume is
activated.
Meta-volumes experience high I/O only during system startup and upgrade.
I/O activity during normal operations is minimal.
Backup metadata volumes
Backup metadata volumes are point-in-time snapshots of the current metadata, and provide extra protection before major
configuration changes, refreshes, or migrations.
Backup creates a point-in-time copy of the current in-memory metadata without activating it. You must create a backup
metadata volume in any of these conditions:
● As part of an overall system health check before a major migration or update.
● If metro node permanently loses access to active meta-volumes.
● After any major migration or update.
Logging volumes
Logging volumes keep track of blocks written:
● During an inter-cluster link outage.
● When one leg of a DR1 becomes unreachable and then recovers.
After the inter-cluster link or leg is restored, the metro node system uses the information in logging volumes to synchronize the
mirrors by sending only changed blocks across the link.
Integrity and resiliency
25