JP2006039814A - ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法 - Google Patents
ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法 Download PDFInfo
- Publication number
- JP2006039814A JP2006039814A JP2004217031A JP2004217031A JP2006039814A JP 2006039814 A JP2006039814 A JP 2006039814A JP 2004217031 A JP2004217031 A JP 2004217031A JP 2004217031 A JP2004217031 A JP 2004217031A JP 2006039814 A JP2006039814 A JP 2006039814A
- Authority
- JP
- Japan
- Prior art keywords
- file
- network storage
- nas
- client
- tree
- 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.)
- Pending
Links
- 238000003860 storage Methods 0.000 title claims description 374
- 238000000034 method Methods 0.000 title claims description 55
- 230000014759 maintenance of location Effects 0.000 title claims description 14
- 238000012546 transfer Methods 0.000 title abstract description 10
- 230000005012 migration Effects 0.000 claims description 52
- 238000013508 migration Methods 0.000 claims description 52
- 230000006854 communication Effects 0.000 claims description 26
- 238000004891 communication Methods 0.000 claims description 26
- 230000007704 transition Effects 0.000 claims description 4
- 230000007175 bidirectional communication Effects 0.000 claims 1
- 101150105138 nas2 gene Proteins 0.000 abstract 6
- 101000713503 Homo sapiens Solute carrier family 13 member 1 Proteins 0.000 abstract 4
- 102100036743 Solute carrier family 13 member 1 Human genes 0.000 abstract 4
- 238000006243 chemical reaction Methods 0.000 description 57
- 238000007726 management method Methods 0.000 description 33
- 230000008569 process Effects 0.000 description 27
- 230000004044 response Effects 0.000 description 27
- 238000012545 processing Methods 0.000 description 26
- 230000006870 function Effects 0.000 description 18
- 238000010586 diagram Methods 0.000 description 8
- 101100490563 Caenorhabditis elegans adr-1 gene Proteins 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 230000010365 information processing Effects 0.000 description 3
- 102220041874 rs587780791 Human genes 0.000 description 3
- 101100388220 Caenorhabditis elegans adr-2 gene Proteins 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 230000004043 responsiveness Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 239000000725 suspension Substances 0.000 description 2
- 238000007792 addition Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File 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/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]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99955—Archiving or backup
Abstract
【課題】 サービス停止時間を短縮し、速やかに移行させる。
【解決手段】 NAS1のファイルツリーと同一構造のファイルツリーが、予めNAS2に形成される。ツリーには、ファイルデータは移行されていない。NAS2は、NAS1で管理されるファイルディスクリプタfd1とNAS2で管理されるfd2との対応関係を保持する。ツリー構造の移行が完了すると、クライアント3へのサービスが再開される。クライアント3が、fd2を指定して所望のファイルへのアクセスを要求すると、NAS2は、fd2をfd1に変換し、NAS1にファイルデータを要求する(d)。NAS1がファイルデータを読出すと、NAS2は、ファイルデータを所定の場所4Bに記憶し、クライアント3に提供する(e)。クライアント3が再びファイルアクセスを希望する場合、NAS2は、移行済のファイルデータを読出して、クライアント3に提供する。
【選択図】 図2
【解決手段】 NAS1のファイルツリーと同一構造のファイルツリーが、予めNAS2に形成される。ツリーには、ファイルデータは移行されていない。NAS2は、NAS1で管理されるファイルディスクリプタfd1とNAS2で管理されるfd2との対応関係を保持する。ツリー構造の移行が完了すると、クライアント3へのサービスが再開される。クライアント3が、fd2を指定して所望のファイルへのアクセスを要求すると、NAS2は、fd2をfd1に変換し、NAS1にファイルデータを要求する(d)。NAS1がファイルデータを読出すと、NAS2は、ファイルデータを所定の場所4Bに記憶し、クライアント3に提供する(e)。クライアント3が再びファイルアクセスを希望する場合、NAS2は、移行済のファイルデータを読出して、クライアント3に提供する。
【選択図】 図2
Description
本発明は、ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法に関する。
ネットワークストレージとは、インターネットやLAN等の通信ネットワークに接続され、複数のコンピュータによって共用されるストレージである。ネットワークストレージとしては、例えば、NAS(Network Attached Storage)等が知られている。企業や自治体あるいは学校等の組織では、膨大なデータを管理するために、一つまたは複数のネットワークストレージを導入し、ネットワークストレージシステムを構築している。
これらの組織で管理すべきデータは日々増大するため、ネットワークストレージシステムの管理者は、やがてネットワークストレージの容量不足に直面する。あるいは、ネットワークストレージを利用するクライアントの数が増大したような場合、管理者は、ネットワークストレージの応答性能の改善を検討する。
このようなネットワークストレージの容量不足や応答性低下等に対応するために、既設のネットワークストレージを新しいネットワークストレージに置き換えたり、あるいは、既設のネットワークストレージと新しく追加するネットワークストレージとを共存させて運用することが行われる(特許文献1)。
この特許文献に記載の従来技術では、まず先に、既設ネットワークストレージが有するディレクトリの階層構造、即ちファイルツリーの構造を新設ネットワークストレージにコピーしておき、次に、クライアントからのアクセス要求に応じて、既設ネットワークストレージから新設ネットワークストレージにファイルを移行させる。
特開2004−46661号公報
リブート後等のように、クライアントが所望のファイルへの最初のアクセスを試みる場合、クライアントは、ネットワークストレージのファイルシステムに対し、目的とするファイルの名称及びそのファイルが属するディレクトリ名を指定する。ファイルシステムは、クライアントから順番に指定された情報に基づいて、ディレクトリ階層構造としてのファイルツリーを順番に順に辿っていき、要求されたファイルを検出する。例えば、クライアントが、ディレクトリA下のサブディレクトリB内に存在するファイルCにアクセスを試みる場合、ファイルシステムは、ディレクトリA→サブディレクトリB→ファイルCへと、順番にファイルツリーを辿っていき、目的とするファイルCを発見する。
ファイルシステムは、以後そのファイルへのアクセスを容易ならしめるために、そのファイルシステム内で一意に識別されるファイル識別情報(例えば、ファイルハンドル等)を発行し、クライアントに送信する。ファイルシステムがファイルツリーを順番に辿っていく過程において、ディレクトリ及びファイルをそれぞれ特定するためのファイル識別情報が、ファイルシステムからクライアントに通知される。
クライアントは、ファイルシステムから発行されたファイル識別情報をメモリ内に保持しておく。上述のように、ファイル識別情報は、ファイルシステム内でファイルを直接指定するための情報である。従って、クライアントは、次のファイルアクセス時に、ネットワークストレージに対してファイル識別情報を直接指定することにより、目的のファイルを要求する。ファイルシステムは、ファイル識別情報に基づいて、要求されたファイルを直接的に特定し、そのファイルへのアクセスをクライアントに提供する。このように、有効なファイル識別情報を入手済である場合、クライアントは、ファイルツリーを順番に辿ってファイルを探す必要がない。
同様に、新設のネットワークストレージは、ファイル識別情報に基づいて、ファイルシステム上でファイルを直接的に特定できる。しかし、ファイル識別情報は、ファイルシステム上でファイルを一意に識別する情報に過ぎず、ファイル識別情報だけで、そのファイルが存在するファイルツリー上の位置を直接特定することはできない。また、ファイル識別情報は、基本的に、それを発行したファイルシステム上で有効に機能し、異なるファイルシステム上では使用することができない。
従って、新設ネットワークストレージがクライアントからファイルアクセスを要求されたとしても、新設ネットワークストレージのファイルシステム以外のファイルシステムで発行されたファイル識別情報を用いてファイルが指定された場合や、要求されたファイルが新設ネットワークストレージ上に存在しない場合には、新設ネットワークストレージは、要求されたファイルを特定することができない。
即ち、新設ネットワークストレージのファイルシステムは、既設ネットワークストレージのファイルシステムが発行したファイル識別情報のみに基づいて、その要求されたファイルが既設ネットワークストレージ上の何処に存在するかを特定できないため、要求されたファイルの実体にアクセスすることはできない。
このように、上記文献に記載の技術では、既設ネットワークストレージから新設ネットワークストレージに未だ移行されていないファイルに対して、新設ネットワークストレージからアクセスするのは難しい。
そこで、上記文献に記載の技術では、事前に既設ネットワークストレージのファイルツリー構造を新設ネットワークストレージにコピーしておくだけでは足りず、新設ネットワークストレージからファイル共有サービスを開始する前に、予め特定の上位ディレクトリから下位に向けて、ファイルツリーの全部(または所定の範囲)のデータも移行させておく必要がある。換言すれば、新設ネットワークストレージにデータを移行した範囲内においてのみ、ファイル共有サービスを提供することができる。
従って、上記文献に記載の技術では、既設ネットワークストレージから新設ネットワークストレージへのファイルツリー全体のデータ移行が完了するまでの間、ファイル共有サービスを再開することができず、この結果、ネットワークストレージの置き換えに長い時間を必要とする。また、上記文献に記載の技術では、サービス再開前に予めデータ移行を済ませておく必要があるため、クライアントにファイル共有サービスを提供しながら移行させることはできない。
なお、上記文献に記載の技術では、例えば、新設ネットワークストレージに設けられた仮想一元化機能により、新旧のネットワークストレージを仮想的に一元化し、要求されたファイルの記憶先に応じて、新旧それぞれのネットワークストレージにアクセス要求を割り振ることも提案されている。しかし、このような仮想的一元化は、旧資産の積極活用という観点では有意義であるが、既設のネットワークストレージを新設のネットワークストレージに完全に置き換えることができない。従って、既設ネットワークストレージに記憶されている古いファイル群は、アクセス性能が相対的に劣る既設ネットワークストレージから提供する必要があり、システム全体としての応答性は低下する。また、旧式で性能の劣るネットワークストレージをいつまでも保守し続けなければならず、システムの保守コストや運用コストが増大する。
そこで、本発明の一つの目的は、本発明の一つの目的は、第2のネットワークストレージに移行されていないファイルへのアクセスが要求された場合でも、そのファイルを記憶する第1のネットワークストレージのファイルシステム上で直ちにファイルを特定し、第1のネットワークストレージからデータを取得してクライアントに提供することができ、比較的短時間で第1のネットワークストレージから第2のネットワークストレージへファイル共有サービスを移行(引継)させることができるようにしたネットワークストレージシステム及び複数ネットワークストレージ間の引継方法の提供にある。
本発明の一つの目的は、ファイルを記憶する第1のネットワークストレージの記憶内容を変更させることなく、また、第1のネットワークストレージに特別な機能を追加することなく、比較的短時間でネットワークストレージ間のファイル単位でのデータ移行を実現できるようにしたネットワークストレージシステム及び複数ネットワークストレージ間の引継方法を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。
上記課題を解決すべく、本発明のネットワークストレージシステムは、第1のネットワークストレージ(既設ネットワークストレージ)から第2のネットワークストレージ(新設ネットワークストレージ)に移行されていないファイルを、第1のネットワークストレージ上で直ちに特定し、ファイル単位でデータを移行できるように構成した。これにより、本発明のネットワークストレージシステムでは、ファイルツリー全体のデータを移行させるよりも前に、ファイル共有サービスを開始することができる。
即ち、本発明のネットワークストレージシステムは、クライアントに提供するファイルを記憶する第1のネットワークストレージと、クライアント及び第1のネットワークストレージにそれぞれ接続される第2のネットワークストレージとを備え、さらに、第1のネットワークストレージが有する第1のファイルツリーと同一構造の第2のファイルツリーを、ファイルシステムのディレクトリ階層構造として、第2のネットワークストレージ上に生成させるファイルツリー生成部と、第1のネットワークストレージ上のファイルへアクセスするべくクライアントから第2のネットワークストレージに対して要求されたアクセス要求に基づいて、クライアントから要求されたファイルを第1のネットワークストレージ上で特定するファイル特定部と、特定されたファイルの属性及びデータを第1のネットワークストレージから取得し、この取得したファイルを第2のファイルツリーの所定の場所に格納させるファイル移行部と、を備える。
クライアントは、例えば、ファイルディスクリプタ等のようなファイル識別情報を含むコマンドにより、第2のネットワークストレージに対して、所望のファイルへのアクセスを要求する。第2のネットワークストレージのファイルシステムは、クライアントから渡されたファイル識別情報に基づいて、要求されたファイルを第1のネットワークストレージのファイルシステム上で特定する。そして、第2のネットワークストレージは、特定されたファイルの属性及びデータを第1のネットワークストレージのファイルシステムから取得し、取得したファイルを第2のファイルツリーの所定の場所に格納させる。また、第1のネットワークストレージから第2のネットワークストレージに移されたファイルは、要求に応じて、第2のネットワークストレージからクライアントに提供される。
これにより、第2のネットワークストレージに移行されていないファイルへのアクセスがクライアントから要求された場合でも、要求されたファイルを第1のネットワークストレージから取得して、クライアントに提供することができる。また、クライアントへのファイル提供とほぼ同時期に、要求されたファイルを第2のファイルツリーの所定の場所に格納させることができる。ここで、「所定の場所」とは、第1のファイルツリー上での格納位置に対応する格納位置を示す。第2のネットワークストレージにファイルを移行させた後で、このファイルへのアクセス要求が発生した場合、第2のネットワークストレージは、第1のネットワークストレージにアクセスすることなく、自己のファイルシステム上でファイルを直接的に特定し、ファイルをクライアントに提供する。
ここで、ファイル移行部は、第1のネットワークストレージの記憶内容を変化させることなく、第1のネットワークストレージからファイルを取得して、第2のファイルツリーの所定の場所に格納させることができる。即ち、第1のネットワークストレージの記憶内容をそのまま保持しながら、ファイル単位で、第2のネットワークストレージにデータを移行させるため、万が一の事態に備えて第1のネットワークストレージの記憶内容をバックアップしておく必要がない。
ファイル移行部は、第1のネットワークストレージから取得したファイルが所定の条件を満たす場合に、この取得したファイルを第2のファイルツリーの所定の場所に格納させることができる。例えば、ファイルの利用頻度が所定値以上の場合に、第2のファイルツリーの所定の場所に格納させることができる。
ここで、例えば、ファイル特定部は、第1のネットワークストレージ上でファイルを特定するための第1のファイル識別情報と第2のネットワークストレージ上でファイルを特定するための第2のファイル識別情報とを対応付けて構成されるファイル特定用情報を参照することにより、クライアントから要求されたファイルを第1のネットワークストレージ上で特定することができる。
ファイル特定部は、クライアントから第1のネットワークストレージ上のファイルへのアクセス要求に基づいて、ファイル特定用情報を構築できる。即ち、例えば、ファイル特定部は、クライアントから第1のネットワークストレージ上のファイルへのアクセス要求に基づいて、第1のネットワークストレージから第1のファイル識別情報を取得し、この取得した第1のファイル識別情報と前記アクセス要求に関して生成された第2のファイル識別情報とを対応付けることにより、ファイル特定用情報を構築可能である。
一つの例を挙げると、クライアントが第2のネットワークストレージに対し、第1のファイル識別情報を用いてファイルアクセスを要求してきた場合、第2のネットワークストレージのファイルシステムは、この第1のファイル識別情報が無効(stale)であるとしてアクセス要求を拒否し、クライアントにリトライを要求する。
リトライ要求を受けたクライアントは、ディレクトリ名やファイル名を指定しながら、目的とするファイルに到達するまで、ファイルツリーを順番に辿っていく。クライアントがファイルツリーを順番に辿っていく過程と同期して、第2のネットワークストレージのファイルシステムは、第1のネットワークストレージのファイルシステムにアクセスし、第1のファイルツリーを順番に辿っていく。そして、目的とするファイルに辿り着いた場合、第2のネットワークストレージのファイルシステムは、そのファイルを第1のネットワークストレージ上で一意に特定するための第1のファイル識別情報を、第1のネットワークストレージのファイルシステムから取得する。なお、このとき、ファイルのデータ及び属性を第1のネットワークストレージのファイルシステムから取得して保存してもよいし、取得しなくてもよい。ここでは、取得しないものとして説明する。
また、第2のネットワークストレージのファイルシステムは、第1のネットワークストレージのファイルシステムから取得した第1のファイル識別情報と、自己が発行する第2のファイル識別情報とを対応付けてファイル特定用情報に登録する。そして、第2のネットワークストレージのファイルシステムは、第2のファイル識別情報をクライアントに通知する。クライアントは、通知された第2のファイル識別情報をメモリに保存し、この第2のファイル識別情報を用いて、所望のファイルへのアクセスを要求する。
第2のネットワークストレージのファイルシステムは、クライアントからのアクセス要求を受領すると、ファイル特定用情報を参照し、第2のファイル識別情報に対応する第1のファイル識別情報を取得する。第2のネットワークストレージのファイルシステムは、第1のファイル識別情報を用いて、第1のネットワークストレージのファイルシステムに対し、そのファイルのデータ及び属性を要求する。第2のネットワークストレージのファイルシステムは、第1のネットワークストレージから取得したファイルのデータ及び属性を所定の場所に保存すると共に、そのファイルをクライアントに提供する。
このように、第2のネットワークストレージのファイルシステムは、クライアントからのリトライアクセス(ファイルツリーを順番に辿っていく処理)と同様の処理を、あたかも自分がクライアントであるかのようにして、第1のネットワークストレージのファイルシステムに対し実行することができる。そして、第2のネットワークストレージは、第1のネットワークストレージの第1のファイルツリーを順番に辿っていく過程で、第1のファイルツリーと同一構造の第2のファイルツリーを構築することができる。
ファイルツリー生成部は、第1のネットワークストレージ上のファイルが第2のファイルツリーの所定の場所に移行済みであるか否かを示す移行状態情報を第2のファイルツリーの構造に対応付けて、第2のファイルツリーを生成することができる。ファイルツリーの構造は、そのツリーを構成する各要素(ファイルやディレクトリ)の繋がり方で表すことができる。そこで、ファイルツリーの構造を構成する一要素としてのファイルについて、そのファイルの実体(データ)が第2ネットワークストレージに移行済みであるか否かを示す情報(移行状態情報)を対応付けておく。つまり、将来そのファイルのデータが格納されるべき場所に、そのファイルのデータが未だ移行されていないことを示す情報を対応付けておく。これにより、第2のネットワークストレージのファイルシステムは、移行状態情報を参照することにより、そのファイルが移行されているか否かを即座に判断することができる。
ファイル特定部は、ファイルツリー生成部がディレクトリ階層構造としての第2のファイルツリーを生成する際に、第1のネットワークストレージから取得する第1のファイル識別情報をファイル特定用情報に予め格納しておくことができる。そして、ファイル特定部は、クライアントからのアクセス要求を処理する度に第1のファイル識別情報に対応して生成される第2のファイル識別情報を、ファイル特定用情報に予め格納された第1のファイル識別情報に対応付けて、ファイル特定用情報に格納させることにより、ファイル特定用情報を大きく2段階に分けて構築できる。即ち、第1段階は、第1のファイル識別情報をファイル特定用情報に登録する段階であり、第2段階は、第2のファイル識別情報を第1のファイル識別情報に対応付けてファイル特定用情報に登録する段階である。
本発明の機能、手段、ステップの全部または一部は、例えば、マイクロコンピュータにより実行されるコンピュータプログラムとして構成可能な場合がある。そして、このコンピュータプログラムは、例えば、ハードディスク、光ディスク、半導体メモリ等の記憶媒体に固定して配布することができる。または、コンピュータプログラムをインターネット等の通信ネットワークを介して、配信することもできる。
以下、図面に基づき、本発明の実施の形態を説明する。図1,図2は、本実施形態の一つの側面に従う全体概念を示す説明図である。本実施形態のストレージシステムは、クライアント3に提供するファイルを記憶する第1のネットワークストレージ1と、クライアント3及び第1のネットワークストレージ1にそれぞれ接続される第2のネットワークストレージ2とを備えている。
このストレージシステムでは、第1のネットワークストレージ1が有する第1のファイルツリーと同一構造の第2のファイルツリーを、ファイルシステムのディレクトリ階層構造として、第2のネットワークストレージ2上に生成させる。そして、クライアント3から第2のネットワークストレージ2上のファイルへのアクセス要求に基づいて、クライアント3から要求されたファイルを第1のネットワークストレージ1上で特定し、特定されたファイルの属性及びデータを第1のネットワークストレージ1から取得し、この取得したファイルを第2のファイルツリーの所定の場所に格納させる。
図1(a)は、第2のネットワークストレージ2を追加する前のストレージシステムの状態を示す。クライアント3は、ファイルディスクリプタ等のようなファイル識別情報fdを指定することにより、第1のネットワークストレージ1のファイルシステム1Aに対し、所望のファイルを要求する。
ファイル識別情報fdとは、そのファイル(ディレクトリを含む場合もある)を管理するファイルシステムやOS(Operating System)内において、そのファイルを一意に特定するための情報である。ファイル識別情報fdとしては、例えば、ファイルディスクリプタを挙げることができる。ファイルディスクリプタを用いることにより、例えば、「/usr/dir1/file1.txt」等のようなフルパスを指定することなく、簡単にファイルを特定することができる。ファイルディスクリプタの生成規則は、ファイルシステムの種類に依存し、各ファイルシステム毎にそれぞれ異なる。ファイルディスクリプタにバッファの管理機能等を含めた管理体系をファイルハンドルと呼ぶ。
例えば、クライアントコンピュータの起動直後等のように、クライアント3が所望のファイルのファイル識別情報を保持していない場合、クライアント3は、ファイルツリーを順番に所望のファイルまで辿っていくことにより、ファイルシステム1Aからファイル識別情報を取得する。そして、クライアント3は、ファイル識別情報を指定して、ファイルシステム1Aにファイルアクセスを要求する。
ファイルシステム1Aは、クライアント3からファイル識別情報を指定されると、このファイル識別情報に基づいて、自己の管理下にあるファイル群の中から、指定されたファイルを直接的に特定し、クライアントに提供する。もしも、指定されたファイルが削除されていたような場合、そのファイル識別情報は無効(stale)として扱われ、ファイルシステム1Aからクライアント3に対し、エラーが通知される。以下の説明では、第1のファイルシステム1Aにより管理されるファイル識別情報をfd1と、第2のファイルシステム2Aにより管理されるファイル識別情報をfd2と、それぞれ省略して記載する。
図1(b)は、ストレージシステムに第2のネットワークストレージ2を追加した場合の説明図である。第2のネットワークストレージ2は、第1のネットワークストレージ1を置き換える(リプレース)ために導入される。第2のネットワークストレージ2は、IPアドレス等のネットワーク設定情報を第1のネットワークストレージ1から継承し、第1のネットワークストレージ1に成りかわる。
第2のネットワークストレージ2は、例えば、情報処理サービスの提供終了後に導入することができる。なお、後述の実施例からも明らかなように、本発明では、情報処理サービスの提供中であっても、第2のネットワークストレージ2をストレージシステムに導入可能であり、情報処理サービスを中断することなく、第1のネットワークストレージ1から第2のネットワークストレージ2への移行を行うことができる。
第2のネットワークストレージ2のファイルシステム2Aは、第1のネットワークストレージ1のファイルシステム1Aとの間で通信を行うことにより、第1のネットワークストレージ1が有するファイルツリーと同一構造のファイルツリーを、第2のネットワークストレージ2に構築する。
ここで、本明細書におけるファイルツリーとは、ディレクトリ階層構造としてのツリー構造、即ち例えるなら、所定構造を有する「容器」を意味し、ファイルの実体であるデータとは切り離して用いる。従って、第1のネットワークストレージ1から第2のネットワークストレージ2へファイルツリー構造をコピーした場合でも、個々のファイルのデータまでは移行されていない。
ファイルツリー構造のコピーは、例えば、第2のファイルシステム2Aから第1のファイルシステム1Aに対し、リスト要求コマンド等を送信し、このコマンドに対して第2のファイルシステム2Aが応答することにより実行される。第2のファイルシステム2Aは、第1のファイルツリーのルートディレクトリ(”/”)から下位に向けて順番にツリー構造を辿りながら、その構造としてのファイルツリーをコピーする。例えば、ルートディレクトリの下位に、”usr”,”etc”というディレクトリが存在する場合、第2のファイルシステム2Aは、これらの”usr”,”etc”にそれぞれiノード番号を割当てると共に、iノード番号間の繋がりを規定することにより、ツリー構造をコピーする。
ファイルの格納容器としてのファイルツリーを第2のネットワークストレージ2にコピーした時点では、ファイルのデータはコピーされていない。図1(b)に示すように、第1のネットワークストレージ1が記憶するファイル4Aのデータは、第2のネットワークストレージ2に未だコピーされておらず、そのファイルデータを格納すべき場所4Bのみが確保されている。
なお、第1のネットワークストレージ1から第2のネットワークストレージ2へファイルツリー構造をコピーする際に、第2のネットワークストレージ2のファイルシステム2Aは、第1のファイルシステム1Aから、ファイルツリー構造の各構成要素(個々のディレクトリ及びファイル)のfd1を取得することができる。そして、取得したfd1を変換部2Bに登録することができる。
第1のファイルシステム1Aで管理するfd1と、第2のファイルシステム2Aで管理するfd2とを対応付けて管理する変換部2Bは、複数のタイミングで生成することができる。後述の実施例からも明らかなように、一つの方法として、ファイルツリー構造をコピーした後、クライアント3からのアクセス要求に基づいて、fd1とfd2との対応関係を徐々に構築することができる。他の一つの方法として、ファイルツリー構造をコピーする際に、fd1と第2のファイルシステム2Aが管理するiノード番号とを対応付けておき、その後、クライアント3からのアクセス要求に基づいてfd2を発行する際に、fd2とfd1とを対応させることもできる。
図1(c)は、第2のネットワークストレージ2がサービスの提供を再開した様子を示している。クライアント3は、第2のネットワークストレージ2のファイルシステム2Aから、所望のファイルのfd2を取得する。説明の便宜上、所望のファイルのfdをfd(file)として示す。クライアント3は、第2のネットワークストレージ2のファイルツリー構造を上から順番に辿っていくことにより、所望のファイルを特定するためのfd2(file)を入手することができる。本実施形態では、ファイルツリー構造の移行が完了した時点で、第2のネットワークストレージ2からクライアント3へのNASサービスを提供可能であるため、サービス停止時間を短くできる。
図2に移る。図2(d)は、クライアント3が、第2のファイルシステム2Aから入手したfd2(file)を用いて、所望のファイルへのアクセスを要求する様子を示す。
第2のファイルシステム2Aは、クライアント3からfd2(file)を受領すると、変換部2Bによって、fd2(file)を第1のファイルシステム1Aが管理するfd1(file)に変換する。そして、第2のネットワークストレージ2は、fd1(file)を指定して、第1のネットワークストレージ1に対し、所望のファイルの取得を要求する。
図2(e)に示すように、第1のファイルシステム1Aは、第2のネットワークストレージ2からfd1(file)を受領すると、直ちにファイルを特定し、このファイルのデータ及び属性を第2のネットワークストレージ2に転送する。ここで、もしも仮に、第2のネットワークストレージ2が、fd1(file)ではなく、fd2(file)を用いてファイルの取得を要求した場合、第1のファイルシステム1Aは、fd2(file)に基づいてファイルを特定することができないため、エラーを返す。
しかし、本実施形態では、第2のネットワークストレージ2は、第1のファイルシステム1Aで管理されるfd1(file)を用いて、ファイルを要求するため、第1のファイルシステム1Aは、要求されたファイルを直ちに特定して、ファイルのデータを第2のネットワークストレージ2に送信することができる。
第2のネットワークストレージ2は、第1のネットワークストレージ1からファイルのデータを受領すると、このデータをファイルツリーの所定の場所4Bに格納する。この格納場所4Bは、既に述べたように、そのファイルのデータが記憶されるべきディレクトリ階層構造上の位置として、ファイルツリーのコピー時に生成されたものである。
第2のネットワークストレージ2は、ファイルを所定場所4Bに格納すると共に、そのファイルのデータをクライアント3に送信する。従って、クライアント3からは、第2のネットワークストレージ2に対するfd2(file)の指定によって、所望のファイルを取得できたように見えない。第2のネットワークストレージ2と第1のネットワークストレージ1との間のやり取りは、クライアント3に対して隠されている。
図2(f)は、第1のネットワークストレージ1が保持するファイル群を、第2のネットワークストレージ2に移行させた後の状態を示す。上述のように、本実施形態では、ファイルツリー構造のみを先に移行してサービスを再開し、その後、クライアント3からの要求に応じて、要求されたファイルのデータを第1のネットワークストレージ1から第2のネットワークストレージ2に個別に移行させる。
従って、本実施形態では、クライアント3がファイルを必要とする場合に、その必要とされたファイルのみをファイル単位で移行させることができる。このような運用を続けているうちに、第1のネットワークストレージ1の有する多くのファイル群が、第2のネットワークストレージ2にコピーされていく。第1のネットワークストレージ1に残されたままのファイル群は、クライアント3から必要とされていないファイル群であるから、そのまま破棄しても構わないし、後日に備えて残しておいてもよい。ここで、第1のネットワークストレージ1から第2のネットワークストレージ2への移行に際して、第1のネットワークストレージ1の記憶内容には何らの変化も生じないため、第1のネットワークストレージ1のデータをバックアップしておく必要はない。第1のネットワークストレージ1が保持するファイル群は、第1のネットワークストレージ1自身にそのまま保持させておくことができる。
上述のように、クライアント3から必要とされる範囲のファイル群が、第1のネットワークストレージ1から第2のネットワークストレージ2に移行された場合に、第2のネットワークストレージ2は、第1のネットワークストレージ1に置き換わる。クライアント3は、fd2を指定して第2のファイルシステム2Aにファイルアクセスを要求すればよく、第2のネットワークストレージ2は、fd2をfd1に変換したり、第1のネットワークストレージ1にアクセスする必要はない。
ここで、第1のネットワークストレージ1から第2のネットワークストレージ2にファイルを移行させる場合に、所定の条件を設定することができる。即ち、第1のネットワークストレージ1から読み出されたファイルが所定の条件を満たすときに、この読出したファイルを第2のファイルツリーの所定の場所に格納させることができる。
所定の条件としては、例えば、ファイルの利用頻度等を挙げることができる。第1のネットワークストレージ1から読出されたファイルの利用頻度が所定値以上の場合は、所定条件が満たされたものと判定し、第2のファイルツリーの所定の場所に格納させる。
ファイルの利用頻度としては、例えば、そのファイルに対して所定期間内に所定回数以上のアクセスが発生したか否か、そのファイルの最終更新日から所定期間が経過しているか否か、そのファイルにアクセスする共有クライアント数が所定値以上であるか否か等を挙げることができる。
利用頻度の低いファイルは、クライアント3からアクセスが要求された場合であっても、第1のネットワークストレージ1から第2のネットワークストレージ2に移行させずに第1のネットワークストレージ1上に残しておくことができる。第1のネットワークストレージ1上に残されたファイルについては、クライアント3からアクセスが要求される度に、第2のネットワークストレージ2が第1のネットワークストレージ1にアクセスして、読み出す。利用頻度の低いファイルを第2のネットワークストレージ2に移行させず、第1のネットワークストレージ1上に残しておくことにより、利用頻度の低いファイルを自然に淘汰することができ、第2のネットワークストレージ2の記憶領域を効率的に使用することができる。もっとも、所定の条件(ファイル移行条件)は、固定的なものである必要はなく、動的に変更可能としてもよい。例えば、クライアント3からのアクセス要求が所定回数に達したような場合には、そのファイルを第1のネットワークストレージ1から第2のネットワークストレージ2に移し替えることもできる。
以下、ネットワークストレージシステムのより詳細な構成について、図3以下を参照しながら説明する。
図3は、ネットワークストレージシステムのハードウェア構成に着目した概略ブロック図である。ネットワークストレージシステムは、それぞれ後述するように、複数のクライアント10,11と、ネットワークストレージ20と、これら各クライアント10,11とネットワークストレージ20とを相互に接続する通信ネットワークCN1とを備えて構成することができる。
クライアント10,11は、コンピュータ装置に搭載されたプログラムであり、ネットワークストレージ20が提供するファイル共有サービス(NASサービス)を利用するためのものである。ここで、例えば、クライアント10は、UNIX(登録商標)OS上にNFS(Network File System,登録商標)を設けたNFSクライアントである。また、例えば、クライアント11は、Windows(登録商標)OS上にCIFS(Common Internet File System,登録商標)を設けたCIFSクライアントである。NFS,CIFSは、ファイルアクセス用のプロトコルであり、例えば、TCP/IP(Transmission Control Protocol/Internet Protocol)上で稼働する。
ネットワークストレージ20は、例えば、NASとして構成されるもので、NFSやCIFS等の多種類のファイルアクセスプロトコルに対応可能である。ネットワークストレージ20は、NASヘッド等とも呼ばれる制御部30と、記憶部40とを備えている。制御部30は、例えば、CPU(Central Processing Unit)31と、RAM(Random Access Memory)32と、ROM(Read Only Memory)33と、通信インターフェース(以下、「通信I/F」)34〜36とを備えて構成することができる。通信I/F34は、例えば、LAN等の通信ネットワークCN1を介して、各クライアント10,11との間でデータ送受信を行う上位通信I/Fである。通信I/F35,36は、例えば、SAN(Storage Area Network)等の通信ネットワークCN2を介して、記憶部40との間でデータ送受信を行う下位通信I/Fである。
制御部30は、各クライアント10,11から受信したコマンドを解釈し、コマンドの内容に従って、記憶部40にアクセスする。制御部30は、記憶部40から読出したファイルを各クライアント10,11に送信する。また、制御部30は、記憶部40から読出したファイルの全部または一部を書き換えて、記憶部40に記憶させる。
記憶部40は、複数の記憶デバイス41を備えている。各記憶デバイス41は、例えば、ハードディスクドライブ、半導体メモリ装置、光ディスクドライブ等として構成することができる。各記憶デバイス41には、複数の通信ネットワークCN2がそれぞれ接続されている。一方の通信ネットワークCN2に障害が発生した場合でも、他方の通信ネットワークCN2を介して記憶デバイス41にアクセス可能である。また、例えば、3個、4個、5個等のような複数個の記憶デバイス41が一つのRAID(Redundant Array of Independent Disks)グループを構成している。各RAIDグループには、少なくとも一つ以上の論理ボリュームを形成することができる。即ち、各記憶デバイス41がそれぞれ提供する物理的な記憶領域上には、論理的な記憶領域である論理ボリューム(Logical Unit:以下、「LU」)が形成される。
なお、図中では、ネットワークストレージ20内に記憶部40を備える場合を示すが、記憶部40の全部または一部をネットワークストレージ20の筐体外部に設ける構成でもよい。例えば、多数の記憶デバイスをアレイ状に配設して構成するディスクアレイ装置を記憶部40として利用することもできる。
図4は、ネットワークストレージシステムのソフトウェア構成に着目した概略ブロック図である。ネットワークストレージ20は、例えば、ネットワークプロトコル層51と、ファイルアクセスプロトコル層52,53と、ファイルシステム54と、論理ボリュームマネージャ(以下、「LVM」)55と、デバイスドライバ群56と、複数のLU57(一つのみ図示)等を備えて構成することができる。
ネットワークプロトコル層51は、例えば、TCP/IPやUDP/IP(User Datagram Protocol/Internet Protocol)等のようなプロトコルをサポートしており、これらのプロトコルに従ってデータの送受信を行う。ファイルアクセスプロトコル層52,53は、ファイルアクセスのためのプロトコルをサポートする。例えば、一方のファイルアクセスプロトコル52はNFSであり、他方のファイルアクセスプロトコル53はCIFSである。
ファイルシステム54は、各LU57へのファイルの入出力等を制御するプログラムであり、各LU57毎にそれぞれファイルツリーを形成する。アクセス制限等が設定されているような場合を除き、各ファイルツリーは、各クライアント10,11にそれぞれ提供可能である。
LVM55は、LU57の管理機能を提供するプログラムである。LVM55は、例えば、複数のLU57を束ねて、ユーザが使用し易い容量のボリュームに分割等する。また、LVM55は、スナップショット機能を備えることもできる。スナップショットとは、ある時点におけるデータの静止化イメージである。スナップショット機能とは、スナップショット作成時点における記憶構成を仮想ボリュームとして提供する機能である。デバイスドライバ群56は、ストレージアクセスの単位であるLU57を上位のLVM55にアクセスさせるために、スペシャルファイルの形式でデータを提供する。
ファイルシステム54は、クライアント10,11からディレクトリ名及びファイル名を明示したコマンドを受領する。ファイルシステム54は、受領したコマンドに基づいて、クライアント10,11から要求されたファイルをボリューム位置情報に変換する。ボリューム位置情報は、例えば、ファイルデータの存在するボリューム番号やセグメント情報から構成される。ファイルシステム54は、アクセス対象のファイルをボリューム位置情報に変換して、LVM55にデータアクセスを要求する。LVM55は、ファイルシステム54からのアクセス要求を受領すると、LU57上のブロックアドレスに変換し、デバイスドライバ群56に渡す。デバイスドライバ群56は、LVM55から受領したブロックアドレスに基づいてLU57にアクセスし、ファイルのデータを読み出す。読み出されたファイルデータは、ネットワークストレージ20のRAM32に一時的に記憶され、クライアント10,11に送信される。
次に、図5は、ネットワークストレージシステムの機能構成に着目した概略ブロック図である。ネットワークストレージシステムは、複数のクライアント10,11と、新設されるネットワークストレージ100(以下、「新NAS100」)と、既に設置されているネットワークストレージ200(以下、「旧NAS200」)と、LAN等の通信ネットワークCN1とを備えている。
各NAS100,200は、それぞれ図3,図4に示したような構成を備えることができる。各NAS100,200は、同一構造である必要はない。旧NAS200は、各クライアント10,11へNASサービスを提供する機能を備えていれば足りる。後述のように、本実施形態に特徴的な各機能は、新NAS100に実装される。但し、場合によっては、特徴的な各機能の全部または一部を新NAS100の外部に設けてもよい。
新NAS100は、例えば、ファイルシステム101と、LU102と、通信部104とを備えて構成することができる。より詳しくは、新NAS100は、図4と共に述べたように、LVMやデバイスドライバ群等の構成も備えているが、説明の便宜上、図5中では図示を省略している。ファイルシステム101は、図4中のファイルシステム54に、LU102は図4中のLU57に、通信部104は図4中のネットワークプロトコル層51及びファイルアクセスプロトコル層52,53に、それぞれ対応する。
ファイルシステム101の内部機能は、例えば、管理部110と、ファイルツリー生成部120と、アクセス要求処理部130とに分類可能である。
管理部110は、ファイルツリーの管理を行うもので、例えば、fd−iノード変換部111と、fd−fd変換部112と、iノード情報管理部113とを備えて構成することができる。
fd−iノード変換部111は、クライアントから受領したファイルディスクリプタfdをiノード番号に変換する機能である。fd−iノード変換部111は、例えば、fd−iノード変換テーブルT11を参照することにより、入力されたファイルディスクリプタfdをiノード番号に変換することができる。これに限らず、例えば、fdからiノード番号を算出可能な場合は、fd−iノード変換テーブルT11を廃止し、fd−iノード変換部111内でファイルディスクリプタfdをiノード番号に変換するようにしてもよい。
fd−fd変換部112は、新NAS100が発行したファイルディスクリプタfd(new)を、旧NAS200が発行したファイルディスクリプタfd(old)に変換する機能である。図中では、新NAS100が発行したファイルディスクリプタを新fdと、旧NAS200が発行したファイルディスクリプタを旧fdと表示している。fd−fd変換部112は、例えば、fd−fd変換テーブルT12を参照することにより、新fdを旧fdに変換する。必要があれば、旧fdを新fdに変換することもできる。後述のように、fd−fd変換テーブルT12は、ファイルツリーを旧NAS200から新NAS100に移行する際に、旧fdに関する部分だけが先に生成される。そして、NASサービスを再開した後、クライアント10,11からのファイルアクセスに応じて、fd−fd変換テーブルT12の残りの部分が徐々に段階的に生成されるようになっている。
iノード情報管理部113は、各iノードの情報を管理するものである。iノード(iノード情報)とは、各ファイル(ディレクトリ)毎にそれぞれ与えられるファイル属性を示す情報である。UNIX(登録商標)の場合、ディレクトリもファイルのように扱われる場合がある。iノードのキーとなるiノード番号とは、ファイルシステム上でファイルを識別するための整数値である。各ファイルは、iノード番号によって、実ボリューム102における格納位置が特定されるようになっている。iノードの情報としては、例えば、そのファイル(またはディレクトリ)の所有者、ファイルサイズ、ファイルの格納先アドレス、ファイルかディレクトリかの区別(ツリーの終端であるか否かを示す情報)等のファイル(ディレクトリ)属性情報を挙げることができる。iノード情報管理部113は、取得した属性情報をiノード情報管理テーブルT13に登録することができる。
ファイルツリー生成部120は、各LU102にそれぞれファイルツリーを生成するものである。また、ファイルツリー生成部120は、旧NAS200の有するファイルツリーと同一構造のファイルツリーを、新NAS100のLU102上に形成する機能を備えている。
アクセス要求処理部130は、クライアントからのファイルアクセス要求を処理するものである。アクセス要求処理部130は、例えば、旧fd取得部131と、新fd発行部132と、移行状態判定部133と、ファイル移行部134とを備えて構成することができる。旧fd取得部131は、目的のファイルについて旧NAS200が発行している旧fdを、旧NAS200から取得するものである。新fd発行部132は、クライアントからのアクセスに応じて、ファイルやディレクトリの新fdを発行し、クライアントに通知させるものである。移行状態判定部133は、旧NAS200のファイルツリーから新NAS100のファイルツリーにファイルデータ(ファイルの実体)が移行済であるか否かを管理するものである。ファイル移行部134は、未移行のファイルデータを旧NAS200から取得し、この取得したファイルデータを旧NAS200のファイルツリーに対応するファイルツリーの所定の場所に記憶させるものである。
ファイルツリー生成部120とアクセス要求処理部130とは、それぞれ必要に応じて管理部110にアクセスし、各テーブルT11〜T13から情報を取得したり、各テーブルT11〜T13に情報を登録する。なお、上記のような機能分類は一例であって、本発明はこれに限定されない。
旧NAS200は、ファイルシステム201とLU202とを備えている。これ以外の機能については、説明及び図示を省略する。旧NAS200は、新NAS100が導入される前から運用されているネットワークストレージであり、そのLU202には、各クライアント10,11によって利用される多数のファイル群が記憶されている。新NAS100の導入前は、旧NAS200が通信ネットワークCN1を介して、各クライアント10,11にNASサービスを提供する。
新NAS100を導入する際に、旧NAS200のネットワーク設定情報は、新NAS100に受け継がれる。そして、旧NAS200は、通信ネットワークCN1から切り離され、新NAS100に通信ネットワークCN2を介して直接的に接続される。
図6は、旧NAS200から新NAS100へファイルツリー構造をコピーする様子を示す模式図である。図中の上側に示すように、旧NAS200のファイルシステム201は、ファイルツリー203を利用して、ファイルへのアクセス要求を処理する。
旧NAS200の有するファイルツリー203と同一構造を有するファイルツリー103を新NAS100上に生成する場合、新NAS100のファイルシステム101は、旧NAS200のファイルシステム201に所定のコマンドを送信する。新NAS100のファイルシステム101は、旧NAS200のファイルシステム201からの応答に基づいて、ファイルツリー103を構築する。
例えば、新NAS100のファイルシステム101は、旧NAS200のファイルシステム201にLOOKUPコマンドやlsコマンド等を送信することにより、旧NAS200のファイルツリー203のルートディレクトリ(”/”)から下位に向けて、ディレクトリ階層構造を辿っていく。図6中の(a)に示すように、新NAS100には、部分的にファイルツリー103が構築されていく。このファイルツリー103は、ファイルデータの格納場所の位置関係を相互に関連付けたものであり、この段階では、ファイルのデータはコピーされない。
図6(a)のテーブルT12に示すように、旧NAS200のファイルツリー構造を上位ディレクトリから下位ディレクトリに向けて辿りながらファイルツリー構造をコピーする過程において、旧NAS200のファイルシステム201で管理される旧fdと、新NAS100のファイルシステム101で管理される新fdとを対応付けて管理することができる。正確には、新fdと旧fdとを直接対応づけるのではなく、新fdと一対一で対応するiノード番号を介して、新fdと旧fdとの対応付けを行うことができる。
即ち、ファイルツリー構造をコピーする過程において、旧NAS200のファイルシステム201から旧fdが取得され、また、新NAS100のファイルシステム101は、ファイルツリーの各構成要素にそれぞれiノード番号を割り当てる。このiノード番号は、ファイルシステム101が発行する新fdと一対一で対応する。従って、ファイルツリー構造をコピーする過程で、旧fdとiノード番号とを対応付けておくことにより、間接的に、旧fdと新fdとを対応付けることができる。旧fdとiノード番号とを先に対応付ける方法については、別の実施例でさらに後述する。
旧fdと新fdとの対応付けは、ファイルツリー構造の移行時に行うこともできるし、後述のように、ファイルツリー構造の移行が完了した後、クライアントからのファイルアクセスに応じて、新旧のfdを対応付けることもできる。
図6(b)に示すように、やがて、旧NAS200のファイルツリー203と同一構造のファイルツリー103が、新NAS100上に構築される。これと同時に、旧fdと新fd(iノード番号)との対応付けも完了する。但し、上述のように、旧fdと新fdとの対応関係の構築方法には種々の変形例が存在する。
旧NAS200から新NAS100にコピーされるファイルツリー構造は、ファイルの格納場所を示すもので、ファイルのデータはコピーされていない。そのことを示すために、図6中では「file」を破線で囲んである。
次に、図7及び図8を参照して、iノード情報を用いたファイルの特定方法について説明する。まず、図7に基づいて、旧NAS200上で実行されるファイル特定方法を説明する。ディレクトリ「dir1」に格納されているファイル「file1.txt」のデータにアクセスする様子を例に挙げて説明する。
最初に、ルートディレクトリのiノード情報を参照する。図示の例では、ルートディレクトリにiノード番号「2」が与えられている。ルートディレクトリのiノード情報には、ルートディレクトリの所有者、ファイルサイズ等の属性の他に、ファイルアドレスAdr1が含まれている。アドレスAdr1は、実ボリュームであるLU202上の記憶位置を示している。
そこで、図7中の右側に示すように、アドレスAdr1に記憶されているデータ内容を参照する。そこには、ルートディレクトリに含まれている各ディレクトリの名称及びそのiノード番号がそれぞれ格納されている。具体的には、例えば、「usr,10」とは、iノード番号「10」を与えられたディレクトリ「usr」を示す。同様に、「bin,20」とは、iノード番号「20」を与えられたディレクトリ「bin」を示す。従って、ルートディレクトリのデータ内容として、「usr,10,bin,20,etc,30」と記述されている場合は、ルートディレクトリ下に、iノード番号「10」のディレクトリ「usr」と、iノード番号「20」のディレクトリ「bin」と、iノード番号「30」のディレクトリ「etc」がそれぞれ設けられていることを示す。
ルートディレクトリ下にディレクトリ「usr」が存在することを確認した後、iノード番号「10」のiノード情報を参照する。iノード番号「10」は、ディレクトリ「usr」に与えられている番号である。そのiノード情報には、ファイルアドレスAdr2が含まれている。そこで、アドレスAdr2に記憶されているデータ内容を参照すると、ディレクトリ「usr」には、2個のサブディレクトリ「dir1」,「dir2」が含まれていることがわかる。
サブディレクトリ「dir1」のiノード情報を参照すると、そこには、ファイルアドレスAdr3が含まれている。アドレスAdr3に記憶されているデータ内容を参照すると、「dir1」には、ファイル「file1.txt」が格納されていることがわかる。そこで、ファイル「file1.txt」に与えられたiノード番号「101」をキーとして、そのファイルのiノード情報を参照する。ファイル「file1.txt」のiノード情報には、ファイルアドレスAdr4が含まれている。また、このiノードがファイルツリーの末端であることを示す末端情報も含まれている。ファイル「file1.txt」のデータは、アドレスAdr4に記憶されているので、アドレスAdr4からファイルデータを読み出すことができる。このようにして、iノード情報管理テーブルをルートディレクトリから順番に辿ることにより、目的のファイルにアクセスすることができるようになっている。
図8は、新NAS100上で実行されるファイル特定方法を示す。図7に示すiノード情報管理テーブルと図8に示すiノード情報管理テーブルT13とは、3つの点で相違している。第1の相違点は、ファイルツリーを構成する各要素(ファイル、ディレクトリ)に与えられるiノード番号がそれぞれ異なる点である。ルートディレクトリには、新旧のNAS100,200のいずれにおいても、iノード番号「2」が与えられているが、ルートディレクトリ下のファイル(ディレクトリを含む)には、それぞれ異なるiノード番号が付与されている。つまり、iノード番号の設定方法は、ファイルシステム毎にそれぞれ相違する。
第2の相違点は、各iノード情報に関連付けられるデータ内容の記憶先アドレスが、新旧のNAS100,200でそれぞれ相違する点である。
第3の相違点は、新NAS100のiノード情報管理テーブルT13には、未更新フラグが追加されている点である。未更新フラグとは、ファイルが新NAS100のLU102に移行済であるか否かを示す情報である。未更新フラグは、例えば、「移行状態情報」や「移行状態判別情報」等と呼ぶこともできる。ディレクトリのiノード情報には、未更新フラグは設定されない。未更新フラグは、ファイルのみに設定される。未更新フラグが「1」の場合は、そのファイルが新NAS100に移行されていないことを示す。この第3の相違点は、本実施形態の特徴的構成の一つである。なお、未更新フラグは、iノード情報管理テーブルT13内に含まれている必要は必ずしもなく、iノード番号と対応付けられていればよい。
次に、図9に基づいて、fd−iノード変換テーブルT11及びfd−fd変換テーブルT12の構成例について説明する。図9(a)は、fd−iノード変換テーブルT11を示す。fd−iノード変換テーブルT11には、例えば、新NAS100が発行する複数の新fdと、これら各新fdに対応付けられるiノード番号とが記憶されている。
図9(b)は、fd−fd変換テーブルT12を示す。fd−fd変換テーブルT12は、新NAS100で発行された新fdと旧NAS200で発行された旧fdとが対応付けられて記憶されている。
図9(c)は、fd−iノード変換テーブルT11とfd−fd変換テーブルT12とを統合した変換テーブルT11Aを示す。この変換テーブルT11Aは、新NAS100におけるiノード番号と、新fdと、旧fdとがそれぞれ対応付けられている。変換テーブルT11及びT12の2つのテーブルを使用してもよいし、代わりに変換テーブルT11Aのみを使用してもよい。
次に、本実施形態の動作を説明する。本実施例では、NFSによる場合を例に挙げて説明する。CIFSの場合は、コマンド等が若干相違するが、基本的動作はほぼ同一であると考えよい。
まず、図10は、ストレージシステムの全体動作の概要を示す。旧NAS200によるサービスの停止から新NAS100によるサービス再開までの手順は、例えば、以下のように行うことができる。より詳細な手順は、図11以下でさらに説明する。
例えば、夜間や休日等のような通常業務の終了後に、旧NAS200は、サービスを停止する(P1)。次に、旧NAS200の有するファイルツリー203と同一構造のファイルツリーを、新NAS100にコピーする(P2)。ファイルツリー構造のコピーが完了した時点で、新NAS100は、NASサービスの提供を再開する(P3)。ファイルツリー構造のコピーを完了した後、直ちに新NAS100からNASサービスを再開可能である点は、本発明の一つの特徴である。
クライアント(10,11)は、新NAS100にアクセスする。新NAS100は、クライアントからLOOKUPコマンドを受信する(P4)。クライアントは、新NAS100に対して、lsコマンドやLOOKUPコマンド等を段階的に送信しながら、新NAS100のファイルツリー103をルートディレクトリから下位に向けて辿っていく(P5)。
アクセス対象のファイルをクライアントが発見すると、新NAS100は、旧NAS200にLOOKUPコマンド等を送信し、そのアクセス対象のファイルに対応付けられている旧fdを、旧NAS200から取得する(P6)。新NAS100は、そのアクセス対象のファイルについて、新fdを発行し、クライアントに通知する(P7)。また、新NAS100は、そのアクセス対象のファイルに関する新fdと旧fdとを対応付けて管理する(P8)。
クライアントは、新fdを指定して、ファイルへのアクセスを要求する(P9)。新NAS100は、クライアントから受領した新fdを旧fdに変換し、この旧fdを用いて旧NAS200からファイルのデータを取得する(P10)。そして、新NAS100は、旧NAS200から取得したファイルデータを記憶すると共に、このファイルデータをクライアントからのアクセスに提供する(P11)。
図11は、ネットワークストレージシステムに追加された新NAS100を立ち上げるまでの手順P1〜P3に対応する処理を示す概略フローチャートである。
最初に、システム管理者等は、新NAS100のネットワーク設定情報として、旧NAS200に設定されているIPアドレスやサーバ名を設定する(S11)。次に、システム管理者等は、旧NAS200によるNASサービスを停止させる(S12)。システム管理者等は、旧NAS200から各クライアント10,11へのNASサービスを停止させた後で、ケーブルの接続を切り替える(S13)。
即ち、システム管理者等は、旧NAS200を通信ネットワークCN1から切り離すと共に、旧NAS200と新NAS100とを通信ネットワークCN2によって直接的に接続する(S13)。
次に、新NAS100のルートディレクトリと旧NAS200のルートディレクトリとにそれぞれ対応付けられているファイルディスクリプタ同士を対応付けて、fd−fd変換テーブルT12に登録する(S14)。つまり、新NAS100のルートディレクトリに対応付けられているファイルディスクリプタ(新fd(root))と旧NAS200のルートディレクトリに対応付けられているファイルディスクリプタ(旧fd(root))とを対応付けて、fd−fd変換テーブルT12に登録する。
システム管理者等は、ファイルツリー構造の移行処理を開始させる。このファイルツリー構造の移行処理の詳細は、さらに後述する。先に簡単に概略を述べると、旧NAS200は、新NAS100に対してNASサービスを提供する(S15)。新NAS100は、旧NAS200に所定のコマンドを送信することにより、そのファイルツリー構造を問合せる。新NAS100は、旧NAS200からの応答内容に基づいて、旧NAS200の有するファイルツリーと同一構造のファイルツリーを生成する(S16)。
ファイルツリー構造をコピーする段階で、旧NAS200で管理される旧fdと新NAS100で管理されるiノード番号との対応付けも完了する(S17)。そして、新NAS100は、ファイルツリー構造のコピーが完了した時点で、クライアントへサービス提供を開始する。既に、新NAS100は、旧NAS200のネットワーク設定情報を継承しているため、クライアントは、旧NAS200から新NAS100に入れ替わったことを特に意識することなく、ファイルアクセスを要求する。
従って、各クライアント10,11から見たNASサービスの停止期間は、S11におけるNASサービスの停止時点からS18におけるNASサービスの再開時点までの期間となる。つまり、実質的に、旧NAS200から新NAS100へのファイルツリーの移行が完了した時点で、各クライアント10,11に対するNASサービスが再開される。但し、新NAS100から各クライアント10,11へNASサービスの提供を開始する時点では、新NAS100は、旧NAS200が記憶しているファイルを記憶していない。後述のように、各クライアント10,11が、旧NAS200の記憶するファイルに対してファイルアクセスを要求した場合、このファイルアクセスに応じて、必要なファイルが旧NAS200から新NAS100へファイル単位で移行される。
このように、本実施形態では、旧NAS200が有するファイルツリー構造のみを新NAS100に先に移行させた段階で、NASサービスを直ちに再開する。その後、各クライアント10,11からのアクセス要求に応じて、必要とされたファイルのみを旧NAS200から新NAS100へ移行させるようになっている。
図12〜図14に基づいて、ファイルツリー構造の移行処理の一例を説明する。以下の説明では、主として、旧NAS200に記憶されたファイル(/root/usr/dir1/file1.txt)を新NAS100に移行させる場合を説明する。
図12は、ルートディレクトリ直下の3つのディレクトリ「usr」、「bin」、「etc」を旧NAS200から新NAS100へ移行させる様子を示す。まず最初に、新NAS100は、旧NAS200に対して、lsコマンドを発行する(S21)。lsコマンドとは、ディレクトリ内のファイル一覧を要求するコマンドである。つまり、S21では、旧NAS200が有するファイルツリー203のルートディレクトリをネットワークマウントし、lsコマンドを発行し、ルートディレクトリ直下の構造を調査する。以下、本明細書において、lsコマンドの発行とは、旧NAS200のルートディレクトリを新NAS100がネットワークマウントし、特定ディレクトリに対して新NAS100がlsコマンドを発行することを言う。
旧NAS200は、新NAS100からlsコマンドを受信すると(S22)、ルートディレクトリ直下に3つのディレクトリ「usr」、「bin」、「etc」が存在する旨を、新NAS100に送信する(S23)。
新NAS100は、旧NAS200からのリスト応答を受信すると(S24)、これら3つのディレクトリについて、それぞれiノード番号を割り当てる(S25〜S27)。本実施例では、「usr」にiノード番号「3」を(S25)、「bin」にiノード番号「4」を(S26)、「etc」にiノード番号「5」を(S27)、それぞれ割り当てる。
新NAS100は、ルートディレクトリのデータ内容として、「usr,3,bin,4,etc,5」をiノード情報管理テーブルT13に登録する(S28)。そして、図8にも示すように、新NAS100は、ルートディレクトリのiノード情報として、「usr,3,bin,4,etc,5」を格納した記憶先のアドレスAdr11と、ルートディレクトリのファイルサイズとを、iノード情報管理テーブルT13に登録する(S29)。
次に、新NAS100は、旧NAS200に対し、ルートディレクトリに関するGETATTRコマンドを発行する(S30)。ここで、GETATTRコマンドとは、ファイルの属性情報を要求するコマンドである。旧NAS200は、新NAS100からGETATTRコマンドを受信すると(S31)、ルートディレクトリの属性情報を読出して、新NAS100に送信する(S32)。
新NAS100は、旧NAS200からルートディレクトリの属性情報を受信すると(S33)、この属性情報をルートディレクトリのiノード情報として、iノード情報管理テーブルT13に登録する。ルートディレクトリの属性情報としては、例えば、「所有者」等を挙げることができる。以上の処理により、LU202のルートディレクトリ直下に位置する構造と同一の構造が、新NAS100のLU102に形成される。
図13は、ルートディレクトリ直下のディレクトリの構造をコピーする場合の処理を示すフローチャートである。この処理は、図12で述べた処理とほぼ同様に行われる。まず最初に、新NAS100は、ディレクトリ「usr」についてのlsコマンドを、旧NAS200に発行する(S41)。旧NAS200は、新NAS100からlsコマンドを受信すると(S42)、ディレクトリ「usr」に含まれるファイルの一覧(dir1,dir2)を新NAS100に送信する(S43)。
新NAS100は、旧NAS200からリスト応答を受信すると(S44)、サブディレクトリ「dir1」にiノード番号「6」を割り当て(S45)、また、サブディレクトリ「dir2」にiノード番号「7」を割り当てる(S46)。そして、新NAS100は、ディレクトリ「usr」のデータ内容として、「dir1,6,dir2,7」を記憶する(S47)。
さらに、新NAS100は、ディレクトリ「usr」のiノード情報として、「dir1,6,dir2,7」の格納先アドレスAdr12とファイルサイズとをiノード情報管理テーブルT13に記憶させる(S48)。次に、新NAS100は、旧NAS200に対し、「usr」に関するLOOKUPコマンドを発行する(S49)。ここで、LOOKUPコマンドとは、ファイルディスクリプタを取得するためのコマンドである。
旧NAS200は、新NAS100からLOOKUPコマンドを受信すると(S50)、ディレクトリ「usr」に関連付けられているファイルディスクリプタ(旧fd(usr))を、新NAS100に送信する(S51)。
但し、新NAS100上で、これ以前に行われている「ls」コマンドの結果より、旧fd(usr)の情報を得ることができる場合は、これらの手順は省略されてもよい。以下、本明細書において、新NAS100上でLOOKUPコマンドを発行する手順は、それ以前に実行されている「ls」コマンドの結果より特定ディレクトリの旧fdの情報を得られる場合には、省略することができる。
但し、新NAS100上で、これ以前に行われている「ls」コマンドの結果より、旧fd(usr)の情報を得ることができる場合は、これらの手順は省略されてもよい。以下、本明細書において、新NAS100上でLOOKUPコマンドを発行する手順は、それ以前に実行されている「ls」コマンドの結果より特定ディレクトリの旧fdの情報を得られる場合には、省略することができる。
新NAS100は、旧NAS200から「usr」のファイルディスクリプタを受信すると(S52)、このファイルディスクリプタを用いて、ディレクトリ「usr」についてのGETATTRコマンドを発行する(S53)。
旧NAS200は、新NAS100からGETATTRコマンドを受信すると(S54)、「usr」の属性情報を読出して、新NAS100に送信する(S55)。
新NAS100は、旧NAS200からディレクトリ「usr」の属性情報を取得すると(S56)、この属性情報をiノード情報管理テーブルT13の「usr」の欄に登録する(S57)。以上のようにして、ルートディレクトリ直下に属する各ディレクトリ「usr」、「bin」、「etc」の内容を旧NAS200からそれぞれ取得し、新NAS100のiノード情報管理テーブルT13に登録することができる。各サブディレクトリ「dir1」、「dir2」を登録する場合も、図13で示したと同様の方法で行われる。iノード情報管理テーブルT13にiノード情報が登録されることにより、旧NAS200のファイルツリー構造が新NAS100に移行される。
図14は、サブディレクトリ「dir1」に格納されているファイル「file1.txt」のiノード情報をiノード情報管理テーブルT13に登録する場合のフローチャートである。このフローチャートでは、ファイルのiノード情報のみが新NAS100側に生成され、ファイルの実体(ファイルデータ)は新NAS100に移行されない。後述のように、ファイルデータの移行は、各クライアント10,11からのアクセス要求が生じた場合に、実行される。
まず、新NAS100は、ファイル「/usr/dir1/file1.txt」についてlsコマンドを発行する(S61)。つまり、ファイル「file1.txt」に属する要素(ファイルやディレクトリ)について、新NAS100は旧NAS200に問い合わせる。
旧NAS200は、新NAS100からのlsコマンドを受信すると(S62)、ファイル「file1.txt」の配下には何も存在しない旨を応答する(S63)。ファイル「file1.txt」は、ファイルツリーの末端の一つであり、それより下に他のファイル等は存在しないためである。
新NAS100は、旧NAS200からの応答を受信すると(S64)、ファイル「file1.txt」についてLOOKUPコマンドを発行する(S65)。旧NAS200は、LOOKUPコマンドを受信すると(S66)、ファイル「file1.txt」の旧fd(file1.txt)を新NAS100に送信する(S67)。
新NAS100は、旧fd(file1.txt)を受信すると(S68)、このfd(file1.txt)を用いて、ファイル「file1.txt」についてのGETATTRコマンドを発行する(S69)。旧NAS200は、新NAS100からGETATTRコマンドを受信すると(S70)、ファイル「file1.txt」に関する属性情報を読出して、新NAS100に送信する(S71)。
新NAS100は、ファイル「file1.txt」についての属性情報を受信すると(S72)、この属性情報を、ファイル「file1.txt」のiノード情報として、iノード情報管理テーブルT13に登録する(S73)。
そして、新NAS100は、ファイル「file1.txt」に対応付けられている未更新フラグを「1」に設定する(S74)。ファイルデータの実体が新NAS100にコピーされていない場合は、「未移行状態」であるので、未更新フラグに「1」が設定される。
図12〜図14で述べた通り、最初に、旧NAS200のファイルツリーと同一構造のファイルツリーが新NAS100に形成される。この段階では、各ファイルの実体は、新NAS100にコピーされず、旧NAS200にのみ存在する。
図15は、各クライアント10,11が新NAS100から新fdを取得する際の処理概要を示すフローチャートである。なお、クライアント10またはクライアント11による動作を特に区別する必要がないので、「クライアント10,11」と表現する。
処理概要を先に述べると、クライアント10,11がファイルまたはディレクトリにアクセスする際には、LOOKUPコマンドを用いて、アクセス対象となるファイルの新fdを新NAS100から取得し、次に、この新fdを用いて更新要求(ライトアクセス)または参照要求(リードアクセス)等を発行する。もしも、アクセス対象のファイルが深い階層に位置する場合は、クライアント10,11は、取得できた最も最下位のディレクトリのfdを用いて、LOOKUPコマンドを発行する。クライアント10,11は、例えば、現在判明している最も下位のパスに対応するfdと、この最も下位のパスに属するディレクトリまたはファイル名とを指定しながら、目的とするファイルまでディレクトリ階層構造を順番に辿り、目的のファイルの新fdを新NAS100から入手する。
図15に戻る。まず最初に、クライアント10,11は、新NAS100に対して、ディレクトリのファイルディスクリプタとそのディレクトリに属する所望のファイル名とを指定して、LOOKUPコマンドを発行する(S101)。図15では、目的のファイルが格納されているディレクトリの新fdを、クライアント10,11が入手しているものとして説明する。目的のファイルが格納されているディレクトリ等のfdが不明の場合は、上述のように、クライアント10,11は、新NAS100のファイルツリー103をルートディレクトリから下位ディレクトリに向けて順番に辿りながら、そのファイルが直接属するディレクトリの新fdを入手する。
新NAS100は、クライアント10,11からのLOOKUPコマンドを受信すると(S102)、iノード情報管理テーブルT13を参照し(S103)、要求されたファイルがファイルツリー上に存在するか否かを判定する(S104)。
クライアント10,11から照会されたファイルが実在しない場合(S104:NO)、新NAS100は、存在しないファイルである旨をクライアント10,11に回答する(S105)。
クライアントから照会されたファイルが新NAS100のファイルツリー103上に実在する場合(S104:YES)、新NAS100は、この要求されたファイルについて新たにファイルディスクリプタを生成する(S106)。新NAS100は、生成した新fdをfd−iノード変換テーブルT11に登録する(S107)。即ち、照会された(要求された)ファイルのiノード番号とこのファイルについて生成された新fdとを対応付けて、fd−iノード変換テーブルT11に登録する。
次に、新NAS100は、要求されたファイルに関連付けられている未更新フラグを確認し(S108)、fd−fd変換テーブルT12を参照する(S109)。新NAS100は、クライアント10,11から受信したディレクトリに関する旧fdが、fd−fd変換テーブルT12に登録されているか否かを判定する(S110)。
新NAS100の運用開始当初は、旧fdと新fdとの対応関係が把握されていないので、要求されたファイルが属するディレクトリの旧fdがfd−fd変換テーブルT12に登録されていないと判断される(S110:NO)。
そこで、新NAS100は、ディレクトリの旧fd及びファイル名を引数として、旧NAS200にLOOKUPコマンドを発行する(S111)。即ち、S102において新NAS100がクライアント10,11から受信したLOOKUPコマンドと同様のLOOKUPコマンドを、新NAS100は旧NAS200に送信する。
旧NAS200は、新NAS100からLOOKUPコマンドを受信すると(S112)、新NAS100から要求されたファイルの旧fdを読出して、新NAS100に回答する(S113)。
新NAS100は、旧NAS200からファイルの旧fdを受信すると(S114)、この旧fdとS106で発行した新fdとを対応付けて、fd−fd変換テーブルT12に登録する(S115)。そして、新NAS100は、S106で新たに生成した新fdを、クライアント10,11に通知する(S116)。
クライアント10,11は、新NAS100からファイルの新fdを受信すると(S117)、この新fdをキャッシュメモリ等に記憶する(S118)。以後、クライアント10,11は、このファイルにアクセスする場合に、キャッシュした新fdを指定してファイルアクセスを要求する。なお、クライアント10,11から指定されたディレクトリの旧fdがfd−fd変換テーブルT12に登録済である場合(S110:YES)、S111,S114,S115の処理はスキップされる。
このように、クライアント10,11から新NAS100に対して、ファイルディスクリプタの取得要求が行われた場合、新NAS100は、新fdを生成して、クライアント10,11に通知する。また、新NAS100は、旧NAS200から旧fdを取得し、この旧fdと新fdとを対応付けて保持する。これにより、図16,図17と共に述べるように、新NAS100に移行されていないファイルへのアクセス要求が発生した場合に、新fdを旧fdに変換して、旧NAS200からファイルを取得することができる。なお、この例では、クライアント10,11からのアクセスに応じて、旧fdを旧NAS200から取得する場合を述べたが、既に述べたように、本発明はこれに限定されず、ファイルツリー構造をコピーする際に旧fdとiノード番号とを対応付けて、旧fdと新fdとの対応関係を間接的に構築することもできる。これについては、さらに後述する。
図16は、クライアント10,11からの更新要求(WRITEコマンド)を処理する場合の概略フローチャートである。まず、クライアント10,11は、更新を希望するファイルの新fdを指定して、WRITEコマンドを発行する(S121)。クライアント10,11は、図15で述べた処理により、所望のファイルの新fdを新NAS100から取得している。
新NAS100は、クライアント10,11からWRITEコマンドを受信すると(S122)、fd−iノード変換テーブルT11を参照し(S123)、クライアント10,11から要求されたファイルが実在するか否かを判定する(S124)。
クライアント10,11から更新を要求されたファイルが実在しない場合(S124:NO)、新NAS100は、要求されたファイルが存在しない旨をクライアント10,11に回答する(S125)。
クライアント10,11から更新を要求されたファイルが実在する場合(S124:YES)、新NAS100は、fd−iノード変換テーブルT11に基づいて、クライアント10,11から指定された新fdをiノード番号に変換する(S126)。次に、新NAS100は、iノード番号に基づいてiノード情報管理テーブルT13を参照し、更新を要求されたファイルに対応付けられている未更新フラグを確認する(S127)。
新NAS100は、未更新フラグの内容に基づいて、更新を要求されたファイルが新NAS100に未移行であるか否かを判定する(S128)。即ち、更新を要求されたファイルの未移行フラグに「1」が設定されているか否かを判定する。更新を要求されたファイルが既に新NAS100にコピー済の場合(S128:NO)、新NAS100は、対象のファイルをLU102からメモリ上に読出して、その一部または全部を更新し、再びLU102に書き戻す(S129)。
更新を要求されたファイルが新NAS100に未だ移行されていない場合(S128:YES)、新NAS100は、fd−fd変換テーブルT12を参照する(S130)。これにより、新NAS100は、クライアント10,11から指定された新fdを、対応する旧fdに変換する(S131)。即ち、新NAS100は、更新を要求されたファイルの旧fdをfd−fd変換テーブルT12から取得する。
そして、新NAS100は、ファイルの旧fdを指定して、旧NAS200に対し、READ命令を発行する(S132)。旧NAS200は、新NAS100からREAD命令を受信すると(S133)、新NAS100から要求されたファイルの全データをLU202から読出して、新NAS100に送信する(S134)。つまり、新NAS100は、クライアント10,11がファイルの一部についてのみ更新を要求している場合でも、そのファイルの全体を旧NAS200から取得する。
新NAS100は、旧NAS200からファイルの全データを受信すると、この受信したファイルデータの一部または全部を書き換えて更新し、LU102の所定の場所に格納させる(S135)。即ち、新NAS100は、クライアント10,11からの更新要求に従ってファイルを更新し、このファイルのデータが格納されるべき位置にファイルを保存させる。ファイルデータが格納されるべき位置は、ファイルツリー構造の移行処理を完了した時点で既に決定されている。更新されたファイルデータは、新NAS100内で、所定のディレクトリに保存される。
新NAS100は、ファイルの更新を完了した後で、この更新したファイルに対応付けられている未更新フラグを「0」に設定する(S136)。これにより、このファイルの移行状態は、「未移行状態」から「移行済状態」に変更される。
新NAS100は、ファイルの更新を完了した後、クライアント10,11に対し、ファイルの更新が完了した旨を報告する(S137)。クライアント10,11は、新NAS100からの通知を受信し、WRITEコマンドの処理完了を知る(S138)。
このように、本実施形態では、クライアント10,11からファイルの更新を要求される度に、要求されたファイルが旧NAS200から新NAS100にコピーされる。従って、最初の更新要求の場合は、旧NAS200からファイルを取得する分だけ、更新要求に対する応答が低下する。しかし、新NAS100に移行した後は、そのファイルに対する更新要求を直ちに処理することができる。
図17は、クライアント10,11からの参照要求(READコマンド)を処理する場合の概略フローチャートである。まず、クライアント10,11は、参照を希望するファイルの新fdを指定して、READコマンドを発行する(S141)。新NAS100は、READコマンドを受信すると(S142)、fd−iノード変換テーブルT11を参照し(S143)、参照を要求されたファイルが実在するか否かを判定する(S144)。クライアント10,11から参照を要求されたファイルがファイルツリー103上に存在しない場合(S144:NO)、新NAS100は、クライアント10,11に対して、要求されたファイルが存在しない旨を回答する(S145)。
参照を要求されたファイルがファイルツリー上に存在する場合(S144:YES)、新NAS100は、fd−iノード変換テーブルT11に基づいて、そのファイルのiノード番号を取得する(S146)。新NAS100は、iノード番号に基づいて、iノード情報管理テーブルT13を参照し、参照を要求されたファイルに対応付けられている未更新フラグを確認する(S147)。
新NAS100は、未更新フラグに基づいて、参照を要求されたファイルが未移行状態であるか否かを判定する(S148)。参照を要求されたファイルが既に新NAS100に移行済の場合(S148:NO)、新NAS100は、要求されたファイルをLU102から読み出す(S149)。
参照を要求されたファイルが新NAS100に未だ移行されていない場合(S148:YES)、新NAS100は、fd−fd変換テーブルT12を参照し(S150)、クライアント10,11から指定された新fdを旧fdに変換する(S151)。
そして、新NAS100は、旧fdを指定して旧NAS200にREADコマンドを発行する(S152)。旧NAS200は、新NAS100からのREADコマンドを受信すると(S153)、新NAS100から要求されたファイルの全データをLU202から読出して、新NAS100に送信する(S154)。
新NAS100は、旧NAS200からファイルの全データを受信すると、このデータを更新し、所定の場所に記憶させる(S155)。即ち、新NAS100は、旧NAS200から取得したファイルデータを、LU102に形成されるファイルツリー103の所定の格納位置に保存する。更新要求の場合と同様に、新NAS100は、クライアント10,11からファイルの一部についてのみ参照を要求された場合でも、そのファイルの全体を旧NAS200から取得し、LU102の所定の場所に格納する。これにより、そのファイルは旧NAS200から新NAS100に移行されたことになる。
新NAS100は、そのファイルに対応付けられている未更新フラグを「0」に設定し、「未移行状態」から「移行済状態」に変更する(S156)。そして、新NAS100は、クライアント10,11に対し、参照を要求されたファイルデータの一部または全部を送信し、READコマンドの処理完了を通知する(S157)。クライアント10,11は、新NAS100からファイルのデータを受信し、また、READコマンドの処理完了を確認する(S158)。
このように、本実施形態では、更新要求の処理で述べたと同様に、クライアント10,11から参照を要求される度に、要求されたファイルが旧NAS200から新NAS100にコピーされる。従って、最初の参照要求の場合は、旧NAS200からファイルを取得する分だけ、参照要求に対する応答が低下する。しかし、新NAS100に移行した後は、そのファイルに対する参照要求を直ちに処理できる。
本実施例は上述のように構成されるので、以下の効果を奏する。本実施例では、まず最初に、旧NAS200が有するファイルツリー203と同一構造のファイルツリーを新NAS100に生成した時点でNASサービスを再開し、次に、クライアント10,11から新NAS100へのファイルアクセス要求に基づいて、要求されたファイルを旧NAS200から新NAS100に段階的に移行させる構成とした。従って、NASサービスの停止時間を短くして、旧NAS200から新NAS100へ移行させることができ、NASの置換を容易に行うことができる。
また、本実施例では、新NAS100において、新fdと旧fdとの対応付け等を行う構成とした。従って、旧NAS200に何ら特別な機能を追加することなく、新NAS100のみでネットワークストレージの移行(置換)を行うことができる。
さらに、本実施例では、旧NAS200の記憶するファイルデータを一切変更することなく、移行前の記憶内容を保持した状態で、旧NAS200から新NAS100にファイルデータを移行させる構成とした。即ち、例えば、図16と共に述べた更新要求処理では、ファイルデータの更新は、新NAS100側でのみ行われ、旧NAS200の記憶内容に変化は生じない。旧NAS200から新NAS100へ移行する際に、新NAS100は、旧NAS200に対して参照要求のみを行うようになっている。従って、移行前のデータ(旧NAS200が保持するファイル群)を破壊することなく、旧NAS200から新NAS100への移行処理(置換処理)を行うことができる。従って、不測の事態に備えて、移行開始前に旧NAS200の記憶内容を予めバックアップしておく必要がなく、旧NAS200から新NAS100への置換作業を比較的簡単に行うことができる。
また、本実施例では、クライアント10,11から旧fdを指定してファイルアクセスが要求された場合に、この要求されたファイルに対応する新たなfdを新NAS100から発行させると共に、旧fdと新fdとの対応関係を新NAS100内で保持する構成とした。そして、クライアント10,11からのファイルアクセス要求が発生した場合に、対象のファイルを旧NAS200から新NAS100に移行させる構成とした。従って、クライアント10,11は、新fdを指定して新NAS100にアクセスするだけで、所望のファイルにアクセスすることができ、また、そのファイルアクセスによって、所望のファイルを旧NAS200から新NAS100に移行させることができる。
また、本実施例では、クライアント10,11から旧ファイルツリーへのアクセス要求に応じて、旧fdと新fdとの対応関係を徐々に構築する構成とした。従って、クライアント10,11が必要とする範囲内でファイル群の移行準備を整えることができる。
図18〜図19に基づいて、第2実施例を説明する。本実施例の特徴は、旧NAS200から新NAS100へファイルツリー構造を移行する際に、旧fdと新fdとの対応関係の構築を開始する点にある。
図18は、本実施例の全体動作の手順を示す概略フローチャートである。図10に示す全体動作と、P23,P28の点で相違する。P21,P22は図10中のP1,P2に、P24〜P27は図10中のP3〜P7に、P29〜P31は図10中のP9〜P11に、それぞれ対応するので重複した説明を割愛する。
P23では、ファイルツリー構造を旧NAS200から新NAS100にコピーする際に、旧NAS200で管理される旧fdと新NAS100で管理されるiノード番号とを対応付けて保存する。そして、P28では、クライアント10,11がファイルツリーを上位ディレクトリから下位ディレクトリに向けて順番に辿る過程で発行される新fdとiノード番号とを対応付ける。これにより、旧fdと新fdとはiノード番号を介して関連付けられる。
図19及び図20を参照して、より詳細に説明する。まず最初に、図19のフローチャートは、旧NAS200から新NAS100へファイルツリー構造を移行する際の処理の一部であり、図13に示すフローチャートに対応する。即ち、図13中のS41〜S52は、図19中のS161〜S172にそれぞれ対応する。同様に、図13中のS54〜S57は、図19中のS175〜S178にそれぞれ対応する。対応する各ステップの説明は省略する。
図20のフローチャートは、図19と同様のファイルツリー構造移行処理の一部であり、図14に示すフローチャートに対応する。即ち、図14中のS61〜S68は、図20中のS181〜S188にそれぞれ対応する。同様に、図14中のS69〜S74は、図20中のS190〜S195にそれぞれ対応する。なお、対応する各ステップの説明は省略する。説明の便宜のため、ディレクトリ「usr」及びファイル「fie1.txt」の移行を例示するが、これ以外のディレクトリやファイルの場合も同様に処理される。
本実施例に特徴的なステップであるS173,S189では、旧NAS200から取得した旧fdを、新NAS100におけるiノード番号に対応付けて、保持する。つまり、図9(c)と共に述べたように、fd−iノード変換テーブルとfd−fd変換テーブルとを統合して扱うことができるが、新NAS100におけるiノード番号に、そのiノード番号に対応する旧fdを予め対応付けて保持しておく。そして、クライアント10,11からの要求に応じて新fdが発行された場合に、この新fdと予め保持しておいた旧fdとを対応付けて記憶する。
図21,図22に基づいて、第3実施例を説明する。本実施例の特徴は、クライアントからのファイルアクセスに応じて、旧NAS200から新NAS100にファイルツリー構造をコピーさせると共に、旧fdと新fdとの対応関係を構築する点にある。即ち、本実施例では、クライアント10,11が稼働状態の場合に旧NAS200から新NAS100への移行を可能としている。
図21は、本実施例による全体処理の概要を示すフローチャートである。まず、新NAS100は、旧NAS200のネットワーク設定情報を継承し(S201)、旧NAS200は、クライアント10,11へのサービス提供を停止する(S202)。そして、システム管理者は、旧NAS200と新NAS100とを直接的に接続し(S203)、旧NAS200から新NAS100にNASサービスを提供させる(S204)。
新NAS100は、旧NAS200のルートディレクトリと新NAS100のルートディレクトリとを対応付ける(S205)。そして、新NAS100は、クライアント10,11へのサービス提供を開始し、クライアント10,11からのファイルアクセス要求に応じて、要求された範囲内でファイルツリー構造をコピーすると共に、ファイルのデータを移行させる。即ち、本実施例では、クライアント10,11からのアクセスに同期して、新NAS100は旧NAS200にアクセスし、必要なデータや属性等を入手する。
図22は、クライアント10,11から新NAS100へのアクセス動作と、新NAS100から旧NAS200へのアクセス動作とが同期している様子を部分的に示すフローチャートである。
まず、新NAS100は、新NAS100のルートディレクトリの新fdと旧NAS200のルートディレクトリの旧fdとを対応付けておく(S211)。クライアントの稼働中に、旧NAS200から新NAS100に入れ替わっているため、クライアントは、旧fdを用いてファイルへのアクセスを要求する(S212)。
新NAS100は、旧fdを解釈することができないため、このファイルアクセス要求をリジェクトし、クライアントにリトライアクセスを要求する(S213)。新NAS100からの通知を受けたクライアントは、ルートディレクトリから目的のファイルに向けて、ファイルツリーを順番に辿っていく。
クライアントは、新NAS100に対し、ルートディレクトリについてlsコマンドを発行する(S214)。新NAS100は、クライアントからの要求に同期して、ルートディレクトリに関するlsコマンドを旧NAS200に送信する(S215)。
旧NAS200は、新NAS100からコマンドを受信すると、ルートディレクトリ直下の構成について、新NAS100に応答する(S216)。新NAS100は、旧NAS200からの応答に基づいて、この応答内容に含まれる範囲内でファイルツリーを形成する(iノード情報管理テーブルを更新する)(S217)。そして、新NAS100は、自身のファイルツリー103のルートディレクトリ直下の構成について、クライアントに応答する(S217)。ここで、留意すべきは、新NAS100は、旧NAS200からの応答内容をそのままクライアントに転送するのではなく、旧NAS200からの応答内容に基づいて更新された新NAS100のツリー構成について応答している点である。
次に、クライアントは、ルートディレクトリ下にある”usr”ディレクトリに関して、新NAS100に問い合わせる(S218)。この問合せを受けた新NAS100は、旧NAS200に、”usr”ディレクトリ下の構成を問い合わせる(S219)。旧NAS200が”usr”ディレクトリ下の構成について応答すると(S220)、新NAS100は、ファイルツリー103をさらに構築し、iノード情報を更新する(S221)。また、新NAS100は、更新した情報に基づいて、”usr”ディレクトリ下の構成についてクライアントに応答する(S221)。
クライアントは、”usr”ディレクトリのfdを要求する(S222)。新NAS100は、このクライアントからのfd要求に同期して、”usr”の旧fdを旧NAS200に要求する(S223)。旧NAS200が”usr”の旧fdを新NAS100に通知すると(S224)、新NAS100は、”usr”の新fdを生成すると共に、この新fdと旧fdとを対応付けて保存する(S225)。そして、新NAS100は、”usr”の新fdをクライアントに通知する(S225)。
クライアントは、新fd”usr”を指定し、”usr”ディレクトリの属性情報の取得を新NAS100に要求する(S226)。新NAS100は、クライアントからの要求を受信すると、旧NAS200に”usr”の属性情報を要求する(S227)。この属性情報の要求に際して、新fd”usr”は旧fd”usr”に変換される。
旧NAS200は、新NAS100からの要求に応じて、”usr”の属性情報を読出し、新NAS100に送信する(S228)。新NAS100は、旧NAS200から受信した属性情報に基づいて、iノード情報を更新する(S229)。そして、新NAS100は、この更新された”usr”の属性情報をクライアントに送信する(S229)。
続いて、クライアントは、”usr”ディレクトリ下に存在する”dir1”ディレクトリについて、新NAS100に問い合わせる(S230)。新NAS100は、クライアントからの問合せ要求を受信すると、旧NAS200に対し、”dir1”ディレクトリ下の構成を問い合わせる(S231)。
旧NAS200は、新NAS100からの問合せに応じて、”dir1”ディレクトリ下の構成を応答する(S232)。新NAS100は、旧NAS200からの応答内容に基づいて、iノード情報を更新し、ファイルツリーを構築する(S233)。
以上の処理は、クライアントが目的のファイルを発見するまで繰り返される。クライアントがファイルに到達すると、新NAS100は旧NAS200からファイルのデータや属性を読出し、これらの情報を記憶すると共に、クライアントに提供する。
このように、クライアントがファイルツリーを上位ディレクトリから下位に向けて順番に辿っていく過程に同期して、新NAS100は、旧NAS200のファイルツリーを上位ディレクトリから下位に向けて順番に辿る。そして、新NAS100は、このファイルツリーを辿る過程で、旧fdと新fdとの対応関係を構築し保持する。従って、本実施例では、クライアントが稼働中の状態において、クライアントから要求された範囲内で、ファイルツリーをコピーすると共に、旧fdと新fdとの対応付けを行うことができる。
クライアントからの要求に同期してファイルツリーのコピー等を行うため、新NAS100の負荷は増大する。しかし、クライアントが特定のファイルまたはファイル群にアクセスするような場合、その使用されるファイルまたはファイル群について、先行してデータ移行を完了させることができる。
図23に基づいて、第4実施例を説明する。本実施例は、クライアントが新NAS100のファイルツリー103を上位ディレクトリから下位に向けて順番に辿る場合の詳細を示す。
クライアントがファイルへのアクセスを行う場合、所望のファイルを特定するための新fdを入手済みであるか否かを判定する(S241)。既に入手済みの場合(S241:YES)、図16や図17で述べたように、所望のファイルの新fdを指定して、ライトアクセスやリードアクセスを行うことができる(S242)。
これに対し、所望のファイルの新fdを未入手の場合(S241:NO)、クライアントは、現在判明している最も下位のパスの新fdと、そのパスの下にあるディレクトリ名とを指定して、LOOKUPコマンドを発行する(S243)。最初の時点では、ルートディレクトリの新fdのみが判明しているので、クライアントは、ルートディレクトリの新fd及びルートディレクトリ下にあるディレクトリ名”usr”を指定して、新NAS100に問い合わせる。
新NAS100は、ルートディレクトリの新fdを旧fdに変換し(S244)、ルートディレクトリの旧fdとディレクトリ名”usr”とを指定して、旧NAS200に問い合わせる(S245)。
旧NAS200は、新NAS100からの問合せに応じて、”usr”ディレクトリの旧fdを通知する(S246)。新NAS100は、”usr”ディレクトリの旧fdを用いて、READDIRコマンドを発行する(S247)。
旧NAS200は、READDIRコマンドを受信すると、”usr”ディレクトリ下の構成を応答する(S248)。新NAS100は、旧NAS200からの応答に基づいて、iノード情報を更新する(S249)。また、新NAS100は、”usr”ディレクトリについて、属性情報の取得を要求する(S251)。旧NAS200は、属性情報の取得要求に応じて、”usr”ディレクトリの属性情報を新NAS100に送信する(S252)。
新NAS100は、旧NAS200からの応答内容に基づいてiノード情報を更新し(S253)、”usr”ディレクトリを特定するための新fdを生成する(S254)。そして、新NAS100は、この新fdと旧fdとを対応付けて保存した後(S255)、”usr”ディレクトリの新fdをクライアントに通知する(S256)。
新fdを受領したクライアントは、”usr”ディレクトリの新fd及び”usr”ディレクトリ下にあるディレクトリ名(”dir1”)とを指定し、再びLOOKUPコマンドを送信する(S243)。以上の処理を、目的のファイルの新fdを入手するまで繰り返し、目的のファイルの新fdを入手した場合は、S242に移る。
次に、図24は、第5実施例に係わるファイル更新処理の概略を示すフローチャートである。図24に示すフローチャートは、図17中のS155の変形例に相当する。本実施例の特徴は、ファイルの利用頻度を考慮して、旧NAS200から新NAS100への移行を制御するようにした点にある。
図17に示す例では、クライアント10,11からファイル参照要求があった場合に、要求されたファイルの全データを旧NAS200から新NAS100にコピーし、新NAS100内で更新記憶させる構成とした。
これに対し、図24に示すファイル更新処理では、新NAS100は、旧NAS200からファイルの全データを取得した後(S261)、この取得したファイルの更新時刻を確認する(S262)。そして、新NAS100は、ファイルの更新時刻に基づいて、そのファイルを更新記憶するか否か、即ち、そのファイルを新NAS100のLU102に保持させるか否かを判定する(S263)。旧NAS200から取得したファイルを更新記憶させる場合(S263:YES)、新NAS100は、取得したファイルの全体をLU102に記憶させる(S264)。
ここで、ファイルの更新時刻に基づいてファイルの更新記憶(新NASへの移行)を行うか否かを判定する条件としては、場合に応じて種々のものを採用可能である。例えば、クライアント10,11から参照を要求されたファイルの更新時刻が、3年前や5年前等のように、所定時間更新されていないような場合は、旧NAS200から新NAS100への移行を行わないように構成できる。従って、所定時間以上更新されず、専ら参照のみされるファイルは、参照要求が発生する度に、旧NAS200から毎回読み出されて、クライアント10,11に提供される。
このように、ファイルの利用頻度が低い場合は、そのファイルを旧NAS200に残しておく。これにより、利用頻度の低いファイルが新NAS100にコピーされるのを未然に防止し、新NAS100の記憶資源(LU102)を効率的に使用できる。この結果、旧NAS200から新NAS100への移行に伴って、不要なファイルを自然に淘汰することができ、ユーザ使用量の割当て管理(QUOTA)等を適切に行うことができる。
なお、クライアント10,11がそのファイルを必要とする場合は、参照要求ではなく、更新要求を発行すればよい。クライアント10,11がファイルの更新を要求することにより、そのファイルは新NAS100にコピーされる。
図25は、第6実施例に係るファイル更新処理を示す。本実施例の特徴は、ファイルの利用頻度を測る指標として、そのファイルを利用する共有ホスト数(クライアント数)を考慮する点にある。
このファイル更新処理では、新NAS100は、旧NAS200からファイルの全データを取得した後(S271)、この取得したファイルを利用している共有ホスト数を確認する(S272)。そして、新NAS100は、共有ホスト数に基づいて、そのファイルを更新記憶するか否か、即ち、そのファイルを新NAS100のLU102に保持させるか否かを判定する(S273)。旧NAS200から取得したファイルを更新記憶させる場合(S273:YES)、新NAS100は、取得したファイルの全体をLU102に記憶させる(S274)。
例えば、そのファイルを共有するクライアントの数が予め設定された所定値よりも少ない場合には、そのファイルを新NAS100へコピーしないようにすることができる。
なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、各実施例を適宜組み合わせることができる。
例えば、ファイル識別情報としてファイルディスクリプタを例に挙げたが、これに限らず、ファイルハンドル等の他の識別情報を用いてもよい。また、上記実施形態では、主としてNFSの場合を説明したが、本発明はCIFS等の場合でも適用可能である。CIFSの場合は、iノードの代わりに、iノードの集合体に相当するMFT(Master File Table)を用いることができる。MFTは、ファイルの実位置を特定するためのマップである。
また、ファイルの利用頻度を測る指標として、最終更新時刻からの経過時間や共有ホスト数を例示したが、これに限らず、単位時間当たりのアクセス数等を用いてもよく、あるいは、更新時刻からの経過時間、共有ホスト数、単位時間当たりのアクセス数等のような複数の指標を適宜組み合わせてもよい。
なお、新NAS上に形成されるfd−fd変換テーブルは、旧NASから新NASにファイルのデータまで完全に移行した場合、不要となる。即ち、旧NASから新NASにファイル群が完全に移行した場合は、fd−fd変換テーブルを削除することができる。不要なfd−fd変換テーブルを削除することにより、オーバーヘッドを解消し、性能劣化を防止することができる。
10,11…クライアント、12…通信インターフェース、20…ネットワークストレージ、30…制御部、31…CPU、32…RAM、33…ROM、34〜36…通信インターフェース、40…記憶部、41…記憶デバイス、51…ネットワークプロトコル層、52,53…ファイルアクセスプロトコル層、54…ファイルシステム、55…論理ボリュームマネージャ、56…デバイスドライバ群、57…論理ボリューム、100…新NAS、101…ファイルシステム、102…論理ボリューム(移行先ボリューム)、103…ファイルツリー、110…管理部、111…fd−iノード変換部、112…fd−fd変換部、113…iノード情報管理部、120…ファイルツリー生成部、130…アクセス要求処理部、131…旧fd取得部、132…新fd発行部、133…移行状態判定部、134…ファイル移行部、200…旧NAS、201…ファイルシステム、202…論理ボリューム(移行元ボリューム)、CN…通信ネットワーク、fd…ファイルディスクリプタ、T11…fd−iノード変換テーブル、T12…fd−fd変換テーブル、T13…iノード情報管理テーブル
Claims (20)
- クライアントに提供するファイルを記憶する第1のネットワークストレージと、前記クライアント及び前記第1のネットワークストレージにそれぞれ接続される第2のネットワークストレージとを備えたネットワークストレージシステムであって、
前記第1のネットワークストレージが有する第1のファイルツリーと同一構造の第2のファイルツリーを、ファイルシステムのディレクトリ階層構造として、前記第2のネットワークストレージ上に生成させるファイルツリー生成部と、
前記第1のネットワークストレージ上のファイルへアクセスするべく前記クライアントから前記第2のネットワークストレージに対して要求されたアクセス要求に基づいて、前記クライアントから要求されたファイルを前記第1のネットワークストレージ上で特定するファイル特定部と、
前記特定されたファイルの属性及びデータを前記第1のネットワークストレージから取得し、この取得したファイルを前記第2のファイルツリーの所定の場所に格納させるファイル移行部と、
を備えたネットワークストレージシステム。 - 前記第1のネットワークストレージのネットワーク設定情報を前記第2のネットワークストレージに継承させ、前記第2のネットワークストレージが前記第1のネットワークストレージに成り代わって前記クライアントにファイル共有サービスを提供するための通信部を備えた請求項1に記載のネットワークストレージシステム。
- 前記ファイル移行部は、前記第1のネットワークストレージの記憶内容を変化させることなく、前記第1のネットワークストレージから前記ファイルを取得して、前記第2のファイルツリーの所定の場所に格納させる請求項1に記載のネットワークストレージシステム。
- 前記ファイル移行部は、前記クライアントからのアクセス要求が前記第1のネットワークストレージ上に存在するファイルの参照要求である場合に、前記ファイル特定部により前記第1のネットワークストレージ上で特定された前記ファイルの属性及びデータを前記第1のネットワークストレージから取得して前記クライアントに提供し、この取得したファイルを前記第2のファイルツリーの所定の場所に格納させる請求項1に記載のネットワークストレージシステム。
- 前記ファイル移行部は、前記第1のネットワークストレージから取得したファイルが所定の条件を満たす場合に、この取得したファイルを前記第2のファイルツリーの所定の場所に格納させる請求項4に記載のネットワークストレージシステム。
- 前記第1のネットワークストレージから取得されたファイルの利用頻度が所定値以上の場合は、前記所定条件が満たされたものと判定されて前記第2のファイルツリーの所定の場所に格納される請求項5に記載のネットワークストレージシステム。
- 前記ファイル移行部は、前記クライアントからのアクセス要求が前記第1のネットワークストレージ上に存在するファイルの更新要求である場合に、前記ファイル特定部により前記第1のネットワークストレージ上で特定された前記ファイルの属性及びデータを前記第1のネットワークストレージから取得し、この取得したファイルを更新して前記第2のファイルツリーの所定の場所に格納させる請求項1に記載のネットワークストレージシステム。
- 前記ファイル特定部は、前記第1のネットワークストレージ上でファイルを特定するための第1のファイル識別情報と前記第2のネットワークストレージ上で前記ファイルを特定するための第2のファイル識別情報とを対応付けて構成されるファイル特定用情報を参照することにより、前記クライアントから要求されたファイルを前記第1のネットワークストレージ上で特定する請求項1に記載のネットワークストレージシステム。
- 前記ファイル特定部は、前記クライアントから前記第1のネットワークストレージ上のファイルへのアクセス要求に基づいて、前記ファイル特定用情報を構築する請求項8に記載のネットワークストレージシステム。
- 前記ファイル特定部は、前記クライアントから前記第1のネットワークストレージ上のファイルへのアクセス要求に基づいて、前記第1のネットワークストレージから前記第1のファイル識別情報を取得し、この取得した第1のファイル識別情報と前記アクセス要求に関して生成された前記第2のファイル識別情報とを対応付けることにより、前記ファイル特定用情報を構築する請求項9に記載のネットワークストレージシステム。
- 前記ファイルツリー生成部は、前記第1のネットワークストレージ上のファイルが前記第2のファイルツリーの所定の場所に移行済みであるか否かを示す移行状態情報を前記第2のファイルツリーの構造に対応付けて、前記第2のファイルツリーを生成する請求項1に記載のネットワークストレージシステム。
- 前記ファイル特定部は、前記ファイルツリー生成部が前記第2のファイルツリーを生成する際に前記第1のネットワークストレージから取得する前記第1のファイル識別情報を前記ファイル特定用情報に予め格納しておき、前記クライアントからのアクセス要求を処理する度に前記第1のファイル識別情報に対応して生成される前記第2のファイル識別情報を、前記ファイル特定用情報に予め格納された前記第1のファイル識別情報に対応付けて、前記ファイル特定用情報に格納させる請求項8に記載のネットワークストレージシステム。
- 前記ファイルツリー生成部と前記ファイル特定部と前記ファイル移行部とを、前記第2のネットワークストレージ上に実現する請求項1に記載のネットワークストレージシステム。
- クライアントへのファイル共有サービスを複数のネットワークストレージ間で引き継がせるための方法であって、
前記第1のネットワークストレージのネットワーク設定情報を前記第2のネットワークストレージに継承させるステップと、
前記第1のネットワークストレージから前記クライアントに提供されるファイル共有サービスを停止させるステップと、
前記第1のネットワークストレージが有する第1のファイルツリーと同一構造の第2のファイルツリーを、ファイルシステムのディレクトリ階層構造として、前記第2のネットワークストレージ上に生成させるステップと、
前記第2のネットワークストレージから前記クライアントに提供されるファイル共有サービスを開始させるステップと、
前記クライアントから前記第2のネットワークストレージ上のファイルへのアクセス要求に基づいて、前記クライアントから要求されたファイルを前記第1のネットワークストレージ上で特定するステップと、
前記特定されたファイルの属性及びデータを前記第1のネットワークストレージから取得し、この取得したファイルを前記第2のファイルツリーの所定の場所に格納させるステップと、
を含んだ複数ネットワークストレージ間の引継方法。 - 前記第2のファイルツリーを生成するステップの前に、前記第1のネットワークストレージと前記第2のネットワークストレージとを双方向通信可能に接続させるステップを設けた請求項14に記載の複数ネットワークストレージ間の引継方法。
- 前記第1のネットワークストレージから取得したファイルを前記第2のファイルツリーの所定の場所に格納させるステップでは、前記第1のネットワークストレージの記憶内容を変化させることなく、前記第1のネットワークストレージから取得したファイルを前記第2のファイルツリーの所定場所に格納させる請求項14に記載の複数ネットワークストレージ間の引継方法。
- 前記第1のネットワークストレージから取得したファイルを前記第2のファイルツリーの所定の場所に格納させるステップでは、前記取得したファイルが所定の条件を満たす場合に、前記取得したファイルを前記第2のファイルツリーの所定の場所に格納させるようになっている請求項14に記載の複数ネットワークストレージ間の引継方法。
- 前記クライアントから要求されたファイルを前記第1のネットワークストレージ上で特定するステップは、前記第1のネットワークストレージ上でファイルを特定するための第1のファイル識別情報と前記第2のネットワークストレージ上で前記ファイルを特定するための第2のファイル識別情報とを対応付けて構成されるファイル特定用情報を参照することにより、前記クライアントから要求されたファイルを前記第1のネットワークストレージ上で特定する請求項14に記載の複数ネットワークストレージ間の引継方法。
- 前記ファイル特定用情報は、前記クライアントから前記第1のネットワークストレージ上のファイルへのアクセス要求がされる度に段階的に構築されるものである請求項18に記載の複数ネットワークストレージ間の引継方法。
- 前記第2のファイルツリーを前記第2のネットワークストレージに生成させるステップは、前記第1のネットワークストレージ上のファイルが前記第2のファイルツリーの所定の場所に移行済みであるか否かを示す移行状態情報を前記第2のファイルツリーの構造に対応付けながら、前記第2のファイルツリーを生成する請求項14に記載の複数ネットワークストレージ間の引継方法。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004217031A JP2006039814A (ja) | 2004-07-26 | 2004-07-26 | ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法 |
US10/944,787 US7313579B2 (en) | 2004-07-26 | 2004-09-21 | Network storage system and handover method between plurality of network storage devices |
EP05250543A EP1622048B1 (en) | 2004-07-26 | 2005-02-01 | Network storage system and handover method between a plurality of network storage devices |
DE602005020395T DE602005020395D1 (de) | 2004-07-26 | 2005-02-01 | Netzwerkspeicherungssystem und Weiterreichungsverfahren zwischen mehreren Netzwerkspeichervorrichtungen |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004217031A JP2006039814A (ja) | 2004-07-26 | 2004-07-26 | ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006039814A true JP2006039814A (ja) | 2006-02-09 |
Family
ID=34940419
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004217031A Pending JP2006039814A (ja) | 2004-07-26 | 2004-07-26 | ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US7313579B2 (ja) |
EP (1) | EP1622048B1 (ja) |
JP (1) | JP2006039814A (ja) |
DE (1) | DE602005020395D1 (ja) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007110931A1 (ja) * | 2006-03-28 | 2007-10-04 | Fujitsu Limited | 名前空間複製プログラム、名前空間複製装置、名前空間複製方法 |
JP2009288912A (ja) * | 2008-05-28 | 2009-12-10 | Hitachi Ltd | Nasシステムの移行方法、装置、プログラム、及びシステム |
JP2010211767A (ja) * | 2009-03-12 | 2010-09-24 | Fujitsu Ltd | アクセス制御装置、ストレージ装置、ネットワーク通信装置、アクセス制御方法、及びアクセス制御プログラム |
US7827193B2 (en) | 2006-11-27 | 2010-11-02 | Hitachi, Ltd. | File sharing system, file sharing device and file sharing volume migration method |
US8046392B2 (en) | 2007-04-27 | 2011-10-25 | Hitachi, Ltd. | Storage system and information transfer method for the same |
JP2016527618A (ja) * | 2013-07-02 | 2016-09-08 | ヒタチ データ システムズ エンジニアリング ユーケー リミテッドHitachi Data Systems Engineering Uk Limited | 仮想化されたファイル・システムのマイグレーションのための方法および装置、仮想化されたファイル・システムのマイグレーションのためのデータ・ストレージ・システム、ならびにデータ・ストレージ・システム内で使用するためのファイル・サーバ |
JP2021033852A (ja) * | 2019-08-28 | 2021-03-01 | 富士ゼロックス株式会社 | 情報処理装置、情報処理システム、及び情報処理プログラム |
US11792334B2 (en) | 2019-08-28 | 2023-10-17 | Fujifilm Business Innovation Corp. | System for efficiently migrating content data |
JP7363198B2 (ja) | 2019-08-28 | 2023-10-18 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置、情報処理システム、及び情報処理プログラム |
Families Citing this family (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7831641B2 (en) * | 2003-04-24 | 2010-11-09 | Neopath Networks, Inc. | Large file support for a network file server |
US7346664B2 (en) | 2003-04-24 | 2008-03-18 | Neopath Networks, Inc. | Transparent file migration using namespace replication |
US8539081B2 (en) | 2003-09-15 | 2013-09-17 | Neopath Networks, Inc. | Enabling proxy services using referral mechanisms |
US8195627B2 (en) | 2004-04-23 | 2012-06-05 | Neopath Networks, Inc. | Storage policy monitoring for a storage network |
US7720796B2 (en) * | 2004-04-23 | 2010-05-18 | Neopath Networks, Inc. | Directory and file mirroring for migration, snapshot, and replication |
US8190741B2 (en) | 2004-04-23 | 2012-05-29 | Neopath Networks, Inc. | Customizing a namespace in a decentralized storage environment |
US7516355B2 (en) * | 2004-11-05 | 2009-04-07 | Broadcom Corporation | Method and computer program product for backing up and restoring online system information |
US7516122B2 (en) * | 2004-12-02 | 2009-04-07 | Computer Associates Think, Inc. | System and method for implementing a management component that exposes attributes |
US7684566B2 (en) * | 2005-05-27 | 2010-03-23 | Microsoft Corporation | Encryption scheme for streamed multimedia content protected by rights management system |
US8832697B2 (en) | 2005-06-29 | 2014-09-09 | Cisco Technology, Inc. | Parallel filesystem traversal for transparent mirroring of directories and files |
US8321690B2 (en) | 2005-08-11 | 2012-11-27 | Microsoft Corporation | Protecting digital media of various content types |
US8131689B2 (en) | 2005-09-30 | 2012-03-06 | Panagiotis Tsirigotis | Accumulating access frequency and file attributes for supporting policy based storage management |
KR100736480B1 (ko) * | 2005-11-21 | 2007-07-06 | 엘지전자 주식회사 | 포터블 디바이스의 미디어 동기화 장치 및 방법 |
US7801847B2 (en) * | 2006-03-27 | 2010-09-21 | Microsoft Corporation | Media file conversion using plug-ins |
US7769842B2 (en) * | 2006-08-08 | 2010-08-03 | Endl Texas, Llc | Storage management unit to configure zoning, LUN masking, access controls, or other storage area network parameters |
JP2008090491A (ja) * | 2006-09-29 | 2008-04-17 | Brother Ind Ltd | Ftp通信システム |
JP2009003499A (ja) * | 2007-06-19 | 2009-01-08 | Hitachi Ltd | ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法 |
JP5000457B2 (ja) * | 2007-10-31 | 2012-08-15 | 株式会社日立製作所 | ファイル共有システム及びファイル共有方法 |
ES2647943T3 (es) | 2007-12-06 | 2017-12-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Método para actualizar la información de capacidad de UE en una red de telecomunicaciones móvil |
JP5317835B2 (ja) * | 2009-06-03 | 2013-10-16 | キヤノン株式会社 | コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラム |
US10417200B2 (en) * | 2010-07-30 | 2019-09-17 | Microsoft Technology Licensing, Llc | Data migration for service upgrades |
US9223799B1 (en) * | 2012-06-29 | 2015-12-29 | Emc Corporation | Lightweight metadata sharing protocol for location transparent file access |
US20140280779A1 (en) * | 2013-03-15 | 2014-09-18 | Synchronoss Technologies, Inc. | Apparatus, system and method of content transferring |
US10474535B2 (en) * | 2013-11-01 | 2019-11-12 | Longsand Limited | Asset browsing and restoration over a network using on demand staging |
WO2015065468A1 (en) * | 2013-11-01 | 2015-05-07 | Longsand Limited | Asset browsing and restoration over a network using pre-staging and directory storage |
US9977760B1 (en) | 2013-12-23 | 2018-05-22 | Google Llc | Accessing data on distributed storage systems |
US20150355862A1 (en) * | 2014-06-04 | 2015-12-10 | Pure Storage, Inc. | Transparent array migration |
US9087012B1 (en) | 2014-06-04 | 2015-07-21 | Pure Storage, Inc. | Disaster recovery at high reliability in a storage cluster |
US9811677B2 (en) | 2014-07-03 | 2017-11-07 | Pure Storage, Inc. | Secure data replication in a storage grid |
US10831719B2 (en) * | 2017-08-29 | 2020-11-10 | Western Digital Technologies, Inc. | File consistency in shared storage using partial-edit files |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5355497A (en) * | 1992-06-10 | 1994-10-11 | Physiotronics Corporation | File directory structure generator and retrevial tool with document locator module mapping the directory structure of files to a real world hierarchical file structure |
US5680954A (en) * | 1994-08-10 | 1997-10-28 | Cummins Engine Company, Inc. | Oil fill cap |
EP0709779B1 (en) | 1994-10-31 | 2001-05-30 | International Business Machines Corporation | Virtual shared disks with application-transparent recovery |
US5680640A (en) * | 1995-09-01 | 1997-10-21 | Emc Corporation | System for migrating data by selecting a first or second transfer means based on the status of a data element map initialized to a predetermined state |
JPH09231242A (ja) * | 1995-09-14 | 1997-09-05 | Sony Corp | ネットワーク上の端末装置及びその端末装置で読み取り可能な情報記録媒体 |
US5852724A (en) | 1996-06-18 | 1998-12-22 | Veritas Software Corp. | System and method for "N" primary servers to fail over to "1" secondary server |
US5835954A (en) * | 1996-09-12 | 1998-11-10 | International Business Machines Corporation | Target DASD controlled data migration move |
US5991760A (en) * | 1997-06-26 | 1999-11-23 | Digital Equipment Corporation | Method and apparatus for modifying copies of remotely stored documents using a web browser |
US7418439B2 (en) | 2000-03-17 | 2008-08-26 | Twin Peaks Software, Inc. | Mirror file system |
US7512673B2 (en) * | 2001-01-11 | 2009-03-31 | Attune Systems, Inc. | Rule based aggregation of files and transactions in a switched file system |
WO2003023623A1 (en) | 2001-09-10 | 2003-03-20 | Unisys Corporation | A method and apparatus for facilitating deployment of software applications with minimum system downtime |
JP2003167683A (ja) * | 2001-11-30 | 2003-06-13 | Hitachi Ltd | 情報記憶システム及びその制御方法 |
US6922761B2 (en) * | 2002-03-25 | 2005-07-26 | Emc Corporation | Method and system for migrating data |
JP4240930B2 (ja) | 2002-07-15 | 2009-03-18 | 株式会社日立製作所 | 複数ネットワークストレージの仮送想一元化方法及び装置 |
-
2004
- 2004-07-26 JP JP2004217031A patent/JP2006039814A/ja active Pending
- 2004-09-21 US US10/944,787 patent/US7313579B2/en active Active
-
2005
- 2005-02-01 EP EP05250543A patent/EP1622048B1/en active Active
- 2005-02-01 DE DE602005020395T patent/DE602005020395D1/de active Active
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007110931A1 (ja) * | 2006-03-28 | 2007-10-04 | Fujitsu Limited | 名前空間複製プログラム、名前空間複製装置、名前空間複製方法 |
JP4699516B2 (ja) * | 2006-03-28 | 2011-06-15 | 富士通株式会社 | 名前空間複製プログラム、名前空間複製装置、名前空間複製方法 |
US7827193B2 (en) | 2006-11-27 | 2010-11-02 | Hitachi, Ltd. | File sharing system, file sharing device and file sharing volume migration method |
US8046392B2 (en) | 2007-04-27 | 2011-10-25 | Hitachi, Ltd. | Storage system and information transfer method for the same |
JP2009288912A (ja) * | 2008-05-28 | 2009-12-10 | Hitachi Ltd | Nasシステムの移行方法、装置、プログラム、及びシステム |
US8315982B2 (en) | 2008-05-28 | 2012-11-20 | Hitachi, Ltd. | Method, apparatus, program and system for migrating NAS system |
JP2010211767A (ja) * | 2009-03-12 | 2010-09-24 | Fujitsu Ltd | アクセス制御装置、ストレージ装置、ネットワーク通信装置、アクセス制御方法、及びアクセス制御プログラム |
JP4724759B2 (ja) * | 2009-03-12 | 2011-07-13 | 富士通株式会社 | アクセス制御装置、ストレージ装置、ネットワーク通信装置、アクセス制御方法、及びアクセス制御プログラム |
JP2016527618A (ja) * | 2013-07-02 | 2016-09-08 | ヒタチ データ システムズ エンジニアリング ユーケー リミテッドHitachi Data Systems Engineering Uk Limited | 仮想化されたファイル・システムのマイグレーションのための方法および装置、仮想化されたファイル・システムのマイグレーションのためのデータ・ストレージ・システム、ならびにデータ・ストレージ・システム内で使用するためのファイル・サーバ |
JP2021033852A (ja) * | 2019-08-28 | 2021-03-01 | 富士ゼロックス株式会社 | 情報処理装置、情報処理システム、及び情報処理プログラム |
US11792334B2 (en) | 2019-08-28 | 2023-10-17 | Fujifilm Business Innovation Corp. | System for efficiently migrating content data |
JP7363198B2 (ja) | 2019-08-28 | 2023-10-18 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置、情報処理システム、及び情報処理プログラム |
JP7375375B2 (ja) | 2019-08-28 | 2023-11-08 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置、情報処理システム、及び情報処理プログラム |
Also Published As
Publication number | Publication date |
---|---|
DE602005020395D1 (de) | 2010-05-20 |
US20060020636A1 (en) | 2006-01-26 |
EP1622048A1 (en) | 2006-02-01 |
US7313579B2 (en) | 2007-12-25 |
EP1622048B1 (en) | 2010-04-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2006039814A (ja) | ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法 | |
JP4824085B2 (ja) | ネットワークファイルシステムをキャッシュするシステム、及び方法 | |
JP4349301B2 (ja) | ストレージ管理システムと方法並びにプログラム | |
US7191290B1 (en) | Apparatus and method for tandem operation in a storage network | |
US9565254B2 (en) | Object location service for network-based content repository | |
US7526668B2 (en) | Failover method of remotely-mirrored clustered file servers | |
JP4787315B2 (ja) | データコンテナの中身をクラスタの複数のボリュームにわたってストライピングするためのストレージシステム・アーキテクチャ | |
US7904649B2 (en) | System and method for restriping data across a plurality of volumes | |
US8161133B2 (en) | Network storage system with a clustered configuration sharing a namespace, and control method therefor | |
US7721045B1 (en) | System and method for efficiently guaranteeing data consistency to clients of a storage system cluster | |
US8601220B1 (en) | Transparent data migration in a storage system environment | |
US8429360B1 (en) | Method and system for efficient migration of a storage object between storage servers based on an ancestry of the storage object in a network storage system | |
US20170075909A1 (en) | In-line policy management with multi-level object handle | |
US20100114889A1 (en) | Remote volume access and migration via a clustered server namespace | |
US7925749B1 (en) | System and method for transparent data replication over migrating virtual servers | |
US7707165B1 (en) | System and method for managing data versions in a file system | |
US7243207B1 (en) | Technique for translating a pure virtual file system data stream into a hybrid virtual volume | |
US8327102B1 (en) | Method and system for non-disruptive migration | |
US20070073782A1 (en) | File system migration in storage system | |
JP2012525634A (ja) | ストライプ化ファイルシステムにおける能力平準化によるデータ分散 | |
US20070192375A1 (en) | Method and computer system for updating data when reference load is balanced by mirroring | |
JP2010097359A (ja) | ファイル管理方法および階層管理ファイルシステム | |
JP2004280283A (ja) | 分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法 | |
JP2009059201A (ja) | ファイルレベルの仮想化と移行を行う中間装置 | |
JP2008515120A (ja) | ストレージネットワーク用ストレージポリシーモニタリング |