JP2023110632A - ファイルストレージシステム - Google Patents

Abstract

【課題】ファイルシステムにアクセスするアプリケーションに影響されず簡易にファイル仮想化機能を提供する。【解決手段】ＣＰＦノード１１０は、アプリケーションプログラム４１１およびＩＯ Ｈｏｏｋプログラム４１２をコンテナ化してクライアント６００に提供し、クライアント６００からのファイルの操作要求に基づきアプリケーションプログラム４１１はＩＯ Ｈｏｏｋプログラム４１２が提供する仮想ファイルシステムに対し呼び出し処理を行い、ＩＯ Ｈｏｏｋプログラム４１２は、操作要求にかかる仮想ファイルシステムへの入力情報または操作内容に基づいて、ファイルの状態管理情報の更新処理を行い、ファイル仮想化プログラム４１５は、状態管理情報に基づいてＣＰＦ１００とＣＡＳとの間でファイルの管理処理を行うと共に、当該呼び出し処理を分散ファイルシステムプログラム４１３に出力する。【選択図】図４

Description

本発明は、ファイルストレージシステムに関する。

デジタルデータ、特にファイルデータのデータ量は急速に増大している。データファイル含めてデジタルデータは、例えば、各種の法令要求に対応する為に、多様な目的の為に長期間に亘って保存する必要がある。
このような要請に対し、データセンターにＣＡＳ（Content Addressed Storage）デバイスを配置し、各拠点（例えば、会社の各事業部）にＮＡＳ（Network Attached Storage）デバイスを配置し、ＣＡＳデバイスとＮＡＳデバイスをＷＡＮ（Wide Area Network）等の通信ネットワークで接続し、ＣＡＳデバイス上でデータの集中管理を行うシステムが従来より知られている。一般的に、現用データはそれが使われている限りＮＡＳデバイスに保存され、続いて、アーカイブ目的でＣＡＳデバイスに移行される。

ファイルデータストレージを管理するストレージシステムは、ファイルを操作するクライアントに対してファイルシステムを提供し、また、ＮＡＳデバイスに格納されたファイルを適宜ＣＡＳデバイスにバックアップする。ストレージシステムが提供するバックアップ機能には、ＮＡＳデバイスに生成／更新されたファイルを検知して非同期にＣＡＳデバイスにマイグレーションする機能、クライアントからアクセスされていないファイルをＮＡＳデバイスから削除するスタブ化機能、及び、クライアントから再参照されたときにＣＡＳデバイスからファイルを取得するリストア機能がある。以下、本明細書において、ストレージシステムが提供するマイグレーション機能、スタブ化機能及びリストア機能をファイル仮想化機能と総称する。

本技術分野の背景技術として、特開２０２１－１５７３８１号（特許文献１）がある。この公報には、ＮＡＳにおいてアプリケーションからのファイルの操作要求に基づいてローカルファイルシステムの呼び出し処理を行ってローカルファイルシステムにファイルの操作要求を処理させ、ＩＯ Ｈｏｏｋプログラムが操作要求にかかるローカルファイルシステムへの入力情報または操作内容に基づいて、ファイルの状態管理情報の更新処理を行い、ファイル仮想化プログラムが、状態管理情報に基づいてＮＡＳとＣＡＳとの間でファイルの管理処理を行う技術が開示されている。

特開２０２１－１５７３８１号公報

特許文献１に記載の技術では、ローカルファイルシステムにアクセスするためのプログラム（特許文献１におけるネットワークストレージプログラム）に対しＩＯ Ｈｏｏｋプログラムをライブラリとしてリンクするための作り込みを必要とする。

また近年、ソフトウェア（例えば、OS）の層を追加することによって、ハードウェア（例えば、CPUおよび周辺機器）を仮想化して、ユーザからのハードウェアとのインターフェース方法の詳細を「隠す」技術である仮想化技術が広く用いられており、これによりユーザは、特定のOSや特定のベンダーやハードウェアの特定の構成など、基盤となるインフラストラクチャに強く依存することなく、いくつかの機能を実行するためのコードを書くことができ、また当該機能に基づくサービスを受けることができる。
仮想化技術の一手段であるコンテナ環境では、ローカルファイルシステムにアクセスするプログラムは任意のアプリケーションとなり、ファイル仮想化機能もこれに対応することが要求される。コンテナ環境において特許文献１に記載の技術を適用しようとすると、任意のアプリケーションに対してその都度ＩＯ Ｈｏｏｋプログラムをリンクする作り込みを行うか、あるいはアプリケーションの修正を行う必要が生じ、開発の工数および労力は多大となる。

本発明は上記の課題に鑑みてなされたもので、ファイルシステムにアクセスするアプリケーションに影響されず簡易にファイル仮想化機能を提供できるファイルストレージシステムを提供することにある。

上記課題を解決すべく、本発明の一つの観点に従うファイルストレージシステムは、各々が第１のファイルシステムを提供する複数のストレージノードと、第１のファイルシステムによりファイルが格納される第１のストレージシステムと、を有し、第２のストレージシステムを利用可能なファイルストレージシステムであって、各ストレージノードは、クライアントの要求に基づいてファイルの操作要求を発行するアプリケーションと、ファイルの状態が格納された状態管理情報を管理し、さらにアプリケーションに対し第１のファイルシステムに基づく仮想ファイルシステムを提供する状態情報管理部と、第１のストレージシステム及び第２のストレージシステムに格納されるファイルを管理するファイル仮想化部と、を備え、アプリケーションはファイルの操作要求に基づく仮想ファイルシステムの呼び出し処理を行い、状態情報管理部は、第１のファイルシステムに前記ファイルの操作要求を出力し、操作要求にかかる仮想ファイルシステムへの入力情報または操作内容に基づいて、ファイルの状態管理情報の更新処理を行い、分散ファイルシステムは、ファイルの操作要求を処理し、ファイル仮想化部は、状態管理情報に基づいて、第１のストレージシステムと前記第２のストレージシステムとの間で前記ファイルの管理処理を行う。

本発明によれば、ファイルシステムにアクセスするアプリケーションに影響されず簡易にファイル仮想化機能を提供できるファイルストレージシステムを実現することができる。

実施例に係るファイルストレージシステムのハードウェア構成を示す図である。 実施例に係るファイルストレージシステムのＣＰＦの概略構成の一例を示す図である。 実施例に係るファイルストレージシステムのＣＰＦにおけるコンテナ化の説明図である。 実施例に係るファイルストレージシステムのＣＰＦの概略構成の他の例を示す図である。 実施例に係るファイルストレージシステムのＣＰＦにおけるプログラムの動作のイメージを示す図である。 実施例に係るファイルストレージシステムのコンテナ管理データの一例を示す図である。 実施例に係るファイルストレージシステムのＯＢＪＳの概略構成の一例を示す図である。 実施例に係るファイルストレージシステムのＩＯ Ｈｏｏｋプログラムの機能を説明するための図である。 実施例に係るファイルストレージシステムが提供するファイルシステムを説明するための図である。 実施例に係るファイルストレージシステムの管理情報ファイルの一例を示す図である。 実施例に係るファイルストレージシステムの管理情報ファイルの他の例を示す図である。 実施例に係るファイルストレージシステムのログファイルの一例を示す図である。 実施例に係るファイルストレージシステムのデータベースの一例を示す図である。 実施例に係るファイルストレージシステムのファイル／ディレクトリ作成処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのファイル／ディレクトリ削除処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのリネーム処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのファイルライト処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのファイルリード処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのディレクトリリード処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのログ反映処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのファイルマイグレーション処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのディレクトリマイグレーション処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのファイルスタブ化処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのＯＢＪＳ側ファイル／ディレクトリ削除処理の一例を説明するためのフローチャートである。 実施例に係るファイルストレージシステムのクローリング処理の一例を説明するためのフローチャートである。

以下、図面を参照して本発明の実施形態を説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

なお、実施例を説明する図において、同一の機能を有する箇所には同一の符号を付し、その繰り返しの説明は省略する。

図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。

以下の説明では、「テーブル」、「リスト」、「キュー」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。

また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

同一あるいは同様な機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。

また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ、ＧＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）および／またはインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であれば良く、特定の処理を行う専用回路（例えばＦＰＧＡやＡＳＩＣ）を含んでいてもよい。

また、以下の説明において、「プロセッサ（部）」は、１以上のプロセッサである。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサでもよい。少なくとも１つのプロセッサは、シングルコアでもよいしマルチコアでもよい。

また、少なくとも１つのプロセッサは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサでもよい。

