WO2015173901A1

WO2015173901A1 - 情報システム

Info

Publication number: WO2015173901A1
Application number: PCT/JP2014/062787
Authority: WO
Inventors: 周作三輪; 信之雑賀; 蟹江　誉
Original assignee: 株式会社日立製作所
Priority date: 2014-05-14
Filing date: 2014-05-14
Publication date: 2015-11-19
Also published as: US9489393B2; US20160259808A1

Abstract

　本発明の情報システムは、ローカルファイルサーバとクライアントを有する複数の拠点と、センターファイルサーバを備えたデータセンタとで構成される。ユーザが、いずれかの拠点のクライアントを用いてローカルファイルサーバのファイルを使用した後、別拠点への移動を開始すると、ローカルファイルサーバでは、各ユーザの位置情報に基づいて、別拠点への到着予測時間が最も短いユーザのファイルを優先的にセンターファイルサーバへとレプリケーションする。また、各拠点では、ユーザの位置情報に基づき、自拠点への到着予測時間が短いユーザのファイルのダウンロードを実施する。

Description

情報システム

　本発明は、通信ネットワークに接続されるファイルサーバを含む情報システムに関する。

　従来、ファイルサーバに格納されたユーザのファイルにアクセスする際には、ファイルサーバの設置されている拠点内のクライアントコンピュータからアクセスする形態が主流であった。しかし、近年では、インターネットの普及に伴い、遠隔地からインターネット経由で、ファイルサーバのデータを利用する形態が広まりつつある。

　遠隔地からインターネット経由で、ファイルサーバにアクセスする場合、ファイルサーバのファイルにアクセスしたいユーザは、インターネットというスループットの保証されていないネットワークを介して、ファイルサーバにアクセスしなければならない。そのため、ネットワークの状態によっては、ユーザがファイルにアクセスする際の応答時間が長くなることがあるという問題がある。

　かかる問題を解決するため、特許文献１には、ネットワーク上で相互接続された複数のファイルサーバとデータ管理センタから成るデータ配送システムにおいて、ユーザの移動に追従して、複数のファイルサーバのうちユーザ近くのファイルサーバに対して、ユーザの使用するファイルを自動的に配送するデータ配送システムの技術が開示されている。特許文献１に開示のデータ配送システムでは、データ管理センタがユーザの所持する位置情報端末から位置情報を取得し、取得した位置情報に基づいて、ユーザの最寄りのファイルサーバにデータを配送するようにしている。これにより、ユーザは使用したいファイルを即座に利用できるという利点がある。

特開２００３－６０７１号公報

　特許文献１に記載のシステムでは、ユーザの移動に伴って、ファイルサーバ間でのファイル転送が発生する。データ配送システムを使用する利用者が多数存在し、各利用者が頻繁に拠点を移動する環境では、そのデータ転送量は多大なものになる。

　転送対象のデータが多量にある場合、単位時間あたりに転送可能なデータ量には限りがあるため、転送対象のファイルに優先付けが必要となる。最も簡便な優先付けの方法として、たとえば最初に拠点の移動を開始した利用者のファイルから順に、移送する方法が考えられる。

　ただし、各利用者の移動速度、移動距離は様々であるため、２番目以降に拠点の移動を開始した利用者が、最初に拠点の移動を開始した利用者よりも先に移動先拠点に到着し、移動先拠点においてファイルの利用を開始することもあり得る。この場合、最初に拠点の移動を開始した利用者のファイル移送を優先して行っていると、２番目以降に拠点の移動を開始した利用者のファイル転送が遅れ、２番目以降に拠点の移動を開始した利用者が、移動先拠点でファイルアクセスするまでの間に、ファイルが移動先拠点に到着していない事態が発生し得る。その場合、利用者は移動先拠点ファイルが配送されて来るまで、ファイルを参照できないという問題が発生する。

　そこで、本発明は、ファイルの配送順序を適切に制御することのできる技術を提供することを目的とする。

　本発明の一観点に係る情報システムは、ローカルファイルサーバとクライアントを有する複数の拠点と、センターファイルサーバを備えたデータセンタとで構成される。ユーザが、いずれかの拠点のクライアントを用いてローカルファイルサーバのファイルを使用した後、別拠点への移動を開始すると、ローカルファイルサーバでは、各ユーザの位置情報に基づいて、別拠点への到着予測時間が最も短いユーザのファイルを優先的にセンターファイルサーバへとレプリケーションする。また、各拠点では、ユーザの位置情報に基づき、自拠点への到着予測時間が短いユーザのファイルのダウンロードを実施する。

　さらに本発明の一観点に係る情報システムでは、各拠点のローカルファイルサーバは、ユーザが拠点のローカルファイルサーバにログインする確率に基づいて、各ユーザのファイルダウンロード量を決定する。

　本発明によると、ある拠点のファイルサーバで更新されたファイルを、ユーザの拠点間移動に伴って、適切に移動先拠点のファイルサーバに適切に格納させることができる。

図１は、本発明の実施例に係る情報システムのハードウェア構成図である。図２は、本発明の実施例に係る情報システムのソフトウェア構成図である。図３は、本発明の実施例に係る情報システムで行われる処理の概要を示す図である。図４は、ローカルファイルサーバ、センターファイルサーバのメモリに格納される各種管理情報を示した図である。図５は、ｉｎｏｄｅの構成を示す図である。図６は、Ｅｄｇｅ位置情報テーブルの構成を示す図である。図７は、位置情報推移保持テーブルの構成を示す図である。図８は、ログイン日時テーブル及びログオフ日時テーブルの構成を示す図である。図９は、近接判定履歴テーブルの構成を示す図である。図１０は、ログイン確率テーブルの構成を示す図である。図１１は、ファイル利用履歴テーブルの構成を示す図である。図１２は、レプリケーション／スタブ化処理のフローチャートである。図１３は、レプリケーション優先順位決定処理のフローチャートである。図１４は、事前ダウンロード処理のフローチャートである。図１５は、レプリケーション対象リストの構成を示す図である。

　以下、本発明の実施例について、図面を用いて説明する。

　いくつかの実施例について、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

　なお、以後の説明では「ａａａテーブル」等の表現にて本発明の情報を説明する場合があるが、これら情報は、テーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。また、「ｂｂｂ名」等の表現にて本発明の「ｂｂｂ」を識別するための情報を説明する場合があるが、これらの識別するための情報は、名前に限られず、識別子や識別番号、アドレスなど、「ｂｂｂ」が特定できる情報であればよい。

　また、以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサ（典型的にはＣＰＵ（Central　Processing　Unit））によって実行されることで、定められた処理をメモリ及びＩ／Ｆ（インタフェース）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は、ファイルサーバ（例えば、後述のローカルファイルサーバ、センターファイルサーバ）が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。記憶メディアとしては、例えば、ＩＣカード、ＳＤカード、ＤＶＤ等であってもよい。

　ここで、以下で説明する実施例で用いられる各種用語について説明する。「Ｃｏｒｅ」とは、リモートの計算機システムを含んだ拠点（集約拠点）であり、例えば、サーバやストレージ装置を一括管理する拠点やクラウドサービスを提供する拠点である。「Ｅｄｇｅ」とは、ローカルの計算機システムを含んだ拠点であり、例えば、支店、営業所、リモートオフィスなどユーザが実際に業務を行う拠点である。「スタブ」とは、ファイルの格納先情報（リンク先を表す情報）が関連付けられたオブジェクト（メタデータ）である。「スタブ化」とは、Ｅｄｇｅ（Ｅｄｇｅの計算機システム）のファイルについて、実際のデータ（実データ）を削除し、管理情報のみを保持した状態にすることをいう。スタブ化されたファイルは、実データを保持していないため、アクセスされるとＣｏｒｅの計算機システムから実データを取得する必要がある。このため、スタブ化されたファイルへのアクセスは、通常のファイルに比べてアクセス性能が低下する。

　「レプリケーション」とは、ＥｄｇｅにあるファイルをＣｏｒｅにコピー（複製）することをいう。「マイグレーション」とは、ＥｄｇｅにあるファイルをＣｏｒｅにレプリケーションし、Ｅｄｇｅのファイルをスタブ化することをいう。「アーカイブ」とは、マイグレーションとレプリケーションとの総称である。「リコール」とは、スタブ化されたファイルについて、Ｃｏｒｅから実データを取得し、Ｅｄｇｅのファイルに保持させることをいう。「キャッシュ」とは、ＥｄｇｅからＣｏｒｅへレプリケーションした後に、Ｅｄｇｅに残っているファイルのこと又は、そのようにＥｄｇｅにファイルを残すことをいう。キャッシュへのアクセスは、通常のファイルと同等なアクセス性能である。「ホームディレクトリ」とは、ファイルサーバにおいて、ユーザ毎に割り当てられたユーザ専用のディレクトリのことをいい、配下に当該ユーザのディレクトリ及びファイルを含む。また「ユーザファイル」とは、当該ユーザのホームディレクトリ配下に格納されている、ユーザのファイル及び／またはディレクトリのことを意味する。

　以下で、本発明の実施例に係る情報システムの構成を説明していく。図１は、実施例に係る情報システムのハードウェア構成を示す図である。

