JP5352115B2 - ストレージシステム及びその監視条件変更方法 - Google Patents

Description

本発明は、ホスト計算機とストレージ装置と管理計算機とを含むストレージシステム及びその監視条件設定方法に関し、特に、ストレージ装置内に設けられるボリュームの監視条件の変更を行う場合に適用しても好適なものである。

情報化社会の進展により、社会の至るところで計算機システムが導入され、そこで処理されるデータ量は爆発的に増えている。また、情報化社会の進展とともに計算機システムで扱われるデータの重要性が高まり、保持されるデータに高い信頼性が要求されるとともに、保持されるデータの喪失をあらゆる災害から防ぐことが情報システムの社会的な使命になっている。

このようなシステムでは、データの信頼性を保障するために、ボリュームの多重化が行われている。処理を行うホスト計算機から出力されるデータは、直接接続されているストレージ装置内のボリュームだけでなく、他のボリューム又は他のストレージ装置のボリュームへもコピーされる。これにより、データは二重化され、データの信頼性が保障される。

一般に、コピーされるボリュームが前記ボリュームと同一ストレージ装置内にある場合をローカルコピー、コピーされるボリュームが前記ボリュームと別ストレージ装置内にある場合をリモートコピーと称し、高信頼性が要求される情報システムに適用されている。また、ローカルコピー、リモートコピーをまとめてレプリケーションと称することもある。このレプリケーション技術によれば、一方のボリュームに障害が発生して動作不可能な状態に陥っても、他方のボリュームに格納されているデータを用いてシステム動作を続行することが可能である。レプリケーションの関係にあるコピー元とコピー先の2つのボリュームをコピーペアと呼ぶ。

通常、コピーペアはホスト計算機もしくはアプリケーションの単位にグルーピングされ、この単位でコピーペアの制御や監視が行われる。複数のコピーペアをホスト計算機もしくはアプリケーションの単位でグルーピングしたグループをコピーグループと呼ぶ。

特許文献１には、複数のホスト計算機と複数のストレージ装置を有したストレージシステムにおいて、コピーグループのレプリケーション監視を行う技術が開示されている。
特開２００７−２４９４４７号公報

近年、ディザスタリカバリ（DR：Disaster Recovery）によってビジネス継続性を確保することの重要性が増してきている。ＤＲを実現する要素技術としてレプリケーション技術が適用されることが多い。ディザスタリカバリを確実に行うためには、監視対象の構成に応じた監視を行うことにより被災をいち早く検出し、必要に応じてストレージシステム構成を変更し、運用を継続する必要がある。

ストレージシステムがＤＲ構成をとっている場合、本番系システム（プライマリサイト）が被災すると、事前に決められた手順にしたがって待機系システム（リモートサイト）に引継ぎ処理が行われる。これにより業務継続性を確保するが、引継ぎ処理の結果発生した構成変更に応じて、これまで行われてきた監視の方法や監視条件の設定を変更しなければならない。

このような場合、従来技術では構成変更と監視が別個に行われていたため、行った構成変更に応じて管理者が手動で監視設定の切り替えを行う必要があった。特にストレージシステムが広域にわたって構築されるディザスタリカバリでは、構成変更が複数のサイトに影響を及ぼす。一方、監視はサイトごとに行われ、かつ上記構成変更がどのように行われるかは被災や障害の度合いによって異なる。そのため、あらかじめ監視条件を決めることが出来ず、現在観測している状態がシステム全体として正しいかどうかを判断できないためである。

本発明は、以上の点を考慮してなされたもので、管理者の管理負荷を軽減するとともに、監視負荷を低減することができるストレージシステム及びその監視条件変更方法を提案しようとするものである。

本発明は、１台以上のストレージ装置と、前記１台以上のストレージ装置へデータのリード／ライトを行なう１台以上のホスト計算機と、前記１台以上のホスト計算機を管理する管理計算機とを含むストレージシステムであって、前記１台以上のストレージ装置それぞれは、データを格納する１つ以上のディスク装置と、前記１つ以上のディスク装置が提供する記憶領域により構成される、複数のボリュームとを有し、前記１台以上のホスト計算機は、前記複数のボリュームのうちの所定数のボリュームで構成されるボリュームグループ（例えば、コピーペア、コピーグループ）の構成情報を管理し、前記管理計算機は、前記ボリュームグループの構成情報を利用して、ボリュームグループの構成変更の有無を検出し、構成変更があることを検出した場合に、予め設定された前記ボリュームグループの構成に合わせた監視条件の設定に基づいて、前記ボリュームグループの監視条件の設定を変更するものである。

この構成によると、複数サイトにわたる大規模なストレージシステムにおいて、ストレージシステムの管理計算機は、各サイトのホスト計算機からボリュームグループの構成情報（例えば、コピーペアのステータス情報）を収集し、収集した情報を解析することにより、ボリュームグループの構成変更（例えば、障害や災害が発生して本番系システムと、待機系システムの切り替え）が行われたことを検出すると、どのような構成変更が行われたかを判定して監視条件の設定を適切に切り替えることができる。

本発明によれば、管理者の管理負荷を軽減するとともに、監視負荷を低減することができるストレージシステム及びその監視条件変更方法を提案できる。

以下、本発明の各実施形態について説明する。なお、本発明は以下に説明する実施形態に限定されるものではない。

（第１の実施形態）
図１は、第１の実施形態のストレージシステムの構成を示すブロック図である。ストレージシステム１では、ストレージ装置１３００（１３００Ａ，１３００Ｂ）とホスト計算機１２００（１２００Ａ，１２００Ｂ）がデータネットワーク１５００（１５００Ａ，１５００Ｂ）で互いに接続される。なお、本第１の実施形態では、データネットワーク１５００はストレージエリアネットワークとするが、ＩＰ（Internet Protocol）ネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。

ホスト計算機１２００と管理計算機１１００は管理ネットワーク１４００を介して接続される。本第１の実施形態では、管理ネットワーク１４００はＩＰネットワークとするが、ストレージエリアネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。また、本実施形態では、管理計算機１１００はストレージ装置１３００と直接接続されず、ホスト計算機１２００を介して情報を取得するものとしたが、直接接続するような構成でも本発明を実施可能である。さらに、本実施形態では、データネットワーク１５００と管理ネットワーク１４００は別ネットワークであるとしたが、これら管理ネットワーク１４００が同一ネットワークであってもよいし、管理計算機１１００とホスト計算機１２００は同一計算機であってもかまわない。なお、説明の都合上、図１では、ストレージ装置１３００を２台、ホスト計算機１２００を２台、管理計算機１１００を１台としたが、本発明ではこれらの数は問わない。

ホスト計算機１２００とストレージ装置１３００とこれらを接続するデータネットワーク１５００の組を本第１の実施形態ではサイトと呼ぶ。複数のサイトは、一般的にお互い地理的に離れた位置に配置される。あるサイトが被災した場合でも他のサイトで業務を継続できるようにするためである。図１は、業務を行うプライマリサイト１７００と、そのバックアップサイトであるリモートサイト１８００からなる。このような構成を２データセンタ（以下、２ＤＣとする。）構成と呼称する。

２ＤＣ構成では、プライマリサイト１７００、リモートサイト１８００の間で、リモートネットワーク１６００を介してリモートコピーが行われる。リモートコピーとは、ストレージ装置のあるボリュームのデータを別のストレージ装置のボリュームにコピーすることにより、データを二重化する技術である。リモートコピー技術によれば、一方のボリュームに障害が発生して動作不可能な状態に陥っても、他方のボリュームに格納されているデータを用いてシステム動作を続行することが可能である。リモートコピーの関係にあるコピー元とコピー先の２つのボリュームをコピーペアと呼ぶ。

以下、管理計算機１１００の構成を図２に、ホスト計算機１２００の構成を図３に、ストレージ装置１３００の構成を図４に示す。

図２は、管理計算機１１００の構成を示す図である。管理計算機１１００は、キーボードやマウスなどの入力装置１１３０、ＣＰＵ（Central Processing Unit）１１４０、ＣＲＴ（Cathode Ray Tube）などの表示装置１１５０、メモリ１１２０、ローカルディスク１１１０、システム管理のためにホスト計算機１２００とデータや制御命令を送受信する管理Ｉ／Ｆ１１６０を有している。

ローカルディスク１１１０は、管理計算機１１００に接続されたハードディスクなどのディスク装置であり、管理プログラム１１１２が記憶されている。

