JP2010205005A - 共通資源管理システム、方法、及び、プログラム - Google Patents

Abstract

【課題】特定のノードにアクセスを集中させることなく、また、ネットワークの規模に依存せずに資源の取得を可能とする共通資源管理システムを提供する。
【解決手段】共通資源管理テーブル１５は、ネットワーク内の複数のノードが共通に使用可能な共通資源の使用状況を管理する。共通資源管理テーブル移動手段１１は、共通資源管理テーブル１５を、一のノードから別のノードに移動させる。テーブルポインタ１４は、共通資源管理テーブルを保有するノードの識別情報を記憶する。テーブルポインタ更新手段１２は、共通資源管理テーブルが移動した際に、テーブルポインタ１４に、移動先のノードの識別情報を記憶する。
【選択図】図１

Description

本発明は、共通資源管理システム、方法、及び、プログラムに関し、更に詳しくは、複数のノードで共有可能な資源を管理する共通資源管理システム、方法、及び、プログラムに関する。

分散並列処理の分野で、複数のノードが共通の資源を利用可能なシステムがある。一般に、そのようなシステムでは、共通資源の管理テーブルを１つのノードに固定し、そのノードが資源の割り当て及び管理を行う。共通資源管理テーブルは、並列処理システム内の様々なプロセスから利用される。このため、共通資源管理テーブルが置かれたノードにアクセスが集中することになり、そのノードのアクセス負荷が高くなる。また、共通資源管理テーブルは、そのアクセスに排他制御を必要とするため、共通資源管理テーブルに関わる処理は、システムの運用効率に影響を与える。

特定ノードへのアクセス集中を回避できる技術として、特許文献１に記載の技術がある。ネットワークには、複数の資源提供主体と、複数の資源使用主体とが接続される。資源提供主体及び資源使用主体は、資源の空き状況を示す空き資源リストをネットワークに巡回させる。資源提供主体は、空き資源リストを受け取ると、その時点で資源提供主体が保有している資源の空き状況に基づいて、空き資源リストを更新する。資源提供主体は、空き資源リストの更新後、更新した空き資源リストを、次の資源提供主体又は資源使用主体に渡す。

各資源使用主体は、ネットワークを介して空き資源リストを取得する。資源使用主体は、空き資源リスト内に、自身が獲得を希望する資源があるか否かを調べる。資源使用主体は、空き資源リストに獲得したい資源があるときは、その資源を獲得すべく、空き資源リストを更新する。資源使用主体は、空き資源リストの更新後、空き資源リストを、次の資源使用主体又は資源提供主体に渡す。また、資源使用主体は、獲得すべき資源を保有する資源提供主体に対して資源使用要求を送信し、資源提供主体から資源を獲得する。

特開平１０−２７１０９号公報

特許文献１では、空き資源リストはネットワークを巡回するので、特定のノードへアクセスが集中することを回避できる。しかし、特許文献１では、空き資源リストをネットワークの全てのノードに巡回させる必要がある。このため、規模に依存して、空き資源リストがネットワークを巡回する時間が変化し、ノード数が増えるほど、資源獲得までに要する時間が長くなる。また、資源使用主体は、空き資源リストが巡回してきたタイミングでしか資源獲得ができないという問題もある。

本発明は、特定のノードにアクセスを集中させることなく、また、ネットワークの規模に依存せずに共通資源の管理情報にアクセス可能な共通資源管理システム、方法、及び、プログラムを提供することを目的とする。

上記目的を達成するために、本発明の共通資源管理システムは、ネットワーク内の複数のノードが共通に使用可能な共通資源の使用状況を管理する共通資源管理テーブルを、一のノードから別のノードに移動させる共通資源管理テーブル移動手段と、前記共通資源管理テーブルが移動した際に、前記共通資源管理テーブルを保有するノードの識別情報を記憶するテーブルポインタに、移動先のノードの識別情報を記憶するテーブルポインタ更新手段とを備えることを特徴とする。

本発明の共通資源管理方法は、コンピュータが、ネットワーク内の複数のノードが共通に使用可能な共通資源の使用状況を管理する共通資源管理テーブルを、一のノードから別のノードに移動させる移動ステップと、前記コンピュータが、前記共通資源管理テーブルを保有するノードの識別情報を記憶するテーブルポインタに、前記移動ステップで移動させた移動先のノードの識別情報を記憶するテーブルポインタ更新ステップとを有することを特徴とする。

本発明のプログラムは、コンピュータに、ネットワーク内の複数のノードが共通に使用可能な共通資源の使用状況を管理する共通資源管理テーブルを、一のノードから別のノードに移動させる移動処理と、前記共通資源管理テーブルを保有するノードの識別情報を記憶するテーブルポインタに、前記移動処理で移動させた移動先のノードの識別情報を記憶するテーブルポインタ更新処理とを実行させることを特徴とする。

本発明の共通資源管理システム、方法、及び、プログラムは、特定のノードにアクセスを集中させることなく、また、ネットワークの規模に依存せずに共通資源の管理情報にアクセスすることができる。

本発明の第１実施形態の共通資源管理システムを示すブロック図。 共通資源管理テーブルアクセス時の動作手順を示すフローチャート。 共通資源管理テーブル再構築時の動作手順を示すフローチャート。 稼働開始時のノードの動作手順を示すフローチャート。 稼働中の２つのノードを示すブロック図。 共通資源管理テーブル移動後の状態を示すブロック図。 プライマリのテーブルポインタにアクセスできない状態を示すブロック図。 プライマリ及びセカンダリのテーブルポインタにアクセスできない状態を示すブロック図。 共通資源管理テーブルにアクセスできない状態を示すブロック図。 共通資源管理テーブルの再構築前の状態を示すブロック図。 共通資源管理テーブルの再構築後の状態を示すブロック図。 稼働中のノードが１つの状態を示すブロック図。 稼働中のノードが２つの状態を示すブロック図。 稼働中のノードが３つの状態を示すブロック図。 本発明の第２実施形態の共通資源管理システムを示すブロック図。

以下、図面を参照し、本発明の実施の形態を詳細に説明する。図１は、本発明の第１実施形態の共通資源管理システムを示している。共通資源管理システムは、分散処理システムを構成する複数のノード（ノード１０、２０）を有する。ノード１０及びノード２０は、例えばコンピュータである。ノード１０とノード２０とは、ネットワークを介して相互に接続される。図１では、ノードの数が２つであるが、ノードの数は３以上でもよい。ノード１０と、ノード２０とは、図示しない共通の資源を利用可能である。

