JP5062979B2

JP5062979B2 - 分散コンピュータ・システムをトラブルシューティングするため、またはアプリケーション・データフローを見出すためのシステム、方法、およびコンピュータ・プログラム

Info

Publication number: JP5062979B2
Application number: JP2005259922A
Authority: JP
Inventors: エイ・ケイ・エム・カムラル・アラム; ヴャチェスラフ・バルスク
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2004-09-14
Filing date: 2005-09-07
Publication date: 2012-10-31
Anticipated expiration: 2025-09-07
Also published as: CN100369420C; CN1750479A; US7603459B2; JP2006085700A; US20060075089A1

Description

本発明は、一般に、分散コンピュータ・システムに関する。より具体的には、本発明は、分散コンピュータ・システムにおいて問題をトラブルシューティングするため、またはアプリケーション・データフローを判定するためのシステム、方法、およびコンピュータ・プログラムに関する。

今日では、分散コンピュータ・システムは公知である。分散コンピュータ・システムは、クライアント・ワークステーションの処理をするために、ネットワークを介して相互接続された多数のサーバを含む。例えば、クライアント・ワークステーションがウェブ・サービスをリクエストし、そのリクエストは、分散コンピュータ・システム内でプロキシサーバからウェブサーバに送られる。ウェブサーバ自体は、全てのアプリケーションまたはデータを保有し、クライアント・リクエストに完全に応答することができない。こうした場合には、ウェブサーバは、クライアント・リクエストの一部または全てを別のサーバに送信するか、または他のサーバについての別のリクエストを生成し、必要なサービスまたはデータを得ることができる。例えば、クライアント・リクエストが、飛行機のチケットの手配、ホテルの予約、レンタカーの手配などの複数の旅行の予約に関する場合、フロントエンドのウェブサーバは、クライアントへのインターフェースとして働く。飛行機のチケットについてクライアントからリクエストを受信すると、フロントエンド・ウェブサーバは、そのリクエストを飛行機予約アプリケーションが動作している別のサーバにネットワークを介して送信する。同様に、ホテルの予約についてクライアントからリクエストを受信すると、フロントエンド・ウェブサーバは、リクエストをホテル予約アプリケーションが動作している別のサーバにネットワークを介して送信する。同様に、レンタカーについてクライアントからリクエストを受信すると、フロントエンド・ウェブサーバは、リクエストをレンタカー・アプリケーションが動作している別のサーバにネットワークを介して送信する。この例においては、これらの他のサービスの各々自体が、対応するデータベースを管理するわけではないので、これらの他のサービスの各々は、それぞれのネットワークを介して、それぞれのデータベースから対応するデータ（すなわち、予約状況、価格など）をリクエストする。したがって、この例においては、複合的な旅行予約についての顧客リクエストに応答するために、多数のサーバを必要とすることになる。同様に、クライアント・リクエストの処理時にアプリケーション・サーバを助けるために、メッセージング・サーバ、認証サーバ、バッチ・サーバ、またはレポーティング（ｒｅｐｏｒｔｉｎｇ）サーバのような他のタイプのサーバ・アプリケーションを必要とすることもある。

複合的な旅行予約についての顧客リクエスト（または他のタイプのサーバ・アプリケーションからの助けを必要とする別のサービスについての顧客リクエスト）に適切に応答するためには、必要なサーバの全てを作動させなければならず、それらのサーバ間のネットワーク接続の全てが活動状態でなければならない。（いずれかのサーバがクラスタ内にある場合には、そのクラスタ内の少なくとも１つのサーバが動作していなければならない。）しかしながら、場合によっては、サーバ（またはサーバ・クラスタ）、あるいはサーバ（またはサーバ・クラスタ）間のネットワーク接続に障害が生じることがある。問題のトラブルシューティングを担当するシステム管理者には、障害箇所またはその障害の性質さえも明らかではない。サーバ間に同時に多数の活動状態のポートおよびネットワーク接続があり得るという事実により、タスクのトラブルシューティングが複雑なものになっている。また、分散コンピュータ・システムの構成を変えることができるが、このことをトラブルシューティングの文書化に反映させることができない。したがって、どのサーバをトラブルシューティングすべきかを判定することは困難である。

したがって、本発明の目的は、障害が生じたネットワーク接続または関連するサーバの識別を容易にすることである。

