JP4012498B2 - 情報処理システム、情報処理装置、情報処理装置の制御方法及びプログラム - Google Patents

Description

本発明は、情報処理システム、情報処理装置、情報処理装置の制御方法、及びプログラムに関し、特に、記憶装置の障害の検出に関する。

近年、情報処理システムで取り扱われるデータ量が増大している。大容量化した記憶装置では記憶容量に見合うだけの入出力性能と信頼性を確保する必要がある。そのため記憶装置への論理パス（入出力経路）を多重化し、記憶装置へのデータ入出力要求（ＩＯ要求）を論理パスに適宜割り当てるものが開発されている。

この論理パスに障害が発生したときに、全ノードの論理ディスク管理テーブルを書き換えることによってＩＯパスの切り替えを行うことによって、ＩＯパス切り替えのために要する時間を短縮する技術が提案されている（例えば、特許文献１参照。）。

また、システムを構成し、切り離し可能な各部位毎に障害検出回数を記憶するカウンタを設け、またそのカウンタ値を総合的に判定する論理を具備することによって、故障部位を高精度に特定し、故障部位をシステムより排除し、正常部位を用いたシステム動作を継続可能とする技術も提案されている（例えば、特許文献２参照。）。
特開２００２−４９５７５号公報 特開平１１−２９６３１１号公報

前述した従来の技術では、複数設けられた全てのパスに障害が発生して、何回かリトライを行ってＩＯ処理が行えないことが検出されてからサーバを切り替えるものであり、障害検出期間中のスループットの低下については考慮されていなかった。

本発明は、全パスに障害が検出される前に予防的にサーバを切り替えることによって、検出期間中のスループットの低下を防止することを目的とする。

本発明は、物理デバイスに論理的に設定された論理ユニットを備える記憶装置と、前記記憶装置に切り替えて接続され、前記記憶装置に対してデータ入出力を要求する複数の情報処理装置と、を備え、前記論理ユニットと前記複数の情報処理装置との通信経路となる複数のパスを経由してデータ入出力を要求する情報処理システムにおいて、前記情報処理装置は、データ入出力要求の結果からパスに発生した障害を検出する障害検出部と、前記検出された障害の種類を特定する障害管理部と、前記特定された障害の種類によって前記情報処理装置の切り替えの実行の判定基準となるパス数を変更し、所定数のパスに障害が発生したことを検出し、前記所定数が前記判定基準となるパス数を超えた場合は、全てのパスに障害が発生して完全な遮断状態に至る前の段階で、前記記憶装置に接続される情報処理装置を切り替えると判定するサーバ切替評価部と、前記切替評価部の判定結果に基づいて、前記論理ユニットに対してデータ入出力を要求する情報処理装置を切り替える切替部と、を備えることを特徴とする。

本発明によると、サーバを切り替える際のパス障害検出期間中のスループットを向上させることができる。

以下、本発明の実施の形態を図面を参照して説明する。

図１は、本実施の第１の形態の情報処理システムの全体構成を示すブロック図である。

情報処理システムは、複数のサーバ（情報処理装置）１００ａ、１００ｂがクラスタ構成をとっているクラスタシステム１０、及び、少なくとも１台の記憶装置２００を含んで構成される。なお、本実施の形態においては、１台のクラスタシステム１０と１台の記憶装置２００とを備える情報処理システムについて説明するが、複数台のクラスタシステム１０及び複数台の記憶装置２００を備える情報処理システムであってもよい。

サーバ１００は、ＣＰＵ（Central Processing Unit）やメモリ等を備え、クライアント端末２０からの指示によって、記憶装置２００に記憶されたデータにアクセスしながら、各種アプリケーションプログラムを実行する。また、サーバ１００には、クラスタシステム１０内での当該サーバの動作を管理し、サーバを切り替えるフェイルオーバ処理を行うクラスタ管理部１１５（クラスタソフトウェア）１１５が設けられている。また、サーバ１００は、複数のパスを論理的に管理し、アプリケーションプログラム１１０からのＩＯ要求を発行するパスを定めるパス管理部１２０を備えている。

サーバ１００には、ネットワーク（例えば、ＳＡＮ（Storage Area Network））を介して記憶装置２００が接続されている。サーバ１００と記憶装置２００との間のＳＡＮを介する通信は、一般にファイバチャネルプロトコル（Fibre Channel Protocol）に従って行われる。すなわち、サーバ１００からは、記憶装置２００に対して、ファイバチャネルプロトコルに従ってブロック単位のデータアクセス要求が送信される。なお、サーバ１００と記憶装置２００とは、必ずしもＳＡＮで接続される必要はなく、ＬＡＮ等のネットワークを介して接続されてもよいし、ＳＣＳＩ（Small Computer System Interface）インターフェースによって直接接続されてもよい。

サーバ１００と記憶装置２００との間を接続するＳＡＮには、サーバ１００と記憶装置２００とを接続するハードウェアによって物理的に構成される通信経路である物理パス３００が設定されている。サーバ１００は、複数の物理パス３００を介して記憶装置２００に記憶されているデータにアクセスする。パス管理部１２０は、記憶装置２００へのＩＯ要求を送信する物理パス３００を多重化して、帯域幅を拡大することによって、データアクセスにおけるボトルネックを解消し、データ入出力処理性能を向上させる。なお、パス管理部１２０は、物理パス３００に対応して設定される論理パスによって、物理パス３００を管理する。

また、サーバ１００は、ネットワーク（例えば、ＬＡＮ：Local Area Network）を介して、記憶装置クライアント端末２０と接続されている。

記憶装置２００は、複数の論理ユニット（ＬＵ：LogicaI Unit）２２０を備え、サーバ１００から送信されてくるＩＯ要求に応じてデータの入出力を処理する。論理ユニット２２０は、記憶装置２００に備わる記憶資源（物理デバイス）を論理的に設定した記憶領域である。図１において、記憶装置２００は、二つの論理ユニットによって構成されているが、３以上の論理ユニットを備えてもよい。記憶資源としては、ハードディスク装置（ディスクアレイ装置）の他、フレキシブルディスク装置や半導体記憶装置等、様々な記憶媒体を用いることができる。

なお、本実施の形態では、サーバ１００がコンピュータ（パーソナルコンピュータ、ワークステーション、メインフレームコンピュータ等）である場合について説明したが、サーバ１００が、ルータ、ハブ等のネットワーク装置であってもよい。

図２は、本発明の第１の実施の形態のサーバ１００の詳細を表した機能ブロック図である。

サーバ１００は、クラスタ管理部１１５、サーバ切替指示部１１６、パス管理ドライバ１３０備えている。また、サーバ１００には、ホスト・バス・アダプタ（ＨＢＡ）及びＨＢＡドライバで構成されるインターフェース（ＩＦ）１４０が設けられている。

パス管理ドライバ１３０は、ＩＯ送受信部１３１、パス選択部１３２、障害検出部１３３、障害管理部１３４、稼動統計管理部１３５及びサーバ切替評価部１３６が設けられている。

ＩＯ送受信部１３１は、パス管理部１２０が受け取ったＩＯ要求を、パス選択部１３２によって選択されたパス（インターフェース１４０）に送出し、インターフェース１４０が受け取ったＩＯ終了をアプリケーション１１０に通知する。

パス選択部１３２は、サーバ１００と記憶装置２００との間の物理パス３００を論理的に管理する。また、パス選択１３２は、アプリケーション１１０が発行したＩＯ要求を割り当てるＩＦ１４０を決定して、当該ＩＯ要求に使用されるパス３００を選択する。そして、ＩＯ要求を各物理パス３００へ適宜振り分けることによって負荷分散処理も行う。さらに、パス選択部１３２は、ある物理パス３００に障害が発生した場合に当該物理パス３００を切り離して、正常な物理パス３００を通じて記憶装置２００へのデータアクセスを継続する機能も有している。これにより、物理パスの障害によるサービス停止を回避しシステムの信頼性を高めている。

障害検出部１３３は、ＩＯ要求に対して記憶装置２００が発行したＩＯ終了通知によって、ＩＯ処理が正常に終了したかを監視する。障害検出部１３３は、ＩＯ処理が異常終了したパスＩＤ、パスの状態（オンラインか、オフラインか）、障害の発生原因、異常終了が通知された時刻を記憶するＩＯ管理テーブルを保持している。障害検出部１３３が、ＩＯ処理が異常に終了したことを検出すると、ＩＯ管理テーブルに障害が発生したパスに関する情報を記憶して、ＩＯ管理テーブルを更新する。

また、障害検出部１３３は、アプリケーション１１０からのＩＯ要求及び記憶装置２００からのＩＯ終了通知から、正常に終了したＩＯ要求のデータ量、当該ＩＯ要求に要した処理時間を取得する。

障害管理部１３４は、パス障害管理テーブル（図７）を保持している。障害管理部１３４は、ＩＯ管理テーブルを読み出すことによってパスの障害情報を取得する。そして、取得したパスの障害情報をパス障害管理テーブルに記憶し、パス毎、エラーの種類毎に計数されるエラーの検出回数（検出値）を更新する。

稼動統計管理部１３５は、稼動統計管理テーブル（図９）を保持している。稼動統計管理部１３５は、障害検出部１３３が取得したＩＯ要求及びＩＯ終了通知から、正常に終了したＩＯ要求のデータ量、当該ＩＯ要求に要した処理時間を取得し、稼動統計管理テーブルの該当パス及び該当期間のデータ量（バイト数）及び時間のデータを更新する。

サーバ切替評価部１３６は、パスに発生したエラーの検出結果に基づいて、クラスタ内のサーバを切り替えるフェイルオーバを実行するかを決定し、その結果をサーバ切替指示部１１６に送る。このフェイルオーバを実行するかを判定するため、サーバ切替評価部１３６は、パスに発生するエラーを解析して、以下の３種類のエラー（瞬断エラー、累計エラー、性能エラー）を解析する。

瞬断エラーは、同一パスで一つのＩＯにおいてエラーが発生したが、続けて発行されるＩＯは正常に終了した場合に、瞬断エラーと判定される。瞬断エラーは、光ファイバの摩耗や、電源の不安定等の要因によって、伝送経路が不安定となった場合に生じる。

累計エラーは、一定期間内（例えば、一月間）に、所定回数を超えるエラーが発生した場合、累計エラーと判定される。なお、一定期間のエラー回数によって累計エラーを判定するのではなく、エラーを計数する期間を定めずに、一定回数のエラーが発生したら累計エラーと判断してもよい。また、連続した所定回数のＩＯ要求の内でエラーとなった回数が所定の閾値を超えたり、全ＩＯ要求のうち所定割合のＩＯ要求がエラーとなったら累計エラーと判断してもよい。

性能エラーは、このパスが設置された状態と比較して、所定の値だけ性能が劣化した場合に、性能エラーと判定される。後述するように、稼動統計管理部１３５においてＩＯ処理のデータ量と処理時間を取得し、設置当初よりレスポンスが６０％劣化した場合に性能エラーと判定することができる。

ＩＦ１４０は、記憶装置２００との間で通信を行うためのインタフェースであり、ホスト・バス・アダプタ（ＨＢＡ）及びＨＢＡドライバを含んでいる。ＨＢＡは、例えば、ＳＣＳＩ（Small Computer System Interface）アダプタ、ファイバチャネルアダプタ等のＨＢＡ（Host Bus Adapter）である。ＩＦ１４０は、パス３００に固有に設けられており、パス選択部１３２によって割り当てられたＩＯ要求を処理し、記憶装置２００に対してアクセスする。すなわち、サーバ１００は、ＩＦ１４０によって、記憶装置２００との間でデータ入出力要求（ＩＯ要求）等を授受することができる。

