JP2007533030A - 物理的ストレージアプライアンス内で実行される仮想ストレージアプライアンスにおいてブロックベースのプロトコルを利用することが可能なシステム及び方法 - Google Patents

Abstract

仮想ファイラのような仮想サーバの複数のインスタンスをストレージアプライアンスのようなサーバ内に作成し、管理する機能を提供するアーキテクチャ。ｖｆｉｌｅｒはマルチプロトコルサーバのインスタンスを確立するための、ストレージアプライアンスプラットフォームのネットワークリソース及びストレージリソースの論理的な分割領域である。各ｖｆｉｌｅｒには、ボリューム又は論理サブボリューム（ｑｔｒｅｅ）といったストレージリソースの専用単位のサブセットと、１以上のネットワークアドレスリソースが割り当てられる。各ｖｆｉｌｅｒはストレージオペレーティングシステムのファイルシステムリソースに共有アクセスすることができる。割当てられた共有リソースに対するアクセスを制限するために、各ｖｆｉｌｅｒに対し、アクセスプロトコルごとに独自のセキュリティドメインが割り当てられる。ファイルシステムは、ｖｆｉｌｅｒバウンダリチェックを実施することにより、現在のｖｆｉｌｅｒが、ファイラプラットフォーム上に記憶された要求ファイルに関する特定のストレージリソースに対するアクセスが許可されているか否かを確認する。

Description

発明の分野
本発明はサーバアーキテクチャに関し、具体的には、単一の物理サーバプラットフォーム内に、ブロックベースのプロトコルを利用することが可能な複数の論理的サーバのインスタンスの作成を可能にするアーキテクチャに関する。

発明の背景
ストレージシステムは、メモリ、テープ、又はディスクのような書き込み可能な持続性記憶装置上での情報の編成に関するストレージサービスを提供するコンピュータである。ストレージシステムは一般に、ストレージ・エリア・ネットワーク（ＳＡＮ）環境やネットワーク・アタッチド・ストレージ（ＮＡＳ）環境の中に分散配置される。ＮＡＳ環境で使用される場合、ストレージシステムは、ストレージオペレーティングシステムを含むファイルサーバとして実施される場合がある。ストレージオペレーティングシステムは、情報を例えばディスク上にディレクトリやファイルの階層構造として編成するファイルシステムを実施する。「ディスク上」の各ファイルは、情報を記憶するように構成された例えばディスクブロックのような一連のデータ構造として実施される。一方、ディレクトリは、特殊なフォーマットのファイルとして実施され、その中に他のファイルやディレクトリに関する情報が記憶される。

ファイルサーバ、又はファイラは、クライアント／サーバモデルの情報配送に従って動作するように構成され、そのため、多数のクライアントシステム（クライアント）が、ファイラ上に記憶されたファイルのような共有リソースにアクセスすることができる。ファイルの共有はＮＡＳシステムの特徴であり、ファイルやファイルシステムに対するセマンティックレベルのアクセスによって実現される。ＮＡＳシステムにおける情報の記憶装置は通常、地理的に分散配置されたイーサネット(R)のような相互接続された通信リンクの集まりを含むコンピュータネットワーク上に分散配置される。コンピュータネットワークにより、クライアントは、ファイルサーバ上に記憶された情報に遠隔からアクセスすることができる。クライアントは通常、周知のトランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のような所定のプロトコルに従って個々のデータのフレームやパケットをやり取りすることにより、ファイラと通信する。

クライアント／サーバモデルでは、クライアントは、ポイント・ツー・ポイントリンク、共有ローカルエリアネットワーク、ワイドエリアネットワーク、あるいは、周知のインターネットのような公衆網上で実施される仮想私設ネットワークのようなコンピュータネットワークを介してファイラに「接続」されたコンピュータ上で実行されるアプリケーションを含む場合がある。ＮＡＳシステムは一般にファイルベースのアクセスプロトコルを使用するため、各クライアントは、ファイルシステムプロトコルメッセージをネットワークを介してファイラに発行することにより（パケットの形で）、ファイラにサービスを要求する場合がある。クライアント間をネットワーク接続するために、ファイラのユーティリティは、従来のコモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコル、ネットワークファイルシステム（ＮＦＳ）プロトコル、ダイレクト・アクセス・ファイルシステム（ＤＡＦＳ）プロトコルのような複数のファイシステムプロトコルを利用できるように拡張される場合がある。

これに対し、ＳＡＮは、ストレージシステムと記憶装置の間に直接接続を確立することが可能な高速ネットワークである。したがって、ＳＡＮは、ストレージバスに対する拡張のようなものと考えられ、したがって、ストレージシステムのストレージオペレーティングシステムは、「拡張バス」を介してブロックベースのアクセスプロトコルを使用して、記憶された情報にアクセスすることができる。この例において、拡張バスは通常、「ＳＣＳＩ ｏｖｅｒ ＦＣプロトコル（ＦＣＰ）」、又は「ＳＣＳＩ ｏｖｅｒ ＴＣＰ／ＩＰ／Ｅｔｈｅｒｎｅｔ(R)プロトコル（ｉＳＣＳＩ）」のようなロックアクセスプロトコルを使用して動作するように構成されたファイバチャネル（ＦＣ）又はイーサネット(R)媒体として実施される。ＳＡＮ構成又はＳＡＮデプロイメントによれば、アプリケーションサーバのようなストレージシステムから記憶装置を切り離すことができ、また、アプリケーションサーバレベルで何らかのレベルの記憶装置の共有が可能になる。ただし、ＳＡＮを単一サーバに専用に使用する環境も存在する。

ストレージシステムは通常、大量の記憶装置（例えば、６テラバイト）を有し、多数（数千）のユーザによって利用することが可能な能力を有する。この種のストレージシステムは一般に、多くのアプリケーション、又は「用途」にとって大き過ぎ、また、高価過ぎる。一般的な最小記憶サイズのボリューム（又は、ファイルシステム）は、約１５０ギガバイトであり、この大きさでも、多くの用途にとって一般に大き過ぎる。単一の一般的なストレージシステムを使用する代わりに、ユーザは、複数のもっと小型のサーバを購入する場合があり、その場合、各サーバは、ユーザの特定用途に適合する。しかしながら、それでも記憶装置の細粒度の問題が存在する。なぜなら、上記のように、一般的な最小記憶サイズのボリュームは約１５０ギガバイトであるからである。また、単数の小型のサーバを入手することは、単一のストレージシステムを購入することに比べて、コストが高くなる場合がある。さらに、多数の小型のサーバをメンテナンス及び管理するコストは通常、単一のストレージシステムをメンテナンス及び管理するコストよりも高い。したがって、多数のサーバを単一のファイラプラットフォーム内に統合し、それらのサーバを論理的に実施することが望ましい。したがって、サーバ統合は、単一の物理的サーバフラットフォーム内に多数の論理的サーバ、すなわち仮想サーバを提供する機能として定義される。単一プラットフォーム内で実施される仮想サーバの例には、ウェブサーバ、データベースサーバ、メールサーバ、及びネームサーバなどがある。

サーバ統合のための前述の技術によれば、サーバの複数の仮想インスタンスを単一の物理的サーバプラットフォーム上に実現することが可能である。しかしながら、そのようなインスタンス化は、ネットワークファイルシステム（ＮＦＳ）やコモンインターネットファイルシステム（ＣＩＦＳ）のようなファイルベースのプロトコルに制限される。そのような統合サーバは、ＦＣＰやｉＳＣＳＩのようなブロックベースのプロトコルを使用してＳＡＮベースのデータアクセス要求を処理する機能を持たない。そのため、サーバや統合サーバを利用したい管理者は、ファイルレベルのプロトコルを利用したＮＡＳベースのネットワークに限られていた。しかしながら、ブロックベースのプロトコルを利用したい管理者は、自分が必要とするデータアクセスに適合する個別のサーバ、又は複数の物理的サーバを入手しなければならなかった。最小記憶サイズが大きなボリュームであることから、この要件は経済的でないことが多い。したがって、ＳＡＮベースのシステムを設置する管理者は、必要最小限の記憶空間のうちの一部しか利用しないことが多く、その結果、購入した記憶装置の能力のうちの多くの部分を「浪費」することになる。

発明の概要
本発明は、ブロックベースのプロトコルを利用可能なストレージシステム内に、仮想ファイラ（ｖｆｉｌｅｒ）のような仮想サーバの複数のサーバのインスタンスを作成し、維持する機能を提供するアーキテクチャに関する。ｖｆｉｌｅｒは、１以上のブロックベースのプロトコルを処理するように構成されたネットワークリソース及びストレージリソースの論理的な分割領域である。ネットワークリソース及びストレージリソースは、マルチプロトコルサーバのインスタンスを確立するように領域分割され、マルチプロトコルサーバは、ブロックベースのプロトコルに応答してデータアクセス要求に対するサービスを提供するように構成される。各ｖｆｉｌｅｒは、物理的ストレージシステムプラットフォーム上の他のｖｆｉｌｅｒとは無関係に管理され、実行される。ネットワークインタフェースのストレージアドレス及びネットワークアドレスの単位のような専用ストレージシステムリソースは、グループ分けされ、領域分割され、ストレージシステム内にセキュリティドメインを確立する。また、ストレージオペレーティングシステムやファイルシステムのような共通のストレージシステムリソースは、複数のｖｆｉｌｅｒ間で共有される場合がある。

具体的には、各ｖｆｉｌｅｒには、ボリュームやｑｔｒｅｅのようなストレージリソースの専用の特有の単位が割り当てられ、更に、ＩＰアドレスやＦＣワールドワイド・ネーム（ＷＷＮ）のようなネットワークアドレスが割り当てられる。また、各ｖｆｉｌｅｒは、クライアントシステムの代わりに、共通ファイルシステムに共有アクセスすることができる。各ｖｆｉｌｅｒには、ｖｆｉｌｅｒコンテキストデータ構造が与えられ、とりわけ、（利用可能な各アクセスプロトコルについて）ｖｆｉｌｅｒに固有の一意のセキュリティドメインに関する情報が与えられ、それによって、ｖｆｉｌｅｒの割り当て済みの共有リソースに対するアクセスを制限することができる。

物理的ストレージシステム上で実行されるストレージオペレーティングシステムのユーザインタフェース（ＵＩ）に関連するＬＵＮベースのコマンドは、特定のｖｆｉｌｅｒコンテキスト内で動作するように変更が加えられる。また、ｖｆｉｌｅｒ内のＬＵＮデータ構造には、適当なｖｆｉｌｅｒ所有権情報がタグ付けされ、そのｖｆｉｌｅｒに関連するＬＵＮをエキスポートすることができる。同様に、特定のｖｆｉｌｅｒコンテキストを使用して、イニシエータグループ（ｉｇｒｏｕｐ）データ構造が識別され、特定のｖｆｉｌｅｒの管理者は、そのコンテキストに関連するｉｇｒｏｕｐだけしか管理できないように構成される。

本発明の上記の利点及び他の利点は、添付の図面と合わせて下記の説明を読むと理解しやすいであろう。図中、同じ参照符号は、同一の要素、又は機能的に同様の要素を意味している。

例示的実施形態の詳細な説明
Ａ．物理的ストレージアプライアンス
図１は、ディスク１３０のような記憶装置上での情報の編成に関連するストレージサービスを提供するように構成された物理的ストレージシステム１００を示す略ブロック図である。図示のストレージシステム１００は、システムバス１２３によって相互接続されたプロセッサ１２２、メモリ１２４、複数のネットワークアダプタ１２５、１２６、及びストレージアダプタ１２８を含むマルチプロトコルストレージアプライアンスとして実施される。マルチプロトコルアプライアンスとは、ネットワーク・アタッチド・ストレージ（ＮＡＳ）デプロイメントやストレージ・エリア・ネットワーク（ＳＡＮ）デプロイメントのユーザ（管理者）及びクライアントのために、ストレージサービス管理を単純し、ストレージ再構成を容易にする機能を有し、再利用可能な記憶空間を有するコンピュータを言う。ストレージアプライアンスは、ファイルシステムによってＮＡＳサービスを提供するとともに、ＳＡＮ仮想化によって論理ユニット番号（ＬＵＮ）のエミュレーションを含むＳＡＮサービスを提供することができる。また、ストレージアプライアンス１００は、情報を名前付きのディレクトリ、ファイル、及び仮想ディスク（ｖｄｉｓｋ）ストレージオブジェクトとしてディスク１３０上に論理編成するための仮想化システム（及び、特に、ファイルシステム）として機能するストレージオペレーティングシステム２００を更に有する。

