JP2007532993A - トランザクションを識別し、トランザクションをサポートする容量を管理する方法 - Google Patents

Abstract

【課題】 複数のサーバのおおよその使用状況を追跡して、ロードの不均衡が示され修正されるようにすること。
【解決手段】 監視プログラムは、サーバ群におけるロード不均衡を検出して、修正を行うことができるように通知を提供するための方法を含む。本発明の一実施形態は、アドレス解決プロトコル（ＡＲＰ）キャッシュから読み取り、どのサーバ・アドレスが存在しているかを決定し、次いで、ＡＲＰキャッシュをクリアする。アドレス解決プロトコルは、それがスヌープするトラフィックと新しい要求から、キャッシュを再設定する。この照会及びクリア操作を定期的に実行することにより、追跡プログラムは、サーバの活動レベルのピクチャを形成することができる。顕著な不均衡が存在する場合には、プログラムは、制御コンソールに対して、人間の介入により問題を解決するように通知する。追跡プログラムは、その結果を定期的にログ・ファイルに書き込んで、必要に応じて、種々の期間についての報告が生成されることを可能にする。この機構により、不均衡を迅速に検出できるだけでなく、既知のリソース能力をその実際の使用と比較することにより、十分に使用されていない状態を見つけることもできる。
【選択図】 図６

Description

本出願は、一般に、適時かつ経済的な方法で、コンピュータ・サービスを管理することに関する。より具体的には、本出願は、サーバの１つ又はそれ以上のものが、期待される負荷を負担していない場合を検出するために、サーバ群に対するトラフィックを監視することに関する。

どのような種類のコンピュータ・システムを構築する場合にも、リソースを望ましい結果に適合させることが重要である。割り当てられたコンピューティング・リソースが少なすぎると、鈍い応答、顧客の不満、及び、一般に不良な結果がもたらされることになる。しかしながら、多すぎるリソースは無駄になり、事業収益に影響する。従って、アプリケーションとそれぞれのリソースの実際の能力との間の適合性を良くすることが、システムの財政上の成功に重要である。このことは、コンピュータ・リソースが顧客に与えられて共有され、採算性がこれらのリソースの最善の使用に大きく依存するプロビジョニング・システムにおいて、特に当て嵌まる。しかしながら、コンピュータ・システムの構築における最善の努力にもかかわらず、リソースの能力は、実際のリアルタイムの状況で必ずしも十分に利用されているわけではなく、見分けるのが困難な形で設計の構成とは異なることがある。例えば、評判の良いウェブサイトは、アクセスのために単一のアドレスを公開するが、このアドレスを使用するのは、実際の対話を管理する多数のトランザクション・サーバの１つに要求を転送するサーバに対してのみである。既存のプログラムは、要求を種々のトランザクション・サーバに配信するが、これらのプログラムは、必要な情報のすべてを持たないか又は問題を修正するための能力がないという状況が生じることがある。

一例を示すことができる。ニュース・サービスは、速報についてコンタクトを取ることができるウェブ・アドレスを提供する。このアドレスは、着信要求を、通常の負荷に対処できる５から１０のサーバ群に向ける単一のウェブ・サーバを指す。しかしながら、ツインタワーへのテロリスト攻撃といった大災害の間は、ニュース・サービスには要求が殺到する可能性がある。情報技術サービスを非常に迅速に提供することに特化したプロビジョニング・サービスの使用は、ニュース・サービスが、予想外の負荷を取り扱うための付加的なサーバと連動し、新しい要求は付加的なサーバに方向転換されるようにすることを可能にする。しかしながら、プロトコルによれば、第１に、所与のユーザからの要求を取り扱うサーバは、トランザクション全体を通して、その要求を取り扱い続けるため、より良いサービスを提供することができる他のサーバがあるにもかかわらず、多数のユーザが元のサーバに残り、限られた帯域幅を得るために競い合うことになる。既存のシステムは、あるサイトにアクセスしているユーザの数を追跡する能力、又は、元のサーバ及び最近割り当てられたサーバの両方が、等しく利用されているかどうかをチェックする能力がないことがある。

使用状況の他の面から見ると、大容量の大型サーバは、その能力のすべてを利用していないことがあるが、このことは、使用状況を追跡するのに利用可能なデータがないため、システム管理ソフトウェアによって、明確に認識されていないという可能性がある。過去には、この情報は、障害分析中に、プロジェクトに関する事後分析で発見されることが最も多かった。

