Pacemakerのboothを動かしてみたら思ったより楽だったのでご紹介...な内容です。少しBoothの説明をしたうえで、おおまかな設定を説明していきます。

##Boothとは？
一言でいうと、Booth[ぶーす]とはPacemakerのCTR(Cluster Ticket Registry)です。地理的に離れた場所にあるHAクラスタの自動フェイルオーバが可能になります。Pacemakerは高可用性クラスタを作るOSSで、Boothはそのアドオンです(もちろんOSSの)。

もう少し詳しく説明します。基本的にPacemakerはLAN環境上で使用することが前提になっており、WANごしなど遠距離での使用は想定されていません。そこでチケットと呼ばれる機能を使うとこの制約に対処できるようになります。
さて、このチケット機能を用いてマルチサイトクラスタを構成している時に、１つのサイトで障害が発生するとします。この時、別のサイトをアクティブにしてサービスを移動させるには、チケットをサービスの移行先のサイトに与える事が必要になります。この作業を自動化するための１つの解決策がBoothです。

マルチサイトクラスタはDR(ディザスタリカバリ)用途に使用されることが多いかと思いますが、Boothを使用する事で障害発生時の迅速な対応が期待できます。

##Boothを使った構成
Boothを使用する場合、サービスの起動する場所であるサイトの他に、Boothがアービトレータとして動作するための追加の1サイトが必要になります。またアービトレータを含む全サイトでboothdというBoothのデーモンを動作させることが必要です。

以下の図は2サイト4ノード+1サイト1ノードの構成例です。
この2サイト4ノード構成では、通常時はサイトA内にチケットを与えておいて、サイトA内で2台構成のHAクラスタを稼働させており、もしサイトAが壊滅した場合にはサイトBにチケットを与えてアクティブ化します。
ここに、さらにアービトレータというboothのためのサイトCを追加しています。

構成にサイトAとサイトBの2つしかなかった場合、どちらが生き残ったサイトなのかは人間が判断する必要がありました。しかしアービトレータがあれば、生き残っているサイトを確認することができるので、チケットを自動で割り振ることが可能になります。

##Boothの設定方法
(CorosyncやPacemaker等の他の設定内容は省きます)
基本的には通常のクラスタ設定に以下2つを加えれば大丈夫です。

/etc/booth/boothd.confを書く
Pacemakerにbooth-siteリソースエージェントを追加する

なお私が動作確認に使った環境は以下です。

OS : CentOS Linux release 7.3.1611 (Core)
kmod-drbd84-8.4.9-1.el7.elrepo.x86_64
drbd84-utils-8.9.8-1.el7.elrepo.x86_64
pacemaker-1.1.15-11.el7.x86_64
corosync-2.4.0-4.el7.x86_64
booth-1.0-6.ef769ef.git.el7.x86_64

###boothd.confに設定する内容
/etc/booth/boothd.conf.sampleがあるので、これを雛型にして編集です。

transport="UDP"

# The port that booth daemons will use to talk to each other.
port="9929"　　　　　

# The arbitrator IP. If you want to configure several arbitrators,
# you need to configure each arbitrator with a separate line.
arbitrator="192.168.129.195"

# The site IP. The cluster site uses this IP to talk to other sites.
# Like arbitrator, you need to configure each site with a separate line.
site="192.168.129.197"
site="192.168.129.198"

# The ticket name, which corresponds to a set of resources which can be
# fail-overed among different sites.
ticket="TIC"
    expire = 120
    timeout = 5
    acquire-after = 120

最後のセンテンスでは、管理する対象のチケットをticket=""で指定しています。サイトが他のboothdと通信ができなくなった場合にはexpireの時間後にチケットがrevokeされます。timeoutは死活監視のタイムアウトです。acqire-afterは、チケットがrevokeされた後で他のサイトにチケットが与えられるまでの時間です。

###Pacemakerにboothdの設定を追加する
ポイントとしては以下のようにocf:pacemaker:booth-siteのリソースエージェントを登録するだけです。構成によってはサイト用のVIPと一緒に起動するようにcolocationやgroupの設定をしたりorderの設定を行ったりも必要かもしれません。

# crm configure 
primitive boothsite-1 ocf:pacemaker:booth-site \
    params config=booth \
    op monitor interval=30s timeout=30s \
    op start interval=0s timeout=30s \
    op stop interval=0s timeout=30s \
    meta target-role=Started
# crm(live)configure# verify
# crm(live)configure# commit

##アービトレータの起動
サイトAとBではPacemakerによって起動しますが、アービトレータでは手動でboothdを起動します。

#booth start

##Boothの動作確認
ちゃんと起動していれば以下のような情報が表示されます。

# booth list
ticket: TIC, leader: 192.168.129.197, expires: 2017-08-02 15:59:31

boothデーモンが起動していないと、コマンドがboohd.confに指定した自分のIPに接続できないというエラーが出ます。

# booth list
Aug 03 09:40:42 3node2 booth: [1103]: error: connect to 192.168.129.195 got an error: Connection refused

##ネットワークを切断して動作確認
boothがきちんと動作していれば、例えばサイトAからアービトレータまでの経路を切断した場合にはexpire時間の経過後にサイトAで有効期限切れになり、さらにacquire-after時間の経過後にサイトBにチケットが与えられます。