[Pacemaker] Problem with ocf.pacemaker.pingd and host unreachable.
Pierre BLONDEAU
pierre.blondeau at unicaen.fr
Thu May 12 09:33:05 UTC 2011
Hi,
I want make a redundant iscsi server.
For this, i use drbd, lvm and iscsitarget on debian squeeze.
I have this configuration for pacemaker :
node leia \
attributes standby="off"
node luke \
attributes standby="off"
primitive drbd_data ocf:linbit:drbd \
operations $id="drbd_data-operations" \
op monitor interval="20" role="Slave" timeout="20" \
op monitor interval="10" role="Master" timeout="20" \
params drbd_resource="data"
primitive iscsi_c3po_disk ocf:heartbeat:iSCSILogicalUnit \
operations $id="iscsi_c3po_disk-operations" \
op monitor interval="10" timeout="10" \
params target_iqn="iqn.iscsi:c3po" lun="0"
path="/dev/data/c3po-disk" scsi_sn="c3po-disk"
additional_parameters="type=blockio"
primitive iscsi_c3po_target ocf:heartbeat:iSCSITarget \
operations $id="iscsi_c3po_target-operations" \
op monitor interval="10" timeout="10" \
params iqn="iqn.iscsi:c3po"
primitive lvm_data ocf:heartbeat:LVM \
operations $id="lvm_data-operations" \
op monitor interval="10" timeout="30" \
params volgrpname="data" \
meta target-role="started"
primitive ping_xen ocf:pacemaker:pingd \
operations $id="ping_xen-operations" \
op monitor interval="10" timeout="20" start-delay="1m" \
params host_list="192.168.7.4 192.168.7.5 192.168.7.6
192.168.7.7 192.168.7.8 192.168.7.9 192.168.7.10 192.168.7.11"
multiplier="1000" \
meta is-managed="true"
group iscsi_c3po_group iscsi_c3po_target iscsi_c3po_disk
ms drbd_data_master drbd_data \
meta master-max="2" target-role="started" notify="true"
interleave="true"
clone iscsi_c3po_clone iscsi_c3po_group \
meta interleave="true" target-role="Started"
clone lvm_data_clone lvm_data \
meta interleave="true" target-role="started"
clone ping_xen_clone ping_xen \
meta target-role="started" interleave="true"
location drbd_data_master-no-ping_xen drbd_data_master \
rule $id="drbd_data_master-no-ping_xen-rule" $role="Master"
-inf: not_defined pingd or pingd number:lte 0
colocation iscsi_c3po_clone-on-lvm_data_clone : lvm_data_clone
iscsi_c3po_clone
colocation lvm_data_clone-on-drbd_data_master : drbd_data_master:Master
lvm_data_clone
order drbd_data_master-before-lvm_data_clone : drbd_data_master
lvm_data_clone
order lvm_data_clone-before-iscsi_c3po_clone : lvm_data_clone
iscsi_c3po_clone
property $id="cib-bootstrap-options" \
dc-version="1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b" \
cluster-infrastructure="openais" \
expected-quorum-votes="3" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
last-lrm-refresh="1305127279"
op_defaults $id="op_defaults-options" \
record-pending="true"
I have three machine for the test plate-forme.
Each of them has two different networks on different interfaces.
The first is for global communication on 192.168.0.0/24 and the gateway
is 192.168.0.1
The second is for drbd, iscsi, and corosync communication on 192.168.7.0/24.
My two machines luke and leia are drbd primary / primary.
Mon problème est qu'en cas de coupure du liens drbd ( perte d'une carte
réseau, d'un switch, etc ... ), les deux machines passe en
"cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown", et en cas de
retour de ce liens, j'ai une corruption de données.
My problem is that in case of failure of links drbd (loss of a network
adapter, a switch, etc ...), tboth machines are in state "cs:
WFConnection ro: Primary / Unknown ds: UpToDate / DUnknown " and in case
of return of this relationship, I have a data corruption.
I add a test ping to disable drbd on the machine that has effectively
lost the links.
If I block pings on the third machine, the drbd is disabled and must
make a manual procedure to restore it (this is what I want).
But if I disable the interface 192.168.7.X on the machine, the ping
packets go in the direction of 192.168.0.1 on the other interface.
So I receive an "ICMP host unreachable 192.168.7.X" but my drbd does not
disable. If I made a firewall rule that prohibits the icmp packet
back, then turns off drbd.
I have an error in my configuration?
Thank you in advance for your answer!
Regards
Pierre BLONDEAU
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5255 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110512/02229aa9/attachment-0003.p7s>
More information about the Pacemaker
mailing list