JP2008234604A - クラスタシステム及びプログラム - Google Patents

Abstract

【課題】リザーブ排他が可能であり、フェールオーバが発生した場合であっても、データ破損が発生せず、共有ディスク装置内のデータの整合を図るクラスタシステムを提供する。
【解決手段】共有ディスク装置３０は、マスター領域３０と、マスター領域へのアクセス権を管理する管理領域１７とを備える。クラスタソフト１２（＃Ａ）は、クラスタソフト１２（＃Ｂ）と定期的に通信し、クラスタソフト１２（＃Ｂ）の生存状態を確認し、自己が稼動系の場合には、サーバマシン１０（＃Ａ）上でアプリケーションを動作させる。稼動系にあるクラスタソフト１２（＃Ｂ）が生存していないと判定された場合には、自己を待機系から稼動系に変更しサーバマシン１０（＃Ａ）上でアプリケーションを動作させる。待機系から稼動系に変更された場合、フィルタドライバ２１（＃Ａ）は、サーバマシン１０（＃Ａ）にアクセス権が与えられるように管理領域１７の内容を変更する。
【選択図】 図１

Description

本発明は、複数のサーバマシンと共有ディスク装置とから構成されるクラスタシステム及びプログラムに関し、特に、フェールオーバが発生した場合であっても、共有ディスク装置内のデータの整合を図ることが可能なクラスタシステム及びプログラムに関する。

例えば、非特許文献１で開示されているＤＮＣＷＡＲＥ（登録商標）ＣｌｕｓｔｅｒＰｅｒｆｅｃｔ（登録商標）等に代表されるクラスタシステムでは、図１２に示すように、稼動系のサーバマシン１０（＃Ａ）と待機系のサーバマシン１０（＃Ｂ）とが設けられ、稼動系のサーバマシン１０（＃Ａ）がアプリケーション１１（＃Ａ）を実行し、（ｉ）に示すように、実行結果であるデータを共有ディスク装置１３に書き込む。その間、（ｉｉ）に示すように、稼動系のサーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）と待機系のサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）とは、通信路１４を経由して、ハートビートａ（非特許文献２参照）と呼ばれる所定のパケット交換をし続け、互いの生存を通知し合う。

そして、待機系のサーバマシン１０（＃Ｂ）がハートビートａの断絶を検出した場合に、（ｉｉｉ）に示すように、待機系のサーバマシン１０（＃Ｂ）で同一のアプリケーション１１（＃Ｂ）を起動させることでアプリケーション処理を継続させる、所謂フェールオーバｂが一般に行われている。

ハートビートａが断絶する理由としては主に以下がある。
（１）稼動系のサーバマシン１０（＃Ａ）のダウン。
（２）通信路１４の障害。
（３）稼動系のサーバマシン１０（＃Ａ）におけるＣＰＵ高負荷等による一時的なスローダウンの発生。

上記（１）の場合であれば、単純に待機系のサーバマシン１０（＃Ｂ）にフェールオーバｂすれば良いが、上記（２）及び（３）の場合には稼動系のサーバマシン１０（＃Ａ）が処理を継続するため、フェールオーバｂしてしまうと以下に示すような不都合が生じる。

すなわち、図１２に示すように、複数台のサーバマシン１０（＃Ａ，＃Ｂ）が同一の共有ディスク装置１３に接続された状態でクラスタ構成を組む場合、上記（２）及び（３）が原因のハートビートａの断絶によりフェールオーバｂが行われると、図１３に示すように、稼動系のサーバマシン１０（＃Ａ）と待機系のサーバマシン１０（＃Ｂ）との両系が共有ディスク装置１３内の同一のデータ領域１５に書き込みを行う可能性があり、その場合、共有ディスク装置１３内のデータの整合性が失われ、データが破壊されてしまう恐れがある。

このため、従来のクラスタシステムでも、この不都合に対する対策が幾つか施されている。以下、この対策を施した従来技術を２つ紹介する。

第１の従来技術は、上記（１）乃至（３）に対処するものであり、ＳＣＳＩ仕様として定義されているリザーブ排他機能が使用され、１つのＬＵ（Logical Unit）につきＩ／Ｏ（ｒｅａｄやｗｒｉｔｅ）を発行可能なサーバが１つに絞られている。つまり、図１４の（ｉ）に示すようにハートビートａ切れが検出され、（ｉｉ）に示すように待機系のサーバマシン１０（＃Ｂ）にフェールオーバｂする際、（ｉｉｉ）に示すように待機系のサーバマシン１０（＃Ｂ）が共有ディスク装置１３内の対象ＬＵをリザーブし、（ｉｖ）に示すように稼動系のサーバマシン１０（＃Ａ）がそれ以上対象ＬＵに書き込みを行うのを防いでから、アプリケーション１１（＃Ｂ）を起動し、（ｖ）に示すように共有ディスク装置１３への書き込みを行うようにしている。

第２の従来技術は、上記（１）及び（２）に対処するものであり、図１５に示すように、ＱＵＯＲＵＭ用領域１７と呼ばれる特殊なＬＵを共有ディスク装置１３内に設け、（ｉｉｉ）に示すように、クラスタを構成するサーバマシン１０（＃Ａ，＃Ｂ）からその時々の現在時刻を定期的に書き込むことで、（ｉ）に示すハートビートａ以外にサーバマシン１０（＃Ａ，＃Ｂ）の状態を監視する。

第２の従来技術によれば、通信路１４の障害が理由で待機系のサーバマシン１０（＃Ｂ）がハートビートａ断絶を確認した場合でも、待機系のサーバマシン１０（＃Ｂ）がＱＵＯＲＵＭ用領域１７を参照する。ＱＵＯＲＵＭ用領域１７は、ディスクＩ／Ｏのパス経由のために、通信路１４に障害があっても参照可能であるので、稼動系のサーバマシン１０（＃Ａ）が現在時刻のｗｒｉｔｅを継続していることを確認することができ、稼動系のサーバマシン１０（＃Ａ）がダウンしていないことを知ることができる。
東芝レビュー Ｖｏｌ．５４ Ｎｏ．１２（１９９９）、１８〜２１ページ Ｓｏｌｓｔｉｃｅ ＨＡ １．３Ｕｓｅｒ’ｓ Ｇｕｉｄｅ、 ２５−１〜２５−５ページ、 １９９７年４月、 Ｓｕｎ ｍｉｃｒｏｓｙｓｔｅｍｓ

しかしながら、このような従来のクラスタシステムでは、以下のような問題がある。

まず、第１の従来技術の場合、図１４の（ｉｉｉ）及び（ｉｖ）に示すようなリザーブ排他が可能な否かは、共有ディスク装置１３や、そのマルチパスドライバ（図示せず）の実装に依存するという問題がある。そのため、新しい共有ディスク装置１３やそのマルチパスドライバに対応するためには、毎回検証することが必要になる。また、共有ディスク装置１３やそのマルチパスドライバによって、細かな制限事項が付きがちである。例えば、ある共有ディスク装置１３では、ディスクＩ／Ｏの物理的なパスが多重化されている環境で片パス障害が起きると、リザーブが維持されない状態に陥ってしまい、排他できなくなってしまう。

また、第２の従来技術の場合、例えば、図１６に示すように、（ｉ）稼動系のサーバマシン１０（＃Ａ）がｗｒｉｔｅ中にＣＰＵ高負荷に陥りスローダウンしてしまった場合には、（ｉｉ）待機系のサーバマシン１０（＃Ｂ）はハートビートａ切れを検出し、稼動系のサーバマシン１０（＃Ａ）がダウンしたと思ってしまい、（ｉｉｉ）フェールオーバｂを実施してしまう。これにより、（ｉｖ）待機系のサーバマシン１０（＃Ｂ）は、ＱＵＯＲＵＭ用領域１７に現在時刻を書き込むとともに、（ｖ）アプリケーションデータ用領域１８のデータ領域１５にデータをｗｒｉｔｅする。

一方、（ｖｉ）稼動系のサーバマシン１０（＃Ａ）も停止した訳ではないので、（ｖｉｉ）復帰直後から、ＱＵＯＲＵＭ用領域１７に現在時刻を書き込むとともに、アプリケーションデータ用領域１８のデータ領域１５へのデータのｗｒｉｔｅを継続する。

このように、稼動系のサーバマシン１０（＃Ａ）がスローダウンから復帰した直後に、両サーバから同じＬＵへの書き込みが行われ、データ破壊が発生する可能性があるという問題がある。

本発明はこのような事情に鑑みてなされたものであり、複数のサーバマシンと共有ディスク装置とから構成されたクラスタシステムにおいて、共有ディスク装置やそのマルチパスドライバの実装に依存せずにリザーブ排他が可能であり、かつ、フェールオーバが発生した場合であっても、複数のサーバマシンの書き込みによるデータ破損を発生させることなく、共有ディスク装置内のデータの整合を図ることが可能なクラスタシステム及びプログラムを提供することを目的とする。

上記の目的を達成するために、本発明では、以下のような手段を講じる。

すなわち、請求項１の発明は、複数のサーバマシンと、複数のサーバマシンに接続された共有ディスク装置とから構成されるクラスタシステムであって、共有ディスク装置は、各サーバマシン上でそれぞれ動作する同一のアプリケーションのデータを格納するマスター領域と、各サーバマシン毎のマスター領域へのアクセス権を管理する管理領域とを備え、各サーバマシンは、動作状態変更手段と、マスター領域アクセス手段とをそれぞれ備えている。

そして、各動作状態変更手段は、動作状態として、稼動系と待機系との少なくとも２つを持ち、異なるサーバマシンに備えられた他の動作状態変更手段と互いに定期的に通信することによって、通信相手の動作状態変更手段の生存状態を確認し、動作状態が稼動系にある場合には、自己が属するサーバマシン上でアプリケーションを動作させる一方、動作状態が待機系にある場合には、自己が属するサーバマシン上でアプリケーションを動作させず、更に、生存状態の確認の結果、稼動系にある通信相手の動作状態変更手段が生存していないと判定された場合には、自己の動作状態を待機系から稼動系に変更し、自己が属するサーバマシン上でアプリケーションを動作させることが可能である。

また、各マスター領域アクセス手段は、同じサーバマシンに属する動作状態変更手段の動作状態が待機系から稼動系に変更された場合には、該サーバマシンにアクセス権が与えられるように管理領域の内容を変更する。各マスター領域アクセス手段は更に、同じサーバマシンに属する動作状態変更手段の動作状態が稼動系になった後は、該サーバマシンの上位からのＩ／Ｏ命令を待ち、Ｉ／Ｏ命令があった場合にはＩ／Ｏ命令を下位に受け渡し、Ｉ／Ｏ命令に対する処理が正常に完了した旨が下位から返ってきた場合にはその旨を上位に返し、正常に完了した旨が下位から返ってこない場合には管理領域を参照し、アクセス権が該サーバマシンに与えられているのであればＩ／Ｏ命令を下位に再度受け渡し、アクセス権が該サーバマシンに与えられていなければ、予め定めたエラー処理を行う。

請求項２の発明は、マスター領域アクセス手段を、ホストバスアダプタカードによって実現することを特徴とする請求項１のクラスタシステムである。

請求項３の発明は、複数のサーバマシンと、複数のサーバマシンに接続された共有ディスク装置とから構成されるクラスタシステムに適用されるプログラムである。ここで、共有ディスク装置は、各サーバマシン上でそれぞれ動作する同一のアプリケーションのデータを格納するマスター領域と、各サーバマシン毎のマスター領域へのアクセス権を管理する管理領域とを備え、各サーバマシンは、動作状態変更手段と、マスター領域アクセス手段とをそれぞれ備え、各動作状態変更手段は、動作状態として、稼動系と待機系との少なくとも２つを持つ。

そして、このプログラムは、異なるサーバマシンに備えられた他の動作状態変更手段と互いに定期的に通信することによって、通信相手の動作状態変更手段の生存状態を確認する機能、各動作状態変更手段が、稼動系にある場合には、自己が属するサーバマシン上でアプリケーションを動作させる一方、待機系にある場合には、自己が属するサーバマシン上でアプリケーションを動作させない機能、生存状態の確認の結果、稼動系にある通信相手の動作状態変更手段が生存していないと判定され、かつ自己の動作状態が待機系にある場合には、各動作状態変更手段が、自己の動作状態を待機系から稼動系に変更し、自己が属するサーバマシン上でアプリケーションを動作させる機能、各マスター領域アクセス手段が、同じサーバマシンに属する動作状態変更手段の動作状態が待機系から稼動系に変更された場合には、該サーバマシンにアクセス権が与えられるように管理領域の内容を変更する機能、各マスター領域アクセス手段が更に、同じサーバマシンに属する動作状態変更手段の動作状態が稼動系になった後は、該サーバマシンの上位からのＩ／Ｏ命令を待ち、Ｉ／Ｏ命令があった場合にはＩ／Ｏ命令を下位に受け渡し、Ｉ／Ｏ命令に対する処理が正常に完了した旨が下位から返ってきた場合にはその旨を上位に返し、正常に完了した旨が下位から返ってこない場合には管理領域を参照し、アクセス権が該サーバマシンに与えられているのであればＩ／Ｏ命令を下位に再度受け渡し、アクセス権が該サーバマシンに与えられていなければ、予め定めたエラー処理を行う機能をコンピュータに実現させる。

本発明によれば、複数のサーバマシンと共有ディスク装置とから構成されたクラスタシステムにおいて、共有ディスク装置やそのマルチパスドライバの実装に依存せずにリザーブ排他が可能であり、かつ、フェールオーバが発生した場合であっても、複数のサーバマシンの書き込みによるデータ破損を発生させることなく、共有ディスク装置内のデータの整合を図ることが可能なクラスタシステム及びプログラムを実現することができる。

以下に、本発明を実施するための最良の形態について図面を参照しながら説明する。

なお、以下の各実施の形態の説明に用いる図中の符号は、図１２乃至図１６と同一部分については同一符号を付して示し、重複説明を省略する。

（第１の実施の形態）
図１は、第１の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図である。

すなわち、本実施の形態に係るクラスタシステムは、複数のサーバマシン（ここでは、一例として２つのサーバマシン１０（＃Ａ，＃Ｂ）を示す）と、これらサーバマシン１０（＃Ａ，＃Ｂ）に接続された共有ディスク装置１３とから構成されたクラスタシステムである。ここでは、仮に、初期状態として、サーバマシン１０（＃Ａ）が稼動系、サーバマシン１０（＃Ｂ）が待機系であるとする。各サーバマシン１０（＃Ａ，＃Ｂ）はそれぞれ、各サーバマシン１０（＃Ａ，＃Ｂ）上でそれぞれ動作するアプリケーション１１（＃Ａ,＃Ｂ）、クラスタソフト１２（＃Ａ，＃Ｂ）、マルチパスドライバ２０（＃Ａ，＃Ｂ）、フィルタドライバ２１（＃Ａ，＃Ｂ）、ホストバスアダプタ（ＨＢＡ）ドライバ２２（＃Ａ，＃Ｂ）を備えている。マルチパスドライバ２０は、アプリケーション１１の下位に、フィルタドライバ２１は、マルチパスドライバ２０の下位に、ＨＢＡドライバ２２は、フィルタドライバの下位にそれぞれ配置して設けられる。なお、フィルタドライバ２１とＨＢＡドライバ２２とを同一モジュールで実現するようにしても良い。更に、各ＨＢＡドライバ２２には、共有ディスク装置１３と通信するための複数のＨＢＡカード２２０（＃１〜＃ｎ）がそれぞれ装着されている。そして、フィルタドライバ２１の持つ機能を、ＨＢＡカード２２０に実装させるようにしても良い。

アプリケーション１１は、主にサーバアプリケーションを想定しており、本実施の形態では、データベースサーバであるとする。

共有ディスク装置１３は、各サーバマシン１０（＃Ａ，＃Ｂ）それぞれとＦＣ（Fiber Channel）ケーブル２３（＃Ａ，＃Ｂ）で接続されており、ＱＵＯＲＵＭ用領域１７とマスター領域３０とを備えている。それぞれを異なるＬＵに分けても良いし、異なるパーティションに分けても良い。これについては、第２の実施の形態で説明する。そして、各ＬＵは、イニシエータ（本実施の形態の場合はＨＢＡカード２２０）が発行するバスリセットにより、ユニットアテンション状態となる。また、共有ディスク装置１３は、イニシエータ毎にユニットアテンション状態を保持し、各イニシエータからアクセスがあるまで状態を保持し続ける。その後、イニシエータからアクセスがあったら、データ書き込みをせずにチェックコンディションを返す。

図２は、サーバマシン１０（＃Ａ，＃Ｂ）と共有ディスク装置１３、特にＱＵＯＲＵＭ用領域１７との関連性を詳細に示す概念図である。したがって、図２ではサーバマシン１０（＃Ａ，＃Ｂ）の構成を簡略して示している。

図２に示すようにＱＵＯＲＵＭ用領域１７は、各サーバマシン１０（＃Ａ，＃Ｂ）うちどのサーバマシン１０がマスター領域３０へのアクセス権を持っているかを管理するアクセス権管理領域１７０を備えている。図２に示す例では、サーバマシン１０（＃Ａ）がアクセス権を持ち、サーバマシン１０（＃Ｂ）がアクセス権を持っていないことを示している。アクセス権の指定及び変更は、後述するようにフィルタドライバ２１が行う。

マスター領域３０は、各サーバマシン１０（＃Ａ,＃Ｂ）上でそれぞれ動作する同一のアプリケーション１１（＃Ａ，＃Ｂ）のデータを格納する領域である。

再び図１に示すように、各クラスタソフト１２は、動作状態として、稼動系と待機系との少なくとも２つを持つ。そして、稼動系の場合、自己が属するサーバマシン１０（例えば、クラスタソフト１２（＃Ａ）の場合であれば、サーバマシン１０（＃Ａ））上でアプリケーション１１を動作させる。一方、待機系にある場合には、自己が属するサーバマシン１０（例えば、クラスタソフト１２（＃Ｂ）の場合であれば、サーバマシン１０（＃Ｂ））上でアプリケーション１１を動作させない。また、異なるサーバマシン１０（例えば、サーバマシン１０（＃Ａ））に備えられた他のクラスタソフト１２（クラスタソフト１２（＃Ａ））と互いに定期的に通信することによって、通信相手のクラスタソフト１２（クラスタソフト１２（＃Ａ））の生存状態を確認する。そして、図３に示すように自己（クラスタソフト１２（＃Ｂ））が待機系にある場合、稼動系にある通信相手のクラスタソフト１２（クラスタソフト１２（＃Ａ））が生存していないと判定された場合（Ｔ１）には、自己（クラスタソフト１２（＃Ｂ））の動作状態を待機系から稼動系に変更する（Ｔ２）。

これにあわせて、フィルタドライバ２１（フィルタドライバ２１（＃Ｂ））は、自己が属するサーバマシン１０（サーバマシン１０（＃Ｂ））がアクセス権を持ち、通信相手のクラスタソフト１２（クラスタソフト１２（＃Ａ））が属するサーバマシン１０（サーバマシン１０（＃Ａ））がアクセス権を持たないようにアクセス権管理領域１７０の内容を変更する（Ｔ３）。図３に示す例は、今までアクセス権を持っていたサーバマシン１０（＃Ａ）がアクセス権を失い（○→×）、代わって、アクセス権を持っていなかったサーバマシン１０（＃Ｂ）がアクセス権を持つ（×→○）ように変更される状態を示している。続いて、クラスタソフト１２（＃Ｂ）は、共有ディスク装置１３にバスリセットを送信する。これにより、サーバマシン１０（＃Ａ）からの次のＩ／Ｏ命令がエラーで返るようになる（Ｔ４）。

ここで、フィルタドライバ２１は、同じサーバマシン１０に属するクラスタソフト１２の動作状態が稼動系になった後は、該サーバマシン１０の上位からのＩ／Ｏ命令を待つ。そして、Ｉ／Ｏ命令があった場合にはＩ／Ｏ命令を下位に受け渡し、このＩ／Ｏ命令に対する処理が正常に完了した旨が下位から返ってきた場合にはその旨を上位に返す。一方、正常に完了した旨が下位から返ってこない場合には、アクセス権管理領域１７０を参照し、自己が属するサーバマシン１０にアクセス権が与えられているのであればＩ／Ｏ命令を下位に再度受け渡し、アクセス権が与えられていないのであれば、自己が属するサーバマシン１０のクラスタソフト１２の動作状態が稼動系ではないことを把握し、予め定めたエラー処理を行う（Ｔ５、Ｔ６）。

このように、アクセス権を持つサーバマシン１０だけが、マスター領域３０にアクセス可能となり、アプリケーション１１を動作させ、そのデータをマスター領域３０に書き込むことが可能となる。一方、アクセス権を持たないサーバマシン１０は、マスター領域３０にアクセスすることができない。

