JP4211285B2 - ネットワークストレージシステムの仮想一元化方法及び装置 - Google Patents
ネットワークストレージシステムの仮想一元化方法及び装置 Download PDFInfo
- Publication number
- JP4211285B2 JP4211285B2 JP2002149977A JP2002149977A JP4211285B2 JP 4211285 B2 JP4211285 B2 JP 4211285B2 JP 2002149977 A JP2002149977 A JP 2002149977A JP 2002149977 A JP2002149977 A JP 2002149977A JP 4211285 B2 JP4211285 B2 JP 4211285B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- network storage
- storage
- network
- group
- 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 - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
- G06F3/0611—Improving I/O performance in relation to response time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
- G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/0643—Management of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のネットワークストレージ装置をクライアントから一つのネットワークストレージ装置として見せる、ネットワークストレージの仮想一元化方法、及び、仮想一元化装置に関する。
【０００２】
【従来の技術】
従来の情報システムは情報を処理する計算機に情報を格納するストレージをローカル接続して使用していた。ところが、近年ネットワーク技術の発達に伴い、ストレージを計算機から分離してネットワークに接続し、ネットワーク経由でストレージにアクセスする形態が普及しつつある。このようなネットワーク接続されたストレージをネットワークストレージと呼ぶ。
ネットワークストレージの代表としてSAN（Storage Area Network）ストレージとNAS(Network Atacched Storage)がある。SANストレージはネットワークとして専用に開発されたSANを用い、性能と信頼性は高いが非常に高価であり、主にエンタープライズ向けに使用される。一方、NASはネットワークとして最も普及しているIPネットワークを使用し、性能はSANストレージより低いが、価格がSANストレージに比べて低く、また手軽に使用できる。
近年、高価で大規模なストレージを用いるより、小規模で安価なNASを複数台用いて、性能と容量を確保したいという要求がある。しかし、NASの台数が増えると、それらを管理するコストが増大するという問題がある。そこで、システム管理コストを抑制するために、複数のNASを計算機から仮想的に一つのNASとして見せ、新しいNASの追加や既存NASの削除を行なっても、計算機には影響を及ぼさないNASの仮想一元化技術が必要となる。
このようなNASの仮想一元化技術として、いくつかの方式が開発されている。例えば、http://www.maxtor.com/products/maxattach/default.htmには、プライマリストレージと呼ばれる管理サーバを兼ねたネットワークストレージがファイルの配置情報を一括管理し、ファイルのアクセス時刻等の属性を用いて格納するネットワークストレージを決定する複数ネットワークストレージの仮想的に一つのネットワークストレージとして見せる方法について記載されている。新規に生成されるファイルはプライマリストレージに格納し、しばらくアクセスされなかったファイルはプライマリストレージからセカンダリストレージに移動される。計算機からのファイルアクセスはプライマリストレージが受け付け、そのファイルがセカンダリストレージに存在する場合は、セカンダリストレージにファイルアクセスを行なうことで、計算機からはあたかも一つのネットワークストレージのように見える。
また、The Zebra Striped Network File System、Hartman et. al.、ACM Transactions on Computer System、vol. 13、No. 3、1995、pp.274-310.には、ファイルを部分的に複数のネットワークストレージに分散して格納し、ファイルがどのストレージにどのような順番で格納されているか集中管理するサーバを設けることによって、複数のネットワークストレージを仮想的に一つのネットワークストレージに見せる方法が記載されている。このように一つのファイルをネットワークストレージ間でストライピングする方法では、ファイルの容量が非常に大きい場合でも、各ネットワークストレージに均等にデータを書き込むことができる。また、DiFFS：a Scalable Distributed File System, Christos Karamanolis et. al.、HP Laboratories Palo Alto、HPL-2001-19、January 24, 2001には、上記の集中管理サーバ方式と異なる非集中管理サーバ方式により、複数のネットワークストレージを仮想的に一つのネットワークストレージとして見せる方法について記載されている。この方法は、ファイルの格納先ネットワークストレージをディレクトリとファイルを管理するディレクトリエントリ内に格納し、このディレクトリエントリを各ネットワークストレージに分散して配置する。
また、米国特許第６，０２９，１６８号には、上記の非集中管理サーバ方式でかつ、一つのファイルを部分的に複数のネットワークストレージに分散して格納する方法が記載されている。この方法はファイルをどのネットワークストレージにどのような順番で配置するかを、各ネットワークストレージに分散して管理する。
【０００３】
【発明が解決しようとする課題】
前記http://www.maxtor.com/products/maxattach/default.htmの方法、及び、前記DiFFS：a Scalable Distributed File Systemの方法は、ファイルの管理情報を集中して持つか分散して持つかの違いはあるが、ファイル毎に格納先ネットワークストレージの情報を持つ。また、前記The Zebra Striped Network File systemの方法、及び、米国特許６，０２９，１６８号の方法は、ファイルの断片毎に格納先ストレージの情報を持つ。このようなファイル毎あるいはファイルの断片ごとに格納先ネットワークストレージの情報を持つと、格納するファイルの数に比例して管理する情報も増大し、この管理情報がネットワークストレージのデータ格納用領域のサイズを圧迫する。
さらに、仮想的に一元化された複数のネットワークストレージに新しいネットワークストレージを追加したり、あるいは、削除したりして構成変更するのに伴い、ファイルの格納先ネットワークストレージが変更されると、格納先の変更された全てのファイルに対して、格納先ネットワークストレージの情報を書き換える必要があり、これが構成変更時の性能に影響を及ぼす。
本発明の目的は、ファイルの格納先に関する管理情報をコンパクト化し、データ格納領域が圧迫されないような複数ネットワークストレージの仮想一元化方法を提供することにある。本発明の他の目的は、ネットワークストレージの構成変更に伴って発生するファイル移動の際の管理情報の更新処理のオーバヘッドを低減し、柔軟にかつ高速に構成変更可能な、複数ネットワークストレージの仮想一元化方法を提供することにある。
【０００４】
【課題を解決するための手段】
本発明は、一つまたは複数のネットワークストレージから構成される仮想一元化ネットワークストレージシステムにおいて、ファイルの格納先ネットワークストレージをファイルグループを単位として管理するところに特徴がある。ファイルが属するファイルグループを予めグループマップとして定義しておく。グループマップは、例えばファイル識別子を検索鍵としたハッシュ関数として与える。さらに、ファイルグループと、そのファイルグループに属するファイルの格納先ネットワークストレージを定めるグループ配置を設けておく。グループ配置は、例えばファイルグループとネットワークストレージとの対応を記録するテーブルやデータベースとして与える。クライアントがファイルにアクセスする際は、まずアクセス対象ファイルのファイル識別子とグループマップとから、そのファイルが属するファイルグループを求める。次に、グループ配置を参照して求めたファイルグループに対応したネットワークストレージを求める。求めたネットワークストレージがアクセス対象ファイルの格納先ネットワークストレージであるから、前記ネットワークストレージに対してファイルアクセスを行なう。この発明によれば、一つ以上のファイルから構成されるファイルグループを単位として格納先ネットワークストレージの情報を持つため、ファイル毎に管理情報を持つ場合にくらべて管理情報が少なくなる。
また、仮想一元化ネットワークストレージシステムの構成変更時には、ファイルグループを単位としてファイルの格納先ネットワークストレージを移動する。この際に、グループ配置の移動するファイルグループの格納先ネットワークストレージを変更するだけで良いので、ファイル毎に格納先情報を管理する場合に比べてオーバヘッドを小さくできる。
【０００５】
【発明の実施の形態】
＜実施例１＞
図１は本発明の第一の実施例を含む情報システムの全体構成を示す図である。クライアント１はネットワーク２を介して本発明の仮想一元化装置３に接続されている。仮想一元化装置３はネットワーク４を介して、ネットワークストレージ５、６、７と接続されている。ネットワーク４を用意する代わりにネットワークストレージ５、６、７をネットワーク２に接続しても良い。ネットワーク２と４を独立すると、アクセス集中時に高い性能を出すことができる。一方ネットネットワーク２にネットワークストレージ５、６、７を接続すると、ネットワーク４が不要となり、コストを抑えることができる。仮想一元化装置３はネットワークストレージ５，６，７を仮想的に一元化し、クライアント１から一つのネットワークストレージとしてアクセスできる仮想一元化ネットワークストレージシステム８を提供する。
(ネットワークストレージ)
ネットワークストレージ５、６、７は公知の技術によって構成されるもので、リモート制御手段１０とストレージ装置１１とを備える。ストレージ装置１１にはファイルシステムを搭載する。
ネットワークストレージ５、６、７は専用装置であっても良いし、ストレージ装置を備えた汎用のサーバ、ワークステーション、あるいは、ＰＣにリモート制御手段を搭載しても良い。リモート制御手段１０は、ネットワーク上に接続されたクライアントからのマウント要求とファイルの生成、読み出し、書き込み、あるいは、ディレクトリの生成等の要求を受け、ローカルストレージ装置のファイルシステムに対してファイルの生成、読み出し、書き込み、あるいは、ディレクトリの生成等を行なう。リモート制御手段１０は、サン・マイクロシステムズ社(Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．)によって開発されたＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）や、マイクロソフト社(Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ)によって開発されたＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）等のファイルアクセスプロトコルを使用して、クライアントとの通信を行なう。本実施例１ではファイルアクセスプロトコルとしてＮＦＳを用いるものとする。ＮＦＳの要求を受けファイルアクセス処理を行なうリモート制御手段１０としては、公知のｍｏｕｎｔｄとｎｆｓｄを使用する。
(仮想一元化装置)
本実施例の仮想一元化装置３は、ファイルシステム１００、グループマップ１１０、グループ配置１２０、要求処理手段１３０、移動手段１４０、容量監視手段１５０、統合手段１６０、管理手段１８０から構成される。ファイルシステム１００、グループマップ１１０、グループ配置１２０は主にファイルの格納先ネットワークストレージを定めるために用いられる。詳細は後述の(ファイルシステム)、(グループマップ)、(グループ配置)の項で説明する。要求処理手段１３０はクライアントからのファイルアクセス要求を処理する。詳細は後述の(要求処理手段)の項で説明する。移動手段１４０は、ネットワークストレージを追加したり削除したり、あるいはネットワークストレージの一つの残容量が定められた値を下回った場合に、ファイルをネットワークストレージ間で移動する。詳細は後述の(移動手段)の項で説明する。容量監視手段１５０は各ネットワークストレージの容量を常時監視し、必要があれば移動手段を起動する。詳細は後述の(容量監視手段)の項で説明する。統合手段１６０は既に運用中の既設ネットワークストレージ装置を仮想一元化ネットワークストレージシステムに統合する際の処理を行なう。詳細は後述の(統合手段)の項で説明する。管理手段１８０は仮想一元化ネットワークストレージシステム８を管理する管理者からの指示を受け付け、仮想一元化装置３の設定を変更したり、移動手段１４０や統合手段１６０を呼び出して構成変更等の要求に対応する。管理者は、クライアント１上の汎用Ｗｅｂブラウザをユーザインタフェースとして管理手段１８０へのアクセスする。あるいは、クライアント１に専用のユーザインタフェースプログラムを搭載してそれを使用したり、仮想一元化装置にコンソールを接続しそれを用いても良い。
仮想一元化装置３の処理の概要を説明する。クライアント１はまず仮想一元化装置３に対してマウント要求を発行して、仮想一元化ネットワークストレージシステム８が共有を許可しているディレクトリをクライアント１のファイルシステムの特定の場所にマウントする。そしてクライアント１がファイルアクセス要求を発行すると、仮想一元化装置３の要求処理手段１３０がそれを受け、ファイルシステム１００、グループマップ１１０、グループ配置１２０を用いて、アクセス対象ファイルの格納先ネットワークストレージを求める。そして、その格納先ネットワークストレージに対してクライアントから受けたファイルアクセス要求を送る。格納先ネットワークストレージがファイルアクセスを実行し終わると、仮想一元化装置３は格納先ネットワークストレージからの得られたデータを要求元クライアント１に返す。このように、クライアント１はアクセス対象ファイルがどのネットワークストレージに存在するか知る必要はなく、複数のネットワークストレージを一つの大きなネットワークストレージとしてアクセスできる。
なお、本発明の仮想一元化装置３は、全てのファイルを一つ以上のファイルグループに分割し、ファイルグループごとにファイルの格納先ネットワークストレージ装置を与え、同一ファイルグループに属するファイルは同じネットワークストレージに格納する。ファイルグループは、使用するネットワークストレージ５、６、７の数と同数かあるいはそれより多く設ける。ファイルグループに属するファイルの容量が、ファイルグループ毎に大きく異なると、それを格納するネットワークストレージ間で使用容量のアンバランスが生じる。これを改善するため、ファイルグループは、ネットワークストレージ数の１０倍から１０００倍程度設ける。こうすることで、ファイルグループ当りの容量のばらつきを減少し、ネットワークストレージ間の使用容量のアンバランスを解消する。このようにファイルグループ単位で格納先ネットワークストレージを定めることで、従来技術で発生するファイル数に比例して管理情報が増加しストレージを圧迫する問題を解消でき、また、ファイル移動時に各ファイル毎に格納先ネットワークストレージの情報を書き換える必要がなくなり、オーバヘッドを減少できる。
以下では仮想一元化装置３の構成要素の詳細について説明する。
(ファイルシステム)
ファイルシステムは、仮想一元化ネットワークストレージシステム全体のディレクトリ構造と、全ファイルのファイル識別子を管理する。仮想一元化装置３が使用するファイルシステム１００はオペレーティングシステムが提供するファイルシステムを使用する。
図２はサン・マイクロシステムズ社のＳｏｌａｒｉｓ、インターナショナル・ビジネス・マシーンズ社（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ）社のＡＩＸ、ヒューレット・パッカード社(Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｍｐａｎｙ)のＨＰ−ＵＸ、Ｌｉｎｕｘ，及び、ＦｒｅｅＢＳＤ等のＵＮＩＸ系オペレーティングシステムにおけるファイルシステムの基本構造を示したものである。図２のファイルシステムは図３のディレクトリ構造を持つファイル郡を格納した様子を示している。図３の／、ｄ１、ｄ２、ｄ３はディレクトリであり、ｆ１、ｆ２、ｆ３はファイルを示している。／はルートと呼ばれディレクトリの始点を表す。
ファイルとディレクトリをまとめてファイルオブジェクトと呼ぶ。ファイルオブジェクトはファイルシステム内でｉノードと呼ばれるデータ構造１００１〜１００７として記録される。ｉノードはそれを識別するｉノード番号という固有の識別子を持つ。図２の例では、／ディレクトリにはiノード１００１が対応しそのiノード番号は２番である。ディレクトリｄ１にはiノード１００２が対応しそのiノード番号は５番である。ディレクトリｄ２にはiノード１００３が対応しそのiノード番号は７番である。ディレクトリｄ３にはiノード１００４が対応しそのiノード番号は９番である。ファイルｆ１にはiノード１００５が対応しそのiノード番号は１０番である。ファイルｆ２にはiノード１００６が対応しそのiノード番号は１４番である。ファイルｆ３にはiノード１００７が対応しそのiノード番号は１６番である。ファイルシステムにおいて、ファイルオブジェクトの識別にはｉノード番号が使用される。一方ファイルオブジェクトの名前や配置場所を管理するディレクトリ情報は、ディレクトリエントリという構造１００８、１００９、１０１０、１０１１によって管理される。ファイルシステム内のディレクトリのそれぞれに対して一つディレクトリエントリが設けられる。ディレクトリ／、ｄ１、ｄ２、ｄ３に対してそれぞれディレクトリエントリ１００８、１００９、１０１０、１０１１が対応する。ディレクトリのｉノードは、そのディレクトリに対応するディレクトリエントリへのポインタを持つ。例えば図２の場合、ディレクトリｄ１に相当するiノード１００２はディレクトリｄ１に対応するディレクトリエントリ１００９へのポインタを保持する。ディレクトリエントリは自身のディレクトリのｉノード番号とそのディレクトリ名(.で表される)の組、親ディレクトリのｉノード番号とそのディレクトリ名(..で表される)の組、及び、自身のディレクトリの直下にあるファイルまたはディレクトリのｉノード番号とファイル名又はディレクトリ名の組を構成要素とする。
ディレクトリ構造は、iノードとディレクトリエントリの相互チェーンによって管理される。例えば、／ディレクトリに相当するiノード１００１はディレクトリエントリ１００８を示しており、このディレクトリエントリを参照すると、／ディレクトリの直下にｄ１という名前のファイルオブジェクトが存在しそのiノード番号が５番であることが分かる。次に、５番のiノード１００２を参照すると、ファイルオブジェクトがディレクトリであることが分かり、それが指し示すディレクトリエントリ１００９を参照することによって、ディレクトリｄ１の直下にiノード番号７番のｄ２という名前のファイルオブジェクトとiノード番号９番のｄ３とうい名前のファイルオブジェクトが存在することがわかる。さらに、iノード番号９番のiノード１００４を参照すると、それがディレクトリであることがわかり、指し示すディレクトリエントリ１０１１を参照することによって、直下にiノード番号１６番のｆ３という名前のファイルオブジェクトが存在することがわかる。このようにして、iノードとディレクトリエントリによってディレクトリ構造が記録される。次に、ファイルに対応するiノード１００５、１００６、１００７はファイルの中身であるデータを格納するデータブロックへのポインタを記録する。図２の場合、ファイルｆ１に対応したiノード１００５はデータブロック１０１２を一つ指しており、このデータブロック１０１２内にファイルｆ１のデータが格納されている。複数のブロックを使用するファイルの場合、iノードはそれらずべてのブロックへのポインタを記録する。
以上、ＵＮＩＸ系オペレーティングシステムが提供するファイルシステムの一般的構造について説明した。通常ファイルシステムは、ファイルのディレクトリ構造や識別子を管理すると共に、ファイルの実体であるデータを保管する。しかし、本発明の仮想一元化装置３は、ファイルシステム１００を、ファイルのディレクトリ構造とファイル識別子(以後管理情報と呼ぶ)の管理にのみ使用し、ファイルの実体であるデータは各ネットワークストレージ５、６、７に格納する。このため、仮想一元化装置３はファイルシステム１００に対して容量０のダミーファイルを生成する。クライアントが仮想一元化ネットワークストレージシステム８に対して図３のようなディレクトリ構造を持つファイル郡を格納した場合、仮想一元化装置３はファイルシステム１００に図２の構造を作るが、ファイルの実体であるデータブロック１０１２、１０１３、１０１４は使用しない。
また、仮想一元化装置３はファイル識別子としてiノード番号を利用する。
なお、ディレクトリ構造とファイル識別子の管理ができれば必ずしもファイルシステム１００を使用する必要はない。ファイル識別子が全ファイルに対しいて一意であることを保証しつつ、データベースを利用して管理しても良いし、専用のテーブルを設けて権利しても良い。
(グループマップ)
グループマップ１１０は、ファイルとそのファイルが属するファイルグループとの対応を与える。具体的にはファイルの識別子であるiノード番号と、そのiノード番号で識別されるファイルの属するファイルグループの識別子を与える。グループマップ１１０の具体例として、ファイルのiノード番号Ｉを検索鍵としハッシュ値をファイルグループの識別子Ｇとするハッシュ関数
Ｇ＝Ｈａｓｈ（Ｉ）
によって与える。例えばファイルをＮ個のファイルグループに分割する場合のハッシュ関数として、ｉノード番号Ｉにファイルグループ数Ｎのモジュロ演算(Ｎで割った余り)を適用して得られた値をファイルグループの識別子とする。
【０００６】
Ｇ ＝ Ｈａｓｈ（Ｉ） ＝ Ｉ ｍｏｄ Ｎ
０〜８までの９つのファイルグループを設けた場合のグループマップのハッシュ関数は以下のようになる。
【０００７】
Ｈａｓｈ（Ｉ） ＝ Ｉ mod 9 …▲１▼
ハッシュ関数は上記のモジュロ演算の他、iノード番号Iに対して一意にファイルグループを対応付けることができれば何を使用しても良い。ただし、特定のファイルグループに属するファイルの数が他のファイルグループに属するファイルの数より極端に多くなるようなハッシュ関数を使用すると、それらのファイルグループを格納するネットワークストレージ間で容量のアンバランスが生じる。この問題を発生させないようにするには、なるべく各ファイルグループに均等にファイルがばら撒かれるような関数を選ぶべきである。
(グループ配置)
グループ配置１２０の構造を図４に示す。グループ配置は、ファイルグループと、そのファイルグループに属するファイルの格納先ネットワークストレージとを対応付ける役割を持つテーブルで、ストレージ装置内に格納される。１２０１の行は９つのファイルグループの識別番号０〜８を示しており、１２０２の行は対応する１２０１行のファイルグループのファイルの格納先ネットワークストレージの識別番号を示す。図４の例で、ファイルグループ１に属するファイルの格納先はネットワークストレージ１であり、ファイルグループ６に属するファイルの格納先はネットワークストレージ３である。仮想一元化装置３は起動時に、グループ配置の１２０２の行に、各ネットワークストレージの識別子がほぼ均等に出現するように、初期化を行なう。
グループ配置１２０は、ネットワークストレージの追加、削除、平滑化、及び、既存ネットワークストレージの取り込みの際に書き換えられる。なお、グループ配置１２０は、ファイルグループと格納先ネットワークストレージとの対応が取れ、かつ、仮想一元化装置３が何らかの障害によってダウンしてしまっても、対応関係が消失してしまわなければ、データベースを利用しても良いし、その他どんな方法であっても良い。
なお、グループ配置１２０は、ファイルアクセスの際に必ず参照するため、グループ配置がストレージ内に格納されていると、性能低下を招く。このため、ストレージ内に格納されたグループ配置１２０のコピーを高速にアクセス可能なメモリに配置しても良い。この場合、グループ配置を書き換える際は、メモリとストレージとを両方とも書き換える必要がある。
(要求処理手段)
要求処理手段１３０はクライアントからのファイルシステムのマウント要求とファイルアクセス要求を処理する。本実施例ではクライアント１と要求処理手段１３０とは、前述のＮＦＳプロトコルを用いてファイルアクセスのやり取りを行なうものとする。一元管理装置３とネットワークストレージ５、６、７の間もＮＦＳプロトコルを用いてファイルアクセスのやり取りを行う。なお、クライアント１がＣＩＦＳにのみ対応している場合、一元管理装置３の要求処理手段１３０はクライアント１とＣＩＦＳにてやり取りを行う必要がある。これを実現するため、一元管理装置３はネットワークストレージ５、６、７とはＮＦＳでやり取りを行い、クライアント１とだけＣＩＦＳでやり取りを行う。ＣＩＦＳクライアントとのやり取りは、Ｓａｍｂａなどの公知な技術を用いることで実現できる。
ＮＦＳではまずクライアントがサーバに対してマウント要求を発行して、サーバ側の共有ファイルのルートディレクトリ(マウントポイントと呼ぶ)をクライアントのファイルシステムの特定の場所にマウントする。要求処理手段１３０はクライアントからのマウント要求に対して、公知のｍｏｕｎｔｄを利用してマウント要求に答える。mountdは、仮想一元化ネットワークストレージシステム８のマウントポイントのファイルハンドル(後述)をクライアント１に返す。
ＮＦＳプロトコルに規定されたファイルやディレクトリに対するアクセス要求には、ファイルの生成を行なうＣＲＥＡＴＥ要求、ファイル名を与えてファイルハンドルを取得するＬＯＯＫＵＰ要求、ファイルを読み出すＲＥＡＤ要求、ファイルを書き込むＷＲＩＴＥ要求、ファイルの属性を設定するＳＥＴＡＴＴＲ要求、ファイルの属性を読み出すＧＥＴＡＴＴＲ要求、ファイルを削除するＲＥＭＯＶＥ要求、ファイルの名前を変更するＲＥＮＡＭＥ要求、ディレクトリを生成するＭＫＤＩＲ要求、ディレクトリを読み出すＲＥＡＤＤＩＲ要求、ディレクトリを削除するＲＭＤＩＲ要求がある。以下各要求毎に要求処理手段３の動作を説明する。
(ＣＲＥＡＴＥ要求の処理)
クライアント１はファイルを生成するディレクトリのファイルハンドルＨと、生成するファイルの名前Ｆを引数としてＣＲＥＡＴＥ要求を発行する。ファイルハンドルは、クライアント１が後に説明するＬＯＯＫＵＰ要求等を発行すると返り値として得られるファイルを識別するデータ構造である。ファイルハンドルの構成を図６に示す。ファイルハンドル１７０は親ディレクトリのiノード番号フィールド１７０１と、ファイルオブジェクトのiノード番号フィールド１７０２を含んでいる。要求処理手段１３０がクライアント１からＣＲＥＡＴＥ要求を受けると、図５の１３０１を呼び出し、要求を処理する。まず１３０２において、親ディレクトリのファイルハンドルＨのiノード番号フィールド１７０２から、ファイルを生成する親ディレクトリのiノード番号ＰＩを取り出し、このiノード番号で識別されるディレクトリにファイル名Ｆのサイズ０のダミーファイルを生成する。生成したファイルのiノード番号をIとする。次に１３０３において、生成したファイルのiノード番号Iに対して上記(ファイルマップ)の項で説明したハッシュ関数Ｈａｓｈを適用し、ファイルグループＧを求める。次に、１３０４において上記(グループ配置)の項で説明したグループ配置１２０を参照し、ファイルグループＧに対応するネットワークストレージＮを求める。求めたネットワークストレージＮがクライアント１が発行したＣＲＥＡＴＥ要求の対象ファイルの格納先ネットワークストレージとなる。そして、１３０５において、クライアント１から送られてきたＣＲＥＡＴＥ要求をネットワークストレージＮに対して発行する。最後に１３０６で、ネットワークストレージ装置ＮからＣＲＥＡＴＥ要求の応答が返ると、ファイルシステム１００上でダミーファイルを生成したディレクトリのiノード番号ＰＩと生成したダミーファイルそのもののiノード番号Iからファイルハンドルを構成して、それを要求元クライアント１に返して処理を終了する。
(ＬＯＯＫＵＰ要求の処理)
クライアント１はファイルハンドルを取得する対象ファイルオブジェクトの名前Ｆと、そのファイルオブジェクトの親ディレクトリのファイルハンドルＨを引数としてＬＯＯＫＵＰ要求を発行する。要求処理手段１３０がクライアント１からＬＯＯＫＵＰ要求を受けると、図７の１３１１を呼び出す。まず１３１２において、親ディレクトリのファイルハンドルＨの１７０２のフィールドから、この親ディレクトリのiノード番号ＰＩを取り出し、このiノード番号で識別されるディレクトリに存在する名前Ｆのファイルオブジェクトのiノード番号Iを取得する。次に、１３１３において親ディレクトリのiノード番号ＰＩとファイルのiノード番号Iからファイルハンドルを構成し、それを要求元クライアント１に返して処理を終了する。
(ＲＥＡＤ要求の処理)
クライアント１は読み出すファイルのファイルハンドルＨと、読み出すファイルの親ディレクトリのファイルハンドルＨｐを引数としてＲＥＡＤ要求を発行する。要求処理手段１３０がクライアント１からＲＥＡＤ要求を受けると、図８の１３２１を呼び出し、要求を処理する。まず１３２２において、ファイルハンドルＨのiノード番号フィールド１７０２からiノード番号Iを取得する。次に、１３２３において、iノード番号Iにハッシュ関数Ｈａｓｈを適用しファイルグループＧを求める。そして、１３２４で、グループ配置１２０を参照し、ファイルグループＧの格納先ネットワークストレージＮを求める。１３２５で、ネットストレージＮに対してＬＯＯＫＵＰ要求を発行し、ＲＥＡＤ要求がアクセス対象としたファイルハンドルＨで識別されるファイルの実体に対するネットワークストレージＮにおけるファイルハンドルＨｎを取得する。１３２６において、取得したファイルハンドルＨｎを引数としてＲＥＡＤ要求をネットワークストレージＮに発行する。１３２７において、ネットワークストレージＮがＲＥＡＤ要求の返り値である読み出し結果を返すと、得られた読み出し結果を要求元クライアント１に返す。
クライアントがＷＲＩＴＥ要求を発行した場合もＲＥＡＤ要求の処理とほぼ同じである。１３２６においてＲＥＡＤ要求を格納先ネットワークストレージＮに対して発行する代わりに、ＷＲＩＴＥ要求を格納先ネットワークストレージＮに発行すれば良い。ＲＥＮＡＭＥ要求とＲＥＭＯＶＥ要求も同様である。
(ＭＫＤＩＲ要求の処理)
クライアント１は生成するディレクトリの名前Ｄと、生成する親ディレクトリのファイルハンドルＨを引数としてＭＫＤＩＲ要求を発行する。要求処理手段１３０がクライアント１からＭＫＤＩＲ要求を受けると、図９の１３３１を呼び出し、要求を処理する。まず１３３２において、ファイルシステム１００にファイルハンドルＨのiノード番号フィールド１７０２に格納されているiノード番号によって識別されるディレクトリに、名前Ｄのディレクトリを生成する。生成したディレクトリのiノード番号をIとする。そして、１３３３にて、ネットワークストレージのそれぞれにＭＫＤＩＲ要求を発行して名前Ｄのディレクトリを生成する。そして１３３４にてファイルハンドルＨのiノード番号フィールド１７０２の値と生成したディレクトリのiノード番号Iとからファイルハンドルを生成し、それを要求元クライアント１に返す。ＲＭＤＩＲ要求の処理も同様であり、ＭＫＤＩＲ要求をすべてＲＭＤＩＲ要求に変更すれば良い。
ＧＥＴＡＴＴＲ要求とＳＥＴＡＴＴ要求は、アクセス対象ファイルオブジェクトがディレクトリの場合、ＭＫＤＩＲ要求の処理の場合と同様に各ネットワークストレージに対してＧＥＴＡＴＴＲ要求またはＳＥＴＡＴＴＲ要求を発行してディレクトリ属性の設定を行なえば良い。アクセス対象ファイルオブジェクトがファイルの場合、ＲＥＡＤ要求の処理と同様に、アクセス対象ファイルの格納先ネットワークストレージにＧＥＴＡＴＴＲ要求または、ＳＥＴＡＴＴＲ要求を発行すれば良い。
ＲＥＡＤＤＩＲ要求の処理はＬＯＯＫＵＰ要求の処理と同様で、ファイルシステム１００に対して対象ディレクトリの情報を読み出しそれをクライアントに返せば良い。
以上、要求処理手段１３０の処理の詳細について説明した。ここでは例題として、クライアント１が図３のような構造を持つディレクトリとファイルを生成しそれにアクセスする場合を示す。まず、仮想一元化ネットワークストレージシステム８にディレクトリやファイルがまったく存在しないと仮定する。ファイルグループは０〜８までの９つを設ける。また、グループマップとして以下のハッシュ関数
Ｈａｓｈ（Ｉ） ＝ Ｉ／９
を用いる。
クライアント１はまずマウント要求を仮想一元化装置３に発行し、仮想一元化装置３の要求処理手段１３０はマウントポイントのファイルハンドルを返す。次にクライアント１はそのマウントポイントのファイルハンドルと生成するディレクトリの名前ｄ１を引数としてＭＫＤＩＲ要求を発行する。仮想一元化装置３の要求処理手段１３０はファイルシステム１００及び各ネットワークストレージ５、６、７にディレクトリを生成する。次にクライアントは生成したｄ１のファイルハンドルとディレクトリ名ｄ２を引数にＭＫＤＩＲ要求を発行すると、仮想一元化装置３の要求処理手段１３０はファイルシステム１００と各ネットワークストレージ５、６、７にディレクトリｄ２を生成する。次にクライアントはディレクトリｄ２のファイルハンドルと
ファイル名ｆ１を引数としてＣＲＥＡＴＥ要求を発行する。すると仮想一元化装置３の要求処理手段１３０はまずファイルシステム１００のディレクトリｄ２において名前ｆ１を持つサイズ０のダミーファイルを生成する。生成したディレクトリやファイルのiノードとディレクトリエントリの構造は図２のようになっているものと仮定する(この図には生成前のディレクトリｄ３とファイルｆ２、ｆ３に相当するiノードやディレクトリエントリが含まれている)。ファイルｆ１に相当するiノードは１００５でありそのiノード番号は１０番である。そこで要求処理手段１３０はiノード番号１０に前述のハッシュ関数▲１▼を適用してファイルｆ１の属するファイルグループが１番であることが分かる。次にグループ配置１２０のファイルグループ１番の列を参照すると、そのファイルの格納先ネットワークストレージが１番(図１の５)であることが分かる。従って要求処理手段１３０はネットワークストレージ５にＣＲＥＡＴＥ要求を発行して、ファイルｆ１の実体をディレクトリｄ２の下に生成する。同様にクライアント１がファイルｆ２のＣＲＥＡＴＥ要求を発行すると、ファイルシステム１００において名前ｆ２を持つダミーのファイルが生成する。生成したダミーファイルのiノードが図２の１００６でありそのiノード番号が１４であるので、要求処理手段１３０はこれに前述のハッシュ関数▲１▼を適用して、このダミーファイルの属するファイルグループが５番であることが分かる。次にグループ配置１２０を参照して格納先ネットワークストレージが２番(図１の６)であることが分かるので、ネットワークストレージ６にＣＲＥＡＴＥ要求を発行してディレクトリｄ２の下にファイルｆ２の実体を生成する。同様にしてディレクトリｄ３をｄ１の下に生成し、ディレクトリｄ３の下にファイルｆ３を生成すると、ファイルシステム１００の構造は図２となり、各ファイルｆ１、ｆ２、ｆ３の配置は図１の５、６、７のストレージ１１に記載の通りとなる。次にクライアント１がファイルｆ３のＲＥＡＤ要求を発行する場合を考える。クライアント１はまずマウントポイントのファイルハンドルとディレクトリ名ｄ１を引数としてＬＯＯＫＵＰ要求を発行し、要求処理手段１３０はディレクトリｄ１のファイルハンドルをクライアント１に返す。次に、クライアントはディレクトリｄ１のファイルハンドルとディレクトリ名ｄ３を引数としてＬＯＯＫＵＰ要求を発行し、要求処理手段１３０はディレクトリｄ３のファイルハンドルをクライアント１に返す。次に、クライアント１はディレクトリｄ３のファイルハンドルとファイル名ｆ３を指定してＬＯＯＫＵＰ要求を発行すると、要求処理手段１３０はファイルｆ３のファイルハンドル(ファイルシステム１００におけるファイルｆ１のダミーファイルのiノード番号とその親ディレクトリのiノード番号から構成される)をクライアントに返す。そこでクライアント１はディレクトリｄ３のファイルハンドルと、ファイルｆ３のファイルハンドルを引数としてＲＥＡＤ要求を発行する。要求処理手段１３０はそれに対して、ファイルｆ３のファイルハンドルからファイルｆ３に相当するダミーファイルのiノード番号を取り出す。iノード番号は１６番であるから、それにハッシュ関数▲１▼を提供してファイルグループ７を得る。グループ配置１２０を参照するとファイルグループ７の格納先ネットワークストレージは３(図１の７)であるから、要求処理手段１３０はネットワークストレージ３にＲＥＡＤ要求を発行してファイルｆ３を読み出す。要求処理手段１３０はネットワークストレージ３から読み出したデータが返ると、それを要求元クライアント１に返す。以上のように、クライアントは単に通常のネットワークストレージへアクセスするように要求を発行すると、仮想一元化装置１３０がアクセス対象ファイルの格納先ネットワークストレージを求め、そのネットワークストレージにファイルアクセス処理を送ってファイルアクセスを行なう。このためクライアントからは仮想一元化ネットワークストレージシステム８があたかも一つのネットワークストレージとして見える。
(容量監視手段)
容量監視手段は定期的に各ネットワークストレージの残容量を求めてそれを図１０の容量テーブル１５００に書き込むと共に、いずれかのネットワークストレージの残容量が定められた値を下回った場合に、後述の移動手段を起動してファイルの移動を行ったり、あるいは、管理者に対して新しいネットワークストレージの追加を催促するメッセージを送ったりする。
容量テーブル１５００は各ネットワークストレージの残容量に関する最新の情報を記録するテーブルである。１５０１の行は各ネットワークストレージの識別子を示す。１５０２の行は、各ネットワークストレージの最大容量(ファイルを一つも格納しない場合の使用可能容量)を記録する。１５０３の行は、各ネットワークストレージの現在の残容量を示す。例えば図１０の例では、容量の単位をＧＢと定めると、ネットワークストレージ１、２、３の最大容量は共に２０ＧＢであり、残容量はそれぞれ１２ＧＢ，８ＧＢ，１４ＧＢである。１５０３の行は残容量に替えて使用容量を記録しても良い。図１１に容量監視手段の容量監視処理のフローを示す。仮想一元化装置３の起動時に１５１１を実行する新しいスレッドまたはプロセスを生成し、要求処理手段１３０によるファイルアクセス処理と並列に各ネットワークストレージの容量を監視する。
まず１５１２でフラグＦｏｖｅｒを０に初期化する。Ｆｏｖｅｒは後述する移動手段による平滑化処理の開始を指示するフラグである。次に１５１３で各ネットワークストレージの残容量を取得し、得られた値を容量テーブル１５００の１５０３の行に書き込む。残容量の計測は、各ネットワークストレージにＳＴＡＴＦＳプロシージャを発行して取得しても良いし、その他ネットワーク経由で各ネットワークストレージの残容量を取得できればどんな方法を用いても良い。次に、１５１４において、１５１３で取得した各ネットワークストレージの残容量が予め定められた閾値Ｔを下回るか調べ、下回る場合は１５１５以降を実行する。閾値Ｔは０以上かつネットワークストレージの最大容量よりも小さな値を指定する。例えば、容量が１００ＧＢのネットワークストレージの場合、１ＧＢ〜１０ＧＢが妥当と考えられるが、それ以外の値でも良い。１５１５では残容量が閾値Ｔを下回ったネットワークストレージＮを移動元ネットワークストレージＮｓに設定し、１５１６でＦｏｖｅｒフラグに１を設定する。移動手段１４０はこのフラグを常時監視しており、値が１に設定されると後述の平滑化処理を起動し、移動元に設定されたネットワークストレージＮのファイルグループの幾つかを他のネットワークストレージに移動し各ネットワークストレージ間の残容量の平滑化を計る。その後１５１７において一定時間スリープし、１５１３の処理へ戻る。一方、１５１４において全ての残容量が閾値Ｔを下回らなかった場合は、１５１７で一定時間スリープし、１５１３の処理へ戻る。１５１７でスリープする時間は、１秒程度を最小とし、１分出会っても良いし、１時間であっても良いし、１日であっても良いし、その他なんでも良い。スリープ時間が短いほど、容量の急激な増加に対して正確に状況を把握できるようになるが、逆に容量の監視処理自身が頻繁に動くため、仮想一元化装置の処理が重くなる。従って、容量の増減の度合いによって、適切なスリープ時間を設定する。
なお、１５１４の条件は、ネットワークストレージの最大残容量と最小残容量の差が予め定められた閾値Ｔｄより大きいかどうかという条件にしても良い。このとき、閾値Ｔｄは０からネットワークストレージの容量までの値を指定する。例えば、ネットワークストレージの容量が１００ＧＢであれば、１ＧＢ〜１０ＧＢが妥当な値であるが、それ以外でも良い。上記のように１５１４の条件を変更した場合は、このとき１５１５の処理を残容量の最も小さなネットワークストレージを移動元ネットワークストレージに設定するよう変更する。
さらに、１５１４の条件を全てのネットワークストレージの総残容量が予め定められた閾値Ｔｔを下回るかどうかという条件に変更し、１５１５を廃止して、１５１６で管理者に対して残容量が残り少なく新たにネットワークストレージを追加することを催促するメッセージを送るように変更しても良い。メッセージを送る手段は、sendmailのような公知の技術を使用して管理者にメールを送信しても良いし、管理手段１８０を介して管理者のインタフェースにメッセージを出しても良い。
(移動手段)
移動手段１４０は、ネットワークストレージを追加したり削除して、仮想一元化ネットワークストレージシステム８の構成を変更する場合に、構成変更の対象となるネットワークストレージに格納されているファイルの移動を行なう。これによって、仮想一元化ネットワークストレージシステムの構成変更が柔軟に行なえる。また、移動手段１４０は各ネットワークストレージの残容量に規定以上のばらつきが生じた場合に、ファイルをネットワークストレージ間で移動し、残容量の平滑化を図る。ファイルを移動しないと、いづれかのネットワークストレージが一杯になった段階で、他のネットワークストレージに空きがあっても、一切ファイルの書き込みができなくなる。これに対して、上記のようにファイルを移動することによって、ほぼ全てのネットワークストレージの容量を使い切るまで使用できるようになる。
移動手段１４０には、基本移動機能、ネットストレージ追加時の移動機能、ネットストレージ削除時の移動機能、平滑化機能の四つの機能がある。各機能に対応して、それぞれ移動処理、追加処理、削除処理、平滑化処理がある。それぞれの処理の詳細を以下に示す。
(移動処理)
移動処理は、ファイルをファイルグループ単位で現在格納されているネットワークストレージから別のネットワークストレージに移動する。図１２に移動処理のフローを示す。移動対象ファイルグループＧｍと、移動先ネットワークストレージＮｄを設定して移動処理１４０１を呼び出すと、移動手段１４０はファイルグループＧｍを現在格納されているネットワークストレージから、移動先ネットワークストレージＮｄに移動する。移動処理はまず１４０２でグループ配置１２０を参照し、移動対象グループＧｍのファイルが現在格納されているネットワークストレージＮｓを求める。次に、ファイルシステム１００のファイルをルートディレクトリ／から一つずつ探索し、ファイルグループＧｍに属するファイルを特定する。このためまず１４０３でファイルシステム１００に探索すべきファイルＦが存在するか調べ、存在する場合は１４０４でファイルＦのiノード番号Ｉを求める。１４０５でファイルＦのiノード番号Ｉにハッシュ関数Ｈａｓｈを適用してファイルＦの属するファイルグループを求め、それが移動対象ファイルグループＧｍと一致する場合は、１４０６でファイルＦを移動元ネットワークストレージ装置Ｎｓから移動先ネットワークストレージＮｄに移動する。移動は、移動手段１４０が、移動元ネットワークストレージＮｓにファイルＦのＲＥＡＤ要求を発行してファイルを読み出し、読み出した内容をそのまま引数としたＷＲＩＴＥ要求を移動先ネットワークストレージＮｄに発行してファイルを書き込み、最後に移動元ネットワークストレージのファイルＦを削除する。あるいは、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用してファイルを移動元から移動先にコピーした後、移動元のファイルを削除しても良い。その他、ファイルを移動元ネットワークストレージから移動先ネットワークストレージに移動できればどんな方法を用いても良い。移動が終わると１４０３に戻って処理を続ける。１４０３で探索すべきファイルが存在しない場合は、移動対象ファイルグループＧｍに属する全てのファイルを移動し終えているので、１４０７でグループ配置１２０のファイルグループＧｍの欄に移動先ネットワークストレージＮｄを書き込み、処理を終了する。
本移動処理は、本発明の仮想一元化ネットワークストレージシステム８の管理者がユーザインタフェース経由で管理手段１８０に対し、移動対象ファイルグループＧｍと移動先ネットワークストレージＮｄを指定し移動の指示を与えたときに呼び出されるか、あるいは、追加処理、削除処理、平滑化処理の処理過程において呼び出される。
移動処理後に、移動処理によって格納先ネットワークストレージが変更されたファイルＦに対し、クライアント１からファイルアクセス要求があった場合、要求処理手段１３０は移動手段１４０が１４０７で変更した後のグループ配置１２０を参照して、格納先ネットワークストレージを決定する。このため、ファイルＦの格納先ネットワークストレージが変更されても、クライアント１は正しくファイルＦにアクセスできる。
なお、移動手段１４０がファイルグループＧｍを移動している最中に、クライアント１がファイルグループＧｍに属するファイルへアクセス要求を発行した場合、要求処理手段１３０は、ファイルグループＧｍの移動が終了するまで、クライアントからのファイルアクセス要求を実行しない。
(追加処理)
本発明の仮想一元化装置３は仮想一元化ネットワークストレージシステム８の容量が不足したとき、新しくネットワークストレージ装置を追加することで、容量を増大することができる。
仮想一元化ネットワークストレージシステム８の管理者は、追加するネットワークストレージをネットワーク４に接続し、ユーザインタフェースを介して管理手段１８０にアクセスし、追加処理の開始を指示する。すると管理手段１８０は、移動手段１４０の追加処理(図１３の１４１１)を呼び出す。
追加処理は、仮想一元化ネットワークストレージシステム８にネットワークストレージを追加した場合に、既存のネットワークストレージを格納先とするファイルグループの幾つかを追加したネットワークストレージに移動し、これによって追加したネットワークストレージを仮想一元化ネットワークストレージシステムに取り込む。処理の詳細フローを図１３に示す。まず、１４１２で追加するネットワークストレージを移動先ネットワークストレージＮｄに設定する。次に１４１３において、容量テーブル１５００の１５０３の行を参照し、ストレージの残容量が最も小さなネットワークストレージを移動元ネットワークストレージＮｓとする。そして１４１４で、グループ配置１２０を参照し、移動元ネットワークストレージＮｓを格納先とするファイルグループを求め、その中からランダムに一つファイルグループを選択し、それを移動対象ファイルグループＧｍに設定する。そして、前述の図１２の移動処理１４０１を呼び出し、移動対象ファイルグループＧｍを移動元ネットワークストレージＮｓから追加したネットワークストレージである移動先ネットワークストレージＮｄに移動する。移動が終了すると、１４１６において、容量テーブル１５００を参照し、移動先ネットワークストレージＮｄの残容量ともっとも少ない残容量を求め、その差が予め定められた閾値Ｔｃを超えれば１４１３に戻って処理を続け、そうでなければ処理を終了する。閾値Ｔｃは、１００ＭＢ、５００ＭＢ、あるいは、１ＧＢなど、なんでも良い。ネットワークストレージ追加時の移動処理にかかる時間を短縮するには、閾値に大きな値を設定する。時間がかかっても各ネットワークストレージ間の残容量の格差を小さくしたい場合は閾値に小さな値を設定する。
なお、１４１３において移動元ネットワークストレージを選択する方法は、ランダムに選択しても良いし、予め定められた順に選択しても良いし、どんな方法を用いても良い。また、１４１４においてファイルグループＧｍを選択する方法は、予め定められた順に選択しても良いし、その他どんな方法を用いても良い。また、１４１６において残容量により終了判定するのではなく、移動したファイルグループの数が予め定めておいた値を超えたら終了するという条件にしても良い。
追加処理の終了後、クライアント１がファイルアクセス要求を発行し、そのアクセス要求の対象が、上記追加処理によって追加ネットワークストレージに移動したファイルグループに属するファイルである場合、要求処理手段１３０はクライアント１からのアクセス要求を追加しネットワークストレージに送り、追加ストレージにてファイルアクセス処理を行う。このように、クライアント１から見ると、仮想一元化ネットワークストレージシステムにネットワークストレージを追加しても、ファイルアクセスの手順は追加前と変わらない。クライアント１から見た場合の唯一の違いは、仮想一元化ネットワークストレージシステムの容量が追加したネットワークストレージの容量分だけ増えたように見えることである。(削除処理)
本実施例の仮想一元化装置３は仮想一元化ネットワークストレージシステム８の容量があまっていて利用しないなどの理由で、システム内のネットワークストレージを取り除き、容量を小さくすることができる。ただし、ネットワークストレージを削除することができるのは、システム全体の空き容量が削除するネットワークストレージの容量より多く存在する場合に限られる。
仮想一元化ネットワークストレージシステム８の管理者は、ユーザインタフェースを介して管理手段１８０にアクセスし、削除するネットワークストレージを指定して削除処理の開始を指示する。すると管理手段１８０は、移動手段１４０の削除処理(図１４の１４２１)を呼び出す。
削除処理は、仮想一元化ネットワークストレージシステム８内のネットワークストレージ５，６，７のいづれかを削除する場合に、削除するネットワークストレージを格納先とする全てのファイルグループをその他のネットワークストレージに移動し、削除するネットワークストレージを仮想一元化ネットワークストレージシステムから論理的に切り離す。処理の詳細フローを図１４に示す。まず、１４２２で削除するネットワークストレージを移動元ネットワークストレージＮｓに設定する。次に１４２３で、容量テーブル１５００の１５０３の行を参照し、ストレージの残容量が最も大きなネットワークストレージを移動先ネットワークストレージＮｄとする。そして１４２４で、グループ配置１２０を参照し、移動元ネットワークストレージＮｓを格納先とするファイルグループを求め、その中からランダムに一つファイルグループを選択し、それを移動対象ファイルグループＧｍに設定する。そして、前述の図１２の移動処理１４０１を呼び出し、移動対象ファイルグループＧｍを削除するネットワークストレージである移動元ネットワークストレージＮｓから移動先ネットワークストレージＮｄに移動する。移動が終了すると、１４２６で、移動元ネットワークストレージＮｓにファイルグループが存在すれば１４２３に戻って処理を続け、そうでなければ処理を終了する。
１４２３の移動先ネットワークストレージの選択方法は、ネットワークストレージの残容量が移動するファイルグループの容量よりも大きければ、ランダムに選択しても良いし、予め順番を決めてその順に選択しても良い。また、１４２４においてファイルグループＧｍの選択方法は、予め定められた順番に選択しても良いし、その他どんな方法で選択しても良い。
上記削除処理が終了すると、管理手段１８０はインタフェースを介して管理者に削除の終了を報告する。この報告を受けて管理者は論理的に切り離されたネットワークストレージをネットワーク４から物理的に切り離す。
削除処理の終了後、クライアント１がファイルアクセス要求を発行し、そのアクセス要求の対象が、削除前に削除したネットワークストレージを格納先とするファイルグループに属するファイルであった場合、要求処理手段１３０はクライアント１からのアクセス要求を削除したネットワークストレージではなく、移動先ネットワークストレージに送り、ファイルアクセス処理を行う。このように、クライアント１から見ると、仮想一元化ネットワークストレージシステムからネットワークストレージを削除しても、ファイルアクセスの手順は削除前と変わらない。クライアント１から見た場合の唯一の違いは、仮想一元化ネットワークストレージシステムの容量が削除したネットワークストレージの容量分だけ減ったように見えることである。
(平滑化処理)
クライアント１が仮想一元化ネットワークストレージシステム８に対してファイルの書き込み要求を発行し、書き込み対象ファイルの格納先ネットワークストレージに空きがない(残容量が０)場合、他のネットアークストレージに大量の空きがあっても、そのファイルの書き込みはできない。このような状況に対処するため、仮想一元化装置３は、ネットワークストレージの残容量が少なくなったり、ネットワークストレージ間の残容量の格差が広がると、平滑化処理を起動して、各ネットワークストレージの残容量が均等になるようにファイルグループの移動を行う。平滑化処理は、仮想一元化装置３の起動時に移動手段１４０が独立したスレッドまたはプロセスとして平滑化処理(図１５の１４３１)を起動する。平滑化処理の詳細を図１５に示す。平滑化処理はバックグラウンドで動いているが、１４３２でＦｏｖｅｒというフラグが０である間は処理を行わない。このフラグは、前述の(容量監視手段)のところで述べたように、ネットワークストレージの残容量が定められた閾値を下回った場合、そのネットワークストレージを移動元ネットワークストレージＮｓとしＦｏｖｅｒを１に設定する。あるいは、ネットワークストレージの最大残容量と最小算容量の差が閾値を超えた場合に、残容量の最も小さなネットワークストレージを移動元ネットワークストレージに設定し、Ｆｏｖｅｒを１に設定する。Ｆｏｖｅｒが１に設定されると、平準化処理は１４３３で移動元ネットワークストレージＮｓを格納先とするファイルグループのうちの一つをランダムに選択して移動対象ファイルグループＧｍとし、１４３４で残容量が最大のネットワークストレージを移動先ネットワークストレージＮｄとし、１４３５で１４０１の移動処理を呼び出しファイルグループＧｍを移動元ネットワークストレージＮｓから移動先ネットワークストレージＮｄに移動する。１４３６で、ネットワークストレージの最大残容量と最小残容量の差が前述の追加処理で説明した閾値Ｔｃの値より大きければ、１４３３に戻って処理を続け、小さくなれば１４３７でＦｏｖｅｒフラグを０に設定して、１４３２に戻る。なお、１４３３においてＮｓからＧｍを選択する方法は、予め定められた順番に選択する方法であっても良いし、その他どのような方法であっても良い。また、１４３４において、Ｎｄに設定するネットワークストレージは、移動元ネットワークストレージＮｓ以外のネットワークストレージを選択できれば、どのような方法を用いても良い。
上記の処理によって、ネットワークストレージ間の残容量の差が小さくなり、特定のネットワークストレージの容量不足によってファイルの書き込みができなくなるという問題を解決することができる。
以上自動的に平滑化処理を起動する場合について説明したが、管理者がユーザインタフェースを介して管理手段１８０にアクセスし、平滑化処理の実行を指示しても良い。このとき、管理者は移動元ネットワークストレージを引数として与える。移動手段１４０は図１５の１４３３を呼び出して平滑化の処理を行い。１４３６で条件が満足されなくなると処理を終了する。なお、管理手段１８０はユーザインタフェースを介して、容量テーブル１５００の情報を管理者にリアルタイムに提供し、管理者が平滑化処理や追加処理や削除処理を行うべきかどうか判断する手助けにすることが望ましい。
(統合手段)
本発明の仮想一元化ネットワークストレージシステム８でない、一般的なネットワークストレージを用いているサイトにおいて、ネットワークストレージの容量が不足すると、新規に既存ネットワークストレージを購入するのが一般的である。しかしこの場合、クライアントからは、既設ネットワークストレージと追加ネットワークストレージが独立して見えるため、使い勝手が悪い。このような場合に対処するため、本発明の仮想一元化手段３は統合化手段１８０によって、既設ネットワークストレージを取り込んで仮想一元化ネットワークストレージシステムを構成し、既設ネットワークストレージのファイルを含みかつより容量の大きな仮想一元化ネットワークストレージを提供する。
図１のネットワーク２に既設ネットワークストレージが接続されており、クライアント１のファイルが既設ネットワークに格納されているものとする。管理者はネットワーク２に仮想一元化ネットワークシステム８を接続し、ユーザインタフェースを介して仮想一元化装置３の管理手段１８０にアクセスし、統合する既設ネットワークストレージを指定して統合の開始を指示する。すると、仮想一元化装置３の統合手段１６０は図１６の１６０１を呼び出し、統合処理を開始する。統合処理はまず１６０２でグループ配置１２０の各ファイルグループに対応したネットワークストレージの欄に、既設ネットワークストレージ又は追加したネットワークストレージの中の一つをそれぞれ書き込む。例えば、ファイルグループが１〜４の４つあり、ネットワークストレージが既設と追加の２つである場合、ファイルグループ１と２に既設ネットワークストレージを、ファイルグループ３と４に追加ネットワークストレージをそれぞれ対応付ける。あるいは、全てのファイルグループに既設ネットワークストレージを割り当てても良いし、その他どのような割当にしても良い。このグループ配置１２０へのネットワークストレージの書き込み方によって、既設ネットワークストレージを仮想一元化ネットワークストレージシステム８に統合し運用を開始した直後における、ファイルグループの格納先ネットワークストレージが決定される。次に１６０３で、図１７の１６６１を呼び出す。そして、まず１６６２で、既設ネットワークストレージに未探索のファイルオブジェクトＦが存在するか調べ、存在する場合は１６１３でファイルオブジェクトＦがディレクトリかどうか調べ、ディレクトリなら１６１４で仮想一元化装置３のファイルシステム１００にディレクトリＦを生成して１６１２に戻って処理を継続する。１６１３で一方ファイルオブジェクトＦがディレクトリでなくファイルである場合は、１６１５でファイルＦと同じ名前と属性を持ちサイズ０のダミーファイルをファイルシステム１００に生成し、１６１２に戻って処理を継続する。１６１２で未探索のファイルオブジェクトが存在しなければ、図１６の１６０３の処理は終了する。次に、１６０４において図１８の１６２１を呼び出す。すると１６２２でファイルシステム１００に未探索のファイルＦが存在するかどうか調べ、存在する場合は１６２３でファイルＦのiノード番号Iを求める。１６２４でファイルＦの属するファイルグループＧを、iノード番号Ｉにグループマップ１１０で与えられたハッシュ関数Ｈａｓｈを適用して求める。１６２５で、グループ配置１２０を参照しファイルグループＧの格納先ネットワークストレージＮを求める。この格納先ネットワークストレージは図１６の１６０２で設定したものである。統合中の現時点において、全てのファイルグループは既設ネットワークストレージに格納されているから、１６２５で求めたファイルグループＧの格納先ネットワークストレージＮが既設ネットワークストレージでである場合には（１６２６）グループ配置の設定と現状とが一致するので何もしなくて良く、１６２２に戻って処理を続ける。もし、１６２６でＮが既設ネットワークストレージでない場合には、１６２７において、ファイルＦを既設ネットワークストレージからネットワークストレージＮに移動する。移動の方法は、既設ネットワークストレージにＲＥＡＤ要求を発行してファイルＦを読み出し、ネットワークストレージＮに読み出したデータを引数としてＷＲＩＴＥ要求を発行してファイルＦを書き込み、最後に既設ネットワークストレージのファイルＦを削除すればよい。移動が終了すると１６２２に戻って処理を続ける。１６２２において、未探索のファイルが存在しなくなると図１６の１６０４の処理が終了し、統合処理全体も終了する。
なお、統合手段１６０による統合処理の実行中は、要求処理手段によるファイルアクセス処理や移動手段による追加・削除・平滑化処理を停止する。
統合処理が終了したあと、クライアント１が既設ネットワークストレージの代わりに仮想一元化装置３に対してファイルアクセスコマンドを発行すると、仮想一元化装置３はアクセス対象ファイルＦの格納先ネットワークストレージに対しアクセス要求を発行してファイルアクセスを行うため、クライアントにとっては既設ネットワークストレージにアクセスするのと、既設ネットワークストレージを統合化した仮想一元化ネットワークストレージシステムにアクセスする場合とで違いは無く、ただ後者の方が容量が多いように見える。
以上、仮想一元化装置３の各構成要素について説明した。これらの各構成要素を搭載した仮想一元化装置の実装例を図１９に示す。ＣＰＵ２０、コントローラ２１、メモリ２２、Ｉ／Ｏインタフェース２３、ネットワークインタフェース２４、ディスク装置２５から構成されるサーバ、ワークステーション、あるいはＰＣをハードウェアとして、前述のＵＮＩＸ系オペレーティングシステム、例えばＬｉｎｕｘを搭載し、ファイルシステム１００、グループマップ１１０、グループ配置１２０はそれぞれデータとしてディスク装置２５に格納し、要求処理手段１３０、移動手段１４０、容量監視手段１５０、統合手段１６０、管理手段１８０はそれぞれプログラムコードとしてメモリ２２に配置し、ＣＰＵ２０がそれらを実行することで仮想一元化装置として機能する。
＜実施例２＞
図２０は本発明の第２の実施例を含む情報システムの全体構成を示す図である。本実施例は図１の実施例１の変形であるから、実施例１との相違部分についてのみ説明する。１４は図１の仮想一元化ネットワークストレージシステム８と同等の機能を持つ仮想一元化ネットワークストレージシステムである。１４のネットワーク４と一つ以上のネットワークストレージ６、７は図１の８の仮想一元化ネットワークストレージシステムと同じであり、異なるのは１２の仮想一元化装置である。本実施例の仮想一元化装置１２は、ファイルシステム１００、グループマップ１１０、グループ配置１２０、要求処理手段１３０、移動手段１４０、容量監視手段１５０、統合手段１６０、管理手段１８０は実施例１の仮想一元化装置３と同一であり、ネットワークストレージ５、６、７の同一のリモート制御手段１０とファイルシステムを構築したストレージ装置１１を持ち、ネットワークストレージとしても機能するネットワークストレージ機能付き仮想一元化装置である点が異なる。８の仮想一元化装置はそれ単独では仮想一元化ネットワークストレージシステムを構成することはできず、他に必ずネットワークストレージを接続する必要があるが、本実施例のネットワークストレージ機能付き仮想一元化装置の場合は、それ単体で仮想一元化ネットワークストレージシステムを構成することが可能であり、より安価に仮想一元化ネットワークストレージシステムを提供できる。一方、実施例２はネットワークストレージを含むため、仮想一元化装置１２が管理データの他にファイルの実体のアクセス処理も行う必要があり、したがってＣＰＵ２０の負荷が高くなり易い。すなわち、実施例１の方がより高い性能を出すことができるという点で優れている。
本実施例の場合グループ配置１２０にはネットワークストレージ装置としても機能する仮想一元化装置１２も特定のファイルグループの格納先として登録する。クライアント１がファイルアクセス要求を発行すると、要求処理手段１３０がそれを受け、アクセス対象ファイルの格納先ネットワークストレージを求め、求めた格納先ネットワークストレージ装置にファイルアクセス要求を発行してファイルアクセスを行う一連の処理は実施例１と同じである。ただし本実施例の仮想一元化装置はネットワークストレージとしても機能し、格納先ネットワークストレージが一元管理装置１２であった場合、要求手段１３０は自身のリモート制御手段１０に対してファイルアクセス要求を発行し、リモートアクセス手段１０は要求処理手段１３０からの要求を受けてストレージ装置１１に対してファイルアクセス処理を行う。
なお、本実施例２のネットワークストレージ機能付き仮想一元化装置１２のストレージ装置１１を２つのパーティションに分割し、その一方にファイルシステム１００を搭載して管理用のファイルシステムとして用い、もう一方のパーティションにもファイルシステムを搭載してファイルの実体を格納するために用いても良い。
＜実施例３＞
図２１は本発明の第３の実施例を含む情報システムの全体構成を示す図である。本実施例は図１の実施例１の変形であるから、実施例１との相違部分についてのみ説明する。まず図１では仮想一元化装置３の内部に存在した要求処理手段１３０に少し手を加えて、仮想一元化装置１３と分離する。この要求処理手段１３１は、サーバ、ワークステーション、ＰＣ等の公知のハードウェア上にＬｉｎｕｘ等の既存オペレーティングシステムを搭載し、そこに要求処理手段１３１を搭載することで実装する。１３１はクライアント１とＮＦＳプロトコルを用いてファイルアクセス処理を行う。クライアント１は複数ある要求処理手段１３１の何れかにファイルアクセス要求を発行する。要求処理手段１３１は自身の中にファイルシステム１００等の管理情報を持たず、クライアント１がファイルアクセス要求を発行すると、ネットワーク２を介して一元管理装置１３の要求処理手段１３２にアクセスしてアクセス対象ファイルの格納先ネットワークストレージを求める。そして求めた格納先ネットワークストレージにファイルアクセス要求を発行してファイルアクセスを行う。ファイルアクセス要求が終了すると要求処理装置１３１はネットワークストレージから得られたファイルアクセス要求の結果を要求元クライアント１に返す。ＮＦＳの各プロシージャの処理に関しては、自身のファイルシステム、グループマップ、及び、グループ配置にアクセスする代わりに、上記のようにネットワーク経由で仮想一元化装置３の要求処理手段１３２にアクセスし、ファイルシステム１００、グループマップ１１０、グループ配置１２０にアクセスして所望のデータを取得すること意外実施例１で説明した処理と同様である。一元管理装置１３の要求処理手段１３２は要求処理手段１３１からの管理情報へのアクセス要求を受け、ファイルシステム１００、グループマップ１１０、グループ配置１２０の参照や更新作業を行う。その他、仮想一元化装置１３における各種の手段の処理は実施例１と同じである。
本実施例３はクライアント１からファイルアクセス要求を受ける要求処理手段１３１を、仮想一元化装置１３と独立させ、かつ、複数設けることによって、実施例１と比べてより多くのクライアントからのリクエストに答えられるようになる。すなわち高い性能が要求される環境での使用は本実施例の形態をとると良い。なお、要求処理手段を複数持たせると、クライアント１から本発明の仮想一元化ネットワークストレージシステムに複数のエントリポイントがあるように見える。そこで、複数の要求手段１３１の前段に負荷分散装置等の公知な技術を導入してエントリポイントを一元化しても良い。
【０００８】
【発明の効果】
本発明のネットワークストレージシステムの仮想一元化方法及び装置はファイルの格納先ネットワークストレージをファイルグループを単位として管理する。ファイルからそのファイルが属するファイルグループを求めるファイルマップを固定的に与えておいて、ファイルグループとその格納先ネットワークストレージとの対応をグループ配置として管理し、ネットワークストレージの追加や削除等の構成変更があった場合には、このグループマップを変更する。このようなファイルグループを単位とした管理方法により、ファイル毎に格納先ネットワークストレージの情報を持つ従来の方法と比べて管理情報が少なくなり、ネットワークストレージの容量を有効に利用できるようになる。
また、仮想一元化ネットワークストレージシステムの構成変更時には、ファイルグループを単位としてファイルの格納先ネットワークストレージを移動する。この際に、グループ配置の移動するファイルグループの格納先ネットワークストレージを変更するだけで良いので、ファイル毎に格納先情報を管理する場合に比べてオーバヘッドを小さくできる。
【図面の簡単な説明】
【図１】本発明のネットワークストレージ装置の仮想一元化方法の構成を示す図である。
【図２】ファイルシステムの構造を示す図である。
【図３】ファイルシステムの構造を説明するために使用するディレクトリ構造の例題を示す図である。
【図４】グループ配置の構成を示す図である。
【図５】ＣＲＥＡＴＥ要求に対する処理の流れを示すフローチャートである。
【図６】ファイルハンドラの構成を示す図である。
【図７】ＬＯＯＫＵＰ要求に対する処理の流れを示すフローチャートである。
【図８】ＲＥＡＤ要求に対する処理の流れを示すフローチャートである。
【図９】ＭＫＤＩＲ要求に対する処理の流れを示すフローチャートである。
【図１０】容量テーブルの構成を示す図である。
【図１１】容量の監視処理の流れを示すフローチャートである。
【図１２】ファイルグループをネットワークストレージ間で移動する処理の流れを示すフローチャートである。
【図１３】ネットワークストレージ装置を追加する場合の処理の流れを示すフローチャートである。
【図１４】ネットワークストレージ装置を削除する場合の処理の流れを示すフローチャートである。
【図１５】ネットワークストレージ間で容量に不均衡が生じた場合に行う各ネットワークストレージの残容量の平滑化処理のフローチャートである。
【図１６】既設ネットワークストレージ装置の仮想一元化ネットワークストレージシステムへの統合方法の処理の流れを説明するフローチャートである。
【図１７】既設ネットワークストレージ装置の統合に際して行うファイル識別子の生成方法の処理の流れを示すフローチャートである。
【図１８】既設ネットワークストレージ装置の統合に際して行うファイルの移動処理の流れを示すフローチャートである。
【図１９】本発明の仮想一元化方法を搭載した計算機システムの図である。
【図２０】ネットワークストレージとしての機能を備えた一元管理装置の構成を示す図である。
【図２１】複数の要求処理手段を備えた仮想一元化ネットワークストレージシステムを示す図である。
【符号の説明】
１ クライアント
２、４ ネットワーク
３ 仮想一元化装置
５、６、７ ネットワークストレージ
８、１４、１５ 仮想一元化ネットワークストレージシステム
１０ リモート
１１ ストレージ装置
１２ ネットワークストレージ機能付き仮想一元化装置
１３ 要求処理部を持たない仮想一元化装置
２０ ＣＰＵ
２１ コントローラ
２２ 主記憶
２３ Ｉ／Ｏインタフェース
２４ ネットワークインタフェース
２５ ストレージ装置
１００ ファイルシステム
１１０ グループマップ
１２０ グループ配置
１３０、１３１、１３２ 要求処理手段
１４０ 移動手段
１５０ 容量監視手段
１６０ 統合手段
１７０ ファイルハンドル
１８０ 管理手段
１００１、１００２、１００３、１００４、１００５、１００６，１００７ ｉノード
１００８，１００９，１０１０，１０１１ ディレクトリエントリ
１０１２，１０１３，１０１４ データブロック
１５００ 容量テーブル。
【発明の属する技術分野】
本発明は、複数のネットワークストレージ装置をクライアントから一つのネットワークストレージ装置として見せる、ネットワークストレージの仮想一元化方法、及び、仮想一元化装置に関する。
【０００２】
【従来の技術】
従来の情報システムは情報を処理する計算機に情報を格納するストレージをローカル接続して使用していた。ところが、近年ネットワーク技術の発達に伴い、ストレージを計算機から分離してネットワークに接続し、ネットワーク経由でストレージにアクセスする形態が普及しつつある。このようなネットワーク接続されたストレージをネットワークストレージと呼ぶ。
ネットワークストレージの代表としてSAN（Storage Area Network）ストレージとNAS(Network Atacched Storage)がある。SANストレージはネットワークとして専用に開発されたSANを用い、性能と信頼性は高いが非常に高価であり、主にエンタープライズ向けに使用される。一方、NASはネットワークとして最も普及しているIPネットワークを使用し、性能はSANストレージより低いが、価格がSANストレージに比べて低く、また手軽に使用できる。
近年、高価で大規模なストレージを用いるより、小規模で安価なNASを複数台用いて、性能と容量を確保したいという要求がある。しかし、NASの台数が増えると、それらを管理するコストが増大するという問題がある。そこで、システム管理コストを抑制するために、複数のNASを計算機から仮想的に一つのNASとして見せ、新しいNASの追加や既存NASの削除を行なっても、計算機には影響を及ぼさないNASの仮想一元化技術が必要となる。
このようなNASの仮想一元化技術として、いくつかの方式が開発されている。例えば、http://www.maxtor.com/products/maxattach/default.htmには、プライマリストレージと呼ばれる管理サーバを兼ねたネットワークストレージがファイルの配置情報を一括管理し、ファイルのアクセス時刻等の属性を用いて格納するネットワークストレージを決定する複数ネットワークストレージの仮想的に一つのネットワークストレージとして見せる方法について記載されている。新規に生成されるファイルはプライマリストレージに格納し、しばらくアクセスされなかったファイルはプライマリストレージからセカンダリストレージに移動される。計算機からのファイルアクセスはプライマリストレージが受け付け、そのファイルがセカンダリストレージに存在する場合は、セカンダリストレージにファイルアクセスを行なうことで、計算機からはあたかも一つのネットワークストレージのように見える。
また、The Zebra Striped Network File System、Hartman et. al.、ACM Transactions on Computer System、vol. 13、No. 3、1995、pp.274-310.には、ファイルを部分的に複数のネットワークストレージに分散して格納し、ファイルがどのストレージにどのような順番で格納されているか集中管理するサーバを設けることによって、複数のネットワークストレージを仮想的に一つのネットワークストレージに見せる方法が記載されている。このように一つのファイルをネットワークストレージ間でストライピングする方法では、ファイルの容量が非常に大きい場合でも、各ネットワークストレージに均等にデータを書き込むことができる。また、DiFFS：a Scalable Distributed File System, Christos Karamanolis et. al.、HP Laboratories Palo Alto、HPL-2001-19、January 24, 2001には、上記の集中管理サーバ方式と異なる非集中管理サーバ方式により、複数のネットワークストレージを仮想的に一つのネットワークストレージとして見せる方法について記載されている。この方法は、ファイルの格納先ネットワークストレージをディレクトリとファイルを管理するディレクトリエントリ内に格納し、このディレクトリエントリを各ネットワークストレージに分散して配置する。
また、米国特許第６，０２９，１６８号には、上記の非集中管理サーバ方式でかつ、一つのファイルを部分的に複数のネットワークストレージに分散して格納する方法が記載されている。この方法はファイルをどのネットワークストレージにどのような順番で配置するかを、各ネットワークストレージに分散して管理する。
【０００３】
【発明が解決しようとする課題】
前記http://www.maxtor.com/products/maxattach/default.htmの方法、及び、前記DiFFS：a Scalable Distributed File Systemの方法は、ファイルの管理情報を集中して持つか分散して持つかの違いはあるが、ファイル毎に格納先ネットワークストレージの情報を持つ。また、前記The Zebra Striped Network File systemの方法、及び、米国特許６，０２９，１６８号の方法は、ファイルの断片毎に格納先ストレージの情報を持つ。このようなファイル毎あるいはファイルの断片ごとに格納先ネットワークストレージの情報を持つと、格納するファイルの数に比例して管理する情報も増大し、この管理情報がネットワークストレージのデータ格納用領域のサイズを圧迫する。
さらに、仮想的に一元化された複数のネットワークストレージに新しいネットワークストレージを追加したり、あるいは、削除したりして構成変更するのに伴い、ファイルの格納先ネットワークストレージが変更されると、格納先の変更された全てのファイルに対して、格納先ネットワークストレージの情報を書き換える必要があり、これが構成変更時の性能に影響を及ぼす。
本発明の目的は、ファイルの格納先に関する管理情報をコンパクト化し、データ格納領域が圧迫されないような複数ネットワークストレージの仮想一元化方法を提供することにある。本発明の他の目的は、ネットワークストレージの構成変更に伴って発生するファイル移動の際の管理情報の更新処理のオーバヘッドを低減し、柔軟にかつ高速に構成変更可能な、複数ネットワークストレージの仮想一元化方法を提供することにある。
【０００４】
【課題を解決するための手段】
本発明は、一つまたは複数のネットワークストレージから構成される仮想一元化ネットワークストレージシステムにおいて、ファイルの格納先ネットワークストレージをファイルグループを単位として管理するところに特徴がある。ファイルが属するファイルグループを予めグループマップとして定義しておく。グループマップは、例えばファイル識別子を検索鍵としたハッシュ関数として与える。さらに、ファイルグループと、そのファイルグループに属するファイルの格納先ネットワークストレージを定めるグループ配置を設けておく。グループ配置は、例えばファイルグループとネットワークストレージとの対応を記録するテーブルやデータベースとして与える。クライアントがファイルにアクセスする際は、まずアクセス対象ファイルのファイル識別子とグループマップとから、そのファイルが属するファイルグループを求める。次に、グループ配置を参照して求めたファイルグループに対応したネットワークストレージを求める。求めたネットワークストレージがアクセス対象ファイルの格納先ネットワークストレージであるから、前記ネットワークストレージに対してファイルアクセスを行なう。この発明によれば、一つ以上のファイルから構成されるファイルグループを単位として格納先ネットワークストレージの情報を持つため、ファイル毎に管理情報を持つ場合にくらべて管理情報が少なくなる。
また、仮想一元化ネットワークストレージシステムの構成変更時には、ファイルグループを単位としてファイルの格納先ネットワークストレージを移動する。この際に、グループ配置の移動するファイルグループの格納先ネットワークストレージを変更するだけで良いので、ファイル毎に格納先情報を管理する場合に比べてオーバヘッドを小さくできる。
【０００５】
【発明の実施の形態】
＜実施例１＞
図１は本発明の第一の実施例を含む情報システムの全体構成を示す図である。クライアント１はネットワーク２を介して本発明の仮想一元化装置３に接続されている。仮想一元化装置３はネットワーク４を介して、ネットワークストレージ５、６、７と接続されている。ネットワーク４を用意する代わりにネットワークストレージ５、６、７をネットワーク２に接続しても良い。ネットワーク２と４を独立すると、アクセス集中時に高い性能を出すことができる。一方ネットネットワーク２にネットワークストレージ５、６、７を接続すると、ネットワーク４が不要となり、コストを抑えることができる。仮想一元化装置３はネットワークストレージ５，６，７を仮想的に一元化し、クライアント１から一つのネットワークストレージとしてアクセスできる仮想一元化ネットワークストレージシステム８を提供する。
(ネットワークストレージ)
ネットワークストレージ５、６、７は公知の技術によって構成されるもので、リモート制御手段１０とストレージ装置１１とを備える。ストレージ装置１１にはファイルシステムを搭載する。
ネットワークストレージ５、６、７は専用装置であっても良いし、ストレージ装置を備えた汎用のサーバ、ワークステーション、あるいは、ＰＣにリモート制御手段を搭載しても良い。リモート制御手段１０は、ネットワーク上に接続されたクライアントからのマウント要求とファイルの生成、読み出し、書き込み、あるいは、ディレクトリの生成等の要求を受け、ローカルストレージ装置のファイルシステムに対してファイルの生成、読み出し、書き込み、あるいは、ディレクトリの生成等を行なう。リモート制御手段１０は、サン・マイクロシステムズ社(Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．)によって開発されたＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）や、マイクロソフト社(Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ)によって開発されたＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）等のファイルアクセスプロトコルを使用して、クライアントとの通信を行なう。本実施例１ではファイルアクセスプロトコルとしてＮＦＳを用いるものとする。ＮＦＳの要求を受けファイルアクセス処理を行なうリモート制御手段１０としては、公知のｍｏｕｎｔｄとｎｆｓｄを使用する。
(仮想一元化装置)
本実施例の仮想一元化装置３は、ファイルシステム１００、グループマップ１１０、グループ配置１２０、要求処理手段１３０、移動手段１４０、容量監視手段１５０、統合手段１６０、管理手段１８０から構成される。ファイルシステム１００、グループマップ１１０、グループ配置１２０は主にファイルの格納先ネットワークストレージを定めるために用いられる。詳細は後述の(ファイルシステム)、(グループマップ)、(グループ配置)の項で説明する。要求処理手段１３０はクライアントからのファイルアクセス要求を処理する。詳細は後述の(要求処理手段)の項で説明する。移動手段１４０は、ネットワークストレージを追加したり削除したり、あるいはネットワークストレージの一つの残容量が定められた値を下回った場合に、ファイルをネットワークストレージ間で移動する。詳細は後述の(移動手段)の項で説明する。容量監視手段１５０は各ネットワークストレージの容量を常時監視し、必要があれば移動手段を起動する。詳細は後述の(容量監視手段)の項で説明する。統合手段１６０は既に運用中の既設ネットワークストレージ装置を仮想一元化ネットワークストレージシステムに統合する際の処理を行なう。詳細は後述の(統合手段)の項で説明する。管理手段１８０は仮想一元化ネットワークストレージシステム８を管理する管理者からの指示を受け付け、仮想一元化装置３の設定を変更したり、移動手段１４０や統合手段１６０を呼び出して構成変更等の要求に対応する。管理者は、クライアント１上の汎用Ｗｅｂブラウザをユーザインタフェースとして管理手段１８０へのアクセスする。あるいは、クライアント１に専用のユーザインタフェースプログラムを搭載してそれを使用したり、仮想一元化装置にコンソールを接続しそれを用いても良い。
仮想一元化装置３の処理の概要を説明する。クライアント１はまず仮想一元化装置３に対してマウント要求を発行して、仮想一元化ネットワークストレージシステム８が共有を許可しているディレクトリをクライアント１のファイルシステムの特定の場所にマウントする。そしてクライアント１がファイルアクセス要求を発行すると、仮想一元化装置３の要求処理手段１３０がそれを受け、ファイルシステム１００、グループマップ１１０、グループ配置１２０を用いて、アクセス対象ファイルの格納先ネットワークストレージを求める。そして、その格納先ネットワークストレージに対してクライアントから受けたファイルアクセス要求を送る。格納先ネットワークストレージがファイルアクセスを実行し終わると、仮想一元化装置３は格納先ネットワークストレージからの得られたデータを要求元クライアント１に返す。このように、クライアント１はアクセス対象ファイルがどのネットワークストレージに存在するか知る必要はなく、複数のネットワークストレージを一つの大きなネットワークストレージとしてアクセスできる。
なお、本発明の仮想一元化装置３は、全てのファイルを一つ以上のファイルグループに分割し、ファイルグループごとにファイルの格納先ネットワークストレージ装置を与え、同一ファイルグループに属するファイルは同じネットワークストレージに格納する。ファイルグループは、使用するネットワークストレージ５、６、７の数と同数かあるいはそれより多く設ける。ファイルグループに属するファイルの容量が、ファイルグループ毎に大きく異なると、それを格納するネットワークストレージ間で使用容量のアンバランスが生じる。これを改善するため、ファイルグループは、ネットワークストレージ数の１０倍から１０００倍程度設ける。こうすることで、ファイルグループ当りの容量のばらつきを減少し、ネットワークストレージ間の使用容量のアンバランスを解消する。このようにファイルグループ単位で格納先ネットワークストレージを定めることで、従来技術で発生するファイル数に比例して管理情報が増加しストレージを圧迫する問題を解消でき、また、ファイル移動時に各ファイル毎に格納先ネットワークストレージの情報を書き換える必要がなくなり、オーバヘッドを減少できる。
以下では仮想一元化装置３の構成要素の詳細について説明する。
(ファイルシステム)
ファイルシステムは、仮想一元化ネットワークストレージシステム全体のディレクトリ構造と、全ファイルのファイル識別子を管理する。仮想一元化装置３が使用するファイルシステム１００はオペレーティングシステムが提供するファイルシステムを使用する。
図２はサン・マイクロシステムズ社のＳｏｌａｒｉｓ、インターナショナル・ビジネス・マシーンズ社（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ）社のＡＩＸ、ヒューレット・パッカード社(Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｍｐａｎｙ)のＨＰ−ＵＸ、Ｌｉｎｕｘ，及び、ＦｒｅｅＢＳＤ等のＵＮＩＸ系オペレーティングシステムにおけるファイルシステムの基本構造を示したものである。図２のファイルシステムは図３のディレクトリ構造を持つファイル郡を格納した様子を示している。図３の／、ｄ１、ｄ２、ｄ３はディレクトリであり、ｆ１、ｆ２、ｆ３はファイルを示している。／はルートと呼ばれディレクトリの始点を表す。
ファイルとディレクトリをまとめてファイルオブジェクトと呼ぶ。ファイルオブジェクトはファイルシステム内でｉノードと呼ばれるデータ構造１００１〜１００７として記録される。ｉノードはそれを識別するｉノード番号という固有の識別子を持つ。図２の例では、／ディレクトリにはiノード１００１が対応しそのiノード番号は２番である。ディレクトリｄ１にはiノード１００２が対応しそのiノード番号は５番である。ディレクトリｄ２にはiノード１００３が対応しそのiノード番号は７番である。ディレクトリｄ３にはiノード１００４が対応しそのiノード番号は９番である。ファイルｆ１にはiノード１００５が対応しそのiノード番号は１０番である。ファイルｆ２にはiノード１００６が対応しそのiノード番号は１４番である。ファイルｆ３にはiノード１００７が対応しそのiノード番号は１６番である。ファイルシステムにおいて、ファイルオブジェクトの識別にはｉノード番号が使用される。一方ファイルオブジェクトの名前や配置場所を管理するディレクトリ情報は、ディレクトリエントリという構造１００８、１００９、１０１０、１０１１によって管理される。ファイルシステム内のディレクトリのそれぞれに対して一つディレクトリエントリが設けられる。ディレクトリ／、ｄ１、ｄ２、ｄ３に対してそれぞれディレクトリエントリ１００８、１００９、１０１０、１０１１が対応する。ディレクトリのｉノードは、そのディレクトリに対応するディレクトリエントリへのポインタを持つ。例えば図２の場合、ディレクトリｄ１に相当するiノード１００２はディレクトリｄ１に対応するディレクトリエントリ１００９へのポインタを保持する。ディレクトリエントリは自身のディレクトリのｉノード番号とそのディレクトリ名(.で表される)の組、親ディレクトリのｉノード番号とそのディレクトリ名(..で表される)の組、及び、自身のディレクトリの直下にあるファイルまたはディレクトリのｉノード番号とファイル名又はディレクトリ名の組を構成要素とする。
ディレクトリ構造は、iノードとディレクトリエントリの相互チェーンによって管理される。例えば、／ディレクトリに相当するiノード１００１はディレクトリエントリ１００８を示しており、このディレクトリエントリを参照すると、／ディレクトリの直下にｄ１という名前のファイルオブジェクトが存在しそのiノード番号が５番であることが分かる。次に、５番のiノード１００２を参照すると、ファイルオブジェクトがディレクトリであることが分かり、それが指し示すディレクトリエントリ１００９を参照することによって、ディレクトリｄ１の直下にiノード番号７番のｄ２という名前のファイルオブジェクトとiノード番号９番のｄ３とうい名前のファイルオブジェクトが存在することがわかる。さらに、iノード番号９番のiノード１００４を参照すると、それがディレクトリであることがわかり、指し示すディレクトリエントリ１０１１を参照することによって、直下にiノード番号１６番のｆ３という名前のファイルオブジェクトが存在することがわかる。このようにして、iノードとディレクトリエントリによってディレクトリ構造が記録される。次に、ファイルに対応するiノード１００５、１００６、１００７はファイルの中身であるデータを格納するデータブロックへのポインタを記録する。図２の場合、ファイルｆ１に対応したiノード１００５はデータブロック１０１２を一つ指しており、このデータブロック１０１２内にファイルｆ１のデータが格納されている。複数のブロックを使用するファイルの場合、iノードはそれらずべてのブロックへのポインタを記録する。
以上、ＵＮＩＸ系オペレーティングシステムが提供するファイルシステムの一般的構造について説明した。通常ファイルシステムは、ファイルのディレクトリ構造や識別子を管理すると共に、ファイルの実体であるデータを保管する。しかし、本発明の仮想一元化装置３は、ファイルシステム１００を、ファイルのディレクトリ構造とファイル識別子(以後管理情報と呼ぶ)の管理にのみ使用し、ファイルの実体であるデータは各ネットワークストレージ５、６、７に格納する。このため、仮想一元化装置３はファイルシステム１００に対して容量０のダミーファイルを生成する。クライアントが仮想一元化ネットワークストレージシステム８に対して図３のようなディレクトリ構造を持つファイル郡を格納した場合、仮想一元化装置３はファイルシステム１００に図２の構造を作るが、ファイルの実体であるデータブロック１０１２、１０１３、１０１４は使用しない。
また、仮想一元化装置３はファイル識別子としてiノード番号を利用する。
なお、ディレクトリ構造とファイル識別子の管理ができれば必ずしもファイルシステム１００を使用する必要はない。ファイル識別子が全ファイルに対しいて一意であることを保証しつつ、データベースを利用して管理しても良いし、専用のテーブルを設けて権利しても良い。
(グループマップ)
グループマップ１１０は、ファイルとそのファイルが属するファイルグループとの対応を与える。具体的にはファイルの識別子であるiノード番号と、そのiノード番号で識別されるファイルの属するファイルグループの識別子を与える。グループマップ１１０の具体例として、ファイルのiノード番号Ｉを検索鍵としハッシュ値をファイルグループの識別子Ｇとするハッシュ関数
Ｇ＝Ｈａｓｈ（Ｉ）
によって与える。例えばファイルをＮ個のファイルグループに分割する場合のハッシュ関数として、ｉノード番号Ｉにファイルグループ数Ｎのモジュロ演算(Ｎで割った余り)を適用して得られた値をファイルグループの識別子とする。
【０００６】
Ｇ ＝ Ｈａｓｈ（Ｉ） ＝ Ｉ ｍｏｄ Ｎ
０〜８までの９つのファイルグループを設けた場合のグループマップのハッシュ関数は以下のようになる。
【０００７】
Ｈａｓｈ（Ｉ） ＝ Ｉ mod 9 …▲１▼
ハッシュ関数は上記のモジュロ演算の他、iノード番号Iに対して一意にファイルグループを対応付けることができれば何を使用しても良い。ただし、特定のファイルグループに属するファイルの数が他のファイルグループに属するファイルの数より極端に多くなるようなハッシュ関数を使用すると、それらのファイルグループを格納するネットワークストレージ間で容量のアンバランスが生じる。この問題を発生させないようにするには、なるべく各ファイルグループに均等にファイルがばら撒かれるような関数を選ぶべきである。
(グループ配置)
グループ配置１２０の構造を図４に示す。グループ配置は、ファイルグループと、そのファイルグループに属するファイルの格納先ネットワークストレージとを対応付ける役割を持つテーブルで、ストレージ装置内に格納される。１２０１の行は９つのファイルグループの識別番号０〜８を示しており、１２０２の行は対応する１２０１行のファイルグループのファイルの格納先ネットワークストレージの識別番号を示す。図４の例で、ファイルグループ１に属するファイルの格納先はネットワークストレージ１であり、ファイルグループ６に属するファイルの格納先はネットワークストレージ３である。仮想一元化装置３は起動時に、グループ配置の１２０２の行に、各ネットワークストレージの識別子がほぼ均等に出現するように、初期化を行なう。
グループ配置１２０は、ネットワークストレージの追加、削除、平滑化、及び、既存ネットワークストレージの取り込みの際に書き換えられる。なお、グループ配置１２０は、ファイルグループと格納先ネットワークストレージとの対応が取れ、かつ、仮想一元化装置３が何らかの障害によってダウンしてしまっても、対応関係が消失してしまわなければ、データベースを利用しても良いし、その他どんな方法であっても良い。
なお、グループ配置１２０は、ファイルアクセスの際に必ず参照するため、グループ配置がストレージ内に格納されていると、性能低下を招く。このため、ストレージ内に格納されたグループ配置１２０のコピーを高速にアクセス可能なメモリに配置しても良い。この場合、グループ配置を書き換える際は、メモリとストレージとを両方とも書き換える必要がある。
(要求処理手段)
要求処理手段１３０はクライアントからのファイルシステムのマウント要求とファイルアクセス要求を処理する。本実施例ではクライアント１と要求処理手段１３０とは、前述のＮＦＳプロトコルを用いてファイルアクセスのやり取りを行なうものとする。一元管理装置３とネットワークストレージ５、６、７の間もＮＦＳプロトコルを用いてファイルアクセスのやり取りを行う。なお、クライアント１がＣＩＦＳにのみ対応している場合、一元管理装置３の要求処理手段１３０はクライアント１とＣＩＦＳにてやり取りを行う必要がある。これを実現するため、一元管理装置３はネットワークストレージ５、６、７とはＮＦＳでやり取りを行い、クライアント１とだけＣＩＦＳでやり取りを行う。ＣＩＦＳクライアントとのやり取りは、Ｓａｍｂａなどの公知な技術を用いることで実現できる。
ＮＦＳではまずクライアントがサーバに対してマウント要求を発行して、サーバ側の共有ファイルのルートディレクトリ(マウントポイントと呼ぶ)をクライアントのファイルシステムの特定の場所にマウントする。要求処理手段１３０はクライアントからのマウント要求に対して、公知のｍｏｕｎｔｄを利用してマウント要求に答える。mountdは、仮想一元化ネットワークストレージシステム８のマウントポイントのファイルハンドル(後述)をクライアント１に返す。
ＮＦＳプロトコルに規定されたファイルやディレクトリに対するアクセス要求には、ファイルの生成を行なうＣＲＥＡＴＥ要求、ファイル名を与えてファイルハンドルを取得するＬＯＯＫＵＰ要求、ファイルを読み出すＲＥＡＤ要求、ファイルを書き込むＷＲＩＴＥ要求、ファイルの属性を設定するＳＥＴＡＴＴＲ要求、ファイルの属性を読み出すＧＥＴＡＴＴＲ要求、ファイルを削除するＲＥＭＯＶＥ要求、ファイルの名前を変更するＲＥＮＡＭＥ要求、ディレクトリを生成するＭＫＤＩＲ要求、ディレクトリを読み出すＲＥＡＤＤＩＲ要求、ディレクトリを削除するＲＭＤＩＲ要求がある。以下各要求毎に要求処理手段３の動作を説明する。
(ＣＲＥＡＴＥ要求の処理)
クライアント１はファイルを生成するディレクトリのファイルハンドルＨと、生成するファイルの名前Ｆを引数としてＣＲＥＡＴＥ要求を発行する。ファイルハンドルは、クライアント１が後に説明するＬＯＯＫＵＰ要求等を発行すると返り値として得られるファイルを識別するデータ構造である。ファイルハンドルの構成を図６に示す。ファイルハンドル１７０は親ディレクトリのiノード番号フィールド１７０１と、ファイルオブジェクトのiノード番号フィールド１７０２を含んでいる。要求処理手段１３０がクライアント１からＣＲＥＡＴＥ要求を受けると、図５の１３０１を呼び出し、要求を処理する。まず１３０２において、親ディレクトリのファイルハンドルＨのiノード番号フィールド１７０２から、ファイルを生成する親ディレクトリのiノード番号ＰＩを取り出し、このiノード番号で識別されるディレクトリにファイル名Ｆのサイズ０のダミーファイルを生成する。生成したファイルのiノード番号をIとする。次に１３０３において、生成したファイルのiノード番号Iに対して上記(ファイルマップ)の項で説明したハッシュ関数Ｈａｓｈを適用し、ファイルグループＧを求める。次に、１３０４において上記(グループ配置)の項で説明したグループ配置１２０を参照し、ファイルグループＧに対応するネットワークストレージＮを求める。求めたネットワークストレージＮがクライアント１が発行したＣＲＥＡＴＥ要求の対象ファイルの格納先ネットワークストレージとなる。そして、１３０５において、クライアント１から送られてきたＣＲＥＡＴＥ要求をネットワークストレージＮに対して発行する。最後に１３０６で、ネットワークストレージ装置ＮからＣＲＥＡＴＥ要求の応答が返ると、ファイルシステム１００上でダミーファイルを生成したディレクトリのiノード番号ＰＩと生成したダミーファイルそのもののiノード番号Iからファイルハンドルを構成して、それを要求元クライアント１に返して処理を終了する。
(ＬＯＯＫＵＰ要求の処理)
クライアント１はファイルハンドルを取得する対象ファイルオブジェクトの名前Ｆと、そのファイルオブジェクトの親ディレクトリのファイルハンドルＨを引数としてＬＯＯＫＵＰ要求を発行する。要求処理手段１３０がクライアント１からＬＯＯＫＵＰ要求を受けると、図７の１３１１を呼び出す。まず１３１２において、親ディレクトリのファイルハンドルＨの１７０２のフィールドから、この親ディレクトリのiノード番号ＰＩを取り出し、このiノード番号で識別されるディレクトリに存在する名前Ｆのファイルオブジェクトのiノード番号Iを取得する。次に、１３１３において親ディレクトリのiノード番号ＰＩとファイルのiノード番号Iからファイルハンドルを構成し、それを要求元クライアント１に返して処理を終了する。
(ＲＥＡＤ要求の処理)
クライアント１は読み出すファイルのファイルハンドルＨと、読み出すファイルの親ディレクトリのファイルハンドルＨｐを引数としてＲＥＡＤ要求を発行する。要求処理手段１３０がクライアント１からＲＥＡＤ要求を受けると、図８の１３２１を呼び出し、要求を処理する。まず１３２２において、ファイルハンドルＨのiノード番号フィールド１７０２からiノード番号Iを取得する。次に、１３２３において、iノード番号Iにハッシュ関数Ｈａｓｈを適用しファイルグループＧを求める。そして、１３２４で、グループ配置１２０を参照し、ファイルグループＧの格納先ネットワークストレージＮを求める。１３２５で、ネットストレージＮに対してＬＯＯＫＵＰ要求を発行し、ＲＥＡＤ要求がアクセス対象としたファイルハンドルＨで識別されるファイルの実体に対するネットワークストレージＮにおけるファイルハンドルＨｎを取得する。１３２６において、取得したファイルハンドルＨｎを引数としてＲＥＡＤ要求をネットワークストレージＮに発行する。１３２７において、ネットワークストレージＮがＲＥＡＤ要求の返り値である読み出し結果を返すと、得られた読み出し結果を要求元クライアント１に返す。
クライアントがＷＲＩＴＥ要求を発行した場合もＲＥＡＤ要求の処理とほぼ同じである。１３２６においてＲＥＡＤ要求を格納先ネットワークストレージＮに対して発行する代わりに、ＷＲＩＴＥ要求を格納先ネットワークストレージＮに発行すれば良い。ＲＥＮＡＭＥ要求とＲＥＭＯＶＥ要求も同様である。
(ＭＫＤＩＲ要求の処理)
クライアント１は生成するディレクトリの名前Ｄと、生成する親ディレクトリのファイルハンドルＨを引数としてＭＫＤＩＲ要求を発行する。要求処理手段１３０がクライアント１からＭＫＤＩＲ要求を受けると、図９の１３３１を呼び出し、要求を処理する。まず１３３２において、ファイルシステム１００にファイルハンドルＨのiノード番号フィールド１７０２に格納されているiノード番号によって識別されるディレクトリに、名前Ｄのディレクトリを生成する。生成したディレクトリのiノード番号をIとする。そして、１３３３にて、ネットワークストレージのそれぞれにＭＫＤＩＲ要求を発行して名前Ｄのディレクトリを生成する。そして１３３４にてファイルハンドルＨのiノード番号フィールド１７０２の値と生成したディレクトリのiノード番号Iとからファイルハンドルを生成し、それを要求元クライアント１に返す。ＲＭＤＩＲ要求の処理も同様であり、ＭＫＤＩＲ要求をすべてＲＭＤＩＲ要求に変更すれば良い。
ＧＥＴＡＴＴＲ要求とＳＥＴＡＴＴ要求は、アクセス対象ファイルオブジェクトがディレクトリの場合、ＭＫＤＩＲ要求の処理の場合と同様に各ネットワークストレージに対してＧＥＴＡＴＴＲ要求またはＳＥＴＡＴＴＲ要求を発行してディレクトリ属性の設定を行なえば良い。アクセス対象ファイルオブジェクトがファイルの場合、ＲＥＡＤ要求の処理と同様に、アクセス対象ファイルの格納先ネットワークストレージにＧＥＴＡＴＴＲ要求または、ＳＥＴＡＴＴＲ要求を発行すれば良い。
ＲＥＡＤＤＩＲ要求の処理はＬＯＯＫＵＰ要求の処理と同様で、ファイルシステム１００に対して対象ディレクトリの情報を読み出しそれをクライアントに返せば良い。
以上、要求処理手段１３０の処理の詳細について説明した。ここでは例題として、クライアント１が図３のような構造を持つディレクトリとファイルを生成しそれにアクセスする場合を示す。まず、仮想一元化ネットワークストレージシステム８にディレクトリやファイルがまったく存在しないと仮定する。ファイルグループは０〜８までの９つを設ける。また、グループマップとして以下のハッシュ関数
Ｈａｓｈ（Ｉ） ＝ Ｉ／９
を用いる。
クライアント１はまずマウント要求を仮想一元化装置３に発行し、仮想一元化装置３の要求処理手段１３０はマウントポイントのファイルハンドルを返す。次にクライアント１はそのマウントポイントのファイルハンドルと生成するディレクトリの名前ｄ１を引数としてＭＫＤＩＲ要求を発行する。仮想一元化装置３の要求処理手段１３０はファイルシステム１００及び各ネットワークストレージ５、６、７にディレクトリを生成する。次にクライアントは生成したｄ１のファイルハンドルとディレクトリ名ｄ２を引数にＭＫＤＩＲ要求を発行すると、仮想一元化装置３の要求処理手段１３０はファイルシステム１００と各ネットワークストレージ５、６、７にディレクトリｄ２を生成する。次にクライアントはディレクトリｄ２のファイルハンドルと
ファイル名ｆ１を引数としてＣＲＥＡＴＥ要求を発行する。すると仮想一元化装置３の要求処理手段１３０はまずファイルシステム１００のディレクトリｄ２において名前ｆ１を持つサイズ０のダミーファイルを生成する。生成したディレクトリやファイルのiノードとディレクトリエントリの構造は図２のようになっているものと仮定する(この図には生成前のディレクトリｄ３とファイルｆ２、ｆ３に相当するiノードやディレクトリエントリが含まれている)。ファイルｆ１に相当するiノードは１００５でありそのiノード番号は１０番である。そこで要求処理手段１３０はiノード番号１０に前述のハッシュ関数▲１▼を適用してファイルｆ１の属するファイルグループが１番であることが分かる。次にグループ配置１２０のファイルグループ１番の列を参照すると、そのファイルの格納先ネットワークストレージが１番(図１の５)であることが分かる。従って要求処理手段１３０はネットワークストレージ５にＣＲＥＡＴＥ要求を発行して、ファイルｆ１の実体をディレクトリｄ２の下に生成する。同様にクライアント１がファイルｆ２のＣＲＥＡＴＥ要求を発行すると、ファイルシステム１００において名前ｆ２を持つダミーのファイルが生成する。生成したダミーファイルのiノードが図２の１００６でありそのiノード番号が１４であるので、要求処理手段１３０はこれに前述のハッシュ関数▲１▼を適用して、このダミーファイルの属するファイルグループが５番であることが分かる。次にグループ配置１２０を参照して格納先ネットワークストレージが２番(図１の６)であることが分かるので、ネットワークストレージ６にＣＲＥＡＴＥ要求を発行してディレクトリｄ２の下にファイルｆ２の実体を生成する。同様にしてディレクトリｄ３をｄ１の下に生成し、ディレクトリｄ３の下にファイルｆ３を生成すると、ファイルシステム１００の構造は図２となり、各ファイルｆ１、ｆ２、ｆ３の配置は図１の５、６、７のストレージ１１に記載の通りとなる。次にクライアント１がファイルｆ３のＲＥＡＤ要求を発行する場合を考える。クライアント１はまずマウントポイントのファイルハンドルとディレクトリ名ｄ１を引数としてＬＯＯＫＵＰ要求を発行し、要求処理手段１３０はディレクトリｄ１のファイルハンドルをクライアント１に返す。次に、クライアントはディレクトリｄ１のファイルハンドルとディレクトリ名ｄ３を引数としてＬＯＯＫＵＰ要求を発行し、要求処理手段１３０はディレクトリｄ３のファイルハンドルをクライアント１に返す。次に、クライアント１はディレクトリｄ３のファイルハンドルとファイル名ｆ３を指定してＬＯＯＫＵＰ要求を発行すると、要求処理手段１３０はファイルｆ３のファイルハンドル(ファイルシステム１００におけるファイルｆ１のダミーファイルのiノード番号とその親ディレクトリのiノード番号から構成される)をクライアントに返す。そこでクライアント１はディレクトリｄ３のファイルハンドルと、ファイルｆ３のファイルハンドルを引数としてＲＥＡＤ要求を発行する。要求処理手段１３０はそれに対して、ファイルｆ３のファイルハンドルからファイルｆ３に相当するダミーファイルのiノード番号を取り出す。iノード番号は１６番であるから、それにハッシュ関数▲１▼を提供してファイルグループ７を得る。グループ配置１２０を参照するとファイルグループ７の格納先ネットワークストレージは３(図１の７)であるから、要求処理手段１３０はネットワークストレージ３にＲＥＡＤ要求を発行してファイルｆ３を読み出す。要求処理手段１３０はネットワークストレージ３から読み出したデータが返ると、それを要求元クライアント１に返す。以上のように、クライアントは単に通常のネットワークストレージへアクセスするように要求を発行すると、仮想一元化装置１３０がアクセス対象ファイルの格納先ネットワークストレージを求め、そのネットワークストレージにファイルアクセス処理を送ってファイルアクセスを行なう。このためクライアントからは仮想一元化ネットワークストレージシステム８があたかも一つのネットワークストレージとして見える。
(容量監視手段)
容量監視手段は定期的に各ネットワークストレージの残容量を求めてそれを図１０の容量テーブル１５００に書き込むと共に、いずれかのネットワークストレージの残容量が定められた値を下回った場合に、後述の移動手段を起動してファイルの移動を行ったり、あるいは、管理者に対して新しいネットワークストレージの追加を催促するメッセージを送ったりする。
容量テーブル１５００は各ネットワークストレージの残容量に関する最新の情報を記録するテーブルである。１５０１の行は各ネットワークストレージの識別子を示す。１５０２の行は、各ネットワークストレージの最大容量(ファイルを一つも格納しない場合の使用可能容量)を記録する。１５０３の行は、各ネットワークストレージの現在の残容量を示す。例えば図１０の例では、容量の単位をＧＢと定めると、ネットワークストレージ１、２、３の最大容量は共に２０ＧＢであり、残容量はそれぞれ１２ＧＢ，８ＧＢ，１４ＧＢである。１５０３の行は残容量に替えて使用容量を記録しても良い。図１１に容量監視手段の容量監視処理のフローを示す。仮想一元化装置３の起動時に１５１１を実行する新しいスレッドまたはプロセスを生成し、要求処理手段１３０によるファイルアクセス処理と並列に各ネットワークストレージの容量を監視する。
まず１５１２でフラグＦｏｖｅｒを０に初期化する。Ｆｏｖｅｒは後述する移動手段による平滑化処理の開始を指示するフラグである。次に１５１３で各ネットワークストレージの残容量を取得し、得られた値を容量テーブル１５００の１５０３の行に書き込む。残容量の計測は、各ネットワークストレージにＳＴＡＴＦＳプロシージャを発行して取得しても良いし、その他ネットワーク経由で各ネットワークストレージの残容量を取得できればどんな方法を用いても良い。次に、１５１４において、１５１３で取得した各ネットワークストレージの残容量が予め定められた閾値Ｔを下回るか調べ、下回る場合は１５１５以降を実行する。閾値Ｔは０以上かつネットワークストレージの最大容量よりも小さな値を指定する。例えば、容量が１００ＧＢのネットワークストレージの場合、１ＧＢ〜１０ＧＢが妥当と考えられるが、それ以外の値でも良い。１５１５では残容量が閾値Ｔを下回ったネットワークストレージＮを移動元ネットワークストレージＮｓに設定し、１５１６でＦｏｖｅｒフラグに１を設定する。移動手段１４０はこのフラグを常時監視しており、値が１に設定されると後述の平滑化処理を起動し、移動元に設定されたネットワークストレージＮのファイルグループの幾つかを他のネットワークストレージに移動し各ネットワークストレージ間の残容量の平滑化を計る。その後１５１７において一定時間スリープし、１５１３の処理へ戻る。一方、１５１４において全ての残容量が閾値Ｔを下回らなかった場合は、１５１７で一定時間スリープし、１５１３の処理へ戻る。１５１７でスリープする時間は、１秒程度を最小とし、１分出会っても良いし、１時間であっても良いし、１日であっても良いし、その他なんでも良い。スリープ時間が短いほど、容量の急激な増加に対して正確に状況を把握できるようになるが、逆に容量の監視処理自身が頻繁に動くため、仮想一元化装置の処理が重くなる。従って、容量の増減の度合いによって、適切なスリープ時間を設定する。
なお、１５１４の条件は、ネットワークストレージの最大残容量と最小残容量の差が予め定められた閾値Ｔｄより大きいかどうかという条件にしても良い。このとき、閾値Ｔｄは０からネットワークストレージの容量までの値を指定する。例えば、ネットワークストレージの容量が１００ＧＢであれば、１ＧＢ〜１０ＧＢが妥当な値であるが、それ以外でも良い。上記のように１５１４の条件を変更した場合は、このとき１５１５の処理を残容量の最も小さなネットワークストレージを移動元ネットワークストレージに設定するよう変更する。
さらに、１５１４の条件を全てのネットワークストレージの総残容量が予め定められた閾値Ｔｔを下回るかどうかという条件に変更し、１５１５を廃止して、１５１６で管理者に対して残容量が残り少なく新たにネットワークストレージを追加することを催促するメッセージを送るように変更しても良い。メッセージを送る手段は、sendmailのような公知の技術を使用して管理者にメールを送信しても良いし、管理手段１８０を介して管理者のインタフェースにメッセージを出しても良い。
(移動手段)
移動手段１４０は、ネットワークストレージを追加したり削除して、仮想一元化ネットワークストレージシステム８の構成を変更する場合に、構成変更の対象となるネットワークストレージに格納されているファイルの移動を行なう。これによって、仮想一元化ネットワークストレージシステムの構成変更が柔軟に行なえる。また、移動手段１４０は各ネットワークストレージの残容量に規定以上のばらつきが生じた場合に、ファイルをネットワークストレージ間で移動し、残容量の平滑化を図る。ファイルを移動しないと、いづれかのネットワークストレージが一杯になった段階で、他のネットワークストレージに空きがあっても、一切ファイルの書き込みができなくなる。これに対して、上記のようにファイルを移動することによって、ほぼ全てのネットワークストレージの容量を使い切るまで使用できるようになる。
移動手段１４０には、基本移動機能、ネットストレージ追加時の移動機能、ネットストレージ削除時の移動機能、平滑化機能の四つの機能がある。各機能に対応して、それぞれ移動処理、追加処理、削除処理、平滑化処理がある。それぞれの処理の詳細を以下に示す。
(移動処理)
移動処理は、ファイルをファイルグループ単位で現在格納されているネットワークストレージから別のネットワークストレージに移動する。図１２に移動処理のフローを示す。移動対象ファイルグループＧｍと、移動先ネットワークストレージＮｄを設定して移動処理１４０１を呼び出すと、移動手段１４０はファイルグループＧｍを現在格納されているネットワークストレージから、移動先ネットワークストレージＮｄに移動する。移動処理はまず１４０２でグループ配置１２０を参照し、移動対象グループＧｍのファイルが現在格納されているネットワークストレージＮｓを求める。次に、ファイルシステム１００のファイルをルートディレクトリ／から一つずつ探索し、ファイルグループＧｍに属するファイルを特定する。このためまず１４０３でファイルシステム１００に探索すべきファイルＦが存在するか調べ、存在する場合は１４０４でファイルＦのiノード番号Ｉを求める。１４０５でファイルＦのiノード番号Ｉにハッシュ関数Ｈａｓｈを適用してファイルＦの属するファイルグループを求め、それが移動対象ファイルグループＧｍと一致する場合は、１４０６でファイルＦを移動元ネットワークストレージ装置Ｎｓから移動先ネットワークストレージＮｄに移動する。移動は、移動手段１４０が、移動元ネットワークストレージＮｓにファイルＦのＲＥＡＤ要求を発行してファイルを読み出し、読み出した内容をそのまま引数としたＷＲＩＴＥ要求を移動先ネットワークストレージＮｄに発行してファイルを書き込み、最後に移動元ネットワークストレージのファイルＦを削除する。あるいは、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用してファイルを移動元から移動先にコピーした後、移動元のファイルを削除しても良い。その他、ファイルを移動元ネットワークストレージから移動先ネットワークストレージに移動できればどんな方法を用いても良い。移動が終わると１４０３に戻って処理を続ける。１４０３で探索すべきファイルが存在しない場合は、移動対象ファイルグループＧｍに属する全てのファイルを移動し終えているので、１４０７でグループ配置１２０のファイルグループＧｍの欄に移動先ネットワークストレージＮｄを書き込み、処理を終了する。
本移動処理は、本発明の仮想一元化ネットワークストレージシステム８の管理者がユーザインタフェース経由で管理手段１８０に対し、移動対象ファイルグループＧｍと移動先ネットワークストレージＮｄを指定し移動の指示を与えたときに呼び出されるか、あるいは、追加処理、削除処理、平滑化処理の処理過程において呼び出される。
移動処理後に、移動処理によって格納先ネットワークストレージが変更されたファイルＦに対し、クライアント１からファイルアクセス要求があった場合、要求処理手段１３０は移動手段１４０が１４０７で変更した後のグループ配置１２０を参照して、格納先ネットワークストレージを決定する。このため、ファイルＦの格納先ネットワークストレージが変更されても、クライアント１は正しくファイルＦにアクセスできる。
なお、移動手段１４０がファイルグループＧｍを移動している最中に、クライアント１がファイルグループＧｍに属するファイルへアクセス要求を発行した場合、要求処理手段１３０は、ファイルグループＧｍの移動が終了するまで、クライアントからのファイルアクセス要求を実行しない。
(追加処理)
本発明の仮想一元化装置３は仮想一元化ネットワークストレージシステム８の容量が不足したとき、新しくネットワークストレージ装置を追加することで、容量を増大することができる。
仮想一元化ネットワークストレージシステム８の管理者は、追加するネットワークストレージをネットワーク４に接続し、ユーザインタフェースを介して管理手段１８０にアクセスし、追加処理の開始を指示する。すると管理手段１８０は、移動手段１４０の追加処理(図１３の１４１１)を呼び出す。
追加処理は、仮想一元化ネットワークストレージシステム８にネットワークストレージを追加した場合に、既存のネットワークストレージを格納先とするファイルグループの幾つかを追加したネットワークストレージに移動し、これによって追加したネットワークストレージを仮想一元化ネットワークストレージシステムに取り込む。処理の詳細フローを図１３に示す。まず、１４１２で追加するネットワークストレージを移動先ネットワークストレージＮｄに設定する。次に１４１３において、容量テーブル１５００の１５０３の行を参照し、ストレージの残容量が最も小さなネットワークストレージを移動元ネットワークストレージＮｓとする。そして１４１４で、グループ配置１２０を参照し、移動元ネットワークストレージＮｓを格納先とするファイルグループを求め、その中からランダムに一つファイルグループを選択し、それを移動対象ファイルグループＧｍに設定する。そして、前述の図１２の移動処理１４０１を呼び出し、移動対象ファイルグループＧｍを移動元ネットワークストレージＮｓから追加したネットワークストレージである移動先ネットワークストレージＮｄに移動する。移動が終了すると、１４１６において、容量テーブル１５００を参照し、移動先ネットワークストレージＮｄの残容量ともっとも少ない残容量を求め、その差が予め定められた閾値Ｔｃを超えれば１４１３に戻って処理を続け、そうでなければ処理を終了する。閾値Ｔｃは、１００ＭＢ、５００ＭＢ、あるいは、１ＧＢなど、なんでも良い。ネットワークストレージ追加時の移動処理にかかる時間を短縮するには、閾値に大きな値を設定する。時間がかかっても各ネットワークストレージ間の残容量の格差を小さくしたい場合は閾値に小さな値を設定する。
なお、１４１３において移動元ネットワークストレージを選択する方法は、ランダムに選択しても良いし、予め定められた順に選択しても良いし、どんな方法を用いても良い。また、１４１４においてファイルグループＧｍを選択する方法は、予め定められた順に選択しても良いし、その他どんな方法を用いても良い。また、１４１６において残容量により終了判定するのではなく、移動したファイルグループの数が予め定めておいた値を超えたら終了するという条件にしても良い。
追加処理の終了後、クライアント１がファイルアクセス要求を発行し、そのアクセス要求の対象が、上記追加処理によって追加ネットワークストレージに移動したファイルグループに属するファイルである場合、要求処理手段１３０はクライアント１からのアクセス要求を追加しネットワークストレージに送り、追加ストレージにてファイルアクセス処理を行う。このように、クライアント１から見ると、仮想一元化ネットワークストレージシステムにネットワークストレージを追加しても、ファイルアクセスの手順は追加前と変わらない。クライアント１から見た場合の唯一の違いは、仮想一元化ネットワークストレージシステムの容量が追加したネットワークストレージの容量分だけ増えたように見えることである。(削除処理)
本実施例の仮想一元化装置３は仮想一元化ネットワークストレージシステム８の容量があまっていて利用しないなどの理由で、システム内のネットワークストレージを取り除き、容量を小さくすることができる。ただし、ネットワークストレージを削除することができるのは、システム全体の空き容量が削除するネットワークストレージの容量より多く存在する場合に限られる。
仮想一元化ネットワークストレージシステム８の管理者は、ユーザインタフェースを介して管理手段１８０にアクセスし、削除するネットワークストレージを指定して削除処理の開始を指示する。すると管理手段１８０は、移動手段１４０の削除処理(図１４の１４２１)を呼び出す。
削除処理は、仮想一元化ネットワークストレージシステム８内のネットワークストレージ５，６，７のいづれかを削除する場合に、削除するネットワークストレージを格納先とする全てのファイルグループをその他のネットワークストレージに移動し、削除するネットワークストレージを仮想一元化ネットワークストレージシステムから論理的に切り離す。処理の詳細フローを図１４に示す。まず、１４２２で削除するネットワークストレージを移動元ネットワークストレージＮｓに設定する。次に１４２３で、容量テーブル１５００の１５０３の行を参照し、ストレージの残容量が最も大きなネットワークストレージを移動先ネットワークストレージＮｄとする。そして１４２４で、グループ配置１２０を参照し、移動元ネットワークストレージＮｓを格納先とするファイルグループを求め、その中からランダムに一つファイルグループを選択し、それを移動対象ファイルグループＧｍに設定する。そして、前述の図１２の移動処理１４０１を呼び出し、移動対象ファイルグループＧｍを削除するネットワークストレージである移動元ネットワークストレージＮｓから移動先ネットワークストレージＮｄに移動する。移動が終了すると、１４２６で、移動元ネットワークストレージＮｓにファイルグループが存在すれば１４２３に戻って処理を続け、そうでなければ処理を終了する。
１４２３の移動先ネットワークストレージの選択方法は、ネットワークストレージの残容量が移動するファイルグループの容量よりも大きければ、ランダムに選択しても良いし、予め順番を決めてその順に選択しても良い。また、１４２４においてファイルグループＧｍの選択方法は、予め定められた順番に選択しても良いし、その他どんな方法で選択しても良い。
上記削除処理が終了すると、管理手段１８０はインタフェースを介して管理者に削除の終了を報告する。この報告を受けて管理者は論理的に切り離されたネットワークストレージをネットワーク４から物理的に切り離す。
削除処理の終了後、クライアント１がファイルアクセス要求を発行し、そのアクセス要求の対象が、削除前に削除したネットワークストレージを格納先とするファイルグループに属するファイルであった場合、要求処理手段１３０はクライアント１からのアクセス要求を削除したネットワークストレージではなく、移動先ネットワークストレージに送り、ファイルアクセス処理を行う。このように、クライアント１から見ると、仮想一元化ネットワークストレージシステムからネットワークストレージを削除しても、ファイルアクセスの手順は削除前と変わらない。クライアント１から見た場合の唯一の違いは、仮想一元化ネットワークストレージシステムの容量が削除したネットワークストレージの容量分だけ減ったように見えることである。
(平滑化処理)
クライアント１が仮想一元化ネットワークストレージシステム８に対してファイルの書き込み要求を発行し、書き込み対象ファイルの格納先ネットワークストレージに空きがない(残容量が０)場合、他のネットアークストレージに大量の空きがあっても、そのファイルの書き込みはできない。このような状況に対処するため、仮想一元化装置３は、ネットワークストレージの残容量が少なくなったり、ネットワークストレージ間の残容量の格差が広がると、平滑化処理を起動して、各ネットワークストレージの残容量が均等になるようにファイルグループの移動を行う。平滑化処理は、仮想一元化装置３の起動時に移動手段１４０が独立したスレッドまたはプロセスとして平滑化処理(図１５の１４３１)を起動する。平滑化処理の詳細を図１５に示す。平滑化処理はバックグラウンドで動いているが、１４３２でＦｏｖｅｒというフラグが０である間は処理を行わない。このフラグは、前述の(容量監視手段)のところで述べたように、ネットワークストレージの残容量が定められた閾値を下回った場合、そのネットワークストレージを移動元ネットワークストレージＮｓとしＦｏｖｅｒを１に設定する。あるいは、ネットワークストレージの最大残容量と最小算容量の差が閾値を超えた場合に、残容量の最も小さなネットワークストレージを移動元ネットワークストレージに設定し、Ｆｏｖｅｒを１に設定する。Ｆｏｖｅｒが１に設定されると、平準化処理は１４３３で移動元ネットワークストレージＮｓを格納先とするファイルグループのうちの一つをランダムに選択して移動対象ファイルグループＧｍとし、１４３４で残容量が最大のネットワークストレージを移動先ネットワークストレージＮｄとし、１４３５で１４０１の移動処理を呼び出しファイルグループＧｍを移動元ネットワークストレージＮｓから移動先ネットワークストレージＮｄに移動する。１４３６で、ネットワークストレージの最大残容量と最小残容量の差が前述の追加処理で説明した閾値Ｔｃの値より大きければ、１４３３に戻って処理を続け、小さくなれば１４３７でＦｏｖｅｒフラグを０に設定して、１４３２に戻る。なお、１４３３においてＮｓからＧｍを選択する方法は、予め定められた順番に選択する方法であっても良いし、その他どのような方法であっても良い。また、１４３４において、Ｎｄに設定するネットワークストレージは、移動元ネットワークストレージＮｓ以外のネットワークストレージを選択できれば、どのような方法を用いても良い。
上記の処理によって、ネットワークストレージ間の残容量の差が小さくなり、特定のネットワークストレージの容量不足によってファイルの書き込みができなくなるという問題を解決することができる。
以上自動的に平滑化処理を起動する場合について説明したが、管理者がユーザインタフェースを介して管理手段１８０にアクセスし、平滑化処理の実行を指示しても良い。このとき、管理者は移動元ネットワークストレージを引数として与える。移動手段１４０は図１５の１４３３を呼び出して平滑化の処理を行い。１４３６で条件が満足されなくなると処理を終了する。なお、管理手段１８０はユーザインタフェースを介して、容量テーブル１５００の情報を管理者にリアルタイムに提供し、管理者が平滑化処理や追加処理や削除処理を行うべきかどうか判断する手助けにすることが望ましい。
(統合手段)
本発明の仮想一元化ネットワークストレージシステム８でない、一般的なネットワークストレージを用いているサイトにおいて、ネットワークストレージの容量が不足すると、新規に既存ネットワークストレージを購入するのが一般的である。しかしこの場合、クライアントからは、既設ネットワークストレージと追加ネットワークストレージが独立して見えるため、使い勝手が悪い。このような場合に対処するため、本発明の仮想一元化手段３は統合化手段１８０によって、既設ネットワークストレージを取り込んで仮想一元化ネットワークストレージシステムを構成し、既設ネットワークストレージのファイルを含みかつより容量の大きな仮想一元化ネットワークストレージを提供する。
図１のネットワーク２に既設ネットワークストレージが接続されており、クライアント１のファイルが既設ネットワークに格納されているものとする。管理者はネットワーク２に仮想一元化ネットワークシステム８を接続し、ユーザインタフェースを介して仮想一元化装置３の管理手段１８０にアクセスし、統合する既設ネットワークストレージを指定して統合の開始を指示する。すると、仮想一元化装置３の統合手段１６０は図１６の１６０１を呼び出し、統合処理を開始する。統合処理はまず１６０２でグループ配置１２０の各ファイルグループに対応したネットワークストレージの欄に、既設ネットワークストレージ又は追加したネットワークストレージの中の一つをそれぞれ書き込む。例えば、ファイルグループが１〜４の４つあり、ネットワークストレージが既設と追加の２つである場合、ファイルグループ１と２に既設ネットワークストレージを、ファイルグループ３と４に追加ネットワークストレージをそれぞれ対応付ける。あるいは、全てのファイルグループに既設ネットワークストレージを割り当てても良いし、その他どのような割当にしても良い。このグループ配置１２０へのネットワークストレージの書き込み方によって、既設ネットワークストレージを仮想一元化ネットワークストレージシステム８に統合し運用を開始した直後における、ファイルグループの格納先ネットワークストレージが決定される。次に１６０３で、図１７の１６６１を呼び出す。そして、まず１６６２で、既設ネットワークストレージに未探索のファイルオブジェクトＦが存在するか調べ、存在する場合は１６１３でファイルオブジェクトＦがディレクトリかどうか調べ、ディレクトリなら１６１４で仮想一元化装置３のファイルシステム１００にディレクトリＦを生成して１６１２に戻って処理を継続する。１６１３で一方ファイルオブジェクトＦがディレクトリでなくファイルである場合は、１６１５でファイルＦと同じ名前と属性を持ちサイズ０のダミーファイルをファイルシステム１００に生成し、１６１２に戻って処理を継続する。１６１２で未探索のファイルオブジェクトが存在しなければ、図１６の１６０３の処理は終了する。次に、１６０４において図１８の１６２１を呼び出す。すると１６２２でファイルシステム１００に未探索のファイルＦが存在するかどうか調べ、存在する場合は１６２３でファイルＦのiノード番号Iを求める。１６２４でファイルＦの属するファイルグループＧを、iノード番号Ｉにグループマップ１１０で与えられたハッシュ関数Ｈａｓｈを適用して求める。１６２５で、グループ配置１２０を参照しファイルグループＧの格納先ネットワークストレージＮを求める。この格納先ネットワークストレージは図１６の１６０２で設定したものである。統合中の現時点において、全てのファイルグループは既設ネットワークストレージに格納されているから、１６２５で求めたファイルグループＧの格納先ネットワークストレージＮが既設ネットワークストレージでである場合には（１６２６）グループ配置の設定と現状とが一致するので何もしなくて良く、１６２２に戻って処理を続ける。もし、１６２６でＮが既設ネットワークストレージでない場合には、１６２７において、ファイルＦを既設ネットワークストレージからネットワークストレージＮに移動する。移動の方法は、既設ネットワークストレージにＲＥＡＤ要求を発行してファイルＦを読み出し、ネットワークストレージＮに読み出したデータを引数としてＷＲＩＴＥ要求を発行してファイルＦを書き込み、最後に既設ネットワークストレージのファイルＦを削除すればよい。移動が終了すると１６２２に戻って処理を続ける。１６２２において、未探索のファイルが存在しなくなると図１６の１６０４の処理が終了し、統合処理全体も終了する。
なお、統合手段１６０による統合処理の実行中は、要求処理手段によるファイルアクセス処理や移動手段による追加・削除・平滑化処理を停止する。
統合処理が終了したあと、クライアント１が既設ネットワークストレージの代わりに仮想一元化装置３に対してファイルアクセスコマンドを発行すると、仮想一元化装置３はアクセス対象ファイルＦの格納先ネットワークストレージに対しアクセス要求を発行してファイルアクセスを行うため、クライアントにとっては既設ネットワークストレージにアクセスするのと、既設ネットワークストレージを統合化した仮想一元化ネットワークストレージシステムにアクセスする場合とで違いは無く、ただ後者の方が容量が多いように見える。
以上、仮想一元化装置３の各構成要素について説明した。これらの各構成要素を搭載した仮想一元化装置の実装例を図１９に示す。ＣＰＵ２０、コントローラ２１、メモリ２２、Ｉ／Ｏインタフェース２３、ネットワークインタフェース２４、ディスク装置２５から構成されるサーバ、ワークステーション、あるいはＰＣをハードウェアとして、前述のＵＮＩＸ系オペレーティングシステム、例えばＬｉｎｕｘを搭載し、ファイルシステム１００、グループマップ１１０、グループ配置１２０はそれぞれデータとしてディスク装置２５に格納し、要求処理手段１３０、移動手段１４０、容量監視手段１５０、統合手段１６０、管理手段１８０はそれぞれプログラムコードとしてメモリ２２に配置し、ＣＰＵ２０がそれらを実行することで仮想一元化装置として機能する。
＜実施例２＞
図２０は本発明の第２の実施例を含む情報システムの全体構成を示す図である。本実施例は図１の実施例１の変形であるから、実施例１との相違部分についてのみ説明する。１４は図１の仮想一元化ネットワークストレージシステム８と同等の機能を持つ仮想一元化ネットワークストレージシステムである。１４のネットワーク４と一つ以上のネットワークストレージ６、７は図１の８の仮想一元化ネットワークストレージシステムと同じであり、異なるのは１２の仮想一元化装置である。本実施例の仮想一元化装置１２は、ファイルシステム１００、グループマップ１１０、グループ配置１２０、要求処理手段１３０、移動手段１４０、容量監視手段１５０、統合手段１６０、管理手段１８０は実施例１の仮想一元化装置３と同一であり、ネットワークストレージ５、６、７の同一のリモート制御手段１０とファイルシステムを構築したストレージ装置１１を持ち、ネットワークストレージとしても機能するネットワークストレージ機能付き仮想一元化装置である点が異なる。８の仮想一元化装置はそれ単独では仮想一元化ネットワークストレージシステムを構成することはできず、他に必ずネットワークストレージを接続する必要があるが、本実施例のネットワークストレージ機能付き仮想一元化装置の場合は、それ単体で仮想一元化ネットワークストレージシステムを構成することが可能であり、より安価に仮想一元化ネットワークストレージシステムを提供できる。一方、実施例２はネットワークストレージを含むため、仮想一元化装置１２が管理データの他にファイルの実体のアクセス処理も行う必要があり、したがってＣＰＵ２０の負荷が高くなり易い。すなわち、実施例１の方がより高い性能を出すことができるという点で優れている。
本実施例の場合グループ配置１２０にはネットワークストレージ装置としても機能する仮想一元化装置１２も特定のファイルグループの格納先として登録する。クライアント１がファイルアクセス要求を発行すると、要求処理手段１３０がそれを受け、アクセス対象ファイルの格納先ネットワークストレージを求め、求めた格納先ネットワークストレージ装置にファイルアクセス要求を発行してファイルアクセスを行う一連の処理は実施例１と同じである。ただし本実施例の仮想一元化装置はネットワークストレージとしても機能し、格納先ネットワークストレージが一元管理装置１２であった場合、要求手段１３０は自身のリモート制御手段１０に対してファイルアクセス要求を発行し、リモートアクセス手段１０は要求処理手段１３０からの要求を受けてストレージ装置１１に対してファイルアクセス処理を行う。
なお、本実施例２のネットワークストレージ機能付き仮想一元化装置１２のストレージ装置１１を２つのパーティションに分割し、その一方にファイルシステム１００を搭載して管理用のファイルシステムとして用い、もう一方のパーティションにもファイルシステムを搭載してファイルの実体を格納するために用いても良い。
＜実施例３＞
図２１は本発明の第３の実施例を含む情報システムの全体構成を示す図である。本実施例は図１の実施例１の変形であるから、実施例１との相違部分についてのみ説明する。まず図１では仮想一元化装置３の内部に存在した要求処理手段１３０に少し手を加えて、仮想一元化装置１３と分離する。この要求処理手段１３１は、サーバ、ワークステーション、ＰＣ等の公知のハードウェア上にＬｉｎｕｘ等の既存オペレーティングシステムを搭載し、そこに要求処理手段１３１を搭載することで実装する。１３１はクライアント１とＮＦＳプロトコルを用いてファイルアクセス処理を行う。クライアント１は複数ある要求処理手段１３１の何れかにファイルアクセス要求を発行する。要求処理手段１３１は自身の中にファイルシステム１００等の管理情報を持たず、クライアント１がファイルアクセス要求を発行すると、ネットワーク２を介して一元管理装置１３の要求処理手段１３２にアクセスしてアクセス対象ファイルの格納先ネットワークストレージを求める。そして求めた格納先ネットワークストレージにファイルアクセス要求を発行してファイルアクセスを行う。ファイルアクセス要求が終了すると要求処理装置１３１はネットワークストレージから得られたファイルアクセス要求の結果を要求元クライアント１に返す。ＮＦＳの各プロシージャの処理に関しては、自身のファイルシステム、グループマップ、及び、グループ配置にアクセスする代わりに、上記のようにネットワーク経由で仮想一元化装置３の要求処理手段１３２にアクセスし、ファイルシステム１００、グループマップ１１０、グループ配置１２０にアクセスして所望のデータを取得すること意外実施例１で説明した処理と同様である。一元管理装置１３の要求処理手段１３２は要求処理手段１３１からの管理情報へのアクセス要求を受け、ファイルシステム１００、グループマップ１１０、グループ配置１２０の参照や更新作業を行う。その他、仮想一元化装置１３における各種の手段の処理は実施例１と同じである。
本実施例３はクライアント１からファイルアクセス要求を受ける要求処理手段１３１を、仮想一元化装置１３と独立させ、かつ、複数設けることによって、実施例１と比べてより多くのクライアントからのリクエストに答えられるようになる。すなわち高い性能が要求される環境での使用は本実施例の形態をとると良い。なお、要求処理手段を複数持たせると、クライアント１から本発明の仮想一元化ネットワークストレージシステムに複数のエントリポイントがあるように見える。そこで、複数の要求手段１３１の前段に負荷分散装置等の公知な技術を導入してエントリポイントを一元化しても良い。
【０００８】
【発明の効果】
本発明のネットワークストレージシステムの仮想一元化方法及び装置はファイルの格納先ネットワークストレージをファイルグループを単位として管理する。ファイルからそのファイルが属するファイルグループを求めるファイルマップを固定的に与えておいて、ファイルグループとその格納先ネットワークストレージとの対応をグループ配置として管理し、ネットワークストレージの追加や削除等の構成変更があった場合には、このグループマップを変更する。このようなファイルグループを単位とした管理方法により、ファイル毎に格納先ネットワークストレージの情報を持つ従来の方法と比べて管理情報が少なくなり、ネットワークストレージの容量を有効に利用できるようになる。
また、仮想一元化ネットワークストレージシステムの構成変更時には、ファイルグループを単位としてファイルの格納先ネットワークストレージを移動する。この際に、グループ配置の移動するファイルグループの格納先ネットワークストレージを変更するだけで良いので、ファイル毎に格納先情報を管理する場合に比べてオーバヘッドを小さくできる。
【図面の簡単な説明】
【図１】本発明のネットワークストレージ装置の仮想一元化方法の構成を示す図である。
【図２】ファイルシステムの構造を示す図である。
【図３】ファイルシステムの構造を説明するために使用するディレクトリ構造の例題を示す図である。
【図４】グループ配置の構成を示す図である。
【図５】ＣＲＥＡＴＥ要求に対する処理の流れを示すフローチャートである。
【図６】ファイルハンドラの構成を示す図である。
【図７】ＬＯＯＫＵＰ要求に対する処理の流れを示すフローチャートである。
【図８】ＲＥＡＤ要求に対する処理の流れを示すフローチャートである。
【図９】ＭＫＤＩＲ要求に対する処理の流れを示すフローチャートである。
【図１０】容量テーブルの構成を示す図である。
【図１１】容量の監視処理の流れを示すフローチャートである。
【図１２】ファイルグループをネットワークストレージ間で移動する処理の流れを示すフローチャートである。
【図１３】ネットワークストレージ装置を追加する場合の処理の流れを示すフローチャートである。
【図１４】ネットワークストレージ装置を削除する場合の処理の流れを示すフローチャートである。
【図１５】ネットワークストレージ間で容量に不均衡が生じた場合に行う各ネットワークストレージの残容量の平滑化処理のフローチャートである。
【図１６】既設ネットワークストレージ装置の仮想一元化ネットワークストレージシステムへの統合方法の処理の流れを説明するフローチャートである。
【図１７】既設ネットワークストレージ装置の統合に際して行うファイル識別子の生成方法の処理の流れを示すフローチャートである。
【図１８】既設ネットワークストレージ装置の統合に際して行うファイルの移動処理の流れを示すフローチャートである。
【図１９】本発明の仮想一元化方法を搭載した計算機システムの図である。
【図２０】ネットワークストレージとしての機能を備えた一元管理装置の構成を示す図である。
【図２１】複数の要求処理手段を備えた仮想一元化ネットワークストレージシステムを示す図である。
【符号の説明】
１ クライアント
２、４ ネットワーク
３ 仮想一元化装置
５、６、７ ネットワークストレージ
８、１４、１５ 仮想一元化ネットワークストレージシステム
１０ リモート
１１ ストレージ装置
１２ ネットワークストレージ機能付き仮想一元化装置
１３ 要求処理部を持たない仮想一元化装置
２０ ＣＰＵ
２１ コントローラ
２２ 主記憶
２３ Ｉ／Ｏインタフェース
２４ ネットワークインタフェース
２５ ストレージ装置
１００ ファイルシステム
１１０ グループマップ
１２０ グループ配置
１３０、１３１、１３２ 要求処理手段
１４０ 移動手段
１５０ 容量監視手段
１６０ 統合手段
１７０ ファイルハンドル
１８０ 管理手段
１００１、１００２、１００３、１００４、１００５、１００６，１００７ ｉノード
１００８，１００９，１０１０，１０１１ ディレクトリエントリ
１０１２，１０１３，１０１４ データブロック
１５００ 容量テーブル。
Claims (3)
- ネットワークに接続された複数のネットワークストレージ装置から構成されるネットワークストレージシステムにおいて、前記ネットワークストレージシステムをクライアントから仮想的に一つのネットワークストレージ装置としてアクセスさせるためのネットワークストレージシステムの仮想一元化方法であって、
前記仮想一元化方法によって仮想的に一元化された仮想一元化ネットワークストレージシステムに格納するファイルをグループ単位でネットワークストレージ装置に格納するために、ファイルを識別する情報から該ファイルが属する一つのファイルグループを導出するグループマップ関数を設定し、
ファイルグループとそのファイルグループに属する全てのファイルの格納先ネットワークストレージ装置との対応を記録するグループ配置表を設け、
前記クライアントが前記仮想一元化ネットワークストレージシステムに対してファイル生成要求を発行すると、前記ファイル生成要求中のファイルを識別する情報を前記グレープマップ関数に適用してファイルの属するファイルグループを求め、前記グループ配置表を参照して前記ファイルグループの格納先ネットワークストレージ装置を求め、求められた格納先ネットワークストレージ装置に前記ファイルを生成し、
前記複数のネットワークストレージ装置のそれぞれのストレージ残容量を定期的に収集し、
収集された各ネットワークストレージ装置のストレージ残容量が所定の条件に達すると、移動元ネットワークストレージ装置、及びそこに格納されている移動対象のファイルグループを選択し、ストレージ残容量が最大のネットワークストレージ装置を移動先ネットワークストレージとし、前記移動対象のファイルグループに属する全ファイルを移動し、前記移動に対応して前期グループ配置表のファイルグループと格納先ネットワークストレージ装置との対応を更新することを特徴とするネットワークストレージシステムの仮想一元化方法。 - 前記所定の条件は、前記複数のネットワークストレージ装置のいずれかのストレージ残容量が閾値を下回ったことであり、前記ストレージ残容量が閾値を下回ったネットワークストレージ装置を移動元ネットワークストレージ装置として選択することを特徴とする請求項１記載のネットワークストレージシステムの仮想一元化方法。
- 前記所定の条件は、前記複数のネットワークストレージ装置のストレージ残容量の最大値と最小値の差が閾値を越えたことであり、ストレージ残容量が最小値であるネットワークストレージ装置を移動元ネットワークストレージ装置に選択することを特徴とする請求項１記載のネットワークストレージシステムの仮想一元化方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002149977A JP4211285B2 (ja) | 2002-05-24 | 2002-05-24 | ネットワークストレージシステムの仮想一元化方法及び装置 |
| US10/335,853 US7606871B2 (en) | 2002-05-24 | 2003-01-03 | System and method for virtualizing network storages into a single file system view |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002149977A JP4211285B2 (ja) | 2002-05-24 | 2002-05-24 | ネットワークストレージシステムの仮想一元化方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003345643A JP2003345643A (ja) | 2003-12-05 |
| JP4211285B2 true JP4211285B2 (ja) | 2009-01-21 |
Family
ID=29545300
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002149977A Expired - Fee Related JP4211285B2 (ja) | 2002-05-24 | 2002-05-24 | ネットワークストレージシステムの仮想一元化方法及び装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7606871B2 (ja) |
| JP (1) | JP4211285B2 (ja) |
Families Citing this family (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7146389B2 (en) * | 2002-08-30 | 2006-12-05 | Hitachi, Ltd. | Method for rebalancing free disk space among network storages virtualized into a single file system view |
| US7831641B2 (en) * | 2003-04-24 | 2010-11-09 | Neopath Networks, Inc. | Large file support for a network file server |
| US7346664B2 (en) | 2003-04-24 | 2008-03-18 | Neopath Networks, Inc. | Transparent file migration using namespace replication |
| JP2004364109A (ja) * | 2003-06-06 | 2004-12-24 | Canon Inc | テンポラリアドレス通信装置、プログラム、記録媒体、および方法 |
| US20050038890A1 (en) * | 2003-08-11 | 2005-02-17 | Hitachi., Ltd. | Load distribution method and client-server system |
| US7890477B2 (en) * | 2003-08-20 | 2011-02-15 | Total Training Network, Inc. | Systems and methods for providing digital content |
| JP4349871B2 (ja) * | 2003-09-09 | 2009-10-21 | 株式会社日立製作所 | ファイル共有装置及びファイル共有装置間のデータ移行方法 |
| US8539081B2 (en) | 2003-09-15 | 2013-09-17 | Neopath Networks, Inc. | Enabling proxy services using referral mechanisms |
| JP4523772B2 (ja) * | 2003-12-24 | 2010-08-11 | 大日本印刷株式会社 | ネットワークを利用したデータ保管システム |
| JP2005215850A (ja) * | 2004-01-28 | 2005-08-11 | Hitachi Ltd | ストレージ装置、ストレージ装置の制御方法、及びストレージシステム |
| JP2005228170A (ja) * | 2004-02-16 | 2005-08-25 | Hitachi Ltd | 記憶装置システム |
| US7133988B2 (en) * | 2004-02-25 | 2006-11-07 | Hitachi, Ltd. | Method and apparatus for managing direct I/O to storage systems in virtualization |
| US7272654B1 (en) | 2004-03-04 | 2007-09-18 | Sandbox Networks, Inc. | Virtualizing network-attached-storage (NAS) with a compact table that stores lossy hashes of file names and parent handles rather than full names |
| US8195627B2 (en) * | 2004-04-23 | 2012-06-05 | Neopath Networks, Inc. | Storage policy monitoring for a storage network |
| US7720796B2 (en) * | 2004-04-23 | 2010-05-18 | Neopath Networks, Inc. | Directory and file mirroring for migration, snapshot, and replication |
| US8190741B2 (en) | 2004-04-23 | 2012-05-29 | Neopath Networks, Inc. | Customizing a namespace in a decentralized storage environment |
| KR20070038957A (ko) * | 2004-07-06 | 2007-04-11 | 마쯔시다덴기산교 가부시키가이샤 | 부호화 또는 복호화 장치 및 기록 재생 단말 |
| JP4281658B2 (ja) * | 2004-09-24 | 2009-06-17 | 日本電気株式会社 | ファイルアクセスサービスシステムとスイッチ装置及びクオータ管理方法並びにプログラム |
| JP4325524B2 (ja) * | 2004-09-29 | 2009-09-02 | 日本電気株式会社 | スイッチ装置とシステム並びにバックアップ及びリストア方法とプログラム |
| US7975061B1 (en) | 2004-11-05 | 2011-07-05 | Commvault Systems, Inc. | System and method for performing multistream storage operations |
| JP4451293B2 (ja) | 2004-12-10 | 2010-04-14 | 株式会社日立製作所 | 名前空間を共有するクラスタ構成のネットワークストレージシステム及びその制御方法 |
| FR2880487B1 (fr) * | 2004-12-31 | 2007-06-01 | Cit Alcatel | Procede de controle d'acces |
| JP2006293981A (ja) * | 2005-03-18 | 2006-10-26 | Hitachi Ltd | データベース格納方法、および、データベース格納システム |
| US8832697B2 (en) | 2005-06-29 | 2014-09-09 | Cisco Technology, Inc. | Parallel filesystem traversal for transparent mirroring of directories and files |
| US8131689B2 (en) | 2005-09-30 | 2012-03-06 | Panagiotis Tsirigotis | Accumulating access frequency and file attributes for supporting policy based storage management |
| US8290903B2 (en) * | 2005-10-04 | 2012-10-16 | Sony Ericsson Mobile Communications Ab | Updating a portable communication device with media files |
| US7620710B2 (en) * | 2005-12-19 | 2009-11-17 | Commvault Systems, Inc. | System and method for performing multi-path storage operations |
| JP2007183767A (ja) * | 2006-01-05 | 2007-07-19 | Fujitsu Ltd | 生体情報削除方法及びそのシステム |
| US8787199B1 (en) * | 2006-08-03 | 2014-07-22 | Oracle America, Inc. | Mechanism for data diffusion and evaporation across networks |
| US9110920B1 (en) * | 2007-05-03 | 2015-08-18 | Emc Corporation | CIFS access to NFS files and directories by translating NFS file handles into pseudo-pathnames |
| US7975109B2 (en) | 2007-05-30 | 2011-07-05 | Schooner Information Technology, Inc. | System including a fine-grained memory and a less-fine-grained memory |
| US7975102B1 (en) * | 2007-08-06 | 2011-07-05 | Netapp, Inc. | Technique to avoid cascaded hot spotting |
| US8229945B2 (en) | 2008-03-20 | 2012-07-24 | Schooner Information Technology, Inc. | Scalable database management software on a cluster of nodes using a shared-distributed flash memory |
| US8732386B2 (en) * | 2008-03-20 | 2014-05-20 | Sandisk Enterprise IP LLC. | Sharing data fabric for coherent-distributed caching of multi-node shared-distributed flash memory |
| US8352497B1 (en) * | 2009-02-09 | 2013-01-08 | American Megatrends, Inc. | Page object caching for variably sized access control lists in data storage systems |
| US20100257218A1 (en) * | 2009-04-03 | 2010-10-07 | Konstantin Iliev Vassilev | Merging multiple heterogeneous file systems into a single virtual unified file system |
| JP2010271933A (ja) * | 2009-05-21 | 2010-12-02 | Brother Ind Ltd | 分散保存システム、ノード装置、ノード処理プログラム及びデータファイル保存方法 |
| US8190655B2 (en) * | 2009-07-02 | 2012-05-29 | Quantum Corporation | Method for reliable and efficient filesystem metadata conversion |
| JP5375972B2 (ja) * | 2009-12-10 | 2013-12-25 | 日本電気株式会社 | 分散ファイルシステム、そのデータ選択方法およびプログラム |
| US8856593B2 (en) | 2010-04-12 | 2014-10-07 | Sandisk Enterprise Ip Llc | Failure recovery using consensus replication in a distributed flash memory system |
| US9047351B2 (en) | 2010-04-12 | 2015-06-02 | Sandisk Enterprise Ip Llc | Cluster of processing nodes with distributed global flash memory using commodity server technology |
| US9164554B2 (en) | 2010-04-12 | 2015-10-20 | Sandisk Enterprise Ip Llc | Non-volatile solid-state storage system supporting high bandwidth and random access |
| US8868487B2 (en) | 2010-04-12 | 2014-10-21 | Sandisk Enterprise Ip Llc | Event processing in a flash memory-based object store |
| US8700842B2 (en) | 2010-04-12 | 2014-04-15 | Sandisk Enterprise Ip Llc | Minimizing write operations to a flash memory-based object store |
| US8290994B2 (en) | 2010-05-05 | 2012-10-16 | International Business Machines Corporation | Obtaining file system view in block-level data storage systems |
| US8954385B2 (en) | 2010-06-28 | 2015-02-10 | Sandisk Enterprise Ip Llc | Efficient recovery of transactional data stores |
| US8694733B2 (en) | 2011-01-03 | 2014-04-08 | Sandisk Enterprise Ip Llc | Slave consistency in a synchronous replication environment |
| JP5477927B2 (ja) * | 2011-01-28 | 2014-04-23 | 日本電気株式会社 | ストレージシステム |
| US8874515B2 (en) | 2011-04-11 | 2014-10-28 | Sandisk Enterprise Ip Llc | Low level object version tracking using non-volatile memory write generations |
| JP5910117B2 (ja) * | 2012-01-30 | 2016-04-27 | 富士通株式会社 | ファイルシステム |
| US9135064B2 (en) | 2012-03-07 | 2015-09-15 | Sandisk Enterprise Ip Llc | Fine grained adaptive throttling of background processes |
| US9104675B1 (en) | 2012-05-01 | 2015-08-11 | Emc Corporation | Inode to pathname support with a hard link database |
| US20130311597A1 (en) * | 2012-05-16 | 2013-11-21 | Apple Inc. | Locally backed cloud-based storage |
| US10043017B2 (en) * | 2013-04-15 | 2018-08-07 | Paul Lewis | Systems and methods for jurisdiction independent data storage in a multi-vendor cloud environment |
| US10984116B2 (en) * | 2013-04-15 | 2021-04-20 | Calamu Technologies Corporation | Systems and methods for digital currency or crypto currency storage in a multi-vendor cloud environment |
| US11636217B2 (en) * | 2013-04-15 | 2023-04-25 | Calamu Technologies Corporation | Systems and methods for breach-proof, resilient, compliant data in a multi-vendor cloud environment and automatically self heals in the event of a ransomware attack |
| WO2014184941A1 (ja) * | 2013-05-17 | 2014-11-20 | 株式会社日立製作所 | ストレージ装置 |
| EP2836901B1 (en) * | 2013-07-02 | 2017-09-06 | Hitachi Data Systems Engineering UK Limited | Method and apparatus for virtualization of a file system, data storage system for virtualization of a file system, and file server for use in a data storage system |
| JP2015072629A (ja) * | 2013-10-03 | 2015-04-16 | 富士通株式会社 | データ処理プログラム及びデータ処理方法 |
| JP6221717B2 (ja) | 2013-12-12 | 2017-11-01 | 富士通株式会社 | ストレージ装置、ストレージシステム及びデータ管理プログラム |
| US9330103B1 (en) * | 2014-03-28 | 2016-05-03 | Emc Corporation | Preserving file handles when moving file system operation between storage processors |
| US9710164B2 (en) | 2015-01-16 | 2017-07-18 | International Business Machines Corporation | Determining a cause for low disk space with respect to a logical disk |
| US11010261B2 (en) | 2017-03-31 | 2021-05-18 | Commvault Systems, Inc. | Dynamically allocating streams during restoration of data |
| WO2020160136A1 (en) * | 2019-01-30 | 2020-08-06 | Paul Lewis | Systems and methods for digital currency or crypto currency storage in a multi-vendor cloud environment |
| CN110321077B (zh) * | 2019-06-17 | 2023-04-14 | 浩云科技股份有限公司 | 一种集中存储文件的管理方法及装置 |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69623227T2 (de) * | 1995-10-27 | 2003-04-17 | Ncr Int Inc | Verfahren und System zur Berechnung von Dateinamen mit hoher Wahrscheinlichkeit der Eindeutigkeit |
| JP3170455B2 (ja) * | 1996-05-27 | 2001-05-28 | インターナショナル・ビジネス・マシーンズ・コーポレ−ション | データ記憶システムにおけるデータの再配置方法、そのシステムに記憶されたデータのアクセス方法及びデータ記憶システム |
| US6658526B2 (en) * | 1997-03-12 | 2003-12-02 | Storage Technology Corporation | Network attached virtual data storage subsystem |
| US6101508A (en) * | 1997-08-01 | 2000-08-08 | Hewlett-Packard Company | Clustered file management for network resources |
| US6029168A (en) * | 1998-01-23 | 2000-02-22 | Tricord Systems, Inc. | Decentralized file mapping in a striped network file system in a distributed computing environment |
| US6807632B1 (en) * | 1999-01-21 | 2004-10-19 | Emc Corporation | Content addressable information encapsulation, representation, and transfer |
| WO2000004483A2 (en) * | 1998-07-15 | 2000-01-27 | Imation Corp. | Hierarchical data storage management |
| US6640278B1 (en) * | 1999-03-25 | 2003-10-28 | Dell Products L.P. | Method for configuration and management of storage resources in a storage network |
| US6195650B1 (en) * | 2000-02-02 | 2001-02-27 | Hewlett-Packard Company | Method and apparatus for virtualizing file access operations and other I/O operations |
| US20020103889A1 (en) * | 2000-02-11 | 2002-08-01 | Thomas Markson | Virtual storage layer approach for dynamically associating computer storage with processing hosts |
| AU2001246799A1 (en) * | 2000-04-18 | 2001-10-30 | Storeage Networking Technologies | Storage virtualization in a storage area network |
| US20010039548A1 (en) * | 2000-04-27 | 2001-11-08 | Yoshitake Shinkai | File replication system, replication control method, and storage medium |
| US6745207B2 (en) * | 2000-06-02 | 2004-06-01 | Hewlett-Packard Development Company, L.P. | System and method for managing virtual storage |
| US6912537B2 (en) * | 2000-06-20 | 2005-06-28 | Storage Technology Corporation | Dynamically changeable virtual mapping scheme |
| US7082441B1 (en) * | 2000-08-17 | 2006-07-25 | Emc Corporation | Method and storage and manipulation of storage system metrics |
| US6782389B1 (en) * | 2000-09-12 | 2004-08-24 | Ibrix, Inc. | Distributing files across multiple, permissibly heterogeneous, storage devices |
| US6907457B2 (en) * | 2001-01-25 | 2005-06-14 | Dell Inc. | Architecture for access to embedded files using a SAN intermediate device |
| US6990667B2 (en) * | 2001-01-29 | 2006-01-24 | Adaptec, Inc. | Server-independent object positioning for load balancing drives and servers |
| US6601070B2 (en) * | 2001-04-05 | 2003-07-29 | Hewlett-Packard Development Company, L.P. | Distribution of physical file systems |
| US6971044B2 (en) * | 2001-04-20 | 2005-11-29 | Egenera, Inc. | Service clusters and method in a processing system with failover capability |
| US7136883B2 (en) * | 2001-09-08 | 2006-11-14 | Siemens Medial Solutions Health Services Corporation | System for managing object storage and retrieval in partitioned storage media |
| JP2003131924A (ja) * | 2001-10-19 | 2003-05-09 | Fujitsu Ltd | リモートアクセスプログラム、リモートアクセス要求処理プログラム、およびクライアントコンピュータ |
| US6895467B2 (en) * | 2001-10-22 | 2005-05-17 | Hewlett-Packard Development Company, L.P. | System and method for atomizing storage |
| US7010655B1 (en) * | 2003-03-24 | 2006-03-07 | Veritas Operating Corporation | Locking and memory allocation in file system cache |
| US6959313B2 (en) * | 2003-07-08 | 2005-10-25 | Pillar Data Systems, Inc. | Snapshots of file systems in data storage systems |
-
2002
- 2002-05-24 JP JP2002149977A patent/JP4211285B2/ja not_active Expired - Fee Related
-
2003
- 2003-01-03 US US10/335,853 patent/US7606871B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7606871B2 (en) | 2009-10-20 |
| JP2003345643A (ja) | 2003-12-05 |
| US20030220985A1 (en) | 2003-11-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4211285B2 (ja) | ネットワークストレージシステムの仮想一元化方法及び装置 | |
| US7587471B2 (en) | System and method for virtualizing network storages into a single file system view | |
| US7680847B2 (en) | Method for rebalancing free disk space among network storages virtualized into a single file system view | |
| US7590667B2 (en) | File replication method for distributed file systems | |
| US7406484B1 (en) | Storage allocation in a distributed segmented file system | |
| US7743035B2 (en) | System and method for restoring a virtual disk from a snapshot | |
| US9442952B2 (en) | Metadata structures and related locking techniques to improve performance and scalability in a cluster file system | |
| US7769711B2 (en) | Migration of control in a distributed segmented file system | |
| US8977659B2 (en) | Distributing files across multiple, permissibly heterogeneous, storage devices | |
| JP5066415B2 (ja) | ファイルシステム仮想化のための方法および装置 | |
| US8161133B2 (en) | Network storage system with a clustered configuration sharing a namespace, and control method therefor | |
| US9405487B2 (en) | Media aware distributed data layout | |
| US8984031B1 (en) | Managing data storage for databases based on application awareness | |
| EP1805591A2 (en) | System and method for reclaming unused space from a thinly provisioned data container | |
| JP2004110218A (ja) | Ｄｂｍｓ向け仮想ボリューム作成・管理方法 | |
| US20070192375A1 (en) | Method and computer system for updating data when reference load is balanced by mirroring | |
| WO2007014296A2 (en) | Scalable distributed file storage access and management | |
| JP2002373103A (ja) | 計算機システム | |
| JP2004252957A (ja) | 分散ファイルシステムのファイルレプリケーション方法及び装置 | |
| US8935307B1 (en) | Independent data access in a segmented file system | |
| Feng et al. | Massive storage systems | |
| Tammineedi | Design of the management component in a scavenged storage environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050518 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060419 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080722 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080922 |
|
| 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: 20081020 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111107 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111107 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111107 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121107 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121107 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131107 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |