JP4686303B2 - ストレージ管理方法およびストレージシステム - Google Patents

Description

本発明は、データの複製を行うストレージシステムに関するものである。

近年、ネットワークを経由して複数のサーバからストレージ装置にアクセスするSAN(Storage Area Network)や、NAS(Network Attached Storage)では、高機能化や大規模化が進みつつある。その一例として、ストレージ装置に備えたリモートコピー機能を利用して、他の作業を中断せず、データを遠隔地などに複製（コピー）を行い、冗長性を高める手法が知られている。
また、遠隔地にある２サイト（拠点）でデータを常に同期させておき、地震や火災など拠点が失われるような災害時でも、他方のサイトのネットワークを利用して業務が直ちに再開できる、冗長性を高める手法が知られている。さらに、広域災害や同時多発テロ等により複数の拠点が同時に利用できなくなった場合のダメージを考え、３サイト以上で冗長性を維持する手法も知られている。
このような状況下において、複数のサイトで構成されるような大規模構成システムで冗長性を維持するため、複数のサイトに跨ったデータのコピーを実施する必要がある。その際に、一つのサイトで障害が発生すると、コピーの失敗により、関連するサイトにおいても障害が誘発する可能性がある。
そこで、従来、そのような障害に対処するため、複数の障害から根本原因を特定する方法が知られている。この方法では、常に最新の状態に更新されているSANトポロジ・マップに対して、発生した障害の情報をマッピングしていき、そこから導かれる障害の時間的・空間的関連性から問題を判定する（例えば、特許文献１）。
特開２００１−２４９８５６号公報

しかし、特許文献１に記載の方法を複数のサイトに跨る大規模なシステムに適用するには、次のような問題があった。すなわち、第１の問題として、SANトポロジ・マップに必要な情報量は、システムを構成する装置数の自乗に比例して増大するため、たとえば数千台程度の装置で構成されるシステムではSANトポロジ・マップを作成するのが困難であった。第２の問題として、サイト内の通信帯域が狭い場合、SANトポロジ・マップを構築するために必要なデータの収集時間が遅延するため、SANトポロジ・マップを常に最新の状態で維持することが困難であった。
このため、たとえ、コピー障害の原因を判定することが困難であったとしても、そのコピー障害に対する適切な対処を行いやすくすることが望まれていた。
そこで、本発明は、前記問題に鑑みてなされたもので、コピー障害に対する適切な対処を行いやすくすることを目的とする。

前記した課題を解決するために本発明は、複数のストレージ装置と、前記ストレージ装置の各々を管理する各管理サーバと、前記各管理サーバとの間で通信を行う計算機とを含んで構成されるコンピュータシステムを用いて実行されるストレージ管理方法であって、前記管理サーバは、管理下の前記ストレージ装置の接続形態を表す接続情報と、当該ストレージ装置のボリュームとペアを組むペアボリュームに関するペアボリューム情報とを格納する記憶部を有し、前記計算機は、前記管理サーバから、一または複数のストレージ装置でのコピーに関する障害の通知を受けた場合、当該通知された障害にかかわるペアボリュームのボリュームを有するストレージ装置を管理する管理サーバに対し、当該ペアボリュームに関するペアボリューム情報の送信要求を行い、前記送信要求を受けた管理サーバは、当該送信要求されたペアボリューム情報を記憶部から読み出して、前記計算機に送信し、前記ペアボリューム情報を受信した計算機は、当該ペアボリューム情報に示されたボリュームを有するストレージ装置に対し、当該ストレージ装置の接続形態を表す接続情報の送信要求を行い、当該接続情報の送信要求を受けた管理サーバは、前記送信要求されたストレージ装置の接続情報を前記記憶部から読み出して、前記計算機に送信し、前記送信された接続情報を受信した計算機は、当該接続情報から、前記通知された障害にかかわるペアボリューム間の中継経路を特定して外部に表示する。

本発明によれば、コピー障害に対する適切な対処を行いやすくすることができる。

[実施の形態１]
図１は本発明の実施の形態１におけるシステム全体の構成例を示すブロック図である。ここでは、東京（First Site）、大阪（Second Site）、福岡（Third Site）の３サイト１１、１２、１３により構成された大規模構成システムを例示している。
各サイト１１〜１３は、ストレージ管理システム（管理サーバともいう）２、３、４の各々に接続され、各ストレージ管理システム２、３、４がIP（Internet Protocol）ネットワーク５３を介してマルチサイト管理システム（計算機ともいう）１に接続されている。サイト１１とサイト１２との間は、IPネットワーク５１によって接続されている。サイト１２とサイト１３との間は、IPネットワーク５２によって接続されている。なお、図１では、図示されていないが、東京と福岡の各サイト１１、１３間を接続するIPネットワークも存在し、各サイト１１〜１３間の相互接続を実現しているものとする。
そして、各サイト１１〜１３では、複数のホスト２００に接続されたＳＡＮ（Storage Area Network）２１〜２３が構築されている。ＳＡＮ２１には、ストレージ装置３１とFC-IP（Fiber Channel−Internet Protocol）変換装置（単に「変換装置」あるいは「中継装置」ともいう）４１とが接続されている。同様に、ＳＡＮ２２、２３の各々にも、ストレージ装置３２、３３と変換装置４２、４３とが接続されている。
なお、ネットワークの接続形態として、各サイト１１〜１３相互間では専用線などのネットワークを介して実現するようにしてもよい。また、ＳＡＮ２１〜２３の各々にはネットワーク用スイッチを接続するようにしてもよい。

［ストレージ装置の構成］
次に、ストレージ装置３１〜３３の構成について説明する。ここでは、ストレージ装置３１の構成について詳述するが、ストレージ装置３２、３３の構成も同様であるため、重複説明を適宜省略する。
図１に示すように、ストレージ装置３１は、ボリューム６１と、コントロールユニット（中継装置）７１と、ポート（中継装置）８１とを含んで構成されている。コントロールユニット７１は、ボリューム６１に関する制御機能や、コピー機能あるいはリモートコピー機能などをもつ。
ボリューム６１は、例えば、一または複数の記憶装置（ハードディスクドライブなど）をＲＡＩＤ（Redundant Array of Independent Disks）構成により形成された仮想的な記憶領域を意味する。ボリューム６１は、他のボリューム（例えば、大阪サイトのボリューム６２など）とペアボリュームを組む。図１では、ストレージ装置３１内に１つのボリューム６１が記載されているが、複数のボリュームが存在するものとする。
ペアボリュームとは、コントロールユニット７１、７２、７３、７４、７５のコピー機能（同一のストレージ装置内のコピー機能）あるいはリモートコピー機能（複数のストレージ装置間のコピー機能）を用いた正ボリューム（複製元ボリューム）と副ボリューム（複製先ボリューム）の組を指す。
なお、ストレージ装置３２は、２つのボリューム６２、６３と、３台のコントロールユニット７２、７３、７４と、２つのポート８２、８３とを含んで構成されている。

［ストレージ管理システムの構成］
次に、ストレージ管理システム２〜４の構成について説明する。なお、図１では、１台のストレージ管理システム２の構成が記載されているが、他のストレージ管理システム３、４も同様の構成である。
ストレージ管理システム２〜４は、管理下の各サイト１１〜１３を管理している。具体的には、ストレージ管理システム２は東京のサイト１１を管理し、ストレージ管理システム３は大阪のサイト１２を管理する。また、ストレージ管理システム４は福岡のサイト１３を管理する。
ストレージ管理システム２は、管理下のサイト１１内の装置（ホスト、ストレージ装置、スイッチ、FC-IP変換装置の各々を意味する）にLAN(Local Area Network)もしくはFC（Fibre Channel）を介して接続されている。そして、ストレージ管理システム２は、SNMP（Simple Network Management Protocol）や、各装置（ホスト、ストレージ装置、スイッチ、FC-IP変換装置）の専用APIなどにより、サイト１１内の装置（ホスト、ストレージ装置、スイッチ、FC-IP変換装置）の管理や監視を行っている。

図１に示すように、ストレージ管理システム２は、ＣＰＵ（処理部）１０１Ａと、メモリ１０１Ｂと、ハードディスク装置１０１Ｃとを含んで構成されている。
メモリ１０１Ｂには、SAN情報収集プログラム１０１と障害監視プログラム１０２とがロードされている。また、ハードディスク装置１０１Ｃには、ＤＢ（Data Base）１０３とＧＵＩ１０４とを有する。ＧＵＩは、Graphical User Interfaceの略であり、ウィンドウなどの画像を表示するためのプログラムを表す。ＣＰＵ１０１Ａは、各種のプログラム１０１、１０２、１０４に従って実行する。
SAN情報収集プログラム１０１は、ストレージ管理システム２〜４が管理しているサイト１１〜１３内の装置（ホスト、ストレージ装置、スイッチ、FC-IP変換装置）の設定や動作情報（性能情報）を定期的に収集している。このSAN情報収集プログラム１０１が収集した情報は、後記するペアボリューム情報テーブル２２１（図２参照）やSAN構成情報テーブル２４１（図５参照）、障害イベントログ情報テーブル２６１（図８参照）として作成されたり更新されたりして、ストレージ管理システム２内のＤＢ１０３に格納される。
障害監視プログラム１０２は、障害イベントログ情報テーブル２６１〜２６３（図８〜図１０参照）を参照してペアボリュームに関する障害を検知した場合に、そのペアボリュームに関する障害イベント通知メッセージをマルチサイト管理システム１に送信する。

