WO2016098152A1

WO2016098152A1 - 情報システム

Info

Publication number: WO2016098152A1
Application number: PCT/JP2014/083108
Authority: WO
Inventors: 純平滝安; 健志北村; 幸二帆波; 信之雑賀
Original assignee: 株式会社日立製作所
Priority date: 2014-12-15
Filing date: 2014-12-15
Publication date: 2016-06-23

Abstract

　本発明の一観点に係る情報システムは、ローカルファイルサーバとクライアントを有する１以上の拠点と、センターファイルサーバを備えたデータセンタとで構成される。ローカルファイルサーバは、ローカルファイルサーバに格納されたファイルが更新された時、更新されたファイルについての情報を更新リストに記録し、更新リストに情報が記録されているファイルをセンターファイルサーバに反映し、その後当該ファイルについての情報を更新リストから削除するための第１プログラム群を有する。ローカルファイルサーバは、第１のプログラム群の実行を継続できなくなった時、プロセッサに第２プログラムの実行を開始させる。第２プログラムが実行されることにより、メモリに残っている、更新されたファイルについての情報が読み出され、当該更新されたファイルについての情報が記憶デバイスに退避される。

Description

情報システム

　本発明は、通信ネットワークに接続されるファイルサーバに関する。

　一般に、サーバやＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）等の計算機では、揮発性記憶媒体で構成される主記憶装置と、ＨＤＤ等の補助記憶装置とを有する。通常は主記憶装置に格納されている情報を用いた運用が行われるが、停止時にはこれらの情報は補助記憶装置に退避される。

　計算機のＯＳに障害が発生した場合、主記憶装置上のデータを補助記憶装置に退避することができないため、必要なデータが消失するおそれがある。この問題を解決するために、たとえば特許文献１には、ＯＳの障害時に、メモリダンプ機能により主記憶装置のデータをまるごとフラッシュメモリ等の補助記憶装置にダンプし、その後、ＯＳの再起動時に補助記憶装置上にダンプされたデータから再び主記憶上にデータを再格納する技術が開示されている。

特開２００９－２６６１１５号公報

　特許文献１に開示の技術では、ＯＳの障害時に主記憶上に格納されていたデータの復旧が可能であるが、データの復旧が完了するまでは、計算機は通常運用ができない状態にある。

　たとえばファイルサーバのように、多くのクライアントから利用される計算機の場合には、障害発生時に迅速に回復できることが求められる。特許文献１に開示の技術ではＯＳの障害時に主記憶の内容をまるごと補助記憶装置にダンプした後にＯＳを再起動し、さらにダンプした内容を読み出してデータの復旧を行う必要があるため、データの復旧が完了するために長時間を要する。本発明の１つの目的は、ＯＳ障害時の復旧を迅速化することにある。

　本発明の一観点に係る情報システムは、ローカルファイルサーバとクライアントを有する１以上の拠点と、センターファイルサーバを備えたデータセンタとで構成される。ローカルファイルサーバは、第１のプログラム群が実行されることにより、ローカルファイルサーバに格納されたファイルが更新された時、前記更新されたファイルについての情報を、前記ローカルファイルサーバのメモリ上に設けられた更新リストに記録し、前記更新リストに前記情報が記録されているファイルを、前記センターファイルサーバに反映し、その後当該ファイルについての情報を、前記更新リストから削除するよう動作する。

　ローカルファイルサーバは、第１のプログラム群の実行を継続できなくなった時、プロセッサに第２プログラムの実行を開始させる。第２プログラムが実行されることにより、ローカルファイルサーバは、
　ａ）メモリから、前記更新リストの存在する領域を特定し、
　ｂ）特定された領域から、前記更新されたファイルについての情報を読み出し、
　ｃ）読み出した更新されたファイルについての情報を、記憶デバイスに格納する
処理を行う。

　本発明によると、ファイルサーバのＯＳがダウンした場合でも、データ損失を生じることなく、迅速にファイルサーバを運用可能状態に復帰させることができる。

実施例に係る情報システムのハードウェア構成図である。実施例に係る情報システムのソフトウェア構成図である。ローカルファイルサーバで稼働する仮想マシンの記憶空間の概念図である。ｉｎｏｄｅの構成を示す図である。ローカルファイルサーバで取り扱われるファイルの内容を示した図である。更新リストの内容を示した図である。データムーバで実行される処理の流れ図である。データムーバで実行される処理の流れ図である。第２カーネル起動時の処理の流れ図である。仮想マシン起動時の処理の流れ図である。

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

　また、以後の説明では「プログラム」を主語として説明を行う場合があるが、実際には、プログラムはプロセッサ（ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ））によって実行されることで、定められた処理が行われる。ただし説明が冗長になることを防ぐため、プログラムを主語として説明することがある。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムは計算機が読み取り可能な記憶メディアに格納され、当該記憶メディアを介して各種プログラムが各装置にインストールされてもよい。記憶メディアとしては、例えば、ＩＣカード、ＳＤカード、ＤＶＤ等であってもよい。あるいは各種プログラムがプログラム配布サーバによって、各装置に配布され、インストールされるようにしてもよい。

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

　「スタブ化」とは、Ｅｄｇｅ（Ｅｄｇｅの計算機システム）のファイルについて、データ（実データ）を削除し、管理情報のみを保持した状態にすることをいう。スタブ化されたファイルは、実データを保持していないため、アクセスされるとＣｏｒｅの計算機システムから実データを取得する必要がある。このため、スタブ化されたファイルへのアクセスは、通常のファイルに比べてアクセス性能が低下する。

　「レプリケーション」とは、Ｅｄｇｅで作成・更新されたファイルをＣｏｒｅにコピー（複製）することをいう。また、ＥｄｇｅにあるファイルをＣｏｒｅにコピーすることで、ＥｄｇｅとＣｏｒｅにあるファイルの内容が同じになるため、「レプリケーション」のことを「同期」と呼ぶこともある。「マイグレーション」とは、ＥｄｇｅにあるファイルをＣｏｒｅにレプリケーションした後、Ｅｄｇｅのファイルをスタブ化することをいう。

　「ファイルシステム」とは一般に、記憶デバイスに格納されたデータの検索や操作を行うためのプログラムのことを意味することもあれば、あるいはデータの検索や操作を可能にするために記憶デバイス上に作成されたデータ構造を意味することもある。本明細書では混同を避けるため、記憶デバイスに格納されたデータの検索や操作を行うためのプログラムのことを「ファイルシステムプログラム」と呼び、記憶デバイス上に作成されたデータ構造のことを「ファイルシステム」と呼ぶ。

　「マウント」とは、アプリケーションプログラムやオペレーティングシステムがファイルシステムにアクセスできるようにするための手続き（処理）を意味する。ある記憶デバイスに格納されているデータ構造（ファイルシステム）にアクセスできるようにする手続きのことを、「ファイルシステムをマウントする」という。

　「デバイスファイル」とは、オペレーティングシステムが、ディスクなどの入出力装置にアクセスするためのインタフェースのことを指す。以下で説明する実施例におけるローカルファイルサーバ３０で実行されるオペレーティングシステム（第１カーネルなど）は、論理ユニット（ＬＵ）等の記憶デバイスごとに固有のデバイスファイル名を付して管理している。ローカルファイルサーバ３０上で実行されるプログラムは、デバイスファイル名を指定してアクセス要求を発行することで、ＬＵにアクセスすることができる。

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

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

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

