JP2008242742A - クラスタシステム - Google Patents

Abstract

【課題】クラスタシステムにおいて、フェールオーバが発生時であっても、ディスクＩ／Ｏの性能劣化を抑えながら、トランザクションの整合を図る。
【解決手段】フィルタドライバ１４（＃Ａ）は、稼動系になると、Ｉ／Ｏ入力を待ち、Ｉ／Ｏ入力の処理結果が成功の場合、有効期限通知デーモン１６（＃Ａ）から通知された有効期限内であれば処理結果をＩ／Ｏ入力側へ返し、有効期限内でなければＩ／Ｏ入力側へエラーを返す。一方、待機系のクラスタソフト１２（＃Ｂ）は、サーバマシン１０（＃Ａ）が生存していないと判定すると、共有領域３３に管理されたアクセス情報を、サーバマシン１０（＃Ｂ）のみがアクセス許可されるよう変更し、所定時間待機した後に、サーバマシン１０（＃Ｂ）側からサーバＢ用データ領域３２（＃Ｂ）が見える状態にするとともに、アプリケーション１１（＃Ｂ）を起動させる。
【選択図】 図１

Description

本発明は、複数のサーバマシンを備えてなるクラスタシステム及びプログラムに関し、特に、フェールオーバが発生した場合であっても、データの整合を図ることが可能なクラスタシステムに関する。

例えば、非特許文献１で開示されているシステムに代表されるクラスタシステムでは、図２０に示すように、稼動系のサーバマシン１０（＃Ａ）と待機系のサーバマシン１０（＃Ｂ）とが設けられ、稼動系のサーバマシン１０（＃Ａ）がアプリケーション１１（＃Ａ）を実行し、（１０１）に示すように、実行結果であるデータをミラーリングディスク装置２０（＃Ａ）に書き込む。その間、（１０２）に示すように、稼動系のサーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）と待機系のサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）とは、通信路５０を経由して、ハートビートａと呼ばれる所定のパケット交換をし続け、互いの生存を通知し合う。

更に、（１０３）に示すように、ハートビート継続中は、常時ミラーリングを行うことによって、ミラーリングディスク装置２０（＃Ａ）に格納されたデータが、ミラーリングディスク装置２０（＃Ｂ）にミラーリングされる。

このような状態において、クラスタソフト１２（＃Ｂ）が、ハートビートａの断絶を検出すると、（１０４）に示すように、待機系のサーバマシン１０（＃Ｂ）で同一のアプリケーション１１（＃Ｂ）を起動させることでアプリケーション処理を継続させる、所謂フェールオーバｂが一般に行われている。

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

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

すなわち、図２１に示すように、複数台のサーバマシン１０（＃Ａ，＃Ｂ）で通信回線５２を経由してミラーリングディスク装置２０（＃Ａ），２０（＃Ｂ）をミラーリングした状態で、データベースサーバアプリケーション（以降「ＤＢサーバ」と称する）１３（＃Ａ，＃Ｂ）を対象にクラスタを構成する場合、上記［３］が原因のハートビートａ断絶によりフェールオーバｂが発生すると、ミラーリングディスク装置２０（＃Ａ），２０（＃Ｂ）間のミラーリングは強制的に停止される。これは、待機系であったサーバマシン１０（＃Ｂ）で新たに実行するＤＢサーバ１３（＃Ｂ）からのｗｒｉｔｅと、稼動系であったサーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）からのｗｒｉｔｅの混在によるデータ破壊を避けるためである。

しかしながら、待機系であったサーバマシン１０（＃Ｂ）が、稼動系であったサーバマシン１０（＃Ａ）のＩＰアドレスやデータ等を全て引き継ぐために、データベースクライアント（以降、「ＤＢクライアント」と称する）６１は、ＤＢサーバ１３（＃Ａ）がＤＢサーバ１３（＃Ｂ）へフェールオーバしたことを意識せず、トランザクションの整合性が崩れる可能性がある。

例えば、図２１に示すように、サーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）が、クライアント６０内のＤＢクライアント６１からのコミット要求を受け（２０１）、そのままスローダウンした場合（２０２）、クラスタソフト１２（＃Ｂ）がハートビートａ切れを検出する（２０３）ことにより、ミラーリングが中止される（２０４）とともに、サーバマシン１０（＃Ｂ）はフェールオーバを行う（２０５）。しかし、その後復帰したサーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）は、自らのミラーリングディスク装置２０（＃Ａ）にｗｒｉｔｅし、正常終了する（２０６）。このとき、ミラーリングは既に停止されているので行われない（２０７）が、ＤＢクライアント６１にコミット成功を返す（２０８）。

しかし、サーバマシン１０（＃Ｂ）にはこのコミットが反映されていないため、フェールオーバ後にサーバマシン１０（＃Ｂ）が、ＤＢクライアント６１からのロールバック要求を受けると（２０９）、サーバマシン１０（＃Ｂ）のＤＢサーバ１３（＃Ｂ）は、ＤＢクライアント６１が意図したチェックポイントよりも１つ前のチェックポイントまでロールバックされてしまう（２１０）。さらにその後、ＤＢクライアント６１からサーバマシン１０（＃Ｂ）に対してなされた要求（２１１）にしたがって、データベースＢにてデータベースの更新やコミットが行われると（２１２）、サーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）もサーバマシン１０（＃Ｂ）のＤＢサーバ１３（＃Ｂ）も、本来あるべき姿とは異なる状態になってしまう。

同様の問題は、図２２に示すように、ミラーリングディスク装置２０（＃Ａ，＃Ｂ）の代わりに、サーバマシン１０（＃Ａ）によってなされたデータを書き込むためのサーバＡ用データ領域３２（＃Ａ）と、サーバマシン１０（＃Ｂ）によってなされたデータを書き込むためのサーバＢ用データ領域３２（＃Ｂ）とを備えた共有ディスク装置３１を用い、クラスタを組んだ場合においても発生する可能性がある。

すなわち、図２２に示すように、サーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）が、クライアント６０内のＤＢクライアント６１からのコミット要求を受け（３０１）、そのままスローダウンした場合（３０２）、クラスタソフト１２（＃Ｂ）がハートビートａ切れを検出すると（３０３）、サーバＡ用データ領域３２（＃Ａ）のデータがサーバＢ用データ領域３２（＃Ｂ）にコピーされる（３０４）とともに、サーバマシン１０（＃Ｂ）はフェールオーバを行う（３０５）。しかし、その後復帰したサーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）は、サーバＡ用データ領域３２（＃Ａ）にｗｒｉｔｅし、正常終了し（３０６）、ＤＢクライアント６１にコミット成功を返す（３０７）。

しかし、サーバマシン１０（＃Ｂ）にはこのコミットが反映されていないため、フェールオーバ後にサーバマシン１０（＃Ｂ）が、ＤＢクライアント６１からのロールバック要求を受けると（３０８）、サーバマシン１０（＃Ｂ）のＤＢサーバ１３（＃Ｂ）は、ＤＢクライアント６１が意図したチェックポイントよりも１つ前のチェックポイントまでロールバックされてしまう（３０９）。さらにその後、ＤＢクライアント６１からサーバマシン１０（＃Ｂ）に対してなされた要求（３１０）にしたがって、ＤＢサーバ１３（＃Ｂ）にてデータベースの更新やコミットが行われると（３１１）、サーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）もサーバマシン１０（＃Ｂ）のＤＢサーバ１３（＃Ｂ）も、本来あるべき姿とは異なる状態になってしまう。