次に、本実施の形態に係るクラスタシステムの動作について説明する。ただし、初期状態として、サーバマシン１０（＃Ａ）とサーバマシン１０（＃Ｂ）との間ではクラスタソフト１２（＃Ａ，＃Ｂ）同士がハートビートを交換し、互いの生存が確認できており、サーバマシン１０（＃Ａ，＃Ｂ）ともに、ＱＵＯＲＵＭ用領域１７とマスター領域３０は上位から見えない（フィルタドライバがフェンスオフ）状態になっており、サーバマシン１０（＃Ａ，＃Ｂ）ともにアプリケーション１１（＃Ａ，＃Ｂ）は起動していないものとする。

まず、図４に示すフローチャートを用いて、サーバマシン１０（＃Ａ）を稼動系に設定する場合におけるクラスタソフト１２（＃Ａ）による処理の流れを説明する。

まず、ユーザ操作により、サーバマシン１０（＃Ａ）を稼動系にせよとの通知が、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）に届く（Ｓ１）。次に、クラスタソフト１２（＃Ａ）によって、サーバマシン１０（＃Ａ）にアクセス権が与えられるようにアクセス権管理領域１７０が設定される（Ｓ２）。すると、クラスタソフト１２（＃Ａ）によって、フィルタドライバ２１（＃Ａ）に稼動系となったことが通知される（Ｓ３）。その後、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）によって、上位からマスター領域３０が見える状態にされる（Ｓ４）。そして、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）によって、アプリケーション１１（＃Ａ）が起動される（Ｓ５）。

次に、図５のフローチャートを用いて、サーバマシン１０（＃Ａ）を稼動系に設定した後のフィルタドライバ２１（＃Ａ）による処理の流れを説明する。

まず、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）が上位からのＩ／Ｏ入力を待つ（Ｓ１１）。そして、Ｉ／Ｏ入力がなされると、なされたＩ／Ｏ入力の種別が判定される。なされたＩ／Ｏ入力がマスター領域３０への命令であれば（Ｓ１２：Ｙｅｓ）ステップＳ１３へ、そうでなければ（Ｓ１２：Ｎｏ）ステップＳ２０へそれぞれ進む。

ステップＳ１３では、アクセス権管理領域１７０を参照する（Ｓ１３）。そして、サーバマシン１０（＃Ａ）がアクセス権を持っているのであれば（Ｓ１３：Ｙｅｓ）、サーバマシン１０（＃Ａ）のフィルタドライバ２１（＃Ａ）が下位に命令を渡す（Ｓ１４）。そして、このＩ／Ｏ命令に対する処理が正常に完了した旨が下位から返ってきた場合には（Ｓ１５：Good）その旨を上位に返す（Ｓ１６）。

一方、正常に完了した旨が下位から返ってこない場合（Ｓ１５：Check Condition）には、アクセス権管理領域１７０を参照する（Ｓ１７）。そして、サーバマシン１０（＃Ａ）がアクセス権を持っているのであれば（Ｓ１８：Ｙｅｓ）、ステップＳ１４に戻ってＩ／Ｏ命令を下位に再度受け渡し、アクセス権を持っていないのであれば（Ｓ１８：Ｎｏ）、自己が属するサーバマシン１０のクラスタソフト１２の動作状態が稼動系ではないことを把握し、ステップＳ１９に進み、予め定めたエラー処理を行う（Ｓ１９）。

また、ステップＳ１５において、正常に完了した旨が下位から返ってきた訳でも、返ってこない訳でもない場合（Ｓ１５：その他）、また、ステップＳ１３において、アクセス権を持っていない場合（Ｓ１３：Ｎｏ）にもステップＳ１９に進む。

ステップＳ２０では、下位のＨＢＡドライバ２２にそのまま処理を渡し（Ｓ２０）、その後、返り値をそのまま上位へリターンする（Ｓ２１）。

次に、図６に示すフローチャートと、図７に示す概念図とを用いて、サーバマシン１０（＃Ｂ）がハートビート切れを検出し、フェールオーバするときのサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）による処理の流れを説明する。

まず、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）は、サーバマシン１０（＃Ａ）が、図７中のＸに示すようにｗｒｉｔｅ中にスローダウンすることによってハートビート切れを検出する（Ｓ３１）と、アクセス権管理領域１７０において、サーバマシン１０（＃Ａ）からサーバマシン１０（＃Ｂ）にアクセス権が変更される（Ｓ３２）。

次に、クラスタソフト１２（＃Ｂ）が、ＨＢＡドライバ２２（＃Ｂ）に対してバスリセットを発行し、これにより、マスター領域３０がユニットアテンション状態になる（Ｓ３３）。続いて、クラスタソフト１２（＃Ｂ）によって、フィルタドライバ２１（＃Ｂ）にサーバマシン１０（＃Ｂ）が稼動系になったことが通知される（Ｓ３４）。その後、サーバマシン１０（＃Ｂ）のフィルタドライバ２１（＃Ｂ）によって、上位からマスター領域３０が見える状態にされる（Ｓ３５）。そして、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）によって、アプリケーション１１（＃Ｂ）が起動される（Ｓ３６）。

