(57)【要約】      （修正有）【課題】管理作業中に管理サーバーで障害が発生した場合であっても管理対象の情報の欠損を抑える。【解決手段】サブサーバー１０３は、設定された時間間隔で、メインサーバー１０２に対して処理対象と処理内容とが設定された処理要求、及び処理要求の結果、が登録されている第１記憶部の情報についての第１取得要求を送信して、応答されてきた情報を第２記憶部に登録する。第１取得要求に対する応答がない場合にメインサーバーでの障害の発生を判定し、障害が発生したと判定された場合、複数のスレーブサーバー１１４、１１５、１１６のそれぞれに対して、処理要求、及び処理要求の結果が登録されている第３記憶部の情報についての第２取得要求を送信し、第２取得要求に対する応答に含まれる情報で第２記憶部の登録情報を補完する。【選択図】図１
2017138923.tif 000002
【特許請求の範囲】
【請求項１】
第１管理サーバーと、第２管理サーバーと、複数のサーバーと、を含むシステムであって、
前記第１管理サーバーは、
処理対象と処理内容とが設定された処理要求を第１記憶部に登録する第１の登録手段と、
前記処理要求を前記複数のサーバーのそれぞれに対して送信する第１の送信手段と、
前記処理要求の結果を受信する第１の受信手段と、
前記受信した結果を前記第１記憶部に登録する第２の登録手段と、
前記第２管理サーバーからの前記第１記憶部の情報についての第１取得要求に対して、前記第１記憶部に登録された情報を応答する第１応答手段と、
を有し、
前記第２管理サーバーは、
設定された時間間隔で、前記第１管理サーバーに対して前記第１記憶部の情報についての第１取得要求を送信する第２の送信手段と、
前記第１取得要求に対して応答されてきた情報を第２記憶部に登録する第３の登録手段と、
前記第１取得要求に対する応答がない場合に前記第１管理サーバーでの障害の発生を判定する判定手段と、
前記第１管理サーバーに障害が発生したと判定された場合、前記複数のサーバーのそれぞれに対して、第３記憶部の情報についての第２取得要求を送信する第３の送信手段と、
前記第２取得要求に対する応答に含まれる情報で前記第２記憶部の登録情報を補完する補完手段と、
を有し、
前記複数のサーバーのそれぞれは、
処理要求を受信する第２の受信手段と、
処理対象に対して処理内容に対応する処理を実行する実行手段と、
処理要求、及び前記処理要求の結果を前記第３記憶部に登録する第４の登録手段と、
前記処理要求の結果を前記処理要求の送信もとに送信する第４の送信手段と、
前記第２管理サーバーからの前記第３記憶部の情報についての第２取得要求に対して、前記第３記憶部に登録された情報を応答する第２応答手段と、
を有するシステム。
【請求項２】
前記第２管理サーバーは、
前記第２記憶部の登録情報の補完の結果、未実行の処理があった場合、前記未実行の処理の処理要求を前記複数のサーバーの少なくとも何れかに対して送信する第５の送信手段を更に有する請求項１記載のシステム。
【請求項３】
前記複数のサーバーのそれぞれは、少なくとも前記設定された時間間隔よりも長い時間、前記第３記憶部で情報を保持する請求項１又は２記載のシステム。
【請求項４】
設定された時間間隔で、第１管理サーバーに対して、処理対象と処理内容とが設定された処理要求、及び前記処理要求の結果、が登録されている第１記憶部の情報についての第１取得要求を送信する第１の送信手段と、
前記第１取得要求に対して応答されてきた情報を第２記憶部に登録する登録手段と、
前記第１取得要求に対する応答がない場合に前記第１管理サーバーでの障害の発生を判定する判定手段と、
前記第１管理サーバーに障害が発生したと判定された場合、複数のサーバーのそれぞれに対して、処理要求、及び前記処理要求の結果が登録されている第３記憶部の情報についての第２取得要求を送信する第２の送信手段と、
前記第２取得要求に対する応答に含まれる情報で前記第２記憶部の登録情報を補完する補完手段と、
を有する管理サーバー。
【請求項５】
第１管理サーバーと、第２管理サーバーと、複数のサーバーと、を含むシステムにおける情報処理方法であって、
前記第１管理サーバーが、処理対象と処理内容とが設定された処理要求を第４記憶部に登録する第１の登録工程と、
前記第１管理サーバーが、前記処理要求を前記複数のサーバーのそれぞれに対して送信する第１の送信工程と、
前記複数のサーバーのそれぞれが、処理要求を受信する第１の受信工程と、
前記複数のサーバーのそれぞれが、処理対象に対して処理内容に対応する処理を実行する実行工程と、
前記複数のサーバーのそれぞれが、処理要求、及び前記処理要求の結果を第５記憶部に登録する第２の登録工程と、
前記複数のサーバーのそれぞれが、前記処理要求の結果を前記処理要求の送信もとに送信する第２の送信工程と、
前記第１管理サーバーが、前記処理要求の結果を受信する第２の受信工程と、
前記第１管理サーバーが、前記受信した結果を前記第４記憶部に登録する第３の登録工程と、
前記第２管理サーバーが、設定された時間間隔で、前記第１管理サーバーに対して前記第４記憶部の情報について第１取得要求を送信する第３の送信工程と、
前記第１管理サーバーが、前記第２管理サーバーからの前記第４記憶部についての情報の第１取得要求に対して、前記第４記憶部に登録された情報を応答する第１応答工程と、
前記第２管理サーバーが、前記第１取得要求に対して応答されてきた情報を第６記憶部に登録する第４の登録工程と、
前記第２管理サーバーが、前記第１取得要求に対する応答がない場合に前記第１管理サーバーでの障害の発生を判定する判定工程と、
前記第２管理サーバーが、前記第１管理サーバーに障害が発生したと判定された場合、前記複数のサーバーのそれぞれに対して、前記第５記憶部の情報についての第２取得要求を送信する第４の送信工程と、
前記複数のサーバーのそれぞれが、前記第２管理サーバーからの前記第５記憶部の情報についての第２取得要求に対して、前記第５記憶部に登録された情報を応答する第２応答手段と、
前記第２管理サーバーが、前記第２取得要求に対する応答に含まれる情報で前記第６記憶部の登録情報を補完する補完工程と、
を含む情報処理方法。
【請求項６】
管理サーバーが実行する情報処理方法であって、
設定された時間間隔で、第１管理サーバーに対して、処理対象と処理内容とが設定された処理要求、及び前記処理要求の結果、が登録されている第１記憶部の情報についての第１取得要求を送信する第１の送信工程と、
前記第１取得要求に対して応答されてきた情報を第２記憶部に登録する登録工程と、
前記第１取得要求に対する応答がない場合に前記第１管理サーバーでの障害の発生を判定する判定工程と、
前記第１管理サーバーに障害が発生したと判定された場合、複数のサーバーのそれぞれに対して、処理要求、及び前記処理要求の結果が登録されている第３記憶部について情報の第２取得要求を送信する第２の送信工程と、
前記第２取得要求に対する応答に含まれる情報で前記第２記憶部の登録情報を補完する補完工程と、
を含む情報処理方法。
【請求項７】
コンピュータを、請求項４記載の管理サーバーの各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システム、管理サーバー、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
近年、ネットワーク技術の発展により、多くの周辺機器等がネットワークに接続されるようになっており、周辺機器等を管理するためのネットワークデバイス管理システムに対しても、より大規模な環境を一元管理することが求められている。しかしながら、単一のサーバーでそれらを管理する場合、利用可能なメモリ等のリソースの制限や処理速度等の問題で一元管理が難しい環境も多く存在している。
これらの問題を解決するために１つの管理サーバーが複数のサーバーを制御して管理対象のネットワークデバイスを管理するものである。大規模なネットワーク環境を管理する場合、このようなシステム構成とすることにより、ネットワークデバイスと通信を行う際の負荷が複数のスレーブサーバーによって分散されるというメリットがある。
一方、ネットワーク管理システムが大規模対応していくということは、ネットワーク管理システムの管理下にあるユーザー数も大きくなっていくということである。したがって、万が一、ネットワークデバイス管理システムで障害が発生した場合、ユーザーに与える影響もそれに従って大きくなっている。そのため、大規模ネットワークを管理するネットワーク管理システムを安定的に稼働させるためには、障害発生時にそれらのデータをバックアップするシステムが必要となってくる。
しかしながら、１つの管理サーバーが複数のサーバーを制御するシステムの場合、従来のシステムと比較して構成が複雑であるため、その構成を考慮したバックアップシステムが必要である。そのためのバックアップ方法が特許文献１に提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−０３２２１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来の技術は１つの管理サーバーのデータのみをバックアップの対象としている。そのため、１つの管理サーバーからの要求により複数のサーバーで管理対象デバイスに対して処理を行っている最中に１つの管理サーバーで障害が発生した場合、タイミングによっては処理の内容、及び、その結果の情報が欠落してしまう可能性があった。
本発明は、管理作業中に管理サーバーで障害が発生した場合であっても管理対象の情報の欠損を可能な限り抑えることを目的とする。
【課題を解決するための手段】
【０００５】
本発明は、第１管理サーバーと、第２管理サーバーと、複数のサーバーと、を含むシステムであって、前記第１管理サーバーは、処理対象と処理内容とが設定された処理要求を第１記憶部に登録する第１の登録手段と、前記処理要求を前記複数のサーバーのそれぞれに対して送信する第１の送信手段と、前記処理要求の結果を受信する第１の受信手段と、前記受信した結果を前記第１記憶部に登録する第２の登録手段と、前記第２管理サーバーからの前記第１記憶部の情報についての第１取得要求に対して、前記第１記憶部に登録された情報を応答する第１応答手段と、を有し、前記第２管理サーバーは、設定された時間間隔で、前記第１管理サーバーに対して前記第１記憶部の情報についての第１取得要求を送信する第２の送信手段と、前記第１取得要求に対して応答されてきた情報を第２記憶部に登録する第３の登録手段と、前記第１取得要求に対する応答がない場合に前記第１管理サーバーでの障害の発生を判定する判定手段と、前記第１管理サーバーに障害が発生したと判定された場合、前記複数のサーバーのそれぞれに対して、第３記憶部の情報についての第２取得要求を送信する第３の送信手段と、前記第２取得要求に対する応答に含まれる情報で前記第２記憶部の登録情報を補完する補完手段と、を有し、前記複数のサーバーのそれぞれは、処理要求を受信する第２の受信手段と、処理対象に対して処理内容に対応する処理を実行する実行手段と、処理要求、及び前記処理要求の結果を前記第３記憶部に登録する第４の登録手段と、前記処理要求の結果を前記処理要求の送信もとに送信する第４の送信手段と、前記第２管理サーバーからの前記第３記憶部の情報についての第２取得要求に対して、前記第３記憶部に登録された情報を応答する第２応答手段と、を有する。
【発明の効果】
【０００６】
本発明によれば、管理作業中に管理サーバーで障害が発生した場合であっても管理対象の情報の欠損を可能な限り抑えることができる。
【図面の簡単な説明】
【０００７】
【図１】ネットワークデバイス管理システムのシステム構成の一例を示す図である。
【図２】メインサーバーのハードウェア構成等の一例を示す図である。
【図３】各デバイスのソフトウェア構成等の一例を示す図である。
【図４】各種のタスクを生成する際の手順を示すフローチャートである。
【図５】各種の情報を受信する際の動作を示すフローチャートである。
【図６】障害を検知した際の動作を示すフローチャートである。
【図７】タスクの実行結果を受信する際の動作を示すフローチャートである。
【図８】要求を受けて処理を実行する際の動作を示すフローチャートである。
【図９】障害によりダウンした際の動作の一例を示すシーケンス図である。
【図１０】情報のデータ構造の一例を示す図である。
【図１１】ＤＢ情報を管理する際の動作を示すフローチャートである。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面に基づいて説明する。
【０００９】
＜実施形態１＞
図１は、ネットワークデバイス管理システムのシステム構成の一例を示す図である。
マスターシステム１００は、ローカルエリアネットワーク（ＬＡＮ）１０１、メインサーバー１０２、サブサーバー１０３から構成される。
メインサーバー１０２は、ネットワーク管理システムのユーザーの登録操作に応じて、管理対象デバイス１２０に対して管理作業（タスク）として情報の取得、及び、設定を行うための情報（タスク情報）を登録する。メインサーバー１０２は、登録されたタスク等に基づきスレーブシステム１１０を介して、管理対象デバイス１２０に対して各種の操作を指示する。メインサーバー１０２は、第１管理サーバーの一例である。
一方、サブサーバー１０３は、後述の手順により、メインサーバー１０２に対して予め登録された周期でＤＢ情報要求を送信する。メインサーバー１０２は、ＤＢ情報要求に対する応答としてＤＢ（データベース）が管理している情報（ＤＢ情報）をサブサーバー１０３に通知する。更に、サブサーバー１０３は、ＤＢ情報要求に対する応答の有無によってメインサーバー１０２の障害を検知し、障害検知時には後述の手順によってメインサーバー１０２に代わってスレーブシステム１１０との通信を行う。サブサーバー１０３は、第２管理サーバーの一例である。
スレーブシステム１１０は、ローカルエリアネットワーク１１１、１１２、１１３、及び、複数のスレーブサーバー１１４、１１５、１１６から構成される。スレーブサーバー１１４、１１５、１１６は通常時にはメインサーバー１０２からのタスクの実行要求を受け、管理対象デバイス１２０に対して情報の取得、及び、設定を行う他、サブサーバー１０３からの要求を受けてＤＢ情報を通知する場合もある。スレーブシステム１１０を構成するスレーブサーバーは、複数のサーバーの一例である。
管理対象デバイス１２０は、複数の複合機能デバイス１２１、１２２、１２３、１２４、１２５、１２６、１２７、１２８、１２９から構成される。これらの複合機能デバイスはそれぞれスレーブサーバー１１４、１１５，１１６の管理下にあり、対応するスレーブサーバーの要求に応じて情報の設定、及び、通知を行う。
本実施形態においては、ローカルエリアネットワーク１０１、１１１、１１２、１１３はそれぞれ個別に図示しているが、物理的に異なる構成をとる必要はない。したがって、仮想的に構成されてもよいし、更には、同一ネットワーク上でユーザーが定義したグループであってもよいものとする。
【００１０】
図２は、ネットワークデバイス管理システムのマスターシステムにおけるメインサーバー１０２のハードウェア構成等の一例を示す図である。
メインサーバー１０２は、一般的なコンピュータであり、サブサーバー１０３、及び、スレーブサーバー１１４、１１５、１１６についても同様の構成を持つ。
メインサーバー１０２は、ＲＯＭ２０１若しくはハードディスク（ＨＤ）２１０に記憶されたネットワークデバイス管理プログラムを実行するＣＰＵ２００を備える。
本実施形態においては、マスターシステム１００のメインサーバー１０２、及び、サブサーバー１０３にはネットワークデバイス管理プログラムとしてマスタープログラムが稼働する。一方、スレーブシステム１１０を構成するスレーブサーバーにはネットワークデバイス管理プログラムとしてスレーブプログラムが稼働するものとするが、以下の説明においては総称としてネットワークデバイス管理プログラムという名称を用いる。
更に、ＣＰＵ２００は、システムバス２０３に接続された各デバイスを総括的に制御する。ＲＡＭ２０２は、ＣＰＵ２００の主メモリ、ワークエリア等として機能する。
キーボードコントローラ（ＫＢＣ）２０４は、キーボード（ＫＢ）２０８やポインティングデバイス等からの指示入力を制御する。ＤＩＳＰコントローラ（ＤＩＳＰＣ）２０５は、ディスプレイ（ＤＩＳＰ）２０９への表示を制御する。
ディスクコントローラ（ＤＫＣ）２０６は、ハードディスク（ＨＤ）２１０、フレキシブルディスクコントローラ（ＦＤ）２１１、ＣＤ−ＲＯＭドライブ（ＣＤ）２１２とのアクセスを制御する。
【００１１】
ネットワークインタフェースカード（ＮＩＣ）２０７は、ローカルエリアネットワーク１０１を介してスレーブサーバー１１４、１１５、１１６、又は、サブサーバー１０３と双方向のデータを授受する。
ネットワークデバイス管理プログラムはＣＤ−ＲＯＭ等の記憶媒体に格納された形で供給されてもよい。その場合にはＣＤ−ＲＯＭドライブ２１２等によって記憶媒体からプログラムが読み取られ、ハードディスク（ＨＤ）２１０にインストールされる。
ＣＰＵ２００がＲＯＭ２０１又はＨＤ２１０に記憶されたネットワークデバイス管理プログラムに基づき処理を実行することによりネットワークデバイス管理アプリケーション等のソフトウェア機能が実現される。また、ＣＰＵ２００がＲＯＭ２０１又はＨＤ２１０に記憶されたネットワークデバイス管理プログラムに基づき処理を実行することにより後述する図４〜図８、図１１等のフローチャートの処理及び後述する図９のシーケンスの処理等が実現される。以下、マスターのネットワークデバイス管理アプリケーションをマスターアプリケーションといい、スレーブのネットワークデバイス管理アプリケーションをスレーブアプリケーションという。
【００１２】
図３は、ネットワークデバイス管理システムを構成する各デバイスのソフトウェア構成等の一例を示す図である。
本実施形態では、メインサーバー１０２においてマスターアプリケーション３００が稼働し、サブサーバー１０３においてもメインサーバー１０２と同様のマスターアプリケーション３００が稼働しているものとする。したがって、メインサーバー１０２、サブサーバー１０３の間には従属関係はなく、メインサーバー１０２が障害によりダウンした場合にはサブサーバー１０３がメインサーバー１０２の役割を担うものとする。一方、スレーブサーバー１１５にはスレーブアプリケーション３１０が稼働しており、スレーブサーバー１１４、１１６にもそれぞれ同様のスレーブアプリケーション３１０が稼働しているものとする。
マスターアプリケーション３００は、ＷＷＷサーバー３０１上で動作する。マスターアプリケーション３００は、タスクを操作するユーザーによるクライアントＰＣ上のＷＷＷブラウザを介した指示等に応じて処理を行う。また、ＷＷＷサーバー３０１は、スレーブサーバー１１４、１１５、１１６上のＷＷＷサーバー３１１とＷＥＢサービスによって通信を行い、タスクの実行要求、実行結果、ＤＢ情報等を双方向でやり取りする。
全体制御部３０２は、マスターアプリケーション３００の全体を制御し、必要に応じてデバイス管理部３０３、デバイス監視部３０４、デバイス探索部３０５、バックアップ制御部３０６、及び、その他のモジュールに処理を振り分ける。
【００１３】
デバイス管理部３０３は、スレーブサーバー１１４、１１５、１１６を介して管理対象デバイス１２０に対する情報の取得、及び、設定を行うためのタスクを生成し、その実行を制御する。
デバイス監視部３０４は、スレーブサーバー１１４、１１５、１１６を介して管理対象デバイス１２０の状態を監視するためのタスクを生成し、その実行を制御する。デバイス監視部３０４は、管理対象デバイス１２０の障害を検出した場合にはメール通知モジュール等によってクライアントＰＣに障害の発生を通知するための電子メールを送信する。
デバイス探索部３０５は、スレーブサーバー１１４、１１５、１１６を介してネットワークに接続された複合機能デバイスを検出するためのタスクを生成し、その実行を制御する。
バックアップ制御部３０６は、メインサーバー１０２においてはサブサーバー１０３からのＤＢ情報要求を受信し、データベースに格納されているＤＢ情報をサブサーバー１０３に送信する役割を担う。一方、マスターアプリケーション３００がサブサーバー１０３で稼働している場合には、バックアップ制御部３０６は、ＤＢ情報要求をメインサーバー１０２に送信し、応答としてＤＢ情報を受信する。また、バックアップ制御部３０６は、メインサーバー１０２からＤＢ情報要求に対する応答がなかった場合にはスレーブシステム１１０に対してＤＢ情報を要求し、必要に応じてメインサーバー１０２の役割を代行する。
スレーブ制御部３０７は、生成されたタスクの処理やユーザー操作によって入力された設定値を必要に応じて適切なスレーブサーバーに通知する。
ＷＥＢサービス制御部３０８は、デバイス管理部３０３、デバイス監視部３０４、デバイス探索部３０５の各モジュールで生成したタスクの処理やその他の設定情報をスレーブ制御部で選択したスレーブサーバーと送受信する。
データベース部３０９は、デバイス管理部３０３、デバイス監視部３０４、デバイス探索部３０５の各モジュールで生成したタスクの情報やその実行結果、及び、各種の設定情報や履歴情報をＨＤ２１０等に格納し、管理する。データベース部３０９が管理しているこれらの情報をＤＢ情報という。
【００１４】
一方、スレーブアプリケーション３１０は、ＷＷＷサーバー３１１上で動作し、マスターアプリケーション３００の要求に応じて、管理対象デバイス１２０に対する情報の設定、及び、取得を行う。
全体制御部３１２は、スレーブアプリケーション３１０の全体を制御し、マスターアプリケーション３００から通知されたタスクの処理を必要に応じてＷＥＢサービス制御部３１３、ＳＮＭＰマネージャー３１４に振り分ける。
ＷＥＢサービス制御部３１３は、マスターアプリケーション３００からの要求を受け、管理対象デバイス１２０とＸＭＬ形式で各種の情報を送受信する。更に、ＷＥＢサービス制御部３１３は、マスターアプリケーション３００へのタスクの実行結果の通知やＤＢ情報の通知等を行う。
ＳＮＭＰマネージャー３１４は、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）プロトコルを利用して管理対象デバイス１２０に対する探索処理や監視処理、及び、管理情報の取得設定を行う。
データベース部３１５は、マスターアプリケーション３００から要求されたタスクの情報やその実行結果、更には、スレーブアプリケーション３１０自身に対して設定された制御情報等をＨＤ２１０等に格納し、管理する。データベース部３１５が管理しているこれらの情報もＤＢ情報という。
【００１５】
更に、複合機能デバイス１２５では、ＷＥＢサービス制御部３２０、及び、ＳＮＭＰエージェント３２１が稼働している。
ＷＥＢサービス制御部３２０は、管理対象デバイス１２０においてスレーブアプリケーション３１０と各種情報をＸＭＬ形式で通信する。
ＳＮＭＰエージェント３２１は、内包するＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）の情報を参照して、ＳＮＭＰマネージャー３１４から送信されたＳＮＭＰのリクエストに応答を返す。
【００１６】
図４は、メインサーバー１０２において稼働するマスターアプリケーション３００において各種のタスクを生成する際の手順を示すフローチャートである。
Ｓ４００では、全体制御部３０２は、ユーザーによる、画面等を介したタスクの操作対象となるターゲットデバイスの選択操作に応じて、ターゲットデバイスを選択し、Ｓ４０１に移行する。
Ｓ４０１では、全体制御部３０２は、ユーザーによる、画面等を介したタスクの処理内容の設定操作に応じて、処理内容を設定し、Ｓ４０２に移行する。Ｓ４０１で設定される値は、例えば、デバイス管理部３０３において生成されるタスクの場合、デバイスのユーザーフレンドリ名称、設置場所情報、又は、ＩＰアドレス等ネットワーク関連の情報である。一方、Ｓ４０１で設定される値は、例えば、デバイス監視部３０４において生成されるタスクの場合、「紙詰まり」や「カバーオープン」等、監視する障害の種別である。更には、Ｓ４０１で設定される値は、例えば、デバイス探索部３０５において生成されるタスクの場合、ＳＮＭＰによる探索であれば、「ユニキャスト」や「ブロードキャスト」といった種別の選択や「コミュニティ名」等である。
Ｓ４０２では、全体制御部３０２は、Ｓ４０１で登録した処理内容を実行するスケジュールの設定を行い、Ｓ４０３に移行する。Ｓ４０２において設定する実行スケジュールとしては、例えば、即時実行や指定した時刻での実行、また、指定した間隔による周期実行等がある。
【００１７】
Ｓ４０３では、全体制御部３０２は、Ｓ４００で選択したターゲットデバイス、Ｓ４０１で設定した処理内容、及び、Ｓ４０２で設定した実行スケジュールをタスクとして、データベース部３０９を介してメインサーバー１０２のＨＤ２１０等に格納、登録する。そして、全体制御部３０２は、Ｓ４０４に移行する。メインサーバー１０２のデータベース部３０９、又はメインサーバー１０２のＨＤ２１０は、第１記憶部、第４記憶部の一例である。Ｓ４００で選択したターゲットデバイスは、処理対象の一例である。タスク、又は後述するタスクの実行要求は、処理要求の一例である。
Ｓ４０４では、全体制御部３０２は、タイマーによりＳ４０２において設定したスケジュールの管理が行い、設定した時刻にＳ４０５に移行する。
Ｓ４０５では、スレーブ制御部３０７は、Ｓ４００で選択されたターゲットデバイスを管理対象とするスレーブサーバーの選択を行い、選択したスレーブサーバー（ｌ台）に対してタスクの実行要求を送信して、Ｓ４０６に移行する。
Ｓ４０６では、全体制御部３０２は、後述の図５のフローチャートでタスクの実行結果を通知してきたスレーブサーバーをカウントするためのインデックスｉを０に初期化して、図４に示すフローチャートの処理を終了する。
【００１８】
図５は、メインサーバー１０２において稼働するマスターアプリケーション３００において各種の情報を受信する際の動作を示すフローチャートである。
Ｓ５００では、全体制御部３０２は、ＷＷＷサーバー３０１、及び、ＷＥＢサービス制御部３０８を介して情報の受信を行い、Ｓ５０１に移行する。
Ｓ５０１では、全体制御部３０２は、Ｓ５００で受信した情報がＳ４０５で送信したタスクの実行要求に対する実行結果であるかどうかの判定を行う。全体制御部３０２は、Ｓ５０１においてタスクの実行結果であると判定した場合にはＳ５０２に移行し、それ以外の場合にはＳ５０６に移行する。
Ｓ５０２では、全体制御部３０２は、ｉ台目のスレーブサーバーから受信したタスクの実行結果を、データベース部３０９を介してメインサーバー１０２のＨＤ２１０等に格納し、Ｓ５０３に移行する。
Ｓ５０３では、全体制御部３０２は、インデックスｉをインクリメントしてＳ５０４に移行する。
【００１９】
Ｓ５０４では、全体制御部３０２は、インデックスｉがＳ４０５においてタスクの実行要求を送信したスレーブサーバーの総数ｌより小さいかどうかの判定を行う。全体制御部３０２は、Ｓ５０４においてインデックスｉがタスクの実行要求を送信したスレーブサーバーの総数ｌより大きい場合には、Ｓ５０５に移行し、それ以外の場合には図５に示すフローチャートの処理を終了する。
Ｓ５０５では、スレーブ制御部３０７は、Ｓ４０５で実行を要求したタスクの処理が全て完了したことを検知してタスク全体の結果を、データベース部３０９を介してメインサーバー１０２のＨＤ２１０等に格納し、Ｓ５０６に移行する。
Ｓ５０６では、全体制御部３０２は、インデックスｉを０に初期化して処理を終了する。
Ｓ５０７では、全体制御部３０２は、Ｓ５００で受信した情報がサブサーバー１０３からのＤＢ情報要求であるかどうかの判定を行う。全体制御部３０２は、Ｓ５０７において、受信した情報がＤＢ情報要求であると判定した場合にはＳ５０８に移行し、それ以外の場合には図５に示すフローチャートの処理を終了する。ＤＢ情報要求は、取得要求の一例である。
Ｓ５０８では、全体制御部３０２は、バックアップ制御部３０６及びデータベース部３０９を介してメインサーバー１０２のＨＤ２１０等に格納し、管理している情報をサブサーバー１０３に通知して、図５に示すフローチャートの処理を終了する。
【００２０】
図６は、サブサーバー１０３においてメインサーバー１０２の障害を検知した際の動作を示すフローチャートである。本フローチャートの説明において参照する機能モジュールは特に断りのない限りサブサーバー１０３上で稼働するマスターアプリケーション３００を構成する機能モジュールである。
Ｓ６００では、全体制御部３０２は、メインサーバー１０２に対してＤＢ情報要求を送信するためのポーリングタイマをセットし、Ｓ６０１に移行する。ポーリングタイマは、設定された時間間隔の一例である。
Ｓ６０１では、全体制御部３０２は、Ｓ６００でセットしたポーリングタイマがタイムアウトしたかどうかの判定を行う。全体制御部３０２は、Ｓ６０１においてタイムアウトが発生したと判定した場合にはＳ６０２に移行し、それ以外の場合にはＳ６０１に戻る。
Ｓ６０２では、全体制御部３０２は、メインサーバー１０２に対してＤＢ情報要求を送信し、Ｓ６０３に移行する。
Ｓ６０３では、全体制御部３０２は、Ｓ６０２でメインサーバー１０２に送信したＤＢ情報要求の応答としてメインサーバー１０２からＤＢ情報が受信できかたどうかの判定を行う。全体制御部３０２は、Ｓ６０３において、ＤＢ情報が受信できたと判定した場合にはＳ６０４に移行し、それ以外の場合には、Ｓ６０５に移行する。
Ｓ６０４では、全体制御部３０２は、受信したＤＢ情報を、データベース部３０９を介してサブサーバー１０３のＨＤ２１０等に保存してＳ６００に戻る。サブサーバー１０３のデータベース部３０９、又はサブサーバー１０３のＨＤ２１０は、第２記憶部、第６記憶部の一例である。
【００２１】
Ｓ６０５では、全体制御部３０２は、メインサーバー１０２がダウンしたと判定してＳ６０６に移行する。
Ｓ６０６では、全体制御部３０２は、Ｓ６０７でＤＢ情報を要求するスレーブサーバーからの応答をカウントするためのインデックスｊを０に初期化してＳ６０７に移行する。
Ｓ６０７では、全体制御部３０２は、管理対象となっているｍ台のスレーブサーバーに対してＤＢ情報を要求してＳ６０８に移行する。
Ｓ６０８では、全体制御部３０２は、Ｓ６０７でサブサーバー１０３からスレーブサーバーに対して送信したＤＢ情報に対するｊ番目のスレーブサーバーからのＤＢ情報を受信してＳ６０９に移行する。
Ｓ６０９では、全体制御部３０２は、Ｓ６０８で受信したｊ番目のスレーブサーバーのＤＢ情報を、データベース部３０９を介してサブサーバー１０３のＨＤ２１０等に保存してＳ６１０に移行する。
Ｓ６１０では、全体制御部３０２は、インデックスｊをインクリメントしてＳ６１１に移行する。
Ｓ６１１では、全体制御部３０２は、インデックスｊがスレーブ制御部３０７において管理対象となっているスレーブサーバーの総数ｍより小さいかどうかの判定を行う。全体制御部３０２は、Ｓ６１１においてインデックスｊがスレーブサーバーの総数ｍより小さい場合には、Ｓ６０８に戻り、それ以外の場合にはＳ６１２に移行する。
【００２２】
Ｓ６１２では、全体制御部３０２は、Ｓ６０４において最後に保存したメインサーバー１０２のＤＢ情報とＳ６０９において保存したｍ台のスレーブサーバーのＤＢ情報とを比較してＳ６１３に移行する。
Ｓ６１３では、全体制御部３０２は、Ｓ６１２の比較の結果、スレーブサーバーにおいてタスクの処理が完了しているにも関わらず、メインサーバー１０２のＤＢ情報に実行結果が登録されていないタスクがあるかどうの判定を行う。全体制御部３０２は、Ｓ６１３において実行結果が登録されていないタスクの情報があると判定した場合にはＳ６１４に移行し、それ以外の場合にはＳ６１５に移行する。
Ｓ６１４では、全体制御部３０２は、Ｓ６１３においてメインサーバー１０２のＤＢ情報に実行結果が登録されていないタスクの情報があると判定した場合にスレーブサーバーのＤＢ情報を参照してタスクの実行結果を補完し、Ｓ６１５に移行する。即ち、全体制御部３０２は、Ｓ６１３においてメインサーバー１０２のＤＢ情報に実行結果が登録されていないタスクの情報がある場合、スレーブサーバーのＤＢ情報に基づき、登録されていないタスクの情報をメインサーバー１０２のＤＢ情報に追加する。メインサーバー１０２のＤＢ情報、又はメインサーバー１０２のデータベース部３０９を介してメインサーバー１０２のＨＤ２１０等に記憶されている情報は、登録情報の一例である。
Ｓ６１５では、全体制御部３０２は、Ｓ６１２の比較の結果、メインサーバー１０２において登録済であるが、スレーブサーバーに対して実行要求が送信されていないタスクの情報があるかどうかの判定を行う。全体制御部３０２は、Ｓ６１５において未実行のタスクの情報があると判定した場合にはＳ６１６に移行し、それ以外の場合には図６に示すフローチャートの処理を終了する。
Ｓ６１６では、全体制御部３０２は、後述の図７のフローチャートでタスクの実行結果を通知してきたスレーブサーバーをカウントするためのインデックスｋを０に初期化してＳ６１７に移行する。
Ｓ６１７では、全体制御部３０２は、スレーブ制御部３０７において管理している情報を参照し、未実行のタスクのターゲットデバイスを管理しているスレーブサーバー（ｎ台）に対してタスクの実行要求を送信する。そして、全体制御部３０２は、図６に示すフローチャートの処理を終了する。
【００２３】
図７は、サブサーバー１０３がメインサーバー１０２に代わってスレーブサーバーに要求したタスクの実行結果を受信する際の動作を示すフローチャートである。
本フローチャートの説明において参照する機能モジュールは特に断りのない限りサブサーバー１０３上で稼働するマスターアプリケーション３００を構成する機能モジュールである。
Ｓ７００では、全体制御部３０２は、ＷＷＷサーバー３０１、及び、ＷＥＢサービス制御部３０８を介して情報の受信を行い、Ｓ７０１に移行する。
Ｓ７０１では、全体制御部３０２は、Ｓ７００で受信した情報がＳ６１７で送信したタスクの実行要求に対する実行結果であるかどうかの判定を行う。全体制御部３０２は、Ｓ７０１においてタスクの実行結果であると判定した場合にはＳ７０２に移行し、それ以外の場合には図７に示すフローチャートの処理を終了する。
Ｓ７０２では、全体制御部３０２は、ｋ台目のスレーブサーバーから受信したタスクの実行結果を、データベース部３０９を介してサブサーバー１０３のＨＤ２１０等に格納し、Ｓ７０３に移行する。
Ｓ７０３では、全体制御部３０２は、インデックスｋをインクリメントしてＳ７０４に移行する。
【００２４】
Ｓ７０４では、全体制御部３０２は、インデックスｋがＳ６１７においてタスクの実行要求を送信したスレーブサーバーの総数ｎより小さいかどうかの判定を行う。全体制御部３０２は、Ｓ７０４においてインデックスｋがタスクの実行要求を送信したスレーブサーバーの総数ｎより大きい場合には、Ｓ７０５に移行し、それ以外の場合には図７に示すフローチャートの処理を終了する。
Ｓ７０５では、スレーブ制御部３０７は、Ｓ６１７で実行を要求したタスクの処理が全て完了したことを検知してタスク全体の結果を、データベース部３０９を介してサブサーバー１０３のＨＤ２１０等に格納し、Ｓ７０６に移行する。
Ｓ７０６では、全体制御部３０２は、インデックスｋを０に初期化して図７に示すフローチャートの処理を終了する。
【００２５】
図８は、スレーブサーバーがマスターシステム１００からの要求を受けて処理を実行する際の動作を示すフローチャートである。
Ｓ８００では、全体制御部３１２は、ＷＷＷサーバー３１１、及び、ＷＥＢサービス制御部３１３を介して情報の受信を行い、Ｓ８０１に移行する。
Ｓ８０１では、全体制御部３１２は、Ｓ８００で受信した情報がタスクの実行要求であるかどうかの判定を行う。全体制御部３１２は、Ｓ８０１において、Ｓ８００において受信した情報がタスクの実行要求であると判定した場合にはＳ８０２に移行し、それ以外の場合にはＳ８０８に移行する。
Ｓ８０２では、全体制御部３１２は、情報の送信元をタスクの実行結果の通知先としてデータベース部３１５を介してスレーブサーバーのＨＤ２１０等に保存し、Ｓ８０３に移行する。本実施形態ではタスクの実行結果の通知先としてメインサーバー１０２、又は、サブサーバー１０３の何れかを想定している。
Ｓ８０３では、全体制御部３１２は、タスクの内容に応じてＷＥＢサービス制御部３１３、又は、ＳＮＭＰマネージャー３１４を介してタスクの処理を実行し、Ｓ８０４に移行する。
Ｓ８０４では、全体制御部３１２は、管理対象デバイス１２０からＳ８０３において実行した処理の結果を受信してＳ８０６に移行する。
Ｓ８０５では、全体制御部３１２は、受信した実行結果を、データベース部３１５を介してスレーブサーバーのＨＤ２１０等に保存する。スレーブサーバーのデータベース部３１５、又はスレーブサーバーのＨＤ２１０は、第３記憶部、第５記憶部の一例である。スレーブサーバーは、少なくとも前記設定された時間間隔（ポーリングタイマ）よりも長い時間、データベース部３１５を介してスレーブサーバーのＨＤ２１０等に記憶されている情報を管理する。
Ｓ８０６では、全体制御部３１２は、Ｓ８０３においてタスクの実行を要求した全ての管理対象デバイス１２０から実行結果が受信できたかどうかの判定を行う。全体制御部３１２は、Ｓ８０６において全ての管理対象デバイス１２０から実行結果が受信できたと判定した場合にはＳ８０７に移行し、それ以外の場合にはＳ８０４に戻る。
Ｓ８０７では、全体制御部３１２は、Ｓ８０２において保存した通知先にＳ８０５で保存したタスクの実行結果を通知して、図８に示すフローチャートの処理を終了する。
【００２６】
Ｓ８０８では、全体制御部３１２は、Ｓ８００において受信した情報がＤＢ情報の要求であるかどうかの判定を行う。全体制御部３１２は、Ｓ８０８において、Ｓ８００で受信した情報がＤＢ情報の要求であると判定した場合にＳ８０９に移行し、それ以外の場合には図８に示すフローチャートの処理を終了する。本実施形態においては、Ｓ８００で受信した情報がＤＢ情報の要求であると判定したことにより、スレーブサーバーがメインサーバーのダウンを検知できるものとする。
Ｓ８０９では、全体制御部３１２は、サブサーバー１０３に対してデータベース部３１５がスレーブサーバーのＨＤ２１０等に保存し、管理しているＤＢ情報を通知してＳ８１０に移行する。
Ｓ８１０では、全体制御部３１２は、Ｓ８０２において保存したタスクの実行結果の通知先をサブサーバー１０３に変更し、図８に示すフローチャートの処理を終了する。
【００２７】
図９は、ネットワークデバイス管理システムにおいてメインサーバー１０２が障害によりダウンした際の動作の一例を示すシーケンス図である。
ＳＱ９００では、メインサーバー１０２は、図４のＳ４００からＳ４０３までに示す手順でタスクの登録を行う。ここで生成されるタスクの種類に特に制限はなく、デバイス管理、デバイス監視、デバイス探索の何れのタスクであってもよい。
ＳＱ９０１では、メインサーバー１０２は、図４のＳ４０５に示す手順でスレーブシステム１１０に対してタスクの実行要求を送信する。
ＳＱ９０２では、スレーブシステム１１０は、図８のＳ８０３に示す手順で管理対象デバイス１２０に対してタスクとして指定された処理を実行する。
ＳＱ９０３では、管理対象デバイス１２０は、図８のＳ８０４に示す手順で、ＳＱ９０２への応答としてスレーブシステム１１０にタスクの処理の実行結果を通知する。
ＳＱ９０４では、スレーブシステム１１０は、ＳＱ９０３の処理結果を受けて、図８のＳ８０７、及び、図５のＳ５００に示す手順で、メインサーバー１０２に対してタスクの実行結果を通知する。
ＳＱ９０５では、サブサーバー１０３は、図６のＳ６０２に示す手順で、メインサーバー１０２に対してＤＢ情報要求を送信する。
ＳＱ９０６では、メインサーバー１０２は、ＳＱ９０５のＤＢ情報要求を受けて図５のＳ５０８に示す手順で、サブサーバー１０３に対してＤＢ情報を通知する。
ＳＱ９０７では、メインサーバー１０２は、ＳＱ９００と同様の手順でタスクの登録を行う。
ＳＱ９０８では、メインサーバー１０２は、ＳＱ９０１と同様の手順でタスクの実行要求を送信する。
ＳＱ９０９では、スレーブシステム１１０は、ＳＱ９０２と同様の手順で管理対象デバイス１２０に対してタスクとして指定された処理を実行する。
【００２８】
ＳＱ９１０では、メインサーバー１０２は、何らかの障害により停止する。この障害によってメインサーバー１０２は、ＤＢ情報要求に対する応答が通知できない状態となったこととする。
ＳＱ９１１では、サブサーバー１０３は、ＳＱ９０５と同様の手順で、メインサーバー１０２に対してＤＢ情報要求が送信される。
ＳＱ９１２では、サブサーバー１０３は、ＳＱ９１１のＤＢ情報要求の応答が受信できないことから図６のＳ６０５の手順でメインサーバー１０２のダウンを検知する。
ＳＱ９１３では、サブサーバー１０３は、図６のＳ６０７の手順でスレーブシステム１１０に対してＤＢ情報の要求を行う。
ＳＱ９１４では、スレーブシステム１１０は、ＳＱ９１３への応答として、図８のＳ８０９の手順でサブサーバー１０３に対してＤＢ情報を通知する。
ＳＱ９１５では、スレーブシステム１１０は、図８のＳ８１０の手順で情報の通知先をサブサーバー１０３に変更する。
ＳＱ９１６では、管理対象デバイス１２０は、ＳＱ９０３と同様の手順で、ＳＱ９０９への応答としてスレーブシステム１１０に実行結果を通知する。ＳＱ９０９における処理の要求は、ＳＱ９１０のサーバーダウン以前にメインサーバー１０２から要求されたタスクである。
ＳＱ９１７では、スレーブシステム１１０は、ＳＱ９１５において情報の通知先をサブサーバー１０３に変更したことから、ＳＱ９０８でメインサーバー１０２から要求されたタスクの実行結果をサブサーバー１０３に通知する。
【００２９】
図１０は、スレーブシステム１１０からマスターシステム１００に通知される情報のデータ構造の一例を示す図である。
実行結果１０００は、ＳＱ９０４やＳＱ９１７でマスターシステム１００に通知されるタスクの実行結果の一例である。
タスク識別子１００１は、タスクを一意に識別するためのタスク識別子である。タスク識別子１００１は、ＳＱ９０１やＳＱ９０８でマスターシステム１００から通知されるタスクの実行要求において指定される。マスターシステム１００では、タスク識別子１００１によって受信した実行結果が何れのタスクの実行結果を識別することができる。
タスク実行結果１００２は、タスク全体としての実行結果である。本実施形態においてはタスクの実行結果の定義はタスクの種別によって異なるものとする。
したがって、例えば複合機能デバイスに対する処理が全て成功した場合のみ本タスクのタスク実行結果１００２を成功とみしてもよい。また、各複合機能デバイスに対する処理の結果に関わらず全ての複合機能デバイスから応答を受信した場合に処理を成功と見なしてもよい。
タスク実行結果１００３は、複合機能デバイス毎のタスクの実行結果である。
【００３０】
ＤＢ情報１０１０は、ＳＱ９１４でスレーブシステム１１０からマスターシステム１００に通知されるＤＢ情報の一例である。
環境設定情報１０１１は、スレーブシステム１１０の各スレーブサーバーに設定される環境設定情報である。本実施形態の環境設定情報としては、例えば、スレーブサーバーのシステム名称や管理対象デバイスに関する情報、更には、参照するデータベースに関する情報等を想定している。
トータルタスク数１０１２は、トータルタスク数であり、ＤＢ情報１０１０に含まれるタスクの総数である。
タスクの識別子１０１３は、タスクの識別子であり、タスク識別子１００１と同様の情報である。
タスク処理情報１０１４は、タスク処理情報であり、ＳＱ９０１やＳＱ９０８でスレーブシステム１１０に通知されるタスク実行要求によって指定される処理の内容である。
タスク状態情報１０１５は、タスクの状態情報であり、具体的には「未実行」、「実行中」、「完了」、「停止中」等タスクの現在の状況に関する情報である。
タスク実行結果１０１６は、タスク全体としての実行結果であり、タスク実行結果１００２と同様の情報ある。
タスク実行結果１０１７は、複合機能デバイス毎のタスクの実行結果であり、タスク実行結果１００３と同様の情報である。
タスク識別子１０１８は、タスク識別子であり、タスク識別子１００１、１０１３と同様の情報である。
タスク処理情報１０１９は、タスクの処理情報であり、タスク処理情報１０１４と同様の情報である。
タスク状態情報１０２０は、タスクの状態情報であり、タスク状態情報１０１５と同様の情報である。本実施形態においては、タスク状態情報１０２０は「実行中」を示しているため、タスク識別子１０１８によって示されるタスクに関する複合機能デバイス毎の実行結果は含まれないものとする。
【００３１】
以上、説明したように本実施形態においては、サブサーバー１０３が稼働状況の確認を兼ねて定期的にメインサーバー１０２のＤＢ情報を取得し、メインサーバー１０２がダウンしたときにはスレーブシステム１１０からＤＢ情報を取得する。更に、サブサーバー１０３が双方から取得したＤＢ情報を比較し補完することで管理情報の欠損を最小限におさえるだけでなく、メインサーバー１０２の障害発生以前にスレーブシステムに要求した処理についても継続して実行することができる。
【００３２】
＜実施形態２＞
実施形態１では、サブサーバー１０３がメインサーバー１０２のＤＢ情報を取得する方法、更には、メインサーバー１０２ダウン時にスレーブシステム１１０からＤＢ情報を取得する方法について説明した。本実施形態では更に、スレーブシステムにおいてＤＢ情報を効率的に管理する方法について説明する。
本実施形態におけるネットワークデバイス管理システムのシステム構成及びハードウェア構成・ソフトウェア構成・データ構成、メインサーバー１０２のダウン時のシーケンスについては、実施形態１で説明した内容と同様である。したがって、本実施形態においては、図１〜図１０の説明を省略する。
【００３３】
図１１は、本実施形態によるスレーブシステム１１０においてＤＢ情報を管理する際の動作を示すフローチャートである。本フローチャートの説明において参照する機能モジュールは特に断りのない限りサブサーバー１０３上で稼働するマスターアプリケーション３００を構成する機能モジュールである。
Ｓ１１００では、全体制御部３０２は、スレーブシステム１１０に対してメインサーバー１０２に対するＤＢ情報要求のポーリング間隔ｔを通知し、Ｓ１１０１に移行する。
Ｓ１１０１では、全体制御部３０２は、イベントの発生を検知し、Ｓ１１０２に移行する。本ステップにおけるイベントとしては、例えば、マスターシステム１００からのタスクの実行要求や設定変更、更には、管理対象デバイス１２０からのタスクの実行結果通知等がある。
Ｓ１１０２では、全体制御部３０２は、Ｓ１１０２において発生したイベントによってデータベース部３１５を介した書込み処理が発生するかどうかの判定を行う。全体制御部３０２は、Ｓ１１０２において、データベース部３１５を介した書込みを伴うイベントであると判定した場合にはＳ１１０３に移行し、それ以外の場合には図１１に示すフローチャートの処理を終了する。
Ｓ１１０３では、全体制御部３０２は、既存データの書込み時刻をチェックして、Ｓ１１０４に移行する。
Ｓ１１０４では、全体制御部３０２は、Ｓ１１０３における既存データのけ着込み時刻のチェックにおいて、現在時刻からポーリング間隔ｔを減じた時刻以前に書き込まれた情報の有無をチェックする。全体制御部３０２は、Ｓ１１０４において、現在時刻からポーリング間隔ｔを減じた時刻以前に書き込まれた情報が存在する場合には、Ｓ１１０５に移行し、それ以外の場合には図１１に示すフローチャートの処理を終了する。
Ｓ１１０５では、全体制御部３０２は、Ｓ１１０４において検出された現在時刻からポーリング間隔ｔを減じた時刻以前に書き込まれた情報を、データベース部３０９を介してサブサーバー１０３のＨＤ２１０等から削除する。そして、全体制御部３０２は、図１１に示すフローチャートの処理を終了する。
【００３４】
以上、説明したように本実施形態において、ネットワークデバイス管理システムにおけるスレーブシステム１１０は、サブサーバー１０３からメインサーバーへのＤＢ情報要求のポーリング間隔を意識してデータを保持している。これによって、メインサーバー１０２が何らかの障害によりダウンした場合にサブサーバー１０３から要求されるＤＢ情報に関して、重複するＤＢ情報の通知を行わないようにすることができ、最小限のＤＢ情報のみを通知することができる。
【００３５】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給する。そして、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００３６】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではない。上述した実施形態では、管理対象のネットワークデバイスを複合機能デバイスとしているが、管理対象としては複合機能デバイスに限定されるものではない。ネットワークデバイスとしては、通信機能を有するプリンタ、ＦＡＸ、ＰＣ、携帯端末装置等であってもよい。また、上述したサーバーのハードウェア構成は一例であり、複数のＣＰＵ、ＤＩＳＰ、ＮＩＣ等を有していてもよい。またサーバーのソフトウェア構成は一例であり、ソフトウェア構成の一部又は全てをハードウェア構成でサーバーに実装してもよい。また、上述した実施形態では、ＤＢ情報を各サーバーのＨＤに保存するものとして説明を行ったがこれに限定されるものではない。例えば、各サーバーは、ＤＢ情報をローカルの他のメモリ（自身のサーバーの他のメモリ）、又はリモートのメモリ（ネットワーク等で各サーバーと接続された別装置のメモリ）に保存し、管理するようにしてもよい。
【００３７】
以上、上述した各実施形態の情報処理によれば、マスター・スレーブ構成のネットワークデバイス管理システムにおいて管理作業中にマスターシステムで障害が発生した場合であっても管理データの欠損を最小限に抑えることができる。
これにより大規模なネットワーク環境を管理するマスター・スレーブ構成のネットワークデバイス管理システムを安定的に稼働させることができる。
よって、管理作業中にメインサーバー１０２で障害が発生した場合であっても管理対象の情報の欠損を可能な限り抑えることができる。
【符号の説明】
【００３８】
１０２  メインサーバー
１０３  サブサーバー
２００  ＣＰＵ
【図１】
2017138923.tif 000003
【図２】
2017138923.tif 000004
【図３】
2017138923.tif 000005
【図４】
2017138923.tif 000006
【図５】
2017138923.tif 000007
【図６】
2017138923.tif 000008
【図７】
2017138923.tif 000009
【図８】
2017138923.tif 000010
【図９】
2017138923.tif 000011
【図１０】
2017138923.tif 000012
【図１１】
2017138923.tif 000013