JP2008033829A - バックアップシステム及びバックアップ方法 - Google Patents

Abstract

【課題】プロバイダよりも下位の構成がどのような構成であっても、コーディネータの機能を変更することなく、プロバイダよりも上位のソリューションによってバックアップを取得する。
【解決手段】ホスト計算機２０は、プライマリボリューム３１からセカンダリボリューム５１へのリモートコピー完了を検出すると、プライマリボリューム３１とセカンダリボリューム５１との間のコピーペアを分割し、プライマリボリューム３１のスナップショットをセカンダリボリューム５１に保持させる。バックアップサーバ４０は、セカンダリボリューム５１を認識する。
【選択図】図１

Description

本発明は複数のストレージシステム間でバックアップを取得するためのバックアップシステム及びバックアップ方法に関する。

近年のコンピュータシステムは、銀行及び証券業務などの基幹業務を大型コンピュータにより一括管理するコンピュータシステムからクライアント・サーバシステムを中心とする分散システムに移行している。このような分散システム環境では、クライアントからの要求をクラスタ構成された複数のサーバと複数のディスクアレイシステムとで処理する構成が採用されている。特開２００３−９９３０６号公報に開示されているように、このような高可用性クラスタでは、地震等の災害発生に対応するため、プライマリサイトだけでなく、プライマリサイトから長距離に所在するセカンダリサイトにもデータセンタを設置し、リモートコピーによりデータを二重化している。

一方、クライアント・サーバシステムにおけるバックアップ機能の一つとして、特開２００３−５３２１９１号公報に開示されているように、スナップショット機能が知られている。ベンダからは、スナップショット機能を搭載した様々な製品が提供されており、例えば、マイクロソフト（登録商標）が提供するＶＳＳ（Volume shadow copy service）は、バックアップソフトウェア、サーバアプリケーション、ストレージハードウェア等のバックアップ関連ハードウェア及びソフトウェアに対し、スナップショット作成のための共通インフラストラクチャを提供するサービスである。ＶＳＳによるバックアップ処理では一旦、スナップショットを作成し、そこからバックアップデータを取得するので、稼動中のサーバアプリケーションを停止させることなく、バックアップを作成できる。
特開２００３−９９３０６号公報 特開２００３−５３２１９１号公報

しかし、従来では、単一のストレージシステム内でバックアップを取得するソリューションと、複数のストレージシステム間でバックアップを取得するソリューションとは、それぞれ異なるものが運用されてきたので、前者のソリューションを用いて複数のストレージシステム間でバックアップを取得することは困難であった。例えば、ＶＳＳにおけるスナップショット取得は、リクエスタからのスナップショット要求を受けたコーディネータがライタに書き込み停止指示を与えるとともに、プロバイダにスナップショット作成指示を与えることで行われる。ＶＳＳが提供するスナップショット作成環境は、単一のストレージシステム内においてスナップショットを取得する場合を意識した設計であると考えられるので、ＶＳＳを用いて複数のストレージシステム間でスナップショットを取得するには、ＯＳの機能の一部であるコーディネータの機能を変更しなければならない。

そこで、本発明は、プロバイダよりも下位の構成がどのような構成であっても、コーディネータの機能を変更することなく、プロバイダよりも上位のソリューションによってバックアップを取得することを課題とする。

上記の課題を解決するため、本発明に係るバックアップシステムは、ホスト計算機と、ホスト計算機から入出力されるデータを格納するプライマリボリュームを有する第一のストレージシステムと、プライマリボリュームとの間でコピーペアを形成可能なセカンダリボリュームを有する第二のストレージシステムと、第二のストレージシステムに接続するバックアップサーバとを備える。ホスト計算機内のプロバイダは、プライマリボリュームからセカンダリボリュームへのリモートコピー完了を検出すると、プライマリボリュームとセカンダリボリュームとの間のコピーペアを分割し、プライマリボリュームのスナップショットをセカンダリボリュームに保持させる。バックアップサーバ内のプロバイダはバックアップサーバ内のオペレーティングシステムにセカンダリボリュームを認識させる。

本発明によれば、プロバイダよりも下位の構成がどのような構成であっても、コーディネータの機能を変更することなく、プロバイダよりも上位のソリューションによってバックアップを取得できる。

以下、各図を参照しながら本発明の実施形態について説明する。
図１は本実施形態に係るバックアップシステム１０のソフトウェア構成を中心としたシステム構成を示す。バックアップシステム１０は、プライマリサイトに設置されたストレージシステム３０と、ストレージシステム３０の記憶資源を使用して業務を行うホスト計算機２０と、プライマリサイトから遠距離に所在するセカンダリサイトに設置されたストレージシステム５０と、ストレージシステム３０，５０間におけるバックアップを管理するバックアップサーバ４０とを備える。

ストレージシステム３０が有するプライマリボリューム（正論理ボリューム）３１と、ストレージシステム５０が有するセカンダリボリューム（副論理ボリューム）５１との間には、リモートコピーペアが形成されており、プライマリボリューム３１のある時刻におけるデータがスナップショットによりカンダリボリューム５１に保持される。ストレージシステム３０，５０間のリモートコピーは、同期コピーでもよく、或いは非同期コピーでもよい。

ここで、同期コピーとは、ホスト計算機２０からのライトアクセスに対して、プライマリボリューム３１とセカンダリボリューム５１とに同一データの書き込み完了（正確には、キャッシュメモリへのデータ書き込み完了）を以って、ホスト計算機２０にライト完了を報告する方式をいう。非同期コピーとは、ホスト計算機２０からのライトアクセスに対して、プライマリボリューム３１にデータを書き込んだ時点（正確には、キャッシュメモリへのデータ書き込む完了）を以ってホスト計算機２０にライト完了を報告し、その後所定のタイミングでセカンダリボリューム５１にデータを書き込む方式をいう。

ホスト計算機２０は、リクエスタ２１、コーディネータ２２、プロバイダ２３、ＲＡＩＤマネージャ２４、及びライタ２５を備える。

リクエスタ２１は、例えば、バックアップアプリケーションであり、スナップショットを取得したいボリュームをコーディネータ２２に指定し、コーディネータ２２からスナップショットボリューム情報（デバイススペシャルファイル、デバイスネームなど）を受け取る。ホスト計算機２０内のリクエスタ２１は、バックアップサーバ４０内のリクエスタ４１との間で通信を行い、バックアップ処理に必要な情報を送受信できる。

コーディネータ２２は、ＯＳの機能の一部であり、スナップショット作成のためのインフラストラクチャを提供するサービスとして動作する。具体的には、コーディネータ２２は、プライマリボリューム３１にアクセスするライタ２５の動作を、リクエスタ２１からの要求に応答して制御する。コーディネータ２２は、バックアップ指定されたボリュームがバックアップ可能なボリュームであるか否かをプロバイダ２３に問い合わせたり、リクエスタ２１にスナップショットボリューム情報を送信したりする機能を有する。

プロバイダ２３は、ストレージ製品を製造販売する各ベンダによって提供されるものであり、スナップショット作成のためのインフラストラクチャを提供するサービスとして動作する。具体的には、プロバイダ２３は、コーディネータ２２からの指示を受けて、プライマリボリューム３１のスナップショットを作成する。プロバイダ２３には、ストレージシステムに依存するハードウェアプロバイダと、ベンダに依存しないソフトウェアプロバイダがある。

ＲＡＩＤマネージャ２４は、ボリュームを管理するための管理ソフトウェアであり、具体的には、プロバイダ２３からの指示を受けて、ボリューム間のペア操作やステータス取得などを行う。ホスト計算機２０内のＲＡＩＤマネージャ２４は、バックアップサーバ４０内のＲＡＩＤマネージャ４４との間で通信を行い、セカンダリサイトに所在するストレージシステム５０内のボリュームの操作やステータスを取得することもできる。

ライタ２５は、サーバアプリケーションに付属してスナップショットバックアップサービスを提供するプログラムであり、具体的には、データベース管理を行うＳＱＬサーバ等である。

バックアップサーバ４０は、リクエスタ４１、コーディネータ４２、プロバイダ４３、及びＲＡＩＤマネージャ４４を備える。これらの各機能は、上述したリクエスタ２１、コーディネータ２２、プロバイダ２３、及びＲＡＩＤマネージャ２４の各機能と同様であるので、詳細な説明を省略する。

ストレージシステム３０は、一つ以上のプライマリボリューム３１と、コマンドデバイス３２とを備える。プライマリボリューム３１は、ホスト計算機２０からのアクセスに供される運用ボリュームである。コマンドデバイス３２は、ホスト計算機２０（より詳細には、ＲＡＩＤマネージャ２４）とストレージシステム３０との間でコマンドやステータスを受け渡すための専用の論理ユニットである。ＲＡＩＤマネージャ２４からストレージシステム３０に送信されるコマンドは、コマンドデバイス３２に書き込まれる。ストレージシステム３０は、コマンドデバイス３２に書き込まれたコマンドに対応する処理を実行し、その実行結果をステータスとしてコマンドデバイス３２に書き込む。ＲＡＩＤマネージャ２４は、コマンドデバイス３２に書き込まれたステータスを読み出して確認し、次に実行すべきコマンドをコマンドデバイス３２に書き込む。このようにしてＲＡＩＤマネージャ２４は、ストレージシステム３０に各種の指示を与えることができる。

ストレージシステム５０は、一つ以上のセカンダリボリューム５１と、コマンドデバイス５２とを備える。セカンダリボリューム５１は、プライマリボリューム３１との間でリモートコピーペアを形成可能なバックアップ用のボリュームである。コマンドデバイス５２の機能は、上述したコマンドデバイス３２の機能と同様であるので、詳細な説明を省略する。

ここで、本実施形態に係るバックアップ方法の概要について説明する。本実施形態ではリモートコピーとスナップショットとを組み合わせることで、バックアップボリュームを作成する（図１に示す例では、セカンダリボリューム５１がバックアップボリュームである。）。そのため、プライマリボリューム３１からセカンダリボリューム５１へのリモートコピー完了をホスト計算機２０（より詳細には、プロバイダ２３）が検出し、プライマリボリューム３１のスナップショットを取得する必要がある。プロバイダ２３は、データベース凍結後にプライマリボリューム３１に格納されているデータに付されている最新のシーケンス番号と、セカンダリボリューム５１に格納されているデータに付されている最新のシーケンス番号とを比較し、両者が一致するか否かにより、リモートコピーが完了したか否かを判定する（特開２００３−９９３０６号公報参照）。

リモートコピーが完了すると、ホスト計算機２０内のＲＡＩＤマネージャ２４は、バックアップサーバ４０内のＲＡＩＤマネージャ４４にリモートコピーペアの分割（スナップショットの取得）を指示する。その後、バックアプサーバ４０内のＲＡＩＤマネージャ４４の処理により、セカンダリボリューム５１をバックアップサーバ４０内のオペレーティングシステムに認識させる。

