ダウンストリームネットワーク要素に接続されたフロントエンドサーバとのセッションを実行するように動作可能なクライアントと、代替ダウンストリームネットワーク要素に接続された少なくとも1つの代替フロントエンドサーバとを含んだネットワークにおけるネットワーク要素のサービス回復のための方法であって、フロントエンドサーバによって、ダウンストリームネットワーク要素のエラーまたは利用不可能性を検出するステップと、応答コードを前記クライアントに送信して、前記クライアントがサービスを代替フロントエンドサーバにリダイレクトするか、または代替フロントエンドサーバで回復するようにトリガーするステップとを含む方法。前記クライアントと前記フロントエンドサーバとの間の前記セッションをサスペンドするステップをさらに含む請求項1に記載の方法。前記検出するステップは、前記ダウンストリームネットワーク要素からメッセージを受信するステップ、またはタイムアウトした応答タイマを検出するステップのうちの1つを含む請求項1に記載の方法。ダウンストリームネットワーク要素に接続されたフロントエンドサーバとのセッションを実行するように動作可能なクライアントと、代替ダウンストリームネットワーク要素に接続された少なくとも1つの代替フロントエンドサーバとを含んだネットワークにおけるネットワーク要素のサービス回復のための方法であって、前記フロントエンドサーバによって、ダウンストリームネットワーク要素のエラーまたは利用不可能性を検出するステップと、要素回復またはクラスタ回復を実行するべきかどうかを決定するステップと、要素回復が決定された場合、前記フロントエンドサーバによって、前記障害が発生したまたは利用不可能なダウンストリームネットワーク要素に対応する代替ダウンストリームネットワーク要素に切り替えるステップと、クラスタ回復が決定された場合、前記フロントエンドサーバによって応答コードを前記クライアントに送信して、前記クライアントがサービスを代替フロントエンドサーバにリダイレクトするか、または代替フロントエンドサーバで回復するかをトリガーするステップとを含む方法。前記クライアントと前記フロントエンドサーバとの間の前記セッションをサスペンドするステップをさらに含む請求項4に記載の方法。前記検出するステップは、前記ダウンストリームネットワーク要素からメッセージを受信するステップ、またはタイムアウトした応答タイマを検出するステップのうちの1つを含む請求項4に記載の方法。ダウンストリームネットワーク要素に接続されたフロントエンドサーバとのセッションを実行するように動作可能なクライアントと、代替ダウンストリームネットワーク要素に接続された少なくとも1つの代替フロントエンドサーバとを含んだネットワークにおけるネットワーク要素のサービス回復のためのシステムであって、ダウンストリームネットワーク要素のエラーまたは利用不可能性を検出し、応答コードを前記クライアントに送信して、前記クライアントがサービスを代替フロントエンドサーバにリダイレクトするか、または代替フロントエンドサーバで回復するようにトリガーするフロントエンドサーバの制御モジュールを備えるシステム。前記ダウンストリームネットワーク要素からメッセージを受信すること、またはタイムアウトした応答タイマを検出することによって前記フロントエンドサーバは、前記エラーまたは利用不可能性を検出する請求項7に記載のシステム。ダウンストリームネットワーク要素に接続されたフロントエンドサーバとのセッションを実行するように動作可能なクライアントと、代替ダウンストリームネットワーク要素に接続された少なくとも1つの代替フロントエンドサーバとを含んだネットワークにおけるネットワーク要素のサービス回復のためのシステムであって、ダウンストリームネットワーク要素のエラーまたは利用不可能性を検出し、要素回復またはクラスタ回復を実行するべきかどうかを決定し、要素回復が決定された場合、前記フロントエンドサーバによって、前記障害が発生したまたは利用不可能なダウンストリームネットワーク要素に対応する代替ダウンストリームネットワーク要素に切り替え、クラスタ回復が決定された場合、前記フロントエンドサーバによって応答コードを前記クライアントに送信して、前記クライアントがサービスを代替フロントエンドサーバにリダイレクトするか、または代替フロントエンドサーバで回復するかをトリガーするフロントエンドサーバの制御モジュールを備えるシステム。前記フロントエンドサーバは、前記ダウンストリームネットワーク要素からメッセージを受信すること、またはタイムアウトした応答タイマを検出することによって前記エラーまたは利用不可能性を検出する請求項9に記載のシステム。ネットワーク要素のサービス回復のための方法およびシステムが提供される。現在の標準的な技法は、自動的なサービス回復をトリガーするためにエラーを操作するのではなく、クライアントと直接的に通信しないバックエンド要素の障害について複雑で複数の要素のソリューションが記述的なエラーをクライアントに返すことである。十分に記述的なエラーは、一部の区分のユーザにとって有益であるが、他の多くのユーザは、むしろ自分たちのためにスマートクライアントデバイスが自動的にサービスを回復させることを望む。一実施形態では、本方法は、フロントエンドサーバによって、ダウンストリームのネットワーク要素のエラーまたは利用不可能性を検出するステップと、クライアントに応答コードを送信して、クライアントがサービスを代替フロントエンドサーバにリダイレクトするか、または代替フロントエンドサーバで回復するようにトリガーするステップとを含む。別の実施形態では、フロントエンドサーバはウェブサーバである。別の実施形態では、ダウンストリームネットワーク要素はデータベースサーバである。別の実施形態では、方法は、クライアントとフロントエンドサーバとの間のセッションをサスペンドすることをさらに含む。別の実施形態では、検出は、ダウンストリームネットワーク要素からメッセージを受信するステップ、またはタイムアウトした応答タイマを検出するステップのうちの1つを含む。別の実施形態では、本方法は、フロントエンドサーバによって、ダウンストリームネットワーク要素のエラーまたは利用不可能性を検出するステップと、要素回復またはクラスタ回復を実行するべきかどうかを決定するステップと、要素回復が決定された場合、フロントエンドサーバによって、障害が発生したダウンストリームネットワーク要素に対応する代替ダウンストリームネットワーク要素に切り替えるステップと、クラスタ回復が決定された場合、フロントエンドサーバによってクライアントに応答コードを送信して、クライアントが代替の冗長フロントエンドサーバにサービスをリダイレクトするか、または代替の冗長フロントエンドサーバで回復するようにトリガーするステップとを含む。別の実施形態では、フロントエンドサーバはウェブサーバである。別の実施形態では、ダウンストリームネットワーク要素はデータベースサーバである。別の実施形態では、方法は、クライアントとフロントエンドサーバとの間のセッションをサスペンドすることをさらに含む。別の実施形態では、検出は、ダウンストリームネットワーク要素からメッセージを受信するステップ、またはタイムアウトした応答タイマを検出するステップのうちの1つを含む。別の実施形態では、決定はデータトラフィックに基づいている。別の実施形態では、本システムは、ダウンストリームネットワーク要素のエラーまたは利用不可能性を検出し、クライアントに応答コードを送信して、クライアントがサービスを代替フロントエンドサーバにリダイレクトするか、または代替フロントエンドサーバで回復するようにトリガーするフロントエンドサーバの制御モジュールを含む。別の実施形態では、フロントエンドサーバはウェブサーバである。別の実施形態では、ダウンストリームネットワーク要素はデータベースサーバである。別の実施形態では、フロントエンドサーバは、ダウンストリームネットワーク要素からメッセージを受信することによって、またはタイムアウトした応答タイマを検出することによってエラーを検出する。別の態様では、クライアント、フロントエンドサーバ、ダウンストリームネットワーク要素、代替フロントエンドサーバ、および代替ダウンストリームネットワーク要素は、IMS要素である。別の実施形態では、本システムは、ダウンストリームネットワーク要素のエラーまたは利用不可能性を検出し、要素回復またはクラスタ回復を実行するべきかどうかを決定し、要素回復が決定された場合、フロントエンドサーバによって、障害が発生したダウンストリームネットワーク要素に対応する代替ダウンストリームネットワーク要素に切り替え、クラスタ回復が決定された場合、フロントエンドサーバによって、クライアントに応答コードを送信して、クライアントがサービスを代替フロントエンドサーバにリダイレクトするか、または代替フロントエンドサーバで回復するようにトリガーするフロントエンドサーバの制御モジュールを含む。別の実施形態では、フロントエンドサーバはウェブサーバである。別の実施形態では、ダウンストリームネットワーク要素はデータベースサーバである。別の実施形態では、フロントエンドサーバは、ダウンストリームネットワーク要素からメッセージを受信することによって、またはタイムアウトした応答タイマを検出することによってエラーを検出する。別の実施形態では、フロントエンドサーバの検出はデータトラフィックに基づいている。別の実施形態では、クライアント、フロントエンドサーバ、ダウンストリームネットワーク要素、代替フロントエンドサーバ、および代替ダウンストリームネットワーク要素は、IMS要素である。本発明の適用性のさらなる範囲は、以下に提供する詳細な説明から明白になるであろう。しかし、本発明の精神および範囲内の様々な変更形態および修正形態を当業者に明白にするため、詳細な説明および特定の例は、本発明の好適な実施形態を示しているが、例示を目的としてのみ提供されるものであることを理解されたい。ここで、本発明の実施形態による装置および/または方法の一部の実施形態について、例示のみを目的として、添付図面に関して記述する。本記載の実施形態によると、ネットワークのダウンストリーム要素に障害がある、または利用不可能な場合には、静的なエラー記述または他の端末の応答をクライアントに単に返すだけでなく、フロントエンドサーバたとえばウェブサーバは、動作可能なシステム/サイトたとえば冗長または代替の経路またはクラスタへの自動回復またはリダイレクションを試みるようにクライアントをトリガーする。目的は、障害が発生したまたは利用不可能なサーバが修理または回復される間、より長いサービス停止を回避するために、利用可能なシステム/サイトにサービスを自動的に回復またはリダイレクトすることである。この点で、本記載の実施形態によると、フロントエンドサーバは、バックエンドサーバつまり、典型的には直接的にクライアントと対話しないダウンストリームサーバによって返されたエラーメッセージをインテリジェントにプロキシし、フロントエンドから遠ざけるようにサービスをリダイレクトするために、状況をシミュレートまたは詐称するたとえばサーバの障害または過負荷状態。少なくとも1つの形態では、フロントエンドサーバはまた、サービスを回復するためにクライアントを代替つまり地理的に冗長なシステムまたはサイトにリダイレクトすることで、クライアントにとって、より優れたサービス可用性/信頼性/経験の質のうちの少なくとも1つが保証されることを決定するための知能またはロジックを含む。概して、アプリケーションプロトコルは全体的には、異なるタイプの応答コードをサポートし、その一部は本質的に終端または記述的でありたとえば、ウェブページが見つからない、ユーザは許可されていない、ゲートウェイに障害があるなど、その一部は、同じかまたは異なるサーバへの回復動作を取るようにクライアントをトリガーすることができるたとえば、一時的に移動、サービスが利用不可能、混み合っている、再試行など。本記載の実施形態によると、フロントエンドサーバは、バックエンドシステムからの潜在的に回復可能なエラーまたは欠陥を、クライアントに対して返された応答コードなどのメッセージにマッピングする。これらのマッピングされた応答コードは、代替システム/サイトへのそれらの要求を再試行するようにクライアントをトリガーする。したがって、本記載の実施形態によると、ウェブサーバフロントエンドが、データベースサーバの障害または利用不可能な状態を、たとえば、クライアントが表示するべきエラーウェブページにマッピングするのではなく、フロントエンドウェブサーバが、クライアントに完全に動作可能なシステム/サイトにサービスを回復またはリダイレクトさせる状況たとえば障害をシミュレートする。本記載の実施形態を実施するために使用するコードまたはメッセージの例として、上に参照した応答コードのタイプは、用途によって異なる場合があることを理解されたい。たとえば、ダウンストリーム障害がフロントエンドサーバによって検出された場合、503ServiceUnavailableコードなど、深刻な問題を示すコードは、フロントエンドサーバによって目的変更repurposeされ、それ自身の障害をシミュレートするためにフロントエンドサーバによってクライアントに伝送されて、切替えをトリガーすることができる。同様に、ダウンストリーム過負荷状態またはダウンストリーム要素を利用不可能にする他の状態が検出された場合、フロントエンドサーバは、302MovedTemporarilyコードなど、リダイレクション応答をクライアントに伝送して、代替クラスタへのリダイレクションをトリガーすることができる。さらに他の例では、フロントエンドサーバは、障害または利用不可能な他の状態を含む利用不可能なすべての状況において、302MovedTemporarilyコードなど、リダイレクション応答を伝送することができる。このシナリオでは、本記載の実施形態を実施するために、深刻な問題上記の503ServiceUnavailableコードなどを示すコードを使用する必要性がなくなる。さらに他の例では、503ServiceUnavailableコードなど、深刻な問題を示すコードは、障害または利用不可能な他の状態を含む、利用不可能なすべての状況で、フロントエンドサーバによって目的変更され、それ自身の障害をシミュレートするためにフロントエンドサーバによってクライアントに伝送されて、切替えをトリガーすることができる。ここで、図示しているものが例示的な実施形態を示すことのみを目的とするものであり、特許請求の主題を限定することを目的とするものではない図面を参照すると、図1は、本記載の実施形態を組み込むことができるシステム100を示す図である。図示したように、システム100は、サービスBを提供する機能エンティティと通信状態にある、またはセッションを実行しているネットワーク要素またはクライアントA102を含む。この機能エンティティは、ネットワーク要素またはサーバB1104、およびネットワーク要素またはサーバB2108を含む。示したサービスBを提供する機能エンティティは、サービスCを提供する機能エンティティと通信する。この機能エンティティは、ネットワーク要素またはサーバC1106およびネットワーク要素またはサーバC2110を含む。図示するように、これらの要素C1およびC2は、要素B1およびB2に対してダウンストリームである。さらに、各ネットワーク要素は、たとえば制御モジュール103、105、107、109、および111など、制御モジュールを含むことが示されている。制御モジュールは、ネットワーク要素に機能を提供し、いくつかの実施形態では、本記載の実施形態の機能を実現するために適切なルーチンを収容しかつ/または実行するものと理解される。たとえば、フロントエンドサーバB1104は、少なくとも1つの形態において、図2~図5に関連して以下に記述される方法を含んだ本記載の実施形態による方法に対応するルーチンを実行するように動作可能な制御モジュール105を含む。図示の構成では、それぞれネットワーク要素B1およびC1に対して、ネットワーク要素B2およびC2は、代替の冗長要素代替要素または冗長要素とも呼ぶとして働くことを理解されたい。この点において、そのような代替サーバもしくは冗長サーバまたは代替の冗長サーバは、それが対応するプライマリサーバを必ずしも正確に複製しないことを理解されたい。また、参照しやすくするために、たとえばB1およびC1について1つの対応する代替の冗長要素だけが本明細書に示されているが、ネットワーク要素は、2つ以上の対応する代替の冗長要素を有することができることを理解されたい。図示するように、要素B1およびC1は、地理的に近い要素のクラスタを形成し、要素B2およびC2は、地理的に近い要素のクラスタを形成する。少なくとも1つの例示的な形態では、ネットワーク要素B1およびB2は、ウェブサーバなどのフロントエンドサーバとして機能する一方、ネットワーク要素C1およびC2は、データベースサーバなどのバックエンドサーバとして機能する。単一のフロントエンドサーバB1またはB2が示されているが参照しやすくするため、ソリューションでは、必ずしも単一のフロントエンドサーバだけである必要はないことを理解されたい。複雑なサービスたとえばIPテレビのヘッドエンドは、サーバ一式全体にわたって実装することができ、論理上、より幅広いソリューション内にあるシステムのより小さなクラスタへと整理することも可能であり得る。それらのより小さなクラスタのそれぞれは、フロントエンドサーバとして働くシステムを有することもあり得る。これは、異なるフロントエンドサーバを備えたより大きなクラスタ内にフロントエンドサーバを備えた、より小さなクラスタを有する再帰的なケースを含む。もちろん、IPマルチメディアサブシステムIMS要素を含む、他のタイプのネットワーク要素を使用することもできる。また、セッション開始プロトコルSIPを含む、様々な信号プロトコルを使用できることを理解されたい。またさらに、ネットワーク要素は、ある目的のためにはクライアントとして、しかし別の目的のためにはサーバとして働くことを理解されたい。したがって、示された構成は、単に例として理解するべきである。また、これと同じように、図1は、冗長要素C1およびC2を含むが、冗長要素D1およびD2、E1およびE2...など図示せずも、システムにある場合があることを理解されたい。少なくとも1つの形態において、主要な要素B1、C1などのすべては、1つのサイトの第1のクラスタクラスタ1に位置すると想定され、少なくとも1つの形態において、冗長要素B2、C2などのすべては、第2のサイトの第2のクラスタクラスタ2に位置すると想定される。典型的には、クライアントと直接対話するクラスタのエッジ要素の障害からの回復オプションは1つだけあるたとえば、B1に障害が発生した場合、クライアントはB2に回復する必要がある。しかし、本記載の実施形態によると、エッジ内の要素の障害に対して2つの回復オプションがある。この点において、場合によっては、より速くより優れた回復を可能にするために、要素のクラスタを回復グループへと整理することができる。図2を参照すると、要素回復をシステムに使用する技術が示されている。この点において、非エッジ要素C1の障害は、要素C2への要素B1の切替えによって回復することができる。理想的には、要素B1が、障害を十分に速く検出し、要素C2を用いて十分なセッションコンテキストを回復するため、回復はクライアントAにとって透過的である。分かるように、要素A1は、依然経路150で要素B1と通信するが、要素B1は、経路152で要素C2と通信する。図3を参照すると、クラスタ回復をシステムに使用する技術が示されている。この点では、非エッジ要素C1の障害または利用不可能性は、クラスタ1から離れてクラスタ2にクライアントAを切り替える、またはリダイレクトすることによって、回復または対処することができる。この場合、クライアントAは、要素B2へのサービスの再確立に明示的に関係している。要素C1の障害または利用不可能性は、要素C1の障害または利用不可能性に応じて、要素B1によってクライアントAに返される深刻な応答コードたとえば、503ServiceUnavailableまたは302MovedTemporarilyなどのリダイレクション応答を介してクライアントAに明示的に通信され、クライアントAは、代替クラスタへの回復を開始することが期待される。この場合、回復の後に、クライアントAは、経路160で要素B2と通信し、要素B2は、経路162で要素C2と通信する。クラスタ回復において、エッジおよび/または他の要素は、自身で回復を試みるのではなく、クライアントたとえばクライアントAに障害または利用不可能応答を明示的にプロキシして戻すことに注意されたい。次に、クライアントは、代替クラスタにリダイレクトするか切り替える。さらに、暗黙的な障害たとえばタイムアウト期限切れ、ハートビートの損失は、同様に、クライアントにプロキシして戻される適切な明示的な障害へと変換されるため、クライアントは、サービスをリダイレクトまたは切り替えることができる。要素回復とクラスタ回復との違いは、ソリューションの様々な要素において異なるように見える可能性があることに注意されたい。たとえば、要素B1が、図2のC1からC2への要素回復を実行する間、クライアントAは、回復動作が取られたことを認識しない。同様に、図3のサイト1からサイト2へのクラスタ回復は、クライアントAには、B1の明白な障害の後に、単にB2への要素回復として見える可能性がある。本記載の実施形態は、様々なやり方で実施できることを理解されたい。たとえば、本記載の実施形態の方法は、受信するエラーまたは他の応答に対するクラスタ回復技術を実行するフロントエンドサーバの機能を含むことができる。さらなる実施形態では、フロントエンドサーバは、また、要素回復またはクラスタ回復を特定のエラーまたは応答の検出に関して実施するべきかどうかについて決定を行うために、ロジックを実行するか、または知能を有することができる。いずれの場合でも、本記載の実施形態による方法は、様々なやり方でシステムにおいて実現できることが理解されるであろう。この点において、様々なソフトウェアルーチンまたはハードウェア構成を使用することができる。たとえば、本出願の方法を実行するソフトウェアルーチンは、フロントエンドサーバB1104の制御モジュール105など、フロントエンドサーバの制御モジュールによって収容かつ/または実行することができる。もちろん、そのようなルーチンはまた、適切なネットワーク要素においてネットワーク内で分散することができ、その一部は図1に図示していない。したがって、ここで図4を参照すると、本記載の実施形態による方法200が示されている。方法200は、ダウンストリームネットワーク要素からのエラーまたは利用不可能性を検出することを含む202。そのような検出は、様々な従来のやり方で達成できる場合がある。たとえば、明示的なメッセージまたは暗黙的なインジケータの受信時たとえば応答タイマのタイムアウトに、エラーまたは利用不可能性を検出できる場合がある。検出時に、フロントエンドサーバは、クラスタ回復技術を実行する。すなわち、フロントエンドサーバは、システムにおいて代替の冗長フロントエンドサーバにクライアントが切り替えることをトリガーするために、障害またはリダイレクトのメッセージをクライアントに送信する204。障害またはリダイレクトのメッセージは、様々な形態を取ることができるたとえば、503ServiceUnavailableまたは302MovedTemporarilyなどのリダイレクション応答。このようにして、フロントエンドサーバは、サービスを障害または利用不可能な状態をシミュレートするため、クライアントは、冗長経路に完全に切り替えるか、または冗長経路にリダイレクトするたとえば、代替の冗長フロントエンドサーバに切り替えることで、代替クラスタに切り替える。また、クライアントとオリジナルのフロントエンドサーバとの間のセッションは、クライアントが代替サーバにサービスをリダイレクトすることを優先してサスペンドされる206。いくつかの実施形態では、過負荷のサーバは、過負荷の短い期間の間に、代替サーバに少数のサービス要求を単にリダイレクトすることができる。したがって、プライマリサーバは、クライアントのトラフィックの大部分を運び続けるが、過負荷の短い期間の間に品質低下したサービスを伝達するのではなくサービスの合格品質を保証するために、少数のトランザクションが他のサーバによって扱われる。上記のように、フロントエンドサーバは、また、クラスタ回復または要素回復を使用する適切さを決定するためにロジックまたは知能を含むことができる。この点において、図5を参照すると、方法300が示されている。方法300は、ダウンストリームネットワーク要素におけるエラーまたは利用不可能性の検出時に開始される402。そのようなエラー検出は、様々な従来のやり方で達成できる場合がある。たとえば、明示的なメッセージまたは暗黙的なインジケータの受信時たとえば応答タイマのタイムアウトに、エラーまたは利用不可能性を検出できる場合がある。この時点で、フロントエンドサーバは回復戦略を決定する304。もちろん、少なくとも1つの形態において、フロントエンドサーバは、要素回復プロセスまたはクラスタ回復プロセスが実行されるかどうかを決定する。この決定は、様々なやり方で達成できる場合がある。たとえば、フロントエンドサーバは、障害が発生したか、または利用不可能なサーバと交換するデータの量またはデータトラフィックを考慮に入れることができる。データ交換速度またはデータトラフィックが比較的低い場合、適応的に、または定期的に設定できるしきい値に基づいて、またはサブルーチンの実行に基づいて、フロントエンドサーバは、要素回復がシステムのためにより良いことを決定することができる。他の状況では、同様の基準に基づいて、フロントエンドサーバは、クラスタ回復が実行されることを決定することができる。要素回復プロセスが決定される場合、フロントエンドサーバは、障害が発生したネットワーク要素に対応する代替の冗長なネットワーク要素と通信するために単に切り替える306。フロントエンドサーバは、クライアントとのセッションを継続する308。しかし、クラスタ回復が実行されることをフロントエンドサーバが304で決定する場合、フロントエンドサーバは、クライアントに障害またはリダイレクトのメッセージを送信する310。障害またはリダイレクトのメッセージは、様々な形態を取ることができるたとえば、503ServiceUnavailableまたは302MovedTemporarilyなどのリダイレクション応答。もちろん、上記のように、障害またはリダイレクトのメッセージは、冗長な代替のサーバ経路またはクラスタにクライアントがリダイレクトするようにトリガーする。クライアントとフロントエンドサーバとの間のセッションは、サスペンドされる312。上記のように、一部の変形形態では、過負荷のサーバは、過負荷の短い期間の間に、代替サーバに少数のサービス要求を単にリダイレクトすることができる。したがって、プライマリサーバは、クライアントのトラフィックの大部分を運び続けるが、過負荷の短い期間の間に品質低下したサービスを伝達するのではなくサービスの合格品質を保証するために、少数のトランザクションが他のサーバによって扱われる。本記載の実施形態の他の変形形態では、3つ以上の要素たとえばD1/D2、E1/E2などによるソリューションは、一部の要素障害は要素回復を通じて緩和され、一部はクラスタ回復を通じて緩和されるハイブリッド回復戦略を展開させる。そのようなシナリオでは、図5に示すものに類似した方法を利用することができる。さらに、回復クラスタは、サイト上のすべてのソリューション要素の一式より小さい場合があるため、サイト1の他の要素がサービスを伝達し続ける間に、サイト1の1つの要素の障害は、サイト2の要素の小さな回復クラスタへと一部のサービスを回復できる場合がある。本記載の実施形態は、特定の例示を用いて示すことができる。この点において、クラスタ回復の優先事項の1つは、最初にローカルサーバに、ローカルサーバのいずれも利用可能でない場合はリモートサーバに、そのサービス要求を送信するように各要素を構成することである。これを達成する1つの方法は、完全修飾ドメイン名FQDNプールの各サーバに優先度を割り当てることを可能にする、DNSSRVレコードを用いることである。この構成を用いると、要素に障害が発生し、サービスがリモートサイトへ切り替えられる場合、その要素はリモートサイトにある他の要素にそれ自身の要求を送信する。同じサイト内に発生する要素間のほとんどの通信を用いると、遅延は、簡単な要素の切替えほどには増加しない。上記の例では、C1/C2サーバのFQDNは、このように実装することができる。典型的には、クライアントがサーバB2にフェイルオーバーした場合、サーバB2は、ローカルサーバC2を自動的に使用する。しかし、クライアントがサーバB1を使用していて、サーバC1に障害が発生するか、または利用不可能になった場合、サーバB1は、サーバC2にその要求を送信し始める。このトラフィックは、地理的にリモートにあるサイト間で流れ、追加の帯域幅が使用され、これらの要求の遅延が増加する。本記載の実施形態によるクラスタのフェイルオーバーを実行するために、たとえば、Cサーバの障害を別に扱うために本明細書に記述したように、サーバB1には特別なソフトウェアロジックが必要である。サーバC1の障害を検出した後、サーバB1は、代替サーバへの回復またはリダイレクションを開始するようにトリガーするために規定されたクライアントに応答コードを明示的に返す必要がある。たとえば、クライアントとB1との間のプロトコルがSIPである場合、B1サーバは、リモートサイトへのクライアントのフェイルオーバーをトリガーするために、503ServiceUnavailableまたは302MovedTemporarily応答を返すことができる。様々な上記方法のステップは、プログラムされたコンピュータたとえば、制御モジュール103、105、107、109、または111によって実行できることを当業者なら容易に理解されるであろう。本明細書において、一部の実施形態は、また、機械またはコンピュータで読取り可能、およびエンコード装置で実行可能またはコンピュータで実行可能なプログラム命令である、たとえば、デジタルデータ記憶メディアなど、プログラム記憶装置を包含することを意図するものであり、前記命令は、上記の方法のステップの一部またはすべてを実行する。プログラム記憶装置は、たとえば、デジタルメモリ、磁気ディスクや磁気テープなどの磁気記憶メディア、ハードドライブ、または光学的に読取り可能なデジタルデータ記憶メディアなどでもよい。また、実施形態は、上記方法の前記ステップを実行するようにプログラムされたコンピュータを包含することを意図するものである。さらに、ネットワーク要素、クライアント、またはサーバと記載された任意の機能ブロックを含む、図に示す様々な要素の機能は、専用ハードウェア、およびソフトウェアを実行することができ、適切なソフトウェアに関連するハードウェアの使用を通じて提供することができる。プロセッサによって提供される場合、機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、またはその一部を共有することができる、複数の個別のプロセッサによって提供することができる。さらに、プロセッサ、コントローラ、またはコントローラモジュールという用語の明示的な使用は、ソフトウェアを実行できるハードウェアを排他的に指すものと解釈するべきではなく、デジタルシグナルプロセッサDSPハードウェア、ネットワークプロセッサ、特定用途向け集積回路ASIC、フィールドプログラマブルゲートアレイFPGA、ソフトウェアを格納するための読取り専用メモリROM、ランダムアクセスメモリRAM、および不揮発性記憶装置を限定することなく、暗黙的に含むことができる。従来型および/またはカスタムの他のハードウェアも含むことができる。同様に、図に示すいずれのスイッチも概念のみを示すものである。それらの機能は、プログラムロジックの動作を通じて、専用ロジックを通じて、プログラム制御および専用ロジックの対話を通じて、または手動でも、実行することができ、文脈からより明確に理解されるように、特定の技術を実装者が選択可能である。上記の記述は、本発明の特定の実施形態の開示を単に提供するものであり、それに限定することを目的として意図するものではない。そのため、本発明は上記の実施形態だけに限定されない。むしろ、当業者なら本発明の範囲に入る代替実施形態を着想し得ることが認識されるであろう。