JP5466717B2

JP5466717B2 - データの整合性を維持するための装置、方法、およびコンピュータ・プログラム（データの整合性を維持するための装置）

Info

Publication number: JP5466717B2
Application number: JP2011548640A
Authority: JP
Inventors: スコフィールド、アンドリュー、ジョン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2009-02-06
Filing date: 2010-01-26
Publication date: 2014-04-09
Anticipated expiration: 2030-01-26
Also published as: CN102301368A; US20100205164A1; JP2012517057A; CN102301368B; KR101581072B1; WO2010089222A1; KR20110114699A; US10372682B2

Description

本発明は、データの整合性を維持するための装置に関する。

「高可用性」商用コンピューティング環境において、典型的には、ハードウェア障害およびソフトウェア障害からの重大プログラムの即時回復を提供するために、ハードウェア技術とソフトウェア技術とが組み合わせられる。この環境は、単一障害点を除去するように設計される。

たとえば典型的な高可用性環境は、一般に、ディスク・ドライブなどのリソースを共有するいくつかの疎結合（loosely coupled）コンピュータを備える。不可欠なプログラムは、いずれのコンピュータ・セット上でも実行可能である。さらに、ハードウェア・リソース（たとえばディスク・ドライブ）はコンピュータ間で共有される。不可欠なプログラムの使用不能につながるハードウェアまたはソフトウェアの障害は、このプログラムを他のコンピュータに移動することにより、その可用性を復元することによって修復可能である。

典型的な高可用性環境は、歴史的に、高可用性（ＨＡ）ソフトウェアと呼ばれるソフトウェアによって管理されてきた。ＨＡソフトウェアは、通常、コンポーネントを監視すること、および障害に応答してリソースを移動させる責務を担うことによって、ハードウェアおよびソフトウェア・コンポーネントの管理を行う。

こうした高可用性環境（１００）の例が、図１に示されており、第１のＨＡソフトウェア（１１７）と、高可用性ソフトウェア・コンポーネントの第１のインスタンス（１１０）とを有する、第１のコンピュータ（１０５）を備え、ここでソフトウェア・コンポーネント（１１０）は、共有リソース（たとえば、データを備える共有ディスク（１２０））にアクセスするように動作可能である。

高可用性環境（１００）は、第１のＨＡソフトウェア（１１７）と通信するように動作可能な第２のＨＡソフトウェア（１１９）を有する第２のコンピュータ（１１５）も備える。

ある例では、第１のコンピュータ（１０５）の第１のインスタンス（１１０）が共有ディスク（１２０）にアクセスする。第１のＨＡソフトウェア（１１７）は、共有ディスク（１２０）の「所有権」を有する。

第１のコンピュータ（１０５）に障害が発生した場合、第２のＨＡソフトウェア（１１９）は、（たとえば、第２のＨＡソフトウェアがもはや第１のＨＡソフトウェア（１１７）と通信できないことに応答して）その障害を検出するように動作可能である。

図２を参照すると、それに応答して、第２のＨＡソフトウェア（１１９）は第１のインスタンス（１１０）を終了し、共有ディスク（１２０）の所有権をそれ自体に移し、その後、第２のコンピュータ（１１５）上でソフトウェア・コンポーネントの第２のインスタンス（１２５）を開始するように、動作可能である。その後第２のコンピュータ（１１５）は、第１のコンピュータ（１０５）から責務を「引き継ぐ」ように動作可能であり、第２のコンピュータ（１１５）上で実行中の第２のインスタンス（１２５）が共有ディスク（１２０）にアクセスできる。

図１および図２の環境（１００）は、ソフトウェア・コンポーネントの保証された単一の活動化を提供するものであり、すなわち、ソフトウェア・コンポーネントの２つのインスタンスを異なるコンピュータ上で同時に開始することは不可能である。ソフトウェア・コンポーネントの２つのインスタンスが異なるコンピュータ上で同時に開始された場合、これによって、共有ディスク（１２０）上のデータ破損などのエラーが引き起こされる可能性がある。

前述の環境（１００）は、不可欠なプログラムの高可用性および不可欠なプログラムの保証された単一の活動化を提供するものであるが、特別なハードウェア（たとえば、複数のコンピュータによるアクセスが可能なように特別に構成される必要のある共有ディスク（１２０））およびソフトウェア（たとえばＨＡソフトウェア）が必要である。

