JP2004054721A - ネットワークストレージ仮想化方法 - Google Patents
ネットワークストレージ仮想化方法 Download PDFInfo
- Publication number
- JP2004054721A JP2004054721A JP2002213245A JP2002213245A JP2004054721A JP 2004054721 A JP2004054721 A JP 2004054721A JP 2002213245 A JP2002213245 A JP 2002213245A JP 2002213245 A JP2002213245 A JP 2002213245A JP 2004054721 A JP2004054721 A JP 2004054721A
- Authority
- JP
- Japan
- Prior art keywords
- network storage
- network
- storages
- request
- 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.)
- Revoked
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/564—Enhancement of application control based on intercepted application data
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
-
- 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/2866—Architectures; Arrangements
- H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
Abstract
【課題】ネットワークストレージの台数増加にともない集中管理型サーバがボトルネックになりシステムのスケーラビリティを阻害する。専用のネットワークストレージを用いる場合には、既存のネットワークストレージを仮想化できない。
【解決手段】３０１によりクライアントからのＲＥＡＤＤＩＲ要求を受信した後、３０２により受信したＲＥＡＤＤＩＲ要求を各ネットワークストレージに転送し、３０３により各ネットワークストレージからのＲＥＡＤＤＩＲ応答を受信し、３０４により受信した各ネットワークストレージからのＲＥＡＤＤＩＲ応答を結合し、３０５により結合したＲＥＡＤＤＩＲ応答をクライアントに送信することにより、専用のネットワークストレージ、集中管理型サーバ、分散ディレクトリを用いずに、汎用のネットワークストレージとネットワークストレージアクセス用プロトコルの処理によりネットワークストレージ仮想化が実現できる。
【選択図】 図３
【解決手段】３０１によりクライアントからのＲＥＡＤＤＩＲ要求を受信した後、３０２により受信したＲＥＡＤＤＩＲ要求を各ネットワークストレージに転送し、３０３により各ネットワークストレージからのＲＥＡＤＤＩＲ応答を受信し、３０４により受信した各ネットワークストレージからのＲＥＡＤＤＩＲ応答を結合し、３０５により結合したＲＥＡＤＤＩＲ応答をクライアントに送信することにより、専用のネットワークストレージ、集中管理型サーバ、分散ディレクトリを用いずに、汎用のネットワークストレージとネットワークストレージアクセス用プロトコルの処理によりネットワークストレージ仮想化が実現できる。
【選択図】 図３
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークストレージ仮想化方法に関し、特にクライアントからの要求を複数のネットワークストレージに転送し、ネットワークストレージからの応答を結合してクライアントに送信する、ストレージ仮想化方法に関する。
【０００２】
【従来の技術】
従来の情報処理システムでは、計算機システムに直接接続したストレージに情報を格納していた。ストレージに格納した情報は直接接続した計算機のみからアクセス可能なため、他の計算機システムから情報にアクセスするためには直接接続した計算機を経由する必要があった。しかし近年のネットワーク技術の発達と格納すべき情報量の飛躍的な増大により、情報を処理する計算機システムと情報を格納するストレージシステムの分離の動きが進み、ネットワークに接続し複数の計算機システムで情報を共有できるストレージシステムが出現してきた。このようなネットワークに接続するストレージをネットワークストレージと呼ぶ。
【０００３】
このようなネットワークストレージの例として、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）で接続してブロックアクセスを提供するＳＡＮストレージ、ＩＰネットワークやＩｎｆｉｎｉｂａｎｄ等で接続してファイルアクセスを提供するＮＡＳ（Ｎｅｔｗｏｒｋ ＡｔｔａｃｈｅｄＳｔｏｒａｇｅ）、ＷｅｂアクセスのインタフェースであるＨＴＴＰプロトコルやそれを拡張したプロトコルでのアクセス形態を提供するＷｅｂストレージなどがある。
【０００４】
ネットワークストレージの普及につれ、システム管理者はネットワークに接続した複数のネットワークストレージを管理する必要が出て来ている。例えば、格納すべきデータ量が既存のネットワークストレージの最大値を超えるような場合には、新たなネットワークストレージを追加しデータの再分配などのシステム再構築が必要になる。ストレージ容量に対する需要の急激な伸びは度重なるシステム再構築を強いるため、システム管理コストを膨張させてきた。
【０００５】
システム管理コストの抑制には、複数のネットワークストレージを計算機システムから仮想的にひとつに見せ、新たな装置の追加を行なってもシステム全体に影響が及ばないようにするストレージの仮想化技術が必須となっている。このようなストレージの仮想化技術に関しては種々の方式が開発され、提案されている
例えば、１９９５年にＨａｒｔｍａｎらが発表したＺｅｂｒａシステム（Ｔｈｅ Ｚｅｂｒａ ＳｔｒｉｐｅｄＮｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ， Ｈａｒｔｍａｎ ｅｔ． ａｌ．， ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ ＣｏｍｐｕｔｅｒＳｙｓｔｅｍ， ｖｏｌ． １３， Ｎｏ． ３， １９９５， ｐｐ． ２７４−３１０．）では、ひとつのファイルを複数のネットワークストレージに分散格納する方式を提案している。ファイルを一定の長さごとに分割し、ネットワークストレージにラウンド・ロビン方式で順次格納する。Ｚｅｂｒａではファイルがどのストレージにどのような順番で分散格納しているか集中管理するサーバがあり、ファイルアクセス処理時にはこの管理サーバにファイルの格納位置に関する情報を問い合わせてからデータをアクセスするという特長がある。すなわち、ファイルを複数のサーバに分散格納させて一つのサーバで集中管理することにより複数のネットワークストレージを仮想的に一つの大きいネットワークストレージに見せる効果がある。
【０００６】
また、Ａｌｅｘａｎｄｅｒ Ｈ． ＦｒａｙらはＺｅｂｒａの集中管理サーバ方式と異なる非集中管理サーバ方式によりファイルのストライピングを行なう方法を提案している（ＵＳＰ６，０２９，１６８、Ｆｉｌｅｄ： １９９８／０１／２３）。この方式では、ファイルのストライピング情報が格納されているスタータノード情報をファイル識別子に埋め込むことでＺｅｂｒａで集中管理していたストライピング情報を複数のネットワークストレージで分散管理している。ファイル識別子にスタータノードを格納するため、ファイルアクセスの際にはまずスタータノードへアクセスを行ない、そこで、ファイルの格納位置を決定し、必要があればアクセスすべきファイルの断片（ブロック）を格納しているサーバへアクセス要求を転送して処理することが特徴となる。このため、クライアントからの当該ファイルについてのアクセスは、スタータノードへ要求を発行するだけで良く、ファイルのストライピングによる格納位置を考慮する必要がないという効果がある。
【０００７】
【発明が解決しようとする課題】
しかし、前記Ｚｅｂｒａシステムでは、アクセスするファイルの断片を格納するネットワークストレージを決定する際に集中管理サーバに問い合わせる必要があり、特にファイルの更新ではネットワークストレージ上のデータの他に集中管理サーバ上のデータも更新する必要がある。このため、ネットワークストレージの台数が増加すると集中管理サーバがボトルネックとなり、システムのスケーラビリティを阻害する原因となっていた。
【０００８】
また、Ａｌｅｘａｎｄｅｒらの非集中管理サーバ方式では、管理サーバが複数のサーバに分散されている点ではＺｅｂｒａの問題点を解決している。しかしながら、該システムではファイルアクセスする際にファイルを一意に特定するファイル名あるいはディレクトリ名とスタータノードが埋め込まれているファイル識別子との変換を分散ディレクトリ等のサーバが行なうことが前提となっており、ファイルの格納場所を管理するサーバ（スタータノード）とファイル名との対応を管理する情報が別途必要となっている。ＵＳＰ ６，０２９，１６８の実施例ではそのような情報を格納する手段としてとして ａ ”ｗｅｌｌ−ｋｎｏｗｎ” ｄｉｓｔｒｉｂｕｅｄ Ｄｉｒｅｃｔｏｒｙ ｆｉｌｅを利用すると述べている。また、ファイル識別子にスタータノードの位置が直接埋め込まれるため、新しいネットワークストレージを追加して既存のファイルのスタータノードを新しいネットワークストレージに移動する際には前記分散ディレクトリに格納されているファイル名とファイル識別子との対応情報を書きかえる必要があった。
【０００９】
さらに、これら従来の技術による方式では専用のネットワークストレージが必要であり、異なる形式のネットワークストレージを混在させて仮想化して運用することができない。つまり、管理コスト低減のため既に運用している複数の型式のネットワークストレージを仮想化して単一のネットワークストレージのイメージとして運用することが出来ず、既存のネットワークストレージの運用コストを低減することが出来ない問題がある。
【００１０】
また、管理サーバを用いる場合にはファイルの管理情報とデータ本体とが異なるサーバに格納されるため、どちらか一方のサーバに障害が発生してもファイルへのアクセスができなくなる問題がある。
【００１１】
【課題を解決するための手段】
本発明の目的の一つは、専用ではなく汎用のネットワークストレージのみによって仮想化が可能なネットワークストレージ仮想化方法を提供することであり、このような目的を実現する構成要件としては、例えば以下のような構成が考えられる。
【００１２】
クライアントからの要求を受信するステップと、第一のネットワークストレージおよび第二のネットワークストレージに受信した要求を転送するステップと、転送した要求に対する第一のネットワークストレージからの応答を受信するステップと、転送した要求に対する第二のネットワークストレージからの応答を受信するステップと、受信した第一のネットワークストレージの応答と受信した第二のネットワークストレージの応答とを結合するステップと、結合した応答を前記クライアントに送信するステップとを含む構成。
【００１３】
あるいは、受信したクライアントからの要求を複数のネットワークストレージに転送するステップと、転送した要求に対する複数のネットワークストレージからの応答を受信するステップと、受信した応答が正常かエラーかを判定するステップと、判定した応答の中で正常な応答のみを結合するステップとを含む構成であってもよい。
【００１４】
更にまた、受信したクライアントからの要求を複数のネットワークストレージに転送するステップと、転送した要求に対する複数のネットワークストレージからの応答を受信するステップと、受信した応答が正常かエラーかを判定するステップと、判定した応答の中で正常な応答の一つをクライアントへ送信するステップとを含む構成であっても良い。
【００１５】
また、本発明の目的を満たすネットワークストレージ仮想化方法としては、ネットワークストレージ識別情報とネットワークストレージの応答の中のアクセス識別子とを一時記憶用の領域に保存するステップとを含んでいても良い。あるいは、複数のネットワークストレージのエントリ情報の整合性管理を行う機能を有していても良い。
【００１６】
更にまた、本発明の目的を実現する構成の一つとしては、複数のネットワークストレージの動作状態を検出するステップと、障害検出時に障害情報を含んだエントリを生成するステップと、クライアントからの要求を受信するステップと、複数のネットワークストレージのうち正常に動作しているネットワークストレージのエントリ情報と生成した障害情報を含んだエントリ情報とを結合してアクセス要求に対する応答メッセージを生成するステップと、生成した応答メッセージを前記クライアントに送信するステップとを含んでいても良い。
【００１７】
また、仮想化している複数のネットワークストレージのエントリ情報と新しいネットワークストレージのエントリ情報との間の整合性を調査するステップと、不整合がある場合に新しいネットワークストレージ上の不整合のあるエントリ情報の識別子を変更するステップとを含む構成としても良い。
【００１８】
また、仮想化している複数のネットワークストレージ中の特定の一台のネットワークストレージを表す仮想的なエントリを生成するステップと、
クライアントからの要求が仮想的なエントリへの要求かを判定するステップと、
クライアントの要求が仮想的なエントリへの要求の場合にクライアントの要求を特定のネットワークストレージへ転送するステップとを含む構成であっても良い。
【００１９】
更にまた、本発明の目的を実現する構成要件の一つとして、複数のネットワークストレージへのアクセスの負荷分散を行う機能を含んでいても良い。
【００２０】
あるいは、複数のネットワークストレージを仮想化して運用するのに必要な情報を複数のネットワークストレージ上に保存するステップとを含む構成であっても良い。
【００２１】
更には、複数のネットワークストレージの識別子を登録するステップと、複数のネットワークストレージへアクセスするための情報を登録するステップと、複数のネットワークストレージの管理者情報を登録するステップとを含む構成であっても良い。
【００２２】
【発明の実施の形態】
発明の実施の形態について図面を参照して説明する。同一の参照番号は同一の構成要素を示す。なお、以下の実施例において、ＲＥＡＤＤＩＲとは、ＮＦＳ（ＮｅｔｗｏｒｋＦｉｌｅ Ｓｙｓｔｅｍ） でディレクトリから任意の数のエントリを順番に取りだし、クライアントがそれ以降のＲＥＡＤＤＩＲ要求で他のエントリを要求するための情報とともに、名前とファイルの識別子を返す動作を意味する。また、ＬＯＯＫＵＰとは、ある名前のディレクトリを検索し、該当するファイルシステムオブジェクトのファイルハンドルと属性を返す動作を意味する。更に、エントリとはディレクトリに格納されたファイルやディレクトリに関する情報を保持する記憶単位を意味するものとする。
【００２３】
図１は、本発明によるネットワークストレージ仮想化方法の実施の形態のアーキテクチャのブロック図である。図１において、１００は本発明によるネットワークストレージ仮想化方法の実施の形態のアーキテクチャ、１０１は演算装置、１０２はメモリ、１０３はＬＡＮ接続インタフェース、１１１はＲＥＡＤＤＩＲ処理ハンドラ、１１２はＬＯＯＫＵＰ処理ハンドラ、１１３はＲＥＡＤ処理ハンドラ、１１４はＷＲＩＴＥ処理ハンドラ、１１５はＣＲＥＡＴＥ処理ハンドラ、１１６は動作モニタ処理ハンドラ、１１７は障害処理ハンドラ、１１８は負荷モニタ処理ハンドラ、１１９は特殊エントリ管理処理ハンドラ、である。
【００２４】
図２は、本発明によるネットワークストレージ仮想化方法の実施の形態のネットワーク接続図である。図２において、２００は本発明によるネットワークストレージ仮想化方法の実施の形態のネットワーク接続図、２０１はクライアント、２０２は本発明のネットワークストレージ仮想化方法の実施の形態によるネットワークストレージ仮想化用コントローラ、２１１は第１のネットワークストレージ、２１２は第２のネットワークストレージ、２１３は第３のネットワークストレージ、である。
【００２５】
図３は、本発明によるネットワークストレージ仮想化方法の実施の形態のＲＥＡＤＤＩＲ処理ハンドラ１１１のフロー図である。図３において、３０１はクライアントからのＲＥＡＤＤＩＲ要求受信ステップ、３０２は、ＲＥＡＤＤＩＲ要求の各ネットワークストレージへの転送ステップ、３０３は各ネットワークストレージからのＲＥＡＤＤＩＲ応答受信ステップ、３０４は各ネットワークストレージからのＲＥＡＤＤＩＲ応答結合ステップ、３０５はクライアントへのＲＥＡＤＤＩＲ応答送信ステップ、である。
【００２６】
図４は、本発明によるネットワークストレージ仮想化方法の実施の形態のＬＯＯＫＵＰ処理ハンドラ１１１のフロー図である。図４において、４０１はクライアントからのＬＯＯＫＵＰ要求受信ステップ、４０２はＬＯＯＫＵＰ要求の各ネットワークストレージへの転送ステップ、４０３は各ネットワークストレージからのＬＯＯＫＵＰ応答受信ステップ、４０４はクライアントへの正常なＬＯＯＫＵＰ応答転送ステップ、である。
【００２７】
図５は、本発明によるネットワークストレージ仮想化方法の実施の形態のＲＥＡＤ処理ハンドラ１１３のフロー図である。図５において、５０１はクライアントからのＲＥＡＤ要求受信ステップ、５０２はＲＥＡＤ要求の適切なネットワークストレージへの転送ステップ、５０３はネットワークストレージからのＲＥＡＤ応答受信ステップ、５０４はクライアントへのＲＥＡＤ応答転送ステップ、である。
【００２８】
図６は、本発明によるネットワークストレージ仮想化方法の実施の形態のＷＲＩＴＥ処理ハンドラ１１４のフロー図である。図６において、６０１はクライアントからのＷＲＩＴＥ要求受信ステップ、６０２はＷＲＩＴＥ要求の適切なネットワークストレージへの転送ステップ、６０３はネットワークストレージからのＷＲＩＴＥ応答受信ステップ、６０４はクライアントへのＷＲＩＴＥ応答転送ステップ、である。
【００２９】
図７は、本発明によるネットワークストレージ仮想化方法の実施の形態のＣＲＥＡＴＥ処理ハンドラ１１５のフロー図である。図７において、７０１はクライアントからのＣＲＥＡＴＥ要求受信ステップ、７０２はＣＲＥＡＴＥ要求の適切なネットワークストレージへの転送ステップ、７０３はネットワークストレージからのＣＲＥＡＴＥ応答受信ステップ、７０４はクライアントへのＣＲＥＡＴＥ応答転送ステップ、である。
【００３０】
図８は、本発明によるネットワークストレージ仮想化方法の実施の形態の負荷モニタ処理ハンドラ１１８のフロー図である。８０１はネットワークストレージのディスク容量調査ステップ、８０２はネットワークストレージのネットワーク帯域調査ステップ、８０３はネットワークストレージの負荷評価ステップ、８０４は特定ファイルへのアクセス状況調査ステップ、８０５はファイルの再配置ステップ、である。
【００３１】
本実施の形態では、クライアント２０１からネットワークストレージへの各種要求をコントローラ２０２が一旦受信し、コントローラ２０２がネットワークストレージ２１１、２１２、２１３に要求を転送し、ネットワークストレージ２１１、２１２、２１３からの応答をコントローラ２０２が結合または取捨選択した後に、クライアント２０１に送信するところに特徴がある。
【００３２】
ＲＦＣ１０９４、ＲＦＣ１８１３、ＲＦＣ３０１０などに記載のＮＦＳプロトコルのようなネットワークストレージアクセス用プロトコルでは、クライアントからネットワークストレージ上のファイルのデータにアクセスする際に、ファイル名ではなくファイルハンドルという値を用いる。ファイルハンドルはネットワークストレージ上でファイルと一対一に結び付く値で、ネットワークストレージが生成する。クライアントがファイルハンドルを取得するためには、ネットワークストレージに対してディレクトリからファイル名を取得するＲＥＡＤＤＩＲ要求や、ディレクトリを検索しファイル名に対応するファイルハンドルを取得するＬＯＯＫＵＰ要求などを発行する必要がある。
【００３３】
本実施の形態によるＲＥＡＤＤＩＲ要求の処理は以下のようになる。クライアント２０１はＲＥＡＤＤＩＲ処理要求を直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３でＲＥＡＤＤＩＲ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＲＥＡＤＤＩＲ処理ハンドラ１１１を呼び出す。
【００３４】
ＲＥＡＤＤＩＲ処理ハンドラ１１１ではクライアントからのＲＥＡＤＤＩＲ要求受信ステップ３０１の後、受信したＲＥＡＤＤＩＲ要求をステップ３０２でＬＡＮ接続インタフェース１０３によりネットワークストレージ２１１、２１２、２１３に転送する。コントローラ２０２が受信したクライアント２０１のＲＥＡＤＤＩＲ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、ネットワークストレージ２１１、２１２、２１３へ転送する際に、送信元をコントローラ２０２に変更し、受信先をそれぞれネットワークストレージ２１１、２１２、２１３に変更する。また、これらの送受信関係以外の付加的な情報についても必要に応じて変更する。これにより、ネットワークストレージ２１１、２１２、２１３は通常のファイルアクセスプロトコルのみでアクセス可能であり、専用のネットワークストレージが不要になる効果がある。また同時に集中管理型サーバや分散ディレクトリが不要になる効果がある。
【００３５】
ネットワークストレージ２１１、２１２、２１３は受信したＲＥＡＤＤＩＲ要求を処理した後、コントローラ２０２にＲＥＡＤＤＩＲ応答を返す。コントローラ２０２はステップ３０３でＬＡＮ接続インタフェース１０３によりネットワークストレージ２１１、２１２、２１３からのＲＥＡＤＤＩＲ応答を受信した後、ステップ３０４でＲＥＡＤＤＩＲ応答を結合する。例えば、ネットワークストレージ２１１がｆｉｌｅ１、ｆｉｌｅ２、ｆｉｌｅ３の情報を返し、ネットワーク２１２がｆｉｌｅＡ、ｆｉｌｅＢ、ｆｉｌｅＣの情報を返し、ネットワークストレージ２１３がｆｉｌｅα、ｆｉｌｅβ、ｆｉｌｅγの情報を返す場合には、コントローラ２０２ではこれらの応答を結合し、ｆｉｌｅ１、ｆｉｌｅ２、ｆｉｌｅ３、ｆｉｌｅＡ、ｆｉｌｅＢ、ｆｉｌｅＣ、ｆｉｌｅα、ｆｉｌｅβ、ｆｉｌｅγの情報からなる応答を生成する。ステップ３０４で応答を結合した後、ステップ３０５でＬＡＮ接続インタフェース１０３により結合した応答をクライアント２０１に送信する。この時クライアント２０１からのＲＥＡＤＤＩＲ要求に対する応答にするため、送信元をコントローラ２０２、受信先をクライアント２０１にし、さらに必要に応じて付加的な情報の値を決定する。ネットワークストレージ２１１、２１２、２１３からの応答を結合した結果、クライアント２０１に一度に送れないような長大な応答になる場合には、ファイルアクセスプロトコルに従い応答を分割して送信する。
【００３６】
このようなＲＥＡＤＤＩＲ要求処理により、複数のネットワークストレージ上に存在するファイルがクライアントからは一つのネットワークストレージ上に存在するように見え、ネットワークストレージを仮想的に一台のネットワークストレージのイメージで運用できる効果がある。さらに、ネットワークストレージに障害が発生した場合には、そのネットワークストレージ上のファイルへのアクセスができなくなるが、ファイル管理情報とファイル本体が同一のネットワークストレージで閉じており、他のネットワークストレージに関する情報を管理しないため、ネットワークストレージに発生した障害の影響が他のネットワークストレージに伝播せず、サービスを続行できる効果がある。また、どのファイルがどのネットワークストレージ上に存在するかをコントローラが管理しないため、コントローラ２０２に障害が発生した場合にはコントローラ２０２を入れ替えるだけで簡単に障害から復帰できる効果がある。
【００３７】
本実施の形態によるＬＯＯＫＵＰ要求の処理は以下のようになる。クライアント２０１のＬＯＯＫＵＰ処理要求は直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３でＬＯＯＫＵＰ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＬＯＯＫＵＰ処理ハンドラ１１２を呼び出す。
【００３８】
ＬＯＯＫＵＰ処理ハンドラ１１２ではクライアントからのＬＯＯＫＵＰ要求受信ステップ４０１の後、ステップ４０２で受信したＬＯＯＫＵＰ要求をＬＡＮ接続インタフェース１０３によりネットワークストレージ２１１、２１２、２１３に転送する。コントローラ２０２が受信したクライアント２０１のＬＯＯＫＵＰ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、ネットワークストレージ２１１、２１２、２１３へ転送する際には、送信元をコントローラ２０２に変更し、受信先をそれぞれネットワークストレージ２１１、２１２、２１３に変更する。また、これらの送受信関係以外の付加的な情報についても必要に応じて変更する。これにより、ネットワークストレージ２１１、２１２、２１３は通常のファイルアクセスプロトコルのみでアクセス可能であり、専用のネットワークストレージが不要になる効果がある。
【００３９】
ネットワークストレージ２１１、２１２、２１３は受信したＬＯＯＫＵＰ要求を処理した後、コントローラ２０２にＬＯＯＫＵＰ応答を返す。コントローラ２０２はステップ４０３でＬＡＮ接続インタフェース１０３によりネットワークストレージ２１１、２１２、２１３からのＬＯＯＫＵＰ応答を受信する。ＬＯＯＫＵＰ要求はファイル名に対するファイルハンドルを検索する要求であるため、ネットワークストレージ２１１、２１２、２１３に対してＬＯＯＫＵＰ要求を転送しても、ファイルが存在しない場合にはエラーを返す。本実施の形態では後述するＣＲＥＡＴＥ要求処理で、複数のネットワークストレージの同一ファイル名が一つしか存在しないよう保証するため、複数のネットワークストレージからのＬＯＯＫＵＰ要求に対する正常応答は高々一つになる。そこで正常なＬＯＯＫＵＰ応答をステップ４０４でＬＡＮ接続インタフェース１０３によりクライアントに転送する。この時クライアント２０１からのＬＯＯＫＵＰ要求に対する応答にするため、送信元をコントローラ２０２、受信先をクライアント２０１にし、さらに付加的な情報の値を決定する。ネットワークストレージ２１１、２１２、２１３が全てエラー応答を返した場合には、クライアント２０１が要求したファイル名が存在しないか、そのファイル名を保存するネットワークストレージに障害が発生した場合である。その場合には、クライアント２０１への応答としてエラーを返す。
【００４０】
このようなＬＯＯＫＵＰ要求処理により、ＲＥＡＤＤＩＲ要求処理の場合と同様の効果がある。
【００４１】
ＲＥＡＤＤＩＲ要求やＬＯＯＫＵＰ要求によりクライアントがファイルハンドルを取得すると、そのファイルハンドルに基づきクライアントがＲＥＡＤ／ＷＲＩＴＥ要求を発行する。ファイルハンドルは一つのネットワークストレージ上では一意であるが、複数のネットワークストレージでは一意とは限らず同一のファイルハンドルが異なるネットワークストレージ上に存在する可能性がある。本実施の形態によりネットワークストレージを仮想化し単一のネットワークストレージのイメージで運用するためには、ファイルハンドルに対応するネットワークストレージを特定できる仕組みが必要になる。
【００４２】
解決する一つの手法として、ネットワークストレージ２１１、２１２、２１３が応答として返したファイルハンドルをネットワークストレージのホスト名やＩＰアドレスなどネットワークストレージに固有の情報を用いて符号化してクライアント２０１に送信する手法がある。ネットワークストレージ２１１、２１２、２１３には同一のファイルハンドルが存在する可能性があるが、これによりクライアント２０１が同一のファイルハンドルを受信しなくなる。ただし、通常ファイルハンドルは３２バイトや６４バイトなどの有限の値であるため、異なるネットワークストレージの異なるファイルハンドルを符号化した結果、同一の値になる可能性がある。このような場合には次に述べるキャッシュを併用することで解決できる。詳細は後述する。
【００４３】
また別の解決手法として、ファイルハンドルをキャッシュする手法がある。ネットワークストレージからＲＥＡＤＤＩＲ応答やＬＯＯＫＵＰ応答を受信した際に、ファイル名、ファイルハンドル、そのファイルハンドルを返したネットワークストレージに固有な情報をキャッシュしておくことで、クライアントからファイルハンドルを用いたＲＥＡＤ／ＷＲＩＴＥ要求を受信した時に、キャッシュのファイルハンドルとネットワークストレージの対応を調べることで、どのネットワークストレージのファイルハンドルかを特定できる。
【００４４】
また、本実施の形態によるＬＯＯＫＵＰ要求処理の際に、複数のネットワークストレージから同一のファイルハンドルが返る可能性がある。この場合には、上記のファイルハンドルの符号化とファイルハンドルのキャッシュを組み合わせることで解決できる。つまり、ファイルハンドルをネットワークストレージに固有な情報で符号化した値をクライアントに送信するファイルハンドルとしてキャッシュする。前述した符号化後のファイルハンドルが同一の値になる可能性がある問題を解決するためには、キャッシュ全体で符号化したファイルハンドルの一意性を調べ、同一のファイルハンドルが存在する場合には、その部分にのみさらに符号化を行う。こうすればキャッシュ全体でのファイルハンドルの一意性を保証できる。
【００４５】
本実施の形態によるファイルのＲＥＡＤ／ＷＲＩＴＥ要求の処理は以下のようになる。まずＲＥＡＤ要求の処理について説明する。クライアント２０１のＲＥＡＤ処理要求は直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３によりＲＥＡＤ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＲＥＡＤ処理ハンドラ１１３を呼び出す。
【００４６】
コントローラ２０２は前述のファイルハンドラの符号化やキャッシュにより、ファイルハンドルに対応するネットワークストレージを特定できる。そこで、ステップ５０１でクライアントからのＲＥＡＤ要求を受信した後、ステップ５０２でＬＡＮ接続インタフェース１０３によりＲＥＡＤ要求を適切なネットワークストレージに転送する。コントローラ２０２が受信したクライアント２０１のＲＥＡＤ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、適切なネットワークストレージに転送する際には、送信元をコントローラ２０２に変更し、受信先を適切なネットワークストレージに変更する。また、ファイルハンドルが符号化されている場合には復号化する。さらにまた、これら以外の付加的な情報についても必要に応じて変更する。次に、ステップ５０３でＬＡＮ接続インタフェース１０３によりネットワークストレージからのＲＥＡＤ応答を受信する。最後にステップ５０４でＬＡＮ接続インタフェース１０３により受信した応答をクライアント２０１に転送する。この時、送信元をコントローラ２０２に変更し、受信先をクライアント２０１に変更する。さらにこれら以外の付加的な情報についても必要に応じて変更する。
【００４７】
これにより、ネットワークストレージ２１１、２１２、２１３は通常のファイルアクセスプロトコルのみでアクセス可能であり、専用のネットワークストレージが不要になる効果がある。さらにクライアントからのＲＥＡＤ要求の際のコントローラ２０２の処理はＲＥＡＤ要求と応答の書き換えと転送だけであり、実際のファイルの読み出しは各ネットワークストレージが行うため、コントローラ２０２への負荷を低減できる効果がある。
【００４８】
ＷＲＩＴＥ要求の処理についてもＲＥＡＤ処理ハンドル１１３を呼び出す代りにＷＲＩＴＥ処理ハンドル１１４を呼び出す点を除き、ＲＥＡＤ要求処理の場合と同様である。クライアント２０１のＷＲＩＴＥ処理要求は直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３によりＷＲＩＴＥ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＷＲＩＴＥ処理ハンドラ１１４を呼び出す。
【００４９】
コントローラ２０２は前述のファイルハンドラの符号化やキャッシュにより、ファイルハンドルに対応するネットワークストレージを特定できる。そこで、ステップ６０１でクライアントからのＷＲＩＴＥ要求を受信した後、ステップ６０２でＬＡＮ接続インタフェース１０３によりＷＲＩＴＥ要求を適切なネットワークストレージに転送する。コントローラ２０２が受信したクライアント２０１のＷＲＩＴＥ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、適切なネットワークストレージに転送する際には、送信元をコントローラ２０２に変更し、受信先を適切なネットワークストレージに変更する。また、ファイルハンドルが符号化されている場合には復号化する。さらにまた、これら以外の付加的な情報についても必要に応じて変更する。次に、ステップ６０３でＬＡＮ接続インタフェース１０３によりネットワークストレージからのＷＲＩＴＥ応答を受信する。最後にステップ６０４でＬＡＮ接続インタフェース１０３により受信した応答をクライアント２０１に転送する。この時、送信元をコントローラ２０２に変更し、受信先をクライアント２０１に変更する。さらにこれら以外の付加的な情報についても必要に応じて変更する。
【００５０】
このようなＷＲＩＴＥ要求処理により、ＲＥＡＤ要求処理の場合と同様の効果がある。
【００５１】
ＣＲＥＡＴＥ要求によりファイルを新規に作成する場合には、ネットワークストレージの負荷を平均化するようにネットワークストレージを選択してファイルを作成するのが望ましい。そこで本実施の形態によるＣＲＥＡＴＥ要求処理は以下のようになる。クライアント２０１のＣＲＥＡＴＥ処理要求は直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３でＣＲＥＡＴＥ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＣＲＥＡＴＥ処理ハンドラ１１５を呼び出す。
【００５２】
コントローラ２０２は後述する負荷モニタ処理ハンドラ１１８によって、最も負荷の小さなネットワークストレージを特定できる。そこで、ステップ７０１でクライアントからのＣＲＥＡＴＥ要求を受信した後、ステップ７０２でＬＡＮ接続インタフェース１０３によりＣＲＥＡＴＥ要求を負荷の小さい適切なネットワークストレージに転送する。コントローラ２０２が受信したクライアント２０１のＣＲＥＡＴＥ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、適切なネットワークストレージに転送する際には、送信元をコントローラ２０２に変更し、受信先を適切なネットワークストレージに変更する。また、これら以外の付加的な情報についても必要に応じて変更する。次に、ステップ７０３でＬＡＮ接続インタフェース１０３によりネットワークストレージからのＣＲＥＡＴＥ応答を受信する。最後にステップ７０４でＬＡＮ接続インタフェース１０３により受信した応答をクライアント２０１に転送する。この時、送信元をコントローラ２０２に変更し、受信先をクライアント２０１に変更する。また必要に応じてネットワークストレージが返したファイルハンドルを前述の手法により符号化し、さらにこれら以外の付加的な情報についても必要に応じて変更する。
【００５３】
このようなＣＲＥＡＴＥ要求処理により、ＲＥＡＤ／ＷＲＩＴＥ要求処理の場合と同様の効果に加え、ネットワークストレージの負荷を均等化する効果がある。
【００５４】
ネットワークストレージ２１１、２１２、２１３の負荷は負荷モニタ処理ハンドラ１１８によって調査する。このハンドラはコントローラ２０２が定期的に実行し、内容を常に更新する。負荷モニタ処理ハンドラ１１８が起動すると、まずステップ８０１によりネットワークストレージ２１１、２１２、２１３のディスクの使用状況調査を行う。これにより、各ネットワークストレージのディスク使用率Ｕ％を求める。次にステップ８０２によりネットワークストレージ２１１、２１２、２１３のネットワーク帯域使用状況調査を行う。これによって、各ネットワークストレージのネットワーク帯域使用率Ｂ％を求める。次に、ステップ８０３で別途定めるディスク容量とネットワーク帯域のどちらを優先して評価するかを定めるパラメータα、βを用いて、評価式α＊Ｕ＋β＊Ｂにより各ネットワークストレージの負荷を評価する。評価式の値が大きいほどネットワークストレージの負荷が大きいことを意味する。ただし、ここでα、βは正数とする。ここで評価した各ネットワークストレージの負荷はＣＲＥＡＴＥ要求処理で新たにファイルを作成する場合のネットワークストレージ選択基準として使用する。 ネットワークストレージ２１１、２１２、２１３の負荷の最大値をｍａｘ（α＊Ｕ＋β＊Ｂ）、最小値をｍｉｎ（α＊Ｕ＋β＊Ｂ）とする。負荷の偏りの許容度パラメータδを用いて、評価式ｍａｘ（α＊Ｕ＋β＊Ｂ）−ｍｉｎ（α＊Ｕ＋β＊Ｂ）＜δを満たすように、ＣＲＥＡＴＥ要求でファイルを作成するネットワークストレージを選択する。
【００５５】
ここで、「負荷の偏りの許容度」とは、システム内の構成要素にかかる負荷の最大と最小でどの程度の差を許容するかの度合いをいう。システム内の構成要素としては、例えばディスク容量などが考えられ、ディスク容量の使用状況の最大と最小でどの程度の差を許容するかを「負荷の偏りの許容度」と表現する。なお、負荷は容量に限らず、プロセッサ使用状況、ネットワーク帯域の使用状況など色々な負荷について考えることができる。許容度は種々の方法で表現可能だが、本実施例では、パラメータδを用いて表現している。
【００５６】
次にステップ８０４により特定ファイルへのアクセス状況を調査する。各ネットワークストレージについて、ネットワークストレージへのアクセス頻度ＦＮを調べる。別途定めるネットワークストレージにどの程度のアクセス集中の許容度パラメータγを用いて、各ネットワークストレージについて評価式ＦＮ＞γを評価し、この式が成り立つ場合には、そのネットワークストレージの個々のファイルのアクセス頻度ＦＦを調査する。
【００５７】
ここで、「アクセス集中の許容度」とは、システムが、どの程度のアクセス集中を許容するかの度合いを言う。ファイルサーバのプロセッサ使用状況、ネットワーク帯域の使用状況、ディスク容量、ディスクアクセスの頻度などが高くなる状態を「アクセス集中」と呼ぶが、このような状態ではシステムの性能が急激に悪化するため、ある程度以上アクセスが集中しないように制御する必要がある。許容度は種々の方法で表現可能だが、本実施例では、パラメータγを用いて表現している。
【００５８】
最後にステップ８０４でＦＦの大きなファイルからＦＮの小さなストレージに移動し、ＦＮを再評価しＦＮを均等化する。
【００５９】
これらにより、ファイル新規作成時の以外の場合、特にアクセス頻度の高い複数のファイルが同一のネットワークストレージに保存されていてホットスポットが発生した場合であっても、ホットスポットの原因となるファイルを移動することで、各ネットワークストレージ負荷を均等化する効果がある。
【００６０】
動作モニタハンドラ１１６はネットワークストレージ２１１、２１２、２１３が正常に動作しているかどうかを監視する。あるネットワークストレージが動作していない場合には、特殊エントリ管理ハンドラ１１９を呼び出し、ネットワークストレージが動作していないことを伝えるための仮想的なファイルエントリを作成する。この特殊エントリはファイル名としてネットワークストレージの障害情報通知用の仮想ファイルと認識できる情報を含む。この仮想的なファイルエントリはネットワークストレージ２１１、２１２、２１３には存在しないことを除き、通常のファイルと同様にアクセスできる。
【００６１】
これにより、コントローラ２０２を管理するための専用のコンソールなどを用いることなく、クライアントはネットワークストレージの障害を知ることができる効果がある。
【００６２】
障害処理ハンドラ１１７は障害の発生していたネットワークストレージが復帰した時の整合性管理を行う。ここで、「整合性」とは、複数ＮＡＳに存在する同一ディレクトリ名の下に同一ファイル名が複数していない状態を「整合性」があると言う。また、同一ディレクトリ上に同一ファイル名が複数存在する状態（実際のファイルは異なるＮＡＳ上に作られる）を「不整合」があると言う。不整合が発生する原因としては、ＮＡＳに障碍が発生している場合などが考えられる。正常動作しているＮＡＳの下に障碍の発生したＮＡＳ上に存在するのと同一のファイル名を持つファイルが作られる可能性があるためである。
本実施の形態によるネットワークストレージ仮想化方法では、クライアントがＣＲＥＡＴＥ要求によりファイルを作成する際に、同一ディレクトリ上に同一ファイル名が高々一つしかないことを保証する。しかしネットワークストレージに障害が発生しアクセス不能になった場合には、ネットワークストレージが障害から復帰した際に同一ファイル名が存在する、整合性が取れていない状態になる可能性がある。この問題を解決するため、障害処理ハンドラ１１７は以下のように動作する。
【００６３】
障害から復帰したネットワークストレージとその他のネットワークストレージについて同一ディレクトリ上に同一ファイル名が存在しないか調査する。同一ファイル名が存在する場合には、障害から復帰したネットワークストレージ上のファイル名を元のファイル名と障害復帰情報を含むファイル名に変更する。障害復帰情報としては、例えばネットワークストレージ固有の情報と復帰時刻などがある。別の手法としては、障害から復帰したネットワークストレージ上にディレクトリ名に障害復帰情報を含んだディレクトリを作成し、そこにファイルを移動する手法がある。
【００６４】
コントローラ２０２にネットワークストレージを増設する際には、仮想化済みのネットワークストレージ群との間でファイル名の重複ないかを調べる整合性調査が必要になるが、このような場合にも障害処理ハンドラ１１７がそのまま適用できる。
【００６５】
これらにより、コントローラ２０２を管理するための専用のコンソールなどを用いることなく、クライアントは障害から復帰したネットワークストレージに発生した整合性エラーを知ることができる効果がある。
【００６６】
特殊エントリ管理ハンドラ１１９は前述の障害情報通知用の仮想的なエントリ管理の他に、ネットワークストレージ２１１、２１２、２１３のなかのいずれか一台を指定してアクセスする必要がある場合の仮想的なディレクトリエントリを提供する。この特殊エントリはディレクトリ名として特定のネットワークへのアクセス用の仮想ディレクトリと認識できる情報を含む。この仮想ディレクトリへの各種アクセス要求は全て特定のネットワークストレージに転送する。この仮想的なディレクトリエントリはネットワークストレージ２１１、２１２、２１３には存在しないことを除き、通常のファイルと同様にアクセスできる。
【００６７】
これにより、コントローラ２０２を管理するための専用のコンソールなどを用いることなく、クライアントは特定のネットワークストレージを指定してファイルを移動することなどができる効果がある。この機能は例えばコントローラ２０２から特定のネットワークストレージを取り外す際に必要になる。 本実施の形態では、ＮＦＳプロトコルを仮定しているが、ＮＦＳ以外のプロトコルについても容易に適用可能である。
【００６８】
本実施の形態では、ファイルハンドルをネットワークストレージ固有の情報より符号化しているが、任意の符号化を利用できる。
【００６９】
本実施の形態では、負荷の要因としてディスク容量とネットワーク帯域を挙げているが、これら以外の負荷要素、例えばネットワークストレージのプロセッサ負荷や内部ディスク帯域など、任意の負荷要素に付いても同様に適用できる。
【００７０】
【発明の効果】
本発明を実施した場合の効果としては、専用ではなく汎用のネットワークストレージを用いてネットワークストレージ仮想化が可能になる効果がある。
【００７１】
また、本発明の範疇に含まれる種々の構成要件を付加することにより、以下のような効果も実現可能となる。例えば、集中管理型サーバや分散ディレクトリを用いずにネットワークストレージの仮想化が可能になる効果がある。
【００７２】
また、ネットワークストレージの障害発生時に障害の影響が他のサーバに伝播せずサービスを続行できる効果がある。
【００７３】
また、ネットワークストレージの仮想化を行うコントローラでファイルの存在場所の管理をしないため、コントローラで障害が発生した場合には、コントローラを交換するだけで障害から復帰できる効果がある。
【００７４】
また、ＲＥＡＤ／ＷＲＩＴＥ要求処理の際にネットワークストレージ仮想化を行うコントローラが行うのはＲＥＡＤ／ＷＲＩＴＥ要求と応答の書き換えだけであり、ネットワークストレージが実際のＲＥＡＤ／ＷＲＩＴＥ要求を処理するため、コントローラへの負荷を低減できる効果がある。
【００７５】
また、ファイルを新規に作成する際に、負荷の少ないネットワークストレージにＣＲＥＡＴＥ要求を転送することにより、ネットワークストレージの負荷を均等化する効果がある。
【００７６】
また、アクセス頻度の高いファイルが特定のネットワークストレージ上に保存されている場合、それらのファイルを他のネットワークストレージに移動することにより、ネットワークストレージの負荷を均等化する効果がある。
【００７７】
また同時に、障害情報通知用の仮想的なファイルエントリを作成することにより、クライアントは専用のコンソールを用いずにネットワークストレージの障害を知ることができる効果がある。
【００７８】
また、ネットワークストレージが障害から復帰する時にファイル名の整合性にエラーが発生した場合、障害のあったネットワークストレージ上のファイル名を障害復帰情報を含んだファイル名に変更することにより、クライアントは専用のコンソールを用いずにネットワークストレージに発生した整合性エラーを知ることができる効果がある。
【００７９】
また、ネットワークストレージ特定のネットワークストレージへのアクセスを指定する仮想的なディレクトリエントリを作成することにより、クライアントは専用のコントローラを用いずに特定のネットワークストレージを指定してファイルを移動することなどができる効果がある。
【図面の簡単な説明】
【図１】本発明によるネットワークストレージ仮想化方法の実施の形態のアーキテクチャのブロック図。
【図２】本発明によるネットワークストレージ仮想化方法の実施の形態のネットワーク接続図
【図３】本発明によるネットワークストレージ仮想化方法の実施の形態のＲＥＡＤＤＩＲ処理ハンドラ１１１のフロー図。
【図４】本発明によるネットワークストレージ仮想化方法の実施の形態のＬＯＯＫＵＰ処理ハンドラ１１２のフロー図。
【図５】本発明によるネットワークストレージ仮想化方法の実施の形態のＲＥＡＤ処理ハンドラ１１３のフロー図。
【図６】本発明によるネットワークストレージ仮想化方法の実施の形態のＷＲＩＴＥ処理ハンドラ１１４のフロー図。
【図７】本発明によるネットワークストレージ仮想化方法の実施の形態のＣＲＥＡＴＥ処理ハンドラ１１５のフロー図。
【図８】本発明によるネットワークストレージ仮想化方法の実施の形態の負荷モニタ処理ハンドラ１１８のフロー図。
【符号の説明】
１００ 本発明によるネットワークストレージ仮想化方法の実施の形態のアーキテクチャ
１０１ 演算装置
１０２ メモリ
１０３ ＬＡＮ接続インタフェース
１１１ ＲＥＡＤＤＩＲ処理ハンドラ
１１２ ＬＯＯＫＵＰ処理ハンドラ
１１３ ＲＥＡＤ処理ハンドラ
１１４ ＷＲＩＴＥ処理ハンドラ
１１５ ＣＲＥＡＴＥ処理ハンドラ
１１６ 動作モニタ処理ハンドラ
１１７ 障害処理ハンドラ
１１８ 負荷モニタ処理ハンドラ
１１９ 特殊エントリ管理処理ハンドラ
２００ 本発明によるネットワークストレージ仮想化方法の実施の形態のネットワーク接続図
２０１ クライアント
２０２ 本発明のネットワークストレージ仮想化方法の実施の形態によるネットワークストレージ仮想化用コントローラ
２１１ 第１のネットワークストレージ
２１２ 第２のネットワークストレージ
２１３ 第３のネットワークストレージ
３０１ クライアントからのＲＥＡＤＤＩＲ要求受信ステップ
３０２ ＲＥＡＤＤＩＲ要求の各ネットワークストレージへの転送ステップ
３０３ 各ネットワークストレージからのＲＥＡＤＤＩＲ応答受信ステップ
３０４ 各ネットワークストレージからのＲＥＡＤＤＩＲ応答結合ステップ
３０５ クライアントへのＲＥＡＤＤＩＲ応答送信ステップ
４０１ クライアントからのＬＯＯＫＵＰ要求受信ステップ
４０２ ＬＯＯＫＵＰ要求の各ネットワークストレージへの転送ステップ
４０３ 各ネットワークストレージからのＬＯＯＫＵＰ応答受信ステップ
４０４ クライアントへの正常なＬＯＯＫＵＰ応答転送ステップ
５０１ クライアントからのＲＥＡＤ要求受信ステップ
５０２ ＲＥＡＤ要求の適切なネットワークストレージへの転送ステップ
５０３ ネットワークストレージからのＲＥＡＤ応答受信ステップ
５０４ クライアントへのＲＥＡＤ応答転送ステップ
６０１ クライアントからのＷＲＩＴＥ要求受信ステップ
６０２ ＷＲＩＴＥ要求の適切なネットワークストレージへの転送ステップ
６０３ ネットワークストレージからのＷＲＩＴＥ応答受信ステップ
６０４ クライアントへのＷＲＩＴＥ応答転送ステップ
７０１ クライアントからのＣＲＥＡＴＥ要求受信ステップ
７０２ ＣＲＥＡＴＥ要求の適切なネットワークストレージへの転送ステップ
７０３ ネットワークストレージからのＣＲＥＡＴＥ応答受信ステップ
７０４ クライアントへのＣＲＥＡＴＥ応答転送ステップ
８０１ ネットワークストレージのディスク容量調査ステップ
８０２ ネットワークストレージのネットワーク帯域調査ステップ
８０３ ネットワークストレージの負荷評価ステップ
８０４ 特定ファイルへのアクセス状況調査ステップ
８０５ ファイルの再配置ステップ。
【発明の属する技術分野】
本発明は、ネットワークストレージ仮想化方法に関し、特にクライアントからの要求を複数のネットワークストレージに転送し、ネットワークストレージからの応答を結合してクライアントに送信する、ストレージ仮想化方法に関する。
【０００２】
【従来の技術】
従来の情報処理システムでは、計算機システムに直接接続したストレージに情報を格納していた。ストレージに格納した情報は直接接続した計算機のみからアクセス可能なため、他の計算機システムから情報にアクセスするためには直接接続した計算機を経由する必要があった。しかし近年のネットワーク技術の発達と格納すべき情報量の飛躍的な増大により、情報を処理する計算機システムと情報を格納するストレージシステムの分離の動きが進み、ネットワークに接続し複数の計算機システムで情報を共有できるストレージシステムが出現してきた。このようなネットワークに接続するストレージをネットワークストレージと呼ぶ。
【０００３】
このようなネットワークストレージの例として、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）で接続してブロックアクセスを提供するＳＡＮストレージ、ＩＰネットワークやＩｎｆｉｎｉｂａｎｄ等で接続してファイルアクセスを提供するＮＡＳ（Ｎｅｔｗｏｒｋ ＡｔｔａｃｈｅｄＳｔｏｒａｇｅ）、ＷｅｂアクセスのインタフェースであるＨＴＴＰプロトコルやそれを拡張したプロトコルでのアクセス形態を提供するＷｅｂストレージなどがある。
【０００４】
ネットワークストレージの普及につれ、システム管理者はネットワークに接続した複数のネットワークストレージを管理する必要が出て来ている。例えば、格納すべきデータ量が既存のネットワークストレージの最大値を超えるような場合には、新たなネットワークストレージを追加しデータの再分配などのシステム再構築が必要になる。ストレージ容量に対する需要の急激な伸びは度重なるシステム再構築を強いるため、システム管理コストを膨張させてきた。
【０００５】
システム管理コストの抑制には、複数のネットワークストレージを計算機システムから仮想的にひとつに見せ、新たな装置の追加を行なってもシステム全体に影響が及ばないようにするストレージの仮想化技術が必須となっている。このようなストレージの仮想化技術に関しては種々の方式が開発され、提案されている
例えば、１９９５年にＨａｒｔｍａｎらが発表したＺｅｂｒａシステム（Ｔｈｅ Ｚｅｂｒａ ＳｔｒｉｐｅｄＮｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ， Ｈａｒｔｍａｎ ｅｔ． ａｌ．， ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ ＣｏｍｐｕｔｅｒＳｙｓｔｅｍ， ｖｏｌ． １３， Ｎｏ． ３， １９９５， ｐｐ． ２７４−３１０．）では、ひとつのファイルを複数のネットワークストレージに分散格納する方式を提案している。ファイルを一定の長さごとに分割し、ネットワークストレージにラウンド・ロビン方式で順次格納する。Ｚｅｂｒａではファイルがどのストレージにどのような順番で分散格納しているか集中管理するサーバがあり、ファイルアクセス処理時にはこの管理サーバにファイルの格納位置に関する情報を問い合わせてからデータをアクセスするという特長がある。すなわち、ファイルを複数のサーバに分散格納させて一つのサーバで集中管理することにより複数のネットワークストレージを仮想的に一つの大きいネットワークストレージに見せる効果がある。
【０００６】
また、Ａｌｅｘａｎｄｅｒ Ｈ． ＦｒａｙらはＺｅｂｒａの集中管理サーバ方式と異なる非集中管理サーバ方式によりファイルのストライピングを行なう方法を提案している（ＵＳＰ６，０２９，１６８、Ｆｉｌｅｄ： １９９８／０１／２３）。この方式では、ファイルのストライピング情報が格納されているスタータノード情報をファイル識別子に埋め込むことでＺｅｂｒａで集中管理していたストライピング情報を複数のネットワークストレージで分散管理している。ファイル識別子にスタータノードを格納するため、ファイルアクセスの際にはまずスタータノードへアクセスを行ない、そこで、ファイルの格納位置を決定し、必要があればアクセスすべきファイルの断片（ブロック）を格納しているサーバへアクセス要求を転送して処理することが特徴となる。このため、クライアントからの当該ファイルについてのアクセスは、スタータノードへ要求を発行するだけで良く、ファイルのストライピングによる格納位置を考慮する必要がないという効果がある。
【０００７】
【発明が解決しようとする課題】
しかし、前記Ｚｅｂｒａシステムでは、アクセスするファイルの断片を格納するネットワークストレージを決定する際に集中管理サーバに問い合わせる必要があり、特にファイルの更新ではネットワークストレージ上のデータの他に集中管理サーバ上のデータも更新する必要がある。このため、ネットワークストレージの台数が増加すると集中管理サーバがボトルネックとなり、システムのスケーラビリティを阻害する原因となっていた。
【０００８】
また、Ａｌｅｘａｎｄｅｒらの非集中管理サーバ方式では、管理サーバが複数のサーバに分散されている点ではＺｅｂｒａの問題点を解決している。しかしながら、該システムではファイルアクセスする際にファイルを一意に特定するファイル名あるいはディレクトリ名とスタータノードが埋め込まれているファイル識別子との変換を分散ディレクトリ等のサーバが行なうことが前提となっており、ファイルの格納場所を管理するサーバ（スタータノード）とファイル名との対応を管理する情報が別途必要となっている。ＵＳＰ ６，０２９，１６８の実施例ではそのような情報を格納する手段としてとして ａ ”ｗｅｌｌ−ｋｎｏｗｎ” ｄｉｓｔｒｉｂｕｅｄ Ｄｉｒｅｃｔｏｒｙ ｆｉｌｅを利用すると述べている。また、ファイル識別子にスタータノードの位置が直接埋め込まれるため、新しいネットワークストレージを追加して既存のファイルのスタータノードを新しいネットワークストレージに移動する際には前記分散ディレクトリに格納されているファイル名とファイル識別子との対応情報を書きかえる必要があった。
【０００９】
さらに、これら従来の技術による方式では専用のネットワークストレージが必要であり、異なる形式のネットワークストレージを混在させて仮想化して運用することができない。つまり、管理コスト低減のため既に運用している複数の型式のネットワークストレージを仮想化して単一のネットワークストレージのイメージとして運用することが出来ず、既存のネットワークストレージの運用コストを低減することが出来ない問題がある。
【００１０】
また、管理サーバを用いる場合にはファイルの管理情報とデータ本体とが異なるサーバに格納されるため、どちらか一方のサーバに障害が発生してもファイルへのアクセスができなくなる問題がある。
【００１１】
【課題を解決するための手段】
本発明の目的の一つは、専用ではなく汎用のネットワークストレージのみによって仮想化が可能なネットワークストレージ仮想化方法を提供することであり、このような目的を実現する構成要件としては、例えば以下のような構成が考えられる。
【００１２】
クライアントからの要求を受信するステップと、第一のネットワークストレージおよび第二のネットワークストレージに受信した要求を転送するステップと、転送した要求に対する第一のネットワークストレージからの応答を受信するステップと、転送した要求に対する第二のネットワークストレージからの応答を受信するステップと、受信した第一のネットワークストレージの応答と受信した第二のネットワークストレージの応答とを結合するステップと、結合した応答を前記クライアントに送信するステップとを含む構成。
【００１３】
あるいは、受信したクライアントからの要求を複数のネットワークストレージに転送するステップと、転送した要求に対する複数のネットワークストレージからの応答を受信するステップと、受信した応答が正常かエラーかを判定するステップと、判定した応答の中で正常な応答のみを結合するステップとを含む構成であってもよい。
【００１４】
更にまた、受信したクライアントからの要求を複数のネットワークストレージに転送するステップと、転送した要求に対する複数のネットワークストレージからの応答を受信するステップと、受信した応答が正常かエラーかを判定するステップと、判定した応答の中で正常な応答の一つをクライアントへ送信するステップとを含む構成であっても良い。
【００１５】
また、本発明の目的を満たすネットワークストレージ仮想化方法としては、ネットワークストレージ識別情報とネットワークストレージの応答の中のアクセス識別子とを一時記憶用の領域に保存するステップとを含んでいても良い。あるいは、複数のネットワークストレージのエントリ情報の整合性管理を行う機能を有していても良い。
【００１６】
更にまた、本発明の目的を実現する構成の一つとしては、複数のネットワークストレージの動作状態を検出するステップと、障害検出時に障害情報を含んだエントリを生成するステップと、クライアントからの要求を受信するステップと、複数のネットワークストレージのうち正常に動作しているネットワークストレージのエントリ情報と生成した障害情報を含んだエントリ情報とを結合してアクセス要求に対する応答メッセージを生成するステップと、生成した応答メッセージを前記クライアントに送信するステップとを含んでいても良い。
【００１７】
また、仮想化している複数のネットワークストレージのエントリ情報と新しいネットワークストレージのエントリ情報との間の整合性を調査するステップと、不整合がある場合に新しいネットワークストレージ上の不整合のあるエントリ情報の識別子を変更するステップとを含む構成としても良い。
【００１８】
また、仮想化している複数のネットワークストレージ中の特定の一台のネットワークストレージを表す仮想的なエントリを生成するステップと、
クライアントからの要求が仮想的なエントリへの要求かを判定するステップと、
クライアントの要求が仮想的なエントリへの要求の場合にクライアントの要求を特定のネットワークストレージへ転送するステップとを含む構成であっても良い。
【００１９】
更にまた、本発明の目的を実現する構成要件の一つとして、複数のネットワークストレージへのアクセスの負荷分散を行う機能を含んでいても良い。
【００２０】
あるいは、複数のネットワークストレージを仮想化して運用するのに必要な情報を複数のネットワークストレージ上に保存するステップとを含む構成であっても良い。
【００２１】
更には、複数のネットワークストレージの識別子を登録するステップと、複数のネットワークストレージへアクセスするための情報を登録するステップと、複数のネットワークストレージの管理者情報を登録するステップとを含む構成であっても良い。
【００２２】
【発明の実施の形態】
発明の実施の形態について図面を参照して説明する。同一の参照番号は同一の構成要素を示す。なお、以下の実施例において、ＲＥＡＤＤＩＲとは、ＮＦＳ（ＮｅｔｗｏｒｋＦｉｌｅ Ｓｙｓｔｅｍ） でディレクトリから任意の数のエントリを順番に取りだし、クライアントがそれ以降のＲＥＡＤＤＩＲ要求で他のエントリを要求するための情報とともに、名前とファイルの識別子を返す動作を意味する。また、ＬＯＯＫＵＰとは、ある名前のディレクトリを検索し、該当するファイルシステムオブジェクトのファイルハンドルと属性を返す動作を意味する。更に、エントリとはディレクトリに格納されたファイルやディレクトリに関する情報を保持する記憶単位を意味するものとする。
【００２３】
図１は、本発明によるネットワークストレージ仮想化方法の実施の形態のアーキテクチャのブロック図である。図１において、１００は本発明によるネットワークストレージ仮想化方法の実施の形態のアーキテクチャ、１０１は演算装置、１０２はメモリ、１０３はＬＡＮ接続インタフェース、１１１はＲＥＡＤＤＩＲ処理ハンドラ、１１２はＬＯＯＫＵＰ処理ハンドラ、１１３はＲＥＡＤ処理ハンドラ、１１４はＷＲＩＴＥ処理ハンドラ、１１５はＣＲＥＡＴＥ処理ハンドラ、１１６は動作モニタ処理ハンドラ、１１７は障害処理ハンドラ、１１８は負荷モニタ処理ハンドラ、１１９は特殊エントリ管理処理ハンドラ、である。
【００２４】
図２は、本発明によるネットワークストレージ仮想化方法の実施の形態のネットワーク接続図である。図２において、２００は本発明によるネットワークストレージ仮想化方法の実施の形態のネットワーク接続図、２０１はクライアント、２０２は本発明のネットワークストレージ仮想化方法の実施の形態によるネットワークストレージ仮想化用コントローラ、２１１は第１のネットワークストレージ、２１２は第２のネットワークストレージ、２１３は第３のネットワークストレージ、である。
【００２５】
図３は、本発明によるネットワークストレージ仮想化方法の実施の形態のＲＥＡＤＤＩＲ処理ハンドラ１１１のフロー図である。図３において、３０１はクライアントからのＲＥＡＤＤＩＲ要求受信ステップ、３０２は、ＲＥＡＤＤＩＲ要求の各ネットワークストレージへの転送ステップ、３０３は各ネットワークストレージからのＲＥＡＤＤＩＲ応答受信ステップ、３０４は各ネットワークストレージからのＲＥＡＤＤＩＲ応答結合ステップ、３０５はクライアントへのＲＥＡＤＤＩＲ応答送信ステップ、である。
【００２６】
図４は、本発明によるネットワークストレージ仮想化方法の実施の形態のＬＯＯＫＵＰ処理ハンドラ１１１のフロー図である。図４において、４０１はクライアントからのＬＯＯＫＵＰ要求受信ステップ、４０２はＬＯＯＫＵＰ要求の各ネットワークストレージへの転送ステップ、４０３は各ネットワークストレージからのＬＯＯＫＵＰ応答受信ステップ、４０４はクライアントへの正常なＬＯＯＫＵＰ応答転送ステップ、である。
【００２７】
図５は、本発明によるネットワークストレージ仮想化方法の実施の形態のＲＥＡＤ処理ハンドラ１１３のフロー図である。図５において、５０１はクライアントからのＲＥＡＤ要求受信ステップ、５０２はＲＥＡＤ要求の適切なネットワークストレージへの転送ステップ、５０３はネットワークストレージからのＲＥＡＤ応答受信ステップ、５０４はクライアントへのＲＥＡＤ応答転送ステップ、である。
【００２８】
図６は、本発明によるネットワークストレージ仮想化方法の実施の形態のＷＲＩＴＥ処理ハンドラ１１４のフロー図である。図６において、６０１はクライアントからのＷＲＩＴＥ要求受信ステップ、６０２はＷＲＩＴＥ要求の適切なネットワークストレージへの転送ステップ、６０３はネットワークストレージからのＷＲＩＴＥ応答受信ステップ、６０４はクライアントへのＷＲＩＴＥ応答転送ステップ、である。
【００２９】
図７は、本発明によるネットワークストレージ仮想化方法の実施の形態のＣＲＥＡＴＥ処理ハンドラ１１５のフロー図である。図７において、７０１はクライアントからのＣＲＥＡＴＥ要求受信ステップ、７０２はＣＲＥＡＴＥ要求の適切なネットワークストレージへの転送ステップ、７０３はネットワークストレージからのＣＲＥＡＴＥ応答受信ステップ、７０４はクライアントへのＣＲＥＡＴＥ応答転送ステップ、である。
【００３０】
図８は、本発明によるネットワークストレージ仮想化方法の実施の形態の負荷モニタ処理ハンドラ１１８のフロー図である。８０１はネットワークストレージのディスク容量調査ステップ、８０２はネットワークストレージのネットワーク帯域調査ステップ、８０３はネットワークストレージの負荷評価ステップ、８０４は特定ファイルへのアクセス状況調査ステップ、８０５はファイルの再配置ステップ、である。
【００３１】
本実施の形態では、クライアント２０１からネットワークストレージへの各種要求をコントローラ２０２が一旦受信し、コントローラ２０２がネットワークストレージ２１１、２１２、２１３に要求を転送し、ネットワークストレージ２１１、２１２、２１３からの応答をコントローラ２０２が結合または取捨選択した後に、クライアント２０１に送信するところに特徴がある。
【００３２】
ＲＦＣ１０９４、ＲＦＣ１８１３、ＲＦＣ３０１０などに記載のＮＦＳプロトコルのようなネットワークストレージアクセス用プロトコルでは、クライアントからネットワークストレージ上のファイルのデータにアクセスする際に、ファイル名ではなくファイルハンドルという値を用いる。ファイルハンドルはネットワークストレージ上でファイルと一対一に結び付く値で、ネットワークストレージが生成する。クライアントがファイルハンドルを取得するためには、ネットワークストレージに対してディレクトリからファイル名を取得するＲＥＡＤＤＩＲ要求や、ディレクトリを検索しファイル名に対応するファイルハンドルを取得するＬＯＯＫＵＰ要求などを発行する必要がある。
【００３３】
本実施の形態によるＲＥＡＤＤＩＲ要求の処理は以下のようになる。クライアント２０１はＲＥＡＤＤＩＲ処理要求を直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３でＲＥＡＤＤＩＲ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＲＥＡＤＤＩＲ処理ハンドラ１１１を呼び出す。
【００３４】
ＲＥＡＤＤＩＲ処理ハンドラ１１１ではクライアントからのＲＥＡＤＤＩＲ要求受信ステップ３０１の後、受信したＲＥＡＤＤＩＲ要求をステップ３０２でＬＡＮ接続インタフェース１０３によりネットワークストレージ２１１、２１２、２１３に転送する。コントローラ２０２が受信したクライアント２０１のＲＥＡＤＤＩＲ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、ネットワークストレージ２１１、２１２、２１３へ転送する際に、送信元をコントローラ２０２に変更し、受信先をそれぞれネットワークストレージ２１１、２１２、２１３に変更する。また、これらの送受信関係以外の付加的な情報についても必要に応じて変更する。これにより、ネットワークストレージ２１１、２１２、２１３は通常のファイルアクセスプロトコルのみでアクセス可能であり、専用のネットワークストレージが不要になる効果がある。また同時に集中管理型サーバや分散ディレクトリが不要になる効果がある。
【００３５】
ネットワークストレージ２１１、２１２、２１３は受信したＲＥＡＤＤＩＲ要求を処理した後、コントローラ２０２にＲＥＡＤＤＩＲ応答を返す。コントローラ２０２はステップ３０３でＬＡＮ接続インタフェース１０３によりネットワークストレージ２１１、２１２、２１３からのＲＥＡＤＤＩＲ応答を受信した後、ステップ３０４でＲＥＡＤＤＩＲ応答を結合する。例えば、ネットワークストレージ２１１がｆｉｌｅ１、ｆｉｌｅ２、ｆｉｌｅ３の情報を返し、ネットワーク２１２がｆｉｌｅＡ、ｆｉｌｅＢ、ｆｉｌｅＣの情報を返し、ネットワークストレージ２１３がｆｉｌｅα、ｆｉｌｅβ、ｆｉｌｅγの情報を返す場合には、コントローラ２０２ではこれらの応答を結合し、ｆｉｌｅ１、ｆｉｌｅ２、ｆｉｌｅ３、ｆｉｌｅＡ、ｆｉｌｅＢ、ｆｉｌｅＣ、ｆｉｌｅα、ｆｉｌｅβ、ｆｉｌｅγの情報からなる応答を生成する。ステップ３０４で応答を結合した後、ステップ３０５でＬＡＮ接続インタフェース１０３により結合した応答をクライアント２０１に送信する。この時クライアント２０１からのＲＥＡＤＤＩＲ要求に対する応答にするため、送信元をコントローラ２０２、受信先をクライアント２０１にし、さらに必要に応じて付加的な情報の値を決定する。ネットワークストレージ２１１、２１２、２１３からの応答を結合した結果、クライアント２０１に一度に送れないような長大な応答になる場合には、ファイルアクセスプロトコルに従い応答を分割して送信する。
【００３６】
このようなＲＥＡＤＤＩＲ要求処理により、複数のネットワークストレージ上に存在するファイルがクライアントからは一つのネットワークストレージ上に存在するように見え、ネットワークストレージを仮想的に一台のネットワークストレージのイメージで運用できる効果がある。さらに、ネットワークストレージに障害が発生した場合には、そのネットワークストレージ上のファイルへのアクセスができなくなるが、ファイル管理情報とファイル本体が同一のネットワークストレージで閉じており、他のネットワークストレージに関する情報を管理しないため、ネットワークストレージに発生した障害の影響が他のネットワークストレージに伝播せず、サービスを続行できる効果がある。また、どのファイルがどのネットワークストレージ上に存在するかをコントローラが管理しないため、コントローラ２０２に障害が発生した場合にはコントローラ２０２を入れ替えるだけで簡単に障害から復帰できる効果がある。
【００３７】
本実施の形態によるＬＯＯＫＵＰ要求の処理は以下のようになる。クライアント２０１のＬＯＯＫＵＰ処理要求は直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３でＬＯＯＫＵＰ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＬＯＯＫＵＰ処理ハンドラ１１２を呼び出す。
【００３８】
ＬＯＯＫＵＰ処理ハンドラ１１２ではクライアントからのＬＯＯＫＵＰ要求受信ステップ４０１の後、ステップ４０２で受信したＬＯＯＫＵＰ要求をＬＡＮ接続インタフェース１０３によりネットワークストレージ２１１、２１２、２１３に転送する。コントローラ２０２が受信したクライアント２０１のＬＯＯＫＵＰ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、ネットワークストレージ２１１、２１２、２１３へ転送する際には、送信元をコントローラ２０２に変更し、受信先をそれぞれネットワークストレージ２１１、２１２、２１３に変更する。また、これらの送受信関係以外の付加的な情報についても必要に応じて変更する。これにより、ネットワークストレージ２１１、２１２、２１３は通常のファイルアクセスプロトコルのみでアクセス可能であり、専用のネットワークストレージが不要になる効果がある。
【００３９】
ネットワークストレージ２１１、２１２、２１３は受信したＬＯＯＫＵＰ要求を処理した後、コントローラ２０２にＬＯＯＫＵＰ応答を返す。コントローラ２０２はステップ４０３でＬＡＮ接続インタフェース１０３によりネットワークストレージ２１１、２１２、２１３からのＬＯＯＫＵＰ応答を受信する。ＬＯＯＫＵＰ要求はファイル名に対するファイルハンドルを検索する要求であるため、ネットワークストレージ２１１、２１２、２１３に対してＬＯＯＫＵＰ要求を転送しても、ファイルが存在しない場合にはエラーを返す。本実施の形態では後述するＣＲＥＡＴＥ要求処理で、複数のネットワークストレージの同一ファイル名が一つしか存在しないよう保証するため、複数のネットワークストレージからのＬＯＯＫＵＰ要求に対する正常応答は高々一つになる。そこで正常なＬＯＯＫＵＰ応答をステップ４０４でＬＡＮ接続インタフェース１０３によりクライアントに転送する。この時クライアント２０１からのＬＯＯＫＵＰ要求に対する応答にするため、送信元をコントローラ２０２、受信先をクライアント２０１にし、さらに付加的な情報の値を決定する。ネットワークストレージ２１１、２１２、２１３が全てエラー応答を返した場合には、クライアント２０１が要求したファイル名が存在しないか、そのファイル名を保存するネットワークストレージに障害が発生した場合である。その場合には、クライアント２０１への応答としてエラーを返す。
【００４０】
このようなＬＯＯＫＵＰ要求処理により、ＲＥＡＤＤＩＲ要求処理の場合と同様の効果がある。
【００４１】
ＲＥＡＤＤＩＲ要求やＬＯＯＫＵＰ要求によりクライアントがファイルハンドルを取得すると、そのファイルハンドルに基づきクライアントがＲＥＡＤ／ＷＲＩＴＥ要求を発行する。ファイルハンドルは一つのネットワークストレージ上では一意であるが、複数のネットワークストレージでは一意とは限らず同一のファイルハンドルが異なるネットワークストレージ上に存在する可能性がある。本実施の形態によりネットワークストレージを仮想化し単一のネットワークストレージのイメージで運用するためには、ファイルハンドルに対応するネットワークストレージを特定できる仕組みが必要になる。
【００４２】
解決する一つの手法として、ネットワークストレージ２１１、２１２、２１３が応答として返したファイルハンドルをネットワークストレージのホスト名やＩＰアドレスなどネットワークストレージに固有の情報を用いて符号化してクライアント２０１に送信する手法がある。ネットワークストレージ２１１、２１２、２１３には同一のファイルハンドルが存在する可能性があるが、これによりクライアント２０１が同一のファイルハンドルを受信しなくなる。ただし、通常ファイルハンドルは３２バイトや６４バイトなどの有限の値であるため、異なるネットワークストレージの異なるファイルハンドルを符号化した結果、同一の値になる可能性がある。このような場合には次に述べるキャッシュを併用することで解決できる。詳細は後述する。
【００４３】
また別の解決手法として、ファイルハンドルをキャッシュする手法がある。ネットワークストレージからＲＥＡＤＤＩＲ応答やＬＯＯＫＵＰ応答を受信した際に、ファイル名、ファイルハンドル、そのファイルハンドルを返したネットワークストレージに固有な情報をキャッシュしておくことで、クライアントからファイルハンドルを用いたＲＥＡＤ／ＷＲＩＴＥ要求を受信した時に、キャッシュのファイルハンドルとネットワークストレージの対応を調べることで、どのネットワークストレージのファイルハンドルかを特定できる。
【００４４】
また、本実施の形態によるＬＯＯＫＵＰ要求処理の際に、複数のネットワークストレージから同一のファイルハンドルが返る可能性がある。この場合には、上記のファイルハンドルの符号化とファイルハンドルのキャッシュを組み合わせることで解決できる。つまり、ファイルハンドルをネットワークストレージに固有な情報で符号化した値をクライアントに送信するファイルハンドルとしてキャッシュする。前述した符号化後のファイルハンドルが同一の値になる可能性がある問題を解決するためには、キャッシュ全体で符号化したファイルハンドルの一意性を調べ、同一のファイルハンドルが存在する場合には、その部分にのみさらに符号化を行う。こうすればキャッシュ全体でのファイルハンドルの一意性を保証できる。
【００４５】
本実施の形態によるファイルのＲＥＡＤ／ＷＲＩＴＥ要求の処理は以下のようになる。まずＲＥＡＤ要求の処理について説明する。クライアント２０１のＲＥＡＤ処理要求は直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３によりＲＥＡＤ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＲＥＡＤ処理ハンドラ１１３を呼び出す。
【００４６】
コントローラ２０２は前述のファイルハンドラの符号化やキャッシュにより、ファイルハンドルに対応するネットワークストレージを特定できる。そこで、ステップ５０１でクライアントからのＲＥＡＤ要求を受信した後、ステップ５０２でＬＡＮ接続インタフェース１０３によりＲＥＡＤ要求を適切なネットワークストレージに転送する。コントローラ２０２が受信したクライアント２０１のＲＥＡＤ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、適切なネットワークストレージに転送する際には、送信元をコントローラ２０２に変更し、受信先を適切なネットワークストレージに変更する。また、ファイルハンドルが符号化されている場合には復号化する。さらにまた、これら以外の付加的な情報についても必要に応じて変更する。次に、ステップ５０３でＬＡＮ接続インタフェース１０３によりネットワークストレージからのＲＥＡＤ応答を受信する。最後にステップ５０４でＬＡＮ接続インタフェース１０３により受信した応答をクライアント２０１に転送する。この時、送信元をコントローラ２０２に変更し、受信先をクライアント２０１に変更する。さらにこれら以外の付加的な情報についても必要に応じて変更する。
【００４７】
これにより、ネットワークストレージ２１１、２１２、２１３は通常のファイルアクセスプロトコルのみでアクセス可能であり、専用のネットワークストレージが不要になる効果がある。さらにクライアントからのＲＥＡＤ要求の際のコントローラ２０２の処理はＲＥＡＤ要求と応答の書き換えと転送だけであり、実際のファイルの読み出しは各ネットワークストレージが行うため、コントローラ２０２への負荷を低減できる効果がある。
【００４８】
ＷＲＩＴＥ要求の処理についてもＲＥＡＤ処理ハンドル１１３を呼び出す代りにＷＲＩＴＥ処理ハンドル１１４を呼び出す点を除き、ＲＥＡＤ要求処理の場合と同様である。クライアント２０１のＷＲＩＴＥ処理要求は直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３によりＷＲＩＴＥ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＷＲＩＴＥ処理ハンドラ１１４を呼び出す。
【００４９】
コントローラ２０２は前述のファイルハンドラの符号化やキャッシュにより、ファイルハンドルに対応するネットワークストレージを特定できる。そこで、ステップ６０１でクライアントからのＷＲＩＴＥ要求を受信した後、ステップ６０２でＬＡＮ接続インタフェース１０３によりＷＲＩＴＥ要求を適切なネットワークストレージに転送する。コントローラ２０２が受信したクライアント２０１のＷＲＩＴＥ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、適切なネットワークストレージに転送する際には、送信元をコントローラ２０２に変更し、受信先を適切なネットワークストレージに変更する。また、ファイルハンドルが符号化されている場合には復号化する。さらにまた、これら以外の付加的な情報についても必要に応じて変更する。次に、ステップ６０３でＬＡＮ接続インタフェース１０３によりネットワークストレージからのＷＲＩＴＥ応答を受信する。最後にステップ６０４でＬＡＮ接続インタフェース１０３により受信した応答をクライアント２０１に転送する。この時、送信元をコントローラ２０２に変更し、受信先をクライアント２０１に変更する。さらにこれら以外の付加的な情報についても必要に応じて変更する。
【００５０】
このようなＷＲＩＴＥ要求処理により、ＲＥＡＤ要求処理の場合と同様の効果がある。
【００５１】
ＣＲＥＡＴＥ要求によりファイルを新規に作成する場合には、ネットワークストレージの負荷を平均化するようにネットワークストレージを選択してファイルを作成するのが望ましい。そこで本実施の形態によるＣＲＥＡＴＥ要求処理は以下のようになる。クライアント２０１のＣＲＥＡＴＥ処理要求は直接ネットワークストレージ２１１、２１２、２１３に送信するのではなく、コントローラ２０２に送信する。コントローラ２０２では、ＬＡＮ接続インタフェース１０３でＣＲＥＡＴＥ要求を受信した後、演算装置１０１が要求の種別を判定し、メモリ１０２上のＣＲＥＡＴＥ処理ハンドラ１１５を呼び出す。
【００５２】
コントローラ２０２は後述する負荷モニタ処理ハンドラ１１８によって、最も負荷の小さなネットワークストレージを特定できる。そこで、ステップ７０１でクライアントからのＣＲＥＡＴＥ要求を受信した後、ステップ７０２でＬＡＮ接続インタフェース１０３によりＣＲＥＡＴＥ要求を負荷の小さい適切なネットワークストレージに転送する。コントローラ２０２が受信したクライアント２０１のＣＲＥＡＴＥ要求では、送信元がクライアント２０１、受信先がコントローラ２０２になっているが、適切なネットワークストレージに転送する際には、送信元をコントローラ２０２に変更し、受信先を適切なネットワークストレージに変更する。また、これら以外の付加的な情報についても必要に応じて変更する。次に、ステップ７０３でＬＡＮ接続インタフェース１０３によりネットワークストレージからのＣＲＥＡＴＥ応答を受信する。最後にステップ７０４でＬＡＮ接続インタフェース１０３により受信した応答をクライアント２０１に転送する。この時、送信元をコントローラ２０２に変更し、受信先をクライアント２０１に変更する。また必要に応じてネットワークストレージが返したファイルハンドルを前述の手法により符号化し、さらにこれら以外の付加的な情報についても必要に応じて変更する。
【００５３】
このようなＣＲＥＡＴＥ要求処理により、ＲＥＡＤ／ＷＲＩＴＥ要求処理の場合と同様の効果に加え、ネットワークストレージの負荷を均等化する効果がある。
【００５４】
ネットワークストレージ２１１、２１２、２１３の負荷は負荷モニタ処理ハンドラ１１８によって調査する。このハンドラはコントローラ２０２が定期的に実行し、内容を常に更新する。負荷モニタ処理ハンドラ１１８が起動すると、まずステップ８０１によりネットワークストレージ２１１、２１２、２１３のディスクの使用状況調査を行う。これにより、各ネットワークストレージのディスク使用率Ｕ％を求める。次にステップ８０２によりネットワークストレージ２１１、２１２、２１３のネットワーク帯域使用状況調査を行う。これによって、各ネットワークストレージのネットワーク帯域使用率Ｂ％を求める。次に、ステップ８０３で別途定めるディスク容量とネットワーク帯域のどちらを優先して評価するかを定めるパラメータα、βを用いて、評価式α＊Ｕ＋β＊Ｂにより各ネットワークストレージの負荷を評価する。評価式の値が大きいほどネットワークストレージの負荷が大きいことを意味する。ただし、ここでα、βは正数とする。ここで評価した各ネットワークストレージの負荷はＣＲＥＡＴＥ要求処理で新たにファイルを作成する場合のネットワークストレージ選択基準として使用する。 ネットワークストレージ２１１、２１２、２１３の負荷の最大値をｍａｘ（α＊Ｕ＋β＊Ｂ）、最小値をｍｉｎ（α＊Ｕ＋β＊Ｂ）とする。負荷の偏りの許容度パラメータδを用いて、評価式ｍａｘ（α＊Ｕ＋β＊Ｂ）−ｍｉｎ（α＊Ｕ＋β＊Ｂ）＜δを満たすように、ＣＲＥＡＴＥ要求でファイルを作成するネットワークストレージを選択する。
【００５５】
ここで、「負荷の偏りの許容度」とは、システム内の構成要素にかかる負荷の最大と最小でどの程度の差を許容するかの度合いをいう。システム内の構成要素としては、例えばディスク容量などが考えられ、ディスク容量の使用状況の最大と最小でどの程度の差を許容するかを「負荷の偏りの許容度」と表現する。なお、負荷は容量に限らず、プロセッサ使用状況、ネットワーク帯域の使用状況など色々な負荷について考えることができる。許容度は種々の方法で表現可能だが、本実施例では、パラメータδを用いて表現している。
【００５６】
次にステップ８０４により特定ファイルへのアクセス状況を調査する。各ネットワークストレージについて、ネットワークストレージへのアクセス頻度ＦＮを調べる。別途定めるネットワークストレージにどの程度のアクセス集中の許容度パラメータγを用いて、各ネットワークストレージについて評価式ＦＮ＞γを評価し、この式が成り立つ場合には、そのネットワークストレージの個々のファイルのアクセス頻度ＦＦを調査する。
【００５７】
ここで、「アクセス集中の許容度」とは、システムが、どの程度のアクセス集中を許容するかの度合いを言う。ファイルサーバのプロセッサ使用状況、ネットワーク帯域の使用状況、ディスク容量、ディスクアクセスの頻度などが高くなる状態を「アクセス集中」と呼ぶが、このような状態ではシステムの性能が急激に悪化するため、ある程度以上アクセスが集中しないように制御する必要がある。許容度は種々の方法で表現可能だが、本実施例では、パラメータγを用いて表現している。
【００５８】
最後にステップ８０４でＦＦの大きなファイルからＦＮの小さなストレージに移動し、ＦＮを再評価しＦＮを均等化する。
【００５９】
これらにより、ファイル新規作成時の以外の場合、特にアクセス頻度の高い複数のファイルが同一のネットワークストレージに保存されていてホットスポットが発生した場合であっても、ホットスポットの原因となるファイルを移動することで、各ネットワークストレージ負荷を均等化する効果がある。
【００６０】
動作モニタハンドラ１１６はネットワークストレージ２１１、２１２、２１３が正常に動作しているかどうかを監視する。あるネットワークストレージが動作していない場合には、特殊エントリ管理ハンドラ１１９を呼び出し、ネットワークストレージが動作していないことを伝えるための仮想的なファイルエントリを作成する。この特殊エントリはファイル名としてネットワークストレージの障害情報通知用の仮想ファイルと認識できる情報を含む。この仮想的なファイルエントリはネットワークストレージ２１１、２１２、２１３には存在しないことを除き、通常のファイルと同様にアクセスできる。
【００６１】
これにより、コントローラ２０２を管理するための専用のコンソールなどを用いることなく、クライアントはネットワークストレージの障害を知ることができる効果がある。
【００６２】
障害処理ハンドラ１１７は障害の発生していたネットワークストレージが復帰した時の整合性管理を行う。ここで、「整合性」とは、複数ＮＡＳに存在する同一ディレクトリ名の下に同一ファイル名が複数していない状態を「整合性」があると言う。また、同一ディレクトリ上に同一ファイル名が複数存在する状態（実際のファイルは異なるＮＡＳ上に作られる）を「不整合」があると言う。不整合が発生する原因としては、ＮＡＳに障碍が発生している場合などが考えられる。正常動作しているＮＡＳの下に障碍の発生したＮＡＳ上に存在するのと同一のファイル名を持つファイルが作られる可能性があるためである。
本実施の形態によるネットワークストレージ仮想化方法では、クライアントがＣＲＥＡＴＥ要求によりファイルを作成する際に、同一ディレクトリ上に同一ファイル名が高々一つしかないことを保証する。しかしネットワークストレージに障害が発生しアクセス不能になった場合には、ネットワークストレージが障害から復帰した際に同一ファイル名が存在する、整合性が取れていない状態になる可能性がある。この問題を解決するため、障害処理ハンドラ１１７は以下のように動作する。
【００６３】
障害から復帰したネットワークストレージとその他のネットワークストレージについて同一ディレクトリ上に同一ファイル名が存在しないか調査する。同一ファイル名が存在する場合には、障害から復帰したネットワークストレージ上のファイル名を元のファイル名と障害復帰情報を含むファイル名に変更する。障害復帰情報としては、例えばネットワークストレージ固有の情報と復帰時刻などがある。別の手法としては、障害から復帰したネットワークストレージ上にディレクトリ名に障害復帰情報を含んだディレクトリを作成し、そこにファイルを移動する手法がある。
【００６４】
コントローラ２０２にネットワークストレージを増設する際には、仮想化済みのネットワークストレージ群との間でファイル名の重複ないかを調べる整合性調査が必要になるが、このような場合にも障害処理ハンドラ１１７がそのまま適用できる。
【００６５】
これらにより、コントローラ２０２を管理するための専用のコンソールなどを用いることなく、クライアントは障害から復帰したネットワークストレージに発生した整合性エラーを知ることができる効果がある。
【００６６】
特殊エントリ管理ハンドラ１１９は前述の障害情報通知用の仮想的なエントリ管理の他に、ネットワークストレージ２１１、２１２、２１３のなかのいずれか一台を指定してアクセスする必要がある場合の仮想的なディレクトリエントリを提供する。この特殊エントリはディレクトリ名として特定のネットワークへのアクセス用の仮想ディレクトリと認識できる情報を含む。この仮想ディレクトリへの各種アクセス要求は全て特定のネットワークストレージに転送する。この仮想的なディレクトリエントリはネットワークストレージ２１１、２１２、２１３には存在しないことを除き、通常のファイルと同様にアクセスできる。
【００６７】
これにより、コントローラ２０２を管理するための専用のコンソールなどを用いることなく、クライアントは特定のネットワークストレージを指定してファイルを移動することなどができる効果がある。この機能は例えばコントローラ２０２から特定のネットワークストレージを取り外す際に必要になる。 本実施の形態では、ＮＦＳプロトコルを仮定しているが、ＮＦＳ以外のプロトコルについても容易に適用可能である。
【００６８】
本実施の形態では、ファイルハンドルをネットワークストレージ固有の情報より符号化しているが、任意の符号化を利用できる。
【００６９】
本実施の形態では、負荷の要因としてディスク容量とネットワーク帯域を挙げているが、これら以外の負荷要素、例えばネットワークストレージのプロセッサ負荷や内部ディスク帯域など、任意の負荷要素に付いても同様に適用できる。
【００７０】
【発明の効果】
本発明を実施した場合の効果としては、専用ではなく汎用のネットワークストレージを用いてネットワークストレージ仮想化が可能になる効果がある。
【００７１】
また、本発明の範疇に含まれる種々の構成要件を付加することにより、以下のような効果も実現可能となる。例えば、集中管理型サーバや分散ディレクトリを用いずにネットワークストレージの仮想化が可能になる効果がある。
【００７２】
また、ネットワークストレージの障害発生時に障害の影響が他のサーバに伝播せずサービスを続行できる効果がある。
【００７３】
また、ネットワークストレージの仮想化を行うコントローラでファイルの存在場所の管理をしないため、コントローラで障害が発生した場合には、コントローラを交換するだけで障害から復帰できる効果がある。
【００７４】
また、ＲＥＡＤ／ＷＲＩＴＥ要求処理の際にネットワークストレージ仮想化を行うコントローラが行うのはＲＥＡＤ／ＷＲＩＴＥ要求と応答の書き換えだけであり、ネットワークストレージが実際のＲＥＡＤ／ＷＲＩＴＥ要求を処理するため、コントローラへの負荷を低減できる効果がある。
【００７５】
また、ファイルを新規に作成する際に、負荷の少ないネットワークストレージにＣＲＥＡＴＥ要求を転送することにより、ネットワークストレージの負荷を均等化する効果がある。
【００７６】
また、アクセス頻度の高いファイルが特定のネットワークストレージ上に保存されている場合、それらのファイルを他のネットワークストレージに移動することにより、ネットワークストレージの負荷を均等化する効果がある。
【００７７】
また同時に、障害情報通知用の仮想的なファイルエントリを作成することにより、クライアントは専用のコンソールを用いずにネットワークストレージの障害を知ることができる効果がある。
【００７８】
また、ネットワークストレージが障害から復帰する時にファイル名の整合性にエラーが発生した場合、障害のあったネットワークストレージ上のファイル名を障害復帰情報を含んだファイル名に変更することにより、クライアントは専用のコンソールを用いずにネットワークストレージに発生した整合性エラーを知ることができる効果がある。
【００７９】
また、ネットワークストレージ特定のネットワークストレージへのアクセスを指定する仮想的なディレクトリエントリを作成することにより、クライアントは専用のコントローラを用いずに特定のネットワークストレージを指定してファイルを移動することなどができる効果がある。
【図面の簡単な説明】
【図１】本発明によるネットワークストレージ仮想化方法の実施の形態のアーキテクチャのブロック図。
【図２】本発明によるネットワークストレージ仮想化方法の実施の形態のネットワーク接続図
【図３】本発明によるネットワークストレージ仮想化方法の実施の形態のＲＥＡＤＤＩＲ処理ハンドラ１１１のフロー図。
【図４】本発明によるネットワークストレージ仮想化方法の実施の形態のＬＯＯＫＵＰ処理ハンドラ１１２のフロー図。
【図５】本発明によるネットワークストレージ仮想化方法の実施の形態のＲＥＡＤ処理ハンドラ１１３のフロー図。
【図６】本発明によるネットワークストレージ仮想化方法の実施の形態のＷＲＩＴＥ処理ハンドラ１１４のフロー図。
【図７】本発明によるネットワークストレージ仮想化方法の実施の形態のＣＲＥＡＴＥ処理ハンドラ１１５のフロー図。
【図８】本発明によるネットワークストレージ仮想化方法の実施の形態の負荷モニタ処理ハンドラ１１８のフロー図。
【符号の説明】
１００ 本発明によるネットワークストレージ仮想化方法の実施の形態のアーキテクチャ
１０１ 演算装置
１０２ メモリ
１０３ ＬＡＮ接続インタフェース
１１１ ＲＥＡＤＤＩＲ処理ハンドラ
１１２ ＬＯＯＫＵＰ処理ハンドラ
１１３ ＲＥＡＤ処理ハンドラ
１１４ ＷＲＩＴＥ処理ハンドラ
１１５ ＣＲＥＡＴＥ処理ハンドラ
１１６ 動作モニタ処理ハンドラ
１１７ 障害処理ハンドラ
１１８ 負荷モニタ処理ハンドラ
１１９ 特殊エントリ管理処理ハンドラ
２００ 本発明によるネットワークストレージ仮想化方法の実施の形態のネットワーク接続図
２０１ クライアント
２０２ 本発明のネットワークストレージ仮想化方法の実施の形態によるネットワークストレージ仮想化用コントローラ
２１１ 第１のネットワークストレージ
２１２ 第２のネットワークストレージ
２１３ 第３のネットワークストレージ
３０１ クライアントからのＲＥＡＤＤＩＲ要求受信ステップ
３０２ ＲＥＡＤＤＩＲ要求の各ネットワークストレージへの転送ステップ
３０３ 各ネットワークストレージからのＲＥＡＤＤＩＲ応答受信ステップ
３０４ 各ネットワークストレージからのＲＥＡＤＤＩＲ応答結合ステップ
３０５ クライアントへのＲＥＡＤＤＩＲ応答送信ステップ
４０１ クライアントからのＬＯＯＫＵＰ要求受信ステップ
４０２ ＬＯＯＫＵＰ要求の各ネットワークストレージへの転送ステップ
４０３ 各ネットワークストレージからのＬＯＯＫＵＰ応答受信ステップ
４０４ クライアントへの正常なＬＯＯＫＵＰ応答転送ステップ
５０１ クライアントからのＲＥＡＤ要求受信ステップ
５０２ ＲＥＡＤ要求の適切なネットワークストレージへの転送ステップ
５０３ ネットワークストレージからのＲＥＡＤ応答受信ステップ
５０４ クライアントへのＲＥＡＤ応答転送ステップ
６０１ クライアントからのＷＲＩＴＥ要求受信ステップ
６０２ ＷＲＩＴＥ要求の適切なネットワークストレージへの転送ステップ
６０３ ネットワークストレージからのＷＲＩＴＥ応答受信ステップ
６０４ クライアントへのＷＲＩＴＥ応答転送ステップ
７０１ クライアントからのＣＲＥＡＴＥ要求受信ステップ
７０２ ＣＲＥＡＴＥ要求の適切なネットワークストレージへの転送ステップ
７０３ ネットワークストレージからのＣＲＥＡＴＥ応答受信ステップ
７０４ クライアントへのＣＲＥＡＴＥ応答転送ステップ
８０１ ネットワークストレージのディスク容量調査ステップ
８０２ ネットワークストレージのネットワーク帯域調査ステップ
８０３ ネットワークストレージの負荷評価ステップ
８０４ 特定ファイルへのアクセス状況調査ステップ
８０５ ファイルの再配置ステップ。
Claims (19)
- 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージ仮想化方法において、
クライアントからの要求を受信するステップと、第一のネットワークストレージおよび第二のネットワークストレージに前記受信した要求を転送するステップと、前記転送した要求に対する前記第一のネットワークストレージからの応答を受信するステップと、前記転送した要求に対する前記第二のネットワークストレージからの応答を受信するステップと、
前記受信した第一のネットワークストレージの応答と前記受信した第二のネットワークストレージの応答とを結合するステップと、前記結合した応答を前記クライアントに送信するステップと、を含むことを特徴とするネットワークストレージ仮想化方法。 - 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージ仮想化方法において、
クライアントからの要求を受信するステップと、
前記受信した要求を複数のネットワークストレージに転送するステップと、前記転送した要求に対する前記複数のネットワークストレージからの応答を受信するステップと、
前記受信した応答が正常かエラーかを判定するステップと、前記判定した応答の中で正常な応答のみを結合するステップと、
前記結合した応答を前記クライアントに送信するステップと、を含むことを特徴とするネットワークストレージ仮想化方法。 - 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージ仮想化方法において、
クライアントからの要求を受信するステップと、
前記受信した要求を複数のネットワークストレージに転送するステップと、
前記転送した要求に対する前記複数のネットワークストレージからの応答を受信するステップと、
前記受信した応答が正常かエラーかを判定するステップと、
前記判定した判定した応答の中で正常な応答の一つを前記クライアントへ送信するステップとを含むことを特徴とするネットワークストレージ仮想化方法。 - 請求項１または請求項２または請求項３のネットワークストレージ仮想化方法において、
前記クライアントに送信した前記応答を基に前記クライアントが生成した要求を受信するステップと、前記ネットワークストレージから受信した応答を基に前記受信した要求を転送するネットワークストレージを判定するステップと、
前記判定したネットワークストレージに前記要求を転送するステップと、
前記転送した要求に対する前記ネットワークストレージからの応答を受信するステップと、
前記受信した応答を前記クライアントに転送するステップとを含むことを特徴とするネットワークストレージ仮想化方法。 - 請求項１または請求項２または請求項３のネットワークストレージ仮想化方法において、
前記ネットワークストレージの応答の中のアクセス識別子を各ネットワークストレージ固有の情報を用いて符号化するステップと、を含むことを特徴とするネットワークストレージ仮想化方法。 - 請求項１または請求項２または請求項３のネットワークストレージ仮想化方法において、
少なくとも前記ネットワークストレージ識別情報と前記ネットワークストレージの応答の中のアクセス識別子とを一時記憶用の領域に保存するステップとを含むことを特徴とするネットワークストレージ仮想化方法。 - 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージの仮想化方法において、
複数のネットワークストレージの動作状態を検出するステップと、
障害検出時に障害情報を含んだエントリを生成するステップと、
クライアントからの要求を受信するステップと、前記複数のネットワークストレージのうち正常に動作しているネットワークストレージのエントリ情報と前記生成した障害情報を含んだエントリ情報とを結合して前記アクセス要求に対する応答メッセージを生成するステップと、
前記生成した応答メッセージを前記クライアントに送信するステップとを含むことを特徴とするネットワークストレージ仮想化方法。 - 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージの仮想化方法において、前記複数のネットワークストレージのエントリ情報の整合性管理を行うことを特徴とするネットワークストレージ仮想化方法。
- 請求項８に記載のネットワークストレージの仮想化方法において、障害が発生していたネットワークストレージが正常動作に復帰したかどうかを検出するステップを有し、
前記エントリ情報の整合性管理には、前記障害が発生していたネットワークストレージのエントリ情報と、正常動作していた任意のネットワークストレージ上のエントリ情報との間の整合性を調査するステップと、
不整合が発生した場合に前記障害が発生していたネットワークストレージ上のエントリ情報の識別子を変更するステップとを含むことを特徴とするネットワークストレージ仮想化方法。 - 請求項８に記載のネットワークストレージの仮想化方法において、障害が発生していたネットワークストレージが正常動作に復帰したかどうかを検出するステップを有し、
前記エントリ情報の整合性管理には、前記障害が発生していたネットワークストレージのエントリ情報と、正常動作していた任意のネットワークストレージ上のエントリ情報との間の整合性を調査するステップと、
不整合が発生した場合に前記障害が発生していたネットワークストレージ上に不整合管理用エントリを作成するステップと、
前記不整合の発生したエントリを前記不整合管理用エントリに移動するステップとを含むことを特徴とするネットワークストレージ仮想化方法。 - 請求項８に記載のネットワークストレージの仮想化方法において、新しいネットワークストレージの情報を登録するステップを有し、
前記エントリ情報の整合性管理には、前記仮想化している複数のネットワークストレージのエントリ情報と前記新しいネットワークストレージのエントリ情報との間の整合性を調査するステップと、
不整合がある場合に前記新しいネットワークストレージ上の前記不整合のあるエントリ情報の識別子を変更するステップとを含むことを特徴とするネットワークストレージ仮想化方法。 - 請求項８に記載のネットワークストレージの仮想化方法において、新しいネットワークストレージの情報を登録するステップを有し、
前記エントリ情報の整合性管理には、
前記仮想化している複数のネットワークストレージのエントリ情報と前記新しいネットワークストレージのエントリ情報との間の整合性を調査するステップと、不整合がある場合に前記新しいネットワークストレージ上に不整合管理用エントリを作成するステップと、前記不整合のあるエントリを前記不整合管理用エントリに移動するステップとを含むことを特徴としたネットワークストレージ仮想化方法。 - 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージ仮想化方法において、
仮想化している複数のネットワークストレージ中の特定の一台のネットワークストレージを表す仮想的なエントリを生成するステップと、
クライアントからの要求が前記仮想的なエントリへの要求かを判定するステップと、
前記クライアントの要求が前記仮想的なエントリへの要求の場合に前記クライアントの要求を前記特定のネットワークストレージへ転送するステップと、を含むことを特徴とするネットワークストレージ仮想化方法。 - 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージ仮想化方法において、
前記複数のネットワークストレージへのアクセスの負荷分散を行うことを特徴とするネットワークストレージ仮想化方法。 - 請求項１４に記載のネットワークストレージ仮想化方法において、
前記負荷分散には、
前記複数のネットワークストレージの負荷をモニタするステップと、前記複数のネットワークストレージの中で最も負荷の低いネットワークストレージを選択するステップと、
クライアントからの新規データ書き込みの要求を前記負荷の最も低いネットワークストレージに転送するステップと、を含むことを特徴とするネットワークストレージ仮想化方法。 - 請求項１４に記載のネットワークストレージ仮想化方法において、
前記負荷分散には、
前記複数のネットワークストレージへのアクセス集中をモニタするステップと、
前記複数のネットワークストレージの特定のエントリへのアクセス集中をモニタするステップと、
特定のネットワークストレージへのアクセス集中の許容度を指定するステップと、
前記ネットワークストレージへのアクセス集中モニタの結果から前記許容度を越えているネットワークストレージを特定するステップと、
前記許容度を越えたネットワークストレージの中でアクセスが集中しているエントリを特定するステップと、
前記アクセスが集中しているエントリを前記複数のネットワークストレージの中で前記許容を越えていないネットワークストレージへと移動するステップと、を含むことを特徴とするネットワークストレージ仮想化方法。 - 請求項１４に記載のネットワークストレージ仮想化方法において、
前記負荷分散には、
前記複数のネットワークストレージの負荷をモニタするステップと、
前記複数のネットワークストレージの負荷の偏りの許容度を指定するステップと、
前記複数のネットワークストレージの中で前記許容度を越えているネットワークストレージを特定するステップと、
前記許容度を越えているネットワークストレージの中で前記許容度を越える原因となるエントリを特定するステップと、
前記原因となるエントリを前記複数のネットワークストレージの中で前記許容度を越えていないネットワークストレージへと移動するステップと、を含むことを特徴とするネットワークストレージ仮想化方法。 - 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージの仮想化方法において、
複数のネットワークストレージを仮想化して運用するのに必要な情報を前記複数のネットワークストレージ上に保存するステップとを含むことを特徴とするネットワークストレージ仮想化方法。 - 複数のネットワークストレージを仮想的な一台のネットワークストレージとしてアクセス可能にするネットワークストレージ仮想化方法において、
複数のネットワークストレージの識別子を登録するステップと、
前記複数のネットワークストレージへアクセスするための情報を登録するステップと、
前記複数のネットワークストレージの管理者情報を登録するステップとを含むことを特徴とするネットワークストレージ仮想化方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002213245A JP2004054721A (ja) | 2002-07-23 | 2002-07-23 | ネットワークストレージ仮想化方法 |
| US10/234,235 US7174360B2 (en) | 2002-07-23 | 2002-09-05 | Method for forming virtual network storage |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002213245A JP2004054721A (ja) | 2002-07-23 | 2002-07-23 | ネットワークストレージ仮想化方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004054721A true JP2004054721A (ja) | 2004-02-19 |
Family
ID=30767832
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002213245A Revoked JP2004054721A (ja) | 2002-07-23 | 2002-07-23 | ネットワークストレージ仮想化方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7174360B2 (ja) |
| JP (1) | JP2004054721A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009053955A (ja) * | 2007-08-27 | 2009-03-12 | Nec Corp | 計算機システム、ストレージ、アクセス制御方法およびアクセス制御用プログラム |
| JP2009252106A (ja) * | 2008-04-09 | 2009-10-29 | Nec Corp | ディスクアレイ制御方法及びディスクアレイ装置 |
| JP2010146215A (ja) * | 2008-12-17 | 2010-07-01 | Hitachi Ltd | クラスタストレージ装置、クラスタストレージシステム、及びその制御方法 |
| JP2015022762A (ja) * | 2013-07-19 | 2015-02-02 | 英奇達資訊股▲ふん▼有限公司 | オンラインストレージ管理方法 |
Families Citing this family (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6728848B2 (en) * | 2001-06-11 | 2004-04-27 | Hitachi, Ltd. | Method and system for backing up storage system data |
| EP1561306B1 (en) * | 2002-11-12 | 2007-03-07 | Zetera Corporation | Communication protocols, systems and methods |
| JP2004280283A (ja) * | 2003-03-13 | 2004-10-07 | Hitachi Ltd | 分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法 |
| JP4320195B2 (ja) * | 2003-03-19 | 2009-08-26 | 株式会社日立製作所 | ファイルストレージサービスシステム、ファイル管理装置、ファイル管理方法、ｉｄ指定型ｎａｓサーバ、および、ファイル読出方法 |
| US7409644B2 (en) * | 2003-05-16 | 2008-08-05 | Microsoft Corporation | File system shell |
| US7421438B2 (en) * | 2004-04-29 | 2008-09-02 | Microsoft Corporation | Metadata editing control |
| US7823077B2 (en) * | 2003-03-24 | 2010-10-26 | Microsoft Corporation | System and method for user modification of metadata in a shell browser |
| US7712034B2 (en) * | 2003-03-24 | 2010-05-04 | Microsoft Corporation | System and method for shell browser |
| US7234114B2 (en) * | 2003-03-24 | 2007-06-19 | Microsoft Corporation | Extensible object previewer in a shell browser |
| US7188316B2 (en) * | 2003-03-24 | 2007-03-06 | Microsoft Corporation | System and method for viewing and editing multi-value properties |
| US7769794B2 (en) | 2003-03-24 | 2010-08-03 | Microsoft Corporation | User interface for a file system shell |
| US7240292B2 (en) * | 2003-04-17 | 2007-07-03 | Microsoft Corporation | Virtual address bar user interface control |
| US7627552B2 (en) * | 2003-03-27 | 2009-12-01 | Microsoft Corporation | System and method for filtering and organizing items based on common elements |
| US7890960B2 (en) | 2003-03-26 | 2011-02-15 | Microsoft Corporation | Extensible user context system for delivery of notifications |
| US7827561B2 (en) | 2003-03-26 | 2010-11-02 | Microsoft Corporation | System and method for public consumption of communication events between arbitrary processes |
| US7650575B2 (en) * | 2003-03-27 | 2010-01-19 | Microsoft Corporation | Rich drag drop user interface |
| US7536386B2 (en) * | 2003-03-27 | 2009-05-19 | Microsoft Corporation | System and method for sharing items in a computer system |
| US7925682B2 (en) | 2003-03-27 | 2011-04-12 | Microsoft Corporation | System and method utilizing virtual folders |
| US7181439B1 (en) * | 2003-04-25 | 2007-02-20 | Network Appliance, Inc. | System and method for transparently accessing a virtual disk using a file-based protocol |
| US20050166260A1 (en) * | 2003-07-11 | 2005-07-28 | Christopher Betts | Distributed policy enforcement using a distributed directory |
| US20050188174A1 (en) * | 2003-10-12 | 2005-08-25 | Microsoft Corporation | Extensible creation and editing of collections of objects |
| US8024335B2 (en) | 2004-05-03 | 2011-09-20 | Microsoft Corporation | System and method for dynamically generating a selectable search extension |
| US7181463B2 (en) | 2003-10-24 | 2007-02-20 | Microsoft Corporation | System and method for managing data using static lists |
| US7631310B1 (en) | 2003-11-14 | 2009-12-08 | Google Inc. | Loadbalancing multiple files across computing devices |
| US20050131960A1 (en) * | 2003-12-15 | 2005-06-16 | Reed Benjamin C. | Method and system of accessing at least one target file in a computer system with an operating system with file locking implemented at file-open time |
| US7380246B2 (en) * | 2003-12-15 | 2008-05-27 | Lenovo (Singapore) Pte. Ltd. | Method and system of accessing at least one target file in a computer system with an operating system with file locking implemented with byte-range locking |
| US20050198401A1 (en) * | 2004-01-29 | 2005-09-08 | Chron Edward G. | Efficiently virtualizing multiple network attached stores |
| JP2005228170A (ja) | 2004-02-16 | 2005-08-25 | Hitachi Ltd | 記憶装置システム |
| US7657846B2 (en) * | 2004-04-23 | 2010-02-02 | Microsoft Corporation | System and method for displaying stack icons |
| US7694236B2 (en) * | 2004-04-23 | 2010-04-06 | Microsoft Corporation | Stack icons representing multiple objects |
| US7992103B2 (en) * | 2004-04-26 | 2011-08-02 | Microsoft Corporation | Scaling icons for representing files |
| US20050240878A1 (en) * | 2004-04-26 | 2005-10-27 | Microsoft Corporation | System and method for scaling icons |
| US8707209B2 (en) | 2004-04-29 | 2014-04-22 | Microsoft Corporation | Save preview representation of files being created |
| US8108430B2 (en) | 2004-04-30 | 2012-01-31 | Microsoft Corporation | Carousel control for metadata navigation and assignment |
| US8412685B2 (en) * | 2004-07-26 | 2013-04-02 | Riverbed Technology, Inc. | Method and system for managing data |
| JP4826077B2 (ja) * | 2004-08-31 | 2011-11-30 | 株式会社日立製作所 | ブートディスク管理方法 |
| KR100661170B1 (ko) * | 2005-01-07 | 2006-12-26 | 삼성전자주식회사 | 화상형성장치 및 그의 제어방법 |
| US20060236253A1 (en) * | 2005-04-15 | 2006-10-19 | Microsoft Corporation | Dialog user interfaces for related tasks and programming interface for same |
| US8490015B2 (en) * | 2005-04-15 | 2013-07-16 | Microsoft Corporation | Task dialog and programming interface for same |
| US20060236244A1 (en) * | 2005-04-15 | 2006-10-19 | Microsoft Corporation | Command links |
| US8195646B2 (en) | 2005-04-22 | 2012-06-05 | Microsoft Corporation | Systems, methods, and user interfaces for storing, searching, navigating, and retrieving electronic information |
| US8522154B2 (en) * | 2005-04-22 | 2013-08-27 | Microsoft Corporation | Scenario specialization of file browser |
| US7665028B2 (en) | 2005-07-13 | 2010-02-16 | Microsoft Corporation | Rich drag drop user interface |
| US7512677B2 (en) * | 2005-10-20 | 2009-03-31 | Uplogix, Inc. | Non-centralized network device management using console communications system and method |
| JP2009020876A (ja) * | 2007-06-14 | 2009-01-29 | Panasonic Corp | ファイル管理装置及びファイル転送方法並びに撮像装置 |
| US9135270B2 (en) * | 2007-12-26 | 2015-09-15 | Oracle International Corporation | Server-centric versioning virtual file system |
| US8935336B2 (en) * | 2008-06-18 | 2015-01-13 | Cisco Technology, Inc. | Optimizing program requests over a wide area network |
| US20110055367A1 (en) * | 2009-08-28 | 2011-03-03 | Dollar James E | Serial port forwarding over secure shell for secure remote management of networked devices |
| US20110055899A1 (en) * | 2009-08-28 | 2011-03-03 | Uplogix, Inc. | Secure remote management of network devices with local processing and secure shell for remote distribution of information |
| US10397029B2 (en) | 2015-07-08 | 2019-08-27 | Toshiba Memory Corporation | Relay apparatus |
| US20230044165A1 (en) * | 2021-08-06 | 2023-02-09 | Samsung Electronics Co., Ltd. | Systems, methods, and apparatus for remote data transfers to memory |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5163131A (en) * | 1989-09-08 | 1992-11-10 | Auspex Systems, Inc. | Parallel i/o network file server architecture |
| US7389312B2 (en) * | 1997-04-28 | 2008-06-17 | Emc Corporation | Mirroring network data to establish virtual storage area network |
| US6067599A (en) * | 1997-05-29 | 2000-05-23 | International Business Machines Corporation | Time delayed auto-premigeration of files in a virtual data storage system |
| 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 |
| JPH11232226A (ja) * | 1998-02-13 | 1999-08-27 | Nec Corp | 協同作業支援システム及び記録媒体 |
| US6421711B1 (en) * | 1998-06-29 | 2002-07-16 | Emc Corporation | Virtual ports for data transferring of a data storage system |
| US6269432B1 (en) * | 1998-10-23 | 2001-07-31 | Ericsson, Inc. | Distributed transactional processing system having redundant data |
| US6842784B1 (en) * | 2000-06-27 | 2005-01-11 | Emc Corporation | Use of global logical volume identifiers to access logical volumes stored among a plurality of storage elements in a computer storage system |
| US6912548B1 (en) * | 2000-06-27 | 2005-06-28 | Emc Corporation | Logical volume identifier database for logical volumes in a computer storage system |
| US6529997B1 (en) * | 2000-08-11 | 2003-03-04 | Storage Technology Corporation | Apparatus and method for writing and reading data to and from a virtual volume of redundant storage devices |
| ATE381191T1 (de) * | 2000-10-26 | 2007-12-15 | Prismedia Networks Inc | Verfahren und system zur verwaltung von verteilten inhalten und entsprechenden metadaten |
| JP4087072B2 (ja) * | 2001-01-25 | 2008-05-14 | 株式会社日立製作所 | ストレージシステム及び仮想プライベートボリューム制御方法 |
| US20030037061A1 (en) * | 2001-05-08 | 2003-02-20 | Gautham Sastri | Data storage system for a multi-client network and method of managing such system |
| US6877011B2 (en) * | 2001-10-10 | 2005-04-05 | Sun Microsystems, Inc. | System and method for host based storage virtualization |
| US7024427B2 (en) * | 2001-12-19 | 2006-04-04 | Emc Corporation | Virtual file system |
-
2002
- 2002-07-23 JP JP2002213245A patent/JP2004054721A/ja not_active Revoked
- 2002-09-05 US US10/234,235 patent/US7174360B2/en not_active Expired - Fee Related
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009053955A (ja) * | 2007-08-27 | 2009-03-12 | Nec Corp | 計算機システム、ストレージ、アクセス制御方法およびアクセス制御用プログラム |
| JP2009252106A (ja) * | 2008-04-09 | 2009-10-29 | Nec Corp | ディスクアレイ制御方法及びディスクアレイ装置 |
| JP2010146215A (ja) * | 2008-12-17 | 2010-07-01 | Hitachi Ltd | クラスタストレージ装置、クラスタストレージシステム、及びその制御方法 |
| JP2015022762A (ja) * | 2013-07-19 | 2015-02-02 | 英奇達資訊股▲ふん▼有限公司 | オンラインストレージ管理方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US7174360B2 (en) | 2007-02-06 |
| US20040019655A1 (en) | 2004-01-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004054721A (ja) | ネットワークストレージ仮想化方法 | |
| US7433934B2 (en) | Network storage virtualization method and system | |
| US9846734B2 (en) | Transparently migrating a storage object between nodes in a clustered storage system | |
| US9729666B2 (en) | Large scale storage system and method of operating thereof | |
| US9049204B2 (en) | Collaborative management of shared resources | |
| US9128626B2 (en) | Distributed virtual storage cloud architecture and a method thereof | |
| US7599941B2 (en) | Transparent redirection and load-balancing in a storage network | |
| US7975102B1 (en) | Technique to avoid cascaded hot spotting | |
| US8955087B2 (en) | Method and system for transferring replicated information from source storage to destination storage | |
| US8756338B1 (en) | Storage server with embedded communication agent | |
| US20230315695A1 (en) | Byte-addressable journal hosted using block storage device | |
| US9544371B1 (en) | Method to discover multiple paths to disk devices cluster wide | |
| US11249671B2 (en) | Methods for improved data replication across hybrid cloud volumes using data tagging and devices thereof | |
| US20220269541A1 (en) | Methods for managing storage quota assignment in a distributed system and devices thereof | |
| US11064020B2 (en) | Connection load distribution in distributed object storage systems | |
| US20220182384A1 (en) | Multi-protocol lock manager for distributed lock management | |
| Gutierrez et al. | uStorage-A Storage Architecture to Provide Block-Level Storage Through Object-Based Storage |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040825 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060510 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20060510 |
|
| AA91 | Notification that invitation to amend document was cancelled |
Free format text: JAPANESE INTERMEDIATE CODE: A971091 Effective date: 20060919 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061027 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061027 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071218 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080214 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20080214 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080227 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080303 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080513 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080916 |