　本発明の実施例に係る情報システムは、データセンタであるＣｏｒｅ１００と、データセンタとは異なる拠点である複数のＥｄｇｅ１０とに配置される。Ｅｄｇｅ１０とはたとえば、企業の支店、事業所等であり、各Ｅｄｇｅ１０は、地理的に異なる場所に存在する。ただし、本発明は、Ｅｄｇｅ１０間の距離によらず、有効である。たとえば第１のＥｄｇｅと第２のＥｄｇｅが近接した拠点、たとえば第１のＥｄｇｅと第２のＥｄｇｅがそれぞれ、同一敷地内の別の建物である構成でも良い。あるいは第１のＥｄｇｅが日本国内にあり、そして第２のＥｄｇｅが米国内に存在する構成でも良い。また図１に示す例では、Ｃｏｒｅ１００が単数であるが、Ｃｏｒｅ１００が複数存在する構成もあり得る。ただし、以下ではＣｏｒｅ１００が単数の構成例を中心に説明する。

　まず、Ｅｄｇｅ１０に配置される計算機システムの構成から説明する。Ｅｄｇｅ１０の計算機システムは、ストレージ装置２０と、１以上のローカルファイルサーバ３０と、１以上のクライアント（例えば、パーソナルコンピュータ）／ホスト（例えば、サーバ）４０とを備える。ローカルファイルサーバ３０は、ローカルのファイルサーバの一例である。ローカルファイルサーバ３０は、例えば、通信ネットワーク５０（例えばＬＡＮ（Local　Area　Network））経由で、クライアント／ホスト４０に接続されている。また、ローカルファイルサーバ３０は、例えば、通信ネットワーク６０（例えばＳＡＮ（Storage　Area　Network））経由で、ストレージ装置２０に接続されている。

　ストレージ装置２０は、ストレージコントローラ（ＣＴＬと略記されることもある）２１とＤＩＳＫ２３とを備える。ストレージコントローラ２１は、ローカルファイルサーバ３０に接続される通信インタフェースや、ＤＩＳＫ２３へのＩ／Ｏ要求を処理するためのプロセッサなどを備えた装置である。ＤＩＳＫ２３は、ローカルファイルサーバ３０からのライトデータを格納する最終記憶デバイスであって、例えばＨＤＤ（Hard　Disk　Drive）、ＳＳＤ（Solid　State　Drive）などの記憶デバイスである。また、ＣＴＬ２１、ＤＩＳＫ２３は、図１ではそれぞれ１つのみが存在する構成が示されているが、複数存在しても良い。複数のＤＩＳＫ２３で、１以上のＲＡＩＤグループが構成されてよい。

　ストレージ装置２０は、ローカルファイルサーバ３０から送信されたブロックレベルのＩ／Ｏ要求をＣＴＬ２１で受信し、適切なＤＩＳＫ２３へのＩ／Ｏを実行する。

　ローカルファイルサーバ３０は、メモリ３１と、ＣＰＵ３２と、ＮＩＣ（Network　Interface　Card）３３と、ＨＢＡ（Host　Bus　Adaptor）３４を備える。メモリ３１、ＮＩＣ３３及びＨＢＡ３４に、ＣＰＵ３２が接続されている。ＮＩＣ３３は、センターファイルサーバ１２０及びクライアント／ホスト４０と通信する通信インタフェース装置である。ＨＢＡ３４は、ストレージ装置２０と通信する通信インタフェース装置である。

　メモリ３１は、ＣＰＵ３２が直接読み書きできる記憶領域（例えば、ＲＡＭ（Random　Access　Memory）やＲＯＭ（Read　Only　Memory））である。ローカルファイルサーバ３０では、メモリ３１上にローカルファイルサーバ３０を制御するプログラム（例えばＯＳ（Operating　System））を読み込み、ＣＰＵ３２がそのプログラムを実行する。ローカルファイルサーバ３０は、メモリ３１に加えて又は代えて、別種の記憶資源を有してもよい。メモリ３１は、記憶デバイスの一例である。

　ローカルファイルサーバ３０は、ＮＩＣ３３経由で、クライアント／ホスト４０からファイルレベルのＩ／Ｏ要求を受信する。ローカルファイルサーバ３０は、ファイルレベルのＩ／Ｏ要求をブロックレベルＩ／Ｏ要求に変換してストレージ装置２０に送信する。

　クライアント／ホスト４０は、メモリ４１と、ＣＰＵ４２と、ＮＩＣ４３と、ＤＩＳＫ４４と、を備える。クライアント／ホスト４０は、メモリ４１及び／又はＤＩＳＫ４４に加えて又は代えて、別種の記憶資源を有してもよい。また、ＤＩＳＫ４４にはたとえば、ＨＤＤやＳＳＤが用いられる。また、ＤＩＳＫ４４がクライアント／ホスト４０に内蔵されている構成は必須ではなく、ＤＩＳＫ４４が外付け、つまりクライアント／ホスト４０の外部にあり、ＨＢＡなどで接続される構成でも良い。

　クライアント／ホスト４０では、ＤＩＳＫ４４に格納されているプログラム（クライアント／ホスト４０を制御するプログラム（例えばＯＳ））をメモリ４１上に読み込み、ＣＰＵ４２がプログラムを実行する。また、クライアント／ホスト４０は、ＮＩＣ４３経由で、ファイルレベルのＩ／Ｏ要求をローカルファイルサーバ３０に送信する。

　本発明の実施例に係る情報システムの利用者であるユーザ１は、各Ｅｄｇｅ１０に移動可能で、任意のＥｄｇｅ１０にあるクライアント／ホスト４０を利用することができる。また、ユーザ１は各Ｅｄｇｅ１０を訪問する際、携帯端末１５０を所持している。携帯端末１５０は、一例として携帯電話等の、携帯可能で無線通信可能な電子機器であり、通信ネットワーク８０に接続されたアクセスポイント１６０を介して、Ｃｏｒｅ１００のセンターファイルサーバ１２０との通信が可能な機器である。また携帯端末１５０は、多くの計算機と同様に、メモリとメモリに格納されたプログラムを実行するためのプロセッサを有するが、図示は省略している。

　また携帯端末１５０は、ＧＰＳ等の、位置情報を取得可能な機能を備えており、取得した位置情報をセンターファイルサーバ１２０に送信する機能を有する。なお、図１では、アクセスポイント１６０が通信ネットワーク８０に接続される構成を示しているが、本発明はこの構成に限定されるものではない。センターファイルサーバ１２０とアクセスポイント１６０が、通信ネットワーク８０以外のネットワークを介して接続される構成でもよい。また、図ではユーザ１のみが示されているが、実際には複数のユーザが情報システムを利用する。そして各ユーザが位置情報を取得可能な機能を備えた携帯端末１５０を所持している。

　続いて、Ｃｏｒｅ１００に配置される計算機システムの構成を説明する。Ｃｏｒｅ１００の計算機システムは、ストレージ装置１１０と、センターファイルサーバ１２０と、を備える。センターファイルサーバ１２０は、リモートのファイルサーバの一例である。センターファイルサーバ１２０に、ストレージ装置１１０が接続されている。

　ストレージ装置１１０は、ストレージコントローラ（図中ではＣＴＬと表記）１１１とＤＩＳＫ１１３とを備える。図１では、ストレージ装置１１０の構成とストレージ装置２０の構成とは、同一である。従って、ストレージ装置１１０も、センターファイルサーバ１２０から送信されたブロックレベルのＩ／Ｏ要求をＣＴＬ１１１で受信し、適切なＤＩＳＫ１１３へのＩ／Ｏを実行する。なお、ストレージ装置１１０の構成とストレージ装置２０の構成が異なっていても、本発明は有効である。

　センターファイルサーバ１２０は、メモリ１２１と、ＣＰＵ１２２と、ＮＩＣ１２３と、ＨＢＡ１２４と、を備える。メモリ１２１に代えて又は加えて、別種の記憶資源が備えられてもよい。センターファイルサーバ１２０では、メモリ１２１上にセンターファイルサーバ１２０を制御するプログラム（例えばＯＳ）を読み込み、ＣＰＵ１２２がそのプログラムを実行する。また、センターファイルサーバ１２０は、ＮＩＣ１２３及び通信ネットワーク８０経由で、ローカルファイルサーバ３０と通信する。センターファイルサーバ１２０は、ＨＢＡ１２４経由で、ストレージ装置１１０に対してブロック単位のアクセスを行う。

　図２は、実施例に係る情報システムのソフトウェア構成図である。

　ストレージ装置２０（１１０）では、ＣＴＬ２１（１１１）が１以上のＤＩＳＫ２３の記憶領域を用いて、１または複数のＬＵ（Logical　Unit）２４（１１４）を形成し、ローカルファイルサーバ３０（センターファイルサーバ１２０）に提供している。ローカルファイルサーバ３０（センターファイルサーバ１２０）は、ストレージ装置２０（１１０）から提供されるＬＵ２４（１１４）に対して、ファイルを格納する。また、ストレージ装置２０（１１０）から提供されるＬＵ２４（１１４）に対して、ローカルファイルサーバ３０（センターファイルサーバ１２０）が使用するＯＳや、各種プログラムが格納されていても良い。

