JPH1196102A

JPH1196102A - サーバ分散管理方法

Info

Publication number: JPH1196102A
Application number: JP9259591A
Authority: JP
Inventors: Shigekazu Inohara; 茂和猪原; Yoshimasa Masuoka; 義政増岡; Kiyouka Bin; 京華閔; Fumio Noda; 文雄野田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1997-09-25
Filing date: 1997-09-25
Publication date: 1999-04-09
Also published as: US6256747B1

Abstract

(57)【要約】【課題】情報システムの複数サーバの動作状況の把握
とキャッシュ管理を、管理者の手間を増やさず、かつ効
率的に行う。【解決手段】複数のサーバ（１０、１０…）が、相互
支援により動的再構成されるマルチキャスト階層を構成
し、この上でサーバ状態（１０９）、キャッシュ・ディ
レクトリ（１０８）、ヴァリデーションの通信（１０
６）を行う。【効果】管理者は他のいくつかのサーバを指定してサ
ーバを立ち上げる以外、サーバ間の連携を管理する必要
がない。キャッシュ・ディレクトリの交換によってサー
バ間のキャッシュが共有されるとともに、ヴァリデーシ
ョン時間が削減されることで、高速なユーザ反応時間が
得られる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は計算機システムに関
し、特にネットワークによって接続された複数の計算機
が、情報を流通・共有・変更するシステム（情報システ
ム）を構築する際のシステムの管理方法に関し、さらに
具体的にはＷｏｒｌｄ―ＷｉｄｅＷｅｂ（ＷＷＷ）に
好適なサーバ分散管理方法に関する。

【０００２】

【従来の技術】現在の情報システムは、ネットワークで
接続された複数の計算機が情報を提供、または入手する
ことによって運営されている。主に情報を提供する計算
機のハードウェアとソフトウェアを総称してサーバ、主
に情報を入手する計算機のハードウェアとソフトウェア
を総称してはクライアントと呼ぶ。

【０００３】従来用いられている情報システムでは、サ
ーバが複数ある場合、これらのサーバの間にはまったく
連携が存在しない（例えば第１のサーバと第２のサーバ
があっても、互いに存在を知らないか、依存しあわな
い）か、強く連携しあっている（例えば第１のサーバと
第２のサーバがデータを互いに交換したり、キャッシュ
する）かのいずれかである。

【０００４】第１のサーバの動作中に第２のサーバが新
設されるか起動された場合（総称してサーバの追加と呼
ぶ）や、第２のサーバが一時停止したり故障（サーバ自
身の故障と、サーバへの通信回線の故障の両方を含む）
した場合（総称してサーバの削除と呼ぶ）に、第１のサ
ーバと第２のサーバを連携させるためには、従来は管理
者が第１のサーバと第２のサーバの設定を適切に行う必
要があった。

【０００５】このことは、サーバがごく少数である場合
には特に問題にならなかった。しかし、サーバが多数に
なった場合、新たなサーバが追加または削除される際
に、管理者に大きな負担となる。

【０００６】近年のインターネットとＷＷＷの爆発的な
成長により、サーバの数が非常に多数にわたる場面が発
生している。まずＷＷＷで用いられている技術（公知例
１と呼ぶ）を説明する。

【０００７】ＷＷＷでは、ＷＷＷサーバが保持すべき情
報を「ホームページ」と呼ばれる単位で保持している。
ホームページは、それぞれＵＲＬ（ＵｎｉｆｏｒｍＲ
ｅｓｏｕｒｃｅＬｏｃａｔｏｒの略）と呼ばれる名前
を持っている。ＷＷＷクライアントのユーザが、アクセ
スしたいホームページのＵＲＬをＷＷＷクライアントに
指定すると、ＷＷＷの第１の処理形態では、ＷＷＷクラ
イアントは当該ＵＲＬで指定されるＷＷＷサーバに対し
て、当該ＵＲＬに対応するホームページの送信を依頼す
る。当該ＷＷＷサーバは、この要求に応えて、当該ホー
ムページを当該ＷＷＷクライアントに与える。

【０００８】また第２の処理形態では、ＷＷＷクライア
ントが、ユーザが与えたＵＲＬで指定されるＷＷＷサー
バに依頼を行なうかわりに、「プロキシ・サーバ（また
は単にプロキシ）」と呼ばれる別の種類のサーバに依頼
を行なう。プロキシは、当該ＷＷＷサーバから当該ＵＲ
Ｌに対応するホームページを得るか、さらに別のプロキ
シに当該ＵＲＬを転送する。プロキシの依頼が複数段階
である場合、プロキシは親子関係を持つ。親子関係を持
つプロキシに関しては、例えばＡ.Ｃｈａｎｋｈｕｎｔ
ｈｏｄ他の文献”ＡＨｉｅｒａｒｃｈｉｃａｌＩｎ
ｔｅｒｎｅｔＯｂｊｅｃｔＣａｃｈｅ”（１９９６
ＵＳＥＮＩＸＴｅｃｈｎｉｃａｌＣｏｎｆｅｒｅｎｃ
ｅ、ｐｐ.１５３―１６３、１９９６）に記載されてい
る。ＷＷＷのプロキシは、複数のクライアントによって
共有されるキャッシュを持つことができる。このため、
多くのプロキシを擁する第２の処理形態が現在のインタ
ーネットでは広く用いられている。各プロキシがどのプ
ロキシに依頼を転送するかは、管理者が設定する。

【０００９】また、ＷＷＷ以外にもいくつかの情報シス
テムが広く用いられているが、いずれのシステムでも複
数のサーバ間の連携は、管理者が設定する固定的な関係
にとどまっている。

【００１０】ネットワーク・ニュース・システム（以後
公知例２と呼ぶ。Ｂ.Ｋａｎｔｏｒ他著の文献”Ｎｅｔ
ｗｏｒｋＮｅｗｓＴｒａｎｓｆｅｒＰｒｏｔｏｃ
ｏｌ：ＡＰｒｏｐｏｓｅｄＳｔａｎｄａｒｄｆｏ
ｒｔｈｅＳｔｒｅａｍ―ＢａｓｅｄＴｒａｎｓｍ
ｉｓｓｉｏｎｏｆＮｅｗｓ”ＮｅｔｗｏｒｋＷｏ
ｒｋｉｎｇＧｒｏｕｐＲＦＣ―９７７等に記載され
ている）は情報システムの別の例であり、ＷＷＷ同様複
数のサーバによって構成される。

【００１１】ネットワーク・ニュース・システムの複数
のサーバは、クライアントが購読および投稿する「ニュ
ース記事」のコピーを互いに配布しあっている。各サー
バの管理者は、それぞれのサーバが別のどのサーバとニ
ュース記事の授受を行うかを設定する。新たなサーバが
追加された場合、既存のサーバの設定を手動で変更する
必要がある。

【００１２】さらに、ＤＮＳドメイン名前サービス（公
知例３と呼ぶ。例えばＰ.Ｍｏｃｋａｐｅｔｒｉｓ著の
文献”ＤｏｍａｉｎＮａｍｅｓ―Ｉｍｐｌｅｍｅｎｔ
ａｔｉｏｎａｎｄＳｐｅｃｉｆｉｃａｔｉｏｎ”Ｎ
ｅｔｗｏｒｋＷｏｒｋｉｎｇＧｒｏｕｐＲＦＣ―
１０３５の特に第２節に記載されている）も情報システ
ムの別の例であり、複数のサーバによって構成される。

【００１３】ＤＮＳはインターネットのホスト名と、そ
のホスト名の付随情報（ＩＰアドレスやメールサーバ）
とを対応づける。この対応情報を保持するため、複数の
ＤＮＳサーバが木構造を構成する。クライアントの依頼
は当該木構造をたどって、複数のサーバの間を転送さ
れ、処理される。

【００１４】各ＤＮＳサーバが、別のどのＤＮＳサーバ
に依頼を転送するかは、各ＤＮＳサーバの管理者が設定
する。あるＤＮＳサーバが置き換わる場合には、隣接す
るＤＮＳサーバの設定を手動で変更する必要がある。ま
た、前記木構造の各ノードは、２つ以上のＤＮＳサーバ
によって冗長構成をとっているが、これらのＤＮＳサー
バが故障した場合（またはこれらのＤＮＳサーバへのネ
ットワーク経路が故障した場合）には、やはり隣接する
ＤＮＳサーバの設定を手動で変更する必要がある。

【００１５】ローカル・エリア・ネットワーク（ＬＡ
Ｎ）内の分散ファイルシステムにおいて、キャッシュの
ための空間を複数のコンピュータで共有する「協調キャ
ッシング」とよばれる方法も知られている。例えばＭｉ
ｃｈａｅｌＤａｈｌｉｎ他著の文献”Ｃｏｏｐｅｒａ
ｔｉｖｅＣａｃｈｉｎｇ：ＵｓｉｎｇＲｅｍｏｔｅ
ＣｌｉｅｎｔＭｅｍｏｒｙｔｏＩｍｐｒｏｖｅ
ＦｉｌｅＳｙｓｔｅｍＰｅｒｆｏｒｍａｎｃｅ”
（ＦｉｒｓｔＵＳＥＮＩＸＳｙｍｐｏｓｉｕｍｏ
ｎＯｐｅｒａｔｉｎｇＳｙｓｔｅｍｓＤｅｓｉｇ
ｎａｎｄＩｍｐｌｅｍｅｎｔａｔｉｏｎ、ｐｐ.２
６７―２８０、１９９４）（公知例４と呼ぶ）では、
「マネージャ」と呼ばれるサーバが、どのファイル・ブ
ロックがどのファイル・サーバに格納されているかを保
持している。マネージャがクライアントからファイル・
ブロックの転送を依頼されると、クライアントにファイ
ル・ブロックが格納されているコンピュータを返答する
か、当該ファイル・サーバにクライアントの要求を転送
する。マネージャは複数存在することができるが、ファ
イル・ブロックとマネージャとの対応関係はあらかじめ
定められており、この対応関係を変更するためには管理
者が手動で設定を変更する必要がある。

【００１６】

【発明が解決しようとする課題】ＷＷＷでは、ある統計
ではサーバ数が１９９６年６月から１９９７年１月まで
の半年で２.８倍に増加するなど、急激な成長が続いて
いる。このため、ＷＷＷ全体の情報量も爆発的に増えて
いる。プロキシは、複数のクライアントによって共有さ
れるキャッシュとしてユーザの反応時間（ユーザが情報
を要求してからその情報がユーザの手元に届くまでの時
間）を減少させる役目があるが、ＷＷＷ全体の情報量に
比してキャッシュの容量が小さいため、現状では低い効
果しか得られていない。