管理プログラム１１１２は、管理計算機１１００のメモリ１１２０にロードされ、ＣＰＵ１１４０によって実行される。管理プログラム１１１２は、１つ以上のストレージ装置のコピーペアの監視を行うための機能をキーボードやマウスなどの入力装置１１３０やグラフィカルユーザインターフェース（GUI：Graphical User Interface）などの表示装置１１５０を介して提供するプログラムである。

メモリ１１２０上の管理テーブル１１２２については後述する。管理Ｉ／Ｆ１１６０は、管理ネットワーク１４００とのインターフェースであって、ホスト計算機１２００とデータや制御命令の送受信を行う。

図３は、ホスト計算機１２００の構成を示す図である。ホスト計算機１２００は、キーボードやマウスなどの入力装置１２４０、ＣＰＵ１２２０、ＣＲＴなどの表示装置１２５０、メモリ１２３０、ストレージＩ／Ｆ１２６０及びローカルディスク１２１０を有している。

ストレージＩ／Ｆ１２６０はデータネットワーク１５００に対するインターフェースであって、ストレージ装置１３００とデータや制御命令の送受信を行う。ローカルディスク１２１０は、ホスト計算機１２００に接続されたハードディスクなどのディスク装置であり、アプリケーション１２１２及び管理プログラム１２１４を格納している。

アプリケーション１２１２は、ホスト計算機１２００のメモリ１２３０上にロードされ、ＣＰＵ１２２０によって実行される。アプリケーション１２１２はストレージ装置１３００上のボリュームに対してデータを読み書きすることにより処理を実行するプログラムであり、例えば、ＤＢＭＳ（Data Base Management System）やファイルシステムなどである。なお、説明の都合上、図３ではアプリケーション１２１２を１つとしたが、本発明ではこの数は問わない。

管理プログラム１２１４は、ホスト計算機１２００のメモリ１２３０上にロードされ、ＣＰＵ１２２０によって実行される。管理プログラム１２１４は、管理計算機１１００からの指示に基づき、ストレージ装置１３００の情報を取得するプログラムである。この情報は、例えば、後述するコピーペアのステータス情報である。

図４は、ストレージ装置１３００の構成を示す図である。ストレージ装置１３００は、データを格納するディスク装置１３１０、ストレージ装置１３００の制御を行うディスクコントローラ１３２０で構成されている。

ディスク装置１３１０は、複数のボリューム１３１１、１３１２、１３１３から構成される。ボリュームは、ハードディスクドライブ（HDD）といった物理的なものであっても、論理デバイス(Logical Device)といった論理的なものであってもよく、本発明ではその種類を問わない。なお説明の都合上、図４ではボリュームの数を３個としたが、本発明ではこれらの数は問わない。ボリュームはコピーペアを構成することができる。

ディスクコントローラ１３２０には、ホストＩ／Ｆ１３２８、リモートＩ／Ｆ１３２６、ディスクＩ／Ｆ１３２５、メモリ１３２１、ＣＰＵ１３２３、ローカルディスク１３２７が設けられている。

ローカルディスク１３２７は、ディスクコントローラ１３２０に接続されたハードディスクなどのディスク装置であり、ストレージマイクロプログラム１３３０が記憶されている。

ストレージマイクロプログラム１３３０は、ディスクコントローラ１３２０のメモリ１３２１にロードされ、ＣＰＵ１３２３によって実行される。なお、本第１の実施形態では、ストレージマイクロプログラム１３３０がディスクコントローラ１３２０上のローカルディスク１３２７に記憶されているものとしたが、本発明はこれに限定されない。例えば、このストレージマイクロプログラム１３３０を、ディスクコントローラ１３２０上にフラッシュメモリなどを設け、そのフラッシュメモリに記憶することも、ディスク装置１３１０内の任意のディスクに記憶することも可能である。

ストレージマイクロプログラム１３３０は、ホスト計算機１２００からの指示を受けて、コピーペアの制御や、コピーペアの状態の取得を行う。コピーペアの制御として、コピーペアを新規に作成するコピーペアの形成、同期の関係を中断するコピーペアの一時停止、一時停止状態から副側のボリュームの内容を正側のボリュームの内容と一致させるコピーペアの再同期といった制御がある。コピーペアの状態の取得とは、それぞれのコピーペアが上記のどの制御によりどの状態になっているかを取得することである。

ホストＩ／Ｆ１３２８は、データネットワーク１５００に対するインターフェースであって、ホスト計算機１２００とデータや制御命令の送受信を行う。リモートＩ／Ｆ１３２６は、リモートネットワーク１６００とのインターフェースであって、サイト間にまたがって行われるリモートコピーのデータ転送に使用される。ディスクＩ／Ｆ１３２５は、ディスク装置１３１０に対するインターフェースであってデータや制御命令の送受信を行う。

ホスト計算機登録テーブル５００１及び図５に示すペアステータス監視テーブル５０００は、本第１の実施形態における管理テーブル１１２２を構成するテーブルである。ホスト計算機登録テーブル５００１は、管理テーブル１１２２上に作成され、ホスト計算機１２００の識別子とホスト計算機１２００を呼び出すために必要な情報を持つ。このホスト計算機１２００を呼び出すために必要な情報の一例はＩＰアドレスとポート番号である。なお、本テーブルは構成が単純であるため図示しない。

図５は、管理計算機１１００上の管理テーブル１１２２を構成するペアステータス監視テーブル５０００である。ペアステータス監視テーブル５０００は、ペアステータスフィールド５１００、被災状況フィールド５２００及び監視設定フィールド５３００を有している。ペアステータスフィールド５１００には、各サイト１７００，１８００から収集されうるコピーペアのステータスが格納される。

本第１の実施形態では、プライマリサイト１７００とリモートサイト１８００の２つのサイトからなる構成を対象としており、それぞれのサイト１７００，１８００からペアステータスが取得できるものとする。したがって、ペアステータスフィールド５１００には、プライマリサイト１７００から取得されうるペアステータスをＰ：の後ろに、リモートサイト１８００から取得されうるペアステータスをＲ：の後ろに格納する。

ここで、ペアステータスとして取得されうるステータスの種類を説明する。本第１の実施形態では、コピーペアの正側、副側のどちらから取得したか、コピーペアの状態はどのようになっているかによって、取得されうるステータスは９種類存在するものとする。

１個目のステータスはＰＡＩＲ（Ｐ）である。これは、ステータスを取得した側が正側であること、コピーペアの正側と副側が同期の取れた状態にあることを示している。

２個目のステータスはＰＡＩＲ（Ｓ）である。これは、ステータスを取得した側が副側であること、コピーペアの正側と副側が同期の取れた状態にあることを示している。

３個目のステータスはＳＵＳＰ（Ｐ）である。これは、ステータスを取得した側が正側であること、コピーペアの正側と副側が同期を一時中断している状態にあることを示している。

４個目のステータスはＳＵＳＰ（Ｓ）である。これは、ステータスを取得した側が副側であること、コピーペアの正側と副側が同期を一時中断している状態にあることを示している。

５個目のステータスはＮ／Ａ（Ｈ）である。これは、管理計算機１１００からホスト計算機１２００に対して行ったステータス取得要求に対して応答がないことを示している。

６個目のステータスはＮ／Ａ（Ｓ）である。これは、ホスト計算機１２００がストレージ装置１３００からのステータス取得に失敗したため、ホスト計算機１２００がコピーペアのステータス情報を返せないことを示している。

７個目のステータスはＰＳＵＥである。ストレージシステム１では、副側のボリュームが障害などによって使用できなくなった場合、正側のストレージ装置１３００に対して“Ｔａｋｅｏｖｅｒ”と呼ばれるコマンドを発行した後に、正側のボリュームのみで業務を再開する。このように“Ｔａｋｅｏｖｅｒ”コマンドを発行して正ボリュームのみで運用を行っている状態のことをＰＳＵＥと呼ぶ。

８個目のステータスはＳＳＷＳである。通常副側のボリュームは書込み禁止で運用している。そのため、ストレージシステム１では、正側のボリュームが障害などによって使用できなくなった場合、このままでは副側のボリュームを使用して業務を再開できない。そこで、副側のストレージ装置１３００に対して“Ｔａｋｅｏｖｅｒ”と呼ばれるコマンドを発行して副ボリュームに書き込みを行えるような状態にした後に業務を再開する。このように“Ｔａｋｅｏｖｅｒ”コマンドを発行して副ボリュームのみで運用を行っている状態のことをＳＳＷＳと呼ぶ。