ノード１０は、共通資源管理テーブル移動手段１１、テーブルポインタ更新手段１２、共通資源管理テーブル再構築手段１３、及び、プロセス１９を有する。また、ノード１０は、情報記憶領域として、テーブルポインタ１４、共通資源管理テーブル１５、及び、管理テーブル情報１６を有する。共通資源管理テーブル移動手段１１は、共通資源管理テーブルアクセス手段１７を含む。ノード１０内の各手段の機能は、コンピュータ上で所定のプログラムを実行することで実現可能である。

ノード２０は、共通資源管理テーブル移動手段２１、テーブルポインタ更新手段２２、共通資源管理テーブル再構築手段２３、及び、プロセス２９を有する。また、ノード２０は、情報記憶領域として、テーブルポインタ２４、共通資源管理テーブル２５、及び、管理テーブル情報２６を有する。共通資源管理テーブル移動手段２１は、共通資源管理テーブルアクセス手段２７を含む。ノード２０内の各手段の機能は、コンピュータ上で所定のプログラムを実行することで実現可能である。なお、以下、ノードを代表して、ノード１０の各構成要素について説明するが、ノード２０内の各構成要素の役割は、ノード１０内の対応する各構成要素の役割と同じである。

共通資源管理テーブル１５は、共通資源の管理情報（使用状況、空き状況）を記憶するテーブルである。共通資源は、システム内でユニークな番号で管理されている。共通資源の具体例としては、ノード間スイッチの複数のレジスタなどが挙げられる。共通資源は、ハードウェア資源には限られず、ソフトウェア的な資源（リソース）でもよい。共通資源管理テーブル移動手段１１は、共通資源管理テーブルを、一のノードから別のノードに移動させる。共通資源管理テーブル１５は、共通資源管理テーブル１５がノード１０に移動した時刻を含む。プロセス１９は、共通資源管理テーブルを参照して処理を行う部分である。

テーブルポインタ１４は、使用中の共通資源管理テーブルを保有するノードのノード番号（ノード識別情報）を格納する。また、テーブルポインタ１４は、付加情報として、共通資源管理テーブルの最終移動時刻を保持する。テーブルポインタは、ネットワークを構成する複数のノードのうちの少なくとも１つに存在する。管理テーブル情報１６は、テーブルポインタが存在するノードのノード番号を保持する。図１では、管理テーブル情報１６は、プライマリとして用いるテーブルポインタを保有するノードのノード番号（Ｐ）と、セカンダリとして用いるテーブルポインタを保有するノードのノード番号（Ｓ）とを保持している。

共通資源管理テーブルアクセス手段１７は、共通資源管理テーブルにアクセスする。共通資源管理テーブルアクセス手段１７は、アクセスに際して、まず、管理テーブル情報１６を参照し、テーブルポインタが存在するノードを特定する。次いで、共通資源管理テーブルアクセス手段１７は、特定したノードが保有するテーブルポインタを参照し、共通資源管理テーブルを保有するノードを特定する。その後、特定したノードが保有する共通資源管理テーブルにアクセスする。

共通資源管理テーブル移動手段１１は、共通資源管理テーブルアクセス手段１７がアクセスする共通資源管理テーブルの内容を、自ノード内の共通資源管理テーブル１５に格納し、共通資源管理テーブルを、自ノードに移動させる。その際、共通資源管理テーブル移動手段１１は、共通資源管理テーブルの移動時刻と現在時刻（共通資源管理テーブルにアクセスした時刻）とを比較する。共通資源管理テーブル移動手段１１は、時刻の差が所定の時間を超えるときに共通資源管理テーブルの移動を行う。差が所定時間よりも短いときは、共通資源管理テーブルの移動は行わない。このようにする理由は、共通資源管理テーブルが頻繁に移動し、ネットワーク負荷が増大することを避けるためである。

テーブルポインタ更新手段１２は、共通資源管理テーブル移動手段１１が共通資源管理テーブルを自ノードに移動すると、移動先のノードのノード番号、つまり、ノード１０のノード番号を、テーブルポインタに格納する。また、テーブルポインタ更新手段１２は、共通資源管理テーブルの最終移動時刻を、テーブルポインタに格納する。このとき、テーブルポインタ更新手段１２は、管理テーブル情報１６に格納されたノード番号のノードが保有するテーブルポインタに、ノード１０のノード番号、及び、最終移動時刻を格納する。

共通資源管理テーブル再構築手段１３は、共通資源管理テーブルアクセス手段１７が共通資源管理テーブルにアクセスできないとき、通信可能なノードから共通資源の使用状況を取得し、自ノード内に共通資源管理テーブルを再構築する。その後、共通資源管理テーブル再構築手段１３は、テーブルポインタに、再構築した共通資源管理テーブルを保有するノード、つまり、自ノードのノード番号を記録する。共通資源管理テーブルアクセス手段１７が共通資源管理テーブルにアクセスできない状況としては、共通資源管理テーブルを保有するノードがダウンし、そのノードから共通資源管理テーブルを取得できない状況が考えられる。また、テーブルポインタを保有するノードがダウンし、使用中の共通資源管理テーブルを保有するノードが不明となる状況が考えられる。

図２に、共通資源管理テーブルへのアクセス時の動作手順を示す。ここでは、ノード１０が共通資源管理テーブルへアクセスするものとして説明する。共通資源管理テーブルアクセス手段１７は、プロセス１９が共通資源管理テーブルを参照する際に、管理テーブル情報１６を参照し、管理テーブル情報１６にプライマリとして用いるテーブルポインタを保有するノードとして記録されているノードを特定する（ステップＡ１）。共通資源管理テーブルアクセス手段１７は、特定したノードが保有するテーブルポインタ、つまり、プライマリとして用いるテーブルポインタにアクセス可能か否かを判断する（ステップＡ２）。共通資源管理テーブルアクセス手段１７は、アクセス可能なときは、テーブルポインタを参照して、使用中の共通資源管理テーブルを保有するノードを特定する（ステップＡ３）。