以上のことから、従来のクラスタシステムでは、元稼動系であったサーバマシン１０（＃Ａ）が復帰してハートビートａが復活した場合には、即座にサーバマシン１０（＃Ａ）及びサーバマシン１０（＃Ｂ）を停止あるいは再起動したり、クラスタソフト１２（＃Ａ），１２（＃Ｂ）間の通信路５０を多重化することにより、通信路５０の一つに障害が発生した場合であってもハートビートａの断絶が発生しないような対策が講じられている。
東芝レビュー Ｖｏｌ．５４ Ｎｏ．１２（１９９９）、１８〜２１ページ

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

すなわち、上述した対策を講じても、上記［３］稼動系のサーバマシン１０におけるＣＰＵ高負荷等により一時的なスローダウンが発生した場合には、フェールオーバした直後にトランザクションの不整合が発生するという可能性を完全に回避できるものではないという問題がある。

この不整合は、例えば図２２に示すクラスタシステムを、図２３に示すように、共有ディスク装置３１に共有領域３３を設け、共有領域３３に格納されたディスクアクセス権管理テーブル３３ａによって共有ディスク装置３１へのアクセス権を管理するとともに、サーバマシン１０にフィルタドライバ１４を設け、共有ディスク装置３１へのデータの書き込み（Ｗｒｉｔｅ）や読み出し（Ｒｅａｄ）（以下、Ｉ／Ｏと呼ぶ）が発生するたびにアクセス権の有無に応じて処理結果を上位であるクライアント６０に戻す方式をとり、フェールオーバ時に、待機系であるサーバマシン１０（＃Ｂ）が、稼動系であるサーバマシン１０（＃Ａ）のアクセス権を奪うように改良することによって回避することができる。

すなわち、この構成では、サーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）が、クライアント６０内のＤＢクライアント６１からのコミット要求を受け（４０１）、そのままスローダウンした場合（４０２）、クラスタソフト１２（＃Ｂ）がハートビートａ切れを検出すると（４０３）、クラスタソフト１２（＃Ｂ）は更に、ディスクアクセス権管理テーブル３３ａを、サーバマシン１０（＃Ａ）ではなくサーバマシン１０（＃Ｂ）に共有ディスク装置３１へのアクセス権が与えられるように書き換える（４０４）。

その後、サーバＡ用データ領域３２（＃Ａ）のデータがサーバＢ用データ領域３２（＃Ｂ）にコピーされる（４０５）とともに、サーバマシン１０（＃Ｂ）がフェールオーバする（４０６）。しかし、その後サーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）が復帰すると、フィルタドライバ１４（＃Ａ）は、ＤＢサーバ１３（＃Ａ）による処理結果をサーバＡ用データ領域３２（＃Ａ）にｗｒｉｔｅし（４０７）、更に、ディスクアクセス権管理テーブル３３ａを参照して、サーバマシン１０（＃Ａ）にアクセス権が与えられているかを確認する（４０８）。

そして、アクセス権が与えられていれば正常リターンがフィルタドライバ１４（＃Ａ）からＤＢサーバ１３（＃Ａ）へ返され、アクセス権が与えられていなければエラーリターンが返される（４０９）。この場合、サーバマシン１０（＃Ｂ）にアクセス権が与えられているので、エラーが返される。更に、このエラーがＤＢサーバ１３（＃Ａ）からＤＢクライアント６１へ返される（４１０）。

これによりクライアント６０は、（４０１）でサーバマシン１０（＃Ａ）に行ったコミット要求に対する処理がエラーになったことを把握し、今度はサーバマシン１０（＃Ｂ）に要求することによりコミット要求のリトライを行う（４１１）。それに対しＤＢサーバ１３（＃Ｂ）がコミット要求完了をＤＢクライアント６１に通知する（４１２）。さらにその後、ＤＢクライアント６１がサーバマシン１０（＃Ｂ）に対して行ったデータベース更新要求（４１３）にしたがって、ＤＢサーバ１３（＃Ｂ）にてデータベースの更新が行われる（４１４）。

その後は、ＤＢクライアント６１からＤＢサーバ１３（＃Ｂ）に対してデータベースのロールバック要求がなされ（４１５）、それに対して、ＤＢサーバ１３（＃Ｂ）からＤＢクライアント６１へロールバック要求完了（成功）が通知される（４１６）。続いて、ＤＢクライアント６１からＤＢサーバ１３（＃Ｂ）に対してデータベースの更新要求がなされ（４１７）、それに対して、ＤＢサーバ１３（＃Ｂ）からＤＢクライアント６１へ更新要求完了（成功）が通知される（４１８）。更に、ＤＢクライアント６１からＤＢサーバ１３（＃Ｂ）に対してコミット要求がなされ（４１９）、それに対して、ＤＢサーバ１３（＃Ｂ）からＤＢクライアント６１へコミット要求完了（成功）が通知される（４２０）。

しかしながら、図２３に示すような構成では、ディスクＩ／Ｏ（ｒｅａｄやｗｒｉｔｅ）が１回発生するたびに共有ディスク装置３１へのＩ／Ｏ（ｒｅａｄやｗｒｉｔｅ）が１回発生するため、ディスクＩ／Ｏの性能劣化が大きくなってしまうという新たな問題が発生する。

一方、図２４は、図２３に示すような改良点を、図２１に示すミラーリングディスク装置２０を備えたクラスタシステムに適用した構成を示す。

すなわち、この構成では、サーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）が、クライアント６０内のＤＢクライアント６１からのコミット要求を受け（５０１）、これに基づいてフィルタドライバ１４（＃Ａ）が、コミット要求に対応するｗｒｉｔｅをミラーリングディスク装置２０（＃Ａ）に発行する（５０２）。

そして、その後、ミラーリングディスク装置２０（＃Ａ）が、ミラーリングディスク装置２０（＃Ｂ）にデータをコピーしてミラーリングする際に、サーバマシン１０（＃Ａ）がスローダウンし（５０３）、その後復帰するものとする。この場合、スローダウンが発生した時点でクラスタソフト１２（＃Ｂ）がハートビートａ切れを検出する（５０４）。その後、サーバマシン１０（＃Ａ）が復帰しても、通信タイムアウト等によりミラーリングディスク装置２０（＃Ａ）からミラーリングディスク装置２０（＃Ｂ）へのミラーリングは失敗してしまう（５０５）。

その後、フィルタドライバ１４（＃Ａ）は、ディスクアクセス権管理テーブル３３ａを参照して、サーバマシン１０（＃Ａ）にアクセス権が与えられているかを確認する（５０６）。この時点で、クラスタソフト１２（＃Ｂ）によって、ディスクアクセス権管理テーブル３３ａが、アクセス権がサーバマシン１０（＃Ｂ）に与えられるように書き換えられていなければ、すなわち、（５０６）のタイミングの後に、クラスタソフト１２（＃Ｂ）によって、ディスクアクセス権管理テーブル３３ａが、アクセス権がサーバマシン１０（＃Ｂ）に与えられるように書き換えられる（５０７）のであれば、フィルタドライバ１４（＃Ａ）は、ＤＢサーバ１３（＃Ａ）に正常リターンを返す（５０８）。

その後、サーバマシン１０（＃Ｂ）がフェールオーバする（５０９）。一方、ＤＢサーバ１３（＃Ａ）は、ＤＢクライアント６１へコミット処理結果（成功）を通知する（５１０）。

しかし、サーバマシン１０（＃Ｂ）にはこのコミットが反映されていないため、フェールオーバ後にサーバマシン１０（＃Ｂ）が、ＤＢクライアント６１からのロールバック要求を受けると（５１１）、サーバマシン１０（＃Ｂ）のＤＢサーバ１３（＃Ｂ）は、ＤＢクライアント６１が意図したチェックポイントよりも１つ前のチェックポイントまでロールバックされてしまう（５１２）。さらにその後、ＤＢクライアント６１からサーバマシン１０（＃Ｂ）に対してなされた要求（５１３）にしたがって、ＤＢサーバ１３（＃Ｂ）にてデータベースの更新やコミットが行われると（５１４）、サーバマシン１０（＃Ａ）のＤＢサーバ１３（＃Ａ）もサーバマシン１０（＃Ｂ）のＤＢサーバ１３（＃Ｂ）も、本来あるべき姿とは異なる状態になってしまう。