バックアップボリュームが不要になった場合には、セカンダリボリューム５１をバックアップサーバ４０内のオペレーティングシステムから認識できないように設定し、リモートコピーペアを再同期させることで、再び、スナップショットを取得できる状態になる。

尚、スナップショット取得の際に利用可能なスナップショットの世代数ＭＵ＃（分割可能なペア状態）を、ＲＡＤＩマネージャ２４，４４の機能を利用して予め取得しておくことで、複数のストレージシステム３０，５０間における複数世代のスナップショットを、単一のストレージシステム内における複数世代のスナップショットの取得と同じにように取得することができる。

次に、図２を参照しながらバックアップ処理の流れについて説明する。説明の便宜上、バックアップボリュームを取得する一連の処理（ステップ２０１〜ステップ２２８）と、バックアップボリュームを削除する一連の処理（ステップ２２９〜ステップ２３４）とを同一のシーケンス図に示すが、取得処理と削除処理とは、必ずしも連続して実行されなければならないものではない。

まず、バックアップボリュームを取得する一連の処理の流れについて説明する。
リクエスタ２１は、ボリュームを指定した上でコーディネータ２２にバックアップ要求をする（ステップ２０１）。

すると、コーディネータ２２は、バックアップ要求を受けたボリュームがバックアップ可能なボリュームであるか否かをプロバイダ２３に問い合わせる（ステップ２０２）。

すると、プロバイダ２３は、リモートコピーペアが分割可能か否かをＲＡＩＤマネージャ２４に問い合わせる（ステップ２０３）。ここでは、スナップショットによりバックアップボリュームを取得する場合を想定しているので、リモートコピーペアが分割可能である場合には、バックアップボリュームを取得できることを意味し、リモートコピーペアを分割できない場合には、バックアップボリュームを取得できないことを意味する。

プロバイダ２３は、ＲＡＩＤマネージャ２４からリモートペア分割可否についての返答を受けると（ステップ２０４）、その情報をコーディネータ２２に転送する（ステップ２０５）。

そして、コーディネータ２２は、バックアップ要求を受けたボリュームがバックアップ可能なボリュームであるならば、プロバイダ２３にボリュームの登録要求を行う（ステップ２０６）。すると、プロバイダ２３は、コーディネータ２２からの登録要求に対してアクノリッジ信号を返す（ステップ２０７）。

プロバイダ２３からボリューム登録完了の報告を受けると、コーディネータ２２は、バックアップの可否をリクエスタ２１に報告する（ステップ２０８）。

バックアップボリュームの取得が可能であるならば、リクエスタ２１は、コーディネータ２２にバックアップ開始要求を通知する（ステップ２０９）。

すると、コーディネータ２２は、ボリューム登録処理が完了しているか否かをプロバイダ２３に問い合わせを行い（ステップ２１０）、登録処理が完了している旨の連絡をプロバイダ２３から受けると（ステップ２１１）、データベース凍結をライタ２５に指示する（ステップ２１２）。

コーディネータ２２は、書き込み処理を停止した旨の連絡をライタ２５から受けると（ステップ２１３）、プロバイダ２３にコピー作成指示（スナップショットによるバックアップボリュームの作成指示）を通知する（ステップ２１４）。

すると、プロバイダ２３は、リモートペア間のリモートコピーが完了したか否かをＲＡＩＤマネージャ２４に問い合わせる（ステップ２１５）。ＲＡＩＤマネージャ２４は、リモートコピー完了を待って、リモートコピー完了報告をする（ステップ２１６）。

そして、プロバイダ２３は、リモートペア間のペア分割をＲＡＩＤマネージャ２４に指示する（ステップ２１７）ホスト計算機２０内のＲＡＩＤマネージャ２４は、バックアップサーバ４０内のＲＡＩＤマネージャ４４にプライマリボリューム３１とセカンダリボリューム５１との間のペア分割を指示し、ペア分割完了を待って、ペア分割完了報告をする（ステップ２１８）。

すると、プロバイダ２３は、バックアップボリューム情報をコーディネータ２２に通知する（ステップ２１９）。

コーディネータ２２は、データベース凍結終了をライタ２５に指示し（ステップ２２０）、ライタ２５からデータベース凍結終了報告を受けると（ステップ２２１）、バックアップボリューム取得の可否をリクエスタ２１に問い合わせる（ステップ２２２）。

すると、図２には図示されてないが、ホスト計算機２０内のリクエスタ２１は、バックアップボリューム取得の可否をバックアップサーバ４０内のリクエスタ４１に問い合わせる。バックアップボリュームは、バックアップサーバ４０内のオペレーティングシステムに対して隠蔽された状態にある。

リクエスタ４１がコーディネータ２２にバックアップボリューム取得要求をすると（ステップ２２３）、コーディネータ４２は、バックアップボリュームをバックアップサーバ４０内のオペレーティングシステムに認識させ、ボリューム名をプロバイダ４３に伝達する（ステップ２２４）。

すると、プロバイダ４３は、バックアップボリュームのオペレーティングシステムからの隠蔽解除をＲＡＩＤマネージャ４４に指示する（ステップ２２５）。

プロバイダ４３は、ＲＡＩＤマネージャ４４から隠蔽解除完了報告を受けると（ステップ２２６）、コーディネータ４２に隠蔽解除完了報告をする（ステップ２２７）。これにより、リクエスタ４１は、バックアップボリュームを取得できる（ステップ２２８）。