　ストレージ装置２０は、ストレージコントローラ（ＣＴＬと略記されることもある）２１とＤＩＳＫ２３とを備える。ストレージコントローラ２１は、ローカルファイルサーバ３０に接続される通信インタフェースや、ＤＩＳＫ２３へのＩ／Ｏ要求を処理するためのプロセッサなどを備えた装置である。ＤＩＳＫ２３は、ローカルファイルサーバ３０からのライトデータを格納する、不揮発性の記憶デバイスである。一例として、ＨＤＤ（Hard　Disk　Drive）をＤＩＳＫ２３に用いることができる。ただしＨＤＤ以外に、ＳＳＤ（Solid　State　Drive）などの記憶デバイスを、ＤＩＳＫ２３に適用してもよい。

　ＣＴＬ２１、ＤＩＳＫ２３は、図１ではそれぞれ１つのみが存在する構成が示されているが、複数存在しても良い。複数のＤＩＳＫ２３で、１以上のＲＡＩＤグループが構成されてよい。

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

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

　メモリ３１は、例えばＲＡＭ（Random　Access　Memory）等の、高速アクセス可能な記憶デバイスである。ローカルファイルサーバ３０では、ＣＰＵ３２がメモリ３１上に格納されたローカルファイルサーバ３０を制御するプログラム（例えばＯＳ（Operating　System）カーネルプログラム）を実行する。ローカルファイルサーバ３０は、メモリ３１に加えて又は代えて、別種の記憶資源を有してもよい。メモリ３１は、記憶デバイスの一例である。

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

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

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

　本発明の実施例に係る情報システムの利用者であるユーザ１は、各Ｅｄｇｅ１０に移動可能で、任意のＥｄｇｅ１０にあるクライアント４０を利用することができる。

　続いて、Ｃｏｒｅ１００に配置される計算機システムの構成を説明する。Ｃｏｒｅ１００の計算機システムは、センターファイルサーバ１２０と、センターファイルサーバ１２０に接続されたストレージ装置１１０とを備える。センターファイルサーバ１２０は、各Ｅｄｇｅのローカルファイルサーバ３０に格納されたデータを受信し、ストレージ装置１１０に保存するための装置である。センターファイルサーバ１２０とストレージ装置１１０は、一種のアーカイブ装置（アーカイブシステム）の役割を果たしている。

　ストレージ装置１１０は、ストレージコントローラ（図中ではＣＴＬと表記）１１１とＤＩＳＫ１１３とを備える。本実施例では、ストレージ装置１１０の構成とストレージ装置２０の構成が同一とする。ただしストレージ装置１１０に、ストレージ装置２０と異なるハードウェア構成を採用するストレージ装置が用いられてもよい。

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

　図２は、実施例に係る情報システムのソフトウェア構成図である。ストレージ装置２０（１１０）では、ＣＴＬ２１（１１１）が１以上のＤＩＳＫ２３の記憶領域を用いて、１または複数のＬＵ（Logical　Unit）２４（１１４）を形成し、ローカルファイルサーバ３０（センターファイルサーバ１２０）に提供している。ローカルファイルサーバ３０（センターファイルサーバ１２０）は、ストレージ装置２０（１１０）から提供されるＬＵ２４（１１４）に対して、ファイルを格納する。

　また、ストレージ装置２０（１１０）が提供するＬＵに対して、ローカルファイルサーバ３０（センターファイルサーバ１２０）が使用する各種プログラムが格納されていても良い。本実施例に係る情報システムでは、ストレージ装置２０（１１０）が形成するＬＵ２５（１１５）に、ローカルファイルサーバ３０（センターファイルサーバ１２０）が使用する各種プログラムが格納される構成を採る。このＬＵ２５（１１５）のことを、ＬＵ２４（１１４）と区別するために、ＯＳ　ＬＵ２５（１１５）と呼ぶ。

　続いてローカルファイルサーバ３０及びセンターファイルサーバ１２０が実行する各種プログラムについて説明する。ローカルファイルサーバ３０のメモリ３１及びセンターファイルサーバ１２０のメモリ１２１には、データムーバプログラム３７（１２５）と、ファイルシステムプログラム３６（１２６）が格納されている。ローカルファイルサーバ３０のメモリ３１には、更に、ファイル共有プログラム３５、第１カーネル３８、第２カーネル３８－２、ハイパーバイザ３９が格納されている。またセンターファイルサーバ１２０のメモリ１２１には、カーネル１２７が格納されている。なお、ローカルファイルサーバ３０が実行するプログラムは、ローカルファイルサーバ３０の起動前には、ＯＳ　ＬＵ２５に格納されている。またセンターファイルサーバ１２０が実行するプログラムは、センターファイルサーバ１２０の起動前には、ＯＳ　ＬＵ１１５に格納されている。

　以下、ローカルファイルサーバ３０内のデータムーバプログラム３７を、「ローカルムーバ」と言い、センターファイルサーバ１２０内のデータムーバプログラム１２５を、「リモートムーバ」と言い、それらを特に区別しない場合に、「データムーバプログラム」と言う。ローカルファイルサーバ３０とセンターファイルサーバ１２０との間では、ローカルムーバ３７及びリモートムーバ１２５を介して、ファイルのやり取りが行われる。

　第１カーネル３８（カーネル１２７）は、ローカルファイルサーバ３０（センターファイルサーバ１２０）上で動作する複数のプログラム（プロセス）のスケジュール制御を行うプログラムで、いわゆるオペレーティングシステム（ＯＳ）の中核をなすプログラムである。また、ハードウェアの制御を行うためのプログラムである、いわゆるデバイスドライバも第１カーネル３８（カーネル１２７）に含まれている。

　第２カーネル３８－２も第１カーネル３８と同様のプログラムであるが、第２カーネル３８－２の詳細は後述する。ハイパーバイザ３９は、ローカルファイルサーバ３０上でいわゆる仮想マシンを稼働させるプログラムである。ハイパーバイザ３９の詳細も後述する。

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

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

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

　ローカルファイルサーバ３０がファイルを格納するために用いるＬＵ２４内には、メタデータ領域２４１と実データ領域２４２というデータ構造が構築されている。メタデータ領域２４１には、各ファイルの管理情報であるｉｎｏｄｅが格納され、実データ領域２４２にはファイルの実データが格納される。ＬＵ２４内のこのデータ構造は、ローカルファイルサーバ３０がはじめてＬＵ２４を使用する際に、ファイルシステムプログラム３６が作成する。またセンターファイルサーバ１２０がファイルを格納するために用いるＬＵ１１４にも、上で説明したものと同様のデータ構造が構築される。これはファイルシステムプログラム１２６が、ＬＵ１１４を初めて使用する際に作成する。

　本実施例では、ＬＵ２４（１１４）内に構築される、上で説明したデータ構造のことを、「ファイルシステム」と呼ぶ。そしてこのファイルシステムをＬＵ２４（１１４）内に作成する処理は、「ファイルシステムを作成する」と呼ぶ。一般に「ファイルシステム」とは、ファイルを格納する記憶デバイス上に構築されるデータ構造以外に、このデータ構造を解釈して、ユーザの要求に応じてデータの操作を行うためのプログラムを意味することもある。しかし本明細書では、ファイルシステムプログラム３６（１２６）との混同を避けるため、ＬＵ２４（１１４）内に構築されたデータ構造のことを「ファイルシステム」と呼ぶ。そして、このファイルシステムの内容を解釈してデータ（ファイル）操作を行うためのプログラム（ファイルシステムプログラム３６（１２６））のことを、「ファイルシステムプログラム」と呼ぶ。