このように、図２３に示すような改良点を、ミラーリングディスク装置２０を備えたクラスタシステムに適用した場合には、フェールオーバした直後にトランザクションの不整合が発生するという可能性を完全に回避できるものではないという問題は依然として解決されない。

本発明はこのような事情に鑑みてなされたものであり、複数のサーバマシンを備えてなるクラスタシステムにおいて、フェールオーバが発生した場合であっても、ディスクＩ／Ｏの性能劣化を抑えながら、トランザクションの整合を図ることが可能なクラスタシステム及びプログラムを提供することを目的とする。

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

すなわち、請求項１の発明は、複数のサーバマシンと、複数のサーバマシンに共有して接続された共有ディスク装置とから構成されたクラスタシステムであって、複数のサーバマシンは、複数のサーバマシン上でそれぞれ動作するアプリケーションと、複数のサーバマシン上でそれぞれ動作するクラスタソフトと、複数のサーバマシン上でそれぞれ動作するフィルタドライバと、複数のサーバマシン上でそれぞれ動作する有効期限通知デーモンとを備えている。また、共有ディスク装置は、各サーバマシンのデータをそれぞれ格納する各サーバ用データ領域と、各サーバマシンで共有する共有領域とを備え、共有領域は、各サーバマシンのそれぞれについて、共有ディスク装置へのアクセスの許可又は不許可が設定されたアクセス情報を管理するアクセス管理部を備えている。

また、有効期限通知デーモンは、アクセス管理部によって管理されているアクセス情報を定期的に参照し、自サーバマシンによるアクセスが許可されているのであれば、現在時間に所定時間を加えた有効期限を設定し、この有効期限を自サーバマシンのフィルタドライバに通知し、複数のサーバマシンに備えられた各クラスタソフトは、互いに定期的に通信して互いのサーバマシンの生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持つ。

そして、クラスタソフトが稼動系になる際には、このクラスタソフトは、アクセス管理部に管理されたアクセス情報を、自サーバマシンのみがアクセスを許可されるように変更し、自サーバマシン側から自サーバマシンのサーバ用データ領域が見える状態にし、自サーバマシンに備えられたアプリケーションを起動させる。クラスタソフトが稼動系になった後は、稼動系のサーバマシンのフィルタドライバは、Ｉ／Ｏ入力を待ち、Ｉ／Ｏ入力の処理結果の一部あるいは全てが成功の場合、現在時間を確認し、現在時間が、有効期限通知デーモンから通知された有効期限内であれば処理結果をＩ／Ｏ入力側へ返し、有効期限内でなければＩ／Ｏ入力側へエラーを返す。待機系のサーバマシンのクラスタソフトが、稼動系のサーバマシンが生存していないと判定した場合には、待機系のサーバマシンのクラスタソフトは、アクセス管理部に管理されたアクセス情報を、自サーバマシンのみがアクセスを許可されるように変更し、所定時間待機した後に、自サーバマシン側から自サーバマシンのサーバ用データ領域が見える状態にするとともに、自サーバマシンに備えられたアプリケーションを起動させる。

請求項２の発明は、複数のサーバマシンと、複数のサーバマシンにそれぞれ接続された複数のミラーリングディスク装置と、複数のサーバマシンに共有して接続された共有装置とから構成されたクラスタシステムであって、複数のサーバマシンは、複数のサーバマシン上でそれぞれ動作するアプリケーションと、複数のサーバマシン上でそれぞれ動作するクラスタソフトと、複数のサーバマシン上でそれぞれ動作するフィルタドライバと、複数のサーバマシン上でそれぞれ動作する有効期限通知デーモンとを備え、共有装置は、各サーバマシンのそれぞれについて、各ミラーリングディスク装置へのアクセスの許可又は不許可が設定されたアクセス情報を管理するアクセス管理部と、各サーバマシンのそれぞれについて、各ミラーリングディスク装置へのミラーリングエラーの発生の有無を示すミラーリングエラー情報を管理するミラーリングエラー発生有無管理部とを備えている。

有効期限通知デーモンは、アクセス管理部によって管理されているアクセス情報を定期的に参照し、自サーバマシンによるアクセスが許可されているのであれば、現在時間に所定時間を加えた有効期限を設定し、この有効期限を自サーバマシンのフィルタドライバに通知する。また、複数のサーバマシンに備えられた各クラスタソフトは、互いに定期的に通信して互いのサーバマシンの生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持つ。

そして、クラスタソフトが稼動系になる際には、このクラスタソフトは、アクセス管理部に管理されたアクセス情報を、自サーバマシンのみがアクセスを許可されるように変更し、自サーバマシン側から、自サーバマシンのミラーリングディスク装置が見える状態にし、自サーバマシンに備えられたアプリケーションを起動させる。クラスタソフトが稼動系になった後は、稼動系のサーバマシンのフィルタドライバは、Ｉ／Ｏ入力を待ち、Ｉ／Ｏ入力の処理を、各ミラーリングディスク装置に対して行わせ、各ミラーリングディスク装置による処理結果が同一の場合には、現在時間を確認し、現在時間が、有効期限通知デーモンから通知された有効期限内であれば処理結果をＩ／Ｏ入力側へ返し、有効期限内でなければＩ／Ｏ入力側へエラーを返し、処理結果が同一では無い場合には、ミラーリングエラー発生有無管理部に管理されたミラーリングエラー情報を、自サーバマシンについてミラーリングエラーが発生しているように変更する。待機系のサーバマシンのクラスタソフトが、稼動系のサーバマシンが生存していないと判定した場合には、待機系のサーバマシンのクラスタソフトは、アクセス管理部に管理されたアクセス情報を、自サーバマシンのみがアクセスを許可されるように変更し、所定時間待機した後に、ミラーリングエラー発生有無管理部に管理されたミラーリングエラー情報が、自サーバマシンについてミラーリングエラーが発生しているように設定されていないのであれば、自サーバマシン側から、自サーバマシンのミラーリングディスク装置が見える状態にするとともに、自サーバマシンに備えられたアプリケーションを起動させる。

請求項３の発明は、請求項１又は請求項２に記載のクラスタシステムにおいて、現在時間が、有効期限通知デーモンから通知された有効期限内であれば処理結果をＩ／Ｏ入力側へ返し、有効期限内でなければＩ／Ｏ入力側へエラーを返す代わりに、クラスタソフトの管理下にあるアプリケーションによってなされた処理結果についてのみ、現在時間を確認し、現在時間が、有効期限通知デーモンから通知された有効期限内であれば処理結果をＩ／Ｏ入力側へ返し、有効期限内でなければＩ／Ｏ入力側へエラーを返す。

本発明によれば、複数のサーバマシンを備えてなるクラスタシステムにおいて、フェールオーバが発生した場合であっても、ディスクＩ／Ｏの性能劣化を抑えながら、トランザクションの整合を図ることが可能なクラスタシステムを実現することができる。

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

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

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

すなわち、本実施の形態に係るクラスタシステムは、複数のサーバマシン（ここでは、一例として２つのサーバマシン１０（＃Ａ，＃Ｂ）を示す）と、これらサーバマシン１０（＃Ａ，＃Ｂ）に接続された共有ディスク装置３１とから構成されたクラスタシステムである。ここでは、仮に、初期状態として、サーバマシン１０（＃Ａ）が稼動系、サーバマシン１０（＃Ｂ）が待機系であるとする。各サーバマシン１０（＃Ａ，＃Ｂ）はそれぞれ、各サーバマシン１０（＃Ａ，＃Ｂ）上でそれぞれ動作するアプリケーション１１（＃Ａ,＃Ｂ）、クラスタソフト１２（＃Ａ，＃Ｂ）、フィルタドライバ１４（＃Ａ，＃Ｂ）、ディスクドライバ１５（＃Ａ，＃Ｂ）、有効期限通知デーモン１６（＃Ａ，＃Ｂ）を備えている。フィルタドライバ１４は、アプリケーション１１とディスクドライバ１５との間に介挿して設けられる。アプリケーション１１は、主にサーバアプリケーションを想定しており、本実施の形態では、プロキシキャッシュサーバであるとする。

