[Pacemaker] Reloading a resource after a failover
Max Williams
Max.Williams at betfair.com
Thu Nov 10 16:30:00 CET 2011
Sorry to bump an old thread but I just thought I'd post an update as to how I solved this issue with Pacemaker. I bit of a work-around but it does work....
I configured a "ocf:heartbeat:anything" resource that runs "rndc reload", like this:
primitive rndc_reload ocf:heartbeat:anything params binfile="/usr/sbin/rndc" cmdline_options="reload"
Then grouped this resource with the VIP so that it would run "rndc reload" after starting the VIP:
group VIP_rndc Cluster_IP rndc_reload meta target-role="Started"
Now after the VIP moves or fails over named will get reloaded so it will listen on the VIP interface. Result.
There is one minor issue and that is when pacemaker tries to stop rndc_reload resource it fails as the process does not stay running. It logs the failure but this doesn't seem to make any difference and there are no errors in crm_mon.
Cheers,
Max
From: Max Williams [mailto:Max.Williams at betfair.com]
Sent: 29 September 2011 10:04
To: The Pacemaker cluster resource manager
Subject: Re: [Pacemaker] Reloading a resource after a failover
Yes this is what I would like to do. Ideally have named as a clone and then have an order like this:
crm(live)configure# order named-service-clone-after-Cluster_IP inf: Cluster_IP:start Named_Service:reload
But it gives this error:
ERROR: bad resource action/instance definition: Named_Service:reload
Is there a way to achieve this?
Can I edit an RA file so that it takes reload as a action? If so, which file?
Or configure pacemaker to run an external command when a resource fails over or moves?
Many thanks,
Max
From: Serge Dubrouski [mailto:sergeyfd at gmail.com]
Sent: 28 September 2011 18:17
To: The Pacemaker cluster resource manager
Subject: Re: [Pacemaker] Reloading a resource after a failover
Put bind itself under pacemaker control. You can use LSB RA or OCF RA that I recently created.
On Sep 28, 2011 10:46 AM, "Max Williams" <Max.Williams at betfair.com<mailto:Max.Williams at betfair.com>> wrote:
> Hi,
> I have a pair of clustered DNS servers with a virtual IP (VIP) configured. The problem is that when the VIP fails over, named on the new host of the VIP will not listen on port 53/UDP of the VIP until it is reloaded (I think this is because this daemon uses UDP, not TCP).
>
> So I'd like to be able to reload named after a failover of the VIP address. Is this possible?
>
> I could do it by configuring named as a cloned resource and then configuring an order so that it is restarted when the VIP fails over or moves but I would much rather have named reload instead of restart.
>
> Any ideas? I'd rather not have to resort to a wrapper script or anything like that.
>
> Thanks,
> Max
>
> ________________________________________________________________________
> In order to protect our email recipients, Betfair Group use SkyScan from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
>
> ________________________________________________________________________
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org<mailto:Pacemaker at oss.clusterlabs.org>
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.clusterlabs.org/pipermail/pacemaker/attachments/20111110/cac67a45/attachment.html>
More information about the Pacemaker
mailing list