以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。図1〜図17は、本発明の一実施の形態を説明するための図である。
本発明の一実施の形態におけるサーバ装置は、本サーバ装置を複数用いてサーバグループが定義・設定された構成において、クライアントからの外部のWebサーバへの参照の要求をサーバグループで受信して、各サーバ装置でのキャッシュ状態及び負荷状態の判断に応じて、Webサーバ参照の代理処理を受け付ける。これによりサーバ間での負荷の調整がなされる。本サーバ装置上では、サーバグループにおける代理処理に係わる負荷分散のための制御方法に従った処理が、プログラムやハードウェア論理等に従って実行される。
<情報処理システム>
図1は、本発明の一実施の形態におけるサーバ装置であるサーバ200を含んで構成される情報処理システムの構成例を示す。本システムは、ネットワーク4に接続される、PC1と、サーバ集合筐体2に実装された複数のサーバ200{a,b,c}と、Webサーバ3とを有する。
ネットワーク4は、TCP/IPをベースとするインターネット、LANなどである。本実施の形態では、ネットワーク4は特にEthernet(登録商標)などによるLANを含んだインターネットであり、TCP/IPベースのプロトコルで通信処理が行われる。PC1とサーバ200は、LANで接続される。Webサーバ3は、サーバ200に対する外部サーバとして、インターネット上に多数存在する。また、サーバグループにおける実際の接続形態として、マルチドロップ接続、スイッチングハブやルータ経由によるスター接続などがあり得るが、いずれの場合も、各サーバ200へ出入りする電文はすべて、他のサーバ200においても傍受可能なように設定されている。
PC1は、ネットワーク端末装置であり、サーバ200に対するクライアント装置として、ネットワーク4を通じてサーバ200に対してアプリケーション等の処理、本例ではWeb参照要求処理を実行する。必要に応じて1つ以上のPC1がネットワーク4に接続される構成である。
サーバ200{a,b,c}は、クライアントであるPC1からの要求を受信してそれに対応したアプリケーション等の処理を行う装置である。サーバ200は、HTTPプロトコルに対応して、Webサーバ3への参照の代理・中継処理を行うものである。本例では、各サーバ200は、サーバ集合筐体2内に実装可能なブレードサーバ方式である。
サーバ集合筐体2は、1つの筐体に複数のサーバ200を実装可能とする筐体である。サーバ集合筐体2は、本例では、ブレードサーバ方式のサーバ200に対応したブレードシャーシの形態である。その他、サーバ集合筐体2は、サーバ200の形態に応じてラックマウントキャビネットといった各種形態が可能である。各サーバ200{a,b,c}は、保守・管理者により、必要に応じて、サーバ集合筐体2内に対して挿抜の動作により実装可能である。前記サーバ200の実装とは、サーバ200及びサーバ集合筐体2の形態に応じた挿抜や搭載やネジ止めなどの方法に加え、製造時点で、布線、半田付けなどにより事実上固定されているものも含んでいい。
サーバ集合筐体2には、各サーバ200の挿抜のためのスロット及びコネクタ等の構成を有する。例えばサーバ200の増設の場合、保守・管理者が、対象サーバ200をスロットに挿入してコネクタ同士を接続することで、サーバ集合筐体2内に接続・固定される。サーバ集合筐体2には、各サーバ200{a,b,c}が自由に実装され、すべてのサーバ200が同じネットワ−ク4に接続される。サーバ集合筐体2に有する実装スペースが許す限りで何台のサーバ200でも実装可能である。本例では、3つのサーバ200{a,b,c}がサーバ集合筐体2内に実装されており、それぞれネットワーク4上で通信可能である。
本システムでは、これら複数のサーバ200{a,b,c}を同一グループとして定義し、ネットワーク4上で処理の負荷分散を行う対象として取り扱う。このグループに関する定義情報を含む必要な設定の情報が、当該グループの各サーバ200において保持される。これら同一グループとして定義及び通信接続される複数のサーバ200{a,b,c}を、サーバグループと称する。
Webサーバ3は、Webコンテンツデータ(コンテンツデータとも称する)を掲示してクライアントに提供・送信するサーバである。Webサーバ3は、コンテンツデータのファイルを保有している。Webサーバ3上には、ポートを介してコンテンツデータが外部からアクセス可能な状態として掲示されている。コンテンツデータは、HTML形式などによるWebページファイルや、それらにリンクされている画像その他の関連データファイルなどが含まれる。また言うまでも無く、本コンテンツデータの内部(ヘッダ情報など)または外部には、本コンテンツデータの更新日時の情報も記述されている。Webサーバ3は、クライアントとなるサーバ200から、ネットワーク4を経由して、ドメイン名やファイル名などを含んだ指定URL及びそれに対応するIPアドレスによりアクセスされる。Webサーバ3は、ポートを通じて、URL指定によるコンテンツ参照の要求を受信すると、URLで指示される最新のコンテンツデータをサーバ200へ送信する。
本システムでは、PC1からのWeb参照要求を、共通の通信アドレスによりサーバグループで受信すると共に、キャッシュ状態と負荷状態に応じてサーバ200で処理を受け付ける。そして処理を受け付けたサーバ200は、Web参照が必要な場合にWebサーバ3へ要求を出す。そしてサーバ200はWebサーバ3からの応答またはキャッシュデータをもとに、PC1へ応答を送信する。PC1からは、Webサーバ3に対するURL参照要求すなわちURL指定によるコンテンツデータ参照の要求が発行される。前記要求を、LAN上で、サーバグループのサーバ200{a,b,c}で受信し、少なくともいずれかのサーバ200で受け付けて、Webサーバ3への参照を代理処理する。
<PC>
図2は、PC1のハードウェアブロック構成図を示している。PC1は、CPU101、メモリ102、LANボード103、HDD104、入力制御ボード105、出力制御ボード106を有する。
CPU101は、PC1全体を制御するプロセッサである。メモリ102は、プログラムやデータなどを一時記憶する。HDD104は、プログラム、テーブル類、DB情報などを記憶している外部記憶装置である。CPU101は、メモリ102上のプログラムを実行してPC1としての機能を実現する。入力制御ボード105は、キーボード、マウスなどの入力装置を制御するボードである。出力制御ボード106は、モニタ、液晶ディスプレイなどの表示装置や他の出力装置を制御するボードである。LANボード103は、ネットワーク4に対するLANインターフェースを制御するボードである。LANボード103によりネットワーク4上で各種コマンドやデータが授受される。PC1は、後述するグループIPアドレス614などを認識している。
図3は、PC1のソフトウェアブロック構成図を示している。PC1は、アプリケーション部111、OS112、通信制御部113、入力制御部114、出力制御部115を有する。
アプリケーション部111は、Webブラウザなどのプログラムを示す。アプリケーション部111は、Webサーバ3に対して参照要求などを発行することができる。OS(オペレーティングシステム)112は、入出力制御、イベント通知、アプリケーション部111のプログラムの起動・終了などのスケジュール管理を行う。アプリケーション部111及びOS112は、サーバ200に対する処理要求を必要に応じて発行する。
通信制御部113は、前記LANボード103の処理に対応するもので、LANインターフェースを制御するドライバや、TCP/IPプロトコル制御などが含まれる。通信制御部113は、LAN上でサーバグループのサーバ200との間で電文を授受する。通信制御部113などの処理により、PC1からWebサーバ3への参照要求が、サーバグループへの要求へと変換され送信される。入力制御部114は、前記入力装置の入力制御を行うドライバなどを含む。出力制御部115は、前記表示装置を制御する表示ドライバ、ビデオメモリ管理などが含まれる。
<サーバ>
図4は、サーバ200{a〜c}のハードウェアブロック構成図を示している。各々のサーバ200は、CPU201、メモリ202、LAN制御部203、HDD204、SVP制御部205を有する。
CPU201は、サーバ200全体を制御するプロセッサであり、自サーバでの処理及びWebサーバ3に対する処理を制御する。メモリ202は、プログラム、データ、テーブル情報などを一時記憶するメモリである。HDD204は、プログラム、テーブル類、DB情報などを記憶している外部記憶装置である。本例では、HDD204には、後述するテーブル(6,7)やキャッシュ情報及びキャッシュデータが保持される。CPU201は、メモリ202上のプログラムを実行してサーバ200としての機能を実現する。
LAN制御部203は、ネットワーク4に対するLANインターフェースを制御する部分である。LAN制御部203によりネットワーク4上で各種コマンドやデータが授受される。また、LAN制御部203は、同一サーバグループ内にある関連IPアドレスをソース、デスティネーションに使用した電文を、一旦、本制御部に取り込み、解析し、傍受可能としている。
SVP制御部205は、SVPインターフェースを制御する部分であり、サーバ内各部と外部のSVP(サービスプロセッサ)に対して接続される。SVPは、SVP制御部205を通じて、各サーバ200についての保守・管理の処理を行う。SVPの処理は、例えば構成や障害の管理といったものである。
本サーバ200は、ブレードサーバ方式であるため、個々には入力装置や出力装置を持たない構成である。その代わりに、外付けの監視装置やシステムコンソールなどの役目を果たすSVPによる入出力を可能とするために、SVP制御部205を有している。保守・管理者は、SVPを操作してサーバ200の保守・管理を行うことができる。サーバ集合筐体2としてのブレードシャーシ内には、図示しないが、上記SVPや、各サーバ200に対する電源供給を行う電源部や送風を行うファンといった部位が設けられている。
図5は、サーバ200{a〜c}のソフトウェアブロック構成図を示している。サーバ200は、アプリケーション部211、OS212、通信制御部213、監視制御部214、負荷測定部215、設定テーブル6、動作テーブル7を有する。
アプリケーション部211は、Web参照などのアプリケーションサーバソフトウェアのプログラムを示す。本例では、アプリケーション部211は、HTTPに対応したプロキシサーバプログラム、すなわち、Webサーバ3へのアクセス・参照を代理・中継しデータをキャッシュする処理を行うためのプログラムである。アプリケーション部211の処理では、PC1などからのHTTPプロトコルなどを用いたURL指定による参照要求に対して、Webコンテンツデータ参照を制御する。
OS212は、入出力制御、イベント通知、アプリケーション部211のプログラムの起動・終了などのスケジュール管理を行う。サーバ200は、OS212とアプリケーション部211において、PC1からの要求に対応した処理を行う。
通信制御部213は、前記LAN制御部203の処理に対応するもので、LANインターフェースを制御するドライバ、TCP/IPプロトコル制御などが含まれる。通信制御部213を介して、PC1との間、サーバグループのサーバ200間、及びWebサーバ3との間で、それぞれ通信可能である。
監視制御部214は、同一サーバグループに構成されたサーバ200の動作状況の監視や、LANインターフェース上での電文の傍受監視などを行う。また監視制御部214は、設定テーブル6や動作テーブル7を管理し、必要に応じて参照・更新する。
負荷測定部215は、負荷状態の把握のための負荷情報として、自サーバ200のCPU201におけるCPU使用率を、定期的またはアプリケーション部211の処理の起動・終了などの負荷の変動時に応じて測定する。負荷測定部215で測定された自サーバ200の負荷情報は、監視制御部214を介して、動作テーブル7に反映される。また、負荷がある程度変動した場合などの契機で、通信制御部213を介して、同一サーバグループ内の他サーバ200への負荷情報の通知や交換のための通信が行われる。
本実施の形態では、グループ定義情報として、設定テーブル6と動作テーブル7を有する。設定テーブル6は、システムの設定のための情報であり、自身も含めた同一サーバグループの各サーバ200{a,b,c}のアドレスや識別名などの必要な設定情報を保持している。動作テーブル7は、システムの状態管理のための情報であり、自身も含めた同一サーバグループの各サーバ200{a,b,c}の動作、負荷、及びキャッシュ等の状態を情報として管理・保持している。
Webサーバ3のハードウェアブロック構成は、サーバ200の構成と同様に、CPU、メモリ、ネットワーク制御部、HDD等を備える。前記CPUがメモリ上のプログラムを実行してWebサーバ3としての機能を実現する。Webサーバ3のソフトウェアブロック構成は、サーバ200の構成と同様に、OS、アプリケーション部、ポートを含む通信制御部などを備える。前記アプリケーション部は、Webサーバプログラムなどであり、クライアントからの参照要求に応じて、コンテンツデータを要求元へ送信する処理などを行わせる。なお、Webサーバ3は、前記図4,5に示すサーバ200と同様のブレードサーバ方式でも、前記図2,3に示すPC1と同様のスタンドアロン方式でもよい。
<テーブル>
図6は、設定テーブル6の形式の一実施例を示す。設定テーブル6は、すべてのサーバ200において、自ホスト名620を除き、同じ内容を持つ。設定テーブル6で、列(601〜603)にサーバ200{a,b,c}単位の情報を示し、行(611〜615)に各設定情報の項目を示している。これら設定テーブル6の内容は、外部のSVPよりSVP制御部205を通じて設定され、HDD204内に記憶される。
固有ホスト名611は、各サーバ200に固有のホスト名が割り当てられる。本例では、各サーバ200{a,b,c}の固有ホスト名611は、“APSRVRa”、“APSRVRb”、“APSRVRc”と割り当てられている。
固有IPアドレス612は、各サーバ200{a,b,c}に固有のIPアドレスが通信アドレスとして割り当てられる。本例では、各サーバ200{a,b,c}の固有IPアドレス612は、“202.200.256.1”、“202.200.256.2”、“202.200.256.3”と割り当てられている。
グループホスト名613は、同一サーバグループのサーバ200群のすべてに対して、同一ホスト名が割り当てられる。本例では、サーバ200{a,b,c}のグループホスト名613は、“APSRVR”が割り当てられている。
グループIPアドレス614は、同一サーバグループのサーバ200群のすべてに対して、同一IPアドレスが共通の通信アドレスとして割り当てられる。一般には、本アドレスとして、テレビ会議などで使用される同一のマルチキャストアドレスや、ブロードキャストアドレスとして定義することでもよい。これにより、サーバ200が分散していても、ルータなどを経由して電文が届けられることになるため、各サーバ200のデータも傍受が可能になる。また、さらに、各サーバ200が同じLANの物理線上に接続されている場合は、固有のIPアドレス以外に、あらかじめ定めた共通のIPアドレスを監視することで実現可能である。本例では、すべてのサーバ200{a,b,c}は、グループIPアドレス614として“202.200.256.0”が割り当てられている。
MACアドレス615は、各サーバ200で固有のMACアドレスである。本例では、サーバ200{a,b,c}のMACアドレス615は、それぞれ、“01.23.45.67.89.AB”、“AB.CD.EF.01.23.45”、“67.89.AB.CD.EF.01”となっている。LAN制御部203は、MACアドレス615を有し、SVPからの設定でなく、パワーオン時、自サーバのMACアドレスのみ、LAN制御部203から取得し、本テーブルに設定することも可能である。また本MACアドレス615は、サーバ200間での処理受け付けの優先順位の情報として使用される。
固有IPアドレス612、グループIPアドレス614、MACアドレス615は、ネットワーク4上の通信において送信元や送信先のアドレスとして使用される。
また、自ホスト名620には、自サーバ200のホスト名が設定される。例えば、サーバa(200)の自ホスト名620に、“APSRVRa”が設定されている。自ホスト名620が固有ホスト名611とリンクすることにより、上記列(601〜603)のうちいずれが自サーバ200の内容かを知ることができる。
本実施の形態では、PC1からサーバ200に対する要求(第1要求913)は、グループIPアドレス614が送信先として使用される。また、要求を受け付けたサーバ200からPC1に対する応答(第1応答914)は、固有IPアドレス612が送信元として使用される。また、サーバ200からWebサーバ3に対する要求(第2要求915)は、固有IPアドレス612が送信元として使用される。ここで、第2要求915のデスティネーションとして、Webサーバ3のIPアドレスの取得方法に関しては、第1要求913のコンテンツ905を参照して、それにより、DNS機能を持っているサーバから、対応するIPアドレスを取得する周知技術を利用している。また、Webサーバ3からサーバ200に対する応答(第2応答916)は、固有IPアドレス612が送信先として使用される。ここで、デスティネーションIPアドレスとして、第2応答916の固有IPアドレス612から第1応答914のPC1のIPアドレスへの変換方法として、サーバ200内に変換テーブルを持ち変換(Network Address Translation)を行う周知技術を利用している。
PC1からは要求に対応した処理を実際に受け付けて実行しているサーバ200を識別する必要は特にないが、当該サーバ200の識別は、固有IPアドレス612等により可能である。また、グループIPアドレス614や固有IPアドレス612は、各サーバ200間の動作状態や負荷情報やキャッシュ情報の通知や交換などの通信においても使用される。本例では、グループIPアドレス614を用いてグループ内に情報が通知される。
通信におけるIPアドレス部分では、上記グループIPアドレス614や固有IPアドレス612が設定されていても、ネットワーク4やEthernet(登録商標)のデータリンクレベルでは、実際に送受信処理するLAN制御部203のMACアドレス615が設定される。但し、以降、IPアドレスからMACアドレス615への変換の技術は、ARP(Address Resolution Protocol)などを使用して、条件に該当するサーバが応答を返すことでMACアドレス615に変換することによりなされる。以下、この処理の詳細過程は省略するが、IPアドレスで行っている動作は、MACアドレス615においても同様に適用可能である。
図7は、動作テーブル7の形式の一実施例を示す。動作テーブル7の列(701〜703)にサーバ200{a,b,c}単位の情報を示し、行(711,712,713)に各サーバ200の動作や負荷やキャッシュの状態などの項目を示している。本例では、動作状態711とCPU使用率712とURLコンテンツキャッシュインデックス情報713とにより各サーバ200の状態が管理されている。これらの値に基づき、サーバ200での処理の受け付けが判断され、すなわちサーバ200間の負荷が調整されることになる。
動作状態711は、各サーバ200での処理に係わる動作状態を示す項目であり、状態の変動に応じて設定される。動作状態711が“ON”ならば、該当サーバ200は、パワー(電源)オンされて稼動状態であること、すなわち処理中または処理提供可能な状態を示す。また動作状態711が“OFF”ならば、該当サーバ200は、パワーオフまたは休止状態、すなわち処理提供しない状態であることを示す。
CPU使用率712は、サーバ200での処理に関する負荷状態を表わす値であり、CPU201の使用率の数値(単位は[%])で示している。自サーバのCPU使用率712は、負荷測定部215の処理により設定され、他サーバのCPU使用率712は、他サーバからの負荷情報の通知により設定される。
URLコンテンツキャッシュインデックス情報(以下、インデックス情報とも称する)713は、サーバ200がWebサーバ3にアクセスした結果、キャッシュとして保存している情報及びデータのうちのデータへのインデックス情報(キャッシュ情報とも称する)の部分である。本インデックス情報713は、サーバ200でのキャッシュ状態を表わす情報であり、URLに対応したコンテンツデータのキャッシュデータへの参照のためのインデックスとなる。各列(701〜703)のURLコンテンツキャッシュインデックスa,b,cは、各サーバ200の情報に対応する。各サーバ200は、自サーバについてのURLコンテンツキャッシュインデックスを、Web参照結果に応じて適宜更新する。また、サーバ200間で自サーバについてのインデックス情報713(キャッシュ情報)を通知や交換し合うことで、各サーバ200は、サーバグループの各サーバ200についてのキャッシュ状態を把握する。
また、これら動作テーブル7の情報も、自ホスト名620とリンクして前記図6と同様の列の配列とすることにより、上記列(701〜703)のうちいずれが自サーバ200の内容かを知ることができる。これら動作テーブル7の内容は、各サーバ200の状態が変化するたびに、後述の方法で複数のサーバ200間でお互いに通信することにより、各サーバ200で保持している情報の整合性をとっている。
図8は、各サーバ200が保持するURLコンテンツキャッシュテーブル(以下、キャッシュテーブルとも称する)の形式の例を示す。本キャッシュテーブルは、キャッシュ情報及びキャッシュデータを管理するものであり、URL801、Web更新日時802、HTMLファイル名803の項目を有する。
URL801は、サーバ200が過去にWebサーバ3へのアクセスで参照した結果として保存しているURLを示す。URL801は、例えば、「HTTP://A」(Aは、ホスト名やドメイン名などを含む、情報資源名を表わす文字列とする)である。URL801は、プロトコル識別子、ホスト名やドメイン名などに続いてHTMLファイル名803を含む。本例では、URL801とは別にHTMLファイル名803を管理している。また、キャッシュテーブルで、URL801(ホスト名)と対応付けられるIPアドレスなどを管理するようにしてもよい。
Web更新日時802は、URL801に対応した、Webサーバ3上のコンテンツデータの更新日時の情報を示す。すなわち、Web更新日時802は、サーバ200がWebサーバ3上から参照した結果として保存しているコンテンツデータのキャッシュデータについての更新日時を示す。なお、Web更新日時802は、サーバ200がコンテンツデータをキャッシュした日時などとは異なる。
図8に示すキャッシュテーブルにおけるURLコンテンツキャッシュインデックス部(801,802)に相当する内容が、図7に示す各サーバ200についてのインデックス情報713にも格納されている。
HTMLファイル名803は、コンテンツデータを表現しているファイル名またはホスト(Webサーバ3)上における当該ファイルへのパスなどを示す。ファイル821は、HTMLファイル名803にリンクされている実コンテンツファイル(HTMLファイル等)のデータすなわちサーバ200におけるキャッシュデータを示す。本例では、コンテンツデータのファイル名をHTMLファイル名803とし、コンテンツデータのファイル821をHTMLファイルとしているが、HTMLファイルからリンクされている文字、画像、音声などの各種データファイルや、それらを合わせた複数のファイルや、それらを統合圧縮したファイルなどで構成されていてもよい。多くの場合、実コンテンツファイルには、画像や音声データなども含まれている。本例では、サーバ200間で、キャッシュテーブルの列(801,802)に相当するインデックス情報713のみを、キャッシュ情報として、お互いに提供・通知し合っている。
図8に示すキャッシュテーブルの行(811,812)は、それぞれキャッシュ例を示しており、例えば、過去に参照したURL801について名称順にソートされて配置されている。また、キャッシュテーブルにおいて、コンテンツデータについてのドメインやホストや複数のファイルによる階層構成に対応して、キャッシュ情報及びキャッシュデータを格納し、関連付けて管理する。
<電文>
図9は、ネットワーク4またはLANインターフェース上で使用される電文の形式の一実施例を示している。電文の種類に対応してその電文に設定される各種情報を示している。PC1、サーバグループのサーバ200、Webサーバ3の間で授受される電文の種類として、本例では、各コマンド(911〜919)を使用する。各コマンド(911〜919)は、例えばヘッダとコンテンツを有する形式であり、ステータスや単なるデータ等の場合を含むものとする。各電文は、コマンド901、ソースIPアドレス902、デスティネーションIPアドレス903、セッション番号904、コンテンツ905の領域を含む。
コマンド901には、起動完了911、負荷情報912、第1要求(第1のURL参照要求)913、第1応答(第1のURL参照応答)914、第2要求(第2のURL参照要求)915、第2応答(第2のURL参照応答)916、更新日時要求917、更新日時回答918、URLキャッシュ919がある。各コマンド(911〜919)は、電文の種類を示しており、コンテンツ905として何を含むかが決まる。なお、便宜的に、PC1とサーバ200の間の通信で「第1」と称し、サーバ200とWebサーバ3の間の通信で「第2」と称して区別している。
ソースIPアドレス902、デスティネーションIPアドレス903は、それぞれ、TCP/IPプロトコルにおける送信元のアドレス、送信先のアドレスが指定される。またセッション番号904は、他の同類の要求及び処理と混信しないための識別情報が設定される。
起動完了911は、自サーバ200が電源オンされて処理提供可能な状態(“ON”)となったことを、同一サーバグループ内の他サーバ200に対し知らせるものである。本例では、このソースIPアドレス902には、各サーバ200の固有IPアドレス612として“202.200.256.i”(iは1,2,3のどれか)を指定する。またデスティネーションIPアドレス903には、グループIPアドレス614を指定する。またコンテンツ905には、どのサーバ200が“ON”となったかを示す情報として“APSRVRj=ON”(jはa,b,cのどれか)が含まれている。
負荷情報912は、サーバ200の負荷の変動時、自身を含む各サーバ200の負荷情報を、サーバグループ内の他サーバ200に対し報告するためのものである。前記負荷の変動は、電源オンによるサーバ200の起動も含む。このソースIPアドレス902及びデスティネーションIPアドレス903は、起動完了911の場合と同様である。また、コンテンツ905には、自サーバ200で動作テーブル7に保持しているサーバグループ内の全サーバ200についての負荷情報を、他サーバ200への確認も含めて報告する。本例では、コンテンツ905に、動作状態711の情報も含めており、例えば“APSRVRa=ON,70%”,“APSRVRb=ON,80%”,“APSRVRc=OFF”などが含まれている。
第1要求913は、各PC1からのURL参照要求、すなわちURLで指定されるWebサーバ3上のコンテンツデータへの参照(取得)の要求を示す。このソースIPアドレス902には、URL参照要求元のPC1のIPアドレスがセットされ、デスティネーションIPアドレス903には、参照先のWebサーバ3のIPアドレスがセットされる。ここで、インターネットにおける周知技術により、参照先のURLの一部(ホスト名やドメイン名)から、DNSサーバの処理により、指定URLに相当するIPアドレスが取得される。また、PC1及びサーバ200における通信の設定に従い、PC1からのWebサーバ3への要求が、PC1からサーバグループへの要求となるように、接続先が変換される。本例では、第1要求913のデスティネーションIPアドレス903には、Webサーバ3のIPアドレスから、アドレス変換により、サーバグループのグループIPアドレス614がセットされる。また、セッション番号904には、他の同類の要求と混信しないための識別情報として、本例では“aa”が付与される。またコンテンツ905には、要求内容や参照先となるURLなどが含まれている。
第1応答914は、前記第1要求913に対応して、サーバグループのサーバ200からPC1への、URL参照の代行処理の結果の応答を示す。このソースIPアドレス902には、参照先のWebサーバ3のIPアドレスがセットされ、デスティネーションIPアドレス903は、要求元のPC1のIPアドレスがセットされる。ここで、ソースIPアドレス902には、Webサーバ3のIPアドレスから、アドレス変換により、代行処理するサーバ200の固有IPアドレス612がセットされる場合を示す。またセッション番号904には、前記第1要求913のセッション番号904と同じ値(“aa”)が付与される。またコンテンツ905には、URLに対応したコンテンツデータなどが含まれている。このコンテンツデータは、サーバ200におけるキャッシュデータまたはWebサーバ3から新たに取得したコンテンツデータである。
第2要求915は、PC1からのURL参照要求に応じて、サーバ200からWebサーバ3へ発行されるURL参照要求を示す。このソースIPアドレス902には、要求元のPC1のIPアドレスがセットされ、デスティネーションIPアドレス903には、参照先のWebサーバ3のIPアドレスがセットされる。ここで、ソースIPアドレス902には、PC1のIPアドレスから、アドレス変換により、第1要求913を受け付けて第2要求915の処理を実行するサーバ200の固有IPアドレス612がセットされる場合を示す。また、セッション番号904には、PC1からの第1要求913におけるセッション番号904(“aa”)に、第2要求915の処理を実行するサーバ200の識別情報(サーバID)、例えば固有ホスト名611などが付加され用いられる。またコンテンツ905には、要求内容や参照先となるURLなどが含まれている。
第2応答916は、前記第2要求915に対応して、Webサーバ3からサーバグループのサーバ200への、URL参照処理の応答を示す。このソースIPアドレス902には、参照先のWebサーバ3のIPアドレスがセットされ、デスティネーションIPアドレス903は、要求元のPC1のIPアドレスがセットされる。ここで、デスティネーションIPアドレス903には、PC1のIPアドレスから、アドレス変換により、前記第2要求915の処理を実行したサーバ200の固有IPアドレス612がセットされる。またセッション番号904には、前記第2要求915のセッション番号904及びサーバIDと同じ値が付与される。またコンテンツ905には、URLに対応したコンテンツデータなどが含まれている。このコンテンツデータは、Webサーバ3から新たに取得されるコンテンツデータである。
PC1は、Webサーバ3に対する第1要求913を出す。変換により、グループIPアドレス614を送信先として用いた第1要求913の電文が、サーバグループに対して送信される。いずれかのサーバ200で第1要求913の処理を受け付け、Webサーバ3への参照が必要な場合は、第1要求913から第2要求915に変換し、Webサーバ3に対し第2要求915の電文が出される。Webサーバ3は、第2要求915に応じて、URLで指示されるコンテンツデータを含んだ第2応答916の電文を該当サーバ200へ送信する。該当サーバ200は、Webサーバ3からの第2応答916に応じて、第1応答914に変換し、要求元のPC1への応答とする。前記Webサーバ3への参照が必要ない場合は、該当サーバ200は、キャッシュデータにより第1応答914の電文をPC1へ応答する。
更新日時要求917と更新日時回答918は、サーバ200におけるコンテンツデータのキャッシュを利用するために、URLに対応したコンテンツデータの更新日時をサーバ200からWebサーバ3へ問い合わせて確認するための要求とその回答の電文である。例えばWebで過去に同じドメインやホストのコンテンツデータを参照している場合、同様のデータがサーバ200のキャッシュ用記憶領域にキャッシュデータとして残っている。そのため、PC1から参照要求されているコンテンツデータについて、サーバ200でのキャッシュデータと、Webサーバ3上の最新のコンテンツデータとで、その更新日時が同じ場合は、サーバ200からWebサーバ3へ毎回取得しに行く必要は無い。そのため、本電文により、事前などの契機で、サーバ200から該当ドメインなどのWebサーバ3に対し、コンテンツデータの更新の状態を確認する。
更新日時要求917で、このソースIPアドレス902には、該当サーバ200の固有IPアドレス612がセットされる場合を示す。デスティネーションIPアドレス903には、Webサーバ3のIPアドレスがセットされる。またセッション番号904は、本例ではPC1側とのセッションとは異なる“bb”が付与される。コンテンツ905は、確認対象となるコンテンツデータに対応したURLなどが含まれる。
更新日時回答918で、このソースIPアドレス902には、Webサーバ3のIPアドレスがセットされる。デスティネーションIPアドレス903には、該当サーバ200の固有IPアドレス612がセットされる場合を示す。またセッション番号904は、前記更新日時要求917のものと同じ値(“bb”)が付与される。コンテンツ905は、確認対象となるコンテンツデータの更新日時の情報が含まれる。
URLキャッシュ919は、自サーバにおいてキャッシュ用記憶領域のキャッシュテーブルにキャッシュ情報として保有している自サーバについてのインデックス情報713を、同じサーバグループ内の他サーバ200へ送信してキャッシュ状態を知らせるためのものである。これにより、サーバグループにおいて各サーバ200は、どのサーバ200が、どのURLに対して、最新のコンテンツデータをキャッシュしているか等を知ることができる。このソースIPアドレス902には、該当サーバ200の固有IPアドレス612がセットされる。デスティネーションIPアドレス903には、グループIPアドレス614がセットされる場合を示す。コンテンツ905には、該当サーバ200についてのURLコンテンツキャッシュインデックスj(jは、自サーバに対応したa,b,cのいずれか)が含まれる。サーバ200から本URLキャッシュ919の電文を他サーバ200へ送るタイミングは、第2応答916により新たなURLのコンテンツデータまたは最新の更新日時のコンテンツデータをWebサーバ3から取得して自身のキャッシュ情報を更新した時などである。
本例では、第1応答914、第2要求915等の電文上において、固有IPアドレス612等により、どのサーバ200が具体的に処理を受け付けたか等を知ることができる。サーバ200は、要求に対して、各サーバ200のキャッシュ状態及び負荷状態に応じて自分が処理すべきものか否か判断して、自己責任により処理を遂行することになる。
<処理シーケンス及びフロー>
次に、本システムにおける処理のシーケンス及びフローを説明する。図10は、PC1、同一サーバグループのサーバ200{a,b,c}、及び、Webサーバ3の間での一連の処理及び制御のシーケンスの例を示している。PC1、サーバ200、及びWebサーバ3の間では、前記電文を用いて本シーケンス及びフローに対応した通信及び処理が行われる。
まずステップS1100で、サーバグループにおいて、例えばサーバc(200)は、パワーオンにより稼動状態となった場合、自身における動作状態の変動を通知するための起動完了911の電文を、サーバグループ内の他サーバa及びb(200)に送信する。前記起動完了911の電文を受信したサーバa及びb(200)は、その情報をもとに、自身の動作テーブル7の内容を更新する。
またS1200で、サーバグループにおいて、例えばサーバa(200)は、自身におけるある程度の負荷変動を検出すると、負荷情報912の電文を、サーバグループ内の他サーバb及びc(200)に送信する(S1111)。前記負荷情報812の電文を受信したサーバb及びc(200)は、その情報をもとに、自身の動作テーブル7の内容を更新する(S1121,S1131)。負荷状態や動作状態の変動が発生したサーバ(200)では、自身の動作テーブル7の内容を更新している。上記動作が、常時、サーバグループ内で任意のサーバ200から他サーバ200に対して、変動発生に伴う情報の通知や交換によりお互いに連絡し合うことが行われている。
負荷変動時の負荷情報の交信については、通常処理を妨げるほどに頻繁に発生し過ぎないようにする。例えば、サーバグループにおいて、負荷通知のための閾値の設定を持たせ、サーバ200での負荷変動がその閾値の範囲を越えた場合に負荷情報912の電文を送信するようにする。
次に、S1101で、PC1から第1のURL参照要求処理が行われた場合を示している。PC1のWebブラウザのプログラムから、Webサーバ3に対する第1要求913の電文が発行される。本第1要求913は、アドレスの変換により、サーバグループに対してグループIPアドレス614を用いて送信される。
一方、S1300で、サーバグループの各サーバ200は、第1要求913を受信する処理、及び、自サーバ200でその第1要求913に対応した処理を受け付けるかどうかを動作テーブル7の参照などに基づき判断する処理などを行う(S1112,S1122,S1132)。図14や図15で述べる処理及び制御に従って、いずれかのサーバ200で処理を受け付け、受け付けたサーバ200でWeb参照の代理処理が実行されることになる。
本例では、サーバグループ内で、該当URLに対応したキャッシュデータを保有しておりかつ負荷が低い状態にあるサーバb(200)で処理を受け付ける場合を示している。例えば、第1要求913の受信時の各サーバ200のキャッシュ状態として、サーバa,b(200)は該当キャッシュを保有しており、サーバc(200)は保有していないとする。また、サーバb(200)での該当キャッシュデータは、サーバa(200)での該当キャッシュデータよりもWeb更新日時802が新しいが、Webサーバ3の最新のコンテンツデータの更新日時よりは古いとする。このような状態に従って、処理を受け付けたサーバb(200)が、Webサーバ3から最新のコンテンツデータを取得してPC1へ応答する場合を示す。
上記S1300では、各サーバ200で独立して処理の受け付けに関する判断が行われるので、状況に応じて結果として、1つのサーバ200のみが処理を受け付ける場合以外にも、複数のサーバ200が処理を受け付ける場合や、いずれも受け付けずに再試行が行われる場合などがある。いずれの場合でも、結果として1つのサーバ200との間で実際に処理が行われることになる。
上記S1300において、各サーバ200は、処理受け付けの判断として、動作テーブル7における各サーバ200{a,b,c}についてのインデックス情報713に基づき、自サーバで該当URLに対応したキャッシュを保有しているか、また保有している場合はそのデータが最新のものか、また複数のサーバで保有している場合は自身の負荷が低いか等を確認して、それに基づき自サーバで処理を受け付けるか否かを決める。
本例では、S1122における要求受信及び処理受付の処理において、サーバb(200)は、該当URLのキャッシュデータでグループ内での最新のものを保有しているので、処理受け付けし、更に、そのキャッシュデータがWebサーバ3でのコンテンツデータと同じ最新のものかを確認するために、更新日時要求917の電文をWebサーバ3へ送信している。これに対し、Webサーバ3は、更新日時要求917で指定されるURLに対応したコンテンツデータの更新日時の情報をセットした更新日時回答918の電文を返信する。そしてサーバb(200)は、更新日時回答918から、該当キャッシュデータが最新か古いかを確認する。該当キャッシュデータがWebサーバ3側のコンテンツデータと同じく最新である場合は、本キャッシュデータを用いてPC1へキャッシュ応答として送信することとなる。また、該当キャッシュデータが古い場合は、S1123で示すように、第2要求915を発行して最新のコンテンツデータを取得してS1124でPC1へ応答することとなる。また更に、グループ内のいずれのサーバ200でも該当キャッシュデータを保有していない場合などには、後述するように、各サーバ200の負荷状態についての比較判断に従って、処理を受け付けるかどうかを決めることとなる。
次に、前記S1122により第1要求913に対応した処理を受け付けたサーバb(200)では、S1123で、Webサーバ3への参照が必要な場合に、第2のURL参照要求処理を行う。サーバb(200)は、Webサーバ3に対して第2要求915の電文を送信する。
S1141において、Webサーバ3は、第2要求915に応じて、第2のURL参照応答処理を行う。Webサーバ3は、第2要求915におけるURLで指定されるコンテンツデータを、第2応答916の電文として、該当サーバb(200)へ送信する。一方、サーバb(200)は、第2応答916の電文を受信して最新のコンテンツデータを取得する。
次に、S1124で、サーバb(200)は、第1のURL参照応答処理を行う。サーバb(200)は、Webサーバ3から第2応答916により受信した最新のコンテンツデータを、第1応答914の電文として、PC1に対して送信する。一方、PC1は、第1応答914の電文を受信し、最新のコンテンツデータを取得してWebブラウザで処理する。
続いて、S1700において、サーバb(200)は、キャッシュ状態の更新を通知する処理を行う。前記S1124で、サーバb(200)は、前記S1123でWebサーバ3から受信した最新のコンテンツデータを、自身のキャッシュテーブルに格納してキャッシュ情報を登録/更新する。それと共に、サーバb(200)は、同じサーバグループの他のサーバa,c(200)に対して、自身のキャッシュ情報の更新を通知するために、自サーバについてのインデックス情報713を含んだURLキャッシュ919の電文を作成して、グループIPアドレス614を用いて送信する。本URLキャッシュ919の電文を受信した各サーバa,c(200)は、受信した情報により、自サーバで保有しているキャッシュ情報、すなわち動作テーブル7及びキャッシュテーブル中の該当位置に反映して内容を更新する(S1113,S1133)。これにより、サーバ200間のキャッシュ情報の整合性が保たれる。従って、サーバ200でのキャッシュ状態と負荷状態に応じた処理の受け付けによって、サーバ200間の負荷が調整されることになる。
また、省略したが、前記サーバグループにおけるサーバb(200)が処理を受け付けた時やその処理を完了した時には、それにより当該サーバb(200)で負荷変動が発生し検出される。そのため、前記S1200の処理と同様に、サーバb(200)から負荷情報912を他サーバa及びc(200)に報告し、各動作テーブル7の内容を更新する。
その他のシーケンスとして、PC1と該当サーバ200の間で、処理の受け付けを確認するようにしてもよい。例えば、PC1からの第1要求913に対して、その処理を受け付けたサーバ200は、PC1へ処理受付を表わす電文を返し、更にPC1から該当サーバ200に対して受付応答を表わす電文を返す。このようなシーケンスにより、該当サーバ200での処理の受け付けを確認する。この場合、上記のような受け付け確認のための電文で、該当サーバ200の固有IPアドレス612等を使用する。処理を受け付けたサーバ200の固有IPアドレス612を使用する理由は、サーバ200間での情報の交換の遅れや漏れ等に起因して複数のサーバ200が処理を受け付けた場合にも対応してサーバ200を識別できるようにするためである。上記受け付け確認の必要性は、これらの電文により、複数のサーバ200で同じ処理が実行される頻度を下げているだけである。通信におけるノイズなどにより電文が取りこぼされた場合なども含めて、複数のサーバ200が処理を受け付けた場合も、上記のような仕組みにより処理がなされるようになっている。
図11は、サーバグループのサーバ200{a,b,c}におけるパワーオン動作時の処理の詳細を示すフロー図である。本処理は、前記図10における、他サーバ200へ起動完了911の電文を送信する処理(S1100)に対応している。
ステップS1001で、パワーオンにより起動されたサーバ200(例えばc)は、動作テーブル7における自サーバ200に相当する列の動作状態711を、“OFF”から“ON”にする。また、S1002で、同サーバ200(c)は、同じ列のCPU使用率712を、‘0’にセットする。
次に、S1003で、同サーバ200(c)は、負荷測定部215,監視制御部214,通信制御部213を起動し、これによりサーバグループの監視が行われる状態となる。
次に、S1004で、同サーバ200(c)は、起動完了911の電文を、同一サーバグループ内の他サーバ200(a,b)に対して送信する。これにより、自サーバ200(c)がサーバグループに対して処理提供可能な状態(“ON”)で新規追加されることを知らせる。
一方、図13のS1321でも示すように、サーバグループの各サーバ200(a,b)は、前記起動完了911の電文を受信すると、それにより新規追加されるサーバ200(c)に対して、自身の動作テーブル7の内容を更新すると共に、自身を含む各サーバ200(a,b)の負荷情報を前記負荷情報912の電文により通知する。
次に、S1005で、前記起動完了911を送信したサーバ200(c)は、他サーバ200(a,b)からの負荷情報912の電文の受信を確認する。負荷情報912の電文を受信した場合(S1005−YES)、S1006で、同サーバ200(c)は、受信した負荷情報912の電文におけるコンテンツ905に含まれている各サーバ200(a,b)についての負荷情報に従い、それに対応する自身の動作テーブル7における自サーバの列(701)以外のすべての列(702,703)を更新する。
図12は、サーバグループのサーバ200{a,b,c}における負荷情報の送信処理の詳細を示すフロー図である。本処理は、前記図10における、負荷変動をチェックして他サーバ200へ負荷情報912の電文を送信する処理(S1200)に対応している。
まず、S1201で、各サーバ200は、負荷測定部215により、自サーバ200の負荷情報としてCPU使用率712を測定している。この負荷の測定方法については各種周知技術があるが、例えば、インターバルタイマーを利用して、一定間隔で、OS212の状態を見て、ウェイト状態か否か(すなわち処理待ちか処理中か)を判定したり、CPU自身から発生されるウェイト信号、HOLD信号など特定の信号を監視することにより、CPU201の使用率を計算することにより行う。
S1202で、サーバ200は、直前測定時の自サーバ200の動作テーブル7のCPU使用率712と、S1201で現在測定した値とを比較する。比較に基づき、S1203で、前記測定したCPU使用率712の値が、ある程度の範囲内に収まるかそれ以上に変動しているかを、閾値との比較により判定することで負荷変動をチェックする。なお、上記判断の基準となる閾値について設定可能としてもよい。
前記閾値内の変動の場合(S1203−YES)、S1205で、該当サーバ200は、定められた時間分をウェイト後、S1201へ移り、再度同様の処理を繰り返す。上記定められた時間の値は、ランダム値や一定値などである。
前記閾値以上の変動がある場合(S1203−NO)、S1204において、該当サーバ200は、前記S1201での測定値を、動作テーブル7におけるCPU使用率712の項目の自サーバ200に対応する列へ設定して更新する。
次に、S1206において、該当サーバ200は、負荷変動を検出したことにより、負荷情報912の電文を作成する。すなわち、該当サーバ200は、自身の動作テーブル7における動作状態711及びCPU使用率712の項目における全サーバの列(701〜703)に対応した値を、負荷情報912の電文のコンテンツ905へセットする。なお、この際、CPU使用率712の値のみ使用するようにしてもよい。
次に、S1207において、該当サーバ200は、作成した負荷情報912の電文を、同一サーバグループ内の他サーバ200に対して送信する。
なお、前記各サーバ200の動作テーブル7の情報に関しては、状態変動や情報の通知の遅れ等により、サーバ200間で違いがあり得る。前記他サーバ200から負荷情報912を受信した際に動作テーブル7へ反映する情報の決定においては、例えば、常に受信した最近値を使用すること、あるいは、最近値に限らず重い負荷を示す情報の方を優先して使用すること等により決定してもよい。また例えば、動作テーブル7で記憶する情報として、ある時点の負荷であることを示すタイムスタンプ情報を付加しておき、本タイムスタンプと比較し、新しい値を利用する形式としてもよい。
また、サーバ200間での負荷情報912の授受に関しては、あるサーバ200からサーバグループに対して自サーバ200のみの情報を通知するようにしてもよい。本例では、動作テーブル7における自サーバ200を含むすべてのサーバ200についての負荷情報を他サーバ200へ通知することで、サーバ200間の情報の違いを少なくさせるようにしている。
図13は、サーバグループのサーバ200{a,b,c}における各種コマンド901の電文の受信処理についての詳細を示すフロー図である。
まず、S1302において、電文を受信したサーバ200は、受信した電文のコマンド901が負荷情報912かどうかを判定する。負荷情報912の場合、S1311で、該当サーバ200は、該当電文のコンテンツ905における全サーバについての負荷情報を、動作テーブル7の該当行(711,712)の自サーバ以外の列(701〜703)へセットする。
次に、S1303において、該当サーバ200は、コマンド901が起動完了911かどうか判定する。起動完了911の場合、S1321で、該当サーバ200は、該当電文のコンテンツ905における対象サーバの動作状態の情報を、自身の動作テーブル7における動作状態711の対象列へセットする。
次に、S1304で、該当サーバ200は、コマンド901が第1要求913かどうか判定する。第1要求913の場合、S1341で、図14で示す処理要求受信処理を行う。そしてこの処理後に終了する。
次に、S1305で、該当サーバ200は、コマンド901が第2応答916かどうか判定する。第2応答916の場合、S1331で、該当サーバ200は、図17で後述するURL参照応答処理を行う。
次に、S1306で、該当サーバ200は、コマンド901が更新日時回答918かどうか判定する。更新日時回答918の場合、S1351で、該当サーバ200は、図16で後述するURL参照要求処理を行う。
次に、S1307で、該当サーバ200は、コマンド901がURLキャッシュ919かどうか判定する。URLキャッシュ919の場合、S1361で、該当サーバ200は、そのコンテンツ905に含まれている対象サーバのインデックス情報713を、自身の動作テーブル7の該当行(713)の対象サーバの列へセットする。これにより、自サーバ200で他サーバ200のキャッシュ情報も取得して保持することができる。受信した電文のコマンド901が以上に該当しない場合、何もしないで当該電文を破棄して終了する。
図14は、サーバグループのサーバ200{a,b,c}における処理要求受信処理(S1300,S1112,S1122,S1132,S1341)の詳細を示すフロー図である。サーバ200は、第1要求913で指定されるURLに関して本処理を行う。本処理では、自サーバ200でのキャッシュ状態と負荷状態を判断して、自サーバ200で処理を受け付けるかどうか決定する。
まず、S1401において、サーバ200は、指定URLについて、動作テーブル7における全サーバの列(701〜703)のインデックス情報713内に含まれているURL801から、指定URLと同じものを抽出する検索を行う。この時、全サーバに対応する全列を検索の対象にする。
S1402において、サーバ200は、前記検索の結果、自サーバ内に該当URLに対応したキャッシュ情報及びキャッシュデータが存在し、かつ自サーバに含まれる該当URLのキャッシュにおけるWeb更新日時802が最新かどうかを判定する。
上記判定で、サーバ200は、自サーバの該当キャッシュが最新である場合(S1402−YES)、S1403において、該当URLのWebサーバ3におけるその時点のコンテンツデータの更新日時と比較するために、更新日時要求917の電文を作成し、該当Webサーバ3に対し送信する。
また上記判定で、サーバ200は、自サーバの該当キャッシュが最新でない場合(S1402−NO)、S1404において、動作テーブル7においてサーバグループの他サーバ200の列で該当URLのキャッシュが存在するかどうかを調べる。ここで、他サーバ200が該当URLに対応したキャッシュデータを保有している場合(S1404−YES)、その保有しているサーバ200が自サーバと同様の処理要求受信処理を行っているので、自サーバでは何もせず終了する。
また上記判定で、サーバグループにおける自他の各サーバ200で該当URLのキャッシュを保有していない場合は(S1404−NO)、S1405で、図15で後述するサーバ負荷比較処理において、どのサーバ200が処理を受け付けるべきかを、各サーバ200の負荷状態などに従って決めることになる。
図15は、サーバグループのサーバ200{a,b,c}におけるサーバ負荷比較処理(S1405)の詳細を示すフロー図である。S1503,S1504の処理により、いずれかのサーバ200で処理を受け付けるように制御する例である。
まず、S1501において、サーバ200は、自身の動作テーブル7における全サーバの列の情報を読み出す。
次に、S1502において、サーバ200は、動作テーブル7におけるCPU使用率712の自サーバの列と他のサーバの列との値を比較する。そして、S1503で、自サーバの列のCPU使用率712がサーバグループ内で最小であり、かつ、S1504で、自サーバの列のMACアドレス615の値が最小である、という条件を満たすかどうかを判断する。すなわちサーバグループ内のサーバ200で負荷が最小の状態である1つのサーバを判断する。上記処理を通じて、1つのサーバ200が、第1要求913に対応した処理を受け付ける義務を負うことになる。本例では、グループ内のサーバ200間での特定の優先順位の設定として、MACアドレス615の値を用いている。
上記条件を満たさない場合(S1503−NO,S1504−NO)、該当サーバ200は、処理受け付けせずに終了する。上記条件を満たす場合(S1504−YES)、S1505において、該当サーバ200は、処理を受け付けることに決め、次に続く処理のために第2要求915の電文を作成し、Webサーバ3に対し送信する。
前記S1504でMACアドレス615を使用する理由は、サーバグループで処理を受け付けるサーバ200を決定する場合に、最後にクリンチすることの無いようにするためであって、他サーバ200と一致することのない識別情報であればIPアドレスなど他の情報を用いてもよい。本例では、あらかじめ設定されている所定の規則の例として、設定テーブル6における各サーバ200のMACアドレス615の情報を用いている。
また前記S1503等において、サーバ200の負荷状態を最小値により判断する以外にも、負荷情報がある程度の閾値以下に収まるものを選択すること等により判断してもよい。
また前記処理を受け付けたサーバ200では、ランダムな時間ウェイトして他サーバ200からの電文を傍受監視して他サーバ200で処理を受け付けていないことを確認してから第2要求915の電文を送信するようにしてもよい。
また前記判断の結果、自サーバ200で処理を受け付ける条件が成立しない場合、該当サーバ200は、ランダムな時間分ウェイトして、他サーバ200が処理を受け付けたかどうかを、他サーバ200が送信する電文を傍受監視することによって判断するようにしてもよい。該当サーバ200は、他サーバ200からWebサーバ3への第2要求915等の電文を傍受した場合、他サーバ200での処理受け付けが確認されるので終了する。また、前記ウェイトで電文を傍受しなかった場合、再度、開始に戻って処理受け付けのための判断を再試行するようにしてもよい。この再試行は、サーバグループの全サーバ200が処理を受け付けなくなる場合を防止するための措置である。
また前記電文の傍受により他サーバ200からの応答(処理受け付け)を知る方法以外にも、サーバ200からPC1やWebサーバ3への要求や応答の送信時に、これに合わせて、同じサーバグループ内の他サーバ200に対してマルチキャスト送信も含む明示的な送信を行う方法により、前記応答を知ることとしてもよい。
上記のようなサーバ200での処理受け付けの決定に係わる所定の判断基準や規則に応じて、1つのサーバ200で処理受け付けが行われるように制御している。また複数のサーバ200で処理受け付けが行われる場合も発生し得るが、1つのサーバ200で実際に処理を行わせるように制御している。本例では、サーバ200での処理受け付けの判断で、まずキャッシュ状態を判断し、次に負荷状態を判断して決めている。
またその他、サーバグループにおける自他の複数のサーバ200で該当URLの同じ更新日時のキャッシュデータを保有している場合に、所定の基準や規則に応じて、いずれかのサーバ200で処理を受け付けることに決める。例えば図15と同様の負荷比較処理によって負荷の低い状態にある1つのサーバ200で処理を受け付けるように決める。あるいは各サーバ200に定められたMACアドレス615等の異なる値を比較して決める。
また、条件を満たす複数のサーバ200で処理を受け付けるようにしてもよい。この場合、同じ処理を受け付けて同時平行的に処理させる。この場合でも、PC1では、最終的には、処理結果となる第2応答916を早く返したサーバ200からのデータが採用されることになる。
図16は、サーバグループのサーバ200{a,b,c}における第2のURL参照要求処理(S1123,S1351)を含む処理の詳細フロー図を示す。本処理は、サーバ200で第1要求913の受信及び処理受け付けに応じて行われる第2要求915の処理に対応している。本例では、サーバ200での第2のURL参照要求処理(S1123)は、処理受け付け(S1122)においてキャッシュの更新日時の確認により処理を受け付けることを決めた後、自サーバで最新のコンテンツデータのキャッシュを保有していないと判明した時に実行される。
まず、S1601において、該当サーバ200は、Webサーバ3から受信した更新日時回答918の電文のコンテンツ905に含まれる更新日時の情報と、自サーバに含まれる該当URL801のキャッシュのWeb更新日時802の情報とを比較する。そして、S1602で、前記Webサーバ3から受信した更新日時の情報の方が最新である場合、言い換えれば、自サーバ200で保有している該当キャッシュデータ(ファイル821)が、Webサーバ3で掲示している最新のコンテンツデータより古いことが判明した場合(S1602−YES)、最新のコンテンツデータを参照することに決め、S1603で、サーバ200は、第2要求915の電文を作成して、Webサーバ3へ送信して終了する。
前記S1602で、逆に、前記Webサーバ3から受信した更新日時の情報が、自サーバ200で保有している該当キャッシュデータのWeb更新日時802と同じである場合、言い換えれば、自サーバ200で保有している該当キャッシュデータが、Webサーバ3で掲示している最新のコンテンツデータと同じであることが判明した場合(S1602−NO)、キャッシュ応答することを決める。S1604で、サーバ200は、自サーバでのキャッシュ情報及びキャッシュデータにおいて、キャッシュテーブルにおける該当URL801に対応するHTMLファイル名803及びそのファイル821を使用して、第1応答914の電文を作成し、要求元のPC1へ送信して終了する。
図17は、サーバグループのサーバ200{a,b,c}におけるURL参照応答処理(S1124)を含む処理の詳細を示すフロー図である。本処理は、サーバ200で第2応答916の受信に応じて行われる第1応答914の処理及びURLキャッシュ処理に対応している。
まず、S1701において、該当サーバ200は、Webサーバ3から受信した第2応答916の電文のコンテンツ905に含まれている、該当URLに対応したコンテンツデータを、キャッシュ記憶領域に格納する。すなわち、サーバ200は、受信コンテンツデータについてのキャッシュ情報を、自身のキャッシュテーブルの列(801〜803)に追加して情報を更新し、また受信コンテンツデータをファイル821に格納する。
次に、S1702で、サーバ200は、キャッシュテーブルにおける、前記受信コンテンツデータについての、URL801及びWeb更新日時802を含む情報を、自身の動作テーブル7におけるインデックス情報713の領域に追加して情報を更新する。
次に、S1703で、サーバ200は、前記受信コンテンツデータをもとに、第1応答914の電文を作成し、要求元のPC1へ送信する。PC1では、第1応答914の電文が受信され、Webブラウザ等で処理されることになる。
次に、S1704で、サーバ200は、上記処理で自サーバでのキャッシュ情報を更新したことにより、これをサーバグループの他サーバ200へ通知して他サーバ200の持つキャッシュ情報を更新させるために、URLキャッシュ919の電文を作成し、他サーバ200へ送信する。サーバ200は、URLキャッシュ919の電文のコンテンツ905に、上記処理で更新した自サーバについてのキャッシュ情報(インデックス情報713)を含む情報をセットする。一方、本URLキャッシュ919の電文を受信した他の各サーバ200では、前記S1361の処理が行われキャッシュ情報が更新されることになる。
以上説明したように、本実施の形態によれば、複数のWebサーバ3に対するProxyサーバ機能を持つサーバ200のサーバグループにおいて、グループ内の各サーバ200における最新のキャッシュと負荷の状態をお互いのサーバ200が知り、それに基づき処理を受け付けてWeb参照の代理処理を実行することにより、サーバ200間での最適な負荷配分を自立的に行うことができる。複数のPC1から参照要求が集中したとしても、各サーバ200での判断に従って適切に負荷配分が調整される。また、全体を管理するあるいは処理要求を一次受け付けするような装置を必要とせず、また外付けの負荷分散装置のような特殊な装置を必要とせず、サーバグループ内のサーバ200における処理の負荷分散・均衡化を図ることができる。サーバ200やPC1の数の増減に伴う負荷変動にも対応して、全サーバ200が自立的に負荷を調整していき、常に、全サーバ200でできる限り均等に負荷を持つようにできる。
以上の他に、本実施の形態では、サーバ200として、Webサーバ3に対するProxyサーバ機能を例とし、複数のサーバ200から共通してアクセスされる典型としてWebサーバ3を例にしたが、サーバ200として、その他のアプリケーションに対応したサーバに対しアクセスしてデータや情報をキャッシュする処理を行う機能にも同様に適用可能である。例えば、DB、DNS、電子メール、その他データ処理などの処理を行うサーバに対しアクセスするサーバで、参照したDBデータ、URL情報や通信アドレス情報、電子メールデータ等の情報及びデータをキャッシュする処理を行う場合に可能である。キャッシュ対象は、参照先の識別情報や通信アドレス、参照したデータ及びその更新日時などである。例えばクライアントからの要求に応じてDBサーバに対する参照処理を行うサーバ200とした形態では、本サーバ200で、キャッシュ情報及びデータとして、DBサーバの識別情報やアドレス、DBファイル名、検索キーコード、データの更新日、対応するフィールドの内容などを保有し、キャッシュ情報をグループ内で交換し合い、各サーバ200でDBデータのキャッシュ状態とDB参照処理の負荷状態を判断して、処理を受け付けする。この場合、前記第2要求915はDBアクセス要求となり、前記第2応答916はDBアクセス結果となる。DBアクセス要求にはコンテンツとして例えば検索キーが含まれる。DBアクセス結果のコンテンツは例えばDB検索結果データである。
また、サーバ200の負荷情報としてCPU使用率712を用いたが、その他、サーバ200でPC1から受け付けた処理数や、いわゆるトラフィック量(転送レート等)や、実行ジョブ(サーバ200での処理を分割した単位)数などの他のパラメータを使用してもよい。
また、本例では、負荷分散対象となるサーバ200に関して、同様の性能のブレードサーバ方式を対象にした。これに限らず、本発明の他の実施の形態では、前記ブレードサーバ方式ではなく、スタンドアロン型の複数のサーバ装置や、それぞれ異なる性能の複数のサーバを用いてシステムが構成される。スタンドアロン型の複数のサーバ装置でシステムを構成する場合、前記図1におけるサーバ集合筐体2を除いた同様の構成となる。また上記異なる性能の複数のサーバ、例えばCPU201の処理速度[Hz]が異なる複数のサーバで構成する場合では、負荷情報として前記CPU使用率712などを使用する場合、低い性能のサーバには少ない仕事量を、高い性能のサーバには多くの仕事量を課すような負荷分散の均衡を保たせる。
また、処理を受け付けたサーバ200の識別に関して、固有IPアドレス612を用いる以外には、グループIPアドレス614、セッション番号904、及びサーバIDの組み合わせを用いる等としてもよい。
また、本システム内に1つのサーバグループのみ設定される場合を示したが、例えば、サーバ集合筐体2においてサーバ200の組み合わせにより複数のサーバグループを設定して、各サーバグループにおいて同様に負荷分散することも可能である。
また、本例では、各サーバ200のネットワーク4に対する接続・配線の形式について、マルチドロップ型、すなわち各サーバ200が独立してLAN制御部203によりネットワーク4に対し接続される形式とした。これに限らず、各サーバ200が、ネットワーク4に対し、スイッチやハブやルータやゲートウェイ等の、データ転送の役割を持つ中継部を介在して接続・配線される形式も可能である。すなわち各サーバ200が中継部に接続され、中継部がネットワーク4に対し接続される形式である。例えば、サーバ集合筐体2内にこのような中継部を設けた構成も可能である。この場合でも、各サーバ200間、及び、各サーバ200とPC1との間の通信の電文において、前記グループIPアドレス614が用いられた場合には、前記中継部でその電文が同一サーバグループのサーバ200に対して転送されるように、転送に関する設定を行っておく。これにより同様に負荷分散が実現可能である。
また、起動完了911、負荷情報912、URLキャッシュ919などのサーバ200間で交換する電文のデスティネーションIPアドレスとして、共通のグループIPアドレス614を使用せず、毎回、同じグループの全サーバ200の個別IPアドレス(612)に対して、ユニキャスト通信により、相手を明示的に指定して送る方法でもよい。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
1…PC、2…サーバ集合筐体、3…Webサーバ、4…ネットワーク、6…設定テーブル、7…動作テーブル、101,201…CPU、102,202…メモリ、103…LANボード、104,204…HDD、105…入力制御ボード、106…出力制御ボード、111,211…アプリケーション部、112,212…OS、113,213…通信制御部、114…入力制御部、115…出力制御部、200…サーバ、203…LAN制御部、205…SVP制御部、214…監視制御部、215…負荷測定部、711…動作状態、712…CPU使用率、713…URLコンテンツキャッシュインデックス情報、801…URL、802…Web更新日時、803…HTMLファイル名、821…ファイル。