共有ディスク装置３１は、各サーバマシン１０（＃Ａ，＃Ｂ）それぞれとＦＣ（Fiber Channel）ケーブル５１（＃Ａ，＃Ｂ）で接続されており、更にサーバＡ用データ領域３２（＃Ａ）、サーバＢ用データ領域３２（＃Ｂ）、及び共有領域３３を持つ。これらは、それぞれを異なるＬＵ（Logical Unit）でも、異なるパーティションでも、異なるファイルでも良い。

図２は、共有ディスク装置３１の詳細構成例を示す概念図である。

図２に示すように共有領域３３は、各サーバマシン１０（＃Ａ，＃Ｂ）のそれぞれについて、共有ディスク装置３１へのアクセスの許可又は不許可が設定されたアクセス情報を管理するディスクアクセス権管理テーブル３３ａを保持している。図２に示すように、サーバＡが「有」、サーバＢが「無」と設定されている場合は、サーバマシン１０（＃Ａ）のアクセスが許可され、サーバマシン１０（＃Ｂ）のアクセスが許可されていないことを示す。

ディスクアクセス権管理テーブル３３ａは、有効期限通知デーモン１６が、定期的（例えば３０秒毎）に参照する。そして、有効期限通知デーモン１６は、自サーバマシン１０によるアクセスが許可されているのであれば、現在時間に予め定めた所定時間（例えば、６０秒）を加えた有効期限を設定し、この有効期限を自サーバマシン１０のフィルタドライバ１４に通知する。なお、有効期限通知デーモン１６は、例えば図３に示すように、時刻変更の影響を受けないもの（ブート後の起動時間等）から現在時間を把握する。

また、クラスタソフト１２（＃Ａ，＃Ｂ）は、互いに定期的に通信し、互いのサーバマシン１０の生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持つ。以下の説明では、サーバマシン１０（＃Ａ）が稼動系であり、サーバマシン（＃Ｂ）が待機系であるものとする。したがって、クラスタソフト１２（＃Ａ）は稼動系の状態であり、クラスタソフト１２（＃Ｂ）は待機系の状態となっている。

クラスタソフト１２（＃Ａ）が稼動系になる際には、クラスタソフト１２（＃Ａ）は、ディスクアクセス権管理テーブル３３ａの情報を、自サーバマシン１０（＃Ａ）のみがアクセス許可されるように設定し、自サーバマシン１０（＃Ａ）側からサーバ用データ領域３２（＃Ａ）が見える状態にし、自サーバマシン１０（＃Ａ）に備えられたアプリケーション１１（＃Ａ）を起動させる。

このようにしてクラスタソフト１２（＃Ａ）が稼動系になった後は、フィルタドライバ１４（＃Ａ）は、例えば図２１に示すようなクライアント６０からのＩ／Ｏ入力を待ち、このＩ／Ｏ入力の処理結果の一部あるいは全てが成功の場合、現在時刻を確認し、現在時刻が、有効期限通知デーモン１６（＃Ａ）から通知された有効期限内であれば、処理結果を例えばクライアント６０のようなＩ／Ｏ入力側へ返し、有効期限内でなければＩ／Ｏ入力側へエラーを返す。このような現在時刻の確認は、フィルタドライバ１４（＃Ａ）が処理結果をＩ／Ｏ入力側に返すたびに行う。

一方、待機系のサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）が、稼動系のサーバマシン１０（＃Ａ）が生存していないと判定した場合には、クラスタソフト１２（＃Ｂ）は、ディスクアクセス権管理テーブル３３ａに設定されている情報を、サーバマシン１０（＃Ｂ）のみがアクセス許可されるように変更し、予め定めた所定時間（例えば３０秒）待機し、しかる後に、サーバマシン１０（＃Ｂ）側からサーバ用データ領域３２（＃Ｂ）が見える状態にするとともに、アプリケーション１１（＃Ｂ）を起動させる。

このように待機することにより、サーバマシン１０（＃Ｂ）がアクセス権を取得してから、即座にフェールオーバするのではなく、安全な時間帯に入ってからフェールオーバするようにしている。待機のための所定時間としては、任意に設定可能であるが、長くするほどフェールオーバに要する時間が長くなる。一方、短くするほどフェールオーバに要する時間は短くなるが、共有領域３３へのアクセス頻度も高くなるので、例えば３０秒のように１分以内が現実的である。

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

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

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

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

まず、サーバマシン１０（＃Ａ）のフィルタドライバ１４（＃Ａ）が、例えば図２１に示すクライアント６０のような上位からのＩ／Ｏ入力を待つ（Ｓ１１）。そして、Ｉ／Ｏ入力がなされ、なされたＩ／Ｏ入力が有効期限の通知である場合（Ｓ１２：Ｙｅｓ）には、ステップＳ１３に進み、有効期限の通知でない場合（Ｓ１２：Ｎｏ）には、ステップＳ１４に進む。

ステップＳ１３では、通知された有効期限に有効期間を更新した後に、ステップＳ２４の処理に進む。

ステップＳ１４では、ステップＳ１１でなされたＩ／Ｏ入力がサーバＡ用データ領域３２（＃Ａ）へのｒｅａｄであればステップＳ１５へ、ｗｒｉｔｅであればステップＳ１６へ、それ以外であればステップＳ２２へそれぞれ進む。

そして、ステップＳ１５ではｒｅａｄが、ステップＳ１６ではｗｒｉｔｅがそれぞれ実行され、ステップＳ１７の処理に進む。

ステップＳ１７では、Ｉ／Ｏが部分的に又は全部が成功した場合にはステップＳ１８の処理に進み、そうでない場合にはステップＳ２０の処理に進む。

ステップＳ１８では、現在の時刻が取得される。そして、ステップＳ１９では、有効期限通知デーモン１６（＃Ａ）から有効期限が通知され、ステップＳ１８で取得した現在の時刻が、有効期限内であるか否かが判定される。そして、有効期限内である場合には、Ｉ／Ｏの処理結果がそのまま上位へ返され（Ｓ２０）た後に、ステップＳ２４の処理に進む。

一方、ステップＳ１９において有効期限を過ぎていると判定された場合には、Ｉ／Ｏ処理失敗のエラーが上位へ返され（Ｓ２１）た後に、ステップＳ２４の処理に進む。

ステップＳ２２では、フィルタドライバ１４（＃Ａ）からディスクドライバ１５（＃Ａ）に処理がそのまま渡され、ステップＳ２３において、ディスクドライバ１５（＃Ａ）からの返り値がそのまま上位に返された後に、ステップＳ２４の処理に進む。

そして、ステップＳ２４では、ＯＳが終了するのであれば処理が終了し、そうでなければステップＳ１１の処理に戻る。

次に、図７のフローチャートと、図６に示す概念図とを用いて、サーバマシン１０（＃Ａ）を稼動系に設定した後の有効期限通知デーモン１６（＃Ａ）による処理の流れを説明する。

有効期限通知デーモン１６（＃Ａ）は、例えば３０秒毎のように、ディスクアクセス権管理テーブル３３ａを定期的に参照する（Ｓ３１）。そして、サーバマシン１０（＃Ａ）にアクセス権が与えられていることを確認すると（Ｓ３２）、現在時刻を取得し（Ｓ３３）、現在時刻に予め定めた所定時間（例えば６０秒）を加えることによって有効期限を設定し（Ｓ３４）、この有効期限をフィルタドライバ１４（＃Ａ）に通知し（Ｓ３５）、ステップＳ３６の処理に進む。また、ステップＳ３２において、アクセス権が与えられていない場合もステップＳ３６の処理に進む。なお、ステップＳ３５の処理は、図５におけるステップＳ１９に対応する。

ステップＳ３６では、例えば３０秒間スリープした後、ＯＳが終了しなければステップＳ３１の処理に戻り、ＯＳが終了するのであれば、この処理も終了する。

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

まず、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）がハートビートａ切れを検出する（Ｓ４１）と、クラスタソフト１２（＃Ｂ）によって、サーバマシン１０（＃Ｂ）にのみアクセス権が与えられるようにディスクアクセス権管理テーブル３３ａが設定される（Ｓ４２）。

次に、クラスタソフト１２（＃Ｂ）は、予め定めた所定時間（例えば、６０秒）スリープした（Ｓ４３）後に、サーバＡ用データ領域３２（＃Ａ）の全データをサーバＢ用データ領域３２（＃Ｂ）にコピーし（Ｓ４４）、更に有効期限通知デーモン１６（＃Ｂ）を起動し（Ｓ４５）、サーバマシン１０（＃Ｂ）が稼動系になったことをフィルタドライバ１４（＃Ｂ）に通知する（Ｓ４６）。

その後、サーバマシン１０（＃Ｂ）のフィルタドライバ１４（＃Ｂ）によって、上位層からサーバＢ用データ領域３２（＃Ｂ）が見える状態にされる（Ｓ４７）。そして、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）によってアプリケーション１１（＃Ｂ）が起動される（Ｓ４８）。

上述したように、本実施の形態に係るクラスタシステムにおいては、上記のような作用により、待機系のサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）が、稼動系のサーバマシン１０（＃Ａ）が生存していないと判定した場合には、サーバマシン１０（＃Ｂ）のみが共有ディスク装置３１へのアクセスが許可されるようにすることができる。

これにより、フェールオーバが発生した場合であっても、複数のサーバマシン１０（＃Ａ，＃Ｂ）の重複書き込みを回避することができ、トランザクションの整合を図ることが可能となる。

また、フェールオーバは、サーバマシン１０（＃Ｂ）がアクセス権を取得した後に直ちに実行するのではなく、予め定めた所定時間（例えば３０秒）待機し、安全な時間帯に入ってからフェールオーバするようにしている。

以上のことから、本実施の形態に係るクラスタシステムは、複数のサーバマシンを備えてなるクラスタシステムにおいて、フェールオーバが発生した場合であっても、ディスクＩ／Ｏの性能劣化を抑えながら、かつトランザクションの整合を図ることが可能となる。

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

すなわち、本実施の形態に係るクラスタシステムは、第１の実施の形態に係るクラスタシステムの概念を、ミラーリングディスク装置２０を備えたクラスタシステムに適用したものである。

図１０に示すような本実施の形態に係るクラスタシステムの、図１に示すような第１の実施の形態に係るクラスタシステムとの相違点を説明すると、図１０に示すようなミラーリングディスク装置２０を備えたクラスタシステムの場合、図１に示すようなクラスタシステムとは異なり、共有ディスク装置３１を備えていない代わりに、サーバマシン１０（＃Ａ）、及びサーバマシン１０（＃Ｂ）のにはそれぞれミラーリングディスク装置２０（＃Ａ），２０（＃Ｂ）が接続されている。また、共有領域３３を保持するための共通コンピュータ７０を備えている。共有領域３３は、第１の実施の形態に係るクラスタシステムと同様にディスクアクセス権管理テーブル３３ａを保持しているが、更にそれに加えて、各サーバマシン１０（＃Ａ）,１０（＃Ｂ）のそれぞれについて、各ミラーリングディスク装置２０（＃Ａ），（＃Ｂ）へのミラーリングエラーの発生の有無を示すミラーリングエラー情報を管理するミラーリングエラー発生有無管理テーブル３３ｂをも保持している。また、各サーバマシン１０（＃Ａ），１０（＃Ｂ）はそれぞれ、ミラーリングエラー発生有無管理テーブル３３ｂの参照及び設定を行うミラーリングデーモン１７（＃Ａ），１７（＃Ｂ）を備えている。

クラスタソフト１２（＃Ａ）が稼動系になった後は、第１の実施の形態と同様に、フィルタドライバ１４（＃Ａ）が、例えばクライアント６０からのＩ／Ｏ入力を待ち、このＩ／Ｏ入力の処理結果の一部あるいは全てが成功の場合、処理結果を、Ｉ／Ｏ入力側へ返すたびに現在時間を確認し、現在時間が、有効期限通知デーモン１６（＃Ａ）から通知された有効期限内であれば処理結果をＩ／Ｏ入力側へ返し、有効期限内でなければＩ／Ｏ入力側へエラーを返す。

しかしながら、処理結果が同一では無い場合に、本実施の形態では、ミラーリングデーモン１７（＃Ａ）が、ミラーリングエラー発生有無管理テーブル３３ｂに管理されたミラーリングエラー情報を、サーバマシン１０（＃Ａ）についてミラーリングエラーが発生しているように変更する。

そして、待機系のサーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）が、稼動系のサーバマシン１０（＃Ａ）が生存していないと判定した場合には、クラスタソフト１２（＃Ｂ）は、ディスクアクセス権管理テーブル３３ａに設定されている情報を、サーバマシン１０（＃Ｂ）のみがアクセス許可されるように変更し、予め定めた所定時間（例えば３０秒）待機した後に、ミラーリングエラー発生有無管理テーブル３３ｂに管理されたミラーリングエラー情報が、サーバマシン１０（＃Ｂ）についてミラーリングエラーが発生しているように設定されていないのであれば、サーバマシン１０（＃Ｂ）側から、ミラーリングディスク装置２０（＃Ｂ）が見える状態にするとともに、アプリケーション１１（＃Ｂ）を起動させる。

次に、以上のように構成した本実施の形態に係るクラスタシステムの動作について説明する。ただし、初期状態として、サーバマシン１０（＃Ａ）とサーバマシン１０（＃Ｂ）との間ではクラスタソフト１２（＃Ａ，＃Ｂ）同士がハートビートを交換し、互いの生存が確認できており、サーバマシン１０（＃Ａ，＃Ｂ）ともに、共有領域３３と各ミラーリングディスク装置２０（＃Ａ，＃Ｂ）は上位層から見えない（フィルタドライバ１４がフェンスオフ。ただし、ミラーリングデーモン１７のみアクセス可能）状態になっており、サーバマシン１０（＃Ａ，＃Ｂ）ともにアプリケーション１１（＃Ａ，＃Ｂ）は起動しておらず、ミラーリングデーモン１７は起動しているものとする。

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

まず、ユーザ操作により、サーバマシン１０（＃Ａ）を稼動系にせよとの通知が、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）に届く（Ｓ５１）。次に、クラスタソフト１２（＃Ａ）によって、サーバマシン１０（＃Ａ）にアクセス権が与えられるようにディスクアクセス権管理テーブル３３ａが設定される（Ｓ５２）。更に、クラスタソフト１２（＃Ａ）によって、ミラーリングエラー発生有無管理テーブル３３ｂに管理されたミラーリングエラー情報が、サーバマシン１０（＃Ａ）についてミラーリングエラーが発生していない（「ミラーリングエラー無」）ように設定される（Ｓ５３）。

すると、クラスタソフト１２（＃Ａ）がミラーリングデーモン１７（＃Ａ）に稼動系となったことが通知する（Ｓ５４）。そして、サーバマシン１０（＃Ａ）のクラスタソフト１２（＃Ａ）が有効期限通知デーモン１６（＃Ａ）を起動し（Ｓ５５）、クラスタソフト１２（＃Ａ）によって、フィルタドライバ１４（＃Ａ）に稼動系となったことを通知する（Ｓ５６）。

その後、サーバマシン１０（＃Ａ）のフィルタドライバ１４（＃Ａ）が上位層からミラーリングディスク装置２０（＃Ａ）が見える状態とする（Ｓ５７）。次に、アプリケーション１１（＃Ａ）が起動される（Ｓ５８）。

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

まず、サーバマシン１０（＃Ａ）のフィルタドライバ１４（＃Ａ）が、例えば図２１に示すクライアント６０のような上位からのＩ／Ｏ入力を待つ（Ｓ６１）。そして、Ｉ／Ｏ入力が有効期限の通知である場合（Ｓ６２：Ｙｅｓ）には、ステップＳ６３に進み、有効期限の通知でない場合（Ｓ６２：Ｎｏ）には、ステップＳ６４に進む。

ステップＳ６３では、有効期限を通知された有効期限に更新した後に、ステップＳ７８の処理に進む。

ステップＳ６４では、ステップＳ６１でなされたＩ／Ｏ入力がミラーリングディスク装置２０（＃Ａ）へのｒｅａｄであればステップＳ６５へ、ｗｒｉｔｅであればステップＳ６６へ、それ以外であればステップＳ７６へそれぞれ進む。

そして、ステップＳ６５ではｒｅａｄが実行され、ステップＳ７１の処理に進み、ステップＳ６６ではｗｒｉｔｅが実行され、ステップＳ６７の処理に進む。

ステップＳ６７では、ミラーリングデーモン１７（＃Ａ）にミラーリングを依頼して待機し、ステップＳ６８でミラーリングが実行される。そして、ミラーリングが成功したならばステップＳ７１の処理に進み、成功しなかったのならステップＳ７０においてミラーリングデーモン１７（＃Ａ）によって、ミラーリングエラー発生有無管理テーブル３３ｂの設定が、サーバマシン１０（＃Ａ）によるミラーリングエラー発生が有るように変更され、ステップＳ７１の処理に進む。

ステップＳ７１では、Ｉ／Ｏが部分的に又は全部が成功した場合にはステップＳ７２の処理に進み、そうでない場合にはステップＳ７４の処理に進む。

ステップＳ７２では、現在時刻が取得される。そして、ステップＳ７３では、有効期限通知デーモン１６（＃Ａ）から有効期限が通知され、ステップＳ７２で取得した現在の時刻が、有効期限内であるか否かが判定される。そして、有効期限内である場合には、Ｉ／Ｏの処理結果がそのまま上位へ返され（Ｓ７４）た後に、ステップＳ７８の処理に進む。

一方、ステップＳ７３において有効期限を過ぎていると判定された場合には、Ｉ／Ｏ処理失敗のエラーが上位へ返され（Ｓ７５）た後に、ステップＳ７８の処理に進む。

ステップＳ７６では、フィルタドライバ１４（＃Ａ）からディスクドライバ１５（＃Ａ）に処理がそのまま渡され、ステップＳ７７において、ディスクドライバ１５（＃Ａ）からの返り値がそのまま上位に返された後に、ステップＳ７８の処理に進む。

そして、ステップＳ７８では、ＯＳが終了するのであれば処理が終了し、そうでなければステップＳ６１の処理に戻る。

また、サーバマシン１０（＃Ａ）を稼動系に設定した後の有効期限通知デーモン１６（＃Ａ）による処理の流れは、図７のフローチャートに示す通りであるので、説明を省略する。

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

まず、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）がハートビートａ切れを検出する（Ｓ８１）と、クラスタソフト１２（＃Ｂ）によって、サーバマシン１０（＃Ｂ）にのみアクセス権が与えられるようにディスクアクセス権管理テーブル３３ａが設定される（Ｓ８２）。

次に、クラスタソフト１２（＃Ｂ）は、予め定めた所定時間（例えば、６０秒）スリープする（Ｓ８３）。

一方、ステップＳ８４において、ミラーリングエラー発生有無管理テーブル３３ｂにおいて、サーバマシン１０（＃Ａ）がミラーリングエラー発生有りと設定されている場合（Ｓ８４：Ｙｅｓ）には、ステップＳ８５の処理に進み、そうでない場合（Ｓ８４：Ｎｏ）には、ステップＳ９１の処理に進む。

ステップＳ８５では、クラスタソフト１２（＃Ｂ）によって、ミラーリングエラー発生有無管理テーブル３３ｂにおいて、サーバマシン１０（＃Ｂ）がミラーリングエラー発生無しと設定され、次に、ステップＳ８６では、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）によって、ミラーリングデーモン１７（＃Ｂ）に、稼動系になったことが通知される。これによって、ミラーリングデータの受信が停止される。

更に有効期限通知デーモン１６（＃Ｂ）を起動し（Ｓ８７）、サーバマシン１０（＃Ｂ）が稼動系になったことをフィルタドライバ１４（＃Ｂ）に通知する（Ｓ８８）。

その後、サーバマシン１０（＃Ｂ）のフィルタドライバ１４（＃Ｂ）によって、上位層からミラーリングディスク装置２０（＃Ｂ）が見える状態にされる（Ｓ８９）。そして、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）によってアプリケーション１１（＃Ｂ）が起動され（Ｓ９０）、処理を終了する。

ステップＳ９１では、クラスタソフト１２（＃Ｂ）が、ディスクアクセス権管理テーブル３３ａにおいて、サーバマシン１０（＃Ｂ）のアクセス権が「有」から「無」に変更され（フェールオーバが断念され）、処理を終了する。

上述したように、本実施の形態に係るクラスタシステムにおいては、上記のような作用により、ミラーリングに失敗している場合にはフェールオーバしないようにすることができる。また、フェールオーバした後には、元稼動系であるサーバマシン１０（＃Ａ）側でＩ／Ｏが成功しないようにすることができる。これにより、トランザクションの不整合の発生を回避することが可能となる。

また、ディスクＩ／Ｏ（ｒｅａｄやｗｒｉｔｅ）のたびにミラーリングディスク装置２０へのＩ／Ｏを発生させることがないので、ディスクＩ／Ｏの性能劣化を抑えることが可能となる。

以上のことから、本実施の形態に係るクラスタシステムは、複数のサーバマシンを備えてなるクラスタシステムにおいて、フェールオーバが発生した場合であっても、ディスクＩ／Ｏの性能劣化を抑えながら、かつトランザクションの整合を図ることが可能となる。

（第３の実施の形態）
本実施の形態に係るクラスタシステムは、第１及び第２の実施の形態に係るクラスタシステムの変形例であり、図１６に示すように、フィルタドライバ１４に代えて、ジャケットライブラリ（以降、「ジャケットＤＬＬ」と称する）１８と、Ｉ／Ｏ処理用ライブラリ（以降、「Ｉ／０処理用ＤＬＬ」と称する）１９とを備えた構成としている点のみが異なる。したがって、ここでは、第１及び第２の実施の形態に係るクラスタシステムと異なる点について説明する。

すなわち、第１及び第２の実施の形態に係るクラスタシステムでは、フィルタドライバ１４が有効期限を判定していたが、本実施の形態では、フィルタドライバ１４ではなく、上位のライブラリが行うようにしている。この際、本来のＩ／Ｏ処理を行うためのＩ／Ｏ処理用ＤＬＬ１９と、アプリケーション１１との間に、Ｉ／Ｏをフックして独自の処理を行うジャケットＤＬＬ１８を備えている。ジャケットＤＬＬの詳細については、特開平１１−１１０１９４号公報を参照されたい。このジャケットＤＬＬ １８は、アプリケーション１１から見ると、Ｉ／Ｏ処理用ＤＬＬ１９であるかのように見えるものであり、図１７に示すように、アプリケーション１１のプロセスハンドル管理テーブル１８ａを持ち、管理しているアプリケーション１１（図１７に示すプロセス１、プロセス２）に対してのみ有効期限による判定ルーチンを通す。