共通資源管理テーブルアクセス手段１７は、ステップＡ２でアクセス不能と判断すると、管理テーブル情報１６を参照し、管理テーブル情報１６にセカンダリとして用いるテーブルポインタを保有するノードとして記録されたノードを特定する（ステップＡ４）。共通資源管理テーブルアクセス手段１７は、特定したノードが保有するテーブルポインタ、つまり、セカンダリとして用いるテーブルポインタにアクセス可能か否かを判断する（ステップＡ５）。共通資源管理テーブルアクセス手段１７は、アクセス可能なときは、ステップＡ３に進み、テーブルポインタを参照して、使用中の共通資源管理テーブルを保有するノードを特定する。

共通資源管理テーブルアクセス手段１７は、ステップＡ５でアクセス不能と判断すると、現在使用中の共通資源管理テーブルを保有するノードが不明であるとして、共通資源管理テーブルの再構築処理を行う（ステップＡ６）。この再構築処理については後述する。なお、プライマリのテーブルポインタと、セカンダリのテーブルポインタとには、同じノード番号が記録されている。このため、プライマリのテーブルポインタを用いる場合も、セカンダリのテーブルポインタを用いる場合も、ステップＡ３で特定される共通資源管理テーブル保有ノードは同じノードになる。

共通資源管理テーブルアクセス手段１７は、ステップＡ３で特定したノードが保有する共通資源管理テーブルにアクセス可能か否かを判断する（ステップＡ７）。共通資源管理テーブルアクセス手段１７は、アクセス不能と判断すると、現在使用中の共通資源管理テーブルが使用不能であるとして、ステップＡ６に進み、共通資源管理テーブルの再構築を行う。共通資源管理テーブルアクセス手段１７は、ステップＡ７でアクセス可能と判断したときは、共通資源管理テーブルから移動時刻を取得し、これと、プライマリ又はセカンダリのテーブルポインタに記録された最終移動時刻とが一致するか否かを判断する（ステップＡ８）。共通資源管理テーブルアクセス手段１７は、両者が一致しないときは、共通資源管理テーブルが無効であるとして、ステップＡ６に進み、共通資源管理テーブルの再構築処理を行う。共通資源管理テーブルアクセス手段１７は、時刻が一致するときは、共通資源管理テーブルが有効であると判断する。

共通資源管理テーブルの有効性が確認されると、共通資源管理テーブル移動手段１１は、現在時刻と共通資源管理テーブルの最終移動時刻との差、つまり、共通資源管理テーブルが前回移動してからの経過時間を求める。共通資源管理テーブル移動手段１１は、経過時間が所定の時間（最大停留時間）を超えているか否かを判断する（ステップＡ９）。この最大停留時間は、システム規模、運用形態などに基づいて、あらかじめ決めておく。共通資源管理テーブル移動手段１１は、前回の移動からの経過時間が、最大停留時間を超えるときは、共通資源管理テーブルを、自ノードに移動する（ステップＡ１０）。すなわち、共通資源管理テーブル移動手段１１は、共通資源管理テーブルアクセス手段１７がアクセスする共通資源管理テーブルの内容を、自ノードの共通資源管理テーブル１５に格納する。共通資源管理テーブル移動手段１１は、ステップＡ９で前回の移動からの経過時間が最大停留時間以内と判断したときは、共通資源管理テーブルの移動を行わない。

共通資源管理テーブルの移動を行った場合、共通資源管理テーブル移動手段１１は、自ノードに移動した共通資源管理テーブル１５に、移動時刻を記録する（ステップＡ１１）。テーブルポインタ更新手段１２は、管理テーブル情報１６に記録されたノード番号のノードが保有するテーブルポインタに自ノードのノード番号を記録する。また、テーブルポインタ更新手段１２は、テーブルポインタの最終移動時刻に、ステップＡ１１で記録した共通資源管理テーブルの移動時刻を記録する（ステップＡ１２）。テーブルポインタ更新手段１２は、管理テーブル情報１６に、プライマリのテーブルポインタを保有するノードとセカンダリのテーブルポインタを保有するノードの２つのノードが記録されているときは、双方のノードが保有するテーブルポインタに、自ノードのノード番号と最終移動時刻とを記録する。

共通資源管理テーブルアクセス手段１７は、プロセス１９の資源取得又は資源解放に合わせて、共通資源管理テーブルを更新する（ステップＡ１３）。共通資源管理テーブルアクセス手段１７は、共通資源管理テーブルが自ノードに移動しているときは、更新内容を自ノードの共通資源管理テーブル１５に反映させる。共通資源管理テーブルアクセス手段１７は、共通資源管理テーブルが移動していないときは、ステップＡ３で特定した共通資源管理テーブル保有ノードが保有する共通資源管理テーブルに、更新内容を反映させる。

図３に、再構築処理の動作手順を示す。共通資源管理テーブル再構築手段１３は、自ノードを含む全ノードから、各ノードの共通資源の使用状況を収集し、共通資源管理テーブル１５に記録する（ステップＢ１）。より詳細には、共通資源管理テーブル再構築手段１３は、各ノードに対し、各ノード（各ノードのマシン）が現在使用している共通資源の情報を問い合わせる。共通資源管理テーブル再構築手段１３は、ノードからの応答に含まれる共通資源の使用状況を、共通資源管理テーブル１５に反映させる。共通資源管理テーブル再構築手段１３は、ノードからの応答が得られないときは、そのノードは未稼働とし、共通資源の使用状況の収集は行わない。

共通資源管理テーブル再構築手段１３は、ステップＢ１では、最弱番のノード番号を持つノードから順に、共通資源の使用状況を問い合わせていく。共通資源管理テーブル再構築手段１３は、全てのノードに対して共通資源の使用状況の問い合わせを完了すると、共通資源管理テーブル１５の移動時刻に、現在時刻を記録する（ステップＢ２）。共通資源管理テーブル再構築手段１３は、システム内に存在するノードが自ノードのみであるか否かを判断する（ステップＢ３）。共通資源管理テーブル再構築手段１３は、システム内に存在するノードが自ノードのみであるときは、管理テーブル情報１６を作成し、管理テーブル情報１６のプライマリに、自ノードのノード番号を記録する（ステップＢ４）。セカンダリについては、空欄（未設定）としておく。

共通資源管理テーブル再構築手段１３は、ステップＢ３でシステム内に他のノードが存在すると判断したときは、プライマリとして用いるテーブルポインタを保有するノードを探すためにブロードキャストを発行する（ステップＢ５）。共通資源管理テーブル再構築手段１３は、発行したブロードキャストに対し応答が得られたか否かを判断する（ステップＢ６）。共通資源管理テーブル再構築手段１３は、応答が得られたときは、管理テーブル情報１６のプライマリに、応答したノードのノード番号を記録する（ステップＢ７）。

