JP4215542B2 - 2つのスナップショット間の変化を判定して宛先スナップショットに送信するシステム及び方法 - Google Patents
2つのスナップショット間の変化を判定して宛先スナップショットに送信するシステム及び方法 Download PDFInfo
- Publication number
- JP4215542B2 JP4215542B2 JP2003075430A JP2003075430A JP4215542B2 JP 4215542 B2 JP4215542 B2 JP 4215542B2 JP 2003075430 A JP2003075430 A JP 2003075430A JP 2003075430 A JP2003075430 A JP 2003075430A JP 4215542 B2 JP4215542 B2 JP 4215542B2
- Authority
- JP
- Japan
- Prior art keywords
- snapshot
- file
- destination
- block
- inode
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
- G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
- G06F11/2074—Asynchronous techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
- G06F11/2066—Optimisation of the communication load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/1734—Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
- G06F16/184—Distributed file systems implemented as replicated file system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
- G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Description
【発明の属する技術分野】
本発明はファイルサーバを用いたデータの記憶に関し、詳しくは遠隔の記憶場所に記憶されたデータのネットワークを介したミラーリングまたは複製に関する。
【0002】
【従来の技術】
ファイルサーバは、ディスク等の記憶装置上での情報の編成に関するファイルサービスを提供するコンピュータである。ファイルサーバまたはファイラーには、ディスク上で情報をディレクトリ及びファイルの階層構造として論理的に編成するためのファイルシステムを実施するストレージオペレーティングシステムが含まれる。「ディスク上」の各ファイルは、ディスクブロック等のデータ構造の集まりとして実現され、情報を格納するように構成される。一方、ディレクトリは、他のファイル及びディレクトリに関する情報を格納する特別な形態のファイルとして実現される。
【0003】
ファイラーは、クライアント/サーバ形態の情報配送に従って動作するようにさらに構成され、多数のクライアントがファイラー等のサーバ上に格納されたファイルにアクセスできるようになっている。この形態の場合、クライアントは、直接接続や、ポイント・ツー・ポイントリンク、共用ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)またはインターネット等の公衆網上で実施される仮想施設ネットワーク(VPN)等のコンピュータネットワークを介してファイラーに「接続」するコンピュータ上で、データベースアプリケーション等のアプリケーションを実行している場合がある。各クライアントは、ネットワークを介してファイルシステムプロトコルメッセージを(パケットの形で)ファイラーに発行することによって、ファイルシステムのサービスをファイラーに要求することができる。
【0004】
一般的なタイプのファイルシステムは「定位置書き込み」ファイルシステムであり、その一例はバークレイ・ファーストファイルシステムである。「ファイルシステム」はディスク等の記憶装置上のデータ及びメタデータの構造を一般に意味し、ファイルシステムによってそれらのディスクに対するデータの読み書きが可能になる。定位置書き込みファイルシステムの場合、inodeやデータブロック等のデータ構造のディスク上での位置が通常、固定になっている。inodeはファイルに関するメタデータ等の情報を記憶するのに用いられるデータ構造であり、データブロックはそのファイルの実際のデータを記憶するのに用いられるデータ構造である。inodeに保持される情報には、例えばそのファイルの所有者、そのファイルのアクセス権、そのファイルのサイズ、そのファイルのタイプ及びデータブロックのディスク上の位置に対する参照などが含まれる。ファイルデータの位置に対する参照は、ポインタとしてinodeに設けられ、そのファイルのデータ量に応じて、間接ブロックの参照、即ちデータブロックへの参照をさらに含む場合もある。inode及びデータブロックに対する変更は、固定位置書き込みファイルシステムに従って「定位置」で行なわれる。ファイルの更新がそのファイルのデータ量を超えるものである場合、さらにデータブロックが割り当てられ、そのデータブロックを参照するように適当なinodeが更新される。
【0005】
他のタイプのファイルシステムとしては、ディスク上のデータを上書きしないWrite-anywhereファイルシステムがある。ディスクからそのディスク上のデータブロックがメモリに取得され(読み出され)、新たなデータで汚される場合、そのデータブロックがディスク上の新たな位置に格納される(書き込まれる)ので、書き込み効率が最適になってる。Write-anywhereファイルシステムは、データがディスク上で実質的に連続的に配置されるように、まず最適なレイアウトを推定する。この最適なレイアウトによって、特にディスクに対するシーケンシャル読み出し処理に関して、効率的なアクセス処理が可能になる。ファイラー上で動作するように構成されたWrite-anywhereファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワークアプライアンス社から入手できるWrite Anywhere File Layout(WAFL)ファイルシステムである。WAFLファイルシステムは、ファイラー及び関連ディスクストレージのプロトコルスタック全体のうちの一部としてマイクロカーネル内で実施される。このマイクロカーネルは、ネットワークアプライアンス社のData ONTAPストレージオペレーティングシステムの一部として提供され、ネットワーク取り付けされたクライアントからのファイルサービス要求を処理する。
【0006】
本明細書で用いられるように「ストレージオペレーティングシステム」という用語はデータアクセスを管理するコンピュータ上で実行可能なコンピュータ実行可能コードを意味し、ファイラーの場合、このコードはカリフォルニア州サニーベイルにあるネットワークアプライアンス社から入手可能なData ONTAP(R)ストレージオペレーティングシステム等のファイルシステムセマンティックを実施するものであり、Data ONTAPストレージオペレーティングシステムはマイクロカーネルとして実施され、Write Anywhere File Layout(WAFL(R))ファイルシステムを実現する。ストレージオペレーティングシステムは、UNIX(R)やWindows(R) NT等の汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施することもできるし、本明細書に記載するようなストレージアプリケーションとして構成された設定可能な機能を有する汎用オペレーティングシステムとして実施することもできる。
【0007】
ディスクストレージは通常、ストレージ空間の全体的な論理的配置を定義する、物理的記憶ディスクを含む1以上のストレージ「ボリューム」として実施される。現在利用可能なファイラー実施形態は、多数の個別のボリューム(例えば150以上)を使用することができる。各ボリュームにはそのボリュームに固有のファイルシステムが関連付けられ、その意味で、ボリュームとファイルシステムは一般に同義語として用いられる。ボリューム内のディスクは通常、1以上のグループのRAID(Redundant Array of Independent(Inexpensive) Disks)に編成される。RAID実施形態は、RAIDグループ内の所定数の物理ディスクにわたってデータ「ストライプ」を冗長書き込みし、そのストライプ化されたデータに関するパリティ情報を適当にキャッシュすることによって、データ記憶の信頼性/完全性を向上させている。WAFLファイルシステムの一例では、RAID4実施形態が有利に用いられている。この実施形態では、1グループのディスクにわたってデータをストライピングし、RAIDグループのうちの選択されたディスク内で個別にパリティをキャッシュする必要がある。本明細書に記載するように、ボリュームは通常、RAID4または同等の高信頼性の実施形態に従って配置された、少なくとも1台のデータディスク及び1台の関連パリティディスク(データ/パリティの場合もある)パーティションを含む。
【0008】
ファイラー、ファイラーに関連するディスク、または、ストレージインフラストラクチャの何らかの部分に故障が発生したときの信頼性を向上させ、災害普及を容易にするため、基礎的データ及び/又は該データを編成するファイルシステムのうちのいくらか又は全部を「ミラーリング」すなわち複製することが一般的である。例えばミラーは、離れたサイトに作成及び格納され、主要な格納場所やそのインフラストラクチャに真の災害(例えば洪水、停電、戦争活動など)が発生した際の復元の可能性を向上させる。ミラーは、ファイルシステムに対する最新の変更を把握するため、管理者によって設定された所定の時間間隔で更新されるのが一般的である。更新の一般的な一形態では、inodeとブロックで構成されるストレージサイトのアクティブファイルシステムを取り込み、ネットワーク(周知のインターネット等)を介して概して「スナップショット」を遠隔のストレージサイトに送信する、「スナップショット」プロセスを使用する。一般に、スナップショットは、ある時点でのファイルシステムのイメージ(通常は読み出し専用)であり、アクティブファイルシステムと同じ一次記憶装置に格納され、アクティブファイルシステムのユーザがアクセスできるようになっている。「アクティブファイルシステム」は、現在の入出力処理が向けられている対象となるファイルシステムを意味する。一連のディスク等の一次記憶装置はアクティブファイルシステムを格納するものであり、テープドライブ等の二次記憶装置はアクティブファイルシステムのバックアップを格納するために用いられる。
【0009】
スナップショットを作成した後、起こり得る災害復旧に備えてその時点で作成されたスナップショットを残し、アクティブファイルシステムが再確立される。スナップショットを作成するたびに古いアクティブファイルシステムが新たなスナップショットになるので、新たなアクティブファイルシステムは何らかの変更を記録し続ける。様々な時間ベースの基準及びその他の基準に応じて、所定数のスナップショットが維持される。スナップショットを作成する処理の詳細については、「INSTANT SNAPSHOT」と題したBlake Lewis他による米国特許出願第09/932578号明細書に記載されており、この出願はここで参照することにより完全に説明したものとして本明細書に取り込まれる。また、WAFLファイルシステムに固有のSnapshot(R)機能については、ネットワークアプライアンス社が発行している「File System Design for NFS File Server Appliance」と題したDavid Hitz他によるTR3002、及び、同所有者の「METHOD FOR MAINTAINING CONSISTNT STATES OF A FILE SYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF A FILE SYSTEM」と題したDavid Hitz他による米国特許第5819292号明細書にさらに詳しい説明があり、これらはここで参照することにより取り込まれる。
【0010】
ファイルシステムの大きさが数十ギガバイトや数百ギガバイト(数テラバイトと同じ)に及ぶ場合、ネットワークを介してファイルシステム全体をリモート(宛先)サイトに完全に複製することは、かなり不便である。遠隔地にデータ複製するためのこの完全バックアップ方法は、ネットワークの帯域幅に激しい負担をかける場合があり、複製先と複製元の両方ファイラーの処理能力にも負担をかける場合がある。一解決方法として、スナップショットをファイルシステムボリュームのうちの変更を受けた部分のみに制限するということが行なわれている。従って、図1は従来技術によるボリュームベースのミラーリングを示すものであり、この図において、複製元ファイルシステム100はネットワークリンク104を介して宛先記憶サイト102(サーバとそれに取り付けられた記憶装置で構成される。図示せず)に接続されている。宛先102は、管理者によって設定された所定の時間間隔で周期的にスナップショットの更新を受信する。これらの時間間隔は、帯域幅、データの重要性、変更の頻度、及び、ボリューム全体のサイズ等を含む様々な基準をもとにして選択される。
【0011】
簡単にまとめると、ソースは、時間をあけて、そのボリュームの1対のスナップショットを作成する。これらのスナップショットは、データをファイラーの不揮発性メモリに送信する送信処理の部分で作成することができ、あるいは他の手段によって作成することもできる。「新たな」スナップショット110は、そのボリュームのアクティブファイルシステムの最新のスナップショットである。「古い」スナップショット112は、そのボリュームの古いスナップショットであり、宛先のミラーに複製されているファイルシステムイメージに一致するはずのものである。注意して欲しいのは、ファイルサーバは、新たなスナップショット112の作成が終われば、ファイルサービス要求に対する作業を自由に続けられるということである。この新たなスナップショットは、現在のボリューム状態を完全に表現するものではなく、その時刻に至るまでの活動状態のチェックポイントとして働くものである。相違検出器120は古いスナップショットと新たなスナップショットを調べる。具体的には、相違検出器は、各スナップショットのブロックのリストを1ブロックづつ検査して、そこに配置されているブロック同士を比較する。Write-anywhereファイルシステムの場合、スナップショットがブロックを参照している限りそのブロックは再利用されないので、データの変更は新たなブロックに書き込まれる。変更が確認された場合(データを意味する「×」の存在または不在で図示する)、相違検出器120は、図2に示す判断処理200によってそのデータを宛先102へ送信するか否かを判定する。この判断処理200は、古いブロックと新しいブロックとを次のような手順で比較する。(a)新/旧ブロック対130のように古いブロックにも新しいブロックにもデータがない場合(200の場合)、転送可能なデータはない。(b)新/旧ブロック対132のように古いブロックにはデータがあるが新しいブロックにはデータがない場合(204の場合)、そのようなデータは転送が済んでいるので(新たな宛先スナップショットポインタはいずれもそのデータを無視するので)、新たなブロック状態は転送しない。(c)新/旧ブロック対134のように古いブロックと新たなブロックとの両方にデータが存在する場合(206の場合)、何も変更がなされていないので、そのブロックデータは既に前のスナップショットに転送されている。(d)最後に、新/旧ブロック対136のように古いブロックにはデータがないが新たなブロックにはデータがある場合(208の場合)、変更されたデータブロックをネットワークを介して転送し、変更されたブロック142のように、宛先の変更されたボリュームスナップショット集合140の一部になるようにする。例示のWrite-anywhereファイルシステム構成の場合、これらの変更されたブロックは、ストレージアレイの新たな未使用の位置に書き込まれる。変更されたブロックがすべて書き込まれると、基礎ファイルシステム情報ブロック、すなわち、新たなスナップショットのルートポインタが宛先に送信される。このファイルシステム情報ブロックが宛先に送信されると、前のファイルシステム情報を置き換えて変更されたブロック構造を指し示すようにすることにより、宛先のファイルシステム全体が更新される。この時点で、変更が宛先ボリュームスナップショットの最新の差分更新として送信される。このファイルシステムは、ソースにある「新たな」スナップショットを正確に表現する。その後、さらなる変更差分から新しい「新たな」スナップショットが作成される。
【0012】
ボリュームベースでスナップショットの遠隔ミラーリングを行なう方法については、同所有者の「FILE SYSTEM IMAGE TRANSFER」と題したSteven Kleiman他による米国特許出願第09/127497号明細書、及び、Steven Kleiman他による「FILE SYSTEM IMAGE TRANSFER BETWEEN DISSIMILAR FILE SYSTEMS」と題した米国特許出願第09/426409号明細書に詳しい説明があり、これら両方がここで参照することにより本明細書に取り込まれる。
【0013】
このボリュームベースの方法は、ソースから遠隔の記憶先へ漸進的にミラーリングするのに有効ではあるが、ボリューム全体についての変更を検査して、それらの変更を1ブロックづつ送信しなければならないという点で、非効率で時間のかかる方法である。言い換えると、この検査は、ブロックに含まれるファイル、inode及びデータ構造に関する基礎情報を何も考慮することなく、ブロックに着目して行われる。宛先が一連のボリュームに編成されているので、ソースと宛先との間には、直接ボリューム単位のマッピングが確立される。ここでも、1ボリュームは1テラバイト以上もの情報を含む場合があり、変更を検査して比較する1ブロックづつの方法は、相当なプロセッサオーバヘッドとそれに関連する処理時間を必要とする。多くの場合、検査中のルートinodeブロックの下方にあるサブブロックにわずかな変更が施されているだけである。しかしながら、そのボリューム内のあらゆるブロックのリストを検査しており、ブロックのグループ分け(ファイル、inode構造など)の多くに変更がないという事実は考慮されていない。さらに、ボリューム全体のサイズ及び範囲が大きくなるにつれて、グループによっては頻繁に変更されるグループもあり、それらのグループの複製は、あまり頻繁に変更されない他のグループの複製よりも頻繁に更新することが望ましいので、ミラーリングしているデータはサブグループに分割することが極めて望ましい。さらに、元のサブグループと複製された(スナップショットの)サブグループとを1つのボリュームに混在させ、ボリューム全体を移動させることなく特定の重要データを遠隔地に移動することが望ましい。従って、全体よりも少ないボリュームのミラーリングを可能にするボリュームの下位編成と、変更されたブロックをスキャンして特定するための、もっと洗練された方法が望まれている。
【0014】
このようなボリュームの下位編成の1つが、周知のQtreeである。Qtreeは、本明細書に記載される例示的ストレージシステム等で実施されるように、ボリュームのファイルシステムにおけるサブツリーである。Qtreeの重要な特徴は、あるQtreeが与えられると、そのQtreeへの所属についてシステム内のあらゆるファイル及びディレクトリを迅速に検査することができるので、Qtreeはファイルシステムを個別のデータ集合に編成するための優れた手段として機能するということである。スナップショットを作成するデータのソース及び宛先として、Qtreeを使用することが望ましい。
【0015】
【発明が解決しようとする課題】
宛先に複製されたスナップショットがQtreeであれば、そのスナップショットは、災害復旧やデータ配布等、他の用途にも利用することができる。しかしながら、ユーザまたはプロセスがアクセスしようとしたとき、宛先のアクティブファイルシステム上にあるスナップショットは、ソーススナップッショットを受信中であったり、ソーススナップショットからの更新を処理中であったりする場合がある。干渉されることなくスナップショットの更新を完了できるようにする方法が強く望まれている。同様に、スナップショットを初期の状態に戻す必要がある場合、そのような復元すなわち「巻き戻し」を容易にする方法も望まれている。様々な時点における複数のスナップショットを処理するための様々なその他の技術は、スナップショット複製手段の汎用性及び有用性を向上させるものである。
【0016】
さらに、宛先スナップショットが更新される速度は、変更データをソースから宛先のアクティブファイルシステムへ送信可能な速度にも、依存する場合がある。ファイル消去及びファイル変更の効率を向上させる方法も望まれている。
【0017】
【課題を解決するための手段】
本発明は、ソースファイルシステムの2バージョンのスナップショットを構成するブロックのスキャン(スキャナを介した)であって、各スナップショットの論理ファイルブロック索引をスキャンした際に特定されるボリュームブロック番号の差異に基づいて各々のスナップショットにおける変更されたブロックを特定するスキャンを利用して、ソースファイルシステムスナップショットにおける変更を宛先複製ファイルシステムに遠隔非同期複製すなわちミラーリングするためのシステム及び方法を提供することにより、従来技術の欠点を克服する。バージョン間で変更のなかったポインタをバイパスし、Treeの階層における変更を識別するように下方へ移動しながら、ファイルに関するブロックのTreeの中を移動する。これらの変更は、宛先のミラーすなわち複製スナップショットに送信される。この方法によって、通常のファイル、ディレクトリ、inode及び任意の他の階層構造を効率的にスキャンし、それらのバージョン間の差異を判定することが可能になる。
【0018】
例示的実施形態によると、各スナップショットに対する論理ファイルブロックの索引に沿ったスキャナを用いたこのソーススキャンは、2つのソーススナップショット間で変更のあったボリュームブロック番号を探し出す。ディスクブロックが常にディスク上の新たな位置に再書き込みされるので、差異は、個々のブロックの基礎とするinodeの変化を示す。スキャナを用いると、未変更のブロックは、それらのinodeが変更されていないので、有効に見過ごされる。変更のあったブロックをスキャナから受信するinode採集器プロセスを用いて、ソースは、選択されたQtree(または他のボリューム下位構成)に特に関連する変更されたブロックからinodeを取り出す。この採集器プロセスは、2つのスナップショット間でバージョンが変更されたinodeを探し出し、その変更されたバージョンを取り出す。inodeは同じであるがファイルには変更が施されている場合(inodeの生成番号が異なることで分かる)、それぞれのinodeの2つのバージョンを両方とも取り出す。一方のバージョンで変更のあったinodeは他方のバージョンでそれらのinode以外のデータブロックを指し示すので、バージョンが変更された(2つのスナップショット間で)inodeは、キューに入れられ、一連のinodeハンドラ/ワーカーに転送され、該ハンドラが、inodeの「ツリー」の下方へ向かってファイルオフセットをスキャンし(これもスキャナを用いて)、基礎とするブロックにおける差異がそれらのブロックのブロックポインタによって識別されるまでスキャンを続けることにより、基礎とするブロックにおける変化を解決する。非同期(遅延)方法の場合、宛先ファイルシステムの更新のためにネットワークを介して送信されるのは、ツリーの変更だけである。宛先ファイルシステムは、読み出し専用でユーザにエクスポートされる。これによって、複製者だけしか複製ファイルシステムの状態を変更できないことが保証される。
【0019】
例示的実施形態では、変更データのデータストリームのネットワークを介した送信には、ファイルシステム非依存のフォーマットが用いられる。このフォーマットは、一意の識別子を有する単独ヘッダの集合で構成される。ヘッダが後続のデータを指し示す場合もあるし、ストリーム内に関連データが含まれる場合もある。例えば、「消去ファイル」ヘッダの内部には、ソーススナップショットで消去されたファイルに関する情報が含まれる場合がある。先ずディレクトリ活動がすべて送信され、その後ファイルデータが送信される。ファイルデータは、終端ヘッダ(フッタ)が設定されるまで規定のヘッダで分離された様々なサイズの塊で送信される。宛先では、このフォーマットをアンパックし、その中に含まれるinodeをネットワーク上に送信し、それらを新たなディレクトリ構造にマッピングする。受信されたファイルデータブロックは、それらのオフセットに従って対応する宛先ファイルに書き込まれる。inodeマップは、ソースのinode(ファイル)を宛先のinode(ファイル)にマッピングするマップを格納する。inodeマップは、生成番号も保持する。(inode番号、生成番号)のタプルによって、システムは、ファイルに対して高速アクセスするためのファイルハンドルを作成することが可能になる。また、このタプルによってシステムは、ファイルが消去された際の変化を追跡し、そのinode番号を新たに作成したファイルに再割り当てすることが可能になる。宛先での新たなディレクトリツリーの作成を容易にするため、宛先ミラープロセスの最初のディレクトリステージは、前記フォーマットでソースディレクトリ情報を受信し、消去されたファイルまたは移動されたファイルをすべてテンポラリなすなわち「一時的な」ディレクトリに移動する。移動されたそれらの一時的ファイルは、一時的ディレクトリからそれらのファイルが移動された先のディレクトリにハードリンクされる。新たに作成されたソースファイルがマップに入れられ、そのディレクトリツリーに組み込まれる。ディレクトリツリーが作成された後、ファイルデータの転送を開始する。ソースからのファイルデータに対する変更は、対応する複製ファイル(inodeマップによって識別される)に書き込まれる。データストリーム転送が完了すると、一時的ディレクトリを消去し、リンク先のないあらゆるファイル(様々な消去されたファイルを含む)を永久に消去する。一実施形態では、複数の個別のソースQtree、または、異なるソースボリュームから作成された他の下位組織を、1つの宛先ボリューム上に複製/ミラーリングすることができる。
【0020】
本発明は、複製された宛先ファイルシステムスナップショットをソースファイルシステムスナップショットの変化分を用いて更新するためのシステム及び方法において、宛先アクティブファイルシステム上で変更されたファイル及び消去されたファイルをそれらのファイルが再利用されるまでずっと一時的ディレクトリに関連付けておくことを可能にするテンポラリすなわち「一時的」ディレクトリを用いて、宛先上でのソース更新情報からの新たなディレクトリツリーの作成を容易にすることによって、従来技術の欠点を克服する。さらに、ソースinode番号から宛先inode番号へのマッピングを行なうinodeマップを宛先上に設けることで、inode/生成番号のタプルを用いた宛先ツリーの作成を容易にしている。このinodeマップにより、ソースファイルシステムと宛先との再同期が可能になる。また、このinodeマップによって、2以上の宛先スナップショットを、それら各々のソースを有するマップに基いて、互いに関連付けることが可能になる。
【0021】
例示的実施形態では、ファイルシステム非依存のフォーマットを用いて、ソースの基礎スナップショット及び差分スナップショットに関して変更のあったファイルデータブロックのデータストリームが送信される。受信したファイルデータブロックは、それらのオフセットに従って対応する宛先ファイルに書き込まれる。inodeマップは、ソースのinode(ファイル)を宛先のinode(ファイル)にマッピングするマップを格納する。inodeマップは、生成番号も保持する。(inode番号、生成番号)のタプルによって、システムは、ファイルに対して高速アクセスするためのファイルハンドルを作成することが可能になる。また、このタプルによってシステムは、ファイルが消去された際の変化を追跡し、そのinode番号を新たに作成したファイルに再割り当てすることが可能になる。宛先での新たなディレクトリツリーの作成を容易にするため、宛先ミラープロセスの最初のディレクトリステージは、前記フォーマットでソースディレクトリ情報を受信し、消去されたファイルまたは移動されたファイルをすべてテンポラリなすなわち「一時的な」ディレクトリに移動する。移動されたそれらの一時的ファイルは、一時的ディレクトリからそれらのファイルが移動された先のディレクトリにハードリンクされる。新たに作成されたソースファイルがマップに入れられ、そのディレクトリツリーに組み込まれる。ディレクトリツリーが作成された後、ファイルデータの転送を開始する。ソースからのファイルデータに対する変更は、対応する複製ファイル(inodeマップによって識別される)に書き込まれる。データストリームの転送が完了すると、一時的ディレクトリを消去し、リンク先のないあらゆるファイル(様々な消去されたファイルを含む)を永久に消去する。一実施形態では、複数の個別のソースQtree、または、異なるソースボリュームから作成された他の下位構成を、1つの宛先ボリューム上に複製/ミラーリングすることができる。
【0022】
別の例示的実施形態では、複製ファイルシステムそれ自体のスナップショットを作成することにより、第1のエキスポートされたスナップショットを作成する。この第1のエキスポートされたスナップショットは第1の状態に対応する。複製スナップショットがさらに変更または更新された後、天災や通信障害が発生した場合、複製ファイルシステムに対するそれ以上の変更を停止/凍結し、続いて、凍結された複製ファイルシステムから第2の状態を表す第2のエキスポートされたスナップショットを作成する。複製ファイルシステムは、第2の状態と第1の状態とのデータの差異を判定し、それらの変化分を用いて第1の状態を再現することにより、第2の状態から第1の状態に「巻き戻す」ことができる。
【0023】
さらに別の例示的実施形態では、ソーススナップショットから転送されたinodeを、inodeマップを用いて宛先にある複製/ミラーファイルシステムのinodeにマッピングし、ソースの状態と宛先の状態とを再同期させる。宛先は新たな「ソース」になり、古い「ソース」に対するinodeマップの転送が新たな「宛先」にネゴシエートされる。受信した古いinodeマップは、ソース上に格納され、反転手順によってアクセスされて、新たなソースのinode数に等しいN個のinodeを有する新たな宛先マップが生成される。次いで新たな宛先は、新たなソースエントリに関連する各宛先について、その格納されたソースマップからエントリを可能であれば作成する。関連する生成番号もマッピングされ、これによって必要なファイルアクセスタプルが生成される。新たなソース索引上で新たな宛先をもたないエントリにはすべてゼロエントリとしてマークが付される。反転inodeマップが完成すると、新たなソースはその変更されたデータで新しい宛先を更新できるようになる。
【0024】
関連実施形態では、同じソースの2つの複製/ミラースナップショットが互いに鏡像関係になるようにすることができる。上記反転実施形態のように、新たな「ソース」(古い複製)がそのinodeマップを宛先システムに転送する。次いで宛先システムは、2つのシステムのinode間の関係を判定する。「連想」プロセスは、両方のinodeマップを同時に調べる(例えば、inode番号単位で同時に)。このプロセスは、元のソースからの各inodeについて、inodeマップの各々から「宛先inode/生成」を取り出す。次いでこのプロセスは、新たなソースを新たなinodeマップの適当なマップ索引として扱う。このプロセスは、新しいソース生成番号を、宛先inode/生成とともに格納する。
【0025】
【発明の実施の形態】
A.ネットワーク及びファイルサーバ環境
さらなる背景として、図3は、本発明に各々有利に用いられる、ソースファイルサーバ310及び宛先ファイルサーバ312からなる一対の相互接続されたファイルサーバを有するストレージシステム環境300を示す略ブロック図である。説明上、このソースファイルサーバは1以上のソースボリューム314を管理するネットワークコンピュータであり、ソースボリューム314の各々がストレージディスク360のアレイ(以下で更に説明する)を有している。同様に、宛先ファイラー312も、ディスク360のアレイから構成される1以上の宛先ボリューム316を管理する。ソースファイルサーバと宛先ファイルサーバ、すなわちファイラーは、ローカルエリアネットワークや周知のインターネット等のワイドエリアネットワークで構成されるネットワーク318を介して接続される。各ファイラー310、312に含まれる適当なネットワークアダプタは、ネットワーク318を介した通信をサポートする。ここでも説明上、ソースファイラー及び宛先ファイラー310、312の各々における似たような構成要素は、類似の参照符号で示している。本明細書で用いられるように、「ソース」という用語は本発明の対象データの移動元の場所として大まかに定義され、「宛先」という用語はデータの移動先の場所として大まかに定義される。ネットワークで接続されたソースファイラー及び宛先ファイラーは本明細書で用いられるソース及び宛先の一例であり、ソース及び宛先は、ダイレクトリンク、すなわちループバック(ローカルなソースと宛先の間でデータストリームを伝達するための単一コンピュータ内部の「ネットワーク」構成)によってリンクされたコンピュータ/ファイラーである場合もあり、その場合ソースと宛先は同じファイラーになる。以下で更に説明するように、ソース及び宛先は、ボリュームのソース下位構成及びボリュームの宛先下位構成であるものとして広く解釈される。実際、少なくとも1つの特別な場合、ソース下位構成及び宛先下位構成は、様々な時点で同じものになる場合がある。
【0026】
ネットワーク接続されたソースファイラー及び宛先ファイラーからなる一対の例の場合、各ファイラー310及び312には、スタンドアロンのコンピュータを含めて、任意のタイプの専用コンピュータ(例えばサーバ)または汎用コンピュータを用いることができる。ソースファイラー及び宛先ファイラー310、312の各々は、システムバス345で相互接続されたプロセッサ320、メモリ325、ネットワークアダプタ330及びストレージアダプタ340を含む。また各ファイラー310、312は、情報をディスク上でディレクトリ及びファイルの階層構造として論理編成するファイルシステムを実現するストレージオペレーティングシステム400(図4)も含む。
【0027】
当業者であれば、本明細書に記載する本発明の方法は、ストレージシステムとして実現されたスタンドアロンのコンピュータを含めて、任意のタイプの専用コンピュータ(例えばファイルサービス装置)または汎用コンピュータに適用できることが分かるであろう。そのため、ファイラー310及び312は各々、大まかに、及び代替として、ストレージシステムと呼ばれる場合もある。また、本発明の教示は様々なストレージシステムアーキテクチャに適用することができ、限定はしないがそれらのアーキテクチャには、ネットワークに取り付けられたストレージ環境、ストレージエリアネットワーク、及び、クライアント/ホストコンピュータに直接取り付けられたディスクアセンブリなどが含まれる。
【0028】
例示的実施形態では、ソフトウェアプログラムコードを記憶するため、メモリ325には、プロセッサ及びアダプタによってアドレス指定可能な記憶場所が含まれる。メモリは、ランダムアクセスメモリ(RAM)の形態に構成され、電源サイクルまたはその他リブート処理によってクリアされるのが通常である(すなわち、メモリは「揮発性」メモリである)。次に、プロセッサ及びアダプタは、そのソフトウェアコードを実行してデータ構造を操作するように構成された処理要素及び/又は論理回路で構成される。一般に、ストレージオペレーティングシステム400は、その一部がメモリに存在し、処理要素によって実行され、とりわけファイラーが実施するファイルサービスをサポートする記憶処理を呼び出すことによって、ファイラーの機能を構成する。当業者であれば、本明細書に記載する本発明の方法に関するプログラム命令の格納及び実行には、様々なコンピュータ読み取り可能な媒体を含めて、他の処理手段及び記憶手段を用いることも可能であることが分かるであろう。
【0029】
ネットワークアダプタ330は各ファイラー310、312をネットワーク318に接続するのに必要な機械回路、電気回路及び信号回路を含み、ネットワーク318はポイント・ツー・ポイント接続や、ローカルエリアネットワーク等の共用媒体からなる。さらに、ソースファイラー310は、クライアント/サーバモデルの情報配送に従って、宛先ファイラー312と対話することができる。従って、例えばTCP/IPその他のネットワークプロトコル形態にカプセル化されたパケット355をネットワーク318を介して交換することにより、クライアントはファイラーのサービスを要求することができ、ファイラーはクライアントから要求されたサービスの結果を返すことができる。
【0030】
ストレージアダプタ340は、ファイラー上で実行されているストレージオペレーティングシステム400(図4)と協働して、クライアントから要求された情報にアクセスする。この情報は、ストレージアダプタ340を介して各ファイラーに取り付けられたディスク360上に格納されている場合もあるし、本明細書で定義されるようなストレージシステムの他のノードに格納されている場合もある。ストレージアダプタ340は、従来の高性能ファイバーチャネルシリアルリンク接続形態等、I/O相互接続構成によってディスクに接続するための入出力(I/O)インタフェース回路を有している。情報はストレージアダプタによって取得され、以下で詳しく説明するように、その情報をパケットに成形して宛先サーバへ送信する場合、システムバス345を介してネットワークアダプタ330に転送する前に、スナップショット手順の一部としてプロセッサ320によって処理される。
【0031】
各ファイラーは、ネットワークアダプタ330を介して1以上のクライアント370と相互接続される場合もある。クライアントは、ファイルサービスの要求をソースファイラー及び宛先ファイラー310,312のそれぞれに送信し、それらの要求に対する応答をLANその他のネットワーク(318)を介して受信する。データは、クライアントと個々のファイラー310、312との間で、共通インターネットファイルシステム(CIFS)プロトコルまたはNFS等の他の適当なプロトコルのカプセル化として定義されたデータパケット374を用いて転送される。
【0032】
一例示的なファイラー実施形態では、各ファイラー310,312は、データのフォールトトレランスなバックアップを可能にする不揮発性ランダムアクセスメモリ(NVRAM)335を含む場合があり、ファイラートランザクションの完全性を確保して電源故障その他の故障によるサービス停止を切り抜けることができる場合がある。このNVRAMのサイズは、ファイラーの実施形態及び機能に応じて決まる。通常は、特定時間(例えば数秒分)のトランザクションのログをとるのに十分なだけのサイズにする。各クライアント要求が完了した後、その要求の結果を要求しているクライアントに返す前に、NVRAMはバッファキャッシュと並行して満たされる。
【0033】
一例示的実施形態では、ディスク360は複数のボリューム(例えばソースボリューム314及び宛先ボリューム316)に配置され、各ボリュームがそのボリュームに関連するファイルシステムを有するようになっている。これらのボリュームは、各々1以上のディスク360を有する。一実施形態では、好ましいRAID4構成に従って、物理ディスク360がRAIDグループに構成され、いくつかのディスクがストライプ化されたデータを格納し、いくつかのディスクがそのデータについて個別パリティを格納する場合がある。しかしながら、他の構成(例えばパリティが複数のストライプに分散されたRAID5など)も考えられる。この実施形態の場合、最小で、1台のパリティディスクと1台のデータディスクを使用する。しかしながら、典型的な実施形態では、RAIDグループ1つ当たり3台のデータディスクと1台のパリティディスクが含まれ、1ボリューム当たり複数のRAIDグループが含まれる。
【0034】
B.ストレージオペレーティングシステム
ディスク360に対する一般的なアクセスを容易にするため、ストレージオペレーティングシステム400(図4)は、情報をディスク上でディレクトリ及びファイルの階層構造として論理編成するWrite-anywhereファイルシステムを実施する。「ディスク上」の各ファイルはデータ等の情報を格納するように構成されたディスクブロックの集まりとして実現され、ディレクトリは他のファイル及びディレクトリが格納された特別な形態のファイルとして実現される。上で説明及び定義したように、本明細書で説明する例示的実施形態の場合、ストレージオペレーティングシステムはカリフォルニア州サニーベイルにあるネットワークアプライアンス社から入手可能なNetApp Data ONTAP(R)オペレーティングシステムであり、このオペレーティングシステムはWrite Anywhereファイルレイアウト(WAFL(R))ファイルシステムを実施する。任意の適当なファイルシステムを使用することが可能であるから、「WAFL」という用語を用いた場合であっても、この用語は本発明の教示に適合可能な任意のファイルシステムを意味するように広く解釈すべきである。
【0035】
例示的ファイラーの各々について、好ましいストレージオペレーティングシステムの構成をまず簡単に説明する。しかしながら、明らかに、本発明の原理は様々な代替ストレージオペレーティングシステムアーキテクチャを用いて実施することもできると考えられる。さらに、ソースファイラー及び宛先ファイラー310、312の各々で実施される特定の機能は、異なる場合もある。図4に示すように、例示的ストレージオペレーティングシステム400は、ネットワークドライバ(例えばイーサネット(R)ドライバ)のメディアアクセス層を含む、一連のソフトウェア層から構成される。このオペレーティングシステムは更に、インターネット・プロトコル(IP)層410、並びに、IP層がサポートする搬送手段であるトランスポート・コントロール・プロトコル(TCP)層415及びユーザ・データグラム・プロトコル(UDP)層420を含む。ファイルシステムプロトコル層は、複数プロトコルのデータアクセスを可能にするため、CIFSプロトコル425、NFSプロトコル430、及び、ハイパー・テキスト・トランスファー・プロトコル(HTTP)プロトコル435をサポートする。さらに、ストレージオペレーティングシステム400は、RAIDプロトコル等のディスクストレージプロトコルを実施するディスクストレージ層440、及び、スモール・コンピュータ・システム・インタフェース(SCSI)等のディスク制御プロトコルを実施するディスクドライバ層445を含む。
【0036】
これらのディスクソフトウェア層とネットワークプロトコル層及びファイルシステムプロトコル層との橋渡しをするのが、ストレージオペレーティングシステム400のファイルシステム層450である。一般にファイルシステム層450は、ディスク上で例えば4キロバイト(KB)のデータブロックを用いたブロックベースのフォーマット表現を有するファイルシステムを実施し、inodeを用いてファイルを表現する。このファイルシステムは、トランザクション要求に応じて、要求されたデータが「コア内」すなわちファイラーのメモリ325に存在しない場合、そのデータをボリュームからロード(取得)する処理を行なう。情報がメモリに存在しない場合、ファイルシステム層450は、inode番号を用いてinodeファイル内に索引を付け、適当なエントリにアクセスしてボリュームブロック番号を取得する。次いでファイルシステム層450は、そのボリュームブロック番号をディスクストレージ(RAID)層440に渡し、RAID層440がそのボリュームブロック番号をディスクブロック番号にマッピングして、そのディスクブロック番号をディスクドライバ層445の適当なドライバ(例えば、ファイバーチャネルディスク相互接続上で実施されるSCSIのカプセル化)に送信する。次いでディスクドライバは、ディスクのそのディスクブロック番号にアクセスして要求されたデータをメモリ325にロードし、ファイラー310、312で処理する。要求が完了すると、ファイラーは、CIFS規格に規定されている従来の受領応答パケットを、個々のネットワーク接続372を介してクライアント370に返す。
【0037】
ファイラーで受信されたクライアント要求についてデータストレージアクセスを実施しなければならない上記ストレージオペレーティングシステムを通るソフトウェア「パス」470は、代替としてハードウェアで実施することも、あるいはハードウェアとソフトウェアの組み合わせで実施することもできる。従って、本発明の代替実施形態では、ストレージアクセス要求データパス470が、フィールド・プログラマブル・ゲートアレイ(FPGA)や特定用途向け集積回路(ASIC)の内部に実現される論理回路として実施される場合がある。この種のハードウェア実施形態は、クライアント370が発行したファイルシステム要求パケット374に応答してファイラー310、312によって提供されるファイルサービスの性能を向上させることができる。
【0038】
ファイルシステム層450の上に重なるのは、本発明の例示的形態によるスナップショット・ミラーリング(複製)・アプリケーション490である。以下で詳細に説明するように、(ソース側では)このアプリケーションは、スナップショットをスキャンして、スナップショットの変化をソースファイラー310から宛先ファイラー312へネットワークを介して送信する働きがある。(宛先側では)このアプリケーションは、受信した情報を基にしてミラースナップショットを更新する働きがある。従って、ソースアプリケーション及び宛先アプリケーションの特定機能は、以下で説明するように、異なる場合がある。スナップショット・ミラーリング・アプリケーション490は、TCP/IP層415,410に対する直接リンク492、及びファイルシステムスナップショット手段(480)に対する直接リンク494に示すように、通常の要求パス470の外側で動作する。このアプリケーションは、ファイルシステム層と対話してファイルの受領応答を受信するので、ファイルベースのデータ構造(具体的にはinodeファイル)を用いてソースのスナップショットを宛先に複製することができる。
【0039】
C.スナップショット手順
例示のWAFLファイルシステムに固有のSnapshot(R)機能については、David Hitz他による「File System Design for an NFS File Server Appliance」と題したTR3002に詳しい説明があり、この文献はここで参照することにより本明細書に取り込まれる。「Snapshot」がネットワークアプライアンス社の登録商標であることに注意して欲しい。この用語は、この特許の目的で、Persistent Consistency Point(CP)Imageを指すために用いられている。Persistent Consistency Point Image(PCPI)とは、記憶装置(例えばディスク等)に格納されたストレージシステムをある時点で表現したものであって、特にアクティブファイルシステムをある時点で表現したものであり、そのPCPIを他の時点で作成されたPCPIから区別する名称その他一意の識別子を有する。また、PCPIには、そのイメージが作成された時点でのアクティブファイルシステムに関するその他の情報(メタデータ)が含まれる場合もある。「PCPI」という用語と「スナップショット」という用語は、ネットワークアプライアンス社の商標権から外れることなく、交換可能に用いられる。
【0040】
スナップショットは、何らかの規則的なスケジュールで作成されるのが一般的である。このスケジュールは大きな変化の影響を受ける。さらに、ファイラーに保持されるスナップショットの数も極めて不定である。格納手段が1つの場合、複数の最近のスナップショットは連続して格納し(例えば4日分のスナップショットを各々4時間の間隔で)、複数のそれよりも古いスナップショットはもっと時間間隔を広げて(例えば前の週に関する日毎のスナップショット及び前の数ヶ月についての週毎のスナップショットなど)保持する場合がある。スナップショットは、アクティブファイルシステムと共に格納され、以下で詳しく説明するように、ストレージオペレーティングシステム400またはスナップショットミラーアプリケーション490から要求があったときに、ファイラーメモリのバッファキャッシュに呼び出される。しかしながら、本発明の教示の中で、様々なスナップショット作成手段及び時間調節手段を用いることができると考えられる。
【0041】
例示的実施形態による例示的ファイルシステムinode構造500を図5に示す。このinodeファイルのinode、すなわちもっと普通に「ルート」inode505は、所与のファイルシステムに関するinodeファイル508を表す情報を保持している。この例示的ファイルシステムinode構造の場合、ルートinode505は、inodeファイル間接ブロック510へのポインタを保持している。inodeファイル間接ブロック510は、1以上のinodeファイル直接ブロック512を指しており、inodeファイル直接ブロック512の各々はinodeファイル508を構成するinode515への一連のポインタを保持している。図示の問題となるinodeファイル508はinode515を構成するボリュームブロックに編成され、inode515はファイルデータ(または「ディスク」)ブロック520A、520B及び520Cへのポインタを保持している。この図の場合、単にinode自体がファイルデータブロックへのポインタを保持しているように単純化して図示している。例示の実施形態では、ファイルデータブロック520(A〜C)の各々は、4キロバイト(KB)のデータを格納するようになっている。しかしながら、1つのinode(515)によって所定数を超えるファイルデータブロックが参照される場合、1以上の間接ブロック525(仮想的に示す)が用いられるということに注意して欲しい。それらの間接ブロックは、それらに関連するファイルデータブロックを指す(図示せず)。あるinode(515)が間接ブロックを指している場合、そのinodeがさらにファイルデータブロックも指すことはありえず、その逆も言える。
【0042】
ファイルシステムは、所与のファイルシステムのスナップショットを作成する場合、図6に示すようなスナップショットinodeを作成する。スナップショットinode605は、実質的にファイルシステム500のルートinode505の複製である。従って例示のファイルシステム構造600は、図5に図示したものと同じinodeファイル間接ブロック510、inodeファイル直接ブロック512、inode515、及び、ファイルデータブロック520(A〜C)を有する。ユーザがファイルデータブロックを変更した場合、ファイルシステム層は、その新たなデータブロックをディスクに書き込み、新たに作成したブロックを指すようにアクティブファイルシステムを変更する。ファイル層は、その新たなデータをスナップショットに保持されるブロックには書き込まない。
【0043】
図7は、ファイルデータブロックが変更された後の例示的inodeファイルシステム構造700を示している。この例の場合、ディスクブロック520Cに格納されたファイルデータが変更された。例示のWAFLファイルシステムは、この変更された内容をディスク上の新たな位置である520C’に書き込む。新たな位置に書き込むため、ディスクブロック(515)に格納されたinodeファイルデータは、ブロック502C’を指すように書き換えられる。この変更によって、WAFLは、515にある変更されたデータについて新たなディスクブロック(715)を割り当てる。同様に、inodeファイル間接ブロック510をブロック710に書き換え、直接ブロック512をブロック712に書き換え、新たに変更されたinode715を指すようにする。従って、ファイルデータブロックの変更が終った後、スナップショットinode605は、元のinodeファイルシステム間接ブロック510へのポインタを保持し、inode515へのリンクを有している。このinode515は、元のファイルデータブロック520A、520B、及び、520Cへのポインタを保持している。しかしながら、新たに書き込まれたinode715は、未変更のファイルデータブロック520A及び520Bへのポインタしか有していない。またinode715は、アクティブファイルシステムの新たな構成を表す変更されたファイルデータブロック520C’へのポインタも保持している。新たなファイルシステムルートinode705は、新たな構造700を表すように確立される。何らかのスナップショットを作成したブロック(例えばブロック510、5151及び520C)にあるメタデータは、それらがすべてのスナップショットから開放されるまで、再利用や上書きから保護されることに注意して欲しい。従って、アクティブファイルシステムルート705が新たなブロック710、712、715及び520C’を指していても、古いブロック510、515及び520Cは、スナップショットが完全に開放されるまで保持される。
【0044】
本発明の例示的実施形態では、ソースは、2つのスナップショット、すなわち、宛先上の複製ファイルシステムのイメージを表す「ベース」スナップショットとソースシステムが宛先に複製しようとしているイメージである「差分」スナップショットとを用いて、宛先にミラーされたリモートスナップショットに必要な更新を実施する。一例では、ソースの立場から、差分スナップショットは最新のスナップショットを含み、ベーススナップショットはあまり最近のものではないスナップショットを含み、最新の変更の集合を宛先に提供することを可能にする。次にこの手順について、さらに詳しく説明する。
【0045】
D.遠隔ミラーリング
スナップショットを作成するための一般的な手順の説明が終わったので、ソースファイラー310(図3)から遠隔の宛先ファイラー312へのスナップショット情報のミラーリングについてさらに詳しく説明する。上で概説したように、ボリューム全体における変更されたブロックの比較に基づくスナップショットの変更差分の伝送は、ファイルシステムスナップショット全部ではなく、データの変更差分だけを転送し、小さくて高速な変更を可能にするので、有利である。しかしながら、本発明の例示的実施形態によると、宛先ミラースナップショットの遠隔差分更新について、さらに効率的及び/又は多用途な手順が考えられる。本明細書で用いられるように、「複製スナップショット」、「複製スナップショット」または「ミラースナップショット」という用語は、適当なスナップショットを保持する宛先ボリューム上のファイルシステムを大まかに指すものとして解釈すべきである(例えばスナップショットのスナップショットが含まれる)。
【0046】
上で簡単に述べたように、この手順は、Qtreeと呼ばれるボリュームの下位構成の利点を得ることができる。Qtreeは、従来のUNIX(R)ファイルシステムやWindows(R)ファイルシステムにおけるパーティションサイズによるデータの集まりに対する制限と同様の働きがあるが、ディスク上の特定領域のブロックに結び付けられていないので、制限の実質的変更について柔軟性がある。ディスクの特定の集まり(例えばn台のディスクからなるRAIDグループ)にマッピングされ従来のパーティションに比較的似ているボリュームとは異なり、Qtreeは、ボリュームよりも高レベルで実施されるので、高い柔軟性を提供することができる。Qtreeは、基本的に、ストレージオペレーティングシステムのソフトウェアにおける抽象概念である。実際、各ボリュームは複数のQtreeを有する場合がある。Qtreeの粒度は、わずか数キロバイトの記憶容量にすることができる。Qtree構造は、適当なファイルシステム管理者によって定義することもできるし、かかる制限を設定する適当な権限を有するユーザによって定義することもできる。
【0047】
上で説明したQtree構成は例示的なものであり、本発明の原理はボリューム全体の方法を含めて、様々なファイルシステム構成に適用することができることに注意して欲しい。Qtreeが例示の実施形態による便利な構成であることの理由の一つは、inodeファイルに識別子を利用できるからである。
【0048】
宛先におけるソースの複製のためにデータを宛先に転送する元になる2つのソーススナップショットにおける変更を計算する処理についてさらに説明する前に、図5〜図7に示すファイルブロック構造をもう一度大まかに参照しておく。ファイルのあらゆるデータブロックは、ディスクブロック(又はボリュームブロック)にマッピングされる。あらゆるディスク/ボリュームブロックは、個別のボリュームブロック番号(VBN)を用いて一意に数えられる。各ファイルは、それらのデータブロックへのポインタを保持する1つのinodeで表現される。これらのポインタはVBNであり、inodeの各ポインタフィールドは内部にVBNを有し、ファイルシステム(またはディスク制御)層に対する要求により適当なディスク/ボリュームブロックを読み出すことによって、ファイルのデータがアクセスされる。このディスクブロックのVBNは、inodeのポインタフィールドに配置される。スナップショットは、ある時点でinodeおよびそのinodeの中のVBNフィールドすべてを取り込む。
【0049】
inode内のVBN「ポインタ」の最大数を超えてスケーリングするため、「間接ブロック」が用いられる。実質的に、ディスクブロックは、データブロックのVBNが割り当てられ、それらVBNで満たされ、次いでinodeポインタがその間接ブロックを指す。大きなツリー構造を作ることができる複数階層の間接ブロックが存在する場合がある。間接ブロックは間接ブロック内のVBNが変更されるたびに毎回、通常のデータブロックと同じ方法で変更され、その間接ブロックの変更されたデータについて新たなディスク/ボリュームブロックが割り当てられる。
【0050】
1.ソース
図8は、ソース環境800内部のスナップショットinodeの例示的ペアを示している。例示的実施形態において、これらは、2つのスナップショットのinodeファイル、すなわち、ベース810及び差分812を表している。これら2つのスナップショットは2つの時点で作成されたものであり、ベースは複製の現在のイメージを表し、差分はその複製を更新するイメージを表すものであることに注意して欲しい。2つのスナップショットの差異によって、いずれの変更を作成して遠隔の複製/ミラーに送信すべきかが決まる。各inodeファイルは、ストレージオペレーティングシステムのスナップショットマネージャ(図4の480)による指示に従って、ソースファイルシステムのディスク上のバッファキャッシュからソースファイルサーバメモリのバッファキャッシュにロードされる。一実施形態において、ベーススナップショット及び差分スナップショットは、ストレージオペレーティングシステムで使用されるときにストレージオペレーティングシステムにロードされる(一度に全部ではなく)。各スナップショットinodeファイル810、812は、一連のストレージブロック814に編成される。この例の場合、ベースinodeファイル810はボリュームブロック番号5、6、及び7で記されたストレージブロックを含み、差分スナップショットinodeファイルは例えばボリュームブロック番号3、5、6、及び8のボリュームブロック番号のストレージブロックを含む。各ブロックの内部は、所定数のinode816に編成される。ボリュームブロックには、それらが基礎にしている論理ファイルブロックの配置に基づいて、図示の順番で索引が付される。
【0051】
Write-anywhereファイルレイアウトの例の場合、ストレージブロックは、直ぐに上書きされたり、再利用されたりすることがない。従って、一連のボリュームブロックで構成されたファイルを変更すれば、常に新たな(新しく書き込まれた)ボリュームブロック番号が発生することになるので、その番号は古いブロックに対する適当な論理ファイルブロックオフセットとして検出することができる。ベーススナップショットinodeファイルと差分スナップショットinodeファイルの間の索引の所与のオフセットに変更されたボリュームブロック番号が存在することは、基礎とするinodeのうちの1以上、及び、そのinodeが指しているファイルに変更があったことを意味している。しかしながら、本システムはinodeやポインタの変更のインジケータに他のインジケータを用いることもでき、これは固定位置ファイルシステムが実施される場合に望ましい。
【0052】
スキャナ820は、索引をサーチし、ボリュームブロック番号その他の識別子を比較して、変更されたベース/差分inodeファイルスナップショットブロックを見付ける。図8の例では、ベーススナップショットinodeファイル810のブロック4は、ファイルスキャン順番で、差分スナップショットinodeファイル812のブロック3に対応している。これは、1以上の基礎とするinodeの変更を示している。さらに、ベーススナップショットinodeファイルのブロック7は、差分スナップショットinodeファイルのブロック8のように見える。両ファイルにおけるブロック5及び6は、変更されていないので、何もinodeその他の情報を更に処理することなく、高速にスキャンされる。従って、両スナップショットにおいて同じ索引でスキャンされたブロックは有効にバイパスして、スキャン時間を削減することができる。
【0053】
変更があったものとして識別されたブロック対(例えばブロック7及び8)は、inode採集器プロセス830を含むソースプロセスの残りの部分に転送される。inode採集器は、転送されたブロックの中から(QtreeIDに基づいて)ミラーされている選択されたQtreeの一部である特定のinodeを識別する。この例の場合、QtreeID Q2が選択されているので、inodeファイルメタデータにこの値を有するinodeが「取り出され」、さらに処理される。選択さえたQtreeの一部ではない他のinode(例えばQtreeIDがQ1及びQ3のinode)は、採集器プロセス830によって破棄または無視される。複数のQtreeIDを選択し、選択されたQtree関連のうちの1つを有するinodeのグループを、採集器プロセスによって抜き出すこともできる。
【0054】
次いで、変更されたブロックから適切に「取り出された」inodeは、変更されたinode842の実行中リストすなわちキュー840に入れられる。これらのinodeは、図示のように不連続の番号で記される。キュー840内の各inodeは、inodeハンドラまたはワーカー850、852及び854に渡され、それらのinodeワーカーが利用できるようになる。図8Aは、inode採集器プロセス830が与えられたinodeをワーカーで処理するためにキューに渡すか否かを判定するのに使用するルールの基本集合の詳細を示す表835である。
【0055】
inode採集器プロセス830は、(1)対象inode(与えられたinode番号)のベーススナップショットのバージョンが選択されたQtreeに割り当て及び配置される(ボックス860)のか、(2)対象inodeの差分スナップショットのバージョンが選択されたQtreeに割り当て及び配置される(ボックス862)のかを問い合わせる。ベースバージョン及び差分バージョンがいずれも選択されたQtreeに割り当て及び配置されない場合、両inodeを無視し(ボックス864)、inodeバージョンの次のペアを参照する。
【0056】
ベースinodeは選択されたQtreeに割り当て及び配置されないが、差分inodeは選択されたQtreeに割り当て及び配置される場合、これは差分ファイルが追加されたことを意味しているので、適当なinode変更をワーカーに送信する(ボックス866)。同様に、ベースinodeは選択されたQtreeに割り当て及び配置されるが、差分inodeは選択されたQtreeに割り当て及び配置されない場合、これはベースファイルが消去されたことを意味しているので、これがデータストリームの形で宛先に送信される(ボックス868)。
【0057】
最後に、ベースinode及び差分inodeが両方とも選択されたQtreeに割り当て及び配置される場合、プロセスは、ベースinodeと差分inodeが同じファイルを表すものであるか否かを問い合わせる(ボックス870)。それらが同じファイルを表している場合、そのファイルまたはそのメタデータ(パーミッション、所有者、パーミッションなど)は変更された可能性がある。これは、採集器プロセスによって検査されている様々なバージョンのinode番号に対する異なる生成番号で示される。この場合、変更されたファイルが送信され、以下で説明するように、inodeは、正確な変更を判定するためにバージョンの比較を行なうように働く(ボックス872)。ベース及び差分がまったく同じファイルではない場合、これは、ベースファイルの消去及び差分ファイルの追加を意味している(ボックス874)。そのような場合、採集器によって差分ファイルの追加がワーカーキューに記入される。
【0058】
図8Bは、ベーススナップショット810における変更されたブロックの例(ブロック10)、及び、差分スナップショット812における変更されたブロック(ブロック12)の例の各々に含まれる情報の詳細を示している。inode2800は、ベースinodeファイルにも差分inodeファイルにも割り当てられていない。これは、そのファイルがファイルシステムに追加されたことを意味している。また、inode採集器プロセスは、このinodeが適当なQtree Q2(この例の場合)に配置されていることも記している。このinodeは、ファイル全体が新しいものであるという注釈とともに、変更されたinodeキューに送信され、処理される。
【0059】
inode2801は、両方のinodeファイルに割り当てられている。このinodeは、適当なQtree Q2に配置され、2バージョンのこのinodeが同じ生成番号を共有している。この時点ではファイルデータ自体に変更があったか否かが分からないので、inode採集器はこのペアを変更されたinodeキューに送信し、ワーカーがいずれのデータに変更があったかを判定する。inode2802は、ベースinodeファイルに割り当てられているが、差分inodeファイルには割り当てられていない。このinodeのベースバージョンは、適当なQtree Q2にあった。これは、このinodeが消去されたことを意味している。inode採集器は、同様にこの情報をワーカーに送信する。最後に、inode2803は、ベースinodeファイルに割り当てられていて、差分inodeファイルにも再割り当てされている。inode採集器830は、2つのバージョン間で(#1と#2の間で)生成番号が変更されたからであることから、これを判断することができる。このinodeが表すファイルはinode2800と同様にQtreeに追加されているので、このinodeは、ファイル全体が新しいものであるという注釈とともに、変更されたinodeキューに送信され、処理される。
【0060】
所与の時点で、所定数のワーカーがキュー840に対して処理を行なう。例示の実施形態の場合、ワーカーの機能は、キュー内のinodeグループに対して並行で行なわれる。つまり、ワーカーは、特に順番なくいったんキューからinodeを取得すると、それらが利用可能になるや否や、さらなるinodeをキューから自由に処理することができる。スキャン820及び採集器830など、他のプロセスも、順番全体の中でインタリーブされる。
【0061】
ワーカーの機能は、ファイル及びディレクトリの各スナップショットのバージョン間の変化を判定することである。上記のように、ソーススナップショットミラーアプリケーションは、2つのスナップショットにおけるinodeの2つのバージョンを分析して、それらのinodeのポインタを比較するようになっている。それらのポインタの2つのバージョンが同じブロックを指している場合、そのブロックは変更されなかったことが分かる。また、間接ブロックへのポインタが変更されなかった場合、その間接ブロックにデータの変更はないので、間接ブロックのポインタが変更されることもありえず、従って、ツリーの下方にあるデータブロックに変更はなかったことになる。これが意味するのは、2つのスナップショット間でほとんど変更されていない巨大なファイルの場合、そのツリー内の各データブロックに対するVBN「ポインタ」を読み飛ばすことにより、それらのデータブロックのVBNに変更があったか否かの確認をスキップすることができるということである。
【0062】
例として、ワーカー850の処理を図9に示す。ワーカー850は、変更のあったinode対を受信すると、各inode(ベース及び差分の各々)910及び912をスキャンして、各々のブロック間でファイルオフセットが一致するか否かを判定する。この例の場合、ブロック6及び7が一致しない。次いで、ブロック6及び7各々の下方へスキャンを続け、基礎とする間接ブロック8/9(920)及び8/10(922)に到達する。ここでも、ファイルオフセット比較は、ブロック8が両方とも共通ブロック930に到達したことを示す(従って変更されていない)。逆に、ブロック9及び10は、オフセットが異なるため一致せず、変更されたブロック940及び942を指している。変更されたブロック942及び上記メタデータは、宛先の複製スナップショット(以下で説明する;図8も参照)に伝送するため、単独で取り出すことができる。例示の実施形態のツリーは4階層の深さまであるが、この手順は、いかなる階層数にも適用することができる。また、ツリーは複数の変更されたブランチを含む場合があり、ワーカーは、それらの変更がすべて識別されるまで、それらのブランチの各々を再帰的にたどらなければならない場合もある。従って、各inodeワーカーは、以下に説明する方法で伝送するために、それらの変更をネットワークに提供する。特に、古い、消去されたブロックに関する新たなブロック及び情報が宛先に送信される。同様に、変更されたブロックに関する情報も送信される。
【0063】
注意して欲しいのは、この例ではほとんどあらゆるデータ構造がファイルになっているので、上記のプロセスは、ファイルデータだけでなく、ディレクトリ、アクセスコントロールリスト(ACL)、及び、inodeファイル自体にも適用することができるということである。
【0064】
さらに注意して欲しいのは、このソース手順は、ボリュームinodeファイル全体を含む、あらゆる粒度のファイルシステム構成に適用することができるということである。本来のQtree構成を用いることにより、そのボリュームの既知のサブセットを複製するための迅速で効率的な方法が得られる。
【0065】
2.ソースと宛先の間の通信
図10を参照すると、ソーススナップショットから複製された宛先スナップショットへの変更の伝送が、概観1000に図示されている。既に説明したように、古いスナップショット及び新たなスナップショットは、対象ボリュームのQtreeその他の選択された下位構成に対応する変更されたinodeを、inode採集器830に提示する。これらの変更されたinodeはキュー840に配置され、次いで、inodeワーカー850、852及び854の集合が、各々のツリーの変更を調べる。inodeワーカーは各々、変更情報を含むメッセージ1002、1004及び1006をソースパイプライン1010に送信する。このパイプラインはファイルシステムデータを1つのデータストリームにパッケージングしてネットワーク層に送信するための手段を実現する方法の一例にすぎないことに注意して欲しい。これらのメッセージは先ず受信器1012にルーティングされ、受信器がこれらのメッセージを収集し、ネットワークを介して送信すべきスナップショット変更情報を含むグループとしてそれらのメッセージをアセンブラ1014に送信する。ここでも、本明細書に記載する「ネットワーク」は、ソースと宛先が同じファイルサーバ、ボリューム上にある場合でも、ソース下位構成から宛先下位構成へのボリューム下位構成(例えばQtree)変更データの伝達を容易にするいかなるものも含むように広く解釈しなければならず、実際、(「SYSTEM AND METHOD FOR REMOTE ASYNCHRONOUS MIRRORING USING SNAPSHOTS」と題する、上で取り込まれた米国特許出願に記載されている巻き戻しの場合では、)異なる時点で同じ下位構成になっている。同じボリュームに戻る経路として用いられる「ネットワーク」の一例は、ループバックである。アセンブラ1014は、ネットワーク318を介して情報のデータストリームを送信するため、宛先が予測及び理解することのできる特別なフォーマット1020を作成する。ネットワーカー1016は、その組み立てられたデータストリームを受信して、それをネットワーク層に転送する。このフォーマットは、TCP/IP等、信頼性の高いプロトコルの中にカプセル化されるのが普通である。カプセル化はネットワーク層で実施することができ、この層が例えばフォーマットされた複製データストリームのTCP/IPパケットを作成する。
【0066】
フォーマット1020について、以下でさらに説明する。概して、このフォーマットの使用は、複数のプロトコル属性(例えば、UNIX(R)のパーミッション、NTのアクセスコントロールリスト(ACL)、複数のファイル名、NTストリーム、ファイルタイプ、ファイル作成/変更など)を有することによって予測される。また、このフォーマットは、ストリーム内のデータ(すなわち、ファイル中の特定データのオフセット位置や、ファイルがファイルオフセット中に空の状態を保つ必要がある「ホール」を有するか否か)を識別ものでなければならない。また、ファイルの名称もこのフォーマットで中継しなければならない。さらに一般的に言うと、このフォーマットは更に、基礎とするネットワークプロトコルや装置(テープやローカルディスク/不揮発性記憶装置の場合)プロトコル及びファイルシステムとは無関係なものにする必要があり、つまり、その情報をシステム「不認識」なものにし、特定のオペレーティングシステムに束縛されないものにすることによって、異なるベンダーのソースシステムと宛先システムがその情報を供給できるようにする必要がある。従って、このフォーマットは、データストリームの外部に何も情報を必要としない自己表現的なものにする必要がある。このような方法で、第1のタイプのソースファイルディレクトリを別のタイプの宛先ファイルディレクトリに直ちに変換することができる。また、ソースオペレーティングシステムまたは宛先オペレーティングシステムに対する新たな改良が古いバージョンの互換性に悪影響を与えないようにする際に、拡張性も可能になる。具体的には、オペレーティングシステムによって認識されないデータ集合(例えば新しいヘッダ)は、必ず無視されるようにするか、あるいは、システムクラッシュその他の望ましくない故障をトリガすることなく予測的方法で処理されるように(すなわち、ストリームが下位互換になる)しなければならない。また、このフォーマットは、ファイルシステム全体の表現も、何らかのファイルまたはディレクトリ内部の変更されたブロック/情報だけの表現も、伝達できるものにしなければならない。さらに、このフォーマットは、ネットワーク及びプロセッサのオーバヘッドを最小限にしなければならない。
【0067】
変更された情報は、ネットワークを介して転送され、宛先パイプライン部分1030で受信される。このパイプラインも、ネットワークからTCP/IPパケットをTCP/IPにカプセル化されたスナップショット複製データストリームフォーマット1020に読み出すためのネットワーカー1032を含む。データ読み取り及びヘッダ分離器1034は、様々なフォーマットヘッダ(以下で説明する)に格納された情報に作用することで、入ってきたフォーマット1020を認識して応答する。ファイル書き込み器1036は、そのフォーマットから取り出したファイルデータを宛先ファイルシステム内の適当な位置に配置する役割がある。
【0068】
宛先パイプライン1030は、データ及びディレクトリ情報を、以下で詳しく説明するメイン宛先スナップショットミラープロセス1040に転送する。宛先スナップショットミラープロセス1040は、受信したスナップショット変更に基づいて宛先側に新たな複製ファイルシステムディレクトリ階層を構築するディレクトリステージ1042から構成される。簡単に説明すると、このディレクトリステージは、受信したフォーマットされた情報に基づいて、ファイルを消去または移動するものである。宛先からソースへのinodeのマップが生成され、更新される。この方法で、ソースファイルシステムのinode番号は、宛先ファイルシステムの対応する(しかしながら通常は異なる)inode番号に関連付けられる。変更または消去されたディレクトリエントリ1052がディレクトリステージ内の適当なディレクトリ再構築ステージで再利用されるか、または複製スナップショットから除去されるまでそれらエントリを維持するため、テンポラリすなわち「一時的」ディレクトリ1050が作成されることに注意して欲しい。さらに、宛先ミラープロセスのファイルステージ1044は、ディレクトリステージで作成したファイルを、関連ファイルヘッダから分離した情報に基づいてデータに格納する。
【0069】
ソーススナップショット変更を編成するフォーマットを、図11及び図12に概略的に示す。例示の実施形態の場合、このフォーマットは、約4KBのブロックに編成される。しかしながら、ヘッダのサイズ及び構成は、実施形態によって様々に異なるものでよい。特定の「ヘッダタイプ」によって識別される4KBヘッダ(図11の符号1100)が存在する。ほぼ2メガバイト(2MB)毎の変更データについて、基本データストリームヘッダ(「データ」)が設けられる。図11を参照すると、4KBの単体ヘッダには、3つの部分、すなわち1KBの汎用部分、2KBの非汎用部分、及び、1KBの拡張部分が含まれる。拡張部分は使用されないが、最近のバージョンでは利用することができる。
【0070】
汎用部分1102には、ヘッダタイプ1110の識別子が含まれる。ヘッダタイプ単体(すなわち、後に関連データを伴わないヘッダ)は、データストリームの開始、データストリームの一部の終端、データストリームの終端、ヘッダにカプセル化された消去されたファイルのリスト、または、NT streamdirの関係を示すことができる。最近のバージョンのWindows(R) NTは、複数のNT「ストリーム」を特定のファイルネームに関連付けることができる。ストリームに関する説明は、Kayuri Patel他による「SYSTEM AND METHOD FOR REPRESENTING NAMED DATA STREAMS WITHIN AN ON-DISK STRUCTURE OF A FILE SYSTEM」と題した米国特許出願第09/891195号に記載があり、その教示はここで参照することにより広く本発明に取り込まれる。また、汎用部分1102には、ヘッダが壊れていないことを確認するためのチェックサム1112も含まれる。さらに、ソース及び宛先が複製の進行を追跡するために用いる「チェックポイント」1114等、その他のデータも設けられる。ヘッダタイプのリストを設けることにより、宛先は比較的容易に下位互換モードで動作することができ、つまり、宛先バージョンの制限内で認識できるヘッダは普通に処理する一方、宛先が理解できないヘッダタイプ(比較的新しいバージョンのソースから供給される)はもっと簡単に無視することができる。
【0071】
ヘッダ1100の非汎用部分1104のデータの種類は、ヘッダタイプに応じて決まる。基本的なヘッダの場合、その非汎用部分には、後続のデータ送信に使用するファイルオフセット(1120)、消去ファイル(ソース側でもう使用しなくなったファイルやその生成番号の変更をリストする単体ヘッダ)、または、その他ヘッダ固有の情報(1124、以下で説明する)に関する情報が含まれる。この場合も、データストリームフォーマット内の適当な位置に様々な単体ヘッダが挿入される。各ヘッダは、データ集合(消去されたファイル等)または後続の情報(ファイルデータ等)を参照するように構成される。
【0072】
図12は、例示の複製データストリームのフォーマット1020をさらに詳細に表したものである。複製データストリームのフォーマットは、「データストリームの開始」という種類の単体データストリームヘッダ1202で始まる。このヘッダには、データストリームの属性を記述するソースによって生成された非汎用部分1104のデータが格納される。
【0073】
フォーマット1020において、次の一連のヘッダは、様々な「パート1」情報(1204)を定義する。重要なのは、送信される各ディレクトリデータ集合の前に、非汎用データを有しない基本ヘッダがくることである。変更されたディレクトリだけが送信され、それらは特定の順番で到着する必要がない。また、何らかの特定ディレクトリからのデータが連続している必要もない。各ディレクトリエントリは、4KBブロックにロードされる。あふれたものは、いずれも新たな4KBブロックにロードされる。各ディレクトリエントリは、後ろに1以上の名称が続くヘッダである。各ディレクトリエントリは、続いてinode及びディレクトリ名を記述する。NTストリームディレクトリも送信される。
【0074】
パート1フォーマット情報1204は、関連ACLを有するあらゆるファイルについてACL情報も提供する。ACLの関連ファイルデータより前にACLを送信することにより、宛先はファイルデータが書き込まれる前にACLを設定することができるようになる。ACLは、「通常の」ファイルフォーマットで送信される。消去ファイル情報(上記の)は、こうした情報と共に1以上の単体ヘッダの非汎用部分1104(もしあれば)に含められて送信される。この情報を前もって送信することにより、ディレクトリ構築機は、移動と消去を区別することができるようになる。
【0075】
パート1フォーマット情報1204は、NTストリームディレクトリ(streamdir)関係情報も保持する。1以上の単体ヘッダ(もしあれば)は、NTストリームを含む宛先ファイルサーバのあらゆる変更されたファイルまたはディレクトリを、それらのストリームに変更があったか否かに関わらず通知する。この情報は、ヘッダ1100(図11)の非汎用部分1104に含められる。
【0076】
パート1フォーマット情報1204は、複製データストリームにおける、シンボリックリンク、名前付きパイプ、ソケット、ブロックデバイス、または、キャラクタデバイスのあらゆる変更について、特別なファイルを含む。それらのファイルは、複製ファイルシステムにファイルを格納する前にその複製ファイルシステムを作成するためのインフラストラクチャを構築する際に、宛先を補助するのに必要となるため、最初に送信される。特別なファイルは、ACLに似たものであり、通常ファイルの形態で送信される。
【0077】
様々なパート1情報1204を送信した後、このフォーマットは、「データストリームのパート1の終端」ヘッダ1206を必要とする。これは、非汎用部分1104にデータを有しない基本ヘッダである。このヘッダは、パート1が終ったので今度はファイルデータを期待するということを宛先に告げるものである。
【0078】
パート1情報の後、このフォーマットは、ファイル及びストリームデータ1208を与える。ファイル内のあらゆる2MB以下の変更されたデータについて、基本ヘッダ1210が設けられ、その後にファイルデータ1212自体が続く。これらのファイルは、特定の順番で書き込む必要のないデータ、または、連続している必要のないデータで構成される。さらに、図11のヘッダを参照すると、この基本ヘッダには、汎用部分1102内部の(この例の場合)「ホールアレイ」1132と協働する、非汎用部分1104に関連するブロック番号データ構造1130が含まれる。ホールアレイは空き空間を意味している。この構造は、実質的に、ホールアレイからファイル内の対応するブロックへのマッピングを提供する。この構造は、データブロックまたはホールを書き込むべき場所を宛先に指示する。
【0079】
一般に、ファイル(1212)は、4KBの塊で書き込まれ、最大でも512個の塊(2MB)ごとに基本ヘッダを有する。同様にストリーム(これも1212)も、4KB塊の通常ファイルのように送信され、ヘッダ間が最大でも2MBになっている。
【0080】
最後に、複製データストリームフォーマット1020の終端には、「データストリームの終端」というタイプの単独ヘッダからなるフッタ1220で印が付けられる。このヘッダは、非汎用部分1104(図11)に何もデータを持たない。
【0081】
3.宛先
遠隔の宛先(例えば、遠隔のファイルサーバ、遠隔のボリューム、遠隔のQtree、又は同様のQtreeなど)は、ネットワークを介してソースファイルサーバからフォーマットされた情報を受信すると、新たなQtreeを作成するか、または、既存のミラーQtree(または、他の適当な組織的構造)を変更し、それをデータで埋める。図13は、宛先スナップショットミラープロセス1040の詳細を示すものである。上で簡単に説明したように、このプロセスは、2つの主要部分、すなわちディレクトリステージ1042とデータ又はファイルステージ1044から構成される。
【0082】
ディレクトリステージ1042は、ソースからデータストリームを送信する際に、最初に呼び出される。このステージは、複数の個別部分から構成される。これらの部分は、すべてパート1フォーマット(非ファイル)のデータを取り扱うように設計される。例示的実施形態において、パート1のデータは、宛先に読み込まれ、ファイルとしてローカルに格納され、次いでローカル記憶装置から処理される。しかしながら、このデータはリアルタイムに到着するように処理することも可能である。
【0083】
具体的には、ディレクトリステージ1042の最初の部分は、消去されたファイルヘッダの処理(1310)を含む。消去されたファイルについては、inodeマップ内のエントリが消去され、複製された宛先スナップ上のマッピングされたinodeとソーススナップ上のinodeとの関連が切断される。
【0084】
次に、ディレクトリステージは、ツリークリーニング処理(1312)を請け負う。このステップは、複製されたスナップショットディレクトリ1330から、ソーススナップショット上で変更のあったディレクトリエントリをすべて除去する。データストリームフォーマット(1020)は、いずれのディレクトリエントリが追加または消去されたかを示す。実際、このフォーマットには、ベースバージョンのディレクトリからのディレクトリエントリと、差分バージョンのディレクトリからのディレクトリエントリとの両方が存在する。宛先スナップショットミラーアプリケーションは、このフォーマットされたデータストリームを宛先ディレクトリフォーマットに変換し、各エントリがinode番号、関連名称のリスト(例えば、様々なマルチプロトコルネーム)及び、「作成」又は「消去」値を含むようにする。一般に、各ファイルは、そのファイルに関連する生成番号を有する。タプルを形成するinode番号及び生成番号は、ファイルシステム内部でディレクトリがファイルにアクセスするために用いられる。ソースはこのタプル情報を前記フォーマットで宛先に送信し、適当なタプルが宛先システムに格納される。既存の宛先ファイルに関して、古くなった生成番号は、そのファイルがソースから消去されたことを示している。生成番号の使用については、以下でさらに説明する。
【0085】
宛先は、ベースディレクトリエントリを消去として処理し、差分ディレクトリエントリを追加として処理する。移動またはリネームされたファイルは、消去(古いディレクトリからの、または古い名称の)として処理された後、追加(新たなディレクトリに対する、または新たな名称の)として処理される。消去その他の変更がなされたディレクトリ1052は、テンポラリすなわち「一時的」ディレクトリに移動され、ユーザがその場所にアクセスできないようにされる。変更されたエントリはアクティブファイルシステムの対象から完全に除去してしまうのではなく、一時的ディレクトリによって側に移動しておくことが可能になる。一時的ディレクトリエントリ自体がデータを指しているので、データが消去されたり、ディレクトリへのリンクが失われたりすることを、完全に防止することができる。
【0086】
宛先に対するQtreeの基礎転送の際には、データストリーム内のファイル及びディレクトリすべてについての幅優先探索として、Qtreeのルートからディレクトリステージツリー構築プロセスが実施される。次いでディレクトリステージは、ツリー構築プロセスを実施し、それらのファイルについてのスタブエントリを用いてすべてのディレクトリを構築する。しかしながら、図示の差分ディレクトリステージ(1042)は、本明細書に典型的に記載されるように、ツリー構築プロセス(1314)の基礎転送とは異なり、ソースと宛先との両方に現在存在するすべての変更されたディレクトリ(すなわち、転送より前に存在していた変更されたディレクトリ)を含むディレクトリキューから開始される。次いで差分ディレクトリステージツリー構築プロセスは、上で幅優先方法と呼んだ方法に従って、残りのディレクトリを処理する。
【0087】
効率を高めるため、ソース側は、パス名ではなく、inode番号及びディレクトリブロックに依存している。通常、宛先上の複製ディレクトリツリー(この例の場合、Qtree)のファイルは、ソース上で対応するファイルがすでに使用されているinode番号の受信を待機することができない(可能であっても)。そのため、宛先にはinodeマップが作成される。図14に全体を示すこのマップ1400によって、ソースは、ソース上の各ファイルを宛先に関連付けることが可能になる。このマッピングは通常、ファイルオフセットに基づく。例えば、「inode877にオフセット20KB」を有する受信されたソースブロックは、宛先inode9912に複製される。次いでこのブロックは、宛先ファイルの適当なオフセットに書き込むことができる。
【0088】
詳しくは、inodeマップ1400の各エントリは、ソーススナップショット上の各inodeについてエントリを有する。マップの各inodeエントリ1402には、ソースinode番号(1404)が索引付けされていて、このソースinode番号を介してアクセスすることができる。これらのソースinodeは、マッピングされる宛先inodeの順番とは無関係に、連続的かつ単調増加する順番でマップにリストされる。このマップは、各ソースinode番号(1404)の下に、マッピングされたinodeがソース上の現在のファイルと一致することを検証するためのソース生成番号(1406)、宛先inode番号(1408)、及び、宛先生成番号(1410)を含む。上記のように、inode番号と生成番号は、合わせて対応するファイルシステムの関連ファイルに直接アクセスするのに必要なタプルを構成する。
【0089】
格納される宛先に関してソース生成番号が上向きにインクリメントされるので、ソース生成番号を維持することにより、宛先は、ソース上でファイルの変更や消去があったか否か(及び、そのソースに関する再割り当てされたinode)を判定することができる。inodeの変更があったことをソースが宛先に通知する場合、ソースはタプルを宛先に送信する。このタプルは、ソースシステム上のinodeを一意に識別する。まったく新しいファイルやディレクトリを作成(例えば「作成」)しなければならないことをソースが宛先に示すたびに、宛先ファイルシステムはそのファイルを作成する。宛先は、そのファイルを作成すると、自分のinodeマップ1400の新たなエントリにデータを登録する。既存のファイルやディレクトリを消去しなければならないことをソースが宛先に示すたびに、宛先は、そのファイルを消去し、inodeマップのエントリをクリアする。注意して欲しいのは、ファイルを変更する場合、ソースは、使用されるタプル及びデータを送信するだけでよいということである。宛先は、inodeマップからそのソースinodeのエントリをロードする。ソース生成番号が一致した場合、そのファイルは宛先上に既に存在しているので変更しなけらばならないということが分かる。宛先は、inodeマップに記録されたタプルを用いて宛先inodeをロードする。最後に、宛先は、そのinodeを用いることにより、ファイル変更を適用することができる。
【0090】
ツリー構築プロセスの一部として、再利用されるエントリは、一時的ディレクトリから複製スナップショットディレクトリ1330に「移動」して戻される。従来、ファイルの移動は、移動するファイルの名前と移動される先のファイルの名前とを知っている必要があった。一時的ディレクトリでは、この移動されるファイルの元の名前を簡単に得ることができない。また、完全な移動には2つのディレクトリ(一時ディレクトリ及び複製スナップショット)を変更しなければならず、さらなるオーバヘッドを伴う場合がある。
【0091】
しかしながら、例示の実施形態では、宛先で受信されたソースinodeがinodeマップ1400のinodeを指していれば、ディレクトリステージが所望のファイル名を有するファイルエントリを作成する(現在の構築スナップショットディレクトリ1330に)。この名称は、ソースで作成された名称と同じでよい。スナップショットディレクトリ1330上のそのファイルと一時ディレクトリのエントリとの間に、ハードリンク1332を作成する(例えば、UNIX(R)ベースのリンクは、1つのファイルに複数の名前を割り当てることができる)。エントリをそのようにリンクすることによって、そのエントリは、一時的ディレクトリとスナップショットディレクトリ自体のファイルとの両方によって指し示されることになる。データストリーム転送の最後に一時的ディレクトリのルートが最終的に消去される場合(一時的を削除することにより)、そのハードリンクはそのエントリに対して維持され、一時ディレクトリ内の特定エントリが消去されたり再利用されたりしないことを保証し(そのエントリのリンク数が1以上であると仮定した場合)、新たなディレクトリ上のそのファイルからデータへのパスが維持される。新しく構築したツリーに最終的に関連付けられることになるあらゆる一時エントリが同時にハードリンクされ、これによって一時ディレクトリの消去に対処する。逆に、再リンクされなかった一時エントリは残らず、事実上一時ディレクトリが消去されたときに永久に消去される。
【0092】
マッピング及び生成番号の使用によって、ソースからのデータストリームにおける高価な(処理上の観点から)従来の完全なパス名(または相対パス名)の使用を回避できることが、分かったはずである。ソース上で変更されたファイルは、ソースや宛先にディレクトリをロードすることなく、宛先上で更新することができる。これによって、ソースから必要となる情報、及び、必要な処理量が制限される。また、ソースはディレクトリ処理のログを維持する必要もない。同様に、宛先は、現在のファイルシステム状態の集中的知識を維持する必要がないので、複数のサブディレクトリを同時に処理することができる。最後に、ソース及び宛先はいずれも、自動的に消去されたファイル等、消去されたファイルを明示的に追跡する必要がない。むしろ、ソースが消去されたファイルのリストを送信するだけで、宛先はこのリストを用いてinodeマップを確認することができる。このように、ファイルを消去するためにツリーを複数回にわたって選択的に検査する必要はなく、転送の終了時に一時ディレクトリを単に除去することが、唯一のファイルクリーニングステップである。
【0093】
ディレクトリステージ1042は、ツリー構築中(サブステップ1316)にディレクトリを処理する際に、ディレクトリ上に何らかのACLを設定する。上記のように、ファイルに対するACL及びNTストリームの関係は、適当な単体ヘッダに格納される。その後、以下で説明するファイルステージで、それらのACLがファイルに設定される。NTストリームは、ファイル自体が作成されるときに、そのファイルに作成される。NTストリームは、実際にはディレクトリであるため、そのエントリはディレクトリフェイズの一部で処理される。
【0094】
新たなディレクトリツリーは、データを有しないファイルや、古いデータを有するファイルを保持する場合がある。「パート1の終端」フォーマットヘッダを読み出すと、宛先ミラープロセス1040は、ファイルステージ1044に入り、そこでディレクトリツリーによって参照されるスナップショットデータファイル1340をデータ(例えば変更データ等)で埋める。図15は、ソースから受信したファイルデータ1502を書き込むための単純化した手順1500を示している。概して、4KBブロックに入れられた各(最大)2MBのデータは、対応するinode番号に到着する。対応するエントリ1402は、inodeマップ1400から調べられる。そのデータから適当なオフセット1504が導出され、それが所定の空の宛先スナップショットファイル1340に書き込まれる。
【0095】
ディレクトリステージ1042及びデータステージ1044の終わりで、すべてのディレクトリ及びファイルが処理されると、ソースからのデータストリーム転送は完了し、新たに複製されたスナップショットが自動的にユーザにエキスポートされる。この時点で、一時ディレクトリ1050(まだ再構築ツリーに「移動」して戻されていない何らかのエントリを含む)の内容が消去される。
【0096】
宛先上での複製スナップショットの最初の作成(「レベル0」転送)の後、上記の一般的手順が続く。レベル0転送と通常更新との違いはベーススナップショットが存在しないことであり、そのためこの比較は、差分スナップショットの情報を、変更ではなく常に追加及び作成として処理する。宛先ミラーアプリケーションは、既に知っている何らかのディレクトリを処理することにより、ツリー構築を開始する。宛先で作成される最初のディレクトリは、単に複製スナップショットのルートディレクトリ(Qtreeルート)である。宛先ルートはinodeマップ上に存在する。ソースは最終的にルート(ルートが到着するまで受信した他のファイルはバッファリングすることができる)を送信し、そのルートが既存の宛先ルートにマッピングされる。次いで、ルートで参照するファイルが宛先で受信及び読み出しされるにつれて、「作成」プロセスで、それらがマッピングされる。最終的に、ディレクトリ全体が作成され、次いでデータファイルが格納される。この後、複製ファイルシステムが完了する。
【0097】
E.巻き戻し(ロールバック)
上記のように、ソース及び宛先は一般に、異なる時点で同じQtreeになる可能性がある。この場合、「巻き戻し」手順を用いることにより、スナップショットに対する変更差分が未完成になる可能性があると考えられる。本質的に、図8を参照する上記のベーススナップショット更新プロセス及び差分スナップショット更新プロセスは、災害から復旧させ、アクティブファイルシステムを所与のスナップショットの状態に戻すように、逆方向に実施される。
【0098】
図16を参照すると、この図は、例示的実施形態による一般的な巻き戻し手順を表している。進行中の処理として、ステップ1605で「第1」のスナップショットを作成する。この第1のスナップショットは、宛先上の複製スナップショットのエキスポートされたスナップショットである場合がある。一時的に、ソースからの差分更新によって、対象の宛先アクティブファイルシステム(複製スナップショット)が変更される(ステップ1610)。
【0099】
パニック、クラッシュ、更新失敗等の非常事態に応答して、ユーザが開始したコマンドを終了させるため、ロールバックが開始される(ステップ1615)。この条件は、複製スナップショットの次の差分更新が適切に行なわれなかった場合の他、データの正確な像を反映しなかった場合などである。
【0100】
ロールバックの開始に応じて、複製スナップショットに対するさらなる変更/更新が、停止される(ステップ1620)。これによって、アクティブファイルシステムを停止直後に次のステップ(下記ステップ1625)でアクティブファイルシステムから作成される第2のスナップショットに反映すべき状態とは異なる状態にする可能性がある、さらなる変更を回避することができる。アクティブファイルシステムに対する変更は、ファイルシステムを読み出し専用状態にしたりすべてのアクセスを拒否させる等、様々な方法を用いて停止させることができる。一実施形態では、「SYSTEM AND METHOD FOR REDIRECTING ACCESS TO A REMOTE MIRRORED SNAPSHOT」と題した上記米国特許出願に記載されているように、アクティブファイルシステムのinodeルックアップのために二次的な階層を導入することによって、アクティブファイルシステムに対するアクセスをエキスポートされたスナップショットにリダイレクトしている。
【0101】
停止させた後、次に、変更されたアクティブファイルシステムのうちの最も新しい状態にある「第2」のエキスポートされたスナップショットを作成する(ステップ1625)。
【0102】
次にステップ1630で、第2のスナップショットと第1のスナップショットの変更差分を計算する。これは、図8及び図9を参照した上記手順に従って行ない、第2のスナップショットをベースとして用い、第1のスナップショットを差分として用いる。次にステップ1635で、計算された変更差分をアクティブファイルシステム(現在の状態で凍結されている)に適用する。この変更は、アクティブファイルシステムが最終的に第1のスナップショットに保持された状態に「巻き戻」されるように適用される(ステップ1640)。これが、巻き戻す必要がある緊急事態の前のアクティブファイルシステムの状態である。
【0103】
特定の状況では、ステップ1625によるアクティブファイルシステムのさらなる更新に対する停止や凍結を解除し、アクティブファイルシステムを変更やユーザ介入に対して再びアクセス可能にする場合もある(ステップ1645)。しかしながら、巻き戻し(下記)等の特定処理の場合、巻き戻されたQtreeは、複製処理による更なる変更についての制御下で維持される。
【0104】
この実施形態による巻き戻しの利点は、個別のログを維持したり、多量のシステムリソースを消費したりすることなく、複製されたデータ集合に対する一連の変更を元に戻すことが可能になるという点である。さらに、巻き戻しの方向、すなわち過去から現在であるか現在から過去であるかが、ほとんど問題にならない。さらに、一時ディレクトリを使用し、ファイルを消去しないことにより、この巻き戻しは、既存のNFSクライアントに悪影響を与えることがない。各NFSクライアントは、inode番号とそのファイルの生成とを含むファイルハンドルによって、ファイルにアクセスする。システムがファイルを消去して再作成する場合、そのファイルは別のinode/生成タプルを有することになる。そのため、NFSクライアントは、ファイルをリロード(古くなったファイルハンドルに関するメッセージを見る)することなくそのファイルにアクセスすることができない。しかしながら、一時ディレクトリによって、リンクの切れたファイルは、転送の終了時まで待たせることできる。そのため、上記の巻き戻しは、NFSクライアントが通知を出すことなく、一時ディレクトリに移動されただけのファイルを復活させることができる。
【0105】
inodeマップ反転
宛先複製スナップショットは、例えばソースQtreeスナップショットを再構築するためにソースでも必要になる場合があり(換言すれば、ソースと宛先の役割が逆になる)、一般的な巻き戻しを利用するためには、ソースと宛先の間にinodeマップが適切に関連付けられている必要がある。この理由は、それらの個々のツリーにおいて、ソースinodeが宛先inodeと一致しないからである。同じ理由で宛先ツリーを構築するためにinodeマップが使用され、巻き戻しの間、ソースは、宛先から戻ってきたあらゆるinodeの性質を判定するためにマッピングを用いる必要がある。しかしながら、宛先のinodeマップは、ソースが使用するのに便利な形態で情報が有効に索引付けされていない。むしろ、ソースは、適当な値を得るために、マップに提示された順番でランダムに探しまわらなければならない場合がある。
【0106】
ソース中心のinodeマップを生成する一方法は、マップエントリの「反転」である。図17は、この反転を実施する手順1700を詳細に示したものである。反転処理は、他の理由に関する災害復旧手順の一部として開始された巻き戻しの一部として(自動的に、又はユーザ指示で)開始される(ステップ1705)。次に、宛先及びソースは、ネゴシエーションをしてinodeマップファイルを宛先からソースに転送する。このネゴシエーションは、適当な誤り訂正及び受領応答を含む既知の転送方法で行なうことができる(ステップ1710)。これにより、inodeが宛先からソースに転送されて格納される。
【0107】
次に、ソースは、各inodeについて1つのエントリを有する空のinodeマップファイルを、ソースQtreeに作成する(ステップ1715)。次いで、新たな宛先は、カウンタをN=1(この例の場合)で初期化する(ステップ1720)。Nは、新たな宛先Qtree上のinode数を表す変数である。
【0108】
ステップ1725で、新たな宛先は、格納しているinodeマップファイル(すなわち、古い宛先/新たなソースからのマップ)における古い宛先に関連付けられたエントリの中から、N番目のinodeを探しだす。次に、新たな宛先は、そのようなエントリが存在するか否かを判定する(判断ステップ1730)。エントリが存在しない場合、新たなソース(古い宛先)のN番目のinodeが割り当てられていないことを表すゼロエントリを、新たなinodeマップファイルに作成する。しかしながら、新たなソース/古い宛先のN番目のinodeが存在した場合、判断ステップ1730はステップ1740に分岐し、新たなinodeマップファイル(ステップ1715で作成されたもの)に新しいエントリを作成する。この新たなエントリは、新たなソース(古い宛先)のN番目のinodeを適切な新しい宛先(古いソース)inodeにマッピングする。代替の実施形態として、この新たなinodeマップはマッピングを開始する前にマップの全てのフィールドをゼロエントリにしておくこともでき、その場合、「ゼロエントリ」の作成にはinodeマップに配置された既存のゼロエントリを残しておくことも含まれると広く考えられる。
【0109】
次いで手順1700は、Nが古い宛先ファイルシステムのinode数に等しいか否かをチェックする(判断ステップ1745)。等しければ、inodeマップファイルが完成し、手順は終了する(ステップ1750)。逆に、マッピングすべきinodeがさらに存在する場合、カウンタを1だけインクリメントする(ステップ1755でN=N+1)。同様に、新たなinodeマップにゼロエントリが作成された場合も、手順1700は判断ステップ1745に分岐し、カウンタをインクリメント(ステップ1755)するか、終了するか(ステップ1750)を判断する。ステップ1755でカウンタがインクリメントされた場合、手順はステップ1725に戻り、そこでインクリメントされたN番目のinodeを探す。
【0110】
例えば、図18は、3つの例示的エントリ1802、1804及び1806を順番に含む、例示的な古い宛先inodeマップファイル1800を示すものである。フィールド1404、1406(ソースinode番号及び宛先inode番号)、1408、1410(ソース生成番号及び宛先生成番号)については、図14を参照して上で説明した。エントリ1802は、(古い)ソースinode72が(古い)宛先inode605にマッピングされることを示している。同様に、エントリ1804はソースinode83を宛先inode328にマッピングし、エントリ1806はソースinode190を宛先inode150にマッピングする。
【0111】
図19は、反転手順1700に従って、図18の古いinodeマップファイル1800から生成された例示的な新しいinodeマップファイル1900を示すものである。この新たなマップファイルには、新たなソース(古い宛先)inode1902、新たな宛先(古いソース)inode1904、新たなソース(古い宛先)生成番号1906、及び、新たな宛先(古いソース)生成番号1908についてのフィールドが含まれる。反転の結果、新たなソースinode150に関するエントリ1910は、適当な索引順番に存在し、新たな宛先inode190(および生成番号)とペアになる。次に(一連の連続した、間にある新たなソースinode151〜372に関するエントリ1914の後)、新たなソースinode328に関するエントリ1912は、新たな宛先inode83にマッピングされる。同様に、間にある新たなソースinode329〜604に関するエントリ1918の後、新たなソースinode605に関するエントリ1916が新たな宛先inode72にマッピングされる。間にあるソースinodeは、他の新しく存在する宛先inodeへのマッピングを有する場合もあるし、あるいは、新たなソースinode606に関するエントリ1930に示すように(記憶している古いソースinodeマップ(1800)上に新たな宛先inodeがなにも検出されなかった場合に、手順1700のステップ1735で設けられるように)、ゼロ値を有する場合もある。
【0112】
G.inodeマップ関連
同一ソースの2つの複製/ミラースナップショットは、互いにミラー関係を確立することができる。これら2つのスナップショットは、元のソースに関する2つの異なる時点での表現である。図20は、元のソース2001が2つの複製/ミラースナップショット、すなわち宛先スナップショットA(2002)及び宛先スナップショットB(2004)を生成する、一般的な環境2000を示すものである。各宛先スナップショットA及びB(2002及び2004)は、元のソース2001から転送されたデータストリームのinodeをマッピングするのに用いられる、inodeマップA及びB(2012及び2014の各々)に関連している。
【0113】
図示の例は、宛先スナップショットA(2002)が、変更を転送して宛先スナップショットB(2004)にミラーを作成するように、準備しているところである。しかしながら、逆の場合、すなわち宛先スナップショットBがミラーを宛先スナップショットBに作成する場合も考えられる。従って、宛先スナップショットA(2002)は、宛先スナップショットAからの複製データに対して所望の宛先システムとして機能する宛先スナップショットB(2004)に転送を行なう際、新たなソースになる。上記の反転実施形態のように、新たなソース2002は、そのinodeマップA2012を宛先システム2004に転送する。次いで宛先システム2004は、2つのシステムのinode間の関係を判定する。この場合、新たなソースシステム及び新たな宛先システムはいずれも、古いソース2001の索引を外して各々のツリーを参照するようにした、各々のinodeマップA及びB(2012及び2014)を有する。2つの個別inodeマップが存在する場合、「連携」プロセス2016はそれらのinodeマップを1inodeづづ同時に調べる。このプロセスは、元のソース2001の各inodeについて、inodeマップA及びBの各々から「宛先inode/生成番号」を取り出す。次いでこのプロセスは、その新たなソースを、新たに関連づけられたinodeマップ2018に関する適当なマップ索引として扱う。関連マップは、新たなソース索引番号に関する新たなソース生成番号が格納され、さらに各索引エントリがinodeマップB(2014)から取り出した新たな宛先inode/生成番号に関連付け/マッピングされる。この新たなマップは、上記の原理に従って新たな宛先2004で使用され、様々な時点に関する新たなソースでの変更に基づいて、そのディレクトリにツリーが構築される。
【0114】
例えば、マップAでは古いソースOSinode番号55(OS55)が古い宛先スナップショットAのinode87(A87)にマッピングされ、マップBではOS55が古い宛先Bのinode99(B99)にマッピングされている場合を仮定する。Bを新たな宛先にし、Aを新たなソースにするためには、共通索引OS55に基づいて各々のマップからA87及びB99を取り出すプロセスを用いて、関連マップを作成する。関連マップには、新たなソースエントリ/新たな宛先エントリ 87/99が格納される。このマップには、古いマップA及びBからのそれらの値を有する関連生成番号も含まれる。この手順は2つの古い宛先システムに適用されているが、本明細書に記載される方法に従う様々な方法により、3以上のシステムに適用することも可能であると考えられる。
【0115】
上記が本発明の例示的実施形態の詳細な説明である。本発明の思想及び範囲から外れることなく様々な変更及び追加を行なうことができる。例えば、図示の相互接続されたソースサーバ及び/又は宛先サーバの数は、異なる数にしてもよい。実際、ソースサーバと宛先サーバは同一マシンにすることもできる。複数のソースがデータを宛先に転送することができ、またその逆可能であると広く考えられる。同様に、サーバの内部アーキテクチャやそれらのストレージアレイ、並びに、ネットワーク接続及びプロトコルは、すべて大きく異るものでよい。様々なソースサーバ及び宛先サーバ上で用いられるオペレーティングシステムも異なっていてよい。さらに、本明細書に記載されるオーレーティングシステム及び手順はいずれも、ハードウェア、ソフトウェア、コンピュータ上で実行されるプログラム命令を有するコンピュータ読み取り可能な媒体、あるいは、ハードウェアとソフトウェアの組み合わせで実施することができる。
【図面の簡単な説明】
【図1】従来の実施形態によるネットワークを介したソースファイルサーバから宛先ファイルサーバへのボリュームスナップショットの遠隔ミラーリングを示す略ブロック図である。
【図2】従来の実施形態により図1の相違検出器がソースファイルサーバから宛先ファイルサーバへブロックの変更を送信すべきか否かを判定するために用いる判断テーブルである。
【図3】本発明の原理を実施するソースファイルサーバ及び宛先ファイルサーバを含む、例示的ネットワーク及びファイルサーバ環境を表す略ブロック図である。
【図4】図3のファイルサーバで使用される例示的ストレージオペレーティングシステムを示す略ブロック図である。
【図5】例示的ファイルシステムinode構造を示す略ブロック図である。
【図6】スナップショットinodeを含む、図5の例示的ファイルシステムinode構造を示す略ブロック図である。
【図7】データブロックが書き替えられた後の図6の例示的ファイルシステムinode構造を示す略ブロック図である。
【図8】スナップショットミラーリングプロセスのソースでの例示的処理を示す略ブロック図である。
【図8A】図8のスナップショットミラーリングプロセスにおいてinode採集器プロセスと共に用いられる判断テーブルである。
【図8B】図8Aのinode採集器プロセスを示す例示的なベーススナップショットブロック及び差分スナップショットブロックを示す詳細な概略図である。
【図9】図8のスナップショットミラーリングプロセスとともに用いられるinodeワーカーの例示的処理を示す略ブロック図である。
【図10】ソースファイルサーバスナップショットミラーリングプロセス及び宛先スナップショットミラーリングプロセス、並びに、それらの間の通信リンクを示す略ブロック図である。
【図11】例示的実施形態によるソースと宛先との間のデータストリーム伝送フォーマットに用いられる単独ヘッダ構造を示す略ブロック図である。
【図12】例示的実施形態によるソースと宛先との間のデータストリーム伝送フォーマットを示す略ブロック図である。
【図13】宛先におけるスナップショットミラーリングプロセスのステージを示す略ブロック図である。
【図14】例示的実施形態によりソースinodeを宛先スナップショットミラーにマッピングするための一般的なinodeマップを示す略ブロック図である。
【図15】宛先スナップショットミラーのソースデータファイルに関連してマッピングされたオフセットへのデータファイルの格納を示す極めて概略的な図である。
【図16】例示的実施形態によるスナップショット巻き戻し手順を示すフロー図である。
【図17】例示的実施形態によりソースファイルシステムを宛先ミラースナップショットの状態に巻き戻す、すなわち同期させるための、inodeマップ反転手順を示すフロー図である。
【図18】図17の反転手順で使用される、宛先にある例示的inodeマップを示す略ブロック図である。
【図19】図18の反転手順により古いソース(新たな宛先)上に構築された例示的inodeマップを示す略ブロック図である。
【図20】例示的実施形態による一般的ないのでマップ関連付けプロセスを示す略ブロック図である。
Claims (17)
- ソースストレージシステム上のデータブロックの論理グループにおける変更を識別し、宛先ストレージシステム上のデータブロックの論理グループの複製を更新するためのシステムであって、
A)第1のスナップショット及び第2のスナップショットそれぞれの第1のブロック識別子の集合及び第2のブロック識別子の集合に作用するスキャナであって、前記第1のスナップショット及び前記第2のスナップショットが、データブロックの論理グループの異なるイメージに対応し、前記第1のスナップショットが、前記複製に対応し、前記第2のスナップショットが、前記第1のスナップショットよりも後の時点で作成されたソースストレージシステムのデータブロックの論理グループのイメージに対応し、該スキャナは、前記第2のブロック識別子の集合の中から前記第1のブロック識別子の集合のうちの対応するブロック識別子と異なる識別子をサーチすることにより、前記複製に反映されていない変更されたデータブロックを示すように構成され、該ブロック識別子は、前記スナップショットの論理ブロックファイル索引のボリュームブロック番号である、スキャナと、
B)前記論理グループのブロックをすべて送信することなく、前記変更されたブロックを宛先ストレージシステムへ送信するように構成されたネットワークアダプタと、
C)前記宛先ストレージシステム上で実行され、前記宛先ストレージシステム上の複製を前記変更されたブロックで更新するように構成されたストレージオペレーティングシステムと、
からなるシステム。 - 前記スキャナは、変更のないボリュームブロック番号を有するブロックをバイパスしつつ、前記第1及び第2のスナップショットそれぞれの論理ブロック索引に関連付けられたポインタの階層を下方に移動してゆき、変更されたブロック識別子を有する指されているブロックを対応するオフセットにある指されているブロックに関して識別する、請求項1のシステム。
- 検索されたブロックにおける所定の関係を有するinodeを取り出し、前記第1のスナップショット及び前記第2のスナップショットにおけるそれらのinodeの第1のバージョンと第2のバージョンとの間の変化を示す、inode採集器をさらに含む、請求項1のシステム。
- 前記所定の関係がボリュームファイルシステムの下位構成を含む、請求項3のシステム。
- 前記下位構成が前記ボリュームファイルシステム内のQtreeを含む、請求項4のシステム。
- 前記inode採集器によって取得され待ち行列に入れられたブロックに対して作用し、取り出された前記inodeの各々の第1のバージョンの階層におけるブロック間の変化を、取り出された前記inodeの各々の第2のバージョンの階層に関して、前記スキャナを用いて計算する、inodeワーカーをさらに含む、請求項4のシステム。
- 前記inodeワーカーは、前記変化を収集し、前記変化をパイプラインへ転送し、該パイプラインは、前記変化を前記宛先ストレージシステムへ伝送するためのデータストリームにパッケージングする、請求項6のシステム。
- 前記ソースストレージシステムと前記宛先ストレージシステムとの間の変化を伝送するための、拡張可能でファイルシステム非依存なフォーマットをさらに含む、請求項7のシステム。
- 宛先ストレージシステム上のデータブロックの論理グループの複製を、ソースストレージシステム上の対応する論理グループにおける変化を用いて更新するための方法であって、
A)ソースストレージシステム上の論理グループの第1のスナップショットの第1のブロック識別子の集合が前記複製に対応し、これをソースストレージシステム上の論理グループの第2のスナップショットの第2のブロック識別子の集合と比較することにより、論理グループ内の対応する位置における変更されたデータブロックを識別し、
B)前記論理グループのブロックをすべて送信することなく、前記変更されたブロックを前記宛先ストレージシステムへ送信し、
C)送信された前記変更されたブロックを使用して、前記宛先ストレージシステム上の複製を更新することからなり、
前記ブロック識別子は、前記スナップショットの論理ブロックファイル索引のブロック番号である、方法。 - 前記第1のスナップショット及び第2のスナップショットは、第1、及び第2の時点での前記ソースストレージシステム上の論理グループのイメージにそれぞれ対応し、前記比較するステップは、前記第1及び第2のブロック識別子の集合の対応するブロック識別子であって前記第1の時点と前記第2の時点との間で変更がなかったブロック識別子を選択する、請求項9の方法。
- 前記ソースストレージシステム上の論理グループは階層構造を含み、前記第1、及び第2のブロック識別子の集合は、それぞれ前記階層構造に対応する階層的ブロック索引を含み、前記選択するステップは、前記階層的ブロック索引をサーチし、比較することにより、前記変更されたブロックを識別するスキャナによって実施される、請求項10の方法。
- 前記第1及び第2のブロック識別子の集合のブロック識別子は、ソースストレージシステム上の論理グループ内の対応する位置にあるデータブロックを参照し、前記選択するステップは、前記論理グループ内の同じ位置にあるデータブロックを参照する前記第1及び第2のブロック識別子の集合のブロック識別子を比較することにより、変更されたブロックを選択する、請求項11の方法。
- inode採集器を用いて所定の関係を有するinodeを取り出し、前記第1のスナップショット及び前記第2のスナップショットにおけるそれらのinodeの第1のバージョンと第2のバージョンとの間の変化を示すことをさらに含む、請求項9の方法。
- 前記所定の関係がボリュームファイルシステムの下位構成を含む、請求項13の方法。
- 前記下位構成が前記ボリュームファイルシステム内のQtreeを含む、請求項14の方法。
- ソースストレージシステム上のデータブロックの論理グループのスナップショットからの変更のデータストリームを受信して、宛先ストレージシステム上の論理グループの複製を更新するためのシステムであって、
A)前記ソースストレージシステム上の論理グループの構造を表すメタデータを読み出し、前記ソースストレージシステム上の論理グループに対する参照を宛先ストレージシステム上の論理グループに対する参照にマッピングし、変更されたブロックを識別する、メタデータステージプロセスと、
B)マッピングされた前記参照に応じて、前記複製上の論理グループに、前記論理グループ内の対応するオフセットにある、前記ソースストレージシステムからの変更されたデータブロックを配置する、データステージプロセスと、
からなるシステム。 - ソースストレージシステム上のデータブロックの論理ブロックに対する変更を識別し、宛先ストレージシステム上の前記論理グループの複製を更新するためのシステムであって、
A)前記ソースストレージシステム上の論理グループに関する構造を表すメタデータであって前記ソースストレージシステム上の論理グループのデータブロックに対する第1の参照の集合を含むメタデータを読み出すステップ(i)と、読み出した前記メタデータの複製を生成するステップ(ii)とを含み、前記第1の参照の集合を宛先ストレージシステム上の論理グループのデータブロックに対する第2の参照の集合にマッピングするステップを含む、メタデータステージプロセスと、
B)前記複製に前記第2の参照の集合によって参照されるデータブロックを配置するステップを含む、前記メタデータステージプロセスに応答する、データステージプロセスと、
からなるシステム。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/100,950 US7225204B2 (en) | 2002-03-19 | 2002-03-19 | System and method for asynchronous mirroring of snapshots at a destination using a purgatory directory and inode mapping |
US10/100,967 US6993539B2 (en) | 2002-03-19 | 2002-03-19 | System and method for determining changes in two snapshots and for transmitting changes to destination snapshot |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004038928A JP2004038928A (ja) | 2004-02-05 |
JP4215542B2 true JP4215542B2 (ja) | 2009-01-28 |
Family
ID=27807254
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003075430A Expired - Lifetime JP4215542B2 (ja) | 2002-03-19 | 2003-03-19 | 2つのスナップショット間の変化を判定して宛先スナップショットに送信するシステム及び方法 |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1349088B1 (ja) |
JP (1) | JP4215542B2 (ja) |
AT (1) | ATE487185T1 (ja) |
DE (1) | DE60334752D1 (ja) |
Families Citing this family (139)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2003028183A1 (en) | 2001-09-28 | 2003-04-03 | Commvault Systems, Inc. | System and method for generating and managing quick recovery volumes |
US7487212B2 (en) | 2001-12-14 | 2009-02-03 | Mirapoint Software, Inc. | Fast path message transfer agent |
CA2508089A1 (en) | 2002-10-07 | 2004-04-22 | Commvault Systems, Inc. | System and method for managing stored data |
JP2005309550A (ja) * | 2004-04-19 | 2005-11-04 | Hitachi Ltd | リモートコピー方法及びリモートコピーシステム |
US8095511B2 (en) * | 2003-06-30 | 2012-01-10 | Microsoft Corporation | Database data recovery system and method |
US7441097B2 (en) | 2003-09-10 | 2008-10-21 | Seagate Technology Llc | Data storage system and method for adaptive reconstruction of a directory structure |
US7143122B2 (en) | 2003-10-28 | 2006-11-28 | Pillar Data Systems, Inc. | Data replication in data storage systems |
CA2546304A1 (en) | 2003-11-13 | 2005-05-26 | Commvault Systems, Inc. | System and method for performing an image level snapshot and for restoring partial volume data |
US7734578B2 (en) | 2003-11-13 | 2010-06-08 | Comm Vault Systems, Inc. | System and method for performing integrated storage operations |
US20050138306A1 (en) * | 2003-12-19 | 2005-06-23 | Panchbudhe Ankur P. | Performance of operations on selected data in a storage area |
US7478211B2 (en) | 2004-01-09 | 2009-01-13 | International Business Machines Corporation | Maintaining consistency for remote copy using virtualization |
US7334094B2 (en) | 2004-04-30 | 2008-02-19 | Network Appliance, Inc. | Online clone volume splitting technique |
JP2005346610A (ja) | 2004-06-07 | 2005-12-15 | Hitachi Ltd | スナップショットの取得および利用のための記憶システムおよび方法 |
WO2006015612A1 (en) * | 2004-08-12 | 2006-02-16 | Telecom Italia S.P.A. | A system, a method and a device for updating a data set through a communication network |
US8959299B2 (en) | 2004-11-15 | 2015-02-17 | Commvault Systems, Inc. | Using a snapshot as a data source |
US7457826B2 (en) * | 2004-12-20 | 2008-11-25 | Microsoft Corporation | Systems and methods for synchronization of items without snapshots |
US7757056B1 (en) | 2005-03-16 | 2010-07-13 | Netapp, Inc. | System and method for efficiently calculating storage required to split a clone volume |
US8661216B2 (en) | 2005-12-19 | 2014-02-25 | Commvault Systems, Inc. | Systems and methods for migrating components in a hierarchical storage network |
US7962709B2 (en) | 2005-12-19 | 2011-06-14 | Commvault Systems, Inc. | Network redirector systems and methods for performing data replication |
US7606844B2 (en) | 2005-12-19 | 2009-10-20 | Commvault Systems, Inc. | System and method for performing replication copy storage operations |
CA2632935C (en) | 2005-12-19 | 2014-02-04 | Commvault Systems, Inc. | Systems and methods for performing data replication |
US7636743B2 (en) | 2005-12-19 | 2009-12-22 | Commvault Systems, Inc. | Pathname translation in a data replication system |
US7651593B2 (en) | 2005-12-19 | 2010-01-26 | Commvault Systems, Inc. | Systems and methods for performing data replication |
US7617262B2 (en) | 2005-12-19 | 2009-11-10 | Commvault Systems, Inc. | Systems and methods for monitoring application data in a data replication system |
US20070180312A1 (en) * | 2006-02-01 | 2007-08-02 | Avaya Technology Llc | Software duplication |
US8316008B1 (en) | 2006-04-14 | 2012-11-20 | Mirapoint Software, Inc. | Fast file attribute search |
US7613750B2 (en) * | 2006-05-29 | 2009-11-03 | Microsoft Corporation | Creating frequent application-consistent backups efficiently |
US8726242B2 (en) | 2006-07-27 | 2014-05-13 | Commvault Systems, Inc. | Systems and methods for continuous data replication |
JP4369471B2 (ja) * | 2006-12-27 | 2009-11-18 | 富士通株式会社 | ミラーリングプログラム、ミラーリング方法、情報記憶装置 |
US8290808B2 (en) | 2007-03-09 | 2012-10-16 | Commvault Systems, Inc. | System and method for automating customer-validated statement of work for a data storage environment |
US7734885B2 (en) * | 2007-06-14 | 2010-06-08 | International Business Machines Corporation | Execution of point-in-time copy operations in continuous mirroring environments |
JP4550869B2 (ja) * | 2007-07-12 | 2010-09-22 | 株式会社東芝 | データ同期システム及びデータ同期プログラム |
US8055864B2 (en) * | 2007-08-06 | 2011-11-08 | International Business Machines Corporation | Efficient hierarchical storage management of a file system with snapshots |
JP2009146389A (ja) * | 2007-11-22 | 2009-07-02 | Hitachi Ltd | バックアップシステム及び方法 |
US8326814B2 (en) | 2007-12-05 | 2012-12-04 | Box, Inc. | Web-based file management system and service |
US8204859B2 (en) * | 2008-12-10 | 2012-06-19 | Commvault Systems, Inc. | Systems and methods for managing replicated database data |
US9495382B2 (en) | 2008-12-10 | 2016-11-15 | Commvault Systems, Inc. | Systems and methods for performing discrete data replication |
US8719767B2 (en) | 2011-03-31 | 2014-05-06 | Commvault Systems, Inc. | Utilizing snapshots to provide builds to developer computing devices |
US9092500B2 (en) | 2009-09-03 | 2015-07-28 | Commvault Systems, Inc. | Utilizing snapshots for access to databases and other applications |
US8433682B2 (en) | 2009-12-31 | 2013-04-30 | Commvault Systems, Inc. | Systems and methods for analyzing snapshots |
US9235595B2 (en) | 2009-10-02 | 2016-01-12 | Symantec Corporation | Storage replication systems and methods |
AU2010339584B2 (en) | 2009-12-31 | 2014-06-26 | Commvault Systems, Inc. | Systems and methods for performing data management operations using snapshots |
JP5574774B2 (ja) * | 2010-03-25 | 2014-08-20 | 日本電信電話株式会社 | ファイルサーバ及び連続スナップショット管理方法及び連続スナップショット管理プログラム |
US8504517B2 (en) | 2010-03-29 | 2013-08-06 | Commvault Systems, Inc. | Systems and methods for selective data replication |
US8352422B2 (en) | 2010-03-30 | 2013-01-08 | Commvault Systems, Inc. | Data restore systems and methods in a replication environment |
US8725698B2 (en) | 2010-03-30 | 2014-05-13 | Commvault Systems, Inc. | Stub file prioritization in a data replication system |
US8504515B2 (en) | 2010-03-30 | 2013-08-06 | Commvault Systems, Inc. | Stubbing systems and methods in a data replication environment |
WO2011150391A1 (en) | 2010-05-28 | 2011-12-01 | Commvault Systems, Inc. | Systems and methods for performing data replication |
WO2012099617A1 (en) | 2011-01-20 | 2012-07-26 | Box.Net, Inc. | Real time notification of activities that occur in a web-based collaboration environment |
US9063912B2 (en) | 2011-06-22 | 2015-06-23 | Box, Inc. | Multimedia content preview rendering in a cloud content management system |
GB2503625A (en) | 2011-07-08 | 2014-01-01 | Box Inc | Collaboration sessions in a workspace on cloud-based content management system |
EP2729877A4 (en) | 2011-07-08 | 2015-06-17 | Box Inc | DESKTOP APPLICATION FOR ACCESS AND INTERACTION WITH JOBS IN A CLOUD-BASED CONTENT MANAGEMENT SYSTEM AND SYNCHRONIZATION MECHANISMS THEREFOR |
US9197718B2 (en) | 2011-09-23 | 2015-11-24 | Box, Inc. | Central management and control of user-contributed content in a web-based collaboration environment and management console thereof |
US8515902B2 (en) | 2011-10-14 | 2013-08-20 | Box, Inc. | Automatic and semi-automatic tagging features of work items in a shared workspace for metadata tracking in a cloud-based content management system with selective or optional user contribution |
US9098474B2 (en) | 2011-10-26 | 2015-08-04 | Box, Inc. | Preview pre-generation based on heuristics and algorithmic prediction/assessment of predicted user behavior for enhancement of user experience |
US8990307B2 (en) | 2011-11-16 | 2015-03-24 | Box, Inc. | Resource effective incremental updating of a remote client with events which occurred via a cloud-enabled platform |
WO2013082320A1 (en) | 2011-11-29 | 2013-06-06 | Box, Inc. | Mobile platform file and folder selection functionalities for offline access and synchronization |
US9019123B2 (en) | 2011-12-22 | 2015-04-28 | Box, Inc. | Health check services for web-based collaboration environments |
US9904435B2 (en) | 2012-01-06 | 2018-02-27 | Box, Inc. | System and method for actionable event generation for task delegation and management via a discussion forum in a web-based collaboration environment |
US8762431B2 (en) | 2012-01-17 | 2014-06-24 | Apple Inc. | System and method for secure erase in copy-on-write file systems |
US11232481B2 (en) | 2012-01-30 | 2022-01-25 | Box, Inc. | Extended applications of multimedia content previews in the cloud-based content management system |
US9965745B2 (en) | 2012-02-24 | 2018-05-08 | Box, Inc. | System and method for promoting enterprise adoption of a web-based collaboration environment |
US9471578B2 (en) | 2012-03-07 | 2016-10-18 | Commvault Systems, Inc. | Data storage system utilizing proxy device for storage operations |
US9298715B2 (en) | 2012-03-07 | 2016-03-29 | Commvault Systems, Inc. | Data storage system utilizing proxy device for storage operations |
US9195636B2 (en) | 2012-03-07 | 2015-11-24 | Box, Inc. | Universal file type preview for mobile devices |
US9054919B2 (en) | 2012-04-05 | 2015-06-09 | Box, Inc. | Device pinning capability for enterprise cloud service and storage accounts |
US9575981B2 (en) | 2012-04-11 | 2017-02-21 | Box, Inc. | Cloud service enabled to handle a set of files depicted to a user as a single file in a native operating system |
US9342537B2 (en) | 2012-04-23 | 2016-05-17 | Commvault Systems, Inc. | Integrated snapshot interface for a data storage system |
WO2013166520A1 (en) | 2012-05-04 | 2013-11-07 | Box, Inc. | Repository redundancy implementation of a system which incrementally updates clients with events that occurred via cloud-enabled platform |
US9691051B2 (en) | 2012-05-21 | 2017-06-27 | Box, Inc. | Security enhancement through application access control |
US9027108B2 (en) | 2012-05-23 | 2015-05-05 | Box, Inc. | Systems and methods for secure file portability between mobile applications on a mobile device |
US8914900B2 (en) | 2012-05-23 | 2014-12-16 | Box, Inc. | Methods, architectures and security mechanisms for a third-party application to access content in a cloud-based platform |
US9021099B2 (en) | 2012-07-03 | 2015-04-28 | Box, Inc. | Load balancing secure FTP connections among multiple FTP servers |
GB2505072A (en) | 2012-07-06 | 2014-02-19 | Box Inc | Identifying users and collaborators as search results in a cloud-based system |
US9792320B2 (en) | 2012-07-06 | 2017-10-17 | Box, Inc. | System and method for performing shard migration to support functions of a cloud-based service |
US9712510B2 (en) | 2012-07-06 | 2017-07-18 | Box, Inc. | Systems and methods for securely submitting comments among users via external messaging applications in a cloud-based platform |
US9473532B2 (en) | 2012-07-19 | 2016-10-18 | Box, Inc. | Data loss prevention (DLP) methods by a cloud service including third party integration architectures |
US9794256B2 (en) | 2012-07-30 | 2017-10-17 | Box, Inc. | System and method for advanced control tools for administrators in a cloud-based service |
US8745267B2 (en) | 2012-08-19 | 2014-06-03 | Box, Inc. | Enhancement of upload and/or download performance based on client and/or server feedback information |
US9369520B2 (en) | 2012-08-19 | 2016-06-14 | Box, Inc. | Enhancement of upload and/or download performance based on client and/or server feedback information |
US9558202B2 (en) | 2012-08-27 | 2017-01-31 | Box, Inc. | Server side techniques for reducing database workload in implementing selective subfolder synchronization in a cloud-based environment |
US9135462B2 (en) | 2012-08-29 | 2015-09-15 | Box, Inc. | Upload and download streaming encryption to/from a cloud-based platform |
US9311071B2 (en) | 2012-09-06 | 2016-04-12 | Box, Inc. | Force upgrade of a mobile application via a server side configuration file |
US9195519B2 (en) | 2012-09-06 | 2015-11-24 | Box, Inc. | Disabling the self-referential appearance of a mobile application in an intent via a background registration |
US9117087B2 (en) | 2012-09-06 | 2015-08-25 | Box, Inc. | System and method for creating a secure channel for inter-application communication based on intents |
US9292833B2 (en) | 2012-09-14 | 2016-03-22 | Box, Inc. | Batching notifications of activities that occur in a web-based collaboration environment |
US10200256B2 (en) | 2012-09-17 | 2019-02-05 | Box, Inc. | System and method of a manipulative handle in an interactive mobile user interface |
US9553758B2 (en) | 2012-09-18 | 2017-01-24 | Box, Inc. | Sandboxing individual applications to specific user folders in a cloud-based service |
US10915492B2 (en) | 2012-09-19 | 2021-02-09 | Box, Inc. | Cloud-based platform enabled with media content indexed for text-based searches and/or metadata extraction |
US9959420B2 (en) | 2012-10-02 | 2018-05-01 | Box, Inc. | System and method for enhanced security and management mechanisms for enterprise administrators in a cloud-based environment |
US9705967B2 (en) | 2012-10-04 | 2017-07-11 | Box, Inc. | Corporate user discovery and identification of recommended collaborators in a cloud platform |
US9495364B2 (en) | 2012-10-04 | 2016-11-15 | Box, Inc. | Enhanced quick search features, low-barrier commenting/interactive features in a collaboration platform |
US9665349B2 (en) | 2012-10-05 | 2017-05-30 | Box, Inc. | System and method for generating embeddable widgets which enable access to a cloud-based collaboration platform |
JP5895099B2 (ja) * | 2012-10-11 | 2016-03-30 | 株式会社日立製作所 | 移行先ファイルサーバ及びファイルシステム移行方法 |
US9628268B2 (en) | 2012-10-17 | 2017-04-18 | Box, Inc. | Remote key management in a cloud-based environment |
US9756022B2 (en) | 2014-08-29 | 2017-09-05 | Box, Inc. | Enhanced remote key management for an enterprise in a cloud-based environment |
US10235383B2 (en) | 2012-12-19 | 2019-03-19 | Box, Inc. | Method and apparatus for synchronization of items with read-only permissions in a cloud-based environment |
US9396245B2 (en) | 2013-01-02 | 2016-07-19 | Box, Inc. | Race condition handling in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform |
US9953036B2 (en) | 2013-01-09 | 2018-04-24 | Box, Inc. | File system monitoring in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform |
US9336226B2 (en) | 2013-01-11 | 2016-05-10 | Commvault Systems, Inc. | Criteria-based data synchronization management |
US9507795B2 (en) | 2013-01-11 | 2016-11-29 | Box, Inc. | Functionalities, features, and user interface of a synchronization client to a cloud-based environment |
US9886346B2 (en) | 2013-01-11 | 2018-02-06 | Commvault Systems, Inc. | Single snapshot for multiple agents |
EP2757491A1 (en) | 2013-01-17 | 2014-07-23 | Box, Inc. | Conflict resolution, retry condition management, and handling of problem files for the synchronization client to a cloud-based platform |
US10725968B2 (en) | 2013-05-10 | 2020-07-28 | Box, Inc. | Top down delete or unsynchronization on delete of and depiction of item synchronization with a synchronization client to a cloud-based platform |
US10846074B2 (en) | 2013-05-10 | 2020-11-24 | Box, Inc. | Identification and handling of items to be ignored for synchronization with a cloud-based platform by a synchronization client |
US9633037B2 (en) | 2013-06-13 | 2017-04-25 | Box, Inc | Systems and methods for synchronization event building and/or collapsing by a synchronization component of a cloud-based platform |
US9805050B2 (en) | 2013-06-21 | 2017-10-31 | Box, Inc. | Maintaining and updating file system shadows on a local device by a synchronization client of a cloud-based platform |
US10110656B2 (en) | 2013-06-25 | 2018-10-23 | Box, Inc. | Systems and methods for providing shell communication in a cloud-based platform |
US10229134B2 (en) | 2013-06-25 | 2019-03-12 | Box, Inc. | Systems and methods for managing upgrades, migration of user data and improving performance of a cloud-based platform |
US9535924B2 (en) | 2013-07-30 | 2017-01-03 | Box, Inc. | Scalability improvement in a system which incrementally updates clients with events that occurred in a cloud-based collaboration platform |
US10509527B2 (en) | 2013-09-13 | 2019-12-17 | Box, Inc. | Systems and methods for configuring event-based automation in cloud-based collaboration platforms |
US8892679B1 (en) | 2013-09-13 | 2014-11-18 | Box, Inc. | Mobile device, methods and user interfaces thereof in a mobile device platform featuring multifunctional access and engagement in a collaborative environment provided by a cloud-based platform |
GB2518298A (en) | 2013-09-13 | 2015-03-18 | Box Inc | High-availability architecture for a cloud-based concurrent-access collaboration platform |
US9213684B2 (en) | 2013-09-13 | 2015-12-15 | Box, Inc. | System and method for rendering document in web browser or mobile device regardless of third-party plug-in software |
US9535909B2 (en) | 2013-09-13 | 2017-01-03 | Box, Inc. | Configurable event-based automation architecture for cloud-based collaboration platforms |
US9704137B2 (en) | 2013-09-13 | 2017-07-11 | Box, Inc. | Simultaneous editing/accessing of content by collaborator invitation through a web-based or mobile application to a cloud-based collaboration platform |
US10866931B2 (en) | 2013-10-22 | 2020-12-15 | Box, Inc. | Desktop application for accessing a cloud collaboration platform |
US9632874B2 (en) | 2014-01-24 | 2017-04-25 | Commvault Systems, Inc. | Database application backup in single snapshot for multiple applications |
US9639426B2 (en) | 2014-01-24 | 2017-05-02 | Commvault Systems, Inc. | Single snapshot for multiple applications |
US9753812B2 (en) | 2014-01-24 | 2017-09-05 | Commvault Systems, Inc. | Generating mapping information for single snapshot for multiple applications |
US9495251B2 (en) | 2014-01-24 | 2016-11-15 | Commvault Systems, Inc. | Snapshot readiness checking and reporting |
US10530854B2 (en) | 2014-05-30 | 2020-01-07 | Box, Inc. | Synchronization of permissioned content in cloud-based environments |
US9602514B2 (en) | 2014-06-16 | 2017-03-21 | Box, Inc. | Enterprise mobility management and verification of a managed application by a content provider |
US9894119B2 (en) | 2014-08-29 | 2018-02-13 | Box, Inc. | Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms |
US10038731B2 (en) | 2014-08-29 | 2018-07-31 | Box, Inc. | Managing flow-based interactions with cloud-based shared content |
US10574442B2 (en) | 2014-08-29 | 2020-02-25 | Box, Inc. | Enhanced remote key management for an enterprise in a cloud-based environment |
US10042716B2 (en) | 2014-09-03 | 2018-08-07 | Commvault Systems, Inc. | Consolidated processing of storage-array commands using a forwarder media agent in conjunction with a snapshot-control media agent |
US9774672B2 (en) | 2014-09-03 | 2017-09-26 | Commvault Systems, Inc. | Consolidated processing of storage-array commands by a snapshot-control media agent |
US9648105B2 (en) | 2014-11-14 | 2017-05-09 | Commvault Systems, Inc. | Unified snapshot storage management, using an enhanced storage manager and enhanced media agents |
US9448731B2 (en) | 2014-11-14 | 2016-09-20 | Commvault Systems, Inc. | Unified snapshot storage management |
CN105989123A (zh) | 2015-02-13 | 2016-10-05 | 阿里巴巴集团控股有限公司 | 一种数据同步方法、装置和*** |
US10678650B1 (en) * | 2015-03-31 | 2020-06-09 | EMC IP Holding Company LLC | Managing snaps at a destination based on policies specified at a source |
US10311150B2 (en) | 2015-04-10 | 2019-06-04 | Commvault Systems, Inc. | Using a Unix-based file system to manage and serve clones to windows-based computing clients |
US10503753B2 (en) | 2016-03-10 | 2019-12-10 | Commvault Systems, Inc. | Snapshot replication operations based on incremental block change tracking |
US10346354B2 (en) | 2016-10-28 | 2019-07-09 | Netapp, Inc. | Reducing stable data eviction with synthetic baseline snapshot and eviction state refresh |
US10824589B2 (en) * | 2016-10-28 | 2020-11-03 | Netapp, Inc. | Snapshot metadata arrangement for efficient cloud integrated data management |
US10732885B2 (en) | 2018-02-14 | 2020-08-04 | Commvault Systems, Inc. | Block-level live browsing and private writable snapshots using an ISCSI server |
US11042318B2 (en) | 2019-07-29 | 2021-06-22 | Commvault Systems, Inc. | Block-level data replication |
US11809285B2 (en) | 2022-02-09 | 2023-11-07 | Commvault Systems, Inc. | Protecting a management database of a data storage management system to meet a recovery point objective (RPO) |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6604118B2 (en) * | 1998-07-31 | 2003-08-05 | Network Appliance, Inc. | File system image transfer |
DE69435146D1 (de) * | 1993-06-03 | 2008-11-13 | Network Appliance Inc | Verfahren und Vorrichtung zum Beschreiben beliebiger Bereiche eines Dateisystems |
-
2003
- 2003-03-19 DE DE60334752T patent/DE60334752D1/de not_active Expired - Lifetime
- 2003-03-19 EP EP03251702A patent/EP1349088B1/en not_active Expired - Lifetime
- 2003-03-19 JP JP2003075430A patent/JP4215542B2/ja not_active Expired - Lifetime
- 2003-03-19 AT AT03251702T patent/ATE487185T1/de not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
DE60334752D1 (de) | 2010-12-16 |
JP2004038928A (ja) | 2004-02-05 |
EP1349088B1 (en) | 2010-11-03 |
EP1349088A2 (en) | 2003-10-01 |
ATE487185T1 (de) | 2010-11-15 |
EP1349088A3 (en) | 2005-04-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4215542B2 (ja) | 2つのスナップショット間の変化を判定して宛先スナップショットに送信するシステム及び方法 | |
JP5166735B2 (ja) | 非常に短い更新インターバルで同期データ複製が可能なシステム及び方法 | |
US7818299B1 (en) | System and method for determining changes in two snapshots and for transmitting changes to a destination snapshot | |
US7039663B1 (en) | System and method for checkpointing and restarting an asynchronous transfer of data between a source and destination snapshot | |
US7007046B2 (en) | Format for transmission file system information between a source and a destination | |
JP4336129B2 (ja) | 複数のスナップショットを管理するシステム及び方法 | |
US7225204B2 (en) | System and method for asynchronous mirroring of snapshots at a destination using a purgatory directory and inode mapping | |
US7464238B1 (en) | System and method for verifying the consistency of mirrored data sets | |
US7043485B2 (en) | System and method for storage of snapshot metadata in a remote file | |
US8301791B2 (en) | System and method for non-disruptive check of a mirror | |
US7363537B1 (en) | System and method for fault-tolerant synchronization of replica updates for fixed persistent consistency point image consumption | |
US7010553B2 (en) | System and method for redirecting access to a remote mirrored snapshot | |
US7685388B1 (en) | Method and system for single pass volume scanning for multiple destination mirroring | |
US20170169053A1 (en) | Mechanism for converting one type of mirror to another type of mirror on a storage system without transferring data | |
US8010509B1 (en) | System and method for verifying and correcting the consistency of mirrored data sets | |
US7478101B1 (en) | System-independent data format in a mirrored storage system environment and method for using the same | |
US7921110B1 (en) | System and method for comparing data sets | |
US7437523B1 (en) | System and method for on-the-fly file folding in a replicated storage system | |
US7437360B1 (en) | System and method for communication and synchronization of application-level dependencies and ownership of persistent consistency point images |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040916 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080226 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080526 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080526 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080530 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080825 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081007 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081104 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4215542 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111114 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121114 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121114 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131114 Year of fee payment: 5 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |