特許 7192893 ネットワークシステム及びネットワークシステムの制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-12-12

(45)【発行日】2022-12-20

(54)【発明の名称】ネットワークシステム及びネットワークシステムの制御方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20221213BHJP

【ＦＩ】

G06F9/50 150C

【請求項の数】 9

(21)【出願番号】P 2020569634

(86)(22)【出願日】2020-01-28

(86)【国際出願番号】 JP2020002907

(87)【国際公開番号】W WO2020158706

(87)【国際公開日】2020-08-06

【審査請求日】2021-07-28

(31)【優先権主張番号】P 2019013481

(32)【優先日】2019-01-29

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100080816

【弁理士】

【氏名又は名称】加藤 朝道

(74)【代理人】

【識別番号】100098648

【弁理士】

【氏名又は名称】内田 潔人

(72)【発明者】

【氏名】林 昇輝

【審査官】漆原 孝治

(56)【参考文献】

【文献】特開２０１８－０６７０３８（ＪＰ，Ａ）

【文献】鶴長 鎮一，ネットワークエンジニア養成 ロードバランサの教科書，ＳｏｆｔｗａｒｅＤｅｓｉｇｎ ，日本，（株）技術評論社，2014年04月18日，282号，pp.54-62

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

それぞれが、データベースサーバと、監視端末からの前記データベースサーバへのアクセス要求を中継するアクセスサーバと、を含む第１及び第２の管理システムと、
前記監視端末から前記アクセスサーバに送信されるアクセス要求を受け、前記アクセス要求の種別に基づき、前記アクセス要求の送信先を、前記第１及び第２の管理システムのうちいずれの管理システムに含まれる前記アクセスサーバとするかを決定するフロントエンドサーバと、
を含み、
前記フロントエンドサーバは、前記監視端末から送信されたアクセス要求を受信すると、前記データベースサーバへのアクセスが、予め定められた所定の回数以上連続する第１のパターン又は前記所定の回数よりも少なく連続する第２のパターンのいずれかであるかに分類し、分類結果に基づき、前記第１又は第２の管理システムの前記アクセスサーバの中から前記アクセス要求の送信先を決定する、ネットワークシステム。

【請求項2】

前記フロントエンドサーバは、前記アクセス要求が前記第１のパターンに分類される場合、前記第１又は第２の管理システムのうち、前記データベースサーバがアクティブ状態である管理システムに含まれる前記アクセスサーバを、前記アクセス要求の送信先として決定する、請求項１に記載のネットワークシステム。

【請求項3】

前記フロントエンドサーバは、前記アクセス要求が前記第２のパターンに分類される場合、前記第１又は第２の管理システムのうち前記データベースサーバがアクティブ状態である管理システムとは異なる管理システムに含まれる前記アクセスサーバを、前記アクセス要求の送信先として決定する、請求項１又は２に記載のネットワークシステム。

【請求項4】

前記フロントエンドサーバは、前記第１及び第２の管理システムに含まれる複数のアクセスサーバのうちアクティブ状態のアクセスサーバのいずれかを、前記アクセス要求の送信先として決定する、請求項１乃至３のいずれか一項に記載のネットワークシステム。

【請求項5】

前記第１及び第２の管理システムは、それぞれ、複数の前記アクセスサーバを含み、
前記フロントエンドサーバは、前記アクセス要求の送信先となるアクセスサーバを、予め定められた優先順位にしたがって決定する、請求項１乃至３のいずれか一項に記載のネットワークシステム。

【請求項6】

前記第１及び第２の管理システムのそれぞれは、前記フロントエンドサーバを含み、
前記監視端末は、前記第１又は第２の管理システムに含まれる前記フロントエンドサーバから前記アクセス要求に関する応答が無い場合には、前記応答がないフロントエンドサーバを含む管理システムとは異なる管理システムに含まれる前記フロントエンドサーバに、前記アクセス要求を送信する、請求項１乃至５のいずれか一項に記載のネットワークシステム。

【請求項7】

前記第１及び第２の管理システムにそれぞれ含まれるデータベースサーバ間の同期を実現する同期サーバをさらに備える、請求項１乃至６のいずれか一項に記載のネットワークシステム。

【請求項8】

前記同期サーバは、前記第１及び第２の管理システムにそれぞれ含まれる前記データベースサーバの状態を管理し、
前記フロントエンドサーバは、前記同期サーバで前記データベースサーバに関する管理ができない場合には、前記データベースサーバに対して、状態確認要求を送信し、前記状態確認要求への応答に基づき、前記データベースサーバの状態を管理する、請求項７に記載のネットワークシステム。

【請求項9】

それぞれが、データベースサーバと、監視端末からの前記データベースサーバへのアクセス要求を中継するアクセスサーバと、を含む第１及び第２の管理システムを備えるネットワークシステムの制御方法であって、
前記監視端末から前記アクセスサーバに送信されるアクセス要求の種別を判定し、
前記アクセス要求の種別に基づき、前記アクセス要求の送信先を、前記第１及び第２の管理システムのうちいずれの管理システムに含まれる前記アクセスサーバとするかを決定し、
前記アクセス要求の送信先の決定にあたり、前記監視端末から送信された前記アクセス要求を受信すると、前記データベースサーバへのアクセスが、予め定められた所定の回数以上連続する第１のパターン又は前記所定の回数よりも少なく連続する第２のパターンのいずれかであるかに分類し、分類結果に基づき、前記第１又は第２の管理システムの前記アクセスサーバの中から前記アクセス要求の送信先を決定する、ネットワークシステムの制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願についての記載］
本発明は、日本国特許出願：特願２０１９－０１３４８１号（２０１９年１月２９日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、ネットワークシステム及びネットワークシステムの制御方法に関する。

【背景技術】

【0002】

図２は、地理的分散ネットワークシステムの関連技術の一例を説明するための図である。図２には、東西の２拠点にネットワークマネジメントシステム（Network Management System：図ではＮＭＳと表記する）を配置した構成が模式的に例示されている。

【0003】

図２に示すネットワークシステムにおいて、ネットワークマネジメントシステム（ＮＭＳ）は、ネットワーク装置（Network Element：図ではＮＥと表記する）１１－１～１１－ｎ（ｎは正の整数）の状態の監視や、設定変更のオペレーションを実行する。当該ネットワークマネジメントシステム（ＮＭＳ）は、災害対策のため、例えば地理的に離れた東西２つの拠点にそれぞれ、ＮＭＳ東１０－１、ＮＭＳ西１０－２として配置されている。

【0004】

保守者は、ＮＭＳ東１０－１、ＮＭＳ西１０－２と同一拠点もしくは別の拠点に存在する監視端末１９－１～１９－ｚ（ｚは正の整数、以下同じ）からＮＭＳ東１０－１又はＮＭＳ西１０－２を通して、ネットワーク装置（ＮＥ１１－１～ＮＥ１１－ｎ）の保守を行う。具体的には、アクセスサーバ（Access Server：図ではＡＣと表記する）１４－１Ｅ～１４－４Ｅ、アクセスサーバ（ＡＣ）１８－１Ｗ～１８－４Ｗは、監視端末１９－１～１９－ｚからの処理要求を受け付ける。

【0005】

アクセスサーバ（ＡＣ）は、データベースサーバ（Database Server：図ではＤＢと表記する）１３Ｅ又は１６Ｗに対してデータベースのアクセスを行う。アクセスサーバ（ＡＣ）は、アクティブ状態（Active：ＡＣＴと略記する）又はスタンバイ状態（Standby：ＳＢＹと略記する）を取り得る。図２を含む図面では、アクセスサーバ（ＡＣ）の状態（ＡＣＴ又はＳＢＹ）を、アクセスサーバ（ＡＣ）を示すボックスの中に括弧書きにて併記している。アクセスサーバ（ＡＣ）において、アクティブ状態（ＡＣＴ）の場合、監視端末からの処理要求を受けて、データベースサーバ（ＤＢ）１３Ｅ又は１６Ｗに対して、データベースアクセス要求（読み出し要求／書き込み要求）を送信できるが、スタンバイ状態（ＳＢＹ）の場合、当該要求を送信することはできない。

【0006】

アクティブ状態（ＡＣＴ）に設定可能なアクセスサーバ（ＡＣ）の台数の上限（すなわち、ＮＭＳ東１０－１、ＮＭＳ西１０－２において全てのＡＣＴ状態のアクセスサーバ（ＡＣ）を合算した上限）には、アクセスサーバ（ＡＣ）とデータベースサーバ（ＤＢ）間のネットワークトラフィック増大の観点や、データベースサーバ（ＤＢ）のサーバ処理負荷増大の観点から、制限が設けられている。特に制限されないが、図２には、アクティブ状態（ＡＣＴ）に設定可能な台数の上限が４台の場合を示している。

【0007】

マネージメントサーバ（Management server：図ではＭＧと表記する）１２－１Ｅ～１２－ｙＥ、１５－１Ｗ～１５ｙＷは、例えばネットワーク装置（ＮＥ）１１－１～１１－ｎからの障害通知の受信や設定変更通知の受信等を行う。

【0008】

同期サーバ（Synchronous server：図ではＳＣと表記する）１７は、２台のデータベースサーバ（ＤＢ）１３Ｅ及び１６Ｗの内容の同期の監視、制御を行う。

【0009】

データベースサーバ（ＤＢ）１３Ｅと１６Ｗのいずれか一方がアクティブ状態（ＡＣＴ）とされ、データベース読み出し要求／データベース書き込み要求に応答可能とされる。しかし、他の一方は、アクティブ状態（ＡＣＴ）の該一方のデータベースサーバと同期しているスタンバイ状態（ＳＢＹ）であり、データベース読み出し要求／データベース書き込み要求には応答できないものとする。

【0010】

ここで、図２に示す関連技術のネットワークシステムでは、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点に配置されているアクセスサーバ（ＡＣ）に処理を振り分ける仕組みが存在しない。このため、監視端末が処理要求を送信するアクセスサーバ（ＡＣ）は、例えば該監視端末内に保持されている設定ファイルに基づき、静的に、決められている。

【0011】

特許文献１には、自身が設置された自拠点の複数の処理サーバ、または前記自拠点から離隔した他拠点の複数の処理サーバに対して、クライアントからリクエストされた情報処理を実行させる処理サーバを決定する負荷分散装置（方法）として、処理サーバの情報を収集するための信号量を減らしつつ、応答時間と処理サーバの処理負荷を減らすことができる負荷分散装置（方法）が開示されている。

【先行技術文献】

【特許文献】

【0012】

【文献】特開２０１７－１０７３５３号公報

【発明の概要】

【発明が解決しようとする課題】

【0013】

なお、上記先行技術文献の開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。

【0014】

上記した関連技術のネットワークシステムには、例えば以下のような問題点がある。

【0015】

第１の問題は、異なる拠点間のデータベースサーバ－アクセスサーバ（ＤＢ－ＡＣ）間のデータベース（ＤＢ）読み出し／書き込みによる保守者の操作性が低下する、ということである。図３は、図２のデータベースサーバ（ＤＢ）の動作例を説明するためのシーケンス図である。図３には、図２のネットワークシステムでの監視端末における処理要求シーケンスとして、図２の監視端末が処理要求を送信してから処理応答を受信するまでのシーケンスが示されている。

【0016】

図３において、図２のデータベースサーバ（ＤＢ）１３Ｅがアクティブ状態（ＡＣＴ）であり、データベースサーバ（ＤＢ）１６Ｗがスタンバイ状態（ＳＢＹ）であるものとする。なお、図３を含む図面において、ＮＭＳ東のシステムに含まれる要素には、ＡＣ－Ｅ、ＤＢ－Ｅ等のように、要素名の末尾に「－Ｅ」を付与し、ＮＭＳ西のシステムに含まれる要素には、ＤＢ－Ｗ等のように、要素名の末尾に「－Ｗ」を付与する。また、各図に含まれるアクセスサーバＡＣ（ｘ）、ＡＣ－Ｅ（ｘ）、ＡＣ－Ｗ（ｘ）において、「ｘ」は１～４の任意の整数である。

【0017】

監視端末からの処理要求は、アクセスサーバ（ＡＣ）１４－１Ｅ～１４－４Ｅ、アクセスサーバ（ＡＣ）１８－１Ｗ～１８－４Ｗのいずれかが受け付ける（図３では、アクティブ状態のＡＣ－Ｅ（ｘ））。それぞれのアクセスサーバ（ＡＣ）は、受け付けた処理要求に基づき、データベースサーバ（ＤＢ）１３Ｅ、データベースサーバ（ＤＢ）１６Ｗに、例えばデータベース（ＤＢ）読み出し要求を送信する。その際、アクセスサーバ（ＡＣ）とデータベースサーバ（ＤＢ）間のデータベース読み出し要求と応答は、連続して、数百回、数千回以上の回数、続く可能性がある。

【0018】

このとき、図３に示されるように、同一拠点内のデータベースサーバ－アクセスサーバ（ＤＢ－ＡＣ）間でデータベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求、およびデータベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答を処理するシーケンスＳ２１０１と、異なる拠点のＤＢ－ＡＣ間でデータベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求とデータベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答を処理するシーケンスＳ２２０１がある。

【0019】

図３において、同一拠点内のＤＢ－ＡＣ間でデータベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求、およびデータベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答を処理するシーケンスＳ２１０１では、１回あたりのＤＢ－ＡＣ間でのデータベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求から、データベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答までのレスポンス時間が短い。このため、データベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求、およびデータベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答が連続して繰り返されても、処理要求Ｓ２１１から処理応答Ｓ２１４までの処理時間が大きく増加することはない。すなわち、同じ拠点のＤＢ－ＡＣ間でのデータベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求、およびデータベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答を処理する場合（Ｓ２１０１）には、１回あたりのデータベース（ＤＢ）読み出し／データベース（ＤＢ）書き込みの処理時間が短い。このため、当該データベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求が、ＤＢ－ＡＣ間で、連続して多数回行なわれた場合であっても、処理要求Ｓ２１１～処理応答Ｓ２１４までの時間は特段に長くはならない。

【0020】

一方、図３において、異なる拠点のＤＢ－ＡＣ間でデータベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求、およびデータベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答を処理するシーケンスＳ２２０１では、１回あたりのＤＢ－ＡＣ間でのデータベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求から、データベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答までのレスポンス時間は長くなる。このため、データベース（ＤＢ）読み出し要求／データベース（ＤＢ）書き込み要求、データベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答が連続して繰り返されると、処理要求Ｓ２２１から処理応答Ｓ２２４までの処理時間が大幅に増加する。すなわち、異なる拠点のＤＢ－ＡＣ間でデータベース（ＤＢ）読み出し／書き込み要求、およびデータベース（ＤＢ）読み出し応答／データベース（ＤＢ）書き込み応答を処理する場合（Ｓ２２０１）には、１回あたりのデータベース（ＤＢ）読み出し／データベース（ＤＢ）書き込みの処理時間が長くなる。その結果、データベース（ＤＢ）読み出し／データベース（ＤＢ）書き込みが、異なる拠点のＤＢ－ＡＣ間で連続して多数回行なわれると、処理要求Ｓ２２１～処理応答Ｓ２２４までの時間は、同一拠点内でのＤＢ－ＡＣ間のシーケンスＳ２１０１と比べて大幅に長くなる。

【0021】

処理要求から処理応答までの時間の大幅な増加は、保守者が監視端末を操作するときの操作性が大きく損なわれる原因となる。つまり、「異なる拠点間のＤＢ－ＡＣ間のデータベース（ＤＢ）読み出し／書き込み」時のレスポンスの遅れが第１の問題である。

【0022】

例えば、図２に示すネットワークシステムにおいて、第１の問題が発生した場合、同じ拠点内のアクセスサーバ－データベースサーバ（ＡＣ－ＤＢ）間のアクセスが行われた場合、特定の画面描画処理が例えば１分で完了するところを、異なる拠点間のＡＣ－ＤＢ間でアクセスを行った場合に、例えば３０分を要する、という事態も生じ得る。保守者が、１画面の表示で３０分待たなければならないという状況は、保守操作性等に大きな制限を課すことになる。

【0023】

例えば、図２に示すネットワークシステムにおいて、データベースサーバ（ＤＢ）１３ＥがＡＣＴ系、データベースサーバ（ＤＢ）１６ＷがＳＢＹ系にある状況から、ＡＣＴ系のデータベースサーバ（ＤＢ）１３Ｅにおいて例えばハードウェア障害の発生などにより、該データベースサーバ（ＤＢ）１６ＥをＡＣＴ系からＳＢＹ系とし、データベースサーバ（ＤＢ）１６ＷをＳＢＹ系からＡＣＴ系とする系切り替えが発生した場合について説明する。この場合、データベースサーバ（ＤＢ）１３Ｅのハードウェア障害の復旧、データベースサーバ（ＤＢ）１３Ｅのデータベースをデータベースサーバ（ＤＢ）１６Ｗのデータベースと同期させる処理、ＡＣＴ系をデータベースサーバ（ＤＢ）１６Ｗからデータベースサーバ（ＤＢ）１３Ｅに切り替える処理が完了するまでの間、異なる拠点間のＡＣ－ＤＢ間のデータベースアクセス（アクセスサーバＡＣ－Ｅ（ｘ）からデータベースサーバＤＢ－Ｗへのアクセス）が行われ、保守者は、第１の問題の制限の下での保守を強いられる。

【0024】

第２の問題は、保守者がシステムを利用することができない時間が発生する、という問題である。

【0025】

保守者の操作性を損なわないためには、ＡＣＴ状態のアクセスサーバ（ＡＣ）とＡＣＴ状態のデータベースサーバ（ＤＢ）が同一拠点に存在することが必要になる。そこで、仮想化技術を使って、アクセスサーバ（ＡＣ）１４－１Ｅ～１４－４Ｅ、アクセスサーバ（ＡＣ）１８－１Ｗ～１８－４Ｗを全て仮想化する。そして、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点の仮想化されたアクセスサーバ（ＡＣ－ＶＭ（Virtual Machine））を全てＡＣＴ状態とし、他方の拠点の仮想化されたアクセスサーバ（ＡＣ－ＶＭ）の全てを停止させておく、という構成が考えられる。

【0026】

例えば、アクセスサーバ（ＡＣ）を監視する監視サーバを新たに用意する。当該監視サーバは、ＡＣＴ状態のデータベースサーバ（ＤＢ）に障害が発生した際に、それまでＡＣＴ状態であったアクセスサーバ（ＡＣ－ＶＭ）を全て停止させ、さらに、停止していたアクセスサーバ（ＡＣ－ＶＭ）に対して、仮想マシンの起動処理を実施してＡＣＴ状態とする。このような処理により、ＡＣＴ状態のアクセスサーバ（ＡＣ－ＶＭ）とＡＣＴ状態のデータベースサーバ（ＤＢ）を同一拠点に存在させることができる。

【0027】

しかし、上記構成は、アクセスサーバ（ＡＣ－ＶＭ）の停止と起動を伴うため、当該処理が終了するまでは、保守者が保守を実施することができない、という問題がある。つまり、「保守者がシステム利用できない期間の発生」が第２の問題点である。

【0028】

本発明は、保守者の操作性が低下することを防止することに寄与する、ネットワークシステム及びネットワークシステムの制御方法を提供することを主たる目的とする。

【課題を解決するための手段】

【0029】

本発明乃至開示の第１の視点によれば、それぞれが、データベースサーバと、監視端末からの前記データベースサーバへのアクセス要求を中継するアクセスサーバと、を含む第１及び第２の管理システムと、前記監視端末が前記アクセスサーバに送信するアクセス要求の種別に基づき、前記アクセス要求の送信先を、前記第１及び第２の管理システムのうちいずれの管理システムに含まれるアクセスサーバとするかを決定する、フロントエンドサーバと、を含む、ネットワークシステムが提供される。

【0030】

本発明乃至開示の第２の視点によれば、それぞれが、データベースサーバと、監視端末からの前記データベースサーバへのアクセス要求を中継するアクセスサーバと、を含む第１及び第２の管理システムを備えるネットワークシステムにおいて、前記監視端末が前記アクセスサーバに送信するアクセス要求の種別を判定するステップと、前記アクセス要求の種別に基づき、前記アクセス要求の送信先を、前記第１及び第２の管理システムのうちいずれの管理システムに含まれるアクセスサーバとするかを決定するステップと、を含むネットワークシステムの制御方法が提供される。

【発明の効果】

【0031】

本発明乃至開示の各視点によれば、保守者の操作性が低下することを防止することに寄与する、ネットワークシステム及びネットワークシステムの制御方法が、提供される。

【図面の簡単な説明】

【0032】

【図1】本発明の一実施形態の概要を説明するための図である。

【図2】東西の２拠点にネットワークマネジメントシステムを配置した構成（関連技術）を示す図である。

【図3】図２におけるデータベースサーバの動作を説明するためのシーケンス図である。

【図4】本発明の第１の実施形態に係るネットワークマネージメントシステム（ＮＭＳ）の構成の一例を示す図である。

【図5】本発明の第１の実施形態においてフロントエンドサーバ（ＦＥ）を利用した処理要求振り分けの一例を説明するための図である。

【図6】本発明の第１の実施形態においてフロントエンドサーバ（ＦＥ）を利用した処理要求振り分けの一例を説明するための図である。

【図7】本発明の第１の実施形態においてフロントエンドサーバ（ＦＥ）を利用した処理要求振り分けの一例を説明するための図である。

【図8】本発明の第１の実施形態においてアクセス要求から処理応答までの動作の一例を示すシーケンス図である。

【図9】本発明の第１の実施形態においてアクセス要求から処理応答までの動作の一例を示すシーケンス図である。

【図10】本発明の第１の実施形態においてアクセス要求からアクセス先のアクセスサーバ（ＡＣ）からの応答の一例を示すシーケンス図である。

【図11】本発明の第１の実施形態においてアクセス先のアクセスサーバ（ＡＣ）の検索処理手順の一例を示すフローチャートである。

【図12】本発明の第１の実施形態においてアクセス先のアクセスサーバ（ＡＣ）の検索処理手順の一例を示すフローチャートである。

【図13】本発明の第１の実施形態において東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かを検索する処理手順の一例を示すフローチャートである。

【図14】本発明の第１の実施形態においてＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かを検索する処理手順の一例を示すフローチャートである。

【図15】本発明の第１の実施形態においてプライマリフロントエンドサーバ（ｐｒｉｍａｒｙ ＦＥ）の障害時にセカンダリフロントエンドサーバ（ｓｅｃｏｎｄａｒｙ ＦＥ）がアクセス要求を処理する一例を示すシーケンス図である。

【図16】本発明の第１の実施形態においてフロントエンドサーバ（ＡＣ）ヘルスチェック正常パターンの一例を示すシーケンス図である。

【図17】本発明の第１の実施形態においてフロントエンドサーバ（ＡＣ）ヘルスチェック障害パターンの一例を示すシーケンス図である。

【図18】本発明の第１の実施形態において同期サーバ（ＳＣ）、データベースサーバ（ＤＢ）ヘルスチェック正常パターンの一例を示すシーケンス図である。

【図19】本発明の第１の実施形態において同期サーバ（ＳＣ）、データベースサーバ（ＤＢ）ヘルスチェックにてＳＣ障害パターンの一例を示すシーケンス図である。

【図20】本発明の第１の実施形態においてＦＥ-Ｅ設定ファイルとＦＥ－Ｅ状態テーブルの一例を示す図である。

【図21】本発明の第１の実施形態においてデータベースサーバ（ＤＢ）、同期サーバ（ＳＣ）及びアクセスサーバ（ＡＣ）それぞれの状態を定義する図である。

【図22】本発明の第１の実施形態において同期サーバ（ＳＣ）、データベースサーバ（ＤＢ）ヘルスチェック応答パターンと、ＡＣＴ データベースサーバ（ＤＢ）の判定とその説明に関する図である。

【図23】本発明の第１の実施形態において監視端末 設定ファイルの一例を示す図である。

【図24】本発明の第１の実施形態において要求ＩＤ－要求パターン対応表の一例を示す図である。

【図25】本発明の第２の実施形態において、アクセスサーバ（ＡＣ）に障害が発生し、他のアクセスサーバ（ＡＣ）をＡＣＴ化する場合の動作を説明するための図である。

【図26】本発明の第２の実施形態において、アクセスサーバ（ＡＣ）のＡＣＴ化の一例を示すシーケンス図である。

【図27】本発明の第２の実施形態において、ＮＭＳ東の全サーバに障害が発生しＮＭＳ西のアクセスサーバ（ＡＣ）をＡＣＴ化する場合の動作を説明するための図である。

【図28】本発明の第２の実施形態において、アクセスサーバ（ＡＣ）のＡＣＴ化の一例を示すシーケンス図である。

【図29】本発明の第２の実施形態において、フロントエンドサーバ（ＦＥ）のハードウェア構成の一例を示す図である。

【発明を実施するための形態】

【0033】

初めに、本発明の一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。さらに、本願開示に示す回路図、ブロック図、内部構成図、接続図などにおいて、明示は省略するが、入力ポート及び出力ポートが各接続線の入力端及び出力端のそれぞれに存在する。入出力インターフェイスも同様である。

【0034】

一実施形態に係るネットワークシステムは、第１の管理システム１０１と、第２の管理システム１０２と、フロントエンドサーバ１０３と、を含む（図１参照）。第１の管理システム１０１と第２の管理システム１０２のそれぞれは、データベースサーバ１１１と、監視端末からのデータベースサーバへのアクセス要求を中継するアクセスサーバ１１２と、を含む。フロントエンドサーバ１０３は、監視端末がアクセスサーバ１１２に送信するアクセス要求の種別に基づき、アクセス要求を第１の管理システム１０１又は第２の管理システム１０２のいずれかに送信するかを決定する。

【0035】

ここで、監視端末がアクセスサーバ（ＡＣ）に送出すアクセス要求の種別によって、データベース（ＤＢ）アクセス要求が連続する種別（パターンＡ）と、それ以外の種別（パターンＢ）と、に分類することができる。本願開示では、パターンＡ、Ｂの要求を、東西どちらの管理システム（ＮＭＳ）に適切に振り分けるかを決定する仕組みを導入することで、少なくとも上記した第１、第２の問題を解決する。

【0036】

上記第１の問題（監視端末を操作する保守者の操作性が低下する）が発生するのは、パターンＡの要求に対して、ＡＣＴ状態のデータベースサーバ（ＤＢ）とは別拠点のアクセスサーバ（ＡＣ）で処理を行っている場合である。つまり、パターンＡの要求に対して、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点に存在するアクセスサーバ（ＡＣ）に処理をさせると、上記第１の問題は発生しない。その際、パターンＢの要求は、ＡＣＴ状態のデータベースサーバ（ＤＢ）と別の拠点（ＳＢＹ状態のデータベースサーバ（ＤＢ）が配置されている拠点）に存在するアクセスサーバ（ＡＣ）で処理を行わせると、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点のアクセスサーバ（ＡＣ）に負荷が集中することを回避できる、という利点が生じる。

【0037】

第２の問題（保守者がシステム利用できない時間が発生する）に関しては、東西両方のＮＭＳに、ＡＣＴ状態のアクセスサーバ（ＡＣ）を稼動させておき、データベースサーバ（ＤＢ）の状態（ＡＣＴ／ＳＢＹ状態）によって、東西のＮＭＳのアクセスサーバ（ＡＣ）に処理要求を適切に振り分けることで、東西のＮＭＳの全てのアクセスサーバ（ＡＣ）が停止する状況を避けることができる。その結果、第２の問題の発生を防止できる。

【0038】

さらに、ＡＣＴ状態のデータベースサーバ（ＤＢ）に単独障害が発生した場合や、東西いずれかの拠点の全てのサーバが同時に障害になった場合でも、上記第１及び第２の問題の発生を防ぐことができる。

【0039】

具体的には、以下の機能をもつフロントエンドサーバ（Front end server：図ではＦＥと表記する）を、東西拠点に用意することで、アクセスサーバ（ＡＣ）への処理要求を適切に振り分ける仕組みを実現する。

【0040】

フロントエンドサーバ（ＦＥ）は、同期サーバ（ＳＣ）に対して定期的に、東西のＮＭＳのデータベースサーバ（ＤＢ）の状態を確認する。フロントエンドサーバ（ＦＥ）は、例えば同期サーバ（ＳＣ）からの応答がない場合には、東西のＮＭＳのデータベースサーバ（ＤＢ）の状態を、フロントエンドサーバ（ＦＥ）自身が確認する。また、フロントエンドサーバ（ＦＥ）は、東西の全てのアクセスサーバ（ＡＣ）の状態を、定期的に確認する。フロントエンドサーバ（ＦＥ）は、監視端末からのアクセス要求を受けて、アクセス要求の種別が、データベース（ＤＢ）アクセス要求が連続するパターン（パターンＡ）に該当するか、それ以外のパターン（パターンＢ）であるか、に分類する。

【0041】

アクセス要求の種別がパターンＡに属する場合、フロントエンドサーバ（ＦＥ）は、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在する場合は、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点にあるＡＣＴ状態のアクセスサーバ（ＡＣ）に対して監視端末が処理要求（アクセス要求）を出すように、監視端末に、アクセス先のアクセスサーバ（ＡＣ）を通知する。ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在せず、異なる拠点に、ＡＣＴ状態のアクセスサーバ（ＡＣ）が存在する場合、保守者の操作性は低下するが、その状態でも、できる限り保守業務を継続できるように、フロントエンドサーバ（ＦＥ）は、別の拠点のＡＣＴ状態のアクセスサーバ（ＡＣ）を、監視端末にアクセス先のアクセスサーバ（ＡＣ）として通知する。

【0042】

