JP4266786B2 - 情報処理システム及び情報処理装置 - Google Patents

Description

本発明は、例えば、ファイルサーバやＮＡＳ（Network Attached Storage）等としても機能させることができる情報処理システム及び情報処理装置に関する。

ネットワーク上に分散された複数のコンピュータ端末間でデータを共有するために、ファイルサーバが用いられている。初期型のファイルサーバとしては、例えば、汎用ＯＳ（Operating System）に、ＣＩＦＳ（Common Internet File System）やＮＦＳ（Network File System：NFSは米国Sun Microsystems社の商標）等のファイル共有プロトコルを実装したものが知られている。改良されたファイルサーバとしては、ファイル共有サービスに特化した専用のＯＳを用い、複数のファイル共有プロトコル（CIFS、NFS、DAFS（Direct Access File System）等）をサポートしたＮＡＳが知られている。

また、情報処理システムの信頼性を高めたり、負荷分散等を行うために、クラスタシステムが構築されている。クラスタシステムとは、複数のＮＡＳを粗結合させて１つのまとまりを構成したものである。クラスタシステムは、少なくとも２つのＮＡＳを含んで構成される。一方のＮＡＳと他方のＮＡＳとは、定期的にハートビート通信を行うことにより、相互にシステムダウンを監視している。ＮＡＳのシステムダウンは、ハートビート通信の途絶により検出される。いずれか一方のＮＡＳがシステムダウンした場合には、他方のＮＡＳがサービスを引き継ぐようになっている。従って、このような冗長構造を採用することによっても、情報処理システムを構成するＮＡＳの数は増大する。

ところで、クラスタ内のノードに障害が発生した場合に、障害発生時のメモリダンプを共有ディスクに格納させる技術が知られている（特許文献１）。
特開２００３−３００１１号公報

システム管理者は、情報処理システムを構成する全てのＮＡＳの稼働状況を常に把握していることが望ましい。しかし、各ＮＡＳの稼働状況は、各ＮＡＳ毎にそれぞれ独立して管理され保存されている。従って、システム管理者が手動操作によって全てのＮＡＳを巡回しながら各ＮＡＳの稼働状況を確認する際に要する時間については考慮されていなかった。また、過負荷状態になっているＮＡＳの稼働状況を確認するために当該ＮＡＳで実行される処理の負荷についても考慮されていなかった。

本発明は、上記の問題点に鑑みてなされたもので、本発明の目的の一つは、各情報処理装置の負荷状態を一元的に管理できるようにした情報処理システム及び情報処理装置を提供することにある。本発明の目的の一つは、情報処理装置の負荷が増大した場合でも、各情報処理装置の負荷状態を安定的に一元管理することができる情報処理システム及び情報処理装置を提供することにある。本発明の更なる目的は、後述する実施の形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明に従う情報処理システムは、複数の情報処理装置と該各情報処理装置により共有される共有記憶装置とを通信ネットワークを介して双方向通信可能に接続してなる情報処理システムであって、各情報処理装置は、自機の負荷状態に関する負荷情報を生成して共有記憶装置に記憶させる負荷情報格納部と、負荷情報閲覧要求に応じて、共有記憶装置に記憶されている各情報処理装置の負荷情報をそれぞれ読出し、負荷情報閲覧要求の発行元に各負荷情報を提供する負荷情報提供部と、共有記憶装置に記憶されている各負荷情報に基づいて、各情報処理装置のうち、処理代行元の情報処理装置及び処理代行先の情報処理装置をそれぞれ決定する処理代行装置決定部と、自機が処理代行先として決定された場合に、処理代行元として決定された情報処理装置における特定の処理を代行する処理代行部と、自機が処理代行元として決定された場合に、処理代行先として決定された情報処理装置に処理代行を依頼する特定の処理を予め登録しておく代行対象処理登録部と、を備えていることを特徴とする。

情報処理装置は、ＣＰＵ（Central Processing Unit）やメモリ等を備えたコンピュータ装置である。情報処理装置は、ファイル共有機能を備えることも可能であり、例えば、ファイルサーバやＮＡＳとして構成することもできる。共有記憶装置は、例えば、半導体記憶装置やディスク記憶装置等が提供する物理的な記憶領域上に設定される論理的な記憶領域（論理ボリューム）である。各情報処理装置及び共有記憶装置は、例えば、ＬＡＮ（Local Area Network）やインターネット等の通信ネットワークを介して相互に接続されている。なお、各情報処理装置の全部または一部は、一つまたは複数のクラスタにまとめることもできる。各情報処理装置は、負荷情報格納部と、負荷情報提供部と、処理代行装置決定部と、処理代行部と、代行対象処理登録部とを、それぞれ備えている。

負荷情報格納部は、自機の負荷状態に関する負荷情報を生成し、共有記憶装置に記憶させる。例えば、負荷情報格納部は、負荷状態に関する基礎情報を収集し、この基礎情報をさらに統計処理することにより、負荷情報を生成することができる。基礎情報としては、例えば、ＣＰＵ利用率、ファイルアクセス数、記憶装置との間のデータ入出力速度等を挙げることができる。統計処理としては、例えば、最大値、最小値、平均値等を挙げることができる。統計処理された負荷情報を用いることにより、基礎情報をそのまま使用する場合よりも、データサイズを低減できる。

負荷情報提供部は、負荷情報閲覧要求に応じて、共有記憶装置に記憶されている全ての情報処理装置に関する負荷情報を読出し、これら読み出した各負荷情報を負荷情報閲覧要求の発行元に提供する。ここで負荷情報閲覧要求の発行元としては、例えば、システム管理者により操作される管理端末等を挙げることができる。このように、各情報処理装置の負荷情報を共有記憶装置に集中して記憶させ、さらに、各情報処理装置のいずれか１つが有する負荷情報提供部を介して、全ての情報処理装置の負荷情報を閲覧可能とする。これにより、システム管理者は、任意の１つの情報処理装置にアクセスするだけで、全ての情報処理装置の負荷状態を把握することができる。ここで、例えば、負荷情報提供部は、各負荷情報をウェブヴラウザで閲覧可能な形態で提供することもできる。ウェブヴラウザで閲覧可能な形態としては、例えば、ＨＴＭＬ（HyperText Markup Language）、ＸＭＬ（eXtensible Markup Language）、ＳＧＭＬ（ Standard Generalized Markup Language）等を挙げることができる。これにより、ウェブヴラウザが実装されているだけの管理端末を用いて、全ての情報処理装置の負荷状態を監視することができる。このような管理端末としては、例えば、パーソナルコンピュータや携帯情報端末、携帯電話等を挙げることができる。

処理代行装置決定部は、共有記憶装置に記憶されている各負荷情報に基づいて、各情報処理装置のうち、処理代行元の情報処理装置及び処理代行先の情報処理装置をそれぞれ決定する。処理代行元に決定された情報処理装置で行われている処理の少なくとも一部は、処理代行先に決定された情報処理装置の処理代行部により代行される。このような自立的な負荷分散作用により、ある情報処理装置に発生した高負荷状態を低減し、情報処理システムの安定性を図ることができる。

ここで、例えば、処理代行装置決定部は、最も高負荷の情報処理装置を処理代行元として決定し、最も低負荷の情報処理装置を処理代行先として決定できる。また、処理代行装置決定部は、最も高負荷の情報処理装置が所定の上限値を上回っている場合に処理代行元の情報処理装置として決定し、最も低負荷の情報処理装置が所定の下限値を以下である場合に処理代行先の情報処理装置として決定することもできる。さらに、処理代行装置決定部は、所定時間毎に、処理代行元の情報処理装置及び処理代行先の情報処理装置をそれぞれ決定することもできる。ここで、留意すべきは、各情報処理装置の処理代行装置決定部は、自機のみに注目して処理代行元及び処理代行先を決定するのではなく、情報処理システム全体の中で自立的で公平に処理代行元及び処理代行先を決定する点にある。処理代行装置決定部は、クラスタを超えて、処理代行元及び処理代行先を決定できる。

処理代行元の情報処理装置及び処理代行先の情報処理装置の対応関係を管理するための代行関係管理テーブルを共有記憶装置に格納しておけば、処理代行装置決定部は、各負荷情報及び代行関係管理テーブルに基づいて、処理代行元の情報処理装置及び処理代行先の情報処理装置をそれぞれ決定することもできる。

処理代行部により代行される特定の処理は、負荷情報格納部により実行される処理の全部または一部とすることができる。これにより、情報処理装置の負荷が増大した場合でも、処理代行先の情報処理装置によって、処理代行元の情報処理装置の負荷状態を監視することができる。

代行対処理処理登録部は、処理代行先の情報処理装置に処理の代行を依頼する特定の処理について予め登録しておく。処理代行先の情報処理装置は、予め登録された特定の処理のみを代行すればよい。ここで、例えば、代行対象処理登録部は、特定の処理をスケジューリングテーブルに予め登録しておくことができる。そして、処理代行先の情報処理装置の処理代行部は、スケジューリングテーブルの読み込み権限を専有することにより、スケジューリングテーブルに基づいて特定の処理を行う。処理代行装置決定部により処理代行先の決定が解除された場合には、処理代行先の処理代行部は、スケジューリングテーブルの読み込み権限を放棄することができる。

以下、図１〜図１１に基づき、本発明の実施形態を説明する。
本発明に係る情報処理システムは、複数のサーバと、これら各サーバにより共有される共有記憶装置と、各サーバを管理するための管理端末とを通信ネットワークを介して双方向通信可能に接続して構成される。

そして、各サーバは、負荷情報格納部と、負荷情報提供部と、処理代行サーバ決定部と、処理代行部と、代行対象処理登録部とを、それぞれ備えている。これら各部は、例えば、エージェントプログラムのような形態で各サーバに常駐する。

ここで、詳細はさらに後述するが、負荷情報格納部は、自機の負荷状態に関する基礎情報を収集し、この基礎情報を統計処理することにより負荷情報を生成し、この負荷情報を共有記憶装置に記憶させる機能を実現する。負荷情報提供部は、管理端末からの負荷情報閲覧要求に応じて、共有記憶装置に記憶されている各サーバの負荷情報をそれぞれ読出し、管理端末に各負荷情報を提供する機能を実現する。また、処理代行サーバ決定部は、所定時間毎に共有記憶装置に記憶されている各負荷情報に基づいて、各サーバのうち、最も高負荷のサーバを処理代行元として、最も低負荷のサーバを処理代行先として、それぞれ決定する機能を実現する。処理代行部は、自機が処理代行先として決定された場合に、処理代行元として決定されたサーバの負荷情報格納部の処理を代行する機能を実現する。代行対象処理登録部は、自機が処理代行元として決定された場合に、処理代行先として決定されたサーバに処理代行を依頼する負荷情報格納部の処理を予め登録しておく機能を実現する。

図１は、本実施例による情報処理システムの全体概要を示すブロック図である。この情報処理システムは、それぞれ後述するように、「負荷情報閲覧要求の発行元」に該当する管理端末１０と、「サーバ」または「情報処理装置」に該当する複数のサーバ２０（１）〜２０（ｎ）と（特定のサーバを示さない場合は、「サーバ２０」と呼ぶ）、「共有記憶装置」に該当する共有ＬＵ（Logical Unit）４０とを備えて構成されている。これら管理端末１０，各サーバ２０，共有ＬＵ４０は、例えば、ＬＡＮ、ＷＡＮ（Wide Area Netwrok）、インターネット等の通信ネットワークＣＮを介して、相互に接続されている。この場合、管理端末１０と各サーバ２０との間のデータ通信は、例えば、TCP/IP（Transmission Control Protocol/Internet Protocol）に従う。なお、管理端末１０から共有ＬＵ４０に直接アクセス可能な構成とする必要はない。

管理端末１０は、例えば、情報処理システムのシステム管理者により操作されるコンピュータ装置である。管理端末１０は、例えば、パーソナルコンピュータ、ワークステーション、携帯情報端末、携帯電話等のようなデータ通信可能なコンピュータ装置として構成される。管理端末１０には、少なくともウェブヴラウザ１１が実装されている。このウェブヴラウザ１１は、例えば、ＨＴＭＬ、ＸＭＬ、ＳＧＭＬ等のマークアップ言語で記述されたファイルを閲覧することができる。

各サーバ２０は、例えば、ＳＡＮ（Storage Area Network）や専用回線等を介して、ローカルＬＵ３０とそれぞれ接続されている。各ローカルＬＵ３０は、例えば、ハードディスク装置、光ディスク装置、半導体メモリ装置等の物理的な記憶装置上に構成された論理的な記憶領域（論理ボリューム）である。各サーバ２０は、それぞれのローカルＬＵ３０を用いて、ファイル共有サービスを提供することができる。各サーバ２０には、それぞれ同一構成の処理部２１〜２６が実装されている。これらの処理部２１〜２６は、それぞれ所定のプログラムが実行されることにより、それぞれの機能を実現する。なお、各処理部２１〜２６の全部または一部、あるいは処理部の一部分は、ハードウェア回路として実現可能な場合がある。

負荷情報格納部２１は、負荷情報格納機能を実現する。負荷情報格納プログラムがサーバ２０上で実行されることにより、サーバ２０は負荷情報格納部２１として機能する。詳細はさらに後述するが、負荷情報格納部２１は、定期的に、自身が実装されているサーバ２０の負荷に関する情報を収集して編集し、この情報を共有ＬＵ４０の所定ディレクトリに格納させる。

負荷情報採集部２２は、負荷情報採集機能を実現する。負荷情報採集プログラムがサーバ２０上で実行されることにより、サーバ２０は負荷情報採集部２２として機能する。負荷情報採集機能とは、管理端末１０のウェブヴラウザ１１からアクセス要求を受け付けた場合に、共有ＬＵ４０に格納されている全ての負荷情報を読み出す機能である。また、負荷情報ファイル作成部２３は、負荷情報ファイル作成機能を実現する。負荷情報ファイル作成プログラムがサーバ２０上で実行されることにより、サーバ２０は負荷情報ファイル作成部２３として機能する。負荷情報ファイル作成機能とは、負荷情報採集部２２により採集された各負荷情報を、ウェブヴラウザ１１で閲覧可能な形態に編集して、ウェブヴラウザ１１に提供する機能である。負荷情報ファイル作成部２３は、例えば、ウェブページを自動生成するためのＣＧＩ（Common Gateway Interface）プログラムをサーバ２０上で実行させることにより、実現することができる。負荷情報採集部２２及び負荷情報ファイル作成部２３は、「負荷情報提供部」に該当する。

処理代行サーバ決定部（以下、代行決定部）２４は、処理代行元サーバ及び処理代行先サーバをそれぞれ決定する機能を実現する。代行決定部２４は、「処理代行ファイルサーバ決定部」または「処理代行装置決定部」に該当する。代行決定プログラムがサーバ２０上で実行されることにより、サーバ２０は代行決定部２４として機能する。詳細はさらに後述するが、代行決定部２４は、各サーバ２０のそれぞれ負荷状態に基づいて、高負荷のサーバ２０を処理代行元として、低負荷のサーバ２０を処理代行先として、それぞれ決定する機能を実現する。

処理代行部２５は、処理代行機能を実現するもので、「処理代行部」に該当する。処理代行プログラムがサーバ２０上で実行されることにより、サーバ２０は処理代行部２５として機能する。処理代行機能とは、自身が実装されているサーバ２０が処理代行先として決定された場合に、処理代行元サーバ２０の特定の処理を肩代わりして実行する機能である。

代行対象処理スケジューリング部（以下、スケジューリング部）２６は、「代行対象処理登録部」または「代行対象処理登録部」に該当する。代行対象処理スケジューリングプログラムがサーバ２０上で実行されることにより、サーバ２０はスケジューリング部２６として機能する。スケジューリング部２６は、代行先サーバ２０に代行を依頼する処理を、代行対象処理スケジューリングテーブル（以下、スケジューリングテーブル）２７に予め登録する。スケジューリング部２６は、負荷情報格納部２１の処理を代行対処理処理として、スケジューリングテーブル２７に予め登録する。これ以外に、通常の業務アプリケーションサービス（例えば、電子メールサービス、ビデオ配信サービス、ドキュメント管理サービス等）の一部を代行対象処理として、スケジューリングテーブル２７に登録することもできる。通常時において、スケジューリングテーブル２７に登録された処理は、そのサーバ２０により実行される。高負荷時においては、スケジューリングテーブル２７に登録された処理は、代行先のサーバ２０により実行される。

