ルータやサーバの状態を可視化したいと思いZabbixを構築したが、Zabbix構築にあたり必要となるDBについて考えたことのメモ。
ソフトウェアの選定については、PortageのZabbixパッケージはUSEフラグにデフォルトでpostgresが設定されており、他のDBソフトウェアについて詳しいわけでもないので、PostgreSQLに絞って考える。
耐障害性の要望として、以下の3つがある。
- ノードが1台停止しても、サービスの提供を継続できる。
- 元々1台のハイパーバイザ上にサーバを構築・運用していたが、過去に物理故障でハイパーバイザごとサービスが停止してしまったことがあり、以降は2台のハイパーバイザへサーバを分散して運用する方針としているため。
- CPUアーキテクチャが違っても、1の要望を満たせる。
- 現在運用している2台のハイパーバイザが、CPUの異なるMiniPCで稼働しているため。
- ソフトウェアバージョンが違っても、1の要望を満たせる。
- PostgreSQLの新しいバージョンがリリースされた時に、1台を切り離してバージョンアップし元に戻す、といった運用を想定しているため。
これらの要望を満たす構成ができないか調べたところ、Pgpool-IIと組み合わせてスナップショットアイソレーションを使用すると実現できそうだったので試すことに。 スナップショットアイソレーションでの構築に関するドキュメント(ネイティブレプリケーション/スナップショットアイソレーションモードの構築の例)とwatchdogの構築に関するドキュメント(Pgpool-II + Watchdogの構築の例)を見ながら構築する。 認証周り(自動接続で参照するファイルの配置やパスワードの使用可能文字)のミスで思うように進まないところもあったが、なんとか要望を満たす構成を実現できた。はず。
最近カーネルのバージョンアップで再起動を伴う作業があったため、作業の流れをまとめておく。
pcp_watchdog_infoでPgpool-IIの稼働状況を確認する。psql -c "show pool_nodes"やpcp_node_infoでPostgreSQLの稼働状況を確認する。pcp_detach_nodeで作業対象のPostgreSQLをクラスタから切り離す。pcp_stop_pgpoolで作業対象のPgpool-IIを停止する。(ホストの再起動で強制的に落としてもよい。)- 再起動する。
pcp_watchdog_infoで作業対象のPgpool-IIが自動起動しstandbyとして認識されていることを確認する。psql -c "show pool_nodes"やpcp_node_infoで作業対象のPostgreSQLが起動していないことを確認する。pcp_recovery_nodeで作業対象のPostgreSQLをクラスタへ戻す。psql -c "show pool_nodes"やpcp_node_infoで作業対象のPostgreSQLがクラスタへ戻ったことを確認する。(psqlで確認するまでpcp_node_infoのstatusがwaitingから変化しないことがあったので、psqlで確認したあとpcp_node_infoで確認する。)
上記の流れで、PostgreSQLを利用しているアプリケーションへ大きな影響を与えることなく、PostgreSQLの切り離しから復旧までできた。
※PostgreSQLの利用状況を精査したわけではなく、ぱっと見大丈夫そう、くらいの感覚であることに注意。