［マルチサイト管理システムの構成］
次に、マルチサイト管理システム１の構成について説明する。マルチサイト管理システム１は、各サイト１１〜１３のストレージ管理システム２〜４とIPネットワーク５３によって接続されている。
図１に示すように、マルチサイト管理システム１は、ＣＰＵ（処理部）１１１Ａと、メモリ１１１Ｂと、ハードディスク装置１１１Ｃとを含んで構成されている。
メモリ１１１Ｂには、障害特定プログラム１１１とデータパス構築プログラム１１２とがロードされている。また、ハードディスク装置１１１Ｃには、ＤＢ（Data Base）１１３とＧＵＩ（Graphical User Interface）１１４とを有する。ＣＰＵ１１１Ａは、各種プログラム１１１、１１２、１１４に従って実行する。
障害特定プログラム１１１は、ストレージ管理システム２〜４から通知された障害イベント通知メッセージを受信すると、その障害イベント通知メッセージを基にデータパス構築プログラム１１２を用いて各サイト１１〜１３からデータパス（ペアボリューム間におけるデータの流れを表したもの）を構築するための情報を選別したり収集したりする。収集したデータパスを受け取った障害特定プログラム１１１は、構築されたデータパス上に存在する障害イベントを各サイト１１〜１３から収集する。
そして、ＣＰＵ１１１Ａが、障害の特定および運用上問題が波及する影響範囲をマルチサイト管理システム１の管理者用端末１１５（コンピュータの表示装置）にＧＵＩ１１４を用いて表示する。また、ＣＰＵ１１１Ａが、障害の影響範囲にあるサイト１１〜１３に障害警告メッセージを送信する。これらの内容は後記する。

［各種テーブルの構成例］
次に、各サイト１１〜１３を管理するストレージ管理システム２〜４のＤＢに管理されているペアボリューム情報テーブル２２１〜２２３の構成例を図２ないし図４に基づいて説明する。
図２はペアボリューム情報テーブル２２１（ペアボリューム情報ともいう）の構成例を示す図である。ペアボリューム情報テーブル２２１は、東京のサイト１１を管理するストレージ管理システム２のＤＢで管理されている。
図２に示すように、ペアボリューム情報テーブル２２１は、正ボリュームと副ボリュームとの項目（列）を含んで構成されている。正ボリュームは複製元のボリュームを表し、副ボリュームは複製先のボリュームを表す。
正ボリュームには、装置名と、Vol部品名と、CU部品名と、Port部品名との項目を含んでいる。装置名には、複製元のストレージ装置を識別するための情報（例えば、ストレージ装置３１を表す「ST01」など）が示され、Vol部品名には、正ボリュームを識別するための情報（例えば、ボリューム６１を表す「01」など）が示される。

CU部品名には、正ボリュームを制御するコントロールユニットを識別するための情報（例えば、コントロールユニット７１を表す「11」など）が示され、Port部品名には、正ボリュームに用いられるポートを識別するための情報（例えば、ポート８１を表す「21」など）が示される。
また、副ボリュームにも、正ボリュームの場合と同様、装置名と、Vol部品名と、CU部品名と、Port部品名との項目を含んでいる。装置名には、複製先のストレージ装置を識別するための情報（例えば、ストレージ装置３２を表す「ST02」など）が示され、Vol部品名には、副ボリュームを識別するための情報（例えば、ボリューム６２を表す「02」など）が示される。
CU部品名には、副ボリュームを制御するコントロールユニットを識別するための情報（例えば、コントロールユニット７２を表す「12」など）が示され、Port部品名には、副ボリュームに用いられるポートを識別するための情報（例えば、ポート８２を表す「22」など）が示される。

このようなテーブル２２１の各値は、ストレージ管理システム２のSAN情報収集プログラム１０１の機能により収集される。具体的には、ストレージ管理システム２のSAN情報収集プログラム１０１は、例えば、定期的あるいはペアボリューム作成時に、ストレージ装置３１のコントロールユニット７１から、ペアボリュームの正ボリューム（図２の正ボリュームのVol部品名２２５で指定されるもの）と副ボリューム（図２の副ボリュームのVol部品名２２９で指定されるもの）を制御するコントロールユニット（図２のCU部品名２２６、２３０で指定されるもの）とポート（図２のPort部品名２２７、２３１で指定されるもの）の情報を問い合わせる。そして、このSAN情報収集プログラム１０１は、問い合わせに対する情報を収集し、これらの情報を用いてペアボリューム情報テーブル２２１の項目（列）２２４〜２３１を作成したり更新したりする。

また、大阪のサイト１２を管理するストレージ管理システム３のＤＢにも、図３に示すペアボリューム情報テーブル２２２が管理される。さらに、福岡のサイト１３を管理するストレージ管理システム３のＤＢにも、図３に示すペアボリューム情報テーブル２２３が管理される。これらのテーブル２２２、２２３も、図２のテーブル２２１と同様の構成である。

なお、図２ないし図４において、「ST01」〜「ST03」の装置名はストレージ装置３１〜３３（図１参照）の各々を表し、「01」〜「04」のVol部品名はボリューム６１〜６４（図１参照）の各々を表す。「１１」〜「１５」のCU部品名はコントロールユニット７１〜７５（図１参照）の各々を表し、「２１」〜「２４」のPort部品名はポート８１〜８４（図１参照）の各々を表す。

次に、各サイト１１〜１３を管理するストレージ管理システム２〜４のＤＢに管理されているSAN構成情報テーブル２４１〜２４３の構成例を図５ないし図７に基づいて説明する。
図５はSAN構成情報テーブル２４１（ストレージ装置の接続形態を表す接続情報ともいう）の構成例を示す図である。SAN構成情報テーブル２４１は、東京のサイト１１を管理するストレージ管理システム２のＤＢで管理されている。
図５に示すように、SAN構成情報テーブル２４１は、装置種別と装置名と部品名との項目（列）を含んで構成されている。
装置種別には、ストレージ装置、変換装置、ボリューム、ＣＵ（コントロールユニット）、ポートのいずれかの種別が示される。
装置名には、装置種別で指定された装置の所属装置（ストレージ装置、変換装置）を識別するための情報（例えば、「ST01」「FP01」など）が示され、部品名には、装置名で指定された部品（ボリューム、ＣＵ、ポート）を識別するための情報（例えば、「01」など）が示される。

このようなテーブル２４１の各値は、ストレージ管理システム２のSAN情報収集プログラム１０１の機能により収集される。具体的には、ストレージ管理システム２のSAN情報収集プログラム１０１は、例えば、定期的あるいはSAN構成変更時に、ストレージ装置３１および変換装置４１の各々に対して、ボリュームやコントロールユニット、ポートの位置を特定するための情報（図５の項目２２４〜２２６）を問い合わせる。そして、このSAN情報収集プログラム１０１は、問い合わせに対する情報を収集し、これらの情報を用いてSAN構成情報テーブル２４１の項目（列）２４４〜２４６を作成したり更新したりする。

また、大阪のサイト１２を管理するストレージ管理システム３のＤＢにも、図６に示すSAN構成情報テーブル２４２が管理される。さらに、福岡のサイト１３を管理するストレージ管理システム３のＤＢにも、図７に示すＳＡＮ構成情報テーブル２４３が管理される。これらのテーブル２４２、２４３も、図５のテーブル２４１と同様の構成である。

なお、図５ないし図７において、「FI01」〜「FI04」の装置名は変換装置４１〜４４（図１参照）の各々を表す。「‐」は空データを表す。

次に、各サイト１１〜１３を管理するストレージ管理システム２〜４のＤＢに管理されている障害イベントログ情報テーブル２６１〜２６３の構成例を図８ないし図１０に基づいて説明する。
図８は障害イベントログ情報テーブル２６１の構成例を示す図である。障害イベントログ情報テーブル２６１は、東京のサイト１１を管理するストレージ管理システム２のＤＢで管理されている。
図８に示すように、障害イベントログ情報テーブル２６１は、装置種別と装置名と部品名と障害イベントと報告済フラグの項目（列）を含んで構成されている。
装置種別には、ＣＰＵ１０１Ａによって障害が検出された装置（ポート、ＣＵなど）の種別が示され、障害イベントには、障害の内容が示される。
報告済みフラグは、当該障害イベントをマルチサイト管理システム１に報告したことを示すフラグである。報告済みであれば「○」の値が書き込まれ、未報告であれば「‐」の値が書き込まれる。
なお、装置名と部品名の項目には、図５〜図７に示した装置名と部品名の各値が示される。

このようなテーブル２６１の各値は、ストレージ管理システム２のSAN情報収集プログラム１０１の機能により収集される。具体的には、ストレージ管理システム２のSAN情報収集プログラム１０１は、例えば、定期的にあるいはSNMPなどにより障害を検知した時に、ストレージ装置３１および変換装置４１の各々から、ボリューム６１やコントロールユニット７１、ポート８１などの性能情報を収集する。そして、このSAN情報収集プログラム１０１は、その性能情報の中から、障害に関する情報（図８の障害イベント２６７で指定されるもの）とその障害が発生した装置の位置に関する情報（図８の項目２６４〜２６６で指定されるもの）を抽出する。そして、このSAN情報収集プログラム１０１は、抽出した情報を用いて障害イベントログ情報テーブル２６１を作成する。