図３は、本発明の第１の実施の形態の障害検出部の動作を示すブロック図である。

アプリケーション１１０は、記憶装置２００に記憶されているデータにアクセスするために、パス管理部１２０に入出力を要求する。パス管理部１２０は、ＩＯ要求受付部１２１によって、アプリケーション１１０によって発行されるＩＯ要求を受け取る。受け取ったＩＯ要求は、パス管理ドライバ１３０に送られ、物理パス３０１〜３０８が選択されて、ＩＯ要求が選択されたパスに対して送信される。

物理パスがオンライン状態（稼動時）であれば、アプリケーション１１０によって発行されたがＩＯ要求は、記憶装置２００によって処理され、ＩＯ処理が正常に終了した旨のＩＯ終了通知が返送される。このＩＯ処理通知は、ＩＯ終了通知部１２２によってアプリケーション１１０に通知される。

しかし、物理パスがオフライン状態（障害時）では、アプリケーション１１０によって発行されたがＩＯ要求は、記憶装置２００によって処理されることなく、記憶装置２００までの経路においてタイムアウトし、パス管理ドライバ１３０に対してＩＯ処理が異常終了した旨をＩＯ終了通知が返送される。パス管理ドライバ１３０は、ＩＯ処理が異常終了した旨を検出すると、他のパスが選択されて、ＩＯ要求が記憶装置２００に対して送信される。そして、ＩＯ要求が記憶装置２００によって処理されると、ＩＯ処理が正常に終了した旨のＩＯ終了通知が返送される。

例えば、図３に示すように、パス３０２に対してＩＯ要求を送信したが、このときパス３０２に障害が生じていた場合、障害検出部１３３がこれを検出して、パス選択部１３２が他のパス３０３を選択して、ＩＯ要求を記憶装置２００に対して送信する。そして、記憶装置２００から返送されたＩＯ終了通知は、アプリケーション１１０に対して送信される。

前述したパスのエラーは、主にパスを構成する伝送経路の一時的な断線によって生じる障害である。例えば、光ファイバの摩耗がによって瞬断が生じる。よって、同時期に設置された光ファイバは同時期に摩耗して一時的な断線状態（瞬断状態）となり、ＩＯ処理に一時的な障害が発生する。そして、何ら措置がとられないと、完全な断線状態に至ってＩＯ障害となる。

サーバ切替部１１６は、サーバ切替評価部１３６による決定に基づいて、サーバを切り替えるクラスタフェイルオーバを実行させるためのサーバ切替指示をクラスタ管理部１１５に発行する。

図４は、本発明の第１の実施の形態のクラスタ切替判定に用いるテーブルの例を説明する図であり、８本のパスが設けられている場合に、サーバ切替部１１６が、前述した３種類のエラーの判定結果に基づいて、サーバを切り替える判定基準を示す。

テーブルの上段に示すケース１では、全パスのうち半数以上のパスに瞬断エラーが発生した場合に（正常なパスが半数未満となった場合に）、サーバを切り替えることを示す。なお、理解の容易のため図４では、パス１〜パス４に瞬断エラーが発生した場合を示したが、エラーが発止したパスが連続しない他の４本のパスの組み合わせである場合にもフェイルオーバを行うと判定される。

テーブルの中段に示すケース２では、全パスのうち７０％以上のパスに累計エラーが発生した場合に（正常なパスが３０％未満となった場合に）、サーバを切り替えることを示す。なお、理解の容易のため図４では、パス１〜パス６に累計エラーが発生した場合を示したが、エラーが発止したパスが連続しない他の６本のパスの組み合わせである場合にもフェイルオーバを行うと判定される。

テーブルの下段に示すケース３では、全パスのうち８０％以上のパスに性能エラーが発生した場合に（正常なパスが２０％未満となった場合に）、サーバを切り替えることを示す。なお、理解の容易のため図４では、パス１〜パス７に性能エラーが発生した場合を示したが、エラーが発止したパスが連続しない他の７本のパスの組み合わせである場合にもフェイルオーバを行うと判定される。

なお、一つのパスに複数のエラーが発生していると判定される場合には、スループットの低下への影響が大きく、情報処理システムが停止に至る可能性が高い重大なエラーを当該パスに生じたエラーであると判定する。図４に示す場合では、瞬断エラーは光ファイバの摩耗が主たる原因であり、同時期に設置された光ファイバは同時期に摩耗して故障する可能性が高いため、半数のパスにエラーが発生した場合にフェイルオーバを実行して、早めにサーバを切り替えて、スループットの低下を防止している。一方、性能エラーの場合には、ＩＯ処理に時間がかかるだけで、ＩＯの処理が行えない訳ではないので、多くのパスに性能エラーが発生するまでフェイルオーバを行うことなく、現用のサーバ及びパスにて稼動させるようにしている。

図５は、本発明の第１の実施の形態のサーバ切替処理のフローチャートである。

まず、アプリケーション１１０が発行しＩＯ要求受付部１２１が受信したＩＯ要求は、パス選択部１３２が選択したパス３０１〜３０８に対して、ＩＯ送受信部１３１によって送信される。そして、記憶装置２００によるＩＯ処理が完了すると、ＩＯ処理が正常に終了した旨のＩＯ終了通知が、記憶装置２００から発行され、ＩＯ送受信部１３１及びＩＯ終了通知部１２２を経由して、アプリケーション１１０に返される（Ｓ５０１）。なお、ＩＯ処理が正常に終了しなかった場合には、ＩＯ処理が異常終了した旨のＩＯ終了通知は発行される。

ＩＯ処理が完了すると、当該ＩＯ処理に関するＩＯ障害（エラー）を検出する（Ｓ５０２）。そして、当該検出された障害に関する情報を障害管理テーブルへ記載して、障害管理テーブルを更新し（Ｓ５０３）、ステップＳ５０５に進む。一方、ＩＯ障害「無」と判定されると、当該パスのＩＯ処理の結果を稼動統計テーブルへ記載し、稼動統計テーブルの当該パスの性能情報を更新し（Ｓ５０４）、ステップＳ５０５に進む。

ステップＳ５０５では、図４において前述した方法（又は、図１２において後述する方法）によって、全パスの障害状態を評価する。そして、所定の閾値との比較結果に基づいてサーバ切替の必要性を判定する（Ｓ５０６）。

図６は、本発明の第１の実施の形態の障害管理テーブル更新処理のフローチャートであり、サーバ切替処理（図５）のステップＳ５０３において実行される。

まず、障害検出部１３３が、記憶装置２００等から発行されたＩＯ終了通知によって、ＩＯ処理が正常に行われたか、ＩＯ処理の途中でエラーが生じたかを評価する（Ｓ６０１）。

そして、ＩＯ障害の有無を判定する（Ｓ６０２）。その結果、ＩＯ障害「無」と判定されると、累計エラーに関する処理（Ｓ６０３〜Ｓ６０６）を実行することなく、ステップＳ６０７へ移行する。一方、ＩＯ障害「有」と判定されると、ステップＳ６０３へ移行して、累計エラーに関する処理（Ｓ６０３〜Ｓ６０６）を実行する。

累計エラーに関する処理では、まず、障害管理テーブル内の当該パスの累計エラー欄における開始時刻と監視期間を参照して、現在時が所定の監視時間範囲内であるかによって、所定の監視時間内に生じたＩＯ障害であるかを判定する（Ｓ６０３）。その結果、所定の監視時間内に生じたＩＯ障害であれば、ステップＳ６０６に移行し、累計エラーの検出値にエラー回数（１回）を加算し、この処理を終了する。

一方、ステップＳ６０３による判定の結果、所定の監視時間外に発生したエラーであると判定されると、現在時刻を監視の開始時刻に設定し（Ｓ６０４）、累計エラーの検出値を”０”にして（Ｓ６０５）、新たな監視時間を開始する。そして、累計エラーの検出値にエラー回数（１回）を加算し（Ｓ６０６）、この処理を終了する。

次に、ＩＯ障害「無」と判定されステップＳ６０７へ移行すると、所定の瞬断監視時間（図６に示す例では１秒前）の間に実行されたＩＯ処理における、ＩＯ障害の有無を判定する（Ｓ６０７）。その結果、過去１秒間にＩＯ障害が発生していないと判定されると、瞬断エラーに関する処理（Ｓ６０８〜Ｓ６１１）を実行することなく、エラーは発生していないと判定して（ステップＳ６１２）、この処理を終了する。

一方、過去１秒間にＩＯ障害が発生していると判定されると、ステップＳ６０３へ移行して、瞬断エラーに関する処理（Ｓ６０８〜Ｓ６１１）を実行する。

瞬断エラーに関する処理では、まず、障害管理テーブル内の当該パスの瞬断エラー欄における開始時刻と監視期間を参照して、現在時が所定の監視時間範囲内であるかによって、所定の監視時間内に生じたＩＯ障害であるかを判定する（Ｓ６０８）。その結果、所定の監視時間内に生じたＩＯ障害であれば、ステップＳ６１１に移行し、瞬断エラーの検出値にエラー回数（１回）を加算し、この処理を終了する。

一方、ステップＳ６０８による判定の結果、所定の監視時間外に発生したエラーであると判定されると、現在時刻を監視の開始時刻に設定し（Ｓ６０９）、瞬断エラーの検出値を”０”にして（Ｓ６１０）、新たな監視時間を開始する。そして、瞬断エラーの検出値にエラー回数（１回）を加算し（Ｓ６１１）、この処理を終了する。

図７は、本発明の第１の実施の形態のパス障害管理テーブルの説明図である。

パス障害管理テーブルには、パス毎、エラーの種類毎に、当該種類のエラーに関する監視開始時刻、監視期間、判定値、検出値が記憶されている。

例えば、瞬断エラーは、２００３年９月１日１０時２０分３０．０２秒から３０日間を監視時間として監視が行われる。その監視時間内に瞬断エラーの発生が検出されると検出値が１ずつ加算され、障害管理テーブルが更新される。また、監視時間内に、判定値（２０回）の瞬断エラーの発生が検出されると、当該パスは瞬断エラーとであると判定される。なお、監視時間内に複数回の瞬断エラーが検出されたときに瞬断エラーが発生したと判定するのは、電源の不安定等の一時的な要因によるパスの不安定を瞬断エラーであると誤認することを避けるためである。

なお、性能エラーは複数回のＩＯ処理の平均によって定められるので、１回でも性能の低下が認められると性能エラーであると判定することから、監視期間は定められていない。

図８は、本発明の第１の実施の形態の稼動統計テーブル更新処理のフローチャートであり、サーバ切替処理（図５）のステップＳ５０４において実行される。

まず、サーバ内に設けられたタイマから月日及び時間を取得して、当該月の特定の日時（図６に示す例では月初め、すなわち１日の０時）であるかを判定する（Ｓ８０１）。そして、月初めでなければステップＳ８０４に移行する。一方、月初めが検出されると、稼動統計テーブルに新たに始まる月のデータを記録する欄を追加し（Ｓ８０２）、ＩＯ処理において当該パスに送付したデータ量、及び当該ＩＯ処理に要した時間を”０”に初期設定して（Ｓ８０３）、新たな期間における性能の監視の準備をする。

