Considerations for creating SnapMirror cascade and fanout relationships for FlexGroups
There are support considerations and limitations you should keep in mind when creating SnapMirror cascade and fanout relationships for FlexGroup volumes.
Considerations for creating cascading relationships
-
Each relationship can be either an inter cluster or intra cluster relationship.
-
All asynchronous policy types, including async-mirror, mirror-vault, and vault, are supported for both relationships.
-
Only "MirrorAllSnapshots," not "MirrorLatest" async-mirror policies are supported.
-
Concurrent updates of cascaded XDP relationships is supported.
-
Supports removing A to B and B to C and resync A to C or resync C to A.
-
A and B FlexGroup volumes also support fanout when all nodes are running ONTAP 9.9.1 or later.
-
Restore operations from B or C FlexGroup volumes are supported.
-
Transfers on FlexGroup relationships are not support while the destination is the source of a restore relationship.
-
The destination of a FlexGroup restore cannot be the destination of any other FlexGroup relationship.
-
FlexGroup file restore operations have the same restrictions as regular FlexGroup restore operations.
-
All nodes in the cluster where the B and C FlexGroup volumes reside must be running ONTAP 9.9.1 or later.
-
All expand and auto expand functionality is supported.
-
In a cascade configuration such as A to B to C, if A to B and B to C have different numbers of constituent SnapMirror relationships, then an abort operation from the source is not supported for the B to C SnapMirror relationship.
-
System Manager does not support cascading relationships regardless of the ONTAP version.
-
When converting an A to B to C set of FlexVol relationship to a FlexGroup relationship, you must convert the B to C hop first.
-
All FlexGroup cascade configurations for relationships with policy types supported by REST are also supported by REST APIs in cascading FlexGroup configurations.
-
As with FlexVol relationships, FlexGroup cascading is not supported by the
snapmirror protect
command.
Considerations for creating fanout relationships
-
Two or more FlexGroup fanout relationships are supported; for example, A to B, A to C, with a maximum of 8 fanout legs.
-
Each relationship can be either intercluster or intracluster.
-
Concurrent updates are supported for the two relationships.
-
All expand and auto expand functionality is supported.
-
If the fanout legs of the relationship have different numbers of constituent SnapMirror relationships, then an abort operation from the source is not supported for the A to B and A to C relationships.
-
All nodes in the cluster where the source and destination FlexGroups reside must be running ONTAP 9.9.1 or later.
-
All asynchronous policy types currently supported for FlexGroup SnapMirror are supported in fanout relationships.
-
You can perform restore operations from B to C FlexGroups.
-
All fanout configurations with policy types supported by rest are also supported for REST APIs in FlexGroup fanout configurations.