JP5212921B2 - ファイルサーバシステム及びファイル管理方法 - Google Patents

Description

本発明は、ファイルサーバ（コンピュータ）によってファイルを共有するファイルサーバシステム及びファイル管理方法に関する。この出願は、２００７年３月１２日に出願された特許出願番号２００７−０６１９６２号の日本特許出願に基づいており、その出願による優先権の利益を主張し、その出願の開示は、引用することにより、そっくりそのままここに組み込まれている。

ファイルサーバは、簡単なファイル共有の方法として広く使われている。このファイルサーバは、部門内のファイルサーバ（部門ファイルサーバ）として、比較的少ないクライアント端末のユーザ（エンドユーザ）に対して使われていた。即ち、比較的少人数のエンドユーザで使われていた。近年では、ＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ；ファイルサーバ専用アプライアンス）やサーバの高性能化、更に情報統合の流れから、ファイルサーバが統合されるようになってきている。統合されたファイルサーバは、数テラバイトの容量をもち、例えば数千人規模で利用される。

このようなファイルサーバは、従来の部門ファイルサーバとは異なり、確実にバックアップをとり、ダウンすることなく、２４時間運用することが求められる。つまり、大規模化・インフラ化してきているといえる。

ファイルサーバの大規模化・インフラ化に伴い、管理コストが増大する。このため、ファイルサーバのユーザ（管理者）にとっては管理コストの削減が大きな課題となっている。

管理者にとっては、全てのファイルの中から、最重要なファイルのレベルに合わせて管理せざるをえない。ところが、ファイルサーバに保存されるファイルは全て重要であるとは限らない。

そのため、例えば業務には関係のないファイルに対しても、「定期的バックアップ」、「冗長化による保管」、「アクセスログの保管」、等、本来は必要ない管理コストが生じる。このような不要な管理コストが発生するのは、ファイルの属性に関係なく、全てのファイルを同一に管理していることが原因である。

かかる問題に対処すべく、ファイルの重要度などの属性に応じて管理方法を変えていく各種技術が開発・提案されている。例えば重要度の低いファイルは、低価格ストレージに移行させる階層ストレージ管理（Ｈｉｅｒａｒｃｈｉｃａｌ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ；ＨＳＭ）などである。

これらの手法を用いれば、増大する管理コストの削減ができるが、実は、ファイルをクラス分けすること自体が難しいという課題がある。

従来の部門ファイルサーバであれば、エンドユーザが少なかったため、管理者がファイルをクラス分けすることができた。しかし、ファイルサーバを大規模化・インフラ化した場合、管理者は、多ければ数千人のエンドユーザを相手にしており、個々のファイルの重要度などを把握できない。

例えば、階層ストレージ管理（ＨＳＭ）では、クラス分けのためにファイルの更新時刻やアクセス時刻、アクセス履歴のような属性をポリシーとして用いている。これは、「アクセスされるファイルは、重要度が高く、かつ、性能が求められる」、「アクセスされないファイルは、重要度が低く、性能も求められない」という考え方に基づいている。このポリシーは、トータル性能の点では合理的と言える。

しかしながら、実際には、このポリシーだけを用いて、ファイルサーバに保存されている全てのファイルを同一にクラス分けすることは難しい。実際のところ、全てのファイルのうちの、クライアント端末からファイルサーバに頻繁にアクセスされないファイルであっても、重要なファイルはいくらでもある。そして、このようなファイルを、ＨＳＭにより、低速なストレージに移してしまうと、該ファイルへのアクセスタイムが遅いと問題になることもあり得る。

少人数のエンドユーザがアクセスするような部門ファイルサーバであれば、どのようなファイルが重要かを管理者が把握することも可能ではあるが、数百人・数千人規模のエンドユーザがアクセスするようなファイルサーバでは、管理者は把握しようがないし、一概にはポリシーを決めることはできない。

また、一般的に、管理者は、ファイルサーバを大規模化・インフラ化したときに、インフラ管理者という意識が強くなりがちであり、ファイルの中身には関わらない傾向が強い。逆に、管理者が全てのファイルに対して重要であるか否かを表す重要度を設定するのではなく、ファイルを扱う側のエンドユーザに、管理ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）やコマンドを開放して、全てのファイルに対して重要度を設定してもらう手法も考えられる。しかし、この手法により、数千人規模のエンドユーザが、誰でも、ファイルの重要度を設定変更できてしまうことは、システムのセキュリティ上、問題がある。

なお、ファイルシステム拡張機能を、ディレクトリに置いたコマンドファイルで実現するという手法が、石井・薗田「ユーザによるファイルシステム拡張機能の管理操作を可能にするコマンドファイル方式の提案」、ＦＩＴ２００６（第５回情報科学技術フォーラム）に提案されている。この手法では、コマンドファイルは、クライアント端末内のクライアントプログラムが作成している。

管理コストを減らして効率的にファイルを管理するには、全てのファイルに対して重要度を設定して、最適な管理コストをかけることが必要である。しかしながら、管理者が全てのファイルに対して重要度を設定する場合、管理者が全てのファイルの中身を見て判断しなくてはならず、大規模・インフラ化したファイルサーバでは実質的に不可能である。

したがって、本発明の課題は、全てのファイルのうちの重要なファイルに関してはセキュリティを維持しながら管理することができ、管理者の負担が軽減することにより管理コストを削減できるファイルサーバシステム及びファイル管理方法を提供することにある。