【００１７】本発明が解決しようとする第１の課題は、
ＷＷＷのプロキシのように複数のサーバを連携して動作
させる際の、管理者の手間を減らすことである。これに
よって、プロキシを多数擁する大規模なキャッシュの実
現において、管理に大量の時間と人数が必要であるとい
う課題を解決する。具体的には、第１のサーバが追加ま
たは削除される場合に、管理者が１つ以上の既存の第２
のサーバの設定を変更することなしに、第１のサーバの
存在（または存在しないこと）を第２のサーバに知ら
せ、また第１のサーバに第２のサーバの存在（または存
在しないこと）を知らせることが課題である。

【００１８】なお第１の課題の解決には、ＷＷＷはイン
ターネットの上で動作しており接続マシン数が膨大であ
り、かつ管理組織も多数にわたるため、ブロードキャス
トを用いる方法や、単一のサーバにすべての設定を集め
る方法は現実的な解決法とならない。また、第２のサー
バが多数になった場合には、第１のサーバと第２のサー
バのすべてが連携することすら現実的ではなくなる。こ
のようにサーバ数が非常に多くなった場合には、連携す
るべきサーバの数を制限するための仕組みが必要とな
る。

【００１９】また第１の課題が解決された場合に、複数
のサーバに分散して存在するキャッシュを運営するため
に、複数のサーバ間で互いのキャッシュのリストを効率
よく交換し、以て１つのサーバのキャッシュにない情報
を別のサーバに問い合わせる方法が必要となる。この方
法を実現することが第２の課題である。

【００２０】さらに、第１および第２の課題が解決され
た場合に、複数のサーバに跨る大規模なキャッシュが実
現されることになるが、この際、ＷＷＷで用いられてい
る通信プロトコルＨＴＴＰ（Ｒ.Ｆｉｅｌｄｉｎｇ他著
の文献”ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏ
ｔｏｃｏｌ―ＨＴＴＰ／１.１、”ＮｅｔｗｏｒｋＷｏ
ｒｋｉｎｇＧｒｏｕｐＲＦＣ―２０６８等に記載さ
れている）では、キャッシュが十分に新しい情報を保持
しているかを確認する動作（ヴァリデーション動作と呼
ぶ）を要求しているが、このヴァリデーション動作がユ
ーザ反応時間を悪化させていることがわかった。このた
め、ヴァリデーション動作がユーザ反応時間を悪化させ
ないようにすることも本発明が解決しようとする第３の
課題である。

【００２１】

【課題を解決するための手段】第１の課題を解決するた
めに本発明の情報システム分散管理方法では、サーバ動
作情報（動作しているサーバのリスト）を分散管理する
ための「サーバ状態伝播プロトコル」を持つ。各サーバ
は、管理者から与えられた少数の他のサーバの名前から
出発して、サーバ群の相互支援によってサーバ動作情報
のマルチキャスト階層を動的に構築する。マルチキャス
ト階層はサーバ群が構成する木構造のグループであり、
各グループは数台から数十台のサーバからなる。一部の
サーバが停止したり再起動するに従って、マルチキャス
ト階層の動的再構成が行われる。

【００２２】このサーバ状態伝播プロトコルにより、上
記第１の課題である複数のサーバを連携して動作させる
際の、管理者の手間が低減される。本発明では、サーバ
の起動時に、他のサーバの名前をいくつか与えるだけで
よく、その後複数のサーバのうち一部が停止したり再起
動する度毎に管理者が各サーバの設定を変更する必要が
ないためである。また、本発明のサーバ状態伝播プロト
コルは、ブロードキャストを必要とせず、マルチキャス
トも動作中のサーバ群にのみ行われるので、インターネ
ット上での使用に耐える。また、各サーバがサーバ動作
情報を交換する際には近接サーバ優先で通信することに
より、サーバ数が膨大になった場合にも動作する。すな
わち、これにより第１の課題が解決される。

【００２３】第２の課題を解決するために本発明の情報
システム分散管理方法では、「広域協調キャッシュ管理
プロトコル」を備える。このプロトコルは、前記サーバ
状態伝播プロトコルが形成するマルチキャスト階層を用
いてキャッシュ・ディレクトリ（ＵＲＬと当該ＵＲＬを
キャッシュ中に保持するサーバのリスト）の伝播と、キ
ャッシュ制御（どのサーバがどのＵＲＬをキャッシュ中
に保持するか、いつ、どのＵＲＬをあるサーバから別の
サーバに移動させるか）を、公知例４のマネージャにあ
たる集中管理サーバなしで行う。

【００２４】サーバがある情報を別のサーバに移動させ
る場合があるが、この場合には移動先サーバを決定する
必要がある。この目的で、サーバが受け入れ可能なキャ
ッシュ価値の最小値（受け入れ可能キャッシュ価値と呼
ぶ）を他サーバに回覧する。また、１つのグループの複
数のサーバが一斉に情報の移動を予定している場合、移
動先が１つのサーバに集中する恐れがある。この問題を
解決するために、各サーバは移動しようとする情報およ
び予定移動先のリストを回覧する。これにより各サーバ
は、他のサーバが選んでいない移動先を避けて移動先サ
ーバを決定することができる。さらに、近接する複数の
サーバが同一情報のキャッシュを保持している場合、こ
のキャッシュのコピーすべてが一斉に破棄されないよう
に工夫することが必要である。集中サーバを用いずに近
似的な方法でこの状態に近づけるために、破棄しようと
する情報のリスト（破棄予定リストと呼ぶ）をサーバの
間で回覧する。自分が破棄しようとする情報のキャッシ
ュがグループのメンバが保持する最後のコピーである場
合には、予定した破棄を中止する。以上により第２の課
題が解決される。

【００２５】第３の課題を解決するために本発明の情報
システム分散管理方法では、従来のようにユーザが情報
を要求した時点でヴァリデーション動作を行うのではな
く、ユーザの要求以前にあらかじめヴァリデーション動
作を行っておく「先行ヴァリデーション」を備える。先
行ヴァリデーションは、一定時間ごとや、ＵＲＬが参照
されてから一定時間経過後などに行う。この先行ヴァリ
デーションをＨＴＴＰのプロトコルで許された範囲内で
行う。これにより従来ユーザ反応時間の多くの部分を占
めていたヴァリデーション動作による消費時間をユーザ
反応時間から取り除くことができ、第３の課題が解決さ
れる。

【００２６】

【発明の実施の形態】以下、本発明の実施の一形態を図
面を参照しながら説明する。簡単のため「発明の実施の
形態」を「実施例」と呼ぶ。

【００２７】図１と図２を用いて実施例の構成を説明す
る。

【００２８】外部サーバ１３、１３’、１３”、…は、
情報システムが提供する情報を保持し、要求に応じてク
ライアント１１またはサーバ１０、１０’、１０”、…
に情報を提供する計算機である。サーバ１０、１０’、
１０”、…は情報システムのキャッシュを保持するサー
バである。クライアント１１はユーザが利用する計算機
で、ネットワーク１２を通じて外部サーバ１３、１
３’、１３”、…またはサーバ１０、１０’、１０”、
…から提供された情報をユーザに表示する。サーバ１
０、１０’、１０”、…は外部サーバ１３、１３’、１
３”、…の中で、最近クライアント１１が利用した情報
や、クライアント１１が今後利用すると予想される情報
をキャッシュとして保持する。このキャッシュの目的に
はいくつか考えうるが、代表的な目的はクライアント１
１が情報を得るのに要する時間を高速化することであ
る。クライアント１１が外部サーバ１３、１３’、１
３”、…の代わりにサーバ１０、１０’、１０”、…に
アクセスすることにより、外部サーバ１３、１３’、１
３”、…がネットワーク１２の遠くにある場合でも高速
に情報にアクセスできる。

【００２９】この実施例の計算機は、いわゆるパーソナ
ル・コンピュータ、ワークステーション、並列計算機、
大型計算機等、任意のコンピュータでよい。クライアン
ト１１はサーバ１０、１０’、１０”、…と通信し、情
報を表示する機能があればよいので、各種コンピュータ
端末装置、携帯通信端末（いわゆるパーソナル・デジタ
ル・アシスタンスＰＤＡやハンドヘルド・パーソナル・
コンピュータＨＰＣ）、ネットワーク・コンピュータな
どでも差し支えない。

【００３０】外部サーバ１３、１３’、１３”、…、ク
ライアント１１、サーバ１０、１０’、１０”、…は計
算機ではなく、計算機とソフトウェアの組合わせで実現
しても差し支えない。特に、計算機自身には変更を加え
ず、計算機上で動作するプログラム（プロセス）によっ
て、本発明を実施しても差し支えない。

【００３１】ネットワーク１２は、ある団体（企業や学
校や類似の団体）の全体や位置部門でよく使用されるＬ
ＡＮでもよく、また地理的に分散した複数の地点を結合
するＷＡＮの一部または全部でもよい。またネットワー
ク１２は、計算機間結合網や並列計算機内部のプロセッ
サ要素間の結合網でもよい。

【００３２】サーバ１０はクライアント要求処理部１０
０、キャッシュ管理部１０１、サーバ管理部１０２、通
信部１０６の各処理部分を含み、キャッシュ表１０７、
キャッシュ・ディレクトリ１０８、サーバ状態表１０
９、グループ表１１０の各データ構造を含む。また、キ
ャッシュ管理部１０１は更にキャッシュ価値評価部１０
４とキャッシュ移動破棄部１０５の各処理部分を含む。
また、サーバ１０、１０’、１０”、…はそれぞれ一意
な番号であるサーバＩＤ（または単にＩＤ）を持つ。サ
ーバＩＤとしては、サーバＩＤからサーバの通信用アド
レスを対応づけ、通信を行うことができるＩＤを用い
る。例えば、ＩＰアドレスをサーバＩＤとして用いても
差し支えない。

【００３３】クライアント要求処理部１００は、クライ
アント１１が情報の取得を要求した際に、応対を行う部
分である。クライアント要求処理部１００からのメッセ
ージ送信は通信部１０６を経由して（１２７）、ネット
ワーク１２に送出される。逆にネットワーク１２からク
ライアント要求処理部１００へのメッセージは、通信部
１０６を経由してクライアント要求処理部１００に送ら
れる（１２６）。クライアント要求処理部１００はキャ
ッシュ表１０７に対する読み出し（１４６）を行う。キ
ャッシュ表１０７に対する書き込み（１４７）を行う場
合もあるが、稀である。