共有ＬＵ４０は、例えば、ハードディスク装置、光ディスク装置、半導体メモリ装置等の物理的な記憶装置上に構成された論理的な記憶領域（論理ボリューム）である。共有ＬＵ４０には、例えば、負荷情報管理テーブル４１と、代行関係管理テーブル４２とが記憶されている。負荷情報管理テーブル４１には、各サーバ２０からの負荷情報がそれぞれ登録される。また、代行関係管理テーブル４２には、代行元サーバ２０及び代行先サーバ２０に関する情報が登録されている。

なお、負荷情報管理テーブル４１は、必ずしもテーブル形式で存在する必要はない。例えば、共有ＬＵ４０に各サーバ２０の専用ディレクトリをそれぞれ設けておき、各サーバ２０は、それぞれの負荷情報を専用ディレクトリに格納していく構成でもよい。また、代行関係管理テーブル４２は、必ずしも必要ではない。

共有ＬＵ４０及び各ローカルＬＵ３０は、それぞれ物理的に離れた場所に設置することもできるし、あるいは同一のストレージサブシステム内に設けることもできる。即ち、ストレージサブシステム内に設定された１つの論理ボリュームを共有ＬＵ４０として用い、他の幾つかの論理ボリュームをそれぞれのサーバ２０にネットワークマウントすることにより、ローカルＬＵ３０としてもよい。

図２（ａ）は、負荷情報管理テーブル４１の記憶内容を、ウェブヴラウザ１１で閲覧する様子を示す模式図である。ウェブヴラウザ１１には、情報処理システムに参加する各サーバ２０の負荷情報が、一覧形式で表示される。負荷情報は、ＣＰＵ利用率やアクセス数等の基礎情報を統計処理することにより、生成される。統計処理の方法としては、例えば、最大値、最小値、平均値等を挙げることができる。

図２（ａ）に示す例では、各サーバ２０の負荷情報が、最大値、最小値及び平均値として表示されている。ここで、負荷情報は、基礎情報を統計的に処理して得られる数値であり、本実施例では、値「１００」が正常稼働時の上限値となるように調整されている。なお、「１００」は一例であって、本発明はこれに限定されない。また、数値表示ではなく、例えば、負荷情報を棒グラフ等のように視覚化、図形化して表示してもよい。さらに、例えば、高負荷状態の場合は赤色、適正状態の場合は緑色、低負荷状態の場合は青色等のように、負荷のレベルに応じてグラフや数値の色彩を変化させてもよい。

図２（ｂ）に示す代行関係管理テーブル４２は、情報処理システム内における代行関係を管理している。この代行関係管理テーブル４２は、例えば、代行先サーバ（処理を肩代わりするサーバ）を特定するための情報（例えば、ＩＰアドレス等）と、代行元サーバ（処理の肩代わりを依頼するサーバ）を特定するための情報と、代行される処理内容と、代行期間とを対応付けることにより構成される。

図中では、１組の代行関係についてのみ示されているが、複数組の代行関係を管理することもできる。さらに、過去に実施された代行関係を、履歴として所定期間保存することも可能である。代行関係の履歴ファイルを保存することにより、情報処理システムのメンテナンス計画や設備改善計画に活かすことができる。また、図２（ｂ）に示す以外の他の情報を合わせて管理してもよい。

代行関係管理テーブル４２の「代行内容」の欄には、代行先サーバにより代行されている処理内容が記録される。本実施例では、負荷情報に関する処理が代行される。これにより、代行元サーバが高負荷状態になった場合でも、この高負荷状態のサーバの負荷情報を共有ＬＵ４０に集約して一元的に管理することができる。代行関係管理テーブル４２の「代行期間」の欄には、代行先サーバによる代行処理の期間が記録される。本実施例では、後述のように、所定サイクルで代行関係の見直しが行われる。

図３は、スケジューリングテーブル２７の一例を示す説明図である。図３に示すスケジューリングテーブル２７は、第２のサーバ（図中、「サーバ２」と表示）２０（２）に登録されているものである。以下の説明では、第２のサーバ２０（２）に所定値以上の高負荷状態が発生し、サーバ２０（２）の処理の一部を第１のサーバ（図中、「サーバ１」と表示）２０（１）に代行させる場合を例に挙げて説明する。図３に示すスケジューリングテーブル２７は、サーバ２０（２）の処理が代行される前の状態を示している。

スケジューリングテーブル２７には、例えば、各処理（図中、「ＪＯＢ」と表示）をそれぞれ識別するための処理識別番号（図中、「ＩＤ」と表示）と、代行可能な各処理の内容（図中、「ＪＯＢ」と表示）と、各処理の実行ステータスを示すフラグ情報（図中、「ＳＴＡＴ」と表示）と、各処理を実行した装置名（図中、「EXECUTOR」と表示）とが、それぞれ対応付けられている。

処理識別情報（ＩＤ）には、例えば、連続した番号が用いられる。図３に示す例では、スケジューリングテーブル２７の一部が抜き出されて表示されているため、「１０１０」番目の処理から始まっている。代行可能な処理内容（ＪＯＢ）として、本実施例では、７種類の処理を例示する。そして、これら７種類の処理は、大きく２種類の処理群に分けることができる。第１の種類の処理群は、基礎情報の収集格納を行うもので、第１の処理〜第４の処理から構成される。第１の処理は、ＣＰＵ利用率の採集処理である（処理識別番号１０１０，１０１６等）。ＣＰＵ利用率の採集処理とは、サーバ２０（２）のメインプロセッサの稼働率を収集する処理である。なお、サーバ２０（２）が複数のマイクロプロセッサを搭載する場合、メインプロセッサの利用率だけではなく、他のマイクロプロセッサの全部または一部の利用率をそれぞれ採集するようにしてもよい。第２の処理は、アクセス数の採集処理である（処理識別番号１０１２，１０１８等）。アクセス数の採集処理とは、サーバ２０（２）に対するファイルアクセス要求の数を収集する処理である。第３の処理は、Ｉ／Ｏ速度の測定処理である（処理識別番号１０１４，１０２０等）。Ｉ／Ｏ速度の測定処理とは、ファイルアクセス要求に応答するためのデータ入出力処理の速度を収集する処理である。第４の処理は、ローカルＬＵ３０への格納である（処理識別番号１０１１，１０１３等）。ローカルＬＵ３０への格納処理とは、収集したＣＰＵ利用率、アクセス数及びＩ／Ｏ速度を、ローカルＬＵ３０の所定領域に格納させる処理である。

ＣＰＵ利用率の採集処理、アクセス数の採集処理及びＩ／Ｏ速度の測定処理は、負荷情報を生成するための基礎的な情報（以下、基礎情報とも呼ぶ）である。これら各基礎情報を採取するたびに、ローカルＬＵ３０への格納処理が実行される。ＣＰＵ利用率の採集及びローカルＬＵ３０への格納と、アクセス数の採集及びローカルＬＵ３０への格納と、Ｉ／Ｏ速度の測定及びローカルＬＵ３０への格納とが、１セットの基礎情報収集格納処理を構成する。この１セットの基礎情報収集格納処理が、繰り返し行われる。なお、基礎情報としては、この他に、例えば、キャッシュメモリの空き容量、ネットワークトラフィック等を採用してもよい。

基礎情報の収集及び格納が所定量行われると、第２の種類の処理群が実行される。この第２の種類の処理群は、負荷情報の生成及び格納を行うもので、第５の処理〜第７の処理から構成される。第５の処理は、ローカルＬＵ３０に格納された基礎情報（ＣＰＵ利用率、アクセス数、Ｉ／Ｏ速度）を読み出す処理である（処理識別番号１０２８）。第６の処理は、ローカルＬＵ３０から読み出された基礎情報に基づいて予め定められた所定の統計処理を行うことにより、負荷情報を生成する処理である（処理識別番号１０２９）。第７の処理は、生成された負荷情報を共有ＬＵ４０の所定領域に格納させる処理である（処理識別番号１０３０）。

このように、複数回の基礎情報収集格納処理が実行されて、負荷情報を生成するのに必要なだけの基礎情報がローカルＬＵ３０内に蓄積されると、負荷情報生成格納処理が開始される。そして、負荷情報生成格納処理により、負荷情報が共有ＬＵ４０に格納されると、一連の処理が完了する。一連の処理とは、基礎情報収集格納処理及び負荷情報生成格納処理である。そして、この一連の処理が何度も繰り返される。ここで、注目すべき点は、基礎情報それ自体は、各サーバ２０のローカルＬＵ３０に格納され、基礎情報から生成された負荷情報のみが共有ＬＵ４０に格納される点である。これにより、生データである基礎情報をそのまま共有ＬＵ４０に格納する場合に比べて、記憶領域の消費量を低減することができ、また、負荷情報ファイル作成部２３により、負荷情報をウェブヴラウザ１１に提供する場合の処理負荷を少なくすることができる。

実行ステータスフラグ（ＳＴＡＴ）は、各処理の実行状況を示すもので、本実施例では、例えば、４種類のステータスを識別できるようになっている。例えば、実行ステータスフラグに「０」がセットされている処理は、「未実行」であることを示す。実行ステータスフラグに「１」がセットされている処理は、「実行済」であることを示す。実行ステータスフラグに「２」がセットされている処理は、「自機（図３に示す例ではサーバ２０（２））で実行中」であることを示す。実行ステータスフラグに「３」がセットされている処理は、「代行先サーバにより実行中」であることを示す。

実行元装置名（EXECUTOR）には、その処理を実行したサーバ２０の装置名や装置番号等が記録される。本実施例の場合は、サーバ２０（２）の処理をサーバ２０（１）が代行する場合を説明するので、実行元装置名には、サーバ２０（２）またはサーバ２０（１）のいずれかの装置名が登録される。

図４には、ある時点で代行処理が開始された場合のスケジューリングテーブル２７が示されている。図４に示す例では、図中黒矢印で示すように、処理識別番号１０３０の実行を完了した時点で、サーバ２０（２）に高負荷状態が発生し、処理識別番号１０３１の時点で、サーバ２０（２）の処理をサーバ２０（１）が代行する様子が示されている。

従って、処理識別番号１０３１のＣＰＵ利用率の採集処理は、サーバ２０（１）により代行され、「実行済」を示すフラグ（「１」）がセットされている。そして、続く処理識別番号１０３２のローカルＬＵ３０への格納処理には、サーバ２０（１）によって実行されている旨を示すフラグ（「３」）がセットされている。さらに続く処理識別番号１０３３及び１０３４には、それぞれ未実行を示すフラグ（「０」）がセットされている。詳細は後述するが、スケジューリングテーブル２７に登録されているサーバ２０（２）の処理をサーバ２０（１）が代行する場合、スケジューリングテーブル２７へのアクセス権は、代行先であるサーバ２０（１）が取得する。従って、サーバ２０（２）は、スケジューリングテーブル２７を読み込んで、そこに登録された処理を行うことができなくなる。サーバ２０（２）の負荷が低下して代行関係が解除されると、スケジューリングテーブル２７のアクセス権は、サーバ２０（１）からサーバ２０（２）に返還される。

次に、本実施例の作用について説明する。図５は、負荷情報の生成から負荷情報の一元管理までの全体動作を示す説明図である。図５では、第１のサーバ２０（１）を例に挙げて説明するが、いずれのサーバ２０でも同様である。

図１には示されていないが、各サーバ２０は、それぞれＯＳ２８及びファイル共有プログラム２９を備えている。ＯＳ２８は、例えば、ファイル共有サービスに特化した専用ＯＳとして構成可能である。ファイル共有部２９は、図外のクライアント端末に対して、所定のファイル共有プロトコルに従ったファイル共有サービスを提供する。

負荷情報格納部２１は、定期的に、ＯＳ２８やファイル共有プログラム２９から、ＣＰＵ利用率やアクセス数等の基礎情報を収集している（Ｓ１）。なお、例えば、図示を省略するが、負荷情報格納部２１は、例えば、入出力専門プロセッサ（Ｉ／Ｏプロセッサ）やメモリコントローラ等の他の回路または部から、基礎情報を収集することもできる。

負荷情報格納部２１は、収集した基礎情報をローカルＬＵ３０の所定領域に格納する（Ｓ２）。ローカルＬＵ３０内には、基礎情報ファイル３１が保存される。負荷情報格納部２１は、所定量の基礎情報が収集されると、ローカルＬＵ３０から基礎情報を読み出す（Ｓ３）。負荷情報格納部２１は、基礎情報を統計処理することにより、負荷情報を生成する（Ｓ４）。このように基礎情報を加工して得られた負荷情報のデータサイズは、負荷情報を生成するために用いられた全基礎情報の合計データサイズよりも小さくなる。負荷情報格納部２１は、生成された負荷情報を共有ＬＵ４０に格納させる（Ｓ５）。

システム管理者は、定期的または不定期に、情報処理システムを構成する各サーバ２０の負荷状況を把握し、システムの維持に努めている。システム管理者は、管理端末１０のウェブヴラウザ１１を介して、任意の時点で、任意のサーバ２０（図５の例では、サーバ２０（１））にアクセスし、負荷情報ファイルの転送を要求する（Ｓ６）。なお、管理端末１０からサーバ２０にログインする際には、例えば、ユーザ名やパスワード等の照合による所定の認証処理を行うことができる。この認証処理は、例えば、指紋、声紋、虹彩等の生体情報の照合を加えても良い。

負荷情報採集部２２は、ウェブヴラウザ１１からの転送要求を受け付けると、共有ＬＵ４０に蓄積された全ての負荷情報を読み出す（Ｓ７，Ｓ８）。負荷情報採集部２２は、ウェブヴラウザ１１からの転送要求を受け付けたサーバ２０（１）以外のその他のサーバ２０を含めて、全てのサーバ２０に関する負荷情報を読み出す。共有ＬＵ４０から読み出された全てのサーバ２０に関する負荷情報は、負荷情報採集部２２から負荷情報ファイル作成部２３に引き渡される（Ｓ９）。

負荷情報ファイル作成部２３は、入力された全ての負荷情報に基づいて、ウェブヴラウザ１１により閲覧可能な形態の負荷情報ファイルを生成し、ウェブヴラウザ１１に送信する（Ｓ１０）。ウェブヴラウザ１１により閲覧可能な形態のファイルとしては、例えば、ＨＴＭＬやＸＭＬ等を挙げることができる。ウェブヴラウザ１１に表示される負荷情報の一覧は、図２に示すような構成である。これにより、システム管理者は、各サーバ２０にそれぞれ個別にアクセスすることなく、全てのサーバ２０の負荷状況を把握することができる。

図６は、高負荷のサーバ２０の処理を低負荷のサーバ２０が代行する場合の全体動作を示す説明図である。図６では、第２のサーバ２０（２）が高負荷状態に、第１のサーバ２０（１）が低負荷状態になっている。そして、図６では、第３のサーバ２０（３）が各サーバ２０（１），２０（２）の負荷状態に基づいて、代行元サーバ及び代行先サーバを決定する場合が示されている。但し、代行関係を決定するサーバは、代行元サーバまたは代行先サーバが兼任することもできる。本実施例では、情報処理システムに参加する全てのサーバ２０の負荷状態に基づいて、システム全体として最も効果的に代行関係が成立するように、代行元サーバ及び代行先サーバを公正に決定する。従って、代行当事者のサーバが代行関係を決定しても特に不都合は生じない。

