AWSのInternal ELBを使ったアクティブ・スタンバイの事例を使って、MySQLをフェイルオーバーさせる方法実験してみました。
SUZ-LAB記事を確認してみた
SUZ-LAB：ELBとHertbeatでアクティブスタンバイの記事を確認してみました。
スクリプトをそのまま使って、ELBにHealthcheckを設定すると記事の通りにELBは動作しました。
ところで、このままでつかうにはちょっと足りてないですね。
PacemakerのOCF:Heartbeat:mysqlと連動させるには
RedHat社ドキュメント：6.3. Colocation of Resourcesを読むと、コロケーション（連動？）設定するとリソースを一体として取り扱うことができます。
pacemkaerでocf:heartbeat:mysqlを用いてmysqlをチェックさせて、動かなくなったらfailoverスクリプトを呼ぶように設定するとELBをつかったMySQLサービスの差し替えができるようになりますね。
簡単にひっつけてみます：
pcs resource create mysql ocf:heartbeat:mysql config="/etc/my.cnf" binary="/usr/bin/mysqld_safe" \
pid="/var/run/mysql/mysql.pid datadir="/var/lib/mysql"
pcs resource update mysql replication_user="replication"
pcs resource update mysql replication_password="password"
pcs resource update mysql monitor interval=20s timeout=30s
pcs resource update mysql monitor interval=10s role=Master timeout=30s
pcs resource update mysql monitor interval=30s role=Slave timeout=30s
・・・
pcs resource create failover lsb:failover
pcs constraint colocation add failover mysql INFINITY
lsbでfailoverスクリプトをリソース登録しているところは、SUZ-LAB記事の通りで。
コロケーションの設定は、REDHATのドキュメントに書いてある通りINFINITY値を設定して連動して動作するようにしています。
mysqlのプロセスをkillするとfailoverスクリプトが動作してELBのヘルスチェックファイルを差し替えすることでアクセス経路を変更するように動作します。
こうすると、MySQLの状態をチェックもすることもできるのでちょとだけだけ現実的になったかな。
他には・・・
アマゾンのドキュメントを読むと、ELBのhealthcheckはインスタンスを生成した時にはチェックをしてくれるのですが停止・起動した場合にはチェックしないことがあるため、インスタンスの登録をやり直すようにとの素敵な文言があります。
継続して利用するインスタンスの場合には、もうひと細工が必要ですね。
AWSは、1分使っても1時間つかっても同じ費用が発生するのでインスタンスをたくさん作るとお金がかかるところがつらいなぁ。