(57)【要約】      （修正有）【課題】アプリケーションとその障害内容に応じて、バックアップの停止・継続を決定する方法を提供する。【解決手段】ストレージ管理プログラム２１１０に、障害時動作管理テーブル２１０９に基づきリモートバックアップの停止、継続を判断する機能を備え、障害が発生したアプリケーションおよびその障害内容に基づくバックアップの停止、継続を実現する。また、障害発生前最後のバックアップを行った時刻から障害発生後最初のバックアップを行う時刻までのデータ変更量を計算し、バックアップの停止、継続を判断する機能を備え、アプリケーション稼動状況に合わせたバックアップの停止、継続を実現できる。【選択図】図４
2011039804.tif 000002
【特許請求の範囲】
【請求項１】
メモリ及び
前記メモリの有するプログラムを実行するCPU
を備え、
アプリケーションを有するホスト計算機及び
前記アプリケーションが利用するボリュームを提供するディスク装置を有し、前記ボリュームのバックアップを行うストレージシステム
に接続された計算機であって、
前記メモリは、
障害時操作管理情報及び
ストレージ管理プログラムを有し、
前記障害時動作管理情報は、
前記アプリケーションの識別子、前記アプリケーションで発生する障害種別の識別子及び前記障害種別に対する前記バックアップの動作を示す障害時動作を対応付ける情報であり、
前記ストレージ管理プログラムは、
前記アプリケーションに障害があった場合、前記ホスト計算機から、障害が起こったアプリケーションの識別子及び障害の種別を含む障害通知を受信し、
前記障害通知及び前記障害時動作管理情報を参照し、前記障害が起こったアプリケーションに対する障害時の動作を決定し、
前記ストレージシステムに前記決定した障害時の動作を実行させる命令を送信する
ことを特徴とする管理計算機。
【請求項２】
請求項1記載の管理計算機であって、
前記障害時動作管理情報は、
前記障害種別の動作について、アプリケーションに起こった障害に対応する優先の度合いを示した値である優先度を含み、
前記ストレージ管理プログラムは、
前記障害時の動作を決定する際、前記障害時動作管理情報を参照し、前記優先度の一番高い動作を障害時の動作として決定する
ことを特徴とする管理計算機。
【請求項３】
請求項2記載の管理計算機であって、前記アプリケーションに障害が複数起こった場合、
前記ストレージ管理プログラムは、前記複数起こった障害の優先度が予め定められた値を超えた場合に、前記ストレージシステムに障害時の動作としてバックアップを停止させる命令を送信することを特徴とする管理計算機。
【請求項４】
請求項1記載の管理計算機であって、
前記ストレージ管理プログラムは、前記ストレージシステムに前記決定した障害時の動作としてバックアップを停止させる命令を送信したあと、前記ストレージシステムから前記障害が起こったアプリケーションの利用するボリュームが回復した通知を受信した場合、前記障害が起こったアプリケーションの利用するボリュームのバックアップを実行させる命令を送信することを特徴とする管理計算機。
【請求項５】
請求項1記載の管理計算機であって、
前記障害種別は、ウィルスの検出、ウィルスの感染、テーブル破壊及び静止化失敗を含むことを特徴とする管理計算機。
【請求項６】
請求項5記載の管理計算機であって、
前記バックアップ管理情報は、さらに、前記アプリケーションが利用するボリュームの識別子を有し、
前記障害が起こったアプリケーションの障害がウィルスの感染であった場合、
前記障害通知は、前記ウィルスの感染の影響のあるボリュームの識別子を有し、
前記ストレージ管理プログラムは、
前記ウィルスの感染の影響のあるボリュームであって、前記障害が起こったアプリケーションの利用するボリューム以外のボリュームについて、前記障害通知及び前記バックアップ管理テーブルを参照して障害時の動作を決定する
ことを特徴とする管理計算機。
【請求項７】
請求項6記載の管理計算機であって、
前記障害時動作管理情報は、さらに、データの変更量を示す条件を有し、
前記障害時動作管理情報の前記障害種別がテーブル破壊の場合、前記条件ごとに対応付けられた前記障害時動作を有し、
前記障害通知は、さらに、前記アプリケーションの障害発生前に最後のバックアップを行ったときから障害発生後最初のバックアップを行うときまでのデータの変更量を含む
ことを特徴とする管理計算機。
【請求項８】
請求項1記載の管理計算機であって、
前記メモリは、さらに、バックアップ管理情報及びペア管理情報を有し、
バックアップ管理情報は、
前記アプリケーションの識別子、前記バックアップのペアを特定するペアの識別子及び前記アプリケーションが利用するボリュームがバックアップを行うか否かを示すバックアップ状態を含み、
前記ペア管理情報は、
前記ストレージシステムで行われるバックアップについて、前記ストレージシステムの識別子、前記ペアの識別子、バックアップ元のボリュームの識別子及びバックアップ先のボリュームの識別子を含み、
前記ストレージ管理プログラムは、
前記ストレージシステムに決定した障害時の動作を実行させる命令を送信する際、前記バックアップ管理情報及び前記ペア管理情報を参照する
ことを特徴とする管理計算機。
【請求項９】
請求項8記載の管理計算機であって、
前記管理計算機に接続するストレージシステムは複数であり、
前記バックアップ管理情報は、さらに、前記ストレージシステムで行われるバックアップの種類がローカルバックアップかリモートバックアップかを示すバックアップ種別を含むことを特徴とする管理計算機。
【請求項１０】
請求項9記載の管理計算機であって、
前記バックアップ管理情報は、
前記バックアップ種別がローカルバックアップである第1のエントリ及び
バックアップ元の識別子が前記第1のエントリのバックアップ先の識別子と同一であって、バックアップ種別がローカルバックアップである第2のエントリ
を含むことを特徴とする管理計算機。
【請求項１１】
請求項9記載の管理計算機であって、
前記バックアップ管理情報は、さらに、バックアップが同期か非同期かを示す転送モードを有し、
前記障害時動作管理情報は、さらに、前記バックアップ種別及び前記転送モードのを有することを特徴とする管理計算機。
【請求項１２】
請求項9記載の管理計算機であって、
前記バックアップ管理情報は、
前記バックアップ種別がリモートバックアップであるエントリを含み、
前記バックアップ種別がローカルバックアップであるエントリを含まない
ことを特徴とする管理計算機。
【請求項１３】
請求項8記載の管理計算機であって、
前記障害時動作は、バックアップの継続、停止及び前記ペア管理情報にあるバックアップ先と異なるバックアップ先にバックアップを行う一時ボリュームバックアップを含むことを特徴とする管理計算機
【請求項１４】
請求項3、7、10、12又は13のうちいずれかに記載の管理計算機であって、
前記ストレージ管理プログラムは、
前記ストレージシステムに前記決定した障害時の動作を実行させる命令を送信したあと、前記ホスト計算機に前記命令の内容の通知を送信することを特徴とする管理計算機。
【請求項１５】
請求項14記載の管理計算機であって、
前記ホスト計算機に通知する命令の内容は、バックアップの種別が変更されたボリュームの識別子を含むことを特徴とする管理計算機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、論理障害発生時のバックアップ方法に関する。
【背景技術】
【０００２】
計算機システムでは、一般に、ユーザ誤操作やコンピュータウィルスなどによるデータ破壊といった論理障害に備え、データを複製して保存する「バックアップ」を実施する。また、オリジナルのデータに障害が発生した時には、バックアップデータを使ってデータを復旧する「リストア」を行う。通常、バックアップは、データ整合性を保証するために、データを利用するアプリケーションを静止化した上で行う。
【０００３】
特許文献1には、データをリモートストレージにバックアップするリモートバックアップに関する技術が記載されている。リモートバックアップにより、一方のストレージに記憶されているデータに障害が発生しても他方のストレージにデータが残っているのでデータの損失を防止することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2003−242011
【発明の概要】
【発明が解決しようとする課題】
【０００５】
データの可用性を向上させるために、あるデータのバックアップデータをさらにバックアップすることがある。例えば、あるデータをローカルストレージにバックアップし、さらにそのバックアップデータをリモートストレージにバックアップする。なお、ここでは、オリジナルのデータのバックアップを一次バックアップ、一次バックアップによって作成されたバックアップデータのバックアップを二次バックアップと呼ぶことにする。
【０００６】
このような環境では、一次バックアップと二次バックアップをそれぞれ異なるユーザが管理することがある。例えば、一次バックアップは、アプリケーションの稼動状況を考慮してアプリケーションを静止化して行う必要があるため、業務アプリケーションが動作するホスト計算機を管理するユーザが管理する。一方、二次バックアップは、ストレージシステムを管理するユーザが管理する。加えて、外部組織が管理しているストレージをリモートストレージとして利用する場合など、二次バックアップによって作成されたバックアップデータを格納可能なボリュームの数が制限されている場合がある。
【０００７】
上記環境では、データが壊れるなどの理由により、データを使用するアプリケーションに論理障害が発生すると、アプリケーションやその障害内容に応じて、二次バックアップの停止、継続を判断する必要がある。例えば、ウィルス感染により全てのデータが破壊されるといった重大な障害が発生した場合には、障害前に作成されたバックアップデータを残すために二次バックアップを停止するかもしれない。一方、テスト用アプリケーションが使用しているデータなど、業務と無関係なデータが壊れた程度の些細な障害であれば、二次バックアップを継続するかもしれない。また、障害発生前最後の二次バックアップを行った時点から障害発生後最初の二次バックアップを行う時点までにアプリケーションがフル稼働しておりデータの更新量が多いと判断した場合には、更新データのバックアップを優先して、バックアップを継続するかもしれない。
【０００８】
しかし、従来技術では、先の環境で障害が発生しても、アプリケーションやその障害内容、及びアプリケーション稼働状況に関わらず、バックアップを停止するか継続することしかできなかった。このため、軽微な障害にも関わらずバックアップを停止してしまったり、重大な障害であるにも関わらずバックアップを継続してしまったりすることがあった。
【０００９】
本発明の目的は、アプリケーションとその障害内容に応じて、バックアップの停止・継続を決定する方法を提供することにある。
【００１０】
また、本発明の他の目的は、障害発生前最後のバックアップ時点から障害発生後最初のバックアップ時点までのアプリケーション稼動状況に応じて、バックアップの停止・継続を決定する方法を提供することにある。
【課題を解決するための手段】
【００１１】
本発明は、ストレージ管理プログラムに、障害時動作管理の処理を示した情報に基づきリモートバックアップの停止、継続を判断する機能を備えることによって、障害が発生したアプリケーションおよびその障害内容に基づくバックアップの停止、継続可能とする。
【００１２】
また、本発明では、ストレージ管理プログラムにデータ変更量計算プログラムをさらに備え、ストレージ管理プログラムが障害発生通知を受信すると、障害発生前最後のリモートバックアップを行った時刻から障害発生後最初のリモートバックアップを行う時刻までのデータ変更量を計算し、計算結果に基づきリモートバックアップの停止、継続を判断する。
【発明の効果】
【００１３】
本発明によれば、障害が発生したアプリケーションとその障害内容にあわせてバックアップの停止・継続を決定することができる。
【００１４】
また、本発明によれば、バックアップを停止したときに生じる影響の度合いにあわせてバックアップの停止・継続を決定することができる。
【図面の簡単な説明】
【００１５】
【図１】実施例1の計算機システムの構成を示す図
【図２】実施例1のバックアップ構成を示す図
【図３】実施例1のストレージシステムの構成を示す図
【図４】実施例1の管理計算機の構成を示す図
【図５】実施例1のホスト計算機の構成を示す図
【図６】実施例1のストレージ管理テーブルの構造を示す図
【図７】実施例1のボリューム管理テーブルの構造を示す図
【図８】実施例1のアプリケーション管理テーブルの構造を示す図
【図９】実施例1のバックアップ管理テーブルの構造を示す図
【図１０】実施例1のローカルバックアップポリシ管理テーブルの構造を示す図
【図１１】実施例1のリモートバックアップポリシ管理テーブルの構造を示す図
【図１２】実施例1のローカルバックアップペア管理テーブルの構造を示す図
【図１３】実施例1のリモートバックアップペア管理テーブルの構造を示す図
【図１４】実施例1の障害時動作管理テーブルの構造を示す図
【図１５】実施例1のアプリケーションに障害が発生したときの処理シーケンスを示す図
【図１６】実施例1のアプリケーションに障害が発生したときのストレージ管理プログラムの処理フローを示す図
【図１７】実施例1のローカルバックアップ設定画面を示す図
【図１８】実施例1のリモートバックアップ設定画面を示す図
【図１９】実施例1の障害時動作設定画面を示す図
【図２０】実施例1の優先度設定画面を示す図
【図２１】実施例1のローカルバックアップ処理フローを示す図
【図２２】実施例1のローカルバックアップ処理フローを示す図
【図２３】実施例1のアプリケーションに障害が発生したときのストレージ管理プログラムの処理フローを示す図
【図２４】実施例2のストレージシステムの構成を示す図
【図２５】実施例2の管理計算機の構成を示す図
【図２６】実施例2の障害時動作管理テーブルの構造を示す図
【図２７】実施例2のアプリケーションに障害が発生したときの処理シーケンスを示す図
【図２８】実施例2のアプリケーションに障害が発生したときのストレージ管理プログラムの処理フローを示す図
【図２９】実施例3の障害時動作管理テーブルの構造を示す図
【図３０】実施例3のアプリケーションに障害が発生したときのストレージ管理プログラムの処理フローを示す図
【図３１】実施例3のストレージ管理プログラムの一時ボリュームへのバックアップ処理に関するストレージ管理プログラムの処理フローを示す図
【発明を実施するための形態】
【００１６】
以下、本発明を、図面を用いて説明する。
【実施例１】
【００１７】
図1は、実施例1の計算機システム1の構成の一例を示す図である。同図に示すように、計算機システム1は、ストレージネットワーク50を介して相互に接続された複数のホスト計算機30ａ、30b及び複数のストレージシステム10ａ、10ｂを含んで構成される。計算機システム1はまた、管理ネットワーク40を介して複数のストレージシステム10ａ、10ｂのそれぞれに接続された管理計算機20を含んでいる。計算機システム1は、例えば、銀行の業務システムや航空機の座席予約業務システム等がある。
【００１８】
ストレージネットワーク50は、主として、ホスト計算機30ａ、30bとストレージシステム10ａ、10ｂとの間のＩＯ要求に基づく通信に使用されるネットワークシステムである。ストレージネットワーク50はまた、ストレージシステム30ａ、30b間のリモートバックアップに基づく通信にも使用される。ストレージネットワーク50には、例えばＬＡＮ、又はＳＡＮ（Storage Area Network）であり、典型的には、ネットワークスイッチやハブ等を含んで構成される。本実施形態では、ストレージネットワーク50は、ファイバーチャネルプロトコルベースのＳＡＮ（ＦＣ−ＳＡＮ）で構成されているものとする。
【００１９】
管理ネットワーク40は、管理計算機20がホスト計算機30ａ、30b及びストレージシステム10ａ、10ｂを管理する際の通信に使用されるネットワークである。本実施形態では、管理ネットワーク40は、ＩＰプロトコルベースのＬＡＮで構成されているものとする。ただし、これは、ストレージネットワーク50と管理ネットワーク40とが物理的に常に別個のものとして構成されることを意味するものではない。例えば、ストレージネットワーク50がＩＰプロトコルベースのネットワークで構成された場合には、両者は一つのネットワークシステム上に形成してもよい。
【００２０】
図2は、実施例1のバックアップ構成の一例を示した図である。図2の例では、アプリケーションＡＰ01は、ストレージシステム1のボリュームＶＯＬ01を使用しており、該ボリュームに格納されたデータはボリュームＶＯＬ11にローカルバックアップしている。さらに、ボリュームＶＯＬ01のデータをバックアップしたデータを記憶するボリュームＶＯＬ11をストレージシステム2のボリュームＶＯＬ01にリモートバックアップしている。また、アプリケーションＡＰ02、ＡＰ03は、ストレ−ジシステム1のボリュームＶＯＬ02を使用しており、該ボリュームはボリュームＶＯＬ12にローカルバックアップしている。さらに、ボリュームＶＯＬ02のデータをバックアップしたデータを記憶するボリュームＶＯＬ12をストレージシステム2のボリュームＶＯＬ02にリモートバックアップしている。すなわち、ローカルバックアップとは、同一のストレージ内で行うデータのバックアップであり、リモートバックアップとは、異なるストレージに対して行うデータのバックアップである。このようなバックアップを行っているとき、例えば本図に示すようにホスト計算機のＡＰ01で障害が発生すると、バックアップを継続するか停止するかを障害の内容に基づいて決定する。
【００２１】
図3は、実施例1のストレージシステム10ａの構成の一例を示す図である。ストレージシステム10ａは、コントローラ110及びディスク装置120を備える。
【００２２】
ディスク装置120は、ホスト計算機30ａ、30ｂから書き込み要求されたデータを記憶する。ディスク装置120に変えて、フラッシュメモリドライブなどの記憶デバイスが採用されてもよい。
【００２３】
コントローラ110は、ストレージシステム10ａ全体を制御する。具体的には、コントローラ110は、ディスク装置120へのデータの書き込み及びディスク装置120からのデータの読み出しを制御する。また、コントローラ110は、ディスク装置120の記憶領域を、一つ以上の論理ボリューム121としてホスト計算機30ａ、30bに提供する。なお、ディスク装置120は複数存在してもよく、典型的には、大容量化、高信頼化等の観点から、ＲＡＩＤ（Redundant Arrays of Independence Disks）技術を用いて、複数のディスク装置120から論理ボリューム121を構成する。以下、論理ボリュームを単にボリュームと呼ぶ。
【００２４】
コントローラ110は、同図に示すように、プロセッサ111、制御メモリ112、キャッシュメモリ113、データインターフェース114、ディスクインターフェース115、管理インターフェース116を備え、これらのコンポーネントは、内部ネットワーク117を介して相互に接続されている。これらコンポーネントは、冗長化構成により、それぞれ多重化されていてもよい。
【００２５】
プロセッサ111は、制御メモリ112に記憶される制御プログラム1121を実行することによって各種処理を行う。
【００２６】
制御メモリ112には、プロセッサ111によって実行される制御プログラム1121及びプロセッサ111によって必要とされる管理情報群1122が記憶される。具体的には、制御プログラム1121には、データインターフェース114が受信したＩＯ要求を処理するプログラム、ディスク装置120へのデータ書き込み及びディスク装置120からのデータ読み出しを制御するプログラム、一以上のディスク装置120の記憶領域からボリューム121を設定するプログラム、ローカルバックアップおよびリモートバックアップを制御するプログラムが含まれる。管理情報群1122には、複数のボリューム121間の関係を示す情報が含まれる。複数のボリューム121の関係を示す情報には、ボリューム121の種別を示す情報、ボリューム121に記憶されたデータをどのボリューム121にローカルバックアップするかを示す情報、及びボリューム121に記憶されたデータをどのボリューム121にリモートバックアップするかを示す情報を含む。
【００２７】
キャッシュメモリ113は、ディスク装置120へ書き込まれるデータ及びディスク装置120から読み出されるデータを一時的に記憶する。
【００２８】
データインターフェース114は、ストレージネットワーク50を介して接続されたホスト計算機30ａ、30b 及び他のストレージシステム10bとの間で通信を行うためのインターフェースである。具体的には、データインターフェース114は、ホスト計算機30ａ、30b からのＩＯ要求(例えば、リード要求及びライト要求)を受信したり、ディスク装置120から読み出されたデータを、ホスト計算機30ａ、30bに送信したりするのに使われる。さらに、リモートバックアップ実施時には、データインターフェース114は、ストレージシステム10ａ、10b間で交換されるデータを送受信するのに使われる。
【００２９】
ディスクインターフェース115は、内部ネットワーク117を介して接続されたディスク装置120との間で通信を行うためのインターフェースである。例えば、ディスクインターフェース115は、キャッシュメモリ113に格納されたデータを取り出して、ディスク装置120に格納したり、ディスク装置120からデータを読み出して、キャッシュメモリ113に書き込んだりするのに使われる。
【００３０】
管理インターフェース116は、管理ネットワーク40を介して接続された管理計算機20との間で通信を行うためのインターフェースである。例えば、管理インターフェース116は管理計算機20からの指示(例えば、バックアップ指示)を受信するのに使われる。
【００３１】
ストレージシステム10bの構成は、ストレージシステム10aと同じため、説明を省略する。ただし、ストレージシステム10aとストレージシステム10bは、運用上、異なる役割が割り当てられる。すなわち、ストレージシステム10ａは、通常の運用時に稼働するストレージシステムであり、ストレージシステム10ｂは、ストレージシステム10ａに格納されたデータの損失に備えて、ストレージシステム10aのデータをバックアップしておくためのストレージシステムである。
【００３２】
図4は、実施例1の管理計算機20の構成の一例を示す図である。管理計算機20は、ストレージシステム10ａ、10bを管理するためのコンピュータであって、メモリ210、プロセッサ220及び管理インタフェース230を備える計算機である。メモリ210、プロセッサ220、及び管理インタフェース230は、内部ネットワーク(図示省略)によって相互接続される。
【００３３】
プロセッサ220は、メモリ210に記憶されるプログラムを実行することによって各種処理を行う。
【００３４】
メモリ210には、プロセッサ220によって実行されるプログラム及びプロセッサ220によって必要とされるテーブルが記憶される。具体的には、メモリ210には、ストレージ管理テーブル2101、アプリケーション管理テーブル2102、ボリューム管理テーブル2103、バックアップ管理テーブル2104、ローカルバックアップポリシ管理テーブル2105、リモートバックアップポリシ管理テーブル2106、ローカルバックアップペア管理テーブル2107、リモートバックアップペア管理テーブル2108、障害時動作管理テーブル2109、ストレージ管理プログラム2110が記憶される。さらに、メモリには、ＯＳ(Operating System)2111が記憶される。ＯＳ2111は、管理計算機20の処理の全体を制御するプログラムである。なお、各テーブルは、図6から図14で詳細に説明する。
【００３５】
なお、以下でメモリが有する情報の保持する形態はテーブルとして説明するが、例えばリストなど、保持する形態はテーブルに限られない。
【００３６】
管理計算機20は、プロセッサ220の制御の下、ＯＳ2111上でのストレージ管理プログラム2110を実行することで、ストレージシステム10ａ、10bを管理するためのユーザインターフェースをユーザに提供し、ユーザの操作を介して、ストレージシステム10ａ、10bに対する設定や実行指示、運用状況の監視といった管理を行う。例えば、ユーザが前もってバックアップスケジュールを登録しておくと、ストレージ管理プログラム2110は、スケジュールされた時刻にローカルバックアップあるいはリモートバックアップの指示をストレージシステム10ａ上の制御プログラム1121に送信する。
【００３７】
図5は、実施例1のホスト計算機30ａの構成の一例を示す図である。ホスト計算機30ａは、例えば、銀行の業務システムや航空機の座席予約業務システム等の中核をなすコンピュータであって、メモリ310、プロセッサ320、データインターフェース330、及び管理インターフェース340を備える計算機である。メモリ310、プロセッサ320、データインターフェース330、及び管理インターフェース340は、内部ネットワーク(図示省略)によって相互接続される。
【００３８】
メモリ310には、プロセッサ320によって実行されるプログラム及びプロセッサ320によって必要とされるテーブルが記憶される。具体的には、メモリ310には、アプリケーション3101、障害検知プログラム3102、アプリケーション管理プログラム3103、ＯＳ3104が記憶される。
【００３９】
アプリケーション3101は、ボリューム121に記憶されたデータを利用するプログラムであって、ボリューム121に対するデータ書き込みやボリューム121からのデータ読み出しを行う。例えば、アプリケーション3101には、データベースを管理するアプリケーションプログラムや、コンピュータウィルスの検知、駆除を行うアプリケーションプログラムなどがある。
【００４０】
障害検知プログラム3102は、アプリケーション3101の障害発生有無を検証し、障害を検知すると、障害が発生したアプリケーションおよびその障害内容をストレージ管理プログラム2110に通知するプログラムである。障害検知プログラム3102は、例えば、アプリケーション3101の動作ログを参照することで障害を検知する。ログを参照することで、アプリケーションがファイルのオープンに失敗していたなどの障害情報を得ることができ、そのような情報からデータが壊れていることが予想でき、該データを含むバックアップ先ボリュームのデータも壊れていると判定できる。
【００４１】
なお、ストレージ管理プログラム2110への障害通知方法は本実施例であげた方法に限らず、電子メール等を使って通知してもよい。
【００４２】
アプリケーション管理プログラム3103は、アプリケーション3101が使用するボリューム121に記憶されたデータをローカルバックアップするとき、およびボリューム121に記憶されたデータをリストアするとき、アプリケーション3101の動作を制御するプログラムである。例えば、アプリケーション管理プログラム3103は、ボリューム121に記憶されたデータをバックアップするときに、アプリケーション3101の動作を静止する。
【００４３】
また、アプリケーション管理プログラム3103は、アプリケーション3101が使用するボリューム121を識別する情報を収集し、収集した情報をストレージ管理プログラム2110に送信する。
【００４４】
ホスト計算機30bの構成は、ホスト計算機30aと同じであるため説明を省略する。  また、管理計算機、ホスト計算機は、それぞれ入力装置(図示省略)を有する。
【００４５】
図6は、実施例1のストレージ管理テーブル2101の一例を示す図である。ストレージ管理テーブル2101は、管理計算機20が管理するストレージシステム10ａ、10ｂのネットワークアドレスを管理するテーブルである。ストレージ管理テーブル2101の各エントリは、ストレージＩＤ欄21011およびＩＰアドレス欄21012を含む。ストレージＩＤ欄21011には、管理計算機20に接続されるストレージシステムの一意な識別子が登録される。ＩＰアドレス欄には、ストレージＩＤ欄21011に登録されたストレージシステムの識別子によって識別されるストレージシステムの管理インターフェースに付与されたネットワークアドレスが登録される。
【００４６】
なお、ストレージ管理テーブル2101の各欄には、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。
【００４７】
図7は、実施例1のボリューム管理テーブル2103の一例を示す図である。ボリューム管理テーブル2103は、管理計算機20が管理するストレージシステム10ａ、10ｂが備えるボリューム121に関する情報を管理するテーブルである。ボリューム管理テーブル2103の各エントリは、ストレージＩＤ欄21031、ボリュームＩＤ欄21032、容量欄21033、使用有無欄21034を含む。ストレージＩＤ欄21031には、ストレージシステムの一意な識別子が登録される。ボリュームＩＤ欄21032には、ストレージＩＤ欄21032に登録されたストレージシステムの識別子によって識別されるストレージシステムが備えるボリュームの一意な識別子が登録される。容量欄21033には、ストレージＩＤ欄21031ならびにボリュームＩＤ欄21032に登録された識別子によって識別されるボリュームの容量が登録される。使用有無欄21034にはストレージＩＤ欄21031ならびボリュームＩＤ欄21032に登録された識別子によって識別されるボリュームが使用されているか否かを示す情報が登録される。
【００４８】
なお、ボリューム管理テーブル2103の各欄には、ストレージ管理テーブル2101に登録されたストレージシステムが備える制御プログラムから取得したデータが登録される。
【００４９】
図8は、実施例1のアプリケーション管理テーブル2102の一例を示す図である。アプリケーション管理テーブル2102は、管理計算機20が管理するホスト計算機30ａ、30ｂ上で動作するアプリケーション3101と、アプリケーション3101が利用するボリューム121との関係を管理するテーブルである。
【００５０】
アプリケーション管理テーブル2102の各エントリは、アプリケーションＩＤ欄21021、ＩＰアドレス欄21022、ストレージＩＤ欄21023、及びボリュームＩＤ欄21024を含む。アプリケーションＩＤ欄21021には、ホスト計算機上で動作するアプリケーションの一意な識別子が登録される。ＩＰアドレス欄21022には、該アプリケーションの識別子によって識別されるアプリケーションが動作するホスト計算機の管理インターフェースに付与されたネットワークアドレスが登録される。ストレージＩＤ欄21023には、該アプリケーションの識別子によって識別されるアプリケーションが使用するボリュームを備えるストレージシステムの一意な識別子が登録される。ボリュームＩＤ欄21024には、該アプリケーションの識別子によって識別されるアプリケーションが使用するボリュームの一意な識別子が登録される。
【００５１】
なお、アプリケーションＩＤ欄21021、及びＩＰアドレス欄21022は、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。ストレージＩＤ欄21023、及びボリュームＩＤ欄21024には、ユーザが設定したアプリケーションの識別子によって識別されるアプリケーションが使用するボリュームの識別子、及び該ボリュームが属するストレージシステムの識別子が設定される。これらの識別子は、ユーザが設定したＩＰアドレスが付与されているホスト計算機から取得する。
【００５２】
図9は、実施例1のバックアップ管理テーブル2104の一例を示す図である。バックアップ管理テーブル2104は、アプリケーション3101が使用するボリュームのバックアップ状態を管理するテーブルである。
【００５３】
バックアップ管理テーブル2104の各エントリは、アプリケーションＩＤ欄21041、バックアップ種別欄21042、ポリシＩＤ欄21043、バックアップ状態欄21044を含む。アプリケーションＩＤ欄21041には、ホスト計算機上で動作するアプリケーションの一意な識別子が登録される。バックアップ種別欄21042には、該アプリケーションの識別子によって識別されるアプリケーションが使用するボリュームをローカルバックアップするか、さらにリモートバックアップするかを識別する識別子を登録する。具体的には、ローカルバックアップを行う場合には「ローカル」、ローカルバックアップしたデータをさらにリモートバックアップする場合には「リモート」と登録する。ポリシＩＤ欄21043には、バックアップ種別が「ローカル」の場合にはローカルバックアップポリシの一意な識別子を登録し、バックアップ種別が「リモート」の場合にはリモートバックアップポリシの一意な識別子を登録する。なお、各ポリシについては、図10、図11で説明する。
【００５４】
バックアップ状態欄21044には、ポリシ欄21043に登録されたポリシに基づくバックアップを有効とするか無効とするかを識別する識別子が登録され、バックアップを有効とする場合には「有効」、無効とする場合には「無効」と登録する。「有効」と登録されている場合、ストレージ管理プログラム2110は、バックアップ種別欄21042およびポリシＩＤ欄21043に登録されている識別子によって識別されるポリシに設定された時刻になると、該ポリシに設定されたペアに対するバックアップ指示をストレージシステム10ａ上の制御プログラム1121に送信する。
【００５５】
なお、エントリのバックアップ状態欄21044に変更があった場合、エントリに設定されたペアに対して、バックアップの状態を変更された内容にするバックアップ指示をストレージシステム10a上の制御プログラム1121に送信してもよい。
【００５６】
また、バックアップ管理テーブル2104の各欄は、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。詳細は図17、18で説明する。
【００５７】
また、バックアップのペアを特定するペアID欄を有し、ストレージ管理プログラム2110がバックアップ管理テーブルを参照するだけでバックアップのペアを特定できるようにしてもよい。
【００５８】
図9の例では、アプリケーションの識別子がAP01であるアプリケーションが使用しているボリュームのデータは、ポリシの識別子がLP01であるローカルバックアップポリシに従いローカルバックアップが行われる。また、ローカルにバックアップされたバックアップデータは、ポリシＩＤがRP01であるリモートバックアップポリシに従いリモートにバックアップされる。
【００５９】
図10は、実施例1のローカルバックアップポリシ管理テーブル2105の一例を示す図である。ローカルバックアップポリシ管理テーブル2105は、ローカルバックアップを実施する際のバックアップペアおよびスケジュールの関係(ポリシ)を管理するテーブルである。
【００６０】
ローカルバックアップポリシ管理テーブル2105の各エントリは、ローカルバックアップポリシＩＤ欄21051、ペアＩＤ欄21052、スケジュール欄21053を含む。ローカルバックアップポリシＩＤ欄21051には、ローカルバックアップポリシの一意な識別子が登録される。ペアＩＤ欄21052には、ローカルバックアップペア管理テーブル2107によって管理されるバックアップ元ボリュームおよびバックアップ先ボリュームのペアに付された一意な識別子が登録される。スケジュール欄21053には、バックアップを開始する日時、曜日、時刻といったスケジュール情報が登録される。
【００６１】
なお、ローカルバックアップポリシ管理テーブル2105の各欄は、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。詳細は、図17で説明する。
【００６２】
図10の例では、毎日00:00になると、ペアＩＤがPAIR01であるペアを構成するバックアップ元ボリュームのデータが、同じくペアＩＤがPAIR01であるペアを構成するバックアップ先ボリュームにバックアップされる。
【００６３】
図11は、実施例1のリモートバックアップポリシ管理テーブル2106の一例を示す図である。リモートバックアップポリシ管理テーブル2106は、リモートバックアップを実施する際のバックアップペアおよびスケジュールの関係(ポリシ)を管理するテーブルである。
【００６４】
リモートバックアップポリシ管理テーブル2106の各エントリは、リモートバックアップポリシＩＤ欄21061、ペアＩＤ欄21062、スケジュール欄21063を含む。リモートバックアップポリシＩＤ欄21061には、リモートバックアップポリシの一意な識別子が登録される。ペアＩＤ欄21062には、リモートバックアップペア管理テーブル2108によって管理されるバックアップ元ボリュームおよびバックアップ先ボリュームのペアに付された一意な識別子が登録される。スケジュール欄21063には、バックアップを開始する日時、曜日、時刻といったスケジュール情報が登録される。
【００６５】
なお、リモートバックアップポリシ管理テーブル2106の各欄は、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。詳細は、図18で説明する。
【００６６】
図12は、実施例1のローカルバックアップペア管理テーブル2107の一例を示す図である。ローカルバックアップペア管理テーブル2107は、ローカルバックアップを実施する際のバックアップ元ボリュームとバックアップ先ボリュームのペアの関係を管理するテーブルである。
【００６７】
ローカルバックアップペア管理テーブル2107の各エントリは、ペアＩＤ欄21071、ストレージＩＤ欄21072、バックアップ元ボリュームＩＤ欄21073、バックアップ先ボリュームＩＤ欄21074を含む。ペアＩＤ欄21071には、ペアの一意な識別子が登録される。ストレージＩＤ欄21072には、バックアップ元ボリューム及びバックアップ先ボリュームを備えるストレージシステムの一意な識別子が登録される。バックアップ元ボリュームＩＤ欄21073には、バックアップ元ボリュームの一意な識別子が登録される。バックアップ先ボリュームＩＤ欄21074には、該バックアップ元ボリュームの識別子によって識別されるボリュームのデータのバックアップ先とするボリュームの一意な識別子を登録する。
【００６８】
なお、ローカルバックアップペア管理テーブル2107の各欄は、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。詳細は、図17で説明する。
【００６９】
図13は、実施例1のリモートバックアップペア管理テーブル2108の一例を示す図である。リモートバックアップペア管理テーブル2108は、リモートバックアップを実施する際のバックアップ元ボリュームとバックアップ先ボリュームのペアの関係を管理するテーブルである。
【００７０】
リモートバックアップペア管理テーブル2108の各エントリは、ペアＩＤ欄21081、バックアップ元ストレージＩＤ欄21082、バックアップ元ボリュームＩＤ欄210823、バックアップ先ストレージＩＤ欄210824、バックアップ先ボリュームＩＤ欄210825を含む。ペアＩＤ欄21081には、ペアの一意な識別子が登録される。バックアップ元ストレージＩＤ欄21082には、バックアップ元ボリュームを備えるストレージシステムの一意な識別子が登録される。バックアップ元ボリュームＩＤ欄21083には、バックアップ元ボリュームの一意な識別子が登録される。バックアップ先ストレージＩＤ欄21084には、該バックアップ元ボリュームの識別子によって識別されるボリュームに記憶されたデータのバックアップ先とするボリュームを備えるストレージシステムの一意な識別子が登録される。バックアップ先ボリュームＩＤ欄21085には、該バックアップ元ボリュームの識別子によって識別されるボリュームのデータのバックアップ先とするボリュームの一意な識別子を登録する。
【００７１】
なお、リモートバックアップペア管理テーブル21082の各欄には、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。詳細は、図18で説明する。
【００７２】
図14は、実施例1の障害時動作管理テーブル2109の一例を示す図である。障害時動作管理テーブル2109は、ホスト計算機30ａ、30ｂ上で動作するアプリケーション3101に論理障害が発生したことを検知したときのバックアップの動作を定義するテーブルである。
【００７３】
障害時動作管理テーブル2109の各エントリは、ボリュームＩＤ欄21091、アプリケーションＩＤ欄21092、障害ＩＤ欄21093、障害時動作欄21094、優先度欄21095を含む。ボリュームＩＤ欄21091には、ボリュームの一意な識別子が登録される。アプリケーションＩＤ欄21092には、該ボリュームの識別子によって識別されるボリュームを使用するアプリケーションの一意な識別子が登録される。複数のアプリケーションが1つのボリュームを共有して使っている場合は、アプリケーションＩＤ欄21092には、複数のアプリケーションの識別子が登録される。障害ＩＤ欄21093には、アプリケーションに発生する障害の一意な識別子が登録される。任意の障害とする場合(障害を限定しない場合)は、「＊」と登録する。障害時動作欄21094には、ボリュームID欄21091、アプリケーションＩＤ欄21092および障害ＩＤ欄21093に登録された識別子によって識別される障害が発生したときに、アプリケーションＩＤ欄21092に登録された識別子によって識別されるアプリケーションに設定されているリモートバックアップを停止するか継続するかを登録する。具体的には、障害が発生したときにリモートバックアップを停止する場合には「停止」、障害が発生した場合でもリモートバックアップを停止しないで継続する場合は「継続」を登録する。優先度欄21095には、アプリケーションに障害が発生したときに、ユーザが対応しなければならない程度を示す優先度が登録される。なお、優先度欄21095の数値が高いほど、優先度が高いことを示す。
【００７４】
図14の例では、ボリュームＶＯＬ01を使うアプリケーションＡＰ01に障害が発生すると、ストレージ管理プログラム2110は無条件にリモートバックアップを停止する。一方、ボリュームＶＯＬ02を使うアプリケーションＡＰ03に、障害Ｆ04(静止化失敗)が発生すると、リモートバックアップを停止する。また、ボリュームＶＯＬ02を使うアプリケーションＡＰ02とＡＰ03に同時に障害Ｆ01(ウィルス検出)、Ｆ04(静止化失敗)を発生すると、優先度の高い障害Ｆ04(静止化失敗)に基づき、リモートバックアップを停止する。
【００７５】
なお、障害時動作管理テーブル2109の各欄には、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。詳細は、図19、20で説明する。
【００７６】
図15は、実施例1のアプリケーションに論理障害が発生したことを検知したときの処理シーケンスの一例を示す図である。
【００７７】
障害検知プログラム3102は、アプリケーションが出力するログ等をもとに障害を検知すると(Ｓ1501)、障害発生通知をストレージ管理プログラム2110に送信する(Ｓ1502)。障害発生通知には、障害が発生したアプリケーションの識別子、発生した障害の識別子、及び障害が発生したボリュームの識別子を含む。発生した障害を区別しない場合は、発生した障害の識別子を省略してもよい。また、本実施例では、障害発生通知に含むアプリケーションの識別子は1つとするが、同一アプリケーションに複数の障害が同時に発生した場合には、障害の識別子を複数含めてもよい。また、ボリュームを識別する識別子は、ストレージ管理プログラム2110がアプリケーション管理テーブル3103を参照し、アプリケーションの識別子によって識別されるアプリケーションが使用しているボリュームを特定するようにしてもよい。
【００７８】
次に、ストレージ管理プログラム2110は、障害時動作管理テーブル2109を参照し、障害発生通知に含まれるボリュームの識別子、アプリケーションの識別子、障害の識別子によって特定される全てのエントリについて、優先度欄21095に登録された優先度を取得する。そして、最も高い優先度が登録されているエントリの障害時動作欄21094に登録された障害時動作を取得する(Ｓ1503)。取得した障害時動作が「停止」の場合は、バックアップ管理テーブル2104を参照し、障害が発生したアプリケーションが使用するボリュームのリモートバックアップを無効化する。すなわち、バックアップ管理テーブル2104のバックアップ状態欄21044を「無効」にする(Ｓ1504)。取得した障害時動作が「継続」の場合は、そのまま処理を終了する。
【００７９】
なお、障害時動作を全て「停止」とした上で、最も高い優先度の値が、ユーザが予め定めた閾値を超えるか否かによって障害時に動作を変更するかどうか、すなわちバックアップ管理テーブル21040のバックアップ状態欄21044を変更するか否かを決定してもよい。この場合、障害時動作欄21094は不要としてもよい。そうすると、例えば、優先度が閾値を超えた場合や、複数の障害があった場合でそれらの障害の優先度の合計値が閾値を超えた場合に、障害時動作を「停止」とすることが考えられる。これにより、例えばバックアップの処理を昼間と夜間に分けて使うなどして、環境や状況に応じた運用が可能となる。
【００８０】
次に、バックアップを無効化した場合は、ストレージ管理プログラム2110は、障害時動作管理テーブル2109を参照し、バックアップを停止したボリュームを使用するアプリケーションの識別子を全て取得する。そして、アプリケーション管理テーブル2102を参照し、取得した識別子によって識別されるアプリケーションが動作するホスト計算機を特定する(Ｓ1505)。
【００８１】
次に、特定したホスト計算機に対し動作変更レポートを通知する(Ｓ1506)。これにより、障害が発生したアプリケーションが動作するホスト計算機だけでなく、障害によってリモートバックアップを停止したボリュームを使う他のアプリケーションが動作するホスト計算機にもレポートが送信される。
【００８２】
なお、特定したホスト計算機に対しレポートを通知するのではなく、各アプリケーションを管理する管理者の連絡先(電子メールアドレスなど)をあらかじめ管理しておき、そのアドレスに対してレポートを送信するなどしてもよい。また、動作変更レポートには、バックアップが停止されたボリュームを識別する識別子および障害理由などが含まれていてもよい。
【００８３】
図16は、実施例1のアプリケーションに論理障害が発生したことを検知したときのストレージ管理プログラム2110の処理フローの一例を示す図である。
【００８４】
ストレージ管理プログラム2110は、障害検知プログラム3102から障害発生通知を受信する(Ｓ1601) 。
【００８５】
次にストレージ管理プログラム2110は、障害時動作管理テーブル2109を参照し、障害発生通知に含まれるボリュームの識別子、アプリケーションの識別子、障害の識別子によって特定される全てのエントリについて、優先度欄21095に登録された優先度を取得する。そして、最も高い優先度が登録されているエントリの障害時動作欄21094に登録されている障害時動作を取得する(Ｓ1602)。
【００８６】
次に、ストレージ管理プログラム2110は、取得した障害時動作が「停止」か「継続」を判定する(Ｓ1603)。「継続」であれば(Ｓ1603のＮｏ)、ストレージ管理プログラム2110は処理を終了する。なお、この場合、ストレージ管理プログラム2110は、予め設定された時刻になると、リモートバックアップ指示を制御プログラム1121に送信する。
【００８７】
Ｓ1603の判定結果が「停止」の場合(Ｓ1603のＹｅｓ)、ストレージ管理プログラム2110は、バックアップ管理テーブル2104を参照し、障害が発生したアプリケーションが使用するボリュームのリモートバックアップを無効化する。すなわち、バックアップ管理テーブル2104のバックアップ状態欄21044を「無効」にする(Ｓ1604)。
【００８８】
次に、ストレージ管理プログラム2110は、障害時動作テーブル2109を参照し、バックアップを停止したボリュームを使用しているアプリケーションの識別子を全て取得する(Ｓ1605)。次に、ストレージ管理プログラム2110は、アプリケーション管理テーブル2102を参照し、Ｓ1605で取得したアプリケーションの識別子によって識別されるアプリケーションが動作するホスト計算機のＩＰアドレスを取得し(Ｓ1606)、該ＩＰアドレスが付与されたホスト計算機に対し動作変更レポートを通知して(Ｓ1607)、処理を終了する。
【００８９】
なお、ストレージ管理プログラム2110が障害発生通知を受信した際に、障害が発生したデータがバックアップされる、あるいは既にバックアップされている可能性があることをリモートバックアップ先であるストレージシステムに通知してもよい。さらに、この情報をストレージシステムおよび管理計算機で保持するようにしてもよい。例えば、ボリューム管理テーブル2103に新たにデータ状態欄を設け、障害が発生したデータが格納されている可能性がある場合は「障害データあり」、障害が発生したデータがない場合には「障害データなし」と登録することでデータの状態を保持する。これにより、リモートにバックアップされたデータを使ってリストアを行う前に、ユーザは、バックアップデータに異常なデータが含まれている可能性があるか否かを確認することができる。
【００９０】
また、ストレージ管理プログラム2110に、障害からのリストアに成功しローカルにバックアップされたデータが正常に戻ったことを示すリストア成功通知を受信する機能を設け、該リストア成功通知を受信するとリモートバックアップを再開するようにしてもよい。すなわち、バックアップ管理テーブル2104のバックアップ状態欄21044を「有効」にする。このとき、予めスケジュールされた時刻になるのを待った上でリモートバックアップを再開するのではなく、臨時にリモートバックアップを行うようにしてもよい。これにより、障害からのリストア状況に即したリモートバックアップの再開が可能となる。
【００９１】
また、障害がウィルスだった場合、この影響を考慮しなければならない場合がある。例えば、ＡＰ02でウィルスに感染しＡＰ02で使用しているボリュームがＶＯＬ02だった場合、ウィルスの種類によっては同一のストレージ内の他のボリュームのＶＯＬ01まで影響を受ける可能性があり、この場合影響下にあるＶＯＬ01とＶＯＬ02のバックアップを全て停止し、復旧を行ってから処理を再開しなければならない。この場合、ストレージ管理プログラム2110が障害検知プログラム3102から障害の内容がウィルスの感染である旨の通知を受けると共(Ｓ1502)に、ウィルス感染の影響があるＶＯＬの通知も受ける。ストレージ管理プログラム2110は、障害が起きたＡＰの利用するＶＯＬ以外でウィルス感染の影響があるＶＯＬについても、障害ＩＤ欄21093のＦ02(ウィルス感染)における障害時動作を特定し、特定された動作に従った処理を行う。これにより、ウィルスに感染した場合においても、計算機システム全体として適切な処理を行うことができる。
【００９２】
図17は、実施例1のローカルバックアップ設定画面5000の一例を示す図である。ローカルバックアップ設定画面5000はストレージ管理プログラム2110によって提供される。ユーザは、ローカルバックアップ設定画面5000を介してローカルバックアップに関する設定を行うことができ、ローカルバックアップ設定画面5000を介してバックアップ管理テーブル2104の各欄、ローカルバックアップペア管理テーブル2107の各欄、およびローカルバックアップポリシ管理テーブル2105の各欄を登録する。
【００９３】
ローカルバックアップ設定画面5000には、アプリケーションＩＤ指定欄5001が表示される。アプリケーション指定欄5001では、アプリケーションの一意な識別子を選択することができ、アプリケーションの識別子が指定されると、ストレージ管理プログラム2110は、アプリケーション管理テーブル2102を参照し、該アプリケーションの識別子によって識別されるアプリケーションが使用しているボリュームの識別子を取得し、アプリケーション指定欄5001に表示する。アプリケーションが複数のボリュームを使用している場合は、複数のボリュームが表示される。
【００９４】
バックアップ先ボリューム指定欄5002には、バックアップ先ボリューム候補一覧5003が表示され、バックアップ先とするボリュームの識別子を選択することができる。すなわち、アプリケーションＩＤ指定欄5001で指定されたアプリケーションの識別子によって識別されるアプリケーションが使っているデータのバックアップ先を選択することができる。バックアップ先ボリューム候補一覧5003には、ボリューム管理テーブル2103に登録されているボリュームのうち使用されていないボリュームのみが表示される。また、バックアップ先ボリューム候補一覧5003には、ボリュームの識別子、リモートバックアップ有無、リモートバックアップスケジュール等の情報が表示される。リモートバックアップ有無には、バックアップ先候補ボリュームにリモートバックアップ設定が行われている場合は「あり」、行われていない場合は「なし」と表示される。リモートバックアップスケジュールには、リモートバックアップ有無が「あり」の場合のみ、リモートバックアップスケジュールが表示される。リモートバックアップ有無、およびリモートバックアップスケジュールは、ストレージ管理プログラム2110がリモートバックアップペア管理テーブル2108、及びリモートバックアップポリシ管理テーブル2106から取得した情報を表示する。
【００９５】
バックアップスケジュール指定欄5004には、ローカルバックアップのバックアップスケジュールを指定することができる。図17のローカルバックアップ設定画面5000では、バックアップ頻度を、毎日、毎週、毎月から選択でき、毎日を選択した場合には何時何分にバックアップを行うのか、毎週を選択した場合には、何曜日の何時何分にバックアップを行うのか、毎月を選択した場合には、何日の何時何分にバックアップを行うのか、を選択することができる。
【００９６】
なお、ボリューム毎にバックアップ先とするボリュームを選ばせるのではなく、あらかじめ同じリモートバックアップポリシが適用されているボリュームをグループ化しておき、バックアップ先とするボリュームを選択する際には、該グループを選択させるようにしてもよい。
【００９７】
図18は、実施例1のリモートバックアップ設定画面6000の一例を示す図である。リモートバックアップ設定画面6000は、ストレージ管理プログラム2110によって提供される。ユーザは、リモートバックアップ設定画面6000を介してリモートバックアップに関する設定を行うことができ、リモートバックアップ設定画面6000を介してリモートバックアップペア管理テーブル2108の各欄、およびリモートバックアップポリシ管理テーブル2106の各欄を登録する。
【００９８】
リモートバックアップ設定画面6000には、バックアップ元指定欄6001が表示される。バックアップ元指定欄6001では、リモートにバックアップしたいボリュームを備えるストレージシステムの一意な識別子と、リモートにバックアップしたいボリュームの一意な識別子を選択することができる。
【００９９】
バックアップ先指定欄6002では、バックアップ先とするボリュームを備えるストレージの一意な識別子と、バックアップ先とするボリュームの一意な識別子を選択することができる。
【０１００】
バックアップスケジュール指定欄6003では、リモートバックアップのバックアップスケジュールを指定することができる。指定できる項目は、ローカルバックアップ設定画面5000のバックアップスケジュール指定欄5003と同様である。
【０１０１】
図19、20は、実施例1の障害時動作設定画面7000および優先度設定画面8000の一例を示す図である。障害時動作設定画面7000および優先度設定画面8000はストレージ管理プログラム2110によって提供される。ユーザは、障害時動作設定画面7000を介して、アプリケーションや障害内容ごとにリモートバックアップを停止するか、継続するかを決定することができ、優先度設定画面8000を介して、同一ボリュームを使用するアプリケーションに複数の論理障害が発生したときの障害時動作の優先度を決定することができる。また、ユーザは、障害時動作設定画面7000および優先度設定画面8000を介して、障害時動作管理テーブル2109の各欄を登録する。
【０１０２】
障害時動作設定画面7000には、アプリケーションＩＤ指定欄7001が表示される。アプリケーションＩＤ指定欄7001では、アプリケーションの識別子を指定することができる。
【０１０３】
障害時動作指定欄7002では、アプリケーションＩＤ指定欄7001で指定されたアプリケーションの識別子によって識別されるアプリケーションに発生しうる障害の識別子、およびその障害が発生したときにリモートバックアップを停止するか、継続するかを指定できる。
【０１０４】
優先度設定画面8000は、障害時動作設定画面7000のボタン7003が押されたときに表示される画面である。優先度設定画面8000では、障害時動作画面7000で指定されたアプリケーションの識別子によって識別されるアプリケーションが使用する全てのボリュームそれぞれに対し、同一ボリュームに複数の障害が発生したときに備え、障害内容の優先度がユーザによって設定される。同一のボリュームで起こりうる障害について一括して優先度を設定できる画面を表示することにより、ユーザは優先度を他の障害の重要度を勘案して相対的に決定することができる。図20の優先度登画面8000では、優先度指定欄8001で、障害内容と優先度をそれぞれ組み合わせて選択し、追加ボタン8002を押すと、選択した障害内容と優先度が選択確認画面8003に追加される。全ての障害内容について優先度を決め、決定ボタン8004を押すと、障害時動作の設定が完了する。
【０１０５】
なお、ローカルバックアップ管理画面5000を介してローカルバックアップ管理を行う権限と、リモートバックアップ管理画面6000を介してリモートバックアップ管理を行う権限を分離してもよい。これにより、1人のユーザにローカルバックアップ管理を行う権限とリモートバックアップ管理を行う権限を与えれば、同じユーザがローカルバックアップ管理とリモートバックアップ管理を行うことができ、異なるユーザにそれぞれの権限を与えれば、異なるユーザがローカルバックアップ管理とリモートバックアップ管理を行うことができる。典型的な例では、ホスト計算機およびアプリケーションを管理するユーザがローカルバックアップ管理を行い、ストレージを管理するユーザがリモートバックアップ管理を行う。
【０１０６】
また、ローカルバックアップ管理画面5000、リモートバックアップ管理画面6000、障害時動作設定画面7000及び優先度設定画面8000は、管理計算機の有する入出力装置によって出力され、またユーザは入出力装置をもって各種設定を行う。なお、この入出力装置としては、ディスプレイ、キーボード、マウスなどが考えられる。
【０１０７】
また、異なるユーザがローカルバックアップ管理とリモートバックアップ管理を行う場合でも、ローカルバックアップ管理を行うユーザが、障害時動作設定画面7000および優先度設定画面8000を介してアプリケーションに障害が発生したときのリモートバックアップの動作を定義できるようにすれば、ローカルバックアップを管理するユーザの設定に基づきリモートバックアップを制御することができる。
【０１０８】
以上、本実施例では、ストレージ管理プログラム2110に、障害時動作管理テーブル2109に基づきリモートバックアップの停止、継続を判断するプログラムを備え、これにより障害が発生したアプリケーションおよびその障害内容に基づくリモートバックアップの停止、継続を実現することができる。すなわち、重大な障害であるにも関わらずバックアップを継続してしまうことや、軽微な障害であるにも関わらずバックアップを停止してしまうことを防止できる。また、障害毎に優先度を定めておくことで、複数の障害が発生した場合でも優先度に応じた障害時動作を行うことができる。
【０１０９】
なお、本実施例は、ローカルバックアップしたデータをさらにローカルバックアップする構成にも適用できる。
【０１１０】
また、本実施例でローカルバックアップを制御するのは管理計算機20として説明をしたが、ローカルバックアップの制御はホスト計算機30でも行うことができ、本発明は、リモートバックアップの管理とローカルバックアップの管理を異なる管理プログラムから行う場合にも有効である。この場合、ホスト計算機30のメモリ310上に、さらにローカルバックアップ管理テーブル、ローカルバックアップポリシ管理テーブル、ローカルバックアップペア管理テーブル、ローカルバックアップ管理プログラムを有することになる。また、管理計算機20のバックアップ管理テーブル2104には、バックアップ種別欄21042が「リモート」のエントリのみとなる。
【０１１１】
それぞれの詳細に関しては、管理計算機20の場合と基本的に同じである。ローカルバックアップ管理テーブルでは、ローカルバックアップの状態を管理する。また、ローカルバックアップ管理プログラムは、制御プログラムにローカルバックアップ指示を送信するなど、ローカルバックアップに関する制御を行う。
【０１１２】
図21に、ホスト計算機30がローカルバックアップを行う場合の、ローカルバックアップ管理プログラムのローカルバックアップ処理フローの一例を示す。なお、ローカルバックアップは、ローカルバックアップ管理テーブルの有効無効欄が「有効」と登録されているエントリのポリシ欄に登録されたポリシに従って実行される。
【０１１３】
ローカルバックアップ管理プログラムは、以下の処理を実行する。まず、ポリシに登録された時刻になると、アプリケーション管理プログラムを介して、アプリケーションを静止化する(Ｓ2102)。次に、ローカルバックアップペア管理テーブルを参照し、ローカルバックアップポリシ管理テーブルのペアID欄に登録されたペアの識別子によって特定されるエントリのストレージID欄に登録されたストレージの識別子、バックアップ元ボリュームID欄に登録されたボリュームの識別子、およびバックアップ先ボリューム欄に登録されたボリュームの識別子を取得する(Ｓ2102)。
【０１１４】
次にＳ2102で取得したバックアップペアに対するローカルバックアップ指示をストレージシステム1aの制御プログラムに送信する(Ｓ2103)。次に、障害検知プログラム3103を介して、バックアップ先ボリュームのデータに障害が発生していないかを確認する(Ｓ2104)。これは、アプリケーションの動作ログ等を参照するなどして行う。例えば、ウィルス検知プログラムでバックアップデータのウィルス感染有無を検証した場合は、その検証ログを参照する。また、データベース管理プログラムなどのアプリケーションがボリュームを使用している場合は、データベース管理プログラムのログを参照する。
【０１１５】
次に、S2104の検証結果から障害の有無を判定する(Ｓ2105)。障害がなければ(Ｓ2105のＹｅｓ)、障害検知プログラム3103を介して、障害発生通知をストレージ管理プログラム2110に通知して処理を完了する(Ｓ2106)。なお、障害発生通知には、障害が発生したアプリケーションの識別子、発生した障害の識別子、及び障害が発生したボリュームの識別子を含む。
【０１１６】
以上のようにすることにより、ホスト計算機30がローカルバックアップを制御する場合でも、管理計算機20とホスト計算機30が連携して、アプリケーションに障害が発生した場合のバックアップ制御を行うことができる。
【０１１７】
また、ローカルにデータをバックアップする前に障害有無を確認し、障害が検知されたらローカルバックアップ自体を停止してしまってもよい。
【０１１８】
なお、図21では、ローカルバックアップしたデータに対して障害有無を確認し、障害を検知するとリモートバックアップを停止したが、ローカルバックアップを行う前に障害有無を検知し、障害を検知するとローカルバックアップ自体を停止してもよい。この場合の処理フローを図22に説明する。また、図23では、図22の処理フローの中でローカルバックアップ管理プログラムがストレージ管理プログラムに障害発生通知を送信し、該通知をストレージ管理プログラムが受信したときのストレージ管理プログラムの処理フローを説明する。
【０１１９】
図22は、ローカルバックアップ管理プログラムのローカルバックアップ処理フローの一例である。ローカルバックアップ管理プログラムは、障害検知プログラム3103を介して、アプリケーションが使用するボリュームのデータに論理障害が発生していないかを確認する(Ｓ2201)。
【０１２０】
次に、Ｓ2201の検証結果から障害有無を判定する(Ｓ2202)。障害が無ければ(Ｓ2202のＹｅｓ)、アプリケーション管理プログラム3103を介してアプリケーションを静止化し(Ｓ2206)、バックアップペアを特定し(Ｓ2207)、Ｓ2207で取得したバックアップペアに対するローカルバックアップ指示をストレージシステム1a上の制御プログラム1121に送信して(Ｓ2208)、処理を終了する。
【０１２１】
一方、Ｓ2205の判定結果が障害ありの場合(Ｓ2202のＹｅｓ)、障害検知プログラム3103を介して、障害発生通知をストレージ管理プログラム2110に通知し、障害時動作を取得する(Ｓ2203)。
【０１２２】
次に、Ｓ2203で取得した障害時動作が「停止」か「継続」かを判定する(Ｓ2204)。「継続であれば(Ｓ2204のＮｏ)、Ｓ2202の判定結果が障害なしの場合と同様の処理を行い、処理を終了する。
【０１２３】
一方、Ｓ2204の判定結果が「停止」の場合(Ｓ2204のＹｅｓ)、ローカルバックアップ管理テーブルを参照し、障害が発生したアプリケーションが使用するボリュームのローカルバックアップを無効化する。すなわち、ローカルバックアップ管理テーブルの有効無効欄を「無効」にし(Ｓ2205)、処理を終了する。
【０１２４】
なお、図22の処理フローでは、バックアップ対象となっているボリュームの障害有無の確認をした後でアプリケーションを静止化するため、障害有無を確認したデータと実際にバックアップするデータが一致しない場合がある。これを防ぐために、アプリケーションを静止化した状態で障害有無を確認してもよい。
【０１２５】
図23は、ストレージ管理プログラム2110が障害発生通知をローカルバックアップ管理プログラムから受信したときのストレージ管理プログラム2110の処理フローの一例を示す図である。ストレージ管理プログラム2110は、障害発生検知プログラム3103から障害発生通知を受信する(Ｓ2301)。
【０１２６】
次に、障害時動作管理テーブル2109を参照し、障害発生通知に含まれるボリュームの識別子、アプリケーションの識別子、障害の識別子によって特定される全てのエントリについて、優先度欄21095に登録された優先度を取得する。そして、最も高い優先度が登録されているエントリの障害時動作欄21094に登録された障害時動作を取得し(Ｓ2302)、取得した障害時動作をローカルバックアップ管理プログラムに通知する(Ｓ2303)。
【０１２７】
次に、Ｓ2303で取得した障害時動作が「停止」か「継続」かを判定する(Ｓ2304)。「継続」であれば(Ｓ2304のＮｏ)、処理を終了する。
【０１２８】
一方、S2304の判定結果が「停止」の場合(Ｓ2304のＹｅｓ)、リモートバックアップ管理テーブル2104を参照し、障害が発生したアプリケーションが使用するボリュームのリモートバックアップを無効化する。すなわち、リモートバックアップ管理テーブル2104の有効無効欄21043を「無効」にする(Ｓ2305)。
【０１２９】
次に、障害時動作管理テーブル2109を参照し、バックアップを停止するボリュームを使用しているアプリケーションの識別子を全て取得する(Ｓ2306)。次に、アプリケーション管理テーブル2102を参照し、Ｓ2305で取得したアプリケーションの識別子によって識別されるアプリケーションが動作するホスト計算機のＩＰアドレスを取得し(Ｓ2307)、該ＩＰアドレスが付与されたホスト計算機に対し動作変更レポートを通知して(Ｓ2308)、処理を終了する。
【０１３０】
なお、図22、23では、同じ障害時動作管理テーブルに基づき、障害発生時のローカルバックアップの動作とリモートバックアップの動作を決定したが、ローカルバックアップ用の障害時動作管理テーブル、リモートバックアップ用の障害時動作管理テーブルを用意し、各々のテーブルに基づき障害発生時のリモートバックアップの動作を決定してもよい。
【０１３１】
また、ローカルサイトのリモートバックアップを行うストレージシステムを2つ用意し、片方と同期、もう片方とは非同期でバックアップを行う、一般にマルチターゲットと呼ばれるリモートコピーの形態があり、このような形態にも本実施例は適用できる。この場合、図9のバックアップ管理テーブルは、さらにバックアップが同期か非同期かを示す転送モード欄を有する。また、図14の障害時動作管理テーブルは、さらにバックアップ種別欄と転送モード欄を有し、障害時動作決定画面7000および優先度登録画面8000を介してユーザから優先度が設定される。ここで、ユーザがストレージシステムのそれぞれに優先度の閾値を設定するなどすれば、バックアップの種別や転送モードによって異なる優先度を設定することで、ストレージ装置それぞれの障害時動作を区別して動作させることができる。
【実施例２】
【０１３２】
本実施例では、ストレージ管理ソフトが障害発生通知を受信すると、障害が発生したアプリケーション、その障害内容、および障害発生前最後のリモートバックアップを行った時刻から障害発生後最初のリモートバックアップを行う時刻までに発生したデータ変更の量に基づき、障害発生後最初のリモートバックアップの継続、停止を判断するメカニズムを提供する。以下、実施例1と異なる点を中心に説明する。
【０１３３】
本実施例の計算機システム、ホスト計算機の構成は、実施例1の計算機システム1、ホスト計算機30の構成と同じであるため、説明を省略する。
【０１３４】
図24は、実施例2のストレージシステム10ａの構成の一例を示す。実施例1と異なる点は、制御メモリ112にデータ変更量監視プログラム1122を備える点である。データ変更量監視プログラム1123は、ホスト計算機10ａ、10ｂからのＩＯ要求に基き、ボリュームに記憶されたデータがどれだけ変更されるかを監視し、計算するプログラムである。たとえば、ボリュームを構成するブロック単位でデータ変更量を監視、計算する。
【０１３５】
図25は、実施例2の管理計算機20の構成の一例を示す図である。実施例1と異なる点は、データ変更量計算プログラム2112を備える点である。データ変更量計算プログラム2112は、ストレージシステム10ａが備えるデータ変更量監視プログラム1123から、任意時点間のボリュームのデータ変更量を取得するプログラムである。
【０１３６】
なお、本実施例では、ストレージシステム10ａにデータ変更量監視プログラムを備え、ストレージシステム10ａでボリュームのデータ変更量を監視しているが、ホスト計算機30ａ、30ｂにデータ変更量監視プログラムを備え、ホスト計算機でボリュームのデータ変更量を監視してもよい。この場合、データ変更量計算プログラム2112は、ホスト計算機30ａ、30ｂが備えるデータ変更量監視プログラムからデータ変更量を取得する。また、この場合ブロック単位でデータ変更量を監視、計算するのではなく、ライト量から判断してもよい。
【０１３７】
図26は、実施例2の障害時動作管理テーブル2109の一例を示す図である。
【０１３８】
障害時動作管理テーブル2109は、ホスト計算機30ａ、30ｂ上で動作するアプリケーション3101に障害が発生したときのリモートバックアップの動作を定義するテーブルである。
【０１３９】
障害時動作管理テーブル2109の各エントリは、ボリュームＩＤ欄21091、アプリケーションＩＤ欄21092、障害ＩＤ欄21093、条件欄21094、障害時動作欄21095、優先度欄21096を含む。条件欄21094以外の欄については図14と同じであるため記載を省略する。条件欄21094には、障害時動作欄21095に登録された障害時動作(停止、継続)を実行するときの条件が登録される。具体的には、障害発生前最後のリモートバックアップを行った時刻から障害発生後最初のリモートバックアップを行う時刻までに、ボリュームＩＤ欄21091に登録されたボリュームの識別子によって識別されるボリュームがどれだけ変更されたかを条件として定義する。
【０１４０】
図26の例では、ボリュームＶＯＬ02を使うアプリケーションＡＰ03に、障害Ｆ03(テーブルＡ破壊)が発生しても、障害発生前最後のリモートバックアップを行った時刻から障害発生後最初のリモートバックアップを行う時刻までのデータ変更量が300Ｋバイト以上であれば、リモートバックアップを継続する。一方、アプリケーションＡＰ03に、障害Ｆ04(テーブルＢ破壊)が発生した場合は、障害発生前最後のリモートバックアップを行った時刻から障害発生後最初のリモートバックアップを行う時刻までのデータ変更量が1000Ｋバイト以上にならないと、リモートバックアップは継続しない。
【０１４１】
なお、障害時動作管理テーブル2109の各欄には、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。
【０１４２】
図27は、実施例2のアプリケーションに論理障害が発生したことを検知したときの処理シーケンスの一例を示す図である。
【０１４３】
障害検知プログラム3102は、障害を検知すると(Ｓ2701)、障害発生通知をストレージ管理プログラム2110に送信する(Ｓ2702)。
【０１４４】
次に、ストレージ管理プログラム2110は、データ変更量計算プログラム2112を介して、データ変更量監視プログラム1123にデータ変更量取得要求を送信し、障害発生前最後のリモートバックアップを行った時刻から障害発生後最初のリモートバックアップを行う時刻までのデータ変更量を受信する(Ｓ2703)。データ変更量取得要求には、障害が発生したボリュームの識別子、障害発生前最後のリモートバックアップを行った時刻、障害発生後最初のリモートバックアップを行う時刻を含む。
【０１４５】
次に、ストレージ管理プログラム2110は、障害時動作管理テーブル2109を参照し、障害発生通知に含まれるボリュームの識別子、アプリケーションの識別子、障害の識別子、およびデータ変更量監視プログラムから受信したデータ変更量によって特定される全てのエントリについて、優先度欄21096に登録された優先度を取得する。そして、最も高い優先度が登録されているエントリの障害時動作欄21095に登録された障害時動作を取得する(Ｓ2704)。取得した障害時動作が「停止」の場合は、バックアップ管理テーブル2104を参照し、障害が発生したアプリケーションが使用するボリュームのリモートバックアップを無効化する。すなわち、バックアップ管理テーブル2104のバックアップ状態欄21044を「無効」にする(Ｓ2705)。取得した障害時動作が「継続」の場合は、ストレージ管理プログラム2110は、予め設定したスケジュールに基づき、予め設定したペアに対するバックアップ指示を制御プログラム1121に送信する。
【０１４６】
次に、バックアップを停止した場合は、ストレージ管理プログラム2110は、バックアップを停止したボリュームを使用するアプリケーションの識別子を全て取得し、アプリケーション管理テーブル2102を参照し、各アプリケーションが動作するホスト計算機を特定する(Ｓ2706)。そして、特定したホスト計算機に対し動作変更レポートを通知する(Ｓ2707)。
【０１４７】
図28は、実施例2のアプリケーションに論理障害が発生したことを検知したときのストレージ管理プログラム2110およびデータ変更量計算プログラム2112の処理フローを説明する。
【０１４８】
ストレージ管理プログラム2110は、障害検知プログラム3102から障害発生通知を受信する(Ｓ2801) 。
【０１４９】
次に、データ変更量計算プログラム2112を介して、データ変更量取得要求をデータ変更量監視プログラム1123に送信し、障害発生前最後のリモートバックアップを行った時刻から障害発生後最初のリモートバックアップを行う時刻までのデータ変更量を受信する(Ｓ2802)。
【０１５０】
次にストレージ管理プログラム2110は、障害時動作管理テーブル2109を参照し、障害発生通知に含まれるボリュームの識別子、アプリケーションの識別子、障害の識別子、およびデータ変更量監視プログラムから受信したデータ変更量によって特定される全てのエントリについて、優先度欄21096に登録された優先度を取得する。そして、最も高い優先度が登録されているエントリの障害時動作欄21095に登録された障害時動作を取得する(Ｓ2803)。
【０１５１】
次に、ストレージ管理プログラム2110は、取得した障害時動作が「停止」か「継続」を判定する(Ｓ2804)。「継続」であれば(Ｓ2804のＮｏ)、処理を終了する。なお、この場合、ストレージ管理プログラム2110は、予め設定されたスケジュールに基づきリモートバックアップ指示を制御プログラム1121に送信する。
【０１５２】
Ｓ2804の判定結果が「停止」の場合(Ｓ2804のＹｅｓ)、バックアップ管理テーブル2104を参照し、障害が発生したアプリケーションが使用するボリュームのリモートバックアップを無効化する。すなわち、バックアップ管理テーブル2104のバックアップ状態欄21044を「無効」にする(Ｓ2805)。
【０１５３】
次に、ストレージ管理プログラム2110は、障害時動作テーブル2109を参照し、バックアップを停止したボリュームを使用しているアプリケーションの識別子を取得する(Ｓ2806)。次に、アプリケーション管理テーブル2102を参照し、Ｓ2806で取得したアプリケーションの識別子によって識別されるアプリケーションが動作するホスト計算機のＩＰアドレスを取得し(Ｓ2807)、該ＩＰアドレスが付与されたホスト計算機に対し動作変更レポートを通知して(Ｓ2808)、処理を終了する。
【０１５４】
以上、本実施例では、ストレージ管理プログラムにデータ変更量計算プログラムを備え、ストレージ管理プログラムが障害発生通知を受信すると、障害発生前最後のリモートバックアップを行った時刻から障害発生後最初のリモートバックアップを行う時刻までのデータ変更量を計算し、計算結果に基づきリモートバックアップの停止、継続を判断する。これによって、障害が発生したアプリケーション、障害内容、およびアプリケーション稼動情報に基づきバックアップの停止、継続を決定することができる。
【実施例３】
【０１５５】
本実施例では、ストレージ管理プログラムが障害発生通知を受信すると、障害発生後最初のリモートバックアップの継続、停止、一時ボリュームへのバックアップを判断するメカニズムを提供する。一時ボリュームへのバックアップとは、通常時(障害未発生時)にバックアップする先として設定されているボリュームとは異なるボリュームにバックアップすることである。以下、実施例1と異なる点を中心に説明する。
【０１５６】
本実施例の計算機システム、ストレージシステム、管理計算機、ホスト計算機の構成は、実施例1の計算機システム1、ストレージシステム10、管理計算機20、ホスト計算機30の構成と同じため、説明を省略する。
【０１５７】
図29は、実施例3の障害時動作管理テーブル2109の一例を示す図である。障害時動作管理テーブル2109は、ホスト計算機30ａ、30ｂ上で動作するアプリケーション3101に障害が発生したときのリモートバックアップの動作を定義するテーブルである。
【０１５８】
障害時動作管理テーブル2109の各エントリは、ボリュームＩＤ欄21091、アプリケーションＩＤ欄21092、障害ＩＤ欄21093、障害時動作欄21094、優先度欄21095を含む。障害時動作欄21094以外の欄については図14と同じため記載を省略する。障害時動作欄21094には、アプリケーションＩＤ欄21092および障害ＩＤ欄21093に登録された識別子によって識別される障害が発生したときのリモートバックアップ動作を登録する。本実施例では、「継続」、「停止」に加え、「一時ボリュームにバックアップ」が登録できる。障害時動作として「一時ボリュームにバックアップ」が登録されている場合には、通常時にバックアップする先として設定されているボリュームとは異なるボリュームにバックアップする。つまり、新しくバックアップを実行した後でも、前回バックアップした時のデータを残すことができる。
【０１５９】
図29の例では、ボリュームＶＯＬ03を使うアプリケーションＡＰ03に、障害Ｆ04(静止化失敗)が発生すると、通常時にバックアップする先として設定されているボリュームとは異なるボリュームにデータをバックアップする。
【０１６０】
なお、障害時動作管理テーブル2109の各欄には、ストレージ管理プログラム2110によって提供されるユーザインターフェースを介してユーザが設定する。
【０１６１】
図30は、実施例3のアプリケーションに障害が発生したときのストレージ管理プログラム2110の処理フローの一例を示す図である。
【０１６２】
ストレージ管理プログラム2110は、障害検知プログラム3102から障害発生通知を受信する(Ｓ3001)。
【０１６３】
次にストレージ管理プログラム2110は、障害時動作管理テーブル2109を参照し、障害発生通知に含まれるボリュームの識別子、アプリケーションの識別子、障害の識別子によって特定される全てのエントリについて、優先度欄21095に登録された優先度を取得する。そして、最も高い優先度が登録されているエントリの障害時動作欄21094に登録された障害時動作を取得する(Ｓ3002)。
【０１６４】
次に、ストレージ管理プログラム2110は、取得した障害時動作が「継続」か「それ以外(停止または一時ボリュームにバックアップ)」を判定する(Ｓ3003)。「継続」であれば(Ｓ3003のＮｏ)、ストレージ管理プログラム2110は処理を終了する。なお、この場合、ストレージ管理プログラム2110は、予め設定されたスケジュールに基づきリモートバックアップを制御プログラム1121に指示する。
【０１６５】
Ｓ3003の判定結果が「それ以外」であれば(Ｓ3003のＹｅｓ)、次に、ストレージ管理プログラム2110は、取得した障害時動作が「停止」か「一時ボリュームにバックアップ」を判定する(Ｓ3004)。「一時ボリュームにバックアップ」であれば(Ｓ3004のＮｏ)、一時ボリュームへのバックアップ処理を実行し(Ｓ3009)、処理を終了する。なお、一時ボリュームへのバックアップ処理は、図31で説明する。
【０１６６】
Ｓ3004の判定結果が「停止」の場合(Ｓ3004のＹｅｓ)、ストレージ管理プログラム2110は、バックアップ管理テーブル2104を参照し、障害が発生したアプリケーションが使用するボリュームのリモートバックアップを無効化する。すなわち、バックアップ管理テーブル2104のバックアップ状態欄21044を「無効」にする(Ｓ3005)。
【０１６７】
次に、ストレージ管理プログラム2110は、障害時動作管理テーブル2109を参照し、バックアップを停止したボリュームを使用しているアプリケーションの識別子を取得する(Ｓ3006)。次に、ストレージ管理プログラム2110は、アプリケーション管理テーブル2102を参照し、Ｓ3006で取得したアプリケーションの識別子によって識別されるアプリケーションが動作するホスト計算機のＩＰアドレスを取得し(Ｓ3007)、該ＩＰアドレスが付与されたホスト計算機に対し動作変更レポートを通知して(Ｓ3008)、処理を終了する。
【０１６８】
図31は、実施例3のストレージ管理プログラム2110の一時ボリュームへのバックアップ処理フローの一例を示す図である。
【０１６９】
ストレージ管理プログラム2110は、ボリューム管理テーブル2103を参照し、リモート側のストレージシステム2が備えるボリュームであって、使用有無欄２１０３４が「未使用」のボリュームの中から、バックアップ先とする一時ボリュームを取得する(S3101)。
【０１７０】
未使用ボリュームがない場合は(S3102のＮｏ)、ローカルバックアップ管理プログラム３１１０にエラーを通知して(Ｓ３１０５)、処理を終了する。なお、未使用ボリュームがなかった場合のリモートバックアップ動作を予めユーザに定義させておき、この設定に基づきリモートバックアップを行っても良い。
【０１７１】
S3102の判定結果が「あり」であれば(S3102のＹｅｓ)であれば、ストレージ管理プログラム2110は、S3101で取得したボリュームをリモートバックアップ先とするボリュームのペアを構築する。すなわち、リモートバックアップペア管理テーブル2108に新しいバックアップペアを登録し、リモートバックアップポリシ管理テーブル2106に新しいポリシを登録する(S3103)。ポリシ登録時に設定するスケジュールは、既に登録されているもともとのリモートバックアップポリシと同じスケジュールとする。
【０１７２】
次に、ストレージ管理プログラム2110は、バックアップ管理テーブル2104を参照し、障害が発生したアプリケーションが使用するボリュームのリモートバックアップを無効化し、S3103で新たに作成したポリシに基づくリモートバックアップを行うよう、新たにエントリを追加し(S3104)、処理を終了する。これ以降のリモートバックアップは、新しいポリシに従い、通常時にバックアップ先として設定されていたボリュームとは異なるボリュームに対して実行される。
【０１７３】
なお、ストレージ管理プログラム2110に、障害からのリストアに成功しローカルにバックアップされたデータが正常に戻ったことを示すリストア成功通知を受信する機能を設け、該リストア成功通知を受信するとバックアップペアをもとに戻すようにしてもよい。
以上、本実施例では、ストレージ管理プログラムに、一時ボリュームへのバックアップを判断するプログラムを備えることで、障害が発生したアプリケーションおよびその障害内容に基づきバックアップの停止、継続、一時ボリュームへのバックアップを決定することができる。
【符号の説明】
【０１７４】
1…コンピュータシステム
10…ストレージ装置
20…管理計算機
30…ホスト装置
40…管理ネットワーク
50…ストレージネットワーク
110…コントローラ
120…ディスク装置
【図１】
2011039804.tif 000003
【図２】
2011039804.tif 000004
【図３】
2011039804.tif 000005
【図４】
2011039804.tif 000006
【図５】
2011039804.tif 000007
【図６】
2011039804.tif 000008
【図７】
2011039804.tif 000009
【図８】
2011039804.tif 000010
【図９】
2011039804.tif 000011
【図１０】
2011039804.tif 000012
【図１１】
2011039804.tif 000013
【図１２】
2011039804.tif 000014
【図１３】
2011039804.tif 000015
【図１４】
2011039804.tif 000016
【図１５】
2011039804.tif 000017
【図１６】
2011039804.tif 000018
【図１７】
2011039804.tif 000019
【図１８】
2011039804.tif 000020
【図１９】
2011039804.tif 000021
【図２０】
2011039804.tif 000022
【図２１】
2011039804.tif 000023
【図２２】
2011039804.tif 000024
【図２３】
2011039804.tif 000025
【図２４】
2011039804.tif 000026
【図２５】
2011039804.tif 000027
【図２６】
2011039804.tif 000028
【図２７】
2011039804.tif 000029
【図２８】
2011039804.tif 000030
【図２９】
2011039804.tif 000031
【図３０】
2011039804.tif 000032
【図３１】
2011039804.tif 000033