【００３４】キャッシュ管理部１０１は、サーバ１０が
保持するキャッシュを管理する部分である。キャッシュ
管理部１０１は、通信部１０６を経由してネットワーク
１２へのメッセージの受信と送信を行う（１２８と１２
９）。またキャッシュ管理部１０１はキャッシュ表１０
７に対する書き込みと読み込み（１３４と１３５）、キ
ャッシュ・ディレクトリ１０８に対する書き込みと読み
込み（１３６と１３７）、およびサーバ状態表１０９に
対する書き込みと読み込み（１３８と１３９）を行う。
キャッシュ管理部１０１中のキャッシュ価値評価部１０
４は、特定の情報のキャッシュを保持することがどのく
らい有用かを判定する部分である。またキャッシュ管理
部１０１中のキャッシュ移動破棄部１０５は、ある情報
のキャッシュをサーバ１０に置いておくべきでない場合
に、当該キャッシュを破棄したり、１つ以上の他のサー
バ１０’、１０”、…に当該キャッシュを移動する部分
である。

【００３５】サーバ管理部１０２は、他のサーバ１
０’、１０”、…をリストアップし、これらのサーバの
動作状況を管理する部分である。サーバ管理部１０２
は、通信部１０６を経由してネットワーク１２へのメッ
セージの受信と送信を行う（１３０と１３１）。またサ
ーバ管理部１０２はサーバ状態表１０９に対する書き込
みと読み込み（１４０と１４１）、およびグループ表１
１０に対する書き込みと読み込み（１４２と１４３）を
行う。

【００３６】ヴァリデーション管理部１０３は、先行ヴ
ァリデーションの制御を行う部分である。ヴァリデーシ
ョン管理部１０３は、通信部１０６を経由してネットワ
ーク１２へのメッセージの受信と送信を行う（１３２と
１３３）。ヴァリデーション管理部１０３はキャッシュ
表１０７に対する書き込みと読み込み（１４４と１４
５）を行う。

【００３７】通信部１０６は、クライアント１１、他の
サーバ１０’、１０”、…、外部サーバ１３、１３’、
１３”、…と通信を行う部分である。クライアント１１
からの受信と送信は１２０と１２１による。他のサーバ
１０’、１０”、…からの受信と送信は１２２と１２３
による。外部サーバ１３、１３’、１３”、…からの受
信と送信は１２４と１２５による。

【００３８】キャッシュ表１０７は、サーバ１０のキャ
ッシュの実体およびキャッシュの各種属性を保持する表
である。キャッシュ表１０７は１つ以上のキャッシュ表
エントリ２００からなる。１つのキャッシュ表エントリ
２００は１つの情報の１つのキャッシュに対応してお
り、ＵＲＬ２０１が当該情報のＵＲＬを保持し、サイズ
２０２が当該情報のバイト数を保持し、日付２０３が当
該情報の最終更新日付を保持し、参照回数２０４が当該
情報の最近の参照回数を保持する。キャッシュ内容２０
５は当該情報のコピーを保持する。

【００３９】キャッシュ・ディレクトリ１０８は、サー
バ１０、１０’、１０”、…のどれが、どの情報のキャ
ッシュを持っているかという情報を保持する表である。
キャッシュ・ディレクトリ１０８は１つ以上のキャッシ
ュ・ディレクトリ・エントリ２１０からなる。１つのキ
ャッシュ・ディレクトリ・エントリ２１０が、１つの別
のサーバが持つ１つの情報に対応しており、ＵＲＬ２１
１が当該情報のＵＲＬを、サーバＩＤ２１２が当該サー
バのサーバＩＤを保持する。

【００４０】サーバ状態表１０９は、サーバ１０、１
０’、１０”、…のうちいくつかのＩＤと動作状態等の
属性とを保持する表である。サーバ状態表１０９は１つ
以上のサーバ状態表エントリ２２０からなる。１つのサ
ーバ状態表１０９が１つのサーバに対応しており、サー
バＩＤ２２１が当該サーバのサーバＩＤを保持し、スル
ープット２２２が当該サーバへ至る通信回線のスループ
ット（ビット／秒）、レイテンシ２２３が当該サーバへ
至る通信回線のレイテンシ（秒）を保持する。サーバ状
態表１０９にあるサーバのエントリがないか、スループ
ット２２２が０であるか、レイテンシ２２３が「無限
大」であれば、当該サーバが動作中でないか、当該サー
バへ至る通信回線に障害が発生していることを意味す
る。

【００４１】グループ表１１０は、サーバ状態表１０９
に格納されているサーバ群のうち、いくつかの近接のサ
ーバ群を選んで保持する表である。１つのグループは最
大ＭＡＸ台（ＭＡＸは定数）のサーバ（メンバ）からな
る。各グループのサーバ群は、サーバＩＤによってグル
ープ内で順序づけされる。グループ内で最も若いサーバ
ＩＤを持つサーバを「リーダ」と呼ぶ。リーダは、１つ
上のグループ（上位グループ）の一員となることがで
き、グループ間でマルチキャスト通信を行う際には、そ
の通信の中継役となる。もしリーダに障害が発生した場
合には、リーダの次に若いサーバＩＤを持つサーバが代
行リーダとなる。この構造を表現するためにグループ表
１１０は、リーダのサーバＩＤを保持するリーダ・サー
バＩＤ２３１、メンバのサーバＩＤを保持するサーバＩ
Ｄ２３２、２３２’、…、上位グループのリーダを保持
する上位リーダ・サーバＩＤ２３３、上位グループの
メンバのサーバＩＤを保持する上位サーバＩＤ２３
４、２３４’、…からなる。

【００４２】次に、図３を用いて、サーバ１０、１
０’、１０”、…が相互に通信する際に用いるメッセー
ジの種類と、その形式を説明する。

【００４３】グループ参加メッセージ３００は、新たに
グループに参加しようとするサーバが発するメッセージ
である。１つのサーバがグループに参加しようとする場
合と、複数のサーバがグループに参加（または変更）し
ようとする場合の両方に用いる。グループ参加メッセー
ジ３００は新規サーバＩＤ３０１、３０１’、…を格
納しており、それぞれが新たにグループに参加しようと
するサーバ群のＩＤである。

【００４４】階層維持メッセージ３１０は、グループの
メンバの動作状況を確認するために用いるメッセージで
ある。通常、あるグループのリーダが発し、当該グルー
プおよび他のいくつかのグループの動作中のメンバの間
を回覧されて、再びリーダに戻る。階層維持メッセージ
３１０は、当該メッセージを最初に発したサーバのＩＤ
である送信元サーバＩＤ３１１と、動作中のサーバ群の
ＩＤである新規サーバＩＤ３１２、３１２’、…と、ネ
スト数３１３からなる。ネスト数３１３は、複数のグル
ープに跨って１つの階層維持メッセージ３１０を回覧す
る際に用い、何段先のグループまで階層維持メッセージ
３１０を回覧するかを指定する。

【００４５】グループ更新メッセージ３２０は、グルー
プに参加することが許可されたサーバに（通常リーダか
ら）送られるメッセージである。グループ更新メッセー
ジ３２０は、参加すべきグループのリーダのＩＤである
新リーダ・サーバＩＤ３２１を格納する。

【００４６】ヴァリデーション依頼メッセージ３３０
は、先行ヴァリデーションを行う時に、先行ヴァリデー
ションを依頼するサーバから、先行ヴァリデーションの
依頼を受けるサーバに送られるメッセージで、先行ヴァ
リデーションの対象となる１つ以上のＵＲＬを持つ。ヴ
ァリデーション依頼メッセージ３３０は１つ以上のヴァ
リデーション依頼メッセージ・エントリ３３１からな
り、各エントリは依頼元サーバのＩＤであるサーバＩＤ
３３２、先行ヴァリデーションの対象となるＵＲＬであ
るＵＲＬ３３３、依頼元サーバが知っているＵＲＬの最
終更新日付である日付３３４を格納する。

【００４７】キャッシュ価値メッセージ３４０は、サー
バ同士が各自のキャッシュ全体のキャッシュ価値の指標
を交換し合うために用いるメッセージである。キャッシ
ュ価値メッセージ３４０は１つ以上のキャッシュ価値メ
ッセージ・エントリ３４１からなり、各エントリはサー
バを指定するサーバＩＤ３４２と、当該サーバのキャッ
シュ価値の指標であるキャッシュ価値３４３を含む。

【００４８】移動予告メッセージ３５０は、第１のサー
バが、キャッシュの中で（一般にはキャッシュ価値の低
い）１つ以上の情報を第２のサーバに移動させる予定で
あることを、他の複数のサーバに知らせる際に用いる。
移動予告メッセージ３５０は１つ以上の移動予告メッセ
ージ・エントリ３５１からなり、移動予告メッセージ・
エントリ３５１は第１のサーバのＩＤであるサーバＩＤ
３５２、当該情報のＵＲＬであるＵＲＬ３５３、および
第２のサーバのＩＤである移動先サーバＩＤ３５４を格
納する。

【００４９】破棄予告メッセージ３６０は、第１のサー
バが、キャッシュの中で（一般にはキャッシュ価値の低
い）１つ以上の情報を破棄する予定であることを、他の
複数のサーバに知らせる際に用いる。破棄予告メッセー
ジ３６０は１つ以上の破棄予告メッセージ・エントリ３
６１からなり、各エントリは第１のサーバのＩＤである
サーバＩＤ３６２と、当該情報のＵＲＬであるＵＲＬ３
５３を格納する。

【００５０】ホストＵＲＬメッセージ３７０は、サーバ
同士が各自のキャッシュにどのような情報が格納されて
いるかを交換し合うために用いるメッセージである。ホ
ストＵＲＬメッセージ３７０は１つ以上のホストＵＲＬ
メッセージ・エントリ３７１からなり、各エントリはキ
ャッシュを持つサーバのＩＤであるサーバＩＤ３７２、
１つの情報のＵＲＬであるＵＲＬ３７３、および当該Ｕ
ＲＬが存在するか存在しないかを示すフラグ３７４を格
納する。

【００５１】サーバ状態伝播本発明の情報システム分散管理方法では、サーバ動作情
報（動作しているサーバのリスト）を分散管理するため
の「サーバ状態伝播プロトコル」を持つ。以下、このプ
ロトコルの動作を説明する。

【００５２】（１）階層形成処理まず図４を用いて、主にサーバ初期化時に行う階層形成
処理を説明する。以下の処理手順の説明では、説明をわ
かりやすくするために動作の骨子に絞って説明を行う。
すなわち、エラー処理やタイミング依存の動作等は省略
する。