９個目のステータスはＳＭＰＬである。これはステータスを取得したボリュームがコピーペアを構成しておらず、正側でも副側でもないことを示している。なお、コピーペア運用を行っている場合でも、ペアを構成している相手側に災害が発生して回復の見込みがない場合は、コピーペアの関係を解消しＳＭＰＬにするケースがある。このような場合のステータスをＳＭＰＬと呼ぶ。

被災状況フィールド５２００には、各サイト１７００，１８００から取得したペアステータスの組み合わせがペアステータスフィールド５１００に格納されているものであった場合に、そこから導出される被災状況が格納される。

監視設定フィールド５３００には、各サイト１７００，１８００から取得したペアステータスの組み合わせがペアステータスフィールド５１００に格納されているものであった場合に、プライマリサイト１７００に設定する監視条件をＰ：の後ろに、リモートサイト１８００に設定する監視条件をＳ：の後ろに格納する。

５０１０から５０８０は、図１に示される構成のストレージシステム１において、プライマリサイト１７００が正側、リモートサイト１８００が副側のリモートコピーを構成している場合のペアステータス監視テーブル５０００の構成要素である。

５０１０は、正常（被災なし）、すなわちコピーペアの正側と副側が同期の取れた状態にあることを示している。このような場合、正側、副側の両方からステータスを取得するのは冗長であるので、正側のみからステータスを取得すればよい。したがって、監視設定としては、プライマリサイト１７００においてＰＡＩＲ（Ｐ）であることを監視すればよい。なお、本第１実施形態では、プライマリサイト１７００において監視を行うものとしたが、リモートサイト１８００でＰＡＩＲ（Ｓ）であることの監視を行ってもよい。

５０２０は、プライマリサイト被災、すなわちプライマリサイト１７００のホスト計算機１２００Ａから応答がなく、ペアが解除された状態であることをリモートサイト１８００からのみ検出できる場合である。このような場合、プライマリサイト１７００が復旧するまでプライマリサイト１７００の監視は行わず、リモートサイト１８００がＳＭＰＬであることのみを監視すればよい。

５０３０は、プライマリサイト１７００のホスト計算機１２００Ａがダウンしたため、リモートサイト１８００のホスト計算機１２００Ｂが業務を引き継ぎ、副側のストレージ装置１３００Ｂに“Ｔａｋｅｏｖｅｒ”コマンドを発行してリモートサイト１８００がコピーペアの正側として同期の取れた状態にある場合である。このような場合、プライマリサイト１７００のホスト計算機１２００Ａの障害が復旧するまでプライマリサイト１７００の監視は行わず、リモートサイト１８００のステータスがＰＡＩＲ（Ｐ）であることを監視すればよい。なお、この場合、障害が発生したのはプライマリサイト１７００のホスト計算機１２００Ａのみであり、両サイト１７００，１８００のストレージ装置１３００Ａ，１３００Ｂがともに稼動しているため、“Ｔａｋｅｏｖｅｒ”コマンドが発行されると、プライマリサイト１７００とリモートサイト１８００の正副の関係を入れ替える操作が行われる。

５０４０は、プライマリサイト１７００のストレージ装置障害により、リモートサイト１８００から“Ｔａｋｅｏｖｅｒ”コマンドを発行することによって、リモートサイト１８００のみで業務を継続していることを示している。このような場合、プライマリサイト１７００のストレージ装置障害が復旧するまでプライマリサイト１７００の監視は行わず、リモートサイト１８００のステータスがＳＳＷＳであることを監視すればよい。

５０５０は、リモートサイト被災、すなわちリモートサイト１８００のホスト計算機１２００Ｂから応答がなく、プライマリサイト１７００はペアが解除された状態である。このような場合、リモートサイト１８００が復旧するまでリモートサイト１８００の監視は行わず、プライマリサイト１７００がＳＭＰＬであることのみを監視すればよい。

５０６０は、リモートサイト１８００のホスト計算機１２００Ｂがダウンしたものの、ストレージ装置１３００Ｂには障害が発生していない状態である。したがって、リモートサイト１８００のホスト計算機１２００Ｂからは応答はないものの、プライマリサイト１７００からはコピーペアの正側として同期の取れた状態であることが返っている。このような場合、リモートサイト１８００のホスト計算機障害が復旧するまでリモートサイト１８００の監視は行わず、プライマリサイト１７００のステータスがＰＡＩＲ（Ｐ）であることを監視すればよい。

５０７０はリモートサイト１８００のストレージ装置障害により、プライマリサイト１７００から“Ｔａｋｅｏｖｅｒ”コマンドを発行することによって、プライマリサイト１７００のみで業務継続していることを示している。このような場合、リモートサイト１８００のストレージ装置障害が復旧するまでリモートサイト１８００の監視は行わず、プライマリサイト１７００のステータスがＰＳＵＥであることを監視すればよい。

５０８０は、サイト間のネットワーク被災により、コピーペアの正側と副側が同期を一時中断している状態であることを示している。このような場合、プライマリサイト１７００、リモートサイト１８００のそれぞれがＳＵＳＰ（Ｐ）、ＳＵＳＰ（Ｓ）であることを監視すればよい。

図６は、管理計算機１１００上の管理プログラム１１１２が実行する、監視条件変更処理を示すフローチャートである。

本処理はステップ６１００によって開始されると、はじめにユーザからの終了指示の有無をチェックする（ステップ６１１０）。終了指示があった場合（ステップ６１１０にてＹＥＳ）、処理を終了する（ステップ６２３０）。

終了指示がなかった場合（ステップ６１１０にてＮＯ）、管理テーブル１１２２内のホスト計算機登録テーブル５００１に登録されているすべてのホスト計算機１２００上の管理プログラム１２１４に対し、ステータス取得要求を発行する（ステップ６１２０）。

ステータス取得要求を受信したホスト計算機１２００上の管理プログラム１２１４は、当該指示に基づきコピーペアのステータスを取得し、その取得したステータスを管理計算機１１００に返す。管理計算機１１００は、コピーペアのステータスが応答として返ると、ペアステータス管理テーブル５０００を参照する（ステップ６１３０）。

プライマリサイト１７００、リモートサイト１８００から取得したステータスと一致しているカラムを５０１０から５０８０の中から検索する（ステップ６１４０）。

一致するものがなかった場合（ステップ６１４０にてＮＯ）は、想定外の障害が発生して予期しない状態になっているか、状態遷移中でしばらく待てば５０１０から５０８０のいずれかの状態に遷移するケースかのいずれかである。予期せぬ障害か遷移中であるかは切り分けられないため、管理者に対してアラートを通知し（ステップ６２１０）、一定時間待機（ステップ６２２０）の後、再びステップ６１１０に戻ってステータスの再取得を行う。

一致するものがあった場合（ステップ６１４０にてＹＥＳ）には、一致したカラムの監視設定フィールド５３００を参照し、監視条件の設定を行う（ステップ６１５０）。

設定を行うと一定時間待機する（ステップ６１６０）。本第１の実施形態では、ポーリング方式によって一定時間ごとに管理計算機１１００からホスト計算機１２００に情報取得を行う形態を想定しているためである。

その後、監視条件に基づいて情報の取得を行う（ステップ６１７０）。監視設定がＳＴＯＰであれば、監視を行わなくてもよいため、そのホスト計算機１２００に対する情報の要求を行わない。

ホスト計算機１２００から情報を取得すると、取得したステータスが監視設定を満たしているかを確認する（ステップ６１８０）。取得したステータスが、監視設定と同一ではない場合（ステップ６１８０にてＮＯ）、構成が変わったことを示している。この場合、すべてのホスト計算機１２００から情報を取得して、どの構成に変わったかを検出する必要がある。そのため、ステップ６１１０に戻り、ステップ６１２０において全ホスト計算機１２００からのステータスの再取得を行う。

一方、取得したステータスが監視設定と同一である場合（ステップ６１８０にてＹＥＳ）は、ホスト計算機１２００からの通知の有無を確認する（ステップ６１９０）。

次に、管理プログラム１１１２は、ホスト計算機１２００上の管理プログラム１２１４からの通知の受信有無を確認する。ホスト計算機１２００上の管理プログラム１２１４は、起動時に管理計算機１１００に対して通知を行う。管理計算機１１００上の管理プログラム１１１２は、受信した通知が未知のホスト計算機１２００からのものであった場合、そのホスト計算機１２００を管理テーブル１１２２上のホスト計算機登録テーブル５００１に登録する。