なお、以下では、図１６に示すように、代表的に、第１の実施の形態に示すような共有ディスク装置３１を備えた構成に適用した場合について説明するが、本実施の形態のようにフィルタドライバ１４の代わりにジャケットＤＬＬ１８と、Ｉ／Ｏ処理用ＤＬＬ１９とを備えた構成は、第２の実施の形態に示すようなミラーリングディスク装置２０を備えた構成に適用することも可能であり、第２の実施の形態に示すようなミラーリングディスク装置２０を備えた構成に適用したものも本発明の一実施例として解される。

次に、図１８のフローチャートと、図１９に示す概念図とを用いて、サーバマシン１０（＃Ａ）を稼動系に設定した後のフィルタドライバ１４（＃Ａ）による処理の流れを説明する。なお、サーバマシン１０（＃Ａ）を稼動系に設定する場合におけるクラスタソフト１２（＃Ａ）による処理の流れ、サーバマシン１０（＃Ｂ）のクラスタソフト１２（＃Ｂ）がハートビート切れを検出し、フェールオーバするときのサーバマシン１０（＃Ｂ）の処理の流れは、第１及び第２の実施の形態と同様である。また、サーバマシン１０（＃Ａ）を稼動系に設定した後の有効期限通知デーモン１６（＃Ａ）による処理については、有効期限をフィルタドライバ１４に通知する代わりに、ジャケットＤＬＬ１８に通知する点のみが異なる。

すなわち、本実施の形態に係るクラスタシステムでは、まず、サーバマシン１０（＃Ａ）のジャケットＤＬＬ１９（＃Ａ）が、例えば図２１に示すクライアント６０のような上位からのＩ／Ｏ入力を待つ（Ｓ１０１）。Ｉ／Ｏ入力が有効期限の通知である場合（Ｓ１０２：Ｙｅｓ）には、ステップＳ１０３に進み、有効期限の通知でない場合（Ｓ１０２：Ｎｏ）には、ステップＳ１０４に進む。

ステップＳ１０３では、通知された有効期限に更新された後に、ステップＳ１１５の処理に進む。

ステップＳ１０４では、ステップＳ１０１でなされたＩ／Ｏ入力がサーバＡ用データ領域３２（＃Ａ）へのｒｅａｄであればステップＳ１０５へ、ｗｒｉｔｅであればステップＳ１０６へ、それ以外であればステップＳ１１３へそれぞれ進む。

そして、ステップＳ１０５ではｒｅａｄが、ステップＳ１０６ではｗｒｉｔｅがそれぞれ実行され、ステップＳ１０７の処理に進む。

ステップＳ１０７では、ジャケットＤＬＬ１８が、プロセスハンドル管理テーブル１８ａを参照し、ｒｅａｄ又はｗｒｉｔｅを実行するアプリケーションが、プロセスハンドル管理テーブル１８ａに書き込まれたアプリケーション（クラスタソフト１２によって管理されたアプリケーション）である場合にはステップＳ１０８の処理に進み、そうでない場合にはステップＳ１１１の処理に進む。

ステップＳ１０８では、Ｉ／Ｏが部分的に又は全部が成功した場合にはステップＳ１０９の処理に進み、そうでない場合にはステップＳ１１１の処理に進む。

ステップＳ１０９では、現在の時間が取得される。そして、ステップＳ１１０では、有効期限通知デーモン１６（＃Ａ）から有効期限が通知され、ステップＳ１０９で取得した現在の時間が、有効期限内であるか否かが判定される。そして、有効期限内である場合には、Ｉ／Ｏの処理結果がそのまま上位へ返され（Ｓ１１１）た後に、ステップＳ１１５の処理に進む。

一方、ステップＳ１１０において有効期限を過ぎていると判定された場合には、ジャケットＤＬＬ１８が、Ｉ／Ｏ処理失敗のエラーを上位へ返した（Ｓ１１２）後に、ステップＳ１１５の処理に進む。

ステップＳ１１３では、Ｉ／Ｏ処理用ＤＬＬ１９（＃Ａ）からディスクドライバ１５（＃Ａ）に処理がそのまま渡され、ステップＳ１１４において、ディスクドライバ１５（＃Ａ）からの返り値がそのまま上位に返された後に、ステップＳ１１５の処理に進む。

そして、ステップＳ１１５では、ＯＳが終了するのであれば処理が終了し、そうでなければステップＳ１０１の処理に戻る。

上述したように、本実施の形態に係るクラスタシステムにおいては、上記のような作用により、Ｉ／Ｏ処理結果を上位へ返す場合、有効期限を使用した判定処理を無条件に行うのではなく、クラスタソフト１２の管理下にあるアプリケーションのＩ／Ｏに限り行うことができ、クラスタソフト１２の管理下にないアプリケーションとディスクデータとを共有することにより、フェールオーバが発生した場合であっても、ディスクＩ／Ｏの性能劣化を抑えながら、トランザクションの整合を図ることが可能となる。

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

第１の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図。 共有ディスク装置の詳細構成例を示す概念図。 現在時刻を取得する手段の例を示す図。 第１の実施の形態に係るクラスタシステムにおいて、サーバマシンを稼動系に設定する場合におけるクラスタソフトによる処理の流れを示すフローチャート。 第１の実施の形態に係るクラスタシステムにおいて、サーバマシンを稼動系に設定した後のフィルタドライバによる処理の流れを示すフローチャート。 第１の実施の形態に係るクラスタシステムにおいて、フィルタドライバによる処理の流れを示す概念図。 第１の実施の形態に係るクラスタシステムにおいて、サーバマシンを稼動系に設定した後の有効期限通知デーモンによる処理の流れを示すフローチャート。 第１の実施の形態に係るクラスタシステムにおいて、ハートビート切れを検出し、フェールオーバするときのサーバマシンの処理の流れを示すフローチャート。 第１の実施の形態に係るクラスタシステムにおいて、フェールオーバ時におけるサーバマシンによる処理の流れを示す概念図。 第２の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図。 第２の実施の形態に係るクラスタシステムにおいて、サーバマシンを稼動系に設定する場合におけるクラスタソフトによる処理の流れを示すフローチャート。 第２の実施の形態に係るクラスタシステムにおいて、サーバマシンを稼動系に設定した後のフィルタドライバによる処理の流れを示すフローチャート。 第２の実施の形態に係るクラスタシステムにおいて、フィルタドライバによる処理の流れを示す概念図。 第２の実施の形態に係るクラスタシステムにおいて、ハートビート切れを検出し、フェールオーバするときのサーバマシンの処理の流れを示すフローチャート。 第２の実施の形態に係るクラスタシステムにおいて、フェールオーバ時におけるサーバマシンによる処理の流れを示す概念図。 第３の実施の形態に係るクラスタシステムの構成例を示す機能ブロック図。 プロセスハンドル管理テーブルの一例を示す図。 第３の実施の形態に係るクラスタシステムにおいて、サーバマシンを稼動系に設定する場合におけるジャケットＤＬＬによる処理の流れを示すフローチャート。 第３の実施の形態に係るクラスタシステムにおいて、ジャケットＤＬＬによる処理の流れを示す概念図。 従来技術のクラスタシステムによるフェールオーバを説明するための概念図。 従来技術のクラスタシステムによるフェールオーバ時に生じるデータ破壊を説明するための概念図（ミラーリングディスク装置使用時）。 従来技術のクラスタシステムによるフェールオーバ時に生じるデータ破壊を説明するための概念図（共有ディスク装置使用時）。 従来技術のクラスタシステムの改良構成例とそれによる処理の流れを示す図（共有ディスク装置使用時）。 従来技術のクラスタシステムの改良構成例とそれによる処理の流れを示す図（ミラーリングディスク装置）。

