(57)【特許請求の範囲】
【請求項１】
複数のサーバと共有ディスク装置とを有し、前記複数のサーバで共有する共有リソースに対する排他制御を行う共有リソース排他制御システムであって、
前記共有ディスク装置は、
前記複数のサーバからアクセスされる共有リソースと、
前記複数のサーバに対応して存在し前記共有リソース毎の使用状況を管理する管理領域とを含み、
前記サーバは、
前記共有ディスク装置上の自サーバに対応する管理領域内のこれからアクセスしようとする共有リソースのビットをオンにし、
前記共有ディスク装置上の他サーバに対応する管理領域内のこれからアクセスしようとする共有リソースのビットを参照し、
前記参照した他サーバのビットが全てオフであれば前記共有リソースが未使用であると判断して前記共有リソースにアクセスして処理を行い、
処理実行後に、前記共有ディスク装置上の自サーバに対応する管理領域内の前記ビットをオフにする、
ことを特徴とする共有リソース排他制御システム。
【請求項２】
複数のサーバと共有ディスク装置とを有し、前記複数のサーバで共有する共有リソースに対する排他制御を行う共有リソース排他制御システムであって、
前記共有ディスク装置は、
前記複数のサーバからアクセスされる共有リソースと、
前記複数のサーバに対応して存在し前記共有リソース毎の使用状況を管理する管理領域とを含み、
前記サーバは、
前記共有ディスク装置上の自サーバに対応する管理領域内にこれからアクセスしようとする共有リソースのリソース名を登録し、
前記共有ディスク装置上の他サーバに対応する管理領域内にこれからアクセスしようとする共有リソースのリソース名が登録されているか否かを調べ、
前記参照した他サーバの管理領域内に前記共有リソースのリソース名が登録されていなければ前記共有リソースが未使用であると判断して前記共有リソースにアクセスして処理を行い、
処理実行後に、前記共有ディスク装置上の自サーバに対応する管理領域内に登録したリソース名を消去する、
ことを特徴とする共有リソース排他制御システム。
【請求項３】
前記サーバは、前記共有リソースの使用状況が全て未使用でない場合には排他エラーとする手段を有する、
ことを特徴とする請求項１又は請求項２記載の共有リソース排他制御システム。
【請求項４】
前記共有リソースと前記管理領域を別々の共有ディスク装置に設ける、
ことを特徴とする請求項１又は請求項２記載の共有リソース排他制御システム。
【請求項５】
複数のサーバと共有ディスク装置とを有し、前記複数のサーバで共有する共有リソースに対する排他制御を行う共有リソース排他制御方法であって、
前記共有ディスク装置は、
前記複数のサーバからアクセスされる共有リソースと、前記複数のサーバに対応して存在し前記共有リソース毎の使用状況を管理する管理領域とを含み、
前記サーバは、
前記共有ディスク装置上の自サーバに対応する管理領域内のこれからアクセスしようとする共有リソースのビットをオンにし、
前記共有ディスク装置上の他サーバに対応する管理領域内のこれからアクセスしようとする共有リソースのビットを参照し、
前記参照した他サーバのビットが全てオフであれば前記共有リソースが未使用であると判断して前記共有リソースにアクセスして処理を行い、
処理実行後に、前記共有ディスク装置上の自サーバに対応する管理領域内の前記ビットをオフにする、
ことを特徴とする共有リソース排他制御方法。
【請求項６】
複数のサーバと共有ディスク装置とを有し、前記複数のサーバで共有する共有リソースに対する排他制御を行う共有リソース排他制御方法であって、
前記共有ディスク装置は、
前記複数のサーバからアクセスされる共有リソースと、前記複数のサーバに対応して存在し前記共有リソース毎の使用状況を管理する管理領域とを含み、
前記サーバは、
前記共有ディスク装置上の自サーバに対応する管理領域内にこれからアクセスしようとする共有リソースのリソース名を登録し、
前記共有ディスク装置上の他サーバに対応する管理領域内にこれからアクセスしようとする共有リソースのリソース名が登録されているか否かを調べ、
前記参照した他サーバの管理領域内に前記共有リソースのリソース名が登録されていなければ前記共有リソースが未使用であると判断して前記共有リソースにアクセスして処理を行い、
処理実行後に、前記共有ディスク装置上の自サーバに対応する管理領域内に登録したリソース名を消去する、
ことを特徴とする共有リソース排他制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数のサーバで共有するリソースに対する排他制御方式に関し、特に共有リソース管理領域を設けて共有リソースに対する排他制御を行う共有リソース排他制御方式および方法に関する。
【０００２】
【従来の技術】
従来、複数のサーバで共有しているリソースに対して各サーバがアクセスする場合、サーバ間で通信を行い共有リソースの使用状況をやりとりすることにより、複数サーバ間での共有リソースの排他制御を実現していた。
【０００３】
このように、サーバ間で通信を行うことにより排他制御を行うために、各サーバは、サーバ間の通信を制御するためのプログラムや各サーバをネットワーク接続するためのハードウェアを備えている。
【０００４】
【発明が解決しようとする課題】
しかしながら、上述した従来の技術では、サーバ間で通信を行い共有リソースの使用状況をやりとりするため、サーバ間の通信を制御するプログラムや各サーバをネットワーク接続するためのハードウェアが必要となり、処理が複雑になり、複数サーバで処理を分散することによるオーバーヘッドが大きくなり、負荷分散したことによる性能向上面での十分な効果を期待できないという問題があった。また、そのためのコストも小さくないという問題があった。
【０００５】
本発明に目的は、上記の問題点を解決し、シンプルな方式で共有リソースの排他制御を行う共有リソース排他制御方式および方法を提供することにある。
【０００６】
【課題を解決するための手段】
本願第１の発明の共有リソース排他制御システムは、複数のサーバと共有ディスク装置とを有し、複数のサーバで共有する共有リソースに対する排他制御を行う共有リソース排他制御システムであって、共有ディスク装置は、複数のサーバからアクセスされる共有リソースと、複数のサーバに対応して存在し共有リソース毎の使用状況を管理する管理領域とを含み、サーバは、共有ディスク装置上の自サーバに対応する管理領域内のこれからアクセスしようとする共有リソースのビットをオンにし、共有ディスク装置上の他サーバに対応する管理領域内のこれからアクセスしようとする共有リソースのビットを参照し、参照した他サーバのビットが全てオフであれば共有リソースが未使用であると判断して共有リソースにアクセスして処理を行い、処理実行後に、共有ディスク装置上の自サーバに対応する管理領域内のビットをオフにする、ことを特徴とする。
また、本願第２の発明の共有リソース排他制御システムは、複数のサーバと共有ディスク装置とを有し、複数のサーバで共有する共有リソースに対する排他制御を行う共有リソース排他制御システムであって、共有ディスク装置は、複数のサーバからアクセスされる共有リソースと、複数のサーバに対応して存在し共有リソース毎の使用状況を管理する管理領域とを含み、サーバは、共有ディスク装置上の自サーバに対応する管理領域内にこれからアクセスしようとする共有リソースのリソース名を登録し、共有ディスク装置上の他サーバに対応する管理領域内にこれからアクセスしようとする共有リソースのリソース名が登録されているか否かを調べ、参照した他サーバの管理領域内に共有リソースのリソース名が登録されていなければ共有リソースが未使用であると判断して共有リソースにアクセスして処理を行い、処理実行後に、共有ディスク装置上の自サーバに対応する管理領域内に登録したリソース名を消去する、ことを特徴とする。
【０００９】
本願第３の発明の共有リソース排他制御システムは、第１又は第２の発明においてサーバは、共有リソースの使用状況が全て未使用でない場合には排他エラーとする手段を有することを特徴とする。
【００１１】
本願第４の発明の共有リソース排他制御システムは、第１又は第２の発明において共有リソースと管理領域を別々の共有ディスク装置に設ける、ことを特徴とする。
【００１２】
本願第５の発明の共有リソース排他制御方法は、複数のサーバと共有ディスク装置とを有し、複数のサーバで共有する共有リソースに対する排他制御を行う共有リソース排他制御方法であって、共有ディスク装置は、複数のサーバからアクセスされる共有リソースと、複数のサーバに対応して存在し共有リソース毎の使用状況を管理する管理領域とを含み、サーバは、共有ディスク装置上の自サーバに対応する管理領域内のこれからアクセスしようとする共有リソースのビットをオンにし、共有ディスク装置上の他サーバに対応する管理領域内のこれからアクセスしようとする共有リソースのビットを参照し、参照した他サーバのビットが全てオフであれば共有リソースが未使用であると判断して共有リソースにアクセスして処理を行い、処理実行後に、共有ディスク装置上の自サーバに対応する管理領域内の前記ビットをオフにする、ことを特徴とする。
【００１３】
本願第６の発明の共有リソース排他制御方法は、複数のサーバと共有ディスク装置とを有し、複数のサーバで共有する共有リソースに対する排他制御を行う共有リソース排他制御方法であって、共有ディスク装置は、複数のサーバからアクセスされる共有リソースと、複数のサーバに対応して存在し共有リソース毎の使用状況を管理する管理領域とを含み、サーバは、共有ディスク装置上の自サーバに対応する管理領域内にこれからアクセスしようとする共有リソースのリソース名を登録し、共有ディスク装置上の他サーバに対応する管理領域内にこれからアクセスしようとする共有リソースのリソース名が登録されているか否かを調べ、参照した他サーバの管理領域内に共有リソースのリソース名が登録されていなければ共有リソースが未使用であると判断して共有リソースにアクセスして処理を行い、処理実行後に、共有ディスク装置上の自サーバに対応する管理領域内に登録したリソース名を消去する、ことを特徴とする。
【００１４】
【発明の実施の形態】
本発明の特徴について説明する。
【００１５】
本発明の共有リソース排他制御方式および方法は、複数サーバ間で共有するリソースについて、サーバ間で通信することなく、各サーバが共有装置内の管理領域をライト／リードすることのみにより、複数サーバ間の共有リソースの排他制御を行うことを特徴としている。
【００１６】
ここで、共有リソースとは、すべての対象サーバからアクセス可能な共有装置上のリソースであり、例えば、共有ディスク装置上のファイル、あるいはそのファイル内の各レコードなどを意味する。
【００１７】
共有装置内の管理領域は、共有リソースの使用状況を管理する領域であり、サーバ対応にサーバ台数分設けられる。
【００１８】
リソースに排他をかけたいサーバは、共有装置上の自サーバ用管理領域の対象リソースに対応するビットをオンにして他サーバ用管理領域を参照し、他サーバ用管理領域の対象リソースに対応するビットがすべてオフであれば排他に成功し、リソースに対する処理を実行する。処理終了後、対応する管理ビットをオフにし、排他を解除する。
【００１９】
リソースに対する管理領域をサーバ台数分設けることで、各管理領域を更新するサーバはその管理領域に対応するサーバのみとなり、自サーバの管理領域は他サーバから上書きされる心配がないため、管理領域の排他を意識することなく（管理領域を排他制御する必要がなく）、シンプルな方式でサーバ間の排他制御を実現することができる。
【００２０】
なお、各サーバ内のプロセス間の排他制御は、各サーバ内で実現されるものとする。また、各サーバは、サーバキャッシュを利用せず、常に最新の共有装置領域を参照するものとする。
【００２１】
次に、本発明の実施の形態の構成について、図面を参照して詳細に説明する。
【００２２】
図１は、本発明の実施の形態の構成を示す図である。
【００２３】
図２は、管理領域を説明する図である。
【００２４】
図３は、共有リソースと管理領域との対応を説明する図である。
【００２５】
図１を参照すると、本発明の実施の形態は、共有装置１と、サーバ群２と、を備えている。
【００２６】
サーバ群２は、サーバ２１〜サーバ２ｎから構成される。各サーバは、プログラム制御で動作するコンピュータであり、共有装置１をアクセスする。
【００２７】
共有装置１は、サーバ群２からアクセスされ参照／更新可能な装置であり、例えば磁気ディスク装置などである。共有装置１は、管理領域群１１と共有リソース群１２とを含む。
【００２８】
管理領域群１１は、共有リソース群１２の排他制御を管理するための領域であり、管理領域１１１〜管理領域１１ｎから構成される。管理領域１１１はサーバ２１に、管理領域１１２はサーバ２２に、…、管理領域１１ｎはサーバ２ｎに対応している。各管理領域にはそれぞれに対応するサーバの共有リソース使用状況が管理されていて、各管理領域は共有リソース毎の使用状況を示すビットの集まりであるビットマップとなっている。各ビットで管理するリソースの使用状況はビットのオン／オフによって表し、オンの場合「対応するリソースは使用中」、オフの場合「対応するリソースは未使用」を表す。図２に管理領域を例示する。図２の１マスが１ビットに対応する。図２では、１ビット目がリソース１２１に、２ビット目がリソース１２２に、…、対応していることを示している。
【００２９】
共有リソース群１２は、リソース１２１〜リソース１２ｍから構成される。各リソースはサーバ群２からアクセスされる。各リソースに対するアクセスは管理領域群１１を使用して排他制御される。共有リソース群１２の一例として、相対編成ファイル内の各レコードがある。相対編成ファイルは、サーバ２１〜サーバ２ｎより参照／更新可能なファイルであり、複数のレコードから構成される。相対編成ファイルを構成する各レコードが、排他制御を行うリソース対象となる。
【００３０】
ここで、共有リソースと管理領域との対応について、より具体的に説明する。本説明では共有リソースを相対編成ファイル内の各レコードとしている。
【００３１】
相対編成ファイルの相対レコード番号を、管理領域の相対位置として使用し、各レコードに対応する管理領域内ビットを特定する。つまり、相対編成ファイルの第１レコード（相対レコード番号１のレコード）の使用状況を管理領域の１ビット目（１マス目）で管理し、第２レコードの使用状況を２ビット目で、第３レコードの使用状況を３ビット目で、という具合に、ｍ番目のリソースをｍビット目で管理する。
【００３２】
相対編成ファイルの各レコードと、管理領域１１１〜管理領域１１ｎのビットの対応例を、図３に示す。図３を参照すると、相対編成ファイルの第３レコードについて、サーバ２１での使用状況は管理領域１１１の３ビット目で、サーバ２２での使用状況は管理領域１１２の３ビット目で、…、サーバ２ｎでの使用状況は管理領域１１ｎの３ビット目で管理されている。
【００３３】
次に、本発明の実施の形態の動作について、図４〜図６を参照して詳細に説明する。
【００３４】
図４は、本発明の実施の形態の動作を説明する図である。
【００３５】
図５は、本発明の実施の形態の動作（ａ）排他開始処理（ｂ）排他解除処理の流れを示す図である。
【００３６】
図６は、リソース競合時の整合性を説明する図である。
【００３７】
図４を参照すると、サーバ２１〜サーバ２ｎに対応する管理領域１１１〜管理領域１１ｎが共有装置１に確保されている。また、共有リソースは相対編成ファイル１３の各レコードである。
【００３８】
最初に、図５（ａ）を用いて、サーバ２１〜サーバ２ｎの各サーバが相対編成ファイル１３のレコードを参照／更新する場合について説明する。例えば、サーバ２１で、相対編成ファイル１３の第３レコード（相対レコード番号３のレコード）を参照／更新する場合、以下の処理となる。
【００３９】
サーバ２１は、共有装置１上の自サーバに対応する管理領域１１１の３ビット目をオンにする（Ｓ１１）。
【００４０】
管理領域群１１全体（管理領域１１１〜管理領域１１ｎ）を読み込み、他サーバ（サーバ２２〜サーバ２ｎ）に対応する管理領域１１２〜管理領域１１ｎのそれぞれの３ビット目を参照する（Ｓ１２）。
【００４１】
参照した各管理領域の３ビット目がすべてオフである場合（Ｓ１３でＹＥＳ）、排他成功（Ｓ１４）として、第３レコードを参照／更新する処理を実行する。
【００４２】
オンである領域がひとつでも存在した場合（Ｓ１３でＮＯ）、管理領域１１１の３ビット目をオフに戻し、排他失敗として処理を中断する（Ｓ１５）。
【００４３】
続いて、図５（ｂ）を用いて、排他成功したサーバ２１が相対編成ファイル１３の第３レコードを排他解除する場合について説明する。サーバ２１は、第３レコードを参照／更新する処理実行後、以下の処理を行う。
【００４４】
共有装置１上のサーバ２１に対応する管理領域１１１の３ビット目をオフにし（Ｓ１６）、排他解除成功として処理を終了する（Ｓ１７）。
【００４５】
次に、図６を参照して、本発明を実施した際に、共有リソースの整合性が維持されることを説明する。
【００４６】
図６は、リソース競合時の整合性を説明する図であり、不整合を排除できることが確認できるタイミングチャートである。図６の縦細線は、対象リソースの各サーバに対応する管理ビットを指し、時間は上から下に流れる。各パターンは、２つのサーバが同じリソースにアクセスする場合の処理の流れを、共有装置上の管理領域へのアクセスタイミングにより場合分けしたものである。図６内の各記号は、以下の処理を意味している。
・ON(T11)：自サーバの対象リソースに対応するビットをオンにして排他を開始する。
・Read(T12)：全サーバ分の管理領域を読み込んで他サーバ用の対象リソースに対応するビットを参照する。
・OK(T13)：Read(T12)で参照したビットがすべてオフである。
・OFF(T14)：自サーバの対象リソースに対応するビットをオフにして排他を解除する。
・Error(T15)：Read(T12)で参照したビットにオンであるものが存在し、排他に失敗した。
・各タイミングチャートの白抜き矢印は、各サーバからの排他が成功し、リソースを確保している期間を示す。
【００４７】
各パターンについて説明する。
【００４８】
パターン１は、先行サーバでの処理がすべて終了し排他解除したと同時に後行サーバでの処理が始まるパターンである。先行サーバがリソースを解放したので、後行サーバはリソースを確保する。
【００４９】
パターン２は、先行サーバでの排他開始後、排他解除前に、後行サーバでの処理が始まるパターンである。先行サーバがリソースを確保しているので、後行サーバはリソース確保に失敗する。
【００５０】
パターン３は、先行サーバが自サーバの対象リソースに対応するビットをオンにした直後に、後行サーバが処理を開始し、先行サーバが後行サーバ用の管理ビットがオンであるために排他エラーと判断して管理ビットをオフにした後に、後行サーバが全サーバ分の管理領域を読み込むパターンである。先行サーバがリソース排他処理を止めたので、後行サーバはリソースを確保する。
【００５１】
パターン４は、先行サーバと後行サーバが、ほぼ同時に処理を開始し、共に排他エラーとなるパターンである。先行サーバと後行サーバと共に、リソースを確保に失敗する。
【００５２】
パターン５は、先行サーバが自サーバの対象リソースに対応するビットをオンにした直後に、後行サーバが処理を開始し、後行サーバが先行サーバ用の管理ビットがオンであるために排他エラーと判断して管理ビットをオフにした後に、先行サーバが全サーバ分の管理領域を読み込むパターンである。後行サーバがリソース排他処理を止めたので、先行サーバはリソースを確保する。
【００５３】
このように、複数のサーバで同時に”ＯＫ”となることがないことを確認でき、整合性が維持される。
【００５４】
上述したように、サーバ対応に設けた管理領域のビットでリソースを管理することにより、シンプルに排他制御を行うことができる。
【００５５】
上述した実施の形態では、管理領域は管理領域内のビットにリソースを対応づけ１つのビットで１つのリソースを管理し、ビットのオン／オフでリソースの使用／未使用を管理しているが、他の実施の形態として、管理領域にリソース名を登録するようにし管理領域にリソース名が登録されているか否かでリソースの使用／未使用を管理するようにしてもよい。
【００５６】
次に、本発明の他の実施の形態について説明する。
【００５７】
本発明の他の実施の形態の構成については上述した実施の形態の構成と同様であるので説明を省略し、本発明の他の実施の形態の動作について図７および図８を参照して説明する。
【００５８】
図７は本発明の他の実施の形態の動作を説明する図であり、図８は管理領域を説明する図である。
【００５９】
ここでは、サーバ３１が相対編成ファイル１３の第３レコード（相対レコード番号３のレコード）をアクセスする場合を例にとり、説明する。なお、第３レコードのリソース名を”ＲＥＣ−３”とする。
【００６０】
サーバ３１は、共有装置１上の自サーバに対応する管理領域１４１内にリソース名”ＲＥＣ−３”を登録する。
【００６１】
管理領域群１４全体（管理領域１４１〜管理領域１４ｎ）を読み込み、他サーバ（サーバ３２〜サーバ３ｎ）に対応する管理領域１４２〜管理領域１４ｎ内にリソース名”ＲＥＣ−３”が登録されているか否かを調べる。
【００６２】
調べた結果、各管理領域内にリソース名”ＲＥＣ−３”が全く登録されていない場合、排他成功として、サーバ３１は第３レコードを参照／更新する処理を実行する。
【００６３】
調べた結果、リソース名”ＲＥＣ−３”が登録されている管理領域がひとつでも存在した場合、サーバ３１は管理領域１４１内に登録したリソース名”ＲＥＣ−３”を消去し、排他失敗として、処理を中断する。
【００６４】
サーバ３１は、第３レコードを参照／更新する処理を実行した後、共有装置１上のサーバ３１に対応する管理領域１４１内に登録したリソース名”ＲＥＣ−３”を消去し、排他解除成功として、処理を終了する。
【００６５】
このように、サーバ対応に設けた管理領域にリソース名を登録して管理することにより、シンプルに排他制御を行うことができる。
【００６６】
また、上述した実施の形態では、管理領域群と共有リソース群とを同一の装置内に設けているが、他の実施の形態として、管理領域群と共有リソース群を別々の装置に設けるようにしてもよい。こうすることにより、共有リソース群に対するアクセス性能が向上する効果がある。
【００６７】
【発明の効果】
第１の効果は、サーバ間での通信を行う必要がないことによる開発コストおよび必要ハードウェアの削減である。サーバ間で通信を行うことにより排他制御を行う場合、サーバ間の通信を制御するプログラムの開発や各サーバをネットワーク接続するためのハードウェアが必要となる。本発明を使用することにより共有リソースが存在するディスク上で排他制御が可能なため、それらのプログラム、ハードウェアがすべて不要となり、開発コストおよびハードウェアコストを大幅に削減できる。
【００６８】
第２の効果は、複数サーバで処理を分散することにより必要となるオーバーヘッドを軽減することによる高パフォーマンスの実現である。複数サーバで処理を分散する場合、整合性を保ちつつパフォーマンスを向上させるためには、排他をかける共有リソースの単位を小さくして処理並列度を上げる必要がある。例えば、ファイル単位で排他をかけるのではなく、レコード単位で排他をかけるという具合である。この場合、排他処理を行う対象および実行回数が増えるため、個々の排他処理が複雑であれば、その分、排他制御を行うことによるオーバーヘッドが増大し、パフォーマンスに大きく影響する。本発明を使用することにより、共有リソースが存在するディスク上のセクタをWrite＆Readするだけで１リソースの排他処理が完了するため、個々の排他処理が単純になり、排他単位を小さくしてもそのオーバーヘッドがほとんど発生しない。従って、複数サーバで処理を分散し大幅にパフォーマンスを向上させることが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態の構成を示す図
【図２】管理領域を説明する図
【図３】共有リソースと管理領域との対応を説明する図
【図４】本発明の実施の形態の動作を説明する図
【図５】本発明の実施の形態の動作（ａ）排他開始処理（ｂ）排他解除処理の流れを示す図
【図６】リソース競合時の整合性を説明する図
【図７】本発明の他の実施の形態の動作を説明する図
【図８】管理領域を説明する図
【符号の説明】
１    共有装置
２    サーバ群
１１    管理領域群
１２    共有リソース群
１３    相対編成ファイル
１４    管理領域群
２１    サーバ
２２    サーバ
２ｎ    サーバ
３１    サーバ
３２    サーバ
３ｎ    サーバ
１１１    管理領域
１１２    管理領域
１１ｎ    管理領域
１２１    リソース
１２２    リソース
１２ｍ    リソース
１４１    管理領域
１４２    管理領域
１４ｎ    管理領域
【図１】
0004257053.tif 000002
【図２】
0004257053.tif 000003
【図３】
0004257053.tif 000004
【図４】
0004257053.tif 000005
【図５】
0004257053.tif 000006
【図６】
0004257053.tif 000007
【図７】
0004257053.tif 000008
【図８】
0004257053.tif 000009