　続いてローカルファイルサーバ３０及びセンターファイルサーバ１２０が実行する各種プログラムについて説明する。ローカルファイルサーバ３０のメモリ３１（センターファイルサーバ１２０のメモリ１２１）には、データムーバプログラム３７（１２５）と、ファイルシステム３６（１２６）と、カーネル／ドライバ３８（１２７）と、が記憶されている。ローカルファイルサーバ３０のメモリ３１には、更に、ファイル共有プログラム３５が記憶されている。以下、ローカルファイルサーバ３０内のデータムーバプログラム３７を、「ローカルムーバ」と言い、センターファイルサーバ１２０内のデータムーバプログラム１２５を、「リモートムーバ」と言い、それらを特に区別しない場合に、「データムーバプログラム」と言う。ローカルファイルサーバ３０とセンターファイルサーバ１２０との間では、ローカルムーバ３７及びリモートムーバ１２５を介して、ファイルのやり取りが行われる。

　カーネル／ドライバ３８（１２７）は、ローカルファイルサーバ３０（センターファイルサーバ１２０）上で動作する複数のプログラム（プロセス）のスケジュール制御やハードウェアからの割り込みをハンドリングするなど、全般的な制御及びハードウェア固有の制御を行う。

　ファイルシステム３６（１２６）は、ＬＵ２４（１１４）にファイル及びファイル管理情報を格納して管理するプログラムであり、ファイルシステムプログラムと呼ばれることもある。ファイル管理情報は、各ファイル、ディレクトリに関する様々な情報（例えば、ファイルのサイズや場所などを表す情報等）を含む。ファイル管理情報のうち、本発明の実施例で中心に説明される、レプリケーション処理や事前ダウンロード処理で必要な管理情報の内容については、後述する。

　ファイル共有プログラム３５は、ＣＩＦＳ（Common　Internet　File　System）、ＮＦＳ（Network　File　System）といった通信プロトコルを使用して、クライアント／ホスト４０にファイル共有サービスを提供するプログラムである。ファイル共有プログラム３５は、クライアント／ホスト４０からファイルアクセス要求（たとえばリード要求）を受け付けると、ローカルムーバ３７を呼び出して、ＬＵ２４からアクセス対象のファイルを読み出し、クライアント／ホスト４０に返送する。

　ローカルムーバ３７について説明する前に、まずファイルシステム３６（１２６）の管理するファイル管理情報について説明する。図５は、本発明の実施例に係る、ローカルファイルサーバ３０（またはセンターファイルサーバ１２０）で管理される、ファイル管理情報の説明図である。

　ローカルファイルサーバ３０がファイルを格納するために用いるＬＵ２４内には、ｉｎｏｄｅ領域２４１と実データ領域２４２が存在する。ｉｎｏｄｅ領域２４１には、各ファイルの管理情報であるｉｎｏｄｅが格納され、実データ領域２４２にはファイルの実データが格納される。

　ｉｎｏｄｅ領域２４１に格納される、ファイルのｉｎｏｄｅ２０１の構成について説明する。なお、ｉｎｏｄｅには、以下で説明する情報以外の情報も格納され得るが、ここでは本発明の実施例で行われるレプリケーション処理や事前ダウンロード処理で用いられる情報についてのみ説明する。ｉｎｏｄｅ２０１は、ｉｎｏｄｅ番号２２０ａと、所有者２２０ｂと、アクセス権２２０ｃと、サイズ２２０ｄと、最終アクセス日時２２０ｅと、スタブ化フラグ２２０ｆと、レプリケーション済みフラグ２２０ｇと、リンク先２２０ｈ、データブロックアドレス２２０ｉのフィールドを有する。

　ｉｎｏｄｅ領域２４１内にある各ｉｎｏｄｅには、ｉｎｏｄｅ番号と呼ばれる、ｉｎｏｄｅ領域２４１内で一意な番号が付されており、ｉｎｏｄｅ番号２２０ａには、このｉｎｏｄｅ番号が格納される。所有者２２０ｂには、このｉｎｏｄｅで管理されるファイルの所有者のユーザＩＤが格納される。アクセス権２２０ｃには、このｉｎｏｄｅで管理されるファイルのアクセス権情報（リード可、ライト可等）が格納される。サイズ２２０ｄには、このｉｎｏｄｅで管理されるファイルのサイズが格納される。最終アクセス日時２２０ｅには、このｉｎｏｄｅで管理されるファイルがアクセスされた最新の日時の情報が格納される。データブロックアドレス２２０ｉは、１つのｉｎｏｄｅの中に複数存在するフィールドで、このｉｎｏｄｅで管理されるファイルの実データが格納されている領域のアドレスが格納される。

　スタブ化フラグ２２０ｆ、レプリケーション済みフラグ２２０ｇと、リンク先２２０ｈは、本発明の実施例に係るローカルムーバ３７で用いられるフィールドである。スタブ化フラグ２２０ｆには、このｉｎｏｄｅで管理されるファイルがスタブ化されているか否かを表す情報が、ローカルムーバ３７によって格納される。“０”が格納されている場合、このファイルはスタブ化されていないことを表し、“１”が格納されている場合、このファイルはスタブ化されていることを表す。

　レプリケーション済みフラグ２２０ｇには、このｉｎｏｄｅで管理されるファイルがセンターファイルサーバ１２０にレプリケーション済みか否かを表す情報が、ローカルムーバ３７によって格納される。“０”が格納されている場合、このｉｎｏｄｅで管理されるファイルが、まだセンターファイルサーバ１２０にレプリケーションされていないことを表し、“１”が格納されている場合、このｉｎｏｄｅで管理されるファイルがセンターファイルサーバ１２０にレプリケーション済みであることを表す。

　ローカルファイルサーバ３０で作成、更新されたファイルは、何らかの契機でセンターファイルサーバ１２０にレプリケーションされる必要がある。レプリケーション済みフラグ２２０ｇは、レプリケーションが必要なファイルを特定するために用いられる。センターファイルサーバ１２０からファイルがダウンロードされ、当該ファイルをＬＵ２４に格納する際に、ローカルムーバ３７は当該ファイルのレプリケーション済みフラグ２２０ｇを“１”にする。クライアント／ホスト４０によってファイルが更新された時、あるいはクライアント／ホスト４０によって新規ファイルが作成された時、ローカルムーバ３７は当該ファイルのレプリケーション済みフラグ２２０ｇを“０”にする。そして後述するレプリケーション処理において、ローカルムーバ３７はレプリケーション済みフラグ２２０ｇが“０”であるファイルをレプリケーション対象とする。ファイルがセンターファイルサーバ１２０にレプリケーションされると、ローカルムーバ３７はＬＵ２４に格納されている対象ファイルのレプリケーション済みフラグ２２０ｇを“１”にする。

　リンク先２２０ｈには、このｉｎｏｄｅで管理されるファイルの実データのＣｏｒｅ１００における格納先（リンク先）を表す情報、たとえばＵＲＬ（Uniform　Resource　Locator）が格納される。リンク先２２０ｈには、センターファイルサーバ１２０のデータムーバプログラム１２５によって、センターファイルサーバ１２０内での格納場所の情報が格納される。そしてローカルファイルサーバ３０からの要求に応じてセンターファイルサーバ１２０がファイルを転送する際に、リンク先２２０ｈを含むファイル管理情報もローカルファイルサーバ３０に転送される。また、レプリケーション処理によってローカルファイルサーバ３０から転送されたファイルがセンターファイルサーバ１２０内のＬＵ１１４に格納されると、格納場所の情報（リンク先２２０ｈ相当の情報）がセンターファイルサーバ１２０からローカルファイルサーバ３０に送信される。ローカルファイルサーバは送信されてきた格納場所の情報を、リンク先２２０ｈに格納する。

　ローカルファイルサーバ３０及びセンターファイルサーバ１２０の持つプログラムの説明に戻る。ローカルムーバ３７は、ファイル共有プログラム３５から呼び出されて動作するプログラムである。ローカルムーバ３７はファイル共有プログラム３５から呼び出されると、ファイルシステム３６を用いて、アクセス対象のファイルの読み書きを実施する。またローカルムーバ３７は、レプリケーション、スタブ化、事前ダウンロード処理を実施するプログラムでもある。

　ローカルムーバ３７はレプリケーション処理を実施する際、レプリケーション対象のファイル（ｉｎｏｄｅと、当該ｉｎｏｄｅのデータブロックアドレス２２０ｉで指し示されているファイルの実データ）を読み出し、読み出されたファイルをセンターファイルサーバ１２０に転送する。リモートムーバ１２５は、ローカルムーバ３７から転送されてきたファイル（レプリケーション対象のファイル）を、ファイルシステム１２６を用いてストレージ装置１１０のＬＵ１１４に書き込む。