また既知のホスト計算機１２００からの通知であっても、障害からの回復時はホスト計算機１２００上の管理プログラム１２１４も再度起動されることになるため、障害回復のタイミングでホスト計算機１２００から管理計算機１１００に対する通知が行われる。

このように、ホスト計算機１２００から通知があった場合（ステップ６１９０にてＹＥＳ）、障害からの回復を含む何かしらの構成変更が行われたということであるので、最初のステップ６１１０に戻り、すべてのホスト計算機１２００からのステータス取得を再度行う。

一方、ホスト計算機１２００からの通知がない場合（ステップ６１９０にてＮＯ）は、構成変更は行われていないということである。したがって、ユーザからの終了指示の有無をチェックし（ステップ６２００）、終了指示があれば処理を終了し（ステップ６２３０）、終了指示がなければ、一定間隔でのポーリングを行うためステップ６１６０に遷移する。

なお、本第１の実施形態では、監視の対象はコピーペアとしたが、コピーグループであっても同様に本発明を実施可能である。また、本発明の対象となるコピー種別はリモートコピーとしたが、ローカルコピーであっても同様に本発明を実施可能である。

（第２の実施形態）
第１の実施形態では、コピーペアのステータスのみに着目したが、性能情報の監視設定も併せて行うことが可能である。たとえば、第１の実施形態で説明したリモートコピーが、ジャーナルボリュームを利用した非同期リモートコピーであった場合、使用しているジャーナルボリュームの量を監視し、事前に決められた閾値を超えるとユーザに対してアラートを通知するといった仕組みを設けることが可能である。

本第２の実施形態では、第１の実施形態のバリエーションとして、コピーペアのステータスに加えジャーナルボリュームを利用した非同期リモートコピーの性能情報の監視設定も行えることについて説明する。

なおジャーナルボリュームとは、非同期リモートコピーにおいてプライマリサイトに設けられるボリュームであり、リモートサイトのストレージ装置に未反映の書き込みデータを一時的にバッファリングするために使用される。ジャーナルボリュームは、ネットワークの帯域が減少したり、業務のＩ／Ｏ（Input Output）が想定以上に発生すると溢れてしまう可能性があるため、閾値を設けて、その閾値を超えないことを監視することが一般的に行われる。

本第２の実施形態のストレージシステムの構成は、第１の実施形態のストレージシステム１の構成と同一であるため、同一の構成には同一の符号を付して説明することとする。

図７に示すペアステータス監視テーブル７０００、図８に示す閾値決定テーブル８０００及びホスト計算機登録テーブル５００1は、本第２の実施形態における管理テーブル１１２２を構成するテーブルである。以下、ペアステータス監視テーブル７０００及び閾値決定テーブル８０００について詳細に説明する。

図７は、性能情報として非同期リモートコピーのジャーナルボリュームの使用量を取得し、閾値監視を行う場合のペアステータス監視テーブル７０００である。ここでは、ペアステータス監視テーブル７０００の、図５に示したペアステータス監視テーブル５０００との相違のみを説明する。ペアステータスフィールド５１００及び被災状況フィールド５２００はペアステータス監視テーブル５０００の構成と同一である。

相違点は、監視設定フィールド５３００にコピーペアのステータス監視だけではなく、ジャーナル（以下ＪＮＬと表記する。）の設定が付与された点である。すなわち、ＪＮＬと記載されている場合、記載された側のサイトにおいてジャーナルボリュームの閾値監視を行う。閾値の値は後述する閾値決定テーブル８０００によって決定される。なおジャーナルボリュームの閾値監視は、コピーペアのステータスがＰＡＩＲである場合、すなわち正副のボリューム間の同期が取れている状態でのみ意味を持つ。

したがって、ペアステータス監視テーブル７０００において、コピーペアのステータスがＰＡＩＲである、７０１０、７０３０、７０６０のケースにおいてのみジャーナルボリュームの閾値監視を行えばよい。なお、７０１０及び７０６０のケースではプライマリサイト１７００が正側になっているためプライマリサイト１７００が、７０３０のケースではリモートサイト１８００が正側になっているためリモートサイト１８００がＪＮＬの監視対象となる。

図８は、ジャーナルの閾値を決定する、閾値決定テーブル８０００である。閾値決定テーブル８０００は、コピーペア名フィールド８１００、コピーペア容量フィールド８２００及びＪＮＬ閾値フィールド８３００を有している。本第２の実施形態では、ジャーナルボリュームの閾値はコピーペアを構成しているボリューム容量の１％とするが、本発明はこの値に限定されるものではない。また、この値をユーザに指定させても本発明を実施可能である。

本第２の実施形態では、ＣＧ０１という名称のコピーペアがあり、このコピーペアの容量は３００ＴＢ、ＪＮＬ閾値は３．０ＴＢであることが示されている。

処理の流れについて、図６に示したフローチャートとの相違についてのみ以下で説明する。

ステップ６１５０において監視条件を設定する際、ペアステータス監視テーブル７０００を参照し、ジャーナルボリュームの閾値を設定すべきであれば設定する。

ステップ６１７０においてステータスを取得する際、監視条件にジャーナルボリュームの閾値が含まれている場合は、ジャーナルボリューム使用量を取得する。

ステップ６１８０において、取得したステータスが監視条件と一致しているかをチェックする際に、ステップ６１７０においてジャーナル使用量を取得していれば、これが閾値決定テーブル８０００に格納されている閾値を下回っていることを確認する。下回っている場合はステップ６１９０に進むが、上回っている場合には「ステータスが監視条件を満たしていない」とみなし、ステップ６１１０に進む。

上記の処理により、コピーペアのステータスに加えジャーナルボリュームを利用した非同期リモートコピーの性能情報の監視設定も行うことが可能である。

（第３の実施形態）
第１の実施形態は、災害や障害といった管理者が予めいつ発生するかを予期できない事象に対し、事象が発生して構成が切り替えられた後に、その構成の変更を検出して監視設定の切り替えを行うものである。しかしながら、バックアップなど予め設定されたスケジュールに基づいて行われ、コピーペアのステータスや構成に影響を及ぼすタスクも存在する。第１の実施形態は、監視設定の切り替えは監視の結果、構成の変更を検出して行うことを説明しているが、スケジュールが予め設定されている場合には、そのスケジュールを加味してあらかじめ監視設定を切り替えることが可能である。

本第３の実施形態では、監視設定の切り替えを、構成変更検出とスケジュール実行の両方をトリガとして行う方法について説明する。

本第３の実施形態のストレージシステムの構成は、第１の実施形態のストレージシステム１の構成と同一であるため、同一の構成には同一の符号を付して説明することとする。

図９に示すペアステータス監視テーブル９０００、図１０に示すスケジュールテーブル１００００及びホスト計算機登録テーブル５００１は、本第３の実施形態における管理テーブル１１２２を構成するテーブルである。以下、ペアステータス監視テーブル９０００及びスケジュールテーブル１００００について詳細に説明する。

図９は、スケジュール実行を加味したペアステータス監視テーブル９０００である。ここでは、図５に示したペアステータス監視テーブル５０００との相違のみを説明する。ペアステータス監視テーブル９０００を説明するに当たり、これまでに述べた９つのステータスに加えて、２つのステータスを説明する。

１０個目のステータスはＲＥＳＹＮＣ（Ｐ）である。これは、ステータスを取得した側が正側であること、コピーペアの正側と副側が同期を一時中断している状態から再び同期している状態に復帰中であることを示している。

１１個目のステータスはＲＥＳＹＮＣ（Ｓ）である。これは、ステータスを取得した側が副側であること、コピーペアの正側と副側が同期を一時中断している状態から再び同期している状態に復帰中であることを示している。

ペアステータス監視テーブル９０００のフィールドの構成はペアステータス監視テーブル５０００と同一である。ペアステータス監視テーブルの構成要素５０１０から５０８０までは、ペアステータス監視テーブル５０００と同一である。

９０９０は、バックアップ中のため、コピーペアの正側と副側が同期を一時中断している状態であることを示している。このような場合、プライマリサイト１７００、リモートサイト１８００のそれぞれがＳＵＳＰ（Ｐ）、ＳＵＳＰ（Ｓ）であることを監視すればよい。５０８０と同じ条件であるが、バックアップ中は本状態を正常状態とみなし、それ以外の時間帯に本状態を検出した場合はネットワーク障害を疑うことになる。

９１００は、バックアップが終了し、コピーペアの正側と副側が同期を一時中断している状態から再び同期している状態に復帰中であることを示している。このような場合、プライマリサイト１７００、リモートサイト１８００のそれぞれがＲＥＳＹＮＣ（Ｐ）、ＲＥＳＹＮＣ（Ｓ）であることを監視すればよい。なお、この再同期の処理が完了すると、再び正側と副側は同期された状態になる。

図１０は、スケジュールテーブル１００００である。時刻フィールド１０１００には、タスクが実行される時間が格納される。タスクフィールド１０２００には、上記時間に実行されるタスクの名称が格納される。適用ルールフィールド１０３００には、タスクが実行される際に適用されるべき監視条件の番号が格納される。この番号は、ペアステータス監視テーブル９０００の左側に記載されている番号である。

たとえば、１００１０は、２：００から３：００の間、バックアップタスクが実行され、その間はペアステータス監視テーブル９０００の＃９のルールすなわち、コピーペアの正側と副側が同期を一時中断している状態であることを監視すればよいことを示している。

管理計算機１１００上の管理プログラム１１１２は、スケジュールテーブル１００００を参照し、タスク開始時刻になると、監視条件設定処理を行う。本第３の実施形態では、タスク開始時刻は２：００、３：００及び３：１０である。

監視条件設定処理はタスク開始時刻になると起動され、そのときの監視設定がスケジュールテーブル１００００の該当するフィールドの１つ前のものであった場合、適用ルールフィールドに格納されたルールを適用する。例えば、３：００には、その時点で適用されている監視条件が＃９、すなわち、プライマリサイト１７００、リモートサイト１８００がペアの同期を一時中断していることを監視中であれば、＃１０の監視条件に切り替えを行う。なお、このようにステータス設定が行なわれない場合は、バックアップ処理が正常に動作していないこととなる。このため、そのステータス設定が行なわれない場合はその旨をユーザに通知することにより、管理計算機１１００は障害などが発生したことをユーザに報知することができる。この際、監視条件の設定処理は行わない。なお、ユーザは管理計算機１１００の管理者でも良いし、各サイト１７００，１８００の管理者でも良い。

図６に示したフローチャートの処理に加え、上記の処理を行うことにより、監視設定の切り替えを、構成変更検出とスケジュール実行の両方をトリガとして行うことが可能となる。

（第４の実施形態）
第１の実施形態から第３の実施形態では、ストレージ装置１３００に対して接続されるホスト計算機１２００の台数を１台としていた。しかしながら、１台のストレージ装置に複数台のホスト計算機を接続しても本発明の実施が可能である。

図１１は本実施形態のストレージシステム２の構成を示すブロック図である。図１に示したストレージシステム１との相違を説明する。ストレージシステム２では、プライマリサイト１７００、リモートサイト１８００の各サイトにおいて、１台のストレージ装置１３００（１３００Ａ、１３００Ｂ）と２台のホスト計算機１２００（１２００Ａ，Ｃ、１２００Ｂ，Ｄ）がデータネットワーク１５００（１５００Ａ、１５００Ｂ）で互いに接続される。

本第４の実施形態では、１台のストレージ装置１３００に接続されるホスト計算機１２００の数は２台としたが、本発明ではこれらの数は問わない。また、ホスト計算機１２００は物理的なホスト計算機ではなく仮想的なホスト計算機でも構わない。すなわち、サーバ仮想化技術を適用することにより、物理的に１台のホスト計算機上に複数台の仮想的なホスト計算機を稼動させるような構成でも本発明を実施可能である。

この構成において、プライマリサイト１７００の２つのホスト計算機１２００Ａ，Ｃ上でそれぞれ業務が稼動しており、ここからプライマリサイト１７００のストレージ装置１３００Ａに書き込みが行われ、さらにリモートサイト１８００のストレージ装置１３００Ｂに非同期リモートコピーによりデータが転送されるものとする。ここで、プライマリサイト１７００のそれぞれのホスト計算機１２００Ａ，Ｃが使用しているコピーペアの名称を、ＣＧ０１及びＣＧ０２とする。なお、本第４の実施形態ではＣＧ０１及びＣＧ０２はコピーペアであるとしたが、コピーグループであっても本発明を実施することが可能である。

図７に示すペアステータス監視テーブル７０００、図１２に示す閾値決定テーブル１２０００及びホスト計算機登録テーブル５００１は、本実施の形態における管理テーブル１１２２を構成するテーブルである。以下閾値決定テーブル１２０００について詳細に説明する。

図１２はジャーナルの閾値を決定する、閾値決定テーブル１２０００である。閾値決定テーブル１２０００のフィールドの構成は、図８に示した閾値決定テーブル８０００と同一である。本第４の実施形態では、ジャーナルボリュームの閾値はコピーペアを構成しているボリューム容量の１％とするが、本発明はこの値に限定されるものではない。また、この値をユーザに指定させても本発明を実施可能である。この閾値決定テーブル１２０００から、コピーペアがＣＧ０１、ＣＧ０２の２つ定義されていること、ＣＧ０１のコピーペア容量が３００ＴＢであり、ＪＮＬ閾値が３．０ＴＢであること、ＣＧ０２のコピーペア容量が２５０ＴＢであり、ＪＮＬ閾値が２．５ＴＢであることがわかる。

通常運用時は、２つの業務はプライマリサイト１７００で稼動する。そのため、ＪＮＬの監視はプライマリサイト１７００にて、５．５ＴＢを閾値として行うことになる。

処理の流れは図６に示したフローチャートにより説明されるが、相違点のみを説明する。ステップ６１９０においてホスト計算機１２００上の管理プログラム１２１４から通知を受信する際に、ホスト計算機１２００が複数台あることを考慮する必要がある。災害や障害が発生すると、プライマリサイト１７００からリモートサイト１８００に“Ｔａｋｅｏｖｅｒ”コマンドが発行されるケースがある。この場合、コピーペアごとに、それぞれのコピーペアの正側がどちらのサイトであるかを監視し、正側のサイトに対し、閾値決定テーブル１２０００に基づいた閾値監視を行う。

さらに、災害や障害だけではなく、メンテナンスや負荷分散を目的に業務をプライマリサイト１７００からリモートサイト１８００にコピーペア単位で正副を入れ替えたり、片側を停止したりするケースがある。この場合も、業務が移動したことをホスト計算機１２００上の管理プログラム１２１４が、管理計算機１１００に通知する。この通知を受信すると、管理計算機１１００は全ステータスを再取得することによって、業務がサイトを移動したことを検出する必要がある。

なお、この場合、移動した業務に対応するコピーペアのＪＮＬ閾値の和をそれぞれのサイトで監視すべき閾値として設定する。例えば、ＣＧ０１、ＣＧ０２の両方の正側がプライマリサイト１７００であれば、プライマリサイト１７００のＪＮＬ閾値を５．５ＴＢに設定する。また、ＣＧ０１の正側がプライマリサイト１７００にあり、ＣＧ０２の正側がリモートサイト１８００にあれば、プライマリサイト１７００のＪＮＬ閾値を３．０ＴＢに、リモートサイト１８００のＪＮＬ閾値を２．５ＴＢに設定する。

なおサーバ仮想化技術として知られている技術を適用することにより、物理的に１台のホスト計算機１２００上に複数台の仮想的なホスト計算機を稼動させるような構成をとることが可能である。サーバ仮想化技術をマルチサイト構成のストレージシステムに適用すると、通常時はバックアップなどしか行わず、被災時しか業務を行わないリモートサイト側には少ない数の物理的なホスト計算機しか用意しなくても本発明を実施可能なため、リモートサイトの構築コストを抑えられるというメリットがある。

この場合、仮想的なホスト計算機を管理する管理プログラムが、仮想的なホスト計算機の構成が変更された際に管理計算機１１００上の管理プログラム１１１２に通知を行うようにして、それを図６に示したフローチャートのステップ６１９０において受信しても本発明を実施可能である。

（第５の実施形態）
リモートコピーには非同期リモートコピーの他に同期リモートコピーがある。同期リモートコピーとは、業務を行っているホスト計算機から発行された書き込みが、正側のストレージ装置と副側のストレージ装置の両方に書き込まれた後に業務を行っているホスト計算機に書き込み完了応答を返す方式である。同期リモートコピーは、正側と副側のデータが常に一致するため、被災時のデータロスがないという特徴がある。