なお、ストレージ管理システム２の障害監視プログラム１０２は、障害イベントログ情報テーブル２６１から、例えば、ペアボリュームの障害に関する情報（障害イベント）を検知したとき、その障害イベントをマルチサイト管理システム１に通知する。ペアボリュームの障害として、ペアボリューム同期失敗、コピー/リモートコピープログラム内部エラーなどがある。また、ペアボリューム以外の障害として、例えば、ハードウェア障害・カーネルパニック・メモリエラー・電源ダウンなどの装置の障害や、通信接続失敗・ポート閉塞・リンクタイムアウト・パケット未到達などの通信の障害、ボリューム閉塞・アクセスエラーなどのボリュームの障害がある。これらの障害も障害イベントログ情報テーブル２６１に登録される。

大阪のサイト１２を管理するストレージ管理システム３のＤＢにも、図９に示す障害イベントログ情報テーブル２６２が管理される。さらに、福岡のサイト１３を管理するストレージ管理システム４のＤＢにも、図１０に示す障害イベントログ情報テーブル２６３が管理される。これらのテーブル２６２、２６３も、図８のテーブル２６１と同様の構成である。

次に、マルチサイト管理システム１のＤＢに管理されているサイト情報テーブル３００の構成例を図１１に基づいて説明する。
図１１に示すように、サイト情報テーブル３００は、装置種別と装置名とサイト名との項目（列）を含んで構成されている。装置種別には、ストレージ装置または変換装置のいずれかの種別が示され、装置名には、装置種別で指定された装置を識別するための情報が示される。サイト名には、東京、大阪または福岡のいずれかの拠点が示される。このような構成により、ストレージ装置または変換装置と、その設置先のサイトとの対応付けが可能となる。

このようなサイト情報テーブル３００は、どのサイトのストレージ管理システムにどの装置の情報収集を依頼するかどうかの判断材料として用いられるものであり、マルチサイト管理システム１によって作成される。具体的には、マルチサイト管理システム１は、各ストレージ管理システム２〜４のSAN構成情報テーブル２２１〜２２３（図２〜図４）を参照し、各サイト１１〜１３内のストレージ装置３１〜３３と変換装置４１〜４４の各々の位置を識別するための情報（図１１の項目３０１〜３０３で指定されるもの）を収集したり更新したりする。この収集・更新は、例えば、一定間隔あるいはストレージ管理システム２〜４から障害イベントの通知を受けたときに行われる。

[抽象データパスの具体例]
次に、ペアボリュームを抽象的に表した抽象データパスについて説明する。
図１２は抽象データパスの概念図である。ここでは、カスケード接続されたペアボリュームの集合を表す抽象データパスを例にして説明する。
図１２では、ボリューム４０１（「０１」のVol部品名）、ボリューム４０２（「０２」のVol部品名）、ボリューム４０３（「０３」）、ボリューム４０４（「０４」）の順に流れる抽象データパスが表されている。
このうち、ボリューム４０１とボリューム４０２の関係をみると、ボリューム４０１を正ボリュームとしたペアボリュームが形成され、ボリューム４０１から４０２へのリモートコピー４１１が行われている。これは、ペアボリューム情報テーブル２２１（図２の最上段のレコード参照）に示された関係と同じである。次に、ボリューム４０２とボリューム４０３の関係をみると、ボリューム４０２を正ボリュームとしたペアボリュームが形成され、ボリューム４０２から４０３へのコピー４１２が行われている。これは、ペアボリューム情報テーブル２２２（図３の最上段から２段目のレコード参照）に示された関係と同じである。
ボリューム４０３とボリューム４０４の関係をみると、ボリューム４０３を正ボリュームとしたペアボリュームが形成され、ボリューム４０３から４０４へのリモートコピー４１３が行われている。これは、ペアボリューム情報テーブル２２３（図４の最上段のレコード参照）に示された関係と同じである。
このように、３つのコピー４１１〜４１３によって、１つの抽象データパスが構成されている。
なお、本実施の形態において、ペアボリュームを構成する正ボリュームと副ボリュームとの間のある位置からみて、正ボリューム側を上流と称したり、副ボリューム側を下流と称したりもする。

[データパスのマッピング例]
次に、図１２に示した抽象データパスに対応するデータパスのマッピング例について説明する。なお、データパスとは、抽象データパスに対して、実際に複製元ボリュームから複製先ボリュームへの複製に必要なデータを中継する装置（コントロールユニットなど）をマッピングした集合を指す。
図１３はデータパスのマッピング例を示す概念図である。
図１３に示すボリューム５０１〜５０４の各々は、図１２のボリューム４０１〜４０４に対応している。そして、ボリューム５０１とボリューム５０２との間には、ボリューム５０１からボリューム５０２へのリモートコピーが行われる場合のデータの中継順序と同様の配列にコントロールユニット５７１（「CU」表記、図１のコントロールユニット７１に相当）などがマッピングにより示されている。

具体的には、ボリューム５０１とボリューム５０２との間には、ボリューム５０１側からみて順次、コントロールユニット５７１、ポート５８１（「Port」表記、図１のポート８１に相当）、ＳＡＮ５２１（図１のＳＡＮ２１に相当）、変換装置５４１（「FC-IP」表記、図１の変換装置４１に相当）、ＩＰネットワーク５５１（「IP」表記、図１のIPネットワーク５１に相当）、変換装置５４２（「FC-IP」表記、図１の変換装置４２に相当）、ＳＡＮ５２２（図１のＳＡＮ２２に相当）、ポート５８２（「Port」表記、図１のポート８２に相当）、コントロールユニット５７２（「CU」表記、図１のコントロールユニット７２に相当）が示されている。

また、ボリューム５０２とボリューム５０３との間には、コントロールユニット５７３（「CU」表記、図１のコントロールユニット７３に相当）が示されている。

さらに、ボリューム５０３とボリューム５０４との間には、ボリューム５０３側からみて順次、コントロールユニット５７４（「CU」表記、図１のコントロールユニット７４に相当）、ポート５８３（「Port」表記、図１のポート８３に相当）、ＳＡＮ５２３（図１のＳＡＮ２２に相当）、変換装置５４３（「FC-IP」表記、図１の変換装置４３に相当）、ＩＰネットワーク５５１（「IP」表記、図１のIPネットワーク５２に相当）、変換装置５４４（「FC-IP」表記、図１の変換装置４４に相当）、ＳＡＮ５２４（図１のＳＡＮ２３に相当）、ポート５８４（「Port」表記、図１のポート８４に相当）、コントロールユニット５７５（「CU」表記、図１のコントロールユニット７５に相当）が示されている。

記号５９１は、障害を表すものであり、この記号５９１が、コントロールユニット５７４上に示されている。
また、障害の根本原因が存在する範囲５９２として、コントロールユニット５７４の下流にある装置（図１３のPort、SAN、FC-IP、IP、FC-IP、SAN、Port、CU、04）が示されている。
さらに、運用上問題が出る影響範囲５９３として、コントロールユニット５７４の上流にある装置（図１３の03、CU、02、CU、Port、SAN、FC-IP、IP、FC-IP、SAN、Port、CU、01）が示されている。
なお、図１３では、複数のサイト間で１つの経路（「０１」→「０２」→「０３」→「０４」）のみが存在する場合について説明したが、例えば、１つの経路（「０１」→「０２」→「０３」→「０４」）上で他のボリュームへの分岐経路（「０２」→他のボリューム）が存在する場合にも適用がある。

[データパス構成情報テーブルの構成例]
次に、図１３に示したデータパスのマッピング例を表すデータパス構成情報テーブル２８０の構成例について説明する。
図１４はデータパス構成情報テーブル２８０の構成例を示す図である。
データパス構成情報テーブル２８０は、装置情報と、上流装置情報と、障害イベントとの項目を含んで構成されている。
装置情報は、対象となる装置がどのサイトに存在するのかを表したものであり、装置種別と装置名と部品名とサイト名との項目を有している。装置種別、装置名および部品名の項目には、図５〜図７に示した装置種別、装置名および部品名の各値が示される。サイト名の項目には、当該装置の管理下にあるサイト先（東京、大阪、福岡）が示される。
上流装置情報は、装置情報の装置名（または部品名）で指定された装置（または部品）の上流に位置付けられる装置（または部品）を表すものであり、装置種別と装置名と部品名とサイト名との項目（装置情報の項目と同様の内容）を有している。
障害イベントには、障害イベントログ情報テーブル２６１〜２６３（図８〜図１０参照）の障害イベントで指定された内容が示される。この障害イベントで指定された内容は、管理者等のユーザにとって、障害の根本原因を特定する際の判断材料となりうる。

このデータパス構成情報テーブル２８０は、マルチサイト管理システム１のデータパス構築プログラム１１２の機能により作成される。データパス構築プログラム１１２は、ストレージ管理システム２〜４からの障害イベント通知メッセージを受信した場合、ストレージ管理システム２〜４のＤＢ上の各テーブル（図２〜図４のペアボリューム情報テーブル２２１〜２２３、図５〜図７のSAN構成情報テーブル２４１〜２４３）の情報を選別したり収集したりすることで、データパス（中継経路）を構築する。

