(57)【要約】【課題】リザーブ排他が可能であり、フェールオーバが発生した場合であっても、データ破損が発生せず、共有ディスク装置内のデータの整合を図るクラスタシステムを提供する。【解決手段】クラスタソフト１２（＃Ａ）が稼動系の場合には、ＱＵＯＲＵＭ用領域１７内のコミット権管理テーブルを変更してサーバマシン１０（＃Ａ）のみにコミット権が付与されるようにしてアプリケーション１１（＃Ａ）を起動させる。フィルタドライバ２１（＃Ａ）は、マスター領域３０への読取要求がなされると、読取要求データがサーバマシンのキャッシュ領域にあればここから読み取り、他にもあればマスター領域から読み取る。Ｉ／Ｏ入力がマスター領域への書込要求であり、サーバマシンのキャッシュ領域に空き容量がなく、自サーバマシンにコミット権が付与されているのであれば、キャッシュ領域のデータをマスター領域にコピーしてキャッシュ領域をクリアする。【選択図】      図１
2008242741.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバマシンと、前記複数のサーバマシンに接続された共有ディスク装置とから構成されたクラスタシステムであって、
前記複数のサーバマシンは、前記複数のサーバマシン上でそれぞれ動作するアプリケーションと、前記複数のサーバマシン上でそれぞれ動作するクラスタソフトと、前記複数のサーバマシン上でそれぞれ動作するフィルタドライバとを備え、
前記共有ディスク装置は、前記アプリケーションのデータを格納するマスター領域と、前記各サーバマシンのデータを格納する各サーバ用領域と、前記各サーバマシンで共有する共通領域とを備え、
各サーバ用領域は、それぞれデータを格納するためのキャッシュ領域及びパッチ領域を備え、
前記共通領域は、前記キャッシュ領域に格納されたデータの、前記マスター領域へのコピー許可であるコミット権が付与されたサーバマシンを規定したコミット権管理部を備え、
前記複数のサーバマシンに備えられた各クラスタソフトは、互いに定期的に通信して互いの生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持ち、
前記クラスタソフトが稼動系の場合には、
前記クラスタソフトは、前記コミット権管理部を変更して自サーバマシンのみに前記コミット権が付与されるようにし、前記自サーバマシン側から前記マスター領域が見える状態にし、前記自サーバマシンに備えられたアプリケーションを起動させ、
前記自サーバマシンに備えられたフィルタドライバは、Ｉ／Ｏ入力を待ち、前記Ｉ／Ｏ入力が前記マスター領域への読取要求だった場合には、読取要求データの一部または全部が自サーバマシン用のキャッシュ領域にあれば前記キャッシュ領域から読み取り、前記読取要求データが他にもあれば前記マスター領域から読み取り、読み取ったデータを、前記読取要求をした前記Ｉ／Ｏ入力側に返し、前記Ｉ／Ｏ入力が前記マスター領域への書込要求だった場合であり、自サーバマシン用のキャッシュ領域に書き込むための空き容量がなく、自サーバマシンにコミット権が付与されているのであれば、前記キャッシュ領域のデータを前記マスター領域にコピーして前記キャッシュ領域をクリアし、自サーバマシンにコミット権が付与されていないのであれば前記書込要求をしたＩ／Ｏ入力側にエラーを返し、しかる後に前記マスター領域における書き込み位置情報と書き込んだデータとを自サーバマシン用のキャッシュ領域に書き込み、この書き込み結果を前記書込要求をしたＩ／Ｏ入力側に返し、前記Ｉ／Ｏ入力が前記マスター領域への読取要求でも書込要求でもない場合には、前記自サーバマシンに備えられたフィルタドライバの下位側に前記Ｉ／Ｏ入力によるデータを受け渡し、返り値を前記Ｉ／Ｏ入力側へ返し、
前記クラスタソフトが待機系の場合であって、前記待機系のクラスタソフトが、稼動系のクラスタソフトが生存していないと判定した場合には、
前記判定したクラスタソフトは、前記コミット権管理部を変更して自サーバマシンにのみコミット権が付与されるようにし、前記稼動系のクラスタソフトが備えられているサーバマシン用のキャッシュ領域のデータを自サーバマシン用の前記パッチ領域にコピーして前記パッチ領域を前記マスター領域の一部として代用し、自サーバマシン側から前記マスター領域が見えるようにし、自サーバマシンに備えられたアプリケーションを起動し、
前記自サーバマシン上に備えられたフィルタドライバは、前記自サーバマシンに備えられたクラスタソフトが稼動系になった後、Ｉ／Ｏ入力を待ち、前記Ｉ／Ｏ入力が前記マスター領域への読取要求だった場合には、読取要求データの一部または全部が自サーバマシン用のパッチ領域にあれば前記パッチ領域から読み取り、読取要求データの一部または全部が自サーバマシン用のキャッシュ領域にあれば前記キャッシュ領域から読み取り、読取要求データが他にもあれば前記マスター領域から読み取り、読み取ったデータを、前記読取要求したＩ／Ｏ入力側に返し、前記Ｉ／Ｏ入力が前記マスター領域への書込要求だった場合には、書込要求先の全部が自サーバマシン用のパッチ領域にあれば前記パッチ領域に書き込んで前記Ｉ／Ｏ入力側に返し、そうでない場合には前記パッチ領域に該当するデータのみを前記パッチ領域に書き込み、自サーバマシン用のキャッシュ領域に書き込むための空き容量が無ければ前記コミット権管理部を参照して自サーバマシンにコミット権が付与されているか否かを確認し、付与されているなら前記マスター領域に自サーバマシン用のキャッシュ領域のデータをコピーして前記キャッシュ領域をクリアし、付与されていないなら前記Ｉ／Ｏ入力側にエラーを返し、しかる後に前記マスター領域における書き込み位置情報と書き込んだデータとを自サーバマシン用のキャッシュ領域に書き込み、前記Ｉ／Ｏ入力側に返し、前記Ｉ／Ｏ入力が前記マスター領域への読取要求でも書込要求でもない場合には、前記自サーバマシンに備えられたフィルタドライバの下位層に前記Ｉ／Ｏ入力によるデータを受け渡し、返り値を前記Ｉ／Ｏ入力側へ返す
ようにしたクラスタシステム。
【請求項２】
複数のサーバマシンと、前記複数のサーバマシンに接続された共有ディスク装置とから構成されたクラスタシステムに適用されるプログラムであって、
前記複数のサーバマシンは、前記複数のサーバマシン上でそれぞれ動作するアプリケーションと、前記複数のサーバマシン上でそれぞれ動作するクラスタソフトと、前記複数のサーバマシン上でそれぞれ動作するフィルタドライバとを備え、
前記共有ディスク装置は、前記アプリケーションのデータを格納するマスター領域と、前記各サーバマシンのデータを格納する各サーバ用領域と、前記各サーバマシンで共有する共通領域とを備え、
各サーバ用領域は、それぞれデータを格納するためのキャッシュ領域及びパッチ領域を備え、
前記共通領域は、前記キャッシュ領域に格納されたデータの、前記マスター領域へのコピー許可であるコミット権が付与されたサーバマシンを規定したコミット権管理部を備え、
前記複数のサーバマシンに備えられた各クラスタソフトは、互いに定期的に通信して互いの生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持ち、
前記プログラムは、前記クラスタソフトが稼動系の場合には、
前記クラスタソフトが、前記コミット権管理部を変更して自サーバマシンのみに前記コミット権が付与されるようにし、前記自サーバマシン側から前記マスター領域が見える状態にし、前記自サーバマシンに備えられたアプリケーションを起動させる機能、
前記自サーバマシンに備えられたフィルタドライバが、Ｉ／Ｏ入力を待ち、前記Ｉ／Ｏ入力が前記マスター領域への読取要求だった場合には、前記自サーバマシン用のキャッシュ領域を参照し、読取要求データの一部または全部が自サーバマシン用のキャッシュ領域にあれば前記キャッシュ領域から読み取り、前記読取要求データが他にもあれば前記マスター領域から読み取り、読み取ったデータを、前記読取要求をした前記Ｉ／Ｏ入力側に返し、前記Ｉ／Ｏ入力が前記マスター領域への書込要求だった場合であり、自サーバマシン用のキャッシュ領域に書き込むための空き容量がなく、自サーバマシンにコミット権が付与されているのであれば、前記キャッシュ領域のデータを前記マスター領域にコピーして前記キャッシュ領域をクリアし、自サーバマシンにコミット権が付与されていないのであれば前記書込要求をしたＩ／Ｏ入力側にエラーを返し、しかる後に前記マスター領域における書き込み位置情報と書き込んだデータとを自サーバマシン用のキャッシュ領域に書き込み、この書き込み結果を前記書込要求をしたＩ／Ｏ入力側に返し、前記Ｉ／Ｏ入力が前記マスター領域への読取要求でも書込要求でもない場合には、前記自サーバマシンに備えられたフィルタドライバの下位側に前記Ｉ／Ｏ入力によるデータを受け渡し、返り値を前記Ｉ／Ｏ入力側へ返す機能をコンピュータに実現させ、
前記プログラムは更に、前記クラスタソフトが待機系の場合には、
前記待機系のクラスタソフトが、稼動系のクラスタソフトが生存しているか否かを判定し、生存していないと判定した場合、前記待機系のクラスタソフトが、前記コミット権管理部を変更して自サーバマシンにのみコミット権が付与されるようにし、前記稼動系のクラスタソフトが備えられているサーバマシン用のキャッシュ領域のデータを自サーバマシン用の前記パッチ領域にコピーして前記パッチ領域を前記マスター領域の一部として代用し、自サーバマシン側から前記マスター領域が見えるようにし、自サーバマシンに備えられたアプリケーションを起動する機能、
前記自サーバマシン上に備えられたフィルタドライバが、前記自サーバマシンに備えられたクラスタソフトが稼動系になった後、Ｉ／Ｏ入力を待ち、前記Ｉ／Ｏ入力が前記マスター領域への読取要求だった場合には、読取要求データの一部または全部が自サーバマシン用のパッチ領域にあれば前記パッチ領域から読み取り、前記自サーバマシン用のキャッシュ領域を参照し、読取要求データの一部または全部が自サーバマシン用のキャッシュ領域にあれば前記キャッシュ領域から読み取り、読取要求データが他にもあれば前記マスター領域から読み取り、読み取ったデータを、前記読取要求したＩ／Ｏ入力側に返し、前記Ｉ／Ｏ入力が前記マスター領域への書込要求だった場合には、書込要求先の全部が自サーバマシン用のパッチ領域にあれば前記パッチ領域に書き込んで前記Ｉ／Ｏ入力側に返し、そうでない場合には前記パッチ領域に該当するデータのみを前記パッチ領域に書き込み、自サーバマシン用のキャッシュ領域に書き込むための空き容量が無ければ前記コミット権管理部を参照して自サーバマシンにコミット権が付与されているか否かを確認し、付与されているなら自サーバマシン用のキャッシュ領域のデータを前記マスター領域にコピーして前記キャッシュ領域をクリアし、付与されていないなら前記Ｉ／Ｏ入力側にエラーを返し、しかる後に前記マスター領域における書き込み位置情報と書き込んだデータとを自サーバマシン用のキャッシュ領域に書き込み、前記Ｉ／Ｏ入力側に返し、前記Ｉ／Ｏ入力が前記マスター領域への読取要求でも書込要求でもない場合には、前記自サーバマシンに備えられたフィルタドライバの下位層に前記Ｉ／Ｏ入力によるデータを受け渡し、返り値を前記Ｉ／Ｏ入力側へ返す機能
をコンピュータに実現させるためのプログラム。
【請求項３】
請求項２に記載のプログラムにおいて、
前記各フィルタドライバは、自サーバマシンのキャッシュ領域と同じデータを持つメモリキャッシュ領域をそれぞれ備え、
前記自サーバマシン用のキャッシュ領域を参照する代わりに、前記自サーバマシン用のメモリキャッシュ領域を参照し、前記マスター領域における書き込み位置情報と書き込んだデータとを自サーバマシン用のキャッシュ領域に書き込む代わりに、前記自サーバマシン用のメモリキャッシュ領域およびキャッシュ領域に書き込み、前記キャッシュ領域のデータを前記マスター領域にコピーする代わりに、前記メモリキャッシュ領域のデータを前記マスター領域にコピーするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバマシンと共有ディスク装置とから構成されたクラスタシステム及びプログラムに関し、特に、フェールオーバが発生した場合であっても、共有ディスク装置内のデータの整合を図ることが可能なクラスタシステム及びプログラムに関する。
【背景技術】
【０００２】
例えば、非特許文献１で開示されているクラスタシステムでは、図１６に示すように、稼動系のサーバマシン１０（＃Ａ）と待機系のサーバマシン１０（＃Ｂ）とが設けられ、稼動系のサーバマシン１０（＃Ａ）がアプリケーション１１（＃Ａ）を実行し、（ｉ）に示すように、実行結果であるデータを共有ディスク装置１３に書き込む。その間、（ｉｉ）に示すように、稼動系のサーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）と待機系のサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）とは、通信路１４を経由して、ハートビートａと呼ばれる所定のパケット交換をし続け、互いの生存を通知し合う。
【０００３】
そして、待機系のサーバマシン１０（＃Ｂ）がハートビートａの断絶を検出した場合に、（ｉｉｉ）に示すように、待機系のサーバマシン１０（＃Ｂ）で同一のアプリケーション１１（＃Ｂ）を起動させることでアプリケーション処理を継続させる、所謂フェールオーバｂが一般に行われている。
【０００４】
ハートビートａが断絶する理由としては主に以下がある。  
（１）稼動系のサーバマシン１０（＃Ａ）のダウン。  
（２）通信路１４の障害。  
（３）稼動系のサーバマシン１０（＃Ａ）におけるＣＰＵ高負荷等による一時的なスローダウンの発生。
【０００５】
上記（１）の場合であれば、単純に待機系のサーバマシン１０（＃Ｂ）にフェールオーバｂすれば良いが、上記（２）及び（３）の場合には稼動系のサーバマシン１０（＃Ａ）が処理を継続するため、フェールオーバｂしてしまうと以下に示すような不都合が生じる。
【０００６】
すなわち、図１６に示すように、複数台のサーバマシン１０（＃Ａ，＃Ｂ）が同一の共有ディスク装置１３に接続された状態でクラスタ構成を組む場合、上記（２）及び（３）が原因のハートビートａの断絶によりフェールオーバｂが行われると、図１７に示すように、稼動系のサーバマシン１０（＃Ａ）と待機系のサーバマシン１０（＃Ｂ）との両系が共有ディスク装置１３内の同一のデータ領域１５に書き込みを行う可能性があり、その場合、共有ディスク装置１３内のデータの整合性が失われ、データが破壊されてしまう恐れがある。
【０００７】
このため、従来のクラスタシステムでも、この不都合に対する対策が幾つか施されている。以下、この対策を施した従来技術を２つ紹介する。
【０００８】
第１の従来技術は、上記（１）乃至（３）に対処するものであり、ＳＣＳＩ仕様として定義されているリザーブ排他機能が使用され、１つのＬＵ（Logical Unit）につきＩ／Ｏ（ｒｅａｄやｗｒｉｔｅ）を発行可能なサーバが１つに絞られている。つまり、図１８の（ｉ）に示すようにハートビートａ切れが検出され、（ｉｉ）に示すように待機系のサーバマシン１０（＃Ｂ）にフェールオーバｂする際、（ｉｉｉ）に示すように待機系のサーバマシン１０（＃Ｂ）が共有ディスク装置１３内の対象ＬＵをリザーブし、（ｉｖ）に示すように稼動系のサーバマシン１０（＃Ａ）がそれ以上対象ＬＵに書き込みを行うのを防いでから、アプリケーション１１（＃Ｂ）を起動し、（ｖ）に示すように共有ディスク装置１３への書き込みを行うようにしている。
【０００９】
第２の従来技術は、上記（１）及び（２）に対処するものであり、図１９に示すように、ＱＵＯＲＵＭ用領域１７と呼ばれる特殊なＬＵを共有ディスク装置１３内に設け、（ｉｉｉ）に示すように、クラスタを構成するサーバマシン１０（＃Ａ，＃Ｂ）からその時々の現在時刻を定期的に書き込むことで、（ｉ）に示すハートビートａ以外にサーバマシン１０（＃Ａ，＃Ｂ）の状態を監視する。
【００１０】
第２の従来技術によれば、通信路１４の障害が理由で待機系のサーバマシン１０（＃Ｂ）がハートビートａ断絶を確認した場合でも、待機系のサーバマシン１０（＃Ｂ）がＱＵＯＲＵＭ用領域１７を参照する。ＱＵＯＲＵＭ用領域１７は、通信路１４に障害があっても参照可能であるので、稼動系のサーバマシン１０（＃Ａ）が現在時刻のｗｒｉｔｅを継続していることを確認することができ、稼動系のサーバマシン１０（＃Ａ）がダウンしていないことを知ることができる。
【非特許文献１】東芝レビュー  Ｖｏｌ．５４  Ｎｏ．１２（１９９９）、１８〜２１ページ
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、このような従来のクラスタシステムでは、以下のような問題がある。
【００１２】
まず、第１の従来技術の場合、図１８の（ｉｉｉ）及び（ｉｖ）に示すようなリザーブ排他が可能な否かは、共有ディスク装置１３や、そのマルチパスドライバ（図示せず）の実装に依存するという問題がある。そのため、新しい共有ディスク装置１３やそのマルチパスドライバに対応するためには、毎回検証することが必要になる。また、共有ディスク装置１３やそのマルチパスドライバによって、細かな制限事項が付きがちである。例えば、ある共有ディスク装置１３では、ディスクＩ／Ｏの物理的なパスが多重化されている環境で片パス障害が起きると、リザーブが維持されない状態に陥ってしまい、排他できなくなってしまう。
【００１３】
また、第２の従来技術の場合、例えば、図２０に示すように、（ｉ）稼動系のサーバマシン１０（＃Ａ）がｗｒｉｔｅ中にＣＰＵ高負荷に陥りスローダウンしてしまった場合には、（ｉｉ）待機系のサーバマシン１０（＃Ｂ）はハートビートａ切れを検出し、稼動系のサーバマシン１０（＃Ａ）がダウンしたと思ってしまい、（ｉｉｉ）フェールオーバｂを実施してしまう。これにより、（ｉｖ）待機系のサーバマシン１０（＃Ｂ）は、ＱＵＯＲＵＭ用領域１７に現在時刻を書き込むとともに、（ｖ）アプリケーションデータ用領域１８のデータ領域１５にデータをｗｒｉｔｅする。
【００１４】
一方、（ｖｉ）稼動系のサーバマシン１０（＃Ａ）も停止した訳ではないので、スローダウンした状態でＱＵＯＲＵＭ用領域１７に現在時刻を書き込むとともに、（ｖｉｉ）復帰直後から、アプリケーションデータ用領域１８のデータ領域１５へのデータのｗｒｉｔｅを継続する。
【００１５】
このように、稼動系のサーバマシン１０（＃Ａ）がスローダウンから復帰した直後に、両サーバから同じＬＵへの書き込みが行われ、データ破壊が発生する可能性があるという問題がある。
【００１６】
本発明はこのような事情に鑑みてなされたものであり、複数のサーバマシンと共有ディスク装置とから構成されたクラスタシステムにおいて、共有ディスク装置やそのマルチパスドライバの実装に依存せずにリザーブ排他が可能であり、かつ、フェールオーバが発生した場合であっても、複数のサーバマシンの書き込みによるデータ破損を発生させることなく、共有ディスク装置内のデータの整合を図ることが可能なクラスタシステム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１７】
上記の目的を達成するために、本発明では、以下のような手段を講じる。
【００１８】
すなわち、請求項１の発明は、複数のサーバマシンと、複数のサーバマシンに接続された共有ディスク装置とから構成されたクラスタシステムであって、複数のサーバマシンは、複数のサーバマシン上でそれぞれ動作するアプリケーションと、複数のサーバマシン上でそれぞれ動作するクラスタソフトと、複数のサーバマシン上でそれぞれ動作するフィルタドライバとを備え、共有ディスク装置は、アプリケーションのデータを格納するマスター領域と、各サーバマシンのデータを格納する各サーバ用領域と、各サーバマシンで共有する共通領域とを備え、各サーバ用領域は、それぞれデータを格納するためのキャッシュ領域及びパッチ領域を備え、共通領域は、キャッシュ領域に格納されたデータの、マスター領域へのコピー許可であるコミット権が付与されたサーバマシンを規定したコミット権管理部を備え、複数のサーバマシンに備えられた各クラスタソフトは、互いに定期的に通信して互いの生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持っている。
【００１９】
そして、クラスタソフトが稼動系の場合には、クラスタソフトは、コミット権管理部を変更して自サーバマシンのみにコミット権が付与されるようにし、自サーバマシン側からマスター領域が見える状態にし、自サーバマシンに備えられたアプリケーションを起動させる。また、自サーバマシンに備えられたフィルタドライバは、Ｉ／Ｏ入力を待ち、Ｉ／Ｏ入力がマスター領域への読取要求だった場合には、読取要求データの一部または全部が自サーバマシン用のキャッシュ領域にあればキャッシュ領域から読み取り、読取要求データが他にもあればマスター領域から読み取り、読み取ったデータを、読取要求をしたＩ／Ｏ入力側に返し、Ｉ／Ｏ入力がマスター領域への書込要求だった場合であり、自サーバマシン用のキャッシュ領域に書き込むための空き容量がなく、自サーバマシンにコミット権が付与されているのであれば、キャッシュ領域のデータをマスター領域にコピーしてキャッシュ領域をクリアし、自サーバマシンにコミット権が付与されていないのであれば書込要求をしたＩ／Ｏ入力側にエラーを返し、しかる後にマスター領域における書き込み位置情報と書き込んだデータとを自サーバマシン用のキャッシュ領域に書き込み、この書き込み結果を書込要求をしたＩ／Ｏ入力側に返し、Ｉ／Ｏ入力がマスター領域への読取要求でも書込要求でもない場合には、自サーバマシンに備えられたフィルタドライバの下位側にＩ／Ｏ入力によるデータを受け渡し、返り値をＩ／Ｏ入力側へ返す。
【００２０】
一方、クラスタソフトが待機系の場合であって、待機系のクラスタソフトが、稼動系のクラスタソフトが生存していないと判定した場合には、判定したクラスタソフトは、コミット権管理部を変更して自サーバマシンにのみコミット権が付与されるようにし、稼動系のクラスタソフトが備えられているサーバマシン用のキャッシュ領域のデータを自サーバマシン用のパッチ領域にコピーしてパッチ領域をマスター領域の一部として代用し、自サーバマシン側からマスター領域が見えるようにし、自サーバマシンに備えられたアプリケーションを起動する。そして、自サーバマシン上に備えられたフィルタドライバは、自サーバマシンに備えられたクラスタソフトが稼動系になった後、Ｉ／Ｏ入力を待ち、Ｉ／Ｏ入力がマスター領域への読取要求だった場合には、読取要求データの一部または全部が自サーバマシン用のパッチ領域にあればパッチ領域から読み取り、読取要求データの一部または全部が自サーバマシン用のキャッシュ領域にあればキャッシュ領域から読み取り、読取要求データが他にもあればマスター領域から読み取り、読み取ったデータを、読取要求したＩ／Ｏ入力側に返し、Ｉ／Ｏ入力がマスター領域への書込要求だった場合には、書込要求先の全部が自サーバマシン用のパッチ領域にあればパッチ領域に書き込んでＩ／Ｏ入力側に返し、そうでない場合にはパッチ領域に該当するデータのみをパッチ領域に書き込み、自サーバマシン用のキャッシュ領域に書き込むための空き容量が無ければコミット権管理部を参照して自サーバマシンにコミット権が付与されているか否かを確認し、付与されているならマスター領域に自サーバマシン用のキャッシュ領域のデータをコピーしてキャッシュ領域をクリアし、付与されていないならＩ／Ｏ入力側にエラーを返し、しかる後にマスター領域における書き込み位置情報と書き込んだデータとを自サーバマシン用のキャッシュ領域に書き込み、Ｉ／Ｏ入力側に返し、Ｉ／Ｏ入力がマスター領域への読取要求でも書込要求でもない場合には、自サーバマシンに備えられたフィルタドライバの下位層にＩ／Ｏ入力によるデータを受け渡し、返り値をＩ／Ｏ入力側へ返す。
【００２１】
請求項２の発明は、請求項１の発明のクラスタシステムに適用されるプログラムである。
【００２２】
請求項３の発明は、請求項３の発明のプログラムにおいて、各フィルタドライバは、自サーバマシンのキャッシュ領域と同じデータを持つメモリキャッシュ領域をそれぞれ備え、自サーバマシン用のキャッシュ領域を参照する代わりに、自サーバマシン用のメモリキャッシュ領域を参照し、マスター領域における書き込み位置情報と書き込んだデータとを自サーバマシン用のキャッシュ領域に書き込む代わりに、自サーバマシン用のメモリキャッシュ領域およびキャッシュ領域に書き込み、キャッシュ領域のデータをマスター領域にコピーする代わりに、メモリキャッシュ領域のデータをマスター領域にコピーするプログラムである。
【発明の効果】
【００２３】
本発明によれば、複数のサーバマシンと共有ディスク装置とから構成されたクラスタシステムにおいて、共有ディスク装置やそのマルチパスドライバの実装に依存せずにリザーブ排他が可能であり、かつ、フェールオーバが発生した場合であっても、複数のサーバマシンの書き込みによるデータ破損を発生させることなく、共有ディスク装置内のデータの整合を図ることが可能なクラスタシステム及びプログラムを実現することができる。
【発明を実施するための最良の形態】
【００２４】
以下に、本発明を実施するための最良の形態について図面を参照しながら説明する。
【００２５】
なお、以下の各実施の形態の説明に用いる図中の符号は、図１６乃至図２０と同一部分については同一符号を付して示し、重複説明を省略する。
【００２６】
（第１の実施の形態）
図１は、第１の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図である。
【００２７】
すなわち、本実施の形態に係るクラスタシステムは、複数のサーバマシン（ここでは、一例として２つのサーバマシン１０（＃Ａ，＃Ｂ）を示す）と、これらサーバマシン１０（＃Ａ，＃Ｂ）に接続された共有ディスク装置１３とから構成されたクラスタシステムである。ここでは、仮に、初期状態として、サーバマシン１０（＃Ａ）が稼動系、サーバマシン１０（＃Ｂ）が待機系であるとする。各サーバマシン１０（＃Ａ，＃Ｂ）はそれぞれ、各サーバマシン１０（＃Ａ，＃Ｂ）上でそれぞれ動作するアプリケーション１１（＃Ａ,＃Ｂ）、クラスタソフト１２（＃Ａ，＃Ｂ）、フィルタドライバ２１（＃Ａ，＃Ｂ）、ディスクドライバ２２（＃Ａ，＃Ｂ）を備えている。フィルタドライバ２１は、アプリケーション１１とディスクドライバ２２との間に介挿して設けられる。アプリケーション１１は、主にサーバアプリケーションを想定しており、本実施の形態では、プロキシキャッシュサーバであるとする。
【００２８】
共有ディスク装置１３は、各サーバマシン１０（＃Ａ，＃Ｂ）それぞれとＦＣ（Fiber Channel）ケーブル２３（＃Ａ，＃Ｂ）で接続されており、ＱＵＯＲＵＭ用領域１７とマスター領域３０とを備えている。それぞれを異なるＬＵに分けても良いし、異なるパーティションに分けても良い。
【００２９】
図２は、共有ディスク装置１３の詳細構成例を示す概念図である。
【００３０】
図２に示すようにＱＵＯＲＵＭ用領域１７は、共通領域１７０、サーバＡ用領域１７１、及びサーバＢ用領域１７２の３つの領域からなる。更に、共通領域１７０はコミット権管理テーブル１７０ａを、サーバＡ用領域１７１はキャッシュ領域１７１ａとパッチ領域１７１ｂを、サーバＢ用領域１７２はキャッシュ領域１７２ａとパッチ領域１７２ｂをそれぞれ備えている。
【００３１】
キャッシュ領域１７１ａは、サーバマシン１０（＃Ａ）のアプリケーション１１（＃Ａ）からＦＣケーブル２３（＃Ａ）を経由してデータがｗｒｉｔｅされる領域である。同様に、キャッシュ領域１７２ａは、サーバマシン１０（＃Ｂ）のアプリケーション１１（＃Ｂ）からＦＣケーブル２３（＃Ｂ）を経由してデータがｗｒｉｔｅされる領域である。
【００３２】
コミット権管理テーブル１７０ａは、キャッシュ領域１７１ａ，１７２ａに格納されたデータの、マスター領域３０へのコピー許可であるコミット権が付与されたサーバマシン１０を規定している。図２は、サーバマシン１０（＃Ａ）に対してコミット権が付与され、サーバマシン１０（＃Ｂ）に対してコミット権が付与されていない例を示している。
【００３３】
マスター領域３０は、キャッシュ領域１７１ａ，１７２ａに書き込まれたデータが一杯になった場合に、キャッシュ領域１７１ａ，１７２ａに書き込まれたデータを移動する領域である。移動は、キャッシュ領域１７１ａ，１７２ａが一杯になった場合に、コミット権を持っているサーバマシン１０、すなわち、コミット権管理テーブル１７０ａにおいて「コミット有」と規定されたサーバマシン１０のフィルタドライバ２１が、マスター領域３０にコミットすることによって開始される。
【００３４】
このような本実施の形態に係るクラスタシステムでは、クラスタソフト１２（＃Ａ，＃Ｂ）同士が、互いに定期的に通信して互いのサーバマシン１０の生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持つ。以下の説明では、サーバマシン１０（＃Ａ）が稼動系であり、サーバマシン（＃Ｂ）が待機系であるものとする。したがって、クラスタソフト１２（＃Ａ）は稼動系の状態であり、クラスタソフト１２（＃Ｂ）は待機系の状態となっている。
【００３５】
このように稼動系であるクラスタソフト１２（＃Ａ）は、コミット権管理テーブル１７０ａを、自サーバマシン１０（＃Ａ）のみにコミット権が付与されるように設定し、上位側である自サーバマシン１０（＃Ａ）側からマスター領域３０が見える状態にし、自サーバマシン１０（＃Ａ）に備えられたアプリケーション１１（＃Ａ）を起動させる。
【００３６】
サーバマシン１０（＃Ａ）に備えられたフィルタドライバ２１（＃Ａ）は、上位からのＩ／Ｏ入力を待ち、Ｉ／Ｏ入力がマスター領域３０へのｒｅａｄだった場合には、ｒｅａｄデータの一部または全部がサーバマシン１０（＃Ａ）用のキャッシュ領域１７１ａにあればキャッシュ領域１７１ａから読み取り、ｒｅａｄデータが他にもあればマスター領域３０から読み取り、読み取ったデータを、ｒｅａｄ要求をしたＩ／Ｏ入力側にまとめて返す。
【００３７】
また、Ｉ／Ｏ入力がマスター領域３０へのｗｒｉｔｅだった場合であり、自サーバマシン１０（＃Ａ）用のキャッシュ領域１７１ａに書き込むための空き容量がなく、自サーバマシン１０（＃Ａ）にコミット権が付与されているのであれば、キャッシュ領域１７１ａのデータをマスター領域３０にコピーしてキャッシュ領域１７１ａをクリアする。一方、自サーバマシン１０（＃Ａ）にコミット権が付与されていないのであれば、ｗｒｉｔｅ要求をしたＩ／Ｏ入力側にエラーを返し、しかる後に、図２のデータテーブル１７１ｃに示すように、マスター領域３０における書き込み位置情報（開始位置、長さ）と書き込んだデータとを自サーバマシン１０（＃Ａ）用のキャッシュ領域１７１ａに書き込み、書き込み結果を、ｗｒｉｔｅ要求をしたＩ／Ｏ入力側に返す。
【００３８】
一方、Ｉ／Ｏ入力が、マスター領域３０へのｒｅａｄでもｗｒｉｔｅでもない場合には、自サーバマシン１０（＃Ａ）に備えられたフィルタドライバ２１（＃Ａ）の下位側にあるディスクドライバ２２（＃Ａ）にＩ／Ｏ入力によるデータをそのまま受け渡し、返り値をそのままＩ／Ｏ入力側へ返す。
【００３９】
次に、待機系のクラスタソフト１２（＃Ｂ）およびフィルタドライバ２１（＃Ｂ）について説明する。
【００４０】
待機系のクラスタソフト１２（＃Ｂ）は、稼動系のクラスタソフト１２（＃Ａ）が生存していない、すなわち動作していないと判定した場合には、コミット権管理テーブル１７０ａを変更して自サーバマシン１０（＃Ｂ）にのみコミット権が付与されるようにする。そして、サーバマシン１０（＃Ａ）用のキャッシュ領域１７１ａのデータを自サーバマシン１０（＃Ｂ）用のパッチ領域１７２ｂにコピーし、パッチ領域１７２ｂをマスター領域３０の一部として代用し、自サーバマシン１０（＃Ｂ）側からマスター領域３０が見えるようにし、自サーバマシン１０（＃Ｂ）に備えられたアプリケーション１１（＃Ｂ）を起動する。
【００４１】
自サーバマシン１０（＃Ｂ）上に備えられたフィルタドライバ２１（＃Ｂ）は、サーバマシン１０（＃Ｂ）に備えられたクラスタソフト１２（＃Ｂ）が稼動系になった後、上位からのＩ／Ｏ入力を待つ。そして、このＩ／Ｏ入力がマスター領域３０へのｒｅａｄだった場合には、ｒｅａｄデータの一部または全部が自サーバマシン１０（＃Ｂ）用のパッチ領域１７２ｂにあればパッチ領域１７２ｂから読み取り、ｒｅａｄデータの一部または全部がキャッシュ領域１７２ａにあれば読み取り、ｒｅａｄデータが他にもあればマスター領域３０から読み取り、読み取ったデータを、ｒｅａｄ要求したＩ／Ｏ入力側にまとめて返す。
【００４２】
そして、Ｉ／Ｏ入力がマスター領域３０へのｗｒｉｔｅだった場合には、ｗｒｉｔｅ先の全部が自サーバマシン１０（＃Ｂ）用のパッチ領域１７２ｂにあればパッチ領域１７２ｂに書き込んでＩ／Ｏ入力側に返す。そうでない場合にはパッチ領域１７２ｂに該当するデータのみをパッチ領域１７２ｂに書き込み、自サーバマシン１０（＃Ｂ）用のキャッシュ領域１７２ａにデータを書き込むための空き容量が無ければコミット権管理テーブル１７０ａを参照して自サーバマシン１０（＃Ｂ）にコミット権が付与されているか否かを確認する。
【００４３】
確認の結果、コミット権が付与されていればマスター領域３０に自サーバマシン１０（＃Ｂ）用のキャッシュ領域１７２ａのデータをコピーしてキャッシュ領域１７２ａをクリアする。一方、コミット権が付与されていないならばＩ／Ｏ入力側にエラーを返し、しかる後にマスター領域３０における書き込み位置情報（開始位置、長さ）と書き込んだデータとを、図２のデータテーブル１７１ｃに示すように自サーバマシン１０（＃Ｂ）用のキャッシュ領域１７２ａに書き込み、Ｉ／Ｏ入力側に返す。
【００４４】
一方、Ｉ／Ｏ入力がマスター領域３０へのｒｅａｄでもｗｒｉｔｅでもない場合には、自サーバマシン１０（＃Ｂ）に備えられたフィルタドライバ２１（＃Ｂ）の下位層であるディスクドライバ２２（＃Ｂ）にＩ／Ｏ入力によるデータをそのまま受け渡し、返り値をそのままＩ／Ｏ入力側へ返す。
【００４５】
また、各サーバマシン１０は、マスター領域３０にコピーすべきパッチ領域（１７１ｂ又は１７２ｂ）を各サーバマシン１０が持っているか否かを管理する。更に、クラスタソフト１２は、稼動系になった場合、この管理結果に基づいて、マスター領域３０にコピーすべきパッチ領域（１７１ｂ又は１７２ｂ）を全てマスター領域３０にコピーするようにしても良い。
【００４６】
次に、以上のように構成した本実施の形態に係るクラスタシステムの動作について説明する。ただし、初期状態として、サーバマシン１０（＃Ａ）とサーバマシン１０（＃Ｂ）との間ではクラスタソフト１２（＃Ａ，＃Ｂ）同士がハートビートを交換し、互いの生存が確認できており、サーバマシン１０（＃Ａ，＃Ｂ）ともに、ＱＵＯＲＵＭ用領域１０７とマスター領域３０は上位層から見えない（フィルタドライバがフェンスオフ）状態になっており、サーバマシン１０（＃Ａ，＃Ｂ）ともにアプリケーション１１（＃Ａ，＃Ｂ）は起動していないものとする。
【００４７】
まず、図３に示すフローチャートと、図４に示す概念図とを用いて、サーバマシン１０（＃Ａ）を稼動系に設定する場合におけるクラスタソフト１２（＃Ａ）による処理の流れを説明する。
【００４８】
まず、ユーザ操作により、サーバマシン１０（＃Ａ）を稼動系にせよとの通知が、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）に届く（Ｓ１）。次に、クラスタソフト１２（＃Ａ）によって、サーバマシン１０（＃Ａ）にコミット権が付与されるようにコミット権管理テーブル１７０ａが設定される（Ｓ２）。すると、クラスタソフト１２（＃Ａ）によって、フィルタドライバ２１（＃Ａ）に稼動系となったことが通知される（Ｓ３）。その後、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）によって、上位層からマスター領域３０が見える状態にされる（Ｓ４）。そして、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）によって、アプリケーション１１（＃Ａ）が起動される（Ｓ５）。
【００４９】
次に、図５のフローチャートと、図４に示す概念図とを用いて、サーバマシン１０（＃Ａ）を稼動系に設定した後のフィルタドライバ２１（＃Ａ）による処理の流れを説明する。
【００５０】
まず、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）が上位からのＩ／Ｏ入力を待つ（Ｓ１１）。そして、Ｉ／Ｏ入力がなされると、なされたＩ／Ｏ入力の種別が判定される（Ｓ１２）。なされたＩ／Ｏ入力がマスター領域３０へのｒｅａｄであればステップＳ１３へ、ｗｒｉｔｅであればステップＳ１９へ、それ以外であればステップＳ２６へそれぞれ進む。
【００５１】
ステップＳ１３では、ｒｅａｄ先データの一部又は全部がキャッシュ領域１７１ａにあれば、キャッシュ領域１７１ａ上の該当するデータがｒｅａｄされ（Ｓ１４）、ステップＳ１５の処理に進む。ｒｅａｄ先データがキャッシュ領域１７１ａに全く無いのであれば、ステップＳ１４の処理をスキップしてステップＳ１５の処理に進む。
【００５２】
ステップＳ１５では、ｒｅａｄ先データの一部又は全部がキャッシュ領域１７１ａに無いのであれば、マスター領域３０から、残りのデータのみがｒｅａｄされ（Ｓ１６）、ステップＳ１７の処理に進む。そうでない場合には、ステップＳ１６の処理をスキップしてステップＳ１７の処理に進む。
【００５３】
ステップＳ１７では、ｒｅａｄされたデータが一つにマージされてｒｅａｄ要求元の上位へ返され（Ｓ１７）、ステップＳ１８の処理に進む。
【００５４】
そして、ステップＳ１８では、ＯＳが終了するのであれば処理が終了し、そうでなければステップＳ１１の処理に戻る（Ｓ１８）。
【００５５】
ステップＳ１９では、キャッシュ領域１７１ａに、ｗｒｉｔｅできるだけの空き容量があるかが判定される（Ｓ１９）。そして、ｗｒｉｔｅできるだけの空き容量があると判定された場合には、ステップＳ２０において、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）によって、共有ディスク装置１３上の書き込み開始アドレス、長さ、生データの３つがサーバマシン１０（＃Ａ）のキャッシュ領域１７１ａに書き込まれる（Ｓ２０）とともに上位へ返される（Ｓ２１）。その後、ステップＳ１８の処理に進む。
【００５６】
一方、ステップＳ１９において、キャッシュ領域１７１ａに、ｗｒｉｔｅできるだけの空き容量が無いと判定された場合には、ステップＳ２２において、コミット権管理テーブル１７０ａが参照され、サーバマシン１０（＃Ａ）にコミット権が付与されているかが確認される（Ｓ２２）。
【００５７】
サーバマシン１０（＃Ａ）にコミット権が付与されていれば、ステップＳ２３に進み、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）が、コミット（キャッシュ領域１７１ａからマスター領域３０への反映）を実施する（Ｓ２３）。
【００５８】
次に、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）が、キャッシュ領域１７１ａからコミット済みのキャッシュを削除し（Ｓ２４）、ステップＳ２０の処理に進む。
【００５９】
一方、ステップＳ２２において、サーバマシン１０（＃Ａ）にコミット権が付与されていない場合には、ステップＳ２５に進み、フィルタドライバ２１（＃Ａ）は上位へエラーを返し（Ｓ２５）、しかる後にステップＳ１８の処理に進む。
【００６０】
ステップＳ２６では、ディスクドライバ２２（＃Ａ）に処理がそのまま渡され、その後ステップＳ２７において返り値がそのまま上位に返され、ステップＳ１８の処理に進む。
【００６１】
次に、図６に示すフローチャートと、図７に示す概念図とを用いて、サーバマシン１０（＃Ｂ）がハートビート切れを検出し、フェールオーバするときのサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）による処理の流れを説明する。
【００６２】
まず、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）は、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）が、図７中のＸに示すようにｗｒｉｔｅ中にスローダウンしたり、図７中のＹに示すようにコミット中にスローダウンすることによってハードビート切れを検出する（Ｓ３１）と、サーバマシン１０（＃Ｂ）にコミット権が付与されるようにコミット権管理テーブル１７０ａが設定される（Ｓ３２）。なお、スローダウンしたクラスタソフト１２（＃Ａ）は、何れの場合であっても、しばらくした後に復帰するものとする。
【００６３】
次に、クラスタソフト１２（＃Ｂ）が、サーバマシン１０（＃Ａ）用のキャッシュ領域１７１ａの全データ（コミット前又はコミット中のものを含む）を、サーバマシン１０（＃Ｂ）のパッチ領域１７２ｂにコピーする（Ｓ３３）。
【００６４】
すると、クラスタソフト１２（＃Ｂ）によって、フィルタドライバ２１（＃Ｂ）にサーバマシン１０（＃Ｂ）が稼動系になったことが通知される（Ｓ３４）。その後、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）によって、上位層からマスター領域３０が見える状態にされる（Ｓ３５）。そして、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）によって、アプリケーション１１（＃Ｂ）が起動される（Ｓ３６）。
【００６５】
次に、図８のフローチャートと、図７に示す概念図とを用いて、サーバマシン１０（＃Ｂ）へのフェールオーバ後のフィルタドライバ２１（＃Ｂ）による処理の流れを説明する。
【００６６】
まず、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）が上位からのＩ／Ｏ入力を待つ（Ｓ４１）。そして、Ｉ／Ｏ入力がなされると、なされたＩ／Ｏ入力の種別が判定される（Ｓ４２）。なされたＩ／Ｏ入力がマスター領域３０へのｒｅａｄであればステップＳ４３へ、ｗｒｉｔｅであればステップＳ５１へ、それ以外であればステップＳ６１へそれぞれ進む。
【００６７】
ステップＳ４３では、ｒｅａｄ先データの一部又は全部がパッチ領域１７２ｂにあれば、パッチ領域１７２ｂ上の該当するデータがｒｅａｄされ（Ｓ４４）、ステップＳ４５の処理に進む。ｒｅａｄ先データがパッチ領域１７２ｂに全く無いのであれば、ステップＳ４４の処理をスキップしてステップＳ４５の処理に進む。
【００６８】
ステップＳ４５では、ｒｅａｄ先データの一部又は全部がキャッシュ領域１７２ａにあるのであれば、キャッシュ領域１７２ａ上の該当データがｒｅａｄされ（Ｓ４６）、ステップＳ４７の処理に進む。そうでない場合には、ステップＳ４６の処理をスキップしてステップＳ４７の処理に進む。
【００６９】
ステップＳ４７では、ｒｅａｄ先データの一部又は全部がパッチ領域１７２ｂにもキャッシュ領域１７２ａにも無いのであれば、マスター領域３０から、残りのデータのみがｒｅａｄされ（Ｓ４８）、ステップＳ４９の処理に進む。そうでない場合には、ステップＳ４８の処理をスキップしてステップＳ４９の処理に進む。
【００７０】
ステップＳ４９では、ｒｅａｄされたデータが一つにマージされてｒｅａｄ要求元の上位へ返され（Ｓ４９）、ステップＳ５０の処理に進む。
【００７１】
そして、ステップＳ５０では、ＯＳが終了するのであれば処理が終了し、そうでなければステップＳ４１の処理に戻る（Ｓ１８）。
【００７２】
ステップＳ５１では、ｗｒｉｔｅ先の一部又は全部がパッチ領域１７２ｂ上にあれば、ステップＳ５２に進み、該当するデータがパッチ領域１７２ｂにｗｒｉｔｅされ（Ｓ５２）、ステップＳ５３の処理に進む。
【００７３】
ステップＳ５３では、ｗｒｉｔｅ先の全部がパッチ領域１７２ｂであった場合には、ステップＳ５６の処理に進み、上位へ結果が返された後にステップＳ５０の処理に進む。一方、ｗｒｉｔｅ先の全部がパッチ領域１７２ｂである訳ではない場合には、ステップＳ５４の処理に進む。
【００７４】
ステップＳ５４では、キャッシュ領域１７２ａに、ｗｒｉｔｅできるだけの空き容量があるかが判定される（Ｓ５４）。そして、ｗｒｉｔｅできるだけの空き容量があると判定された場合には、ステップＳ５５において、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）によって、共有ディスク装置１３上の書き込み開始アドレス、長さ、生データの３つがサーバマシン１０（＃Ｂ）のキャッシュ領域１７２ａに書き込まれる（Ｓ５５）とともに上位へ返される（Ｓ５６）。その後、ステップＳ５０の処理に進む。
【００７５】
一方、ステップＳ５４において、キャッシュ領域１７２ａに、ｗｒｉｔｅできるだけの空き容量が無いと判定された場合には、ステップＳ５７において、コミット権管理テーブル１７０ａが参照され、サーバマシン１０（＃Ｂ）にコミット権が付与されているかが確認される（Ｓ５７）。
【００７６】
サーバマシン１０（＃Ｂ）にコミット権が付与されていれば、ステップＳ５８に進み、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）が、コミット（キャッシュ領域１７２ａからマスター領域３０への反映）を実施する（Ｓ５８）。
【００７７】
次に、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）が、キャッシュ領域１７２ａからコミット済みのキャッシュを削除し（Ｓ５９）、ステップＳ５５の処理に進む。
【００７８】
一方、ステップＳ５７において、サーバマシン１０（＃Ｂ）にコミット権が付与されていない場合には、ステップＳ６０に進み、フィルタドライバ２１（＃Ｂ）は上位へエラーを返し（Ｓ６０）、しかる後にステップＳ５０の処理に進む。
【００７９】
ステップＳ６１では、ディスクドライバ２２（＃Ｂ）に処理がそのまま渡され、その後ステップＳ６２において返り値がそのまま上位に返され、ステップＳ５０の処理に進む。
【００８０】
上述したように、本実施の形態に係るクラスタシステムにおいては、上記のような作用により、複数のサーバマシン１０（＃Ａ，＃Ｂ）と共有ディスク装置１３とから構成されたクラスタシステムにおいて、共有ディスク装置１３やそのマルチパスドライバの実装に依存せずにリザーブ排他が可能となる。
【００８１】
また、稼動系のサーバマシン１０（＃Ａ）のダウン、スローダウン、あるいは通信路１４の障害のようないかなる理由でフェールオーバが発生した場合であっても、複数のサーバマシン１０（＃Ａ，＃Ｂ）の重複書き込みによるデータ破損が発生することなく、共有ディスク装置１３内のデータの整合を図ることが可能となる。しかも、アプリケーションデータのためのサーバＡ用領域１７１及びサーバＢ用領域１７２を通常と比較してほとんど増やさずに済むのみならず、フェールオーバ時にコピーするデータ量も少なくて済むために迅速なフェールオーバが可能となる。
【００８２】
また、各サーバマシン１０は、マスター領域３０にコピーすべきパッチ領域（１７１ｂ又は１７２ｂ）を各サーバマシン１０が持っているか否かを管理する。更に、クラスタソフト１２は、稼動系になった場合、この管理結果に基づいて、マスター領域３０にコピーすべきパッチ領域（１７１ｂ又は１７２ｂ）のデータを全てマスター領域３０にコピーすることもできるので、元稼動系のサーバマシン１０（＃Ａ）の状態が確認できない状態（ダウン／スローダウン／生存）で、パッチ領域１７２ｂを持つ新たな稼動系のサーバマシン１０（＃Ｂ）を停止させた場合でも、アプリケーションデータの整合性を崩す危険を回避することが可能となる。
【００８３】
（第２の実施の形態）
図９は、第２の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図である。本実施の形態に係るクラスタシステムは、第１の実施の形態に係るクラスタシステムの変形例であるので、第１の実施の形態と同一部位については同一符番で示して重複説明を省略し、異なる点について説明する。
【００８４】
すなわち、本実施の形態に係るクラスタシステムは、図１に示す構成に加えて、各サーバマシン１０（＃Ａ，＃Ｂ）が更にコミットスレッド２４（＃Ａ，＃Ｂ）とメモリキャッシュ領域２５（＃Ａ，＃Ｂ）とを備えている。コミットスレッド２４及びメモリキャッシュ領域２５はともにフィルタドライバ２１に備えられている。
【００８５】
また、共有ディスク装置１３においては、図１に示すＱＵＯＲＵＭ用領域１７を無くした代わりに、マスター領域３０の中にＱＵＯＲＵＭ用ファイル３１を備えている。更に、ＱＵＯＲＵＭ用ファイル３１は、図１０に示すように、コミット権管理テーブル１７０ａ及びパッチ領域保持状態管理テーブル１７０ｂを含む共通領域１７０と、キャッシュ領域１７１ａ及びパッチ領域１７１ｂを含むサーバＡ用領域１７１と、キャッシュ領域１７２ａ及びパッチ領域１７２ｂを含むサーバＢ用領域１７２とを含んでいる。
【００８６】
パッチ領域保持状態管理テーブル１７０ｂは、マスター領域３０に反映すべきデータを各サーバマシン１０（＃Ａ，＃Ｂ）がパッチ領域１７１ｂ，１７２ｂに保持しているか否かの情報を管理している。
【００８７】
メモリキャッシュ領域２５（＃Ａ)には、サーバマシン１０（＃Ａ）のアプリケーション１１（＃Ａ）からフィルタドライバ２１（＃Ａ）を経由してｗｒｉｔｅされるデータが書き込まれる。同じデータは、ＦＣケーブル２３（＃Ａ）を経由してサーバＡ用領域１７１内のキャッシュ領域１７１ａにも書き込まれる。
【００８８】
同様に、メモリキャッシュ領域２５（＃Ｂ）には、サーバマシン１０（＃Ｂ）のアプリケーション１１（＃Ｂ）からフィルタドライバ２１（＃Ｂ）を経由してｗｒｉｔｅされるデータが書き込まれる。同じデータは、ＦＣケーブル２３（＃Ｂ）を経由してサーバＢ用領域１７２内のキャッシュ領域１７２ａにも書き込まれる。
【００８９】
これにより、各フィルタドライバ２１（＃Ａ，＃Ｂ）は、各サーバマシン１０（＃Ａ，＃Ｂ）のキャッシュ領域１７１ａ，１７２ａと同じデータを持つメモリキャッシュ領域２５（＃Ａ，＃Ｂ）をそれぞれ備えることになる。
【００９０】
コミットスレッド２４は、自サーバマシン１０にコミット権が付与されている場合、直接もしくはフィルタドライバ２１を経由して、自サーバマシン１０用のキャッシュ領域（１７１ａ又は１７２ａ）のデータを、マスター領域３０に定期的にコピーさせる。
【００９１】
このような本実施の形態に係るクラスタシステムでは、第１の実施の形態に係るクラスタシステムのフィルタドライバ２１が、自サーバマシン１０用のキャッシュ領域（１７１ａ又は１７２ａ）を参照する代わりに、自サーバマシン１０用のメモリキャッシュ領域２５を参照する。また、マスター領域３０における書き込み位置情報と書き込んだデータとを自サーバマシン１０用のキャッシュ領域（１７１ａ又は１７２ａ）内のデータテーブル（１７１ｃ又は１７２ｃ）に書き込む代わりに、自サーバマシン１０用のメモリキャッシュ領域２５およびキャッシュ領域（１７１ａ又は１７２ａ）に書き込む。また、キャッシュ領域（１７１ａ又は１７２ａ）のデータをマスター領域３０にコピーする代わりに、メモリキャッシュ領域２５のデータをマスター領域３０にコピーする。
【００９２】
次に、以上のように構成した本実施の形態に係るクラスタシステムの動作について説明する。
【００９３】
まず、図１１に示すフローチャートを用いて、サーバマシン１０（＃Ａ）を稼動系に設定する場合におけるクラスタソフト１２（＃Ａ）による処理の流れを説明する。
【００９４】
まず、ユーザ操作により、サーバマシン１０（＃Ａ）を稼動系にせよとの通知が、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）に届く（Ｓ７１）。次に、クラスタソフト１２（＃Ａ）によって、サーバマシン１０（＃Ａ）にコミット権が付与されるようにコミット権管理テーブル１７０ａが設定される（Ｓ７２）。すると、クラスタソフト１２（＃Ａ）によって、フィルタドライバ２１（＃Ａ）に稼動系となったことが通知される（Ｓ７３）。そして、フィルタドライバ２１（＃Ａ）は、パッチ領域保持状態管理テーブル１７０ｂを参照し、指定されているサーバマシン１０のパッチ領域（１７１ｂ又は１７２ｂ）の内容がマスター領域３０に反映される（Ｓ７４）。
【００９５】
その後、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）によって、上位層からマスター領域３０が見える状態にされる（Ｓ７５）。そして、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）によって、コミットスレッド２４（＃Ａ）が起動され（Ｓ７６）、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）によって、アプリケーション１１（＃Ａ）が起動される（Ｓ７７）。
【００９６】
次に、図１２のフローチャートを用いて、サーバマシン１０（＃Ａ）を稼動系に設定した後のコミットスレッド２４（＃Ａ）による処理の流れを説明する。
【００９７】
サーバマシン１０（＃Ａ）が稼動系に設定された後、コミットスレッド２４（＃Ａ）がフィルタドライバ２１（＃Ａ）に対してコミット実行命令を発行する（Ｓ８１）。コミットを連続的に続けていると、サーバマシン１０（＃Ａ）の負荷が常に１００％になって、他の処理をする余裕がなくなる恐れがある。これを回避するために、ステップＳ８１の後、例えば１０秒間スリープする（Ｓ８２）。これによって、キャッシュ領域１７１ａが満杯にならない程度である例えば１０秒間スリープし、コミットを継続する（Ｓ８３）。
【００９８】
次に、図１３のフローチャートを用いて、サーバマシン１０（＃Ａ）を稼動系に設定した後のフィルタドライバ２１（＃Ａ）による処理の流れを説明する。
【００９９】
まず、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）が上位からのＩ／Ｏ入力を待つ（Ｓ９１）。そして、なされたＩ／Ｏ入力がコミット実行命令である場合にはステップＳ９３の処理に進み、コミット実行命令ではない場合にはステップＳ１００の処理に進む。
【０１００】
ステップＳ９３では、コミット権管理テーブル１７０ａが参照され、サーバマシン１０（＃Ａ）にコミット権が付与されているか否かが確認される。そして、サーバマシン１０（＃Ａ）にコミット権が付与されている場合には、ステップＳ９４で、コミット時に、ｒｅａｄ／ｗｒｉｔｅ命令を出さないようにアプリケーション１１（＃Ａ）をブロックする処理であるロックが、コミットスレッド２４（＃Ａ）によって獲得される。
【０１０１】
そして、フィルタドライバ２１（＃Ａ）によって、メモリキャッシュ領域２５（＃Ａ）が参照され、コミットする範囲が確定され（Ｓ９５）た後に、コミット、すなわちメモリキャッシュ領域２５（＃Ａ）からマスター領域３０への反映が実施される（Ｓ９６）。そして、メモリキャッシュ領域２５（＃Ａ）及びキャッシュ領域１７１ａからコミット済みのキャッシュが削除され（Ｓ９７）た後に、ステップＳ９３で獲得されたロックが解放される（Ｓ９８）。その後、ステップＳ１２０の処理に進む。
【０１０２】
そして、ステップＳ１２０では、ＯＳが終了するのであれば処理が終了し、そうでなければステップＳ９１の処理に戻る（Ｓ１２０）。
【０１０３】
一方、ステップＳ９３において、サーバマシン１０（＃Ａ）にコミット権が付与されていない場合には、フィルタドライバ２１（＃Ａ）によって上位へエラーが戻され（Ｓ９９）た後に、ステップＳ１２０の処理に進む。
【０１０４】
ステップＳ１００では、ステップＳ９１でなされたＩ／Ｏ入力の種別が判定される（Ｓ１００）。なされたＩ／Ｏ入力がマスター領域３０へのｒｅａｄであればステップＳ１０１へ、ｗｒｉｔｅであればステップＳ１０９へ、それ以外であればステップＳ１１８へそれぞれ進む。
【０１０５】
ステップＳ１０１では、ｒｅａｄ中にコミット命令を出さないようにコミットスレッド２４（＃Ａ）をブロックする処理であるロックが、アプリケーション１１（＃Ａ）によって獲得される（Ｓ１０１）。そして、ｒｅａｄ先データの一部又は全部がメモリキャッシュ領域２５（＃Ａ）にあれば（Ｓ１０２）、メモリキャッシュ領域２５（＃Ａ）の該当するデータがｒｅａｄされ（Ｓ１０３）、ステップＳ１０４の処理に進む。ｒｅａｄ先データがメモリキャッシュ領域２５（＃Ａ）に全く無いのであれば、ステップＳ１０３の処理をスキップしてステップＳ１０４の処理に進む。
【０１０６】
ステップＳ１０４では、ｒｅａｄ先データの一部又は全部がキャッシュ領域１７１ａに無いのであれば、マスター領域３０から、残りのデータのみがｒｅａｄされ（Ｓ１０５）、ステップＳ１０６の処理に進む。そうでない場合には、ステップＳ１０５の処理をスキップしてステップＳ１０６の処理に進む。
【０１０７】
ステップＳ１０６では、ステップＳ１０１で獲得されたロックが解放され、その後、ｒｅａｄされたデータが一つにマージされてｒｅａｄ要求元の上位へ返され（Ｓ１０７）、ステップＳ１２０の処理に進む。
【０１０８】
ステップＳ１０９では、ｗｒｉｔｅ中にコミット命令を出さないようにコミットスレッド２４（＃Ａ）をブロックする処理であるロックが、アプリケーション１１（＃Ａ）によって獲得される。そして、メモリキャッシュ領域２５（＃Ａ）に、ｗｒｉｔｅできるだけの空き容量があるかが判定される（Ｓ１１０）。そして、ｗｒｉｔｅできるだけの空き容量があると判定された場合には、ステップＳ１１１において、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）によって、共有ディスク装置１３上の書き込み開始アドレス、長さ、生データの３つがサーバマシン１０（＃Ａ）のメモリキャッシュ領域２５（＃Ａ）及びキャッシュ領域１７１ａのデータテーブル１７１ｃに書き込まれ（Ｓ１１１）、ステップＳ１０９で獲得されたロックが解放された（Ｓ１１２）後に、ステップＳ１１１で書き込まれたデータが上位へ返される（Ｓ１１３）。その後、ステップＳ１２０の処理に進む。
【０１０９】
一方、ステップＳ１１０において、キャッシュ領域１７１ａに、ｗｒｉｔｅできるだけの空き容量が無いと判定された場合には、ステップＳ１０９で獲得されたロックが解放され（Ｓ１１４）、ステップＳ１１５において、フィルタドライバ２１（＃Ａ）によってコミットの実行命令が発行される（Ｓ１１５）。そして、コミットの実行命令が成功するとステップＳ１０９の処理に戻り、成功しなかった場合には、フィルタドライバ２１（＃Ａ）によって上位へエラーが戻され（Ｓ１１７）、ステップＳ１２０の処理に進む。
【０１１０】
ステップＳ１１８では、ディスクドライバ２２（＃Ａ）に処理がそのまま渡され、その後ステップＳ１１９において返り値がそのまま上位に返され、ステップＳ１２０の処理に進む。
【０１１１】
次に、図１４に示すフローチャートを用いて、サーバマシン１０（＃Ｂ）がハートビート切れを検出し、フェールオーバするときのサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）による処理の流れを説明する。
【０１１２】
まず、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）は、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）が、図７中のＸに示すようにｗｒｉｔｅ中にスローダウンしたり、図７中のＹに示すようにコミット中にスローダウンすることによってハードビート切れを検出する（Ｓ１３１）と、クラスタソフト１２（＃Ｂ）によって、サーバマシン１０（＃Ｂ）にコミット権が付与されるようにコミット権管理テーブル１７０ａが設定される（Ｓ１３２）。なお、スローダウンしたクラスタソフト１２（＃Ａ）は、何れの場合であっても、しばらくした後に復帰するものとする。
【０１１３】
次に、クラスタソフト１２（＃Ｂ）が、サーバマシン１０（＃Ａ）用のキャッシュ領域１７１ａの全データ（コミット前又はコミット中のものを含む）を、サーバマシン１０（＃Ｂ）のパッチ領域１７２ｂにコピーする（Ｓ１３３）。
【０１１４】
すると、クラスタソフト１２（＃Ｂ）によって、パッチ領域保持状態管理テーブル１７０ｂが、サーバマシン１０（＃Ｂ）のパッチ領域保持状態が指定されるように変更される（Ｓ１３４）。
【０１１５】
次に、クラスタソフト１２（＃Ｂ）によって、フィルタドライバ２１（＃Ｂ）にサーバマシン１０（＃Ｂ）が稼動系になったことが通知される（Ｓ１３５）。その後、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）によって、上位層からマスター領域３０が見える状態にされる（Ｓ１３６）。そして、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）によって、コミットスレッド２４（＃Ｂ）が起動され（Ｓ１３７）、次にアプリケーション１１（＃Ｂ）が起動される（Ｓ１３８）。
【０１１６】
次に、図１５のフローチャートを用いて、サーバマシン１０（＃Ｂ）にフェールオーバ後のフィルタドライバ２１（＃Ｂ）による処理の流れを説明する。
【０１１７】
まず、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）が上位からのＩ／Ｏ入力を待つ（Ｓ１４１）。このＩ／Ｏ入力がコミット実行命令である場合には、ステップＳ１４３の処理に進み、コミット実行命令でない場合には、ステップＳ１５０の処理に進む（Ｓ１４２）。
【０１１８】
ステップＳ１４３では、コミット権管理テーブル１７０ａが参照され、サーバマシン１０（＃Ｂ）にコミット権が付与されているか否かが確認される。そして、サーバマシン１０（＃Ｂ）にコミット権が付与されている場合には、ステップＳ１４４で、コミット時に、ｒｅａｄ／ｗｒｉｔｅ命令を出さないようにアプリケーション１１（＃Ｂ）をブロックする処理であるロックが、コミットスレッド２４（＃Ｂ）によって獲得される。
【０１１９】
そして、フィルタドライバ２１（＃Ｂ）によって、メモリキャッシュ領域２５（＃Ｂ）が参照され、コミットする範囲が確定され（Ｓ１４５）た後に、コミット、すなわちメモリキャッシュ領域２５（＃Ｂ）からマスター領域３０への反映が実施される（Ｓ１４６）。そして、メモリキャッシュ領域２５（＃Ｂ）及びキャッシュ領域１７２ａからコミット済みのキャッシュが削除され（Ｓ１４７）た後に、ステップＳ１４３で獲得されたロックが解放される（Ｓ１４８）。その後、ステップＳ１７４の処理に進む。
【０１２０】
そして、ステップＳ１７４では、ＯＳが終了するのであれば処理が終了し、そうでなければステップＳ１４１の処理に戻る（Ｓ１７４）。
【０１２１】
一方、ステップＳ１４３において、サーバマシン１０（＃Ｂ）にコミット権が付与されていない場合には、フィルタドライバ２１（＃Ｂ）によって上位へエラーが戻され（Ｓ１４９）た後に、ステップＳ１７４の処理に進む。
【０１２２】
ステップＳ１５０では、ステップＳ１４１でなされたＩ／Ｏ入力の種別が判定される（Ｓ５０）。なされたＩ／Ｏ入力がマスター領域３０へのｒｅａｄであればステップＳ１５１へ、ｗｒｉｔｅであればステップＳ１６０へ、それ以外であればステップＳ１７２へそれぞれ進む。
【０１２３】
ステップＳ１５１では、ｒｅａｄ先データの一部又は全部がパッチ領域１７２ｂにあれば、パッチ領域１７２ｂ上の該当するデータがｒｅａｄされ（Ｓ１５２）、ステップＳ１５３の処理に進む。ｒｅａｄ先データがパッチ領域１７２ｂに全く無いのであれば、ステップＳ１５２の処理をスキップしてステップＳ１５３の処理に進む。
【０１２４】
ステップＳ１５３では、ｒｅａｄ中にコミット命令を出さないようにコミットスレッド２４（＃Ｂ）をブロックする処理であるロックが、アプリケーション１１（＃Ｂ）によって獲得される（Ｓ１５３）。そして、ｒｅａｄ先データの一部又は全部がメモリキャッシュ領域２５（＃Ｂ）にあれば（Ｓ１５４）、メモリキャッシュ領域２５（＃Ｂ）の該当するデータがｒｅａｄされ（Ｓ１５５）、ステップＳ１５６の処理に進む。ｒｅａｄ先データがメモリキャッシュ領域２５（＃Ｂ）に全く無いのであれば、ステップＳ１５５の処理をスキップしてステップＳ１５６の処理に進む。
【０１２５】
ステップＳ１５６では、ｒｅａｄ先データの一部又は全部がキャッシュ領域１７２ａにもパッチ領域１７２ｂにも無いのであれば、マスター領域３０から、残りのデータのみがｒｅａｄされ（Ｓ１５７）、ステップＳ１５８の処理に進む。そうでない場合には、ステップＳ１５７の処理をスキップしてステップＳ１５８の処理に進む。
【０１２６】
ステップＳ１５８では、ステップＳ１５３で獲得されたロックが解放され、その後、ｒｅａｄされたデータが一つにマージされてｒｅａｄ要求元の上位へ返され（Ｓ１５９）、ステップＳ１７４の処理に進む。
【０１２７】
ステップＳ１６０では、ｗｒｉｔｅ先の一部又は全部がパッチ領域１７２ｂ上にあれば、ステップＳ１６１に進み、該当するデータがパッチ領域１７２ｂにｗｒｉｔｅされ（Ｓ１６１）、ステップＳ１６２の処理に進む。
【０１２８】
ステップＳ１６２では、ｗｒｉｔｅ先の全てがパッチ領域１７２ｂであった場合には、ステップＳ１６７の処理に進み、上位へ結果が返された後にステップＳ１７４の処理に進む。一方、ｗｒｉｔｅ先の全てがパッチ領域１７２ｂである訳ではない場合には、ステップＳ１６３の処理に進む。
【０１２９】
ステップＳ１６３では、ｗｒｉｔｅ中にコミット命令を出さないようにコミットスレッド２４（＃Ｂ）をブロックする処理であるロックが、アプリケーション１１（＃Ｂ）によって獲得される。そして、メモリキャッシュ領域２５（＃Ｂ）に、ｗｒｉｔｅできるだけの空き容量があるかが判定される（Ｓ１６４）。そして、ｗｒｉｔｅできるだけの空き容量があると判定された場合には、ステップＳ１６５において、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）によって、共有ディスク装置１３上の書き込み開始アドレス、長さ、生データの３つがサーバマシン１０（＃Ｂ）のメモリキャッシュ領域２５（＃Ｂ）及びキャッシュ領域１７２ａに書き込まれ（Ｓ１６５）、ステップＳ１６３で獲得されたロックが解放された（Ｓ１６６）後に、ステップＳ１６５で書き込まれたデータが上位へ返される（Ｓ１６７）。その後、ステップＳ１７４の処理に進む。
【０１３０】
一方、ステップＳ１６４において、キャッシュ領域１７２ａに、ｗｒｉｔｅできるだけの空き容量が無いと判定された場合には、ステップＳ１６３で獲得されたロックが解放され（Ｓ１６８）、ステップＳ１６９において、フィルタドライバ２１（＃Ｂ）によってコミットの実行命令が発行される（Ｓ１６９）。そして、コミットの実行命令が成功するとステップＳ１６３の処理に戻り、成功しなかった場合には、フィルタドライバ２１（＃Ｂ）によって上位へエラーが戻され（Ｓ１７１）、ステップＳ１７４の処理に進む。
【０１３１】
ステップＳ１７２では、ディスクドライバ２２（＃Ｂ）に処理がそのまま渡され、その後ステップＳ１７３において返り値がそのまま上位に返され、ステップＳ１７４の処理に進む。
【０１３２】
なお、サーバマシン１０（＃Ｂ）にフェールオーバした後のコミットスレッド２４（＃Ｂ）による処理の流れは、図１２のフローチャートの説明に示すサーバマシン１０（＃Ａ）、フィルタドライバ２１（＃Ａ）、コミットスレッド２４（＃Ａ）、及びキャッシュ領域１７１ａを、サーバマシン１０（＃Ｂ）、フィルタドライバ２１（＃Ｂ）、コミットスレッド２４（＃Ｂ）、及びキャッシュ領域１７２ａに読み替えたものと同じである。
【０１３３】
上述したように、本実施の形態に係るクラスタシステムにおいては、共通領域１７０、サーバＡ用領域１７１、及びサーバＢ用領域１７２をマスター領域３０内に設けているので、新たに特別なＬＵやパーティションを用意することが無くなるため、例えば、既に稼動しているクラスタシステムへの適用を容易に行うことが可能となる。
【０１３４】
また、フィルタドライバ２１がコミットする際、例えば、第１の実施の形態のような構成では、キャッシュ領域（１７１ａ又は１７２ａ）からのデータのｒｅａｄと、マスター領域３０へのデータのｗｒｉｔｅとのために２回のディスクアクセスが必要であったが、本実施の形態によれば、ディスクアクセスの回数が減るため、共有ディスク装置１３に対する負荷が減り、上位アプリケーションからのＩ／Ｏに対しより高速な処理が可能となる。
【０１３５】
更に、本実施の形態に係るクラスタシステムでは、コミットスレッド２４は、自サーバマシン１０にコミット権が付与されている場合、直接もしくはフィルタドライバ２１を経由して、自サーバマシン１０用のキャッシュ領域（１７１ａ又は１７２ａ）のデータを、マスター領域３０に定期的にコピーさせるので、マスター領域３０にキャッシュ領域（１７１ａ又は１７２ａ）のデータをコピーする処理を、通常のＩ／Ｏ入力に対する処理と並行して行うことが可能となり、上位アプリケーションからのＩ／Ｏの遅延を防ぎ、高速化を図ることが可能となる。
【０１３６】
更にまた、本実施の形態に係るクラスタシステムでは、パッチ領域保持状態を管理するパッチ領域保持状態管理テーブル１７０ｂを備えているので、パッチ領域保持状態管理テーブル１７０ｂを参照することにより、マスター領域３０に反映すべきパッチ領域（１７１ｂ又は１７２ｂ）を各サーバマシン１０（＃Ａ，＃Ｂ）が持っているか否かを把握できる。従って、例えば、サーバマシン１０（＃Ｂ）を停止させたい場合でも、サーバマシン１０（＃Ａ）の状態を確認することができ、パッチ領域１７１ｂからマスター領域３０への必要な反映のし忘れや、サーバマシン１０（＃Ａ）とサーバマシン１０（＃Ｂ）との両系による重複書き込みを回避し、パッチ領域（１７１ｂ又は１７２ｂ）をマスター領域３０の該当箇所に確実に反映することが可能となる。
【０１３７】
以上、本発明を実施するための最良の形態について、添付図面を参照しながら説明したが、本発明はかかる構成に限定されない。特許請求の範囲の発明された技術的思想の範疇において、当業者であれば、各種の変更例及び修正例に想到し得るものであり、それら変更例及び修正例についても本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【０１３８】
【図１】第１の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図。
【図２】第２の実施の形態における共有ディスク装置の詳細構成例を示す概念図。
【図３】サーバマシンを稼動系に設定する場合におけるクラスタソフトによる処理の流れを示すフローチャート。
【図４】サーバマシンを稼動系に設定する場合におけるクラスタソフト、および設定後におけるフィルタドライバによる処理の流れを示す概念図。
【図５】サーバマシンを稼動系に設定した後のフィルタドライバによる処理の流れを示すフローチャート。
【図６】サーバマシンがハートビート切れを検出し、フェールオーバするときのサーバマシンのクラスタソフトによる処理の流れを示すフローチャート。
【図７】サーバマシンがハートビート切れを検出し、フェールオーバするときのサーバマシンのクラスタソフトによる処理と、サーバマシンにフェールオーバ後のフィルタドライバによる処理の流れを示す概念図。
【図８】サーバマシンにフェールオーバ後のフィルタドライバによる処理の流れを示すフローチャート。
【図９】第２の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図。
【図１０】第２の実施の形態における共有ディスク装置の詳細構成例を示す概念図。
【図１１】サーバマシンを稼動系に設定する場合におけるクラスタソフトによる処理の流れを示すフローチャート。
【図１２】サーバマシンを稼動系に設定した後のコミットスレッドによる処理の流れを示すフローチャート。
【図１３】サーバマシンを稼動系に設定した後のフィルタドライバによる処理の流れを示すフローチャート。
【図１４】サーバマシンがハートビート切れを検出し、フェールオーバするときのクラスタソフトによる処理の流れを示すフローチャート。
【図１５】サーバマシンにフェールオーバ後のフィルタドライバによる処理の流れを示すフローチャート。
【図１６】従来技術のクラスタシステムによるフェールオーバを説明するための概念図。
【図１７】従来技術のクラスタシステムによるフェールオーバ時に生じるデータ破壊を説明するための概念図。
【図１８】リザーブ排他機能を用いた従来技術のクラスタシステムによるフェールオーバを説明するための概念図。
【図１９】ＱＵＯＲＵＭを用いた従来技術のクラスタシステムによるフェールオーバを説明するための概念図。
【図２０】ＱＵＯＲＵＭを用いた従来技術のクラスタシステムによるフェールオーバ時に生じるデータ破壊を説明するための概念図。
【符号の説明】
【０１３９】
ａ…ハートビート、ｂ…フェールオーバ、１０…サーバマシン、１１…アプリケーション、１２…クラスタソフト、１３…共有ディスク装置、１４…通信路、１５…データ領域、１７…ＱＵＯＲＵＭ用領域、１８…アプリケーションデータ用領域、２１…フィルタドライバ、２２…ディスクドライバ、２３…ＦＣケーブル、２４…コミットスレッド、２５…メモリキャッシュ領域、３０…マスター領域、３１…ＱＵＯＲＵＭ用ファイル、１０７…ＱＵＯＲＵＭ用領域、１７０…共通領域、１７０ａ…コミット権管理テーブル、１７０ｂ…パッチ領域保持状態管理テーブル、１７１…サーバＡ用領域、１７１ａ，１７２ａ…キャッシュ領域、１７１ｂ，１７２ｂ…パッチ領域、１７１ｃ…データテーブル、１７２…サーバＢ用領域
【図１】
2008242741.tif 000003
【図２】
2008242741.tif 000004
【図３】
2008242741.tif 000005
【図４】
2008242741.tif 000006
【図５】
2008242741.tif 000007
【図６】
2008242741.tif 000008
【図７】
2008242741.tif 000009
【図８】
2008242741.tif 000010
【図９】
2008242741.tif 000011
【図１０】
2008242741.tif 000012
【図１１】
2008242741.tif 000013
【図１２】
2008242741.tif 000014
【図１３】
2008242741.tif 000015
【図１４】
2008242741.tif 000016
【図１５】
2008242741.tif 000017
【図１６】
2008242741.tif 000018
【図１７】
2008242741.tif 000019
【図１８】
2008242741.tif 000020
【図１９】
2008242741.tif 000021
【図２０】
2008242741.tif 000022