JP2004295464A - 計算機システム - Google Patents

Abstract

【課題】従来のファイルシステムでは、ひとつのファイルに対する多数ユーザのアクセス権限情報設定や、ファイル毎に異なるファイル属性情報の設定は、管理領域を浪費する問題があった。また、複数のストレージを用いてファイルを格納する場合に、ストレージ毎の課金情報管理ができなかった。
【解決手段】システムは、ファイル属性を管理するデータベースのファイル属性ＤＢと、課金情報を管理するデータベースの課金情報ＤＢとファイルデータを格納するローカルファイルシステムを持つ。課金情報ＤＢはユーザあるいはグループとサーバの組み合わせ毎にレコードを持ち、新しいユーザやサーバが追加される毎にレコードを追加する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介して接続された複数の計算機を用いて実現されるシステムに関する。
【０００２】
【従来の技術】
近年のインターネット等のネットワークの普及に伴い、ネットワークにおいてサービスを提供する計算機が提供するデータ量及びこれら計算機をネットワークを介して使用する使用者（以下「ユーザ」）の数が増大してきている。
【０００３】
しかし、一つの計算機がユーザが要求するデータ全てを管理する従来の集中型の計算機システムでは、計算機の処理性能に限界があり、その限界性能を超えてすべてのユーザが要求するデータを供給できない。また、計算機に接続された記憶装置の記憶容量にも限界がある。さらに、その計算機に障害が発生した場合には、データへのアクセスが不可能になる。
【０００４】
このような問題を解決する技術として、分散型の計算機システムが提案されている。
【０００５】
例えば非特許文献１に開示されている技術では、地理的に分散した複数の場所（以下「サイト」）に設置された計算機あるいは記憶装置の各々にデータを複製して配置する。このため、複数の計算機間でデータ処理に対する負荷やデータを分散することができる。さらに、ある計算機に障害が発生した場合でも、他の計算機にあるデータの複製を用いてデータを再構成することを可能としている。
【０００６】
以下、ユーザや計算機が使用するプログラム等の一かたまりのデータを「ファイル」と称する。
【０００７】
【非特許文献１】
“ＯｃｅａｎＳｔｏｒｅ： Ａｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｇｌｏｂａｌ−Ｓｃａｌｅ Ｐｅｒｓｉｓｔｅｎｔ Ｓｔｏｒａｇｅ”，Ｊｏｈｎ Ｋｕｂｉａｔｏｗｉｃｚ ｅｔ ａｌ．， Ａｐｐｅａｒｓ ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｎｉｎｔｈ ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｓｕｐｐｏｒｔ ｆｏｒ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅｓ ａｎｄ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ （ＡＳＰＬＯＳ ２０００）， Ｎｏｖｅｍｂｅｒ ２０００．の２章。
【０００８】
【発明が解決しようとする課題】
従来の集中管理型の計算機システムや非特許文献１に開示された計算機が世界規模に分散した計算機システム環境では、多数のユーザが計算機が管理するファイルにアクセスする。このような環境でセキュリティを確保するため、計算機システムではユーザ毎にファイルへのアクセス権を設定することが必要となる。また、多数のユーザが要求する様々な用途に応じるため、このような計算機システムにおいては、個々のファイルに対し、用途に応じたファイル属性を状況に応じて設定することが必要となる。
【０００９】
ところが従来の計算機で実行されるファイルを管理するプログラム（以下「ファイルシステム」）では、ファイルに設定できるファイル属性の数や種類に制限があった。また、ファイル属性がファイルシステム全体で固定して管理されているので、個々のファイルに与えられたファイル属性の種類や数を自由に増減することはできず、ファイル属性の管理に柔軟性がなかった。
【００１０】
また、複数サイトに存在する計算機が管理する記憶装置にファイルを複製して格納するサービスをストレージサービスプロバイダ等が行う際、プロバイダとしては、各サイトの計算機が管理する記憶装置毎に異なる課金条件（以下、「課金ポリシー」）を設定し、その課金ポリシーに基づいた課金するために必要な情報（以下「課金情報」）を採取したいという要求がある。ところが、従来のファイルシステムでは、ファイル属性情報として、ファイルの容量やファイルへのアクセス回数のみの固定的な情報しか採取しておらず、あるサイトでの課金ポリシーに基づいた特定の課金情報、例えばファイルを格納する記憶装置の種類等についての情報は収集できなかった。
【００１１】
本発明の目的は、ファイルに対して柔軟にファイル属性を追加、削除できる計算機システムを提供することである。
【００１２】
また本発明の別の目的は、複数のサイトの課金ポリシーを反映した課金情報を採取する計算機システムを提供することである。
【００１３】
【課題を解決するための手段】
上記目的を達成するため、本発明の計算機システムは以下の構成とする。すなわち、計算機システムは、計算機システム内に格納されるファイルを管理するためのデータ（以下、ファイル管理情報）が格納された記憶装置を管理する第一の計算機及び第一の計算機とネットワークを介して接続され、ファイルの実データ（以下「ファイルデータ」）が格納された記憶装置を管理する第二の計算機を有する。そして、本計算機システムにおいては、ユーザからのファイルアクセス要求を受けた第一の計算機は、第一の計算機が管理するファイル管理情報をファイルアクセス要求の内容に基づいて検索し、検索された情報の内容にしたがって、ファイルアクセス要求に対応するファイルの処理要求をネットワークを介して第二の計算機に送信する。ファイルの処理要求を受信した第二の計算機は、ファイルの処理要求で指定される処理を行い、その結果を第一の計算機に送信する。結果を受信した第一の計算機は、その内容に基づいてユーザに結果を送信する。
【００１４】
尚、ファイル管理情報には、ファイル属性についての情報、ファイルの使用の可否についての情報及びシステムにおけるファイルの格納位置を示す情報が含まれても良い。
【００１５】
さらに、ファイル属性についての情報には、ある一つのファイル属性を有するファイルのみを管理するテーブルが含まれていても良い。ここで、ある一つのファイル属性としては、ファイルが暗号化されているかどうかという属性が考えられるが、これに限られない。
【００１６】
また、ファイル管理情報には、課金情報、具体的には、ファイルを使用するユーザの第二の計算機毎のファイル使用に関する情報等が含まれていても良い。この場合、第一の計算機は、ファイルアクセス要求をユーザから受取った際に、そのアクセス内容に応じて第二の計算機ごとのファイル使用に関する情報を更新する。
【００１７】
更に、本計算機システムは課金管理用の計算機を有し、課金管理用の計算機は、第二の計算機毎の課金情報を用いて、ファイルのユーザの料金を計算しても良い。
【００１８】
尚、第一の計算機及び第二の計算機は複数でもよく、第一の計算機は、記憶装置に格納されるファイル管理情報の数だけ存在しても良い。
【００１９】
更に、第二の記憶装置も複数有り、ファイルデータの複製が複数の第二の記憶装置に分散して格納されてもよい。
【００２０】
【発明の実施の形態】
以下、図を用いて本発明の実施形態を説明する。
【００２１】
図１は、本発明を適用した計算機システムの実施形態を示す図である。計算機システムは、サイト１５００Ａ及びサイト１５００Ｂを有し、これらのサイト間はインターネット１０００を介して接続されている。
【００２２】
サイト１５００は、ユーザが使用する複数の計算機（以下「クライアント」）８００、ファイル管理情報（以下「メタデータ」）を管理する複数の計算機（以下「ＣＮ」）１０１、ファイルデータを管理する複数の計算機（以下「ＳＮ」）３０１及び複数の記憶装置６００を有する。ここで、クライアント８００、ＣＮ１０１及びＳＮ３０１は、ネットワーク７００を介して相互に接続されている。また、複数の記憶装置６００、ＣＮ１０１及びＳＮ３０１は、ファイバーケーブルなどで構成されたストレージネットワーク５００を介して相互に接続されている。
【００２３】
尚、ストレージネットワーク５００では、通信プロトコルとして、ＳＣＳＩやファイバチャネルプロトコルが使用される。
【００２４】
ネットワーク７００は、インターネット１０００を介してサイト１５００Ｂのネットワーク７００に接続されている。したがって、サイト１の各クライアント８００、ＣＮ１０１及びＳＮ３０１は、サイト１５００ＢのＳＮ３０１Ｃとネットワーク７００及びインターネット１０００を介して通信可能である。
【００２５】
クライアント８００、ＣＮ１０１及びＳＮ３０１は、プロセッサ、メモリ、入出力部、ネットワークインターフェース及び記憶装置を有する計算機である。
【００２６】
ＣＮ１０１のプロセッサは、メタデータの管理を行うサーバプログラム（以下「ＭＳＶＲ」）１００と、メタデータを格納するデータベースの管理を行うサーバプログラム（以下「ＤＢＭＳ」）３０２を実行する。これらのプログラムはメモリに格納される。一方、ＳＮ３０１のプロセッサは、ファイルデータの管理を行うサーバプログラム（以下「ＦＳＶＲ」）３００を実行する。ＦＳＶＲ３００は、ＳＮ３０１が有するメモリに格納される。
【００２７】
記憶装置６００は、制御部及び記憶部を有する。記憶部に使用される記憶媒体としては、磁気ディスク、半導体ディスクまたは光ディスクがある。また、記憶装置６００には、記憶部としてこれらディスクを単体で使用するディスク装置や、記憶部として複数のディスク装置を使用するディスクアレイ等の記憶装置システムが含まれる。
【００２８】
ＣＮ１０１及びＳＮ３０１は、ＭＳＶＲ１００及びＦＳＶＲ３００を実行して、協調して記憶装置６００に格納されたファイルの管理を行う。本実施形態においては、ファイル属性や課金情報などのメタデータと、ファイルデータがそれぞれ異なる計算機及び異なる記憶装置６００で管理される。これにより、より柔軟なファイル属性の管理が行える
記憶装置６００Ａの記憶部には、ファイル属性データベース（以下「ＤＢ」）１１０及び各ユーザの課金情報ＤＢ２１０が格納される。ファイル属性ＤＢ１１０には、ファイル属性テーブル１２０、ＡＣＬテーブル１３０、拡張属性テーブル１４０、ロケーションテーブル１５０及びファイルＩＤビットマップ１６０が格納される。一方、課金情報ＤＢ２１０には、サーバ単位課金情報テーブル２２０が格納される。
【００２９】
ＣＮ１０１Ａは、ＭＳＶＲ１００Ａを実行し、かつファイル属性ＤＢ１１０を用いて、記憶装置６００Ｂ及びＣに格納されたファイルデータに対応するファイル属性を管理する。ＣＮ１０１Ａは、ＭＳＶＲ１００Ｂを実行し、かつ課金情報ＤＢ２１０を用いて、計算機システムに格納されたファイルを使用する際にユーザに課せられる課金を計算するための情報を管理する。
【００３０】
記憶装置６００Ｂ及びＣには、ローカルファイルシステム（以下「ローカルＦＳ」）３１０が格納されている。ローカルＦＳ３１０とは、ファイルデータ３２０、ファイルデータを管理するためのメタデータ３３０及びそれを管理するプログラムから構成されるものである。メタデータ３３０には、ローカルＦＳ３１０が管理するファイルデータ３２０の記憶装置６００における格納位置、データ量等を示す情報が格納されている。
【００３１】
ＳＮ３０１は、ＦＳＶＲ３００を実行することで、ローカルＦＳ３１０を管理制御する。尚、ローカルＦＳ３１０ＡはＳＮ３０１Ａに管理され、ローカルＦＳ３１０ＢはＳＮ３０１Ｂに管理され、ローカルＦＳ３１０ＣはＳＮ３０１Ｃに管理され、ローカルＦＳ３１０ＤはＳＮ３０１Ｄに管理される。
【００３２】
本実施形態の計算機システムでは、クライアント８００がファイルを作成すると、自動的に同一内容を持つ複数のファイルがＣＮ１０１で作成され、その複数のファイルのファイルデータは、それぞれ異なるＳＮ３０１に転送され、それぞれが管理するローカルＦＳ３１０に格納される。各ローカルＦＳ３１０に格納されたファイルデータをローカルファイルと呼ぶ。
【００３３】
本実施形態では、ひとつのファイルに対し、複数のローカルファイルが存在する。これらの各ローカルファイルの格納位置はＣＮ１０１が決定し、格納位置を示す情報は、ＣＮ１０１の指示によって、ファイル属性ＤＢ１１０内のロケーションテーブル１５０に登録される。また、ＣＮ１０１Ａは、ＭＳＶＲ１００Ａを実行することで、ファイルサイズや作成日付などの基本的なファイル属性をファイル属性テーブル１２０で管理する。
【００３４】
さらに、ＣＮ１０１Ａは、ＭＳＶＲ１００Ａを実行することで、各クライアント８００のファイルへのアクセス権をＡＣＬテーブル１３０で管理する。また、ＣＮ１０１Ａは、ＭＳＶＲ１００Ａを実行することで、その他のファイル属性を拡張ファイル属性テーブル１４０で管理する。
【００３５】
一方、ＣＮ１０１Ｂは、ＭＳＶＲ１００Ｂを実行し、かつ課金情報ＤＢ２１０を用いて、ファイルを使用するユーザへの課金に必要な情報を管理する。
【００３６】
一般に、ＳＮ３０１で管理される記憶装置６００の信頼性や性能などの特性は異なるため、ユーザに対する課金ポリシーもＳＮ３０１や記憶装置６００毎に異なる。このため、ＣＮ１０１Ｂは、記憶装置６００を管理するＳＮ３０１とユーザとのペア毎に課金情報のレコードを作成しサーバ単位課金情報テーブル２２０に登録することで、サイト毎あるいはＳＮ３０１毎の課金情報を収集する。
【００３７】
本実施形態では、ＣＮ１０１は、ファイル属性や課金情報をリレーショナルデータベースの形式で管理する。
【００３８】
図２は、ファイル属性ＤＢ１１０が有する各テーブルの構成例を示す図である。ファイル属性テーブル１２０には、すべてのファイルに共通するファイル属性が格納される。ファイル属性テーブル１２０は、ファイルの識別子が登録されるＦＩＬＥ−ＩＤ２２１０、ファイル所有者のＩＤが格納されるＯＷＮＥＲ２２２０、ファイルの作成日付が格納されるＤＡＴＥ２２３０、ファイルサイズが格納されるＳＩＺＥ２２４０及びファイルの種類を示す情報が格納されるＴＹＰＥ２２５０のエントリで構成されている。ファイル属性テーブル１２０では、１つのファイルに対して１つのレコードが存在する。
【００３９】
ＡＣＬテーブル１３０には、ファイルに対するユーザ毎のアクセス権限に関する情報が格納される。具体的には、ＡＣＬテーブル１３０は、ファイルの識別子が登録されるＦＩＬＥ−ＩＤ２１１０、ユーザの識別子が登録されるＵＳＲ２１２０、アクセス権限の種別、例えばファイルの読み出し又は書き込みについてのアクセス権限の有無の情報が登録されるＲＥＡＤ２１３０及びＷＲＩＴＥ２１４０並びにファイルに対するアクセス可能期限の情報が登録されるＥＸＰＩＲＥ２１５０の各エントリを有する。ＡＣＬテーブル１３０には、ファイルとユーザの組み合わせに対応するレコードが、ファイルとユーザの組み合わせ数分存在する。
【００４０】
拡張属性テーブル１４０は、ファイルの種類に応じた属性を管理する属性テーブルとして使用される。図２では、拡張属性テーブル１４０を暗号化ファイルの属性を管理するための属性テーブルとして使用する例を示している。この場合、拡張属性テーブル１４０は、ファイルの識別子が登録されるＦＩＬＥ−ＩＤ２４１０及び暗号化キーの情報が登録される暗号化キー２４２０のエントリで構成される。
【００４１】
ここで、本計算機システムで管理されるファイルが暗号化ファイルの場合には、図２に示す拡張属性テーブル１４０が使用される（拡張属性テーブル１４０にそのファイルが登録される）が、他の種類のファイルでは拡張属性テーブル１４０は使用（登録）されない。このように、ファイル属性を格納する拡張属性テーブル１４０をあるファイル属性ごとに個別に設けることで、特定の種類のファイルを特定のテーブルで管理する。このように管理することで、無駄にテーブルのサイズを増大させることなく多種多様なファイル属性を管理することが可能となる。
【００４２】
ロケーションテーブル１５０には、ファイルデータの格納位置を示す情報が保持される。ロケーションテーブル１５０は、ファイルの識別子が登録されるＦＩＬＥ−ＩＤ２３１０及びファイルデータを格納した場所が登録されるＬｏｃａｔｉｏｎ２３２０のエントリを有する。
【００４３】
以上述べた、ファイル属性テーブル１２０、ＡＣＬテーブル１３０、拡張属性テーブル１４０及びロケーションテーブル１５０にはすべてＦＩＬＥ−ＩＤのエントリが含まれている。したがって、各テーブルは、ＦＩＬＥ−ＩＤのエントリを用いて相互に関連するリレーショナルデータベース構造となっており、必要に応じて必要な属性を検索することが可能である。
【００４４】
図３は、サーバ単位課金情報テーブル２２０の構成を示した図である。サーバ単位課金情報テーブル２２０は、ユーザ識別子が登録されるＵＳＲ３１１０、ＳＮ３０１で実行されるＦＳＶＲ３００の識別子が登録されるＦＳＶＲ−ＩＤ３１２０、ＦＳＶＲ３００の実行によりＳＮ３０１で管理される記憶装置６００に格納されているファイルの総記憶容量が登録される使用容量３１３０、記憶装置６００に格納されているファイルの数が登録される総ファイル数３１４０、記憶装置６００からユーザが読み出したデータの量が登録されるＲサイズ３１５０及び記憶装置６００にユーザが書き込んだデータの量が登録されるＷサイズ３１６０の各エントリで構成される。
【００４５】
尚、サーバ単位課金情報テーブル２２０は、ユーザのローカルＦＳの使用情報をＳＮ３０１（具体的には、ＳＮ３０１で実行されるＦＳＶＲ３００）毎に蓄積するため、各々のユーザとＳＮ３０１のペア毎のレコードを有する。
【００４６】
ＣＮ１０１Ｂは、ＭＳＶＲ１００Ｂを実行し、ＵＳＲ３１１０に登録された情報をキーにして課金情報ＤＢ２１０内を検索することで、各ＳＮ３０１が管理する記憶装置６００のユーザ毎の使用状況を取得することができる。
【００４７】
なお、本実施形態では、リレーショナルデータベースを用いてファイル属性ＤＢ１１０及び課金情報ＤＢ２１０を管理する例を説明したが、リレーショナルデータベースの代わりにオブジェクト指向データベースやＸＭＬデータベースを用いることも可能である。
【００４８】
次に、本計算機システムでユーザがファイルを読み出すあるいはファイルを更新する（ファイルにデータを書き込む）処理について説明する。
【００４９】
まず、ユーザがファイルを更新する場合について説明する。以下、すでにファイル（以下「ＦＩＬＥ１」）が本計算機システム内に作成されているとして説明を行う。クライアント８００Ａを使用するユーザ（識別子としてＵＳＲ１が与えられている）がＦＩＬＥ１のデータの更新を行う場合、始めにクライアント８００ＡがＡＧＥＮＴ８１０を実行して、ＣＮ１０１Ａに対してファイルの更新要求（以下「ＷＲＩＴＥ要求」）４１００を送信する。
【００５０】
図４の上段に、クライアント８００ＡからＣＮ１０１Ａに送信されるＷＲＩＴＥ要求の具体例を示す。ＷＲＩＴＥ要求４１００には、コマンド種類４１１０、ユーザ識別子４１２０、ファイル識別子４１３０、ＷＲＩＴＥ開始オフセット４１４０、データサイズ４１５０およびデータ４１６０の各エントリが含まれる。
【００５１】
本実施形態のＷＲＩＴＥ要求の各エントリには、具体的には以下のような情報が登録される。コマンド種類４１１０エントリには本要求がデータ更新要求であることを示す「ＷＲＩＴＥ」、ユーザ識別子４１２０エントリには要求を発行したユーザを示す情報である「ＵＳＲ１」、及びファイル識別子４１３０エントリには対象となるファイルを指定する情報である「ＦＩＬＥ１」が登録されている。
【００５２】
また、ＷＲＩＴＥ開始オフセット４１４０、データサイズ４１５０およびデータ４１６０エントリには、ファイル内でのデータを更新すべき位置、データサイズ及び実際のデータが各々格納される。
【００５３】
図７は、ＷＲＩＴＥ要求４１００を受信したＣＮ１０１Ａの処理手順を示すフローチャートである。ＣＮ１０１Ａは、ＭＳＶＲ１００Ａを実行することで本処理を実行する。
【００５４】
ＷＲＩＴＥ要求４１００を受信したＣＮ１０１Ａは、ユーザのアクセス権限を確認するために、受信したファイル識別子であるＦＩＬＥ１及びユーザ識別子であるＵＳＲ１をキーとして、記憶装置６００Ａに格納されたＡＣＬテーブル１３０を検索する検索要求を作成する。ＣＮ１０１Ａは、作成された検索要求を実行するためにＤＢＭＳ１０２Ａの実行を開始する。
【００５５】
ここで、図１１に、この検索要求の具体例であるＡＣＬテーブル検索要求６０００Ａの内容を示す。
【００５６】
ＡＣＬテーブル検索要求６０００は、コマンド名６００１、選択フィールド名６００２、検索対象テーブル名６００３及び検索条件６００４エントリで構成される。図１１の例では、コマンド名６００１Ａに“ＳＥＬＥＣＴ”、選択フィールド名６００２Ａに“ＷＲＩＴＥ”、検索対象テーブル名６００３Ａに“ＡＣＬテーブル”、及び検索条件６００４Ａに“ＦＩＬＥ−ＩＤ＝ＦＩＬＥ１ ＡＮＤＯＷＮＥＲ＝ＵＳＲ１ ＡＮＤ ＣＵＲＤＡＴＥ（）＜ＥＸＰＩＲＥ”が指定されている。
【００５７】
上述の登録内容によって、具体的には、ＡＣＬテーブル１３０から、ＦＩＬＥ−ＩＤがＦＩＬＥ１、ＯＷＮＥＲフィールドがＵＳＲ１、及びＥＸＰＩＲＥフィールドの期限が現在時刻よりも大きい値が登録されているレコードの検索が指定される。
【００５８】
ＣＮ１０１Ａは、ＤＢＭＳ１０２Ａを実行することで、ＡＣＬテーブル検索要求６０００で指示された検索処理をファイル属性ＤＢ１１０に対して指示し、その結果を記憶装置６００Ａから受信する。ここで、ＣＮ１０１ＡがＤＢＭＳ１０２Ａを実行することで実行する検索処理には、データベースの高速検索技術が用いられる。例えばＵＳＰ６，３５３，８２０Ｂ１に記述されているような方法を用いて、高速な検索処理を実行することが可能である。
【００５９】
本実施形態では、ＡＣＬテーブル検索要求６０００の検索条件６００４を満たすレコードがレコード２１１１であるので、検索結果として、レコード２１１１のＷＲＩＴＥフィールド２１４０に登録された値がＣＮ１０１Ａに送信される（ステップ５０００）。
【００６０】
その後、ＣＮ１０１Ａは、送信されたＷＲＩＴＥフィールド２１４０の値が１かどうかによりＷＲＩＴＥ要求が許可されているかどうかを判断する。本実施形態では、値が１である場合にはファイルへのアクセス許可を示す。したがって、抽出されたＷＲＩＴＥフィールド２１４０の値は１であるため、ＣＮ１０１Ａは、本ＷＲＩＴＥ要求が許可されていると判断する（ステップ５０２０）。
【００６１】
ＷＲＩＴＥフィールド２１４０が０の場合は、ＣＮ１０１Ａは、ＷＲＩＴＥ要求が許可されていないと判断し、クライアント８００Ａにアクセス不許可の旨を通知して処理を終了する（ステップ５１００）。
【００６２】
ＷＲＩＴＥ要求が許可される場合、次にＣＮ１０１Ａは、更新すべきファイルの位置を把握する必要がある。そのため、ＣＮ１０１Ａは、ロケーションテーブル検索要求６１００作成し、ＤＢＭＳ１０２Ａを実行してロケーションテーブル１５０を検索することにより、ファイルを更新する位置を示す情報が含まれるロケーション情報を記憶装置６００Ａから取得する。
【００６３】
図１１に、ロケーションテーブル検索要求６１００の例を示す。ＦＩＬＥ１の格納位置を得るためのロケーションテーブル検索要求６１００には、検索コマンド６１０１に“ＳＥＬＥＣＴ”、取得フィールド６１０２に“ＬＯＣＡＴＩＯＮ”、検索対象テーブル６１０３に“ロケーションテーブル”、検索条件６１０４に“ＦＩＬＥ−ＩＤ＝ＦＩＬＥ１”の情報が登録される。
【００６４】
このロケーションテーブル検索要求６１００を用いて、ＤＢＭＳ１０２Ａを実行するＣＮ１０１Ａは、ロケーションテーブル１５０の検索を記憶装置６００に指示し、ＦＩＬＥ−ＩＤフィールドに“ＦＩＬＥ１”が指定されているレコード２３１１及び２３１２についての情報を記憶装置６００Ａから取得する。
【００６５】
その後、ＣＮ１０１Ａは、取得されたレコードから、ＬＯＣＡＴＩＯＮフィールド２３２０に格納されている情報である“ＦＳＶＲ１：／ＦＩＬＥ１”と“ＦＳＶＲ３：／ＦＩＬＥ１”の情報を抽出する（ステップ５０３０、５０４０）。
【００６６】
ＬＯＣＡＴＩＯＮフィールド２３２０に格納された値を抽出したＣＮ１０１Ａは、抽出した値に含まれる全てのＳＮ３０１に対して、ローカルファイルＷＲＩＴＥ要求を送信する。
【００６７】
図５の上段に、ローカルファイルＷＲＩＴＥ要求４５００の具体例を示す。ローカルファイルＷＲＩＴＥ要求４５００には、送信先ＦＳＶＲ４５１０、ローカルファイルＩ／Ｏコマンド４５２０、ローカルファイル名４５３０、ＯＦＦＳＥＴ４５４０、ＳＩＺＥ４５５０及びデータ４５６０のエントリが含まれる。
【００６８】
本実施形態の場合、送信先ＦＳＶＲ４５１０にはＳＮ３０１Ａ又はＣを示す情報が登録され、ローカルファイルＩ／Ｏコマンド４５２０には、ローカルファイル更新要求であることを示すＷＲＩＴＥが登録される。また、他のエントリには、各々、ローカルファイルの位置等を示す情報が登録される（ステップ５０５０）。
【００６９】
図８は、ローカルファイルＷＲＩＴＥ要求４５００を受信したＳＮ３０１Ａ（及び３０１Ｃ）の処理手順を示すフローチャートである。ローカルファイルＷＲＩＴＥ要求４５００を受信したＳＮ３０１Ａは、初めに記憶装置６００Ｂに格納されたメタデータ３３０Ａを参照し、受信したローカルファイルＷＲＩＴＥ要求で指定されたローカルファイル４５３０が使用する記憶装置６００の容量（以下、「使用ディスクサイズ」）を取得する。上述したように、メタデータ３３０Ａには、ローカルＦＳ３１０Ａに格納されたローカルファイルの位置、データ量に関する情報に加え、使用ディスクサイズの情報も含まれている（ステップ５２００）。
【００７０】
次に、ＳＮ３０１Ａは、ローカルファイルシステム３１０Ａに受信したデータを書き込むだけの空き容量が十分にあるかどうかをチェックし、不十分な場合はステップ５２３０に進みＣＮ１０１Ａにエラーを返す。
【００７１】
次に、ＳＮ３０１Ａは、受信したローカルファイルＷＲＩＴＥ要求のＯＦＦＳＥＴ４５４０に登録された情報で示される位置から、受信したデータをＳＩＺＥ４５５０で指定されたサイズだけＳＮ３０１Ａが有するキャッシュメモリに書き込むＷＲＩＴＥ処理及びそのＷＲＩＴＥ処理の結果を記憶装置６００Ｂに反映するＳＹＮＣ処理を行う（ステップ５２１０）。
【００７２】
ＳＹＮＣ処理の完了後、ＳＮ３０１Ａは、メタデータ３３０Ａを参照して、書き込み完了後のローカルファイルの使用ディスクサイズを取得する。その後、ＳＮ３０１Ａは、ローカルファイルの書き込み前後の記憶装置８００の使用ディスクサイズを比較して、ローカルファイルの書き込みによって新たにローカルファイルに与えられた記憶容量、即ち新規ディスク割り当てサイズを算出する（ステップ５２２０）。
【００７３】
尚、この新規ディスク割り当てサイズは、サーバ単位課金情報テーブル２２０の更新時に使用される。サーバ単位課金情報テーブル２２０に存在する使用容量３１２０フィールドには、ユーザに使用されている記憶装置６００の容量を正確に反映する必要がある。
【００７４】
このため、各ローカルファイルへのＷＲＩＴＥ処理で新規に割り当てられた記憶容量を把握する必要があるが、ローカルファイルに対して上書きを行う場合には、既にローカルファイルが存在しているので、新規記憶容量の割り当て処理が発生せず、使用記憶容量の増分が把握されない。このため、ローカルファイルＷＲＩＴＥ処理の前後でＷＲＩＴＥ対象のローカルファイルの使用ディスクサイズを比較し、新規ディスク割り当てサイズを計算する。
【００７５】
最後にＳＮ３０１Ａは、ローカルファイルＷＲＩＴＥ処理の結果をＣＮ１０１Ａに送信する。ＣＮ１０１Ａに送信される内容には、ローカルファイルＷＲＩＴＥ処理に伴うデータの更新が成功したかどうかを示すステータス、書き込み処理が完了したデータのサイズを示す書き込み完了サイズ及び書き込み完了サイズの内新規に割り当てられた新規ディスク割り当てサイズの情報が含まれる（ステップ５２３０）。
【００７６】
図７に戻って説明を続ける。
【００７７】
ＳＮ３０１Ａ（又は３０１Ｃ）から書き込み結果を受信した（ステップ５０６０）ＣＮ１０１Ａは、受信した結果に含まれるステータスの情報をチェックする（ステップ５０７０）。
【００７８】
書き込みに失敗したＳＮ３０１が存在する場合には、ＣＮ１０１Ａは、失敗したＳＮ３０１が管理する記憶装置６００に格納されたローカルファイルの全データの読み出し要求をＳＮ３０１に送信する。ＳＮ３０１からこれらのデータを取得した後、ＣＮ１０１Ａは、取得したデータを書き込みに成功したＳＮ３０１に送信し、書き込みに成功したＳＮ３０１が管理する記憶装置６００に格納されたローカルファイルの書き換えを指示する。これにより、ＣＮ１０１Ａは、計算機システム内で分散された全てのローカルファイルを書き込み前の状態に戻す。その後、ＣＮ１０１Ａは、クライアント８００Ａにエラーを示す結果を送信する（ステップ５０７５）
全てのローカルファイルに対するデータの書き込みに成功した場合、ＣＮ１０１Ａはファイル属性テーブル１２０の更新処理を行う。具体的には、ＣＮ１０１Ａは、ファイル属性テーブル１２０内のファイル識別子４１３０で示されるファイルに対応するレコードのＳＩＺＥフィールド２２４０の値をＷＲＩＴＥ実行後のサイズに更新する。
【００７９】
まず、ＣＮ１０１ＡはＳＩＺＥフィールド取得要求を作成する。この要求には、検索コマンド“ＳＥＬＥＣＴ”、検索先テーブルにファイル属性テーブル、取得フィールドにＳＩＺＥ、検索条件としてＦＩＬＥ−ＩＤフィールドがファイル識別子４１３０と等しい条件を指定する情報が含まれる。ＣＮ１０１ＡがＤＢＭＳ１０２Ａを実行してこのＳＩＺＥフィールド取得要求を処理することで、ＷＲＩＴＥ実行前のＳＩＺＥフィールド２２４０の値が取得できる。
【００８０】
次に、ＣＮ１０１Ａは、ＷＲＩＴＥ要求４１００のＯＦＦＳＥＴ４１４０とＳＩＺＥ４１５０に登録された値を足した値と、ＳＩＺＥフィールド取得要求で取得されたＳＩＺＥフィールド２２４０に登録された値を比較する。ＳＩＺＥフィールド取得要求で取得された値が足された値と等しい又は大きい場合は、ファイルサイズの更新処理の必要が無いため、ＣＮ１０１Ａは、本ファイル属性テーブル更新処理を終了し、次の処理を実行する。
【００８１】
ＳＩＺＥフィールド取得要求で取得された値が足された値より小さい場合には、ＣＮ１０１Ａは、ＯＦＦＳＥＴ４１４０とＳＩＺＥ４１５０を足した値を新しいファイルサイズとしてファイル属性テーブルを更新する。
【００８２】
具体的には、ＣＮ１０１Ａはファイルサイズ更新要求を作成する。ファイルサイズ更新要求には、更新コマンド“ＵＰＤＡＴＥ”、検索先テーブルにファイル属性テーブル、更新命令として“ＳＥＴ ＳＩＺＥ＝新ファイルサイズ”、更新条件としてＦＩＬＥ−ＩＤフィールドがファイル識別子４１３０と等しい条件を指定する情報が含まれる。ＣＮ１０１Ａが、ＤＢＭＳ１０２Ａを実行してこのファイルサイズ更新要求を処理することにより、ファイル属性テーブルが更新され、結果が記憶装置６００に反映される（ステップ５０７５）。
【００８３】
ファイル属性テーブル更新処理が終了すると、ＣＮ１０１Ａは、ＣＮ１０１Ｂに課金情報ＤＢ更新要求４７００を送信する（ステップ５０８０）。
【００８４】
図６に、課金情報ＤＢ更新要求４７００の内容の具体例を示す。課金情報ＤＢ更新要求４７００は、送信先ＭＳＶＲ４７１０、ユーザ識別子ＵＳＲ４７２０、ファイルサーバ識別子４７３０及びファイルサーバ毎書き込み情報リスト４７４０のエントリを有する。
【００８５】
ファイルサーバ毎書き込み情報リストエントリ４７４０は更に、ファイルサーバ識別子４７５０、ＲＥＡＤ完了サイズ４７６０、ＷＲＩＴＥ完了サイズ４７７０及びディスクサイズ４７８０のエントリを含む。
【００８６】
ＣＮ１０１Ａより課金情報ＤＢ更新要求を受信したＣＮ１０１Ｂは、課金情報テーブル２２０の更新処理を行う。課金情報テーブル２２０の更新処理については後述する（ステップ５０８０）。
【００８７】
ＣＮ１０１Ｂから課金情報ＤＢ更新処理終了の通知を受信したＣＮ１０１Ａは、クライアント８００Ａに対して書き込み完了を報告し（ステップ５０９０）、ＷＲＩＴＥ処理を終了する（ステップ５１００）。
【００８８】
図９は、課金情報ＤＢ更新要求を受信したＣＮ１０１Ｂが行う課金情報テーブル２２０の更新処理の手順を示す図である。
【００８９】
ＣＮ１０１Ｂは最初に、ユーザ識別子及びＳＮ３０１を示す識別子のペアをキーにして、課金情報テーブル２１０内でそれらペアと一致するレコードの検索並びに検索されたレコードに含まれる使用容量３１２０エントリ及びＷサイズ３１５０エントリにそれぞれ課金情報ＤＢ更新要求に含まれるディスクサイズ４７８０エントリとＷＲＩＴＥサイズ４７７０エントリに登録された情報の足しこみを指示するデータベース更新要求６２００を作成し、ＤＢＭＳ１０２Ｂの実行を開始する。
【００９０】
データベース更新コマンド要求は、コマンド名６２０１、更新テーブル名６２０２、更新情報６２０３及び検索条件６４０４のエントリを有する。図１２は、データベース更新要求６２００の具体例を示した図である。データベース更新要求６２００Ａ（及びＢ）の各エントリには、コマンド名６２０１Ａ（及び６２０１Ｂ）に“ＵＰＤＡＴＥ”を、更新テーブル名６２０２Ａ（及び６２０２Ｂ）に“課金情報テーブル”を、検索条件６２０４Ａ（及び６２０４Ｂ）に“ＵＳＲ＝ＵＳＲ１ ＡＮＤ ＦＳＶＲ−ＩＤ＝ＦＳＶＲ３００Ａ”を示す情報が指定される。また、更新情報６２０３Ａには“使用容量＝使用容量＋ＤＳＫサイズ”を示す情報が、更新情報６２０３Ｂには“Ｗサイズ＝Ｗサイズ＋ＷＣＳＩＺＥ”を示す情報が指定されている。
【００９１】
本実施形態の場合、ＵＳＲ１及びＦＳＶＲ１のキーで選択される課金情報ＤＢ２１０内のレコード３１１１並びにＵＳＲ１及びＦＳＶＲ３のキーで選択されるレコード３１１２の２つのレコードが存在する。このため、始めにＣＮ１０１Ｂは、ＵＳＲ１及びＦＳＶＲ１のキーで選択されるレコード３１１１に対するデータベース更新コマンド６２００Ａ（および６２００Ｂ）を作成し、ＤＢＭＳ１０２Ｂを実行する（ステップ５４００）。
【００９２】
ＤＢＭＳ１０２Ｂを実行するＣＮ１０１Ｂは、作成されたデータベース更新コマンド６２００Ａ（および６２００Ｂ）に基づいて、各々のレコードの使用容量３１２０エントリ及びＷサイズ３１５０エントリに、新規割り当てディスクサイズと書き込み完了サイズを足しこんだ結果を記憶装置６００Ａに書き込む処理を行う。
【００９３】
データベース更新要求処理時に、指定したユーザ識別子とＦＳＶＲ３００を指定する識別子の組に一致するレコードが存在しない場合、課金情報ＤＢ更新処理はエラーとなる。このため、ＣＮ１０１Ｂは、データベース更新要求６２００の処理が成功したかどうかについての情報（実行結果）を記憶装置６００Ａから収集する。
【００９４】
ＣＮ１０１Ｂは、収集されたデータベース更新要求実行結果を参照し、本処理が成功したかどうかを判断する（ステップ５４１０）。
【００９５】
ＵＳＲ１及びＦＳＶＲ１のキーに基づいた課金情報ＤＢ更新処理が失敗した場合、それはＵＳＲ１及びＦＳＶＲ１をキーとしたレコードが、課金情報テーブル２２０に存在しないことを意味する。このため、このエラーが発生した場合には、ＣＮ１０１Ｂは、新規レコード追加要求を記憶装置６００Ａに送信する必要がある。尚、このエラーは、新規ファイルに対する書き込みの場合に発生するが、ここでは既存のファイルに対する書き込み処理の例であるため発生しない。本処理の詳細は、後述の新規ファイル作成処理で説明する（ステップ５４２０）。
【００９６】
ＣＮ１０１Ｂは、ＵＳＲ１及びＦＳＶＲ１に対するデータベース更新処理要求が完了すると、課金情報ＤＢ更新要求４７００のファイルサーバ毎書き込み情報リスト４７４０に指定されたＳＮ３０１全てに対する処理が終了したかどうか判断し（ステップ５４３０）、終了していない場合にはステップ５４００〜５４２０を繰り返す。本実施形態の場合、ＣＮ１０１Ｂは、次のＵＳＲ１及びＦＳＶＲ３をキーとしたレコードに対し、ステップ５４００〜ステップ５４２０の処理を繰り返す。
【００９７】
課金情報ＤＢ更新要求に含まれるファイルサーバ毎書き込み情報リスト４７４０に指定された全ＳＮ３０１に対する課金情報更新処理が終了すると、ＣＮ１０１Ｂは、結果をＣＮ１０１Ａに送信し、処理を終了する（ステップ５４４０）。
【００９８】
このように、データベースで課金情報を管理することで、ＳＮ３０１毎の課金情報を容易に管理することが可能となる。
【００９９】
尚、本実施形態では、ファイル属性ＤＢ１１０と課金情報ＤＢ２１０を異なるＣＮＲ１０１で管理する例を説明したが、両ＤＢをひとつのＣＮ１０１で管理する構成としても良い。
【０１００】
次に、ユーザがクライアント８００Ａを介してファイルを読み出すＲＥＡＤ処理の例を説明する。尚、ここでは、すでにあるファイル（以下「ＦＩＬＥ２」）がシステム内に作成されているとして説明を行う。
【０１０１】
クライアント８００Ａを使用するユーザ（以下「ＵＳＲ２」）がＦＩＬＥ２の読み出しを行う場合、始めにクライアント８００Ａは、ＡＧＥＮＴ８１０を実行して、ＣＮ１０１Ａに対してＲＥＡＤ要求４２００を送信する。
【０１０２】
図４の中段に、ＲＥＡＤ要求の具体例を示す。ＲＥＡＤ要求４２００には、コマンド種類４２１０、ユーザ識別子４２２０、ファイル識別子４２３０、ＲＥＡＤ開始オフセット４２４０及びデータサイズ４２５０の各エントリが含まれる。本例では、コマンド種類４２１０エントリには、ファイルの読み出し要求であることを示す「ＲＥＡＤ」が、ユーザ識別子４２２０には「ＵＳＲ２」が、ファイル識別子４２３０には、「ＦＩＬＥ２」を示す情報が登録されている。また、ＲＥＡＤ開始オフセット４２４０、データサイズ４４５０には、ファイル内でのデータを読み出すべき位置、データサイズが各々格納される。
【０１０３】
なお以下では特に断りのない限り、ＣＮ１０１ＡはＭＳＶＲ１００Ａを実行することで処理を行う。
【０１０４】
ＲＥＡＤ要求４２００を受信したＣＮ１０１Ａは、ユーザのアクセス権限を確認するために、受信したファイル識別子であるＦＩＬＥ２及びユーザ識別子であるＵＳＲ２をキーとして、ＡＣＬテーブル１３０を検索するＡＣＬテーブル検索要求６０００Ｂを作成する。次に、ＤＢＭＳ１０２Ａを実行して上記ＡＣＬテーブル検索要求６０００Ｂを記憶装置６００Ａに送信し、アクセス権限に関する情報を記憶装置６００Ａから取得する。
【０１０５】
ＡＣＬテーブル検索要求６０００Ｂの具体例を図１１に示す。ＡＣＬテーブル検索要求６０００Ｂの各エントリには、コマンド名６００１Ｂに“ＳＥＬＥＣＴ”を、選択フィールド名６００２Ｂに“ＲＥＡＤ”を、検索対象テーブル名６００３ＢにＡＣＬテーブルを、検索条件６００４Ｂに“ＦＩＬＥ−ＩＤ＝ＦＩＬＥ２ ＡＮＤ ＯＷＮＥＲ＝ＵＳＲ２ ＡＮＤ ＣＵＲＤＡＴＥ（）＜ＥＸＰＩＲＥ”を指定する情報が登録されている。
【０１０６】
このＡＣＬテーブル検索要求６０００Ｂにより、ＣＮ１０１ＡはＤＢＭＳ１０２Ａを実行して、ＡＣＬテーブルからＦＩＬＥ−ＩＤにＦＩＬＥ２を持ち、ＯＷＮＥＲフィールドにＵＳＲ２を持ち、ＥＸＰＩＲＥフィールドの期限が現在時刻よりも大きいレコードを選択し、そのＲＥＡＤフィールドを記憶装置６００Ａから取得する。
【０１０７】
本実施形態では、検索条件６００４Ｂエントリに登録された条件を満たすレコードはレコード２１１３であるため、ここでは、ＣＮ１０１Ａは、記憶装置６００Ａから、レコード２１１３のＲＥＡＤフィールド２１３０に登録された値を取得できる。
【０１０８】
ＣＮ１０１Ａは、ＤＢＭＳ１０２Ａの実行により得られたＲＥＡＤフィールドの値が１かどうかによりＲＥＡＤ要求が許可されているかどうかを判断する。ここでは、ＲＥＡＤフィールド２１３０の値は１であるため、ＣＮ１０１Ａは本ＲＥＡＤ要求が許可されていると判断する。
【０１０９】
ＲＥＡＤフィールド２１３０が０の場合は、ＣＮ１０１Ａは本ＷＲＩＴＥ要求が許可されていないと判断し、クライアント８００Ａにアクセス不許可の旨を通知して処理を終了する。
【０１１０】
ＲＥＡＤ要求が許可される場合、ＣＮ１０１Ａは読み出すべきファイルの位置を把握する必要がある。ＣＮ１０１Ａは、読み出すべきファイルの位置についての情報であるロケーション情報を、ＷＲＩＴＥ処理と同様にロケーションテーブル検索要求６１００をＤＢＭＳ１０２Ａを実行して処理することにより記憶装置６００から取得する。この時、ロケーションテーブル検索要求６１００の検索条件６１４０には“ＦＩＬＥ−ＩＤ＝ＦＩＬＥ２”が指定される。
【０１１１】
本実施形態においては、この処理により“ＦＳＶＲ１：／ＦＩＬＥ２”と“ＦＳＶＲ３：／ＦＩＬＥ２”の２つのロケーション情報が取得される。
【０１１２】
次にＣＮ１０１Ａは、ファイル識別子であるＦＩＬＥ２を用いて、ファイル属性テーブル１２０を検索し、条件を満たすレコードを記憶装置６００Ａから読み出す。そして、ＣＮ１０１Ａは、選択されたレコードのファイルサイズ２２４０及びファイルタイプ２２５０エントリに登録されている情報を取得する。本実施形態では、ＣＮ１０１Ａは、選択されたレコード２２１２から、ファイルサイズ２０ＭＢ及びファイルタイプＥＮＣＲＹＰＴという情報を取得する。
【０１１３】
ここで、ＥＮＣＲＹＰＴという情報は、ＣＮ１０１Ａがクライアント８００にファイルを転送する時に、そのファイルを暗号化して送信しなければならないファイルタイプであることを意味する。したがって、クライアント８００Ａへファイルデータを転送するときに、ＣＮ１０１Ａは、拡張属性テーブル１４０に格納されている暗号化キーを用いてファイルデータを暗号化する必要がある。
【０１１４】
本実施形態においては、ファイルデータが格納されているＳＮ３０１が管理する記憶装置６００のいずれからでもデータを取得できるため、ＣＮ１０１Ａは、ＳＮ１０１Ａ又はＳＮ１０１Ｃの何れか、もしくは両方にローカルファイルＲＥＡＤ要求４６００を発行することができる。
【０１１５】
以下、ＣＮ１０１Ａが、ＣＮ１０１Ａと同じネットワーク７００に接続されているＳＮ３０１ＡにローカルファイルＲＥＡＤ要求を送信する例を説明する。ただし、ＣＮ１０１Ａが、ＳＮ３０１ＡとＳＮ３０１Ｃの両方に対し、ローカルファイルから半分ずつのデータを読み出すローカルファイルＲＥＡＤ要求を発行しても良い。
【０１１６】
図５の中段に、ローカルファイルＲＥＡＤ要求４６００の具体例を示す。ローカルファイルＲＥＡＤ要求４６００には、送信先ＦＳＶＲ４６１０、ローカルファイルＩ／Ｏコマンド４６２０、ローカルファイル名４６３０、ＯＦＦＳＥＴ４６４０及びＳＩＺＥ４６５０の各エントリが含まれる。ローカルファイルＩ／Ｏコマンド４６２０エントリには、ファイルの読み出しを示す「ＲＥＡＤ」の情報が登録される。また、ローカルファイル名４６３０エントリには、ＦＩＬＥ２を示す「ＦＩＬＥ２」が登録される。
【０１１７】
なお以下では、特に断りのない限り、ＳＮ３０１Ａの処理は、ＦＳＶＲ３００Ａの実行により行われる。
【０１１８】
ローカルファイルＲＥＡＤ要求４６００を受信したＳＮ３０１Ａは、指定されたローカルファイルのＯＦＦＳＥＴ４６４０エントリに登録された位置からＳＩＺＥ４５５０エントリで指定されたサイズのデータを読み出すローカルファイルＲＥＡＤ処理を行う。具体的には、ＳＮ３０１Ａは必要なファイルデータを取得するため、適宜記憶装置６００Ｂに読み出し要求を発行する。
【０１１９】
ＳＮ３０１Ａは、ローカルファイルＲＥＡＤ処理が終了したら、読み出したデータとサイズをＣＮ１０１Ａに送信する。
【０１２０】
ＣＮ１０１Ａは、ＳＮ３０１ＡからローカルファイルＲＥＡＤ要求の結果を受信すると、受信した結果に含まれるステータスをチェックし、ローカルファイルの読み出しが成功したかどうかを確認する。
【０１２１】
ＳＮ３０１ＡのローカルファイルＲＥＡＤ処理が失敗した場合には、ＳＮ３０１Ｃに対して同様の要求を発行する。このように、複数のローカルファイルが存在する場合、あるＳＮ３０１の読み出しが失敗しても、他のＳＮ３０１を用いて読み出し処理を行うことが可能であり、信頼性が向上する。ロケーションテーブル１５０に登録されている全てのＳＮ３０１の読み出しが失敗した場合には、ＣＮ１０１Ａはクライアント８００に対してエラーを返す。
【０１２２】
ＳＮ３０１Ａからのローカルファイルの読み出しが成功すると、ＣＮ１０１Ａは課金情報ＤＢ更新要求４７００を作成し、ＣＮ１０１Ｂに送信する。以下、特に断りのない限り、ＣＮ１０１ＢはＭＳＶＲ１００Ｂを実行して処理を行う。
【０１２３】
課金情報ＤＢ更新要求４７００を受信したＣＮ１０１Ｂは最初に、ユーザ識別子及びＦＳＶＲ３００を示す識別子のペアをキーにして、課金情報テーブル２１０内でそれらペアと一致するレコードの検索及び検索されたレコードに含まれるＲサイズ３１４０エントリに、課金情報ＤＢ更新要求４７００に含まれるＲＥＡＤ完了サイズ４７６０エントリに登録された情報の足しこみを記憶装置６００Ａに指示する課金情報テーブル更新要求６２００Ｃを作成する。
【０１２４】
課金情報テーブル更新要求６２００Ｃは、コマンド名６２０１、更新テーブル名６２０２、更新情報６２０３及び検索条件６４０４の各エントリを有する。図１２ではコマンド名６２０１Ｃに“ＵＰＤＡＴＥ”を、更新テーブル名６２０２Ｃに“課金情報テーブル”を、更新情報６２０３Ｃには“Ｒサイズ＝Ｒサイズ＋ＲＣＳＩＺＥ”を、検索条件６２０４Ｃに“ＵＳＲ＝ＵＳＲ２ ＡＮＤ ＦＳＶＲ−ＩＤ＝ＳＮ３０１Ａ”を指定する情報が登録されている例を示す。
【０１２５】
課金情報テーブル２２０でＵＳＲ２及びＳＮ３０１Ａの組に該当するレコードは、レコード３１１３である。このため、ＣＮ１０１Ｂは、ＤＢＭＳ１０２Ｂを実行して、レコード３１１３のＲサイズ３１４０エントリにＲＥＡＤ完了サイズを足しこんだ結果を書き込む処理を、課金情報テーブル更新要求６２００Ｃで記憶装置６００Ａに指示する。
【０１２６】
ＣＮ１０１Ｂは、次に課金情報ＤＢ更新要求４７００のファイルサーバ毎書き込み情報リスト４７４０エントリに指定された全てのファイルサーバに対する処理が終了したかどうか判断し、終了していない場合には前述のデータベース更新要求処理を繰り返す。本実施形態の場合、他に指定されたファイルサーバが存在しないため、ＣＮ１０１Ｂはこの時点で課金情報更新処理を終了し、結果をＣＮ１０１Ａに送信する。
【０１２７】
ＣＮ１０１Ｂから課金情報ＤＢ更新処理終了の通知を受信したＣＮ１０１Ａは、ファイル識別子であるＦＩＬＥ２をキーにして記憶装置６００Ａ内の拡張属性テーブル１４０を検索し、ＦＩＬＥ２が拡張属性テーブル１４０に登録されているかを確認する。本例の場合、ＣＮ１０１Ａは、ＫＥＹ２４２０エントリより、ＦＩＬＥ２をクライアント８００に送信するために必要な暗号化キーＫＥＹ１を取得する。尚、拡張属性テーブル１４０にファイルが登録されていない場合、この属性に対応する処理（本例では暗号化）は行われない。
【０１２８】
その後、ＣＮ１０１Ａは、ＫＥＹ１を用いて読み出されたファイルデータを暗号化し、クライアント８００に対して読み出し結果として暗号化されたファイルデータを送信し、ＲＥＡＤ処理を終了する。
【０１２９】
図１０は、計算機システム内に新しいファイル（以下「新規ファイル」）を作成する場合の処理手順を示す図である。以下の処理は、ＣＮ１０１ＡがＭＳＶＲ１００Ａを実行して行う処理である。
【０１３０】
新規ファイルを作成する場合、ユーザの指示を受けたクライアント８００はＡＧＥＮＴプログラム８１０Ａを実行して、ＣＮ１０１Ａに対してＣＲＥＡＴＥ要求４３００を送信する。図４の下段にＣＲＥＡＴＥ要求４３００の例を示す。ＣＲＥＡＴＥ要求４３００には、ファイル作成コマンド４３１０、ユーザＩＤ４３２０、ファイルの冗長度４３３０、ファイルタイプ４３４０、暗号化キー４３５０、及び有効期限ＥＸＰ＿ＤＡＴＥ４３６０のエントリが含まれる。
【０１３１】
ＣＲＥＡＴＥ要求４３００を受信したＣＮ１０１Ａは、ファイルに割り当てるファイルＩＤを取得する。この処理には、ファイルＩＤビットマップ１６０が用いられる。ファイルＩＤビットマップ１６０には、計算機システムで使用可能なファイルＩＤが登録され、さらに計算機システムで使用中のファイルＩＤにはビット１が、未使用のファイルＩＤにはビット０が割り当てられている。
【０１３２】
ＣＮ１０１Ａは、記憶装置６００Ａに格納されたファイルＩＤビットマップ１６０を検索して０のビットを探すことで、未使用のファイルＩＤを取得することができる。０のビットが見つかると、使用中であることを示すためにＣＮ１０１Ａはそのビットを１にするよう、記憶装置６００に指示する（ステップ５６００）。
【０１３３】
次にＣＮ１０１Ａは、ファイルデータを格納するＳＮ３０１を選択する。ＣＲＥＡＴＥ要求４３００には、ファイルの冗長度が指定されており、ＣＮ１０１Ａは指定された冗長度に相当する数のＳＮ３０１を選択する。この選択は、たとえばＣＮ１０１Ａがネットワーク７００にブロードキャストメッセージを流し、最初にリプライを返したＳＮ３０１から順に選択する方法を使用する（ステップ５６１０）。
【０１３４】
次にＣＮ１０１Ａは、ステップ５６１０で選択されたＳＮ３０１にローカルファイル作成要求４６９０を送信し、その実行結果を受け取る（ステップ５６２０）。図５の下段に、ローカルファイル作成要求４６９０の例を示す。ローカルファイル作成要求４６９０には、ファイルを作成するＳＮ３０１名ＦＳＶＲ４６９１、ローカルファイル作成コマンドＣＲＥＴＥ４６９２及びローカルファイル名４６９３のエントリを有する。ここで、ローカルファイル名４６９３には、ステップ５６００で選択したファイルＩＤを示す情報が登録される。
【０１３５】
ローカルファイル作成要求４６９０を受信したＳＮ３０１はＦＳＶＲを実行し、コマンドに指定されたローカルファイル名４６９３エントリに登録された値を用いてローカルファイルを作成し、その結果をＣＮ１０１Ａに返信する。
【０１３６】
結果を受信したＣＮ１０１Ａは、受信したローカルファイル作成結果が成功したかどうかを判断し（ステップ５６２５）、失敗した場合にはステップ５６１０に戻る。 ローカルファイルの作成が成功した場合、ＣＮ１０１Ａは、ローカルファイル作成に成功したＳＮ３０１の名前ＦＳＶＲをロケーションテーブル１５０に登録する。この登録処理は、ＣＮ１０１ＡがＤＢＭＳ１０２Ａを実行することで実現する。このとき、記憶装置６００へは、ロケーション登録要求６１１０が指定される。
【０１３７】
図１１に、ロケーション登録要求６１１０の具体例を示す。ロケーション登録要求６１１０には、登録コマンドＩＮＳＥＲＴ６１１１、テーブル名６１１２及び登録するレコードの値６１１３の各エントリが含まれる。本例では、登録するレコードの値６１１３に登録される値として、ＦＩＬＥ−ＩＤフィールドにステップ５６００で割り当てたファイルＩＤが、ＬＯＣＡＴＩＯＮフィールドにローカルファイルの作成に成功したＳＮ３０１名“ＦＳＶＲ”と作成したローカルファイル名がセットされる（ステップ５６３０）。
【０１３８】
ロケーションテーブル１５０への情報の登録が完了すると、ＣＮ１０１Ａは、ファイルの冗長度４３３０で指定された数のローカルファイルの作成が完了したかどうかを調べる（ステップ５６４０）。冗長度４３３０で指定された数のローカルファイル作成が完了していない場合には、ステップ５６１０から再び処理を行なう。
【０１３９】
一方、指定された数のローカルファイル作成が完了した場合には、ＣＮ１０１Ａは、ファイルタイプ４３３０で指定されたファイルタイプが拡張属性テーブル１１４０に登録すべきものかどうか、本例ではＥＮＣＲＹＰＴかどうかを調べる（ステップ５６５０）。
【０１４０】
ファイルタイプがＥＮＣＲＹＰＴである場合、ＣＮ１０１Ａは、暗号化キー４３５０で指定されたキー及びファイル−ＩＤを拡張属性テーブル１４０に登録する処理を行なう。この登録処理は、ＣＮ１０１ＡがＤＢＭＳ１０２Ａを実行することで実現され、その際、記憶装置６００への指示として、拡張属性登録要求６０２０が作成される。
【０１４１】
図１１に、拡張属性登録要求６０２０の例を示す。拡張属性登録要求６０２０には、ＤＢ登録コマンド６０２１、拡張属性テーブル名６０２２、登録するレコードの値６０２３の各エントリが含まれる。登録するレコードの値６０２３に登録される値としては、ＦＩＬＥ−ＩＤフィールドにステップ５６００で割り当てたファイルＩＤが、ＫＥＹフィールドに暗号化キー４３５０で指定されたキーがセットされる（ステップ５６６０）。
【０１４２】
ステップ５６５０でファイルタイプがＥＮＣＲＹＩＰＴでないと判断された場合又はステップ５６６０で拡張属性テーブルへの値の登録後、ＣＮ１０１Ａは、ファイル属性テーブ１２０ルの登録処理を行なう。
【０１４３】
このファイル属性テーブルへの登録処理は、ＣＮ１０１ＡがＤＢＭＳ１０２Ａを実行することで実現するが、ＣＮ１０１ＡはＤＢＭＳ１０２Ａを実行する前に、ＤＢＭＳ１０２Ａ実行時に必要なファイル属性テーブル登録要求６０３０を作成する。
【０１４４】
図１１に、ファイル属性テーブル登録要求６０３０の例を示す。ファイル属性テーブル登録要求６０３０には、ＤＢ登録コマンド６０３１、ファイル属性テーブル名６０３２、登録するレコードの値６０３３の各エントリが含まれる。登録するレコードの値６０３３エントリのＦＩＬＥ−ＩＤフィールドにはステップ５６００で割り当てられたファイルＩＤが、ＯＷＮＥＲフィールドにはユーザＩＤ４３２０で指定された値が、ＤＡＴＥフィールドには現在の日時を示すＣＵＲＤＡＴＥ（）が、ＳＩＺＥフィールドには０が、及びＴＹＰＥフィールドにはファイルタイプ４３４０で示される値が設定される。
【０１４５】
ＣＮ１０１Ａは、ＤＢＭＳ１０２Ａ実行時にファイル属性テーブル登録要求６０３０を参照し、その内容に従ってファイル属性テーブル１２０への登録処理を行い、結果を記憶装置６００に反映する（ステップ５６７０）。
【０１４６】
ＣＮ１０１Ａは、ファイル属性テーブルへの登録処理が終了すると、新規ファイルのＡＣＬテーブルへの登録処理を行なう。この登録処理は、ＣＮ１０１ＡがＤＢＭＳ１０２Ａを実行し、以下のＡＣＬテーブル登録要求６０１０を処理することで実現される。
【０１４７】
図１１に、ＡＣＬテーブル登録要求６０１０の例を示す。ＡＣＬテーブル登録要求６０１０には、ＤＢ登録コマンド６０１１、ＡＣＬテーブル名６０１２、登録するレコードの値６０１３のエントリが含まれる。登録するレコードの値６０１３に登録される値としては、ＦＩＬＥ−ＩＤフィールドにステップ５６００で割り当てられたファイルＩＤが、ＯＷＮＥＲフィールドにユーザＩＤ４３２０で指定された値が、ＥＸＰＩＲＥフィールドにＥＸＰ＿ＤＡＴＥ４３６０の値がセットされる（ステップ５６８０）。
【０１４８】
ＡＣＬテーブルへの登録処理が完了すると、ＣＮ１０１Ａは、クライアント８００に対してファイル作成処理が成功したかどうかの情報を返信する。この時、ファイル作成処理に成功した場合には、ファイルＩＤも同時に返す（ステップ５６９０）。
【０１４９】
次に、図１および図１３を用いてユーザ毎の請求金額を計算する実施形態を説明する。上述したように、本計算機システムは、記憶装置６００の使用情報をＳＮ３０１毎に管理している。このため、ＳＮ３０１毎に課金方針や課金単価が異なる場合でもそれらを反映した課金を行うことが可能となる。
【０１５０】
本実施形態では、計算機システムに新たに課金サーバ９００及び課金データＤＢが格納される記憶装置６００Ｄが追加される。課金サーバ９００は、上述したクライアント８００等と同様の計算機である。記憶装置６００Ｄには、以下に説明される各種テーブルが格納される。尚、課金サーバ９００と記憶装置６００Ｄは同一筐体でも別狂態でも良い。本実施形態では、課金データＤＢ９３０を用いてユーザごとの請求金額が計算される。
【０１５１】
具体的には、課金サーバ９００は、請求金額を計算するために課金計算プログラム９１０を実行する。また、課金サーバ９００は、課金を行うユーザのユーザＩＤをユーザテーブル９４０で、ＳＮ３０１毎の課金ポリシーを課金ポリシーテーブル９５０で管理する。
【０１５２】
さらに課金サーバ９００は、記憶装置６００Ｄのユーザテーブル９４０及び課金ポリシーテーブル９５０を検索し、その検索結果を課金請求テーブル９６０に格納するためのプログラムであるＤＢＭＳ９２０を実行する。
【０１５３】
図１４は、ユーザテーブル９４０の構成例を示す図である。ユーザテーブルは本計算機システムを使用するユーザの情報を保持するテーブルであり、ユーザＩＤ７０００、氏名７０１０、請求先７０２０及び備考７０３０等のエントリを含む。。
【０１５４】
図１４上段に、課金請求テーブル９６０の例を示す。課金請求テーブル９６０は、一定使用期間毎の請求金額についての情報を保持するテーブルであり、本テーブル９６０の情報に基づいて、計算機システムの所有者等は使用料を請求する。本テーブル９６０には、ユーザＩＤ７１００、使用月７１１０及び請求金額７１２０などのエントリが含まれる。なお本テーブル９６０には、請求済みかどうか、徴収済みかどうかなどの情報を登録するエントリが含まれていても良い。
【０１５５】
図１４中段に、各ファイルサーバ毎の課金ポリシーを保持する課金ポリシーテーブル９５０の例を示す。本テーブル９５０に格納された情報及び課金情報ＤＢ２１０に格納された情報を元に、課金サーバ９００はユーザ毎の請求金額を計算する。本テーブル９５０には、ファイルサーバ名７２００、単位容量あたりの使用金額を示す容量単価７２１０、ファイル１つあたりの使用金額を示すファイル単価７２２０、単位サイズの読み出しあたりの使用金額を示すＲＥＡＤ単価７２３０及び単位サイズの書き込みあたりの使用金額を示すＷＲＩＴＥ単価７２４０の各エントリが含まれる。
【０１５６】
図１３は、課金サーバ９００が課金計算プログラム９１０を実行して行う処理手順を示す図である。
【０１５７】
課金サーバ９００は、はじめに記憶装置６００Ｄのユーザテーブル９４０からユーザＩＤのリストを取得する。この処理は、課金計算サーバ９００がＤＢＭＳ９２０を実行し、以下のユーザＩＤリスト取得要求６４２０を処理することで実現される。
【０１５８】
図１２に、ユーザＩＤリスト取得要求６４２０の例を示す。ユーザＩＤリスト取得要求６４２０では、検索コマンドエントリ６４２１に“ＳＥＬＥＣＴ”、取得フィールド名エントリ６４２２に“ＵＳＲ”、検索先テーブル名エントリ６４２３に“ユーザテーブル”を示す情報が登録される（ステップ５６００）。
【０１５９】
次に、課金サーバ９００は、取得したリストの先頭のユーザＩＤを取得する（ステップ５６１０）。
【０１６０】
その後、課金サーバ９００は、取得されたユーザＩＤに基づいて、課金情報取得処理を行なう。この処理は、課金サーバ９００がＣＮ１０１Ｂに課金情報検索要求６４１０を発行し、ＣＮ１０１ＢがＤＢＭＳ１０２Ｂを実行することで実現される。
【０１６１】
図１２に、課金情報検索要求６４１０の例を示す。課金情報検索要求６４１０には、検索コマンド“ＳＥＬＥＣＴ”６４１１、全フィールド取得指定“＊”６４１２、検索先テーブル６４１３、検索条件６４１４が含まれる。検索条件６４１４としては、ＵＳＲフィールド３１１０の値がステップ５６００で取得したユーザＩＤと等しいレコードを取得する条件が指定される（ステップ５６２０）。
【０１６２】
課金情報を取得した課金サーバ９００は、次にＳＮ３０１毎の請求金額を計算する。取得された課金情報には、同一ユーザが使用した全ＳＮ３０１に関するサーバ単位課金情報テーブル２２０のレコードが含まれている。課金サーバ９００は、各レコードに含まれるＦＳＶＲ―ＩＤフィールド３１１０の値を用いて課金ポリシテーブル９５０を検索することで、そのＳＮ３０１の課金ポリシを取得し、取得した課金ポリシとサーバ単位課金情報テーブル２２０のレコードの情報とを用いてＳＮ３０１毎の請求金額を計算する。
【０１６３】
この時、課金ポリシテーブル９５０の検索は、課金サーバ９００がＤＢＭＳ９２０を実行し、課金ポリシテーブル検索要求６４３０を処理することで実現される。図１２に、課金ポリシテーブル検索要求６４３０の構成例を示す。課金ポリシテーブル検索要求６４３０は、検索コマンド“ＳＥＬＥＣＴ”６４３１、全フィールド取得指定“＊”６４３２、検索先テーブル“課金ポリシテーブル”６４３３、検索条件６４３４を含む。検索条件６４３４には、ＦＳＶＲフィールド７２００が現在の請求金額計算対象ＳＮ３０１の名前ＦＳＶＲと等しいという条件が指定される。
【０１６４】
尚、選択されたＳＮ３０１に対応する請求金額は、ステップ５６００で取得された課金情報に含まれる使用容量フィールド３１２０、ファイル数フィールド３１３０、Ｒサイズフィールド３１４０、Ｗサイズフィールド３１５０に登録された値に、それぞれ課金ポリシの容量単価７２１０、ファイル単価７２２０、ＲＥＡＤ単価７２３０、ＷＲＩＴＥ単価７２４０の値を掛け合わせて計算できる（ステップ５６３０）。
【０１６５】
ＳＮ３０１毎の請求金額が計算されると、課金サーバ９００は、全ＳＮ３０１の請求金額を合計し、その結果を課金請求テーブル９６０に格納する。この処理は、課金サーバ９００がＤＢＭＳ９２０を実行し、課金請求テーブル登録要求６４００を処理すること出実現される。
【０１６６】
図１２に、課金請求テーブル登録要求６４００の例を示す。課金請求テーブル登録要求６４００は、登録コマンド“ＩＮＳＥＲＴ”６４０１、登録先テーブル名“課金請求テーブル”６４０２及び登録内容６４０３を含む。登録内容６４０３には、ユーザＩＤ、使用月及び請求金額を示す情報が含まれる（ステップ５６４０）。
【０１６７】
ＳＮ３０１の請求金額計算を完了した課金サーバ９００は、全ユーザの請求金額計算の処理が完了したかどうかを判定する。まだ処理の完了していないユーザが存在する場合には、課金サーバ９００は、ステップ５６１０からステップ５６４０の処理を繰り返す（ステップ５６５０）。
【０１６８】
以上説明したとおり、本実施形態により、ＳＮ３０１毎の課金ポリシを反映したきめ細かな課金制御が可能となる。
【０１６９】
【発明の効果】
本発明によれば、ファイル毎に柔軟にファイル属性を付加したり、多数ユーザのアクセス権限情報を効率よく管理する計算機システムを実現することができる。また、複数のサイトに分散したサーバが管理する記憶装置を利用してファイルを格納する場合に、サイトやサーバ毎に課金情報を管理する計算機システムを実現できる。
【図面の簡単な説明】
【図１】本発明を適用した計算機システムの全体構成の例を示す図である。
【図２】ファイル属性ＤＢの各種テーブルの例を示す図である。
【図３】課金情報ＤＢの例を示す図である。
【図４】ファイルＩＯ要求コマンドの例を示す図である。
【図５】ローカルファイルＩＯ要求の例を示す図である。
【図６】課金情報ＤＢ更新要求の例を示す図である。
【図７】ＭＳＶＲ１００Ａの処理を示すフローチャートである。
【図８】ＦＳＶＲ３００の処理を示すフローチャートである。
【図９】ＭＳＶＲ１００Ｂの処理を示すフローチャートである。
【図１０】新規ファイルを作成する場合の処理を示すフローチャートである。
【図１１】ＡＣＬテーブルの検索要求と登録要求、拡張属性テーブル登録要求及びロケーションテーブルの検索要求と登録要求の例を示す図である。
【図１２】課金情報テーブルの更新要求と登録要求、請求金額の計算処理に使用する各種テーブルの登録要求および検索要求の例を示す図である。
【図１３】課金サーバ９００の処理を示すフローチャートである。
【図１４】ユーザテーブル、課金請求テーブル及び課金ポリシテーブルの例を示す図である。
【符号の説明】
１００…ＭＳＶＲ、３００…ＦＳＶＲ、５００…ストレージネットワーク、６００…記憶装置、７００…ネットワーク、１０００…インターネット。