共通資源管理テーブル再構築手段１３は、ステップＢ６で応答が得られないと判断すると、管理テーブル情報１６のプライマリに、自ノードのノード番号を記録する（ステップＢ８）。その後、共通資源管理テーブル再構築手段１３は、自ノードがプライマリとなったことを通知するために、管理テーブル情報１６のプライマリが変更されたことを、ブロードキャストで、他のノードに通知する（ステップＢ９）。他のノードは、通知内容に従って、管理テーブル情報のプライマリに、ノード１０のノード番号を記録する。

共通資源管理テーブル再構築手段１３は、プライマリとして用いるテーブルポインタを保有するノードの探索後、セカンダリとして用いるテーブルポインタを保有するノードを探索する。共通資源管理テーブル再構築手段１３は、セカンダリとして用いるテーブルポインタを保有するノードを探すためにブロードキャストを発行する（ステップＢ１０）。共通資源管理テーブル再構築手段１３は、発行したブロードキャストに対し応答が得られたか否かを判断する（ステップＢ１１）。共通資源管理テーブル再構築手段１３は、応答が得られたときは、管理テーブル情報１６のセカンダリに、応答したノードのノード番号を記録する（ステップＢ１２）。

共通資源管理テーブル再構築手段１３は、ステップＢ１１で応答が得られないと判断すると、自ノードがプライマリとして用いるテーブルポインタを保有するノードになっているか否かを判断する（ステップＢ１３）。共通資源管理テーブル再構築手段１３は、自ノードがプライマリのテーブルポインタを保有するノードになっているときは、他のノード、例えば隣接ノードに対し、セカンダリとして用いるテーブルポインタを保有するノードになることを依頼する（ステップＢ１４）。共通資源管理テーブル再構築手段１３は、自ノードがプライマリのテーブルポインタを保有するノードでないときは、管理テーブル情報１６のセカンダリに、自ノードのノード番号を記録する（ステップＢ１５）。その後、共通資源管理テーブル再構築手段１３は、自ノードがセカンダリになったことを通知するために、管理テーブル情報１６のセカンダリが変更されたことを、ブロードキャストで、他のノードに通知する（ステップＢ１６）。

共通資源管理テーブル再構築手段１３は、管理テーブル情報１６に記録されたノード番号のノードが保有するテーブルポインタに、自ノードのノード番号を記録する（ステップＢ１７）。また、共通資源管理テーブル再構築手段１３は、管理テーブル情報１６に記録されたノード番号のノードが保有するテーブルポインタに、ステップＢ２で共通資源管理テーブル１５に記録した移動時刻を記録する。ステップＢ３からステップＢ４に進んだ場合、プライマリとして用いるテーブルポインタを保有するノードが自ノードで、セカンダリとして用いテーブルポインタを保有するノードは存在しない。このため、共通資源管理テーブル再構築手段１３は、自ノードのテーブルポインタ１４に、自ノードのノード番号及び移動時刻を記録する。ステップＢ３からステップＢ４に進んだ場合、共通資源管理テーブル再構築手段１３は、プライマリ及びセカンダリとして用いるテーブルポインタの双方に、自ノードのノード番号及び移動時刻を記録する。

図４に、ノード起動時の動作手順を示す。ノードは、稼働を開始すると、他のノードから管理テーブル情報の取得を試み、管理テーブル情報が取得できたか否かを判断する（ステップＣ１）。既にネットワークに接続されたノードが存在し、そのノードが稼働中であれば、新たに稼働を開始したノードは、稼働中のノードから管理テーブル情報を取得できる。ノードは、管理テーブル情報が取得できないと判断すると、共通資源管理テーブル再構築手段を用いて、共通資源管理テーブルの再構築処理を行う（ステップＣ２）。

ステップＣ２の共通資源管理テーブル再構築処理の手順は、図３に示す手順と同じである。新たに稼働したノードは、共通資源管理テーブルの再構築処理を行うことで、自ノード内に共通資源管理テーブルを作成すると共に、テーブルポインタ及び管理テーブル情報を生成する。ノードは、テーブルポインタの共通資源管理テーブル所在ノードに、自ノードのノード番号を記録する。また、ノードは、管理テーブル情報のプライマリに、自ノードのノード番号を記録する。管理テーブル情報のセカンダリは、設定なしにしておく。

新たに稼働したノードは、ステップＣ１で管理テーブル情報が取得できたと判断すると、自ノード内の管理テーブル情報に、取得した管理テーブル情報の内容を格納する（ステップＣ３）。ノードは、管理テーブル情報に、プライマリとして用いるテーブルポインタを保有するノードのノード番号とセカンダリとして用いるテーブルポインタを保有するノードのノード番号とが記録されているか否かを判断する（ステップＣ４）。プライマリ及びセカンダリとして用いるテーブルポインタを保有するノードの双方が記録されているときは、処理を終了する。

ノードは、ステップＣ３でプライマリとして用いるテーブルポインタを保有するノードとセカンダリとして用いるテーブルポインタを保有するノードの何れか一方が記録されていると判断したときは、記録されたノード番号のノードから、そのノードが保有するテーブルポインタの取得を試みる。ノードは、テーブルポインタを取得できたか否かを判断する（ステップＣ５）。ノードは、テーブルポインタが取得できないときは、ステップＣ２に移行し、共通資源管理テーブルの再構築を行う。

ノードは、ステップＣ５でテーブルポインタが取得できたと判断すると、取得したテーブルポインタの内容を、自ノードのテーブルポインタに記録する（ステップＣ６）。その後、ノードは、管理テーブル情報に、自ノードのノード番号を、プライマリとして用いるテーブルポインタを保有するノードとセカンダリとして用いるテーブルポインタを保有するノードのうちの未設定の方のノードとして記録する。ノードは、自ノードがプライマリとして用いるテーブルポインタを保有するノード又はセカンダリとして用いるテーブルポインタを保有するノードになったことをブロードキャストで宣言する（ステップＣ７）。

