次のコマンドで、SBDデバイスを初期化します。

root # sbd -d /dev/SBD create

これによって、デバイスにヘッダが書き込まれ、デフォルトのタイミングでこのデバイスを共有する最大255ノードのスロットが作成されます。

SBD用に複数のデバイスを使用する場合は、次のように、-dオプションを複数回指定することでデバイスを設定します。

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

SBDデバイスがマルチパスグループ上にある場合は、SBDが使用するタイムアウトを調整します。これは、SBDデバイスの初期化時に指定できます(すべてのタイムアウトは秒単位で指定)。

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

次のコマンドで、デバイスに何が書き込まれたか確認します。

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

ブート時のSBDデーモンの起動を有効にするには、次のコマンドを使用します。

root # systemctl enable sbd.service

ha-cluster-initを実行します。このスクリプトによりSBDが正しく設定され、設定ファイル/etc/sysconfig/sbdが、Csync2で同期される必要のあるファイルのリストに追加されます。

SBDを手動で設定する場合は、次の手順を実行します。

CorosyncのinitスクリプトでSBDを開始および停止するには、ファイル/etc/sysconfig/sbdを編集し、次の行を検索して、SBDをSBDデバイスで置き換えます。

SBD_DEVICE="/dev/SBD"

1行目で複数のデバイスを指定する必要がある場合は、セミコロンで区切って指定します(デバイスの順序は任意で構いません)。

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

SBDデバイスがアクセス不能な場合は、SBDデーモンが開始できなくなり、Corosyncの起動を抑止します。

注記: ブート時にサービスを開始

SBDデバイスがノードからアクセスできなくなった場合は、ノードが無限の再起動サイクルに入ることあります。これは技術的には正しい振る舞いですが、管理ポリシーによっては、まず間違いなく面倒な問題となるでしょう。そのような場合には、ブート時にCorosyncおよびPacemakerを自動的に開始しないのがよいでしょう。

先に進む前に、systemctl restart pacemaker.serviceを実行して、SBDがすべてのノード上で開始しているようにします。

次のコマンドを使用すると、ノードスロットとそれらの現在のメッセージがSBDデバイスからダンプされます。

root # sbd -d /dev/SBD list

ここに、SBDとともに起動されたすべてのクラスタノードが一覧され、メッセージスロットにはclearが表示されるはずです。

ノードの1つにテストメッセージを送信してみます。

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

ノードがシステムログファイルにメッセージの受信を記録します。

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

これによって、SBDがノード上で実際に機能し、メッセージを受信できることが確認されます。

SBDのセットアップを完了するには、次のように、SBDをCIB内でSTONITH/フェンシングメカニズムとしてアクティブにします。

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

リソースのクローンを作成する必要はありません。どちらにせよ問題が発生すればそれぞれのノードをシャットダウンすることになるからです。

どの値がstonith-timeoutに設定されているかは、msgwaitタイムアウトによって異なります。msgwaitタイムアウトは、基盤のIOシステムで許可されている最大タイムアウトより長い必要があります。たとえば、プレーンなSCSIディスクの場合は、30秒です。msgwaitタイムアウト値を30秒に設定する場合、stonith-timeoutを40秒に設定すると適切です。

ノードスロットは自動的に割り当てられるので、手動のホストリストを定義する必要はありません。

以前設定した他のフェンシングデバイスを無効にします。現在、この機能にはSBDメカニズムが使用されるからです。

rootとしてログインし、シェルを起動します。

設定ファイル/etc/sg_persist.confを作成します。

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

次のコマンドを実行して、プリミティブリソース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

sg_persistプリミティブをマスタ-スレーブグループに追加します。

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

aliceサーバ上にマスタを設定し、bobノード上にスレーブを設定します。

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

いくつかのテストをします。リソースがマスタ/スレーブステータスの場合は、マスタサーバ上で、/dev/sdc1をマウントして、書き込むことができます。ただし、スレーブサーバ上では書き込むことができません。

OCFS2プリミティブを追加します。

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

ベースグループからクローンを作成します。

crm(live)configure# clone cl-group basegroup

ms-sgと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

editコマンドで、すべての変更内容を確認します。

変更をコミットします.