本発明は、クライアント・リクエストを処理するために必要とされる可能性がある活動状態の接続（ａｃｔｉｖｅｃｏｎｎｅｃｔｉｏｎ）を判定（ｄｅｔｅｒｍｉｎｅ）するためのシステム、方法、およびコンピュータ・プログラムを提供する。コンピュータ・プログラムは、第１のサーバと複数の他のサーバとの間の活動状態の接続を繰り返し検知するステップと、第１のサーバと複数のサーバそれぞれとの間の活動状態の接続が検知された頻度を判定するステップをコンピュータに実行させる。好ましくは、コンピュータ・プログラムは、活動状態の接続それぞれが最後に検知されたときを判定するステップをコンピュータに実行させる。さらに、コンピュータ・プログラムは、活動状態の接続、活動状態の接続が検知された頻度、および活動状態の接続が最後に検知されたとき、をリストするテーブルを形成するステップをコンピュータに実行させる。テーブルを形成するステップにおいては、検出するステップにおいて最新の繰り返し周期に活動状態として検知されなかった活動状態の接続をテーブルにおいて強調表示することが好ましい。

好ましくは、コンピュータ・プログラムは、システム機能のために使用されるポート、またはユーザ・クライアントからのリクエストを受信するために使用されるポートを使用しない複数の活動状態の接続を識別する。また、コンピュータ・プログラムが、活動状態の接続のうち第１のサーバ上のリスニング・ポートを使用するものを識別するステップをさらにコンピュータに実行させるようにすることもできる。さらに、コンピュータ・プログラムが、システム機能のために使用されるポートまたはユーザ・クライアントからリクエストを受信するために使用されるポートを使用しない活動状態の接続を識別するステップをさらにコンピュータに実行させるようにすることもできる。

本発明が、図面に関連して詳細に説明される。図１は、プロキシサーバ１１−１３、（バックアップの負荷平衡サーバ１５を有する）負荷平衡サーバ１４、関連したアプリケーション・サーバ１６−１８、データベース・サーバ１９、メッセージング・サーバ２０、認証サーバ２１、バッチ・サーバ２２、レポーティング・サーバ２３、および別のアプリケーション・サーバ２４を含む分散コンピュータ・システム１０を示す。イントラネット４３上のクライアント・コンピュータ４０、４２は、ファイアウォール４４および（インターネットのような）ネットワーク５０を介して、プロキシサーバ１１、１２、１３にアクセスする。ＴＣＰ／ＩＰネットワーク、ＬＡＮ、またはＷＡＮのようなネットワーク５２は、プロキシサーバ１１、１２、１３を負荷平衡サーバ１４、１５に接続する。プロキシサーバは、ウェブサイトのホームページＵＲＬに常駐し、そのＵＲＬ内の修飾子として指定されるアプリケーションに、クライアント・リクエストを送信することができる。図示される例においては、アプリケーション・サーバ１６−１８は、クラスタ状に構成される。アプリケーション・サーバ１６−１８の性質は、本発明にとって重要ではないが、そのアプリケーション・サーバ１６−１８は、クライアント・リクエストを処理するために、サービスのための他のサーバ１９−２３に依存するようにすることができる。ＴＣＰ／ＩＰネットワーク、ＬＡＮ、またはＷＡＮのようなネットワーク５４が、アプリケーション・サーバ１６−１８をサーバ１９−２４に接続する。データベース・サーバ１９は、アプリケーション・サーバ１６−１８が必要とされるデータを格納できるデータベースを管理し、クライアント・リクエストに応答することができる。メッセージング・サーバ２０はデータのメッセージをキューに入れ、ＩＢＭＭＱシリーズ・ソフトウェアのようなアプリケーションの間に送信する。認証サーバ２１は、アプリケーションおよびユーザからの認証／ログインリクエストを処理する。バッチ・サーバ２２は、連続化されたリクエストのバッチ処理を行う。レポーティング・サーバ２３は、アクセス率や使用方法といった種々のアプリケーション統計データを集める。アプリケーション・サーバ２４は、アプリケーション・サーバ１６−１８が必要とされる付加的なサービスを提供し、クライアント・リクエストに応答する。他のタイプのサーバは、アプリケーション・サーバ１６−１８と協働して、クライアント・リクエストを処理することができる。

以下に詳細に説明されるように、活動状態のネットワーク接続を確立することによって、種々のサーバが互いに通信する。各々のネットワーク接続は、ソケットの対すなわちローカル・ソケットおよび外部ソケットによって表すことができる。「ソケット」は、ネットワーク・アドレスおよびポートの組み合わせであり、接続の一方の端を表す。各々の「接続」は、指向性を有する。一方のソケットは、「サーバ」ソケット、すなわちリクエストを受信（供給）するソケットである。他方のソケットは、「クライアント」ソケット、すなわちリクエストの開始／送信をするソケットである。各々の「サーバ」ソケットのポートは、常に固定され、アプリケーションによって予め決定される。多くのサーバ・ソケット・ポートの各々の識別（一般的には、数）は、「クライアント」が知っているので、クライアントは、そのクライアントのリクエストを適切なサーバ・ポートにアドレス指定する。サーバ・ポートの例は、ｈｔｔｐリクエストに対する「８０」およびｈｔｔｐリクエストに対する「４４３」である。「クライアント」ソケットのポートは、クライアント・オペレーティング・システムによって、ランダムに割り当てられる。

ネットワーク接続分析プログラム１３０が、トラブルシューティング用コンピュータ１２０上で動作する。ネットワーク接続エージェント・プログラム７１−８４が、それぞれサーバ１１−２４上で動作する。以下に詳細に説明されるように、エージェント・プログラムは、それぞれのサーバに質問し、サーバが現在どのポートを使用しているかを識別し、他の開始パートナーからの通信、およびその開始パートナーの識別をリッスン（ｌｉｓｔｅｎ）する。これらは、２つのコンピュータ間の「活動状態の」接続である。エージェント・プログラムは、これらのポート、そのポートの状態、およびそのポートの開始パートナーを分析プログラム１３０に報告する。次に、分析プログラム１３０は、ポート、そのポートの状態、およびパートナー・サーバ、並びにポート・サンプリング時間を中央データベース１４０に記録する。このことにより、およそある時点で、活動状態の接続のスナップショット、すなわちポート、そのポートの状態、およびそのポートのパートナーが形成される。次に、分析プログラム１３０は、サーバ間の接続のために、これらのポートのどれを使用し、種々のクライアントからのリクエストを処理できるかを判定する。これらは、「持続的接続（ｐｅｒｓｉｓｔｅｎｔｃｏｎｎｅｃｔｉｏｎ）」と考えられ、クライアント・リクエストを処理するために何度も必要だと考えられるので、トラブルシューティングのためのベースラインとして働く。クライアントとサーバとの間のような、他の低頻度の／一時的な接続は、「持続的」と考えられないかまたはベースライン内に含まれる。分散コンピュータ・システム内のどこかにその後の障害がある場合には、管理者は、現在の活動状態の接続をベースライン、持続的接続と比較し、ベースライン、持続的接続のいずれかが欠落しているかどうかを判定する。欠落している場合には、このことにより、問題の原因、すなわち過去に持続的接続がなされたが、現在は活動状態にない２つのサーバの１つを識別することができる。管理者によるリクエスト時に、分析プログラム１３０は、指定のサーバについての全ての接続をテーブルで示し、そのサーバへの接続の多くが活動状態にないものの、ベースラインから予想されるかどうかを判定する。この場合、このことが、このサーバが有する問題を示す傾向がある。

図２は、前述のプロセスをより詳細に示す。ステップ２００において、エージェント・プログラム７１−８４が、周知の「ｎｅｔｓｔａｔ−ａｎ」コマンドまたは同等コマンドを用いて、それぞれのサーバ内のオペレーティング・システムに質問して、このサーバについての全ての空きポートを識別し、これらのポートを通してなされる接続／セッションについての情報を獲得する。（「ｎｅｔｓｔａｔ−ａｎ」コマンドは、Ｕｎｉｘ（商標）オペレーティング・システムにおいて周知のものである。「Ｎｅｔｓｔａｔ」は、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（商標）オペレーティング・システムにおいて周知の同等コマンドである。）ｎｅｔｓｔａｔ−ａｎコマンドへの応答は、サーバについての全ての空きポートのリスト、接続のために用いられるプロトコル・タイプ（例えば、ＴＣＰまたはＵＤＰ）、ローカルＩＰアドレスおよびポート番号、外部ＩＰアドレスおよびポート番号、並びに接続／セッションの状態を含む。接続「状態」は、接続についてのそれぞれのソケットの組み合わせの状態を表す。状態の例は、ＬＩＳＴＥＮ、ＥＳＴＡＢＬＩＳＨＥＤ、ＣＬＯＳＥ＿ＷＡＩＴ、およびＴＩＭＥ＿ＷＡＩＴである。ＬＩＳＴＥＮ状態は、ソケットが、ユーザまたはサーバ・アプリケーションからのリクエストを受信するために、リスニング／サービス・モードにあることを示す。図示される例においては、アプリケーション・サーバ１６、１７、または１８は、（リスニング）サーバ１９−２４にそれぞれのサービスをリクエストすることができる。ＬＩＳＴＥＮ状態は、リクエストを受信し、リクエストされたサービスを与えることができるコンピュータ（サーバ１９−２４のような）の特性である。同様に、プロキシサーバ１１−１３の１つが（負荷平衡サーバ１４を介して）サーバ１６−１８の１つにユーザリクエストを送信するとき、１つのプロキシサーバ１１−１３と１つのサーバ１６−１８との間に接続があり、その１つのサーバ１６−１８は、この接続におけるリスナーであると考えられる。