　１つのＬＵ２４を複数のパーティションに分割し、各パーティションにファイルシステムを作成すること、つまり１つのＬＵ２４内に複数のファイルシステムを作成することも可能である。ただし本実施例では、１つのＬＵ２４にファイルシステムを１つだけ作成する場合の例について説明する。

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

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

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

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

　リンク先２２０ｈには、このｉｎｏｄｅ２０１で管理されるファイルの実データの、Ｃｏｒｅ１００内での格納先（リンク先）を表す情報が格納される。具体的にはリンク先２２０ｈには、センターファイルサーバ１２５内での格納場所の情報が格納される。格納場所の情報の表記方法としては、たとえばＵＲＬ（Uniform　Resource　Locator）が用いられる。またセンターファイルサーバ１２０のデータムーバプログラム１２５が格納場所を決定する。そしてローカルファイルサーバ３０からの要求に応じてセンターファイルサーバ１２０がファイルを転送する際に、リンク先２２０ｈを含むファイル管理情報もローカルファイルサーバ３０に転送される。

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

　ローカルムーバ３７はレプリケーション処理を実施する際、ファイルシステムプログラム３６を用いて、レプリケーション対象のファイル（ｉｎｏｄｅ２０１及びｉｎｏｄｅのデータブロックアドレス２２０ｉで指し示されているファイルの実データ）を読み出す。そしてローカルムーバ３７は、読み出されたファイルをセンターファイルサーバ１２０に転送する。リモートムーバ１２５は、ローカルムーバ３７から転送されてきたファイル（レプリケーション対象のファイル）を、ファイルシステムプログラム１２６を用いてストレージ装置１１０のＬＵ１１４に書き込む。ファイルのセンターファイルサーバ１２０への転送が完了すると、ローカルムーバ３７は、ファイルシステムプログラム３６を用いて、ＬＵ２４に格納されている対象ファイルのレプリケーション済みフラグ２２０ｇを“１”にする。また、後述する更新リスト４０２の内容の更新を行う。更新リスト４０２については後述する。

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

　なお、本実施例に係るローカルファイルサーバ３０では、１つのファイルシステムについて、１つのローカルムーバ３７と１つのファイル共有プログラム３５が実行される。そのため、たとえばローカルファイルサーバ３０で２個のファイルシステムが作成されている場合（仮にそれぞれのファイルシステムを、ファイルシステムＡ，ファイルシステムＢと呼ぶ）、ローカルファイルサーバ３０では、ファイルシステムＡに対する処理を担当するローカルムーバ３７とファイル共有プログラム３５が実行されるとともに、ファイルシステムＢに対する処理を担当するローカルムーバ３７とファイル共有プログラム３５が実行される。以下では、あるファイルシステム（仮に「ファイルシステムＸ」と呼ぶ）についての処理を担当するローカルムーバ３７とファイル共有プログラム３５のことをそれぞれ、「ファイルシステムＸ用のローカルムーバ３７」、「ファイルシステムＸ用のファイル共有プログラム３５」と呼ぶ。

　ただし、１つのローカルムーバ３７が複数のファイルシステムについての処理を担当する構成を採ってもよい。同様に、１つのファイル共有プログラム３５が複数のファイルシステムについての処理を担当する構成を採ってもよい。

　管理ソフト７０は、ローカルファイルサーバ３０の管理を行うためのソフトウェアである。ローカルファイルサーバ３０の管理者（ユーザ）が、保守作業のためにローカルファイルサーバ３０を停止（シャットダウン）する場合、あるいはローカルファイルサーバ３０にファイル同期を指示する場合等に、管理ソフト７０が用いられる。管理ソフト７０は、ローカルファイルサーバ３０の管理者（ユーザ）に、ＧＵＩあるいはＣＬＩを提供し、管理者はこのＧＵＩあるいはＣＬＩを用いてローカルファイルサーバ３０に指示を出す。管理ソフト７０は、第１カーネル３８、ハイパーバイザ３９、あるいはデータムーバプログラム３７のプログラムの一部として実装されていてもよい。

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

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

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

　続いて、ローカルファイルサーバ３０の、第１カーネル３８、第２カーネル３８－２、ハイパーバイザ３９について、図３を用いて説明する。ハイパーバイザ３９は、ローカルファイルサーバ３０上でいわゆる仮想マシンを稼働させるプログラムである。本実施例に係るローカルファイルサーバ３０では、ハイパーバイザ３９は少なくとも２つの仮想マシンを稼働させる。以下、２つの仮想マシンのうち、一方をＶＭ＃１（図３の要素３９１）、もう一方をＶＭ＃２（図３の要素３９２）と呼ぶ。

　よく知られているように、ハイパーバイザ３９はローカルファイルサーバ３０中の物理資源であるＣＰＵ３２やメモリ３１等を仮想化し、仮想化されたメモリ及び仮想化されたＣＰＵを用いて仮想マシンを作成する。そして本実施例に係るローカルファイルサーバ３０では、第１カーネル３８等のプログラムは、仮想マシン上の仮想的なＣＰＵ、仮想的なメモリを用いて実行される。（仮想マシンには、仮想化されたＣＰＵや仮想化されたメモリ以外にも、仮想化された資源が存在する。たとえば仮想化された入出力デバイス（ネットワークデバイス等）も存在するが、本実施例の説明には直接関係するものではないため、説明を省略する）

　ＶＭ＃１（３９１）に割り当てられた仮想的なメモリで構築される記憶空間を、ＶＭメモリ空間３１１と呼ぶ。またＶＭ＃２（３９２）に割り当てられた仮想的なメモリで構築される記憶空間を、ＶＭメモリ空間３１２と呼ぶ。ＶＭメモリ空間３１１とＶＭメモリ空間３１２は原則として、同じサイズの空間である。またＶＭメモリ空間３１１上で動作するプログラムは、ＶＭメモリ空間３１２に直接アクセスすることはできない。逆にＶＭメモリ空間３１２上で動作するプログラムも、ＶＭメモリ空間３１１に直接アクセスすることはできない。

　通常時（障害が発生していないとき）、第１カーネル３８はＶＭ＃１またはＶＭ＃２のいずれか一方でのみ実行される。図３ではＶＭ＃１でのみ、第１カーネル３８が実行されている状態を表している。この時、第１カーネル３８はＶＭメモリ空間３１１上に格納され、仮想的なＣＰＵ（非図示）により実行される。

　また第１カーネル３８がＶＭ＃１で実行を開始する時（起動される時）、第１カーネル３８はＶＭメモリ空間３１１上の所定の記憶領域（図３の、第２カーネル用領域３１１’）を確保する。そして第１カーネル３８は、第２カーネル用領域３１１’上の一部の領域に第２カーネル３８－２（先にも述べたとおり、これはプログラムである）を格納する。

　なお、第２カーネル３８－２は、通常時は実行されない。詳細は後述するが、プログラムの不具合等の問題のために第１カーネル３８の実行が停止した時に、第２カーネル３８－２の実行が開始される。第１カーネル３８は通常時、ＶＭメモリ空間３１１のうち、第２カーネル用領域３１１’以外の領域を用いる（ＶＭメモリ空間３１１のうち、第２カーネル用領域３１１’以外の領域を用いて、ファイルシステムプログラム３６等の各種プログラムがロードされ、また実行される）。第２カーネル３８－２の動作については、後述する。

　続いて、ローカルファイルサーバ３０で管理される各ファイルについて、図５を用いて説明する。クライアント４０を使用するユーザによって、ローカルファイルサーバ３０に作成されるファイル（または更新されるファイル）のことを、「ユーザファイル」と呼ぶ。なお、ユーザファイルには、ユーザによって作成／更新されるディレクトリも含まれる。

　またローカルファイルサーバ３０は、各ＬＵ２４内に１つずつ、更新リスト４０２という管理情報（ファイル）を作成する。更新リスト４０２はファイルシステムプログラム３６によって管理されるファイルの１つであるが、ユーザによって作成されるものではない。ローカルムーバ３７が作成する。更新リスト４０２は、ファイルシステム中の、たとえばルートディレクトリ直下に作成される。また、ＬＵ２４が複数存在する場合、更新リスト４０２はＬＵ２４ごとに作成される。つまり更新リストは、１つのファイルシステムにつき１つ作成される。

　更新リスト４０２の例を、図６に示す。図６に示すように、更新リスト４０２内には、ＭＡＧＩＣ　Ｎｕｍｂｅｒ　４１１とパス名リスト４１２のセットが複数並んで格納されている。ＭＡＧＩＣ　Ｎｕｍｂｅｒ　４１１は、所定の規則で作成された文字列（バイト列）である。これにより、ＭＡＧＩＣ　Ｎｕｍｂｅｒ　４１１の直後に格納されているデータ（つまりパス名リスト４１２）が、更新リスト４０２の内容であることを識別できるように設けられている。パス名リスト４１２は、センターファイルサーバ１２０に反映すべきファイルのファイル名が、フルパスで格納されている。

　１つの更新リスト４０２内の全てのＭＡＧＩＣ　Ｎｕｍｂｅｒ４１１には、同一のバイト列が格納されている。ただしローカルファイルサーバ３０が複数のＬＵ２４にファイルシステムを構築し、それぞれのＬＵ２４にファイルを格納する構成の場合、更新リスト４０２毎に異なるＭＡＧＩＣ　Ｎｕｍｂｅｒ４１１が用いられる。本実施例に係るローカルファイルサーバ３０では、第１カーネル３８が各ＬＵ２４に付しているデバイスファイル名（／ｄｅｖ／ｓｄ１ｃなどのファイル名）が、ＭＡＧＩＣ　Ｎｕｍｂｅｒ４１１の中に含まれるようにする。

　ＭＡＧＩＣ　Ｎｕｍｂｅｒ　４１１とパス名リスト４１２はそれぞれ、固定サイズである。たとえば、ＭＡＧＩＣ　Ｎｕｍｂｅｒ　４１１のサイズが３２バイト、パス名リスト４１２のサイズが９９２バイトである。これにより、ＭＡＧＩＣ　Ｎｕｍｂｅｒ　４１１は、更新リスト４０２内に１ＫＢ間隔で配置される。センターファイルサーバ１２０に反映すべきファイルのファイル名が非常に多く、１つのパス名リスト４１２にすべてのファイル名を格納しきれない場合がある。その場合、１番目のパス名リスト４１２に格納できなかったファイル名は、２番目以降のパス名リスト４１２に格納される。また、各パス名リスト４１２に格納されている最後のファイル名の直後にはＮＵＬＬが格納される。

　なお、パス名リスト４１２にファイル名（パス名）を格納する構成に代えて、ｉｎｏｄｅ番号を格納するようにしてもよい。

　更新リスト４０２は、最終的にＬＵ２４に格納されるが、ローカルファイルサーバ３０が更新リスト４０２の内容を編集（反映すべきファイルのファイル名を追加する等）する場合、ＶＭメモリ空間３１１上で編集を行う。そして更新リスト４０２は原則として、ＶＭメモリ空間３１１上に常駐し、更新リスト４０２の編集（更新）とは非同期（たとえば１０分間隔等）に、ＬＵ２４に反映される。そのため、ローカルファイルサーバ３０で短期間に多数のユーザファイル４０１の更新が発生した場合でも、原則としてメモリ上（ＶＭメモリ空間３１１上）に存在する更新リスト４０２のみが更新される。結果として、ＬＵ２４への書き込み（更新リスト４０２の書き込み）が多数発生することを防ぎ、システム性能が低下することを防ぐことができる。なお、別の実施形態として、更新リスト４０２を非同期にＬＵ２４に反映する処理も行わない態様もあり得る。

　また、ローカルファイルサーバ３０の管理者からの指示により、第１カーネル３８が停止（シャットダウン）される場合もある。この事象はたとえば、ローカルファイルサーバ３０の保守を行う場合等に発生し得る。この場合、第１カーネル３８の停止前に、ＶＭメモリ空間３１１上の更新リスト４０２の内容は、ＬＵ２４に反映される。

　続いてフラグファイル４０３について説明する。フラグファイル４０３は、ローカルムーバ３７によって作成されるファイルで、ＬＵ２４に格納される。ＬＵ２４が複数ある場合、各ＬＵ２４にフラグファイルが格納される。フラグファイル４０３は、ローカルファイルサーバ３０の起動時に、前回ローカルファイルサーバ３０が異常停止したか否かを判定するために用いられる。具体的な用いられ方は後述する。

　フラグファイル４０３のファイル名は、ＬＵ２４のルートディレクトリに格納されるどのファイル名とも異なる名称のファイル名（たとえば“．ｆｌａｇｆｉｌｅ”という名称）である。またフラグファイル４０３は、実データを持たないファイル（サイズが０バイトのファイル）であってよい。なお、上ではフラグファイル４０３がＬＵ２４に格納される例について説明したが、ＯＳ　ＬＵ２５にフラグファイルを格納するという規則を採用してもよい。

　続いて、ローカルムーバ３７の処理フローを、図７、図８を用いて説明する。なお、以下ではＶＭ＃１（３９１）で第１カーネル３８、ローカルムーバ３７、ファイル共有プログラム３５、ファイルシステムプログラム３６が実行されている場合、つまりこれらのプログラムがＶＭメモリ空間３１１上にロードされて実行されている場合について中心に説明する。そのため、ＶＭメモリ空間３１１のことを「メモリ」と略記することもあるが、特に断りのない限り、「メモリ」とはＶＭメモリ空間３１１のことを指す。

　ローカルムーバ３７は、第１カーネル３８の起動時に、第１カーネル３８によってメモリ（ＶＭメモリ空間３１１）に読み込まれ、その実行が開始される。またその時点では、ファイル共有プログラム３５とファイルシステムプログラム３６もＶＭメモリ空間３１１上にロードされ、実行を開始している。

　ローカルムーバ３７の実行が開始されると、ローカルムーバ３７はＬＵ２４にフラグファイル４０３が存在するか確認する。フラグファイル４０３が存在した場合（Ｓ５０１：Ｙ）、そのＬＵ２４内の全ファイルについて、レプリケーション済みフラグ２２０ｇの内容をチェックする（Ｓ５０２）。そしてローカルムーバ３７は、メモリ上で更新リスト４０２を作成するとともに、レプリケーション済みフラグ２２０ｇが“０”であるファイルのファイル名を、更新リスト４０２に格納する（Ｓ５０３）。ここで作成された更新リスト４０２は、ＬＵ２４にも格納される。

　Ｓ５０３の後、ローカルムーバ３７はフラグファイル４０３をＬＵ２４に作成し（Ｓ５０４）、イベントを待つ（Ｓ５０５）。なお、Ｓ５０２，Ｓ５０３が実行された時には、フラグファイル４０３が存在しているので、Ｓ５０４は必ずしも実行されなくともよい。図７、図８の処理フローの説明において、イベントとは、ユーザあるいは他のプログラム（たとえばファイルシステムプログラム３６等）からの処理要求のことをいう。イベントには処理の種別（以下では「イベント種別」と呼ぶ）と、その処理に必要な情報が含まれている。ローカルムーバ３７はイベントを受信すると、イベントに含まれているイベント種別で指定されている処理を行う。イベントは原則として、ローカルムーバ３７以外のプログラムから発行される要求である。ただしローカルムーバ３７自身がイベントを発行し、そのイベントをローカルムーバ３７が受信することで、ローカルムーバ３７がそのイベントで指定された処理を行うこともある。

　Ｓ５０６でローカルムーバ３７は、イベント種別を判別する。イベントには少なくとも、同期イベント、ファイル更新イベント、ＯＳ停止イベントがある。ローカルムーバ３７が同期イベントを受信すると、ローカルファイルサーバ３０に格納されているファイルのうち、まだセンターファイルサーバ１２０にレプリケーションされていないファイルを、センターファイルサーバ１２０にコピーする処理を行う。この処理を「同期処理」と呼ぶ。ローカルファイルサーバ３０の管理者が、管理ソフト７０を用いてローカルムーバ３７に同期指示（同期イベントと呼ぶ）を発行することで、ローカルムーバ３７に同期イベントが受信され、同期処理が開始される。また、ローカルムーバ３７が定期的（５分間隔等）に同期イベントを発行するようにしてもよい。この場合ローカルムーバ３７が、自身が発行した同期イベントを受信することで、同期処理が開始される。

　受信したイベントが同期イベントの場合（Ｓ５０６：Ｙ）、ローカルムーバ３７は更新リスト４０２を読み出す（Ｓ５０７）。更新リスト４０２を読み出す際、更新リスト４０２がメモリ（ＶＭメモリ空間３１１）にある場合には、メモリ上の更新リスト４０２を読み出す。なお、たとえばローカルファイルサーバ３０の起動直後等にはメモリ上に更新リスト４０２が存在しない場合がある。その場合、ローカルムーバ３７はＬＵ２４上の更新リスト４０２を読み出してメモリ上に格納する。また、ファイルシステムを構築したＬＵ２４が複数存在する場合、ＬＵ２４毎に更新リスト４０２が存在する。そのため、各ＬＵ２４の更新リスト４０２を読み出す。

　続いてローカルムーバ３７は、ファイルシステムプログラム３６を用いて、更新リスト４０２に記録されている更新対象ファイルをＬＵ２４から読み出す。そして読み出されたファイルをセンターファイルサーバ１２０に転送する（Ｓ５０８）。

　センターファイルサーバ１２０へのファイル転送が完了すると、ローカルムーバ３７は転送の完了したファイルのレプリケーション済みフラグ２２０ｇに“１”を格納する（Ｓ５０９）。そしてローカルムーバ３７は更新リスト４０２に記録されているファイル名（転送の完了したファイルのファイル名）を削除する（Ｓ５１０）。その後処理は、再びＳ５０５に戻り、ローカルムーバ３７はイベントの到着を待つ。

　受信したイベントがファイル更新イベントの場合（Ｓ５０６：Ｎ、かつＳ５２１：Ｙ）、ファイル更新処理が実施される。ファイル更新イベントは、ファイル共有プログラム３５が発行する、ファイル作成または更新の指示である。ファイル共有プログラム３５は、クライアント４０からファイル作成または更新要求を受信すると、ローカルムーバ３７に更新イベントを発行する。更新イベントには、作成（または更新）対象のファイル名、ファイルの実データが含まれている。ローカルムーバ３７は、更新イベントを受信すると、ファイルシステムプログラム３６に対してファイルの作成または更新を指示する（Ｓ５２２）。ファイルシステムプログラム３６は、ファイルの作成または更新の指示を受信すると、ファイルをＬＵ２４に格納するとともに、作成（または更新）対象のファイルのレプリケーション済みフラグ２２０ｇに“０”を格納する。

　続いてローカルムーバ３７は、更新リスト４０２に、作成（または更新）対象ファイルのファイル名を追加する（Ｓ５２３）。この時、原則として、更新リスト４０２はメモリ上に存在する。そのためローカルムーバ３７は、メモリ上の更新リスト４０２にファイル名を追加する処理を行う。もし更新リスト４０２がメモリ上に存在しない場合には、ＬＵ２４から更新リスト４０２を読み出してメモリ上に格納する。そしてメモリ上に格納された更新リスト４０２にファイル名を追加する処理を行う。Ｓ５２３の処理が完了すると、処理はＳ５０１に戻る。

　また、ローカルムーバ３７は、メモリ上の更新リスト４０２をＬＵ２４に格納する処理を行ってもよい（Ｓ５２５）。この処理は、Ｓ５２３の処理とは独立した契機で（たとえば数分間隔で）実施すればよい。Ｓ５２５の処理は必須ではない。

　受信したイベントがＯＳ停止イベントの場合（Ｓ５０２：Ｎ、かつＳ５２１：Ｎ、かつＳ５３１：Ｙ）、ローカルファイルサーバ３０の停止（シャットダウン）が行われる。ＯＳ停止イベントは、管理者が管理ソフト７０を用いてＯＳ停止の指示を行った時に、管理ソフト７０によって発行されるイベントである。ローカルムーバ３７がＯＳ停止イベントを受信すると（Ｓ５３１：Ｙ）、ローカルムーバ３７はメモリ上に格納されている更新リスト４０２をＬＵ２４に格納する（Ｓ５３２）。

　続いてローカルムーバ３７は、フラグファイル４０３を削除する（Ｓ５３３）。本実施例に係るローカルファイルサーバ３０では、第１カーネル３９やローカルムーバ３７が実行中の間、フラグファイル４０３がＬＵ２４に格納されている。そしてＯＳ（第１カーネル３９）の停止時には、フラグファイル４０３を削除するという規則でローカルファイルサーバ３０が運用されている。これにより、第１カーネル３９の起動時に、フラグファイル４０３の有無を確認することで、以前ローカルファイルサーバ３０が停電等の要因で異常終了したか否かを判定することができる。起動時にフラグファイル４０３が存在しない場合には、起動前にローカルファイルサーバ３０は正常に停止したことを意味する。逆に起動時にフラグファイル４０３が存在した場合には、起動前にローカルファイルサーバ３０が異常停止したことを意味する。

　なお、ＬＵ２４が複数ある場合、ＶＭ＃１（３９１）上で複数のローカルムーバ３７が実行されている。ＯＳ停止イベントを受信したローカルムーバ３７は、ＶＭ＃１（３９１）上で実行中の、その他の全てのローカルムーバ３７に対して、更新リスト４０２をＬＵ２４に格納する指示、及びフラグファイル４０３を削除する指示を出す。この指示を受信したローカルムーバ３７は、自身が処理を担当するＬＵ２４（ファイルシステム）に更新リスト４０２を格納する処理、そしてフラグファイル４０３を削除する処理を行う。

　フラグファイル４０３を削除した後、ローカルムーバ３７はＯＳの停止（シャットダウン）を行う（Ｓ５３４）。具体的には、ＶＭ＃１（３９１）で実行されている第１カーネル３８に、シャットダウン要求を発行することで、ＯＳを停止させる。ＯＳが停止する際、ローカルムーバ３７をはじめ、ＶＭ＃１（３９１）上で実行されている全プログラムは終了する。

　次に、第１カーネル３８が異常終了した時に、ローカルファイルサーバ３０で行われる処理の流れを説明する。本実施例に係るローカルファイルサーバ３０の第１カーネル３８は、プログラムの不具合やハードウェアの異常により、処理を継続できないと判断した時、第１カーネル３８の実行を停止するとともに、第２カーネル用領域３１１’にあらかじめロードしてある第２カーネル３８－２を起動させる機能を持つ。

　第２カーネル３８－２は、第１カーネル３８と同様のプログラムである。ただし第２カーネル３８－２は、更新リスト４０２の復旧を行うために実行されるプログラムである。そのため更新リスト４０２の復旧に必須でないプログラムは含まれていない点が、第１カーネル３８と異なる。更新リスト４０２の復旧の際、ストレージ装置２０のＬＵ２４へのアクセスは必須であるため、第２カーネル３８－２は少なくとも、ＬＵ２４（そしてＯＳ　ＬＵ２５）にアクセスするためのディスクデバイスドライバを含んでいる。また更新リスト４０２の復旧が完了すると、第２カーネル３８－２は実行を終了する。

　第１カーネル３８によって第２カーネル３８－２が起動された後、第２カーネル３８－２によって行われる処理の流れを、図９を用いて説明する。なお、上での説明と同様、第２カーネル３８－２が、ＶＭ＃１（３９１）で実行される場合を例にとって説明する。そのため、第２カーネル３８－２及びその他のプログラムはＶＭメモリ空間３１１の第２カーネル用領域３１１’に格納される。また、以下の説明では、ＶＭメモリ空間３１１のことを「メモリ」と呼ぶ。

　第２カーネル３８－２はまず、ＶＭ＃２（３９２）上で、ＯＳを起動させる（Ｓ６０１）。これはハイパーバイザ３９に指示を発行することで、ＶＭ＃２（３９２）上でのＯＳの起動が実施される。この時の起動処理の詳細は後述する。

　続いて第２カーネル３８－２は、メモリの全領域（ＶＭメモリ空間３１１全体）を検索し、メモリ上に更新リスト４０２が格納されている領域を特定する（Ｓ６０２）。更新リスト４０２には、ＭＡＧＩＣ　Ｎｕｍｂｅｒ４１１が含まれているので、第２カーネル３８－２はこのＭＡＧＩＣ　Ｎｕｍｂｅｒ４１１を検索することで、更新リスト４０２の格納されているメモリ上の領域を特定する。

　ただし、メモリ上にある更新リストの特定方法は、ここで説明する方法に限定されない。メモリ上に格納されている更新リスト４０２を特定できる方法であれば、任意の方法を使用することができる。たとえば更新リスト４０２をメモリ上に作成する場合、必ずメモリ上のあらかじめ決められたアドレスに更新リスト４０２を作成するようにしてもよい。このような方法で更新リスト４０２を作成すると、第２カーネル３８－２はメモリ上のあらかじめ決められたアドレスからデータを読み出すことで、更新リスト４０２を読み出すことができる。

　メモリ上に存在した更新リスト４０２を特定すると、第２カーネル３８－２は特定された更新リスト４０２をＬＵ２４に反映する（Ｓ６０３）。更新リスト４０２のＭＡＧＩＣ　Ｎｕｍｂｅｒ４１１には、更新リスト４０２が格納されるべきＬＵ２４のデバイスファイル名が含まれている。そのため、第２カーネル３８－２は、メモリ上の更新リスト４０２が反映されるべきＬＵ２４を容易に特定できる。その後第２カーネル３８－２は、更新リスト４０２がＬＵ２４に反映されたことを、ＶＭ＃２（３９２）に通知する。この通知には、更新リスト４０２が反映されたＬＵ２４を特定できる情報（デバイスファイル名等）が含まれている。

　なお、ローカルファイルサーバ３０で複数のファイルシステムが構築されている場合がある。その場合、複数の更新リスト４０２がメモリ上に存在する。複数の更新リスト４０２がメモリ上に存在する場合には、第２カーネル３８－２はＳ６０２～Ｓ６０４の処理を繰り返す。

　メモリ上に存在したすべての更新リスト４０２について、Ｓ６０２～Ｓ６０４の処理が完了したら（Ｓ６０５：Ｙ）、第２カーネル３８－２はＶＭ＃２（３９２）に、全てのＬＵ２４について更新リスト４０２の復旧が完了した旨を通知する（Ｓ６０６）。その後第２カーネル３８－２は処理を停止する（Ｓ６０７）。停止の際、第２カーネル３８－２はハイパーバイザ３９に対し、ＶＭ＃１（３９１）の停止を依頼する。ハイパーバイザ３９はこの依頼を受信すると、ＶＭ＃１（３９１）を停止する。ただしＶＭ＃１（３９１）の停止は必須の処理ではない。ＶＭ＃２（３９２）上で稼働するＯＳ（第１カーネル３９）が異常終了した際に、即座にＶＭ＃１（３９１）で第１カーネルを起動できるようにするために、ＶＭ＃１（３９１）を稼働状態にしておいてもよい。

　続いて、仮想マシン（ＶＭ＃１またはＶＭ＃２）上で、ＯＳが起動される時の処理の流れを説明する。なお、以下では、ＶＭ＃２（３９２）上でＯＳが起動される場合について説明する。

　仮想マシン上での、ＯＳの起動の契機には何通りかの契機が存在する。１つは、上で述べたように、ＶＭ＃１（３９１）で実行されていた第２カーネル３８－２が、ＶＭ＃２（３９２）上でのＯＳの起動を要求する場合がある。またそれ以外に、管理者（ユーザ）がローカルファイルサーバ３０の電源をＯＮにした契機で、ハイパーバイザ３９から、仮想マシン（ＶＭ＃１またはＶＭ＃２）上でのＯＳの起動を指示される場合がある。本実施例に係る仮想マシンでは、第２カーネル３８－２がＯＳの起動を要求しているのか、それ以外の要因でＯＳの起動が行われたのか、認識できる機能を持つ。具体的には第１カーネル３８が起動される際、ハイパーバイザ３９から起動契機についての情報が、第１カーネル３８に渡される。

　以下、図１０を用いて、ＶＭ＃２（３９２）上でのＯＳ起動時の処理の流れを説明する。ＯＳの起動が指示されると、ＶＭ＃２（３９２）は第１カーネル３８をＶＭメモリ空間３１２上にロードして、第１カーネル３８の実行を開始する（Ｓ１０１０）。第１カーネル３８の実行が開始されると、第１カーネル３８はＶＭメモリ空間３１２上に第２カーネル用領域３１１’を確保する。そして第１カーネル３８は第２カーネルを、第２カーネル用領域３１１’にロードする。

