JP2011054033A - 監視制御装置 - Google Patents

監視制御装置 Download PDF

Info

Publication number
JP2011054033A
JP2011054033A JP2009203857A JP2009203857A JP2011054033A JP 2011054033 A JP2011054033 A JP 2011054033A JP 2009203857 A JP2009203857 A JP 2009203857A JP 2009203857 A JP2009203857 A JP 2009203857A JP 2011054033 A JP2011054033 A JP 2011054033A
Authority
JP
Japan
Prior art keywords
monitoring control
server
monitoring
control application
disk
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2009203857A
Other languages
English (en)
Inventor
Yasushi Ariga
靖 有賀
Takamitsu Chikedera
隆光 千見寺
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2009203857A priority Critical patent/JP2011054033A/ja
Publication of JP2011054033A publication Critical patent/JP2011054033A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Hardware Redundancy (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】2重障害への耐性を高めるとともに障害の発生から短時間で復旧可能な監視制御装置を提供すること。
【解決手段】運用系サーバ101と待機系サーバ102とが共有ディスク103を介して監視制御アプリケーション情報を共有しつつ被監視装置への監視制御を行う監視制御システムにおいて、運用系サーバ101と待機系サーバ102とに、ミドルウェア201、監視制御アプリケーション202、および冗長障害監視アプリケーション203を設ける。冗長監視制御アプリケーション203は、各サーバのローカルディスク1011、1021に記憶されている監視制御アプリケーション情報と共有ディスク103に記憶されている監視制御アプリケーション情報とを同期させる。この状態から両系障害が生じれば、監視制御アプリケーション202により提供される機能を必要最低限に絞り込んだ縮退運転を行わせる。
【選択図】 図1

Description

この発明は、SNMP(Simple Network Management Protocol)を用いてネットワークを監視する監視制御装置に関する。特にこの発明は、共有ディスクを利用するクラスタシステムの形態をとる監視制御装置の改良に関する。
IP(Internet Protocol)網のようなネットワークを監視するプロトコルには、実装が容易なSNMPが用いられることが多い。SNMPでは、SNMP TRAP(以下ではTRAPと表記する)と称するメッセージを用いて被監視装置から監視制御装置に管理情報が通知される。また、耐障害性能を高めるため監視制御装置は冗長化されることが多い。そのなかに、共有ディスクを設けてクラスタシステム化されるシステムがある(例えば、特許文献1を参照)。
運用系サーバと待機系サーバとを備える監視制御装置において、運用系および待機系のいずれのサーバも共有ディスクにアクセスし、運用系サーバと待機系サーバの切り替え時にデータを共有する。共有ディスクは冗長化され、ディスクの単一障害により監視制御装置の機能が停止しないように設計されることが多い。
しかしながら共有ディスク障害からの復旧前に共有ディスクの別の箇所で障害が発生すると(いわゆる共有ディスクの2重障害)、共有ディスクの停止が監視制御装置の機能停止の原因となる。このほか復旧操作を誤った場合や、オンラインで交換不能な部品(マザーボードなど)に障害が発生した場合にも同様に、監視制御装置が機能停止することになる。
監視制御装置は24時間稼動することが求められ、機能停止状態が長時間継続するとシステム運用へのインパクトが大きい。障害発生から復旧までの時間を規定時間内に納めることが、システムを利用する通信事業者から要求される場合もある。障害の発生に際して監視制御機能を短時間で復旧させることが求められている。
特開2006−227770号公報
障害に備えて装置を冗長化するには、それぞれ独立して動作可能なサーバを2つ設置する形態が先ず考えられる。しかし、2つのサーバ間でデータの同期をとるためにデータの処理量が倍増し、処理能力の高いサーバを用いたり、サーバの数をさらに増やしたりといった対処が必要になる。これに代えて共有ディスクを2重化する形態もあるが、この形態ではディスクへのアクセス回数が倍増し、やはり処理能力の高いサーバが必要になる。
このように監視制御装置を冗長化するには高額なサーバが必要であったり、構成が複雑になる分データの同期やメンテナンスも複雑になるという欠点がある。また、これら2重化の手法は共有ディスクの2重障害には耐えられない場合もあり、安価な共有ディスクではディスクのコントローラの2重化が困難なものもある。
この発明は上記事情によりなされたもので、その目的は、共有ディスクの2重障害への耐性を高めるとともに障害の発生から短時間で復旧可能な監視制御装置を提供することにある。
上記目的を達成するためにこの発明の一態様によれば、共有ディスクを用いて情報を共有する運用系サーバと待機系サーバとを備え、前記運用系サーバまたは待機系サーバのいずれかにおいて選択的に有効化される共通アドレスに向け被監視装置から発報される監視制御情報に基づいて前記被監視装置への監視制御を行う監視制御装置において、前記運用系サーバおよび待機系サーバの各々は、前記共有ディスクとは別に設けられるローカルディスクと、前記共有ディスクにアクセスして前記監視制御に係わる処理を担う監視制御アプリケーションと、自サーバの運用状態の監視と前記運用系サーバと前記待機系サーバとの冗長切替に係わる処理を担うミドルウェアと、このミドルウェアの状態を監視する冗長障害監視アプリケーションとを備え、前記冗長障害監視アプリケーションは、前記ミドルウェアの状態に基づいて自サーバの運用状態を判定し、この判定の結果自サーバが運用系サーバであれば、前記共有ディスクと前記ローカルディスク間で監視制御アプリケーション情報を同期させ、前記ミドルウェアの状態から前記共有ディスクの障害を検出した場合に、前記運用系サーバおよび待機系サーバのいずれかの前記共通アドレスを有効化し、前記監視制御アプリケーションのアクセス先を自サーバのローカルディスクに変更し、前記監視制御アプリケーションの機能のうち少なくとも前記監視制御情報の受信に係わる機能を残した縮退運転を開始することを特徴とする監視制御装置が提供される。
このような手段を講じることにより、共有ディスクの監視制御アプリケーション情報は、運用系サーバおよび待機系サーバの各ローカルディスクの情報と予め同期される。この状態から共有ディスクの障害が検出されると、監視制御アプリケーションを縮退運転させるサーバ(縮退運転サーバ)が決定され、縮退運転サーバの共通アドレスが有効化される。よって縮退運転サーバにおいてローカルディスクを用いた監視制御が引き継がれるとともに、少なくとも監視制御情報(例えばTRAP)の受信に係わる機能は残した上で縮退運転が開始される。すなわち、共有ディスクの障害が生じた場合にこの共有ディスクがシステムから切り離され、機能を必要最低限とした縮退運転が開始されるのでシステムダウンに至ることがない。従って共有ディスクの2重障害への耐性を高めることができ、また、共有ディスクとローカルディスクとの間のデータ同期が予めとられているので、短時間での復旧を促すことが可能になる。
この発明によれば、共有ディスクの2重障害への耐性を高めるとともに障害の発生から短時間で復旧可能な監視制御装置を提供することができる。
この発明に係わる監視制御装置の実施の形態を示す機能ブロック図。 共有ディスクおよびローカルディスク間での監視制御アプリケーション情報の更新手順を示すフローチャート。 監視制御アプリケーション情報の更新に係わる別の手順を示すフローチャート。 冗長障害監視アプリケーション203による作用を説明するためのフローチャート。 監視制御アプリケーションの起動および共通IPアドレスの有効化手順を示すフローチャート。 監視制御アプリケーションの停止および共通IPアドレスの無効化手順を示すフローチャート。 両系障害でない状態におけるシステムの動作を示す図。 両系障害が発生し縮退運転となった状態を示す図。
図1は、この発明に係わる監視制御装置の実施の形態を示す機能ブロック図である。図1の監視制御装置MSはIPネットワーク107に接続され、同じくIPネットワーク107に属する被監視装置104から発報されるTRAP(監視制御情報)をもとに、制御対象への監視/制御処理を行う。監視制御装置MSに対するコマンド投入などの操作は、上位サーバ106からIPネットワーク107経由で与えられる。上位サーバ106は各種情報を操作したり表示したりするための表示・操作アプリケーションを備える。上位サーバ106は複数設けられることもある。
監視制御装置MSは、互いに共有ディスク103を共有する運用系サーバ101、待機系サーバ102を備える。運用系サーバ101はローカルディスク1011を備え、待機系サーバ102はローカルディスク1021を備える。運用系サーバ101の共通IPアドレス105宛てに発報されたTRAPは運用系サーバ101により受信された後、上位サーバ106に送られる。上位サーバ106は運用系サーバ101の共通IPアドレス105と通信することでこのTRAPを受信する。
運用系サーバ101、待機系サーバ102はその処理機能としてミドルウェア201、監視制御アプリケーション202、および冗長障害監視アプリケーション203を備える。ただし待機系サーバ102においては監視制御アプリケーション202は機能を休止する。ミドルウェアは、運用系サーバ101と待機系サーバ102の監視および切替え動作を司る。運用系サーバ101、待機系サーバ102は共有ディスク103のデータを共有するが、ミドルウェア201による制御により運用系サーバ101のみが共有ディスク103へのアクセス権を持つ。
ミドルウェア201は、運用系サーバ101と待機系サーバ102との双方に常駐し相互に通信を行い、運用系/待機系サーバの決定、運用系サーバでの共有ディスク103のリザーブ、共通IPアドレスの有効化、あるいは、監視制御アプリケーション202の起動、などを制御する。またミドルウェア201は、運用系サーバ101と待機系サーバ102との切り替え動作を司る。
監視制御アプリケーション202は、被監視装置104から発報されたTRAPの受信および蓄積、あるいは上位サーバ106へのTRAP情報の転送や監視操作画面の提供などの処理を実現する。
冗長障害監視アプリケーション203はOS(Operations System)から起動されるもので、運用系サーバ101と待機系サーバ102との双方に常駐し相互に通信を行う。この通信により、例えば共有ディスク103とローカルディスク1011,1021間の監視制御アプリケーション情報の更新などが行われる。また、運用系サーバ101と待機系サーバ102のそれぞれに常駐するミドルウェアの状態を監視し、相互通信により両系障害の有無を検出する。
両系障害以外の障害の場合、運用系サーバ101に常駐するミドルウェア201は、運用系サーバ障害を検出した後、共通IPアドレスの停止、監視制御アプリケーションの停止、共有ディスク103の解放を行う。その後、待機系サーバ102に常駐のミドルウェアが、共有ディスク103のリザーブ、監視制御アプリケーションの起動、および共通IPアドレス有効化を行うことで、待機系サーバ102で監視制御アプリケーションの運用を開始する。
特に、共有ディスク103の共通部(バスやマザーボード)の故障、あるいは共有ディスクの2重障害が発生すると、待機系サーバ102に常駐のミドルウェアが待機系サーバ102で監視制御アプリケーションを起動すべく制御を開始するが、失敗となる。よって共通IPアドレスが運用系、待機系のいずれにおいても無効、および監視制御アプリケーションが運用系、待機系のいずれにおいても未起動の状態となり、このような状態を両系障害と称する。
この実施形態では、共有ディスク103の障害時に障害箇所を切り離し、監視制御装置が提供する機能を必要最低限に絞って縮退運転を行うようにする。以下にその処理手順につき説明するが、まず、監視制御アプリケーション202が機能するために必要な監視制御アプリケーション情報の、ディスク間での更新処理につき説明する。なお監視制御アプリケーション情報とは、被監視装置のIPアドレス、被監視装置名称、その状態などの情報を含む。
例えば、監視制御アプリケーション情報を運用系サーバ101のみに保持させ、共有ディスク103の監視制御アプリケーション情報が更新されたとき、あるいは監視制御アプリケーションの処理が待機系サーバ102から運用系サーバ101に切替わったときに切替え後の運用系サーバ101の監視制御アプリケーション情報を共有ディスクの情報により更新する方法がある。しかしながらこの方法では、運用系サーバ101を縮退運転サーバとして機能させ、縮退運転への移行前(障害発生前)の監視制御アプリケーションを運用系サーバ101で機能させておく必要がある。また、共有ディスク103の障害時には運用系サーバ101で縮退運転を行うことが可能であるが、共有ディスク障害にさらに運用系サーバ101の障害が重なれば、監視制御アプリケーション情報を参照することができない。そこでこの実施形態では、以下の手順により監視制御アプリケーション情報を更新させる。
図2は、監視制御アプリケーション情報の更新に係わる基本的手順を示すフローチャートである。図2において、冗長障害監視アプリケーションはミドルウェアの状態を例えば定期的に監視し(ステップS201)、その運用状態が運用系サーバであるか待機系サーバであるかを判定する(ステップS202)。
このステップで運用系サーバと判定されれば、共有ディスクとローカルディスク間での監視制御アプリケーション情報の差分の有無が確認される(ステップS203)。差分が有れば、共有ディスク103に保存されている監視制御アプリケーション情報が待機系サーバ102に転送され、待機系サーバ102のローカルディスク1021に保存されている監視制御アプリケーション情報が更新される(ステップS204)。
図3は、監視制御アプリケーション情報の更新に係わる別の手順を示すフローチャートである。図3において、運用系および待機系のそれぞれの冗長障害監視アプリケーションは図2の手順と同様に、ミドルウェアの状態を例えば定期的に監視し(ステップS301)、その運用状態が運用系サーバであるか待機系サーバであるかを判定する(ステップS302)。
このステップで自系が運用系サーバと判定されれば、共有ディスクとローカルディスク間での監視制御アプリケーション情報の差分の有無が確認される(ステップS303)。差分が有れば、共有ディスクの監視制御アプリケーション情報が他系である待機系サーバ102の冗長障害監視アプリケーションに送信され(ステップS304)、待機系サーバ102のローカルディスク1021に保存されている監視制御アプリケーション情報が更新される(ステップS305)。差分が無ければ、他系である待機系サーバ102の冗長監視制御アプリケーションに差分無しが送信される(ステップS306)。
ステップS302で判断された運用状態において、自系が待機系サーバであれば、この待機系サーバの冗長監視制御アプリケーションは、監視制御アプリケーション情報を他系である運用系サーバの冗長監視制御アプリケーションから受信する(ステップS307)。この監視制御アプリケーション情報は、他系である運用系サーバがステップS304またはステップS306にて送信したものである。そして、受信した監視制御アプリケーション情報から、共有ディスクとローカルディスクとの間での監視制御アプリケーション情報の差分の有無が判定される(ステップS308)。差分が有れば、ローカルディスクに記憶されている監視制御アプリケーション情報が差分に基づいて更新される(ステップS309)。
以上の動作により、共有ディスク103、運用系サーバ101のローカルディスク1011、および待機系サーバ102のローカルディスク1021に記憶される監視制御アプリケーション情報の同期をとることができる。この実施形態ではこのようにディスク間の監視制御アプリケーション情報を同期させておくことにより、両系障害時のローカルディスクを使用した縮退運転に備えるようにする。
図4は、冗長障害監視アプリケーション203による作用を説明するためのフローチャートである。冗長障害監視アプリケーション203は、例えば定期的にミドルウェア201の状態を監視し(ステップS401)、その結果に基づいて両系障害の有無を判定する(ステップS402)。
ステップS402で両系障害の発生が判定されれば、運用系サーバ101の冗長障害監視アプリケーションと待機系サーバ102の冗長障害監視アプリケーションとが相互に通信し、片系運転サーバ、すなわち縮退運転するサーバを決定する(ステップS403)。例えば監視制御アプリケーション202が前回起動していなかったサーバが縮退運転サーバとして決定される。なお運用系サーバ、待機系サーバのいずれにおいても監視制御アプリケーション202が起動していなかった場合には、システム起動時の初期待機系を縮退運転サーバとして決定する。
次に、冗長障害監視アプリケーション203は自サーバの状態を判定し(ステップS404)、自サーバが縮退運転サーバ(片系運転サーバ)である場合に、監視制御アプリケーション202を起動し、共通IPアドレス有効化処理を実行する(ステップS405)。
図5は、監視制御アプリケーションの起動および共通IPアドレスの有効化手順を示すフローチャートである。この処理は冗長障害監視アプリケーション203により実行される。冗長障害監視アプリケーション203は、監視制御アプリケーション202のアクセス先を自サーバのローカルディスクに切り替え、そのうえで監視制御アプリケーション202を起動する(ステップS501)。そうして、冗長障害監視アプリケーション203により共通IPアドレスが有効化される(ステップS502)。なおステップS501において、監視制御アプリケーション202のアクセス先はディスクデバイスに限定されるものではなく、サーバに内蔵の半導体メモリなどであっても良い。つまり共通IPアドレスを介して受信した情報(TRAPなど)を、別途設けられる内部メモリに記憶・蓄積するようにしても良い。
図6は、監視制御アプリケーションの停止および共通IPアドレスの無効化手順を示すフローチャートである。この処理手順は両系障害が復旧した後、例えば上位サーバ106からのオペレータによるコマンド投入などにより実施される。図6において、まず監視制御アプリケーション202を停止したのち、監視制御アプリケーション202のアクセス先が共有ディスク103に切り替えられる(ステップS601)。そのうえで共通IPアドレスが無効化される(ステップS602)。この後、ミドルウェア201による制御により運用系サーバ101と待機系サーバ102とが冗長動作を再開する。
図7は、両系障害でない状態におけるシステムの動作を示す図である。この状態では運用系サーバ101、待機系サーバ102の双方におけるミドルウェア201が相互に通信しつつ、運用系サーバ101の監視制御アプリケーション202が主たる機能を果たす。すなわち、被監視装置104から共通IPアドレス105宛てに発報されるTRAP901は、運用系サーバ101の監視制御アプリケーション202により受信され、共有ディスク103に蓄積される。上位サーバ106は運用系サーバ101からTRAP情報902を取得し、表示・操作アプリケーション108の機能により監視操作画面を更新する。これによりTRAP表示や監視操作機能がオペレータに提供される。
図8は、両系障害が発生し縮退運転となった状態を示す図である。すなわち図8の状態では共有ディスク103に障害が発生し、運用系サーバ101、待機系サーバ102のいずれも共有ディスク103にアクセスすることができない。なお図8においては待機系サーバ102を縮退運転サーバとする。
縮退運転時に提供される監視制御アプリケーションの機能としては、例えば(1)TRAP受信のみ、(2)TRAPの履歴検索、(3)被監視装置の状態表示/状態変更/試験機能の実行、あるいは(4)全ての機能、といった、(1)〜(4)の4段階に分けるようにしてもよい。なおこの4段階に縛られることなく、監視制御アプリケーション情報のインプリメントの仕方によって、提供可能な機能や段階は適宜変更することが可能である。また縮退運転時には、被監視装置104の状態表示、回線の閉塞、引き込み、極性反転、ループバックなど、縮退状態となった監視制御アプリケーション202の機能の一部を、上位サーバ106から実施できるようにしても良い。
さて、図8において、共通IPアドレス105は縮退運転サーバ(待機系サーバ102)において有効化されている。よって被監視装置104から発報されるTRAPは待機系サーバ102で受信され、また、上位サーバ106は待機系サーバ102の共通IPアドレス宛てにTRAP情報の取得要求を出す。待機系サーバ102の監視制御アプリケーション202は、予め更新済みのローカルディスク1021上の情報を用いて機能する。すなわち図2、図3の手順により、ローカルディスク1021の情報は共有ディスク103のデータ更新に伴って更新されており、その更新データを用いてTRAPの取得を継続することができる。
縮退運転時には、監視制御アプリケーション202により提供される機能を必要最低限に絞り込み、監視制御アプリケーション情報を限定する。これは、縮退運転が運用系サーバ101と待機系サーバ102との双方が稼動できない非常時の運用形態であることを反映する。
例えば、監視制御アプリケーション情報がない場合には、被監視装置104からのTRAPを受信して上位サーバ106に受け渡すようにすれば良い。また、監視制御アプリケーション情報に被監視装置の設置場所や運用状態の情報が含まれていれば、受信したTRAPにこれらの機能を付加して上位サーバ106に受け渡すようにすれば良い。
オペレータのログイン情報が監視制御アプリケーション情報に含まれていれば、オペレータがシステムにログインしてTRAPの履歴を検索することが可能になる。さらに被監視装置104の識別情報(ID)とIPアドレス情報があれば、ログイン後に被監視装置104の状態表示や状態変更、試験機能の実行などが可能となる。さらに、共有ディスク103に保存されるログなどまで含めて、すべての情報を監視制御アプリケーション情報としてローカルディスクに保持するようにすれば、両系障害発生時においても通常時と同様の機能を提供することが可能になる。
以上の手順をまとめると、この実施形態では下記の処理が実施される。すなわち共有ディスク103の共通部(バスやマザーボード)の故障、あるいは2重障害により共有ディスク103が動作できない故障が発生すると、運用系サーバ101のミドルウェア201は自サーバの共通IPアドレスを停止、監視制御アプリケーション202の停止、および共有ディスク103の解放を行う。また、待機系サーバ102のミドルウェア201は監視制御アプリケーション202の処理を待機系サーバに切替えるための動作を開始する。しかしながらこの状態では共有ディスク103がリザーブできないので、待機系サーバ102のミドルウェア201は切替え不可を検出する。
一方、冗長障害監視アプリケーション203は運用系サーバ101のミドルウェア201の状態と、待機系サーバ102のミドルウェア201の状態とから、切戻しの発生、あるいは両系障害の発生を検出する。さらに、共有ディスク103のマウント状態から共有ディスク障害と判定されれば、運用系サーバ101、待機系サーバ102のうち単体で動作させるサーバ(縮退運転サーバ)を決定する。
縮退運転サーバの冗長障害監視アプリケーション203は、監視制御アプリケーション202のアクセス先を共有ディスク103から自サーバのローカルディスクに変更したうえで、監視制御アプリケーション202の機能の全部または一部を起動し縮退運転を開始したのち、共通IPアドレスを有効化する。縮退運転では、監視制御アプリケーション202は被監視装置104から受信したTRAPをローカルディスク、あるいは内蔵メモリなどに記録する。
その際、共有ディスクに記憶される、TRAP受信に必要な情報(各局の名称、被監視装置の状態、名称、IPアドレスなど)をローカルディスクにコピーし、共有ディスク103のデータ更新時にローカルディスクのデータも併せて更新することでディスク間のデータを同期させておくようにする。縮退運転サーバは、自サーバのローカルディスクを参照し、受信したTRAPに必要な情報を付加する処理を継続する。
以上述べたようにこの実施形態では、運用系サーバ101と待機系サーバ102とが共有ディスク103を介して監視制御アプリケーション情報を共有しつつ被監視装置への監視制御を行う監視制御システムにおいて、運用系サーバ101と待機系サーバ102とに、ミドルウェア201、監視制御アプリケーション202、および冗長障害監視アプリケーション203を設ける。冗長監視制御アプリケーション203は、各サーバのローカルディスク1011、1021に記憶されている監視制御アプリケーション情報と共有ディスク103に記憶されている監視制御アプリケーション情報とを同期させる。また、冗長障害監視アプリケーション203はミドルウェア201の状態を監視し、その結果に基づいて両系障害の有無を判定する。両系障害が発生すると、冗長障害監視アプリケーション203は運用系サーバ101、待機系サーバ102のいずれかを縮退運転サーバとし、監視制御アプリケーション202により提供される機能を必要最低限に絞り込んだ縮退運転を行わせるようにしている。このように、共有ディスクとローカルディスク間で監視制御アプリケーション情報を同期させるようにしているので、両系障害が発生した場合でも、ローカルディスクを使用した縮退運転に直ちに切り替えることが可能になる。従って2重障害への耐性を高めるとともに障害の発生から短時間で復旧可能な監視制御装置を提供することが可能となる。
なお、この発明は上記実施の形態に限定されるものではない。例えば冗長障害監視アプリケーション203による監視制御アプリケーション202の起動、共通IPアドレスの有効化処理、あるいは監視制御アプリケーション202のアクセス先の変更(共有ディスクからローカルディスクへ)などは、オペレータによるマニュアル操作によっても実施可能である。すなわち冗長障害監視アプリケーションが何らかのエラーにより機能していない場合、あるいはオペレータが監視制御アプリケーションの動作不能を判断した場合、さらには障害の発生とは無関係に、オペレータの操作により縮退運転を開始するようにしても良い。
また上記実施形態では、運用系サーバ101および待機系サーバ102をそれぞれ1システムとして説明したが、これに縛られるものではなく、運用系サーバが複数ある場合(1+N冗長構成)にも上記実施形態を適用することができる。このようなケースでは、1つの運用系サーバに障害が発生して待機系サーバにその監視制御アプリケーションの処理が切替わっている状態で、他の運用系サーバに障害が発生しても、その運用系サーバは障害部分を切り離して縮退運転に移行することが可能である。
さらに、この発明は実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
MS…監視制御装置、101…運用系サーバ、102…待機系サーバ、103…共有ディスク、104…被監視装置、105…共通IPアドレス、106…上位サーバ、107…IPネットワーク、201…ミドルウェア、202…監視制御アプリケーション、203…冗長障害監視アプリケーション、1011,1021…ローカルディスク、901…TRAP、902…TRAP情報

Claims (3)

  1. 共有ディスクを用いて情報を共有する運用系サーバと待機系サーバとを備え、前記運用系サーバまたは待機系サーバのいずれかにおいて選択的に有効化される共通アドレスに向け被監視装置から発報される監視制御情報に基づいて前記被監視装置への監視制御を行う監視制御装置において、
    前記運用系サーバおよび待機系サーバの各々は、
    前記共有ディスクとは別に設けられるローカルディスクと、
    前記共有ディスクにアクセスして前記監視制御に係わる処理を担う監視制御アプリケーションと、
    自サーバの運用状態の監視と前記運用系サーバと前記待機系サーバとの冗長切替に係わる処理を担うミドルウェアと、
    このミドルウェアの状態を監視する冗長障害監視アプリケーションとを備え、
    前記冗長障害監視アプリケーションは、
    前記ミドルウェアの状態に基づいて自サーバの運用状態を判定し、
    この判定の結果自サーバが運用系サーバであれば、前記共有ディスクと前記ローカルディスク間で監視制御アプリケーション情報を同期させ、
    前記ミドルウェアの状態から前記共有ディスクの障害を検出した場合に、前記運用系サーバおよび待機系サーバのいずれかの前記共通アドレスを有効化し、
    前記監視制御アプリケーションのアクセス先を自サーバのローカルディスクに変更し、
    前記監視制御アプリケーションの機能のうち少なくとも前記監視制御情報の受信に係わる機能を残した縮退運転を開始することを特徴とする監視制御装置。
  2. 前記運用系サーバおよび待機系サーバの各々は、さらに、前記ローカルディスクとは別途設けられる内部メモリを備え、
    前記監視制御アプリケーションは、受信した監視制御情報を自サーバの内部メモリに記憶することを特徴とする請求項1に記載の監視制御装置。
  3. 前記監視制御アプリケーションは、前記共有ディスクに記憶される前記監視制御情報の受信に要する情報を自サーバのローカルディスクに保持し、前記共有ディスクのデータ更新に伴って前記監視制御情報の受信に要する情報を更新することを特徴とする請求項1に記載の監視制御装置。
JP2009203857A 2009-09-03 2009-09-03 監視制御装置 Pending JP2011054033A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009203857A JP2011054033A (ja) 2009-09-03 2009-09-03 監視制御装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009203857A JP2011054033A (ja) 2009-09-03 2009-09-03 監視制御装置

Publications (1)

Publication Number Publication Date
JP2011054033A true JP2011054033A (ja) 2011-03-17

Family

ID=43942950

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009203857A Pending JP2011054033A (ja) 2009-09-03 2009-09-03 監視制御装置

Country Status (1)

Country Link
JP (1) JP2011054033A (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015141589A (ja) * 2014-01-29 2015-08-03 Necプラットフォームズ株式会社 サーバ装置、サーバシステムおよび障害対策方法
JP2018147510A (ja) * 2018-05-09 2018-09-20 Necプラットフォームズ株式会社 サーバ装置およびサーバシステム
JP2021149133A (ja) * 2020-03-16 2021-09-27 Necソリューションイノベータ株式会社 クラスタリングシステム、クラスタリングシステムの運用方法、及びプログラム
CN115718672A (zh) * 2022-11-22 2023-02-28 支付宝(杭州)信息技术有限公司 应用异常检测方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05127935A (ja) * 1991-10-31 1993-05-25 Mitsubishi Electric Corp 二重系計算機装置
JP2005332057A (ja) * 2004-05-18 2005-12-02 Hitachi Ltd 分散型計算機システムのプロセス管理方法
JP2006107074A (ja) * 2004-10-05 2006-04-20 Fujitsu Ltd 二重化通信制御システム及び通信制御方法
JP2007305059A (ja) * 2006-05-15 2007-11-22 Nec Corp コンピュータシステム、制御コンピュータ、及びプログラム
JP2008077216A (ja) * 2006-09-19 2008-04-03 Toshiba Corp ネットワーク監視方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05127935A (ja) * 1991-10-31 1993-05-25 Mitsubishi Electric Corp 二重系計算機装置
JP2005332057A (ja) * 2004-05-18 2005-12-02 Hitachi Ltd 分散型計算機システムのプロセス管理方法
JP2006107074A (ja) * 2004-10-05 2006-04-20 Fujitsu Ltd 二重化通信制御システム及び通信制御方法
JP2007305059A (ja) * 2006-05-15 2007-11-22 Nec Corp コンピュータシステム、制御コンピュータ、及びプログラム
JP2008077216A (ja) * 2006-09-19 2008-04-03 Toshiba Corp ネットワーク監視方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015141589A (ja) * 2014-01-29 2015-08-03 Necプラットフォームズ株式会社 サーバ装置、サーバシステムおよび障害対策方法
JP2018147510A (ja) * 2018-05-09 2018-09-20 Necプラットフォームズ株式会社 サーバ装置およびサーバシステム
JP2021149133A (ja) * 2020-03-16 2021-09-27 Necソリューションイノベータ株式会社 クラスタリングシステム、クラスタリングシステムの運用方法、及びプログラム
CN115718672A (zh) * 2022-11-22 2023-02-28 支付宝(杭州)信息技术有限公司 应用异常检测方法及装置

Similar Documents

Publication Publication Date Title
JP5243384B2 (ja) アプリケーションステーションで利用される冗長マネージャ
EP3285168B1 (en) Disaster tolerance method and apparatus in active-active cluster system
CN103546914B (zh) 一种hss主备管理的方法及装置
JP5707355B2 (ja) ホットスタンバイ方式によるクライアントサーバシステム
US20100268687A1 (en) Node system, server switching method, server apparatus, and data takeover method
CN101873223A (zh) 基于ip切换的n+m服务备份机制
CN113127270A (zh) 一种基于云计算的3取2安全计算机平台
CN112052127B (zh) 一种用于双机热备环境的数据同步方法及装置
CN102045187B (zh) 一种利用检查点实现高可用性系统的方法和设备
JP2011054033A (ja) 監視制御装置
CN105959145B (zh) 一种适用高可用性集群的并行管理服务器的方法及系统
JP5285045B2 (ja) 仮想環境における故障復旧方法及びサーバ及びプログラム
CN117435405A (zh) 双机热备和故障切换系统和方法
JP5285044B2 (ja) クラスタシステム復旧方法及びサーバ及びプログラム
JP2021061478A (ja) 中継装置、中継システム、及び中継プログラム
JP2009075719A (ja) 冗長構成装置及びその自己診断方法
CN114598594B (zh) 一种多集群下应用故障的处理方法、系统、介质和设备
CN111510336B (zh) 一种网络设备状态管理方法及装置
JP2008204113A (ja) ネットワーク監視システム
JP3325785B2 (ja) 計算機の故障検出・回復方式
JP2006268278A (ja) 遠隔保守コンピュータ保守システム
JP2010136038A (ja) 伝送装置及び冗長構成部の系切替え方法
JP2006229512A (ja) サーバ切替方法,サーバ及びサーバ切替プログラム
CN117785568B (zh) 一种双主双机热备方法及装置
KR101401006B1 (ko) 고가용성 시스템에서 소프트웨어 업데이트를 수행하기 위한 방법 및 장치

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110912

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121018

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121023

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20130402