(57)【要約】【課題】　サーバ・ファームにおけるサーバ障害の診断および自己修復のための方法，システム，および装置を提供すること。【解決手段】　本発明に従って構成されたオートノミック・サーバ・ファーム１２０は、サーバ・ファーム１２０の外部にあるクライアント１１０から受信した要求に応答できる複数のサーバ１５０を含むことができる。ランダム，ラウンドロビン，および最低使用頻度のようなリソース割り振りアルゴリズムに従って、選択されたサーバへ要求を発送するように、ＩＰスプレイヤまたはネットワーク・ディスパッチャ１４０のようなリソース・ディレクタを構成することができる。さらに、障害診断および自己修復の管理がリソース・ディレクタの能力だけに依存する従来のサーバ・ファームと異なり、本発明においては、クライアント支援障害検出ロジックをリソース・ディレクタと接続して、障害診断および自己修復のクライアント支援管理を提供できる。【選択図】　　　図１
2004110790.tif 000002
【特許請求の範囲】
【請求項１】
　サーバ・ファームにおいてサーバ障害を診断し自己修復する方法であって、
　前記サーバ・ファーム内の割り当てサーバとの通信要求／応答セッションを確立しようと試みるクライアントからの再試行要求を受信するステップと、
　前記再試行要求に基づいて前記割り当てサーバの障害の発生を判断するステップと、
　前記割り当てサーバの障害を修復するオペレーションを実行するステップと、を含む方法。
【請求項２】
　前記再試行要求に基づく前記割り当てサーバの障害の発生の判断に応答して、前記サーバ・ファーム内の別のサーバを割り当てて前記再試行要求を処理するステップをさらに含む請求項１記載の方法。
【請求項３】
　前記判断するステップは、前記割り当てサーバの障害の発生の指示を、前記再試行要求に付随する要求ストリング内で発見するステップを含む請求項１記載の方法。
【請求項４】
　前記判断するステップは、前記割り当てサーバの障害の発生の指示を、前記再試行要求に付随するクッキー内で発見するステップを含む請求項１記載の方法。
【請求項５】
　前記実行するステップは、前記最初のサーバの再生，前記最初のサーバ内のデバイスの再始動，および前記最初のサーバ内のアプリケーションの再始動より構成されるグループから選択された少なくとも１つの修復オペレーションを実行するステップを含む請求項１記載の方法。
【請求項６】
　前記実行するステップは、管理ノードに前記障害を通知するステップをさらに含む請求項１記載の方法。
【請求項７】
　前記実行するステップは、
　前記障害を診断するステップと、
　前記診断に基づいて少なくとも１つの修復オペレーションを実行するステップとを含み、前記修復オペレーションは、前記最初のサーバの再生，前記最初のサーバ内のデバイスの再始動，および前記最初のサーバ内のアプリケーションの再始動より構成されるグループから選択される請求項１記載の方法。
【請求項８】
　前記診断するステップは、前記割り当てサーバをpingするステップと、
　前記割り当てサーバと前記クライアントとの間でトレースルートを実行するステップと、を含む請求項７記載の方法。
【請求項９】
　前記診断するステップは、
　前記割り当てサーバにテスト・トランザクションを注入するステップと、
　前記注入によって生じた結果を監視するステップと、を含む請求項７記載の方法。
【請求項１０】
　前記注入するステップは、前記クライアントに前記割り当てサーバへテスト・トランザクションを注入させるステップを含む請求項９記載の方法。
【請求項１１】
　オートノミック・サーバ・ファームであって、
　前記サーバ・ファームの外部にあるクライアントから受信した要求に応答できる複数のサーバと、
　前記複数のサーバのうちの選択されたサーバへ要求を発送するよう構成されたリソース・ディレクタと、
　前記リソース・ディレクタに接続されたクライアント支援障害検出ロジックとを備える
オートノミック・サーバ・ファーム。
【請求項１２】
　前記リソース・ディレクタに通信可能に接続され、前記選択されたサーバの検出障害を診断するよう構成されたドクタをさらに備える請求項１１記載のオートノミック・サーバ・ファーム。
【請求項１３】
　サーバ・ファームにおいてサーバ障害の診断および自己修復を実行するコンピュータ・プログラムを格納するマシン可読ストレージであって、前記コンピュータ・プログラムは、実行されたときに前記マシンに所定のステップを実行させる命令のルーチン・セットを含み、前記所定のステップは、
　前記サーバ・ファーム内の割り当てサーバとの通信要求／応答セッションを確立しようと試みるクライアントからの再試行要求を受信するステップと、
　前記再試行要求に基づいて前記割り当てサーバの障害の発生を判断するステップと、
　前記割り当てサーバの障害を修復するオペレーションを実行するステップと、を含むマシン可読ストレージ。
【請求項１４】
　前記再試行要求に基づく前記割り当てサーバの障害の発生の判断に応答して、前記サーバ・ファーム内の別のサーバを割り当てて前記再試行要求を処理するステップをさらに含む請求項１３記載のマシン可読ストレージ。
【請求項１５】
　前記判断するステップは、前記割り当てサーバの障害の発生の指示を、前記再試行要求に付随する要求ストリング内で発見するステップを含む請求項１３記載のマシン可読ストレージ。
【請求項１６】
　前記判断するステップは、前記割り当てサーバの障害の発生の指示を、前記再試行要求に付随するクッキー内で発見するステップを含む請求項１３記載のマシン可読ストレージ。
【請求項１７】
　前記実行するステップは、前記最初のサーバの再生，前記最初のサーバ内のデバイスの再始動，および前記最初のサーバ内のアプリケーションの再始動より構成されるグループから選択された少なくとも１つの修復オペレーションを実行するステップを含む請求項１３記載のマシン可読ストレージ。
【請求項１８】
　前記実行するステップは、管理ノードに前記障害を通知するステップをさらに含む請求項１３記載のマシン可読ストレージ。
【請求項１９】
　前記実行するステップは、
　前記障害を診断するステップと、
　前記診断に基づいて少なくとも１つの修復オペレーションを実行するステップとを含み、前記修復オペレーションは、前記最初のサーバの再生，前記最初のサーバ内のデバイスの再始動，および前記最初のサーバ内のアプリケーションの再始動より構成されるグループから選択される請求項１３記載のマシン可読ストレージ。
【請求項２０】
　前記診断するステップは、前記割り当てサーバをpingするステップと、
　前記割り当てサーバと前記クライアントとの間でトレースルートを実行するステップと、を含む請求項１９記載のマシン可読ストレージ。
【請求項２１】
　前記診断するステップは、
　前記割り当てサーバにテスト・トランザクションを注入するステップと、
　前記注入によって生じた結果を監視するステップと、を含む請求項１９記載のマシン可読ストレージ。
【請求項２２】
　前記注入するステップは、前記クライアントに前記割り当てサーバへテスト・トランザクションを注入させるステップを含む請求項２１記載のマシン可読ストレージ。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、オートノミック・コンピューティングの分野に関し、特に、サーバ・ファームの自己修復に関する。
【背景技術】
【０００２】
　エンタープライズ・コンピューティングの出現から始まって、コンピュータ・テクノロジの複雑さは、エンタープライズへの配備に利用できる革新的なテクノロジの数の増大と同じペースで急激に増大してきた。ムーアの法則が、情報技術部門において著しい成長を推進し、そしてテクノロジの進歩の礎石としてみなされてきた。それにもかかわらず、新たなコンピュータ・テクノロジを配備し管理する最前線の人々は、価格すなわちテクノロジ・マネジメントがコンピュータ・テクノロジの増大する数および複雑さに比例することを認めた。
【０００３】
　換言すると、エンタープライズ内のそれぞれのコンポーネントを監視し管理しなければならないという要件が与えられたとすると、相互運用性の主要な目的は達成するのがますます困難になる。従来のエンタープライズは少数の標準コンポーネントだけによってあらかじめ構成されていたのに対して、今日のエンタープライズは、それぞれが特定の稼動パラメータ内で高性能に動作し、あるいは特定の稼動パラメータ外で低性能に動作し得る膨大な数の異種のコンポーネントを含むことができる。したがって、一般の人々にとっては、将来の目標が、なおいっそうの能力を有する多くの新たなテクノロジを開発することにあると思われるかもしれないが、当業者は、将来の真の目標が、既に存在すると思われるテクノロジのマネジメント内部にはっきりと存在していることを理解できる。
【０００４】
　有名な声明であるAutonomic Computing：IBM's Perspective on the State of Information Technologyにおいて、IBMリサーチのシニア・バイス・プレジデントであるPaul Hornは以下のように述べた。“我々が直面している問題は、ムーアの法則に遅れを取らないようにすることではなく、むしろその数十年間の支配の結果に対処することである。”この考察を前提として、Hornは生物科学の自律神経系と類似するコンピュータを提案した。すなわち、人間の自律神経系が、人間の器官に対するどのような意識的な作用も伴わずに、監視し、調整し、修復し、コンディションの変化に反応するのに対して、オートノミック・コンピューティング・システムにおいては、コンピュータ・システム・オペレータの器官に対するどのような意識的な作用も必要とせずに、システムが自己調整し、自己修復し、コンディションの変化に反応する必要がある。
【０００５】
　したがって、自律神経系が、複雑さに対処する負担から人間を解放することができる一方、オートノミック・コンピューティング・システムもまたそのように人間を解放することができるのである。逆に、コンピューティング・システム自身は、自身の複雑さに対処する責任を負担することができる。ＩＢＭの声明の最も重要な点は、オートノミック・コンピューティング・システムの８つの主要な特徴に関連する。
I．システムは“自身を理解”しなければならず、またシステムIDを有するシステム・コンポーネントを含まなければならない。
II．システムは、変化しかつ予測できないコンディションのもとで自身を構成しそして再構成できなければならない。
III．システムは現状維持に甘んじてはならず、システムは自身の動作を最適化する方法を常に捜さなければならない。
IV．システムは自己修復でなければならず、自身のパーツの一部を誤動作させるかもしれないルーチン・イベントおよび変則のイベントからリカバリできなければならない。
V．システムは自己防御のエキスパートでなければならない。
VI．システムはその環境と自身のアクティビティを取り囲む状況とを理解し、それに応じて動作しなければならない。
VII．システムはオープン・スタンダードに従わなければならない。
VIII．システムは、自身の複雑さをユーザから隠しておくと同時に、必要とされる最適化リソースを予期しなければならない。
【０００６】
　特に、オートノミック・コンピューティングの８つのテナントに従って、自己構成，自己管理，および自己修復がオートノミック・オペレーションのための基礎を与える様々な単一システムおよびピアツーピア・システムが提案されてきた。しかしながら、オートノミック・コンピューティングの８つのテナントにもかかわらず、サーバ・ファーム内部の自己管理および自己修復を促進するためにサーバ・ファーム内のサーバ・プロセスとクライアント・コンピュータ・デバイスとの相互作用を検討した既存の実装例は存在しない。むしろ、たいていのサーバ・ファームは、定期的なハートビート・メカニズムに依存するか、あるいは、スプレイヤ（sprayer）がサーバを割り当てて着信要求を処理する時にサーバ・ファーム内のサーバの正常性を監視する点での“スプレイヤ”の使用に依存する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
　本発明は、サーバ・ファームにおけるサーバ障害の診断および自己修復のための方法，システムおよび装置を提供する。
【課題を解決するための手段】
【０００８】
　具体的には、本発明は、サーバ・ファームのオートノミック構成を可能にすることができる。本発明に従って構成されたオートノミック・サーバ・ファームは、サーバ・ファームの外部にあるクライアントから受信した要求に応答することができる複数のサーバを含むことができる。ランダム，ラウンドロビン，および最低使用頻度のようなリソース割り振りアルゴリズムに従って、複数のサーバのうちの選択されたサーバへ要求を発送するように、ＩＰスプレイヤまたはネットワーク・ディスパッチャのようなリソース・ディレクタを構成することができる。特に、障害の診断および自己修復の管理がリソース・ディレクタの能力だけに依存する従来のサーバ・ファームと異なり、本発明においては、クライアント支援障害検出ロジックをリソース・ディレクタへ接続して障害診断および自己修復についてのクライアント支援管理を提供することができる。
【０００９】
　サーバ・ファームにおいてサーバ障害を診断し自己修復する方法は、サーバ・ファーム内の割り当てサーバとの通信要求／応答セッションを確立しようと試みるクライアントからの再試行要求を受信するステップを含むことができる。再試行要求に基づいて割り当てサーバの障害の発生を判断することができる。その結果、サーバ・ファーム内の異なるサーバを割り当てて再試行要求を処理することができる。さらに、割り当てサーバの障害を修復するオペレーションを実行することができる。
【００１０】
　本発明の１つの態様において、上記判断するステップは、割り当てサーバの障害の発生の指示を、再試行要求に付随する要求ストリング内で発見するステップを含むことができる。代わりに、上記判断するステップは、割り当てサーバの障害の発生の指示を、再試行要求に付随するクッキー内で発見するステップを含むことができる。最後に、上記実行するステップは、最初のサーバの再生，最初のサーバ内のデバイスの再始動，および最初のサーバ内のアプリケーションの再始動より構成されるグループから選択された少なくとも１つの修復オペレーションを実行するステップを含むことができる。任意で、上記実行するステップは、管理ノードに障害を通知するステップを含んでもよい。
【発明を実施するための最良の形態】
【００１１】
　本発明は、サーバ・ファームにおけるクライアント支援診断および自己修復のための方法，システムおよび装置を提供する。具体的には、本発明によれば、個々のクライアント・コンピュータ・デバイスは、サーバ・ファーム内の１以上のサーバにデータを含むサービスを要求することができる。個々のクライアント・コンピュータ・デバイスから受信したそれぞれの要求に対して、例えばスプレイヤであるネットワーク・ディスパッチング・プロセスは、サーバ・ファーム内の使用可能なサーバへ要求を発送でき、それにより要求クライアントと割り当てサーバとが通信セッションを確立できる。
【００１２】
　割り当てサーバが通信セッションの間に要求クライアントに応答しない状況においては、要求クライアントは、割り当てサーバが要求に応答しなかったという指示と一緒に要求を再試行することができる。この指示は、例えば、障害のあるサーバの直接リファレンス，あるいは相関関係子を含むことができ、この相関関係子に基づいて、ネットワーク・ディスパッチャが障害のあるサーバのＩＤを決定することができる。ネットワーク・ディスパッチング・プロセスは、再試行を受信すると同時に、サーバ・ファーム内の他のサーバへ要求を再び発送することができる。加えて、ネットワーク・ディスパッチング・プロセスは、障害のあるサーバの修復処理、例えば、サーバの再生，サーバ内の特定のアプリケーションまたはプロセスの再始動，およびサーバ・ファーム・アドミニストレータへの通知、を始めることができる。
【００１３】
　このように、サーバ・ファーム内のサーバと対話するクライアント・コンピュータ・デバイスは、ネットワーク・ディスパッチャ内部に実装された診断ツールを用いて以前は不可能であった程度の細分性で、サーバ・ファーム内のサーバの応答性を監視することができる。すなわち、ネットワーク・ディスパッチャ単独では、サーバ・ファーム内の特定のサーバへ最初の要求を発送する時に通信セッションの成功を監視できるだけであるが、本発明においては、通信可能に接続されたクライアントおよびサーバ間のそれぞれの要求の際に通信セッションの成功を監視することができる。したがって、本発明を用いることにより、サーバ・ファームにおけるオートノミック・コンピューティング構成を促進することができる。
【００１４】
　図１は、本発明に係るクライアント支援診断および自己修復用に構成されたサーバ・ファームのブロック図である。サーバ・ファーム１２０は、１以上のサーバ１５０を含むことができ、それぞれのサーバ１５０は、１以上のコンピュータ・プロセス１７０と関連データ１８０とをホスティングする。ネットワーク・ディスパッチャ１４０を構成して、コンピュータ通信ネットワーク１３０を介した１以上のクライアント１１０からの着信要求を受信することができる。ネットワーク・ディスパッチャ１４０は、ラウンドロビン，またはランダム・サーバ選択のような周知のロードバランシング・アルゴリズムに従って、このような着信要求をサーバ１５０のうちの選択されたサーバに発送することができる。任意で管理ノード１６０を設けることができ、この管理ノード１６０によってサーバ・ファーム１２０の構成を管理することができる。
【００１５】
　動作時において、通信セッションを、個々のクライアント１１０とサーバ・ファーム１２０内のサーバ１５０との間で確立することができる。具体的には、個々のクライアント１１０からの最初の要求の受信と同時に、例えばフロントエンドＩＰスプレイヤ，リソース・ディレクタあるいは他のこのようなネットワーク・デバイスであるネットワーク・ディスパッチャ１４０は、ランダム選択，最低使用頻度，もしくはラウンドロビン選択のようなロードバランシングまたは他のサーバ選択アルゴリズムに従って、サーバ・ファーム１２０内のサーバ１５０のうちの選択されたサーバに最初の要求を発送することができる。選択サーバ１５０の割り当てに基づいて、クライアント１１０と選択サーバ１５０との間に通信セッションを確立することができ、この通信セッションの間に、クライアント１１０と選択サーバ１５０との間でセッション親和性（session affinity）を維持することができる。
【００１６】
　クライアント１１０と選択サーバ１５０との通信接続の間に、要求／応答トランザクションが発生し得る。通常、選択サーバ１５０がクライアント１１０からの要求に適切に応答できる場合には、セッション親和性を維持することができる。しかしながら、選択サーバ１５０が要求１９０Ａに応答しない場合には、セッションを確立するための最初の要求の際に障害が発生した場合でさえ、クライアント１１０は再試行１９０Ｂを試みることができる。特に、再試行要求１９０Ｂに加えて、クライアント１１０は、要求１９０Ａに応答しなかった選択サーバ１５０を識別することができる。具体的には、選択サーバ１５０のＩＤを、例えばクッキーとして、あるいは再試行要求ストリング内部に含めることができる。
【００１７】
　どのような場合でも、再試行要求１９０Ｂの検出と同時に、ネットワーク・ディスパッチャ１４０は新しいサーバ１５０を割り当てて再試行要求１９０Ｂに応答することができる。さらに、ネットワーク・ディスパッチャ１４０は、選択サーバ１５０の修復処置を始めることができる。代わりに、ネットワーク・ディスパッチャ１４０と同じノードに位置するかまたは、他のノード内に位置する任意で加えられるドクタ・プロセス１９５が、修復処置を始めてもよい。このような修復処置は、例えば、選択サーバ１５０の再生，選択サーバ１５０内の特定のアプリケーションまたはプロセスの再始動，および管理ノード１６０への通知を含むことができる。
【００１８】
　さらに、本発明は、いずれか１つの最初のタイムアウト条件における応答障害の報告に厳密に限定されるわけではなく、サーバ内のタイムアウト条件だけに基づく障害の発生の判断に厳密に限定されるわけでもない。むしろ、サーバの障害が確認される時期については、要求クライアントは障害が発生したことを決定する前に複数回の対象要求を再試行することができる。さらに、クライアントは、例えばHTTP 4xx通知のような問題のある応答の検査を通じて、障害が発生したことを宣言してもよい。このような問題のある応答は、他の状況ではサーバの障害を示すことができる。
【００１９】
　より具体的には、ネットワーク・ディスパッチャ１４０は、複数のクラスのサーバ障害を処理することができる。例えば、ネットワーク・ディスパッチャ１４０は、クライアント１１０によって送信された要求１９０Ａが割り当てサーバ１５０に到達しないという状況を処理することができる。また、ネットワーク・ディスパッチャ１４０は、割り当てサーバ１５０が結果を生成しないという状況を処理することができる。さらに、ネットワーク・ディスパッチャ１４０は、割り当てサーバ１５０によって生成された結果がクライアント１１０に到達しないという状況を処理することができる。全てのケースにおいて、クライアント１１０と割り当てサーバ１５０との間の要求／応答トランザクションを完成しないことから生じる全ての障害状態を、ネットワーク・ディスパッチャ１４０が処理できるということは当業者にとって明らかである。
【００２０】
　図２は、サーバ・ファームにおけるクライアント支援診断および自己修復のためのプロセスを説明するタイミング図である。まず、ステップ１において、クライアントは要求をスプレイヤへ送ることができる。ステップ２において、スプレイヤは、サーバ・ファーム内の最初に割り当てられたサーバへ要求を発送することができる。最初に割り当てられたサーバが１回以上の試みの後に応答しない場合、またはサーバがエラー通知で応答する場合、あるいは応答から障害を検出できた場合には、ステップ３において、クライアントは再試行を試みることができ、最初に割り当てられたサーバが要求に応答しなかったという指示をこの再試行に含めることができる。
【００２１】
　ステップ４において、サーバ・ファーム内の新しいサーバを割り当ててクライアントの要求を処理する必要性を認めたスプレイヤまたは任意でドクタ・プロセスは、サーバ・ファーム内の次のサーバを割り当てて、再試行要求を含むクライアントからの後続の要求を処理することができる。特に、ラウンドロビン，ランダム，もしくは最低使用頻度のようなリソース管理またはロード・バランシング・アルゴリズムに従って次のサーバを割り当てることができる。どのような場合でも、ステップ５において、最初に割り当てられたサーバの障害を確認したスプレイヤ、または場合によってドクタは、さらに、最初に割り当てられたサーバの状況を診断することができる。
【００２２】
　さらに、スプレイヤまたはドクタ・プロセスは、様々な方法を使用して異なるクラスのサーバ障害を識別することができ、このような様々な方法のそれぞれの使用は、エラーのクラスに依存し得る。例えば、サーバが要求に応答しなかった場合、または応答がクライアントによって受信されなかった場合には、pingおよびトレースルート（traceroute）のような従来のＩＰツールを用いてサーバ障害を診断することができる。これに対して、サーバが要求を受信したが結果を生成しなかった場合には、ドクタは当該疑わしいサーバへ診断トランザクションを注入することができ、あるいはドクタは、クライアントが当該疑わしいサーバへ診断トランザクションを注入することを要求することができる。続いて、ドクタはその結果を監視することができる。
【００２３】
　スプレイヤまたは任意のドクタ・プロセスが障害を確実に識別できる状況においては、スプレイヤは、最初に割り当てられたサーバの再生，または最初に割り当てられたサーバ内のアプリケーションもしくはプロセスの再始動のような修復処置を始めることができる。スプレイヤは、また、検出した障害をサーバ・ファームのアドミニストレータに通知することができる。最後に、ステップ６において、次のサーバが障害を起こさなかったと仮定すると、サーバ・ファーム内の次のサーバは、クライアントの再試行要求およびクライアントによって発行された後続の要求に応答することができる。
【００２４】
　本発明は、ハードウェア，ソフトウェア，またはハードウェアおよびソフトウェアの組み合せで実現することができる。本発明の方法およびシステムの実装は、１つのコンピュータ・システムにおける集中型式で実現でき、あるいは、異なる要素が様々な相互接続コンピュータ・システムに広がる分散型式で実現できる。あらゆる種類のコンピュータ・システム、もしくはここに述べた方法を実施するのに適合した他の装置が、ここに述べた機能を実現するために適している。
【００２５】
　ハードウェアおよびソフトウェアの典型的な組み合せは、コンピュータ・プログラムを備える汎用コンピュータ・システムとすることができ、当該コンピュータ・プログラムは、ロードされ実行された時に当該コンピュータ・システムを制御し、ここに述べた方法を実行させる。本発明は、また、ここに述べた方法の実装を可能にする全ての特徴を含むコンピュータ・プログラム・プロダクトで実施することもでき、当該コンピュータ・プログラム・プロダクトは、コンピュータ・システムにロードされた時にここに述べた方法を実行することができる。
【００２６】
　本出願に関してコンピュータ・プログラムまたはアプリケーションとは、あらゆる言語，コードまたは表記での命令群の表現を意味し、このような命令群は、情報処理機能を有するシステムに特定の機能を直接、またはａ）他の言語，コードまたは表記への変換、ｂ）他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行させるものである。もちろん、本発明の趣旨および必須の特性から外れることなしに他の形式で本発明を実現することができ、したがって、上述の明細書よりむしろ、本発明の範囲を示す特許請求の範囲を参照されたい。
【００２７】
　まとめとして、本発明の構成に関して以下の事項を開示する。
（１）サーバ・ファームにおいてサーバ障害を診断し自己修復する方法であって、前記サーバ・ファーム内の割り当てサーバとの通信要求／応答セッションを確立しようと試みるクライアントからの再試行要求を受信するステップと、前記再試行要求に基づいて前記割り当てサーバの障害の発生を判断するステップと、前記割り当てサーバの障害を修復するオペレーションを実行するステップと、を含む方法。
（２）前記再試行要求に基づく前記割り当てサーバの障害の発生の判断に応答して、前記サーバ・ファーム内の別のサーバを割り当てて前記再試行要求を処理するステップをさらに含む上記（１）記載の方法。
（３）前記判断するステップは、前記割り当てサーバの障害の発生の指示を、前記再試行要求に付随する要求ストリング内で発見するステップを含む上記（１）記載の方法。
（４）前記判断するステップは、前記割り当てサーバの障害の発生の指示を、前記再試行要求に付随するクッキー内で発見するステップを含む上記（１）記載の方法。
（５）前記実行するステップは、前記最初のサーバの再生，前記最初のサーバ内のデバイスの再始動，および前記最初のサーバ内のアプリケーションの再始動より構成されるグループから選択された少なくとも１つの修復オペレーションを実行するステップを含む上記（１）記載の方法。
（６）前記実行するステップは、管理ノードに前記障害を通知するステップをさらに含む上記（１）記載の方法。
（７）前記実行するステップは、前記障害を診断するステップと、前記診断に基づいて少なくとも１つの修復オペレーションを実行するステップとを含み、前記修復オペレーションは、前記最初のサーバの再生，前記最初のサーバ内のデバイスの再始動，および前記最初のサーバ内のアプリケーションの再始動より構成されるグループから選択される上記（１）記載の方法。
（８）前記診断するステップは、前記割り当てサーバをpingするステップと、前記割り当てサーバと前記クライアントとの間でトレースルートを実行するステップと、を含む上記（７）記載の方法。
（９）前記診断するステップは、前記割り当てサーバにテスト・トランザクションを注入するステップと、前記注入によって生じた結果を監視するステップと、を含む上記（７）記載の方法。
（１０）前記注入するステップは、前記クライアントに前記割り当てサーバへテスト・トランザクションを注入させるステップを含む上記（９）記載の方法。
（１１）オートノミック・サーバ・ファームであって、前記サーバ・ファームの外部にあるクライアントから受信した要求に応答できる複数のサーバと、前記複数のサーバのうちの選択されたサーバへ要求を発送するよう構成されたリソース・ディレクタと、前記リソース・ディレクタに接続されたクライアント支援障害検出ロジックとを備えるオートノミック・サーバ・ファーム。
（１２）前記リソース・ディレクタに通信可能に接続され、前記選択されたサーバの検出障害を診断するよう構成されたドクタをさらに備える上記（１１）記載のオートノミック・サーバ・ファーム。
（１３）サーバ・ファームにおいてサーバ障害の診断および自己修復を実行するコンピュータ・プログラムを格納するマシン可読ストレージであって、前記コンピュータ・プログラムは、実行されたときに前記マシンに所定のステップを実行させる命令のルーチン・セットを含み、前記所定のステップは、前記サーバ・ファーム内の割り当てサーバとの通信要求／応答セッションを確立しようと試みるクライアントからの再試行要求を受信するステップと、前記再試行要求に基づいて前記割り当てサーバの障害の発生を判断するステップと、前記割り当てサーバの障害を修復するオペレーションを実行するステップと、を含むマシン可読ストレージ。
（１４）前記再試行要求に基づく前記割り当てサーバの障害の発生の判断に応答して、前記サーバ・ファーム内の別のサーバを割り当てて前記再試行要求を処理するステップをさらに含む上記（１３）記載のマシン可読ストレージ。
（１５）前記判断するステップは、前記割り当てサーバの障害の発生の指示を、前記再試行要求に付随する要求ストリング内で発見するステップを含む上記（１３）記載のマシン可読ストレージ。
（１６）前記判断するステップは、前記割り当てサーバの障害の発生の指示を、前記再試行要求に付随するクッキー内で発見するステップを含む上記（１３）記載のマシン可読ストレージ。
（１７）前記実行するステップは、前記最初のサーバの再生，前記最初のサーバ内のデバイスの再始動，および前記最初のサーバ内のアプリケーションの再始動より構成されるグループから選択された少なくとも１つの修復オペレーションを実行するステップを含む上記（１３）記載のマシン可読ストレージ。
（１８）前記実行するステップは、管理ノードに前記障害を通知するステップをさらに含む上記（１３）記載のマシン可読ストレージ。
（１９）前記実行するステップは、前記障害を診断するステップと、前記診断に基づいて少なくとも１つの修復オペレーションを実行するステップとを含み、前記修復オペレーションは、前記最初のサーバの再生，前記最初のサーバ内のデバイスの再始動，および前記最初のサーバ内のアプリケーションの再始動より構成されるグループから選択される上記（１３）記載のマシン可読ストレージ。
（２０）前記診断するステップは、前記割り当てサーバをpingするステップと、前記割り当てサーバと前記クライアントとの間でトレースルートを実行するステップと、を含む上記（１９）記載のマシン可読ストレージ。
（２１）前記診断するステップは、前記割り当てサーバにテスト・トランザクションを注入するステップと、前記注入によって生じた結果を監視するステップと、を含む上記（１９）記載のマシン可読ストレージ。
（２２）前記注入するステップは、前記クライアントに前記割り当てサーバへテスト・トランザクションを注入させるステップを含む上記（２１）記載のマシン可読ストレージ。
【図面の簡単な説明】
【００２８】
【図１】本発明に係るクライアント支援診断および自己修復用に構成されたサーバ・ファームのブロック図である。
【図２】サーバ・ファームにおけるクライアント支援診断および自己修復のプロセスを説明するタイミング図である。
【符号の説明】
【００２９】
　１１０　クライアント
　１２０　サーバ・ファーム
　１３０　コンピュータ通信ネットワーク
　１４０　ネットワーク・ディスパッチャ
　１５０　サーバ
　１６０　管理ノード
　１７０　コンピュータ・プロセス
　１８０　関連データ
　１９０Ａ　要求
　１９０Ｂ　再試行
　１９５　関連ドクタ・プロセス
【図１】
2004110790.tif 000003
【図２】
2004110790.tif 000004