JP5508798B2 - クラスタを考慮してレプリケーションを管理する管理方法及びシステム - Google Patents

Description

本発明は、クラスタ環境におけるストレージシステムを用いたバックアップ、リカバリに関する。

近年、グローバル化や、オンライン業務の導入等により、企業情報システムは２４時間３６５日、稼働し続けることが望まれている。上記を実現する技術として、クラスタリング技術がある。一般的に、クラスタリング技術とは、サーバ、ストレージシステムなどの情報システムの資源を冗長化し、可用性を高める技術で、情報システムの一部分に障害が起こっても、障害が発生していない資源を用いて、当該情報システム上のタスクを引き継ぐことができる。クラスタリング技術はデータを共有するローカルクラスタと、データを複製し、異なる装置間で冗長にデータを保持するリモートクラスタがある。
クラスタリング技術は冗長化のため、各情報システムの同一資源を複数持つ。この資源の増加は、結果として、利用者に複雑な設定を強いることになり、問題となっている。この問題については、たとえば、特許文献１の従来技術で、サーバ、ストレージシステムとも冗長構成をとるリモートクラスタ環境において、クラスタ対象のサーバを指定することで、複数のストレージシステム間でデータの内容を一致させるレプリケーション（後述する）を設定できる。

その一方、企業情報システムでは、誤操作や、機器障害などによるデータ崩壊、損失に備えるためバックアップが実施される。バックアップとは企業情報システムで使用されるデータを複製することを指す。データの複製は計算機にとって負荷が大きいため、この負荷を削減するためにレプリケーション技術が使用される。レプリケーション技術の従来技術としてたとえば、特許文献２がある。特許文献２では計算機がデータを複製するのではなく、ストレージシステムが当該ストレージシステムにおける記憶領域上のデータを別の記憶領域に複製する。

米国特許公開公報第２００４／０１８１７０７号報 米国特許公開公報第２００９／００５５６１３号報

ここで、ローカル、リモートいずれかのクラスタリング技術を適用した企業情報システムで、利用者に複雑な設定を強いることになく、バックアップを実現することを考える。特許文献１にはバックアップに関する記載がないため、上記を満たさない。特許文献２には、レプリケーション技術の設定容易化に関する記載がないため、特許文献１との組み合わせをしても、上記は達成されない。さらに、特許文献１はリモートクラスタリングに関する記載のみで、ストレージシステムを冗長化しないローカルクラスタの記載もない。

以上のように、従来技術では上記の課題を解決できない。

本発明は、ローカル、リモートのいずれかのクラスタリング技術を適用した企業情報システムで、利用者に複雑な設定を強いることになく、バックアップできるシステムを提供することを目的とする。

ホスト計算機とストレージシステムを管理する管理システムはクラスタの情報を保持し、仮想ホスト識別子を指定したバックアップ指示に基いて活性状態のホスト計算機と非活性状態のホスト計算機を特定し、ディザスタリカバリ用途のレプリケーション実行の必要性の有無を判断し、必要な場合はバックアップ用途のレプリケーションを組み合わせて実行する。

ローカル、リモートのいずれかのクラスタリング技術を適用した計算機システムで、利用者に複雑な設定を強いることになく、バックアップを実現できる。

図１は、計算機システムの構成に関するブロック図である。 図２は、ストレージサブシステム１０００の詳細図である。 図３は、管理計算機１０の詳細図である。 図４は、ホスト計算機の詳細図である。 図５は、ローカルクラスタシステムでのバックアップ構成を示す。 図６は、リモートクラスタシステムでのバックアップ構成を示す。 図７は、管理計算機１０に記憶される管理側ストレージ情報１１４Ｃの構成例を示す。 図８は、管理計算機１０に記憶される管理側レプリケーション情報１１３Ｃの構成例を示す。 図９は、管理計算機１０に記憶される管理側バックアップ情報１８の構成例を示す。 図１０は、管理計算機１０に記憶される管理側カタログ情報１８の構成例を示す。 図１１は、管理計算機１０に記憶される管理側カタログ情報１５の構成例を示す。 図１２は、管理計算機１０に記憶される管理側ＡＰボリューム対応情報１３の構成例を示す。 図１３は、管理計算機１０に記憶される管理側クラスタ構成情報１９の構成例を示す。 図１４は、本発明の実施例１のストレージサブシステム１０００に記憶されるストレージ側レプリケーションペア情報１２１０の構成例である。 図１５は、本発明の実施例１のストレージサブシステム１０００に記憶されるストレージ側ボリューム管理情報１２５０の構成例を示す。 図１６は、管理計算機１０によるストレージサブシステム１０００に関する管理側ストレージ情報１１４Ｃ作成のためのフローである。 図１７は、管理計算機１０によるクラスタシステムの管理情報で管理側クラスタ構成情報１９の作成のためのフローである。 図１８は、管理計算機による、クラスタシステムの構成情報を取得するための画面例である。 図１９は、管理計算機１０によるホスト計算機２００上で動作するＡＰとそのＡＰが使用するボリュームを対応づけて管理する管理側ＡＰボリューム構成情報１９を作成するためのフローである。 図２０は、バックアップ対象のアプリケーションの情報を取得するための画面例である。 図２１は、管理計算機１０によるバックアップで必要な管理側バックアップ情報１９、管理側カタログ情報１４、管理側拠点カタログ情報１４の作成のためのフローである。 図２２は、バックアップ対象のアプリケーションが使用するデータの情報を取得するための画面例である。 図２３は、バックアップ対象のアプリケーションが使用する詳細データの情報を取得するための画面例である。 図２４は、バックアップスケジュールの情報を取得するための画面例である。 図２５は、管理計算機１０によるレプリケーション構成の構築処理である。 図２６は、管理計算機による管理計算機１０によるバックアップ処理のためのフローである。 図２７は、管理計算機１０によるリストア処理のためのフローである。 図２８は、リストア処理の入力画面例を示す。 図２９は、リストア処理の詳細データを決定する入力画面例である。 図３０は、非活性状態のホスト計算機２００による活性状態のホスト計算機２００が障害になった後にバックアップ処理を引き継ぐためのフローを示す。 図３１は、障害ホスト２００ａ障害後のリストア処理である。 図３２は、障害ホスト２００ａが障害前にバックアップしたデータをリストア対象のデータとして使用するか否かを判定するためのフローである。 図３３は、障害ホスト２００ａが障害前に取得したデータをレプリケーション制御でリストア対象の論理ボリュームに転送する処理に関するフローである。 図３４は、における、障害発生後に障害ホスト２００ａの作成したデータをレプリケーションの処理に関する説明図である。 図３５は、正副ストレージサブシステム１０００によって実行されるレプリケーションの開始処理のフローである。 図３６は、ストレージサブシステム１０００によって実行される定常コピー処理の一例を示すフローチャートである。 図３７は、リモートレプリケーション実施時にストレージサブシステム１０００によって生成されるデータ転送要求である。

以下、本発明を、図面を参照して説明する。

以後の説明では「ｘｘｘテーブル」、「ｘｘｘリスト」、「ｘｘｘＤＢ」又は「ｘｘｘキュー」等の表現にて本発明の情報を説明するが、これら情報はテーブル、リスト、ＤＢ又はキュー等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ｘｘｘテーブル」、「ｘｘｘリスト」、「ｘｘｘＤＢ」及び「ｘｘｘキュー」等について「ｘｘｘ情報」と呼ぶことがある。

また各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」及び「番号」という表現を用いるが、これらの表現は装置や部品などの物理的な存在に限らず、論理的な存在についても区別をつけるために割り当てられているものであるため、お互いに置換が可能である。

以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることによって定められた処理をメモリ及びインターフェースを用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理はストレージサブシステム、管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアによって実現されてもよい。これはストレージシステムに於いても同様であり、プログラムを主語として開示された処理を記憶制御装置又はストレージシステムが行う処理としてもよい。

また、各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。

（１−１）システム構成
図１は、本発明の実施例１の計算機システムの構成に関するブロック図の一例である。

計算機システムは、主拠点、遠隔拠点に分かれてストレージサブシステム１０００が配置されており、それぞれの拠点にあるストレージサブシステム１０００は１か２以上のホスト計算機２００と接続される構成である。ホスト計算機２００は、クライアント計算機２５０と接続される。管理計算機１０はそれぞれの拠点のホスト計算機２００と制御線５５を介して接続される。なお、図１では、管理計算機、ホスト計算機およびストレージサブシステムの各要素を拠点別に分け、それぞれ記号ａ、ｂを付与したが、明細書中特に記号を付記しない場合は共通の内容の説明であるものとする。また、ホスト計算機２００及びストレージサブシステム１０００は、何台備わっていてもよい。

ホスト計算機２００、ストレージサブシステム１０００はデータ通信線５００を介して相互に接続される。

なお、データ通信線５００は一つ以上のネットワークから構成されてもよい。さらに、データ通信線５００は、データ通信線５００と制御線５５のいずれかまたは両方と共用の通信線やネットワークであってもよい。

図３に管理計算機１０の詳細を示す。管理計算機１０は、メモリ４０、プロセッサ２０及び管理ポート３０を備える計算機である。メモリ４０、プロセッサ２０及び管理ポート３０は、内部ネットワーク（図示省略）によって相互に接続される。なお、管理計算機１０は管理ポート以外のポートを用いてホスト計算機２００、ストレージサブシステム１００と接続してもよい。なお、メモリ４０は半導体メモリ又は／及びディスク装置、又はこれらを併用したものであってよい。メモリについては以後で説明するホスト計算機、ストレージサブシステムでも半導体メモリ又はディスク装置、又はこれら併用したものであってもよい。

プロセッサ２０は、メモリ４０に記憶されるプログラムを実行することによって、各種処理を行う。例えば、プロセッサ２０は、ホスト計算機２００に後述のバックアップ制御指示を出すことによって、ホスト計算機２００を制御する。

メモリ４０には、プロセッサ２０によって実行されるプログラム及びプロセッサ２０によって必要とされる情報等が記憶される。具体的には、メモリ４０には、管理プログラム１２、管理側ＡＰボリューム対応情報１３、管理側カタログ情報１４、管理側レプリケーション情報１１３Ｃ、管理側ストレージ情報１１４Ｃ、管理側バックアップ情報１８、クラスタ構成情報１９、及び管理側拠点カタログ情報１５が記憶される。更に、メモリ４０には、ＡＰ１６プログラム（以下、ＡＰ）１６及びＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１７が記憶される。ＡＰ１６は、各種処理を実現するアプリケーションプログラムである。例えば、ＡＰ１６は、データベース機能、メールサーバ機能、又はＷＥＢサーバ機能等を提供する。ＯＳ１７は、管理計算機１００の処理の全体を制御するプログラムである。

管理プログラム１２は、制御線５５を介して複数拠点（図１の場合は主拠点と遠隔拠点）にあるストレージサブシステム１０００や、ホスト計算機２００を集中管理するプログラムである。

管理側ＡＰボリューム対応情報１３は、２つの拠点（主拠点、遠隔拠点）のそれぞれに存在するホスト計算機と当該ホスト計算機上で動作するＡＰ２１１を管理するための情報である。なお、ＡＰボリューム対応情報１３については、図１２で詳細を説明する。
管理側カタログ情報１４は、バックアップ済みデータに関する情報を保持ための情報である。なお、管理側カタログ情報１４については、図１０で詳細を説明する。
管理側拠点カタログ情報１５は、バックアップデータとバックアップ時刻に関する情報である。なお、管理側拠点カタログ情報１５については、図１１で詳細を説明する。

管理側バックアップ情報１８は、バックアップするために必要な情報を保持ための情報である。なお、管理側バックアップ情報１８については、図９で詳細を説明する。

管理側クラスタ構成情報１９は、クラスタシステムの構成を管理するための情報である。なお、管理側クラスタ構成情報１９については、図１３で詳細を説明する。

レプリケーション情報１１３Ｃは、レプリケーションの構成及び状態を管理するための情報である。なお、レプリケーション情報１１３Ｃについては、図８で詳細を説明する。

管理側ストレージ情報１１４Ｃは、当該管理計算機１０によって管理されるストレージサブシステム１０００に関する管理情報である。管理側ストレージ情報１１４Ｃは１台のストレージサブシステム１０００につき１個のテーブルが作成される。管理側ストレージ情報１１４Ｃについては、図７で詳細を説明する。

管理ポート３０は、制御線５５を介してホスト計算機２００に接続されるインターフェースである。制御線５５は一つ以上のネットワークから構成されてもよい。さらに、制御線５５は、データ通信線５５０とデータ通信線５００のいずれかまたは両方と共用の通信線やネットワークであってもよい。
また、管理計算機１０は入出力装置を有する。入出力装置の例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外の装置であってもよい。また、入出力装置の代替としてシリアルインターフェースやイーサーネットインターフェースを入出力装置とし、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力装置での入力及び表示を代替してもよい。

以後、計算機システムを管理し、本発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理計算機が表示用情報を表示する場合は管理計算機が管理システムである、また、管理計算機と表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

図４にホスト計算機２００の詳細を示す。ホスト計算機２００は、メモリ２１０、プロセッサ２２０、管理ポート２４０及びデータポート２３０を備える計算機である。

メモリ２１０、プロセッサ２２０及びデータポート２３０は、内部ネットワーク（図示省略）によって相互に接続される。

プロセッサ２２０は、メモリ２１０に記憶されるプログラムを実行することによって、各種処理を実現する。例えば、プロセッサ２２０は、ストレージサブシステム１０００にＩＯ要求を送信することによって、当該ストレージサブシステム１０００によって提供される一つ以上の論理ボリューム（以後、単にボリュームと呼ぶことがある）Ｖｏｌにアクセスする。

メモリ２１０には、プロセッサ２２０によって実行されるプログラム及びプロセッサ２２０によって必要とされる情報等が記憶される。具体的には、メモリ２１０には、ＡＰ２１１、ＯＳ２１２、バックアッププログラム２１３、クラスタプログラム２１４、管理側拠点カタログ情報１５Ｌ、管理側バックアップ情報１８Ｌ、管理側レプリケーション情報１１３Ｌ、スケジューラ２１７が記憶される。

ＡＰ２１１は、各種処理を実現するプログラムである。なお、ＡＰとはＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍの略である。ＡＰ２１１は、例えば、データベース機能又はＷＥＢサーバ機能を提供する。ＯＳ２１２は、ホスト計算機２００の処理の全体を制御するプログラムである。バックアッププログラム２１３は管理計算機からの指示を受信し、当該指示に従った処理を実施するプログラムである。クラスタプログラム２１４は後述のクラスタ処理を実施するプログラムである。スケジューラ２１７は所定の時刻に所定のプログラムを実行するためのプログラムである。本実施例ではスケジューラ２１７は独立のプログラムとして記載したが、ＯＳ２１２の１機能であっても構わない。

管理側拠点カタログ情報１５Ｌは、バックアップデータとバックアップ時刻に関する情報で、管理計算機１０が保持する同名の情報の複製である。管理側拠点カタログ情報１５Ｌの詳細の説明については管理計算機１０の管理側拠点カタログ情報１５と同様のため省略する。本明細書では管理計算機１０の同名の情報区別をするため末尾にＬをつけて記載する。

