[Pacemaker] Query regarding "crm node standby/online" command

[neha chatrath]

Hello,

Thanks for the reply. Let me rephrase my query regarding interface
monitoring.
I have (say 3 IP interfaces) eth0, eth1, eth2.
Heartbeat is running on eth0.
I can monitor my eth0 link using Heartbeat but is there a possibility of
monitoring eth1 and eth2 interfaces as well using Heartbeat mechanism?
I need this to detect scenarios like if eth0 is working fine (thus, no
break in cluster communication via Heartbeat) but there is some issue with
either eth1 or eth2, I need to raise some alarms etc

Thanks and regards
Neha Chatrath

Message: 4
Date: Tue, 08 Nov 2011 09:45:17 +0100
From: Florian Haas <florian at hastexo.com>
To: The Pacemaker cluster resource manager
       <pacemaker at oss.clusterlabs.org
>
Subject: Re: [Pacemaker] Query regarding "crm node standby/online"
       command
Message-ID: <4EB8EC1D.8050209 at hastexo.com>
Content-Type: text/plain; charset=ISO-8859-1

On 2011-11-08 06:22, neha chatrath wrote:
> Hello,
>
> I am running Heartbeat and Pacemaker in a cluster with 2 nodes.
> I also have a client registered with Heartbeat daemon for any node/IF
> status changes.

Can you give more details as to the nature of that client?

> When I execute "crm node standby" command on one of the nodes, there is
> no node status change info reported to the client.
> Is this the expected behavior?

I would say yes, as putting a node in standby mode does not change its
status of being a fully-fledged member of the cluster. It still
participates in all cluster communications, it receives all
configuration changes and status updates. It's merely ineligible for
running any resources. So from the cluster communications layer point of
view (i.e. from Heartbeat's or Corosync's perspective) nothing changes.

> Also, one more query about Heartbeat daemon:
> In my system, I have multiple IP interfaces (each configured with a
> separate IP) with Heartbeat running on one of them.
> I have a requirement of monitoring of all these IP interfaces and
> perform necessary actions (like perform failover etc) in case of any
> interface failure.

Well there is no reason to do this externally. You set up fencing using
an out-of-band fencing method. When cluster communications break down,
you fence one node off the cluster, so resources fail over to the other.

As a word of caution, it seems like you're at least headed into the
direction of reinventing the wheel, and it also seems like you are
trying to implement functionality that's already present in the stack.
(This is just a hunch based on the limited information given, however.)
If that is the case, I would strongly suggest you take a look at
Clusters From Scratch and the Linux-HA User's Guide, and possibly also
Pacemaker: Configuration Explained, to better familiarize yourself with
the functionality of the stack.

Hope this helps.
Cheers,
Florian


On Tue, Nov 8, 2011 at 10:52 AM, neha chatrath <nehachatrath at gmail.com>wrote:

> Hello,
>
> I am running Heartbeat and Pacemaker in a cluster with 2 nodes.
> I also have a client registered with Heartbeat daemon for any node/IF
> status changes.
>
> When I execute "crm node standby" command on one of the nodes, there is no
> node status change info reported to the client.
> Is this the expected behavior?
>
> Also, one more query about Heartbeat daemon:
> In my system, I have multiple IP interfaces (each configured with a
> separate IP) with Heartbeat running on one of them.
> I have a requirement of monitoring of all these IP interfaces and perform
> necessary actions (like perform failover etc) in case of any interface
> failure.
> I am able to monitor the interface on which Heartbeat is running but not
> the rest of them.
> Does Heartbeat allows monitoring of interfaces other than the interfaces
> on which Heartbeat is running?
>
> Thanks and regards
> Neha Chatrath
>
>



-- 
Cheers
Neha Chatrath
                          KEEP SMILING!!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.clusterlabs.org/pipermail/pacemaker/attachments/20111115/e7f3c665/attachment.html>