Claims (13)

1. ファイル管理情報が格納された第一の記憶装置と、
   前記第一の記憶装置に接続される第一の計算機と、
   前記第一の計算機とネットワークを介して接続される第二の計算機と、
   前記第二の計算機と接続され、前記ファイル管理情報で管理されるファイルデータが格納される第二の記憶装置とを有することを特徴とする計算機システム。
2. 前記第一の計算機は、
   前記第二の記憶装置に格納されたファイルデータを更新する要求を受信した場合、前記第一の記憶装置に格納された前記ファイル管理情報の内容を確認し、前記ファイル管理情報の内容に従って、前記第二の計算機に前記ファイルデータを更新する要求の対象となるファイルデータの更新を指示する要求を送信し、
   前記第二の計算機は、
   前記指示する要求に基づいて、前記第二の記憶装置に格納されたファイルデータを更新し、その結果を前記第一の計算機に送信することを特徴とする請求項１記載の計算機システム。
3. 前記第一の計算機は、
   前記第二の記憶装置に格納されたファイルデータを読み出す要求を受信した場合、前記第一の記憶装置に格納された前記ファイル管理情報の内容を確認し、前記ファイル管理情報の内容に従って前記第二の計算機に前記ファイルデータを読み出す要求の対象となるファイルデータの読み出しを指示する要求を送信し、
   前記第二の計算機は、
   前記指示する要求に基づいて、前記第二の記憶装置に格納されたファイルデータを読み出し、読み出した前記ファイルデータを前記第一の計算機に送信し、
   前記第一の計算機は、
   受信した前記ファイルデータを、前記ファイルデータを読み出す要求の発信先に送信することを特徴とする請求項２記載の計算機システム。
4. 前記ファイル管理情報には、ファイル属性に関する情報、ファイルデータの格納位置に関する情報及びファイルへのアクセス権限に関する情報が含まれていることを特徴とする請求項３記載の計算機システム。
5. 前記ファイル管理情報には、ある特定のファイル属性を有するファイルのみを管理するテーブルが含まれていることを特徴とする請求項４記載の計算機システム。
6. 前記第一の計算機は、
   前記ファイルデータを読み出す要求及び前記ファイルデータの更新の要求を受信した際に、これらの要求で指定されるファイルが前記テーブルに登録されているか否かを確認し、登録されている場合には、前記テーブルに対応するファイル属性に従った処理を行うことを特徴とする請求項５記載の計算機システム。
7. 前記テーブルに対応するファイル属性が暗号化に関するファイル属性であり、
   前記第一の計算機は、
   前記ファイルデータを読み出す要求を受信した際に、これらの要求で指定されるファイルが前記テーブルに登録されているか否かを確認し、登録されている場合は、前記第二の計算機から受信したファイルデータを前記テーブルに登録されている情報に基づいて暗号化して前記要求元に送信することを特徴とする請求項６記載の計算機システム。
8. 前記ファイル管理情報には、
   該計算機システムを使用する者に対する料金を計算するために必要な情報が含まれていることを特徴とする請求項７記載の計算機システム。
