JP2007140746A - 計算機システム及び管理計算機並びにリカバリ管理方法 - Google Patents

Abstract

【課題】適切なジャーナルボリュームの容量を、ユーザのバックアップ、リカバリに関する運用形態を用いて算出し、前記ジャーナルを用いた短時間でのリカバリを可能とするリカバリシステムを構築する方法を提供する。
【解決手段】ストレージシステム１２０は、ボリュームが格納するデータの更新履歴とボリュームが格納するデータを複製したボリュームを保持し、更新履歴と複製ボリュームとで、任意の更新時点のボリュームデータを復元し、管理計算機１００は、更新履歴を保持するボリュームについて、ユーザの操作を受けて、復元する時間であるリカバリ時間目標及び／又は更新時点であるリカバリポイント目標と、更新履歴を保持する期間である更新履歴保持期間とを含む登録作成要求を取得し、ボリュームが格納するデータの更新履歴を監視し、更新履歴の量を算出し、更新履歴を保持するボリュームの容量を決定する。
【選択図】図１

Description

本発明は、計算機や記憶装置を用いた計算機システムにおいて、データのバックアップ、リカバリのシステムに関する。

企業などでの計算機システムにおいて、ストレージのデータ量の増大に伴い、通常運用時のデータばかりでなく、通常運用時のデータのバックアップデータもまた増大している。バックアップデータは、ある一定の間隔（例えば、一日ごと）に取得しており、通常運用のデータに対して、多世代のバックアップデータを取得することも多い。通常運用をしているときに、何らかの障害が起こると、バックアップデータを用いて、ある時点のデータをリカバリすることとなるが、多世代でバックアップしていても、リソースの制限等から、戻したい時間のデータとは、差が生じる可能性がある。例えば、テープにバックアップデータを保存しているとき、テープの巻数が有限であるため、テープを使いまわさなければならない。このとき、１日単位で午前０時０分にバックアップデータを取得していたとすると、午後１１時にデータが破壊されて、バックアップデータを用いようとすると、２３時間前のデータが最新のバックアップデータとなってしまう。すなわち、リカバリするポイントがとても長くなってしまう。

この問題を解決するために、通常データに対する更新履歴、すなわちジャーナルデータを取得し、損失データを回復させる技術が提供されている（例えば、特許文献１）。特許文献１では、ストレージへの書き込みデータに対してジャーナリングを行なうことで、ジャーナリングを行なう直前のボリュームのデータを持つボリューム（以下、「基底ボリューム」ともいう）を作成しておき、前記基底ボリュームに、任意の時間のジャーナルを当てることで、任意の時間のボリュームのデータを復元することが可能である。

ジャーナルには、書き込みデータ更新後のジャーナルである更新後ジャーナルと書き込みデータ更新前のジャーナルである更新前ジャーナルが定義されているものもある（例えば、特許文献１）。更新後ジャーナル、更新前ジャーナルを取得し、前記更新後ジャーナル、更新前ジャーナルを適用することで、あるタイミングのボリュームに対して、より古いデータに戻したり、新しいデータに書き換えたりすることが可能となる。これにより、ジャーナルデータを用いて、戻したいタイミングを柔軟に探し出して、リカバリデータを作成することが可能である。
米国特許公開明細書２００５／００１５４１６

かかる従来の方法においては、次のような問題がある。ジャーナルは書き込みデータを取得するごとにデータが追加されるので、書き込みデータが多くなってくると、ジャーナルデータを格納している領域の使用率が１００％となることが考えられる。よって、ジャーナルデータがあふれてしまったり、上書きしてしまったりして、新しいジャーナルデータを追加できなかったり、古いジャーナルデータを削除してしまうこととなる。

特許文献１では、データがあふれる前に、基底ボリュームとジャーナルデータを用いてスナップショットを作成し、スナップショット作成後は、スナップショット作成に用いた古いジャーナルデータを除去することが可能である。しかし特許文献１の発明だと、ジャーナルデータが多いと、スナップショット作成に対する処理コストがかかり、またスナップショット数の増大、すなわちボリューム数の増大がおこり、ストレージ内の管理リソースを多く使用してしまう。よって、適切なジャーナルデータを格納する領域（以下、「ジャーナルボリューム」ともいう）の容量とスナップショット作成タイミングを設定してユーザへ提供する必要がある。

また、ここでジャーナルボリュームの容量を設定する場合、ただ容量をユーザが指定するのは、ホストのアクセス状況や使用可能なリソース、またユーザがリカバリ要求として考慮するリカバリポイントに戻るタイミング、リカバリのかかる時間を意識して行なう必要があり、容量の見積が困難という課題がある。

本発明は、適切なジャーナルボリュームの容量を、ユーザのバックアップ、リカバリに関する運用形態、すなわちリカバリポイント、リカバリ時間、またジャーナルの保存期間を用いて算出し、前記ジャーナルを用いた短時間でのリカバリを可能とするリカバリシステムを構築する方法を提供することを目的とする。

上記課題を解決するために、本発明では、該当ホスト計算機（以下、単に「ホスト」という場合がある）に対するボリュームへのアクセスを監視し、ユーザのリカバリ要求にあわせたジャーナルボリュームの容量と、基底ボリュームの作成タイミングを決定する。またユーザがデータを戻したい時間を指定するチェックポイントのタイミングも決定する。ここで、ホスト側のデータ管理は、通常ではキャッシュ等を用いることで、ストレージ側のボリュームのデータと不一致が起きている。よって、ホスト側のデータをストレージ側で復元するために、ホスト側のデータとストレージ側のデータを一致させておく必要がある。このデータを一致させてチェックポイントとして扱うことが考えられる。

また、ユーザのリカバリ要求は、前記リカバリポイント目標、リカバリ時間目標、ジャーナル保存期間である。また要求により、使用最大ジャーナルボリューム容量や対象ホストを指定する。ジャーナルは該当ホストの書き込みが該当するボリュームに対して来たときに、書き込まれる。よって、該当ホストのボリュームアクセスは書き込みの状況を監視する。そして、監視期間の間の書き込み量と、この書き込み状況をジャーナルとして管理するためのジャーナル管理領域の増分と、実際のジャーナル保存期間から、更新後ジャーナルを算出する。上記設定により、ユーザ指定のリカバリポイント、リカバリ時間を調整し、ホストのジャーナル運用への影響軽減とジャーナル量や基底ボリューム数や量の増大を防ぐことができる。

すなわち、本発明は、記憶領域であるボリュームを備えるストレージシステムと、該ストレージシステムを管理する管理計算機と、前記ストレージシステムのボリュームへデータを読み書きするホスト計算機とを具備し、各装置を、ネットワークを介して接続した計算機システムにおいて、前記ストレージシステムは、ボリュームが格納するデータの更新履歴とボリュームが格納するデータを複製したボリュームを保持し、前記更新履歴と前記複製したボリュームとで、任意の更新時点のボリュームが格納するデータを復元し、前記管理計算機は、更新履歴を保持するボリュームについて、復元する時間であるリカバリ時間目標及び／又は更新時点であるリカバリポイント目標と、更新履歴を保持する期間である更新履歴保持期間とを含む登録作成要求を取得し、ボリュームが格納するデータの更新履歴を監視し、更新履歴の量を算出し、更新履歴を保持するボリュームの容量を決定する計算機システムである。

本発明によれば、ユーザの運用要求に合わせてジャーナルの簡易設定が可能となり、ユーザの要求とストレージの使用に即したリカバリ管理を実現することが可能である。

本発明を実施するための最良の形態を説明する。
以下、本発明の計算機システム及び管理計算機並びにリカバリ管理方法の実施例について、図面を用いて詳細に説明する。

実施例１を説明する。図１は、本発明の第一の形態の計算機システムの構成を示す図である。ストレージ１２０は、実際に計算機（例えばホスト計算機）１１０が操作するデータを格納する記憶領域であるボリューム１２４がある。ボリューム１２４はハードディスクによる媒体であったり、ハードディスクを複数持って、ＲＡＩＤ構成のボリュームを実現するボリュームであったりする。また読み書きに関するデータＩ／Ｏの送受信や管理計算機１００などと通信を行なうＩ／Ｆ１２２と、実際にデータＩ／Ｏの読み書きの制御を行なうＣＰＵ１２１とメモリ１２３を有する。Ｉ／Ｆ１２２は、通信形態の相違（例えば管理計算機１００との通信がＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ホスト１１０とのデータＩ／ＯはＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ））によっては、通信形態ごとに通信装置が別々に配置されることもある。また同じプロトコルでも、用途の違いなどから、管理計算機１００との通信と、ホスト１１０との通信とで別々に配置されることもある。ストレージシステムを、以下、単に「ストレージ」ともいう場合がある。

メモリ１２３にはストレージマイクロプログラム１２５と、ストレージアクセス監視プログラム１２６があり、ＣＰＵ１２１によって実行されることにより実現される。またストレージマイクロプログラム１２５やストレージアクセス監視プログラム１２６が管理する管理テーブル１２７がある。ストレージマイクロプログラム１２５は、ストレージ１２０の構成について管理するプログラムであり、ボリューム１２４に対するジャーナルボリュームを作成し、このジャーナルボリュームを用いたリカバリを実行する機能や、ボリューム１２４をＩ／Ｆ１２２経由でホスト１１０に認識させるための機能などのストレージの機能を持つ。ストレージアクセス監視プログラム１２６は、ストレージに対するアクセス時間とそれにともなうアクセス（書き込み量、書き込み回数等）や、アクセス性能などを監視するプログラムである。管理テーブル１２７は、ジャーナルを用いたリカバリ機能を実行する上で必要な情報等、ストレージマイクロプログラム１２５で利用する情報を管理するテーブルである。

管理計算機１００は、ＣＰＵ１０１とメモリ１０３と、ストレージ１２０やホスト１１０と通信するＩ／Ｆ１０２を有する。管理計算機用のストレージ連携プログラム１０４、ストレージアクセス分析プログラム１０５、ジャーナル容量決定プログラム１０６、コピースケジュール決定プログラム１０７、ホスト連携プログラム１０８は、本発明の実施の形態の処理を実現するものである。ストレージ連携プログラム１０４、ストレージアクセス分析プログラム１０５、ジャーナル容量決定プログラム１０６、コピースケジュール決定プログラム１０７、ホスト連携プログラム１０８は、管理計算機１００のメモリ１０３に格納されており、ＣＰＵ１０１によって実行されることにより実現される。ストレージ管理情報１０９は、ストレージ連携プログラム１０４、ストレージアクセス分析プログラム１０５、ジャーナル容量決定プログラム１０６、コピースケジュール決定プログラム１０７、ホスト連携プログラム１０８で使用する情報である。

ホスト１１０は、ストレージ１２０のボリューム１２４にＩ／Ｆ１１２を介して、データＩ／Ｏを送受信して、ホストのデータをボリューム１２４に格納、編集する計算機である。ホスト１１０は、前述したＩ／Ｆ１１２とＣＰＵ１１１、メモリ１１３を有する。ホスト１１０を管理計算機１００で管理する場合は、ホスト１１０のメモリ１１３上の管理計算機連携プログラム１１６を使用し、管理計算機１００にＩ／Ｆ１１２を介して、情報の送受信を行なう。またホスト１１０のアプリケーション１１４は、ホスト１１０上で動作する業務を実行するプログラムである。このアプリケーション１１４には、ストレージ１２０のボリューム１２４上のデータの更新、作成を行なうデータ管理や、データの複製を行なうバックアップ管理などがある。またリカバリマネージャ１１５は、ストレージ１２０のストレージマイクロプログラム１２５と連携して、ボリュームの複製やリカバリを行なうプログラムである。ストレージアクセス監視プログラム１１７は、ストレージに対するアクセス時間とそれにともなうアクセス（書き込み量、書き込み回数等）や、アクセス性能などを監視するプログラムである。メモリ１１３に格納されているアプリケーション１１４、リカバリマネージャ１１５、管理計算機連携プログラム１１６、ストレージアクセス監視プログラム１１７は、ＣＰＵ１１１によって実行されることにより実現される。Ｉ／Ｆ１１２は管理計算機１００とストレージ１２０に接続されているが、管理計算機１００への情報の送受信には、ＴＣＰ／ＩＰのようなプロトコル、ストレージ１２０に対しては、Ｆｉｂｒｅ Ｃｈａｎｎｅｌのようなプロトコルを使用する場合、すなわち別々のプロトコルで接続する場合には、それぞれ別々のＩ／Ｆとなっていてもよい。別の言い方をすれば、例えばホスト１１０のデータの送受信に管理計算機１００とストレージ１２０とで、同じプロトコルを使用する場合は、Ｉ／Ｆ１１２は、１つのＩ／Ｆの装置で構成してもよい。

図２は、ジャーナルボリュームの構成である。ジャーナルボリュームは１つまたは複数のボリュームで構成され、ジャーナルデータを格納するボリュームである。ジャーナルボリューム２００には、ジャーナルを管理するためのジャーナルヘッダ２０３を格納する領域であるジャーナルヘッダ領域２０１と、実際のジャーナルデータ２０４を格納するジャーナルデータ領域２０２で構成されている。

ジャーナルヘッダ２０３には、データボリュームＩＤ２１１、書き込み先アドレス２１２、データ長２１３、生成時刻２１４、順序番号２１５、更新後ジャーナルが格納されているボリュームのＩＤを示すＡＪＮＬボリュームＩＤ２１６、更新後ジャーナルが格納されているアドレスを示すＡＪＮＬ格納アドレス２１７、更新前ジャーナルが格納されているボリュームのＩＤを示すＢＪＮＬボリュームＩＤ２１８、更新前ジャーナルが格納されているアドレスを示すＢＪＮＬ格納アドレス２１９があり、各ジャーナルの管理情報が入る。前記より、ジャーナルボリュームの容量を決定するには、ジャーナルデータ２０４とジャーナルヘッダ２０３の使用量を算出する必要がある。

また、ホスト１１０側のデータと、ストレージ１２０側でのデータの整合性を保つことを確認するチェックポイントのマーク（以下、「ジャーナルマーク」ともいう）もジャーナルヘッダ２０３のメンバに入れてもよい。この場合、ジャーナルデータは特に発生しない。このフラグより前のジャーナルデータを基底ボリュームに当てることで、ホスト１１０上でも整合性のあるデータにリカバリすることができる。またこのチェックフラグを用いなくても、整合性のある生成時刻を管理計算機１００が覚えていたり、整合性があるとホスト１１０側で確認できたときに、生成時刻をジャーナルに入れることで、この生成時刻のあるものだけ、スナップショットを取得するなどの処理としてもよい。このチェックポイントのマークを入れる時刻の間隔が、リカバリポイントの間隔と連動して管理することも可能である。すなわちチェックポイントマークのある時点にリカバリすれば、ホスト１１０では正しくデータを扱えるので、その時点をリカバリポイントとして扱うようにする。

図３は、管理計算機１００で実行される各プログラムで使用するストレージ管理情報１０９のテーブル群の一例を説明する図である。ストレージ管理情報１０９には、ボリュームテーブル３００、ボリューム監視設定テーブル３１０、ストレージ空き領域テーブル３２０、ジャーナルヘッダ容量テーブル３３０、リカバリデータ量テーブル３４０がある。

ボリュームテーブル３００には、ストレージのボリュームの情報が格納されており、ボリュームを識別するボリュームＩＤ３０１と、ストレージを識別するストレージＩＤ３０２と、各ストレージ内部のボリュームを識別するストレージボリュームＩＤ３０３と、各ボリュームの容量を示す容量３０４と、ボリュームの属性を示す属性３０５が格納されている。属性３０５ではホスト１１０等で使用されるデータが格納されているデータボリュームと、ジャーナルとして扱っているジャーナルボリュームを識別している。よって、ジャーナルボリュームが作成されると、このテーブルに、属性３０５が「ジャーナルボリューム」となるボリューム情報が登録される。このテーブル３００は、管理計算機１００で複数のストレージ１２０を管理する場合に、複数のストレージのボリュームの識別を可能とする。また、容量３０４において、図３の例においては、ボリュームＩＤ「ＶＯＬ１」のボリューム容量は１０Ｇバイトであることを示している。

ボリューム監視設定テーブル３１０には、ボリュームを識別するボリュームＩＤ３１１と、各ボリュームを使用するホストを識別するホストＩＤ３１２と、ホストの書き込み量の監視の期間設定である監視期間３１３が格納されている。監視期間は、テーブルの例で示すとおり、日にち指定や時間指定としてもよいし、開始時刻と終了時刻を格納し、この時間内で監視を行なうとしてもよい。開始時刻と日にちを指定する形式でもよい。

ストレージ空き領域テーブル３２０には、ストレージを識別するストレージＩＤ３２１と、各ストレージの空き領域の容量を示す空き領域３２２が格納されている。ストレージＩＤ３２１において、ボリュームテーブル３００のストレージＩＤ３０２と同じ値のものは、同じストレージであることを示している。空き領域３２２は、ストレージ１２０でデータやジャーナルなどが格納されていない未使用な領域の容量を示しており、この未使用な空き領域を用いて、新規ジャーナルボリュームを作成することになる。すなわちこの空き領域の容量が新規作成できるジャーナルボリューム容量となる。図３の例においては、ストレージＩＤ１のストレージの空き領域は１０Ｔバイトであることを示している。

ジャーナルヘッダ容量テーブル３３０には、ジャーナルボリュームでジャーナルを管理するジャーナル用のヘッダの容量を示すジャーナルヘッダ容量３３１を格納する。ジャーナルデータ管理のため、ジャーナルデータを書き込むごとにこのヘッダも必要となり、ジャーナル量を算出するにはジャーナルヘッダの容量を考慮する必要があり、この容量も用いてジャーナル容量を決定することになる。図３の例においては、ジャーナルヘッダの容量は１００バイトであることを示している。

リカバリデータ量テーブル３４０には、１秒間に実行されるリカバリデータの量を示す１秒間のリカバリデータ量３４１が格納されている。このデータを用いて、各ジャーナルの時点と基底ボリュームでリカバリするときのリカバリ時間を算出する。図３の例においては、１秒間のリカバリデータ量は１０Ｍバイトであることを示している。

図４はユーザがジャーナルボリューム作成を指示する画面を表す図の一例である。ジャーナルボリューム指定画面４００には、ジャーナルで複製を管理したいボリュームを指定する対象ボリューム４０１と、ジャーナルを保存する期間を指定するジャーナル保存期間４０２と、リカバリポイント目標を指定するリカバリポイント目標４０３と、リカバリ時間目標を指定するリカバリ時間目標４０４と、ユーザが使用可能なジャーナル容量を指定する使用最大ジャーナルボリューム容量４０５と、対象ボリューム４０１で実際に監視をおこなって書き込みを行なう監視対象となるホストを指定する対象ホスト４０６の指定項目がある。

またジャーナルボリューム作成に関連したコピー設定を行なうかどうかを指定するコピー設定４０７の指定項目もあり、上記４０１から４０７までの指定項目について、ジャーナルボリューム作成を実行するボタンである実行４０８と、キャンセルを行なうときのボタンであるキャンセル４０９でジャーナルボリューム指定画面４００は構成されている。コピー設定４０７には、「あり」と「なし」が指定可能であり、「あり」の場合は後述する図６のフローチャートで示される処理手順を行ない、「なし」の場合は後述する図７のフローチャートで示される処理手順を行なう。

使用最大ジャーナルボリューム容量４０５がユーザとして指定することがなければ、ジャーナルができる最大値として扱ってもよい。対象ホスト４０６が指定されていなくても、対象ボリュームが使用するホストがパス設定等でわかれば、自動的にホストを選出してもよい。対象ホストが一つで、対象ボリュームが複数であれば、対象ボリュームに複数のボリュームを指定してもよい。ボリュームごとに指定を変えたければ、対象ボリューム一つずつ指定することになる。

リカバリポイント目標４０３やリカバリ時間目標４０４について、業務によっては稼働時間が限られていたり、書き込み量が多い時間と少ない時間があったりする場合に対応するため、ある時間間隔ごとに指定させてもよい。例えば、８時から１７時までのリカバリ目標時間は、通常業務であり、書き込みを多く行なわれることを見越して１０分にするが、その他の時間では、業務はほとんど行なわれず、書き込み量も少ないと判断し、１時間とするなどの指定をさせてもよい。

図５は、リカバリに伴う情報を管理するリカバリ管理テーブル５００と、書き込み管理テーブル５１０に関するものであり、管理計算機１００のストレージ管理情報１０９で管理するテーブル群に含まれる一例である。リカバリ管理テーブル５００は、各対象データボリュームに対して用意される。リカバリ管理テーブル５００には、チェックポイントの識別子を表すチェックポイント５０１と、チェックポイントの時刻を表す時刻５０２と、チェックポイント間で使用するジャーナル量を表すジャーナル量５０３と、チェックポイント時、ジャーナルにチェックポイントのマークを入れる又は基底ボリュームを作るを指定するチェックポイント定義５０４、チェックポイントに戻す場合の復元方法を示す復元方法５０５、基底ボリュームを作成するとき、更新前ジャーナルの作成の有無、及び作成の場合にどこまでの更新前ジャーナルであるかを示す更新前ジャーナル作成５０６の情報が格納されている。

チェックポイント５０１のマークは、前述のとおり、ジャーナルヘッダ２０３のメンバとして新たに加えてもよいし、生成時刻２１４の時刻からチェックポイントのマークとして管理してよい時刻を管理計算機１００で管理するようにしてもよい。例えば、ＣＰ１のチェックポイントの時刻では、ホスト１１０のデータをＣＰ２で取得した基底ボリュームと更新前ジャーナルで復元できることを管理しておけばよい。

図５の例では、チェックポイント５０１のＣＰ１は、２００５年７月１日０時１０分のポイントであり、２００５年７月１日０時０分からスタートしたジャーナル量は３００Ｍであることを示している。またジャーナルマークによるチェックポイントの登録を行ない、チェックポイントへのデータの復元方法は、チェックポイントＣＰ２で作成される基底ボリュームと更新前ジャーナルにより復元されることを示されており、更新前ジャーナル作成は、基底ボリュームは作成されないので、このチェックポイントの時刻には行なわれないことを示している。また、リカバリ管理テーブル５００には、基底ボリュームを作成するとき、更新後ジャーナルを作成するが、作成する場合、どこまでの更新後ジャーナルを作成するかを示す更新後ジャーナル作成の情報が格納されていてもよい。更新前ジャーナル作成５０６の情報の代わりでもよいし、別の列を設けてもよい。

書き込み管理テーブル５１０は、リカバリ管理テーブル５００のチェックポイント５０１と同じ定義のチェックポイント５１１と、リカバリ管理テーブル５００の時刻５０２と同じ定義の時刻５１２と、チェックポイント間隔の書き込み量を示す書き込み量５１３と、チェックポイント間隔の書き込み回数を示す書き込み回数５１４の情報が格納されている。書き込み管理テーブル５１０は、各ボリュームで用意されるものである。このテーブルの情報により、チェックポイント間隔でのボリュームの書き込み傾向を格納し、この情報を用いてチェックポイント間隔のジャーナル量を算出することになる。

図６は、ジャーナルボリュームを作成する手順を示すフローチャートの一例である。図６において、ステップ６００及びステップ６０４からステップ６１２まではジャーナル容量決定プログラム１０６のステップ、ステップ６０１はホスト１１０のストレージアクセス監視プログラム１１７またはストレージ１２０のストレージアクセス監視プログラム１２６のステップ、ステップ６０２からステップ６０３まではストレージアクセス分析プログラム１０５のステップ、ステップ６１３はストレージ連携プログラム１０４とストレージ１２０のストレージマイクロプログラム１２５のステップに対応する。実際には、ＣＰＵがメモリから各プログラムを読み出し、各プログラムのステップを実行する。以下、プログラムを主語にして説明する場合があるが、そのプログラムを実行する処理部であるＣＰＵ１０１が処理を実行する。

まず、管理計算機１００のジャーナル容量決定プログラム１０６が、ユーザからジャーナル設定要求を受け付ける（ステップ６００）。要求として、図４でも示したように、ジャーナルで複製を管理したいボリュームを指定する対象ボリューム、ジャーナル保存期間、リカバリポイント目標、リカバリ時間目標、使用最大ジャーナルボリューム容量、対象ホストの指定項目がある。

次に、ストレージアクセス監視プログラム１２６は、ステップ６００で受け付けた要求を基に、対象ボリューム書き込み量の監視であるストレージアクセス監視を行なう（ステップ６０１）。ストレージアクセス監視は、ストレージ１２０でも、ホスト１１０でも行なってよい。ホスト１１０のキャッシュ量も考慮するときには、ホストでの監視がキャッシュ上の書き込み量もわかるので、正確さは増す。しかしキャッシュ容量を固定値とする、またはアクセスのアルゴリズムがわかり、キャッシュへの書き込みの監視をしなくても算出できるのであれば、またチェックポイントで行なう処理であるホストとの情報同期を行なうようにリカバリマネージャに指示するなどすれば、ストレージ側でアクセス監視をしてもよい。これはユーザに選択させてもよいし、監視プログラムを呼び出すジャーナル容量決定プログラム１０６が指定してもよい。また監視する期間もまた、ボリューム監視設定テーブル３１０の監視期間３１３で指定したものを条件として送信し、ストレージアクセス監視プログラムが、その期間ストレージアクセスの監視を行なう。

次に、ストレージアクセス分析プログラム１０５は、ステップ６０１で監視していた書き込み量を管理計算機１００上に収集する（ステップ６０２）。収集のタイミングは、定期的にストレージアクセス監視プログラムから収集してもよいし、監視期間が終わって、すなわちストレージアクセス監視プログラムの監視が終わってから情報を収集してもよい。図４の例では、対象ボリューム４０１で指定したボリュームＶＯＬ１に対して、図３のボリューム監視設定テーブル３１０から、監視期間は２日であるので、２日間のアクセスを監視する。監視期間は、図４の画面でユーザに指定させてもよい。

次に、ストレージアクセス分析プログラム１０５は、ステップ６０２で収集した書き込み量を分析する（ステップ６０３）。これはチェックポイントごとに分析する。そして、書き込み管理テーブル５１０に各ボリュームの書き込み時刻と書き込み量を格納する。この分析プログラムはホスト１１０やストレージ１２０のストレージアクセス監視プログラム１１７、１２６におき、書き込み量を分析して、管理計算機１００に、書き込み管理テーブル５１０に相当する情報を送っても良い。

次に、ジャーナル容量決定プログラム１０６は、ステップ６０３で分析した書き込み量とステップ６００で取得したジャーナル設定要求から、チェックポイント間隔ごとのジャーナル量を算出する（ステップ６０４）。ジャーナルは、図２でも示したように、ジャーナルデータとジャーナルヘッダの合計となる。よって、書き込みデータ量と、書き込み回数、ジャーナル保存期間により更新後ジャーナルを決定することはできる。更新前ジャーナルは、更新後ジャーナルの保存期間内のジャーナルの中で、リカバリポイント目標、リカバリ時間目標を基に、必要となる更新前ジャーナルのデータで決まる。更新前ジャーナルのヘッダは、更新後ジャーナルで使用していたものを適用すればよいので、特に量は増えない。

ジャーナルは、書き込み量が更新後ジャーナルデータ領域として必要な容量であり、書き込み回数とジャーナル容量を乗算したものがジャーナルヘッダ領域として必要な容量となる。そして監視期間内でチェックポイントごとのジャーナル容量を計算する。図５の書き込み管理テーブル５１０で示す例では、ＣＰ１のチェックポイントＩＤをもつ期間の書き込み量が２９７Ｍバイト、書き込み回数が３万回であり、そして、ジャーナルヘッダ容量テーブル３３０から、ジャーナルヘッダ容量は１００バイトとなっているので、３００Ｍバイトとなる。この情報をリカバリ管理テーブル５００に格納することになる。これをチェックポイントごとにジャーナル量を算出し、リカバリ管理テーブル５００にそれぞれジャーナル量を格納することになる。

次に、ステップ６００におけるジャーナル設定要求と、ジャーナル容量決定プログラム１０６は、ステップ６０４で求めたチェックポイント間隔ごとのジャーナル量と、基底ボリューム数を用いて、全ジャーナル数を算出する（ステップ６０５）。

更新前ジャーナルは、ステップ６００の要求である、リカバリポイント、リカバリ時間で決定する。リカバリデータ量テーブル３４０から１秒間にジャーナルを当てられる値が１Ｍバイトであるとする。またリカバリポイントは１０分ごと、リカバリ時間は１０分であるとする。リカバリポイントごとにリカバリするためには、リカバリポイントの間隔でチェックポイントをおく。

リカバリ時間は、基底ボリュームから、ジャーナル量を割り当てる時間となる。よって、更新後ジャーナルにおいて、リカバリ時間１０分内でジャーナルを割り当てられる量６００Ｍバイトであることがわかる。

このとき、リカバリ管理テーブル５００により、チェックポイント５０１のＣＰ２まで割り当てることが可能である。更新後ジャーナルのみでジャーナルを形成する場合は、ＣＰ２のときに基底ボリュームを作ることで、リカバリ時間１０分を守ることができる。

更新前ジャーナルを用いると、基底ボリューム数を削減することが可能となる。更新前ジャーナルを割り当てるようにすれば、単純計算で更新後ジャーナルでのリカバリと比較して倍のジャーナル量において、基底ボリュームを作ればよい。例えば、上記例でいくと、ある基底ボリュームに対して、基底ボリュームより新しいデータをリカバリする場合は、更新後ジャーナルで割り当てられるデータが６００Ｍバイト分割り当て可能で、基底ボリュームより古いデータをリカバリする場合、６００Ｍバイトのジャーナル分さかのぼることができる。よって、更新後ジャーナルだけでは６００Ｍバイト分のジャーナルをおくと次の世代の基底ボリュームを作成しなければならないが、更新前ジャーナルを用いて、ひとつの基底ボリュームで１２００Ｍバイト分のジャーナルでリカバリすることが可能である。

よって、更新前ジャーナルも用いれば、１２００Ｍバイト分のジャーナルが出来るときに基底ボリュームを作ればよい。基底ボリュームは通常ひとつ前の時間に取得した基底ボリュームに更新後ジャーナルを割り当てて作ることができるため、この更新後ジャーナルを割り当てるごとに、一つ前の基底ボリュームのデータを追い出すことで、更新前ジャーナルを作り出す。

ジャーナルを用いたリカバリにおいて、チェックポイントを用いると、更新前ジャーナルはチェックポイントごとに戻ればいいので、リカバリ管理テーブル５００の例でいけば、チェックポイント５０１のＣＰ３とそれより新しいチェックポイントに戻せばいいので、ＣＰ３から６００Ｍバイト分のジャーナルを割り当てることができる。前記ＣＰ２と前記ＣＰ３の間の２００Ｍバイトのデータは、更新前ジャーナルに反映しなくてもよい。よって、チェックポイントＣＰ３からＣＰ６までをＣＰ１、ＣＰ２で適応した基底ボリュームの次の世代の基底ボリュームと、この基底ボリューム作成時に作成する更新前ジャーナルでリカバリすることが可能である。結局、この場合１世代分のジャーナルとして、１２００Ｍバイトではなく、１３００Ｍバイト分のジャーナルを管理できることになる。

上記リカバリ時間が１０分ということで、１０分でできる量だけ、基底ボリューム数を少なくすることを考慮しているが、別の処理も考えられる。更新前ジャーナルはあくまでできるだけリカバリ時間をすくなくするものとし、リカバリ時間の判定は更新後ジャーナルで行ない、更新前ジャーナルを用いると早くなるものだけ、更新前ジャーナルを作るという手段をとる。

この場合、リカバリ管理テーブル５００から、チェックポイントＣＰ２までで、まず次世代基底ボリュームをつくる。ＣＰ１のリカバリは基底ボリュームとジャーナルになるが、更新前ジャーナルと更新後ジャーナルを考えると、更新前ジャーナルは２００Ｍバイト当てればよいだけなので、更新前ジャーナルを作る。次にＣＰ３，ＣＰ４、ＣＰ５のうちでＣＰ５のときに次世代の基底ボリュームを作ることになる。このとき、ＣＰ３はＣＰ２の時点でできた基底ボリュームと更新後ジャーナルで、ＣＰ４はＣＰ５の時点でできた基底ボリュームと更新前ジャーナルで、それぞれリカバリを行なうことで、リカバリ時間を速くする。リカバリ管理テーブル５００の例では、この処理に従った例を示しており、チェックポイント定義５０４では、チェックポイントＣＰ１、ＣＰ３、ＣＰ４をジャーナル上のチェックポイントマークで扱い、ＣＰ２、ＣＰ５を基底ボリュームで定義している。

上記のような処理を用いて、ジャーナル保存期間の更新前ジャーナルを算出する。すなわち、リカバリ管理テーブル５００のＣＰ５までの例でいけば、ＣＰ１とＣＰ２の間のジャーナル２００Ｍバイトと、ＣＰ４とＣＰ５の間のジャーナル１５０Ｍバイトが更新前ジャーナルを作成するので、合計３５０Ｍバイトの更新前ジャーナルを作成する必要があることを算出する。また更新後ジャーナルはＣＰ５までのジャーナル量は、ＣＰ５までのジャーナル量の合計であるので、１１００Ｍバイト必要である。よって、ここまでのジャーナル量は、更新後ジャーナルと更新前ジャーナルの合計であるので、１４５０Ｍバイトとなる。

上記に伴い、更新前ジャーナルをどこまで取得するか、またどのジャーナルをあてるかも指定する。上記の処理の例に従えば、リカバリ管理テーブル５００の復元方法５０５、更新前ジャーナル作成５０６に示されている。ＣＰ１のチェックポイントであれば、復元方法は、復元方法５０５から、ＣＰ２の時点で作成される基底ボリュームと、この基底ボリュームからＣＰ１までの更新前ジャーナルをあてることで復元することを表している。またＣＰ２では、更新前ジャーナル作成５０６から、基底ボリュームを作成したときに、ＣＰ１までの更新前ジャーナルを作成することを示している。

図３、図４の例に従えば、図４の対象ボリューム４０１であるＶＯＬ１のジャーナル保存期間は１日であり、監視期間はボリューム監視設定テーブル３１０から、２日である。この場合、監視期間でジャーナル量の多い日のデータを採用したり、平均を取ったりする。監視期間で定常的なデータにならなければ、監視期間を延長する、またはユーザに選択させてもよい。

そして、上記ジャーナル量の算出の処理を複数適応し、基底ボリューム数が少なく、ジャーナル量も少ないものを選ぶ。どちらか一方が大きくなったら、適時優先度を決めるか、ユーザに提示することで、どちらを選ぶか決めてもよい。

また、基底ボリューム数に制限があれば、ジャーナル量算出中に基底ボリューム数が制限を越えてしまう場合がある。例えば、ある通常運用のボリュームに対する基底ボリューム数の制限が１０個であるとする。またユーザの指定したリカバリ時間目標を１０分とする。このとき上記ジャーナル量の算出処理から、ジャーナル量が多いと、リカバリ時間目標を達成するためには、基底ボリュームが増えて、１１個以上必要な場合が発生する。その場合には、管理計算機１００が、ユーザのリカバリ時間目標を変えてしまい、例えば１１分などに変えてしまい、再度算出する。また、上記ジャーナル量の処理中に基底ボリューム数の制限を越えることがわかった時点で、ユーザに状況を通知し、再度図４の画面でリカバリ時間を再設定するようにしてもよい。

そして、上記でホストのボリュームへの書き込み量からジャーナル量を算出したが、運用中、監視期間のデータと同等になるとは限らないので、算出したものの倍の量をつけるなど、算出したジャーナル量に重みをつけて算出してもよい、例えばジャーナル保存期間内で必要なジャーナル量が１０Ｇバイトと算出したら、その倍をとって、２０Ｇバイトをジャーナル量として算出してもよい。

次に、ジャーナル容量決定プログラム１０６は、算出したジャーナル量に格納するジャーナルボリュームは作成可能か判定する（ステップ６０６）。すなわち、算出したジャーナル量分のボリュームをジャーナルボリュームとして確保できるか判定する。この場合、ストレージ空き領域テーブル３２０で示されるストレージの空き領域か、ユーザが指定した使用最大ジャーナルボリューム容量４０５で比較することになる。また使用最大ジャーナル量が指定されていなくても、各ユーザが使用できる空き領域がジャーナル容量決定プログラム１０６で取得可能であれば、要求を出してきたユーザの使用できる空き領域も比較対象となる。

ジャーナルボリュームが作成可能ならステップ６０７へ、作成ができないようであればステップ６０８へ進む。

上記ジャーナル量の算出の処理で複数案を満たすのであれば、両方出してもよいし、プログラム上で優先度を設けて、一方のジャーナル算出で、条件をみたせば、そちらを出して、ステップ６０７へいってもよい。

ジャーナル容量決定プログラム１０６は、ステップ６０７で、使用ジャーナル量を表示してユーザに提示する。ジャーナル量は、更新後ジャーナル量、更新前ジャーナル量の区別も提示してもよい。ステップ６０７終了後ステップ６１３に進む。

ジャーナル容量決定プログラム１０６は、ステップ６０８で、更新前ジャーナル削減により、ジャーナル容量が確保できるか調べる。すべての更新前ジャーナルを削減しなくてもよく、例えば、更新後ジャーナルと更新前ジャーナルとでリカバリ目標時間の差異が少ないものから削減していき、作成可能なジャーナルで提示する。このとき更新前ジャーナルの作成タイミングも考慮する必要がある。この条件により作成可能であれば、ステップ６０９に、作成できなければステップ６１０に進む。

ジャーナル容量決定プログラム１０６は、ステップ６０９で、使用ジャーナルボリューム容量を表示してユーザに提示する。また条件によりすべてのユーザの用件を達成できていないことをユーザに提示する。例えば、ステップ６０７で算出した更新後ジャーナルのみの使用ジャーナルボリューム容量を提示する。そして、ヒントとして、リカバリ時間を達成できないが、更新前ジャーナルを削減することで、ジャーナル量を満たせること提示する。ステップ６０９終了後ステップ６１３に進む。

ジャーナル容量決定プログラム１０６は、ステップ６１０で、更新前ジャーナル作成後、対応更新後ジャーナル削減によりジャーナルボリュームは作成可能か判定する。更新前ジャーナルはリカバリ時間目標削減のために使用し、更新前ジャーナルが壊れても、更新後ジャーナルで復帰できるようにしていたが、この場合は、どちらか一方のジャーナルでスナップショットをとることになる。この条件により作成可能であればステップ６１１に、作成できなければステップ６１２に進む。

ジャーナル容量決定プログラム１０６は、ステップ６１１で、対応更新後ジャーナル削減案を表示してユーザに提示する。また条件によりすべてのユーザの用件を達成できていないことをユーザに提示する。例えば、ジャーナル量は、相当する更新前ジャーナル、更新後ジャーナルの量を提示する。ステップ６１１終了後ステップ６１３に進む。

ジャーナル容量決定プログラム１０６は、ステップ６１２で、保存期間の削減案を提示し、短縮した保存期間のジャーナル量削減効果を提示する。例えば、ジャーナル保存期間を１２時間として、その１２時間分のジャーナル量を提示する。

ストレージ連携プログラム１０４は、ステップ６１３で、ユーザに確認してジャーナルを作成する。ステップ６１３において、このとき例えば６０９で提示した代替案をユーザが気に入らなければ、ステップ６１０に進むような処理の流れにしてもよい。またステップ６１３において、ジャーナルボリュームは性能によっては、１つではなく２つにするとかの選択、言い方を換えれば、既存のジャーナルボリュームを用いるか、新しいものを用いるかをユーザに選択させるなどの処理を加えても良い。

またステップ６１３において、一旦ユーザがキャンセルして、もう一度ステップ６００からジャーナル量の作成を行なう場合、書き込みの監視データを無効にしてしまうと、また書き込みの監視を行なわなければならないので、ステップ６１３でキャンセルした場合は、ステップ６０２で取得した書き込みの監視データを保持しておき、ステップ６０１、６０２における処理を飛ばすようにしてもよい。

ステップ６０７において、使用ジャーナル量は十分確保できるが、ジャーナルボリュームの配置から、予定より多くのジャーナルボリュームを作る必要があれば、それを提示してもよい。またジャーナルボリュームを既存の未使用のボリュームで作るか、空き領域から作るか、また既存のジャーナルボリュームに追加するか、新規にジャーナルボリュームを作成するかも、入力画面か確認画面で選択させてもよい。

ステップ６０８、６０９とステップ６１０、６１１は、処理順番を入れ替えて行なってもよい。

またユーザにより、詳細設定を行なわせるか、管理サーバで自動的にすべて設定してしまい、確認は行なわせるが、選択はさせない、というような処理にしてもよい。

ストレージ１２０のジャーナルを管理するジャーナルヘッダ２０３にチェックポイントマークを用いるのであれば、ジャーナルヘッダの量として算出しておき、ジャーナル量の算出に利用する必要がある。

また、更新前ジャーナル、更新後ジャーナルをすべて取得したいという項目を用意し、ユーザに図４の画面で指定させるようにすれば、更新前ジャーナル、更新後ジャーナルを算出して、ユーザに提示すればよい。また、上記に示した更新前ジャーナルと更新後ジャーナルの用途を逆にしてジャーナルの運用を行っても良い。この場合、更新前ジャーナルを取得しつつ、リカバリ目標時間等から、必要な分の更新後ジャーナルを取得することを考慮し、ジャーナル量を算出してもよい。このとき、リカバリ管理テーブル５００で更新後ジャーナル作成の列を加えて、更新後ジャーナル作成について管理すればよい。

上記フローチャートの処理により、ユーザのリカバリポイント、リカバリ時間、ジャーナル保存期間などのリカバリ要求から、更新後ジャーナルと更新前ジャーナルの容量を算出し、必要な全ジャーナルボリューム容量を算出し、ジャーナルボリュームを設定することが可能となる。

図７は、チェックポイント、基底ボリューム作成のタイミングを決定する手順を示すフローチャートの一例である。図７において、ステップ７００とステップ７０２は図６で説明したステップであり、ステップ７００はステップ６００と同等である。ステップ７０２はステップ６０１から６１３までのステップをさす。またその他のステップは管理計算機１００のコピースケジュール決定プログラム１０７が、それらのプログラムを実行するＣＰＵ１０１の処理により行なう。以下、プログラムを主語にして説明する場合があるが、そのプログラムを実行する処理部であるＣＰＵ１０１が処理を実行する。

まず、管理計算機１００のジャーナル容量決定プログラム１０６が、ユーザからジャーナル設定要求を受け付ける（ステップ７００）。図４のコピー設定４０７が「あり」のときにこの図７のフローチャートの処理を行なうことになる。

次に、ジャーナル容量決定プログラム１０６は、ステップ７００で受け付けた要求から、ジャーナルを適用する必要はあるか調べる（ステップ７０１）。ジャーナルを適用する必要がないとは、リカバリポイント時間が長い場合であって、従来のフルコピーまたは差分コピーの処理を行なうだけでよく、ジャーナルを用いないコピーでよければ、ステップ７０７に進む。ジャーナルを適用する必要であればステップ７０２に進む。例えば、リカバリポイントが１日であり、ジャーナル保存期間も１日であれば、通常運用のボリュームの複製を一つ作ればよく。その複製を使いまわせばよく、ジャーナルを作る必要がない。この場合ステップ７０７に進む。

また例えば、あるボリュームの複製が２４世代作成できる場合、ユーザの要求としてジャーナル保存期間が１日であり、リカバリポイント目標が１時間であれば、ボリュームの複製の世代で１時間ごとにボリュームの複製を作成すればよい。よって、この場合もステップ７０７に進む。

ステップ７０２では、図５で示した、ジャーナル作成の処理を行なう。

コピースケジュール決定プログラム１０７は、ステップ７０３で、チェックポイントの間隔は適切かどうか判定する。チェックポイントが、図４のように特に時間指定もせずに「１０分」として指定しても、ある時間の書き込みが監視上少ないとわかれば、チェックポイントを発行する時間が無駄になってしまい、他の業務に影響を与える可能性もある。またリカバリの際にも使われないチェックポイントを発行すると、結局管理データが多くなってしまう。また書き込み量が多いと、リカバリポイントをもっと短くすることで、実際の業務におけるリカバリポイントを多くとって、リカバリポイント時間を実質短くできるようになる。

よって、上記において、ある書き込み量の閾値を設ける。閾値と監視上での書き込み量と比較して、チェックポイントの間隔を改善したほうがよいかどうか判定する。そして、チェックポイント間隔が適切であればステップ７０５に、適切でなければステップ７０４に進む。例えば、１０分では３００Ｍバイト以上のジャーナル量があれば、別途チェックポイントを作成する、という閾値を設ける。このとき、リカバリ管理テーブル５００からＣＰ１までのチェックポイントまでのジャーナル量は３００Ｍバイトなので、チェックポイントを別途作成することとなる。この場合は、ステップ７０４に進む。

コピースケジュール決定プログラム１０７は、ステップ７０４で、ライト傾向からチェックポイントタイミングを算出し、閾値と比較してチェックポイントの増減を算出する。例えば、ＣＰ１の場合、ジャーナルが半分となる時刻にチェックポイントを設けるため、ステップ７０２、７０３で取得した各書き込みデータから、ジャーナルが半分、すなわち１５０Ｍバイトの部分でチェックポイントを追加するようにする。

コピースケジュール決定プログラム１０７は、ステップ７０５で、上記処理から、チェックポイントと基底ボリュームの設定間隔を決定し、実行環境を整える。ユーザに確認を行なうこととしてもよいし、自動的に行なってもよい。

次に、コピースケジュール決定プログラム１０７は、ステップ７０６で、実際のチェックポイントと基底ボリュームの設定間隔の設定を行なう。チェックポイント、基底ボリュームのタイミングはリカバリ管理テーブル５００のようになる。

コピースケジュール決定プログラム１０７は、ステップ７０７で、ジャーナルを用いたコピーではなく、複製元のデータを複製先に全コピーを行なうコピー機能を用いて設定する。

チェックポイント数にも制限があれば、それに基づき、ステップ７０３、７０４の処理を行なってもよい。

以上により、ユーザのリカバリの要求により、ストレージへのアクセスを監視し、要求に基づいたチェックポイント、基底ボリューム設定が可能となる。

図８は、図４でユーザがジャーナルボリューム作成を指示した後、図６のフローチャートの処理にて算出したジャーナル量を示すジャーナル確認画面を表す図の一例である。図６のフローチャートのステップ６０７、６０９、６１１、６１２の表示と、実際の実行を行なうステップ６１３で使用される画面である。

ジャーナルボリューム確認画面８００は、図４で指定した、対象ボリューム８０１、ジャーナル保存期間８０２と、リカバリポイント目標８０３と、リカバリ時間目標８０４と、使用最大ジャーナルボリューム容量８０５と、対象ホスト８０６に加え、算出したジャーナル量８０７と、ジャーナル量が他の要因で作成できないときに使用するヒント８０８と、実行ボタンである８０９と、キャンセルボタンである８１０がある。

算出ジャーナル量８０７は、図５のステップ６０７で表示される値である。ヒント８０８は、主にステップ６０９、６１１、６１２のときにデータが入る。例えば、ステップ６０７で算出した更新後ジャーナルのみの容量を算出ジャーナル量８０７で提示し、ヒント８０８として、リカバリ時間を達成できないが、更新前ジャーナルを削減することで、ジャーナル量を満たせること提示する。ここで、ステップ６０７で算出した更新後ジャーナルと更新前ジャーナル両方をここで提示してもよい。

ステップ６１３において、ユーザ確認後、訂正を行なうこともある。この場合は、再度図４と同じ入力画面に戻るか、算出ジャーナル量をユーザで書き換え、そのデータを反映した後に実行ボタンを押すようにする。

ヒント８０８で示す事項は、場合によって複雑化する。例えば、前記でも示しているとおり、時間によって、ジャーナル量が異なっていることもある。この場合は、書き込み管理テーブル５１０の情報をグラフ化し、閾値をどこで越えているかなど示してもよい。

また図６のフローチャートにて、図４の画面でユーザが入力する値４０１から４０４に変更があったら、８０１から８０４の表示には、図６のフローチャートで導き出した値を表示し、入力時の値の色の変更や、「（注）」などの文字の表示を表示し、または何も出力せず、ヒント８０８にて導き出した値を出力するようにしてもよい。例えばリカバリ時間目標の値が、ユーザの入力値と異なっていれば、リカバリ時間目標８０４には「（注）２０分」とし、ヒント８０８に「リカバリ時間目標の入力値は１０分でした。」というような情報を提示してもよい。

図９は、図４でユーザがジャーナルボリューム作成を指示した後、図７のフローチャートの処理にて算出したジャーナル量とチェックポイント、基底ボリューム作成のタイミングを示すジャーナルコピー確認画面を表す図の一例である。図７のフローチャートの７０５で、ユーザに確認を行なうために使用する画面である。

ジャーナルコピー確認画面９００は、図４で指定した、対象ボリューム９０１、ジャーナル保存期間９０２と、リカバリポイント目標９０３と、リカバリ時間目標９０４と、使用最大ジャーナルボリューム容量９０５と、対象ホスト９０６に加え、算出したジャーナル量９０７と、チェックポイントタイミング９０８と、基底ボリューム作成タイミング９０９と、ジャーナル量が他の要因で作成できないときに使用するヒント９１０と、実行ボタンである９１１と、キャンセルボタンである９１２がある。

算出ジャーナル量９０７は、図６のステップ６０７で表示される値である。チェックポイントタイミング９０８、基底ボリューム作成タイミング９０９は、図６、図７で算出して、ステップ７０５のときの結果を表示する。ただし、図５のリカバリ管理テーブル５００で示しているように、時刻によってタイミングが変化することがある。よって、リカバリ管理テーブル５００のテーブルの内容を、チェックポイント９０８、基底ボリューム作成タイミング９０９のかわりに提示してもよい。しかし、時刻５０２の値は、定期的に発行するため、時刻だけ表示する。

上記リカバリ時間テーブル５００を利用した表示を行なうとき、ユーザにチェックポイントと基底ボリュームのタイミングを変更させてもよい。例えば、リカバリ管理テーブル５００のＣＰ２のチェックポイントでは基底ボリュームを作ることになっているが、ユーザが基底ボリュームを作らずに、ジャーナルマークでよいとすれば、そのようにテーブルを書き換えて、実行させてもよい、その場合、ＣＰ１ではＣＰ２の基底ボリュームと更新前ジャーナルにて復元することを想定しているが、これは実行されないことを警告に出してから、実際のコピー設定を行なってもよい。

ヒント９１０は、条件により、基底ボリューム数の変更を行なうときなどに、そのヒントを示す。例えば、「１８時から２４時まではジャーナル更新がありません。基底ボリュームのタイミングをこの期間は少なくすることが可能です。」を表示する。

ステップ７０５において、ユーザ確認後、訂正を行なうこともある。この場合は、再度図４と同じ入力画面に戻るか、算出ジャーナル量やチェックポイントタイミング、基底ボリュームタイミングをユーザで書き換えて、そのデータを反映して、実行ボタンを押すようにする。

ヒントで示す事項は、場合によって複雑化する。例えば、前記でも示しているとおり、時間によって、ジャーナル量が異なっていることもある。この場合は、図５の書き込み管理テーブル５１０のグラフ化を行ない、また閾値をどこで越えているかなど示してもよい。

また、図６のフローチャートにて、図４の画面でユーザが入力する値４０１から４０４に変更があったら、９０１から９０４の表示には、図７のフローチャートで導き出した値を表示して、入力時の値の色の変更や、「（注）」などの文字の表示を行い、または何も出力せず、ヒント９１０にて導き出した値を出力するようにしてもよい。例えばリカバリ時間目標の値が、ユーザの入力値と異なっていれば、リカバリ時間目標９０４には「（注）２０分」とし、ヒント９１０に「リカバリ時間目標の入力値は１０分でした。」というような情報を提示してもよい。

以上、本実施例により、ユーザの運用要求である、ジャーナル保存期間、リカバリポイント、リカバリ時間に応じて、ジャーナルボリュームの設定と可能となり、ユーザの要求とストレージの使用に即したリカバリ管理、すなわちチェックポイント、基底ボリューム作成を実現することが可能となる。

また、本実施例では、管理計算機１００における、各プログラム、各情報は、ストレージ１２０に含まれてもよい。またホスト１１０に含まれてもよい。

なお、本実施例において、前記リカバリポイント目標は、前記チェックポイントでデータを復元するポイントとして扱うことが可能である。例えばリカバリポイント目標を１０分とすると、チェックポイントを１０分ごとに指定することによって、１０分ごとにデータを復元するポイントを確立する。よって、障害などで通常運用のボリュームのデータが破壊されても、チェックポイントまでのジャーナルを、前記基底ボリュームにあてることによって、最低でも１０分前のデータに復元することが可能となる。

またリカバリ時間目標の要求から、更新後ジャーナルではリカバリ時間目標を満たせないようであれば、リカバリ時間目標を満たすことができるように、ある期間の基底ボリュームを取得し、また更新前ジャーナルを利用するように設定する。例えば、各チェックポイントのデータを１０分で戻すようにリカバリ時間を設定されたとき、基底ボリュームから、更新後ジャーナルをあてる時間が１０分以上になるジャーナル量があることが考えられる。このときは、更新前ジャーナルで戻れる時間にスナップショット取得するように指示し、このスナップ量に対して、更新前ジャーナルをあてるように設定する。また、リカバリ時間目標の要求から、更新前ジャーナルではリカバリ時間目標を満たせないようであれば、リカバリ時間目標を満たすことができるように、ある期日の基底ボリュームを取得し、また、更新後ジャーナルを利用するように設定する。

またジャーナル量にあわせて、多世代の基底ボリュームを取得して、リカバリ時に、基底ボリュームとジャーナルを用いるか決定する。またリカバリ時間がそれほど求められなければ、基底ボリュームのみ何世代か取得するか、全て基底ボリュームと更新後ジャーナルで行なうようにすればよい。

また書き込みデータがない時間に、チェックポイント設定や基底ボリューム設定を行わないように指示してもよい。また書き込みが多い時はチェックポイントの間隔を短くするなど、チェックポイントの付け方を指示してもよい。また、ジャーナルボリュームの容量指定やストレージ状況により、ジャーナルの運用を調整する。例えば、ジャーナル量制限のため、保存期間内にジャーナルがあふれる設定を算出すれば、リソース量を考慮し、リカバリ時間をあまり考慮せずに更新前ジャーナルをなくすなどの対策を提示する。

以上実施例で説明したが、本発明の他の実施形態１は、前記更新履歴の情報は、更新前のデータの履歴情報及び／又は更新後のデータの履歴情報である計算機システムである。

本発明の他の実施形態２は、前記ストレージシステムは、更新前のデータの履歴情報の作成について、更新後のデータの履歴情報を用いてボリューム復元の際に前記リカバリ時間目標を満たせない量分だけ作成し、又は、リカバリ時間目標を満たしても、よりリカバリ時間を速くする量分だけ作成する計算機システムである。

本発明の他の実施形態３は、前記ストレージシステムは、更新後のデータの履歴情報の作成について、更新前のデータの履歴情報を用いてボリューム復元の際に前記リカバリ時間目標を満たせない量分だけ作成し、又は、リカバリ時間目標を満たしても、よりリカバリ時間を速くする量分だけ作成する計算機システムである。

本発明の他の実施形態４は、前記更新履歴を保持するボリュームの容量は、ユーザの使用可能なボリューム容量である計算機システムである。

本発明の他の実施形態５は、前記ストレージシステムは、算出した更新履歴量を保持するボリュームを提供することができないとき、更新前履歴のデータを取得しない、又は、更新後履歴のデータを取得しない、又は、更新前履歴と更新後履歴のデータが同じ期間のデータとして重複しないように取得する計算機システムである。

本発明の他の実施形態６は、前記ストレージシステムは、算出した更新履歴量を保持するボリュームを提供することができないとき、更新履歴の保存期間を短くする計算機システムである。

本発明の他の実施形態７は、前記管理計算機は、リカバリ時間目標及び／又はリカバリポイント目標と、更新履歴保持期間と、更新履歴の情報とから、前記ボリュームのデータ複製の世代数とタイミングを決定し、前記ボリュームのデータ複製の世代数とタイミングを設定する計算機システムである。

本発明の他の実施形態８は、前記管理計算機は、リカバリポイント目標から、更新履歴を用いてリカバリを行なうポイントであるチェックポイントのタイミングを決定し、前記チェックポイントのタイミングを設定することを特徴とする計算機システムである。

本発明の他の実施形態９は、前記管理計算機は、算出した更新履歴の傾向を把握し、チェックポイント処理の増減案を提示し、チェックポイントを増加又は減少させる計算機システムである。

本発明の他の実施形態１０は、前記管理計算機は、リカバリポイントがボリュームの複製だけで実現できるとき、更新履歴を用いた復元を用いずに、ボリュームの複製のみを設定する計算機システムである。

本発明の他の実施形態１１は、ボリュームが格納するデータの更新履歴とボリュームが格納するデータを複製したボリュームを保持し、かつ、前記更新履歴と前記複製したボリュームとで任意の更新時点のボリュームのデータ復元するストレージシステムを管理し、ネットワークを介して接続した前記ストレージシステム及び該ストレージシステムのボリュームへデータを読み書きするホスト計算機とで計算機システムを構成する管理計算機において、ストレージ連携プログラム、ストレージアクセス分析プログラム、ジャーナル容量決定プログラム、コピースケジュール決定プログラム、ホスト連携プログラム及びストレージ管理情報を格納するメモリと、管理計算機全体の動作を制御するＣＰＵと、ネットワーク接続用のインタフェースとを備え、更新履歴を保持するボリュームについて、復元する時間であるリカバリ時間目標及び／又は更新時点であるリカバリポイント目標と、更新履歴を保持する期間である更新履歴保持期間とを含む登録作成要求を取得し、ボリュームが格納するデータの更新履歴を監視し、更新履歴の量を算出し、更新履歴を保持するボリュームの容量を決定する管理計算機である。

本発明の他の実施形態１２は、前記更新履歴の情報は、更新前のデータの履歴情報及び／又は更新後のデータの履歴情報である管理計算機である。

本発明の他の実施形態１３は、前記更新履歴を保持するボリュームの容量は、ユーザの使用可能なボリューム容量である管理計算機である。

本発明の他の実施形態１４は、リカバリ時間目標及び／又はリカバリポイント目標と、更新履歴保持期間と、更新履歴の情報とから、前記ボリュームのデータ複製の世代数とタイミングを決定し、前記ボリュームのデータ複製の世代数とタイミングを設定する管理計算機である。

本発明の他の実施形態１５は、リカバリポイント目標から、更新履歴を用いてリカバリを行なうポイントであるチェックポイントのタイミングを決定し、前記チェックポイントのタイミングを設定する管理計算機である。

本発明の他の実施形態１６は、算出した更新履歴の傾向を把握し、チェックポイント処理の増減案を提示し、チェックポイントを増加又は減少させる管理計算機である。

本発明の他の実施形態１７は、リカバリポイントがボリュームの複製だけで実現できるとき、更新履歴を用いた復元を用いずに、ボリュームの複製のみを設定する管理計算機である。

本発明の他の実施形態１８は、記憶領域であるボリュームを備えるストレージシステムと、該ストレージシステムを管理する管理計算機と、前記ストレージシステムのボリュームが格納するデータの読み書きするホスト計算機とを備え、各装置を、ネットワークを介して接続した計算機システムにおけるリカバリ管理方法において、ボリュームが格納するデータの更新履歴とボリュームが格納するデータを複製したボリュームを保持することと、前記更新履歴と前記複製したボリュームとで、任意の更新時点のボリュームのデータ復元することと、更新履歴を保持するボリュームについて、復元する時間であるリカバリ時間目標及び／又は更新時点であるリカバリポイント目標と、更新履歴を保持する期間である更新履歴保持期間とを含む登録作成要求を所得することと、ボリュームが格納するデータの更新履歴を監視することと、更新履歴の量を算出することと、更新履歴を保持するボリュームの容量を決定することを有するリカバリ管理方法である。

実施例１の計算機システムの構成の一例を示す図。 実施例１の計算機システムで管理するジャーナルの一例を示す図。 実施例１の計算機システムで用いられるテーブルの一例を示す図。 実施例１の計算機システムで用いられるテーブルの一例を示す図。 実施例１の計算機システムで用いられる設定画面の一例を示す図。 実施例１におけるジャーナル量を算出、設定する手順を示すフローチャートの一例を示す図。 実施例１におけるチェックポイントと基底ボリュームのタイミングを設定する手順を示すフローチャートの一例を示す図。 実施例１におけるジャーナル量を表示する一例を示す図。 実施例１におけるチェックポイントと基底ボリュームのタイミングを表示する一例を示す図。

符号の説明

１００ 管理計算機
１０１ ＣＰＵ
１０２ Ｉ／Ｆ
１０３ メモリ
１０４ ストレージ連携プログラム
１０５ ストレージアクセス分析プログラム
１０６ ジャーナル容量決定プログラム
１０７ コピースケジュール決定プログラム
１０８ ホスト連携プログラム
１０９ ストレージ管理情報
１１０ ホスト
１１１ ＣＰＵ
１１２ Ｉ／Ｆ
１１３ メモリ
１１４ アプリケーション
１１５ リカバリマネージャ
１１６ 管理計算機連携プログラム
１１７ ストレージアクセス監視プログラム
１２０ ストレージ
１２１ ＣＰＵ
１２２ Ｉ／Ｆ
１２３ メモリ
１２４ ボリューム
１２５ ストレージマイクロプログラム
１２６ ストレージアクセス監視プログラム
１２７ 管理テーブル

Claims (19)

1. 記憶領域であるボリュームを備えるストレージシステムと、該ストレージシステムを管理する管理計算機と、前記ストレージシステムのボリュームが格納するデータの読み書きするホスト計算機とを具備し、各装置を、ネットワークを介して接続した計算機システムにおいて、
   前記ストレージシステムは、ボリュームが格納するデータの更新履歴とボリュームが格納するデータを複製したボリュームを保持し、前記更新履歴と前記複製したボリュームとで、任意の更新時点のボリュームが格納するデータを復元し、前記管理計算機は、更新履歴を保持するボリュームについて、復元する時間であるリカバリ時間目標及び／又は更新時点であるリカバリポイント目標と、更新履歴を保持する期間である更新履歴保持期間とを含む登録作成要求を取得し、ボリュームが格納するデータの更新履歴を監視し、更新履歴の量を算出し、更新履歴を保持するボリュームの容量を決定することを特徴とする計算機システム。
2. 請求項１記載の計算機システムにおいて、
   前記更新履歴の情報は、更新前のデータの履歴情報及び／又は更新後のデータの履歴情報であることを特徴とする計算機システム。
3. 請求項２記載の計算機システムにおいて、
   前記ストレージシステムは、更新前のデータの履歴情報の作成について、更新後のデータの履歴情報を用いてボリューム復元の際に前記リカバリ時間目標を満たせない量分だけ作成し、又は、リカバリ時間目標を満たしても、よりリカバリ時間を速くする量分だけ作成することを特徴とする計算機システム。
4. 請求項２記載の計算機システムにおいて、
   前記ストレージシステムは、更新後のデータの履歴情報の作成について、更新前のデータの履歴情報を用いてボリューム復元の際に前記リカバリ時間目標を満たせない量分だけ作成し、又は、リカバリ時間目標を満たしても、よりリカバリ時間を速くする量分だけ作成することを特徴とする計算機システム。
5. 請求項１記載の計算機システムにおいて、
   前記更新履歴を保持するボリュームの容量は、ユーザの使用可能なボリューム容量であることを特徴とする計算機システム。
6. 請求項２記載の計算機システムにおいて、
   前記ストレージシステムは、算出した更新履歴量を保持するボリュームを提供することができないとき、更新前履歴のデータを取得しない、又は、更新後履歴のデータを取得しない、又は、更新前履歴のデータと更新後履歴のデータが同じ期間のデータとして重複しないように取得することを特徴とする計算機システム。
7. 請求項１記載の計算機システムにおいて、
   前記ストレージシステムは、算出した更新履歴量を保持するボリュームを提供することができないとき、更新履歴の保存期間を短くすることを特徴とする計算機システム。
8. 請求項１記載の計算機システムにおいて、
   前記管理計算機は、リカバリ時間目標及び／又はリカバリポイント目標と、更新履歴保持期間と、更新履歴の情報とから、前記ボリュームのデータ複製の世代数とタイミングを決定し、前記ボリュームのデータ複製の世代数とタイミングを設定することを特徴とする計算機システム。
9. 請求項１記載の計算機システムにおいて、
   前記管理計算機は、リカバリポイント目標から、更新履歴を用いてリカバリを行なうポイントであるチェックポイントのタイミングを決定し、前記チェックポイントのタイミングを設定することを特徴とする計算機システム。
10. 請求項９記載の計算機システムにおいて、
    前記管理計算機は、算出した更新履歴の傾向を把握し、チェックポイント処理の増減案を提示し、チェックポイントを増加又は減少させることを特徴とする計算機システム。
11. 請求項１記載の計算機システムにおいて、
    前記管理計算機は、リカバリポイントがボリュームの複製だけで実現できるとき、更新履歴を用いた復元を用いずに、ボリュームの複製のみを設定することと特徴とする計算機システム。
12. ボリュームが格納するデータの更新履歴とボリュームが格納するデータを複製したボリュームを保持し、かつ、前記更新履歴と前記複製したボリュームとで任意の更新時点のボリュームが格納するデータを復元するストレージシステムを管理し、ネットワークを介して接続した前記ストレージシステム及び該ストレージシステムのボリュームが格納するデータの読み書きするホスト計算機とで計算機システムを構成する管理計算機において、
    ストレージ管理情報を格納するメモリと、管理計算機全体の動作を制御するＣＰＵと、ネットワーク接続用のインタフェースとを備え、更新履歴を保持するボリュームについて、復元する時間であるリカバリ時間目標及び／又は更新時点であるリカバリポイント目標と、更新履歴を保持する期間である更新履歴保持期間とを含む登録作成要求を取得し、ボリュームが格納するデータの更新履歴を監視し、更新履歴の量を算出し、更新履歴を保持するボリュームの容量を決定することを特徴とする管理計算機。
13. 請求項１２記載の管理計算機において、
    前記更新履歴の情報は、更新前のデータの履歴情報及び／又は更新後のデータの履歴情報であることを特徴とする管理計算機。
14. 請求項１２記載の管理計算機において、
    前記更新履歴を保持するボリュームの容量は、ユーザの使用可能なボリューム容量であることを特徴とする管理計算機。
15. 請求項１２記載の管理計算機において、
    リカバリ時間目標及び／又はリカバリポイント目標と、更新履歴保持期間と、更新履歴の情報とから、前記ボリュームのデータ複製の世代数とタイミングを決定し、前記ボリュームのデータ複製の世代数とタイミングを設定することを特徴とする管理計算機。
16. 請求項１２記載の管理計算機において、
    リカバリポイント目標から、更新履歴を用いてリカバリを行なうポイントであるチェックポイントのタイミングを決定し、前記チェックポイントのタイミングを設定することを特徴とする管理計算機。
17. 請求項１６記載の管理計算機において、
    算出した更新履歴の傾向を把握し、チェックポイント処理の増減案を提示し、チェックポイントを増加又は減少させることを特徴とする管理計算機。
18. 請求項１２記載の管理計算機において、
    リカバリポイントがボリュームの複製だけで実現できるとき、更新履歴を用いた復元を用いずに、ボリュームの複製のみを設定することと特徴とする管理計算機。
19. 記憶領域であるボリュームを備えるストレージシステムと、該ストレージシステムを管理する管理計算機と、前記ストレージシステムのボリュームが格納するデータの読み書きするホスト計算機とを備え、各装置を、ネットワークを介して接続した計算機システムにおけるリカバリ管理方法において、
    ボリュームが格納するデータの更新履歴とボリュームが格納するデータを複製したボリュームを保持することと、前記更新履歴と前記複製したボリュームとで、任意の更新時点のボリュームが格納するデータを復元することと、更新履歴を保持するボリュームについて、復元する時間であるリカバリ時間目標及び／又は更新時点であるリカバリポイント目標と、更新履歴を保持する期間である更新履歴保持期間とを含む登録作成要求を所得することと、ボリュームが格納するデータの更新履歴を監視することと、更新履歴の量を算出することと、更新履歴を保持するボリュームの容量を決定することを有することを特徴とするリカバリ管理方法。

Images