Skip to main content

Key concepts

Contributors netapp-ahibbard netapp-thomi netapp-lenida

SnapMirror Business Continuity (SM-BC) utilizes features such as consistency groups and the ONTAP Mediator to ensure your data is replicated and served even in the event of a disaster scenario. When planning your SM-BC deployment, it is important to understand the essential concepts in SM-BC and its architecture.

Architecture

The following figure illustrates a high-level overview of an SM-BC deployment.

SnapMirror Business Continuity workflow

The diagram shows an enterprise application that is hosted on an storage VM (SVM) at the primary data center. The SVM contains five volumes, three of which are part of a consistency group. The three volumes in the consistency group are mirrored to a secondary data center. In normal circumstances, all write operations are performed to the primary data center; in effect, this data center serves as the source for I/O operations, while the secondary data center serves as a destination.

In the event of a disaster scenario at the primary data center, the ONTAP Mediator will direct the secondary data center to act as the primary, serving all I/O operations. Only the volumes that are mirrored in the consistency group will be served. Any operations pertaining to the other two volumes on the SVM will be affected by the disaster event.

Essential concepts

Understanding the following terms will help you deploy SM-BC.

Consistency group

A consistency group is a collection of volumes or LUNs that provide a write-order consistency guarantee for the application workload that needs to be protected for business continuity. A consistency group ensures all volumes of this data set are quiesced and then snapped at the same point in time, providing a data-consistent restore point across volumes for that data set.

In SM-BC, you will create a primary and secondary consistency group for replication and data protection. The secondary consistency group will serve your data in the event of a disruption.

To learn more about consistency groups, see Consistency groups overview.

Constituent

An individual volume or LUN that is part of a consistency group, which is protected by the SM-BC relationship.

ONTAP Mediator

The ONTAP Mediators monitors the two ONTAP clusters and orchestrates failover in case your primary storage system fails. With the ONTAP Mediator, your application automatically reconnects to the resources in the secondary storage system.

With the ONTAP Mediator's health information, clusters can differentiate between intercluster LIF failure and site failure. When the site goes down, ONTAP Mediator passes on the health information to the peer cluster on demand, facilitating the peer cluster to failover.

Learn more about the ONTAP Mediator.

Planned failover

A manual operation to change the roles of copies in a SM-BC relationship. The primary sites becomes the secondary, and the secondary becomes the primary.

Automatic unplanned failover (AUFO)

An automatic operation to perform a failover to the mirror copy. The operation requires assistance from Mediator to detect that the primary copy is unavailable.

Out of Sync (OOS)

When the application I/O is not replicating to the secondary storage system, it will be reported as out of sync. An out of sync status means the secondary volumes are not synchronized with the primary (source) and that SnapMirror replication is not occurring.

If the mirror state is Snapmirrored, this indicates a transfer failure or failure due to an unsupported operation.

Zero RPO

RPO stands for recovery point objective, which is the amount of data loss deemed acceptable during a given time period. Zero RPO signifies that no data loss is acceptable.

Zero RTO

RTO stands for recovery time objective, which is the amount of time that is deemed acceptable for an application to return to normal operations following an outage, failure, or other data loss event. Zero RTO signifies that no amount of downtime is acceptable.