本発明のファイルサーバシステムは、複数のクライアント端末と、複数のクライアント端末により共有されるファイルサーバと、を具備している。ファイルサーバは、複数の記憶領域のそれぞれに対応する複数のディレクトリを備えるファイルシステムと、管理手段と、を具備している。管理者、又は、複数のクライアント端末のユーザであるエンドユーザのうちの、予め決められたエンドユーザによって、複数の記憶領域のうちの所定の記憶領域に対して管理ポリシーが与えられる。このとき、管理手段は、管理ポリシーが設定された設定ファイルを生成し、複数のディレクトリのうちの、所定の記憶領域に対応するディレクトリ内に設定する。設定ファイルの内容の変更を表す変更情報を含む書込命令が管理者又は予め決められたエンドユーザによって与えられる。このとき、管理手段は、変更情報に基づいて管理ポリシーを変更する。

上記発明の目的、効果、特徴は、添付される図面と連携して実施の形態の記述から、より明らかになる。

図１は、本発明の第１実施形態によるファイルサーバシステムの構成を示している。 図２は、本発明の第１実施形態によるファイルサーバシステムにおけるファイルサーバ２のファイルシステム３の複数のディレクトリ６を表すディレクトリの一例を示している。 図３は、本発明の第１実施形態によるファイルサーバシステムにおけるファイルサーバ２の動作を説明するための図である。 図４は、本発明の第１実施形態によるファイルサーバシステムにおける設定ファイルオープン時の動作を示すフローチャートである。 図５は、本発明の第１実施形態によるファイルサーバシステムにおける設定ファイルクローズ時の動作を示すフローチャートである。 図６は、本発明の第１実施形態によるファイルサーバシステムにおけるファイルサーバ２のファイルシステム３のディレクトリ６の一例を示している。 図７は、本発明の第２実施形態によるファイルサーバシステムにおけるファイルサーバ２のファイルシステム３のディレクトリ６の一例を示している。 図８は、本発明の第１実施形態によるファイルサーバシステムにおける管理エンジン４の構成を示している。

以下に添付図面を参照して、本発明のファイルサーバシステムについて詳細に説明する。

（第１実施形態）
図１は、本発明の第１実施形態によるファイルサーバシステムの構成を示している。ファイルサーバシステムは、複数のクライアント端末１と、複数のクライアント端末１により共有されるファイルサーバ２と、を具備している。ファイルサーバ２は、コンピュータであり、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）である実行手段（実行部）３１と、記録媒体である記憶手段（記憶部）３２と、を具備している。記憶部３２には、ファイルサーバ２に実行させるためのコンピュータプログラムが記憶されている。実行部３１は、ファイルサーバ２の起動時などにコンピュータプログラムを記憶部３２から読み取って実行する。記憶部３２は、ファイルシステム３を備え、コンピュータプログラムは、管理手段（管理エンジン）４とファイルシステム拡張手段（ファイルシステム拡張エンジン）８とを含んでいる。

管理エンジン４は、図１に示す例では、ファイルサーバ２内に設けられているが、物理的に、ファイルサーバ２とは別のサーバに設ける構成としてもよい。また、管理エンジン４が、複数のファイルサーバ２の管理を行う形態としてもよい。

ファイルシステム拡張エンジン８は、ファイルシステム３に対して何らかの付加処理を実行する。付加処理としては、例えば、
・バックアップ・スナップショット・レプリケーションのようなファイル保護、
・ウイルススキャン・暗号化のようなセキュリティ、
・ＨＳＭ（Ｈｉｅｒａｒｃｈｉｃａｌ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ；階層ストレージ管理）やＩＬＭ（Ｉｎｆｏｒｍａｔｉｏｎ Ｌｉｆｅｓｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ；情報ライフサイクル管理）のようなライフサイクル管理、
の少なくとも１つの処理を含んでいる。ただし、これらの処理に限定するものではなく、ファイルサーバとそのファイルに対して何らかの操作を行うエンジンであれば何でもよい。なお、図１では、ファイルシステム拡張エンジン８としては１つだけ示されているが、複数備えられ、複数の付加処理に対応する構成としてもよい。

図２に示されるように、ファイルシステム３は、記憶部３２の複数の記憶領域のそれぞれに対応する複数のディレクトリ６を備えている。

ファイルサーバ２には、キーボード、ポインティングデバイス、表示装置、印刷装置を含む入出力装置３３が接続されている。入出力装置３３は、ファイルサーバ２を管理する管理者により使用される。管理者は、入出力装置３３とファイルサーバ２とを用いて、複数のクライアント端末１のユーザであるエンドユーザのうちの、管理者が許可したエンドユーザを予め決めておく。図３に示されるように、管理者又は上記の予め決められたエンドユーザは、複数の記憶領域のうちの所定の記憶領域に対して管理ポリシーをファイルサーバ２に与える。例えば、管理者は、所定の記憶領域に対して管理ポリシーをファイルサーバ２に与える（図３の（１）ポリシー設定）。なお、管理者は入出力装置３３をネットワーク経由で操作することもできるし、リモートログインのように仮想的な入出力装置３３を経由して操作することも可能である。