第１から第４の実施形態説明したように、２つのサイト間でリモートコピーを行うことにより、１つのサイトが被災した場合でも残りのサイトで業務を継続することができる。しかしながら、１つのサイトが被災してしまうと残り１サイトでの運用となるため、冗長度は失われてしまう。また、２つのサイトを近距離に配置する場合、ネットワークの遅延が少ないため同期リモートコピーを使用することができ、被災時に失われてしまうデータの量を極小化することができるが、大規模災害に弱いという欠点がある。一方、２つのサイトを遠距離に配置する場合、大規模災害には強いが、ネットワークの遅延が大きいため非同期リモートコピーを使用せざるを得ず、被災時に失われてしまうデータの量が多くなってしまうという欠点がある。

そこで、これらの欠点をカバーするために、プライマリサイトに対して同期リモートコピーを行う近距離のローカルサイトと、非同期リモートコピーを行う遠距離のリモートサイトを組み合わせた３データセンタ（以下、３ＤＣとする）構成を取る場合がある。３ＤＣ構成を取ることにより、プライマリサイトのみが被災してしまった場合には、ローカルサイトにおいてデータロスを極小におさえた業務継続を行い、プライマリサイトとローカルサイトの両方が被災するような大規模災害が発生した場合には、リモートサイトにおいて最小限のデータロスで業務継続を行うことができる。

本第５の実施形態では、３ＤＣ構成をとった場合でも本発明を実施可能であることを説明する。

図１３は、本第５の実施形態のストレージシステムの構成を示すブロック図である。ストレージシステム３は、図１に示す構成に加えてローカルサイト１３１００が追加されている。ローカルサイト１３１００の構成は他のサイト１７００，１８００の構成と同様である。また、ローカルサイト１３１００内を構成する管理計算機１１００、ホスト計算機１２００Ｅ、ストレージ装置１３００Ｅの構成は、第１の実施形態においてそれぞれ図２、図３、図４を用いてした説明と同様である。

ローカルサイト１３１００内のホスト計算機１２００Ｅは、管理計算機１１００と管理ネットワーク１４００で互いに接続される。ローカルサイト１３１００内のストレージ装置１３００Ｅは、リモートネットワーク１６００を介して他サイトのストレージ装置１３００Ａ，１３００Ｂと互いに接続される。なお、説明の都合上、図１３では、ストレージ装置１３００を３台、ホスト計算機１２００を３台、管理計算機１１００を１台としたが、本発明ではこれらの数は問わない。

この構成において、プライマリサイト１７００のホスト計算機１２００Ａ上で業務が稼動しており、ここからプライマリサイト１７００のストレージ装置１３００Ａに書き込みが行われる。さらに、プライマリサイト１７００とローカルサイト１３１００の間で同期リモートコピーが行われ、プライマリサイト１７００とリモートサイト１８００の間で非同期リモートコピーが行われているものとする。ここで、ローカルサイト１３１００とリモートサイト１８００の間では、プライマリサイト１７００が被災した際に速やかに非同期リモートコピーの同期状態に移行できるようにプライマリサイト１７００から書き込まれたデータの差分管理を行っているものとする。

図１４及び図１５に示すペアステータス監視テーブル１４０００、１４００１、及びホスト計算機登録テーブル５００１は、本実施の形態における管理テーブル１１２２を構成するテーブルである。以下、ペアステータス監視テーブル１４０００、１４００１について詳細に説明する。

ペアステータス監視テーブル１４０００及び１４００１を説明するに当たり、これまでに述べた１１種類のステータスに加えて、２種類のステータスを説明する。

１２個目のステータスはＨＯＬＤ（Ｐ）である。これは、ステータスを取得した側が正側であること、コピーペアの正側と副側が差分管理を行い、障害発生時には差分データの転送だけで同期状態に復帰できる状態であることを示している。

１３個目のステータスはＨＯＬＤ（Ｓ）である。これは、ステータスを取得した側が副側であること、コピーペアの正側と副側が差分管理を行い、障害発生時には差分データの転送だけで同期状態に復帰できる状態であることを示している。

ペアステータス監視テーブル１４０００及び１４００１は、ペアステータスフィールド５１００、被災状況フィールド５２００及び監視設定フィールド５３００を有している。ペアステータスフィールド５１００には、各サイトから収集されうるコピーペアのステータスが格納される。本第５の実施形態では、プライマリサイト１７００とローカルサイト１３１００及びリモートサイト１８００の３つのサイトからなる構成を対象としており、それぞれのサイトからペアステータスが取得できるものとする。したがって、ペアステータスフィールド５１００には、プライマリサイト１７００から取得したペアステータスをＰ：の後ろに、ローカルサイト１３１００から取得したペアステータスをＬ：の後ろに、リモートサイト１８００から取得したペアステータスをＲ：の後ろに格納する。

以下、プライマリサイト１７００とローカルサイト１３１００の間の同期リモートコピーをＴＣ（True Copy）、プライマリサイト１７００とリモートサイト１８００の間の非同期リモートコピーをＵＲ（Universal Replicate）と呼称する。なお、ローカルサイト１３１００とリモートサイト１８００の間で行っているデータの差分管理をＵＲ２と呼称する。

被災状況フィールド５２００には、各サイト１７００，１３１００，１８００から取得したペアステータスの組み合わせから導出される被災状況が格納される。

監視設定フィールド５３００には、正副のペアステータスがペアステータスフィールド５１００に格納されているものであった場合にプライマリサイト１７００に設定する監視条件をＰ：の後ろに、ローカルサイト１３１００に設定する監視条件をＬ：の後ろに、リモートサイト１８００に設定する監視条件をＲ：の後ろに格納する。

１４０１０から１４１３０は、ストレージシステム３において、同期リモートコピーと非同期リモートコピーを組み合わせた３ＤＣのストレージシステムが構成されている場合の、ペアステータス監視テーブル１４０００及び１４００１の構成要素である。

１４０１０は、正常（被災なし）を示している。すなわち、ＴＣ及びＵＲが同期の取れた状態にあり、ＵＲ２が差分管理している状態である。このような場合、正側、副側の両方からステータスを取得するのは冗長であるので、正側のみからステータスを取得すればよい。したがって、監視設定としては、プライマリサイト１７００のＴＣ、ＵＲがそれぞれＰＡＩＲ（Ｐ）であること、ローカルサイト１３１００のＵＲ２がＨＯＬＤ（Ｐ）であることを監視すればよい。本第５の実施形態では、それぞれのコピーペアの正側を監視するものとしたが、副側で監視を行ってもよい。

１４０２０は、プライマリサイト被災を示している。すなわちプライマリサイト１７００がダウンしてＴＣ及びＵＲのペアは解除された状態にあり、差分管理を行っていたＵＲ２が同期状態になることによって、ローカルサイト１３１００とリモートサイト１８００の間でコピーを行っている状態である。このような場合、ＳＭＰＬとなっているＴＣ及びＵＲペアの監視は行わず、同期が取れた状態のＵＲ２の監視をコピーペアの正側すなわちローカルサイト１３１００から行えばよい。

１４０３０は、プライマリサイトのホスト計算機がダウンした状態を示している。ローカルサイト１３１００のホスト計算機１２００が業務を引き継ぎ、ＴＣは“Ｔａｋｅｏｖｅｒ”コマンドが発行されてローカルサイト１３１００がコピーペアの正側として同期の取れた状態に、ＵＲは差分管理状態に、ＵＲ２はローカルサイト１３１００がコピーペアの正側として同期の取れた状態になる。したがって、監視設定としては、プライマリサイト１７００のホスト計算機障害が復旧するまでプライマリサイト１７００の監視は行わず、ローカルサイト１３１００のＴＣ、ＵＲ２がそれぞれＰＡＩＲ（Ｐ）であること、及びＵＲは副側であるリモートサイト１８００からしか監視できないため、リモートサイト１８００のＵＲがＨＯＬＤ（Ｓ）であることを監視すればよい。

１４０４０は、プライマリサイトでストレージ装置障害が発生した状態を示している。プライマリサイト１７００のストレージ装置１３００Ａに障害が発生したため、ローカルサイト１３１００にて業務を引き継ぐ。ＴＣ、ＵＲはそれぞれローカルサイト１３１００、リモートサイト１８００において“Ｔａｋｅｏｖｅｒ”コマンドが発行され副側のボリュームに書き込みを行えるような状態にし、差分管理を行っていたＵＲ２が同期状態になることによって、ローカルサイト１３１００とリモートサイト１８００の間でコピーを行う。したがって、監視設定としては、プライマリサイト１７００のストレージ装置障害が復旧するまでプライマリサイト１７００の監視は行わず、ローカルサイト１３１００においてＴＣがＳＳＷＳであること、ＵＲ２がＰＡＩＲ（Ｐ）であることを、リモートサイト１８００においてＵＲがＳＳＷＳであることを監視すればよい。