以下、具体的なケースを用いて説明する。図５に、稼働中の２つのノードを示す。図５は、障害等が発生していないケースである。ノード２０（ノード番号２０）は、プライマリとして用いるテーブルポインタ２４を保有するノードであり、ノード１０（ノード番号１０）は、セカンダリとして用いるテーブルポインタ１４を保有するノードである。ノード１０の管理テーブル情報１６のプライマリ（Ｐ）にはノード番号「２０」が記録され、セカンダリ（Ｓ）にはノード番号「１０」が記録されている。ノード２０でも、同様に、管理テーブル情報２６のプライマリ（Ｐ）にはノード番号「２０」が記録され、セカンダリ（Ｓ）にはノード番号「１０」が記録されている。

使用中の共通資源管理テーブル情報を保有するノードは、ノード２０である。ノード２０が保有する共通資源管理テーブル２５の移動時刻は、時刻ｔ１である。プライマリとして用いるノード２０のテーブルポインタ２４には、共通資源管理テーブル所在ノードとしてノード番号「２０」が記録されている。また、テーブルポインタ２４には、最終移動時刻として時刻ｔ１が記録されている。セカンダリとして用いるノード１０のテーブルポインタ１４にも、同様に、共通資源管理テーブル所在ノードとしてノード番号「２０」が記録され、最終移動時刻として時刻ｔ１が記録されている。

図５で、ノード１０に属するプロセス（ｐｒｏｃ１）１９が共通資源管理テーブルにアクセスする必要が生じたとする。共通資源管理テーブルアクセス手段１７（図１）は、自ノード内の管理テーブル情報１６のプライマリ（Ｐ）を参照し、ノード番号「２０」を取得する。共通資源管理テーブルアクセス手段１７は、ノード２０が保有するテーブルポインタ２４にアクセスし、使用中の共通資源管理テーブルを保有するノードのノード番号「２０」を取得する。また、共通資源管理テーブルアクセス手段１７は、テーブルポインタ２４から、最終移動時刻ｔ１を取得する。

共通資源管理テーブルアクセス手段１７は、ノード２０が保有する共通資源管理テーブル２５から、共通資源管理テーブル２５がノード２０に移動してきた時刻（移動時刻）ｔ１を取得する。共通資源管理テーブルアクセス手段１７は、テーブルポインタ２４に記録された最終移動時刻ｔ１と、共通資源管理テーブル２５に記録された移動時刻ｔ１とを比較する。両者は一致するので、共通資源管理テーブルアクセス手段１７は、ノード２０が保有する共通資源管理テーブル２５は有効であると判断する。

ノード１０の共通資源管理テーブル移動手段１１は、共通資源管理テーブルがリモートノードにあるので、これを自ノードに移動するか否かを決定する。より詳細には、まず、現在時刻と共通資源管理テーブル２５の移動時刻ｔ１との差から、共通資源管理テーブルがノード２０に移動してからの経過時間を求める。次いで、経過時間と所定の最大停留時間とを比較し、経過時間が最大停留時間を超えるか否かを判断する。共通資源管理テーブル移動手段１１は、経過時間が最大停留時間を超えるときは、共通資源管理テーブルを自ノードに移動すると決定する。経過時間が最大停留時間以内であれば、共通資源管理テーブルを移動しないと決定する。

図６に、共通資源管理テーブル移動後の状態を示す。共通資源管理テーブル移動手段１１は、共通資源管理テーブル２５の内容を複製し、共通資源管理テーブル１５として格納する。また、共通資源管理テーブル１５に、移動時刻ｔ２を記録する。これで、ノード１０が保有する共通資源管理テーブル１５が利用可能な状態になる。その後、テーブルポインタ更新手段１２は、管理テーブル情報１６を参照し、プライマリとして用いるテーブルポインタ２４及びセカンダリとして用いるテーブルポインタ１４の内容を更新する。この更新では、共通資源管理テーブル所在ノードのノード番号をノード番号「２０」からノード番号「１０」に変更すると共に、最終移動時刻を時刻ｔ１から時刻ｔ２に変更する。

プロセス１９は、共通資源管理テーブルに対して更新等の処理を行う。プロセス１９は、共通資源管理テーブルが移動していれば、自ノード内の共通資源管理テーブル１５に、更新内容を反映させる。プロセス１９は、共通資源管理テーブルの移動がなければ、リモートノードであるノード２０が保有する共通資源管理テーブル２５に、更新内容を反映させる。

図７に、プライマリとして用いるテーブルポインタにアクセスできないケースを示す。ノード４０のプロセスに、共通資源管理テーブルにアクセスする必要が生じたとする。ノード４０の共通資源管理テーブルアクセス手段は、管理テーブル情報４６を参照し、プライマリとして用いる、ノード３０が保有するテーブルポインタ３４にアクセスしようとする。ノード３０がダウンなどにより稼働を停止している場合、ノード４０の共通資源管理テーブルアクセス手段は、アクセスに失敗する。

ノード４０の共通資源管理テーブルアクセス手段は、プライマリとして用いるテーブルポインタ３４へのアクセスに失敗すると、管理テーブル情報４６を再び参照し、セカンダリとして用いる、ノード２０が保有するテーブルポインタ２４へアクセスする。ノード２０は稼働中であるので、このアクセスは成功する。共通資源管理テーブルアクセス手段は、テーブルポインタ２４を参照し、使用中の共通資源管理テーブルを保有するノードのノード番号「１０」と、最終移動時刻ｔ５とを取得する。これ以降は、図５を用いて説明した障害等が発生していないケースと同じである。

図８に、プライマリ及びセカンダリとして用いるテーブルポインタの双方にアクセスできないケースを示す。ノード４０のプロセスに、共通資源管理テーブルにアクセスする必要が生じたとする。ノード４０の共通資源管理テーブルアクセス手段は、管理テーブル情報４６を参照し、プライマリとして用いる、ノード３０が保有するテーブルポインタ３４にアクセスしようとする。ノード３０がダウンなどにより稼働を停止している場合、ノード４０の共通資源管理テーブルアクセス手段は、アクセスに失敗する。ここまでは、図７を用いて説明したケースと同じである。

ノード４０の共通資源管理テーブルアクセス手段は、プライマリとして用いるテーブルポインタ３４へのアクセスに失敗すると、管理テーブル情報４６を再び参照し、セカンダリとして用いる、ノード２０が保有するテーブルポインタ２４へのアクセスを試みる。ノード２０は、ダウンしており、このアクセスにも失敗する。つまり、共通資源管理テーブルアクセス手段は、プライマリとして用いるテーブルポインタ３４へのアクセスも、セカンダリとして用いるテーブルポインタ２４へのアクセスも失敗する。