このとき、ファイルサーバ２の管理エンジン４は、管理ポリシーが設定された設定ファイル５を生成し、複数のディレクトリ６のうちの、所定の記憶領域に対応するディレクトリ６内に設定する（図３の（２）作成）。

設定ファイル５は、管理エンジン４によって上記のディレクトリ６（１番目のディレクトリ）に作成される。１番目のディレクトリに対してディレクトリ６（２、３、…番目のディレクトリ）が追加されるごとに、管理エンジン４によって、上位ディレクトリ（１、２、３、…番目のディレクトリ）から継承されて作成される。

設定ファイル５には、予め決められたエンドユーザを表すアクセスコントロールリスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔｓ；ＡＣＬ）７が適用される。このＡＣＬ７は、管理者が個別に設定ファイル５に設定するようにしてもよいが、ポリシーとしてファイルサーバ２に与えることで、管理エンジン４がポリシーに応じて適切に設定ファイル５を設定することができる。これにより、設定ファイル５は、誰でも更新（編集・変更）できるわけではなく、管理者が許可したエンドユーザにのみ、更新が可能とされる。このように、設定ファイル５は、全てのファイルの中で、重要なファイルとして扱われる。

その後、管理エンジン４は、設定ファイル５に対するアクセスを監視する（図３の（２）監視）。

また、管理エンジン４は、設定ファイル５を生成したとき、設定通知をファイルシステム拡張エンジン８に出力する。ファイルシステム拡張エンジン８は、設定通知に応じて、ファイルシステム３に対して付加処理を実行する（図３の（２）設定通知）。

管理者又は予め決められたエンドユーザは、設定ファイル５を書き込む（更新する）ための書込命令をファイルサーバ２に与える。例えば、予め決められたエンドユーザは、書込命令をファイルサーバ２に与える。書込命令は、設定ファイル５の内容の変更を表す変更情報を含んでいる。管理者又は予め決められたエンドユーザは、変更情報に基づいて管理ポリシーを変更する（図３の（３）更新）。

管理エンジン４は、設定ファイル５に対するアクセスを監視した結果、設定ファイル５が更新された場合、変更情報をファイルシステム拡張エンジン８に応じた管理ポリシーを設定ファイル５に設定する（図３の（４）監視結果）。このとき、管理エンジン４は、変更通知をファイルシステム拡張エンジン８に出力する。ファイルシステム拡張エンジン８は、変更通知に応じて、ファイルシステム３に対して付加処理を実行する（図３の（５）変更通知）。また、管理エンジン４は、設定ファイル５が更新された旨を管理者（入出力装置３３）に通知する（図３の（５）通知）。これにより、管理者は、管理者以外のユーザ（予め決められたエンドユーザ）により設定ファイル５が更新されたことを把握することができる。

ファイルシステム拡張エンジン８が実行する付加処理が、階層ストレージ管理（ＨＳＭ）とファイル拡張子制限である場合を例にして説明する。

階層ストレージ管理（ＨＳＭ）では、アクセスされず重要度の低いファイルを、プライマリストレージから、大容量・低コストのセカンダリストレージに移動する。どのファイルを移動させるかは、ポリシーとして設定するが、ファイルシステム３全体を同じポリシーで管理するのは難しい。このため、本発明によれば、管理者が許可したエンドユーザのみに、ポリシー設定を委譲することが有効である。管理エンジン４は、設定ファイル５からポリシーを読み込んで、ＨＳＭを実行するようにファイルシステム拡張エンジン８を制御する。

ファイル拡張子（例えばファイル名の最後部に位置しファイル名本体とピリオドで区別される）の制限においては、セキュリティ問題や会社のファイルサーバに個人のファイルを置かせたくないというようなニーズがある。しかし、全社的に、ファイル拡張子の制限をかけてしまうと、どこかの部署では、例外的に必要になる事態も想定されることから、なかなか設定しきれない。そこで、本発明によれば、ファイル拡張子の制限を部門レベルで設定ができ、かつ、その変更も、予め決められたエンドユーザのみができるというメリットがある。例えば、特定部門で使うＣＡＤソフトが制限されている拡張子のファイルを自動で作成してしまう場合では、全社的に制限を解除しなければならなかったが、本発明によれば、部門レベルで、ファイル拡張子の制限の解除を容易に行うことができる。

図８は、管理エンジン４の構成を示す図である。管理エンジン４は、管理者Ｉ／Ｆ（インタフェース）処理部２０と、ポリシー制御部２１と、設定制御部２２と、設定ファイル処理部２３と、ファイルシステム拡張エンジンＩ／Ｆ処理部２４と、を備えている。

まず、管理者は、管理者Ｉ／Ｆ処理部２０を介して、ファイルシステム３の所定の記憶領域に対して管理ポリシーをポリシー制御部２１に与える。このとき、ポリシー制御部２１は、管理ポリシーが設定された設定ファイル５を生成し、ファイルサーバ２の負荷や記憶容量に問題があるか否かをチェックする。ここで、ファイルサーバ２の負荷や記憶容量に問題がない場合、設定制御部２２は、所定の記憶領域に対応するディレクトリ６内に設定ファイル５を書き込むためのライト（Ｗ）コマンドの発行を依頼する。このとき、設定ファイル処理部２３は、ライトコマンドを発行し、ファイルシステム３の所定の記憶領域に対応するディレクトリ６内に設定ファイル５を書き込む（設定する）。また、設定制御部２２は、設定通知を表すコマンドの発行を依頼する。ファイルシステム拡張エンジンＩ／Ｆ処理部２４は、設定通知を表すコマンドを発行し、ファイルシステム拡張エンジン８は、設定通知に応じて、ファイルシステム３に対して付加処理を実行する。このとき、設定制御部２２は、設定ファイル５に対するアクセスを監視するための監視コマンドの発行を依頼する。このとき、設定ファイル処理部２３は、監視コマンドを発行し、設定ファイル５に対するアクセスを監視する。

設定ファイル処理部２３とファイルシステム拡張エンジンＩ／Ｆ処理部２４のいずれかでエラーが発生した場合、リトライやリカバリー処理の制御は、設定制御部２２で行う。設定制御部２２は、最終的に、所望の動作を実行できなかった場合、ポリシー制御部２１に対してエラーを伝える。ポリシー制御部２１は、管理者Ｉ／Ｆ処理部２０を介して、そのエラーを表す情報を管理者（入出力装置３３）に通知する。

このように、本発明の第１実施形態によるファイルサーバシステムによれば、全てのファイルのうちの重要なファイルに関してはセキュリティを維持しながら管理することができ、管理者の負担が軽減することにより管理コストを削減できる。

前述したように、既存技術（石井・薗田「ユーザによるファイルシステム拡張機能の管理操作を可能にするコマンドファイル方式の提案」、ＦＩＴ２００６（第５回情報科学技術フォーラム））では、コマンドファイルは、クライアント端末内のクライアントプログラムが作成することになっている。一方、本発明の第１実施形態によるファイルサーバシステムによれば、ファイルサーバ２は、管理ポリシー（ＡＣＬ７）が設定された設定ファイル５をファイルシステム３のディレクトリ６（所定の記憶領域）に予め作成しておく。これにより、ファイルサーバ２は、ＡＣＬ７を利用して、設定ファイル５を更新できるエンドユーザを制限することができる。

また、既存技術（クライアント端末側がコマンドファイルを作成）では、ディレクトリへの書き込み権限があれば、誰でも作成することができてしまう。これに対して、本発明の第１実施形態によるファイルサーバシステムによれば、ファイルサーバ２は、ＡＣＬ７を利用して、ディレクトリ６を所有するエンドユーザ（ディレクトリ６が割り当てられたエンドユーザ）に対して、設定ファイル５を更新できないようにすることもできる。

また、既存技術では、ファイルの更新を監視する際、ディレクトリに対する新規作成やＲＥＮＡＭＥを全て監視しなければならない。一方、本発明の第１実施形態によるファイルサーバシステムによれば、ファイルサーバ２は、作成した設定ファイル５のみを監視していればよく、監視の負荷を低減することができるという利点もある。

以下では、設定ファイル５の更新として、予め決められたエンドユーザ（クライアント端末１）が設定ファイル５を編集するためにオープンし、設定ファイル５を編集後に保存・クローズする際の手順を図４及び図５を用いて説明する。

図４は、本発明の第１実施形態によるファイルサーバシステムにおける設定ファイルオープン時の動作を示すフローチャートである。即ち、クライアント端末１が設定ファイル５をオープンするときの手順を示している。

クライアント端末１がオープンシステムコールを発行する（ステップＳ１０１）。

オープンシステムコールがファイルサーバ２のファイルシステム３に伝わると、まずはＡＣＬ機能によりエンドユーザがチェックされる（ステップＳ１０２）。

設定ファイル５に対してアクセス許可があるエンドユーザのみがオープンできる。オープン時に、ファイルシステム３のレイヤでシステムコールがフックされ、管理エンジン４に通知される（ステップＳ１０３）。フックは同期的に行われ、管理エンジン４がオープン許可を返すまで、クライアント端末１には応答が返らない。

オープンシステムコールのフックを受けた管理エンジン４は、現在の設定ファイル５を読み込んで格納しておく（ステップＳ１０４）。これは、「クライアント端末１が設定ファイル５を書き換えたときに、以前とどこを変更したかをチェックするため」、及び、「もし変更した設定ファイル５になんらかの誤りがあったりした場合に元に戻すため」、である。

ここで、管理エンジン４が設定ファイル５を読み込むときにもフックが働いてしまっては、無限ループしてしまう。このため、ファイルシステム３に対しては、フックをしない特権ユーザの設定を可能としておき、管理エンジン４を特権ユーザとしておく。

管理エンジン４が設定ファイル５を読み込み、ファイルシステム３に処理を返すと、クライアント端末１にオープンシステムコールの応答が返る（ステップＳ１０５）。

オープンできたクライアント端末１は、設定ファイル５を編集する。

図５は、本発明の第１実施形態によるファイルサーバシステムにおける設定ファイルクローズ時の動作を示すフローチャートである。即ち、クライアント端末１が設定ファイル５を編集後に保存・クローズするときの手順を示している。

クライアント端末１が設定ファイル５を保存・クローズするためにクローズシステムコールを発行する（ステップＳ１１０）。