ＮＡＳベースのネットワーク環境のクライアントは、ファイルの記憶観点を有する一方、ＳＡＮベースのネットワーク環境のクライアントは、ブロック又はディスクの記憶観点を有する。その目的のために、ストレージアプライアンス１００は、ＬＵＮ又はｖｄｉｓｋオブジェクトを作成することにより、ディスクをＳＡＮクライアントに提示（エキスポート）する。ｖｄｉｓｋオブジェクト（以下「ｖｄｉｓｋ」）は、仮想化システムによって実施される特殊なファイルタイプであり、ＳＡＮクライアントから見た場合に、エミューレートディスクとみなされる。

図示の実施形態において、メモリ１２４は、本発明に関連するソフトウェアプログラムコードやデータ構造を記憶するために、プロセッサ及びアダプタによってアドレス指定可能な記憶場所を有する。また、プロセッサ及びアダプタは、ソフトウェアプログラムコードを実行し、データ構造を操作するように構成された処理要素、及び／又は論理回路を有する場合がある。ストレージオペレーティングシステム２００の一部は通常、メモリに常駐し、処理要素によって実行され、とりわけ、ストレージアプライアンスによって実施されるストレージサービスを支援するためのストレージオペレーションを実施することにより、ストレージアプライアンスの機能を編成する。

ネットワークアダプタ１２５は、ポイント・ツー・ポイントリンク、ワイドエリアネットワーク、公衆網（インターネット）上で実施される仮想私設ネットワーク、又は共有ローカルエリアネットワーク（以下、例示的イーサネット(R)ネットワーク１６５）を介して、ストレージアプライアンスを複数のクライアント１６０ａ、ｂに接続する。したがって、ネットワークアダプタ１２５は、ストレージアプライアンスを従来のイーサネットスイッチ１７０のようなネットワークスイッチに接続するために必要とされる機械的、電気的、及び信号的回路を含むネットワークインタフェースカード（ＮＩＣ）を含む場合がある。このＮＡＳベースのネットワーク環境の場合、クライアントは、マルチプロトコルストレージアプライアンスに記憶された情報をファイルとしてアクセスする。クライアント１６０は、トランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）プロトコルのような所定のプロトコルに従って、個々のデータフレームやパケットをやりとりすることにより、ネットワーク１６５を介してストレージアプライアンスと通信する。

クライアント１６０は、ＵＮＩＸ(R)やＭｉｃｒｏｓｏｆｔ ｗｉｎｄｏｗｓ(R)オペレーティングシステムのような種々のオペレーティングシステム上でアプリケーションを実施するように構成された汎用コンピュータであってよい。クライアントシステムは一般に、ＮＡＳベースのネットワークを介して情報にアクセス（ファイル及びディレクトリの形で）するときに、ファイルベースのアクセスプロトコルを使用する。したがって、各クライアント１６０は、ネットワーク１６５を介してファイルアクセスプロトコルメッセージをストレージアプライアンスに発行することにより（パケットの形で）、ストレージアプライアンス１００にサービスを要求する場合がある。例えば、Ｗｉｎｄｏｗｓオペレーティングシステム上で動作するクライアント１６０ａは、「ＣＩＦＳ ｏｖｅｒ ＴＣＰＩＰプロトコル」を使用してストレージアプライアンス１００と通信する場合がある。一方、ＵＮＩＸオペレーティングシステム上で動作するクライアント１６０ｂは、「ＤＭＡ ｏｖｅｒ ＴＣＰ／ＩＰ（ＲＤＭＡ）プロトコル」に従って、「ＮＦＳ ｏｖｅｒ ＴＣＰ／ＩＰプロトコル」または「ＤＡＦＳ ｏｖｅｒ ＶＩプロトコル」を使用して、マルチプロトコルアプライアンスと通信する場合がある。

また、ストレージネットワーク「ターゲット」アダプタ１２６は、マルチプロトコルストレージアプライアンス１００をクライアント１６０に接続する。クライアント１６０は、記憶された情報をブロック又はディスクとしてアクセスするように更に構成される場合がある。このＳＡＮベースのネットワーク環境の場合、ストレージアプライアンスは、例示的なファイバチャネル（ＦＣ）ネットワーク１８５に接続される。ＦＣは、ＳＡＮデプロイメントにおいて主に見られる適当なプロトコル及び媒体を規定するネットワーク規格である。ネットワークターゲットアダプタ１２６は、ストレージアプライアンス１００を従来のＦＣスイッチ１８０のようなＳＡＮネットワークスイッチに接続するために必要とされる機械的、電気的、及び信号的回路を有するＦＣホストバスアダプタ（ＨＢＡ）を含む場合がある。ＦＣ ＨＢＡによれば、ＦＣアクセスが可能になるだけでなく、ストレージアプライアンスのファイバチャネルネットワーク処理の負荷を減らすこともできる。

クライアント１６０は一般に、ＳＡＮベースのネットワークを介して情報にアクセスするときに（ブロック、ディスク又はｖｄｉｓｋの形で）、ＳＣＳＩプロトコルのようなブロックベースのアクセスプロトコルを使用する。ＳＣＳＩは、ディスク１３０のような種々の周辺機器をストレージアプライアンス１００に接続することが可能な標準的でデバイスに依存しないプロトコルを備えた周辺機器入出力（Ｉ／Ｏ）インタフェースである。ＳＣＳＩ用語において、ＳＡＮ環境で動作するクライアント１６０は「イニシエータ」と呼ばれ、データの要求やコマンドの発行を行う。したがって、ストレージアプライアンスは、イニシエータから発行された要求に対し、要求／応答プロトコルに従って応答するように構成された「ターゲット」である。ＦＣプロトコルによれば、イニシエータ及びターゲットは、ワールドワイドネーム（ＷＷＮ）を含む終点アドレスを有する。ＷＷＮは重複しない（一意の）識別子であり、例えば、８バイトの数値からなるノード名又はポート名である。

ストレージアプライアンス１００は、「ＳＣＳＩ ｏｖｅｒ ＴＣＰ（ｉＳＣＳＩ）」や「ＳＣＳＩ ｏｖｅｒ ＦＣ（ＦＣＰ）」のような種々のブロックベースのプロトコルを利用することができる。したがって、イニシエータ（以下、クライアント１６０）は、ネットワーク１６５を介してｉＳＣＳＩメッセージやＦＣＰメッセージを発行することによりターゲット（以下、ストレージアプライアンス１０００）にサービスを要求し、ディスク上に記憶された情報を得る。基礎となるトランスポートプロトコルがＴＣＰ／ＩＰである場合、クライアントは、ＳＣＳＩプロトコルコマンドをＴＣＰ／ＩＰによってカプセル化し、ｉＳＣＳＩコマンドを生成する。ｉＳＣＳＩコマンドの詳細については、Julian Satran他による「Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ」、ｉＳＣＳＩ、２００２年１０月５日、に記載されており、この文献の内容は参照により本明細書に援用される。

ストレージアダプタ１２８は、ストレージアプライアンス上で実行されているストレージオペレーティングシステム２００と協働し、クライアントから要求された情報にアクセスする。この情報は、ディスク１３０上に記憶されている場合もあれば、情報を記憶するように構成された他の同様の媒体に記憶されている場合もある。ストレージアダプタは、従来の高性能ＦＣシリアルリンクトポロジのようなＩ／Ｏ相互接続構成を介してディスクに接続するためのＩ／Ｏインタフェース回路を含む。情報はストレージアダプタによって読み出され、必要に応じてプロセッサ１２２（又は、アダプタ１２８自体）によって処理された後、システムバス１２３を介してネットワークアダプタ１２５、１２６に転送され、そこで、その情報は、パケット又はメッセージとして成形され、クライアントに返送される。

ストレージアプライアンスにおける情報の記憶は、ディスク空間の全体的論理構成を規定する、物理的なストレージディスク１３０の集まりからなる１以上のストレージボリューム（ＶＯＬ１〜２ １５０）として実施されることが望ましい。ボリューム内のディスクは通常、１以上のＲＡＩＤ（Redundant Array of Independent(or Inexpensive) Disks）グループに編成される。ＲＡＩＤ実施形態によれば、ＲＡＩＤグループ内の所与の数の物理的ディスクにわたってデータを「ストライプ」状に書き込み、そのストライプ状のデータの冗長情報を適切に記憶することによって、データ記憶の信頼性／完全性を向上させることができる。この冗長情報によれば、ストレージディスクの故障時に失われるデータの復元が可能となる。当業者には明らかなように、ミラーリングのような他の冗長技術を本発明に従って使用してもよい。

具体的には、各ボリューム１５０は、ＲＡＩＤグループ１４０、１４２、及び１４４に編成された物理ディスク１３０のアレイから構成される。例えばＲＡＩＤ４レベル構成によれば、各ＲＡＩＤグループの物理ディスクは、ストライプ状のデータ（Ｄ）を記憶するように構成されたディスクと、そのデータのパリティ（Ｐ）を記憶するように構成されたディスクとからなる。なお、他のＲＡＩＤレベル構成（例えばＲＡＩＤ５）を本明細書の教示に従って使用することも可能である。図示の実施形態では、一台のパリティディスクと１台のデータディスクからなる最小限のディスクしか使用していない。しかしながら、一般的な実施形態は、１つのＲＡＩＤグループあたり、３台のデータディスク及び一台のパリティディスクを有し、１つのボリュームあたり、少なくとも１つのＲＡＩＤグループを有する。

ディスク１３０に対するアクセスを容易にするために、ストレージオペレーティングシステム２００は、ディスク１３０によって提供される記憶空間を「仮想化」する仮想化システムのｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、情報を名前付きのディレクトリオブジェクト及びファイルオブジェクト（以下、「ディレクトリ」及び「ファイル」）の階層構造としてディスク上に論理編成する。「ディスク上」の各ファイルは、データのような情報を記憶するように構成された一連のディスクブロックとして実施される一方、ディレクトリは、特殊なフォーマットのファイルとして実施され、その中に、他のファイルやディレクトリの名前、及びそれらへのリンクが記憶される。仮想化システムによれば、ファイルシステムはさらに、情報を名前付きのｖｄｉｓｋの階層構造としてディスク上に論理編成することもでき、したがって、名前付きのファイルやディレクトリに対するファイルベースのアクセス（ＮＡＳ）が可能になるとともに、ファイルベースのストレージプラットフォーム上の名前付きｖｄｉｓｋに対するブロックベースのアクセス（ＳＡＮ）が更に可能になり、ＮＡＳとＳＡＮの統合アプライアンスアプローチがストレージシステムに提供される。ファイルシステムによれば、ＳＡＮデプロイメントにおける基礎的な物理的記憶装置の管理の複雑さが低減される。

上記のように、ｖｄｉｓｋは、普通（通常）のファイルから導出されるボリューム内の特殊なファイルタイプであるが、ディスクのエミュレーションを可能にするエキスポート制御及び処理制限を有する。ｖｄｉｓｋは、ユーザが例えばＮＦＳやＣＩＦＳのようなプロトコルを使用して作成可能なファイルとは異なり、ユーザインタフェース（ＵＩ）を使用して特殊なタイプのファイル（オブジェクト）としてマルチプロトコルストレージアプライアンス上に作成される。例えばｖｄｉｓｋは、データを有する特殊ファイルｉｎｏｄｅと、セキュリティ情報のような属性を有する少なくとも１つの関連ストリームｉｎｏｄｅとを含むマルチｉｎｏｄｅオブジェクトである。特殊ファイルｉｎｏｄｅは、エミュレートディスクに関連するアプリケーションデータのようなデータを記憶するためのメインコンテナとして機能する。ストリームｉｎｏｄｅは、例えばリブート処理によってＬＵＮをエキスポートすることができ、且つ、ｖｄｉｓｋをＳＡＮクライアントに関連する単一のディスクオブジェクトとして管理することが可能な属性を記憶する。ｖｄｉｓｋ及びｖｄｉｓｋに関連するｉｎｏｄｅについては、「Virtualization by Layering Virtual Disk Objects on a File System」と題するVijayan Rajan他による米国特許出願第１０／１０／２１６，４５３号に記載されており、その内容は参照により本明細書に援用される。

Ｂ．ストレージオペレーティングシステム
図示の実施形態において、ストレージオペレーティングシステムは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから販売されているＮｅｔＡｐｐ Ｄａｔａ ＯＮＴＡＰ（登録商標）オペレーティングシステムであることが望ましい。ＮｅｔＡｐｐ Ｄａｔａ ＯＮＴＡＰオペレーティングシステムは、Ｗｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＷＡＦＬ）（登録商標）を実施する。ただし、当然ながら、ｗｒｉｔｅ ｉｎ−ｐｌａｃｅファイルシステムを有する何らかの他のストレージオペレーティングシステムを、本明細書に記載する本発明の原理に従って使用するために拡張することも可能である。したがって、「ＷＡＦＬ」という用語を使用した場合でも、この用語は、本発明の教示に適合する任意のファイルシステムアーキテクチャを指すものとして広い意味で解釈しなければならない。

本明細書で使用される場合、「ストレージオペレーティングシステム」という用語は通常、データアクセスを管理するコンピュータ上で動作するコンピュータ実行可能コードを意味し、マルチプロトコルストレージアプライアンスの場合、Ｄａｔａ ＯＮＴＡＰストレージオペレーティングシステムのようなデータアクセスセマンティックを実施することができる。Ｄａｔａ ＯＮＴＡＰストレージオペレーティングシステムはマイクロカーネルとして実施される。また、ストレージオペレーティングシステムはＵＮＩＸ(R)やＷｉｎｄｏｗｓ ＮＴ(R)のような汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施してもよいし、本明細書に記載されるようなストレージアプリケーションのために構成された、設定機能を備えた汎用オペレーティングシステムとして実施してもよい。

したがって、「ストレージシステム」という用語は、ストレージ機能を実施するように構成され、他の装置又はシステムに関連する任意のサブシステムだけでなく、そのような構成も含むものとして広い意味で解釈しなければならない。

図２は、本発明で使用するのに都合がよいストレージオペレーティングシステム２００を示す略ブロック図である。ストレージオペレーティングシステムは、統合ネットワークプロトコルスタックを形成するように編成されたソフトウェア層、すなわち、もっと具体的には、マルチプロトコルストレージアプライアンスに記憶された情報に、ブロックアクセスプロトコル及びファイルアクセスプロトコルを使用してアクセスするためのデータパスをクライアントに与えるマルチプロトコルエンジンを形成するように編成された一連のソフトウェア層を含む。このプロトコルスタックは、ＩＰ層２１２、ＩＰ層２１２をサポートする搬送手段であるＴＣＰ層２１４、及びユーザデータグラムプロトコル（ＵＤＰ）層２１６のようなネットワークプロトコル層に対するインタフェースとしての働きをするネットワークドライバ（例えば、ギガビットイーサネット(R)ドライバ）のメディアアクセス層２１０を含む。ファイルシステムプロトコル層はマルチプロトコルファイルアクセスを可能にし、その目的のために、ＤＡＦＳプロトコル２１８、ＮＦＳプロトコル２２０、ＣＩＦＳプロトコル２２２、及びハイパーテキストトランスファプロトコル（ＨＴＴＰ）２２４を含む。ＶＩ層２２６は、ＤＡＦＳプロトコル２１８に必要されるような、ＲＤＭＡのようなダイレクトアクセストランスポート（ＤＡＴ）機能を提供するためのＶＩアーキテクチャを実施する。

ｉＳＣＳＩドライバ層２２８は、ＴＣＰ／ＩＰネットワークプロトコル層を介したブロックプロトコルアクセスを可能し、ＦＣドライバ層２３０は、ＦＣ ＨＢＡ１２６と協働し、ブロックアクセス要求を送受信するとともに、統合ストレージアプライアンスに対して相互に応答をやり取りする。ＦＣドライバ及びｉＳＣＳＩドライバは、ＬＵＮ（ｖｄｉｓｋ）に対してＦＣ又はｉＳＣＳＩに固有のアクセス制御を行い、したがって、マルチプロトコルストレージアプライアンス上の単一のｖｄｉｓｋにアクセスするときに、ｉＳＣＳＩ又はＦＣＰ、あるいはそれら両方に対するｖｄｉｓｋのエキスポートを管理する。さらに、ストレージオペレーティングシステムは、ＲＡＩＤプロトコルのようなディスクストレージプロトコルを実施するディスクストレージ層２４０と、例えばＳＣＳＩプロトコルのようなディスクアクセスプロトコルを実施するディスクドライバ層２５０とを有する。

ディスクソフトウェア層と統合ネットワークプロトコルスタック層との間を橋渡しするのは、仮想化システム３００である。図３は、例えばｖｄｉｓｋモジュール３３０及びＳＣＳＩターゲットモジュール３１０として実施される仮想化モジュールと協働するファイルシステム３２０によって実施される仮想化システム３００の例を示す略ブロック図である。なお、ｖｄｉｓｋモジュール３３０、ファイルシステム３２０、及びＳＣＳＩターゲットモジュール３１０は、ソフトウェアで実施しても、ハードウェアで実施しても、ファームウェアで実施してもよく、それらの組み合わせで実施しても良い。ｖｄｉｓｋモジュール３３０は、ファイルシステム３２０の上に層として形成され（及び、ファイルシステム３２０と交信し）、ブロックベースのＳＣＳＩターゲットモジュールからファイルシステムによって管理されるブロックまでのデータパスを提供する。また、ｖｄｉｓｋモジュールは、システム管理者がマルチプロトコルストレージアプライアンス１００に対して発行したコマンドに応答して、簡単なユーザインタフェース（ＵＩ３５０）のような管理インタフェースによるアクセスを可能にする。実際には、ｖｄｉｓｋモジュール３３０は、とりわけ、システム管理者がＵＩ３５０を介して発行した一連のｖｄｉｓｋ（ＬＵＮ）コマンドを実行することにより、ＳＡＮデプロイメントを管理する。これらのｖｄｉｓｋコマンドは、ファイルシステム３２０及びＳＣＳＩターゲットモジュール３１０と交信し、ｖｄｉｓｋを実現するための原始的なファイルシステムオペレーション（「プリミティブ」）に変換される。

次に、ＳＣＳＩターゲットモジュール３１０は、それらの要求に応答して、アクセス要求の中に指定されたＬＵＮへの論理ブロックアクセスを特殊なｖｄｉｓｋファイルタイプへの仮想的なブロックアクセスに変換するマッピング手順を実施し、ｖｄｉｓｋをＬＵＮに変換することにより、ディスクまたはＬＵＮのエミュレーションを開始する。ＳＣＳＩターゲットモジュールは、図示のようにＦＣドライバ２２８、ｉＳＣＳＩドライバ２３０と、ファイルシステム３２０との間に配置され、それによって、ＳＡＮブロック（ＬＵＮ）空間とファイルシステム空間との間に仮想化システムの変換層３００を提供する。ファイルシステム空間では、ＬＵＮがｖｄｉｓｋとして表現される。

ファイルシステムは、ファイルベースのアクセスによってディスク等の記憶装置に記憶された情報にアクセスする機能を提供する。また、ファイルシステムは、ブロックベースのアクセスによって記憶された情報にアクセスするボリューム管理機能も提供する。すなわち、ファイルシステム３２０は、ファイルシステムセマンティック（記憶装置を個々のオブジェクトに分割したり、それらのストレージオブジェクトに名前を付けたりする機能）を提供する他に、通常ならばボリュームマネージャに関連する機能も提供する。

ファイルシステム３２０は、例えば４キロバイト（ｋＢ）ブロックを使用し、ｉｎｏｄｅを使用してファイルを表現する、ブロックベースのディスク上フォーマット表現を有するＷＡＦＬファイルシステムを実施する。ＷＡＦＬファイルシステムは、ファイルを使用して、ファイルシステムのレイアウトを表わすメタデータを記憶する。これらのメタデータには、とりわけ、ｉｎｏｄｅファイルがある。ファイルハンドル、すなわち、ｉｎｏｄｅ番号を含む識別子を使用して、ディスクからｉｎｏｄｅが読み出される。ｉｎｏｄｅファイルを有するファイルシステムの構造に関する説明は、１９９８年１０月６日に発行されたDavid Hitz他による「Method for Maintaining Consistent States of a File System and for Creating User-Accessible Read-Only Copies of a File System」と題する米国特許第５，８１９，２９２号に記載されており、この文献は参照により完全に本明細書に援用される。

上記のように、ファイルシステム３２０は、情報をファイルオブジェクト、ディレクトリオブジェクト、及びｖｄｉｓｋオブジェクトとしてディスク１３０のボリューム１５０の中に編成する。基礎となる各ボリューム１５０は、ＲＡＩＤグループ１４０〜１４４の集まりであり、これらは、そのボリューム内のディスク故障（複数の場合もあり）に対する保護及び信頼性を提供する。マルチプロトコルストレージアプライアンスによって提供されるサービスは、例えばＲＡＩＤ４構成によって保護される。このレベルの保護は、例えばアプライアンスプラットフォーム上での同期ミラーリングを含むように拡張することもできる。ボリューム１５０に対して後者の保護が指定された場合、ボリューム上に作成され、ＲＡＩＤ４によって保護されたｖｄｉｓｋ３２２は、同期ミラーリングにより追加された保護機能を「継承」する。その場合、同期ミラーリングによる保護機能は、ｖｄｉｓｋの性質ではなく、ファイルシステム３２０の基礎となるボリューム及び信頼性保証の性質である。

統合マルチプロトコルストレージアプライアンス１００の管理は、ＵＩ３５０を使用し、システム管理者が利用可能なｖｄｉｓｋコマンドのセットを使用することによって単純化される。ｖｄｉｓｋコマンドセットを実施するために、とりわけ、ｖｄｉｓｋの作成、ｖｄｉｓｋの増減、及び／又はｖｄｉｓｋの破壊を行うために、ＵＩ３５０は、例えばコマンドラインインタフェース（ＣＬＩ３５２）とグラフィカルユーザインタフェース（ＧＵＩ３５４）の両方を有する。そして、アプライアンス１００の仮想化記憶空間機能によれば、破壊されたｖｄｉｓｋの記憶空間は、例えばＮＡＳベースのファイルとして再使用することができる。アプリケーションデータに対するブロックベースのＮＡＳマルチプロトコルアクセスを維持したまま、ユーザ制御によりｖｄｉｓｋを増加（「拡大」）及び減少（「縮小」）することができる。

Ｃ．仮想ストレージアプライアンス（Ｖｆｉｌｅｒ）
本発明は、物理的ストレージアプライアンスプラットフォームのような単一の物理的サーバ内に、仮想ストレージアプライアンス（ｖｆｉｌｅｒ）のようなブロックベースの仮想サーバの複数のインスタンスを作成し、管理する機能を有するアーキテクチャを含む。ｖｆｉｌｅｒは、ｉＳＣＳＩのようなブロックベースのプロトコルに応答してデータアクセス要求に対するサービスを提供するように構成されたマルチプロＴコルサーバのインスタンスを確立するための、ストレージアプライアンスプラットフォームのネットワークリソース及びストレージリソースの論理的分割領域である。各ｖｆｉｌｅｒは、プラットフォーム上の他のｖｆｉｌｅｒとは全く無関係に管理され、実行される。その目的のために、記憶単位や、ネットワークインタフェースのネットワークアドレスのような専用ストレージアプライアンスリソースは、自由にグループ化され、「ハードパーティション」として領域分割され、ストレージアプライアンス内にセキュリティドメインを確立することができる。ただし、ストレージオペレーティングシステムやファイルシステムのような共通ストレージアプライアンスリソースは、複数のｖｆｉｌｅｒ間で共有することができる。

具体的には、各ｖｆｉｌｅｒには、特定量の専用の異なるストレージリソース、すなわちストレージリソースのサブセットと、１以上の専用の異なるネットワークアドレスが割り当てられる。また、各ｖｆｉｌｅｒは、クライアントの代わりに共通フィルシステムに対して共有アクセスすることができる。したがって、例えばクライアントがアクセスしている共通ファイルシステムに関連するセキュリティオブジェクトの解釈は、ｖｆｉｌｅｒによって異なる場合がある。この問題を解消するために、各ｖｆｉｌｅｒは、特に、そのｖｆｉｌｅｒに固有の異なるセキュリティドメインに関連する情報を含むｖｆｉｌｅｒコンテキストデータ構造（以下、「ｖｆｉｌｅｒコンテキスト」）を有し、それによって、ｖｆｉｌｅｒの割当て済みの共有リソースに対するアクセスを制限する。

例えば、第１のｖｆｉｌｅｒのｖｆｉｌｅｒコンテキストは、ストレージアプライアンス上のストレージリソースの第１のサブセットにアクセスするための要求が発行されたときに、第１のセキュリティドメインのユーザ又はクライアントが、ソースネットワークアドレスと宛先ネットワークアドレスの第１のセットを使用できるようにする。同様に、第２のｖｆｉｌｅｒのｖｆｉｌｅｒコンテキストは、第２のセキュリティドメインのクライアントが、ソースネットワークアドレスと宛先ネットワークアドレスの第２のセットを使用して、ストレージリソースの第２のサブセットにアクセスできるようにする。ここで特に、各セキュリティドメインのクライアントは、ストレージアプライアンス上の互いの「存在」に気づくことがなく、また、互いのストレージリソースにアクセスすることもできないことに注意して欲しい。要するに、ｖｆｉｌｅｒ間にデータは流れない。