テーブルポインタへのアクセスに失敗すると、使用中の共通資源管理テーブルを保有するノードが不明になるので、図３に示す手順で、共通資源管理テーブルを再構築する。共通資源管理テーブルの再構築を行うことで、ノード４０に、共通資源管理テーブルが生成される。共通資源管理テーブルを再構築した以降は、図５に示す障害がないケースと同様である。

図９に、使用中の共通資源管理テーブルにアクセスできないケースを示す。ノード４０のプロセスに、共通資源管理テーブルにアクセスする必要が生じたとする。ノード４０の共通資源管理テーブルアクセス手段は、管理テーブル情報４６を参照し、プライマリとして用いる、ノード３０が保有するテーブルポインタ３４にアクセスする。共通資源管理テーブルアクセス手段は、テーブルポインタ３４から、共通資源管理テーブルの所在ノードのノード番号「１０」と最終移動時刻ｔ５とを取得する。

ノード４０の共通資源管理テーブルアクセス手段は、ノード１０の共通資源管理テーブル１５にアクセスし、移動時刻を取得しようとするが、ノード１０はダウンしており、アクセスに失敗する。共通資源管理テーブルへのアクセスができないので、図３に示す手順で、共通資源管理テーブルを再構築する。共通資源管理テーブルの再構築を行うことで、ノード４０に、共通資源管理テーブルが生成される。共通資源管理テーブルを再構築した以降は、図５に示す障害がないケースと同様である。

図１０に、ノード３０に共通資源管理テーブルを再構築するケースを示す。ノード２０は、プライマリとして用いるテーブルポインタ２４を保有するノードであり、ノード１０は、セカンダリといして用いるテーブルポインタ１４を保有するノードである。使用中の共通資源管理テーブルが存在するノードは、ノード１０である。ノード３０の共通資源管理テーブルアクセス手段は、プライマリとして用いる、ノード２０が保有するテーブルポインタ２４へのアクセス後、ノード１０の共通資源管理テーブル１５へアクセスする。ノード１０はダウンしており、共通資源管理テーブルアクセス手段は、このアクセスに失敗する。共通資源管理テーブル１５へのアクセスに失敗すると、ノード３０の共通資源管理テーブル再構築手段は、自ノード内に、共通資源管理テーブルを再構築する。

ノード３０の共通資源管理テーブル再構築手段は、自ノードを含む全ノードに対し、現在使用している共通資源の情報（使用状況）を問い合わせ、共通資源の使用状況を収集する。共通資源管理テーブル再構築手段は、収集した使用状況を、自ノード内の共通資源管理テーブル３５に反映させる。このとき、問い合わせに対する応答が得られないノードは、未稼働であるとして、使用状況を収集しない。共通資源管理テーブル再構築手段は、稼働中の全てのノードから共通資源の使用状況を収集し、共通資源管理テーブルが完成すると、共通資源管理テーブルの移動時刻に、現在時刻を記録する。

続いて、ノード３０の共通資源管理テーブル再構築手段は、プライマリとして用いるテーブルポインタを保有するノードを探すために、ブロードキャストを行い、その応答を待つ。図１０では、ノード２０が該当し、ノード２０がブロードキャストに対して応答する。共通資源管理テーブル再構築手段は、ノード２０のノード番号「２０」を、管理テーブル情報３６のプライマリ（Ｐ）に記録する。共通資源管理テーブル再構築手段は、引き続き、セカンダリとして用いるテーブルポインタを保有するノードを探すために、ブロードキャストを行い、その応答を待つ。図１０では、ノード１０が該当するものの、ノード１０はダウンしており、ブロードキャストに対して応答するノードはない。

ノード３０の共通資源管理テーブル再構築手段は、セカンダリのテーブルポインタを保有するノードからの応答がない場合、管理テーブル情報３６のセカンダリ（Ｓ）に、自ノードのノード番号「３０」を記録する。また、共通資源管理テーブル再構築手段は、自ノードがセカンダリとして用いるテーブルポインタを保有するノードになることを宣言するブロードキャストを行う。その後、共通資源管理テーブル再構築手段は、管理テーブル情報３６を参照して、プライマリとして用いる、ノード２０が保有するテーブルポインタ２４と、セカンダリとして用いる自ノードのテーブルポインタ３４とを更新する。

図１１に、共通資源管理テーブル再構築後の状態を示す。ノード３０の共通資源管理テーブル再構築手段は、自ノードがセカンダリとして用いるテーブルポインタを保有するノードになることを宣言する。他のノード２０、４０は、宣言の内容に従って、管理テーブル情報２６、４６におけるセカンダリ（Ｓ）に記録されるノード番号を、ノード番号「１０」からノード番号「３０」に書き換える。また、共通資源管理テーブル再構築手段は、管理テーブル情報３６の参照後、プライマリとして用いるテーブルポインタ２４及びセカンダリとして用いるテーブルポインタ３４の共通資源管理テーブル所在ノードに、ノード番号「３０」を記録する。このようにすることで、以降、共通資源管理テーブルにアクセスするノードは、ノード３０が保有する共通資源管理テーブル３５にアクセスすることになる。

なお、共通資源管理テーブルへのアクセスが不能になったことを複数のノードが検出した場合、複数のノードで、並行して、共通資源管理テーブルの再構築が行われる可能性がある。これを防ぐために、共通資源管理テーブル再構築手段は、共通資源管理テーブルの再構築が終了した旨を、全ノードに通知する。再構築終了の通知を受けたノードは、再構築処理を中止し、作成していた共通資源管理テーブルを破棄する。このようにすることで、共通資源管理テーブルが重複して作成されることを防止できる。

図１２に、ノード立ち上げ時の状態を示す。図１２は、システム内に稼働ノードが存在せず、ノード３０が新たに稼働を開始した状態を示している。ノード３０は、隣接ノードから管理テーブル情報を取得しようとするが、稼働ノードはノード３０のみであるため、管理テーブル情報を取得できない。ノード３０は、共通資源管理テーブルの再構築処理を行い、テーブルポインタ３４、共通資源管理テーブル３５、及び、管理テーブル情報３６を生成する。

ノード３０は、共通資源管理テーブル３５の作成後、作成した時刻ｔ４を共通資源管理テーブル３５に記録する。また、ノード３０は、テーブルポインタ３４の共通資源管理テーブル所在ノードに、自ノードのノード番号「３０」を記録する。最終移動時刻には、共通資源管理テーブルを作成した時刻である時刻ｔ４を記録する。ノード３０は、管理テーブル情報３６のプライマリ（Ｐ）に、自ノードのノード番号「３０」を記録する。セカンダリ（Ｓ）については、空欄（設定なし）にしておく。

