Am Mittwoch, 18. August 2010 schrieb Dejan Muhamedagic: > Hi, Hi Dejan,
> On Wed, Aug 18, 2010 at 04:41:32PM +0200, Martin Steigerwald wrote:
> > Hi,
> >
> > I have a working fencing setup with heartbeat-1:
> >
> > somehost1:~# grep ^stonith /etc/ha.d/ha.cf
> > stonith_host * cyclades 172.21.101.79 root
> > 10
> >
> > So thats a cyclades stonith plugin, the IP adress of the
> > Cyclades Alterpath, login name for SSH login, and the serial
> > port of the IPDU that should powercycle the node to be fenced.
> >
> > Now when I want to configure a stonith plugin in
> > corosync/pacemaker, I can't set the serial port.
> >
> > There is simply no such parameter in that resource agent shown
>
> > in pacemaker:
> It turns out that the cyclades stonith plugin is missing the
> serialport parameter in the meta-data. The crm shell normally
> won't allow you to set parameters which are not mentioned in the
> meta-data, but you can relax the checks at the options level
> (see the check-* options, can't recall the name right now).
It appears to be
crm(live)# options check-mode relaxed
At least it seems to accept the serialport now - despite the error message:
crm(live)configure# primitive fencing stonith:cyclades params
ipaddr="172.21.101.79" login="root" serialport="10" op monitor interval="15s"
timeout="60s"
ERROR: fencing: parameter serialport does not exist
WARNING: fencing: default timeout 20s for start is smaller than the advised 60
crm(live)configure# clone cloneFencing fencing
crm(live)configure# property stonith-enabled="true"
crm(live)configure# show
node node1
node node2
primitive fencing stonith:cyclades \
params ipaddr="172.21.101.79" login="root" serialport="10" \
op monitor interval="15s" timeout="60s"
primitive resLdir ocf:heartbeat:ldirectord \
params configfile="/etc/ldirectord.cf" target_role="started" \
op monitor interval="30s" timeout="10s" on_fail="restart"
primitive resLoadbalancerIP ocf:heartbeat:IPaddr2 \
params ip="172.21.101.82" nic="eth2" cidr_netmask="16"
clone cloneFencing fencing
clone cloneLdir resLdir \
meta target-role="Started"
property $id="cib-bootstrap-options" \
dc-version="1.0.9-unknown" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
no-quorum-policy="ignore" \
stonith-enabled="true"
crm(live)configure# commit
WARNING: CIB changed in the meantime: won't touch it!
Do you still want to commit? y
But still a STONITH does not work. I trigger ist on node2 by killall -9
corosync and get this in the log of node1 which wants to fence node 2 - node 2
obviously has nothing in the logs:
Aug 23 11:55:29 node1 corosync[6552]: [TOTEM ] A processor failed, forming
new configuration.
Aug 23 11:55:35 node1 corosync[6552]: [pcmk ] notice: pcmk_peer_update:
Transitional membership event on ring 108: memb=1, new=0, lost=1
Aug 23 11:55:35 node1 corosync[6552]: [pcmk ] info: pcmk_peer_update: memb:
node1 28223680
Aug 23 11:55:35 node1 corosync[6552]: [pcmk ] info: pcmk_peer_update: lost:
node2 45000896
Aug 23 11:55:35 node1 corosync[6552]: [pcmk ] notice: pcmk_peer_update:
Stable membership event on ring 108: memb=1, new=0, lost=0
Aug 23 11:55:35 node1 corosync[6552]: [pcmk ] info: pcmk_peer_update: MEMB:
node1 28223680
Aug 23 11:55:35 node1 corosync[6552]: [pcmk ] info:
ais_mark_unseen_peer_dead: Node node2 was not seen in the previous transition
Aug 23 11:55:35 node1 corosync[6552]: [pcmk ] info: update_member: Node
45000896/node2 is now: lost
Aug 23 11:55:35 node1 corosync[6552]: [pcmk ] info:
send_member_notification: Sending membership update 108 to 2 children
Aug 23 11:55:35 node1 corosync[6552]: [TOTEM ] A processor joined or left
the membership and a new membership was formed.
Aug 23 11:55:35 node1 corosync[6552]: [MAIN ] Completed service
synchronization, ready to provide service.
Aug 23 11:55:35 node1 cib: [6560]: notice: ais_dispatch: Membership 108:
quorum lost
Aug 23 11:55:35 node1 cib: [6560]: info: crm_update_peer: Node node2:
id=45000896 state=lost (new) addr=r(0) ip(192.168.174.2) votes=1 born=104
seen
=104 proc=00000000000000000000000000013312
Aug 23 11:55:35 node1 cib: [6560]: info: cib_process_request: Operation
complete: op cib_modify for section nodes (origin=local/crmd/274, version=0.
56.14): ok (rc=0)
Aug 23 11:55:35 node1 cib: [6560]: info: log_data_element: cib:diff: - <cib
have-quorum="1" admin_epoch="0" epoch="56" num_updates="15" />
Aug 23 11:55:35 node1 cib: [6560]: info: log_data_element: cib:diff: + <cib
have-quorum="0" admin_epoch="0" epoch="57" num_updates="1" />
Aug 23 11:55:35 node1 pengine: [6563]: notice: unpack_config: On loss of CCM
Quorum: Ignore
Aug 23 11:55:35 node1 pengine: [6563]: info: unpack_config: Node scores: 'red'
= -INFINITY, 'yellow' = 0, 'green' = 0
Aug 23 11:55:35 node1 pengine: [6563]: WARN: pe_fence_node: Node node2 will be
fenced because it is un-expectedly down
Aug 23 11:55:35 node1 pengine: [6563]: info: determine_online_status_fencing:
ha_state=active, ccm_state=false, crm_state=online, join_state=memb
er, expected=member
Aug 23 11:55:35 node1 pengine: [6563]: WARN: determine_online_status: Node
node2 is unclean
Aug 23 11:55:35 node1 crmd: [6564]: notice: ais_dispatch: Membership 108:
quorum lost
Aug 23 11:55:35 node1 crmd: [6564]: info: ais_status_callback: status: node2
is now lost (was member)
Aug 23 11:55:35 node1 crmd: [6564]: info: crm_update_peer: Node node2:
id=45000896 state=lost (new) addr=r(0) ip(192.168.174.2) votes=1 born=104 see
n=104 proc=00000000000000000000000000013312
Aug 23 11:55:35 node1 crmd: [6564]: info: erase_node_from_join: Removed node
node2 from join calculations: welcomed=0 itegrated=0 finalized=0 confirm
ed=1
Aug 23 11:55:35 node1 crmd: [6564]: info: crm_update_quorum: Updating quorum
status to false (call=276)
Aug 23 11:55:35 node1 cib: [6560]: info: cib_process_request: Operation
complete: op cib_modify for section cib (origin=local/crmd/276, version=0.57
.1): ok (rc=0)
Aug 23 11:55:35 node1 cib: [6560]: info: cib_process_request: Operation
complete: op cib_modify for section crm_config (origin=local/crmd/278, versi
on=0.57.1): ok (rc=0)
Aug 23 11:55:35 node1 pengine: [6563]: notice: unpack_rsc_op: Operation
resLdir:0_monitor_0 found resource resLdir:0 active on node2
Aug 23 11:55:35 node1 pengine: [6563]: info: determine_online_status: Node
node1 is online
Aug 23 11:55:35 node1 pengine: [6563]: notice: unpack_rsc_op: Operation
resLdir:1_monitor_0 found resource resLdir:1 active on node1
Aug 23 11:55:35 node1 pengine: [6563]: info: find_clone: Internally renamed
fencing:0 on node1 to fencing:1
Aug 23 11:55:35 node1 pengine: [6563]: WARN: unpack_rsc_op: Processing failed
op fencing:0_start_0 on node1: unknown error (1)
Aug 23 11:55:35 node1 crmd: [6564]: info: crm_ais_dispatch: Setting expected
votes to 2
Aug 23 11:55:35 node1 crmd: [6564]: WARN: match_down_event: No match for
shutdown action on node2
Aug 23 11:55:35 node1 crmd: [6564]: info: te_update_diff: Stonith/shutdown of
node2 not matched
Aug 23 11:55:35 node1 crmd: [6564]: info: abort_transition_graph:
te_update_diff:191 - Triggered transition abort (complete=1, tag=node_state,
id=node2, magic=NA, cib=0.56.15) : Node failure
Aug 23 11:55:35 node1 crmd: [6564]: info: abort_transition_graph:
need_abort:59 - Triggered transition abort (complete=1) : Non-status change
node1 seems to initiate the fencing, but then it fails with:
Aug 23 11:55:35 node1 pengine: [6563]: WARN: unpack_rsc_op: Processing failed
op fencing:0_start_0 on node1: unknown error (1)
Aug 23 11:55:35 node1 crmd: [6564]: info: crm_ais_dispatch: Setting expected
votes to 2
Aug 23 11:55:35 node1 crmd: [6564]: WARN: match_down_event: No match for
shutdown action on node2
Aug 23 11:55:35 node1 crmd: [6564]: info: te_update_diff: Stonith/shutdown of
node2 not matched
I cannot make much out of the "unknown error". I also do not understand the
"No match for shutdown action on node2". The CIB on node2 is in sync with the
one of node1.
Configuration seems to validate:
node1:~# crm_verify --live-check
node1:~#
Any hints?
Should I file a bug report?
> The meta-data has been fixed now.
Thanks,
--
Martin Steigerwald - team(ix) GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
