以下、図面を参照して、本発明の各実施形態について説明する。
[第1の実施形態]
図1は、本発明の第1の実施形態に係るクラスタシステム(計算機システム)の機能構成を示すブロック図である。
図1に示すように、本実施形態に係るクラスタシステムは、複数のサーバ(計算機)及び共有ディスク10を備える。複数のサーバは、サーバ(第1の計算機)20及びサーバ(第2の計算機)30を含む。
また、共有ディスク10及びサーバ20は、例えばFC(Fibre Channel)ケーブルで接続されている。同様に、共有ディスク10及びサーバ30は、FCケーブルで接続されている。サーバ20及びサーバ30は、例えば2本の通信路を介して通信可能に接続されている。以下、サーバ20は稼動系サーバ、サーバ30は待機系サーバであるものとして説明する。
共有ディスク10は、マスター領域(第1の領域)11及びQUORUM領域を含む。マスター領域11は、上記したサーバ20及びサーバ30によってアクセスされる共有領域である。ここでは、マスター領域11は、共有ディスク10が有する論理ユニット(LU:Logical Unit)、例えばLU1に含まれるものとする。
QUORUM領域には、アクセス権管理テーブル12が含まれる。このアクセス権管理テーブル12には、クラスタシステムを構成するサーバ20及びサーバ30のそれぞれについて、共有ディスク10のマスター領域11へのアクセスの許可または不許可が設定される。図1に示すように、アクセス権管理テーブル12において例えばLU1に対応付けてサーバ20に「○」、サーバ30に「×」が設定されている場合には、サーバ20のマスター領域11に対するアクセスが許可され、サーバ30のマスター領域11に対するアクセスは許可されていないことを示す。つまり、図1に示す例では、アクセス権管理テーブル12には、マスター領域11に対するアクセスの許可を示すアクセス権がサーバ20に設定されている。
また、QUORUM領域には、サーバ20用のデータ領域(以下、サーバ20用領域と表記)13及びサーバ30用のデータ領域(以下、サーバ30用データ領域と表記)14が含まれる。
本実施形態においては、上記したマスター領域11及びQUORUM領域を異なるLUに分けてもよいし、異なるパーティションに分けてもよい。
サーバ20は、当該サーバ20上で動作するアプリケーション21、クラスタソフト22、ディスクドライバ23及びアクセス権ポーリングデーモン24を備える。
稼動系サーバであるサーバ20では、アプリケーション21が実行される。このようにサーバ20でアプリケーション21が実行されている間には、稼動系サーバであるサーバ20に備えられるクラスタソフト22及び待機系サーバであるサーバ30に備えられるクラスタソフト32の間で通信路を経由してハートビートと呼ばれる所定のパケットを定期的に交換し続け、互いの生存を通知し合う。
ディスクドライバ23は、上位(例えば、アプリケーション21)からのI/O(リードまたはライト)要求に基づいて、共有ディスク10に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ23は、上記した共有ディスク10に含まれるアクセス権管理テーブル12を参照して処理を実行する。
また、ディスクドライバ23は、例えば共有ディスク10に含まれるマスター領域11に対してライト処理(ライトアクセス)を実行する際に、当該ライト(アクセス)先となる領域に対応するブロック(ライト先ブロック)をサーバ20用のビットマップ(bitmap)テーブル(第1の計算機用テーブル)に登録する。つまり、ディスクドライバ23は、サーバ20用のビットマップテーブル(以下、第1のビットマップテーブルと表記)のライト先ブロックにbitを立てることによって、ライト先ブロックを登録する。第1のビットマップテーブルにおいては、マスター領域11に含まれる領域の各々に対応する複数のブロックを登録することができ、例えば1ブロックが1MBに対応する。以下に説明する第1のビットマップテーブル以外のビットマップテーブルについても同様である。
この第1のビットマップテーブルは、例えばサーバ20に備えられるメモリ(図示せず)にその領域が確保される。また、第1のビットマップテーブルは、上記した共有ディスク10のサーバ20用領域に保持される。
アクセス権ポーリングデーモン24は、共有ディスク10に含まれるアクセス権管理テーブル12を定期的(例えば、30秒毎)に参照する。アクセス権ポーリングデーモン24は、サーバ20によるアクセスが許可されている(つまり、サーバ20にアクセス権が設定されている)場合、例えば現在時間に予め定められた時間(例えば、60秒)を加えた有効期限(マスター領域11に対するアクセス権の有効期限)を設定し、この有効期限をサーバ20のディスクドライバ23に通知する。
サーバ30は、当該サーバ30上で動作するアプリケーション31、クラスタソフト32、ディスクドライバ33及びアクセス権ポーリングデーモン34を備える。
上記したように稼動系サーバであるサーバ20に備えられるクラスタソフト22及び待機系サーバであるサーバ30に備えられるクラスタソフト32の間では通信路を経由してハートビートと呼ばれる所定のパケットを交換し続け、互いの生存を通知し合う。
ここで、例えば待機系サーバであるサーバ30のクラスタソフト32によって稼動系サーバであるサーバ20のクラスタソフト22からのハートビートの断絶(クラスタソフト22からのハートビートが受信されなくなること)が検出された場合を想定する。この場合、サーバ30上ではサーバ20で起動されていたアプリケーション21の処理を継続するためにアプリケーション31が起動される。これにより、サーバ30でフェイルオーバが実行される。
なお、ハートビートが断絶する理由としては、例えば稼動系サーバの故障(ダウン)、サーバ20及びサーバ30間の通信路の障害またはサーバ20でCPU高負荷等による一時的なスローダウンの発生等がある。
クラスタソフト32は、クラスタソフト22からのハートビートの断絶が検出された場合、共有ディスク10に含まれるアクセス権管理テーブル12に対してマスター領域11に対するアクセス権をサーバ30に変更(設定)する。
クラスタソフト32は、上記した第1のビットマップテーブルに登録されているブロックに対応するマスター領域11(に含まれる領域)に格納されているデータを、当該マスター領域11とは異なる共有ディスク10上の別の領域であるログ領域(第2の領域)にコピーする。
クラスタソフト32は、サーバ20のマスター領域11に対するアクセス権の有効期限が確実に切れる時刻まで待機し、当該時刻後にアプリケーション31を起動する。
また、クラスタソフト32は、上記したフェイルオーバの完了後、一定時間が経過した場合に、上記したログ領域に格納されているデータをマスター領域11の対応する領域にコピーする。クラスタソフト32は、このコピー処理が完了すると、ログ領域を削除する。
ディスクドライバ33は、上位(例えば、アプリケーション31)からのI/O要求に基づいて、共有ディスク10に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ33は、I/O要求が上記した第1のビットマップテーブルに登録されているブロック(に対応する領域)に対する要求である場合には、上記したログ領域に対して当該要求に応じた処理(アクセス)を実行する。
また、ディスクドライバ33は、上記したディスクドライバ23と同様に、例えば共有ディスク10に含まれるマスター領域11に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック(ライト先ブロック)をサーバ30用のビットマップテーブル(第2の計算機用テーブル)に登録する。このサーバ30用のビットマップテーブル(以下、第2のビットマップテーブル)は、例えばサーバ30に備えられるメモリ(図示せず)上にその領域が確保される。また、第2のビットマップテーブルは、上記した共有ディスク10のサーバ30用領域14に保持される。
アクセス権ポーリングデーモン34は、上記したサーバ20のアクセス権ポーリングデーモン24と同様であるのでその詳しい説明は省略する。
次に、図2を参照して、上記したフェイルオーバについて説明する。ここでは、サーバ20は稼動系サーバ、サーバ30は待機系サーバとして動作しているものとする。
ここで、例えば稼動系サーバであるサーバ20でCPU高負荷による一時的なスローダウンが発生した場合を想定する。
この場合、待機系サーバであるサーバ30(のクラスタソフト33)は稼動系サーバ20(のクラスタソフト23)からのハートビートの断絶を検出する(ステップS1)。
次に、サーバ30のクラスタソフト33は、共有ディスク10に含まれるアクセス権管理テーブル12に対してマスター領域11に対するアクセス権をサーバ30に変更する(ステップS2)。
このとき、サーバ20のアクセス権ポーリングデーモン24は、アクセス権管理テーブル12においてアクセス権がサーバ20からサーバ30に変更されたため、サーバ20のマスター領域11に対するアクセス権の有効期限を更新しない。
上記したステップS2の処理が実行されると、サーバ30のクラスタソフト33は、サーバ20のアクセス権ポーリングデーモン24によって設定されたアクセス権の有効期限切れまで待機する。このアクセス権の有効期限が切れた後、サーバ30のクラスタソフト33はアプリケーション31を起動し、サーバ30によるマスター領域11に対するアクセスが開始される。
ここで、図2を参照して、フェイルオーバ前後にサーバ20においてなされるライト要求(ライト命令)について説明する。このライト要求は、例えばサーバ20と接続されたクライアント端末50からの要求に基づいて、サーバ20のアプリケーション21からディスクドライバ23に送信される。
ディスクドライバ23は、上記したサーバ20のマスター領域11に対するアクセス権の有効期限(サーバ20の有効期限)内においては、アプリケーション21から送信されるライト要求を含むI/O要求を共有ディスク10に送信する。また、ディスクドライバ23は、サーバ20の有効期限内においては、例えば共有ディスク10からのI/O要求に対する応答をアプリケーション21に返す。つまり、ディスクドライバ23は、サーバ20の有効期限内においては、I/O要求及び応答を通過させる機能を有する。
一方、サーバ20の有効期限外においては、アプリケーション21からI/O要求を受けた場合及び共有ディスク10から応答を受けた場合にはエラーが当該アプリケーション21に対して返される(エラーリターン)。
ここで、図2では、例えば上記したサーバ20の有効期限が切れた時点でのアプリケーション21によって送信されたI/O要求(ここでは、ライト要求)の状態を表す。ライト要求の状態は、図2に示すようにライト要求211〜214に大別される。
例えばライト要求211は、サーバ20の有効期限が切れた時点で既に正常に処理されているライト要求である。
ライト要求212は、サーバ20の有効期限が切れた時点で既にマスター領域11にライト処理が実行されているが、共有ディスク10からの応答がディスクドライバ23を通過していないのでサーバ20の有効期限切れによりエラーリターンとなるライト要求である。
ライト要求213は、サーバ20の有効期限が切れた時点でマスター領域11にはライト処理が実行されていないが、ディスクドライバ23を通過している。よって、ライト要求213は、サーバ20の有効期限が切れた後にマスター領域11にライト処理が実行されるが、上記したライト要求212と同様に共有ディスク10からの応答がディスクドライバ23を通過していないのでサーバ20の有効期限切れによりエラーリターンとなるライト要求である。
ライト要求214は、サーバ20の有効期限が切れた時点で当該ライト要求214がディスクドライバ23を通過していないので、マスター領域11に対してライト処理が実行されることなくエラーリターンとなるライト要求である。
上記したようにすることでフェイルオーバを境に元稼動系サーバ(サーバ20)からのライト要求は必ずエラーとなる仕組みを実現できる。この仕組みは、上記したようにサーバ20がスローダウンしていたとしても実現される。
ところで、上記したライト要求213においては、フェイルオーバ後に当該ライト要求213に応じたライト処理が実行されるため、元稼動系サーバであるサーバ20と元待機系(現稼動系)サーバであるサーバ30との両系書き込みによるデータ破壊のリスクがある。
図2に示すライト要求213の状態でサーバ20が上記したようにCPU高負荷による一時的なスローダウンが発生した場合を想定する。この場合、例えばライト要求213によるライト処理の対象となる領域と同一の領域に対してサーバ30によるライト処理がされた後にサーバ20のスローダウンが回復した場合には、当該サーバ30によるライト処理された領域がライト要求213によって上塗り(上書き)されることになる。これにより、データ破壊が生じる場合がある。
また、例えばライト要求213によるライト処理の対象となる領域と同一の領域に対してサーバ30によるリード処理がされた場合であっても、その後にライト要求213によるライト処理が実行された場合には、サーバ30が再度リード処理を同一の領域に対して実行したにもかかわらずリード結果の不一致という事態が生じる場合がある。
そこで、本実施形態に係るクラスタシステムにおいては、例えばライト要求213により上塗りされ得る領域(小領域)とそれ以外の領域を上記した別途設けられたビットマップテーブル(例えば、第1のビットマップテーブル)を用いて常に区分する。これにより、本実施形態においては、フェイルオーバ発生後から安定状態に落ち着くまでの間、上記した小領域の複製を持つことで、スプリットブレイン時にディスクデータの破壊を防ぎつつフェイルオーバさせる。
次に、図3及び図4を参照して、図1に示すクラスタシステムの仕組みの概略について説明する。
まず、図3に示すフェイルオーバ前の安定期(通常運転期)においては、稼動系サーバであるサーバ20においてアプリケーション21によって送信されるI/O要求に応じてライト処理またはリード処理がマスター領域11に対して実行される。
ここで、アプリケーション21によって送信されるI/O要求がライト要求である場合には、当該ライト要求によってライト処理される領域(ライト先ブロック)がサーバ20用のビットマップテーブル(第1のビットマップテーブル)131に登録される。なお、この第1のビットマップテーブル131は、共有ディスク10に含まれるサーバ20用領域13に保持されている。
図4に示すように、安定期(通常運転期)においては、マスター領域11(図4では、領域Bと表記)には、稼動系サーバであるサーバ20がライトし得る領域B1及び当該サーバ20がライトしない領域B2が含まれるが、第1のビットマップテーブル131には稼動系サーバであるサーバ20がライトし得る領域B1が登録される。
次に、例えばサーバ20からのハートビートの断絶が検出されることにより、待機系サーバであるサーバ30がフェイルオーバを実行した場合を想定する。
この場合、図3に示すようにフェイルオーバ直後においては、共有ディスク10のサーバ20用領域13に保持されている第1のビットマップテーブル131がサーバ30用領域14にコピーされる。
また、コピーされた第1のビットマップテーブルに登録されているブロック(に対応するマスター領域11の領域)に格納されているデータが当該マスター領域11とは異なる共有ディスク10上の別領域であるログ領域にコピーされる。なお、ログ領域は、例えばサーバ30用領域14に確保される。
フェイルオーバ直後においては、元稼動系サーバであるサーバ20において起動されていたアプリケーション21の処理を継続するために起動された現稼動系サーバであるサーバ30のアプリケーション31によって送信されるI/O要求に応じてライト処理またはリード処理がマスター領域11に対して実行される。
ここで、アプリケーション31によって送信されるI/O要求がライト要求である場合には、当該ライト要求に応じてライト先ブロックがサーバ30用のビットマップテーブル(第2のビットマップテーブル)141に登録される。なお、この第2のビットマップテーブル141は、共有ディスク10に含まれるサーバ30用領域14に保持されている。
また、アプリケーション31によって送信されるI/O要求が第1のビットマップテーブル131に登録されているブロックに対応する領域に対する要求である場合、当該I/O要求に応じた処理はログ領域に対して実行される。
図4に示すように、フェイルオーバ直後においては、マスター領域11には、元稼動系サーバであるサーバ20のライト要求(例えば、上記した図2におけるライト要求213)により上塗りされ得る領域A(小領域)及びそれ以外の領域Bが含まれる。領域Bには、現稼動系サーバであるサーバ30がライトし得る領域B1及び当該サーバ30がライトしない領域B2が含まれる。ここで、領域Aは、上記した図3に示す第1のビットマップテーブル131に登録されているブロックに対応する領域である。また、領域B1は、第2のビットマップテーブル141に登録されているブロックに対応する領域である。
また、マスター領域11とは別領域である領域Lは、上記した領域A(に格納されているデータ)がコピーされたログ領域である。この領域Lには、領域Aに格納されているデータがコピーされる。
次に、フェイルオーバの後、一定時間が経過した場合を想定する。この場合には、共有ディスク10、サーバ20及びサーバ30から構成されるクラスタシステムは安定期(片肺運転)となる。この一定時間とは、予め設定された例えば元稼動系サーバであるサーバ20におけるCPU高負荷による一時的なスローダウンが回復するために十分な時間である。
図3に示す安定期(片肺運転)においては、上記したログ領域に格納されているデータが当該ログ領域に対応するマスター領域11の領域(第1のビットマップテーブル131に登録されているブロックに対応する領域A)にコピーされる。
また、サーバ30用領域14に保持されている第1のビットマップテーブル131が当該サーバ30用領域から削除される。
また、安定期(片肺運転)時では、上記したフェイルオーバ直後と同様に、サーバ30のアプリケーション31によって送信されるI/O要求がライト要求である場合には、当該ライト要求に応じてライト先ブロックがサーバ30用のビットマップテーブル(第2のビットマップテーブル)141に登録される。
上記したように、本実施形態においては、フェイルオーバ直後から安定期(片肺運転)までは元稼動系サーバ(サーバ20)により上塗りされ得る領域A、マスター領域11における当該領域A以外の領域B及びマスター領域11とは別領域である領域L(ログ領域)の3つに分割されて管理される。
次に、図5のフローチャートを参照して、例えばサーバ20を稼動系サーバに移行する際の当該サーバ20のクラスタソフト22の処理手順について説明する。
ここでは、初期状態として、サーバ20及びサーバ30間ではクラスタソフト同士(クラスタソフト22及び32)がハートビートを交換し、互いの生存が確認できているものとする。また、サーバ20及びサーバ30共に、QUORUM用領域とマスター領域11が上位層から見えない(ディスクドライバ23及び33がフェンスオフ)状態であり、アプリケーション(アプリケーション21及び31)は起動されていないものとする。
まず、サーバ20のクラスタソフト22は、例えばユーザの操作に応じてサーバ20を稼動系サーバにする旨の通知をクライアント端末から受け取る(ステップS11)。
次に、クラスタソフト22は、共有ディスク10に含まれるアクセス権管理テーブル12を変更する(ステップS12)。この場合、クラスタソフト22は、アクセス権管理テーブル12においてマスター領域11に対するアクセス権をサーバ20に設定する。
クラスタソフト22は、サーバ20のディスクドライバ23に当該サーバ20が稼動系サーバとなった旨を通知する(ステップS13)。このとき、ディスクドライバ23は、上位層からマスター領域11が見える状態にする。
クラスタソフト22は、サーバ20のアプリケーション21を起動する(ステップS14)。
次に、図6のフローチャートを参照して、サーバ20が稼動系サーバに移行した後の当該サーバ20のディスクドライバ23の処理手順について説明する。
まず、ディスクドライバ23は、上位(アプリケーション21)からのI/O要求を入力する(ステップS21)。
次に、ディスクドライバ23は、例えばアクセス権ポーリングデーモン24から通知される有効期限に基づいて、アクセス権管理テーブル12にサーバ20のアクセス権(サーバ20のマスター領域11に対するアクセス権)が設定されているか否かを判定する。つまり、ディスクドライバ23は、サーバ20にマスター領域11に対するアクセス権があるか否かを判定する(ステップS22)。
サーバ20にアクセス権があると判定された場合(ステップS22のYES)、ディスクドライバ23は、入力されたI/O要求がマスター領域11へのライト要求であるか否かを判定する(ステップS23)。
マスター領域11へのライト要求であると判定された場合(ステップS23のYES)、ディスクドライバ23は、サーバ20に備えられるメモリ上に保持されている第1のビットマップテーブルを参照する。ディスクドライバ23は、ライト要求の対象となる領域に対応するブロック(ライト先ブロック)が第1のビットマップテーブルに登録済みであるか否かを判定する(ステップS24)。
ライト先ブロックが第1のビットマップテーブルに登録済みでないと判定された場合(ステップS24のNO)、ディスクドライバ23は、当該ライト先ブロックを当該第1のビットマップテーブルに登録する(ステップS25)。この場合、ディスクドライバ23は、サーバ20に備えられるメモリ上に保持されている第1のビットマップテーブル及び上記した共有ディスク10に含まれるサーバ20用領域13に保持されている第1のビットマップテーブルにライト先ブロックを登録する。
次に、ディスクドライバ23は、例えばアクセス権ポーリングデーモン24から通知される有効期限に基づいて、サーバ20にマスター領域11に対するアクセス権があるか否かを判定する(ステップS26)。
サーバ20にアクセス権があると判定された場合(ステップS26のYES)、ディスクドライバ23は、マスター領域11へのライト処理を実行する(ステップ27)。
ディスクドライバ23は、例えばアクセス権ポーリングデーモン24から通知される有効期限に基づいて、サーバ20にアクセス権があるか否かを判定する(ステップS28)。
サーバ20にアクセス権があると判定された場合(ステップS28のYES)、ディスクドライバ23は、例えば正常にライト処理が実行された旨の処理結果を上位へリターンする(ステップS29)。
一方、上記したステップS22、S26及びS28においてサーバ20にアクセス権がない、つまり、アクセス権ポーリングデーモン24から通知される有効期限が切れていると判定された場合には、エラーを上位へリターンする(ステップS30)。
また、ステップS23においてI/O要求がマスター領域11へのライト要求でない、つまり、例えばマスター領域11へのリード要求等であると判定された場合、下位の共有ディスク10にそのままI/O要求が渡され、ステップS28の処理が実行される。
また、ステップS24においてライト先ブロックが第1のビットマップテーブルに登録済みであると判定された場合、ステップS26の処理が実行される。
ここで、図7を参照して、サーバ20が稼動系サーバに移行した後の当該サーバ20のディスクドライバ23の処理について具体的に説明する。なお、共有ディスク10に含まれるアクセス権管理テーブル12には、マスター領域11に対するアクセス権がサーバ20に設定されているものとする。
まず、ディスクドライバ23は、アプリケーション21からのI/O要求を入力する(ステップS31)。ここでは、アプリケーション21からのI/O要求は、マスター領域11(LU1)に対するライト要求であるものとして説明する。
次に、ディスクドライバ23は、例えばアクセス権ポーリングデーモン24から通知される有効期限に基づいて、サーバ20にアクセス権があるか否かを判定する(ステップS32)。上記したようにアクセス権管理テーブル12にはサーバ20のアクセス権が設定されているため、ここではサーバ20にアクセス権があると判定される。
ディスクドライバ23は、アプリケーション21から入力されたライト要求の対象となる領域に対応するブロック(ライト先ブロック)がサーバ20に備えられたメモリ上に保持されている第1のビットマップテーブル131に登録済みであるか否かを判定する。なお、図7に示すように、第1のビットマップテーブル131は、上記したサーバ20に備えられたメモリ以外に、共有ディスク10に含まれるサーバ20用領域13に保持されている。
ここで、ライト先ブロックが第1のビットマップテーブル131に登録済みでない場合を想定する。この場合、ディスクドライバ23は、サーバ20に備えられたメモリ上に保持されている第1のビットマップテーブル131にライト先ブロックを登録する(ステップS33)。
また、ディスクドライバ23は、共有ディスク10に含まれるサーバ20用領域13に保持されている第1のビットマップテーブル131にライト先ブロックを登録する(ステップS34)。
次に、ディスクドライバ23は、上記したステップS32に相当するステップS35の処理を実行する。つまり、ディスクドライバ23は、サーバ20にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル12は変更されておらず、サーバ20にアクセス権があると判定されたものとする。
ディスクドライバ23は、アプリケーション21から入力されたライト要求に応じてマスター領域11に対するライト処理を実行する(ステップS36)。
ディスクドライバ23は、上記したステップS32(またはステップS35)の処理に相当するステップS37の処理を実行する。ここで、サーバ20にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション21に返される。
一方、上記したステップS32、S35及びS37においてサーバ20にアクセス権がないと判定された場合には、アプリケーション21にエラーが返される。このステップS32、S35及びS37においては、上記したようにサーバ30(のクラスタソフト32)によってアクセス権管理テーブル12が変更された場合に、サーバ20にアクセス権がないと判定される。
次に、図8のフローチャートを参照して、サーバ30においてフェイルオーバが実行される際の当該サーバ30のクラスタソフト32の処理手順について説明する。
ここでは、サーバ20が稼動系サーバ、サーバ30が待機系サーバであるものとして説明する。
まず、待機系サーバであるサーバ30のクラスタソフト32は、稼動系サーバであるサーバ20のクラスタソフト22からのハートビートの断絶を検出する(ステップS41)。このハートビートの断絶は、例えば稼動系サーバであるサーバ20の故障によるダウンの他、例えばサーバ20及びサーバ30間の通信路の障害、またはサーバ20でCPU高負荷等による一時的なスローダウン等により発生し得る。
次に、クラスタソフト32は、共有ディスク10に含まれるアクセス権管理テーブル12を変更する(ステップS42)。この場合、クラスタソフト32は、マスター領域11に対するアクセス権をサーバ30に設定する。
アクセス権管理テーブル12が変更されると、サーバ30のアクセス権ポーリングデーモン34は、サーバ30の有効期限を設定し、当該有効期限をサーバ30のディスクドライバ33に通知する。アクセス権ポーリングデーモン34は、定期的にアクセス権管理テーブル12を参照し、サーバ30のアクセス権が設定されている場合には有効期限を更新する。
クラスタソフト32は、共有ディスク10に含まれるサーバ20用領域13に保持されている第1のビットマップテーブルを、当該共有ディスク10上の別領域である例えばサーバ30用領域14にコピーする(ステップS43)。つまり、クラスタソフト32は、第1のビットマップテーブルのコピーを、サーバ30用領域14上に作成する。
また、クラスタソフト32は、第1のビットマップテーブルを例えばサーバ30に備えられるメモリ上にコピーする。つまり、クラスタソフト32は、第1のピットマップテーブルのコピーを、サーバ30に備えられるメモリ上に作成する。
クラスタソフト32は、サーバ30用領域14にコピーされた第1のビットマップテーブル(第1のビットマップテーブルのコピー)に登録されているブロックのブロック番号及び当該ブロック(に対応する領域)に格納されているデータをマスター領域11とは別の領域(ログ領域)にコピーする(ステップS44)。
クラスタソフト32は、サーバ20のアクセス権ポーリングデーモン24によって設定されたサーバ20のアクセス権の有効期限が確実に切れる時刻まで待機する(ステップS45)。
クラスタソフト32は、サーバ30のディスクドライバ33に当該サーバ30が稼動系サーバとなった旨を通知する(ステップS46)。このとき、ディスクドライバ33は、上位層からマスター領域11が見える状態にする。
クラスタソフト32は、サーバ30のアプリケーション31を起動する(ステップS47)。これにより、フェイルオーバが完了される。
次に、図9のフローチャートを参照して、上記したフェイルオーバ直後のサーバ30のディスクドライバ33の処理手順について説明する。
まず、ディスクドライバ33は、上位(アプリケーション31)からのI/O要求を入力する(ステップS51)。
次に、ディスクドライバ33は、例えばアクセス権ポーリングデーモン34から通知される有効期限に基づいて、アクセス権管理テーブル12にサーバ30のアクセス権が設定されているか否かを判定する。つまり、ディスクドライバ33は、サーバ30にマスター領域11に対するアクセス権があるか否かを判定する(ステップS52)。
サーバ30にアクセス権があると判定された場合(ステップS52のYES)、ディスクドライバ33は、入力されたI/O要求がマスター領域11へのライト要求であるか否かを判定する(ステップS53)。
マスター領域11へのライト要求であると判定された場合(ステップS53のYES)、ディスクドライバ33は、サーバ30に備えられるメモリ上に保持されている第2のビットマップテーブルを参照する。ディスクドライバ33は、ライト要求の対象となる領域に対応するブロック(ライト先ブロック)が第2のビットマップテーブルに登録済みであるか否かを判定する(ステップS54)。
ライト先ブロックが第2のビットマップテーブルに登録済みでないと判定された場合(ステップS54のNO)、ディスクドライバ33は、当該ライト先ブロックを当該第2のビットマップテーブルに登録する(ステップS55)。この場合、ディスクドライバ33は、サーバ30bに備えられるメモリ上に保持されている第2のビットマップテーブル及び共有ディスク10に含まれるサーバ30用領域14に保持されている第2のビットマップテーブルにライト先ブロックを登録する。
次に、ディスクドライバ33は、例えばアクセス権ポーリングデーモン34から通知される有効期限に基づいて、サーバ30にマスター領域11に対するアクセス権があるか否かを判定する(ステップS56)。
サーバ30にアクセス権があると判定された場合(ステップS56のYES)、ディスクドライバ33は、ライト先ブロックがサーバ30に備えられるメモリ上に保持されている第1のビットマップテーブル(第1のビットマップテーブルのコピー)に登録済みであるか否かを判定する(ステップS57)。
ここで、ステップS57においては、例えばサーバ20用領域13に保持されている第1のビットマップテーブルでなく、サーバ30に備えられるメモリ上の第1のビットマップテーブルのコピーを用いて判定処理が実行される。これにより、例えば判定処理中にサーバ20用領域13に保持されている第1のビットマップテーブルがサーバ20によって更新されるような場合であっても誤動作を行うことなく処理を実行することが可能となる。
ライト先ブロックが第1のビットマップテーブルに登録済みであると判定された場合(ステップS57のYES)、ディスクドライバ33は、上記したクラスタソフト32によって第1のビットマップテーブルに登録されているブロックの番号及び当該ブロック(に対応する領域)に格納されているデータがコピーされているログ領域へのライト処理を実行する(ステップS58)。このとき、ディスクドライバ33は、ログ領域のうち、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
一方、ライト先ブロックが第1のビットマップテーブルに登録済みでないと判定された場合(ステップS57のNO)、ディスクドライバ33は、マスター領域11へのライト処理を実行する(ステップS59)。
ディスクドライバ33は、例えばアクセス権ポーリングデーモン34から通知される有効期限に基づいて、サーバ30にアクセス権があるか否かを判定する(ステップS60)。
サーバ30にアクセス権があると判定された場合(ステップS60のYES)、ディスクドライバ33は、例えば正常にライト処理が実行された旨の処理結果を上位へリターンする(ステップS61)。
一方、上記したステップS52、S56及びS60においてサーバ30にアクセス権がない、つまりアクセス権ポーリングデーモン34から通知される有効期限が切れていると判定された場合には、エラーを上位へリターンする(ステップS61)。
また、ステップS53においてI/O要求がマスター領域11へのライト要求でない、
例えばマスター領域11へのリード要求等であると判定された場合、当該リード要求に応じて共有ディスク10に対してリード処理が実行される。この場合、上述したリード結果の不一致という事態を避けるために、リード要求の対象となる領域に対応するブロック(リード先ブロック)が第1のビットマップテーブルに登録済みである場合にはログ領域に対してリード処理が実行される。このリード処理が実行されると、ステップS60の処理が実行される。
一方、例えばマスター領域11以外へのI/O要求である場合には、下位の共有ディスク10にそのままI/O要求が渡され、ステップS60の処理が実行される。
また、ステップS54においてライト先ブロックが第2のビットマップテーブルに登録済みであると判定された場合、ステップS56の処理が実行される。
つまり、上記したようにフェイルオーバ直後においては、第1のビットマップテーブルに登録されているサーバ20からのライト要求により上塗りされる可能性のある領域(小領域)をアクセス先とするサーバ30からのアクセスは、ログ領域に対して行われることになる。
図10を参照して、サーバ30においてフェイルオーバが実行される際の当該サーバ30のクラスタソフト32及びディスクドライバ33の処理について具体的に説明する。なお、フェイルオーバが実行される以前の共有ディスク10に含まれるアクセス権管理テーブル12には、稼動系サーバであるサーバ20にアクセス権が設定されているものとする。
ここで、待機系サーバであるサーバ30のクラスタソフト32が、稼動系サーバであるサーバ20のクラスタソフト22からのハートビートの断絶を検出したものとする。
この場合、サーバ30のクラスタソフト32は、共有ディスク10に含まれるアクセス権管理テーブル12を変更する(ステップS71)。クラスタソフト32は、マスター領域11に対するアクセス権をサーバ30に設定する。これにより、サーバ30は、マスター領域11(LU1)へのアクセス権をサーバ20から奪う。
図10に示す例では、サーバ20の「○」を「×」に変更し、サーバ30の「×」を「○」に変更する。これにより、サーバ30にマスター領域11へのアクセス権が設定される。
アクセス権管理テーブル12が変更されると、サーバ30のアクセス権ポーリングデーモン34は、サーバ30の有効期限を設定し、当該有効期限をサーバ30のディスクドライバ33に通知する。
クラスタソフト32は、共有ディスク10に含まれるサーバ20用領域13に保持されている第1のビットマップテーブル131を、サーバ30用領域14にコピーする(ステップS72)。
また、クラスタソフト32は、第1のビットマップテーブル131をサーバ30に備えられるメモリ上にコピーする(ステップS73)。
クラスタソフト32は、サーバ30用領域14にコピーされた第1のビットマップテーブル131に登録されているブロックのブロック番号及び当該ブロック(に対応する領域)に格納されているデータを、マスター領域11からログ領域142にコピーする(ステップS74、S75)。このログ領域142は、共有ディスク10に含まれる例えばサーバ30用領域14にその領域が確保される。
上記した処理が実行されると、クラスタソフト32は、サーバ20のアクセス権の有効期限が確実に切れる時刻まで待機した後、アプリケーション31を起動させる。
クラスタソフト32によってアプリケーション31が起動されると、サーバ30のディスクドライバ33は、アプリケーション31からのI/O要求を入力する(ステップS76)。ここでは、アプリケーション31からのI/O要求は、マスター領域11に対するライト要求であるものとして説明する。
次に、ディスクドライバ33は、例えばアクセス権ポーリングデーモン34から通知される有効期限に基づいて、サーバ30にアクセス権があるか否かを判定する(ステップS77)。上記したステップS71の処理においてアクセス権管理テーブル12にはクラスタソフト32によってサーバ30にアクセス権が設定されているため、ここではサーバ30にアクセス権があると判定される。
ディスクドライバ33は、アプリケーション31から入力されたライト要求の対象となる領域に対応するブロック(ライト先ブロック)がサーバ30に備えられたメモリ上に保持されている第2のビットマップテーブル141に登録済みであるか否かを判定する。なお、図10に示すように第2のビットマップテーブル141は、上記したサーバ30に備えられたメモリ以外に、共有ディスク10に含まれるサーバ30用領域14に保持される。
ここで、ライト先ブロックが第2のビットマップテーブル141に登録済みでない場合を想定する。この場合、ディスクドライバ33は、サーバ30に備えられたメモリ上に保持されている第2のビットマップテーブル141にライト先ブロックを登録する(ステップS78)。
また、ディスクドライバ33は、共有ディスク10に含まれるサーバ30用領域14に保持されている第2のビットマップテーブル141にライト先ブロックを登録する(ステップS79)。
次に、ディスクドライバ33は、上記したステップS77に相当するステップS80の処理を実行する。つまり、ディスクドライバ33は、サーバ30にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル12は変更されておらず、サーバ30にアクセス権があると判定されたものとする。
ディスクドライバ33は、サーバ30に備えられるメモリ上に保持されている第1のビットマップテーブル131を参照する(ステップS81)。これにより、ディスクドライバ33は、アプリケーション31から入力されたライト要求の対象となる領域に対応するブロック(ライト先ブロック)が第1のビットマップテーブル131に登録済みであるか否かを判定する。
ここで、ライト先ブロックが第1のビットマップテーブル131に登録済みであると判定された場合を想定する。この場合には、ディスクドライバ33は、上記したクラスタソフト32によって第1のビットマップテーブル131に登録されているブロックのブロック番号及び当該ブロック(に対応する領域)に格納されているデータがコピーされているログ領域142に対してライト処理を実行する(ステップS82)。このとき、ディスクドライバ33は、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
一方、ライト先ブロックが第1のビットマップテーブル131に登録済みでない場合を想定する。この場合には、ディスクドライバ33は、アプリケーション31から入力されたライト要求に応じてマスター領域11に対するライト処理を実行する(ステップS83)。
ディスクドライバ33は、上記したステップS77(またはステップS80)の処理に相当するステップS84の処理を実行する。ここで、サーバ30にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション31に返される。
一方、上記したステップS77、S80及びS84においてサーバ30にアクセス権がないと判定された場合には、アプリケーション31にエラーが返される。
次に、図11のフローチャートを参照して、フェイルオーバが完了し、一定時間が経過した後のサーバ30のクラスタソフト32の処理手順について説明する。この一定時間とは、例えば元稼動系サーバであるサーバ20におけるCPU高負荷による一時的なスローダウンが回復するために十分な時間であり、予め定められている。
まず、サーバ30のクラスタソフト32は、当該サーバ30に備えられているメモリ上に保持されている第1のビットマップテーブルを削除する(ステップS91)。
次に、クラスタソフト32は、共有ディスク10に含まれるサーバ30用領域14内に保持されている第1のビットマップテーブルを削除する(ステップS92)。
クラスタソフト32は、共有ディスク10に含まれるサーバ30用領域14に確保されているログ領域に格納されているデータを、マスター領域11の当該ログ領域に対応する場所(領域)にコピーする(ステップS93)。
ステップ93に示すコピー処理が完了されると、クラスタソフト32は、サーバ30用領域14に確保されているログ領域を削除する(ステップS94)。
なお、図11に示すクラスタソフト32の処理後においては、サーバ30のディスクドライバ33では上述した図6に示す処理に相当する処理が実行される。
ここで、図12を参照して、フェイルオーバが完了し、一定時間が経過した後のサーバ30のクラスタソフト32及びディスクドライバ33の処理について具体的に説明する。
まず、サーバ30のクラスタソフト32は、当該サーバ30に備えられているメモリ上に保持されている第1のビットマップテーブル131を削除する(ステップS101)。
次に、クラスタソフト32は、共有ディスク10に含まれるサーバ30用領域14に保持されている第1のビットマップテーブル131を削除する(ステップS102)。
クラスタソフト32は、共有ディスク10に含まれるサーバ30用領域14に確保されているログ領域142に格納されているデータをマスター領域11の対応する領域にコピーし、当該ログ領域142(に格納されているデータ)を削除する(ステップS103)。
ここで、上記したサーバ30のクラスタソフト32の処理の完了後に、当該サーバ30のディスクドライバ33がサーバ30上で起動されているアプリケーション31からI/O要求を入力したものとする(ステップS104)。このI/O要求は、マスター領域11(LU1)に対するライト要求であるものとして説明する。
次に、ディスクドライバ33は、例えばアクセス権ポーリングデーモン24から通知される有効期限に基づいて、サーバ30にアクセス権があるか否かを判定する(ステップS105)。ここでは、図12に示すようにアクセス権管理テーブル12にはサーバ30のアクセス権が設定されているものとする。つまり、ディスクドライバ33によってサーバ30にアクセス権があると判定されたものとする。
ディスクドライバ33は、アプリケーション31から入力されたライト要求の対象となる領域(ライト先ブロック)がサーバ30に備えられたメモリ上に保持されている第2のビットマップテーブル141に登録済みであるか否かを判定する。なお、図12に示すように第2のビットマップテーブル141は、上記したサーバ30に備えられたメモリ以外に、共有ディスク10に含まれるサーバ30用領域14に保持される。
ここで、ライト先ブロックが第2のビットマップテーブル141に登録済みでない場合を想定する。この場合、ディスクドライバ33は、サーバ30に備えられたメモリ上に保持されている第2のビットマップテーブル141にライト先ブロックを登録する(ステップS106)。
また、ディスクドライバ33は、共有ディスク10に含まれるサーバ30用領域14に保持されている第2のビットマップテーブル141にライト先ブロックを登録する(ステップS107)。
次に、ディスクドライバ33は、上記したステップS105の処理に相当するステップS108の処理を実行する。つまり、ディスクドライバ33は、サーバ30にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル12は変更されておらず、サーバ30にアクセス権があると判定されたものとする。
ディスクドライバ33は、アプリケーション31から入力されたライト要求に応じてマスター領域11に対するライト処理を実行する(ステップS109)。
ディスクドライバ33は、上記したステップS105(またはステップS108)の処理に相当するステップS110の処理を実行する。ここで、サーバ30にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション31に返される。
一方、上記したステップS105、S108及びS110においてサーバ30にアクセス権がないと判定された場合には、アプリケーション31にエラーが返される。
ここでは、図11に示す処理がフェイルオーバの後に一定期間が経過した後に実行されるものとして説明したが、この処理は、例えば元稼動系サーバであるサーバ20(のクラスタソフト22)からハートビートが検出された後、つまり、サーバ20で発生したスローダウンの回復が確認され、当該サーバ20からのライトアクセスが確実に停止された後に実行されても構わない。
上記したように本実施形態においては、通常運転時に稼動系サーバであるサーバ20によりマスター領域11に対してライト処理が実行される場合に当該ライト処理に応じてライト先ブロックが第1のビットマップテーブルに登録される。この後、サーバ20からサーバ30にフェイルオーバが実行された場合、当該フェイルオーバ直後におけるサーバ30からの第1のビットマップテーブルに登録されているブロック(に対応する領域)に対するアクセスは、当該第1のビットマップテーブルに登録されているブロック(のブロック番号及び当該ブロックに格納されているデータ)がコピーされたログ領域に対して実行される。そして、例えばサーバ20のスローダウンが回復するのに十分な時間(一定時間)経過後にログ領域(に格納されているデータ)がマスター領域11にコピーされる。これにより、本実施形態においては、現稼動系サーバであるサーバ30によってマスター領域11に対してライト処理が実行された後に、当該ライト処理が実行されたブロックと同一の領域に対して元稼動系サーバであるサーバ20からのライト要求によってデータが上塗りされた場合であっても当該上塗りされた領域にはログ領域がコピーされるので、当該上塗りされることによって生じるデータ破壊を防止することが可能となる。同様に、本実施形態においては、例えば現稼動系サーバであるサーバ30によってリード処理が実行された領域と同一の領域に対して元稼動系サーバであるサーバ20からのライト要求によってデータが上塗りされることによって生じるリード結果の不一致を防止することが可能となる。
[第2の実施形態]
次に、図13を参照して、本発明の第2の実施形態に係るクラスタシステムについて説明する。図13は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。なお、前述した図1と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図1と異なる部分について主に述べる。以下の各実施形態についても同様にして重複した説明を省略する。
図13に示すように、本実施形態に係るクラスタシステムは、複数のサーバ及び共有ディスク100を備える。複数のサーバは、サーバ(第3の計算機)40を含む。
また、共有ディスク100及びサーバ40は、例えばFCケーブルで接続されている。サーバ40は、例えばサーバ30と2本の通信路を介して通信可能に接続されている。
共有ディスク100は、アクセス権管理テーブル121を含む。このアクセス権管理テーブル121には、クラスタシステムを構成するサーバ20、30及び40のそれぞれについて、共有ディスク100のマスター領域11へのアクセスの許可または不許可が設定される。図13に示すように、アクセス権管理テーブル121において例えばLU1に対応付けてサーバ20に「×」、サーバ30に「○」、サーバ40に「×」が設定されている場合には、サーバ30にアクセス権が設定されており、他のサーバ20及び40はマスター領域11へのアクセスが許可されていない。
また、共有ディスク10は、サーバ40用のデータ領域(以下、サーバ40用領域と表記)15を含む。このサーバ40用領域15には、例えばサーバ40によってライト処理が実行される際に当該ライト先となる領域に対応するブロックが登録されるサーバ40用のビットマップテーブル(以下、第3のビットマップテーブルと表記)が保持される。
サーバ40は、当該サーバ40上で動作するアプリケーション31、クラスタソフト42、ディスクドライバ43及びアクセス権ポーリングデーモン44を備える。
ここで、前述したようにサーバ30においてフェイルオーバが実行され、サーバ30が稼動系サーバである場合を想定する。この場合には、サーバ40は、サーバ30の待機系サーバとして動作する。
稼動系サーバであるサーバ30に備えられるクラスタソフト32及び待機系サーバであるサーバ40に備えられるクラスタソフト42の間では通信路を経由してハートビートを交換し続け、互いの生存を通知し合う。
例えば待機系サーバであるサーバ40のクラスタソフト42によって稼動系サーバであるサーバ30のクラスタソフト32からのハートビートの断絶が検出された場合には、サーバ40上ではサーバ30で起動されていたアプリケーション31の処理を継続するためにアプリケーション41が起動される。これにより、サーバ40はフェイルオーバを実行する。
クラスタソフト42は、サーバ30のクラスタソフト32からのハートビートの断絶が検出された場合、共有ディスク100に含まれるアクセス権管理テーブル121に対してマスター領域11に対するアクセス権をサーバ40に変更(設定)する。
クラスタソフト42は、前述した第1のビットマップテーブル及び第2のビットマップテーブルに登録されているブロックに対応するマスター領域11(に含まれる領域)に格納されているデータを、当該マスター領域11とは異なる共有ディスク100上の別の領域であるログ領域(第3の領域)にコピーする。このログ領域は、例えば上記したサーバ40用領域15内にその領域が確保される。
クラスタソフト42は、サーバ30のマスター領域11に対するアクセス権の有効期限が確実に切れる時刻まで待機し、当該時刻後にアプリケーション41を起動する。
また、クラスタソフト42は、上記したフェイルオーバが完了し、更に一定時間が経過した場合に、上記したログ領域に格納されているデータをマスター領域11の対応する領域にコピーする。クラスタソフト42は、このコピー処理が完了すると、ログ領域を削除する。
ディスクドライバ43は、上位(例えば、アプリケーション41)からのI/O要求に基づいて、共有ディスク100に対してデータのリードまたはライト処理を実行する。この場合、ディスクドライバ43は、I/O要求が上記した第1のビットマップテーブル及び第2のビットマップテーブルに登録されている領域に対する要求である場合には、上記したサーバ40用領域15に含まれるログ領域に対して当該要求に応じた処理を実行する。
また、ディスクドライバ43は、例えば共有ディスク100に含まれるマスター領域11に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック(ライト先ブロック)を上記した第3のビットマップテーブルに登録する。この第3のビットマップテーブルは、例えばサーバ40に備えられるメモリ(図示せず)上にその領域が確保される。また、第3のビットマップテーブルは、上記した共有ディスク100のサーバ40用領域15に保持される。
アクセス権ポーリングデーモン44は、前述したサーバ20のアクセス権ポーリングデーモン24(またはサーバ30のアクセス権ポーリングデーモン34)と同様であるのでその詳しい説明は省略する。
つまり、本実施形態においては、上記したようにサーバ20、30及び40の3台系のクラスタシステムを想定している。このクラスタシステムにおいて、サーバ20からサーバ30へのフェイルオーバ直後にサーバ30で障害等が発生した場合には、サーバ40に処理が引き継がれる。この場合には、サーバ40においては前述した第1の実施形態におけるサーバ30と同様にフェイルオーバが実行される。
次に、図14を参照して、サーバ40においてフェイルオーバが実行される際の当該サーバ40のクラスタソフト42及びディスクドライバ43の処理について具体的に説明する。
ここでは、上記したようにサーバ20からサーバ30へのフェイルオーバ直後にサーバ30で例えばCPU高負荷等によるスローダウンが発生し、サーバ40でフェイルオーバが実行される場合を想定している。よって、サーバ40でフェイルオーバが実行される以前の共有ディスク100に含まれるアクセス権管理テーブル121には、稼動系サーバであるサーバ30にアクセス権が設定されているものとする。
まず、待機系サーバであるサーバ40のクラスタソフト42が、稼動系サーバであるサーバ30のクラスタソフト32からのハートビートの断絶を検出したものとする。
この場合、サーバ40のクラスタソフト42は、共有ディスク100に含まれるアクセス権管理テーブル121を変更する(ステップS111)。クラスタソフト42は、マスター領域11に対するアクセス権をサーバ40に設定する。これにより、サーバ40は、マスター領域11(LU1)へのアクセス権をサーバ30から奪う。
図14に示す例では、サーバ30の「○」が「×」に変更され、サーバ40の「×」が「○」に変更される。これにより、サーバ40にマスター領域11へのアクセス権が設定される。
アクセス権管理テーブル121が変更されると、サーバ40のアクセス権ポーリングデーモン44は、サーバ40の有効期限を設定し、当該有効期限をサーバ40のディスクドライバ43に通知する。
クラスタソフト42は、共有ディスクに含まれるサーバ20用領域13に保持されている第1のビットマップテーブル131及びサーバ30用領域14に保持されている第2のビットマップテーブル141が組み合わされたビットマップテーブル(以下、第4のビットマップテーブルと表記)151をサーバ40用領域15にコピー(作成)する(ステップS112)。この第4のビットマップテーブル151には、第1のビットマップテーブル131及び第2のビットマップテーブルに登録されているブロックが登録されている。
また、クラスタソフト42は、第4のビットマップテーブル151をサーバ40に備えられるメモリ上にコピーする(ステップS113)。
クラスタソフト42は、サーバ40用領域15にコピーされた第4のビットマップテーブル151を参照して、上記した第1のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロック(に対応する領域)に格納されているデータとしてサーバ30用領域14に含まれているログ領域142のブロック番号及びデータをログ領域152にコピーする(ステップS1l4、ステップS115)。
また、クラスタソフト42は、サーバ40用領域15にコピーされた第4のビットマップテーブル151を参照して、上記した第2のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータを、マスター領域11からログ領域52にコピーする(ステップS114、ステップS116)。
このステップS114〜ステップS116の処理によって、第4のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータが、ログ領域152にコピーされる。
このログ領域152は、共有ディスク100に含まれる例えばサーバ40用領域15にその領域が確保される。
上記した処理が実行されると、クラスタソフト42は、サーバ30のアクセス権の有効期限が確実にけれる時刻まで待機した後、アプリケーション41を起動させる。
クラスタソフト42によってアプリケーション41が起動されると、サーバ40のディスクドライバ43は、アプリケーション41からのI/O要求を入力する(ステップS117)。ここでは、アプリケーション41からのI/O要求は、マスター領域11に対するライト要求であるものとして説明する。
次に、ディスクドライバ43は、例えばアクセス権ポーリングデーモン44から通知される有効期限に基づいて、サーバ40にアクセス権があるか否かを判定する(ステップS118)。上記したステップS111の処理においてアクセス権管理テーブル121にはクラスタソフト42によってサーバ40にアクセス権が設定されているため、ここではサーバ40にアクセス権があると判定される。
ディスクドライバ43は、アプリケーション41から入力されたライト要求の対象となるライト先ブロックがサーバ40に備えられたメモリ上に保持されている第3のビットマップテーブル153に登録済みであるか否かを判定する。なお、図14に示すように第3のビットマップテーブル151は、上記したサーバ40に備えられたメモリ以外に、共有ディスク100に含まれるサーバ40用領域15に保持される。
ここで、ライト先ブロックが第3のビットマップテーブル153に登録済みでない場合を想定する。この場合、ディスクドライバ43は、サーバ40に備えられたメモリ上に保持されている第3のビットマップテーブル153にライト先ブロックを登録する(ステップS119)。
また、ディスクドライバ43は、共有ディスク100に含まれるサーバ40用領域15に保持されている第3のビットマップテーブル153にライト先ブロックを登録する(ステップS120)。
次に、ディスクドライバ43は、上記したステップS118に相当するステップS121の処理を実行する。つまり、ディスクドライバ43は、サーバ40にアクセス権があるか否かを判定する。ここでは、アクセス権管理テーブル121は変更されておらず、サーバ40にアクセス権があると判定されたものとする。
ディスクドライバ43は、サーバ40に備えられるメモリ上に保持されている第4のビットマップテーブル151を参照する(ステップS122)。これにより、ディスクドライバ43は、アプリケーション41から入力されたライト要求の対象となる領域に対応するブロック(ライト先ブロック)が第4のビットマップテーブル151に登録済みであるか否かを判定する。
ここで、ライト先ブロックが第4のビットマップテーブル151に登録済みであると判定された場合を想定する。この場合には、ディスクドライバ43は、上記したクラスタソフト42によって第4のビットマップテーブル151に登録されているブロックのブロック番号及び当該ブロック(に対応する領域)に格納されているデータがコピーされているログ領域152に対してライト処理を実行する(ステップS123)。このとき、ディスクドライバ43は、ライト先ブロックのブロック番号及び当該ブロックに格納されているデータがコピーされた領域に対してライト処理を実行する。
一方、ライト先ブロックが第4のビットマップテーブル151に登録済みでないと判定された場合を想定する。この場合には、ディスクドライバ43は、アプリケーション41から入力されたライト要求に応じてマスター領域11に対するライト処理を実行する(ステップS124)。
ディスクドライバ43は、上記したステップS118(またはステップS121)の処理に相当するステップS125の処理を実行する。ここで、サーバ40にアクセス権があると判定されると、例えば正常にライト処理が完了した旨を示す処理結果がアプリケーション41に返される。
一方、上記したステップS118、S121及びS125においてサーバ40にアクセス権がないと判定された場合には、アプリケーション41にエラーが返される。
上記したように本実施形態においては、例えばサーバ20、30及び40の3台系のクラスタシステムにおいてサーバ20からサーバ30にフェイルオーバが実行された直後に当該サーバ30からサーバ40にフェイルオーバが実行された(多段フェイルオーバが発生した)場合には、当該サーバ40からのアクセスは、第1のビットマップテーブル及び第2のビットマップテーブルが組み合わされた第4のビットマップテーブルに登録されているブロックのブロック番号及び当該ブロックに格納されているデータがコピーされたログ領域に対して実行される。これにより、本実施形態においては、上記したサーバ20、30及び40の3台系のクラスタシステムのような多台系のクラスタシステムで多段フェイルオーバが発生した場合であっても、処理を複雑化することなくデータ破壊を防止することが可能となる。
[第3の実施形態]
次に、図15を参照して、本発明の第3の実施形態に係るクラスタシステムについて説明する。図15は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。
図15に示すように、本実施形態に係るクラスタシステムにおいては、サーバ20は、テーブル整理デーモン25を備える。
また、本実施形態においては、前述した第1の実施形態とは異なり、サーバ20に備えられるメモリ上には、第1のビットマップテーブルに代えてイントマップ(intmap)テーブルが保持される。第1のビットマップテーブルとは異なり、このイントマップテーブルにおいては、4バイトが1ブロックに対応する。イントマップテーブルには、1ブロック毎に例えばintの値が登録される。
ディスクドライバ23は、例えば共有ディスク10に含まれるマスター領域11に対してライト処理を実行する場合には、当該ライト先となる領域に対応するブロック(ライト先ブロック)をサーバ20に備えられるメモリ上に保持されるイントマップテーブルに登録する。
このとき、ライト先ブロックがイントマップテーブルに登録されていない場合、つまり、ライト先ブロックへの初書き込みの場合には、当該ライト先ブロックに対応するintの値として現在のシーケンス(sequence)番号が登録される。一方、ライト先ブロックが既にイントマップテーブルに登録されている場合には、例えば当該ライト先ブロックに対応するintの値に1を加えた値(つまり、シーケンス番号+1)を登録する。
これにより、イントマップテーブルにおいては、当該イントマップテーブルに登録されているintの値(シーケンス番号)に応じて、当該値に対応するブロックへのアクセス頻度が示される。
テーブル整理デーモン25は、例えば定期的にイントマップテーブルを参照する。テーブル整理デーモン25は、イントマップテーブルに登録済みのブロック数が予め定められた値(以下、閾値と表記)以上であるか否かを判定する。
テーブル整理デーモン25は、例えばイントマップテーブルにおいて古いシーケンス番号を持つintの値をクリア(=0)する。つまり、テーブル整理デーモン25は、アクセス頻度の少ない登録済みのブロックをイントマップテーブルから未登録とする。
テーブル整理デーモン25は、intの値がクリアされたブロックを共有ディスク10に含まれるサーバ20用領域に保持されている第1のビットマップテーブルから未登録とする。これにより、テーブル整理デーモン25は、アクセス頻度の少ないブロックを削除することによって登録済みのブロック数を閾値以下にする。
次に、図16を参照して、図15に示すクラスタシステムを構成するサーバ20が稼動系サーバに移行した後の当該サーバ20のディスクドライバ23及びテーブル整理デーモンの処理について具体的に説明する。なお、共有ディスク10に含まれるアクセス権管理テーブル12には、サーバ20のマスター領域11に対するアクセス権が設定されているものとする。
まず、前述した図7に示すステップS31及びステップS32の処理に相当するステップS131及びステップS132の処理が実行される。なお、ステップS131で入力されたI/O要求は、マスター領域11(LU1)に対するライト要求であるものとする。
次に、ディスクドライバ23は、アプリケーション21から入力されたライト要求の対象となる領域に対応するブロック(ライト先ブロック)をサーバ20に備えられたメモリ上に保持されているイントマップテーブル132に登録する(ステップS133)。
このとき、ライト先ブロックがイントマップテーブル132に登録されていない場合、つまり、当該ライト先ブロックへの初書き込みである場合には、ディスクドライバ23は、当該ライト先ブロックに対応するintの値として現在のシーケンス番号を登録する。
一方、ライト先ブロックが既にイントマップテーブルに登録されている場合には、ディスクドライバ23は、当該ライト先ブロックに対応するintの値であるシーケンス番号+1を当該ライト先ブロックに対応するintの値として登録する。
ステップS133の処理が実行されると、図7に示すステップS34〜ステップS37の処理に相当するステップS134〜ステップS137の処理が実行される。
ところで、テーブル整理デーモン25は、上記したようにイントマップテーブル132を定期的に参照する(ステップS138)。テーブル整理デーモン25は、イントマップテーブル132に登録済みのブロック数が閾値以上であるか否かを判定する。
ここで、テーブル整理デーモン25によってイントマップテーブル132に登録済みのブロック数が閾値以上であると判定された場合を想定する。この場合には、テーブル整理デーモン25は、イントマップテーブル132に登録されている古いシーケンス番号を持つintの値をクリアする。
次に、テーブル整理デーモン25は、共有ディスク10に含まれるサーバ20用領域13に保持されている第1のビットマップテーブル131において、クリアされたintの値に対応するブロックを未登録とする(ステップS139)。これにより、テーブル整理デーモン25は、例えばアクセス頻度の少ないブロックを未登録とすることで、第1のビットマップテーブル131に登録されている登録済みのブロック数を閾値以下にする。
上記したように本実施形態においては、イントマップテーブルに登録されているブロック数が閾値以上になった場合には、当該登録されているブロックのうち、アクセス頻度の少ないブロックを第1のビットマップテーブル(及びイントマップテーブル)において未登録とすることで、例えばサーバ30によってフェイルオーバが実行された場合であってもデータ破壊を防止するために別途必要となるディスク領域(ログ領域)のサイズを一定サイズ以下に抑えることが可能となる。
なお、本実施形態においては、テーブル整理デーモン25がサーバ20に備えられるものとして説明したが、例えばテーブル整理デーモン25がクラスタシステムを構成する複数のサーバの全てに備えられる構成であっても構わない。
[第4の実施形態]
次に、図17を参照して、本発明の第4の実施形態に係るクラスタシステムについて説明する。図17は、本実施形態に係るクラスタシステムの機能構成を示すブロック図である。
図17に示すように、本実施形態に係るクラスタシステムにおいては、サーバ20は、統計情報処理部26を備える。
本実施形態においては、サーバ20のディスクドライバ23は、アプリケーション21からマスター領域11に対するライト要求を入力した場合、当該ライト要求の対象となる領域に対応するブロック(ライト先ブロック)を統計情報処理部26に通知する。ディスクドライバ23は、マスター領域11に対するライト要求を入力する度に当該ライト要求に係るライト先ブロックを通知する。
統計情報処理部26は、統計情報処理部26は、ディスクドライバ23からのライト先ブロックの通知に基づいて、例えばサーバ20のマスター領域11に対する書き込みのアクセスパターンを統計的に解析する。
統計情報処理部26は、アクセスパターンの解析結果に基づいて、例えば将来書き込みがなされる可能性の高いブロック(ライト先ブロック)を予測する。統計情報処理部26は、サーバ20に備えられているメモリ上に保持されている第1のビットマップテーブル及び共有ディスク10に含まれるサーバ20用領域14に保持されている第1のビットマップテーブルに、予測されたライト先ブロックを予め登録する。
次に、図18を参照して、図17に示すクラスタシステムを構成するサーバ20が稼動系サーバに移行した後の当該サーバ20のディスクドライバ23及び統計情報処理部26の処理について具体的に説明する。なお、共有ディスク10に含まれるアクセス権管理テーブル12には、サーバ20にマスター領域11に対するアクセス権が設定されているものとする。
まず、前述した図7に示すステップS31〜ステップS34の処理に相当するステップS141〜ステップS144の処理が実行される。なお、ステップS141で入力されたI/O要求は、マスター領域11(LU1)に対するライト要求であるものとする。
次に、ディスクドライバ23は、アプリケーション21から入力されたライト要求の対象となる領域に対応するブロック(ライト先ブロック)を統計情報処理部26に通知する(ステップS145)。ディスクドライバ23は、マスター領域11に対するライト要求を入力する都度、ライト先ブロックを通知する。このとき、ディスクドライバ23は、例えばライト先ブロックのブロック番号等を通知する。
以下、ディスクドライバ23では、前述した図7に示すステップS35〜ステップS37の処理に相当するステップS146〜ステップS148の処理が実行される。
統計情報処理部26は、ディスクドライバ23から通知されたライト先ブロックに基づいて、サーバ20のマスター領域11に対する書き込みのアクセスパターンを統計的に解析する。
統計情報処理部26は、解析されたサーバ20のアクセスパターンに基づいて、当該サーバ20によって将来書き込みがなされる可能性の高いブロック(ライト先ブロック)を予測する。
具体的には、ディスクドライバ23によって通知されたライト先ブロックのブロック番号が例えばブロック番号10、ブロック番号11及びブロック番号12と続いた場合、つまり、サーバ20(のディスクドライバ23)によってブロック番号10のブロック、ブロック番号20のブロック及びブロック番号30のブロックに対して書き込み(ライト処理)が実行された場合には、統計情報処理部26は、ブロック番号13〜20のブロックを将来書き込みがなされる可能性が高いブロックとして予測する。
また、ディスクドライバ23によって通知されたライト先ブロックのブロック番号が例えばブロック番号10、ブロック番号20及びブロック番号30と続いた場合、統計情報処理部26は、ブロック番号40及び50のブロックを将来書き込みがなされる可能性が高いブロックとして予測する。
統計情報処理部26は、サーバ20に備えられるメモリ上に保持されている第1のビットマップテーブル131に、予測されたブロックを登録する(ステップS149)。
また、統計情報処理部26は、共有ディスクに含まれるサーバ20用領域に保持されている第1のビットマップテーブル131に、予測されたブロックを登録する(ステップS150)。
なお、上記したステップS149及びステップS150の処理は、I/O負荷の低い(軽い)時間帯等に実行される。
上記したように本実施形態においては、サーバ20のライト先ブロックに基づいて当該サーバ20のアクセスパターンを解析し、当該アクセスパターンから将来書き込みがなされる可能性の高いブロックを予め第1のビットマップテーブルに登録しておくことで、将来ライト先ブロックを第1のビットマップテーブルに登録(更新)する際のI/Oによって発生する性能劣化の度合いを未然に削減することが可能となる。
なお、本実施形態においては、統計情報処理部26がサーバ20に備えられるものとして説明したが、例えば統計情報処理部26がクラスタシステムを構成する複数のサーバの全てに備えられる構成であっても構わない。[第5の実施形態]
次に、本発明の第5の実施形態に係るクラスタシステムについて説明する。本実施形態に係るクラスタシステムの構成については、前述した図17に示すクラスタシステムの構成と同様であるので、図17を用いて説明する。ここでは、前述した第4の実施形態に係るクラスタシステムと異なる部分について主に述べる。
本実施形態においては、サーバ20に備えられる統計情報処理部26は、アプリケーション21の起動(開始)直後からしばらくの間(予め定められた時間)サーバ20のディスクドライバ23からライト先ブロックの通知を受け取る。
統計情報処理部26は、受け取られたライト先ブロックの通知に基づいて、サーバ20のマスター領域11に対するアクセスパターンを統計的に解析する。統計情報処理部26は、解析されたアクセスパターンに基づいて、アクセス頻度の高いライト先ブロックが登録されたビットマップテーブルのテンプレート(以下、単にテンプレートと表記)を作成する。作成されたテンプレートは、例えばサーバ20上で記憶される。
テンプレートは、例えばアプリケーション21の起動時(サーバ20の稼動時)に前述した第1のビットマップテーブルとして用いられる。
また、サーバ20のアプリケーション21が停止された際の第1のビットマップテーブルを記憶しておき、当該記憶されている第1のビットマップテーブル及びテンプレートがマージされたものを、当該アプリケーション21の起動時に第1のビットマップテーブルとして用いる構成であっても構わない。
上記したように本実施形態においては、サーバ20のライト先ブロックに基づいて当該サーバ20のアクセスパターンを解析し、当該アクセスパターンに基づいてアクセス頻度の高いライト先ブロックが登録されたテンプレートを予め作成しておき、アプリケーション21の起動時には当該テンプレートが第1のビットマップテーブルとして用いられる。これにより、本実施形態においては、アプリケーション21の開始時に、ライト先ブロックを第1のビットマップテーブルに登録(更新)するためのI/Oによって発生する性能劣化の度合いを未然に削減することが可能となる。
なお、本願発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。
10…共有ディスク(記憶装置)、11…マスター領域(第1の領域)、12…アクセス権管理テーブル、13…サーバ20用領域、14…サーバ30用領域、15…サーバ40用領域、20,30,40…サーバ、21,31,41…アプリケーション、22,32,42…クラスタソフト、23,33,43…ディスクドライバ、24,34,44…アクセス権ポーリングデーモン、25…テーブル整理デーモン、26…統計情報処理部、50…クライアント端末、131…第1のビットマップテーブル(第1の計算機用テーブル)、132…イントマップテーブル、141…第2のビットマップテーブル(第2の計算機用テーブル)、142,152…ログ領域、151…第4のビットマップテーブル、153…第3のビットマップテーブル。