各々のサーバ上のエージェント・プログラムは、状態がＬＩＳＴＥＮである場合に、ｎｅｔｓｔａｔ−ａｎコマンドへの応答から記録を選択し、これらの選択された記録からポート番号を取り出すことによって、そのサーバについてのリスニング（ソケット）ポートのリストを構築する。サーバがリクエストされたサービスを与える役割を果たしている場合、これらがポートの記録である。各々のサーバ上のエージェント・プログラムはまた、状態がＥＳＴＡＢＬＩＳＨＥＤ、ＣＬＯＳＥ＿ＷＡＩＴである場合に、ｎｅｔｓｔａｔ−ａｎコマンドへの応答から記録を選択し、これらの選択された記録からポート番号を取り出すことによって、そのサーバについての非リスニング（ソケット）ポートのリストも構築する。サーバがリクエストを行うかまたはリクエストを送信する役割を果たしている場合、これらがポートの記録である。次のものは、コマンド「ｎｅｔｓｔａｔ−ａｎ」が、ＩＰアドレス９．１７．１００．１０を有するローカル・サーバ上で実行される時の例である。以下の応答：

プロトコルローカル・アドレス外部アドレス状態
tcp *.50504 *．* LISTEN
tcp 9.17.100.10.50504 9.100.20.100.1111 ESTABLISHED
tcp 9.17.100.10.1112 9.100.20.101.2000 ESTABLISHED

状態「ＬＩＳＴＥＮ」を含む行は、ローカル・サーバがポート５０５０４をリッスンすることを示す。状態「ＥＳＴＡＢＬＩＳＨＥＤ」を有する次の行は、ローカル・サーバとＩＰアドレス９．１００．２０．１００を有する別の遠隔サーバとの間の接続を示す。この接続のためのローカル・ソケットは、ポート５０５０４を示す。遠隔ソケット・ポートは、１１１１である。ローカル・ポートは、この接続についてのローカル・サーバのリスナー・ポート・リストに属するので、このローカル・サーバは、サービスを遠隔サーバに提供する。状態「ＥＳＴＡＢＬＩＳＨＥＤ」を有する次の行は、このサーバとＩＰアドレス９．１００．２０．１０１を有する別の遠隔サーバとの間の接続を示す。この接続のための遠隔ソケットは、ポート１１１２を示す。遠隔ソケット・ポートは２０００である。ローカル・ポートは、この接続についてのローカル・サーバのリスナー・ポート・リストに属さないので、このローカル・サーバは、遠隔サーバからサービスをリクエストし、その遠隔サーバは、ポート２０００をリッスンする。

ローカル・サーバと２つの遠隔サーバとの間のデータフローを判定するためには、ローカル・サーバ上のデータを分析するだけで十分である。遠隔サーバは、ローカル・サーバに対して反対の接続性を有する。しかしながら、遠隔サーバ上で動作しているエージェント・プログラムは、その遠隔サーバとさらに他のサーバとの間の接続性の発見を可能にする。