クローズシステムコールは、オープンと同様に、ファイルシステム３の入り口でフックされて管理エンジン４に通知される（ステップＳ１１１）。ただし、この通知は、非同期的に行う。つまり、管理エンジン４が応答を返すのを待たずに、クライアント端末１に対してクローズシステムコールの応答を返す（ステップＳ１１２）。変更の反映には、時間がかかる可能性があり、それまでファイルのクローズ応答が返らないと、クライアント端末１のオペレーティングシステム（ＯＳ）によっては、ファイルサーバ２がストールしたと判断して接続を切ってしまうからである。

クローズシステムコールのフックを受けた管理エンジン４は、まず設定ファイル５を読み込む（ステップＳ１１３）。

管理エンジン４は、読み込んだ設定ファイル５に文法的にエラーがないかのチェックを行う（ステップＳ１１４）。

次に、管理エンジン４は、読み込んだ設定ファイル５とオープン時の設定ファイル５との差分をチェックする（ステップＳ１１５）。

そのあと、管理エンジン４は、差分（変更分）を反映させる制御を行う（ステップＳ１１６）。すなわち、管理エンジン４は、ファイルシステム拡張エンジン８に対して差分を反映させる。

管理エンジン４は、設定ファイル５を生成するときに、管理者と予め決められたエンドユーザとが閲覧可能な設定変更応答ファイル９を生成し、ディレクトリ６内に設定する。設定変更応答ファイル９は、設定ファイル５が正常に更新されたか否かを表している。例えば、管理エンジン４は、設定ファイル５が変更される際にシステム上の不正がある場合にはエラーを発生する。この場合、設定変更応答ファイル９は、設定ファイル５が正常に更新されないので、上記のエラーを表す情報を含んでいる（ステップＳ１１７）。これにより、クライアント端末１は、設定変更応答ファイル９を読み出して、設定ファイル５が正常に更新されたか否かを確認できる。

また、設定変更応答ファイル９が生成されるまでは、設定ファイル５の更新中であることがわかる。このことを明示的に行うために、管理エンジン４は、書込命令（変更情報）を受け付けた時点で、前回の設定変更応答ファイル９をディレクトリ６から削除してもよい。

図６は、ファイルサーバ２のファイルシステム３のディレクトリ６の一例を示している。図６に示す例では、通常ファイル１０に加え、設定ファイル５と設定変更応答ファイル９が、ディレクトリ６の下に配置され、設定ファイル５と設定変更応答ファイル９は管理エンジン４が作成する。

設定ファイル５は、ＡＣＬ７により限定されたエンドユーザのみ更新できるようになっている。

設定変更応答ファイル９に対して、ＡＣＬ１１が設定される。ＡＣＬ１１は、限定されたエンドユーザのみが読み込みでき、設定変更応答ファイル９の更新は管理エンジン４しかできないことを表している。

設定ファイル５のＡＣＬ７を管理エンジン４が設定するため、ディレクトリ６が割り当てられたエンドユーザからもアクセスできないように設定することができる。その場合、ディレクトリ６が割り当てられたエンドユーザからも設定ファイル５の更新は許さないことになる。

設定ファイル５にアクセスできないと、ディレクトリ６の削除もできないと思われるかもしれないが、ディレクトリ６からのファイル削除は、ディレクトリ６自体に書き込みのアクセス権があれば可能である。

もし、予め決められたエンドユーザ（クライアント端末１）がディレクトリ削除の目的以外で、設定ファイル５を削除した場合、設定ファイル５がない状態になる。この場合、上位ディレクトリの設定ファイルを継承する。クライアント端末１がディレクトリ６内にファイル作成などの操作をした際に、設定ファイル５がないことを、管理エンジン４が検出し、上位ディレクトリの設定ファイル５と同じ設定で動作を行う。また、上位ディレクトリに対する下位ディレクトリであるサブディレクトリに対しても同じ設定を継承する。サブディレクトリが多数存在すると、時間を要することがあり得るが、終了するまで、設定変更応答ファイル９ができないので、クライアント端末１は処理中であることがわかる。

また、設定ファイル５に対して、特定拡張子のファイル作成を禁止するというような設定が行われている場合、設定ファイル５である既存のファイルが禁止ファイルとなる可能性がある。この場合、管理エンジン４が既存のファイルを勝手に削除することもできるが、それは、非常に危険である。例えば、設定ミスによって重要なファイルを削除してしまう可能性もある。そこで、このような危険を避けるため、禁止ファイルになっていても、管理エンジン４では自動削除は行わず、設定変更応答ファイル９にリストアップする。ただし、リストアップしたファイルを一括で削除できるように、テンポラリのゴミ箱に移動したり、一括削除の設定を別途設けたりすることにより、一括削除を簡単に可能とする。

また、設定ファイル５の内部に、ディレクトリ６のフルパス名が含まれている場合がある。この場合、上位ディレクトリで名前の変更（ＲＥＮＡＭＥ）があったときに、下位ディレクトリの設定ファイル５を全て変更して回らなければならない。これは大きな負荷となってしまい、問題である。この対処のため、設定ファイル５には、パス名が含まれないようにする。その代わりに、ディレクトリ６のｉｎｏｄｅ番号を入れておく。これにより、名前変更やＭＯＶＥがなされても設定ファイル５を変更しないで済み、負荷の軽減になる。

また、設定されるべきディレクトリ６に設定ファイル５が設定されない場合、設定ファイル５、ディレクトリ６に対してｉｎｏｄｅ番号の比較を用いることが好ましい。この場合、ディレクトリ６、設定ファイル５のｉｎｏｄｅ番号を比較すれば確認ができる。もし、設定されるべきディレクトリ６に設定ファイル５が設定されない場合には、上位ディレクトリの設定ファイル５を継承して新しい設定ファイル５を作ることが好ましい。

（第２実施形態）
第２実施形態では、第１実施形態と重複する説明を省略する。

図７は、本発明の第２実施形態によるファイルサーバシステムにおけるファイルサーバ２のファイルシステム３のディレクトリ６の一例を示している。第２実施形態では、ファイルサーバ２の管理エンジン４は、設定ファイル５が生成されたときに、設定変更リクエストファイル１２を生成し、ディレクトリ６内に設定する。管理者、予め決められたエンドユーザが、それぞれ入出力装置３３、クライアント端末１を用いて、書込命令（変更情報）を与える。このとき、管理エンジン４は、管理者又は予め決められたエンドユーザのみが変更できるアクセス権を設定変更リクエストファイル１２に設定する。管理者又は予め決められたエンドユーザが変更情報を設定変更リクエストファイル１２に更新したときに、ファイルサーバ２の負荷や記憶容量に問題があるか否かをチェックする。ここで、ファイルサーバ２の負荷や記憶容量に問題がない場合、管理エンジン４は、設定変更リクエストファイル１２から変更情報を読み出し、変更情報に基づいて管理ポリシーを変更する。

本実施形態では、管理者（入出力装置３３）、又は、クライアント端末１（特定エンドユーザ；予め決められたエンドユーザ）は、設定変更リクエストファイル１２に変更情報を記述する。この場合、変更前の設定ファイル５が残っているため、管理エンジン４は、オープン時に読み込む必要がなくなる。

図７に示したディレクトリ構成において、第１実施形態とは異なり、設定ファイル５のＡＣＬ７は、クライアント端末１（全てのエンドユーザ）が更新することはできないように設定される。

クライアント端末１（特定エンドユーザ）は、設定変更リクエストファイル１２を更新して設定ファイル５の更新を指示する。ファイルシステム３において、設定変更リクエストファイル１２に対するアクセスの監視が行われ、設定変更リクエストファイル１２の書き込み（更新）が行われると、管理エンジン４に通知される。管理エンジン４は設定変更リクエストファイル１２を読み込んで、設定変更を、ファイルシステム拡張エンジン８に反映させる制御を行う。すなわち、設定変更リクエストファイル１２が、特定エンドユーザによって更新されると、第１実施形態と同様、ファイルシステムから、図８の設定ファイル処理部２３を通じて、ポリシー制御部２１へ通知される。ポリシー制御部２１は、設定変更リクエストファイル１２による設定ファイル５の更新が、ポリシーに照合して許可されるか否かを確認するために、ファイルサーバ２の負荷や記憶容量などの各種情報と照合し、問題がないかをチェックする。ポリシー制御部２１は、設定ファイル５の更新を許可する場合には、設定制御部２２に対して、設定ファイル５の更新を行うように指示する。

管理エンジン４は、設定変更リクエストファイル１２の内容に従って設定を反映した後、設定変更リクエストファイル１２に記述された変更情報を、ファイルシステム３内の設定ファイル５（図７参照）に反映させる。つづいて、管理エンジン４は、設定変更リクエストファイル１２の内容をリセット（クリア）する（例えばバイト長０のファイルとする）。管理エンジン４において、ファイルシステム３内の設定ファイル５の内容の更新、設定変更リクエストファイル１２のリセットは、ポリシー制御部２１の指示により、設定制御部２２、設定ファイル処理部２３を介して行われる。

本実施形態において、設定変更リクエストファイル１２には、限定された特定のエンドユーザしかアクセス・更新できないようなＡＣＬ１３が与えられる。また設定ファイル５は、管理者側（管理エンジン）からのみアクセス可能であり、エンドユーザには、更新、削除等のアクセスができないＡＣＬ７が与えられる。

本発明の第２実施形態によるファイルサーバシステムによれば、第１実施形態に対して、オープン時に設定ファイル５を読み込んで保存するステップ（図４のＳ１０４）が不要になる。このため、オープン時の動作が簡単になり、管理エンジン４も変更前の設定ファイル５を保持していておく必要がないというメリットがある。これにより、第１実施形態の効果に加えて、第１実施形態に対して管理コストを削減できる。

以上、本発明を上記実施形態に即して説明したが、本発明は上記実施形態の構成にのみ制限されるものでなく、本発明の範囲内で当業者であればなし得るであろう各種変形を含むことは勿論である。

以上の説明により、本発明のファイルサーバシステムによれば、全てのファイルのうちの重要なファイルに関してはセキュリティを維持しながら管理することができ、管理者の負担が軽減することにより管理コストを削減できる。

Claims (20)

1. 複数のクライアント端末と、
   前記複数のクライアント端末により共有されるファイルサーバと、
   を具備し、
   前記ファイルサーバは、
   複数の記憶領域のそれぞれに対応する複数のディレクトリを備えるファイルシステムと、
   前記複数の記憶領域のうちの所定の記憶領域に対して、管理者、又は、前記複数のクライアント端末のユーザであるエンドユーザのうちの、予め決められたエンドユーザが管理権限を持つという管理ポリシーが与えられたとき、前記管理ポリシーを前記ファイルシステムのアクセス権として設定することにより、前記管理者又は前記予め決められたエンドユーザのみがアクセス可能な設定ファイルを、前記複数のディレクトリのうちの、前記所定の記憶領域に対応するディレクトリ内に生成する管理手段と、
   を具備するファイルサーバシステム。