そして、正常に終了したＩＯ処理において使用したパスに送付したデータ量、及び当該ＩＯ処理に要した時間を稼動統計テーブルの該当する欄に加算する（Ｓ８０４）。

そして、所定の割合（図８に示す例では６０％）だけ性能が劣化しているかを判定する（Ｓ８０５）。この判定は、定期的（例えば、１日１回）や、ユーザからの指示によって行われる。この判定の結果、６０％の性能劣化が見られたら性能エラーと判定して（Ｓ８０６）、この処理を終了する。一方、６０％までも性能が劣化していなかったら性能エラーと判定することなく、この処理を終了する。

なお、図８では、月単位で当該パスの性能（当該パスによるＩＯ処理のレスポンス）を集計しているが、任意の期間を設定して性能を監視してもよい。

図９は、本発明の第１の実施の形態の稼動統計管理テーブルの説明図である。

稼動統計管理テーブルには、パス毎、月毎に、ＩＯ処理によって当該パスに送付したデータ量の累積値、及び当該パスにおけるＩＯ処理に要した時間の累積値が記録されている。そして、累積データ量を累積処理時間で除することによって、当該監視期間のＩＯ処理のレスポンスを求めることができる。

なお、稼動統計テーブルには、性能が最も良好であった期間（通常は設置時）のレスポンスと、現在の監視期間のＩＯ処理のデータ量の累積値及びＩＯ処理の所要時間の累積値を記録していれば足りる。

また、図９に示す稼動統計管理テーブルでは、ＩＯ処理のデータ量とＩＯ処理の所要時間とを月毎に記録しているが、他の監視期間を定めて、パスの性能を監視してもよい。

図１０は、本発明の第１の実施の形態のサーバ切替判定処理のフローチャートであり、サーバ切替処理（図５）のステップＳ５０６において実行される。

まず、障害管理テーブル（図７）を参照して、パス毎に検出値が判定値を超えているか否かを判定する（Ｓ１００１）。検出値が判定値を超えていれば、エラーが発生したパスを特定する（Ｓ１００２）。この判定値との比較作業を全てのパスについて行う。

そして、ＩＯ処理負荷が高い時間帯（日中）であるか否かを判定する（Ｓ１００３）。本実施の形態のような情報処理システムでは、ＩＯ処理負荷が高い時間帯（高負荷時間帯）と、ＩＯ処理負荷が低い時間帯（低負荷時間帯））とが存在する。例えば、銀行のオンラインシステムや航空会社における座席予約システムの場合には日中の負荷が高くなるので、予めＩＯ処理負荷を調査した結果に基づいて、高負荷時間帯と低負荷時間帯とを定めておく。

そして、日中（高負荷時間帯）であれば、サーバ切替閾値テーブル（図１１）の日中欄を選択し（Ｓ１００４）、夜間（低負荷時間帯）であれば、サーバ切替閾値テーブルの夜間欄を選択して（Ｓ１００５）、判定閾値を定める。図１１に示すサーバ切替閾値テーブルでは、エラーの種類毎に全パス数に対して判定閾値となるパス数の比率が定められている。

そして、ステップＳ１００２で特定したエラーが発生しているパス数と、Ｓ１００４又はＳ１００５で選択した閾値とを比較して（Ｓ１００６）、エラーパス数が閾値以上であれば、サーバ切替指示を発行する（Ｓ１００７）。

すなわち、図１１に示すサーバ切替閾値テーブルで、全パス数が８本であり、瞬断エラーの場合には、日中は４本（８本×０．５＝４）が閾値となるが、夜間は３本（８本×０．４＝３．２）が閾値となる。よって、夜間は日中より少ない本数のパスで瞬断エラーが検出されてもサーバの切替（フェイルオーバ）が発生することになる。よって、ＩＯ負荷が高い時間帯（日中）にはフェイルオーバを抑制して、ＩＯ負荷が低い時間帯（夜間）に優先してフェイルオーバをさせることができる。

なお、判定閾値を時間によって定めるのではなく、稼動統計管理部１３５が収集したＩＯ処理量やスループットに基づいて、ＩＯ処理負荷が低い時間帯の判定閾値を緩和して定め、フェイルオーバを促進し、ＩＯ処理負荷が高い時間帯の判定基準を厳しく定め、フェイルオーバを抑制するようにしてもよい。

図１２は、本発明の第２の実施の形態のパスの障害判定に用いるテーブルの例を説明する図である。

第２の実施の形態では、エラーが発生しているパスの、エラーの種類によって定められた点数を加算して、各パスで合計することによって点数を算出して、フェイルオーバをするかを判定するものであり、第１の実施の形態（図４）のようにパスに１種類のエラーが発生している場合の他、パスに複数種類のエラーが発生している場合も的確に障害を判定することができる。

具体的には、瞬断エラーの場合は”２”を、累計エラーの場合は”１．４３”を、性能エラーの場合は”１．２５”を加算して、合計点数を求める。そして、全パス本数と比較してフェイルオーバをするかを判定する。このエラーの種類毎のエラー点数は、スループットの低下に対する影響の大きさによって、そのエラーが重大であれば点数を高くして、早めにサーバを切り替えるようにしている。

例えば、テーブルの上段に示すケース４では、３本のパスに瞬断エラーが発生しており、２本のパスに累計エラーが発生しているので、合計点数は、
３×２＋２×１．４３＝８．８６ となり、全パス数（８本）を超えるのでフェイルオーバが必要と判定される。

同様に、テーブルの中段に示すケース５では、３本のパスに累計エラーが発生しており、４本のパスに性能エラーが発生しているので、合計点数は、
３×１．４３＋４×１．２５＝９．２９ となり、全パス数（８本）を超えるのでフェイルオーバが必要と判定される。

さらに、テーブルの下段に示すケース６では、２本のパスに瞬断エラーが発生しており、２本のパスに累計エラーが発生しており、２本のパスに性能エラーが発生しているので、合計点数は、
２×２＋２×１．４３＋２×１．２５＝９．３６ となり、全パス数（８本）を超えるのでフェイルオーバが必要と判定される。

図１３は、本発明の第２の実施の形態のサーバ切替判定処理のフローチャートであり、サーバ切替処理（図５）のステップＳ５０６において実行される。なお、第２の実施の形態では、サーバ切替処理が異なるのみで他の処理は前述した第１の実施の形態と同じなので、その詳細な説明は省略する。

まず、障害管理テーブル（図７）を参照して、パス毎に検出値が判定値を超えているか否かについて判定する（Ｓ１３０１）。検出値が判定値を超えていれば、閾値を超えているエラーの種類を求め、エラーの種類を特定する（Ｓ１３０２）。この判定値との比較作業を全てのパスについて行う。

このとき、複数の種類のエラーの検出値が判定値を超えていれば、その中で一番重要なエラーをそのパスのエラーの種類として特定する。エラーの重要度は、スループットの低下に対する影響等を考慮して予め定めておく。例えば、瞬断エラー、累計エラー、性能エラーの順に重要なエラーとして定めておくとよい。また、検出された複数の種類のエラーのポイントを加算してもよい。

そして、ＩＯ処理負荷が高い時間帯（日中）であるか否かを判定する（Ｓ１３０３）。本実施の形態のような情報処理システムでは時間帯によってＩＯ処理負荷が異なることから、高負荷時間帯と低負荷時間帯とを定めておく。

そして、日中（高負荷時間帯）であれば、エラー点数テーブル（図１４）の日中欄を選択し（Ｓ１３０４）、夜間（低負荷時間帯）であれば、エラー点数テーブルの夜間欄を選択して（Ｓ１３０５）、各エラーに関連して加算される点数を定める。図１４に示すエラー点数テーブルでは、エラーの種類毎に、そのエラーが発生したパスに付与される点数が定められている。

そして、ステップＳ１３０２でパス毎に特定されたエラーの種類に対応して定まるエラー点数の合計値と、閾値（本実施の形態ではパス数）とを比較して（Ｓ１３０６）、エラー点数の合計値が閾値以上であれば、サーバ切替指示を発行する（Ｓ１３０７）。

以上説明したように、第２の実施の形態では、エラーの種類によって定められた点数を用いることによって、パスに発生したエラーが複数種類にわたっている場合にも的確に障害を判定することができる。また、８本のパス中の６本のパスに性能エラーが発生した場合、日中ではエラー点数が７．５（６本×１．２５）となり、夜間ではエラー点数が８．２８（６本×１．３８）となり判定閾値（８本）を超える。よって、ＩＯ負荷が高い時間帯（日中）にはフェイルオーバを抑制して、ＩＯ負荷が低い時間帯（夜間）に優先してフェイルオーバをさせることができる。

なお、エラー点数を時間によって定めるのではなく、稼動統計管理部１３５が収集したＩＯ処理量やスループットに基づいて、ＩＯ処理負荷が低い時間帯はエラー点数を高くし、ＩＯ処理負荷が高い時間帯はエラー点数を低く定めるようにしてもよい。

図１５は、本発明の第３の実施の形態のサーバ切替判定処理のフローチャートであり、サーバ切替処理（図５）のステップＳ５０６において実行される。

第３の実施の形態では、時間帯（又は、ＩＯ処理負荷）によって判定閾値を変える第１の実施の形態と異なり、時間帯によって判定対象となるエラー種別を変えることによって、フェイルオーバを抑制する。なお、第３の実施の形態では、サーバ切替処理が異なるのみで他の処理は前述した第１の実施の形態と同じなので、その詳細な説明は省略する。

まず、障害管理テーブル（図７）を参照して、パス毎に検出値が判定値を超えているか否かについて判定する（Ｓ１５０１）。検出値が判定値を超えていれば、閾値を超えているエラーの種類を求め、エラーの種類を特定する（Ｓ１５０２）。この判定値との比較作業を全てのパスについて行う。このとき、一つのパスにおいて複数の種類のエラーの検出値が判定値を超えていれば、当該複数のエラーをそのパスのエラーの種類として特定する。

そして、ＩＯ処理負荷が高い時間帯（日中）であるか否かを判定する（Ｓ１５０３）。本実施の形態のような情報処理システムでは時間帯によってＩＯ処理負荷が異なることから、高負荷時間帯と低負荷時間帯とを定めておく。

そして、日中（高負荷時間帯）であれば、性能エラーを除外して、パス毎のエラー種別を特定し直す（Ｓ１５０４）。すなわち、あるパスに性能エラーのみが発生している場合には、当該パスにはエラーが発生していないものとする。また、あるパスに性能エラー及び他のエラー（例えば、瞬断エラー）のみが発生している場合には、当該パスには当該他のエラー（瞬断エラー）が発生しているものとする。

そして、ステップＳ１００２で特定したエラーが発生しているパス数と、予め定めた閾値（例えば、パス数の半分）とを比較して（Ｓ１５０５）、エラーパス数が閾値以上であれば、サーバ切替指示を発行する（Ｓ１５０６）。

なお、ステップＳ１５０２、Ｓ１５０４でパス毎に特定されたエラーの種類に対応して定まるエラー点数の合計値と、閾値（本実施の形態ではパス数）とを比較して、エラー点数の合計値が閾値以上であれば、サーバ切替指示を発行してもよい。

以上説明したように、第３の実施の形態では、一部の種類のエラーについてはエラーの判定をしないので（又は、一部の種類のエラーのみについてエラーの判定をするので）、ＩＯ負荷が高い時間帯（日中）にはフェイルオーバを抑制して、ＩＯ負荷が低い時間帯（夜間）に優先してフェイルオーバをさせることができる。