　また、ローカルムーバ３７は所定の条件が満たされた場合に、ＬＵ２４内のレプリケーション済みファイル（厳密にはそのファイルの実データ）を削除し、ＬＵ２４には実データが削除されたファイルのスタブ（メタデータ）のみを置く（いわゆるスタブ化処理を行う）。これにより、レプリケーション済みファイルの実質的なマイグレーションを実現する。具体的には、スタブ化されるファイルのスタブ化フラグ２２０ｆに“１”を格納し、データブロックアドレス２２０ｉの値をＮＵＬＬにする。その後、ローカルムーバ３７は、実データが削除されたファイルに対してクライアント／ホスト４０からリード要求を受けた場合、スタブ（ファイル管理情報つまりｉｎｏｄｅ）を参照することにより、スタブにリンクしているファイルの実データをリモートムーバ１２５経由で取得し、取得したファイルをクライアント／ホスト４０に送信する。なお、本実施例において、「スタブ」とは、ファイルの格納先情報（リンク先を表す情報。本発明の実施例では、ｉｎｏｄｅに含まれているリンク先２２０ｈ等が該当する）が関連付けられたオブジェクト（メタデータ）である。ローカルムーバ３７の働きにより、クライアント／ホスト４０からは、ＬＵ２４に格納されているファイルが実データのないスタブであっても、そのことは認識されない。

　次に、クライアント／ホスト４０のメモリ４１に格納されている各種プログラムについて説明する。クライアント／ホスト４０のメモリ４１には、アプリケーション４５と、ファイルシステム４６と、カーネル／ドライバ４７とが記憶されている。

　アプリケーション４５は、クライアント／ホスト４０が、作業の目的に応じて使うソフトウェア（アプリケーションプログラム）である。カーネル／ドライバ４７は、上述のファイルシステム３６（１２６）、カーネル／ドライバ３８（１２７）とほぼ同様である。

　ファイルシステム４６は、アプリケーション４５等からのファイルアクセス要求を処理するプログラムである。ファイルシステム４６はアプリケーション４５等からファイルアクセス要求を受け付けた時、アクセス対象のファイルがＤＩＳＫ４４にあるファイルである場合には、ＤＩＳＫ４４に格納されているファイルへのアクセス処理を行う。一方、アクセス対象のファイルがローカルファイルサーバ３０の管理するファイルである場合、ＣＩＦＳ、ＮＦＳといったプロトコルを用いてファイル共有プログラム３５と通信し、ローカルファイルサーバ３０の管理するファイルへのアクセス処理を行う。

　続いてセンターファイルサーバ１２０及び携帯端末１５０が実行するプログラムについて説明する。センターファイルサーバ１２０の位置情報管理プログラム１２８は、ユーザ１の持つ携帯端末１５０からの位置情報を受信して、位置情報推移保持テーブル４００（後述）に格納する。一方、携帯端末１５０のメモリには、位置送信プログラム１５５が格納されており、定期的に携帯端末１５０の位置情報（緯度、経度情報等）を取得し、ユーザ１のユーザ情報（後述）とともに、位置情報をセンターファイルサーバ１２０に送信する。

　次に、本発明の実施例に係る情報システムで行われる、ファイルレプリケーション、事前ダウンロード処理の概要を、図３を用いて説明する。センターファイルサーバ１２０は、本発明の実施例に係る情報システムを使用する全ユーザのファイルを格納、管理している。ユーザは各拠点のクライアント／ホスト４０を介して、ローカルファイルサーバ３０に格納されているファイルにアクセスする。ローカルファイルサーバ３０には、センターファイルサーバ１２０で管理されているすべてのファイルが格納されているわけではなく、ユーザがファイルを使用する時、あるいはユーザがファイルを使用する前に、センターファイルサーバ１２０からファイルがダウンロードされる。ユーザはローカルファイルサーバ３０にダウンロードされたファイルを参照または更新し、更新されたファイルについては、センターファイルサーバ１２０へとレプリケーションが行われる。

　最初の状態（状態０と呼ぶ）として、あるユーザ（ユーザＡ）が拠点Ａ（Ｅｄｇｅ１０Ａ）のクライアント／ホスト４０にログインし、さらにクライアント／ホスト４０を用いてローカルファイルサーバ３０にログインした後、ローカルファイルサーバ３０が提供するファイルにアクセスしている状態を想定する。状態０では、ユーザＡが使用する１または複数のファイルは、Ｅｄｇｅ１０ＡのＬＵ２４に格納されている。またＣｏｒｅ１００のＬＵ１１４にもユーザＡのファイルは存在するが、Ｅｄｇｅ１０ＡでユーザＡがファイルの更新を行った場合には、Ｃｏｒｅ１００のＬＵ１１４に格納されているユーザＡのファイルは、Ｅｄｇｅ１０Ａに存在するファイルよりも古いファイル（Ｅｄｇｅ１０Ａで行われたファイルへの更新の内容が反映されていないファイル）である。

　次に、ユーザＡが別の拠点（拠点Ｂ（Ｅｄｇｅ１０Ｂ））に移動するため、クライアント／ホスト４０及びローカルファイルサーバ３０からログオフする。ログオフ処理が行われた時点の状態を「状態１」と呼ぶ。その後ユーザは拠点Ｂに向かって移動を開始する。

　ユーザＡの所持する携帯端末１５０は定期的に位置情報をセンターファイルサーバ１２０に送信し続けている。ユーザＡが拠点Ａから拠点Ｂに移動している途中（状態２と呼ぶ）でも、位置情報の送信が行われる。

　拠点Ａのローカルファイルサーバ３０は、拠点Ａで更新されたファイルを、センターファイルサーバ１２０に対してレプリケーションするが、その際に、各ユーザの位置情報に基づいて、レプリケーションを行うファイルの優先順位の決定を行う。ローカルファイルサーバ３０は、定期的にセンターファイルサーバ１２０から、ユーザＡ及びその他ユーザの位置情報を取得している（図中（３））。ローカルファイルサーバ３０では、この取得した位置情報をもとにレプリケーション順位を決定する。優先順位の決定方法の詳細は後述するが、各ユーザのうち、他拠点に到達する予想時間が短いユーザのファイルから優先的にレプリケーションする（図中（４））。その後、拠点Ａのローカルファイルサーバ３０は、レプリケーション済みのファイルのスタブ化を行う。他拠点に到達する予想時間が短ければ短いほど、移動先拠点でファイルアクセスを開始する時刻が早いと考えられる。そのため、本発明の実施例に係るレプリケーション順位の決定方法では、移動先拠点でファイルアクセスを開始する時刻が早いユーザのファイルから順にレプリケーションされるため、拠点Ａで更新したファイルに移動先拠点でアクセスできないという事態を防ぐことができる。

　一方、ユーザＡの移動先である拠点Ｂ（Ｅｄｇｅ１０Ｂ）のローカルサーバ３０も、定期的に位置情報を取得している（図中（６））。拠点Ｂ（Ｅｄｇｅ１０Ｂ）のローカルファイルサーバ３０では、この取得した位置情報をもとに、Ｃｏｒｅ１００から拠点Ｂ（Ｅｄｇｅ１０Ｂ）のＬＵ２４にダウンロード（リコール）するファイルを選定する。選定されるファイルは、近々拠点Ｂに到来し、ローカルファイルサーバ３０にログインする可能性が高いユーザのファイルが優先的に選定される（図中（７））。その後ユーザＡが拠点Ｂに到着し、拠点Ｂのクライアント／ホスト４０及びローカルファイルサーバ３０にログインした時点では、ユーザＡの使用するファイルが、拠点Ｂのローカルファイルサーバ３０にダウンロードされた状態になっているため、ユーザＡがファイルアクセスを行った時、拠点Ｂのローカルファイルサーバ３０は、センターファイルサーバ１２０からファイルをダウンロード（リコール）する必要がない。

　上の説明では、拠点Ａのローカルファイルサーバ３０がレプリケーション、スタブ化を行い、拠点Ｂのローカルファイルサーバ３０がファイルのダウンロード（リコール）を行う例を説明したが、ユーザＡが拠点ＢからＡに移動することもあり得る。その場合には、拠点Ｂのローカルファイルサーバ３０がレプリケーション、スタブ化を行い、拠点Ａのローカルファイルサーバ３０がファイルのダウンロード（リコール）を行う。そのため、いずれの拠点のローカルファイルサーバ３０も、位置情報に基づいたレプリケーション、スタブ化を行うプログラム、位置情報に基づいたファイルのダウンロード（リコール）を行うプログラムの両方を有している。なお、本発明の実施例に係る情報システムでは、ローカルファイルサーバ３０のデータムーバプログラム３７に、位置情報に基づいたレプリケーション、スタブ化を行うプログラム、位置情報に基づいたファイルのダウンロード（リコール）を行うプログラムの両方が含まれている。

　次に、位置情報に基づいたレプリケーション、スタブ化、位置情報に基づいたファイルダウンロード（リコール）を行うために、ローカルファイルサーバ３０、センターファイルサーバ１２０で使用される各種管理情報について、図４を用いて説明する。ローカルファイルサーバ３０はメモリ３１内に、Ｅｄｇｅ位置情報テーブル３００、ログイン日時テーブル３１０、ログオフ日時テーブル３２０、近接判定履歴テーブル３３０、ログイン確率テーブル３４０、ファイル利用履歴テーブル３５０を有する。またセンターファイルサーバ１２０はメモリ１２１内に、位置情報推移保持テーブル４００、Ｅｄｇｅ位置情報テーブル４１０を有する。