管理側バックアップ情報１８Ｌはバックアップするために必要な情報を保持ための情報で、管理計算機１０が保持する同名の情報の複製である。管理側バックアップ情報１８Ｌの詳細の説明については管理計算機１０の管理側バックアップ情報１８と同様のため省略する。本明細書では管理計算機１０の同名の情報区別をするため末尾にＬをつけて記載する。

管理側レプリケーション情報１１３Ｌは、レプリケーションの構成及び状態を管理するための情報で、管理計算機１０が保持する同名の情報の複製である。なお、レプリケーション情報１１３Ｌの詳細の説明については、管理計算機１０の管理側レプリケーション情報１１４Ｃと同様のため省略する。本明細書では管理計算機１０の同名の情報区別をするため末尾にＬをつけて記載する。

データポート２３０は、データ通信線５００を介して、ストレージサブシステム１０００に接続されるインターフェースである。具体的には、データポート２３０は、ストレージサブシステム１０００にＩＯ要求を送信する。

管理ポート２４０は、制御線５５を介して、管理計算機１０に接続されるインターフェースである。具体的には、データポート２３０は、管理計算機１０からの制御指示を送信する。

なおホスト計算機２００は入出力装置を有してもよい。入出力装置の例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外の装置であってもよい。また、入出力装置の代替としてシリアルインターフェースやイーサーネットインターフェースを入出力装置とし、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力装置での入力及び表示を代替してもよい。また、ホスト計算機２００、管理計算機１０のそれぞれの入出力装置は同じである必要はない。

次に図２を用いてストレージサブシステム１０００について説明する。

ストレージサブシステム１０００ａと、ストレージサブシステム１０００ｂとはデータ通信線５５０を介して接続される。また、ストレージサブシステム１０００は、記憶制御装置３００及びディスク装置１５００を備える。

なお、データ通信線５５０は一つ以上のネットワークから構成されてもよい。さらに、データ通信線５５０は、データ通信線５００と通信線５５のいずれかまたは両方と共用の通信線やネットワークであってもよい。

ディスク装置１５００は、ディスク型の記憶メディアのドライブであり、ホスト計算機２００から書き込み要求されたデータを記憶する。ディスク装置１５００に代えて、他種の記憶デバイス（例えばフラッシュメモリドライブ）が採用されても良い。記憶制御装置３００は、ストレージサブシステム１０００の全体を制御する。具体的には、記憶制御装置３００は、ディスク装置１５００へのデータの書き込み及びディスク装置１５００からのデータの読み出しを制御する。また、記憶制御装置３００は、ディスク装置１５００の記憶領域を、一つ以上の論理ボリュームＶｏｌとしてホスト計算機２００に提供する。なお、ディスク装置１５００は複数存在してもよい。

記憶制御装置３００は、メモリ１２００、キャッシュメモリ１１００（メモリ１２００と共用であってもよい）、ストレージポート１３２０、管理ポート１３３０、プロセッサ１３１０を備える。なお、記憶制御装置３００の実装にあたって、一つ以上の回路基盤上に、前記ハードウェア構成物（例えば、ストレージポート１３２０、管理ポート１３３０、やプロセッサ１３１０）のそれぞれが一つ以上存在していればよい。例えば、信頼性を向上させるためや高性能化などの理由から記憶制御装置３００を複数個から構成し、個々の記憶制御装置がメモリ１２００やストレージポート１３２０やプロセッサ１３１０を有してもよく、さらに複数のコントロールユニットにキャッシュメモリ１１００が接続されたハードウェア構成であってもかまわない。なお、図示は省略したが、記憶制御装置は一つ以上のバックエンドポートを有し、バックエンドポートがディスク装置１５００と接続されている。しかし、バックエンドポート以外のハードウェアによって記憶制御装置１０００がディスク装置と接続されてもよい。

キャッシュメモリ１１００は、ディスク装置１５００へ書き込まれるデータ及びディスク装置１５００から読み出されるデータを、一時的に記憶する。

ストレージポート１３２０は、データ通信線５００を介してホスト計算機２００と接続され、また、データ通信線５５０を介して他のストレージサブシステム１０００に接続されるインターフェースである。具体的には、ストレージポート１３２０は、ホスト計算機２００からのＩＯ要求を受信する。また、ストレージポート１３２０は、ディスク装置１５００から読み出されたデータをホスト計算機２００に返送する。更に、ストレージポート１３２０は、ストレージサブシステム１０００同士で交換されるデータを送受信する。

管理ポート１３３０は、制御線５５を介して、管理計算機１０に接続されるインターフェースである。具体的には、管理ポート１３３０は、管理計算機１０からの制御指示を受信する。ここで、制御指示はストレージ制御指示、バックアップ制御指示の２種類がある。ストレージ制御指示にはストレージ情報報告、レプリケーション構築指示、レプリケーション一時停止指示、レプリケーション再開指示、レプリケーションリバース指示、レプリケーション状態報告指示がある。バックアップ制御指示はホスト計算機２００の上のバックアッププログラムへの指示である。バックアップ制御指示にはボリューム情報報告指示、ＡＰ構成情報報告、バックアップ状態報告、スケジューラ登録指示、リフレッシュ指示、タスクスケジューラ登録指示、リストア指示、複合リストア指示がある。

プロセッサ１３１０は、メモリ１２００、に記憶されるプログラムを実行することによって、各種処理を行う。具体的には、プロセッサ１３１０は、ストレージポート１３２０によって受信されたＩＯ要求を処理する。また、プロセッサ１３１０は、ディスク装置１５００へのデータの書き込み及びディスク装置１５００からのデータの読み出しを制御する。また、プロセッサ１３１０は、以下に示すプログラムの処理によって、一以上のディスク装置１５００の記憶領域を基に論理ボリュームＶｏｌを設定する。

メモリ１２００には、プロセッサ１３１０によって実行されるプログラム及びプロセッサ１３１０によって必要とされる情報等が記憶される。具体的には、メモリ１２００には、ストレージ側レプリケーションペア情報１２１０、ストレージ側レプリケーション処理プログラム１２３０、ボリューム情報１２５０及びＩＯ処理プログラム１２９０が記憶される。

ＩＯ処理プログラム１２９０は、ホスト計算機からストレージポートを介して受信した読み込み要求又は書き込み要求を処理するプログラムである。その処理の概要は以下の通りである：
＊ 読み込み要求の場合：当該要求は論理ボリューム及び論理ボリューム内のアドレス、及びリード長を指定し、指定内容に応じてＩＯ処理プログラム１２９０はキャッシュメモリ１１００またはディスク装置１５００からデータを読み出し、ホスト計算機に送信する。
＊ 書き込み要求の場合：当該要求は論理ボリューム及び論理ボリューム内のアドレス、及び書き込みデータ長を指定し、また書き込みデータを伴う。ＩＯ処理プログラムは、書き込みデータをキャッシュメモリ１１００に一次格納後、指定内容に対応したディスク装置へ書き込みデータを書き込む。

以上、ストレージサブシステム１０００のハードウェア構成を示したが、ストレージサブシステム１０００ａとストレージサブシステム１０００ｂが必ずしも同一のハードウェア構成でなくてもよい。

次にメモリ１２００に格納されたプログラム及び情報について説明する。

ストレージ側レプリケーションペア情報１２１０は、レプリケーションペアを管理するための情報である。レプリケーションペアは、レプリケーションの対象となるストレージサブシステム１０００上の二つの論理ボリュームＶｏｌの対である。また、ストレージ側レプリケーションペア情報１２１０については、図１１で詳細を説明する。

ストレージ側レプリケーション処理プログラム１２３０は、レプリケーション処理（初期レプリケーション及び定常レプリケーション）を行う。レプリケーション処理については、図３５、３６で詳細を説明する。

ストレージ側ボリューム情報１２５０は、当該ストレージサブシステム１０００によって提供される論理ボリュームＶｏｌを管理するための情報である。なお、ストレージ側ボリューム情報１２５０については、図１５で詳細を説明する。
以上、説明した構成により、ホスト計算機２００ａ、２００ｂ、２００ｃ、２００ｄが送信した書き込みデータは主拠点のストレージサブシステム１０００ａ（正ストレージサブシステム）の論理ボリュームＶｏｌへ格納される。また計算機システムがリモートクラスタの場合、論理ボリュームＶｏｌに格納された書き込みデータは正ストレージサブシステムが同期レプリケーション又は非同期レプリケーションによって遠隔拠点のストレージサブシステム１０００ｂ（副ストレージサブシステム）へ転送され、転送された書き込みデータは副ストレージサブシステムの論理ボリュームＶｏｌへ格納される。これにより正ストレージサブシステムの論理ボリュームＶｏｌのデータであって、データ二重化の対象となるデータを冗長化することができ、その結果として正ストレージサブシステムの論理ボリュームＶｏｌのデータが消失した場合も副ストレージサブシステムの論理ボリュームＶｏｌに格納した複製データを用いてホスト計算機２００ｂもしくは２００ｄにて所定の処理を再開することができる。

（１−２）実施例１の概要
次に実施例１の概要を説明する。なお、本概要に説明の無い事項について権利を放棄するものではない。

はじめに、本発明によるローカルクラスタを適用した計算機システム（以降ローカルクラスタシステムとよぶ）におけるバックアップについて説明する。ローカルクラスタシステムでのバックアップ構成を図５に示す。図５−１は、通常状態のローカルクラスタシステムの構成である。ローカルクラスタは同一拠点にある複数のホスト計算機が同一ストレージサブシステムの論理ボリュームＶｏｌを共有する。なお、論理ボリュームの共有とは、前述の複数のホスト計算機が、同時とは限らないが論理ボリュームを指定したアクセス要求を送信するということを少なくとも意味する。なお、アクセス要求には読み込み要求及び書き込み要求が含まれる。

ローカルクラスタシステムでは、ホスト計算機２００ａと２００ｃの一方が活性状態で、もう一方が非活性状態となる。活性状態のホスト計算機は当該ホスト計算機上で動作する少なくとも１以上のアプリケーションプログラムが稼働し、クライアント計算機にアプリケーションプログラムのサービスを提供する。以下、クラスタシステムで制御対象となるアプリケーションプログラムを、クラスタ対象アプリケーションとよび、明細書中は単にＡＰと記載する。一方、非活性状態のホスト計算機ではクラスタ対象ＡＰは稼働しない、又はクライアント計算機に対象ＡＰによるサービスを提供しない。上記２つのホスト計算機それぞれはハードウェアや論理的な障害に備え、相手のホスト計算機の状態を監視する。また、バックアップは活性状態のホスト計算機が自計算機で生成した特定時期のデータをストレージサブシステムのレプリケーションで複製し、保存することで実現する。

ここで、活性状態のホスト計算機がバックアップ操作を指示を実施する理由は、ＡＰを静止化（バックアップ対象の論理ボリュームのデータをＡＰが回復可能な状態にするために短時間ＡＰの動きを停止する手続き）と、データレプリケーションのためのローカルレプリケーション制御を短時間に完了させる必要があるためである。短時間に上記バックアップのための手続きを完了できないと、いわゆるバックアップウィンドウ（バックアップのためにＡＰが停止する時間）が増大し、ＡＰの性能を著しく劣化させることになり、問題となる。

ここで、活性状態のホスト計算機２００ａが何らかの原因で故障した場合を考える。この場合、図５−２に示すように、非活性状態のホスト計算機２００ｃのクラスタが活性状態のホスト計算機２００ａで障害が発生したことを検出する。次に、非活性のホスト計算機２００ｃはＡＰ引き継ぎのため、ＡＰを起動し、その状態を非活性状態から活性状態に変更し、クライアント計算機からのアクセスを当該ホスト計算機宛てに切り替わるようにネットワーク設定を変更する。このネットワークの設定の変更には、仮想的なＩＰアドレス又はホスト名ＩＰといった仮想ホスト識別子を用意し、活性状態であるホスト計算機が変わった場合に、仮想ホスト識別子に対応するホスト計算機を、元は活性状態であったホスト計算機から新たに活性状態となったホスト計算機に切り替えることを含む。

なお、この対応付けの方法は仮想ＩＰアドレスの場合は、ホスト計算機のＥｔｈｅｒｎｅｔポートのＭＡＣアドレスとの対応をＡＲＰによって切り替える方法がある。また、仮想ホスト名を用いる対応付けの方法の場合は、ＤＮＳを操作して、ホスト名をホスト計算期間で切り替える方式がある。以後の説明では仮想ＩＰアドレス、仮想ホスト名を障害前後切り替える方式を前提として記載する。なお、前提方式では、クライアント計算機からは、ホスト計算機２００ではなく仮想的なアドレスを持つ計算機を意識することになるため、仮想的なアドレスを持つホスト計算機を仮想ホスト計算機とよぶことにする。ただし、本発明は前提方式に限定するものでははい。それ以外の方式（例えば、ＤＮＳ操作によるアドレス切り替え方式）であっても、本発明で扱う仮想ホスト計算機のアドレスを、障害前後で切り替えるアドレスとして取り扱うことで対処可能である。

ここで、上記のようなＡＰのホスト計算機間の引き継ぎをフェールオーバ処理とよぶ。フェールオーバ処理は障害を契機とする場合と、テスト目的とした手動を契機とする場合がある。また、フェールオーバ処理後のバックアップは、フェールオーバ後に活性になるホスト計算機２００ｃがフェールオーバ後に自計算機がアクセスする論理ボリュームの特定時点のデータをローカルレプリケーションで複製し、保存することで実現する。また、活性状態のホスト計算機で障害発生後もバックアップされたデータはストレージサブシステム上に保存されているため、バックアップ時のデータ保存論理ボリュームＶｏｌやその履歴をまとめた管理側カタログ情報も、フェールオーバを契機に活性、非活性のホスト計算期間で引き継がれる。これを実現するため、バックアップカタログ管理側カタログ情報もＡＰのデータ同様にストレージサブシステム上の論理ボリュームＶｏｌに保存し、当該ホスト計算期間で共有する。

次に、リモートクラスタを適用した計算機システム（以降リモートクラスタシステムとよぶ）におけるバックアップについて説明する。リモートクラスタシステムでのバックアップ構成を図６に示す。

図６−１は、通常状態のリモートクラスタシステムの構成である。リモートクラスタシステムは主拠点、遠隔拠点のそれぞれに存在するホスト計算機が異なるストレージサブシステムの論理ボリュームＶｏｌ上のデータをアクセスするクラスタ構成である。主拠点、遠隔拠点のホスト計算機間で、ＡＰが同一の処理を実施できるようにするために、両拠点のストレージサブシステムが論理ボリュームＶｏｌ間のデータを、リモートレプリケーションで内容一致させる。リモートクラスタシステムでも、ホスト計算機２００ａと２００ｂの一方が活性状態で、もう一方が非活性状態となる。活性状態のホスト計算機は当該ホスト計算機上で動作する少なくとも１以上のＡＰが稼働し、クライアント計算機にＡＰのサービスを提供する。バックアップは活性状態のホスト計算機２００ａが自計算機で生成した特定時期のデータをストレージサブシステムのローカルレプリケーションで複製し、保存することで実現する。

図６−２に示すように、フェールオーバ時、非活性状態のホスト計算機２００ｂではＡＰ引き継ぎのため、ＡＰを起動し、その状態を非活性状態から活性状態に変更する。また、フェールオーバ後バックアップデータの保存される主拠点ストレージサブシステムとは異なる遠隔拠点のストレージサブシステム上のデータをホスト計算機２００ｂはアクセスすることになるため、ホスト計算機はローカルクラスタのように同一ストレージサブシステムにあるバックアップしたデータを使用することができない。ただし、ストレージサブシステム間のリモートレプリケーションおよびローカルレプリケーションを組み合わせて制御することで、バックアップデータを使用することが可能となる。この処理については後述する。フェールオーバを契機に活性、非活性のホスト計算期間で引き継ぎを実現するためには、フェールオーバ前後でバックアップデータ保存先論理ボリュームＶｏｌが異なることを考慮した管理側カタログ情報の管理が必要となる。なお、リモートクラスタ構成でのフェールオーバの要因の一例は活性状態であったホスト計算機の障害や、活性状態であったホスト計算機がアクセスしていたストレージサブシステムの障害にも対応できる点がローカルクラスタ構成とは異なる点である。

ここで、図５、６からもわかるように、ローカルクラスタシステム、リモートクラスタシステムそれぞれで、システムおよびバックアップで必要となるレプリケーションの設定や形態が変わる。本実施例では、ローカルクラスタシステム、リモートクラスタシステムで異なるレプリケーション構成の設定を容易化する。以降、本文で、ローカルクラスタ、リモートクラスタと使い分けせず単にクラスタと記載する場合、ローカル、リモートの違いなく、クラスタ全般を指すものとする。

なお、本発明でのリモートクラスタを構成するためのレプリケーションとバックアップを作成するためのレプリケーションは、コピー元の論理ボリュームのデータをコピー先の論理ボリュームに複製する点では類似するが、異なる点がある。リモートクラスタ用のレプリケーションの場合、データコピー処理を継続的又は繰り返し行うことで、コピー先の論理ボリュームのデータをできるだけコピー元の論理ボリュームの最新時点のデータに近づける。これによってコピー元の論理ボリュームを提供するストレージサブシステムが被災した場合でも出来るだけ新しいデータ（またはコピー元の論理ボリュームと同じデータ）を持つコピー先の論理ボリュームを用いることで、コピーし損ねた更新データをできるだけ少なくして業務を再開することができる。このような用途（ディザスタリカバリ用途と呼ぶことがある）で用いる場合、典型的には一つのコピー元の論理ボリュームに対して一つのコピー先論理ボリュームが対応する。ただし、マルチターゲット方式と呼ばれる、複数のストレージ装置にレプリケーションする場合は一つのコピー元の論理ボリュームに複数の論理ボリュームが対応する場合もある。

一方のバックアップ用途でレプリケーションを用いる場合は、所定の時点のコピー元の論理ボリュームのデータをコピー先の論理ボリュームに物理的又は仮想的に生成する。バックアップデータはデータ消失または破損したデータを復旧させる場合に用いるほか、前述のレプリケーションではコピー処理によってコピー先の論理ボリュームにも障害が伝わってしまう類の障害にも対応できる。こうした障害の例としては管理者による御操作または語設定、ウィルス感染、プログラムの誤動作がある。またより好適にはバックアップデータは複数世代を作成することが多い。

なお、バックアップ用途の場合は仮想的にバックアップデータを提供する技術として論理スナップショットと呼ばれる技術もあり、本発明のバックアップデータ作成の一手段として採用してもよい。また、バックアップ用途の場合もコピー元の論理ボリュームとコピー先の論理ボリュームが同一のストレージサブシステム内に存在する必要はない。以後の説明では説明を簡単にするために、ディザスタリカバリ用途のレプリケーションをリモートレプリケーション、バックアップ用途のレプリケーションをローカルレプリケーションと呼ぶ。

なお、以後の説明ではフェールオーバ前に活性状態であるホスト計算機で実行するＡＰが一つの仮想ホスト識別子に対応するものとして説明する。しかし、ＡＰと仮想ホスト識別子との対応はこれに限らない。例えば、活性状態であるホスト計算機で実行するＡＰが複数の場合に、あるＡＰに対してはある仮想ホスト識別子を割り当て、別なＡＰには別な仮想ホスト識別子を割り当てても良い。

なお、以後の説明では「レプリケーション（Ｒｅｐｌｉｃａｔｉｏｎ）」を「レプリ（ＲＥＰＬＩ）」と略すことがある。

（１−３）本実施例１の計算機システムが扱う情報
（１−３−１）管理側ストレージ情報
図７は管理計算機１０に記憶される管理側ストレージ情報１１４Ｃの構成例を示した図である。なお、管理側ストレージ情報１１４Ｃはストレージサブシステム１０００から取得した情報を基に作成するテーブルであり、作成処理は後述で説明する。

管理側ストレージ情報１１４Ｃは、ホスト計算機２００が認識する論理ボリュームＶｏｌ（ボリュームＩＤ）とストレージサブシステムが割り当てる論理ボリュームＶｏｌ（ＨＷボリュームＩＤ）の対応関係を示すテーブルであり、ストレージサブシステムＩＤ１１４０２、論理ボリュームＩＤ１１４０３、ＨＷ論理ボリュームＩＤ１１４０４を含む。

ストレージサブシステムＩＤ１１４０２は、管理計算機１０によって管理されるストレージサブシステム１０００の識別子である。

ホストＩＤ１１４０５は、計算機システムにおいてホスト計算機２００をユニークに識別するために使用する識別子である。クラスタの場合、クライアント計算機との接続性を考慮し、仮想的なホスト計算機をクライアント計算機に提供する場合がある。当該ホストＩＤ１１４０５には、ホストＩＤが設定される。

論理ボリュームＩＤ１１４０３は、ホスト計算機がストレージサブシステム１０００の内の論理ボリュームＶｏｌを識別するための論理ボリュームＶｏｌの識別子である。図５では２３：１０などの情報が格納されている。

ＨＷ論理ボリュームＩＤ１１４０４は、ストレージサブシステムＩＤ１１４０２が示すストレージサブシステム１０００の内部処理で使用するために、ストレージサブシステム１０００が自ストレージサブシステム内で付与して管理している論理ボリュームＶｏｌの識別子である。図５では２３：１０などの情報が格納されている。

以上の説明では管理側ストレージ情報１１４Ｃはテーブル構造を有する情報として説明したが、当該情報は各拠点が有するストレージサブシステム１０００と、当該ストレージサブシステム１０００が有するボリュームを特定できればテーブル以外のデータ構造であってもよい。

さらに、複数の管理側ストレージ情報１１４Ｃをまとめた前述の管理側ストレージ情報も各拠点に対応するストレージサブシステムと、当該ストレージサブシステムが有するボリュームを特定できればどの様なデータ構造であってもよい。

（１−３−２）管理側レプリケーション情報
図８は管理計算機１０に記憶される管理側レプリケーション情報１１３Ｃの構成例を示した図である。なお、管理側レプリケーション情報１１３Ｃは、レプリケーションを管理するための情報で、管理計算機１０が主拠点の管理側ストレージ情報テーブル１１３Ａ、遠隔拠点の管理側ストレージ情報テーブル１１３Ｂの両方のテーブルを作成する。この動作の詳細は後述する。

管理側レプリケーション情報１１３Ｃは、管理計算機１０がレプリケーションを構築するごとに作成されるテーブルであり、この要求ごとに当該テーブルにレプリケーショングループＩＤ（レプリケーショングループ識別子）が付与される。レプリケーショングループは複数のレプリケーションペアの集合である。

管理側レプリケーション情報１１３Ｃには、レプリケーショングループＩＤ１１３００、レプリケーションオプション情報１１３０１、レプリケーション状態１１３０２及びレプリケーション構成情報１１３０３から１１３０７が含まれる。

レプリケーショングループＩＤ１１３００は、複数のレプリケーションペアをまとめてグループで管理するための識別子である。

レプリケーションオプション情報１１３０１は、レプリケーション種別及びレプリケーションオプション情報を含む。レプリケーション種別は、ストレージサブシステム１０００が提供する機能である。レプリケーション種別には、ローカルレプリケーション、同期リモートレプリケーション、非同期リモートレプリケーションのいずれかを示す。ここで、レプリケーションの種別は大きくローカルレプリケーション、リモートレプリケーションある。リモートレプリケーションとは、異なるストレージサブシステム１０００間で行われるレプリケーションであり、この場合、レプリケーション元の論理ボリュームＶｏｌ（正論理ボリュームとよぶ）とレプリケーション先の論理ボリュームＶｏｌ（副論理ボリュームとよぶ）とが別々のストレージサブシステム１０００ａとストレージサブシステム１０００ｂに存在する。

リモートレプリケーションはさらに同期リモートレプリケーションか、非同期リモートレプリケーションがある。同期リモートレプリケーションはホスト計算機によるデータの書き込みと、正論理ボリュームと副論理ボリュームの内容の一致のためのレプリケーション処理の時期が一致しているリモートレプリケーションである。また、非同期リモートレプリケーションはホスト計算機によるデータの書き込みと、正論理ボリュームと副論理ボリュームの内容の一致のためのレプリケーション処理の時期が一致していないリモートレプリケーションある。また、レプリケーションオプション情報には、レプリケーション種別毎に備わるオプションを指定することも出来る。オプション情報には、例えば、リモートレプリケーションの一時停止時にレプリケーション先の論理ボリュームＶｏｌ（副論理ボリューム）への書き込みが可能か否かを表すものがある。リモートレプリケーションの一時停止とは、管理計算機１０からの要求によるリモートレプリケーションの一時停止である。

レプリケーション状態情報１１３０２は、このレプリケーション情報１１３によって管理されるレプリケーションの現在の状態を示す。具体的には、例えば、レプリケーション状態情報１１３０２は、このレプリケーション情報１１３によって管理されるレプリケーションの状態が、未コピー、コピー中、一時停止、ペア状態又は異常状態のいずれであるかを示す。

レプリケーション構成情報は、ペアＩＤ１１３０３、正ストレージサブシステムＩＤ１１３０４、ＨＷボリュームＩＤ１１３０５、副ストレージサブシステムＩＤ１１３０６及び副ＨＷボリュームＩＤ１１４０７を含む。

ペアＩＤ１１３０３は、管理計算機１０がペアに付与する識別子である。

正ストレージサブシステムＩＤ１１３０４は、正論理ボリュームを提供するレプリケーション元（以下、正側）のストレージサブシステム（以下、正ストレージサブシステム）１０００ａの識別子である。正ストレージサブシステム１０００ａは、拠点計算機装置１００ａ、ホスト計算機２００ａからのデータを格納する。

正ＨＷボリュームＩＤ１１３０５は、正ストレージサブシステム１０００ａが自ストレージサブシステム内で管理するために付与する正論理ボリュームの識別子である。

副ストレージサブシステムＩＤ１１３０６は、レプリケーション先の副論理ボリュームを提供するレプリケーション先（以下、副側）のストレージサブシステム１０００ｂ（以下、副ストレージサブシステム）の識別子である。

副ＨＷボリューム１１３０７は、副ストレージサブシステム１０００ｂが自ストレージサブシステム内で管理するために付与する副論理ボリュームの識別子である。

なお、正論理ボリュームとはコピー元の論理ボリュームを指し、副論理ボリュームとはコピー先の論理ボリュームを指す。一つのストレージシステムは複数の論理ボリュームを提供し、それぞれは個別に正論理ボリュームと副論理ボリュームになり得る。従って、正ストレージサブシステムと呼ぶ場合は、当該サブシステムには正論理ボリュームしか存在しないということではなく、説明対象となる正論理ボリュームと副論理ボリュームのレプリケーションペアを説明の中心とした際に説明を簡単にするために割り当てた名前に過ぎない。このことは副ストレージサブシステムという用語についても同様である。

またレプリケーション状態のそれぞれの状態は以下の意味を持つ。

＊ 未コピー状態：コピーが開始されていないことを示す状態である。

＊ コピー中状態：正論理ボリュームのデータを副論理ボリュームにコピーしている途中の状態である。本状態は未コピー状態から遷移する他、一時停止状態又は異常状態から遷移する場合もある。

＊ ペア状態：正論理ボリュームのデータを副論理ボリュームにコピー完了し、さらに正論理ボリュームに対する書き込みデータを副論理ボリュームに反映する処理が動作していることを示す状態である。本状態はコピー中状態から遷移する。なお、ディザスタリカバリ用途の場合は、レプリケーションペアが本状態になっていないとより最新のデータを用いたＡＰの業務回復ができない。

＊ 一時停止状態：ペア状態における書き込みデータの反映を停止した状態で、副論理ボリュームには正論理ボリュームの反映処理を停止した時点のデータが格納される。なお、前述の論理スナップショット等のバックアップ用途のレプリケーションでは、副論理ボリュームが仮想的にでも所定の時点の正論理ボリュームのデータを格納しているようにホスト計算機に提供できれば良いため、反映処理が停止していなくても良い。さらに、本状態中の正論理ボリューム又は副論理ボリュームへの書き込みについては、書き込み位置をビットマップ等で記録してもよい。この書き込み位置情報は、コピー中状態に遷移した時のコピーを当該情報に記録した位置に限定することでコピー量を減らすことができるためである。

＊ 異常状態：何らかの障害、例えばストレージサブシステムやサブシステム間のネットワークの障害、によってコピー処理が異常停止したことを示す状態である。本状態はコピー中状態又はペア状態から遷移する。なお、本状態でも一時停止状態で説明したような書き込み位置情報を用いた書き込み位置の記録を行っても良い。

以上の説明では管理側レプリケーション情報１１３Ｃはテーブル構造を有する情報として説明したが、当該情報はレプリケーショングループと一つ以上のレプリケーションペアとの対応、またはレプリケーショングループ（またはレプリケーションペアの）レプリケーション状態、またはレプリケーションペアとストレージサブシステム１０００とボリュームとの対応を有するのであれば、テーブル以外のデータ構造であってもよい。

さらに、複数の管理側レプリケーション情報１１３Ｃをまとめた情報をレプリケーション情報として扱ってもよく、この場合もレプリケーション情報はレプリケーショングループと一つ以上のレプリケーションペアとの対応、またはレプリケーショングループ（またはレプリケーションペアの）レプリケーション状態、またはレプリケーションペアとストレージサブシステム１０００とボリュームとの対応を有するのであれば、テーブル以外のデータ構造であってもよい。

（１−３−３）管理側バックアップ情報
図９は管理計算機１０に記憶される管理側バックアップ情報１８の構成例を示す図である。

管理側バックアップ情報１８は利用者に指定されたバックアップの要件を保持する。管理側バックアップ情報１０は、バックアップＩＤ１８０１、ホストＩＤ１８０２、ＡＰ１８０３、データ１の１８０４、データ２の１８０５、Ｂａｃｋｕｐ欄（開始１８０７、間隔１８０８、保護期間１８０９）が含まれる
バックアップＩＤ１８０１は管理計算機１０がバックアップ対象に付与する識別子である。

仮想ホストＩＤ１８０２はホスト計算機の識別子である。クラスタの場合、クライアント計算機との接続性を考慮し、仮想的なホスト計算機をクライアント計算機に提供する場合がある。その場合、当該仮想ホストＩＤ１８０２には、仮想的なホストＩＤが設定される。また、クラスタでない場合は、通常のホストＩＤがＩＤ１８０２に格納される。

ＡＰ１８０３はＡＰ２１１の識別子である。

データ１（１８０４）は、ＡＰ２１１動作中のホスト計算機２００が参照するデータの名称である。ＡＰ２１１のデータが複数の階層で構成される場合は、最上位階層で識別されるデータ名称が格納される。

データ２（１８０５）は、ＡＰ２１１動作中のホスト計算機２００が参照する階層化されたデータの内、上位２階層目で識別されるデータ名称である。ＡＰ２１１のデータが複数の階層で構成されない場合は格納されない。以後の実施例ではＡＰ２１１のデータが２階層であることを前提としている。しかし、ＡＰ２１１のデータ階層が３階層以上の場合、その階層の数に応じ当該階層のデータ名称を保存する情報が追加すれば本発明は適用可能である。

Ｂａｃｋｕｐ欄の開始１８０７はバックアップの開始時刻が保存される。Ｂａｃｋｕｐ欄の間隔１８０８はバックアップを取得する時間間隔である。Ｂａｃｋｕｐ欄の保護期間１８０９はバックアップされたデータを保護する期間である。

（１−３−４）管理側カタログ情報
図１０は、管理計算機１０に記憶される管理側カタログ情報１８の構成例を示す図である。管理側カタログ情報１８はバックアップデータに関する情報を保持する。管理側カタログ情報１８は、バックアップＩＤ１４０１、Ｒｅｍｏｔｅ Ｃｌｕｓｔｅｒ１４０３、ホストＩＤ（１ｓｔから２ｎｄ）、活性ホストＩＤ１４０７が含まれる。

バックアップＩＤ１４０１はバックアップを識別するための識別子である。

Ｒｅｍｏｔｅ Ｃｌｕｓｔｅｒ１４０３は計算機システムがリモートクラスタか否かを示す。リモートクラスタの場合、さらに当該ホストＩＤに関連するレプリケーショングループＩＤがレプリケーショングループＩＤ１４０４に格納される。

ホストＩＤの１ｓｔ１４０５にはホストＩＤが保存される。同様に、２ｎｄ１４０６には２つめのホストＩＤが保存される。図１０では２ｎｄまでしか欄が存在しないが、３ｒｄ以降の欄があっても構わない。前述のようにクラスタの場合、ホスト計算機が仮想化される場合があり、その場合、このホストＩＤには当該仮想ホスト計算機に対応する３つめ以降のホスト計算機ＩＤを保存する。

活性ホストＩＤ１４０７はクラスタシステムにおける活性状態のホスト計算機を指す。

（１−３−５）管理側拠点カタログ情報
図１１は、管理計算機１０に記憶される管理側カタログ情報１５の構成例を示す図である。

管理側拠点カタログ情報１５はバックアップで使用するレプリケーションとバックアップ時刻に関する情報を保持する。管理側拠点カタログ情報１５はバックアップＩＤ１５００１、ホストＩＤ１５００２、使用中世代１５００３、世代数１５００４、世代１のグループ１５００５、世代１の時刻１５００６、世代２のグループ１５００７、世代２の時刻１５００８、世代１のグループ１５００９、世代１の時刻１５０１０を含む。

バックアップＩＤ１５００１は管理計算機１０がバックアップ対象に付与する識別子である。

ホストＩＤ１５００２はホストＩＤが保存される。

使用中世代１５００３は、現在バックアップで使用中のレプリケーショングループを指す。

世代数１５００４は、同一バックアップ対象に使用するレプリケーションの世代数を示す。レプリケーションの世代とは複製元のデータが共通で複製先が異なるレプリケーショングループの数を表す。レプリケーションに世代を設けることで、同一データを異なる時間で複数複製することが出来る。すなわち、レプリケーションの世代数が３の場合、バックアップ対象のデータが同一ストレージサブシステム内に異なる３つの時間でバックアップされていることを指す。

次の世代１（グループ１５００５、時刻１５００６）から世代３（グループ１５００９、時刻１５０１０）はバックアップの取得時間とそのバックアップが保存されるレプリケーショングループの関係を世代別に示す。前述の通り、世代数分、本情報１５００５から１５００６は存在する。なお、当然ながら本発明は３世代以外のバックアップ世代についても適用可能であることはいうまでもない。

（１−３−６）管理側ＡＰボリューム対応情報
図１２は、管理計算機１０に記憶される管理側ＡＰボリューム対応情報１３の構成例を示す図である。

管理側ＡＰボリューム対応情報１３はホスト計算機上で稼働するバックアップ対象のアプリケーションプログラム（ＡＰ）の扱うデータと当該データが配置される論理ボリュームＶｏｌの対応関係を管理するための情報である。管理側ＡＰボリューム対応情報１３は、ホストＩＤ１３００１、仮想ホストＩＤ１３００２、アプリ名１３００２、データ１（１３００４）、データ２（１３００５）、ボリュームＩＤ１３００６が含まれる。

ホストＩＤ１３００１は、ホスト計算機２００の識別子である。クラスタの場合、クライアント計算機との接続性を考慮し、仮想的なホスト計算機をクライアント計算機に提供する場合がある。その場合、当該ホストＩＤ１８０２には、仮想的なホストＩＤが設定される。また、クラスタでない場合は、通常のホストＩＤがＩＤ１３００１に格納される。

仮想ホストＩＤ１３００２は、クラスタ対象のホスト計算機に設定される仮想的なホスト計算機の識別子である。仮想ホストＩＤ１３００２は、クラスタ環境の場合、使用される。

アプリ名１３００３は、当該ホスト計算機２００上で動作するＡＰ２１１の名称である。

データ１（１３００４）は、ＡＰ２１１動作中のホスト計算機２００が参照するデータの名称である。ＡＰ２１１のデータが複数の階層で構成される場合は、最上位階層のデータ名称が格納される。

データ２（１３００５）は、ＡＰ２１１動作中のホスト計算機２００が参照する階層化されたデータの内、上位２階層目のデータ名称である。ＡＰ２１１のデータが複数の階層で構成されない場合は格納されない。

ボリュームＩＤ１３００６は、ＡＰ２１１のデータを格納する論理ボリュームＶｏｌで、当該ホスト計算機２００がストレージサブシステム１０００内の論理ボリュームＶｏｌを識別するための論理ボリュームＶｏｌの識別子である。

（１−３−７）管理側クラスタ構成情報
図１３は、管理計算機１０に記憶される管理側クラスタ構成情報１９の構成例を示す図である。

管理側クラスタ構成情報１９は本計算機システムのクラスタ構成を管理するための情報である。管理側クラスタ構成情報１９は、仮想ホストＩＤ１９００１、Ｒｅｍｏｔｅ Ｃｌｕｓｔｅｒ１９００２、ホストＩＤ（１ｓｔ１９００３、２ｎｄ１９００４）が含まれる。

仮想ホストＩＤ１９００１は、クラスタ対象のホスト計算機２００に設定される仮想的なホスト計算機の識別子である。

Ｒｅｍｏｔｅ Ｃｌｕｓｔｅｒ１９００２は計算機システムがリモートクラスタか否かを示す。リモートクラスタの場合、さらに当該ホストＩＤに関連するレプリケーショングループＩＤがレプリケーショングループＩＤ１４０４に格納される。

ホストＩＤの１ｓｔ１９００２には上記仮想ホスト計算機に対応するホストＩＤが保存される。同様に、２ｎｄ１４０６には上記仮想ホスト計算機に対応する２つめのホストＩＤが保存される。図１３ではホスト計算機が２つの場合の例であり、ホスト計算機が２つであることを限定するものではない。たとえば、ホストが３つの場合、ホストＩＤには３ｒｄまで情報欄が追加される。当然ながら本発明は一つの仮想ホストを提供するホストが３つ以外であってもよい。

（１−３−８）ストレージ側レプリケーションペア情報
図１４は、本発明の実施例１のストレージサブシステム１０００に記憶されるストレージ側レプリケーションペア情報１２１０の構成例を示す図である。

ストレージ側レプリケーションペア情報１２１０は、レプリケーションペアＩＤ１２１００１、ボリュームＩＤ１２１０２、レプリケーション状態情報１２１０３、レプリ対象ストレージサブシステムＩＤ１２１０４、レプリ対象ボリュームＩＤ１２１０５、レプリケーション種別１２１０６、およびレプリケーショングループＩＤ１２１０７を含む。

レプリケーションペアＩＤ１２１０２は、論理ボリュームＩＤ１２１０２によって識別される論理ボリュームＶｏｌ、及びレプリ対象ボリュームＩＤ１２１０５によって識別される論理ボリュームＶｏｌを含むレプリケーションペアの識別子である。具体的には、上述のレプリケーション情報１１３のペアＩＤ１１４０３が登録される。

ボリュームＩＤ１２１０２は、当該レプリケーションペア情報１２１０を記憶するストレージサブシステム１０００によって提供される論理ボリュームＶｏｌの識別子である。

レプリケーション状態情報１２１０３は、論理ボリュームＩＤ１２１０１によって識別される論理ボリュームＶｏｌに対するレプリケーションの現在の状態を示す。具体的には、レプリケーション状態情報１２１０３は、当該レプリケーションペアＩＤが指すレプリケーションペアの状態が、未コピー、コピー中、一時停止中又は異常のいずれであるかを示す。

レプリ対象ストレージサブシステムＩＤ１２１０４は、論理ボリュームＩＤ１２１０１によって識別される論理ボリュームＶｏｌとレプリケーションペアになるレプリケーション先の論理ボリュームＶｏｌを提供するストレージサブシステム１０００の識別子である。つまり、レプリ対象ストレージＩＤ１２１０３には、副ストレージサブシステム１０００の識別子が格納される。

レプリ対象ボリュームＩＤ１２１０５は、論理ボリュームＩＤ１２１０２によって識別される論理ボリュームＶｏｌとレプリケーションペアになる論理ボリュームＶｏｌの識別子である。つまり、レプリ対象ボリュームＩＤ１２１０５には、論理ボリュームＩＤ１２１０２によって識別される論理ボリュームＶｏｌに記憶されるデータのレプリケーション先となる副論理ボリュームの識別子が格納される。

レプリケーション種別ＩＤ１２１０６は、ストレージサブシステム１０００が提供する機能であり、同期リモートレプリケーションか、非同期リモートレプリケーション、ローカルレプリケーションのいずれであるかを示す。

レプリケーショングループＩＤ１２１００はレプリケーションペアＩＤ１２１０１２１０１によって識別されるレプリケーションペアが属するレプリケーショングループの識別子である。ストレージサブシステム１０００は、一つ以上のレプリケーションペアを含むレプリケーショングループを管理する。そのため、管理計算機１００は、レプリケーショングループを指定して、リモートレプリケーションの運用の一時停止、再開又は解除をグループに含まれるレプリケーションペアを一括して要求できる。

以上の説明ではレプリケーションペア情報１２１０はテーブル構造を有する情報として説明したが、当該情報は、レプリケーションペアとレプリケーショングループとの対応、レプリケーションペアとストレージのボリュームの対応、レプリケーションペアのレプリケーション種別とレプリケーション状態と、を有するのであればテーブル以外のデータ構造であってもよい。

また、ストレージサブシステム１０００ａのレプリケーションペア情報１２１０ａとストレージサブシステム１０００ｂのレプリケーションペア情報１２１０ｂは必ずしも同じデータ構造や同じデータを有しなくても良い。

（１−３−９）ストレージ側ボリューム管理情報
図１５は、本発明の実施例１のストレージサブシステム１０００に記憶されるストレージ側ボリューム管理情報１２５０の構成例を示す図である。

ストレージ側ボリューム管理情報１２５０は、論理ボリュームＩＤ１２５０１、ボリューム状態情報１２５０２、容量１２５０３、レプリケーションペアＩＤ１２５０４及びグループＩＤ１２５０５を含む。

論理ボリュームＩＤ１２５０１は、当該ボリューム管理情報１２５０を記憶するストレージサブシステム１０００によって提供される論理ボリュームＶｏｌの識別子である。

ボリューム状態情報１２５０２は、論理ボリュームＩＤ１２５０１によって識別される論理ボリュームＶｏｌの現在の状態を示す。具体的には、ボリューム状態情報１２５０２には、正論理ボリューム、副論理ボリューム、正常、異常又は未実装のうち少なくとも一つが格納される。

例えば、論理ボリュームＩＤ１２５０１によって識別される論理ボリュームＶｏｌが正論理ボリュームの場合、ボリューム状態情報１２５０２には「正論理ボリューム」が格納される。また、論理ボリュームＩＤ１２５０１によって識別される論理ボリュームＶｏｌが副論理ボリュームの場合、ボリューム状態情報１２５０２には「副論理ボリューム」が格納される。なお、正論理ボリュームとはリモートレプリケーションのレプリケーション元であるボリュームを示し、副論理ボリュームとはリモートレプリケーションのレプリケーション先であるボリュームを示す。

また、論理ボリュームＩＤ１２５０１によって識別される論理ボリュームＶｏｌにホスト計算機２００が正常にアクセスできる場合、ボリューム状態情報１２５０２には「正常」が格納される。また、論理ボリュームＩＤ１２５０１によって識別される論理ボリュームＶｏｌにホスト計算機２００が正常にアクセスできない場合、ボリューム状態情報１２５０２には「異常」が格納される。例えば、ディスク装置１５００の故障時、レプリケーションの障害時に、ボリューム状態情報１２５０２には「異常」が格納される。

また、論理ボリュームＩＤ１２５０１によって識別される論理ボリュームＶｏｌにデータが格納されていない場合、ボリューム状態情報１２５０２には「未実装」が格納される。

容量１２５０３は、論理ボリュームＩＤ１２５０１によって識別される論理ボリュームＶｏｌの容量である。レプリケーションペアＩＤ１２５０５は、論理ボリュームＩＤ１２５０１によって識別される論理ボリュームＶｏｌを含むレプリケーションペアの一意な識別子である。

レプリケーションペアＩＤ１２５０４は、論理ボリュームＩＤ１２５０１に関連するレプリケーションペアの識別子である。具体的には、図６で説明したレプリケーション情報１１３のペアＩＤ１１３０３が格納される。

レプリケーショングループＩＤ１２５０５は、レプリケーションペアＩＤ１２５０４が属するレプリケーショングループの識別子である。管理計算機１００がレプリケーション要求をするごとに作成されるレプリケーション情報テーブル１１４に付与されたレプリケーショングループＩＤが格納される。

以上の説明ではストレージ側ボリューム管理情報１２５０はテーブル構造を有する情報として説明したが、当該情報は論理ボリュームＶｏｌの状態、容量を有するのであればテーブル以外のデータ構造であってもよい。また、当該情報に論理ボリュームＶｏｌとレプリケーションペアとの対応や、論理ボリュームＶｏｌとレプリケーショングループとの対応を有しても良い。

また、ストレージサブシステム１０００ａのボリューム管理情報１２５０ａとストレージサブシステム１０００ｂのストレージ側ボリューム管理情報１２５０ｂは必ずしも同じデータ構造や同じデータを有しなくても良い。

（１−４）実施例１の計算機システムの情報作成処理動作
これより、実施例１の計算機システムの処理動作を説明する。なお、本実施例では、クラスタシステムに必要な設定はホスト計算機２００において、実施されているものとする。ただし、リモートクラスタにおけるリモートレプリケーションは構築されておらず、ホスト計算機２００上のクラスタプログラムは停止状態であるものとする。

（１−４−１）管理側ストレージ情報の作成処理
それでは、はじめに、管理側ストレージ情報１１４Ｃの作成処理について説明する。当該作成は、管理計算機１０が管理プログラム１２に基づいて実行する。

図１６は管理計算機１０によるストレージサブシステム１０００に関する管理側ストレージ情報１１４Ｃ作成のためのフローである。

管理計算機１０は、使用者からアドレスもしくはストレージサブシステムＩＤを受け取る。管理計算機１０は受け取ったアドレスを基に、ストレージ制御指示を発行する（ステップ５０００）。

次にストレージサブシステム１０００は、ステップ５０００から送られた制御指示を受け取ると、当該指示内容を解析する（ステップ５０１０）。

次に、ストレージサブシステム１０００は、解析内容に基づき、メモリ１２００からストレージ側ボリューム管理情報１２５０を参照し、当該管理情報の内容を前述の制御指示の応答として返信する（ステップ５０２０）。当該管理情報の内容には、ＨＷ論理ボリュームＩＤ、ボリューム状態情報、容量が含まれる。ここで、ストレージサブシステムＩＤはネットワークアドレス（たとえばＩＰアドレス）であっても、ハードウェア製品番号などのＩＤでも構わない。ただし、ハードウェア製品番号の場合、上記の管理情報には当該ハードウェア製品番号が含まれる。

管理計算機１０は、ストレージサブシステム１０００からの制御指示の応答を受信すると、その内容を解析し、正常か否かを判定する（ステップ５０３０）。

ストレージサブシステム１０００からの制御指示の返答が正常であった場合（ステップ５０３０Ｙｅｓ）、管理計算機１０は管理側ストレージ情報１１４Ｃを作成する。作成の際、ホストＩＤ１１４０５、ボリュームＩＤ１１４０３はストレージサブシステムでは得られない情報であるため、空白のままにする。

一方、ストレージサブシステム１０００からの制御指示の応答が正常でなかった場合（ステップ５０３０Ｎｏ）、管理計算機１０は指定されたアドレスにはストレージサブシステムが存在しないことを通知する。

（１−４−２）管理側クラスタ構成情報の作成処理
次に、管理側クラスタ構成情報の作成処理について説明する。当該作成は、管理計算機１０が管理プログラム１２に基づいて実行する。

図１７は管理計算機１０によるクラスタシステムの管理情報で管理側クラスタ構成情報１９の作成のためのフローである。

管理計算機１０は、端末等の入力画面を通して、使用者からクラスタシステムを管理する上で必要となるホスト計算機のアドレスと、当該ホスト計算機に対応する仮想ホスト計算機のアドレスを受け取る（ステップ５１００）。ここで、当該アドレスとは、ホスト計算機のネットワークアドレス、もしくはネットワークホスト名で、本明細書では、ホストＩＤと同じ意味で扱う。通常、クラスタシステムの場合、１つの仮想ホスト計算機に複数のホスト計算機が対応する。図１８に入力画面例を示す。図１８ではアドレス“ｈｏｓｔ１”の仮想ホスト計算機に対し、２つのホスト計算機（アドレス”ｐｈｏｓｔ１”，” ｐｈｏｓｔ２”）が入力されている。

次に、管理計算機１０は使用者から入力されたアドレスを指示先にしたバックアップ制御指示（ボリューム情報報告）を作成し、ホスト計算機２００に発行する（ステップ５１１０）。たとえば、図１８の入力に対しては、２つのホスト計算機のアドレスが指定されているため、管理計算機１０はバックアップ制御指示を２つの異なるホスト計算機に発行する。

ホスト計算機２００は、当該指示を受け取ると、その指示内容を解析（ステップ５１２０）し、次に、ＯＳ２１２に当該ＯＳが管理するボリューム情報を取得する。当該ＯＳから得られるボリューム情報には、当該ＯＳが管理する全ボリュームのボリュームＩＤとＨＷボリュームＩＤ、および、当該ＨＷボリュームが存在するストレージサブシステムのＩＤが含まれる。次に、ホスト計算機２００は、当該ボリューム情報を含めたバックアップ制御指示の応答を作成し、管理計算機１０に返信する（ステップ５１３０）。

管理計算機１０は、ホスト計算機２００からバックアップ制御指示の応答を受信すると、その内容を解析し、正常な応答か否かを判定する（ステップ５１４０）。

ホスト計算機２００の応答が正常であった場合（ステップ５１４０Ｙｅｓ）、管理計算機１０は、全ホスト計算機２００の応答から得た、ストレージサブシステムＩＤとＨＷ論理ボリュームの組み合わせの中で、共通な組み合わせがあるか否かを判定する（ステップステップ５１５０）。

ストレージサブシステムＩＤとＨＷ論理ボリュームの組み合わせが他のホスト計算機の応答から得られる組み合わせと共通なものがある場合（ステップ５１５０Ｙｅｓ）、管理計算機１０はクラスタシステムがローカルクラスタであると判定し、当該判定を基に管理側クラスタ構成情報１９を作成する。具体的に、管理側クラスタ構成情報１９のＲｅｍｏｔｅ Ｃｌｕｓｔｅｒ１９００２を“Ｎｏ”に設定し、さらに、使用者の入力情報の仮想ホスト計算機のアドレスを仮想ホストＩＤ１９００１に、ホスト計算機のアドレスを１以上含んだ、管理側クラスタ構成情報１９を作成する。次に、管理計算機１０は、ステップ５１００で入力されたホスト計算機と、上記応答から得られたストレージサブシステム、ボリュームＩＤ、ＨＷボリュームＩＤの対応関係（Ｅ２Ｅ情報とよぶことにする）がわかるため、図１６で作成された管理側ストレージ情報１１４ＣのストレージサブシステムＩＤとＨＷボリュームＩＤが一致する上記Ｅ２Ｅ情報の内容を空白部分（ボリュームＩＤ、ホストＩＤ）に埋める。

ストレージサブシステムＩＤとＨＷ論理ボリュームの組み合わせが他のホスト計算機の応答から得られる組み合わせとすべて異なる場合（ステップ５１５０Ｎｏ）、管理計算機１０はクラスタシステムがリモートクラスタであると判定し、Ｒｅｍｏｔｅ Ｃｌｕｓｔｅｒ１９００２の設定がＹｅｓである管理側クラスタ構成情報１９を作成する。次に、管理計算機１０は、ステップ５１００で入力されたホスト計算機と、上記応答から得られたＥ２Ｅ情報がわかるため、図１６で作成された管理側ストレージ情報１１４ＣのストレージサブシステムＩＤとＨＷボリュームＩＤが一致する上記Ｅ２Ｅ情報の内容を空白部分（ボリュームＩＤ、ホストＩＤ）に埋める。

（１−４−３）管理側ＡＰボリューム対応情報
次に、管理側ＡＰボリューム対応情報の作成処理について説明する。当該作成は、管理計算機１０が管理プログラム１２に基づいて実行する。

図１９は管理計算機１０によるホスト計算機２００上で動作するＡＰとそのＡＰが使用するボリュームを対応づけて管理する管理側ＡＰボリューム構成情報１９を作成するためのフローである。

管理計算機１０は、端末等の入力画面を通して、使用者から仮想ホスト計算機のアドレスと当該仮想ホスト計算機が指すホスト計算機２００上で動作するアプリケーション名を受け取る（ステップ５２００）。ここで、仮想ホスト計算機のアドレスを指定する理由は、使用者の情報入力の手続きを削減するためである。従って、ホスト計算機２００による入力でも構わないが、その場合、複数のホスト計算機２００を指定する必要がある。また、複数のアプリケーション名が指定されても構わない。本実施例では、管理側クラスタ構成情報の作成と管理側ＡＰボリューム対応情報はそれぞれ個別の処理として記載するが、一連の手続きであっても構わない。また、図２０に入力画面例を示す。

次に、管理計算機１０は使用者から入力されたアドレスを指示先にしたバックアップ制御指示（ＡＰ構成情報報告）を作成し、指定された仮想ホスト計算機に対応する複数のホスト計算機２００に発行する（ステップ５２００）。たとえば、２つのホスト計算機と１つの仮想ホスト計算機が対応する場合、管理計算機１０はバックアップ制御指示を２つの異なるホスト計算機に発行する。

ホスト計算機２００は、当該指示を受け取ると、その指示内容を解析（ステップ５２１０）し、次に、ＡＰ２１１もしくはＯＳ２１２が管理するＡＰ２１１と使用ボリュームに関する情報を取得する。当該情報には、当該ＡＰが使用する全データの情報と当該データが配置されるボリュームＩＤが含まれる。ここで、上記ＡＰ２１１が使用するデータは複数の階層に分類される場合があり、その場合、それらすべての分類された情報をホスト計算機２００は収集し、ボリュームの情報と対応づけた情報として、バックアップ制御指示の応答を作成し、管理計算機１０に返信する（ステップ５２２０）。

管理計算機１０は、ホスト計算機２００からバックアップ制御指示の応答を受信すると、その内容を解析し、正常な応答か否かを判定する（ステップ５２３０）。

ホスト計算機２００の応答が正常であった場合（ステップ５２３０Ｙｅｓ）、管理計算機１０は、取得した応答から管理側ＡＰボリューム対応情報１３を作成する（ステップ５１５０）。具体的に、管理計算機１０は取得した応答から、ＡＰが使用する全データの情報をデータ１（１３００４）およびデータ２（１３００５）に、ボリュームＩＤを１３００６に格納した管理側ＡＰボリューム対応情報１３を作成する。

ホスト計算機２００の応答が正常ではなかった場合（ステップ５２３０Ｎｏ）、管理計算機１０はアプリケーション情報取得を失敗したことを使用者に通知する。

（１−４−４）バックアップ設定のための処理
次に、管理計算機１０はバックアップ設定を実施する。バックアップ設定の手続きでは、管理計算機１０は管理側バックアップ情報１９、管理側カタログ情報１４、管理側拠点カタログ情報を作成する。以下、バックアップ設定中のそれぞれの情報の作成処理について説明する。上記すべての情報の作成は、管理計算機１０が管理プログラム１２に基づいて実行する。

図２１は管理計算機１０によるバックアップで必要な管理側バックアップ情報１９、管理側カタログ情報１４、管理側拠点カタログ情報１４の作成のためのフローである。

はじめに、管理計算機１０は、端末等の入力画面を通して、使用者からバックアップ対象のアプリケーションと、仮想ホスト計算機２００の情報を取得する（ステップ５３００）。入力画面例を図２２に示す。

図２２では、管理計算機１０は、図上部のアプリケーションプログラム一覧から、バックアップ対象の情報として、仮想ホスト計算機がＨｏｓｔ１、アプリケーション名がＤＢを得る。次に、管理計算機１０は、図下部のアプリケーションのデータ情報から、バックアップ対象のデータとしてＩｎｓｔａｎｃｅ１を取得する。図２２の画面で、使用者は一通りの情報入力後、バックアップスケジュール作成ボタンを押下すると、バックアップデータを特定するための画面が現れる。当該画面により、管理計算機１０は、バックアップ対象アプリケーションの保護対象データを取得する。図２３に画面例を示す。具体的に、図２３で、管理計算機は図２２で指定したアプリケーション名ＤＢのバックアップ対象データとして、Ｉｎｓｔａｎｃｅ１のＤＢ１を取得する。

次に、管理計算機１０は、上記バックアップ対象ＡＰ名、データを基に、管理側バックアップ情報１８を作成する（ステップ５３１５）。具体的に、管理計算機１０は、ホストＩＤ１８０２、ＡＰ１８０３、データ１（１８０４）、データ２（１８０５）を上記使用者の入力から得た仮想ホスト計算機名（図２２で取得）、アプリケーション名（図２２で取得）、データ名（図２２で取得）と詳細のデータ名（図２３で取得）をそれぞれ登録し、さらに、管理計算機１０は、あらかじめ定められたユニークなバックアップＩＤ１８０１を作成し、バックアップＩＤ１８０１に登録する。

次に、管理計算機１０は、入力画面を通して、使用者からバックアップスケジュールの情報を取得する。バックアップスケジュールの情報には、即時、スケジュールの選択、スケジュールにはさらに、開始時刻、保護期間、バックアップ間隔がある。図２４に入力画面例を示す。図２４では、管理計算機１０は、バックアップスケジュールとして、開始時刻が１０：１２、保護期間が３日、バックアップ間隔が１日を取得する。さらに管理計算機１０はバックアップ頻度を開始時刻で指定した時刻をスケジュール形態で割ることで算出する。図２４の例では、開始時刻の数（１０：１２の１つ）÷スケジュール形態（日単位）で、１となる。

次に、管理計算機１０は、バックアップ世代数の計算を行う。バックアップ世代数の計算式例を以下に示す。
バックアップ世代数＝バックアップ期間×バックアップ頻度
例えば、図２４の例で世代数はバックアップ期間３日÷バックアップ頻度１日で、１０となる。

次に、管理計算機１０は、レプリケーション構成の構築処理５３３０を行う。

次に、管理計算機１０は活性状態のホスト計算機２００にバックアップ制御指示を発行する（ステップ５３４０）。具体的には、管理計算機１０は、管理側拠点カタログ情報１５、および、管理側バックアップ情報１８を含めたバックアップ制御指示（スケジューラ登録指示）を活性状態のホスト計算機２００に発行する。活性状態のホスト計算機２００は、正側ストレージに接続されるホスト計算機であり、ホスト計算機のクラスタプログラム２１４の状態である。ローカルクラスタの場合は、任意の１ホスト計算機が活性状態となりうるため、ホスト計算機２００のクラスタプログラム２１４の状態を参照し、活性状態のホスト計算機２００を決定する。活性状態のホスト計算機２００の動作については後述する。

次に、図２５を用い、管理計算機１０によるレプリケーション構成の構築処理を説明する。

はじめに、管理計算機１０は管理側クラスタ構成情報１９の仮想ホストＩＤが、ステップ５３００で指定された仮想ホストＩＤに合致する管理側クラスタ構成情報１９の該当行の情報（仮想ホストＩＤ、Ｒｅｍｏｔｅ Ｃｌｕｓｔｅｒ、ホストＩＤの組み合わせ）のＲｅｍｏｔｅ Ｃｌｕｓｔｅｒが“Ｙｅｓ”であるか否かを確認する（ステップ５３３１）。

Ｒｅｍｏｔｅ Ｃｌｕｓｔｅｒが“Ｙｅｓ”の場合（ステップ５３３１Ｙｅｓ）、管理計算機１０はリモートクラスタ向けの設定を行う。すなわち、管理計算機１０はステップ５３００で指定されたホストＩＤ１１４０５、アプリ名を含む管理側ＡＰボリューム対応情報１３を参照する。次に、管理計算機１０は、当該管理側ＡＰボリューム対応情報１３で該当する行情報に含まれるホストＩＤ１３００１、ボリュームＩＤ１３００６が合致する管理側ストレージ情報１１４ＣのストレージサブシステムＩＤ１１４０２、ＨＷボリュームＩＤ１１４０４を検出する。管理計算機１０は、このＨＷボリュームＩＤ１１４０４をリモートクラスタで使用するリモートレプリケーションの正論理ボリュームか、副論理ボリュームのいずれかを設定する（ステップ５３３２）。正論理ボリューム、副論理ボリュームのいずれを設定するかは、例えば、管理計算機１０がランダムに選択しても良いし、事前に決めておいても良いし、後で、使用者に指定されるものでも良い。

次に、管理計算機１０は、ステップ５３３２で決定した当該正論理ボリュームと副論理ボリュームを基に、管理側レプリケーション情報１１３Ｃを作成する。具体的には、管理計算機１０は正論理ボリュームに管理側ストレージ情報から得た情報を、正ストレージシステムＩＤ１１３０４にストレージサブシステムＩＤ１１４０２を、正ＨＷボリュームＩＤ１１３０５に同ＨＷボリュームＩＤ１１４０４を、管理側レプリケーション情報１１３Ｃに登録する。さらに、副論理ボリュームとして管理側ストレージ情報１１４Ｃから得た情報を用い、副ストレージサブシステムＩＤとして、副ストレージシステムＩＤ１１３０６としてストレージサブシステムＩＤ１１４０２を、副ＨＷボリュームＩＤ１１３０７として同ＨＷボリュームＩＤ１１４０４を管理側レプリケーション情報１１３Ｃに登録する。また、管理計算機１０は、管理側レプリケーション情報１１３ＣのレプリケーショングループＩＤ１１３００として他のものと衝突しないレプリケーショングループ名を決定し、レプリケーションオプション情報１１３０１としてリモートレプリケーションを登録する。さらに、管理計算機１０は、管理側カタログ情報１４を作成する。具体的に、管理計算機１０はバックアップＩＤ１４０１に管理側バックアップ情報１８（ステップ５３１５で作成）で登録したバックアップＩＤ１８０１を、Ｒｅｍｏｔｅ Ｃｌｕｓｔｅｒ１４０３には管理側クラスタ構成情報１９の仮想ホストＩＤが使用者の指定した値と合致する行情報のＲｅｍｏｔｅ Ｃｌｕｓｔｅｒ１９００２、ホストＩＤ１ｓｔ１４０５には同行情報の１９００３、ホストＩＤ２ｎｄ１４０５には同行情報の１９００４を登録する。さらに、管理計算機１０は活性ホストＩＤとして、正ストレージサブシステム１０００に接続されるホスト計算機を登録する（ステップ５３３３）。

次に、管理計算機１０は、リモートクラスタの副ストレージサブシステムのバックアップ用のレプリケーション情報１１３Ｃを作成する。すなわち、管理計算機１０は、ステップ５３３３で副論理ボリュームとして設定したＨＷ論理ボリュームをローカルレプリケーションの正論理ボリュームとして設定する。さらに、管理計算機１０は、現状レプリケーションとして使用されていない論理ボリュームＶｏｌを同一ストレージサブシステムＩＤ１１４０２の管理側ストレージ情報から選択し、副論理ボリュームとして設定する。ここで、レプリケーションとして使用されていないボリュームを選択するには、ストレージサブシステム１０００の情報をストレージ制御指示から取得する、あらかじめ使用者が定めた論理ボリュームＶｏｌを使用するといった方法がある。次に、管理計算機１０は、管理側レプリケーション情報１１３ＣのレプリケーショングループＩＤ１１３００として他のものと衝突しないレプリケーショングループ名を決定し、レプリケーションオプション情報１１３０１としてローカルレプリケーションを登録する。ここで、管理計算機１０は管理側レプリケーション情報を図２１で実施したバックアップ世代数（ステップ５３２０）分作成する。次に、管理計算機１０は副ストレージサブシステム向けの管理側拠点カタログ情報１５を作成する。具体的に、管理計算機１０は管理側バックアップ情報として付与したバックアップＩＤ１８０１を１５００１に、ホスト１５００２は正論理ボリュームに設定した論理ボリュームＶｏｌを使用するホスト計算機２００のＩＤ、使用中世代１５００３は初期値を設定し、世代数１５００４はステップ５３２０で計算した結果、世代１グループ１５００５、世代２グループ１５００７、世代１グループ１５００９には上記のリモートクラスタの副ストレージサブシステム向けに作成したレプリケーション情報１１３Ｃに登録したレプリケーショングループＩＤ１１３００を登録する（ステップ５３３４）。

次に、ステップ５３３１でＲｅｍｏｔｅ Ｃｌｕｓｔｅｒが“Ｎｏ”の場合、もしくは、ステップ５３３４の次の処理として、管理計算機１０はローカルクラスタ、リモートクラスタ向け、正ストレージサブシステムのバックアップ用レプリケーション情報１１３Ｃを作成する。すなわち、管理計算機１０は、ステップ５３３３で正論理ボリュームとして設定したＨＷ論理ボリュームをローカルレプリケーションの正論理ボリュームに設定する。さらに、管理計算機１０は、現状レプリケーションとして使用されていない論理ボリュームＶｏｌを同一ストレージサブシステムＩＤ１１４０２の管理側ストレージ情報から選択し、副論理ボリュームとして設定する。次に、管理計算機１０は、管理側レプリケーション情報１１３ＣのレプリケーショングループＩＤ１１３００として他のものと衝突しないレプリケーショングループ名を決定し、レプリケーションオプション情報１１３０１としてローカルレプリケーションを登録する。ここで、管理計算機１０は管理側レプリケーション情報を図２１で実施したバックアップ世代（ステップ５３２０）分作成する。次に、管理計算機１０は正ストレージサブシステム向けの管理側拠点カタログ情報１５を作成する。具体的に、管理計算機１０は管理側バックアップ情報として付与したバックアップＩＤ１８０１を１５００１に、ホスト１５００２は正論理ボリュームに設定した論理ボリュームを使用するホスト計算機２００のＩＤ、使用中世代１５００３は初期値を設定し、世代数１５００４はステップ５３２０で計算した結果、世代１グループ１５００５、世代２グループ１５００７、世代１グループ１５００９には上記のリモートクラスタの副ストレージサブシステム向けに作成したレプリケーション情報１１３Ｃに登録したレプリケーショングループＩＤ１１３００を登録する（ステップ５３３５）。

最後に管理計算機１０は上記ステップで作成した管理側レプリケーション情報からストレージ制御指示（レプリケーション構築）を作成し、ストレージサブシステム１０００に発行する（ステップ５３３６）。ストレージサブシステム１０００は当該ストレージ制御指示に従い、レプリケーションを構築する。

（１−５）実施例１の計算機システムにおける通常動作
（１−５−１）バックアップ処理
管理計算機１０がバックアップ設定のための処理（図２１）を完了すると、活性状態のホスト計算機２００で、バックアップ処理が開始になる。当該作成は、ホスト計算機２００がバックアッププログラム２１３に基づいて実行する。

図２６は管理計算機１０によるバックアップ処理のためのフローである。

はじめに、ホスト計算機２００は管理計算機１０からのバックアップ制御指示を受信（ステップ５４００）すると、バックアップ制御指示の内容を解析し、当該指示の中に含まれる管理側バックアップ情報１８と、管理側拠点カタログ情報１５を取り出し、当該計算機内のメモリ２１０に格納する。図では、管理計算機２０条の情報と区別するため、ホスト計算機２００上に配置される上記情報をそれぞれ、管理側バックアップ情報１８Ｌ、管理側拠点カタログ情報１５Ｌと表記する。

次に、ホスト計算機２００は、当該管理側バックアップ情報１８と、管理側拠点カタログ情報１５を読み出し、バックアップ対象アプリとそのデータ、バックアップ開始時刻、バックアップで使用するレプリケーショングループを特定する。次に、ホスト計算機２００は、当該計算機上のスケジューラ２１７に、アプリケーションのデータに対するバックアップ実行指示が開始時刻に実行されるよう登録する（ステップ５４１０）。

次に、ホスト計算機２００はスケジューラを監視し、バックアップ実行指示が完了するのを待つ（ステップ５４２０）。バックアップ実行指示が実施されると、ホスト計算機２００は、当該計算機上で動作するＡＰ２１１を静止化する。ＡＰの静止化とは、当該ＡＰを一時的に停止させ、ＡＰやＯＳに存在する当該ＡＰのデータの一時データを、すべてストレージサブシステムに書き出すことで、当該データを回復可能な状態にする手続きである。ＡＰの静止化後、ホスト計算機２００は、該当するＡＰのデータのバックアップをレプリケーションで保管するため、ストレージ制御指示（レプリケーション一時停止）を発行する。ストレージサブシステム１０００は当該指示を受け取ると、指定されたレプリケーショングループに含まれるレプリケーションペアのコピーを停止する。

バックアップ実行指示が完了した場合（５４２０Ｙｅｓ）、ホスト計算機２００は次に実行実施すべきバックアップの時刻を計算する。具体的に、ホスト計算機２００は、バックアップが完了した時刻にバックアップ間隔を加算することで算出する。次に、ホスト計算機２００は、バックアップ開始時刻を変更したバックアップ指示をスケジューラ２１７に登録するために、ステップ５４１０に遷移する（ステップ５４３０）。

（１−５−２）リストア処理
リストア処理は、管理計算機１０がバックアップ済みデータを回復するための処理である。当該リストア処理は、管理計算機１０が管理プログラム１２に、ホスト計算機２００がバックアッププログラム２１３に基づいて実行される。

図２７は管理計算機１０によるリストア処理のためのフローである。

はじめに、端末等の入力画面を通して、使用者がリストアを実施する場合、管理計算機１０は、活性状態のホスト計算機２００にバックアップ制御指示（バックアップ状態報告）を発行する（ステップ５５００）。バックアップ状態報告は物理計算機が管理する管理側拠点カタログ情報を取得することが出来る。

ホスト計算機２００は、当該バックアップ状態制御指示を受信すると、その内容を解析し、指示内容がバックアップ状態報告であることが判明すると、自計算機２００が管理する管理側拠点カタログ情報１５Ｌを応答に含めて、返信する（ステップ５５０５）。

次に、管理計算機１０は、当該情報の内容を、入力画面を通し出力し、使用者からリストアすべきアプリケーションのデータを取得する。次に、管理計算機１０は、活性状態のホスト計算機にバックアップ制御指示（リストア指示）を発行する（ステップ５５１０）。ここで、リストア処理の入力画面例を図２８に示す。

図２８で、管理計算機１０は、図上部のアプリケーションプログラム一覧から、リストア対象の情報として、仮想ホスト計算機がＨｏｓｔ１、アプリケーション名がＤＢを得る。次に、管理計算機１０は、図下部のアプリケーションのデータ情報から、リストア対象のデータとしてＩｎｓｔａｎｃｅ１を取得する。図２８の画面で、使用者は一通りの情報入力後、リストアボタンを押下すると、リストアデータを特定するための画面が現れる。当該画面により、管理計算機１０は、リストア対象データを回復するためのすべて情報を得る。図２９に画面例を示す。

具体的に、図２９で、管理計算機は図２８で指定したアプリケーション名ＤＢのリストア対象のデータとして、Ｉｎｓｔａｎｃｅ１のＤＢ１とそのバックアップ時間（２００９−０８−１２ １１：１２：２０）を取得する。取得後、管理計算機１０は当該情報を基にバックアップ制御指示（リストア指示）を活性状態のホスト計算機２００に発行する。複数あるホスト計算機の中から活性状態のものを特定するため、管理計算機１０は、管理側カタログ情報１４の活性ホストＩＤを参照する。

ホスト計算機２００は、当該バックアップ制御指示を受信すると、当該制御指示を解析し、当該制御指示がバックアップデータのリストア処理を開始する（ステップ５５２０）。

次に、ホスト計算機２００は、ＡＰ２１１を停止させる。ＡＰ２１１の停止には例えば、ＡＰ専用の操作インターフェースや、ＡＰ２１１専用の制御コマンドを使用する（ステップ５５３０）。

次に、ホスト計算機２００は、レプリケーション操作を行うために、活性ホスト計算機のホストＩＤを持つ管理側拠点カタログ情報を参照し、リストアの入力画面で指定された世代のレプリケーショングループＩＤを特定し、当該レプリケーショングループＩＤを指定してストレージ制御指示（レプリケーション一時停止指示）を当該レプリケーショングループに記載されるストレージサブシステム１０００に発行する（ステップ５５４０）。すると、ストレージサブシステム１０００は当該指示に従ってレプリケーション制御を実施する。具体的には、アプリケーションが使用する正論理ボリュームに副論理ボリュームの内容を上書きする。

次に、ホスト計算機２００は、ＡＰ２１１を起動する。ＡＰ２１１が動作するとホスト計算機２００はリストアしたデータを参照し、ＡＰ２１１のための処理を継続する。次にホスト計算機２００は、ＡＰリストアが完了したことをバックアップ制御指示の応答で管理計算機１０に返送する（ステップ５５５０）。

管理計算機１０は、バックアップ制御指示の応答を受信すると、リストアが成功したか否かを当該応答から判定する（ステップ５５６０）。

当該応答がリストア成功の場合（ステップ５５６０Ｙｅｓ）、管理計算機１０はリストアが成功したことを使用者に通知する（ステップ５５７０）。

一方、当該応答がリストア失敗の場合（ステップ５５６０Ｎｏ）、管理計算機１０はリストアが失敗したことを使用者に通知する（ステップ５５７０）。使用者は再度リストア可能なデータを見つけるべくステップ５５００からやり直す。

（１−６）実施例１のリモートクラスタを適用した計算機システムの障害時の動作
障害時の動作はローカルクラスタとリモートクラスタで異なる。ここでは、リモートクラスタの障害発生後の動作について説明する。

（１−６−１）活性状態のホスト計算機障害後のバックアップ処理
はじめに、活性状態のホスト計算機障害後のバックアップ処理について説明する。以後、上記障害が発生したホスト計算機を障害ホストとよぶ。当該処理は、ホスト計算機２００がクラスタプログラム２１４に基づいて実行する。

図３０は非活性状態のホスト計算機２００による障害ホスト２００ａが障害になった後にバックアップ処理を引き継ぐためのフローである。

ホスト計算機２００の障害を検出するため、クラスタシステム上の複数のホスト計算機２００は自計算機とは異なる障害監視対象のホスト計算機が動作しているかを定期的に調査する（ステップ５６００）。これは、ホスト計算機２００が制御線５５を介して別ホスト計算機２００と簡単な情報を通信することで実現する。

ここで、活性状態のホスト計算機２００ａが障害になると、その障害を検出した非活性状態のホスト計算機２００が当該活性状態のホスト計算機（障害ホスト）の処理を引き継ぐ、フェールオーバ処理を実施する（ステップ５６００Ｎｏ）。具体的に、当該非活性状態のホスト計算機２００ｂ（以下、新活性ホストとよぶ）は以下の手続きを実施する。

はじめに、新活性ホスト２００ｂは、自新活性ホスト２００ｂがアクセスする論理ボリュームＶｏｌを使用可能にするため、レプリケーション操作を行う。具体的には、ストレージサブシステム１０００間で実施するリモートレプリケーションの方向を変更する必要があり、新活性ホスト２００ｂは、ストレージ制御指示（レプリケーションリバース指示）を副ストレージサブシステム１０００ｂに発行する（ステップ５６１０）。副ストレージサブシステム１０００ｂは少なくとも自ストレージサブシステム１０００ｂが処理中のリモートレプリケーションを一時停止させ、副論理ボリュームであった論理ボリュームを正論理ボリュームに変更する。さらに、可能であれば副ストレージサブシステム１０００ｂは当該リモートレプリケーションのレプリケーション方向を逆向きにする処理を実施する。レプリケーション方向を逆向きにする処理は、副ストレージサブシステム１０００ｂが正ストレージサブシステム１０００ａと通信し、両者のレプリケーション処理の継続が可能な場合、両ストレージサブシステム１０００が連携し、レプリケーションの方向を逆転させる。結果として、上記リモートレプリケーションの状態は逆方向にレプリケーションを実施するコピー中状態か、異常状態のいずれかになる。

次に、新活性ホスト２００ｂは、クライアント計算機に見せるネットワークアドレスを障害ホスト２００ａが使用していたアドレスに変更する（ステップ５６２０）。

次に、新活性ホスト２００ｂは、自新活性ホスト２００ｂ上のＡＰ２１６を起動する。

次に、新活性ホスト２００ｂは、自新活性ホスト２００ｂ上のバックアッププログラム２１３を起動する。バックアッププログラム２１３が起動すると新活性ホスト２００ｂは、メモリ上に配置された、管理側拠点カタログ情報１５Ｌおよび管理側バックアップ情報１８Ｌを参照し、バックアップ処理を開始する。ここで、新活性ホスト２００ｂのバックアップ処理は、障害ホスト２００ａで実施していたバックアップ処理を引き継ぐため、障害ホスト２００ａが、スケジューラに登録していたバックアップ実行指示が新活性ホスト２００ｂのバックアップ実行指示になるように変更する。

（１−６−２）フェールオーバ後のリストア処理
フェールオーバ後のリストア処理について説明する。当該処理は、ホスト計算機２００がクラスタプログラム２１４に基づいて実行する。

リストア処理は、管理計算機１０がバックアップ済みデータを回復するための処理である。当該リストア処理は、管理計算機１０が管理プログラム１２に、ホスト計算機２００がバックアッププログラム２１３に基づいて実行される。

フェールオーバ後のリストア処理は、基本的に通常状態のリストア処理と同様の処理になる。ただし、障害ホスト２００ａが障害前に取得していたバックアップデータをリストア可能にするための処理５５９０Ｆ、処理５５４０Ｆが追加になる。

図３１は、フェールオーバ後のリストア処理であり、通常状態のリストア処理に比べ変更が生ずる。以下、変更を図３２、図３３を用いて説明する。

図３２は障害ホスト２００ａがフェールオーバ前に正ストレージサブシステム１０００ａにバックアップしたデータをリストア対象のデータとして使用するか否かを判定するためのフローで、図３１の５５９０Ｆの処理である。

はじめに、管理計算機１０はストレージサブシステム間に構築されたリモートレプリケーションの状態を取得するために、ストレージ制御指示（レプリケーション状態報告）を副ストレージサブシステム１０００ｂに発行する（ステップ５５９１）。

当該制御指示を受信した副ストレージサブシステム１０００ｂは、指示内容を解析し、ストレージ側レプリケーションペア管理情報１２１０を参照し当該情報上のレプリ状態情報１２１０３を読み出し、その状態情報を当該制御指示の応答として管理計算機１０に返信する（ステップ５９９２）。

管理計算機１０は当該制御指示の応答を受信すると、リモートレプリケーションが異常状態の場合（ステップ５５９３Ｎｏ）、障害ホスト２００の障害だけでなく、正ストレージサブシステム１０００ａも障害が発生していると判定する。具体的には、管理計算機１０は、当該正ストレージサブシステム２００ａにバックアップされたデータをリストア対象として使用せず、フェールオーバ後に新活性ホスト２００ｂが取得したバックアップのみをリカバリ対象とするために、新活性ホスト２００ｂが管理している管理側バックアップ情報１８のみを参照する（ステップ５５９５）。

一方で、リモートレプリケーションが異常状態ではない場合（ステップ５５９３Ｙｅｓ）、フェールオーバ後も正ストレージサブシステム１０００ａは稼働しているものとして、管理計算機１０が定期的に障害ホスト２００ａから取得していた、障害ホスト２００ａ上の管理側拠点カタログ情報（以後、新活性ホストが管理する管理側拠点カタログ情報と区別するため、当該管理側拠点カタログ情報を残存拠点カタログ情報とよぶことにする）も、リストア対象にする（ステップ５５９４）。そのため、図２８に示すリストア画面ではリストア候補が障害ホスト２００ａがフェールオーバ前に取得したバックアップのデータ分、増加する。ここで、ステップ５５９４の処理は、管理計算機１０が障害前後によらず、定期的に対象のホスト計算機から管理側拠点カタログ情報を取得していることを前提としている。この情報が古い場合、リストア不可能なデータが当該管理側拠点カタログ情報に記載される場合があるため、物理サーバへの情報取得間隔はスケジュールされたバックアップ処理間隔よりも十分に短いものとする。

図３１のステップ５５１０Ｆの処理は、図２７で示した通常時のリストア処理と例外ケースをのぞき同一の処理である。例外ケースとはすなわち、使用者が障害ホストのバックアップデータをリストア対象として選択可能になる場合で、この場合、管理計算機１０は、新活性ホスト計算機にバックアップ制御指示（複合リストア）を発行する。複合リストア処理とは、リストア対象のデータを得るために、リモートレプリケーションとローカルレプリケーションを組み合わせる処理である。そのために、複合リストア指示にはリストア対象のデータの情報に加え、正副ストレージサブシステム１０００間に構築中のリモートレプリケーションの情報も含める。

図３３は障害ホスト２００ａがフェールオーバ前に取得したデータをリストアする可能性がある場合の、リストア処理のためのレプリケーション制御処理フローで、図３１の５５４０Ｆの処理である。

はじめに、新活性ホスト２００ｂは、管理計算機１０から受信したバックアップ制御指示に記載されるリストア対象が障害になったホスト計算機２００ａのデータか否かを判定する（ステップ５５４１）。

当該リストア対象が障害ホスト２００ａのデータでない場合（ステップ５５４１Ｎｏ）、ステップ５５４０で示したレプリケーション操作を行う（ステップ５５４３）。

一方、当該リストア対象が障害ホスト２００ａのバックアップデータの場合（ステップ５５４１Ｙｅｓ）、新活性ホスト２００ｂは障害ホスト２００ａに接続される正ストレージサブシステム１０００ａに格納されたバックアップデータを副ストレージサブシステム１０００ｂに転送するためのレプリケーション操作を行う。具体的に、新活性ホスト２００ｂは、バックアップ制御指示のリストア指示に含まれるリストア対象のバックアップデータが保存されたレプリケーションのグループと、バックアップ制御指示に含まれるリモートレプリケーションのグループの両方を連続して制御する。図３４は障害発生後に障害ホスト２００ａの作成したデータをレプリケーションの処理に関する説明図である。

図３４で、新活性ホスト２００ｂは、ストレージサブシステム１０００内のレプリケーション（１）を逆向きにする。つぎに、新活性時ホスト２００は、リモートレプリケーション（２）を逆向きにする。この２つの手続きにより、たとえ障害がホスト計算機で発生した後でも、当該データを含めた形でリストア対象にすることが出来る。

障害ホストのホストＩＤを持つ管理側拠点カタログ情報を参照し、当該レプリケーショングループＩＤを指定してストレージ制御指示（レプリケーション一時停止指示）を当該レプリケーショングループに記載されるストレージサブシステム１０００に発行する。すると、ストレージサブシステム１０００は当該指示に従ってレプリケーション制御を実施する。具体的には、障害ホスト２００が使用する正論理ボリュームに副論理ボリュームの内容を上書きする。

（１−７）本実施例１のローカルクラスタを適用した計算機システムの障害時動作
障害時の動作はローカルクラスタとリモートクラスタで異なる。ここでは、ローカルクラスタの障害後の動作について説明する。

（１−７−１）ホスト計算機障害後のバックアップ処理
はじめに、ローカルクラスタはストレージサブシステム１０００が複数存在しないため、リモートレプリケーションの制御が必要でなくなる。従って、図３０のステップ５６１０が存在しないことがリモートクラスタしすてむにおけるバックアップ処理と大きく異なる。

また、ホスト計算機２００間で同一ストレージサブシステム１００００、論理ボリュームＶｏｌを使用するため、バックアップで必要となる管理側拠点カタログ情報、管理側カタログ情報をホスト計算機２００間で共有する。そのため、ホスト計算機２００が共有するストレージサブシステム１０００上のデータ同様に、当該バックアップ情報をデータ同様にストレージサブシステム上に配置する。そのため、ホスト計算機２００ａに障害が発生し、別のホスト計算機２００ｂにフェールオーバしても、新活性ホスト２００はストレージサブシステムからバックアップ情報を読み込むのみで、バックアップ情報に障害ホスト２００のバックアップ内容と変化が無く、使用者が使用するする画面も変化が生じない。
（１−７−２）ホスト計算機障害後のリストア処理
ローカルクラスタシステムにおけるリストア処理は、リモートクラスタシステムと比較すると、リモートレプリケーションの制御のための処理が存在しないことが相違となる。ローカルクラスタシステムにおけるリストア処理では、リモートクラスタシステムの場合とは異なり、障害ホスト２００がバックアップしていたデータはストレージサブシステムが故障しない限り同一バックアップデータをリストア対象データとして利用できる。

（１−８）ストレージサブシステムのレプリケーション処理
ストレージサブシステムにおけるレプリケーション処理は２つの期間に分類される。初期コピーと定常コピーである。初期コピーはレプリケーションの開始処理で、レプリケーション元の論理ボリュームＶｏｌの内容をレプリケーション先に複製する処理である。定常コピーは初期コピー終了後のレプリケーション処理である。

（１−８−１）ストレージサブシステムによる初期コピー処理
次に、ストレージサブシステム１０００による、リモートレプリケーションの開始処理について説明する。

図３５は実施例１における正副ストレージサブシステム１０００によって実行されるレプリケーションの開始処理（以後、初期コピー処理とよぶ）のフローチャートを示す図である。

（ステップ８０１０）正ストレージサブシステム１０００ａは、ストレージ制御指示（レプリケーション構築指示）を受信し、当該指示から抽出した情報に基づいて、ストレージ側レプリケーションペア管理情報１２１０を作成する。具体的には、正ストレージサブシステム１０００ａは、レプリケーション構築指示にて指定された正論理ボリュームのＩＤをコピー元の正論理ボリュームとしてストレージ側レプリケーションペア管理情報１２１０の論理ボリュームＩＤ１２１０１に格納する。次に、正ストレージサブシステム１０００ａは、初期コピー中を、ストレージ側レプリケーションペア管理情報１２１０のレプリケーション状態情報１２１０２に格納する。さらに、正ストレージサブシステム１０００ａは、当該要求に含まれるレプリケーションペアのＩＤをレプリケーションペアＩＤ１２１００に格納し、当該要求に含まれるコピーグループＩＤコピーグループＩＤ１２１００に格納し、当該要求に含まれるコピー種別を、ストレージ側レプリケーションペア管理情報１２１０のコピー種別１２１０６に格納する。

（ステップ８０２０）ストレージサブシステム１０００ａは、リモートレプリケーション開始相手となるストレージサブシステム１０００ｂへレプリケーションン構築指示に含まれる情報に対応する情報を含むストレージ間レプリケーションペア開始要求を作成する。

なお、ストレージ間レプリケーションペア開始要求に含まれる情報を以下に示す。
（１）開始対象のレプリケーションペアの正ストレージサブシステムのＩＤと正論理ボリュームのＩＤ。
（２）開始対象のレプリケーションペアの副ストレージサブシステムのＩＤと副論理ボリュームのＩＤ。
（３）開始対象のレプリケーションペアのコピー種別。
（４）開始対象のレプリケーションペアのＩＤ。
（５）開始対象のレプリケーションペアが含まれるコピーグループのＩＤ。

（ステップ８０４０）当該要求を受信した副ストレージサブシステム１０００ｂはストレージ側レプリケーション管理情報１２１０ｂの生成または更新のため、当該要求に対応する処理として８０１０を行う。

（ステップ８０５０）次に、正ストレージサブシステム１０００ａは、正論理ボリュームが格納するデータを副ストレージサブシステムの副論理ボリュームにコピーする初期コピーを開始する。

なお、初期コピー中の正ストレージサブシステム３００は、ストレージ側レプリケーションペア管理情報１２１０Ａの論理ボリュームＩＤ１２１０２によって識別される正論理ボリュームからデータを読み出し、読み出し元の正論理ボリュームのＩＤ（または対応する副論理ボリュームのＩＤ）と正論理ボリュームのアドレス（または対応する副論理ボリュームのアドレス）と読み出したデータを含む初期コピー要求を作成し、副ストレージサブシステム１０００ｂへ送信する。

初期コピー要求を作成した副ストレージサブシステム１０００ｂは当該リクエストが特定した副論理ボリュームと副論理ボリュームのアドレスに対して正論理ボリュームから読み出したデータを書き込む。

（１−８−２）ストレージサブシステムによる定常コピー処理
正副ストレージサブシステム１０００は、初期コピー処理が終了すると、リモートコピーの継続処理（以後、定常コピーとよぶ）の運用を開始する。つまり、正副ストレージサブシステム１０００は、正論理ボリュームのデータと副論理ボリュームのデータとが一致してから、定常コピーの運用を開始する。

具体的には、正ストレージサブシステム１０００ａは、初期コピー処理を終了してから書き込み要求を受信すると、定常コピー処理を実行する。例えば、正ストレージサブシステム１０００ａは、正論理ボリュームにデータを書き込むと、当該書き込みデータを副論理ボリュームにも書き込む。

図３６は、本発明の実施例１のストレージサブシステム１０００によって実行される定常コピー処理の一例を示すフローチャートである。なお、定常コピーは図２７以外の処理によって実現してもよい。

正ストレージサブシステム１０００ａは、ホスト計算機２００からＩＯを受信する。当該ＩＯは、書き込み要求である。次に、正ストレージサブシステム１０００ａは、ＩＯ要求から、書き込みが要求されるデータ（書き込みデータ）を抽出する。次に、正ストレージサブシステム１０００ａは、ＩＯ要求から、ストレージＩＤ及びボリュームＩＤを抽出する。

次に、正ストレージサブシステム１０００ａは、抽出した書き込みデータを、取得した論理ボリュームＩＤによって識別される論理ボリュームＶｏｌに書き込む。

（ステップ８２５０）次に、正ストレージサブシステム１０００ａは、図３７に示すデータ転送要求を作成する。

具体的には、コピー元の正ストレージサブシステム１０００ａは、取得した論理ボリュームＩＤとレプリケーションペア管理情報１２１０Ａの論理ボリュームＩＤ１２１０１とが一致するレプリケーションペア管理情報１２１０を選択する。次に、レプリケーション元の正ストレージサブシステム１０００ａは、選択したレプリケーションペア管理情報１２１０Ａから、レプリケーション対象ストレージＩＤ１２１０４及びレプリケーション対象ボリュームＩＤ１２１０５を抽出する。

次に、正ストレージサブシステム１０００ａは、抽出したレプリケーション対象ボリュームＩＤ１２１０５を、データ転送要求の論理ボリュームＩＤに格納する。次に、正ストレージサブシステム１０００ａは、書き込みデータを格納したブロックのアドレスを、データ転送要求のブロックアドレスに格納する。

次に、正ストレージサブシステム１０００ａは、書き込みデータの大きさを、データ転送要求の書き込みデータ長に格納する。次に、正ストレージサブシステム１０００ａは、書き込みデータの一部又は全部を、データ転送要求の転送データに格納する。

次に、正ストレージサブシステム１０００ａは、定常コピーにおいて当該転送要求を作成した順番を、データ転送要求の通し番号１８４０５に格納する。次に、正ストレージサブシステム１０００ａは、抽出したレプリケーション対象ストレージＩＤを、データ転送要求１８４０の転送先ストレージＩＤ１８４０６に格納する。

（ステップ８２６０）次に、正ストレージサブシステム１０００ａは、作成したデータ転送要求１８４０を、副ストレージサブシステム１０００ｂに送信する。

（ステップ８２７０）副ストレージサブシステム１０００ｂは、データ転送要求１８４０を受信する。すると、副ストレージサブシステム１０００ｂは、データ転送要求１８４０の論理ボリュームＩＤ１８４０１によって識別される論理ボリュームＶｏｌに、データ転送要求１８４０の転送データ２３Ｄを書き込む。

そして、ストレージサブシステム１０００は、一つのＩＯ要求に対応する定常コピーの処理を終了する。

以上の説明によって、複数の論理ボリュームを提供し、一つ以上の装置から構成されるストレージシステムと、複数の計算機と、を管理し、前記複数のホスト計算機と接続するポートと、クラスタ情報を格納するメモリと、前記複数の計算機同士で発生したフェールオーバを検知して前記クラスタ情報を更新するプロセッサと、入力用の仮想ホスト識別子と、入力用のアプリケーションインスタンス識別子と、バックアップスケジュール入力値と、を含むバックアップ設定要求を受信する、入出力装置と、を有する管理システムについて説明した。

なお、前記プロセッサは、
（Ａ）前記クラスタ情報を参照することで、前記複数のホスト計算機に含まれ、前記入力用の仮想ホスト識別子に対応する活性状態の計算機と、前記活性状態のホスト計算機に対応する非活性状態のホスト計算機とを特定し、
（Ｂ）前記入力用のアプリケーションインスタンス識別子にて識別されるアプリケーションプログラムを実行することで前記活性状態のホスト計算機がアクセスする、前記ストレージシステムに含まれる第一のストレージサブシステムと前記第一のストレージサブシステムが提供する第一の論理ボリュームとを特定し、
（Ｃ）前記非活性状態のホスト計算機が前記第一のストレージサブシステム及び前記第一の論理ボリュームにアクセス可能か判断し、
（Ｄ）前記非活性状態のホスト計算機が前記第一の論理ボリュームにアクセス可能でない場合、前記非活性状態のホスト計算機からアクセス可能な前記ストレージシステムに含まれる第二のストレージサブシステムを選択し、前記第一の論理ボリュームをコピー元として前記第二のストレージサブシステムが提供する第二の論理ボリュームをコピー先とするディザスタリカバリ用途のレプリケーション構築指示を前記第一のストレージシステムへ送信し、
（Ｅ）前記ポートを介して、前記バックアップスケジュール入力値に基づき作成したバックアップスケジュール指示情報を含むバックアップスケジュール登録指示を活性状態のホスト計算機計算機に送信することで、前記バックアップスケジュール入力値に従った前記第一の論理ボリュームをコピー元とし、前記第一のストレージサブシステムが含む一つ以上の第三の論理ボリュームをコピー先とする、バックアップ用レプリケーション処理の制御を前記活性状態のホスト計算機に行わせる、
ことについても説明した。

なお、前記プロセッサは、
（Ｆ）前記活性状態のホスト計算機からレプリケーション処理の情報を取得することで、前記バックアップスケジュール入力値に従って作成されたバックアップデータの生成時間、及び前記バックアップデータを格納する前記一つ以上の第三の論理ボリュームの識別子を、管理用カタログ情報として前記メモリに格納し、
（Ｇ）前記管理用カタログ情報を参照することで、前記入力用仮想ホスト識別子及び前記入力用アプリケーションインスタンス識別子で指定された前記アプリケーションプログラムに対応するバックアップデータの生成時間を一つ以上、前記入出力装置に表示させてもよいことも説明した。

また、前記不活性状態のホスト計算機が、フェールオーバによって前記活性状態のホスト計算機から前記アプリケーションプログラムの処理を引き継ぐことで次の活性状態のホスト計算機となった場合、前記プロセッサは、
（Ｈ）前記次の活性状態のホスト計算機が前記活性状態のホスト計算機から引き継いだ、前記バックアップスケジュール入力値に基くバックアップ用レプリケーション処理の制御の次の情報を取得し、
（Ｉ）前記次の情報に従って、活性状態のホスト計算機が制御することで生成した次のバックアップデータの生成時間、及び前記バックアップデータを格納する前記一つ以上の第三の論理ボリュームの識別子を、前記カタログ情報として前記メモリに格納し、
（Ｊ）前記管理用カタログ情報を参照することで、前記アプリケーションプログラムに対応するバックアップデータの生成時間として、前記次のバックアップデータの生成時間を前記入出力装置へ表示させてもよいことも説明した。

また、前記入力装置は、前記入力用の仮想ホスト識別子及び前記入力用のアプリケーションインスタンス識別子と、前記バックアップデータの生成時間表示に基いて入力された所定のバックアップデータを指定したリストア指示を受信し、前記プロセッサは、前記リストア指示で指定されたバックアップデータを格納する前記第三の論理ボリュームの一つを特定し、前記特定された第三の論理ボリュームの一つを指定したリストア指示を前記活性状態のホスト計算機へ送信することで、前記ストレージシステムに、前記第三の論理ボリュームの一つに格納されたバックアップデータを前記第一の論理ボリュームへ戻させてもよいことも説明した。

また、前記不活性状態のホスト計算機が、フェールオーバによって前記活性状態のホスト計算機から前記アプリケーションプログラムの処理を引き継ぐことで次の活性状態のホスト計算機となった場合、前記プロセッサは、
（Ｈ）前記次の活性状態のホスト計算機が前記活性状態のホスト計算機から引き継いだ、前記バックアップスケジュール入力値に基くバックアップ用レプリケーション処理の制御の次の情報を取得し、
（Ｉ）前記次の情報に従って、活性状態のホスト計算機が制御することで生成した次のバックアップデータの生成時間、及び前記バックアップデータを格納する前記一つ以上の第三の論理ボリュームの識別子を、前記カタログ情報として前記メモリに格納し、
（Ｊ）前記管理用カタログ情報を参照することで、前記アプリケーションプログラムに対応するバックアップデータの生成時間として、前記次のバックアップデータの生成時間を前記入出力装置へ表示させても良いことも説明した。

また、前記不活性状態のホスト計算機が、前記第一のストレージサブシステムへアクセス可能でなく、フェールオーバによって前記活性状態のホスト計算機から前記アプリケーションプログラムの処理を引き継ぐことで次の活性状態のホスト計算機となった場合、前記プロセッサは、
（Ｋ）前記バックアップスケジュール入力値に基いた前記第二の論理ボリュームをコピー元として前記第二のストレージサブシステムが提供する一つ以上の第四の論理ボリュームをコピー先とする、次のバックアップ用レプリケーション処理の制御の次の情報を取得し、
（Ｌ）前記次の情報に従って、活性状態のホスト計算機が制御することで生成した次のバックアップデータの生成時間、及び前記バックアップデータを格納する前記一つ以上の第三の論理ボリュームの識別子を、前記カタログ情報として前記メモリに格納し、
（Ｍ）前記管理用カタログ情報を参照することで、前記アプリケーションプログラムに対応するバックアップデータの生成時間として、前記第四の論理ボリュームに格納された前記次のバックアップデータの生成時間を前記入出力装置に表示し、前記第三の論理ボリュームに格納された前記バックアップデータの生成時間の表示を抑止してもよいことも説明した。

１０…管理計算機 ２０…プロセッサ ３０…管理ポート ４０…メモリ ２００…ホスト計算機 ２５０…クライアント計算機 １０００…ストレージサブシステム

Claims (5)

1. 複数の論理ボリュームを提供し、一つ以上の装置から構成されるストレージシステムと、複数の計算機と、を管理する管理システムであって、
   前記管理システムは、
   前記複数のホスト計算機と接続するポートと、
   クラスタ情報を格納するメモリと、
   前記複数の計算機同士で発生したフェールオーバを検知して前記クラスタ情報を更新するプロセッサと、
   入力用の仮想ホスト識別子と、入力用のアプリケーションインスタンス識別子と、バックアップスケジュール入力値と、を含むバックアップ設定要求を受信する、入出力装置と、
   を有し、
   前記プロセッサは、
   前記入出力装置より、前記仮想ホスト識別子とともに前記複数のホスト計算機のうちの第１ホスト計算機及び第２ホスト計算機を指定してクラスタの設定を受け付けると、
   前記第１ホスト計算機及び第２ホスト計算機より、前記ストレージシステムからそれぞれのホスト計算機に提供されている論理ボリュームの情報を取得し、
   前記第１ホスト計算機及び第２ホスト計算機に提供されている論理ボリュームの情報を比較することにより、前記設定するクラスタの種別を判断し、
   前記仮想ホスト識別子と、前記第１ホスト計算機及び第２ホスト計算機とを対応づけて、前記クラスタの種別とともに前記クラスタ情報に格納し、
   前記入出力装置より前記バックアップ設定要求を受け付けると、
   （Ａ）前記クラスタ情報を参照して、前記複数のホスト計算機に含まれ、前記入力用の仮想ホスト識別子に対応する活性状態のホスト計算機と、前記活性状態のホスト計算機に対応する非活性状態のホスト計算機とを特定し、
   （Ｂ）前記入力用のアプリケーションインスタンス識別子にて識別されるアプリケーションプログラムを実行することで前記活性状態のホスト計算機がアクセスする、前記ストレージシステムに含まれる第一のストレージサブシステムと前記第一のストレージサブシステムが提供する第一の論理ボリュームとを特定し、
   （Ｃ）前記クラスタ情報を参照して、前記活性状態のホスト計算機と前記非活性状態のホスト計算機とが構成するクラスタの種別に基づき、前記非活性状態のホスト計算機が前記第一のストレージサブシステム及び前記第一の論理ボリュームにアクセス可能か判断し、
   （Ｄ）前記非活性状態のホスト計算機が前記第一の論理ボリュームにアクセス可能でない場合、前記非活性状態のホスト計算機からアクセス可能な前記ストレージシステムに含まれる第二のストレージサブシステムを選択し、前記第一の論理ボリュームをコピー元として前記第二のストレージサブシステムが提供する第二の論理ボリュームをコピー先とするディザスタリカバリ用途のレプリケーション構築指示を前記第一のストレージシステムへ送信し、
   （Ｅ）前記ポートを介して、前記バックアップスケジュール入力値に基づき作成したバックアップスケジュール指示情報を含むバックアップスケジュール登録指示を活性状態のホスト計算機に送信することで、前記バックアップスケジュール入力値に従った前記第一の論理ボリュームをコピー元とし、前記第一のストレージサブシステムが含む一つ以上の第三の論理ボリュームをコピー先とする、バックアップ用レプリケーション処理の制御を前記活性状態のホスト計算機に行わせる、
   ことを特徴とした管理システム。
2. 請求項１記載の管理システムであって、
   前記プロセッサは、
   （Ｆ）前記活性状態のホスト計算機からレプリケーション処理の情報を取得することで、前記バックアップスケジュール入力値に従って作成されたバックアップデータの生成時間、及び前記バックアップデータを格納する前記一つ以上の第三の論理ボリュームの識別子を、管理用カタログ情報として前記メモリに格納し、
   （Ｇ）前記管理用カタログ情報を参照することで、前記入力用仮想ホスト識別子及び前記入力用アプリケーションインスタンス識別子で指定された前記アプリケーションプログラムに対応するバックアップデータの生成時間を一つ以上、前記入出力装置に表示させる、
   ことを特徴とした管理システム。
3. 請求項２記載の管理システムであって、
   前記入力装置は、前記入力用の仮想ホスト識別子及び前記入力用のアプリケーションインスタンス識別子と、前記バックアップデータの生成時間表示に基いて入力された所定のバックアップデータを指定したリストア指示を受信し、
   前記プロセッサは、前記リストア指示で指定されたバックアップデータを格納する前記第三の論理ボリュームの一つを特定し、前記特定された第三の論理ボリュームの一つを指定したリストア指示を前記活性状態のホスト計算機へ送信することで、前記ストレージシステムに、前記第三の論理ボリュームの一つに格納されたバックアップデータを前記第一の論理ボリュームへ戻させる、
   ことを特徴とした管理システム。
4. 請求項３記載の管理システムであって、
   前記不活性状態のホスト計算機が、フェールオーバによって前記活性状態のホスト計算機から前記アプリケーションプログラムの処理を引き継ぐことで次の活性状態のホスト計算機となった場合、前記プロセッサは、
   （Ｈ）前記次の活性状態のホスト計算機が前記活性状態のホスト計算機から引き継いだ、前記バックアップスケジュール入力値に基くバックアップ用レプリケーション処理の制御の次の情報を取得し、
   （Ｉ）前記次の情報に従って、活性状態のホスト計算機が制御することで生成した次のバックアップデータの生成時間、及び前記バックアップデータを格納する前記一つ以上の第三の論理ボリュームの識別子を、前記カタログ情報として前記メモリに格納し、
   （Ｊ）前記管理用カタログ情報を参照することで、前記アプリケーションプログラムに対応するバックアップデータの生成時間として、前記次のバックアップデータの生成時間を前記入出力装置へ表示させる、
   ことを特徴とした管理システム。
5. 請求項３記載の管理システムであって、
   前記不活性状態のホスト計算機が、前記第一のストレージサブシステムへアクセス可能でなく、フェールオーバによって前記活性状態のホスト計算機から前記アプリケーションプログラムの処理を引き継ぐことで次の活性状態のホスト計算機となった場合、前記プロセッサは、
   （Ｋ）前記バックアップスケジュール入力値に基いた前記第二の論理ボリュームをコピー元として前記第二のストレージサブシステムが提供する一つ以上の第四の論理ボリュームをコピー先とする、次のバックアップ用レプリケーション処理の制御の次の情報を取得し、
   （Ｌ）前記次の情報に従って、活性状態のホスト計算機が制御することで生成した次のバックアップデータの生成時間、及び前記バックアップデータを格納する前記一つ以上の第三の論理ボリュームの識別子を、前記カタログ情報として前記メモリに格納し、
   （Ｍ）前記管理用カタログ情報を参照することで、前記アプリケーションプログラムに対応するバックアップデータの生成時間として、前記第四の論理ボリュームに格納された前記次のバックアップデータの生成時間を前記入出力装置に表示し、前記第三の論理ボリュームに格納された前記バックアップデータの生成時間の表示を抑止する、
   ことを特徴とした管理システム。

Images