より最新の技法では、特別なハードウェアあるいはソフトウェアまたはその両方を必要とせずに、高可用性および保証された単一の活動化を達成することができる。

こうした環境（２００）が図３に示されており、環境（２００）は同じソフトウェア・コンポーネントの２つのインスタンスを備える。より詳細に言えば、環境（２００）は、高可用性ソフトウェア・コンポーネントの第３のインスタンス（２１０）を有する第３のコンピュータ（２０５）を備え、この第３のインスタンス（２１０）は、たとえばデータを備える共有ディスク（２２０）などの共有リソースにアクセスするように動作可能である。環境（２００）は、高可用性ソフトウェア・コンポーネントの第４のインスタンス（２２５）を有する第４のコンピュータ（２１５）も備え、この第４のインスタンス（２２５）も、共有ディスク（２２０）にアクセスするように動作可能である。

図１および図２の例では、環境（１００）がＨＡソフトウェアを備えるため、ソフトウェア・コンポーネントは保証された単一の活動化に対する責務を負う必要がない。図３の環境（２００）はＨＡソフトウェアを備えないため、ソフトウェア・コンポーネントは、両方のコンピュータ（２０５、２１５）からの協調性のない同時アクセスによって共有ディスク上のデータが破損されないことを保証できる必要がある。

ソフトウェア・コンポーネントの各インスタンスがそれぞれ単一のプロセスからなる場合、および、共有ディスク上のデータが少数のファイルにのみ含まれる場合、データの整合性が維持されることを保証するためには、共有ディスク上のデータ・ファイルのファイル・ロッキングを使用すれば十分である。

たとえば、一度にソフトウェア・コンポーネントの１つの実行インスタンスのみがデータ・ファイルの読み取りまたは書き込みを行っていることを保証するために、排他的ファイル・ロッキングを使用することができる。より複雑な手法では、ソフトウェア・コンポーネントの複数のインスタンスが協調性のないアクセスによってデータ・ファイルを破損しないことを保証するために、データ・ファイルの領域の「範囲ロッキング」を使用することができる。

ソフトウェア・コンポーネントがより複雑になった場合、さらなる改良が求められる。

好ましい実施形態の第１の態様によれば、第１の複数のプロセスを有する第１のソフトウェア・インスタンスと第２のソフトウェア・インスタンスとを備える環境で使用するために、データの整合性を維持するための装置が提供され、ここで、第１のソフトウェア・インスタンスおよび第２のソフトウェア・インスタンスはそれぞれ共有データにアクセスするように動作可能であり、共有データに関連付けられたファイルはロッキング用に使用され、この装置は、第１の階層ファイル・ロックが第１の複数のプロセスのうちの第１の親プロセスによって保持されないことに応答して、第２のインスタンスに代わって第１の階層ファイル・ロックを取得するための、第１のロック・コンポーネントと、第２のインスタンスに代わって第１の階層ファイル・ロックが取得されることに応答して、第２のロック・コンポーネントを活動化するための手段であって、第２のロック・コンポーネントは、第１の階層ファイル・ロックの子である第２の階層ファイル・ロックがいずれの第１の複数のプロセスによっても保持されないことに応答して、第２のインスタンスに代わって第２の階層ファイル・ロックを取得するように動作可能である、活動化するための手段と、第１のロック・コンポーネントが第１の階層ファイル・ロックを取得することに応答して、および、第２のロック・コンポーネントが第２の階層ファイル・ロックを取得することに応答して、第１のインスタンスが共有データにアクセスするのを防ぐため、および、第２のインスタンスが共有データにアクセスできるようにするための手段と、を備える。

好ましい実施形態の第２の態様によれば、第１の複数のプロセスを有する第１のソフトウェア・インスタンスと第２のソフトウェア・インスタンスとを備える環境で使用するために、データの整合性を維持するための方法が提供され、ここで、第１のソフトウェア・インスタンスおよび第２のソフトウェア・インスタンスはそれぞれ共有データにアクセスするように動作可能であり、共有データに関連付けられたファイルはロッキング用に使用され、この方法は、第１の階層ファイル・ロックが第１の複数のプロセスのうちの第１の親プロセスによって保持されないことに応答して、第２のインスタンスに代わって第１の階層ファイル・ロックを取得することと、第２のインスタンスに代わって第１の階層ファイル・ロックが取得されること、および、第１の階層ファイル・ロックの子である第２の階層ファイル・ロックがいずれの第１の複数のプロセスによっても保持されないことに応答して、第２のインスタンスに代わって第２の階層ファイル・ロックを取得することと、第１の階層ファイル・ロックおよび第２の階層ファイル・ロックが取得されることに応答して、第１のインスタンスが共有データにアクセスするのを防ぐこと、および、第２のインスタンスが共有データにアクセスできるようにすることと、を含む。

好ましい実施形態の第３の態様によれば、コンピュータ上で実行された場合に上記方法のすべてのステップを実行するように適合されたプログラム・コード手段を備える、コンピュータ・プログラムが提供される。

次に本発明について、以下の図面に示された好ましい諸実施形態を参照しながら、単なる例として説明する。

従来技術の高可用性の第１の環境を示すブロック図である。高可用性の第１の環境においてコンピュータの障害が発生した場合の、図１に示された従来技術の高可用性の第１の環境を示すブロック図である。従来技術の高可能性の第２の環境を示すブロック図である。好ましい実施形態に従った、高可用性の第２の環境を示すブロック図である。図４の環境の親プロセスに関連付けられたプロセスに含まれる動作ステップを示す流れ図である。図４の環境の子プロセスに関連付けられたプロセスに含まれる動作ステップを示す流れ図である。第１の親プロセスに関連付けられたコンポーネントを示すブロック図である。第２の親プロセスに関連付けられたコンポーネントを示すブロック図である。図７の親プロセスの第１の子プロセスに関連付けられたコンポーネントを示すブロック図である。図７の親プロセスの第２の子プロセスに関連付けられたコンポーネントを示すブロック図である。

ソフトウェア・コンポーネントの複数のインスタンスが、それぞれ、共有リソースのデータにアクセス可能な複数のプロセスを備える環境では、改良された手法が求められる。

本明細書の例では、ソフトウェア・コンポーネントの複数のインスタンスは、複数のコンピュータ上で同時に開始されることが可能である。各インスタンスはこの環境においてデータにアクセスするように動作可能であり、各インスタンスは１つまたは複数のオペレーティング・システム・プロセスを備える。

ソフトウェア・コンポーネントの各インスタンスは、「アクティブ」インスタンス（データの更新ができる）または「スタンバイ」インスタンス（データの更新ができない）のいずれかである。

いずれの時点でも、この環境は複数のアクティブ・インスタンスを備えないが、複数のスタンバイ・インスタンスは存在可能であり、これによって不可欠なプログラムの単一の活動化が保証される。

好ましいことに、単一のスタンバイ・インスタンスは、アクティブ・インスタンスの完全障害（すなわち、現行のアクティブ・インスタンスのあらゆるプロセスに関連付けられる障害）が発生した場合、新しいアクティブ・インスタンスとなることが可能である。より好ましいことに、アクティブ・インスタンスの部分障害（すなわち、現行のアクティブ・インスタンスのプロセスのサブセットには関連付けられるが、現行のアクティブ・インスタンスのあらゆるプロセスには関連付けられない障害）は、単一のスタンバイ・インスタンスが新しいアクティブ・インスタンスとなるのを防ぐ。

次に、好ましい実施形態の実装について、図面を参照しながら説明する。

図４は、高可用性ソフトウェア・コンポーネントの第５のインスタンス（３１０）を有する第５のコンピュータ（３０５）を備える、高可用性環境（３００）を示す。

第５のインスタンス（３１０）は複数のプロセス（３１１、３１２、および３１３）を備え、それぞれが、たとえばデータを備える共有ディスク（３２０）などの共有リソースにアクセスするように動作可能である。ある例では、共有ディスク（３２０）はネットワーク・ファイル・システムに関連付けられる。

第１のプロセス（３１１）は、２つの子プロセス（すなわち、第２のプロセス（３１２）および第３のプロセス（３１３））を有する親プロセスであり、この親プロセスが子プロセスを開始する。

環境（３００）は、高可用性ソフトウェア・コンポーネントの第６のインスタンス（３２５）を有する第６のコンピュータ（３１５）も備え、この第６のインスタンス（３２５）は、それぞれが共有ディスク（３２０）にアクセスするように動作可能な複数のプロセス（３２６、３２７、および３２８）を備える。

第４のプロセス（３２６）は、２つの子プロセス（すなわち、第５のプロセス（３２７）および第６のプロセス（３２８））を有する親プロセスであり、この親プロセスが子プロセスを開始する。