サーバ２０（３）は、定期的に、共有ＬＵ４０の負荷情報管理テーブル４１にアクセスすることにより、高負荷状態のサーバ２０が出現していないかを監視している（Ｓ１１，Ｓ１２）。サーバ２０（３）の代行決定部２４は、負荷情報管理テーブル４１の最新内容に基づいて、所定の上限値以上の高負荷状態となっているサーバ（サーバ２０（２））を検出する（Ｓ１３）。また、代行決定部２４は、負荷情報管理テーブル４１の最新内容に基づいて、所定の下限値以下の低負荷状態となっているサーバ（サーバ２０（１））を検出する（Ｓ１４）。上限値以上の高負荷状態のサーバ２０（２）と、下限値以下の低負荷状態のサーバ２０（１）との両方が検出された場合、代行決定部２４は、高負荷のサーバ２０（２）を代行元サーバに決定し、低負荷のサーバ２０（１）を代行先サーバに決定する（Ｓ１５）。

サーバ２０（３）の代行決定部２４は、代行先として決定されたサーバ２０（１）に対し、この決定（代行先決定通知）を通知する（Ｓ１６）。この通知は、例えば、サーバ２０（３）からサーバ２０（１）への直接的なメッセージで実現できる。あるいは、共有ＬＵ４０の所定領域を介して、サーバ２０（３）からサーバ２０（１）に対し、決定を通知する構成でもよい。この代行先決定通知には、例えば、代行先サーバ２０（１）を特定するための情報と、代行元サーバ２０（２）を特定するための情報とが含まれている。

代行先として選択されたサーバ２０（１）は、サーバ２０（３）からの代行先決定通知に基づいて、代行元サーバ２０（２）の処理を一部肩代わりする（Ｓ１９）。具体的には、代行先サーバ２０（１）の処理代行部２５は、代行元サーバ２０（２）のスケジューリングテーブル２７の読み込みロックを取得し、代行元サーバ２０（２）が自身のスケジューリングテーブル２７を参照できないようにする（Ｓ１７）。このように、テーブルロックを設定した後で、処理代行部２５は、代行元サーバ２０（２）のスケジューリングテーブル２７を参照し（Ｓ１８）、未処理のタスク（ＪＯＢ）を順番に実行していく（Ｓ１９）。処理代行部２５は、自身が実行する処理のステータスフラグ（ＳＴＡＴ）を更新する（Ｓ２０）。これにより、サーバ２０（１）の処理代行部２５により実行された処理の実行ステータスフラグは、「０」→「３」→「１」へと変化する。

より詳しくは、代行先サーバ２０（１）が、代行元サーバ２０（２）のスケジューリングテーブル２７に従って処理を代行する場合、代行元サーバ２０（２）のローカルＬＵ３０は、代行元サーバ２０（２）からアンマウントされる。そして、代行元サーバ２０（２）のローカルＬＵ３０は、代行先サーバ２０（１）にマウントされる。これにより、代行先サーバ２０（１）は、代行元サーバ２０（２）のローカルＬＵ３０を用いて、代行元サーバ２０（２）の処理を肩代わりすることができる。代行先サーバ２０（１）により代行される処理は、図３及び図４と共に述べたように、基礎情報の収集格納処理と、負荷情報の生成格納処理である。

次に、個別の処理内容について詳細を説明する。図７は、負荷情報格納部２１により実行される基礎情報収集格納処理を示す。この基礎情報の採集及びローカルＬＵ３０への格納は、全てのサーバ２０においてそれぞれ実行されるものである。なお、後述する各処理も、原則として全てのサーバ２０において実行され得る。

まず、負荷情報格納部２１は、予め設定された所定時間ｔ１が経過したか否かを監視している（Ｓ３１）。この所定時間ｔ１は、基礎情報の採集サイクルを規定する時間である。所定時間ｔ１は、例えば、サーバ２０に大きな負荷をかけないように、そして、必要なだけの基礎情報を収集できるように、設定される。

所定時間ｔ１が経過すると（S31:YES）、負荷情報格納部２１は、ＣＰＵ利用率やアクセス数等の最新の基礎情報を収集する（Ｓ３２）。負荷情報格納部２１は、ローカルＬＵ３０にアクセスし（Ｓ３３）、最新の基礎情報をローカルＬＵ３０の所定の場所に格納する（Ｓ３４）。負荷情報格納部２１がアクセスするローカルＬＵ３０は、収集した基礎情報に対応するサーバ２０のローカルＬＵ３０である。即ち、代行先サーバ２０によって負荷情報の収集及び格納処理が代行されている場合、代行先サーバに固有のローカルＬＵ３０ではなく、代行元サーバ２０のローカルＬＵ３０に基礎情報が格納される。なお、例えば、再びＳ３４に戻る時に、所定時間ｔ１を刻むタイマをリスタートさせる。

図８は、負荷情報格納部２１により実行される負荷情報生成格納処理を示す。まず、負荷情報格納部２１は、予め設定された所定時間ｔ２が経過したか否かを監視している（Ｓ４１）。この所定時間ｔ２は、負荷情報の生成サイクルを規定する時間である。この所定時間ｔ２は、例えば、所定時間ｔ１と同様に、サーバ２０に大きな負担とならず、かつ、情報処理システムの管理上必要な周期で負荷情報が収集されるように、設定される。

所定時間ｔ２が経過すると（S41:YES）、負荷情報格納部２１は、ローカルＬＵ３０にアクセスして（Ｓ４２）、ローカルＬＵ３０に格納されている基礎情報を読み出す（Ｓ４３）。負荷情報格納部２１は、読み出された基礎情報を加工処理することにより、負荷情報を生成する（Ｓ４４）。即ち、負荷情報格納部２１は、例えば、多種類かつ複数の基礎情報を統計的に処理することにより、サーバ２０の負荷状態を示す負荷値を生成する。この統計処理された負荷情報（負荷値）は、例えば、最大値、最小値、平均値等のように生成される。負荷情報格納部２１は、負荷情報を生成すると、共有ＬＵ４０にアクセスし（Ｓ４５）、負荷情報管理テーブル４１に負荷情報を登録する（Ｓ４６）。なお、例えば、再びＳ４１に戻る時に、所定時間ｔ２をカウントするタイマをリスタートさせる。

図９は、代行決定部２４により実行される代行元サーバ及び代行先サーバの決定処理を示す。代行決定部２４は、予め設定された所定時間ｔ３が経過したか否かを監視している（Ｓ５１）。この所定時間ｔ３は、代行関係を決定するサイクル、即ち、代行関係を見直すサイクルを規定する時間である。所定時間ｔ３は、例えば、サーバ２０に大きな負担をかけず、かつ、代行先サーバ２０に長期間の代行を強いることがないように、設定される。なお、上述した各所定時間ｔ１〜ｔ３は、固定値である必要はなく、状況に応じて適宜調節するようにしてもよい。また、各所定時間ｔ１〜ｔ３は、それぞれ異なる値である必要もない。

所定時間ｔ３が経過すると（S51:YES）、代行決定部２４は、代行元サーバ２０及び代行先サーバ２０をそれぞれ決定するための判定初期値をセットする（Ｓ５２）。代行決定部２４は、例えば、２種類の判定初期値をセットする。１つは、代行元となる高負荷のサーバ２０を決定するために用いる高負荷閾値ＬＨである。他の１つは、代行先となる低負荷のサーバ２０を決定するために用いる低負荷閾値ＬＬである。

代行決定部２４は、共有ＬＵ５３にアクセスし（Ｓ５３）、負荷情報管理テーブル４１を参照する（Ｓ５４）。代行決定部２４は、負荷情報管理テーブル４１に基づいて、情報処理システム内で最も高負荷状態となっているサーバ２０を検出し、この最も高負荷状態のサーバ２０の負荷が高負荷閾値ＬＨ以上であるか否かを判定する（Ｓ５５）。この高負荷閾値ＬＨは、例えば、負荷値「１００」に設定される。

最も高負荷状態のサーバ２０の負荷が高負荷閾値ＬＨ未満の場合（S55:NO）、代行決定部２４は、処理の一部を代行させるほどの高負荷状態ではないと判定し、再びＳ５１に戻る。なお、Ｓ５１，Ｓ５５，Ｓ５６でそれぞれ「ＮＯ」と判定された場合やＳ５８を終了してＳ５１に戻る時に、所定時間ｔ３をカウントするタイマがリセットされ、改めて時間をカウントする。