次に、バックアップボリュームを削除する一連の処理の流れについて説明する。
リクエスタ４１は、コーディネータ４２にバックアップボリューム削除要求をする（ステップ２２９）。

すると、コーディネータ４２は、プロバイダ４３にバックアップボリューム削除要求をする（ステップ２３０）。

プロバイダ４３は、バックアップボリュームのオペレーティングシステムからの隠蔽処理をＲＡＩＤマネージャ４４に指示する（ステップ２３１）。

すると、図２には図示されてないが、バックアップサーバ４０内のＲＡＩＤマネージャ４４は、ホスト計算機２０内のＲＡＩＤマネージャ２４にリモートペアの再同期（バックアップボリュームの削除）を指示する。

ＲＡＩＤマネージャ４４は、プロバイダ４３にバックアプボリューム削除完了を報告する（ステップ２３２）。

プロバイダ４３は、コーディネータ４２にバックアプボリューム削除完了を報告する（ステップ２３３）。

コーディネータ４２は、リクエスタ４１にバックアプボリューム削除完了を報告する（ステップ２３４）。

本実施形態によれば、プロバイダ以下の下層のシステム構成を変更した場合（例えば、ストレージシステムの台数を変更した場合やカスケードペアを変更した場合）に、プロバイダの機能によって上記システム構成変更に対応する処理を行うので、プロバイダよりも上層（例えば、リクエスタ）の機能変更は不要となる。それ故、バックアップアプリケーションを使用してバックアップシステムを管理するシステム管理者は、プロバイダ以下の下層のシステム構成変更を意識することなく、バックアップアプリケーションを操作すればよい。これは、見方を変えれば、プロバイダ以下の下層のシステム構成変更に対応する機能をプロバイダが有しているため、バックアップアプリケーションの負荷軽減にも資する。

図３は本実施例に係るバックアップシステム１０のハードウェア構成を中心としたシステム構成を示す。図１に示す符号と同一符号のデバイスは同一のデバイスを示すものとしてその詳細な説明を省略する。ホスト計算機２０、ストレージシステム３０、バックアップサーバ４０、及びストレージシステム５０は、ネットワーク６０を介して相互に接続されている。

ホスト計算機２０は、ＣＰＵ（Central Processing Unit）、メモリ、及び入出力インターフェ等を備えたコンピュータシステムであり、具体的には、パーソナルコンピュータ、ワークステーション、メインフレーム等である。ホスト計算機２０には、ストレージシステム２０の記憶資源を使用するアプリケーションプログラム（例えば、データベースプログラム）が格納されている。

ストレージシステム３０は、データを格納するための記憶装置３２０と、記憶装置３２０へのデータの読み書きを制御する記憶制御装置３１０とを備える。記憶制御装置３１０は、複数のポート３１１、一つ以上のマイクロプロセッサ３１２、一つ以上の共有メモリ３１３、及び一つ以上のキャッシュメモリ３１４を備える。記憶装置３２０は、複数のストレージデバイス３２１を備える。

ポート３１１は、ホスト計算機２０、バックアップサーバ４０又はストレージシステム５０との間でデータ通信を制御するための通信インタフェースである。ポート３１１は、ＣＰＵやメモリ等を備えたマイクロコンピュータシステムとして構成されており、ホスト計算機２０から受信したコマンドを解釈実行する。各ポート３１１には、それぞれを識別するためのネットワークアドレス（例えば、ＩＰアドレスやＷＷＮ（World Wide Name））が割り当てられている。各ポート３１１は、ＮＡＳ（Network Attached Storage）として機能することもできる。

マイクロプロセッサ３１２はストレージデバイス３２１へのデータ入出力を制御する。マイクロプロセッサ３１２は、ポート３１１がホスト計算機２０から受信したデータをホスト計算機２０からのライトコマンドに基づいてストレージデバイス３２１の所定アドレスに書き込む他、ホスト計算機２０からのリードコマンドに基づいてストレージデバイス３２１の所定アドレスからデータを読み出し、ホスト計算機２０に送信する。マイクロプロセッサ３１２は、読み書きすべきデータの論理アドレスを物理アドレスに変換し、ストレージデバイス３２１との間のデータ入出力を制御する。複数のストレージデバイス３２１がＲＡＩＤ（Redundant Arrays of Independent Inexpensive Disks）に従って管理されている場合は、マイクロプロセッサ３１２は、ＲＡＩＤ構成に応じたデータアクセスを行う。

共有メモリ３１３は、主として、リソースの構成情報や各種コマンド等を記憶するために利用される。キャッシュメモリ３１４は、主として、ストレージデバイス３２１に読み書きされるデータを一時的に格納するために利用される。

ストレージデバイス３２１は、例えば、ハードディスク、フレキシブルディスク、磁気テープ、半導体メモリ、フラッシュメモリ、光ディスク等のような物理デバイスである。

ストレージシステム５０は、データを格納するための記憶装置５２０と、記憶装置５２０へのデータの読み書きを制御する記憶制御装置５１０とを備える。記憶制御装置５１０は、複数のポート５１１、一つ以上のマイクロプロセッサ５１２、一つ以上の共有メモリ５１３、及び一つ以上のキャッシュメモリ５１４を備える。記憶装置５２０は、複数のストレージデバイス５２１を備える。

