Why are "sms.fanout.comm.snap.deleted" alerts being generated?
Applies to
- ONTAP 9.7 and later
- SnapMirror Synchronous (SM-S) and SnapMirror asynchronous fan-out configuration such as this:
Answer
- A fan-out configuration with SnapMirror Synchronous (SM-S) and SnapMirror asynchronous relationships might log the following alert on the SnapMirror source:
Wed Jan 06 03:05:00 +0000 [ClusterA-01: rpl_worker_main: sms.fanout.comm.snap.deleted:alert]: SnapMirror Synchronous operation 'Update' for relationship '123456ab-1234-1234-abcd-0123456789ab' has cleaned up some of the old base Snapshot copies between the synchronous source and synchronous destination, which could result in no common Snapshot copy existing between the synchronous and asynchronous destinations.
- This alert is generated when ONTAP detects that SnapMirror in-common Snapshots created by the SM-S relationship are not being replicated by the fan-out asynchronous relationship
- If a disaster recovery scenario were to occur for the SM-S relationship, the asynchronous destination would not have in-common Snapshots with the SM-S destination, leading to "no common Snapshot" errors when attempting to establish the asynchronous relationship from the original SM-S destination
Avoiding the alert
- Review TR-4832: Three-Data-Center Disaster Recovery Using NetApp SnapMirror for ONTAP 9.7 for best practices for the fan-out topology
- Use the MirrorAllSnapshots SnapMirror policy for the asynchronous relationship. This will ensure SnapMirror common Snapshots created by the SM-S relationship will always be replicated to the asynchronous destination
- Ensure the asynchronous relationship update schedule is at least as often as the common Snapshot creation schedule for the SM-S (default hourly)