How can I avoid having to create a stonith device for each node in a cluster where the "port" (-n) values do not match the node names in RHEL 6 or 7 with pacemaker?

Solution Unverified - Updated

Environment

  • Red Hat Enterprise Linux (RHEL) 6 or 7 with the High Availability Add on
  • Pacemaker
  • All nodes utilize a single shared stonith/fence device, but the node names do not match the values that must be passed to -n or what is listed in -o list output to/from the stonith agent
    • This is often applicable in virtualized environments where the hostname is used as the node name, but the VM name on the host is different

Issue

  • Is there a way to not have to create a stonith device for every node just because the names listed in -o list output don't match the node names?
  • How can I tell stonith to map nodenames to different names before passing them to a fence agent?
  • My pacemaker nodes are virtualized guests, and my stonith device won't work because stonith passes the nodename as the -n (port) value and it needs to pass the VM's name which is different

Resolution

Create a single stonith device with a pcmk_host_map to map node name:port name.

# pcs stonith create <stonith id> <stonith device type> pcmk_host_map="<node name>:<port name>" [stonith device options]

For example:

# pcs stonith create vmfence fence_vmware_soap pcmk_host_map="node1.example.com:vm-node1;node2.example.com:vm-node2"  ipaddr=10.10.10.10 ssl=1 login=root passwd=redhat

In this example, the node names are node1.example.com and node2.example.com, but the values that must be passed to the agent's -n option are vm-node1 and vm-node2.

If the shared stonith device has already been created, then a host map can still be added:

# pcs stonith update vmfence pcmk_host_map="node1.example.com:vm-node1;node2.example.com:vm-node2"

Root Cause

  • pacemaker's stonith-ng has the ability to take a single shared device which is not configured with any specific per-node values and use it to fence a node by simply passing the node name as the -n value to the agent. When starting this resource, stonith-ng will probe the device for each node to see which nodes are capable of fencing which others. This however creates a problem when the node name is not the same as the value that would need to be passed to the agent and therefore a map is needed.

  • This is common in virtualized environments where the virtualization host has a name for the VM, and the VM itself has the cluster configured with a node name that does not match. In other words, the node might be configured with a node name of node1.example.com (its hostname), whereas the virtualization interface and the fence agent's -o list output may show "vmnode1". stonith-ng would try to execute the agent as fence_agent -o status -n node1.example.com, when it needs to specify fence_agent -o status -n vmnode1.

  • This is where pcmk_host_map comes in use; you can tell stonith-ng that for this device, map each node to a different name. This allows it to use a single device, and automatically figure out which nodes should fence which others.

SBR
Product(s)
Components
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.