アクセス要求の種別がパターンＢに属する場合、ＡＣＴ状態のデータベースサーバ（ＤＢ）と異なる拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在する場合には、フロントエンドサーバ（ＦＥ）は、ＡＣＴ状態のデータベースサーバ（ＤＢ）とは異なる拠点にあるＡＣＴ状態のアクセスサーバ（ＡＣ）に対して、監視端末が処理要求（アクセス要求）を送信するように、監視端末に対して、該異なる拠点のＡＣＴ状態のアクセスサーバ（ＡＣ）を、アクセス先のアクセスサーバ（ＡＣ）として通知する。

【0043】

アクセス要求の種別がパターンＢに属する場合、ＡＣＴ状態のデータベースサーバ（ＤＢ）と異なる拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在せず、同じ拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在する場合には、フロントエンドサーバ（ＦＥ）は、監視端末に対して、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点のＡＣＴ状態のアクセスサーバ（ＡＣ）を、アクセス先のアクセスサーバ（ＡＣ）として通知する。かかる構成により、例えば災害対策のために、遠隔地にサーバを分散配置したネットワーク装置について、データベース障害や、拠点被災による拠点内全サーバ障害時に、保守者の操作性を低下させないように、最適なサーバ間通信の振り分けを行うことができる。

【0044】

以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。

【0045】

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

【0046】

図４は、第１の実施形態に係るネットワークマネージメントシステム（ＮＭＳ）の構成の一例を示す図である。図４に示すように、ＮＭＳはＮＭＳ東３０－１とＮＭＳ西３０－２を含む。図４に示すシステムは、図２に示すＮＭＳ東、ＮＭＳ西に、それぞれフロントエンドサーバ（ＦＥ）３３Ｅ、３７Ｗが追加されている。

【0047】

ＮＭＳ東３０－１、ＮＭＳ西３０－２には、１台のデータベースサーバ（ＤＢ）と、複数台のアクセスサーバ（ＡＣ）と、１台のフロントエンドサーバ（ＦＥ）と、０又は１台の同期サーバ（ＳＣ）と、複数台のマネージメントサーバ（ＭＧ）と、が含まれる。なお、図４を含む以降の図面において、アクセスサーバ（ＡＣ）の台数を４台としているが、これは例示であって、アクセスサーバ（ＡＣ）の台数は４台に制限されるものでないことは勿論である。また、マネージメントサーバ（ＭＧ）については、図４以降の図面でも東西のＮＭＳ内に存在するが、実施形態の動作に直接関与しないため示されていない。

【0048】

データベースサーバ（ＤＢ）に関して、同期サーバ（ＳＣ）をＮＭＳ東３０－１、ＮＭＳ西３０－２のいずれかに１台配置することで、複数のデータベースサーバ（ＤＢ）サーバ同士でデータベース内容の同期をすることができる。ＮＭＳでは、データベースサーバ（ＤＢ）は１台がＡＣＴ状態であり、データベースアクセス要求に応答する。他のデータベースサーバ（ＤＢ）は、ＡＣＴ状態のデータベースサーバ（ＤＢ）とデータベース内容を同期しており、データベース読み出し要求に対して、要求された情報を応答として返さない状態である。当該状態をＳＢＹという。データベースサーバ（ＤＢ）は、物理マシン（Physical Machine）でもよいし仮想マシン(Virtual Machine)であってもよい。

【0049】

アクセスサーバ（ＡＣ）は、監視端末からの処理要求を受けると、ＡＣＴ状態のデータベースサーバ（ＤＢ）に、例えばデータベース（ＤＢ）読み出し要求を送信し、データベース（ＤＢ）読み出し応答を受信する。データベース（ＤＢ）読み出し要求とその応答は複数回連続して繰り返されることがある。その後、アクセスサーバ（ＡＣ）は、監視端末に処理応答を返す。

【0050】

監視端末からアクセスサーバ（ＡＣ）ヘルスチェック要求を受けたとき、アクセスサーバ（ＡＣ）は、アクセスサーバ（ＡＣ）の状態（自装置の状態）がＡＣＴである場合、アクセスサーバ（ＡＣ）ヘルスチェック応答でＡＣＴである旨を監視端末に返す。アクセスサーバ（ＡＣ）の状態がＳＢＹである場合、アクセスサーバ（ＡＣ）は、アクセスサーバ（ＡＣ）ヘルスチェック応答でＳＢＹである旨を監視端末に返す。アクセスサーバ（ＡＣ）は物理マシンでも仮想マシンでもよい。

【0051】

フロントエンドサーバ（ＦＥ）は、データベースサーバ（ＤＢ）の状態を定期的に同期サーバ（ＳＣ）に問い合わせ、東西のＮＭＳのそれぞれのデータベースサーバ（ＤＢ）の状態を確認する。同期サーバ（ＳＣ）の応答がない場合は、フロントエンドサーバ（ＦＥ）から東西のＮＭＳのデータベースサーバ（ＤＢ）状態確認要求を送信し、データベースサーバ（ＤＢ）の状態を確認する。また、フロントエンドサーバ（ＦＥ）は、東西のＮＭＳの全てのアクセスサーバ（ＡＣ）にヘルスチェック要求を送信することで、東西のＮＭＳに含まれる全てのアクセスサーバ（ＡＣ）の状態を確認する。

【0052】

フロントエンドサーバ（ＦＥ）は、監視端末からのアクセス要求を受けると、アクセス要求の種別（要求ＩＤ（Identifier））に基づき、データベースサーバ（ＤＢ）アクセス回数が多い処理（パターンＡ）と、データベースサーバ（ＤＢ）アクセス回数が少ない処理（パターンＢ）とに分類する。つまり、パターンＡは、データベースサーバへのアクセスが、所定の回数以上連続する場合であり、パターンＢは上記アクセスが当該所定の回数よりも少なく連続する場合である。

【0053】

アクセス要求の種別がパターンＡの場合は、フロントエンドサーバ（ＦＥ）は、ＡＣＴ状態のデータベースサーバ（ＤＢ）が存在する拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かを確認する。その際、複数のアクセスサーバ（ＡＣ）が存在している場合は、フロントエンドサーバ（ＦＥ）は、前回の処理要求の対象アクセスサーバ（ＡＣ）とは別のアクセスサーバ（ＡＣ）を今回の処理要求の対象とするように、フロントエンドサーバ（ＦＥ）自身の状態確認テーブルの前回フラグを使用し、ラウンドロビンで、対象アクセスサーバ（ＡＣ）を選択する。ＡＣＴ状態のデータベースサーバ（ＤＢ）が存在する拠点にはＡＣＴ状態のアクセスサーバ（ＡＣ）が存在せずに、他の拠点に存在する場合は、フロントエンドサーバ（ＦＥ）は、同様に、他の拠点のアクセスサーバ（ＡＣ）をラウンドロビンで選択する。

【0054】

パターンＢの場合は、パターンＡとは反対に、フロントエンドサーバ（ＦＥ）は、ＡＣＴ状態のデータベースサーバ（ＤＢ）が存在しない拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するかを先に調べる。ＡＣＴ状態のアクセスサーバ（ＡＣ）が存在しなければ、フロントエンドサーバ（ＦＥ）は、ＡＣＴ状態のデータベースサーバ（ＤＢ）が存在する拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かを調べる。

【0055】

フロントエンドサーバ（ＦＥ）は、選択したアクセスサーバ（ＡＣ）のＩＰ（Internet Protocol）アドレスを、監視端末に応答する。

【0056】

フロントエンドサーバ（ＦＥ）は、例えば障害の生じているアクセスサーバ（ＡＣ）を停止させた後、新たにアクセスサーバ（ＡＣ）を起動させる構成としてもよい。フロントエンドサーバ（ＦＥ）は、目的に応じて、停止させたアクセスサーバ（ＡＣ）と同一拠点にあるアクセスサーバ（ＡＣ）を起動してもよいし、異なる拠点にあるアクセスサーバ（ＡＣ）を起動してもよい。例えば、フロントエンドサーバ（ＦＥ）は、各拠点にＳＢＹ状態のアクセスサーバ（ＡＣ）を用意しておくために、ＳＢＹ状態のアクセスサーバ（ＡＣ）がない拠点においてアクセスサーバ（ＡＣ）を起動してもよいし、各拠点に、予め定められた一定数のアクセスサーバ（ＡＣ）を用意しておくために、停止したアクセスサーバ（ＡＣ）と同一拠点において新たなアクセスサーバ（ＡＣ）を起動してもよい。フロントエンドサーバ（ＦＥ）がこのようなアクセスサーバ（ＡＣ）の停止と起動の機能を具備することで、アクセスサーバ（ＡＣ）の耐障害性が向上できる。フロントエンドサーバ（ＦＥ）は物理マシンでもよいし仮想マシンでもよい。

【0057】

同期サーバ（ＳＣ）は、複数のデータベースサーバ（ＤＢ）サーバ同士でデータベースの記憶内容（データ）の同期ができていることの監視と制御を行う。例えば、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同期サーバ（ＳＣ）の間の経路がネットワーク障害になった場合や、ＡＣＴ状態のデータベースサーバ（ＤＢ）がＳＢＹ状態に切り替わった場合には、同期サーバ（ＳＣ）は、それまでＳＢＹ状態であった対向のデータベースサーバ（ＤＢ）をＡＣＴ状態に遷移させる。同期サーバ（ＳＣ）は物理マシンでもよいし仮想マシンでもよい。

【0058】

マネージメントサーバ（ＭＧ）は、監視対象のＮＥの台数に応じた台数が設置される。マネージメントサーバ（ＭＧ）は、ネットワーク装置（ＮＥ）の状態変更を監視する。例えば、ネットワーク装置（ＮＥ）が送信したＳＮＭＰ（Simple Network Management Protocol）ｔｒａｐによるアラーム通知をマネージメントサーバ（ＭＧ）が受信する。マネージメントサーバ（ＭＧ）は、ネットワーク装置（ＮＥ）のＣＰＵ（Central Processing Unit）使用率などの性能情報を定期的に収集する。当該収集には、ＳＮＭＰｇｅｔや、ｔｅｌｎｅｔ／ＳＳＨ（Secure Shell）ログイン、ＦＴＰ／ＳＦＴＰ（File Transfer Protocol/SSH File Transfer Protocol）でのファイル送受信等が用いられる。

【0059】

マネージメントサーバ（ＭＧ）がネットワーク装置（ＮＥ）の監視に用いる情報を「ＮＥ監視情報」と表記する。マネージメントサーバ（ＭＧ）は、収集したＮＥ監視情報をアクセスサーバ（ＡＣ）経由でデータベースサーバ（ＤＢ）に書き込む。具体的には、マネージメントサーバ（ＭＧ）は、アクセスサーバ（ＡＣ）にＮＥ監視情報を送信し、アクセスサーバ（ＡＣ）が、ＡＣＴ状態のデータベースサーバ（ＤＢ）にＮＥ監視情報の書き込み要求を行ってＮＥ監視情報をデータベースに書き込む。

【0060】

保守者が監視端末から保守設定変更を実行するとき、当該内容が、マネージメントサーバ（ＭＧ）によるネットワーク装置（ＮＥ）の定期監視の設定変更である場合、アクセスサーバ（ＡＣ）はマネージメントサーバ（ＭＧ）に対して定期監視の設定変更の通知を行い、同時にアクセスサーバ（ＡＣ）からデータベースサーバ（ＤＢ）に、定期監視の設定変更内容が書き込まれる。保守設定の変更内容が、ネットワーク装置（ＮＥ）自体の設定の変更の場合は、アクセスサーバ（ＡＣ）からマネージメントサーバ（ＭＧ）を経由してＮＥにｔｅｌｎｅｔ／ＳＳＨログインやＦＴＰ／ＳＦＴＰでのファイル送受信を行って、ＮＥの設定変更を実行する。マネージメントサーバ（ＭＧ）は物理マシンでも仮想マシンでも良い。

【0061】

監視端末は、保守者に保守用インターフェイスを提供し、ネットワーク装置（ＮＥ）の保守画面（リングマップ表示、アラームリスト表示など）を保守者の操作により表示する。保守画面の表示や更新などの処理をする際は、監視端末は、フロントエンドサーバ（ＦＥ）にアクセス要求を送信し、アクセス先のアクセスサーバ（ＡＣ）のＩＰアドレスを応答として受信する。その後、フロントエンドサーバ（ＦＥ）からアクセスサーバ（ＡＣ）に対して処理要求が送信され、アクセスサーバ（ＡＣ）はデータベースサーバ（ＤＢ）に対してデータベース（ＤＢ）読み出しやデータベース（ＤＢ）書き込み要求を送信する。データベース（ＤＢ）読み出し／書き込みを終えると、アクセスサーバ（ＡＣ）は、監視端末に処理応答を送信し、監視端末が画面表示を行う。監視端末は、物理マシンでも仮想マシンでもよい。

【0062】

ネットワーク装置（ＮＥ）は、状態変更が発生した場合はＳＮＭＰ ｔｒａｐなどの手段で、マネージメントサーバ（ＭＧ）にアラームを通知する。また、ネットワーク装置（ＮＥ）は、マネージメントサーバ（ＭＧ）からの設定変更実行を受け付ける。

【0063】

続いて、図面を参照して第１の実施形態のシステムの動作を説明する。

【0064】

図５は、フロントエンドサーバ（ＦＥ）を利用した処理要求振り分けの一例を示す図である。図５には、正常時（障害非発生時）において、監視端末３８－１からのアクセス要求を、フロントエンドサーバ（ＦＥ）がパターンＡ、Ｂに分類し、当該分類結果に基づき適切なアクセスサーバ（ＡＣ）に振り分けて処理を行う様子が示されている。

【0065】

フロントエンドサーバ（ＦＥ）３３Ｅは、監視端末３８－１からのアクセス要求Ｓ１を受けると、図２４に示す要求ＩＤ-要求パターン対応表に示されるように、アクセス要求の要求ＩＤごとにパターンＡ、パターンＢのいずれであるかを識別する。

【0066】

図５において、アクセス要求Ｓ１がパターンＡの場合、ＡＣＴ状態のデータベースサーバ（ＤＢ）であるデータベースサーバ（ＤＢ）３１Ｅと同一拠点に、ＡＣＴ状態のアクセスサーバ（ＡＣ）３２－１Ｅとアクセスサーバ（ＡＣ）３２－２Ｅが存在するので、フロントエンドサーバ（ＦＥ）３３Ｅは、このうちいずれかに処理を振り分ける。

【0067】

フロントエンドサーバ（ＦＥ）３３Ｅは、アクセスサーバ（ＡＣ）３２－１Ｅ、３２－２Ｅのうち、特定のアクセスサーバ（ＡＣ）に処理を集中させることなく、処理を行うアクセスサーバ（ＡＣ）をラウンドロビンで振り分ける。このために、例えば図２０（ａ）、（ｂ）に示すＦＥ－Ｅ設定ファイル、ＦＥ－Ｅ状態テーブルのうち図２０（ｂ）のＦＥ－Ｅ状態テーブルを参照する。ＦＥ－Ｅ状態テーブルは、フロントエンドサーバ（ＦＥ）３３Ｅで管理するデータベースサーバ（ＤＢ）、アクセスサーバ（ＡＣ）、同期サーバ（ＳＣ）の状態を管理するテーブルであり、ＡＣＴ状態のアクセスサーバ（ＡＣ）について前回選択されたものであるかフラグ欄を有する。

