0

i have 2 virtual centos7 nodes , root can login passwordless among themself,

i have configured stonith like this but the services are not coming up, fencing is not happening , im new to this, could someone help me rectify issue~

[root@node1 cluster]# pcs stonith create nub1 fence_virt pcmk_host_list="node1"
[root@node1 cluster]# pcs stonith create nub2 fence_virt pcmk_host_list="node2"
[root@node1 cluster]# pcs stonith show
 nub1   (stonith:fence_virt):   Stopped
 nub2   (stonith:fence_virt):   Stopped
[root@node1 cluster]#
[root@node1 cluster]#
[root@node1 cluster]#
[root@node1 cluster]#
[root@node1 cluster]# pcs status
Cluster name: mycluster
Stack: corosync
Current DC: node2 (version 1.1.15-11.el7_3.5-e174ec8) - partition with quorum
Last updated: Tue Jul 25 07:03:37 2017          Last change: Tue Jul 25 07:02:00 2017 by root via cibadmin on node1

2 nodes and 3 resources configured

Online: [ node1 node2 ]

Full list of resources:

 ClusterIP      (ocf::heartbeat:IPaddr2):       Started node1
 nub1   (stonith:fence_virt):   Stopped
 nub2   (stonith:fence_virt):   Stopped

Failed Actions:
* nub1_start_0 on node1 'unknown error' (1): call=56, status=Error, exitreason='none',
    last-rc-change='Tue Jul 25 07:01:34 2017', queued=0ms, exec=7006ms
* nub2_start_0 on node1 'unknown error' (1): call=58, status=Error, exitreason='none',
    last-rc-change='Tue Jul 25 07:01:42 2017', queued=0ms, exec=7009ms
* nub1_start_0 on node2 'unknown error' (1): call=54, status=Error, exitreason='none',
    last-rc-change='Tue Jul 25 07:01:26 2017', queued=0ms, exec=7010ms
* nub2_start_0 on node2 'unknown error' (1): call=60, status=Error, exitreason='none',
    last-rc-change='Tue Jul 25 07:01:34 2017', queued=0ms, exec=7013ms


Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled





[root@node1 cluster]# pcs stonith fence node2
Error: unable to fence 'node2'
Command failed: No route to host

[root@node1 cluster]# pcs stonith fence nub2
Error: unable to fence 'nub2'
Command failed: No such device

[root@node1 cluster]# ping node2
PING node2 (192.168.100.102) 56(84) bytes of data.
64 bytes from node2 (192.168.100.102): icmp_seq=1 ttl=64 time=0.247 ms
64 bytes from node2 (192.168.100.102): icmp_seq=2 ttl=64 time=0.304 ms
^C
--- node2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.247/0.275/0.304/0.032 ms
Mohammed Ali
  • 671
  • 2
  • 14
  • 38

2 Answers2

0

Take a look at the information needed for your fence agent: # pcs resource describe fence_virt

Without seeing system logs, I'd guess you need to add the port= parameter to your STONITH device configurations. Those should be the machine names from the hypervisor's perspective.

If that's not the case: # grep fence_virt /var/log/messages should get you pointed in the right direction.

You'll also want to add location constraints to keep those devices running on the correct node; the device to fence nub1 should never run on nub1, and the device to fence nub2 should never run on nub2.

Matt Kereczman
  • 669
  • 3
  • 7
  • ah I resolved it with this! ```pcs stonith create iscsi-stonith-device fence_scsi pcmk_host_list="node1 node2" devices="/dev/disk/by-id/wwn-0x60014054e119057bacb487a85f9239cc" meta provides=unfencing``` – Mohammed Ali Aug 15 '17 at 13:37
  • That's a totally different fence agent, but whatever works for you I suppose. – Matt Kereczman Aug 15 '17 at 22:40
0

In order to use fence_virt, the physical host(s) that run your node VMs need to run fence_virtd that will respond to incoming fencing requests from fence_virt fencing agents.

The agents will communicate with the fence_virtd(s) over IP multicast, so you'll need to ensure IP multicast connectivity between your guests and host(s). The default multicast IP address is 225.0.0.12, and the port number is 1229.

See detailed instructions here: https://wiki.clusterlabs.org/wiki/Guest_Fencing

Note: the instructions talk about the port being TCP, but I don't think it is possible to use TCP over multicast, so it most likely is a misunderstanding and the multicast communication actually uses an UDP port, as is common with other multicast protocols.

telcoM
  • 87,318
  • 3
  • 112
  • 232