従って、サーバのおおよその使用状況を追跡して、不均衡が示され修正されるようにすることができる機構を有することが望ましい。

本発明の第１の態様は、第１のサーバが複数の第２のサーバに要求を転送するようにされたネットワーク上でサーバ群内のサーバについて相対的負荷を監視するための方法を提供する。この方法は、複数の第２のサーバの各々について、アドレス及びそれぞれのカウンタを含む第１の表を準備するステップと、キャッシュ・ダンプを形成するために、アドレス解決プロトコル・キャッシュのコピーをストレージ域にダンプするステップと、複数の第２のサーバのうちのどれがキャッシュ・ダンプに存在するのかをキャッシュ・ダンプから決定するステップと、存在する第２のサーバの各々について、それぞれのカウンタを増分するステップと、を含む。決定するステップと増分するステップとが完了した後で、この方法は、複数のそれぞれのカウンタを互いに比較して、第２のサーバ間のロード不均衡が閾値より大きいかどうかを判断する。ロード不均衡が閾値より大きい場合には、ロード不均衡に関するメッセージが送信される。

本発明の第２の態様は、インターネットに接続されており、アドレス解決プロトコル・キャッシュを有する第１のサーバと、第１のサーバ上で稼動するプログラムと、第１のサーバとネットワークを形成するように接続された複数の第２のサーバと、を含むネットワークを提供する。第１のサーバは、インターネットから受信した複数の要求を、複数の第２のサーバのそれぞれのサーバに転送する。プログラムは、

複数の第２のサーバの各々について、アドレス及びそれぞれのカウンタを含む第１の表を準備するステップと、

アドレス解決プロセス・キャッシュをキャッシュ・ダンプにダンプするステップと、

キャッシュ・ダンプ内の各々のアドレスについて、キャッシュ・ダンプ内のアドレスが第１の表内のアドレスと一致する場合には、それぞれのカウンタを増分するステップと、

複数のカウンタを互いに比較して、第２のサーバ間のロード不均衡が閾値より大きいかどうかを判断するステップと、

ロード不均衡が閾値よりも大きい場合には、ロード不均衡に関するメッセージを送信するステップと、
を実行する。

本発明の１つの態様は、サーバ間の不均衡を検出して、修正を行うことができるように通知を提供するための方法を含む監視プログラムを提供する。本発明の一実施形態は、アドレス解決プロトコル（ＡＲＰ）キャッシュを読み取って、どのサーバ・アドレスが存在するかを決定し、次いで、ＡＲＰキャッシュをクリアする。アドレス解決プロトコルは、それがスヌープするトラフィックと新しい要求から、キャッシュを再設定する。この照会及びクリア操作を数秒毎に実行することにより、監視プログラムは、種々のサーバの活動レベルのピクチャを形成することができる。顕著な不均衡が存在する場合には、プログラムは、メッセージを制御コンソールに送信して、その問題が知られ、解決することができるようにする。監視プログラムは、その結果を定期的にログ・ファイルに書き込んで、必要に応じて、種々の期間についての報告が生成されることを可能にすることができる。この機構により、不均衡を迅速に検出できるだけでなく、期待されるリソースの使用パターンをその実際の使用と比較することにより、十分に使用されていない状態を見つけることもできる。

本発明によるコンピュータ・プログラム製品は、プログラムが上述の方法を行うように実行されるデータ処理装置の動作を制御するための一組の命令を実装する。

本発明の特徴と信じられる新規なフィーチャは、添付の特許請求の範囲に示される。しかしながら本発明自体、好ましい使用様式、並びに本発明の更なる目的及び利点は、添付の図面と併せて、以下の例示的な実施形態の詳細な説明を参照して読むことにより、最も良く理解されるであろう。