最も高負荷状態のサーバ２０の負荷が高負荷閾値ＬＨ以上である場合（S55:YES）、代行決定部２４は、負荷情報管理テーブル４１に基づいて、情報処理システム内で最も低負荷状態となっているサーバ２０を検出する。そして、代行決定部２４は、最も低負荷状態のサーバ２０の負荷が低負荷閾値ＬＬ以下であるか否かを判定する（Ｓ５６）。この低負荷閾値ＬＬは、例えば、負荷値「３０」に設定される。最も低負荷状態のサーバ２０の負荷が低負荷閾値ＬＬを上回っている場合（S56:NO）、代行決定部２４は、他のサーバ２０の処理を代行できるほどの余力がないものと判定し、再びＳ５１に戻る。

最も低負荷状態のサーバ２０の負荷が低負荷閾値ＬＬ以下の場合（S56:YES）、代行決定部２４は、代行関係を設定する（Ｓ５７）。即ち、代行決定部２４は、最も高負荷であって、かつ、高負荷閾値ＬＨ以上の負荷を有するサーバ２０を代行元サーバとして決定する。また、代行決定部２４は、最も低負荷であって、かつ、低負荷閾値ＬＬ以下の負荷を有するサーバ２０を代行先サーバとして決定する。そして、代行決定部２４は、代行先サーバとして決定されたサーバ２０に対し、代行先として決定された事を示す情報と、代行元として決定されたサーバを特定するための情報とを送信する（Ｓ５７）。

図２（ａ）に示したように、本実施例では、第２のサーバ２０（２）は、他の全てのサーバ２０よりも負荷が高く、その負荷平均値（Ave）は高負荷閾値ＬＨを上回る「１０５」となっている。一方、第１のサーバ（１）は、他の全てのサーバ２０よりも負荷が低く、その負荷平均値は低負荷閾値ＬＬと等しい「３０」になっている。従って、代行決定部２４は、高負荷閾値ＬＨ以上の負荷を有する第２のサーバ２０（２）を代行元サーバとして選択し、低負荷閾値ＬＬ以下の負荷を有する第１のサーバ２０（１）を代行先サーバとして選択する。

ここで、注意すべき点は、代行決定部２４は、単純に、最も高負荷のサーバ２０と最も低負荷のサーバ２０とを抽出して代行ペアを生成するものではない点である。このような単純なペアリングを行った場合は、例えば、ほんの僅かに負荷値が他のサーバ２０を上回るサーバ２０が代行元サーバとして決定され、ほんの僅かに負荷値が他のサーバ２０を下回るサーバ２０が代行先サーバとして決定される可能性がある。全てのサーバ２０が高負荷状態に置かれている場合は、既に高負荷状態のサーバ２０が代行先サーバとして選択される結果、代行先として決定されたサーバ２０の負荷状態がさらに上がり、応答性の低下等を招くおそれもある。従って、最高負荷のサーバ２０と最低負荷のサーバ２０とを単純にペアリングする方法では、情報処理システム全体として最適な負荷分散を行うことができない。そこで、代行決定部２４は、上述の通り、最も高負荷であり、かつ、高負荷閾値ＬＨ以上のサーバ２０を代行元サーバとして決定し、最も低負荷であり、かつ、低負荷閾値ＬＬ以下のサーバ２０を代行先サーバとして決定する。これにより、代行されるべきサーバ２０が代行元サーバとして決定され、代行するだけの余力のあるサーバ２０が代行先サーバとして決定される。また、代行元あるいは代行先の候補となる全てのサーバ２０の負荷情報が負荷情報管理テーブル４１のように一括して管理されているので、より代行されることが必要なサーバ２０が代行元サーバとして選択され、より代行する余力のあるサーバ２０が代行先サーバ２０として選択されることが可能となる。

図１０は、代行先サーバとして決定されたサーバ２０の処理代行部２５による代行処理を示す。処理代行部２５は、代行決定部２４から代行先サーバとして決定された旨の通知を受け取ると起動する（S61:YES）。ここで、処理代行部２５に通知する代行決定部２４は、処理代行部２５と同一のサーバ２０に実装されていてもよいし、処理代行部２５と異なるサーバ２０に実装されていてもよい。

処理代行部２５は、代行元サーバとして決定されたサーバ２０にアクセスし、まず最初に、代行元サーバの有するスケジューリングテーブル２７の読み込みロックを取得する（Ｓ６２）。代行先サーバの処理代行部２５は、代行元サーバのスケジューリングテーブル２７の読み込みをロックする（Ｓ６３）。これにより、代行元サーバは、スケジューリングテーブル２７に登録されたジョブを読み出して実行することができなくなる。代行元サーバのスケジューリングテーブル２７の読み込みは、代行先サーバの処理代行部２５により支配される。

処理代行部２５は、代行元サーバのローカルＬＵ３０を代行元サーバからアンマウントさせて、代行先サーバにマウントさせる（Ｓ６４）。処理代行部２５は、代行元サーバのローカルＬＵ３０を支配下に置いた後、代行元サーバのスケジューリングテーブル２７に基づいて（Ｓ６５）、処理を実行する（Ｓ６６）。処理代行部２５は、スケジューリングテーブル２７に登録された処理を実行すると、実行ステータスフラグを書き換えて、スケジューリングテーブル２７を更新させる（Ｓ６７）。

処理代行部２５は、予め設定されている代行期間が経過したか否かを判定する（Ｓ６８）。代行期間は、例えば、代行決定部２４による代行関係の見直し時期に合わせて設定することができる。代行期間が経過するまでの間は、即ち、代行先サーバとして指定されている期間中は（S68:NO）、代行先サーバの処理代行部２５は、Ｓ６５〜Ｓ６７を繰り返し、移行元サーバのスケジューリングテーブル２７に基づいて処理を実行する。

代行期間が経過すると（S68:YES）、スケジューリングテーブル２７の読み込みロックを解除し、代行元サーバのローカルＬＵ３０をアンマウントする（Ｓ６９）。そして、再びＳ６１に戻る。このように、予め設定された所定の代行期間毎に、処理代行部２５による代行処理は解除される。代行決定部２４によって別のサーバ２０が代行先サーバとして選択された場合は、その新たなサーバ２０の処理代行部２５によって代行元サーバの処理の一部が代行される。もっとも、代行関係の見直しにより、代行元サーバ及び代行先サーバの双方がそれぞれ別のサーバ２０に入れ替わる場合もあるし、代行ペアが設定されない場合もある。

図１１は、本実施例によって各サーバ間で処理の代行が行われる様子を模式的に示す説明図である。図１１では、サーバ２０（１）（サーバ１と表示）〜サーバ２０（３）（サーバ３と表示）の３台を例に挙げて説明する。図中の左端に示すＴ１〜Ｔ５は、代行の単位期間を示す。

各代行期間Ｔ１〜Ｔ５において、各サーバ２０（１）〜サーバ２０（３）は、上述した通り、基礎情報の収集と（Ｐ１）、基礎情報に基づく負荷情報の生成と（Ｐ２）、負荷情報の共有ＬＵ４０への格納と（Ｐ３）、代行元サーバ及び代行先サーバの決定と（Ｐ４）を、それぞれ独立して実施している。基礎情報の収集（Ｐ１）と、負荷情報の生成（Ｐ２）と、負荷情報の格納（Ｐ３）とは、負荷情報格納部２１により実行される。代行対象の決定（代行関係の決定とも言う）（Ｐ４）は、代行決定部２４により実行される。

代行期間Ｔ１では、高負荷のサーバ２０は発生していない。従って、代行期間Ｔ１の最後で実行される代行関係決定処理Ｐ４では、代行元サーバ及び代行先サーバのいずれも決定されない。

そこで、次の代行期間Ｔ２に移行する。この代行期間Ｔ２において、第２のサーバ２０（２）に高負荷状態が発生したとする。例えば、第２のサーバ２０（２）にクライアント端末からのファイルアクセス要求が集中したような場合に、第２のサーバ２０（２）の負荷が増大する。一方、第１のサーバ２０（１）の負荷は、低負荷閾値ＬＬ以下であるとする。そこで、代行期間Ｔ２の最後に行われる代行関係決定処理（逆に言えば、次の代行期間Ｔ３の開始直前に実行される代行関係決定処理）では、サーバ２０（２）が代行元サーバとして決定され、サーバ２０（１）が代行先サーバとして決定される。