２つのコンピュータ間に多数の空き接続があることが多い。接続の一部は長時間持続し、他のものは現れてはすぐ消えるが、両方のタイプとも「持続的」と考えられる。リクエスト中のコンピュータが、同じタイプのサービスのための保守用コンピュータと多数の接続を有する場合には、全てのリクエストがその保守用コンピュータにおいて同じソケットを用いるが、リクエスト中のコンピュータにおいては異なるソケットがある。本発明の一実施形態においては、各々の（ローカル）サーバ上のエージェント・プログラムが、共通の外部サーバに基づいて接続／セッションをひとまとめにし、リンクの最終テーブル（すなわち、サーバ・アドレス、クライアント・アドレス、およびサーバ・ポート）を示す。「サーバ・アドレス」は、ローカル・サーバに対して局所的にも遠隔にもすることができる。次に、トラブルシューティング用コンピュータ１２０において、エージェント・プログラムは、それぞれのリストを分析プログラム１３０に送信する（ステップ２０４）。代替的に、エージェント・プログラムの各々は、ｎｅｔｓｔａｔ−ａｎコマンドを介して得られた情報を分析プログラム１３０に送り、その分析プログラム１３０は、各々のサーバについて前述のリストを構築する。

受信後（または前述のリストの構築後）、分析プログラム１３０は、ベースライン内に含ませるべきでない、持続的なサーバ・アプリケーション間の接続である可能性が高くない活動状態の接続を、次の方法でフィルタをかけて除去／削除する（ステップ２１０）。したがって、分析プログラム１３０は、他のシステム機能、すなわちクライアント／顧客リクエストのアプリケーション処理に関連しない機能を処理することになる、その分析プログラム１３０により推測されるこれらの活動状態の接続を、フィルタをかけて除去する。システム機能の例は、タイム・サービス、管理者によるログオン、データ・バックアップ、遠隔設定およびサービスを可能にするネットワーク・インストール管理、保守ファイルのＦＴＰ送信またはプログラム更新、管理者の有効ユーザＩＤ／パスワードの組み合わせのリストの伝送、システム管理者のログオンのための非暗号化情報の通信などである。分析プログラム１３０は、一般にこれらの他のシステム機能を処理するために用いられる特定のタイプおよび範囲のポート番号のリストを有する。例えば、システム機能は、一般に、システム管理者のログオンのための暗号化通信用ＳＳＨポート、システム管理者のログオンのための非暗号化通信用Ｔｅｌｎｅｔポート、ファイルを保守し、プログラムを更新するためのＦＴＰポートを用いる。同様に、一般に、ポート番号１−１０２４が一般的なシステム機能のために使用されるので、分析プログラム１３０は、これらのポートについての活動状態の接続の記録を、フィルタをかけて除去する。分析プログラム１３０はまた、ポート８０および４４３といった、クライアント（図示される例においては、クライアント・コンピュータ４２）からのリクエストを直接受信するために、一般にサーバによって使用されるこれらのポートについての記録もフィルタをかけて除去する。

活動状態の接続のデータベース１４０から、これらのシステム機能のポートおよびクライアント・ポートを削除した後、残りのポート（活動状態の接続を有する）は、（付加的な接続はリスト内に残ることができるが）クライアント・リクエストに従って、サーバ・アプリケーション間の接続のために使用されると考えられる。この時点で、トラブルシューティング用コンピュータ１２０の何らかの停止に誰も気づかなかったと仮定すると、分析プログラム１３０は、活動状態の接続ポートのフィルタがかけられたリストを、クライアント・リクエストを処理するために、通常のサーバ・アプリケーション間の機能を処理することが必要だと考えられる活動状態の接続の「ベースライン」すなわち基準リストとして扱う。

次に、分析プログラム１３０は、１つの列は、活動状態のポートがリスニング・モードにあるサーバについてのものであり、別の列は、活動状態のポートがリスニング・モードにないパートナー・サーバについてのものである、サーバ間活動状態接続テーブルを形成する（ステップ２２０）。このテーブルは、中央データベース１４０内に格納される。分析プログラム１３０は、データベース内の記録の固有性を保証する。一般的に、１つのサーバは、同時に数百の活動状態の接続を有することができるが、それらを、ごくわずかのサーバ間のものにすることができる。したがって、本発明の一実施形態においては、分析プログラム１３０は、２つのサーバ間の異なるポート上の多数の接続を１つの指向性接続として扱い、これらの全ての接続をテーブル内の１行の入力としてひとまとめにする。サーバ間活動状態接続テーブルは、リスニング・モードのサーバとそれぞれのパートナー・サーバとの間に少なくとも１つの活動状態の接続が検知された時の多数のサンプル時間を示す列と、同じ２つのサーバ間にこうした接続が検知された時の最後のサンプル時間を示す別の列とを含む。本発明のこの実施形態においては、サーバ間活動状態接続テーブルは、次のカテゴリー、すなわち、
リスニング・サーバのＩＰアドレス、パートナー・サーバのＩＰアドレス、接続数、最後の接続時間
を含む。

