Any suggestion if Notifier resource goes offline

If Notifier is clustered it can be managed like any other resource.

When faulted, it will failover to other node.

You can increase RestartLimit. Will restart rather than failing over.

I have honestly never seen notifier failing and cannot think of any reason why it would...

Thanks for your kind input. This is the same answer I expected on CONNECT :) hmmm, So there is no other way to think about

the 'HAD' will store upto 30 notifications by default. we can increase it. These 30 notifications are maintain as circular FIFO list.  Once notifier reads it from 'HAD', the entry is deleted. 

One can use the triggers to send trap/email directly instead of using the notifier; however it can provide you information only in the events the triggers are invoked. There are generally some more instances when useful notifications are sent.

Recommendation: Use the notifier with clustered configuration. Normally it is part of 'ClusterService' service group which gets special preference within VCS in terms of the failover etc. Increase the notification limits if required. 

Thanks to all of you. Suppose if Notifier resource goes down and Application Service Group is working fine, in that situation Client dont want to get bother and open the Java Console(after some time interval) to verify that really the Notifier resource is online or not.

What I feel that we can use trap/SNMP parallel with notifier resource.

Suppose if Notifier resource goes down....

1.  Cluster Notifier resource (add to ClusterService sg)
2.  Increase RestartLimit

So, suppose Notifier goes down:

1. It will restart on the active node
2. If restart fails, it will failover

SNMP is part of Notifier resource. See NotifierMngr agent in Bundled Agent Guide.

You trust VCS with your Critical Application. Why not trust VCS to look after Notifier?

Suppose if Notifier resource goes down and Application Service Group is working fine, in that situation Client dont want to get bother and open the Java Console(after some time interval) to verify that really the Notifier resource is online or not.

I agree with Marianne that "You trust VCS with your Critical Application. Why not trust VCS to look after Notifier?", but one problem I find with the notifier resource is that it does not tell you when ANY service group comes back up, unless I think you select severity "INFO", so if you have WARNING or ERROR, then you get a notification to tell you service group is down, but not that it is back up (this was the case in 5.0, not sure if this has changed).  Now if the service group doesn't come back up, then you should get an error message saying "service group has nowhere to fail", but you have to wait until all timeouts and restarts are exhausted before you get this, so I would rather know as soon as service is back online, rather than wait 10 - 15 mins and think, I have no more notifications, so service must be back online by now!  

Also some customers want to know where it has failed to, so a message saying "Service X is back up on system Y" would be useful and this is where you can use triggers in conjunction with notifier to tell you this and help you with your particular concern.

To do this use the PreOnline trigger which is passed the reason why it is being called, so I generally code:

IF reason is FAULT, then send email saying something like "Service group X is back up on system Y"

Only having message sent if reason is FAULT means you won't get messages when onlining the service group manually.

You can also use resfault trigger to send an email when a resource faults.

So using these triggers you will have an independent mechanism to tell you when resources (such as Notifier resource), fault and come back online.

Mike

The matter is not of trust. We do trust thats why we are selling it and not other solution :) .. The matter is as I mentioned that for the lack of watching cluster SG , the offline of SG may cause ignoring of Application SG faults and as far as the Application SG, we can feel that another SG already monitoring the behaviour of our App SG.

Thanks all for their kind replies

Triggers will definately sort your issue of knowing if Application service group faults while Notifier resource is down - so is this what you are looking for and if not, what are you expecting to happen?

As Amit says, you can't use triggers for all notifications, as there are other issues like loss of heartbeats, "resource in admin wait", concurrency violations where there are some other triggers for most of these events, but not all, but at least resfault and preonline trigger will tell you notifier is down so that you can rectify this before you get any issues for which there aren't triggers for.

Mike

reading through - i am lost in understanding the concern?

is the concern that notifier resource faults? or while it is faulted, the fault of other resource is not reported?

The notifier resource is normally configured under ClusterService sg, hence gets more preference. 

The fault of other resources in the mean time are captured in the circular queue and whenever notifier comes back, it reports these fault. It also includes the fault of notifier resource itself. 

I am not able to understand the concern with respect to Application SG and notifier resource.