【００５３】管理者は、０個または１つ以上の他のサー
バのサーバＩＤを与えて、サーバ１０を起動する。サー
バ１０が起動されるとすべての表を「空」に初期化した
後サーバ管理部１０２に制御を移し、与えられたサーバ
ＩＤをサーバ状態表１０９に格納してから、他のサーバ
１０’、１０”、…の動作状態を調べ、他のサーバ１
０’、１０”、…をより多く取得し、１つのグループに
参加する動作を行う。

【００５４】ステップ４０１で、サーバ状態表１０９が
空であるかを判定する。判定結果がＹ（ＹＥＳの略）で
あれば（４０２）、他のサーバが一切わからないので、
ステップ４０３で、サーバ状態表１０９に新たなサーバ
状態表エントリ２２０を追加し、当該エントリのサーバ
ＩＤ２２１に自分のＩＤを、スループット２２２に「無
限大」を、レイテンシ２２３に「０」を格納する。そし
て、階層形成処理を終了する（４１７）。

【００５５】一方、ステップ４０１の判定結果がＮ（Ｎ
Ｏの略）であれば（４０４）、サーバ状態表１０９から
第１のサーバを１つ選択し（ステップ４０５）、第１の
サーバに「グループ表転送」の要求メッセージを送信す
る（ステップ４０６）。ステップ４０６では同時に、第
１のサーバとサーバ１０との通信速度の計測を開始す
る。なお第１のサーバが「グループ表転送」の要求メッ
セージを受け取ると、第１のサーバのグループ表１１０
をメッセージに詰め、返答としてサーバ１０に送る。続
くステップ４０７で、第１のサーバが返答として返した
グループ表を受信し、同時に通信速度の計測を終了す
る。

【００５６】ステップ４０８では、サーバ状態表１０９
に計測した通信速度を反映させるとともに、受け取った
第１のサーバのグループ表を自サーバのサーバ状態表１
０９に反映させる。具体的には、サーバ状態表エントリ
２２０でサーバＩＤ２２１が第１のサーバのＩＤに等し
いエントリを探し、当該エントリのスループット２２２
とレイテンシ２２３を計測した通信速度を用いて更新す
る。更新の方法には、平均をとる、置き換えるなどいく
つか考えられるが、本実施例では置き換える方法をと
る。次に、受け取った第１のサーバのグループ表に含ま
れるリーダ・サーバＩＤ、サーバＩＤ、上位リーダ・サ
ーバＩＤ、上位サーバＩＤのうち、サーバ状態表１０９
に対応するサーバ状態表エントリ２２０がないサーバの
ＩＤの各々について、新たなサーバ状態表エントリ２２
０を追加し、サーバＩＤ２２１に当該サーバのＩＤを、
スループット２２２に「０」を、レイテンシ２２３に
「無限大」を格納する。これにより、第１のサーバに近
接のサーバ群がいくつか、サーバ状態表１０９に追加さ
れる。

【００５７】ステップ４０９では、上記ステップ４０５
から４０８をＮ回（Ｎは定数）繰り返したかどうかを判
定する。判定がＮなら（４１０）、ステップ４０５に戻
る。判定がＹなら（４１１）、ステップ４１２に移る。
ステップ４１２では、サーバ状態表に格納されたサーバ
群のうち、最も近接のサーバ（例えばスループット２２
２をレイテンシ２２３で割った値が最大のサーバ）に対
してグループ参加メッセージ３００を送る。この際新規
サーバＩＤ３０１には自分のサーバＩＤを格納する。ス
テップ４１３で、当該グループ参加メッセージ３００に
対する返答であるグループ更新メッセージ３２０を受信
すると、ステップ４１４でグループ更新メッセージ３２
０の新リーダ・サーバＩＤ３２１に対応するリーダに向
けて、「グループ表転送」の要求メッセージを送信する
（ステップ４１５）。リーダは「グループ表転送」の要
求メッセージを受け取ると、リーダのグループ表１１０
をメッセージに詰め、返答としてサーバ１０に送る。続
くステップ４０７で、第１のサーバが返答として返した
グループ表を受信し、さらにステップ４１６で、受け取
ったグループ表を自サーバのグループ表１１０に反映さ
せる。

【００５８】以上が階層形成処理の手順である。なお、
グループ更新メッセージ３２０がこの手順以外に受信さ
れる場合もありうる。この場合、当該グループ更新メッ
セージ３２０の新リーダ・サーバＩＤ３２１を用いて、
ステップ４１４、４１５、４１６の処理を行う。

【００５９】（２）グループ参加要求処理次にグループ参加メッセージ３００を受信した場合の処
理を、５を用いて説明する。

【００６０】サーバ１０がグループ参加メッセージ３０
０を受け取ると、ステップ５０１で自分がリーダがどう
かを判定する。具体的には、グループ表１１０のリーダ
・サーバＩＤ２３１が「空」であるか、自分のサーバＩ
Ｄが格納されているならば、リーダである。ステップ５
０１の判定がＮなら（５０２）、ステップ５０３でリー
ダ（グループ表１１０のリーダ・サーバＩＤ２３１に格
納されているサーバＩＤ）に現在処理中のグループ参加
メッセージ３００を転送し、グループ参加要求処理を終
了する（５０４）。

【００６１】一方ステップ５０１の判定がＹなら（５０
５）、グループのメンバ数がどのように変化するかによ
ってどのようにグループを構成するかを決定する。まず
現在グループに参加しているメンバの数（グループ表１
１０のサーバＩＤ２３２、２３２’、…の数）を調べ
「旧メンバ数」とする。そして、グループ参加メッセー
ジ３００に含まれるサーバの数（新規サーバＩＤ３０
１、３０１’、…の数）を「新メンバ数」とする。ステ
ップ５０６では、旧メンバ数と新メンバ数の和が前記Ｍ
ＡＸ未満かどうかを調べる。この判定がＹなら（５０
７）、ステップ５０８で、グループ参加メッセージ３０
０に含まれる新規サーバＩＤ３０１、３０１’、…を
グループ表１１０のサーバＩＤ２３２、２３２’、…
に追加する。ステップ５０９でグループ更新メッセージ
３２０の新リーダ・サーバＩＤ３２１にサーバ１０のサ
ーバＩＤを格納し、当該メッセージをグループ参加メッ
セージ３００の新規サーバＩＤ３０１、３０１’、…
に対応するサーバ群に返答する。そして、グループ参加
要求処理を終了する（５１０）。

【００６２】一方、ステップ５０６の判定がＮなら（５
１１）、ステップ５１２で旧メンバ数を１増加してもＭ
ＡＸ未満かどうかを調べる。この判定がＹなら（５１
３）、５１４で、グループ参加メッセージ３００の新規
サーバＩＤ３０１をグループ表１１０のサーバＩＤ
２３２、２３２’、…に追加する。そしてステップ５１
５で新規サーバＩＤ３０１には新リーダ・サーバＩＤ３
２１にサーバ１０のサーバＩＤを格納したグループ更新
メッセージ３２０を送信し、新規サーバＩＤ３０
１’、３０１”、…には新リーダ・サーバＩＤ３２１に
新規サーバＩＤ３０１を格納したグループ更新メッセー
ジ３２０を送信する。そして、グループ参加要求処理を
終了する（５１６）。

【００６３】一方、ステップ５１２の判定がＮなら（５
１７）、ステップ５１８で新グループを作成する。この
新グループのメンバは、サーバ１０と新規サーバＩＤ３
０１のサーバ、およびサーバＩＤ２３２のサーバであ
る。現在のグループのリーダはサーバＩＤ２３２に譲
る。具体的には、現在のグループを、サーバＩＤ２３２
をリーダとしたグループとするために、サーバＩＤ２
３２、２３２’、…に対し、新リーダ・サーバＩＤ３２
１にサーバＩＤ２３２を格納したグループ更新メッセー
ジ３２０を送信する。サーバＩＤ２３２のサーバはこれ
によってリーダになり、かつ既にのべた動作によって、
上位リーダをサーバ１０に設定する。次に新グループを
形成するため、グループ表１１０のサーバＩＤ２３
２、２３２’、…に、新規サーバＩＤ３０１とサーバＩ
Ｄ２３２を格納する。続くステップ５１９で、新規サー
バＩＤ３０１には新リーダ・サーバＩＤ３２１にサーバ
１０のサーバＩＤを格納したグループ更新メッセージ３
２０を送信し、新規サーバＩＤ３０１’、３０１”、…
には新リーダ・サーバＩＤ３２１に新規サーバＩＤ３０
１を格納したグループ更新メッセージ３２０を送信す
る。

【００６４】以上がグループ参加要求処理である。以上
の動作によって、各グループの最大数をＭＡＸ以下に保
ちながら、サーバの動的な増加に対応して階層化して行
くことが可能となる。

【００６５】（３）階層維持メッセージ受信処理サーバ１０がリーダの場合、タイマー等を用いて定期的
に階層維持メッセージ３１０を発行する。階層維持メッ
セージは、サーバ１０が属するグループのメンバの他、
上下Ｋ段（Ｋは階層維持メッセージ受信処理開始時の引
数）のグループ階層を伝って回覧され、再びサーバ１０
に戻る。この動作を実現する処理の手順を図６を用いて
説明する。階層維持メッセージ３１０に対し各メンバ
は、自分が動作中であるというデータを付加して次のメ
ンバに送る。もし次のメンバとの通信ができなければ、
その次のメンバを試みる。この動作の結末は、（１）動
作中のメンバ全員を回って階層維持メッセージ３１０が
リーダに返る、（２）階層維持メッセージ３１０を保持
中のメンバが障害を起して階層維持メッセージ３１０、
（３）リーダが障害を起し、最終送信先がなくなる、の
いずれかとなる。以下のプロトコルでは代行リーダとタ
イムアウトの使用により、（１）、（２）、（３）のい
ずれにも対処できる。

【００６６】サーバ１０が階層維持メッセージ３１０を
受け取ると、まずステップ６０１で送信元サーバＩＤ３
１１が自分のＩＤと等しいかどうかを判定する。判定が
Ｙなら（６０２）、階層維持メッセージ受信処理は終了
である。

【００６７】一方ステップ６０１の判定がＮなら（６０
３）、ステップ６０４で階層維持メッセージ３１０に自
分のサーバＩＤを新規サーバＩＤ３１２、３１２’、…
に追加する。