【0068】

ＦＥ－Ｅ状態テーブルにおいて、前回フラグが“ｙ”であるアクセスサーバ（ＡＣ－Ｅ２）ではない方のアクセスサーバ（ＡＣ－Ｅ１）に対して、処理要求を行わせるために、フロントエンドサーバ（ＦＥ）３３Ｅは、Ｓ２のアクセス先応答で、アクセスサーバ（ＡＣ－Ｅ１）のＩＰアドレスを監視端末３８－１に応答する。なお、図２０を含む図面において、図４に示すＮＭＳ東３０－１に含まれるアクセスサーバ（ＡＣ）を、図の上から順にＡＣ－Ｅ１～ＡＣ－Ｅ４と表記し、ＮＭＳ西３０－２に含まれるアクセスサーバ（ＡＣ）を、図の上から順にＡＣ－Ｗ１～ＡＣ－Ｗ４と表記する。

【0069】

図５において、Ｓ３（Ａ）では、監視端末３８－１から、アクセスサーバ（ＡＣ）３２－１Ｅ（ＡＣ－Ｅ１）に処理要求（パターンＡ）を送信する。

【0070】

アクセスサーバ（ＡＣ）３２－１Ｅは、Ｓ４（Ａ）では、アクセスサーバ（ＡＣ）３２－１Ｅからデータベースサーバ（ＤＢ）３１Ｅに、データベース（ＤＢ）アクセス要求（パターンＡ）を行う。これは、アクセスサーバ（ＡＣ）３２－１Ｅとデータベースサーバ（ＤＢ）３１Ｅとの間で、データベース（ＤＢ）読み出し要求、データベース（ＤＢ）読み出し応答が連続して多くの回数が行われることを示す。

【0071】

図５において、アクセス要求Ｓ１がパターンＢの場合、ＡＣＴ状態のデータベースサーバ（ＤＢ）３１Ｅと別の拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）３６－１Ｗとアクセスサーバ（ＡＣ）３６－２Ｗが存在するので、フロントエンドサーバ（ＦＥ）３３Ｅは、このうちいずれかに処理を振り分ける。

【0072】

パターンＡのときと同様に、ラウンドロビンで処理を行うために、フロントエンドサーバ（ＦＥ）３３Ｅは、図２０（ｂ）のＦＥ－Ｅ状態テーブルを参照する。

【0073】

ＦＥ－Ｅ状態テーブルで、前回フラグが“ｙ”であるアクセスサーバ（ＡＣ－Ｗ２）ではない方のアクセスサーバ（ＡＣ－Ｗ１）に対して処理要求を行わせるために、フロントエンドサーバ（ＦＥ）３３Ｅは、Ｓ２のアクセス先応答で、アクセスサーバ（ＡＣ）３６－１Ｗ（ＡＣ－Ｗ１）のＩＰアドレスを監視端末３８－１に応答する。

【0074】

Ｓ３（Ｂ）では、監視端末３８－１から、アクセスサーバ（ＡＣ）３６－１Ｗに処理要求（パターンＢ）を送信する。

【0075】

アクセスサーバ（ＡＣ）３６－１Ｗは、Ｓ４（Ｂ）では、アクセスサーバ（ＡＣ）３６－１Ｗからデータベースサーバ（ＤＢ）３１Ｅに対して、データベース（ＤＢ）アクセス要求（パターンＡ）を行う。このとき、アクセスサーバ（ＡＣ）３６－１Ｗとデータベースサーバ（ＤＢ）３１Ｅとの間で、例えばデータベース（ＤＢ）読み出し要求、データベース（ＤＢ）読み出し応答が複数回行われる可能性はあるが、その回数は少ない。

【0076】

図６は、フロントエンドサーバ（ＦＥ）を利用した処理要求振り分けの一例を示す図である。図６には、データベースサーバ（ＤＢ）の障害時において、図５の状態から、ＡＣＴ状態のデータベースサーバ（ＤＢ）３１Ｅが障害になり、それまでＳＢＹ状態のデータベースサーバ（ＤＢ）３４ＷがＡＣＴ状態に遷移したときの動作の一例が示されている。すなわち、図６には、図５の場合と同様に、監視端末３８-１からのアクセス要求を、フロントエンドサーバ（ＦＥ）３３ＥがパターンＡ、Ｂに分類し、適切なアクセスサーバ（ＡＣ）に振り分けて処理を行う様子が示されている。

【0077】

フロントエンドサーバ（ＦＥ）３３Ｅは、監視端末３８－１からのアクセス要求Ｓ１を受けると、アクセス要求Ｓ１がパターンＡ、パターンＢのいずれであるかを識別する。

【0078】

図６において、アクセス要求Ｓ１がパターンＡの場合、ＡＣＴ状態のデータベースサーバ（ＤＢ）３４Ｗと同一拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）３６－１Ｗとアクセスサーバ（ＡＣ）３６－２Ｗが存在するので、このうちいずれかに処理を振り分ける。フロントエンドサーバ（ＦＥ）３３Ｅは、アクセスサーバ（ＡＣ）３６－１Ｗ、３６－２Ｗのうち、特定のアクセスサーバ（ＡＣ）に処理を集中させることなく、処理を行うアクセスサーバ（ＡＣ）を、ラウンドロビンで振り分けるために、図２０（ｂ）に示すＦＥ－Ｅ状態テーブルを参照する。

【0079】

ＦＥ－Ｅ状態テーブルにおいて、前回フラグが“ｙ”であるアクセスサーバ（ＡＣ）－Ｗ２ではない方のアクセスサーバ（ＡＣ-Ｗ１）に対して、処理要求を行わせるために、フロントエンドサーバ（ＦＥ）３３Ｅは、Ｓ２のアクセス先応答で、アクセスサーバ（ＡＣ）３６－１Ｗ（ＡＣ－Ｗ１）のＩＰアドレスを監視端末３８－１に応答する。

【0080】

Ｓ３（Ａ）では、監視端末３８－１から、アクセスサーバ（ＡＣ）３６－１Ｗに処理要求（パターンＡ）を行う。アクセスサーバ（ＡＣ）３６－１Ｗは、Ｓ４（Ａ）では、データベースサーバ（ＤＢ）３４Ｗに、データベース（ＤＢ）アクセス要求（パターンＡ）を行う。これは、アクセスサーバ（ＡＣ）３６－１Ｗとデータベースサーバ（ＤＢ）３４Ｗとの間で、例えばデータベース（ＤＢ）読み出し要求、データベース（ＤＢ）読み出し応答が連続して多くの回数が行われることを示している。

【0081】

図６において、アクセス要求Ｓ１がパターンＢの場合、ＡＣＴ状態のデータベースサーバ（ＤＢ）３４Ｗと別の拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）３２－１Ｅ、アクセスサーバ（ＡＣ）３２－２Ｅが存在するので、フロントエンドサーバ（ＦＥ）３３Ｅは、このうちいずれかに処理を振り分ける。パターンＡのときと同様にラウンドロビンで処理を行うために、フロントエンドサーバ（ＦＥ）３３Ｅは、図２０に示すＦＥ－Ｅ状態テーブルを参照する。

【0082】

ＦＥ－Ｅ状態テーブルにおいて、前回フラグが“ｙ”であるアクセスサーバ（ＡＣ－Ｅ２）ではない方のアクセスサーバ（ＡＣ-Ｅ１）に対して処理要求を行わせるために、フロントエンドサーバ（ＦＥ）３３Ｅは、Ｓ２アクセス先応答で、アクセスサーバ（ＡＣ）３２－１Ｅ（ＡＣ－Ｅ１）のＩＰアドレスを監視端末３８－１に応答する。

【0083】

Ｓ３（Ｂ）では、監視端末３８－１から、アクセスサーバ（ＡＣ）３２－１Ｅに処理要求（パターンＢ）を行う。アクセスサーバ（ＡＣ）３２－１Ｅは、Ｓ４（Ｂ）では、アクセスサーバ（ＡＣ）３２－１Ｅからデータベースサーバ（ＤＢ）３４Ｗに、データベース（ＤＢ）アクセス（パターンＢ）を行う。このとき、アクセスサーバ（ＡＣ）３２－１Ｅとデータベースサーバ（ＤＢ）３４Ｗとの間で、データベース（ＤＢ）読み出し要求、データベース（ＤＢ）読み出し応答が複数回行われる可能性はあるが、その回数は少ない。

【0084】

図７は、フロントエンドサーバ（ＦＥ）を利用した処理要求振り分けの一例を示す図である。図７には、東拠点被災時の振り分けの様子が示されている。具体的には、図７は、図６の状態からＮＭＳ東３０－１の全サーバが障害になった状態が示されている。図７には、図５と同様に監視端末３８－１からのアクセス要求（Ｓ１）を、フロントエンドサーバ（ＦＥ）３７ＷがパターンＡ、Ｂに分類し、適切なアクセスサーバ（ＡＣ）に振り分けて処理を行う様子が示されている。

【0085】

監視端末は、図２３に示す監視端末 設定ファイルに指定されたプライマリフロントエンドサーバ（ｐｒｉｍａｒｙ ＦＥ）であるフロントエンドサーバ（ＦＥ）３３Ｅにアクセス要求を出す（Ｓ１）が、応答にタイムアウトが発生し、監視端末は、セカンダリフロントエンドサーバ（ｓｅｃｏｎｄａｒｙ ＦＥ）であるフロントエンドサーバ（ＦＥ）３７Ｗにアクセス要求を出す（Ｓ２）。この例では、ＮＭＳ東３０－１の全アクセスサーバ（ＡＣ）が障害になっているため、アクセス要求をパターンＡ、Ｂに分類し、アクセス先のアクセスサーバ（ＡＣ）を振り分けることの必要性やメリットはない。

【0086】

しかし、片方の拠点が被災し全サーバが障害になった場合であっても、パターン分けロジックを使って適切な振り分けが行われる。この点について、図７を参照して説明する。

【0087】

図７において、アクセス要求Ｓ１がパターンＡの場合、ＡＣＴ状態のデータベースサーバ（ＤＢ）３４Ｗと同一拠点にＡＣＴ状態のアクセスサーバ（ＡＣ）３６－１Ｗとアクセスサーバ（ＡＣ）３６－２Ｗが存在するので、フロントエンドサーバ（ＦＥ）３７Ｗは、このうちいずれかに処理を振り分ける。フロントエンドサーバ（ＦＥ）３７Ｗは、アクセスサーバ（ＡＣ）３６－１Ｗと３６－２Ｗのうち、特定のアクセスサーバ（ＡＣ）に処理を集中させることなく、処理を行うアクセスサーバ（ＡＣ）を、例えばラウンドロビンで振り分けるために、図示されないＦＥ－Ｗ状態テーブルを参照する。

【0088】

ＦＥ－Ｗ状態テーブルの形式は、図２０（ｂ）のＦＥ－Ｅ状態テーブルと同じである。ここでは、ＦＥ－Ｗ状態テーブルでアクセスサーバ（ＡＣ-Ｗ２）の前回フラグが“ｙ”である場合を例に動作を説明する。アクセスサーバ（ＡＣ-Ｗ２）ではない方のアクセスサーバ（ＡＣ-Ｗ１）に対して、処理要求を行わせるために、フロントエンドサーバ（ＦＥ）３７Ｗは、Ｓ３アクセス先応答で、アクセスサーバ（ＡＣ）３６－１ＷのＩＰアドレスを監視端末３８－１に応答する。

【0089】

Ｓ４（Ａ）では、監視端末３８－１は、アクセスサーバ（ＡＣ）３６－１Ｗに処理要求（パターンＡ）を行う。Ｓ４（Ａ）では、アクセスサーバ（ＡＣ）３６－１Ｗは、データベースサーバ（ＤＢ）３４Ｗにデータベース（ＤＢ）アクセス（パターンＡ）を行う。これは、アクセスサーバ（ＡＣ）３６－１Ｗとデータベースサーバ（ＤＢ）３４Ｗとの間で、データベース（ＤＢ）読み出し要求、データベース（ＤＢ）読み出し応答が連続して多くの回数が行われることを示している。

【0090】

図７において、アクセス要求Ｓ１がパターンＢの場合、この例では、ＡＣＴ状態のデータベースサーバ（ＤＢ）３４Ｗと別の拠点にはＡＣＴ状態のアクセスサーバ（ＡＣ）は存在しない。このため、フロントエンドサーバ（ＦＥ）３７Ｗは、同じ拠点でＡＣＴ状態のアクセスサーバ（ＡＣ）３６－１Ｗとアクセスサーバ（ＡＣ）３６－２Ｗのうちいずれかに処理を振り分ける。

【0091】

パターンＡのときと同様に、ラウンドロビンで処理を行うために、フロントエンドサーバ（ＦＥ）３７Ｗは、ＦＥ－Ｗ状態テーブルを参照する。ここでは、ＦＥ－Ｗ状態テーブルでアクセスサーバ（ＡＣ-Ｗ１）の前回フラグが“ｙ”である場合を例に動作を説明する。アクセスサーバ（ＡＣ-Ｗ１）ではない方のアクセスサーバ（ＡＣ-Ｗ２）に対して処理要求を行わせるため、フロントエンドサーバ（ＦＥ）３７Ｗは、Ｓ３アクセス先応答で、アクセスサーバ（ＡＣ）３６-２ＷのＩＰアドレスを監視端末３８－１に応答する。

【0092】

Ｓ４（Ｂ）では、監視端末３８－１は、アクセスサーバ（ＡＣ）３６－２Ｗに処理要求（パターンＢ）を行う。アクセスサーバ（ＡＣ）３６－２Ｗは、Ｓ５（Ｂ）では、アクセスサーバ（ＡＣ）３６－２Ｗからデータベースサーバ（ＤＢ）３４Ｗに、データベース（ＤＢ）アクセス要求（パターンＢ）を行う。このとき、アクセスサーバ（ＡＣ）３６－２Ｗとデータベースサーバ（ＤＢ）３４Ｗとの間で、例えばデータベース（ＤＢ）読み出し要求、データベース（ＤＢ）読み出し応答が複数回行われる可能性はあるが、その回数は少ない。

【0093】

続いて、フローチャート等の各図を参照し第１の実施形態に係るシステムの動作をより詳細に説明する。

【0094】

図８は、アクセス要求から処理応答までの動作の一例を示すシーケンス図である。図８に示すＮＭＳ東のデータベース（ＤＢ）アクセス要求と応答パターンのシーケンスは、ＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態であるとき、監視端末からアクセス要求をフロントエンドサーバ（ＦＥ）に送信し、フロントエンドサーバ（ＦＥ）がアクセス応答を監視端末に送信する処理を、パターンＡ、Ｂのそれぞれについて示したシーケンスである。なお、図８を含む図面においてＮＭＳ東のデータベースサーバ（ＤＢ）はＤＢ－Ｅ、ＮＭＳ西のデータベースサーバ（ＤＢ）はＤＢ－Ｗと表記する。他の構成（例えば、アクセスサーバ（ＡＣ））についても同様に表記する。