代行期間Ｔ３において、サーバ２０（１）の負荷情報格納部２１等が自機に関する「基礎情報の採集（Ｐ１）」〜「負荷情報の格納（Ｐ３）」の各処理を行う。また、サーバ２０（１）の処理代行部２５は、代行元のサーバ２０（２）に関するＰ１〜Ｐ３の処理を行う。従って、代行先サーバとして選択されたサーバ２０（１）の負荷情報格納部２１は、自機及び代行元サーバに関する基礎情報をそれぞれ個別に収集し（Ｐ１）、それぞれの負荷情報を個別に生成し（Ｐ２）、各負荷情報を共有ＬＵ４０に格納させる（Ｐ３）。なお、代行関係の決定処理（Ｐ４）は、代行元サーバ及び代行先サーバのそれぞれで重複して実行する必要はない。従って、代行先であるサーバ２０（１）の代行決定部２４と、代行と無関係のサーバ２０（３）の代行決定部２４との２つの部だけが、次の代行期間Ｔ４における代行関係を決定する。

サーバ２０（２）の負荷情報に関する特定の処理を、サーバ２０（１）が肩代わりして実行することにより、この分だけサーバ２０（２）の負荷は軽減される。また、高負荷状態のサーバ２０（２）の負荷情報は、サーバ２０（１）により生成されて共有ＬＵ４０に格納される。従って、管理者は、ウェブヴラウザ１１を介して負荷情報を参照することにより、高負荷状態のサーバ２０（２）に関する負荷情報も含めて、全てのサーバ２０の負荷情報を一括して確認することができる。

代行期間Ｔ４において、サーバ２０（２）の負荷が高負荷閾値ＬＨ未満まで低下したとする。代行期間Ｔ４における代行関係は、代行期間Ｔ３の終期で決定済である。従って、代行期間Ｔ４の途中で、サーバ２０（２）の負荷が低下した場合でも、サーバ２０（１）によるサーバ２０（２）の代行は解消されない。なお、予め設定された代行期間中に、負荷状態が増大または減少した場合には、既に設定されている代行関係を解消し、新たな代行関係を設定するようにしてもよい。

代行期間Ｔ４の終わりに、代行関係の見直しが行われる。この時点で、サーバ２０（２）の負荷は高負荷閾値ＬＨ未満に低下しているので、代行関係の設定は行われない。従って、代行期間Ｔ５では、代行期間Ｔ１と同様に、各サーバ２０（１）〜２０（３）のそれぞれが、自機に関する基礎情報の収集（Ｐ１）、負荷情報の生成（Ｐ２）、負荷情報の格納（Ｐ３）、代行関係の決定（Ｐ４）を実行する。

以上詳述した通り、本実施例によれば、以下の効果を奏する。
まず、各サーバ２０の負荷情報は、共有ＬＵ４０に集約される。システム管理者は、ウェブヴラウザ１１を介して、いずれか１台のサーバ２０の負荷情報採集部２２にアクセスするだけで、全てのサーバ２０の負荷状態を簡単に確認できる。従って、システム管理者は、各サーバ２０の稼働状況を一元的に管理することができ、保守作業の作業性が向上する。

また、いずれかのサーバ２０が高負荷状態になった場合は、この高負荷のサーバ２０の負荷情報に関する処理を、低負荷のサーバ２０が代行する。従って、いずれかのサーバ２０に高負荷状態が生じても、この高負荷状態のサーバ２０に関する負荷情報の生成及び格納は、途切れることなく続行される。このため、負荷変動に拘わらず、各サーバ２０の負荷状況を一元的に管理し続けることができる。

さらに、負荷情報格納部２１は、まず基礎情報を収集してローカルＬＵ３０に格納し、ローカルＬＵ３０に格納された基礎情報を統計処理することにより負荷情報を生成する。従って、生データである基礎情報をそのまま共有ＬＵ４０に蓄積する場合に比較して、データサイズを低減することができる。また、処理済みのデータである負荷情報を共有ＬＵ４０に格納しておくので、ウェブヴラウザ１１に表示する負荷情報一覧画面を簡単に生成することができる。

また、負荷情報の一覧をウェブヴラウザ１１によって閲覧できる。従って、負荷状況を一元的に確認するための管理端末１０は、少なくともウェブヴラウザ１１のみを備えていればよく、特別な閲覧部を実装している必要はない。

さらに、最高負荷のサーバ２０が高負荷閾値ＬＨ以上の負荷を有する場合に代行元サーバとして選択し、最低負荷のサーバ２０が低負荷閾値ＬＬ以下の負荷を有する場合に代行先サーバとして選択する。従って、処理の肩代わりを必要とするサーバ２０を代行元サーバとして選択し、処理を肩代わりするだけの余裕のあるサーバ２０を代行先サーバとして選択することができる。

また、代行決定部２４は、全てのサーバ２０の負荷情報に基づいて、代行元サーバ及び代行先サーバをそれぞれ決定する。従って、システム全体の状況に基づいて、公平に代行関係を決定することができ、公正な負荷分散を行うことができる。

さらに、代行決定部２４は、代行期間が経過する毎に、代行関係を見直すようになっている。従って、所定サイクル毎に代行処理を行わせることができ、簡単な制御構造で、負荷情報の一元的な監視と負荷変動への対応とを実現することができる。

また、本実施例は、フェイルオーバクラスタの内部で、あるいはクラスタを超えて実現可能である。即ち、例えば、代行元サーバと代行先サーバとが１つのクラスタを構成する場合、代行元サーバがシステムダウンしてフェイルオーバが発動されるか否かとは別に、負荷情報に関する特定の処理は、独立して代行される。また、代行元サーバと代行先サーバとがそれぞれ別のクラスタに属する場合も、負荷情報に関する特定の処理の代行が実行される。

なお、本発明は、上述した実施例に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。

例えば、図１１では、各サーバ２０の動作がほぼ同期しているかのように示しているが、実際には、各サーバ２０は、それぞれ独立して動作している。この場合、各サーバ２０の代行決定部２４は、代行関係決定時に代行関係管理テーブル４２をそれぞれ参照することにより、不要な決定を省くことができる。即ち、あるサーバ２０の代行決定部２４によって代行関係が既に決定されている場合、この決定直後に起動した別のサーバ２０の代行決定部２４は、代行関係管理テーブル４２を参照することにより、代行関係の決定処理が不要であることを知ることができる。

また、図９に示す処理では、最高負荷のサーバが高負荷閾値ＬＨ以上の負荷を有する場合に代行元サーバとして選択し、最低負荷のサーバが低負荷閾値ＬＬ以下の負荷を有する場合に代行先サーバとして選択しているが（Ｓ５５〜Ｓ５７）、本発明はこれに限定されない。例えば、Ｓ５５では、「高負荷閾値ＬＨ以上のサーバが存在するか否かを判定し、高負荷閾値ＬＨ以上の負荷を有するサーバが存在する場合は、このサーバを代行元サーバとして選択する。高負荷閾値ＬＨ以上の負荷を有するサーバが複数存在する場合は、より負荷の高い方のサーバを代行元サーバとして選択する。」ことができる。Ｓ５６では、「負荷が低負荷閾値ＬＬ以下のサーバが存在するか否かを判定し、低負荷閾値ＬＬ以下の負荷を有するサーバが存在する場合は、このサーバを代行先サーバとして選択する。低負荷閾値ＬＬ以下のサーバが複数存在する場合は、より負荷の低い方のサーバを代行先サーバとして選択する。」ことができる。