[障害特定プログラムの処理例]
次に、図１の障害特定プログラム１１１の処理例について説明するが、その前提として、まず障害の根本原因の特定に関する原理を説明する。
本実施の形態では、コピー/リモートコピーに関する障害があった場合、データパスの一番下流に近い障害がその障害の根本原因にあるとの前提で処理を行う。このため、まずは、当該障害に関連するデータパスを構築するために必要な情報を収集し、その情報から障害の根本原因を特定する。具体的には、コピー/リモートコピーに関して発生した障害にかかるペアボリュームに基づいて、そのボリュームに関連するペアボリュームを全て追跡する。そして、追跡により収集したペアボリュームから抽象データパスを構築する。
次に、構築した抽象データパスに対してストレージシステム内における装置（ポート、コントローラなど）の接続情報をマッピングすることでデータパスを構築する。すなわち、抽象データパス内で表されるペアボリューム間において、正ボリューム（コピー元）から副ボリューム（コピー先）へのコピー/リモートコピーに関するデータを中継した装置をその正ボリュームと副ボリュームの間に新しく追加する。
このようにして構築したデータパス上でコピー/リモートコピーに関する障害が発生した場合、データの流れは正ボリュームから副ボリュームへの一方向であるため、データパス上のデータの流れがどこかの装置で塞き止められていることになっている。そして、障害が発生した場合に他の装置へ波及する範囲は、データが上手く流れなくなったデータパスの上流部分になっている。したがって、このような特徴から、コピー/リモートコピーに関する障害の根本原因は発生した障害の下流にあり、コピー/リモートコピーに関する障害の影響範囲は発生した障害の上流にあることになる。

次に、図１の障害特定プログラム１１１の処理例について説明する。
図１５は障害特定プログラム１１１の処理例を示すフローチャートである。ここでは、例えば、大阪のサイト１２を管理するストレージ管理システム３の障害監視プログラム１０２が、障害イベントログ情報テーブル２６２（図９参照）の２行目にあるペアボリュームに関する障害（例えば、コントロールユニットでペアボリュームエラー）を検知した場合を前提に説明する。
この場合、ストレージ管理システム３では、障害監視プログラム１０２が、まず、ペアボリューム情報テーブル２２２（図３参照）から、障害イベントログ情報テーブル２６２（図９参照）の２行目に指定された項目（装置種別、装置名、部品名）２６４〜２６６の各値（CU、ST02、14）に対応する行に含まれる全項目の各項目２２４〜２３１の値を取り出す。
そして、障害監視プログラム１０２が、障害イベントログ情報テーブル２６２（図９参照）の２行目に指定された項目（装置種別、装置名）の各値２６４〜２６５（CU、ST02）と、前記取り出したペアボリューム情報テーブル２２２（図３参照）の全項目の各値２２４〜２３１とを含む障害イベント通知メッセージをマルチサイト管理システム１に送信する。これにより、マルチサイト管理システム１では、障害特定プログラム１１１により図１５のステップ６０１以降の処理が行われる。

ステップ６０１では、マルチサイト管理システム１は、例えば、ストレージ管理システム３の障害監視プログラム１０２からの障害イベント通知メッセージを受信する。これにより、障害特定プログラム１１１の実行が開始され、障害特定プログラム１１１は、受信した障害イベント通知メッセージから、ボリュームの情報を抽出する（ステップ６０２）。具体的には、ステップ６０２では、障害特定プログラム１１１は、障害イベント通知メッセージ中の各値２２４〜２３１の中から、正ボリュームであるボリューム６３（障害が発生したペアボリュームのもの）に関する値２２４〜２２５（図３の正ボリュームの装置名、Vol部品名の値）を取り出す。

ステップ６０３では、障害特定プログラム１１１は、データパス構築プログラム１１２に障害イベント通知メッセージの中から抽出したボリューム６３の情報（値２２４〜２２５）を渡し、データパスの構築を依頼する。
この依頼により、ボリューム６３の情報２２４〜２２５を受け取ったデータパス構築プログラム１１２は、ボリューム６３の情報２２４〜２２５に基づいて、データパスを構築し、構築したデータパスの構成情報をデータパス構成情報テーブル２８０として、障害特定プログラム１１１に返す。

ステップ６０４では、障害特定プログラム１１１は、データパス構築プログラム１１２からデータパスの構成情報を受け取ると、障害イベント通知メッセージに含まれていた障害を検知した装置を調査対象装置とする。本実施の形態では、障害イベント通知メッセージには、障害を検知した装置を表す値２６４〜２６６（図９の障害イベントログ情報テーブルの装置種別、装置名、部品名）が含まれている。このため、この値２６４で指定されたコントロールユニット７４が、調査対象装置になる。

ステップ６０５では、障害特定プログラム１１１は、調査対象装置を管理するストレージ管理システムに装置障害確認メッセージを送信する。
本実施の形態では、調査対象装置はコントロールユニット７４であり、このコントロールユニット７４を管理するストレージ管理システムはストレージ管理システム３（障害イベント通知メッセージ中の項目２６５で指定されたもの）である。装置障害確認メッセージには、データパス構成情報テーブル２８９（図１７参照）の項目２８１〜２８３（装置種別、装置名、部品名）の各値を含んで構成されている。

障害特定プログラム１１１からの送信を受け、ストレージ管理システム３（確認先ストレージ管理システムともいう）は、障害イベントログ情報テーブル２６２（図９参照）を検索する。その検索の結果、受信した装置障害確認メッセージ中の各値２８１〜２８３で指定された装置種別、装置名および部品名に関する障害イベントログが存在する場合は、その障害イベントログに示された障害イベントのデータ内容２６７（図９のペアボリュームエラー、ST02-03→ST03-04参照）を装置障害報告メッセージに含めて、マルチサイト管理システム１に送信する。
他方、障害イベントログが存在しない場合は、「無」の値を装置障害報告メッセージに含めて、マルチサイト管理システム１に送信する。

ステップ６０６では、ストレージ管理システム３からの送信を受け、マルチサイト管理システム１は、確認先ストレージ管理システムとしてのストレージ管理システム３から返信された装置障害報告メッセージによりデータパス情報テーブル２８９（図１７参照）の障害イベントを更新する。この更新では、例えば、受信した装置障害報告メッセージに含まれる値（例えば「無」）をデータパス情報テーブル２８９の障害イベントの値２８８として格納する。

ステップ６０６の終了後、ステップ６０７では、データパス構成情報テーブル２８０（図１４参照）で表されるデータパス（図１３参照）の下流にある装置を全部調査済かどうかの判断を行う。具体的には、この判断では、データパス構成情報テーブル２８０（図１７参照）の上流装置情報の項目（装置種別、装置名、部品名）の各値２８５〜２８７を辿り、ステップ６０１で受信した障害イベント通知メッセージ中の値２６４で指定されたコントロールユニット７４（障害を検知した装置）に到達できる装置（当該装置の下流に位置づけられるもの、図１３参照）がないか確認する。

確認の結果、例えば、そのような装置が存在する場合（ステップ６０７のＮｏ）、その装置（未調査の装置）を調査対象装置とし（ステップ６０８）、ステップ６０５に戻って、ステップ６０５以降の処理を行う。他方、そのような装置が存在しない場合（ステップ６０７のＹｅｓ）、当該データパス内で一番下流にある障害イベント（最上流の装置から辿る回数がもっとも多い装置で発生した図１４の障害イベント）を探し出し、それを根本原因として特定する（ステップ６０９）。
ステップ６１０では、特定した根本原因とその影響範囲とを特定して、例えばコンピュータの表示装置に表示する。この表示例は後記図１８で詳述する。
ステップ６１１では、ステップ６１０において特定した障害の影響範囲内のストレージ管理システム２〜４に障害警告メッセージを送信し、ステップ６１２に進んで、次の障害イベントの待ち受け状態（待機状態）に移行する。なお、ステップ６１１において送信された障害警告メッセージを受信したストレージ管理システム２〜４は、その障害警告メッセージに含まれるデータパス構成情報テーブル２８０をＤＢに格納する。

[データパス構築プログラムの処理例]
次に、図１５のステップ６０３で渡されたボリュームの情報（図３の装置名およびVol部品名の値２２４〜２２５）を受け取るデータパス構築プログラム１１２（図１参照）の処理例について説明する。
図１６はデータパス構築プログラム１１２の処理例を示すフローチャートである。
ステップ６３１では、データパス構築プログラム１１２は、図１５のステップ６０３で渡されたボリュームの情報（図３の装置名およびVol部品名の値２２４〜２２５）を受け取り、抽象データパスの構築を開始する。
ステップ６３２では、受け取った情報で指定されたボリュームを調査対象ボリュームとする。
具体的には、受け取った情報（図３の装置名およびVol部品名の値２２４〜２２５）を新規に作成したデータパス構成情報テーブル２８０（図１４参照）の装置種別、装置名および部品名の項目（列）２８１〜２８３に書き込む。また、データパス構成情報テーブル２８０（図１４参照）の装置種別、装置名および部品名の項目（列）２８５〜２８７の全てに「-」の値を書き込む。そして、このようにして書き込んだデータパス構成情報テーブル２８０（図１４参照）の１行目で指定されたボリュームを調査対象ボリュームとする。なお、装置種別、装置名および部品名の項目（列）２８５〜２８７（図１４参照）の全ての値が「-」の場合、データパス構成情報テーブル２８０で表されるデータパスの最上流であることを示す。

ステップ６３３では、調査対象ボリュームを持つ調査対象サイトを検索する。具体的には、データパス構成情報テーブル２８０（図１４参照）の装置情報から、装置名２８２で指定された装置が存在するサイト名３０３（図１１のサイト情報テーブル３００参照）で指定されたサイトを調べる。そして、調べたサイトが例えば「大阪」であれば、データパス構成情報テーブル２８０（図１４参照）の１行目のサイト名２８４に「大阪」と書き込む。