　図６を用いて、Ｅｄｇｅ位置情報テーブル３００（４１０）の内容を説明する。Ｅｄｇｅ位置情報テーブル３００（４１０）は、各拠点の地理的位置情報を記録しているテーブルであり、各拠点３０１の経度３０２、緯度３０３が格納されている。各拠点のローカルファイルサーバ３０にあるＥｄｇｅ位置情報テーブル３００には、いずれも同内容の情報が格納される。またセンターファイルサーバ１２０にも、同内容のＥｄｇｅ位置情報テーブル４１０が存在する（一方、Ｅｄｇｅ位置情報テーブル３００（４１０）以外のテーブル、つまりログイン日時テーブル３１０、ログオフ日時テーブル３２０、近接判定履歴テーブル３３０、ログイン確率テーブル３４０、そしてファイル利用履歴テーブル３５０は、各ローカルファイルサーバ３０が独立に管理している情報である）。

　図８を用いて、ログイン日時テーブル３１０、ログオフ日時テーブル３２０の内容について説明する。ログイン日時テーブル３１０は、クライアント／ホスト４０を利用するユーザ１がローカルファイルサーバ３０にログインした日時（ログイン日時３１２）を、ユーザの識別情報であるユーザＩＤ（３１１）と対応付けて記録するテーブルである。一方ログオフ日時テーブル３２０は、クライアント／ホスト４０を利用するユーザ１がローカルファイルサーバ３０からログオフした日時（ログオフ日時３２２）を、ユーザの識別情報であるユーザＩＤ（３２１）と対応付けて記録するテーブルである。ユーザがクライアント／ホスト４０を用いて、ローカルファイルサーバ３０にログインすると、ファイル共有プログラム３５がログイン日時テーブルに、ユーザＩＤ（３１１）とログイン日時３１２１を記録する。一方ユーザがログオフする際には、ファイル共有プログラム３５がログオフ日時テーブル３２０に、ユーザＩＤ（３２１）とログイン日時３２２を記録する。ログイン日時テーブル３１０、ログオフ日時テーブル３２０には、１人のユーザについて、複数個のログイン日時３１２、複数個のログオフ日時３２２が記録できる。

　続いて図７を用いて、位置情報推移保持テーブル４００の内容を説明する。位置情報推移保持テーブル４００は、センターファイルサーバ１２０の位置情報管理プログラム１２８が、携帯端末（の位置送信プログラム１５５）から位置情報を受信した結果を記録するためのテーブルである。位置送信プログラム１５５からは、ユーザの情報（ユーザＩＤ）、そして位置情報である経度と緯度の情報が送られてくる。位置情報管理プログラム１２８はこの情報を受信すると、位置送信プログラム１５５から送られてくるユーザＩＤをユーザＩＤ４０１欄に、経度と緯度をそれぞれ、経度４０３、緯度４０４に記録する。また登録時刻４０２には、位置情報推移保持テーブル４００にユーザＩＤ４０１、経度４０３そして緯度４０４を記録した時点の時刻、または位置送信プログラム１５５からユーザＩＤや位置情報を受信した時刻が格納される。位置情報推移保持テーブル４００に格納される時刻には、センターファイルサーバ１２０の持つ時計から取得される時刻情報が用いられる。ただし別の実施形態として、携帯端末１５０の位置送信プログラム１５５から、ユーザＩＤや位置情報と併せて時刻情報を送信してもらい、送信された時刻を位置情報推移保持テーブル４００に格納してもよい。

　ここで、本発明の実施例に係る情報システムで用いられる、ユーザＩＤ４０１について、補足説明しておく。計算機システムによっては、１人のユーザに対して割り当てられるユーザＩＤが各計算機で異なることもある（たとえば、“ｈｉｒａｎｏ”というユーザに対して割り当てられているユーザＩＤが、拠点Ａのクライアント／ホスト４０では“４０”であるが、一方拠点Ｂのクライアント／ホスト４０では“３５２１”が割り当てられているということがあり得る）。だが、本発明の実施例に係る情報システムでは、各クライアント／ホスト４０、ローカルファイルサーバ３０、センターファイルサーバ１２０において、１のユーザに対して割り当てられているユーザＩＤは、全て共通の（同一の）ＩＤであるとする。そのため、たとえばユーザ“ｈｉｒａｎｏ”のユーザＩＤは、いずれのＥｄｇｅのクライアント／ホスト４０、あるいはローカルファイルサーバ３０においても、共通のＩＤ（たとえば“４０”）である。

　これは、ユーザ“ｈｉｒａｎｏ”が所持する携帯端末１５０においても同様である。そのため、ユーザ“ｈｉｒａｎｏ”が所持する携帯端末１５０の位置送信プログラム１５５は、センターファイルサーバ１２０に位置情報とユーザＩＤを送信する場合、共通のＩＤ（たとえば“４０”）を送信するよう、構成されている。

　ただし、別の実施態様として、センターファイルサーバ１２０で、携帯端末１５０から送信されてくる、ユーザ“ｈｉｒａｎｏ”に割り当てられているユーザＩＤと、センターファイルサーバ１２０やローカルファイルサーバ３０でユーザ“ｈｉｒａｎｏ”に割り当てられているユーザＩＤとの対応表を管理しておき、携帯端末１５０から送信されてくる、ユーザ“ｈｉｒａｎｏ”に割り当てられているユーザＩＤを、センターファイルサーバ１２０やローカルファイルサーバ３０においてユーザ“ｈｉｒａｎｏ”に割り当てられているユーザＩＤに変換するような手段を設けてもよい。このようにすれば、携帯端末１５０とその他のサーバ（例えばローカルファイルサーバ３０、センターファイルサーバ１２０）とで、１のユーザに割り当てられているユーザＩＤが異なっていても、本発明は実施可能である。

　位置送信プログラム１５５は定期的に位置情報を送信してくるので、位置情報推移保持テーブル４００は、１ユーザについて、複数の情報（登録時刻４０２、経度４０３そして緯度４０４の組）を格納可能に構成されている。そのため、位置情報推移保持テーブル４００に登録された、あるユーザの複数の位置情報及び登録時刻から、ユーザの移動速度や移動ベクトル（移動の方向等）を算出することが可能である。さらに、Ｅｄｇｅ位置情報テーブル３００に登録されている各Ｅｄｇｅの位置情報とユーザの位置情報（複数）とを用いることで、各ユーザのいる位置から各Ｅｄｇｅまでの距離及び距離の変化率の算出も可能である。距離の変化率を参照することにより、各ユーザが各Ｅｄｇｅに接近しているのか、遠ざかっているのかを判定することができる。

　続いて図９を用いて、近接判定履歴テーブル３３０の内容を説明する。近接判定履歴テーブル３３０は、ユーザが拠点（Ｅｄｇｅ）に接近したと判断される時に、ユーザの情報やその時の時刻を格納するために用いられる。近接判定履歴テーブル３３０には、ユーザＩＤ３３１、接近日時３３２、ログイン有無３３３の欄が存在する。ある拠点（仮にＥｄｇｅ　Ａとする）のローカルファイルサーバ３０は、ユーザ（仮にこのユーザＩＤを“Ｕｓｅｒ００１”とする）が自拠点（Ｅｄｇｅ　Ａ）に接近したと判断した場合（具体的には、センターファイルサーバ１２０から取得した、ユーザ（Ｕｓｅｒ００１）の最新の位置情報とＥｄｇｅ　Ａの位置情報から算出される距離が、所定の閾値未満になった場合）、ユーザＩＤ３３１に“Ｕｓｅｒ００１”を、接近日時３３２に現在時刻（ユーザが自拠点に接近したと判定された時刻）を格納する。また、ユーザが自拠点に接近したと判断する方法は、これ以外の方法を採用してもよい。たとえば、自拠点から各ユーザまでの距離と、各ユーザの移動速度をもとに、各ユーザが自拠点に到達する到達予測時間を算出し、予測時間が所定の閾値以下である場合、ユーザが自拠点に接近したと判断してもよい。さらにこの両方の方法を用いてもよい。

　また、近接判定履歴テーブル３３０のログイン有無３３３には、“－１”、“０”、“１”のいずれかの値が格納されるが、初期値は“－１”である。そのため、ユーザＩＤ３３１、接近日時３３２に値が格納された時点では、ログイン有無３３３には値“－１”が格納される。ローカルファイルサーバ３０は、ユーザＩＤ３３１、接近日時３３２に値が格納されてしばらく後に、ログイン日時テーブル３１０を参照し、接近日時３３２から所定時間以内に、ユーザＩＤ３３１で特定されるユーザがローカルファイルサーバ３０にログインした事実があるか判定する。ユーザＩＤ３３１で特定されるユーザがローカルファイルサーバ３０にログインした事実がある場合には、ログイン有無３３３に“１”を格納する。所定時間以内にログインしていなかった場合にはログイン有無３３３に“０”を格納する。

　近接判定履歴テーブル３３０には、１ユーザについて、複数の情報（接近日時３３２、ログイン有無３３３の組）を格納可能である。ただし、１ユーザについての情報を無尽蔵に格納するわけにはいかないため、１ユーザあたりＮ（Ｎ＞１）個の情報を格納可能として、Ｎ個より多くの情報を格納する場合には、最も古い情報（接近日時３３２が最も過去の情報）を削除する。

　図１０は、ログイン確率テーブル３４０の内容を示している。本発明の実施例では、
（あるユーザがある拠点に接近したと判断され、かつその時にローカルファイルサーバにログインした回数）÷（あるユーザがある拠点に接近したと判断された回数）
で算出される値のことを、「ログイン確率」と呼ぶ。ログイン確率テーブル３４０には、ユーザＩＤ３４１ごとに、ログイン確率３４２が格納される。ローカルファイルサーバ３０は近接判定履歴テーブル３３０を参照し、ユーザ（ユーザＩＤ３３１で特定されるユーザ）ごとにログイン確率を計算して、ログイン確率３４２に計算した値を格納する。

　一例として、ユーザＩＤがＵｓｅｒ００１のユーザのログイン確率を計算する場合の例を説明する。まず、近接判定履歴テーブル３３０の中で、ユーザＩＤ３３１が“Ｕｓｅｒ００１”である行の数を計数する（この値を仮にＡとする）。続いて、ユーザＩＤ３３１が“Ｕｓｅｒ００１”である行のうち、ログイン有無３３３の値が“１”である行の数（この数をＢとする）を計数する。この場合、“Ｂ／Ａ”がＵｓｅｒ００１のログイン確率である。ローカルファイルサーバ３０がログイン確率の計算を行う契機は、近接判定履歴テーブル３３０の内容を更新する契機と同時に行ってもよいし、あるいはこれと無関係のタイミングで定期的に実施するようにしてもよい。

　図１１は、ファイル利用履歴テーブル３５０の内容を示している。ファイル利用履歴テーブル３５０は、ファイルサーバ３０が提供しているファイルにユーザがアクセスした履歴を格納するためのテーブルであり、ユーザＩＤ３５１で特定されるユーザが、ファイルパス３５３で特定されるファイルにアクセスした日時が、アクセス日時３５２に格納され、またサイズ３５４にはアクセスデータサイズが格納される。

　ファイル利用履歴テーブル３５０は、履歴を格納するためのテーブルであるから、初期状態では何も情報が格納されていない。ユーザがローカルファイルサーバ３０の提供するファイルにアクセスすると、ファイル共有プログラム３５が、ユーザＩＤ３５１、アクセス日時３５２、ファイルパス３５３、及びサイズ３５４の情報を格納する。ただしユーザが同一ファイルに再アクセスした場合には、すでに当該ファイルについての履歴がファイル利用履歴テーブル３５０に格納されているので、その場合には、アクセス対象ファイルのアクセス日時３５２とサイズ３５４の内容の更新のみが行われる。

　続いて、本発明の実施例に係るローカルムーバ３７が実行する、レプリケーション／スタブ化処理の流れを、図１２を用いて説明する。レプリケーション／スタブ化処理は、ローカルファイルサーバ３０において定期的に実行される処理である。

　最初にローカルムーバ３７は、ログオフ日時テーブル３２０とログイン日時テーブ３１０を参照し、現在時刻から過去の所定時間内にログオフしたユーザであって、かつ現在ログインしていないユーザのユーザＩＤを収集する（Ｓ３０１）。以下では、現在時刻から過去の所定時間内にログオフしたユーザのことを「候補ユーザ」と呼ぶ。

　続いてローカルムーバ３７は、センターファイルサーバ１２０の位置情報管理プログラム１２８に対し、Ｓ３０１で収集したユーザＩＤに対応した位置情報の送信を要求し、位置情報管理プログラム１２８からユーザの位置情報を取得する（Ｓ３０２）。位置情報管理プログラム１２８に送信される要求には、Ｓ３０１で収集されたユーザＩＤが含まれている。位置情報管理プログラム１２８はローカルムーバ３７からこの要求を受信すると、要求に含まれているユーザＩＤをもとに位置情報推移保持テーブル４００を参照し、ユーザＩＤ４０１が、要求に含まれているユーザＩＤと等しい行をすべて抽出し、抽出された行の登録時刻４０２、経度４０３、緯度４０４のセットをローカルムーバ３７に返送する。以下では、位置情報管理プログラム１２８からデータムーバに返送された、位置情報推移保持テーブル４００内の、ユーザＩＤ４０１が要求に含まれているユーザＩＤと等しい行の情報のことを、位置推移情報と呼ぶ。なお、Ｓ３０２でローカルムーバ３７に返送される情報は、上で説明した例に限定されない。返送される情報にユーザＩＤ４０１が含まれていてもよい。また、必ずしも位置情報推移保持テーブル４００の中から、要求に含まれているユーザＩＤとユーザＩＤ４０１が等しい行をすべて抽出する必要はない。要求に含まれているユーザＩＤとユーザＩＤ４０１が等しい行のうち、登録時刻４０２が新しい行から順にＮ行（Ｎ≧２）を抽出して、抽出された行の情報を返送するようにしてもよい。

　ローカルムーバ３７は、位置情報管理プログラム１２８から位置推移情報を受信すると、レプリケーション優先順位の決定処理を行う（Ｓ３０３）。位置推移情報及びＥｄｇｅ位置情報テーブル３００を参照し、レプリケーション対象ファイルの選定を行う。詳細は図１３を用いて後述するが、Ｓ３０３が実行された結果、レプリケーション対象ファイルの一覧が格納されたレプリケーション対象リストが作成される。

　レプリケーション優先順位の決定処理が終了すると、ローカルムーバ３７はＳ３０３で作成されたレプリケーション対象リストに格納されているファイルの順序に従って、ファイルのレプリケーションを行う（Ｓ３０４）。なお、レプリケーションが行われたファイルについては、レプリケーション済みフラグ２２０ｇが“０”から“１”に変更される。その後ローカルムーバ３７は、ファイルのスタブ化を行う（Ｓ３０５）。ファイルのスタブ化では、ローカルムーバ３７は各ファイルのメタデータを参照し、レプリケーション済みフラグ２２０ｇが“１”のファイルのうち、最終アクセス日時２２０ｅと現在日時との差が所定値以上のファイルについてスタブ化を行う。スタブ化が行われたファイルについては、スタブ化フラグ２２０ｆが“１”に設定される。

　ファイルのスタブ化が完了すると、処理を終了する。なお、ここではレプリケーションを行った後にスタブ化を行う処理例を説明したが、必ずしもレプリケーションを行った後にスタブ化を行う必要はない。レプリケーション処理とは独立（非同期）のタイミングで、スタブ化を定期的に実行するようにしてもよい。

　続いてレプリケーション優先順位の決定処理について、図１３を用いて説明する。

　レプリケーション優先順位の決定処理では、図１２のＳ３０２で取得された、候補ユーザの位置情報を元にして、レプリケーション対象ファイルの決定及びレプリケーション優先順位を決定する。最初にローカルムーバ３７は、Ｓ３０２で取得された各候補ユーザの位置推移情報から、最新の位置情報（登録時刻が最も新しい情報）を抽出する。ローカルムーバ３７は、この抽出された最新の位置情報と、Ｅｄｇｅ位置情報テーブル３００から、各候補ユーザの各拠点までの距離を算出する（Ｓ３５１）。なお、ここでの各拠点には、自拠点（Ｓ３５１の処理を実行しているローカルファイルサーバ３０の置かれている拠点）は含まれていないものとする。

　ユーザの経度と緯度、そして各拠点の経度と緯度を用いて、ユーザと各拠点の間の距離を算出する方法には、一例として、特開２００９－１５１８１号公報に開示されているLambert-Andoyerの公式を用いる方法を用いることができる。ただし、本発明におけるユーザと各拠点の間の距離を算出する方法は、この方法に限定されるものではなく、その他の方法を用いてもよい。

　続いてＳ３５２では、ローカルムーバ３７は各候補ユーザの位置推移情報を用いて、各拠点への平均移動速度を算出する。具体的には、複数の位置情報（一例として２つの位置情報）を用いて、各拠点への単位時間の変位を求めればよい。Ｓ３５３では、Ｓ３５２で求めた、各ユーザの各拠点への平均移動速度から、各ユーザがいずれかの拠点に向かって接近しているか、あるいは遠ざかっているかを判定し、いずれかの拠点に向かって接近しているユーザのみを選定する。ただし、Ｓ３５３で行われる判定方法は、上で説明した方法に限定されるものではない。それ以外の方法を用いてもよい。以下では、ここで選定されたユーザのことを、「選定ユーザ」と呼ぶ。

　Ｓ３５４は、ローカルムーバ３７はＳ３５３で選定された各ユーザについて、各拠点に到達するまでの予測時間を算出する。予測時間の算出方法の一例は、Ｓ３５１で求められた各拠点までの距離を、Ｓ３５２で算出された各拠点への平均移動速度で除算すればよい。ただしこれ以外の算出方法を用いて、予測時間の算出を行ってもよい。

　Ｓ３５５以降では、レプリケーション対象リストを作成する処理が行われる。レプリケーション対象リスト４００は、図１５に示されているように、レプリケーション対象とされたファイルのパス名が複数登録されたリストである。リストの先頭に位置するパス名は、もっともレプリケーション優先順位の高いファイルのパス名であり、以下レプリケーション優先順に、ファイルのパス名がこのリストへと追加格納されていく。

