高可用性（冗長化）環境構築サービス

ビジネスの多様化と変化が急速に進むなか、それらを支えるIT技術も日進月歩で進化しており、ITシステムがビジネスの根幹を支える大きな要素として重要性を高めています。それに伴いITシステムの安定稼働に対する要求も日々高まるなか、安定稼働を実現するために用いられる監視システムの役割も日々大きくなっており、安定した稼働監視の実現 = 監視システムの可用性担保はもはや必須と言っても過言ではなくなりました。

Zabbix サーバーの高可用（冗長）構成には大きく以下3つの選択肢があり、それぞれの特徴には次のようなものがあります。

Zabbix LLC Native HA / Active-Standby 方式

Zabbix バージョン 6.0 から登場した、Zabbix サーバーの標準機能でフェイルオーバー動作を実施する方式です。なお、Zabbix データベースにおける高可用（冗長）構成は提供されないため、AWS（Amazon Web Services）や Microsoft Azure をはじめとするクラウド環境と組み合わせ、Zabbix データベースにマネージドサービスを活用する方式にてコストメリットが出ます。

• Zabbix Enterprise サポート＆サブスクリプション契約の有無によらず実装可能
• クラスターソフトウェアの導入（追加ソフトウェア費用）は、原則不要
• Zabbix データベースの高可用（冗長）構成を利用する場合は、別途クラスターソフトウェアや主従系間データ同期の仕組みが必要
• 監視データの収集処理は主系の1台で実行されるため、障害発生時の監視ダウンタイムが若干発生する
  （フェイルオーバー動作中のデータ欠落・遅延）
• 異常検知の重複排除に考慮が必要
  • Zabbix エージェントによるアクティブ監視処理での重複検知抑止には、Zabbix エージェント バージョン 6.0 以降の利用もしくはロードバランサ―（AWS環境の場合、NLBを使用する）を用いた受信経路の集約が必要
  • SNMP トラップは主従系の2台で受信処理が稼働するため、アクティブ監視処理と同様な対処が必要
  • 従系での連続稼働が可能。主系切り戻し時における設定内容の同期などの考慮が不要

HA クラスター製品利用 / Active-Standby 方式

別途、HA クラスター製品を用いてフェイルオーバー動作を実施する方式です。Red Hat High Availability アドオンなどのクラスターソフトウェアを別途導入し、HA クラスターを構成します。

• Zabbix Enterprise サポート＆サブスクリプション契約の有無によらず実装可能
• クラスターソフトウェアの導入（追加ソフトウェア費用）が必要（例: Red Hat High Availability アドオンなど）
• 監視データの収集処理は主系の1台で実行されるため、障害発生時の監視ダウンタイムが若干発生する
  （フェイルオーバー動作中のデータ欠落・遅延）
• 異常検知の重複排除に考慮が必要
  • Zabbix エージェントによるアクティブ監視処理での重複検知抑止には、Zabbix エージェント バージョン 6.0 以降の利用もしくはロードバランサ―（AWS環境の場合、NLBを使用する）、または 仮想IPアドレス（VIP）を用いた受信経路の集約が必要
    • Zabbix エージェント バージョン 6.0 以降では複数指定した監視データ送信先別にエージェント側でキャッシュされるため、主系に送信済みのデータが従系に切り替わったタイミングで送信される可能性あり
• 従系での連続稼働が可能。主系切り戻し時における設定内容の同期などの考慮が不要

Zabbix Japan LLC 設定バックアップ同期ツール / Active-Active 方式

Zabbix Enterprise サポート＆サブスクリプション契約にて利用可能となる、Zabbix設定バックアップ同期ツールを用いた Active-Active 冗長化方式です。

• 実装にZabbix Enterprise サポート＆サブスクリプション契約が必須
  （サポート契約者に提供されるZabbix設定バックアップ同期ツールが必要）
• クラスターソフトウェアの導入（追加ソフトウェア費用）は不要
• 監視データの収集処理は2台で実行されるため、障害発生時の監視ダウンタイムは原則なし（データ欠落なし）
  • 監視データは別々のデータベースに蓄積されるため、厳密には値が一致しない
  • 監視トラフィックや監視対象機器の負荷が2倍になる
• 異常検知は遅延リスクがあるものの重複や欠落なし
  • 2台の Zabbix サーバーが別々に監視をするため、従系からの発報を抑止するために画面による操作にてアクションを無効にする必要あり
• 主系での障害発生後、従系での連続稼働は非推奨
  • 監視設定の同期を定期的に主系→従系で実施しているため、逆方向の同期は原則不可