Initialize the SBD device with the following command:

root # sbd -d /dev/SBD create

This will write a header to the device, and create slots for up to 255 nodes sharing this device with default timings.

If you want to use more than one device for SBD, provide the devices by specifying the -d option multiple times, for example:

root # sbd -d /dev/SBD1 -d /dev/SBD2 -d /dev/SBD3 create

If your SBD device resides on a multipath group, adjust the timeouts SBD uses. This can be specified when the SBD device is initialized (all timeouts are given in seconds):

root # /usr/sbin/sbd -d /dev/SBD -4 1801 -1 902 create

With the following command, check what has been written to the device:

root # sbd -d /dev/SBD dump 
Header version     : 2
Number of slots    : 255
Sector size        : 512
Timeout (watchdog) : 5
Timeout (allocate) : 2
Timeout (loop)     : 1
Timeout (msgwait)  : 10

Enable the SBD daemon to start at boot time with:

root # systemctl enable sbd.service

Run ha-cluster-init. This script ensure that SBD is correctly configured and the configuration file /etc/sysconfig/sbd is added to the list of files that needs to be synchronized with Csync2.

If you want to configure SBD manually, perform the following step:

To make the Corosync init script start and stop SBD, edit the file /etc/sysconfig/sbd and search for the following line, replacing SBD with your SBD device:

SBD_DEVICE="/dev/SBD"

If you need to specify multiple devices in the first line, separate them by a semicolon (the order of the devices does not matter):

SBD_DEVICE="/dev/SBD1; /dev/SBD2; /dev/SBD3"

If the SBD device is not accessible, the daemon will fail to start and inhibit Corosync startup.

Note

If the SBD device becomes inaccessible from a node, this could cause the node to enter an infinite reboot cycle. This is technically correct behavior, but depending on your administrative policies, most likely a nuisance. In such cases, better do not automatically start up Corosync and Pacemaker on boot.

Before proceeding, ensure that SBD has started on all nodes by executing systemctl restart pacemaker.service.

The following command will dump the node slots and their current messages from the SBD device:

root # sbd -d /dev/SBD list

Now you should see all cluster nodes that have ever been started with SBD listed here, the message slot should show clear.

Try sending a test message to one of the nodes:

root # sbd -d /dev/SBD message nodea test

The node will acknowledge the receipt of the message in the system logs:

Aug 29 14:10:00 nodea sbd: [13412]: info: Received command test from nodeb

This confirms that SBD is indeed up and running on the node and that it is ready to receive messages.

To complete the SBD setup, activate SBD as a STONITH/fencing mechanism in the CIB as follows:

root # crm configure
crm(live)configure# property stonith-enabled="true"
crm(live)configure# property stonith-timeout="40s"
crm(live)configure# primitive stonith_sbd stonith:external/sbd \
   op start interval="0" timeout="15" start-delay="10"
crm(live)configure# commit
crm(live)configure# quit

The resource does not need to be cloned, as it would shut down the respective node anyway if there was a problem.

Which value to set for stonith-timeout depends on the msgwait timeout. The msgwait timeout should be longer than the maximum allowed timeout for the underlying IO system. For example, this is 30 seconds for plain SCSI disks. Provided you set the msgwait timeout value to 30 seconds, setting stonith-timeout to 40 seconds is appropriate.

Since node slots are allocated automatically, no manual host list needs to be defined.

Disable any other fencing devices you might have configured before, since the SBD mechanism is used for this function now.

Log in as root and start a shell.

Create the configuration file /etc/sg_persist.conf:

sg_persist_resource_MDRAID1() {
      devs="/dev/sdd /dev/sde"
      required_devs_nof=2
}

Run the following commands to create the primitive resources sg_persist:

root # crm configure
crm(live)configure# primitive sg ocf:heartbeat:sg_persist \
    params config_file=/etc/sg_persist.conf \
           sg_persist_resource=MDRAID1 \
           reservation_type=1 \
    op monitor interval=60 timeout=60

Add the sg_persist primitive to a master-slave group:

crm(live)configure# ms ms-sg sg \
    meta master-max=1 notify=true

Set the master on the alice server and the slave on the bob node:

crm(live)configure# location ms-sg-alice-loc ms-sg inf: alice
crm(live)configure# location ms-sg-bob-loc ms-sg 100: bob

Do some tests. When the resource is in master/slave status, on the master server, you can mount and write on /dev/sdc1, while on the slave server you cannot write.

Add an OCFS2 primitive:

crm(live)configure# primitive ocfs2 ocf:heartbeat:Filesystem \
    params device="/dev/sdc1" directory="/mnt/ocfs2" fstype=ocfs2

Create a clone from a basegroup:

crm(live)configure# clone cl-group basegroup

Add relationship between ms-sg and cl-group:

crm(live)configure# colocation ocfs2-group-on-ms-sg inf: cl-group ms-sg:Master
crm(live)configure# order ms-sg-before-ocfs2-group inf: ms-sg:promote cl-group

Check all your changes with the edit command.

Commit your changes.