ステップ６３４では、調査対象サイトのストレージ管理システムにペアボリューム構成要求メッセージを送信する。具体的には、例えば、マルチサイト管理システム１は、ステップ６３３において書き込んだ１行目のサイト名２８４（図１４参照）のサイト（例えば、大阪）を管理するストレージ管理システム３に対して、データパス構成情報テーブル２８０（図１４参照）の１行目の装置名２８２と部品名２８３との各値を含んで構成されるペアボリューム構成要求メッセージを送信する。
その要求メッセージの送信を受け、ストレージ管理システム３は、例えば、部品名２８３で指定された値を表すボリューム６３（図１参照）とペアボリュームとなっている全てのボリューム（正ボリュームと副ボリューム）の位置を特定する情報（図３の正ボリュームの項目２２４〜２２５・副ボリュームの項目２２８〜２２９）をペアボリューム情報テーブル２２２（図３参照）から検索する。
ストレージ管理システム３は、前記検索されたボリューム６３の全ペアボリュームの位置を特定する情報（図３のペアボリューム情報テーブル２２２の２行目の正ボリュームの項目２２４〜２２５・図３のペアボリューム情報テーブル２２２の３行目の副ボリュームの項目２２８〜２２９の各値）をペアボリューム構成情報メッセージとして、マルチサイト管理システム１に送信する。

ストレージ管理システム３からペアボリューム構成情報メッセージを受信したマルチサイト管理システム１は、当該ペアボリューム構成情報メッセージより、抽象データパスを構築する（ステップ６３５）。具体的には、ボリューム６３の正ボリュームであるボリューム６２の情報（図３の正ボリュームの項目２２４〜２２５の各値）について、データパス構成情報テーブル２８０（図１４参照）において重複がないか調べる。その結果、重複がなければ、ボリューム６２の情報（図３の正ボリュームの項目２２４〜２２５の各値）と、当該ボリュームのサイト名とをデータパス構成情報テーブル２８０の２行目の項目２８１〜２８３に書き込む。
また、その２行目の項目２８５〜２８７には、ボリューム６２の副ボリュームである１行目の項目２８５〜２８７の値を書き込み、また、１行目の項目２８５〜２８７には、正ボリュームであるボリューム６２の２行目の項目２８１〜２８３の値を書き込む。
他方、重複があれば、ボリューム６２の情報（図３の正ボリュームの項目２２４〜２２５の各値）を書き込まない。
そして、ボリューム６３の副ボリュームであるボリューム６４の情報（図４の正ボリュームの項目２２４〜２２５の各値）について、データパス構成情報テーブル２８０において重複がないか調べる。その結果、重複がなければ、ボリューム６４の情報（図３の正ボリュームの項目２２４〜２２５の各値）と、当該ボリュームのサイト名とをデータパス構成情報テーブル２８０の３行目の項目２８１〜２８３に書き込む。また、３行目の項目２８５〜２８７には、１行目の項目２８１〜２８３の値を書き込む。他方、もし重複があれば、ボリューム６４の情報は一切書き込まない。以上より、データパス構成情報テーブル２８０の１行目のボリューム６３に関する調査が終了する。

ステップ６３５の後、ステップ６３６では、データパス構成情報テーブル２８０に示された全ボリュームを調査完了済かどうかの判断を行う。この判断では、次の調査対象となる行があるかどうかを調べる。
そして、次行に調査対象となるデータが存在する場合は（ステップ６３６のＮｏ）、その行を調査対象とし（ステップ６３７）、ステップ６３３に戻る。
他方、次行に調査対象となるデータが存在しない場合は（ステップ６３６のＹｅｓ）、全ての抽象データパスを構築できたことになるため、抽象データパスの構築を終了しデータパス構築を開始する（ステップ６６１）。このときのデータパス構成情報テーブルは、図１７に示したテーブル２８９の構成となる。

図１６に戻って、ステップ６６２では、構築を終了した抽象データパスの最上流ペアボリュームを調査対象ペアボリュームとする。具体的には、データパス構成情報テーブル２８９（図１７参照）から、抽象データパスの最上流である項目２８５〜２８７の値が全て「-」の行に示された項目２８１のボリュームを検索し、調査対象ペアボリュームを決定する。

ステップ６６３では、マルチサイト管理システム１は、調査対象ペアボリュームにおける正ボリュームの項目２８４のサイト（例えば、東京）１１を管理するストレージ管理システム２に対して、正ボリューム６１と副ボリューム６２の項目２８１〜２８２の各値を含んで構成されたペアボリュームパス要求メッセージを送信する。
その要求メッセージの送信を受け、ストレージ管理システム２は、ペアボリューム情報テーブル２２１（図２参照）やSAN構成情報テーブル２４１（図５参照）を用いて、受信したペアボリュームパス要求メッセージに含まれる各値の正ボリュームから副ボリュームに届く複製データを中継した装置の経路（パス）を追跡させる。そして、ストレージ管理システム２は、前記追跡した結果（図２のペアボリューム情報テーブル２２１の１行目の項目２２４〜２３１の各値、図５のSAN構成情報テーブル２４１の変換装置（複製データの中継経路となるもの）の装置名２４５の値）をペアボリュームパス情報メッセージに含めて、マルチサイト管理システム１に送信する。

ステップ６６４では、ペアボリュームパス情報メッセージを受信したマルチサイト管理システム１は、要求先ストレージ管理システムから返信されたペアボリュームパス情報メッセージよりデータパスを構築する。具体的には、マルチサイト管理システム１は、ペアボリュームパス情報メッセージから、正ボリューム６１および副ボリューム６２のペアボリュームを制御する２台のコントロールユニット７１、７２と、２つのポート８１、８２との情報（図２のペアボリューム情報テーブル２２１の１行目の項目２２４〜２３１の各値）を取得する。そして、それらの情報をデータパス構成情報テーブル２８０の５行目（コントロールユニット７１に関するもの）、６行目（ポート８１に関するもの）、７行目（ポート８２に関するもの）および８行目（コントロールユニット７２に関するもの）の装置種別２８１、装置名２８２および部品名２８３に書き込む。
データパス構成情報テーブル２８０の５行目（コントロールユニット７１に関するもの）は、装置名２８２の「ST01」の値をキーとして、サイト情報テーブル３００（図１１参照）が検索される。そして、そのキーに対応するサイト名２８５に例えば「東京」と書き込まれる。また、５行目の項目２８５〜２８７（図１４の上流装置情報の装置種別、装置名、部品名）に、４行目の項目２８１〜２８３（図１４の装置情報の装置種別、装置名、部品名）の値が書き込まれる。

同様に、データパス構成情報テーブル２８０の６行目、７行目および８行目においても、項目２８４〜２８７（図１４のサイト名、上流装置情報の装置種別、装置名、部品名）に各値を書き込む。最後に、副ボリュームであるデータパス構成情報テーブル２８０（図１４参照）の２行目（ボリューム６２に関するもの）において、項目２８５〜２８７の値を８行目（コントロールユニット７２に関するもの）の項目２８１〜２８３の値に書き換える。

次に、マルチサイト管理システム１は、ポート８１とポート８２との間に存在する装置の情報に関する処理を行う。具体的には、マルチサイト管理システム１は、受信したペアボリュームパス情報メッセージを基に、２台の変換装置４１、４２に関する情報をデータパス構成情報テーブル２８０の９行目（変換装置４１に関するもの）と１０行目（変換装置４２に関するもの）の項目２８１〜２８７に書き込む。最後に、７行目（ポート８２に関するもの）の項目２８５〜２８７の値を１０行目（変換装置４２に関するもの）の項目２８１〜２８３の値に書き換える。

ステップ６６５では、データパス上における全ペアボリュームの経路の調査が完了済かどうかの判断を行う。この判断では、データパス構成情報テーブル２８９（図１７参照）の２つの項目２８１、２８５の各値が共に「ボリューム」である行がないかどうかで確認する。
確認の結果、２つの項目２８１、２８５の各値が共に「ボリューム」である行があれば、調査が未完了と判断し（ステップ６６５のＮｏ）、当該行に示されたボリュームのペアボリュームを調査対象とし（ステップ６６６）、ステップ６６３に戻ってステップ処理を行う。他方、調査完了済と判断すれば（ステップ６６５のＹｅｓ）、ステップ６６７に進んでデータパスの構築を終了する（ステップ６６７）。終了後、マルチサイト管理システム１のＣＰＵ１１１Ａは、構築したデータパスを表す中継経路を管理者用端末１１５に表示させる。この表示画面は、図１３のような中継経路を表示することとなる。これにより、ユーザは、コピー障害に対する適切な対処を行いやすくなる。

なお、ポート８１からポート８２を経由した装置の経路（パス）を追跡する方法として、例えば次のような方法がある。すなわち、まず、SANのトポロジ（ポートを含むネットワーク接続形態）を管理する機能を持つスイッチ（図示省略）に対して、ポート８１からポート８２までの中継経路を問い合わせる。そして、その問い合わせに対する応答をスイッチから受信し、その応答から、その中継経路上の２台の変換装置４１、４２の情報を抽出して、データパス構成情報テーブル２８８に書き込む方法である。
もっとも、データの冗長性を高めるため、複数の経路（変換装置の組み合わせ）が存在する場合があるので、その場合は、その経路の終端となるポート８２のレコードをその経路の数だけ複製する。そして、そのポート８２の上流に位置づけられた装置を特定するための項目２８５〜２８７（図１７の上流装置情報の装置種別、装置名、部品名）に、それぞれの経路の上流を示す値を書き換える。これにより、複数の経路を表すことが可能となる。
なお、ＩＰネットワークなどの公衆回線網がリモートコピーに利用される場合、ストレージ管理システムではその公衆回線網を用いて中継経路の管理を行うことができないため、経路の追跡を行わない。