図７は第１のプロセス（３１１）に関連付けられたコンポーネントを示すブロック図であり、この第１のプロセス（３１１）は、それぞれが共有ディスク（３２０）にアクセスするように動作可能な、第１の監視コンポーネント（６００）および第１のロック・コンポーネント（６０５）を備える。第１のプロセス（３１１）は、第１のイニシエータ・コンポーネント（６１０）も備える。

図８は第４のプロセス（３２６）に関連付けられたコンポーネントを示すブロック図であり、この第４のプロセス（３２６）は、それぞれが共有ディスク（３２０）にアクセスするように動作可能な、第２の監視コンポーネント（６１５）および第２のロック・コンポーネント（６２０）を備える。第４のプロセス（３２６）は、第２のイニシエータ・コンポーネント（６２５）も備える。

図９は第２のプロセス（３１２）に関連付けられたコンポーネントを示すブロック図であり、この第２のプロセス（３１２）は、それぞれが共有ディスク（３２０）にアクセスするように動作可能な、第３の監視コンポーネント（７００）および第３のロック・コンポーネント（７０５）を備える。第２のプロセス（３１２）は、第１のターミネータ（７１０）も備える。

図１０は第３のプロセス（３１３）に関連付けられたコンポーネントを示すブロック図であり、この第３のプロセス（３１３）は、それぞれが共有ディスク（３２０）にアクセスするように動作可能な、第４の監視コンポーネント（７１５）および第４のロック・コンポーネント（７２０）を備える。第３のプロセス（３１３）は、第２のターミネータ（７２５）も備える。

好ましくは、親プロセスおよび子プロセスのそれぞれが１つまたは複数のロックにアクセスするように動作可能である。

共有ディスク（３２０）上に格納されたファイルはロッキング用に使用される。

本明細書の例では、排他モードでロック可能なマスタ・ロック、および、排他モードまたは共有モードでロック可能なアクティブ・ロックが提供される。

本発明は、通知ロック（advisorylock）または必須ロック（mandatory lock）と共に実装可能である。

好ましくは、ロックは、その親プロセスがロックを保持するインスタンスに関連付けられた識別子を備える。一例では、この識別子は、共有ディスク（３２０）でロッキング用に使用されるファイル内に格納される。他の例では、この識別子は、ロッキング用に使用されるファイルとは別のファイル内に格納される。

次に、ある例について、図４から図１０を参照しながら説明する。

ある例では、第１のプロセス（３１１）が実行を開始することによって、第５のインスタンス（３１０）を開始させる。

図５を参照すると、第１のプロセス（３１１）の第１の監視コンポーネント（６００）は、ロックの排他モードが取得可能かどうかを判別する（ステップ４００）ために、マスタ・ロックを監視する。

第１の監視コンポーネント（６００）はマスタ・ロック上で排他モードが取得可能であるものと決定し、これに応答して、第１のロック・コンポーネント（６０５）はマスタ・ロック上で排他モードを取得する。好ましくは、第１のプロセス（３１１）に関連付けられた識別子はマスタ・ロックに関連付けられる。

第１のプロセス（３１１）の第１の監視コンポーネント（６００）は、ロックの排他モードが取得可能かどうかを判別するために、アクティブ・ロックを監視する。

第１の監視コンポーネント（６００）はアクティブ・ロック上で排他モードが取得可能であるものと決定し、これに応答して、第１のロック・コンポーネント（６０５）はアクティブ・ロック上で当該排他モードを取得する。好ましくは、第１のプロセス（３１１）に関連付けられた識別子はアクティブ・ロックに関連付けられる。

これに応答して、第５のインスタンス（３１０）がアクティブ・インスタンスになる（すなわち、第５のインスタンス（３１０）が唯一のアクティブ・インスタンスになる）。

これに応答して、第１のロック・コンポーネント（６０５）はアクティブ・ロック上で排他モードをロック解除し、その後、共有モードでアクティブ・ロックをロックする。

第１のイニシエータ・コンポーネント（６１０）は、１つまたは複数の子プロセスを開始する。本明細書の例では、第１のイニシエータ・コンポーネント（６１０）は第２のプロセス（３１２）および第３のプロセス（３１３）を開始する。

別の方法として、第２のプロセス（３１２）および第３のプロセス（３１３）のうちの少なくとも１つを、（たとえば、第１のプロセス（３１１）とは別の他のプロセスによって）独立に開始することができる。

