以下、本発明のいくつかの実施形態について、図面を参照しながら説明する。なお、これにより本発明が限定されるものではない。
<第一の実施形態>。
まず、第一の実施形態について説明する。
本実施形態に係る計算機システムは、ジャーナリングを用いたバックアップ技術を用いてバックアップ及びリストアを行うストレージシステムを備える。当該ストレージシステムは、密に連携する複数のアプリケーションのデータを格納するボリュームを備え、ジャーナリングを用いたバックアップ技術でこれをバックアップ(及びリストア)する。
当該計算機システムでは、複数のアプリケーションがお互いに処理を呼び出しあう。このため、データ破壊などの障害発生時には、全てのアプリケーションをリカバリしてから業務を再開する必要がある。
また、ジャーナリングを用いたバックアップ技術を用いて任意時点の状態にデータをリストアすると、一般的なアプリケーションにとってデータは不整合な状態である。このため、整合性確認処理(例えば、FSCKやクラッシュリカバリ)が必要となるが、当該処理にかかる時間は、アプリケーションのタイプやリカバリポイントにおけるアプリケーションの稼働状況や状態によって大きく異なる。
ところで、全ボリュームを一括してリストアすると、全ボリュームにとって、リストア完了までの時間が長くなる。この結果、全てのアプリケーションにとって、整合性確認開始時間が遅くなり、業務再開までの時間が長くなってしまうという問題が発生する。
本実施形態では、この問題を解決するために、リストアされたデータの整合性確認の時間が長いアプリケーションのデータを優先的にリストアし、他より早く完了させる。これにより、長い処理時間を必要とする整合性確認処理ほど前倒しして実行できるようになる。また、当該整合性確認処理はホスト計算機上で行われ、ストレージシステムのリストア処理性能に影響を与えないため、他のアプリケーションのデータのリストアを当該処理と並行して実行できる。この結果、業務再開までの時間を短くすることが可能になる。
以下、本実施形態のシステム構成と動作を説明する。
(1)第一の実施形態のシステム構成。
図1は、本実施形態の計算機システムの構成を示すブロック図である。本システムでは、ストレージシステム1000とホスト計算機1100は、データネットワーク1300を介して互いに接続される。本実施形態では、データネットワーク1300は、ストレージエリアネットワークとするが、IPネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。
ストレージシステム1000とホスト計算機1100と管理計算機1200は、管理ネットワーク1400を介して互いに接続される。本実施形態では、管理ネットワーク1400は、IPネットワークとするが、ストレージエリアネットワークであっても、あるいはこれら以外のデータ通信用ネットワークであってもよい。また、データネットワーク1300と管理ネットワーク1400が、同一ネットワークであってもよいし、ホスト計算機1100と管理計算機1200が、同一計算機であってもかまわない。
なお、説明の都合上、図1では、ストレージシステム1000を1台、ホスト計算機1100を1台、管理計算機1200を1台としたが、これら以上の台数を設置しても良い。
ストレージシステム1000は、データを格納するディスク装置1010、ストレージシステム1000内の制御を行うディスクコントローラ1020で構成されている。
ディスク装置1010は、ディスク型の記憶装置、例えば、ハードディスクドライブである。ディスク装置1010に代えて、フラッシュメモリデバイス等、多種の記憶装置が採用されてもよい。ディスク装置1010の記憶空間を基に、複数の論理ボリューム、例えば、データボリューム1011、スナップショットボリューム1012、ジャーナルボリューム1013等が形成される。そして、複数の論理ボリュームのうちの一以上の論理ボリュームより、それぞれ、ジャーナルグループ1014、SSVOLグループ1015が構成される。尚、ストレージシステム1000は、実際には、複数のディスク装置1010を備え、複数のディスク装置1010の記憶空間を基に、論理ボリュームが形成される。ディスク装置1010は、複数に限らず一つでもよい。
ジャーナルグループ1014は、一つ以上のデータボリューム1011により構成される。データボリューム1011は、ホスト計算機1100が利用するデータを格納する論理ボリュームである。また、ジャーナルグループ1014には、一つ以上のジャーナルボリューム1013及び一つ以上のSSVOLグループ1015が、関連付けられる。
ジャーナルボリューム1013は、ジャーナルを格納する論理ボリュームである。
SSVOLグループ1015は、一つ以上のスナップショットボリューム1012で構成される。スナップショットボリューム1012は、ある時点におけるデータボリューム1011の複製イメージ(スナップショット)を格納する論理ボリュームである。なお、スナップショットボリューム1012に格納されるスナップショットは、データボリューム1011のフルバックアップであっても、差分バックアップのような論理的なイメージであっても良い。
なお、これらの論理ボリュームに関する情報(構成情報)は、後述する制御プログラム1028を実行するCPU1023によって、管理情報群1029内で管理される。
ディスクコントローラ1020は、管理I/F1021、データI/F1022、ディスクI/F1025、メインメモリ1026、CPU1023、タイマ1024を備えている。
メインメモリ1026には、管理情報群1029と、制御プログラム1028と、マーカー管理テーブル1030と、ジャーナル管理テーブル1031とが記憶される。CPU1023は、メインメモリ1026に記憶されたプログラムを実行する。
制御プログラム1028がCPU1023に実行されることにより、スナップショットの取得、ジャーナルの生成、ジャーナリングを用いたリストア、ジャーナルの開放などのジャーナリングを用いたバックアップ技術を実現するために必要な処理が行われる。以下、コンピュータプログラムが主語になる場合は、実際にはそのコンピュータプログラムを実行するCPUによって処理が行われるものとする。
また、制御プログラム1028は、ジャーナリングを用いたバックアップ技術を用いてリカバリを支援するためにマーカーを生成、管理する。マーカーとは、テキストデータを含むデータである。また、マーカーは、ジャーナルの作成順序と関連付けられて管理される。このため、マーカーは、リカバリを行う際にリカバリポイント選択のための指標として用いることができる。
さらに、制御プログラム1028は、管理計算機1200やホスト計算機1100からの要求に応じディスク装置1010に対するデータの入出力を処理することや、ストレージシステム1000内の構成情報(論理ボリュームの構成等)や制御情報の設定を行うことができる。ストレージシステム1000の構成の設定としては、例えば、どの論理ボリュームがデータボリューム1011なのか等の論理ボリュームの種別を示す情報や、データボリューム1011がどのジャーナルグループに所属しているのか等のボリューム間の関係性を示す情報の設定がある。この構成の設定を表した情報は、構成情報の全部叉は一部として、管理情報群1029に含まれる。制御プログラム1028は、管理情報群1029の情報を参照または更新しながら上述した種々の処理を実行することができる。
ここで、ジャーナリングを用いたバックアップ技術に関連する制御プログラム1028の動作のうち、本実施形態の説明に必要な動作について述べておく。
制御プログラム1028は、スナップショット、ジャーナル、マーカーの作成順序を管理する。これにより、データのリストアを行う際に、どのスナップショットにどのジャーナルをどのような順番で適用していけばよいのかが特定できるようになる。
具体的な作成順序の管理方法と利用方法は、例えば、次の通りである。
まず、この作成順序を管理するために、制御プログラム1028が、ジャーナルグループ1014毎に順序番号を管理している。
そして、制御プログラム1028は、ホスト計算機1100からデータボリューム1011への書き込みを受け付けると、当該データボリューム1011に対して書込みを行う。このとき、制御プログラム1028は、書き込みデータをジャーナルとし、当該データボリューム1011が属するジャーナルグループ1014の順序番号を、当該ジャーナルに割り振る。そして、制御プログラム1028は、当該ジャーナルを、当該データボリューム1011が属するジャーナルグループ1014に関連付けられたジャーナルボリューム1013に、格納する。その後、制御プログラム1028は、当該ジャーナルグループ1014の順序番号に1を加算する。
また、制御プログラム1028は、後述するリカバリマネージャ1162やバックアップ指示プログラム1252からマーカー作成要求を受け付けると、マーカーを作成し、当該データボリューム1011が属するジャーナルグループ1014の順序番号を、当該マーカーに割り振る。そして、制御プログラム1028は、当該マーカーを、当該データボリューム1011が属するジャーナルグループ1014に関連付けられたマーカー管理テーブル1030(後述する)に、格納する。その後、制御プログラム1028は、当該ジャーナルグループ1014の順序番号に1を加算する。
さらに、制御プログラム1028は、後述するリカバリマネージャ1162やバックアップ指示プログラム1252からスナップショット取得要求を受け付けると、指定されたジャーナルグループ1014に属するデータボリューム1011のスナップショットを、当該ジャーナルグループ1014に関連付けられたSSVOLグループ1015に属するスナップショットボリューム1012に、格納する。次に、制御プログラム1028は、当該ジャーナルグループ1014の順序番号を、スナップショットに割り振る。その後、制御プログラム1028は、当該ジャーナルグループ1014の順序番号に1を加算する。
以上の処理を、制御プログラム1028が行うことで、スナップショット、ジャーナル、マーカーの作成順序が、管理される。
この作成順序は、リストアの際に、制御プログラム1028によって利用される。制御プログラム1028は、この作成順序を用いて基底スナップショットに適用すべきジャーナルとその適用順序とを特定する。具体的には、特定のスナップショット(基底スナップショットとなる)にジャーナルを適用してリストアを行う場合、制御プログラム1028は、当該スナップショットより大きく且つ指定されたリカバリポイントのジャーナル以下の順序番号を持つジャーナルを、順序番号に従って適用する。また、リカバリポイントとしてマーカーを指定した場合は、制御プログラム1028は、基底スナップショットより大きく且つ指定されたリカバリポイントのマーカーより小さい順序番号を持つジャーナルを、順序番号に従って適用する。以上の処理を、制御プログラム1028が行うことでリストアが行われる。
管理情報群1029は、ジャーナリングを用いたバックアップの各種機能を実行するための情報であり、上述したように、例えば、どの論理ボリュームがデータボリューム1011なのか、どの論理ボリュームがスナップショットボリューム1012なのか等の論理ボリュームの種別を示す情報や、データボリューム1011がどのジャーナルグループ1014に所属しているのか等のボリューム間の関係性を示す情報が含まれる。
マーカー管理テーブル1030及びジャーナル管理テーブル1031については、後述する。
タイマ1024は、現在時刻を提供する機能を持つ一般的なタイマである。ジャーナル作成時やスナップショット取得時に、制御プログラム1028によって参照される。
データI/F1022は、データネットワーク1300に対するインタフェースであって、一つ以上の通信用ポートを持つ。ディスクコントローラ1020は、このポートを介してホスト計算機1100、他のストレージシステム1000と、データや制御命令の送受信を行う。管理I/F1021は、管理ネットワーク1400とのインタフェースであって、ホスト計算機1100、管理計算機1200と、データや制御命令の送受信を行う。ディスクI/F1025は、ディスク装置1010に対するインタフェースであって、データや制御命令の送受信を行う。
ホスト計算機1100は、キーボードやマウスなどの入力装置1140、CPU1130、CRTなどの表示装置1120、メモリ1160、データI/F1110、管理I/F1150を備える。
データI/F1110は、データネットワーク1300に対するインタフェースであって、一つ以上の通信ポートを持つ。このポートを介して、ホスト計算機1100は、ストレージシステム1000と、データや制御命令の送受信を行う。管理I/F1150は、管理ネットワーク1400に対するインタフェースであって、システム管理のために管理計算機1200及びストレージシステム1000と、データや制御命令の送受信を行う。
メモリ1160には、アプリケーション1161、リカバリマネージャ1162、整合性確認時間取得エージェント1163が記憶される。CPU1130は、メモリ1160に記憶された各種プログラムを実行することで、各機能を実現する。
アプリケーション1161は、データボリューム1011を利用するアプリケーションプログラムであり、例えば、DBMSやファイルシステムである。
リカバリマネージャ1162は、例えば、アプリケーション1161の静止化、ストレージシステム1000に対するスナップショット取得の要求や特定時点のデータのリストア要求等を行うプログラムである。また、リカバリマネージャ1162は、アプリケーションの静止化などのイベントやユーザの指示に応じて、ストレージシステム1000にマーカーの挿入を要求する。リカバリマネージャ1162は、ユーザや他のプログラムがこれらの機能を実行できるように、ユーザや他のプログラムに対するインタフェースとして、コマンドラインインタフェース(以降、「CLI」と呼ぶ)などを提供する。
整合性確認時間取得エージェント1163は、後述する整合性確認時間モニタ1256の要求に従い、当該要求を受け付けた時点におけるデータボリューム1011内のデータの整合性を確認するために、アプリケーション1161が必要とする時間(以下、「整合性確認時間」)を取得するプログラムである。例えば、アプリケーション1161がOracle DBというDBMSであれば、整合性確認時間取得エージェント1163は、MTTR(Mean Time To Repair)アドバイザというツールから、クラッシュリカバリに必要な時間を、整合性確認時間として取得することができる。また、例えば、アプリケーション1161が一般的なファイルシステムであれば、他の作業にリソースが利用されていなければ、FSCKに必要な時間は主にファイル数(有効なi-nodeの数)に依存するため、整合性確認時間取得エージェント1163は、ファイル数ごとに過去のFSCKにかかった時間の実績値を保持しておくことで、現在のファイル数から整合性確認時間を推定することが可能である。また、ジャーナリングファイルシステムでは、ほぼ数秒単位でFSCKが完了することが知られているため、整合性確認時間は、数秒単位の時間となる。
また、整合性確認時間取得エージェント1163は、アプリケーションがDBMSである場合は、DBMSがチェックポイントを発行するタイミング(データボリューム1011に反映されていないデータを全て反映させるタイミング)を、監視する。DBMSがチェックポイントを発行すると、整合性確認時間取得エージェント1163は、整合性確認時間モニタ1256に整合性確認時間取得を指示する。
なお、説明の都合上、図1では、アプリケーション1163を一つとしたが、本実施形態ではこれ以上設置してもよい。
管理計算機1200は、キーボードやマウスなどの入力装置1240、CPU1230、CRTなどの表示装置1220、メモリ1250、管理I/F1210を備える。
管理I/F1210は、システム管理のために、ホスト計算機1100及びストレージシステム1000と、データや制御命令を送受信する。
メモリ1250には、設定プログラム1251、バックアップ指示プログラム1252、リカバリ指示プログラム1253、JNLG管理テーブル1254、ボリューム管理テーブル1255、整合性確認時間モニタ1256、モニタ管理テーブル1257が記憶される。CPU1230は、メモリ1250に記憶された各種プログラムを実行することで、各機能を実現する。
設定プログラム1251は、JNLG管理テーブル1254、ボリューム管理テーブル1255、モニタ管理テーブル1257に値を設定するためのプログラムである。設定プログラム1251は、ユーザにこれらの値を設定させるためのインタフェースとして、CLIなどを提供する。
バックアップ指示プログラム1252は、一以上のジャーナルグループ1014の中から選択されたジャーナルグループ1014に属するアプリケーション1161群の静止化ポイントを、記録するためのプログラムである。ここで、ジャーナルグループ1014に属するアプリケーション1161群とは、当該ジャーナルグループ1014を構成する一以上のデータボリューム1011のうち、いずれか一つ又はそれ以上を利用するアプリケーションの集合体のことである。以降、ジャーナルグループに属するボリュームを利用するアプリケーションのことを、単に、「ジャーナルグループに属するアプリケーション」と呼ぶ。当該プログラムの動作の詳細は、後述する。
リカバリ指示プログラム1253は、ユーザの指示に従い、指示されたジャーナルグループ1014に属するアプリケーション1161を、指定された時点(リカバリポイント)におけるデータを用いてリカバリするためのプログラムである。当該プログラムの動作の詳細は、後述する。
整合性確認時間モニタ1256は、特定のジャーナルグループ1014に属するアプリケーション1161が、特定の時点におけるデータボリューム1011内のデータを用いてリカバリを行う際に、当該データの整合性確認を行うために必要な時間を取得するためのプログラムである。当該プログラムの動作の詳細は、後述する。
JNLG管理テーブル1254、ボリューム管理テーブル1255、モニタ管理テーブル1257の詳細は後述する。
以下、図2から図6まで、本実施形態に係る計算機システムが備える種々のテーブルの構成例を示す。なお、各図のテーブルにおいて、参照番号が付されているのは、カラム或いはフィールドを指し、カラム或いはフィールドに格納される値それ自体を指してはいない。従って、以下の説明では、カラム或いはフィールドを指す場合には、参照番号を付して説明し、カラム或いはフィールドを指しているわけではない場合には、参照番号を付さずに説明することにする。第二、第三の実施形態の説明においても同様とする。
図2は、JNLG管理テーブル1254の一例である。
当該テーブル1254は、アプリケーション1161がどのジャーナルグループ1014に属するかという対応関係を管理する。AP_ID2001は、当該計算機システムにおけるアプリケーション1161の識別子を格納するカラムである。JNLG_ID2002は、前記アプリケーション1161が属するジャーナルグループ1014の識別子を格納するカラムである。AP管理用ネットワークアドレス2003は、前記アプリケーション1161が稼動しているホスト計算機1100のネットワークアドレスが格納されるカラムである。AP管理用ネットワークアドレス2003に格納される値として、たとえばIPアドレスが用いられる。
JNLG管理テーブル1254における各情報要素の対応関係は、設定プログラム1251が提供するCLIを用いて、ユーザによって設定される。
図3は、ボリューム管理テーブル1255の一例である。
当該テーブル1255は、アプリケーション1161と当該アプリケーション1161が利用するデータボリューム1011との対応関係を管理する。AP_ID3001は、当該計算機システムにおけるアプリケーション1161の識別子を格納するカラムである。データボリュームID3002は、前記アプリケーション1161が利用するデータボリューム1011のIDを格納するカラムである。ストレージ管理用ネットワークアドレス3003は、前記データボリューム1011を格納するストレージシステム1000のネットワークアドレスを格納するカラムである。ストレージ管理用ネットワークアドレス3003に格納される値として、たとえばIPアドレスが用いられる。
ボリューム管理テーブル1255における各情報要素の対応関係は、設定プログラム1251が提供するCLIを用いて、ユーザによって設定される。
図4は、モニタ管理テーブル1257の一例である。
当該テーブル1257は、ジャーナルグループ1014に属するアプリケーション1161の整合性確認時間を取得する間隔を管理する。JNLG_ID4001は、取得の対象となるアプリケーション1161群が属するジャーナルグループ1014のIDを格納するカラムである。モニタ間隔4002は、当該ジャーナルグループ1014に属するアプリケーション1161の整合性確認時間を取得する間隔を格納するカラムである。たとえば、モニタ間隔4002に格納された値が、「60Sec」であれば、60秒周期で整合性確認時間の取得が行われる。
モニタ管理テーブル1257における各情報要素の対応関係は、設定プログラム1251が提供するCLIを用いて、ユーザによって設定される。
図5は、マーカー管理テーブル1030の一例である。
当該テーブル1030は、マーカーを管理するテーブルである。また、当該テーブル1030はジャーナルグループ1014毎に管理されている。時刻5001は、マーカーが作成された時刻を格納するカラムである。順序番号5002は、当該マーカーに割り振られた順序番号を格納するカラムである。当該順序番号は、前述の通り、マーカーやジャーナルやスナップショットが作成された順序の関係を示す。データ5003は、マーカーに付与されたテキストデータが格納されるカラムである。
マーカー管理テーブル1030にて管理されるマーカーは、例えば、以下のようにして作成される。すなわち、後述するリカバリマネージャ1161やバックアップ指示プログラム1252が、マーカーに付与すべきテキストデータをパラメータとして、制御プログラム1028にマーカー作成を要求する。作成要求を受けた制御プログラム1028は、タイマ1024から、例えば、マーカー作成の要求を受けた時の時刻を取得して時刻5001に設定する。また、制御プログラム1028は、現在の順序番号を当該マーカーに割り振って、その順序番号を順序番号5002に設定する。このとき、上述したように、制御プログラム1028がジャーナルグループ毎に管理している順序番号には、1が加算される。さらに、パラメータとして指定されたテキストデータを制御プログラム1028がデータ5003に設定する。具体的には、「静止化ポイント」や「整合性確認時間(DB1:100Sec, DB2:150Sec, FS3:0Sec)」といったテキストデータ(テキストに限らず他の形式でもよい)である。
図6は、ジャーナル管理テーブル1031の一例である。
当該テーブル1031は、ジャーナルのメタデータを管理する。また、当該テーブルはジャーナルグループ毎に管理されている。時刻6001は、ジャーナルが作成された時刻を格納するカラムである。順序番号6002は、当該ジャーナルに割り振られた順序番号を格納するカラムである。当該順序番号は、前述の通り、マーカーやジャーナルやスナップショットが作成された順序の関係を示す。適用先ボリューム6003は、ジャーナルを適用するデータボリューム1011の識別子を格納するカラムである。適用先アドレス6004は、ジャーナルを適用するアドレスを格納するカラムである。格納ボリューム6005は、当該ジャーナルが格納されているボリュームの識別子が格納されるカラムである。格納アドレス6006は、当該ジャーナルが格納されているアドレスを格納するカラムである。データ長6007は、当該ジャーナルの長さが格納されるカラムである。
これらのカラムには、ホスト計算機1100からの書込みに対してジャーナルを作成するたびに、制御プログラム1028が、値を設定する。まず、制御プログラム1028は、タイマ1024から、例えば、ジャーナル作成の要求を受けた時の時刻を取得して時刻5001に設定する。また、制御プログラム1028は、現在の順序番号を当該ジャーナルに割り振って、その順序番号を順序番号5002に設定する。このとき、上述したように、制御プログラム1028がジャーナルグループ毎に管理している順序番号には、1が加算される。さらに、制御プログラム1028は、書き込み要求を参照し、書き込み先のデータボリューム1011の識別子を適用先ボリューム6003に、書き込み先のアドレスを適用先アドレス6004に、ジャーナルを格納するボリュームのIDを格納ボリューム6005に、ジャーナルを格納するアドレスを格納アドレス6006に、書き込みデータの長さをデータ長6007に、それぞれ設定する。
尚、図1に示されてはいないが、メインメモリ1026には、スナップショットボリューム管理テーブル24000と、SSVOLグループ管理テーブル25000とが記憶される。
図24は、スナップショットボリューム管理テーブル24000の構成例を示す。
スナップショットボリューム管理テーブル24000には、SSVOLグループ1015を構成するスナップショットに関する情報が記録される。例えば、各SSVOLグループ(スナップショットボリュームグループ)1015毎に、該SSVOLグループのID、該SSVOLグループに属するスナップショットボリュームのID、及び該SSVOLグループに対応付けられたデータボリュームのIDが格納される。具体的には、例えば、本テーブルには、SSVOLグループID24001、スナップショットボリュームID24002及び対応データボリュームID24003がある。
SSVOLグループID24001は、管理対象となるSSVOLグループの識別子が格納されるカラムである。
スナップショットボリュームID24002は、論理ボリューム(スナップショットボリューム)の識別子が格納されるカラムである。該カラムの各エントリ(セル)には、該エントリが対応するSSVOLグループIDが割り当てられたSSVOLグループに属するスナップショットボリュームのIDが格納される。
対応データボリュームID24003は、スナップショット取得対象のデータボリュームの識別子を格納する。該カラムの各エントリ(セル)には、該エントリが対応するSSVOLグループIDが割り当てられたSSVOLグループに対応付けられたデータボリュームのIDが格納される。
これらの値は、例えば、設定プログラム1251が提供するCLIを管理者が用いて、SSVOLグループにスナップショットボリュームとなる論理ボリュームを追加することで設定することが可能である。
図25は、SSVOLグループ管理テーブル25000の構成例を示す。
SSVOLグループ管理テーブル25000には、ジャーナルグループ1014とSSVOLグループ1015の関連付けに関する情報が記録される。例えば、各ジャーナルグループ1014毎に、該ジャーナルグループのIDと、該ジャーナルグループに対応するSSVOLグループのIDと、該SSVOLグループに対応したスナップショットの順序番号と、該スナップショットの取得時刻とが記録される。具体的には、例えば、本テーブル25000には、JNLG_ID25001、SSVOLグループID25002、順序番号25003及び取得時刻25004がある。
JNLG_ID25001は、管理対象となるジャーナルグループの識別子が格納されるカラムである。
SVOLグループID25002は、JNLG_ID25001で示されるジャーナルグループのスナップショットを格納するSSVOLグループの識別子が格納される。
これらの値は、例えば、設定プログラム1251が提供するCLIを管理者が用いて、ジャーナルグループにSSVOLグループを関連付けることにより設定することが可能である。
順序番号25003は、当該スナップショットに割り振られた順序番号を格納するカラムである。当該順序番号は、前述の通り、マーカーやジャーナルやスナップショットが作成された順序の関係を示す。
取得時刻25004は、スナップショットが作成された時刻を格納するカラムである。
(2)第一の実施形態の動作。
次に、本実施形態の動作を説明する。
図7は、バックアップ指示プログラム1252の処理の流れを示したものである。
本処理では、連携する全アプリケーション1161にとって、データの整合性が保たれている時点が記録される。本処理は、ユーザがバックアップ指示プログラム1252を起動することで開始される。
本処理が起動されると、まずバックアップ指示プログラム1252は、静止化指示が発生するまで待機する(ステップ7010)。この静止化指示は、例えば、バックアップ指示プログラム1252が提供するCLIを介して、ユーザやジョブスケジューラが静止化の要求を出したときに発生する。ユーザやジョブスケジューラは、当該CLIのパラメータとして、特定のジャーナルグループ1014を指定する。
静止化指示を受け付けると、バックアップ指示プログラム1252は、パラメータに指定されたジャーナルグループ1014に属する全てのアプリケーション1161を静止化する(ステップ7020)。静止化対象のアプリケーション1161は、JNLG管理テーブル1254を参照することで特定可能である。本ステップでは、バックアップ指示プログラム1252はリカバリマネージャ1162と通信を行い、リカバリマネージャ1162にアプリケーション1161の静止化指示を発行する。当該通信は、AP管理用ネットワークアドレスとリカバリマネージャ1162固有のポート番号とを利用することで確立される。
次に、バックアップ指示プログラム1252は、ステップ7020で指示した全てのアプリケーション1161の静止化が完了するまで待機する(ステップ7030)。
全てのアプリケーション1161の静止化の完了を確認した後に、バックアップ指示プログラム1252は、パラメータで指定されたジャーナルグループ1014の静止化ポイントとして、マーカーを挿入するように、制御プログラム1028に指示する(ステップ7040)。本ステップでは、バックアップ指示プログラム1252は、制御プログラム1028と通信を行い、マーカーの挿入指示を発行する。当該通信は、パラメータで指定されたジャーナルグループ1014に属するデータボリューム1011に対応するストレージ管理用ネットワークアドレス3003のうちの一つと制御プログラム1028固有のポート番号とを利用することで確立される。当該指示を受け付けた制御プログラム1028は、前述したように、マーカーを作成し、マーカー管理テーブル1030へ格納する。
次に、バックアップ指示プログラム1252は、パラメータに指定されたジャーナルグループ1014に属する全てのアプリケーション1161の静止化を解除する(ステップ7050)。本ステップでは、前記ステップ7020と同様に、バックアップ指示プログラム1252はリカバリマネージャ1162と通信を行い、リカバリマネージャ1162に静止化解除指示を発行する。
次に、バックアップ指示プログラム1252は、ステップ7050で指示した全てのアプリケーション1161の静止化解除が完了するまで待機する(ステップ7060)。
そして、全アプリケーション1161の静止化解除が完了すると、バックアップ指示プログラム1252の処理は、ステップ7010に戻る。
以上が、バックアップ指示プログラム1252の処理の流れである。
図8は、整合性確認時間モニタ1256と整合性確認時間取得エージェント1163の処理の流れの一つを示したものである。
本処理では、アプリケーション1161毎の特定時点におけるデータボリューム1011内のデータの整合性を確認するために必要となる時間、すなわち、整合性確認時間が記録される。本処理は、ユーザが、パラメータとして特定のジャーナルグループ1014を指定して、整合性確認時間モニタ1256を起動することで開始される。
本処理が起動されると、まず整合性確認時間モニタ1256は、整合性確認時間の取得タイミングまで待機する(ステップ8010)。待機する時間は、パラメータに指定されたジャーナルグループ1014に対応するモニタ間隔4002に基づいて決定される。たとえば、モニタ管理テーブル1257の当該ジャーナルグループ1014に対応するモニタ間隔4002に格納されている値が、「60Sec」となっている場合は、整合性確認時間モニタ1256は、60秒間待機することとなる。
次に、整合性確認時間モニタ1256は、本ステップを処理する時点におけるデータボリューム1011内のデータの整合性確認時間の取得を、整合性確認時間取得エージェント1163に要求する(ステップ8020)。この要求は、パラメータに指定されたジャーナルグループ1014に属するアプリケーション1161が動作する全ホスト計算機1100上の整合性確認時間取得エージェント1163に通知される。本ステップでは、整合性確認時間モニタ1256は整合性確認時間取得エージェント1163と通信を行う。当該通信は、AP管理用ネットワークアドレスと整合性確認時間取得エージェント1163固有のポート番号とを利用することで確立される。
整合性確認時間の取得指示を受け付けた整合性確認時間取得エージェント1163は、アプリケーションの整合性確認時間を取得し、取得した整合性確認時間を整合性確認時間モニタ1256へ通知する(ステップ8030)。当該整合性確認時間は、前述のとおりMTTRアドバイザなどを用いて取得される。
整合性確認時間モニタ1256は、アプリケーションの整合性確認時間の取得を指示した全整合性確認時間取得エージェント1163からの完了応答が返ってくるまで待機する(ステップ8040)。
全整合性確認時間取得エージェント1163からの完了応答が返ると、整合性確認時間モニタ1256は、パラメータで指定されたジャーナルグループ1014のマーカー管理テーブル1030に、取得した整合性確認時間情報をマーカーとして挿入するように、制御プログラム1028に指示する(ステップ8050)。ここで、マーカーに付与するテキストデータは、たとえば「整合性確認時間(DB1:100Sec, DB2:150Sec, FS3:0Sec)」といったものである。これは、識別子がDB1であるアプリケーション1161の整合性確認時間が100秒、識別子がDB2であるアプリケーション1161の整合性確認時間が150秒、識別子がFSであるアプリケーション1161の整合性確認時間が0秒である、ということを示す。その後、整合性確認時間モニタ1256の処理は、ステップ8010へ移行する。
以上が、性確認時間モニタ1256と整合性確認時間取得エージェント1163の処理の流れの一つである。
なお、ステップ8050において、整合性確認時間情報をマーカーとしてマーカー管理テーブル1030に格納したが、変形例として、整合性確認時間モニタ1256は適当な識別子をマーカーとして挿入するように指示し、当該識別子と整合性確認時間の対応関係をメモリ1250において管理しておくようにしても良い。
図9は、整合性確認時間取得エージェント1163と整合性確認時間モニタ1256の処理の流れの一つを示したものである。
本処理では、単一のDBMSがチェックポイントを発行するなどのタイミングに応じて、アプリケーション1161毎の当該時点におけるデータボリューム1011内のデータの整合性確認時間を記録する。本処理は、ユーザが、パラメータとして管理計算機1200のネットワークアドレスを指定して、整合性確認時間取得エージェント1256を起動することで開始される。なお、本処理は、図8で示した処理と同一部分が含まれるため、同一部分の説明は省略する。
本処理が起動されると、まず整合性確認時間取得エージェント1163は、DBMSのチェックポイント発行タイミングを監視する(ステップ9010)。
DBMSがチェックポイントを発行すると、整合性確認時間取得エージェント1163は、整合性確認時間モニタ1256に、当該DBMSが属するジャーナルグループ(静止化対象のジャーナルグループ)1014に属する全アプリケーション1161の整合性確認時間取得を要求する。この際、整合性確認時間取得エージェント1163は、パラメータで指定されたネットワークアドレスと整合性確認時間モニタ1256固有のポート番号とを用いて、整合性確認時間モニタ1256との通信を確立する(ステップ9020)。
整合性確認時間モニタ1256が当該要求を受け付けた以降のステップ8020から8050までは、前述した通りの処理を行う。
そして、整合性確認時間取得エージェント1163は、静止化対象のジャーナルグループ1014に属する全アプリケーション1161の整合性確認時間取得要求に対する整合性確認時間モニタ1256からの応答を待つ(ステップ9030)。そして、応答があり次第、整合性確認時間取得エージェント1163の処理は、ステップ9010へ進む。
以上が、性確認時間モニタ1256と整合性確認時間取得エージェント1163の処理の流れの一つである。これにより、DBMS等のアプリケーション1161による整合性確認時間が0となる時点を記録することができる。
図10は、リカバリ指示プログラム1253の処理の流れを示したものである。
本処理は、ユーザが、パラメータとして特定のジャーナルグループ1014を指定して、リカバリ指示プログラム1253を起動することで開始される。
本処理が起動されると、まずリカバリ指示プログラム1253は、指定されたジャーナルグループ1014のリストア可能な時点の範囲を、制御プログラム1028から取得する(ステップ10010)。制御プログラム1028は、SSVOLグループ管理テーブル25000を参照することにより、リストア可能な時点の範囲を算出することができる。当該範囲は、例えば、「2006/11/10 0:00〜2006/11/15 11:00」といった形で表現される。
次にリカバリ指示プログラム1253は、指定されたジャーナルグループ1014のマーカー管理テーブル1030の情報を、制御プログラム1028から取得する(ステップ10020)。
次にリカバリ指示プログラム1253は、ステップ10010において取得したリストア可能な時点の範囲と、ステップ10020において取得したマーカーの情報を用いて、リカバリポイント選択画面をユーザにGUI(グラフィカルユーザインタフェース)で提示する(ステップ10030)。この表示形式の一例については、後述する。なお、変形例として、CUI(キャラクタユーザインタフェース)で提示しても良い。
提示されたリカバリポイント選択画面から、ユーザがリカバリポイントを選択する(ステップ10040)。
次に、リカバリ指示プログラム1253は、選択されたリカバリポイントが静止化ポイントであるか否かを判定する(ステップ10050)。例えば、リカバリ指示プログラム1253は、ステップ10020において取得したマーカー管理テーブル1030の情報から、選択されたリカバリポイントが静止化ポイントであるか否かを判定する。
静止化ポイントである場合(ステップ10050:YES)、リカバリ指示プログラム1253は、パラメータとして指定されたジャーナルグループ1014のリストアを、制御プログラム1028へ指示する(ステップ10060)。当該指示は、ストレージ管理用ネットワークアドレス3003と制御プログラム1028固有のポート番号とを用いて通信を確立することで実行される。制御プログラム1028は、当該指示を受け付けるとリストアを実行する。
次に、リカバリ指示プログラム1253は、ステップ10060において指示したリストアが完了するまで待機する(ステップ10070)。リストアが完了すると、リカバリ指示プログラム1253は、指定されたジャーナルグループ1014に属する全てのアプリケーション1161に対して整合性確認を行うように指示する(ステップ10080)。リカバリポイントが静止化ポイントである場合は、整合性確認の指示を受けたアプリケーション1161は、FSCK等のデータの整合性確認を行うことなく、ボリュームのマウントを行う。尚、リカバリポイントが静止化ポイントである場合は、リカバリ指示プログラム1253は、アプリケーション1161に対して整合性確認の指示をするのではなく、ボリュームのマウントを指示してもよい。
次にリカバリ指示プログラム1253は、ステップ10080において指示した整合性の確認が完了するまで待機し(ステップ10090)、当該整合性の確認が完了したら処理を終了する。
一方、ステップ10050において、リカバリポイントが静止化ポイントでないと判定された場合(ステップ10050:NO)、リカバリ指示プログラム1253は、アプリケーション1161毎の整合性確認時間を推定する(ステップ10100)。このときリカバリ指示プログラム1253は、ステップ10020において取得したマーカー管理テーブル1030の情報から、リカバリポイントから最も近い過去とリカバリポイントから最も近い未来との整合性確認時間が付与されマーカーを取得する(以降、過去のものを直前のマーカー、未来のものを直後のマーカーと呼ぶ)。そして、リカバリ指示プログラム1253は、この二つのマーカーからアプリケーション毎の整合性確認時間を推定する。例えば、アプリケーション1161がDBMSである場合は、一般に、クラッシュリカバリに必要となる時間は、特定の契機(通常はチェックポイント作成のタイミング)で0秒になり、その後、単調に増加する。このため、リカバリ指示プログラム1253は、直前のマーカーと直後のマーカーとが示す整合性確認時間から、整合性確認時間のおおよその変化量を計算して、それらの値からリカバリポイントにおける整合性確認時間を推定することができる。本実施形態では、リカバリ指示プログラム1253は、直前のマーカーにおける整合性確認時間と直後のマーカーにおける整合性確認時間の平均をリカバリポイントにおける整合性確認時間の推定値としている。変形例としては、リカバリポイントの時刻が、直前と直後のマーカーが挿入された時刻からどの程度はなれているかによって、重みをつけて、推定値が求められても良い。あるいは、直前のマーカーにおける整合性確認時間や直後のマーカーにおける整合性確認時間が、推定値として扱われても良い。また、直後のマーカーがない場合は、直前のマーカーに付与された整合性確認時間が、推定値とされても良い。また、アプリケーション1161が一般的なファイルシステムである場合は、直前のマーカーが示す整合性確認時間と直後のマーカーが示す整合性確認時間との平均値が、推定値となる。アプリケーション1161がジャーナリングファイルシステムである場合は、整合性確認時間がほぼ数秒である。
次にリカバリ指示プログラム1253は、整合性確認時間の推定値が最も長いアプリケーション1161が利用するボリュームを、リストアするように制御プログラム1028へ指示する(ステップ10110)。制御プログラム1028は、当該指示を受け付けると、ジャーナリングを用いたリストアを実行する。
次にリカバリ指示プログラム1253は、ステップ10110において指示したリストアが完了するまで待機する(ステップ10120)。
リストアが完了すると、リカバリ指示プログラム1253は、ステップ10110においてリストアを指示したボリュームを利用するアプリケーション1161に対して、整合性の確認を指示する(ステップ10130)。
次にリカバリ指示プログラム1253は、まだリストアしていないボリュームがあるかを判断する(ステップ10140)。全てリストア済みである場合(ステップ10140:NO)、リカバリ指示プログラム1253の処理は、ステップ10090に進み、リカバリ指示プログラム1253は、ステップ10130で指示した整合性確認が全て終了するまで待機する。整合性確認が全て終了すると、リカバリ指示プログラム1253は、処理を終了する。
一方、まだリストアが完了していないボリュームがある場合は(ステップ10140:YES)、リカバリ指示プログラム1253は、先ほどリストアしたボリューム以外のボリュームの中で、そのボリュームを利用するアプリケーション1161の整合性確認時間の推定値が最も長いものをリストアするように、制御プログラム1028へ指示する(ステップ10150)。その後、リカバリ指示プログラム1253の処理は、ステップ10120へ進む。
以上が、リカバリ指示プログラム1253の処理の流れである。
なお、本実施形態では、ステップ10110及びステップ10150において、ボリュームのリストア指示は、単一アプリケーション1161毎に行われているが、変形例において、複数のアプリケーション1161が利用する複数のボリュームに対して、一括して行われてもよい。つまり、CPU1023が複数存在するストレージシステム1000など、特定のボリューム数まで並行にリストアしても個々のリストアの性能が劣化しないストレージシステム1000が存在する。このストレージシステム1000を利用する場合、性能が劣化しない上限まで、複数のボリュームを並行してリストアが行われても問題ない。このため、単一のアプリケーション1161が利用するボリューム数が当該上限数よりも小さい場合は、リカバリ指示プログラム1253は、リストアが行われるボリューム数が当該上限数を超えない範囲で、他のアプリケーション1161のボリュームをリストアするように指示することができる。なお、このときリストア対象のボリュームは、整合性確認時間の長いアプリケーション1161の順番に従って選択される。
また、本実施形態では、ステップ10100において、アプリケーション1161の整合性確認時間が推定され、その長さに応じて利用するボリュームのリストア順序が決定されたが、変形例として、アプリケーション1161のタイプで、当該アプリケーション1161が利用するリストア順序が決定されても良い。つまり、一般的なファイルシステムの整合性確認時間は一般的に長いため、一般的なファイルシステムが利用するボリュームが、優先的にリストアされるようにしてもよい。また、ジャーナリングファイルシステムの整合性確認時間は一般的に数秒であるため、ジャーナリングファイルシステムが利用するボリュームのリストアを後回しにするといった方法で、ボリュームのリストア順序が決定されても良い。
図11Aは、ステップ10030において、リカバリ指示プログラム1253がユーザに提示するGUIの例である。
符号11010は、リストア可能な時点の範囲を数直線で示した図である。符号11012は、マーカーが挿入された時刻を示すアイコンである。本アイコン11012は、マーカーに付与されたテキストデータの内容に応じて形や色を変更しても良い。符号11013は、マウス等の入力装置によって移動するポインタである。ステップ10040において、ユーザがリカバリポイントの選択を行う際に移動させる。
符号10021は、マーカーに付与されているテキストデータを表示するテキストフィールドである。ユーザが、符号11010の数直線上のアイコン11012にポインタ11013を移動させ、クリックすると、当該アイコン11012に対応するマーカーに含まれているテキストデータが、このテキストフィールド10021に表示される。なお、アイコン11012が存在しない数直線上の点をクリックされても、テキストフィールド11021には何も表示されない。符号11022は、リカバリポイントの時刻を表示するテキストフィールドである。ユーザが、符号11010の数直線上の一点にポインタ11013を移動させ、クリックすると、当該点に対応する時刻が、このテキストフィールド11022に表示される。
符号11031は、リカバリポイントの選択を確定するためのボタンである。ユーザが、本ボタン11031を押下すると、テキストフィールド11022に表示された時点のデータをリカバリすることが、リカバリ指示プログラム1253へ要求されたことになる。符号11032は、図10を用いて説明した処理を終了するためのボタンである。ユーザが、本ボタン11032を押下すると、図10を用いて説明した処理を終了することが、リカバリ指示プログラム1252へ要求されたことになる。本要求を受け取ったリカバリ指示プログラム1253は、処理を強制終了する。
以上が、ステップ10030において表示されるインタフェースの例である。
図11Bは、ステップ10030において、リカバリ指示プログラム1253がユーザに提示するGUIの別の例である。
符号11040は、リストア可能な時点の範囲と複合アプリケーションの業務再開までの時間との関係を示した2次元グラフである。ここで、複合アプリケーションとは、連携して動作している複数のアプリケーション全体のことをいう。従って、複合アプリケーションの業務再開までの時間とは、連携して動作している複数のアプリケーションのそれぞれが利用する全てのボリュームについて、リカバリが完了するまでに要する時間となる。尚、リカバリにかかる時間は、リストアにかかる時間と整合性確認時間とを足し合わせたものである。当該グラフ11040の横軸は、リストア可能な時刻を示す。当該グラフ11040の縦軸は、複合アプリケーションの業務再開までの時間を示す。
符号11012、11013、11021、11022、11031,11032は、図11Aのものと同様なので、説明を省略する。
符号11023は、複合アプリケーションの業務再開までの時間を表示するテキストフィールドである。ユーザが、横軸上の一点にポインタ11013を移動させ、クリックすると、当該点に対応する複合アプリケーションの業務再開までの時間が、このテキストフィールド11023に表示される。
なお、当該GUIでリカバリ時間を表示するためには、予め複合アプリケーションの業務再開までの時間を、算出しておく必要がある。このため、ステップ10020において、リカバリ指示プログラム1253が、ジャーナル管理テーブル1031の情報とジャーナル適用速度とを取得する。そして、リカバリ指示プログラム1253は、ジャーナル管理テーブル1031における適用先ボリューム6003に格納された値と適用先アドレス6004に格納された値とデータ長6007に格納された値とを用いて、各時点の各ボリュームへのジャーナル適用量を算出する。また、リカバリ指示プログラム1253は、リストア可能な範囲にある各時点のボリュームのリストア順序を決定する。そして、リカバリ指示プログラム1253は、これらの情報を元に、実際にリカバリを行った場合の時間をシミュレートする。具体的には、まず、ボリューム毎のジャーナル適用量をジャーナル適用速度で割り、各ボリュームごとにリストアにかかる時間が算出される。この各ボリュームごとに算出されたリストアにかかる時間を、リストア順序どおり足し合わせることで、各ボリュームについて、実際にリストアが完了するまでにかかる時間(以下、「リストア完了時間」)が算出される。その後、各アプリケーション1161が利用するボリュームのリストア完了時間(各アプリケーション1161が複数のボリュームを利用している場合は、最長のリストア完了時間)に、そのアプリケーション1161の整合性確認時間の推定値が足し合わされて、各アプリケーション1161についてのリカバリにかかる時間が算出される。そして、複数のアプリケーション1161のリカバリにかかる時間の中で、最も長くなったものが、複数のアプリケーションが連携して動作する計算機システムの業務再開までの時間となる。
このように、リストアされたデータの整合性確認の時間が長いアプリケーション1161のデータを優先的にリストアし、他より早く完了させることにより、長い時間必要とする整合性確認処理ほど前倒しして実行できるようになる。また、当該整合性確認処理は、ホスト計算機1100上で行われ、ストレージシステム1000のリストア処理性能に影響を与えないため、他のアプリケーション1161のデータのリストアを、当該処理と並行して実行することもできる。この結果、複数のアプリケーション1161が連携して動作する計算機システムの業務再開までの時間を、短くすることが可能になる。
<第二の実施形態>。
次に第二の実施形態について説明する。
本実施形態は、ワークフローで疎に連携する複数のアプリケーションをリストアする例である。本実施形態におけるストレージシステムは、これらのアプリケーションのデータを格納するボリュームを備え、ジャーナリングを用いたバックアップ技術で、これをバックアップ(及びリストア)する。
当該計算機システムでは、複数のアプリケーションは、お互いに処理を呼び出すことはせず、独立して処理を行う。各アプリケーションは、処理が完了すると、FTP(File Transfer Protocol)等で、次に処理を開始するアプリケーションが稼動しているホスト計算機へ、処理結果を転送する。そして、当該処理結果をインプットとして、次に処理を行うアプリケーションは、処理を開始する。このように、各処理が独立して順番に実行されるため、データ破壊などの障害発生時には、リカバリポイント直後に開始する処理を行うアプリケーションをリカバリすれば、業務を再開できる。なお、上記各処理のことをジョブと呼ぶ。また、ジョブの実行順序の定義をワークフローと呼ぶ。
ところで、前述したとおり、全ボリュームを一括してリストアすると、全ボリュームにとって、リストア完了までの時間が長くなる。この結果、全てのアプリケーションにとって、ジョブの開始時刻が遅くなり、業務再開までの時間が長くなってしまうという問題が発生する。
本実施形態では、この問題を解決するために、リカバリポイントを基点に、先にジョブが開始されるアプリケーションほど、リストアの優先度を高くする。これにより、リカバリ後すぐに処理を開始する必要があるアプリケーションほど、前倒ししてリカバリされるため、業務再開までの時間を短くすることが可能になる。
以下、本実施形態のシステム構成と動作を説明する。その際、第一の実施形態との相違点を主に説明し、第一の実施形態との共通点については、説明を省略或いは簡略する。
(1)第二の実施形態のシステム構成。
図12は、本実施形態の計算機システムの構成を示すブロック図である。
本システムでは、第一の実施形態のシステム構成に、ジョブ管理計算機12500が追加されている。そして、ジョブ管理計算機12500は、管理ネットワーク1400を介して、ストレージシステム1000、ホスト計算機1100、管理計算機1200と接続される。
ストレージシステム1000の構成は、第一の実施形態と同等であるため、説明を省略する。
ホスト計算機1100のメモリ1160には、新たにジョブ管理エージェント12163が記憶されている。また、メモリ1160に、整合性確認時間取得エージェント1163を記憶しておく必要はない。
ジョブ管理エージェント12163は、後述するジョブ管理サーバ12561の要求に応じて、アプリケーション1161のコマンドを実行するプログラムである。この動作の詳細は、後述する。
管理計算機1200のメモリ1250には、バックアップ指示プログラム1252、整合性確認時間モニタ1256、モニタ管理テーブル1257を記憶しておく必要はない。
また、JNLG管理テーブル1254’に、新たにアプリケーション1161の稼働状況を管理できるようにする必要がある。本テーブル1254’の詳細は、後述する。
さらに、リカバリ指示プログラム1253’は、第一の実施形態とは異なり、制御プログラム1028からワークフローの進捗情報を、後述するジョブ管理サーバ12561からワークフローファイル12563の情報を、それぞれ取得し、指定されたリカバリポイントの直後に処理を行うアプリケーション1161のボリュームから、リカバリを開始していく。この動作の流れは、後述する。また、リカバリ指示プログラム1253’は、整合性確認開始指示プロセス1258を備える。整合性確認開始指示プロセス1258は、アプリケーション1161の状況、すなわち、そのアプリケーション1161が利用するボリュームのリカバリ状況を監視する。そして、整合性確認開始指示プロセス1258は、リカバリが完了したアプリケーション1161へ、整合性確認処理の開始を指示する。
ジョブ管理計算機12500は、キーボードやマウスなどの入力装置12540、CPU12530、CRTなどの表示装置12520、メモリ12560、管理I/F12550を備える。
管理I/F12550は、システム管理のためにホスト計算機1100、管理計算機1200、ストレージ装置1000とデータや制御命令を送受信する。
メモリ12560には、ジョブ管理サーバ12561、ワークフローファイル12562、ワークフロー管理テーブル12563が、記憶されている。CPU12530は、メモリ12560に記憶された各種プログラムを実行することで、各機能を実現する。
ジョブ管理サーバ12561は、ワークフローファイル12562に定義されたジョブの実行順序に従い、ジョブを実行するアプリケーション1161が稼動するホスト計算機1100のジョブ管理エージェントに、ジョブの開始を要求するプログラムである。また、ジョブ管理サーバ12561は、ジョブ完了毎に、ワークフローの進捗を示すマーカーを挿入するように制御プログラム1028へ要求する。なお、本動作の詳細は、後述する。
ワークフロー管理テーブル12563の詳細は、後述する。
図13は、ワークフローファイル12562の一例である。
ワークフローファイル12562は、ワークフローの管理、すなわち、ジョブの実行順序の管理を行う。各ワークフローには、ジョブ管理計算機12500において、一意の識別子が割り振られている。実行順序13001には、本ワークフローで実行されるジョブの順序番号が、格納される。AP_ID13002には、そのジョブを実行するアプリケーションのIDが、格納される。コマンド13003には、そのジョブのコマンドのCLIが、格納される。AP管理用ネットワークアドレス13004には、ジョブを実行するホスト計算機のネットワークアドレスが、格納される。AP管理用ネットワークアドレス13004に格納される値として、たとえばIPアドレスが用いられる。これらの値は、ジョブ管理サーバ12561が提供するGUIを用いて、ユーザがワークフローの定義を行う際に設定される。
稼働状況13005には、ジョブを実行するアプリケーション1161の稼働状況が、格納される。稼働状況13005に格納される値としては、例えば、「稼働中」、「リカバリ中」のいずれか一方とすることができる。本実施形態では、ユーザがワークフロー定義を行った際に、ジョブ管理サーバ12561によって、稼働状況13005に「稼働中」が、設定される。
図14は、ワークフロー管理テーブル12563の一例である。
本テーブル12563は、ワークフローの進捗を管理する。ワークフローID14001は、管理対象となるワークフローの識別子を格納するカラムである。開始時刻14002は、ワークフローを開始するタイミングが格納されるカラムである。これらのカラムに格納される値は、ジョブ管理サーバ12561が提供するGUIを用いて、ユーザによって、ワークフロー定義を行う際に設定される。
進捗状況14003は、ワークフローの進捗状況を格納するカラムである。本カラム14003には、ワークフロー開始前であれば、例えば、「WAIT」が格納される。また、本カラム14003には、ワークフロー終了後であれば、例えば、「DONE」が格納される。ワークフロー実行中であれば、例えば、開始直後には「0」が本カラム14003に格納され、その後、ジョブ完了するたびに、完了したジョブの実行順序が本カラム14003に格納される。
図15は、JNLG管理テーブル1254’の一例である。
本テーブル1254’は、第一の実施形態とほぼ同等であるため、相違点を主に説明する。
ステータス15004は、アプリケーション1161の稼働状況を格納するカラムである。本カラム1254’には、例えば、「稼働中」、「リカバリ前」、「リストア完」のいずれかが格納される。
設定プログラム1251が提供するCLIを用いて、アプリケーション1161とジャーナルグループ1014の対応関係を設定する際に、本カラム1254’には「稼働中」が設定される。
(2)第二の実施形態の動作
次に、本実施形態の動作の説明を行う。
まず、ジョブ管理サーバ12561とジョブ管理エージェント12163のワークフロー実行時の処理の流れを、図16を用いて説明する。本処理は、ジョブ管理サーバ12561が提供するCLIを用いて、ユーザが起動する。
ユーザによって起動されると、ジョブ管理サーバ12561は、ワークフローの開始時間まで待機する(ステップ16010)。本開始時間は、ワークフロー管理テーブル12563に記憶されているものである。
開始時間になると、ジョブ管理サーバ12561は、ワークフロー管理テーブル12563における実行対象のワークフロー(以下、「実行対象ワークフロー」)の進捗状況14003に「0」を設定する(ステップ16015)。
次に、ジョブ管理サーバ12561は、実行対象ワークフローのワークフローファイル12562を参照して、開始するジョブを実行するアプリケーション1161の稼働状況を確認し、「稼働中」で無ければ、稼働中になるまで待機する(ステップ16020)。なお、開始するジョブは、実行中のワークフローにおいて、進捗状況14003に格納されている値に、「1」を加算した実行順序を持つジョブとなる。
稼働状況が「稼働中」になると、ジョブ管理サーバ12561は、ジョブを開始するようにジョブ管理エージェント12163へ指示する(ステップ16030)。このとき、ジョブ管理サーバ12561は、AP管理用ネットワークアドレスとジョブ管理エージェント12163固有のポート番号とを用いて、ジョブ管理エージェント12163と通信を確立し、ジョブ開始指示を伝える。また、ジョブ管理サーバ12561は、ジョブ開始指示と併せて、実行するアプリケーション1161とそのCLI名を引き渡す。さらに、一つ前に完了したジョブの出力が存在する場合は、ジョブ管理サーバ12561は、当該出力をジョブ管理エージェント12163へ引き渡す。
ジョブ開始指示を受け取ったジョブ管理エージェント12163は、ジョブを起動し(ステップ16040)、その完了を待つ(ステップ16050)。ジョブが完了すると、ジョブ管理エージェント12163は、その出力と共にジョブ完了通知を、ジョブ管理サーバ12561へ通知する。
完了通知を受け取ったジョブ管理サーバ12561は、完了したジョブの実行順序を、実行対象ワークフローの進捗状況14003へ設定する(ステップ16060)。
そして、ジョブ管理サーバ12561は、ワークフローの進捗情報をマーカーとして挿入するように、制御プログラム1028へ要求する(ステップ16070)。本要求に基づいて、例えば、「ワークフローID:2, 進捗状況:3」といったテキストデータが付与されたマーカーが作成される。これは、ワークフローIDが2のワークフロー内で実行順序が3までのジョブが完了しているという情報になる。
次に、ジョブ管理サーバ12561は、ワークフロー内の全ジョブが終了したかを判定する(ステップ16080)。ここでは、進捗状況14003に格納されている値と実行中ワークフローのワークフローファイル12562に定義されているジョブの数とが同値であれば、ワークフロー内の全ジョブが完了したことが判明する。
ワークフロー内で未完了のジョブがある場合は(ステップ16080:NO)、ジョブ管理サーバ12561の処理は、ステップ16020へ戻る。
一方、全ジョブが完了していた場合は(ステップ16080:YES)、ジョブ管理サーバ12561は、実行対象ワークフローの進捗状況14003へ「DONE」を設定する(ステップ16090)。
そして、ジョブ管理サーバ12561は、ワークフローの完了情報をマーカーとして挿入するように、制御プログラム1028へ要求する(ステップ16100)。本要求に基づいて、例えば、「ワークフローID:2, 進捗状況:DONE」といったテキストデータが付与されたマーカーが作成される。これは、ワークフローIDが2のワークフローが完了したことを示す。
以上が、ジョブ管理サーバ12561とジョブ管理エージェント12163のワークフロー実行時の処理の流れである。
次に、リカバリ指示プログラム1253’が、リカバリ指示を受け付けたときの処理の流れを、図17を用いて説明する。
本処理は、ユーザが、パラメータとして特定のジャーナルグループ1014を指定して、リカバリ指示プログラム1253’を起動することで開始される。
ユーザにより本処理が起動されると、リカバリ指示プログラム1253’は、制御プログラム1028から、リストア可能範囲とマーカー管理テーブル1030の情報とを取得する。また、ユーザからリカバリポイントを受け付ける(ステップ10010〜10040)。本処理は、第一の実施形態と同様であるため、説明を省略する。
次に、リカバリ指示プログラム1253’は、ジョブ管理サーバ12561から、ワークフローファイル12562の情報とワークフロー管理テーブル12563の情報とを取得する(ステップ17005)。なお、本ステップでは、リカバリ指示プログラム1253’は、予めリカバリ指示プログラム’に、ジョブ管理用計算機12500のIPアドレスとジョブ管理用サーバ固有のポート番号とを設定しておき、それらを用い、ジョブ管理サーバ12561との通信を確立した後に、情報を取得する。
次に、リカバリ指示プログラム’は、リカバリ対象の全アプリケーション1161に対応する稼働状況とステータスを変更する(ステップ17010)。本ステップでは、リカバリ指示プログラム1253’は、JNLG管理テーブル1254と指定されたジャーナルグループの識別子とから、リカバリ対象のアプリケーション1161を特定する。そして、リカバリ指示プログラム1253’は、特定されたアプリケーション1161に対応するステータス15004に、「リカバリ前」を設定する。次に、リカバリ指示プログラム1253’は、ジョブ管理サーバ12561に、特定されたアプリケーション1161に対応する稼働状況13005に、「リカバリ中」を設定するように要求する。
次に、リカバリ指示プログラム1253’は、整合性確認開始指示プロセス1258を起動する(ステップ17020)。本プロセスは、CPU1230によって実行される。本プロセスの処理の流れは、後述する。
次に、リカバリ指示プログラム1253’は、リカバリポイントにおいて実行中のワークフローが存在するか否かを判定する(ステップ17030)。本ステップの判定は、ステップ10010〜10040において取得したマーカー管理テーブル1030の情報から、リカバリポイント以前に挿入された進捗状況が記録されているマーカーのうち、最新の進捗状況が「DONE」となっていないワークフローがあるか否かを検索することにより、行われる。
ステップ17030において、実行中のワークフローが存在しないと判定された場合(ステップ17030:NO)、リカバリ指示プログラム1253’は、指定されたジャーナルグループ1014に属する全ボリュームのリストアを、制御プログラム1028へ要求する(ステップ17040)。
次に、リカバリ指示プログラム1253’は、ステップ17040において要求したリストアが完了するまで待機する(ステップ17045)。
リストアが完了したら、リカバリ指示プログラム1253’は、ステップ17045においてリストアが完了したボリュームを利用する全アプリケーション1161に対応するステータス15004に、「リストア完」を設定し(ステップ17050)、処理を終了する。
一方、ステップ17030において、実行中のワークフローがあると判定された場合(ステップ17030:YES)、リカバリ指示プログラム1253’は、リカバリポイント直後に実行するアプリケーション1161が利用するボリュームのリストアを、制御プログラム1028へ要求する(ステップ17060)。リカバリポイント直後に実行するアプリケーション1161は、以下のようにして特定される。すなわち、まず、ステップ17030で検索されたマーカーに付与されているテキストデータを参照して、リカバリポイント直後に実行するワークフローのワークフローIDと進捗状況とが取得される。次に、そのワークフローIDに対応するワークフローファイル12562を参照して、進捗状況の値に1を加算した実行順序を持つジョブが、次に実行するジョブとして特定される。そのジョブを実行するアプリケーション1161が、リカバリポイント直後に実行されるアプリケーション1161である。また、リカバリポイント直後に実行するアプリケーション1161が利用するボリュームはボリューム管理テーブル1255から特定することができる。
次に、リカバリ指示プログラム1253’は、ステップ17060において要求したリストアが完了するまで待機する(ステップ17070)。
リストアが完了すると、リカバリ指示プログラム1253’は、ステップ17070においてリストアしたボリュームを利用するアプリケーション1161に対応するステータス15004に、「リストア完」を設定する(ステップ17080)。
次に、リカバリ指示プログラム1253’は、ジョブ管理サーバ12561へ、ワークフローの再開を要求する(ステップ17090)。このとき、リカバリ指示プログラム1253’は、ジョブ管理サーバ12561へ、ステップ17060で利用した進捗状況の値を、リカバリポイントにおける進捗状況として引き渡す。
次に、リカバリ指示プログラム1253’は、ワークフロー内に次に実行するジョブが存在するかを判定する(ステップ17100)。
ステップ17100において、存在しないと判定した場合(ステップ17100:NO)、リカバリ指示プログラム1253’は、指定されたジャーナルグループ1014に属するボリュームのうち、まだリストアしていないボリュームのリストアを、制御プログラム1028へ要求する(ステップ17040)。
一方、ステップ17100において存在すると判定した場合(ステップ17100:YES)、次のジョブを行うアプリケーション1161のボリュームが、リストア済みであるか否かを判定する(ステップ17110)。本判定では、ジョブを実行するアプリケーション1161に対応するステータス15004、「リカバリ前」が格納されている場合は、リストアされておらず、「リストア完」が格納されている場合は、リストア済みであると判定される。
ステップ17110において、リストア済みと判定された場合は(ステップ17110:NO)、リカバリ指示プログラム1253’の処理は、ステップ17100へ進む。一方、リストアされていないと判定された場合は(ステップ17110:YES)、リカバリ指示プログラム1253’は、次にジョブを実行するアプリケーション1161が利用するボリュームのリストアを、制御プログラム1028へ要求する(ステップ17120)。
次に、リカバリ指示プログラム1253’は、ステップ17120において要求したリストアが完了するまで待機する(ステップ17130)。
リストアが完了すると、リカバリ指示プログラム1253’は、ステップ17130においてリストアしたボリュームを利用するアプリケーション1161に対応するステータス15004に、「リストア完」を設定する(ステップ17140)。そして、リカバリ指示プログラム1253’の処理は、ステップ17100へ戻る。
以上が、リカバリ指示プログラム1253が、リカバリ指示を受け付けたときの処理の流れである。
なお、ステップ17040〜17050では、未リストアボリュームを纏めてリストアしたが、変形例として、ワークフローの実行順序が若いジョブのアプリケーション1161が利用するボリュームから順番にリストアし、利用するボリュームがリストア完了したアプリケーション1161から、そのアプリケーション1161に対応するステータス16004に、「リストア完」を設定していってもよい。
次に、ステップ17020において起動された整合性確認開始指示プロセス1258の処理の流れを、図18を用いて説明する。
本プロセスが起動されると、整合性確認開始指示プロセス1258は、JNLG管理テーブル1254のステータス15004に「リストア完」が格納されているアプリケーション1161が存在するか否かを判定する(ステップ18010)。
ステップ18010において、存在しない場合は(ステップ18010:NO)、再びステップ18010の判定が繰り返される。一方、存在すると判定された場合は(ステップ18010:YES)、整合性確認開始指示プロセス1258は、その中の一つのアプリケーション1161に対して、整合性確認を行うように指示する(ステップ18020)。なお、このとき、整合性確認開始指示プロセス1258は、AP管理用ネットワークアドレスと、ジョブ管理用サーバ固有のポート番号とを用い、アプリケーション1161との通信を確立した後に、整合性確認開始の指示を行う。
次に整合性確認開始指示プロセス1258は、ステップ18020において指示した整合性確認が完了するまで待機する(ステップ18030)。
整合性確認が完了したら、整合性確認開始指示プロセス1258は、整合性確認が完了したアプリケーション1161に対応する稼働状況13005へ「稼働中」を設定するように、ジョブ管理サーバ12561へ指示する(ステップ18040)。なお、この処理は、CPU1230が、予めリカバリ指示プログラムに設定してあったジョブ管理用計算機のIPアドレスと、ジョブ管理用サーバ固有のポート番号とを用い、ジョブ管理サーバ12561との通信を確立した後に行われる。
次に、整合性確認開始指示プロセス1258は、整合性確認が完了したアプリケーション1161に対応するステータス15004に、「稼働中」を設定する(ステップ18050)。
次に、整合性確認開始指示プロセス1258は、リカバリ対象として指定されたジャーナルグループ1014に属するボリュームを利用する全てのアプリケーション1161が、稼働中となったか否かを判定する(ステップ18060)。当該判定は、JNLG管理テーブル1254におけるステータス15004が参照されることにより行われる。
ステップ18060において、全てのアプリケーションが稼働中であると判定された場合は(ステップ18060:YES)、処理を終了する。一方、稼働中でないアプリケーション1161が存在する場合は、整合性確認開始指示プロセス1258の処理は、ステップ18010へ戻る。
以上が、ステップ17020において起動された整合性確認開始指示プロセス1258の処理の流れとなる。
以上が第二の実施形態の説明である。本実施形態によれば、リカバリ後すぐに処理を開始する必要があるアプリケーション1161ほど前倒ししてリカバリされるため、業務再開までの時間を短くすることが可能になる。
<第三の実施形態>。
次に第三の実施形態について説明する。
本実施形態に係る計算機システムは、コピーグループを一括バックアップする技術を用いてバックアップ及びリストアを行うストレージシステムを備える。当該ストレージシステムは、疎に連携する複数のアプリケーションのデータを格納するボリュームを備え、これらのボリュームを一括バックアップする。
当該計算機システムにおいても、第二の実施形態と同様の問題が発生する。
そこで、本実施形態では、この問題を解決するために、リカバリポイントを基点に、先にジョブが開始されるアプリケーションほど、リストアの優先度を高くし、リカバリ後すぐに処理を開始する必要があるアプリケーションほど前倒ししてリカバリさせる。これにより、業務再開までの時間を短くすることが可能になる。
以下、本実施形態のシステム構成と動作を説明する。
(1)第三の実施形態のシステム構成。
本実施形態のシステム構成の大部分は第二の実施形態のものと同じであるため、以降は相違点を主に説明する。
図19は、本実施形態の計算機システムの構成を示すブロック図である。
当該構成のストレージシステム1000のディスク装置には、一つ以上のコピーグループ19013が格納されている。当該コピーグループ19013は、一つ以上のデータボリューム1011と一つ以上のバックアップボリューム19012とにより構成されている。データボリューム1011は、ホスト計算機1100上で動作するアプリケーション1161により利用されるデータを格納する。バックアップボリューム19012には、特定時点におけるデータボリューム内のデータのバックアップデータが格納される。
本実施形態における制御プログラム1028は、バックアップ指示プログラム1252から、コピーグループ19013の一括バックアップを要求されると、コピーグループに19013属する全てのデータボリューム1011の同一時点のデータをバックアップボリューム19012へコピーする
なお、本実施形態では、ディスク装置1010内に、ジャーナルグループ1014、SSVOLグループ1015、スナップショットボリューム1012、ジャーナルボリューム1013は必要ない。
また、メインメモリ1026にマーカー管理テーブル1030、ジャーナル管理テーブル1031を記憶させる必要もない。
ホスト計算機1100、ジョブ管理計算機12500に関しては、第二の実施形態と同等であるため、説明を省略する。
管理計算機上1200のメモリ1250には、バックアップ指示プログラム1252’、リカバリ指示プログラム1253’’、コピーグループ管理テーブル19254、バックアップ管理テーブル19256、設定プログラム1251、ボリューム管理テーブル1255が、記憶される。
設定プログラム1251及びボリューム管理テーブル1255は、第一の実施形態で示したものと同様であるので、説明を省略する。
バックアップ指示プログラム1252’、リカバリ指示プログラム1253’’は、第一の実施形態のものとほぼ同等であるため、相違点を主に後ほど説明する。コピーグループ管理テーブル19254、バックアップ管理テーブル19256についても、後述する。
図20は、コピーグループ管理テーブル19254の一例である。
本テーブル19254は、アプリケーション1161がどのコピーグループ19013に属するかを管理する。AP_ID20001は、本システムにおけるアプリケーション1161の識別子を格納するカラムである。CG_ID20002は、アプリケーション1161が属するコピーグループ19013の識別子を格納するカラムである。AP管理用ネットワークアドレス20003は、アプリケーション1161が稼動しているホスト計算機1100のネットワークアドレスを格納するカラムである。ステータス20004はアプリケーション1161の稼働状況を格納するカラムである。本カラム20004には、例えば、「稼働中」、「リカバリ前」、「リストア完」のいずれかが格納される。
これらの値は、設定プログラム1251が提供するCLIを用いて、ユーザによって設定される。なお、ステータス20004には、設定プログラム1251によって、「稼働中」と設定される。
図21は、バックアップ管理テーブル19256の一例である。
本テーブル19256は、バックアップに関する情報(以下、「バックアップ情報」)の管理を行う。CG_ID21001は、バックアップデータ取得対象のコピーグループ19013の識別子を格納するカラムである。取得時刻21002は、バックアップデータを取得した時刻を格納するカラムである。進捗状況21003は、コピーグループ19013に属するアプリケーション1161を用いて実行されるワークフローの、バックアップデータ取得時点における進捗状況を格納するカラムである。このカラム21003には、例えば、「ワークフローID:2, 進捗状況:2」などが格納される。これは、このバックアップデータ取得時点において、ワークフローIDが2であるワークフローの二つ目のジョブまで終了していることを示す。
これらの値は、ユーザ等からバックアップ取得の要求を受け付けたバックアップ指示プログラム1252’によって、バックアップを取得した際に設定される。この動作の詳細は後述する。
(2)第三の実施形態の動作。
次に、本実施形態の動作の説明を行う。
本実施形態の動作の大部分は、第二の実施形態の動作と同じであるため、以降は相違点を主に説明する。
まず、バックアップ指示プログラム1252’の処理の流れを、図22を用いて説明する。
本処理は、ユーザがバックアップ指示プログラム1252’を起動することで開始される。
本処理が起動されると、まずバックアップ指示プログラム1252’は、バックアップデータの取得指示が発生するまで待機する(ステップ22010)。このバックアップデータの取得指示は、バックアップ指示プログラム1252’が提供するCLIを用いることで発生させることができる。ユーザやジョブスケジューラは、当該CLIのパラメータとして、特定のコピーグループ19013を指定する。
バックアップデータの取得指示を受け付けると、バックアップ指示プログラム1252’は、パラメータに指定されたコピーグループ19013に属する全てのアプリケーション1161を静止化する(ステップ22020)。静止化対象のアプリケーション1161は、コピーグループ管理テーブル19254を参照することで特定可能である。本ステップでは、バックアップ指示プログラム1252’は、リカバリマネージャ1162と通信を行い、リカバリマネージャ1162にアプリケーション1161の静止化指示を発行する。当該通信は、AP管理用ネットワークアドレスとリカバリマネージャ1162固有のポート番号とを利用することで確立される。
次に、バックアップ指示プログラム1252’は、ステップ22020で指示した全てのアプリケーション1161の静止化が完了するまで待機する(ステップ22030)。
全てのアプリケーション1161の静止化の完了を確認した後に、バックアップ指示プログラム1252’は、ワークフローの進捗状況をジョブ管理サーバ12561から取得する(ステップ22040)。進捗状況の取得は、例えば、以下のようにして行われる。すなわち、バックアップ指示プログラム1252’は、ワークフロー(ワークフローID)を指定して、その進捗状況の取得要求を、ジョブ管理サーバ12561へ通知する。取得要求を受けたジョブ管理サーバは、ワークフロー管理テーブル12563を参照して、指定されたワークフローに対応する進捗状況の値を取得し、それをバックアップ指示プログラム1252’へ通知する。
次に、バックアップ指示プログラム1252’は、制御プログラム1028へ、パラメータに指定されたコピーグループ19013に属するデータボリューム1011のデータを、バックアップするように要求する。(ステップ22050)。
次に、バックアップ指示プログラム1252’は、バックアップ管理テーブル19256を更新する(ステップ22060)。ここでは、バックアップ指示プログラム1252’は、バックアップ対象となるコピーグループ19013の識別子を、CG_ID21001へ設定する。また、バックアップ指示プログラム1252’は、構成図には図示されていないタイマから現在時刻を取得し、この時刻を取得時刻21002へ設定する。さらに、バックアップ指示プログラム1252’は、ステップ22040において取得したワークフローの進捗状況の値を、進捗状況21001へ設定する。
次に、バックアップ指示プログラム1252’は、パラメータに指定されたコピーグループ19013に属する全てのアプリケーション1161の静止化を解除する(ステップ22070)。本ステップでは、前記ステップ22020と同様に、バックアップ指示プログラム1252’は、リカバリマネージャ1162と通信を行い、リカバリマネージャ1162に静止化解除指示を発行する。
次に、バックアップ指示プログラム1252’は、ステップ22070で指示した全てのアプリケーション1161の静止化解除が完了するまで待機する(ステップ22080)。そして、全アプリケーション1161の静止化解除完了を確認した後に、バックアップ指示プログラム1252’の処理は、ステップ7010に戻る。
以上が、バックアップ指示プログラム1252の処理の流れである。
次に、リカバリ指示プログラム1253’’が、リカバリ指示を受け付けたときの処理の流れを、図23を用いて説明する。本処理は、ユーザが、パラメータとして特定のコピーグループ19013を指定して、リカバリ指示プログラム1253’’を起動することで開始される。なお、本処理は、第二の実施形態で図17を用いて説明した処理とほぼ同等であるため、以下、相違点を主に説明する。
ユーザにより本処理が起動されると、リカバリ指示プログラム1253’’は、バックアップ管理テーブル19256から、パラメータとして指定されたコピーグループ19013のバックアップ情報を検索し、その情報をリカバリ候補として、ユーザに提示する(ステップ23010)。
次に、提示された候補から、ユーザは、リカバリポイントを選択する(ステップ23020)。
リカバリポイントを受け付けたリカバリ指示プログラム1253’’は、ジョブ管理サーバ12561から、ワークフローファイルの情報を取得する(ステップ23030)。
以降、ステップ17010からステップ17050まで、第二の実施形態で図17を用いて説明した処理と以下の点を除き実質的に同等である。すなわち、ステップ17010やステップ17050等において稼働状況情報を設定し、また、参照する箇所に関しては、JNLG管理テーブル1254のステータス15004ではなく、コピーグループ管理テーブル19254のステータス20004に対して行われる。
以上が、リカバリ指示プログラム1253’’が、リカバリ指示を受け付けたときの処理の流れである。
以上が第三の実施形態の説明である。本実施形態によれば、複数アプリケーション1161のデータボリューム1011を一括バックアップする技術を用いてバックアップしたデータをリカバリする場合でも、リカバリ後すぐに処理を開始する必要があるアプリケーション1161ほど前倒ししてリカバリすることで、業務再開までの時間を短くなる。
以上、本発明の幾つかの実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。