【0095】

図８において、Ｓ７１０１は、ＮＭＳ東のＮＭＳのデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からのアクセス要求がパターンＡである場合のシーケンスである。Ｓ７１０１では、ＮＭＳ東のアクセスサーバＡＣ（ｘ）がＡＣＴ状態であるものとする。

【0096】

この場合、Ｓ７１０１では、同じ拠点内のＮＭＳ東のアクセスサーバＡＣ（ｘ）からＮＭＳ東のデータベースサーバ（ＤＢ）に対してアクセスしているため、データベース（ＤＢ）読み出し／書き込みの回数が多くなっても、上記第１の問題（異なる拠点間のＤＢ－ＡＣ間のデータベース（ＤＢ）読み出し／書き込みによる保守者の操作性低下）は発生しない。

【0097】

図８において、Ｓ７２０１は、ＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からのアクセス要求がパターンＢである場合のシーケンスである。Ｓ７２０１では、ＮＭＳ西のアクセスサーバＡＣ（ｘ）がＡＣＴ状態であるものとする。

【0098】

この場合、Ｓ７２０１では、異なる拠点間のＮＭＳ西のアクセスサーバ（ＡＣ）（ｘ）からＮＭＳ東のデータベースサーバ（ＤＢ）に対してアクセスしているため、データベース（ＤＢ）読み出し／書き込みの回数が多くなると、第１の問題（異なる拠点間のＤＢ－ＡＣ間のＤデータベース（ＤＢ）読み出し／書き込みによる保守者の操作性低下）が発生する。しかし、元々、パターンＢの要求は、読み書きの回数が少ないので問題は発生しない（問題とならない）。

【0099】

図５におけるＳ３（Ａ）やＳ４（Ａ）は、図８のＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からのアクセス要求がパターンＡであり、ＮＭＳ東のアクセスサーバＡＣ（ｘ）がＡＣＴ状態の場合（Ｓ７１０１）の処理に該当する。図５におけるＳ３（Ｂ）やＳ４（Ｂ）は、図８のＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からのアクセス要求がパターンＢであり、ＮＭＳ西のアクセスサーバＡＣ（ｘ）がＡＣＴの場合（Ｓ７２０１）の処理に該当する。

【0100】

図９は、アクセス要求から処理応答までの動作の一例を示すシーケンス図である。図９示すＮＭＳ西のデータベース（ＤＢ）アクセス要求、応答パターンのシーケンスはＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態であるとき、監視端末からアクセス要求をフロントエンドサーバ（ＦＥ）に送信し、フロントエンドサーバ（ＦＥ）がアクセス応答を監視端末に送信する処理を、監視端末からのアクセス要求がパターンＡ、Ｂのそれぞれについて示したシーケンスである。

【0101】

図９において、Ｓ８１０１は、ＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からの要求がパターンＡである場合のシーケンスである。Ｓ８１０１において、ＮＭＳ西のアクセスサーバＡＣ（ｘ）がＡＣＴ状態であるものとする。

【0102】

この場合、Ｓ８１０１では、同じ拠点内のＮＭＳ西のアクセスサーバ（ＡＣ）（ｘ）からＮＭＳ西のデータベースサーバ（ＤＢ）に対してアクセスしているため、データベース（ＤＢ）読み出し／書き込みの回数が多くなっても、上記第１の問題（異なる拠点間のＤＢ－ＡＣ間のデータベース（ＤＢ）読み出し／書き込みによる保守者の操作性低下）は発生しない。

【0103】

図９において、Ｓ８２０１は、ＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、要求パターンＢである場合のシーケンスである。Ｓ８２０１において、ＮＭＳ西のアクセスサーバ（ＡＣ）（ｘ）がＡＣＴ状態であるものとする。

【0104】

この場合、Ｓ８２０１では、異なる拠点間のＮＭＳ東のアクセスサーバ（ＡＣ）（ｘ）からＮＭＳ西のデータベースサーバ（ＤＢ）に対してアクセスしているため、データベース（ＤＢ）読み出し／書き込みの回数が多くなると、第１の問題（異なる拠点間のＤＢ－ＡＣ間のデータベース（ＤＢ）読み出し／書き込みによる保守者の操作性低下）が発生する。しかし、元々、パターンＢのアクセス要求は、読み書きの回数が少ないので問題は発生しない（問題とならない）。

【0105】

図６に示すＳ３（Ａ）やＳ４（Ａ）は、図９において、西のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からの要求がパターンＡであり、ＮＭＳ西のアクセスサーバＡＣ（ｘ）がＡＣＴ状態の場合（Ｓ８１０１）の処理に該当する。同様に、図７に示すＳ４（Ａ）やＳ５（Ａ）は、図９において、ＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態であり要求パターンＡであり、ＮＭＳ西のアクセスサーバＡＣ（ｘ）がＡＣＴ状態である場合（Ｓ８１０１）の処理に該当する。

【0106】

図６に示すＳ３（Ｂ）やＳ４（Ｂ）は、図９において、ＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態でであり、監視端末からの要求がパターンＢであり、ＮＭＳ東のアクセスサーバＡＣ（ｘ）がＡＣＴ状態である場合（Ｓ８２０１）の処理に該当する。

【0107】

図７に示すＳ４（Ｂ）やＳ５（Ｂ）は、図９において、ＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からの要求がパターンＡであり、ＮＭＳ西のアクセスサーバＡＣ（ｘ）がＡＣＴの場合（Ｓ８１０１）の処理と同じ処理を行う。

【0108】

図１０は、アクセス要求から，アクセス先のアクセスサーバ（ＡＣ）応答の処理の一例を示す流れ図である。図１０には、監視端末がアクセス要求を送信してから、アクセス先アクセスサーバ（ＡＣ）応答を受信するまでのフロントエンドサーバ（ＦＥ）処理の一例が示されている。

【0109】

要求パターン分類（Ｓ９１２）では、フロントエンドサーバ（ＦＥ）は、図２４に示す「要求ＩＤ－要求パターン対応表」に従って、保守者の操作ごとに決まる要求の種別を示す要求ＩＤがパターンＡ、Ｂに分類される。

【0110】

ＡＣＴ データベースサーバ（ＤＢ）判定（Ｓ９１３）では、フロントエンドサーバ（ＦＥ）は、図２２に示す「ＳＣ、ＤＢヘルスチェック応答パターンとＡＣＴ ＤＢ判定と説明」と、ＮＭＳ東のデータベースサーバ（ＤＢ）、ＮＭＳ西のデータベースサーバ（ＤＢ）の状態と、に基づき、ＡＣＴ状態のデータベースサーバ（ＤＢ）の判定を行う。

【0111】

判定の結果、ＮＭＳ東のデータベースサーバ（ＤＢ）及びＮＭＳ西のデータベースサーバ（ＤＢ）が共にＡＣＴ状態であれば（Ｓ１９３ａ、Ｙｅｓ分岐）、フロントエンドサーバ（ＦＥ）は、アクセス先のアクセスサーバ（ＡＣ）応答を行う（Ｓ９１３ｂ）。つまり、フロントエンドサーバ（ＦＥ）は、前回のヘルスチェック時にアクセス先として判定されたアクセスサーバ（ＡＣ）を通知する。Ｓ９１３ａの判定がＮＯであれば、Ｓ９１４以降の処理が実行される。

【0112】

Ｓ９１４では、フロントエンドサーバ（ＦＥ）は、ＮＭＳ東のデータベースサーバ（ＤＢ）又はＮＭＳ西のデータベースサーバ（ＤＢ）のどちらがＡＣＴ状態であるか判定し、いずれもＡＣＴ状態でなければ、データベースサーバ（ＤＢ）状態エラー応答を返答する（Ｓ９１５）。少なくとも一方のデータベースサーバ（ＤＢ）がＡＣＴ状態であれば、フロントエンドサーバ（ＦＥ）は、Ｓ９１６のアクセス先検索を行う。

【0113】

アクセス先アクセスサーバ（ＡＣ）検索（Ｓ９１６）では、フロントエンドサーバ（ＦＥ）は、ＡＣＴ データベースサーバ（ＤＢ）判定の結果（ＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態又はＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態）と、アクセス要求のパターンの分類（パターンＡ又はＢ）に基づき処理を行う。ＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からのアクセス要求がパターンＡ、又は、ＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、監視端末からのアクセス要求がパターンＢの場合は、図１１に示す処理が行われる。

【0114】

図１１は、フロントエンドサーバ（ＦＥ）におけるアクセス先アクセスサーバ（ＡＣ）検索処理フロー（東⇒西パターン）の一例を示すフローチャートである。図１１を参照すると、Ｓ１０１２において、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かが検索される。なお、図１１等では、ＮＭＳ東、ＮＭＳ西を東、西と表記する。

【0115】

フロントエンドサーバ（ＦＥ）は、検索の結果、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在する場合（Ｓ１０１３がＹｅｓ）、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）があると検知される（Ｓ１０１３ａ）。この場合、図１０のＳ９１９の処理が実行される。

【0116】

フロントエンドサーバ（ＦＥ）は、検索の結果、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在しない場合（Ｓ１０１３がＮｏ）、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かが検索される（Ｓ１０１４）。

【0117】

フロントエンドサーバ（ＦＥ）は、検索の結果、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在する場合（Ｓ１０１５がＹｅｓ）、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）があると検知される（Ｓ１０１５ａ）。この場合、図１０のＳ９１９の処理が実行される。

【0118】

フロントエンドサーバ（ＦＥ）は、検索の結果、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在しない場合（Ｓ１０１５がＮｏ）、ＡＣＴ状態のアクセスサーバ（ＡＣ）が存在しないことを検知する（Ｓ１０１６）。

【0119】

フロントエンドサーバ（ＦＥ）は、ＡＣＴなアクセスサーバ（ＡＣ）が存在しないことを検知（Ｓ１０１６）した場合は、図１０に示すＡＣＴなアクセスサーバ（ＡＣ）が存在するか否かの判定（Ｓ９１７）がＮｏとなり、アクセスサーバ（ＡＣ）状態エラー応答がフロントエンドサーバ（ＦＥ）から監視端末に送信される（Ｓ９１８）。

【0120】

なお、図５に示すＳ３（Ａ）やＳ４（Ａ）の処理は、図１１に示す「アクセス先アクセスサーバ（ＡＣ）検索処理フロー（東⇒西パターン）」におけるＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するＳ１０１３の分岐がＹｅｓになる場合の一例である。また、図６に示すＳ３（Ｂ）やＳ４（Ｂ）の処理も、図１１において、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するＳ１０１３の分岐がＹＥＳになる場合の一例である。さらに、図７に示すＳ４（Ｂ）やＳ５（Ｂ）の処理は、図１１において、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するＳ１０１３の分岐がＮＯになり、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するＳ１０１５の分岐がＹＥＳになる場合の例である。

【0121】

ＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、アクセス要求がパターンＢ、又は、ＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、アクセス要求がパターンＡの場合には、図１２に示す処理が行われる。図１２は、フロントエンドサーバ（ＦＥ）におけるアクセス先アクセスサーバ（ＡＣ）検索処理フロー（西⇒東パターン）の一例を示すフローチャートである。

【0122】

図１２を参照すると、Ｓ１１１２において、フロントエンドサーバ（ＦＥ）は、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かを検索する。

【0123】

検索の結果、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在する場合（Ｓ１１１３が“ＹＥＳ”）、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）があると検知される（Ｓ１１１３ａ）。この場合、図１０のＳ９１９の処理が実行される。

【0124】

検索の結果、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在しない場合（Ｓ１１１３が“ＮＯ”）、フロントエンドサーバ（ＦＥ）は、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かを検索する（Ｓ１１１４）。

【0125】

検索の結果、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在する場合（Ｓ１１１５が“Ｙｅｓ”）、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）があると検知される（Ｓ１１１５ａ）。この場合、図１０のＳ９１９の処理が実行される。

【0126】

検索の結果、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在しない場合（Ｓ１１１５が“ＮＯ”）、ＡＣＴなアクセスサーバ（ＡＣ）が存在しないことを検知する（Ｓ１１１６）。

【0127】

ＡＣＴなアクセスサーバ（ＡＣ）が存在しないことを検知（Ｓ１１１６）した場合は、図１０に示すＡＣＴなアクセスサーバ（ＡＣ）が存在するか否かの判定（Ｓ９１７）が“ＮＯ”となり、ＡＣ状態エラー応答が、フロントエンドサーバ（ＦＥ）から監視端末に送信される（Ｓ９１８）。

【0128】

なお、図５に示すＳ３（Ｂ）やＳ４（Ｂ）の処理は、図１２に示す「アクセス先ＡＣ検索処理フロー（西⇒東パターン）」におけるＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するＳ１１１３の分岐が“ＹＥＳ”になる場合の一例である。また、図６に示すＳ３（Ａ）やＳ４（Ａ）の処理も、図１２において、西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するＳ１１１３の分岐が“ＹＥＳ”になる場合の一例である。さらに、図７に示すＳ４（Ａ）やＳ５（Ａ）の処理は、図１２において、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するＳ１１１３の分岐が“ＹＥＳ”になる場合の例である。

【0129】

図１３は、ＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かを検索する処理の一例を示すフローチャートである。図１３は、図１１においてＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか検索する処理（Ｓ１０１２）の内容、又は、図１２においてＮＭＳ東にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか検索する処理（Ｓ１１１４）の内容を示す。

【0130】

図１３に示すように、ｉ＝１、２、３、４まで繰り返しループ開始（Ｓ１２１２）からｉ＝１、２、３、４まで繰り返しループ終了（Ｓ１２１８）までの処理は、ＮＭＳ東に存在するアクセスサーバ（ＡＣ）の数だけ繰り返す処理であって、当該ケースでは、ＮＭＳ東のアクセスサーバ（ＡＣ）の台数４台分の処理が繰り返される。上記ループ処理ではｉがインクリメントされる処理（Ｓ１２１６ａ）が実行され、ループ処理が終了すると、処理は図１１のＳ１０１３又は図１２のＳ１１１５へ遷移する（Ｓ１２１８ａ）。

【0131】

フロントエンドサーバ（ＦＥ）は、ＡＣＴ状態のアクセスサーバ（ＡＣ）が見つかった場合（Ｓ１２１６が“ＹＥＳ”）、発見されたアクセスサーバ（ＡＣ）のＩＰアドレスを、ＦＥ設定ファイルから取得し、ＦＥ状態テーブルにおいて、アクセスサーバ（ＡＣ－Ｅ１）からアクセスサーバ（ＡＣ－Ｅ４）の前回フラグをクリアし、ＦＥ状態テーブルにおける発見されたアクセスサーバ（ＡＣ）の前回フラグを“ｙ”にする（Ｓ１２１７）。

【0132】

図１４は、ＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか否かを検索する処理の一例を示すフローチャートである。図１４は、図１１においてＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか検索する処理（Ｓ１０１４）の内容、又は、図１２においてＮＭＳ西にＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するか検索する処理（Ｓ１１１２）の内容を示す。

【0133】

図１４に示すように、ｉ＝１、２、３、４まで繰り返しループ開始（Ｓ１３１２）からｉ＝１、２、３、４まで繰り返しループ終了（Ｓ１３１８）までの処理は、ＮＭＳ西に存在するアクセスサーバ（ＡＣ）の数だけ繰り返す処理であって、当該ケースでは、ＮＭＳ西のアクセスサーバ（ＡＣ）の台数４台分の処理が繰り返される。上記ループ処理ではｉがインクリメントされる処理（Ｓ１３１６ａ）が実行され、ループ処理が終了すると、処理が図１１のＳ１０１５又は図１２のＳ１１１３へ遷移する（Ｓ１３１８ａ）。

【0134】

フロントエンドサーバ（ＦＥ）は、ＡＣＴ状態のアクセスサーバ（ＡＣ）が見つかった場合（Ｓ１３１６が“ＹＥＳ”）、発見されたアクセスサーバ（ＡＣ）のＩＰアドレスをＦＥ設定ファイルから取得し、ＦＥ状態テーブルのアクセスサーバ（ＡＣ）－Ｗ１からアクセスサーバ（ＡＣ）－Ｗ４の前回フラグをクリアし、ＦＥ状態テーブルにおける発見されたアクセスサーバ（ＡＣ）の前回フラグを“ｙ”に設定する（Ｓ１３１７）。

【0135】

図１５は、プライマリフロントエンドサーバ（ｐｒｉｍａｒｙ ＦＥ）の障害時に、セカンダリフロントエンドサーバ（ｓｅｃｏｎｄａｒｙ ＦＥ）がアクセス要求を処理する一例を示すシーケンス図である。監視端末は、図２３に示す「監視端末 設定ファイル」に示された設定ファイルにおいて、プライマリフロントエンドサーバ（ｐｒｉｍａｒｙ ＦＥ）に指定されているフロントエンドサーバ（ＦＥ）に対して、アクセス要求を行う（Ｓ１４１１）。

【0136】

図１５の例では、プライマリフロントエンドサーバ（ｐｒｉｍａｒｙ ＦＥ）には障害が発生しているため、プライマリフロントエンドサーバ（ｐｒｉｍａｒｙ ＦＥ）からのアクセス応答はない（Ｓ１４１２）。その結果、監視端末がタイムアウト処理を実行（Ｓ１４１３）した後、ＦＥ設定ファイルにおいて、セカンダリフロントエンドサーバ（ｓｅｃｏｎｄａｒｙ ＦＥ）に指定されているフロントエンドサーバ（ＦＥ）に対して、アクセス要求を行う（Ｓ１４１４）。

【0137】

図１５の例では、セカンダリフロントエンドサーバ（ｓｅｃｏｎｄａｒｙ ＦＥ）は正常であるため、アクセス先アクセスサーバ（ＡＣ）応答がセカンダリフロントエンドサーバ（ｓｅｃｏｎｄａｒｙ ＦＥ）から監視端末に送信される（Ｓ１４１５）。

【0138】

図１６は、アクセスサーバ（ＡＣ）ヘルスチェック正常パターンの一例を示すシーケンス図である。図１６には、フロントエンドサーバ（ＦＥ）が、東西のＮＭＳにおける全アクセスサーバ（ＡＣ）に対して、アクセスサーバ（ＡＣ）ヘルスチェック要求を送信し、各アクセスサーバ（ＡＣ）の状態を更新する処理を定期的に実施している様子が示されている。図１６に示す例は、全てのアクセスサーバ（ＡＣ）から、ＡＣＴ又はＳＢＹ状態である旨の応答がある場合（正常時の場合）を示している。ＡＣＴ又はＳＢＹ状態である旨の応答をフロントエンドサーバ（ＦＥ）が受信すると、ＦＥ状態テーブルが更新される（Ｓ１５１３～Ｓ１５１６）。

【0139】

図１７は、アクセスサーバ（ＡＣ）ヘルスチェック障害パターンの一例を示すシーケンス図である。図１７には、フロントエンドサーバ（ＦＥ）が、東西のＮＭＳにおける全アクセスサーバ（ＡＣ）に対して、アクセスサーバ（ＡＣ）ヘルスチェック要求を送信し、各アクセスサーバ（ＡＣ）の状態を更新する処理を定期的に実施している様子が示されている。

【0140】

図１７に示す例は、アクセスサーバ（ＡＣ）－Ｅ４が障害時の例であり、アクセスサーバ（ＡＣ）－Ｅ４からのアクセスサーバ（ＡＣ）ヘルスチェックの応答はない（Ｓ１６１４）。その後、全てのアクセスサーバ（ＡＣ）から、ＡＣＴ又はＳＢＹ状態である旨の応答がある場合（正常時の場合）とは異なり、タイムアウト処理が実施される（アクセスサーバ（ＡＣ）－Ｅ４＝障害で状態更新Ｓ１６１７の処理が実施される）。

【0141】

図１８は、同期サーバ（ＳＣ）とデータベースサーバ（ＤＢ）のヘルスチェック正常パターンの一例を示すシーケンス図である。図１８には、フロントエンドサーバ（ＦＥ）が、同期サーバ（ＳＣ）に定期的にヘルスチェック要求を送信し、応答の内容によって、ＮＭＳ東のデータベースサーバ（ＤＢ）とＮＭＳ西のデータベースサーバ（ＤＢ）の状態を更新する処理のシーケンスが示されている。

【0142】

図１８のシーケンスは、同期サーバ（ＳＣ）が正常、ＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態、ＮＭＳ西のデータベースサーバ（ＤＢ）がＳＢＹ状態のときのシーケンスである。同期サーバ（ＳＣ）は、フロントエンドサーバ（ＦＥ）からの同期サーバ（ＳＣ）ヘルスチェック要求（Ｓ１７１１）とは非同期に、ＮＭＳ東のデータベースサーバ（ＤＢ）とＮＭＳ西のデータベースサーバ（ＤＢ）の状態を監視している（Ｓ１７２１～Ｓ１７２４）。

【0143】

同期サーバ（ＳＣ）は、フロントエンドサーバ（ＦＥ）からの同期サーバ（ＳＣ）ヘルスチェック要求（Ｓ１７１１）を受けると、非同期に保持しているＮＭＳ東のデータベースサーバ（ＤＢ）の状態（ＡＣＴ）と、ＮＭＳ西のデータベースサーバ（ＤＢ）の状態（ＳＢＹ）を、同期サーバ（ＳＣ）ヘルスチェック応答でフロントエンドサーバ（ＦＥ）に送信する（Ｓ１７１２）。フロントエンドサーバ（ＦＥ）は、ＮＭＳ東のデータベースサーバ（ＤＢ）＝ＡＣＴ状態、ＮＭＳ西のデータベースサーバ（ＤＢ）＝ＳＢＹ状態で、ＦＥ状態テーブルを更新する（Ｓ１７１３）。

【0144】

図１９は、同期サーバ（ＳＣ）とデータベースサーバ（ＤＢ）のヘルスチェックにて同期サーバ（ＳＣ）障害パターンの一例を示すシーケンス図である。図１９には、フロントエンドサーバ（ＦＥ）が、同期サーバ（ＳＣ）に対して定期的にヘルスチェック要求を送信し、応答の内容によって、ＮＭＳ東のデータベースサーバ（ＤＢ）とＮＭＳ西のデータベースサーバ（ＤＢ）の状態を更新する処理のシーケンスが示されている。図１９のシーケンスは、同期サーバ（ＳＣ）が障害、ＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態であり、ＮＭＳ西のデータベースサーバ（ＤＢ）がＳＢＹ状態のときのシーケンスである。

【0145】

フロントエンドサーバ（ＦＥ）は、同期サーバ（ＳＣ）に対して同期サーバ（ＳＣ）ヘルスチェック要求を送信する（Ｓ１８１１）が、同期サーバ（ＳＣ）ヘルスチェック応答なしとなる（Ｓ１８１２）。その結果、タイムアウト検知処理（Ｓ１８１３）にて、タイムアウトが検知される。

【0146】

フロントエンドサーバ（ＦＥ）は、データベースサーバ（ＤＢ）の状態を確認するため、ＮＭＳ東のデータベースサーバ（ＤＢ）とＮＭＳ西のデータベースサーバ（ＤＢ）それぞれに、データベースサーバ（ＤＢ）状態確認要求を送信する（Ｓ１８１４、Ｓ１８１６）。ＮＭＳ東のデータベースサーバ（ＤＢ）は、フロントエンドサーバ（ＦＥ）にデータベースサーバ（ＤＢ）状態確認応答（ＡＣＴ）を送信（Ｓ１８１５）し、ＮＭＳ西のデータベースサーバ（ＤＢ）は、フロントエンドサーバ（ＦＥ）にデータベースサーバ（ＤＢ）状態確認応答（ＳＢＹ）を送信する（Ｓ１８１７）。

【0147】

フロントエンドサーバ（ＦＥ）は、ＮＭＳ東のデータベースサーバ（ＤＢ）＝ＡＣＴ、ＮＭＳ西のデータベースサーバ（ＤＢ）＝ＳＢＹで状態テーブルを更新する（Ｓ１８１８）。

【0148】

図２０（ａ）は、ＦＥ-Ｅ設定ファイルの一例を示し、図２０（ｂ）はＦＥ－Ｅ状態テーブルの一例を示す。ＮＭＳ東のフロントエンドサーバ（ＦＥ）は、図２０に示す設定ファイルと状態テーブルを有する。ＮＭＳ西のフロントエンドサーバ（ＦＥ）も、同じ形式の設定ファイルと状態テーブルを有する。

【0149】

図２１は、データベースサーバ（ＤＢ）、同期サーバ（ＳＣ）及びアクセスサーバ（ＡＣ）それぞれの状態を定義する図である。図２１に示すように、データベースサーバ（ＤＢ）、同期サーバ（ＳＣ）及びアクセスサーバ（ＡＣ）の状態が一覧化されている。それぞれの状態の説明は、図２１の説明欄に記載した通りである。

【0150】

図２２は、同期サーバ（ＳＣ）、データベースサーバ（ＤＢ）ヘルスチェック応答パターンと、ＡＣＴ データベースサーバ（ＤＢ）判定とその説明に関する図である。図２２には、同期サーバ（ＳＣ）、データベースサーバ（ＤＢ）ヘルスチェック応答で入手したＮＭＳ東のデータベースサーバ（ＤＢ）、ＮＭＳ西のデータベースサーバ（ＤＢ）の状態と、それらを元にした、ＡＣＴ データベースサーバ（ＤＢ）判定の方法（結果）が示されている。なお、ＮＭＳ東のデータベースサーバ（ＤＢ）がＡＣＴ状態、且つ、ＮＭＳ西のデータベースサーバ（ＤＢ）がＡＣＴ状態のときに、ＡＣＴ データベースサーバ（ＤＢ）判定を、前回のヘルスチェック時の判定結果を採用するとしている理由は以下の通りである。

【0151】

上記状況は、ＮＭＳ東のデータベースサーバ（ＤＢ）とＮＭＳ西のデータベースサーバ（ＤＢ）がそれぞれ、違う内容のデータベースを保持して運用を続けている状態であり、同じ監視端末からの処理は、前回と同じデータベースにアクセスして処理をさせる必要があるためである。

【0152】

仮に、前回と異なるデータベースにアクセスして処理が行われると、例えば、監視端末１９－１上の画面上に、監視端末１９－１を操作する保守者１が変更を実施した内容（ＮＭＳ東のデータベースサーバ（ＤＢ）の内容とする）が表示されず、別の監視端末１９－２を操作する保守者２が変更を実施した内容（ＮＭＳ西のデータベースサーバ（ＤＢ）の内容）が表示されてしまうなど、様々な不都合が発生する。

【0153】

図２３は、監視端末 設定ファイルの一例を示す図である。監視端末は、図２３に示すような設定ファイルを有する。図２４は、要求ＩＤ－要求パターン対応表の一例を示す図である。

【0154】

図２４には、アクセス要求の要求ＩＤごとに、パターンＡ、パターンＢのいずれであるかを識別するための対応表が記載されている。

【0155】

以上のように、第１の実施形態に係るフロントエンドサーバ（ＦＥ）は、監視端末からのアクセス要求の種別に基づき、当該アクセス要求の送信先を変更する。その結果、以下の効果が得られる。

【0156】

第１の効果は、第１の問題（異なる拠点間のＤＢ－ＡＣ間のデータベース（ＤＢ）読み出し／書き込みによる保守者の操作性低下）の発生を防ぐことができる。既存のシステムには、データベースアクセス回数が多い要求か否かを判定して、アクセス要求が多いパターン（パターンＡ）について、ＡＣＴ状態のデータベースサーバ（ＤＢ）と同じ拠点のアクセスサーバ（ＡＣ）の中にＡＣＴ状態のアクセスサーバ（ＡＣ）があれば、他の拠点のアクセスサーバ（ＡＣ）よりも優先して接続するというロジック（制御）が存在しない。しかし、本願開示では、そのロジックを実装したことで、第１の問題を防ぐことができる。

【0157】

第２の効果は、耐障害性の向上である。これは、第２の問題（保守者がシステム利用できない時間の発生）を防ぐことを意味する。初期状態において、東と西の両方のＮＭＳにＡＣＴ状態のアクセスサーバ（ＡＣ）を配置することで、データベースサーバ（ＤＢ）障害時や、ＮＭＳ東の全サーバ障害時などでも、保守者が継続してシステム利用できる（システム利用できない時間の発生を防ぐ）。

【0158】

さらに、フロントエンドサーバ（ＦＥ）の単独障害の場合には、もう片方のフロントエンドサーバ（ＦＥ）が動作していれば、システムが問題なく利用でき第１、第２の問題は発生しない。同様に、同期サーバ（ＳＣ）の単独障害時もシステムは問題なく利用でき、第１、第２の問題は発生しない。アクセスサーバ（ＡＣ）障害については、アクセスサーバ（ＡＣ）が単独障害を起こした場合や、ある拠点のアクセスサーバ（ＡＣ）が全て障害になった場合でも、ＡＣＴ状態のデータベースサーバ（ＤＢ）が東西のＮＭＳのいずれかにあるかを判別し、最適な振り分けを行うことができる。

【0159】

データベースサーバ（ＤＢ）単独障害時もシステムは問題なく利用でき、第１、第２の問題は発生しない。また、第１、第２の問題に関し、問題を発生させないための最善の振り分け処理を実現できる。データベースサーバ（ＤＢ）両系ＡＣＴは正常でない状態であるが、通常運用状態からデータベースサーバ（ＤＢ－Ｅ）と同期サーバ（ＳＣ）の間のネットワークが障害になったことを同期サーバ（ＳＣ）が検知し、同期サーバ（ＳＣ）がデータベースサーバ（ＤＢ－Ｗ）をＡＣＴからＳＢＹに遷移させた後、ネットワーク障害が復旧した状態では、この状態になる。そのため、この状態でも、システムができるだけ正しい振る舞いができるよう、ＡＣＴ データベースサーバ（ＤＢ）判定の方法を、前回のヘルスチェック時の判定結果を採用することと、定義した。

【0160】