好ましくは、第２のプロセスおよび第３のプロセスは、アクティブ・ロックの保持者が第１のプロセスである旨を確認するまでは、いかなる作業も実行せず、第３の監視コンポーネント（７００）および第４の監視コンポーネント（７１５）のそれぞれは、識別子が第２のプロセスおよび第３のプロセスのそれぞれの親プロセスに関連付けられているかどうかを判別するために、アクティブ・ロックに関連付けられた識別子をチェックする。識別子が親プロセスに関連付けられていない場合、第２のプロセスおよび第３のプロセスは、親プロセスに障害が発生し、さらにそれらを終了しなければならないものと想定するが、この終了手順については以下でより詳細に説明する。

この例では、識別子は親プロセス（すなわち第１のプロセス（３１１））に関連付けられる。これに応答して、図６を参照すると、開始時に、第３の監視コンポーネント（７００）および第４の監視コンポーネント（７１５）のそれぞれは、ロックの共有モードが取得可能かどうかを判別する（ステップ５００）ために、アクティブ・ロックを監視する。

第３の監視コンポーネント（７００）は、アクティブ・ロック上で共有モードが取得可能であるものと決定し、これに応答して、第３のロック・コンポーネント（７０５）はアクティブ・ロック上で当該共有モードを取得する（ステップ５０５）。

第４の監視コンポーネント（７１５）は、アクティブ・ロック上で共有モードが取得可能であるものと決定し、これに応答して、第４のロック・コンポーネント（７２０）はアクティブ・ロック上で当該共有モードを取得する（ステップ５０５）。

したがって、第１のプロセス（３１１）はマスタ・ロックを排他モードで保持し、第１のプロセス（３１１）、第２のプロセス（３１２）、および第３のプロセス（３１３）のそれぞれは、アクティブ・ロックを共有モードで保持する。

結果として、他の単一インスタンスが新しいアクティブ・インスタンスになることはできず、第１のプロセス（３１１）、第２のプロセス（３１２）、および第３のプロセス（３１３）のそれぞれは、共有ディスク内のデータに安全にアクセスすることができる。第１のプロセス（３１１）、第２のプロセス（３１２）、および第３のプロセス（３１３）が同じインスタンス（すなわち、第５のインスタンス（３１０））に関連付けられているため、第１のプロセス（３１１）、第２のプロセス（３１２）、および第３のプロセス（３１３）による共有ディスク（３２０）へのアクセスは、既知の機構を使用して調整可能であることを理解されたい。

図５を参照すると、この例では、第４のプロセス（３２６）は第６のインスタンス（３２５）によって開始される。

第４のプロセス（３２６）の第４の監視コンポーネント（６１５）は、ロックの排他モードが取得可能であるかどうかを判別する（４００）ために、マスタ・ロックを監視する。

第４の監視コンポーネント（６１５）は、マスタ・ロック上で排他モードが取得できないものと決定するが、これは、マスタ・ロックの排他モードが第１のプロセス（３１１）によってすでに取得されているためである。

有利なことに、第４の監視コンポーネント（６１５）は、マスタ・ロックの排他モードが取得可能であるかどうかに関連付けられた決定を使用して、他のインスタンスがアクティブであるかどうかも判別することができる。第４の監視コンポーネント（６１５）がマスタ・ロックの排他モードを取得できない場合、第４の監視コンポーネント（６１５）は、他のインスタンスがマスタ・ロックの排他モードをすでに保持しているものと決定する。

ステップ４３０で、第６のインスタンス（３２５）は、新しいアクティブ・インスタンスとなるように再試行するかどうかを判別する。第６のインスタンス（３２５）が、新しいアクティブ・インスタンスとなるように再試行しないことに応答して、図５のプロセスは終了する。

第６のインスタンス（３２５）が、新しいアクティブ・インスタンスとなるように再試行することに応答して、第６のインスタンス（３２５）はスタンバイ・インスタンスとしてマークされる（ステップ４３５）。

この例では、第６のインスタンス（３２５）は新しいアクティブ・インスタンスとなるように再試行し（ステップ４３５）、その後、第４の監視コンポーネント（６１５）は、ロックの排他モードが取得可能かどうかを判別する（ステップ４００）ためにマスタ・ロックを監視する。