本発明の実施の形態では、情報処理装置は、データ入出力要求の結果からパスに発生した障害を検出する障害検出部と、所定数のパスに障害が発生したことを検出すると、全てのパスに障害が発生する前でも、前記記憶装置に接続される情報処理装置を切り替える情報処理装置の切り替えを実行するかを判定する切替評価部と、前記切替評価部の判定結果に基づいて、前記論理ユニットに対してデータ入出力を要求する情報処理装置を切り替える切替部と、を備えるので、サーバを切り替える際のパス障害検出期間中のスループットを向上させることができると共に、全パスに障害が検出される前に予防的にサーバを切り替えることによって、検出期間中のスループットの低下を防止することができる。

また、前記サーバ切替評価部は、前記障害検出部によって特定された障害の種類によって、前記情報処理装置の切り替えの実行の判定基準となるパス数を変更するので、障害の重大度に応じて適切な情報処理装置の切り替えの判定をすることができる。

また、前記サーバ切替評価部は、前記障害検出部によって特定された複数種類の障害の組み合わせに基づいて前記情報処理装置の切り替えの実行を判定するので、複数のパスに異なる種類の障害が発生しても適切に情報処理装置の切り替えの判定をすることができる。

また、前記サーバ切替評価部は、データ入出力要求の負荷状態に応じて前記情報処理装置の切り替えの実行の判定基準となるパス数を変更するので、高負荷時間帯における情報処理装置の切り替えを抑制し、低負荷時間帯における情報処理装置の切り替えを促進するので、業務に影響が少ない時間帯に情報処理装置の切り替えをさせることができる。

本発明の第１の実施の形態の情報処理システムの全体構成を示すブロック図である。 本発明の第１の実施の形態のサーバ１００の詳細を表した機能ブロック図である。 本発明の第１の実施の形態の障害検出部１３３の動作を示すブロック図である。 本発明の第１の実施の形態のクラスタ切替判定に用いるテーブルの説明図である。 本発明の第１の実施の形態のサーバ切替処理のフローチャートである。 本発明の第１の実施の形態の障害管理テーブル更新処理のフローチャートである。 本発明の第１の実施の形態の障害管理テーブルの説明図である。 本発明の第１の実施の形態の稼動統計テーブル更新処理のフローチャートである。 本発明の第１の実施の形態の稼動統計管理テーブルの説明図である。 本発明の第１の実施の形態のサーバ切替判定処理のフローチャートである。 本発明の第１の実施の形態のサーバ切替閾値テーブルの説明図である。 本発明の第２の実施の形態のパスの障害判定に用いるテーブルの例の説明図である。 本発明の第２の実施の形態のサーバ切替判定処理のフローチャートである。 本発明の第２の実施の形態のエラー点数テーブルの説明図である。 本発明の第３の実施の形態のサーバ切替判定処理のフローチャートである。

符号の説明

１０ クラスタシステム
１００ 情報処理装置
１１０ アプリケーション
１１５ クラスタ管理部
１１６ サーバ切替指示部
１２０ パス管理部
１３０ パス管理ドライバ
１３１ ＩＯ送受信部
１３２ パス選択部
１３３ 障害検出部
１３４ 障害管理部
１３５ 稼動統計管理部
１３６ サーバ切替評価部
１４０ インターフェース（ＩＦ）
２００ 記憶装置
２１０ ディスク制御部
２２０ 論理ユニット（ＬＵ）
３００ 物理パス

Claims (17)

1. 物理デバイスに論理的に設定された論理ユニットを備える記憶装置と、
   前記記憶装置に切り替えて接続され、前記記憶装置に対してデータ入出力を要求する複数の情報処理装置と、を備え、
   前記論理ユニットと前記複数の情報処理装置との通信経路となる複数のパスを経由してデータ入出力を要求する情報処理システムにおいて、
   前記情報処理装置は、
   データ入出力要求の結果からパスに発生した障害を検出する障害検出部と、
   前記検出された障害の種類を特定する障害管理部と、
   前記特定された障害の種類によって前記情報処理装置の切り替えの実行の判定基準となるパス数を変更し、所定数のパスに障害が発生したことを検出し、前記所定数が前記判定基準となるパス数を超えた場合は、全てのパスに障害が発生して完全な遮断状態に至る前の段階で、前記記憶装置に接続される情報処理装置を切り替えると判定するサーバ切替評価部と、
   前記切替評価部の判定結果に基づいて、前記論理ユニットに対してデータ入出力を要求する情報処理装置を切り替える切替部と、を備えることを特徴とする情報処理システム。
2. 前記障害管理部は、パスの瞬断によって生じる瞬断エラーを特定し、
   前記サーバ切替評価部は、前記瞬断エラーによる情報処理装置の切り替えの実行の判定基準となるパス数を、他のエラーによる情報処理装置の切り替えの実行の判定基準となるパス数より大きく設定することを特徴とする請求項１に記載の情報処理システム。
3. 前記障害管理部は、パスの性能の劣化によって生じる性能エラーを特定し、
   前記サーバ切替評価部は、前記性能エラーによる情報処理装置の切り替えの実行の判定基準となるパス数を、他のエラーによるフェイルオーバの実行の判定基準となるパス数より小さく設定することを特徴とする請求項１に記載の情報処理システム。
