【わたしに♥おまかせ Zabbix⑧】Active-Active構成を用いた冗長化のポイント！
こんにちは！プラットフォーム技術部の齊藤(沙)です。
最近ではシステム全体の信頼性を高めるために、監視システムにも可用性が求められることが多く、Zabbix に関しても冗長化が必要となることが多くあります。
ということで、今回は Zabbix を Active-Active 構成を用いることで冗長化する方法と注意点について確認していきたいと思います！
前回の記事はこちら。
https://devlog.arksystems.co.jp/2018/11/16/6138/まとめ記事作りました♥
Active-Active 構成での冗長化ってどんな環境？
「まるごとおまかせZabbix」では、オプションサービス「快適Z：高可用性オプション」にて、Zabbix の Active-Active 構成による冗長化サービスを提供しています。
本サービスにおける Active-Active 冗長構成は、
- 監視機能は Active-Active（1,2号機にて同じ対象を多重監視）
- 通知機能は Active-Standby (2号機の通知機能を無効化)
となっており、監視機能は Active-Active ですが、通知機能は Active-Standby 構成であって完全な Active-Active 構成ではありません。なぜこのような構成になっているのかについては後述しますのでそちらを参照ください。
なぜ Active-Active 構成なの？
一般的なシステムの冗長化構成には Active-Active の他に Active-Standby という選択肢もありますが、「まるごとおまかせZabbix」ではなぜ Active-Active 構成を採用しているのでしょうか。
理由は大きく2つあります。
監視ダウンタイムの最小化！
Active-Standby 構成では、Active 機に障害が発生した際に、Standby 機への切り替わりが完了するまでの間は監視機能そのものが停止してしまい、監視データもその間の分は歯抜けになってしまいます。
Active-Active 構成では、1,2号機の両系統から同じ対象を監視することによって、片方に障害が発生してももう片方で監視が継続できるので、監視のダウンタイムは生じず、監視データの歯抜けも起こりません。
※ 通知機能は1号機から2号機への切り替わりが完了するまでの間、停止します。
障害ポイントの最小化！
Zabbix は Webフロントエンド、Zabbix-Server、データベースなど多くのコンポーネントが存在するため、Active-Standby 構成ではそれぞれに関して系統の切り替え方式を検討、実装する必要があります。
Webフロントエンドと Zabbix-Server に関しては Pacemaker と Corosync で、データベースに関しては DBMS のクラスタ機能でそれらを担うことが多く、システムに必要なコンポーネントが増え構成がとても複雑です。その結果、障害ポイントが増えてしまい通常運用に必要な作業も煩雑になることから運用負荷も高まる傾向にあります。
しかし Active-Active 構成を採用すれば、クラスタソフトやクラスタ構成も必要なく、障害ポイントや運用負荷を最小化できます。
Active-Active 構成で考慮すべき問題
Zabbix の Active-Active 冗長化については、2台の Zabbix サーバーにそれぞれ同様の設定を行い、それぞれ独立して稼働させることで実現できますが、以下のような問題があります。
監視設定の登録作業が2倍になる
1,2号機にて同じ対象を監視するので、監視設定の追加/変更/削除は1,2号機双方へ実施する必要があります。同じ作業を2回行うことになるため、運用負荷が上がるだけでなくヒューマンエラーの発生確率も上がります。
障害通知が多重発報される
1,2号機にて同じ対象を監視するので、監視対象に障害が発生した場合、1,2号機双方から運用担当者へ同じ障害通知が多重発報されます。不要な障害通知は状況誤認による混乱や対処の遅れを生む原因となり、運用品質の低下につながります。
上記問題の解決に必要な対策
上記の問題を解決するために、どのような対策が必要なのか確認していきます。
「監視設定の登録作業が2倍になる」問題への対策
- 1号機から2号機へ監視設定を自動同期する
「障害通知が多重発報される」問題への対策
- 通知機能だけはあえて Active-Standby 構成とする
- 障害通知の発報元を1号機から2号機へ自動切替える
Active-Active 構成 問題対策の実現方法
では、上記対策について、具体的にどのように実現するのかを確認していきたいと思います。
1. 1号機から2号機へ監視設定を自動同期する
実現方法
1号機から2号機への監視設定の自動同期に関しては、Zabbix 社が提供している Zabbix 設定バックアップ同期ツールを用います。
Zabbix 設定バックアップ同期ツールでは、設定を同期する際に2号機のアクション設定をすべて無効化する機能を有しています。これにより2号機からの障害通知の多重発報を抑制できます。
注意点
1号機から2号機への監視設定の同期は Zabbix 設定バックアップ同期ツールを用いることで実現できますが、設定同期をしている間は、2号機の Zabbix-Server を停止させる必要があります。同ツールは停止機能を提供していないため、別途スクリプトを作り込む必要があります。
Active-Active 構成を採用する場合、1,2号機で相互監視をするケースが大半ですが、2号機の Zabbix-Server および Webインターフェース停止中は1号機から当該アラートが出力されないよう、1号機の該当プロセス監視に対して、トリガー設定の COUNT 関数や SUM 関数を用いて5分程度の DOWN は障害として検知しないようあらかじめ対処しておくことが必要です。
また、該当のプロセス監視のみではなく、2号機のすべての監視について一定期間通知が無効になっても問題なければ、Zabbix のメンテナンス機能を用いるという選択肢もあります。
自動同期を行う前提として、2号機の WebUI 上で監視設定を新たに追加することを禁止する必要があります。以下その理由について説明します。
Zabbix データベースでは監視設定と、監視履歴データはそれぞれ itemid という一意な識別子で紐づけをしています。
Zabbix 設定バックアップ同期ツールは上記のうち、監視設定のみを2号機へ同期(上書き)しますが、監視履歴データは同期しません。つまり itemid の採番は1号機での監視設定時のみ行われ、2号機は設定同期によりその itemid を継承する形で対象となる監視データを取得、蓄積する仕組みとなります。
よって、2号機側で監視設定を行った場合、その監視設定により取得,蓄積された監視履歴データは1号機側には存在しない2号機独自の itemid に紐づけられます。
設定の同期により1号機側の監視設定で上書きされるので、2号機独自の itemid で採番された監視設定は消滅しますが、それに紐づけられた監視履歴データは削除されずゴミデータとして残ってしまいます。
さらには、1号機への監視設定追加時に、2号機側で独自に採番された itemid と重複する itemid が付与されてしまった場合、2号機への設定同期後に監視設定と監視履歴データが不正に紐づいてしまうため、監視履歴データの参照時に誤ったデータが表示されることにもなります。
2号機の監視設定追加を禁止するという観点では、手動によるオペレーション以外にもディスカバリ設定によって自動で追加されることもあるため、ディスカバリ設定のアクションも含めて無効化をした上で、通知機能を担うアクション設定のみを有効にする必要があります。
2. 通知機能だけはあえて Active-Standby 構成とする
実現方法
1号機での障害発生を契機に、1号機から2号機への「障害通知切り替え機能」を実行する。
2号機から1号機の監視(主要コンポーネントである Zabbix-Server プロセスや、データベースプロセス、及び1号機自体の死活状況など)を行い、1号機の障害発生を契機に後述の「3. 障害通知の発報元を1号機から2号機へ自動で切替える」機能を起動する。
上記一連の処理をスクリプトで実装し、2号機にて定期実行することで実現します。
注意点
上記の処理は2号機の Zabbix 標準機能である、アイテム,トリガー,アクション設定の組み合わせで実現できるように見えますが、前述「1. 1号機から2号機へ監視設定を自動同期する」で説明したとおり、設定同期の際に2号機側のアクションはすべて無効化しているため、2号機側ではアクション設定を利用できません。
そのため上記一連の処理はすべてスクリプトで実装するか、Zabbix API やデータベースへの SQL 実行を用いてアクション設定のみを有効化する実装が必要となります。
「まるごとおまかせZabbix」では、スクリプト化することで本機能を実現しています。
3. 障害通知の発報元を1号機から2号機へ自動で切り替える
実現方法
1号機から2号機への障害通知機能の切替えは、前述の「1. 1号機から2号機へ監視設定を自動同期する」にて無効化されているアクション設定を有効化することで実現します。
前述の「2. 通知機能だけはあえて Active-Standby 構成とする」を用いて2号機上で1号機の障害を検知した際、Zabbix API やデータベースへの SQL 実行にて2号機のアクション設定を有効化することで障害通知の発報元を2号機に切り替えます。
注意点
障害通知の発報元を切り替える時は、障害通知のアクションのみ有効にする必要があります。
また、 前述「1. 1号機から2号機へ監視設定を自動同期する」 の注意点の繰り返しとなりますが、障害通知発報元を2号機に切替えた後も、2号機側の WebUI 上で監視設定を追加することは禁止する必要がありますので改めてご注意ください。
まとめ
今回は Zabbix の Active-Active 構成を用いた冗長化について確認していきました。
Zabbix の Active-Active 冗長化は Zabbix 社から提供されている Zabbix 設定バックアップ同期ツールを活用することでいくつかの運用上の問題を解決することができますが、実運用を考えるとそのままでは不足する面も多く、なんらかの形でそれを補う必要があります。
「まるごとおまかせZabbix」ではそれらの不足に対し、極力運用の手間を軽減するよう考慮し、自動化を実現しています。
運用負荷を上げずにZabbix の可用性を向上させたい！とお考えの方々に今回の記事が少しでも参考になれば幸いです！
Zabbixの導入・構築でお困りですか？
Zabbixの導入・構築でお困りですか？アークシステムは、Zabbix Japan LLCの公式認定パートナーとして、豊富な実績と高い技術力でお客様をサポートします。
アークシステムが選ばれる理由
- 豊富な経験: 多くのZabbix導入・構築プロジェクトを成功に導いた実績
- 確かな技術力: Zabbix認定資格を持つエンジニアが対応
- 独自のソリューション: 「監視定義テンプレート」を活用した迅速かつ高品質な実装
- 最新情報へのアクセス: Zabbix社との強力なパートナーシップを活かした最新技術対応
こんな方に最適です
- Zabbixの新規導入を検討している
- 現行システムの運用に課題を感じている
- 大規模環境での監視体制を整えたい
アークシステムでは、Zabbixの導入・運用に関する課題を解決し、最適な環境を構築します。どんなご相談でもお気軽にお問い合わせください！