第３の効果は、アクセスサーバ（ＡＣ）の負荷分散である。拠点内に複数のＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するときは、監視端末からの処理要求をラウンドロビンで別々のアクセスサーバ（ＡＣ）に処理させるよう振り分けることができる。東西両方の拠点のＮＭＳに、ＡＣＴ状態のアクセスサーバ（ＡＣ）が存在するときは、データベース（ＤＢ）アクセスの数が多い処理をＡＣＴ状態のデータベースサーバ（ＤＢ）が存在する拠点のアクセスサーバ（ＡＣ）に振り分け、データベース（ＤＢ）アクセスの数が少ない処理を他方の拠点のアクセスサーバ（ＡＣ）に振り分けることができる。

【0161】

［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。

【0162】

ここで、ＡＣＴ状態のアクセスサーバ（ＡＣ）が障害になったとき、東西のＮＭＳ全体のＡＣＴ状態のアクセスサーバ（ＡＣ）の合計数まで、ＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴ状態に遷移させることができる。しかし、図６に示すフロントエンドサーバ（ＦＥ）を利用した処理要求振り分け（ＤＢ－Ｅ障害時）では、ＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴに遷移させる仕組みがなく、アクセスサーバ（ＡＣ３２－３Ｅ、ＡＣ３２－４Ｅ）はＳＢＹ状態のままである。

【0163】

第２の実施形態では、ＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴに遷移させる仕組みを備えるシステムについて説明する。第２の実施形態では、フロントエンドサーバ（ＦＥ）にＡＣＴ状態とＳＢＹ状態を新たに定義し、アクセスサーバ（ＡＣ）をＳＢＹからＡＣＴに遷移させる要求を送信する機能を持たせる。当該機能により、アクセスサーバ（ＡＣ）がＳＢＹから自動的にＡＣＴに遷移できるように構成している。

【0164】

フロントエンドサーバ（ＦＥ）のＡＣＴ状態は、ＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴに遷移させる要求を出すことができることとする。フロントエンドサーバ（ＦＥ）のＳＢＹ状態は、ＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴに遷移させる要求を出さない状態とする。

【0165】

ＡＣＴ状態のフロントエンドサーバ（ＦＥ）は、東西のＮＭＳ中に１台とする。その理由は、複数台のフロントエンドサーバ（ＦＥ）が同時にＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴ状態に遷移させる処理を行うことを回避するためである。

【0166】

ＮＭＳ東のフロントエンドサーバ（ＦＥ）とＮＭＳ西のフロントエンドサーバ（ＦＥ）は、互いに対向マシンの状態を監視する。ＡＣＴ状態の対向マシンが障害になると、ＳＢＹ状態のマシンは、ＡＣＴ状態に遷移する。

【0167】

図２５は、第２の実施形態において、アクセスサーバ（ＡＣ４２－１Ｅ）に障害が発生し、アクセスサーバ（ＡＣ）４２－３ＥをＡＣＴ化する場合の動作を説明するための図である。図２５には、ＡＣＴ状態のアクセスサーバ（ＡＣ）４２－１Ｅの運用中に障害状態となった場合の動作が示されている。

【0168】

Ｓ１は、ＡＣＴ状態のアクセスサーバ（ＡＣ）４２－１Ｅに障害は発生したことを示す。

【0169】

Ｓ２では、ＡＣＴ状態のフロントエンドサーバ（ＦＥ）４３Ｅが、アクセスサーバ（ＡＣ）４２－１Ｅにアクセスサーバ（ＡＣ）ヘルスチェック要求を送信したが、その応答がなく、アクセスサーバ（ＡＣ）４２－１Ｅが障害状態になったことを把握する。

【0170】

Ｓ３では、ＮＭＳ東のＳＢＹ状態のアクセスサーバ（ＡＣ）のなかからアクセスサーバ（ＡＣ）４２－３Ｅに対して、フロントエンドサーバ（ＦＥ）４３Ｅが、アクセスサーバアクティブ化要求（ＡＣ ＡＣＴ化要求）を送信する。これにより、アクセスサーバ（ＡＣ）４２－３ＥはＳＢＹ状態からＡＣＴ状態に遷移する。

【0171】

図２６は、アクセスサーバ（ＡＣ）ヘルスチェックの結果、アクセスサーバ（ＡＣ－Ｅ１）に障害時、アクセスサーバ（ＡＣ－Ｅ３）のＡＣＴ化の一例を示すシーケンス図である。図２６は、図２５に示す動作をシーケンスで表したものである。

【0172】

アクセスサーバ（ＡＣ－Ｅ１）で障害が発生した後のＡＣヘルスチェック要求Ｓ２５１１に対して、アクセスサーバ（ＡＣ－Ｅ１）はＡＣヘルスチェックに対して応答しない（Ｓ２５１２）。その結果、タイムアウト処理により、アクセスサーバ（ＡＣ－Ｅ１）＝障害で状態が更新（Ｓ２５１５）された後、Ｓ２５１５’で障害の起こったアクセスサーバ（ＡＣ）の停止要求が通知されてもよい。

【0173】

その後、フロントエンドサーバ（ＦＥ）は、ＮＭＳ東のアクセスサーバ（ＡＣ）内にＳＢＹ状態からＡＣＴ状態に遷移させることが可能なアクセスサーバ（ＡＣ）が存在するか否かを確認する。フロントエンドサーバ（ＦＥ）は、ＮＭＳ東のアクセスサーバ（ＡＣ）のＳＢＹ状態の数＞０であり、且つ、東西のＮＭＳのアクセスサーバ（ＡＣ）のＡＣＴ状態の数＜４を満たすか否かを判定する（Ｓ２５１６）。

【0174】

当該判定が“ＹＥＳ”の場合には、ＳＢＹ状態からＡＣＴ状態に遷移させることが可能なアクセスサーバ（ＡＣ）が存在することを示しているので、フロントエンドサーバ（ＦＥ）のアクセスサーバ（ＡＣ）ヘルスチェックプロセスは、アクセスサーバ（ＡＣ） ＡＣＴ化通知（アクセスサーバＡＣ－Ｅ１障害）を、アクセスサーバ（ＡＣ） ＡＣＴ化プロセスに通知する（Ｓ２５１７）。

【0175】

なお、上記処理を別々のプロセスで処理している理由は、同一のプロセスで処理を行うと、アクセスサーバ（ＡＣ） ＡＣＴ化の処理が終了するまで、次回のアクセスサーバ（ＡＣ）ヘルスチェック要求を送信することができず、アクセスサーバ（ＡＣ）ヘルスチェック要求を一定間隔で送信できなくなるためである。但し、アクセスサーバ（ＡＣ）ヘルスチェックプロセスとアクセスサーバ（ＡＣ） ＡＣＴ化プロセスが一体化されていてもよい。

【0176】

アクセスサーバ（ＡＣ） ＡＣＴ化通知（アクセスサーバ（ＡＣ－Ｅ１）障害；Ｓ２５１７）を受けたアクセスサーバ（ＡＣ） ＡＣＴ化プロセスは、ＮＭＳ東のアクセスサーバ（ＡＣ）のうち、ＳＢＹ状態からＡＣＴ状態に遷移させることが可能なアクセスサーバ（ＡＣ）の全てについて、アクセスサーバ（ＡＣ） ＡＣＴ化要求）を送信する（Ｓ２５２２）。図２６では、アクセスサーバ（ＡＣ－Ｅ３）に、アクセスサーバ（ＡＣ） ＡＣＴ化要求が送信され（Ｓ２５２２）、アクセスサーバ（ＡＣ－Ｅ３）は状態をＳＢＹからＡＣＴに変更する（Ｓ２５２３）。

【0177】

アクセスサーバ（ＡＣ－Ｅ３）は、アクセスサーバ（ＡＣ） ＡＣＴ化応答をフロントエンドサーバ（ＦＥ）のアクセスサーバ（ＡＣ） ＡＣＴ化プロセスに送信する（Ｓ２５２４）。アクセスサーバ（ＡＣ） ＡＣＴ化プロセスは、状態テーブルのアクセスサーバ（ＡＣ－Ｅ３）の状態を、ＡＣＴ状態に更新する（Ｓ２５２５）。

【0178】

上記Ｓ２５１６の判定がＮｏの場合には、ＮＭＳ西にＳＢＹ状態からＡＣＴ状態に遷移させることができるアクセスサーバ（ＡＣ）が存在するか否かの確認を行う。具体的には、ＮＭＳ西アクセスサーバ（ＡＣ） ＳＢＹ状態の数＞０ 且つ 東西のＮＭＳのアクセスサーバ（ＡＣ） ＡＣＴ状態の数＜４が満たされるか否かが判定される（Ｓ２５１８）。ここで、図２６は、アクセスサーバ（ＡＣ－Ｅ１）に障害が発生した場合のシーケンス図であるので、ＳＢＹ状態にあるアクセスサーバ（ＡＣ）をＡＣＴ状態にする処理は働かない。従って、Ｓ２５１８の判定結果は“ＮＯ”となる。その結果、西のアクセスサーバ（ＡＣ）のＡＣＴ化は行われず処理は終了する。

【0179】

なお、条件が変わり、Ｓ２５１８の判定結果が“ＹＥＳ”となる場合もある。この場合、アクセスサーバ（ＡＣ） ＡＣＴ化通知がアクセスサーバ（ＡＣ） ＡＣＴ化プロセスに通知（Ｓ２５１９）され、アクセスサーバ（ＡＣ）のＡＣＴ化が実施される（Ｓ２５１１０）。この場合、対象とするアクセスサーバ（ＡＣ）は、ＳＢＹ状態にある西アクセスサーバ（ＡＣ）の全てであり、終了条件は、ＡＣＴ状態の東西ＮＭＳのアクセスサーバ（ＡＣ）の数が「４」に達した場合である。ＮＭＳ西のアクセスサーバ（ＡＣ）のＡＣＴ化が完了すると、その旨がアクセスサーバ（ＡＣ）ヘルスチェックプロセスに通知される（Ｓ２５２１０’）。

【0180】

なお、アクセスサーバ（ＡＣ－Ｅ１）の障害のときに、東西のＮＭＳのうち、ＮＭＳ東のアクセスサーバ（ＡＣ）の方を先に、ＳＢＹ状態からＡＣＴ状態に遷移させる対象にして処理を行う理由は、東西のＮＭＳにＡＣＴ状態のアクセスサーバ（ＡＣ）が１台以上存在することで、問題２を発生させることを防ぐことができるためである。同様に、図７（フロントエンドサーバ（ＦＥ）を利用した処理要求振り分け 東拠点被災時）では、ＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴ状態に遷移させる仕組みがなく、アクセスサーバ（ＡＣ－Ｗ３及びＡＣ－Ｗ４）は、ＳＢＹ状態のままであったが、本実施形態によれば、自動的にＡＣＴに遷移できるようにする。

【0181】

図２７は、ＮＭＳ東において全サーバに障害が発生し、ＮＭＳ西のアクセスサーバ（ＡＣ）をアクティブ化（ＡＣＴ化）する場合の動作を説明するための図である。図２７には、東拠点が被災し、全サーバが障害に陥った後、アクセスサーバ（ＡＣ－Ｗ３及びＡＣ－Ｗ４）が自動的にＳＢＹ状態からＡＣＴ状態に遷移することを示す動作例である。

【0182】

Ｓ１は、ＮＭＳ東の全サーバが障害状態になったことを示す。

【0183】

Ｓ２では、ＡＣＴ状態のフロントエンドサーバ（ＦＥ）６７Ｗが、アクセスサーバ（ＡＣ）６２－１Ｅ～アクセスサーバ（ＡＣ）６２－４Ｅに対して、アクセスサーバ（ＡＣ）ヘルスチェック要求を送信する。しかし、その応答はなく、アクセスサーバ（ＡＣ）６２－１Ｅ～アクセスサーバ（ＡＣ６２－４Ｅは障害状態として扱われる。

【0184】

Ｓ３では、フロントエンドサーバ（ＦＥ）６７Ｗが、ＮＭＳ西のＳＢＹ状態のアクセスサーバ（ＡＣ）の中からアクセスサーバ（ＡＣ）６６－３Ｗ、アクセスサーバ（ＡＣ）６６－４Ｗに対して、アクセスサーバ（ＡＣ） ＡＣＴ化要求を送信する。その結果、アクセスサーバ（ＡＣ）６６－３Ｗとアクセスサーバ（ＡＣ）６６－４Ｗは、ＳＢＹ状態からＡＣＴ状態に遷移する。

【0185】

図２８は、ＡＣヘルスチェックにおけるＮＭＳ東のＡＣ全障害時、アクセスサーバ（ＡＣ－Ｗ３、ＡＣ－Ｗ４）のＡＣＴ化の一例を示すシーケンス図である。図２８は、図２７の動作をシーケンスで表現したものである。

【0186】

アクセスサーバ（ＡＣ－Ｅ１～ＡＣ－Ｅ４）において障害が発生した後のフロントエンドサーバ（ＦＥ）からのアクセスサーバ（ＡＣ）ヘルスチェック要求（Ｓ２７１１）に対して、アクセスサーバ（ＡＣ－Ｅ１～ＡＣ－Ｅ４）は、該アクセスサーバ（ＡＣ）ヘルスチェックに応答しない（Ｓ２７１２）。その後、ＮＭＳ西のアクセスサーバ（ＡＣ）の状態が更新（Ｓ２７１４）され、タイムアウト処理にてＮＭＳ東のアクセスサーバ（ＡＣ）の状態は、全て障害状態に更新される（Ｓ２７１４ａ）。

【0187】

その後、フロントエンドサーバ（ＦＥ）は、ＮＭＳ東のアクセスサーバ（ＡＣ）内に、ＳＢＹからＡＣＴに遷移させることが可能なアクセスサーバ（ＡＣ）が存在するか否かを確認する（Ｓ２７１５）。具体的には、ＮＭＳ東のアクセスサーバ（ＡＣ） ＳＢＹ状態の数＞０ 且つ 東西のＮＭＳのアクセスサーバ（ＡＣ） ＡＣＴ状態の数＜４を満たすか否かの判定により確認される。ここでは、Ｓ２７１５の判定は“ＮＯ”となるが、“ＹＥＳ”の場合には、フロントエンドサーバ（ＦＥ）内のアクセスサーバ（ＡＣ） ＡＣＴ化通知が、アクセスサーバ（ＡＣ） ＡＣＴ化プロセスに通知され（Ｓ２７１９）され、アクセスサーバ（ＡＣ）のＡＣＴ化が実施される（Ｓ２７１１０）。この場合、対象とするアクセスサーバ（ＡＣ）は、ＳＢＹ状態にあるＮＭＳ東アクセスサーバ（ＡＣ）の全てであり、終了条件はＡＣＴ状態の東西のＮＭＳのアクセスサーバ（ＡＣ）の数が「４」に達した場合である。ＮＭＳ東のアクセスサーバ（ＡＣ）のＡＣＴ化が完了すると、その旨が、フロントエンドサーバ（ＦＥ）内のアクセスサーバ（ＡＣ）ヘルスチェックプロセスに通知される（Ｓ２７２１０’）。