2. 前記ファイルサーバは、
   前記ファイルシステムに対して付加処理を実行するファイルシステム拡張手段、
   を更に具備し、
   前記管理手段は、
   前記設定ファイルに対するアクセスを監視し、前記設定ファイルの内容が変更された場合、その内容の変更を表す変更情報を前記ファイルシステム拡張手段に通知し、
   前記ファイルシステム拡張手段は、
   前記変更情報に応じて、前記ファイルシステムに対して前記付加処理を実行する請求の範囲１に記載のファイルサーバシステム。
3. 前記管理手段は、
   前記設定ファイルを生成するときに、前記管理者と前記予め決められたエンドユーザとが閲覧可能なアクセス権を前記ファイルシステムのアクセス権として設定した設定変更応答ファイルを前記ディレクトリ内に生成し、
   前記設定変更応答ファイルは、前記付加処理が正常に実行され、前記設定ファイルが正常に更新されたか否かを表す、
   請求の範囲２に記載のファイルサーバシステム。
4. 前記管理手段は、
   前記設定ファイルが生成されたときに、前記管理者又は前記予め決められたエンドユーザのみが変更可能なアクセス権を前記ファイルシステムのアクセス権として設定した設定変更リクエストファイルを前記ディレクトリ内に生成し、
   前記管理者又は前記予め決められたエンドユーザにより前記設定変更リクエストファイルの内容が変更された場合、その内容の変更を表す前記変更情報を前記ファイルシステム拡張手段に通知し、
   前記ファイルシステム拡張手段は、
   前記変更情報に応じて、前記ファイルシステムに対して前記付加処理を実行し、
   前記管理手段は、前記ファイルサーバの負荷や記憶容量に問題がない場合、前記設定変更リクエストファイルの内容を前記設定ファイルに反映させる、
   請求の範囲２に記載のファイルサーバシステム。
5. 前記付加処理は、ファイル保護、セキュリティ、ライフサイクル管理の少なくとも１つの処理を含む、
   請求の範囲２〜４のいずれかに記載のファイルサーバシステム。
6. 複数のクライアント端末により共有されるファイルサーバであって、
   前記ファイルサーバは、
   複数の記憶領域のそれぞれに対応する複数のディレクトリを備えるファイルシステムと、
   前記複数の記憶領域のうちの所定の記憶領域に対して、管理者、又は、前記複数のクライアント端末のユーザであるエンドユーザのうちの、予め決められたエンドユーザが管理権限を持つという管理ポリシーが与えられたとき、前記管理ポリシーを前記ファイルシステムのアクセス権として設定することにより、前記管理者又は前記予め決められたエンドユーザのみがアクセス可能な設定ファイルを、前記複数のディレクトリのうちの、前記所定の記憶領域に対応するディレクトリ内に生成する管理手段と、
   を具備するファイルサーバ。
7. 前記ファイルサーバは、
   前記ファイルシステムに対して付加処理を実行するファイルシステム拡張手段、
   を更に具備し、
   前記管理手段は、
   前記設定ファイルに対するアクセスを監視し、前記設定ファイルの内容が変更された場合、その内容の変更を表す変更情報を前記ファイルシステム拡張手段に通知し、
   前記ファイルシステム拡張手段は、
   前記変更情報に応じて、前記ファイルシステムに対して前記付加処理を実行する、
   請求の範囲６に記載のファイルサーバ。
8. 前記管理手段は、
   前記設定ファイルを生成するときに、前記管理者と前記予め決められたエンドユーザとが閲覧可能なアクセス権を前記ファイルシステムのアクセス権として設定した設定変更応答ファイルを前記ディレクトリ内に生成し、
   前記設定変更応答ファイルは、前記付加処理が正常に実行され、前記設定ファイルが正常に更新されたか否かを表す、
   請求の範囲７に記載のファイルサーバ。
9. 前記管理手段は、
   前記設定ファイルが生成されたときに、前記管理者又は前記予め決められたエンドユーザのみが変更可能なアクセス権を前記ファイルシステムのアクセス権として設定した設定変更リクエストファイルを前記ディレクトリ内に生成し、
   前記管理者又は前記予め決められたエンドユーザにより前記設定変更リクエストファイルの内容が変更された場合、その内容の変更を表す前記変更情報を前記ファイルシステム拡張手段に通知し、
   前記ファイルシステム拡張手段は、
   前記変更情報に応じて、前記ファイルシステムに対して前記付加処理を実行し、
   前記管理手段は、前記ファイルサーバの負荷や記憶容量に問題がない場合、前記設定変更リクエストファイルの内容を前記設定ファイルに反映させる、
   請求の範囲７に記載のファイルサーバ。
10. 前記付加処理は、ファイル保護、セキュリティ、ライフサイクル管理の少なくとも１つの処理を含む、
    請求の範囲７〜９のいずれかに記載のファイルサーバ。
