This Question is Not Answered

1 "correct" answer available (10 pts) 2 "helpful" answers available (5 pts)
78 Views 2 Replies Last post: Nov 17, 2009 3:14 PM by modugu RSS
modugu NetApp Employee Enthusiast 41 posts since
Jun 27, 2008
Currently Being Moderated

Nov 17, 2009 6:46 AM

sm.lag events

I am testing SnapMirror Lag Alerting ,

 

12382   2566 snapmirror:nearly-out-of-date  Warning    10 Nov 16:58
12401   2566 snapmirror:out-of-date         Error      10 Nov 17:58

 

I am using Snapmirror Replication Policy in Disaster Recovery ,

 

I was able to get these events working in protection manager ,with Mirror Policy Error/Warning Thresholds,

But see these working inconsistent ,with Replication Policy,

 

 

 

Do the alerts need to be more than the Replication time of the relationship ?

If these events trigger more than once or only Once and need to be ackowledge before another event for each relationship

 

I am testing on snapmirror relationship thats being replicated every hour

Attachments:
Tags: snapmirror, sm.lag
smoot NetApp Employee Master 89 posts since
Mar 19, 2008
Currently Being Moderated
Nov 17, 2009 9:43 AM in response to: modugu
Re: sm.lag events

Hi Modugu --

 

I think you've got two questions.

 

First, do the lag warning and error thresholds need to be longer than the replication frequency of your relationship?  In other words, if you are mirroring once a day, can you set the lag warning threshold at one hour?  No, the lag measures how much time has elapsed since the last replication started, so just before the next scheduled update, the lag will be about 24 hours.  You'd want to set the lag threshold at something like 25 to 30 hours, depending on how long an update takes.

 

Second, do you need to acknowledge the events.  No, these events automatically reset themselves when the lag changes state.  So, if you have a lag warning and the relationship gets updated (so the lag now becomes much shorter), a "Lag OK" event will trigger and that automatically replaces the lag warning event as the "current" event for that relationship.  Many DFM events work like this.

 

-- Pete

More Like This

  • Retrieving data ...

Bookmarked By (0)