【００６８】なおこの時、すでに新規サーバＩＤ３１
２、３１２’、…に自分のサーバＩＤが含まれている場
合、同じ階層維持メッセージ３１０が２度回ってきたこ
とを意味する。この場合、リーダが受け取るべきメッセ
ージを受け取れなかったために、自分が代行リーダにな
ったことを意味する。この場合で、階層維持メッセージ
３１０がグループ表１１０の上位サーバＩＤ２３４、
２３４’、…のいずれかから送られた場合には上位グル
ープのリーダになるため、上位サーバＩＤ２３４、２
３４’、…のサーバ群に対して、新リーダ・サーバＩＤ
３２１に自分のサーバＩＤを格納したグループ更新メッ
セージ３２０を送信する。また、階層維持メッセージ３
１０がグループ表１１０のサーバＩＤ２３２、２３
２’、…のいずれかから贈られた場合にはグループのリ
ーダになるため、サーバＩＤ２３２、２３２’、…の
サーバ群に対して、新リーダ・サーバＩＤ３２１に自分
のサーバＩＤを格納したグループ更新メッセージ３２０
を送信する。

【００６９】続いて、自分がリーダで、かつネスト数３
１３が１に等しいかを判定する（ステップ６０５）。判
定がＹなら（６０６）、ステップ６０６で階層維持メッ
セージ３１０にグループ表１１０のサーバＩＤ２３
２、２３２’、…を新規サーバＩＤ３１２、３１２’、
…に追加し、ステップ６１０に進む（６０８）。また、
ステップ６０５の判定がＮなら、ここでは何もしない
（６０９）。

【００７０】続いて、自分がリーダで、かつネスト数３
１３が２以上かを判定する（ステップ６１０）。判定が
Ｙなら（６１１）、ステップ６１２で送信元サーバＩＤ
３１１をサーバ１０のＩＤに変更してネスト数３１３を
１減じ、ステップ６１３でメンバの１つに階層維持メッ
セージ３１０を送信する。具体的には、グループ表１１
０のサーバＩＤ２３２、２３２’、…を上から走査し
ていき、階層維持メッセージ３１０の送信がうまくいく
まで試みる。ステップ６１４でメンバから階層維持メッ
セージ３１０が戻ってきたら、階層維持メッセージ３１
０の送信元サーバＩＤ３１１を元に戻し、次の処理に進
む（６１５）。

【００７１】なお、ステップ６１３とステップ６１４の
間で回覧される送信元サーバＩＤ３１１が、メンバの障
害やネットワーク１２の障害によって、失われる可能性
もある。この際、サーバ１０はタイムアウトによりステ
ップ６１４の受信をあきらめ、次の処理に進む（６１
５）。

【００７２】次に、ステップ６１７で、階層維持メッセ
ージ３１０が上位メンバから受け取ったものかを判定す
る。判定がＹなら（６１８）、当該階層維持メッセージ
３１０は上位メンバを回覧されているので、送信先も上
位メンバから選択するのが良い。具体的にはステップ６
１９で、グループ表１１０の上位サーバＩＤ２３４、
２３４’、…のうちサーバ１０のＩＤが格納されている
エントリを探す。もしこの条件に合うエントリがあり、
そのエントリの次のエントリのサーバがあれば、当該サ
ーバに階層維持メッセージ３１０の送信を試みる。もし
当該サーバへの送信が失敗した場合（すなわち当該サー
バの障害かネットワーク１２の障害の場合）、さらに次
のエントリ、その次のエントリ、…を試みる。もし最後
のエントリも試したら、上位リーダ・サーバＩＤ２３
３を試みる。これを上位リーダ・サーバＩＤ２３３お
よび上位サーバＩＤ２３４をすべて試みるまで続け、も
しどこにも送信できなければ送信をあきらめる。次にス
テップ６２２に進む（６２０）。また、ステップ６１７
の判定がＮなら（６２１）、ステップ６２２に進む。

【００７３】ステップ６２２では、階層維持メッセージ
３１０がメンバから受け取ったものかを判定する。判定
がＹなら（６２３）、当該階層維持メッセージ３１０は
メンバを回覧されているので、送信先もメンバから選択
するのが良い。具体的にはステップ６２４で、グループ
表１１０のサーバＩＤ２３２、２３２’、…のうちサ
ーバ１０のＩＤが格納されているエントリを探す。もし
この条件に合うエントリがあり、そのエントリの次のエ
ントリのサーバがあれば、当該サーバに階層維持メッセ
ージ３１０の送信を試みる。もし当該サーバへの送信が
失敗した場合（すなわち当該サーバの障害かネットワー
ク１２の障害の場合）、さらに次のエントリ、その次の
エントリ、…を試みる。もし最後のエントリも試した
ら、リーダ・サーバＩＤ２３１を試みる。これをリーダ
・サーバＩＤ２３１およびサーバＩＤ２３２をすべて試
みるまで続け、もしどこにも送信できなければ送信をあ
きらめ（６２６）、階層維持メッセージ受信処理を終了
する。また、ステップ６２２の判定がＮなら（６２
６）、そのまま階層維持メッセージ受信処理を終了す
る。

【００７４】以上が階層維持メッセージの処理の手順で
ある。階層維持メッセージの受信処理が終了してから、
サーバ１０は階層維持メッセージ３１０の新規サーバＩ
Ｄ３１２をサーバ状態表１０９に反映する。すなわち、
サーバ状態表１０９に対応するサーバ状態表エントリ２
２０がないサーバのＩＤの各々について、新たなサーバ
状態表エントリ２２０を追加し、サーバＩＤ２２１に当
該サーバのＩＤを、スループット２２２に「０」を、レ
イテンシ２２３に「無限大」を格納する。これにより、
第１のサーバに近接のサーバ群がいくつか、サーバ状態
表１０９に追加される。

【００７５】階層維持メッセージ３１０のうちネスト数
３１３が０のメッセージは、特にグループ内のサーバの
活動状態を調べ、メンバに伝播するのに用いる。この場
合、リーダが階層維持メッセージ３１０を送信して、動
作中のメンバを一周してリーダに戻る。この後、同じメ
ッセージにネスト数３１３に「―１」を格納してメンバ
に回覧する。ネスト数３１３が―１の階層維持メッセー
ジ３１０を受け取ったら、サーバは階層維持メッセージ
３１０の新規サーバＩＤ３１２、３１２’、…をサーバ
ＩＤ２３２、２３２’、…に格納して、次のメンバに
同じメッセージを渡す。この手順により、メンバの活動
状態がグループ全体に伝播する。

【００７６】（４）階層再構成処理あるグループのサーバ数が一定数以下になった場合、グ
ループを再構成する。この手順を図７を用いて説明す
る。

【００７７】サーバ１０がリーダの場合、グループ表１
１０が変化する度に階層再構成処理を起動する。ステッ
プ７０１で、グループ表１１０のサーバＩＤ２３２、
２３２’、…の数がＭＩＮ以下（ＭＩＮは定数）かつ、
上位リーダ・サーバＩＤ２３３が「空」でなく、かつ
上位リーダ・サーバＩＤ２３３が自分のサーバＩＤ以
外であるかを判定する。この判定がＮなら（７０２）、
階層再構成処理を終了する。

【００７８】一方、ステップ７０１の判定がＹなら（７
０３）、上位リーダ・サーバＩＤ２３３に対応するサー
バに、グループ参加メッセージ３００を送る。この際の
新規サーバＩＤ３０１、３０１’、…には、自分のサ
ーバＩＤおよびグループ表１１０のサーバＩＤ２３
２、２３２’、…を格納する。

【００７９】これにより、既に説明したグループ参加要
求処理が上位グループで起動され、サーバ１０の属する
グループは再構成されて、通常別のグループに吸収され
る。

【００８０】以上（１）から（４）の各処理によって実
現されるサーバ状態伝播プロトコルによって、以下の特
長が得られる。相互支援によってマルチキャスト階層を
動的に構築することによって、他サーバの動作状況の変
化および通信速度の変化を、集中サーバを必要とせずに
把握すること。伝播するサーバ情報を一定数以下の近接
サーバの情報と遠隔サーバの情報に絞り、伝播先をマル
チキャスト階層の構造にしたがって一定数以下にするこ
とによって、サーバが多数になっても、管理のための通
信が爆発しないこと。マルチキャスト階層再構築によっ
て、システム動作中の動的なサーバの参加・脱退に対応
することと、一部サーバまたはネットワークの障害時に
対処すること。管理者が与える設定を、サーバ起動時に
最初に通信する少数のサーバのみに絞り、管理者の設定
が簡単にすること。

【００８１】広域協調キャッシュ管理本発明の情報システム分散管理方法では、「広域協調キ
ャッシュ管理プロトコル」を備える。このプロトコル
は、前記サーバ状態伝播プロトコルが形成するマルチキ
ャスト階層を用いてキャッシュ・ディレクトリの伝播
と、キャッシュ制御（どのサーバがどのＵＲＬをキャッ
シュ中に保持するか、いつ、どのＵＲＬをあるサーバか
ら別のサーバに移動させるか）を集中管理サーバなしで
行う。

【００８２】（１）キャッシュの検索とキャッシュ・デ
ィレクトリの伝播サーバ１０が、クライアント１１が発した第１のＵＲＬ
の情報に対する要求を受け付けると、クライアント要求
処理部１００がこの要求を処理する。クライアント要求
処理部１００は、キャッシュ表１０７を第１のＵＲＬを
用いて検索し、ＵＲＬ２０１が第１のＵＲＬに等しいキ
ャッシュ表エントリ２００があればキャッシュ内容２０
５をクライアント１１に返し、参照回数２０４を１増加
させる。このようなエントリがなければ、キャッシュ管
理部１０１に制御を移す。

【００８３】キャッシュ管理部１０１では、キャッシュ
・ディレクトリ１０８を第１のＵＲＬを用いて検索し他
のサーバ１０’、１０”、…が第１のＵＲＬの情報を保
持していないかを調べる。すなわち、ＵＲＬ２１１が第
１のＵＲＬに等しいキャッシュ・ディレクトリ・エント
リ２１０があれば、当該キャッシュ・ディレクトリ・エ
ントリ２１０のサーバＩＤ２１２に対応するサーバにク
ライアント１１の要求を転送する。もしこのようなエン
トリがなければ、第１のＵＲＬを処理可能な外部サーバ
１３、１３’、１３”、…にクライアント１１の要求を
送信する。

【００８４】他のサーバ１０’、１０”、…と外部サー
バ１３、１３’、１３”、…に送信した要求の返答は、
ＨＴＴＰのプロトコルで返される。このプロトコルの詳
細は省略するが、情報の内容、サイズ、最終更新日付が
付加されるのが普通である。この返答を受け取ったキャ
ッシュ管理部１０１は、キャッシュ表１０７に新たなキ
ャッシュ表エントリ２００を作り、該エントリのＵＲＬ
２０１に第１のＵＲＬを、サイズ２０２にサイズを、日
付２０３に最終更新日付を、参照回数２０４に０を、キ
ャッシュ内容２０５に情報の内容を格納する。