図１３に、ノード２０が稼働を開始した状態を示す。図１２に示す状態から、ノード２０が稼働を開始すると、ノード２０は、隣接ノードであるノード３０から管理テーブル情報３６の内容を取得し、その内容を自ノードの管理テーブル情報２６に反映する。このとき取得する管理テーブル情報の内容は、図１２に示す管理テーブル情報３６の内容であり、プライマリ（Ｐ）のみが設定済み（ノード番号「３０」）で、セカンダリ（Ｓ）は設定なしである。

ノード２０は、管理テーブル情報２６のプライマリ（Ｐ）を参照し、ノード３０のテーブルポインタ３４にアクセス可能か否かを調べる。ノード２０は、テーブルポインタ３４の内容を取得し、これを自ノードのテーブルポインタ２４に反映する。すなわち、テーブルポインタ２４の共通資源管理テーブル所在ノードにノード番号「３０」を記録し、最終移動時刻に時刻ｔ４を記録する。その後、ノード２０は、管理テーブル情報２６のセカンダリ（Ｓ）に自ノードのノード番号「２０」を記録する。また、ノード２０は、セカンダリとしても用いるテーブルポインタを保有するノードになることを宣言するブロードキャストを行う。ノード３０は、ノード２０がセカンダリのテーブルポインタを保有するノードになることを宣言することで、管理テーブル情報３６のセカンダリ（Ｓ）に、ノード番号「２０」を記録する。

図１４に、更にノード４０が稼働を開始した状態を示す。図１３に示す状態からノード４０が稼働を開始すると、ノード４０は、隣接ノードから管理テーブル情報の内容を取得し、その内容を自ノードの管理テーブル情報４６に反映する。管理テーブル情報の内容の取得元は、ノード２０の管理テーブル情報２６とノード３０の管理テーブル情報３６のどちらでもよい。システム内には、既に、プライマリとして用いるテーブルポインタ３４と、セカンダリとして用いるテーブルポインタ２４とが存在している。従って、ノード４０内に新たにテーブルポインタを作成する必要はなく、ノード４０は、管理テーブル情報４６のみを有することになる。以降、新たに稼働を開始するノードは、ノード４０と同様に、管理テーブル情報を生成する。

本実施形態の共通資源管理システムは、最小構成として、共通資源管理テーブル移動手段と、テーブルポインタ更新手段とを備える。共通資源管理テーブル移動手段は、共通資源管理テーブルを一のノードから別のノードに移動させる。テーブルポインタ更新手段は、共通資源管理テーブルが移動した際に、テーブルポインタに、移動先のノードの識別情報を記憶する。本実施形態では、共通資源管理テーブル移動手段が共通資源管理テーブルを移動させるので、共通資源管理テーブルが１つのノードに固定されない。このため、共通資源管理テーブルへのアクセスで特定のノードにアクセスが集中することがなく、特定のノードの共通資源管理テーブルを固定する場合に比して負荷分散を期待できる。

特許文献１では、空き資源管理リストを全ノードに巡回させる必要があるので、ノード数に依存して、資源取得に要する時間が長くなっていた。本実施形態では、共通資源管理テーブルを全てのノードに巡回させる必要はないので、ネットワーク規模に依存して、資源取得に要する時間が長くなることはない。また、特許文献１では、各資源使用主体は、空き資源管理リストが巡回してきたタイミングでしか資源を取得することができなかった。本実施形態では、使用中の共通資源管理テーブルを保有するノードを、テーブルポインタを用いて管理しているので、各ノードは、任意の時点で、テーブルポインタを参照して、共通資源管理テーブルにアクセスできる。更に、特許文献１では、資源管理リストを巡回させるために、システム内の個々のノードに対して、論理的に一筆書きできる必要があったが、本実施形態ではそのような制約はない。

また、本実施形態では、共通資源管理テーブルにアクセスしたノードに、共通資源管理テーブルを移動している。共通資源管理テーブルの移動後、移動先のノードは、ローカルアクセスで、共通資源管理テーブルにアクセスできる。例えば、ノードのプロセスが共通資源管理テーブルに対して探索などの処理を行うとき、そのプロセスが、短時間に複数回共通資源管理テーブルにアクセスすることがしばしばある。本実施形態では、共通資源管理テーブルを、アクセスしたノードに移動するので、移動後のアクセスを高速化することができる。その結果として、処理の高速化が可能である。

本実施形態では、共通資源管理テーブルを保有するノードを示すテーブルポインタを、プライマリとセカンダリの２つ用意し、２つのノードがテーブルポインタを保有している。テーブルポインタが失われると、共通資源管理テーブルの所在が不明となって、各ノードは、共通資源管理テーブルにアクセスできなくなる。本実施形態では、プライマリとセカンダリの２つのテーブルポインタがあるので、ノードがダウンすることなどで、プライマリのテーブルポインタが参照できないときでも、セカンダリのテーブルポインタをアクセスして、共通資源管理テーブルを保有するノードの特定が可能である。このように、テーブルポインタを保有するノードを複数設けておくことで、耐障害性の向上を期待できる。

本実施形態では、共通資源管理テーブルにアクセスできなくなると、共通資源管理テーブル再構築手段が、各ノードから共通資源の使用状況を収集し、共通資源管理テーブルを再構築する。共通資源管理テーブル再構築手段が、テーブルポインタに、再構築した共通資源管理テーブルを保有するノードの識別情報を記録することで、各ノードは、再構築された共通資源管理テーブルにアクセスできる。従って、本実施形態では、共通資源管理テーブルを保有するノードがダウンするなどして共通資源管理テーブルへアクセスできなくなったときでも、共通資源管理テーブルを再構築することで、ダウンしたノードを除くシステムの継続運用が可能である。

図１５は、本発明の第２実施形態の共通資源管理システムを示している。共通資源管理システムは、ノード１０ａ、２０ａと、クロスバースイッチ５０とを有する。クロスバースイッチ５０は、ノード間を接続するネットワークスイッチである。クロスバースイッチ５０は、システム用共有レジスタ５１と、ユーザ用共有レジスタ５２とを有する。システム用共有レジスタ５１は、システムが使用するレジスタであり、ユーザ用共有レジスタ５２は、ユーザが分散処理プログラム等で使用可能なレジスタである。

ユーザ用共有レジスタ５２は、複数のノードで共有される共通資源に該当する。システム用共有レジスタ５１は、テーブルポインタ５３を記憶している。システム用共有レジスタ５１は、各ノードから一意にアクセスすることが可能である。各ノードは、記憶領域として、共通資源管理テーブル（ユーザ用共有レジスタフリーリスト）を有する。また、図１５では図示を省略するが、各ノードは、共通資源管理テーブル移動手段、共通資源管理テーブル再構築手段、及び、共通資源管理テーブルアクセス手段を有している。

図１５では、ノード２０ａが、使用中のユーザ用共有レジスタフリーリスト２５を保有しており、テーブルポインタ５３には、共通資源管理テーブル所在ノードに、ノード２０ａのノード番号「２０」が記録されている。第１実施形態では、テーブルポインタを複数のノードに配置し、プライマリとして用いるテーブルポインタを保有するノードと、セカンダリとして用いるテーブルポインタを保有するノードとを、管理テーブル情報を用いて管理した。本実施形態では、テーブルポインタ５３は、クロスバースイッチ５０に固定的に配置されるので、管理テーブル情報は不要である。

テーブルポインタ５３を、クロスバースイッチ５０のシステム用共有レジスタ５１に１つだけ配置するのは次のような理由からである。すなわち、クロスバースイッチ５０が何らかの原因で故障すると、接続されたノード間のアクセスができなくなることに加えて、各ノードは、システム用共有レジスタ５１及びユーザ用共有レジスタ５２にアクセスできなくなる。つまり、テーブルポインタ５３へのアクセスができなくなると共に、共通資源の利用ができなくなる。仮にどこかのノードがセカンダリとして用いるテーブルポインタを保有していたとしても、クロスバースイッチ５０がダウンすると、共通資源を利用することはできない。従って、テーブルポインタに冗長性を持たせる必要はなく、テーブルポインタは、クロスバースイッチ５０に１つあれば十分である。

本実施形態においても、共通資源管理テーブルであるユーザ用共有レジスタフリーリストの移動は、第１実施形態と同じである。つまり、各ノードは、ユーザ用共有レジスタフリーリストへのアクセス時に、自ノードに、ユーザ共有レジスタフリーリストを移動する。従って、本実施形態では、第１実施形態と同様な効果を得ることができる。すなわち、特定のノードに対するアクセスが集中することを防いで負荷分散を図ることができる。また、ユーザ用共有レジスタフリーリストの移動後に同じノードがアクセスする際のアクセスをローカルアクセスとすることができ、処理の高速化が可能である。

本実施形態では、テーブルポインタ５３は、クロスバースイッチ５０内のシステム用共有レジスタ５１に配置している。従って、各ノードが、テーブルポインタの参照時にアクセスするのは、クロスバースイッチ５０までとなる。何れかのノードがテーブルポインタを保有する構成の場合、アクセス元のノードは、クロスバースイッチ５０を通って、アクセス先のノードまでアクセスすることになる。本実施形態では、クロスバースイッチ５０までのアクセスで、テーブルポインタ５３にアクセスできるので、ノードがテーブルポインタを保有する構成に比して、ネットワーク負荷を低減する効果が期待できる。

本実施形態では、テーブルポインタ５３は、クロスバースイッチ５０内に固定的に配置されるので、管理テーブル情報は不要である。管理テーブル情報を用いる場合、ユーザ用共有レジスタフリーリストにアクセスするためには、まず、管理テーブル情報を参照し、テーブルポインタを保有するノードを特定する必要がある。本実施形態では、管理テーブル情報を参照してテーブルポインタを保有するノードを特定する手順を省けるので、ユーザ用共有レジスタフリーリストへのアクセスの高速化が期待できる。

本実施形態では、テーブルポインタ５３をクロスバースイッチ５０に配置している。テーブルポインタを、ノードからクロスバースイッチ５０に移すことで、システムとしての耐障害性のノード依存割合を低下させることができる。これは、クロスバースイッチ５０の耐障害性を上げることで、システムの運用としての耐障害性を上げることができることを意味している。特に、ノード数が多くなる大規模システムでは、テーブルポインタをクロスバースイッチ５０に配置する構成は、有利な構成になる。

また、本実施形態でも、ノードダウン等によりユーザ用共有レジスタフリーリストが失われたときは、共通資源管理テーブル再構築手段が、各ノードにユーザ用共有レジスタ５２の使用状況を問い合わせ、ユーザ用共有レジスタフリーリストの再構築を行う。ユーザ用共有レジスタフリーリストの再構築を行うことで、ダウンしたノードを除くシステムの継続運用が可能である。

なお、上記各実施形態では、各ノードが共通資源管理テーブル移動手段、テーブルポインタ更新手段、及び、共通資源管理テーブル再構築を有しているが、全てのノードがこれら３つの手段を有している必要はなく、最低限、システム内に各手段が１つあればよい。また、共通資源管理テーブル移動手段は、共通資源管理テーブルにアクセスしたノードに共通資源管理テーブルを移動することとしたが、これには限定されない。負荷分散の観点からは、移動先の決定は任意であり、移動先がアクセスしたノードでなくとも、負荷分散の効果は得られる。

以上、本発明をその好適な実施形態に基づいて説明したが、本発明の共通資源管理システム、方法、及び、プログラムは、上記実施形態にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。

本発明は、ＨＰＣ（High Performance Computing）の分野に適用することができる。

１０、２０、３０、４０：ノード
１１、２１：共通資源管理テーブル移動手段
１２、２２：テーブルポインタ更新手段
１３、２３：共通資源管理テーブル再構築手段
１４、２４、３４：テーブルポインタ
１５、２５、３５：共通資源管理テーブル
１６、２６、３６、４６：管理テーブル情報
１７、２７：共通資源管理テーブルアクセス手段
１９、２９：プロセス
５０：クロスバースイッチ
５１：システム用共有レジスタ
５２：ユーザ用共有レジスタ
５３：テーブルポインタ

Claims (25)

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. 前記共通資源管理テーブルを再構築する処理では、前記共通資源管理テーブルを保有するノードへアクセスしたときに当該ノードから応答がないとき、又は、前記テーブルポインタを参照することができないとき、前記共通資源管理テーブルの再構築を行う、請求項２４に記載のプログラム。

Images