なお、スローダウンしたサーバマシン１０（＃Ａ）は、何れの場合であっても、しばらくした後に復帰するものとする。しかしながら、復帰後、マスター領域３０に対してｗｒｉｔｅを試みるものの、チェックコンディションＹが返されるため、図５のフローチャートに従い、これ以降、マスター領域３０へデータを書き込まなくなる。これにより、両系同時書き込みによるデータ破壊を防ぐことができる。

このようなクラスタシステムは、例えば磁気ディスク等の記録媒体に記録されたプログラムや、インターネット等の通信ネットワークを介してダウンロードしたプログラムを読み込み、このプログラムによって動作が制御されるサーバマシン１０によって実現される。

また、このプログラムは、サーバマシン１０に実行させることができるものであって、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハ一ドディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記録媒体に格納し、またインターネット等の通信媒体により伝送して頒布することもできる。

なお、記録媒体に格納されるプログラムは、サーバマシン１０に実行させるソフトウェア手段（実行プログラムのみならずテーブルやデータ構造も含む）をサーバマシン１０内に構成させる設定プログラムをも含む。

また、このプログラムは、記録媒体から、あるいは通信媒体からサーバマシン１０に読み込まれると、サーバマシン１０を動作させることによって上述した処理を実行させる。

上述したように、本実施の形態に係るクラスタシステムにおいては、上記のような作用により、共有ディスク装置１３への依存性が少なく、また、共有ディスク装置１３上のデータフォーマットが汎用的であるようなソフトウェア排他を実現できる。また、稼動系サーバマシン１０のダウン、通信路１４の障害、稼動系サーバマシン１０でのＣＰＵ高負荷等による一時的なスローダウンの発生の何れの原因でハートビート断絶が起こった場合であっても、マスター領域３０のへの両系同時書き込みによるデータ破壊を防ぐことができる。

また、フィルタドライバ２１をマルチパスドライバ２０の下位に配置しているので、マルチパスドライバ２０の実装に依存せずに上記作用効果を奏することができる。

更に、フィルタドライバ２１とＨＢＡドライバ２２とを同一モジュールにすれば、ＨＢＡドライバ２２のみで上記作用効果を奏することができる。

更にまた、フィルタドライバ２１の持つ機能を、ＨＢＡカード２２０に実装させることによって、ＨＢＡカード２２０のみで上記作用効果を奏することができる。

（第２の実施の形態）
第２の実施の形態に係るクラスタシステムは、第１の実施の形態に係るクラスタシステムの変形例であるので、第１の実施の形態と同一部位については同一符番で示して重複説明を省略し、異なる点について説明する。

図８は、本実施の形態における図２に対応する概念図である。

すなわち、本実施の形態に係るクラスタシステムでは、共有ディスク装置１３のマスター領域３０に、複数のＬＵ３１を備えている。図８では、一例として２つのＬＵ３１（＃１，＃２）を示しているが、もちろん２つに限られるものではない。

そして、アクセス権管理領域１７０は、これらＬＵ３１（＃１，＃２）のそれぞれに対するアクセス権を設定できるようになっている。

このようなクラスタシステムにおいて、（１）第１のアプリケーションに対してはサーバマシン１０（＃Ｂ）が稼動系で、サーバマシン１０（＃Ａ）が待機系となっており、（２）第２のアプリケーションに対してはサーバマシン１０（＃Ａ）が稼動系で、サーバマシン１０（＃Ｂ）が待機系となっている状態を想定する。

上記（１）の場合、ハートビート切れが生じると、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）がそれを検出し、フィルタドライバ２１（＃Ａ）がＬＵ３１（＃２）のアクセス権を奪ってリセットを発行する。これ以降、サーバマシン１０（＃Ｂ）によるＬＵ３１（＃２）へのアクセスはエラーとなる。

上記（２）の場合、ハートビート切れが生じると、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）がそれを検出し、フィルタドライバ２１（＃Ｂ）がＬＵ３１（＃１）のアクセス権を奪ってリセットを発行する。これ以降、サーバマシン１０（＃Ａ）によるＬＵ３１（＃１）へのアクセスはエラーとなる。

上記（１）の場合のハートビート切れ、又は（２）の場合のハートビート切れのうちの何れか一方が起きる場合は、第１の実施の形態と同様である。

一方、上記（１）の場合のハートビート切れと、上記（２）の場合のハートビート切れとの両方が同時に起きた場合であって、更に、リセットが各ＬＵ３１（＃１，＃２）毎に発行できる場合であれば、上記（１）の場合のハートビート切れ後の処理の流れと、上記（２）の場合のハートビート切れ後の処理の流れとは独立した事象となるため、同様に第１の実施の形態と同様である。

一方、上記（１）の場合のハートビート切れと、上記（２）の場合のハートビート切れとの両方が同時に起きた場合であって、更に、リセットがＬＵ３１（＃１，＃２）に跨って発行される場合、リセットが２度発行されるため、フィルタドライバ２１はアクセス権の同期を２回行うことになる。しかしながら、同期回数が増えるデメリットは、フィルタドライバ２１におけるリトライ回数が増える程度であり、信頼性の面で問題となることはない。

したがって、本実施の形態に係るクラスタシステムのように、共有ディスク装置１３のマスター領域３０に複数のＬＵ３１を備え、かつ複数のアプリケーションがそれぞれ何れかのサーバマシン１０を稼動系として動作するような構成においても、第１の実施の形態に係るクラスタシステムと同様の作用効果を奏することができる。