以下の説明において、「インターフェース（部）」は、１以上のインターフェースでよい。この１以上のインターフェースは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし、２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明において、「メモリ部」は、１以上のメモリであり、典型的には主記憶デバイスでよい。メモリ部における少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。

プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

本開示において、記憶デバイスは、１台のＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の１台のストレージドライブ、複数台のストレージドライブを含むＲＡＩＤ装置、及び複数のＲＡＩＤ装置を含む。また、ドライブがＨＤＤである場合には、例えば、ＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ） ＨＤＤを含んでもよく、ＮＬ－ＳＡＳ（ニアラインＳＡＳ） ＨＤＤを含んでもよい。

以下、図面を参照して、実施例を説明する。

図1は、実施例に係るファイルストレージシステムのハードウェア構成を示す図である。

実施例に係るファイルストレージシステム１は、サイト１０－１、１０－２及びクラウド２０を有し、サイト１０－１、１０－２及びクラウド２０間はＷＡＮ（Wide Area Network）であるネットワーク３０により接続されている。なお、図１では２つのサイト１０－１、１０－２が図示されているが、本実施例においてサイトの数に特段の制限はない。

サイト１０－１は、ＣＰＦ（Container Platform）１００、クライアント６００及び管理端末７００を有し、これらＣＰＦ１００、クライアント６００及び管理端末７００はＬＡＮ（Local Area Network）により相互に接続されている。

ＣＰＦ１００の具体的構成については後述する。クライアント６００は各種情報処理が可能なコンピュータ等の情報処理装置であり、ＣＰＦ１００にファイルを格納する、ファイルのリード／ライト処理を行うなど、各種のファイル操作を行う。管理端末７００はＣＰＦ１００の管理を行い、ＣＰＦ１００に異常があった際などにＣＰＦ１００に対して各種操作指示等を行う。

サイト１０－２も、ＣＰＦ１００及びクライアント６００を有する。なお、図１に図示するサイト１０－１、１０－２のハードウェア構成は単なる例示であり、少なくともそれぞれ１台のＣＰＦ１００及びクライアント６００を有する構成であれば、その台数や他のハードウェア構成を有することに制限はない。

クラウド２０はＯＢＪＳ（Object Storage）２００を有する。ＯＢＪＳ２００は、サイト１０－１、１０－２のＣＰＦ１００に格納されたファイルのバックアップ先として機能する。

図２Ａは、実施例に係るファイルストレージシステム１のＣＰＦ１００の概略構成の一例を示す図である。

ＣＰＦ１００はコントローラとしての１又は複数のＣＰＦノード（ストレージノード）１１０と１つのストレージシステム１２０とを有する。

各ＣＰＦノード１１０は、ＣＰＦノード１１０及びＣＰＦ１００全体の動作制御を行うプロセッサ１１１、プロセッサ１１１の動作制御に用いられるプログラム及びデータを記憶するメモリ１１２、クライアント６００からライトされるデータやストレージシステム１２０からリードされたデータを一時的に格納するキャッシュ１１３、サイト１０－１、１０－２内の他のクライアント６００等との間での通信を行うインターフェース（Ｉ／Ｆ）１１４及びストレージシステム１２０との間での通信を行うインターフェース（Ｉ／Ｆ）１１５を有する。

ストレージシステム１２０も、ストレージシステム１２０の動作制御を行うプロセッサ１２１、プロセッサ１２１の動作制御に用いられるプログラム及びデータを記憶するメモリ１２２、ＣＰＦノード１１０からライトされるデータや記憶デバイス１２４からリードされたデータを一時的に格納するキャッシュ１２３、各種のファイルが格納される記憶デバイス１２４及びＣＰＦノード１１０との間での通信を行うインターフェース（Ｉ／Ｆ）１２５を有する。

メモリ１１２には、アプリケーションプログラム４１１、ＩＯ Ｈｏｏｋプログラム４１２、分散ファイルシステムプログラム４１３、データベースプログラム４１４及びファイル仮想化プログラム４１５、コンテナ管理データ４１６が格納されている。
また図示は省略しているが、各ＣＰＦノード１１０ではコンテナ基盤が作動し、各プログラムをコンテナ化してクライアント６００へ提供する。

アプリケーションプログラム４１１は、例えば、Ｅｘｃｅｌ（登録商標）やＷｏｒｄ（登録商標）といったファイルを入出力するあらゆるソフトウェアを含む。アプリケーションプログラム４１１は、クライアント６００からのリクエストに応じて分散ファイルシステム５１０に対してファイル操作を行う。

ＩＯ Ｈｏｏｋプログラム４１２は、後述する本実施例の特徴であるＩＯ Ｈｏｏｋ処理を行うプログラムであり、アプリケーションプログラム４１１が発行するシステムコールが呼び出されたら、ファイルへのＩＯ処理に関する情報を抽出し、ファイル仮想化管理情報の更新処理を行う。さらに、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００を記録する。またＩＯ Ｈｏｏｋプログラム４１２は、アプリケーションプログラム４１１に対して仮想のファイルシステムを提供する。ＩＯ Ｈｏｏｋプログラム４１２の動作の詳細については後述する。

分散ファイルシステムプログラム４１３は、クライアント６００等に対して分散ファイルシステムを提供する。また分散ファイルシステムプログラム４１３は、アプリケーションプログラム４１１からのシステムコールに基づき分散ファイルシステム５１０に対するファイル操作を実行する。
データベースプログラム４１４はデータベース３２００を管理する。
ファイル仮想化プログラム４１５は、ログファイル３１００を監視して記憶デバイス１２４内のファイルのマイグレーションまたはスタブ化またはリストアを行う。

コンテナ管理データ４１６は、各ＣＰＦノード１１０に格納されるプログラムのリストと、当該プログラムが実行されるＣＰＦノード１１０との対応関係が登録されており、各ＣＰＦノード間１１０で共有される。各ＣＰＦノード１１０はコンテナ管理データに基づき自己で実行されるプログラムのコンテナ化および実行と、ＣＰＦノード１１０間でのプログラムの連携を管理する。

図２Ｅは、実施例に係るファイルストレージシステムのコンテナ管理データ４１６の一例を示す図である。コンテナ管理データ４１６は、プログラム４１６１と動作ノード４１６２とを有し、プログラム４１６１は各ＣＰＦノード１１０に格納されるプログラムの名称が格納され、動作ノード４１６２は当該プログラムが実行されるＣＰＦノード１１０の名称が格納される。プログラム４１６１と動作ノード４１６２には、識別子等の各プログラムや各ＣＰＦノードを識別可能な他の情報を格納するようにしてもよい。

管理者は、管理端末７００によっていずれかのＣＰＦノード１１０にアクセスし、
メモリ１１２に格納された各種プログラムから稼働させるプログラムと実行させるＣＰＦノード１１０を選択してコンテナ管理データ４１６へ設定登録することができる。またプログラム４１６１と動作ノード４１６２が設定登録されたコンテナ管理データ４１６は他のＣＰＦノード１１０と共有される。コンテナ管理データ４１６はデータベースプログラム４１４によって共有するようにしてもよい。

記憶デバイス１２４には、データベース３２００、ユーザファイル１２００、ディレクトリ２２００、管理情報ファイル１１００、２１００及びログファイル３１００が格納されており、これらファイルは分散ファイルシステムプログラム４１３が構築する分散ファイルシステム５１０により管理されている。

図２Ｂは、実施例に係るファイルストレージシステムのＣＰＦ１００におけるプログラムのコンテナ化の説明図である。以下、図２Ａで示した構成例に基づき実施例のＣＰＦにおけるプログラムのコンテナ化について説明する。
上述したコンテナ基盤は、稼働させるプログラム４１１～４１５についてコンテナ化に要するメモリ１１２の領域をリソースとして割り当てた上でそれぞれコンテナ化し、クライアント６００にコンテナ２０１～２０５を提供する。

コンテナはコンピュータやオペレーティングシステム（OS）の領域での仮想化技術の一手段であり、OSのカーネル上で、直接ユーザ空間で実行できるプログラムやアプリケーションを仮想化する。コンテナ化されたプログラムやアプリケーションは、OSの通常のシステムコールを使用して機能することができ、コンテナは仮想化されたゲストOSを必要としない。すなわちクライアント６００は自身のOSによらずまた特殊なエミュレーションソフトウェア等を用いることなくＣＰＦのプログラムやアプリケーションを使用することができる。