9. 前記必要な情報には、前記使用する者が使用する前記第二の記憶装置に格納されているファイルデータの全容量、前記使用する者が前記第二の記憶装置へ書き込んだデータの総量及び前記使用する者が前記第二の記憶装置から読み出したデータの総量に関する情報が含まれ、これらの情報が前記第二の記憶装置を管理する前記第二の計算機ごとに管理されていることを特徴とする請求項８記載の計算機システム。
10. 前記第二の計算機は、
    前記第一の計算機から前記ファイルデータの更新の要求を受信した場合、前記ファイルデータの更新の要求の処理の際に前記第二の記憶装置に格納されたデータ量及びデータの更新によって増加したデータ量についての情報を前記第一の計算機に送信し、
    前記第一の計算機は、受信した前記情報を用いて、前記第一の記憶装置に格納された前記必要な情報の内容を更新することを特徴とする請求項９記載の計算機システム。
11. 更に第三の計算機及び前記第三の計算機に接続される第三の記憶装置を有し、
    前記第三の記憶装置は前記第二の計算機毎の課金条件についての情報を有し、
    前記第三の計算機は、前記第一の記憶装置に格納された前記必要な情報を前記第一の計算機を介して読み出し、
    読み出した前記必要な情報と前記課金条件についての情報に基づいて、前記使用する者への料金を計算することを特徴とする請求項１０記載の計算機システム。
12. 前記第一の計算機及び前記第一の記憶装置は複数有り、
    前記ファイル属性についての情報と前記必要な情報とは各々異なる前記第一の記憶装置に格納され、各々異なる前記第一の計算機で管理されることを特徴とする請求項８記載の計算機システム。
13. 前記第二の記憶装置は複数有り、前記ファイルデータが複製されて、複数の前記第二の記憶装置の各々に格納されていることを特徴とする請求項１２記載の計算機システム。

Images