【００８５】グループのキャッシュ・ディレクトリ１０
８を更新するために、新たな情報を入手したサーバ１０
は、グループのメンバに対してホストＵＲＬメッセージ
３７０を送る。ホストＵＲＬメッセージ３７０のサーバ
ＩＤ３７２はサーバ１０のＩＤを、ＵＲＬ３７３は当該
情報のＵＲＬを、フラグ３７４は「存在」を保持する。

【００８６】（２）キャッシュ価値回覧処理本発明では、サーバ１０、１０’、１０”、…がキャッ
シュされた情報のキャッシュ価値を「キャッシュ価値=
（参照回数）×（予測再入手時間）／（情報のサイ
ズ）」の式で評価する。予測再入手時間は、外部サーバ
１３、１３’、１３”、…と他のサーバ１０’、１
０”、…から入手する時間を予測する。他のサーバ１
０’、１０”、…との予測際入手時間の予測には、サー
バ状態表１０９のスループット２２２とレイテンシ２２
３を用いる。外部サーバ１３、１３’、１３”、…を用
いた予測再入手時間は、スループットとレイテンシとも
に一律な定数を用いる。

【００８７】サーバ１０、１０’、１０”、…は、キャ
ッシュに保持している各情報のキャッシュ価値を計算
し、情報を順序付けする。この順序に従って、必要に応
じて情報をキャッシュから破棄したり、他のサーバ１
０’、１０”、…へ移動する。

【００８８】サーバ１０が第１の情報を他のサーバ１
０’、１０”、…の１つに移動させる場合には、移動先
サーバを決定する必要がある。この目的でサーバ１０、
１０’、１０”、…は、自分が受け入れ可能なキャッシ
ュ価値の最小値（受け入れ可能キャッシュ価値と呼ぶ）
を他サーバに回覧する。受け入れ可能キャッシュ価値に
は、例えば、キャッシュされている情報のうち、最下位
から数えてＭ番目（Ｍは適当な定数）のキャッシュ価値
を用いる。この受け入れ可能キャッシュ価値を用いて、
各サーバは移動先サーバを選択する。

【００８９】受け入れ可能キャッシュ価値回覧処理の手
順を、図８を用いて説明する。

【００９０】リーダのキャッシュ価値評価部１０４は、
一定時間毎にキャッシュ価値回覧処理を起動する。また
リーダ以外のキャッシュ価値評価部１０４は、キャッシ
ュ価値メッセージ３４０を受け取った時点でキャッシュ
価値回覧処理を行う。キャッシュ価値回覧処理を開始す
ると、ステップ８０１で自分がリーダであるかどうかを
判定する。

【００９１】ステップ８０１の判定がＹの場合（８０
２）、ステップ８０３で上記の要領で自分の回覧すべき
受け入れ可能キャッシュ価値を計算する。次に、新たな
キャッシュ価値メッセージ３４０を作成し、新たなキャ
ッシュ価値メッセージ・エントリ３４１を作り、当該エ
ントリのサーバＩＤ３４２に自分のサーバＩＤを、キャ
ッシュ価値３４３に計算した受け入れ可能キャッシュ価
値を格納する。そして、ステップ８０４で作成したキャ
ッシュ価値メッセージ３４０を送信する。送信先は、階
層維持メッセージの回覧と同様、グループ表１１０を用
いて決定する。

【００９２】続くステップ８０５では動作中のメンバを
一周してきたキャッシュ価値メッセージ３４０を受信す
る。そして受け取ったメッセージをもう一周回覧するた
めに、ステップ８０６で再びメンバに受け取ったキャッ
シュ価値メッセージ３４０を送信する。さらにステップ
８０７でキャッシュ価値メッセージ３４０を受信する。
これによって、キャッシュ価値回覧処理の間動作中のメ
ンバは２回キャッシュ価値メッセージ３４０を受け取る
ことになる。

【００９３】一方ステップ８０１の判定がＮの場合（８
０８）、まずステップ８０９でキャッシュ価値メッセー
ジ３４０を受信し、ステップ８１０でキャッシュ価値メ
ッセージ３４０の自分のキャッシュ価値メッセージ・エ
ントリ３４１があるかを判定する。具体的には、受信し
たキャッシュ価値メッセージ３４０のキャッシュ価値メ
ッセージ・エントリ３４１のうち、サーバＩＤ３４２が
自分のサーバＩＤに等しいエントリがあるかを調べる。
この判定がＮの場合（８１１）、ステップ８１２で回覧
すべき受け入れ可能キャッシュ価値を計算し、ステップ
８１３でキャッシュ価値メッセージ３４０に自分のキャ
ッシュ価値メッセージ・エントリ３４１を追加する。す
なわち、新たなキャッシュ価値メッセージ・エントリ３
４１を作り、当該エントリのサーバＩＤ３４２に自分の
サーバＩＤを、キャッシュ価値３４３に計算した受け入
れ可能キャッシュ価値を格納する。そして、ステップ８
１４で次のメンバにキャッシュ価値メッセージ３４０を
送る。送信先は、階層維持メッセージの回覧と同様、グ
ループ表１１０を用いて決定する。

【００９４】また、ステップ８１０の判定がＹの場合
（８１５）、すなわち二周目の回覧の場合、ステップ８
１６で、受信したキャッシュ価値メッセージ３４０をキ
ャッシュ価値評価部１０４の中に保存する。続いてステ
ップ８１４の処理を行い、キャッシュ価値回覧処理を終
了する。

【００９５】（３）移動予告回覧によるキャッシュ移動
集中の回避１つのグループの複数のサーバが一斉に情報の移動を予
定している場合、移動先が１つのサーバに集中する恐れ
がある。この問題を解決するために、各サーバは移動し
ようとする情報および予定移動先のリスト（移動予定リ
ストと呼ぶ）を移動予告メッセージ３５０にのせて回覧
する。これにより各サーバは、他のサーバが選んでいな
い移動先を避けて移動先サーバを決定することができ
る。

【００９６】移動予告回覧処理の手順を、図９を用いて
説明する。

【００９７】リーダのキャッシュ移動破棄部１０５は、
一定時間毎に移動予告回覧処理を起動する。またリーダ
以外のキャッシュ移動破棄部１０５は、移動予告メッセ
ージ３５０を受け取った時点で移動予告回覧処理を行
う。移動予告回覧処理を開始すると、ステップ９０１で
自分がリーダであるかどうかを判定する。

【００９８】ステップ９０１の判定がＹの場合（９０
２）、ステップ９０３で上記の要領で移動予告リストを
作成する。移動予告リストはステップ９０４で移動予告
メッセージ３５０に格納される。すなわち、新たな移動
予告メッセージ３５０を作成し、移動すべき情報毎に新
たな移動予告メッセージ・エントリ３５１を作り、当該
エントリのサーバＩＤ３５２に自分のサーバＩＤを、Ｕ
ＲＬ３５３に移動すべき情報のＵＲＬを、そして移動先
サーバＩＤ３５４に移動先サーバを格納する。そして、
ステップ９０５で作成した移動予告メッセージ３５０を
送信する。送信先は、階層維持メッセージの回覧と同
様、グループ表１１０を用いて決定する。続くステップ
９０６で、移動処理を行う。すなわち、移動すべき情報
のそれぞれに対し、情報を移動すべきサーバに情報をネ
ットワーク１２経由で転送する。

【００９９】一方ステップ９０１の判定がＮの場合（９
０７）、まずステップ９０８で移動予告メッセージ３５
０を受信し、ステップ９０９で移動予告メッセージ３５
０をもとに自分の移動予告リストを更新する。すなわ
ち、もし自分が移動を予定している移動先サーバが、移
動予告メッセージ３５０の上記Ｍ個以上の移動予告メッ
セージ・エントリ３５１の移動先サーバＩＤ３５４に格
納されていれば、別の移動先サーバを選択する。次にス
テップ９１０で、更新した自分の移動予告リストを移動
予告メッセージ３５０に反映する。すなわち、移動すべ
き情報毎に新たな移動予告メッセージ・エントリ３５１
を作り、当該エントリのサーバＩＤ３５２に自分のサー
バＩＤを、ＵＲＬ３５３に移動すべき情報のＵＲＬを、
そして移動先サーバＩＤ３５４に移動先サーバを格納す
る。続くステップ９１１で、作成した移動予告メッセー
ジ３５０を送信する。送信先は、階層維持メッセージの
回覧と同様、グループ表１１０を用いて決定する。続く
ステップ９０６で、移動処理を行う。すなわち、移動す
べき情報のそれぞれに対し、情報を移動すべきサーバに
情報をネットワーク１２経由で転送する。

【０１００】（４）破棄予告回覧によるキャッシュ一斉
破棄の回避近接する複数のサーバが同一情報のキャッシュを保持し
ている場合、このキャッシュのコピーすべてが一斉に破
棄されないように工夫することが必要である。理想的に
は、近接する複数のサーバに対して情報のコピーがただ
１つ存在するのが望ましい。本発明のシステムでは、集
中の管理サーバを用いずに近似的な方法でこの状態に近
づける。このために、破棄しようとする情報のリスト
（破棄予定リストと呼ぶ）をメンバの間で回覧する。自
分が破棄しようとする情報のキャッシュがグループのメ
ンバが保持する最後のコピーである場合には、予定した
破棄を中止する。

【０１０１】破棄予告回覧処理の手順を、図１０を用い
て説明する。

【０１０２】リーダのキャッシュ移動破棄部１０５は、
一定時間毎に破棄予告回覧処理を起動する。またリーダ
以外のキャッシュ移動破棄部１０５は、破棄予告メッセ
ージ３６０を受け取った時点で破棄予告回覧処理を行
う。破棄予告回覧処理を開始すると、ステップ１００１
で自分がリーダであるかどうかを判定する。

【０１０３】ステップ１００１の判定がＹの場合（１０
０２）、ステップ１００３で上記の要領で破棄予告リス
トを作成する。破棄予告リストはステップ１００４で破
棄予告メッセージ３６０に格納され、送信される。すな
わち、新たな破棄予告メッセージ３６０を作成し、破棄
すべき情報毎に新たな破棄予告メッセージ・エントリ３
６１を作り、当該エントリのサーバＩＤ３６２に自分の
サーバＩＤを、ＵＲＬ３６３に破棄すべき情報のＵＲＬ
を格納する。送信先は、階層維持メッセージの回覧と同
様、グループ表１１０を用いて決定する。続くステップ
１００５で、破棄予告メッセージ３６０の受信を行い、
しかる後にステップ１００６で破棄処理を行う。すなわ
ち、破棄すべき情報のそれぞれをキャッシュ表１０７か
ら削除する。この際、グループのキャッシュ・ディレク
トリ１０８を更新するために、サーバ１０はグループの
メンバに対してホストＵＲＬメッセージ３７０を送る。
ホストＵＲＬメッセージ３７０のサーバＩＤ３７２はサ
ーバ１０のＩＤを、ＵＲＬ３７３は当該ＵＲＬ３３３
を、フラグ３７４は「存在しない」を保持する。

