(57)【要約】【課題】業務運用管理システムでのシステム構成や環境構築を遠隔地にある別のシステムにマッピングし、元のシステムに障害が発生した場合に、元のシステムとはホスト名が異なるマシン上でも、業務定義を変更することなく自動的な運用継続を可能とし、迅速かつ容易に業務再開することを目的とする。【解決手段】マネージャーと複数のエージェントからなる業務運用管理システムと、障害発生時に業務運用管理システムの機能を代行する待機系業務運用管理システムから構成された業務復旧支援システムを構築する。実行系システムの各ホストと待機系システムの各ホストをマッピングさせ、実行系のホストで障害が発生した場合、待機系のマッピングされたホストで業務を代替実行する。実行系と待機系で構成変更が発生した場合には、待機系のホストの負荷が均一に分散されるようにマッピングを設定し構成管理情報を更新する。【選択図】図１
2007265333.tif 000002
【特許請求の範囲】
【請求項１】
マネージャーホストと、そのマネージャーホストに管理されている任意の数のエージェントホストとを備え、前記マネージャーホストからの要求に応じて前記エージェントホストが実際の業務の実行を行う業務運用管理システムにおいて、障害が発生した場合に、業務の復旧を支援する業務復旧支援システムであって、
前記業務運用管理システムが停止した場合に、代替運用を行う、マネージャーホストと、そのマネージャーホストに管理される任意の数のエージェントホストとを備えた待機系業務運用管理システムを設けるとともに、
前記業務運用管理システムのマネージャーホストおよびエージェントホストに障害が発生したとき、前記待機系業務運用管理システムのどのマネージャーホストおよびどのエージェントホストで業務代行を行うかをあらかじめ定義した構成管理テーブルを記憶する手段と、
前記業務運用管理システムでのマネージャーホストおよびエージェントホストの各ホスト名と、それらのホストを代替する前記待機系業務運用管理システムのホストを特定するIPアドレスとの対応関係を格納したホスト名解決テーブルを記憶する手段と、
前記業務運用管理システムのマネージャーホストが停止したことを検知したとき、前記構成管理テーブルから、前記停止したマネージャーホストの代替となる前記待機系業務運用管理システムのマネージャーホストを割り当て、業務を継続させる手段と、
前記業務運用管理システムのエージェントホストが停止したことを検知したとき、前記ホスト名解決テーブルから、前記停止したエージェントホストの代替となる前記待機系業務運用管理システムのエージェントホストを割り当て、業務を継続させる手段と
を備えたことを特徴とする業務復旧支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子計算機での業務運用における、システム障害時の業務復旧を遠隔地で迅速に行うことを可能にする業務復旧支援システムに関する。
【背景技術】
【０００２】
電子計算機を使用した業務運用管理システムでは、様々な要因によるシステムの障害が発生する危険性がある。このため、企業の基幹業務で運用中のシステムについて、障害発生時の対応システムの構築が実施されてきている。
【０００３】
近年では、重要データのバックアップだけでなく、冗長構成を持つ（クラスタ）システムによる障害時の対応システムが構築されてきている。また、広域災害に対しても遠隔地でのディスクミラーリングやデータレプリケーションにより、拠点全体が破壊された場合でも、別拠点でシステムを再構築し業務を再開できるようになってきている。
【０００４】
下記特許文献１に記載のものは、冗長構成を持つコンピューターシステムにおいて、システム障害自動復旧処理を、障害監視装置を用いて統合的に管理し、発生した障害の種別により、その復旧動作を自動的に実施可能とすることで、システム保守のための工数を削減するものである。
【０００５】
また、遠隔地へのデータの複製を行う遠隔データ・シャドーイング・システムの方法として、例えば、下記特許文献２に記載のものが知られている。
【特許文献１】特開2003−114811号公報
【特許文献２】特開平7−244597号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、これまでの技術は、遠隔地に必要データを転送したり退避したりすることは、設定により自動的にできるものの、障害時にシステム構成を再構築して障害復旧を図ることについては、迅速かつ容易に実行できるとは言い難い。システム構成の再構築のためには、元のシステムと同じシステム構成を準備しておく必要がある、または人手による元のシステムと同様の業務が実行できる環境の再構築が必要である、などの事情があるためである。
【０００７】
上記特許文献２で示される技術は、遠隔地にデータを転送しておく技術であり、そのままでは遠隔地でのシステム再開が可能とはならない。また、上記特許文献１で示される技術は、システムの部品については、障害の種別に応じて自動的に復旧できるものの、コンピューターのOSについては、冗長構成（クラスタ）システムを前提としているため、遠隔地のまったく異なる別コンピューターでの業務復旧には対応できない。例えば、マネージャー、エージェント構成で業務運用管理を行っている場合は、業務の定義情報中に、業務を実行するエージェントマシン情報を持っているため、別システム上で同一の業務を実行させるには、業務定義中で指定してあるホスト名（コンピューター名）で動作が可能でなければならない。このためには、元のシステムとまったく同じマシン環境を準備しておく必要がある。または、別システムで業務を再開させるときに、各業務が問題なく動作できるよう、マシン間の通信設定情報を変更するか、別システムで動作可能なように、すべての業務定義を変更しなければならない。
【０００８】
本発明は、業務運用管理システムでのシステム構成や環境構築を、例えば遠隔地にある別のシステムにマッピングし、元のシステムに障害が発生した場合に、元のシステムとはホスト名（コンピューター名）が異なるマシン上でも、業務定義を変更することなく、自動的な運用継続を可能とするとともに、迅速かつ容易に業務再開できるような技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明では、マネージャーホストと、そのマネージャーホストに管理されている任意の数のエージェントホストとを備え、前記マネージャーホストからの要求に応じて前記エージェントホストが実際の業務の実行を行う業務運用管理システムにおいて、障害が発生し、前記業務運用管理システムが停止した場合に、代替運用を行う、マネージャーホストと、そのマネージャーホストに管理される任意の数のエージェントホストとを備えた待機系業務運用管理システムを設ける。そして、前記業務運用管理システムのマネージャーホストおよびエージェントホストに障害が発生したとき、前記待機系業務運用管理システムのどのマネージャーホストおよびどのエージェントホストで業務代行を行うかをあらかじめ定義した構成管理テーブルを用意しておくとともに、前記業務運用管理システムでのマネージャーホストおよびエージェントホストの各ホスト名と、それらのホストを代替する前記待機系業務運用管理システムのホストを特定するIPアドレスとの対応関係を格納したホスト名解決テーブルを用意する。前記業務運用管理システムのマネージャーホストが停止したことを検知したとき、前記構成管理テーブルから、前記停止したマネージャーホストの代替となる前記待機系業務運用管理システムのマネージャーホストを割り当て、業務を継続させる。また、前記業務運用管理システムのエージェントホストが停止したことを検知したとき、前記ホスト名解決テーブルから、前記停止したエージェントホストの代替となる前記待機系業務運用管理システムのエージェントホストを割り当て、業務を継続させる。
【００１０】
前記業務運用管理システムのマネージャーホストで、新たなエージェントホストが追加されたときには、自動的に構成管理情報を更新し、前記待機系業務運用管理システムに通知を行い、前記待機系業務運用管理システムのマネージャーでは、前記業務運用管理システムに追加されたエージェントが停止した場合に、前記業務運用管理システムでの業務を、前記待機系業務運用管理システムの各エージェントに、負荷を自動分散して、代替実行させるように構成定義設定を行うようにするとよい。また、前記待機系業務運用管理システムのマネージャーホストで、新たなエージェントホストが追加されたときに、自動的に構成管理情報を更新し、既存のエージェントホストのうち、最も多くのエージェントホストの代替実行が定義されているホストを検索し、新たに追加したエージェントホストに負荷を自動分散させるように構成定義設定を行うようにするとよい。
【発明の効果】
【００１１】
本発明によれば、業務運用管理システムでのシステム構成や環境構築を、自動的に、例えば遠隔地にある別のシステムにマッピングし、元のシステムとはホスト名（コンピューター名）が異なるマシン上でも、ホスト名などの構成情報の変更や業務定義を変更することなく、自動的な運用継続を可能とし、大規模な障害が発生した場合でも、迅速かつ容易に業務再開できる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明を実施する場合の一形態を図面を参照して具体的に説明する。
【００１３】
図１は、本発明の一実施形態のシステムの概略構成を表すブロック図である。この実施形態の遠隔地での業務復旧支援システムは、実行系システム1と待機系システム2で構成されている。実行系システム1は、拠点3と拠点4からなる。拠点3には、業務の定義情報を持ち業務実行をコントロールするマネージャー6と、マネージャー6からの要求により実際の業務を実行するエージェント7および8が設けられている。拠点4には、マネージャー6からの要求により実際の業務を実行するエージェント9が設けられている。待機系システム2は、拠点5からなる。拠点5には、実行系システム1のマネージャー6に障害が発生した場合に業務を引き継いで管理するマネージャー10と、実行系システム1のエージェント7、8、または9に障害が発生した場合に業務を引き継いで実行するエージェント11および12が設けられている。それぞれの拠点間は、ネットワーク13（例えばWAN（Wide Area Network））で接続されている。これらのマネージャーおよびエージェントは、それぞれ、１台のマシンと考えてよい。
【００１４】
図２は、実行系システムと待機系システムとのマッピング構成を示すブロック図である。マッピングとは、実行系の各マシンに障害が発生したときに、待機系のどのマシンが業務を引き継ぐのかを関連づけた定義のことを指す。図２の例では、実行系システムのマネージャー21（図１の6）と待機系システムのマネージャー25（図１の10）とがマッピングされている。マネージャー21が障害により停止した場合には、マネージャー25が引き継いで業務を継続する。同様に、エージェント22（図１の7）とエージェント24（図１の9）がエージェント26（図１の11）と、エージェント23（図１の8）がエージェント27（図１の12）と、それぞれマッピングされている。それぞれのエージェントの何れかが障害により停止すると、マネージャーは、待機系システムのエージェントに業務の実行を要求する。エージェント26は、実行系の複数のエージェント22，24とマッピングされている。エージェント22とエージェント24の両方とも停止した場合には、２つのエージェント分の業務をエージェント26で実行する。
【００１５】
図３は、図２のマッピング構成を管理する構成管理テーブルの構成図である。本構成管理テーブルにより、実行系システムでのホスト名31と、該実行系システムでのホストにマッピングされている待機系システムのホスト名32と、該待機系システムのホストのIPアドレス33とを定義する。また、それぞれのホストがマネージャーなのかエージェントなのかを示す種別34と、マネージャーの場合における待機系の起動モード35を定義する。この構成管理テーブルは、予め管理者により作成され、実行系および待機系それぞれのマネージャー21，25上に格納されている。構成管理テーブルのデータ更新は、管理者の指示に基づいて、実行系マネージャー21にて実施される。実行系マネージャー21内の構成管理テーブルが更新されると、その更新データが待機系マネージャー25に転送され、該待機系マネージャー内の構成管理テーブルも同様に更新される。
【００１６】
待機系への業務切り替えが発生した場合、本構成管理テーブルのデータを読み込み、起動モードが「自動」の場合、待機系で業務運用管理システムを起動した後、待機系に転送されている業務データを元に、自動的に業務を再開する。起動モードが「手動」の場合、待機系で業務運用管理システムを起動した後、業務は、中断状態となる。この場合、業務の実行状況を業務データ中の実行ログ等で確認し、手動で、業務を再開する。業務切り替えの処理手順については、後に詳しく説明する。
【００１７】
図４は、実行系と待機系の業務データの転送を表すブロック図である。実行系システム41（例えば図１の1）のマネージャー43（図１の6）には、業務定義データ、業務実行状態データ、業務実行結果データ、および構成管理データなどを格納したデータベース45が接続されている。データベース45に更新が発生すると、データベースソフトウェアのレプリケーション機能により、データベース45中のデータが待機系システム42（図１の2）のマネージャー44（図１の10）に接続されているデータベース46に反映される。これにより、業務運用中には、実行系システム41内のデータベース45と同じデータが、待機系システム42内のデータベース46に保持されることになる。
【００１８】
図５は、ホスト名解決のためのデータテーブルであるホスト名解決テーブルの構成図である。実行系システムでのホスト名51とそれぞれのIPアドレス52、現在そのホストが使用中かどうかを示すフラグを格納するフラグ領域53（図５の例では、0が使用中、1が未使用を示すものとする）、および、IPアドレスの優先度54が格納されている。実行系システムが正常に運用されている状態では、ホスト名51が当該正常に運用されている実行系システムのホスト名であるレコードのうち、IPアドレス52が当該正常に運用されている実行系システムのホストのIPアドレスであるレコードのフラグ領域53が0（使用中）になっており、それ以外の同一ホスト名のレコードについては、IPアドレス52が待機系システムのホスト（上記実行系システムのホストにマッピングされているもの）のIPアドレスとなり、フラグ領域53は1（未使用）となっている。マネージャーとエージェント間の通信処理では、このホスト名解決テーブルの情報に従ってアドレス解決が行われる。マネージャーでは、ジョブの定義情報に設定されている実行先エージェントのアドレスを解決するときに、ホスト名51が実行先エージェントで、かつフラグ領域53が0（使用中）のレコードを入力する。このレコードに設定されているIPアドレス52を使用し、通信を行う。エージェントへの通信処理では、マネージャーのホスト名とIPアドレスをエージェントに連絡する。このときも、ホスト名解決テーブルの情報を参照する。IPアドレス52が自ホストと同じで、かつフラグ領域53が0（使用中）のレコードを入力する。このレコードに設定されているホスト名51とIPアドレス52をエージェントに連絡する。エージェントからマネージャーへの通信は、このホスト名とIPアドレスを使用し、通信を行う。
【００１９】
例えば、図５のホスト名解決テーブルの先頭レコード（実行系システムが正常に運用されている状態であるとする）は、ホスト名51が「マネージャー21」、IPアドレス52が「1.0.0.1」、フラグ領域53が「0」、優先度54が「1」であるが、これは現在正常に運用されている実行系システムのホストを示している。次のレコードは、ホスト名51が「マネージャー21」、IPアドレス52が「2.0.0.1」、フラグ領域53が「1」、優先度54が「2」であるが、これは上記IPアドレス52が「1.0.0.1」の実行系のホストにマッピングされており、該実行系のホストに障害が発生したときに該「マネージャー21」を引き継ぐ待機系のホストを示すレコードである。実行系のホストで障害が発生した場合、「マネージャー21」のレコードを入力し、実行系のホストのレコードのフラグ領域53を1（未使用）に変更し、待機系のホストのレコードのフラグ領域53を0（使用中）に変更する。その後の通信処理では、待機系のホストのレコードが使用中となるため、ホスト名「マネージャー21」のIPアドレスは、待機系のホストである「2.0.0.1」が使用されるようになる。
【００２０】
優先度54は、障害が発生して待機系のホストに引き継ぐ際の優先度（数値が低い程優先度が高いとする）を示す。実行系システムのホストに障害が発生すると、そのホストと同じホスト名51を持つ待機系システムのIPアドレス52のうち、優先度54が最も高いIPアドレス52を取得し、該IPアドレスの待機系ホストで上記障害が発生した実行系システムのホストを引き継ぐ。このとき、業務を引き継いだ待機系システムのホストを示すレコードのフラグ領域54は1（未使用）から0（使用中）に更新する。
【００２１】
図６は、実行系システムのマネージャーが停止した場合の、待機系マネージャーにおける復旧処理の概要を示すフローチャートである。
【００２２】
待機系のマネージャーは、定期的に実行系マネージャー（図２で説明したように、当該待機系マネージャーとマッピングされている実行系マネージャー）と通信を行い、実行系マネージャーが稼働中かどうかをチェックする。実行系マネージャーが稼働中であれば終了し、停止していた場合は次のステップに進む（ステップ601）。実行系マネージャーが停止していた場合、待機系マネージャーは、図３で説明した構成管理テーブルを読み込む（ステップ602）。図５のホスト名解決テーブルのマネージャーホスト名と同じホスト名51のレコードを入力し、実行系ホストのレコードのフラグ領域53を1（未使用）にし、待機系ホストのレコードのフラグ領域53を0（使用中）にする。これ以降、通信処理でマネージャーから通知されるマネージャーホストのIPアドレスは、待機系ホストのIPアドレスとなる（ステップ603）。読み込んだ構成管理テーブル中の実行ホスト名31が当該停止したマネージャーであるレコードの起動モード35が自動起動か手動起動かをチェックする（ステップ604）。自動起動の場合、当該待機系マネージャーで業務システムを起動し業務を再開する（ステップ611）。
【００２３】
ステップ604で手動起動の場合は、図３の構成管理テーブルの実行系ホスト名31に登録されている実行系システムの各エージェントのうちの先頭のエージェントを最初の処理対象のエージェントとして、ステップ605に進む。図５に示したホスト名解決テーブルを参照し、処理対象のエージェントのホスト名と同じホスト名51を持つレコードのうち、優先度54が最も高い（値が小さいもの）レコードを最初の対象レコードとする（ステップ605）。次に、対象レコードのIPアドレス52で特定されるエージェントが停止中か稼働中かをチェックする（ステップ606）。停止中であれば、当該対象レコードのフラグ領域53を1（未使用）とし（ステップ607）、図５のホスト名解決テーブルの当該対象レコードの次の優先度を持つレコード（処理対象のエージェントのホスト名と同じホスト名51を持つもの）を探索する（ステップ608）。あればそのレコードを新たに対象レコードとして、ステップ606に戻る（ステップ609）。ステップ609で次の優先度を持つレコードが無ければ、上記処理対象のエージェントを実現する稼働中のホストが無かったということであるから、エラーログを出力し（ステップ610）、処理を終了する。
【００２４】
ステップ606で対象レコードのIPアドレス52で特定されるエージェントが稼働中であれば、対象レコードのフラグ領域53を0（使用中）とする。以降の通信時にマネージャーがジョブ実行先エージェントのホスト名からIPアドレスを解決する場合、このレコードが参照され、ジョブの実行先が待機系のエージェントに切り替わる（ステップ612）。図３の構成管理テーブルの実行系ホスト名31に登録されている各エージェントの中から、未だ処理していない実行系のエージェントがあるか否か判定する（ステップ613）。未処理のエージェントがあれば、そのエージェントを新たな処理対象のエージェントとして、ステップ605に戻る。未処理のエージェントが無ければ、図３の構成管理テーブルの実行系ホスト名31に登録されている全エージェントについて処理を終えたということであるから、待機モードで業務システムを起動する（ステップ611）。
【００２５】
待機モードでの業務システムの起動とは、業務の実行を抑止しつつシステム起動して待機する処理である。なお、自動起動の場合はステップ604からステップ611に進むが、この場合は自動モードで業務システムの起動を行いすぐに業務を再開する。また、図５のホスト名解決テーブル中のマネージャーのレコードのフラグ領域53については、停止した実行系マネージャーのフラグ領域53を1（未使用）とし、業務を引き継いだ待機系マネージャーのフラグ領域53を0（使用中）とする処理を行う必要があるが、この処理はステップ611のシステム起動処理の中で行うものとする。
【００２６】
以上のように、マネージャーの復旧処理では、自動起動の場合は、すぐに業務システムを起動して業務を再開し、手動起動の場合は、各エージェントの状態を確認し、構成を変更して業務システムを起動し、業務再開待機状態にする。
【００２７】
自動起動の場合の各エージェントの稼動／停止確認、および構成の変更は、実際に業務が再開し、該当するエージェントに対して、業務の実行要求が行われるときに、手動起動の場合と同様の処理（ステップ604〜610，612，613）が行われる。
【００２８】
図７は、実行系システムのエージェントが停止した場合の復旧処理の概要を示すフローチャートである。本処理は、マネージャーからエージェントに対して業務の実行要求を行った場合に、当該エージェントが停止だったとき、当該マネージャーにおいて起動される。
【００２９】
まず、図５に示したホスト名解決テーブルから、IPアドレス52が当該停止したエージェントのIPアドレスに一致するレコードを探索する（ステップ701）。探索された当該停止エージェントのレコードのフラグ領域53を1（未使用）とする（ステップ702）。次に、図５のホスト名解決テーブルから、ホスト名51が上記停止したエージェントと同一で、優先度54が上記停止したエージェントの次に高いレコードを探索する（ステップ703）。優先度が次に高いレコードが無い場合は、停止したエージェントを引き継ぐ待機系エージェントが無いということであるから、エラーログを出力し、処理を終了する（ステップ704、708）。次の優先度のレコードがあれば、そのレコードのIPアドレス52で特定されるエージェントが稼働中かどうかチェックし（ステップ705）、稼働中であれば、そのレコードのフラグ領域53を0（使用中）にする。以降の通信時にマネージャーがジョブ実行先エージェントのホスト名からIPアドレスを解決する場合、このレコードが参照され、ジョブの実行先が待機系のエージェントに切り替わる（ステップ706）。業務実行要求を当該IPアドレスのエージェントに送る（ステップ707）。エージェントが停止中の場合は（ステップ705）、ステップ702に戻る。
【００３０】
以上のように、エージェント復旧処理では、エージェントが停止していた場合、マッピングされている稼働中の他のエージェント（優先度が高いものから順に割当てる）で業務を実行する。エージェントからマネージャーに対しての業務実行結果の通知についても、同様な処理が行われ、マッピングされている稼働中の他のマネージャーに通知を行う。
【００３１】
図８は、実行系システムにエージェントが追加された場合の構成変更処理の概要を示すフローチャートである。
【００３２】
実行系マネージャーでは、新たにエージェントを追加し（ステップ801）、図３の構成管理テーブルに実行系のホスト名31だけを格納したレコードを追加する（ステップ802）。図４で説明したように、実行系マネージャーにおいて構成管理テーブルに追加・変更があると、その旨が待機系マネージャーに通知される。待機系マネージャーでは、自機内に保持している図３の構成管理テーブルに同様にして前記レコード追加を行うとともに、図１０に示すエージェント一覧テーブルから、カレントフラグ104がONのデータを読み込む（ステップ803）。
【００３３】
ここで図１０のエージェント一覧テーブルについて説明する。エージェント一覧テーブルは、待機系マネージャーで保持しているテーブルである。エージェント一覧テーブルは、エージェントID101、エージェントホスト名102、IPアドレス103、カレントフラグ104、およびマッピングエージェント数105を持つ。エージェントID101は、ここでは通し番号である。エージェントホスト名102は、待機系ホスト名を記載する。IPアドレス103は、対応するエージェントホスト名102のホストのIPアドレスである。カレントフラグ104は、次に割り当てる待機系エージェントを示している。すなわち、マッピングする待機系エージェントが必要になったときには、カレントフラグ104がONのエージェントを使用する。エージェント一覧テーブルに登録されているエージェントの中で、カレントフラグ104がONのものは１つだけで、残りのエージェントのカレントフラグ104はOFFである。カレントフラグ104がONのエージェントを待機系エージェントとして割り当てたときには、そのエージェントのカレントフラグ104をOFFとし、エージェントID101が次の番号のエージェントのカレントフラグ104がONとされる。エージェント一覧テーブルの最後のエージェントの次は、エージェントID101が１の先頭エージェントに戻る。マッピングエージェント数105は、当該エージェントを待機系としてマッピングしている実行系エージェントの数を示す。
【００３４】
再び図８に戻って、ステップ803の後、待機系マネージャーでは、カレントフラグ104がONのエージェントのホスト名102とIPアドレス103を上記実行系マネージャーに通知し（ステップ804）、当該カレントフラグ104をOFFにし、次のIDのレコードのカレントフラグ104をONにする（ステップ805）。実行系マネージャーでは、ステップ804で通知されたエージェント情報（ホスト名とIPアドレス）を元に、図３の構成管理テーブルと図５のホスト名解決テーブルを更新する（ステップ806）。ここで更新された情報は、図４で示すように、待機系マネージャーに反映される。
【００３５】
以上のように、新しいエージェントが追加されると、待機系のエージェントとのマッピングが自動的に行われ、データベースに反映される。本構成変更機能は、設定により、手動でのみ実施するようにすることが可能である。
【００３６】
図９は、待機系システムにエージェントが追加された場合の構成変更処理の概要を示すフローチャートである。
【００３７】
待機系マネージャーでは、新たにエージェントを追加し（ステップ901）、図１０のエージェント一覧テーブルにレコードを追加する（ステップ902）。エージェント一覧テーブルから、マッピングエージェント数105が最大のレコードを入力し、その値を１カウントダウンし、ステップ902で追加したレコードのマッピングエージェント数105を１にする（ステップ903）。次に、図３の構成管理テーブルから、ステップ903でマッピングエージェント数をカウントダウンしたエージェント名のレコードを読み込み、データの変更を実行系マネージャーに通知する（ステップ904、905）。
【００３８】
実行系マネージャーでは、通知されたエージェント情報を元に、構成管理テーブルのマッピングするエージェントを更新し、ホスト名解決テーブルの該当するIPアドレスを更新する（ステップ906）。
【００３９】
以上のように、待機系で新しいエージェントが追加されると、実行系エージェントとのマッピングが更新され、複数のエージェントがマッピングされている待機系エージェントに対して、エージェントの分散が自動的に行われる。本構成変更機能は、設定により、手動でのみ実施するようにすることが可能である。
【００４０】
なお、上記実施形態では、待機系システムのマネージャーで、実行系システムのマネージャーの停止を検出し図６の処理を行うようにしているが、マネージャーの停止を検出する機能やシステムを起動する機能などを備えた別の装置でこれらの処理を行ってもよい。図７の処理も同様である。
【図面の簡単な説明】
【００４１】
【図１】本発明の一実施形態の構成を表すブロック図
【図２】実行系システムと待機系システムのマッピング構成を示すブロック図
【図３】マッピング構成を管理するデータ構成図
【図４】実行系と待機系の業務データの転送を表すブロック図
【図５】ホスト名解決のためのデータ構成図
【図６】実行系システムのマネージャーが停止した場合の復旧処理の概要を示すフローチャート
【図７】実行系システムのエージェントが停止した場合の復旧処理の概要を示すフローチャート
【図８】実行系システムにエージェントが追加された場合の構成変更処理の概要を示すフローチャート
【図９】待機系システムにエージェントが追加された場合の構成変更処理の概要を示すフローチャート
【図１０】エージェント一覧を管理するデータ構成図
【符号の説明】
【００４２】
1…実行系システム、2…待機系システム、3、4、5…拠点、6…実行系システムのマネージャー、7、8、9…実行系システムのエージェント、10…待機系システムのマネージャー、11、12…待機系システムのエージェント、13…公衆回線網、21…実行系システムのマネージャー、22、23、24…実行系システムのエージェント、25…待機系システムのマネージャー、26、27…待機系システムのエージェント、31…実行系ホスト名、32…待機系ホスト名、33…待機系IPアドレス、34…種別、35…起動モード、41…実行系システム、42…待機系システム、43…実行系システムのマネージャー、44…待機系システムのマネージャー、45…実行系システムの業務運用管理システムDB、46…待機系システムの業務運用管理システムDB、51…ホスト名、52…IPアドレス、53…フラグ領域、54…優先度、101…エージェントID、102…エージェントホスト名、103…IPアドレス、104…カレントフラグ、105…マッピングエージェント数。
【図１】
2007265333.tif 000003
【図２】
2007265333.tif 000004
【図３】
2007265333.tif 000005
【図４】
2007265333.tif 000006
【図５】
2007265333.tif 000007
【図６】
2007265333.tif 000008
【図７】
2007265333.tif 000009
【図８】
2007265333.tif 000010
【図９】
2007265333.tif 000011
【図１０】
2007265333.tif 000012