本発明の別の実施形態において、分析プログラム１３０は、各々のサーバおよび各々のパートナー・サーバの各々のリスニング・ポートについて別個の行入力を有するサーバ間活動状態接続テーブルを作成する。この行入力は、このリスニング・ポートと同じパートナー・サーバとの間の接続数と、このリスニング・ポートとパートナー・サーバとの間の最後の接続時間とを示す（リスニング・サーバのＩＰアドレスおよびパートナー・サーバのＩＰアドレスに加えて）。この付加された情報を用いる場合、ポート８０（ＨＴＴＰ）またはポート３８６（ＬＤＡＰ）のような特定のポートだけについて接続を分析し、トラブルシューティングをさらに助けることができる。一部の接続は１方向に機能するが他のものは機能しないので、このことは有用であり、ポートの仕様が、障害の局所化を助長する。

ステップ２００−２２０の第１の反復（ｉｔｅｒａｔｉｏｎ）、すなわち繰り返し周期の間、対応する２つのサーバ間に少なくとも１つの接続が検知される場合、「サンプル数」が、各々の入力について１に設定される。前述のステップ２００―２２０は、例えば、１０分毎といった次のエージェント・プログラム・サンプリング時間で繰り返される。この次のステップ２００―２２０の反復後、サーバ間活動状態接続入力の現在のリストが、既存のサーバ間活動状態接続テーブルのものと比較される（ステップ２３４）。リスニング・サーバおよびパートナー・サーバの対についての現在のリストに、既存のテーブル内に現れない何らかの検知された接続がある場合には、それらが、サーバ間活動状態接続テーブルに付加され、サンプル数が１に設定され、時間列が現在のサンプル時間に設定される（ステップ２３６）。既存のテーブル内に既に現れた、リスニング・サーバおよびパートナー・サーバの対についての現在のリスト内に、検知された何らかの接続がある場合には、サンプル数がインクリメントされ、時間列は現在のサンプル時間に設定される（ステップ２３８）。このように、サンプル数の値は、これらの２つのサーバ間の接続の持続性、すなわちクライアント・リクエストを処理するために使用される可能性が高い接続を示す。サンプル時間の入力は、この接続が現在活動状態かどうかを示し、現在活動状態にない場合には、対応するサーバを停止させることができる。

高い値のサンプル数を有する接続は、２つのサーバ・アプリケーション間（異なるサーバにおける）、アプリケーション・サーバとデータベース・マネージャーとの間、またはアプリケーション・サーバとサーバ２０−２４のいずれかとの間の接続のような、クライアント・リクエストの通常の処理のために必要とされる可能性が高い接続を示す。フロントエンド・サーバが顧客へのインターフェースである場合の複合的な旅行予約を必要とされるクライアント／顧客の例においては、アプリケーション・サーバ１６−１８と、飛行機予約アプリケーション、ホテル予約アプリケーション、およびレンタカー予約アプリケーションのホストとして働くアプリケーション・サーバ２４（または図２に図示されていない他の関連したサーバ）との間の接続についてのサンプル数が高い値になる可能性がある。飛行機予約アプリケーションと飛行機データベース・サーバとの間、ホテル予約アプリケーションとホテル・データベース・サーバとの間、およびレンタカー予約アプリケーションとレンタカー・データベース・サーバとの間の接続についても高い値になる可能性がある（図２に図示されていない）。

ステップ２４０において、例えば、通常のクライアント・リクエストの処理と関連しない低頻度または不規則な接続を示す、１週間に１度以下程度の間隔のようなサンプル数が少ない場合には、分析プログラム１３０は、それらの入力（列）をサーバ間活動状態接続テーブルから削除する。例えば、管理者は、たまにプローブを動作させるときなど、サーバ・アプリケーション・ポートに対してサーバ・アプリケーションを用いるサーバを試験することができる。こうした試験は、ほとんど行われず、通常のクライアント・リクエストと関連したものではない。また、特定の接続が１ヶ月のような所定の期間活動状態になかった場合、分析プログラム１３０は、この接続をサーバ間テーブルから削除する。このように、ステップ２４０は、更なるフィルタ操作を行い、「持続的」である可能性が高くない活動状態の接続を削除するステップを表す。