　Ｓ３５５では、ローカルムーバ３７は選定ユーザ（複数）のユーザＩＤをいずれかの拠点への予測到達時間がもっとも短い順にソートする。そしてソートされたユーザＩＤ順に、以下の処理を実行する：
　（１）当該ユーザＩＤで特定されるユーザのホームディレクトリ配下の各ファイルの中から、レプリケーション済フラグ２２０ｇの値が“０”のファイルを特定する。
　（２）特定されたファイルのパス名をレプリケーション対象リスト４００に登録する。

　Ｓ３５６では、ローカルムーバ３７はＳ３５５で処理対象とされたユーザ以外のユーザのホームディレクトリ配下の各ファイルについて、レプリケーション済フラグ２２０ｇの値が“０”のファイルを、レプリケーション対象として選択する作業を実行し、選択されたファイルのパス名をレプリケーション対象リスト４００に追加する。

　さらにＳ３５７では、ローカルムーバ３７はホームディレクトリ以外の各ファイルについて、レプリケーション済フラグ２２０ｇの値が“０”のファイルを、レプリケーション対象として選択する作業を実行し、選択されたファイルのパス名をレプリケーション対象リスト４００に追加登録して、処理を終了する。

　続いて、本発明の実施例に係るローカルムーバ３７が実行する、事前ダウンロード処理の流れを、図１４を用いて説明する。事前ダウンロード処理もレプリケーション／スタブ化処理と同様、ローカルファイルサーバ３０において定期的に実行される処理である。

　最初にローカルムーバ３７は、位置情報管理プログラム１２８から各ユーザの位置推移情報を取得する（Ｓ４０１）。

　続いてローカルムーバ３７は、Ｓ４０１で取得した各ユーザの位置推移情報と、自拠点の位置情報（Ｅｄｇｅ位置情報テーブル３００に登録されている）を用いて、各ユーザの自拠点までの位置及び、各ユーザの移動速度を算出する（Ｓ４０２）。この処理は、図１３のＳ３５１、Ｓ３５２と同様の処理を行ってもよいし、異なる処理を行ってもよい。Ｓ３５１、Ｓ３５２と異なる点は、Ｓ３５１、Ｓ３５２では各拠点までの距離、各拠点への移動速度を算出したが、Ｓ４０２では自拠点までの位置及び移動速度のみを算出する点である。

　続いてＳ４０３で、ローカルムーバ３７は、Ｓ４０２で算出した各ユーザの位置情報と移動速度をもとに、自拠点に向かっている（接近している）ユーザの選定を行う。ここではまず、図１３のＳ３５３と同様の方法で、自拠点に向かっていると判断されるユーザを選択する。さらに図１３のＳ３５４と同様の方法で、自拠点に向かっていると判断されるユーザの、自拠点へ到達するまでの予測時間を算出する。そして算出された予測時間が所定の閾値以下であるユーザを選定する。ここで選定されたユーザのことを、「候補ユーザ」と呼ぶ。また、別の方法として、近接判定履歴テーブル３３０の説明の際に述べたとおり、自拠点からの距離が所定の閾値未満の位置にいるユーザを候補ユーザとする方法を採用することもできる。あるいはこの２つの方法を用いて候補ユーザを選定する、つまり、自拠点に接近しており、かつ自拠点からの距離が所定の閾値未満の位置にいるユーザを、候補ユーザとして選定するようにしてもよい。

　また、ここでは、候補ユーザの情報及び現在時刻（Ｓ４０３の判定を行った時刻）を、近接判定履歴テーブル３３０に登録する。さらにログイン日時テーブル３１０をあわせて参照し、近接判定履歴テーブル３３０に登録されている各エントリについて、ログイン有無を判定し、ログイン有無３３３に０または１を記録する。

　続いてＳ４０４では、ローカルムーバ３７は、候補ユーザのログイン確率を算出する。ログイン確率の算出は、図１０の説明の時に述べたとおりの処理を行う。つまり近接判定履歴テーブル３３０を参照し、ユーザごとに
（ユーザが自拠点に接近したと判断され、かつその時にログインした回数）÷（ユーザが自拠点に接近したと判断された回数）
を計算し、ログイン確率テーブル３４０に、候補ユーザのログイン確率を登録する。そしてログイン確率テーブル３４０を参照し、候補ユーザの中でログイン確率が所定の閾値以上であるユーザを選択する。ここで選択されたユーザのことを、「選択ユーザ」と呼ぶ。

　Ｓ４０５ではローカルムーバ３７は、Ｓ４０５で選択されたユーザのユーザファイル（ホームディレクトリのファイル）を格納するための記憶領域の容量を決定する。各ユーザに対して割り当てるべき記憶容量を、ローカルファイルサーバ３０の空き容量を選択ユーザの数で均等に割るという方法もあり得るが、本発明の実施例に係るローカルファイルサーバ３０では、Ｓ４０４で算出された各ユーザのログイン確率に基づいて、各ユーザに対して割り当てるべき記憶容量を決定する。ここで決定される記憶容量が、ユーザファイルのダウンロード上限値となる。ログイン確率の高いユーザには多くの記憶領域を割り当てて、ログイン確率の高いユーザのデータが多くダウンロードされるようにする。以下、各ユーザに対して割り当てるべき記憶容量の算出方法を説明する。

　Ｓ４０４の処理の結果、Ｎ人（ユーザ１、ユーザ２、…ユーザＮ）の選択ユーザが存在する場合を想定して説明する。Ｓ４０４の処理の結果、自拠点に向かっているユーザｉ（１≦ｉ≦Ｎ）のログイン確率がそれぞれＰｉであった場合、ローカルムーバ３７は、ユーザごとに重みづけ係数Ｗｉを、以下の式（１）に基づいて算出する。

　Ｗｉが算出されたら、ローカルムーバ３７は各ユーザに対して割り当てるべき記憶容量Ｃｉを、以下の式（２）に基づいて算出する。
［数２］
　Ｃｉ＝ローカルファイルサーバ３０の空き容量×Ｗｉ　・・・・（２）
（なお、ローカルファイルサーバ３０の空き容量とは、ローカルファイルサーバ３０がファイルシステム３６を用いてファイル・ディレクトリを格納しているＬＵ２４の記憶領域のうち、まだファイルやディレクトリが格納されていない未使用領域のサイズである。）

　最後にＳ４０６で、ローカルムーバ３７は各選択ユーザのユーザファイルのうち、ダウンロード対象のファイルの決定及び決定されたファイルのダウンロードを行う。各ユーザｉについて、以下の（ａ）～（ｄ）の順でファイルのダウンロードが行われる。また、以下で説明する通り、ファイル利用履歴テーブル３５０に記録されているファイルの中からダウンロード対象のファイルが決定される。本実施例では、ファイル利用履歴テーブル３５０に記録されているファイルのうち、ユーザｉのホームディレクトリ内のファイル（ユーザファイル）をダウンロード対象とする。ただし別の実施形態として、ファイル利用履歴テーブル３５０に、ユーザｉが自身のホームディレクトリ以外のファイルをアクセスしていた履歴が残っていた場合、そのファイルをダウンロード対象に含める態様もあり得る。

　（ａ）　まずローカルムーバ３７は、ファイル利用履歴テーブル３５０を参照し、ユーザｉのホームディレクトリ内のファイルのうち、アクセス日時３５２が現在時刻から所定時間以内であるファイルを選択してダウンロードする。この時、各ユーザｉのユーザファイルについて、Ｃｉを超えない範囲でダウンロードが行われる。

　（ｂ）　（ａ）のダウンロード処理でダウンロードされたファイルの合計サイズが、Ｃｉ未満であった場合、ローカルムーバ３７は、ファイル利用履歴テーブル３５０に登録されているユーザｉのホームディレクトリ内のファイルのうち、かつ（ａ）でダウンロードされなかったファイルをダウンロードする。この時も、各ユーザｉのユーザファイルについて、Ｃｉを超えない範囲でダウンロードが行われる。

　（ｃ）　（ａ）及び（ｂ）のダウンロード処理でダウンロードされたファイルの合計サイズが、Ｃｉ未満であった場合、ローカルムーバ３７は、他拠点のローカルファイルサーバ３０からファイル利用履歴テーブル３５０を取得する。そしてローカルムーバ３７は、他拠点のファイル利用履歴テーブル３５０に登録されているファイルで、ユーザｉのホームディレクトリ内のファイルのうち、アクセス日時３５２が現在時刻から所定時間以内であるファイル（ただし（ａ）及び（ｂ）のダウンロード処理でダウンロードされたファイルは含まれない）をダウンロードする。この時も、各ユーザｉのユーザファイルについて、Ｃｉを超えない範囲でダウンロードが行われる。

　（ｄ）　（ａ）、（ｂ）及び（ｃ）のダウンロード処理でダウンロードされたファイルの合計サイズが、Ｃｉ未満であった場合、ローカルムーバ３７は、他拠点のファイル利用履歴テーブル３５０に登録されているユーザｉのホームディレクトリ内のファイルのうち、かつ（ｃ）でダウンロードされなかったファイルをダウンロードする。この時も、各ユーザｉのユーザファイルについて、Ｃｉを超えない範囲でダウンロードが行われる。