ここで図面を参照すると、図１は、インターネット１２０を通じて顧客にサービスを提供するプロビジョニング・システムの使用を示している。サービス・プロバイダ１２４は、種々の被管理サービス１２８を与える。これらのサービスは、以下に限定されるものではないが、サーバ、端末、ディスク・スペース、及び広範囲のソフトウェアを含むことができる。サービス１２８を望む顧客１２２は、インターネット１２０を通じて、又は電話といった他の手段（図示せず）を用いて、プロバイダ１２４にコンタクトすることができる。次いで、プロビジョニングは、自動プロビジョニング・システム１２６により管理される。契約上の取り決めは、種々の形態をとることができる。例えば、顧客は、サービス・プロバイダ１２４と契約を結んで、サーバ及び端末を顧客のサイトに設置し、顧客１２２が人員追加するときには、プロバイダ１２４が端末を追加するようにすることができる。ソフトウェアのアップグレードは、要求が受信された時に、自動プロビジョニング・システムにより、自動的に顧客のコンピュータにダウンロードされるようにすることができる。第２の顧客は、異なるプロジェクトが開始したり終了したりするため、コンピューティングのニーズが時間と共に大幅に変化する事業を有するとすることができる。この顧客は、必要に応じて、自分の場所に基本コンピュータ機器を持つが、プロジェクトの有効期間中に、サービス・プロバイダからのサーバ、ストレージ、及びソフトウェアを利用する契約をすることができる。こうした第３者プロビジョニング・システムは、引用によりここに組み入れる、「第３者リソース・プロビジョニング管理のための方法及びシステム」と題する米国特許出願第２００２０１６９８７６号に説明されている。

図２は、図１のプロビジョニング・システム１２６によるプロビジョニングが可能で、本発明を実施することができるデータ処理システムのネットワークの図形表示を示す。ネットワーク・データ処理システム１００は、ネットワーク１０２に接続されており、これは、ネットワーク・データ処理システム１００内で互いに接続された種々のデバイスとコンピュータとの間に通信リンクを提供するのに使用される。

図示例においては、サーバ１０４は、ネットワーク１０２及びインターネット１２０に接続されている。さらに、ストレージ・ユニット１０６とサーバ１０８、１１０、１１２、１１４及び１１６がネットワーク１０２に接続されている。図示例においては、サーバ１０４のアドレスは、インターネット上のユーザのためのコンタクト・ポイントとして提供される。しかしながら、サーバ１０４は、次いで、要求を他のサーバ１０８ないし１１６に転送する。サーバ１０４は、サーバ間でロード・バランシングを実行して、ロードをできるだけ均等に拡げるようにするプログラムを有するが、ロード・バランシングは、「厄介」なものであり、要求がサーバ１１０といった所与のサーバに送信されると、そのユーザからのすべての要求がそのセッション中、同じサーバに向けられることになる。負荷が重い間は、プロビジョニング・システム１２６は、付加的なサーバを提供して作業負荷を処理することができる。ネットワーク・データ処理システム１００は、図示されていない他のデバイスを含むことができる。図示例においては、ネットワーク・データ処理システム１００は、サーバ１０４によりインターネット１２０に接続される。インターネット１２０は、互いに通信を行うために、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のプロトコル・スイートを用いるネットワーク及びゲートウェイの世界的な集合を表す。インターネットの中心は、データ及びメッセージを送る何千もの商業、政府、教育及びその他のコンピュータ・システムで構成される、主ノード又はホスト・コンピュータ間の高速データ通信回線のバックボーンである。ネットワーク・データ処理システム１００は、例として、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、又は広域ネットワーク（ＷＡＮ）といった複数の異なる種類のネットワークとして実装することができる。図１は、一例であり、本発明の構造的な制限を意図するものではない。

図３を参照すると、サーバ１０４ないし１１６の１つ、又はプロビジョニング・システム１２６の一部であるサーバとして実装することができるデータ処理システムのブロック図が、本発明の好ましい実施形態により示されている。データ処理システム２００は、システム・バス２０６に接続された複数のプロセッサ２０２及び２０４を含む対称型マルチプロセッサ（ＳＭＰ）システムとすることができる。代替的には、単一プロセッサ・システムを採用してもよい。さらに、システム・バス２０６には、ローカル・メモリ２０９に対するインターフェースを提供するメモリ・コントローラ／キャッシュ２０８が接続される。Ｉ／Ｏバス・ブリッジ２１０は、システム・バス２０６に接続されて、Ｉ／Ｏバス２１２に対するインターフェースを提供する。メモリ・コントローラ／キャッシュ２０８とＩ／Ｏバス・ブリッジ２１０は、図示のように統合することができる。

Ｉ／Ｏバス２１２に接続された周辺機器相互接続（ＰＣＩ）バス・ブリッジ２１４は、ＰＣＩローカル・バス２１６に対するインターフェースを提供する。複数のモデムをＰＣＩローカル・バス２１６に接続することができる。典型的なＰＣＩバスの実装は、４つのＰＣＩ拡張スロット又はアドイン・コネクタをサポートする。図２のクライアント１０８ないし１１２への通信リンクは、アドイン・コネクタを通してＰＣＩローカル・バス２１６に接続されたモデム２１８及びネットワーク・アダプタ２２０により提供することができる。