図２Ｃは、実施例に係るファイルストレージシステムのＣＰＦの概略構成の他の例を示す図である。
この例では、ＣＰＦ１００には物理サーバであるＣＰＦサーバ１０１が設けられ、ＣＰＦサーバ１０１には仮想マシン（Virtual Machine）としての複数のＣＰＦ仮想ノード１１０´が作動する。複数のＣＰＦ仮想ノード１１０´は、ＣＰＦサーバ１０１におけるプロセッサ１１１、キャッシュ１１３およびインターフェース（Ｉ／Ｆ）１１４、１１５等のハード資源を共有しつつ、仮想ノード毎にメモリ１１２の使用領域を分割して割り当てた上でメモリ１１２の各種プログラムを格納し実行することで実現される。
ＣＰＦ仮想ノードの構成・動作については、図２Ａの実施例に係るＣＰＦノード１１０と同一のため説明は省略する。尚、ＣＰＦサーバ１０１は、ファイル操作の処理数や負荷に応じて複数設けるようにしてもよい。

図２Ｄは、実施例に係るファイルストレージシステムのＣＰＦ１００におけるプログラムの動作のイメージを示す図である。図２Ｄは３つのＣＰＦノード１１０－１、１１０－２、１１０－３およびストレージシステム１２０で実行されるプログラムを示している。既に述べたように、各ＣＰＦノード１１０で実行されるプログラムは、管理端末７００によって各ノードのメモリ１１２に格納された各種プログラムから選択され、コンテナ管理データ４１６に設定登録される。

図２Ｄにおいて、ＣＰＦノード１１０－１ではアプリケーションプログラム４１１、ＩＯ Ｈｏｏｋプログラム４１２および分散ファイルシステムプログラム４１３が実行され、ＣＰＦノード１１０－２ではファイル仮想化プログラム４１５および分散ファイルシステムプログラム４１３が実行され、ＣＰＦノード１１０－３では分散ファイルシステムプログラム４１３が実行される。またストレージシステム１２０では分散ファイルシステム５１０が実行される。

本実施例において、(1)アプリケーションプログラム４１１とＩＯ Ｈｏｏｋプログラム４１２は組となって同一のＣＰＦノード１１０で実行される。
既に述べたように、ＩＯ Ｈｏｏｋプログラム４１２はアプリケーションプログラム４１１に対して仮想のファイルシステムを提供しつつ、アプリケーションプログラム４１１が発行するシステムコールからファイルへのＩＯ処理に関する情報を抽出するため、アプリケーションプログラム４１１が実行されるＣＰＦノード１１０で共に実行されることが好適である。

条件(1)に関連し、管理端末７００は実行プログラムをコンテナ管理データ４１６に設定登録する際に、アプリケーションプログラム４１１が登録されたＣＰＦノード１１０に対し自動的にＩＯ Ｈｏｏｋプログラム４１２を設定登録するようにしてもよい。

また本実施例において(2)ＩＯ Ｈｏｏｋプログラム４１２とファイル仮想化プログラム４１５は異なるＣＰＦノード１１０で実行される。
動作の詳細については後述するが、ファイル仮想化プログラム４１５は記憶デバイス１２４内のファイルのマイグレーションまたはスタブ化またはリストアにあたり、ＣＰＦ１００に格納されたファイルのバックアップ先のＯＢＪＳ２００とネットワーク３０を介したデータ通信を伴う分プロセッサの負荷が大きい。一方でＩＯ Ｈｏｏｋプログラム４１２は、アプリケーションプログラム４１１に仮想のファイルシステムを提供しつつ、アプリケーションプログラム４１１が発行するファイル操作要求に伴うシステムコールを監視しており、プログラムの実行頻度が多くなりがちな分こちらもプロセッサの負荷が大きい。
ＩＯ Ｈｏｏｋプログラム４１２とファイル仮想化プログラム４１５が同一のノードで実行されると、ＩＯ Ｈｏｏｋプログラム４１２の実行頻度が多大となるにつれ、ファイル仮想化プログラム４１５の実行に対するプロセッサの負荷も多大となり、上記マイグレーションまたはスタブ化またはリストアの各処理の遅延やこれに伴う更新データとの間の齟齬等が発生し、ファイルデータの信頼性に影響を及ぼすおそれがある。

条件(2)に関連し、管理端末７００は実行プログラムをコンテナ管理データ４１６に設定登録する際に、ＩＯ Ｈｏｏｋプログラム４１２が登録されたＣＰＦノード１１０に対しファイル仮想化プログラム４１５が選択できないようにしてもよい。

また各ＣＰＦノード１１０では分散ファイルシステムプログラム４１３が実行されるが、このうち１つをマスタとし、他がスレイブとして動作するようにしてもよい。例えばＣＰＦノード１１０－３の分散ファイルシステムプログラム４１３をマスタとすると、他のＣＰＦノード１１０－１、１１０－２の分散ファイルシステムプログラム４１３から、それぞれが受領した分散ファイルシステム５１０に対するファイル操作のシステムコールが転送され、マスタの分散ファイルシステムプログラム４１３がファイル操作を実行する。このようにマスタの分散ファイルシステムプログラムにファイル操作を一局集中して行わせることで、各ＣＰＦノード１１０の負荷を分散させ他のプログラムの実行にリソースを集中させることができる。

尚、図２ＤはＣＰＦノード１１０が３つの場合について示しているが、ＣＰＦノード１１０の数はこれに限らない。また上記 (1)(2)の条件を満たす限り、各ＣＰＦノード１１０と作動するプログラムの組み合わせは図２Ｄの例に限られるものではない。

図３は、実施例に係るファイルストレージシステム１のＯＢＪＳ２００の概略構成の一例を示す図である。

ＯＢＪＳ２００はコントローラとしてのヘッド２１０とストレージシステム２２０とを有する。

ヘッド２１０は、ヘッド２１０及びＯＢＪＳ２００全体の動作制御を行うプロセッサ２１１、プロセッサ２１１の動作制御に用いられるプログラム及びデータを記憶するメモリ２１２、ＣＰＦ１００からライトされるデータやストレージシステム２２０からリードされたデータを一時的に格納するキャッシュ２１３、サイト１０－１、１０－２との間での通信を行うインターフェース（Ｉ／Ｆ）２１４及びストレージシステム２２０との間での通信を行うインターフェース（Ｉ／Ｆ）２１５を有する。

ストレージシステム２２０も、ストレージシステム２２０の動作制御を行うプロセッサ２２１、プロセッサ２２１の動作制御に用いられるプログラム及びデータを記憶するメモリ２２２、ヘッド２１０からライトされるデータや記憶デバイス２２４からリードされたデータを一時的に格納するキャッシュ２２３、各種のファイルが格納される記憶デバイス２２４及びヘッド２１０との間での通信を行うインターフェース（Ｉ／Ｆ）２２５を有する。

メモリ２１２には、ネットワークストレージプログラム４２１、ローカルファイルシステムプログラム４２２及びファイル仮想化プログラム４２３が格納されている。

ネットワークストレージプログラム４２１は、ＣＰＦ１００からの各種要求を受領し、この要求に含まれるプロトコルを処理する。

ローカルファイルシステムプログラム４２２は、ＣＰＦ１００に対してファイルシステムを提供する。尚、使用するファイルシステムプログラムはローカルファイルシステムプログラム４２２に限らず、分散ファイルシステムを使用しても構わない。

ファイル仮想化プログラム４２３は、ＣＰＦノード１１０のファイル仮想化プログラム４１５と協同して、ＣＰＦ１００の記憶デバイス１２４内のファイルのマイグレーションまたはスタブ化またはリストアを行う。

記憶デバイス２２４には、ユーザファイル１２００及びディレクトリ２２００が格納されており、これらファイルはローカルファイルシステムプログラム４２２が構築するローカルファイルシステム５２０により管理されている。

図４は、実施例に係るファイルストレージシステム１のＩＯ Ｈｏｏｋプログラム４１２の機能を説明するための図である。尚、図４では説明簡略化のためアプリケーションプログラム４１１、ＩＯ Ｈｏｏｋプログラム４１２および分散ファイルシステムプログラム４１３は一つのＣＰＦノード１１０で動作するものとして説明する。

クライアント６００は、クライアントプログラム６０１を有する。クライアントプログラム６０１は、クライアント６００のリクエストに応じて、ＣＰＦ１００のアプリケーションプログラム４１１と通信するためのソフトウェアであり、ＣＰＦ１００のプロトコルでＣＰＦノード１１０に対してアプリケーションの操作を介してファイル操作のリクエストをする。クライアントプログラム６０１は、例えばリモートアクセスアプリケーションやＷＷＷ(World Wide Web)ブラウザソフト（ＣＰＦ１００のプロトコルがインターネットの場合）である。

ＣＰＦノード１１０においてアプリケーションプログラム４１１は、このリクエストに応じてＩＯ Ｈｏｏｋプログラム４１２が提供する仮想ファイルシステムに対してファイル操作を行う。後述するように仮想ファイルシステムは分散ファイルシステムプログラム４１３が提供する分散ファイルシステム５１０を疑似したものであり、このような制御によりＩＯ Ｈｏｏｋプログラム４１２はアプリケーションプログラム４１１から分散ファイルシステム５１０を想定したファイル操作のシステムコールの発行を受けることで当該システムコールを認識できる。
また既に述べたように本実施例ではアプリケーションプログラム４１１およびＩＯ Ｈｏｏｋプログラム４１２はそれぞれコンテナ基盤にてコンテナ化されてクライアント６００に提供され、これらは互いの動作環境や仕様に影響せず独立して作動する。

ＩＯ Ｈｏｏｋプログラム４１２が提供する仮想ファイルシステムに対しアプリケーションプログラム４１１がシステムコールを発行すると、ＩＯ Ｈｏｏｋプログラム４１２は仮想ファイルシステムへのファイル操作のＡＰＩからファイルへのＩＯ処理に関する情報を抽出し、ファイル仮想化管理情報の更新処理を行い、また、ログを出力する。尚、ＩＯ処理に関する情報の抽出対象はシステムコールに限らず、例えば分散ファイルシステム５１０が提供する固有のＡＰＩとしても構わない。
ＩＯ処理に関する情報を抽出した上で、ＩＯ Ｈｏｏｋプログラム４１２は、アプリケーションプログラム４１１が発行した仮想ファイルシステムへのファイル操作のＡＰＩを分散ファイルシステム５１０へ出力し、これにより分散ファイルシステム５１０に対し所望のファイル操作が行われる。

図５は、実施例に係るファイルストレージシステム１が提供するファイルシステムを説明するための図である。

既に説明したように、ＣＰＦ１００（のストレージシステム１２０）には分散ファイルシステム５１０が構築されており、この分散ファイルシステム５１０は、一例として、ルートディレクトリ２２００－０、ディレクトリ２２００－１を有する。各々のディレクトリ２２００－０、２２００－１は管理情報ファイル２１００－１、２１００－２を有する。ディレクトリ２２００－１には、一例としてファイル１２００－１、１２００－２が格納されている。また、ディレクトリ２２００－１には、これらファイル１２００－１、１２００－２の管理情報ファイル１１００－１、１１００－２が格納されている。

ＩＯ Ｈｏｏｋプログラム４１２がアプリケーションプログラム４１１に提供する仮想ファイルシステムも、上述した分散ファイルシステム５１０と同様の構成である。仮想ファイルシステムには、分散ファイルシステム５１０に加えて、スタブ化されたファイル、すなわちＯＢＪＳ２００にバックアップされ分散ファイルシステム５１０から削除されたファイルを併せて提供するようにしてもよい。
コンテナ基盤がアプリケーションプログラム４１１の起動時にアプリケーションプログラム４１１に仮想ファイルシステムをマウントすることで、クライアント６００はアプリケーションプログラム４１１を介して各種ファイル操作を行うことができる。但し管理情報ファイルについては、ＩＯ Ｈｏｏｋプログラム４１２が情報をフィルタするため、仮想ファイルシステム上には登場せず、操作もできない。

ＯＢＪＳ２００にもローカルファイルシステム５２０が構築されている。ローカルファイルシステム５２０は階層構造を持たず、ルートディレクトリの下に全てのディレクトリ２３００－０、２３００－１及びファイル１２００－１、１２００－２が配置されている。ＯＢＪＳ２００においては、それぞれのディレクトリ２３００－０、２３００－１、ファイル１２００－１、１２００－２はＵＵＩＤ（Universally Unique Identifier）により一意に特定される。

図６は、実施例１に係るファイルストレージシステム１の管理情報ファイル２１００の一例を示す図である。

管理情報ファイル２１００は、ユーザディレクトリ管理情報２１１０を有する。ユーザディレクトリ管理情報２１１０は、ＵＵＩＤ毎にエントリを有する。各エントリは、ユーザディレクトリ２２００に付与されたＵＵＩＤ２１１１、ユーザディレクトリ２２００のディレクトリ状態２１１２、ユーザディレクトリ２２００の本体ハンドラ２１１３、マイグレーション有無２１１４である。

ディレクトリ状態２１１２は、前回のバックアップからこのユーザディレクトリ２２００が更新されたか否かを示す値であり、Ｄｉｒｔｙとはファイルが更新されたことを示す値である。本体ハンドラ２１１３はユーザディレクトリ２２００を一意に特定する値であり、システムコールで操作対象としてユーザディレクトリ２２００を指定するために使用できる値である。本体ハンドラ２１１３には、ユーザディレクトリ２２００の生成から削除までの間に変更がない値を用いる。マイグレーション有無２１１４は、このユーザディレクトリ２２００が一度でもバックアップされたことがあるか否かを示す値である。

ユーザディレクトリ２２００はファイル／ディレクトリ名２２０１及びＩｎｏｄｅ番号（＃）２２０２を有する。図６に示す例は図５におけるディレクトリ（ｄｉｒ１）２２００－１であり、このディレクトリ２２００－１には２つのファイル（Ｆｉｌｅ１、Ｆｉｌｅ２）が格納されている。Ｉｎｏｄｅ番号２２０２は、それぞれのファイル（Ｆｉｌｅ１、Ｆｉｌｅ２）に一意に付与されたＩｎｏｄｅ番号である。

ＯＢＪＳ用ディレクトリ２３００はファイル／ディレクトリ名２３０１及びＩｎｏｄｅ番号（＃）２３０２を有する。ファイル／ディレクトリ名２３０１はユーザディレクトリ２２００のファイル／ディレクトリ名２２０１と同一であるが、Ｉｎｏｄｅ番号２３０２については、ＣＰＦ１００からＯＢＪＳ２００へのマイグレーションの際にＵＵＩＤに書き換えられる。これは、Ｉｎｏｄｅ番号はＣＰＦ１００内においてのみ一意に定められるものであり、マイグレーションの際にはＯＢＪＳ２００内において一意に定められるＵＵＩＤを振る必要があるからである。

図７は、実施例に係るファイルストレージシステム１の管理情報ファイル１１００の他の例を示す図である。

管理情報ファイル１１００は、ユーザファイル管理情報１１１０及び部分管理情報１１２０を有する。

ユーザファイル管理情報１１１０は、ＵＵＩＤ毎にエントリを有する。各エントリは、ユーザファイル１２００に付与されたＵＵＩＤ１１１１、ユーザファイル１２００のファイル状態１１１２、ユーザファイル１２００の本体ハンドラ１１１３、マイグレーション有無２１１４である。

部分管理情報１１２０はユーザファイル１２００毎に作成される。部分管理情報１１２０は、オフセット１１２１、長さ１１２２及び部分状態１１２３を有する。オフセット１１２１は、ユーザファイル１２００が部分的に更新処理されたときのその更新処理の開始位置を示し、長さ１１２２はオフセット１１２１の位置からどれだけのデータ長だけ更新処理がされたかを示し、部分状態１１２３はどのような更新処理がされたかを示す。ここに、Ｄｉｒｔｙ１２０１は前回のバックアップ処理後に更新されたことを示し、Ｓｔｕｂ２２０３はバックアップ処理後にローカル（つまりＣＰＦ１００）から消去されたことを示し、Ｃａｃｈｅｄ２２０２はローカルにもデータがあり、バックアップもあることを示す。

図８は、実施例に係るファイルストレージシステム１のログファイル３１００の一例を示す図である。

ログファイル３１００は、ＡＰＩ名３１０１、引数３１０２、返り値３１０３、タイプ３１０４、Ｉｎｏｄｅ番号３１０５、管理情報ファイルハンドラ３１０６、親Ｉｎｏｄｅ番号３１０７、実行状態３１０８及びタイムスタンプ３１０９を有する。ログファイル３１００の各行は、アプリケーションプログラム４１１からＩＯ Ｈｏｏｋプログラム４１２の提供する仮想ファイルシステムへのシステムコールがある毎に作成される。

ＡＰＩ名３１０１はシステムコールの種類を示し、おおよそｗｒｉｔｅ、ｒｅａｄ、ｏｐｅｎ、ｃｌｏｓｅの値が格納される。引数３１０２はシステムコールの引数であり、おおよそファイルディスクリプタ、ファイル操作開始位置及びデータサイズを有する。返り値３１０３はシステムコールの結果として分散ファイルシステム５１０から返ってくる値であり、Ｎ．Ａ．はシステムコール実行中のためまだ返り値がないことを示し、０は正常に実行されたことを示す。これ以外にも分散ファイルシステム５１０により定められた値が格納される。タイプ３１０４はシステムコールの対象となるものがファイルであるのかディレクトリであるのかを示す値である。Ｉｎｏｄｅ番号はシステムコールの対象となるファイル等のＩｎｏｄｅ番号である。管理情報ファイルハンドラ３１０６はシステムコールの対象となるファイル等を一意に特定する値であり、システムコールでのファイルやディレクトリ操作での操作対象指定に使用できる値である。管理情報ファイルハンドラ３１０６は、ファイルやディレクトリの生成から削除まで変更がない。親Ｉｎｏｄｅ番号３１０７は、システムコールの対象となるファイル等の上位（親）のディレクトリのＩｎｏｄｅ番号である。これは、システムコールによりファイルやディレクトリが移動または削除された場合、バックアップ処理の対象として親ディレクトリを特定する必要があるからである。実行状態３１０８はシステムコールの実行状態を示す値が格納される。タイムスタンプ３１０９はシステムコールが呼び出された時刻である。

図９は、実施例に係るファイルストレージシステム１のデータベース３２００の一例を示す図である。

データベース３２００はＩｎｏｄｅ番号３２０１、タイプ３２０２、管理情報ファイルハンドラ３２０３、Ｄｉｒｔｙ部有無３２０４、非Ｓｔｕｂ部有無３２０５及び削除フラグ３２０６を有する。データベース３２００の各行は、分散ファイルシステム５１０内のディレクトリ及びファイル毎に作成される。

Ｉｎｏｄｅ番号３２０１はディレクトリまたはファイルのＩｎｏｄｅ番号である。タイプ３２０２はＩｎｏｄｅ番号３２０１で特定されるものがファイルであるのかディレクトリであるのかを示す値である。管理情報ファイルハンドラ３２０３は対象となるファイル等を一意に特定する値である。Ｄｉｒｔｙ部有無３２０４は、ディレクトリに格納されたファイルまたはファイルそのものの一部にでもＤｉｒｔｙ部があるか否かを示す値が格納される。非Ｓｔｕｂ部有無３２０５は、前回のバックアップ処理後にデータが一部でも書き換えられている部分があるか否かを示す値が格納される。削除フラグ３２０６はディレクトリに格納されたファイルまたはファイルそのものが削除されているか否かを示す値が格納される。

次に、図１０～図２１のフローチャートを参照して、本実施例のファイルストレージシステム１の動作について説明する。

図１０は、実施例に係るファイルストレージシステム１のファイル／ディレクトリ作成処理の一例を説明するためのフローチャートである。

ファイル／ディレクトリ作成処理が開始すると（ステップＳ１００）、まず、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００に作成処理の開始を追記する（ステップＳ１０１）。

次いで、ＩＯ Ｈｏｏｋプログラム４１２は、アプリケーションプログラム４１１からのシステムコールに基づいてユーザファイル１２００／ディレクトリ２２００の作成処理を実施する（ステップＳ１０２）。次いで、ＩＯ Ｈｏｏｋプログラム４１２は管理情報ファイル１１００、２１００を作成する（ステップＳ１０３）。次いで、ＩＯ Ｈｏｏｋプログラム４１２は、作成対象のファイル／ディレクトリの親ディレクトリの管理情報ファイル２１００のディレクトリ状態２１１２をＤｉｒｔｙに更新する（ステップＳ１０４）。

そして、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００に作成処理の完了を追記し（ステップＳ１０５）、作成処理の完了をアプリケーションプログラム４１１に応答する（ステップＳ１０６）。

図１１は、実施例に係るファイルストレージシステム１のファイル／ディレクトリ削除処理の一例を説明するためのフローチャートである。

ファイル／ディレクトリ削除処理が開始すると（ステップＳ２００）、まず、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００に削除処理の開始を追記する（ステップＳ２０１）。

次いで、ＩＯ Ｈｏｏｋプログラム４１２は、削除対象のファイル／ディレクトリにマイグレーションが有るか否かを判定する（ステップＳ２０２）。マイグレーションの有無は、管理情報ファイル１１００、２１００のマイグレーションの有無１１１４、２１１４で確認することができる。そして、判定が肯定されたら（ステップＳ２０２においてＹＥＳ）、プログラムはステップＳ２０３に移行し、判定が否定されたら（ステップＳ２０２においてＮＯ）、プログラムはステップＳ２０６に移行する。

ステップＳ２０３において、ＩＯ Ｈｏｏｋプログラム４１２は管理情報ファイル１１００、２１００とユーザファイル１２００をゴミ箱ディレクトリに移動し、次いで、ＩＯ Ｈｏｏｋプログラム４１２はユーザファイル１２００の中身を空にする（ステップＳ２０４）。そして、ＩＯ Ｈｏｏｋプログラム４１２は、対応する管理情報ファイル１１００、２１００のファイル状態１１１２／ディレクトリ状態２１１２をＤｅｌｅｔｅｄに更新し、部分管理情報１１２０を消去する（ステップＳ２０５）。

一方、ステップＳ２０６において、ＩＯ Ｈｏｏｋプログラム４１２は管理情報ファイル１１００、２１００を消去し、次いで、ユーザファイル１２００／ユーザディレクトリ２２００の削除処理を実行する（ステップＳ２０７）。

次いで、ＩＯ Ｈｏｏｋプログラム４１２は、作成対象のファイル／ディレクトリの親ディレクトリの管理情報ファイル２１００のディレクトリ状態２１１２をＤｉｒｔｙに更新する（ステップＳ２０８）。そして、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００に削除処理の完了を追記し（ステップＳ２０９）、削除処理の完了をアプリケーションプログラム４１１に応答する（ステップＳ２１０）。

図１２は、実施例に係るファイルストレージシステム１のリネーム処理の一例を説明するためのフローチャートである。

リネーム処理が開始すると（ステップＳ３００）、まず、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００にリネーム処理の開始を追記する（ステップＳ３０１）。

次に、ＩＯ Ｈｏｏｋプログラム４１２は通常のリネーム処理を実施する（ステップＳ３０２）。次いで、ＩＯ Ｈｏｏｋプログラム４１２は、リネーム対象の移動先ディレクトリに対応する管理情報ファイル２１００のディレクトリ状態２１１２をＤｉｒｔｙに更新し（ステップＳ３０３）、さらに、ＩＯ Ｈｏｏｋプログラム４１２は、リネーム対象の移動元ディレクトリに対応する管理情報ファイル２１００のディレクトリ状態２１１２をＤｉｒｔｙに更新する（ステップＳ３０４）。

そして、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００にリネーム処理の完了を追記し（ステップＳ３０５）、リネーム処理の完了をアプリケーションプログラム４１１に応答する（ステップＳ３０６）。

図１３は、実施例に係るファイルストレージシステム１のファイルライト処理の一例を説明するためのフローチャートである。

ファイルライト処理が開始すると（ステップＳ４００）、まず、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００にライト処理の開始を追記する（ステップＳ４０１）。

次に、ＩＯ Ｈｏｏｋプログラム４１２はユーザファイル１２００に通常のライト処理を実施する（ステップＳ４０２）。次いで、ＩＯ Ｈｏｏｋプログラム４１２は、対応する管理情報ファイル１１００のファイル状態１１１２をＤｉｒｔｙに更新する（ステップＳ４０３）。

そして、ＩＯ Ｈｏｏｋプログラム４１２はログファイル３１００にライト処理の完了を追記し（ステップＳ４０４）、ライト処理の完了をアプリケーションプログラム４１１に応答する（ステップＳ４０５）。

図１４は、実施例に係るファイルストレージシステム１のファイルリード処理の一例を説明するためのフローチャートである。

ファイルリード処理が開始すると（ステップＳ５００）、まず、ＩＯ Ｈｏｏｋプログラム４１２は対応する管理情報ファイル１１００を取得する（ステップＳ５０１）。

次いで、ＩＯ Ｈｏｏｋプログラム４１２は、リード対象箇所がスタブ化された部分を含むかどうかを判定する（ステップＳ５０２）。そして、判定が肯定されたら（ステップＳ５０２においてＹＥＳ）、プログラムはステップＳ５０３に移行し、判定が否定されたら（ステップＳ５０２においてＮＯ）、プログラムはステップＳ５０６に移行する。

ステップＳ５０３では、ＩＯ Ｈｏｏｋプログラム４１２が、リード対象箇所内のスタブ化された部分のデータをＯＢＪＳ２００に要求する。ＯＢＪＳ２００のファイル仮想化プログラム４２３は、ＩＯ Ｈｏｏｋプログラム４１２からの要求に基づいて当該データをＣＰＦ１００に転送する（ステップＳ５０４）。

次いで、ＩＯ Ｈｏｏｋプログラム４１２は、管理情報ファイル１１００内のリコール部、すなわちＯＢＪＳ２００から転送されたデータの部分状態１１２３をＣａｃｈｅｄに更新する（ステップＳ５０５）。

そして、ＩＯ Ｈｏｏｋプログラム４１２はユーザファイル１２００に通常のリード処理を実施し（ステップＳ５０６）、リード処理の完了をアプリケーションプログラム４１１に応答する（ステップＳ５０７）。

図１５は、実施例に係るファイルストレージシステム１のディレクトリリード処理の一例を説明するためのフローチャートである。

ディレクトリリード処理が開始すると（ステップＳ６００）、まず、ＩＯ Ｈｏｏｋプログラム４１２は対応する管理情報ファイル２１００を取得する（ステップＳ６０１）。

次いで、ＩＯ Ｈｏｏｋプログラム４１２は、リード対象にディレクトリがスタブ化された状態かどうかを判定する（ステップＳ６０２）。そして、判定が肯定されたら（ステップＳ６０２においてＹＥＳ）、プログラムはステップＳ６０３に移行し、判定が否定されたら（ステップＳ６０２においてＮＯ）、プログラムはステップＳ６０７に移行する。

ステップＳ６０３では、ＩＯ Ｈｏｏｋプログラム４１２が、リード対象のＯＢＪＳ用ディレクトリ２３００の取得要求をＯＢＪＳ２００に転送する。ＯＢＪＳ２００のファイル仮想化プログラム４２３は、ＩＯ Ｈｏｏｋプログラム４１２からの要求に基づいて当該データをＣＰＦ１００に転送する（ステップＳ６０４）。

次に、ＩＯ Ｈｏｏｋプログラム４１２は、ＯＢＪＳ２００より取得したデータでユーザディレクトリ２２００を更新し（ステップＳ６０５）、管理情報ファイル２１００のディレクトリ状態２１１２をＣａｃｈｅｄに更新する（ステップＳ６０６）。

そして、ＩＯ Ｈｏｏｋプログラム４１２はユーザディレクトリ２２００に通常のリード処理を実施し（ステップＳ６０７）、クライアント６００から管理情報ファイル２１００が見えないようにリード結果から管理情報ファイル２１００の情報を消去し（ステップＳ６０８）、リード処理の完了をアプリケーションプログラム４１１に応答する（ステップＳ６０９）。

図１６は、実施例に係るファイルストレージシステム１のログ反映処理の一例を説明するためのフローチャートである。

ログ反映処理が開始すると（ステップＳ１３０１）、ファイル仮想化プログラム４１５はログファイル３１００の実行状態３１０８を参照して、ログファイル３１００から完了した操作のリストを取得する（ステップＳ１３０２）。

次いで、ファイル仮想化プログラム４１５は、ステップＳ１３０２で取得したリストが空であるかどうかを判定する（ステップＳ１３０３）。その結果、判定が肯定されたら（ステップＳ１３０３においてＹＥＳ）プログラムはステップＳ１３１４に移行し、判定が否定されたら（ステップＳ１３０３においてＮＯ）プログラムはステップＳ１３０４に移行する。

ステップＳ１３０４では、ファイル仮想化プログラム４１５が、ステップＳ１３０２で取得したリストからエントリを１つ取得する。次いで、ファイル仮想化プログラム４１５は、ステップＳ１３０４で取得したエントリがライト処理であるか否かを判定する（ステップＳ１３０５）。そして、判定が肯定されたら（ステップＳ１３０５においてＹＥＳ）プログラムはステップＳ１３０６に移行し、判定が否定されたら（ステップＳ１３０５においてＮＯ）プログラムはステップＳ１３０７に移行する。

ステップＳ１３０６では、ファイル仮想化プログラム４１５が、データベース３２００の操作対象のエントリのＤｉｒｔｙ部有無３２０４及び非Ｓｔｕｂ部有無３２０５をそれぞれありにする。

ステップＳ１３０７では、ファイル仮想化プログラム４１５が、ステップＳ１３０４で取得したエントリが作成処理であるか否かを判定する。そして、判定が肯定されたら（ステップＳ１３０７においてＹＥＳ）プログラムはステップＳ１３０８に移行し、判定が否定されたら（ステップＳ１３０７においてＮＯ）プログラムはステップＳ１３１０に移行する。

ステップＳ１３０８では、ファイル仮想化プログラム４１５が、データベース３２００の操作対象のエントリを作成し、作成したエントリのＤｉｒｔｙ部有無３２０４及び非Ｓｔｕｂ部有無３２０５をそれぞれありにし、削除フラグ３２０６の値をＦａｌｓｅにする。さらに、ファイル仮想化プログラム４１５は、データベース３２００の操作対象の親ディレクトリのエントリのＤｉｒｔｙ部有無３２０４及び非Ｓｔｕｂ部有無３２０５をそれぞれありにする（ステップＳ１３０９）。

ステップＳ１３１０では、ファイル仮想化プログラム４１５が、ステップＳ１３０４で取得したエントリが削除処理であるか否かを判定する。そして、判定が肯定されたら（ステップＳ１３１０においてＹＥＳ）プログラムはステップＳ１３１１に移行し、判定が否定されたら（ステップＳ１３１０においてＮＯ）プログラムはステップＳ１３１２に移行する。

ステップＳ１３１１では、ファイル仮想化プログラム４１５が、データベース３２００の操作対象のエントリのＤｉｒｔｙ部有無３２０４及び非Ｓｔｕｂ部有無３２０５をそれぞれなしにして、さらに、削除フラグ３２０６をＴｒｕｅにする。

ステップＳ１３１２では、ファイル仮想化プログラム４１５が、ステップＳ１３０４で取得したエントリがリネーム処理であるか否かを判定する。そして、判定が肯定されたら（ステップＳ１３１２においてＹＥＳ）プログラムはステップＳ１３０９に移行し、判定が否定されたら（ステップＳ１３１２においてＮＯ）プログラムはステップＳ１３１３に移行する。

ステップＳ１３１３では、ファイル仮想化プログラム４１５が、ステップＳ１３０２で取得したリストからエントリを削除する。

一方、ステップＳ１３１４では、ファイル仮想化プログラム４１５が処理を完了したログを削除する。

図１７では、実施例に係るファイルストレージシステムのファイルマイグレーション処理の一例を説明するためのフローチャートである。

ファイルマイグレーション処理が開始すると（ステップＳ７００）、ファイル仮想化プログラム４１５は、データベース３２００から、Ｄｉｒｔｙ部有無３２０４がありでタイプ３２０２がファイルのエントリをリストとして取得する（ステップＳ７０１）。

次いで、ファイル仮想化プログラム４１５は、ステップＳ７０１で取得したファイルリストが空であるかどうかを判定する（ステップＳ７０２）。その結果、判定が肯定されたら（ステップＳ７０２においてＹＥＳ）プログラムはステップＳ７１２に移行し、判定が否定されたら（ステップＳ７０２においてＮＯ）プログラムはステップＳ７０３に移行する。

ステップＳ７０３では、ファイル仮想化プログラム４１５が、ステップＳ７０１で取得したリストからエントリを１つ取得する。次いで、ファイル仮想化プログラム４１５は、ステップＳ７０３で取得したエントリが示す管理情報ファイル１１００を取得する（ステップＳ７０４）。次いで、ファイル仮想化プログラム４１５は、ステップＳ７０４で取得した管理情報ファイル１１００の部分管理情報１１２０から、Ｄｉｒｔｙのエントリを転送部分リストとして取得し（ステップＳ７０５）、取得した転送部分リストの該当箇所をユーザファイル１２００から取得する（ステップＳ７０６）。

次に、ファイル仮想化プログラム４１５は、管理情報ファイル１１００中のＵＵＩＤ１１１１への更新要求とともに、ステップＳ７０５で取得した転送部分リストとステップＳ７０６で取得したユーザファイル１２００からデータとをＯＢＪＳ２００に転送する（ステップＳ７０７）。

ＯＢＪＳ２００のファイル仮想化プログラム４２３は、ＵＵＩＤで特定されるＯＢＪＳ２００内のユーザファイル１２００から、ステップＳ７０７で受領した転送部分リストの示す箇所を更新し（ステップＳ７０８）、ＣＰＦ１００に更新の完了を返す（ステップＳ７０９）。

そして、ファイル仮想化プログラム４１５は、管理情報ファイル１１００のファイル状態１１１２と転送部分リストの該当箇所の部分状態１１２３をＣａｃｈｅｄにし（ステップＳ７１０）、ステップＳ７０１で取得したファイルリストからエントリを削除する（ステップＳ７１１）。

一方、ステップＳ７１２において、ファイル仮想化プログラム４１５は、データベース３２００から操作を完了したエントリのＤｉｒｔｙ部有無３２０４をなしにする。

図１８は、実施例に係るファイルストレージシステム１のディレクトリマイグレーション処理の一例を説明するためのフローチャートである。

ディレクトリマイグレーション処理が開始すると（ステップＳ８００）、ファイル仮想化プログラム４１５は、データベース３２００から、Ｄｉｒｔｙ部有無３２０４がありでタイプ３２０２がディレクトリのエントリをリストとして取得する（ステップＳ８０１）。

次いで、ファイル仮想化プログラム４１５は、ステップＳ８０１で取得したファイルリストが空であるかどうかを判定する（ステップＳ８０２）。その結果、判定が肯定されたら（ステップＳ８０２においてＹＥＳ）プログラムはステップＳ８１２に移行し、判定が否定されたら（ステップＳ８０２においてＮＯ）プログラムはステップＳ８０３に移行する。

ステップＳ８０３では、ファイル仮想化プログラム４１５が、ステップＳ８０１で取得したリストからエントリを１つ取得する。次いで、ファイル仮想化プログラム４１５は、ステップＳ８０３で取得したエントリが示す管理情報ファイル２１００を取得する（ステップＳ８０４）。次いで、ファイル仮想化プログラム４１５は、ステップＳ８０４で取得した管理情報ファイル２１００の示すユーザディレクトリ２２００を取得し（ステップＳ８０５）、取得したユーザディレクトリ２２００に基づいてＯＢＪＳ用ディレクトリ２３００の情報を生成する（ステップＳ８０６）。

次に、ファイル仮想化プログラム４１５は、管理情報ファイル２１００中のＵＵＩＤ２１１１への更新要求とともに、ステップＳ８０６で生成したＯＢＪＳ用ディレクトリ２３００の情報をＯＢＪＳ２００に転送する（ステップＳ８０７）。

ＯＢＪＳ２００のファイル仮想化プログラム４２３は、ＵＵＩＤで特定されるＯＢＪＳ２００内のＯＢＪＳ用ディレクトリ２３００を更新し（ステップＳ８０８）、ＣＰＦ１００に更新の完了を返す（ステップＳ８０９）。

そして、ファイル仮想化プログラム４１５は、管理情報ファイル２１００のディレクトリ状態２１１２をＣａｃｈｅｄにし（ステップＳ８１０）、ステップＳ８０１で取得したファイルリストからエントリを削除する（ステップＳ８１１）。

一方、ステップＳ８１２において、ファイル仮想化プログラム４１５は、データベース３２００から操作を完了したエントリのＤｉｒｔｙ部有無３２０４をなしにする。

図１９は、実施例に係るファイルストレージシステム１のファイルスタブ化処理の一例を説明するためのフローチャートである。

ファイルスタブ化処理が開始すると（ステップＳ９００）、ファイル仮想化プログラム４１５は、データベース３２００から、Ｄｉｒｔｙ部有無３２０４がなしでタイプ３２０２がファイルのエントリをリストとして取得する（ステップＳ９０１）。

次いで、ファイル仮想化プログラム４１５は、ステップＳ９０１で取得したファイルリストが空であるかどうかを判定する（ステップＳ９０２）。その結果、判定が肯定されたら（ステップＳ９０２においてＹＥＳ）プログラムはステップＳ９０８に移行し、判定が否定されたら（ステップＳ９０２においてＮＯ）プログラムはステップＳ９０３に移行する。

ステップＳ７０３では、ファイル仮想化プログラム４１５が、ステップＳ９０１で取得したリストからエントリを１つ取得する。次いで、ファイル仮想化プログラム４１５は、ステップＳ７０３で取得したエントリが示す管理情報ファイル１１００を取得する（ステップＳ９０４）。次いで、ファイル仮想化プログラム４１５は、ステップＳ９０４で取得した管理情報ファイル１１００が示すユーザファイル１２００を取得する（ステップＳ９０５）。

そして、ファイル仮想化プログラム４１５は、管理情報ファイル１１００のファイル状態１１１２と転送部分リストの該当箇所の部分状態１１２３をＳｔｕｂにし（ステップＳ９０６）、ステップＳ９０１で取得したファイルリストからエントリを削除する（ステップＳ９０７）。

一方、ステップＳ９０８において、ファイル仮想化プログラム４１５は、データベース３２００から操作を完了したエントリの非Ｓｔｕｂ部有無３２０５をなしにする。

図２０は、実施例に係るファイルストレージシステム１のＯＢＪＳ側ファイル／ディレクトリ削除処理の一例を説明するためのフローチャートである。

ＯＢＪＳ側ファイル／ディレクトリ削除処理が開始すると（ステップＳ１０００）、ファイル仮想化プログラム４１５は、データベース３２００から、削除フラグ３２０６がＴｒｕｅのエントリをリストとして取得する（ステップＳ１００１）。

次いで、ファイル仮想化プログラム４１５は、ステップＳ１００１で取得したファイルリストが空であるかどうかを判定する（ステップＳ１００２）。その結果、判定が肯定されたら（ステップＳ１００２においてＹＥＳ）プログラムはステップＳ１０１０に移行し、判定が否定されたら（ステップＳ１００２においてＮＯ）プログラムはステップＳ１００３に移行する。

ステップＳ１００３では、ファイル仮想化プログラム４１５が、ステップＳ１００１で取得したリストからエントリを１つ取得する。次いで、ファイル仮想化プログラム４１５は、ステップＳ１００３で取得したエントリが示す管理情報ファイル１１００、２１００を取得する（ステップＳ１００４）。

次に、ファイル仮想化プログラム４１５は、管理情報ファイル１１００、２１００が示すＵＵＩＤ１１１１、２１１１の削除要求をＯＢＪＳ２００に転送する（ステップＳ１００５）。

ＯＢＪＳ２００のファイル仮想化プログラム４２３は、ＵＵＩＤで特定されるＯＢＪＳ２００内のユーザファイル１２００／ユーザディレクトリ２２００を削除し（ステップＳ１００６）、ＣＰＦ１００に削除の完了を返す（ステップＳ１００７）。

そして、ファイル仮想化プログラム４１５は、ステップＳ１００１で取得したリストからエントリを削除する（ステップＳ１００９）。

一方、ステップＳ１０１０において、ファイル仮想化プログラム４１５は、データベース３２００から操作を完了したエントリのＤｉｒｔｙ部有無３２０４をなしにする。

図２１は、実施例に係るファイルストレージシステム１のクローリング処理の一例を説明するためのフローチャートである。

クローリング処理が開始すると（ステップＳ１１００）、ファイル仮想化プログラム４１５は、ファイル仮想化の対象となるユーザファイル１２００／ユーザディレクトリ２２００のルートディレクトリ２２００に対して以下に示すステップＳ１２００の処理を実行する。

ステップＳ１２００では、まず、ファイル仮想化プログラム４１５が、該当するユーザファイル１２００／ユーザディレクトリ２２００の管理情報ファイル１１００、２１００を取得する（ステップＳ１２０２）。

次いで、ファイル仮想化プログラム４１５は、ステップＳ１２０２で取得した管理情報ファイル１１００、２１００のファイル状態１１１２／ディレクトリ状態２１１２がＤｉｒｔｙであるか否かを判定する（ステップＳ１２０３）。そして、判定が肯定されたら（ステップＳ１２０３においてＹＥＳ）、プログラムはステップＳ１２０４に移行し、判定が否定されたら（ステップＳ１２０３においてＮＯ）、プログラムはステップＳ１２０５に移行する。

ステップＳ１２０４では、Ｄｉｒｔｙ部有無３２０４があり、非Ｓｔｕｂ部有無３２０５があり、削除フラグ３２０６がＦａｌｓｅとしてデータベース３２００に対象のエントリを登録する。

ステップＳ１２０５では、ファイル仮想化プログラム４１５は、ステップＳ１２０２で取得した管理情報ファイル１１００、２１００のファイル状態１１１２／ディレクトリ状態２１１２がＣａｃｈｅｄであるか否かを判定する。そして、判定が肯定されたら（ステップＳ１２０５においてＹＥＳ）、プログラムはステップＳ１２０６に移行し、判定が否定されたら（ステップＳ１２０５においてＮＯ）、プログラムはステップＳ１２０７に移行する。

ステップＳ１２０６では、Ｄｉｒｔｙ部有無３２０４がなし、非Ｓｔｕｂ部有無３２０５があり、削除フラグ３２０６がＦａｌｓｅとしてデータベース３２００に対象のエントリを登録する。

ステップＳ１２０７では、ファイル仮想化プログラム４１５は、ステップＳ１２０２で取得した管理情報ファイル１１００、２１００のファイル状態１１１２／ディレクトリ状態２１１２がＤｅｌｅｔｅｄであるか否かを判定する。そして、判定が肯定されたら（ステップＳ１２０７においてＹＥＳ）、プログラムはステップＳ１２０８に移行し、判定が否定されたら（ステップＳ１２０７においてＮＯ）、プログラムはステップＳ１２０９に移行する。

ステップＳ１２０８では、Ｄｉｒｔｙ部有無３２０４がなし、非Ｓｔｕｂ部有無３２０５がなし、削除フラグ３２０６がＴｒｕｅとしてデータベース３２００に対象のエントリを登録する。

ステップＳ１２０９では、ファイル仮想化プログラム４１５が、クローリング処理の対象がディレクトリであるか否かを判定する。そして、判定が肯定されたら（ステップＳ１２０９においてＹＥＳ）、プログラムはステップＳ１２１０に移行し、判定が否定されたら（ステップＳ１２０９においてＮＯ）、プログラムを終了する。

ステップＳ１２１０では、ディレクトリ内の各ファイル／ディレクトリに対してステップＳ１２００の処理を実行する。

このように構成される本実施例によれば、ファイルストレージシステム１のＣＰＦ１００は、クライアント６００からのファイルの操作要求からファイルシステムの呼び出し処理までの間に割り込み、ファイルシステムへの入力情報または操作内容に基づいて、ファイルの状態管理情報である管理情報ファイル１１００、２１００の更新処理を追加している。

従って、本実施例によれば、ファイルシステムにアクセスするアプリケーションに影響されず簡易にファイル仮想化機能を提供することが可能となる。

ＣＰＦノード１１０は、アプリケーションプログラム４１１およびＩＯ Ｈｏｏｋプログラム４１２をコンテナ化してクライアント６００に提供しており、これらは互いの動作環境や仕様に影響せず独立して作動する。ＩＯ Ｈｏｏｋプログラム４１２は分散ファイルシステム５１０を疑似した仮想ファイルシステムをアプリケーションプログラム４１１に提供しており、クライアント６００からのリクエストに基づきアプリケーションプログラム４１１は仮想ファイルシステムに対するファイル操作のシステムコールを発行する。
ＩＯ Ｈｏｏｋプログラム４１２は発行された仮想ファイルシステムに対するファイル操作のシステムコールからファイルへのＩＯ処理に関する情報を抽出し、ファイル仮想化管理情報の更新処理を行い、また、ログを出力する。さらにＩＯ Ｈｏｏｋプログラム４１２は、アプリケーションプログラム４１１が発行した仮想ファイルシステムへのファイル操作のＡＰＩを分散ファイルシステム５１０へ出力して所望のファイル操作が行われる。

このような構成により、アプリケーションの種別を考慮することなく、任意のアプリケーションに対してその都度ＩＯ Ｈｏｏｋプログラムをリンクする作り込みやアプリケーションの修正が不要となるため、ファイル仮想化システムの開発の工数および労力を軽減でき簡易にファイル仮想化機能を提供できる。

また、本実施例によれば、アプリケーションプログラム４１１およびＩＯ Ｈｏｏｋプログラム４１２を始めとした各プログラムをコンテナ化して実行するＣＰＦノード１１０を選択して設定登録することで、各プログラムの動作特性や負荷状況に応じ実行に適したＣＰＦノード１１０を適宜選択し登録できるため、特定のＣＰＦノード１１０へのファイル操作等の負荷集中を回避して複数のＣＰＦノード１１０へ負荷を分散することができる。

なお、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、ＳＳＤ（Solid State Drive）、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

１…ファイルストレージシステム、１０－１…サイト、１０－２…サイト、２０…データセンター、３０…ネットワーク、１００…ＣＰＦ、２００…ＯＢＪＳ、４１１…アプリケーションプログラム、４１２…Ｈｏｏｋプログラム、４１３…分散ファイルシステムプログラム、４１４…データベースプログラム、４１５、４２３…ファイル仮想化プログラム、４１６…コンテナ管理データ、４２１…ネットワークストレージプログラム、４２２…ローカルファイルシステムプログラム、５１０…ローカルファイルシステム、５２０…ローカルファイルシステム、５３０…ネットワークファイルシステム、６００…クライアント、１１００、２１００…管理情報ファイル、１２００…ユーザファイル、２２００…ユーザディレクトリ、２３００…ＯＢＪＳ用ディレクトリ、

Claims (9)

1. 各々が第１のファイルシステムを提供する複数のストレージノードと、
   前記第１のファイルシステムによりファイルが格納される第１のストレージシステムと、
   を有し、
   第２のストレージシステムを利用可能なファイルストレージシステムであって、
   前記各ストレージノードは、
   クライアントの要求に基づいて前記ファイルの操作要求を発行するアプリケーションと、
   前記ファイルの状態が格納された状態管理情報を管理し、さらに前記アプリケーションに対し前記第１のファイルシステムに基づく仮想ファイルシステムを提供する状態情報管理部と、
   前記第１のストレージシステム及び第２のストレージシステムに格納されるファイルを管理するファイル仮想化部と、
   を備え、
   前記アプリケーションは前記ファイルの操作要求に基づく前記仮想ファイルシステムの呼び出し処理を行い、
   前記状態情報管理部は、前記第１のファイルシステムに前記ファイルの操作要求を出力し、前記操作要求にかかる前記仮想の第１のファイルシステムへの入力情報または操作内容に基づいて、前記ファイルの状態管理情報の更新処理を行い、
   前記第１のファイルシステムは、前記ファイルの操作要求を処理し、
   前記ファイル仮想化部は、前記状態管理情報に基づいて、前記第１のストレージシステムと前記第２のストレージシステムとの間で前記ファイルの管理処理を行う
   ことを特徴とする分散ファイルストレージシステム。
2. 前記アプリケーション、前記状態情報管理部および前記ファイル仮想化部はコンテナ化され、
   それぞれが少なくとも１つずつ任意の前記ストレージノードにおいて実行されることを特徴とする請求項１記載のファイルストレージシステム。
3. 前記アプリケーションおよび前記状態情報管理部は、同一の前記ストレージノードにおいて実行されることを特徴とする請求項２記載のファイルストレージシステム。
4. 前記状態情報管理部と前記ファイル仮想化部はそれぞれ異なる前記ストレージノードにおいて実行されることを特徴とする請求項２記載のファイルストレージシステム。
5. 各前記ストレージノードの前記分散ファイルシステムのうちの一つがマスタであり、他の前記ストレージノードの前記分散ファイルシステムにおける前記ファイルの操作要求を処理することを特徴とする請求項１記載のファイルストレージシステム。
6. 前記ファイルの管理処理は、前記第１のストレージシステムと第２のストレージシステムとの間でのファイルのスタブ化またはマイグレーションであることを特徴とする請求項１に記載のファイルストレージシステム。
7. 前記第２のストレージシステムには、第２のファイルシステムによりファイルが格納され、
   前記分散ファイルシステムは階層構造を有し、前記第２のファイルシステムは階層構造を有さず、
   前記ファイル仮想化部は、前記分散ファイルシステムと、第２のファイルシステムと、の間で前記ファイルの管理処理を行う
   ことを特徴とする請求項６に記載のファイルストレージシステム。
8. 前記状態情報管理部は、前記状態管理情報の更新に加えて前記操作要求のログを作成し、
   前記ファイル仮想化部は、前記操作要求のログに基づいて、前記ファイルの管理処理を行う
   ことを特徴とする請求項１に記載のファイルストレージシステム。
9. 前記状態情報管理部は、前記ログに、前記ファイルの生成から削除までの期間で変更がなく前記ファイルのアクセスに用いる情報を登録することを特徴とする請求項８に記載のファイルストレージシステム。
   
   

Images