ネットワーク６０は、例えば、ＬＡＮ（Local Area Network）、ＳＡＮ（Storage Area Network）、インターネット、専用回線、公衆回線等である。ここで、ＬＡＮを介するデータ通信は、例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）プロトコルに基づく。ホスト計算機２０がＬＡＮを介してストレージシステム３０に接続される場合、ホスト計算機２０は、ファイル名を指定してファイル単位でのデータ入出力を要求する。一方、ホスト計算機２０がＳＡＮを介してストレージシステム３０に接続される場合、ホスト計算機２０は、ファイバチャネルプロトコルに基づいて、複数のストレージデバイス３２１により提供される記憶領域のデータ管理単位であるブロックを単位としてデータ入出力を要求する。ネットワーク６０がＬＡＮである場合、ポート３１１は、例えばＬＡＮ対応のネットワークカードである。ネットワーク６０がＳＡＮである場合、ポート３１１は、例えば、ＨＢＡ（Host Bus Adapter）である。

図４は本実施例に係るバックアップシステム１０のソフトウェア構成を中心としたシステム構成を示す。図１に示す符号と同一符号のデバイスは同一のデバイスを示すものとしてその詳細な説明を省略する。

ストレージシステム５０は、プライマリボリューム３１との間でリモートコピーペアを形成するセカンダリボリューム５１と、セカンダリボリューム５１との間でカスケードペアを形成する複数のセカンダリボリューム５３，５４を備える。複数のセカンダリボリューム５３，５４は、それぞれセカンダリボリューム５１の異なる世代のスナップショットを保持するものである。例えば、セカンダリボリューム５３は、ある時刻ｔ１におけるセカンダリボリューム５１のスナップショットを保持するものであり、セカンダリボリューム５４は、他の時刻ｔ２におけるセカンダリボリューム５１のスナップショットを保持するものである。

本明細書では、説明の便宜上、プライマリボリューム３１とセカンダリボリューム５１との間のペア関係と、セカンダリボリューム５１とセカンダリボリューム５３，５４との間のペア関係を区別するため、前者をリモートコピーペアと称し、後者をカスケードペアと称する。

このように、プライマリボリューム３１のデータを一旦、リモートコピー先のセカンダリボリューム５１に転送してから、セカンダリボリューム５１のスナップショットを取得することで、データ転送時間を短縮しつつ、スナップショットの世代数を増やすことができる。

次に、図５を参照しながらバックアップ処理の流れについて説明する。説明の便宜上、バックアップボリュームを取得する一連の処理（ステップ５０１〜ステップ５２８）と、バックアップボリュームを削除する一連の処理（ステップ５２９〜ステップ５３４）とを同一のシーケンス図に示すが、取得処理と削除処理とは、必ずしも連続して実行されなければならないものではない。

まず、バックアップボリュームを取得する一連の処理の流れについて説明する。
リクエスタ２１は、ボリュームを指定した上でコーディネータ２２にバックアップ要求をする（ステップ５０１）。

すると、コーディネータ２２は、バックアップ要求を受けたボリュームがバックアップ可能なボリュームであるか否かをプロバイダ２３に問い合わせる（ステップ５０２）。

すると、プロバイダ２３は、リモートコピーペアが分割可能か否かをＲＡＩＤマネージャ２４に問い合わせる（ステップ５０３）。ここでは、スナップショットによりバックアップボリュームを取得する場合を想定しているので、リモートコピーペアが分割可能である場合には、バックアップボリュームを取得できることを意味し、リモートコピーペアを分割できない場合には、バックアップボリュームを取得できないことを意味する。

プロバイダ２３は、ＲＡＩＤマネージャ２４からリモートペア分割可否についての返答を受けると（ステップ５０４）、その情報をコーディネータ２２に転送する（ステップ５０５）。

そして、コーディネータ２２は、バックアップ要求を受けたボリュームがバックアップ可能なボリュームであるならば、プロバイダ２３にボリュームの登録要求を行う（ステップ５０６）。すると、プロバイダ２３は、コーディネータ２２からの登録要求に対してアクノリッジ信号を返す（ステップ５０７）。

プロバイダ２３からボリューム登録完了の報告を受けると、コーディネータ２２は、バックアップの可否をリクエスタ２１に報告する（ステップ５０８）。

バックアップボリュームの取得が可能であるならば、リクエスタ２１は、コーディネータ２２にバックアップ開始要求を通知する（ステップ５０９）。

すると、コーディネータ２２は、ボリューム登録処理が完了しているか否かをプロバイダ２３に問い合わせを行い（ステップ５１０）、登録処理が完了している旨の連絡をプロバイダ２３から受けると（ステップ５１１）、データベース凍結をライタ２５に指示する（ステップ５１２）。

コーディネータ２２は、書き込み処理を停止した旨の連絡をライタ２５から受けると（ステップ５１３）、プロバイダ２３にコピー作成指示（スナップショットによるバックアップボリュームの作成指示）を通知する（ステップ５１４）。

すると、プロバイダ２３は、リモートペア間のリモートコピーが完了したか否かをＲＡＩＤマネージャ２４に問い合わせる（ステップ５１５）。ＲＡＩＤマネージャ２４は、リモートコピー完了を待って、リモートコピー完了報告をする（ステップ５１６）。

そして、プロバイダ２３は、リモートペア間のペア分割をＲＡＩＤマネージャ２４に指示する（ステップ５１７）ＲＡＩＤマネージャ２４は、ペア分割完了を待って、ペア分割完了報告をする（ステップ５１８）。

すると、プロバイダ２３は、バックアップボリューム情報をコーディネータ２２に通知する（ステップ５１９）。

コーディネータ２２は、データベース凍結終了をライタ２５に指示し（ステップ５２０）、ライタ２５からデータベース凍結終了報告を受けると（ステップ５２１）、バックアップボリューム取得の可否をリクエスタ２１に問い合わせる（ステップ５２２）。

すると、図２には図示されてないが、ホスト計算機２０内のリクエスタ２１は、バックアップボリューム取得の可否をバックアップサーバ４０内のリクエスタ４１に問い合わせる。バックアップボリュームは、バックアップサーバ４０内のオペレーティングシステムに対して隠蔽された状態にある。

リクエスタ４１がコーディネータ２２にバックアップボリューム取得要求をすると（ステップ５２３）、コーディネータ４２は、バックアップボリュームをオペレーティングシステムに認識させ、ボリューム名をプロバイダ４３に伝達する（ステップ５２４）。

すると、プロバイダ４３は、バックアップボリュームのオペレーティングシステムからの隠蔽解除をＲＡＩＤマネージャ４４に指示する（ステップ５２５）。

プロバイダ４３は、ＲＡＩＤマネージャ４４から隠蔽解除完了報告を受けると（ステップ５２６）、コーディネータ４２に隠蔽解除完了報告をする（ステップ５２７）。これにより、リクエスタ４１は、バックアップボリュームを取得できる（ステップ５２８）。

次に、バックアップボリュームを削除する一連の処理の流れについて説明する。
リクエスタ４１は、コーディネータ４２にバックアップボリューム削除要求をする（ステップ５２９）。

すると、コーディネータ４２は、プロバイダ４３にバックアップボリューム削除要求をする（ステップ５３０）。

プロバイダ４３は、バックアップボリュームのオペレーティングシステムからの隠蔽処理をＲＡＩＤマネージャ４４に指示する（ステップ５３１）。

すると、図２には図示されてないが、バックアップサーバ４０内のＲＡＩＤマネージャ４４は、ホスト計算機２０内のＲＡＩＤマネージャ２４にリモートペアのペア再同期（バックアップボリュームの削除）を指示する。

ＲＡＩＤマネージャ４４は、プロバイダ４３にバックアプボリューム削除完了を報告する（ステップ５３２）。

プロバイダ４３は、コーディネータ４２にバックアプボリューム削除完了を報告する（ステップ５３３）。

コーディネータ４２は、リクエスタ４１にバックアプボリューム削除完了を報告する（ステップ５３４）。

次に、図６乃至図９を参照しながらプロバイダ２３の処理の詳細について説明する。
まず、バックアップ要求を受けたボリュームがバックアップ可能なボリュームであるか否かを判定する処理について、図６を参照しながら説明する。

プロバイダ２３は、プライマリボリューム３１のＬＵＮ情報をコーディネータ２２から取得すると（ステップ６０１）、ＬＵＮ情報に含まれているベンダＩＤ及びプロダクトＩＤをチェックし、プライマリボリューム３１がサポート対象のものであるか否かを判定する（ステップ６０２）。

プロバイダ２３は、プライマリボリューム３１がサポート対象外のものであると判定すると、サポート不可である旨をコーディネータ２２に返す（ステップ６０３）。

一方、プロバイダ２３は、プライマリボリューム３１がサポート対象のものであると判定すると、プライマリボリューム３１のＬＵＮ情報からプライマリボリューム３１を有するストレージシステム３０のＤＫＣ番号、及びプライマリボリューム３１のＬＤＥＶ番号を取得する（ステップ６０４）。ＤＫＣ番号は、ストレージシステムの製品番号を示すものである。

そして、プロバイダ２３は、スナップショットの世代数ＭＵ＃の範囲内において、ステップ６０６〜ステップ６０８の処理を繰り返す（ステップ６０５）。即ち、プロバイダ２３は、バックアップサーバ４０内のＲＡＩＤマネージャ４４からカスケードペア情報を取得し（ステップ６０６）、バックアップボリュームとして利用可能なペア状態か否かを判定し（ステップ６０７）、バックアップボリュームとして利用可能なペア状態であれば、その世代番号ＭＵ＃を取得する（ステップ６０８）。

そして、プロバイダ２３は、利用可能な世代数が存在するか否かをチェックし（ステップ６０９）、利用可能な世代数が存在しないならば、サポート不可である旨をコーディネータ２２に返し（ステップ６１０）、利用可能な世代数が存在するならば、バックアップ可能である旨をコーディネータ２２に返す（ステップ６１１）。

次に、ボリューム登録処理について、図７を参照しながら説明する。
プロバイダ２３は、プライマリボリューム３１のＬＵＮ情報をコーディネータ２２から取得すると（ステップ７０１）、ＬＵＮ情報からプライマリボリューム３１を有するストレージシステム３０のＤＫＣ番号、及びプライマリボリューム３１のＬＤＥＶ番号を取得する（ステップ７０２）。

そして、プロバイダ２３は、スナップショットの世代数ＭＵ＃の範囲内において、ステップ７０４〜ステップ７０６の処理を繰り返す（ステップ７０３）。即ち、プロバイダ２３は、バックアップサーバ４０内のＲＡＩＤマネージャ４４からカスケードペア情報を取得し（ステップ７０４）、バックアップボリュームとして利用可能なペア状態か否かを判定し（ステップ７０５）、バックアップボリュームとして利用可能なペア状態であれば、その世代番号ＭＵ＃を取得する（ステップ７０６）。

そして、プロバイダ２３は、利用可能な世代数が存在するか否かをチェックし（ステップ７０７）、利用可能な世代数が存在しないならば、サポート不可である旨をコーディネータ２２に返し（ステップ７０８）、利用可能な世代数が存在するならば、ＤＫＣ番号、ＬＤＥＶ番号、及びＭＵ＃をスナップショット構造体に格納する（ステップ７０９）。スナップショット構造体とは、スナップショットによるバックアップボリュームを取得する対象となるボリュームに関する情報を格納するための記憶領域をいう。

次に、バックアップボリューム作成処理について、図８を参照しながら説明する。
プロバイダ２３は、コーディネータ２２からスナップショットＩＤを取得し、そのスナップショットＩＤを基にスナップショット構造体を取得する（ステップ８０１）。

そして、プロバイダ２３は、スナップショット構造体に格納されている全てのボリュームに関する情報について、ステップ８０３〜ステップ８０５の処理を繰り返す（ステップ８０２）。即ち、プロバイダ２３は、プライマリボリューム３１を有するストレージシステム３０のＤＫＣ番号、及びプライマリボリューム３１のＬＤＥＶ番号をスナップショット構造体から取得し（ステップ８０３）、プライマリボリューム３１からセカンダリボリューム５１へのリモートコピー完了を待ち（ステップ８０４）、スナップショット構造体に格納されているＭＵ＃に対応するセカンダリボリュームについて、カスケードペアの分割をＲＡＩＤマネージャ４４に命令する（ステップ８０５）。

次に、バックアップボリューム情報通知処理について、図９を参照しながら説明する。
プロバイダ２３は、コーディネータ２２からプライマリボリューム３１のＬＵＮ情報を取得する（ステップ９０１）。

そして、プロバイダ２３はプライマリボリューム３１を有するストレージシステム３０のＤＫＣ番号、及びプライマリボリューム３１のＬＤＥＶ番号をＬＵＮ情報から取得し、カスケードペアを有するストレージシステムのＤＫＣ番号、及びカスケードペアのセカンダリボリューム（バックアップボリューム）のＬＤＥＶ番号を、バックアップサーバ４０内のＲＡＩＤマネージャ４４経由で取得する（ステップ９０２）。

プロバイダ２３は、カスケードペアを有するストレージシステムのＤＫＣ番号、及びカスケードペアのセカンダリボリューム（バックアップボリューム）のＬＤＥＶ番号を基にバックアップボリューム情報を生成し、バックアップボリューム情報をコーディネータ２２に返す（ステップ９０３）。

図１０は本実施例に係るバックアップシステム１１のソフトウェア構成を中心とするシステム構成を示す。図１に示す符号と同一符号のデバイスは同一のデバイスを示すものとしてその詳細な説明を省略する。

バックアップシステム１１は、バックアップ先のストレージシステムとして、ストレージシステム５０の他に更に、ストレージシステム７０を備える。ストレージシステム７０は、プライマリボリューム３１との間でリモートコピーペアを形成するセカンダリボリューム７１と、セカンダリボリューム７１との間でカスケードペアを形成する複数のセカンダリボリューム７３，７４と、ボリューム操作を行うためのコマンドデバイス７２とを備える。

ストレージシステム３０は、複数のプライマリボリューム３１，３３と、ボリューム操作を行うためのコマンドデバイス３２とを備える。プライマリボリューム３１は、セカンダリボリューム７１にリモートコピーされ、ある時刻の静止化されたデータイメージは、スナップショットとして、セカンダリボリューム７３に保持され、また他の時刻の静止化されたデータイメージは、スナップショットとして、セカンダリボリューム７４に保持される。同様に、プライマリボリューム３３は、セカンダリボリューム５１にリモートコピーされ、ある時刻の静止化されたデータイメージは、スナップショットとして、セカンダリボリューム５３に保持され、また他の時刻の静止化されたデータイメージは、スナップショットとして、セカンダリボリューム５４に保持される。

このように、プロバイダ２３，４３以下の下層のシステム構成が変更された場合（ストレージシステムの台数が増減された場合やカスケードペアが変更された場合）にも、プロバイダ２３，４３の機能によって、そのシステム構成変更に対応できる。それ故、バックアップアプリケーションを使用してバックアップシステムを管理するシステム管理者は、プロバイダ以下の下層のシステム構成変更を意識することなく、バックアップアプリケーションを操作すればよい。プロバイダ以下の下層のシステム構成変更に対応する機能をプロバイダが有しているため、バックアップアプリケーションの負荷軽減にも資する。

本実施形態に係るバックアップシステムのソフトウェア構成を中心としたシステム構成図である。 本実施形態に係るバックアップ処理の流れ図である。 本実施例に係るバックアップシステムのハードウェア構成を中心としたシステム構成図である。 本実施例に係るバックアップシステムのソフトウェア構成を中心としたシステム構成図である。 本実施例に係るバックアップ処理の流れ図である。 バックアップ可能なボリュームであるか否かを判定する処理を示す流れ図である。 ボリューム登録処理を示す流れ図である。 バックアップボリューム作成処理を示す流れ図である。 バックアップボリューム情報通知処理を示す流れ図である。 本実施例に係るバックアップシステムのソフトウェア構成を中心としたシステム構成図である。

符号の説明

１０，１１…バックアップシステム ２０…ホスト計算機 ３０…ストレージシステム ４０…バックアップサーバ ５０…ストレージシステム

Claims (10)

1. ホスト計算機と、
   前記ホスト計算機から入出力されるデータを格納するプライマリボリュームを有する第一のストレージシステムと、
   前記プライマリボリュームとの間でコピーペアを形成可能なセカンダリボリュームを有する第二のストレージシステムと、
   前記第二のストレージシステムに接続するバックアップサーバと、
   を備え、
   前記ホスト計算機は、前記プライマリボリュームから前記セカンダリボリュームへのリモートコピー完了を検出すると、前記プライマリボリュームと前記セカンダリボリュームとの間のコピーペアを分割し、前記プライマリボリュームのスナップショットを前記セカンダリボリュームに保持させ、前記バックアップサーバは、前記セカンダリボリュームを認識する、バックアップシステム。
2. ホスト計算機と、
   前記ホスト計算機から入出力されるデータを格納するプライマリボリュームを有する第一のストレージシステムと、
   前記プライマリボリュームとの間でコピーペアを形成可能な第一のセカンダリボリュームと、前記第一のセカンダリボリュームとの間でコピーペアを形成可能な第二のセカンダリボリュームとを有する第二のストレージシステムと、
   前記第二のストレージシステムに接続するバックアップサーバと、
   を備え、
   前記ホスト計算機は、前記プライマリボリュームから前記第一のセカンダリボリュームへのリモートコピー完了を検出すると、前記第一のセカンダリボリュームと前記第二のセカンダリボリュームとの間のコピーペアを分割し、前記プライマリボリュームのスナップショットを前記第二のセカンダリボリュームに保持させ、前記バックアップサーバは、前記第二のセカンダリボリュームを認識する、バックアップシステム。
3. 請求項２に記載のバックアップシステムであって、
   前記ホスト計算機は、前記第一のセカンダリボリュームとの間のコピーペアを分割できる前記第二のセカンダリボリュームの個数を前記バックアップサーバに問い合わせ、前記プライマリボリュームの複数世代のスナップショット取得を前記バックアップサーバに指示する、バックアップシステム。
4. 請求項２に記載のバックアップシステムであって、
   前記ホスト計算機は、前記第一のセカンダリボリュームと前記第二のセカンダリボリュームとの間のペア状態を再同期させることにより、前記第二のセカンダリボリュームに保持されているスナップショットを削除する、バックアップシステム。
5. 請求項２に記載のバックアップシステムであって、
   前記ホスト計算機は、前記プライマリボリュームに格納されているデータに付されているシーケンス番号と、前記第一のセカンダリボリュームに格納されているデータに付されているシーケンス番号が一致するか否かにより、前記プライマリボリュームから前記第一のセカンダリボリュームへのリモートコピーが完了したか否かを判断する、バックアップシステム。
6. ホスト計算機と、前記ホスト計算機から入出力されるデータを格納するプライマリボリュームを有する第一のストレージシステムと、前記プライマリボリュームとの間でコピーペアを形成可能なセカンダリボリュームを有する第二のストレージシステムと、前記第二のストレージシステムに接続するバックアップサーバとを備えるバックアップシステムにおけるバックアップ方法であって、
   前記プライマリボリュームから前記セカンダリボリュームへのリモートコピー完了を検出するステップと、
   前記プライマリボリュームと前記セカンダリボリュームとの間のコピーペアを分割するステップと、
   前記プライマリボリュームのスナップショットを前記セカンダリボリュームに保持させるステップと、
   前記セカンダリボリュームを認識するステップと、
   を備えるバックアップ方法。
7. ホスト計算機と、前記ホスト計算機から入出力されるデータを格納するプライマリボリュームを有する第一のストレージシステムと、前記プライマリボリュームとの間でコピーペアを形成可能な第一のセカンダリボリュームと、前記第一のセカンダリボリュームとの間でコピーペアを形成可能な第二のセカンダリボリュームとを有する第二のストレージシステムと、前記第二のストレージシステムに接続するバックアップサーバとを備えるバックアップシステムにおけるバックアップ方法であって、
   前記プライマリボリュームから前記第一のセカンダリボリュームへのリモートコピー完了を検出するステップと、
   前記第一のセカンダリボリュームと前記第二のセカンダリボリュームとの間のコピーペアを分割するステップと、
   前記プライマリボリュームのスナップショットを前記第二のセカンダリボリュームに保持させるステップと、
   前記第二のセカンダリボリュームを認識するステップと、
   を備えるバックアップ方法。
8. 請求項７に記載のバックアップ方法であって、
   前記第一のセカンダリボリュームとの間のコピーペアを分割できる前記第二のセカンダリボリュームの個数を前記バックアップサーバに問い合わせるステップと、
   前記プライマリボリュームの複数世代のスナップショット取得を前記バックアップサーバに指示するステップと、
   を更に備えるバックアップ方法。
9. 請求項７に記載のバックアップ方法であって、
   前記第一のセカンダリボリュームと前記第二のセカンダリボリュームとの間のペア状態を再同期させることにより、前記第二のセカンダリボリュームに保持されているスナップショットを削除するステップを更に備える、バックアップ方法。
10. 請求項７に記載のバックアップ方法であって、
    前記プライマリボリュームに格納されているデータに付されているシーケンス番号と、前記第一のセカンダリボリュームに格納されているデータに付されているシーケンス番号が一致するか否かにより、前記プライマリボリュームから前記第一のセカンダリボリュームへのリモートコピーが完了したか否かを判断するステップを更に備える、バックアップ方法。
    
    

Images