付加的なＰＣＩバス・ブリッジ２２２及び２２４は、付加的なＰＣＩローカル・バス２２６及び２２８に対するインターフェースを提供し、ここから付加的なモデム又はネットワーク・アダプタをサポートすることができる。このようにして、データ処理システム２００は、複数のネットワーク・コンピュータへの接続を可能にする。メモリ・マップ・グラフィックス・アダプタ２３０及びハードディスク２３２もまた、図示のように、直接又は間接的に、Ｉ／Ｏバス２１２に接続することができる。

当業者であれば、図３に示すハードウェアは異なっていてもよいことを理解するであろう。例えば、光学ディスク・ドライブ及び同様なものといった他の周辺デバイスもまた、図示されるハードウェアに加えて、又はその代わりに使用することができる。図示例は、本発明に関して構造的な制限を示唆することを意味するものではない。

図３に示すデータ処理システムは、例えば、拡張対話式エグゼクティブ（ＡＩＸ（Ｒ））オペレーティング・システム又はＬＩＮＵＸ（Ｒ）オペレーティング・システムを稼動する、ニューヨーク州アーモンク所在のインターナショナル・ビジネス・マシーンズ・コーポレーションの製品であるＩＢＭ（Ｒ） ｅＳｅｒｖｅｒ（Ｒ） ｐＳｅｒｉｅｓ（Ｒ）システムとすることができる。

通信するためには、すべてのネットワーク・デバイスは、固有の、製造者により定義されたメディア・アクセス制御（ＭＡＣ）アドレスを有し、これにより識別されることができる。ＭＡＣアドレスは６バイトを含み、各対がコロンで分離された、１２個の１６進数字として書かれる。例示的なＭＡＣアドレスは、０Ａ：４Ｂ：００：００：０７：０８となる。一方、インターネット・プロトコル（ＩＰ）アドレスは、デバイスとインターネットとの間の接続のためのアドレスである。ＩＰアドレスは領域によって分けられ、インターネット・サービス・プロバイダ（ＩＳＰ）といった、その領域内のローカルな登録機構により割り当てられる。ＩＰアドレスは、アドレスが属するクラスによって定まるフォーマットの４バイトである。１０００００００ ００００１０１１ ００００００１１ ０００１１１１１として表される２進数アドレスをもつ例示的なＩＰアドレスは、１２８．１１．３．３１と書かれる。図２のネットワーク１０２といった１つのネットワーク内では、ホストはそのＭＡＣアドレスにより知られるが、ＴＣＰ／ＩＰといった高レベルのプロトコルでは、ＩＰアドレスといったシンボリック・アドレスによりホストを指定する。

コンピュータが、所与のＩＰアドレスにメッセージを送信することを望む場合には、このＩＰアドレスを、低レベルのデバイスが理解できる物理ハードウェア・アドレス（ＭＡＣ）に変換しなくてはならない。この変換は、この目的のために、ＡＲＰキャッシュと呼ばれるルックアップ表を維持するアドレス解決プロトコル（ＡＲＰ）により提供される。ＡＲＰが、そのキャッシュ内にＭＡＣアドレスをまだもっていない場合には、この情報の要求はネットワークに配信される。

図４を参照すると、ＡＲＰ要求メッセージ３００のフォーマットが示されている。メッセージの最初の２バイトは、「１」がイーサネットを示す、ハードウェア・アドレス・タイプ３０２である。次の２バイトは、０×０８００がＩＰを示す、プロトコル・アドレス・タイプ３０４である。１バイトのハードウェア・アドレス長フィールド３０６及び１バイトのプロトコル・アドレス長フィールド３０８が次の２バイトであり、次いで「１」が要求を示し、「２」が応答を示す、２バイトの動作コード３１０が続く。次の６バイトは、送信側のＭＡＣアドレス３１２であり、次いで、４バイトの送信側のＩＰアドレス３１４、６バイトのターゲットＭＡＣアドレス３１６、及び４バイトのターゲットＩＰアドレス３１８が続く。