　次に第１カーネル３８は、起動時に渡されている起動契機についての情報を参照し、ＶＭ＃１上の第２カーネル３８－２からＯＳの起動を要求されたのか否かを判定する。ＶＭ＃１上の第２カーネル３８－２からＯＳの起動を要求された場合（Ｓ１０３０：Ｙ）、ＶＭ＃１上では、上で図９を用いて説明した処理、つまり更新リスト４０２の復旧処理が行われていることを意味する。そのため、第１カーネル３８は、ＶＭ＃１からの通知（特定のＬＵ２４の更新リスト４０２が復旧された旨の通知、あるいは全ＬＵ２４について更新リスト４０２の復旧が完了した旨の通知）を待つ（Ｓ１０４０）。

　ＶＭ＃１から通知を受領すると（Ｓ１０４０：Ｙ）、第１カーネル３８はその通知が、全ＬＵ２４について更新リスト４０２の復旧が完了した旨の通知か否かを判定する（Ｓ１０５０）。特定のＬＵ２４の更新リスト４０２が復旧された旨の通知であった場合（Ｓ１０４０：Ｎ）、その通知には、復旧された更新リスト４０２が格納されたＬＵ２４を特定する情報（デバイスファイル名等）が含まれている。第１カーネル３８は通知に含まれている情報により特定されるＬＵ２４について、ファイルシステムマウントを実施し（Ｓ１０６０）、マウントされたファイルシステム内に格納されているフラグファイルを削除する（Ｓ１０７０）。そしてファイル共有プログラム３５及びデータムーバ３７を起動することで、Ｓ１０６０でマウントされたファイルシステムを、クライアント４０からアクセス可能な状態にする（Ｓ１０８０）。Ｓ１０８０でデータムーバ３７が起動されることにより、図７の処理が開始される。なお、Ｓ１０８０の処理は、「ファイル共有サービスを開始する」処理ということもある。この後再びＳ１０４０から処理を繰り返す。

　全ＬＵ２４について更新リスト４０２の復旧が完了した旨の通知を受信した場合（Ｓ１０５０：Ｙ）、起動処理は終了する。

　一方Ｓ１０３０の判定が否定的であった場合、第１カーネル３８は、ファイルシステムマウント（Ｓ１０６０’）、ファイル共有サービスの開始（Ｓ１０８０’）を行い、起動処理は終了する。Ｓ１０６０’、Ｓ１０８０’の処理はそれぞれ、Ｓ１０６０，Ｓ１０８０と同じ処理である。ただし、ＬＵ２４が複数ある場合、Ｓ１０６０’では各ＬＵ２４についてファイルシステムマウントが行われる。またＳ１０８０’では、各ＬＵ２４についてファイル共有サービスの開始処理が行われる。

　以上が、本発明の一実施例に係る情報システムの説明である。本実施例に係る情報システムでは、ローカルファイルサーバのＯＳがダウンした場合でも、その時にメモリ上に格納された情報を、ＤＩＳＫ（ＨＤＤ）等の不揮発記憶媒体に適切に退避できる。本実施例に係る情報システムの場合、たとえばローカルファイルサーバで更新されたファイルの情報が、ローカルファイルサーバのメモリ上の更新リストに格納される。ローカルファイルサーバはこの更新リストに基づいて、ローカルファイルサーバで更新されたファイルの内容をセンターファイルサーバに反映している。

　ローカルファイルサーバのＯＳがダウンし、メモリ上の更新リストの内容にアクセスできなくなると、ローカルファイルサーバで更新されたファイルの内容をセンターファイルサーバに反映することができなくなる。本実施例に係るローカルファイルサーバは、プログラムの不具合やハードウェアの異常により、ＯＳが処理を継続できなくなった（異常終了した）場合、更新リストの復旧を行うためのプログラムである第２カーネルを起動させる。起動された第２カーネルは、メモリ内を検索することで、メモリ上に残されている更新リストを特定し、これをＤＩＳＫ等の不揮発記憶媒体に格納する。その後再起動されたＯＳ（及びデータムーバなどの、ファイルアクセス要求に係る処理を実行するプログラム群）は、ＤＩＳＫに格納された更新リストを読み出すことで、ローカルファイルサーバ内のファイルのうちセンターファイルサーバに反映すべきものを特定することができる。

　また、実施例に係るローカルファイルサーバは、ＯＳが通常備えるメモリダンプ機能によって、不揮発記憶媒体に格納されたメモリ内容（メモリダンプ）を読み出すことで更新リストを特定するのではなく、メモリ上を検索することで更新リストを特定し退避する。そのため、更新リストの特定及び退避を高速に行うことができる。また実施例に係るローカルファイルサーバは、仮想マシン上でＯＳを実行し、ＯＳダウン時には第２カーネルによる更新リストの特定及び退避処理と並行して、別の仮想マシン上でＯＳを再起動させる。これにより、ローカルファイルサーバをより迅速に、クライアントからのファイルアクセスサービスを受け付けられる状態に復旧させることが可能になる。

　さらに、障害の種類によっては、ＯＳが異常終了した時に、第２カーネルを起動させることができない場合もある。たとえば停電等の障害が発生した場合が例として挙げられる。本実施例に係るローカルファイルサーバは、このような場合に備え、各ファイルの管理情報（ｉｎｏｄｅ）に、センターファイルサーバに反映が必要であるか否かを特定できる情報（レプリケーション済みフラグ２２０ｇ）を付加している。停電等の障害が発生した場合には、本実施例に係るローカルファイルサーバは、ＯＳの再起動時に全ファイルのレプリケーション済みフラグ２２０ｇを確認し、センターファイルサーバに反映が必要なファイルを特定する。

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

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

Claims