分散ネットワークに関連した問題がある場合、システム管理者は、サーバ間活動状態接続テーブルを見るようにリクエストすることができる（決定２４４）。これに応答して、分析プログラム１３０は、テーブルを表示し、最新のサンプリングが活動状態のものとして示さなかった（履歴的に持続的な）接続を強調表示する（ステップ２５０）。強調表示された入力接続の１以上が高い値のサンプル数を有する場合、こうすることによって、顧客の遭遇した問題の原因（たとえば、リッスン・サーバ、パートナー・サーバ、またはその間のネットワークがダウンしたこと、あるいは他の理由のためにこの接続が失われたこと）が分離（ｉｓｏｌａｔｅ）される。逆に、サンプル番号の値が大きいが、顧客のクレームの前にかなりの時間活動状態になかった場合、この接続の喪失が、顧客の問題の原因ではないことを示す傾向がある。また、ある状況においては、履歴テーブル内に低いサンプル数を有する現在の接続がないことが、依然として、顧客が遭遇した問題の原因を示すことがある。例えば、システム管理者が、最近、あるデータベース・サーバから別のデータベース・サーバにアプリケーション・サーバを切り換えた場合には、新しいデータベースへの接続についてのサンプル数は低くなるが、それにもかかわらず、これは重要な接続である。

同様に、場合によっては、サンプリング時に２つのサーバ間に活動状態の接続が存在しないが、これはサーバのいずれかの故障によるものではない。むしろ、通常の作動中、接続は、頻繁に始まったり終わったりする。それにもかかわらず、統計的には、この状況は、通常クライアント・リクエストを処理するために協働する２つのサーバ間で頻繁に生じるものではない。

以上のことに基づいて、持続的なサーバ間の活動状態の接続を識別し、こうした識別を用いて分散コンピュータ・システム内の障害をトラブルシューティングするためのシステム、方法、およびコンピュータ・プログラムが開示された。しかしながら、本発明の範囲から逸脱することなく、多数の修正および代替をなすことができる。したがって、本発明の実施の形態は例示であり、本発明を制限するものとして解釈されるべきではない。本発明の範囲は、特許請求の範囲を記載により決定すべきである。

本発明の実施形態における分散コンピュータ・システムのブロック図である。図１の分散コンピュータ・システムのトラブルシューティング用コンピュータ内のネットワーク接続分析プログラムの作動を示すフローチャートである。

１０：分散コンピュータ・システム
１１、１２、１３：プロキシサーバ
１６、１７、１８：アプリケーション・サーバ
１９：データベース・サーバ
２０：メッセージング・サーバ
２１：認証サーバ
２２：バッチ・サーバ
２３：レポーティング・サーバ
２４：アプリケーション・サーバ
１２０：トラブルシューティング用コンピュータ
１３０：ネットワーク接続分析プログラム
１４０：データベース

Claims