ＡＲＰ要求を送信するのに先立って、コンピュータは、それ自体のＭＡＣアドレス３１２及びＩＰアドレス３１４を書き込み、ターゲットＩＰアドレス３１６を書き込み、動作コード３１０を「１」に設定し、ターゲットＭＡＣアドレスをゼロに設定する。この要求は、次いで、配信され、同時に、要求が送信されたという表示をもって、ターゲットＩＰアドレスがＡＲＰキャッシュに加えられる。送信側が応答を受信した場合には、受信側のＭＡＣアドレスを、対応するＩＰアドレスと共にＡＲＰキャッシュに格納し、同時に、その入力項目が完了したとしてマークする。要求処理の相手方においては、ターゲット機械がそれ自体のアドレスを認識し、最初に、該ターゲットが、このソースから付加的なコンタクトを受信する可能性があるため、送信側のアドレスをそれ自体のキャッシュに保存し、次に、メッセージに応答して、それ自体のＭＡＣアドレスを提供する、という２つの動作により要求に応答する。アドレスをそれ自体のものとして認識しない他のコンピュータは、配信メッセージを破棄する。

ＡＲＰ要求が、個々のネットワーク内で応答を引き出さない場合には、要求は他のネットワーク・ハブに配信されて、望ましい接続を探し当てる。この場合、物理ハードウェア・アドレスは、ルート情報を加えた形で戻される。ＡＲＰキャッシュは、情報が再度アクセスされたかどうかに依存することもあるし、しないこともある、所定の時間の長さについてのコンタクト情報を維持する。所定の間隔、例えば１０分が経過すると、アドレスは削除されて、より最近のアドレスのためにスペースが利用可能になる。ＡＲＰ入力項目がタイムアウトするまでの時間制限、並びに、この時間制限を更新できるかどうかは、使用されているオペレーティング・システムにより管理される。

図５は、簡略化された例示的なＡＲＰキャッシュ４００を示す。このシステムにおいては、アドレス解決プロトコルは、要求を通して受信したアドレスを保存するだけではなく、通過する通信ストリームをスヌープして、キャッシュ内にまだ存在しないアドレスがあれば、それを追加する。ＡＲＰキャッシュの正確なフォーマットは、システムごとに異なっていてよく、この図に示すキャッシュは、本発明に必要な情報だけを含む。キャッシュ４００には、各々のアクティブなアドレスについての記録があり、少なくともサーバ又はクライアントのＩＰアドレス４１０、対応するＭＡＣアドレス４１５、及び時間フィールド４２０を示す。時間フィールド４２０は、規定の期間が経過した場合、或いは、アドレスが規定の期間においてアクティブではなかった場合に、いつ項目を表から除去すべきかを判断するのに用いられる。例示的なキャッシュ４００は、存続期間（ＴＴＬ）フィールドを使用する。このシステムでは、項目がキャッシュに加えられた時に、２１６０秒の時間値がこのフィールドに挿入される。この値は毎秒１ずつ減り、ゼロに到達した場合には、スペースは、別のアドレスによる使用のために開放される。しかしながら、関連アドレスが要求される又はスヌープされる度に、ＴＴＬフィールドは開始値である２１６０にリセットされる。このようにして、項目は、そのアドレスがアクティブである限り、２１６０秒の間、キャッシュ内に残る。システムは、さらに、逆の発想を使用して、入力に際してカウンタをゼロに設定し、次いで、限界に到達してスペースが開放されるまで、カウンタを毎秒増分させることができる。カウンタをゼロにリセットすることができる場合には、項目は、通常の活動を有する限り、キャッシュ内に残るが、カウンタをリセットすることができない場合には、項目は一定の長さの時間しかキャッシュ内に残らない。

本発明のプログラムが使用される場合には、プログラムは定期的にＡＲＰキャッシュをクリアする。クリアが頻繁に実行される場合には、キャッシュは、最後にクリアされて以来アクティブであるアドレスだけを含む。本発明のプログラムは、最初にインストールされた場合には、典型的には、キャッシュをチェックし、およそ毎秒に一回それをクリアする。関連のサーバがどれだけ速くキャッシュに再追加されるかを監視することにより、プログラムは、サーバ活動の概略を求めることができる。

キャッシュ・ダンプがチェックされるに伴い、情報は図７に示す表に格納される。表６００は、サーバ・アドレス６０２のフィールドと、サーバに関連するカウンタ６０４のフィールドとを含む。サーバ・アドレス６０２がキャッシュ・ダンプにおいて見出される度に、それぞれのカウンタ６０４が増分される。

