(57)【特許請求の範囲】
【請求項１】
複数の共有資源と、前記共有資源を使用可能であり、２以上のグループに分類される複数のノードと、を含み、前記各グループは、１つの管理ノードと、該管理ノード以外の少なくとも１つのメンバノードとから構成された資源管理システムであって、
前記各グループごとに、前記各共有資源の識別情報、前記各共有資源の自グループ内における使用情報、および前記各共有資源を所有するノードを示す所有ノード情報を含む資源管理テーブルを備える、資源管理システム。
【請求項２】
前記資源管理テーブルは、前記各グループの管理ノードが備える、請求項１に記載の資源管理システム。
【請求項３】
前記各グループ内の前記メンバノードは、該メンバノード自身が使用する前記共有資源の共有資源情報を有し、
前記各グループ内の少なくとも１の前記メンバノードは、
自グループ内の前記管理ノードがダウンした場合、他グループ内の前記管理ノードから前記識別情報および前記使用情報と、前記自グループ内の前記メンバノードから前記共有資源情報とを収集する収集手段と、
前記収集した前記識別情報、前記使用情報、および前記共有資源情報に基づいて、前記自グループの資源管理テーブルを作成する作成手段と、を備える請求項２に記載の資源管理システム。
【請求項４】
前記各管理ノードは、
自グループ内の前記メンバノードがダウンした場合、前記資源管理テーブルを参照し、前記ダウンしたメンバノードが使用していた共有資源の使用停止情報を他グループの前記管理ノードに通知する第１通知手段と、
他グループの前記管理ノードから前記使用停止情報が通知された場合、前記資源管理テーブルを参照し、自グループ内で前記使用停止の対象となる共有資源を使用するメンバノードが存在するか否かを判定する判定手段と、
前記判定した結果、前記使用停止の対象となる共有資源を使用するメンバノードが存在する場合、該メンバノードに対して前記使用停止情報を通知する第２通知手段と、を備える請求項１〜３に記載の資源管理システム。
【請求項５】
前記各管理ノードは、
他グループの前記資源管理テーブルの参照を必要とする場合、前記他グループの前記資源管理テーブルを取得する取得手段を備える、請求項１〜４のいずれか１項に記載の資源管理システム。
【請求項６】
前記資源管理テーブルは、前記グループごとに、自グループのノードと他グループのノードとを相互に通信する通信装置が備え、
前記各管理ノードは、
前記他グループの前記通信装置がダウンした場合、動作中の他グループの前記通信装置から前記識別情報および前記使用情報を収集する収集手段と、
前記収集した結果に基づいて、前記ダウンした通信装置が管理する共有資源を特定する特定手段と、
自グループ内で前記特定された前記共有資源を使用するメンバノードが存在するか否かを判定する判定手段と、
前記判定した結果、前記特定された前記共有資源を使用するメンバノードが存在する場合、該メンバノードに対して使用停止情報を通知する通知手段と、を備える、請求項１に記載の資源管理システム。
【請求項７】
複数の共有資源と、前記共有資源を使用可能であり、２以上のグループに分類される複数のノードと、を含み、前記各グループは、１つの管理ノードと、該管理ノード以外の少なくとも１つのメンバノードとから構成された資源管理システムにおける資源管理方法であって、
前記各グループの管理ノードは、前記複数の共有資源の識別情報と、前記各共有資源の自グループ内における使用情報、および前記各共有資源を所有するノードを示す所有ノード情報を含む資源管理テーブルを備えており、
前記管理ノードがダウンした場合、
前記ダウンした管理ノードが属する自グループ内の１のメンバノードは、他グループ内の前記管理ノードから前記識別情報および前記使用情報と、前記自グループ内の前記メンバノードから共有資源情報とを収集する収集段階と、
前記収集した前記識別情報、前記使用情報、および前記共有資源情報に基づいて、資源管理テーブルを作成する作成段階と、
を有する資源管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、資源管理システムおよび資源管理方法に関する。
【背景技術】
【０００２】
複数のノードを含んで構成されるネットワークシステムにおいて、ノード間で共有可能な資源（リソース）を融通し合うシステムが実現されている（たとえば、特許文献１参照）。
【０００３】
特許文献１に記載のシステムは、ネットワークに接続された複数台のノード（サーバ）をグループで束ね、グループ内のノード間で資源（メモリリソース）を融通し合い、また、グループ内で融通可能な資源が無い場合、他のグループの資源を使用する仕組みである。また、資源の管理は、それぞれグループ内の代表ノード（管理サーバ）が資源管理テーブルを用いることにより行われている。代表ノード以外のノードとしては、代表のノードに対して資源の割り当て要求をし、資源を使用（所有）する所有ノード、および、所有ノードが所有する資源を共有して使用する共有ノードが存在する。
【０００４】
ここで、上記ネットワークシステムにおいて、たとえば、資源が割り当てられた所有ノードが障害でダウンした場合、そのダウンした旨の情報をその資源を共有して使用する共有ノードに対して通知し、その資源の使用を停止する必要がある。また、代表ノードが障害でダウンした場合、資源の管理情報そのものが失われ、このままではシステムとして運用継続ができないため、資源管理テーブルを再構築する必要がある。これら所有ノード、または代表ノードがダウンした場合の処理を、図１に示すシステムを例にとって、以下、具体的に説明する。
【０００５】
図１に示すシステムは、１つのネットワークスイッチと、該ネットワークスイッチに接続された５つのノード（ノード０〜ノード４）を含んで構成される。ネットワークスイッチは、接続される全ノードから、等価にアクセス可能な４個のレジスタからなる共有レジスタ（共有資源）を有する。共有レジスタは、個々のレジスタが複数のノードで同時に使用(共有)することができ、ノード０を資源管理者（代表ノード）とすれば、ノード０が有する資源管理テーブル（共有レジスタ管理テーブル）によって使用状況が管理される。図１の例では、レジスタ０は、ノード１に所有され、かつ、ノード２〜ノード４に共有されており、また、レジスタ３は、ノード４に所有され、かつ、ノード３に共有されている状態を示す。なお、レジスタ１とレジスタ２は、未使用状態を示す。
【０００６】
まず、一般的な共有レジスタの管理について、たとえば、ノード４が共有レジスタを必要とし、ノード４にレジスタ３が割り当てられ、ノード３がノード４に割り当てられたレジスタ３を共有して使用する場合を例にとって説明する。
【０００７】
ノード４は、まず、資源管理者であるノード０に対して「資源割り当て」の要求情報を通知する。ノード０は、ノード４より「資源割り当て」の要求情報を受けると、資源管理テーブルを参照して、未使用資源のレジスタを探索する。探索した結果、未使用資源のレジスタ（ここでは、レジスタ３）があった場合、ノード０は、そのレジスタ番号（資源番号）の情報をノード４に通知する。この際、資源管理テーブルは、資源番号３の所有ノードとして「ノード４」の情報を設定する。一方、ノード４は、資源番号の情報を受けると、保有資源番号として「レジスタ３」の情報を保持し、割り当てられたレジスタ３を使用することができる。
【０００８】
また、ノード３がノード４の所有する資源（レジスタ３）を共有して使用する場合、ノード３は、まず、ノード４に対して「共有許可」の要求情報を通知する。ノード４は、ノード３から「共有許可」の要求情報を受けてレジスタ３の共有を許可する場合、そのレジスタ番号の情報をノード３に通知する。この際、ノード４は、共有ノード（共有者）であるノード３を管理するために、保有資源番号の共有ノードとして「ノード３」の情報を設定する。一方、ノード３は、共有許可された資源番号の情報を受けると、共有資源番号として「レジスタ３」の情報を保持し、共有許可されたレジスタ３を使用することができる。
【０００９】
ノード４は、レジスタ３の使用を終了するとき、まず、共有ノードに対してレジスタ３の「使用停止」の要求情報を通知する。ノード３は、「使用停止」の要求情報を受けると、共有資源番号として保持された「レジスタ３」の情報を削除し、ノード４に対して削除処理が終了した旨を返答する。ノード４は、全共有ノードから使用停止の要求に対する返答を受け取った後、保有資源番号として保持された「レジスタ３」の情報を削除し、資源管理者であるノード０に対して、レジスタ３の所有を解放する「資源解放」の要求情報を通知する。
【００１０】
ノード０は、「資源解放」の要求情報を受けると、資源管理テーブルを参照して、対応する資源番号３の所有ノードとしての「ノード４」の情報を削除して、資源開放処理を終了する。
【００１１】
上述したシステムにおいて、資源を所有する所有ノードが障害でダウンした場合、たとえば、レジスタ３の資源を所有しているノード４が障害等でダウンした場合は、レジスタ３の解放ができない状態となる。この状態を解消するため、ノード４のダウン発生が検知されると、資源管理者であるノード０は、資源管理テーブルに、所有ノードとして「ノード４」の情報が設定されているか否かを判定する。所有ノードに「ノード４」の情報が設定されていると判定した場合、ノード４によるレジスタ３の解放は不可能であるため、ノード０が代わりにレジスタ３の資源の解放処理を実施する。
【００１２】
資源の解放処理は、まず、ダウンしたノード４が所有していたレジスタ３の資源番号を使用している全共有ノードに、資源の「使用停止」の要求情報を通知する必要がある。しかしながら、資源管理者であるノード０は、資源の所有ノードの情報のみを管理しており、資源の共有ノードの情報については管理していない。よって、共有ノードを特定することができず、資源の「使用停止」の要求情報をシステムに接続された全ノードに対してブロードキャストによって通知する必要がある。そして、ノード０は、全てのノードに「使用停止」の要求情報を通知し、該通知に対する返答を各ノードから全て受け取った後、資源管理テーブルにおいて、レジスタ３の資源番号３の所有ノードとして「ノード４」の設定を削除し、ダウンしたノード４が所有していたレジスタ３を解放する。
【００１３】
一方、上述したシステムにおいて、資源管理テーブルを有する代表ノード、たとえば、ノード０が障害等でダウンした場合は、このままではシステムとして運用継続はできないため、資源管理テーブルを復旧させる必要がある。資源管理テーブルを復旧させる方法として、システムを再起動する方法がある。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００６−１８７１７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１５】
上述したシステムでは、所有ノードがダウンした場合、どのノードがどの資源を共有しているか不明となり、資源の「使用停止」の要求情報の通知先が不明となってしまう。よって、該要求情報をシステム内の全ノードにブロードキャストすることによって通知し、かつ、各ノードからの返答を全て受信する必要がある。こうした一連の処理によってシステム全体で処理される情報量は増加し、システム負荷が非常に高くなってしまうという問題点があった。
【００１６】
また、上述したシステムにおいて、資源管理テーブルを有する代表ノードがダウンした場合、資源管理テーブルを復旧させる方法として、システムを再起動する方法が挙げられるが、この方法は、１つのノードのダウンのために、システム全体の処理を停止させなければならず、各種運用の継続性の観点から大きな問題となる。そこで、システム全体の停止を回避するため、定期的もしくは所定のタイミングで、資源管理テーブルのバックアップをとる方法も考えられる。しかしながら、バックアップをとる方法であっても、障害時において、バックアップされた資源管理テーブルに基づいて、現在との整合性を確保するためにシステム内の全ノードに対してブロードキャストを行う必要は依然として存在しており、システム負荷が非常に高くなってしまうという問題点を有している。
【００１７】
したがって、本発明は、上記問題点を解決し、ネットワークシステムを構成するノードがダウンした場合でも、復旧の際、システム全体で処理される情報量を制限し、システム負荷を軽減することができる新しい資源管理システムおよび資源管理方法を提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明の資源管理システムは、複数の共有資源と、前記共有資源を使用可能であり、２以上のグループに分類される複数のノードと、を含み、前記各グループは、１つの管理ノードと、該管理ノード以外の少なくとも１つのメンバノードとから構成された資源管理システムであって、前記各グループごとに、前記各共有資源の識別情報、前記各共有資源の自グループ内における使用情報、および前記各共有資源を所有するノードを示す所有ノード情報を含む資源管理テーブルを備える。
【００１９】
さらに、本発明の資源管理方法は、複数の共有資源と、前記共有資源を使用可能であり、２以上のグループに分類される複数のノードと、を含み、前記各グループは、１つの管理ノードと、該管理ノード以外の少なくとも１つのメンバノードとから構成された資源管理システムにおける資源管理方法であって、前記各グループの管理ノードは、前記複数の共有資源の識別情報と、前記各共有資源の自グループ内における使用情報、および前記各共有資源を所有するノードを示す所有ノード情報を含む資源管理テーブルを備ており、前記管理ノードがダウンした場合、前記ダウンした管理ノードが属する自グループ内の１のメンバノードは、他グループ内の前記管理ノードから前記識別情報および前記使用情報と、前記自グループ内の前記メンバノードから前記共有資源情報とを収集する収集段階と、前記収集した前記識別情報、前記使用情報、および前記共有資源情報に基づいて、資源管理テーブルを作成する作成段階と、を有する。
【発明の効果】
【００２０】
以上のように構成された本発明によれば、ネットワークシステムを構成するノードがダウンした場合でも、復旧の際、システム全体で処理される情報量を制限し、システム負荷を軽減することができる。
【図面の簡単な説明】
【００２１】
【図１】従来の資源管理システムの概略構成の一例を示す図である。
【図２】第１実施形態の資源管理システム１の概略構成の一例を示す図である。
【図３】本実施形態の代表ノード１０等のハードウェア構成を示す概略図である。
【図４】本実施形態の代表ノード、所有ノード、および共有ノードの関係を示す図である。
【図５】本実施形態の資源管理テーブルの一例を示す図である。
【図６】第１実施形態の資源管理方法を説明するための図である。
【図７】第１実施形態の資源管理方法を説明するための図である。
【図８】第１実施形態の資源管理方法を説明するための図である。
【図９】第１実施形態の資源管理方法を説明するための図である。
【図１０】第１実施形態の資源管理方法を説明するための図である。
【図１１】第１実施形態の資源管理方法を説明するための図である。
【図１２】第１実施形態の資源管理方法を説明するための図である。
【図１３】第１実施形態の資源管理方法を説明するための図である。
【図１４】第１実施形態の資源管理方法を説明するための図である。
【図１５】第１実施形態の資源管理方法を説明するための図である。
【図１６】第１実施形態の資源管理方法を説明するための図である。
【図１７】第１実施形態の資源管理方法を説明するための図である。
【図１８】第１実施形態の資源管理方法を説明するための図である。
【図１９】第２実施形態の資源管理システム２の概略構成の一例を示す図である。
【図２０】第２実施形態の資源管理方法を説明するための図である。
【図２１】第３実施形態の資源管理システム２の概略構成の一例を示す図である。
【発明を実施するための形態】
【００２２】
以下、本発明を実施するための好適な各実施形態を、図面を参照しながら説明する。
【００２３】
＜第１実施形態＞
図２は、本発明の第１実施形態の資源管理システム１の概略構成の一例を示す図である。
【００２４】
本実施形態の資源管理システム１は、図２に示すとおり、共有資源Ａと、１つの代表ノードと２つのメンバノードから構成されるグループ１〜３とを含んで構成され、共有資源Ａとグループ１〜３の各ノードとはネットワークを介して接続される。グループ１は、１つの代表ノード１０と２つのメンバノード１１，１２を含み、グループ２は、１つの代表ノード２０と２つのメンバノード２１，２２を含み、グループ３は、１つの代表ノード３０と２つのメンバノード３１，３２を含む。
【００２５】
ここで、各グループ１〜３を構成する代表ノード１０，２０，３０、およびメンバノード１１，１２，２１，２２，３１，３２は、ハードウェアとして、図３に示すように、たとえば、ＣＰＵ、ＣＰＵにバス結合されたＲＯＭ、ＲＡＭ、記憶部、入力部、表示部、および入出力インタフェースなど、通常のコンピュータ装置と同様のハードウェアを備える。これら各ノードは、物理的には、専用化したシステム、あるいは汎用の情報処理装置のいずれであってもよい。たとえば、一般的な構成の情報処理装置において、本発明の資源管理方法における各処理を規定したソフトウェアを起動することにより、資源管理システム１を実現することもできる。
【００２６】
共有資源Ａは、ネットワークを介して接続された複数のノードから使用されるコンピュータ資源であって、たとえば、共有レジスタなどのデバイスである。本実施形態の共有資源Ａは、４つの共有資源０〜３で構成され、各共有資源０〜３は、それぞれいずれかの代表ノード（管理ノード）で管理される。たとえば、あるシステム内に代表ノードが２つ（代表ノードａ，ｂ）、および共有資源Ａが２つ（共有資源Ａ−０，Ａ−１）あれば、共有資源Ａ−０は、代表ノードａによって管理され、共有資源Ａ−１は、代表ノードｂによって管理される。よって、各代表ノードが有する共有資源Ａに対する管理情報を収集することで、システム内の共有資源Ａの全体の管理状態を把握することができる。なお、本実施形態の共有資源Ａは、４つの共有資源０〜３を有する場合を例にとって説明するが、共有資源の数は、４つの場合に限られず、複数のノードから共有することができる資源であればよく、少なくとも１つ以上あればよい。
【００２７】
各グループを構成する代表ノード１０，２０，３０、およびメンバノード１１，１２，２１，２２，３１，３２は、それぞれ同様の機能および構成とすることができるので、以下、グループ１の代表ノード１０およびメンバノード１１、１２を用いてその機能および構成を説明する。
【００２８】
代表ノード１０は、共有資源０〜３のいずれかを管理する管理ノードであって、メンバノード１１，１２がダウンした場合に、メンバノード１１，１２からの「資源割り当て」の要求に応じて、自身が管理する共有資源の「割り当て／解放」を行うノードであって、ダウンしたメンバノードが使用する共有資源の使用停止を、他の代表ノード２０等に通知するノードである。
【００２９】
代表ノード１０は、図２に示すように、第１通知手段１０１、判定手段１０２、第２通知手段１０３、およびデータベース１０４を備える。なお、代表ノード１０において、メンバノード１１，１２からの「資源割り当て」の要求に応じて、自身が管理する共有資源の「割り当て／解放」を行うための手段は、原則として、上述したような従来の方法を用いることができるので、ここでの詳細な説明は省略する。
【００３０】
データベース１０４は、複数の共有資源０〜３の識別情報と、自グループ内の代表ノード１０およびメンバノード１１，１２の共有資源の使用情報と、共有資源０〜３を所有するノードを示す所有ノード情報とを有する資源管理テーブルを記憶する。なお、資源管理テーブルについては、後述する。
【００３１】
第１通知手段１０１は、自グループ１内のメンバノードがダウンした場合、資源管理テーブルを参照し、ダウンしたメンバノードが使用していた共有資源の「使用停止」の要求情報を他グループの代表ノード２０，３０に通知する。
【００３２】
判定手段１０２は、他グループ内のメンバノードがダウンした場合であって、他グループの代表ノード２０，３０から、「使用停止」の要求情報が通知された場合、資源管理テーブルを参照し、自グループ内で使用停止の対象となる共有資源を使用しているメンバノードが存在するか否かを判定する。また、判定手段１０２は、他グループ内の代表ノードがダウンした場合であって、他グループの代表ノードとして機能するメンバノードから、「使用停止」の要求情報が通知された場合も同様に判定する。
【００３３】
第２通知手段１０３は、他グループ内のメンバノードがダウンした場合であって、判定手段１０２が判定した結果、自グループ内で使用停止の対象となる共有資源を使用するメンバノードが存在する場合、該メンバノードに対して「使用停止」の要求情報を通知する。また、第２通知手段１０３は、他グループ内の代表ノードがダウンした場合も同様に通知する。
【００３４】
メンバノード１１，１２は、代表ノード１０に対して、共有資源の割り当て要求を行ない、共有資源が割り当てられた場合、所有ノードとなり、また、ある所有ノードが所有している共有資源の共有を申請し、共有が許可された場合、共有ノードとなる。図４に、上記の管理ノードとしての代表ノードと、メンバノードまたは共有ノードとしてのメンバノードとの関係を例示する。また、メンバノード１１，１２は、代表ノード１０がダウンした場合、資源管理テーブルを作成し、代表ノードとして機能する。なお、代表ノード１０において、メンバノード１１，１２からの「資源割り当て」の要求に応じて、自身が管理する共有資源の「割り当て／解放」を行うための手段は、原則として、上述したような従来の方法を用いることができるので、ここでの詳細な説明は省略する。
【００３５】
メンバノード１１，１２は、図２に示すように、収集手段１１１，１２１、作成手段１１２，１２２、第３通知手段１１３，１２３、およびメンバノード自身が使用する共有資源の情報（共有資源情報）を記憶するデータベース１１４，１２４を備える。
【００３６】
収集手段１１１，１２１は、自グループ内の代表ノード１０がダウンした場合、他グループ内の代表ノード２０，３０から共有資源の識別情報および使用情報を収集し、また、自グループ内のメンバノードから共有資源情報を収集する。
【００３７】
作成手段１１２，１２２は、収集した複数の共有資源の識別情報および使用情報と、共有資源情報とに基づいて、新たな資源管理テーブルを作成する。
【００３８】
第３通知手段１１３，１２３は、自グループ内の代表ノード１０がダウンした場合、他グループ内の代表ノード２０，３０に対して、そのダウンした代表ノード１０が管理していた共有資源の「使用停止」の要求情報を通知する。
【００３９】
データベース１１４，１２４は、共有資源情報を記憶する。共有資源情報は、メンバノード１１，１２が、共有資源０〜３のいずれかの所有者となった場合に、その所有対象の共有資源に応じた資源番号の情報である。
【００４０】
なお、代表ノード１０およびメンバノード１１，１２において、上述した各手段は、たとえば、主にＣＰＵがＲＯＭやＲＡＭに格納されるプログラムを実行し、各ハードウェアを制御することにより、実現することができ、また、データベース１０４，１１３，１２３は、ＲＡＭや記憶部を用いて実現することができる。
【００４１】
ここで、本実施形態の資源管理テーブルの一例を、図５に示す。資源管理テーブルは、資源番号、使用フラグ、オーナノード（所有ノード）の各情報から構成されるテーブルである。なお、資源番号は、複数ある共有資源を識別するために、各共有資源０〜３にそれぞれ割り当てられる一連の番号である識別情報を示し、使用フラグは、自グループ内の代表ノード１０およびメンバノード１１，１２において各共有資源０〜３を使用しているか否かの使用情報を示し、オーナノード（所有ノード）は、共有資源を所有するノードを示す所有ノード情報を示す。オーナノードに、番号が設定されている場合、その番号をもつノードが資源を所有している状態を示す。また、何も設定されていない場合（図中では、空欄の場合）、その資源管理テーブルを備える代表ノードが、対象となる共有資源を管理しているが、誰も所有していない状態を示す。さらに、対象となる共有資源の管理外のノードとして設定されている場合（図中では、斜線の場合）、その共有資源が他の代表ノードによって管理されている状態を示す。
【００４２】
すなわち、図５に示す資源管理テーブルの例では、資源番号０の共有資源は、使用フラグが「使」で、かつ、オーナノードが「１１」と設定されているので、この資源管理テーブルをもつ代表ノード１０が管理する共有資源であって、自グループ内のメンバノード１１が所有（使用）していることを示す。資源番号１の共有資源は、使用フラグが「未」で、かつ、オーナノードが「空欄」で何も設定されていないので、どのノードも所有していないことを示す。資源番号２の共有資源は、使用フラグが「使」で、かつ、オーナノードが「斜線」で管理外として設定されているので、この資源管理テーブルをもつ代表ノード１０が管理する共有資源ではないが、自グループ内のノードが使用していることを示す。資源番号３の共有資源は、使用フラグが「未」で、かつ、オーナノードが「斜線」で管理外として設定されているので、この資源管理テーブルをもつ代表ノード１０が管理する共有資源ではなく、自グループ内のノードが使用していないことを示す。
【００４３】
なお、図５に示した資源管理テーブルの各項目および設定情報は、上記のものに限定されるものではなく、実装する際に適切な数値に置換可能であるため、本実施形態では、その具体的な数値等について特定しない。
【００４４】
＜資源管理方法＞
以下、図６〜図１８を参照して、資源管理システム１において実施される本実施形態の資源管理方法を、正常時処理段階と、障害時復旧処理段階とに分けて説明する。なお、各図を参照して説明する下記の各処理は、処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。
【００４５】
［正常時処理段階］
図６は、正常時処理段階の資源管理システム１の初期状態を示す図である。図６に示すように、資源管理システム１は、代表ノード１０およびメンバノード１１，１２を含むグループ１と、代表ノード２０およびメンバノード２１，２２を含むグループ２と、代表ノード３０およびメンバノード３１，３２を含むグループ３と、各代表ノードの管理対象である４つの共有資源０〜３からなる共有資源Ａとで構成される。各共有資源０〜３は、それぞれ資源番号０〜３が割り当てられて各グループにより分散管理される。初期状態として、たとえば、共有資源０（資源番号０）と共有資源２（資源番号２）は代表ノード１０が管理し、共有資源１（資源番号１）は代表ノード２０が管理し、共有資源３（資源番号３）は代表ノード３０が管理するものとする。なお、それぞれの共有資源の使用状況は、図６の各資源管理テーブルに示された状況とする。
【００４６】
メンバノードが共有資源Ａの割り当てを要求する各処理、たとえば、グループ１内のメンバノード１２が代表ノード１０に共有資源Ａの割り当てを要求する各処理について、図６に示す状態を初期状態とし、図７を参照して説明する。なお、図７に示す例では、メンバノード１２が属する自グループ１内に未使用の共有資源２があるものとする。
【００４７】
まず、メンバノード１２は、自グループ内の共有資源を管理する代表ノード１０に対して共有資源Ａの割り当てを要求する（ステップＳ１０）。具体的には、メンバノード１２は、代表ノード１０に共有資源Ａの「資源割り当て」の要求情報を通知する。
【００４８】
次いで、代表ノード１０は、メンバノード１２から上記要求を受け取ると、自ノードの資源管理テーブルを参照し、どのメンバノードにも所有されていない未使用の共有資源Ａを探索する（ステップＳ１１）。すなわち、資源管理テーブルのうち、使用フラグが「未」であり、かつ、オーナノードが「空欄」である共有資源Ａを探索する。
【００４９】
次いで、代表ノード１０は、探索した結果、未使用の共有資源２の存在を確認すると、共有資源２をメンバノード１２に割り当てて所有者とするため、資源管理テーブルを更新する（ステップＳ１２）。たとえば、資源管理テーブルにおいて、使用フラグを「未」から「使」に、オーナノードを「空欄」からメンバノード１２を表す「１２」に設定する。
【００５０】
次いで、代表ノード１０は、メンバノード１２からの共通資源の割り当て要求に対して、資源番号２の情報をメンバノード１２に返却する（ステップＳ１３）。メンバノード１２は、取得した資源番号２の情報を自ノード内に保持する。
【００５１】
上記各処理が実施されることで、メンバノード１２は、共有資源２を所有する所有者となる。
【００５２】
次に、メンバノードが共有資源Ａの割り当てを要求したが、該要求したメンバノードの属する自グループ内に未使用の共有資源Ａが無い場合、たとえば、グループ２内のメンバノード２２が代表ノード２０に共有資源Ａの割り当てを要求した場合の各処理について、図６に示す状態を初期状態とし、図８および図９を参照して説明する。例として、グループ２内のメンバノード２２が代表ノード２０に共有資源Ａの割り当てを要求した場合を説明する。
【００５３】
まず、メンバノード２２は、自グループ２内の共有資源を管理する代表ノード２０に対して共有資源Ａの割り当てを要求する（ステップＳ２０）。具体的には、メンバノード２２は、代表ノード２０に共有資源Ａの「資源割り当て」の要求情報を通知する。
【００５４】
次いで、代表ノード２０は、メンバノード２２から上記要求を受け取ると、自ノードの資源管理テーブルを参照し、どのメンバノードにも所有されていない未使用の共有資源Ａを探索する（ステップＳ２１）。すなわち、資源管理テーブルのうち、使用フラグが「未」であり、かつ、オーナノードが「空欄」である共有資源Ａを探索する。
【００５５】
次いで、代表ノード２０は、探索した結果、未使用の共有資源が無い場合、図８に示すように、他の代表ノード１０に未使用の共有資源の管理権の譲渡を要求する（ステップＳ２２）。なお、共有資源の管理権の譲渡の要求先は、代表ノード１０または代表ノード３０のどちらを先にしてもよく、また、同時であってもよく、その要求する代表ノードの決定アルゴリズムは適宜変更することができる。
【００５６】
次いで、代表ノード１０は、代表ノード２０から上記要求を受け取ると、図９に示すように、自ノードの資源管理テーブルを参照し、どのメンバノードにも所有されていない未使用の共有資源Ａを探索する（ステップＳ２３）。具体的には、資源管理テーブルのうち、使用フラグが「未」であり、かつ、オーナノードが「空欄」である共有資源Ａを探索する。
【００５７】
次いで、代表ノード１０は、探索した結果、未使用の共有資源２の存在を確認すると、共有資源２の管理権を代表ノード２０に譲渡するために、自ノードの資源管理テーブルを更新する（ステップＳ２４）。たとえば、資源管理テーブルにおいて、該当する共有資源２が他のグループ２の代表ノード２０で管理されるため、資源番号２のオーナノードを「空欄」から「斜線」に設定して更新する。
【００５８】
次いで、代表ノード１０は、代表ノード２０に対して共有資源２の管理権を譲渡する（ステップＳ２５）。
【００５９】
次いで、代表ノード２０は、代表ノード１０からの共有資源２の管理権の譲渡を受け取ると、共有資源２をメンバノード２２に割り当てて所有者とするため、自ノードの資源管理テーブルを更新する（ステップＳ２６）。たとえば、資源管理テーブルにおいて、資源番号２の使用フラグを「未」から「使」に、オーナノードを「斜線」からメンバノード２２を表す「２２」に設定する。
【００６０】
次いで、代表ノード２０は、メンバノード２２からの共通資源の割り当て要求に対して、資源番号２の情報をメンバノード２２に返却する（ステップＳ２７）。メンバノード２２は、取得した資源番号２の情報を自ノード内に保持する。
【００６１】
上記各処理が実施されることで、メンバノード１２は、共有資源２を所有する所有者となる。
【００６２】
次に、メンバノードが、すでにあるメンバノードに所有されている共有資源を共有する場合の各処理、たとえば、グループ３のメンバノード３１がグループ２のメンバノード２２で所有されている共有資源２を共有して使用する場合の各処理について、図９に示す最終状態を初期段階とし、図１０に示す処理を参照して説明する。ここで、メンバノード３１は、事前にメンバノード２２より共有資源２の使用の許可を得ているものとする。
【００６３】
まず、メンバノード３１は、共有資源２の使用要求を、自グループの代表ノード３０に通知する（ステップＳ３０）。
【００６４】
代表ノード３０は、自ノード内の資源管理テーブルを更新する（ステップＳ３１）。たとえば、資源番号２の使用フラグを「未」から「使」に更新する。
【００６５】
上記各処理が実施されることで、メンバノード３１は、共有資源２の共有者となる。
【００６６】
なお、共有資源Ａの使用は、その所有ノードであるメンバノードのみならず、他のメンバノードも使用が可能な資源である。よって、メンバノード３１が、事前にメンバノード２２より共有資源２の使用の許可を得ていない場合は、たとえば、代表ノード３０に対して、共有申請を行うために「共有許可」を通知し、システム内で所有ノードとして設定されているメンバノードに共有の許可の有無を問い合わせ、共有許可の返答があったメンバノードが所有する共有資源を使用することができる。
【００６７】
［障害時復旧処理段階：代表ノードがダウンする場合］
以下、資源管理テーブルを有する代表ノード、たとえば、代表ノード２０がダウンした場合の復旧処理について図１１〜図１６を参照して説明する。障害時の初期状態は、図１１に示す状態とする。
【００６８】
まず、代表ノード２０がダウンした場合、図１２に示すように、メンバノード２１が代表ノードとして機能する（ステップＳ４０）。たとえば、代表ノード２０と同グループに属するメンバノード２１は、代表ノード２０のダウンを検知することで、代表ノード２１として機能する。なお、代表ノード２１として機能するメンバノードは、メンバノード２１の場合に限られず、メンバノード２であってもよい。本実施形態において、代表ノードとして機能するメンバノードを決定するアルゴリズムは特定されない。
【００６９】
次いで、メンバノード２１（代表ノード２１）は、図１３に示すように、他グループ内１０，３０の代表ノード１０，３０から、各代表ノード１０，３０の管理内の共有資源の管理情報を収集する（ステップＳ４１）。具体的には、代表ノード１０（３０）は、自ノードの資源管理テーブルを探索し、自ノードで管理する共有資源である共有資源０（３）の識別情報（資源番号）を、メンバノード２１に対して返却することで、メンバノード２１は、各代表ノード１０，３０の管理内の共有資源の識別情報を収集する。
【００７０】
次いで、メンバノード２１（代表ノード２１）は、収集した複数の共有資源の識別情報に基づいて、資源管理テーブルを作成する（ステップＳ４２）。すなわち、初期状態（内容が何も設定されていない状態）の資源管理テーブルに対して、資源番号０および３が他グループの代表ノード１０，３０によって管理されている状態、すなわち、資源番号０および３の使用フラグを「未」とし、かつ、オーナノードを「斜線」として設定する。
【００７１】
なお、自グループ以外の全ての代表ノードから識別情報を取得することで、使用フラグが設定されていない資源番号に該当する共有資源は、ダウンした代表ノード２０が管理していた共有資源であることを特定することができる。
【００７２】
次いで、メンバノード２１（代表ノード２１）は、図１４に示すように、他グループ内１０，３０の代表ノード１０，３０から、各代表ノード１０，３０の管理外の共有資源の使用情報を収集する（ステップＳ４３）。具体的には、代表ノード１０（３０）が、自ノードの資源管理テーブルを参照し、自ノードの管理外で使用中の共有資源を探索し、その結果をメンバノード２１に返却することで、メンバノード２１は、各代表ノード１０，３０の管理外の共有資源の使用情報を収集する。図１４に示す管理状態では、メンバノード２１は、代表ノード１０から自ノードの管理外で使用中の共有資源は無し、という使用情報を、また、代表ノード３０から自ノードの管理外で使用中の共有資源２の使用情報を収集する。
【００７３】
次いで、メンバノード２１（代表ノード２１）は、収集した使用情報に基づいて資源管理テーブルを作成する（ステップＳ４４）。たとえば、メンバノード２１は、代表ノード３０より要求結果を受け取り、自ノード内の資源管理テーブルの資源番号２の使用フラグを「使」として設定する。
【００７４】
次いで、メンバノード２１（代表ノード２１）は、図１５に示すように、自グループのメンバノード（メンバノード２１自身を含む）から、共有資源情報を収集する（ステップＳ４５）。具体的には、代表ノードとなったメンバノード２１自身からは共有資源１を所有することを表す共有資源情報、およびメンバノード２２からは所有する共有資源は無いという共有資源情報を収集する。
【００７５】
次いで、メンバノード２１（代表ノード２１）は、収集した共有資源情報に基づいて資源管理テーブルを作成する（ステップＳ４６）。たとえば、代表ノード２１となったメンバノード２１が、資源番号１の共有資源１を所有していた場合、自ノード内の資源管理テーブルの資源番号１の使用フラグを「使」として設定し、オーナノードをメンバノード２１を表す「２１」として設定する。この時点で、資源管理テーブルにおいて、使用フラグが「使」で、かつ、オーナノードが何も設定されていない共有資源は、ダウンした代表ノード１０の所有資源であることが特定できる。
【００７６】
次いで、メンバノード２１（代表ノード２１）は、図１６に示すように、他グループ内の代表ノード１０，３０に対して、そのダウンした代表ノード２０が管理していた共有資源２の「使用停止」の要求情報を通知する（ステップＳ４７）。
【００７７】
次いで、代表ノード１０，３０は、資源管理テーブルを参照し、自グループ内で使用停止の対象となる共有資源を使用しているメンバノードが存在するか否かを判定する（ステップＳ４８）。具体的には、代表ノード１０は、資源番号２の使用フラグが「未」であるので該当するメンバノードが存在しないと判定し、代表ノード３０は、資源番号２の使用フラグが「使」であるので該当するメンバノードが存在すると判定する。
【００７８】
次いで、代表ノード１０，３０は、判定した結果、該当するメンバノードが存在する場合、該グループ内のメンバノードに対して「使用停止」の要求情報を通知し、一方、該当するメンバノードが存在しない場合、該グループ内のメンバノードに対して、「使用停止」の要求情報を通知しない（ステップＳ４９）。具体的には、代表ノード１０は、該当するメンバノードが存在しないと判定されるため、「使用停止」の要求情報を通知せず、一方、代表ノード３０は、該当するメンバノードが存在すると判定されるため、「使用停止」の要求情報を通知する。
【００７９】
次いで、メンバノード２１（代表ノード２１）は、自グループ内のメンバノード２２に対して、資源番号２の「使用停止」の要求情報を通知し、自ノード内の資源管理テーブルを更新する（ステップS５０）。たとえば、資源管理テーブルにおいて、資源番号２の「使用フラグ」を「未」に設定する。
【００８０】
［障害時復旧処理段階：共有資源を所有するメンバノードがダウンする場合］
以下、共有資源を所有するメンバノード、たとえば、共有資源２を所有するメンバノード２２がダウンした場合の復旧処理について、図１７〜図１８を参照して説明する。障害時の初期状態は、図１７に示す状態とする。
【００８１】
まず、代表ノード２０は、図１８に示すように、自グループ内のメンバノード２２がダウンした場合、資源管理テーブルを参照し、ダウンしたメンバノード２２が使用していた共有資源２の「使用停止」の要求情報を他グループの代表ノード１０，３０に通知する（ステップＳ５１）。代表ノード２０は、たとえば、メンバノード２２のダウンを検知した場合、資源管理テーブルを参照し、該ダウンしたメンバノード２２が共有資源を所有する所有ノードであるかを判断し、所有ノードである場合、該当する共有資源の「使用停止」の要求情報を他グループの代表ノード１０，３０に通知する。
【００８２】
次いで、代表ノード１０，３０は、自ノードの資源管理テーブルを参照し、自グループ内で使用停止の対象となる共有資源２を使用しているメンバノードが存在するか否かを判定する（ステップＳ５２）。具体的には、代表ノード１０は、資源番号２の使用フラグが「未」であるので該当するメンバノードが存在しないと判定し、代表ノード３０は、資源番号２の使用フラグが「使」であるので該当するメンバノードが存在すると判定する。
【００８３】
次いで、代表ノード１０，３０は、自グループ内で使用停止の対象となる共有資源を使用するメンバノードが存在する場合、該メンバノードに対して「使用停止」の要求情報を通知し、一方、該当するメンバノードが存在しない場合、該グループ内のメンバノードに対して、「使用停止」の要求情報を通知しない（ステップＳ５３）。具体的には、代表ノード１０は、該当するメンバノードが存在しないと判定されるため、「使用停止」の要求情報を通知せず、一方、代表ノード３０は、該当するメンバノードが存在すると判定されるため、「使用停止」の要求情報を通知する。
【００８４】
次いで、代表ノード２０は、自ノード内の資源管理テーブルを更新する（ステップＳ５３）。たとえば、資源管理テーブルにおいて、資源番号２の「使用フラグ」を「未」に変更する。
【００８５】
以上より、本実施形態の資源管理システムおよび資源管理方法によれば、各グループの代表ノードに資源管理テーブルを備える構成とすることで、ある代表ノードがダウンした場合であっても、他の代表ノードが保持する資源管理テーブルの情報等から、ダウンした代表ノードが保持していた資源管理テーブルを復元することができるため、従来のように、資源管理テーブルのバックアップを必要とせず、かつ、資源管理システム内の全てのノードに問い合わせるためにブロードキャストをする必要がない。その結果、システム全体で処理される情報量を制限し、システム負荷を軽減することができる。
【００８６】
また、各グループの代表ノードに資源管理テーブルを備える構成とすることで、共有資源を所有する、あるメンバノード（所有ノード）がダウンした場合であっても、代表ノードおよびメンバノードをグループで束ね、各グループの代表ノードにメンバノードの共有資源の使用情報を管理させているため、各グループごとに、そのダウンしたメンバノードが所有する共有資源を使用するメンバノードが存在するか否かを特定することができる。その結果、各グループごとに、代表ノード以下のメンバノードに対して、該当する共有資源の障害を通知するか否かを判断することができため、従来のように、資源管理システム内の全てのノードにブロードキャストを必要とせず、その通知範囲をグループ単位に減少させることができ、障害時のシステム負荷を低減することができる。
【００８７】
＜第２実施形態＞
図１９は、本発明の第２実施形態の資源管理システム１の概略構成の一例を示す図である。
【００８８】
第２実施形態の資源管理システム２は、第１実施形態の資源管理システム１において、ＲＤＭＡ（Ｒｅｍｏｔｅ  Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）を適用することを特徴とする。
【００８９】
資源管理システム２は、第１実施形態の資源管理システム１の構成に加えて、各代表ノードにさらに他グループの資源管理テーブルを取得する取得手段を備える。なお、取得手段以外は、原則として、上記資源管理システム１と同様の機能とすることができるので、ここでの詳細な説明は省略する。
【００９０】
代表ノード１０の取得手段１０５は、他の代表ノード２０，３０の資源管理テーブルを参照する必要が生じた場合、たとえば、他の代表ノード（管理ノード）から識別情報や使用情報の収集を必要とする場合、他の代表ノード２０，３０の資源管理テーブルを取得する。具体的には、取得手段１０５は、ＲＤＭＡを使用して、資源管理テーブルを自ノード内にコピーする。代表ノード２０の取得手段２０５、および代表ノード３０の取得手段３０５も同様である。
【００９１】
以下、第２実施形態の資源管理システムの処理手順を、図２０を参照して説明する。
【００９２】
たとえば、代表ノード２０の資源管理テーブルに関連する処理過程において、他の代表ノード（ここでは、代表ノード１０）の資源管理テーブルに対して参照の必要が生じたものとする。
【００９３】
代表ノード２０は、ＲＤＭＡを使用して、代表ノード１０の資源管理テーブルを、自ノード内にコピー処理して取得する（以下、コピーした資源管理テーブルをコピーテーブルと称する）。
【００９４】
代表ノード２０は、コピーテーブルに対して参照を実行し、参照結果を利用して、代表ノード２０の管理テーブルに関連する処理を継続することができる。
【００９５】
以上の処理は、代表ノード３０においても同様にすることができる。よって、図２０に示すように、代表ノード２０と代表ノード３０は、代表ノード１０の資源管理テーブルのＲＤＭＡを用いたコピー処理も含めて、各処理の同時実行が可能であり、この際、代表ノード１０の計算資源を一切使用しない。
【００９６】
すなわち、ＲＤＭＡを用いない方法では、代表ノード１０に対して同時に処理請求が到着した場合、同時到着した数分だけ、代表ノード１０の計算資源を消費するか、もしくは１要求分の計算資源をシリアルに実行することとなってしまい、また、どちらにおいても処理に関わりのない代表ノード１０の計算資源を要する。さらに、処理要求を行った代表ノードは、その応答を待つために、自身の計算資源の無駄も発生してしまう。
【００９７】
しかし、本実施形態のように、ＲＤＭＡを用いることで、資源管理テーブルの参照が必要な相手側の代表ノードにおいて計算資源の消費を抑制することができ、また、処理要求を行った自身も待機状態で不必要な計算資源の消費を抑制することができる。
【００９８】
次に、代表ノード２０は、他の代表ノードの資源管理テーブルに対して更新が必要である場合の処理手順を説明する。
【００９９】
たとえば、代表ノード２０の資源管理テーブルに関連する処理過程において、他の代表ノード（ここでは、代表ノード１０）の資源管理テーブルに対して更新の必要が生じたものとする。
【０１００】
代表ノード２０は、ＲＤＭＡを使用して、代表ノード１０の資源管理テーブルを、自ノード内にコピー処理して取得する（以下、コピーした資源管理テーブルをコピーテーブルと称する）。
【０１０１】
以上の処理は、代表ノード２０は、コピーテーブルに対して更新を実行し、該更新を実行したコピーテーブルを、ＲＤＭＡを用いて代表ノード１０に送信し、代表ノード１０の資源管理テーブルを上書きし、代表ノード２０の管理テーブルに関連する処理を継続することができる。
【０１０２】
他の代表ノードの資源管理テーブルの更新が必要である場合も、上記参照する処理の場合と同様に、相手側の他の代表ノード１０における計算資源を使用しないという利点を有する。
【０１０３】
以上より、 ＲＤＭＡを使用できる環境において、本実施形態にＲＤＭＡを適用することは、他の代表ノードに対して無用な計算資源の消費を抑制できるだけでなく、システムの並列処理を最大限生かすことができる。
【０１０４】
なお、本実施形態において、取得手段は、各代表ノードに備える場合を説明したが、本発明はこれに限られず、たとえば、メンバノードにも備えることができる。メンバノードが取得手段を備えることで、たとえば、代表ノードがダウンした場合であって、自ら代表ノードとして機能し、資源管理テーブルを作成するときに、各代表ノードから並列に、資源管理テーブルを参照することができるため、有効である。
【０１０５】
＜第３実施形態＞
図２１は、本発明の第３実施形態の資源管理システム３の概略構成の一例を示す図である。
【０１０６】
第３実施形態の資源管理システム３は、第１実施形態の資源管理システム１の構成に加えて、各ノードの接続に通信装置を使用した構成である。
【０１０７】
資源管理システム３において、代表ノードおよびメンバノードの機能および構成は、下記で特に言及しない場合、原則として、第１実施形態の資源管理システム１と同様の機能および構成とすることができるので、ここでの詳細な説明は省略する。
【０１０８】
通信装置１３，２３，３３は、グループごとに備えられ、自グループの代表ノード（管理ノード）およびメンバノードと、他グループの代表ノード（管理ノード）およびメンバノードとを相互に通信する装置であって、たとえば、クロスバースイッチである。各通信装置１３，２３，３３は、共有レジスタの一部を管理領域として使用し、該管理領域に上記第１実施形態において各代表ノードが備えていた資源管理テーブルを配置する。なお、本実施形態においては、各代表ノード１０，２０，３０において、資源管理テーブルを保持しない構成とする。
【０１０９】
各代表ノードに資源管理テーブルを保持しない構成とすることで、ある代表ノードがダウンした場合であっても、資源管理テーブルが消失することはないため、第１実施形態において、ダウンした代表ノードが管理していた共有資源を特定するための各処理が不要となり、ダウンした代表ノードが所有していた資源の使用停止の通知に関する各処理と、資源管理テーブルの更新処理（該当する資源番号の使用フラグの更新処理）のみで復旧が可能となる。
【０１１０】
ここで、資源管理システム３の構成において、資源管理テーブルの消失は、クロスバースイッチのダウンによって発生する。資源管理システム３から見た場合、１つのクロスバースイッチがダウンした状況とは、該クロスバースイッチに接続された全てのノードが通信不可となるため、１つのグループに属する代表ノードおよびメンバノードがダウンしたことと同等である。また、本構成では、共有資源がクロスバースイッチ内に存在しているため、クロスバースイッチのダウンと共にその資源も消滅してしまう。
【０１１１】
そこで、本実施形態の資源管理システム３では、代表ノード１０'は、他グループのクロスバースイッチがダウンした場合、動作中の他グループの通信装置２３，３３が管理する共有資源の識別情報および使用情報を収集する収集手段と、該収集した結果に基づいて、ダウンしたクロスバースイッチが管理する共有資源を特定する特定手段と、自グループ内で特定された共有資源を使用するメンバノードが存在するか否かを判定する判定手段と、判定した結果、特定された共有資源を使用するメンバノードが存在する場合、該メンバノードに対して使用停止情報を通知する通知手段と、を備える。
【０１１２】
資源管理システム３において、上記クロスバースイッチがダウンした場合の資源管理テーブルの復旧は、各グループの代表ノードが以下の処理を実施する。
【０１１３】
まず、ダウンしたクロスバースイッチと同グループの代表ノードが管理していた共有資源を、現存する各代表ノードの管理している共有資源と全体の共有資源の差分から特定する。
【０１１４】
次いで、ダウンしたクロスバースイッチの代表ノードが管理していた資源の使用状況を確認し、必要に応じてメンバノードに使用停止を通知する。
【０１１５】
次いで、ダウンしたクロスバースイッチ内の共有資源の管理権をもっている場合は、資源管理テーブルより該当する共通資源の項目を削除する。
【０１１６】
次いで、ダウンしたクロスバースイッチの代表ノードに、自クロスバースイッチ内の共有資源の管理権を譲渡している場合は、その資源の管理権を自分自身に設定する。
【０１１７】
次いで、各代表ノード間で上記処理の完了を待機する。
【０１１８】
以上の処理により、クロスバースイッチがダウンしても、資源管理システムを継続することが可能である。なお、本構成において、「代表ノードは接続しているクロスバースイッチ内の資源のみを管理し、共有資源の管理権を譲渡しない」という条件をつけるならば、クロスバースイッチのダウンによる復旧作業は、ダウンしたクロスバースイッチの代表ノードが管理していた資源の使用状況を確認し、必要に応じてメンバノードに使用停止を通知する処理のみに簡略化できる。
【０１１９】
＜変形例＞
以上のように本発明の好適な実施形態について説明したが、本発明は、以上の実施形態に限定されるべきものではなく、特許請求の範囲に表現された思想および範囲を逸脱することなく、種々の変形、追加、および省略が当業者によって可能である。
【０１２０】
たとえば、本発明は、ＨＰＣ（Ｈｉｇｈ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｃｏｍｐｕｔｉｎｇ）分野、クラスタリング分野において、各ノード間が相互に情報を伝達する手段（ネットワーク等）で等価に接続され、これら各ノードにより共有される資源があり、この資源を一意な番号で特定することができ、資源をシステム内で共通に管理する場合に適用することができる。
【０１２１】
また、上記各実施形態において、各グループに属するメンバノードの数は２つとしたが、本発明はこれに限られず、グループごとに、それぞれ少なくとも１つ以上とすることもできる。
【０１２２】
さらに、上記各実施形態において、各代表ノードおよびメンバノードに備えられている各手段は、そのいくつかを一纏めにして構成されていてもよいし、一つの手段をさらに複数の手段に分割して構成されていてもよい。
【符号の説明】
【０１２３】
１、２、３  資源管理システム、
１０、２０、３０  代表ノード、
１１、１２、２１、２２、３１、３２  メンバノード、
１０１  第１通知手段、
１０２  判定手段、
１０３  第２通知手段、
１０４  データベース、
１１１、１２１  収集手段、
１１２、１２２  作成手段、
１１３、１２３  データベース。
【図１】
0005517044.tif 000002
【図２】
0005517044.tif 000003
【図３】
0005517044.tif 000004
【図４】
0005517044.tif 000005
【図５】
0005517044.tif 000006
【図６】
0005517044.tif 000007
【図７】
0005517044.tif 000008
【図８】
0005517044.tif 000009
【図９】
0005517044.tif 000010
【図１０】
0005517044.tif 000011
【図１１】
0005517044.tif 000012
【図１２】
0005517044.tif 000013
【図１３】
0005517044.tif 000014
【図１４】
0005517044.tif 000015
【図１５】
0005517044.tif 000016
【図１６】
0005517044.tif 000017
【図１７】
0005517044.tif 000018
【図１８】
0005517044.tif 000019
【図１９】
0005517044.tif 000020
【図２０】
0005517044.tif 000021
【図２１】
0005517044.tif 000022