　クライアントと、１以上のファイルを格納するセンターファイルサーバと、前記センターファイルサーバと前記クライアントに接続され、１以上の前記ファイルを格納するローカルファイルサーバを有する情報システムにおいて、
　前記ローカルファイルサーバは、メモリとプロセッサと記憶デバイスと第１のプログラム群と第２プログラムを有し、
　前記第１のプログラム群は前記プロセッサに、
　前記記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求を受け付け、
　前記記憶デバイスに格納されたファイルが更新された時、前記更新されたファイルについての情報を、前記ローカルファイルサーバのメモリ上に設けられた更新リストに記録し、
　前記更新リストに前記情報が記録されているファイルを、前記センターファイルサーバに反映し、
　前記センターファイルサーバに反映されたファイルについての情報を、前記更新リストから削除する、
処理を実行させるものであって、
　前記ローカルファイルサーバは、前記第１のプログラム群の実行を継続できなくなった時、前記プロセッサに前記第２プログラムの実行を開始させ、
　前記プロセッサは、前記第２プログラムが実行されることにより、
　ａ）　前記メモリから、前記更新リストの存在する領域を特定し、
　ｂ）　前記特定された領域から、前記更新されたファイルについての情報を読み出し、
　ｃ）　前記更新されたファイルについての情報を、前記記憶デバイスに格納する、
ことを特徴とする、情報システム。
　前記プロセッサは、前記第２プログラムが実行されることにより、
　前記ｃ）の後に、
　前記記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求の受け付けを開始する、
ことを特徴とする、請求項１に記載の情報システム。
　前記ローカルファイルサーバでは、第１の仮想計算機と第２の仮想計算機が稼働しており、
　前記第１の仮想計算機は、前記第１の仮想計算機で実行されている前記第１のプログラム群の実行を継続できなくなったことを契機に、前記第２プログラムの実行を開始し、
　前記第１の仮想計算機は、前記第２プログラムが実行されることにより、前記第２の仮想計算機で前記第１のプログラム群の実行を開始させ、
　前記第２の仮想計算機は、前記第１のプログラム群の実行の開始後、前記第１の仮想計算機から、前記更新されたファイルについての情報を前記記憶デバイスに格納した旨の通知を受信するまで、前記記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求の受け付けを待機する、
ことを特徴とする、請求項２に記載の情報システム。
　前記ローカルファイルサーバは、複数の記憶デバイスを有し、
　前記第１の仮想計算機は、前記複数の記憶デバイスのうちの第１記憶デバイス内の前記更新されたファイルについての情報を前記第１記憶デバイスに格納した後、前記第２の仮想計算機に、第１記憶デバイス内の前記更新されたファイルについての情報を前記第１記憶デバイスに格納した旨の第１通知を送信し、前記複数の記憶デバイスのうちの第２記憶デバイス内の前記更新されたファイルについての情報を前記第２記憶デバイスに格納した後、前記第２の仮想計算機に、第２記憶デバイス内の前記更新されたファイルについての情報を前記第２記憶デバイスに格納した旨の第２通知を送信し、
　前記第２の仮想計算機は、前記第１通知を受信すると、前記第１記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求の受け付けを開始し、
　前記第２の仮想計算機は、前記第２通知を受信するまでは、前記第２記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求の受け付けを待機する、
ことを特徴とする、請求項３に記載の情報システム。
　前記ローカルファイルサーバは、前記ファイルが更新されたとき、前記記憶デバイスに格納される前記ファイルの管理情報に、前記ファイルが更新された旨を表す情報を格納し、
　前記ローカルファイルサーバは、前記プロセッサに第２プログラムの実行を開始させることができなかった場合、
　前記記憶デバイスに格納される前記ファイルの管理情報を参照し、
　前記管理情報に前記ファイルが更新された旨を表す情報が格納されている場合、前記ファイルについての情報を、前記更新リストに記録する、
ことを特徴とする、請求項１に記載の情報システム。
　前記ローカルファイルサーバは、
　起動時に、前記記憶デバイスにフラグファイルを作成し、
　外部からの指示によりシャットダウンされる時に、前記記憶デバイスに格納されているフラグファイルを削除するよう構成されており、
　前記ローカルファイルサーバは再起動時に、前記記憶デバイスにフラグファイルが格納されている場合、
　前記再起動前に前記第１のプログラム群の実行を継続できなくなり、かつ前記プロセッサに第２プログラムの実行を開始させることができなかったと判断する、
ことを特徴とする、請求項５に記載の情報システム。
　クライアントとセンターファイルサーバに接続され、１以上のファイルを格納したローカルファイルサーバであって、
　前記ローカルファイルサーバは、メモリとプロセッサと記憶デバイスと第１のプログラム群と第２プログラムを有し、
　前記第１のプログラム群は前記プロセッサに、
　前記記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求を受け付け、
　前記ローカルファイルサーバに格納されたファイルが更新された時、前記更新されたファイルについての情報を、前記ローカルファイルサーバのメモリ上に設けられた更新リストに記録し、
　前記更新リストに前記情報が記録されているファイルを、前記ローカルファイルサーバに接続されたセンターファイルサーバに反映し、
　前記センターファイルサーバに反映されたファイルについての情報を、前記更新リストから削除する、
処理を実行させるものであって、
　前記ローカルファイルサーバは、前記第１のプログラム群の実行を継続できなくなった時、前記プロセッサに第２プログラムの実行を開始させ、
　前記プロセッサは、前記第２プログラムが実行されることにより、
　ａ）　前記メモリから、前記更新リストの存在する領域を特定し、
　ｂ）　前記特定された領域から、前記更新されたファイルについての情報を読み出し、
　ｃ）　前記更新されたファイルについての情報を、前記記憶デバイスに格納する、
ことを特徴とする、ローカルファイルサーバ。
　前記プロセッサは、前記第２プログラムが実行されることにより、
　前記ｃ）の後に、
　前記記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求の受け付けを開始する、
ことを特徴とする、請求項７に記載のローカルファイルサーバ。
　前記ローカルファイルサーバでは、第１の仮想計算機と第２の仮想計算機が稼働しており、
　前記第１の仮想計算機は、前記第１の仮想計算機で実行されている前記第１のプログラム群が異常終了したことを契機に、前記第２プログラムの実行を開始し、
　前記第１の仮想計算機は、前記第２プログラムが実行されることにより、前記第２の仮想計算機で前記第１のプログラム群の実行を開始させ、
　前記第２の仮想計算機は、前記第１のプログラム群の実行の開始後、前記第１の仮想計算機から、前記更新されたファイルについての情報を前記記憶デバイスに格納した旨の通知を受信するまで、前記記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求の受け付けを待機する、
ことを特徴とする、請求項８に記載のローカルファイルサーバ。
　前記ローカルファイルサーバは、前記ファイルが更新されたとき、前記記憶デバイスに格納される前記ファイルの管理情報に、前記ファイルが更新された旨を表す情報を格納し、
　前記ローカルファイルサーバは、前記プロセッサに第２プログラムの実行を開始させることができなかった場合、
　前記記憶デバイスに格納される前記ファイルの管理情報を参照し、
　前記管理情報に前記ファイルが更新された旨を表す情報が格納されている場合、前記ファイルについての情報を、前記更新リストに記録する、
ことを特徴とする、請求項７に記載のローカルファイルサーバ。
　前記ローカルファイルサーバは、
　起動時に、前記記憶デバイスにフラグファイルを作成し、
　外部からの指示によりシャットダウンされる時に、前記記憶デバイスに格納されているフラグファイルを削除するよう構成されており、
　前記ローカルファイルサーバは再起動時に、前記記憶デバイスにフラグファイルが格納されている場合、
　前記再起動前に前記第１のプログラム群の実行を継続できなくなり、かつ前記プロセッサに第２プログラムの実行を開始させることができなかったと判断する、
ことを特徴とする、請求項１０に記載のローカルファイルサーバ。
　第１のプログラム群と第２のプログラムが記録された記憶媒体であって、
　前記第１のプログラム群は、メモリとプロセッサと記憶デバイスを有するコンピュータの前記プロセッサに、
　前記コンピュータに接続されたクライアントからの、前記記憶デバイスに格納されたファイルに対するアクセス要求を受け付け、
　前記ファイルが更新された時、前記更新されたファイルについての情報を、前記メモリ上の更新リストに記録し、
　前記更新リストに前記情報が記録されているファイルを、前記コンピュータに接続されたセンターファイルサーバに反映し、
　前記センターファイルサーバに反映されたファイルについての情報を、前記更新リストから削除する、
処理を実行させるよう構成されており、
前記プロセッサにより前記第１のプログラム群の実行が継続できなくなった時、前記第１のプログラム群は前記プロセッサに前記第２プログラムの実行を開始させ、
　前記第２プログラムは前記プロセッサに、
　ａ）　前記メモリから、前記更新リストの存在する領域を特定し、
　ｂ）　前記特定された領域から、前記更新されたファイルについての情報を読み出し、
　ｃ）　前記更新されたファイルについての情報を、前記記憶デバイスに格納する、
処理を実行させることを特徴とする、記憶媒体。
　前記第２プログラムは前記プロセッサに、
　前記ｃ）の後に、
　前記記憶デバイスに格納されたファイルに対するクライアントからのアクセス要求の受け付けを開始させる、
ことを特徴とする、請求項１２に記載の記憶媒体。