Stylez Advent Calendar 2016の23日目です。
以前、取引先の方と「Zabbix自体には冗長化の機能って無いよね。AWS上でZabbix構築する際、耐障害性を考慮した冗長構成のベストって何？」って話になり、色々議論したことがあったので、その内容をまとめました。
前提
- AWS上で構築
- 負荷分散的な要素は考慮しない
- 監視サービスの継続性を重視
案１. クラスタウェア
絵が雑ですいません。。。
ネットで探すと良く出てくるパターンでしょうか。
PacemakerとかDRBDでWebやDBのプロセス・データをサーバ間で監視・同期させて、障害が起きたら自動的に切り替える構成です。
オンプレ時代からの枯れた構成ですし、実績は今回紹介するパターンでは最も多そうな気がしますが、クラスタウェアの管理が運用上負担になりそうです。（個人的にトラウマ）
参考：AWS上のZabbixをPacemaker（HeartbeatV2）で冗長化
案２. AutoScaling + RDS
WebとDBを分離し、DBはRDSを利用。
WebはAutoScaling（上限下限：１）にして、インスタンスが死んだら自動的に再構築されるという構成です。
クラスタウェア構成と比較して、冗長部分はAWSにお任せするパターンです。
この構成は少しクセがあり、AutoScalingなのでインスタンス起動の度にIPアドレスが変わります。
従って、管理画面アクセス用と監視対象サーバからの通信（アクティブチェック）用の内部ELBを入れる必要があります。
また、Zabbixエージェント側の設定も工夫が必要で、ホスト自動登録設定を仕込んだ際に、内部ELBのIPアドレスでホスト登録されてしまうので、実サーバのIPを通知できるようにエージェント設定を変更する必要があります。
ここまでAutoScalingのクセに悩むのであれば、AutoRecoveryでも良いじゃんって話もありますが、AutoRecoveryだとAZをまたいで起動しないので、AZ障害を鑑みてAutoScalingを選んでいます。
クセをつかむまでは大変ですが、一度設定してしまえば、冗長部分の運用負荷は大きくないので、おすすめです。
案３. Zabbix製バックアップツール
Zabbix公式で出ている Zabbix設定バックアップ同期ツール（以下、バックアップツール）というものがあります。
通常、エクスポート/インポート出来る設定項目は限られていて、アクションやユーザとか一部の項目はエクスポートできません。
もちろん、DBダンプすれば可能ですが、まるっとダンプすると監視データごとぶっこぬいてしまうので、監視設定のバックアップという意味合いでは難があります。
このツールを使えば、通常エクスポート出来ない部分含めた設定をファイルとして出したり入れたりすることが出来ます。
従って、このツールを双方のシングルZabbixに入れて、マスターからバックアップしたファイルをスレーブのZabbixに適用し続ければ、設定を同期することが可能になります。
この構成は文字通り設定だけ同期する事になるので、Active/Active構成で動くZabbixが出来上がります。
しかも、スレーブにバックアップ設定を適用する際、障害通知を無効にするオプションが指定できるので、双方のZabbixからアラートが飛ぶという事も回避できます。
問題点として、クラスタ構成と違ってマスター障害時はスレーブ側の障害通知を手動で有効にし、管理画面はスレーブ側を参照する必要があります。
あと、バックアップファイルをスレーブに転送する処理は、自分で作る必要があります。（rsyncするとか、共有ディレクトリに置くとか）
また、Active/Active故に、双方の監視データは異なる値が取れている可能性があります。運用する上ではこのあたり意識する必要がありそうです。
最後に、一番の問題は、このツール自体が、Zabbix社の技術サポート契約に加入する必要があるという事です。
という事で、お金かかります。
総括
個人的にはクラスタの管理はしたくないので、案2か案3。構成のシンプルさを見れば、案3を推したいです。
最近では、Dockerとか今までの常識を覆すようなインフラも出てきて、こういった専用サーバがある前提でという考えも無くなってくるのかもしれません。
他にも良い案知ってる方がいれば教えてください。