大規模監視におけるZabbix proxyの冗長化について
お世話になります。
大規模監視環境におけるZabbixProxyの冗長化について質問させてください。
現在、複数のZabbixProxyを用いてSNMPポーリングとICMP監視データを採取する構成を考えています。
対象監視サーバが数十万台あり、百万単位のアイテムを5分間隔でポーリングします。
その際、サーバを遠隔地に配置し、一方がダウンしてももう一方でカバーできるようZabbixProxyの冗長化を図りたいのですが、どうすればよいでしょうか。
冗長構成として、AエリアとBエリアに同様のProxyを配置し、通常時はAエリアを稼働、
Bエリアではサーバをアクティブ状態で、監視サービスだけを停止した状態でスタンバイし、
Aエリアのサーバがダウンした際にはシステムを長時間停止せずに自動でBエリアに稼働が移行する、という機能を実現したいです。
監視対象が膨大なので、常に2エリアを動かすことはできません。
どのような構成でどのような設定をすればよろしいでしょうか。
皆様の知恵をお貸しください。よろしくお願いします。
wakaba - 投稿数: 228
広瀬です
①シェルか何か手製のScriptでエラー検知して、サーバダウンしたらStbを起動させる
⇒何を持ってハードダウンとするかが問題で、PINGが通らない＝ダウンとは
言い切れないのが1点＜後述のパターンにも言えるが・・・
⇒また、IPアドレスは仮想IPを立てる必要があり、IPの制御を何処で担保するか
②Pacemaker + Corosync + DRBDを利用する
⇒仮想IP、リソース制御、DBデータの同期が可能。一番確実なのはこの辺だと思います。
但し、DRBDに関してはそのままでは遠隔地のデータ同期が非常に重いのでDRBD Proxy
を使う必要があります(DRBDそのものはOSSですが、DRBD Proxyは有償です)
⇒PacemakerにしてもDRBDにしても技術的な敷居が非常に高いのが欠点
他、商用製品のLifeKeeperなどでも同等な事は可能です。果てしなく高そうですけど・・・
冗長化の要件がどの程度か次第ですが、上述のソフトウェア(商用、OSSともに)はダウンタイム
が何処かしらで発生します。
同一セグメント内という前提条件ですが、ライトなDBならDOWNからUPまで3秒で切り替わりますし、
InnoDBのバッファプールに50Gくらい割り当てているMySQLで実施した事がありますが、落とすの
に最低でも数十秒は要します
※DBの設計次第とも言えるのであくまで参考値
厳密性持たせるならFTサーバ使うしか手法は無いですが、ハードだけで数百万クラスなので
割に合わないと思います。保守も高そうで・・・・