In this NetApp tutorial, you’ll learn about SnapMirror Engine fan in, fan out, and cascades. Scroll down for the video and also text tutorial.
NetApp SnapMirror Fan In, Fan Out, and Cascades Video Tutorial
Marnix van der Erve
I took your course and it helped me a lot in troubleshooting some major issues with a NetApp MetroCluster. It developed my understanding of storage technologies. I designed a new solution and migrated to the new environment to stabilize and consolidate.
With fan in, you can replicate multiple source volumes from the same or different SVMs into multiple different destination volumes on the same SVM. That is fan in to the same SVM.
However, you cannot replicate multiple source volumes into the same destination volumes. You can't fan multiple volumes into the same destination volume.
Let's have a look at what exactly that means with a diagram. We've got a volume in an SVM called SVM2 and another volume in a different SVM called SVM3. We are replicating those volumes at two different volumes in SVM1.
SVM2 and SVM3 could be in the same or in different clusters. That will work just fine. The next one we could do is to have two different volumes in SVM2 being replicated in two different volumes in SVM1.
You cannot, however, replicate multiple different sources into the same destination volume. In our example, we've got two different sources and we can't replicate it in the same destination.
You can fan out to up to eight destination volumes from a single source volume for data protection on SnapVault mirror relationships. A source volume can have a maximum of one load sharing mirror copy per node in its cluster. You would never want to have more than one copy per node anyway, so that's really not a limitation.
A source volume can have both one load sharing destination volume on each node and its cluster and multiple data protection and SnapVault destination volumes.
Load sharing mirror copies are always replicated as a group going from the same source volume. When you've got load sharing mirrors configured, normally that will be to a load sharing mirror destination volume on each node in the cluster.
The replication schedule is the same for all of those destinations. Whenever you've got a load shedding mirror for a source, it replicates out to all its destinations at the same time. However, each data protection and SnapVault destination is configured independently and they can have different schedules.
I could have, for example, Volume 1 in SVM1. I could replicate that to one cluster where I'm replicating every 10 minutes. I could replicate it to a different destination cluster where I'm replicating every hour.
Looking at some examples of fan out, the first one here, we've got the same source volume and we are replicating it to a destination volume. We're also replicating it to a different destination volume. You could do this to get additional redundancy. It could be that this top cluster is in one location and the bottom cluster is in a different location.
You could also have that different replication schedule for both of those replications. So, that was two different SnapMirrors going out. You can have up to eight different fan-out replications. For the same source volume, you could replicate it out to eight different destination volumes.
The top example we have is SnapMirror. In the bottom example, we're using SnapMirror to a destination volume. That would be in one cluster. The SnapVault would be going out to a different cluster.
If you want it to do SnapMirror and SnapVault out to the same cluster, it would be better to do that to the same destination volume and use unified replication there. That would give you space savings and also cut down on the amount of bandwidth required.
If you do want to replicate out to different destinations and if you've got one site that is used for disaster recovery and another site that is used for backup, that will work just fine as well.
When you do fan out, only one relationship in a fan out configuration can be a SnapMirror Synchronous relationship. You could replicate out to one destination synchronously. You could still replicate out to up to another seven other destination volumes but those would be asynchronous relationships.
In our example below, we're replicating to our destination volume from our source volume. Then from that destination volume, we're replicating out to another destination volume.
The reason you would want to do this would be for additional redundancy. Rather than having one backup copy, we've got two different backup copies there. Another reason to do this would be if you're doing SnapMirror to multiple different sites to get the read-only load balancing there. You could do that with fan out and you could also do it with a cascade.
The supported different possible cascade combinations are:
- SnapMirror to SnapMirror
- SnapMirror to SnapVault
- SnapVault to SnapMirror
- SnapVault to SnapVault
SnapMirror Synchronous cascades are supported from ONTAP 9.6. When you do that, it's going to be synchronous from your primary to the secondary, and then asynchronous from the secondary to the tertiary.
Obviously, you wouldn't have a cascade where you had synchronous on one side and then synchronous on the other side. That would just not be possible because of the time delay there.
Fan-out and Cascade Data Protection Deployments: https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.pow-dap%2FGUID-2B4BA77A-8263-4686-9F5D-603D96F89878.html
Text by Libby Teofilo, Technical Writer at www.flackbox.com
With a mission to spread network awareness through writing, Libby consistently immerses herself into the unrelenting process of knowledge acquisition and dissemination. If not engrossed in technology, you might see her with a book in one hand and a coffee in the other.