第４の監視コンポーネント（６１５）は、マスタ・ロック上で排他モードが取得可能であるものと決定するが、これは、この例において、マスタ・ロックの排他モードが第１のプロセス（３１１）のロック・コンポーネント（６０５）によって解除されている（たとえば、第１のプロセス（３１１）が作業を完了したために明示的に解除されている、第１のプロセス（３１１）に障害が発生したために暗黙的に解除されている）ためである。

その後、第４のロック・コンポーネント（７２０）は、マスタ・ロック上で排他モードを取得する（ステップ４０５）。

ここで第６のインスタンス（３２５）は、新しいアクティブ・インスタンスとなるように試行する。

これに応答して、その後第４の監視コンポーネント（６１５）は、ロックの排他モードが取得可能かどうかを判別する（ステップ４１０）ためにアクティブ・ロックを監視する。

第１の監視コンポーネント（６００）は、アクティブ・ロック上で排他モードが取得できないものと決定するが、本明細書の例では、これは、第２のプロセス（３１２）または第３のプロセス（３１３）のうちの少なくとも１つが、依然としてアクティブ・ロックを共有モードで保持しているためである。

その後、第４のロック・コンポーネント（７２０）はマスタ・ロック上で排他モードを解除し、第６のインスタンス（３２５）はスタンバイ・インスタンスを維持する（ステップ４３０）。

好ましい実施形態は、「階層」ロック、すなわちマスタ・ロックおよびアクティブ・ロックを提供し、ここで最初にマスタ・ロックが取得され、続いてアクティブ・ロックが取得できることを理解されたい。本発明は、階層ロックを使用することにより、現行のアクティブ・インスタンスの親プロセスは終了可能であるが、関連付けられた子プロセスはまだ終了しないように、タイミング・ウィンドウを調節し、その結果として、マスタ・ロック上の排他モードは親プロセスによって解除され、アクティブ・ロック上の共有モードは子プロセスによって解除されないようにすることによって、信頼性を与える。したがって、たとえ第４のプロセス（３２６）がマスタ・ロック上で排他モードを取得できる場合（すなわち、第２のプロセス（３１２）または第３のプロセス（３１３）のうちの少なくとも１つが依然としてアクティブ・ロックを維持していることによって、第４のプロセス（３２６）がアクティブ・ロック上で排他モードを取得できないため）であっても、第６のインスタンス（３２５）はスタンバイ・インスタンスを維持する。

第６のインスタンス（３２５）が新しいアクティブ・インスタンスになるように再試行しない（ステップ４３５）ことに応答して、プロセスは終了する。

この例では、第６のインスタンス（３２５）が新しいアクティブ・インスタンスになるように再試行する（ステップ４３５）ことに応答して、第４の監視コンポーネント（６１５）は、ロックの排他モードが取得できるかどうかを判別する（ステップ４００）ためにマスタ・ロックを監視する。

第４の監視コンポーネント（６１５）は、マスタ・ロック上で排他モードが取得できるものと決定するが、この例では、これは、マスタ・ロックの排他モードが第１のプロセス（３１１）の第１のロック・コンポーネント（６０５）によって解除されているためである。

その後、第４のロック・コンポーネント（７２０）はマスタ・ロック上で排他モードを取得する。

第４の監視コンポーネント（６１５）は、その後、ロックの排他モードが取得できるかどうかを判別するため（ステップ４１０）にアクティブ・ロックを監視する。

第１の監視コンポーネント（６００）は、排他モードがアクティブ・ロック上で取得できるものと決定するが、この例では、これは、第２のプロセス（３１２）または第３のプロセス（３１３）のいずれも、依然としてアクティブ・ロックを共有モードで保持していないためである。

第２のプロセス（３１２）または第３のプロセス（３１３）のいずれもアクティブ・ロックを共有モードで保持していないというイベントは、たとえば、第２のプロセスおよび第３のプロセスのそれぞれが明示的または暗黙的に終了されることによって、あるいは、第１のプロセス（３１１）が（明示的に、または障害によって暗黙的に）終了し、その後、第３の監視コンポーネント（７００）および第４の監視コンポーネント（７１５）のそれぞれが、第１のプロセス（３１１）がポーリング機能を使用することで終了したものと決定する（ステップ５１０）ことによって、発生する可能性があり、その後、第２のプロセスおよび第３のプロセスそれぞれの第１のターミネータ（７１０）および第２のターミネータ（７２５）それぞれが終了し（ステップ５２０）、共有モードのアクティブ・ロックを解除する。第１のプロセス（３１１）が終了していない場合、子プロセスは作業を続行可能である（ステップ５１５）ことを理解されたい。

第１の監視コンポーネント（６００）が、アクティブ・ロック上で排他モードが取得可能であるものと決定することに応答して、第４のロック・コンポーネント（７２０）はアクティブ・ロック上で当該排他モードを取得する。

これに応答して、第６のインスタンス（３２５）が新しいアクティブ・インスタンスとなる。

前述の例では、実行中の第５のインスタンス（３１０）の子プロセス（すなわち、前のアクティブ・インスタンス）が存在しないため、第４のロック・コンポーネント（７２０）は、アクティブ・ロック上で排他モードを取得するように動作可能であることを理解されたい。さらに、第５のインスタンス（３１０）に関連付けられたそれぞれのプロセス（３１１、３１２、および３１３）が実行中でないため、第４のロック・コンポーネント（７２０）は、マスタ・ロック上およびアクティブ・ロック上のそれぞれで排他モードを取得するように動作可能である。

他の実装では、複数のアクティブ・ロックが提供される。好ましくは、マスタ・ロック上の排他モードが解除されている場合、アクティブ・インスタンスのすべてのプロセスは、他のインスタンスが新しいアクティブ・インスタンスとなるように試行できるようにするために、複数のアクティブ・ロックのすべてを解除しなければならない。

その後、第４のロック・コンポーネント（７２０）はアクティブ・ロック上の排他モードをロック解除し、その後、アクティブ・ロックを共有モードでロックする。

第２のイニシエータ・コンポーネント（６２５）は、１つまたは複数の子プロセス、たとえば第５のプロセス（３２７）および第６のプロセス（３２８）を開始することができる。

有利なことに、本発明は、各インスタンスが複数のプロセスを備えることが可能な環境において、インスタンスの高可用性（たとえば、あるインスタンスが新しいアクティブ・インスタンスになることができる）、ならびに、ソフトウェア・コンポーネントの１つのインスタンスのみが一度に共有データにアクセスできるような保証された単一の活動化（たとえば、たとえば排他マスタ・ロックおよび排他／共有アクティブ・ロックなどの「階層」ロッキングを使用することによって）を、可能にする。

有利なことに、他のインスタンスの位置を用いてインスタンスを構成する必要はなく、単一の活動化を保証するためにネットワークがインスタンス間でハートビート（heartbeating）する必要はない。これは、ファイル・ロッキングを使用して単一の活動化を保証できるためである。有利なことに、障害の発生したインスタンスに関連付けられたデータ（たとえば、障害の発生したインスタンスが実行されていた場所に関連付けられた場所）を知る必要なしに、障害の発生したインスタンスをスタンバイ・インスタンスに置き換えることができる。

有利なことに、ＨＡソフトウェアは不要である。これによって有用性が増加し、より容易にスタンバイ・インスタンスを導入することができる。

さらに、たとえばネットワークの故障停止があった場合、ロックを保持するプロセスの識別子のロックとの関連付けが有利である。故障停止に続き、親プロセスはロックを再取得し、識別子がそれ自体のものであるかどうかを判別するために、識別子に問い合わせることができる。識別子がそれ自体のものである場合、プロセスは、故障停止以前にロックを保持していたこと、および、故障停止中に他のいずれのインスタンスもロックを取得しなかったことがわかる。識別子がそれ自体のものでない場合、プロセスは、故障停止中に他のインスタンスがロックを取得しなければならなかったことがわかり、この場合、親プロセスおよびインスタンスに関連付けられた他のプロセスは、整合性を保証するためにインスタンスを終了しなければならない（また、必要であれば、親プロセスはロックを取得するために再実行および試行することができる）。

複数のスタンバイ・インスタンスが存在する場合、好ましくは、現行のアクティブ・インスタンスがもはやアクティブ・インスタンスでなければ、新しいアクティブ・インスタンスとなるように単一のスタンバイ・インスタンスを選択するために選択プロセスが実装され、ここで、たとえば複数のスタンバイ・インスタンスは新しいアクティブ・インスタンスとなるように競合し、複数のスタンバイ・インスタンスは、どちらが新しいアクティブ・インスタンスとなるかを決定することを理解されたい。別の方法として、他のロック・ファイルを使用して、スタンバイ・インスタンスを調整および監視することができる。

Claims

第１の複数のプロセスを有する第１のソフトウェア・インスタンスと第２のソフトウェア・インスタンスとを備える環境で使用され、データの整合性を維持するための装置であって、前記第１のソフトウェア・インスタンスおよび前記第２のソフトウェア・インスタンスはそれぞれ共有データにアクセスするように動作可能であり、前記共有データに関連付けられたファイルはロッキング用に使用され、
前記第２のソフトウェア・インスタンスの各プロセスが、第１のロック・コンポーネント、第２のロック・コンポーネント、及び、第２のロック・コンポーネントを活動化するための手段を有するものであって、
第１の階層ファイル・ロックが前記第１の複数のプロセスのうちの第１の親プロセスによって保持されないことに応答して、前記第２のインスタンスに代わって前記第１の階層ファイル・ロックを取得するための、第１のロック・コンポーネントと、
前記第２のインスタンスに代わって前記第１の階層ファイル・ロックが取得されることに応答して、第２のロック・コンポーネントを活動化するための手段であって、前記第２のロック・コンポーネントは、前記第１の階層ファイル・ロックの子である第２の階層ファイル・ロックがいずれの前記第１の複数のプロセスによっても保持されないことに応答して、前記第２のインスタンスに代わって前記第２の階層ファイル・ロックを取得するように動作可能である、活動化するための手段と、
前記第１のロック・コンポーネントが前記第１の階層ファイル・ロックを取得することに応答して、および、前記第２のロック・コンポーネントが前記第２の階層ファイル・ロックを取得することに応答して、前記第１のインスタンスが共有データにアクセスするのを防ぐため、および、第２のインスタンスが前記共有データにアクセスできるようにするための手段と、
を備える、装置。
前記第２のソフトウェア・インスタンスの各プロセスが、さらに、第２の監視コンポーネントを有していて、
前記第２のロック・コンポーネントは、第２の監視コンポーネントが、前記第１の複数のプロセスのうちの少なくとも１つによって第２の階層ファイル・ロックが取得されたものと決定することに応答して、前記第２のインスタンスに代わって前記第２の階層ファイル・ロックを取得するのを防ぐように動作可能である、請求項１に記載の装置。
前記第２のソフトウェア・インスタンスは第２の複数のプロセスを備え、前記第２のロック・コンポーネントは、前記第２の複数のプロセスのうちの少なくとも１つに代わって前記第２の階層ファイル・ロックを取得するように動作可能である、請求項１に記載の装置。
前記第１の階層ファイル・ロックが取得されるように使用可能であるかどうかを判別するための、第１の監視コンポーネントをさらに備える、請求項１に記載の装置。
前記第２の階層ファイル・ロックが取得されるように使用可能であるかどうかを判別するための、第２の監視コンポーネントをさらに備える、請求項１に記載の装置。
第１の複数のプロセスを有する第１のソフトウェア・インスタンスと第２のソフトウェア・インスタンスとを備える環境で使用され、データの整合性を維持するための方法であって、前記第１のソフトウェア・インスタンスおよび前記第２のソフトウェア・インスタンスはそれぞれ共有データにアクセスするように動作可能であり、前記共有データに関連付けられたファイルはロッキング用に使用され、
前記第２のソフトウェア・インスタンスの各プロセスが、第１のロック・コンポーネント、第２のロック・コンポーネント、及び、第２のロック・コンポーネントを活動化するための手段を有するものであって、
第１の階層ファイル・ロックが前記第１の複数のプロセスのうちの第１の親プロセスによって保持されないことに応答して、前記第２のインスタンスに代わって前記第１の階層ファイル・ロックを取得すること、
前記第２のインスタンスに代わって前記第１の階層ファイル・ロックが取得されること、および、前記第１の階層ファイル・ロックの子である第２の階層ファイル・ロックがいずれの前記第１の複数のプロセスによっても保持されないことに応答して、前記第２のインスタンスに代わって第２の階層ファイル・ロックを取得すること、および
前記第１の階層ファイル・ロックおよび前記第２の階層ファイル・ロックが取得されることに応答して、前記第１のインスタンスが前記共有データにアクセスするのを防ぐこと、および、前記第２のインスタンスが前記共有データにアクセスできるようにすること、
を含み、
これらのことをハードウェア技術とソフトウェア技術とが組み合わされたコンピュータに実行させる、方法。
コンピュータ上で実行された場合に請求項６に記載の方法を実行するように適合されたプログラム・コードを備える、コンピュータ・プログラム。