4. 前記サーバ切替評価部は、前記特定された複数種類の障害の組み合わせに基づいて前記情報処理装置の切り替えの実行を判定することを特徴とする請求項１に記載の情報処理システム。
5. 前記サーバ切替評価部は、パスに発生した種類の障害に応じて定められた点数の集計結果に基づいて、前記情報処理装置の切り替えを実行するかを判定することを特徴とする請求項４に記載の情報処理システム。
6. 前記サーバ切替評価部は、データ入出力要求の負荷状態に応じて前記情報処理装置の切り替えの実行の判定基準となるパス数を変更することを特徴とする請求項１に記載の情報処理システム。
7. 前記サーバ切替評価部は、データ入出力要求の負荷状態が高くなる時間帯には、前記情報処理装置の切り替えの実行の判定基準となるパス数を、他の時間帯より小さく設定することを特徴とする請求項１に記載の情報処理システム。
8. 物理デバイスに論理的に設定された論理ユニットを備える記憶装置と、
   前記記憶装置に切り替えて接続され、前記記憶装置に対してデータ入出力を要求する複数の情報処理装置と、を備え、
   前記論理ユニットと前記複数の情報処理装置との通信経路となる複数のパスを経由してデータ入出力を要求する情報処理システムにおいて、
   前記情報処理装置は、
   前記記憶装置に送信されるデータ入出力要求を割り当てるパスを選択するパス選択部と、
   前記パス選択部によって選択されたパスに対して発生したデータ入出力要求を送出するＩＯ送受信部と、
   正常に終了したデータ入出力要求の処理状態を集計する稼動統計管理部と、
   前記パスに発生した障害を検出する障害検出部と、
   前記検出された障害の種類を特定し、パス毎、エラーの種類毎にエラーの検出回数を集計する障害管理部と、
   前記特定された障害の種類によって前記情報処理装置の切り替えの実行の判定基準となるパス数を変更し、所定数のパスに障害が発生したことを検出し、前記所定数が前記判定基準となるパス数を超えた場合は、全てのパスに障害が発生して完全な遮断状態に至る前の段階で、前記記憶装置に接続される情報処理装置を切り替えると判定するサーバ切替評価部と
   前記切替評価部の判定結果に基づいて、前記論理ユニットに対してデータ入出力を要求する情報処理装置を切り替える切替部と、を備えることを特徴とする情報処理システム。
9. 物理デバイスに論理的に設定された論理ユニットを備えた記憶装置に対して、前記記憶装置に対して切り替えて接続され、前記論理ユニットと複数の情報処理装置との通信経路となる複数のパスを経由してデータ入出力を要求する情報処理装置において、
   データ入出力要求の結果からパスに発生した障害を検出する障害検出部と、
   前記検出された障害の種類を特定する障害管理部と、
   前記特定された障害の種類によって前記情報処理装置の切り替えの実行の判定基準となるパス数を変更し、所定数のパスに障害が発生したことを検出し、前記所定数が前記判定基準となるパス数を超えた場合は、全てのパスに障害が発生して完全な遮断状態に至る前の段階で、前記記憶装置に接続される情報処理装置を切り替えると判定するサーバ切替評価部と、
   前記切替評価部の判定結果に基づいて、前記論理ユニットに対してデータ入出力を要求する情報処理装置を切り替える切替部と、を備えることを特徴とする情報処理装置。
10. 前記サーバ切替評価部は、前記特定された複数種類の障害の組み合わせに基づいて前記情報処理装置の切り替えの実行を判定することを特徴とする請求項９に記載の情報処理装置。
11. 前記サーバ切替評価部は、データ入出力要求の負荷状態に応じて前記情報処理装置の切り替えの実行の判定基準となるパス数を変更することを特徴とする請求項９に記載の情報処理装置。
12. 物理デバイスに論理的に設定された論理ユニットを備えた記憶装置に対して、前記論理ユニットと複数の情報処理装置との通信経路となる複数のパスを経由してデータ入出力を要求する情報処理装置において、前記記憶装置に接続される複数の情報処理装置を切り替える情報処理装置の制御方法であって、
    データ入出力要求の結果からパスに発生した障害を検出し、
    前記検出された障害の種類を特定し、
    前記特定された障害の種類によって前記情報処理装置の切り替えの実行の判定基準となるパス数を変更し、
    所定数のパスに障害が発生したことを検出し、前記所定数が前記判定基準となるパス数を超えた場合は、全てのパスに障害が発生して完全な遮断状態に至る前の段階で、前記記憶装置に接続される情報処理装置の切り替えを実行すると判定し、
    前記切替評価部の判定結果に基づいて、前記論理ユニットに対してデータ入出力を要求する情報処理装置を切り替えることを特徴とする制御方法。
13. 前記検出した障害の種類を特定し、
    前記特定された複数種類の障害の組み合わせに基づいて前記情報処理装置の切り替えの実行を判定することを特徴とする請求項１２に記載の制御方法。
14. データ入出力要求の負荷状態に応じて前記情報処理装置の切り替えの実行の判定基準となるパス数を変更することを特徴とする請求項１２に記載の制御方法。
15. 物理デバイスに論理的に設定された論理ユニットを備えた記憶装置に対して、前記論理ユニットと複数の情報処理装置との通信経路となる複数のパスを経由してデータ入出力を要求する情報処理装置を機能させるプログラムであって、
    データ入出力要求の結果からパスに発生した障害を検出する手段と、
    前記検出された障害の種類を特定する手段と、
    前記特定された障害の種類によって前記情報処理装置の切り替えの実行の判定基準となるパス数を変更する手段と、
    所定数のパスに障害が発生したことを検出し、前記所定数が前記判定基準となるパス数を超えた場合は、全てのパスに障害が発生して完全な遮断状態に至る前の段階で、前記記憶装置に接続される情報処理装置の切り替えを実行すると判定する手段と、
    前記切替評価部の判定結果に基づいて、前記論理ユニットに対してデータ入出力を要求する情報処理装置を切り替える手段として機能させることを特徴とするプログラム。
16. 前記特定された複数種類の障害の組み合わせに基づいて前記情報処理装置の切り替えの実行を判定する手段として機能させることを特徴とする請求項１５に記載のプログラム。
17. データ入出力要求の負荷状態に応じて前記情報処理装置の切り替えの実行の判定基準となるパス数を変更する手段として機能することを特徴とする請求項１５に記載のプログラム。

Images