【0188】

フロントエンドサーバ（ＦＥ）は、ＮＭＳ東のアクセスサーバ（ＡＣ）内に、ＳＢＹ状態からＡＣＴ状態に遷移させることが可能なアクセスサーバ（ＡＣ）は存在しないことを確認する（Ｓ２７１５、ＮＯ分岐）。その後、フロントエンドサーバ（ＦＥ）は、西のアクセスサーバ（ＡＣ）内に、ＳＢＹ状態からＡＣＴ状態に遷移させることが可能なアクセスサーバ（ＡＣ）が存在するか否かを確認する（Ｓ２７１６）。具体的には、ＮＭＳ西アクセスサーバ（ＡＣ） ＳＢＹ状態の数＞０、且つ、東西のＮＭＳのアクセスサーバ（ＡＣ） ＡＣＴ状態の数＜４を満たすか否かの判定により確認される。

【0189】

上記判定が“ＹＥＳ”の場合には、ＳＢＹ状態からＡＣＴ状態に遷移させることが可能なアクセスサーバ（ＡＣ）が存在するので、アクセスサーバ（ＡＣ） ＡＣＴ化通知（アクセスサーバ（ＡＣ－Ｅ１～ＡＣ－Ｅ４障害）を、アクセスサーバ（ＡＣ）ヘルスチェックプロセスから、アクセスサーバ（ＡＣ） ＡＣＴ化プロセスに通知する（Ｓ２７１７）。

【0190】

上記通知（ＡＣ ＡＣＴ化通知（ＡＣ－Ｅ１～ＡＣ－Ｅ４障害）；Ｓ２５１７）を受けたフロントエンドサーバ（ＦＥ）のアクセスサーバ（ＡＣ） ＡＣＴ化プロセスは、ＮＭＳ西のアクセスサーバ（ＡＣ）のうち、ＳＢＹ状態からＡＣＴ状態に遷移させることが可能なアクセスサーバ（ＡＣ）の全てについて、アクセスサーバ（ＡＣ） ＡＣＴ化要求を送信する。

【0191】

図２８の例では、アクセスサーバ（ＡＣ－Ｗ３、ＡＣ－Ｗ４）に、ＡＣ ＡＣＴ化要求を送信する（Ｓ２７２２）。アクセスサーバ（ＡＣ－Ｗ３、ＡＣ－Ｗ４）はそれぞれの状態を、ＳＢＹからＡＣＴに変更する（Ｓ２７２３）。

【0192】

アクセスサーバ（ＡＣ－Ｅ３、ＡＣ－Ｅ４）は、アクセスサーバ（ＡＣ） ＡＣＴ化応答をフロントエンドサーバ（ＦＥ）のアクセスサーバ（ＡＣ） ＡＣＴ化プロセスに送信する（Ｓ２７２４）。フロントエンドサーバ（ＦＥ）のアクセスサーバ（ＡＣ） ＡＣＴ化プロセスは、ＦＥ状態テーブルのアクセスサーバ（ＡＣ－Ｗ３、ＡＣ－Ｗ４）の状態を、ＡＣＴに更新する（Ｓ２７２５）。上記Ｓ２７１６の判定が“ＮＯ”の場合には、図２８の処理を終了する。

【0193】

［第３の実施形態］
続いて、第３の実施形態について図面を参照して詳細に説明する。

【0194】

なお、第２の実施形態ではフロントエンドサーバ（ＦＥ）が、障害の生じたアクセスサーバ（ＡＣ）に代わって、ＳＢＹ状態のアクセスサーバ（ＡＣ）の中からアクセスサーバ（ＡＣ）を選択し、ＡＣＴ化することを記載した。第３の実施形態では、フロントエンドサーバ（ＦＥ）が、障害の生じたアクセスサーバ（ＡＣ）に代わってＳＢＹ状態のアクセスサーバ（ＡＣ）の中からアクセスサーバ（ＡＣ）を選択し、ＡＣＴ化した後に、フロントエンドサーバ（ＦＥ）が障害の生じているアクセスサーバ（ＡＣ）を停止させる場合を説明する。

【0195】

なお、停止の実装方法はいくつか考えられる。

【0196】

例えば、アクセスサーバ（ＡＣ）が物理マシンであって、アクセスサーバ（ＡＣ）の物理マシン電源停止によりアクセスサーバ（ＡＣ）停止を実装する場合は、電源停止による省電力化のメリットが得られる。

【0197】

アクセスサーバ（ＡＣ）が仮想マシンであって、アクセスサーバ（ＡＣ）の仮想マシンを停止させることにより、アクセスサーバ（ＡＣ）停止を実装する場合、仮想マシンに割り当てていたＣＰＵ、メモリなどのリソースを回収でき、別の仮想マシン起動に活用することもできる。

【0198】

また、フロントエンドサーバ（ＦＥ）が、障害の生じたアクセスサーバ（ＡＣ）に代わって、ＳＢＹ状態のアクセスサーバ（ＡＣ）の中からアクセスサーバ（ＡＣ）を選択してＡＣＴ化し、アクセスサーバ（ＡＣ）を停止させた後、フロントエンドサーバ（ＦＥ）は、目的に応じて、停止させたアクセスサーバ（ＡＣ）と同一拠点においてアクセスサーバ（ＡＣ）を起動してもよいし、あるいは、異なる拠点にアクセスサーバ（ＡＣ）を起動してもよい。

【0199】

例えば、各拠点にＳＢＹ状態のアクセスサーバ（ＡＣ）を用意しておくために、ＳＢＹ状態のアクセスサーバ（ＡＣ）がない拠点にアクセスサーバ（ＡＣ）を起動してもよいし、各拠点に一定数のアクセスサーバ（ＡＣ）を用意しておくために、停止したアクセスサーバ（ＡＣ）と同拠点に新たなアクセスサーバ（ＡＣ）を起動してもよい。

【0200】

起動処理を実施した後のアクセスサーバ（ＡＣ）の状態は、アクセスサーバ（ＡＣ）のＡＣＴ状態の上限台数に達していない場合、ＡＣＴ状態になり、ＡＣＴ上限台数に達している場合には、ＳＢＹ状態になる。ＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴ状態にする処理時間は、停止中のアクセスサーバ（ＡＣ）を起動してＡＣＴ状態にする処理時間に比べて短い。

【0201】

そのため、アクセスサーバ（ＡＣ）に障害が発生した後に、ＳＢＹ状態のアクセスサーバ（ＡＣ）と、停止中アクセスサーバ（ＡＣ）の両方が存在し、いずれかのＡＣＴ化処理を実施する場合には、ＳＢＹ状態のアクセスサーバ（ＡＣ）をＡＣＴにする方を優先すると、障害からの復旧時間が早くなる。

【0202】

また、停止中のアクセスサーバ（ＡＣ）を起動させてＳＢＹ状態にしておくことで、次に別のアクセスサーバ（ＡＣ）の障害が発生したときに、ＳＢＹにしておいたアクセスサーバ（ＡＣ）をＡＣＴ化することができ、停止中のアクセスサーバ（ＡＣ）をＡＣＴ状態とする場合と比べて、より早く障害から復旧させることができる。

【0203】

［ハードウェア構成］
続いて、ネットワークシステムをなす各装置のハードウェア構成について説明する。

【0204】

図２９は、フロントエンドサーバ（ＦＥ）３３Ｅのハードウェア構成の一例を示す図である。フロントエンドサーバ（ＦＥ）３３Ｅは、所謂、情報処理装置（コンピュータ）により実現され、図２９に例示する構成を備える。例えば、フロントエンドサーバ（ＦＥ）３３Ｅは、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）５１、メモリ５２、入出力インターフェイス５３、通信手段であるＮＩＣ（Network Interface Card）５４等を備える。

【0205】

但し、図２９に示す構成は、フロントエンドサーバ（ＦＥ）３３Ｅのハードウェア構成を限定する趣旨ではない。フロントエンドサーバ（ＦＥ）３３Ｅは、図示しないハードウェアを含んでもよい。フロントエンドサーバ（ＦＥ）３３Ｅに含まれるＣＰＵ等の数も図２９の例示に限定する趣旨ではなく、例えば、複数のＣＰＵ５１がフロントエンドサーバ（ＦＥ）３３Ｅに含まれていてもよい。

【0206】

メモリ５２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）等である。

【0207】

入出力インターフェイス５３は、図示されない入出力装置のインターフェイスである。入出力装置には、例えば、表示装置、操作デバイス等が含まれる。表示装置は、例えば、液晶ディスプレイ等である。操作デバイスは、例えば、キーボードやマウス等である。

【0208】

フロントエンドサーバ（ＦＥ）３３Ｅの機能は、上述の処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ５２に格納されたプログラムをＣＰＵ５１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能は、何らかのハードウェア、或いはハードウェアを利用して実行されるソフトウェアにより実現できればよい。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。

【0209】

なお、アクセスサーバ等も情報処理装置（コンピュータ）により実現可能であり、そのハードウェア構成は当業者にとって明らかであるため詳細な説明を省略する。

【0210】

［変形例］
上記実施形態では、東西の管理システム（ＮＭＳ）それぞれにフロントエンドサーバ（ＦＥ）が含まれる構成を説明したが、フロントエンドサーバは少なくとも１台システムに含まれていればよい。また、フロントエンドサーバは、必ずしも東西の管理システム（ＮＭＳ）に含まれていなくともよい。また、地理的に離れた東西の管理システムの東西はあくまで説明のための一例であり、方位は東西に制限されるものでないことは勿論である。

【0211】

また、上述の説明で用いた複数のフローチャートでは、複数の工程（処理）が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。また、上述の各実施形態は、内容が相反しない範囲で組み合わせることができる。

【0212】

上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、地理的に分散し、データベースを利用するネットワークシステムやデータベースに連続して多数回のアクセスを行う処理を行うシステム等に好適に適用可能である。

【0213】

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
上述の第１の視点に係るネットワークシステムのとおりである。
［付記２］
前記フロントエンドサーバは、前記監視端末から取得したアクセス要求を、前記データベースサーバへのアクセスが、所定の回数以上連続する第１のパターン又は前記所定の回数よりも少なく連続する第２のパターンのいずれかであるかに分類し、分類結果に基づき前記アクセス要求の送信先を決定する、付記１に記載のネットワークシステム。
［付記３］
前記フロントエンドサーバは、前記アクセス要求が第１のパターンであれば、前記データベースサーバがアクティブな管理システムに含まれる前記アクセスサーバを前記第１のパターンのアクセス要求の送信先として決定する、付記２に記載のネットワークシステム。
［付記４］
前記フロントエンドサーバは、前記アクセス要求が第２のパターンであれば、前記データベースサーバがアクティブな管理システムとは異なる管理システムに含まれる前記アクセスサーバを、前記第２のパターンのアクセス要求の送信先として決定する、付記２又は３に記載のネットワークシステム。
［付記５］
前記フロントエンドサーバは、前記第１、第２の管理システムに含まれるアクセスサーバのうちアクティブなアクセスサーバを前記アクセス要求の送信先として決定する、付記２乃至４のいずれか一に記載のネットワークシステム。
［付記６］
前記第１、第２の管理システムのそれぞれに複数の前記アクセスサーバが含まれ、
前記フロントエンドサーバは、前記アクセス要求の送信先となるアクセスサーバをラウンドロビンにより決定する、付記２乃至４のいずれか一に記載のネットワークシステム。
［付記７］
前記第１、第２の管理システムのそれぞれは、前記フロントエンドサーバを含み、
前記監視端末は、前記第１又は第２の管理システムに含まれるフロントエンドサーバから前記アクセス要求に関する応答が無い場合には、前記応答がないフロントエンドサーバを含む管理システムとは異なる管理システムのフロントエンドサーバに前記アクセス要求を送信する、付記１乃至６のいずれか一に記載のネットワークシステム。
［付記８］
前記第１、第２の管理システムに含まれるデータベースサーバ間の同期を実現する同期サーバをさらに備える、付記１乃至７のいずれか一に記載のネットワークシステム。
［付記９］
前記同期サーバは、前記データベースサーバがアクティブであるかスタンバイであるかを管理し、
前記フロントエンドサーバは、前記同期サーバが前記データベースサーバに関する管理ができない場合に、前記データベースサーバに対して状態確認要求を送信し、前記状態確認要求への応答に基づいて前記データベースサーバがアクティブであるかスタンバイであるかを管理する、付記８に記載のネットワークシステム。
［付記１０］
前記フロントエンドサーバは、前記アクセスサーバの障害発生を検出すると、スタンバイ状態の前記アクセスサーバをアクティブ状態にする、付記１乃至９のいずれか一に記載のネットワークシステム。
［付記１１］
前記フロントエンドサーバは、前記第１、第２の管理システムに含まれるアクセスサーバに対してヘルスチェック要求を送信し、前記ヘルスチェック要求への応答に基づいて各アクセスサーバの状態を管理する、付記１乃至１０のいずれか一に記載のネットワークシステム。
［付記１２］
前記フロントエンドサーバは、決定した前記アクセス要求の送信先を前記監視端末に通知する、付記１乃至９のいずれか一に記載のネットワークシステム。
［付記１３］
上述の第２の視点に係るネットワークシステムの制御方法のとおりである。

【0214】

なお、引用した上記の特許文献の開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択（部分的削除を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。さらに、上記引用した文献の各開示事項は、必要に応じ、本発明の趣旨に則り、本発明の開示の一部として、その一部又は全部を、本書の記載事項と組み合わせて用いることも、本願の開示事項に含まれるものとみなされる。

【符号の説明】

【0215】

１０－１、３０－１、４０－１、６０－１ ＮＭＳ東
１０－２、３０－２、４０－２、６０－２ ＮＭＳ西
１１－１～１１－ｎ ネットワーク装置（ＮＥ）
１２－１Ｅ～１２－ｙＥ、１５－１Ｗ～１５－ｙＷ マネージメントサーバ（ＭＧ）
１３Ｅ、１６Ｗ、３１Ｅ、３４Ｗ、４１Ｅ、４４Ｗ、６１Ｅ、６４Ｗ、１１１ ＤＢ
１４－１Ｅ～１４－４Ｅ、１８－１Ｗ～１８－４Ｗ、３２－１Ｅ～３２－４Ｅ、３６－１Ｗ～３６－４Ｗ、４２－１Ｅ～４２－４Ｅ、４６－１Ｗ～４６－４Ｗ、６２－１Ｅ～６２－４Ｅ、６６－１Ｗ～６６－４Ｗ、１１２ アクセスサーバ（ＡＣ）
１７、３５、４５、６５ 同期サーバ（ＳＣ）
１９－１～１９－ｚ、３８－１～３８－ｚ、４８－１～４８－ｚ、６８－１～６８－ｚ 監視端末
３３Ｅ、３７Ｗ、４３Ｅ、４７Ｗ、６３Ｅ、６７Ｗ、１０３ フロントエンドサーバ（ＦＥ）
５１ ＣＰＵ
５２ メモリ
５３ 入出力インターフェイス
５４ ＮＩＣ
１０１ 第１の管理システム
１０２ 第２の管理システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】