ここで図６を参照すると、本発明のプログラムの例示的な実施形態による、複数のサーバの使用レベルを比較するのに必要な動作を見ることができる。プログラムは、ネットワーク（例えばネットワーク１０２）とより大きなインターネットとの間のインターフェースとしての機能を果たすゲートウェイ・サーバ（例えば１０４）上にインストールされる。このネットワークに送られた全パケットは、サーバ１０４と関連するルータを通過して、ＡＲＰキャッシュは、サーバ１０８ないし１１６の使用に関する情報を含むようになる。例えば、以前に説明したニュース・サービスは、公開されたウェブ・アドレスに配置されたサーバ上に、本発明のプログラムをインストールする。

革新的なプログラムにアクセス可能な、関心のあるサーバ、例えば、サーバ１０８ないし１１６のアドレスのリストが維持される。一時的な条件のためにシステムが付加的なサーバを加えた場合には、それらのサーバのアドレスがリストに加えられる。プログラムが開始するに伴い、追跡されるべきサーバのアドレスが、項目６０２として表６００に入力される（ステップ５１０）。次いで、サーバに関連するカウンタ６０４がクリアされてゼロになる（ステップ５１５）。プログラムは、ＡＲＰキャッシュの内容を作業域にダンプし、キャッシュ内の項目をクリアすることにより開始する（ステップ５２０）。このように、アドレス解決プロトコルは、革新的なプログラムがサーバの活動をチェックしている間、動作し続けることができる。次いで、追跡プログラムが、取得されたばかりのＡＲＰダンプ内の最初の項目を調べる（ステップ５２５）。そこに格納されたアドレスが、追跡されているサーバの１つのアドレスかどうかに関しての判断がなされる（ステップ５３０）。答えが「イエス」である場合には、サーバのカウンタ６０４は１だけ増分され（ステップ５３５）、そうでない場合には、このステップは省かれる。監視プログラムは、次いで、ダンプ内の最後の項目を調べているかどうかを判断する（ステップ５４０）。調べてない場合には、追跡プログラムはダンプ内の次の項目に進み（ステップ５４５）、次いで、ステップ５３０に戻り、キャッシュ・ダンプの残りをチェックする。

キャッシュの終わりに到達した場合には、追跡プログラムは、表６００で収集した情報を分析することができる。プログラムがＡＲＰキャッシュをダンプし、分析したのが初めてであれば、例えば、上述の例における最後の２１６０秒といった、キャッシュにより設定された期間内でサーバがアクティブであったかどうかを知らせることしかできない。しかしながら、監視プログラムがキャッシュを繰り返しダンプし、クリアするに伴い、全サーバがたいてい又は常にキャッシュ内に現れているかどうかの知識を構築することができる。サーバが、時々ＡＲＰキャッシュ・ダンプに現れなくても驚くことはないが、これが頻繁に起こる場合、特にオペレータが利用可能な他のインジケータが、サーバがビジー状態であると示す場合には、一般に、問題の現れである。

監視プログラムは、種々のサーバのカウンタを比較して、それらの差が閾値よりも大きいかどうかを調べる（ステップ５５０）。答えが「イエス」である場合には、メッセージが、収集された関連データのコピーと併せて、制御コンソールに送信される（ステップ５５５）。従って、このプログラム自体が問題を修正することはないが、疑わしい条件が存在することをオペレータに知らせる。サーバ上のロードが閾値よりも大きく異なることがない場合には、メッセージは省かれる。

累計は、定期的にログ・ファイルに書き込まれ、クリアされることができる。ロギングの期間は、数分から数時間又は数日まで異なることができる。間隔がどのように決められても、プログラムは、この期間が経過したかどうかをチェックする（ステップ５６０）。期間が経過していた場合には、ログ記録又はログ報告が書き込まれ、カウンタ６０４がクリアされる（ステップ５６５）。ＡＲＰキャッシュのダンプ及びクリアに戻る前に、プログラムは、サーバの数が変更されたかどうかを判断する（ステップ５７０）。一般に、この答えは「ノー」であり、プログラムは再びキャッシュをダンプし、クリアする（ステップ５２０）。変化する条件が、サーバの数を増加させる又は減少させる原因となった場合には、プログラムはステップ５１０に戻り、予想されるサーバすべてのアドレスが表６００に記録され、次いで、チェックが再び始まる。

すべてのコンピュータ・アプリケーションにおけるように、このプログラムでは、十分な情報を提供することと、作業の追跡にあまりに時間がかかり、実際の作業を終わらせる時間がないこと、との間にトレードオフがある。監視プログラムは、連続的で、密集したキャッシュのダンプを使用することにより、最も効率よく動作する。しかしながら、アクティブなプロセスにおける信頼性が増加するに伴い、モニタは、例えば、１５分毎又は１時間毎に１分ずつ、その動作を省略することができる。このようにして、プログラムは、常時稼動することなく、必要なデータを取得することができる。もちろん、例えば、他のシステム・モニタが潜在的なシステム問題があることを示した場合には、監視プログラムは、オペレータの入力により連続稼動に戻ることができる。

ここで、サーバ間の不均衡の検出について、図８を参照して説明する。この例では、ＩＰアドレス００００．０ｃ０７．ｂｃ０１をもつ単一のルータが、ＩＰアドレス１９２．１６８．１２．１７４、１９２．１６８．１２９．１９１、１９２．１６８．１３５．１６７、及び１９２．１６８．１３５．１３６における、４つの異なるサーバに照会を送信する。以下は、幾つかの一連のキャッシュ・ダンプの一部を表す表、及び、関連する走査の反復後にもたらされる表を表す。このシステムでは、キャッシュは、ゼロから上向きに増分される年数フィールドを使用することに注目されたい。

キャッシュ・ダンプ、時間＝０

１回目の反復後の表

予想されるサーバのすべてが、この最初の走査において見出された。１秒後に、ダンプが再び生じる。

キャッシュ・ダンプ、時間＝１

２回目の反復後の表

今度は、３つのサーバがダンプ内で探索されたが、‘１３６サーバは見出されなかった。１秒後に、ダンプが再び生じる。

キャッシュ・ダンプ、時間＝２

３回目の反復後の表

ここでも、‘１３６サーバがキャッシュ・ダンプ内に見出されなかった。これは、問題の検出とすることができるが、閾値に到達するまでは、そのように認識されない。閾値が３５秒に設定されていると仮定し、時間を飛び越して進めることにする。ここで、３６回目の反復におけるキャッシュ・ダンプを示す。

キャッシュ・ダンプ、時間＝３５

３６回目の反復後の表

この反復において、サーバ‘１３６の出現と他のサーバのそれとの間の差が、閾値３５に到達する。この時点で、オペレータは明白な問題を知らされる。

この方法及びシステムは、サーバ群の活動を監視し、報告して、変更が必要な時にオペレータが対応することを可能にする方法を提供するものであるが、これは、以前は明らかではなかった。

本発明は、完全に機能するデータ処理システムの内容で説明されているが、重要な点は、当業者であれば、本発明のプロセスは、コンピュータ可読媒体の命令形態及び種々の形態で配信することができ、しかも、本発明は、配信を実行するのに実際に使用される信号担持媒体の特定の種類に関係なく、等しく適用されるものと理解するであろうということである。

コンピュータ可読媒体の例は、フレキシブル・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭといった書き込み可能型媒体、並びにデジタル及びアナログ通信リンクといった伝送型媒体、例えば、無線周波伝送及び光波伝送といった伝送形体を用いた有線又は無線通信リンクを含む。コンピュータ可読媒体は、特定のデータ処理システムにおける実際の使用のためにデコードされる、コード化フォーマットの形態をとることができる。

本発明の説明は、例示及び説明の目的のために提示されたものであり、網羅的であること又は開示された形態に発明を限定することを意図するものではない。多数の修正及び変形態様が当業者には明白であろう。実施形態は、本発明の原理、実用的な適用例を最も良く説明し、他の当業者が、想定される特定の使用に適した種々の修正をもつ種々の実施形態について本発明を理解することを可能にするように選択され、説明されたものである。

インターネットに接続された、プロビジョニング・システムの図形表示を示す。 プロビジョニング・システムにより管理されるリソースの一部となることができ、本発明の監視プログラムを実装することができるサーバ群を示す。 サーバとして実装することができるデータ処理システムのブロック図である。 例示的なＡＲＰ要求記録を示す。 本発明の例示的な実施形態による例示的なＡＲＰキャッシュの一部を示す。 本発明の例示的な実施形態によるサーバの使用を監視する監視プログラムの動作のフローチャートを示す。 本発明の例示的な実施形態によるそれぞれのサーバの活動を追跡するのに使用される表を示す。 問題がどのように検出され得るかを例示する、ネットワーク及び関連するＩＰアドレスを示す。

Claims (11)

1. 第１のサーバが複数の第２のサーバに要求を転送するようにされたネットワーク上でサーバ群内のサーバについて相対的負荷を監視する方法であって、
   前記複数の第２のサーバの各々について、アドレス及びそれぞれのカウンタを含む第１の表を準備するステップと、
   キャッシュ・ダンプを形成するために、アドレス解決プロトコル・キャッシュのコピーをストレージ域にダンプするステップと、
   前記複数の第２のサーバのうちのどれが前記キャッシュ・ダンプに存在するのかを前記キャッシュ・ダンプから決定するステップと、
   存在する前記第２のサーバの各々について、それぞれのカウンタを増分するステップと、
   前記決定するステップと前記増分するステップとが完了した後で、前記複数のそれぞれのカウンタを互いに比較して、前記第２のサーバ間のロード不均衡が閾値より大きいかどうかを判断するステップと、
   前記ロード不均衡が前記閾値より大きい場合には、前記ロード不均衡に関するメッセージを送信するステップと、
   を含む方法。
2. 前記ダンプするステップと前記決定するステップとが繰り返し実行され、前記アドレス解決プロトコル・キャッシュが、前記ダンプするステップの各々の繰り返しの後でクリアされる、請求項１に記載の方法。
3. 前記準備するステップは、最初に実行された後は、サーバが前記複数の第２のサーバに加えられたか又はこれから除去された場合にのみ実行される、請求項１に記載の方法。
4. 定期的に、前記カウンタの値をログ・ファイルに書き込むステップと、前記カウンタをクリアするステップとをさらに含む、請求項１に記載の方法。
5. インターネットに接続されており、アドレス解決プロトコル・キャッシュを有する第１のサーバと、
   前記第１のサーバとネットワークを形成するように接続された複数の第２のサーバであって、前記第１のサーバが、インターネットから受信した複数の要求を前記複数の第２のサーバのそれぞれのサーバに転送する、複数の第２のサーバと、
   前記第１のサーバ上で稼動するプログラムであって、前記複数の第２のサーバの各々について、アドレス及びそれぞれのカウンタを含む第１の表を準備するステップと、前記アドレス解決プロセス・キャッシュをキャッシュ・ダンプにダンプするステップと、前記キャッシュ・ダンプ内の各々のアドレスについて、前記キャッシュ・ダンプ内の前記アドレスが前記第１の表内のアドレスと一致する場合には、それぞれのカウンタを増分するステップと、前記複数のカウンタを互いに比較して、前記第２のサーバ間のロード不均衡が閾値より大きいかどうかを判断するステップと、前記ロード不均衡が前記閾値より大きい場合には、前記ロード不均衡に関するメッセージをオペレータ・コンソールに送信するステップとを実行するプログラムと、
   を含むネットワーク。
6. 前記プログラムが前記ステップを繰り返し実行し、前記アドレス解決プロトコル・キャッシュが各前記ダンプするステップの後でクリアされる、請求項５に記載のネットワーク。
7. 前記準備するステップは、最初に実行された後は、サーバが前記複数の第２のサーバに加えられたか又はこれから除去された場合にのみ実行される、請求項５に記載のネットワーク。
8. 機械可読フォーマットのコンピュータ・プログラム製品であって、
   複数のサーバの各々について、アドレス及びそれぞれの第１のカウンタを含む第１の表を準備する第１の命令と、
   キャッシュ・ダンプを形成するために、アドレス解決プロトコル・キャッシュをダンプする第２の命令と、
   前記キャッシュ・ダンプ内の各々のアドレスと一致する前記第１の表内の各々のアドレスについて、前記第１の表内のそれぞれのカウンタを増分する第３の命令と、
   前記第１のカウンタを互いに比較して、前記第２のサーバ間のロード不均衡が閾値より大きいかどうかを判断する第４の命令と、
   前記ロード不均衡が前記閾値より大きい場合には、前記ロード不均衡に関するメッセージをオペレータ・コンソールに送信する第５の命令と、
   を含む、コンピュータ・プログラム製品。
9. 前記プログラムが前記ステップを繰り返し実行し、前記アドレス解決プロトコル・キャッシュが各前記ダンプするステップの後でクリアされる、請求項８に記載のコンピュータ・プログラム製品。
10. 前記第１の命令は、最初に実行された後は、サーバが前記複数の第２のサーバに加えられたか又はこれから除去された場合にのみ実行される、請求項８に記載のコンピュータ・プログラム製品。
11. 前記プログラムが、前記第２のサーバの各々のサーバが所与の期間にわたりアクティブであった時間の相対量の報告を提供する第１１の命令をさらに含む、請求項８に記載のコンピュータ・プログラム製品。

Images