[障害特定表示の具体例]
次に、図１５のステップ６１０での表示例を図１８に示す。この表示例では、マルチサイト管理システム１のＧＵＩ１１４により出力されたウィンドウ７００を用いて示している。
図１８に示すように、ウィンドウ７００には、検知障害、障害特定および影響範囲特定の表示項目７１０、７１１、７１２がある。そして、検知障害の表示項目７１０は、装置種別、装置名、部品名、サイト名および障害イベントの各項目を含んでいる。障害特定の表示項目７１１は、装置種別、装置名、部品名、サイト名および障害イベントの各項目を含んでいる。また、影響範囲特定の表示項目７１２は、装置種別、装置名、部品名、サイト名および障害イベントの各項目を含んでいる。ボタン７９９は、ＧＵＩ１１４による表示の終了を指示するためのものである。
このようなウィンドウ７００をみたユーザは、例えば、検知障害の表示項目７１０等から、大阪サイトのコントロールユニットでペアボリュームエラーが検知されたこと等を確認することが可能となる。

なお、検知障害の表示項目７１０の情報７２１〜７２５は、ステップ６０１（図１５参照）において受信された障害イベント通知メッセージ中の各値２２４〜２３１（図２〜図４参照）に対応する各値をデータパス構成情報テーブル２８０から検索されて表示される。
障害特定の表示項目７１１の情報７３１〜７３５は、ステップ６１０（図１５参照）において特定された障害の根本原因にかかる装置の情報と、その直近の上下流に位置する装置の情報とからなり、これらの情報は、データパス構成情報テーブル２８０から抽出されて表示される。なお、仮に冗長化された経路が存在し、上流もしくは下流の装置が複数ある場合は、それらの装置の情報は全てデータパス構成情報テーブル２８０から抽出されて表示される。
影響範囲特定の表示項目７１２の情報７４１〜７４５は、ステップ６１０において特定した障害範囲にある装置の情報である。

[ストレージ管理システムでの障害監視プログラムの処理例]
次に、ストレージ管理システム２〜４での障害監視プログラム１０２の処理例について説明する。
図１９は障害監視プログラム１０２の処理例を示すフローチャートである。ここでは、ストレージ管理システム２を例にして説明するが、他のストレージ管理システム３、４も同様の処理を行う。
ストレージ管理システム２の障害監視プログラム１０２は、一定時間経過したとき、もしくはＳＮＭＰにより障害を検知したときに（ステップ６８０）、ステップ６８１に進む。
ステップ６８１では、障害監視プログラム１０２がロードされているストレージ管理システム２の障害イベントログ情報テーブル２６１（図８参照）より、未報告のペアボリューム障害を検索する。そして、検索の結果、未報告障害が存在するかの判断を行う（ステップ６８２）。具体的には、障害イベントログ情報テーブル２６１（図８参照）の報告済フラグに示された「○」（○は報告済を表す）以外の行に障害イベント（ペアボリュームに関するもの）があるかどうかの判断を行う。

そして、ステップ６８２において未報告障害が存在しない場合（ステップ６８２のＮｏ）、障害監視プログラム１０２は、待機状態に移行する(ステップ６８３)。他方、ステップ６８２において未報告障害が存在する場合（ステップ６８２のＹｅｓ）、障害監視プログラム１０２は、当該未報告障害としての障害イベント（図８の障害イベントログ情報テーブルの障害イベント）を検知障害イベントとし、その検知障害イベントより、ペアボリューム情報テーブル２２１（図２参照）から、検知障害イベントに関するペアボリューム情報（図２の項目２２４〜２３１の各値）を取得する（ステップ６８４）。

ステップ６８５では、取得したペアボリューム情報と、前記障害警告メッセージ内のデータパス情報とを比較する。比較の結果、データパスの一部と一致するかどうかの判断を行う（ステップ６８６）。具体的には、障害監視プログラム１０２をロードしたストレージ管理システム２が、受信した障害警告メッセージ中のデータパス構成情報テーブル２８０を検索し、ステップ６８４で取得した検知障害イベントのペアボリュームの情報（図２の項目２２４〜２３１の各値）を全て含むデータパス構成情報テーブル２８０が存在するかの検索を行う。

そして、ステップ６８６における比較の結果、該当するデータパス構成情報テーブル２８０が存在しない場合（ステップ６８６のＮｏ）、マルチサイト管理システム１に障害イベント通知メッセージを送信する（ステップ６８７）。具体的には、ステップ６８７では、マルチサイト管理システム１に対して、検知障害イベントが発生した装置の情報（図８の項目２６４〜２６６の各値）と、ペアボリュームの情報（図２の項目２２４〜２３１）とを含む障害イベント通知メッセージを送信する。

次に、障害イベントログ情報テーブル２６１における検知障害イベントの報告済みフラグを更新し（ステップ６８８）、待機状態に移行する（ステップ６８３）。具体的には、ステップ６８８では、障害イベントログ情報テーブル２６１（図８参照）の報告済フラグに「○」（報告済を表す）の値を書き込む。

他方、ステップ６８６において、該当するデータパス構成情報テーブル２８０（図１４参照）が存在する場合（ステップ６８６のＹｅｓ）、ストレージ管理システム２のＧＵＩ１０４で、ウィンドウ７００（図１７参照）をコンピュータの表示装置に表示し（ステップ６８９）、ステップ６８７以降の処理を実行する。

[実施の形態２]
実施の形態２では、実施の形態１において用いられていた障害イベントに代えて、性能異常イベントを用いる点に主要な特徴がある。性能異常イベントとは、入出力データの転送量などの性能指標を監視する装置（コントローラ、ポート、キャッシュ、メモリなど）において、あらかじめ設定されていた性能指標の閾値を超過した場合に通知されるものである。性能指標としては、入出力データの転送量のほか、通信帯域やキャッシュ残り容量などがある。もっとも、装置の性能指標は、当該装置が監視してもよいし、専用の監視装置あるいはストレージ管理システム２〜４が一括して監視してもよい。

図２０は本発明の実施の形態２におけるシステム全体の構成例を示すブロック図である。なお、実施の形態１と同一の部分は同一の符号を付して重複説明を省略する。
図２０において、マルチサイト管理システム１では、実施の形態１における障害特定プログラム１１１（図１参照）に代えて、性能異常特定プログラム１１６がメモリ１１１Ｂにロードされている。また、ストレージ管理システム２では、実施の形態１における障害監視プログラム１０２（図１参照）に代えて、性能異常監視プログラム１０５がメモリ１０１Ｂにロードされている（ストレージ管理システム３、４も同様）。
そして、ストレージ管理システム２のＤＢには、図２１に示す性能異常イベントログ情報テーブル２６９が管理されている。この性能異常イベントログ情報テーブル２６９は、障害イベントログ情報テーブル２６１〜２６３（図８〜図１０参照）の障害イベントの項目２６７に代えて、図２１に示す性能異常イベントの項目２７０にした点が、障害イベントログ情報テーブル２６１〜２６３（図８〜図１０参照）と異なる。この性能異常イベントログ情報テーブル２６９の値は、ストレージ管理システム２〜４のSAN情報収集プログラム１０１がSNMPなどにより性能異常の通知を受信した場合などに各装置から性能異常イベントの情報を収集して更新される。
性能異常特定プログラム１１６は、図２２に示すデータパス構成情報テーブル２９１を作成してＤＢ１０３に格納する。データパス構成情報テーブル２９１も、図１４のデータパス構成情報テーブル２８０の障害イベントの項目２８８に代えて、性能異常イベントの項目２９２にした点が、データパス構成情報テーブル２８０（図１４参照）と異なる。その他の構成は、実施の形態１の場合とほぼ同様である。

次に、図２０の性能異常特定プログラム１１６の処理例について説明する（適宜図１等参照）。なお、この処理例は、障害イベントに代えて性能異常イベントを用いる点を除けば、図１５のステップ６０１〜６１２の処理例とほぼ同様である。
図２３は性能異常特定プログラム１１６の処理例を示すフローチャートである。ここでは、例えば、ストレージ管理システム３（大阪のサイトを管理）の性能監視異常監視プログラム１０５が、性能異常イベントログ情報テーブル２６９の１行目の性能異常イベントを検知し、マルチサイト管理システム１に対して性能異常通知メッセージを送信した場合を前提に説明する。なお、性能異常イベント通知メッセージは、性能異常イベントログ情報テーブル２６９（図２１参照）の項目２７０の性能異常イベントを含む以外は、実施の形態１における障害イベント通知メッセージと同じ構造である。

この場合、マルチサイト管理システム１は、ストレージ管理システム３の性能異常監視プログラム１０５からの性能異常イベント通知メッセージを受信し（ステップ８２１）、性能異常特定プログラム１１６（図２０参照）の実行を開始し、ステップ８２２以降の処理を行う。
ステップ８２２では、受信した性能異常イベント通知メッセージから、ボリュームの情報を抽出する。具体的には、性能異常イベント通知メッセージに含まれているペアボリュームに関する情報（図３の項目２２４〜２３１の値）から、性能異常が発生したペアボリュームの正ボリュームであるボリューム６３の情報（図３の項目２２４〜２２５の値）を取り出す。

ステップ８２３では、データパス構築プログラム１１２（図２０参照）に、抽出したボリュームの情報を渡し、データパス構築の処理を行う。具体的には、性能異常特定プログラム１１６は、データパス構築プログラム１１２に性能異常イベント通知メッセージから抽出したボリューム６３の情報（図３の項目２２４〜２２５の値）を渡して、データパスの構築を依頼する。具体的には、ステップ８２３では、ボリューム６３の情報（図３の項目２２４〜２２５の値）を受け取ったデータパス構築プログラム１１２は、ボリューム６３の情報（図３の項目２２４〜２２５の値）に基づいて、データパスを構築し、構築したデータパスの構成情報をデータパス構成情報テーブル２９１として、性能異常特定プログラム１１６（図２０参照）に返す。