【０１０４】一方ステップ１００１の判定がＮの場合
（１００７）、まずステップ１００８で破棄予告メッセ
ージ３６０を受信し、ステップ１００９で破棄予告メッ
セージ３６０とキャッシュ・ディレクトリ１０８をもと
に自分の破棄予告リストを更新する。すなわち、もし自
分が破棄を予定している情報のそれぞれについて、
「（キャッシュ・ディレクトリ１０８に登場する回数）
―（破棄予告メッセージ３６０に登場する回数）」が１
以下であれば、破棄をしないことにし、破棄予定リスト
から取り除く。次にステップ１０１０で、更新した自分
の破棄予告リストを破棄予告メッセージ３６０に反映す
る。すなわち、破棄すべき情報毎に新たな破棄予告メッ
セージ・エントリ３６１を作り、当該エントリのサーバ
ＩＤ３６２に自分のサーバＩＤを、ＵＲＬ３６３に破棄
すべき情報のＵＲＬを格納する。続くステップ１０１１
で、作成した破棄予告メッセージ３６０を送信する。送
信先は、階層維持メッセージの回覧と同様、グループ表
１１０を用いて決定する。続くステップ１００６で、す
でに説明した破棄処理を行う。

【０１０５】先行ヴァリデーションＷＷＷではキャッシュのヴァリデーションに消費する時
間がユーザの反応時間のかなりの部分を占める。そこ
で、定期的にキャッシュされた情報のヴァリデーション
を行っておくことで、キャッシュの新鮮さを常に一定以
上に保つ先行ヴァリデーションを導入する。先行ヴァリ
デーションは、ユーザの要求が特にないときにでも、ヴ
ァリデーションをサーバ１０、１０’、１０”、…が行
うことである。これにより、ユーザがＷＷＷページを参
照した時点でのヴァリデーションをできる限り回避す
る。

【０１０６】ヴァリデーション間隔をどの程度まで広く
取ることが可能かを見積るために、１度参照されたＷＷ
Ｗページが、別のユーザから参照されるまでの時間を、
我々の組織のＷＷＷ利用記録から得た。１時間以内に再
参照されるＷＷＷページは参照されるＷＷＷページ全体
の２.３%に過ぎず、１２時間以内でも９.９%である。ま
た全体を平均すると再参照間隔は１７７.７時間である
ことが明らかとなった。正確な時間はユーザの母集団に
左右されることが予想されるが、基本的にヴァリデーシ
ョンの時間間隔は８時間から１２時間程度でもユーザが
得るキャッシュの新鮮さにほとんど影響を与えないこと
が言える。また、ヴァリデーション動作を変更する場
合、広く用いられているＨＴＴＰ／１.０およびＩｎｔ
ｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒ
ｃｅ（ＩＥＴＦ）に標準化提案されているＨＴＴＰ／
１.１に準拠することが望ましい。ＨＴＴＰ／１.１では
キャッシュの古さが２４時間以内なら、ユーザに警告を
行う必要なしと決められている。このため、８時間以上
２４時間以下が、望ましい先行ヴァリデーション間隔と
なる。また、サーバが置かれている組織の都合により、
管理者が明示的に指定した時間帯を先行ヴァリデーショ
ンに用いてもよい。こうすることで、企業の従業員がサ
ーバ１０を利用しない時間帯を選んで先行プリフェッチ
を行うことが可能となる。

【０１０７】さらに、先行ヴァリデーションに際して
は、先行ヴァリデーションを行うサーバおよび当該サー
バ付近のネットワークに相当の負荷が発生するため、ク
ライアントからのサーバへの負荷が低い時間帯（オペレ
ーティング・システムへの問合わせにより、サーバの負
荷を得ることが可能である）、またはネットワークの負
荷が低い時間帯（グループ内のサーバとの通信速度の変
化を記録することにより、ネットワークの負荷の概算を
得ることができる）とを別の条件として用いるとよい。

【０１０８】また、先行ヴァリデーションは、各サーバ
が外部サーバ１３、１３’、１３”、…に対して行うこ
とができるが、複数のサーバが行うべき先行ヴァリデー
ションの対象となるＵＲＬを、１つのサーバに集めて、
一括してヴァリデーションを行った方が、１つのＵＲＬ
を何回もヴァリデーションする無駄が少なくなる。そこ
で、あるサーバから別のサーバに先行ヴァリデーション
を依頼するヴァリデーション依頼メッセージ３３０を用
いる。

【０１０９】先行ヴァリデーションの処理を図１１を用
いて説明する。

【０１１０】リーダのヴァリデーション管理部１０３
は、上記の時間間隔に基づく考察により、一定時間毎に
ヴァリデーション処理を起動する。またリーダ以外のヴ
ァリデーション管理部１０３は、同じく一定時間毎にヴ
ァリデーション処理を起動する。ヴァリデーション処理
を開始すると、ステップ１１０１で自分がリーダである
かどうかを判定する。

【０１１１】ステップ１１０１の判定がＹの場合（１１
０２）、ステップ１１０３でメンバから送られてくるヴ
ァリデーション依頼を受信する。一定時間ヴァリデーシ
ョン依頼を受け付けたあと、ステップ１１０４に移り、
ヴァリデーション処理を行う。この処理の内容は、ヴァ
リデーション依頼メッセージ３３０中の各ヴァリデーシ
ョン依頼メッセージ・エントリ３３１のＵＲＬ３３３に
ついて、ＨＴＴＰの「ＨＥＡＤ」要求を用いて、最終更
新日付を外部サーバ１３、１３’、１３”、…から入手
することである。ヴァリデーション処理が終わると、続
くステップ１１０５で、ヴァリデーション依頼を受信し
た各サーバに、ヴァリデーションの結果を返す。ヴァリ
デーションの結果はヴァリデーション依頼と同じヴァリ
デーション依頼メッセージ３３０であるが、各ヴァリデ
ーション依頼メッセージ・エントリ３３１の日付３３４
はそれぞれ、ステップ１１０４で得た最新の最終更新日
付で置き換えてから送信する。

【０１１２】一方ステップ１１０１の判定がＮの場合
（１１０７）、まずステップ１１０８でヴァリデーショ
ン依頼メッセージ３３０を作成する。ヴァリデーション
依頼メッセージ３３０には、ヴァリデーションの対象と
なる情報（すなわちキャッシュ表１０７に含まれる情報
のうち、参照回数２０４がＴ回以上の情報（Ｔは定
数））に関してそれぞれヴァリデーション依頼メッセ−
ジ３３０には、ヴァリデーションの対象となる情報（す
なわちキャッシュ表１０７に含まれる情報のうち、参照
回数２０４がＴ回以上の情報（Ｔは定数））に関してそ
れぞれヴァリデーション依頼メッセージ・エントリ３３
１を作成し、サーバＩＤ３３２に自分のサーバＩＤを、
ＵＲＬ３３３に当該情報のＵＲＬを格納する。日付３３
４には「空」を格納する。続くステップ１１０８で作成
したヴァリデーション依頼メッセージ３３０をリーダに
対して送信する。続くステップ１１０９では、リーダが
ヴァリデーション結果を返答として返すのを待って受け
取る。ステップ１１０９ではヴァリデーション結果をも
とにキャッシュ表１０７を更新する。すなわち、ヴァリ
デーション結果であるヴァリデーション依頼メッセージ
３３０に格納されたヴァリデーション依頼メッセージ・
エントリ３３１のそれぞれについて、ＵＲＬ３３３がキ
ャッシュ表１０７のＵＲＬ２０１に等しいキャッシュ表
エントリ２００を検索し、もしそのようなキャッシュ表
エントリ２００があれば、参照回数２０４に０を格納す
る。そして、当該キャッシュ表エントリ２００の日付２
０３を当該ヴァリデーション依頼メッセージ・エントリ
３３１の日付３３４と比較する。もし日付３３４がより
新しければ、キャッシュ表１０７中の情報は古いので、
当該キャッシュ表エントリ２００を削除する。この際、
グループのキャッシュ・ディレクトリ１０８を更新する
ために、サーバ１０はグループのメンバに対してホスト
ＵＲＬメッセージ３７０を送る。ホストＵＲＬメッセー
ジ３７０のサーバＩＤ３７２はサーバ１０のＩＤを、Ｕ
ＲＬ３７３は当該ＵＲＬ３３３を、フラグ３７４は「存
在しない」を保持する。

【０１１３】なお、上記定数Ｔの設定に際しては、ＷＷ
Ｗのローカリティが低いことを考慮することが重要であ
る。例えば、我々の組織では、ユーザが要求したＷＷＷ
の情報のうち７０%近くが、一回しか参照されないこと
がわかった。このため、例えばＴを１にすると、キャッ
シュされた情報のうちヴァリデーションをすべき情報
を、効果的に絞りこむことができ、大量の情報をすべて
ヴァリデーションしなくてもよい。

【０１１４】以上の手順で、先行ヴァリデーションが行
われ、キャッシュ表１０７の中の情報は常にある程度以
上の新鮮さが保証される。

【０１１５】

【発明の効果】サーバ動作情報（動作しているサーバの
リスト）を分散管理するためのサーバ状態伝播プロトコ
ルを持ったことにより、ＷＷＷのプロキシのように複数
のサーバを連携して動作させる際の、管理者の手間を減
らすことができる。管理者は他のいくつかのサーバを指
定してサーバを立ち上げる以外、サーバ間の連携を管理
する必要がない。

【０１１６】サーバ状態伝播プロトコルが形成するマル
チキャスト階層を用いてキャッシュ・ディレクトリの伝
播と、キャッシュ制御を、集中管理サーバなしで行う広
域協調キャッシュ管理プロトコルを備えたことにより、
複数のサーバに分散して存在するキャッシュを運営する
ために、複数のサーバ間で互いのキャッシュのリストを
効率よく交換し、以て１つのサーバのキャッシュにない
情報を別のサーバに問い合わせることができる。

【０１１７】ユーザの要求以前にあらかじめヴァリデー
ション動作を行っておく「先行ヴァリデーション」を備
えたことにより、ヴァリデーション動作がユーザ反応時
間を悪化させないようにすることができる。

【図面の簡単な説明】

【図１】本発明の内部構成を示すブロック図。

【図２】データ構造を示す図。

【図３】メッセージの形式を説明する図。

【図４】サーバ初期化時の階層形成処理のフローチャー
ト。

【図５】グループ参加要求処理のフローチャート。

【図６】階層維持メッセージ受信処理のフローチャー
ト。

【図７】階層再構成処理のフローチャート。

【図８】キャッシュ価値回覧処理のフローチャート。

【図９】移動予告回覧処理のフローチャート。

【図１０】破棄予告回覧処理のフローチャート。

【図１１】ヴァリデーション処理のフローチャート。

【符号の説明】

１０、１０’、１０”、…：サーバ、１１：クライアン
ト、１２：ネットワーク、１３、１３’、１３”、…：
外部サーバ、１００：クライアント要求処理部、１０
１：キャッシュ管理部、１０２：サーバ管理部、１０
３：ヴァリデーション管理部、１０４：キャッシュ価値
評価部、１０５：キャッシュ移動破棄部、１０６：通信
部、１０７：キャッシュ表、１０８：キャッシュ・ディ
レクトリ、１０９：サーバ状態表、１１０：グループ
表。

───────────────────────────────────────────────────── フロントページの続き (72)発明者野田文雄東京都国分寺市東恋ケ窪一丁目280番地株式会社日立製作所中央研究所内

Claims

【特許請求の範囲】

【請求項１】ネットワークで互いに接続された１つ以上
のサーバ機能を有する計算機からなり、該計算機はそれ
ぞれ一意な番号（ＩＤ）を持ち、それぞれ独立に動作ま
たは停止することができ、該ＩＤを用いて該計算機間の
通信先を指定し、動作中の計算機を１つ以上の第１のグ
ループに分類して管理するサーバ分散管理方法であっ
て、第１のグループに属する計算機のそれぞれに、該計算機
の属するグループを構成する計算機のＩＤを通知する処
理と、管理者が動作中の計算機の初期ＩＤを１つ以上与えて第
１の計算機を新たに起動した際に、該計算機を第１のグ
ループのいずれかに追加する処理と、第１のグループのいずれかの台数が第１の定数を超えた
場合に、第１のグループを分類し直して、各グループを
第１の定数以下の台数に再分類する処理と、からなるこ
とを特徴とするサーバ分散管理方法。
【請求項２】前記第１のグループのそれぞれがリーダを
持ち、前記追加する処理は、前記初期ＩＤに対応する１つ以上の計算機から、該計算
機が保持する動作中の計算機の表を前記第１の計算機に
送信する処理と、第１の計算機が該表中の第２の計算機を選択する処理
と、第１の計算機をグループに追加する要求を、第１の計算
機が第２の計算機経由で、第２の計算機の属するグルー
プのリーダである第３の計算機へ送信する処理と、第３の計算機が第１の計算機を該グループへ追加する処
理とからなる請求項１に記載のサーバ分散管理方法。
【請求項３】前記動作中の計算機が、前記第１のグルー
プの相互の上下関係を決定し、もって第１のグループが
階層構造を形成する請求項１に記載のサーバ分散管理方
法。
【請求項４】前記再分類する処理は、前記第１の定数を超えたグループのリーダが新たなグル
ープを作成する処理と、該超えたグループに属する計
算機の一部を該新たなグループに移動する処理と、から
なる請求項１に記載のサーバ分散管理方法。
【請求項５】前記再分類する処理は、前記第１の定数を
超えたグループのリーダが、該リーダの属するグループ
を構成する計算機の一部を前記階層構造で隣接するグル
ープに移動する処理を含む請求項３に記載のサーバ分散
管理方法。
【請求項６】前記第１の計算機をグループに追加する要
求を送信する処理は、前記動作中の計算機の一部または全部との通信速度を計
測する処理と、第１の計算機との通信速度が大きい計算機が属するグル
ープへ追加の要求を送信する処理と、からなる請求項２
に記載のサーバ分散管理方法。
【請求項７】ネットワークで互いに接続された１つ以上
のサーバ機能を有する計算機からなり、該計算機はそれ
ぞれ一意な番号（ＩＤ）を持ち、それぞれ独立に動作ま
たは停止することができ、該ＩＤを用いて該計算機間の
通信先を指定し、動作中の計算機を１つ以上の第１のグ
ループに分類して管理するサーバ分散管理方法であっ
て、第１のグループに属する計算機のそれぞれに、該計算機
の属するグループを構成する計算機のＩＤを通知する処
理と、管理者が動作中の計算機の初期ＩＤを１つ以上与えて第
１の計算機を新たに起動した際に、該計算機を第１のグ
ループのいずれかに追加する処理と、第１のグループのいずれかの台数が第１の定数を超えた
場合に、第１のグループを分類し直して、各グループを
第１の定数以下の台数に再分類する処理と、動作中の計算機のいずれかが停止または故障または通信
が不能になった場合に、該計算機の属するグループから
該計算機を削除する処理と、前記第１のグループのいずれかの台数が第２の定数未満
となった場合に、第１のグループに属する一部または全
部の計算機を第２のグループに移動させる処理と、から
なることを特徴とするサーバ分散管理方法。
【請求項８】前記第２のグループとして、請求項３の階
層構造で隣接するグループを用いる請求項７に記載のサ
ーバ分散管理方法。
【請求項９】前記第１のグループに属する計算機が、第
１のグループを構成する計算機のＩＤを収集する処理を
行う請求項１または請求項７に記載のサーバ分散管理方
法。
【請求項１０】前記第１のグループに属する計算機のそ
れぞれが、該計算機の属するするグループを構成するす
べての計算機のＩＤを保持する表を持つ請求項１または
請求項７に記載のサーバ分散管理方法。
【請求項１１】前記第１のグループの１つである第３の
グループに属する計算機が、第３のグループを構成する
計算機の一部または全部に１つのデータを送信する場合
に、第３のグループを構成する計算機の間で該データを
順に回覧する請求項１または請求項７に記載のサーバ分
散管理方法。
【請求項１２】前記第３のグループに属する計算機が、
前記第３のグループを構成する１つ以上の計算機からデ
ータを収集する場合に、１つのメッセージを該１つ以上
の計算機の間で回覧し、回覧時に該１つ以上の計算機の
各々が該メッセージにデータを付加する請求項１または
請求項７に記載のサーバ分散管理方法。
【請求項１３】ネットワークで互いに接続されて情報を
利用するクライアントと、１つ以上の情報を保持してク
ライアントにより指定された情報を提供する２つ以上の
サーバとからなり、１つのサーバが保持する情報を別の
サーバに移動させるサーバ分散管理方法であって、第１のサーバが保持する第１の情報を第２のサーバに移
動させることを１つ以上の第３のサーバに予告する移動
予告メッセージを第３のサーバに送付する処理と、該メッセージを受け取った第３のサーバが、第３のサー
バが持つ第２の情報を第２のサーバに移動する動作を中
止する処理と、からなることを特徴とするサーバ分散管
理方法。
【請求項１４】前記第３のサーバが、請求項１または請
求項７に記載のグループに属する計算機である請求項１
３に記載のサーバ分散管理方法。
【請求項１５】前記移動予告メッセージを請求項１１に
記載の順に回覧して第３のサーバに送付する請求項１３
に記載のサーバ分散管理方法。
【請求項１６】前記移動予告メッセージを受け取った第
３のサーバは、前記第２のサーバへの情報の移動数が第
１の定数以上である場合に第２の情報を第２のサーバに
移動する動作を中止する請求項１３に記載の情報サーバ
分散管理方法。
【請求項１７】ネットワークで互いに接続された、情報
を利用するクライアントと、１つ以上の情報を保持し、
クライアントからの依頼により指定された情報を提供す
る２つ以上のサーバからなり、サーバが保持するデータ
を破棄することができるサーバ分散管理方法であって、第１のサーバが保持する第１の情報を破棄する際に、第
１の情報のコピーを持つ可能性がある１つ以上の第２の
サーバに、該破棄を予告する破棄予告メッセージを送付
する処理と、該破棄予告メッセージを受け取った第２のサーバが自身
の保持する第１の情報のコピーの破棄を中止する処理
と、からなるサーバ分散管理方法。
【請求項１８】前記第２のサーバが、請求項１または請
求項７に記載のグループに属する計算機である請求項１
７に記載のサーバ分散管理方法。
【請求項１９】前記破棄予告メッセージを、請求項１１
に記載の順に回覧して第２のサーバに送付する請求項１
７に記載のサーバ分散管理方法。
【請求項２０】前記第２のサーバが第２の情報を破棄す
る際に、回覧された前記破棄予告メッセージに、該破棄
の予告を追加して回覧する請求項１７に記載のサーバ分
散管理方法。
【請求項２１】前記第２のサーバが、前記第１のサーバ
及び第２のサーバのうち、第１の情報またはそのコピー
を持つ可能性があるサーバの数の予測である保持数を保
持し、前記破棄予告メッセージに記載の第１の情報またはその
コピーの破棄予告数を得、該保持数から該破棄予告数を減じた数が１以下であれ
ば、第２のサーバが保持する第１の情報またはそのコピ
ーの破棄を中止する請求項１７に記載のサーバ分散管理
方法。
【請求項２２】ネットワークで互いに接続された、情報
を利用するクライアントと、１つ以上の情報のコピーを
保持し、クライアントからの依頼により指定された情報
を提供するサーバと、１つ以上の情報を保持し、サーバ
またはクライアントに情報を提供する２つ以上の外部サ
ーバとからなり、サーバまたはクライアントが情報のコ
ピーが最新かどうかを問合わせるヴァリデーションに対
して外部サーバが答えるサーバ分散管理方法であって、サーバが保持する情報のうち、前回のヴァリデーション
から１回以上参照された情報を、所定の時間毎に、サー
バが外部サーバにヴァリデーションを行うことを特徴と
するサーバ分散管理方法。
【請求項２３】前記所定の時間として、８時間以上２４
時間以下の時間を用いる請求項２２に記載のサーバ分散
管理方法。
【請求項２４】前記所定の時間毎のヴァリデーションに
かえて、前記情報を外部サーバから入手してから８時間
以上２４時間以下で、かつサーバの負荷またはサーバ近
辺のネットワークの負荷が所定の値以下の時にヴァリデ
ーションを行う請求項２２に記載のサーバ分散管理方
法。
【請求項２５】前記所定の時間毎のヴァリデーションに
かえて、前記情報を外部サーバから入手してから８時間
以上２４時間以下で、かつ管理者が指定した時間帯の中
でヴァリデーションを行う請求項２２に記載の情報サー
バ分散管理方法。