Corosync とか Pacemaker
- そのものについては適当におぐぐり下さい
- この 2つを使って定期的なスクリプトの実行とフェイルオーバー時にスタンバイとなるサーバーに処理を以降してスクリプトの- 実行を継続させる実装を行いたいと思います
- 定期的なスクリプトの実行は Pacemaker での op monitor を利用します(これ、重要)
Corosync の設定
# Please read the corosync.conf.5 manual page compatibility: whitetank aisexec { user: root group: root } service { name: pacemaker ver: 0 } totem { version: 2 secauth: off interface { member { memberaddr: xxx.xxx.xxx.1 } member { memberaddr: xxx.xxx.xxx.2 } ringnumber: 0 bindnetaddr: xxx.xxx.xxx.1 # Master サーバーに設定 bindnetaddr: xxx.xxx.xxx.2 # Slave サーバーに設定 mcastport: 5405 ttl: 1 } transport: udpu } logging { fileline: off to_logfile: yes to_syslog: yes debug: on logfile: /var/log/cluster/corosync.log debug: off timestamp: on logger_subsys { subsys: AMF debug: off } }
Pacemaker の設定
primitive hoge lsb:hoge op start interval="0s" timeout="300s" on-fail="restart" op monitor interval="10s" timeout="60s" on-fail="restart" op stop interval="0s" timeout="300s" on-fail="block" property $id="cib-bootstrap-options" dc-version="1.0.13-30bb726" cluster-infrastructure="openais" expected-quorum-votes="2" no-quorum-policy="ignore" stonith-enabled="false" crmd-transition-delay="0s"
スクリプト
以下を hoge として /etc/init.d/hoge に設置。
#!/bin/sh # # chkconfig: 2345 99 10 # description: xxxxxxxxxxxxxx # Source Function Library . /etc/init.d/functions # System Variable prog=${0##*/} lock=/var/lock/subsys/$prog # User Variavle # Source Config if [ -f /etc/sysconfig/$prog ] ; then . /etc/sysconfig/$prog fi # case "$1" in start) curl -LI yahoo.com -o /dev/null -w '%{http_code}n' -s > /tmp/test exit 0 ;; stop) rm -f /tmp/test exit 0 ;; status) if [ -f /tmp/test ] ; then curl -LI yahoo.com -o /dev/null -w '%{http_code}n' -s >> /tmp/test exit 0 else exit 3 fi ;; *) echo "Usage: $0 {start|stop|status}" exit 1 esac
もすこし凝ったことをさせたい場合には…
curl -LI yahoo.com -o /dev/null -w '%{http_code}n' -s >> /tmp/test
の部分を独自実装しているスクリプトに置き換えれば良い。但し、返り値の判断等も合わせて実装する必要がある。
挙動
通常
- Corosync が起動した時点 Master 側で op start を実施(/tmp/test に 200 が出力)
- op monitor が実施され定期的(interval=”10s”)に /tmp/test 以下に 200 が出力される
Master 停止(フェイルオーバー発生)
- Master 側で op stop が発生(/tmp/test に 200 が出力)
- Slave 側で op start が発生
- 以降で Slave 側で op monitor が実施されて定期的に /tmp/test 以下に 200 が出力される
<
h4 id=”behavior-standby-stop”>Standby 停止(何もおきない)
1.Standby 側を node standby にてステータスをスタンバイに遷移
2.Master 側は Standby 側のスタンバイのステータスを検知するが特に何もアクションを起こさない(Master 側でスクリプトは実行され続ける)
スプリットブレイン発生
crm コマンド
実行例
crm node xxxx
とか
crm configure xxx
configure
- edit で設定を修正することが出来る
- commit 設定を修正後に設定を反映させる(但し、直ぐに反映されるので注意する)
node
- standby node{node} のステータスを standby ステータスにする
- online node{node} のステータスを online ステータスにする
その他
- end 各サブメニューから抜ける
- exit crm コマンドから抜ける
AWS 上でスプリットブレインっぽいことを起こす方法
- セキュリティグループで UDP 通信をぶった切る(Corosync の再起動が必要→セキュリティグループをぶった切っても接続済みの通信は継続されるっぽい)
- iptables で UDP を切る
iptables -A INPUT -p udp -j DROP iptables -A OUTPUT -p udp -j DROP
取り急ぎ
メモ。
元記事は、こちらです。