１４０５０は、ローカルサイト被災を示している。すなわちローカルサイト１３１００がダウンしてＴＣ、ＵＲ２のペアは解除された状態にあり、ＵＲペアのみが同期状態にある場合である。したがって、監視設定としては、ローカルサイト１３１００が復旧するまでローカルサイト１３１００の監視は行わず、プライマリサイト１７００においてＵＲがＰＡＩＲ（Ｐ）であることのみを監視すればよい。

１４０６０は、ローカルサイトのホスト計算機がダウンしたものの、ストレージ装置には障害が発生していない状態である。すなわち、ローカルサイト１３１００のホスト計算機１２００Ｅからは応答はないものの、プライマリサイト、リモートサイトからは正常時と同様の状態であることが返っている。このような場合、ローカルサイトのホスト計算機障害が復旧するまでローカルサイトの監視は行わず、プライマリサイトにおいて、ＴＣ及びＵＲがＰＡＩＲ（Ｐ）であること、リモートサイトにおいて、ＵＲ２がＨＯＬＤ（Ｓ）であることを監視すればよい。

１４０７０はローカルサイトでストレージ装置障害が発生した状態を示している。ローカルサイト１３１００のストレージ装置１３００Ｅに障害が発生したため、プライマリサイト１７００とリモートサイト１８００の間のみが同期の取れた状態である。このような場合、ローカルサイト１３１００のストレージ装置障害が復旧するまでローカルサイト１３１００の監視は行わず、プライマリサイト１７００において、ＴＣがＰＳＵＥであること、ＵＲがＰＡＩＲ（Ｐ）であること、リモートサイト１８００において、ＵＲ２がＳＳＷＳであることを監視すればよい。

１４０８０は、リモートサイト被災を示している。すなわちリモートサイト１８００がダウンしてＵＲ、ＵＲ２のペアは解除された状態にあり、ＴＣペアのみが同期状態にある場合である。したがって、監視設定としては、リモートサイト１８００が復旧するまでリモートサイト１８００の監視は行わず、プライマリサイト１７００においてＴＣがＰＡＩＲ（Ｐ）であることのみを監視すればよい。

１４０９０は、リモートサイトのホスト計算機がダウンしたものの、ストレージ装置には障害が発生していない状態である。すなわち、リモートサイト１８００のホスト計算機１２００Ｂからは応答はないものの、プライマリサイト１７００、ローカルサイト１３１００からは正常時と同様の状態であることが返っている。このような場合、リモートサイト１８００のホスト計算機障害が復旧するまでリモートサイト１８００の監視は行わず、プライマリサイト１７００において、ＴＣ及びＵＲがＰＡＩＲ（Ｐ）であること、ローカルサイト１３１００において、ＵＲ２がＨＯＬＤ（Ｐ）であることを監視すればよい。

１４１００はリモートサイトでストレージ装置障害が発生した状態を示している。リモートサイト１８００のストレージ装置１３００Ｂに障害が発生したため、プライマリサイト１７００とローカルサイト１３１００の間のみが同期の取れた状態である。このような場合、リモートサイト１８００のストレージ装置障害が復旧するまでリモートサイト１８００の監視は行わず、プライマリサイト１７００において、ＴＣがＰＡＩＲ（Ｐ）であること、ＵＲがＰＳＵＥであること、ローカルサイト１３１００において、ＵＲ２がＰＳＵＥであることを監視すればよい。

１４１１０は、プライマリサイトとローカルサイトの間のネットワーク被災により、コピーペアＴＣの正側と副側が同期を一時中断している状態であることを示している。このような場合、プライマリサイト１７００において、ＴＣがＳＵＳＰ（Ｐ）であること、ＵＲがＰＡＩＲ（Ｐ）であること、ローカルサイト１３１００において、ＴＣがＳＵＳＰ（Ｓ）であること、ＵＲ２がＨＯＬＤ（Ｐ）であることを監視すればよい。

１４１２０は、プライマリサイトとリモートサイトの間のネットワーク被災により、コピーペアＵＲの正側と副側が同期を一時中断している状態であることを示している。このような場合、プライマリサイト１７００において、ＴＣがＰＡＩＲ（Ｐ）であること、ＵＲがＳＵＳＰ（Ｐ）であること、ローカルサイト１３１００において、ＵＲ２がＨＯＬＤ（Ｐ）であること、リモートサイト１８００において、ＵＲがＳＵＳＰ（Ｓ）であることを監視すればよい。

１４１３０は、ローカルサイトとリモートサイトの間のネットワーク被災により、コピーペアＵＲ２の正側と副側が差分管理を一時中断している状態であることを示している。このような場合、プライマリサイト１７００において、ＴＣ及びＵＲがＰＡＩＲ（Ｐ）であること、ローカルサイト１３１００において、ＵＲ２がＳＵＳＰ（Ｐ）であること、リモートサイト１８００において、ＵＲ２がＳＵＳＰ（Ｓ）であることを監視すればよい。

本第５の実施形態の処理の流れは、第１の実施形態における図６に示すフローチャートによって説明されたものと同一である。相違点は、参照するテーブルがペアステータス監視テーブル５０００ではなく、ペアステータス監視テーブル１４０００及び１４００１であることである。

なお、本第５の実施形態では、ペアのステータスのみを監視条件として設定するものとしたが、第２の実施形態で示したように性能情報も監視条件として追加することができる。

上記各実施形態のストレージシステム１，２及び３によると、構成の変更に応じて監視方法や監視条件の再設定を行うことによりレプリケーション管理者の管理負荷を軽減するとともに、監視対象を最適化することによって監視負荷を低減することができる。

本発明は、ストレージシステム及びその監視条件変更方法に広く適用することができる。

本発明の第１の実施形態に係わるストレーシシステムの構成を示す図である。 同実施形態に係わる管理計算機の構成を示す図である。 同実施形態に係わるホスト計算機の構成を示す図である。 同実施形態に係わるストレージ装置の構成を示す図である。 同実施形態に係わるペアステータス監視テーブルの一例を示す図である。 同実施形態に係わる管理計算機の管理プログラムの監視条件の設定を行う処理を示すフローチャートである。 本発明の第２の実施形態に係わるペアステータス監視テーブルの一例を示す図である。 同実施の態に係わる閾値決定テーブルの一例を示す図である。 本発明の第３の実施形態に係わるペアステータス監視テーブルの一例を示す図である。 同実施形態に係わるスケジュールテーブルの一例を示す図である。 本発明の第４の実施形態に係わるストレージシステムの構成を示す図である。 同実施形態に係わる閾値決定テーブルの一例を示す図である。 本発明の第５の実施形態に係わるストレージステムの構成を示す図である。 同実施形態に係わるペアステータス監視テーブルの一例の一部分を示す図である。 同実施形態に係わるペアステータス監視テーブルの一例の他の部分を示す図である。

符号の説明

１，２，３…ストレージシステム、１１００…管理計算機、１１１０…ローカルディスク、１１１２…管理プログラム、１１２０…メモリ、１１２２…管理テーブル、１１３０…入力装置、１１５０…表示装置、１２００（１２００Ａ，Ｂ，Ｃ，Ｄ，Ｅ）…ホスト計算機、１２１０…ローカルディスク、１２１２…アプリケーション、１２１４…管理プログラム、１２３０…メモリ、１２４０…入力装置、１２５０…表示装置、１３００（１３００Ａ，Ｂ、Ｅ）…ストレージ装置、１３１０…ディスク装置、１３１１…ボリューム、１３２０ …ディスクコントローラ、１３２１…メモリ、１３２７…ローカルディスク、１３３０…ストレージマイクロプログラム、１４００…管理ネットワーク、１５００…データネットワーク、１６００…リモートネットワーク、１７００…プライマリサイト、１８００…リモートサイト、５０００…ペアステータス監視テーブル、５００1…ホスト計算機登録テーブル、５０１０…構成要素、５１００…ペアステータスフィールド、５２００…被災状況フィールド、５３００…監視設定フィールド、７０００…ペアステータス監視テーブル、８０００…閾値決定テーブル、８１００…コピーペア名フィールド、８２００…コピーペア容量フィールド、８３００…閾値フィールド、９０００…ペアステータス監視テーブル、１００００…スケジュールテーブル、１０１００…時刻フィールド、１０２００…タスクフィールド、１０３００…適用ルールフィールド、１２０００…閾値決定テーブル、１３１００…ローカルサイト、１４０００…ペアステータス監視テーブル

