(57)【要約】【課題】  サービス停止時間を短縮し、速やかに移行させる。【解決手段】  NAS１のファイルツリーと同一構造のファイルツリーが、予めNAS２に形成される。ツリーには、ファイルデータは移行されていない。NAS２は、NAS１で管理されるファイルディスクリプタｆｄ１とNAS２で管理されるｆｄ２との対応関係を保持する。ツリー構造の移行が完了すると、クライアント３へのサービスが再開される。クライアント３が、ｆｄ２を指定して所望のファイルへのアクセスを要求すると、NAS２は、ｆｄ２をｆｄ１に変換し、NAS１にファイルデータを要求する（ｄ）。NAS１がファイルデータを読出すと、NAS２は、ファイルデータを所定の場所４Ｂに記憶し、クライアント３に提供する（ｅ）。クライアント３が再びファイルアクセスを希望する場合、NAS２は、移行済のファイルデータを読出して、クライアント３に提供する。【選択図】        図２
2006039814.tif 000002
【特許請求の範囲】
【請求項１】
クライアントに提供するファイルを記憶する第１のネットワークストレージと、前記クライアント及び前記第１のネットワークストレージにそれぞれ接続される第２のネットワークストレージとを備えたネットワークストレージシステムであって、
前記第１のネットワークストレージが有する第１のファイルツリーと同一構造の第２のファイルツリーを、ファイルシステムのディレクトリ階層構造として、前記第２のネットワークストレージ上に生成させるファイルツリー生成部と、
前記第１のネットワークストレージ上のファイルへアクセスするべく前記クライアントから前記第２のネットワークストレージに対して要求されたアクセス要求に基づいて、前記クライアントから要求されたファイルを前記第１のネットワークストレージ上で特定するファイル特定部と、
前記特定されたファイルの属性及びデータを前記第１のネットワークストレージから取得し、この取得したファイルを前記第２のファイルツリーの所定の場所に格納させるファイル移行部と、
を備えたネットワークストレージシステム。
【請求項２】
前記第１のネットワークストレージのネットワーク設定情報を前記第２のネットワークストレージに継承させ、前記第２のネットワークストレージが前記第１のネットワークストレージに成り代わって前記クライアントにファイル共有サービスを提供するための通信部を備えた請求項１に記載のネットワークストレージシステム。
【請求項３】
前記ファイル移行部は、前記第１のネットワークストレージの記憶内容を変化させることなく、前記第１のネットワークストレージから前記ファイルを取得して、前記第２のファイルツリーの所定の場所に格納させる請求項１に記載のネットワークストレージシステム。
【請求項４】
前記ファイル移行部は、前記クライアントからのアクセス要求が前記第１のネットワークストレージ上に存在するファイルの参照要求である場合に、前記ファイル特定部により前記第１のネットワークストレージ上で特定された前記ファイルの属性及びデータを前記第１のネットワークストレージから取得して前記クライアントに提供し、この取得したファイルを前記第２のファイルツリーの所定の場所に格納させる請求項１に記載のネットワークストレージシステム。
【請求項５】
前記ファイル移行部は、前記第１のネットワークストレージから取得したファイルが所定の条件を満たす場合に、この取得したファイルを前記第２のファイルツリーの所定の場所に格納させる請求項４に記載のネットワークストレージシステム。
【請求項６】
前記第１のネットワークストレージから取得されたファイルの利用頻度が所定値以上の場合は、前記所定条件が満たされたものと判定されて前記第２のファイルツリーの所定の場所に格納される請求項５に記載のネットワークストレージシステム。
【請求項７】
前記ファイル移行部は、前記クライアントからのアクセス要求が前記第１のネットワークストレージ上に存在するファイルの更新要求である場合に、前記ファイル特定部により前記第１のネットワークストレージ上で特定された前記ファイルの属性及びデータを前記第１のネットワークストレージから取得し、この取得したファイルを更新して前記第２のファイルツリーの所定の場所に格納させる請求項１に記載のネットワークストレージシステム。
【請求項８】
前記ファイル特定部は、前記第１のネットワークストレージ上でファイルを特定するための第１のファイル識別情報と前記第２のネットワークストレージ上で前記ファイルを特定するための第２のファイル識別情報とを対応付けて構成されるファイル特定用情報を参照することにより、前記クライアントから要求されたファイルを前記第１のネットワークストレージ上で特定する請求項１に記載のネットワークストレージシステム。
【請求項９】
前記ファイル特定部は、前記クライアントから前記第１のネットワークストレージ上のファイルへのアクセス要求に基づいて、前記ファイル特定用情報を構築する請求項８に記載のネットワークストレージシステム。
【請求項１０】
前記ファイル特定部は、前記クライアントから前記第１のネットワークストレージ上のファイルへのアクセス要求に基づいて、前記第１のネットワークストレージから前記第１のファイル識別情報を取得し、この取得した第１のファイル識別情報と前記アクセス要求に関して生成された前記第２のファイル識別情報とを対応付けることにより、前記ファイル特定用情報を構築する請求項９に記載のネットワークストレージシステム。
【請求項１１】
前記ファイルツリー生成部は、前記第１のネットワークストレージ上のファイルが前記第２のファイルツリーの所定の場所に移行済みであるか否かを示す移行状態情報を前記第２のファイルツリーの構造に対応付けて、前記第２のファイルツリーを生成する請求項１に記載のネットワークストレージシステム。
【請求項１２】
前記ファイル特定部は、前記ファイルツリー生成部が前記第２のファイルツリーを生成する際に前記第１のネットワークストレージから取得する前記第１のファイル識別情報を前記ファイル特定用情報に予め格納しておき、前記クライアントからのアクセス要求を処理する度に前記第１のファイル識別情報に対応して生成される前記第２のファイル識別情報を、前記ファイル特定用情報に予め格納された前記第１のファイル識別情報に対応付けて、前記ファイル特定用情報に格納させる請求項８に記載のネットワークストレージシステム。
【請求項１３】
前記ファイルツリー生成部と前記ファイル特定部と前記ファイル移行部とを、前記第２のネットワークストレージ上に実現する請求項１に記載のネットワークストレージシステム。
【請求項１４】
クライアントへのファイル共有サービスを複数のネットワークストレージ間で引き継がせるための方法であって、
前記第１のネットワークストレージのネットワーク設定情報を前記第２のネットワークストレージに継承させるステップと、
前記第１のネットワークストレージから前記クライアントに提供されるファイル共有サービスを停止させるステップと、
前記第１のネットワークストレージが有する第１のファイルツリーと同一構造の第２のファイルツリーを、ファイルシステムのディレクトリ階層構造として、前記第２のネットワークストレージ上に生成させるステップと、
前記第２のネットワークストレージから前記クライアントに提供されるファイル共有サービスを開始させるステップと、
前記クライアントから前記第２のネットワークストレージ上のファイルへのアクセス要求に基づいて、前記クライアントから要求されたファイルを前記第１のネットワークストレージ上で特定するステップと、
前記特定されたファイルの属性及びデータを前記第１のネットワークストレージから取得し、この取得したファイルを前記第２のファイルツリーの所定の場所に格納させるステップと、
を含んだ複数ネットワークストレージ間の引継方法。
【請求項１５】
前記第２のファイルツリーを生成するステップの前に、前記第１のネットワークストレージと前記第２のネットワークストレージとを双方向通信可能に接続させるステップを設けた請求項１４に記載の複数ネットワークストレージ間の引継方法。
【請求項１６】
前記第１のネットワークストレージから取得したファイルを前記第２のファイルツリーの所定の場所に格納させるステップでは、前記第１のネットワークストレージの記憶内容を変化させることなく、前記第１のネットワークストレージから取得したファイルを前記第２のファイルツリーの所定場所に格納させる請求項１４に記載の複数ネットワークストレージ間の引継方法。
【請求項１７】
前記第１のネットワークストレージから取得したファイルを前記第２のファイルツリーの所定の場所に格納させるステップでは、前記取得したファイルが所定の条件を満たす場合に、前記取得したファイルを前記第２のファイルツリーの所定の場所に格納させるようになっている請求項１４に記載の複数ネットワークストレージ間の引継方法。
【請求項１８】
前記クライアントから要求されたファイルを前記第１のネットワークストレージ上で特定するステップは、前記第１のネットワークストレージ上でファイルを特定するための第１のファイル識別情報と前記第２のネットワークストレージ上で前記ファイルを特定するための第２のファイル識別情報とを対応付けて構成されるファイル特定用情報を参照することにより、前記クライアントから要求されたファイルを前記第１のネットワークストレージ上で特定する請求項１４に記載の複数ネットワークストレージ間の引継方法。
【請求項１９】
前記ファイル特定用情報は、前記クライアントから前記第１のネットワークストレージ上のファイルへのアクセス要求がされる度に段階的に構築されるものである請求項１８に記載の複数ネットワークストレージ間の引継方法。
【請求項２０】
前記第２のファイルツリーを前記第２のネットワークストレージに生成させるステップは、前記第１のネットワークストレージ上のファイルが前記第２のファイルツリーの所定の場所に移行済みであるか否かを示す移行状態情報を前記第２のファイルツリーの構造に対応付けながら、前記第２のファイルツリーを生成する請求項１４に記載の複数ネットワークストレージ間の引継方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法に関する。
【背景技術】
【０００２】
ネットワークストレージとは、インターネットやLAN等の通信ネットワークに接続され、複数のコンピュータによって共用されるストレージである。ネットワークストレージとしては、例えば、NAS（Network Attached Storage）等が知られている。企業や自治体あるいは学校等の組織では、膨大なデータを管理するために、一つまたは複数のネットワークストレージを導入し、ネットワークストレージシステムを構築している。
【０００３】
これらの組織で管理すべきデータは日々増大するため、ネットワークストレージシステムの管理者は、やがてネットワークストレージの容量不足に直面する。あるいは、ネットワークストレージを利用するクライアントの数が増大したような場合、管理者は、ネットワークストレージの応答性能の改善を検討する。
【０００４】
このようなネットワークストレージの容量不足や応答性低下等に対応するために、既設のネットワークストレージを新しいネットワークストレージに置き換えたり、あるいは、既設のネットワークストレージと新しく追加するネットワークストレージとを共存させて運用することが行われる（特許文献１）。
【０００５】
この特許文献に記載の従来技術では、まず先に、既設ネットワークストレージが有するディレクトリの階層構造、即ちファイルツリーの構造を新設ネットワークストレージにコピーしておき、次に、クライアントからのアクセス要求に応じて、既設ネットワークストレージから新設ネットワークストレージにファイルを移行させる。
【特許文献１】特開２００４−４６６６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
リブート後等のように、クライアントが所望のファイルへの最初のアクセスを試みる場合、クライアントは、ネットワークストレージのファイルシステムに対し、目的とするファイルの名称及びそのファイルが属するディレクトリ名を指定する。ファイルシステムは、クライアントから順番に指定された情報に基づいて、ディレクトリ階層構造としてのファイルツリーを順番に順に辿っていき、要求されたファイルを検出する。例えば、クライアントが、ディレクトリＡ下のサブディレクトリＢ内に存在するファイルＣにアクセスを試みる場合、ファイルシステムは、ディレクトリＡ→サブディレクトリＢ→ファイルＣへと、順番にファイルツリーを辿っていき、目的とするファイルＣを発見する。
【０００７】
ファイルシステムは、以後そのファイルへのアクセスを容易ならしめるために、そのファイルシステム内で一意に識別されるファイル識別情報（例えば、ファイルハンドル等）を発行し、クライアントに送信する。ファイルシステムがファイルツリーを順番に辿っていく過程において、ディレクトリ及びファイルをそれぞれ特定するためのファイル識別情報が、ファイルシステムからクライアントに通知される。
【０００８】
クライアントは、ファイルシステムから発行されたファイル識別情報をメモリ内に保持しておく。上述のように、ファイル識別情報は、ファイルシステム内でファイルを直接指定するための情報である。従って、クライアントは、次のファイルアクセス時に、ネットワークストレージに対してファイル識別情報を直接指定することにより、目的のファイルを要求する。ファイルシステムは、ファイル識別情報に基づいて、要求されたファイルを直接的に特定し、そのファイルへのアクセスをクライアントに提供する。このように、有効なファイル識別情報を入手済である場合、クライアントは、ファイルツリーを順番に辿ってファイルを探す必要がない。
【０００９】
同様に、新設のネットワークストレージは、ファイル識別情報に基づいて、ファイルシステム上でファイルを直接的に特定できる。しかし、ファイル識別情報は、ファイルシステム上でファイルを一意に識別する情報に過ぎず、ファイル識別情報だけで、そのファイルが存在するファイルツリー上の位置を直接特定することはできない。また、ファイル識別情報は、基本的に、それを発行したファイルシステム上で有効に機能し、異なるファイルシステム上では使用することができない。
【００１０】
従って、新設ネットワークストレージがクライアントからファイルアクセスを要求されたとしても、新設ネットワークストレージのファイルシステム以外のファイルシステムで発行されたファイル識別情報を用いてファイルが指定された場合や、要求されたファイルが新設ネットワークストレージ上に存在しない場合には、新設ネットワークストレージは、要求されたファイルを特定することができない。
【００１１】
即ち、新設ネットワークストレージのファイルシステムは、既設ネットワークストレージのファイルシステムが発行したファイル識別情報のみに基づいて、その要求されたファイルが既設ネットワークストレージ上の何処に存在するかを特定できないため、要求されたファイルの実体にアクセスすることはできない。
【００１２】
このように、上記文献に記載の技術では、既設ネットワークストレージから新設ネットワークストレージに未だ移行されていないファイルに対して、新設ネットワークストレージからアクセスするのは難しい。
【００１３】
そこで、上記文献に記載の技術では、事前に既設ネットワークストレージのファイルツリー構造を新設ネットワークストレージにコピーしておくだけでは足りず、新設ネットワークストレージからファイル共有サービスを開始する前に、予め特定の上位ディレクトリから下位に向けて、ファイルツリーの全部（または所定の範囲）のデータも移行させておく必要がある。換言すれば、新設ネットワークストレージにデータを移行した範囲内においてのみ、ファイル共有サービスを提供することができる。
【００１４】
従って、上記文献に記載の技術では、既設ネットワークストレージから新設ネットワークストレージへのファイルツリー全体のデータ移行が完了するまでの間、ファイル共有サービスを再開することができず、この結果、ネットワークストレージの置き換えに長い時間を必要とする。また、上記文献に記載の技術では、サービス再開前に予めデータ移行を済ませておく必要があるため、クライアントにファイル共有サービスを提供しながら移行させることはできない。
【００１５】
なお、上記文献に記載の技術では、例えば、新設ネットワークストレージに設けられた仮想一元化機能により、新旧のネットワークストレージを仮想的に一元化し、要求されたファイルの記憶先に応じて、新旧それぞれのネットワークストレージにアクセス要求を割り振ることも提案されている。しかし、このような仮想的一元化は、旧資産の積極活用という観点では有意義であるが、既設のネットワークストレージを新設のネットワークストレージに完全に置き換えることができない。従って、既設ネットワークストレージに記憶されている古いファイル群は、アクセス性能が相対的に劣る既設ネットワークストレージから提供する必要があり、システム全体としての応答性は低下する。また、旧式で性能の劣るネットワークストレージをいつまでも保守し続けなければならず、システムの保守コストや運用コストが増大する。
【００１６】
そこで、本発明の一つの目的は、本発明の一つの目的は、第２のネットワークストレージに移行されていないファイルへのアクセスが要求された場合でも、そのファイルを記憶する第１のネットワークストレージのファイルシステム上で直ちにファイルを特定し、第１のネットワークストレージからデータを取得してクライアントに提供することができ、比較的短時間で第１のネットワークストレージから第２のネットワークストレージへファイル共有サービスを移行（引継）させることができるようにしたネットワークストレージシステム及び複数ネットワークストレージ間の引継方法の提供にある。
【００１７】
本発明の一つの目的は、ファイルを記憶する第１のネットワークストレージの記憶内容を変更させることなく、また、第１のネットワークストレージに特別な機能を追加することなく、比較的短時間でネットワークストレージ間のファイル単位でのデータ移行を実現できるようにしたネットワークストレージシステム及び複数ネットワークストレージ間の引継方法を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。
【課題を解決するための手段】
【００１８】
上記課題を解決すべく、本発明のネットワークストレージシステムは、第１のネットワークストレージ（既設ネットワークストレージ）から第２のネットワークストレージ（新設ネットワークストレージ）に移行されていないファイルを、第１のネットワークストレージ上で直ちに特定し、ファイル単位でデータを移行できるように構成した。これにより、本発明のネットワークストレージシステムでは、ファイルツリー全体のデータを移行させるよりも前に、ファイル共有サービスを開始することができる。
【００１９】
即ち、本発明のネットワークストレージシステムは、クライアントに提供するファイルを記憶する第１のネットワークストレージと、クライアント及び第１のネットワークストレージにそれぞれ接続される第２のネットワークストレージとを備え、さらに、第１のネットワークストレージが有する第１のファイルツリーと同一構造の第２のファイルツリーを、ファイルシステムのディレクトリ階層構造として、第２のネットワークストレージ上に生成させるファイルツリー生成部と、第１のネットワークストレージ上のファイルへアクセスするべくクライアントから第２のネットワークストレージに対して要求されたアクセス要求に基づいて、クライアントから要求されたファイルを第１のネットワークストレージ上で特定するファイル特定部と、特定されたファイルの属性及びデータを第１のネットワークストレージから取得し、この取得したファイルを第２のファイルツリーの所定の場所に格納させるファイル移行部と、を備える。
【００２０】
クライアントは、例えば、ファイルディスクリプタ等のようなファイル識別情報を含むコマンドにより、第２のネットワークストレージに対して、所望のファイルへのアクセスを要求する。第２のネットワークストレージのファイルシステムは、クライアントから渡されたファイル識別情報に基づいて、要求されたファイルを第１のネットワークストレージのファイルシステム上で特定する。そして、第２のネットワークストレージは、特定されたファイルの属性及びデータを第１のネットワークストレージのファイルシステムから取得し、取得したファイルを第２のファイルツリーの所定の場所に格納させる。また、第１のネットワークストレージから第２のネットワークストレージに移されたファイルは、要求に応じて、第２のネットワークストレージからクライアントに提供される。
【００２１】
これにより、第２のネットワークストレージに移行されていないファイルへのアクセスがクライアントから要求された場合でも、要求されたファイルを第１のネットワークストレージから取得して、クライアントに提供することができる。また、クライアントへのファイル提供とほぼ同時期に、要求されたファイルを第２のファイルツリーの所定の場所に格納させることができる。ここで、「所定の場所」とは、第１のファイルツリー上での格納位置に対応する格納位置を示す。第２のネットワークストレージにファイルを移行させた後で、このファイルへのアクセス要求が発生した場合、第２のネットワークストレージは、第１のネットワークストレージにアクセスすることなく、自己のファイルシステム上でファイルを直接的に特定し、ファイルをクライアントに提供する。
【００２２】
ここで、ファイル移行部は、第１のネットワークストレージの記憶内容を変化させることなく、第１のネットワークストレージからファイルを取得して、第２のファイルツリーの所定の場所に格納させることができる。即ち、第１のネットワークストレージの記憶内容をそのまま保持しながら、ファイル単位で、第２のネットワークストレージにデータを移行させるため、万が一の事態に備えて第１のネットワークストレージの記憶内容をバックアップしておく必要がない。
【００２３】
ファイル移行部は、第１のネットワークストレージから取得したファイルが所定の条件を満たす場合に、この取得したファイルを第２のファイルツリーの所定の場所に格納させることができる。例えば、ファイルの利用頻度が所定値以上の場合に、第２のファイルツリーの所定の場所に格納させることができる。
【００２４】
ここで、例えば、ファイル特定部は、第１のネットワークストレージ上でファイルを特定するための第１のファイル識別情報と第２のネットワークストレージ上でファイルを特定するための第２のファイル識別情報とを対応付けて構成されるファイル特定用情報を参照することにより、クライアントから要求されたファイルを第１のネットワークストレージ上で特定することができる。
【００２５】
ファイル特定部は、クライアントから第１のネットワークストレージ上のファイルへのアクセス要求に基づいて、ファイル特定用情報を構築できる。即ち、例えば、ファイル特定部は、クライアントから第１のネットワークストレージ上のファイルへのアクセス要求に基づいて、第１のネットワークストレージから第１のファイル識別情報を取得し、この取得した第１のファイル識別情報と前記アクセス要求に関して生成された第２のファイル識別情報とを対応付けることにより、ファイル特定用情報を構築可能である。
【００２６】
一つの例を挙げると、クライアントが第２のネットワークストレージに対し、第１のファイル識別情報を用いてファイルアクセスを要求してきた場合、第２のネットワークストレージのファイルシステムは、この第１のファイル識別情報が無効（stale）であるとしてアクセス要求を拒否し、クライアントにリトライを要求する。
【００２７】
リトライ要求を受けたクライアントは、ディレクトリ名やファイル名を指定しながら、目的とするファイルに到達するまで、ファイルツリーを順番に辿っていく。クライアントがファイルツリーを順番に辿っていく過程と同期して、第２のネットワークストレージのファイルシステムは、第１のネットワークストレージのファイルシステムにアクセスし、第１のファイルツリーを順番に辿っていく。そして、目的とするファイルに辿り着いた場合、第２のネットワークストレージのファイルシステムは、そのファイルを第１のネットワークストレージ上で一意に特定するための第１のファイル識別情報を、第１のネットワークストレージのファイルシステムから取得する。なお、このとき、ファイルのデータ及び属性を第１のネットワークストレージのファイルシステムから取得して保存してもよいし、取得しなくてもよい。ここでは、取得しないものとして説明する。
【００２８】
また、第２のネットワークストレージのファイルシステムは、第１のネットワークストレージのファイルシステムから取得した第１のファイル識別情報と、自己が発行する第２のファイル識別情報とを対応付けてファイル特定用情報に登録する。そして、第２のネットワークストレージのファイルシステムは、第２のファイル識別情報をクライアントに通知する。クライアントは、通知された第２のファイル識別情報をメモリに保存し、この第２のファイル識別情報を用いて、所望のファイルへのアクセスを要求する。
【００２９】
第２のネットワークストレージのファイルシステムは、クライアントからのアクセス要求を受領すると、ファイル特定用情報を参照し、第２のファイル識別情報に対応する第１のファイル識別情報を取得する。第２のネットワークストレージのファイルシステムは、第１のファイル識別情報を用いて、第１のネットワークストレージのファイルシステムに対し、そのファイルのデータ及び属性を要求する。第２のネットワークストレージのファイルシステムは、第１のネットワークストレージから取得したファイルのデータ及び属性を所定の場所に保存すると共に、そのファイルをクライアントに提供する。
【００３０】
このように、第２のネットワークストレージのファイルシステムは、クライアントからのリトライアクセス（ファイルツリーを順番に辿っていく処理）と同様の処理を、あたかも自分がクライアントであるかのようにして、第１のネットワークストレージのファイルシステムに対し実行することができる。そして、第２のネットワークストレージは、第１のネットワークストレージの第１のファイルツリーを順番に辿っていく過程で、第１のファイルツリーと同一構造の第２のファイルツリーを構築することができる。
【００３１】
ファイルツリー生成部は、第１のネットワークストレージ上のファイルが第２のファイルツリーの所定の場所に移行済みであるか否かを示す移行状態情報を第２のファイルツリーの構造に対応付けて、第２のファイルツリーを生成することができる。ファイルツリーの構造は、そのツリーを構成する各要素（ファイルやディレクトリ）の繋がり方で表すことができる。そこで、ファイルツリーの構造を構成する一要素としてのファイルについて、そのファイルの実体（データ）が第２ネットワークストレージに移行済みであるか否かを示す情報（移行状態情報）を対応付けておく。つまり、将来そのファイルのデータが格納されるべき場所に、そのファイルのデータが未だ移行されていないことを示す情報を対応付けておく。これにより、第２のネットワークストレージのファイルシステムは、移行状態情報を参照することにより、そのファイルが移行されているか否かを即座に判断することができる。
【００３２】
ファイル特定部は、ファイルツリー生成部がディレクトリ階層構造としての第２のファイルツリーを生成する際に、第１のネットワークストレージから取得する第１のファイル識別情報をファイル特定用情報に予め格納しておくことができる。そして、ファイル特定部は、クライアントからのアクセス要求を処理する度に第１のファイル識別情報に対応して生成される第２のファイル識別情報を、ファイル特定用情報に予め格納された第１のファイル識別情報に対応付けて、ファイル特定用情報に格納させることにより、ファイル特定用情報を大きく２段階に分けて構築できる。即ち、第１段階は、第１のファイル識別情報をファイル特定用情報に登録する段階であり、第２段階は、第２のファイル識別情報を第１のファイル識別情報に対応付けてファイル特定用情報に登録する段階である。
【００３３】
本発明の機能、手段、ステップの全部または一部は、例えば、マイクロコンピュータにより実行されるコンピュータプログラムとして構成可能な場合がある。そして、このコンピュータプログラムは、例えば、ハードディスク、光ディスク、半導体メモリ等の記憶媒体に固定して配布することができる。または、コンピュータプログラムをインターネット等の通信ネットワークを介して、配信することもできる。
【発明を実施するための最良の形態】
【００３４】
以下、図面に基づき、本発明の実施の形態を説明する。図１，図２は、本実施形態の一つの側面に従う全体概念を示す説明図である。本実施形態のストレージシステムは、クライアント３に提供するファイルを記憶する第１のネットワークストレージ１と、クライアント３及び第１のネットワークストレージ１にそれぞれ接続される第２のネットワークストレージ２とを備えている。
【００３５】
このストレージシステムでは、第１のネットワークストレージ１が有する第１のファイルツリーと同一構造の第２のファイルツリーを、ファイルシステムのディレクトリ階層構造として、第２のネットワークストレージ２上に生成させる。そして、クライアント３から第２のネットワークストレージ２上のファイルへのアクセス要求に基づいて、クライアント３から要求されたファイルを第１のネットワークストレージ１上で特定し、特定されたファイルの属性及びデータを第１のネットワークストレージ１から取得し、この取得したファイルを第２のファイルツリーの所定の場所に格納させる。
【００３６】
図１（ａ）は、第２のネットワークストレージ２を追加する前のストレージシステムの状態を示す。クライアント３は、ファイルディスクリプタ等のようなファイル識別情報ｆｄを指定することにより、第１のネットワークストレージ１のファイルシステム１Ａに対し、所望のファイルを要求する。
【００３７】
ファイル識別情報ｆｄとは、そのファイル（ディレクトリを含む場合もある）を管理するファイルシステムやＯＳ（Operating System）内において、そのファイルを一意に特定するための情報である。ファイル識別情報ｆｄとしては、例えば、ファイルディスクリプタを挙げることができる。ファイルディスクリプタを用いることにより、例えば、「/usr/dir1/file1.txt」等のようなフルパスを指定することなく、簡単にファイルを特定することができる。ファイルディスクリプタの生成規則は、ファイルシステムの種類に依存し、各ファイルシステム毎にそれぞれ異なる。ファイルディスクリプタにバッファの管理機能等を含めた管理体系をファイルハンドルと呼ぶ。
【００３８】
例えば、クライアントコンピュータの起動直後等のように、クライアント３が所望のファイルのファイル識別情報を保持していない場合、クライアント３は、ファイルツリーを順番に所望のファイルまで辿っていくことにより、ファイルシステム１Ａからファイル識別情報を取得する。そして、クライアント３は、ファイル識別情報を指定して、ファイルシステム１Ａにファイルアクセスを要求する。
【００３９】
ファイルシステム１Ａは、クライアント３からファイル識別情報を指定されると、このファイル識別情報に基づいて、自己の管理下にあるファイル群の中から、指定されたファイルを直接的に特定し、クライアントに提供する。もしも、指定されたファイルが削除されていたような場合、そのファイル識別情報は無効（stale）として扱われ、ファイルシステム１Ａからクライアント３に対し、エラーが通知される。以下の説明では、第１のファイルシステム１Ａにより管理されるファイル識別情報をｆｄ１と、第２のファイルシステム２Ａにより管理されるファイル識別情報をｆｄ２と、それぞれ省略して記載する。
【００４０】
図１（ｂ）は、ストレージシステムに第２のネットワークストレージ２を追加した場合の説明図である。第２のネットワークストレージ２は、第１のネットワークストレージ１を置き換える（リプレース）ために導入される。第２のネットワークストレージ２は、ＩＰアドレス等のネットワーク設定情報を第１のネットワークストレージ１から継承し、第１のネットワークストレージ１に成りかわる。
【００４１】
第２のネットワークストレージ２は、例えば、情報処理サービスの提供終了後に導入することができる。なお、後述の実施例からも明らかなように、本発明では、情報処理サービスの提供中であっても、第２のネットワークストレージ２をストレージシステムに導入可能であり、情報処理サービスを中断することなく、第１のネットワークストレージ１から第２のネットワークストレージ２への移行を行うことができる。
【００４２】
第２のネットワークストレージ２のファイルシステム２Ａは、第１のネットワークストレージ１のファイルシステム１Ａとの間で通信を行うことにより、第１のネットワークストレージ１が有するファイルツリーと同一構造のファイルツリーを、第２のネットワークストレージ２に構築する。
【００４３】
ここで、本明細書におけるファイルツリーとは、ディレクトリ階層構造としてのツリー構造、即ち例えるなら、所定構造を有する「容器」を意味し、ファイルの実体であるデータとは切り離して用いる。従って、第１のネットワークストレージ１から第２のネットワークストレージ２へファイルツリー構造をコピーした場合でも、個々のファイルのデータまでは移行されていない。
【００４４】
ファイルツリー構造のコピーは、例えば、第２のファイルシステム２Ａから第１のファイルシステム１Ａに対し、リスト要求コマンド等を送信し、このコマンドに対して第２のファイルシステム２Ａが応答することにより実行される。第２のファイルシステム２Ａは、第１のファイルツリーのルートディレクトリ（”/”）から下位に向けて順番にツリー構造を辿りながら、その構造としてのファイルツリーをコピーする。例えば、ルートディレクトリの下位に、”usr”，”etc”というディレクトリが存在する場合、第２のファイルシステム２Ａは、これらの”usr”，”etc”にそれぞれｉノード番号を割当てると共に、ｉノード番号間の繋がりを規定することにより、ツリー構造をコピーする。
【００４５】
ファイルの格納容器としてのファイルツリーを第２のネットワークストレージ２にコピーした時点では、ファイルのデータはコピーされていない。図１（ｂ）に示すように、第１のネットワークストレージ１が記憶するファイル４Ａのデータは、第２のネットワークストレージ２に未だコピーされておらず、そのファイルデータを格納すべき場所４Ｂのみが確保されている。
【００４６】
なお、第１のネットワークストレージ１から第２のネットワークストレージ２へファイルツリー構造をコピーする際に、第２のネットワークストレージ２のファイルシステム２Ａは、第１のファイルシステム１Ａから、ファイルツリー構造の各構成要素（個々のディレクトリ及びファイル）のｆｄ１を取得することができる。そして、取得したｆｄ１を変換部２Ｂに登録することができる。
【００４７】
第１のファイルシステム１Ａで管理するｆｄ１と、第２のファイルシステム２Ａで管理するｆｄ２とを対応付けて管理する変換部２Ｂは、複数のタイミングで生成することができる。後述の実施例からも明らかなように、一つの方法として、ファイルツリー構造をコピーした後、クライアント３からのアクセス要求に基づいて、ｆｄ１とｆｄ２との対応関係を徐々に構築することができる。他の一つの方法として、ファイルツリー構造をコピーする際に、ｆｄ１と第２のファイルシステム２Ａが管理するｉノード番号とを対応付けておき、その後、クライアント３からのアクセス要求に基づいてｆｄ２を発行する際に、ｆｄ２とｆｄ１とを対応させることもできる。
【００４８】
図１（ｃ）は、第２のネットワークストレージ２がサービスの提供を再開した様子を示している。クライアント３は、第２のネットワークストレージ２のファイルシステム２Ａから、所望のファイルのｆｄ２を取得する。説明の便宜上、所望のファイルのｆｄをｆｄ（file）として示す。クライアント３は、第２のネットワークストレージ２のファイルツリー構造を上から順番に辿っていくことにより、所望のファイルを特定するためのｆｄ２（file）を入手することができる。本実施形態では、ファイルツリー構造の移行が完了した時点で、第２のネットワークストレージ２からクライアント３へのNASサービスを提供可能であるため、サービス停止時間を短くできる。
【００４９】
図２に移る。図２（ｄ）は、クライアント３が、第２のファイルシステム２Ａから入手したｆｄ２（file）を用いて、所望のファイルへのアクセスを要求する様子を示す。
【００５０】
第２のファイルシステム２Ａは、クライアント３からｆｄ２（file）を受領すると、変換部２Ｂによって、ｆｄ２（file）を第１のファイルシステム１Ａが管理するｆｄ１（file）に変換する。そして、第２のネットワークストレージ２は、ｆｄ１（file）を指定して、第１のネットワークストレージ１に対し、所望のファイルの取得を要求する。
【００５１】
図２（ｅ）に示すように、第１のファイルシステム１Ａは、第２のネットワークストレージ２からｆｄ１（file）を受領すると、直ちにファイルを特定し、このファイルのデータ及び属性を第２のネットワークストレージ２に転送する。ここで、もしも仮に、第２のネットワークストレージ２が、ｆｄ１（file）ではなく、ｆｄ２（file）を用いてファイルの取得を要求した場合、第１のファイルシステム１Ａは、ｆｄ２（file）に基づいてファイルを特定することができないため、エラーを返す。
【００５２】
しかし、本実施形態では、第２のネットワークストレージ２は、第１のファイルシステム１Ａで管理されるｆｄ１（file）を用いて、ファイルを要求するため、第１のファイルシステム１Ａは、要求されたファイルを直ちに特定して、ファイルのデータを第２のネットワークストレージ２に送信することができる。
【００５３】
第２のネットワークストレージ２は、第１のネットワークストレージ１からファイルのデータを受領すると、このデータをファイルツリーの所定の場所４Ｂに格納する。この格納場所４Ｂは、既に述べたように、そのファイルのデータが記憶されるべきディレクトリ階層構造上の位置として、ファイルツリーのコピー時に生成されたものである。
【００５４】
第２のネットワークストレージ２は、ファイルを所定場所４Ｂに格納すると共に、そのファイルのデータをクライアント３に送信する。従って、クライアント３からは、第２のネットワークストレージ２に対するｆｄ２（file）の指定によって、所望のファイルを取得できたように見えない。第２のネットワークストレージ２と第１のネットワークストレージ１との間のやり取りは、クライアント３に対して隠されている。
【００５５】
図２（ｆ）は、第１のネットワークストレージ１が保持するファイル群を、第２のネットワークストレージ２に移行させた後の状態を示す。上述のように、本実施形態では、ファイルツリー構造のみを先に移行してサービスを再開し、その後、クライアント３からの要求に応じて、要求されたファイルのデータを第１のネットワークストレージ１から第２のネットワークストレージ２に個別に移行させる。
【００５６】
従って、本実施形態では、クライアント３がファイルを必要とする場合に、その必要とされたファイルのみをファイル単位で移行させることができる。このような運用を続けているうちに、第１のネットワークストレージ１の有する多くのファイル群が、第２のネットワークストレージ２にコピーされていく。第１のネットワークストレージ１に残されたままのファイル群は、クライアント３から必要とされていないファイル群であるから、そのまま破棄しても構わないし、後日に備えて残しておいてもよい。ここで、第１のネットワークストレージ１から第２のネットワークストレージ２への移行に際して、第１のネットワークストレージ１の記憶内容には何らの変化も生じないため、第１のネットワークストレージ１のデータをバックアップしておく必要はない。第１のネットワークストレージ１が保持するファイル群は、第１のネットワークストレージ１自身にそのまま保持させておくことができる。
【００５７】
上述のように、クライアント３から必要とされる範囲のファイル群が、第１のネットワークストレージ１から第２のネットワークストレージ２に移行された場合に、第２のネットワークストレージ２は、第１のネットワークストレージ１に置き換わる。クライアント３は、ｆｄ２を指定して第２のファイルシステム２Ａにファイルアクセスを要求すればよく、第２のネットワークストレージ２は、ｆｄ２をｆｄ１に変換したり、第１のネットワークストレージ１にアクセスする必要はない。
【００５８】
ここで、第１のネットワークストレージ１から第２のネットワークストレージ２にファイルを移行させる場合に、所定の条件を設定することができる。即ち、第１のネットワークストレージ１から読み出されたファイルが所定の条件を満たすときに、この読出したファイルを第２のファイルツリーの所定の場所に格納させることができる。
【００５９】
所定の条件としては、例えば、ファイルの利用頻度等を挙げることができる。第１のネットワークストレージ１から読出されたファイルの利用頻度が所定値以上の場合は、所定条件が満たされたものと判定し、第２のファイルツリーの所定の場所に格納させる。
【００６０】
ファイルの利用頻度としては、例えば、そのファイルに対して所定期間内に所定回数以上のアクセスが発生したか否か、そのファイルの最終更新日から所定期間が経過しているか否か、そのファイルにアクセスする共有クライアント数が所定値以上であるか否か等を挙げることができる。
【００６１】
利用頻度の低いファイルは、クライアント３からアクセスが要求された場合であっても、第１のネットワークストレージ１から第２のネットワークストレージ２に移行させずに第１のネットワークストレージ１上に残しておくことができる。第１のネットワークストレージ１上に残されたファイルについては、クライアント３からアクセスが要求される度に、第２のネットワークストレージ２が第１のネットワークストレージ１にアクセスして、読み出す。利用頻度の低いファイルを第２のネットワークストレージ２に移行させず、第１のネットワークストレージ１上に残しておくことにより、利用頻度の低いファイルを自然に淘汰することができ、第２のネットワークストレージ２の記憶領域を効率的に使用することができる。もっとも、所定の条件（ファイル移行条件）は、固定的なものである必要はなく、動的に変更可能としてもよい。例えば、クライアント３からのアクセス要求が所定回数に達したような場合には、そのファイルを第１のネットワークストレージ１から第２のネットワークストレージ２に移し替えることもできる。
【００６２】
以下、ネットワークストレージシステムのより詳細な構成について、図３以下を参照しながら説明する。
【実施例１】
【００６３】
図３は、ネットワークストレージシステムのハードウェア構成に着目した概略ブロック図である。ネットワークストレージシステムは、それぞれ後述するように、複数のクライアント１０，１１と、ネットワークストレージ２０と、これら各クライアント１０，１１とネットワークストレージ２０とを相互に接続する通信ネットワークＣＮ１とを備えて構成することができる。
【００６４】
クライアント１０，１１は、コンピュータ装置に搭載されたプログラムであり、ネットワークストレージ２０が提供するファイル共有サービス（NASサービス）を利用するためのものである。ここで、例えば、クライアント１０は、UNIX（登録商標）ＯＳ上にNFS（Network File System，登録商標）を設けたNFSクライアントである。また、例えば、クライアント１１は、Windows（登録商標）ＯＳ上にCIFS（Common Internet File System，登録商標）を設けたCIFSクライアントである。NFS，CIFSは、ファイルアクセス用のプロトコルであり、例えば、TCP/IP（Transmission Control Protocol/Internet Protocol）上で稼働する。
【００６５】
ネットワークストレージ２０は、例えば、NASとして構成されるもので、NFSやCIFS等の多種類のファイルアクセスプロトコルに対応可能である。ネットワークストレージ２０は、NASヘッド等とも呼ばれる制御部３０と、記憶部４０とを備えている。制御部３０は、例えば、CPU（Central Processing Unit）３１と、RAM（Random Access Memory）３２と、ROM（Read Only Memory）３３と、通信インターフェース（以下、「通信Ｉ／Ｆ」）３４〜３６とを備えて構成することができる。通信Ｉ／Ｆ３４は、例えば、LAN等の通信ネットワークＣＮ１を介して、各クライアント１０，１１との間でデータ送受信を行う上位通信Ｉ／Ｆである。通信Ｉ／Ｆ３５，３６は、例えば、SAN（Storage Area Network）等の通信ネットワークＣＮ２を介して、記憶部４０との間でデータ送受信を行う下位通信Ｉ／Ｆである。
【００６６】
制御部３０は、各クライアント１０，１１から受信したコマンドを解釈し、コマンドの内容に従って、記憶部４０にアクセスする。制御部３０は、記憶部４０から読出したファイルを各クライアント１０，１１に送信する。また、制御部３０は、記憶部４０から読出したファイルの全部または一部を書き換えて、記憶部４０に記憶させる。
【００６７】
記憶部４０は、複数の記憶デバイス４１を備えている。各記憶デバイス４１は、例えば、ハードディスクドライブ、半導体メモリ装置、光ディスクドライブ等として構成することができる。各記憶デバイス４１には、複数の通信ネットワークＣＮ２がそれぞれ接続されている。一方の通信ネットワークＣＮ２に障害が発生した場合でも、他方の通信ネットワークＣＮ２を介して記憶デバイス４１にアクセス可能である。また、例えば、３個、４個、５個等のような複数個の記憶デバイス４１が一つのRAID（Redundant Array of Independent Disks）グループを構成している。各RAIDグループには、少なくとも一つ以上の論理ボリュームを形成することができる。即ち、各記憶デバイス４１がそれぞれ提供する物理的な記憶領域上には、論理的な記憶領域である論理ボリューム（Logical Unit：以下、「ＬＵ」）が形成される。
【００６８】
なお、図中では、ネットワークストレージ２０内に記憶部４０を備える場合を示すが、記憶部４０の全部または一部をネットワークストレージ２０の筐体外部に設ける構成でもよい。例えば、多数の記憶デバイスをアレイ状に配設して構成するディスクアレイ装置を記憶部４０として利用することもできる。
【００６９】
図４は、ネットワークストレージシステムのソフトウェア構成に着目した概略ブロック図である。ネットワークストレージ２０は、例えば、ネットワークプロトコル層５１と、ファイルアクセスプロトコル層５２，５３と、ファイルシステム５４と、論理ボリュームマネージャ（以下、「LVM」）５５と、デバイスドライバ群５６と、複数のＬＵ５７（一つのみ図示）等を備えて構成することができる。
【００７０】
ネットワークプロトコル層５１は、例えば、TCP/IPやUDP/IP（User Datagram Protocol/Internet Protocol）等のようなプロトコルをサポートしており、これらのプロトコルに従ってデータの送受信を行う。ファイルアクセスプロトコル層５２，５３は、ファイルアクセスのためのプロトコルをサポートする。例えば、一方のファイルアクセスプロトコル５２はNFSであり、他方のファイルアクセスプロトコル５３はCIFSである。
【００７１】
ファイルシステム５４は、各ＬＵ５７へのファイルの入出力等を制御するプログラムであり、各ＬＵ５７毎にそれぞれファイルツリーを形成する。アクセス制限等が設定されているような場合を除き、各ファイルツリーは、各クライアント１０，１１にそれぞれ提供可能である。
【００７２】
LVM５５は、ＬＵ５７の管理機能を提供するプログラムである。LVM５５は、例えば、複数のＬＵ５７を束ねて、ユーザが使用し易い容量のボリュームに分割等する。また、LVM５５は、スナップショット機能を備えることもできる。スナップショットとは、ある時点におけるデータの静止化イメージである。スナップショット機能とは、スナップショット作成時点における記憶構成を仮想ボリュームとして提供する機能である。デバイスドライバ群５６は、ストレージアクセスの単位であるＬＵ５７を上位のLVM５５にアクセスさせるために、スペシャルファイルの形式でデータを提供する。
【００７３】
ファイルシステム５４は、クライアント１０，１１からディレクトリ名及びファイル名を明示したコマンドを受領する。ファイルシステム５４は、受領したコマンドに基づいて、クライアント１０，１１から要求されたファイルをボリューム位置情報に変換する。ボリューム位置情報は、例えば、ファイルデータの存在するボリューム番号やセグメント情報から構成される。ファイルシステム５４は、アクセス対象のファイルをボリューム位置情報に変換して、LVM５５にデータアクセスを要求する。LVM５５は、ファイルシステム５４からのアクセス要求を受領すると、ＬＵ５７上のブロックアドレスに変換し、デバイスドライバ群５６に渡す。デバイスドライバ群５６は、LVM５５から受領したブロックアドレスに基づいてＬＵ５７にアクセスし、ファイルのデータを読み出す。読み出されたファイルデータは、ネットワークストレージ２０のRAM３２に一時的に記憶され、クライアント１０，１１に送信される。
【００７４】
次に、図５は、ネットワークストレージシステムの機能構成に着目した概略ブロック図である。ネットワークストレージシステムは、複数のクライアント１０，１１と、新設されるネットワークストレージ１００（以下、「新NAS１００」）と、既に設置されているネットワークストレージ２００（以下、「旧NAS２００」）と、LAN等の通信ネットワークＣＮ１とを備えている。
【００７５】
各NAS１００，２００は、それぞれ図３，図４に示したような構成を備えることができる。各NAS１００，２００は、同一構造である必要はない。旧NAS２００は、各クライアント１０，１１へNASサービスを提供する機能を備えていれば足りる。後述のように、本実施形態に特徴的な各機能は、新NAS１００に実装される。但し、場合によっては、特徴的な各機能の全部または一部を新NAS１００の外部に設けてもよい。
【００７６】
新NAS１００は、例えば、ファイルシステム１０１と、ＬＵ１０２と、通信部１０４とを備えて構成することができる。より詳しくは、新NAS１００は、図４と共に述べたように、LVMやデバイスドライバ群等の構成も備えているが、説明の便宜上、図５中では図示を省略している。ファイルシステム１０１は、図４中のファイルシステム５４に、ＬＵ１０２は図４中のＬＵ５７に、通信部１０４は図４中のネットワークプロトコル層５１及びファイルアクセスプロトコル層５２，５３に、それぞれ対応する。
【００７７】
ファイルシステム１０１の内部機能は、例えば、管理部１１０と、ファイルツリー生成部１２０と、アクセス要求処理部１３０とに分類可能である。
【００７８】
管理部１１０は、ファイルツリーの管理を行うもので、例えば、ｆｄ−ｉノード変換部１１１と、ｆｄ−ｆｄ変換部１１２と、ｉノード情報管理部１１３とを備えて構成することができる。
【００７９】
ｆｄ−ｉノード変換部１１１は、クライアントから受領したファイルディスクリプタｆｄをｉノード番号に変換する機能である。ｆｄ−ｉノード変換部１１１は、例えば、ｆｄ−ｉノード変換テーブルＴ１１を参照することにより、入力されたファイルディスクリプタｆｄをｉノード番号に変換することができる。これに限らず、例えば、ｆｄからｉノード番号を算出可能な場合は、ｆｄ−ｉノード変換テーブルＴ１１を廃止し、ｆｄ−ｉノード変換部１１１内でファイルディスクリプタｆｄをｉノード番号に変換するようにしてもよい。
【００８０】
ｆｄ−ｆｄ変換部１１２は、新NAS１００が発行したファイルディスクリプタｆｄ（new）を、旧NAS２００が発行したファイルディスクリプタｆｄ（old）に変換する機能である。図中では、新NAS１００が発行したファイルディスクリプタを新ｆｄと、旧NAS２００が発行したファイルディスクリプタを旧ｆｄと表示している。ｆｄ−ｆｄ変換部１１２は、例えば、ｆｄ−ｆｄ変換テーブルＴ１２を参照することにより、新ｆｄを旧ｆｄに変換する。必要があれば、旧ｆｄを新ｆｄに変換することもできる。後述のように、ｆｄ−ｆｄ変換テーブルＴ１２は、ファイルツリーを旧NAS２００から新NAS１００に移行する際に、旧ｆｄに関する部分だけが先に生成される。そして、NASサービスを再開した後、クライアント１０，１１からのファイルアクセスに応じて、ｆｄ−ｆｄ変換テーブルＴ１２の残りの部分が徐々に段階的に生成されるようになっている。
【００８１】
ｉノード情報管理部１１３は、各ｉノードの情報を管理するものである。ｉノード（ｉノード情報）とは、各ファイル（ディレクトリ）毎にそれぞれ与えられるファイル属性を示す情報である。UNIX（登録商標）の場合、ディレクトリもファイルのように扱われる場合がある。ｉノードのキーとなるｉノード番号とは、ファイルシステム上でファイルを識別するための整数値である。各ファイルは、ｉノード番号によって、実ボリューム１０２における格納位置が特定されるようになっている。ｉノードの情報としては、例えば、そのファイル（またはディレクトリ）の所有者、ファイルサイズ、ファイルの格納先アドレス、ファイルかディレクトリかの区別（ツリーの終端であるか否かを示す情報）等のファイル（ディレクトリ）属性情報を挙げることができる。ｉノード情報管理部１１３は、取得した属性情報をｉノード情報管理テーブルＴ１３に登録することができる。
【００８２】
ファイルツリー生成部１２０は、各ＬＵ１０２にそれぞれファイルツリーを生成するものである。また、ファイルツリー生成部１２０は、旧NAS２００の有するファイルツリーと同一構造のファイルツリーを、新NAS１００のＬＵ１０２上に形成する機能を備えている。
【００８３】
アクセス要求処理部１３０は、クライアントからのファイルアクセス要求を処理するものである。アクセス要求処理部１３０は、例えば、旧ｆｄ取得部１３１と、新ｆｄ発行部１３２と、移行状態判定部１３３と、ファイル移行部１３４とを備えて構成することができる。旧ｆｄ取得部１３１は、目的のファイルについて旧NAS２００が発行している旧ｆｄを、旧NAS２００から取得するものである。新ｆｄ発行部１３２は、クライアントからのアクセスに応じて、ファイルやディレクトリの新ｆｄを発行し、クライアントに通知させるものである。移行状態判定部１３３は、旧NAS２００のファイルツリーから新NAS１００のファイルツリーにファイルデータ（ファイルの実体）が移行済であるか否かを管理するものである。ファイル移行部１３４は、未移行のファイルデータを旧NAS２００から取得し、この取得したファイルデータを旧NAS２００のファイルツリーに対応するファイルツリーの所定の場所に記憶させるものである。
【００８４】
ファイルツリー生成部１２０とアクセス要求処理部１３０とは、それぞれ必要に応じて管理部１１０にアクセスし、各テーブルＴ１１〜Ｔ１３から情報を取得したり、各テーブルＴ１１〜Ｔ１３に情報を登録する。なお、上記のような機能分類は一例であって、本発明はこれに限定されない。
【００８５】
旧NAS２００は、ファイルシステム２０１とＬＵ２０２とを備えている。これ以外の機能については、説明及び図示を省略する。旧NAS２００は、新NAS１００が導入される前から運用されているネットワークストレージであり、そのＬＵ２０２には、各クライアント１０，１１によって利用される多数のファイル群が記憶されている。新NAS１００の導入前は、旧NAS２００が通信ネットワークＣＮ１を介して、各クライアント１０，１１にNASサービスを提供する。
【００８６】
新NAS１００を導入する際に、旧NAS２００のネットワーク設定情報は、新NAS１００に受け継がれる。そして、旧NAS２００は、通信ネットワークＣＮ１から切り離され、新NAS１００に通信ネットワークＣＮ２を介して直接的に接続される。
【００８７】
図６は、旧NAS２００から新NAS１００へファイルツリー構造をコピーする様子を示す模式図である。図中の上側に示すように、旧NAS２００のファイルシステム２０１は、ファイルツリー２０３を利用して、ファイルへのアクセス要求を処理する。
【００８８】
旧NAS２００の有するファイルツリー２０３と同一構造を有するファイルツリー１０３を新NAS１００上に生成する場合、新NAS１００のファイルシステム１０１は、旧NAS２００のファイルシステム２０１に所定のコマンドを送信する。新NAS１００のファイルシステム１０１は、旧NAS２００のファイルシステム２０１からの応答に基づいて、ファイルツリー１０３を構築する。
【００８９】
例えば、新NAS１００のファイルシステム１０１は、旧NAS２００のファイルシステム２０１にLOOKUPコマンドやｌｓコマンド等を送信することにより、旧NAS２００のファイルツリー２０３のルートディレクトリ（”/”）から下位に向けて、ディレクトリ階層構造を辿っていく。図６中の（ａ）に示すように、新NAS１００には、部分的にファイルツリー１０３が構築されていく。このファイルツリー１０３は、ファイルデータの格納場所の位置関係を相互に関連付けたものであり、この段階では、ファイルのデータはコピーされない。
【００９０】
図６（ａ）のテーブルＴ１２に示すように、旧NAS２００のファイルツリー構造を上位ディレクトリから下位ディレクトリに向けて辿りながらファイルツリー構造をコピーする過程において、旧NAS２００のファイルシステム２０１で管理される旧ｆｄと、新NAS１００のファイルシステム１０１で管理される新ｆｄとを対応付けて管理することができる。正確には、新ｆｄと旧ｆｄとを直接対応づけるのではなく、新ｆｄと一対一で対応するｉノード番号を介して、新ｆｄと旧ｆｄとの対応付けを行うことができる。
【００９１】
即ち、ファイルツリー構造をコピーする過程において、旧NAS２００のファイルシステム２０１から旧ｆｄが取得され、また、新NAS１００のファイルシステム１０１は、ファイルツリーの各構成要素にそれぞれｉノード番号を割り当てる。このｉノード番号は、ファイルシステム１０１が発行する新ｆｄと一対一で対応する。従って、ファイルツリー構造をコピーする過程で、旧ｆｄとｉノード番号とを対応付けておくことにより、間接的に、旧ｆｄと新ｆｄとを対応付けることができる。旧ｆｄとｉノード番号とを先に対応付ける方法については、別の実施例でさらに後述する。
【００９２】
旧ｆｄと新ｆｄとの対応付けは、ファイルツリー構造の移行時に行うこともできるし、後述のように、ファイルツリー構造の移行が完了した後、クライアントからのファイルアクセスに応じて、新旧のｆｄを対応付けることもできる。
【００９３】
図６（ｂ）に示すように、やがて、旧NAS２００のファイルツリー２０３と同一構造のファイルツリー１０３が、新NAS１００上に構築される。これと同時に、旧ｆｄと新ｆｄ（ｉノード番号）との対応付けも完了する。但し、上述のように、旧ｆｄと新ｆｄとの対応関係の構築方法には種々の変形例が存在する。
【００９４】
旧NAS２００から新NAS１００にコピーされるファイルツリー構造は、ファイルの格納場所を示すもので、ファイルのデータはコピーされていない。そのことを示すために、図６中では「file」を破線で囲んである。
【００９５】
次に、図７及び図８を参照して、ｉノード情報を用いたファイルの特定方法について説明する。まず、図７に基づいて、旧NAS２００上で実行されるファイル特定方法を説明する。ディレクトリ「dir1」に格納されているファイル「file1.txt」のデータにアクセスする様子を例に挙げて説明する。
【００９６】
最初に、ルートディレクトリのｉノード情報を参照する。図示の例では、ルートディレクトリにｉノード番号「２」が与えられている。ルートディレクトリのｉノード情報には、ルートディレクトリの所有者、ファイルサイズ等の属性の他に、ファイルアドレスAdr１が含まれている。アドレスAdr１は、実ボリュームであるＬＵ２０２上の記憶位置を示している。
【００９７】
そこで、図７中の右側に示すように、アドレスAdr１に記憶されているデータ内容を参照する。そこには、ルートディレクトリに含まれている各ディレクトリの名称及びそのｉノード番号がそれぞれ格納されている。具体的には、例えば、「usr，10」とは、ｉノード番号「１０」を与えられたディレクトリ「usr」を示す。同様に、「bin，２０」とは、ｉノード番号「２０」を与えられたディレクトリ「bin」を示す。従って、ルートディレクトリのデータ内容として、「usr，10，bin，20，etc，30」と記述されている場合は、ルートディレクトリ下に、ｉノード番号「１０」のディレクトリ「usr」と、ｉノード番号「２０」のディレクトリ「bin」と、ｉノード番号「３０」のディレクトリ「etc」がそれぞれ設けられていることを示す。
【００９８】
ルートディレクトリ下にディレクトリ「usr」が存在することを確認した後、ｉノード番号「１０」のｉノード情報を参照する。ｉノード番号「１０」は、ディレクトリ「usr」に与えられている番号である。そのｉノード情報には、ファイルアドレスAdr２が含まれている。そこで、アドレスAdr２に記憶されているデータ内容を参照すると、ディレクトリ「usr」には、２個のサブディレクトリ「dir1」，「dir2」が含まれていることがわかる。
【００９９】
サブディレクトリ「dir1」のｉノード情報を参照すると、そこには、ファイルアドレスAdr３が含まれている。アドレスAdr３に記憶されているデータ内容を参照すると、「dir1」には、ファイル「file1.txt」が格納されていることがわかる。そこで、ファイル「file1.txt」に与えられたｉノード番号「１０１」をキーとして、そのファイルのｉノード情報を参照する。ファイル「file1.txt」のｉノード情報には、ファイルアドレスAdr４が含まれている。また、このｉノードがファイルツリーの末端であることを示す末端情報も含まれている。ファイル「file1.txt」のデータは、アドレスAdr４に記憶されているので、アドレスAdr４からファイルデータを読み出すことができる。このようにして、ｉノード情報管理テーブルをルートディレクトリから順番に辿ることにより、目的のファイルにアクセスすることができるようになっている。
【０１００】
図８は、新NAS１００上で実行されるファイル特定方法を示す。図７に示すｉノード情報管理テーブルと図８に示すｉノード情報管理テーブルＴ１３とは、３つの点で相違している。第１の相違点は、ファイルツリーを構成する各要素（ファイル、ディレクトリ）に与えられるｉノード番号がそれぞれ異なる点である。ルートディレクトリには、新旧のNAS１００，２００のいずれにおいても、ｉノード番号「２」が与えられているが、ルートディレクトリ下のファイル（ディレクトリを含む）には、それぞれ異なるｉノード番号が付与されている。つまり、ｉノード番号の設定方法は、ファイルシステム毎にそれぞれ相違する。
【０１０１】
第２の相違点は、各ｉノード情報に関連付けられるデータ内容の記憶先アドレスが、新旧のNAS１００，２００でそれぞれ相違する点である。
【０１０２】
第３の相違点は、新NAS１００のｉノード情報管理テーブルＴ１３には、未更新フラグが追加されている点である。未更新フラグとは、ファイルが新NAS１００のＬＵ１０２に移行済であるか否かを示す情報である。未更新フラグは、例えば、「移行状態情報」や「移行状態判別情報」等と呼ぶこともできる。ディレクトリのｉノード情報には、未更新フラグは設定されない。未更新フラグは、ファイルのみに設定される。未更新フラグが「１」の場合は、そのファイルが新NAS１００に移行されていないことを示す。この第３の相違点は、本実施形態の特徴的構成の一つである。なお、未更新フラグは、ｉノード情報管理テーブルＴ１３内に含まれている必要は必ずしもなく、ｉノード番号と対応付けられていればよい。
【０１０３】
次に、図９に基づいて、ｆｄ−ｉノード変換テーブルＴ１１及びｆｄ−ｆｄ変換テーブルＴ１２の構成例について説明する。図９（ａ）は、ｆｄ−ｉノード変換テーブルＴ１１を示す。ｆｄ−ｉノード変換テーブルＴ１１には、例えば、新NAS１００が発行する複数の新ｆｄと、これら各新ｆｄに対応付けられるｉノード番号とが記憶されている。
【０１０４】
図９（ｂ）は、ｆｄ−ｆｄ変換テーブルＴ１２を示す。ｆｄ−ｆｄ変換テーブルＴ１２は、新NAS１００で発行された新ｆｄと旧NAS２００で発行された旧ｆｄとが対応付けられて記憶されている。
【０１０５】
図９（ｃ）は、ｆｄ−ｉノード変換テーブルＴ１１とｆｄ−ｆｄ変換テーブルＴ１２とを統合した変換テーブルＴ１１Ａを示す。この変換テーブルＴ１１Ａは、新NAS１００におけるｉノード番号と、新ｆｄと、旧ｆｄとがそれぞれ対応付けられている。変換テーブルＴ１１及びＴ１２の２つのテーブルを使用してもよいし、代わりに変換テーブルＴ１１Ａのみを使用してもよい。
【０１０６】
次に、本実施形態の動作を説明する。本実施例では、NFSによる場合を例に挙げて説明する。CIFSの場合は、コマンド等が若干相違するが、基本的動作はほぼ同一であると考えよい。
【０１０７】
まず、図１０は、ストレージシステムの全体動作の概要を示す。旧NAS２００によるサービスの停止から新NAS１００によるサービス再開までの手順は、例えば、以下のように行うことができる。より詳細な手順は、図１１以下でさらに説明する。
【０１０８】
例えば、夜間や休日等のような通常業務の終了後に、旧NAS２００は、サービスを停止する（Ｐ１）。次に、旧NAS２００の有するファイルツリー２０３と同一構造のファイルツリーを、新NAS１００にコピーする（Ｐ２）。ファイルツリー構造のコピーが完了した時点で、新NAS１００は、NASサービスの提供を再開する（Ｐ３）。ファイルツリー構造のコピーを完了した後、直ちに新NAS１００からNASサービスを再開可能である点は、本発明の一つの特徴である。
【０１０９】
クライアント（１０，１１）は、新NAS１００にアクセスする。新NAS１００は、クライアントからLOOKUPコマンドを受信する（Ｐ４）。クライアントは、新NAS１００に対して、ｌｓコマンドやLOOKUPコマンド等を段階的に送信しながら、新NAS１００のファイルツリー１０３をルートディレクトリから下位に向けて辿っていく（Ｐ５）。
【０１１０】
アクセス対象のファイルをクライアントが発見すると、新NAS１００は、旧NAS２００にLOOKUPコマンド等を送信し、そのアクセス対象のファイルに対応付けられている旧ｆｄを、旧NAS２００から取得する（Ｐ６）。新NAS１００は、そのアクセス対象のファイルについて、新ｆｄを発行し、クライアントに通知する（Ｐ７）。また、新NAS１００は、そのアクセス対象のファイルに関する新ｆｄと旧ｆｄとを対応付けて管理する（Ｐ８）。
【０１１１】
クライアントは、新ｆｄを指定して、ファイルへのアクセスを要求する（Ｐ９）。新NAS１００は、クライアントから受領した新ｆｄを旧ｆｄに変換し、この旧ｆｄを用いて旧NAS２００からファイルのデータを取得する（Ｐ１０）。そして、新NAS１００は、旧NAS２００から取得したファイルデータを記憶すると共に、このファイルデータをクライアントからのアクセスに提供する（Ｐ１１）。
【０１１２】
図１１は、ネットワークストレージシステムに追加された新NAS１００を立ち上げるまでの手順Ｐ１〜Ｐ３に対応する処理を示す概略フローチャートである。
【０１１３】
最初に、システム管理者等は、新NAS１００のネットワーク設定情報として、旧NAS２００に設定されているIPアドレスやサーバ名を設定する（Ｓ１１）。次に、システム管理者等は、旧NAS２００によるNASサービスを停止させる（Ｓ１２）。システム管理者等は、旧NAS２００から各クライアント１０，１１へのNASサービスを停止させた後で、ケーブルの接続を切り替える（Ｓ１３）。
【０１１４】
即ち、システム管理者等は、旧NAS２００を通信ネットワークＣＮ１から切り離すと共に、旧NAS２００と新NAS１００とを通信ネットワークＣＮ２によって直接的に接続する（Ｓ１３）。
【０１１５】
次に、新NAS１００のルートディレクトリと旧NAS２００のルートディレクトリとにそれぞれ対応付けられているファイルディスクリプタ同士を対応付けて、ｆｄ−ｆｄ変換テーブルＴ１２に登録する（Ｓ１４）。つまり、新NAS１００のルートディレクトリに対応付けられているファイルディスクリプタ（新ｆｄ（root））と旧NAS２００のルートディレクトリに対応付けられているファイルディスクリプタ（旧ｆｄ（root））とを対応付けて、ｆｄ−ｆｄ変換テーブルＴ１２に登録する。
【０１１６】
システム管理者等は、ファイルツリー構造の移行処理を開始させる。このファイルツリー構造の移行処理の詳細は、さらに後述する。先に簡単に概略を述べると、旧NAS２００は、新NAS１００に対してNASサービスを提供する（Ｓ１５）。新NAS１００は、旧NAS２００に所定のコマンドを送信することにより、そのファイルツリー構造を問合せる。新NAS１００は、旧NAS２００からの応答内容に基づいて、旧NAS２００の有するファイルツリーと同一構造のファイルツリーを生成する（Ｓ１６）。
【０１１７】
ファイルツリー構造をコピーする段階で、旧NAS２００で管理される旧ｆｄと新NAS１００で管理されるｉノード番号との対応付けも完了する（Ｓ１７）。そして、新NAS１００は、ファイルツリー構造のコピーが完了した時点で、クライアントへサービス提供を開始する。既に、新NAS１００は、旧NAS２００のネットワーク設定情報を継承しているため、クライアントは、旧NAS２００から新NAS１００に入れ替わったことを特に意識することなく、ファイルアクセスを要求する。
【０１１８】
従って、各クライアント１０，１１から見たNASサービスの停止期間は、Ｓ１１におけるNASサービスの停止時点からＳ１８におけるNASサービスの再開時点までの期間となる。つまり、実質的に、旧NAS２００から新NAS１００へのファイルツリーの移行が完了した時点で、各クライアント１０，１１に対するNASサービスが再開される。但し、新NAS１００から各クライアント１０，１１へNASサービスの提供を開始する時点では、新NAS１００は、旧NAS２００が記憶しているファイルを記憶していない。後述のように、各クライアント１０，１１が、旧NAS２００の記憶するファイルに対してファイルアクセスを要求した場合、このファイルアクセスに応じて、必要なファイルが旧NAS２００から新NAS１００へファイル単位で移行される。
【０１１９】
このように、本実施形態では、旧NAS２００が有するファイルツリー構造のみを新NAS１００に先に移行させた段階で、NASサービスを直ちに再開する。その後、各クライアント１０，１１からのアクセス要求に応じて、必要とされたファイルのみを旧NAS２００から新NAS１００へ移行させるようになっている。
【０１２０】
図１２〜図１４に基づいて、ファイルツリー構造の移行処理の一例を説明する。以下の説明では、主として、旧NAS２００に記憶されたファイル（/root/usr/dir1/file1.txt）を新NAS１００に移行させる場合を説明する。
【０１２１】
図１２は、ルートディレクトリ直下の３つのディレクトリ「usr」、「bin」、「etc」を旧NAS２００から新NAS１００へ移行させる様子を示す。まず最初に、新NAS１００は、旧NAS２００に対して、ｌｓコマンドを発行する（Ｓ２１）。ｌｓコマンドとは、ディレクトリ内のファイル一覧を要求するコマンドである。つまり、Ｓ２１では、旧NAS２００が有するファイルツリー２０３のルートディレクトリをネットワークマウントし、ｌｓコマンドを発行し、ルートディレクトリ直下の構造を調査する。以下、本明細書において、ｌｓコマンドの発行とは、旧NAS２００のルートディレクトリを新NAS１００がネットワークマウントし、特定ディレクトリに対して新NAS１００がｌｓコマンドを発行することを言う。
【０１２２】
旧NAS２００は、新NAS１００からｌｓコマンドを受信すると（Ｓ２２）、ルートディレクトリ直下に３つのディレクトリ「usr」、「bin」、「etc」が存在する旨を、新NAS１００に送信する（Ｓ２３）。
【０１２３】
新NAS１００は、旧NAS２００からのリスト応答を受信すると（Ｓ２４）、これら３つのディレクトリについて、それぞれｉノード番号を割り当てる（Ｓ２５〜Ｓ２７）。本実施例では、「usr」にｉノード番号「３」を（Ｓ２５）、「bin」にｉノード番号「４」を（Ｓ２６）、「etc」にｉノード番号「５」を（Ｓ２７）、それぞれ割り当てる。
【０１２４】
新NAS１００は、ルートディレクトリのデータ内容として、「usr,3,bin,4,etc,5」をｉノード情報管理テーブルＴ１３に登録する（Ｓ２８）。そして、図８にも示すように、新NAS１００は、ルートディレクトリのｉノード情報として、「usr,3,bin,4,etc,5」を格納した記憶先のアドレスAdr１１と、ルートディレクトリのファイルサイズとを、ｉノード情報管理テーブルＴ１３に登録する（Ｓ２９）。
【０１２５】
次に、新NAS１００は、旧NAS２００に対し、ルートディレクトリに関するGETATTRコマンドを発行する（Ｓ３０）。ここで、GETATTRコマンドとは、ファイルの属性情報を要求するコマンドである。旧NAS２００は、新NAS１００からGETATTRコマンドを受信すると（Ｓ３１）、ルートディレクトリの属性情報を読出して、新NAS１００に送信する（Ｓ３２）。
【０１２６】
新NAS１００は、旧NAS２００からルートディレクトリの属性情報を受信すると（Ｓ３３）、この属性情報をルートディレクトリのｉノード情報として、ｉノード情報管理テーブルＴ１３に登録する。ルートディレクトリの属性情報としては、例えば、「所有者」等を挙げることができる。以上の処理により、ＬＵ２０２のルートディレクトリ直下に位置する構造と同一の構造が、新NAS１００のＬＵ１０２に形成される。
【０１２７】
図１３は、ルートディレクトリ直下のディレクトリの構造をコピーする場合の処理を示すフローチャートである。この処理は、図１２で述べた処理とほぼ同様に行われる。まず最初に、新NAS１００は、ディレクトリ「usr」についてのｌｓコマンドを、旧NAS２００に発行する（Ｓ４１）。旧NAS２００は、新NAS１００からｌｓコマンドを受信すると（Ｓ４２）、ディレクトリ「usr」に含まれるファイルの一覧（dir1，dir2）を新NAS１００に送信する（Ｓ４３）。
【０１２８】
新NAS１００は、旧NAS２００からリスト応答を受信すると（Ｓ４４）、サブディレクトリ「dir1」にｉノード番号「６」を割り当て（Ｓ４５）、また、サブディレクトリ「dir2」にｉノード番号「７」を割り当てる（Ｓ４６）。そして、新NAS１００は、ディレクトリ「usr」のデータ内容として、「dir1,6,dir2,7」を記憶する（Ｓ４７）。
【０１２９】
さらに、新NAS１００は、ディレクトリ「usr」のｉノード情報として、「dir1,6,dir2,7」の格納先アドレスAdr１２とファイルサイズとをｉノード情報管理テーブルＴ１３に記憶させる（Ｓ４８）。次に、新NAS１００は、旧NAS２００に対し、「usr」に関するLOOKUPコマンドを発行する（Ｓ４９）。ここで、LOOKUPコマンドとは、ファイルディスクリプタを取得するためのコマンドである。
【０１３０】
旧NAS２００は、新NAS１００からLOOKUPコマンドを受信すると（Ｓ５０）、ディレクトリ「usr」に関連付けられているファイルディスクリプタ（旧ｆｄ（usr））を、新NAS１００に送信する（Ｓ５１）。
但し、新NAS１００上で、これ以前に行われている「ｌｓ」コマンドの結果より、旧ｆｄ（usr）の情報を得ることができる場合は、これらの手順は省略されてもよい。以下、本明細書において、新NAS１００上でLOOKUPコマンドを発行する手順は、それ以前に実行されている「ｌｓ」コマンドの結果より特定ディレクトリの旧ｆｄの情報を得られる場合には、省略することができる。
【０１３１】
新NAS１００は、旧NAS２００から「usr」のファイルディスクリプタを受信すると（Ｓ５２）、このファイルディスクリプタを用いて、ディレクトリ「usr」についてのGETATTRコマンドを発行する（Ｓ５３）。
【０１３２】
旧NAS２００は、新NAS１００からGETATTRコマンドを受信すると（Ｓ５４）、「usr」の属性情報を読出して、新NAS１００に送信する（Ｓ５５）。
【０１３３】
新NAS１００は、旧NAS２００からディレクトリ「usr」の属性情報を取得すると（Ｓ５６）、この属性情報をｉノード情報管理テーブルＴ１３の「usr」の欄に登録する（Ｓ５７）。以上のようにして、ルートディレクトリ直下に属する各ディレクトリ「usr」、「bin」、「etc」の内容を旧NAS２００からそれぞれ取得し、新NAS１００のｉノード情報管理テーブルＴ１３に登録することができる。各サブディレクトリ「dir1」、「dir2」を登録する場合も、図１３で示したと同様の方法で行われる。ｉノード情報管理テーブルＴ１３にｉノード情報が登録されることにより、旧NAS２００のファイルツリー構造が新NAS１００に移行される。
【０１３４】
図１４は、サブディレクトリ「dir1」に格納されているファイル「file1.txt」のｉノード情報をｉノード情報管理テーブルＴ１３に登録する場合のフローチャートである。このフローチャートでは、ファイルのｉノード情報のみが新NAS１００側に生成され、ファイルの実体（ファイルデータ）は新NAS１００に移行されない。後述のように、ファイルデータの移行は、各クライアント１０，１１からのアクセス要求が生じた場合に、実行される。
【０１３５】
まず、新NAS１００は、ファイル「/usr/dir1/file1.txt」についてｌｓコマンドを発行する（Ｓ６１）。つまり、ファイル「file1.txt」に属する要素（ファイルやディレクトリ）について、新NAS１００は旧NAS２００に問い合わせる。
【０１３６】
旧NAS２００は、新NAS１００からのｌｓコマンドを受信すると（Ｓ６２）、ファイル「file1.txt」の配下には何も存在しない旨を応答する（Ｓ６３）。ファイル「file1.txt」は、ファイルツリーの末端の一つであり、それより下に他のファイル等は存在しないためである。
【０１３７】
新NAS１００は、旧NAS２００からの応答を受信すると（Ｓ６４）、ファイル「file1.txt」についてLOOKUPコマンドを発行する（Ｓ６５）。旧NAS２００は、LOOKUPコマンドを受信すると（Ｓ６６）、ファイル「file1.txt」の旧ｆｄ（file1.txt）を新NAS１００に送信する（Ｓ６７）。
【０１３８】
新NAS１００は、旧ｆｄ（file1.txt）を受信すると（Ｓ６８）、このｆｄ（file1.txt）を用いて、ファイル「file1.txt」についてのGETATTRコマンドを発行する（Ｓ６９）。旧NAS２００は、新NAS１００からGETATTRコマンドを受信すると（Ｓ７０）、ファイル「file1.txt」に関する属性情報を読出して、新NAS１００に送信する（Ｓ７１）。
【０１３９】
新NAS１００は、ファイル「file1.txt」についての属性情報を受信すると（Ｓ７２）、この属性情報を、ファイル「file1.txt」のｉノード情報として、ｉノード情報管理テーブルＴ１３に登録する（Ｓ７３）。
【０１４０】
そして、新NAS１００は、ファイル「file1.txt」に対応付けられている未更新フラグを「１」に設定する（Ｓ７４）。ファイルデータの実体が新NAS１００にコピーされていない場合は、「未移行状態」であるので、未更新フラグに「１」が設定される。
【０１４１】
図１２〜図１４で述べた通り、最初に、旧NAS２００のファイルツリーと同一構造のファイルツリーが新NAS１００に形成される。この段階では、各ファイルの実体は、新NAS１００にコピーされず、旧NAS２００にのみ存在する。
【０１４２】
図１５は、各クライアント１０，１１が新NAS１００から新ｆｄを取得する際の処理概要を示すフローチャートである。なお、クライアント１０またはクライアント１１による動作を特に区別する必要がないので、「クライアント１０，１１」と表現する。
【０１４３】
処理概要を先に述べると、クライアント１０，１１がファイルまたはディレクトリにアクセスする際には、LOOKUPコマンドを用いて、アクセス対象となるファイルの新ｆｄを新NAS１００から取得し、次に、この新ｆｄを用いて更新要求（ライトアクセス）または参照要求（リードアクセス）等を発行する。もしも、アクセス対象のファイルが深い階層に位置する場合は、クライアント１０，１１は、取得できた最も最下位のディレクトリのｆｄを用いて、LOOKUPコマンドを発行する。クライアント１０，１１は、例えば、現在判明している最も下位のパスに対応するｆｄと、この最も下位のパスに属するディレクトリまたはファイル名とを指定しながら、目的とするファイルまでディレクトリ階層構造を順番に辿り、目的のファイルの新ｆｄを新NAS１００から入手する。
【０１４４】
図１５に戻る。まず最初に、クライアント１０，１１は、新NAS１００に対して、ディレクトリのファイルディスクリプタとそのディレクトリに属する所望のファイル名とを指定して、LOOKUPコマンドを発行する（Ｓ１０１）。図１５では、目的のファイルが格納されているディレクトリの新ｆｄを、クライアント１０，１１が入手しているものとして説明する。目的のファイルが格納されているディレクトリ等のｆｄが不明の場合は、上述のように、クライアント１０，１１は、新NAS１００のファイルツリー１０３をルートディレクトリから下位ディレクトリに向けて順番に辿りながら、そのファイルが直接属するディレクトリの新ｆｄを入手する。
【０１４５】
新NAS１００は、クライアント１０，１１からのLOOKUPコマンドを受信すると（Ｓ１０２）、ｉノード情報管理テーブルＴ１３を参照し（Ｓ１０３）、要求されたファイルがファイルツリー上に存在するか否かを判定する（Ｓ１０４）。
【０１４６】
クライアント１０，１１から照会されたファイルが実在しない場合（S104：NO）、新NAS１００は、存在しないファイルである旨をクライアント１０，１１に回答する（Ｓ１０５）。
【０１４７】
クライアントから照会されたファイルが新NAS１００のファイルツリー１０３上に実在する場合（S104：YES）、新NAS１００は、この要求されたファイルについて新たにファイルディスクリプタを生成する（Ｓ１０６）。新NAS１００は、生成した新ｆｄをｆｄ−ｉノード変換テーブルＴ１１に登録する（Ｓ１０７）。即ち、照会された（要求された）ファイルのｉノード番号とこのファイルについて生成された新ｆｄとを対応付けて、ｆｄ−ｉノード変換テーブルＴ１１に登録する。
【０１４８】
次に、新NAS１００は、要求されたファイルに関連付けられている未更新フラグを確認し（Ｓ１０８）、ｆｄ−ｆｄ変換テーブルＴ１２を参照する（Ｓ１０９）。新NAS１００は、クライアント１０，１１から受信したディレクトリに関する旧ｆｄが、ｆｄ−ｆｄ変換テーブルＴ１２に登録されているか否かを判定する（Ｓ１１０）。
【０１４９】
新NAS１００の運用開始当初は、旧ｆｄと新ｆｄとの対応関係が把握されていないので、要求されたファイルが属するディレクトリの旧ｆｄがｆｄ−ｆｄ変換テーブルＴ１２に登録されていないと判断される（S110：NO）。
【０１５０】
そこで、新NAS１００は、ディレクトリの旧ｆｄ及びファイル名を引数として、旧NAS２００にLOOKUPコマンドを発行する（Ｓ１１１）。即ち、Ｓ１０２において新NAS１００がクライアント１０，１１から受信したLOOKUPコマンドと同様のLOOKUPコマンドを、新NAS１００は旧NAS２００に送信する。
【０１５１】
旧NAS２００は、新NAS１００からLOOKUPコマンドを受信すると（Ｓ１１２）、新NAS１００から要求されたファイルの旧ｆｄを読出して、新NAS１００に回答する（Ｓ１１３）。
【０１５２】
新NAS１００は、旧NAS２００からファイルの旧ｆｄを受信すると（Ｓ１１４）、この旧ｆｄとＳ１０６で発行した新ｆｄとを対応付けて、ｆｄ−ｆｄ変換テーブルＴ１２に登録する（Ｓ１１５）。そして、新NAS１００は、Ｓ１０６で新たに生成した新ｆｄを、クライアント１０，１１に通知する（Ｓ１１６）。
【０１５３】
クライアント１０，１１は、新NAS１００からファイルの新ｆｄを受信すると（Ｓ１１７）、この新ｆｄをキャッシュメモリ等に記憶する（Ｓ１１８）。以後、クライアント１０，１１は、このファイルにアクセスする場合に、キャッシュした新ｆｄを指定してファイルアクセスを要求する。なお、クライアント１０，１１から指定されたディレクトリの旧ｆｄがｆｄ−ｆｄ変換テーブルＴ１２に登録済である場合（S110：YES）、Ｓ１１１，Ｓ１１４，Ｓ１１５の処理はスキップされる。
【０１５４】
このように、クライアント１０，１１から新NAS１００に対して、ファイルディスクリプタの取得要求が行われた場合、新NAS１００は、新ｆｄを生成して、クライアント１０，１１に通知する。また、新NAS１００は、旧NAS２００から旧ｆｄを取得し、この旧ｆｄと新ｆｄとを対応付けて保持する。これにより、図１６，図１７と共に述べるように、新NAS１００に移行されていないファイルへのアクセス要求が発生した場合に、新ｆｄを旧ｆｄに変換して、旧NAS２００からファイルを取得することができる。なお、この例では、クライアント１０，１１からのアクセスに応じて、旧ｆｄを旧NAS２００から取得する場合を述べたが、既に述べたように、本発明はこれに限定されず、ファイルツリー構造をコピーする際に旧ｆｄとｉノード番号とを対応付けて、旧ｆｄと新ｆｄとの対応関係を間接的に構築することもできる。これについては、さらに後述する。
【０１５５】
図１６は、クライアント１０，１１からの更新要求（WRITEコマンド）を処理する場合の概略フローチャートである。まず、クライアント１０，１１は、更新を希望するファイルの新ｆｄを指定して、WRITEコマンドを発行する（Ｓ１２１）。クライアント１０，１１は、図１５で述べた処理により、所望のファイルの新ｆｄを新NAS１００から取得している。
【０１５６】
新NAS１００は、クライアント１０，１１からWRITEコマンドを受信すると（Ｓ１２２）、ｆｄ−ｉノード変換テーブルＴ１１を参照し（Ｓ１２３）、クライアント１０，１１から要求されたファイルが実在するか否かを判定する（Ｓ１２４）。
【０１５７】
クライアント１０，１１から更新を要求されたファイルが実在しない場合（S124：NO）、新NAS１００は、要求されたファイルが存在しない旨をクライアント１０，１１に回答する（Ｓ１２５）。
【０１５８】
クライアント１０，１１から更新を要求されたファイルが実在する場合（S124：YES）、新NAS１００は、ｆｄ−ｉノード変換テーブルＴ１１に基づいて、クライアント１０，１１から指定された新ｆｄをｉノード番号に変換する（Ｓ１２６）。次に、新NAS１００は、ｉノード番号に基づいてｉノード情報管理テーブルＴ１３を参照し、更新を要求されたファイルに対応付けられている未更新フラグを確認する（Ｓ１２７）。
【０１５９】
新NAS１００は、未更新フラグの内容に基づいて、更新を要求されたファイルが新NAS１００に未移行であるか否かを判定する（Ｓ１２８）。即ち、更新を要求されたファイルの未移行フラグに「１」が設定されているか否かを判定する。更新を要求されたファイルが既に新NAS１００にコピー済の場合（S128：NO）、新NAS１００は、対象のファイルをＬＵ１０２からメモリ上に読出して、その一部または全部を更新し、再びＬＵ１０２に書き戻す（Ｓ１２９）。
【０１６０】
更新を要求されたファイルが新NAS１００に未だ移行されていない場合（S128：YES）、新NAS１００は、ｆｄ−ｆｄ変換テーブルＴ１２を参照する（Ｓ１３０）。これにより、新NAS１００は、クライアント１０，１１から指定された新ｆｄを、対応する旧ｆｄに変換する（Ｓ１３１）。即ち、新NAS１００は、更新を要求されたファイルの旧ｆｄをｆｄ−ｆｄ変換テーブルＴ１２から取得する。
【０１６１】
そして、新NAS１００は、ファイルの旧ｆｄを指定して、旧NAS２００に対し、READ命令を発行する（Ｓ１３２）。旧NAS２００は、新NAS１００からREAD命令を受信すると（Ｓ１３３）、新NAS１００から要求されたファイルの全データをＬＵ２０２から読出して、新NAS１００に送信する（Ｓ１３４）。つまり、新NAS１００は、クライアント１０，１１がファイルの一部についてのみ更新を要求している場合でも、そのファイルの全体を旧NAS２００から取得する。
【０１６２】
新NAS１００は、旧NAS２００からファイルの全データを受信すると、この受信したファイルデータの一部または全部を書き換えて更新し、ＬＵ１０２の所定の場所に格納させる（Ｓ１３５）。即ち、新NAS１００は、クライアント１０，１１からの更新要求に従ってファイルを更新し、このファイルのデータが格納されるべき位置にファイルを保存させる。ファイルデータが格納されるべき位置は、ファイルツリー構造の移行処理を完了した時点で既に決定されている。更新されたファイルデータは、新NAS１００内で、所定のディレクトリに保存される。
【０１６３】
新NAS１００は、ファイルの更新を完了した後で、この更新したファイルに対応付けられている未更新フラグを「０」に設定する（Ｓ１３６）。これにより、このファイルの移行状態は、「未移行状態」から「移行済状態」に変更される。
【０１６４】
新NAS１００は、ファイルの更新を完了した後、クライアント１０，１１に対し、ファイルの更新が完了した旨を報告する（Ｓ１３７）。クライアント１０，１１は、新NAS１００からの通知を受信し、WRITEコマンドの処理完了を知る（Ｓ１３８）。
【０１６５】
このように、本実施形態では、クライアント１０，１１からファイルの更新を要求される度に、要求されたファイルが旧NAS２００から新NAS１００にコピーされる。従って、最初の更新要求の場合は、旧NAS２００からファイルを取得する分だけ、更新要求に対する応答が低下する。しかし、新NAS１００に移行した後は、そのファイルに対する更新要求を直ちに処理することができる。
【０１６６】
図１７は、クライアント１０，１１からの参照要求（READコマンド）を処理する場合の概略フローチャートである。まず、クライアント１０，１１は、参照を希望するファイルの新ｆｄを指定して、READコマンドを発行する（Ｓ１４１）。新NAS１００は、READコマンドを受信すると（Ｓ１４２）、ｆｄ−ｉノード変換テーブルＴ１１を参照し（Ｓ１４３）、参照を要求されたファイルが実在するか否かを判定する（Ｓ１４４）。クライアント１０，１１から参照を要求されたファイルがファイルツリー１０３上に存在しない場合（S144：NO）、新NAS１００は、クライアント１０，１１に対して、要求されたファイルが存在しない旨を回答する（Ｓ１４５）。
【０１６７】
参照を要求されたファイルがファイルツリー上に存在する場合（S144：YES）、新NAS１００は、ｆｄ−ｉノード変換テーブルＴ１１に基づいて、そのファイルのｉノード番号を取得する（Ｓ１４６）。新NAS１００は、ｉノード番号に基づいて、ｉノード情報管理テーブルＴ１３を参照し、参照を要求されたファイルに対応付けられている未更新フラグを確認する（Ｓ１４７）。
【０１６８】
新NAS１００は、未更新フラグに基づいて、参照を要求されたファイルが未移行状態であるか否かを判定する（Ｓ１４８）。参照を要求されたファイルが既に新NAS１００に移行済の場合（S148：NO）、新NAS１００は、要求されたファイルをＬＵ１０２から読み出す（Ｓ１４９）。
【０１６９】
参照を要求されたファイルが新NAS１００に未だ移行されていない場合（S148：YES）、新NAS１００は、ｆｄ−ｆｄ変換テーブルＴ１２を参照し（Ｓ１５０）、クライアント１０，１１から指定された新ｆｄを旧ｆｄに変換する（Ｓ１５１）。
【０１７０】
そして、新NAS１００は、旧ｆｄを指定して旧NAS２００にREADコマンドを発行する（Ｓ１５２）。旧NAS２００は、新NAS１００からのREADコマンドを受信すると（Ｓ１５３）、新NAS１００から要求されたファイルの全データをＬＵ２０２から読出して、新NAS１００に送信する（Ｓ１５４）。
【０１７１】
新NAS１００は、旧NAS２００からファイルの全データを受信すると、このデータを更新し、所定の場所に記憶させる（Ｓ１５５）。即ち、新NAS１００は、旧NAS２００から取得したファイルデータを、ＬＵ１０２に形成されるファイルツリー１０３の所定の格納位置に保存する。更新要求の場合と同様に、新NAS１００は、クライアント１０，１１からファイルの一部についてのみ参照を要求された場合でも、そのファイルの全体を旧NAS２００から取得し、ＬＵ１０２の所定の場所に格納する。これにより、そのファイルは旧NAS２００から新NAS１００に移行されたことになる。
【０１７２】
新NAS１００は、そのファイルに対応付けられている未更新フラグを「０」に設定し、「未移行状態」から「移行済状態」に変更する（Ｓ１５６）。そして、新NAS１００は、クライアント１０，１１に対し、参照を要求されたファイルデータの一部または全部を送信し、READコマンドの処理完了を通知する（Ｓ１５７）。クライアント１０，１１は、新NAS１００からファイルのデータを受信し、また、READコマンドの処理完了を確認する（Ｓ１５８）。
【０１７３】
このように、本実施形態では、更新要求の処理で述べたと同様に、クライアント１０，１１から参照を要求される度に、要求されたファイルが旧NAS２００から新NAS１００にコピーされる。従って、最初の参照要求の場合は、旧NAS２００からファイルを取得する分だけ、参照要求に対する応答が低下する。しかし、新NAS１００に移行した後は、そのファイルに対する参照要求を直ちに処理できる。
【０１７４】
本実施例は上述のように構成されるので、以下の効果を奏する。本実施例では、まず最初に、旧NAS２００が有するファイルツリー２０３と同一構造のファイルツリーを新NAS１００に生成した時点でNASサービスを再開し、次に、クライアント１０，１１から新NAS１００へのファイルアクセス要求に基づいて、要求されたファイルを旧NAS２００から新NAS１００に段階的に移行させる構成とした。従って、NASサービスの停止時間を短くして、旧NAS２００から新NAS１００へ移行させることができ、NASの置換を容易に行うことができる。
【０１７５】
また、本実施例では、新NAS１００において、新ｆｄと旧ｆｄとの対応付け等を行う構成とした。従って、旧NAS２００に何ら特別な機能を追加することなく、新NAS１００のみでネットワークストレージの移行（置換）を行うことができる。
【０１７６】
さらに、本実施例では、旧NAS２００の記憶するファイルデータを一切変更することなく、移行前の記憶内容を保持した状態で、旧NAS２００から新NAS１００にファイルデータを移行させる構成とした。即ち、例えば、図１６と共に述べた更新要求処理では、ファイルデータの更新は、新NAS１００側でのみ行われ、旧NAS２００の記憶内容に変化は生じない。旧NAS２００から新NAS１００へ移行する際に、新NAS１００は、旧NAS２００に対して参照要求のみを行うようになっている。従って、移行前のデータ（旧NAS２００が保持するファイル群）を破壊することなく、旧NAS２００から新NAS１００への移行処理（置換処理）を行うことができる。従って、不測の事態に備えて、移行開始前に旧NAS２００の記憶内容を予めバックアップしておく必要がなく、旧NAS２００から新NAS１００への置換作業を比較的簡単に行うことができる。
【０１７７】
また、本実施例では、クライアント１０，１１から旧ｆｄを指定してファイルアクセスが要求された場合に、この要求されたファイルに対応する新たなｆｄを新NAS１００から発行させると共に、旧ｆｄと新ｆｄとの対応関係を新NAS１００内で保持する構成とした。そして、クライアント１０，１１からのファイルアクセス要求が発生した場合に、対象のファイルを旧NAS２００から新NAS１００に移行させる構成とした。従って、クライアント１０，１１は、新ｆｄを指定して新NAS１００にアクセスするだけで、所望のファイルにアクセスすることができ、また、そのファイルアクセスによって、所望のファイルを旧NAS２００から新NAS１００に移行させることができる。
【０１７８】
また、本実施例では、クライアント１０，１１から旧ファイルツリーへのアクセス要求に応じて、旧ｆｄと新ｆｄとの対応関係を徐々に構築する構成とした。従って、クライアント１０，１１が必要とする範囲内でファイル群の移行準備を整えることができる。
【実施例２】
【０１７９】
図１８〜図１９に基づいて、第２実施例を説明する。本実施例の特徴は、旧NAS２００から新NAS１００へファイルツリー構造を移行する際に、旧ｆｄと新ｆｄとの対応関係の構築を開始する点にある。
【０１８０】
図１８は、本実施例の全体動作の手順を示す概略フローチャートである。図１０に示す全体動作と、Ｐ２３，Ｐ２８の点で相違する。Ｐ２１，Ｐ２２は図１０中のＰ１，Ｐ２に、Ｐ２４〜Ｐ２７は図１０中のＰ３〜Ｐ７に、Ｐ２９〜Ｐ３１は図１０中のＰ９〜Ｐ１１に、それぞれ対応するので重複した説明を割愛する。
【０１８１】
Ｐ２３では、ファイルツリー構造を旧NAS２００から新NAS１００にコピーする際に、旧NAS２００で管理される旧ｆｄと新NAS１００で管理されるｉノード番号とを対応付けて保存する。そして、Ｐ２８では、クライアント１０，１１がファイルツリーを上位ディレクトリから下位ディレクトリに向けて順番に辿る過程で発行される新ｆｄとｉノード番号とを対応付ける。これにより、旧ｆｄと新ｆｄとはｉノード番号を介して関連付けられる。
【０１８２】
図１９及び図２０を参照して、より詳細に説明する。まず最初に、図１９のフローチャートは、旧NAS２００から新NAS１００へファイルツリー構造を移行する際の処理の一部であり、図１３に示すフローチャートに対応する。即ち、図１３中のＳ４１〜Ｓ５２は、図１９中のＳ１６１〜Ｓ１７２にそれぞれ対応する。同様に、図１３中のＳ５４〜Ｓ５７は、図１９中のＳ１７５〜Ｓ１７８にそれぞれ対応する。対応する各ステップの説明は省略する。
【０１８３】
図２０のフローチャートは、図１９と同様のファイルツリー構造移行処理の一部であり、図１４に示すフローチャートに対応する。即ち、図１４中のＳ６１〜Ｓ６８は、図２０中のＳ１８１〜Ｓ１８８にそれぞれ対応する。同様に、図１４中のＳ６９〜Ｓ７４は、図２０中のＳ１９０〜Ｓ１９５にそれぞれ対応する。なお、対応する各ステップの説明は省略する。説明の便宜のため、ディレクトリ「usr」及びファイル「fie1.txt」の移行を例示するが、これ以外のディレクトリやファイルの場合も同様に処理される。
【０１８４】
本実施例に特徴的なステップであるＳ１７３，Ｓ１８９では、旧NAS２００から取得した旧ｆｄを、新NAS１００におけるｉノード番号に対応付けて、保持する。つまり、図９（ｃ）と共に述べたように、ｆｄ−ｉノード変換テーブルとｆｄ−ｆｄ変換テーブルとを統合して扱うことができるが、新NAS１００におけるｉノード番号に、そのｉノード番号に対応する旧ｆｄを予め対応付けて保持しておく。そして、クライアント１０，１１からの要求に応じて新ｆｄが発行された場合に、この新ｆｄと予め保持しておいた旧ｆｄとを対応付けて記憶する。
【実施例３】
【０１８５】
図２１，図２２に基づいて、第３実施例を説明する。本実施例の特徴は、クライアントからのファイルアクセスに応じて、旧NAS２００から新NAS１００にファイルツリー構造をコピーさせると共に、旧ｆｄと新ｆｄとの対応関係を構築する点にある。即ち、本実施例では、クライアント１０，１１が稼働状態の場合に旧NAS２００から新NAS１００への移行を可能としている。
【０１８６】
図２１は、本実施例による全体処理の概要を示すフローチャートである。まず、新NAS１００は、旧NAS２００のネットワーク設定情報を継承し（Ｓ２０１）、旧NAS２００は、クライアント１０，１１へのサービス提供を停止する（Ｓ２０２）。そして、システム管理者は、旧NAS２００と新NAS１００とを直接的に接続し（Ｓ２０３）、旧NAS２００から新NAS１００にNASサービスを提供させる（Ｓ２０４）。
【０１８７】
新NAS１００は、旧NAS２００のルートディレクトリと新NAS１００のルートディレクトリとを対応付ける（Ｓ２０５）。そして、新NAS１００は、クライアント１０，１１へのサービス提供を開始し、クライアント１０，１１からのファイルアクセス要求に応じて、要求された範囲内でファイルツリー構造をコピーすると共に、ファイルのデータを移行させる。即ち、本実施例では、クライアント１０，１１からのアクセスに同期して、新NAS１００は旧NAS２００にアクセスし、必要なデータや属性等を入手する。
【０１８８】
図２２は、クライアント１０，１１から新NAS１００へのアクセス動作と、新NAS１００から旧NAS２００へのアクセス動作とが同期している様子を部分的に示すフローチャートである。
【０１８９】
まず、新NAS１００は、新NAS１００のルートディレクトリの新ｆｄと旧NAS２００のルートディレクトリの旧ｆｄとを対応付けておく（Ｓ２１１）。クライアントの稼働中に、旧NAS２００から新NAS１００に入れ替わっているため、クライアントは、旧ｆｄを用いてファイルへのアクセスを要求する（Ｓ２１２）。
【０１９０】
新NAS１００は、旧ｆｄを解釈することができないため、このファイルアクセス要求をリジェクトし、クライアントにリトライアクセスを要求する（Ｓ２１３）。新NAS１００からの通知を受けたクライアントは、ルートディレクトリから目的のファイルに向けて、ファイルツリーを順番に辿っていく。
【０１９１】
クライアントは、新NAS１００に対し、ルートディレクトリについてｌｓコマンドを発行する（Ｓ２１４）。新NAS１００は、クライアントからの要求に同期して、ルートディレクトリに関するｌｓコマンドを旧NAS２００に送信する（Ｓ２１５）。
【０１９２】
旧NAS２００は、新NAS１００からコマンドを受信すると、ルートディレクトリ直下の構成について、新NAS１００に応答する（Ｓ２１６）。新NAS１００は、旧NAS２００からの応答に基づいて、この応答内容に含まれる範囲内でファイルツリーを形成する（ｉノード情報管理テーブルを更新する）（Ｓ２１７）。そして、新NAS１００は、自身のファイルツリー１０３のルートディレクトリ直下の構成について、クライアントに応答する（Ｓ２１７）。ここで、留意すべきは、新NAS１００は、旧NAS２００からの応答内容をそのままクライアントに転送するのではなく、旧NAS２００からの応答内容に基づいて更新された新NAS１００のツリー構成について応答している点である。
【０１９３】
次に、クライアントは、ルートディレクトリ下にある”usr”ディレクトリに関して、新NAS１００に問い合わせる（Ｓ２１８）。この問合せを受けた新NAS１００は、旧NAS２００に、”usr”ディレクトリ下の構成を問い合わせる（Ｓ２１９）。旧NAS２００が”usr”ディレクトリ下の構成について応答すると（Ｓ２２０）、新NAS１００は、ファイルツリー１０３をさらに構築し、ｉノード情報を更新する（Ｓ２２１）。また、新NAS１００は、更新した情報に基づいて、”usr”ディレクトリ下の構成についてクライアントに応答する（Ｓ２２１）。
【０１９４】
クライアントは、”usr”ディレクトリのｆｄを要求する（Ｓ２２２）。新NAS１００は、このクライアントからのｆｄ要求に同期して、”usr”の旧ｆｄを旧NAS２００に要求する（Ｓ２２３）。旧NAS２００が”usr”の旧ｆｄを新NAS１００に通知すると（Ｓ２２４）、新NAS１００は、”usr”の新ｆｄを生成すると共に、この新ｆｄと旧ｆｄとを対応付けて保存する（Ｓ２２５）。そして、新NAS１００は、”usr”の新ｆｄをクライアントに通知する（Ｓ２２５）。
【０１９５】
クライアントは、新ｆｄ”usr”を指定し、”usr”ディレクトリの属性情報の取得を新NAS１００に要求する（Ｓ２２６）。新NAS１００は、クライアントからの要求を受信すると、旧NAS２００に”usr”の属性情報を要求する（Ｓ２２７）。この属性情報の要求に際して、新ｆｄ”usr”は旧ｆｄ”usr”に変換される。
【０１９６】
旧NAS２００は、新NAS１００からの要求に応じて、”usr”の属性情報を読出し、新NAS１００に送信する（Ｓ２２８）。新NAS１００は、旧NAS２００から受信した属性情報に基づいて、ｉノード情報を更新する（Ｓ２２９）。そして、新NAS１００は、この更新された”usr”の属性情報をクライアントに送信する（Ｓ２２９）。
【０１９７】
続いて、クライアントは、”usr”ディレクトリ下に存在する”dir1”ディレクトリについて、新NAS１００に問い合わせる（Ｓ２３０）。新NAS１００は、クライアントからの問合せ要求を受信すると、旧NAS２００に対し、”dir1”ディレクトリ下の構成を問い合わせる（Ｓ２３１）。
【０１９８】
旧NAS２００は、新NAS１００からの問合せに応じて、”dir1”ディレクトリ下の構成を応答する（Ｓ２３２）。新NAS１００は、旧NAS２００からの応答内容に基づいて、ｉノード情報を更新し、ファイルツリーを構築する（Ｓ２３３）。
【０１９９】
以上の処理は、クライアントが目的のファイルを発見するまで繰り返される。クライアントがファイルに到達すると、新NAS１００は旧NAS２００からファイルのデータや属性を読出し、これらの情報を記憶すると共に、クライアントに提供する。
【０２００】
このように、クライアントがファイルツリーを上位ディレクトリから下位に向けて順番に辿っていく過程に同期して、新NAS１００は、旧NAS２００のファイルツリーを上位ディレクトリから下位に向けて順番に辿る。そして、新NAS１００は、このファイルツリーを辿る過程で、旧ｆｄと新ｆｄとの対応関係を構築し保持する。従って、本実施例では、クライアントが稼働中の状態において、クライアントから要求された範囲内で、ファイルツリーをコピーすると共に、旧ｆｄと新ｆｄとの対応付けを行うことができる。
【０２０１】
クライアントからの要求に同期してファイルツリーのコピー等を行うため、新NAS１００の負荷は増大する。しかし、クライアントが特定のファイルまたはファイル群にアクセスするような場合、その使用されるファイルまたはファイル群について、先行してデータ移行を完了させることができる。
【実施例４】
【０２０２】
図２３に基づいて、第４実施例を説明する。本実施例は、クライアントが新NAS１００のファイルツリー１０３を上位ディレクトリから下位に向けて順番に辿る場合の詳細を示す。
【０２０３】
クライアントがファイルへのアクセスを行う場合、所望のファイルを特定するための新ｆｄを入手済みであるか否かを判定する（Ｓ２４１）。既に入手済みの場合（S241：YES）、図１６や図１７で述べたように、所望のファイルの新ｆｄを指定して、ライトアクセスやリードアクセスを行うことができる（Ｓ２４２）。
【０２０４】
これに対し、所望のファイルの新ｆｄを未入手の場合（S241：NO）、クライアントは、現在判明している最も下位のパスの新ｆｄと、そのパスの下にあるディレクトリ名とを指定して、LOOKUPコマンドを発行する（Ｓ２４３）。最初の時点では、ルートディレクトリの新ｆｄのみが判明しているので、クライアントは、ルートディレクトリの新ｆｄ及びルートディレクトリ下にあるディレクトリ名”usr”を指定して、新NAS１００に問い合わせる。
【０２０５】
新NAS１００は、ルートディレクトリの新ｆｄを旧ｆｄに変換し（Ｓ２４４）、ルートディレクトリの旧ｆｄとディレクトリ名”usr”とを指定して、旧NAS２００に問い合わせる（Ｓ２４５）。
【０２０６】
旧NAS２００は、新NAS１００からの問合せに応じて、”usr”ディレクトリの旧ｆｄを通知する（Ｓ２４６）。新NAS１００は、”usr”ディレクトリの旧ｆｄを用いて、READDIRコマンドを発行する（Ｓ２４７）。
【０２０７】
旧NAS２００は、READDIRコマンドを受信すると、”usr”ディレクトリ下の構成を応答する（Ｓ２４８）。新NAS１００は、旧NAS２００からの応答に基づいて、ｉノード情報を更新する（Ｓ２４９）。また、新NAS１００は、”usr”ディレクトリについて、属性情報の取得を要求する（Ｓ２５１）。旧NAS２００は、属性情報の取得要求に応じて、”usr”ディレクトリの属性情報を新NAS１００に送信する（Ｓ２５２）。
【０２０８】
新NAS１００は、旧NAS２００からの応答内容に基づいてｉノード情報を更新し（Ｓ２５３）、”usr”ディレクトリを特定するための新ｆｄを生成する（Ｓ２５４）。そして、新NAS１００は、この新ｆｄと旧ｆｄとを対応付けて保存した後（Ｓ２５５）、”usr”ディレクトリの新ｆｄをクライアントに通知する（Ｓ２５６）。
【０２０９】
新ｆｄを受領したクライアントは、”usr”ディレクトリの新ｆｄ及び”usr”ディレクトリ下にあるディレクトリ名（”dir1”）とを指定し、再びLOOKUPコマンドを送信する（Ｓ２４３）。以上の処理を、目的のファイルの新ｆｄを入手するまで繰り返し、目的のファイルの新ｆｄを入手した場合は、Ｓ２４２に移る。
【実施例５】
【０２１０】
次に、図２４は、第５実施例に係わるファイル更新処理の概略を示すフローチャートである。図２４に示すフローチャートは、図１７中のＳ１５５の変形例に相当する。本実施例の特徴は、ファイルの利用頻度を考慮して、旧NAS２００から新NAS１００への移行を制御するようにした点にある。
【０２１１】
図１７に示す例では、クライアント１０，１１からファイル参照要求があった場合に、要求されたファイルの全データを旧NAS２００から新NAS１００にコピーし、新NAS１００内で更新記憶させる構成とした。
【０２１２】
これに対し、図２４に示すファイル更新処理では、新NAS１００は、旧NAS２００からファイルの全データを取得した後（Ｓ２６１）、この取得したファイルの更新時刻を確認する（Ｓ２６２）。そして、新NAS１００は、ファイルの更新時刻に基づいて、そのファイルを更新記憶するか否か、即ち、そのファイルを新NAS１００のＬＵ１０２に保持させるか否かを判定する（Ｓ２６３）。旧NAS２００から取得したファイルを更新記憶させる場合（S263：YES）、新NAS１００は、取得したファイルの全体をＬＵ１０２に記憶させる（Ｓ２６４）。
【０２１３】
ここで、ファイルの更新時刻に基づいてファイルの更新記憶（新NASへの移行）を行うか否かを判定する条件としては、場合に応じて種々のものを採用可能である。例えば、クライアント１０，１１から参照を要求されたファイルの更新時刻が、３年前や５年前等のように、所定時間更新されていないような場合は、旧NAS２００から新NAS１００への移行を行わないように構成できる。従って、所定時間以上更新されず、専ら参照のみされるファイルは、参照要求が発生する度に、旧NAS２００から毎回読み出されて、クライアント１０，１１に提供される。
【０２１４】
このように、ファイルの利用頻度が低い場合は、そのファイルを旧NAS２００に残しておく。これにより、利用頻度の低いファイルが新NAS１００にコピーされるのを未然に防止し、新NAS１００の記憶資源（ＬＵ１０２）を効率的に使用できる。この結果、旧NAS２００から新NAS１００への移行に伴って、不要なファイルを自然に淘汰することができ、ユーザ使用量の割当て管理（QUOTA）等を適切に行うことができる。
【０２１５】
なお、クライアント１０，１１がそのファイルを必要とする場合は、参照要求ではなく、更新要求を発行すればよい。クライアント１０，１１がファイルの更新を要求することにより、そのファイルは新NAS１００にコピーされる。
【実施例６】
【０２１６】
図２５は、第６実施例に係るファイル更新処理を示す。本実施例の特徴は、ファイルの利用頻度を測る指標として、そのファイルを利用する共有ホスト数（クライアント数）を考慮する点にある。
【０２１７】
このファイル更新処理では、新NAS１００は、旧NAS２００からファイルの全データを取得した後（Ｓ２７１）、この取得したファイルを利用している共有ホスト数を確認する（Ｓ２７２）。そして、新NAS１００は、共有ホスト数に基づいて、そのファイルを更新記憶するか否か、即ち、そのファイルを新NAS１００のＬＵ１０２に保持させるか否かを判定する（Ｓ２７３）。旧NAS２００から取得したファイルを更新記憶させる場合（S273：YES）、新NAS１００は、取得したファイルの全体をＬＵ１０２に記憶させる（Ｓ２７４）。
【０２１８】
例えば、そのファイルを共有するクライアントの数が予め設定された所定値よりも少ない場合には、そのファイルを新NAS１００へコピーしないようにすることができる。
【０２１９】
なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、各実施例を適宜組み合わせることができる。
【０２２０】
例えば、ファイル識別情報としてファイルディスクリプタを例に挙げたが、これに限らず、ファイルハンドル等の他の識別情報を用いてもよい。また、上記実施形態では、主としてNFSの場合を説明したが、本発明はCIFS等の場合でも適用可能である。CIFSの場合は、ｉノードの代わりに、ｉノードの集合体に相当するMFT（Master File Table）を用いることができる。MFTは、ファイルの実位置を特定するためのマップである。
【０２２１】
また、ファイルの利用頻度を測る指標として、最終更新時刻からの経過時間や共有ホスト数を例示したが、これに限らず、単位時間当たりのアクセス数等を用いてもよく、あるいは、更新時刻からの経過時間、共有ホスト数、単位時間当たりのアクセス数等のような複数の指標を適宜組み合わせてもよい。
【０２２２】
なお、新NAS上に形成されるｆｄ−ｆｄ変換テーブルは、旧NASから新NASにファイルのデータまで完全に移行した場合、不要となる。即ち、旧NASから新NASにファイル群が完全に移行した場合は、ｆｄ−ｆｄ変換テーブルを削除することができる。不要なｆｄ−ｆｄ変換テーブルを削除することにより、オーバーヘッドを解消し、性能劣化を防止することができる。
【図面の簡単な説明】
【０２２３】
【図１】本発明の実施形態の概念を示す説明図である。
【図２】図１に続く本発明の実施形態の概念を示す説明図である。
【図３】ネットワークストレージのハードウェア構造に着目した概略ブロック図である。
【図４】ネットワークストレージのソフトウェア構造に着目した概略ブロック図である。
【図５】ネットワークストレージシステムの全体構造を示す概略ブロック図である。
【図６】旧NASのファイルツリーを新NASに移行する様子を模式的に示す説明図である。
【図７】旧NASにおいて、ｉノード情報によりファイルデータにアクセスする様子を示す説明図である。
【図８】新NASにおいて、ｉノード情報によりファイルデータにアクセスする様子を示す説明図である。
【図９】新NASに記憶される各種テーブルの概略構造を示す説明図であって、（ａ）はｆｄ−ｉノード変換テーブルを、（ｂ）はｆｄ−ｆｄ変換テーブルを、（ｃ）はｆｄ−ｉノード変換テーブルとｆｄ−ｆｄ変換テーブルとを統合したテーブルを、それぞれ示す。
【図１０】ストレージシステムの全体動作の概略を示すフローチャートである。
【図１１】ネットワークストレージシステムに追加された新NASを立ち上げる手順を示す概略フローチャートである。
【図１２】旧NASのファイルツリーと同一構造のファイルツリーを新NASに生成する様子を示すフローチャートであり、ルートディレクトリ直下の構造をコピーする様子を示す。
【図１３】図１２と同様のファイルツリー移行を示すフローチャートであり、ディレクトリの構造をコピーする様子を示す。
【図１４】図１２と同様のファイルツリー移行を示すフローチャートであり、ファイルの構造をコピーする様子を示す。
【図１５】新NASからクライアントに新たなファイルディスクリプタを発行する様子を示すフローチャートである。
【図１６】クライアントからの更新要求を処理する様子を示すフローチャートである。
【図１７】クライアントからの参照要求を処理する様子を示すフローチャートである。
【図１８】第２実施例によるストレージシステムの全体動作の概略フローチャートである。
【図１９】ファイルツリー構造をコピーしながら、旧ｆｄと新ｆｄとを対応付ける変換テーブルを生成する様子を示すフローチャートである。
【図２０】図１９と同様のフローチャートであり、ファイル構造をコピーする様子を示す。
【図２１】第３実施例に係るストレージシステムの概略フローチャートである。
【図２２】クライアントからの要求に同期して新NASが旧NASから情報を取得する様子を示すフローチャートである。
【図２３】第４実施例に係り、クライアントが新NASのファイルツリーを順番に辿りながら新ｆｄを取得する様子を示すフローチャートである。
【図２４】第５実施例に係り、ファイルの更新が所定時間以上行われた場合に、旧NASから新NASにファイルを移行させる様子を示すフローチャートである。
【図２５】第６実施例に係り、ファイルの共有ホスト数が所定値以上の場合に、旧NASから新NASにファイルを移行させる様子を示すフローチャートである。
【符号の説明】
【０２２４】
１０，１１…クライアント、１２…通信インターフェース、２０…ネットワークストレージ、３０…制御部、３１…CPU、３２…RAM、３３…ROM、３４〜３６…通信インターフェース、４０…記憶部、４１…記憶デバイス、５１…ネットワークプロトコル層、５２，５３…ファイルアクセスプロトコル層、５４…ファイルシステム、５５…論理ボリュームマネージャ、５６…デバイスドライバ群、５７…論理ボリューム、１００…新NAS、１０１…ファイルシステム、１０２…論理ボリューム（移行先ボリューム）、１０３…ファイルツリー、１１０…管理部、１１１…ｆｄ−ｉノード変換部、１１２…ｆｄ−ｆｄ変換部、１１３…ｉノード情報管理部、１２０…ファイルツリー生成部、１３０…アクセス要求処理部、１３１…旧ｆｄ取得部、１３２…新ｆｄ発行部、１３３…移行状態判定部、１３４…ファイル移行部、２００…旧NAS、２０１…ファイルシステム、２０２…論理ボリューム（移行元ボリューム）、ＣＮ…通信ネットワーク、ｆｄ…ファイルディスクリプタ、Ｔ１１…ｆｄ−ｉノード変換テーブル、Ｔ１２…ｆｄ−ｆｄ変換テーブル、Ｔ１３…ｉノード情報管理テーブル
【図１】
2006039814.tif 000003
【図２】
2006039814.tif 000004
【図３】
2006039814.tif 000005
【図４】
2006039814.tif 000006
【図５】
2006039814.tif 000007
【図６】
2006039814.tif 000008
【図７】
2006039814.tif 000009
【図８】
2006039814.tif 000010
【図９】
2006039814.tif 000011
【図１０】
2006039814.tif 000012
【図１１】
2006039814.tif 000013
【図１２】
2006039814.tif 000014
【図１３】
2006039814.tif 000015
【図１４】
2006039814.tif 000016
【図１５】
2006039814.tif 000017
【図１６】
2006039814.tif 000018
【図１７】
2006039814.tif 000019
【図１８】
2006039814.tif 000020
【図１９】
2006039814.tif 000021
【図２０】
2006039814.tif 000022
【図２１】
2006039814.tif 000023
【図２２】
2006039814.tif 000024
【図２３】
2006039814.tif 000025
【図２４】
2006039814.tif 000026
【図２５】
2006039814.tif 000027
【手続補正書】
【提出日】平成16年9月21日(2004.9.21)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００５４
【補正方法】変更
【補正の内容】
【００５４】
第２のネットワークストレージ２は、ファイルを所定場所４Ｂに格納すると共に、そのファイルのデータをクライアント３に送信する。従って、クライアント３からは、第２のネットワークストレージ２に対するｆｄ２（file）の指定によって、所望のファイルを取得できたように見える。第２のネットワークストレージ２と第１のネットワークストレージ１との間のやり取りは、クライアント３に対して隠されている。