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

Q: 監視システムの冗長化はなぜ必要ですか？

「監視の空白」による二次被害の防止 監視サーバーが停止している間に発生した障害は、誰にも通知されません。監視が止まっている最中に、基幹データベースがダウンしたらどうなるでしょうか？Zabbixを冗長化していれば、万が一故障してしまった際に即座にサブ機が監視を引き継ぎます。よって、「気づかないうちに基幹データベースなどの重要サービスが止まっていた」という最悪の事態を防げます。 Zabbixメンテナンス時のダウンタイムゼロ ZabbixにもOSのセキュリティパッチ適用やZabbix自体のマイナーアップデートが必要となり、一時的に監視を停止する必要があります。監視停止の影響を最小限にするため、従系を先にアップデートし、その後、役割を切り替えてから主系をアップデートする「ローリングアップデート」が可能です。また、メンテナンス作業中に予期せぬ不具合が発生しても監視を継続したまま切り戻しが可能になります。

Q: クラウド環境（AWS/Azure）での冗長化にも対応していますか？

対応しています。Zabbix LLC Native HA / Active-Standby 方式を用い、クラウドで準備されるマネージドDBを採用する方式をお勧めいたします。

Q: アプライアンスでの冗長化にも対応していますか？

対応しています。 アプライアンス では、Zabbix Japan LLC 設定バックアップ同期ツール / Active-Active 方式を採用する方式でご提供いたします。

Q: Active-Active構成のメリットについて教えてください。

2台のZabbixサーバーが常時データを収集するため、スタンバイ機への切り替え時に発生するデータ欠測がありません。ただしネットワーク負荷が2倍になる点にご留意ください。

システム監視の停止が避けられない環境向けに
冗長化された Zabbix サーバーを構築

Zabbix サーバーを冗長化する場合、Zabbix ならびに主従系切替・データ同期に伴う仕組みの実装が必要です。当社では、これらの考慮ポイントを網羅的にカバーすることで監視システムのサービス継続性を担保しながら、運用者の負荷を最大限に削減できるよう設計しています。

ミッションクリティカルなシステムの監視に Zabbix を採用している金融・通信業界のお客様、監視をサービスメニューとして提供しているデータセンター事業者様など、さまざまな業界のお客様に採用いただいています。

こんな方におすすめ

安定した稼働監視が必要
監視システムの可用性を担保したい
監視システム障害時の対応に悩んでいる
2台の Zabbix 間で監視設定が同期できない
Zabbix を冗長化したいがノウハウがない
監視システムをサービスとして提供している

複雑化するITシステムを安定稼働させるためには？

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

Zabbix高可用性（冗長化）環境構築資料をダウンロード

方式ごとの比較からクラウド環境との親和性まで紹介

高可用（冗長）構成の種類と選択

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 サーバーが別々に監視をするため、従系からの発報を抑止するために画面による操作にてアクションを無効にする必要あり
主系での障害発生後、従系での連続稼働は非推奨
- 監視設定の同期を定期的に主系→従系で実施しているため、逆方向の同期は原則不可

Zabbix冗長化構築のご相談

最適なHA構成を、Zabbix認定パートナーが提案いたします

諸元・方式比較表

よくあるご質問（FAQ）

監視システムの冗長化はなぜ必要ですか？

「監視の空白」による二次被害の防止
監視サーバーが停止している間に発生した障害は、誰にも通知されません。監視が止まっている最中に、基幹データベースがダウンしたらどうなるでしょうか？
Zabbixを冗長化していれば、万が一故障してしまった際に即座にサブ機が監視を引き継ぎます。
よって、「気づかないうちに基幹データベースなどの重要サービスが止まっていた」という最悪の事態を防げます。
Zabbixメンテナンス時のダウンタイムゼロ
ZabbixにもOSのセキュリティパッチ適用やZabbix自体のマイナーアップデートが必要となり、一時的に監視を停止する必要があります。
監視停止の影響を最小限にするため、従系を先にアップデートし、その後、役割を切り替えてから主系をアップデートする「ローリングアップデート」が可能です。
また、メンテナンス作業中に予期せぬ不具合が発生しても監視を継続したまま切り戻しが可能になります。

サーバーの冗長化にはそれなりのコストが掛かりませんか？

冗長化のコストは、「最悪の事態を防ぐための保険料」です。「冗長化のコスト」と「監視対象システムの停止による損失」を比較・検討ください。監視対象のシステムが重要なシステムであればこそ、障害発見の遅れがリスクとなります。