(57)【特許請求の範囲】
【請求項１】
第１のロックマネージャ装置と第２のロックマネージャ装置を含む分散ロックシステムのロックマネージャ装置であって、
前記分散ロックシステムにより管理されるリソースがロック中であるか否かを示す情報と、
前記分散ロックシステムにより管理されるロック中であるリソースの数を記憶するロックカウンタと、
前記第１のロックマネージャ装置がマスタ、前記第２のロックマネージャ装置がスレーブである場合において、前記ロックカウンタにロック中であるリソースの数を記憶させるとともに、前記ロックカウンタが０でなければ一定時間待機し、前記ロックカウンタが０になったなら、前記第２のロックマネージャ装置にマスタ化要求を送信することで、前記第２のロックマネージャ装置がマスタ、前記第１のロックマネージャ装置がスレーブとなるように動作するロックマネージャと
を備えることを特徴とするロックマネージャ装置。
【請求項２】
前記ロックマネージャは、マスタとスレーブの交代が開始されてからマスタとスレーブの交代が完了するまでの間、当該ロックマネージャのマスタが受信するロック要求に対してロック獲得処理を実行しないことを特徴とする請求項１に記載のロックマネージャ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ロック情報を共有せずにサービスを提供しながらマスタ交代を可能とする冗長化ロックマネージャ装置に関するものである。
【背景技術】
【０００２】
分散システムでは、リソースの排他制御を行うために分散ロックシステムが必要とされる。分散ロックシステム自体も高可用性のために装置の冗長化が求められ(要求１)、その装置を保守するために、サービスを提供しながら冗長化された装置のマスタ交代を行えることが求められる(要求２)。
【０００３】
分散ロックシステムの実現手法のひとつに、ロックサービスを提供するロックマネージャ装置の突然の故障に備え、ロック管理情報を複数のロックマネージャ装置で常時共有し、故障復旧時にロック管理情報をロックマネージャ間で引き継ぐ手法がある（例えば、非特許文献１）。このようなロック情報を共有する手法は、ロック獲得時・解放時にロック情報を複数の装置間で同期させるための処理負荷や処理時間がかかり高速化しにくいという問題(問題１)と、ロック管理情報をロックマネージャ間で引継ぐ仕組みが複雑であり実装コストが高いという問題(問題２)とがある。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】藤原祐二, 藤田肇, 石川裕, "耐故障分散ロック機構の設計と検証," 情報処理学会, 研究報告システムソフトウェアとオペレーティング・システム（OS）, vol. 2011-OS-118, No. 14, pp. 1-7.
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、上記の課題に鑑みてなされたものであり、その目的とするところは、ロック情報を共有せずにサービスを提供しながらマスタ交代を可能とするロックマネージャ装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記の課題を解決するために、本発明は、第１のロックマネージャ装置と第２のロックマネージャ装置を含む分散ロックシステムのロックマネージャ装置であって、前記分散ロックシステムにより管理されるリソースがロック中であるか否かを示す情報と、前記分散ロックシステムにより管理されるロック中であるリソースの数を記憶するロックカウンタと、前記第１のロックマネージャ装置がマスタ、前記第２のロックマネージャ装置がスレーブである場合において、前記ロックカウンタにロック中であるリソースの数を記憶させるとともに、前記ロックカウンタが０でなければ一定時間待機し、前記ロックカウンタが０になったなら、前記第２のロックマネージャ装置にマスタ化要求を送信することで、前記第２のロックマネージャ装置がマスタ、前記第１のロックマネージャ装置がスレーブとなるように動作するロックマネージャとを備えることを特徴とする。
【０００７】
例えば、前記ロックマネージャは、マスタとスレーブの交代が開始されてからマスタとスレーブの交代が完了するまでの間、当該ロックマネージャのマスタが受信するロック要求に対してロック獲得処理を実行しない。
【発明の効果】
【０００８】
本発明によれば、ロック情報を共有せずにサービスを提供しながらマスタ交代を行うことができる。
【図面の簡単な説明】
【０００９】
【図１】ロックマネージャ装置によるロック制御の例を示す図である。
【図２】保守操作によってマスタのロックマネージャ装置とスレーブのロックマネージャ装置を交代させる例を示す図である。
【図３】図２の続きを示す図である。
【図４】クライアント装置がデータをロック中にマスタのロックマネージャ装置１が故障し、マスタ／スレーブが交代した場合の例を示す図である。
【図５】クライアント装置が、その時点のマスタのロックマネージャ装置にアンロック要求を送信する例を示す図である。
【図６】クライアント装置の故障によりアンロックできない事態を避けるべく、一定の時間が経過したら、強制的にアンロックする例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施の形態について図面を参照して説明する。
【００１１】
図１…図６は、本実施の形態に係るロックマネージャ装置を利用した分散ロックシステムの動作を示す図である。これら図に示す分散ロックシステムは、ロック情報を共有しない単純な分散ロックシステムである。
【００１２】
この分散ロックシステムは、管理対象であるリソースの排他制御を行うもので、高可用性のためにロックマネージャ装置を冗長化しており、そのロックマネージャ装置を保守するために、サービスを提供しながら冗長化されたロックマネージャ装置のマスタ交代を行うことができる。ここでは、リソースとして、データを例に説明するが、リソースはデータに限るものではない。
【００１３】
マスタ交代が求められる理由は、ロックマネージャ装置の部品交換や再起動等の保守を行う際に、マスタを止めるとサービスが停止する可能性があるので、スレーブにしてから装置を止めるのである。
【００１４】
図１は、ロックマネージャ装置によるロック制御の例を示す図である。
【００１５】
図１に示すように、各ロックマネージャ装置は、ロックされたデータの名前や識別子（以下、便宜的にＩＤと記す）が記載され、これにより、ロックされたデータが管理されるロック管理表、ロック管理表に基づいて、データが使用中であることを管理する（ＩＤをロックする）処理と、データをロックされていない状態にする（データをアンロックする）処理とを行うロックマネージャとを備える。
【００１６】
また、ここでは、ロックマネージャ装置１がマスタ、ロックマネージャ装置２がスレーブとし、通常は、マスタのロックマネージャが、クライアント装置Ａやクライアント装置Ｂからの要求によりロック／アンロックを行う。当初は、ロックされたデータはなく、ロック管理表はＩＤを記載していない。
【００１７】
なお、図では、クライアント装置Ａとクライアント装置Ｂが別の装置であるように記載するが、同一装置の中で動作していてもよい。
【００１８】
例えば、クライアント装置Ａは、データ１０をロックすべく、データ１０を示すロック要求をロックマネージャ装置１に送信したとする（Ｓ１）。ロックマネージャ装置１は、このロック要求を受信する。
【００１９】
ロックマネージャ装置１のロックマネージャは、ロック管理表を参照し（Ｓ３）、データ１０のＩＤがロック管理表に記載されていないので、ロック管理表にデータ１０のＩＤを記載し（Ｓ５）ロック中であることを記憶し、クライアント装置Ａにロック獲得を通知する（Ｓ７）。クライアント装置Ａは、例えば、ロック獲得により、データ１０を用いた処理を行う（Ｓ９）。
【００２０】
ここでクライアント装置Ｂも、データ１０をロックすべく、データ１０を示すロック要求をロックマネージャ装置１に送信したとする（Ｓ１１）。
【００２１】
ロックマネージャ装置１のロックマネージャは、ロック管理表を参照し（Ｓ１３）、データ１０のＩＤがロック管理表に記載されているので、待機状態に入る（Ｓ１５）。この場合、ロックマネージャは、ロック管理表に対し、クライアント装置Ｂがデータ１０について待機中であることを示す待機情報を記載する（Ｓ１７）。
【００２２】
クライアント装置Ａは、データ１０を用いた処理が終わると、データ１０をアンロックすべく、データ１０を示すアンロック要求をロックマネージャ装置１に送信する（Ｓ２１）。
【００２３】
ロックマネージャ装置１のロックマネージャは、ロック管理表を参照し（Ｓ３）、データ１０のＩＤがロック管理表に記載され且つデータ１０の待機情報がロック管理表に記載されているので、待機情報を削除する（Ｓ２５）。また、ロックマネージャは、クライアント装置Ａにアンロック完了を通知する（Ｓ２７）。また、ロックマネージャは、データ１０について待機中のロック要求を処理すべく、データ１０の管理情報はロック中のまま維持し待機情報においてデータ１０について待機中であるクライアント装置Ｂにロック獲得を通知する（Ｓ２９）。これにより、待機状態が終了する。クライアント装置Ｂは、例えば、ロック獲得により、データ１０を用いた処理を行う（Ｓ３１）。
【００２４】
クライアント装置Ｂは、データ１０を用いた処理が終わると、データ１０をアンロックすべく、データ１０を示すアンロック要求をロックマネージャ装置１に送信する（Ｓ４１）。
【００２５】
ロックマネージャ装置１のロックマネージャは、ロック管理表を参照し（Ｓ４３）、アンロック要求に示されたデータ１０のＩＤがロック管理表に記載され且つデータ１０の待機情報がロック管理表に記載されていないので、データ１０のＩＤをロック管理表から削除する（Ｓ４５）。また、ロックマネージャは、クライアント装置Ｂにアンロック完了を通知する（Ｓ４７）。
【００２６】
以上に述べたことから、ロックマネージャ装置１がロックの管理を行う動作において、ロックマネージャ装置２と情報のやりとりを行っていないことがわかるであろう。つまり、ロックマネージャ装置１とロックマネージャ装置２はロック情報を共有していない。そのため、ロックマネージャの動作が簡素となり、高速に自律的に動作する装置を実現できることが見込める。以上のようにロックマネージャ装置は、クライアント装置に通信回線を介して接続されるロックマネージャ装置であって、クライアント装置によりロックされたデータを管理するロック管理表と、クライアント装置からのロック要求に示されたデータがロック管理表に記載されていない場合は、ロック管理表に当該データを記載するとともに当該クライアント装置にロック獲得を通知する一方、当該データがロック管理表に記載されている場合は、ロック管理表に対し当該クライアント装置が当該データについて待機中であることを示す待機情報を記載し、クライアント装置からのアンロック要求に示されたデータがロック管理表に記載され且つ当該データの待機情報がロック管理表に記載されていない場合は、当該データをロック管理表から削除するとともに当該クライアント装置にアンロック完了を通知する一方、当該データがロック管理表に記載され且つ当該データの待機情報がロック管理表に記載されている場合は、当該待機情報を削除するとともに当該クライアント装置にアンロック完了を通知するとともに当該待機情報において当該データについて待機中であるクライアント装置にロック獲得を通知するので、高性能な冗長化分散ロックシステムを実現できる。具体的には、ロックマネージャ装置間でのロック情報の共有をしないため、分散ロックシステムの高速化が可能になる。
【００２７】
図２、図３は、保守操作によってマスタのロックマネージャ装置とスレーブのロックマネージャ装置を交代させる例を示す図である。
【００２８】
図２に示すように、この場合、各ロックマネージャ装置１、２には、ロック管理表に記載されたＩＤの数つまりロックされたデータ数を記憶するロックカウンタを設ける。ロックカウンタの初期値は０であり、ロック獲得の際に１加算され、アンロック完了の際に１減算される。
【００２９】
図２、図３のように、マスタ／スレーブの交代中、ロック掃き出し（詳しくは後述する）が行われる。交代中は新規のロックを行わず、ロック掃き出し後に交代を行う。交代のタイミングではロック中のデータはないので、データの排他性が維持できる。
【００３０】
例えば、クライアント装置Ａは、データ１０をロックすべく、データ１０を示すロック要求をロックマネージャ装置１に送信する（Ｓ５１）。
【００３１】
ロックマネージャ装置１のロックマネージャは、ロック管理表を参照し（Ｓ５３）、データ１０のＩＤがロック管理表に記載されていないので、ロック管理表にデータ１０のＩＤを記載し（Ｓ５５）、クライアント装置Ａにロック獲得を通知する（Ｓ５７）。クライアント装置Ａは、例えば、ロック獲得により、データ１０を用いた処理を行う（Ｓ５９）。また、ロックマネージャは、ロックカウンタに１を加算する（Ｓ５６）。
【００３２】
ここで、保守操作によるマスタ／スレーブの交代が行われたとする。
【００３３】
まず、ロックカウンタが０でなければ一定時間待機を繰り返し、ロックカウンタが０になるまでループする処理を行う。このようにロック中のデータが無くなるまで待つことを本稿では「ロック掃き出し」と呼ぶ。
【００３４】
ロック掃き出しでは、ロックマネージャは、ロックカウンタを読み出し（Ｓ１０１）、ロックカウンタが０でなければ一定時間待機する（Ｓ１０３）。
【００３５】
ここで例えば、待機中に、クライアント装置Ｂが、データ１０を示すロック要求をロックマネージャ装置１に送信したとする（Ｓ１１１）。
【００３６】
ロックマネージャ装置１のロックマネージャは、マスタ交代中（Ｓ１０３）なので、マスタ／スレーブの交代中である旨をクライアント装置Ｂに通知する（Ｓ１１３）。つまり、ロックマネージャは、マスタとスレーブの交代が開始されてからマスタとスレーブの交代が完了するまでの間、自身が受信するロック要求に対してロック獲得処理を実行しない。
【００３７】
交代中を通知されたクライアント装置Ｂは、一定時間待機した後、新しいマスタのロックマネージャ装置にロック要求を送信すればよい（図３：Ｓ１３１）。そうすれば、ロックを獲得できよう(図３：Ｓ１３７)。
【００３８】
クライアント装置Ａは、データ１０を用いた処理が終わると、データ１０をアンロックすべく、データ１０を示すアンロック要求をロックマネージャ装置１に送信する（Ｓ１２１）。
【００３９】
ロックマネージャ装置１のロックマネージャは、アンロック要求に示されたデータ１０のＩＤをロック管理表から削除する（Ｓ１２５）。また、ロックマネージャは、クライアント装置Ａにアンロック完了を通知する（Ｓ１２７）。また、ロックマネージャは、ロックカウンタから１を減算する（Ｓ１２６）。
【００４０】
こうして、ロックカウンタが０になったなら、ロックマネージャ装置１のロックマネージャは、ロックマネージャ装置２にマスタ化要求を送信する。これにより、マスタ／スレーブが交代し、ロックマネージャ装置１がスレーブ、ロックマネージャ装置２がマスタとなる。これにより、保守操作によるマスタ／スレーブの交代が終了する。
【００４１】
図３に進み、例えば、クライアント装置Ｂは、データ１０をロックすべく、データ１０を示すロック要求をロックマネージャ装置２に送信する（Ｓ１３１）。
【００４２】
ロックマネージャ装置２のロックマネージャは、ロック管理表を参照し（Ｓ１３３）、データ１０のＩＤがロック管理表に記載されていないので、ロック管理表にデータ１０のＩＤを記載し（Ｓ１３５）、クライアント装置Ｂにロック獲得を通知する（Ｓ１３７）。クライアント装置Ｂは、例えば、ロック獲得により、データ１０を用いた処理を行う（Ｓ１３９）。また、ロックマネージャは、ロックカウンタに１を加算する（Ｓ１３６）。
【００４３】
クライアント装置Ｂは、データ１０を用いた処理が終わると、データ１０をアンロックすべく、データ１０を示すアンロック要求をロックマネージャ装置２に送信する（Ｓ１４１）。
【００４４】
ロックマネージャ装置２のロックマネージャは、アンロック要求に示されたデータ１０のＩＤをロック管理表から削除する（Ｓ１４５）。また、ロックマネージャは、クライアント装置Ｂにアンロック完了を通知する（Ｓ１４７）。また、ロックマネージャは、ロックカウンタから１を減算する（Ｓ１４６）。
【００４５】
以上のように、ロックマネージャ装置１は、分散ロックシステムにより管理されるリソースがロック中であるか否かを示す情報（ロック管理表）と、分散ロックシステムにより管理されるロック中であるリソースの数を記憶するロックカウンタと、ロックマネージャ装置１がマスタ、ロックマネージャ装置２がスレーブである場合において、ロックカウンタにロック中であるリソースの数を記憶させるとともに（Ｓ５６、Ｓ１２６）、ロックカウンタが０でなければ一定時間待機し（Ｓ１０３）、ロックカウンタが０になったなら（Ｓ１２６）、ロックマネージャ装置２にマスタ化要求を送信することで、ロックマネージャ装置２がマスタ、ロックマネージャ装置１がスレーブとなるように動作するロックマネージャとを備える。つまり、特徴１）ロックマネージャ間でロック情報を共有せず（問題１、２の解消）、特徴２）ロックの掃き出しを行うことで、サービスを提供しながらマスタ交代を行うことができる（要件１、２の充足）。
【００４６】
つまり、特徴１により、ロック情報管理のオーバーヘッドが少なく済み、高速な動作が見込める。また、特徴２により、マスタ交代の時点ではロック中のリソースが無いのでリソースの排他を損なうことなくマスタ交代が可能である。つまり、装置の部品交換や再起動等の保守を行う際にサービスを停止することなく装置をスレーブ化することができるから保守性が良好である。
【００４７】
なお、リソースがロック中であるか否かを示す情報は、ロック管理表に限らず、リソースがロック中であるか否かを示す情報であればどのような形態の情報であってもよい。
【００４８】
また、上記説明では、ロックマネージャ装置１がマスタからスレーブになり、ロックマネージャ装置２がスレーブからマスタになる例を説明したが、逆の場合も同様に、ロックカウンタが０になったならマスタとスレーブが交代する。
【００４９】
図４は、クライアント装置Ａとクライアント装置Ｂがデータ１０をロックしようとし、その間でマスタのロックマネージャ装置１が故障し、マスタ／スレーブが交代した場合の例を示す図である。
【００５０】
図２と同様に、ステップＳ５１、５３、５５、５６、５７が行われた後、ロックマネージャ装置１のロックマネージャが、ロック管理を不可能とする故障を発生し（Ｓ１５１）、これにより、マスタ／スレーブが前述の方法で交代する。クライアント装置Ａは、ロック獲得により、データ１０を用いた処理を行う（Ｓ５９）。
【００５１】
例えば、クライアント装置Ｂは、データ１０をロックすべく、データ１０を示すロック要求を、マスタとなったロックマネージャ装置２に送信する（Ｓ１６１）。
【００５２】
ロックマネージャ装置２のロックマネージャは、ロック管理表を参照し（Ｓ１６３）、データ１０のＩＤがロック管理表に記載されていないので、ロック管理表にデータ１０のＩＤを記載し（Ｓ１６５）、クライアント装置Ｂにロック獲得を通知する（Ｓ１６７）。クライアント装置Ｂは、例えば、ロック獲得により、データ１０を用いた処理を行う（Ｓ１６９）。また、ロックマネージャは、ロックカウンタに１を加算する（Ｓ１６６）。
【００５３】
ステップＳ５９、Ｓ１６９では、クライアント装置Ａ、Ｂが同時に同一のデータ１０を使用し、これにより、データ１０が破壊する可能性がある。
【００５４】
クライアント装置Ａは、データ１０を用いた処理が終わると、データ１０をアンロックすべく、データ１０を示すアンロック要求をロックマネージャ装置１に送信する（Ｓ１７１）。本実施例ではクライアント装置Ａは、ロックを獲得したロックマネージャ装置にアンロック要求を送信する例を示している。
【００５５】
ロックマネージャ装置１のロックマネージャは、交代によりスレーブとなったので、要求先がマスタでないことをエラーとしてクライアント装置Ａに通知する（Ｓ１７３）。
【００５６】
クライアント装置Ａは、このエラーにより、データ１０の排他性が失われ、データが破壊された可能性がある旨をログに記録する（Ｓ１７５）。
【００５７】
クライアント装置Ｂは、データ１０を用いた処理が終わると、データ１０をアンロックすべく、データ１０を示すアンロック要求をロックマネージャ装置２に送信する（Ｓ１８１）。
【００５８】
ロックマネージャ装置２のロックマネージャは、アンロック要求に示されたデータ１０のＩＤをロック管理表から削除する（Ｓ１８５）。また、ロックマネージャは、クライアント装置Ｂにアンロック完了を通知する（Ｓ１８７）。また、ロックマネージャは、ロックカウンタから１を減算する（Ｓ１８６）。
【００５９】
Ｓ１７５で出力したログの情報によって、システム管理者はロックマネージャの故障等によりデータが破壊された可能性があることを知ることができるので、当該ログ情報に基づいてシステム管理者が破壊されたデータを修復するなどの対処を行うことができる。つまり、本発明の特徴を有するロックマネージャは故障が発生した場合には排他が損なわれる可能性があり、データが破壊されるなど期待しない状態になる可能性があるが、ログに出力する情報に基づいて人手による修復を行うことができる。
【００６０】
図４は、クライアント装置が、ロックを獲得したロックマネージャ装置にアンロック要求を送信する例を示したが、図５に示すように、クライアント装置が、その時点のマスタのロックマネージャ装置にアンロック要求を送信するという方法もある。
【００６１】
ところで、一般に分散ロックシステムでは、クライアントの故障によってロックが解放されなくなる場合があるという問題があり、対策が必要である。
【００６２】
対策の方法としては、図６に示すように、ロックを獲得している時間に制限を設け、ロック獲得してから制限時間が経過したらロックマネージャにて強制的にロックを解放してもよいし、ロックマネージャがクライアントの死活監視を行い、ロックマネージャがクライアントの故障を検知したら当該クライアントが獲得しているロックを強制解放してもよいし、他の方法でもよい。
【００６３】
なお、本実施の形態のロックマネージャ装置としてコンピュータを機能させるためのコンピュータプログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に記録でき、また、インターネットなどの通信網を介して伝送させて、広く流通させることができる。
【符号の説明】
【００６４】
１、２…ロックマネージャ装置
Ａ、Ｂ…クライアント装置
【図１】
0006043742.tif 000002
【図２】
0006043742.tif 000003
【図３】
0006043742.tif 000004
【図４】
0006043742.tif 000005
【図５】
0006043742.tif 000006
【図６】
0006043742.tif 000007