符号の説明

ａ…ハートビート、ｂ…フェールオーバ、１０…サーバマシン、１１…アプリケーション、１２…クラスタソフト、１３…データベースサーバ、１４…フィルタドライバ、１５…ディスクドライバ、１６…有効期限通知デーモン、１７…ミラーリングデーモン、１８…ジャケットＤＬＬ、１８ａ…プロセスハンドル管理テーブル、１９…Ｉ／Ｏ処理用ＤＬＬ、２０…ミラーリングディスク装置、３１…共有ディスク装置、３２…サーバＡ用データ領域、３２…サーバＢ用データ領域、３３…共有領域、３３ａ…ディスクアクセス権管理テーブル、３３ｂ…ミラーリングエラー発生有無管理テーブル、５０，５２…通信路、５１…ＦＣケーブル、６０…クライアント、６１…ＤＢクライアント、７０…共通コンピュータ

Claims (3)

1. 複数のサーバマシンと、前記複数のサーバマシンに共有して接続された共有ディスク装置とから構成されたクラスタシステムであって、
   前記複数のサーバマシンは、前記複数のサーバマシン上でそれぞれ動作するアプリケーションと、前記複数のサーバマシン上でそれぞれ動作するクラスタソフトと、前記複数のサーバマシン上でそれぞれ動作するフィルタドライバと、前記複数のサーバマシン上でそれぞれ動作する有効期限通知デーモンとを備え、
   前記共有ディスク装置は、前記各サーバマシンのデータをそれぞれ格納する各サーバ用データ領域と、前記各サーバマシンで共有する共有領域とを備え、
   前記共有領域は、前記各サーバマシンのそれぞれについて、前記共有ディスク装置へのアクセスの許可又は不許可が設定されたアクセス情報を管理するアクセス管理部を備え、
   前記有効期限通知デーモンは、前記アクセス管理部によって管理されているアクセス情報を定期的に参照し、自サーバマシンによるアクセスが許可されているのであれば、現在時間に所定時間を加えた有効期限を設定し、この有効期限を自サーバマシンのフィルタドライバに通知し、
   前記複数のサーバマシンに備えられた各クラスタソフトは、互いに定期的に通信して互いのサーバマシンの生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持ち、
   前記クラスタソフトが稼動系になる際には、このクラスタソフトは、前記アクセス管理部に管理されたアクセス情報を、自サーバマシンのみがアクセスを許可されるように変更し、前記自サーバマシン側から前記自サーバマシンのサーバ用データ領域が見える状態にし、前記自サーバマシンに備えられたアプリケーションを起動させ、
   前記クラスタソフトが稼動系になった後は、前記稼動系のサーバマシンのフィルタドライバは、Ｉ／Ｏ入力を待ち、前記Ｉ／Ｏ入力の処理結果の一部あるいは全てが成功の場合、現在時間を確認し、前記現在時間が、前記有効期限通知デーモンから通知された有効期限内であれば前記処理結果を前記Ｉ／Ｏ入力側へ返し、有効期限内でなければ前記Ｉ／Ｏ入力側へエラーを返し、
   前記待機系のサーバマシンのクラスタソフトが、前記稼動系のサーバマシンが生存していないと判定した場合には、前記待機系のサーバマシンのクラスタソフトは、前記アクセス管理部に管理されたアクセス情報を、自サーバマシンのみがアクセスを許可されるように変更し、所定時間待機した後に、前記自サーバマシン側から前記自サーバマシンのサーバ用データ領域が見える状態にするとともに、前記自サーバマシンに備えられたアプリケーションを起動させる
   ようにしたクラスタシステム。
2. 複数のサーバマシンと、前記複数のサーバマシンにそれぞれ接続された複数のミラーリングディスク装置と、前記複数のサーバマシンに共有して接続された共有装置とから構成されたクラスタシステムであって、
   前記複数のサーバマシンは、前記複数のサーバマシン上でそれぞれ動作するアプリケーションと、前記複数のサーバマシン上でそれぞれ動作するクラスタソフトと、前記複数のサーバマシン上でそれぞれ動作するフィルタドライバと、前記複数のサーバマシン上でそれぞれ動作する有効期限通知デーモンとを備え、
   前記共有装置は、前記各サーバマシンのそれぞれについて、前記各ミラーリングディスク装置へのアクセスの許可又は不許可が設定されたアクセス情報を管理するアクセス管理部と、前記各サーバマシンのそれぞれについて、前記各ミラーリングディスク装置へのミラーリングエラーの発生の有無を示すミラーリングエラー情報を管理するミラーリングエラー発生有無管理部とを備え、
   前記有効期限通知デーモンは、前記アクセス管理部によって管理されているアクセス情報を定期的に参照し、自サーバマシンによるアクセスが許可されているのであれば、現在時間に所定時間を加えた有効期限を設定し、この有効期限を自サーバマシンのフィルタドライバに通知し、
   前記複数のサーバマシンに備えられた各クラスタソフトは、互いに定期的に通信して互いのサーバマシンの生存状態を確認し合うと共に、それぞれ稼動系と待機系との２種類の状態を持ち、
   前記クラスタソフトが稼動系になる際には、このクラスタソフトは、前記アクセス管理部に管理されたアクセス情報を、自サーバマシンのみがアクセスを許可されるように変更し、前記自サーバマシン側から、前記自サーバマシンのミラーリングディスク装置が見える状態にし、自サーバマシンに備えられたアプリケーションを起動させ、
   前記クラスタソフトが稼動系になった後は、前記稼動系のサーバマシンのフィルタドライバは、Ｉ／Ｏ入力を待ち、前記Ｉ／Ｏ入力の処理を、前記各ミラーリングディスク装置に対して行わせ、前記各ミラーリングディスク装置による処理結果が同一の場合には、現在時間を確認し、前記現在時間が、前記有効期限通知デーモンから通知された有効期限内であれば前記処理結果を前記Ｉ／Ｏ入力側へ返し、有効期限内でなければ前記Ｉ／Ｏ入力側へエラーを返し、前記処理結果が同一では無い場合には、前記ミラーリングエラー発生有無管理部に管理されたミラーリングエラー情報を、自サーバマシンについてミラーリングエラーが発生しているように変更し、
   前記待機系のサーバマシンのクラスタソフトが、前記稼動系のサーバマシンが生存していないと判定した場合には、前記待機系のサーバマシンのクラスタソフトは、前記アクセス管理部に管理されたアクセス情報を、自サーバマシンのみがアクセスを許可されるように変更し、所定時間待機した後に、前記ミラーリングエラー発生有無管理部に管理されたミラーリングエラー情報が、自サーバマシンについてミラーリングエラーが発生しているように設定されていないのであれば、前記自サーバマシン側から、前記自サーバマシンのミラーリングディスク装置が見える状態にするとともに、前記自サーバマシンに備えられたアプリケーションを起動させる
   ようにしたクラスタシステム。
3. 請求項１又は請求項２に記載のクラスタシステムにおいて、
   前記現在時間が、前記有効期限通知デーモンから通知された有効期限内であれば前記処理結果を前記Ｉ／Ｏ入力側へ返し、有効期限内でなければ前記Ｉ／Ｏ入力側へエラーを返す代わりに、前記クラスタソフトの管理下にあるアプリケーションによってなされた処理結果についてのみ、現在時間を確認し、前記現在時間が、前記有効期限通知デーモンから通知された有効期限内であれば前記処理結果を前記Ｉ／Ｏ入力側へ返し、有効期限内でなければ前記Ｉ／Ｏ入力側へエラーを返すようにしたクラスタシステム。

Images