[Pacemaker] CLUSTERIP/iptables interaction

[Michael Schwartzkopff]

Am Montag, 14. Dezember 2009 15:53:25 schrieb Tim Serong:
> On 12/15/2009 at 01:03 AM, Michael Schwartzkopff <misch at multinet.de> wrote:
> > Am Montag, 14. Dezember 2009 13:00:34 schrieb Chris Picton:
> > > Hi all
> > >
> > > I am doing some tests with clusterip and pacemaker/heartbeat on Centos
> > > 5.4, using the clusterlabs repo
> > >
> > > My resource looks like:
> > > primitive CLUSTERIP_21 ocf:heartbeat:IPaddr2 \
> > > 	op monitor interval="10" timeout="20" start-delay="0" \
> > > 	params ip="10.202.4.21" nic="eth0" cidr_netmask="24"
> > > clusterip_hash="sourceip-sourceport" \
> > > 	meta resource-stickiness="0"
> > > clone clone_CLUSTERIP_21 CLUSTERIP_21 \
> > > 	meta clone-max="2" globally-unique="true" clone-node-max="2"
> > >
> > >
> > > This start up fine, and adds an iptables rule correctly, however, if I
> > > restart the iptables service the clusterip rule gets removed.
> >
> > Of course. The rule is inserted and managed by the cluster dynamically.
> >
> > > I then get the below errors in my log file.  These continue without
> > > stopping.
> > >
> > > It seems that the ipaddr2 script is not currently capable of recreating
> > > the iptables rule if it get inadvertently removed.
> > >
> > > It this known behaviour?  If not, where does my error lie?
> >
> > I did not verify this behaviour but it sounds reasonable. Perhaps
> > recreating
> >
> > the iptables rule after the loss could/should be part of the monitoring
> > of the
> > IPaddr2 script.
> >
> >
> > Looking through your logs it seems monitor detect the problem but cannot
> > recreate the correct rule. Perhaps an error in the RA.
>
> The monitor op shouldn't make any changes.  If the rule has gone away,
> the monitor op should return failure to indicate the resource is broken,
> which will result in Pacemaker telling the the failed resource to stop, and
> start again.  Actually, from the logs it looks like a restart was
> attempted, and the stop op reported success, but the subsequent start
> failed for some reason.
>
> Regards,
>
> Tim

Exactly. So the RA seems to have a problem handeling this error scenario 
correctly.

Greetings,
-- 
Dr. Michael Schwartzkopff
MultiNET Services GmbH
Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany
Tel: +49 - 89 - 45 69 11 0
Fax: +49 - 89 - 45 69 11 21
mob: +49 - 174 - 343 28 75

mail: misch at multinet.de
web: www.multinet.de

Sitz der Gesellschaft: 85630 Grasbrunn
Registergericht: Amtsgericht München HRB 114375
Geschäftsführer: Günter Jurgeneit, Hubert Martens

---

PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B
Skype: misch42