クライアント・リクエストを処理するために必要とされる可能性がある活動状態の接続を判定する方法であって、
第１のサーバと複数の他のサーバとの間の活動状態の接続を繰り返し検知するステップと、
前記第１のサーバと前記複数の他のサーバそれぞれとの間の活動状態の接続が検知された頻度を判定するステップと、
前記活動状態の接続のそれぞれが最後に検知されたときを判定するステップと、
前記活動状態の接続、前記活動状態の接続が検知された頻度、および前記活動状態の接続のそれぞれが最後に検知されたとき、をリストするテーブルを形成するステップと
を含み、
前記繰り返し検知するステップが、前記第１のサーバ上で活動状態の複数の接続を検知し、そして、システム機能のために使用されるポートを利用する１以上の活動状態の接続を、フィルタをかけて除去することによって、前記第１のサーバと前記複数の他のサーバとの間の前記活動状態の接続を識別するステップを含む、前記方法。
クライアント・リクエストを処理するために必要とされる可能性がある活動状態の接続を判定する方法であって、
第１のサーバと複数の他のサーバとの間の活動状態の接続を繰り返し検知するステップと、
前記第１のサーバと前記複数の他のサーバそれぞれとの間の活動状態の接続が検知された頻度を判定するステップと、
前記活動状態の接続のそれぞれが最後に検知されたときを判定するステップと、
前記活動状態の接続、前記活動状態の接続が検知された頻度、および前記活動状態の接続のそれぞれが最後に検知されたとき、をリストするテーブルを形成するステップと
を含み、
前記繰り返し検知するステップが、前記第１のサーバ上で活動状態の複数の接続を検知するステップと、システム機能のために使用されるポートを利用する１以上の活動状態の接続を、フィルタをかけて除去するステップとを含む、前記方法。
前記テーブルを形成するステップは、前記検知するステップにおいて最新の繰り返し周期に活動状態として検知されなかった前記活動状態の接続を前記テーブルにおいて強調表示するステップを含む、請求項１又は２に記載の方法。
前記活動状態の接続のうち前記第１のサーバ上のリスニング・ポートを使用するものを識別するステップをさらに含む、請求項１〜３のいずれか一項に記載の方法。
前記検知するステップが、ユーザ・クライアントからリクエストを受信するために使用されるポートを利用する１以上の活動状態の接続を、フィルタをかけて除去する識別するステップを含む、請求項１〜４のいずれか一項に記載の方法。
前記検知するステップが、ユーザ・クライアントからリクエストを受信するために使用されるポートを利用する１以上の活動状態の接続を、フィルタをかけて除去する識別することによって、前記第１のサーバと前記複数の他のサーバとの間の前記活動状態の接続を識別するステップを含む、請求項１〜４のいずれか一項に記載の方法。
クライアント・リクエストを処理するために必要とされる可能性がある活動状態の接続を見出すためのコンピュータ・システムであって、
第１のサーバと複数の他のサーバとの間の活動状態の接続を繰り返し検知するための手段と、
前記第１のサーバと前記複数の他のサーバのそれぞれとの間の活動状態の接続が検知された頻度を判定するための手段と、
前記活動状態の接続のそれぞれが最後に検知されたときを判定するための手段と、
前記活動状態の接続、前記活動状態の接続が検知された頻度、および前記活動状態の接続のそれぞれが最後に検知されたとき、をリストするテーブルを形成するための手段と、
を備えており、
前記繰り返し検知するための手段が、前記第１のサーバ上で活動状態の複数の接続を検知し、そして、システム機能のために使用されるポートを利用する１以上の活動状態の接続をフィルタをかけて除去することによって、前記第１のサーバと前記複数の他のサーバとの間の前記活動状態の接続を識別する、前記コンピュータ・システム。
クライアント・リクエストを処理するために必要とされる可能性がある活動状態の接続を見出すためのコンピュータ・システムであって、
第１のサーバと複数の他のサーバとの間の活動状態の接続を繰り返し検知するための手段と、
前記第１のサーバと前記複数の他のサーバのそれぞれとの間の活動状態の接続が検知された頻度を判定するための手段と、
前記活動状態の接続のそれぞれが最後に検知されたときを判定するための手段と、
前記活動状態の接続、前記活動状態の接続が検知された頻度、および前記活動状態の接続のそれぞれが最後に検知されたとき、をリストするテーブルを形成するための手段と、
を備えており、
前記繰り返し検知するための手段が、前記第１のサーバ上で活動状態の複数の接続を検知するステップと、システム機能のために使用されるポートを利用する１以上の活動状態の接続を、フィルタをかけて除去する、前記コンピュータ・システム。
前記テーブルを形成するための手段は、前記検知するための手段において最新の繰り返し周期に活動状態として検知されなかった前記活動状態の接続を前記テーブルにおいて強調表示する、請求項７又は８に記載のコンピュータ・システム。
前記活動状態の接続のうち前記第１のサーバ上のリスニング・ポートを使用するものを識別するための手段をさらに備えている、請求項７〜９に記載のコンピュータ・システム。
前記検知するための手段が、ユーザ・クライアントからリクエストを受信するために使用されるポートを利用する１以上の活動状態の接続を、フィルタをかけて除去する識別する、請求項７〜１０のいずれか一項に記載のコンピュータ・システム。
前記検知するための手段が、ユーザ・クライアントからリクエストを受信するために使用されるポートを利用する１以上の活動状態の接続を、フィルタをかけて除去する識別することによって、前記第１のサーバと前記複数の他のサーバとの間の前記活動状態の接続を識別する、請求項７〜１０のいずれか一項に記載のコンピュータ・システム。
クライアント・リクエストを処理するために必要とされる可能性がある活動状態の接続を判定するためのコンピュータ・プログラムであって、コンピュータに請求項１〜６のいずれか一項に記載の方法の各ステップを実行させる前記コンピュータ・プログラム。