JP6044434B2 - 情報処理システム，制御方法，および制御プログラム - Google Patents
情報処理システム，制御方法，および制御プログラム Download PDFInfo
- Publication number
- JP6044434B2 JP6044434B2 JP2013086343A JP2013086343A JP6044434B2 JP 6044434 B2 JP6044434 B2 JP 6044434B2 JP 2013086343 A JP2013086343 A JP 2013086343A JP 2013086343 A JP2013086343 A JP 2013086343A JP 6044434 B2 JP6044434 B2 JP 6044434B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- information processing
- information
- state
- terminal
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
- Debugging And Monitoring (AREA)
Description
本件は、情報処理システム，制御方法，および制御プログラムに関する。
従来、冗長化された複数のサーバの各々が運用系又は待機系として機能し、運用系のサーバが制御対象の制御を行なう冗長サーバシステム（情報処理システム）が知られている。
図２７は、冗長サーバシステム１００の構成例を示す図であり、図２８は、図２７に示す０系サーバ３００−１のアプリケーションに障害が発生した場合の運用切替処理の一例を説明する図である。
図２７は、冗長サーバシステム１００の構成例を示す図であり、図２８は、図２７に示す０系サーバ３００−１のアプリケーションに障害が発生した場合の運用切替処理の一例を説明する図である。
図２７に示すように、冗長サーバシステム１００は、Human Machine Interface（ＨＭＩ）端末２００−１及び２００−２、０系サーバ３００−１、１系サーバ３００−２、通信ネットワーク４００、並びにネットワーク５００〜７００をそなえる。以下、ＨＭＩ端末２００−１及び２００−２を区別しない場合には、単にＨＭＩ端末２００という。
ＨＭＩ端末２００は、ネットワーク５００を介して、通信ネットワーク４００に対する制御指示を０系サーバ３００−１及び１系サーバ３００−２に通知するものであり、０系サーバ３００−１及び１系サーバ３００−２に対するクライアントとして機能する。
ＨＭＩ端末２００は、ネットワーク５００を介して、通信ネットワーク４００に対する制御指示を０系サーバ３００−１及び１系サーバ３００−２に通知するものであり、０系サーバ３００−１及び１系サーバ３００−２に対するクライアントとして機能する。
通信ネットワーク４００は、０系サーバ３００−１及び１系サーバ３００−２による制御対象である。通信ネットワーク４００では、伝送装置であるGateway Network Element（ＧＮＥ）４００ａ−１及び４００ａ−２、並びにＮＥ４００ｂ−１及び４００ｂ−２が伝送路を通じてリング状に接続される。
ＮＥ４００ｂ−１及び４００ｂ−２は、それぞれ図示しない他のリングと接続され、他のリングから伝送されてきた情報を、ＧＮＥ４００ａ−１及び４００ａ−２へのいずれかの経路へ選択的に送出（中継）する。ＧＮＥ４００ａ−１及び４００ａ−２は、外部のネットワークからの情報をリング内へ送出する一方、リングを伝送される情報を外部のネットワークへ選択的に分岐させ送出する、アド／ドロップの機能を有する。また、ＧＮＥ４００ａ−１及び４００ａ−２は、ネットワーク７００を介して０系サーバ３００−１及び１系サーバ３００−２と接続される。
ＮＥ４００ｂ−１及び４００ｂ−２は、それぞれ図示しない他のリングと接続され、他のリングから伝送されてきた情報を、ＧＮＥ４００ａ−１及び４００ａ−２へのいずれかの経路へ選択的に送出（中継）する。ＧＮＥ４００ａ−１及び４００ａ−２は、外部のネットワークからの情報をリング内へ送出する一方、リングを伝送される情報を外部のネットワークへ選択的に分岐させ送出する、アド／ドロップの機能を有する。また、ＧＮＥ４００ａ−１及び４００ａ−２は、ネットワーク７００を介して０系サーバ３００−１及び１系サーバ３００−２と接続される。
０系サーバ３００−１及び１系サーバ３００−２は、ネットワーク６００を介して相互に通信可能に接続され、冗長化されたサーバである。０系サーバ３００−１及び１系サーバ３００−２は、ネットワーク７００を介して通信ネットワーク４００を制御（管理）する、クラスタ構成のOperation System（ＯｐＳ）サーバ３００として機能する。
また、０系サーバ３００−１及び１系サーバ３００−２は、それぞれ通信ネットワーク４００の制御に用いる制御情報（例えばＮＥ４００ｂ−１及び４００ｂ−２の設定情報）を格納する構成Database（ＤＢ）をそなえる（図示省略）。
また、０系サーバ３００−１及び１系サーバ３００−２は、それぞれ通信ネットワーク４００の制御に用いる制御情報（例えばＮＥ４００ｂ−１及び４００ｂ−２の設定情報）を格納する構成Database（ＤＢ）をそなえる（図示省略）。
運用系である０系サーバ３００−１は、通信ネットワーク４００の制御に応じて構成ＤＢの更新を行なう。運用系により構成ＤＢが変更されると、変更内容は、所定のタイミングで運用系から待機系である１系サーバ３００−２に伝播して、運用系及び待機系間で同期が行なわれる。なお、通信ネットワーク４００からＯｐＳサーバ３００へ通知される警報又はイベント等の情報は、運用系及び待機系の双方へ送信される（図２７中、破線矢印Ｆ１参照）。従って、警報又はイベント等の情報に関する構成ＤＢの変更内容の伝播は、行なわれない。
０系サーバ３００−１は、運用系として機能し、通信ネットワーク４００に対する制御を行なう。０系サーバ３００−１は、例えば、ＧＮＥ４００ａ−１又は４００ａ−２を介して、ＮＥ４００ｂ−１又は４００ｂ−２に、他のリングから伝送されてきた情報を転送する経路に関する情報を設定する（図２７中、実線矢印Ｆ２参照）。
１系サーバ３００−２は、待機系として機能し、通信ネットワーク４００に対する制御は行なわず、ネットワーク６００を介して、運用系が実行するアプリケーションに障害が発生したか否かを監視する。
１系サーバ３００−２は、待機系として機能し、通信ネットワーク４００に対する制御は行なわず、ネットワーク６００を介して、運用系が実行するアプリケーションに障害が発生したか否かを監視する。
図２８に示す例では、１系サーバ３００−２のアプリケーションは、運用系である０系サーバ３００−１が実行するアプリケーションに異常が発生すると（図２８中（ｉ）参照）、定期的な監視（図２８中（ii）参照）によって、この異常を検出する。
そして、１系サーバ３００−２は、０系サーバ３００−１のアプリケーションに、構成ＤＢ内の運用状態を運用系から待機系に変更する指示を送出する（図２８中（iii）参照）。その後、１系サーバ３００−２は、自系サーバの構成ＤＢ内の運用状態を待機系から運用系に変更する（図２８中（iv）参照）。なお、上述のように、０系サーバ３００−１の構成ＤＢの内容は、１系サーバ３００−２の構成ＤＢに伝播される。
そして、１系サーバ３００−２は、０系サーバ３００−１のアプリケーションに、構成ＤＢ内の運用状態を運用系から待機系に変更する指示を送出する（図２８中（iii）参照）。その後、１系サーバ３００−２は、自系サーバの構成ＤＢ内の運用状態を待機系から運用系に変更する（図２８中（iv）参照）。なお、上述のように、０系サーバ３００−１の構成ＤＢの内容は、１系サーバ３００−２の構成ＤＢに伝播される。
なお、運用状態の切り替えにおいて、先に０系サーバ３００−１の運用状態を待機系に切り替えるのは、同時に２つの系が運用系になることにより、冗長サーバシステム１００（通信ネットワーク４００）に以下のような影響が生じることを避けるためである。つまり、同時に２つの系が運用系になると、２つの系がＮＥ４００ｂ−１及び４００ｂ−２を制御可能になり、予期せぬ制御が行なわれる虞がある。また、２つの系がそれぞれ有する構成ＤＢが個別に変更／削除等されることにより、制御情報の整合性が崩れる虞がある。従って、待機系である１系サーバ３００−２は、先に０系サーバ３００−１の運用状態を待機系に切り替える。
以上の処理により、運用系のアプリケーション障害の発生に伴うＯｐＳサーバ３００における運用状態の切り替えが完了する。
なお、ネットワーク５００、６００、及び７００は、例えばTransmission Control Protocol / Internet Protocol（ＴＣＰ／ＩＰ）等のネットワークである。
なお、ネットワーク５００、６００、及び７００は、例えばTransmission Control Protocol / Internet Protocol（ＴＣＰ／ＩＰ）等のネットワークである。
図２９は、図２７に示す０系サーバ３００−１又は系間のネットワーク６００において障害が発生した場合の例を説明する図である。
図２９に示すように、ＯｐＳサーバ３００では、０系サーバ３００−１においてOperating System（ＯＳ）の異常又はHardware（ＨＷ；ハードウェア）の故障が発生する場合がある（図２９中（ｉ’）参照）。又は、ＯｐＳサーバ３００では、系間のネットワーク６００に通信異常が発生する場合がある（図２９中（ｉ”）参照）。
図２９に示すように、ＯｐＳサーバ３００では、０系サーバ３００−１においてOperating System（ＯＳ）の異常又はHardware（ＨＷ；ハードウェア）の故障が発生する場合がある（図２９中（ｉ’）参照）。又は、ＯｐＳサーバ３００では、系間のネットワーク６００に通信異常が発生する場合がある（図２９中（ｉ”）参照）。
図２９に示すような異常又は故障が発生すると、待機系である１系サーバ３００−２からのアプリケーションの監視において、０系サーバ３００−１は応答を返さない。
しかしながら、１系サーバ３００−２は、０系サーバ３００−１が応答を返さない場合に、０系サーバ３００−１のアプリケーション異常が原因であると判断し、運用切替処理を実施してしまう場合がある。
しかしながら、１系サーバ３００−２は、０系サーバ３００−１が応答を返さない場合に、０系サーバ３００−１のアプリケーション異常が原因であると判断し、運用切替処理を実施してしまう場合がある。
０系サーバ３００−１が応答を返さない原因がＯＳ又はハードウェアの障害である場合、０系サーバ３００−１は、通信ネットワーク４００の制御を行なうことが困難であると考えられる。従って、１系サーバ３００−２が運用系に切り替わっても、２つの系が運用系になることによる上述した影響（ＮＥ４００ｂ−１及び４００ｂ−２への予期せぬ制御、及び、２つの系の構成ＤＢ間の整合性崩壊）が通信ネットワーク４００に生じる可能性は低い。
一方、０系サーバ３００−１が応答を返さない原因が系間のネットワーク６００の通信異常である場合、０系サーバ３００−１は、０系サーバ３００−１自体は正常であり、通信ネットワーク４００の制御を行なうことができる可能性が高い。従って、１系サーバ３００−２が運用系に切り替わり、２つの系が運用系になると、上述した影響が通信ネットワーク４００に生じ得る。
このように、冗長サーバシステム１００では、系間のネットワーク６００で通信障害が発生した場合に、０系サーバ３００−１及び１系サーバ３００−２の双方が運用系になると、通信ネットワーク４００の制御（運用又は保守等）が困難になるという課題がある。
なお、ここまで、制御対象が通信ネットワーク４００であるものとして説明したが、これに限定されるものではない。上述した課題は、制御対象が、冗長化された複数の情報処理装置のうちの一の情報処理装置による所定の処理によって制御される種々のシステム（装置又は／及びネットワーク）である場合にも、同様に生じ得る。
なお、ここまで、制御対象が通信ネットワーク４００であるものとして説明したが、これに限定されるものではない。上述した課題は、制御対象が、冗長化された複数の情報処理装置のうちの一の情報処理装置による所定の処理によって制御される種々のシステム（装置又は／及びネットワーク）である場合にも、同様に生じ得る。
１つの側面では、本発明は、相互に通信可能に接続され冗長化された複数の装置（情報処理装置）をそなえ、一の装置が所定の処理を行なう情報処理システムにおいて、装置間で通信障害が発生した場合に、複数の装置が所定の処理を行なうことを抑止することを目的とする。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
本件の情報処理システムは、相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置と、前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置と、をそなえた情報処理システムであって、前記端末装置は、前記複数の情報処理装置の各々から、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を取得する取得部と、前記複数の情報処理装置の各々に、他の情報処理装置から取得した状態情報を通知する通知部と、をそなえ、前記複数の情報処理装置の各々は、自装置が保持する状態情報と前記端末装置から通知された他の情報処理装置の状態情報とに基づいて、前記自装置が前記所定の処理を行なうか否かを判定する判定部をそなえる。
一実施形態によれば、相互に通信可能に接続され冗長化された複数の装置（情報処理装置）をそなえ、一の装置が所定の処理を行なう情報処理システムにおいて、装置間で通信障害が発生した場合に、複数の装置が所定の処理を行なうことを抑止することができる。
以下、図面を参照して実施の形態を説明する。
〔１〕一実施形態
〔１−１〕冗長サーバシステムについて
図１は、一実施形態に係る冗長サーバシステム（情報処理システム）１の構成例を示す図である。図１に示すように、一実施形態に係る冗長サーバシステム１は、１以上（例えば２つ）のＨＭＩ端末２−１及び２−２、複数（例えば２つ）のサーバとしての０系サーバ３−１及び１系サーバ３−２、通信ネットワーク４、並びにネットワーク５〜７をそなえる。以下、ＨＭＩ端末２−１及び２−２を区別しない場合には、単にＨＭＩ端末２といい、０系サーバ３−１及び１系サーバ３−２を区別しない場合には、単にサーバ３という。
〔１〕一実施形態
〔１−１〕冗長サーバシステムについて
図１は、一実施形態に係る冗長サーバシステム（情報処理システム）１の構成例を示す図である。図１に示すように、一実施形態に係る冗長サーバシステム１は、１以上（例えば２つ）のＨＭＩ端末２−１及び２−２、複数（例えば２つ）のサーバとしての０系サーバ３−１及び１系サーバ３−２、通信ネットワーク４、並びにネットワーク５〜７をそなえる。以下、ＨＭＩ端末２−１及び２−２を区別しない場合には、単にＨＭＩ端末２といい、０系サーバ３−１及び１系サーバ３−２を区別しない場合には、単にサーバ３という。
ＨＭＩ端末（端末装置）２は、ネットワーク５を介して、通信ネットワーク４に対する制御指示をサーバ３に通知するものであり、サーバ３に対するクライアントとして機能する。
また、ＨＭＩ端末２は、０系サーバ３−１及び１系サーバ３−２のうちの少なくとも一つのサーバ３へログイン（接続処理）を行ない、ログインが完了したログイン済みのサーバ３の制御及び監視を行なう。例えば、ＨＭＩ端末２は、運用系のサーバ３が実行する所定の処理の制御や、オペレータ（監視者）による運用系又は待機系のサーバ３の監視を、対象となるサーバ３にログインを行なった上で実行する。
また、ＨＭＩ端末２は、０系サーバ３−１及び１系サーバ３−２のうちの少なくとも一つのサーバ３へログイン（接続処理）を行ない、ログインが完了したログイン済みのサーバ３の制御及び監視を行なう。例えば、ＨＭＩ端末２は、運用系のサーバ３が実行する所定の処理の制御や、オペレータ（監視者）による運用系又は待機系のサーバ３の監視を、対象となるサーバ３にログインを行なった上で実行する。
なお、ＨＭＩ端末２としては、Personal Computer（ＰＣ）やサーバ等の情報処理装置が挙げられる。
通信ネットワーク４は、０系サーバ３−１及び１系サーバ３−２による制御対象であり、図２７に示す通信ネットワーク４００と同様に、伝送装置であるＧＮＥ４ａ−１及び４ａ−２、並びにＮＥ４ｂ−１及び４ｂ−２が伝送路を通じてリング状に接続される。なお、以下、ＧＮＥ４ａ−１及び４ａ−２を区別しない場合には、単にＧＮＥ４ａといい、ＮＥ４ｂ−１及び４ｂ−２を区別しない場合には、単にＮＥ４ｂという。
通信ネットワーク４は、０系サーバ３−１及び１系サーバ３−２による制御対象であり、図２７に示す通信ネットワーク４００と同様に、伝送装置であるＧＮＥ４ａ−１及び４ａ−２、並びにＮＥ４ｂ−１及び４ｂ−２が伝送路を通じてリング状に接続される。なお、以下、ＧＮＥ４ａ−１及び４ａ−２を区別しない場合には、単にＧＮＥ４ａといい、ＮＥ４ｂ−１及び４ｂ−２を区別しない場合には、単にＮＥ４ｂという。
ＮＥ４ｂ−１及び４ｂ−２は、それぞれ図示しない他のリングと接続され、他のリングから伝送されてきた情報を、ＧＮＥ４ａ−１及び４ａ−２へのいずれかの経路へ選択的に送出（中継）する。ＧＮＥ４ａ−１及び４ａ−２は、外部のネットワークからの情報をリング内へ送出する一方、リングを伝送される情報を外部のネットワークへ選択的に分岐させ送出する、アド／ドロップの機能を有する。また、ＧＮＥ４ａは、ネットワーク７を介して０系サーバ３−１及び１系サーバ３−２と接続される。
なお、通信ネットワーク４としては、種々の伝送方式による、電気信号又は光信号等の通信網、又は、電話回線網等の伝送システムが挙げられる。また、制御対象は通信ネットワーク４に限定されるものではなく、制御対象としては、サーバ３のうちの一のサーバ３による所定の処理によって制御される種々のシステムであればよい。
０系サーバ３−１及び１系サーバ３−２は、ネットワーク６を介して相互に通信可能に接続され、冗長化されたサーバである。０系サーバ３−１及び１系サーバ３−２は、ネットワーク７を介して通信ネットワーク４を制御（管理）する、クラスタ構成のＯｐＳサーバ３００として機能する。なお、０系サーバ３−１及び１系サーバ３−２としては、それぞれ、情報処理装置が挙げられる。以下、サーバ３をＯｐＳサーバ３という場合もある。
０系サーバ３−１及び１系サーバ３−２は、ネットワーク６を介して相互に通信可能に接続され、冗長化されたサーバである。０系サーバ３−１及び１系サーバ３−２は、ネットワーク７を介して通信ネットワーク４を制御（管理）する、クラスタ構成のＯｐＳサーバ３００として機能する。なお、０系サーバ３−１及び１系サーバ３−２としては、それぞれ、情報処理装置が挙げられる。以下、サーバ３をＯｐＳサーバ３という場合もある。
０系サーバ３−１は、運用系として機能し、通信ネットワーク４に対する制御を行なう。０系サーバ３−１は、例えば、図２７に示す０系サーバ３００−１と同様に、ＧＮＥ４ａ−１又は４ａ−２を介して、ＮＥ４ｂ−１又は４ｂ−２に、他のリングから伝送されてきた情報を転送する経路に関する情報を設定する。
１系サーバ３−２は、待機系として機能し、自系サーバ（自装置）が待機系の場合には、通信ネットワーク４に対する制御の実行を抑止する。
１系サーバ３−２は、待機系として機能し、自系サーバ（自装置）が待機系の場合には、通信ネットワーク４に対する制御の実行を抑止する。
また、本実施形態に係るＯｐＳサーバ３は、運用系及び待機系に係わらずＨＭＩ端末２を介して相互に監視を行なう。
〔１−２〕全体の動作について
本実施形態に係る冗長サーバシステム１は、以下の（１）〜（３）に示す処理を行なうことで、ＯｐＳサーバ３による相互監視を実現する。
（１） ＨＭＩ端末２が、複数のサーバ３の各々から、サーバ３に係るログイン済みのＨＭＩ端末２の数を含む状態情報を取得する。
（２） ＨＭＩ端末２が、複数のサーバ３の各々に、他系サーバ（他のサーバ）３から取得した状態情報を通知する。
（３） 複数のサーバ３の各々が、自系サーバ（自装置）３が保持する状態情報とＨＭＩ端末２から通知された他系サーバ３の状態情報とに基づいて、自装置が所定の処理を行なうか否かを判定する。
〔１−２〕全体の動作について
本実施形態に係る冗長サーバシステム１は、以下の（１）〜（３）に示す処理を行なうことで、ＯｐＳサーバ３による相互監視を実現する。
（１） ＨＭＩ端末２が、複数のサーバ３の各々から、サーバ３に係るログイン済みのＨＭＩ端末２の数を含む状態情報を取得する。
（２） ＨＭＩ端末２が、複数のサーバ３の各々に、他系サーバ（他のサーバ）３から取得した状態情報を通知する。
（３） 複数のサーバ３の各々が、自系サーバ（自装置）３が保持する状態情報とＨＭＩ端末２から通知された他系サーバ３の状態情報とに基づいて、自装置が所定の処理を行なうか否かを判定する。
なお、上記（１）及び（２）の処理は、処理順序を入れ替えてもよい。
上述した（１）〜（３）の処理により、複数のサーバ３の各々は、冗長化されたサーバ３のネットワーク６が不通の場合も、サーバ３とＨＭＩ端末２との間のネットワーク５を経由して、各サーバ３へのＨＭＩ端末２のログイン数を通知される。従って、各サーバ３は、自系サーバ及び他系サーバ３におけるＨＭＩ端末２のログイン数に基づき、複数のサーバ３のうちのいずれのサーバ３が所定の処理を行なうか否かを、容易に判定することができる。つまり、複数のサーバ３の各々は、自律的に自系サーバが運用系であるか否かを判断することができる。
上述した（１）〜（３）の処理により、複数のサーバ３の各々は、冗長化されたサーバ３のネットワーク６が不通の場合も、サーバ３とＨＭＩ端末２との間のネットワーク５を経由して、各サーバ３へのＨＭＩ端末２のログイン数を通知される。従って、各サーバ３は、自系サーバ及び他系サーバ３におけるＨＭＩ端末２のログイン数に基づき、複数のサーバ３のうちのいずれのサーバ３が所定の処理を行なうか否かを、容易に判定することができる。つまり、複数のサーバ３の各々は、自律的に自系サーバが運用系であるか否かを判断することができる。
従って、本実施形態に係る冗長サーバシステム１によれば、複数のサーバ３間の通信の障害時においても、複数のサーバ３が同時に所定の処理を行なうことを回避できる。
〔１−３〕ＨＭＩ端末及びＯｐＳサーバのハードウェア構成
次に、図２を参照して、ＨＭＩ端末２及びＯｐＳサーバ３のハードウェア構成を説明する。図２は、図１に示すＨＭＩ端末２及びＯｐＳサーバ３のハードウェア構成を示す図である。
〔１−３〕ＨＭＩ端末及びＯｐＳサーバのハードウェア構成
次に、図２を参照して、ＨＭＩ端末２及びＯｐＳサーバ３のハードウェア構成を説明する。図２は、図１に示すＨＭＩ端末２及びＯｐＳサーバ３のハードウェア構成を示す図である。
ＨＭＩ端末２及びＯｐＳサーバ３は、図２に示すように、ＣＰＵ１０ａ及び１０ｂ、メモリ１１ａ及び１１ｂ、記憶部１２ａ及び１２ｂ、インタフェース１３ａ及び１３ｂ、並びに入出力部１４ａ及び１４ｂをそなえる。また、ＨＭＩ端末２及びＯｐＳサーバ３は、図２に示すように、記録媒体１５ａ及び１５ｂ、並びに読取部１６ａ及び１６ｂをさらにそなえる。なお、各ハードウェアの符号の末尾に付されたアルファベットは、“ａ”がＨＭＩ端末２に、“ｂ”がＯｐＳサーバ３に、それぞれ対応する。例えば、ＨＭＩ端末２は、ＣＰＵ１０ａ、メモリ１１ａ、記憶部１２ａ、インタフェース１３ａ、入出力部１４ａ、記録媒体１５ａ、及び読取部１６ａをそなえる。
ＣＰＵ１０ａ及び１０ｂは、それぞれ、対応するメモリ１１ａ及び１１ｂ〜読取部１６ａ及び１６ｂと接続され、種々の制御や演算を行なう処理装置（プロセッサ）である。ＣＰＵ１０ａ又は１０ｂは、メモリ１１ａ又は１１ｂ、記録媒体１５ａ又は１５ｂ、又は図示しないRead Only Memory（ＲＯＭ）等に格納されたプログラムを実行することにより、ＨＭＩ端末２又はＯｐＳサーバ３における種々の機能を実現する。なお、ＣＰＵ１０ａ及び１０ｂに限らず、プロセッサとしては、Application Specific Integrated Circuit（ＡＳＩＣ）やField Programmable Gate Array（ＦＰＧＡ）等の集積回路、Micro Processing Unit（ＭＰＵ）等の電子回路が用いられてもよい。
メモリ１１ａ及び１１ｂは、種々のデータやプログラムを一時的に格納する記憶装置であって、ＣＰＵ１０ａ及び１０ｂがプログラムを実行する際に、データやプログラムを一時的に格納・展開して用いる。なお、メモリ１１ａ及び１１ｂとしては、例えばRandom Access Memory（ＲＡＭ）等の揮発性メモリが挙げられる。
記憶部１２ａ及び１２ｂは、種々のデータやプログラム等を格納するハードウェアである。記憶部１２ａ及び１２ｂとしては、例えばHard Disk Drive（ＨＤＤ）等の磁気ディスク装置、Solid State Drive（ＳＳＤ）等の半導体ドライブ装置、フラッシュメモリ等の不揮発性メモリ等の各種デバイスが挙げられる。
記憶部１２ａ及び１２ｂは、種々のデータやプログラム等を格納するハードウェアである。記憶部１２ａ及び１２ｂとしては、例えばHard Disk Drive（ＨＤＤ）等の磁気ディスク装置、Solid State Drive（ＳＳＤ）等の半導体ドライブ装置、フラッシュメモリ等の不揮発性メモリ等の各種デバイスが挙げられる。
インタフェース１３ａ及び１３ｂは、有線又は無線による、ＨＭＩ端末２−ＯｐＳサーバ３間（ネットワーク５）、２つのＯｐＳサーバ３間（ネットワーク６）、又はＯｐＳサーバ３−通信ネットワーク４間（ネットワーク７）の接続及び通信の制御を行なう。インタフェース１３ａ及び１３ｂとしては、Local Area Network（ＬＡＮ）カード等のネットワークコントローラが挙げられる。
入出力部１４ａ及び１４ｂは、例えばマウスやキーボード等の入力装置、及びディスプレイやプリンタ等の出力装置の少なくとも一方を含むものである。入出力部１４ａ及び１４ｂは、入力装置によりＨＭＩ端末２及びＯｐＳサーバ３のオペレータ（管理者）の操作等による動作命令を受け付ける一方、ＨＭＩ端末２及びＯｐＳサーバ３による監視結果等の処理結果を出力装置に表示（出力）する。
記録媒体１５ａ及び１５ｂは、フラッシュメモリやＲＯＭ等の記憶装置であり、種々のデータやプログラムを記録する。読取部１６ａ及び１６ｂは、光ディスクやUniversal Serial Bus（ＵＳＢ）メモリ等のコンピュータ読取可能な記録媒体１７ａ及び１７ｂに記録されたデータやプログラムを読み出す装置である。
記録媒体１５ａ及び１７ａの少なくとも一方には、本実施形態に係るＨＭＩ端末２の機能を実現する制御プログラムが格納されてもよく、記録媒体１５ｂ及び１７ｂの少なくとも一方には、ＯｐＳサーバ３の機能を実現する制御プログラムが格納されてもよい。例えば、ＣＰＵ１０ａ（１０ｂ）は、記録媒体１５ａ（１５ｂ）、又は読取部１６ａ（１６ｂ）を介して記録媒体１７ａ（１７ｂ）から入力された制御プログラムを、メモリ１１ａ（１１ｂ）等の記憶装置に展開して実行する。これにより、ＣＰＵ１０ａ（１０ｂ）は、ＨＭＩ端末２（ＯｐＳサーバ３）の機能を実現する。
記録媒体１５ａ及び１７ａの少なくとも一方には、本実施形態に係るＨＭＩ端末２の機能を実現する制御プログラムが格納されてもよく、記録媒体１５ｂ及び１７ｂの少なくとも一方には、ＯｐＳサーバ３の機能を実現する制御プログラムが格納されてもよい。例えば、ＣＰＵ１０ａ（１０ｂ）は、記録媒体１５ａ（１５ｂ）、又は読取部１６ａ（１６ｂ）を介して記録媒体１７ａ（１７ｂ）から入力された制御プログラムを、メモリ１１ａ（１１ｂ）等の記憶装置に展開して実行する。これにより、ＣＰＵ１０ａ（１０ｂ）は、ＨＭＩ端末２（ＯｐＳサーバ３）の機能を実現する。
なお、上述した各ハードウェアは、互いにバスで通信可能に接続される。
また、ネットワーク５〜７としては、例えばＴＣＰ／ＩＰネットワーク等のネットワークが挙げられ、専用回線又はインターネット等の公衆回線（公共ネットワーク）とすることができる。なお、ネットワーク５は、後述する理由により、インターネット等の公衆回線（公共ネットワーク）であることが好ましい。
また、ネットワーク５〜７としては、例えばＴＣＰ／ＩＰネットワーク等のネットワークが挙げられ、専用回線又はインターネット等の公衆回線（公共ネットワーク）とすることができる。なお、ネットワーク５は、後述する理由により、インターネット等の公衆回線（公共ネットワーク）であることが好ましい。
さらに、ＨＭＩ端末２、ＯｐＳサーバ３、及び通信ネットワーク４と、各ネットワーク５〜７との間の接続は、それぞれケーブルによる有線接続及び無線接続のいずれの態様で接続されてもよい。有線接続のケーブルとしては、ＬＡＮケーブル、InfiniBand（インフィニバンド（登録商標））等のケーブル、又はFibre Channel（ファイバチャネル）のファイバケーブル等のシリアルケーブルが例として挙げられる。また、無線接続としては、無線ＬＡＮ、又はBluetooth（登録商標）等が例として挙げられる。なお、ＯｐＳサーバ３間の接続は、ネットワーク６に代えて、上述したケーブルによる有線接続及び無線接続のいずれかの態様の接続としてもよい。
なお、ＨＭＩ端末２及びＯｐＳサーバ３の上述したハードウェア構成は例示である。従って、個々のＨＭＩ端末２及びＯｐＳサーバ３内でのハードウェアの増減や分割、ＨＭＩ端末２及びＯｐＳサーバ３の任意の組み合わせでの統合等は、適宜行なわれてもよい。
〔１−４〕ＨＭＩ端末の説明
次に、図３を参照して、ＨＭＩ端末２の詳細を説明する。図３は、図１に示すＨＭＩ端末２の構成例を示す図である。
〔１−４〕ＨＭＩ端末の説明
次に、図３を参照して、ＨＭＩ端末２の詳細を説明する。図３は、図１に示すＨＭＩ端末２の構成例を示す図である。
図３に示すように、ＨＭＩ端末２は、ＯｐＳサーバ側通信部２１、ヘルスチェック部２２、ログイン／ログオフ処理部２３、ログイン状態通知部２４、及び保持部２５をそなえる。
ＯｐＳサーバ側通信部２１は、ＯｐＳサーバ３との通信を行なう。具体的には、ＯｐＳサーバ側通信部２１は、ＯｐＳサーバ３に対する要求送信、ＯｐＳサーバ３からの応答受信、及びＯｐＳサーバ３からの制御結果等のイベントの受信等を行なう。ＯｐＳサーバ側通信部２１は、図２に示すインタフェース１３ａにより実現される。
ＯｐＳサーバ側通信部２１は、ＯｐＳサーバ３との通信を行なう。具体的には、ＯｐＳサーバ側通信部２１は、ＯｐＳサーバ３に対する要求送信、ＯｐＳサーバ３からの応答受信、及びＯｐＳサーバ３からの制御結果等のイベントの受信等を行なう。ＯｐＳサーバ側通信部２１は、図２に示すインタフェース１３ａにより実現される。
ヘルスチェック部２２は、運用系及び待機系のそれぞれのサーバ３に対して定期的に疎通確認のコマンドを送信するものであり、通知部２２ａ及び第１取得部２２ｂをそなえる。
通知部２２ａは、複数のサーバ３の各々に、他系サーバ３から取得した、当該他系サーバ３に係る状態情報を通知する。
通知部２２ａは、複数のサーバ３の各々に、他系サーバ３から取得した、当該他系サーバ３に係る状態情報を通知する。
第１取得部（取得部）２２ｂは、複数のサーバ３の各々から、当該サーバ３に係る状態情報を取得する。
ここで、状態情報は、例えば、サーバ３に係るログイン済みのＨＭＩ端末２の数と、当該サーバ３の動作状態とを含む。
動作状態の例としては、サーバ３が所定の処理を行なうサーバ３である（運用系である）ことを示す“運用”（第１状態）、及び、サーバ３が待機を行なうサーバ３である（待機系である）ことを示す“待機”（第２状態）が挙げられる。また、動作状態の他の例としては、サーバ３に障害が発生したことを示す“不明”（第３状態）が挙げられる。
ここで、状態情報は、例えば、サーバ３に係るログイン済みのＨＭＩ端末２の数と、当該サーバ３の動作状態とを含む。
動作状態の例としては、サーバ３が所定の処理を行なうサーバ３である（運用系である）ことを示す“運用”（第１状態）、及び、サーバ３が待機を行なうサーバ３である（待機系である）ことを示す“待機”（第２状態）が挙げられる。また、動作状態の他の例としては、サーバ３に障害が発生したことを示す“不明”（第３状態）が挙げられる。
また、複数のサーバ３に係る状態情報は、保持部２５の運用切替判断テーブル２５ａに設定される。なお、運用切替判断テーブル２５ａの詳細については、後述する。
通知部２２ａは、アクセス先のサーバ３に通知する、アクセス先のサーバ３以外の他系サーバ３に係る状態情報を、運用切替判断テーブル２５ａから取得する。
ヘルスチェック部２２は、第１所定時間ごとに、通知部２２ａによる他系サーバ３に係る状態情報と、第１取得部２２ｂによるサーバ３への状態情報の取得要求とを含むコマンドを、アクセス先のサーバ３へ疎通確認（ヘルスチェック）として出力する。
通知部２２ａは、アクセス先のサーバ３に通知する、アクセス先のサーバ３以外の他系サーバ３に係る状態情報を、運用切替判断テーブル２５ａから取得する。
ヘルスチェック部２２は、第１所定時間ごとに、通知部２２ａによる他系サーバ３に係る状態情報と、第１取得部２２ｂによるサーバ３への状態情報の取得要求とを含むコマンドを、アクセス先のサーバ３へ疎通確認（ヘルスチェック）として出力する。
ヘルスチェック部２２からの上述した疎通確認のコマンドは、ＯｐＳサーバ側通信部２１を介してアクセス先のＯｐＳサーバ３へ送信される。また、ＯｐＳサーバ３からの疎通確認のコマンドへの応答は、ＯｐＳサーバ側通信部２１を介してヘルスチェック部２２により受信される。
ＯｐＳサーバ３から応答を受け取ると、第１取得部２２ｂは、受信した応答に含まれる状態情報を、運用切替判断テーブル２５ａにＯｐＳサーバ３と対応付けて設定し、運用切替判断テーブル２５ａを更新する。
ＯｐＳサーバ３から応答を受け取ると、第１取得部２２ｂは、受信した応答に含まれる状態情報を、運用切替判断テーブル２５ａにＯｐＳサーバ３と対応付けて設定し、運用切替判断テーブル２５ａを更新する。
各ＯｐＳサーバ３において自律的な運用切替の判断に用いられる運用切替判断テーブル２５ａは、ヘルスチェック部２２による上述した処理（ヘルスチェック処理）により、ＨＭＩ端末２を介して相互に更新される。
また、上述の如く、ＨＭＩ端末２は、１以上、例えば複数そなえられてもよい。ＨＭＩ端末２の数が多くなると、ＨＭＩ端末２の冗長度が高まる。従って、仮にあるＨＭＩ端末２とサーバ３との間に通信障害が発生したとしても、他のＨＭＩ端末２からサーバ３に対するヘルスチェック処理を行なうことができ、ＯｐＳサーバ３において運用切替の判断処理が妨げられる可能性を低減させることができる。
また、上述の如く、ＨＭＩ端末２は、１以上、例えば複数そなえられてもよい。ＨＭＩ端末２の数が多くなると、ＨＭＩ端末２の冗長度が高まる。従って、仮にあるＨＭＩ端末２とサーバ３との間に通信障害が発生したとしても、他のＨＭＩ端末２からサーバ３に対するヘルスチェック処理を行なうことができ、ＯｐＳサーバ３において運用切替の判断処理が妨げられる可能性を低減させることができる。
なお、ＨＭＩ端末２−ＯｐＳサーバ３間の接続は、上述のように、インターネット等の公衆回線であることが好ましい。例えば、ＯｐＳサーバ３間の接続（ネットワーク６）を冗長化する等の手法によっても、ネットワーク６の障害がＯｐＳサーバ３間の運用切替処理に与える影響を低減させることができる。しかし、ネットワーク６が専用回線である場合には、ネットワーク６の冗長化に伴う設備費用が発生する。これに対し、ＨＭＩ端末２及び公衆回線のネットワーク５を介して、ＯｐＳサーバ３間のヘルスチェックが行なわれることにより、既存の設備を用いて、ネットワーク６の障害がＯｐＳサーバ３間の運用切替処理に与える影響を低減させることができる。
ログイン／ログオフ処理部２３は、ＯｐＳサーバ側通信部２１を介して、各サーバ３へのログイン又はログオフ処理を行なう。
具体的には、ログイン／ログオフ処理部２３は、ＨＭＩ端末２が運用系のサーバ３の制御を行なう場合、又は、運用系又は待機系のサーバの監視を行なう場合に、対象となるサーバ３との間でログイン処理（接続処理）を行なう。なお、ログイン処理においては、ＨＭＩ端末２は、ＯｐＳサーバ３へ送信されるログイン要求に、ＨＭＩ端末２の識別ＩＤやＩＰアドレス等のＨＭＩ端末２を識別可能な情報を含める。ＨＭＩ端末２は、ログイン／ログオフ処理部２３によるログイン処理によって取得した所定の資格情報を用いて、対象のサーバ３の制御又は監視を行なう。
具体的には、ログイン／ログオフ処理部２３は、ＨＭＩ端末２が運用系のサーバ３の制御を行なう場合、又は、運用系又は待機系のサーバの監視を行なう場合に、対象となるサーバ３との間でログイン処理（接続処理）を行なう。なお、ログイン処理においては、ＨＭＩ端末２は、ＯｐＳサーバ３へ送信されるログイン要求に、ＨＭＩ端末２の識別ＩＤやＩＰアドレス等のＨＭＩ端末２を識別可能な情報を含める。ＨＭＩ端末２は、ログイン／ログオフ処理部２３によるログイン処理によって取得した所定の資格情報を用いて、対象のサーバ３の制御又は監視を行なう。
また、ログイン／ログオフ処理部２３によるログイン処理において、ログイン先のサーバ３は、ログイン要求の応答に、自系サーバ３に係る状態情報を含め、ＨＭＩ端末２へ送信する。ログイン応答に含まれる状態情報は、ヘルスチェック部２２により、運用切替判断テーブル２５ａに設定される。
さらに、ログイン／ログオフ処理部２３は、運用系のサーバ３の制御や各サーバ３の監視を終了する際に、ログイン中のサーバ３との間でログオフ処理を行ない、所定の資格情報を破棄する。
さらに、ログイン／ログオフ処理部２３は、運用系のサーバ３の制御や各サーバ３の監視を終了する際に、ログイン中のサーバ３との間でログオフ処理を行ない、所定の資格情報を破棄する。
なお、上述したヘルスチェック部２２によるヘルスチェック処理は、アクセス先のサーバ３へログイン済みか否かに係わらず、実行される。
ログイン状態通知部２４は、各サーバ３に対するログイン状態の変化を、運用系及び待機系の双方のサーバ３へ通知する。
例えば、ログイン状態通知部２４は、ログイン／ログオフ処理部２３によるログイン処理が完了すると、ログイン先のサーバ３以外の他系サーバ３に対して、ログイン処理の完了を通知する。なお、ログイン状態通知部２４は、他系サーバ３への通知に、ログイン先のサーバ３から受信したログイン応答に含まれる状態情報を含める。
ログイン状態通知部２４は、各サーバ３に対するログイン状態の変化を、運用系及び待機系の双方のサーバ３へ通知する。
例えば、ログイン状態通知部２４は、ログイン／ログオフ処理部２３によるログイン処理が完了すると、ログイン先のサーバ３以外の他系サーバ３に対して、ログイン処理の完了を通知する。なお、ログイン状態通知部２４は、他系サーバ３への通知に、ログイン先のサーバ３から受信したログイン応答に含まれる状態情報を含める。
また、ログイン状態通知部２４は、ログイン／ログオフ処理部２３によるログオフ処理が完了すると、ログオフをしたサーバ３以外の他系サーバ３に対して、ログオフ処理の完了を通知する。
保持部２５は、後述する運用切替判断テーブル２５ａ（図５参照）を保持する記憶部である。保持部２５は、メモリ１１ａ又は記憶部１２ａ等により実現される。
保持部２５は、後述する運用切替判断テーブル２５ａ（図５参照）を保持する記憶部である。保持部２５は、メモリ１１ａ又は記憶部１２ａ等により実現される。
なお、上述したＨＭＩ端末２の動作は、ＣＰＵ１０ａが制御プログラムをメモリ１１ａに展開して実行することにより実現される。
〔１−５〕ＯｐＳサーバの構成例
次に、図４〜図６を参照して、ＯｐＳサーバ３の構成例を説明する。図４は、図１に示すＯｐＳサーバ３の構成例を示す図である。図５は、図１に示すＨＭＩ端末２及びＯｐＳサーバ３が保持する運用切替判断テーブル２５ａ及び３５ａの一例を示す図であり、図６は、ＯｐＳサーバ３が保持する運用切替判断基準３５ｂの一例を示す図である。
〔１−５〕ＯｐＳサーバの構成例
次に、図４〜図６を参照して、ＯｐＳサーバ３の構成例を説明する。図４は、図１に示すＯｐＳサーバ３の構成例を示す図である。図５は、図１に示すＨＭＩ端末２及びＯｐＳサーバ３が保持する運用切替判断テーブル２５ａ及び３５ａの一例を示す図であり、図６は、ＯｐＳサーバ３が保持する運用切替判断基準３５ｂの一例を示す図である。
図４に示すように、ＯｐＳサーバ３は、ＨＭＩ端末側通信部３１、コマンド処理部３２、通信ネットワーク側通信部３３、ＤＢアクセス部３４、及びデータベース部３５をそなえる。また、ＯｐＳサーバ３は、運用状態判定部３６、他系ＡＰ（アプリケーション）状態監視部３７、及び他系サーバ側通信部３８をさらにそなえる。
ＨＭＩ端末側通信部３１は、ＨＭＩ端末２との通信を行なう。具体的には、ＨＭＩ端末２は、ＨＭＩ端末２からの要求受信、ＨＭＩ端末２に対する応答送信、及びＨＭＩ端末２へのイベントの通知等を行なう。
ＨＭＩ端末側通信部３１は、ＨＭＩ端末２との通信を行なう。具体的には、ＨＭＩ端末２は、ＨＭＩ端末２からの要求受信、ＨＭＩ端末２に対する応答送信、及びＨＭＩ端末２へのイベントの通知等を行なう。
コマンド処理部（設定部）３２は、ＨＭＩ端末２からの要求、及び、通信ネットワーク４からの応答に対する処理を行なう。
具体的には、コマンド処理部３２は、ＨＭＩ端末２からの要求を解析し、通信ネットワーク４のＮＥ４ｂに対する要求（制御要求）を生成し、通信ネットワーク側通信部３３へ出力する。また、コマンド処理部３２は、通信ネットワーク４のＮＥ４ｂからの応答（制御応答）を受信し、ＨＭＩ端末２への応答を生成し、ＨＭＩ端末２へ出力する。
具体的には、コマンド処理部３２は、ＨＭＩ端末２からの要求を解析し、通信ネットワーク４のＮＥ４ｂに対する要求（制御要求）を生成し、通信ネットワーク側通信部３３へ出力する。また、コマンド処理部３２は、通信ネットワーク４のＮＥ４ｂからの応答（制御応答）を受信し、ＨＭＩ端末２への応答を生成し、ＨＭＩ端末２へ出力する。
また、コマンド処理部３２は、制御情報を格納するデータベース部３５に対する、通信ネットワーク４の制御（要求及び応答）に応じたデータの格納又は参照等を行なう。
さらに、コマンド処理部３２は、ＨＭＩ端末２からの要求に応じて、データベース部３５が保持する運用切替判断テーブル３５ａの更新又は参照等を行なう。
具体的には、コマンド処理部３２は、ログイン／ログオフ処理部２３によるログイン処理において、ログイン又はログオフが行なわれると、運用切替判断テーブル３５ａの自系サーバ３に係るログイン済みのＨＭＩ端末２の数を１増加又は１減少させる。
さらに、コマンド処理部３２は、ＨＭＩ端末２からの要求に応じて、データベース部３５が保持する運用切替判断テーブル３５ａの更新又は参照等を行なう。
具体的には、コマンド処理部３２は、ログイン／ログオフ処理部２３によるログイン処理において、ログイン又はログオフが行なわれると、運用切替判断テーブル３５ａの自系サーバ３に係るログイン済みのＨＭＩ端末２の数を１増加又は１減少させる。
また、コマンド処理部３２は、ログイン処理において、運用切替判断テーブル３５ａの自系サーバ３に係る状態情報を参照し、ログイン要求の応答に、自系サーバ３にログインしているＨＭＩ端末２の数及び自系サーバ３の運用状態を含めて、ＨＭＩ端末２へ送信する。
なお、コマンド処理部３２は、ＨＭＩ端末２との間でログイン処理が行なわれると、当該ＨＭＩ端末２を特定する情報を、データベース部３５のログイン情報３５ｃに設定し、ログオフ処理が行なわれると、当該情報を、ログイン情報３５ｃから削除する。
なお、コマンド処理部３２は、ＨＭＩ端末２との間でログイン処理が行なわれると、当該ＨＭＩ端末２を特定する情報を、データベース部３５のログイン情報３５ｃに設定し、ログオフ処理が行なわれると、当該情報を、ログイン情報３５ｃから削除する。
また、ＨＭＩ端末２の障害やＨＭＩ端末２とネットワーク５との間の通信障害等により、ログオフ処理が行なわれずにＨＭＩ端末２がＯｐＳサーバ３にアクセスできなくなる場合がある。そこで、コマンド処理部３２は、自系サーバ３に係るログイン済みのＨＭＩ端末２から、ヘルスチェック処理の実行周期である第１所定時間よりも長い第２所定時間の間、アクセスがなかった場合にも、当該ＨＭＩ端末２を特定する情報を、ログイン情報３５ｃから削除する。また、コマンド処理部３２は、運用切替判断テーブル３５ａの自系サーバ３に係る状態情報に含まれるログイン済みのＨＭＩ端末２の数を１減少させる。
なお、コマンド処理部３２は、自系サーバ３との間でログイン処理が行なわれていない（未ログインの）ＨＭＩ端末２から、第２所定時間の間、ヘルスチェックによるアクセスがなかった場合、当該ＨＭＩ端末２との間でログイン済みの他系サーバ３を特定する。例えば、コマンド処理部３２は、サーバ３が２つである場合、ログイン情報３５ｃを参照して自系サーバ３にログインしていないＨＭＩ端末２は、他系サーバ３にログイン済みと判断する。そして、コマンド処理部３２は、運用切替判断テーブル３５ａの他系サーバ３に係る状態情報に含まれるログイン済みのＨＭＩ端末２の数を１減少させる。
ここで、コマンド処理部３２は、他系サーバ３に係る状態情報に含まれるログイン済みのＨＭＩ端末２の数を１減少させても、ＨＭＩ端末２による定期的なヘルスチェック処理によって、受信する他系サーバ３に係る状態情報により上書きされる。しかし、ＯｐＳサーバ３では、運用切替の正確な判断のため、できるだけ運用切替判断テーブル３５ａを最新の状態にしておくことが好ましい。従って、コマンド処理部３２は、他系サーバ３に係る状態情報に含まれるログイン済みのＨＭＩ端末２の数が１減少したと認識すると、運用切替判断テーブル３５ａの更新を行なうのである。
また、コマンド処理部３２は、ヘルスチェック部２２によるヘルスチェック処理において、通知部２２ａから受信した他系サーバ３に係る状態情報を、運用切替判断テーブル３５ａへ設定する。なお、通知部２２ａから受信した他系サーバ３に係る状態情報には、他系サーバ３に係るログイン済みのＨＭＩ端末２の数及び他系サーバ３の運用状態が含まれる。
さらに、コマンド処理部３２は、ヘルスチェック処理において、ＯｐＳサーバ３からの疎通確認のコマンドへの応答に、自系サーバ３にログインしているＨＭＩ端末２の数及び自系サーバ３の運用状態を含めて、ＨＭＩ端末２へ送信する。
以上のように、コマンド処理部３２は、ＨＭＩ端末２からの要求に応じて運用切替判断テーブル３５ａの更新等を行なうことで、ＯｐＳサーバ３における運用切替の判断に用いられる運用切替判断テーブル３５ａを、最新の状態に維持することができる。これにより、後述する運用状態判定部３８は、最新の運用切替判断テーブル３５ａを用いて運用切替の有無を判断することができ、０系サーバ３−１及び１系サーバ３−２が両系とも運用系になることを防止できる。
以上のように、コマンド処理部３２は、ＨＭＩ端末２からの要求に応じて運用切替判断テーブル３５ａの更新等を行なうことで、ＯｐＳサーバ３における運用切替の判断に用いられる運用切替判断テーブル３５ａを、最新の状態に維持することができる。これにより、後述する運用状態判定部３８は、最新の運用切替判断テーブル３５ａを用いて運用切替の有無を判断することができ、０系サーバ３−１及び１系サーバ３−２が両系とも運用系になることを防止できる。
通信ネットワーク側通信部３３は、通信ネットワーク４との通信を行なう。具体的には、通信ネットワーク側通信部３３は、ＮＥ４ｂへの要求送信、及び、ＮＥ４ｂからの応答受信等を行なう。また、通信ネットワーク側通信部３３は、通信ネットワーク４から運用系及び待機系の双方へ通知される警報又はイベント等の情報を受信する。
ＤＢアクセス部３４は、データベース部３５へのデータの格納又は参照等を行なうものであり、コマンド処理部３２又は運用状態判定部３６からの要求に応じて、データベース部３５が保持する制御情報、運用切替判断テーブル３５ａ、又は運用切替判断基準３５ｂの更新又は参照等を行なう。
ＤＢアクセス部３４は、データベース部３５へのデータの格納又は参照等を行なうものであり、コマンド処理部３２又は運用状態判定部３６からの要求に応じて、データベース部３５が保持する制御情報、運用切替判断テーブル３５ａ、又は運用切替判断基準３５ｂの更新又は参照等を行なう。
データベース部（格納部）３５は、種々のデータを格納するものであり、通信ネットワーク４の制御情報（例えばＮＥ４ｂの設定情報）のほか、運用切替判断テーブル３５ａ、運用切替判断基準３５ｂ、及びログイン情報３５ｃを格納する。データベース部３５は、メモリ１１ｂ又は記憶部１２ｂ等により実現される。
ここで、図５及び図７を参照して、運用切替判断テーブル２５ａ及び３５ａ、並びに、ログイン情報３５ｃについて説明する。なお、図６に示す運用切替判断基準３５ｂについては後述する。
ここで、図５及び図７を参照して、運用切替判断テーブル２５ａ及び３５ａ、並びに、ログイン情報３５ｃについて説明する。なお、図６に示す運用切替判断基準３５ｂについては後述する。
運用切替判断テーブル２５ａ及び３５ａは、複数のＯｐＳサーバ３の各々において、自系サーバ３が運用系になるか否かを判断するために用いられる情報である。例えば、ＨＭＩ端末２が保持する運用切替判断テーブル２５ａには、ヘルスチェック処理及びログイン／ログオフ処理により取得した各サーバ３の状態情報が含まれる。また、０系サーバ３−１が保持する運用切替判断テーブル３５ａには、自系サーバ３で更新した自系サーバ３の状態情報と、ＨＭＩ端末２から通知された１系サーバ３−２の状態情報とが含まれる。
図５に例示するように、運用切替判断テーブル２５ａ及び３５ａは、項目名として、系情報、０系及び１系のそれぞれの運用状態、並びに、自系及び他系のそれぞれのサーバ３へのＨＭＩ端末２のログイン数を含む。
系情報は、自系サーバ３が系及び１系のいずれであるかを示す情報であり、“０系”又は“１系”が設定される。
系情報は、自系サーバ３が系及び１系のいずれであるかを示す情報であり、“０系”又は“１系”が設定される。
０系運用状態及び１系運用状態（動作状態）は、それぞれ、０系及び１系のサーバ３の運用状態を示す状態であり、“運用”、“待機”、又は、“不明”が設定される。
自系サーバログイン数及び他系サーバログイン数（ログイン数）は、それぞれ、自系及び他系のサーバにログインしているＨＭＩ端末２の数を示す情報であり、“０”以上の整数が設定される。
自系サーバログイン数及び他系サーバログイン数（ログイン数）は、それぞれ、自系及び他系のサーバにログインしているＨＭＩ端末２の数を示す情報であり、“０”以上の整数が設定される。
なお、ＨＭＩ端末２は、各サーバ３から受信した状態情報を、１つの運用切替判断テーブル２５ａで管理してもよいし、サーバ３ごとの運用切替判断テーブル２５ａで管理してもよい。
１つの運用切替判断テーブル２５ａで管理する場合、ＨＭＩ端末２は、各サーバから受信した状態情報を、１つの運用切替判断テーブル２５ａに設定する。この場合、運用切替判断テーブル２５ａはサーバ３間で共通となるため、系情報は省略してもよい。
１つの運用切替判断テーブル２５ａで管理する場合、ＨＭＩ端末２は、各サーバから受信した状態情報を、１つの運用切替判断テーブル２５ａに設定する。この場合、運用切替判断テーブル２５ａはサーバ３間で共通となるため、系情報は省略してもよい。
なお、運用切替判断テーブル２５ａはヘルスチェック部２２により、運用切替判断テーブル３５ａはコマンド処理部３２又は運用状態判定部３６により、それぞれ更新され、最新の状態に保たれる。
ログイン情報（接続情報）３５ｃは、自系サーバ３にログイン済みのＨＭＩ端末２を特定する情報を含む。
ログイン情報（接続情報）３５ｃは、自系サーバ３にログイン済みのＨＭＩ端末２を特定する情報を含む。
図７に例示するように、ログイン情報３５ｃは、ログイン済みのＨＭＩ端末２を識別する情報の一例として、ＨＭＩ端末２のＩＤを含む。なお、ログイン情報３５ｃには、ログイン日時等の情報が含まれてもよい。
図４の説明に戻り、他系サーバ側通信部３６は、他系のサーバ３との通信を行なう。具体的には、他系サーバ側通信部３６は、他系サーバ３のアプリケーションの状態監視に係る要求の送受信等を行なう。また、運用系のサーバ３側における他系サーバ側通信部３６は、データベース部３５内の制御情報が更新されると、変更内容を、所定のタイミングで他系サーバ３に送信し、運用系及び待機系間で制御情報の同期を行なう。
図４の説明に戻り、他系サーバ側通信部３６は、他系のサーバ３との通信を行なう。具体的には、他系サーバ側通信部３６は、他系サーバ３のアプリケーションの状態監視に係る要求の送受信等を行なう。また、運用系のサーバ３側における他系サーバ側通信部３６は、データベース部３５内の制御情報が更新されると、変更内容を、所定のタイミングで他系サーバ３に送信し、運用系及び待機系間で制御情報の同期を行なう。
他系ＡＰ状態監視部３７は、他系サーバ側通信部３６を介して、他系サーバ３に対してアプリケーションが正常に動作しているか否かを、系間のネットワーク６の通信状態を含めて定期的に監視する。具体的には、他系ＡＰ状態監視部３７は、定期的に、他系サーバ３に対して他系ＡＰ状態の監視要求を送信する。また、他系ＡＰ状態監視部３７は、他系サーバ３から監視要求を受信すると、自系サーバ３のアプリケーションの起動状態を確認し、起動有無を応答として他系サーバ３へ送信する。
運用状態判定部（判定部）３８は、運用切替判断テーブル３５ａの情報と、他系ＡＰ状態監視部３７による他系サーバ３のアプリケーションの監視結果とに基づいて、自系サーバ３の運用状態を切り替えるか否かを、第３所定時間ごとに判断する。なお、第３所定時間は、任意の時間とすることができる。例えば、第３所定時間は、ヘルスチェック処理の実行周期と同程度としてもよいし、それよりも短い又は長い時間であってもよい。
ここで、運用状態判定部３８による、運用切替の判断処理を、図６に示す運用切替判断基準３５ｂとともに説明する。
運用切替判断基準３５ｂは、複数のＯｐＳサーバ３の各々において、運用切替判断テーブル３５ａの更新の際に運用状態判定部３８により参照される情報である。なお、複数のサーバ３には、それぞれ同一の運用切替判断基準３５ｂが格納される。
運用切替判断基準３５ｂは、複数のＯｐＳサーバ３の各々において、運用切替判断テーブル３５ａの更新の際に運用状態判定部３８により参照される情報である。なお、複数のサーバ３には、それぞれ同一の運用切替判断基準３５ｂが格納される。
図６に例示するように、運用切替判断基準３５ｂは、０系及び１系の運用状態、並びに、ＨＭＩ端末２のログイン数に対応付けて、運用切替を行なうか否かを示す情報が設定される。
運用状態判定部３８は、運用切替判断テーブル３５ａを参照し、複数のサーバ３の運用状態が“運用”であると判断した場合、運用状態が“運用”であるサーバ３の中から、ログイン済みのＨＭＩ端末２の数に基づいて、運用状態を切り替える。
運用状態判定部３８は、運用切替判断テーブル３５ａを参照し、複数のサーバ３の運用状態が“運用”であると判断した場合、運用状態が“運用”であるサーバ３の中から、ログイン済みのＨＭＩ端末２の数に基づいて、運用状態を切り替える。
例えば、運用状態判定部３８は、図６のＡ１に示すように、運用状態が“運用”である０系サーバ３−１及び１系サーバ３−２のうち、いずれか一方のサーバ３みがログイン数１以上である場合、当該一方のサーバ３が“運用”であると判定する。また、運用状態判定部３８は、他系サーバ３が“待機”であると判定する。
また、運用状態判定部３８は、図６のＡ２に示すように、運用状態が“運用”である０系サーバ３−１及び１系サーバ３−２の双方がログイン数１以上である場合、予め定めたサーバ３（例えば０系サーバ３−１）が“運用”であると判定する。また、運用状態判定部３８は、１系サーバ３−２が“待機”であると判定する。
また、運用状態判定部３８は、図６のＡ２に示すように、運用状態が“運用”である０系サーバ３−１及び１系サーバ３−２の双方がログイン数１以上である場合、予め定めたサーバ３（例えば０系サーバ３−１）が“運用”であると判定する。また、運用状態判定部３８は、１系サーバ３−２が“待機”であると判定する。
そして、運用状態判定部３８は、判定した０系及び１系運用状態を運用切替判断テーブル３５ａに設定し、更新後の運用切替判断テーブル３５ａに基づいて、自系サーバ３が運用系であるか否かを判定する。
また、ＯｐＳサーバ３が実行する通信ネットワーク４の制御用のアプリケーションは、運用状態判定部３８による判定結果に従って、自系サーバ３を運用系又は待機系として動作させる。
また、ＯｐＳサーバ３が実行する通信ネットワーク４の制御用のアプリケーションは、運用状態判定部３８による判定結果に従って、自系サーバ３を運用系又は待機系として動作させる。
このように、運用状態とログイン済みのＨＭＩ端末２の数とに基づく運用切替により、ＯｐＳサーバ３は、運用状態が“運用”のサーバ３が複数存在する状態でも、運用状態が“運用”のサーバ３を１つに修正（復旧）することができる。
例えば、冗長サーバシステム１において、サーバ３の系間のネットワーク６に通信異常、且つ、ＨＭＩ端末２とサーバ３との間に通信異常が発生した場合、オペレータ等により、待機系のサーバ３が運用系に切り替えられ、結果的に複数のサーバ３が運用系になる場合がある。この場合においても、各サーバ３は、通信異常の復旧後に、ヘルスチェック処理により互いに相手サーバ３も運用系であることを認識すると、上述した運用切替により、自律的に正常状態（一方が運用系、残りが待機系）に遷移することができる。なお、全てのＨＭＩ端末２とサーバ３との間に通信異常が発生した場合でも、同様の効果を奏することができる。
例えば、冗長サーバシステム１において、サーバ３の系間のネットワーク６に通信異常、且つ、ＨＭＩ端末２とサーバ３との間に通信異常が発生した場合、オペレータ等により、待機系のサーバ３が運用系に切り替えられ、結果的に複数のサーバ３が運用系になる場合がある。この場合においても、各サーバ３は、通信異常の復旧後に、ヘルスチェック処理により互いに相手サーバ３も運用系であることを認識すると、上述した運用切替により、自律的に正常状態（一方が運用系、残りが待機系）に遷移することができる。なお、全てのＨＭＩ端末２とサーバ３との間に通信異常が発生した場合でも、同様の効果を奏することができる。
ところで、図２９に示す例では、運用切替の有無の判断及び切替処理は、図２８に示すように１系サーバ３００−２により自律的に行なわれるのではなく、ＨＭＩ端末２００を介してオペレータ（管理者）により手動で行なわれる。しかしながら、運用切替処理がオペレータにより手動で行なわれる場合、１系サーバ３００−２により行なわれる場合と比べ、新たな運用系が動作可能になるまでに時間がかかる。ＮＥ４００ｂ−１又は４００ｂ−２に対する制御は、運用系により行なわれるため、新たな運用系が動作可能になるまでは、通信ネットワーク４００内のＮＥ４００ｂ−１又は４００ｂ−２等に対する運用又は保守等の制御が制限されることになる。
これに対し、上述した運用状態とログイン済みのＨＭＩ端末２の数とに基づく運用切替によれば、運用切替が各サーバ３により自律的に行なわれるため、図２９に示す例と比べ、通信ネットワーク４の制御に係る不都合を抑制することができる。
なお、運用状態判定部３８は、運用状態が“運用”である０系サーバ３−１及び１系サーバ３−２の双方がログイン数１以上である場合、ログイン数が多い方のサーバ３が“運用”であると判定してもよい。
なお、運用状態判定部３８は、運用状態が“運用”である０系サーバ３−１及び１系サーバ３−２の双方がログイン数１以上である場合、ログイン数が多い方のサーバ３が“運用”であると判定してもよい。
また、運用状態判定部３８は、運用状態が“運用”であるか否かに係わらず、自系サーバ３にログイン済みのＨＭＩ端末２の数と他系サーバ３にログイン済みのＨＭＩ端末２の数とに基づいて、自系サーバ３が運用系であるか否かを判定する。この判定は、他系ＡＰ状態監視部３７により、他系サーバ３のアプリケーション障害又はネットワーク６の不通（通信障害を含む）が発生したことが検出されたときに行なわれることが好ましい。
具体的には、運用状態判定部３８は、他系ＡＰ状態監視部３７による監視によって障害が検出されると、運用切替判断テーブル３５ａを参照し、自系サーバ３及び他系サーバ３に係るログイン済みのＨＭＩ端末２の数を参照する。そして、運用状態判定部３８は、自系サーバ３の方が他系サーバ３よりもログイン済みのＨＭＩ端末２の数が多い場合には、自系サーバ３が“運用”であると判定し、少ない場合には、自系サーバ３が“待機”であると判定する。
なお、他系サーバ３のアプリケーションに障害が生じると、他系サーバ３に係るＨＭＩ端末２のログイン数は０になるため、運用状態判定部３８は、自系サーバ３に係るログイン数が１以上であれば、上記判定により、自系サーバを運用系に切り替えることができる。
このように、ログイン済みのＨＭＩ端末２の数に基づく運用切替により、ネットワーク６に通信障害が発生した場合でも、複数のサーバ３が同時に運用系になることを回避できる。また、ＨＭＩ端末２の障害やＨＭＩ端末２とネットワーク５との間の通信障害が発生した場合でも、運用系に複数のＨＭＩ端末２がログインしていれば、オペレータは、ログイン済みの他のＨＭＩ端末２を介して運用系に制御指示を送信することができる。
このように、ログイン済みのＨＭＩ端末２の数に基づく運用切替により、ネットワーク６に通信障害が発生した場合でも、複数のサーバ３が同時に運用系になることを回避できる。また、ＨＭＩ端末２の障害やＨＭＩ端末２とネットワーク５との間の通信障害が発生した場合でも、運用系に複数のＨＭＩ端末２がログインしていれば、オペレータは、ログイン済みの他のＨＭＩ端末２を介して運用系に制御指示を送信することができる。
さらに、運用状態判定部３８は、自系サーバ３に係るログイン済みのＨＭＩ端末２の数が１以上、自系サーバ３の運用状態が“待機”、且つ、他系サーバ３の運用状態が“不明”である場合、自系サーバ３の運用状態が“運用”であると判定する（図６のＢ参照）。
ここで、他系サーバ３の運用状態が“不明”とは、他系サーバ３に係るログイン済みのＨＭＩ端末２の数が０であり、且つ、他系ＡＰ状態監視部３７が他系サーバ３との通信で異常を検出した場合に、運用状態判定部３８により設定される状態である。なお、自系サーバ３の運用状態が“不明”とは、自系サーバ３に係るログイン済みのＨＭＩ端末２の数が０であり、且つ、他系ＡＰ状態監視部３７が他系サーバ３との通信で異常を検出した場合に、運用状態判定部３８により設定される状態である。
ここで、他系サーバ３の運用状態が“不明”とは、他系サーバ３に係るログイン済みのＨＭＩ端末２の数が０であり、且つ、他系ＡＰ状態監視部３７が他系サーバ３との通信で異常を検出した場合に、運用状態判定部３８により設定される状態である。なお、自系サーバ３の運用状態が“不明”とは、自系サーバ３に係るログイン済みのＨＭＩ端末２の数が０であり、且つ、他系ＡＰ状態監視部３７が他系サーバ３との通信で異常を検出した場合に、運用状態判定部３８により設定される状態である。
図６のＢに示すように、自系サーバ３の運用状態が“待機”の場合に、他系サーバ３との通信で障害が発生しても、運用状態判定部３８は、運用切替判断テーブル３５ａに基づいて、自系サーバ３の運用状態が“運用”であると判定することができる。従って、ＯｐＳサーバ３は、運用系のサーバ３の停止時間を短時間に抑えることができ、通信ネットワーク４の制御に係る不都合を抑制することができる。
なお、図６のＢに示す判定及び運用切替後、運用切替判断テーブル３５ａは、自系サーバ３の運用状態が“運用”、且つ、他系サーバ３の運用状態が“不明”を示す。この状態で、他系ＡＰ状態監視部３７が他系サーバ３との通信で異常を検出しなくなると、つまり通信障害が復旧すると、運用状態判定部３８は、他系サーバ３の動作状態が“待機”であると判定する。
また、運用状態判定部３８は、図６のＣに示すように、自系サーバ３及び他系サーバ３のうちのいずれか一方のサーバ３の運用状態が“運用”である場合には、既に運用系が確定しているため、運用切替を抑止する。
さらに、運用状態判定部３８は、図６のＤに示すように、全てのサーバ３の運用状態が“待機”であると判断した場合には、ログイン済みのＨＭＩ端末２の数に基づいて、図６のＡ１及びＡ２と同様に、いずれかのサーバ３の運用状態が“運用”であると判定する。
さらに、運用状態判定部３８は、図６のＤに示すように、全てのサーバ３の運用状態が“待機”であると判断した場合には、ログイン済みのＨＭＩ端末２の数に基づいて、図６のＡ１及びＡ２と同様に、いずれかのサーバ３の運用状態が“運用”であると判定する。
また、運用状態判定部３８は、図６のＥに示すように、全てのサーバ３の運用状態が“不明”である場合には、いずれのサーバ３にもＨＭＩ端末２がログインしていないため、運用切替を抑止する。この場合、ＯｐＳサーバ３は、少なくとも１つのサーバ３の運用状態が“不明”から“運用”又は“待機”に切り替わるまで、通信ネットワーク４の制御を抑止する。
以上のように、一実施形態に係る冗長サーバシステム１によれば、ＯｐＳサーバ３間のネットワーク６が不通の場合であっても、サーバ３−ＨＭＩ端末２間のネットワーク５を経由して、サーバ３の運用状態を自律的に待機系から運用系へ切り替えることができる。
従って、障害により運用系サーバ３が存在しない状態でも、速やかにサーバ３を運用系に切り替えることができ、ＯｐＳサーバ３による通信ネットワーク４の運用又は保守の再開までの時間を短縮することができる。
従って、障害により運用系サーバ３が存在しない状態でも、速やかにサーバ３を運用系に切り替えることができ、ＯｐＳサーバ３による通信ネットワーク４の運用又は保守の再開までの時間を短縮することができる。
また、ＨＭＩ端末２が複数のサーバ３に接続可能であれば、確実に運用切替の判断を行なうことができ、複数のサーバ３が運用系になることを抑制することができる。
〔１−６〕動作例
次に、図８〜図１４を参照して、上述の如く構成された一実施形態に係る冗長サーバシステム１（ＨＭＩ端末２及びＯｐＳサーバ３）の動作例を説明する。なお、以下の説明では、ログイン先のサーバ３又は自系サーバ３が０系サーバ３−１であるものとして説明する。ログイン先のサーバ３又は自系サーバ３が１系サーバ３−２である場合には、自系（０系）と他系（１系）とを入れ替えればよい。
〔１−６〕動作例
次に、図８〜図１４を参照して、上述の如く構成された一実施形態に係る冗長サーバシステム１（ＨＭＩ端末２及びＯｐＳサーバ３）の動作例を説明する。なお、以下の説明では、ログイン先のサーバ３又は自系サーバ３が０系サーバ３−１であるものとして説明する。ログイン先のサーバ３又は自系サーバ３が１系サーバ３−２である場合には、自系（０系）と他系（１系）とを入れ替えればよい。
〔１−６−１〕全体の動作例
はじめに、図８及び図９を参照して、ＨＭＩ端末２及びＯｐＳサーバ３の全体の処理を説明する。図８及び図９は、それぞれ、図１に示すＨＭＩ端末２及びＯｐＳサーバ３の全体の処理を説明するフローチャートである。
ＨＭＩ端末２の処理では、図８に示すように、通信ネットワーク４の制御に先立ち、ＨＭＩ端末２により、ＯｐＳサーバ３へのログイン処理が行なわれる（ステップＳ１；図１０のステップＳ１１〜Ｓ１９）。
はじめに、図８及び図９を参照して、ＨＭＩ端末２及びＯｐＳサーバ３の全体の処理を説明する。図８及び図９は、それぞれ、図１に示すＨＭＩ端末２及びＯｐＳサーバ３の全体の処理を説明するフローチャートである。
ＨＭＩ端末２の処理では、図８に示すように、通信ネットワーク４の制御に先立ち、ＨＭＩ端末２により、ＯｐＳサーバ３へのログイン処理が行なわれる（ステップＳ１；図１０のステップＳ１１〜Ｓ１９）。
具体的には、ＨＭＩ端末２により、ログイン先（例えば０系サーバ３−１）に対してログイン処理が行なわれる。ログイン処理では、ＨＭＩ端末２により、運用切替判断テーブル３５ａに対して、０系サーバ３−１へのログイン数の更新（加算）、並びに、０系サーバ３−１の運用状態及びログイン数の参照が行なわれる（ステップＳ１−１）。
また、ＨＭＩ端末２により、１系サーバ３−２の運用切替判断テーブル３５ａに対して、０系サーバ３−１の運用状態及びログイン数の更新が行なわれる（ステップＳ１−２）。
また、ＨＭＩ端末２により、１系サーバ３−２の運用切替判断テーブル３５ａに対して、０系サーバ３−１の運用状態及びログイン数の更新が行なわれる（ステップＳ１−２）。
また、ＨＭＩ端末２により、ＯｐＳサーバ３へのヘルスチェック処理が行なわれる（ステップＳ２；図１１のステップＳ２１〜Ｓ２６）。
具体的には、ＨＭＩ端末２により、０系サーバ３−１の運用切替判断テーブル３５ａに対して、１系サーバ３−２の運用状態及びログイン数の更新が行なわれる。また、ＨＭＩ端末２により、０系サーバ３−１の運用切替判断テーブル３５ａから、０系サーバ３−１の運用状態及びログイン数の参照が行なわれる（ステップＳ２−１）。
具体的には、ＨＭＩ端末２により、０系サーバ３−１の運用切替判断テーブル３５ａに対して、１系サーバ３−２の運用状態及びログイン数の更新が行なわれる。また、ＨＭＩ端末２により、０系サーバ３−１の運用切替判断テーブル３５ａから、０系サーバ３−１の運用状態及びログイン数の参照が行なわれる（ステップＳ２−１）。
同様に、ＨＭＩ端末２により、１系サーバ３−２の運用切替判断テーブル３５ａに対して、０系サーバ３−１の状態情報の更新、及び、１系サーバ３−２の状態情報の参照が行なわれる（ステップＳ２−２）。
そして、ＨＭＩ端末２により、第１所定時間待機され（ステップＳ２−３）、ステップＳ２−１に処理が移行する。
そして、ＨＭＩ端末２により、第１所定時間待機され（ステップＳ２−３）、ステップＳ２−１に処理が移行する。
ＯｐＳサーバ３の処理では、図９に示すように、ＯｐＳサーバ３により、ＨＭＩ端末２からのヘルスチェック要求の受信確認が行なわれる（ステップＳ３；図１２及び図１３のステップＳ３１〜Ｓ３７）。
具体的には、ＯｐＳサーバ３により、第２所定時間間隔で、ＨＭＩ端末２からヘルスチェック要求を受信したか否かが判定され、受信していない場合に、当該ＨＭＩ端末２がログインしているサーバ３に係るログイン数の更新（減算）が行なわれる。
具体的には、ＯｐＳサーバ３により、第２所定時間間隔で、ＨＭＩ端末２からヘルスチェック要求を受信したか否かが判定され、受信していない場合に、当該ＨＭＩ端末２がログインしているサーバ３に係るログイン数の更新（減算）が行なわれる。
また、ＯｐＳサーバ３により、系間のネットワーク６の監視による、運用切替判断テーブル３５ａの更新処理が行なわれる（ステップＳ４；図１４のステップＳ４１〜Ｓ５２）。
具体的には、ＯｐＳサーバ３により、第３所定時間間隔で、運用切替判断テーブル３５ａと、系間のネットワーク６の通信状態の監視結果とに基づいて、サーバ３の運用状態の判断及び運用切替の有無の判断、並びに、運用切替処理が実行される。
具体的には、ＯｐＳサーバ３により、第３所定時間間隔で、運用切替判断テーブル３５ａと、系間のネットワーク６の通信状態の監視結果とに基づいて、サーバ３の運用状態の判断及び運用切替の有無の判断、並びに、運用切替処理が実行される。
〔１−６−２〕ＨＭＩ端末の動作例
次に、図１０及び図１１を参照して、ＨＭＩ端末２によるログイン処理、及び、ＨＭＩ端末２によるヘルスチェック処理を説明する。図１０及び図１１は、それぞれ、ＨＭＩ端末２によるログイン処理、及び、ＨＭＩ端末２によるヘルスチェック処理を説明するフローチャートである。
次に、図１０及び図１１を参照して、ＨＭＩ端末２によるログイン処理、及び、ＨＭＩ端末２によるヘルスチェック処理を説明する。図１０及び図１１は、それぞれ、ＨＭＩ端末２によるログイン処理、及び、ＨＭＩ端末２によるヘルスチェック処理を説明するフローチャートである。
ＨＭＩ端末２によるログイン処理（図８のステップＳ１）では、図１０に示すように、ログイン／ログオフ処理部２３から指定サーバ３（例えば０系サーバ３−１）にログイン要求が発行される（ステップＳ１１）。ログイン要求は、ＯｐＳサーバ側通信部２１により受け付けられ、０系サーバ３−１へ送信される。
０系サーバ３−１では、ＨＭＩ端末側通信部３１によりログイン要求が受信され、コマンド処理部３２に渡される（ステップＳ１２）。そして、コマンド処理部３２により、データベース部３５の運用切替判断テーブル３５ａ内の自系（０系）サーバログイン数が最新化（１加算）される（ステップＳ１３）。
０系サーバ３−１では、ＨＭＩ端末側通信部３１によりログイン要求が受信され、コマンド処理部３２に渡される（ステップＳ１２）。そして、コマンド処理部３２により、データベース部３５の運用切替判断テーブル３５ａ内の自系（０系）サーバログイン数が最新化（１加算）される（ステップＳ１３）。
また、コマンド処理部３２により、運用切替判断テーブル３５ａから“０系運用状態”及び“自系（０系）サーバログイン数”が読み出され、ＨＭＩ端末２からのログイン要求に対する応答に含められて、ＨＭＩ端末２へ送信される（ステップＳ１４）。
ＨＭＩ端末２では、ログイン／ログオフ処理部２３により、０系サーバ３−１からＯｐＳサーバ側通信部２１を経由してログイン完了を示す応答が受信される（ステップＳ１５）。ヘルスチェック部２２では、応答に含まれる“０系運用状態”及び“自系（０系）サーバログイン数”が、保持部２５の運用切替判断テーブル２５ａに設定される（ステップＳ１６）。また、ログイン状態通知部２４により、他系（１系）サーバ３に対して、“０系運用状態”及び“自系（０系；１系サーバ３−２では“他系”として扱われる）サーバログイン数”が運用状態通知要求として送信される（ステップＳ１７）。
ＨＭＩ端末２では、ログイン／ログオフ処理部２３により、０系サーバ３−１からＯｐＳサーバ側通信部２１を経由してログイン完了を示す応答が受信される（ステップＳ１５）。ヘルスチェック部２２では、応答に含まれる“０系運用状態”及び“自系（０系）サーバログイン数”が、保持部２５の運用切替判断テーブル２５ａに設定される（ステップＳ１６）。また、ログイン状態通知部２４により、他系（１系）サーバ３に対して、“０系運用状態”及び“自系（０系；１系サーバ３−２では“他系”として扱われる）サーバログイン数”が運用状態通知要求として送信される（ステップＳ１７）。
１系サーバ３−２では、ＨＭＩ端末側通信部３１により運用状態通知要求が受信され、コマンド処理部３２に渡される（ステップＳ１８）。そして、コマンド処理部３２により、データベース部３５の運用切替判断テーブル３５ａ内に受信した“０系運用状態”及び“他系（０系）サーバログイン数”が設定され（ステップＳ１９）、ＨＭＩ端末２によるログイン処理が終了する。
ＨＭＩ端末２によるヘルスチェック処理（図８のステップＳ２）では、図１１に示すように、ヘルスチェック部２２からログイン中又は未ログインの対象サーバ３（例えば０系サーバ３−１）にヘルスチェック要求が発行される（ステップＳ２１）。なお、ヘルスチェック要求には、ＨＭＩ端末２の保持部２５が保持する他系（１系）サーバ３の運用状態とサーバログイン数とが含まれる。また、ヘルスチェック部２２から発行されたヘルスチェック要求は、ＯｐＳサーバ側通信部２１により受信され、対象サーバ３へ送信される。
０系サーバ３−１では、ＨＭＩ端末側通信部３１によりヘルスチェック要求が受信され、コマンド処理部３２に渡される（ステップＳ２２）。そして、コマンド処理部３２により、データベース部３５の運用切替判断テーブル３５ａ内に“１系運用状態”及び“他系（１系）サーバログイン数”が設定される（ステップＳ２３）。また、コマンド処理部３２により、運用切替判断テーブル３５ａ内の“０系運用状態”及び“自系（０系）サーバログイン数”が読み出され、ＨＭＩ端末２からのヘルスチェック要求に対する応答に含められて、ＨＭＩ端末２へ送信される（ステップＳ２４）。
ＨＭＩ端末２では、ヘルスチェック部２２により、０系サーバ３−１からＯｐＳサーバ側通信部２１を経由してヘルスチェック要求の応答が受信され（ステップＳ２５）、ＨＭＩ端末２によるヘルスチェック処理が終了する。なお、ヘルスチェック部２２は、受信した応答に含まれる“０系運用状態”及び“自系（０系）サーバログイン数”を、保持部２５の運用切替判断テーブル２５ａに設定する（ステップＳ２６）。
なお、図１１のステップＳ２１〜Ｓ２６の処理は、図８のステップＳ２−１に相当する。つまり、ＨＭＩ端末２は、図１１のステップＳ２１〜Ｓ２６の自系（０系）と他系（１系）とを入れ替えて、図８のステップＳ２−２に相当する処理を実行する。また、ＨＭＩ端末２は、上述のように、第２所定時間待機し（図８のステップＳ２−３）、ステップＳＳ２−１〜Ｓ２−３の処理を繰り返し実行する。
〔１−６−３〕ＯｐＳサーバの動作例
次に、図１２〜図１４を参照して、ＯｐＳサーバ３によるヘルスチェックの受信確認処理、及び、運用切替判断テーブル３５ａの更新処理を説明する。図１２及び図１３は、ＯｐＳサーバ３によるヘルスチェックの受信確認処理を説明するフローチャートである。図１４は、ＯｐＳサーバ３による運用切替判断テーブル３５ａの更新処理を説明するフローチャートである。
次に、図１２〜図１４を参照して、ＯｐＳサーバ３によるヘルスチェックの受信確認処理、及び、運用切替判断テーブル３５ａの更新処理を説明する。図１２及び図１３は、ＯｐＳサーバ３によるヘルスチェックの受信確認処理を説明するフローチャートである。図１４は、ＯｐＳサーバ３による運用切替判断テーブル３５ａの更新処理を説明するフローチャートである。
ＯｐＳサーバ３によるヘルスチェックの受信確認処理（図９のステップＳ３）では、図１２に示すように、コマンド処理部３２により、自系サーバ３にログインしているはずのＨＭＩ端末２から、ヘルスチェック要求が第２所定時間の間にあったか否かが判定される（ステップＳ３１）。ヘルスチェック要求があった場合（ステップＳ３１のＹｅｓルート）、コマンド処理部３２により、第２所定時間待機され（ステップＳ３２）、ステップＳ３１に処理が移行する。
一方、ヘルスチェック要求がなかった場合（ステップＳ３１のＮｏルート）、コマンド処理部３２により、当該ＨＭＩ端末２はログオフ処理を行なわずにログオフしたと判断される。そして、コマンド処理部３２により、データベース部３５のログイン情報３５ｃから該当ＨＭＩ端末２を特定する情報が削除される（ステップＳ３３）。また、コマンド処理部３２により、運用切替判断テーブル３５ａ内の自系サーバログイン数が最新化（１減算）され（ステップＳ３４）、ステップＳ３２に処理が移行する。
また、図１３に示すように、コマンド処理部３２により、他系サーバ３にログインしているはずのＨＭＩ端末２から、ヘルスチェック要求が第２所定時間の間にあったか否かが判定される（ステップＳ３５）。ヘルスチェック要求があった場合（ステップＳ３５のＹｅｓルート）、コマンド処理部３２により、第２所定時間待機され（ステップＳ３６）、ステップＳ３５に処理が移行する。
一方、ヘルスチェック要求がなかった場合（ステップＳ３５のＮｏルート）、コマンド処理部３２により、当該ＨＭＩ端末２はログオフ処理を行なわずにログオフしたと判断される。そして、コマンド処理部３２により、運用切替判断テーブル３５ａ内の他系サーバログイン数が最新化（１減算）され（ステップＳ３７）、ステップＳ３６に処理が移行する。
以上の処理により、ＯｐＳサーバ３によるヘルスチェックの受信確認処理が終了する。
ＯｐＳサーバ３による運用切替判断テーブル３５ａの更新処理（図９のステップＳ４）では、図１４に示すように、他系ＡＰ状態監視部３７により、運用切替判断テーブル３５ａが参照される（ステップＳ４１）。このとき、他系ＡＰ状態監視部３７は、自系サーバ３及び他系サーバ３の運用状態、及び、他系サーバ３のログイン数を取得する。
ＯｐＳサーバ３による運用切替判断テーブル３５ａの更新処理（図９のステップＳ４）では、図１４に示すように、他系ＡＰ状態監視部３７により、運用切替判断テーブル３５ａが参照される（ステップＳ４１）。このとき、他系ＡＰ状態監視部３７は、自系サーバ３及び他系サーバ３の運用状態、及び、他系サーバ３のログイン数を取得する。
次いで、他系ＡＰ状態監視部３７により、他系サーバ側通信部３６を介して、他系サーバ３へ他系ＡＰ状態監視要求が発行される（ステップＳ４２）。なお、他系ＡＰ状態監視要求は、系間のネットワーク６で通信異常が発生している場合は、他系サーバ３には届かない。また、他系ＡＰ状態監視部３７は、後述するように、他系サーバ３のアプリケーションの起動状態が異常である場合も、通信異常と同様に処理する。
他系サーバ３では、他系サーバ側通信部３６により他系ＡＰ状態監視要求が受信され、他系サーバ３のアプリケーションの起動状態が確認され、起動有無が応答される（ステップＳ４３）。
自系サーバ３では、応答結果が受信され（ステップＳ４４）、運用状態判定部３８により、応答結果から系間通信が異常、且つ、他系のログイン数が０であるか否かが判定される（ステップＳ４５）。判定の結果、ステップＳ４５の条件を満たさない場合（ステップＳ４５のＮｏルート）、ステップＳ４６に処理が移行する。ステップＳ４６では、運用状態判定部３８により、系間通信正常、自系の運用状態が“運用”、且つ、他系の運用状態が“不明”であるか否かが判定される。判定の結果、ステップＳ４６の条件を満たさない場合（ステップＳ４６のＮｏルート）、ステップＳ４９に処理が移行する。
自系サーバ３では、応答結果が受信され（ステップＳ４４）、運用状態判定部３８により、応答結果から系間通信が異常、且つ、他系のログイン数が０であるか否かが判定される（ステップＳ４５）。判定の結果、ステップＳ４５の条件を満たさない場合（ステップＳ４５のＮｏルート）、ステップＳ４６に処理が移行する。ステップＳ４６では、運用状態判定部３８により、系間通信正常、自系の運用状態が“運用”、且つ、他系の運用状態が“不明”であるか否かが判定される。判定の結果、ステップＳ４６の条件を満たさない場合（ステップＳ４６のＮｏルート）、ステップＳ４９に処理が移行する。
ステップＳ４５において、判定の結果、条件を満たす場合（ステップＳ４５のＹｅｓルート）、運用状態判定部３８により、他系サーバ３の運用状態が“不明”であると判定され（ステップＳ４７）、運用切替判断テーブル３５ａが更新される。そして、ステップＳ４９に処理が移行する。
また、ステップＳ４６において、判定の結果、条件を満たす場合（ステップＳ４６のＹｅｓルート）、運用状態判定部３８により、他系サーバ３の運用状態が“待機”であると判定され（ステップＳ４８）、運用切替判断テーブル３５ａが更新される。つまり、運用状態判定部３８は、運用状態が“不明”であった他系サーバ３について、系間通信が正常になったと判断し、他系サーバ３を待機系に切り替える。そして、ステップＳ４９に処理が移行する。
また、ステップＳ４６において、判定の結果、条件を満たす場合（ステップＳ４６のＹｅｓルート）、運用状態判定部３８により、他系サーバ３の運用状態が“待機”であると判定され（ステップＳ４８）、運用切替判断テーブル３５ａが更新される。つまり、運用状態判定部３８は、運用状態が“不明”であった他系サーバ３について、系間通信が正常になったと判断し、他系サーバ３を待機系に切り替える。そして、ステップＳ４９に処理が移行する。
ステップＳ４９では、運用状態判定部３８により、ＤＢアクセス部３４を介して、データベース部３５の運用切替判断基準３５ｂが参照され、運用切替判断テーブル３５ａに基づき、自系サーバ３の運用状態が判定される。
また、ＯｐＳサーバ３が実行する通信ネットワーク４の制御用のアプリケーションにより、運用状態判定部３８の判定結果が運用状態の切り替えを示す場合には、運用切替が実施される（ステップＳ５０）。さらに、運用状態判定部３８により、判定の結果、自系サーバ３の運用状態が更新される場合には、ＤＢアクセス部３４を経由して運用切替判断テーブル３５ａが更新される（ステップＳ５１）。
また、ＯｐＳサーバ３が実行する通信ネットワーク４の制御用のアプリケーションにより、運用状態判定部３８の判定結果が運用状態の切り替えを示す場合には、運用切替が実施される（ステップＳ５０）。さらに、運用状態判定部３８により、判定の結果、自系サーバ３の運用状態が更新される場合には、ＤＢアクセス部３４を経由して運用切替判断テーブル３５ａが更新される（ステップＳ５１）。
そして、ＯｐＳサーバ３により、第３所定時間待機され（ステップＳ５２）、ステップＳ４１に処理が移行し、ＯｐＳサーバ３による運用切替判断テーブル３５ａの更新処理が終了する。
〔１−７〕運用切替処理の実施例
次に、図１５〜図２６を参照して、冗長サーバシステム１において障害が発生した場合の、ＯｐＳサーバ３による運用切替処理の実施例を説明する。
〔１−７〕運用切替処理の実施例
次に、図１５〜図２６を参照して、冗長サーバシステム１において障害が発生した場合の、ＯｐＳサーバ３による運用切替処理の実施例を説明する。
〔１−７−１〕第１実施例
はじめに、図１５〜図２２を参照して、第１実施例について説明する。図１５は、一実施形態の第１実施例に係る冗長サーバシステム１において、系間のネットワーク６の通信異常及び０系サーバ３−１のハードウェア故障が発生した場合の例を示す図である。図１６〜図２２は、図１５に示す例における運用切替判断テーブル２５ａ及び３５ａの変化を説明する図である。なお、図１６〜図２２において、変更のあった値には、下線を付している。
はじめに、図１５〜図２２を参照して、第１実施例について説明する。図１５は、一実施形態の第１実施例に係る冗長サーバシステム１において、系間のネットワーク６の通信異常及び０系サーバ３−１のハードウェア故障が発生した場合の例を示す図である。図１６〜図２２は、図１５に示す例における運用切替判断テーブル２５ａ及び３５ａの変化を説明する図である。なお、図１６〜図２２において、変更のあった値には、下線を付している。
図１５に示すように、第１実施例では、図１に示すものと同様の冗長サーバシステム１を用いて説明する。第１実施例では、サーバ３の系間のネットワーク６の通信が異常状態、且つ、運用系である０系サーバ３−１にハードウェア故障が検出された場合の、ＯｐＳサーバ３による運用切替処理を説明する。
図１６の上欄に示すように、冗長サーバシステム１の初期状態では、０系サーバ３−１が運用系であり１系サーバ３−２が待機系である。また、０系サーバ３−１及び１系サーバ３−２のいずれにもＨＭＩ端末２はログインしていない。なお、図１６〜図１９は、初期状態から障害の発生が検出されるまでのＨＭＩ端末２が保持する運用切替判断テーブル２５ａ、及び、両サーバ３が保持する運用切替判断テーブル３５ａ（以下、単にテーブル２５ａ及び３５ａという）の遷移を示している。
図１６の上欄に示すように、冗長サーバシステム１の初期状態では、０系サーバ３−１が運用系であり１系サーバ３−２が待機系である。また、０系サーバ３−１及び１系サーバ３−２のいずれにもＨＭＩ端末２はログインしていない。なお、図１６〜図１９は、初期状態から障害の発生が検出されるまでのＨＭＩ端末２が保持する運用切替判断テーブル２５ａ、及び、両サーバ３が保持する運用切替判断テーブル３５ａ（以下、単にテーブル２５ａ及び３５ａという）の遷移を示している。
はじめに、ＨＭＩ端末２−１が０系サーバ３−１にログイン処理を行ない、ログインが完了する（図１０のログイン処理のフローチャート参照）。このとき、テーブル２５ａ及び３５ａは、図１６の下欄に示すようになる。
つまり、０系サーバ３−１のテーブル３５ａには、自系（０系）サーバログイン数に“１”が設定される。また、１系サーバ３−２のテーブル３５ａには、ＨＭＩ端末２−１による０系サーバ３−１の読出結果が反映されて、０系運用状態に“運用”（変更なし）、他系（０系）サーバログイン数に“１”が設定される。なお、ＨＭＩ端末２のテーブル２５ａにも同様の情報が設定される。以下の説明においても同様である。
つまり、０系サーバ３−１のテーブル３５ａには、自系（０系）サーバログイン数に“１”が設定される。また、１系サーバ３−２のテーブル３５ａには、ＨＭＩ端末２−１による０系サーバ３−１の読出結果が反映されて、０系運用状態に“運用”（変更なし）、他系（０系）サーバログイン数に“１”が設定される。なお、ＨＭＩ端末２のテーブル２５ａにも同様の情報が設定される。以下の説明においても同様である。
次に、ＨＭＩ端末２−２が１系サーバ３−２にログイン処理を行ない、ログインが完了する（図１０のログイン処理のフローチャート参照）。このとき、テーブル２５ａ及び３５ａは、図１７に示すようになる。
つまり、１系サーバ３−２のテーブル３５ａには、自系（１系）サーバログイン数に“１”が設定される。また、０系サーバ３−１のテーブル３５ａには、ＨＭＩ端末２−２による１系サーバ３−２の読出結果が反映されて、１系運用状態に“待機”（変更なし）、他系（１系）サーバログイン数に“１”が設定される。図１７に示すように、ＨＭＩ端末２−１及び２−２によるログイン処理が完了すると、ＨＭＩ端末２からサーバ３へのヘルスチェックが行なわれる状態、つまり通常の運用状態に遷移する。
つまり、１系サーバ３−２のテーブル３５ａには、自系（１系）サーバログイン数に“１”が設定される。また、０系サーバ３−１のテーブル３５ａには、ＨＭＩ端末２−２による１系サーバ３−２の読出結果が反映されて、１系運用状態に“待機”（変更なし）、他系（１系）サーバログイン数に“１”が設定される。図１７に示すように、ＨＭＩ端末２−１及び２−２によるログイン処理が完了すると、ＨＭＩ端末２からサーバ３へのヘルスチェックが行なわれる状態、つまり通常の運用状態に遷移する。
次いで、ＨＭＩ端末２−１から０系サーバ３−１へヘルスチェック処理が行なわれ、ヘルスチェックが完了する（図８のステップＳ２−１，図１１のヘルスチェック処理のフローチャート参照）。このとき、テーブル２５ａ及び３５ａは、図１８の上欄に示すようになる。
つまり、０系サーバ３−１のテーブル３５ａには、ＨＭＩ端末２−１による１系サーバ３−２の読出結果が反映されて、１系運用状態に“待機”（変更なし）、他系（１系）サーバログイン数に“１”（変更なし）が設定される。
つまり、０系サーバ３−１のテーブル３５ａには、ＨＭＩ端末２−１による１系サーバ３−２の読出結果が反映されて、１系運用状態に“待機”（変更なし）、他系（１系）サーバログイン数に“１”（変更なし）が設定される。
また、ＨＭＩ端末２−１から１系サーバ３−２へヘルスチェック処理が行なわれ、ヘルスチェックが完了する（図８のステップＳ２−２，図１１のヘルスチェック処理のフローチャート参照）。このとき、テーブル２５ａ及び３５ａは、図１８の下欄に示すようになる。
つまり、１系サーバ３−２のテーブル３５ａには、ＨＭＩ端末２−１による０系サーバ３−１の読出結果が反映されて、０系運用状態に“運用”（変更なし）、他系（０系）サーバログイン数に“１”（変更なし）が設定される。
つまり、１系サーバ３−２のテーブル３５ａには、ＨＭＩ端末２−１による０系サーバ３−１の読出結果が反映されて、０系運用状態に“運用”（変更なし）、他系（０系）サーバログイン数に“１”（変更なし）が設定される。
同様に、ＨＭＩ端末２−２から１系サーバ３−２へのヘルスチェック処理、及び、ＨＭＩ端末２−２から０系サーバ３−１へのヘルスチェック処理が行なわれ、ヘルスチェックが完了すると、テーブル２５ａ及び３５ａは、図１９の上欄及び下欄に示すようになる。
なお、図１８及び図１９に示す処理は、第１所定時間ごとに繰り返し実行される（図８のステップＳ２−３参照）。
なお、図１８及び図１９に示す処理は、第１所定時間ごとに繰り返し実行される（図８のステップＳ２−３参照）。
ここで、図１５に示すサーバ３の系間のネットワーク６に通信異常が発生した場合、各サーバ３は、系間のネットワーク６が不通になるため、他系ＡＰ状態監視部３７により障害が検出される。しかし、上述したヘルスチェック処理が、サーバ３−ＨＭＩ端末２間のネットワーク５を介して行なわれるため、テーブル２５ａ及び３５ａは、通信異常の影響を受けずに、相手のサーバ状態を認識することができる。
次に、系間のネットワーク６の通信異常に加えて、図１５に示す０系サーバ３−１のハードウェア故障が検出された場合を想定する。このとき、ＨＭＩ端末２−１から０系サーバ３−１へヘルスチェック処理が行なわれ、ヘルスチェックが完了すると（図８のステップＳ２−１，図１１のヘルスチェック処理のフローチャート参照）、テーブル２５ａ及び３５ａは、図２０の上欄に示すようになる。
ＨＭＩ端末２−１は、故障が発生した０系サーバ３−１に対するヘルスチェック処理を失敗する。このとき、ＨＭＩ端末２−１の保持部２５が保持するテーブル２５ａには、０系サーバ３−１に関して、全ての項目が異常値（又はＮｕｌｌ等）になる（図２０中、“？”と表記）。なお、以下の説明では、０系サーバ３−１のテーブル３５ａについて、ＨＭＩ端末２が保持するテーブル２５ａを用いて説明する。
ＨＭＩ端末２−１から１系サーバ３−２へヘルスチェック処理が行なわれ、ヘルスチェックが完了すると、テーブル２５ａ及び３５ａは、図２０の下欄に示すようになる。
つまり、ＨＭＩ端末２−１による０系サーバ３−１からのテーブル３５ａの読み出しができなかったため、１系サーバ３−２のテーブル３５ａには、０系運用状態の設定が行なわれない。また、０系サーバ３−１にログインしていたＨＭＩ端末２−１が０系サーバ３−１へアクセスできないため、１系サーバ３−２のテーブル３５ａには、他系（０系）サーバログイン数に“０”が設定される。
つまり、ＨＭＩ端末２−１による０系サーバ３−１からのテーブル３５ａの読み出しができなかったため、１系サーバ３−２のテーブル３５ａには、０系運用状態の設定が行なわれない。また、０系サーバ３−１にログインしていたＨＭＩ端末２−１が０系サーバ３−１へアクセスできないため、１系サーバ３−２のテーブル３５ａには、他系（０系）サーバログイン数に“０”が設定される。
また、ＨＭＩ端末２−２から１系サーバ３−２へヘルスチェック処理が行なわれ、ヘルスチェックが完了すると、テーブル２５ａ及び３５ａは、図２１の上欄に示すようになる。
つまり、ＨＭＩ端末２−１による０系サーバ３−１からのテーブル３５ａの読み出しができなかったため、１系サーバ３−２のテーブル３５ａには、０系運用状態及び他系（０系）サーバログイン数の設定が行なわれない。
つまり、ＨＭＩ端末２−１による０系サーバ３−１からのテーブル３５ａの読み出しができなかったため、１系サーバ３−２のテーブル３５ａには、０系運用状態及び他系（０系）サーバログイン数の設定が行なわれない。
また、ＨＭＩ端末２−２は、故障が発生した０系サーバ３−１に対するヘルスチェック処理を失敗する。このとき、ＨＭＩ端末２−１の保持部２５が保持するテーブル２５ａには、図２１の下欄に示すように、０系サーバ３−１に関して、全ての項目が異常値等になる。
次いで、１系サーバ３−２は、運用状態判定部３８により運用切替判断テーブル３５ａの更新処理を行なうと（図１４の運用切替判断テーブルの更新処理のステップＳ４５及びＳ４７参照）、テーブル２５ａ及び３５ａは、図２２の上欄に示すようになる。
次いで、１系サーバ３−２は、運用状態判定部３８により運用切替判断テーブル３５ａの更新処理を行なうと（図１４の運用切替判断テーブルの更新処理のステップＳ４５及びＳ４７参照）、テーブル２５ａ及び３５ａは、図２２の上欄に示すようになる。
つまり、１系サーバ３−２の運用状態判定部３８は、他系ＡＰ状態監視部３７で異常を検出し、且つ、他系（０系）サーバログイン数が“０”を検出するため、０系運用状態が“不明”であると判定する。
次いで、１系サーバ３−２は、運用状態判定部３８により運用切替判断テーブル３５ａの更新処理を行なうと（図１４の運用切替判断テーブルの更新処理のステップＳ４９〜Ｓ５１参照）、テーブル２５ａ及び３５ａは、図２２の下欄に示すようになる。
次いで、１系サーバ３−２は、運用状態判定部３８により運用切替判断テーブル３５ａの更新処理を行なうと（図１４の運用切替判断テーブルの更新処理のステップＳ４９〜Ｓ５１参照）、テーブル２５ａ及び３５ａは、図２２の下欄に示すようになる。
つまり、１系サーバ３−２の運用状態判定部３８は、データベース部３５から運用切替判断基準３５ｂを参照し、１系サーバ３−２の運用状態を判定して、テーブル３５ａを更新する。このとき、１系サーバ３−２は、自系（１系）の運用状態が“待機”、且つ、他系（０系）の運用状態が“不明”であると検出するため、１系運用状態が“運用”であると判定する（図６のＢ参照）。
以上の処理により、サーバ３の系間のネットワーク６の通信が異常状態、且つ、運用系である０系サーバ３−１にハードウェア故障が検出された場合の、ＯｐＳサーバ３による運用切替処理が終了する。
〔１−７−２〕第２実施例
次に、図２３〜図２６を参照して、第２実施例について説明する。図２３は、一実施形態の第２実施例に係る冗長サーバシステム１′において、系間のネットワーク６の通信異常及びＨＭＩ端末２と０系サーバ３−１との間の通信異常が発生した場合の例を示す図である。図２４〜図２６は、図２３に示す例における運用切替判断テーブル２５ａ及び３５ａの変化を説明する図である。なお、図２４〜図２６において、変更のあった値には、下線を付している。
〔１−７−２〕第２実施例
次に、図２３〜図２６を参照して、第２実施例について説明する。図２３は、一実施形態の第２実施例に係る冗長サーバシステム１′において、系間のネットワーク６の通信異常及びＨＭＩ端末２と０系サーバ３−１との間の通信異常が発生した場合の例を示す図である。図２４〜図２６は、図２３に示す例における運用切替判断テーブル２５ａ及び３５ａの変化を説明する図である。なお、図２４〜図２６において、変更のあった値には、下線を付している。
図２３に示すように、第２実施例では、１つのＨＭＩ端末２−１をそなえる冗長サーバシステム１′を用いて説明する。なお、冗長サーバシステム１′は、ＨＭＩ端末２の数以外は図１に示す冗長サーバシステム１と同様である。第２実施例では、サーバ３の系間のネットワーク６の通信が異常状態、且つ、ＨＭＩ端末２−１と０系サーバ３−１との間のネットワーク５の通信が異常状態である場合の、ＯｐＳサーバ３による運用切替処理を説明する。
図２３に示す例において、系間のネットワーク６の通信異常及びＨＭＩ端末２と０系サーバ３−１との間の通信異常が発生した場合、オペレータが故意に待機系であった１系サーバ３−２を運用系に変更することがある。このとき、ＯｐＳサーバ３がともに運用系になる。なお、図２３に示す例では、ＨＭＩ端末２−１は、１系サーバ３−２にログインしている。
以上の前提において、図２４に示すように、冗長サーバシステム１′では、０系サーバ３−１のテーブル３５ａには、０系運用状態に“運用”、自系（０系）サーバログイン数に“０”が設定される。なお、０系サーバ３−１は通信障害により外部に接続できないため、１系運用状態に“不明”、他系（１系）サーバログイン数に“０”が設定される。
また、１系サーバ３−２のテーブル３５ａには、０系サーバ３−１との通信が不通であるため、０系運用状態に“不明”が設定され、オペレータからの強制的な設定により、１系運用状態に“運用”が設定される。また、１系サーバ３−２のテーブル３５ａには、自系（１系）サーバログイン数に“１”、他系（０系）サーバログイン数に“０”が設定される。
また、１系サーバ３−２のテーブル３５ａには、０系サーバ３−１との通信が不通であるため、０系運用状態に“不明”が設定され、オペレータからの強制的な設定により、１系運用状態に“運用”が設定される。また、１系サーバ３−２のテーブル３５ａには、自系（１系）サーバログイン数に“１”、他系（０系）サーバログイン数に“０”が設定される。
なお、ＨＭＩ端末２のテーブル２５ａにも同様の情報が設定される。以下の説明においても同様である。
次に、ＨＭＩ端末２と０系サーバ３−１との間の通信障害が復旧した場合を想定する。ＨＭＩ端末２−１は、１系サーバ３−２へ既にログイン済みであるため、ＨＭＩ端末２−１から定期的なヘルスチェック処理が行なわれる。ＨＭＩ端末２−１から１系サーバ３−２へヘルスチェック処理が行なわれ、ヘルスチェックが完了すると（図８のステップＳ２−１，図１１のヘルスチェック処理のフローチャート参照）、テーブル２５ａ及び３５ａは、図２５の上欄に示すようになる。
次に、ＨＭＩ端末２と０系サーバ３−１との間の通信障害が復旧した場合を想定する。ＨＭＩ端末２−１は、１系サーバ３−２へ既にログイン済みであるため、ＨＭＩ端末２−１から定期的なヘルスチェック処理が行なわれる。ＨＭＩ端末２−１から１系サーバ３−２へヘルスチェック処理が行なわれ、ヘルスチェックが完了すると（図８のステップＳ２−１，図１１のヘルスチェック処理のフローチャート参照）、テーブル２５ａ及び３５ａは、図２５の上欄に示すようになる。
つまり、１系サーバ３−２のテーブル３５ａには、ＨＭＩ端末２−１による０系サーバ３−１の読出結果が反映されて、０系運用状態に“運用”、他系（０系）サーバログイン数に“０”（変更なし）が設定される。
また、ＨＭＩ端末２−１から０系サーバ３−２へヘルスチェック処理が行なわれ、ヘルスチェックが完了する（図８のステップＳ２−２，図１１のヘルスチェック処理のフローチャート参照）。このとき、テーブル２５ａ及び３５ａは、図２５の下欄に示すようになる。
また、ＨＭＩ端末２−１から０系サーバ３−２へヘルスチェック処理が行なわれ、ヘルスチェックが完了する（図８のステップＳ２−２，図１１のヘルスチェック処理のフローチャート参照）。このとき、テーブル２５ａ及び３５ａは、図２５の下欄に示すようになる。
つまり、０系サーバ３−１のテーブル３５ａには、ＨＭＩ端末２−１による１系サーバ３−２の読出結果が反映されて、１系運用状態に“運用”、他系（１系）サーバログイン数に“１”が設定される。
次いで、０系サーバ３−１は、運用状態判定部３８により運用切替判断テーブル３５ａの更新処理を行なうと（図１４の運用切替判断テーブルの更新処理のステップＳ４９〜Ｓ５１参照）、テーブル２５ａ及び３５ａは、図２６の上欄に示すようになる。
次いで、０系サーバ３−１は、運用状態判定部３８により運用切替判断テーブル３５ａの更新処理を行なうと（図１４の運用切替判断テーブルの更新処理のステップＳ４９〜Ｓ５１参照）、テーブル２５ａ及び３５ａは、図２６の上欄に示すようになる。
つまり、０系サーバ３−１の運用状態判定部３８は、データベース部３５から運用切替判断基準３５ｂを参照し、０系サーバ３−１の運用状態を判定して、テーブル３５ａを更新する。このとき、０系サーバ３−１は、０系サーバ３−１及び１系サーバ３−２の双方の運用状態が“運用”、且つ、１系サーバ３−２に係るログイン数のみが１以上であるため、自系サーバ３（０系サーバ３−１）の運用状態を“待機”に変更する（図６のＡ２参照）。
また、１系サーバ３−２も、ＨＭＩ端末２−１による次のヘルスチェック処理が行なわれる前に、運用状態判定部３８により運用切替判断テーブル３５ａの更新処理を行なう（図１４の運用切替判断テーブルの更新処理のステップＳ４９〜Ｓ５１参照）。このとき、テーブル２５ａ及び３５ａは、図２６の下欄に示すようになる。
つまり、１系サーバ３−２の運用状態判定部３８は、データベース部３５から運用切替判断基準３５ｂを参照し、１系サーバ３−２の運用状態を判定して、テーブル３５ａを更新する。このとき、１系サーバ３−２は、０系サーバ３−１及び１系サーバ３−２の双方の運用状態が“運用”、且つ、１系サーバ３−２に係るログイン数のみが１以上であるため、他系サーバ３（０系サーバ３−１）の運用状態を“待機”に変更する（図６のＡ２参照）。
つまり、１系サーバ３−２の運用状態判定部３８は、データベース部３５から運用切替判断基準３５ｂを参照し、１系サーバ３−２の運用状態を判定して、テーブル３５ａを更新する。このとき、１系サーバ３−２は、０系サーバ３−１及び１系サーバ３−２の双方の運用状態が“運用”、且つ、１系サーバ３−２に係るログイン数のみが１以上であるため、他系サーバ３（０系サーバ３−１）の運用状態を“待機”に変更する（図６のＡ２参照）。
以上の処理により、サーバ３の系間のネットワーク６の通信異常及びＨＭＩ端末２−１と０系サーバ３−１との間の通信異常が発生した場合の、ＯｐＳサーバ３による運用切替処理が終了する。
このように、本実施形態の一例としてのＨＭＩ端末２及びＯｐＳサーバ３によれば、０系サーバ３−１及び１系サーバ３−２がともに運用系となった状態から、ＨＭＩ端末２−１と０系サーバ３−１との間の通信異常が復旧した場合に、直ちに運用切替が行なわれる。つまり、ＨＭＩ端末２及びＯｐＳサーバ３は、通信異常の復旧後に、速やかに、各サーバ３の運用状態を運用切替判断基準３５ｂに即した状態（運用系又は待機系）に切り替え、障害の復旧を行なうことができる。
このように、本実施形態の一例としてのＨＭＩ端末２及びＯｐＳサーバ３によれば、０系サーバ３−１及び１系サーバ３−２がともに運用系となった状態から、ＨＭＩ端末２−１と０系サーバ３−１との間の通信異常が復旧した場合に、直ちに運用切替が行なわれる。つまり、ＨＭＩ端末２及びＯｐＳサーバ３は、通信異常の復旧後に、速やかに、各サーバ３の運用状態を運用切替判断基準３５ｂに即した状態（運用系又は待機系）に切り替え、障害の復旧を行なうことができる。
なお、第２実施例で説明した処理の流れは、冗長サーバシステム１、又はＨＭＩ端末２が３以上の他の冗長サーバシステムにおいて、全てのＨＭＩ端末２とサーバ３との間のネットワークが通信異常になった場合においても、同様に適用可能である。
〔２〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
〔２〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
上述した一実施形態において、ＯｐＳサーバ３は、０系サーバ３−１及び１系サーバ３−２の２つのサーバ３により実現されるものとして説明したが、これに限定されるものではない。例えば、ＯｐＳサーバ３が３以上のサーバ３により実現されてもよい。この場合、運用切替判断テーブル２５ａ及び３５ａには、サーバ３の数に対応する運用状態とログインしているＨＭＩ端末２の数とが設定される。また、運用切替判断基準３５ｂには、３以上のサーバ３のうちのいずれか１のサーバ３の運用状態が“運用”となるように、条件が設定される。
また、一実施形態において、ＯｐＳサーバ３は、ＨＭＩ端末２からログイン要求やヘルスチェック要求等を受信し、これらの要求の応答として、状態情報をＨＭＩ端末２へ送信するものとして説明したが、これに限定されるものではない。例えば、ＯｐＳサーバ３は、定期的に、ＨＭＩ端末２へ他系サーバ３の状態情報の取得要求、及び、自系サーバ３の状態情報を送信し、ＨＭＩ端末２から、送信した状態情報の取得要求への応答として、他系サーバ３の状態情報を受信してもよい。
なお、一実施形態のＨＭＩ端末２及びＯｐＳサーバ３の各種機能の全部もしくは一部は、コンピュータ（ＣＰＵ，情報処理装置，各種端末を含む）が所定のプログラムを実行することによって実現されてもよい。
そのプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体（例えば図２に示す記録媒体１７ａ又は／及び１７ｂ）に記録された形態で提供される。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。なお、上記プログラムは、ＨＭＩ端末２及びＯｐＳサーバ３のそれぞれに実行させる機能ごとに分割されて、例えば図２に示す記録媒体１７ａ及び１７ｂのそれぞれに記録されてもよい。
そのプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体（例えば図２に示す記録媒体１７ａ又は／及び１７ｂ）に記録された形態で提供される。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。なお、上記プログラムは、ＨＭＩ端末２及びＯｐＳサーバ３のそれぞれに実行させる機能ごとに分割されて、例えば図２に示す記録媒体１７ａ及び１７ｂのそれぞれに記録されてもよい。
ここで、コンピュータとは、ハードウェアとＯＳ（オペレーティングシステム）とを含む概念であり、ＯＳの制御の下で動作するハードウェアを意味している。また、ＯＳが不要でアプリケーションプログラム単独でハードウェアを動作させるような場合には、そのハードウェア自体がコンピュータに相当する。ハードウェアは、少なくとも、ＣＰＵ等のマイクロプロセッサと、記録媒体に記録されたコンピュータプログラムを読み取る手段とをそなえている。上記プログラムは、上述のようなコンピュータに、一実施形態のＨＭＩ端末２及びＯｐＳサーバ３の各種機能を実現させるプログラムコードを含んでいる。また、その機能の一部は、アプリケーションプログラムではなくＯＳによって実現されてもよい。
〔３〕付記
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置と、
前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置と、をそなえた情報処理システムであって、
前記端末装置は、
前記複数の情報処理装置の各々から、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を取得する取得部と、
前記複数の情報処理装置の各々に、他の情報処理装置から取得した状態情報を通知する通知部と、をそなえ、
前記複数の情報処理装置の各々は、
自装置が保持する状態情報と前記端末装置から通知された他の情報処理装置の状態情報とに基づいて、前記自装置が前記所定の処理を行なうか否かを判定する判定部をそなえる
ことを特徴とする、情報処理システム。
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置と、
前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置と、をそなえた情報処理システムであって、
前記端末装置は、
前記複数の情報処理装置の各々から、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を取得する取得部と、
前記複数の情報処理装置の各々に、他の情報処理装置から取得した状態情報を通知する通知部と、をそなえ、
前記複数の情報処理装置の各々は、
自装置が保持する状態情報と前記端末装置から通知された他の情報処理装置の状態情報とに基づいて、前記自装置が前記所定の処理を行なうか否かを判定する判定部をそなえる
ことを特徴とする、情報処理システム。
（付記２）
前記状態情報は、
前記情報処理装置が、前記所定の処理を行なう第１状態、及び待機を行なう第２状態、のいずれであるかを示す動作状態をさらに含み、
前記判定部は、
前記自装置が保持する状態情報と前記端末装置から通知された前記他の情報処理装置の状態情報とに基づき、２以上の前記情報処理装置が前記第１状態であると判断した場合、前記２以上の情報処理装置の中から、接続処理済みの端末装置の数に基づいて、一の情報処理装置が前記第１状態であると判定し、前記第１状態であると判定した情報処理装置以外の情報処理装置が前記第２状態であると判定し、
判定した前記動作状態に基づいて、前記自装置が前記所定の処理を行なうか否かを判定する、
ことを特徴とする、付記１記載の情報処理システム。
前記状態情報は、
前記情報処理装置が、前記所定の処理を行なう第１状態、及び待機を行なう第２状態、のいずれであるかを示す動作状態をさらに含み、
前記判定部は、
前記自装置が保持する状態情報と前記端末装置から通知された前記他の情報処理装置の状態情報とに基づき、２以上の前記情報処理装置が前記第１状態であると判断した場合、前記２以上の情報処理装置の中から、接続処理済みの端末装置の数に基づいて、一の情報処理装置が前記第１状態であると判定し、前記第１状態であると判定した情報処理装置以外の情報処理装置が前記第２状態であると判定し、
判定した前記動作状態に基づいて、前記自装置が前記所定の処理を行なうか否かを判定する、
ことを特徴とする、付記１記載の情報処理システム。
（付記３）
前記動作状態は、
前記情報処理装置が、前記第１状態、前記第２状態、及び障害が発生したことを示す第３状態、のいずれであるかを示し、
前記判定部は、
前記自装置が保持する状態情報と前記他の情報処理装置の状態情報とに基づいて、前記自装置に係る接続処理済みの端末装置の数が１以上であり、前記自装置が前記第２状態であり、且つ、前記他の情報処理装置が前記第３状態である場合、前記自装置の動作状態が前記第１状態であると判定する、
ことを特徴とする、付記２記載の情報処理システム。
前記動作状態は、
前記情報処理装置が、前記第１状態、前記第２状態、及び障害が発生したことを示す第３状態、のいずれであるかを示し、
前記判定部は、
前記自装置が保持する状態情報と前記他の情報処理装置の状態情報とに基づいて、前記自装置に係る接続処理済みの端末装置の数が１以上であり、前記自装置が前記第２状態であり、且つ、前記他の情報処理装置が前記第３状態である場合、前記自装置の動作状態が前記第１状態であると判定する、
ことを特徴とする、付記２記載の情報処理システム。
（付記４）
前記判定部は、
前記他の情報処理装置に係る接続処理済みの端末装置の数が０であり、且つ、前記他の情報処理装置との通信で異常を検出した場合、前記他の情報処理装置の動作状態が前記第３状態であると判定する、
ことを特徴とする、付記３記載の情報処理システム。
前記判定部は、
前記他の情報処理装置に係る接続処理済みの端末装置の数が０であり、且つ、前記他の情報処理装置との通信で異常を検出した場合、前記他の情報処理装置の動作状態が前記第３状態であると判定する、
ことを特徴とする、付記３記載の情報処理システム。
（付記５）
前記判定部は、
前記自装置が前記第１状態であり、前記他の情報処理装置が前記第３状態であり、且つ、前記他の情報処理装置との通信で異常を検出しない場合、前記他の情報処理装置の動作状態が前記第２状態であると判定する、
ことを特徴とする、付記４記載の情報処理システム。
前記判定部は、
前記自装置が前記第１状態であり、前記他の情報処理装置が前記第３状態であり、且つ、前記他の情報処理装置との通信で異常を検出しない場合、前記他の情報処理装置の動作状態が前記第２状態であると判定する、
ことを特徴とする、付記４記載の情報処理システム。
（付記６）
前記複数の情報処理装置の各々は、
前記自装置に係る状態情報と前記端末装置から通知された他の情報処理装置の状態情報とを格納するとともに、接続処理済みの前記端末装置を特定する情報を含む接続情報を格納する格納部と、
前記端末装置との間で前記接続処理が行なわれると、当該端末装置を特定する情報を前記接続情報に設定し、前記格納部が格納する前記自装置に係る状態情報に含まれる接続処理済みの端末装置の数を増加させる設定部と、をさらにそなえる
ことを特徴とする、付記１〜５のいずれか１項記載の情報処理システム。
前記複数の情報処理装置の各々は、
前記自装置に係る状態情報と前記端末装置から通知された他の情報処理装置の状態情報とを格納するとともに、接続処理済みの前記端末装置を特定する情報を含む接続情報を格納する格納部と、
前記端末装置との間で前記接続処理が行なわれると、当該端末装置を特定する情報を前記接続情報に設定し、前記格納部が格納する前記自装置に係る状態情報に含まれる接続処理済みの端末装置の数を増加させる設定部と、をさらにそなえる
ことを特徴とする、付記１〜５のいずれか１項記載の情報処理システム。
（付記７）
前記取得部及び前記通知部は、
第１所定時間ごとに、前記複数の情報処理装置の各々に対する前記状態情報の取得及び通知のためのアクセスを行ない、
前記設定部は、
前記自装置に係る接続処理済みの第１の端末装置から、前記第１所定時間よりも長い第２所定時間の間、前記アクセスがなかった場合、当該端末装置を特定する情報を前記接続情報から削除し、前記格納部が格納する前記自装置に係る状態情報に含まれる接続処理済みの端末装置の数を減少させ、
前記自装置との間で前記接続処理が行なわれていない第２の端末装置から、前記第２所定時間の間、前記アクセスがなかった場合、前記格納部が格納する前記第２の端末装置との間で接続処理済みの情報処理装置に係る状態情報に含まれる接続処理済みの端末装置の数を減少させる、
ことを特徴とする、付記６記載の情報処理システム。
前記取得部及び前記通知部は、
第１所定時間ごとに、前記複数の情報処理装置の各々に対する前記状態情報の取得及び通知のためのアクセスを行ない、
前記設定部は、
前記自装置に係る接続処理済みの第１の端末装置から、前記第１所定時間よりも長い第２所定時間の間、前記アクセスがなかった場合、当該端末装置を特定する情報を前記接続情報から削除し、前記格納部が格納する前記自装置に係る状態情報に含まれる接続処理済みの端末装置の数を減少させ、
前記自装置との間で前記接続処理が行なわれていない第２の端末装置から、前記第２所定時間の間、前記アクセスがなかった場合、前記格納部が格納する前記第２の端末装置との間で接続処理済みの情報処理装置に係る状態情報に含まれる接続処理済みの端末装置の数を減少させる、
ことを特徴とする、付記６記載の情報処理システム。
（付記８）
前記複数の端末装置は、前記複数の情報処理装置を公共ネットワーク経由で制御する、
ことを特徴とする、付記１〜７のいずれか１項記載の情報処理システム。
（付記９）
相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置と、前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置と、をそなえた情報処理システムの制御方法であって、
前記端末装置において、
前記複数の情報処理装置の各々から、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を取得し、
前記複数の情報処理装置の各々に、他の情報処理装置から取得した状態情報を通知し、
前記複数の情報処理装置の各々において、
自装置が保持する状態情報と前記端末装置から通知された他の情報処理装置の状態情報とに基づいて、前記自装置が前記所定の処理を行なうか否かを判定する、
ことを特徴とする、制御方法。
前記複数の端末装置は、前記複数の情報処理装置を公共ネットワーク経由で制御する、
ことを特徴とする、付記１〜７のいずれか１項記載の情報処理システム。
（付記９）
相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置と、前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置と、をそなえた情報処理システムの制御方法であって、
前記端末装置において、
前記複数の情報処理装置の各々から、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を取得し、
前記複数の情報処理装置の各々に、他の情報処理装置から取得した状態情報を通知し、
前記複数の情報処理装置の各々において、
自装置が保持する状態情報と前記端末装置から通知された他の情報処理装置の状態情報とに基づいて、前記自装置が前記所定の処理を行なうか否かを判定する、
ことを特徴とする、制御方法。
（付記１０）
相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置の各々を制御する処理を、前記複数の情報処理装置の各々に実行させる制御プログラムであって、
前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置に対して、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を送信し、
前記端末装置から、前記端末装置が他の情報処理装置から取得した状態情報を受信し、
前記情報処理装置が保持する状態情報と前記端末装置から受信した他の情報処理装置の状態情報とに基づいて、前記情報処理装置が前記所定の処理を行なうか否かを判定する、
処理を、前記複数の情報処理装置の各々に実行させることを特徴とする、制御プログラム。
相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置の各々を制御する処理を、前記複数の情報処理装置の各々に実行させる制御プログラムであって、
前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置に対して、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を送信し、
前記端末装置から、前記端末装置が他の情報処理装置から取得した状態情報を受信し、
前記情報処理装置が保持する状態情報と前記端末装置から受信した他の情報処理装置の状態情報とに基づいて、前記情報処理装置が前記所定の処理を行なうか否かを判定する、
処理を、前記複数の情報処理装置の各々に実行させることを特徴とする、制御プログラム。
１ 冗長サーバシステム（情報処理システム）
２，２−１，２−２ ＨＭＩ端末（端末装置）
３，３−１ ０系サーバ（運用系，ＯｐＳサーバ，情報処理装置）
３，３−２ １系サーバ（待機系，ＯｐＳサーバ，情報処理装置）
４ 通信ネットワーク（伝送装置群，制御対象）
５ ネットワーク（公共ネットワーク）
６，７ ネットワーク
１０ａ，１０ｂ ＣＰＵ（プロセッサ）
１１ａ，１１ｂ メモリ
１２ａ，１２ｂ 記憶部
１３ａ，１３ｂ インタフェース
１４ａ，１４ｂ 入出力部
１５ａ，１５ｂ，１７ａ，１７ｂ 記録媒体
１６ａ，１６ｂ 読取部
２１ ＯｐＳサーバ側通信部
２２ ヘルスチェック部
２２ａ 通知部
２２ｂ 第１取得部（取得部）
２３ ログイン／ログオフ処理部
２４ ログイン状態通知部
２４ａ 第２取得部
２５ 保持部
２５ａ 運用切替判断テーブル
３１ ＨＭＩ端末側通信部
３２ コマンド処理部（設定部）
３３ 通信ネットワーク側通信部
３４ ＤＢアクセス部
３５ データベース部（格納部）
３５ａ 運用切替判断テーブル
３５ｂ 運用切替判断基準
３５ｃ ログイン情報
３６ 他系サーバ側通信部
３７ 他系ＡＰ状態監視部
３８ 運用状態判定部（判定部）
１００ 冗長サーバシステム
２００，２００−１，２００−２ ＨＭＩ端末
３００，３００−１ ０系サーバ（運用系，ＯｐＳサーバ）
３００，３００−２ １系サーバ（待機系，ＯｐＳサーバ）
４００ 通信ネットワーク（制御対象）
４００ａ−１，４００ａ−２ ＧＮＥ
４００ｂ−１，４００ｂ−２ ＮＥ
５００，６００，７００ ネットワーク
２，２−１，２−２ ＨＭＩ端末（端末装置）
３，３−１ ０系サーバ（運用系，ＯｐＳサーバ，情報処理装置）
３，３−２ １系サーバ（待機系，ＯｐＳサーバ，情報処理装置）
４ 通信ネットワーク（伝送装置群，制御対象）
５ ネットワーク（公共ネットワーク）
６，７ ネットワーク
１０ａ，１０ｂ ＣＰＵ（プロセッサ）
１１ａ，１１ｂ メモリ
１２ａ，１２ｂ 記憶部
１３ａ，１３ｂ インタフェース
１４ａ，１４ｂ 入出力部
１５ａ，１５ｂ，１７ａ，１７ｂ 記録媒体
１６ａ，１６ｂ 読取部
２１ ＯｐＳサーバ側通信部
２２ ヘルスチェック部
２２ａ 通知部
２２ｂ 第１取得部（取得部）
２３ ログイン／ログオフ処理部
２４ ログイン状態通知部
２４ａ 第２取得部
２５ 保持部
２５ａ 運用切替判断テーブル
３１ ＨＭＩ端末側通信部
３２ コマンド処理部（設定部）
３３ 通信ネットワーク側通信部
３４ ＤＢアクセス部
３５ データベース部（格納部）
３５ａ 運用切替判断テーブル
３５ｂ 運用切替判断基準
３５ｃ ログイン情報
３６ 他系サーバ側通信部
３７ 他系ＡＰ状態監視部
３８ 運用状態判定部（判定部）
１００ 冗長サーバシステム
２００，２００−１，２００−２ ＨＭＩ端末
３００，３００−１ ０系サーバ（運用系，ＯｐＳサーバ）
３００，３００−２ １系サーバ（待機系，ＯｐＳサーバ）
４００ 通信ネットワーク（制御対象）
４００ａ−１，４００ａ−２ ＧＮＥ
４００ｂ−１，４００ｂ−２ ＮＥ
５００，６００，７００ ネットワーク
Claims (6)
- 相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置と、
前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置と、をそなえた情報処理システムであって、
前記端末装置は、
前記複数の情報処理装置の各々から、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を取得する取得部と、
前記複数の情報処理装置の各々に、他の情報処理装置から取得した状態情報を通知する通知部と、をそなえ、
前記複数の情報処理装置の各々は、
自装置が保持する状態情報と前記端末装置から通知された他の情報処理装置の状態情報とに基づいて、前記自装置が前記所定の処理を行なうか否かを判定する判定部をそなえる
ことを特徴とする、情報処理システム。 - 前記状態情報は、
前記情報処理装置が、前記所定の処理を行なう第１状態、及び待機を行なう第２状態、のいずれであるかを示す動作状態をさらに含み、
前記判定部は、
前記自装置が保持する状態情報と前記端末装置から通知された前記他の情報処理装置の状態情報とに基づき、２以上の前記情報処理装置が前記第１状態であると判断した場合、前記２以上の情報処理装置の中から、接続処理済みの端末装置の数に基づいて、一の情報処理装置が前記第１状態であると判定し、前記第１状態であると判定した情報処理装置以外の情報処理装置が前記第２状態であると判定し、
判定した前記動作状態に基づいて、前記自装置が前記所定の処理を行なうか否かを判定する、
ことを特徴とする、請求項１記載の情報処理システム。 - 前記動作状態は、
前記情報処理装置が、前記第１状態、前記第２状態、及び障害が発生したことを示す第３状態、のいずれであるかを示し、
前記判定部は、
前記自装置が保持する状態情報と前記他の情報処理装置の状態情報とに基づいて、前記自装置に係る接続処理済みの端末装置の数が１以上であり、前記自装置が前記第２状態であり、且つ、前記他の情報処理装置が前記第３状態である場合、前記自装置の動作状態が前記第１状態であると判定する、
ことを特徴とする、請求項２記載の情報処理システム。 - 前記複数の情報処理装置の各々は、
前記自装置に係る状態情報と前記端末装置から通知された他の情報処理装置の状態情報とを格納するとともに、接続処理済みの前記端末装置を特定する情報を含む接続情報を格納する格納部と、
前記端末装置との間で前記接続処理が行なわれると、当該端末装置を特定する情報を前記接続情報に設定し、前記格納部が格納する前記自装置に係る状態情報に含まれる接続処理済みの端末装置の数を増加させる設定部と、をさらにそなえる
ことを特徴とする、請求項１〜３のいずれか１項記載の情報処理システム。 - 相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置と、前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置と、をそなえた情報処理システムの制御方法であって、
前記端末装置において、
前記複数の情報処理装置の各々から、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を取得し、
前記複数の情報処理装置の各々に、他の情報処理装置から取得した状態情報を通知し、
前記複数の情報処理装置の各々において、
自装置が保持する状態情報と前記端末装置から通知された他の情報処理装置の状態情報とに基づいて、前記自装置が前記所定の処理を行なうか否かを判定する、
ことを特徴とする、制御方法。 - 相互に通信可能に接続され冗長化された複数の情報処理装置であって、一の情報処理装置が所定の処理を行なう前記複数の情報処理装置の各々を制御する処理を、前記複数の情報処理装置の各々に実行させる制御プログラムであって、
前記複数の情報処理装置のうちの少なくとも一つの情報処理装置と接続処理を行ない、前記接続処理が完了した接続処理済みの情報処理装置の制御を行なう１以上の端末装置に対して、前記情報処理装置に係る接続処理済みの端末装置の数を含む状態情報を送信し、
前記端末装置から、前記端末装置が他の情報処理装置から取得した状態情報を受信し、
前記情報処理装置が保持する状態情報と前記端末装置から受信した他の情報処理装置の状態情報とに基づいて、前記情報処理装置が前記所定の処理を行なうか否かを判定する、
処理を、前記複数の情報処理装置の各々に実行させることを特徴とする、制御プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013086343A JP6044434B2 (ja) | 2013-04-17 | 2013-04-17 | 情報処理システム，制御方法，および制御プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013086343A JP6044434B2 (ja) | 2013-04-17 | 2013-04-17 | 情報処理システム，制御方法，および制御プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2014211674A JP2014211674A (ja) | 2014-11-13 |
| JP6044434B2 true JP6044434B2 (ja) | 2016-12-14 |
Family
ID=51931418
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013086343A Expired - Fee Related JP6044434B2 (ja) | 2013-04-17 | 2013-04-17 | 情報処理システム，制御方法，および制御プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6044434B2 (ja) |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1011369A (ja) * | 1996-06-27 | 1998-01-16 | Hitachi Ltd | 通信システムおよびホットスタンバイ切替機能を備える情報処理装置 |
| JP2001142795A (ja) * | 1999-11-11 | 2001-05-25 | Toshiba Corp | 計算機システムとそのシステムの処理プログラムを記憶した記憶媒体 |
| JP2002251384A (ja) * | 2001-02-23 | 2002-09-06 | Mitsubishi Electric Corp | 広域クラスタ制御方式 |
-
2013
- 2013-04-17 JP JP2013086343A patent/JP6044434B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2014211674A (ja) | 2014-11-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6089884B2 (ja) | 情報処理システム，情報処理装置，情報処理装置の制御プログラム，及び情報処理システムの制御方法 | |
| JP4538736B2 (ja) | ジョブ実行監視システム、ジョブ制御装置、ジョブ実行方法及びジョブ制御プログラム | |
| US20130205017A1 (en) | Computer failure monitoring method and device | |
| JP2008234617A (ja) | 設備監視システム及び監視装置 | |
| JP2014241536A (ja) | 監視装置、及び監視方法 | |
| JP2013161252A (ja) | 冗長コンピュータ制御プログラム、方法、及び装置 | |
| JP5613119B2 (ja) | マスター／スレーブシステム、制御装置、マスター／スレーブ切替方法、および、マスター／スレーブ切替プログラム | |
| JP6044434B2 (ja) | 情報処理システム，制御方法，および制御プログラム | |
| JPWO2018056044A1 (ja) | 計算機並びにクラスタ管理システム、方法及びプログラム | |
| JP6830608B2 (ja) | 通信システム、被制御機器、及び、通信システムの制御方法 | |
| JP2018056633A (ja) | クラスタシステム、サーバ、サーバの動作方法、及びプログラム | |
| JP2006277646A (ja) | 障害解析システム及び方法並びにプログラム | |
| JP2015057685A (ja) | 監視システム | |
| JP5005425B2 (ja) | 制御装置復帰システム | |
| JP4836920B2 (ja) | ネットワーク監視システム及び端末装置 | |
| JP6488600B2 (ja) | 情報処理システム、プログラム及び情報処理装置 | |
| JP5631285B2 (ja) | 障害監視システムおよび障害監視方法 | |
| JP2004007930A (ja) | 電力系統監視制御システムおよびプログラム | |
| JP2011250033A (ja) | 監視システム及びサーバ切替方法 | |
| US20240323074A1 (en) | Computer-Implemented Method for Operating a Terminal with High Availability in a Network | |
| WO2018235310A1 (ja) | 切替管理装置、監視制御システム、切替管理方法および切替管理プログラム | |
| JP2013003956A (ja) | 故障復旧管理装置、故障復旧管理方法及び故障復旧管理プログラム | |
| JP6851273B2 (ja) | プラント監視制御装置 | |
| WO2013073022A1 (ja) | 計算機システム及び障害検出方法 | |
| JP5836177B2 (ja) | 運用システム切り替え装置、運用システム切り替え方法及び運用システム切り替えプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160113 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20160930 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20161018 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20161031 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6044434 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |