JP4237515B2 - ネットワークストレージ仮想化方法およびネットワークストレージシステム - Google Patents
ネットワークストレージ仮想化方法およびネットワークストレージシステム Download PDFInfo
- Publication number
- JP4237515B2 JP4237515B2 JP2003030426A JP2003030426A JP4237515B2 JP 4237515 B2 JP4237515 B2 JP 4237515B2 JP 2003030426 A JP2003030426 A JP 2003030426A JP 2003030426 A JP2003030426 A JP 2003030426A JP 4237515 B2 JP4237515 B2 JP 4237515B2
- Authority
- JP
- Japan
- Prior art keywords
- network storage
- access request
- directory server
- file
- client
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークストレージ仮想化システムに係り、ネットワークに直付けされるネットワークストレージを仮想化することにより、クライアントからのネットワークストレージのアクセスを容易にして、システムの構築、運用を柔軟におこなうことのできるネットワークストレージ仮想化システムに関する。
【０００２】
【従来の技術】
従来の情報処理システムでは、計算機システムに直接接続したハードディスクドライブなどのストレージに情報を格納していた。ストレージに格納した情報は、ストレージを直接接続した計算機からのみアクセス可能なため、他の計算機システムから情報にアクセスするためには、ストレージを直接接続した計算機を経由する必要があった。
【０００３】
しかしながら、近年のネットワーク技術の発達と格納すべき情報量の飛躍的な増大により、情報を処理する計算機システムと情報を格納するストレージシステムの分離の動きが進んでいる。その結果、ネットワークに接続し複数の計算機システム間で情報を共有できるストレージシステムが出現してきた。このようなネットワークに接続するストレージをネットワークストレージと呼ぶ。
【０００４】
このようなネットワークストレージの例として、ＳＡＮ（Storage Area Network）で接続してブロックアクセスを提供するＳＡＮストレージ、ＩＰネットワークやＩｎｆｉｎｉｂａｎｄなどで接続してファイルアクセスを提供するＮＡＳ（Network Attached Storage）、ＷｅｂアクセスのインタフェースであるＨＴＴＰプロトコルやそれを拡張したプロトコルでのアクセス形態を提供するＷｅｂストレージなどがある。
【０００５】
ネットワークストレージの普及につれ、システム管理者は、ネットワークに接続した複数のネットワークストレージを管理する必要が生じてきた。例えば、格納すべきデータ量が既存のネットワークストレージの最大値を越えるような場合には、新たなネットワークストレージを追加し、データの再分配などのシステム再構築が必要になる。ストレージ容量に対する需要の急激な伸びは、度重なるシステム再構築を強いるためシステム管理コストを膨張させてきた。
【０００６】
システム管理コストの抑制には、複数のネットワークストレージを計算機システムからは仮想的に一つに見せ、新たな装置の追加を行なってもシステム全体に影響が及ばないようにするストレージ仮想化技術が必須となっている。このようなストレージ仮想化技術に関しては各種方式が開発され提案されている。
【０００７】
例えば、１９９５年にＨａｒｔｍａｎらが発表したＺｅｂｒａ（例えば、非特許文献１参照）では、一つのファイルをストライピングして複数のネットワークストレージに分散格納する方式を提案している。この方式では、ファイルを一定の長さごとに分割し、ネットワークストレージにラウンド・ロビン方式で順次格納する。Ｚｅｂｒａでは、ファイルがどのストレージにどのような順番で分散格納しているか集中管理するサーバがあり、ファイルアクセス処理時にはこの管理サーバにファイルの格納位置に関する情報を問い合わせてからファイルの本体データにアクセスするという特徴がある。すなわち、Ｚｅｂｒａでは、ファイルを複数のサーバに分散格納させて一つのサーバで集中管理することにより、複数のネットワークストレージを仮想的に一つの大きいネットワークストレージに見せている。
【０００８】
また、特許文献１では、Ａｌｅｘａｎｄｅｒ Ｈ． Ｆｒｅｙらは、Ｚｅｂｒａの集中管理サーバ方式と異なる非集中管理サーバ方式によりファイルのストライピングを行なう方式を提案している。この方式では、ファイルのストライピング情報が格納されているスタータノード情報をファイル識別子に埋め込むことで、Ｚｅｂｒａで集中管理していたストライピング情報を複数のネットワークストレージで分散管理している。ファイル識別子にスタータノードを格納するため、クライアントがファイルアクセスする際には、まずスタータノードへアクセスをおこない、そこでファイルの格納位置を決定し、必要があればアクセスすべきファイルの断片（ブロック）を格納しているサーバへアクセス要求を転送して処理することになる。このため、クライアントからの当該ファイルについてのアクセスは、スタータノードへ要求を発行するだけで良く、ファイルのストライピングによる格納位置を考慮する必要がないという利点がある。
【０００９】
また、特許文献２の「分散ファイル管理装置及び分散ファイル管理システム」では、複数のサーバ計算機に状態管理部を設け、負荷情報を保持して負荷を管理し、記憶装置に、分散ファイルの一部または全部を構成する部分ファイルを記憶して、分散ファイルの部分ファイルを特定し、状態管理部で管理する負荷情報に基づき部分ファイルを処理するサーバ計算機を決定するようにする。これにより特定のサーバへの負荷の集中を防ぐことができる。
【００１０】
【非特許文献１】
The Zebra Striped Network File System, Hartman et. al., ACM Transactions on ComputerSystem, Vol. 13, No. 3, 1995, pp. 274-310.
【特許文献１】
米国特許第６，０２９，１６８号明細書
【特許文献２】
特開２０００―２０７３７０号公報
【００１１】
【発明が解決しようとする課題】
上記従来技術のＺｅｂｒａでは、ファイルを分散していても、ユーザはそれらの詳細情報を保持していなくてもアクセスできる利点がある。しかしながら、前記Ｚｅｂｒａでは、アクセスするファイルの断片を格納するネットワークストレージを決定する際に、集中管理サーバに問い合わせる必要があり、特にファイルの更新ではネットワークストレージ上のデータの他に集中管理サーバ上のデータも更新する必要がある。このため、ネットワークストレージの台数が増加すると集中管理サーバがボトルネックとなり、システムのスケーラビリティを阻害する要因となっている。さらに、Ｚｅｂｒａでは専用のクライアントが必要となるため、ＮＦＳなどの標準プロトコルに適用できない問題がある。
【００１２】
また、特許文献１の非集中管理サーバ方式では、管理サーバが複数のサーバに分散されている点では、集中管理サーバがボトルネックになるというＺｅｂｒａの問題点を解決している。しかしながら、このシステムではファイルアクセスする際にファイルを一意に特定するファイル名あるいはディレクトリ名とスタータノードが埋め込まれているファイル識別子との変換を分散ディレクトリ等のサーバがおこなうことが前提となっており、ファイルの格納場所を管理するサーバとファイル名との対応を管理する情報が別途必要となっている。特許文献１の実施例ではそのような情報を格納する手段としてａ ″ｗｅｌｌ−ｋｎｏｗｎ″ ｄｉｓｔｒｉｂｕｔｅｄ ｄｉｒｅｃｔｏｒｙ ｆｉｌｅを利用すると述べている。また、ファイル識別子にスタータノードの位置を直接埋め込むため、新しいネットワークストレージを追加して既存のファイルのスタータノードを新しいネットワークストレージに移動する際には、分散ディレクトリに格納されているファイル名とファイル識別子との対応情報を書き換える必要がある。このため、新規ネットワークストレージ増設の際の管理コストが増大する問題がある。
【００１３】
また、特許文献２に記載の発明では、複数サーバ間での負荷、特にディスクやネットワークへの負荷の分散に主眼を置いているが、分散ファイル管理手段の冗長化を考慮していないため、障害発生時にアクセスが不能になる問題がある。
【００１４】
本発明は、上記問題点を解決するためになされもので、その第一の目的は、ＮＦＳなどの標準プロトコルを用いてアクセス可能なネットワークストレージ仮想化方法を提供することである。
【００１５】
また、本発明の第二の目的は、ネットワークストレージの増設や減設の際の管理コストが小さいネットワークストレージ仮想化方法を提供することである。
【００１６】
また、本発明の第三の目的は、ファイル管理情報を冗長化することで障害発生時にも継続して運用可能なネットワークストレージ仮想化方法を提供することである。
【００１７】
さらに、本発明の第四の目的は、クライアントからの要求を受信するネットワークストレージと、要求の処理をおこないクライアントに応答を返すネットワークストレージとが異なる場合でも、クライアントでは、そのことを意識せずとも、ネットワークストレージへの要求をおこなうことのできるネットワークストレージ仮想化システムを提供することである。
【００１８】
【課題を解決するための手段】
本発明のネットワークストレージ仮想化方法は、上記目的を達成するため以下のようにする。
【００１９】
ネットワークストレージ仮想化システムにファイル管理情報を保存するディレクトリサーバを設け、クライアントからネットワークストレージにアクセス要求があったときに、クライアントからの要求を第一のネットワークストレージが受信し、第一のネットワークストレージが受信した要求をディレクトリサーバに転送する。そして、ディレクトリサーバは、ファイル管理情報を基に要求を処理するネットワークストレージとして第二のネットワークストレージを選択して、その第二のネットワークストレージに要求を転送する。
【００２０】
第二のネットワークストレージでは、要求を処理して、要求を処理した結果を要求の応答としてクライアントに送信するようにする。
【００２１】
また、ディレクトリサーバが複数あるときには、受信した要求を転送するためのディレクトリサーバを選択するようにする。
【００２２】
このときに、第二のネットワークストレージは、要求を処理したのは、第一のネットワークストレージであるように見せかけた応答を処理結果に含ませて返すようにする。したがって、クライアントでは、どのネットワークストレージが処理をおこなったかを意識せずともよい。
【００２３】
また、前記ディレクトリサーバが要求を処理するネットワークストレージとして第二のネットワークストレージを選択したことを、第一のネットワークストレージに通知するようにしてもよい。このようにして、第一のネットワークストレージに通知内容を保存しておけば、二回目に第一のネットワークストレージに同じファイルにアクセスがあったときに、直接、その要求を第二のネットワークストレージに転送することができる。
【００２４】
また、ディレクトリサーバの有するファイル管理情報を分割して複数のネットワークストレージにも保存するようにして、クライアントからネットワークストレージにアクセス要求があったときに、クライアントからの要求を受信した第一のネットワークストレージでは、要求を転送するディレクトリサーバまたは第二のネットワークストレージを選択して、選択したディレクトリサーバまたは前記第二のネットワークストレージに、要求を転送するようにする。
【００２５】
選択されたディレクトリサーバまたは第二のネットワークストレージでは、要求を処理する第三のネットワークストレージに要求を転送して、第三のネットワークストレージに処理をおこなわせる。
【００２６】
ディレクトリサーバとネットワークストレージに分割して保存されるファイル管理情報は、整合性を維持して保存しておく必要がある。
【００２７】
このようにすれば、ファイル管理情報が分散して管理されるため、冗長度が増し、システムの安全度を高めることができる。
【００２８】
また、クライアントからネットワークストレージにアクセス要求があったときに、要求を受信したネットワークストレージで、ディレクトリサーバに対して前記受信した要求を処理するネットワークストレージを問い合わせて、通知させ、要求を受信したネットワークストレージで、要求を処理するネットワークストレージに転送するようにしてもよい。
【００２９】
このネットワークストレージ仮想化方法では、標準のプロトコルでシステムを構築することができ、クライアントに特別なプロトコルや仕様を意識させることはない。また、ファイルの容量増加したときなどのシステムの増設などもネットワークストレージを追加することにより簡単におこなうことができる。
【００３０】
さらに、ファイル管理情報を分散管理されているために、システムの安全性が高まっており、一部のディレクトリサーバやネットワークストレージに障害がおこっても継続運転することが可能である。
【００３１】
【発明の実施の形態】
以下、本発明に係る各実施形態を、図１ないし図８を用いて説明する。
【００３２】
〔本発明のネットワークストレージシステムのシステム構成〕
先ず、図１を用いて本発明のネットワークストレージシステムのシステム構成について説明する。
図１は、本発明のネットワークストレージシステムのシステム構成図である。
【００３３】
本発明のネットワークストレージは、クライアントＫ００と、ネットワークストレージＮ０１〜Ｎ０４およびディレクトリサーバＤ０１、Ｄ０２とをＬＡＮ１００により接続する。
【００３４】
クライアントＫ００は、サーバに対してファイルの読み書き、ファイル管理情報取得などのファイルアクセス要求をおこなう。
【００３５】
ネットワークストレージＮ０１〜Ｎ０４は、ネットワークに直接接続されているストレージデバイスであり、ファイルの本体データを格納する。
【００３６】
ディレクトリサーバＤ０１、Ｄ０２は、ファイル属性やファイル本体データを格納しているネットワークストレージの情報などからなるファイルの管理情報を格納する。
【００３７】
なお、この図１の例では、ネットワークストレージが三台、ディレクトリサーバが二台であるが、ネットワークストレージは、システムの規模に応じて何台でも増設してもよいし、ディレクトリサーバは、ファイル管理情報の容量、サーバの性能などに従って適切な台数を設けることができる。
【００３８】
〔実施形態１〕
次に、図２ないし図５を用いて本発明に係る第一の実施形態について説明する。
図２は、本発明に係る第一の実施形態の処理の流れを示す模式図である。
図３は、クライアントからＲＥＡＤ／ＷＲＩＴＥ要求がされたときの処理を示すＰＡＤ（Problem Analysis Diagram）図である。
図４は、クライアントからＣＲＥＡＴＥ要求がされたときの処理を示すＰＡＤ図である。
図５は、クライアントからＬＯＯＫＵＰ要求がされたときの処理を示すＰＡＤ図である。
【００３９】
本実施形態では、ＲＦＣ１８１３（NFS Version3 Protocol Specification）に記載のＮＦＳのプロトコルを使いクライアントＫ００が通信する場合のネットワークストレージの仮想化方法について説明する。ＮＦＳ（Network File System）は、ＴＣＰ／ＩＰ環境下で標準的に使用される分散分散ファイルシステムである。以下では、ＮＦＳの代表的なプロトコルであるＲＥＡＤ、ＷＲＩＴＥ、ＣＲＥＡＴＥ、ＬＯＯＫＵＰを例にしてネットワーク仮想化方法の動作を説明するが、その他のＮＦＳのプロトコルについても、同様に考えることができる。
（Ｉ）ネットワークストレージ仮想化方法の処理の概要
先ず、図２により本発明のネットワークストレージ仮想化方法の処理の概要について説明する。
【００４０】
図２（ａ）は、クライアントからの要求がファイル本体とファイル管理情報の両方にアクセスする場合であり、ＲＥＡＤ、ＷＲＩＴＥ、ＣＲＥＡＴＥなどのプロトコルがこれに該当する。
【００４１】
この処理では、先ず、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）にＬＡＮ経由でファイルアクセス要求を発する（Ａ０１）。ファイルの管理情報は、ディレクトリサーバに格納されているため、ネットワークストレージＮ０１では、そのファイルのファイル管理情報を格納されているディレクトリサーバＤ０１を選択して、その要求を転送する（Ａ０２）。
【００４２】
このときに、ネットワークストレージＮ０１は、転送されてきたクライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報を転送する。
【００４３】
ディレクトリサーバＤ０１は、そのファイルの格納されているネットワークストレージを検索して、転送されてきたクライアントと第一のネットワークストレージＮ０１のＩＰアドレスなどの情報と共に、該当するネットワークストレージＮ０３（第二のネットワークストレージ）に要求を転送する（Ａ０３）。
【００４４】
ネットワークストレージＮ０３では、受信した要求を処理して、クライアントＫ００に応答を返す（Ａ０４）。このとき、ファイルアクセス時刻などのファイル管理情報の更新処理などのために、ディレクトリサーバＤ０１に対してファイル管理情報の読み出しや更新をおこなう（Ａ０５）。
【００４５】
ここで重要なことは、処理をおこなう第二のネットワークストレージＮ０３は、要求を処理したのは、第一のネットワークストレージＮ０１であるように見せかけるようにすることである。すなわち、第二のネットワークストレージＮ０３に、クライアントと第一のネットワークストレージＮ０１のＩＰアドレスなどの情報が転送されるので、第二のネットワークストレージＮ０３の応答パケットに第一のネットワークストレージＮ０１のＩＰアドレスを含めて、クライアントＫ００でファイルアクセスの要求を出したセッションを引き継げるようにする。
【００４６】
このようにすれば、クライアントＫ００からみると、どのネットワークストレージが要求を処理するかを意識せずともよい。
【００４７】
図２（ｂ）は、クライアントからの要求がファイル管理情報のみにアクセスする場合であり、例えば、ＬＯＯＫＵＰなどのプロトコルがこれに該当する。
【００４８】
この処理では、先ず、クライアントＫ００は、システム上の任意のネットワークストレージＮ０１にＬＡＮ経由でファイルアクセス要求を発する（Ａ０１）。ファイルの管理情報は、ディレクトリサーバに格納されているため、ネットワークストレージＮ０１では、そのファイルのファイル管理情報を格納しているディレクトリサーバＤ０１を選択して、その要求を転送する（Ａ０２）。
【００４９】
ディレクトリサーバＤ０１は、受信した要求を処理して、クライアントＫ００に応答を返す（Ａ０４）。
【００５０】
このタイプの要求は、ファイル管理情報のみのアクセスであるため、ディレクトリサーバだけで処理することができる。
（II）ネットワークストレージ仮想化方法の処理の詳細
次に、図３ないし図５を用いて各プロトコル毎に本発明のネットワークストレージ仮想化方法の処理の詳細について説明する。
（ａ）ＲＥＡＤ／ＷＲＩＴＥプロトコル
ＮＦＳのＲＥＡＤ／ＷＲＩＴＥ要求は、ファイルに対して読み書きをおこなうプロトコルである。また、ファイルハンドルｆｉｌｅで指定するファイルについて、ファイルに対して読み書きをおこなって、ファイルの属性を返すインタフェースを持つ。
【００５１】
なお、ファイルハンドルとは、ＮＦＳでファイルに対する情報を取り扱うための識別子である。
【００５２】
先ず、クライアントＫ００がネットワークストレージＮ０１に対して、ファイルハンドルｆｉｌｅに対するＲＥＡＤ／ＷＲＩＴＥ要求を発行する（図２（ａ）Ａ０１）。
【００５３】
ネットワークストレージＮ０１は、クライアントＫ００からのＲＥＡＤ／ＷＲＩＴＥ要求を受信する（Ｓ３０１）。ＮＦＳではファイルハンドルは最大６４バイトの可変長の値である。
【００５４】
ディレクトリサーバは、このシステムでは二台あるので、このファイルハンドルを基にディレクトリサーバＤ０１、Ｄ０２のどちらに処理を依頼するかを決定する必要がある。この決定の方法には、例えば、ラウンドロビンでディレクトリサーバを交互に切り替える方法や、ファイルハンドルの２の剰余でディレクトリサーバを決定する方法がある。以降では、剰余によりディレクトリサーバを決定するものとして説明する。剰余が０（ファイルハンドルの最下位ビットが０）の場合ディレクトリサーバＤ０１を選択し、剰余が１（ファイルハンドルの最下位ビットが１）の場合ディレクトリサーバＤ０２を選択する。ここでは仮にディレクトリサーバＤ０１を選択したとする（Ｓ３０２）。
【００５５】
剰余によってディレクトリサーバを選択することにより、例えば、ファイル属性を変更する場合には、特定のファイルハンドルを処理するディレクトリサーバを一意に指定できるため、二つのディレクトリサーバで同一のファイルハンドルについてファイル属性を変更し、データの整合性が取れなくなる事態を回避することができる。
【００５６】
もちろん、このようなディレクトリサーバの選択にファイルハンドルの剰余を用いる方法のほかに、ファイルハンドルとディレクトリサーバを一対一に結びつける任意の手段を用いることができる。
【００５７】
次に、ネットワークストレージＮ０１がディレクトリサーバＤ０１に対して受信したＲＥＡＤ／ＷＲＩＴＥ要求を転送する（Ｓ３０３、図２（ａ）Ａ０２）。ここで、クライアントＫ００のＩＰアドレス、ネットワークストレージＮ０１のＩＰアドレス、ＴＣＰやＵＤＰの送受信のポート番号、ＲＰＣのトランザクションＩＤ（ＸＩＤ）、ＲＰＣのプログラム番号、ＲＰＣのバージョン番号、ＲＰＣのプロシージャ番号、ＲＰＣの認証情報と検証情報など、応答メッセージを作成するのに必要な情報の全てを転送する。
【００５８】
転送した要求を受信したディレクトリサーバＤ０１では、ファイルハンドルｆｉｌｅを検索し（Ｓ３０４）、実際に存在するファイルハンドルであるか否かを確認する。ｆｉｌｅが見つかった場合には、Ｓ３１１に進み、見つからなかった場合には、Ｓ３２１に進む。
【００５９】
ｆｉｌｅが見つかった場合には、先ず、ｆｉｌｅに対応したファイルの本体データを保持するネットワークストレージを検索する（Ｓ３１１）。ここではネットワークストレージＮ０３がファイルの本体データを保持しているとする。このネットワークストレージＮ０３にＲＥＡＤ／ＷＲＩＴＥ要求を転送する（Ｓ３１２、図２（ａ）Ａ０３）。
【００６０】
ここでも先ほどと同様にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も同時に転送する。
【００６１】
この要求を受けたネットワークストレージＮ０３では、ｆｉｌｅに対応したファイルの本体データをＲＥＡＤ／ＷＲＩＴＥする（Ｓ３１３）。
【００６２】
ファイルをＲＥＡＤ／ＷＲＩＴＥするとアクセス時刻などのファイルの属性を更新する必要がある。そこで、ディレクトリサーバＤ０１にｆｉｌｅのファイル属性の更新と、必要なファイル属性情報の読み出しを依頼する（Ｓ３１４、図２（ａ）Ａ０５）。そして、応答メッセージを組み立てる（Ｓ３１５）。ここで、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からの応答だと認識するように、ネットワークストレージＮ０３が応答メッセージを組み立てる。最後に、組み立てた応答メッセージをクライアントＫ００に送信する（Ｓ３１６、図２（ａ）Ａ０４）。
【００６３】
ｆｉｌｅが見つからなかった場合には、ｆｉｌｅのファイル属性を読み出し（Ｓ３２１）、エラーメッセージを組み立てる（Ｓ３２２）。ここでｆｉｌｅが見つかった場合と同様に、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からのエラーメッセージだと認識するように、ディレクトリサーバＤ０１がエラーメッセージを組み立てる。最後に、組み立てたエラーメッセージをクライアントＫ００に送信する（Ｓ３２３、図２（ａ）Ａ０４）。
【００６４】
このＲＥＡＤ／ＷＲＩＴＥ要求の処理では、Ｓ３０２で要求を転送するディレクトリサーバを選択して要求を転送していることにより、ディレクトリサーバの負荷分散をおこなうことができる。さらに、Ｓ３０３で要求を転送する際にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も転送して、Ｓ３１５やＳ３２２であたかもネットワークストレージＮ０１がメッセージを組み立てたかのようにクライアントＫ００に応答するため、クライアントＫ００ではどのネットワークストレージで処理がおこなわれたのかを意識せずともよい。
【００６５】
また、ファイルハンドルごとにファイル属性を処理するディレクトリサーバが一意に決まるため、ファイル属性更新時に、二つのディレクトリサーバでのデータ整合性を確保することができる。
【００６６】
さらに、複数のネットワークストレージにＲＥＡＤ／ＷＲＩＴＥ要求を転送することにより、ネットワークストレージの負荷分散をおこなうことができる。
（ｂ）ＣＲＥＡＴＥプロトコル
ＮＦＳのＣＲＥＡＴＥ要求は、指定されたディレクトリにファイルを生成するプロトコルである。このＣＲＥＡＴＥ要求は、ファイルハンドルｄｉｒで指定するディレクトリ上にファイル名ｎａｍｅのファイルを新規作成し、作成したファイルのファイルハンドルｏｂｊ＿ｆｈとファイルとディレクトリの属性を返すインターフェースを持つ。
【００６７】
先ず、クライアントＫ００がネットワークストレージＮ０１に対して、ファイルハンドルｄｉｒ上にファイル名ｎａｍｅのファイルを新規作成するＣＲＥＡＴＥ要求を発行する（図２（ａ）Ａ０１）。
【００６８】
ネットワークストレージＮ０１は、このクライアントＫ００からのＣＲＥＡＴＥ要求を受信する（Ｓ４０１）。ＮＦＳでは、既に述べたようにファイルハンドルは最大６４バイトの可変長の値である。
【００６９】
ネットワークストレージＮ０１では、このファイルハンドルを基にディレクトリサーバＤ０１、Ｄ０２のどちらに処理を依頼するかを決定する（Ｓ４０２）。
【００７０】
ここでもＲＥＡＤ／ＷＲＩＴＥの場合と同様に、ファイルハンドルの剰余で処理を依頼するディレクトリサーバを決定する。剰余によってディレクトリサーバを選択することにより、二つのディレクトリサーバが同一ディレクトリ上に同一ファイル名を同時に作成し、データ整合性が取れなくなる事態を回避できる。ここでは仮にディレクトリサーバＤ０１を選択したとする。
【００７１】
ネットワークストレージＮ０１が、選択したディレクトリサーバＤ０１に受信したＣＲＥＡＴＥ要求を転送する（Ｓ４０３、図２（ａ）Ａ０２）。ここで、クライアントＫ００のＩＰアドレス、ネットワークストレージＮ０１のＩＰアドレス、ＴＣＰやＵＤＰの送受信のポート番号、ＲＰＣのトランザクションＩＤ（ＸＩＤ）、ＲＰＣのプログラム番号、ＲＰＣのバージョン番号、ＲＰＣのプロシージャ番号、ＲＰＣの認証情報と検証情報などの応答メッセージを作成するのに必要な情報の全てを転送する。
【００７２】
転送した要求を受信したディレクトリサーバＤ０１では、ファイルハンドルｄｉｒを検索し（Ｓ４０４）、実際に存在するディレクトリのファイルハンドルであるかどうかを確認する。ｄｉｒが見つかった場合には、Ｓ４１１に進み、見つからなかった場合には、Ｓ４２１に進む。
【００７３】
ｄｉｒが見つかった場合には、ファイル名ｎａｍｅの新規ファイルを作成するネットワークストレージを選択する（Ｓ４１１）。ネットワークストレージの選択の際には、以下の手法により最も負荷の低いネットワークストレージを選択すればよい。先ず、各ネットワークストレージのディスク使用率Ｕ％を求める。次に、各ネットワークストレージのネットワーク帯域使用率Ｂ％を求める。そして、別途定めるディスク容量とネットワーク帯域のどちらを優先して評価するかを定めるパラメータα、βを用いて、評価式α＊Ｕ＋β＊Ｂにより各ネットワークストレージを評価する。ただし、ここでα、βは正数とする。評価式の値が大きいほどネットワークストレージのディスクまたはネットワークの負荷が大きいことを意味する。したがって、この評価式の値の小さいネットワークストレージを選択するようにするのが合理的である。
【００７４】
ここでは、仮にネットワークストレージＮ０３を選択したとする。このときネットワークストレージＮ０３にＣＲＥＡＴＥ要求を転送する（Ｓ４１２、図２（ａ）Ａ０３）。ここでも先程と同様にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も同時に転送する。
【００７５】
ネットワークストレージＮ０３では、ファイル名ｎａｍｅのファイル本体データのエントリとファイルハンドルｏｂｊ＿ｆｈを作成する（Ｓ４１３）。そして、ＲＥＡＤ／ＷＲＩＴＥのところで述べた手法で、ｏｂｊ＿ｆｈの剰余からディレクトリサーバを選択する。ここでは、ディレクトリサーバＤ０１が選択されたものとする。ネットワークストレージＮ０３は、そのディレクトリサーバＤ０１に対して、ｏｂｊ＿ｆｈのファイル属性の作成と、必要なファイル属性情報の読み出しを依頼する（Ｓ４１４、図２（ａ）Ａ０５）。
【００７６】
次に、ネットワークストレージＮ０３は、ディレクトリサーバＤ０１にｄｉｒに対応したディレクトリのファイル属性の更新と必要なファイル属性情報の読み出しを依頼する（Ｓ４１５、図２（ａ）Ａ０５）。そして、応答メッセージを組み立てる（Ｓ４１６）。ここで、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からの応答だと認識するように、ネットワークストレージＮ０３が応答メッセージを組み立て、最後に、Ｓ４１７で組み立てた応答メッセージをクライアントＫ００に送信する（Ｓ４１７、図２（ａ）Ａ０４）。
【００７７】
ｄｉｒが見つからなかった場合には、ｄｉｒのディレクトリのファイル属性を読み出し（Ｓ４２１）、ディレクトリサーバＤ０１がエラーメッセージを組み立てる（Ｓ４２２）。ここで、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からの応答だと認識するように、ディレクトリサーバＤ０１が応答メッセージを組み立てる。最後に、組み立てたエラーメッセージをクライアントＫ００に送信する（Ｓ４２３、図２（ａ）Ａ０４）。
このＣＲＥＴＥ要求の処理では、このＲＥＡＤ／ＷＲＩＴＥ要求の処理の場合と同様に、Ｓ４０２で要求を転送するディレクトリサーバを判定することにより、ディレクトリサーバの負荷分散をおこなうことができる。
【００７８】
さらに、Ｓ４０３で要求を転送する際にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も転送して、Ｓ４１６やＳ４２２であたかもネットワークストレージＮ０１がメッセージを組み立てたかのようにクライアントＫ００に応答するため、クライアントＫ００ではどのネットワークストレージで処理がおこなわれたのかを意識せずともよい。
【００７９】
また、ディレクトリのファイルハンドルごとにファイルの作成やファイル属性を処理するディレクトリサーバが一意に定まるため、ファイル作成やファイル属性更新時に、二つのディレクトリサーバでのデータ整合性を確保することができる。さらに、負荷のかかっていないネットワークストレージを選択してＣＲＥＡＴＥ要求を転送することにより、理想的なネットワークストレージの負荷分散をおこなうことができる。
（ｃ）ＬＯＯＫＵＰプロトコル
ＮＦＳのＬＯＯＫＵＰ要求は、指定したファイル名に対して、そのファイルに関連した情報を返すプロトコルである。すなわち、ファイルハンドルｄｉｒで指定するディレクトリ上に存在するファイル名ｆｎａｍｅのファイルについて、ファイルのファイルハンドルｏｂｊ＿ｆｈ、ファイルの属性ｏｂｊ＿ａｔｔｒ、ディレクトリの属性ｄｉｒ＿ａｔｔｒを返すインターフェースを持つ。
【００８０】
ＬＯＯＫＵＰ要求では、クライアントＫ００がネットワークストレージＮ０１に対して、ファイルハンドルｄｉｒ上にあるファイル名ｆｎａｍｅのファイルについてＬＯＯＫＵＰ要求を発行する（図２（ｂ）Ａ０１）。
【００８１】
ネットワークストレージＮ０１は、このクライアントＫ００からのＬＯＯＫＵＰ要求を受信する（Ｓ５０１、図２（ｂ）Ａ０１）。
【００８２】
このファイルハンドルを基にディレクトリサーバＤ０１、Ｄ０２のどちらに処理を依頼するかを決定する（Ｓ５０２）。この決定の方法は、ＲＥＡＤ／ＷＲＩＴＥのところで述べたのと同様の手法を用いることができる。ここでは、仮にディレクトリサーバＤ０１を選択したとする。
【００８３】
そして、ネットワークストレージＮ０１が、そのディレクトリサーバＤ０１に受信したＬＯＯＫＵＰ要求を転送する（Ｓ５０３、図２（ｂ）Ａ０２）。ここで、クライアントＫ００のＩＰアドレス、ネットワークストレージＮ０１のＩＰアドレス、ＴＣＰやＵＤＰの送受信のポート番号、ＲＰＣのトランザクションＩＤ（ＸＩＤ）、ＲＰＣのプログラム番号、ＲＰＣのバージョン番号、ＲＰＣのプロシージャ番号、ＲＰＣの認証情報と検証情報など、応答メッセージを作成するのに必要な情報の全てを転送する。
【００８４】
転送した要求を受信したディレクトリサーバＤ０１では、ファイルハンドルｄｉｒのエントリ上でファイル名ｆｎａｍｅのファイルが持つファイルハンドルｏｂｊ＿ｆｈを検索する（Ｓ５０４）。ｏｂｊ＿ｆｈが見つかった場合には、Ｓ５１１に進み、見つからなかった場合には、Ｓ５２１に進む。
【００８５】
ｏｂｊ＿ｆｈが見つかった場合には、ｏｂｊ＿ｆｈのファイル属性を読み出し（Ｓ５１１）、ｄｉｒのディレクトリ属性を読み出す（Ｓ５１２）。そして、ディレクトリサーバＤ０１では、これらの情報を使い応答メッセージを組み立てる（Ｓ５１３）。ここで、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からの応答だと認識するように、ディレクトリサーバＤ０１が応答メッセージを組み立てるようにする。最後に、組み立てた応答メッセージをクライアントＫ００に送信する（Ｓ５１４、図２（ｂ）Ｂ０１）。
【００８６】
ｏｂｊ＿ｆｈが見つからなかった場合には、ｄｉｒのディレクトリ属性を読み出し（Ｓ５２１）、エラーメッセージを組み立てる（Ｓ５２２）。ここでｏｂｊ＿ｆｈが見つかった場合と同様に、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からのエラーメッセージだと認識するように、ディレクトリサーバＤ０１がエラーメッセージを組み立てるようにする。最後に、組み立てた応答メッセージをクライアントＫ００に送信する（Ｓ５２３、図２（ｂ）Ｂ０１）。
【００８７】
この要求処理では、処理をおこなうのがディレクトリサーバであり、ネットワークストレージを介さないことに注意する。
【００８８】
ＬＯＯＫＵＰ要求の処理では、Ｓ５０２で要求を転送するサーバを判定することにより、ディレクトリサーバの負荷分散をおこなうことができる。さらに、Ｓ５０３で要求を転送する際にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も転送して、Ｓ５１３やＳ５２２であたかもネットワークストレージＮ０１がメッセージを組み立てたかのようにクライアントＫ００が認識できるようにしたため、クライアントＫ００は、どのディレクトリサーバが応答を返してくるのかを意識せずともよい。
（III）ディレクトリサーバの二重化およびファイル本体とファイル管理情報の格納形態について
これまでの説明では、ディレクトリサーバが二台あり、いずれのディレクトリサーバを使うのかを、ファイルハンドラに従って選択するようにした。本発明のネットワークストレージ仮想化方法では、ディレクトリサーバが一台でも構築することができる。しかしながら、ディレクトリサーバを複数台にすることにより、ファイル管理情報に関する処理について負荷を分散することができる。
【００８９】
また、各々のディレクトリサーバに別々のファイル管理情報を格納しておき、それをファイルハンドラによって、選択する方法をとると、効率的にディレクトリサーバにファイル管理情報を格納することができる。
【００９０】
しかしながら、信頼性を向上するためには、ファイル管理情報を複数のディレクトリサーバに多重化して格納しておくことが望ましい。ファイル管理情報をディレクトリサーバで保持するようにしたときには、あるディレクトリサーバのファイル管理情報が更新されたときには、適切なタイミングで他のディレクトリサーバに連絡をとり、同期をとって更新してファイル管理情報の整合性を維持しておく必要がある。
【００９１】
ここで、ファイル本体のデータについても信頼性を向上させるために、一つのファイルについて多重化して、複数のネットワークストレージに冗長保持することが望ましい。この場合に、あるファイルハンドラに対するファイル管理情報を格納するディレクトリサーバを複数用意して、それぞれのディレクトリサーバでファイル本体を格納している冗長保持している複数のネットワークストレージを管理させるようにすれば、ファイル本体のデータを多重化した場合のファイル管理についても容易に実現することができる。
【００９２】
さらに、本実施形態では、ファイルハンドルとそのファイルハンドルに対応した管理情報をペアで管理するようにした。しかしながら、本発明のネットワークストレージは、ファイルハンドルとファイルハンドルに対応した管理情報とファイルのオフセット情報を一組で管理することにより、一つのファイルを複数のネットワークストレージに分散して格納する方法にも容易に適用することができる。この方法によって、一つのファイルを複数のネットワークストレージに分割して保存することにより、このシステムのデータ格納方法として、 ＺｅｂｒａファイルシステムのようなファイルのストライプやＲＡＩＤ５のようなデータ冗長化手段も採用することができる。
【００９３】
上記のように、複数のディレクトリサーバおよびネットワークストレージを用意して、ファイル管理情報とファイル本体データを冗長化して格納しておけば、あるディレクトリサーバやネットワークストレージに障害が発生したときでも、他方のディレクトリサーバやネットワークストレージを用いることで、容易にフェールオーバを実現することができる。
（IV）通信形態について
本実施形態では、クライアントはＮＦＳプロトコルによりネットワークストレージの一台に要求を送信して、最終的な応答が要求を受信したネットワークストレージとは異なるネットワークストレージから返る場合であっても、最初に要求を受信したネットワークストレージからの応答のように応答メッセージを作成して、クライアントに返すようにした。すなわち、クライアントは、ＮＦＳのような標準プロトコルを用いて、仮想化されたネットワークストレージにアクセスすることができ、特別のプロトコルやソフトウェアを要しない。
【００９４】
もちろん、クライアントとの通信にＮＦＳ以外のプロトコルを用いても、本発明のネットワークストレージ仮想化方法は、容易に実現することができる。
【００９５】
また、本発明のネットワークストレージ仮想化方法では、ネットワークストレージとディレクトリサーバ間の通信は、クライアント側に見せる必要がないため、クライアントを接続したＬＡＮとは、別のＬＡＮを構築して、そのＬＡＮを用いて通信することにより、クライアントを接続したＬＡＮの通信帯域を節約することができる。
（V）システムの拡張性について
本発明のネットワークストレージ仮想化方法では、ネットワークストレージがファイルの本体データの保存をおこない、ディレクトリサーバがファイルの管理情報を保存する。このためシステム全体のディスク容量を増設するには、新しいネットワークストレージをネットワークに接続するだけで良く、ファイル管理情報の配置を変更する必要がないので、変更のための手間がかからず、ネットワークストレージの増設の際の管理コストが小さくすることができる。また、減設の場合も同様にファイル管理情報の配置を変更する必要がないので、ネットワークストレージの減設の際の管理コストを小さくすることかできる。
【００９６】
〔実施形態２〕
次に、図６を用いて本発明に係る第二の実施形態について説明する。
図６は、本発明に係る第二の実施形態の処理の流れを示す模式図である。
【００９７】
本実施形態は、第一の実施形態の機能を拡張して、クライアントからネットワークストレージにファイルアクセスの要求処理を出すときに、同じファイルを二回目にアクセスするときに、処理性能を上げようとするものである。
【００９８】
図６（ａ）は、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）に一回目の処理の依頼がきたときの流れ図であり、Ａ０１〜Ａ０４までの処理については、第一の実施形態と同様である。
【００９９】
異なるのは、ディレクトリサーバＤ０１は、ファイルの格納されているネットワークストレージＮ０３（第二のネットワークストレージ）に要求を転送（Ａ０３）するのと同時にネットワークストレージＮ０１に、ファイルがネットワークストレージＮ０３に格納されていることを、例えば、ファイル識別子とネットワークストレージ識別子の対という形態で通知することである（Ｇ０１）。
【０１００】
このときに、ネットワークストレージＮ０１とネットワークストレージＮ０３は、並列に動作しているので、システムとして、それほど処理性能が低下することもない。
【０１０１】
ネットワークストレージＮ０１では、そのファイル識別子とネットワークストレージ識別子の対応を、キャッシュファイルとして一時記憶用領域に保存しておく。
【０１０２】
この状態にあるとき、図６（ｂ）に示されるようにクライアントＫ００から同じファイルに対してファイルアクセスの要求がネットワークストレージＮ０１に発せられたとする。
【０１０３】
このときに、ネットワークストレージＮ０１は、先ず、そのファイルに対応しているファイル識別子とネットワークストレージ識別子の対応が一時記憶用領域の中にないかを検索する。そして、見つかったときには、ネットワークストレージＮ０２に直接要求を転送する（Ｈ０２）。そのあと、ネットワークストレージＮ０２で、要求を処理してクライアントに応答する（Ａ０４）ことは、第一の実施形態と同様である。見つからなかったときには、図６（ａ）の場合と同様に、該当するディレクトリサーバＤ０１を選択して、それに要求を転送する（Ａ０２）。
【０１０４】
この実施形態によれば、一時記憶用領域の中に既にアクセスしたファイルの関連情報が記憶されているときには、ディレクトリサーバＤ０１を経由せずに、ネットワークストレージＮ０２に直接要求を転送することができるので、処理性能を大幅に向上させることができる。
【０１０５】
〔実施形態３〕
次に、図７を用いて本発明に係る第三の実施形態について説明する。
図７は、本発明に係る第三の実施形態の処理の流れを示す模式図である。
【０１０６】
第一の実施形態では、ファイル管理情報は、もっぱらディレクトリサーバが管理していた。ディレクトリサーバの数が少なく、かつ、多くのＲＥＡＤ／ＷＲＩＴＥ要求が発生して、一時に大量のファイル管理情報を更新しなければならなくなったときに、ディレクトリサーバに負荷がかかり、システムの性能のボトルネックになるおそれがある。
【０１０７】
本実施形態では、そのような事態を防止できるように、個々のネットワークストレージに対して、ファイル管理もおこなえるように、ディレクトリサーバ機能を持たせたものである。ディレクトリサーバは、第一の実施形態と同様に、ファイル管理情報を全て保持する。そして、各ネットワークストレージに、ファイル管理情報を分割して、コピーする。分割するときの手法としては、ファイルハンドルを用いて、ネットワークストレージと対応付ける評価関数を用いることができる。例えば、ファイルハンドルのバイト表現の剰余を計算する評価関数がある。この評価関数を用いた場合には、Ｎ台のネットワークストレージがあるとすると、各ネットワークストレージに０からＮ−１までの識別子を割り振り、ファイルハンドルのＮの剰余を計算し、剰余の値に対応した識別子を持つネットワークストレージにそのファイルハンドルに対応するファイル管理情報を格納する。
【０１０８】
このように分類したファイル管理情報を対応するネットワークストレージにコピーすることで、ファイル管理情報を重複することなく各ネットワークストレージの記憶装置に分割してコピーすることができる。
【０１０９】
この処理では、先ず、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）にＬＡＮ経由で、ＲＥＡＤ／ＷＲＩＴＥ要求のファイルアクセス要求を発する（Ａ０１）。
【０１１０】
本実施形態では、各々のネットワークストレージにディレクトリサーバ機能が付加されているために、ディレクトリサーバとネットワークストレージの両方がファイル管理情報に対する処理をおこなうことができる。
【０１１１】
第一の実施形態では、要求を転送するのは、ディレクトリサーバのみであったが、本実施形態では、要求を転送する候補として、ディレクトリサーバとネットワークストレージの二通りがあることに注意する必要がある。
【０１１２】
図７（ａ）は、ネットワークストレージＮ０２（第二のネットワークストレージが選択されたものとする。ＲＥＡＤ／ＷＲＩＴＥプロトコルのときには、例えば、上記のようにファイルハンドルの剰余を求めることにより、ネットワークストレージＮ０２を選択することができる。
【０１１３】
そして、ネットワークストレージＮ０１は、ネットワークストレージＮ０２に受信した要求を転送する（Ｃ０２）。
【０１１４】
このときに、ネットワークストレージＮ０１は、クライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報も同時に転送する。
【０１１５】
ネットワークストレージＮ０２では、転送された要求に含まれているファイルハンドルからファイル管理情報を検索して、ファイル管理情報の示すファイル本体データを格納しているネットワークストレージＮ０３（第三のネットワークストレージ）に転送する（Ｃ０３）。このときにも、クライアントと第一のネットワークストレージＮ０１のＩＰアドレスなども転送するのは、Ｃ０２のときと同様である。
【０１１６】
ネットワークストレージＮ０３では、転送された要求に含まれるファイルハンドルに対応するファイル本体データに対して要求された処理をおこない、結果をクライアントＫ００に応答する（Ａ０４）。
【０１１７】
応答を返すとき、ネットワークストレージＮ０３は、転送されてきたクライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報を用い、あたかも、ネットワークストレージＮ０１が要求を処理したようなパケットを組み立てる。クライアントＫ００側では、どのネットワークストレージが処理をしたのかを一切意識する必要がないのは、第一の実施形態と同様である。
【０１１８】
そして、最後に、ファイルのアクセス時刻の更新などファイル管理情報が更新されるので、この情報をディレクトリサーバＤ０１とネットワークストレージＮ０２に送信して（Ａ０５）、ディレクトリサーバＤ０１とネットワークストレージＮ０２上のファイル管理情報を書き換える。
【０１１９】
これにより、ネットワークストレージ上のファイル管理情報とディレクトリサーバ上のファイル管理情報とは、整合性が保たれる。
【０１２０】
またこのとき、多数のファイルにＲＥＡＤ／ＷＲＩＴＥ要求が発生する場合や同一のファイルに対して頻繁にＲＥＡＤ／ＷＲＩＴＥ要求が発生する場合には、上記の手法では、毎回ディレクトリサーバが多数のファイル管理情報の更新要求パケットを受信することになるため、ディレクトリサーバに負荷がかかりすぎるおそれがある。
【０１２１】
そのために、ネットワークストレージ上で、ディレクトリサーバに送信すべきファイル管理情報を蓄積しておき、適切な時期に、まとめてディレクトリサーバ上のファイル管理情報を更新するようにすればよい。すなわち、複数のファイル管理情報の更新要求パケットをまとめて、一つの更新要求パケットにすることにより通信量を減らし、しかも、同一ファイルのファイル管理情報を頻繁に更新する場合には、最終結果のみが更新要求パケットとして送られるので、ディレクトリサーバのファイル管理情報の更新処理を減らすことができる。
【０１２２】
図７（ａ）に示した処理では、クライアントＫ００の要求がＲＥＡＤ／ＷＲＩＴＥ要求のように、要求のインタフェースにファイルハンドルを含んでいて、それにより、ファイル管理情報を格納している第二のネットワークストレージＮ０２を選択した。
【０１２３】
次に、ＣＲＥＡＴＥ要求のように、クライアントＫ００の要求がインタフェースにファイルハンドルを含んでいない処理が発せられたものとする。
【０１２４】
この処理では、図７（ｂ）に示されるように、先ず、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）にＬＡＮ経由で、ＣＲＥＡＴＥ要求を発する（Ａ０１）。
【０１２５】
このときに、ネットワークストレージＮ０１は、ネットワークストレージではなく、必ずディレクトリサーバを選択することになる。そして、ディレクトリサーバＤ０１に要求を転送する（Ｅ０２）。また、ネットワークストレージＮ０１が、クライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報も同時に転送するのは、図７（ａ）のときと同様である。
【０１２６】
要求を受信したディレクトリサーバＤ０１は、新規ファイルハンドルと新規ファイル管理情報を作成し、例えば、ファイルハンドルの剰余から新規ファイル管理情報をコピーするネットワークストレージＮ０３（第三のネットワークストレージ）を求めて、それに対して新規ファイルの作成要求とファイル管理情報の格納要求を送信する（Ｅ０３）。なお、新規ファイルの作成要求はネットワークストレージＮ０３以外の任意のネットワークストレージに対して送信してよい。
【０１２７】
ネットワークストレージＮ０３は、要求に応じて、新規ファイルを作成して、ファイル管理情報を格納した後に、クライアントＫ００に要求の応答を返す（Ａ０４）。また、応答を返すとき、ネットワークストレージＮ０３は、転送されてきたクライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報を用い、あたかも、ネットワークストレージＮ０１が要求を処理したようなパケットを組み立てるのは、図７（ａ）の場合と同様である。
【０１２８】
そして、ネットワークストレージＮ０３上のファイル管理情報を更新し、この情報をディレクトリサーバＤ０１上に送信して（Ａ０５）、ディレクトリサーバＤ０１上のファイル管理情報を書き換えて、ネットワークストレージ上のファイル管理情報とディレクトリサーバ上のファイル管理情報との整合性が保つようにする。
【０１２９】
なお、図７に示したようなシステム形態で、新規にネットワークストレージを増設する際には、ディレクトリサーバのファイル管理情報のデータ更新が終了した後に、新規ネットワークストレージを含めてネットワークストレージに識別子を割り当て、ファイル管理情報の分割とネットワークストレージへのコピーを再びおこなうようにする。
【０１３０】
本実施形態では、上記のように、ネットワークストレージにディレクトリサーバ機能を持たせることにより、ファイル管理情報に関する処理の負荷を分散させ、処理の並列性を増すことにより、より高いスループットを達成することができる。また、ファイル管理情報がネットワークストレージにディレクトリサーバとに、二重化して保持されているために、システムの信頼性が高まり、いずれかのネットワークストレージやディレクトリサーバに障害がおこったときであっても、ファイル管理情報を喪失するのを防ぐことができ、継続してシステム運用をおこなえるという特徴がある。
【０１３１】
〔実施形態４〕
次に、図８を用いて本発明に係る第四の実施形態について説明する。
図８は、本発明に係る第四の実施形態の処理の流れを示す模式図である。
【０１３２】
第一の実施形態は、第一のネットワークストレージがクライアントから要求を受信して、その要求をディレクトリサーバに転送した。しかしながら、ＷＲＩＴＥ要求などで書き換える容量が大きいときには、そのパケットも大きくなり、ディレクトリサーバに転送すると、ディレクトリサーバに負荷がかかり、ネットワーク帯域も圧迫する恐れがある。
【０１３３】
本実施形態では、第一のネットワークストレージは、ディレクトリサーバに対して、ファイルアクセスの要求を転送すべきネットワークストレージを問い合わせて、その返答にしたがって、その要求を転送するものである。通常、問い合わせパケットは、ＷＲＩＴＥ要求のパケットに比べて、小さいので、ディレクトリサーバに負担がかからず、ネットワーク上に流れるパケット量を少なくすることができる。
【０１３４】
この処理では、先ず、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）にＬＡＮ経由でファイルアクセス要求を発する（Ａ０１）。
【０１３５】
ネットワークストレージＮ０１は、そのファイルのファイル管理情報を格納されているディレクトリサーバＤ０１を選択して、それに対してファイル本体の格納されているネットワークストレージの問い合わせ要求をおこなう（Ｆ０１）。
【０１３６】
ディレクトリサーバＤ０１は、問い合わせ要求の中に含まれるファイルハンドルからそのファイルの格納されているネットワークストレージを検索して、該当するネットワークストレージは、ネットワークストレージＮ０３（第二のネットワークストレージ）であることを返答する（Ｆ０２）。
【０１３７】
ネットワークストレージＮ０１は、これを受信して、ネットワークストレージＮ０３に要求を転送する（Ｆ０３）。
【０１３８】
ネットワークストレージＮ０３では、要求を処理して応答をクライアントＫ００に返し（Ａ０４）、ディレクトリサーバのファイル管理情報を更新する（Ａ０５）ことは、第一の実施形態と同様である。
【０１３９】
問い合わせの結果は、ファイル識別子とネットワークストレージの識別子の対応として、第一のネットワークストレージＮ０１のキャッシュファイルなどの一時記憶領域に格納しておく。そして、おなじファイルに対してアクセス要求があったときには、一時記憶領域の情報を検索して、見つかったときには、ただちに、そのファイルの格納されているネットワークストレージに要求を転送する。この流れは、図６（ｂ）で示したものと同様である。
【０１４０】
【発明の効果】
本発明によれば、ＮＦＳなどの標準プロトコルを用いてアクセス可能なネットワークストレージ仮想化方法を提供することができる。
【０１４１】
また、ネットワークストレージの増設や減設の際の管理コストが小さいネットワークストレージ仮想化方法を提供することができる。
【０１４２】
また、ファイル管理情報を冗長化することで障害発生時にも継続して運用可能なネットワークストレージ仮想化方法を提供することである。
【０１４３】
さらに、クライアントからの要求を受信するネットワークストレージと、要求の処理をおこないクライアントに応答を返すネットワークストレージとが異なる場合でも、クライアントでは、そのことを意識せずとも、ネットワークストレージへの要求をおこなうことのできるネットワークストレージ仮想化システムを提供することができる。
【図面の簡単な説明】
【図１】本発明のネットワークストレージシステムのシステム構成図である。
【図２】本発明に係る第一の実施形態の処理の流れを示す模式図である。
【図３】クライアントからＲＥＡＤ／ＷＲＩＴＥ要求がされたときの処理を示すＰＡＤ（Problem Analysis Diagram）図である。
【図４】クライアントからＣＲＥＡＴＥ要求がされたときの処理を示すＰＡＤ図である。
【図５】クライアントからＬＯＯＫＵＰ要求がされたときの処理を示すＰＡＤ図である。
【図６】本発明に係る第二の実施形態の処理の流れを示す模式図である。
【図７】本発明に係る第三の実施形態の処理の流れを示す模式図である。
【図８】本発明に係る第四の実施形態の処理の流れを示す模式図である。
【符号の説明】
Ｋ００…クライアント
１００…ＬＡＮ
Ｎ０１〜Ｎ０４…ネットワークストレージ
Ｄ０１，Ｄ０２…ディレクトリサーバ
【発明の属する技術分野】
本発明は、ネットワークストレージ仮想化システムに係り、ネットワークに直付けされるネットワークストレージを仮想化することにより、クライアントからのネットワークストレージのアクセスを容易にして、システムの構築、運用を柔軟におこなうことのできるネットワークストレージ仮想化システムに関する。
【０００２】
【従来の技術】
従来の情報処理システムでは、計算機システムに直接接続したハードディスクドライブなどのストレージに情報を格納していた。ストレージに格納した情報は、ストレージを直接接続した計算機からのみアクセス可能なため、他の計算機システムから情報にアクセスするためには、ストレージを直接接続した計算機を経由する必要があった。
【０００３】
しかしながら、近年のネットワーク技術の発達と格納すべき情報量の飛躍的な増大により、情報を処理する計算機システムと情報を格納するストレージシステムの分離の動きが進んでいる。その結果、ネットワークに接続し複数の計算機システム間で情報を共有できるストレージシステムが出現してきた。このようなネットワークに接続するストレージをネットワークストレージと呼ぶ。
【０００４】
このようなネットワークストレージの例として、ＳＡＮ（Storage Area Network）で接続してブロックアクセスを提供するＳＡＮストレージ、ＩＰネットワークやＩｎｆｉｎｉｂａｎｄなどで接続してファイルアクセスを提供するＮＡＳ（Network Attached Storage）、ＷｅｂアクセスのインタフェースであるＨＴＴＰプロトコルやそれを拡張したプロトコルでのアクセス形態を提供するＷｅｂストレージなどがある。
【０００５】
ネットワークストレージの普及につれ、システム管理者は、ネットワークに接続した複数のネットワークストレージを管理する必要が生じてきた。例えば、格納すべきデータ量が既存のネットワークストレージの最大値を越えるような場合には、新たなネットワークストレージを追加し、データの再分配などのシステム再構築が必要になる。ストレージ容量に対する需要の急激な伸びは、度重なるシステム再構築を強いるためシステム管理コストを膨張させてきた。
【０００６】
システム管理コストの抑制には、複数のネットワークストレージを計算機システムからは仮想的に一つに見せ、新たな装置の追加を行なってもシステム全体に影響が及ばないようにするストレージ仮想化技術が必須となっている。このようなストレージ仮想化技術に関しては各種方式が開発され提案されている。
【０００７】
例えば、１９９５年にＨａｒｔｍａｎらが発表したＺｅｂｒａ（例えば、非特許文献１参照）では、一つのファイルをストライピングして複数のネットワークストレージに分散格納する方式を提案している。この方式では、ファイルを一定の長さごとに分割し、ネットワークストレージにラウンド・ロビン方式で順次格納する。Ｚｅｂｒａでは、ファイルがどのストレージにどのような順番で分散格納しているか集中管理するサーバがあり、ファイルアクセス処理時にはこの管理サーバにファイルの格納位置に関する情報を問い合わせてからファイルの本体データにアクセスするという特徴がある。すなわち、Ｚｅｂｒａでは、ファイルを複数のサーバに分散格納させて一つのサーバで集中管理することにより、複数のネットワークストレージを仮想的に一つの大きいネットワークストレージに見せている。
【０００８】
また、特許文献１では、Ａｌｅｘａｎｄｅｒ Ｈ． Ｆｒｅｙらは、Ｚｅｂｒａの集中管理サーバ方式と異なる非集中管理サーバ方式によりファイルのストライピングを行なう方式を提案している。この方式では、ファイルのストライピング情報が格納されているスタータノード情報をファイル識別子に埋め込むことで、Ｚｅｂｒａで集中管理していたストライピング情報を複数のネットワークストレージで分散管理している。ファイル識別子にスタータノードを格納するため、クライアントがファイルアクセスする際には、まずスタータノードへアクセスをおこない、そこでファイルの格納位置を決定し、必要があればアクセスすべきファイルの断片（ブロック）を格納しているサーバへアクセス要求を転送して処理することになる。このため、クライアントからの当該ファイルについてのアクセスは、スタータノードへ要求を発行するだけで良く、ファイルのストライピングによる格納位置を考慮する必要がないという利点がある。
【０００９】
また、特許文献２の「分散ファイル管理装置及び分散ファイル管理システム」では、複数のサーバ計算機に状態管理部を設け、負荷情報を保持して負荷を管理し、記憶装置に、分散ファイルの一部または全部を構成する部分ファイルを記憶して、分散ファイルの部分ファイルを特定し、状態管理部で管理する負荷情報に基づき部分ファイルを処理するサーバ計算機を決定するようにする。これにより特定のサーバへの負荷の集中を防ぐことができる。
【００１０】
【非特許文献１】
The Zebra Striped Network File System, Hartman et. al., ACM Transactions on ComputerSystem, Vol. 13, No. 3, 1995, pp. 274-310.
【特許文献１】
米国特許第６，０２９，１６８号明細書
【特許文献２】
特開２０００―２０７３７０号公報
【００１１】
【発明が解決しようとする課題】
上記従来技術のＺｅｂｒａでは、ファイルを分散していても、ユーザはそれらの詳細情報を保持していなくてもアクセスできる利点がある。しかしながら、前記Ｚｅｂｒａでは、アクセスするファイルの断片を格納するネットワークストレージを決定する際に、集中管理サーバに問い合わせる必要があり、特にファイルの更新ではネットワークストレージ上のデータの他に集中管理サーバ上のデータも更新する必要がある。このため、ネットワークストレージの台数が増加すると集中管理サーバがボトルネックとなり、システムのスケーラビリティを阻害する要因となっている。さらに、Ｚｅｂｒａでは専用のクライアントが必要となるため、ＮＦＳなどの標準プロトコルに適用できない問題がある。
【００１２】
また、特許文献１の非集中管理サーバ方式では、管理サーバが複数のサーバに分散されている点では、集中管理サーバがボトルネックになるというＺｅｂｒａの問題点を解決している。しかしながら、このシステムではファイルアクセスする際にファイルを一意に特定するファイル名あるいはディレクトリ名とスタータノードが埋め込まれているファイル識別子との変換を分散ディレクトリ等のサーバがおこなうことが前提となっており、ファイルの格納場所を管理するサーバとファイル名との対応を管理する情報が別途必要となっている。特許文献１の実施例ではそのような情報を格納する手段としてａ ″ｗｅｌｌ−ｋｎｏｗｎ″ ｄｉｓｔｒｉｂｕｔｅｄ ｄｉｒｅｃｔｏｒｙ ｆｉｌｅを利用すると述べている。また、ファイル識別子にスタータノードの位置を直接埋め込むため、新しいネットワークストレージを追加して既存のファイルのスタータノードを新しいネットワークストレージに移動する際には、分散ディレクトリに格納されているファイル名とファイル識別子との対応情報を書き換える必要がある。このため、新規ネットワークストレージ増設の際の管理コストが増大する問題がある。
【００１３】
また、特許文献２に記載の発明では、複数サーバ間での負荷、特にディスクやネットワークへの負荷の分散に主眼を置いているが、分散ファイル管理手段の冗長化を考慮していないため、障害発生時にアクセスが不能になる問題がある。
【００１４】
本発明は、上記問題点を解決するためになされもので、その第一の目的は、ＮＦＳなどの標準プロトコルを用いてアクセス可能なネットワークストレージ仮想化方法を提供することである。
【００１５】
また、本発明の第二の目的は、ネットワークストレージの増設や減設の際の管理コストが小さいネットワークストレージ仮想化方法を提供することである。
【００１６】
また、本発明の第三の目的は、ファイル管理情報を冗長化することで障害発生時にも継続して運用可能なネットワークストレージ仮想化方法を提供することである。
【００１７】
さらに、本発明の第四の目的は、クライアントからの要求を受信するネットワークストレージと、要求の処理をおこないクライアントに応答を返すネットワークストレージとが異なる場合でも、クライアントでは、そのことを意識せずとも、ネットワークストレージへの要求をおこなうことのできるネットワークストレージ仮想化システムを提供することである。
【００１８】
【課題を解決するための手段】
本発明のネットワークストレージ仮想化方法は、上記目的を達成するため以下のようにする。
【００１９】
ネットワークストレージ仮想化システムにファイル管理情報を保存するディレクトリサーバを設け、クライアントからネットワークストレージにアクセス要求があったときに、クライアントからの要求を第一のネットワークストレージが受信し、第一のネットワークストレージが受信した要求をディレクトリサーバに転送する。そして、ディレクトリサーバは、ファイル管理情報を基に要求を処理するネットワークストレージとして第二のネットワークストレージを選択して、その第二のネットワークストレージに要求を転送する。
【００２０】
第二のネットワークストレージでは、要求を処理して、要求を処理した結果を要求の応答としてクライアントに送信するようにする。
【００２１】
また、ディレクトリサーバが複数あるときには、受信した要求を転送するためのディレクトリサーバを選択するようにする。
【００２２】
このときに、第二のネットワークストレージは、要求を処理したのは、第一のネットワークストレージであるように見せかけた応答を処理結果に含ませて返すようにする。したがって、クライアントでは、どのネットワークストレージが処理をおこなったかを意識せずともよい。
【００２３】
また、前記ディレクトリサーバが要求を処理するネットワークストレージとして第二のネットワークストレージを選択したことを、第一のネットワークストレージに通知するようにしてもよい。このようにして、第一のネットワークストレージに通知内容を保存しておけば、二回目に第一のネットワークストレージに同じファイルにアクセスがあったときに、直接、その要求を第二のネットワークストレージに転送することができる。
【００２４】
また、ディレクトリサーバの有するファイル管理情報を分割して複数のネットワークストレージにも保存するようにして、クライアントからネットワークストレージにアクセス要求があったときに、クライアントからの要求を受信した第一のネットワークストレージでは、要求を転送するディレクトリサーバまたは第二のネットワークストレージを選択して、選択したディレクトリサーバまたは前記第二のネットワークストレージに、要求を転送するようにする。
【００２５】
選択されたディレクトリサーバまたは第二のネットワークストレージでは、要求を処理する第三のネットワークストレージに要求を転送して、第三のネットワークストレージに処理をおこなわせる。
【００２６】
ディレクトリサーバとネットワークストレージに分割して保存されるファイル管理情報は、整合性を維持して保存しておく必要がある。
【００２７】
このようにすれば、ファイル管理情報が分散して管理されるため、冗長度が増し、システムの安全度を高めることができる。
【００２８】
また、クライアントからネットワークストレージにアクセス要求があったときに、要求を受信したネットワークストレージで、ディレクトリサーバに対して前記受信した要求を処理するネットワークストレージを問い合わせて、通知させ、要求を受信したネットワークストレージで、要求を処理するネットワークストレージに転送するようにしてもよい。
【００２９】
このネットワークストレージ仮想化方法では、標準のプロトコルでシステムを構築することができ、クライアントに特別なプロトコルや仕様を意識させることはない。また、ファイルの容量増加したときなどのシステムの増設などもネットワークストレージを追加することにより簡単におこなうことができる。
【００３０】
さらに、ファイル管理情報を分散管理されているために、システムの安全性が高まっており、一部のディレクトリサーバやネットワークストレージに障害がおこっても継続運転することが可能である。
【００３１】
【発明の実施の形態】
以下、本発明に係る各実施形態を、図１ないし図８を用いて説明する。
【００３２】
〔本発明のネットワークストレージシステムのシステム構成〕
先ず、図１を用いて本発明のネットワークストレージシステムのシステム構成について説明する。
図１は、本発明のネットワークストレージシステムのシステム構成図である。
【００３３】
本発明のネットワークストレージは、クライアントＫ００と、ネットワークストレージＮ０１〜Ｎ０４およびディレクトリサーバＤ０１、Ｄ０２とをＬＡＮ１００により接続する。
【００３４】
クライアントＫ００は、サーバに対してファイルの読み書き、ファイル管理情報取得などのファイルアクセス要求をおこなう。
【００３５】
ネットワークストレージＮ０１〜Ｎ０４は、ネットワークに直接接続されているストレージデバイスであり、ファイルの本体データを格納する。
【００３６】
ディレクトリサーバＤ０１、Ｄ０２は、ファイル属性やファイル本体データを格納しているネットワークストレージの情報などからなるファイルの管理情報を格納する。
【００３７】
なお、この図１の例では、ネットワークストレージが三台、ディレクトリサーバが二台であるが、ネットワークストレージは、システムの規模に応じて何台でも増設してもよいし、ディレクトリサーバは、ファイル管理情報の容量、サーバの性能などに従って適切な台数を設けることができる。
【００３８】
〔実施形態１〕
次に、図２ないし図５を用いて本発明に係る第一の実施形態について説明する。
図２は、本発明に係る第一の実施形態の処理の流れを示す模式図である。
図３は、クライアントからＲＥＡＤ／ＷＲＩＴＥ要求がされたときの処理を示すＰＡＤ（Problem Analysis Diagram）図である。
図４は、クライアントからＣＲＥＡＴＥ要求がされたときの処理を示すＰＡＤ図である。
図５は、クライアントからＬＯＯＫＵＰ要求がされたときの処理を示すＰＡＤ図である。
【００３９】
本実施形態では、ＲＦＣ１８１３（NFS Version3 Protocol Specification）に記載のＮＦＳのプロトコルを使いクライアントＫ００が通信する場合のネットワークストレージの仮想化方法について説明する。ＮＦＳ（Network File System）は、ＴＣＰ／ＩＰ環境下で標準的に使用される分散分散ファイルシステムである。以下では、ＮＦＳの代表的なプロトコルであるＲＥＡＤ、ＷＲＩＴＥ、ＣＲＥＡＴＥ、ＬＯＯＫＵＰを例にしてネットワーク仮想化方法の動作を説明するが、その他のＮＦＳのプロトコルについても、同様に考えることができる。
（Ｉ）ネットワークストレージ仮想化方法の処理の概要
先ず、図２により本発明のネットワークストレージ仮想化方法の処理の概要について説明する。
【００４０】
図２（ａ）は、クライアントからの要求がファイル本体とファイル管理情報の両方にアクセスする場合であり、ＲＥＡＤ、ＷＲＩＴＥ、ＣＲＥＡＴＥなどのプロトコルがこれに該当する。
【００４１】
この処理では、先ず、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）にＬＡＮ経由でファイルアクセス要求を発する（Ａ０１）。ファイルの管理情報は、ディレクトリサーバに格納されているため、ネットワークストレージＮ０１では、そのファイルのファイル管理情報を格納されているディレクトリサーバＤ０１を選択して、その要求を転送する（Ａ０２）。
【００４２】
このときに、ネットワークストレージＮ０１は、転送されてきたクライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報を転送する。
【００４３】
ディレクトリサーバＤ０１は、そのファイルの格納されているネットワークストレージを検索して、転送されてきたクライアントと第一のネットワークストレージＮ０１のＩＰアドレスなどの情報と共に、該当するネットワークストレージＮ０３（第二のネットワークストレージ）に要求を転送する（Ａ０３）。
【００４４】
ネットワークストレージＮ０３では、受信した要求を処理して、クライアントＫ００に応答を返す（Ａ０４）。このとき、ファイルアクセス時刻などのファイル管理情報の更新処理などのために、ディレクトリサーバＤ０１に対してファイル管理情報の読み出しや更新をおこなう（Ａ０５）。
【００４５】
ここで重要なことは、処理をおこなう第二のネットワークストレージＮ０３は、要求を処理したのは、第一のネットワークストレージＮ０１であるように見せかけるようにすることである。すなわち、第二のネットワークストレージＮ０３に、クライアントと第一のネットワークストレージＮ０１のＩＰアドレスなどの情報が転送されるので、第二のネットワークストレージＮ０３の応答パケットに第一のネットワークストレージＮ０１のＩＰアドレスを含めて、クライアントＫ００でファイルアクセスの要求を出したセッションを引き継げるようにする。
【００４６】
このようにすれば、クライアントＫ００からみると、どのネットワークストレージが要求を処理するかを意識せずともよい。
【００４７】
図２（ｂ）は、クライアントからの要求がファイル管理情報のみにアクセスする場合であり、例えば、ＬＯＯＫＵＰなどのプロトコルがこれに該当する。
【００４８】
この処理では、先ず、クライアントＫ００は、システム上の任意のネットワークストレージＮ０１にＬＡＮ経由でファイルアクセス要求を発する（Ａ０１）。ファイルの管理情報は、ディレクトリサーバに格納されているため、ネットワークストレージＮ０１では、そのファイルのファイル管理情報を格納しているディレクトリサーバＤ０１を選択して、その要求を転送する（Ａ０２）。
【００４９】
ディレクトリサーバＤ０１は、受信した要求を処理して、クライアントＫ００に応答を返す（Ａ０４）。
【００５０】
このタイプの要求は、ファイル管理情報のみのアクセスであるため、ディレクトリサーバだけで処理することができる。
（II）ネットワークストレージ仮想化方法の処理の詳細
次に、図３ないし図５を用いて各プロトコル毎に本発明のネットワークストレージ仮想化方法の処理の詳細について説明する。
（ａ）ＲＥＡＤ／ＷＲＩＴＥプロトコル
ＮＦＳのＲＥＡＤ／ＷＲＩＴＥ要求は、ファイルに対して読み書きをおこなうプロトコルである。また、ファイルハンドルｆｉｌｅで指定するファイルについて、ファイルに対して読み書きをおこなって、ファイルの属性を返すインタフェースを持つ。
【００５１】
なお、ファイルハンドルとは、ＮＦＳでファイルに対する情報を取り扱うための識別子である。
【００５２】
先ず、クライアントＫ００がネットワークストレージＮ０１に対して、ファイルハンドルｆｉｌｅに対するＲＥＡＤ／ＷＲＩＴＥ要求を発行する（図２（ａ）Ａ０１）。
【００５３】
ネットワークストレージＮ０１は、クライアントＫ００からのＲＥＡＤ／ＷＲＩＴＥ要求を受信する（Ｓ３０１）。ＮＦＳではファイルハンドルは最大６４バイトの可変長の値である。
【００５４】
ディレクトリサーバは、このシステムでは二台あるので、このファイルハンドルを基にディレクトリサーバＤ０１、Ｄ０２のどちらに処理を依頼するかを決定する必要がある。この決定の方法には、例えば、ラウンドロビンでディレクトリサーバを交互に切り替える方法や、ファイルハンドルの２の剰余でディレクトリサーバを決定する方法がある。以降では、剰余によりディレクトリサーバを決定するものとして説明する。剰余が０（ファイルハンドルの最下位ビットが０）の場合ディレクトリサーバＤ０１を選択し、剰余が１（ファイルハンドルの最下位ビットが１）の場合ディレクトリサーバＤ０２を選択する。ここでは仮にディレクトリサーバＤ０１を選択したとする（Ｓ３０２）。
【００５５】
剰余によってディレクトリサーバを選択することにより、例えば、ファイル属性を変更する場合には、特定のファイルハンドルを処理するディレクトリサーバを一意に指定できるため、二つのディレクトリサーバで同一のファイルハンドルについてファイル属性を変更し、データの整合性が取れなくなる事態を回避することができる。
【００５６】
もちろん、このようなディレクトリサーバの選択にファイルハンドルの剰余を用いる方法のほかに、ファイルハンドルとディレクトリサーバを一対一に結びつける任意の手段を用いることができる。
【００５７】
次に、ネットワークストレージＮ０１がディレクトリサーバＤ０１に対して受信したＲＥＡＤ／ＷＲＩＴＥ要求を転送する（Ｓ３０３、図２（ａ）Ａ０２）。ここで、クライアントＫ００のＩＰアドレス、ネットワークストレージＮ０１のＩＰアドレス、ＴＣＰやＵＤＰの送受信のポート番号、ＲＰＣのトランザクションＩＤ（ＸＩＤ）、ＲＰＣのプログラム番号、ＲＰＣのバージョン番号、ＲＰＣのプロシージャ番号、ＲＰＣの認証情報と検証情報など、応答メッセージを作成するのに必要な情報の全てを転送する。
【００５８】
転送した要求を受信したディレクトリサーバＤ０１では、ファイルハンドルｆｉｌｅを検索し（Ｓ３０４）、実際に存在するファイルハンドルであるか否かを確認する。ｆｉｌｅが見つかった場合には、Ｓ３１１に進み、見つからなかった場合には、Ｓ３２１に進む。
【００５９】
ｆｉｌｅが見つかった場合には、先ず、ｆｉｌｅに対応したファイルの本体データを保持するネットワークストレージを検索する（Ｓ３１１）。ここではネットワークストレージＮ０３がファイルの本体データを保持しているとする。このネットワークストレージＮ０３にＲＥＡＤ／ＷＲＩＴＥ要求を転送する（Ｓ３１２、図２（ａ）Ａ０３）。
【００６０】
ここでも先ほどと同様にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も同時に転送する。
【００６１】
この要求を受けたネットワークストレージＮ０３では、ｆｉｌｅに対応したファイルの本体データをＲＥＡＤ／ＷＲＩＴＥする（Ｓ３１３）。
【００６２】
ファイルをＲＥＡＤ／ＷＲＩＴＥするとアクセス時刻などのファイルの属性を更新する必要がある。そこで、ディレクトリサーバＤ０１にｆｉｌｅのファイル属性の更新と、必要なファイル属性情報の読み出しを依頼する（Ｓ３１４、図２（ａ）Ａ０５）。そして、応答メッセージを組み立てる（Ｓ３１５）。ここで、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からの応答だと認識するように、ネットワークストレージＮ０３が応答メッセージを組み立てる。最後に、組み立てた応答メッセージをクライアントＫ００に送信する（Ｓ３１６、図２（ａ）Ａ０４）。
【００６３】
ｆｉｌｅが見つからなかった場合には、ｆｉｌｅのファイル属性を読み出し（Ｓ３２１）、エラーメッセージを組み立てる（Ｓ３２２）。ここでｆｉｌｅが見つかった場合と同様に、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からのエラーメッセージだと認識するように、ディレクトリサーバＤ０１がエラーメッセージを組み立てる。最後に、組み立てたエラーメッセージをクライアントＫ００に送信する（Ｓ３２３、図２（ａ）Ａ０４）。
【００６４】
このＲＥＡＤ／ＷＲＩＴＥ要求の処理では、Ｓ３０２で要求を転送するディレクトリサーバを選択して要求を転送していることにより、ディレクトリサーバの負荷分散をおこなうことができる。さらに、Ｓ３０３で要求を転送する際にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も転送して、Ｓ３１５やＳ３２２であたかもネットワークストレージＮ０１がメッセージを組み立てたかのようにクライアントＫ００に応答するため、クライアントＫ００ではどのネットワークストレージで処理がおこなわれたのかを意識せずともよい。
【００６５】
また、ファイルハンドルごとにファイル属性を処理するディレクトリサーバが一意に決まるため、ファイル属性更新時に、二つのディレクトリサーバでのデータ整合性を確保することができる。
【００６６】
さらに、複数のネットワークストレージにＲＥＡＤ／ＷＲＩＴＥ要求を転送することにより、ネットワークストレージの負荷分散をおこなうことができる。
（ｂ）ＣＲＥＡＴＥプロトコル
ＮＦＳのＣＲＥＡＴＥ要求は、指定されたディレクトリにファイルを生成するプロトコルである。このＣＲＥＡＴＥ要求は、ファイルハンドルｄｉｒで指定するディレクトリ上にファイル名ｎａｍｅのファイルを新規作成し、作成したファイルのファイルハンドルｏｂｊ＿ｆｈとファイルとディレクトリの属性を返すインターフェースを持つ。
【００６７】
先ず、クライアントＫ００がネットワークストレージＮ０１に対して、ファイルハンドルｄｉｒ上にファイル名ｎａｍｅのファイルを新規作成するＣＲＥＡＴＥ要求を発行する（図２（ａ）Ａ０１）。
【００６８】
ネットワークストレージＮ０１は、このクライアントＫ００からのＣＲＥＡＴＥ要求を受信する（Ｓ４０１）。ＮＦＳでは、既に述べたようにファイルハンドルは最大６４バイトの可変長の値である。
【００６９】
ネットワークストレージＮ０１では、このファイルハンドルを基にディレクトリサーバＤ０１、Ｄ０２のどちらに処理を依頼するかを決定する（Ｓ４０２）。
【００７０】
ここでもＲＥＡＤ／ＷＲＩＴＥの場合と同様に、ファイルハンドルの剰余で処理を依頼するディレクトリサーバを決定する。剰余によってディレクトリサーバを選択することにより、二つのディレクトリサーバが同一ディレクトリ上に同一ファイル名を同時に作成し、データ整合性が取れなくなる事態を回避できる。ここでは仮にディレクトリサーバＤ０１を選択したとする。
【００７１】
ネットワークストレージＮ０１が、選択したディレクトリサーバＤ０１に受信したＣＲＥＡＴＥ要求を転送する（Ｓ４０３、図２（ａ）Ａ０２）。ここで、クライアントＫ００のＩＰアドレス、ネットワークストレージＮ０１のＩＰアドレス、ＴＣＰやＵＤＰの送受信のポート番号、ＲＰＣのトランザクションＩＤ（ＸＩＤ）、ＲＰＣのプログラム番号、ＲＰＣのバージョン番号、ＲＰＣのプロシージャ番号、ＲＰＣの認証情報と検証情報などの応答メッセージを作成するのに必要な情報の全てを転送する。
【００７２】
転送した要求を受信したディレクトリサーバＤ０１では、ファイルハンドルｄｉｒを検索し（Ｓ４０４）、実際に存在するディレクトリのファイルハンドルであるかどうかを確認する。ｄｉｒが見つかった場合には、Ｓ４１１に進み、見つからなかった場合には、Ｓ４２１に進む。
【００７３】
ｄｉｒが見つかった場合には、ファイル名ｎａｍｅの新規ファイルを作成するネットワークストレージを選択する（Ｓ４１１）。ネットワークストレージの選択の際には、以下の手法により最も負荷の低いネットワークストレージを選択すればよい。先ず、各ネットワークストレージのディスク使用率Ｕ％を求める。次に、各ネットワークストレージのネットワーク帯域使用率Ｂ％を求める。そして、別途定めるディスク容量とネットワーク帯域のどちらを優先して評価するかを定めるパラメータα、βを用いて、評価式α＊Ｕ＋β＊Ｂにより各ネットワークストレージを評価する。ただし、ここでα、βは正数とする。評価式の値が大きいほどネットワークストレージのディスクまたはネットワークの負荷が大きいことを意味する。したがって、この評価式の値の小さいネットワークストレージを選択するようにするのが合理的である。
【００７４】
ここでは、仮にネットワークストレージＮ０３を選択したとする。このときネットワークストレージＮ０３にＣＲＥＡＴＥ要求を転送する（Ｓ４１２、図２（ａ）Ａ０３）。ここでも先程と同様にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も同時に転送する。
【００７５】
ネットワークストレージＮ０３では、ファイル名ｎａｍｅのファイル本体データのエントリとファイルハンドルｏｂｊ＿ｆｈを作成する（Ｓ４１３）。そして、ＲＥＡＤ／ＷＲＩＴＥのところで述べた手法で、ｏｂｊ＿ｆｈの剰余からディレクトリサーバを選択する。ここでは、ディレクトリサーバＤ０１が選択されたものとする。ネットワークストレージＮ０３は、そのディレクトリサーバＤ０１に対して、ｏｂｊ＿ｆｈのファイル属性の作成と、必要なファイル属性情報の読み出しを依頼する（Ｓ４１４、図２（ａ）Ａ０５）。
【００７６】
次に、ネットワークストレージＮ０３は、ディレクトリサーバＤ０１にｄｉｒに対応したディレクトリのファイル属性の更新と必要なファイル属性情報の読み出しを依頼する（Ｓ４１５、図２（ａ）Ａ０５）。そして、応答メッセージを組み立てる（Ｓ４１６）。ここで、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からの応答だと認識するように、ネットワークストレージＮ０３が応答メッセージを組み立て、最後に、Ｓ４１７で組み立てた応答メッセージをクライアントＫ００に送信する（Ｓ４１７、図２（ａ）Ａ０４）。
【００７７】
ｄｉｒが見つからなかった場合には、ｄｉｒのディレクトリのファイル属性を読み出し（Ｓ４２１）、ディレクトリサーバＤ０１がエラーメッセージを組み立てる（Ｓ４２２）。ここで、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からの応答だと認識するように、ディレクトリサーバＤ０１が応答メッセージを組み立てる。最後に、組み立てたエラーメッセージをクライアントＫ００に送信する（Ｓ４２３、図２（ａ）Ａ０４）。
このＣＲＥＴＥ要求の処理では、このＲＥＡＤ／ＷＲＩＴＥ要求の処理の場合と同様に、Ｓ４０２で要求を転送するディレクトリサーバを判定することにより、ディレクトリサーバの負荷分散をおこなうことができる。
【００７８】
さらに、Ｓ４０３で要求を転送する際にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も転送して、Ｓ４１６やＳ４２２であたかもネットワークストレージＮ０１がメッセージを組み立てたかのようにクライアントＫ００に応答するため、クライアントＫ００ではどのネットワークストレージで処理がおこなわれたのかを意識せずともよい。
【００７９】
また、ディレクトリのファイルハンドルごとにファイルの作成やファイル属性を処理するディレクトリサーバが一意に定まるため、ファイル作成やファイル属性更新時に、二つのディレクトリサーバでのデータ整合性を確保することができる。さらに、負荷のかかっていないネットワークストレージを選択してＣＲＥＡＴＥ要求を転送することにより、理想的なネットワークストレージの負荷分散をおこなうことができる。
（ｃ）ＬＯＯＫＵＰプロトコル
ＮＦＳのＬＯＯＫＵＰ要求は、指定したファイル名に対して、そのファイルに関連した情報を返すプロトコルである。すなわち、ファイルハンドルｄｉｒで指定するディレクトリ上に存在するファイル名ｆｎａｍｅのファイルについて、ファイルのファイルハンドルｏｂｊ＿ｆｈ、ファイルの属性ｏｂｊ＿ａｔｔｒ、ディレクトリの属性ｄｉｒ＿ａｔｔｒを返すインターフェースを持つ。
【００８０】
ＬＯＯＫＵＰ要求では、クライアントＫ００がネットワークストレージＮ０１に対して、ファイルハンドルｄｉｒ上にあるファイル名ｆｎａｍｅのファイルについてＬＯＯＫＵＰ要求を発行する（図２（ｂ）Ａ０１）。
【００８１】
ネットワークストレージＮ０１は、このクライアントＫ００からのＬＯＯＫＵＰ要求を受信する（Ｓ５０１、図２（ｂ）Ａ０１）。
【００８２】
このファイルハンドルを基にディレクトリサーバＤ０１、Ｄ０２のどちらに処理を依頼するかを決定する（Ｓ５０２）。この決定の方法は、ＲＥＡＤ／ＷＲＩＴＥのところで述べたのと同様の手法を用いることができる。ここでは、仮にディレクトリサーバＤ０１を選択したとする。
【００８３】
そして、ネットワークストレージＮ０１が、そのディレクトリサーバＤ０１に受信したＬＯＯＫＵＰ要求を転送する（Ｓ５０３、図２（ｂ）Ａ０２）。ここで、クライアントＫ００のＩＰアドレス、ネットワークストレージＮ０１のＩＰアドレス、ＴＣＰやＵＤＰの送受信のポート番号、ＲＰＣのトランザクションＩＤ（ＸＩＤ）、ＲＰＣのプログラム番号、ＲＰＣのバージョン番号、ＲＰＣのプロシージャ番号、ＲＰＣの認証情報と検証情報など、応答メッセージを作成するのに必要な情報の全てを転送する。
【００８４】
転送した要求を受信したディレクトリサーバＤ０１では、ファイルハンドルｄｉｒのエントリ上でファイル名ｆｎａｍｅのファイルが持つファイルハンドルｏｂｊ＿ｆｈを検索する（Ｓ５０４）。ｏｂｊ＿ｆｈが見つかった場合には、Ｓ５１１に進み、見つからなかった場合には、Ｓ５２１に進む。
【００８５】
ｏｂｊ＿ｆｈが見つかった場合には、ｏｂｊ＿ｆｈのファイル属性を読み出し（Ｓ５１１）、ｄｉｒのディレクトリ属性を読み出す（Ｓ５１２）。そして、ディレクトリサーバＤ０１では、これらの情報を使い応答メッセージを組み立てる（Ｓ５１３）。ここで、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からの応答だと認識するように、ディレクトリサーバＤ０１が応答メッセージを組み立てるようにする。最後に、組み立てた応答メッセージをクライアントＫ００に送信する（Ｓ５１４、図２（ｂ）Ｂ０１）。
【００８６】
ｏｂｊ＿ｆｈが見つからなかった場合には、ｄｉｒのディレクトリ属性を読み出し（Ｓ５２１）、エラーメッセージを組み立てる（Ｓ５２２）。ここでｏｂｊ＿ｆｈが見つかった場合と同様に、要求を転送した際に一緒に転送したクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報を用いて、クライアントＫ００がネットワークストレージＮ０１からのエラーメッセージだと認識するように、ディレクトリサーバＤ０１がエラーメッセージを組み立てるようにする。最後に、組み立てた応答メッセージをクライアントＫ００に送信する（Ｓ５２３、図２（ｂ）Ｂ０１）。
【００８７】
この要求処理では、処理をおこなうのがディレクトリサーバであり、ネットワークストレージを介さないことに注意する。
【００８８】
ＬＯＯＫＵＰ要求の処理では、Ｓ５０２で要求を転送するサーバを判定することにより、ディレクトリサーバの負荷分散をおこなうことができる。さらに、Ｓ５０３で要求を転送する際にクライアントＫ００やネットワークストレージＮ０１のＩＰアドレスなどの情報も転送して、Ｓ５１３やＳ５２２であたかもネットワークストレージＮ０１がメッセージを組み立てたかのようにクライアントＫ００が認識できるようにしたため、クライアントＫ００は、どのディレクトリサーバが応答を返してくるのかを意識せずともよい。
（III）ディレクトリサーバの二重化およびファイル本体とファイル管理情報の格納形態について
これまでの説明では、ディレクトリサーバが二台あり、いずれのディレクトリサーバを使うのかを、ファイルハンドラに従って選択するようにした。本発明のネットワークストレージ仮想化方法では、ディレクトリサーバが一台でも構築することができる。しかしながら、ディレクトリサーバを複数台にすることにより、ファイル管理情報に関する処理について負荷を分散することができる。
【００８９】
また、各々のディレクトリサーバに別々のファイル管理情報を格納しておき、それをファイルハンドラによって、選択する方法をとると、効率的にディレクトリサーバにファイル管理情報を格納することができる。
【００９０】
しかしながら、信頼性を向上するためには、ファイル管理情報を複数のディレクトリサーバに多重化して格納しておくことが望ましい。ファイル管理情報をディレクトリサーバで保持するようにしたときには、あるディレクトリサーバのファイル管理情報が更新されたときには、適切なタイミングで他のディレクトリサーバに連絡をとり、同期をとって更新してファイル管理情報の整合性を維持しておく必要がある。
【００９１】
ここで、ファイル本体のデータについても信頼性を向上させるために、一つのファイルについて多重化して、複数のネットワークストレージに冗長保持することが望ましい。この場合に、あるファイルハンドラに対するファイル管理情報を格納するディレクトリサーバを複数用意して、それぞれのディレクトリサーバでファイル本体を格納している冗長保持している複数のネットワークストレージを管理させるようにすれば、ファイル本体のデータを多重化した場合のファイル管理についても容易に実現することができる。
【００９２】
さらに、本実施形態では、ファイルハンドルとそのファイルハンドルに対応した管理情報をペアで管理するようにした。しかしながら、本発明のネットワークストレージは、ファイルハンドルとファイルハンドルに対応した管理情報とファイルのオフセット情報を一組で管理することにより、一つのファイルを複数のネットワークストレージに分散して格納する方法にも容易に適用することができる。この方法によって、一つのファイルを複数のネットワークストレージに分割して保存することにより、このシステムのデータ格納方法として、 ＺｅｂｒａファイルシステムのようなファイルのストライプやＲＡＩＤ５のようなデータ冗長化手段も採用することができる。
【００９３】
上記のように、複数のディレクトリサーバおよびネットワークストレージを用意して、ファイル管理情報とファイル本体データを冗長化して格納しておけば、あるディレクトリサーバやネットワークストレージに障害が発生したときでも、他方のディレクトリサーバやネットワークストレージを用いることで、容易にフェールオーバを実現することができる。
（IV）通信形態について
本実施形態では、クライアントはＮＦＳプロトコルによりネットワークストレージの一台に要求を送信して、最終的な応答が要求を受信したネットワークストレージとは異なるネットワークストレージから返る場合であっても、最初に要求を受信したネットワークストレージからの応答のように応答メッセージを作成して、クライアントに返すようにした。すなわち、クライアントは、ＮＦＳのような標準プロトコルを用いて、仮想化されたネットワークストレージにアクセスすることができ、特別のプロトコルやソフトウェアを要しない。
【００９４】
もちろん、クライアントとの通信にＮＦＳ以外のプロトコルを用いても、本発明のネットワークストレージ仮想化方法は、容易に実現することができる。
【００９５】
また、本発明のネットワークストレージ仮想化方法では、ネットワークストレージとディレクトリサーバ間の通信は、クライアント側に見せる必要がないため、クライアントを接続したＬＡＮとは、別のＬＡＮを構築して、そのＬＡＮを用いて通信することにより、クライアントを接続したＬＡＮの通信帯域を節約することができる。
（V）システムの拡張性について
本発明のネットワークストレージ仮想化方法では、ネットワークストレージがファイルの本体データの保存をおこない、ディレクトリサーバがファイルの管理情報を保存する。このためシステム全体のディスク容量を増設するには、新しいネットワークストレージをネットワークに接続するだけで良く、ファイル管理情報の配置を変更する必要がないので、変更のための手間がかからず、ネットワークストレージの増設の際の管理コストが小さくすることができる。また、減設の場合も同様にファイル管理情報の配置を変更する必要がないので、ネットワークストレージの減設の際の管理コストを小さくすることかできる。
【００９６】
〔実施形態２〕
次に、図６を用いて本発明に係る第二の実施形態について説明する。
図６は、本発明に係る第二の実施形態の処理の流れを示す模式図である。
【００９７】
本実施形態は、第一の実施形態の機能を拡張して、クライアントからネットワークストレージにファイルアクセスの要求処理を出すときに、同じファイルを二回目にアクセスするときに、処理性能を上げようとするものである。
【００９８】
図６（ａ）は、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）に一回目の処理の依頼がきたときの流れ図であり、Ａ０１〜Ａ０４までの処理については、第一の実施形態と同様である。
【００９９】
異なるのは、ディレクトリサーバＤ０１は、ファイルの格納されているネットワークストレージＮ０３（第二のネットワークストレージ）に要求を転送（Ａ０３）するのと同時にネットワークストレージＮ０１に、ファイルがネットワークストレージＮ０３に格納されていることを、例えば、ファイル識別子とネットワークストレージ識別子の対という形態で通知することである（Ｇ０１）。
【０１００】
このときに、ネットワークストレージＮ０１とネットワークストレージＮ０３は、並列に動作しているので、システムとして、それほど処理性能が低下することもない。
【０１０１】
ネットワークストレージＮ０１では、そのファイル識別子とネットワークストレージ識別子の対応を、キャッシュファイルとして一時記憶用領域に保存しておく。
【０１０２】
この状態にあるとき、図６（ｂ）に示されるようにクライアントＫ００から同じファイルに対してファイルアクセスの要求がネットワークストレージＮ０１に発せられたとする。
【０１０３】
このときに、ネットワークストレージＮ０１は、先ず、そのファイルに対応しているファイル識別子とネットワークストレージ識別子の対応が一時記憶用領域の中にないかを検索する。そして、見つかったときには、ネットワークストレージＮ０２に直接要求を転送する（Ｈ０２）。そのあと、ネットワークストレージＮ０２で、要求を処理してクライアントに応答する（Ａ０４）ことは、第一の実施形態と同様である。見つからなかったときには、図６（ａ）の場合と同様に、該当するディレクトリサーバＤ０１を選択して、それに要求を転送する（Ａ０２）。
【０１０４】
この実施形態によれば、一時記憶用領域の中に既にアクセスしたファイルの関連情報が記憶されているときには、ディレクトリサーバＤ０１を経由せずに、ネットワークストレージＮ０２に直接要求を転送することができるので、処理性能を大幅に向上させることができる。
【０１０５】
〔実施形態３〕
次に、図７を用いて本発明に係る第三の実施形態について説明する。
図７は、本発明に係る第三の実施形態の処理の流れを示す模式図である。
【０１０６】
第一の実施形態では、ファイル管理情報は、もっぱらディレクトリサーバが管理していた。ディレクトリサーバの数が少なく、かつ、多くのＲＥＡＤ／ＷＲＩＴＥ要求が発生して、一時に大量のファイル管理情報を更新しなければならなくなったときに、ディレクトリサーバに負荷がかかり、システムの性能のボトルネックになるおそれがある。
【０１０７】
本実施形態では、そのような事態を防止できるように、個々のネットワークストレージに対して、ファイル管理もおこなえるように、ディレクトリサーバ機能を持たせたものである。ディレクトリサーバは、第一の実施形態と同様に、ファイル管理情報を全て保持する。そして、各ネットワークストレージに、ファイル管理情報を分割して、コピーする。分割するときの手法としては、ファイルハンドルを用いて、ネットワークストレージと対応付ける評価関数を用いることができる。例えば、ファイルハンドルのバイト表現の剰余を計算する評価関数がある。この評価関数を用いた場合には、Ｎ台のネットワークストレージがあるとすると、各ネットワークストレージに０からＮ−１までの識別子を割り振り、ファイルハンドルのＮの剰余を計算し、剰余の値に対応した識別子を持つネットワークストレージにそのファイルハンドルに対応するファイル管理情報を格納する。
【０１０８】
このように分類したファイル管理情報を対応するネットワークストレージにコピーすることで、ファイル管理情報を重複することなく各ネットワークストレージの記憶装置に分割してコピーすることができる。
【０１０９】
この処理では、先ず、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）にＬＡＮ経由で、ＲＥＡＤ／ＷＲＩＴＥ要求のファイルアクセス要求を発する（Ａ０１）。
【０１１０】
本実施形態では、各々のネットワークストレージにディレクトリサーバ機能が付加されているために、ディレクトリサーバとネットワークストレージの両方がファイル管理情報に対する処理をおこなうことができる。
【０１１１】
第一の実施形態では、要求を転送するのは、ディレクトリサーバのみであったが、本実施形態では、要求を転送する候補として、ディレクトリサーバとネットワークストレージの二通りがあることに注意する必要がある。
【０１１２】
図７（ａ）は、ネットワークストレージＮ０２（第二のネットワークストレージが選択されたものとする。ＲＥＡＤ／ＷＲＩＴＥプロトコルのときには、例えば、上記のようにファイルハンドルの剰余を求めることにより、ネットワークストレージＮ０２を選択することができる。
【０１１３】
そして、ネットワークストレージＮ０１は、ネットワークストレージＮ０２に受信した要求を転送する（Ｃ０２）。
【０１１４】
このときに、ネットワークストレージＮ０１は、クライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報も同時に転送する。
【０１１５】
ネットワークストレージＮ０２では、転送された要求に含まれているファイルハンドルからファイル管理情報を検索して、ファイル管理情報の示すファイル本体データを格納しているネットワークストレージＮ０３（第三のネットワークストレージ）に転送する（Ｃ０３）。このときにも、クライアントと第一のネットワークストレージＮ０１のＩＰアドレスなども転送するのは、Ｃ０２のときと同様である。
【０１１６】
ネットワークストレージＮ０３では、転送された要求に含まれるファイルハンドルに対応するファイル本体データに対して要求された処理をおこない、結果をクライアントＫ００に応答する（Ａ０４）。
【０１１７】
応答を返すとき、ネットワークストレージＮ０３は、転送されてきたクライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報を用い、あたかも、ネットワークストレージＮ０１が要求を処理したようなパケットを組み立てる。クライアントＫ００側では、どのネットワークストレージが処理をしたのかを一切意識する必要がないのは、第一の実施形態と同様である。
【０１１８】
そして、最後に、ファイルのアクセス時刻の更新などファイル管理情報が更新されるので、この情報をディレクトリサーバＤ０１とネットワークストレージＮ０２に送信して（Ａ０５）、ディレクトリサーバＤ０１とネットワークストレージＮ０２上のファイル管理情報を書き換える。
【０１１９】
これにより、ネットワークストレージ上のファイル管理情報とディレクトリサーバ上のファイル管理情報とは、整合性が保たれる。
【０１２０】
またこのとき、多数のファイルにＲＥＡＤ／ＷＲＩＴＥ要求が発生する場合や同一のファイルに対して頻繁にＲＥＡＤ／ＷＲＩＴＥ要求が発生する場合には、上記の手法では、毎回ディレクトリサーバが多数のファイル管理情報の更新要求パケットを受信することになるため、ディレクトリサーバに負荷がかかりすぎるおそれがある。
【０１２１】
そのために、ネットワークストレージ上で、ディレクトリサーバに送信すべきファイル管理情報を蓄積しておき、適切な時期に、まとめてディレクトリサーバ上のファイル管理情報を更新するようにすればよい。すなわち、複数のファイル管理情報の更新要求パケットをまとめて、一つの更新要求パケットにすることにより通信量を減らし、しかも、同一ファイルのファイル管理情報を頻繁に更新する場合には、最終結果のみが更新要求パケットとして送られるので、ディレクトリサーバのファイル管理情報の更新処理を減らすことができる。
【０１２２】
図７（ａ）に示した処理では、クライアントＫ００の要求がＲＥＡＤ／ＷＲＩＴＥ要求のように、要求のインタフェースにファイルハンドルを含んでいて、それにより、ファイル管理情報を格納している第二のネットワークストレージＮ０２を選択した。
【０１２３】
次に、ＣＲＥＡＴＥ要求のように、クライアントＫ００の要求がインタフェースにファイルハンドルを含んでいない処理が発せられたものとする。
【０１２４】
この処理では、図７（ｂ）に示されるように、先ず、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）にＬＡＮ経由で、ＣＲＥＡＴＥ要求を発する（Ａ０１）。
【０１２５】
このときに、ネットワークストレージＮ０１は、ネットワークストレージではなく、必ずディレクトリサーバを選択することになる。そして、ディレクトリサーバＤ０１に要求を転送する（Ｅ０２）。また、ネットワークストレージＮ０１が、クライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報も同時に転送するのは、図７（ａ）のときと同様である。
【０１２６】
要求を受信したディレクトリサーバＤ０１は、新規ファイルハンドルと新規ファイル管理情報を作成し、例えば、ファイルハンドルの剰余から新規ファイル管理情報をコピーするネットワークストレージＮ０３（第三のネットワークストレージ）を求めて、それに対して新規ファイルの作成要求とファイル管理情報の格納要求を送信する（Ｅ０３）。なお、新規ファイルの作成要求はネットワークストレージＮ０３以外の任意のネットワークストレージに対して送信してよい。
【０１２７】
ネットワークストレージＮ０３は、要求に応じて、新規ファイルを作成して、ファイル管理情報を格納した後に、クライアントＫ００に要求の応答を返す（Ａ０４）。また、応答を返すとき、ネットワークストレージＮ０３は、転送されてきたクライアントと第一のネットワークストレージＮ０１のＩＰアドレス、送受信のポート番号、ＲＥＡＤ／ＷＲＩＴＥ要求のトランザクションＩＤなどの情報を用い、あたかも、ネットワークストレージＮ０１が要求を処理したようなパケットを組み立てるのは、図７（ａ）の場合と同様である。
【０１２８】
そして、ネットワークストレージＮ０３上のファイル管理情報を更新し、この情報をディレクトリサーバＤ０１上に送信して（Ａ０５）、ディレクトリサーバＤ０１上のファイル管理情報を書き換えて、ネットワークストレージ上のファイル管理情報とディレクトリサーバ上のファイル管理情報との整合性が保つようにする。
【０１２９】
なお、図７に示したようなシステム形態で、新規にネットワークストレージを増設する際には、ディレクトリサーバのファイル管理情報のデータ更新が終了した後に、新規ネットワークストレージを含めてネットワークストレージに識別子を割り当て、ファイル管理情報の分割とネットワークストレージへのコピーを再びおこなうようにする。
【０１３０】
本実施形態では、上記のように、ネットワークストレージにディレクトリサーバ機能を持たせることにより、ファイル管理情報に関する処理の負荷を分散させ、処理の並列性を増すことにより、より高いスループットを達成することができる。また、ファイル管理情報がネットワークストレージにディレクトリサーバとに、二重化して保持されているために、システムの信頼性が高まり、いずれかのネットワークストレージやディレクトリサーバに障害がおこったときであっても、ファイル管理情報を喪失するのを防ぐことができ、継続してシステム運用をおこなえるという特徴がある。
【０１３１】
〔実施形態４〕
次に、図８を用いて本発明に係る第四の実施形態について説明する。
図８は、本発明に係る第四の実施形態の処理の流れを示す模式図である。
【０１３２】
第一の実施形態は、第一のネットワークストレージがクライアントから要求を受信して、その要求をディレクトリサーバに転送した。しかしながら、ＷＲＩＴＥ要求などで書き換える容量が大きいときには、そのパケットも大きくなり、ディレクトリサーバに転送すると、ディレクトリサーバに負荷がかかり、ネットワーク帯域も圧迫する恐れがある。
【０１３３】
本実施形態では、第一のネットワークストレージは、ディレクトリサーバに対して、ファイルアクセスの要求を転送すべきネットワークストレージを問い合わせて、その返答にしたがって、その要求を転送するものである。通常、問い合わせパケットは、ＷＲＩＴＥ要求のパケットに比べて、小さいので、ディレクトリサーバに負担がかからず、ネットワーク上に流れるパケット量を少なくすることができる。
【０１３４】
この処理では、先ず、クライアントＫ００からネットワークストレージＮ０１（第一のネットワークストレージ）にＬＡＮ経由でファイルアクセス要求を発する（Ａ０１）。
【０１３５】
ネットワークストレージＮ０１は、そのファイルのファイル管理情報を格納されているディレクトリサーバＤ０１を選択して、それに対してファイル本体の格納されているネットワークストレージの問い合わせ要求をおこなう（Ｆ０１）。
【０１３６】
ディレクトリサーバＤ０１は、問い合わせ要求の中に含まれるファイルハンドルからそのファイルの格納されているネットワークストレージを検索して、該当するネットワークストレージは、ネットワークストレージＮ０３（第二のネットワークストレージ）であることを返答する（Ｆ０２）。
【０１３７】
ネットワークストレージＮ０１は、これを受信して、ネットワークストレージＮ０３に要求を転送する（Ｆ０３）。
【０１３８】
ネットワークストレージＮ０３では、要求を処理して応答をクライアントＫ００に返し（Ａ０４）、ディレクトリサーバのファイル管理情報を更新する（Ａ０５）ことは、第一の実施形態と同様である。
【０１３９】
問い合わせの結果は、ファイル識別子とネットワークストレージの識別子の対応として、第一のネットワークストレージＮ０１のキャッシュファイルなどの一時記憶領域に格納しておく。そして、おなじファイルに対してアクセス要求があったときには、一時記憶領域の情報を検索して、見つかったときには、ただちに、そのファイルの格納されているネットワークストレージに要求を転送する。この流れは、図６（ｂ）で示したものと同様である。
【０１４０】
【発明の効果】
本発明によれば、ＮＦＳなどの標準プロトコルを用いてアクセス可能なネットワークストレージ仮想化方法を提供することができる。
【０１４１】
また、ネットワークストレージの増設や減設の際の管理コストが小さいネットワークストレージ仮想化方法を提供することができる。
【０１４２】
また、ファイル管理情報を冗長化することで障害発生時にも継続して運用可能なネットワークストレージ仮想化方法を提供することである。
【０１４３】
さらに、クライアントからの要求を受信するネットワークストレージと、要求の処理をおこないクライアントに応答を返すネットワークストレージとが異なる場合でも、クライアントでは、そのことを意識せずとも、ネットワークストレージへの要求をおこなうことのできるネットワークストレージ仮想化システムを提供することができる。
【図面の簡単な説明】
【図１】本発明のネットワークストレージシステムのシステム構成図である。
【図２】本発明に係る第一の実施形態の処理の流れを示す模式図である。
【図３】クライアントからＲＥＡＤ／ＷＲＩＴＥ要求がされたときの処理を示すＰＡＤ（Problem Analysis Diagram）図である。
【図４】クライアントからＣＲＥＡＴＥ要求がされたときの処理を示すＰＡＤ図である。
【図５】クライアントからＬＯＯＫＵＰ要求がされたときの処理を示すＰＡＤ図である。
【図６】本発明に係る第二の実施形態の処理の流れを示す模式図である。
【図７】本発明に係る第三の実施形態の処理の流れを示す模式図である。
【図８】本発明に係る第四の実施形態の処理の流れを示す模式図である。
【符号の説明】
Ｋ００…クライアント
１００…ＬＡＮ
Ｎ０１〜Ｎ０４…ネットワークストレージ
Ｄ０１，Ｄ０２…ディレクトリサーバ
Claims (10)
- クライアントからのファイルデータを保存するネットワークストレージにアクセスするためのネットワークストレージ仮想化方法において、
ファイル属性及びファイルデータを格納するネットワークストレージの情報を含むファイル管理情報を保存するディレクトリサーバを設け、
前記クライアントから前記ネットワークストレージに、前記ファイル管理情報へのアクセス要求があったときに、
（１）前記クライアントから前記ファイル管理情報へのアクセス要求を第一のネットワークストレージが受信するステップ、
（２）前記第一のネットワークストレージが、受信した前記アクセス要求及び第一のネットワークストレージのＩＰアドレスを前記ディレクトリサーバに転送するステップを有し、
前記アクセス要求が、前記ファイルデータ及び前記ファイル管理情報へのアクセス要求である場合、
（３）前記ディレクトリサーバが、前記ファイル管理情報を基に前記アクセス要求を処理するネットワークストレージとして第二のネットワークストレージを選択するステップ、
（４）前記ディレクトリサーバが、選択した第二のネットワークストレージに前記アクセス要求及び前記第一のネットワークストレージのＩＰアドレスを転送するステップ、
（５）前記第二のネットワークストレージが、前記アクセス要求を処理するステップ、
（６）前記第二のネットワークストレージが、前記第一のネットワークストレージのＩＰアドレスに基づく応答メッセージを組み立てるステップ、
（７）前記第二のネットワークストレージが、前記アクセス要求を処理した結果及び前記応答メッセージを、前記アクセス要求の応答として前記クライアントに送信するステップを有し、
前記アクセス要求が、前記ファイル管理情報のみへのアクセス要求である場合、（３′）前記ディレクトリサーバが、前記アクセス要求を処理するステップ、
（４′）前記ディレクトリサーバが、前記第一のネットワークストレージのＩＰアドレスに基づく応答メッセージを組み立てるステップ、
（５′）前記ディレクトリサーバが、前記アクセス要求を処理した結果及び前記応答メッセージを、前記アクセス要求の応答として前記クライアントに送信するステップを有することを特徴とするネットワークストレージ仮想化方法。 - 前記ディレクトリサーバが複数あって、前記（２）のステップにおいて、受信したアクセス要求を転送するためのディレクトリサーバを選択するための処理を含むことを特徴とする請求項１記載のネットワークストレージ仮想化方法。
- さらに、前記（３）のステップの結果として、前記アクセス要求を処理するネットワークストレージとして前記第二のネットワークストレージを選択したことを、前記ディレクトリサーバが前記第一のネットワークストレージに通知するステップを含むことを特徴とする請求項１記載のネットワークストレージ仮想化方法。
- クライアントからのファイルデータを保存するネットワークストレージにアクセスするためのネットワークストレージ仮想化方法において、
ファイル属性及びファイルデータを格納するネットワークストレージの情報を含むファイル管理情報が保存されるディレクトリサーバと、前記ファイル管理情報が分割されて保存される複数のネットワークストレージとを設け、
前記クライアントから前記ネットワークストレージに、前記ファイル管理情報へのアクセス要求があったときに、
（８）前記クライアントから前記ファイル管理情報へのアクセス要求を第一のネットワークストレージが受信するステップ、
（９）前記第一のネットワークストレージが、受信した前記アクセス要求及び第一のネットワークストレージのＩＰアドレスを転送する前記ディレクトリサーバまたは第二のネットワークストレージを選択するステップ、
（１０）前記第一のネットワークストレージが、選択されたディレクトリサーバまたは第二のネットワークストレージに、受信した前記アクセス要求及び第一のネットワークストレージのＩＰアドレスを転送するステップ、
（１１）前記ディレクトリサーバが選択された場合、前記ディレクトリサーバが、前記ディレクトリサーバに保存されるファイル管理情報を基に前記アクセス要求を処理する第三のネットワークストレージを選択するステップ、
（１１′）前記第二のネットワークストレージが選択された場合、前記第二のネットワークストレージが、前記複数のネットワークストレージに分割して保存されるファイル管理情報を基に前記アクセス要求を処理する第三のネットワークストレージを選択するステップ、
（１２）選択されたディレクトリサーバ又は第二のネットワークストレージが、受信した前記アクセス要求及び第一のネットワークストレージのＩＰアドレスを、前記第三のネットワークストレージに転送するステップ、
（１３）前記第三のネットワークストレージが、前記アクセス要求を処理するステップ、
（１４）前記第三のネットワークストレージが、前記第一のネットワークストレージのＩＰアドレスに基づく応答メッセージを組み立てるステップ、
（１５）前記第三のネットワークストレージが、前記アクセス要求を処理した結果及び前記応答メッセージを、前記アクセス要求の応答として前記クライアントに送信するステップを有することを特徴とするネットワークストレージ仮想化方法。 - 前記（１１）（ｌｌ′）のステップの結果として、前記ディレクトリサーバまたは前記第二のネットワークストレージが、前記アクセス要求を処理するネットワークストレージとして前記第三のネットワークストレージを選択したことを前記第一のネットワークストレージに通知するステップを含むことを特徴とする請求項４記載のネットワークストレージ仮想化方法。
- クライアントからのファイルデータを保存するネットワークストレージにアクセスするためのネットワークストレージシステムにおいて、
ファイル属性及びファイルデータを格納するネットワークストレージの情報を含むファイル管理情報を保存するディレクトリサーバを設け、
前記クライアントから前記ネットワークストレージに、前記ファイル管理情報へのアクセス要求があったときに、
第一のネットワークストレージは、前記クライアントから前記ファイル管理情報へのアクセス要求を受信し、
前記第一のネットワークストレージは、受信した前記アクセス要求及び第一のネットワークストレージのＩＰアドレスを前記ディレクトリサーバに転送し、
前記アクセス要求が、前記ファイルデータ及び前記ファイル管理情報へのアクセス要求である場合、
前記ディレクトリサーバは、前記ファイル管理情報を基に前記アクセス要求を処理するネットワークストレージとして第二のネットワークストレージを選択し、
前記ディレクトリサーバは、選択した第二のネットワークストレージに前記アクセス要求及び前記第一のネットワークストレージのＩＰアドレスを転送し、
前記第二のネットワークストレージは、前記アクセス要求を処理し、
前記第二のネットワークストレージは、前記第一のネットワークストレージのＩＰアドレスに基づく応答メッセージを組み立て、
前記第二のネットワークストレージは、前記アクセス要求を処理した結果及び前記応答メッセージを、前記アクセス要求の応答として前記クライアントに送信し、
前記アクセス要求が、前記ファイル管理情報のみへのアクセス要求である場合、
前記ディレクトリサーバは、前記アクセス要求を処理し、
前記ディレクトリサーバは、前記第一のネットワークストレージのＩＰアドレスに基づく応答メッセージを組み立て、
前記ディレクトリサーバは、前記アクセス要求を処理した結果及び前記応答メッセージ を、前記アクセス要求の応答として前記クライアントに送信することを特徴とするネットワークストレージシステム。 - 前記ディレクトリサーバが複数あって、第一のネットワークストレージは、受信したアクセス要求を転送するためのディレクトリサーバを選択することを特徴とする請求項６記載のネットワークストレージシステム。
- さらに、前記ディレクトリサーバが、前記アクセス要求を処理するネットワークストレージとして前記第二のネットワークストレージを選択したことを、前記ディレクトリサーバが前記第一のネットワークストレージに通知することを特徴とする請求項６記載のネットワークストレージシステム。
- クライアントからのファイルデータを保存するネットワークストレージにアクセスするためのネットワークストレージシステムにおいて、
ファイル属性及びファイルデータを格納するネットワークストレージの情報を含むファイル管理情報が保存されるディレクトリサーバと、前記ファイル管理情報が分割されて保存される複数のネットワークストレージとを設け、
前記クライアントから前記ネットワークストレージに、前記ファイル管理情報へのアクセス要求があったときに、
第一のネットワークストレージは、前記クライアントから前記ファイル管理情報へのアクセス要求を受信し、
前記第一のネットワークストレージは、受信した前記アクセス要求及び第一のネットワークストレージのＩＰアドレスを転送する前記ディレクトリサーバまたは第二のネットワークストレージを選択し、
前記第一のネットワークストレージは、選択されたディレクトリサーバまたは第二のネットワークストレージに、受信した前記アクセス要求及び第一のネットワークストレージのＩＰアドレスを転送し、
前記ディレクトリサーバが選択された場合、前記ディレクトリサーバは、前記ディレクトリサーバに保存されるファイル管理情報を基に前記アクセス要求を処理する第三のネットワークストレージを選択し、
前記第二のネットワークストレージが選択された場合、前記第二のネットワークストレージは、前記複数のネットワークストレージに分割して保存されるファイル管理情報を基に前記アクセス要求を処理する第三のネットワークストレージを選択し、
選択されたディレクトリサーバ又は第二のネットワークストレージは、受信した前記アクセス要求及び第一のネットワークストレージのＩＰアドレスを、前記第三のネットワークストレージに転送し、
前記第三のネットワークストレージは、前記アクセス要求を処理し、
前記第三のネットワークストレージは、前記第一のネットワークストレージのＩＰアドレスに基づく応答メッセージを組み立て、
前記第三のネットワークストレージは、前記アクセス要求を処理した結果及び前記応答メッセージを、前記アクセス要求の応答として前記クライアントに送信することを特徴とするネットワークストレージシステム。 - 前記第三のネットワークストレージの選択の結果として、前記ディレクトリサーバまたは前記第二のネットワークストレージが、前記アクセス要求を処理するネットワークストレージとして前記第三のネットワークストレージを選択したことを前記第一のネットワークストレージに通知することを特徴とする請求項９記載のネットワークストレージシステム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003030426A JP4237515B2 (ja) | 2003-02-07 | 2003-02-07 | ネットワークストレージ仮想化方法およびネットワークストレージシステム |
| US10/368,644 US7433934B2 (en) | 2003-02-07 | 2003-02-20 | Network storage virtualization method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003030426A JP4237515B2 (ja) | 2003-02-07 | 2003-02-07 | ネットワークストレージ仮想化方法およびネットワークストレージシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004240803A JP2004240803A (ja) | 2004-08-26 |
| JP4237515B2 true JP4237515B2 (ja) | 2009-03-11 |
Family
ID=32957317
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003030426A Expired - Fee Related JP4237515B2 (ja) | 2003-02-07 | 2003-02-07 | ネットワークストレージ仮想化方法およびネットワークストレージシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7433934B2 (ja) |
| JP (1) | JP4237515B2 (ja) |
Families Citing this family (37)
| 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 |
| JP4265245B2 (ja) * | 2003-03-17 | 2009-05-20 | 株式会社日立製作所 | 計算機システム |
| US7630994B1 (en) | 2004-03-12 | 2009-12-08 | Netapp, Inc. | On the fly summarization of file walk data |
| US7293039B1 (en) | 2004-03-12 | 2007-11-06 | Network Appliance, Inc. | Storage resource management across multiple paths |
| US7844646B1 (en) * | 2004-03-12 | 2010-11-30 | Netapp, Inc. | Method and apparatus for representing file system metadata within a database for efficient queries |
| US7539702B2 (en) * | 2004-03-12 | 2009-05-26 | Netapp, Inc. | Pre-summarization and analysis of results generated by an agent |
| US7546631B1 (en) * | 2004-04-30 | 2009-06-09 | Sun Microsystems, Inc. | Embedded management system for a physical device having virtual elements |
| JP2006309375A (ja) * | 2005-04-27 | 2006-11-09 | Hitachi Ltd | システム情報に基づいて動作する記憶装置システム及びその記憶装置システムの制御方法 |
| US8073899B2 (en) * | 2005-04-29 | 2011-12-06 | Netapp, Inc. | System and method for proxying data access commands in a storage system cluster |
| US8886778B2 (en) * | 2005-04-29 | 2014-11-11 | Netapp, Inc. | System and method for proxying network management protocol commands to enable cluster wide management of data backups |
| US7363457B1 (en) | 2005-07-21 | 2008-04-22 | Sun Microsystems, Inc. | Method and system for providing virtualization data services for legacy storage devices |
| US8255425B1 (en) * | 2005-11-01 | 2012-08-28 | Netapp, Inc. | System and method for event notification using an event routing table |
| JP4175379B2 (ja) | 2006-04-25 | 2008-11-05 | 日本電気株式会社 | ファイル共有方法およびファイル共有システム |
| US20080177907A1 (en) * | 2007-01-23 | 2008-07-24 | Paul Boerger | Method and system of a peripheral port of a server system |
| US20080270480A1 (en) * | 2007-04-26 | 2008-10-30 | Hanes David H | Method and system of deleting files from a remote server |
| US20080270594A1 (en) * | 2007-04-27 | 2008-10-30 | Mcjilton Charles M | Method and system of separate file storage locations as unified file storage |
| US8005993B2 (en) | 2007-04-30 | 2011-08-23 | Hewlett-Packard Development Company, L.P. | System and method of a storage expansion unit for a network attached storage device |
| JP2009020876A (ja) * | 2007-06-14 | 2009-01-29 | Panasonic Corp | ファイル管理装置及びファイル転送方法並びに撮像装置 |
| US8452821B2 (en) * | 2007-06-29 | 2013-05-28 | Microsoft Corporation | Efficient updates for distributed file systems |
| US8209365B2 (en) * | 2007-07-23 | 2012-06-26 | Hewlett-Packard Development Company, L.P. | Technique for virtualizing storage using stateless servers |
| US9298417B1 (en) * | 2007-07-25 | 2016-03-29 | Emc Corporation | Systems and methods for facilitating management of data |
| JP5076736B2 (ja) * | 2007-08-27 | 2012-11-21 | 日本電気株式会社 | 計算機システム、ストレージ、アクセス制御方法およびアクセス制御用プログラム |
| US7791487B2 (en) * | 2007-11-29 | 2010-09-07 | International Business Machines Corporation | Locating radio frequency identification tags in time and space |
| CN101562631A (zh) * | 2008-04-18 | 2009-10-21 | 鸿富锦精密工业（深圳）有限公司 | 网络存储管理装置和方法 |
| US7992055B1 (en) | 2008-11-07 | 2011-08-02 | Netapp, Inc. | System and method for providing autosupport for a security system |
| CN101459669A (zh) * | 2008-12-29 | 2009-06-17 | 成都市华为赛门铁克科技有限公司 | 一种网络文件***的访问方法和装置 |
| US20100274886A1 (en) * | 2009-04-24 | 2010-10-28 | Nelson Nahum | Virtualized data storage in a virtualized server environment |
| JP5423879B2 (ja) * | 2010-03-29 | 2014-02-19 | 日本電気株式会社 | データアクセス場所選択システム、方法およびプログラム |
| US8793645B2 (en) | 2010-04-02 | 2014-07-29 | Microsoft Corporation | Replacement of data element in a graph |
| JP2011242826A (ja) * | 2010-05-14 | 2011-12-01 | Fujitsu Ltd | ファイル管理システム及びファイル管理プログラム |
| JP5822452B2 (ja) * | 2010-10-22 | 2015-11-24 | 株式会社インテック | ストレージサービス提供装置、システム、サービス提供方法、及びサービス提供プログラム |
| JP5637115B2 (ja) * | 2011-10-18 | 2014-12-10 | 株式会社バッファロー | ネットワークストレージシステム、ネットワークストレージシステムにおけるデータ操作方法、記憶装置 |
| US8769105B2 (en) | 2012-09-14 | 2014-07-01 | Peaxy, Inc. | Software-defined network attachable storage system and method |
| US9984083B1 (en) * | 2013-02-25 | 2018-05-29 | EMC IP Holding Company LLC | Pluggable storage system for parallel query engines across non-native file systems |
| US9753980B1 (en) | 2013-02-25 | 2017-09-05 | EMC IP Holding Company LLC | M X N dispatching in large scale distributed system |
| JP6683160B2 (ja) | 2017-03-27 | 2020-04-15 | 日本電気株式会社 | ストレージシステム、および通信方法 |
| US10467097B2 (en) * | 2017-06-02 | 2019-11-05 | International Business Machines Corporation | Indicating data health in a DSN memory |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5513314A (en) * | 1995-01-27 | 1996-04-30 | Auspex Systems, Inc. | Fault tolerant NFS server system and mirroring protocol |
| 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 |
| US5964886A (en) * | 1998-05-12 | 1999-10-12 | Sun Microsystems, Inc. | Highly available cluster virtual disk system |
| JP2000020365A (ja) * | 1998-07-07 | 2000-01-21 | Matsushita Electric Ind Co Ltd | データ処理装置、及びそのファイル管理方法 |
| DE60035969T2 (de) * | 2000-06-15 | 2008-05-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Verfahren und Anordnung zur Behandlung der Informationpakete durch vom Nutzer auswählbare Relaisknoten |
| JP3570501B2 (ja) * | 2000-06-15 | 2004-09-29 | 日本電気株式会社 | ネットワークシステム及びパケットデータ伝送方法 |
| US6970939B2 (en) * | 2000-10-26 | 2005-11-29 | Intel Corporation | Method and apparatus for large payload distribution in a network |
| US6606690B2 (en) * | 2001-02-20 | 2003-08-12 | Hewlett-Packard Development Company, L.P. | System and method for accessing a storage area network as network attached storage |
| US20030037061A1 (en) * | 2001-05-08 | 2003-02-20 | Gautham Sastri | Data storage system for a multi-client network and method of managing such system |
| JP4113352B2 (ja) * | 2001-10-31 | 2008-07-09 | 株式会社日立製作所 | ストレージ・ネットワークにおけるストレージ・リソース運用管理方法 |
| US7024427B2 (en) * | 2001-12-19 | 2006-04-04 | Emc Corporation | Virtual file system |
| US7548975B2 (en) * | 2002-01-09 | 2009-06-16 | Cisco Technology, Inc. | Methods and apparatus for implementing virtualization of storage within a storage area network through a virtual enclosure |
| US7433948B2 (en) * | 2002-01-23 | 2008-10-07 | Cisco Technology, Inc. | Methods and apparatus for implementing virtualization of storage within a storage area network |
| JP4154893B2 (ja) * | 2002-01-23 | 2008-09-24 | 株式会社日立製作所 | ネットワークストレージ仮想化方法 |
| JP4059711B2 (ja) * | 2002-06-04 | 2008-03-12 | 株式会社日立グローバルストレージテクノロジーズ | 多重書き込み型記憶装置 |
-
2003
- 2003-02-07 JP JP2003030426A patent/JP4237515B2/ja not_active Expired - Fee Related
- 2003-02-20 US US10/368,644 patent/US7433934B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US7433934B2 (en) | 2008-10-07 |
| JP2004240803A (ja) | 2004-08-26 |
| US20040205143A1 (en) | 2004-10-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4237515B2 (ja) | ネットワークストレージ仮想化方法およびネットワークストレージシステム | |
| JP4448719B2 (ja) | ストレージシステム | |
| JP4068473B2 (ja) | ストレージ装置、分担範囲決定方法及びプログラム | |
| US10558565B2 (en) | Garbage collection implementing erasure coding | |
| US9614912B2 (en) | System and method of implementing an object storage infrastructure for cloud-based services | |
| JP5427533B2 (ja) | 階層ストレージ管理システムにおける重複ファイルの転送方法及びシステム | |
| US9342529B2 (en) | Directory-level referral method for parallel NFS with multiple metadata servers | |
| US9880753B2 (en) | Write requests in a distributed storage system | |
| US8533231B2 (en) | Cloud storage system with distributed metadata | |
| JP2004054721A (ja) | ネットワークストレージ仮想化方法 | |
| JP4297747B2 (ja) | ストレージ装置 | |
| US20030217077A1 (en) | Methods and apparatus for storing updatable user data using a cluster of application servers | |
| US9031906B2 (en) | Method of managing data in asymmetric cluster file system | |
| JP2004126716A (ja) | 広域分散ストレージシステムを利用したデータ格納方法、その方法をコンピュータに実現させるプログラム、記録媒体、及び広域分散ストレージシステムにおける制御装置 | |
| US11431798B2 (en) | Data storage system | |
| CN111225003B (zh) | 一种nfs节点配置方法和装置 | |
| US9544371B1 (en) | Method to discover multiple paths to disk devices cluster wide | |
| US11900160B2 (en) | Methods for managing storage quota assignment in a distributed system and devices thereof | |
| JP2012164185A (ja) | サーバ、クライアント、これらを有するバックアップシステム、及びこれらのバックアップ方法 | |
| JP2005018100A (ja) | ネットワークファイルサーバ、情報処理装置並びにプログラム | |
| WO2021187194A1 (ja) | 分散処理システム、分散処理システムの制御方法、及び、分散処理システムの制御装置 | |
| JP2023541069A (ja) | アクティブ－アクティブストレージシステムおよびそのデータ処理方法 | |
| WO2012046585A1 (ja) | 分散ストレージシステム、その制御方法、およびプログラム | |
| JP3835199B2 (ja) | 分散管理型ネットワークファイルシステム及びファイル方法 | |
| WO2024148824A1 (zh) | 数据处理方法、***、装置、存储介质及电子设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20050105 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050803 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20050803 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080902 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081030 |
|
| 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: 20081125 |
|
| 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: 20081218 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4237515 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111226 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111226 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121226 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121226 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121226 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131226 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |