(57)【特許請求の範囲】
【請求項１】
複数の資源からなる共有資源の割り当てと当該割り当てた共有資源の返却を管理する共有資源管理手段と、
複数のプロセスを有するプロセスグループにおける前記共有資源の割り当てと返却を管理する管理マスタと、を備え、
前記共有資源管理手段は、
前記管理マスタから当該プロセスグループに割り当てられた資源の仮返却を受け付ける手段と、
他のプロセスグループを管理する他の管理マスタから前記共有資源の取得要求を受け付ける手段と、
前記共有資源中に未使用の資源があるか否かを判定し、未使用の資源がないと判定した場合は、前記仮返却された資源を前記他のプロセスグループに割り当てる割当手段と、
を備えることを特徴とする共有資源管理システム。
【請求項２】
前記管理マスタは、
当該管理マスタが対象とするプロセスグループ中の少なくとも１つのプロセスが当該プロセスグループに割り当てられた資源を返却可能な状態になった場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ仮返却することを特徴とする請求項１に記載の共有資源管理システム。
【請求項３】
前記共有資源管理手段は、
前記仮返却された資源を前記他のプロセスグループに割り当てる場合は、当該仮返却された資源の資源情報の削除を当該仮返却した管理マスタに要求することを特徴とする請求項１または２に記載の共有資源管理システム。
【請求項４】
前記共有資源管理手段は、
前記未使用の資源がないと判定した場合において前記仮返却された資源が複数あるときは、当該複数の仮返却された資源について算定された各情報削除処理コストに基づいて、前記他のプロセスグループに割り当てる資源を選択することを特徴とする請求項１乃至３いずれか１項に記載の共有資源管理システム。
【請求項５】
前記管理マスタは、
当該管理マスタが対象とするプロセスグループ中の全てのプロセスが当該プロセスグループに割り当てられた資源を返却可能な状態になった場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ返却することを特徴とする請求項１乃至４いずれか１項に記載の共有資源管理システム。
【請求項６】
前記管理マスタは、
当該管理マスタが対象とするプロセスグループが消滅した場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ返却することを特徴とする請求項１乃至４いずれか１項に記載の共有資源管理システム。
【請求項７】
複数の資源からなる共有資源の割り当てと当該割り当てた共有資源の返却を管理する共有資源管理手段と、複数のプロセスを有するプロセスグループにおける前記共有資源の割り当てと返却を管理する管理マスタと、を備えるシステムにおける共有資源管理方法であって、
前記共有資源管理手段が、
前記管理マスタから当該プロセスグループに割り当てられた資源の仮返却を受け付けるステップと、
他のプロセスグループを管理する他の管理マスタから前記共有資源の取得要求を受け付けるステップと、
前記共有資源中に未使用の資源があるか否かを判定し、未使用の資源がないと判定した場合は、前記仮返却された資源を前記他のプロセスグループに割り当てる割当ステップと、
を備えることを特徴とする共有資源管理方法。
【請求項８】
前記管理マスタは、
当該管理マスタが対象とするプロセスグループ中の少なくとも１つのプロセスが当該プロセスグループに割り当てられた資源を返却可能な状態になった場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ仮返却するステップを備えることを特徴とする請求項７に記載の共有資源管理方法。
【請求項９】
前記共有資源管理手段は、
前記仮返却された資源を前記他のプロセスグループに割り当てる場合は、当該仮返却された資源の資源情報の削除を当該仮返却した管理マスタに要求するステップを備えることを特徴とする請求項７または８に記載の共有資源管理方法。
【請求項１０】
前記共有資源管理手段は、
前記未使用の資源がないと判定した場合において前記仮返却された資源が複数あるときは、当該複数の仮返却された資源について算定された各情報削除処理コストに基づいて、前記他のプロセスグループに割り当てる資源を選択するステップを備えることを特徴とする請求項７乃至９いずれか１項に記載の共有資源管理方法。
【請求項１１】
前記管理マスタは、
当該管理マスタが対象とするプロセスグループ中の全てのプロセスが当該プロセスグループに割り当てられた資源を返却可能な状態になった場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ返却するステップを備えることを特徴とする請求項７乃至１０いずれか１項に記載の共有資源管理方法。
【請求項１２】
前記管理マスタは、
当該管理マスタが対象とするプロセスグループが消滅した場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ返却するステップを備えることを特徴とする請求項７乃至１０いずれか１項に記載の共有資源管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共有資源管理システム及び共有資源管理方法に係り、特に、ＨＰＣ（High Performance Computing）分野に適用可能な共有資源管理システム及び共有資源管理方法に関する。
【背景技術】
【０００２】
コンピュータの共有資源の割り当てや返却を管理する技術が知られている。下記特許文献１（特開２００１−１９５２６８号公報）には、このような共有資源管理技術の一例として、資源割当手段１２により各資源の資源量を実行要求対象のＡＰに割り当てることができない場合、ＡＰ実行待ち合わせ手段１５が、実行要求対象のＡＰより低いＡＰサービスレベルのＡＰの実行を中断して各資源を解放させ、その解放された各資源を実行要求対象のＡＰに優先的に割り当てて実行させることが記載されている。
【０００３】
また、下記特許文献２（特開２００１−３５６９２１号公報）には、資源空き状況通知手段１ｃが、資源割り当て状況管理手段１ｂを参照して資源の空き状況が変化したことを検知した場合は、ジョブに対してその旨を通知し、資源再割り当て手段１ｅが、資源の再割り当ての要求がジョブからなされた場合は、それらのジョブに対して解放された資源を割り当てることが記載されている。
【０００４】
また、下記特許文献３（特開平６−３４２３７７号公報）には、資源確保管理部６が、プログラム制御文１４により起動されるプログラムの実行開始前に、必要な複数のプログラム使用資源１５を、複数のプロセスにて分散して並列的に確保し、資源解放管理部７は、使用を終えた複数のプログラム使用資源１５を、複数のプロセスにて分散して並列的に開放する処理を管理することが記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−１９５２６８号公報
【特許文献２】特開２００１−３５６９２１号公報
【特許文献３】特開平６−３４２３７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、ＨＰＣ（High Performance Computing）分野のジョブはプロセス群（グループ）によって並列処理で実行され、この並列内容はデータパラレルである場合が多いところ、これらグループの共有資源返却方式として、例えば以下の２つの方式が知られている。
【０００７】
第１の方式は、プロセスからの返却通知をとりまとめ、グループ内で資源の使用者がいなくなった時点でシステムに資源を返却するものであり、例えば「プロセス毎の返却」方式と呼ばれる（図３３を参照）。この方式は、実行中に資源返却が可能であるため、効率よく資源を運用することができる一方、全プロセスによる資源返却処理のとりまとめが必要であるためプロセス数の増大と共に処理コストも増加するという問題がある。
【０００８】
第２の方式は、グループ消滅時に資源を返却するものであり、例えば「グループ消滅時の返却」方式と呼ばれる（図３４を参照）。この方式は、返却処理コストが一定である（プロセス数の影響をうけない）一方、各プロセスが処理の途中で資源を必要としなくなっても処理が終了するまで資源を保持し続けるので効率のよい資源運用ができないという問題がある。
【０００９】
すなわち、第１の方式（プロセス毎の返却方式）と第２の方式（グループ消滅時の返却方式）は、それぞれ、資源運用の効率化と資源返却処理コストがトレードオフの関係にあり、どちらも一長一短である。よって、双方の欠点を解消するとともに双方の利点を両立することができる新たな仕組みが望まれるところ、上述した特許文献１〜３には、かかる課題については何ら考慮されていない。
【００１０】
従って、本発明の目的は、資源運用の効率化と資源返却処理コスト削減を両立することができる共有資源システムを提供することにある。
【課題を解決するための手段】
【００１１】
本発明に係る共有資源管理システムは、複数の資源からなる共有資源の割り当てと当該割り当てた共有資源の返却を管理する共有資源管理手段と、複数のプロセスを有するプロセスグループにおける前記共有資源の割り当てと返却を管理する管理マスタと、を備え、前記共有資源管理手段は、前記管理マスタから当該プロセスグループに割り当てられた資源の仮返却を受け付ける手段と、他のプロセスグループを管理する他の管理マスタから前記共有資源の取得要求を受け付ける手段と、前記共有資源中に未使用の資源があるか否かを判定し、未使用の資源がないと判定した場合は、前記仮返却された資源を前記他のプロセスグループに割り当てる割当手段と、を備える。
【００１２】
また、本発明に係る共有資源管理方法は、複数の資源からなる共有資源の割り当てと当該割り当てた共有資源の返却を管理する共有資源管理手段と、複数のプロセスを有するプロセスグループにおける前記共有資源の割り当てと返却を管理する管理マスタと、を備えるシステムにおける共有資源管理方法であって、前記共有資源管理手段が、前記管理マスタから当該プロセスグループに割り当てられた資源の仮返却を受け付けるステップと、他のプロセスグループを管理する他の管理マスタから前記共有資源の取得要求を受け付けるステップと、前記共有資源中に未使用の資源があるか否かを判定し、未使用の資源がないと判定した場合は、前記仮返却された資源を前記他のプロセスグループに割り当てる割当ステップと、を備える。
【発明の効果】
【００１３】
本発明の共有資源システムによれば、資源運用の効率化と資源返却処理コスト削減を両立することができるようになる。
【図面の簡単な説明】
【００１４】
【図１】仮定システムの概略構成の一例を示す図である。
【図２】複数ジョブが仮定システムを共有する場合の構成を示す図である。
【図３】共有資源管理とグループ管理の一例を説明するための図である。
【図４】共有資源管理とグループ管理の一例を説明するための図である。
【図５】共有資源管理とグループ管理の一例を説明するための図である。
【図６】グループ管理（マスタ）とグループ管理（スレーブ）の一例を説明するための図である。
【図７】グループ管理（マスタ）とグループ管理（スレーブ）の一例を説明するための図である。
【図８】共有資源管理とグループ管理の一例を説明するための図である。
【図９】グループ管理（マスタ）とグループ管理（スレーブ）の一例を説明するための図である。
【図１０】仮定システムの概略構成の一例を示す図である。
【図１１】共有資源管理とグループ管理の一例を説明するための図である。
【図１２】共有資源管理とグループ管理の一例を説明するための図である。
【図１３】共有資源管理とグループ管理の一例を説明するための図である。
【図１４】共有資源管理とグループ管理の一例を説明するための図である。
【図１５】共有資源管理とグループ管理の一例を説明するための図である。
【図１６】共有資源管理とグループ管理の一例を説明するための図である。
【図１７】共有資源管理とグループ管理の一例を説明するための図である。
【図１８】グループ管理（マスタ）とグループ管理（スレーブ）の一例を説明するための図である。
【図１９】グループ管理（マスタ）とグループ管理（スレーブ）の一例を説明するための図である。
【図２０】共有資源管理とグループ管理の一例を説明するための図である。
【図２１】共有資源管理とグループ管理の一例を説明するための図である。
【図２２】共有資源管理とグループ管理の一例を説明するための図である。
【図２３】共有資源管理とグループ管理の一例を説明するための図である。
【図２４】共有資源管理とグループ管理の一例を説明するための図である。
【図２５】共有資源管理とグループ管理の一例を説明するための図である。
【図２６】共有資源管理とグループ管理の一例を説明するための図である。
【図２７】共有資源管理構成の一例を示す図である。
【図２８】資源取得の流れの一例を示すフローチャートである。
【図２９】資源共有の流れの一例を示すフローチャートである。
【図３０】資源取得の流れ（未使用資源なし）の一例を示すフローチャートである。
【図３１】資源返却の流れの一例を示すフローチャートである。
【図３２】共有資源の割り当てとアクセスを説明するための図である。
【図３３】従来の一般的な資源返却方法の一例を説明するための図である。
【図３４】従来の一般的な資源返却方法の一例を説明するための図である。
【図３５】代表返却方法を説明するための図である。
【図３６】本実施形態に係る共有資源管理方法を説明するための図である。
【図３７】本実施形態に係る共有資源管理システムの構成の一例を示す図である。
【図３８】従来の共有資源管理システムの構成の一例を示す図である。
【図３９】本実施形態に係る共有資源管理方法を説明するための図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する場合がある。
【００１６】
本発明が想定する共有資源の使用方法は、共有資源をシステムが管理し、その割り当てはプロセスを束ねたグループ単位とし、1つの共有資源を複数のグループで共有することはないという構成を前提とする。図３２は、このような共有資源の使用方法を示している。当該方法では、グループＡ、Ｂ内の各プロセスＰ１、Ｐ２、Ｐ３は、自身が属するグループが保持する共有資源にのみアクセスが可能である。グループＡ、Ｂ内の各プロセスＰ１、Ｐ２、Ｐ３は、グループが保持する共有資源にアクセスするために、その共有資源に関する情報を保持し、その保持情報をもとに割り当てられた共有資源にアクセスが可能となる。
【００１７】
また、共有資源を使用するシステムは、複数のノード(計算資源)をネットワークスイッチによって接続したシステム（以下「仮定システム」という。）の構成を採用することができる。図１は、このような仮定システムの構成を示している。なお、ノードは物理的、論理的のどちらであってもよい。仮定システム１ａは、各ノード１００ａ〜１１１ａから共通にアクセスすることが可能な共有資源２００ａを装備する。なお、この共有資源２００ａはネットワークスイッチ３００ａに接続する形態、ネットワークスイッチ３００ａ内に装備する形態のどちらでもよい。共有資源２００ａとは、同じ機能を有する複数の資源のことであり、例えば、各ノードから共通にアクセス可能な多数のレジスタ、もしくは共有メモリ等が該当する。
【００１８】
仮定システム１ａの運用形態としては、ある1ジョブが仮定システム１ａの全てを占有する場合と、複数のジョブで仮定システム１を同時に共有する場合がある。図２は、5つのジョブＡ〜Ｅによる仮定システム１ａの共有例を示している。仮定システム１ａを複数のジョブで共有する場合、あるジョブの計算結果が他のジョブの計算結果に影響を及ぼさないことを保証するために、仮定システム１ａは、あるジョブが使用するノードを予めグループ化した上でジョブを実行する。よって仮定システム１ａは、ノードをグループ化する手段と、それを管理する機能を有する。ここで仮定システム１ａによってグループ化されるノードは、ジョブの実行前に用意されるが、ジョブの実行中に、グループに対するノードの追加、削除に関する機能の是非を問わない。
【００１９】
仮定システム１ａを複数ジョブで共有可能な場合、仮定システム１ａに接続された共有資源２００ａは、グループ毎に割り当てられるものであり、グループ間で共有をしないものとする。このため仮定システム１は、共有資源２００ａをグループに割り当てる際、資源を割り当てた結果により、他ジョブの計算結果に影響を及ぼすことがないことを保証する必要がある。よって仮定システム１ａは、共有資源に関して、グループからの「資源の割り当て要求」と「資源の返却要求」を受け付けと、各グループに対して排他的な割り当てを保証するための「共有資源管理」を実行する。
【００２０】
次に、このようなグループが仮定システム１ａに対して、共有資源２００ａの取得を要求し、グループ内の各ノードで共有資源を２００ａ共有し、共有資源２００ａを返却するまでの流れについて説明する。
【００２１】
図３は、共有資源管理テーブル、グループ管理テーブルの構成の一例を示している。同図で示される共有資源は、同じ機能を有する資源を複数個有し、各資源は資源番号で区別される。ここでグループは「グループ管理(マスタ)」と「グループ管理(スレーブ)」によって構成される。グループ管理(マスタ)は、グループ内のグループ管理(スレーブ)を管理し、グループ管理(スレーブ)はノード内のプロセスを管理する。
【００２２】
共有資源管理（「共有資源管理手段」ともいう）における各資源の管理情報は、例えば、グループへの割り当て状況を示すフラグ「状態」、資源を割り当てたグループの管理情報をもつノード番号を保持する「グループ管理ノード」、グループを識別する「グループID」である。例えば図3では、資源番号1の共有資源は、「状態」が「使」であるため割り当てがされており、割り当てたグループは「グループID」に記載された「X」で、グループを管理するテーブル(グループ管理(マスタ))の所在ノードは「グループ管理ノード」に記される「#05」であることが示されている。また、ここで「状態」が「未」である共有資源は、割り当てされていない未使用資源を意味する。
【００２３】
グループ管理(マスタ)（「グループ管理手段（マスタ）」ともいう）は、当該ジョブが他ジョブの計算結果に影響を与えないことを保証するために組まれるグループを管理する。保持情報は、グループを識別するための「グループID」、当該グループに所属するノード情報を保持する「参加ノード情報」、グループがシステムより割り当てられた共有資源の番号と、その資源を使用するノードの数をカウントする「保有共有資源情報」である。例えば図3では「グループID」は「X」で、当該グループは「#04、 #05、 #06、 #07」の4ノードから構成されており、共有資源1を保有し、その共有資源を使用しているノードは3ノードであることが示されている。ここで保有共有資源情報の共有数に関して、使用ノード数の管理は行なうが、使用ノード番号の情報は管理しない。これは保持可能な共有資源毎に、使用ノード情報をもつ場合、参加ノード数が多い大規模グループでは、その管理テーブルが巨大になるためである。グループ管理(マスタ)において、共有資源の「管理」として必要とされる情報は、共有資源を仮定システムに返却するタイミングを判断する情報であり、それはグループ内で共有資源の使用者がいなくなったときである。そのため、使用者数の管理のみでよい。
【００２４】
グループ管理(スレーブ)（「グループ管理手段（スレーブ）」ともいう）は、各ノードが、どのグループに属するかを管理する。保持情報は、所属グループを識別するための「グループID」、グループ管理の「マスタ」が存在するノード番号を保持する「マスタノード」、当該ノードが使用できる共有資源番号を保持する「共有資源番号」である。例えば図3では、「グループID」は「X」であり、グループ管理のマスタはノード「#05」に存在し、当該ノードが使用できる共有資源は1番の共有資源である。
【００２５】
以上の管理テーブルを用いて、共有資源の取得について説明する。図４は、初期状態を示している。以下、グループID「X」をもつグループを「グループX」と呼ぶ。今、グループXは、当該グループに属するノードが「#04、 #05、 #06」の3ノードで構成されており、グループが保有する資源として共有資源1を保持している。共有資源1はグループ内の各ノードから使用可能な状態にあるため、その共有数は3である。また各ノードのグループ管理(スレーブ)の状態は、現在、みな同じであるため、代表として1つだけを示している。この状態でグループXが新たに共有資源を保有する場合、グループ管理(マスタ)は仮定システム１の「共有資源管理」に対して、共有資源の割り当てを要求する(図4-(1))。続いて「共有資源管理」は要求に応えるために、共有資源管理テーブルを探索し、未使用資源として共有資源2を見つける(図4-(2))。資源を割り当てるために、共用資源管理テーブル上の共有資源2に対応する情報を「状態：未→使」、「グループ管理ノード：#05」、「グループID：X」に変更する(図5-(3))。「共有資源管理」は割り当て共有資源の番号2を、割り当て要求したグループ管理(マスタ)に通知する(図5-(4))。グループ管理(マスタ)は、通知された共有資源番号2を自身の管理テーブルに登録する(図5-(5))。このとき共有資源2はグループとして所有されただけであり、各ノードから、その資源の使用の申し出を受けていないため、共有数は0である。続いてグループ管理(スレーブ #04)が、共有資源2を使用するために、グループ管理(マスタ)に対して、共有資源2の共有を要求する(図6-(6))。グループ管理(マスタ)は、グループ管理(スレーブ #04)からの要求に応えるために、管理テーブルの共有資源2に対応する共有数を1加算し(図6-(7))、共有番号2をグループ管理(スレーブ #04)に通知する(図6-(8))。要求の応答を受けたグループ管理(スレーブ #04)は、返却値である共有資源番号2を自身の管理テーブルに登録する(図6-(9))。
【００２６】
以上の手順を経て、グループ管理(スレーブ #04)のノードから共有資源2へアクセスすることが可能となる(図6-(10))。この時点でグループ管理(スレーブ #04)のノードは、自身の管理テーブルに登録された共有資源1と共有資源2にアクセス可能であるが、グループ管理(スレーブ #05)とグループ管理(スレーブ #06)のノードは、自身の管理テーブルに共有資源2の情報が無いため、同共有資源にアクセスすることはできない。使用を希望する場合は、グループ管理(スレーブ #04)と同様の手順を踏んで、自身の管理テーブルに情報を登録することが必要である。
【００２７】
続いて、共有資源の返却について説明する。図7はグループXが保持する共有資源2に関して、資源の返却における初期状態を示したものである。グループXが所有する共有資源2の共有数は2であり、グループ管理(スレーブ #04)とグループ管理(スレーブ #05)によって共有されている。この状態でグループ管理(スレーブ #04)のノードは共有資源2の使用を終えたため、その資源の返却要求処理を開始する(図7-(1))。同処理において、まず始めに、自身の管理テーブルに登録された共有資源2に関する情報を削除する(図7-(2))。続いて、グループ管理(スレーブ #04)は、グループ管理(マスタ)に対して共有資源2の使用終了を通知する(図7-(3))。通知を受けたグループ管理(マスタ)は、管理テーブルの共有資源2に対応する共有数を1つ下げる(図7-(4))。共有数変更した後の値は1であり、同資源の使用者がまだ存在するため、共有資源管理に共有資源2を返却せずに保持し続ける。これにより共有資源2に対して、グループ管理(スレーブ #04)のノードからアクセスすることはできないが、グループ管理(スレーブ #05)のノードからアクセスすることは依然として可能である。続いてグループ管理(スレーブ #05)のノードも共有資源2の使用を終え、資源の返却要求処理を開始する(図8-(5))。これまでの手順同様に、自身の管理テーブルから共有資源2に対応する情報を削除し(図8-(6))、グループ管理(マスタ)に対して、共有資源2の返却を通知する(図8-(7))。通知を受けたグループ管理(マスタ)は、管理テーブルから共有資源2に対応する共有数を1つ下げる(図8-(4))。共有数を変更した結果、その値は0であるため、グループ内に共有資源2の使用者がいないことが分かる。よってグループ管理(マスタ)は、共有資源2を、仮定システム１の共有資源管理手段に返却する処理を開始する。まず始めにグループ管理(マスタ)は、自身の管理テーブルから共有資源2に対応する情報を削除する(図8-(5))。続いて、グループ管理(マスタ)は、共有資源管理手段に対して、共有資源2の返却を通知する(図8-(6))。通知を受けた共有資源管理手段は、自身の管理テーブルから共有資源2に対応する情報に対して、状態を「使→未」へ変更し、その他の情報を削除する(図8-(7))。この時点で共有資源2に関する情報は、仮定システム１内のどのノードも保持しておらず、割り当てが解消された状態となる。よって今後の要求に応じて、同資源は再度割り当て可能となる。
【００２８】
ここで、以上のような共有資源管理方法においては、次に述べるような問題がある。上述したように、HPC分野では、実行時間短縮のために並列処理が一般的であり、この並列処理は、各プロセスが同じ動作を行なうデータパラレル方式である場合が多いところ、グループが所有する共有資源の使用期間も各プロセスで同等であるため、各プロセスによる共有資源の使用終了もほぼ同じタイミングで発生する。ここで、プロセスによる資源使用終了は、グループ管理(スレーブ)によってグループ管理(マスタ)に通知されるが、データパラレル方式では、時間的空間的にもグループ管理(マスタ)にアクセスが集中してしまう。そこで、全グループ管理(スレーブ)の使用終了報告を待たずに、特定のグループ管理(スレーブ)の使用終了報告をもって、システムに資源返却するという方法も考えられるが、HPC分野では、従来の資源管理方法による返却方式も必要であるため、新たな方式は、従来方式と同時に使用が可能であることが望ましい。換言すれば、1つのプログラム内で従来方式と新方式の混在使用ができれば望ましい。
【００２９】
また、多数のノードから構成されるグループ(システム全体を占有するような大規模ジョブ)において、ジョブ実行途中に共有資源を解放する場合、返却要求はネットワークを通じて行なわれるため、システム内の全体的なネットワーク負荷を高めてしまうという問題がある。また、グループ管理(マスタ)は、1箇所にあるため、ネットワークに局所的な高負荷をもたらす(図9参照)。また、これらの要求はグループ管理(マスタ)の管理テーブルを更新することを伴う処理であるところ、当該処理は、管理テーブルの一貫性を保つため並列に処理することはできず、順次処理となるため、グループ規模が大きく、共有数の多い資源の解放は、時間的に大きな処理コストを伴うなどの問題もある。
【００３０】
これらの問題を回避する簡易な方法としては、一度保有した共有資源を、ジョブが終了するまで保持し続け、グループの終了処理の際に一緒に資源返却を行なうことが考えられる。一般に仮定システムがもつ共有資源の数は限りがあり、その数も少ないが、仮定システムをジョブが占有している状態では、資源を返却しても、その資源を要求する者がいなため、ジョブの終了まで保持し続けても問題はないからである。よってシステム占有状態の大規模ジョブにおいて、ジョブ終了まで共有資源を保持し続けることは、共有資源の返却コスト削減となる。
【００３１】
一方、少数のノードから構成されるグループが、仮定システム内に多数存在する場合には(図2参照)、共有資源の不足が考えられるため、このような小規模ジョブにおいては、ジョブ実行中においても、小まめな共有資源返却が望ましい。共有資源返却コストから見た場合においても、グループを構成するノード数が少ないため、返却に伴うネットワーク使用箇所も局所的であり、グループ管理(マスタ)のノードに対する一極集中も、大規模ジョブに比べて、その度合いはかなり小さくなる。
【００３２】
すなわち、仮定システムは、稼動率の面から見て、同じシステムが大規模ジョブと小規模ジョブの2つの種類のジョブに対応する必要があるものの、共有資源管理に関して、その要求は相反する。また、資源返却の効率は、ユーザプログラムにゆだねられているともいえる。例えば自身のプログラムが大規模ジョブであるにも関わらず、小まめな共有資源返却を行なうならば、それはジョブの実行時間は不必要に長くなり、システムを浪費していることになる。逆に自身のジョブが小規模ジョブであるにも関わらず、共有資源を不必要に保持し続けるならば、同時に実行可能なジョブ数が減り、計算資源の有効活用が困難になるかもしれない。このようにユーザが自身のジョブの大小を判断してプログラムを作成することは、望ましい状況ではなく、システムが現状に応じて判断することが好ましい。
よって、データパラレル方式のプログラム実行時における共有資源の返却処理コストを削減する(すなわち、マスタ一極集中を緩和する)ことができる共有資源システムを提供することが望まれる。
【００３３】
また、共有資源返却に関して従来方式と新方式を相互運用することができる共有資源システムを提供することが望まれる。
【００３４】
また、システムの状況に合わせて共有資源を効果的に運用することができる共有資源システムを提供することが望まれる。
【００３５】
なお、本発明は、上述のHPC分野で使用されることを想定しており、より具体的には、複数のプロセスからなるプロセス群(グループ)で構成されること、グループ内での共有資源はメモリ・レジスタ等であること、及び、各プロセスの処理がほぼ同じである(資源の返却タイミングが同じ)データパラレル方式であることを前提としている。
【００３６】
本発明は、上記の特徴を活かして、グループ内の代表プロセスの返却処理のみで資源を返却できる「代表返却方式」を採用する。ただし、この方式を単純に適用すると、図35で説明するような管理不正を発生させる場合がある。そこで、本発明は、この問題を解決する手段として、従来2方式のどちらにも遷移可能な中間状態である「仮返却」(図39参照)という状態を新たに設ける。図39で示すように、「仮返却」状態の資源割り当ては、従来方式の状態に遷移させたのちに行なうので、管理不正の問題は発生しない。また「仮返却」状態は従来方式へ遷移する前の中間状態なので、同じ管理テーブルで従来方式の運用も可能である。この理由によって従来プログラムの実行も可能となっている。すなわち、後述するように、本発明によれば、「仮返却」を行なう新設の資源返却インターフェースを用意することで、1つのグループ管理(スレーブ)の返却処理で資源返却が可能になる。また、1つの共通資源管理テーブルで「従来インターフェース」と「新設インターフェース」の処理の対応が可能であるため、従来方式と新方式で同時使用が可能になる。また、「仮返却」により資源要求が行なわれるまで、実質的な情報削除処理が遅延されるため、システムの稼働状況に合わせた共有資源の割り当て処理が可能になる。
【００３７】
図37は、本実施形態に係るシステムの概略構成を示す図である。なお、従来技術は、図38に示されている。本発明は、従来の返却方法に、「仮返却」状態を生成する処理経路（「処理手段」ともいう）である「仮返却」（「仮返却手段」ともいう）を新設したものであり、新設経路による管理の不整合を解決するために「仮返却資源情報削除要求」５０５（「仮返却資源情報削除要求手段」ともいう）と「仮返却資源情報削除手段」６０１の処理経路を追加した構成をとる(図37の斜線経路を参照)。ここで「仮返却」状態とは、図39で示すように、従来の2つの返却方法に遷移することができる中間状態を意味する。
【００３８】
図37で示すように、グループＡ６００の「仮返却」６０２の斜線経路によって共有資源管理５００（「共有資源管理手段」ともいう）に返された共有資源は、返却要求受付５０１により受け付けられ、従来の状態と異なる「仮返却」という状態で共有資源管理５００によって管理される。またグループＢ７００の「資源要求／情報登録手段」７０１からの資源要求を割り当て要求受付５０４が受け付けて、共有資源管理５００が、仮返却状態の資源をグループに割り当てる場合、「仮返却資源情報削除要求」５０５と「仮返却資源情報削除手段」６０１を経由する斜線経路により、プロセスがもつ「仮返却」状態資源の情報を削除したのちに、割り当てを行なう。これは図39で「プロセス毎の返却」に遷移したことと同等である。また仮返却状態の資源が割り当てられる前にグループが消滅した場合、その資源の状態は未使用資源に移行する。これは図39で「グループ消滅時返却」に遷移したことと同等である。
【００３９】
以下、共有資源を管理テーブルにより管理する場合の詳細な実施例の構成について説明する。本実施例では、共有資源管理の資源の状態(図3の共有資源管理の「状態」)として、次の3つを定義する。第１の状態は「使」であり、対象共有資源がグループに割り当てられている状態(使用中)を意味する。第２の状態は「未」であり、対象共有資源がどのグループにも割り当てられていない状態(未使用)を意味する。第３の状態は「仮」であり、対象共有資源はグループからシステムに返却されているが、グループ内のノードが対象共有資源の情報を保持していることを意味する。
【００４０】
図10は、仮定システム１、共有資源２００、共有資源管理テーブル４００、グループ、グループＸ内における各管理テーブル（１００ｍ、１００ｓ、１０１ｓ、１０２ｓ）の配置について示したものである。図10において、共用資源２００はネットワーク３００に接続された物理的に孤立した存在として示されているが、これは便宜上の表記である。従って各ノード（１００〜１１１）で共有可能なものであれば、その存在はノードの内外を問わない。また共有資源管理テーブル４００も同様に示されているが、これも「共有資源管理」がアクセス可能な位置にあれば、ノードの内外を問わない。
【００４１】
「共有資源」とは、ある機能を有する資源が複数集まったものである。例えばネットワーク上に存在し、各ノードよりアクセス可能なレジスタが複数存在する等である。
【００４２】
「共有資源管理」（「共有資源管理手段」ともいう）とは、上記共有資源の個々を管理する機能を有する。各グループ管理(マスタ)より「共有資源の割り当て要求」、「共有資源の返却」の通知を受け、実際の処理を行なう。「共有資源情報削除要求」をグループ管理(マスタ)に要求する役割も担う。
【００４３】
「グループ管理(マスタ)」（「グループ管理手段(マスタ)」ともいう）とは、グループ内の「グループ管理(スレーブ)」を管理する機能を有する。グループに参加しているノードの番号、グループが保有している共有資源の番号等を管理する。グループ管理(マスタ)のみが、仮定システムに対して「共有資源の割り当て要求」と「共有資源の返却」を行なうことができる。また仮定システム１より「共有資源情報削除要求」を受け、処理の完了を仮定システムに通知する役割もグループ管理(マスタ)が行なう。
【００４４】
「グループ管理(スレーブ)」（「グループ管理手段(スレーブ)」ともいう）とは、ノード内において、グループに属するプロセスを管理する機能を有する。またそのプロセスがアクセス可能な共有資源情報も管理する。グループ管理(スレーブ)がグループ管理(マスタ)に「資源共有」を要求することによって、グループ管理(スレーブ)に共有資源の情報が登録され、同資源にアクセスが可能となる。よって、プロセスはグループ管理(スレーブ)に登録された共有資源にのみアクセスが可能であり、グループ管理(スレーブ)はグループ管理(マスタ)が保有する共有資源の情報のみ登録することが可能であるため、プロセスは、グループが保有する共有資源以外の共有資源にアクセスすることはできない。またグループ管理(スレーブ)は、直接、「共有資源管理」に問合せすることはできない。グループ管理(スレーブ)がグループ管理(マスタ)に要求し、グループ管理(マスタ)が共有資源管理に問合せする形態になる。ここでグループ管理(スレーブ)はプロセスを管理するものであるが、本実施例では、説明の便宜上、グループ管理(スレーブ)を末端として説明し、その管理を管理テーブルにおいて省略している。
【００４５】
図11は、各管理テーブルの内容の一例を示したものである。各列の意味は、以下の通りである。
【００４６】
まず、共有資源管理の管理テーブルについて説明する。「資源番号」とは、管理対象の共有資源に振られた一意な番号である。「状態」とは、共有資源の割り当て状況である。「使」はあるグループに資源を割り当てている状態である。「未」はどのグループにも資源を割り当てておらず、すぐに割り当て可能な状態である。「仮」は資源割り当て可能であるが、割り当て前に「共有資源情報削除処理」を必要とする状態である。「情報削除処理コスト」は、共有資源情報削除処理」を行なう場合の処理コスト値である。「グループ管理ノード」は、そのグループを管理する「グループ管理(マスタ)」が存在するノード番号である。「グループID：仮定システム内でグループを一意に識別するためのIDである。
【００４７】
ここで「情報削除処理コスト」はとは、「仮」状態の資源が複数あった場合、どれか1つを選択するための指標であり、値が小さいほど割り当てるときの処理コストが小さくなるような評価指標とする。以下の指標の例を示す。
情報削除処理コスト = a + b
a = α *グループに参加しているノード数
b = β *資源の共有数
aはグループ管理(マスタ)がグループ内の各グループ管理(スレーブ)に削除要求を行なうときの通信コストであり、bは各グループ管理(スレーブ)から削除完了を行なうときの通信コストである。またa、bにおけるαとβは重み係数であり、実行システムの状態に合わせて適切に設定される値である。実行システム依存であるため、本実施例はこの値を特定しない。この重みの決め方の一例として、パケット数などがある。グループ管理(マスタ)からグループ管理(スレーブ)に送信される情報削除要求にかかるパケット数を3、グループ管理(スレーブ)からグループ管理(マスタ)に送信される完了通知にかかるパケット数を1とするならば、α=3、β=1とすることが考えられる。以下、本実施例では、説明の便宜上、α=1、β=1として動作説明を行なうが、値はこれらに特定されない。
【００４８】
次に、グループ管理(マスタ)の管理テーブルについて説明する。「グループID」は、仮定システム内でグループを一意に識別するためのIDである。「参加ノード情報」は、そのグループに参加しているノードの番号である。各ノードは仮定システム内で一意な値が割り振られている。「保有共有資源情報」は、その分子はそのグループが保有する(仮定システムによって割り当てられた)共有資源番号であり、その分母はグループ内でその資源情報をもつグループ管理(スレーブ)の数である。
【００４９】
次に、グループ管理(スレーブ)の管理テーブルについて説明する。「グループID」は、仮定システム内でグループを一意に識別するためのIDである。「マスタノード」は、グループ管理(スレーブ)が属するグループにおいて、グループ管理(マスタ)がいるノード番号である。「共有資源番号」は、グループ管理(スレーブ)のノードからアクセス可能な共有資源の番号である。グループ管理(マスタ)に情報が登録されていても、グループ管理(スレーブ)に情報がない場合、プロセスは共有資源にアクセスできない。
【００５０】
図27に本実施例の管理構成を示す。まず、グループ管理(スレーブ)について説明する。「共有要求」（「共有要求手段」ともいう）は、グループが保持する共有資源の使用をマスタに要求する手段である。「資源登録削除」（「資源登録削除手段」ともいう）は、共有資源の情報を自身の管理テーブルに登録・削除を行なう手段である。「使用終了通知」（「使用終了通知手段」ともいう）は、自身が指定共有資源の終了をマスタに通知する手段(従来方式と発明方式の2手段あり)である。「情報削除通知」（「情報削除通知手段」ともいう）は、自身の管理テーブルから指定された共有資源の情報を削除したことをマスタに通知する手段である。
【００５１】
次に、グループ管理(マスタ)について説明する。「資源要求」（「資源要求手段」ともいう）は、グループの代表として共有資源管理に共有資源の割り当てを要求する手段である。「資源登録削除」（「資源登録削除手段」ともいう）は、共有資源の情報を自身の管理テーブルに登録・削除を行なう手段である。「テーブル更新」（「テーブル更新手段」ともいう）は、自身の管理テーブルの情報を更新する手段である。「資源返却」（「資源返却手段」ともいう）は、指定した共有資源を共有資源管理テーブルに返却する手段（従来方式と発明方式の2手段あり)である。「情報削除要求」（「情報削除要求手段」ともいう）は、指定した共有資源の情報削除をスレーブに要求する手段である。「情報削除通知」（「情報削除通知手段」ともいう）は、グループ内で指定された共有資源の情報削除が完了したことを共有資源管理に通知する手段である。
【００５２】
次に、共有資源管理について説明する。「資源探索」（「資源探索手段」ともいう）は、自身の管理テーブルから未使用資源、仮解放資源を探索する手段である。「テーブル更新」（「テーブル更新手段」ともいう）は、指定共有資源の管理情報を更新する手段である。「情報削除要求」（「情報削除要求手段」ともいう）は、指定した共有資源の情報削除をグループ管理(マスタ)に要求する手段である。
【００５３】
次に、以上のように構成される仮想システム１の動作について説明する。
【００５４】
まず、「１．共有資源の要求(未使用資源がある場合)」の動作について説明する。図12はグループRが共有資源の割り当てを要求した場合の処理手順を示したものである。対応フローは図28である。この条件では、まだ割り当てられていない未使用資源がある場合を仮定している。これは共有資源管理テーブルにおいて、状態が「未」である資源が存在することを意味し、該当する共有資源は資源番号3である。このときノード番号55であるグループRのグループ管理(マスタ)が共有資源の割り当てを要求する場合の手順を以下に示す。
【００５５】
グループ管理(マスタ)は共有資源を得るために、共有資源管理に「共有資源割り当て要求」を送信する(図12-(1))（図28のＳ１）。要求を受け取った共有資源管理は自身が管理する「共有資源管理テーブル」から、状態が「未」である資源をさがす(図12-(2))（図28のＳ２）。探索の結果、資源番号3が該当することを見つけ（図28のＳ２の「有」）、割り当てを行なうために管理情報である状態を「使」、グループ管理ノードを「#55」、グループIDを「R」に更新する(図12-(3))（図28のＳ４）。その後、情報を更新した資源番号3を、共有使資源の割り当て要求を行なったグループ管理(マスタ)に通知する(図12-(4))（図28のＳ５）。共有資源管理より資源番号を通知されたグループ管理(マスタ)は、自身が管理する「グループ管理(マスタ)テーブル」に、通知された資源番号3とその共有数0を登録する(図12-(5))（図28のＳ６）。以上の手順を行なった後の各テーブルの状態を図13に示す。
【００５６】
次に、「２．グループ内における共有資源の共有」に関する動作について説明する。図14はグループが保有する共有資源を、グループ内のグループ管理(スレーブ)により共有する場合の処理手順を示したものである。対応フローは図29である。この条件において、ノード番号55であるグループ管理(マスタ #55)は保有共有資源として資源番号3の共有資源をもつ。このときノード番号57であるグループ管理(スレーブ #57)が、この共有資源の共有を要求する場合の処理手順を以下に示す。
【００５７】
グループ管理(スレーブ)はグループが保有する資源の共有をグループ管理(マスタ)に要求する(図14-(1))（図29のＳ１１）。要求を受けたグループ管理(マスタ)は資源番号3に対応する保有共有資源情報の「共有数」を１つ増やす(図14-(2))（図29のＳ１２）。更新後、グループ管理(マスタ)は、共有を要求したグループ管理(スレーブ)に共有資源番号3を通知する(図14-(3))（図29のＳ１３）。通知を受けたグループ管理(スレーブ)は、自身が管理する「グループ管理(スレーブ)テーブル」に共有資源番号3を登録する(図14-(4))（図29のＳ１４）。以上の手順を行なった後の各テーブルの状態を図15に示す。
【００５８】
次に、「３．共有資源の要求(未使用資源がない場合)」に関する動作について説明する。図16はグループXが共有資源の割り当てを要求した場合の処理手順を示したものである。対応フローは図30である。この条件では、共有資源管理テーブル上に未使用資源はなく、割り当て可能な資源として「仮返却」された資源のみがある場合を仮定している。これに該当する資源は共有資源管理テーブルにおいて、状態が「仮」である資源番号2と4である。このときノード番号00であるグループ管理(マスタ)が共有資源の割り当てを要求する場合の手順を以下に示す。
【００５９】
グループ管理(マスタ)は共有資源を得るために、共有資源管理に「共有資源割り当て要求」を送信する(図16-(1))（図30のＳ２１）。要求を受け取った共有資源管理は自身が管理する「共有資源テーブル」から、状態が「未」である資源をさがす(図16-(2))（図30のＳ２２）。探索の結果、「未」の資源が見つからなかったので（図30のＳ２３の「無」）、続いて「仮」の資源をさがす(図16-(3))（図30のＳ２４）。探索の結果、資源番号2と4が見つかる(図16-(4))（図30のＳ２５の「有」）。資源番号2と4の「情報削除処理コスト」値を比較して、最も小さな値をもつ資源番号4を割り当て候補として選択する(図16-(5))。共有資源管理は資源番号4を仮返却したグループZのグループ管理(マスタ)に対して、資源番号4の「共有資源情報削除」を要求する(図17-(6))（図30のＳ２６）。要求を受け取ったグループZのグループ管理(マスタ)は、自身が管理する管理テーブルの「参加ノード情報」をもとに、グループの全グループ管理(スレーブ)に対して「共有資源番号4の情報削除」を要求する(図18-(7))（図30のＳ２７）。グループ管理(マスタ)は情報の削除要求を送信した後、各グループ管理(スレーブ)からの削除完了通知を待つ。要求を受け取ったグループZの各グループ管理(スレーブ)は、自身が管理する管理テーブルから共有資源番号4の情報を削除する(図18-(8))（図30のＳ２８）。情報を削除したグループZの各グループ管理(スレーブ)は処理の完了通知をグループZのグループ管理(マスタ)に通知する（図30のＳ２９）。ここで削除要求対象である資源番号4の情報をもたないグループ管理(スレーブ)は何もしない。グループZのグループ管理(マスタ)が待つ各グループ管理(スレーブ)からの完了通知数は、情報削除対象である資源の「共有数」である。この数の完了通知を受け取ることで、グループ内において、対象資源の情報をもつグループ管理(スレーブ)の存在しないことが保証される(図19-(10))。よってこの時点で情報削除対象の資源に関する情報は、グループZのグループ管理(マスタ)のみが保持しており、自身が管理するテーブルから情報を削除することで、仮定システム内において、対象資源の情報をもつノードは存在しないことが保証される(図19-(11))（図30のＳ３０）。処理が完了したグループZのグループ管理(マスタ)は「情報削除完了」を共有資源管理に通知する(図20-(12))（図30のＳ３１）。通知を受けた共有資源管理は、資源番号4の情報を未使用状態に変更する(図20-(13))。この時点で資源番号4は未使用となったため、割り当てが可能となる。よって資源番号4をグループXに割り当てるため、管理情報を使用状態に更新する(図21-(14))（図30のＳ３２）。更新後、グループXのグループ管理(マスタ)に、割り当て共有資源番号4を通知する(図21-(15))（図30のＳ３３）。通知を受けたグループXのグループ管理(マスタ)は、自身が管理する管理テーブルの保有共有資源情報に「4/0」を登録する(図21-(16))（図30のＳ３４）。以上の手順を行なった後の各テーブルの状態を図22に示す。
【００６０】
次に、「４．共有資源の仮返却(スレーブが仮返却する場合)」に関する動作について説明する。図23はグループ管理(スレーブ)が共有している共有資源をグループ管理(マスタ)に仮返却する場合の処理手順を示したものである。対応フローは図31である。この条件では、返却予定の資源に、返却者以外の共有者がいる。よってここでは、グループ管理(マスタ)が共有資源管理に対して行なう返却が「仮返却」となる場合を仮定している。このときグループXのノード番号#02のグループ管理(スレーブ)が、自身が共有する共有資源番号1の資源返却を要求する場合の手順を以下に示す。
【００６１】
グループ管理(スレーブ)は自身が共有する共有資源番号1の資源仮返却を希望する。まず始めに自身の管理テーブルから共有資源番号1の情報を削除する(図23-(1))（図31のＳ６１）。返却を希望するグループ管理(スレーブ)は、グループ管理(マスタ)へ、共有資源番号1の仮返却を要求する(図23-(2))（図31のＳ６２）。要求を受けたグループ管理(マスタ)は、共有資源番号1に対応する「保有共有資源情報」の「共有数」を1つ下げ、「仮」の印をつける(図23-(3))（図31のＳ６３）。その後、グループ管理(マスタ)は共有資源管理へ共有資源1の仮返却を通知する（図31のＳ６４、Ｓ６５）。このとき「情報削除処理コスト」値も通知するが、説明の便宜上、α=1、β=1としているので、値は5となる(図23-(4))。通知を受けた共有資源管理は資源番号1の状態を「仮」、情報削除処理コストを「5」に更新する（図31のＳ６６）。以上の手順を行なった後の各テーブルの状態を図24に示す。
【００６２】
次に、「５．共有資源の返却(マスタが返却する場合)」に関する動作について説明する。図25はグループ管理(マスタ)が保有する共有資源を共有資源管理に通常返却する場合の処理手順を示したものである。対応フローは図31である。グループ管理(マスタ)が共有資源を返却する場合は共有数が1から0になった場合とグループが消滅する場合である。どちらもグループ管理(スレーブ)が発端となるが、グループ管理(マスタ)から見ると、どちらも共有数が0になったときに返却することに変わりはないので、説明手順は共有数が0になったところから始め、発端のグループ管理(スレーブ)の動作は省略する。同図ではグループXが消滅する場合の資源返却を仮定したもので、グループ管理(マスタ)が保有する資源番号1と4の返却が必要となる。しかし各資源の返却手順は同じであるため、資源番号1の返却手順のみを以下に示す。
【００６３】
グループ管理(マスタ)はグループ消滅に伴い、保有共有資源の返却処理を開始する。保有共有資源は2つあるが、1つずつ返却されるため、共有資源番号1に着目する。グループが消滅する場合、参加ノードはもはやいない。よって資源の共有数は0である（図31のＳ４８の「０」）。グループ管理(マスタ)は自身の管理テーブルから共有資源1に関する情報を削除する(図25-(1))。これからグループが消滅し、テーブルが放棄されるので情報削除処理は必要ないが、グループ消滅以外でも資源返却は可能であり、その手順との共通性を意識して、この処理を行なう。削除処理を行なった後、グループ管理(マスタ)は、共有資源管理へ共有資源番号1の返却を通知する(図25-(2))（図31のＳ４９）。通知を受けた共有資源管理は、資源番号1の管理情報を未使用として更新する(図25-(3))（図31のＳ５０）。以上の手順を共有資源番号4に対しても行なう。以上の手順を行なった後の各テーブルの状態を図26に示す。
【００６４】
次に、従来の管理法との共存について説明する。本発明は、従来返却法(従来法ともいう)としても動作可能である。例えば、共有資源返却用の手続き手段(インターフェース)を以下のように2つ用意する。
１. freeOld()
２. freeNew()
freeOld()は従来法のための手続き手段であり、freeNew()は発明法のためのインターフェースとする。freeNew()を使用する場合は、これまで説明した手順で管理を実行する。従来法のfreeOld()を使用する場合は、単に従来通りに共有数が0になった段階で共有資源管理に資源を返却すればよい。単に本発明において「仮返却」という中間状態を除いた管理を行なえばよいだけであり、特別な追加処理は必要ない。
【００６５】
よって本発明を適用したシステムにおいても、プログラムの変更なしに、従来法のインターフェースによって書かれたプログラムの実行が可能である。
また従来のプログラムに対して、従来方式のインターフェースで新方式の処理を適用することも可能である。例えば従来方式のライブラリと新方式のライブラリを用意し、これらをダイナミックリンクライブラリとする。実行時にユーザが環境変数等で指定することでリンクするライブラリを変更する方法で、従来方式のインターフェースにおいても新方式の処理が可能となる。
【００６６】
HPCのプログラムはデータパラレルによりプロセスごとに同じ処理を行なうと仮定しているが、ネットワーク遅延やCPU数以上のプロセス実行によるプロセス切り替え、割り込み等が原因で処理タイミングがずれる場合が考えられる。よって従来方式で書かれたプログラムに対してそのまま新方式を適用すると、実行タイミングのズレにより資源解放されているにも関わらず資源を使用しているプロセスが発生する場合が考えられる。この場合の対策として、以下の4つが考えられる。
【００６７】
第１の対策として、情報削除要求が来た場合、使用状況に関わらず強制的に情報を削除するようにしてもよい(資源を使用していたジョブはアボートになる)。
【００６８】
第２の対策として、各プロセスが共有資源の使用状態をノード内で管理し、情報削除要求が来た場合、まだ使用していることを通知することで要求を拒否するようにしてもよい。拒否された共有資源管理は本「仮返却」資源の割り当てをあきらめ、次ぎの候補の「仮返却」資源に対して「情報削除要求」を行なう。
【００６９】
第３の対策として、各プロセスが共有資源の使用状態をノード内で管理し、情報削除要求が来た場合、使用が終了するまで返答を保留するようにしてもよい。もしくは要求を拒否し、拒否された共有資源管理は、一定時間を置いてリトライするようにしてもよい。これはどちらの場合においても、共有資源管理が「仮返却」資源の情報が削除されるまで待つことを意味する。
【００７０】
第４の対策として、仮資源返却の場合、管理テーブルの「状態」をすぐに「仮」にせず、想定される実行タイミングのズレより大きい時間、状態の変更を保留した後に「仮」に変更するようにしてもよい。
【００７１】
上記本実施形態によれば、資源運用の効率化と資源返却処理コスト削減を両立することができるようになる。
【００７２】
また、上記本実施形態によれば、「プロセス毎の返却」方法で全ての資源共有者が同時に資源返却処理を行なう場合、グループ管理(マスタ)にアクセスが集中することで、ネットワークに局所的な高負荷が発生したが、これを緩和することができることが挙げられる。すなわち、グループの代表として1プロセスによる返却処理だけでシステムに資源を返却できるようにしたためである。
【００７３】
また、上記本実施形態によれば、「プロセス毎の返却」方法において管理テーブルの整合性を保証するための排他アクセスが原因で、ノード数の多い大規模ジョブによる資源返却では非常に大きな時間的返却コストを必要としたが、これを緩和できることが挙げられる。すなわち、ジョブの大小にかかわらずグループの代表として1プロセスによる返却処理だけでシステムに資源を返却できるようにしたためである。
【００７４】
また、上記本実施形態によれば、未使用資源枯渇時に資源要求が発生した場合は資源返却の処理コストを支払うことで未使用資源を確保してジョブの並行実行を優先するが、未使用資源がある場合は資源の返却コスト削減を優先する動作を自動で行なうことができることが挙げられる。すなわち、「仮返却」状態の資源を、未使用資源が無くなった時にはじめて割り当て対象とする管理手法のためである。
【００７５】
また、上記本実施形態によれば、管理テーブルを分けることなく「仮返却」が従来の返却法と共存できるため、従来法の動作を期待するプログラムの実行も可能なことが挙げられる。すなわち、「仮返却」が従来法の状態に遷移可能な中間状態という位置づけのためである。
【００７６】
なお、本明細書等において、手段とは、単に物理的手段を意味するものではなく、その手段が有する機能をソフトウェアによって実現する場合も含む。また、１つの手段が有する機能が２つ以上の物理的手段により実現されても、２つ以上の手段の機能が１つの物理的手段により実現されてもよい。
【００７７】
また、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。
【００７８】
なお、上記実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限らない。
【００７９】
（付記１）複数の資源からなる共有資源の割り当てと当該割り当てた共有資源の返却を管理する共有資源管理手段と、
複数のプロセスを有するプロセスグループにおける前記共有資源の割り当てと返却を管理する管理マスタと、を備え、
前記共有資源管理手段は、
前記管理マスタから当該プロセスグループに割り当てられた資源の仮返却を受け付ける手段と、
他のプロセスグループを管理する他の管理マスタから前記共有資源の取得要求を受け付ける手段と、
前記共有資源中に未使用の資源があるか否かを判定し、未使用の資源がないと判定した場合は、前記仮返却された資源を前記他のプロセスグループに割り当てる割当手段と、
を備えることを特徴とする共有資源管理システム。
【００８０】
（付記２）前記管理マスタは、
当該管理マスタが対象とするプロセスグループ中の少なくとも１つのプロセスが当該プロセスグループに割り当てられた資源を返却可能な状態になった場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ仮返却することを特徴とする付記１に記載の共有資源管理システム。
【００８１】
（付記３）前記共有資源管理手段は、
前記仮返却された資源を前記他のプロセスグループに割り当てる場合は、当該仮返却された資源の資源情報の削除を当該仮返却した管理マスタに要求することを特徴とする付記１または２に記載の共有資源管理システム。
【００８２】
（付記４）前記共有資源管理手段は、
前記未使用の資源がないと判定した場合において前記仮返却された資源が複数あるときは、当該複数の仮返却された資源について算定された各情報削除処理コストに基づいて、前記他のプロセスグループに割り当てる資源を選択することを特徴とする付記１乃至３いずれか１項に記載の共有資源管理システム。
【００８３】
（付記５）前記管理マスタは、
当該管理マスタが対象とするプロセスグループ中の全てのプロセスが当該プロセスグループに割り当てられた資源を返却可能な状態になった場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ返却することを特徴とする付記１乃至４いずれか１項に記載の共有資源管理システム。
【００８４】
（付記６）前記管理マスタは、
当該管理マスタが対象とするプロセスグループが消滅した場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ返却することを特徴とする付記１乃至４いずれか１項に記載の共有資源管理システム。
【００８５】
（付記７）複数の資源からなる共有資源の割り当てと当該割り当てた共有資源の返却を管理する共有資源管理手段と、複数のプロセスを有するプロセスグループにおける前記共有資源の割り当てと返却を管理する管理マスタと、を備えるシステムにおける共有資源管理方法であって、
前記共有資源管理手段が、
前記管理マスタから当該プロセスグループに割り当てられた資源の仮返却を受け付けるステップと、
他のプロセスグループを管理する他の管理マスタから前記共有資源の取得要求を受け付けるステップと、
前記共有資源中に未使用の資源があるか否かを判定し、未使用の資源がないと判定した場合は、前記仮返却された資源を前記他のプロセスグループに割り当てる割当ステップと、
を備えることを特徴とする共有資源管理方法。
【００８６】
（付記８）前記管理マスタは、
当該管理マスタが対象とするプロセスグループ中の少なくとも１つのプロセスが当該プロセスグループに割り当てられた資源を返却可能な状態になった場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ仮返却するステップを備えることを特徴とする付記７に記載の共有資源管理方法。
【００８７】
（付記９）前記共有資源管理手段は、
前記仮返却された資源を前記他のプロセスグループに割り当てる場合は、当該仮返却された資源の資源情報の削除を当該仮返却した管理マスタに要求するステップを備えることを特徴とする付記７または８に記載の共有資源管理方法。
【００８８】
（付記１０）前記共有資源管理手段は、
前記未使用の資源がないと判定した場合において前記仮返却された資源が複数あるときは、当該複数の仮返却された資源について算定された各情報削除処理コストに基づいて、前記他のプロセスグループに割り当てる資源を選択するステップを備えることを特徴とする付記７乃至９いずれか１項に記載の共有資源管理方法。
【００８９】
（付記１１）前記管理マスタは、
当該管理マスタが対象とするプロセスグループ中の全てのプロセスが当該プロセスグループに割り当てられた資源を返却可能な状態になった場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ返却するステップを備えることを特徴とする付記７乃至１０いずれか１項に記載の共有資源管理方法。
【００９０】
（付記１２）前記管理マスタは、
当該管理マスタが対象とするプロセスグループが消滅した場合に、当該プロセスグループに割り当てられた資源を前記共有資源管理手段へ返却するステップを備えることを特徴とする付記７乃至１０いずれか１項に記載の共有資源管理方法。
【符号の説明】
【００９１】
１…仮定システム、１００…ノード＃００、１０１…ノード＃０１、１０２…ノード＃０２、１０３…ノード＃０３、１０４…ノード＃０４、１０５…ノード＃０５、１０６…ノード＃０６、１０７…ノード＃０７、１０８…ノード＃０８、１０９…ノード＃０９、１１１…ノード＃１１、２００…共有資源、３００…ネットワークスイッチ、４００…共有資源管理テーブル
【図１】
0005601473.tif 000002
【図２】
0005601473.tif 000003
【図３】
0005601473.tif 000004
【図４】
0005601473.tif 000005
【図５】
0005601473.tif 000006
【図６】
0005601473.tif 000007
【図７】
0005601473.tif 000008
【図８】
0005601473.tif 000009
【図９】
0005601473.tif 000010
【図１０】
0005601473.tif 000011
【図１１】
0005601473.tif 000012
【図１２】
0005601473.tif 000013
【図１３】
0005601473.tif 000014
【図１４】
0005601473.tif 000015
【図１５】
0005601473.tif 000016
【図１６】
0005601473.tif 000017
【図１７】
0005601473.tif 000018
【図１９】
0005601473.tif 000019
【図２０】
0005601473.tif 000020
【図２３】
0005601473.tif 000021
【図２４】
0005601473.tif 000022
【図２５】
0005601473.tif 000023
【図２６】
0005601473.tif 000024
【図２７】
0005601473.tif 000025
【図２８】
0005601473.tif 000026
【図２９】
0005601473.tif 000027
【図３０】
0005601473.tif 000028
【図３１】
0005601473.tif 000029
【図１８】
0005601473.tif 000030
【図２１】
0005601473.tif 000031
【図２２】
0005601473.tif 000032
【図３２】
0005601473.tif 000033
【図３３】
0005601473.tif 000034
【図３４】
0005601473.tif 000035
【図３５】
0005601473.tif 000036
【図３６】
0005601473.tif 000037
【図３７】
0005601473.tif 000038
【図３８】
0005601473.tif 000039
【図３９】
0005601473.tif 000040