　Ｓ４０６のダウンロードが完了したら、事前ダウンロード処理は終了する。

　以上が、本発明の実施例に係る情報システムにおける、ファイルレプリケーション方法及びファイル事前ダウンロード方法である。本発明のローカルファイルサーバは、ユーザの位置情報をもとに、各ユーザの他拠点に到達する予測時間を算出する。そして他拠点に到達する予測時間の短いユーザのユーザファイルから優先的に、センターファイルサーバへレプリケーションする。移動先拠点でファイルアクセスを開始する時刻が早いユーザのファイルから順にレプリケーションされるため、ある拠点で更新したファイルに対して、移動先拠点でアクセスできないという事態を防ぐことができる。

　また本発明のローカルファイルサーバは、ユーザの位置情報をもとに、ユーザが自拠点に接近しているか判定し、自拠点に接近していると判断されるユーザのユーザファイルを優先的にセンターファイルサーバから事前ダウンロードする。そのため、拠点に到来するユーザがファイルアクセスを行う時点では、ローカルファイルサーバにユーザファイルがダウンロード済みであるので、ユーザのファイルアクセス応答時間を短くすることが可能である。また、ユーザが自拠点に接近したと判定された時刻や、ユーザがローカルファイルサーバにログインした時刻を記憶しておき、これらの情報をもとにユーザのログイン確率を算出し、ログイン確率に基づいて、ユーザファイルのダウンロード量を決定するので、ローカルファイルサーバにアクセスする可能性の高いユーザファイルをより多く事前ダウンロードすることが可能になる。

　また、ユーザの位置情報として、ユーザの所持する携帯端末が備えるＧＰＳ等の位置情報取得手段から定期的に送信される位置情報（緯度、経度など）を用いているため、ユーザが拠点に到達する予測時間の算出や、ユーザが拠点に接近しているか否かの判定を、高い精度で実施することができる。結果として、精度の高いレプリケーション順位の決定、事前ダウンロード順位の決定を行うことができる。

　以上、本発明の実施例を説明したが、これは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、他の種々の形態でも実施する事が可能である。

　たとえば上で説明した情報システムでは、各ユーザは、各Ｅｄｇｅ１０にあるクライアント／ホスト４０にログインし、クライアント／ホスト４０からローカルファイルサーバ３０の管理するファイルにアクセスしていたが、この構成に限定されるものではない。たとえばローカルファイルサーバ３０にクライアント／ホスト４０の機能を持たせ、ローカルファイルサーバ３０にユーザが直接ログインし、ローカルファイルサーバ３０の管理するファイルにアクセスするようにしてもよい。

　またローカルファイルサーバ３０のライトデータを格納するストレージ装置２０は、ローカルファイルサーバ３０の外部にある構成に限定されるものではない。ストレージ装置２０がローカルファイルサーバ３０に内蔵される構成を採用してもよい。さらにセンターファイルサーバ１２０もローカルファイルサーバ３０と同様に、ストレージ装置１１０を内蔵する構成を採用してもよい。

１０　Ｅｄｇｅ、３０　ローカルファイルサーバ、１００　Ｃｏｒｅ、１２０　センターファイルサーバ。

Claims

　センターファイルサーバを備えたデータセンタと、複数のユーザのユーザファイルを格納したローカルファイルサーバを有する複数の拠点とで構成される情報システムにおいて、
　前記ローカルファイルサーバは、前記ローカルファイルサーバからログオフしたユーザの、前記複数の拠点への到達予測時間を算出し、前記到達予測時間に基づいて、前記センターファイルサーバへ複製する前記ユーザファイルの優先順位を決定し、
　前記優先順位に従って、前記ユーザファイルを前記センターファイルサーバへと複製する、
ことを特徴とする情報システム。
　前記ローカルファイルサーバは、前記到達予測時間の最も短いユーザの前記ユーザファイルから順に、前記優先順位の高いユーザファイルと決定する、
ことを特徴とする、請求項１に記載の情報システム。
　前記センターファイルサーバへの複製が行われた後、前記ローカルファイルサーバは、前記センターファイルサーバに複製されたファイルのスタブ化を行うことを特徴とする、請求項１に記載の情報システム。
　前記ローカルファイルサーバは、前記複数の拠点の位置情報と、複数の時点における前記ユーザの位置情報に基づいて、前記複数の拠点への到達予測時間を算出することを特徴とする、請求項１に記載の情報システム。
　前記ユーザの位置情報は、前記ユーザの所持する携帯端末から定期的に発信される位置情報であることを特徴とする、請求項４に記載の情報システム。
　前記センターファイルサーバは、前記ユーザの所持する前記携帯端末から定期的に発信される位置情報を受信すると、前記位置情報を、前記ユーザの情報と前記位置情報の受信時刻とともに記憶しておき、
　前記ローカルファイルサーバは、前記センターファイルサーバから前記位置情報と前記位置情報の受信時刻の組を複数取得することを特徴とする、請求項５に記載の情報システム。
　前記ローカルファイルサーバは、前記ローカルファイルサーバの存在する自拠点の位置情報と、複数の時点における前記ユーザの位置情報に基づいて、前記ユーザが前記自拠点に接近しているか判定し、
　前記自拠点に接近していると判定された前記ユーザのユーザファイルを、前記ユーザが前記ローカルファイルサーバにログインする前に前記センターファイルサーバからダウンロードする、
ことを特徴とする、請求項１に記載の情報システム。
　前記ローカルファイルサーバは、前記自拠点の位置情報と、前記複数の時点における前記ユーザの位置情報から、前記各ユーザの前記自拠点への到達予測時間を算出し、
　前記到達予測時間が所定の閾値以下であるユーザは、前記自拠点に接近していると判定する、
ことを特徴とする、請求項７に記載の情報システム。
　前記ローカルファイルサーバは、前記ユーザが前記自拠点に接近していると判定された時刻を複数個、前記ユーザの情報と対応付けて、近接判定履歴テーブルに記憶しており、
　前記ローカルファイルサーバはまた、前記ユーザが前記ローカルファイルサーバにログインした時刻を複数個、前記ユーザの情報と対応付けて、ログイン日時テーブルに記憶しており、
　前記ローカルファイルサーバは、前記近接判定履歴テーブルと前記ログイン日時テーブルを用いて、
（前記ユーザが前記自拠点に接近したと判断され、かつその時に前記ローカルファイルサーバにログインした回数）÷（前記ユーザが前記自拠点に接近したと判断された回数）を計算することによって、前記各ユーザのログイン確率を算出し、
　前記ログイン確率に基づいて、前記各ユーザのデータのダウンロード上限値を算出する、
ことを特徴とする、
請求項７に記載の情報システム。
　センターファイルサーバに接続され、複数のユーザのユーザファイルを格納するローカルファイルサーバであって、
　前記ローカルファイルサーバは、前記ローカルファイルサーバからログオフしたユーザの、前記センターファイルサーバに接続された他のローカルサーバの存在する拠点への到達予測時間を算出し、前記到達予測時間に基づいて、前記センターファイルサーバへ複製する前記ユーザファイルの優先順位を決定し、
　前記優先順位に従って、前記ユーザファイルを前記センターファイルサーバへと複製する、
ことを特徴とするローカルファイルサーバ。
　前記ローカルファイルサーバは、前記拠点の位置情報と、複数の時点における前記ユーザの位置情報に基づいて、前記拠点への到達予測時間を算出することを特徴とする、請求項１０に記載のローカルファイルサーバ。
　前記ユーザの位置情報は、前記ユーザの所持する携帯端末から定期的に発信される位置情報であることを特徴とする、請求項１１に記載のローカルファイルサーバ。
　前記ローカルファイルサーバは、前記ローカルファイルサーバの存在する自拠点の位置情報と、複数の時点における前記ユーザの位置情報に基づいて、前記ユーザが前記自拠点に接近しているか判定し、
　前記自拠点に接近していると判定された前記ユーザのユーザファイルを、前記ユーザが前記ローカルファイルサーバにログインする前に前記センターファイルサーバからダウンロードする、
ことを特徴とする、請求項１０に記載のローカルファイルサーバ。
　センターファイルサーバを備えたデータセンタと、複数のユーザのユーザファイルを格納したローカルファイルサーバを有する複数の拠点とで構成される情報システムの制御方法であって、
　前記ローカルファイルサーバは、
　前記ローカルファイルサーバからログオフしたユーザの、前記複数の拠点への到達予測時間を算出し、
　前記到達予測時間に基づいて、前記センターファイルサーバへ複製する前記ユーザファイルの優先順位を決定し、
　前記優先順位に従って、前記ユーザファイルを前記センターファイルサーバへと複製する、
ことを特徴とする、情報システムの制御方法。
　前記ローカルファイルサーバは、前記ローカルファイルサーバの存在する自拠点の位置情報と、複数の時点における前記ユーザの位置情報に基づいて、前記ユーザが前記自拠点に接近しているか判定し、
　前記自拠点に接近していると判定された前記ユーザのユーザファイルを、前記ユーザが前記ローカルファイルサーバにログインする前に前記センターファイルサーバからダウンロードする、
ことを特徴とする、請求項１４に記載の情報システムの制御方法。