Claims (7)

1. １台以上のストレージ装置と、前記１台以上のストレージ装置へデータのリード／ライトを行う１台以上のホスト計算機と、前記１台以上のホスト計算機を管理する管理計算機とを含むストレージシステムであって、
   前記１台以上のストレージ装置それぞれは、
   データを格納する１つ以上のディスク装置と、前記１つ以上のディスク装置が提供する記憶領域により構成される、複数のボリュームとを有し、
   前記１台以上のホスト計算機は、
   前記複数のボリュームのうちの所定数のボリュームで構成されるボリュームグループの構成情報を管理し、
   前記ボリュームグループの構成は、前記複数のボリュームのうちの１つのボリュームを前記１台以上のホスト計算機のいずれかからデータライトされる正ボリュームとし、前記正ボリュームでないボリュームを前記正ボリュームに書き込まれたデータのコピー先である副ボリュームとするコピーペアの構成であり、
   前記正ボリュームを備える前記ストレージ装置と前記ホスト計算機との組で構成されるプライマリサイトと、前記副ボリュームを備える前記ストレージ装置と前記ホスト計算機との組で構成されるリモートサイトとを有し、前記プライマリサイトと前記リモートサイトとは地理的に離れた位置に配置され、
   前記構成情報には、前記プライマリサイトの前記正ボリュームのコピーペアのステータス及び前記リモートサイトの前記副ボリュームのコピーペアのステータスが含まれ、
   前記管理計算機は、
   前記プライマリサイト及び前記リモートサイトを監視する監視設定として、前記コピーペアのステータスに応じて、前記プライマリサイトの前記正ボリュームまたは前記リモートサイトの前記副ボリュームに対して、前記コピーペアのステータスに関する監視条件を設定し、
   前記コピーペアのステータスが前記監視設定に設定された前記コピーペアのステータスに関する監視条件を満たしていない場合に、前記コピーペアのステータスに変更があるとして、変更後の前記コピーペアのステータスを取得し、該コピーペアのステータスに応じて、前記プライマリサイトの前記正ボリュームまたは前記リモートサイトの前記副ボリュームにそれぞれ対応する前記コピーペアのステータスに関する監視条件の設定を変更する
   ことを特徴とするストレージシステム。
2. 前記管理計算機は、前記コピーペアのステータスの変更が予め前記監視設定に設定された範囲内の変更であった場合は前記コピーペアのステータスに対応して設定された前記監視条件に変更し、前記コピーペアのステータスの変更が予め前記監視設定に設定された範囲内の変更でない場合は前記管理計算機の管理者にその旨を報知する
   ことを特徴とする請求項１に記載のストレージシステム。
3. 前記１台以上のホスト計算機は、１台の物理的なホスト計算機上で仮想的なホスト計算機として稼動する、複数の仮想的なホスト計算機を含むことを特徴とする
   請求項１に記載のストレージシステム。
4. １台以上のストレージ装置と、前記１台以上のストレージ装置へデータのリード／ライトを行う１台以上のホスト計算機と、前記１台以上のホスト計算機を管理する管理計算機とを含むストレージシステムの監視条件変更方法であって、
   前記１台以上のストレージ装置それぞれは、データを格納する１つ以上のディスク装置と、前記１つ以上のディスク装置が提供する記憶領域により構成される、複数のボリュームとを有し、
   前記１台以上のホスト計算機は、前記複数のボリュームのうちの所定数のボリュームで構成されるボリュームグループの構成情報を管理し、
   前記１台以上のストレージ装置のうちの１台以上のストレージ装置と、前記１台以上のホスト計算機のうちの１台以上のホスト計算機と含んで構成される、複数のサイトを有し、
   前記ボリュームグループの構成は、前記複数のボリュームのうちの１つのボリュームを前記１台以上のホスト計算機のいずれかからデータライトされる正ボリュームとし、前記正ボリュームでないボリュームを前記正ボリュームに書き込まれたデータのコピー先である副ボリュームとするコピーペアの構成であり、
   前記正ボリュームを備える前記ストレージ装置と前記ホスト計算機との組で構成されるプライマリサイトと、前記副ボリュームを備える前記ストレージ装置と前記ホスト計算機との組で構成されるリモートサイトとを有し、前記プライマリサイトと前記リモートサイトとは地理的に離れた位置に配置され、
   前記構成情報には、前記プライマリサイトの前記正ボリュームのコピーペアのステータス及び前記リモートサイトの前記副ボリュームのコピーペアのステータスが含まれ、
   前記管理計算機が、前記プライマリサイト及び前記リモートサイトを監視する監視設定として、前記コピーペアのステータスに応じて、前記プライマリサイトの前記正ボリュームまたは前記リモートサイトの前記副ボリュームに対して、前記コピーペアのステータスに関する監視条件を設定するステップと、
   前記管理計算機が、前記コピーペアのステータスが前記監視設定に設定された前記コピーペアのステータスに関する監視条件を満たしていない場合に、前記コピーペアのステータスに変更があるとして、変更後の前記コピーペアのステータスを取得するステップと、
   前記管理計算機が、該コピーペアのステータスに応じて、前記プライマリサイトの前記正ボリュームまたは前記リモートサイトの前記副ボリュームにそれぞれ対応する前記コピーペアのステータスに関する監視条件の設定を変更するステップと
   を含むことを特徴とするストレージシステムの管理条件変更方法。
5. 前記管理計算機が、前記コピーペアのステータスの変更が予め前記監視設定に設定された範囲内の変更であった場合は前記コピーペアのステータスに対応して設定された前記監視条件に変更するステップと、
   前記管理計算機が、前記コピーペアのステータスの変更が予め前記監視設定に設定された範囲内の変更でない場合は前記管理計算機の管理者にその旨を報知するステップと
   を含むことを特徴とする請求項４に記載のストレージシステムの管理条件変更方法。
6. データを格納する１つ以上のディスク装置と、前記１つ以上のディスク装置が提供する記憶領域により構成される、複数のボリュームとを、それぞれ有する１台以上のストレージ装置と、
   前記１台以上のストレージ装置へデータのリード／ライトを行うとともに、前記複数のボリュームのうちの所定数のボリュームで構成されるボリュームグループの構成情報を管理する、１台以上のホスト計算機と、
   を含むストレージシステムにおいて前記１台以上のストレージ装置及び前記１台以上のホスト計算機を管理する管理計算機であって、
   前記ボリュームグループの構成は、前記複数のボリュームのうちの１つのボリュームを前記１台以上のホスト計算機のいずれかからデータライトされる正ボリュームとし、前記正ボリュームでないボリュームを前記正ボリュームに書き込まれたデータのコピー先である副ボリュームとするコピーペアの構成であり、
   前記正ボリュームを備える前記ストレージ装置と前記ホスト計算機との組で構成されるプライマリサイトと、前記副ボリュームを備える前記ストレージ装置と前記ホスト計算機との組で構成されるリモートサイトとを有し、前記プライマリサイトと前記リモートサイトとは地理的に離れた位置に配置され、
   前記構成情報には、前記プライマリサイトの前記正ボリュームのコピーペアのステータス及び前記リモートサイトの前記副ボリュームのコピーペアのステータスが含まれ、
   前記管理計算機は、
   前記プライマリサイト及び前記リモートサイトを監視する監視設定として、前記コピーペアのステータスに応じて、前記プライマリサイトの前記正ボリュームまたは前記リモートサイトの前記副ボリュームに対して、前記コピーペアのステータスに関する監視条件を設定し、
   前記コピーペアのステータスが前記監視設定に設定された前記コピーペアのステータスに関する監視条件を満たしていない場合に、前記コピーペアのステータスに変更があるとして、変更後の前記コピーペアのステータスを取得し、該コピーペアのステータスに応じて、前記プライマリサイトの前記正ボリュームまたは前記リモートサイトの前記副ボリュームにそれぞれ対応する前記コピーペアのステータスに関する監視条件の設定を変更する
   ことを特徴とする管理計算機。
7. 前記コピーペアのステータスの変更が予め前記監視設定に設定された範囲内の変更であった場合は前記コピーペアのステータスに対応して設定された前記監視条件に変更し、前記コピーペアのステータスの変更が予め前記監視設定に設定された範囲内の変更でない場合は前記管理計算機の管理者にその旨を報知する
   ことを特徴とする請求項６に記載の管理計算機。
   

Images