ステップ８２４では、性能異常イベント通知メッセージから、性能異常イベントに示された装置を調査対象装置とする。具体的には、性能異常特定プログラム１１６は、データパス構築プログラム１１２からデータパス構成情報テーブルを受け取ると、性能異常イベント通知メッセージに含まれていた性能異常イベントに示された装置を調査対象装置とする。

ステップ８２５では、調査対象装置を管理するストレージ管理システムに装置性能異常確認メッセージを送信する。具体的には、マルチサイト管理システム１は、調査対象装置であるボリュームのサイト１１〜１３を管理するストレージ管理システム２〜４に対して、図１４の装置種別、装置名および部品名の項目２８１〜２８３の各値で構成された装置性能異常確認メッセージを送信する。
なお、マルチサイト管理システム１から装置性能異常確認メッセージを受信したストレージ管理システム２〜４は、装置性能異常確認メッセージより、性能異常イベントログ情報テーブル２６９（図２１参照）を検索する。検索の結果、ストレージ管理システム２〜４は、性能異常イベントログ情報テーブル２６９（図２１参照）の項目２７０に性能異常イベントログが存在する場合は、その性能異常イベントを装置性能異常報告メッセージに含め、他方、性能異常イベントログが存在しない場合は、「無」の値を装置性能異常報告メッセージに含めて、マルチサイト管理システム１に送信する。

ステップ８２６では、確認先ストレージ管理システムとしてのストレージ管理システム２〜４から返信された装置性能異常報告メッセージよりデータパス構成情報テーブル２９１（図２２参照）の項目（障害イベント）２８８の値を更新する。具体的には、ストレージ管理システム２〜４からの装置性能異常報告メッセージを受信したマルチサイト管理システム１は、装置性能異常報告メッセージから、データパス構成情報テーブル２９１の項目２９２の性能異常イベントにその性能異常イベント（図２１の項目２７０の値）を格納する。

ステップ８２６を完了した直後、上流の装置を辿ることで性能異常イベント通知メッセージに含まれていた性能異常イベントを検知した装置に到達できる装置がないか確認する（ステップ８２７）。そして、そのような装置が存在する場合は（ステップ８２７のＮｏ）、その装置を調査対象装置とし（ステップ８２８）、ステップ８２５に戻ってステップ処理を行う。
他方、ステップ８２７において、そのような装置が存在しない場合は（ステップ８２７のＹｅｓ）、データパス内で一番下流にある性能異常イベントを探し出し、それを根本原因として特定する（ステップ８２９）。具体的には、ステップ８２９では、収集した性能異常イベントの中で、データパスのもっとも下流にある（最上流の装置から辿る回数がもっとも多い）装置で発生した性能異常イベント（図２２の項目２９２の値）を検索する。

ステップ８３０では、根本原因とその影響範囲を特定し、表示する。具体的には、該当した性能異常イベント（図２２の項目２９２の値）を根本原因として特定し、さらに性能異常イベント通知メッセージに含まれていた装置より上流にあるデータパスを性能異常の影響範囲として特定し、例えばコンピュータの表示装置に表示する。
ステップ８３１では、影響範囲内のストレージ管理システムに性能異常警告メッセージを送信し、ステップ８３２に進んで、次の性能異常イベントの待ち受け状態（待機状態）に移行する（ステップ８３２）。具体的には、ステップ８３０で特定した性能異常の影響範囲にある装置のサイト（図２２の項目２８４の値）を管理するストレージ管理システム２〜４に対して、データパス構成情報テーブル２９１（図２２参照）によって構成される性能異常警告メッセージを送信する。

ここで、ステップ８３０においてＧＵＩ１１４に出力されるウィンドウ７０１の表示例を図２４に示す。この表示例では、検知性能異常の表示項目７１３と、性能異常特定の表示項目７１４と、影響範囲特定の表示項目７１５とを含んでいる。これらの表示項目７１３〜７１５では、性能異常イベントの内容が表示される点が、図１８の場合と異なる。

なお、検知性能異常の表示項目７１３（情報７２１〜７２４、７２６）では、図２３のステップ８２１において受信した性能異常イベントに関する情報（図２２の項目２８１〜２８４、２９２の各値に対応）を表示する。なお、仮に冗長化された経路が存在し、上流もしくは下流の装置が複数ある場合は、それらの装置の情報は全てデータパス構成情報テーブル２９１（図２２参照）から抽出されて表示される。
性能異常特定の表示項目７１４（情報７３１〜７３４、７３６）では、図２３のステップ８３０において性能異常を特定した装置の情報とその直近の上下流の装置の情報とが表示される。
影響範囲特定の表示項目７１５（情報７４１〜７４４、７４６）では、ステップ６１０において特定した障害範囲にある装置の情報である。

図２３のステップ８３１において、マルチサイト管理システム１からの性能異常警告メッセージを受信したストレージ管理システム２〜４は、性能異常警告メッセージに含まれるデータパス構成情報テーブル２９１（図２２参照）をＤＢに格納する。

次に、ストレージ管理システム２〜４での性能異常監視プログラム１０５の処理例について説明する。なお、この処理例は、障害イベントに代えて性能異常イベントを用いる点を除けば、図１９のステップ６８０〜６８９の処理例とほぼ同様である。
図２５は性能異常監視プログラム１０５の処理例を示すフローチャートである。ここでは、ストレージ管理システム２を例にして説明するが、他のストレージ管理システム３、４も同様の処理を行う。
ストレージ管理システム２の性能異常監視プログラム１０５は、一定時間経過したとき、もしくはＳＮＭＰにより障害を検知したときに（ステップ８００）、ステップ８０１に進む。
ステップ８０１では、性能異常監視プログラム１０５がロードされているストレージ管理システム２の性能異常イベントログ情報テーブル２６９（図２１参照）より、未報告のペアボリューム性能異常を検索する。そして、検索の結果、未報告性能異常が存在するかの判断を行う（ステップ８０２）。具体的には、性能異常イベントログ情報テーブル２６９（図２１参照）の報告済フラグに示された「○」（○は報告済を表す）以外の行の性能異常イベント（ペアボリュームに関するもの）があるかどうかの判断を行う。

そして、ステップ８０２において未報告性能異常が存在しない場合（ステップ８０２のＮｏ）、性能異常監視プログラム１０５は、待機状態に移行する(ステップ８０３)。他方、ステップ８０２において未報告性能異常が存在する場合（ステップ８０２のＹｅｓ）、性能異常監視プログラム１０５は、当該未報告性能異常としての性能異常イベント（図２２の性能異常イベントログ情報テーブルの性能異常イベント）を検知性能異常イベントとし、その検知性能異常イベントより、ペアボリューム情報テーブル２２１（図２参照）から、検知性能異常イベントに関するペアボリューム情報（図２の項目２２４〜２３１の各値）を取得する（ステップ８０４）。

ステップ８０５では、取得したペアボリューム情報と、前記性能異常警告メッセージ内のデータパス情報とを比較する。比較の結果、データパスの一部と一致するかどうかの判断を行う（ステップ８０６）。具体的には、性能異常監視プログラム１０５をロードしたストレージ管理システム２が、受信した性能異常警告メッセージ中のデータパス構成情報テーブル２９１を検索し、ステップ８０４で取得した検知性能異常イベントのペアボリュームの情報（図２の項目２２４〜２３１の各値）を全て含むデータパス構成情報テーブル２９１が存在するかの検索を行う。

そして、ステップ８０６における比較の結果、該当するデータパス構成情報テーブル２９１が存在しない場合（ステップ８０６のＮｏ）、マルチサイト管理システム１に性能異常イベント通知メッセージを送信する（ステップ８０７）。具体的には、ステップ８０７では、マルチサイト管理システム１に対して、検知性能異常イベントが発生した装置の情報（図２１の項目２６４〜２６６の各値）と、ペアボリュームの情報（図２の項目２２４〜２３１）とを含む性能異常イベント通知メッセージを送信する。

次に、性能異常イベントログ情報テーブル２６９における検知性能異常イベントの報告済みフラグを更新し（ステップ８０８）、待機状態に移行する（ステップ８０３）。具体的には、ステップ８０８では、性能異常イベントログ情報テーブル２６９（図２１参照）の報告済フラグに「○」（報告済を表す）の値を書き込む。

他方、ステップ８０６において、該当するデータパス構成情報テーブル２９１（図２２参照）が存在する場合（ステップ８０６のＹｅｓ）、ストレージ管理システム２のＧＵＩ１０４で、ウィンドウ７０１（図２４参照）をコンピュータの表示装置に表示し（ステップ８０９）、ステップ８０７以降の処理を実行する。

なお、本発明は、実施の形態１、２に限られない。たとえば、図１のコントロールユニット７１において、ペアボリューム書き込み失敗の障害が発生した場合、ストレージ管理システム２のSAN情報収集プログラム１０１により、障害イベントログ情報テーブル２６１に書き込まれる。その情報をストレージ管理システム２の障害監視プログラム１０２が検出すると、図１９の処理例のとおり、マルチサイト管理システム１に対して、発生した障害に関する障害イベント通知メッセージを送信する。
障害イベント通知メッセージを受信したマルチサイト管理システム１の障害特定プログラム１１１は、受信した障害イベント通知メッセージからボリュームに関する情報を抽出し、その情報をデータパス構築プログラム１１２に渡して、データパスを構築させる。その際のデータパスを構築するための情報は、データパス構成情報テーブル２８０と同様である。データパス構築プログラム１１２からデータパス構成情報テーブル２８０を受け取った障害特定プログラム１１１は、障害を検知したコントロールユニット７１よりデータパスの下流にある装置に対して、その装置を管理する各サイトのストレージ管理システム２〜４に対して装置障害確認メッセージを送信し、返信された装置障害報告メッセージの内容をデータパス構成情報テーブル２８０に反映させる。その結果、ステップ６０９においてボリューム６２においてボリュームが書き込みエラーであるという情報がデータパス上でもっとも下流にあることが判明したため、障害の根本原因をボリューム６２の書き込みエラーと特定し、影響範囲をストレージ装置３１と特定し、マルチサイト管理システム１において図１８の障害特定表示ウィンドウを用いて表示する。そして、データパス構成情報テーブル２８０を含んだ障害警告メッセージをストレージ管理システム２に送信する。

また、前記実施の形態において一例を記述する。図１のコントロールユニット７４において、リモートコピーの内部プログラムエラーが発生した場合、ストレージ管理システム４のSAN情報収集プログラム１０１により、障害イベントログ情報テーブル２６３に各値の情報が書き込まれる。その情報をストレージ管理システム４の障害監視プログラム１０２が検出すると、マルチサイト管理システム１に対して、発生した障害に関する障害イベント通知メッセージを送信する。前述の障害イベント通知メッセージを受信したマルチサイト管理システム１の障害特定プログラム１１１は、受信した障害イベント通知メッセージからボリュームに関する情報を抽出し、その情報をデータパス構築プログラム１１２に渡して、データパスを構築させる。その際のデータパスを構築するための情報は、データパス情報テーブル２８０と同様である。データパス構築プログラム１１２からデータパス情報テーブル２８０を受け取った障害特定プログラム１１１は、障害を検知したコントロールユニット７４よりデータパスの下流にある装置に対して、その装置を管理する各サイトのストレージ管理システム４に対して装置障害確認メッセージを送信し、返信された装置障害報告メッセージの内容をデータパス情報テーブル２８０に反映させる。その結果、図１５のステップ６０９においてコントロールユニット７４において内部プログラムエラーであるという情報がデータパス上でもっとも下流にあることが判明したため、障害の根本原因をコントロールユニット７４において内部プログラムエラーと特定し、影響範囲をストレージ装置３１〜３３、FC-IP変換装置４１〜４４と特定し、マルチサイト管理システム１において図１８の障害特定表示のウィンドウ７００を用いて表示する。そして、データパス情報テーブル２８０を含んだ障害警告メッセージをストレージ管理システム２〜４に送信する。

実施の形態１、２では、マルチサイト管理システム１は、１台の場合で説明したが、例えば、複数台で分散処理するようにしてもよい。また、ストレージ管理システム２〜４は、マルチサイト管理システム１とは独立のシステムとして設けているが、例えば、１台のマルチサイト管理システム１にそれらの機能を兼ね備えるようにしてもよい。さらに、ストレージ管理システム２〜４は、管理下のサイトごとに設けることとしたが、運用形態に応じ、１台のストレージ管理システムに集約してもよい。

本発明の実施の形態１におけるシステム全体の構成例を示すブロック図である。 ペアボリューム情報テーブル（東京）の構成例を示す図である。 ペアボリューム情報テーブル（大阪）の構成例を示す図である。 ペアボリューム情報テーブル（福岡）の構成例を示す図である。 SAN構成情報テーブル（東京）の構成例を示す図である。 SAN構成情報テーブル（大阪）の構成例を示す図である。 SAN構成情報テーブル（福岡）の構成例を示す図である。 障害イベントログ情報テーブル（東京）の構成例を示す図である。 障害イベントログ情報テーブル（大阪）の構成例を示す図である。 障害イベントログ情報テーブル（福岡）の構成例を示す図である。 サイト情報テーブルの構成例を示す図である。 抽象データパスの概念図である。 データパスのマッピング例を示す概念図である。 データパス構成情報テーブルの構成例を示す図である。 障害特定プログラムの処理例を示すフローチャートである。 データパス構築プログラムの処理例を示すフローチャートである。 図１６のステップ６６１でのデータパス構成情報テーブルの構成例を示す図である。 障害特定表示に関するウィンドウの表示例を示す図である。 障害監視プログラムの処理例を示すフローチャートである。 本発明の実施の形態２におけるシステム全体の構成例を示すブロック図である。 性能異常イベントログ情報テーブルの構成例を示す図である。 データパス構成情報テーブル（性能異常特定プログラム用）の構成例を示す図である。 性能異常特定プログラムの処理例を示すフローチャートである。 性能異常特定表示に関するウィンドウの表示例を示す図である。 性能異常監視プログラムの処理例を示すフローチャートである。

符号の説明

１ マルチサイト管理システム
２〜４ ストレージ管理システム
１１〜１３ サイト（東京11・大阪12・福岡13）
２１〜２３ SAN（ストレージ・エリア・ネットワーク）
３１〜３３ ストレージ装置
４１〜４４ FC-IP変換装置
５１〜５３ IPネットワーク
６１〜６４ ボリューム
７１〜７５ コントロールユニット
８１〜８４ ポート
１０１ SAN情報収集プログラム
１０１Ａ ＣＰＵ（処理部）
１０１Ｂ メモリ
１０１Ｃ ハードディスク装置
１０２ 障害監視プログラム
１０３ ＤＢ
１０４ ＧＵＩ
１１１ 障害特定プログラム
１１１Ａ ＣＰＵ（処理部）
１１１Ｂ メモリ
１１１Ｃ ハードディスク装置
１１２ データパス構築プログラム
１１３ ＤＢ
１１４ ＧＵＩ

Claims (4)

1. 複数のストレージ装置と、前記ストレージ装置の各々を管理する各管理サーバと、前記各管理サーバとの間で通信を行う計算機とを含んで構成されるコンピュータシステムを用いて、一または複数の前記ストレージ装置でのコピー障害が発生した際に、コピー障害に対する発生原因を特定するストレージ管理方法であって、
   前記管理サーバは、管理下の前記ストレージ装置の接続形態を表す接続情報と、当該ストレージ装置のボリュームとペアを組むペアボリュームに関するペアボリューム情報とを格納する記憶部を有し、
   前記計算機は、
   一または複数の前記管理サーバからストレージ装置でのコピーに関する障害イベントの通知メッセージを受けた場合、前記通知メッセージからボリューム情報を抽出し、前記ボリューム情報に基づいてデータパスを構築するとともに構築したデータパスの構成を示すデータパス構成情報を作成し、前記通知メッセージに含まれていた障害を検知した装置を調査対象装置とし、前記調査対象装置を管理する管理サーバに装置障害確認メッセージを送信し、
   前記装置障害確認メッセージを受信した管理サーバは、
   前記調査対象装置に係る障害イベントログを含む装置障害報告メッセージを作成して前記計算機に送信し、
   前記計算機は、
   受信した前記装置障害報告メッセージに基づいて、前記データパス構成情報に含まれる障害イベントを更新し、前記データパス構成情報のうち障害イベントのある装置の下流側にある装置を調査し、前記データパス構成情報の中で複数の障害イベントがある場合、一番下流にある障害イベントを抽出して根本原因として特定し、前記根本原因を表示装置に表示する
   ことを特徴とするストレージ管理方法。
2. 前記計算機は、前記通知メッセージで通知された障害にかかわるペアボリュームのコピー元のボリュームよりも上位に位置する装置に対し、その障害の影響範囲として特定する
   ことを特徴とする請求項１に記載のストレージ管理方法。
3. 複数のストレージ装置と、前記ストレージ装置の各々を管理する各管理サーバと、前記各管理サーバとの間で通信を行う計算機とを含んで構成されるストレージシステムであって、
   前記管理サーバは、管理下の前記ストレージ装置の接続形態を表す接続情報と、当該ストレージ装置のボリュームとペアを組むペアボリュームに関するペアボリューム情報とを格納する記憶部を有し、
   前記計算機は、
   一または複数の前記管理サーバからストレージ装置でのコピーに関する障害イベントの通知メッセージを受けた場合、前記通知メッセージからボリューム情報を抽出し、前記ボリューム情報に基づいてデータパスを構築するとともに構築したデータパスの構成を示すデータパス構成情報を作成し、前記通知メッセージに含まれていた障害を検知した装置を調査対象装置とし、前記調査対象装置を管理する管理サーバに装置障害確認メッセージを送信し、
   前記装置障害確認メッセージを受信した管理サーバは、
   前記調査対象装置に係る障害イベントログを含む装置障害報告メッセージを作成して前記計算機に送信し、
   前記計算機は、
   受信した前記装置障害報告メッセージに基づいて、前記データパス構成情報に含まれる障害イベントを更新し、前記データパス構成情報のうち障害イベントのある装置の下流側にある装置を調査し、前記データパス構成情報の中で複数の障害イベントがある場合、一番下流にある障害イベントを抽出して根本原因として特定し、前記根本原因を表示装置に表示する
   ことを特徴とするストレージシステム。
4. 前記計算機は、前記通知メッセージで通知された障害にかかわるペアボリュームのコピー元のボリュームよりも上位に位置する装置に対し、その障害の影響範囲として特定する
   ことを特徴とする請求項３に記載のストレージシステム。

Images