運用管理サーバをクラスタシステムにする場合、二重化する場合のそれぞれの特長を以下に示します。
クラスタシステム | 運用管理サーバ | 運用管理サーバ | |
|---|---|---|---|
通常運用 | 管理機能は、一方のサーバで動作する。 | 管理機能は、すべてのサーバで動作する。 イベント通知/対処情報は相互連携する。 管理情報もそれぞれのサーバで管理する。一部の情報は、主系サーバだけで収集/管理し、情報を連携する。 | 管理機能は、すべてのサーバで動作する。 イベント通知/対処情報は相互連携する。 管理情報もそれぞれのサーバで収集/管理する。 |
通常運用 | クラスタサービスに登録した論理ホスト名(IPアドレス)に対して情報を通知する。 | 両サーバに対して情報を通知する。 | |
運用管理サーバのノードダウン時 | もう一方のノード(待機)で管理機能が起動し、情報を引き継ぐ。 | ダウンしたサーバ側だけ利用できなくなるが、もう一方で、監視を継続できる。 ただし、従系側では、一部の機能は使用できない。 | ダウンしたサーバ側だけ利用できなくなるが、もう一方で、監視を継続できる。 |
運用管理サーバのノードダウン時 | クラスタのIP引継ぎにより自動的に通知先を切り替える。 | 通知できなくなったマネージャへの情報は、一定量保留するが復旧しなければ破棄される。 | |
トラフィック量 | 監視メッセージなどを通知する先の運用管理サーバが1つのため、トラフィック量は1台分。 | 監視メッセージなどを通知する先の運用管理サーバが複数台あるため、トラフィック量が台数分になる。 | |
運用管理サーバの設置場所 | クラスタ構成の範囲(同一サイト内) | 各運用管理サーバの設置に制約はないが、情報の同期を考慮し同一サイトに設置する。 | 各運用管理サーバを遠隔地に設置することも可能 |
運用管理サーバ自身の監視 | 運用管理サーバ自身は監視できない。 | 運用管理サーバ自身を監視可能。また相互監視も可能。 | 運用管理サーバ自身を監視可能。 |
構成情報の管理 | 共有ディスク上で一元管理。 | 各サーバで別々に管理しているが、同期処理により同一構成で管理。 | 各サーバで別々に管理している。管理対象のシステムは別構成でも可。(イベント/対処情報だけは同期) |
各種情報のバックアップ | 両方の運用管理サーバを停止しないとバックアップできない。 | 一方の運用管理サーバは動作したまま、片方だけバックアップできる。 | |