[ClusterLabs] Notification agent and Notification recipients

[Sriram]

Thanks Ken, Jan. Will look into the clone notifications.

Regards,
Sriram.

On Sat, Aug 5, 2017 at 1:25 AM, Ken Gaillot <kgaillot at redhat.com> wrote:

> On Thu, 2017-08-03 at 12:31 +0530, Sriram wrote:
> >
> > Hi Team,
> >
> >
> > We have a four node cluster (1 active : 3 standby) in our lab for a
> > particular service. If the active node goes down, one of the three
> > standby node  becomes active. Now there will be (1 active :  2
> > standby : 1 offline).
> >
> >
> > Is there any way where this newly elected node sends notification to
> > the remaining 2 standby nodes about its new status ?
>
> Hi Sriram,
>
> This depends on how your service is configured in the cluster.
>
> If you have a clone or master/slave resource, then clone notifications
> is probably what you want (not alerts, which is the path you were going
> down -- alerts are designed to e.g. email a system administrator after
> an important event).
>
> For details about clone notifications, see:
>
> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-
> single/Pacemaker_Explained/index.html#_clone_resource_agent_requirements
>
> The RA must support the "notify" action, which will be called when a
> clone instance is started or stopped. See the similar section later for
> master/slave resources for additional information. See the mysql or
> pgsql resource agents for examples of notify implementations.
>
> > I was exploring "notification agent" and "notification recipient"
> > features, but that doesn't seem to work. /etc/sysconfig/notify.sh
> > doesn't get invoked even in the newly elected active node.
>
> Yep, that's something different altogether -- it's only enabled on RHEL
> systems, and solely for backward compatibility with an early
> implementation of the alerts interface. The new alerts interface is more
> flexible, but it's not designed to send information between cluster
> nodes -- it's designed to send information to something external to the
> cluster, such as a human, or an SNMP server, or a monitoring system.
>
>
> > Cluster Properties:
> >  cluster-infrastructure: corosync
> >  dc-version: 1.1.17-e2e6cdce80
> >  default-action-timeout: 240
> >  have-watchdog: false
> >  no-quorum-policy: ignore
> >  notification-agent: /etc/sysconfig/notify.sh
> >  notification-recipient: /var/log/notify.log
> >  placement-strategy: balanced
> >  stonith-enabled: false
> >  symmetric-cluster: false
> >
> >
> >
> >
> > I m using the following versions of pacemaker and corosync.
> >
> >
> > /usr/sbin # ./pacemakerd --version
> > Pacemaker 1.1.17
> > Written by Andrew Beekhof
> > /usr/sbin # ./corosync -v
> > Corosync Cluster Engine, version '2.3.5'
> > Copyright (c) 2006-2009 Red Hat, Inc.
> >
> >
> > Can you please suggest if I m doing anything wrong or if there any
> > other mechanisms to achieve this ?
> >
> >
> > Regards,
> > Sriram.
> >
> >
> > _______________________________________________
> > Users mailing list: Users at clusterlabs.org
> > http://lists.clusterlabs.org/mailman/listinfo/users
> >
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> > Bugs: http://bugs.clusterlabs.org
>
> --
> Ken Gaillot <kgaillot at redhat.com>
>
>
>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20170807/e5409076/attachment-0003.html>