11. 複数のクライアント端末により共有され、複数の記憶領域のそれぞれに対応する複数のディレクトリを備えるファイルシステムを用いるファイル管理方法であって、
    前記複数の記憶領域のうちの所定の記憶領域に対して、管理者、又は、前記複数のクライアント端末のユーザであるエンドユーザのうちの、予め決められたエンドユーザが管理権限を持つという管理ポリシーが与えられたとき、
    前記管理ポリシーを前記ファイルシステムのアクセス権として設定するステップと、
    前記管理者又は前記予め決められたエンドユーザのみがアクセス可能な設定ファイルを、前記複数のディレクトリのうちの、前記所定の記憶領域に対応するディレクトリ内に生成するステップと、
    を具備するファイル管理方法。
12. 前記ファイルシステムに対して付加処理を実行するステップと、
    前記設定ファイルに対するアクセスを監視し、前記設定ファイルの内容が変更された場合、その内容の変更を表す変更情報に応じて、前記ファイルシステムに対して前記付加処理を実行するステップと、
    を更に具備する請求の範囲１１に記載のファイル管理方法。
13. 前記設定ファイルを生成するときに、前記管理者と前記予め決められたエンドユーザとが閲覧可能なアクセス権を前記ファイルシステムのアクセス権として設定した設定変更応答ファイルを前記ディレクトリ内に生成するステップ、
    を更に具備し、
    前記設定変更応答ファイルは、前記付加処理が正常に実行され、前記設定ファイルが正常に更新されたか否かを表す、
    請求の範囲１２に記載のファイル管理方法。
14. 前記設定ファイルが生成されたときに、前記管理者又は前記予め決められたエンドユーザのみが変更可能なアクセス権を前記ファイルシステムのアクセス権として設定した設定変更リクエストファイルを前記ディレクトリ内に生成するステップと、
    前記管理者又は前記予め決められたエンドユーザにより前記設定変更リクエストファイルの内容が変更された場合、その内容の変更を表す前記変更情報に応じて、前記ファイルシステムに対して前記付加処理を実行するステップと、
    前記ファイルサーバの負荷や記憶容量に問題がない場合、前記設定変更リクエストファイルの内容を前記設定ファイルに反映させるステップと、
    を更に具備する請求の範囲１２に記載のファイル管理方法。
15. 前記付加処理は、ファイル保護、セキュリティ、ライフサイクル管理の少なくとも１つの処理を含む、
    請求の範囲１２〜１４のいずれかに記載のファイル管理方法。
16. 複数のクライアント端末により共有され、複数の記憶領域のそれぞれに対応する複数のディレクトリを備えるファイルシステムを用いるコンピュータに適用され、
    前記複数の記憶領域のうちの所定の記憶領域に対して、管理者、又は、前記複数のクライアント端末のユーザであるエンドユーザのうちの、予め決められたエンドユーザが管理権限を持つという管理ポリシーが与えられたとき、
    前記管理ポリシーを前記ファイルシステムのアクセス権として設定するステップと、
    前記管理者又は前記予め決められたエンドユーザのみがアクセス可能な設定ファイルを、前記複数のディレクトリのうちの、前記所定の記憶領域に対応するディレクトリ内に生成するステップと、
    の各ステップを前記コンピュータに実行させるためのコンピュータプログラムが記憶され、前記コンピュータプログラムを前記コンピュータが読み取り可能な記録媒体。
17. 前記ファイルシステムに対して付加処理を実行するステップと、
    前記設定ファイルに対するアクセスを監視し、前記設定ファイルの内容が変更された場合、その内容の変更を表す変更情報に応じて、前記ファイルシステムに対して前記付加処理を実行するステップと、
    の各ステップを更に前記コンピュータに実行させるための前記コンピュータプログラム
    が記憶された請求の範囲１６に記載の記録媒体。
18. 前記設定ファイルを生成するときに、前記管理者と前記予め決められたエンドユーザとが閲覧可能なアクセス権を前記ファイルシステムのアクセス権として設定した設定変更応答ファイルを前記ディレクトリ内に生成するステップ、
    を更に前記コンピュータに実行させるための前記コンピュータプログラムが記憶され、
    前記設定変更応答ファイルは、前記付加処理が正常に実行され、前記設定ファイルが正常に更新されたか否かを表す、
    請求の範囲１７に記載の記録媒体。
19. 前記設定ファイルが生成されたときに、前記管理者又は前記予め決められたエンドユーザのみが変更可能なアクセス権を前記ファイルシステムのアクセス権として設定した設定変更リクエストファイルを前記ディレクトリ内に生成するステップと、
    前記管理者又は前記予め決められたエンドユーザにより前記設定変更リクエストファイルの内容が変更された場合、その内容の変更を表す前記変更情報に応じて、前記ファイルシステムに対して前記付加処理を実行するステップと、
    前記ファイルサーバの負荷や記憶容量に問題がない場合、前記設定変更リクエストファイルの内容を前記設定ファイルに反映させるステップと、
    の各ステップを更に前記コンピュータに実行させるための前記コンピュータプログラムが記憶された請求の範囲１７に記載の記録媒体。
20. 前記付加処理は、ファイル保護、セキュリティ、ライフサイクル管理の少なくとも１つの処理を含む、
    請求の範囲１７〜１９のいずれかに記載の記録媒体。

Images