(57)【要約】【課題】  サーバ側の状況をストレージ装置側から観測し、サーバの状況に応じて処理の優先度を制御する。【解決手段】  ストレージ装置２は、多数のサーバ１Ａ〜１Ｃにより利用される。サーバ１Ａとサーバ１Ｂとは、フェイルオーバクラスタを構成する。状況検出部５は、サーバ１Ａ，１Ｂから観測された事象が所定の事象（リンクダウン等）にが該当するか否かを判定する。所定の事象が観測された場合、状況検出部５はフェイルオーバの発生を検出する。優先度制御部６は、フェイルオーバの発生検知に応じて、フェイルオーバ先サーバの処理優先度を通常時よりも高く設定する。予め設定されたフェイルオーバ時間が経過した場合、フェイルオーバ時の優先度は通常時の優先度に戻される。【選択図】        図１
2005301442.tif 000002
【特許請求の範囲】
【請求項１】
複数のホスト装置との間のデータ授受をそれぞれ制御する上位インターフェース制御部と、
複数の記憶デバイスとの間のデータ授受をそれぞれ制御する下位インターフェース制御部と、
前記上位インターフェース制御部及び前記下位インターフェース制御部に共用されるメモリ部と、
前記上位インターフェース制御部を介して前記各ホスト装置の状況をそれぞれ検出する状況検出部と、
検出された前記各ホスト装置の状況に応じて、前記各ホスト装置からの入出力要求を処理するための処理優先度をそれぞれ制御する優先度制御部と、
を備えたストレージ装置。
【請求項２】
前記各ホスト装置はクラスタを構成しており、
前記優先度制御部は、検出された前記ホスト装置の状況が異常事態の発生を示している場合は、この異常事態が発生したホスト装置とペアを構成するホスト装置の処理優先度を高くするように制御する請求項１に記載のストレージ装置。
【請求項３】
前記各ホスト装置はクラスタを構成しており、
前記優先度制御部は、検出された前記ホスト装置の状況が過負荷状態を示している場合は、この過負荷状態が発生したホスト装置の処理優先度を高くするように制御する請求項１に記載のストレージ装置。
【請求項４】
前記各ホスト装置はクラスタを構成しており、
前記優先度制御部は、検出された前記ホスト装置の状況が過負荷状態を示している場合は、この過負荷状態が発生したホスト装置の処理優先度を高くするように制御し、検出された前記ホスト装置の状況が異常事態の発生を示している場合は、この異常事態が発生したホスト装置とペアを構成するホスト装置の処理優先度を高くするように制御する請求項１に記載のストレージ装置。
【請求項５】
前記各ホスト装置は、フェイルオーバクラスタを構成する請求項２〜請求項４のいずれか１項に記載のストレージ装置。
【請求項６】
前記各ホスト装置はクラスタを構成しており、
前記優先度制御部は、ペアを構成する一方のホスト装置に所定の障害が発生した場合に、前記ペアを構成する他方のホスト装置が前記障害発生を検出するよりも前に、前記他方のホスト装置の処理優先度を高くする請求項１に記載のストレージ装置。
【請求項７】
前記メモリ部には、複数の状況パターンとこれら各状況パターン毎の処理優先度とを対応付ける優先度管理テーブルが予め記憶されており、
前記優先度制御部は、検出された前記各ホスト装置の状況に基づいて、前記優先度管理テーブルを参照することにより、前記各ホスト装置に対する処理優先度を決定する請求項１に記載のストレージ装置。
【請求項８】
前記各状況パターンには、前記各ホスト装置が置かれうる所定の複数の状況に基づいて前記各ホスト装置からそれぞれ発行される所定の入出力要求が定義されており、
前記状況検出部は、前記各ホスト装置から前記上位インターフェース制御部に受信された入出力要求と前記所定の入出力要求とを比較することにより、前記各ホスト装置の状況をそれぞれ検出する請求項６に記載のストレージ装置。
【請求項９】
前記優先度制御部は、所定の変更終了条件が成立したときは、変更した処理優先度を元の処理優先度に戻すように制御する請求項１に記載のストレージ装置。
【請求項１０】
前記優先度制御部は、前記ホスト装置からの入出力要求の処理が所定値よりも遅れている場合は処理優先度を段階的に上昇させ、前記ホスト装置からの入出力要求の処理が所定値よりも早まっている場合は前記処理優先度を段階的に低下させるように制御する請求項１に記載のストレージ装置。
【請求項１１】
フェイルオーバクラスタを構成する複数のホスト装置との間のデータ授受をそれぞれ制御するチャネルアダプタと、
複数のディスク媒体との間のデータ授受をそれぞれ制御するディスクアダプタと、
前記チャネルアダプタ及び前記ディスクアダプタに共用されるメモリと、
前記メモリに記憶され、前記各ホスト装置が置かれうる所定の複数の状況にそれぞれ由来する所定の入出力要求及びこれら各所定の入出力要求毎の処理優先度とを予め対応付けた優先度管理テーブルと、
前記チャネルアダプタを介して受信された前記各ホスト装置からの入出力要求と前記優先度管理テーブルに対応付けられた前記各所定の入出力要求とを比較することにより、前記各ホスト装置が前記所定の状況にあるか否かをそれぞれ検出する状況検出部と、
前記所定の状況を有するホスト装置が検出された場合は、このホスト装置のフェイルオーバ先として設定されているホスト装置の処理優先度を通常の処理優先度よりも高くし、フェイルオーバが終了した場合は、前記フェイルオーバ先として設定されているホスト装置の処理優先度を前記通常の処理優先度に低下させる優先度制御部と、
前記優先度管理テーブルの内容を変更するための変更指示部と、
を備えたストレージ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージ装置に関する。
【背景技術】
【０００２】
ストレージ装置は、例えば、ディスクアレイ装置等とも呼ばれるもので、多数のディスクドライブをアレイ状に配設して構成される。ストレージ装置は、例えば、RAID（Redundant Array of Independent Inexpensive Disks）に基づく記憶領域を提供する。各ディスクドライブが有する物理的な記憶領域上には、論理的な記憶領域である論理ボリューム（論理デバイス）が形成されている。例えば、サーバ等のようなホストコンピュータは、ストレージ装置に対して所定形式のライトコマンド又はリードコマンドを発行することにより、所望のデータの読み書きを行うことができる。
【０００３】
ところで、複数のサーバが一つのまとまりを構成し、ストレージ装置の一つまたは複数の論理ボリュームを共有することもできる。このように、複数のサーバを疎結合させるものをクラスタシステム等と呼ぶ。クラスタシステムとしては、例えば、フェイルオーバシステムが知られている。フェイルオーバシステムとは、一方のサーバが停止した場合に、他方のサーバが業務アプリケーションサービスを引継ぐものである（特許文献１）。これにより、フェイルオーバシステムでは、クライアントコンピュータに対するサービスの継続性を保証している。
【０００４】
なお、複数のサーバがディスク装置を共用する場合に、サービスの重要性に応じてキューの実行順序を入れ替えることにより、重要なサービスを優先的に処理できるようにしたディスク装置も知られている（特許文献２）。
【特許文献１】特開２０００−２１５０７６号公報
【特許文献２】特開２００１−２２２３８２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前者の特許文献に記載された従来技術では、フェイルオーバ先に関する情報を各ノード（サーバ）にそれぞれ保持させることにより、フェイルオーバの開始に要する時間を短縮し、フェイルオーバ時間の短縮を図っている。しかしながら、この従来技術では、専らサーバ側での時間短縮を図るもので、ストレージ装置側の時間短縮については何ら考慮していない。
【０００６】
フェイルオーバ時には、例えば、ダウンしたサーバからファイルシステムをアンマウントする処理、アンマウントされたファイルシステムをフェイルオーバ先のサーバにマウントする処理、フェイルオーバ元のサーバとフェイルオーバ先のサーバとの間でデータの整合性をとる処理、フェイルオーバ先のサーバ上でアプリケーションプログラムを再起動する処理等のように、種々の処理が実行される。
【０００７】
これらの処理を行うために、フェイルオーバ先のサーバは、フェイルオーバ時に、頻繁にストレージ装置にアクセスし、データの読出しや書込みを行う。従って、サーバ側でフェイルオーバ時間の短縮を試みても、ストレージ装置の応答性が改善されなければ、フェイルオーバ時間を短縮することはできない。フェイルオーバ時におけるストレージ装置の応答性がボトルネックとなるためである。
【０００８】
特に、近年では、ストレージ装置の記憶容量が増大し、処理性能も向上している。高性能・高容量のストレージ装置を少数のサーバで使用するシステムは不経済のため、多数のサーバによって１台のストレージ装置が共用される場合が多い。
【０００９】
ストレージ装置が１つのフェイルオーバクラスタにのみ利用されている場合、ストレージ装置は、フェイルオーバに伴う入出力要求の処理に専念することができる。しかし、ストレージ装置が多数のクラスタやサーバによって共用される状況下では、ストレージ装置は、フェイルオーバに伴う入出力要求の処理以外に、他のサーバからの入出力要求も処理しなければならならい。このため、フェイルオーバに伴う入出力要求への応答が遅れ、フェイルオーバ時間が長引く可能性がある。
【００１０】
ところで、後者の特許文献では、各メモリアクセスに予め設定された優先度に応じて、キューの実行順序を入れ替えている。しかし、この従来技術は、フェイルオーバクラスタシステムについて何ら考慮されておらず、また、サーバの状況に応じてメモリアクセスの優先度を動的に変更するものではない。
【００１１】
本発明の一つの目的は、ホスト装置の状況に応じて、入出力要求を処理する優先度を動的に変更できるようにしたストレージ装置を提供することにある。本発明の一つの目的は、一方のホスト装置の異常事態を検出した場合に、このホスト装置とペアを構成する他方のホスト装置への処理優先度を高くすることにより、異常事態への対応を早期に行うことができるようにしたストレージ装置を提供することにある。本発明の一つの目的は、過負荷状態のホスト装置への処理優先度を高くすることにより、過負荷による障害発生を抑制できるようにしたストレージ装置を提供することにある。本発明の一つの目的は、過負荷状態のホスト装置に障害が発生するのを抑制し、たとえ障害が発生した場合でも、ペアを構成する他のホスト装置の処理優先度を事前に高めて、速やかに障害に対応できるようにしたストレージ装置を提供することにある。本発明の一つの目的は、ホスト装置間のフェイルオーバを事前に察知し、フェイルオーバ先のホスト装置への処理優先度を予め高めておくことにより、フェイルオーバを早期に完了させることができるストレージ装置を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。
【課題を解決するための手段】
【００１２】
上記課題を解決すべく、本発明では、各ホスト装置の状況をストレージ装置側で認識し、この認識に基づいて各ホスト装置への処理優先度を動的に制御できるようにする。本発明に従うストレージ装置は、複数のホスト装置との間のデータ授受をそれぞれ制御する上位インターフェース制御部と、複数の記憶デバイスとの間のデータ授受をそれぞれ制御する下位インターフェース制御部と、上位インターフェース制御部及び下位インターフェース制御部に共用されるメモリ部とを備える。さらに、このストレージ装置は、上位インターフェース制御部を介して各ホスト装置の状況をそれぞれ検出する状況検出部と、検出された各ホスト装置の状況に応じて、各ホスト装置からの入出力要求を処理するための処理優先度をそれぞれ制御する優先度制御部と、を備えている。
【００１３】
ホスト装置としては、例えば、サーバ、パーソナルコンピュータ、メインフレーム等を挙げることができる。記憶デバイスとしては、例えば、ハードディスクドライブ、半導体メモリ装置、光ディスクドライブ等を挙げることができる。メモリ部としては、例えば、キャッシュメモリや制御メモリ等を挙げることができる。また、例えば、記憶デバイスの一部をメモリ部として使用することもできる。状況検出部は、上位インターフェース制御部を介して、各ホスト装置が置かれている状況をそれぞれ検出する。例えば、ホスト装置から出されたコマンドの種類や処理の対象、ホスト装置からの応答の有無等に基づいて、状況検出部は、各ホスト装置の状況を検出可能である。優先度制御部は、各ホスト装置の状況に応じて、処理優先度を制御する。処理優先度とは、ホスト装置からの入出力要求を処理する優先順位である。処理優先度が高くなればなるほど、その入出力要求は他の要求に優先して処理される。処理優先度の高い入出力要求を優先的に処理する方法としては、例えば、キューの実行順序を入れ替える方法や、処理優先度の高い入出力要求により多くのコンピュータ資源（CPU利用率やメモリ使用量等）を割り当てる方法等がある。
【００１４】
各ホスト装置はクラスタを構成することができ、優先度制御部は、検出されたホスト装置の状況が異常事態の発生を示している場合は、この異常事態が発生したホスト装置とペアを構成するホスト装置の処理優先度を高くするように制御することができる。即ち、例えば、フェイルオーバクラスタの場合、フェイルオーバが発生したときには、フェイルオーバ先ホスト装置の処理優先度を高くし、フェイルオーバ時間を短縮する。
【００１５】
優先度制御部は、検出されたホスト装置の状況が過負荷状態を示している場合、この過負荷状態が発生したホスト装置の処理優先度を高くするように制御可能である。これにより、ホスト装置が過負荷によってシステムダウンするのを抑制し、フェイルオーバの発生を防止または遅らせることができる。
【００１６】
優先度制御部は、検出されたホスト装置の状況が過負荷状態を示している場合は、この過負荷状態が発生したホスト装置の処理優先度を高くするように制御し、検出されたホスト装置の状況が異常事態の発生を示している場合は、この異常事態が発生したホスト装置とペアを構成するホスト装置の処理優先度を高くするように制御することもできる。これにより、過負荷によるシステムダウンを抑制または遅らせ、仮にホスト装置が過負荷によってダウンした場合でも、早期にフェイルオーバを完了させることができる。
【００１７】
優先度制御部は、ペアを構成する一方のホスト装置に所定の障害が発生した場合に、ペアを構成する他方のホスト装置が障害発生を検出するよりも前に、他方のホスト装置の処理優先度を高くすることもできる。例えば、フェイルオーバクラスタの場合、フェイルオーバ先ホスト装置がフェイルオーバの開始を決定するよりも前に、優先度制御部は、フェイルオーバ先ホスト装置の処理優先度を事前に高めておくことができる。このようなフェイルオーバの早期察知は、例えば、フェイルオーバ元ホスト装置との間のチャネルパス障害が発生した場合、フェイルオーバ元ホスト装置からの応答が所定時間以上帰ってこない場合、フェイルオーバ元ホスト装置が特定のコマンド（共有ボリュームの排他制御を解除するコマンド等）を発行した場合等に、行うことができる。
【００１８】
メモリ部には、複数の状況パターンとこれら各状況パターン毎の処理優先度とを対応付ける優先度管理テーブルを予め記憶させることができる。そして、優先度制御部は、検出された各ホスト装置の状況に基づいて、優先度管理テーブルを参照することにより、各ホスト装置に対する処理優先度を決定することができる。
【００１９】
各状況パターンには、各ホスト装置が置かれうる所定の複数の状況に基づいて各ホスト装置からそれぞれ発行される所定の入出力要求を定義することができる。状況検出部は、各ホスト装置から上位インターフェース制御部に受信された入出力要求と所定の入出力要求とを比較することにより、各ホスト装置の状況をそれぞれ検出可能である。
【００２０】
優先度制御部は、所定の変更終了条件が成立したときは、変更した処理優先度を元の処理優先度に戻すように制御することができる。これにより、障害等への対応が完了した場合には、ストレージ装置のコンピュータ資源を他のホスト装置の入出力要求処理に割り振ることができ、ストレージ装置を効率的に使用することができる。
【００２１】
優先度制御部は、ホスト装置からの入出力要求の処理が所定値よりも遅れている場合は処理優先度を段階的に上昇させ、ホスト装置からの入出力要求の処理が所定値よりも早まっている場合は処理優先度を段階的に低下させるように制御することもできる。また、例えば、優先度管理テーブルに予め登録されていない状況がホスト装置に発生した場合、優先度制御部は、このホスト装置への応答時間を考慮して、処理優先度を段階的に変更することもできる。
【００２２】
本発明の別の観点に従えば、複数のホスト装置との間のデータ授受をそれぞれ制御する上位インターフェース制御部と、複数の記憶デバイスとの間のデータ授受をそれぞれ制御する下位インターフェース制御部と、前記上位インターフェース制御部及び前記下位インターフェース制御部に共用されるメモリ部とを備えたストレージ装置の処理優先度を制御する方法であって、前記上位インターフェース制御部を介して前記各ホスト装置の状況をそれぞれ検出するステップと、検出された前記各ホスト装置の状況に応じて、前記各ホスト装置からの入出力要求を処理するための処理優先度をそれぞれ制御するステップとを備える。
【発明を実施するための最良の形態】
【００２３】
以下、図面に基づき、本発明の実施の形態を説明する。本実施形態のストレージ装置は、フェイルオーバクラスタを構成する複数のホスト装置との間のデータ授受をそれぞれ制御するチャネルアダプタと、複数のディスク媒体との間のデータ授受をそれぞれ制御するディスクアダプタと、チャネルアダプタ及びディスクアダプタに共用されるメモリとを備えている。また、このストレージ装置は、メモリに記憶され、各ホスト装置が置かれうる所定の複数の状況にそれぞれ由来する所定の入出力要求及びこれら各所定の入出力要求毎の処理優先度とを予め対応付けた優先度管理テーブルと、チャネルアダプタを介して受信された各ホスト装置からの入出力要求と優先度管理テーブルに対応付けられた各所定の入出力要求とを比較することにより、各ホスト装置が所定の状況にあるか否かをそれぞれ検出する状況検出部と、所定の状況を有するホスト装置が検出された場合は、このホスト装置のフェイルオーバ先として設定されているホスト装置の処理優先度を通常の処理優先度よりも高くし、フェイルオーバが終了した場合は、フェイルオーバ先として設定されているホスト装置の処理優先度を通常の処理優先度に低下させる優先度制御部と、優先度管理テーブルの内容を変更するための変更指示部とを備える。
【００２４】
図１は、本実施形態の全体概念を示す説明図である。複数のサーバ１Ａ〜１Ｃがストレージ装置２を共用している。図中では、サーバ１Ａを「サーバ１」、サーバ１Ｂを「サーバ２」、サーバ１Ｃを「サーバ３」と表記している。これらの各サーバ１Ａ〜１Ｃは、LAN（Local Area Network）等の通信ネットワーク３を介して相互に接続されている。また、各サーバ１Ａ〜１Ｃは、通信ネットワーク３を介して、複数のクライアントコンピュータ（図示せず）とも接続されている。そして、各サーバ１Ａ〜１Ｃは、SAN（Storage Area Network）等の通信ネットワーク４を介して、ストレージ装置２にそれぞれ接続されている。
【００２５】
ここで、サーバ１Ａとサーバ１Ｂとは、フェイルオーバクラスタを構成し、互いに相手方のフェイルオーバ先として設定されている。各サーバ１Ａ，１Ｂは、ハートビート通信を行うことにより、相手方がシステムダウンしたか否かを随時監視している。一方のサーバ１Ａが障害等でダウンした場合、サーバ１Ａが提供する業務アプリケーションサービスは、他方のサーバ１Ｂにより引き継がれる。逆に、他方のサーバ１Ｂがダウンした場合、他方のサーバ１Ｂが提供する業務アプリケーションサービスは、一方のサーバ１Ａに引き継がれる。
【００２６】
ストレージ装置２は、論理ボリューム（論理的な記憶デバイス）を各サーバ１Ａ〜１Ｃにそれぞれ提供する。フェイルオーバクラスタを構成する各サーバ１Ａ，１Ｂは、共通の論理ボリュームを共有する。ストレージ装置２は、各サーバ１Ａ〜１Ｃからの反応等に基づいて、各サーバ１Ａ〜１Ｃの状況をそれぞれ検出する。
【００２７】
フェイルオーバクラスタを構成するサーバ１Ａ，１Ｂを中心に説明すると、各サーバ１Ａ，１Ｂがどのような状況に置かれているかは、各サーバ１Ａ，１Ｂから観測される所定の事象２Ａに基づいて、推定的に検出することができる。所定の事象２Ａには、例えば、サーバ１Ａ，１Ｂとストレージ装置２との間のリンクがダウンした場合、サーバ１Ａ，１Ｂから所定の応答が無く無反応の場合、サーバ１Ａ，１Ｂから所定のコマンド（ReleaseコマンドやResetコマンド等）が出された場合等を含めることができる。このような所定の事象２Ａが観測された場合、フェイルオーバの発生を予測可能である。状況パターン検出用情報７には、このような所定の事象２Ａがフェイルオーバ発生の予兆として予め対応付けられている。
【００２８】
状況検出部５は、各サーバ１Ａ，１Ｂの観測結果が所定の事象２Ａに該当するか否かを判定する。観測結果が所定の事象２Ａに該当する場合、状況検出部５は、フェイルオーバの発生を検出し、優先度制御部６に通知する。優先度制御部６は、処理優先度管理用情報８を参照することにより、サーバ１Ａまたはサーバ１Ｂの処理優先度を通常時のそれよりも高く設定する。処理優先度管理用情報８には、観測された各事象毎に、どのサーバの処理優先度をどのように調節するかが予め定義されている。
【００２９】
例えば、サーバ１Ａからサーバ１Ｂへのファイルオーバが発生すると予測された場合、優先度制御部６は、サーバ１Ｂの処理優先度を高く設定する。逆に、サーバ１Ｂからサーバ１Ａへのフェイルオーバが発生すると予測される場合、優先度制御部６は、サーバ１Ａの処理優先度を高く設定する。処理優先度が高く設定されたサーバに対しては、例えば、入出力要求（Ｉ／Ｏ要求）の実行順位を高めたり、そのサーバからの入出力要求の処理にCPUやメモリ等のコンピュータ資源を優先的に割り当てる等の所定の優先的処理操作２Ｂが実行される。この結果、高い処理優先度を有するサーバからの入出力要求は、他のサーバのからの入出力要求に優先して処理される。
【００３０】
図１中の下側に示すタイミングチャート９に示されているように、仮に例えば、「サーバ１」（サーバ１Ａ）が何らかの障害によってダウンした場合を考える。サーバ１Ａのダウンは、ストレージ装置２によって事前に観測できる場合がある。サーバ１Ａがダウンする前に観測される所定の事象が予め状況パターン検出用情報７に定義されている場合、サーバ１Ａのダウンを事前に察知することができる。ストレージ装置２は、サーバ１Ａのダウンを事前に察知すると、「サーバ２」（サーバ１Ｂ）がフェイルオーバを開始するよりも前に、即ち、サーバ１Ｂがサーバ１Ａのダウンを認識するよりも前に、サーバ１Ｂの処理優先度を予め高く設定しておく。これにより、サーバ１Ｂからの入出力要求は優先的に処理され、フェイルオーバに伴う各処理が早期に完了する。従って、フェイルオーバ時間ｔを短縮することができる。
【００３１】
以下、具体的な実施例について説明する。まず最初に、図２，図３に基づいて、ストレージ装置の構成例を説明し、次に、図３以下を参照しながら、サーバ側の状況を観測して処理優先度を動的に制御する方法を説明する。
【実施例１】
【００３２】
図２は、ストレージ装置１０の外観構成を示す概略斜視図である。ストレージ装置１０は、例えば、基本筐体１１と複数の増設筐体１２とから構成することができる。
基本筐体１１は、ストレージ装置１０の最小構成単位であり、記憶機能及び制御機能の両方を備えている。増設筐体１２は、ストレージ装置１０のオプションであり、基本筐体１１の有する制御機能により制御される。例えば、最大４個の増設筐体１２を基本筐体１１に接続可能である。
【００３３】
基本筐体１１には、複数の制御パッケージ１３と、複数の電源ユニット１４と、複数のバッテリユニット１５と、複数のディスクドライブ２６とがそれぞれ着脱可能に設けられている。増設筐体１２には、複数のディスクドライブ２６と、複数の電源ユニット１４及び複数のバッテリユニット１５が着脱可能に設けられている。また、基本筐体１１及び各増設筐体１２には、複数の冷却ファン１６もそれぞれ設けられている。
【００３４】
制御パッケージ１３は、後述するチャネルアダプタ（以下、CHA）２１、ディスクアダプタ（以下、DKA）２２及びキャッシュメモリ２３等をそれぞれ実現するためのモジュールである。即ち、基本筐体１１には、複数のCHAパッケージ、複数のDKAパッケージ及び１つ以上のメモリパッケージがそれぞれ着脱可能に設けられ、パッケージ単位で交換可能となっている。
【００３５】
図３は、ストレージ装置１０の全体概要を示すブロック図である。ストレージ装置１０は、通信ネットワークＣＮ１を介して、複数のホストコンピュータ３０と双方向通信可能にそれぞれ接続可能である。
【００３６】
通信ネットワークＣＮ１は、例えば、LAN、SAN、インターネットあるいは専用回線等である。LANを用いる場合、ホストコンピュータ３０とストレージ装置１０との間のデータ転送は、TCP/IPに従って行われる。SANを用いる場合、ホストコンピュータ３０とストレージ装置１０とは、ファイバチャネルプロトコルに従ってデータ転送を行う。また、ホストコンピュータ３０がメインフレームの場合は、例えば、FICON（Fibre Connection：登録商標）、ESCON（Enterprise System Connection：登録商標）、ACONARC（Advanced Connection Architecture：登録商標）、FIBARC（Fibre Connection Architecture：登録商標）等の通信プロトコルに従ってデータ転送が行われる。
【００３７】
各ホストコンピュータ３０は、例えば、サーバ、パーソナルコンピュータ、ワークステーション、メインフレーム等として実現されるものである。例えば、各ホストコンピュータ３０は、図外に位置する複数のクライアント端末と別の通信ネットワークを介して接続されている。各ホストコンピュータ３０は、例えば、各クライアント端末からの要求に応じて、ストレージ装置１０にデータの読み書きを行うことにより、各クライアント端末へのサービスを提供する。
【００３８】
各CHA２１は、各ホストコンピュータ３０との間のデータ転送を制御するもので、通信ポート２１Ａを備えている。ストレージ装置１０には、例えば３２個のCHA２１を設けることができる。CHA２１は、例えば、オープン系用CHA、メインフレーム系用CHA等のように、ホストコンピュータ３０の種類に応じて用意される。各CHA２１を介して、各ホストコンピュータ３０の状況を観測することができる。
【００３９】
各CHA２１は、それぞれに接続されたホストコンピュータ３０から、データの読み書きを要求するコマンド及びデータを受信し、ホストコンピュータ３０から受信したコマンドに従って動作する。
【００４０】
DKA２２の動作も含めて先に説明すると、CHA２１は、ホストコンピュータ３０からリードコマンドを受信すると、このリードコマンドを共有メモリ２４に記憶させる。DKA２２は、共有メモリ２４を随時参照しており、未処理のリードコマンドを発見すると、ディスクドライブ２６からデータを読み出して、キャッシュメモリ２３に記憶させる。CHA２１は、キャッシュメモリ２３に移されたデータを読み出し、ホストコンピュータ３０に送信する。
【００４１】
一方、CHA２１は、ホストコンピュータ３０からライトコマンドを受信すると、このライトコマンドを共有メモリ２４に記憶させる。また、CHA２１は、受信したデータ（ユーザデータ）をキャッシュメモリ２３に記憶させる。CHA２１は、キャッシュメモリ２３にデータを記憶した後、ホストコンピュータ３０に書込み完了を報告する。DKA２２は、共有メモリ２４に記憶されたライトコマンドに従って、キャッシュメモリ２３に記憶されたデータを読出し、所定のディスクドライブ２６に記憶させる。
【００４２】
各DKA２２は、ストレージ装置１０内に例えば４個や８個等のように複数個設けることができる。各DKA２２は、各ディスクドライブ２６との間のデータ通信をそれぞれ制御する。各DKA２２と各ディスクドライブ２６とは、例えば、SAN等の通信ネットワークＣＮ４を介して接続され、ファイバチャネルプロトコルに従ってブロック単位のデータ転送を行う。各DKA２２は、ディスクドライブ２６の状態を随時監視しており、この監視結果は、内部ネットワークＣＮ３を介して、SVP２８に送信される。
【００４３】
各CHA２１及び各DKA２２は、例えば、プロセッサやメモリ等が実装されたプリント基板と、メモリに格納された制御プログラム（いずれも不図示）とをそれぞれ備えており、これらのハードウェアとソフトウェアとの協働作業によって、それぞれ所定の機能を実現するようになっている。
【００４４】
キャッシュメモリ２３は、例えば、ユーザデータ等を記憶するものである。キャッシュメモリ２３は、例えば不揮発メモリから構成される。
【００４５】
共有メモリ（あるいは制御メモリ）２４は、例えば不揮発メモリから構成される。共有メモリ２４には、例えば、制御情報や管理情報等が記憶される。これらの制御情報等の情報は、複数の共有メモリ２４により多重管理することができる。共有メモリ２４及びキャッシュメモリ２３は、それぞれ複数個設けることができる。また、同一のメモリ基板にキャッシュメモリ２３と共有メモリ２４とを混在させて実装することもできる。あるいは、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。
【００４６】
スイッチ部２５は、各CHA２１と、各DKA２２と、キャッシュメモリ２３と、共有メモリ２４とをそれぞれ接続するものである。これにより、全てのCHA２１，DKA２２は、キャッシュメモリ２３及び共有メモリ２４にそれぞれアクセス可能である。スイッチ部２５は、例えば超高速クロスバスイッチ等として構成することができる。
【００４７】
ストレージ装置１０は、多数のディスクドライブ２６を実装可能である。各ディスクドライブ２６は、例えば、ハードディスクドライブ（ＨＤＤ）や半導体メモリ装置等として実現することができる。
【００４８】
ディスクドライブ２６は、物理的な記憶デバイスである。RAID構成等によっても相違するが、例えば、４個１組のディスクドライブ２６が提供する物理的な記憶領域上には、仮想的な論理領域であるRAIDグループ２７が構築される。さらに、RAIDグループ２７上には、仮想的な論理デバイス（LU：Logigal Unit）を１つ以上設定可能である。論理デバイスは論理ボリュームとも呼ばれる。
【００４９】
なお、ストレージ装置１０により使用される記憶資源は、全てストレージ装置１０内に設けられている必要はない。ストレージ装置１０は、ストレージ装置１０の外部に存在する記憶資源を、あたかも自己の記憶資源であるかのように取り込んで、利用することもできる。
【００５０】
サービスプロセッサ（SVP）２８は、LAN等の内部ネットワークＣＮ３を介して、各CHA２１及び各DKA２２とそれぞれ接続されている。SVP２８は、例えば、CHA２１を経由して、共有メモリ２４にアクセスすることもできる。また、SVP２８は、LAN等の通信ネットワークＣＮ２を介して、複数の管理端末３１に接続可能である。SVP２８は、ストレージ装置１０内部の各種状態を収集し、管理端末３１に提供する。なお、SVP２８は、ストレージ装置１０の筐体内に設けられている必要はなく、筐体外に設けることもできる。
【００５１】
図４は、ストレージ装置２００を含むストレージシステムの全体構成を示すブロック図である。このストレージシステムは、複数のサーバ１１０〜１４０と、ストレージ装置２００とを備えている。
【００５２】
各サーバ１１０〜１４０は、図３中のホストコンピュータ３０に対応する。各サーバ１１０〜サーバ１４０は、それぞれ業務アプリケーションプログラム１１１，１２１（サーバ１１０，１２０のみ図示）を備えることができる。図中では、サーバ１１０を「サーバ１（ノード１）」と、サーバ１２０を「サーバ２（ノード２）」と、サーバ１３０を「サーバ３（ノード３）」と、サーバ１４０を「サーバ４（ノード４）」と、それぞれ表記している。各サーバ１１０〜１４０は、例えば、LAN等の通信ネットワークＣＮ１１を介して、相互に接続されている。各サーバ１１０〜１４０は、通信ネットワークＣＮ１１を介して、図外のクライアント端末とも接続されている。また、各サーバ１１０〜１４０は、例えば、SAN等の通信ネットワークＣＮ１２を介して、ストレージ装置２００とそれぞれ接続されている。
【００５３】
図示を省略しているが、各サーバ１１０〜１４０とストレージ装置２００とを、通信ネットワークＣＮ１１によって接続することもできる。各サーバ１１０〜１４０とストレージ装置２００とは、通信ネットワークＣＮ１１を介して、制御情報等を送受信することができる。なお、各サーバ１１０〜１４０とストレージ装置２００とは、SAN等の通信ネットワークＣＮ１２を介して、制御情報等を送受信することもできる。この場合、通信ネットワークＣＮ１２を介して、ブロックデータ及び制御情報等が伝送される。
【００５４】
第１のサーバ１１０と第２のサーバ１２０とは、互いにフェイルオーバの関係に立つフェイルオーバクラスタを構成している。これらの各サーバ１１０，１２０間は、専用の通信ネットワークＣＮ１３により接続されている。この通信ネットワークＣＮ１３を介して、各サーバ１１０，１２０は、ハートビート通信を行っている。各サーバ１１０，１２０は、ハートビート通信が途絶した場合に、相手方のシステムダウンを認識し、フェイルオーバを実行する。
【００５５】
ストレージ装置２００は、具体的には、図２，図３で述べたような構成を備えることができる。ストレージ装置２００は、複数のポート制御部２１１〜２１４と、フェイルオーバ検出部２２０と、スケジューラ２３０と、メモリ２４０と、ディスク制御部２５０と、記憶装置２６０と、SVP２７０とを備えることができる。
【００５６】
各ポート制御部２１１〜２１４は、各サーバ１１０〜１４０とのデータ通信を制御するためのものである。各ポート制御部２１１〜２１４は、例えば、CHA２１の通信ポート２１Ａに対応する。
【００５７】
フェイルオーバ検出部２２０は、各ポート制御部２１１〜２１４から受信されたコマンド等に基づいて、フェイルオーバの発生または発生の予兆を検出する。フェイルオーバ検出部２２０は、例えば、CHA２１の制御プログラムにより実現可能である。フェイルオーバ検出部２２０は、管理テーブル２４２を参照することにより、サーバ１１０，１２０間でフェイルオーバが発生するか否かを予測的に検出可能である。この検出処理の詳細は、さらに後述する。
【００５８】
スケジューラ２３０は、各サーバ１１０〜１４０から受信したコマンドの処理順序を制御するものである。スケジューラ２３０は、例えば、CHA２１の制御プログラム、またはCHA２１及びDKA２２の制御プログラムとして実現可能である。スケジューラ２３０は、例えば、キュー２４１を利用することにより、各サーバ１１０〜１４０からのコマンドを所定の順序で処理させる。また、スケジューラ２３０は、フェイルオーバの発生が検出された場合、管理テーブル２４２を参照し、フェイルオーバ先のサーバからのコマンドを優先的に処理させる。この処理については、さらに後述する。
【００５９】
メモリ２４０は、例えば、キュー２４１と管理テーブル２４２とを記憶する。メモリ２４０は、例えば、共有メモリ２４に対応する。但し、これに限らず、例えば、管理テーブル２４２は、記憶装置２６０内の所定領域に格納させる構成でもよい。
【００６０】
ディスク制御部２５０は、記憶装置２６０内の各論理ボリューム２６１にアクセスし、論理ボリューム２６１との間のデータ通信を制御する。ディスク制御部２５０は、例えば、DKA２２に対応する。記憶装置２６０は、多数のディスクドライブを備えており、これらの物理的なディスクドライブ上には、論理的な記憶デバイスである論理ボリューム２６１が複数形成されている。以下の説明では、論理ボリューム２６１を論理デバイス２６１と呼ぶ。
【００６１】
SVP２７０は、例えば、ストレージ装置２００内の各部の状態を監視したり、RAID構成の設定等を行う。SVP２７０は、例えば、図３中のSVP２８に対応する。ユーザ（システム管理者等）は、SVP２７０を介して、管理テーブル２４２の登録内容を変更することができる。
【００６２】
図５，図６に基づいて、フェイルオーバシステムの詳細を説明する。フェイルオーバクラスタを構成する第１のサーバ１１０は、例えば、業務アプリケーションプログラム（以下、「業務アプリケーション」と略記）１１１と、ハートビート監視部１１２と、業務アプリケーションの起動停止制御部（以下、「起動停止制御部」と略記）１１３と、ディスク排他制御部１１４とを備えることができる。同様に、フェイルオーバクラスタを構成する第２のサーバ１２０も、業務アプリケーション１２１と、ハートビート監視部１２２と、起動停止制御部１２３と、ディスク排他制御部１２４とを備えることができる。
【００６３】
業務アプリケーション１１１，１２１は、クライアント端末に提供するサービスを実行するためのプログラムである。ハートビート監視部１１２，１２２は、ハートビート信号の送受信を行い、ハートビート通信が継続しているか否かを監視する。起動停止制御部１１３，１２３は、業務アプリケーション１１１，１２１の起動及び停止を制御する。ディスク排他制御部１１４，１２４は、各サーバ１１０，１２０が共有する論理デバイス２６１の排他制御を行う。
【００６４】
サーバ１１０は、例えば、HBA（Host Bus Adapter）等のポート１１５から通信ネットワークＣＮ１２を介して、ストレージ装置２００のポート制御部２１１に接続することができる。同様に、サーバ１２０は、ポート１２５から通信ネットワークＣＮ１２を介して、ストレージ装置２００のポート制御部２１２に接続することができる。各サーバ１１０，１２０は、所定の一つまたは複数の論理デバイス２６１を共有する。
【００６５】
図６（ａ）には、通常時の状態が示されている。通常時には、サーバ１１０が現用系（稼働系）のサーバ、サーバ１２０が待機系のサーバ、であるとする。フェイルオーバクラスタは、サーバ１１０を介して各クライアント端末にサービスを提供する。共有論理デバイス２６１は、サーバ１１０が独占的に使用する。なお、サーバ１１０から提供されている業務アプリケーションサービスについては、サーバ１１０が稼働系サーバ、サーバ１２０が待機系サーバとなるが、サーバ１２０は独自の業務アプリケーションサービスを提供することもできる。
【００６６】
図６（ｂ）には、サーバ１１０が何らかの障害でシステムダウンしたり、サーバ１１０が計画的に停止された場合が示されている。サーバ１１０のダウンによって、サーバ１１０，１２０間のハートビート通信が途絶する。ハートビート通信が途切れてから所定時間の経過後に、待機系のサーバ１２０は、フェイルオーバ処理を実行する。これにより、サーバ１２０は、サーバ１１０で提供されていたサービスを引き継ぐ。サービスの引継ぎに際して、サーバ１１０のＩＰアドレス等もサーバ１２０に継承される。サーバ１２０は、待機系サーバから稼働系サーバに変わり、共有論理デバイス２６１へのアクセス権を排他的に取得する。
【００６７】
クライアント端末がフェイルオーバ中にサービスの提供を求めた場合、クライアント端末にエラーが返される。サーバ１１０からサーバ１２０へのフェイルオーバが終了すると、クライアント端末は、サーバ１２０からサービスを受ける。クライアント端末は、クラスタ内のどのサーバからサービスが提供されているのかまで意識しない。クライアント端末からは、クラスタ全体が一つのサーバとして認識される。
【００６８】
ハートビート通信の途絶後、所定時間の経過を待つのは、一時的な高負荷等によって、サーバ１１０からのハートビート信号の送信が遅れる場合を考慮したものである。ハートビート通信の一時的な遅れによって、無用なフェイルオーバ処理が開始されるのを防止するために、所定時間待機する。
【００６９】
一方、フェイルオーバ時間は極力短縮する必要がある。業務アプリケーション１１１が提供するサービスの種類によっては、２４時間３６５日の連続稼働を要求される場合もあり、できるだけ短時間でサービスを再開する必要がある。サーバ１１０からサーバ１２０へのフェイルオーバを行う場合は、例えば、共有論理デバイス２６１の排他制御や、業務アプリケーション１２１の起動処理、各サーバ１１０，１２０間でのデータの整合性を維持する処理等のように、多種類の処理を実行する。これらのフェイルオーバに伴う処理の実行は、フェイルオーバ先のサーバ１２０からストレージ装置２００に対する多数の入出力要求を発生させる。各入出力要求に対する応答がそれぞれ遅れると、この応答の遅れの分だけ、フェイルオーバ開始からフェイルオーバ完了までの時間が長くなる。
【００７０】
このため従来は、例えば１０分〜２０分程度の遅れが発生していた。本発明は、以下に述べるように、フェイルオーバ時のフェイルバック先サーバに対するストレージ装置２００の応答性を改善することにより、フェイルオーバ時間の短縮を図る。
【００７１】
図７は、管理テーブル２４２の構成を示す説明図である。管理テーブル２４２は、例えば、複数のテーブルＴ１〜Ｔ３を連携させることにより、構成することができる。
サーバ管理テーブルＴ１は、例えば、各サーバ１１０〜１４０をそれぞれ識別するためのサーバＩＤ（識別コード）と、ＷＷＮ（World Wide Name）と、平常時の優先順位と、現在順位と、フェイルオーバ時の優先順位と、フェイルオーバ中であるか否かを示すフラグとを、それぞれ対応付けることにより構成することができる。
【００７２】
ここで、平常時の優先順位（処理優先度）とは、フェイルオーバ処理の実行状態以外の通常の状態における優先順位を示す。優先順位は、例えば、１０段階で設定することができる。優先順位の数字が小さくなればなるほど、高い優先順位となる。図示の例では、各サーバ１１０〜１４０の全てに同一の優先順位「５」が設定されている。従って、ストレージ装置２００は、平常状態において、各サーバ１１０〜１４０からそれぞれ出される入出力要求を公平に処理する。現在順位とは、現在設定されている優先順位である。フェイルオーバ時の優先順位とは、フェイルオーバの開始に先立って、またはフェイルオーバの開始と共に、あるいはフェイルオーバの開始後に、設定される優先順位である。
【００７３】
各サーバ１１０，１２０は、互いにフェイルオーバの関係に立つため、フェイルオーバ時の優先順位は同一順位となっている。サーバ１１０，１２０のうちいずれのサーバがダウンするか不明だからである。もしも、サーバ１１０がダウンした場合には、フェイルオーバ先のサーバ１２０の優先順位は、平常時の「５」からフェイルオーバ時の「１」に上昇する。逆に、サーバ１２０がダウンした場合には、フェイルオーバ先のサーバ１１０の優先順位が、平常時の「５」からフェイルオーバ時の「１」に上昇する。図６の例では、サーバ１１０でのみサービスを提供するかのように示したが、サーバ１１０，１２０はそれぞれ個別に独自のサービスをクライアント端末に提供することができる。
【００７４】
図６に示す例では、サーバ１１０，１２０間でフェイルオーバが実行中であり、各サーバ１１０（Ｎ１），１２０（Ｎ２）の優先順位がそれぞれ最高レベルに設定されている様子が示されている。なお、他のサーバ１３０（Ｎ３），１４０（Ｎ４）に着目すると、サーバ１３０の優先順位は、フェイルオーバ実行の前後で変化しない。サーバ１４０の優先順位は、平常時には「５」であるが、サーバ１１０，１２０間でのフェイルオーバ時には「７」へ低下する。即ち、本実施例において、サーバ１４０の重要度は低い。
【００７５】
クラスタ管理テーブルＴ２は、例えば、各クラスタを識別するためのクラスタＩＤと、各クラスタを構成するサーバのサーバＩＤと、フェイルオーバ監視対象と、フェイルオーバ時間とを、それぞれ対応付けることにより構成することができる。本実施例では、サーバ１１０，１２０によるフェイルオーバクラスタ（Ｃ１）のみを示すが、これ以外のクラスタを定義することもできる。フェイルオーバ監視対象には、例えば、クラスタによって共有される論理デバイスのディスク番号と、監視対象の動作パターンＩＤとを含めることができる。フェイルオーバ時間は、フェイルオーバ開始からフェイルオーバ完了までに要する時間であり、このフェイルオーバ時間内にフェイルオーバが完了するように、フェイルオーバクラスタシステムは設計されている。なお、図示のように、各クラスタ単位でフェイルオーバ時間をそれぞれ設定する構成でもよいし、あるいは、サーバの動作パターン毎にフェイルオーバ時間をそれぞれ設定する構成でもよい。または、動作パターンを複数のグループに分類し、各グループ毎にそれぞれフェイルオーバ時間を設定する構成としてもよい。
【００７６】
フェイルオーバ検出パターンテーブル（以下、「パターンテーブル」）Ｔ３は、フェイルオーバの発生を検出するための動作パターンを予め定義するためのものである。パターンテーブルＴ３は、例えば、動作パターンを識別するための動作パターンＩＤと、各動作パターンＩＤ毎のフェイルオーバ検出パターンと、フェイルオーバ検出時の事前対策の処理内容とを、それぞれ対応付けることにより構成することができる。
【００７７】
例えば、動作パターンＰＡ１は、「ファイバチャネルのリンクダウン」を検出するためのものである。ファイバチャネルのリンクダウンとは、例えば、ファイバチャネルスイッチやハブ、ファイバケーブル、HBA等に何らかの問題が発生し、サーバ１１０，１２０とストレージ装置２００との間のＩ／Ｏパスに障害が発生するような場合である。ファイバチャネルのリンクダウンが検出された場合、フェイルオーバ発生の予兆と判断され、障害の発生したＩ／Ｏパスを使用するサーバとペアを構成するサーバ（つまり、将来のフェイルオーバ先サーバ）の優先順位を高くする。
【００７８】
動作パターンＰＡ２は、「ホストの無反応」を検出するためのものである。例えば、サーバからの通常の応答が所定時間以上返されないような場合、フェイルオーバ発生の予兆と判断することができる。この場合は、無応答のサーバとペアを構成するサーバの優先順位を高くする。
【００７９】
動作パターンＰＢ１は、「Releaseコマンドの受領」を検出するためのものである。Releaseコマンドとは、共有論理デバイス２６１に対する排他制御の解除を指示するコマンドである。Releaseコマンドは、共有論理デバイス２６１へのアクセスロックを取得しているサーバが発行する。Releaseコマンドが発行される場合とは、例えば、稼働系サーバを計画的に停止させるような場合である。そこで、この場合は、Releaseコマンドを発行したサーバとペアを構成するサーバの優先順位を高くする。
【００８０】
動作パターンＰＢ２は、「Resetコマンドの受領」を検出するためのものである。Resetコマンドとは、共有論理デバイス２６１へのアクセスロックを強制的に解除させるコマンドである。Resetコマンドが発行される場合とは、リンクダウンやホスト無反応等のような予兆もなく、フェイルオーバが発生するような場合である。フェイルオーバ先のサーバは、フェイルオーバの開始に際してResetコマンドを発行し、フェイルオーバ元サーバが取得している共有論理デバイス２６１へのアクセスロックを強制的に解除する。そこで、この場合は、Resetコマンドを発行したサーバ、つまり、フェイルオーバ先サーバの優先順位を高く設定する。
【００８１】
動作パターンＰＢ３は、「Reserveコマンドの受領」を検出するためのものである。Reserveコマンドとは、共有論理デバイス２６１の排他的使用を予約するためのコマンドである。ディスク排他制御に際して、先にResetコマンドを発行し、次にReserveコマンドを発行する場合もあるが、Resetコマンドを発行せずにReserveコマンドを発行する場合もある。この後者の場合に備えて、動作パターンＰＢ３を定義する。
【００８２】
動作パターンＰＢ４は、「特定アドレス範囲に対するWriteコマンドの受領」を検出するためのものである。ここで、特定アドレス範囲とは、例えば、Quoramディスク等のようなフェイルオーバクラスタを制御するための制御情報を格納する所定の記憶領域を意味する。クラスタを制御するための情報としては、例えば、共有論理デバイス２６１へのアクセスロックを取得しているサーバＩＤやファイルシステムのマウント状態等を挙げることができる。従って、この特定アドレス範囲に対してWriteコマンドが発行される場合とは、例えば、ファイルオーバ先サーバがクラスタ制御情報を更新して共有論理デバイス２６１の使用を宣言するような場合である。そこで、この場合は、特定アドレス範囲へのWriteコマンドを発行したサーバの優先順位を高くする。
【００８３】
以上述べた各動作パターンのうち、ＰＡ１，ＰＡ２，ＰＢ１は、フェイルオーバ先サーバでの処理が開始されるよりも前に、フェイルオーバの発生を検出可能な動作パターンである。従って、これらＰＡ１，ＰＡ２，ＰＢ１の各動作パターンが検出された場合は、フェイルオーバ開始前に、またはフェイルオーバの開始とほぼ同時に、フェイルオーバ先サーバの優先順位を高めておくことができる。
【００８４】
その他の動作パターンＰＢ２〜ＰＢ４は、フェイルオーバ先サーバにおいて観測される動作である。従って、これらの動作パターンＰＢ２〜ＰＢ４が検出された場合は、フェイルオーバの開始とほぼ同時に、またはフェイルオーバ開始直後に、フェイルオーバ先サーバの優先順位を高めることができる。
【００８５】
以上のように、本実施例では、フェイルオーバの発生を検出した場合、またはフェイルオーバの発生を予測した場合に、フェイルオーバ先サーバの優先順位を通常時のそれよりも高く設定する。ここで、留意すべき点は、フェイルオーバの発生検出に伴って変更された優先順位は、そのまま固定的に維持されるのではなく、フェイルオーバの終了によって初期状態（平常状態）に復帰する点である。一つの例としては、後述のように、予め設定されたフェイルオーバ時間の経過をトリガとして、優先的な取扱いが解除される。フェイルオーバ時にのみ所定のサーバの優先順位が一時的に変更される点は、本実施例の一つの特徴である。
【００８６】
図８は、サーバからの入出力要求を優先順位に基づいて処理する方法の概略を示す説明図である。図８（ａ）は、フェイルオーバ発生前またはフェイルオーバ完了後の通常時における処理順序を示す。キュー２４１には、各サーバ１１０〜１４０からの入出力要求が到着順に繋がっている。
【００８７】
図８（ａ）の例では、「サーバ３」（サーバ１３０）からの入出力要求の次に「サーバ４」（サーバ１４０）からの入出力要求が繋がり、さらに「サーバ２」（サーバ１２０）からの入出力要求が新たに到着した様子が示されている。これら各サーバの優先順位は、全て「５」に設定されており、優劣がない。従って、キュー２４１は、到着順に入出力要求を繋ぐ。入出力要求は、FIFO（First-In First-Out ）方式で到着順に処理される。
【００８８】
図８（ｂ）は、フェイルオーバ時の処理順序を示す。フェイルオーバ時には、フェイルオーバクラスタを構成する各サーバ１１０，１２０の優先順位が通常時のそれよりも高く設定される。「サーバ２」（サーバ１２０）の優先順位は、平均的な順位である「５」から最高レベルの「１」に上昇する。「サーバ２」はフェイルバック先サーバであるため、高い優先順位が与えられる。従って、キュー２４１では、入出力要求の繋ぎ替えが実行される。遅れて到着した「サーバ２」の入出力要求は、先に到着している他の入出力要求に優先してキュー２４１の先頭に繋げられる。従って、「サーバ２」の入出力要求は優先的に処理される。
【００８９】
図９は、ストレージ装置２００で実行される動的な優先順位の制御処理を示すフローチャートである。このフローチャートは、処理の概略を示すもので、実際のプログラムとは相違する。
【００９０】
まず、ユーザは、図３に示すような管理端末を介して、サーバの監視条件を管理テーブル２４２に登録する（Ｓ１）。図１０（ａ）に示すように、ユーザは、ストレージ装置２００を利用する各サーバ１１０〜１４０の全部または一部について、平常時の優先順位とフェイルオーバ時（異常事態発生時）の優先順位とをそれぞれ設定する。図示の例では、各サーバの優先順位を１０段階の数値で指定する様子を示している。これに限らず、例えば、フェイルオーバクラスタを構成するサーバをユーザが指定するだけで、予め用意されているフェイルオーバ用の初期優先順位が自動的に設定される構成でもよい。図１０（ａ）に示す登録画面Ｇ１への入力内容は、サーバ管理テーブルＴ１に記憶される。
【００９１】
図１０（ｂ）に示すように、ユーザは、各フェイルオーバクラスタ毎に、フェイルオーバの発生を検出するための一つまたは複数の動作パターンとフェイルオーバ時間とを指定することができる。この登録画面Ｇ２への入力内容は、クラスタ管理テーブルＴ２に記憶される。
【００９２】
図９に戻る。管理テーブル２４２への条件設定が終了した後（Ｓ１）、ストレージ装置２００は、フェイルオーバの監視を開始する（Ｓ２）。ストレージ装置２００は、CHA２１で検出されるチャネルパス（Ｉ／Ｏパス）障害やCHA２１が受信したコマンドに関する情報を比較的短い周期で定期的に収集する。ストレージ装置２００は、これらのコマンド等に関する情報とクラスタ管理テーブルＴ２及びパターンテーブルＴ３とを照合し、フェイルオーバの発生を監視する（Ｓ３）。
【００９３】
ストレージ装置２００は、受信したコマンドがクラスタ管理テーブルＴ２に登録されているコマンドと一致するか否か、チャネルパス障害やサーバの無応答が検出されたか否かに基づいて、フェイルオーバの発生を監視する（Ｓ４）。
【００９４】
フェイルオーバの発生またはその予兆が検出された場合（S4：YES）、ストレージ装置２００は、サーバ管理テーブルＴ１の登録内容に従って、各サーバ１１０〜１４０の優先順位を変更する（Ｓ５）。具体的には、フェイルバック先サーバの優先順位は、通常時の優先順位よりも高くなるように変更され、重要度の低いサーバの優先順位は、通常時の優先順位よりも低くされるか、または通常時と同じ値にされる。
【００９５】
フェイルオーバ先サーバは、フェイルオーバに伴う各処理を実行するために、ストレージ装置２００に対して頻繁に入出力要求を発行する。この入出力要求は、ストレージ装置２００内で優先的に処理され、ストレージ装置２００からフェイルオーバ先サーバに対して速やかに応答が返される。従って、フェイルオーバに伴う処理は、従来よりも早期に完了する。
【００９６】
ストレージ装置２００は、変更した優先順位を維持したまま、フェイルオーバが完了するまで待機する（Ｓ６）。フェイルオーバの完了待ちは、フェイルオーバ時における優先順位の一時的変更を解除するための条件として位置付けることが可能である。一つの例としては、予め設定されているフェイルオーバ時間が経過した場合に、フェイルオーバが完了したものと見なすことができる。別の例としては、フェイルオーバ先サーバからの入出力要求の発生頻度が所定レベルまで低下した場合に、フェイルオーバが完了したものと推定することもできる。あるいは、フェイルオーバ先サーバからフェイルオーバの完了を告げるコマンドや情報がストレージ装置２００に入力される場合は、このコマンド等の受信によってフェイルオーバの完了を検出することができる。
【００９７】
本実施例では、制御構造を簡素化するために、予め設定されている所定のフェイルオーバ時間が経過した場合にフェイルオーバが完了したものと判断する。但し、この方法に限らず、上述の他の方法等も採用することができる。
【００９８】
フェイルオーバの完了が検出されると（S6：YES）、ストレージ装置２００は、サーバ管理テーブルＴ１を参照し、各サーバ１１０〜１４０の優先順位をそれぞれ平常時の優先順位に戻す（Ｓ７）。これにより、各サーバ１１０〜１４０からの入出力要求は、平常時の優先順位に基づいてそれぞれ処理される。
【００９９】
図１１〜図１４に基づいて、動作パターン毎の具体的な処理の流れを説明する。図１１は、動作パターンＰＡ１の場合の流れを示す。ある時刻Ｔ１において、「サーバ１」（サーバ１１０）に何らかの障害が発生し、この結果、ファイバチャネルのリンクダウンを生じたとする（Ｓ１１）。
【０１００】
時刻Ｔ２において、ファイバチャネルのリンクダウンは、ストレージ装置２００のCHA２１により検出される（Ｓ１２）。時刻Ｔ３において、ストレージ装置２００は、フェイルオーバ先サーバである「サーバ２」（サーバ１２０）の優先順位を最高レベルに変更する（Ｓ１３）。これにより、時刻Ｔ５において、ストレージ装置２００は、最高の優先順位でサーバ１２０からの入出力要求を処理する準備を整える（Ｓ１４）。また、サーバ１２０の優先順位を高く設定した後、フェイルオーバ時間を計測するためのタイマをスタートさせる。
【０１０１】
ところで、サーバ１１０は、先にリンクダウンを発生させた後でシステムダウンし、これによりハートビート通信が途絶する。ハートビート通信が途絶すると、時刻Ｔ４において、サーバ１２０は、サーバ１１０のシステムダウンを検出する（Ｓ１５）。時刻Ｔ６において、サーバ１２０は、ResetコマンドやReserveコマンドを発行することにより、共有論理デバイス２６１の排他制御を開始する（Ｓ１６）。これにより、業務アプリケーションサービスを提供するために必要な共有論理デバイス２６１を、サーバ１２０が使用可能となる。
【０１０２】
時刻Ｔ７において、サーバ１２０は、業務アプリケーション１２１を起動し、サービス提供のために必要な入出力要求を出す（Ｓ１７）。この入出力要求によって、例えば、サーバ１２０上に必要なデータベース等が構築される。サーバ１２０からの入出力要求は、最高の優先順位で優先的に処理される。サーバ１１０のダウンをサーバ１２０が検出してディスク排他制御を開始するよりも前に、フェイルオーバ先のサーバ１２０の優先順位が事前に高く設定されている。これにより、サーバ１２０からの入出力要求に対して、ストレージ装置２００は、速やかに応答を返すことができる。
【０１０３】
サーバ１２０の優先順位を最高レベルに変更した時点（Ｔ３）から所定のフェイルオーバ時間が経過した時刻Ｔ８において、ストレージ装置２００は、サーバ１２０の優先順位を通常時の優先順位に戻す（Ｓ１８）。
【０１０４】
優先順位が初期状態に変更される時期とほぼ同時期の時刻Ｔ９において、サーバ１２０は、フェイルオーバを完了し、そのまま引き続き業務アプリケーションサービスを提供する（Ｓ１９）。時刻Ｔ１０において、ストレージ装置２００は、通常の優先順位に従って、サーバ１２０からの入出力要求を処理する（Ｓ２０）。
【０１０５】
フェイルオーバ時の高い優先順位を通常時の優先順位に戻すタイミングは、フェイルオーバ時間により決定される。この初期化タイミングは、例えば、フェイルオーバの完了直後または完了直前に設定することができるが、これらに限定されない。フェイルオーバに伴う処理の大半を完了した後で、フェイルオーバ時の優先順位を通常時の優先順位に戻すような場合でも、フェイルオーバ時間を従来よりも短縮可能である。
【０１０６】
なお、図１１に示す流れは、動作パターンＰＡ２でもほぼ同様である。サーバ１１０の無応答が検出された場合は、ディスク排他制御が開始されるよりも前に、サーバ１２０の優先順位を高く設定しておくことができる。
【０１０７】
図１２は、動作パターンＰＢ１の場合の流れを示す。動作パターンＰＢ１は、例えば、サーバ１１０の計画停止のような場合に出現する。
【０１０８】
時刻Ｔ１１において、ユーザは、サーバ１１０の業務アプリケーション１１１を停止させる（Ｓ３２）。これによりフェイルオーバ処理が開始される。フェイルオーバ元のサーバ１１０は、Releaseコマンドを発行することにより、共有論理デバイス２６１の排他的使用を放棄する（Ｓ３２）。
【０１０９】
ストレージ装置２００は、サーバ１１０からのReleaseコマンドを受信すると（Ｓ３３）、フェイルオーバ先となるサーバ１２０の優先順位を通常時の優先順位からフェイルオーバ時の高い優先順位に変更する（Ｓ３４）。これと同時に（Ｔ１２）、ストレージ装置２００は、フェイルオーバ時間を規定するタイマをスタートさせる。
【０１１０】
ストレージ装置２００は、サーバ１２０からの入出力要求を高い優先順位をもって処理し、速やかに応答を返す（Ｓ３５）。サーバ１１０が共有論理デバイス２６１の排他制御を解除した後、サーバ１２０は、フェイルオーバの開始を認識し、共有論理デバイス２６１のアクセスロックを取得する（Ｓ３６）。そして、上記同様に、サーバ１２０は、フェイルオーバに伴う各処理を実行するために、ストレージ装置２００に対して頻繁に入出力要求を出す（Ｓ３７）。
【０１１１】
フェイルオーバ時間が経過すると（Ｔ１３）、サーバ１２０の優先順位は通常時の優先順位に戻される（Ｓ３８）。サーバ１２０は、フェイルオーバを完了し、そのまま引き続き業務アプリケーションサービスを提供する（Ｓ３９）。ストレージ装置２００は、通常の優先順位に従って、サーバ１２０からの入出力要求を処理する（Ｓ４０）。
【０１１２】
図１３は、動作パターンＰＢ２の場合の流れを示す。動作パターンＰＢ２は、例えば、リンクダウンや無応答のような事象を発生させずに、サーバ１１０がダウンするような場合に出現する。
【０１１３】
時刻Ｔ２１において、サーバ１１０は何らかの障害によりダウンする（Ｓ５１）。これによりハートビート通信が途絶え、時刻Ｔ２２において、サーバ１２０は、サーバ１１０のダウンを検出する（Ｓ５２）。時刻Ｔ２３において、サーバ１２０は、ResetコマンドやReleaseコマンドを発行することにより、共有論理デバイス２６１の排他制御を開始する（Ｓ５３）。
【０１１４】
時刻Ｔ２４において、ストレージ装置２００は、サーバ１２０からResetコマンドを受信する（Ｓ５４）。ストレージ装置２００は、Resetコマンドの受信により、サーバ１２０の優先順位を通常時の優先順位よりも高く設定する（Ｓ５５）。同時に、ストレージ装置２００は、優先順位の一時的な変更を解除させるためのタイマをスタートさせる。
【０１１５】
ストレージ装置２００は、サーバ１２０からの入出力要求を優先的に処理する（Ｓ５６，Ｔ２５）。サーバ１２０は、フェイルオーバに伴う各処理のために、頻繁な入出力操作をストレージ装置２００に要求する（Ｓ５７）。フェイルオーバ時間が経過すると（Ｔ２６）、ストレージ装置２００は、サーバ１２０の優先順位を通常時の優先順位に戻す（Ｓ５８）。サーバ１２０は、フェイルオーバの完了後、業務アプリケーションサービスを引き続き提供する（Ｓ５９）。ストレージ装置２００は、通常の優先順位に従って、サーバ１２０からの入出力要求を処理する（Ｓ６０）。
【０１１６】
なお、図１３に示す流れは、動作パターンＰＢ３の場合もほぼ同様である。動作パターンＰＢ３の場合は、Resetコマンドが発行されずにReleaseコマンドが発行される。ストレージ装置２００は、サーバ１２０からReleaseコマンドを受信した場合に、サーバ１２０の優先順位をフェイルオーバ時の優先順位に変更する。
【０１１７】
図１４は、動作パターンＰＢ４の場合の流れを示す。動作パターンＰＢ４は、例えば、共有論理デバイス２６１の排他制御を行わない構成下において、リンクダウン等が生じずにフェイルオーバが実行されるような場合に出現する。
【０１１８】
時刻Ｔ３１において、サーバ１１０がダウンし、ハートビート通信が途切れると（Ｓ７１）、サーバ１２０は、サーバ１１０のダウンを検出する（Ｓ７２，Ｔ３２）。これにより、サーバ１２０は、特定アドレス領域を対象とするWriteコマンドを発行し、クラスタの制御情報を書き換える。
【０１１９】
時刻Ｔ３３において、ストレージ装置２００は、特定アドレス領域へのWriteコマンドを受信すると（Ｓ７４）、サーバ１２０の優先順位を通常時の優先順位からフェイルオーバ時の優先順位に変更する（Ｓ７５，Ｔ３４）。同時に、フェイルオーバ時間を計測するためのタイマがスタートされる。ストレージ装置２００は、サーバ１２０からの入出力要求を優先的に処理する（Ｓ７３）。これにより、フェイルオーバに伴う各処理が速やかに実行されていく。そして、Ｔ３５において、所定のフェイルオーバ時間が経過すると、ストレージ装置２００は、サーバ１２０の優先順位をフェイルオーバ時の優先順位から通常時の優先順位に戻す（Ｓ７７）。
【０１２０】
サーバ１２０は、フェイルオーバを完了した後も、引き続いて業務アプリケーションサービスを提供する（Ｓ７８）。ストレージ装置２００は、通常の優先順位に従って、サーバ１２０からの入出力要求を処理する（Ｓ７９）。
【０１２１】
本実施例は上述のように構成されるので、以下の効果を奏する。本実施例では、各サーバ１１０〜１４０の状況をストレージ装置２００側でそれぞれ観測し、これらの観測結果に応じて、各サーバ１１０〜１４０の優先順位を動的に変更可能な構成とした。従って、各サーバ１１０〜１４０の状況に応じた優先順位を設定することができる。
【０１２２】
本実施例では、各サーバ１１０〜１４０側での異常事態（フェイルオーバ発生、またはフェイルオーバ発生の予兆）をストレージ装置２００側で検出した場合は、この異常状態を生じたサーバとペアを構成するサーバの優先順位を高くする構成とした。従って、異常状態からの回復（フェイルオーバの完了）を早期に実現することができる。
【０１２３】
即ち、本実施例では、フェイルオーバ中のフェイルオーバ先サーバからの入出力要求を優先的に処理する構成とした。従って、フェイルオーバクラスタを構成するサーバ１１０，１２０のみならず、他のサーバ１３０，１４０からも利用されるストレージ装置２００において、フェイルオーバ中の応答性を改善することができ、フェイルオーバ時間の短縮を図ることができる。
【０１２４】
本実施例では、フェイルオーバの発生に関連する動作パターンＰＡ１〜ＰＢ４を予め定義し、これら各動作パターン毎に優先順位の変更方法を設定する構成とした。従って、比較的簡単な構成で、フェイルオーバを検出することができ、フェイルオーバに応じた優先順位を設定することができる。
【０１２５】
本実施例では、予め設定したフェイルオーバ時間が経過した場合に、フェイルオーバ先サーバの優先順位を通常時の優先順位に戻す構成とした。従って、フェイルオーバの進行状況に応じて優先順位を動的に制御することができ、ストレージ装置２００のコンピュータ資源を有効に利用することができる。また、時間管理によってフェイルオーバ時の優先順位を初期状態に復帰させるため、制御構成を簡素化することができる。
【０１２６】
本実施例では、ストレージ装置２００側でサーバ１１０〜１４０の状況を監視し、サーバの状況に応じて優先順位を設定する構成とした。従って、サーバ側に特別の機能を追加する必要はなく、ストレージ装置２００内で優先順位を動的に変更し、フェイルオーバ時の応答性を改善して、フェイルオーバ時間を短縮することができる。このため、接続台数やＯＳ種類等のようなサーバ構成が変化した場合でも、対応することができる。
【実施例２】
【０１２７】
図１５，図１６に基づいて第２実施例を説明する。本実施例は第１実施例の変形例に位置づけられるものである。本実施例の特徴は、管理テーブルに登録されていない状況（動作パターン）が検出された場合でも、サーバからの入出力要求の量等を考慮して、優先順位を段階的に変化させる点にある。
【０１２８】
本実施例では、クラスタ管理テーブルＴＡ２に動作パターンＰＢ１が登録されていない状況下で、動作パターンＰＢ１が検出された場合を示す。時刻Ｔ４１において、サーバ１１０の業務アプリケーション１１１を計画的に停止させる（Ｓ８１）。サーバ１１０は、Releaseコマンドを発行することにより、共有論理デバイス２６１の排他的使用を解除する（Ｓ８２）。
【０１２９】
ストレージ装置２００は、サーバ１１０からReleaseコマンドを受信すると（Ｓ８３）、クラスタ管理テーブルＴＡ２を参照する。本実施例では、「Releaseコマンド受信」を検出するための動作パターンＰＢ１がクラスタ管理テーブルＴＡ２に登録されていない。従って、Releaseコマンドを受信したストレージ装置２００は、フェイルオーバ先サーバとなるサーバ１２０の優先順位を変更しない。
【０１３０】
しかし、ストレージ装置２００は、クラスタ管理テーブルＴＡ２に登録されていない状況が検出された場合、優先順位の自動調節を開始する（Ｓ８４，Ｔ４２）。図１６にも示すように、ストレージ装置２００は、単位時間あたりの入出力要求が増大し、キューの待ち時間の方が入出力要求の処理時間よりも長くなった場合（キュー待ち時間＞Ｉ／Ｏ処理時間）、サーバ１２０の優先順位を１段階上げる（Ｔ４３）。
【０１３１】
予め設定されたフェイルオーバ時間が経過するまでは、いったん上げた優先順位は低下させない。従って、時刻Ｔ４３の後に、キュー待ち時間が入出力要求の処理時間以下になった場合でも、ストレージ装置２００は、現在の優先順位を維持する。ストレージ装置２００は、キューの待ち時間が入出力要求の処理時間を超えるたびに、その都度優先順位を１段階ずつ増加させる。
【０１３２】
ストレージ装置２００は、キュー待ち時間等に基づいて、サーバ１２０の優先順位を段階的に上げていきながら、サーバ１２０からの入出力要求を処理する（Ｓ８５）。サーバ１２０は、共有論理デバイス２６１の排他制御（Ｓ８６）や業務アプリケーションの起動処理（Ｓ８７）等を行うために、ストレージ装置２００に入出力要求を出す。これらのサーバ１２０からの入出力要求は、段階的に上昇する優先順位に基づいて、ストレージ装置２００内で処理される。
【０１３３】
優先順位の段階的な制御を開始した後、所定のフェイルオーバ時間が経過した場合、ストレージ装置２００は、サーバ１２０の優先順位を段階的に低下させる。図１６にも示すように、キュー待ち時間がＩ／Ｏ処理時間以下になった場合（キュー待ち時間≦Ｉ／Ｏ処理時間）は、優先順位が１段階低下する。優先順位の下限値は、サーバ１２０に設定されている平常時（通常時）の優先順位である。ストレージ装置２００は、サーバ１２０の優先順位が平常時の優先順位まで低下した場合、優先順位をそれ以上低下させない。
【０１３４】
サーバ１２０は、フェイルオーバ完了後も引き続き通常業務を続行する（Ｓ８８）。ストレージ装置２００は、サーバ１２０からの入出力要求を、段階的に低下していく優先順位または平常時の優先順位に基づいて、処理する（Ｓ８９）。
【０１３５】
なお、優先順位を段階的に変化させる場合の変化幅は、１段階に限らず、複数段階でもよい。また、優先順位を引き上げるときの変化幅と優先順位を引き下げるときの変化幅とを変えることもできる。
【０１３６】
また、本実施例は、フェイルオーバクラスタを構成しない他のサーバ１３０，１４０にも適用可能である。各サーバ１３０，１４０からの利用状態に応じて優先順位を段階的に変更することができる。フェイルオーバ時間が事前に設定されていない場合は、初期設定値を用いればよい。さらに、本実施例は、フェイルオーバクラスタを構成するサーバ１１０，１２０のみに限定して用いることもできる。
【０１３７】
優先順位を段階的に変化させる場合の判定方法としては、上述したキュー待ち時間とＩ／Ｏ処理時間との比較に限定されない。例えば、単位時間あたりの入出力要求（アクセス頻度）が所定値を超えた場合に優先順位を引き上げる等の構成でもよい。
【０１３８】
本実施例では、上述した実施例の効果に加えて、さらに以下の効果を奏する。本実施例では、クラスタ管理テーブルＴＡ２に登録されていない動作パターンが検出された場合でも、キュー待ち時間とＩ／Ｏ処理時間とに基づいて、優先順位を段階的に引き上げる構成とした。従って、ユーザが動作パターンの登録を忘れたような場合や予期せぬ動作パターンが検出されたような場合でも、実際の使用状況（Ｉ／Ｏ処理状況）に基づいて、優先順位を段階的に引き上げることができる。これにより、実際の使用状況に応じた優先順位を自動的に設定することができ、ストレージ装置２００の応答性を改善できる。
【０１３９】
本実施例では、予め設定されているフェイルオーバ時間が経過した後で、キュー待ち時間とＩ／Ｏ処理時間とに基づいて、優先順位を段階的に引き下げる構成とした。従って、フェイルオーバ時間内において、ストレージ装置２００は、実際の使用状況に応じた比較的高い優先順位に基づいて、サーバからの入出力要求を処理することができる。そして、フェイルオーバ時間が経過した後では、ストレージ装置２００は、実際の使用状況に基づいて優先順位を段階的に引き下げ、コンピュータ資源を他のサーバからの処理に割当てることができる。
【０１４０】
本実施例では、クラスタ管理テーブルＴＡ２に動作パターンが登録されていない場合でも、実際のストレージ装置利用状態に基づいて、優先順位を段階的に変化させる構成を採用する。従って、ストレージ装置２００のコンピュータ資源（入出力要求を処理するための資源）を、実際の利用状況に応じて配分することができる。
【実施例３】
【０１４１】
図１７〜図２０に基づいて第３実施例を説明する。本実施例は、第１実施例の変形例として位置づけられる。本実施例の特徴は、各サーバの負荷状態及びフェイルオーバ発生時の動作パターンに応じて、優先順位を動的に変更させる点にある。
【０１４２】
図１７は、ストレージシステムの全体概要を示すブロック図である。本実施例のフェイルオーバ検出部２２１は、フェイルオーバクラスタ内でのフェイルオーバを検出するだけではなく、各サーバ１１０〜１４０が過負荷状態にあるか否かも検出する。管理テーブル２４３は、管理テーブル２４２とほぼ同様の構成を備える。但し、管理テーブル２４３の一部を構成するサーバ管理テーブルＴＡ１ａには、図１８に示すように、過負荷時の優先順位と過負荷状態に対応中であるか否かを示すフラグとが含まれている。そして、スケジューラ２３１は、管理テーブル２４３により決定される優先順位に基づいて、各サーバ１１０〜１４０からの入出力要求をそれぞれ処理する。
【０１４３】
ここで、図１８に示す「過負荷時の優先順位」とは、サーバ負荷が所定値を超えた場合に、そのサーバに与えられる優先順位を示す。フェイルオーバクラスタを構成する各サーバ１１０，１２０には、それぞれ最高レベルの優先順位が設定されている。従って、これら各サーバ１１０，１２０のいずれかが過負荷状態になった場合は、フェイルオーバ実行の有無を問わずに、高い優先順位が与えられる。
【０１４４】
図１９は、サーバ負荷状態及びフェイルオーバ発生状況に基づいて、優先順位を動的に制御するための処理概要を示すフローチャートである。ユーザは、管理テーブル２４３に所定の監視条件を設定する（Ｓ１０１）。ストレージ装置２００は、管理テーブル２４３に登録された監視条件に従って、フェイルオーバの発生を監視する（Ｓ１０２）。ストレージ装置２００は、各サーバ１１０〜１４０の負荷状態を監視する（Ｓ１０３）。
【０１４５】
フェイルオーバの発生が検出されない場合（S105：NO）、サーバ負荷が所定値を超えたか否かを判定する（Ｓ１０６）。所定値を超えた過負荷状態のサーバが検出された場合（S106：YES）、ストレージ装置２００は、サーバ管理テーブルＴＡ１ａに基づいて、過負荷状態のサーバの優先順位を高く設定する（Ｓ１０７）。ここで、サーバ負荷の検出方法としては、例えば、サーバからの単位時間あたりの入出力要求の量等を計測することにより行うことができる。
【０１４６】
フェイルオーバの発生またはその予兆が検出された場合（S105：YES）、ストレージ装置２００は、過負荷状態に対応するためにサーバの優先順位を変更済であるか否かを判定し、変更済みの場合は優先順位を元の状態に戻す（Ｓ１０８）。次に、ストレージ装置２００は、フェイルオーバ先サーバの優先順を高く設定し（Ｓ１０９）、フェイルオーバが完了するまで待機する（Ｓ１１０）。フェイルオーバ時間が経過してフェイルオーバが完了したと判断された場合（S110：YES）、ストレージ装置２００は、変更した優先順位を元の状態に戻す（Ｓ１１１）。
【０１４７】
図２０は、本実施例による動作の概略を示すタイミングチャートである。時刻Ｔ５１において、「サーバ１」として示すサーバ１１０の負荷が所定値Ｌを上回ると、ストレージ装置２００は、この高負荷状態に対応すべく、サーバ１１０の優先順位を通常時よりも高く設定する。これにより、例えば、サーバ１１０が過負荷のためにシステムダウンする可能性を少なくしたり、システムダウンまでの時間を長くすることができる。
【０１４８】
サーバ１１０の優先順位を高くした後で、サーバ１１０にリンクダウン等を生じる場合がある。この場合、ストレージ装置２００は、フェイルオーバ先のサーバ１２０の優先順位を高く設定する。
【０１４９】
このように、本実施例では、サーバ負荷が所定値Ｌよりも高い場合、この過負荷状態のサーバ（将来のフェイルオーバ元サーバ）の優先順位を高く設定する。そして、この過負荷状態のサーバがシステムダウンしてフェイルオーバが開始される場合は、フェイルオーバ先サーバの優先順位を高く設定する。
【０１５０】
なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、各実施例を適宜組み合わせることができる。
【図面の簡単な説明】
【０１５１】
【図１】本発明の実施形態の概念を示す説明図である。
【図２】ストレージ装置の外観を示す斜視図である。
【図３】ストレージ装置の機能ブロック図である。
【図４】ストレージシステムの全体構成を示すブロック図である。
【図５】フェイルオーバクラスタの構成を示す説明図である。
【図６】フェイルオーバの様子を示す模式図である。
【図７】管理テーブルの一例を示す説明図である。
【図８】優先順位に基づいてキューの処理順序を入れ替える様子を示す説明図である。
【図９】優先順位制御処理を示すフローチャートである。
【図１０】監視条件の設定を行うための画面例を示す説明図である。
【図１１】リンクダウン等によるフェイルオーバの進行状況を示す説明図である。
【図１２】計画停止等によるフェイルオーバの進行状況を示す説明図である。
【図１３】リンクダウン等を伴わないフェイルオーバの進行状況を示す説明図である。
【図１４】排他制御を実施しない場合のフェイルオーバの進行状況を示す説明図である。
【図１５】本発明の第２実施例に係り、検出された動作パターンが未登録の場合に優先順位を段階的に制御する様子を示す説明図である。
【図１６】優先順位が段階的に変化する様子を示す説明図である。
【図１７】本発明の第３実施例に係るストレージシステムのブロック図である。
【図１８】サーバ管理テーブルの構成を示す説明図である。
【図１９】優先順位制御処理を示すフローチャートである。
【図２０】将来のフェイルオーバ元サーバの優先順位を高く設定した後で、フェイルオーバ先サーバの優先順位を高く設定する様子を示すタイミングチャートである。
【符号の説明】
【０１５２】
１Ａ〜１Ｃ…サーバ、２…ストレージ装置、２Ａ…所定の事象、２Ｂ…優先的処理操作、３，４…通信ネットワーク、５…状況検出部、６…優先度制御部、７…状況パターン検出用情報、８…処理優先度管理用情報、９…タイミングチャート、１０…ストレージ装置、１１…基本筐体、１２…増設筐体、１３…制御パッケージ、１４…電源ユニット、１５…バッテリユニット、１６…冷却ファン、２１…チャネルアダプタ、２１Ａ…通信ポート、２２…ディスクアダプタ、２３…キャッシュメモリ、２４…共有メモリ、２５…スイッチ部、２６…ディスクドライブ、２７…RAIDグループ、２８…SVP、３０…ホストコンピュータ、３１…管理端末、１１０〜１４０…サーバ、１１１，１２１…業務アプリケーションプログラム、１１２，１２２…ハートビート監視部、１１３，１２３…起動停止制御部、１１４，１２４…ディスク排他制御部、１１５，１２５…ポート、２００…ストレージ装置、２１１〜２１４…ポート制御部、２２０，２２１…フェイルオーバ検出部、２３０，２３１…スケジューラ、２４０…メモリ、２４１…キュー、２４２，２４３…管理テーブル、２５０…ディスク制御部、２６０…記憶装置、２６１…論理デバイス（論理ボリューム）、ＣＮ…通信ネットワーク、Ｇ１，Ｇ２…登録画面、ＰＡ１〜ＰＢ４…動作パターン
【図１】
2005301442.tif 000003
【図２】
2005301442.tif 000004
【図３】
2005301442.tif 000005
【図４】
2005301442.tif 000006
【図５】
2005301442.tif 000007
【図６】
2005301442.tif 000008
【図７】
2005301442.tif 000009
【図８】
2005301442.tif 000010
【図９】
2005301442.tif 000011
【図１０】
2005301442.tif 000012
【図１１】
2005301442.tif 000013
【図１２】
2005301442.tif 000014
【図１３】
2005301442.tif 000015
【図１４】
2005301442.tif 000016
【図１５】
2005301442.tif 000017
【図１６】
2005301442.tif 000018
【図１７】
2005301442.tif 000019
【図１８】
2005301442.tif 000020
【図１９】
2005301442.tif 000021
【図２０】
2005301442.tif 000022