計算機システム
【課題】複数のサーバ間でフェイルオーバが発生した場合に当該複数のサーバから共有ディスクにアクセスされることによってデータが破壊されることを防止することができる。
【解決手段】ディスクドライバ２３は、サーバ２０がマスター領域１１にライトアクセスする際に、当該ライトアクセス先となる領域を第１のビットマップテーブルに登録する。クラスタソフト３２は、所定のパケットの断絶が検出された場合に、アクセス権管理テーブル１２においてサーバ３０にアクセス権を設定する。クラスタソフト３２は、第１のビットマップテーブルに登録されている領域に格納されているデータをログ領域にコピーする。ディスクドライバ３３は、サーバ３０にアクセス権が設定された後に、マスター領域１１にアクセスする際に、当該アクセス先となる領域が第１のビットマップテーブルに登録されている場合には、ログ領域に対してアクセスする。
【解決手段】ディスクドライバ２３は、サーバ２０がマスター領域１１にライトアクセスする際に、当該ライトアクセス先となる領域を第１のビットマップテーブルに登録する。クラスタソフト３２は、所定のパケットの断絶が検出された場合に、アクセス権管理テーブル１２においてサーバ３０にアクセス権を設定する。クラスタソフト３２は、第１のビットマップテーブルに登録されている領域に格納されているデータをログ領域にコピーする。ディスクドライバ３３は、サーバ３０にアクセス権が設定された後に、マスター領域１１にアクセスする際に、当該アクセス先となる領域が第１のビットマップテーブルに登録されている場合には、ログ領域に対してアクセスする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の計算機間でフェイルオーバが実行される計算機システムに関する。
【背景技術】
【０００２】
近年、例えば複数の計算機（サーバ）及び少なくとも１つ以上のストレージ装置から構成されるクラスタシステム（計算機システム）が知られている。クラスタシステムを構成する複数のサーバには、例えば稼動系サーバ及び待機系サーバが含まれる。
【０００３】
このようなクラスタシステムでは、稼動系サーバ及び待機系サーバ間には通信路が確立されており、互いに通信可能である。
【０００４】
クラスタシステムにおいては、まず、稼動系サーバで例えばアプリケーションが開始される。稼動系サーバでアプリケーションが実行されている際、当該稼動系サーバと待機系サーバとの間（通信路経由）で、所定のパケット（以下、ハートビートと表記）を交換し続ける。
【０００５】
これにより、例えば稼動系サーバからハートビートが送信されなくなると、待機系サーバではハートビートの断絶が検出される。この場合、例えば稼動系サーバが故障等の発生によりダウンしたものとして、待機系サーバでは、当該稼動系サーバで実行されていたアプリケーションを起動する。これにより、アプリケーション処理を継続させることができる（フェイルオーバ）。
【０００６】
ここで、稼動系サーバからのハートビートが断絶する理由には、上記した稼動系サーバの故障以外に、例えば稼動系サーバ及び待機系サーバ間の通信路の障害または稼動系サーバでＣＰＵ高負荷による一時的なスローダウンの発生等がある。
【０００７】
上記したように稼動系サーバが故障等によりダウンすることによってハートビートが断絶した場合には、単純に待機系サーバにフェイルオーバすればよい。しかしながら、例えば稼動系サーバ及び待機系サーバ間の通信路の障害または稼動系サーバでＣＰＵ高負荷による一時的なスローダウンの発生等によってハートビートが断絶した場合には、稼動系サーバでは処理が継続されるため、単にフェイルオーバすると問題がある。
【０００８】
例えば複数台のサーバ（稼動系サーバ及び待機系サーバ）が同一の共有ディスクに接続された状態でクラスタ構成を組む場合において、上記した稼動系サーバ及び待機系サーバ間の通信路の障害または稼動系サーバでＣＰＵ高負荷による一時的なスローダウンの発生が原因でハートビートの断絶が検出され、フェイルオーバが実行された場合を想定する。
【０００９】
この場合、上記したように稼動系サーバ及び待機系サーバの両方が稼動している状態となるため、例えば稼動系サーバ及び待機系サーバの両方が共有ディスク内の同一データ領域に書き込みを行う可能性がある。これにより、例えば共有ディスク内のデータの整合性が失われ、当該データが破壊されることがある。
【００１０】
そこで、上記したようなデータ破壊を防ぐための技術として、例えばＳＣＳＩ（Small Computer System Interface）仕様として定義されているリザーブ排他機能を使用する技術が知られている。この技術によれば、例えば１つのＬＵ（Logical Unit）につきＩ／Ｏ（readまたはwrite）を発行可能なサーバを１つに絞る手法が利用される。すなわち、待機系サーバにフェイルオーバする際、待機系サーバが共有ディスク内の対象ＬＵをリザーブし、稼動系サーバがそれ以上対象ＬＵに書き込みを行うのを防いでからアプリケーションが起動される。
【００１１】
このような技術に関連して、クラスタシステムの各ノード間の通信路の故障によってスプリットブレインの状態が発生した場合において、外部記憶装置内の排他制御を使用して、処理要求が競合しないように共有のデータ資源を保護する技術（以下、先行技術１と表記）が開示されている（例えば、特許文献１を参照）。この先行技術１によれば、例えばストレージのファームウェア内の排他制御部を用い、クラスタシステムの調停機構と組み合わせてＩ／Ｏアクセス制御を実施している。
【００１２】
また、共有ディスク内に例えばＱＵＯＲＵＭと呼ばれる特殊なＬＵを用意してアプリケーションデータのマスター領域へのコミット権を管理し、ソフトウェア排他を行う技術（以下、先行技術２と表記）がある。この先行技術２によれば、例えばディスク上にサーバ毎のキャッシュ領域を用意してデータの書き込みを２段階とし、フェイルオーバ後に元稼動系が２段階目の書き込みを行う先が小領域に限定されることを利用して、フェイルオーバ後にマスター領域から当該小領域が外される、つまり、代替の保存先領域が設けられる。
【特許文献１】特開２００５−２５２８９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、上記した先行技術１においてはＳＣＳＩリザーブ排他という共有ディスク装置の実装に依存した機能を利用するため、例えばリザーブ排他が可能か否かは共有ディスク装置やそのマルチパスドライバの実装に依存することになる。つまり、例えば新しい共有ディスク装置やそのマルチパスドライバに対応するには毎回検証が必要となる。
【００１４】
また、上記した先行技術１では、例えば共有ディスク装置やそのマルチパスドライバによって、細かな制限事項が付加されている場合がある。例えばある共有ディスク装置では、ディスクＩ／Ｏの物理的なパスが多重化されている環境で当該パスに障害（片パス障害）が起きると、共有ディスクのリザーブが維持されない状態に陥る。この場合には、共有ディスクにおいて例えば他のサーバ（元稼動系サーバ）のアクセスを排他することはできない。
【００１５】
また、先行技術１においては、共有ディスクをリザーブする際には上記したＬＵ単位でしかリザーブすることができず、例えばパーティション単位または当該パーティション群からなる論理ボリューム単位で運用することはできない。
【００１６】
更に、先行技術１においては、例えば同一バスに接続された別のマシンをリブートするとバスリセットによりリザーブが外れる場合がある。また、多サービス構成でスプリットブレインすると、リザーブを奪うためのバスリセットが飛び交うため排他しきれない場合がある。このように、先行技術１では、リザーブを確実に維持することができないため、他のサーバからのアクセスを排他することができない時間が生じる。
【００１７】
上記した先行技術２においては、アプリケーションのデータは当該先行技術２の仕組みに対応したドライバ経由でないとアクセスすることはできない。つまり、データがストレージ間でバックアップされた場合に当該バックアップ先でデータを読み出すには、例えばキャッシュ領域のデータをマスター領域へ反映する機能を有するような別途用意した特殊なコマンドが必要となる。また、先行技術２の仕組みに対応したフィルタドライバをインストールする必要もある。
【００１８】
また、先行技術２では、例えばクラスタシステムを構成するサーバが３台以上の場合、フェイルオーバを繰り返すとマスターデータが様々な領域に分散するため、更に複雑な実装が必要となる。
【００１９】
そこで、本発明の目的は、複数のサーバ間でフェイルオーバが発生した場合に、当該複数のサーバから共有ディスクにアクセスされることによってデータが破壊されることを防止する計算機システムを提供することにある。
【課題を解決するための手段】
【００２０】
本発明の１つの態様によれば、第１の計算機と、当該第１の計算機と接続され、当該第１の計算機から定期的に所定のパケットを受信する第２の計算機と、前記第１の計算機及び前記第２の計算機と接続されている記憶装置とを備える計算機システムにおいて、前記記憶装置は、前記第１の計算機及び第２の計算機からアクセスされる第１の領域と、前記第１の領域に対するアクセスの許可を示すアクセス権が前記第１の計算機に設定されているアクセス権管理テーブルと、前記第１の領域とは異なる第２の領域と、前記第１の領域に対して前記第１の計算機によってライトアクセスされた際に、当該ライトアクセス先となる領域を登録するための第１の計算機用テーブルとを含み、前記第１の計算機は、当該第１の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、当該ライトアクセス先となる領域を前記記憶装置に含まれる第１の計算機用テーブルに登録するアクセス先登録手段を含み、前記第２の計算機は、前記第１の計算機からの前記所定のパケットの断絶が検出された場合に、前記記憶装置に含まれるアクセス権管理テーブルにおいて前記第２の計算機に前記アクセス権を設定する設定手段と、前記第１の計算機用テーブルに登録されている領域に格納されているデータを、前記第２の領域にコピーするコピー処理手段と、前記第２の計算機にアクセス権が設定された後に、前記記憶装置に含まれる第１の領域にアクセスする際に、当該アクセス先となる領域が前記第１の計算機用テーブルに登録されているかを判定する判定手段と、前記第１の計算機用テーブルに登録されていると判定された場合、前記第１の計算機用テーブルに登録されている領域に格納されているデータがコピーされた前記第２の領域に対してアクセスするアクセス手段とを含むことを特徴とする計算機システムが提供される。
【発明の効果】
【００２１】
本発明によれば、複数のサーバ間でフェイルオーバが発生した場合に、当該複数のサーバから共有ディスクにアクセスされることによってデータが破壊されることを防止することが可能となる。
【発明を実施するための最良の形態】
【００２２】
以下、図面を参照して、本発明の各実施形態について説明する。
【００２３】
［第１の実施形態］
図１は、本発明の第１の実施形態に係るクラスタシステム（計算機システム）の機能構成を示すブロック図である。
【００２４】
図１に示すように、本実施形態に係るクラスタシステムは、複数のサーバ（計算機）及び共有ディスク１０を備える。複数のサーバは、サーバ（第１の計算機）２０及びサーバ（第２の計算機）３０を含む。
【００２５】
また、共有ディスク１０及びサーバ２０は、例えばＦＣ（Fibre Channel）ケーブルで接続されている。同様に、共有ディスク１０及びサーバ３０は、ＦＣケーブルで接続されている。サーバ２０及びサーバ３０は、例えば２本の通信路を介して通信可能に接続されている。以下、サーバ２０は稼動系サーバ、サーバ３０は待機系サーバであるものとして説明する。
【００２６】
共有ディスク１０は、マスター領域（第１の領域）１１及びＱＵＯＲＵＭ領域を含む。マスター領域１１は、上記したサーバ２０及びサーバ３０によってアクセスされる共有領域である。ここでは、マスター領域１１は、共有ディスク１０が有する論理ユニット（ＬＵ：Logical Unit）、例えばＬＵ１に含まれるものとする。
【００２７】
ＱＵＯＲＵＭ領域には、アクセス権管理テーブル１２が含まれる。このアクセス権管理テーブル１２には、クラスタシステムを構成するサーバ２０及びサーバ３０のそれぞれについて、共有ディスク１０のマスター領域１１へのアクセスの許可または不許可が設定される。図１に示すように、アクセス権管理テーブル１２において例えばＬＵ１に対応付けてサーバ２０に「○」、サーバ３０に「×」が設定されている場合には、サーバ２０のマスター領域１１に対するアクセスが許可され、サーバ３０のマスター領域１１に対するアクセスは許可されていないことを示す。つまり、図１に示す例では、アクセス権管理テーブル１２には、マスター領域１１に対するアクセスの許可を示すアクセス権がサーバ２０に設定されている。
【００２８】
また、ＱＵＯＲＵＭ領域には、サーバ２０用のデータ領域（以下、サーバ２０用領域と表記）１３及びサーバ３０用のデータ領域（以下、サーバ３０用データ領域と表記）１４が含まれる。
【００２９】
本実施形態においては、上記したマスター領域１１及びＱＵＯＲＵＭ領域を異なるＬＵに分けてもよいし、異なるパーティションに分けてもよい。
【００３０】
サーバ２０は、当該サーバ２０上で動作するアプリケーション２１、クラスタソフト２２、ディスクドライバ２３及びアクセス権ポーリングデーモン２４を備える。
【００３１】
稼動系サーバであるサーバ２０では、アプリケーション２１が実行される。このようにサーバ２０でアプリケーション２１が実行されている間には、稼動系サーバであるサーバ２０に備えられるクラスタソフト２２及び待機系サーバであるサーバ３０に備えられるクラスタソフト３２の間で通信路を経由してハートビートと呼ばれる所定のパケットを定期的に交換し続け、互いの生存を通知し合う。
【００３２】
ディスクドライバ２３は、上位（例えば、アプリケーション２１）からのＩ／Ｏ（リードまたはライト）要求に基づいて、共有ディスク１０に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ２３は、上記した共有ディスク１０に含まれるアクセス権管理テーブル１２を参照して処理を実行する。
【００３３】
また、ディスクドライバ２３は、例えば共有ディスク１０に含まれるマスター領域１１に対してライト処理（ライトアクセス）を実行する際に、当該ライト（アクセス）先となる領域に対応するブロック（ライト先ブロック）をサーバ２０用のビットマップ（bitmap）テーブル（第１の計算機用テーブル）に登録する。つまり、ディスクドライバ２３は、サーバ２０用のビットマップテーブル（以下、第１のビットマップテーブルと表記）のライト先ブロックにｂｉｔを立てることによって、ライト先ブロックを登録する。第１のビットマップテーブルにおいては、マスター領域１１に含まれる領域の各々に対応する複数のブロックを登録することができ、例えば１ブロックが１ＭＢに対応する。以下に説明する第１のビットマップテーブル以外のビットマップテーブルについても同様である。
【００３４】
この第１のビットマップテーブルは、例えばサーバ２０に備えられるメモリ（図示せず）にその領域が確保される。また、第１のビットマップテーブルは、上記した共有ディスク１０のサーバ２０用領域に保持される。
【００３５】
アクセス権ポーリングデーモン２４は、共有ディスク１０に含まれるアクセス権管理テーブル１２を定期的（例えば、３０秒毎）に参照する。アクセス権ポーリングデーモン２４は、サーバ２０によるアクセスが許可されている（つまり、サーバ２０にアクセス権が設定されている）場合、例えば現在時間に予め定められた時間（例えば、６０秒）を加えた有効期限（マスター領域１１に対するアクセス権の有効期限）を設定し、この有効期限をサーバ２０のディスクドライバ２３に通知する。
【００３６】
サーバ３０は、当該サーバ３０上で動作するアプリケーション３１、クラスタソフト３２、ディスクドライバ３３及びアクセス権ポーリングデーモン３４を備える。
【００３７】
上記したように稼動系サーバであるサーバ２０に備えられるクラスタソフト２２及び待機系サーバであるサーバ３０に備えられるクラスタソフト３２の間では通信路を経由してハートビートと呼ばれる所定のパケットを交換し続け、互いの生存を通知し合う。
【００３８】
ここで、例えば待機系サーバであるサーバ３０のクラスタソフト３２によって稼動系サーバであるサーバ２０のクラスタソフト２２からのハートビートの断絶（クラスタソフト２２からのハートビートが受信されなくなること）が検出された場合を想定する。この場合、サーバ３０上ではサーバ２０で起動されていたアプリケーション２１の処理を継続するためにアプリケーション３１が起動される。これにより、サーバ３０でフェイルオーバが実行される。
【００３９】
なお、ハートビートが断絶する理由としては、例えば稼動系サーバの故障（ダウン）、サーバ２０及びサーバ３０間の通信路の障害またはサーバ２０でＣＰＵ高負荷等による一時的なスローダウンの発生等がある。
【００４０】
クラスタソフト３２は、クラスタソフト２２からのハートビートの断絶が検出された場合、共有ディスク１０に含まれるアクセス権管理テーブル１２に対してマスター領域１１に対するアクセス権をサーバ３０に変更（設定）する。
【００４１】
クラスタソフト３２は、上記した第１のビットマップテーブルに登録されているブロックに対応するマスター領域１１（に含まれる領域）に格納されているデータを、当該マスター領域１１とは異なる共有ディスク１０上の別の領域であるログ領域（第２の領域）にコピーする。
【００４２】
クラスタソフト３２は、サーバ２０のマスター領域１１に対するアクセス権の有効期限が確実に切れる時刻まで待機し、当該時刻後にアプリケーション３１を起動する。
【００４３】
また、クラスタソフト３２は、上記したフェイルオーバの完了後、一定時間が経過した場合に、上記したログ領域に格納されているデータをマスター領域１１の対応する領域にコピーする。クラスタソフト３２は、このコピー処理が完了すると、ログ領域を削除する。
【００４４】
ディスクドライバ３３は、上位（例えば、アプリケーション３１）からのＩ／Ｏ要求に基づいて、共有ディスク１０に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ３３は、Ｉ／Ｏ要求が上記した第１のビットマップテーブルに登録されているブロック（に対応する領域）に対する要求である場合には、上記したログ領域に対して当該要求に応じた処理（アクセス）を実行する。
【００４５】
また、ディスクドライバ３３は、上記したディスクドライバ２３と同様に、例えば共有ディスク１０に含まれるマスター領域１１に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック（ライト先ブロック）をサーバ３０用のビットマップテーブル（第２の計算機用テーブル）に登録する。このサーバ３０用のビットマップテーブル（以下、第２のビットマップテーブル）は、例えばサーバ３０に備えられるメモリ（図示せず）上にその領域が確保される。また、第２のビットマップテーブルは、上記した共有ディスク１０のサーバ３０用領域１４に保持される。
【００４６】
アクセス権ポーリングデーモン３４は、上記したサーバ２０のアクセス権ポーリングデーモン２４と同様であるのでその詳しい説明は省略する。
【００４７】
次に、図２を参照して、上記したフェイルオーバについて説明する。ここでは、サーバ２０は稼動系サーバ、サーバ３０は待機系サーバとして動作しているものとする。
【００４８】
ここで、例えば稼動系サーバであるサーバ２０でＣＰＵ高負荷による一時的なスローダウンが発生した場合を想定する。
【００４９】
この場合、待機系サーバであるサーバ３０（のクラスタソフト３３）は稼動系サーバ２０（のクラスタソフト２３）からのハートビートの断絶を検出する（ステップＳ１）。
【００５０】
次に、サーバ３０のクラスタソフト３３は、共有ディスク１０に含まれるアクセス権管理テーブル１２に対してマスター領域１１に対するアクセス権をサーバ３０に変更する（ステップＳ２）。
【００５１】
このとき、サーバ２０のアクセス権ポーリングデーモン２４は、アクセス権管理テーブル１２においてアクセス権がサーバ２０からサーバ３０に変更されたため、サーバ２０のマスター領域１１に対するアクセス権の有効期限を更新しない。
【００５２】
上記したステップＳ２の処理が実行されると、サーバ３０のクラスタソフト３３は、サーバ２０のアクセス権ポーリングデーモン２４によって設定されたアクセス権の有効期限切れまで待機する。このアクセス権の有効期限が切れた後、サーバ３０のクラスタソフト３３はアプリケーション３１を起動し、サーバ３０によるマスター領域１１に対するアクセスが開始される。
【００５３】
ここで、図２を参照して、フェイルオーバ前後にサーバ２０においてなされるライト要求（ライト命令）について説明する。このライト要求は、例えばサーバ２０と接続されたクライアント端末５０からの要求に基づいて、サーバ２０のアプリケーション２１からディスクドライバ２３に送信される。
【００５４】
ディスクドライバ２３は、上記したサーバ２０のマスター領域１１に対するアクセス権の有効期限（サーバ２０の有効期限）内においては、アプリケーション２１から送信されるライト要求を含むＩ／Ｏ要求を共有ディスク１０に送信する。また、ディスクドライバ２３は、サーバ２０の有効期限内においては、例えば共有ディスク１０からのＩ／Ｏ要求に対する応答をアプリケーション２１に返す。つまり、ディスクドライバ２３は、サーバ２０の有効期限内においては、Ｉ／Ｏ要求及び応答を通過させる機能を有する。
【００５５】
一方、サーバ２０の有効期限外においては、アプリケーション２１からＩ／Ｏ要求を受けた場合及び共有ディスク１０から応答を受けた場合にはエラーが当該アプリケーション２１に対して返される（エラーリターン）。
【００５６】
ここで、図２では、例えば上記したサーバ２０の有効期限が切れた時点でのアプリケーション２１によって送信されたＩ／Ｏ要求（ここでは、ライト要求）の状態を表す。ライト要求の状態は、図２に示すようにライト要求２１１〜２１４に大別される。
【００５７】
例えばライト要求２１１は、サーバ２０の有効期限が切れた時点で既に正常に処理されているライト要求である。
【００５８】
ライト要求２１２は、サーバ２０の有効期限が切れた時点で既にマスター領域１１にライト処理が実行されているが、共有ディスク１０からの応答がディスクドライバ２３を通過していないのでサーバ２０の有効期限切れによりエラーリターンとなるライト要求である。
【００５９】
ライト要求２１３は、サーバ２０の有効期限が切れた時点でマスター領域１１にはライト処理が実行されていないが、ディスクドライバ２３を通過している。よって、ライト要求２１３は、サーバ２０の有効期限が切れた後にマスター領域１１にライト処理が実行されるが、上記したライト要求２１２と同様に共有ディスク１０からの応答がディスクドライバ２３を通過していないのでサーバ２０の有効期限切れによりエラーリターンとなるライト要求である。
【００６０】
ライト要求２１４は、サーバ２０の有効期限が切れた時点で当該ライト要求２１４がディスクドライバ２３を通過していないので、マスター領域１１に対してライト処理が実行されることなくエラーリターンとなるライト要求である。
【００６１】
上記したようにすることでフェイルオーバを境に元稼動系サーバ（サーバ２０）からのライト要求は必ずエラーとなる仕組みを実現できる。この仕組みは、上記したようにサーバ２０がスローダウンしていたとしても実現される。
【００６２】
ところで、上記したライト要求２１３においては、フェイルオーバ後に当該ライト要求２１３に応じたライト処理が実行されるため、元稼動系サーバであるサーバ２０と元待機系（現稼動系）サーバであるサーバ３０との両系書き込みによるデータ破壊のリスクがある。
【００６３】
図２に示すライト要求２１３の状態でサーバ２０が上記したようにＣＰＵ高負荷による一時的なスローダウンが発生した場合を想定する。この場合、例えばライト要求２１３によるライト処理の対象となる領域と同一の領域に対してサーバ３０によるライト処理がされた後にサーバ２０のスローダウンが回復した場合には、当該サーバ３０によるライト処理された領域がライト要求２１３によって上塗り（上書き）されることになる。これにより、データ破壊が生じる場合がある。
【００６４】
また、例えばライト要求２１３によるライト処理の対象となる領域と同一の領域に対してサーバ３０によるリード処理がされた場合であっても、その後にライト要求２１３によるライト処理が実行された場合には、サーバ３０が再度リード処理を同一の領域に対して実行したにもかかわらずリード結果の不一致という事態が生じる場合がある。
【００６５】
そこで、本実施形態に係るクラスタシステムにおいては、例えばライト要求２１３により上塗りされ得る領域（小領域）とそれ以外の領域を上記した別途設けられたビットマップテーブル（例えば、第１のビットマップテーブル）を用いて常に区分する。これにより、本実施形態においては、フェイルオーバ発生後から安定状態に落ち着くまでの間、上記した小領域の複製を持つことで、スプリットブレイン時にディスクデータの破壊を防ぎつつフェイルオーバさせる。
【００６６】
次に、図３及び図４を参照して、図１に示すクラスタシステムの仕組みの概略について説明する。
【００６７】
まず、図３に示すフェイルオーバ前の安定期（通常運転期）においては、稼動系サーバであるサーバ２０においてアプリケーション２１によって送信されるＩ／Ｏ要求に応じてライト処理またはリード処理がマスター領域１１に対して実行される。
【００６８】
ここで、アプリケーション２１によって送信されるＩ／Ｏ要求がライト要求である場合には、当該ライト要求によってライト処理される領域（ライト先ブロック）がサーバ２０用のビットマップテーブル（第１のビットマップテーブル）１３１に登録される。なお、この第１のビットマップテーブル１３１は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている。
【００６９】
図４に示すように、安定期（通常運転期）においては、マスター領域１１（図４では、領域Ｂと表記）には、稼動系サーバであるサーバ２０がライトし得る領域Ｂ１及び当該サーバ２０がライトしない領域Ｂ２が含まれるが、第１のビットマップテーブル１３１には稼動系サーバであるサーバ２０がライトし得る領域Ｂ１が登録される。
【００７０】
次に、例えばサーバ２０からのハートビートの断絶が検出されることにより、待機系サーバであるサーバ３０がフェイルオーバを実行した場合を想定する。
【００７１】
この場合、図３に示すようにフェイルオーバ直後においては、共有ディスク１０のサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１がサーバ３０用領域１４にコピーされる。
【００７２】
また、コピーされた第１のビットマップテーブルに登録されているブロック（に対応するマスター領域１１の領域）に格納されているデータが当該マスター領域１１とは異なる共有ディスク１０上の別領域であるログ領域にコピーされる。なお、ログ領域は、例えばサーバ３０用領域１４に確保される。
【００７３】
フェイルオーバ直後においては、元稼動系サーバであるサーバ２０において起動されていたアプリケーション２１の処理を継続するために起動された現稼動系サーバであるサーバ３０のアプリケーション３１によって送信されるＩ／Ｏ要求に応じてライト処理またはリード処理がマスター領域１１に対して実行される。
【００７４】
ここで、アプリケーション３１によって送信されるＩ／Ｏ要求がライト要求である場合には、当該ライト要求に応じてライト先ブロックがサーバ３０用のビットマップテーブル（第２のビットマップテーブル）１４１に登録される。なお、この第２のビットマップテーブル１４１は、共有ディスク１０に含まれるサーバ３０用領域１４に保持されている。
【００７５】
また、アプリケーション３１によって送信されるＩ／Ｏ要求が第１のビットマップテーブル１３１に登録されているブロックに対応する領域に対する要求である場合、当該Ｉ／Ｏ要求に応じた処理はログ領域に対して実行される。
【００７６】
図４に示すように、フェイルオーバ直後においては、マスター領域１１には、元稼動系サーバであるサーバ２０のライト要求（例えば、上記した図２におけるライト要求２１３）により上塗りされ得る領域Ａ（小領域）及びそれ以外の領域Ｂが含まれる。領域Ｂには、現稼動系サーバであるサーバ３０がライトし得る領域Ｂ１及び当該サーバ３０がライトしない領域Ｂ２が含まれる。ここで、領域Ａは、上記した図３に示す第１のビットマップテーブル１３１に登録されているブロックに対応する領域である。また、領域Ｂ１は、第２のビットマップテーブル１４１に登録されているブロックに対応する領域である。
【００７７】
また、マスター領域１１とは別領域である領域Ｌは、上記した領域Ａ（に格納されているデータ）がコピーされたログ領域である。この領域Ｌには、領域Ａに格納されているデータがコピーされる。
【００７８】
次に、フェイルオーバの後、一定時間が経過した場合を想定する。この場合には、共有ディスク１０、サーバ２０及びサーバ３０から構成されるクラスタシステムは安定期（片肺運転）となる。この一定時間とは、予め設定された例えば元稼動系サーバであるサーバ２０におけるＣＰＵ高負荷による一時的なスローダウンが回復するために十分な時間である。
【００７９】
図３に示す安定期（片肺運転）においては、上記したログ領域に格納されているデータが当該ログ領域に対応するマスター領域１１の領域（第１のビットマップテーブル１３１に登録されているブロックに対応する領域Ａ）にコピーされる。
【００８０】
また、サーバ３０用領域１４に保持されている第１のビットマップテーブル１３１が当該サーバ３０用領域から削除される。
【００８１】
また、安定期（片肺運転）時では、上記したフェイルオーバ直後と同様に、サーバ３０のアプリケーション３１によって送信されるＩ／Ｏ要求がライト要求である場合には、当該ライト要求に応じてライト先ブロックがサーバ３０用のビットマップテーブル（第２のビットマップテーブル）１４１に登録される。
【００８２】
上記したように、本実施形態においては、フェイルオーバ直後から安定期（片肺運転）までは元稼動系サーバ（サーバ２０）により上塗りされ得る領域Ａ、マスター領域１１における当該領域Ａ以外の領域Ｂ及びマスター領域１１とは別領域である領域Ｌ（ログ領域）の３つに分割されて管理される。
【００８３】
次に、図５のフローチャートを参照して、例えばサーバ２０を稼動系サーバに移行する際の当該サーバ２０のクラスタソフト２２の処理手順について説明する。
【００８４】
ここでは、初期状態として、サーバ２０及びサーバ３０間ではクラスタソフト同士（クラスタソフト２２及び３２）がハートビートを交換し、互いの生存が確認できているものとする。また、サーバ２０及びサーバ３０共に、ＱＵＯＲＵＭ用領域とマスター領域１１が上位層から見えない（ディスクドライバ２３及び３３がフェンスオフ）状態であり、アプリケーション（アプリケーション２１及び３１）は起動されていないものとする。
【００８５】
まず、サーバ２０のクラスタソフト２２は、例えばユーザの操作に応じてサーバ２０を稼動系サーバにする旨の通知をクライアント端末から受け取る（ステップＳ１１）。
【００８６】
次に、クラスタソフト２２は、共有ディスク１０に含まれるアクセス権管理テーブル１２を変更する（ステップＳ１２）。この場合、クラスタソフト２２は、アクセス権管理テーブル１２においてマスター領域１１に対するアクセス権をサーバ２０に設定する。
【００８７】
クラスタソフト２２は、サーバ２０のディスクドライバ２３に当該サーバ２０が稼動系サーバとなった旨を通知する（ステップＳ１３）。このとき、ディスクドライバ２３は、上位層からマスター領域１１が見える状態にする。
【００８８】
クラスタソフト２２は、サーバ２０のアプリケーション２１を起動する（ステップＳ１４）。
【００８９】
次に、図６のフローチャートを参照して、サーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３の処理手順について説明する。
【００９０】
まず、ディスクドライバ２３は、上位（アプリケーション２１）からのＩ／Ｏ要求を入力する（ステップＳ２１）。
【００９１】
次に、ディスクドライバ２３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、アクセス権管理テーブル１２にサーバ２０のアクセス権（サーバ２０のマスター領域１１に対するアクセス権）が設定されているか否かを判定する。つまり、ディスクドライバ２３は、サーバ２０にマスター領域１１に対するアクセス権があるか否かを判定する（ステップＳ２２）。
【００９２】
サーバ２０にアクセス権があると判定された場合（ステップＳ２２のＹＥＳ）、ディスクドライバ２３は、入力されたＩ／Ｏ要求がマスター領域１１へのライト要求であるか否かを判定する（ステップＳ２３）。
【００９３】
マスター領域１１へのライト要求であると判定された場合（ステップＳ２３のＹＥＳ）、ディスクドライバ２３は、サーバ２０に備えられるメモリ上に保持されている第１のビットマップテーブルを参照する。ディスクドライバ２３は、ライト要求の対象となる領域に対応するブロック（ライト先ブロック）が第１のビットマップテーブルに登録済みであるか否かを判定する（ステップＳ２４）。
【００９４】
ライト先ブロックが第１のビットマップテーブルに登録済みでないと判定された場合（ステップＳ２４のＮＯ）、ディスクドライバ２３は、当該ライト先ブロックを当該第１のビットマップテーブルに登録する（ステップＳ２５）。この場合、ディスクドライバ２３は、サーバ２０に備えられるメモリ上に保持されている第１のビットマップテーブル及び上記した共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブルにライト先ブロックを登録する。
【００９５】
次に、ディスクドライバ２３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、サーバ２０にマスター領域１１に対するアクセス権があるか否かを判定する（ステップＳ２６）。
【００９６】
サーバ２０にアクセス権があると判定された場合（ステップＳ２６のＹＥＳ）、ディスクドライバ２３は、マスター領域１１へのライト処理を実行する（ステップ２７）。
【００９７】
ディスクドライバ２３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、サーバ２０にアクセス権があるか否かを判定する（ステップＳ２８）。
【００９８】
サーバ２０にアクセス権があると判定された場合（ステップＳ２８のＹＥＳ）、ディスクドライバ２３は、例えば正常にライト処理が実行された旨の処理結果を上位へリターンする（ステップＳ２９）。
【００９９】
一方、上記したステップＳ２２、Ｓ２６及びＳ２８においてサーバ２０にアクセス権がない、つまり、アクセス権ポーリングデーモン２４から通知される有効期限が切れていると判定された場合には、エラーを上位へリターンする（ステップＳ３０）。
【０１００】
また、ステップＳ２３においてＩ／Ｏ要求がマスター領域１１へのライト要求でない、つまり、例えばマスター領域１１へのリード要求等であると判定された場合、下位の共有ディスク１０にそのままＩ／Ｏ要求が渡され、ステップＳ２８の処理が実行される。
【０１０１】
また、ステップＳ２４においてライト先ブロックが第１のビットマップテーブルに登録済みであると判定された場合、ステップＳ２６の処理が実行される。
【０１０２】
ここで、図７を参照して、サーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３の処理について具体的に説明する。なお、共有ディスク１０に含まれるアクセス権管理テーブル１２には、マスター領域１１に対するアクセス権がサーバ２０に設定されているものとする。
【０１０３】
まず、ディスクドライバ２３は、アプリケーション２１からのＩ／Ｏ要求を入力する（ステップＳ３１）。ここでは、アプリケーション２１からのＩ／Ｏ要求は、マスター領域１１（ＬＵ１）に対するライト要求であるものとして説明する。
【０１０４】
次に、ディスクドライバ２３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、サーバ２０にアクセス権があるか否かを判定する（ステップＳ３２）。上記したようにアクセス権管理テーブル１２にはサーバ２０のアクセス権が設定されているため、ここではサーバ２０にアクセス権があると判定される。
【０１０５】
ディスクドライバ２３は、アプリケーション２１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）がサーバ２０に備えられたメモリ上に保持されている第１のビットマップテーブル１３１に登録済みであるか否かを判定する。なお、図７に示すように、第１のビットマップテーブル１３１は、上記したサーバ２０に備えられたメモリ以外に、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている。
【０１０６】
ここで、ライト先ブロックが第１のビットマップテーブル１３１に登録済みでない場合を想定する。この場合、ディスクドライバ２３は、サーバ２０に備えられたメモリ上に保持されている第１のビットマップテーブル１３１にライト先ブロックを登録する（ステップＳ３３）。
【０１０７】
また、ディスクドライバ２３は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１にライト先ブロックを登録する（ステップＳ３４）。
【０１０８】
次に、ディスクドライバ２３は、上記したステップＳ３２に相当するステップＳ３５の処理を実行する。つまり、ディスクドライバ２３は、サーバ２０にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル１２は変更されておらず、サーバ２０にアクセス権があると判定されたものとする。
【０１０９】
ディスクドライバ２３は、アプリケーション２１から入力されたライト要求に応じてマスター領域１１に対するライト処理を実行する（ステップＳ３６）。
【０１１０】
ディスクドライバ２３は、上記したステップＳ３２（またはステップＳ３５）の処理に相当するステップＳ３７の処理を実行する。ここで、サーバ２０にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション２１に返される。
【０１１１】
一方、上記したステップＳ３２、Ｓ３５及びＳ３７においてサーバ２０にアクセス権がないと判定された場合には、アプリケーション２１にエラーが返される。このステップＳ３２、Ｓ３５及びＳ３７においては、上記したようにサーバ３０（のクラスタソフト３２）によってアクセス権管理テーブル１２が変更された場合に、サーバ２０にアクセス権がないと判定される。
【０１１２】
次に、図８のフローチャートを参照して、サーバ３０においてフェイルオーバが実行される際の当該サーバ３０のクラスタソフト３２の処理手順について説明する。
【０１１３】
ここでは、サーバ２０が稼動系サーバ、サーバ３０が待機系サーバであるものとして説明する。
【０１１４】
まず、待機系サーバであるサーバ３０のクラスタソフト３２は、稼動系サーバであるサーバ２０のクラスタソフト２２からのハートビートの断絶を検出する（ステップＳ４１）。このハートビートの断絶は、例えば稼動系サーバであるサーバ２０の故障によるダウンの他、例えばサーバ２０及びサーバ３０間の通信路の障害、またはサーバ２０でＣＰＵ高負荷等による一時的なスローダウン等により発生し得る。
【０１１５】
次に、クラスタソフト３２は、共有ディスク１０に含まれるアクセス権管理テーブル１２を変更する（ステップＳ４２）。この場合、クラスタソフト３２は、マスター領域１１に対するアクセス権をサーバ３０に設定する。
【０１１６】
アクセス権管理テーブル１２が変更されると、サーバ３０のアクセス権ポーリングデーモン３４は、サーバ３０の有効期限を設定し、当該有効期限をサーバ３０のディスクドライバ３３に通知する。アクセス権ポーリングデーモン３４は、定期的にアクセス権管理テーブル１２を参照し、サーバ３０のアクセス権が設定されている場合には有効期限を更新する。
【０１１７】
クラスタソフト３２は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブルを、当該共有ディスク１０上の別領域である例えばサーバ３０用領域１４にコピーする（ステップＳ４３）。つまり、クラスタソフト３２は、第１のビットマップテーブルのコピーを、サーバ３０用領域１４上に作成する。
【０１１８】
また、クラスタソフト３２は、第１のビットマップテーブルを例えばサーバ３０に備えられるメモリ上にコピーする。つまり、クラスタソフト３２は、第１のピットマップテーブルのコピーを、サーバ３０に備えられるメモリ上に作成する。
【０１１９】
クラスタソフト３２は、サーバ３０用領域１４にコピーされた第１のビットマップテーブル（第１のビットマップテーブルのコピー）に登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータをマスター領域１１とは別の領域（ログ領域）にコピーする（ステップＳ４４）。
【０１２０】
クラスタソフト３２は、サーバ２０のアクセス権ポーリングデーモン２４によって設定されたサーバ２０のアクセス権の有効期限が確実に切れる時刻まで待機する（ステップＳ４５）。
【０１２１】
クラスタソフト３２は、サーバ３０のディスクドライバ３３に当該サーバ３０が稼動系サーバとなった旨を通知する（ステップＳ４６）。このとき、ディスクドライバ３３は、上位層からマスター領域１１が見える状態にする。
【０１２２】
クラスタソフト３２は、サーバ３０のアプリケーション３１を起動する（ステップＳ４７）。これにより、フェイルオーバが完了される。
【０１２３】
次に、図９のフローチャートを参照して、上記したフェイルオーバ直後のサーバ３０のディスクドライバ３３の処理手順について説明する。
【０１２４】
まず、ディスクドライバ３３は、上位（アプリケーション３１）からのＩ／Ｏ要求を入力する（ステップＳ５１）。
【０１２５】
次に、ディスクドライバ３３は、例えばアクセス権ポーリングデーモン３４から通知される有効期限に基づいて、アクセス権管理テーブル１２にサーバ３０のアクセス権が設定されているか否かを判定する。つまり、ディスクドライバ３３は、サーバ３０にマスター領域１１に対するアクセス権があるか否かを判定する（ステップＳ５２）。
【０１２６】
サーバ３０にアクセス権があると判定された場合（ステップＳ５２のＹＥＳ）、ディスクドライバ３３は、入力されたＩ／Ｏ要求がマスター領域１１へのライト要求であるか否かを判定する（ステップＳ５３）。
【０１２７】
マスター領域１１へのライト要求であると判定された場合（ステップＳ５３のＹＥＳ）、ディスクドライバ３３は、サーバ３０に備えられるメモリ上に保持されている第２のビットマップテーブルを参照する。ディスクドライバ３３は、ライト要求の対象となる領域に対応するブロック（ライト先ブロック）が第２のビットマップテーブルに登録済みであるか否かを判定する（ステップＳ５４）。
【０１２８】
ライト先ブロックが第２のビットマップテーブルに登録済みでないと判定された場合（ステップＳ５４のＮＯ）、ディスクドライバ３３は、当該ライト先ブロックを当該第２のビットマップテーブルに登録する（ステップＳ５５）。この場合、ディスクドライバ３３は、サーバ３０ｂに備えられるメモリ上に保持されている第２のビットマップテーブル及び共有ディスク１０に含まれるサーバ３０用領域１４に保持されている第２のビットマップテーブルにライト先ブロックを登録する。
【０１２９】
次に、ディスクドライバ３３は、例えばアクセス権ポーリングデーモン３４から通知される有効期限に基づいて、サーバ３０にマスター領域１１に対するアクセス権があるか否かを判定する（ステップＳ５６）。
【０１３０】
サーバ３０にアクセス権があると判定された場合（ステップＳ５６のＹＥＳ）、ディスクドライバ３３は、ライト先ブロックがサーバ３０に備えられるメモリ上に保持されている第１のビットマップテーブル（第１のビットマップテーブルのコピー）に登録済みであるか否かを判定する（ステップＳ５７）。
【０１３１】
ここで、ステップＳ５７においては、例えばサーバ２０用領域１３に保持されている第１のビットマップテーブルでなく、サーバ３０に備えられるメモリ上の第１のビットマップテーブルのコピーを用いて判定処理が実行される。これにより、例えば判定処理中にサーバ２０用領域１３に保持されている第１のビットマップテーブルがサーバ２０によって更新されるような場合であっても誤動作を行うことなく処理を実行することが可能となる。
【０１３２】
ライト先ブロックが第１のビットマップテーブルに登録済みであると判定された場合（ステップＳ５７のＹＥＳ）、ディスクドライバ３３は、上記したクラスタソフト３２によって第１のビットマップテーブルに登録されているブロックの番号及び当該ブロック（に対応する領域）に格納されているデータがコピーされているログ領域へのライト処理を実行する（ステップＳ５８）。このとき、ディスクドライバ３３は、ログ領域のうち、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
【０１３３】
一方、ライト先ブロックが第１のビットマップテーブルに登録済みでないと判定された場合（ステップＳ５７のＮＯ）、ディスクドライバ３３は、マスター領域１１へのライト処理を実行する（ステップＳ５９）。
【０１３４】
ディスクドライバ３３は、例えばアクセス権ポーリングデーモン３４から通知される有効期限に基づいて、サーバ３０にアクセス権があるか否かを判定する（ステップＳ６０）。
【０１３５】
サーバ３０にアクセス権があると判定された場合（ステップＳ６０のＹＥＳ）、ディスクドライバ３３は、例えば正常にライト処理が実行された旨の処理結果を上位へリターンする（ステップＳ６１）。
【０１３６】
一方、上記したステップＳ５２、Ｓ５６及びＳ６０においてサーバ３０にアクセス権がない、つまりアクセス権ポーリングデーモン３４から通知される有効期限が切れていると判定された場合には、エラーを上位へリターンする（ステップＳ６１）。
【０１３７】
また、ステップＳ５３においてＩ／Ｏ要求がマスター領域１１へのライト要求でない、
例えばマスター領域１１へのリード要求等であると判定された場合、当該リード要求に応じて共有ディスク１０に対してリード処理が実行される。この場合、上述したリード結果の不一致という事態を避けるために、リード要求の対象となる領域に対応するブロック（リード先ブロック）が第１のビットマップテーブルに登録済みである場合にはログ領域に対してリード処理が実行される。このリード処理が実行されると、ステップＳ６０の処理が実行される。
【０１３８】
一方、例えばマスター領域１１以外へのＩ／Ｏ要求である場合には、下位の共有ディスク１０にそのままＩ／Ｏ要求が渡され、ステップＳ６０の処理が実行される。
【０１３９】
また、ステップＳ５４においてライト先ブロックが第２のビットマップテーブルに登録済みであると判定された場合、ステップＳ５６の処理が実行される。
【０１４０】
つまり、上記したようにフェイルオーバ直後においては、第１のビットマップテーブルに登録されているサーバ２０からのライト要求により上塗りされる可能性のある領域（小領域）をアクセス先とするサーバ３０からのアクセスは、ログ領域に対して行われることになる。
【０１４１】
図１０を参照して、サーバ３０においてフェイルオーバが実行される際の当該サーバ３０のクラスタソフト３２及びディスクドライバ３３の処理について具体的に説明する。なお、フェイルオーバが実行される以前の共有ディスク１０に含まれるアクセス権管理テーブル１２には、稼動系サーバであるサーバ２０にアクセス権が設定されているものとする。
【０１４２】
ここで、待機系サーバであるサーバ３０のクラスタソフト３２が、稼動系サーバであるサーバ２０のクラスタソフト２２からのハートビートの断絶を検出したものとする。
【０１４３】
この場合、サーバ３０のクラスタソフト３２は、共有ディスク１０に含まれるアクセス権管理テーブル１２を変更する（ステップＳ７１）。クラスタソフト３２は、マスター領域１１に対するアクセス権をサーバ３０に設定する。これにより、サーバ３０は、マスター領域１１（ＬＵ１）へのアクセス権をサーバ２０から奪う。
【０１４４】
図１０に示す例では、サーバ２０の「○」を「×」に変更し、サーバ３０の「×」を「○」に変更する。これにより、サーバ３０にマスター領域１１へのアクセス権が設定される。
【０１４５】
アクセス権管理テーブル１２が変更されると、サーバ３０のアクセス権ポーリングデーモン３４は、サーバ３０の有効期限を設定し、当該有効期限をサーバ３０のディスクドライバ３３に通知する。
【０１４６】
クラスタソフト３２は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１を、サーバ３０用領域１４にコピーする（ステップＳ７２）。
【０１４７】
また、クラスタソフト３２は、第１のビットマップテーブル１３１をサーバ３０に備えられるメモリ上にコピーする（ステップＳ７３）。
【０１４８】
クラスタソフト３２は、サーバ３０用領域１４にコピーされた第１のビットマップテーブル１３１に登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータを、マスター領域１１からログ領域１４２にコピーする（ステップＳ７４、Ｓ７５）。このログ領域１４２は、共有ディスク１０に含まれる例えばサーバ３０用領域１４にその領域が確保される。
【０１４９】
上記した処理が実行されると、クラスタソフト３２は、サーバ２０のアクセス権の有効期限が確実に切れる時刻まで待機した後、アプリケーション３１を起動させる。
【０１５０】
クラスタソフト３２によってアプリケーション３１が起動されると、サーバ３０のディスクドライバ３３は、アプリケーション３１からのＩ／Ｏ要求を入力する（ステップＳ７６）。ここでは、アプリケーション３１からのＩ／Ｏ要求は、マスター領域１１に対するライト要求であるものとして説明する。
【０１５１】
次に、ディスクドライバ３３は、例えばアクセス権ポーリングデーモン３４から通知される有効期限に基づいて、サーバ３０にアクセス権があるか否かを判定する（ステップＳ７７）。上記したステップＳ７１の処理においてアクセス権管理テーブル１２にはクラスタソフト３２によってサーバ３０にアクセス権が設定されているため、ここではサーバ３０にアクセス権があると判定される。
【０１５２】
ディスクドライバ３３は、アプリケーション３１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）がサーバ３０に備えられたメモリ上に保持されている第２のビットマップテーブル１４１に登録済みであるか否かを判定する。なお、図１０に示すように第２のビットマップテーブル１４１は、上記したサーバ３０に備えられたメモリ以外に、共有ディスク１０に含まれるサーバ３０用領域１４に保持される。
【０１５３】
ここで、ライト先ブロックが第２のビットマップテーブル１４１に登録済みでない場合を想定する。この場合、ディスクドライバ３３は、サーバ３０に備えられたメモリ上に保持されている第２のビットマップテーブル１４１にライト先ブロックを登録する（ステップＳ７８）。
【０１５４】
また、ディスクドライバ３３は、共有ディスク１０に含まれるサーバ３０用領域１４に保持されている第２のビットマップテーブル１４１にライト先ブロックを登録する（ステップＳ７９）。
【０１５５】
次に、ディスクドライバ３３は、上記したステップＳ７７に相当するステップＳ８０の処理を実行する。つまり、ディスクドライバ３３は、サーバ３０にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル１２は変更されておらず、サーバ３０にアクセス権があると判定されたものとする。
【０１５６】
ディスクドライバ３３は、サーバ３０に備えられるメモリ上に保持されている第１のビットマップテーブル１３１を参照する（ステップＳ８１）。これにより、ディスクドライバ３３は、アプリケーション３１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）が第１のビットマップテーブル１３１に登録済みであるか否かを判定する。
【０１５７】
ここで、ライト先ブロックが第１のビットマップテーブル１３１に登録済みであると判定された場合を想定する。この場合には、ディスクドライバ３３は、上記したクラスタソフト３２によって第１のビットマップテーブル１３１に登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータがコピーされているログ領域１４２に対してライト処理を実行する（ステップＳ８２）。このとき、ディスクドライバ３３は、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
【０１５８】
一方、ライト先ブロックが第１のビットマップテーブル１３１に登録済みでない場合を想定する。この場合には、ディスクドライバ３３は、アプリケーション３１から入力されたライト要求に応じてマスター領域１１に対するライト処理を実行する（ステップＳ８３）。
【０１５９】
ディスクドライバ３３は、上記したステップＳ７７（またはステップＳ８０）の処理に相当するステップＳ８４の処理を実行する。ここで、サーバ３０にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション３１に返される。
【０１６０】
一方、上記したステップＳ７７、Ｓ８０及びＳ８４においてサーバ３０にアクセス権がないと判定された場合には、アプリケーション３１にエラーが返される。
【０１６１】
次に、図１１のフローチャートを参照して、フェイルオーバが完了し、一定時間が経過した後のサーバ３０のクラスタソフト３２の処理手順について説明する。この一定時間とは、例えば元稼動系サーバであるサーバ２０におけるＣＰＵ高負荷による一時的なスローダウンが回復するために十分な時間であり、予め定められている。
【０１６２】
まず、サーバ３０のクラスタソフト３２は、当該サーバ３０に備えられているメモリ上に保持されている第１のビットマップテーブルを削除する（ステップＳ９１）。
【０１６３】
次に、クラスタソフト３２は、共有ディスク１０に含まれるサーバ３０用領域１４内に保持されている第１のビットマップテーブルを削除する（ステップＳ９２）。
【０１６４】
クラスタソフト３２は、共有ディスク１０に含まれるサーバ３０用領域１４に確保されているログ領域に格納されているデータを、マスター領域１１の当該ログ領域に対応する場所（領域）にコピーする（ステップＳ９３）。
【０１６５】
ステップ９３に示すコピー処理が完了されると、クラスタソフト３２は、サーバ３０用領域１４に確保されているログ領域を削除する（ステップＳ９４）。
【０１６６】
なお、図１１に示すクラスタソフト３２の処理後においては、サーバ３０のディスクドライバ３３では上述した図６に示す処理に相当する処理が実行される。
【０１６７】
ここで、図１２を参照して、フェイルオーバが完了し、一定時間が経過した後のサーバ３０のクラスタソフト３２及びディスクドライバ３３の処理について具体的に説明する。
【０１６８】
まず、サーバ３０のクラスタソフト３２は、当該サーバ３０に備えられているメモリ上に保持されている第１のビットマップテーブル１３１を削除する（ステップＳ１０１）。
【０１６９】
次に、クラスタソフト３２は、共有ディスク１０に含まれるサーバ３０用領域１４に保持されている第１のビットマップテーブル１３１を削除する（ステップＳ１０２）。
【０１７０】
クラスタソフト３２は、共有ディスク１０に含まれるサーバ３０用領域１４に確保されているログ領域１４２に格納されているデータをマスター領域１１の対応する領域にコピーし、当該ログ領域１４２（に格納されているデータ）を削除する（ステップＳ１０３）。
【０１７１】
ここで、上記したサーバ３０のクラスタソフト３２の処理の完了後に、当該サーバ３０のディスクドライバ３３がサーバ３０上で起動されているアプリケーション３１からＩ／Ｏ要求を入力したものとする（ステップＳ１０４）。このＩ／Ｏ要求は、マスター領域１１（ＬＵ１）に対するライト要求であるものとして説明する。
【０１７２】
次に、ディスクドライバ３３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、サーバ３０にアクセス権があるか否かを判定する（ステップＳ１０５）。ここでは、図１２に示すようにアクセス権管理テーブル１２にはサーバ３０のアクセス権が設定されているものとする。つまり、ディスクドライバ３３によってサーバ３０にアクセス権があると判定されたものとする。
【０１７３】
ディスクドライバ３３は、アプリケーション３１から入力されたライト要求の対象となる領域（ライト先ブロック）がサーバ３０に備えられたメモリ上に保持されている第２のビットマップテーブル１４１に登録済みであるか否かを判定する。なお、図１２に示すように第２のビットマップテーブル１４１は、上記したサーバ３０に備えられたメモリ以外に、共有ディスク１０に含まれるサーバ３０用領域１４に保持される。
【０１７４】
ここで、ライト先ブロックが第２のビットマップテーブル１４１に登録済みでない場合を想定する。この場合、ディスクドライバ３３は、サーバ３０に備えられたメモリ上に保持されている第２のビットマップテーブル１４１にライト先ブロックを登録する（ステップＳ１０６）。
【０１７５】
また、ディスクドライバ３３は、共有ディスク１０に含まれるサーバ３０用領域１４に保持されている第２のビットマップテーブル１４１にライト先ブロックを登録する（ステップＳ１０７）。
【０１７６】
次に、ディスクドライバ３３は、上記したステップＳ１０５の処理に相当するステップＳ１０８の処理を実行する。つまり、ディスクドライバ３３は、サーバ３０にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル１２は変更されておらず、サーバ３０にアクセス権があると判定されたものとする。
【０１７７】
ディスクドライバ３３は、アプリケーション３１から入力されたライト要求に応じてマスター領域１１に対するライト処理を実行する（ステップＳ１０９）。
【０１７８】
ディスクドライバ３３は、上記したステップＳ１０５（またはステップＳ１０８）の処理に相当するステップＳ１１０の処理を実行する。ここで、サーバ３０にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション３１に返される。
【０１７９】
一方、上記したステップＳ１０５、Ｓ１０８及びＳ１１０においてサーバ３０にアクセス権がないと判定された場合には、アプリケーション３１にエラーが返される。
【０１８０】
ここでは、図１１に示す処理がフェイルオーバの後に一定期間が経過した後に実行されるものとして説明したが、この処理は、例えば元稼動系サーバであるサーバ２０（のクラスタソフト２２）からハートビートが検出された後、つまり、サーバ２０で発生したスローダウンの回復が確認され、当該サーバ２０からのライトアクセスが確実に停止された後に実行されても構わない。
【０１８１】
上記したように本実施形態においては、通常運転時に稼動系サーバであるサーバ２０によりマスター領域１１に対してライト処理が実行される場合に当該ライト処理に応じてライト先ブロックが第１のビットマップテーブルに登録される。この後、サーバ２０からサーバ３０にフェイルオーバが実行された場合、当該フェイルオーバ直後におけるサーバ３０からの第１のビットマップテーブルに登録されているブロック（に対応する領域）に対するアクセスは、当該第１のビットマップテーブルに登録されているブロック（のブロック番号及び当該ブロックに格納されているデータ）がコピーされたログ領域に対して実行される。そして、例えばサーバ２０のスローダウンが回復するのに十分な時間（一定時間）経過後にログ領域（に格納されているデータ）がマスター領域１１にコピーされる。これにより、本実施形態においては、現稼動系サーバであるサーバ３０によってマスター領域１１に対してライト処理が実行された後に、当該ライト処理が実行されたブロックと同一の領域に対して元稼動系サーバであるサーバ２０からのライト要求によってデータが上塗りされた場合であっても当該上塗りされた領域にはログ領域がコピーされるので、当該上塗りされることによって生じるデータ破壊を防止することが可能となる。同様に、本実施形態においては、例えば現稼動系サーバであるサーバ３０によってリード処理が実行された領域と同一の領域に対して元稼動系サーバであるサーバ２０からのライト要求によってデータが上塗りされることによって生じるリード結果の不一致を防止することが可能となる。
【０１８２】
［第２の実施形態］
次に、図１３を参照して、本発明の第２の実施形態に係るクラスタシステムについて説明する。図１３は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。なお、前述した図１と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１と異なる部分について主に述べる。以下の各実施形態についても同様にして重複した説明を省略する。
【０１８３】
図１３に示すように、本実施形態に係るクラスタシステムは、複数のサーバ及び共有ディスク１００を備える。複数のサーバは、サーバ（第３の計算機）４０を含む。
【０１８４】
また、共有ディスク１００及びサーバ４０は、例えばＦＣケーブルで接続されている。サーバ４０は、例えばサーバ３０と２本の通信路を介して通信可能に接続されている。
【０１８５】
共有ディスク１００は、アクセス権管理テーブル１２１を含む。このアクセス権管理テーブル１２１には、クラスタシステムを構成するサーバ２０、３０及び４０のそれぞれについて、共有ディスク１００のマスター領域１１へのアクセスの許可または不許可が設定される。図１３に示すように、アクセス権管理テーブル１２１において例えばＬＵ１に対応付けてサーバ２０に「×」、サーバ３０に「○」、サーバ４０に「×」が設定されている場合には、サーバ３０にアクセス権が設定されており、他のサーバ２０及び４０はマスター領域１１へのアクセスが許可されていない。
【０１８６】
また、共有ディスク１０は、サーバ４０用のデータ領域（以下、サーバ４０用領域と表記）１５を含む。このサーバ４０用領域１５には、例えばサーバ４０によってライト処理が実行される際に当該ライト先となる領域に対応するブロックが登録されるサーバ４０用のビットマップテーブル（以下、第３のビットマップテーブルと表記）が保持される。
【０１８７】
サーバ４０は、当該サーバ４０上で動作するアプリケーション３１、クラスタソフト４２、ディスクドライバ４３及びアクセス権ポーリングデーモン４４を備える。
【０１８８】
ここで、前述したようにサーバ３０においてフェイルオーバが実行され、サーバ３０が稼動系サーバである場合を想定する。この場合には、サーバ４０は、サーバ３０の待機系サーバとして動作する。
【０１８９】
稼動系サーバであるサーバ３０に備えられるクラスタソフト３２及び待機系サーバであるサーバ４０に備えられるクラスタソフト４２の間では通信路を経由してハートビートを交換し続け、互いの生存を通知し合う。
【０１９０】
例えば待機系サーバであるサーバ４０のクラスタソフト４２によって稼動系サーバであるサーバ３０のクラスタソフト３２からのハートビートの断絶が検出された場合には、サーバ４０上ではサーバ３０で起動されていたアプリケーション３１の処理を継続するためにアプリケーション４１が起動される。これにより、サーバ４０はフェイルオーバを実行する。
【０１９１】
クラスタソフト４２は、サーバ３０のクラスタソフト３２からのハートビートの断絶が検出された場合、共有ディスク１００に含まれるアクセス権管理テーブル１２１に対してマスター領域１１に対するアクセス権をサーバ４０に変更（設定）する。
【０１９２】
クラスタソフト４２は、前述した第１のビットマップテーブル及び第２のビットマップテーブルに登録されているブロックに対応するマスター領域１１（に含まれる領域）に格納されているデータを、当該マスター領域１１とは異なる共有ディスク１００上の別の領域であるログ領域（第３の領域）にコピーする。このログ領域は、例えば上記したサーバ４０用領域１５内にその領域が確保される。
【０１９３】
クラスタソフト４２は、サーバ３０のマスター領域１１に対するアクセス権の有効期限が確実に切れる時刻まで待機し、当該時刻後にアプリケーション４１を起動する。
【０１９４】
また、クラスタソフト４２は、上記したフェイルオーバが完了し、更に一定時間が経過した場合に、上記したログ領域に格納されているデータをマスター領域１１の対応する領域にコピーする。クラスタソフト４２は、このコピー処理が完了すると、ログ領域を削除する。
【０１９５】
ディスクドライバ４３は、上位（例えば、アプリケーション４１）からのＩ／Ｏ要求に基づいて、共有ディスク１００に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ４３は、Ｉ／Ｏ要求が上記した第１のビットマップテーブル及び第２のビットマップテーブルに登録されている領域に対する要求である場合には、上記したサーバ４０用領域１５に含まれるログ領域に対して当該要求に応じた処理を実行する。
【０１９６】
また、ディスクドライバ４３は、例えば共有ディスク１００に含まれるマスター領域１１に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック（ライト先ブロック）を上記した第３のビットマップテーブルに登録する。この第３のビットマップテーブルは、例えばサーバ４０に備えられるメモリ（図示せず）上にその領域が確保される。また、第３のビットマップテーブルは、上記した共有ディスク１００のサーバ４０用領域１５に保持される。
【０１９７】
アクセス権ポーリングデーモン４４は、前述したサーバ２０のアクセス権ポーリングデーモン２４（またはサーバ３０のアクセス権ポーリングデーモン３４）と同様であるのでその詳しい説明は省略する。
【０１９８】
つまり、本実施形態においては、上記したようにサーバ２０、３０及び４０の３台系のクラスタシステムを想定している。このクラスタシステムにおいて、サーバ２０からサーバ３０へのフェイルオーバ直後にサーバ３０で障害等が発生した場合には、サーバ４０に処理が引き継がれる。この場合には、サーバ４０においては前述した第１の実施形態におけるサーバ３０と同様にフェイルオーバが実行される。
【０１９９】
次に、図１４を参照して、サーバ４０においてフェイルオーバが実行される際の当該サーバ４０のクラスタソフト４２及びディスクドライバ４３の処理について具体的に説明する。
【０２００】
ここでは、上記したようにサーバ２０からサーバ３０へのフェイルオーバ直後にサーバ３０で例えばＣＰＵ高負荷等によるスローダウンが発生し、サーバ４０でフェイルオーバが実行される場合を想定している。よって、サーバ４０でフェイルオーバが実行される以前の共有ディスク１００に含まれるアクセス権管理テーブル１２１には、稼動系サーバであるサーバ３０にアクセス権が設定されているものとする。
【０２０１】
まず、待機系サーバであるサーバ４０のクラスタソフト４２が、稼動系サーバであるサーバ３０のクラスタソフト３２からのハートビートの断絶を検出したものとする。
【０２０２】
この場合、サーバ４０のクラスタソフト４２は、共有ディスク１００に含まれるアクセス権管理テーブル１２１を変更する（ステップＳ１１１）。クラスタソフト４２は、マスター領域１１に対するアクセス権をサーバ４０に設定する。これにより、サーバ４０は、マスター領域１１（ＬＵ１）へのアクセス権をサーバ３０から奪う。
【０２０３】
図１４に示す例では、サーバ３０の「○」が「×」に変更され、サーバ４０の「×」が「○」に変更される。これにより、サーバ４０にマスター領域１１へのアクセス権が設定される。
【０２０４】
アクセス権管理テーブル１２１が変更されると、サーバ４０のアクセス権ポーリングデーモン４４は、サーバ４０の有効期限を設定し、当該有効期限をサーバ４０のディスクドライバ４３に通知する。
【０２０５】
クラスタソフト４２は、共有ディスクに含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１及びサーバ３０用領域１４に保持されている第２のビットマップテーブル１４１が組み合わされたビットマップテーブル（以下、第４のビットマップテーブルと表記）１５１をサーバ４０用領域１５にコピー（作成）する（ステップＳ１１２）。この第４のビットマップテーブル１５１には、第１のビットマップテーブル１３１及び第２のビットマップテーブルに登録されているブロックが登録されている。
【０２０６】
また、クラスタソフト４２は、第４のビットマップテーブル１５１をサーバ４０に備えられるメモリ上にコピーする（ステップＳ１１３）。
【０２０７】
クラスタソフト４２は、サーバ４０用領域１５にコピーされた第４のビットマップテーブル１５１を参照して、上記した第１のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータとしてサーバ３０用領域１４に含まれているログ領域１４２のブロック番号及びデータをログ領域１５２にコピーする（ステップＳ１ｌ４、ステップＳ１１５）。
【０２０８】
また、クラスタソフト４２は、サーバ４０用領域１５にコピーされた第４のビットマップテーブル１５１を参照して、上記した第２のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータを、マスター領域１１からログ領域５２にコピーする（ステップＳ１１４、ステップＳ１１６）。
【０２０９】
このステップＳ１１４〜ステップＳ１１６の処理によって、第４のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータが、ログ領域１５２にコピーされる。
【０２１０】
このログ領域１５２は、共有ディスク１００に含まれる例えばサーバ４０用領域１５にその領域が確保される。
【０２１１】
上記した処理が実行されると、クラスタソフト４２は、サーバ３０のアクセス権の有効期限が確実にけれる時刻まで待機した後、アプリケーション４１を起動させる。
【０２１２】
クラスタソフト４２によってアプリケーション４１が起動されると、サーバ４０のディスクドライバ４３は、アプリケーション４１からのＩ／Ｏ要求を入力する（ステップＳ１１７）。ここでは、アプリケーション４１からのＩ／Ｏ要求は、マスター領域１１に対するライト要求であるものとして説明する。
【０２１３】
次に、ディスクドライバ４３は、例えばアクセス権ポーリングデーモン４４から通知される有効期限に基づいて、サーバ４０にアクセス権があるか否かを判定する（ステップＳ１１８）。上記したステップＳ１１１の処理においてアクセス権管理テーブル１２１にはクラスタソフト４２によってサーバ４０にアクセス権が設定されているため、ここではサーバ４０にアクセス権があると判定される。
【０２１４】
ディスクドライバ４３は、アプリケーション４１から入力されたライト要求の対象となるライト先ブロックがサーバ４０に備えられたメモリ上に保持されている第３のビットマップテーブル１５３に登録済みであるか否かを判定する。なお、図１４に示すように第３のビットマップテーブル１５１は、上記したサーバ４０に備えられたメモリ以外に、共有ディスク１００に含まれるサーバ４０用領域１５に保持される。
【０２１５】
ここで、ライト先ブロックが第３のビットマップテーブル１５３に登録済みでない場合を想定する。この場合、ディスクドライバ４３は、サーバ４０に備えられたメモリ上に保持されている第３のビットマップテーブル１５３にライト先ブロックを登録する（ステップＳ１１９）。
【０２１６】
また、ディスクドライバ４３は、共有ディスク１００に含まれるサーバ４０用領域１５に保持されている第３のビットマップテーブル１５３にライト先ブロックを登録する（ステップＳ１２０）。
【０２１７】
次に、ディスクドライバ４３は、上記したステップＳ１１８に相当するステップＳ１２１の処理を実行する。つまり、ディスクドライバ４３は、サーバ４０にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル１２１は変更されておらず、サーバ４０にアクセス権があると判定されたものとする。
【０２１８】
ディスクドライバ４３は、サーバ４０に備えられるメモリ上に保持されている第４のビットマップテーブル１５１を参照する（ステップＳ１２２）。これにより、ディスクドライバ４３は、アプリケーション４１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）が第４のビットマップテーブル１５１に登録済みであるか否かを判定する。
【０２１９】
ここで、ライト先ブロックが第４のビットマップテーブル１５１に登録済みであると判定された場合を想定する。この場合には、ディスクドライバ４３は、上記したクラスタソフト４２によって第４のビットマップテーブル１５１に登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータがコピーされているログ領域１５２に対してライト処理を実行する（ステップＳ１２３）。このとき、ディスクドライバ４３は、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
【０２２０】
一方、ライト先ブロックが第４のビットマップテーブル１５１に登録済みでないと判定された場合を想定する。この場合には、ディスクドライバ４３は、アプリケーション４１から入力されたライト要求に応じてマスター領域１１に対するライト処理を実行する（ステップＳ１２４）。
【０２２１】
ディスクドライバ４３は、上記したステップＳ１１８（またはステップＳ１２１）の処理に相当するステップＳ１２５の処理を実行する。ここで、サーバ４０にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション４１に返される。
【０２２２】
一方、上記したステップＳ１１８、Ｓ１２１及びＳ１２５においてサーバ４０にアクセス権がないと判定された場合には、アプリケーション４１にエラーが返される。
【０２２３】
上記したように本実施形態においては、例えばサーバ２０、３０及び４０の３台系のクラスタシステムにおいてサーバ２０からサーバ３０にフェイルオーバが実行された直後に当該サーバ３０からサーバ４０にフェイルオーバが実行された（多段フェイルオーバが発生した）場合には、当該サーバ４０からのアクセスは、第１のビットマップテーブル及び第２のビットマップテーブルが組み合わされた第４のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータがコピーされたログ領域に対して実行される。これにより、本実施形態においては、上記したサーバ２０、３０及び４０の３台系のクラスタシステムのような多台系のクラスタシステムで多段フェイルオーバが発生した場合であっても、処理を複雑化することなくデータ破壊を防止することが可能となる。
【０２２４】
［第３の実施形態］
次に、図１５を参照して、本発明の第３の実施形態に係るクラスタシステムについて説明する。図１５は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。
【０２２５】
図１５に示すように、本実施形態に係るクラスタシステムにおいては、サーバ２０は、テーブル整理デーモン２５を備える。
【０２２６】
また、本実施形態においては、前述した第１の実施形態とは異なり、サーバ２０に備えられるメモリ上には、第１のビットマップテーブルに代えてイントマップ（intmap）テーブルが保持される。第１のビットマップテーブルとは異なり、このイントマップテーブルにおいては、４バイトが１ブロックに対応する。イントマップテーブルには、１ブロック毎に例えばｉｎｔの値が登録される。
【０２２７】
ディスクドライバ２３は、例えば共有ディスク１０に含まれるマスター領域１１に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック（ライト先ブロック）をサーバ２０に備えられるメモリ上に保持されるイントマップテーブルに登録する。
【０２２８】
このとき、ライト先ブロックがイントマップテーブルに登録されていない場合、つまり、ライト先ブロックへの初書き込みの場合には、当該ライト先ブロックに対応するｉｎｔの値として現在のシーケンス（sequence）番号が登録される。一方、ライト先ブロックが既にイントマップテーブルに登録されている場合には、例えば当該ライト先ブロックに対応するｉｎｔの値に１を加えた値（つまり、シーケンス番号＋１）を登録する。
【０２２９】
これにより、イントマップテーブルにおいては、当該イントマップテーブルに登録されているｉｎｔの値（シーケンス番号）に応じて、当該値に対応するブロックへのアクセス頻度が示される。
【０２３０】
テーブル整理デーモン２５は、例えば定期的にイントマップテーブルを参照する。テーブル整理デーモン２５は、イントマップテーブルに登録済みのブロック数が予め定められた値（以下、閾値と表記）以上であるか否かを判定する。
【０２３１】
テーブル整理デーモン２５は、例えばイントマップテーブルにおいて古いシーケンス番号を持つｉｎｔの値をクリア（＝０）する。つまり、テーブル整理デーモン２５は、アクセス頻度の少ない登録済みのブロックをイントマップテーブルから未登録とする。
【０２３２】
テーブル整理デーモン２５は、ｉｎｔの値がクリアされたブロックを共有ディスク１０に含まれるサーバ２０用領域に保持されている第１のビットマップテーブルから未登録とする。これにより、テーブル整理デーモン２５は、アクセス頻度の少ないブロックを削除することによって登録済みのブロック数を閾値以下にする。
【０２３３】
次に、図１６を参照して、図１５に示すクラスタシステムを構成するサーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３及びテーブル整理デーモンの処理について具体的に説明する。なお、共有ディスク１０に含まれるアクセス権管理テーブル１２には、サーバ２０のマスター領域１１に対するアクセス権が設定されているものとする。
【０２３４】
まず、前述した図７に示すステップＳ３１及びステップＳ３２の処理に相当するステップＳ１３１及びステップＳ１３２の処理が実行される。なお、ステップＳ１３１で入力されたＩ／Ｏ要求は、マスター領域１１（ＬＵ１）に対するライト要求であるものとする。
【０２３５】
次に、ディスクドライバ２３は、アプリケーション２１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）をサーバ２０に備えられたメモリ上に保持されているイントマップテーブル１３２に登録する（ステップＳ１３３）。
【０２３６】
このとき、ライト先ブロックがイントマップテーブル１３２に登録されていない場合、つまり、当該ライト先ブロックへの初書き込みである場合には、ディスクドライバ２３は、当該ライト先ブロックに対応するｉｎｔの値として現在のシーケンス番号を登録する。
【０２３７】
一方、ライト先ブロックが既にイントマップテーブルに登録されている場合には、ディスクドライバ２３は、当該ライト先ブロックに対応するｉｎｔの値であるシーケンス番号＋１を当該ライト先ブロックに対応するｉｎｔの値として登録する。
【０２３８】
ステップＳ１３３の処理が実行されると、図７に示すステップＳ３４〜ステップＳ３７の処理に相当するステップＳ１３４〜ステップＳ１３７の処理が実行される。
【０２３９】
ところで、テーブル整理デーモン２５は、上記したようにイントマップテーブル１３２を定期的に参照する（ステップＳ１３８）。テーブル整理デーモン２５は、イントマップテーブル１３２に登録済みのブロック数が閾値以上であるか否かを判定する。
【０２４０】
ここで、テーブル整理デーモン２５によってイントマップテーブル１３２に登録済みのブロック数が閾値以上であると判定された場合を想定する。この場合には、テーブル整理デーモン２５は、イントマップテーブル１３２に登録されている古いシーケンス番号を持つｉｎｔの値をクリアする。
【０２４１】
次に、テーブル整理デーモン２５は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１において、クリアされたｉｎｔの値に対応するブロックを未登録とする（ステップＳ１３９）。これにより、テーブル整理デーモン２５は、例えばアクセス頻度の少ないブロックを未登録とすることで、第１のビットマップテーブル１３１に登録されている登録済みのブロック数を閾値以下にする。
【０２４２】
上記したように本実施形態においては、イントマップテーブルに登録されているブロック数が閾値以上になった場合には、当該登録されているブロックのうち、アクセス頻度の少ないブロックを第１のビットマップテーブル（及びイントマップテーブル）において未登録とすることで、例えばサーバ３０によってフェイルオーバが実行された場合であってもデータ破壊を防止するために別途必要となるディスク領域（ログ領域）のサイズを一定サイズ以下に抑えることが可能となる。
【０２４３】
なお、本実施形態においては、テーブル整理デーモン２５がサーバ２０に備えられるものとして説明したが、例えばテーブル整理デーモン２５がクラスタシステムを構成する複数のサーバの全てに備えられる構成であっても構わない。
【０２４４】
［第４の実施形態］
次に、図１７を参照して、本発明の第４の実施形態に係るクラスタシステムについて説明する。図１７は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。
【０２４５】
図１７に示すように、本実施形態に係るクラスタシステムにおいては、サーバ２０は、統計情報処理部２６を備える。
【０２４６】
本実施形態においては、サーバ２０のディスクドライバ２３は、アプリケーション２１からマスター領域１１に対するライト要求を入力した場合、当該ライト要求の対象となる領域に対応するブロック（ライト先ブロック）を統計情報処理部２６に通知する。ディスクドライバ２３は、マスター領域１１に対するライト要求を入力する度に当該ライト要求に係るライト先ブロックを通知する。
【０２４７】
統計情報処理部２６は、統計情報処理部２６は、ディスクドライバ２３からのライト先ブロックの通知に基づいて、例えばサーバ２０のマスター領域１１に対する書き込みのアクセスパターンを統計的に解析する。
【０２４８】
統計情報処理部２６は、アクセスパターンの解析結果に基づいて、例えば将来書き込みがなされる可能性の高いブロック（ライト先ブロック）を予測する。統計情報処理部２６は、サーバ２０に備えられているメモリ上に保持されている第１のビットマップテーブル及び共有ディスク１０に含まれるサーバ２０用領域１４に保持されている第１のビットマップテーブルに、予測されたライト先ブロックを予め登録する。
【０２４９】
次に、図１８を参照して、図１７に示すクラスタシステムを構成するサーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３及び統計情報処理部２６の処理について具体的に説明する。なお、共有ディスク１０に含まれるアクセス権管理テーブル１２には、サーバ２０にマスター領域１１に対するアクセス権が設定されているものとする。
【０２５０】
まず、前述した図７に示すステップＳ３１〜ステップＳ３４の処理に相当するステップＳ１４１〜ステップＳ１４４の処理が実行される。なお、ステップＳ１４１で入力されたＩ／Ｏ要求は、マスター領域１１（ＬＵ１）に対するライト要求であるものとする。
【０２５１】
次に、ディスクドライバ２３は、アプリケーション２１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）を統計情報処理部２６に通知する（ステップＳ１４５）。ディスクドライバ２３は、マスター領域１１に対するライト要求を入力する都度、ライト先ブロックを通知する。このとき、ディスクドライバ２３は、例えばライト先ブロックのブロック番号等を通知する。
【０２５２】
以下、ディスクドライバ２３では、前述した図７に示すステップＳ３５〜ステップＳ３７の処理に相当するステップＳ１４６〜ステップＳ１４８の処理が実行される。
【０２５３】
統計情報処理部２６は、ディスクドライバ２３から通知されたライト先ブロックに基づいて、サーバ２０のマスター領域１１に対する書き込みのアクセスパターンを統計的に解析する。
【０２５４】
統計情報処理部２６は、解析されたサーバ２０のアクセスパターンに基づいて、当該サーバ２０によって将来書き込みがなされる可能性の高いブロック（ライト先ブロック）を予測する。
【０２５５】
具体的には、ディスクドライバ２３によって通知されたライト先ブロックのブロック番号が例えばブロック番号１０、ブロック番号１１及びブロック番号１２と続いた場合、つまり、サーバ２０（のディスクドライバ２３）によってブロック番号１０のブロック、ブロック番号２０のブロック及びブロック番号３０のブロックに対して書き込み（ライト処理）が実行された場合には、統計情報処理部２６は、ブロック番号１３〜２０のブロックを将来書き込みがなされる可能性が高いブロックとして予測する。
【０２５６】
また、ディスクドライバ２３によって通知されたライト先ブロックのブロック番号が例えばブロック番号１０、ブロック番号２０及びブロック番号３０と続いた場合、統計情報処理部２６は、ブロック番号４０及び５０のブロックを将来書き込みがなされる可能性が高いブロックとして予測する。
【０２５７】
統計情報処理部２６は、サーバ２０に備えられるメモリ上に保持されている第1のビットマップテーブル１３１に、予測されたブロックを登録する（ステップＳ１４９）。
【０２５８】
また、統計情報処理部２６は、共有ディスクに含まれるサーバ２０用領域に保持されている第１のビットマップテーブル１３１に、予測されたブロックを登録する（ステップＳ１５０）。
【０２５９】
なお、上記したステップＳ１４９及びステップＳ１５０の処理は、Ｉ／Ｏ負荷の低い（軽い）時間帯等に実行される。
【０２６０】
上記したように本実施形態においては、サーバ２０のライト先ブロックに基づいて当該サーバ２０のアクセスパターンを解析し、当該アクセスパターンから将来書き込みがなされる可能性の高いブロックを予め第１のビットマップテーブルに登録しておくことで、将来ライト先ブロックを第１のビットマップテーブルに登録（更新）する際のＩ／Ｏによって発生する性能劣化の度合いを未然に削減することが可能となる。
【０２６１】
なお、本実施形態においては、統計情報処理部２６がサーバ２０に備えられるものとして説明したが、例えば統計情報処理部２６がクラスタシステムを構成する複数のサーバの全てに備えられる構成であっても構わない。［第５の実施形態］
次に、本発明の第５の実施形態に係るクラスタシステムについて説明する。本実施形態に係るクラスタシステムの構成については、前述した図１７に示すクラスタシステムの構成と同様であるので、図１７を用いて説明する。ここでは、前述した第４の実施形態に係るクラスタシステムと異なる部分について主に述べる。
【０２６２】
本実施形態においては、サーバ２０に備えられる統計情報処理部２６は、アプリケーション２１の起動（開始）直後からしばらくの間（予め定められた時間）サーバ２０のディスクドライバ２３からライト先ブロックの通知を受け取る。
【０２６３】
統計情報処理部２６は、受け取られたライト先ブロックの通知に基づいて、サーバ２０のマスター領域１１に対するアクセスパターンを統計的に解析する。統計情報処理部２６は、解析されたアクセスパターンに基づいて、アクセス頻度の高いライト先ブロックが登録されたビットマップテーブルのテンプレート（以下、単にテンプレートと表記）を作成する。作成されたテンプレートは、例えばサーバ２０上で記憶される。
【０２６４】
テンプレートは、例えばアプリケーション２１の起動時（サーバ２０の稼動時）に前述した第１のビットマップテーブルとして用いられる。
【０２６５】
また、サーバ２０のアプリケーション２１が停止された際の第１のビットマップテーブルを記憶しておき、当該記憶されている第１のビットマップテーブル及びテンプレートがマージされたものを、当該アプリケーション２１の起動時に第１のビットマップテーブルとして用いる構成であっても構わない。
【０２６６】
上記したように本実施形態においては、サーバ２０のライト先ブロックに基づいて当該サーバ２０のアクセスパターンを解析し、当該アクセスパターンに基づいてアクセス頻度の高いライト先ブロックが登録されたテンプレートを予め作成しておき、アプリケーション２１の起動時には当該テンプレートが第１のビットマップテーブルとして用いられる。これにより、本実施形態においては、アプリケーション２１の開始時に、ライト先ブロックを第１のビットマップテーブルに登録（更新）するためのＩ／Ｏによって発生する性能劣化の度合いを未然に削減することが可能となる。
【０２６７】
なお、本願発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。
【図面の簡単な説明】
【０２６８】
【図１】本発明の第１の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図２】フェイルオーバについて説明するための図。
【図３】図１に示すクラスタシステムの仕組みの概略について説明するための図。
【図４】ビットマップテーブルに登録される領域について説明するための図。
【図５】サーバ２０を稼動系サーバに移行する際の当該サーバ２０のクラスタソフト２２の処理手順を示すフローチャート。
【図６】サーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３の処理手順を示すフローチャート。
【図７】サーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３の処理について具体的に説明するための図。
【図８】サーバ３０においてフェイルオーバが実行される際の当該サーバ３０のクラスタソフト３２の処理手順を示すフローチャート。
【図９】フェイルオーバ直後のサーバ３０のディスクドライバ３３の処理手順を示すフローチャート。
【図１０】サーバ３０においてフェイルオーバが実行される際の当該サーバ３０のクラスタソフト３２及びディスクドライバ３３の処理について具体的に説明するための図。
【図１１】フェイルオーバが完了し、一定時間が経過した後のサーバ３０のクラスタソフト３２の処理手順を示すフローチャート。
【図１２】フェイルオーバが完了し、一定時間が経過した後のサーバ３０のクラスタソフト３２及びディスクドライバ３３の処理について具体的に説明するための図。
【図１３】本発明の第２の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図１４】サーバ４０においてフェイルオーバが実行される際の当該サーバ４０のクラスタソフト４２及びディスクドライバ４３の処理について具体的に説明するための図。
【図１５】本発明の第３の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図１６】図１５に示すクラスタシステムを構成するサーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３及びテーブル整理デーモンの処理について具体的に説明するための図。
【図１７】本発明の第４の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図１８】図１７に示すクラスタシステムを構成するサーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３及び統計情報処理部２６の処理について具体的に説明するための図。
【符号の説明】
【０２６９】
１０…共有ディスク（記憶装置）、１１…マスター領域（第１の領域）、１２…アクセス権管理テーブル、１３…サーバ２０用領域、１４…サーバ３０用領域、１５…サーバ４０用領域、２０，３０，４０…サーバ、２１，３１，４１…アプリケーション、２２，３２，４２…クラスタソフト、２３，３３，４３…ディスクドライバ、２４，３４，４４…アクセス権ポーリングデーモン、２５…テーブル整理デーモン、２６…統計情報処理部、５０…クライアント端末、１３１…第１のビットマップテーブル（第１の計算機用テーブル）、１３２…イントマップテーブル、１４１…第２のビットマップテーブル（第２の計算機用テーブル）、１４２，１５２…ログ領域、１５１…第４のビットマップテーブル、１５３…第３のビットマップテーブル。
【技術分野】
【０００１】
本発明は、複数の計算機間でフェイルオーバが実行される計算機システムに関する。
【背景技術】
【０００２】
近年、例えば複数の計算機（サーバ）及び少なくとも１つ以上のストレージ装置から構成されるクラスタシステム（計算機システム）が知られている。クラスタシステムを構成する複数のサーバには、例えば稼動系サーバ及び待機系サーバが含まれる。
【０００３】
このようなクラスタシステムでは、稼動系サーバ及び待機系サーバ間には通信路が確立されており、互いに通信可能である。
【０００４】
クラスタシステムにおいては、まず、稼動系サーバで例えばアプリケーションが開始される。稼動系サーバでアプリケーションが実行されている際、当該稼動系サーバと待機系サーバとの間（通信路経由）で、所定のパケット（以下、ハートビートと表記）を交換し続ける。
【０００５】
これにより、例えば稼動系サーバからハートビートが送信されなくなると、待機系サーバではハートビートの断絶が検出される。この場合、例えば稼動系サーバが故障等の発生によりダウンしたものとして、待機系サーバでは、当該稼動系サーバで実行されていたアプリケーションを起動する。これにより、アプリケーション処理を継続させることができる（フェイルオーバ）。
【０００６】
ここで、稼動系サーバからのハートビートが断絶する理由には、上記した稼動系サーバの故障以外に、例えば稼動系サーバ及び待機系サーバ間の通信路の障害または稼動系サーバでＣＰＵ高負荷による一時的なスローダウンの発生等がある。
【０００７】
上記したように稼動系サーバが故障等によりダウンすることによってハートビートが断絶した場合には、単純に待機系サーバにフェイルオーバすればよい。しかしながら、例えば稼動系サーバ及び待機系サーバ間の通信路の障害または稼動系サーバでＣＰＵ高負荷による一時的なスローダウンの発生等によってハートビートが断絶した場合には、稼動系サーバでは処理が継続されるため、単にフェイルオーバすると問題がある。
【０００８】
例えば複数台のサーバ（稼動系サーバ及び待機系サーバ）が同一の共有ディスクに接続された状態でクラスタ構成を組む場合において、上記した稼動系サーバ及び待機系サーバ間の通信路の障害または稼動系サーバでＣＰＵ高負荷による一時的なスローダウンの発生が原因でハートビートの断絶が検出され、フェイルオーバが実行された場合を想定する。
【０００９】
この場合、上記したように稼動系サーバ及び待機系サーバの両方が稼動している状態となるため、例えば稼動系サーバ及び待機系サーバの両方が共有ディスク内の同一データ領域に書き込みを行う可能性がある。これにより、例えば共有ディスク内のデータの整合性が失われ、当該データが破壊されることがある。
【００１０】
そこで、上記したようなデータ破壊を防ぐための技術として、例えばＳＣＳＩ（Small Computer System Interface）仕様として定義されているリザーブ排他機能を使用する技術が知られている。この技術によれば、例えば１つのＬＵ（Logical Unit）につきＩ／Ｏ（readまたはwrite）を発行可能なサーバを１つに絞る手法が利用される。すなわち、待機系サーバにフェイルオーバする際、待機系サーバが共有ディスク内の対象ＬＵをリザーブし、稼動系サーバがそれ以上対象ＬＵに書き込みを行うのを防いでからアプリケーションが起動される。
【００１１】
このような技術に関連して、クラスタシステムの各ノード間の通信路の故障によってスプリットブレインの状態が発生した場合において、外部記憶装置内の排他制御を使用して、処理要求が競合しないように共有のデータ資源を保護する技術（以下、先行技術１と表記）が開示されている（例えば、特許文献１を参照）。この先行技術１によれば、例えばストレージのファームウェア内の排他制御部を用い、クラスタシステムの調停機構と組み合わせてＩ／Ｏアクセス制御を実施している。
【００１２】
また、共有ディスク内に例えばＱＵＯＲＵＭと呼ばれる特殊なＬＵを用意してアプリケーションデータのマスター領域へのコミット権を管理し、ソフトウェア排他を行う技術（以下、先行技術２と表記）がある。この先行技術２によれば、例えばディスク上にサーバ毎のキャッシュ領域を用意してデータの書き込みを２段階とし、フェイルオーバ後に元稼動系が２段階目の書き込みを行う先が小領域に限定されることを利用して、フェイルオーバ後にマスター領域から当該小領域が外される、つまり、代替の保存先領域が設けられる。
【特許文献１】特開２００５−２５２８９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、上記した先行技術１においてはＳＣＳＩリザーブ排他という共有ディスク装置の実装に依存した機能を利用するため、例えばリザーブ排他が可能か否かは共有ディスク装置やそのマルチパスドライバの実装に依存することになる。つまり、例えば新しい共有ディスク装置やそのマルチパスドライバに対応するには毎回検証が必要となる。
【００１４】
また、上記した先行技術１では、例えば共有ディスク装置やそのマルチパスドライバによって、細かな制限事項が付加されている場合がある。例えばある共有ディスク装置では、ディスクＩ／Ｏの物理的なパスが多重化されている環境で当該パスに障害（片パス障害）が起きると、共有ディスクのリザーブが維持されない状態に陥る。この場合には、共有ディスクにおいて例えば他のサーバ（元稼動系サーバ）のアクセスを排他することはできない。
【００１５】
また、先行技術１においては、共有ディスクをリザーブする際には上記したＬＵ単位でしかリザーブすることができず、例えばパーティション単位または当該パーティション群からなる論理ボリューム単位で運用することはできない。
【００１６】
更に、先行技術１においては、例えば同一バスに接続された別のマシンをリブートするとバスリセットによりリザーブが外れる場合がある。また、多サービス構成でスプリットブレインすると、リザーブを奪うためのバスリセットが飛び交うため排他しきれない場合がある。このように、先行技術１では、リザーブを確実に維持することができないため、他のサーバからのアクセスを排他することができない時間が生じる。
【００１７】
上記した先行技術２においては、アプリケーションのデータは当該先行技術２の仕組みに対応したドライバ経由でないとアクセスすることはできない。つまり、データがストレージ間でバックアップされた場合に当該バックアップ先でデータを読み出すには、例えばキャッシュ領域のデータをマスター領域へ反映する機能を有するような別途用意した特殊なコマンドが必要となる。また、先行技術２の仕組みに対応したフィルタドライバをインストールする必要もある。
【００１８】
また、先行技術２では、例えばクラスタシステムを構成するサーバが３台以上の場合、フェイルオーバを繰り返すとマスターデータが様々な領域に分散するため、更に複雑な実装が必要となる。
【００１９】
そこで、本発明の目的は、複数のサーバ間でフェイルオーバが発生した場合に、当該複数のサーバから共有ディスクにアクセスされることによってデータが破壊されることを防止する計算機システムを提供することにある。
【課題を解決するための手段】
【００２０】
本発明の１つの態様によれば、第１の計算機と、当該第１の計算機と接続され、当該第１の計算機から定期的に所定のパケットを受信する第２の計算機と、前記第１の計算機及び前記第２の計算機と接続されている記憶装置とを備える計算機システムにおいて、前記記憶装置は、前記第１の計算機及び第２の計算機からアクセスされる第１の領域と、前記第１の領域に対するアクセスの許可を示すアクセス権が前記第１の計算機に設定されているアクセス権管理テーブルと、前記第１の領域とは異なる第２の領域と、前記第１の領域に対して前記第１の計算機によってライトアクセスされた際に、当該ライトアクセス先となる領域を登録するための第１の計算機用テーブルとを含み、前記第１の計算機は、当該第１の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、当該ライトアクセス先となる領域を前記記憶装置に含まれる第１の計算機用テーブルに登録するアクセス先登録手段を含み、前記第２の計算機は、前記第１の計算機からの前記所定のパケットの断絶が検出された場合に、前記記憶装置に含まれるアクセス権管理テーブルにおいて前記第２の計算機に前記アクセス権を設定する設定手段と、前記第１の計算機用テーブルに登録されている領域に格納されているデータを、前記第２の領域にコピーするコピー処理手段と、前記第２の計算機にアクセス権が設定された後に、前記記憶装置に含まれる第１の領域にアクセスする際に、当該アクセス先となる領域が前記第１の計算機用テーブルに登録されているかを判定する判定手段と、前記第１の計算機用テーブルに登録されていると判定された場合、前記第１の計算機用テーブルに登録されている領域に格納されているデータがコピーされた前記第２の領域に対してアクセスするアクセス手段とを含むことを特徴とする計算機システムが提供される。
【発明の効果】
【００２１】
本発明によれば、複数のサーバ間でフェイルオーバが発生した場合に、当該複数のサーバから共有ディスクにアクセスされることによってデータが破壊されることを防止することが可能となる。
【発明を実施するための最良の形態】
【００２２】
以下、図面を参照して、本発明の各実施形態について説明する。
【００２３】
［第１の実施形態］
図１は、本発明の第１の実施形態に係るクラスタシステム（計算機システム）の機能構成を示すブロック図である。
【００２４】
図１に示すように、本実施形態に係るクラスタシステムは、複数のサーバ（計算機）及び共有ディスク１０を備える。複数のサーバは、サーバ（第１の計算機）２０及びサーバ（第２の計算機）３０を含む。
【００２５】
また、共有ディスク１０及びサーバ２０は、例えばＦＣ（Fibre Channel）ケーブルで接続されている。同様に、共有ディスク１０及びサーバ３０は、ＦＣケーブルで接続されている。サーバ２０及びサーバ３０は、例えば２本の通信路を介して通信可能に接続されている。以下、サーバ２０は稼動系サーバ、サーバ３０は待機系サーバであるものとして説明する。
【００２６】
共有ディスク１０は、マスター領域（第１の領域）１１及びＱＵＯＲＵＭ領域を含む。マスター領域１１は、上記したサーバ２０及びサーバ３０によってアクセスされる共有領域である。ここでは、マスター領域１１は、共有ディスク１０が有する論理ユニット（ＬＵ：Logical Unit）、例えばＬＵ１に含まれるものとする。
【００２７】
ＱＵＯＲＵＭ領域には、アクセス権管理テーブル１２が含まれる。このアクセス権管理テーブル１２には、クラスタシステムを構成するサーバ２０及びサーバ３０のそれぞれについて、共有ディスク１０のマスター領域１１へのアクセスの許可または不許可が設定される。図１に示すように、アクセス権管理テーブル１２において例えばＬＵ１に対応付けてサーバ２０に「○」、サーバ３０に「×」が設定されている場合には、サーバ２０のマスター領域１１に対するアクセスが許可され、サーバ３０のマスター領域１１に対するアクセスは許可されていないことを示す。つまり、図１に示す例では、アクセス権管理テーブル１２には、マスター領域１１に対するアクセスの許可を示すアクセス権がサーバ２０に設定されている。
【００２８】
また、ＱＵＯＲＵＭ領域には、サーバ２０用のデータ領域（以下、サーバ２０用領域と表記）１３及びサーバ３０用のデータ領域（以下、サーバ３０用データ領域と表記）１４が含まれる。
【００２９】
本実施形態においては、上記したマスター領域１１及びＱＵＯＲＵＭ領域を異なるＬＵに分けてもよいし、異なるパーティションに分けてもよい。
【００３０】
サーバ２０は、当該サーバ２０上で動作するアプリケーション２１、クラスタソフト２２、ディスクドライバ２３及びアクセス権ポーリングデーモン２４を備える。
【００３１】
稼動系サーバであるサーバ２０では、アプリケーション２１が実行される。このようにサーバ２０でアプリケーション２１が実行されている間には、稼動系サーバであるサーバ２０に備えられるクラスタソフト２２及び待機系サーバであるサーバ３０に備えられるクラスタソフト３２の間で通信路を経由してハートビートと呼ばれる所定のパケットを定期的に交換し続け、互いの生存を通知し合う。
【００３２】
ディスクドライバ２３は、上位（例えば、アプリケーション２１）からのＩ／Ｏ（リードまたはライト）要求に基づいて、共有ディスク１０に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ２３は、上記した共有ディスク１０に含まれるアクセス権管理テーブル１２を参照して処理を実行する。
【００３３】
また、ディスクドライバ２３は、例えば共有ディスク１０に含まれるマスター領域１１に対してライト処理（ライトアクセス）を実行する際に、当該ライト（アクセス）先となる領域に対応するブロック（ライト先ブロック）をサーバ２０用のビットマップ（bitmap）テーブル（第１の計算機用テーブル）に登録する。つまり、ディスクドライバ２３は、サーバ２０用のビットマップテーブル（以下、第１のビットマップテーブルと表記）のライト先ブロックにｂｉｔを立てることによって、ライト先ブロックを登録する。第１のビットマップテーブルにおいては、マスター領域１１に含まれる領域の各々に対応する複数のブロックを登録することができ、例えば１ブロックが１ＭＢに対応する。以下に説明する第１のビットマップテーブル以外のビットマップテーブルについても同様である。
【００３４】
この第１のビットマップテーブルは、例えばサーバ２０に備えられるメモリ（図示せず）にその領域が確保される。また、第１のビットマップテーブルは、上記した共有ディスク１０のサーバ２０用領域に保持される。
【００３５】
アクセス権ポーリングデーモン２４は、共有ディスク１０に含まれるアクセス権管理テーブル１２を定期的（例えば、３０秒毎）に参照する。アクセス権ポーリングデーモン２４は、サーバ２０によるアクセスが許可されている（つまり、サーバ２０にアクセス権が設定されている）場合、例えば現在時間に予め定められた時間（例えば、６０秒）を加えた有効期限（マスター領域１１に対するアクセス権の有効期限）を設定し、この有効期限をサーバ２０のディスクドライバ２３に通知する。
【００３６】
サーバ３０は、当該サーバ３０上で動作するアプリケーション３１、クラスタソフト３２、ディスクドライバ３３及びアクセス権ポーリングデーモン３４を備える。
【００３７】
上記したように稼動系サーバであるサーバ２０に備えられるクラスタソフト２２及び待機系サーバであるサーバ３０に備えられるクラスタソフト３２の間では通信路を経由してハートビートと呼ばれる所定のパケットを交換し続け、互いの生存を通知し合う。
【００３８】
ここで、例えば待機系サーバであるサーバ３０のクラスタソフト３２によって稼動系サーバであるサーバ２０のクラスタソフト２２からのハートビートの断絶（クラスタソフト２２からのハートビートが受信されなくなること）が検出された場合を想定する。この場合、サーバ３０上ではサーバ２０で起動されていたアプリケーション２１の処理を継続するためにアプリケーション３１が起動される。これにより、サーバ３０でフェイルオーバが実行される。
【００３９】
なお、ハートビートが断絶する理由としては、例えば稼動系サーバの故障（ダウン）、サーバ２０及びサーバ３０間の通信路の障害またはサーバ２０でＣＰＵ高負荷等による一時的なスローダウンの発生等がある。
【００４０】
クラスタソフト３２は、クラスタソフト２２からのハートビートの断絶が検出された場合、共有ディスク１０に含まれるアクセス権管理テーブル１２に対してマスター領域１１に対するアクセス権をサーバ３０に変更（設定）する。
【００４１】
クラスタソフト３２は、上記した第１のビットマップテーブルに登録されているブロックに対応するマスター領域１１（に含まれる領域）に格納されているデータを、当該マスター領域１１とは異なる共有ディスク１０上の別の領域であるログ領域（第２の領域）にコピーする。
【００４２】
クラスタソフト３２は、サーバ２０のマスター領域１１に対するアクセス権の有効期限が確実に切れる時刻まで待機し、当該時刻後にアプリケーション３１を起動する。
【００４３】
また、クラスタソフト３２は、上記したフェイルオーバの完了後、一定時間が経過した場合に、上記したログ領域に格納されているデータをマスター領域１１の対応する領域にコピーする。クラスタソフト３２は、このコピー処理が完了すると、ログ領域を削除する。
【００４４】
ディスクドライバ３３は、上位（例えば、アプリケーション３１）からのＩ／Ｏ要求に基づいて、共有ディスク１０に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ３３は、Ｉ／Ｏ要求が上記した第１のビットマップテーブルに登録されているブロック（に対応する領域）に対する要求である場合には、上記したログ領域に対して当該要求に応じた処理（アクセス）を実行する。
【００４５】
また、ディスクドライバ３３は、上記したディスクドライバ２３と同様に、例えば共有ディスク１０に含まれるマスター領域１１に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック（ライト先ブロック）をサーバ３０用のビットマップテーブル（第２の計算機用テーブル）に登録する。このサーバ３０用のビットマップテーブル（以下、第２のビットマップテーブル）は、例えばサーバ３０に備えられるメモリ（図示せず）上にその領域が確保される。また、第２のビットマップテーブルは、上記した共有ディスク１０のサーバ３０用領域１４に保持される。
【００４６】
アクセス権ポーリングデーモン３４は、上記したサーバ２０のアクセス権ポーリングデーモン２４と同様であるのでその詳しい説明は省略する。
【００４７】
次に、図２を参照して、上記したフェイルオーバについて説明する。ここでは、サーバ２０は稼動系サーバ、サーバ３０は待機系サーバとして動作しているものとする。
【００４８】
ここで、例えば稼動系サーバであるサーバ２０でＣＰＵ高負荷による一時的なスローダウンが発生した場合を想定する。
【００４９】
この場合、待機系サーバであるサーバ３０（のクラスタソフト３３）は稼動系サーバ２０（のクラスタソフト２３）からのハートビートの断絶を検出する（ステップＳ１）。
【００５０】
次に、サーバ３０のクラスタソフト３３は、共有ディスク１０に含まれるアクセス権管理テーブル１２に対してマスター領域１１に対するアクセス権をサーバ３０に変更する（ステップＳ２）。
【００５１】
このとき、サーバ２０のアクセス権ポーリングデーモン２４は、アクセス権管理テーブル１２においてアクセス権がサーバ２０からサーバ３０に変更されたため、サーバ２０のマスター領域１１に対するアクセス権の有効期限を更新しない。
【００５２】
上記したステップＳ２の処理が実行されると、サーバ３０のクラスタソフト３３は、サーバ２０のアクセス権ポーリングデーモン２４によって設定されたアクセス権の有効期限切れまで待機する。このアクセス権の有効期限が切れた後、サーバ３０のクラスタソフト３３はアプリケーション３１を起動し、サーバ３０によるマスター領域１１に対するアクセスが開始される。
【００５３】
ここで、図２を参照して、フェイルオーバ前後にサーバ２０においてなされるライト要求（ライト命令）について説明する。このライト要求は、例えばサーバ２０と接続されたクライアント端末５０からの要求に基づいて、サーバ２０のアプリケーション２１からディスクドライバ２３に送信される。
【００５４】
ディスクドライバ２３は、上記したサーバ２０のマスター領域１１に対するアクセス権の有効期限（サーバ２０の有効期限）内においては、アプリケーション２１から送信されるライト要求を含むＩ／Ｏ要求を共有ディスク１０に送信する。また、ディスクドライバ２３は、サーバ２０の有効期限内においては、例えば共有ディスク１０からのＩ／Ｏ要求に対する応答をアプリケーション２１に返す。つまり、ディスクドライバ２３は、サーバ２０の有効期限内においては、Ｉ／Ｏ要求及び応答を通過させる機能を有する。
【００５５】
一方、サーバ２０の有効期限外においては、アプリケーション２１からＩ／Ｏ要求を受けた場合及び共有ディスク１０から応答を受けた場合にはエラーが当該アプリケーション２１に対して返される（エラーリターン）。
【００５６】
ここで、図２では、例えば上記したサーバ２０の有効期限が切れた時点でのアプリケーション２１によって送信されたＩ／Ｏ要求（ここでは、ライト要求）の状態を表す。ライト要求の状態は、図２に示すようにライト要求２１１〜２１４に大別される。
【００５７】
例えばライト要求２１１は、サーバ２０の有効期限が切れた時点で既に正常に処理されているライト要求である。
【００５８】
ライト要求２１２は、サーバ２０の有効期限が切れた時点で既にマスター領域１１にライト処理が実行されているが、共有ディスク１０からの応答がディスクドライバ２３を通過していないのでサーバ２０の有効期限切れによりエラーリターンとなるライト要求である。
【００５９】
ライト要求２１３は、サーバ２０の有効期限が切れた時点でマスター領域１１にはライト処理が実行されていないが、ディスクドライバ２３を通過している。よって、ライト要求２１３は、サーバ２０の有効期限が切れた後にマスター領域１１にライト処理が実行されるが、上記したライト要求２１２と同様に共有ディスク１０からの応答がディスクドライバ２３を通過していないのでサーバ２０の有効期限切れによりエラーリターンとなるライト要求である。
【００６０】
ライト要求２１４は、サーバ２０の有効期限が切れた時点で当該ライト要求２１４がディスクドライバ２３を通過していないので、マスター領域１１に対してライト処理が実行されることなくエラーリターンとなるライト要求である。
【００６１】
上記したようにすることでフェイルオーバを境に元稼動系サーバ（サーバ２０）からのライト要求は必ずエラーとなる仕組みを実現できる。この仕組みは、上記したようにサーバ２０がスローダウンしていたとしても実現される。
【００６２】
ところで、上記したライト要求２１３においては、フェイルオーバ後に当該ライト要求２１３に応じたライト処理が実行されるため、元稼動系サーバであるサーバ２０と元待機系（現稼動系）サーバであるサーバ３０との両系書き込みによるデータ破壊のリスクがある。
【００６３】
図２に示すライト要求２１３の状態でサーバ２０が上記したようにＣＰＵ高負荷による一時的なスローダウンが発生した場合を想定する。この場合、例えばライト要求２１３によるライト処理の対象となる領域と同一の領域に対してサーバ３０によるライト処理がされた後にサーバ２０のスローダウンが回復した場合には、当該サーバ３０によるライト処理された領域がライト要求２１３によって上塗り（上書き）されることになる。これにより、データ破壊が生じる場合がある。
【００６４】
また、例えばライト要求２１３によるライト処理の対象となる領域と同一の領域に対してサーバ３０によるリード処理がされた場合であっても、その後にライト要求２１３によるライト処理が実行された場合には、サーバ３０が再度リード処理を同一の領域に対して実行したにもかかわらずリード結果の不一致という事態が生じる場合がある。
【００６５】
そこで、本実施形態に係るクラスタシステムにおいては、例えばライト要求２１３により上塗りされ得る領域（小領域）とそれ以外の領域を上記した別途設けられたビットマップテーブル（例えば、第１のビットマップテーブル）を用いて常に区分する。これにより、本実施形態においては、フェイルオーバ発生後から安定状態に落ち着くまでの間、上記した小領域の複製を持つことで、スプリットブレイン時にディスクデータの破壊を防ぎつつフェイルオーバさせる。
【００６６】
次に、図３及び図４を参照して、図１に示すクラスタシステムの仕組みの概略について説明する。
【００６７】
まず、図３に示すフェイルオーバ前の安定期（通常運転期）においては、稼動系サーバであるサーバ２０においてアプリケーション２１によって送信されるＩ／Ｏ要求に応じてライト処理またはリード処理がマスター領域１１に対して実行される。
【００６８】
ここで、アプリケーション２１によって送信されるＩ／Ｏ要求がライト要求である場合には、当該ライト要求によってライト処理される領域（ライト先ブロック）がサーバ２０用のビットマップテーブル（第１のビットマップテーブル）１３１に登録される。なお、この第１のビットマップテーブル１３１は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている。
【００６９】
図４に示すように、安定期（通常運転期）においては、マスター領域１１（図４では、領域Ｂと表記）には、稼動系サーバであるサーバ２０がライトし得る領域Ｂ１及び当該サーバ２０がライトしない領域Ｂ２が含まれるが、第１のビットマップテーブル１３１には稼動系サーバであるサーバ２０がライトし得る領域Ｂ１が登録される。
【００７０】
次に、例えばサーバ２０からのハートビートの断絶が検出されることにより、待機系サーバであるサーバ３０がフェイルオーバを実行した場合を想定する。
【００７１】
この場合、図３に示すようにフェイルオーバ直後においては、共有ディスク１０のサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１がサーバ３０用領域１４にコピーされる。
【００７２】
また、コピーされた第１のビットマップテーブルに登録されているブロック（に対応するマスター領域１１の領域）に格納されているデータが当該マスター領域１１とは異なる共有ディスク１０上の別領域であるログ領域にコピーされる。なお、ログ領域は、例えばサーバ３０用領域１４に確保される。
【００７３】
フェイルオーバ直後においては、元稼動系サーバであるサーバ２０において起動されていたアプリケーション２１の処理を継続するために起動された現稼動系サーバであるサーバ３０のアプリケーション３１によって送信されるＩ／Ｏ要求に応じてライト処理またはリード処理がマスター領域１１に対して実行される。
【００７４】
ここで、アプリケーション３１によって送信されるＩ／Ｏ要求がライト要求である場合には、当該ライト要求に応じてライト先ブロックがサーバ３０用のビットマップテーブル（第２のビットマップテーブル）１４１に登録される。なお、この第２のビットマップテーブル１４１は、共有ディスク１０に含まれるサーバ３０用領域１４に保持されている。
【００７５】
また、アプリケーション３１によって送信されるＩ／Ｏ要求が第１のビットマップテーブル１３１に登録されているブロックに対応する領域に対する要求である場合、当該Ｉ／Ｏ要求に応じた処理はログ領域に対して実行される。
【００７６】
図４に示すように、フェイルオーバ直後においては、マスター領域１１には、元稼動系サーバであるサーバ２０のライト要求（例えば、上記した図２におけるライト要求２１３）により上塗りされ得る領域Ａ（小領域）及びそれ以外の領域Ｂが含まれる。領域Ｂには、現稼動系サーバであるサーバ３０がライトし得る領域Ｂ１及び当該サーバ３０がライトしない領域Ｂ２が含まれる。ここで、領域Ａは、上記した図３に示す第１のビットマップテーブル１３１に登録されているブロックに対応する領域である。また、領域Ｂ１は、第２のビットマップテーブル１４１に登録されているブロックに対応する領域である。
【００７７】
また、マスター領域１１とは別領域である領域Ｌは、上記した領域Ａ（に格納されているデータ）がコピーされたログ領域である。この領域Ｌには、領域Ａに格納されているデータがコピーされる。
【００７８】
次に、フェイルオーバの後、一定時間が経過した場合を想定する。この場合には、共有ディスク１０、サーバ２０及びサーバ３０から構成されるクラスタシステムは安定期（片肺運転）となる。この一定時間とは、予め設定された例えば元稼動系サーバであるサーバ２０におけるＣＰＵ高負荷による一時的なスローダウンが回復するために十分な時間である。
【００７９】
図３に示す安定期（片肺運転）においては、上記したログ領域に格納されているデータが当該ログ領域に対応するマスター領域１１の領域（第１のビットマップテーブル１３１に登録されているブロックに対応する領域Ａ）にコピーされる。
【００８０】
また、サーバ３０用領域１４に保持されている第１のビットマップテーブル１３１が当該サーバ３０用領域から削除される。
【００８１】
また、安定期（片肺運転）時では、上記したフェイルオーバ直後と同様に、サーバ３０のアプリケーション３１によって送信されるＩ／Ｏ要求がライト要求である場合には、当該ライト要求に応じてライト先ブロックがサーバ３０用のビットマップテーブル（第２のビットマップテーブル）１４１に登録される。
【００８２】
上記したように、本実施形態においては、フェイルオーバ直後から安定期（片肺運転）までは元稼動系サーバ（サーバ２０）により上塗りされ得る領域Ａ、マスター領域１１における当該領域Ａ以外の領域Ｂ及びマスター領域１１とは別領域である領域Ｌ（ログ領域）の３つに分割されて管理される。
【００８３】
次に、図５のフローチャートを参照して、例えばサーバ２０を稼動系サーバに移行する際の当該サーバ２０のクラスタソフト２２の処理手順について説明する。
【００８４】
ここでは、初期状態として、サーバ２０及びサーバ３０間ではクラスタソフト同士（クラスタソフト２２及び３２）がハートビートを交換し、互いの生存が確認できているものとする。また、サーバ２０及びサーバ３０共に、ＱＵＯＲＵＭ用領域とマスター領域１１が上位層から見えない（ディスクドライバ２３及び３３がフェンスオフ）状態であり、アプリケーション（アプリケーション２１及び３１）は起動されていないものとする。
【００８５】
まず、サーバ２０のクラスタソフト２２は、例えばユーザの操作に応じてサーバ２０を稼動系サーバにする旨の通知をクライアント端末から受け取る（ステップＳ１１）。
【００８６】
次に、クラスタソフト２２は、共有ディスク１０に含まれるアクセス権管理テーブル１２を変更する（ステップＳ１２）。この場合、クラスタソフト２２は、アクセス権管理テーブル１２においてマスター領域１１に対するアクセス権をサーバ２０に設定する。
【００８７】
クラスタソフト２２は、サーバ２０のディスクドライバ２３に当該サーバ２０が稼動系サーバとなった旨を通知する（ステップＳ１３）。このとき、ディスクドライバ２３は、上位層からマスター領域１１が見える状態にする。
【００８８】
クラスタソフト２２は、サーバ２０のアプリケーション２１を起動する（ステップＳ１４）。
【００８９】
次に、図６のフローチャートを参照して、サーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３の処理手順について説明する。
【００９０】
まず、ディスクドライバ２３は、上位（アプリケーション２１）からのＩ／Ｏ要求を入力する（ステップＳ２１）。
【００９１】
次に、ディスクドライバ２３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、アクセス権管理テーブル１２にサーバ２０のアクセス権（サーバ２０のマスター領域１１に対するアクセス権）が設定されているか否かを判定する。つまり、ディスクドライバ２３は、サーバ２０にマスター領域１１に対するアクセス権があるか否かを判定する（ステップＳ２２）。
【００９２】
サーバ２０にアクセス権があると判定された場合（ステップＳ２２のＹＥＳ）、ディスクドライバ２３は、入力されたＩ／Ｏ要求がマスター領域１１へのライト要求であるか否かを判定する（ステップＳ２３）。
【００９３】
マスター領域１１へのライト要求であると判定された場合（ステップＳ２３のＹＥＳ）、ディスクドライバ２３は、サーバ２０に備えられるメモリ上に保持されている第１のビットマップテーブルを参照する。ディスクドライバ２３は、ライト要求の対象となる領域に対応するブロック（ライト先ブロック）が第１のビットマップテーブルに登録済みであるか否かを判定する（ステップＳ２４）。
【００９４】
ライト先ブロックが第１のビットマップテーブルに登録済みでないと判定された場合（ステップＳ２４のＮＯ）、ディスクドライバ２３は、当該ライト先ブロックを当該第１のビットマップテーブルに登録する（ステップＳ２５）。この場合、ディスクドライバ２３は、サーバ２０に備えられるメモリ上に保持されている第１のビットマップテーブル及び上記した共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブルにライト先ブロックを登録する。
【００９５】
次に、ディスクドライバ２３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、サーバ２０にマスター領域１１に対するアクセス権があるか否かを判定する（ステップＳ２６）。
【００９６】
サーバ２０にアクセス権があると判定された場合（ステップＳ２６のＹＥＳ）、ディスクドライバ２３は、マスター領域１１へのライト処理を実行する（ステップ２７）。
【００９７】
ディスクドライバ２３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、サーバ２０にアクセス権があるか否かを判定する（ステップＳ２８）。
【００９８】
サーバ２０にアクセス権があると判定された場合（ステップＳ２８のＹＥＳ）、ディスクドライバ２３は、例えば正常にライト処理が実行された旨の処理結果を上位へリターンする（ステップＳ２９）。
【００９９】
一方、上記したステップＳ２２、Ｓ２６及びＳ２８においてサーバ２０にアクセス権がない、つまり、アクセス権ポーリングデーモン２４から通知される有効期限が切れていると判定された場合には、エラーを上位へリターンする（ステップＳ３０）。
【０１００】
また、ステップＳ２３においてＩ／Ｏ要求がマスター領域１１へのライト要求でない、つまり、例えばマスター領域１１へのリード要求等であると判定された場合、下位の共有ディスク１０にそのままＩ／Ｏ要求が渡され、ステップＳ２８の処理が実行される。
【０１０１】
また、ステップＳ２４においてライト先ブロックが第１のビットマップテーブルに登録済みであると判定された場合、ステップＳ２６の処理が実行される。
【０１０２】
ここで、図７を参照して、サーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３の処理について具体的に説明する。なお、共有ディスク１０に含まれるアクセス権管理テーブル１２には、マスター領域１１に対するアクセス権がサーバ２０に設定されているものとする。
【０１０３】
まず、ディスクドライバ２３は、アプリケーション２１からのＩ／Ｏ要求を入力する（ステップＳ３１）。ここでは、アプリケーション２１からのＩ／Ｏ要求は、マスター領域１１（ＬＵ１）に対するライト要求であるものとして説明する。
【０１０４】
次に、ディスクドライバ２３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、サーバ２０にアクセス権があるか否かを判定する（ステップＳ３２）。上記したようにアクセス権管理テーブル１２にはサーバ２０のアクセス権が設定されているため、ここではサーバ２０にアクセス権があると判定される。
【０１０５】
ディスクドライバ２３は、アプリケーション２１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）がサーバ２０に備えられたメモリ上に保持されている第１のビットマップテーブル１３１に登録済みであるか否かを判定する。なお、図７に示すように、第１のビットマップテーブル１３１は、上記したサーバ２０に備えられたメモリ以外に、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている。
【０１０６】
ここで、ライト先ブロックが第１のビットマップテーブル１３１に登録済みでない場合を想定する。この場合、ディスクドライバ２３は、サーバ２０に備えられたメモリ上に保持されている第１のビットマップテーブル１３１にライト先ブロックを登録する（ステップＳ３３）。
【０１０７】
また、ディスクドライバ２３は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１にライト先ブロックを登録する（ステップＳ３４）。
【０１０８】
次に、ディスクドライバ２３は、上記したステップＳ３２に相当するステップＳ３５の処理を実行する。つまり、ディスクドライバ２３は、サーバ２０にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル１２は変更されておらず、サーバ２０にアクセス権があると判定されたものとする。
【０１０９】
ディスクドライバ２３は、アプリケーション２１から入力されたライト要求に応じてマスター領域１１に対するライト処理を実行する（ステップＳ３６）。
【０１１０】
ディスクドライバ２３は、上記したステップＳ３２（またはステップＳ３５）の処理に相当するステップＳ３７の処理を実行する。ここで、サーバ２０にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション２１に返される。
【０１１１】
一方、上記したステップＳ３２、Ｓ３５及びＳ３７においてサーバ２０にアクセス権がないと判定された場合には、アプリケーション２１にエラーが返される。このステップＳ３２、Ｓ３５及びＳ３７においては、上記したようにサーバ３０（のクラスタソフト３２）によってアクセス権管理テーブル１２が変更された場合に、サーバ２０にアクセス権がないと判定される。
【０１１２】
次に、図８のフローチャートを参照して、サーバ３０においてフェイルオーバが実行される際の当該サーバ３０のクラスタソフト３２の処理手順について説明する。
【０１１３】
ここでは、サーバ２０が稼動系サーバ、サーバ３０が待機系サーバであるものとして説明する。
【０１１４】
まず、待機系サーバであるサーバ３０のクラスタソフト３２は、稼動系サーバであるサーバ２０のクラスタソフト２２からのハートビートの断絶を検出する（ステップＳ４１）。このハートビートの断絶は、例えば稼動系サーバであるサーバ２０の故障によるダウンの他、例えばサーバ２０及びサーバ３０間の通信路の障害、またはサーバ２０でＣＰＵ高負荷等による一時的なスローダウン等により発生し得る。
【０１１５】
次に、クラスタソフト３２は、共有ディスク１０に含まれるアクセス権管理テーブル１２を変更する（ステップＳ４２）。この場合、クラスタソフト３２は、マスター領域１１に対するアクセス権をサーバ３０に設定する。
【０１１６】
アクセス権管理テーブル１２が変更されると、サーバ３０のアクセス権ポーリングデーモン３４は、サーバ３０の有効期限を設定し、当該有効期限をサーバ３０のディスクドライバ３３に通知する。アクセス権ポーリングデーモン３４は、定期的にアクセス権管理テーブル１２を参照し、サーバ３０のアクセス権が設定されている場合には有効期限を更新する。
【０１１７】
クラスタソフト３２は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブルを、当該共有ディスク１０上の別領域である例えばサーバ３０用領域１４にコピーする（ステップＳ４３）。つまり、クラスタソフト３２は、第１のビットマップテーブルのコピーを、サーバ３０用領域１４上に作成する。
【０１１８】
また、クラスタソフト３２は、第１のビットマップテーブルを例えばサーバ３０に備えられるメモリ上にコピーする。つまり、クラスタソフト３２は、第１のピットマップテーブルのコピーを、サーバ３０に備えられるメモリ上に作成する。
【０１１９】
クラスタソフト３２は、サーバ３０用領域１４にコピーされた第１のビットマップテーブル（第１のビットマップテーブルのコピー）に登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータをマスター領域１１とは別の領域（ログ領域）にコピーする（ステップＳ４４）。
【０１２０】
クラスタソフト３２は、サーバ２０のアクセス権ポーリングデーモン２４によって設定されたサーバ２０のアクセス権の有効期限が確実に切れる時刻まで待機する（ステップＳ４５）。
【０１２１】
クラスタソフト３２は、サーバ３０のディスクドライバ３３に当該サーバ３０が稼動系サーバとなった旨を通知する（ステップＳ４６）。このとき、ディスクドライバ３３は、上位層からマスター領域１１が見える状態にする。
【０１２２】
クラスタソフト３２は、サーバ３０のアプリケーション３１を起動する（ステップＳ４７）。これにより、フェイルオーバが完了される。
【０１２３】
次に、図９のフローチャートを参照して、上記したフェイルオーバ直後のサーバ３０のディスクドライバ３３の処理手順について説明する。
【０１２４】
まず、ディスクドライバ３３は、上位（アプリケーション３１）からのＩ／Ｏ要求を入力する（ステップＳ５１）。
【０１２５】
次に、ディスクドライバ３３は、例えばアクセス権ポーリングデーモン３４から通知される有効期限に基づいて、アクセス権管理テーブル１２にサーバ３０のアクセス権が設定されているか否かを判定する。つまり、ディスクドライバ３３は、サーバ３０にマスター領域１１に対するアクセス権があるか否かを判定する（ステップＳ５２）。
【０１２６】
サーバ３０にアクセス権があると判定された場合（ステップＳ５２のＹＥＳ）、ディスクドライバ３３は、入力されたＩ／Ｏ要求がマスター領域１１へのライト要求であるか否かを判定する（ステップＳ５３）。
【０１２７】
マスター領域１１へのライト要求であると判定された場合（ステップＳ５３のＹＥＳ）、ディスクドライバ３３は、サーバ３０に備えられるメモリ上に保持されている第２のビットマップテーブルを参照する。ディスクドライバ３３は、ライト要求の対象となる領域に対応するブロック（ライト先ブロック）が第２のビットマップテーブルに登録済みであるか否かを判定する（ステップＳ５４）。
【０１２８】
ライト先ブロックが第２のビットマップテーブルに登録済みでないと判定された場合（ステップＳ５４のＮＯ）、ディスクドライバ３３は、当該ライト先ブロックを当該第２のビットマップテーブルに登録する（ステップＳ５５）。この場合、ディスクドライバ３３は、サーバ３０ｂに備えられるメモリ上に保持されている第２のビットマップテーブル及び共有ディスク１０に含まれるサーバ３０用領域１４に保持されている第２のビットマップテーブルにライト先ブロックを登録する。
【０１２９】
次に、ディスクドライバ３３は、例えばアクセス権ポーリングデーモン３４から通知される有効期限に基づいて、サーバ３０にマスター領域１１に対するアクセス権があるか否かを判定する（ステップＳ５６）。
【０１３０】
サーバ３０にアクセス権があると判定された場合（ステップＳ５６のＹＥＳ）、ディスクドライバ３３は、ライト先ブロックがサーバ３０に備えられるメモリ上に保持されている第１のビットマップテーブル（第１のビットマップテーブルのコピー）に登録済みであるか否かを判定する（ステップＳ５７）。
【０１３１】
ここで、ステップＳ５７においては、例えばサーバ２０用領域１３に保持されている第１のビットマップテーブルでなく、サーバ３０に備えられるメモリ上の第１のビットマップテーブルのコピーを用いて判定処理が実行される。これにより、例えば判定処理中にサーバ２０用領域１３に保持されている第１のビットマップテーブルがサーバ２０によって更新されるような場合であっても誤動作を行うことなく処理を実行することが可能となる。
【０１３２】
ライト先ブロックが第１のビットマップテーブルに登録済みであると判定された場合（ステップＳ５７のＹＥＳ）、ディスクドライバ３３は、上記したクラスタソフト３２によって第１のビットマップテーブルに登録されているブロックの番号及び当該ブロック（に対応する領域）に格納されているデータがコピーされているログ領域へのライト処理を実行する（ステップＳ５８）。このとき、ディスクドライバ３３は、ログ領域のうち、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
【０１３３】
一方、ライト先ブロックが第１のビットマップテーブルに登録済みでないと判定された場合（ステップＳ５７のＮＯ）、ディスクドライバ３３は、マスター領域１１へのライト処理を実行する（ステップＳ５９）。
【０１３４】
ディスクドライバ３３は、例えばアクセス権ポーリングデーモン３４から通知される有効期限に基づいて、サーバ３０にアクセス権があるか否かを判定する（ステップＳ６０）。
【０１３５】
サーバ３０にアクセス権があると判定された場合（ステップＳ６０のＹＥＳ）、ディスクドライバ３３は、例えば正常にライト処理が実行された旨の処理結果を上位へリターンする（ステップＳ６１）。
【０１３６】
一方、上記したステップＳ５２、Ｓ５６及びＳ６０においてサーバ３０にアクセス権がない、つまりアクセス権ポーリングデーモン３４から通知される有効期限が切れていると判定された場合には、エラーを上位へリターンする（ステップＳ６１）。
【０１３７】
また、ステップＳ５３においてＩ／Ｏ要求がマスター領域１１へのライト要求でない、
例えばマスター領域１１へのリード要求等であると判定された場合、当該リード要求に応じて共有ディスク１０に対してリード処理が実行される。この場合、上述したリード結果の不一致という事態を避けるために、リード要求の対象となる領域に対応するブロック（リード先ブロック）が第１のビットマップテーブルに登録済みである場合にはログ領域に対してリード処理が実行される。このリード処理が実行されると、ステップＳ６０の処理が実行される。
【０１３８】
一方、例えばマスター領域１１以外へのＩ／Ｏ要求である場合には、下位の共有ディスク１０にそのままＩ／Ｏ要求が渡され、ステップＳ６０の処理が実行される。
【０１３９】
また、ステップＳ５４においてライト先ブロックが第２のビットマップテーブルに登録済みであると判定された場合、ステップＳ５６の処理が実行される。
【０１４０】
つまり、上記したようにフェイルオーバ直後においては、第１のビットマップテーブルに登録されているサーバ２０からのライト要求により上塗りされる可能性のある領域（小領域）をアクセス先とするサーバ３０からのアクセスは、ログ領域に対して行われることになる。
【０１４１】
図１０を参照して、サーバ３０においてフェイルオーバが実行される際の当該サーバ３０のクラスタソフト３２及びディスクドライバ３３の処理について具体的に説明する。なお、フェイルオーバが実行される以前の共有ディスク１０に含まれるアクセス権管理テーブル１２には、稼動系サーバであるサーバ２０にアクセス権が設定されているものとする。
【０１４２】
ここで、待機系サーバであるサーバ３０のクラスタソフト３２が、稼動系サーバであるサーバ２０のクラスタソフト２２からのハートビートの断絶を検出したものとする。
【０１４３】
この場合、サーバ３０のクラスタソフト３２は、共有ディスク１０に含まれるアクセス権管理テーブル１２を変更する（ステップＳ７１）。クラスタソフト３２は、マスター領域１１に対するアクセス権をサーバ３０に設定する。これにより、サーバ３０は、マスター領域１１（ＬＵ１）へのアクセス権をサーバ２０から奪う。
【０１４４】
図１０に示す例では、サーバ２０の「○」を「×」に変更し、サーバ３０の「×」を「○」に変更する。これにより、サーバ３０にマスター領域１１へのアクセス権が設定される。
【０１４５】
アクセス権管理テーブル１２が変更されると、サーバ３０のアクセス権ポーリングデーモン３４は、サーバ３０の有効期限を設定し、当該有効期限をサーバ３０のディスクドライバ３３に通知する。
【０１４６】
クラスタソフト３２は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１を、サーバ３０用領域１４にコピーする（ステップＳ７２）。
【０１４７】
また、クラスタソフト３２は、第１のビットマップテーブル１３１をサーバ３０に備えられるメモリ上にコピーする（ステップＳ７３）。
【０１４８】
クラスタソフト３２は、サーバ３０用領域１４にコピーされた第１のビットマップテーブル１３１に登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータを、マスター領域１１からログ領域１４２にコピーする（ステップＳ７４、Ｓ７５）。このログ領域１４２は、共有ディスク１０に含まれる例えばサーバ３０用領域１４にその領域が確保される。
【０１４９】
上記した処理が実行されると、クラスタソフト３２は、サーバ２０のアクセス権の有効期限が確実に切れる時刻まで待機した後、アプリケーション３１を起動させる。
【０１５０】
クラスタソフト３２によってアプリケーション３１が起動されると、サーバ３０のディスクドライバ３３は、アプリケーション３１からのＩ／Ｏ要求を入力する（ステップＳ７６）。ここでは、アプリケーション３１からのＩ／Ｏ要求は、マスター領域１１に対するライト要求であるものとして説明する。
【０１５１】
次に、ディスクドライバ３３は、例えばアクセス権ポーリングデーモン３４から通知される有効期限に基づいて、サーバ３０にアクセス権があるか否かを判定する（ステップＳ７７）。上記したステップＳ７１の処理においてアクセス権管理テーブル１２にはクラスタソフト３２によってサーバ３０にアクセス権が設定されているため、ここではサーバ３０にアクセス権があると判定される。
【０１５２】
ディスクドライバ３３は、アプリケーション３１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）がサーバ３０に備えられたメモリ上に保持されている第２のビットマップテーブル１４１に登録済みであるか否かを判定する。なお、図１０に示すように第２のビットマップテーブル１４１は、上記したサーバ３０に備えられたメモリ以外に、共有ディスク１０に含まれるサーバ３０用領域１４に保持される。
【０１５３】
ここで、ライト先ブロックが第２のビットマップテーブル１４１に登録済みでない場合を想定する。この場合、ディスクドライバ３３は、サーバ３０に備えられたメモリ上に保持されている第２のビットマップテーブル１４１にライト先ブロックを登録する（ステップＳ７８）。
【０１５４】
また、ディスクドライバ３３は、共有ディスク１０に含まれるサーバ３０用領域１４に保持されている第２のビットマップテーブル１４１にライト先ブロックを登録する（ステップＳ７９）。
【０１５５】
次に、ディスクドライバ３３は、上記したステップＳ７７に相当するステップＳ８０の処理を実行する。つまり、ディスクドライバ３３は、サーバ３０にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル１２は変更されておらず、サーバ３０にアクセス権があると判定されたものとする。
【０１５６】
ディスクドライバ３３は、サーバ３０に備えられるメモリ上に保持されている第１のビットマップテーブル１３１を参照する（ステップＳ８１）。これにより、ディスクドライバ３３は、アプリケーション３１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）が第１のビットマップテーブル１３１に登録済みであるか否かを判定する。
【０１５７】
ここで、ライト先ブロックが第１のビットマップテーブル１３１に登録済みであると判定された場合を想定する。この場合には、ディスクドライバ３３は、上記したクラスタソフト３２によって第１のビットマップテーブル１３１に登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータがコピーされているログ領域１４２に対してライト処理を実行する（ステップＳ８２）。このとき、ディスクドライバ３３は、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
【０１５８】
一方、ライト先ブロックが第１のビットマップテーブル１３１に登録済みでない場合を想定する。この場合には、ディスクドライバ３３は、アプリケーション３１から入力されたライト要求に応じてマスター領域１１に対するライト処理を実行する（ステップＳ８３）。
【０１５９】
ディスクドライバ３３は、上記したステップＳ７７（またはステップＳ８０）の処理に相当するステップＳ８４の処理を実行する。ここで、サーバ３０にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション３１に返される。
【０１６０】
一方、上記したステップＳ７７、Ｓ８０及びＳ８４においてサーバ３０にアクセス権がないと判定された場合には、アプリケーション３１にエラーが返される。
【０１６１】
次に、図１１のフローチャートを参照して、フェイルオーバが完了し、一定時間が経過した後のサーバ３０のクラスタソフト３２の処理手順について説明する。この一定時間とは、例えば元稼動系サーバであるサーバ２０におけるＣＰＵ高負荷による一時的なスローダウンが回復するために十分な時間であり、予め定められている。
【０１６２】
まず、サーバ３０のクラスタソフト３２は、当該サーバ３０に備えられているメモリ上に保持されている第１のビットマップテーブルを削除する（ステップＳ９１）。
【０１６３】
次に、クラスタソフト３２は、共有ディスク１０に含まれるサーバ３０用領域１４内に保持されている第１のビットマップテーブルを削除する（ステップＳ９２）。
【０１６４】
クラスタソフト３２は、共有ディスク１０に含まれるサーバ３０用領域１４に確保されているログ領域に格納されているデータを、マスター領域１１の当該ログ領域に対応する場所（領域）にコピーする（ステップＳ９３）。
【０１６５】
ステップ９３に示すコピー処理が完了されると、クラスタソフト３２は、サーバ３０用領域１４に確保されているログ領域を削除する（ステップＳ９４）。
【０１６６】
なお、図１１に示すクラスタソフト３２の処理後においては、サーバ３０のディスクドライバ３３では上述した図６に示す処理に相当する処理が実行される。
【０１６７】
ここで、図１２を参照して、フェイルオーバが完了し、一定時間が経過した後のサーバ３０のクラスタソフト３２及びディスクドライバ３３の処理について具体的に説明する。
【０１６８】
まず、サーバ３０のクラスタソフト３２は、当該サーバ３０に備えられているメモリ上に保持されている第１のビットマップテーブル１３１を削除する（ステップＳ１０１）。
【０１６９】
次に、クラスタソフト３２は、共有ディスク１０に含まれるサーバ３０用領域１４に保持されている第１のビットマップテーブル１３１を削除する（ステップＳ１０２）。
【０１７０】
クラスタソフト３２は、共有ディスク１０に含まれるサーバ３０用領域１４に確保されているログ領域１４２に格納されているデータをマスター領域１１の対応する領域にコピーし、当該ログ領域１４２（に格納されているデータ）を削除する（ステップＳ１０３）。
【０１７１】
ここで、上記したサーバ３０のクラスタソフト３２の処理の完了後に、当該サーバ３０のディスクドライバ３３がサーバ３０上で起動されているアプリケーション３１からＩ／Ｏ要求を入力したものとする（ステップＳ１０４）。このＩ／Ｏ要求は、マスター領域１１（ＬＵ１）に対するライト要求であるものとして説明する。
【０１７２】
次に、ディスクドライバ３３は、例えばアクセス権ポーリングデーモン２４から通知される有効期限に基づいて、サーバ３０にアクセス権があるか否かを判定する（ステップＳ１０５）。ここでは、図１２に示すようにアクセス権管理テーブル１２にはサーバ３０のアクセス権が設定されているものとする。つまり、ディスクドライバ３３によってサーバ３０にアクセス権があると判定されたものとする。
【０１７３】
ディスクドライバ３３は、アプリケーション３１から入力されたライト要求の対象となる領域（ライト先ブロック）がサーバ３０に備えられたメモリ上に保持されている第２のビットマップテーブル１４１に登録済みであるか否かを判定する。なお、図１２に示すように第２のビットマップテーブル１４１は、上記したサーバ３０に備えられたメモリ以外に、共有ディスク１０に含まれるサーバ３０用領域１４に保持される。
【０１７４】
ここで、ライト先ブロックが第２のビットマップテーブル１４１に登録済みでない場合を想定する。この場合、ディスクドライバ３３は、サーバ３０に備えられたメモリ上に保持されている第２のビットマップテーブル１４１にライト先ブロックを登録する（ステップＳ１０６）。
【０１７５】
また、ディスクドライバ３３は、共有ディスク１０に含まれるサーバ３０用領域１４に保持されている第２のビットマップテーブル１４１にライト先ブロックを登録する（ステップＳ１０７）。
【０１７６】
次に、ディスクドライバ３３は、上記したステップＳ１０５の処理に相当するステップＳ１０８の処理を実行する。つまり、ディスクドライバ３３は、サーバ３０にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル１２は変更されておらず、サーバ３０にアクセス権があると判定されたものとする。
【０１７７】
ディスクドライバ３３は、アプリケーション３１から入力されたライト要求に応じてマスター領域１１に対するライト処理を実行する（ステップＳ１０９）。
【０１７８】
ディスクドライバ３３は、上記したステップＳ１０５（またはステップＳ１０８）の処理に相当するステップＳ１１０の処理を実行する。ここで、サーバ３０にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション３１に返される。
【０１７９】
一方、上記したステップＳ１０５、Ｓ１０８及びＳ１１０においてサーバ３０にアクセス権がないと判定された場合には、アプリケーション３１にエラーが返される。
【０１８０】
ここでは、図１１に示す処理がフェイルオーバの後に一定期間が経過した後に実行されるものとして説明したが、この処理は、例えば元稼動系サーバであるサーバ２０（のクラスタソフト２２）からハートビートが検出された後、つまり、サーバ２０で発生したスローダウンの回復が確認され、当該サーバ２０からのライトアクセスが確実に停止された後に実行されても構わない。
【０１８１】
上記したように本実施形態においては、通常運転時に稼動系サーバであるサーバ２０によりマスター領域１１に対してライト処理が実行される場合に当該ライト処理に応じてライト先ブロックが第１のビットマップテーブルに登録される。この後、サーバ２０からサーバ３０にフェイルオーバが実行された場合、当該フェイルオーバ直後におけるサーバ３０からの第１のビットマップテーブルに登録されているブロック（に対応する領域）に対するアクセスは、当該第１のビットマップテーブルに登録されているブロック（のブロック番号及び当該ブロックに格納されているデータ）がコピーされたログ領域に対して実行される。そして、例えばサーバ２０のスローダウンが回復するのに十分な時間（一定時間）経過後にログ領域（に格納されているデータ）がマスター領域１１にコピーされる。これにより、本実施形態においては、現稼動系サーバであるサーバ３０によってマスター領域１１に対してライト処理が実行された後に、当該ライト処理が実行されたブロックと同一の領域に対して元稼動系サーバであるサーバ２０からのライト要求によってデータが上塗りされた場合であっても当該上塗りされた領域にはログ領域がコピーされるので、当該上塗りされることによって生じるデータ破壊を防止することが可能となる。同様に、本実施形態においては、例えば現稼動系サーバであるサーバ３０によってリード処理が実行された領域と同一の領域に対して元稼動系サーバであるサーバ２０からのライト要求によってデータが上塗りされることによって生じるリード結果の不一致を防止することが可能となる。
【０１８２】
［第２の実施形態］
次に、図１３を参照して、本発明の第２の実施形態に係るクラスタシステムについて説明する。図１３は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。なお、前述した図１と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１と異なる部分について主に述べる。以下の各実施形態についても同様にして重複した説明を省略する。
【０１８３】
図１３に示すように、本実施形態に係るクラスタシステムは、複数のサーバ及び共有ディスク１００を備える。複数のサーバは、サーバ（第３の計算機）４０を含む。
【０１８４】
また、共有ディスク１００及びサーバ４０は、例えばＦＣケーブルで接続されている。サーバ４０は、例えばサーバ３０と２本の通信路を介して通信可能に接続されている。
【０１８５】
共有ディスク１００は、アクセス権管理テーブル１２１を含む。このアクセス権管理テーブル１２１には、クラスタシステムを構成するサーバ２０、３０及び４０のそれぞれについて、共有ディスク１００のマスター領域１１へのアクセスの許可または不許可が設定される。図１３に示すように、アクセス権管理テーブル１２１において例えばＬＵ１に対応付けてサーバ２０に「×」、サーバ３０に「○」、サーバ４０に「×」が設定されている場合には、サーバ３０にアクセス権が設定されており、他のサーバ２０及び４０はマスター領域１１へのアクセスが許可されていない。
【０１８６】
また、共有ディスク１０は、サーバ４０用のデータ領域（以下、サーバ４０用領域と表記）１５を含む。このサーバ４０用領域１５には、例えばサーバ４０によってライト処理が実行される際に当該ライト先となる領域に対応するブロックが登録されるサーバ４０用のビットマップテーブル（以下、第３のビットマップテーブルと表記）が保持される。
【０１８７】
サーバ４０は、当該サーバ４０上で動作するアプリケーション３１、クラスタソフト４２、ディスクドライバ４３及びアクセス権ポーリングデーモン４４を備える。
【０１８８】
ここで、前述したようにサーバ３０においてフェイルオーバが実行され、サーバ３０が稼動系サーバである場合を想定する。この場合には、サーバ４０は、サーバ３０の待機系サーバとして動作する。
【０１８９】
稼動系サーバであるサーバ３０に備えられるクラスタソフト３２及び待機系サーバであるサーバ４０に備えられるクラスタソフト４２の間では通信路を経由してハートビートを交換し続け、互いの生存を通知し合う。
【０１９０】
例えば待機系サーバであるサーバ４０のクラスタソフト４２によって稼動系サーバであるサーバ３０のクラスタソフト３２からのハートビートの断絶が検出された場合には、サーバ４０上ではサーバ３０で起動されていたアプリケーション３１の処理を継続するためにアプリケーション４１が起動される。これにより、サーバ４０はフェイルオーバを実行する。
【０１９１】
クラスタソフト４２は、サーバ３０のクラスタソフト３２からのハートビートの断絶が検出された場合、共有ディスク１００に含まれるアクセス権管理テーブル１２１に対してマスター領域１１に対するアクセス権をサーバ４０に変更（設定）する。
【０１９２】
クラスタソフト４２は、前述した第１のビットマップテーブル及び第２のビットマップテーブルに登録されているブロックに対応するマスター領域１１（に含まれる領域）に格納されているデータを、当該マスター領域１１とは異なる共有ディスク１００上の別の領域であるログ領域（第３の領域）にコピーする。このログ領域は、例えば上記したサーバ４０用領域１５内にその領域が確保される。
【０１９３】
クラスタソフト４２は、サーバ３０のマスター領域１１に対するアクセス権の有効期限が確実に切れる時刻まで待機し、当該時刻後にアプリケーション４１を起動する。
【０１９４】
また、クラスタソフト４２は、上記したフェイルオーバが完了し、更に一定時間が経過した場合に、上記したログ領域に格納されているデータをマスター領域１１の対応する領域にコピーする。クラスタソフト４２は、このコピー処理が完了すると、ログ領域を削除する。
【０１９５】
ディスクドライバ４３は、上位（例えば、アプリケーション４１）からのＩ／Ｏ要求に基づいて、共有ディスク１００に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ４３は、Ｉ／Ｏ要求が上記した第１のビットマップテーブル及び第２のビットマップテーブルに登録されている領域に対する要求である場合には、上記したサーバ４０用領域１５に含まれるログ領域に対して当該要求に応じた処理を実行する。
【０１９６】
また、ディスクドライバ４３は、例えば共有ディスク１００に含まれるマスター領域１１に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック（ライト先ブロック）を上記した第３のビットマップテーブルに登録する。この第３のビットマップテーブルは、例えばサーバ４０に備えられるメモリ（図示せず）上にその領域が確保される。また、第３のビットマップテーブルは、上記した共有ディスク１００のサーバ４０用領域１５に保持される。
【０１９７】
アクセス権ポーリングデーモン４４は、前述したサーバ２０のアクセス権ポーリングデーモン２４（またはサーバ３０のアクセス権ポーリングデーモン３４）と同様であるのでその詳しい説明は省略する。
【０１９８】
つまり、本実施形態においては、上記したようにサーバ２０、３０及び４０の３台系のクラスタシステムを想定している。このクラスタシステムにおいて、サーバ２０からサーバ３０へのフェイルオーバ直後にサーバ３０で障害等が発生した場合には、サーバ４０に処理が引き継がれる。この場合には、サーバ４０においては前述した第１の実施形態におけるサーバ３０と同様にフェイルオーバが実行される。
【０１９９】
次に、図１４を参照して、サーバ４０においてフェイルオーバが実行される際の当該サーバ４０のクラスタソフト４２及びディスクドライバ４３の処理について具体的に説明する。
【０２００】
ここでは、上記したようにサーバ２０からサーバ３０へのフェイルオーバ直後にサーバ３０で例えばＣＰＵ高負荷等によるスローダウンが発生し、サーバ４０でフェイルオーバが実行される場合を想定している。よって、サーバ４０でフェイルオーバが実行される以前の共有ディスク１００に含まれるアクセス権管理テーブル１２１には、稼動系サーバであるサーバ３０にアクセス権が設定されているものとする。
【０２０１】
まず、待機系サーバであるサーバ４０のクラスタソフト４２が、稼動系サーバであるサーバ３０のクラスタソフト３２からのハートビートの断絶を検出したものとする。
【０２０２】
この場合、サーバ４０のクラスタソフト４２は、共有ディスク１００に含まれるアクセス権管理テーブル１２１を変更する（ステップＳ１１１）。クラスタソフト４２は、マスター領域１１に対するアクセス権をサーバ４０に設定する。これにより、サーバ４０は、マスター領域１１（ＬＵ１）へのアクセス権をサーバ３０から奪う。
【０２０３】
図１４に示す例では、サーバ３０の「○」が「×」に変更され、サーバ４０の「×」が「○」に変更される。これにより、サーバ４０にマスター領域１１へのアクセス権が設定される。
【０２０４】
アクセス権管理テーブル１２１が変更されると、サーバ４０のアクセス権ポーリングデーモン４４は、サーバ４０の有効期限を設定し、当該有効期限をサーバ４０のディスクドライバ４３に通知する。
【０２０５】
クラスタソフト４２は、共有ディスクに含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１及びサーバ３０用領域１４に保持されている第２のビットマップテーブル１４１が組み合わされたビットマップテーブル（以下、第４のビットマップテーブルと表記）１５１をサーバ４０用領域１５にコピー（作成）する（ステップＳ１１２）。この第４のビットマップテーブル１５１には、第１のビットマップテーブル１３１及び第２のビットマップテーブルに登録されているブロックが登録されている。
【０２０６】
また、クラスタソフト４２は、第４のビットマップテーブル１５１をサーバ４０に備えられるメモリ上にコピーする（ステップＳ１１３）。
【０２０７】
クラスタソフト４２は、サーバ４０用領域１５にコピーされた第４のビットマップテーブル１５１を参照して、上記した第１のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータとしてサーバ３０用領域１４に含まれているログ領域１４２のブロック番号及びデータをログ領域１５２にコピーする（ステップＳ１ｌ４、ステップＳ１１５）。
【０２０８】
また、クラスタソフト４２は、サーバ４０用領域１５にコピーされた第４のビットマップテーブル１５１を参照して、上記した第２のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータを、マスター領域１１からログ領域５２にコピーする（ステップＳ１１４、ステップＳ１１６）。
【０２０９】
このステップＳ１１４〜ステップＳ１１６の処理によって、第４のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータが、ログ領域１５２にコピーされる。
【０２１０】
このログ領域１５２は、共有ディスク１００に含まれる例えばサーバ４０用領域１５にその領域が確保される。
【０２１１】
上記した処理が実行されると、クラスタソフト４２は、サーバ３０のアクセス権の有効期限が確実にけれる時刻まで待機した後、アプリケーション４１を起動させる。
【０２１２】
クラスタソフト４２によってアプリケーション４１が起動されると、サーバ４０のディスクドライバ４３は、アプリケーション４１からのＩ／Ｏ要求を入力する（ステップＳ１１７）。ここでは、アプリケーション４１からのＩ／Ｏ要求は、マスター領域１１に対するライト要求であるものとして説明する。
【０２１３】
次に、ディスクドライバ４３は、例えばアクセス権ポーリングデーモン４４から通知される有効期限に基づいて、サーバ４０にアクセス権があるか否かを判定する（ステップＳ１１８）。上記したステップＳ１１１の処理においてアクセス権管理テーブル１２１にはクラスタソフト４２によってサーバ４０にアクセス権が設定されているため、ここではサーバ４０にアクセス権があると判定される。
【０２１４】
ディスクドライバ４３は、アプリケーション４１から入力されたライト要求の対象となるライト先ブロックがサーバ４０に備えられたメモリ上に保持されている第３のビットマップテーブル１５３に登録済みであるか否かを判定する。なお、図１４に示すように第３のビットマップテーブル１５１は、上記したサーバ４０に備えられたメモリ以外に、共有ディスク１００に含まれるサーバ４０用領域１５に保持される。
【０２１５】
ここで、ライト先ブロックが第３のビットマップテーブル１５３に登録済みでない場合を想定する。この場合、ディスクドライバ４３は、サーバ４０に備えられたメモリ上に保持されている第３のビットマップテーブル１５３にライト先ブロックを登録する（ステップＳ１１９）。
【０２１６】
また、ディスクドライバ４３は、共有ディスク１００に含まれるサーバ４０用領域１５に保持されている第３のビットマップテーブル１５３にライト先ブロックを登録する（ステップＳ１２０）。
【０２１７】
次に、ディスクドライバ４３は、上記したステップＳ１１８に相当するステップＳ１２１の処理を実行する。つまり、ディスクドライバ４３は、サーバ４０にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル１２１は変更されておらず、サーバ４０にアクセス権があると判定されたものとする。
【０２１８】
ディスクドライバ４３は、サーバ４０に備えられるメモリ上に保持されている第４のビットマップテーブル１５１を参照する（ステップＳ１２２）。これにより、ディスクドライバ４３は、アプリケーション４１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）が第４のビットマップテーブル１５１に登録済みであるか否かを判定する。
【０２１９】
ここで、ライト先ブロックが第４のビットマップテーブル１５１に登録済みであると判定された場合を想定する。この場合には、ディスクドライバ４３は、上記したクラスタソフト４２によって第４のビットマップテーブル１５１に登録されているブロックのブロック番号及び当該ブロック（に対応する領域）に格納されているデータがコピーされているログ領域１５２に対してライト処理を実行する（ステップＳ１２３）。このとき、ディスクドライバ４３は、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
【０２２０】
一方、ライト先ブロックが第４のビットマップテーブル１５１に登録済みでないと判定された場合を想定する。この場合には、ディスクドライバ４３は、アプリケーション４１から入力されたライト要求に応じてマスター領域１１に対するライト処理を実行する（ステップＳ１２４）。
【０２２１】
ディスクドライバ４３は、上記したステップＳ１１８（またはステップＳ１２１）の処理に相当するステップＳ１２５の処理を実行する。ここで、サーバ４０にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション４１に返される。
【０２２２】
一方、上記したステップＳ１１８、Ｓ１２１及びＳ１２５においてサーバ４０にアクセス権がないと判定された場合には、アプリケーション４１にエラーが返される。
【０２２３】
上記したように本実施形態においては、例えばサーバ２０、３０及び４０の３台系のクラスタシステムにおいてサーバ２０からサーバ３０にフェイルオーバが実行された直後に当該サーバ３０からサーバ４０にフェイルオーバが実行された（多段フェイルオーバが発生した）場合には、当該サーバ４０からのアクセスは、第１のビットマップテーブル及び第２のビットマップテーブルが組み合わされた第４のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータがコピーされたログ領域に対して実行される。これにより、本実施形態においては、上記したサーバ２０、３０及び４０の３台系のクラスタシステムのような多台系のクラスタシステムで多段フェイルオーバが発生した場合であっても、処理を複雑化することなくデータ破壊を防止することが可能となる。
【０２２４】
［第３の実施形態］
次に、図１５を参照して、本発明の第３の実施形態に係るクラスタシステムについて説明する。図１５は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。
【０２２５】
図１５に示すように、本実施形態に係るクラスタシステムにおいては、サーバ２０は、テーブル整理デーモン２５を備える。
【０２２６】
また、本実施形態においては、前述した第１の実施形態とは異なり、サーバ２０に備えられるメモリ上には、第１のビットマップテーブルに代えてイントマップ（intmap）テーブルが保持される。第１のビットマップテーブルとは異なり、このイントマップテーブルにおいては、４バイトが１ブロックに対応する。イントマップテーブルには、１ブロック毎に例えばｉｎｔの値が登録される。
【０２２７】
ディスクドライバ２３は、例えば共有ディスク１０に含まれるマスター領域１１に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック（ライト先ブロック）をサーバ２０に備えられるメモリ上に保持されるイントマップテーブルに登録する。
【０２２８】
このとき、ライト先ブロックがイントマップテーブルに登録されていない場合、つまり、ライト先ブロックへの初書き込みの場合には、当該ライト先ブロックに対応するｉｎｔの値として現在のシーケンス（sequence）番号が登録される。一方、ライト先ブロックが既にイントマップテーブルに登録されている場合には、例えば当該ライト先ブロックに対応するｉｎｔの値に１を加えた値（つまり、シーケンス番号＋１）を登録する。
【０２２９】
これにより、イントマップテーブルにおいては、当該イントマップテーブルに登録されているｉｎｔの値（シーケンス番号）に応じて、当該値に対応するブロックへのアクセス頻度が示される。
【０２３０】
テーブル整理デーモン２５は、例えば定期的にイントマップテーブルを参照する。テーブル整理デーモン２５は、イントマップテーブルに登録済みのブロック数が予め定められた値（以下、閾値と表記）以上であるか否かを判定する。
【０２３１】
テーブル整理デーモン２５は、例えばイントマップテーブルにおいて古いシーケンス番号を持つｉｎｔの値をクリア（＝０）する。つまり、テーブル整理デーモン２５は、アクセス頻度の少ない登録済みのブロックをイントマップテーブルから未登録とする。
【０２３２】
テーブル整理デーモン２５は、ｉｎｔの値がクリアされたブロックを共有ディスク１０に含まれるサーバ２０用領域に保持されている第１のビットマップテーブルから未登録とする。これにより、テーブル整理デーモン２５は、アクセス頻度の少ないブロックを削除することによって登録済みのブロック数を閾値以下にする。
【０２３３】
次に、図１６を参照して、図１５に示すクラスタシステムを構成するサーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３及びテーブル整理デーモンの処理について具体的に説明する。なお、共有ディスク１０に含まれるアクセス権管理テーブル１２には、サーバ２０のマスター領域１１に対するアクセス権が設定されているものとする。
【０２３４】
まず、前述した図７に示すステップＳ３１及びステップＳ３２の処理に相当するステップＳ１３１及びステップＳ１３２の処理が実行される。なお、ステップＳ１３１で入力されたＩ／Ｏ要求は、マスター領域１１（ＬＵ１）に対するライト要求であるものとする。
【０２３５】
次に、ディスクドライバ２３は、アプリケーション２１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）をサーバ２０に備えられたメモリ上に保持されているイントマップテーブル１３２に登録する（ステップＳ１３３）。
【０２３６】
このとき、ライト先ブロックがイントマップテーブル１３２に登録されていない場合、つまり、当該ライト先ブロックへの初書き込みである場合には、ディスクドライバ２３は、当該ライト先ブロックに対応するｉｎｔの値として現在のシーケンス番号を登録する。
【０２３７】
一方、ライト先ブロックが既にイントマップテーブルに登録されている場合には、ディスクドライバ２３は、当該ライト先ブロックに対応するｉｎｔの値であるシーケンス番号＋１を当該ライト先ブロックに対応するｉｎｔの値として登録する。
【０２３８】
ステップＳ１３３の処理が実行されると、図７に示すステップＳ３４〜ステップＳ３７の処理に相当するステップＳ１３４〜ステップＳ１３７の処理が実行される。
【０２３９】
ところで、テーブル整理デーモン２５は、上記したようにイントマップテーブル１３２を定期的に参照する（ステップＳ１３８）。テーブル整理デーモン２５は、イントマップテーブル１３２に登録済みのブロック数が閾値以上であるか否かを判定する。
【０２４０】
ここで、テーブル整理デーモン２５によってイントマップテーブル１３２に登録済みのブロック数が閾値以上であると判定された場合を想定する。この場合には、テーブル整理デーモン２５は、イントマップテーブル１３２に登録されている古いシーケンス番号を持つｉｎｔの値をクリアする。
【０２４１】
次に、テーブル整理デーモン２５は、共有ディスク１０に含まれるサーバ２０用領域１３に保持されている第１のビットマップテーブル１３１において、クリアされたｉｎｔの値に対応するブロックを未登録とする（ステップＳ１３９）。これにより、テーブル整理デーモン２５は、例えばアクセス頻度の少ないブロックを未登録とすることで、第１のビットマップテーブル１３１に登録されている登録済みのブロック数を閾値以下にする。
【０２４２】
上記したように本実施形態においては、イントマップテーブルに登録されているブロック数が閾値以上になった場合には、当該登録されているブロックのうち、アクセス頻度の少ないブロックを第１のビットマップテーブル（及びイントマップテーブル）において未登録とすることで、例えばサーバ３０によってフェイルオーバが実行された場合であってもデータ破壊を防止するために別途必要となるディスク領域（ログ領域）のサイズを一定サイズ以下に抑えることが可能となる。
【０２４３】
なお、本実施形態においては、テーブル整理デーモン２５がサーバ２０に備えられるものとして説明したが、例えばテーブル整理デーモン２５がクラスタシステムを構成する複数のサーバの全てに備えられる構成であっても構わない。
【０２４４】
［第４の実施形態］
次に、図１７を参照して、本発明の第４の実施形態に係るクラスタシステムについて説明する。図１７は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。
【０２４５】
図１７に示すように、本実施形態に係るクラスタシステムにおいては、サーバ２０は、統計情報処理部２６を備える。
【０２４６】
本実施形態においては、サーバ２０のディスクドライバ２３は、アプリケーション２１からマスター領域１１に対するライト要求を入力した場合、当該ライト要求の対象となる領域に対応するブロック（ライト先ブロック）を統計情報処理部２６に通知する。ディスクドライバ２３は、マスター領域１１に対するライト要求を入力する度に当該ライト要求に係るライト先ブロックを通知する。
【０２４７】
統計情報処理部２６は、統計情報処理部２６は、ディスクドライバ２３からのライト先ブロックの通知に基づいて、例えばサーバ２０のマスター領域１１に対する書き込みのアクセスパターンを統計的に解析する。
【０２４８】
統計情報処理部２６は、アクセスパターンの解析結果に基づいて、例えば将来書き込みがなされる可能性の高いブロック（ライト先ブロック）を予測する。統計情報処理部２６は、サーバ２０に備えられているメモリ上に保持されている第１のビットマップテーブル及び共有ディスク１０に含まれるサーバ２０用領域１４に保持されている第１のビットマップテーブルに、予測されたライト先ブロックを予め登録する。
【０２４９】
次に、図１８を参照して、図１７に示すクラスタシステムを構成するサーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３及び統計情報処理部２６の処理について具体的に説明する。なお、共有ディスク１０に含まれるアクセス権管理テーブル１２には、サーバ２０にマスター領域１１に対するアクセス権が設定されているものとする。
【０２５０】
まず、前述した図７に示すステップＳ３１〜ステップＳ３４の処理に相当するステップＳ１４１〜ステップＳ１４４の処理が実行される。なお、ステップＳ１４１で入力されたＩ／Ｏ要求は、マスター領域１１（ＬＵ１）に対するライト要求であるものとする。
【０２５１】
次に、ディスクドライバ２３は、アプリケーション２１から入力されたライト要求の対象となる領域に対応するブロック（ライト先ブロック）を統計情報処理部２６に通知する（ステップＳ１４５）。ディスクドライバ２３は、マスター領域１１に対するライト要求を入力する都度、ライト先ブロックを通知する。このとき、ディスクドライバ２３は、例えばライト先ブロックのブロック番号等を通知する。
【０２５２】
以下、ディスクドライバ２３では、前述した図７に示すステップＳ３５〜ステップＳ３７の処理に相当するステップＳ１４６〜ステップＳ１４８の処理が実行される。
【０２５３】
統計情報処理部２６は、ディスクドライバ２３から通知されたライト先ブロックに基づいて、サーバ２０のマスター領域１１に対する書き込みのアクセスパターンを統計的に解析する。
【０２５４】
統計情報処理部２６は、解析されたサーバ２０のアクセスパターンに基づいて、当該サーバ２０によって将来書き込みがなされる可能性の高いブロック（ライト先ブロック）を予測する。
【０２５５】
具体的には、ディスクドライバ２３によって通知されたライト先ブロックのブロック番号が例えばブロック番号１０、ブロック番号１１及びブロック番号１２と続いた場合、つまり、サーバ２０（のディスクドライバ２３）によってブロック番号１０のブロック、ブロック番号２０のブロック及びブロック番号３０のブロックに対して書き込み（ライト処理）が実行された場合には、統計情報処理部２６は、ブロック番号１３〜２０のブロックを将来書き込みがなされる可能性が高いブロックとして予測する。
【０２５６】
また、ディスクドライバ２３によって通知されたライト先ブロックのブロック番号が例えばブロック番号１０、ブロック番号２０及びブロック番号３０と続いた場合、統計情報処理部２６は、ブロック番号４０及び５０のブロックを将来書き込みがなされる可能性が高いブロックとして予測する。
【０２５７】
統計情報処理部２６は、サーバ２０に備えられるメモリ上に保持されている第1のビットマップテーブル１３１に、予測されたブロックを登録する（ステップＳ１４９）。
【０２５８】
また、統計情報処理部２６は、共有ディスクに含まれるサーバ２０用領域に保持されている第１のビットマップテーブル１３１に、予測されたブロックを登録する（ステップＳ１５０）。
【０２５９】
なお、上記したステップＳ１４９及びステップＳ１５０の処理は、Ｉ／Ｏ負荷の低い（軽い）時間帯等に実行される。
【０２６０】
上記したように本実施形態においては、サーバ２０のライト先ブロックに基づいて当該サーバ２０のアクセスパターンを解析し、当該アクセスパターンから将来書き込みがなされる可能性の高いブロックを予め第１のビットマップテーブルに登録しておくことで、将来ライト先ブロックを第１のビットマップテーブルに登録（更新）する際のＩ／Ｏによって発生する性能劣化の度合いを未然に削減することが可能となる。
【０２６１】
なお、本実施形態においては、統計情報処理部２６がサーバ２０に備えられるものとして説明したが、例えば統計情報処理部２６がクラスタシステムを構成する複数のサーバの全てに備えられる構成であっても構わない。［第５の実施形態］
次に、本発明の第５の実施形態に係るクラスタシステムについて説明する。本実施形態に係るクラスタシステムの構成については、前述した図１７に示すクラスタシステムの構成と同様であるので、図１７を用いて説明する。ここでは、前述した第４の実施形態に係るクラスタシステムと異なる部分について主に述べる。
【０２６２】
本実施形態においては、サーバ２０に備えられる統計情報処理部２６は、アプリケーション２１の起動（開始）直後からしばらくの間（予め定められた時間）サーバ２０のディスクドライバ２３からライト先ブロックの通知を受け取る。
【０２６３】
統計情報処理部２６は、受け取られたライト先ブロックの通知に基づいて、サーバ２０のマスター領域１１に対するアクセスパターンを統計的に解析する。統計情報処理部２６は、解析されたアクセスパターンに基づいて、アクセス頻度の高いライト先ブロックが登録されたビットマップテーブルのテンプレート（以下、単にテンプレートと表記）を作成する。作成されたテンプレートは、例えばサーバ２０上で記憶される。
【０２６４】
テンプレートは、例えばアプリケーション２１の起動時（サーバ２０の稼動時）に前述した第１のビットマップテーブルとして用いられる。
【０２６５】
また、サーバ２０のアプリケーション２１が停止された際の第１のビットマップテーブルを記憶しておき、当該記憶されている第１のビットマップテーブル及びテンプレートがマージされたものを、当該アプリケーション２１の起動時に第１のビットマップテーブルとして用いる構成であっても構わない。
【０２６６】
上記したように本実施形態においては、サーバ２０のライト先ブロックに基づいて当該サーバ２０のアクセスパターンを解析し、当該アクセスパターンに基づいてアクセス頻度の高いライト先ブロックが登録されたテンプレートを予め作成しておき、アプリケーション２１の起動時には当該テンプレートが第１のビットマップテーブルとして用いられる。これにより、本実施形態においては、アプリケーション２１の開始時に、ライト先ブロックを第１のビットマップテーブルに登録（更新）するためのＩ／Ｏによって発生する性能劣化の度合いを未然に削減することが可能となる。
【０２６７】
なお、本願発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。
【図面の簡単な説明】
【０２６８】
【図１】本発明の第１の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図２】フェイルオーバについて説明するための図。
【図３】図１に示すクラスタシステムの仕組みの概略について説明するための図。
【図４】ビットマップテーブルに登録される領域について説明するための図。
【図５】サーバ２０を稼動系サーバに移行する際の当該サーバ２０のクラスタソフト２２の処理手順を示すフローチャート。
【図６】サーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３の処理手順を示すフローチャート。
【図７】サーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３の処理について具体的に説明するための図。
【図８】サーバ３０においてフェイルオーバが実行される際の当該サーバ３０のクラスタソフト３２の処理手順を示すフローチャート。
【図９】フェイルオーバ直後のサーバ３０のディスクドライバ３３の処理手順を示すフローチャート。
【図１０】サーバ３０においてフェイルオーバが実行される際の当該サーバ３０のクラスタソフト３２及びディスクドライバ３３の処理について具体的に説明するための図。
【図１１】フェイルオーバが完了し、一定時間が経過した後のサーバ３０のクラスタソフト３２の処理手順を示すフローチャート。
【図１２】フェイルオーバが完了し、一定時間が経過した後のサーバ３０のクラスタソフト３２及びディスクドライバ３３の処理について具体的に説明するための図。
【図１３】本発明の第２の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図１４】サーバ４０においてフェイルオーバが実行される際の当該サーバ４０のクラスタソフト４２及びディスクドライバ４３の処理について具体的に説明するための図。
【図１５】本発明の第３の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図１６】図１５に示すクラスタシステムを構成するサーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３及びテーブル整理デーモンの処理について具体的に説明するための図。
【図１７】本発明の第４の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図１８】図１７に示すクラスタシステムを構成するサーバ２０が稼動系サーバに移行した後の当該サーバ２０のディスクドライバ２３及び統計情報処理部２６の処理について具体的に説明するための図。
【符号の説明】
【０２６９】
１０…共有ディスク（記憶装置）、１１…マスター領域（第１の領域）、１２…アクセス権管理テーブル、１３…サーバ２０用領域、１４…サーバ３０用領域、１５…サーバ４０用領域、２０，３０，４０…サーバ、２１，３１，４１…アプリケーション、２２，３２，４２…クラスタソフト、２３，３３，４３…ディスクドライバ、２４，３４，４４…アクセス権ポーリングデーモン、２５…テーブル整理デーモン、２６…統計情報処理部、５０…クライアント端末、１３１…第１のビットマップテーブル（第１の計算機用テーブル）、１３２…イントマップテーブル、１４１…第２のビットマップテーブル（第２の計算機用テーブル）、１４２，１５２…ログ領域、１５１…第４のビットマップテーブル、１５３…第３のビットマップテーブル。
【特許請求の範囲】
【請求項１】
第１の計算機と、当該第１の計算機と接続され、当該第１の計算機から定期的に所定のパケットを受信する第２の計算機と、前記第１の計算機及び前記第２の計算機と接続されている記憶装置とを備える計算機システムにおいて、
前記記憶装置は、
前記第１の計算機及び第２の計算機からアクセスされる第１の領域と、
前記第１の領域に対するアクセスの許可を示すアクセス権が前記第１の計算機に設定されているアクセス権管理テーブルと、
前記第１の領域とは異なる第２の領域と、
前記第１の領域に対して前記第１の計算機によってライトアクセスされた際に、当該ライトアクセス先となる領域を登録するための第１の計算機用テーブルと
を含み、
前記第１の計算機は、当該第１の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、当該ライトアクセス先となる領域を前記記憶装置に含まれる第１の計算機用テーブルに登録するアクセス先登録手段を含み、
前記第２の計算機は、
前記第１の計算機からの前記所定のパケットの断絶が検出された場合に、前記記憶装置に含まれるアクセス権管理テーブルにおいて前記第２の計算機に前記アクセス権を設定する設定手段と、
前記第１の計算機用テーブルに登録されている領域に格納されているデータを、前記第２の領域にコピーするコピー処理手段と、
前記第２の計算機にアクセス権が設定された後に、前記記憶装置に含まれる第１の領域にアクセスする際に、当該アクセス先となる領域が前記第１の計算機用テーブルに登録されているかを判定する判定手段と、
前記第１の計算機用テーブルに登録されていると判定された場合、前記第１の計算機用テーブルに登録されている領域に格納されているデータがコピーされた前記第２の領域に対してアクセスするアクセス手段と
を含む
ことを特徴とする計算機システム。
【請求項２】
前記第１の計算機は、
前記第１の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、前記アクセス権管理テーブルを参照して、当該第１の計算機に前記アクセス権が設定されているかを判定する第１の判定手段と、
前記アクセス先登録手段によって前記ライトアクセス先となる領域が前記第１の計算機用テーブルに登録された後に、前記アクセス権管理テーブルを参照して、前記第１の計算機に前記アクセス権が設定されているかを判定する第２の判定手段と、
前記アクセス権が設定されていると前記第２の判定手段によって判定された場合、前記第１の領域に対してライトアクセスを実行するライトアクセス手段と、
前記ライトアクセス手段によって前記第１の領域に対してライトアクセスが実行された後に、前記アクセス権管理テーブルを参照して、当該アクセス手段によるライトアクセスの処理結果を上位へリターンするリターン手段と
を更に含み、
前記アクセス先登録手段は、前記第１の計算機の第１の判定手段によって当該第１の計算機に前記アクセス権が設定されていると判定された場合に、前記ライトアクセス先となる領域を前記第１の計算機用テーブルに登録し、
前記第２の計算機の判定手段は、前記第１の計算機用テーブルに登録されていると判定された場合、前記第２の計算機に前記アクセス権が設定されているかを、前記アクセス権管理テーブルを参照して判定し、
前記第２の計算機のアクセス手段は、前記第２の計算機の判定手段によって当該第２の計算機に前記アクセス権が設定されていると判定された場合、前記第２の領域に対してアクセスする
ことを特徴とする請求項１記載の計算機システム。
【請求項３】
前記第２の計算機は、
前記第１の計算機用テーブルのコピーを作成するコピー作成手段を更に含み、
前記判定手段は、前記第２の計算機にアクセス権が設定された後に、前記記憶装置に含まれる第１の領域にアクセスする際に、当該アクセス先となる領域が前記作成された第１の計算機用テーブルのコピーに登録されているかを判定し、
前記アクセス手段は、前記作成された第１の計算機用テーブルのコピーに登録されていると判定された場合、当該第１の計算機用テーブルのコピーに登録されている領域に格納されているデータがコピーされた前記第２の領域に対してアクセスする
ことを特徴とする請求項１または請求項２記載の計算機システム。
【請求項４】
前記コピー処理手段は、前記第１の計算機からの前記所定のパケットの断絶が検出されてから予め定められた時間経過後または第１の計算機からのライトアクセスが確実に停止された後、前記第２の領域に格納されているデータを前記第１の領域に含まれる領域のうち、前記第１の計算機用テーブルに登録されている領域にコピーすることを特徴とする請求項１記載の計算機システム。
【請求項５】
前記第２の計算機及び前記記憶装置と接続され、当該第２の計算機から定期的に所定のパケットを受信する第３の計算機を更に具備し、
前記第１の領域は、前記第３の計算機からアクセスされ、
前記記憶装置は、
前記記憶装置に含まれる第１の領域に対して前記第２の計算機によってライトアクセスされた際に、当該ライトアクセス先となる領域を登録するための第２の計算機用テーブルと、
前記第１の領域及び第２の領域とは異なる第３の領域と
を更に含み、
前記第２の計算機は、当該第２の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、当該ライトアクセス先となる領域を前記記憶装置に含まれる第２の計算機用テーブルに登録する登録手段を更に含み、
前記第３の計算機は、
前記第２の計算機からの前記所定のパケットの断絶が検出された場合に、前記記憶装置に含まれるアクセス権管理テーブルにおいて前記第３の計算機に前記アクセス権を設定する設定手段と、
前記第１の計算機用テーブル及び前記第２の計算機用テーブルに登録されている領域に格納されているデータを、前記第３の領域にコピーするコピー処理手段と、
前記第３の計算機にアクセス権が設定された後に、前記記憶装置に含まれる第１の領域にアクセスする際に、当該アクセス先となる領域が前記第１の計算機用テーブルまたは第２の計算機用テーブルに登録されているかを判定する判定手段と、
前記第１の計算機用テーブルまたは前記第２の計算機用テーブルに登録されていると判定された場合、前記第１の計算機用テーブルまたは前記第２の計算機用テーブルに登録されている領域に格納されているデータがコピーされた前記第３の領域に対してアクセスするアクセス手段と
を含む
ことを特徴とする請求項１記載の計算機システム。
【請求項６】
前記第１の計算機は、
前記第１の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、当該ライトアクセス先となる領域に対するアクセス頻度を、前記第１の計算機用テーブルに登録するアクセス頻度登録手段と、
前記第１の計算機用テーブルに登録されている領域であって当該領域に対するアクセス頻度が少ない領域を、当該第１の計算機用テーブルから未登録とする未登録手段と
を更に含む
ことを特徴とする請求項１記載の計算機システム。
【請求項７】
前記第１の計算機は、
前記第１の計算機によってライトアクセスされた第１の領域に含まれる領域に基づいて、当該第１の計算機のアクセスパターンを統計的に解析する解析手段と、
前記解析されたアクセスパターンに基づいて、前記第１の計算機によってライトアクセスされる領域を予測する予測手段と
を更に含み、
前記登録手段は、前記予測された領域を前記第１の計算機用テーブルに登録する
ことを特徴とする請求項１記載の計算機システム。
【請求項８】
前記第１の計算機は、
前記第１の計算機によってライトアクセスされた第１の領域に含まれる領域に基づいて、当該第１の計算機のアクセスパターンを統計的に解析する解析手段と、
前記解析されたアクセスパターンに基づいて、前記第１の計算機用テーブルに登録されている領域のうち、アクセス頻度が高い領域が登録されたテンプレートを作成するテンプレート作成手段と
を更に含み、
前記記憶装置は、前記第１の計算機が稼動する際に、前記作成されたテンプレートを前記第１の計算機用テーブルとして含む
ことを特徴とする請求項１記載の計算機システム。
【請求項１】
第１の計算機と、当該第１の計算機と接続され、当該第１の計算機から定期的に所定のパケットを受信する第２の計算機と、前記第１の計算機及び前記第２の計算機と接続されている記憶装置とを備える計算機システムにおいて、
前記記憶装置は、
前記第１の計算機及び第２の計算機からアクセスされる第１の領域と、
前記第１の領域に対するアクセスの許可を示すアクセス権が前記第１の計算機に設定されているアクセス権管理テーブルと、
前記第１の領域とは異なる第２の領域と、
前記第１の領域に対して前記第１の計算機によってライトアクセスされた際に、当該ライトアクセス先となる領域を登録するための第１の計算機用テーブルと
を含み、
前記第１の計算機は、当該第１の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、当該ライトアクセス先となる領域を前記記憶装置に含まれる第１の計算機用テーブルに登録するアクセス先登録手段を含み、
前記第２の計算機は、
前記第１の計算機からの前記所定のパケットの断絶が検出された場合に、前記記憶装置に含まれるアクセス権管理テーブルにおいて前記第２の計算機に前記アクセス権を設定する設定手段と、
前記第１の計算機用テーブルに登録されている領域に格納されているデータを、前記第２の領域にコピーするコピー処理手段と、
前記第２の計算機にアクセス権が設定された後に、前記記憶装置に含まれる第１の領域にアクセスする際に、当該アクセス先となる領域が前記第１の計算機用テーブルに登録されているかを判定する判定手段と、
前記第１の計算機用テーブルに登録されていると判定された場合、前記第１の計算機用テーブルに登録されている領域に格納されているデータがコピーされた前記第２の領域に対してアクセスするアクセス手段と
を含む
ことを特徴とする計算機システム。
【請求項２】
前記第１の計算機は、
前記第１の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、前記アクセス権管理テーブルを参照して、当該第１の計算機に前記アクセス権が設定されているかを判定する第１の判定手段と、
前記アクセス先登録手段によって前記ライトアクセス先となる領域が前記第１の計算機用テーブルに登録された後に、前記アクセス権管理テーブルを参照して、前記第１の計算機に前記アクセス権が設定されているかを判定する第２の判定手段と、
前記アクセス権が設定されていると前記第２の判定手段によって判定された場合、前記第１の領域に対してライトアクセスを実行するライトアクセス手段と、
前記ライトアクセス手段によって前記第１の領域に対してライトアクセスが実行された後に、前記アクセス権管理テーブルを参照して、当該アクセス手段によるライトアクセスの処理結果を上位へリターンするリターン手段と
を更に含み、
前記アクセス先登録手段は、前記第１の計算機の第１の判定手段によって当該第１の計算機に前記アクセス権が設定されていると判定された場合に、前記ライトアクセス先となる領域を前記第１の計算機用テーブルに登録し、
前記第２の計算機の判定手段は、前記第１の計算機用テーブルに登録されていると判定された場合、前記第２の計算機に前記アクセス権が設定されているかを、前記アクセス権管理テーブルを参照して判定し、
前記第２の計算機のアクセス手段は、前記第２の計算機の判定手段によって当該第２の計算機に前記アクセス権が設定されていると判定された場合、前記第２の領域に対してアクセスする
ことを特徴とする請求項１記載の計算機システム。
【請求項３】
前記第２の計算機は、
前記第１の計算機用テーブルのコピーを作成するコピー作成手段を更に含み、
前記判定手段は、前記第２の計算機にアクセス権が設定された後に、前記記憶装置に含まれる第１の領域にアクセスする際に、当該アクセス先となる領域が前記作成された第１の計算機用テーブルのコピーに登録されているかを判定し、
前記アクセス手段は、前記作成された第１の計算機用テーブルのコピーに登録されていると判定された場合、当該第１の計算機用テーブルのコピーに登録されている領域に格納されているデータがコピーされた前記第２の領域に対してアクセスする
ことを特徴とする請求項１または請求項２記載の計算機システム。
【請求項４】
前記コピー処理手段は、前記第１の計算機からの前記所定のパケットの断絶が検出されてから予め定められた時間経過後または第１の計算機からのライトアクセスが確実に停止された後、前記第２の領域に格納されているデータを前記第１の領域に含まれる領域のうち、前記第１の計算機用テーブルに登録されている領域にコピーすることを特徴とする請求項１記載の計算機システム。
【請求項５】
前記第２の計算機及び前記記憶装置と接続され、当該第２の計算機から定期的に所定のパケットを受信する第３の計算機を更に具備し、
前記第１の領域は、前記第３の計算機からアクセスされ、
前記記憶装置は、
前記記憶装置に含まれる第１の領域に対して前記第２の計算機によってライトアクセスされた際に、当該ライトアクセス先となる領域を登録するための第２の計算機用テーブルと、
前記第１の領域及び第２の領域とは異なる第３の領域と
を更に含み、
前記第２の計算機は、当該第２の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、当該ライトアクセス先となる領域を前記記憶装置に含まれる第２の計算機用テーブルに登録する登録手段を更に含み、
前記第３の計算機は、
前記第２の計算機からの前記所定のパケットの断絶が検出された場合に、前記記憶装置に含まれるアクセス権管理テーブルにおいて前記第３の計算機に前記アクセス権を設定する設定手段と、
前記第１の計算機用テーブル及び前記第２の計算機用テーブルに登録されている領域に格納されているデータを、前記第３の領域にコピーするコピー処理手段と、
前記第３の計算機にアクセス権が設定された後に、前記記憶装置に含まれる第１の領域にアクセスする際に、当該アクセス先となる領域が前記第１の計算機用テーブルまたは第２の計算機用テーブルに登録されているかを判定する判定手段と、
前記第１の計算機用テーブルまたは前記第２の計算機用テーブルに登録されていると判定された場合、前記第１の計算機用テーブルまたは前記第２の計算機用テーブルに登録されている領域に格納されているデータがコピーされた前記第３の領域に対してアクセスするアクセス手段と
を含む
ことを特徴とする請求項１記載の計算機システム。
【請求項６】
前記第１の計算機は、
前記第１の計算機が前記記憶装置に含まれる第１の領域にライトアクセスする際に、当該ライトアクセス先となる領域に対するアクセス頻度を、前記第１の計算機用テーブルに登録するアクセス頻度登録手段と、
前記第１の計算機用テーブルに登録されている領域であって当該領域に対するアクセス頻度が少ない領域を、当該第１の計算機用テーブルから未登録とする未登録手段と
を更に含む
ことを特徴とする請求項１記載の計算機システム。
【請求項７】
前記第１の計算機は、
前記第１の計算機によってライトアクセスされた第１の領域に含まれる領域に基づいて、当該第１の計算機のアクセスパターンを統計的に解析する解析手段と、
前記解析されたアクセスパターンに基づいて、前記第１の計算機によってライトアクセスされる領域を予測する予測手段と
を更に含み、
前記登録手段は、前記予測された領域を前記第１の計算機用テーブルに登録する
ことを特徴とする請求項１記載の計算機システム。
【請求項８】
前記第１の計算機は、
前記第１の計算機によってライトアクセスされた第１の領域に含まれる領域に基づいて、当該第１の計算機のアクセスパターンを統計的に解析する解析手段と、
前記解析されたアクセスパターンに基づいて、前記第１の計算機用テーブルに登録されている領域のうち、アクセス頻度が高い領域が登録されたテンプレートを作成するテンプレート作成手段と
を更に含み、
前記記憶装置は、前記第１の計算機が稼動する際に、前記作成されたテンプレートを前記第１の計算機用テーブルとして含む
ことを特徴とする請求項１記載の計算機システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２００９−２８２７７６（Ｐ２００９−２８２７７６Ａ）
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願番号】特願２００８−１３４５６６（Ｐ２００８−１３４５６６）
【出願日】平成２０年５月２２日（２００８．５．２２）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願日】平成２０年５月２２日（２００８．５．２２）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]