本発明の実施例に係わる情報処理システムの全体概要を示すブロック図である。 共有ＬＵに格納される情報の構造例を示し、（ａ）は、負荷情報管理テーブルに基づく情報をウェブヴラウザで閲覧した場合を示す模式図、（ｂ）は、代行関係管理テーブルの一例を示す説明図、をそれぞれ示す。 代行が行われる前におけるスケジューリングテーブルの説明図である。 途中で代行が行われた場合におけるスケジューリングテーブルの説明図である。 負荷情報の生成から格納までの処理の流れを示す説明図である。 代行関係の決定から処理代行までの流れを示す説明図である。 基礎情報格納処理を示すフローチャートである。 負荷情報格納処理を示すフローチャートである。 代行元サーバ及び代行先サーバをそれぞれ決定するための代行関係決定処理を示すフローチャートである。 代行先サーバにより実行される代行処理を示すフローチャートである。 負荷情報に関連する処理が代行される様子を模式的に示す説明図である。

符号の説明

１０…管理端末、１１…ウェブヴラウザ、２０…サーバ、２１…負荷情報格納部、２２…負荷情報採集部、２３…負荷情報ファイル作成部、２４…代行決定部、２５…処理代行部、２６…スケジューリング部、２７…スケジューリングテーブル、２８…ＯＳ、２９…ファイル共有プログラム、３１…基礎情報ファイル、４１…負荷情報管理テーブル、４２…代行関係管理テーブル、ＣＮ…通信ネットワーク

Claims (8)

1. 複数の情報処理装置と、該各情報処理装置により共有される共有記憶装置と、前記各情報処理装置を管理するための管理端末とを通信ネットワークを介して双方向通信可能に接続してなる情報処理システムにおいて、
   前記各情報処理装置は、
   自機の負荷状態に関する基礎情報を収集し、この基礎情報を統計処理することにより負荷情報を生成し、この負荷情報を前記共有記憶装置に記憶させる負荷情報格納部と、
   前記管理端末からの負荷情報閲覧要求に応じて、前記共有記憶装置に記憶されている前記各情報処理装置の負荷情報をそれぞれ読出し、前記管理端末に前記各負荷情報を提供する負荷情報提供部と、
   所定時間毎に前記共有記憶装置に記憶されている前記各負荷情報に基づいて、前記各情報処理装置のうち、最も高負荷の情報処理装置を処理代行元として、最も低負荷の情報処理装置を処理代行先として、それぞれ決定する処理代行情報処理装置決定部と、
   自機が処理代行先として決定された場合に、前記処理代行元として決定された前記情報処理装置の前記負荷情報格納部の処理を代行する処理代行部と、
   自機が処理代行元として決定された場合に、前記処理代行先として決定された前記情報処理装置に処理代行を依頼する前記負荷情報格納部の処理を予め登録しておく代行対象処理登録部と、を備え、
   前記処理代行装置決定部は、前記最も高負荷の情報処理装置の負荷が所定の上限値を上回っている場合に、この情報処理装置を前記処理代行元の情報処理装置として決定し、前記最も低負荷の情報処理装置の負荷が所定の下限値を下回る場合に、この情報処理装置を前記処理代行先の情報処理装置として決定するものである、
   ことを特徴とする情報処理システム。
2. 複数の情報処理装置と該各情報処理装置により共有される共有記憶装置とを通信ネットワークを介して双方向通信可能に接続してなる情報処理システムにおいて、
   前記各情報処理装置は、
   自機の負荷状態に関する負荷情報を生成して前記共有記憶装置に記憶させる負荷情報格納部と、
   負荷情報閲覧要求に応じて、前記共有記憶装置に記憶されている前記各情報処理装置の負荷情報をそれぞれ読出し、前記負荷情報閲覧要求の発行元に前記各負荷情報を提供する負荷情報提供部と、
   前記共有記憶装置に記憶されている前記各負荷情報に基づいて、前記各情報処理装置のうち、処理代行元の情報処理装置及び処理代行先の情報処理装置をそれぞれ決定する処理代行装置決定部と、
   自機が処理代行先として決定された場合に、前記処理代行元として決定された前記情報処理装置における特定の処理を代行する処理代行部と、
   自機が処理代行元として決定された場合に、前記処理代行先として決定された前記情報処理装置に処理代行を依頼する特定の処理を予め登録しておく代行対象処理登録部と、を備え、
   前記処理代行装置決定部は、前記各情報処理装置のうち最も高負荷の情報処理装置の負荷が所定の上限値を上回っている場合に、この情報処理装置を前記処理代行元の情報処理装置として決定し、前記各情報処理装置のうち最も低負荷の情報処理装置の負荷が所定の下限値を下回る場合に、この情報処理装置を前記処理代行先の情報処理装置として決定するものである、
   ことを特徴とする情報処理システム。
3. 前記負荷情報格納部は、自機の負荷状態に関する基礎情報を収集し、この基礎情報を統計処理することにより負荷情報を生成し、この負荷情報を前記共有記憶装置に記憶させるものである請求項２に記載の情報処理システム。
4. 前記負荷情報提供部は、前記各負荷情報をウェブヴラウザで閲覧可能な形態で提供するものである請求項３に記載の情報処理システム。
5. 前記処理代行元の情報処理装置及び前記処理代行先の情報処理装置の対応関係を管理するための代行関係管理テーブルを、前記共有記憶装置に格納し、前記処理代行装置決定部は、前記各負荷情報及び前記代行関係管理テーブルに基づいて、前記処理代行元の情報処理装置及び前記処理代行先の情報処理装置をそれぞれ決定する請求項４に記載の情報処理システム。
6. 前記特定の処理は、前記負荷情報格納部により実行される処理の全部または一部である請求項５に記載の情報処理システム。
7. 他の情報処理装置及び該他の情報処理装置と共有する共有記憶装置と通信ネットワークを介して双方向通信可能に接続される情報処理装置において、
   負荷状態に関する負荷情報を生成して前記共有記憶装置に記憶させる負荷情報格納部と、
   負荷情報閲覧要求に応じて、前記共有記憶装置に記憶されている前記各情報処理装置の負荷情報をそれぞれ読出し、前記負荷情報閲覧要求の発行元に前記各負荷情報を提供する負荷情報提供部と、
   前記共有記憶装置に記憶されている前記各負荷情報に基づいて、前記各情報処理装置のうち、処理代行元の情報処理装置及び処理代行先の情報処理装置をそれぞれ決定する処理代行装置決定部と、
   自機が処理代行先として決定された場合に、前記処理代行元として決定された前記情報処理装置における特定の処理を代行する処理代行部と、
   自機が処理代行元として決定された場合に、前記処理代行先として決定された前記情報処理装置に処理代行を依頼する特定の処理を予め登録しておく代行対象処理登録部と、を備え、
   前記処理代行装置決定部は、前記各情報処理装置のうち最も高負荷の情報処理装置の負荷が所定の上限値を上回っている場合に、この情報処理装置を前記処理代行元の情報処理装置として決定し、前記各情報処理装置のうち最も低負荷の情報処理装置の負荷が所定の下限値を下回る場合に、この情報処理装置を前記処理代行先の情報処理装置として決定するものである、
   ことを特徴とする情報処理装置。
8. 他の情報処理装置及び該他の情報処理装置と共有する共有記憶装置と通信ネットワークを介して双方向通信可能に接続される情報処理装置に所定の管理方法を実行させるためのコンピュータプログラムであって、
   前記所定の管理方法は、
   負荷状態に関する負荷情報を生成して前記共有記憶装置に記憶させるステップと、
   負荷情報閲覧要求を受け付けるステップと、
   前記負荷情報閲覧要求に応じて、前記共有記憶装置に記憶されている前記各情報処理装置の負荷情報をそれぞれ読出すステップと、
   前記読出された各負荷情報を前記負荷情報閲覧要求の発行元に提供するステップと、
   前記共有記憶装置に記憶されている前記各負荷情報を参照するステップと、
   前記各負荷情報に基づいて、前記各情報処理装置のうち最も高負荷の情報処理装置の負荷が所定の上限値を上回っている場合に、この情報処理装置を処理代行元の情報処理装置として決定するステップと、
   前記各負荷情報に基づいて、前記各情報処理装置のうち最も低負荷の情報処理装置の負荷が所定の下限値を下回る場合に、この情報処理装置を処理代行先の情報処理装置として決定するステップと、
   自機が処理代行先として決定された場合に、前記処理代行元として決定された前記情報処理装置における特定の処理を代行するステップと、
   を含むことを特徴とするコンピュータプログラム。

Images