（第３の実施の形態）
本実施の形態では、仮想マシン環境を利用したクラスタシステムについて説明する。

この仮想マシン環境を利用したクラスタシステムは、第１の実施の形態に係るクラスタシステムの変形例であり、例えば図９のブロック図に示すように、物理マシン１００上に複数の仮想マシン１０２が用意され、仮想マシンモニタ１０１が、これら複数の仮想マシン１０２を制御する。更に、各仮想マシン１０２は、各仮想マシン１０２上でそれぞれ動くゲストＯＳ １０４と称されるＯＳと、ゲストＯＳ １０４上に配置されたフィルタドライバ１０６及びクラスタソフト１０８を備えている。更に各仮想マシン１０２は同一のアプリケーション１１０を備えている。

図９は、一例として物理マシン１００内に２つの仮想マシン１０２（＃１，＃２）を設けた例を示している。また、フィルタドライバ１０６及びクラスタソフト１０８の構成は、第１の実施の形態におけるフィルタドライバ２１及びクラスタソフト１２と同じである。

また、共有ディスク装置１３は、３つの仮想ディスク１３０（＃０，＃１，＃２）を備えており、仮想ディスク１３０（＃０）はＱＵＯＲＵＭ用領域として、仮想ディスク１３０（＃１，＃２）は図１のマスター領域３０に相当するデータ用として使用される。なお、本実施の形態は、このように仮想ディスクとする場合に限定されることはなく、ＬＵをそのまま使用することもできる。

図１０は、仮想マシン環境を利用したクラスタシステムの別の構成例を示す図であり、複数の物理マシン１００を備え、各物理マシン１００がそれぞれ１つの仮想マシン１０２のみを備えている点が図９の構成と異なっている。

図１１は、仮想マシン環境を利用したクラスタシステムの更に別の構成例を示す図であり、仮想マシン１０２（＃１）と物理マシン１００（＃２）とを混在させて本発明のクラスタシステムを構築した例である。

以上、図９及び図１０にその一例を示すように、仮想マシン環境を利用した場合であっても、物理マシンの代わりに仮想マシン、ＬＵの代わりに仮想ディスクとなるだけであり、第１及び第２の実施の形態に係るクラスタシステムと本質的に同じ機能を有するクラスタシステムを構築することが可能となる。

また、図１１にその一例を示すように、物理マシンと仮想マシンとを混在させた場合であっても、第１及び第２の実施の形態に係るクラスタシステムと本質的に同じ機能を有するクラスタシステムを構築することが可能となる。

以上、本発明を実施するための最良の形態について、添付図面を参照しながら説明したが、本発明はかかる構成に限定されない。特許請求の範囲の発明された技術的思想の範疇において、当業者であれば、各種の変更例及び修正例に想到し得るものであり、それら変更例及び修正例についても本発明の技術的範囲に属するものと了解される。

例えば、上記実施の形態では、２台のサーバマシン１０（＃Ａ，＃Ｂ）によって構成されるクラスタシステムを例に説明したが、当業者であれば、本発明のクラスタシステムは、２台のサーバマシン１０に限定されるものではなく、３台以上のサーバマシン１０からなるクラスタシステムにも同様に適用可能であることが理解されよう。

第１の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図。 サーバマシンと共有ディスク装置との関連性を詳細に示す概念図。 サーバマシンと共有ディスク装置との関連性を詳細に示す概念図。 サーバマシンを稼動系に設定する場合におけるクラスタソフトによる処理の流れを示すフローチャート。 サーバマシンを稼動系に設定した後のフィルタドライバによる処理の流れを示すフローチャート。 サーバマシンがハートビート切れを検出し、フェールオーバするときのサーバマシンのクラスタソフトによる処理の流れを示すフローチャート。 サーバマシンがハートビート切れを検出し、フェールオーバするときのサーバマシンのクラスタソフトによる処理と、サーバマシンにフェールオーバ後のフィルタドライバによる処理の流れを示す概念図。 第２の実施の形態に係るクラスタシステムにおけるサーバマシンと共有ディスク装置との関連性を詳細に示す概念図 仮想マシン環境を利用したクラスタシステムの構成例を示す機能ブロック図。 仮想マシン環境を利用したクラスタシステムの別の構成例を示す機能ブロック図。 仮想マシン環境を利用したクラスタシステムの更に別の構成例を示す機能ブロック図。 従来技術のクラスタシステムによるフェールオーバを説明するための概念図。 従来技術のクラスタシステムによるフェールオーバ時に生じるデータ破壊を説明するための概念図。 リザーブ排他機能を用いた従来技術のクラスタシステムによるフェールオーバを説明するための概念図。 ＱＵＯＲＵＭを用いた従来技術のクラスタシステムによるフェールオーバを説明するための概念図。 ＱＵＯＲＵＭを用いた従来技術のクラスタシステムによるフェールオーバ時に生じるデータ破壊を説明するための概念図。

符号の説明

ａ…ハートビート、ｂ…フェールオーバ、１０…サーバマシン、１１…アプリケーション、１２…クラスタソフト、１３…共有ディスク装置、１４…通信路、１５…データ領域、１７…ＱＵＯＲＵＭ用領域、１８…アプリケーションデータ用領域、２０…マルチパスドライバ、２１…フィルタドライバ、２２…ホストバスアダプタドライバ、２３…ＦＣケーブル、３０…マスター領域、３１…ＬＵ、１００…物理マシン、１０１…仮想マシンモニタ、１０２…仮想マシン、１０６…フィルタドライバ、１０８…クラスタソフト、１１０…アプリケーション、１３０…仮想ディスク、１７０…アクセス権管理領域、２２０…ＨＢＡカード

Claims (3)

1. 複数のサーバマシンと、前記複数のサーバマシンに接続された共有ディスク装置とから構成されるクラスタシステムであって、
   前記共有ディスク装置は、前記各サーバマシン上でそれぞれ動作する同一のアプリケーションのデータを格納するマスター領域と、前記各サーバマシン毎の前記マスター領域へのアクセス権を管理する管理領域とを備え、
   前記各サーバマシンは、動作状態変更手段と、マスター領域アクセス手段とをそれぞれ備え、
   前記各動作状態変更手段は、動作状態として、稼動系と待機系との少なくとも２つを持ち、異なるサーバマシンに備えられた他の動作状態変更手段と互いに定期的に通信することによって、通信相手の動作状態変更手段の生存状態を確認し、自己が前記動作状態が稼動系にある場合には、自己が属するサーバマシン上で前記アプリケーションを動作させる一方、前記動作状態が待機系にある場合には、自己が属するサーバマシン上で前記アプリケーションを動作させず、更に、前記生存状態の確認の結果、稼動系にある前記通信相手の動作状態変更手段が生存していないと判定された場合には、自己の動作状態を待機系から稼動系に変更し、自己が属するサーバマシン上で前記アプリケーションを動作させることが可能であり、
   前記各マスター領域アクセス手段は、同じサーバマシンに属する動作状態変更手段の動作状態が前記待機系から前記稼動系に変更された場合には、該サーバマシンに前記アクセス権が与えられるように前記管理領域の内容を変更し、
   前記各マスター領域アクセス手段は更に、同じサーバマシンに属する動作状態変更手段の動作状態が前記稼動系になった後は、該サーバマシンの上位からのＩ／Ｏ命令を待ち、前記Ｉ／Ｏ命令があった場合には前記Ｉ／Ｏ命令を下位に受け渡し、前記Ｉ／Ｏ命令に対する処理が正常に完了した旨が下位から返ってきた場合にはその旨を上位に返し、正常に完了した旨が下位から返ってこない場合には前記管理領域を参照し、前記アクセス権が該サーバマシンに与えられているのであれば前記Ｉ／Ｏ命令を下位に再度受け渡し、前記アクセス権が該サーバマシンに与えられていなければ、予め定めたエラー処理を行うことを特徴とするクラスタシステム。
2. 前記マスター領域アクセス手段を、ホストバスアダプタカードによって実現することを特徴とする請求項１のクラスタシステム。
3. 複数のサーバマシンと、前記複数のサーバマシンに接続された共有ディスク装置とから構成されるクラスタシステムに適用されるプログラムであって、
   前記共有ディスク装置は、前記各サーバマシン上でそれぞれ動作する同一のアプリケーションのデータを格納するマスター領域と、前記各サーバマシン毎の前記マスター領域へのアクセス権を管理する管理領域とを備え、
   前記各サーバマシンは、動作状態変更手段と、マスター領域アクセス手段とをそれぞれ備え、
   前記各動作状態変更手段が、動作状態として、稼動系と待機系との少なくとも２つを持ち、異なるサーバマシンに備えられた他の動作状態変更手段と互いに定期的に通信することによって、通信相手の動作状態変更手段の生存状態を確認する機能、
   前記各動作状態変更手段が、前記稼動系にある場合には、自己が属するサーバマシン上で前記アプリケーションを動作させる一方、前記待機系にある場合には、自己が属するサーバマシン上で前記アプリケーションを動作させない機能、
   前記生存状態の確認の結果、稼動系にある前記通信相手の動作状態変更手段が生存していないと判定され、かつ自己の動作状態が待機系にある場合には、前記各動作状態変更手段が、自己の動作状態を待機系から稼動系に変更し、自己が属するサーバマシン上で前記アプリケーションを動作させる機能、
   前記各マスター領域アクセス手段が、同じサーバマシンに属する動作状態変更手段の動作状態が前記待機系から前記稼動系に変更された場合には、該サーバマシンに前記アクセス権が与えられるように前記管理領域の内容を変更する機能、
   前記各マスター領域アクセス手段が更に、同じサーバマシンに属する動作状態変更手段の動作状態が前記稼動系になった後は、該サーバマシンの上位からのＩ／Ｏ命令を待ち、前記Ｉ／Ｏ命令があった場合には前記Ｉ／Ｏ命令を下位に受け渡し、前記Ｉ／Ｏ命令に対する処理が正常に完了した旨が下位から返ってきた場合にはその旨を上位に返し、正常に完了した旨が下位から返ってこない場合には前記管理領域を参照し、前記アクセス権が該サーバマシンに与えられているのであれば前記Ｉ／Ｏ命令を下位に再度受け渡し、前記アクセス権が該サーバマシンに与えられていなければ、予め定めたエラー処理を行う機能
   をコンピュータに実現させるためのプログラム。

Images