図４は、複数のｖｆｉｌｅｒを有するストレージアプライアンスプラットフォーム４００の一実施形態を示す略ブロック図である。各ｖｆｉｌｅｒは、例えばＣＩＦＳサーバやｉＳＣＳＩサーバのようなサーバとして実施され、論理的名前、例えばＶＦ１〜ＶＦ３で参照される。クライアントから見ると、各ｖｆｉｌｅｒは、他のｖｆｉｌｅｒから分離され、独立しているように見える。各ｖｆｉｌｅｒ ＶＦ１〜ＶＦ３は、１以上のインターネットプロトコル（ＩＰ）アドレスを有するように構成され、これらのＩＰアドレスは１以上のネットワークインタフェース４０８ａ〜ｃに割り当てられる場合がある。この文脈において、「ネットワークインタフェース」という用語は、「物理的」ＮＩＣ、並びに、仮想インタフェース（ＶＩＦ）、仮想ローカルエリアネットワーク（ＶＬＡＮ）、及びエミュレートＬＡＮ（ＥＬＡＮ）のような「ソフトウェアによる」ＮＩＣを含む、ＩＰアドレスを割り当てることが可能なインタフェースを意味する。ここで特に、単一のＮＩＣが複数のＩＰアドレスを有することもあり、必要に応じて、複数のｖｆｉｌｅｒが単一のＮＩＣを共有することもある点に注意して欲しい。

ストレージアプライアンスの各インタフェースには、インタフェースをＩＰ空間に実質的に「バインド」するＩＰ空間識別子（ＩＤ）４０６ａ〜ｃが更に割り当てられる。「ＩＰ空間」とは、ストレージアプライアンスとそのストレージアプライアンスが有するストレージオペレーティングシステムが使用している特定のＩＰアドレス空間を意味する。１つのストレージアプライアンスが、複数のＩＰ空間を有することもある。各ｖｆｉｌｅｒには１つのＩＰアドレス空間が関連付けられ、したがって、各ｖｆｉｌｅｒは１つのＩＰ空間に属する。各ＩＰ空間内において、ＩＰアドレスは重複しないものでなければならない。ＩＰ空間の詳細については、Gaurav Banga他による「Technique for Enabling Multiple Virtual Filers on a Single Filer to Participate in Multiple Address Spaces with Overlapping Network Addresses」と題する米国特許出願第１０／０３５，６６６号に記載されている。

各ｖｆｉｌｅｒに割り当てられるストレージリソースの単位には、ボリュームとサブボリューム（ｑｔｒｅｅ）がある。ボリューム（Ｖ）４１０は、ファイルシステムからなる、すなわちディレクトリとファイルの階層構造からなる記憶単位である。ｑｔｒｅｅ ＱＴ１〜３ ４２０は、小型ボリューム（小型ファイルシステム）又はボリュームの一部に似た特殊なディレクトリであり、例えばファイルのｉｎｏｄｅ内に記憶されたｑｔｒｅｅ識別子（ｑｔｒｅｅＩＤ）によってファイルシステム内における自分自身を識別することが可能な性質を有する。ｖｆｉｌｅｒアーキテクチャによれば、ｖｆｉｌｅｒに対する、又はｖｆｉｌｅｒ間におけるリソースの作成、割当て、及びマッピングといった、ストレージリソースの効率的な使用及び管理が可能になる。例えば、仮想サーバ（ｖｆｉｌｅｒ等）、及びそれに関連するストレージリソース（ｑｔｒｅｅ等）は、サーバ（ストレージアプライアンス等）に統合されたり、同様の名前のリソースを有する他の仮想サーバ（ｖｆｉｌｅｒ）に統合される場合がある。ストレージリソースはｖｆｉｌｅｒ単位で割り当てられるため、そのようなサーバ統合及びストレージ移動は、クライアントにとって分かりやすい。なぜなら、クライアントがそのデータを参照する方法に何も変化がないからである。

図示の実施形態において、各ｖｆｉｌｅｒは、ｖｆｉｌｅｒがアクセス可能な特定量のデータ、例えばボリューム及びｑｔｒｅｅを有する。また、ｖｄｉｓｋはｖｆｉｌｅｒによって直接所有されるのではなく、代わりに、ｖｄｉｓｋは、ｖｄｉｓｋが存在するボリュームやｑｔｒｅｅの所有者属性を継承する場合がある。したがって、ｖｆｉｌｅｒが所与のボリューム又はｑｔｒｅｅにアクセスできる場合、ｖｆｉｌｅｒはそれらの記憶単位に記憶されたいずれのｖｄｉｓｋにもアクセスすることができる。これによって、記憶単位の所有権を単純化することができ、上で援用した「Architecture for Creating and Maintaining Virtual Filers on a Filer」と題する米国特許出願に記載されているようなファイルベースのｖｆｉｌｅｒに適合させることができる。

本発明の一態様によれば、ｖｆｉｌｅｒは、ストレージオペレーティングシステムに関連するＵＩ３５０（後で詳しく説明する）の下記のＣＬＩコマンドによって作成される。

vfiler create [xyz][-s IPspace-name][-i IP address(s)][/vol/vol2][/vol/vol3/qt1]
ここで、「xyz」は作成するｖｆｉｌｅｒの名前、「-s IPspace-name」はそのｖｆｉｌｅｒが属するＩＰ空間の名前、「-i IP address(s)」は、そのｖｆｉｌｅｒのＩＰアドレス又は一連のＩＰアドレスである。また、「/vol/vol2」は、第１の記憶単位への第１のパス記述子、「/vol/vol3/qt1」は第２の記憶単位への第２のパス記述子を意味する。デフォルトｖｆｉｌｅｒは、物理的ストレージアプライアンスの起動時の初期化の際に作成されるｖｆｉｌｅｒ０（ＶＦ０）である。ＶＦ０は、他にｖｆｉｌｅｒが何も作成されていないときにストレージアプライアンスにおいて実施される唯一のｖｆｉｌｅｒである。デフォルトＶＦ０は、物理的ストレージアプライアンスプラットフォームに関連付けられ、例えば、そのストレージアプライアンス上の全てのｖｆｉｌｅｒに対して全てのリソース割当てが完了した後、未割当てのファイラリソースに対するアクセスを可能にする。ｖｆｉｌｅｒが何も定義されていない場合、ＶＦ０は、ストレージアプライアンスの全てのリソースを有する。

各ｖｆｉｌｅｒは、ストレージアプライアンスのルートディレクトリにある特定のメタデータを管理する。このメタデータは、ｖｆｉｌｅｒの種々の構成ファイルを含む。また、このメタデータは、ｖｆｉｌｅｒのルートディレクトリにある隠しメタデータディレクトリにミラーリングされる。通常、このメタデータは、ｖｆｉｌｅｒの／ｅｔｃディレクトリにミラーリングされる。ただし、代替実施形態として、メタデータは、ｖｆｉｌｅｒディレクトリ構造内の他の場所にミラーリングしてもよい。隠しメタデータディレクトリは通常、後で詳しくするｖｆｉｌｅｒのミラーリングに使用される。

具体的には、ｖｆｉｌｅｒ作成ＣＬＩコマンドは、各ｖｆｉｌｅｒについてｖｆｉｌｅｒコンテキスト５００ａ〜ｃを生成する。なお、ストレージアプライアンスの初期化時には、ＶＦ０に対するｖｆｉｌｅｒコンテキストが生成されることに注意して欲しい。図５は、マルチプロトコルサーバのインスタンスを確立するために必要とされる構成情報、又は「状態」を含むｖｆｉｌｅｒコンテキスト５００のコア内表現を示す略ブロック図である。これらのコンテキストのインスタンスは、ｖｆｉｌｅｒアーキテクチャの基礎となる。ｖｆｉｌｅｒコンテキスト５００は、ｖｆｉｌｅｒの名前５０２を記憶するためのフィールドと、そのｖｆｉｌｅｒコンテキストを使用して作成された一意の識別子（ＵＵＩＤ５０４）を記憶するためのフィールドとを有する。ＵＵＩＤは、例えば、現在の日時や、そのｖｆｉｌｅｒに関連するメディアアクセスコントロール（ＭＡＣ）を含む場合がある。ｖｆｉｌｅｒリストフィールド５０６は、ストレージアプライアンスプラットフォーム上のｖｆｉｌｅｒのリストを有し、ＩＰ空間識別子（ＩＤ）フィールド５０８は、ｖｆｉｌｅｒのＩＰ空間ＩＤを有する。

ｖｆｉｌｅｒアーキテクチャによれば、記憶装置やネットワークデバイスといったハードウェアリソースがｖｆｉｌｅｒに直接割り当てられることはない。代わりに、それらのハードウェアデバイスの機能の一部のみを（完全に一般的に）表わすソフトウェアオブジェクトが、ｖｆｉｌｅｒに割り当てられる。これらのソフトウェア（「ソフト」）オブジェクトは、ハードウェアリソースのうちの「動的に調節可能な」部分にのみ対応する。ｖｆｉｌｅｒへの割当てにソフトウェアオブジェクトを使用する利点は、物理的ファイラ上のｖｆｉｌｅｒ間におけるハードウェアリソースの全体又は一部の割当て、追加、移動、及び再移動を行う際の総合的な柔軟性にある。これらの処理は、例えば、実行時間の短い単純なコンソールコマンドを使用することにより、ＶＭやデータムーバのような仮想サーバに基づくハードウェアパーティション間においてハードウェアオブジェクトの再構成や複製を行う複雑で実行時間の長い手順に比べて、非常に迅速に実施することができる。

したがって、ｖｆｉｌｅｒコンテキスト構造５００の他のフィールドは、仮想ファイラストレージ（ｖｆｓｔｏｒｅ）構造（ソフトオブジェクト）のリスト５１０と、仮想ファイラネットワーク（ｖｆｎｅｔ）オブジェクトのリスト５１２とを有する。図６は、本発明と共に使用するのに都合がよいソフトオブジェクトデータ構造を示す略ブロック図である。具体的には、ｖｆｓｔｏｒｅリスト５１０は、ｖｆｓｔｏｒｅソフトオブジェクト６１０へのポインタを含み、各ｖｆｓｔｏｒｅソフトオブジェクト６１０は、ｖｆｉｌｅｒに割り当てられたｑｔｒｅｅやボリュームのような一単位のストレージリソースへのパスを参照するポインタ６１２を有する。これにより、例えば、複数のｑｔｒｅｅからなるボリュームを複数のｖｆｉｌｅｒ間で有効に共有することが可能となる。また、各ｑｔｒｅｅ又はボリュームをｖｆｉｌｅｒコンテキスト５００（従って、ｖｆｓｔｏｒｅ６１０）に逆方向に「マッピング」するハッシュテーブル（図示せず）も用意される。

ｖｆｎｅｔリスト５１２は、ｖｆｎｅｔソフトオブジェクト６２０へのポインタを含み、各ｖｆｎｅｔソフトオブジェクト６２０は、ｖｆｉｌｅｒに割り当てられたＩＰアドレスを表わすインタフェースアドレス（ｉｆａｄｄｒ）データ構造６４０を参照するポインタ６２２を有する。例えばＮＩＣのような何らかのネットワークインタフェースにＩＰアドレスを割り当てるとき、各ｖｆｎｅｔオブジェクト６２０は、そのネットワークインタフェースに割り当てられる「フローティング」機能を表わす場合がある。複数のＩＰアドレスをＮＩＣに割り当てる場合、ＮＩＣの機能は、複数のｖｆｎｅｔオブジェクト６２０間で有効に共有され、したがって、異なるｖｆｉｌｅｒ間で有効に共有される。（インタフェースネットワーク（ｉｎｅｔ）データ構造６３０によって表現されるような）インタフェースに単一のＩＰアドレスしか割り当てない場合、単一のｖｆｎｅｔオブジェクト６２０だけが、したがって単一のｖｆｉｌｅｒだけが、そのＮＩＣの機能を利用する。

「リソースマッピング」は、ｑｔｒｅｅ若しくはボリューム、あるいはｉｆｎｅｔ構造のようなハードウェアリソースの種々の部分に既に割り当てられたｖｆｉｌｅｒのリソース（例えば、ｖｆｓｔｏｒｅオブジェクトやｖｆｎｅｔオブジェクト）を表わすソフトオブジェクト間のマッピングとして定義される。したがって、ｖｆｓｔｏｒｅオブジェクト及びｖｆｎｅｔソフトオブジェクトは、それらのハードウェアリソースの機能のうちの動的に調節可能な部分を表わす間接度のレベルを提供する。すなわち、それらのソフトウェアオブジェクトは、例えばそれらのオブジェクトのポインタを変更することによってネットワークリソースやストレージリソースを「論理的に」再割当てするときに柔軟性が得られるような形で、ハードウェアリソースを表現する他のソフトウェアオブジェクト（データ構造）に「リンク」される。このような柔軟性によれば、ネットワークリソースやストレージハードウェアリソースを例えば手作業で再割当てすることによりｖｆｉｌｅｒ構成の変更を物理的に実施するのとは異なり、ｖｆｉｌｅｒ構成変更の変更をファイルシステムレベルで論理的に実施することが可能になる。

例えば、ｉｆｎｅｔ構造６３０は、ネットワークインタフェースに割り当てられたＩＰアドレスのリストを記憶するためのＩＰリストフィールド６３２を有する。このリスト６３２は、それらのＩＰアドレスに関連する適当なｉｆａｄｄｒデータ構造６４０を参照するポインタ６３４を含む。上記のように、各ｖｆｎｅｔオブジェクト６２０は、ｉｆａｄｄｒ構造６４０へのポインタ６４４（対応するＩＰアドレスがｉｆｎｅｔ構造６３０に設定されている場合）を有するか、又は空の値を有する（対応するアドレスが設定されていない場合）。また、各ｉｆａｄｄｒ構造６４０は、ｖｆｉｌｅｒコンテキスト５００への（したがって、対応するｖｆｎｅｔオブジェクト６２０への）バックリンクポインタ６４２を更に有する。

同様に、ストレージリソースがオンラインである場合、各ｖｆｓｔｏｒｅオブジェクト６１０は、１つの記憶単位のパスへのポインタ６１２を有する。図示の実施形態において、ＷＡＦＬファイルシステム３３０は、ｑｔｒｅｅやボリュームのような記憶単位が利用できるか否か、及びその範囲に関する情報を管理する。パスを使用してファイルシステムに問合せ、応答として、そのパスが属するボリューム及びｑｔｒｅｅを示すストレージ識別子タプル（例えば、ｆｓｉｄ、ｑｔｒｅｅＩＤ）を受信するためのシステムコールが用意される。

また、ｖｆｉｌｅｒアーキテクチャにおけるリソースマッピングによれば、例えばｖｆｉｌｅｒ間におけるネットワークリソースやストレージリソースの移動（割当て）に関し、効率的なネットワークやストレージの管理が更に可能となる。ネットワーク管理とは、ファイラプラットフォーム上のｖｆｉｌｅｒやｖｆｉｌｅｒが有するネットワークリソースの割当てに動的変更が加えられたときや、ファイラプラットフォーム上で他の変更がなされたときに、ｖｆｉｌｅｒとｖｆｉｌｅｒが有するネットワークリソースとの間のリソースマッピングを維持するための一連のデータ構造及びアルゴリズムを意味する。一方、ストレージ管理とは、それらのリソースの割当てに動的変更が加えられたときや、プラットフォーム上で他の変更がなされたときに、ｖｆｉｌｅｒとｖｆｉｌｅｒが有するストレージリソースとの間のリソースマッピングを維持するための一連のデータ構造及びアルゴリズムを意味する。割当ての変更には、リソースの追加、ｖｆｉｌｅｒ間におけるリソースの移動及び削除などがある。他のシステム変更としては、新たなＮＩＣ（ＶＩＦ、ＶＬＡＮ、又は新たなデバイス）の作成、及び、ストレージボリュームの追加／始動／停止などがある。

また、ネットワークやストレージの管理には、ｖｆｉｌｅｒ間におけるリソースの割当てに変更が加えられたときに、ネットワークオブジェクトやストレージオブジェクトに対して実施されるタスクも含まれる。例えば、ｖｆｉｌｅｒに対するＩＰアドレスの割当てが変更された場合、ＴＣＰ／ＩＰ接続や、ＩＰアドレスに関連するルーティングを初期化しなければならない。同様に、ｖｆｉｌｅｒに割り当てられた記憶単位に変更があった場合、ｑｔｒｅｅやボリュームに対して実行中のディスク入出力処理を中止し、クオータを初期化しなければならない。

各ｖｆｉｌｅｒコンテキスト５００は、特定のプロトコルまたはサブシステムのインスタンスに必要とされる全ての情報（グローバル変数等）を含む複数の「モジュール」データ構造を更に含む。例えば、ＣＩＦＳモジュールデータ構造５２０は、ＣＩＦＳプロトコルのインスタンスに必要とされる全ての情報を有し、例えば、ドメインコントローラ５２２との通信、ＣＩＦＳプロトコルのアクティブセッション５２４、及びＣＩＦＳプロトコルに関連する種々の制御ブロック５２５に関する情報を有する。ドメインコントローラは、ログイン要求を受信し、認証を開始するネットワークサーバである。ＣＩＦＳ要求の際にＮＴタイプのセキュリティを可能にするために、セキュリティドメイン５２６に関連する情報も与えられる。セキュリティ情報は、ドメイン部分と関連ＩＤ（ＲＩＤ）部分とを含むセキュリティ識別子を含み、後者のＲＩＤは、ＵＮＩＸセキュリティのユーザＩＤに似ている。Ｗｉｎｄｏｗｓドメインセキュリティの場合、セキュリティ情報は、ドメインコントローラとの信頼関係を更に含む。この信頼関係は、ｖｆｉｌｅｒの代わりにユーザを認証するために、ｖｆｉｌｅｒがドメインコントローラを「信頼」する機能を意味する。各ＣＩＦＳモジュール５２０は、ＣＩＦＳ認証プロセスのプロセスＩＤ（ＰＩＤ５２８）を更に含み、このプロセスＩＤにより、ＣＩＦＳ層は、認証要求を正しいＣＩＦＳ認証プロセスに送信することが可能となる。

ｖｆｉｌｅｒに関連するプロトコル及びサブシステムのそれぞれについて、同様の「モジュールごと」のデータ構造が存在し、例えば、限定はしないが、ｉＳＣＳＩプロトコル５３０、ｖｄｉｓｋデータ構造５４０、ＳＣＳＩターゲット５５０、ＮＩＳサブシステム５６０、ドメインネームサービス（ＤＮＳ）サブシステム５７０、及びレジストリ５８０などが存在する。ＮＩＳサブシステム、すなわち「イエローページ」は、ＮＦＳプロトコルのサービス探知器であり、各ユーザパスワードに関連するユーザＩＤやグループＩＤのようなセキュリティ情報を記憶する分散データベースとして実施される。ｖｄｉｓｋデータ構造は、ｖｆｉｌｅｒに関連するｖｄｉｓｋをｖｆｉｌｅｒによって管理するために使用される種々のコア内データ構造へのポインタを含む。ＳＣＳＩターゲットデータ構造５５０は、ｖｆｉｌｅｒが種々のｖｆｉｌｅｒごとのデータを記憶するために使用され、例えば、そのｖｆｉｌｅｒにログインしたイニシエータの識別情報や、種々のアダプタの現在の状態等のデータを記憶するために使用される。

Ｃ．イニシエータグループ
ＳＡＮクライアントは通常、論理番号、すなわちＬＵＮによってディスクを識別し、アドレス指定する。しかしながら、ＵＩ３５０は、ｖｄｉｓｋモジュール３３０及びＳＣＳＩターゲットモジュール３１０と通信し、論理名をｖｄｉｓｋにマッピングする。ｉｇｒｏｕｐは、（クラスタ環境が構築されているか否かによって異なる）１以上のイニシエータに関連する１以上のアドレス、例えばＷＷＮやｉＳＣＳＩ ＩＤに割り当てられた論理名の付けられたエンティティである。ｉｇｒｏｕｐの詳細については、Mohan Srinivasan他による「Consistent Logical Naming of Initiator Groups」と題する米国特許出願第１０／４２１，５７６号に記載されている。ストレージアプライアンスは、ｉｇｒｏｕｐを使用して、論理名によりｖｄｉｓｋのエキスポート制御を管理する。ｉｇｒｏｕｐを作成した場合、アドレスは実質的に、論理名又はｉｇｒｏｕｐにバインド（関連付け）される。

図示の実施形態において、ｖｄｉｓｋ（ＬＵＮ）は、ｉｇｒｏｕｐの上に「層」として形成される。ｉｇｒｏｕｐは、ｖｄｉｓｋへのアクセスを要求するクライアントまたはイニシエータの「名前」（すなわち、識別情報）の基礎的な詳細を要約する。名前の詳細は、ＦＣＰやｉＳＣＳＩのようなブロックアクセスプロトコルによって全く異なる場合がある（クライアント／イニシエータによるｖｄｉｓｋ／ＬＵＮへのアクセスを許可するために）。しかしながら、ｉｇｒｏｕｐの論理名はＦＣ規格及びＳＣＳＩ規格に準拠し、本明細書に記載するユーザインタフェースシステムは、ｖｄｉｓｋに対するアクセスを単純化したそれらの規格の１つの応用形態に相当する。したがって、ｉｇｒｏｕｐ要約によれば、アドレス指定の実施が、アドレス指定の基礎的な詳細から分離される。換言すれば、ｉｇｒｏｕｐによれば、ユーザは、論理名を指定することによってクライアント、又は関連クライアントを定義し、その後、上位層のｖｄｉｓｋ（ＬＵＮ）コマンドを使用してそれらにアクセスすることが可能となる。その結果、ｖｄｉｓｋ（ＬＵＮ）をｉＳＣＳＩ及びＦＣＰを介して簡単に共有することが可能となり、それによって、ｖｄｉｓｋをｉＳＣＳＩとＦＣＰの混成クラスタのような応用形態において使用することが可能になる。さらに、クライアント／イニシエータの再編成や更新が、ＬＵＮレベルでの（アクセスを許可する）セキュリティに影響を与えることはない。なぜなら、それらは論理ｉｇｒｏｕｐ名を使用して間接的に実施されるからである。

図７は、本発明の一実施形態によるｉｇｒｏｕｐデータ構造７００を示す概略図である。ｉｇｒｏｕｐデータ構造７００は、ｉｇｒｏｕｐ名フィールド７０５、アドレスフィールド７１０、ｖｆｉｌｅｒフィールド７１５を含み、代替実施形態では、補助的なフィールド７２０を更に含む場合がある。オブジェクト名フィールド７０５は、そのｉｇｒｏｕｐに関連する論理名を識別する。アドレスフィールド７１０は、そのｉｇｒｏｕｐを含むクライアントを識別するための、例えばＷＷＮアドレスやｉＳＣＳＩ ＩＤのような１以上のアドレスを有する。ｖｆｉｌｅｒフィールド７１５は、どのｖｆｉｅｒがそのｉｇｒｏｕｐに関連しているかを識別する。本発明の一態様によれば、各ｉｇｒｏｕｐが１つのｖｆｉｌｅｒに関連付けられ、それによって、ＬＵＮやｉｇｒｏｕｐをｖｆｉｌｅｒごとに管理することが可能となり、また、特定のｖｆｉｌｅｒに関連するｖｄｉｓｋへのクライアントアクセスをｖｆｉｌｅｒごとに管理することも可能になる。また、ｉｇｒｏｕｐに対する変更は、適当なｖｆｉｌｅｒコンテキストの中で実施しなければならない。したがって、例えば、或るｉｇｒｏｕｐのアドレスフィールド７１０へのイニシエータの追加は、そのｉｇｒｏｕｐのｖｆｉｌｅｒフィールド７１５の中に指定されたｖｆｉｌｅｒコンテキストの中で実施しなければならない。

ＵＩシステムは、ＬＵＮ ＩＤをｖｄｉｓｋに割当て、そのｖｄｉｓｋに対するアクセスが許可されたイニシエータのｉｇｒｏｕｐ、すなわち、そのｖｄｉｓｋをエキスポートする宛先のクライアントのｉｇｒｏｕｐを指定する手段を有する。各ｉｇｒｏｕｐには、そのｉｇｒｏｕｐに含まれる構成要素イニシエータ（ノード名）のトランスポートプロトコルタイプ及びオペレーティングシステムタイプのような属性が関連付けられる。例えば、或るｉｇｒｏｕｐ内のイニシエータは、ＦＣＰ及びｉＳＣＳＩトランスポートプロトコルタイプを利用することができる。オペレーティングシステムタイプ属性とは、ｉｇｒｏｕｐ内の構成要素イニシエータのオペレーティングシステムタイプを意味する。後者の属性を設定する理由は、ＳＣＳＩターゲット（マルチプロトコルストレージアプライアンス等）が、異なるオペレーティングシステム（例えば、ソラリス、Ｗｉｎｄｏｗｓ、及びＬｉｎｕｘ等）のイニシエータと通信するときに、異なる動作をすることがあるからである。ストレージアプライアンスで受信した要求の処理は、ストレージオペレーティングシステムの比較的下位の層で実施される。ｉｇｒｏｕｐ名にはアドレス（ＷＷＮやｉＳＣＳＩ ＩＤ）が関連付けられているので、それらの下位の層は、例えば、その要求がｉＳＣＳＩトランスポートを介して受信されたか、それともＦＣＰトランスポートを介して受信したかを「知る」ことができる。

ｉｇｒｏｕｐの属性は異なるものである必要はない。すなわち、ｉｇｒｏｕｐは、ＦＣＰ及びｉＳＣＳＩの種々の組み合わせをトランスポートとして有する複数のイニシエータを有することができる。例えば、ｉＳＣＳＩイニシエータとＦＣＰイニシエータは、１つのｉｇｒｏｕｐに結合される場合がある。また、ｉｇｒｏｕｐは、種々のオペレーティングシステムイニシエータ構成要素をサポートする。これにより、アプリケーションを停止させることなく、ＦＣ ＳＡＮクラスタからｉＳＣＳＩクラスタへの良好なローリングアップグレードのような処理が可能となる。また、ｉｇｒｏｕｐの構成要素は、何時でも変更することができる。すなわち、ｉｇｒｏｕｐに対するイニシエータの追加や削除は、何時でも行うことができる。その結果、イニシエータはｉｇｒｏｕｐのマッピングを継承するか、又は失う。

Ｄ．Ｖｆｉｌｅｒのユーザインタフェース
ストレージアプライアンス１００の管理は、システム管理者が利用可能なＵＩ３５０の使用、並びに、ｉｇｒｏｕｐ及びＬＵＮコマンドセットの使用により、単純化される。上記のように、ＵＩ３５０は、ｖｄｉｓｋコマンドセットの実行に使用されるコマンドラインインタフェース（ＣＬＩ３５２）とグラフィカルユーザインタフェース（ＧＵＩ３５４）を両方とも有し、それらはとりわけ、ｖｄｉｓｋの作成、ｖｄｉｓｋのサイズの増減、及び／又はｖｄｉｓｋの破壊といったｖｄｉｓｋコマンドの実行に使用される。ＵＩから入力されたコマンドは、それがＣＬＩから入力されたものであるかＧＵＩから入力されたものであるかに関わらず、従来のユーザインタフェース技術を使用して、所望のｖｄｉｓｋ変更、及び／又はｉｇｒｏｕｐ変更を実施するための１セットのファイルシステムプリミティブに変換される。

ｖｆｉｌｅｒのユーザインタフェースは、物理的ストレージアプライアンス上で通常使用されるものと同じコマンドを有する。そのようなコマンドの詳細については、Brian Pawlowski他による「User Interface System for a Multi-Protocol Storage Appliance」と題する米国特許出願第１０／６３８，５６７号に記載されている。本発明によれば、ＵＩにおいて利用可能なブロックベースのコマンドは特定のｖｆｉｌｅｒコンテキストの中でしか機能せず、コマンドはそのｖｆｉｌｅｒコンテキストの中で実行される。

コマンドラインインタフェース
ＵＩ３５０によれば、例えば、管理者がｖｄｉｓｋを作成するときに、使用すべき既存のディスク、及び／又はブロックを明示的に設定し、指定する必要性を無くすことによって、ストレージアプライアンスの管理は単純化される。そのような管理の単純化を行うために、図示のＵＩは、ｉｇｒｏｕｐコマンドやＬＵＮコマンドのような多数のＣＬＩコマンドを有する。ｉｇｒｏｕｐコマンドは、後で説明するように、所与のストレージシステムに関連するｉｇｒｏｕｐを作成し、破壊し、及び／又は管理するための種々のオプションを有する。同様に、ＬＵＮコマンドも、システム管理者が、ストレージシステムに関連するＬＵＮを作成し、破壊し、及び／又は管理するための種々のオプションを有する。

本発明の他の態様によれば、ｖｆｉｌｅｒに対するＬＵＮベースの、又はブロックベースの管理に関連する全てのＣＬＩコマンドは、特定のｖｆｉｌｅｒコンテキストの中で実行される。したがって、あるコマンドによって行われる変更は、ｖｆｉｌｅｒに特有のものであり、物理的ストレージアプライアンスの全体的動作に影響を与えることはない。なお、本明細書の説明は、ＬＵＮコマンド及びｉｇｒｏｕｐコマンドを例として記載されているが、本発明の原理は、ＬＵＮベースの、又はブロックベースの処理を行うためのＵＩ内の任意のコマンドに適用することができる。

ｉｇｒｏｕｐコマンドの例は、次のようなものである。

igroup create -f/i <groupname> <nodename(s)>
ここで、パラメータ「<groupname>」には、ｉｇｒｏｕｐの名前が指定され、パラメータ「<nodename(s)>」には、そのｉｇｒｏｕｐにバインドされるイニシエータ、例えばＷＷＮアドレスＩＤ又はｉＳＣＳＩアドレスＩＤが指定される。オプション「f/i」は、列挙するノード名がＦＣＰ ＷＷＮであるか（「-f」 オプション）、それともｉＳＣＳＩアドレスであるか（「-i」オプション）を決定する。オプション「create」は、ＷＷＮアドレスＩＤ又はｉＳＣＳＩアドレスＩＤを論理名又はｉｇｒｏｕｐに実質的にバインドすることにより、新たなｉｇｒｏｕｐを作成する。ｉｇｒｏｕｐコマンド、適当なｉｇｒｏｕｐデータ構造の作成、及びファイルシステムプリミティブの働きの詳細については、Mohan Srinivasan他による「Consistent Logical Naming of Initiator Groups」と題する米国特許出願第１０／４２１，５７６号に記載されており、その内容は参照により本明細書に援用される。

代替実施形態では、例えば、ｉｇｒｏｕｐを削除するためのオプション「destroy」のような種々の他のオプションを付けてｉｇｒｏｕｐコマンドを実行する場合がある。ユーザが「igroup destroy」コマンドをＣＬＩ３５２に入力すると、ストレージオペレーティングシステムは、適当なｉｇｒｏｕｐデータ構造及びストリームフィールドを削除し、論理名からＷＷＮアドレスＩＤ又はｉＳＣＳＩＩＤの「バインド」を解除する。他のオプションとして、全てのｉｇｒｏｕｐ及びそれらに関連するネットワークアドレスを表示するための「igroup show」コマンドがある。

単純なイニシエータグループ同士のバインディングの場合、ｉｇｒｏｕｐは１つのイニシエータを有する場合がある（あるいは、ＳＡＮクラスタの場合、又は冗長構成若しくはマルチパス構成のために複数のイニシエータを有する単一クライアントの場合、もっと多くのイニシエータを有する場合もある）。したがって、作成されたｉｇｒｏｕｐによれば、人間にとって分かりやすい論理名によるイニシエータのグループ化が可能となる。

ＬＵＮコマンドの例は次のようなものである。

lun create -s <size> <pathname>
ここで、オプション「create」は、ＬＵＮ（ｖｄｉｓｋ）の作成を指定し、オプション「-s」は作成すべきｖｄｉｓｋのサイズを指定し、パラメータ「<pathname>」は、作成されるｖｄｉｓｋへの正規のパスを指定するものである。一実施形態において、サイズは、例えば、ｂ（バイト）、ｋ（キロバイト）、ｍ（メガバイト）、ｇ（ギガバイト）、又はｔ（テラバイト）といった数値による識別子をサフィックスとして使用して表記される場合がある。当業者には明らかなように、本発明の教示に従って、種々の他のサイズ識別子を使用することも可能である。

「lun create」コマンドの結果、ＲＡＩＤ保護を明示的に指定しなくても、指定されたサイズのＲＡＩＤ保護されたｖｄｉｓｋが作成される。マルチプロトコルストレージアプライアンスのディスク上の情報の記憶は、入力されない。「未処理」のビットだけがディスク上に記憶される。ファイルシステムは、ボリューム内の全てのディスクにわたって、それらのビットをｖｄｉｓｋ及びＲＡＩＤグループに編成する。このように、仮想化システム３００は、ユーザに分かりやすい態様でｖｄｉｓｋを作成するので、作成されたディスクを明示的に構成する必要はない。作成されるｖｄｉｓｋは、ファイルシステムによって作成された基礎となるボリュームの高性能な信頼性や記憶帯域幅といった性質を継承する。作成されるｖｄｉｓｋは、ｖｆｉｌｅｒが所有するボリュームやｑｔｒｅｅのような記憶単位上に配置される必要があり、「lun create」コマンドは、そのｖｆｉｌｅｒのコンテキストにおいて実行される。ｖｄｉｓｋを作成する場合、ＬＵＮデータ構造のｖｆｉｌｅｒエントリ８４０（図８参照）は、そのｖｄｉｓｋを「所有」するｖｆｉｌｅｒを識別するように設定される。

上記のように、マルチプロトコルストレージアプライアンスは、イニシエータグループ（ｉｇｒｏｕｐ）を使用して、論理名によってｖｄｉｓｋのエキスポート制御を管理する。１以上のｖｄｉｓｋをｉｇｒｏｕｐにエキスポートするために、すなわち、１以上のｖｄｉｓｋをｉｇｒｏｕｐから「参照可能」にするために、「lun map」コマンドを使用する場合がある。

「lun map」コマンドの例は次のようなものである。

lun map <path name> <igroup>
ここで、パラメータ<path name>は、マッピングされるＬＵＮへのパス名であり、パラメータ<igroup>は、所望のＬＵＮにマッピングすべきイニシエータグループを指定するパラメータである。その意味で、「lun map」コマンドは、ＮＦＳエキスポートやＣＩＦＳシェアと同様のものである。すなわち、ＷＷＮアドレス又はｉＳＣＳＩ ＩＤは、パス名によって指定されたｖｄｉｓｋへのアクセスを許可されたクライアントを識別する。以後、ストレージオペレーティングシステムの内部的な全ての処理に、論理名ｉｇｒｏｕｐが使用される。この論理名要約は、ユーザとマルチプロトコルストレージアプライアンスの間の対話のような、ＬＵＮコマンドとｉｇｒｏｕｐコマンドのセット全体に行き渡る。特に、ｉｇｒｏｕｐ名変換は、以後全てのエキスポート処理、及び種々のＳＡＮクライアントにエキスポートされるＬＵＮのリスティングに使用される。このマッピングは、ｖｆｉｌｅｒコンテキストに対して有効であり、コマンドはｖｆｉｌｅｒコンテキストの中で実行される。

マッピングを元に戻すために、ストレージオペレーティングシステムは、ＬＵＮからｉｇｒｏｕｐの割当てを解除するための「lun unmap」コマンドを有する。

「lun unmap」コマンドの例は次のようなものである。

lun unmap <path name> <igroup>
ここで、パラメータ<path name>には、マッピングを解除すべきＬＵＮへのパス名が指定され、パラメータ<igroup>には、ＬＵＮとの関連付けを解除すべきｉｇｒｏｕｐが指定される。「lun unmap」コマンドを実行した後、ｉｇｒｏｕｐ内のイニシエータからそのＬＵＮは参照できなくなる。

ＬＵＮのサイズは、「lun resize」コマンドを使用して、管理者が自由に調節することができる。「lun resize」コマンドの例は次のようなものである。

lun resize <path name> <size>
ここで、パラメータ<path name>は、リサイズすべきＬＵＮのパス名であり、パラメータ<size>には、そのＬＵＮの新たなサイズが指定される。一実施形態において、サイズは、例えば、ｂ(バイト）、ｋ（キロバイト）、ｍ（メガバイト）、ｇ（ギガバイト）、又はｔ（テラバイト）のような数値による識別子を種々のサフィックスとして使用して表される。一実施形態において、「lun resize」コマンドは、ストレージアプライアンスによってクライアントに報告されたＬＵＮのサイズを変更する。ストレージアプライアンスがその変更を報告した後、クライアント上で実行されているホストアプリケーションは、そのサイズ変更を管理する。

管理者は、「lun destroy」コマンドを使用することにより、ＬＵＮを削除（破壊）することができる。「lun destroy」コマンドは、ＬＵＮを実現している基礎となるファイルをファイルシステムから削除するコマンドである。

「lun destroy」コマンドの例は次のようなものである。

lun destroy <path name>
ここで、パラメータ<path name>には、削除（破壊）すべきＬＵＮのパス名が指定される。「lun destroy」コマンドを実行すると、ストレージオペレーティングシステムは、ｖｄｉｓｋをファイルシステムから消去する。

ＣＬＩの動作を簡単に要約すると、「igroup」コマンド及び「lun」コマンドは、ユーザ／システム管理者が、ｉｇｒｏｕｐ及びＬＵＮの作成、削除、及び管理を行うために用意される。管理者はまず、ｉｇｒｏｕｐを作成する。ｉｇｒｏｕｐは、１以上のイニシエータＷＷＮ又はｉＳＣＳＩ ＩＤから人間とって分かりやすい論理名へのマッピングである。次にユーザは、「lun create」コマンドを使用して、ＬＵＮ又はｖｄｉｓｋを作成する。次に、システム管理者は、「lun map」コマンドを使用して、作成されたＬＵＮをｉｇｒｏｕｐにマッピングし、そのｉｇｒｏｕｐ内のイニシエータが、そのＬＵＮにアクセスできるようにする。管理者は、ＬＵＮの作成が終わると、「lun resize」コマンドを使用し、変動するシステムの必要性に合わせてＬＵＮのサイズを拡大縮小することができる。ｉｇｒｏｕｐがＬＵＮへのアクセスを何も必要としなくなった場合、「lun unmap」コマンドを使用して、ＬＵＮに対するそのｉｇｒｏｕｐの関連付けを解除することができる。最後に、ＬＵＮが不要になった場合、「lun destroy」コマンドを使用して、そのＬＵＮを削除することができる。

グラフィカルユーザインタフェース
ユーザ又は管理者が、ｖｄｉｓｋ／ｉｇｒｏｕｐコマンドセットに含まれる管理機能に容易にアクセスできるようにするために、マルチプロトコルストレージアプライアンス上でＧＵＩ３５４を実施する場合がある。ＵＩのＧＵＩ部分は、適当なブロックベースの互換性を有するように変更が加えられる。ＣＵＩコマンドの他に、ＧＵＩを設けることにより、管理者は、マニュアルをあまり参照しなくても、及び／又は他の助力を借りなくても、マルチプロトコルストレージアプライアンスを初期化することが可能になる。また、ＧＵＩによれば、ＣＵＩでは得ることのできない補助的なグラフィック、及び／又は表による報告データの表示も可能になる。そのような総合的報告の詳細については、Brian M. Hackworthによる「System and Method for Consolidated Reporting of Characteristics for a Group of File Systems」と題する米国特許出願第０９／８６２，９４９号に記載されている。

ＧＵＩは、ＬＵＮ管理コマンドを実行するためのＣＵＩの代替手段を提供する。また、ＧＵＩは、経験の浅いシステム管理者にとって容易に使用することができ、また、特定のコマンドを探してマニュアルを参照する必要を無くすことにより、ＬＵＮのより迅速な初期化を可能にする。ＧＵＩは、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ(R)環境、Ｘ−Ｗｉｎｄｏｗベースのワークステーション環境、又は他のグラフィカルユーザインタフェースシステム環境のような種々の環境において実施することができる。あるいは、ＧＵＩは、ワールドワイドウェブを介してブラウザによってアクセスされる場合もある。

一実施形態において、ＧＵＩは、一連のメニューオプション、又は他のグラフィカルな対話をＣＬＩコマンドに変換し、例えば、リモートシェル（ＲＳＨ）技術を使用してそのＣＬＩコマンドを実行する。他の実施形態において、ＧＵＩは、要求された動作を実施するためのファイルシステムプリミティブを直接生成するための適当な従来のプログラムコードを含む場合がある。例えば、Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＪＶＭ）３７０（図３に示す）は、ＵＩ３５０のＧＵＩ３５４とのインタフェースとして機能する多数のサーブレット３７５を含む場合がある。サーブレット３７５は、例えば、ワールドワイドウェブを介して遠隔地に表示するためのＨＴＭＬを「オンザフライ」で生成することにより、以下で説明する種々のインタフェース機能を実施することができる。サーブレットは、ストレージオペレーティングシステムのＨＴＴＰ層２２４と直接通信し、ＨＴＭＬ要求を送信し、ユーザ選択を受信する。代替実施形態において、ＧＵＩウェブベースのページの作成は、例えばダイナミックＨＴＭＬ（ＤＨＴＭＬ）やＦｌａｓｈ技術のような、動的リモートグラフィカルユーザインタフェース技術のうちの他の技術を使用して実施してもよい。一方、一実施形態において、ＧＵＩは、特定タスクの生成や特定タスクの実施をユーザに「案内」するための一連の「操作ガイド機能（ウィザード）」を提供する。

Ｅ．Ｖｆｉｌｅｒの動作
本発明によれば、適当なｖｆｉｌｅｒコンテキストの中で、受信データアクセス処理が実施される。ストレージオペレーティングシステムは、例えば、コマンドの送信先である受信ネットワークアドレスを分析することにより、そのコンテキストを判定する。また、ストレージオペレーティングシステムは、所与のＬＵＮに対するアクセスが許可されたｉｇｒｏｕｐに関連するイニシエータだけが、ＬＵＮを変更できるようにする。そのＬＵＮを「所有」するｖｆｉｌｅｒを含む処理の際に、ストレージオペレーティングシステムは、ＬＵＮデータ構造を利用してＬＵＮメタデータをトラッキングする。

図８は、ＬＵＮデータ構造８００の例を示している。ＬＵＮデータ構造８００は、ボリューム名フィールド８０５、パス名フィールド８１０、ボリューム番号８１５、及びアプライアンス名フィールド８２０、アプライアンス番号フィールド８２５、ＰＣＰＩ番号８３０、エキスポートすべきＷＷＮのフィールド８３５、及びｖｆｉｌｅｒフィールド８４０を含み、代替実施形態では、補助的なフィールド８４５を更に含む場合がある。なお、今述べたこれらのフィールドは、単に例示の目的で記載したものであり、本発明の種々の実施形態に従って、更に別のフィールドや異なるフィールドを使用してもよい。ボリューム名フィールド８０５は、ｖｄｉｓｋを含むボリュームを識別する。パス名フィールド８１０は、ボリューム名フィールド８０５において指定されたボリューム上での、ｖｄｉｓｋを含むファイルへのパスを表わす。エキスポートすべきＷＷＮのリストフィールド８３５は、ＬＵＮをエキスポートすべき宛先のクライアントであって、所与のＬＵＮにアクセスすることが可能なＷＷＮのリストを含む。ｖｆｉｌｅｒフィールド８４０は、このＬＵＮがどのｖｆｉｌｅｒに関連付けられているかを識別するフィールドである。ＬＵＮ／ｖｄｉｓｋに対する処理は、ｖｆｉｌｅｒのコンテキストの中で実施しなければならない。ＬＵＮデータオブジェクトの詳細については、「System and Method for Optimized Lun Masking」と題する米国特許出願第１０／６１９，１２２号に記載されている。

一実施形態によれば、ｖｆｉｌｅｒのクライアントは、ｉＳＣＳＩのようなブロックベースのプロトコルを使用してｖｆｉｌｅｒによってエキスポートされたｖｄｉｓｋにアクセスすることができる。図９は、本発明の実施形態に従って、ｖｆｉｌｅｒに送信されたデータアクセス要求を処理する際にｖｆｉｌｅｒによって実施される手順９００のステップの詳細を示すフロー図である。手順９００は、ステップ９０５から開始され、ステップ９１０へ進み、そこで、到来した要求をストレージアプライアンスのネットワークインタフェースにおいて受信する。ネットワークインタフェースには、例えば、従来のイーサネット(R)ＮＩＣが使用される。次に、ステップ９１５で、その要求の宛先アドレス及びインタフェースのＩＰ空間ＩＤに基づいて、その要求を適当なｖｆｉｌｅｒに送信する。例えば、メディアアクセス層のドライバが、特定のｖｄｉｓｋにアクセスするためのｉＳＣＳＩ要求を受信するものと仮定する。上記のように、ネットワークインタフェースは、特定のＩＰ空間に関連付けられている。ネットワークドライバはその要求をＩＰ層に渡し、ＩＰ層は、その要求の宛先ＩＰアドレス及びＩＰ空間ＩＤをＩＰデータベースに記憶されている構成情報と比較し、その要求を所有しているｖｆｉｌｅｒコンテキストを選択する。その結果、特定のｖｆｉｌｅｒコンテキストがその要求に関連付けられる。到来した要求を処理するためのｖｆｉｌｅｒコンテキストの選択については、Gaurav Banga他による「Technique for Enabling Multiple Virtual Filers on a Single Filer to Participate in Multiple Address Spaces with Overlapping Network Address」と題する米国特許出願第１０／０３５，６６６号に記載されている。次に、ステップ９２０で、そのｖｆｉｌｅｒコンテキストを現在のプロセスに設定する。ストレージオペレーティングシステムは、そのｖｆｉｌｅｒコンテキストを使用して、そのｖｆｉｌｅｒコンテキストに関連するデータだけにアクセスを制限する。

ステップ９２５では、受信した要求をストレージオペレーティングシステムのｉＳＣＳＩドライバに渡し、実行させる。次に、ｉＳＣＳＩドライバは、適当なｉＳＣＳＩプロトコルコードを実行し（ステップ９３０）、得られた要求をストレージオペレーティングシステムのＳＣＳＩターゲットモジュールに渡す。ステップ９３５において、ＳＣＳＩターゲットモジュールは、その要求に対して適当なセキュリティチェックを実施する。一実施形態において、それらのセキュリティチェックには、例えば、ｖｄｉｓｋが、データアクセス要求の要求元のイニシエータに適切にマッピングされているか否かを確認することがある。適当なセキュリティチェックが完了した後、ステップ９４０において、ＳＣＳＩターゲットモジュールは、受信したデータアクセス要求を適当なファイルシステムプリミティブに変換し、結果得られたメッセージをファイルシステムに渡し、処理させる。

次に、ステップ９４５において、ファイルシステムは、そのｖｆｉｌｅｒが、ｖｄｉｓｋを含むｑｔｒｅｅ又はボリュームを所有しているか否かを判定する。ｖｆｉｌｅｒが適当なデータコンテナ、例えば、ｑｔｒｅｅ又はボリュームを所有していない場合、手順はステップ９５０へ分岐し、そこで、その要求を拒絶した後、ステップ９７５で手順は完了する。一方、ｖｆｉｌｅｒがｑｔｒｅｅ又はボリュームを所有している場合、手順はステップ９５５へ進み、そこで、ファイルシステムはストレージリソースにアクセスする。次に、ステップ９６０において、受信した要求に対するサービスを提供し、ステップ９６５において応答を生成する。読み出し要求の場合、これは、ｖｄｉｓｋの適当なブロックからデータを取得し、応答を生成することにより達成される。次に、ステップ９７０において、その応答をネットワークを介して元のクライアントに転送した後、手順はステップ９７５において完了する。

もう一度まとめると、要求が、物理的ストレージアプライアンスのネットワークインタフェースにおいて受信されると、その要求の送信先であるｖｆｉｌｅｒが判定される。次に、ｖｆｉｌｅｒコンテキストを設定し、その要求をストレージオペレーティングシステムの種々の層を通して処理する。例えばボリュームやｑｔｒｅｅのようなｖｄｉｓｋの基礎となるデータコンテナの所有権のチェックのような、適当なセキュリティチェックを実施することにより、設定されたｖｆｉｌｅｒコンテキストが、所望の機能を実行実行するための適切なパーミッション（許可）を有しているか否かを確認する。次に、そのコマンドを処理し、要求元のクライアントに返送すべき応答を生成する。

ｖｆｉｌｅｒの更に別の特徴は、ある物理的ストレージアプライアンスから別の物理的ストレージアプライアンスへ移動させることが出来ることにある。移動は、様々な理由によって実施され、例えば、複数の物理的ストレージアプライアンスにわたって、要求の処理のためのロードバランスを取るために実施される場合がある。あるいは、ｖｆｉｌｅｒは災害復旧のために移動される場合がある。例えばｖｆｉｌｅｒのうちの１つを実行している物理的ストレージアプライアンスが故障した場合、ｖｆｉｌｅｒは作成されるが、災害復旧状態になるまで、そのｖｆｉｌｅｒは起動されない。

図１０は、本発明の一実施形態によるｖｆｉｌｅｒの移動を実施するための手順１０００のステップを示している。手順１０００はステップ１００５から開始され、ステップ１０１０へ進み、そこで、例えば、ソースｖｆｉｌｅｒの物理的ストレージアプライアンス上でＣＬＩコマンドを実行することにより、ｖｆｉｌｅｒ移動が開始される。次に、ステップ１０１５において、ｖｆｉｌｅｒのミラーリングを開始する。ミラーリングは、ソースｖｆｉｌｅｒに関連する全てのＬＵＮを、物理的ストレージアプライアンスに移動する。ミラーリングは種々の技術によって実施することができる。そのような技術の１つは、Michael L. Federwisch他による「System and Method for Determining Changes in Two Snapshots and for Transmitting Changes to a Destination Snapshot」と題する米国特許出願第１０／１００，９６７号に記載されており、その内容は参照により本明細書に援用される。ステップ１０２０において、ｖｆｉｌｅｒに関連する全てのＬＵＮはすべて、アンエキスポート（エキスポート解除）される。次に、ステップ１０２５において、何らかの補助的なデータが、宛先に移動される。そのような補助的なデータは、宛先のミラーリングプロセスの完了をソースミラーと同じ時点に近づけることを含む。データが宛先に移動された後、次に、ステップ１０３０において、ソースｖｆｉｌｅｒを破壊し、宛先ストレージアプライアンス上に宛先ｖｆｉｌｅｒを作成する（ステップ１０３５）。

次に、ステップ１０４０において、ｖｆｉｌｅｒ内の隠しディレクトリからメタデータをストレージアプライアンスのルートにコピーする。上記のように、特定メタデータのシャドウコピーは、各ｖｆｉｌｅｒのルートディレクトリに作成される。このシャドウコピーは、実際のメタデータファイルが書き込まれる任意の時点で書き込まれる隠しファイルである。隠しファイルは各ｖｆｉｌｅｒ（内）の「底部」にあるディレクトリに格納されるため、それらの隠しファイルは、移動処理の一部において移動される。したがって、ステップ１０４０において、隠しメタデータファイルは、隠しディレクトリからストレージアプライアンスのルートボリューム内の適当な場所にコピーされる。メタデータがコピーされた後、ステップ１０４５において、管理者は適当な認証を実施する。認証データベースは通常、物理的アプライアンスのルートボリュームに記憶され、ユーザは認証データベースにアクセスすることができず、認証データベースはｖｆｉｌｅｒにミラーリングしたり、ｖｆｉｌｅｒからアクセスすることができない。したがって、認証データベースは通常、管理者が再作成しなければならない。認証情報を再作成するステップは、例えば、管理者が、ＣＨＡＰのような特定タイプの認証を実施した場合に必要となる。そのような構成の場合、ＣＨＡＰデータベースを再作成しなければならない。ただし、他の実施形態において、認証再作成ステップは必要とされない場合もある。

なお、ｖｆｉｌｅｒ移動の一実施形態において、管理者は、「vfiler migrate」コマンドを実施することにより、例えば、データのミラーリングのような、必要とされる全ての移動処理を実施する。代替実施形態において、管理者はまず、「vfiler migrate start」コマンドを発行し、ミラーリング処理を開始するが、「vfiler migrate complete」コマンドが実行されるまで、残りの移動ステップを実施しない。次に、ステップ１０５０において、新たに作成されたｖｆｉｌｅｒからＬＵＮをエキスポートする。そして、プロセスはステップ１０５５において完了する。

もう一度まとめると、本発明は、物理的ストレージアプライアンスにおいて実行される仮想ストレージアプライアンス上にブロックベースのプロトコルを作成し管理するシステム、方法、又はアーキテクチャに関する。これは、上で援用した「Architecture for Creating and Maintaining Virtual Filers on a Filer」と題する米国特許出願に記載されているようなものとは異なる。この米国特許出願に記載されているものは、ファイルレベルのプロトコルに限られる。本発明によるｖｆｉｌｅｒは、マルチプロトコルであり、ブロックベースのプロトコルとファイルベースのプロトコルを両方とも処理することができる。なお、本明細書の説明は、ｉＳＣＳＩを例として記載されているが、本発明の原理は、「ＳＣＳＩ ｅｎｃａｐｓｕｌａｔｅｄ ｉｎ ＦＣ（ＦＣＰ）」のような任意のブロックベースのプロトコルに適用することができる。ＦＣＰ実施形態の場合、物理的ストレージシステム上の複数のｖｆｉｌｅｒ間でネットワークリソースを領域分割するために、複数のＩＤを使用可能なＨＢＡが必要になるであろう。ＵＩのＣＬＩに関連するブロックベースのコマンドは、ｖｆｉｌｅｒコンテキストを認識し、特定のｖｆｉｌｅｒのコンテキストの中で動作するように変更が加えられる。

上記の説明は、本発明の特定の幾つかの実施形態に関するものである。しかしながら、当然ながら、本発明の利点の一部または全部を維持したまま、記載した実施形態に種々の変更及び改変を加えることも可能である。具体的には、任意数のＮＩＣ／ＨＢＡを本発明に従って使用することができる。また、手順及びプロセスは、ハードウェアで実施してもソフトウェアで実施してもよく、プログラム命令、ファームウェア、あるいはそれらの組み合わせを有するコンピュータ読み取り可能媒体として実施してもよい。したがって、添付の特許請求の範囲の目的は、そのような変更も本発明の思想及び範囲の中に含めることにある。

本発明の一実施形態による例示的ストレージシステムを示す略ブロック図である。 本発明と共に使用するのに都合がよいストレージオペレーティングシステムを示す略ブロック図である。 本発明の一実施形態による仮想化システムを示す略ブロック図である。 本発明の一実施形態による、複数の仮想ファイラ（ｖｆｉｌｅｒ）を有するストレージアプライアンスの一実施形態を示す概略図である。 本発明の一実施形態によるｖｆｉｌｅｒコンテキストデータ構造を示す略ブロック図である。 本発明の一実施形態によるｉｆｎｅｔデータ構造を示す略ブロック図である。 本発明の一実施形態による例示的なイニシエータグループデータ構造を示す略ブロック図である。 本発明の一実施形態による例示的なＬＵＮデータ構造を示す略ブロック図である。 本発明の一実施形態による、ｖｆｉｌｅｒに対するデータアクセス要求を処理する手順のステップの詳細を示すフロー図である。 本発明の一実施形態による、ｖｆｉｌｅｒを移動する手順のステップの詳細を示すフロー図である。

Claims (23)

1. １以上のブロックベースのプロトコルを処理するように構成された複数のネットワークリソースと、
   各ｖｆｉｌｅｒが前記ネットワークリソースの論理的分割領域を含み、前記ブロックベースのプロトコルに応答して、データアクセス要求に対するサービスを提供するように構成されたマルチプロトコルサーバのインスタンスを確立するように構成された、１以上のｖｆｉｌｅｒと
   からなるシステム。
2. 前記ネットワークリソースは、１以上のネットワークアドレスリソースに割り当てられたネットワークインタフェースを含む、請求項１に記載のシステム。
3. 情報をストレージリソースの単位として記憶するように構成された記憶媒体を更に含み、前記ストレージリソースの単位は、前記ｖｆｉｌｅｒのそれぞれの間に割り当てられたストレージリソースの単位である、請求項１に記載のシステム。
4. 前記ストレージリソースの単位は、ボリュームからなる、請求項３に記載のシステム。
5. 前記ストレージリソースの単位は、ｑｔｒｅｅからなる、請求項３に記載のシステム。
6. 前記記憶媒体上のストレージリソースの特定の単位にアクセスするための要求が許可されていることを確認するためのバウンダリチェックを実施するように構成されたファイルシステムリソースを有するオペレーティングシステムを更に含み、各ｖｆｉｌｅｒは、前記ファイルシステムに対する共有アクセスを許可され、前記ストレージリソースの単位内に仮想ディスクを生成するように更に構成され、前記仮想ディスクがそれぞれ、前記ｖｆｉｌｅｒのうちの１以上に関連する、請求項３に記載のシステム。
7. 前記オペレーティングシステムは、仮想ディスクに対する処理を実施するように構成されたコマンドセットを有するユーザインタフェースを更に含み、前記コマンドセットが、ｖｆｉｌｅｒのコンテキストの中で実行される、請求項６に記載のシステム。
8. 前記ユーザインタフェースは、前記コマンドセットを利用できるように構成されたコマンドラインインタフェース（ＣＬＩ）からなる、請求項７に記載のシステム。
9. 前記ＣＬＩは、前記ｖｆｉｌｅｒのコンテキストに関連する仮想ディスクに対する処理を実施するように構成されたＬＵＮコマンドを含む、請求項８に記載のシステム。
10. 前記ＬＵＮコマンドは、前記サーバに関連するファイルシステム上に論理ユニット番号を生成し、該論理ユニット番号は、前記ｖｆｉｌｅｒのコンテキストに関連する、請求項９に記載のシステム。
11. 前記ＣＬＩは、イニシエータグループを１以上のイニシエータアドレスにバインドするための１セットのファイルシステムプリミティブを生成するｉｇｒｏｕｐコマンドを含み、前記イニシエータグループは前記仮想サーバのコンテキストに関連する、請求項８に記載のシステム。
12. 前記ブロックベースのプロトコルはｉＳＣＳＩである、請求項１に記載のシステム。
13. 前記ブロックベースのプロトコルはＦＣＰである、請求項１に記載のシステム。
14. 各ｖｆｉｌｅｒに与えられたコンテキストデータ構造を更に含み、前記コンテキストデータ構造は、ｖｆｉｌｅｒのセキュリティドメインに関連する情報を含み、割当て済みの共有リソースに対するアクセスに制限を課す、請求項１に記載のシステム。
15. 前記マルチプロトコルサーバは、１以上のファイルレベルのプロトコルに応答して、データアクセス要求を処理するように更に構成される、請求項１に記載のシステム。
16. ｖｆｉｌｅｒを実施する方法であって、
    １以上のブロックベースのプロトコルを処理するように複数のネットワークリソースを構成するステップと、
    前記ネットワークリソースを領域分割し、１以上のｖｆｉｌｅｒを確立するステップであって、各ｖｆｉｅｌｅｒが、前記ブロックベースのプロトコルに応答して、データアクセス要求に対するサービスを提供するように構成されたマルチプロトコルサーバのインスタンスを含むように、前記ネットワークリソースを領域分割するステップと
    からなる方法。
17. 情報をストレージリソースの単位として記憶するように記憶媒体を構成するステップを更に含み、前記ストレージリソースの単位は、前記ｖｆｉｌｅｒのそれぞれの間に割り当てられる、請求項１６に記載の方法。
18. 前記ストレージリソースの単位はボリュームからなる、請求項１７に記載の方法。
19. 前記ストレージリソースの単位はｑｔｒｅｅからなる、請求項１７に記載の方法。
20. ｖｆｉｌｅｒを実施するための実行可能プログラム命令を含むコンピュータ読み取り可能媒体であって、前記実行可能プログラム命令は、
    １以上のブロックベースのプロトコルを処理するように複数のネットワークリソースを構成するステップと、
    前記ネットワークリソースを領域分割し、１以上のｖｆｉｌｅｒを確立するステップであって、各ｖｆｉｌｅｒが、前記ブロックベースのプロトコルに応答して、データアクセス要求に対するサービスを提供するように構成されたマルチプロトコルサーバのインスタンスを含むように、前記ネットワークリソースを領域分割するステップと
    を実施するためプログラム命令を含む、コンピュータ読み取り可能媒体。
21. 第１の物理的サーバから第２の物理的サーバへｖｆｉｌｅｒを移動させる方法であって、
    第１の物理的サーバから第２の物理的サーバへデータのいミラーリングを開始するステップと、
    前記第１の物理的サーバ上のｖｆｉｌｅｒに関連するＬＵＮをアンエキスポートするステップと、
    前記第１の物理的サーバ上のｖｆｉｌｅｒを破壊するステップと、
    前記第２の物理的サーバ上にｖｆｉｌｅｒを作成するステップと、
    メタデータを隠しディレクトリから前記ｖｆｉｌｅｒのルートディレクトリにコピーするステップと、
    前記第２の物理的サーバ上のｖｆｉｌｅｒに関連するＬＵＮをエキスポートするステップと
    からなる方法。
22. 前記第１の物理的サーバ上のｖｆｉｌｅｒを破壊するステップは、ｖｆｉｌｅｒコンテキストデータ構造を消去するステップからなる、請求項２１に記載の方法。
23. 前記隠しディレクトリは、前記ｖｆｉｌｅｒのルートディレクトリ内のディレクトリからなる、請求項２１に記載の方法。

Images