JP4526329B2 - 複数世代の回復スナップショットに関する情報処理システム - Google Patents

Description

本発明はデータの格納とバックアップをするストレージシステムに関わり、さらに詳細には、データの回復を処理し促進することを改善する技術に関わる。

データ信頼性を改善し、データのリモートバックアップコピーを備えたストレージシステムは、今日良く知られており、広く使われている。高性能なストレージシステムは莫大な量のデータを収容することができ、多数のアプリケーションに関して高速なアクセスができる。例えば、航空会社の予約システム、金融情報システムなどでは多数のユーザーがアクセスできる多量の情報を収容できる。これらのシステムでは、データを高速にアクセスできるだけでなく、障害から比較的速やかに回復できる高い信頼性のバックアップオペレーションが重要である。この様なシステムは冗長性のあるハードウェアを有してデザインされていて、システムにおけるデータの完全なリモートコピーを可能にしている。

航空会社の予約システムや金融情報システムの様なアプリケーションでは、データの可用性の欠如はたとえ短期間でも重大な困難を引き起こすことになる。多くのストレージシステムはスナップショット機能を有していて、システム管理者により制御できる周期をベースに、格納されている情報のコピーを作成する。

ストレージシステムのデータ回復に関する従来技術のひとつが、米国特許Ｎo. 6,397, 351、名称“Method and Apparatus for Rapid Data Restoration…”に記述されている。この従来技術では、プライマリボリュームで障害発生の直前に最後に使用されたデータは、障害発生の後にデータに加えられた変更の履歴とバックアップデータとを結合させて、回復させられることができる。

米国特許Ｎo. 6,397,351

例えばデータベースマネージメントシステムの様な多くのアプリケーションは、特別な回復ツールを有しており、装置やサーバーが障害を起こした時にアプリケーションのデータを回復する。これらのツールは、通常では障害の発生時にデータを有効にするだけである。データを保護したり、確実な一貫性のあった時点まで回復したりするために、アプリケーションはデータの完全性を保持するための情報を格納する能力を時には有している。Oracleのデータベースマネージメントソフトウェアはその様な能力を提供している。

従って、必要とされることは、ストレージシステムのバックアップと回復機能を実行できるだけでなく、ストレージシステム全体のオペレーションに適切なアプリケーション自身のデータ完全性マネージメントを行うシステムである。

多くのストレージサブシステムは、特定のボリュームあるいはボリュームの一部に周期的に、例えば毎分、毎時などにデータの状態のコピーを作成するスナップショット機能を有している。この様な従来のストレージサブシステムでは、データの状態は、ストレージサブシステムに接続したホストで実行されるアプリケーションプログラムの見通しとしばしば整合していない。これはスナップショットデータの状況がアプリケーションプログラムあるいはオペレーティングシステムと結合していないからである。しかしながら、現在では、実行不能になるとアプリケーションあるいはオペレーティングシステムプログラムで使用されるデータを回復する能力を有した多くのオペレーティングシステム機能とアプリケーションプログラムがある。この様なソフトウェアは、アプリケーションあるいはオペレーティングシステムの実行不能回復機能の実行の後に、回復されたデータの集計を通常提供する。本特許の特徴は、ボリュームの状況を示すスナップショットデータとアプリケーションあるいはオペレーティングシステムソフトウェアの実行不能回復機能によって回復されたデータを結合する能力である。

この様なシステムの基本的な構成は、ホストコンピュータとストレージサブシステムである。ホストとストレージサブシステムは、適正なチャネル、例えばファイバーチャネルインタフェース、イーサネット（登録商標）接続、インターネットなどで接続されている。ホスト自身は、ストレージサブシステム、スナップショットを生成するスケジューラ、ストレージサブシステムを制御するストレージエージェントなどを制御するためのマネージメントモジュールを含んでいる。アプリケーションソフトウェア、例えば従来のオフィスツールあるいはデータベースシステムは、そのアプリケーションのデータとファイルシステムの回復ツールを含んでいる。

この基本的な構成を使用して、スケジューラは予め決められたスケジュールに従ってスナップショットを生成するオペレーションを実施する。障害が発生すると、アプリケーションあるいはオペレーティングシステムソフトウェアの回復ツールは、ダメージを受けたデータをスナップショットから回復し、マネージャモジュールはスナップショットの集計に回復されたデータを挿入する。結果として、スナップショットデータは、どんなオペレーティングシステムあるいはアプリケーションソフトウェアのデータ回復機能も結合する。

スナップショットからデータの修復が要求されると、システム管理者はスナップショットデータを一覧表にするモジュールにアクセスして、スナップショットの集計から適切なスナップショットを選び、ホストに送出する。

ある一つの実施例では、ホストに結合されるのに適合したストレージサブシステムが存在している（提供される）。ストレージサブシステムは決められた時点におけるストレージサブシステム内のデータの状態を示すスナップショットデータを格納し、対応する時点のアプリケーションプログラムあるいはオペレーティングシステム機能に関係した他のデータを格納する。スナップショットと他のデータを結合することにより、ストレージサブシステムは決められた時点のその状況を示す状態に修復されることができる。

他の実施例では、データを格納するストレージシステムは、データ回復プログラムを実行できるオペレーティングシステムあるいはアプリケーションソフトウェアを有するコンピューターシステムに結合しており、障害後のデータ修復の効果を増大する方法は、特定のストレージシステムに収納されているデータのスナップショットを生成するステップと、オペレーティングシステムあるいはアプリケーションシステムのデータ回復プログラムを使用して、第二のデータイメージを結果として提供するためにコンピューターシステムに関係したデータを回復するステップを含んでいる。次いで、第一と第二のイメージは回復されたデータを提供するために結合される。

図１は、本発明の一実施例におけるハードウェア構成要素と構成要素の間の相互接続を示す構成図である。この構成図に示されている様に、システムは二つの部分、ホスト１０とストレージサブシステム２０、に一般に分割されている。ホスト１０は通常では商業的に入手できる従来のコンピューターシステム、例えばサーバーである。述べられている実施例では、ホスト１０は中央処理装置（ＣＰＵ）１２、メモリー１４、ストレージ１５を含んでいる。ストレージ１５は通常ではオペレーティングシステム、アプリケーションソフトウェア、およびストレージサブシステムマネージメントソフトウェアに対するストレージを提供する。

ストレージサブシステム２０は制御処理装置２２とデータを格納する為の一連のストレージボリューム２５を含んでいる。ストレージボリューム２５は通常ではハードディスクドライブあるいはハードディスクドライブのアレイ、これは例えばＲＡＩＤシステムとして構成されている、によって実現されている。ホスト１０のように、制御処理装置２２は通常では中央処理装置を含んでおり、好ましくはノンボラタイルランダムアクセスメモリー（ＮＶＲＡＭ）を含んでいる。制御処理装置はＮＶＲＡＭにデータを格納して、例えば電源障害から保護する。

ストレージボリューム２５は通常では一連のプライマリボリュームとセカンダリボリュームとして構成されている。通常では、プライマリボリュームはコンピューターシステムで使われるデータのストレージに使用され、一方、セカンダリストレージボリュームはより高いデータ信頼性を確保するために予備のストレージをしばしば提供する。ストレージボリュームはいろいろな良く知られた構成、例えばＲＡＩＤ０、ＲＡＩＤ５あるいは他の技術で構成されることがある。

図１では、ホストとストレージシステムは、イーサネット（登録商標）ベースのネットワークを使用して相互に結合されているように示されている。他の良く知られた接続方式を使用することもできる。例えばファイバーチャネル、ＳＣＳＩ，iＳＣＳＩ、トークンリングなどである。ストレージサブシステムの制御に対して、ブロック入力／出力オペレーションがインバンド接続を通して実施できる。もしストレージサブシステムがＮＦＳあるいはＣＩＦＳの様なファイルサーバをサポートしていると、コントローラーモジュールはファイルサーバ機能を提供することもあり、ファイルとして格納されたデータをプライマリおよびセカンダリボリュームに送出する。図１に示されたハードウェアは全て従来の商業的に入手できるコンピューターシステムの構成要素である。

図２は、図１のハードウェアシステムに対するソフトウェア構成要素とそれらの間の仮想的な相互接続を示した図である。図２で、実線はデータアクセスの方向を示しており、点線は制御の方向を示している。図２に示されている様に、ホストＣＰＵは、アプリケーションプログラム（ＡＰＰ）、ファイルシステム（ＦＳ）、およびアプリケーションデータとファイルシステムのための回復ツールを実行する。加えて、ホストは、全体システムのマネージメントを行うためにスケジューリングモジュール、マネージャモジュール、およびＣＬＩ／ＧＵＩインターフェースも実行する。ホストのメモリーの一部は、これらのいろいろなモジュールの為に使用される。

通常、アプリケーションとファイルシステムの構成要素は、アプリケーションが失敗する時にはいつでもデータを回復する為に“ジャーナル”の様な機能を有している。この様なツールは、プログラムが実行不能になった時に、もし無ければ失われてしまうかも知れない情報の回復の見通しを増大させる為の技術として、オペレーティングシステムの供給者あるいはアプリケーションの供給者によって通常は提供される。例えばファイルシステムレベルでは、NetAppはData ONTAPTM製品の中でこの様な技術を提供しており、VeritasもVeritas FilesystemTMの中でそれを提供している。加えて、オペレーティングシステムの供給者も“ｆｓｃｋ”に似たファイルシステム回復ツールをしばしば提供している。アプリケーション供給者が提供するデータ回復ツール（以下、回復ツール又は単にツールともいう）の例としては、Oracleのバージョン９ｉ“Fast Start Checkpointing”あるいはMicrosoftのOffice Tools document recoveryがある。図１および図２で述べられている好適な実施例では、これらの回復ツールはデータストレージの信頼性とシステムからの回復を増強する為に使用される。

大規模なストレージシステムでは、“スナップショット”の取得は、バックアップ情報を提供する為に良く知られた技術である。例えば、Hitachi Data SystemsのSoftware Solutions Guideのページ３８を参照されたい。実際に、スナップショットは、決められた時点のボリュームの全データの状態の記録を含んでいる。この様な記録は、固定の時点で既知の少なくとも以前の状況にストレージボリュームを修復することを可能にする。図２に表されているシステムに対するスナップショットの処理は、スケジューラモジュールの役目である。スケジューラモジュールは、スナップショットの取得のスケジュールを保持しており、ホスト（図１）のディスク１５のファイルとしてそのスケジュールを格納している。

図３は、スナップショットのスケジューリング用のファイルを示したものである。示されている様に、このファイルは、各項目毎に期間、処理、オーナーを含んでいる。図３に示された例では、スナップショットは、これは一分毎に取得されるが、第一の行に示されており、一時間毎に起きる様に予定されたバックアップオペレーションは、第二の行に示されている。
図２のマネージャモジュール３２は、異なった二つの種類の事象を処理する。第一の処理はスナップショットの生成である。この処理は、スケジューラモジュール３１に起動されるＡＰＩ（applications program interface）“create snapshot”を使用して通常は実行される。第二の処理は、例えば管理者の要求があったときに、ＣＬＩ（Command Line Interface）あるいはＧＵＩ（Graphical user interface）を使用した、データの修復である。

図４は、修復オペレーションと関連して使用されるであろうスナップショットの集計を示す表である。図４に示されている様に、この集計は、対象となる修復データの名前、スナップショットが取得された時間、データの状態、アプリケーションが回復ツールを提供するものと仮定した場合のアプリケーションの見通し（アプリケーション時間を参照）による修復時間を含んでいる。しばしば追加の列が、ストレージシステムの複数の異なったスナップショットの中から一つのスナップショットを特定する為に、スナップショットＩＤとして設けられる。スナップショットの集計の各フィールドは、スナップショットにつける名前、スナップショットがアプリケーションの観点から何時に取得されたかを示すアプリケーション時間、任意のスナップショットＩＤ、および“データの状態“という名前のフィールドである。この最後のフィールドは以下に説明される。

データの修復の特定なアプリケーションに対して、ここの好適な実施例で述べられる様に、二つの主要な部分がある。第一の部分は、適切なＡＰＩ（create snapshot）を呼び出すことによってスケジューラモジュール３１で起動されるスナップショットの生成である。第二の部分は修復オペレーション自身であり、選択されたスナップショットからデータを修復しようとする管理者によって通常は起動される。

図５は、スナップショットの生成を示すフローチャートである。処理がステップ４０で開始した後に、スナップショットはホスト１０（図１）のマネージャモジュール３２の制御の元に取得される。これは図５のステップ４１に示されている。ステップ４２では、ファイルシステムとスナップショットのデータとが回復される。これは、通常、マネージャモジュール３２が、回復ツールに、ファイルシステムとアプリケーションデータのために整合した状態を作る様に要求することで、実施される。ファイルシステムのために、通常の回復ツールはｆｓｃｋであり、アプリケーションのために、ツールは、通常、アプリケーションの供給者によって提供されるものである。

もしシステムが、例えばＮＦＳサーバーやＣＩＦＳサーバーのようなファイルシステムレベルで、プライマリボリュームとセカンダリボリュームを使用すれば、回復ツールはアプリケーションの回復ツールを実行することになる。一方、実行においてブロックレベルでプライマリボリュームとセカンダリボリュームが使用されると、回復ツールはファイルシステムのｆｓｃｋとアプリケーションの回復ツールを実行する。回復の間に、マネージャモジュールは、図４のスナップショット集計テーブルの先頭のデータの状態の下に“確認中”という状態を挿入する。

図５に示されている様に、次のステップはスナップショットの結果を挿入することである。もし回復が成功ならば、この結果は“回復済”となる。もし成功ならば、マネージャはデータの状態のフィールドに“整合（回復済）”という結果を挿入する。一方、もし回復が失敗ならば、結果は“不整合（未回復）”となる（図４の列３を参照）。

図６は修復処理に関係したオペレーションを示したフローチャートである。修復オペレーションは、整合しているスナップショット同士の集計から管理者が選択したデータを提供する。図６に示されている様に、フローチャートはステップ５０で開始して、ステップ５１に進んでスナップショットの集計を要求する。それに応答して、マネージャモジュールは図４に示されている集計をステップ５２で返す。次に、ステップ５３でスナップショットが要求される。

ステップ５４で示されている様に、要求されたスナップショットがホストに送出される。ステップ５５で、スナップショットはホストに組み込まれ、そしてステップ５６で、管理者がその様に要求していると仮定して、マネージャモジュールは、回復されたデータを使用してアプリケーションを実行し始める。このオペレーションとやり取りの結果として、管理者は、どのスナップショット同士が整合していてどのスナップショット同士が整合していないかを区別できる。これがスナップショットと修復へのアクセスをより容易にする。

図７は、図２で前に示されたソフトウェアの構成要素に対する代わりの実現内容の構成図である。図７では、スケジューラモジュールはホストの中に配置されているのではなく、ストレージサブシステム制御処理装置の中に配置されていることに注目されたい。この実施では、スケジューラは自分自身でスナップショットの生成を実行できる。さらに、スケジュールファイル（図３に対応）も今やストレージサブシステムの制御モジュールの中に配置されるであろう。

図８は、図７で表された実施例におけるスナップショットの生成を示すフローチャートである。図８に示されている様に、スナップショットは制御装置のマクロコードを使用してステップ８０で生成される。次に、ファイルシステムとスナップショットのデータは、ステップ８１で示されている様に回復される。ファイルシステムに対する回復ツールはｆｓｃｋオペレーションであり、アプリケーションに対する回復ツールはアプリケーション供給者によって提供されるツールである。もしプライマリボリュームとセカンダリボリュームが例えばＮＦＳサーバーあるいはＣＩＦＳサーバーの方法で使用されると、ファイルシステムに対する回復ツールはアプリケーションに対する回復ツールを実行する。一方、それらのツールは別々に実行され、別々に制御されることができる。上記のように、回復オペレーションの間に、マネージャモジュールは“確認中”の状態を集計に挿入する。

ステップ８２で、スナップショットの結果は挿入される。これはマネージャモジュールが回復の結果を挿入することによって達成される。回復が失敗すると、マネージャモジュールは“不整合（未回復）”という結果を挿入する。もしオペレーションが成功であると、マネージャは“整合（回復済）”という結果を挿入する。

図９は、図１とは異なったハードウェア構成を示している構成図である。この実施で、スナップショットの生成の後のアプリケーションの回復モジュールが変更されている。図９に示されている構成要素は図１に示されている構成要素とおおむね類似しているが、オンラインホスト９０とスナップショットマネージメントホスト１００の二つのホストが存在している。ストレージサブシステム２０は図１に述べられているものと同じである。しかしながら、“ＦＣ”という名前の二つのチャネルインターフェースがストレージサブシステムにある。二つのホスト９０と１００のそれぞれは、ストレージサブシステム２０のボリュームに接続し、共有できる。もし必要ならば、管理者がホストバスアダプターに固有の番号であるＷＷＮ（world wide name）を割り付けると、ホストからそのボリュームへのアクセスを制御できる様なストレージサブシステム２０にすることができる。この機能はしばしばＬＵＮ（Logical Unit Number）マッピングと呼ばれる。ホストとストレージサブシステムの間の別の通信接続はイーサネット（登録商標）接続であるが、その他の良く知られたインターフェースが使用されてもよい。

図１０は、図９のハードウェアの実現内容に対するソフトウェアの構成要素を示した構成図である。この図の上の部分に示されている様に、図１０に示されている配列と図２に述べられている配列の間の重要な相違は、関連した特定の業務によって、機能が二つのホストの間で分けられていることである。図１０で、オンラインホストはファイルシステム（ｆｓ）、アプリケーションサーバーの部分とエージェントを含んでいる。スナップショットマネージメントホストは図２の残りの構成要素を含んでいる。オンラインホスト９０はアプリケーションとファイルシステムを実行し、スナップショットマネージメントホストは決められたスケジュールでスナップショットマネージメントを実行し、データ回復ツールを設定されている様に維持する。図１０に示されているモジュールのそれぞれは上記に述べられたのと同じ方法で動作する。マネージャモジュールはアプリケーションとファイルシステムのオペレーションを直接には制御できないので、エージェントがオンラインホストに挿入されて、アプリケーションの開始と停止を制御する能力を実現する。

図１１は図１０に示されているモジュールに対する動作シーケンスを示すフローチャートである。図１１に示されている様に、ステップ１１０のスナップショットを組み込むステップとステップ１２０の回復されたデータを使用してアプリケーションを開始するステップはエージェントに移されている。その他の全てのステップは図６と同じ方法で実行される。

図１２は本発明の別の実施方法を示す構成図であり、ここではスケジューラ１２５は図７に示されているのと同じ方法でストレージサブシステム２０の制御処理装置に組み込まれている。このことは、ストレージサブシステム２０の中の制御処理装置内からスケジューラが自分自身でスナップショットを実行できるようにする。

以上は本発明の好適な実施例の記述である。以下の請求範囲で決められた範囲から外れる事無く、いろいろな修正が本発明の実施に対して行われることは理解されるところである。

好適な実施例でのハードウェア構成要素と相互接続の構成図である。 図１を実施するためのソフトウェア構成要素の構成図である。 スケジュールファイルの一例である。 スナップショット情報の集計の一例である。 スナップショットの生成を示すフローチャートである。 修復オペレーションを示すフローチャートである。 本発明の他の実施におけるソフトウェア構成要素の配置を示す。 図７の実施に対するスナップショットの生成を示すフローチャートである。 本発明のさらなる実施例でのハードウェア構成要素と相互接続の構成図である。 その様な実施例でのソフトウェア構成要素と関連を示す構成図である。 この実施における修復オペレーションを示すフローチャートである。 本発明のさらなる実施例でのソフトウェア構成要素と関連を示す構成図である。

１０・・・ホスト、１２・・・ＣＰＵ、１４・・・メモリー、１５・・・ディスク、２０・・・ストレージサブシステム、２２・・・ＣＴＬ、３１・・・スケジューラ、３２・・・マネージャ、１２５・・・スケジューラ

Claims (4)

1. データ回復プログラムを実行可能なアプリケーションソフトウェアを有するコンピュータと、前記コンピュータに接続されており、前記コンピュータから書き込み要求を受け取るストレージシステムとを備える情報処理システムにおいて、
   前記ストレージシステムは、
   前記コンピュータからの前記書き込み要求を処理するストレージコントローラと、
   前記ストレージコントローラに接続され、前記コンピュータからの前記書き込み要求に関連するデータを格納する第１の格納ボリュームと、
   前記ストレージコントローラに接続され、所定時間における前記第１の格納ボリュームのスナップショットを格納する前記第２の格納ボリュームとを有し、
   前記情報処理システムは、
   前記データ回復プログラム及び前記スナップショットを使用して前記第１の格納ボリュームのデータ回復動作を実行し、
   前記情報処理システムは、
   前記データ回復動作の結果が正常な回復であることを示す場合、前記スナップショットを整合性のあるスナップショットとして指定し、前記データ回復動作の結果が正常でない回復であることを示す場合、前記スナップショットを整合性のないスナップショットとして指定し、
   前記情報処理システムは、
   ユーザからの要求に応じて、前記ユーザに対し、前記スナップショットについて整合性があるか否かを含む前記スナップショットの情報を提示する
   ことを特徴とする情報処理システム。
2. 前記スナップショットは、前記コンピュータの制御の下に生成されることを特徴とする請求項１に記載の情報処理システム。
3. 前記スナップショットは、前記ストレージシステムの制御の下に生成されることを特徴とする請求項１に記載の情報処理システム。
4. 前記アプリケーションソフトウェアは、
   前記データ回復動作のためのジャーナル情報を管理することを特徴とする請求項１に記載の情報処理システム。