(57)【要約】  クライアント回復戦略が、冗長構成についてのサービスの可用性を最大にするための方法およびシステムが提供される。本方法は、タイミング・パラメータを適応的に調整するステップと、適応的に調整されたタイミング・パラメータに基づいて故障を検出するステップと、冗長サーバに切り替えるステップとを含む。タイミング・パラメータは、再試行の最大回数と、応答タイマと、キープアライブ・メッセージとを含む。クライアントとのウォーム・セッションに従事する代替サーバに切り替えるステップは、性能を改善するように実施されることもある。本方法および本システムは、冗長サーバに対する改善された回復時間とトラフィックの適切な形成とを可能にする。【特許請求の範囲】
【請求項１】
サーバ、および対応する冗長サーバと通信するように動作するクライアントを含むシステムにおける回復のための方法であって、
ランダムに割り付けるアプローチに基づいてサーバ故障を検出するようにプロセスの少なくとも１つのタイミング・パラメータを適応的に調整するステップと、
前記少なくとも１つの適応的に調整されたタイミング・パラメータに基づいて前記故障を検出するステップと、
冗長サーバに切り替えるステップと、
を含む方法。
【請求項２】
前記少なくとも１つのタイミング・パラメータは、再試行の最大回数である、請求項１に記載の方法。
【請求項３】
前記少なくとも１つのタイミング・パラメータは、応答タイマを含む、請求項１に記載の方法。
【請求項４】
前記少なくとも１つのタイミング・パラメータは、キープアライブ・メッセージの伝送の間の期間を含む、請求項１に記載の方法。
【請求項５】
前記冗長サーバに切り替えるステップは、クライアントとのあらかじめ構成されたセッションを保持する冗長サーバに切り替えるステップを含む、請求項１に記載の方法。
【請求項６】
サーバ、および対応する冗長サーバと通信するように動作するクライアントを含むネットワークにおける回復のためのシステムであって、
ランダムに割り付けるアプローチに基づいてサーバ故障を検出するようにプロセスの少なくとも１つのタイミング・パラメータを適応的に調整し、前記少なくとも１つの適応的に調整されたタイミング・パラメータに基づいて前記故障を検出し、冗長サーバにクライアントを切り替える制御モジュール
を備えるシステム。
【請求項７】
前記少なくとも１つのタイミング・パラメータは、再試行の最大回数である、請求項６に記載のシステム。
【請求項８】
前記少なくとも１つのタイミング・パラメータは、応答タイマを含む、請求項６に記載のシステム。
【請求項９】
前記少なくとも１つのタイミング・パラメータは、キープアライブ・メッセージの伝送の間の期間を含む、請求項６に記載のシステム。
【請求項１０】
前記冗長サーバは、前記クライアントとのあらかじめ構成されたセッションに従事している、請求項６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの中の冗長サーバ構成におけるサービスの可用性を改善するクライアント回復戦略のための方法およびシステムに関する。本発明は、詳細には、クライアント回復戦略の技術に関し、したがって特にそれに関連して説明されることになるが、本発明は、他の分野および用途においても有用性を有し得ることが理解されるであろう。
【背景技術】
【０００２】
システムの冗長配列は、図１におけるような信頼性ブロック図（ＲＢＤ：ｒｅｌｉａｂｉｌｉｔｙ  ｂｌｏｃｋ  ｄｉａｇｒａｍ）を用いて示すのが好都合である。示されるように、サービスのために動作しており、チェーンとして配列されるコンポーネントを有するシステム１０は、冗長構成を示すものである。単一のコンポーネントＡは、１対の冗長コンポーネントＢ１およびＢ２と直列になっており、別の対の冗長コンポーネントＣ１およびＣ２と直列になっており、冗長コンポーネントＤ１、Ｄ２およびＤ３のプールと直列になっている。このサンプル・システム１０によって提供されるサービスは、動作しているコンポーネントを経由して図１の左端から右端への経路を通して使用可能である。冗長システムの利点を示すために、例えば、コンポーネントＢ１が、故障する場合、トラフィックは、コンポーネントＢ２によってサービスされ得、そのようにしてシステムは、動作し続けることができる。
【０００３】
冗長性および高い可用性の機構の目的は、単一の故障が、受け入れることができないサービス中断を生じないことを保証することである。重要な要素が、冗長性を用いて構成されないときには（図１のコンポーネントＡなど）、単一のポイントの故障は、そのような単一要素において起こり、故障した単一要素が修復され、またサービスが回復され得るまで、サービスを使用不可能にすることもある。高い可用性と重要なシステムは、通常、そのような単一ポイントの故障が存在しないように設計されている。
【０００４】
サーバが故障するときには、そのサーバがその故障についてネットワークの中の他のコンポーネントに通知することが有利である。したがって、多数の機能的な故障は、明示的なエラー・メッセージが、故障したコンポーネントによって伝送されるので、ネットワークの中で検出される。例えば、図１において、コンポーネントＢ１（例えば、サーバ）は、故障し、また標準ベースのエラー・メッセージを通してその故障についてコンポーネントＡ（例えば、別のサーバまたはクライアント）に通知することができる。しかしながら、多数の重大な故障は、明示的なエラー応答がクライアントに到達できないようにする。それゆえに、多数の故障は、暗黙的に、すなわち、コマンド要求やキープアライブ（ｋｅｅｐａｌｉｖｅ）などのメッセージの肯定応答の欠如に基づいて検出される。クライアントがそのような要求を送信するときに、クライアントは、一般的に、タイマ（応答タイマと呼ばれる）を開始させ、またタイマが、応答がサーバから受信される前に期限切れになる場合、クライアントは、要求（再試行と呼ばれる）を再送信し、また応答タイマを再スタートさせる。タイマがもう一度期限切れになる場合、クライアントは、それが再試行の最大回数に到達するまで、再試行を送信し続ける。重大な暗示的故障の確認と、それゆえの任意の回復アクションの開始とは、一般に、初期の応答タイムアウトに最大回数の肯定応答されなかった再試行を送信する時間を加えた時間だけ遅延させられる。
【０００５】
これらのパラメータが、異なるタイプの故障を検出するように設計されるので、システムは、通常、応答タイマと再試行との両方をサポートする。応答タイマは、サーバが要求を処理することをできないようにするサーバの故障を検出する。再試行は、折に触れてパケットが失われるようにする可能性があるネットワーク故障に対して保護する。ＴＣＰやＳＣＴＰなどの信頼できるトランスポート・プロトコルは、肯定応答と再試行とをサポートする。しかし、これらのうちの１つが使用されるときでさえも、アプリケーション・レイヤにおいて応答タイマを使用して、アプリケーション・プロセスの故障に対して保護することが依然として望ましい。例えば、ＴＣＰ接続を介して搬送されるアプリケーション・セッションは、作動しており、またクライアントとサーバとの間でパケットと肯定応答とを適切にあちこちに送信している可能性があるが、サーバ側のアプリケーション・プロセスは故障し、またそれゆえにクライアントへのＴＣＰ接続を介するアプリケーション・ペイロードを正しく受信し、また送信することができない可能性がある。この場合には、クライアント・アプリケーションとサーバ・アプリケーションとの間に別個の肯定応答メッセージが存在していない限り、クライアントは問題について知らないはずである。
【０００６】
とりわけ、多数のプロトコル（例えば、ＳＩＰ）は、プロトコル・タイムアウトと、自動的なプロトコル再試行（所定の最大再試行カウントを有する）とを指定する。サービスの可用性を改善する論理戦略は、最大回数の再伝送がタイムアウトしているときに、クライアントが、代替サーバに対して再試行することである。クライアントは、主要なサーバと、１つまたは複数の代替サーバとの両方についてのネットワーク・アドレス（ＩＰアドレスなど）を用いて構成され得るか、またはそれらのクライアントは、ＤＮＳに頼って、ネットワーク・アドレスを（例えば、ラウンド・ロビン・スキームを経由して）提供することができるか、あるいは他の機構が使用され得るかのいずれかとすることができることに留意すべきである。これは、個別のクライアントの場合に非常によく機能するが、多数のクライアントをサポートするサーバの壊滅的な故障は、クライアント再伝送とタイムアウトとのすべてを同期化させる可能性があるので、このスタイルのクライアント駆動された回復は、高い可用性のサービスのためにはうまく適合しない。したがって、故障したサーバによって以前にサービスされたクライアントのすべては、突然、代替サーバに接続／登録しようと試みることもあり、代替サーバを過負荷にし、また場合によっては、代替サーバによるサービスの許容可能な品質を伴って（過負荷イベントにより、それらのサービス品質は悪化するが）、以前にサービスされたこともあるユーザに対して故障を連鎖させる。
【０００７】
従来の戦略は、トラフィックのスパイクまたはバーストに直面するときでさえ、単に代替サーバのサーバ過負荷制御機構に頼ってトラフィックを形成し、また代替サーバに頼って動作したままでいることである。これらの状況においては、過負荷制御戦略は、通常、サーバを崩壊から保護するように設計されている。したがって、これらの戦略は、保守的であり、また必要な可能性よりも長い期間にわたって新しい接続を引き延ばす可能性が高い。より保守的な戦略は、所定のレートまで新しいクライアントの接続またはサービスを意図的に減速することにより、より長い時間にわたってクライアント・サービスを拒否することになる。最終的には、クライアントは、動作する代替サーバに正常に接続するか、またはプロセスを停止して接続するかのいずれかである。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
冗長サーバ構成におけるサービスの可用性を最大にするためのクライアント回復戦略に関する方法およびシステムが提供される。
【課題を解決するための手段】
【０００９】
一態様においては、本方法は、サーバ故障を検出するプロセスの少なくとも１つのタイミング・パラメータを適応的に調整するステップと、少なくとも１つの動的に調整されたタイミング・パラメータに基づいて故障を検出するステップと、冗長サーバに切り替えるステップとを含む。
【００１０】
別の態様においては、少なくとも１つのタイミング・パラメータは、再試行の最大回数である。
【００１１】
別の態様においては、少なくとも１つのタイミング・パラメータを適応的に調整するステップは、再試行の最大回数をランダムに割り付けるステップを含む。
【００１２】
別の態様においては、少なくとも１つのタイミング・パラメータを適応的に調整するステップは、履歴ファクタに基づいて再試行の最大回数を調整するステップを含む。
【００１３】
別の態様においては、少なくとも１つのタイミング・パラメータは、応答タイマを含む。
【００１４】
別の態様においては、少なくとも１つのタイミング・パラメータを適応的に調整するステップは、履歴ファクタに基づいて応答タイマを調整するステップを含む。
【００１５】
別の態様においては、少なくとも１つのタイミング・パラメータは、キープアライブ・メッセージの伝送の間の期間を含む。
【００１６】
別の態様においては、少なくとも１つのタイミング・パラメータを適応的に調整するステップは、トラフィック負荷に基づいてキープアライブ・メッセージの間の期間を調整するステップを含む。
【００１７】
別の態様においては、冗長サーバに切り替えるステップは、クライアントとのあらかじめ構成されたセッションを維持する冗長サーバに切り替えるステップを含む。
【００１８】
別の態様においては、システムは、サーバ故障を検出するプロセスの少なくとも１つのタイミング・パラメータを適応的に調整し、少なくとも１つの適応的に調整されたタイミング・パラメータに基づいて故障を検出し、クライアントを冗長サーバに切り替える制御モジュールを備える。
【００１９】
別の態様においては、少なくとも１つのタイミング・パラメータは、再試行の最大回数である。
【００２０】
別の態様においては、制御モジュールは、再試行の最大回数をランダムに割り付けることにより、少なくとも１つのタイミング・パラメータを適応的に調整する。
【００２１】
別の態様においては、制御モジュールは、履歴ファクタに基づいて再試行の最大回数を調整することにより少なくとも１つのタイミング・パラメータを適応的に調整する。
【００２２】
別の態様においては、少なくとも１つのタイミング・パラメータは、応答タイマを含む。
【００２３】
別の態様においては、制御モジュールは、履歴ファクタに基づいて応答タイマを調整することにより少なくとも１つのタイミング・パラメータを適応的に調整する。
【００２４】
別の態様においては、少なくとも１つのタイミング・パラメータは、キープアライブ・メッセージの伝送の間の期間を含む。
【００２５】
別の態様においては、制御モジュールは、キープアライブ・メッセージの間の期間を調整することにより少なくとも１つのタイミング・パラメータを適応的に調整する。
【００２６】
別の態様においては、冗長サーバは、クライアントとのあらかじめ構成されたセッションにおける冗長サーバである。
【００２７】
本発明の適用可能性のさらなる範囲は、以下で提供される詳細な説明から明らかになるであろう。しかしながら、本発明の精神および範囲内の様々な変更形態および修正形態は、当業者には明らかになるので、詳細な説明および特定の例は、本発明の好ましい実施形態を示しながら、例証としてだけ与えられることを理解すべきである。
【００２８】
本発明の実施形態による装置および／または方法のいくつかの実施形態は、次に、例としてのみ、および添付図面を参照して説明される。
【図面の簡単な説明】
【００２９】
【図１】冗長構成を示す一例の信頼性のブロック図である。
【図２】本記載の実施形態が実装され得る例示的システムを示す図である。
【図３】本記載の実施形態による方法を示すフロー・チャートである。
【図４】故障技法を示すタイミング図である。
【図５】本記載の実施形態による技法を示すタイミング図である。
【図６】本記載の実施形態による技法を示すタイミング図である。
【図７】本記載の実施形態による技法を示すタイミング図である。
【発明を実施するための形態】
【００３０】
本記載の実施形態は、回復時間を改善するサーバの冗長な展開を有するネットワークに対して適用されることもある。図２を参照すると、本記載の実施形態が実装され得る一例のシステム１００は、通常はサーバまたはネットワーク要素Ｂ１（１０４）からネットワーク・サービスにアクセスしている論理クライアント・ネットワーク要素Ａ（１０２）を含む。名目上地理的に分散された冗長サーバまたはネットワーク要素Ｂ２（１０６）（代替サーバ、または代替冗長サーバ、あるいはネットワーク要素とも称される）もまた、ネットワークにおいて使用可能である。そのような代替サーバ、または冗長サーバ、あるいは代替冗長サーバは、必ずしもそれが対応する主要なサーバを正確に再現するとは限らないことを理解すべきである。示される構成は、単に１つの例にすぎないこともまた認識すべきである。変形形態がうまく実装される可能性もある。また、複数の冗長的な、または代替的なネットワーク要素が、主要なネットワーク要素（サーバＢ１など）に対応することができることも理解すべきである。
【００３１】
クライアントＡと、サーバＢ１およびＢ２とはまた、それが存在するネットワーク要素、および／または他のネットワーク要素の機能を制御するように動作する制御モジュール（それぞれ１０３、１０５および１０７）とともに示される。ネットワーク要素は、ＩＰネットワーキングを経由した標準プロトコル（例えば、ＳＩＰ）を含めて、様々な技法を使用して通信することができることも理解すべきである。
【００３２】
下記の詳細な説明を読むことから明らかになるように、本記載の実施形態を具現化すると、サーバＢ１が故障するときに、クライアントＡによって見られるように、改善されたサービスの可用性が促進される。
【００３３】
図３を参照すると、クライアント回復戦略が、冗長構成についてのサービスの可用性を改善するための方法２００が提供されている。本方法は、（２０２において）サーバ故障を検出するためにクライアント・プロセスのタイミング・パラメータを動的に設定する、または調整するステップと、（２０４において）動的に設定されたタイミング・パラメータに基づいて故障を検出するステップと、（２０６において）冗長サーバに切り替えるステップとを含む。
【００３４】
本方法２００は、様々なハードウェア構成およびソフトウェア・ルーチンを使用して実施され得ることを理解すべきである。例えば、ルーチンは、クライアントＡ（例えば、クライアントＡの制御モジュール１０３）またはサーバＢ１（またはＢ２）（例えば、サーバＢ１、Ｂ２の制御モジュール１０５、１０７）において存在することができ、および／またはクライアントＡ（例えば、クライアントＡの制御モジュール１０３により）またはサーバＢ１（またはＢ２）により（例えば、サーバＢ１、Ｂ２の制御モジュール１０５、１０７により）実行されることもある。それらのルーチンはまた、本記載の実施形態を実現するために例証されたシステム・コンポーネントのうちのいくつかまたはすべてにおいて分散され、および／またはそれらのうちのいくつかまたはすべてによって実行されることもある。さらに、用語「クライアント」および「サーバ」は、特定のアプリケーション・プロトコル交換に関して参照されることを理解すべきである。例えば、コール・サーバは、加入者情報データベース・サーバに対する「クライアント」とすることができ、またＩＰ電話クライアントに対する「サーバ」とすることができる。さらにまた、他のネットワーク要素（図示されず）は、本方法を実施するルーチンを記憶し、および／または実行するように実装されることもあることを理解すべきである。
【００３５】
主題のタイミング・パラメータは、アプリケーションごとに変化するが、以下の少なくとも１つの形態を含むことができる。
・  ＭａｘＲｅｔｒｙＣｏｕｎｔ  −  このパラメータは、応答タイマが、タイムアウトした後に試みられる再試行の回数に対する最大値を設定する。
・  ＴＴＩＭＥＯＵＴ  −  このパラメータは、深い非応答的システムに起因してクライアントが如何に高速にタイムアウトするかを保存し、初期要求およびすべての後続の再試行がタイムアウトするための典型的な時間を意味している。
・  ＴＫＥＥＰＡＬＩＶＥ  −  このパラメータは、サーバが依然として使用可能であることを検証するために、クライアントが如何に高速にサーバにポーリングするかを保存する。
・  ＴＣＬＩＥＮＴ  −  このパラメータは、典型的な（すなわち、中央値の、または５０番目のパーセンタイル値の）クライアントが、如何に高速に冗長サーバの上でサービスを正常に回復させるかを保存する。
【００３６】
本記載の実施形態によれば、これらの値は、以下で説明されるように、適応的に（例えば、動的に）設定され、または調整される。これらのパラメータについての小さな値を使用して、できるだけ早く故障を検出し、代替サーバに切り替え（ＦＡＩＬＯＶＥＲ：フェイルオーバー）をし、ダウンタイムと失敗した要求とを最小にすることが望ましい。しかしながら、代替サーバに切り替えることは、そのサーバの上のリソースを使用して、クライアントを登録し、またそのクライアントについてのコンテキスト情報を取り出すことであると理解すべきである。あまりにも多数のクライアントが、同時に切り替えをする場合、過剰な回数の登録試行は、代替サーバを過負荷に駆動する可能性がある。それゆえに、重要でない一時的故障（トラフィックのバーストに起因したブレード・フェイルオーバー（ｂｌａｄｅ  ｆａｉｌｏｖｅｒｓ）または一時的に遅いプロセスなど）についての切り替えを回避することが有利であることもある。
【００３７】
したがって、同期化された再伝送とタイムアウト戦略とに、１つのシステム・インスタンスの故障に続くプールの中で、動作システムに対するトラフィックのスパイクまたはバーストを単に引き起こさせるのではなくて、代替サーバに対する再接続要求の形成が、クライアントそれら自体によって推進される。本記載の実施形態によれば、タイミング・パラメータは、適応され、および／または設定され、その結果、暗黙の故障検出が最適化される。
【００３８】
一実施形態においては、再試行の最大回数は、クライアント回復を改善する乱数に合わせて調整され、または設定される。これに関しては、プロトコルは、タイムアウト期間と最大再試行カウントとを指定する（またはネゴシエートする）が、クライアントは、一般的に、代替サーバに接続しようと試みる前に、最後の再試行がタイムアウトするのを待つことを必要とされない。通常、メッセージが、プロトコル・タイムアウトの期限切れに先立って応答を受信することになる確率は、非常に高い（例えば、９９．９９９％のサービス信頼性）。第１のメッセージが、プロトコル・タイムアウトの期限切れに先立って応答を受信しない場合、第１の再伝送が迅速で正しい応答を与えることになる確率は、いささか低くなり、また場合によってはずっと低くなる。肯定応答されなかった各再伝送は、次の再伝送の成功の確率がより低くなることを示唆する。
【００３９】
本記載の実施形態によれば、これらの可能性の高くない、またはますます絶望的になる再伝送のおのおのが続くのを単に待つのではなくて、クライアントは、異なる判断基準に基づいて非応答サーバに対して再伝送することを停止し、および／または異なった時間に代替サーバに切り替えることができる。異なるクライアントが、異なった時間に代替サーバに登録する場合、そのときにはこれらのクライアントの認証、識別およびセッション確立についての処理負荷は平坦にされるので、代替サーバはこれらのクライアントを受け入れる可能性がより高くなり、それによってサービス中断の持続時間が短くなる。これを達成するために、クライアントは、この実施形態において、試みられることになる再試行の回数をランダムに、すなわち、プロトコルの中でネゴシエートされる再伝送の試みの最大回数まで、割り付ける。もちろん、本明細書において提案される技法などの、ランダムに割り付けられたバックオフは、主要なサーバの大きな故障の後に代替サーバを過負荷状態に押し込める可能性があるトラフィック・スパイクを取り除かないこともあるが、しかしながら、より長い期間にわたってクライアントによって開始された回復の試みを拡張することにより負荷を形成することは、代替サーバ上の負荷を平坦にすることになる。
【００４０】
例示的な戦略は、メッセージまたは応答のタイマがタイムアウトするときはいつでも、各クライアントが、以下のプロシージャを実行するためのものである。
１．乱数を生成するか、またはクライアント固有の数、例えば、ネットワーク・インターフェースＭＡＣアドレスの指定された桁を使用する。
２．乱数のドメインを「ＭａｘｉｍｕｍＲｅｔｒｙＣｏｕｎｔ」バケットへと論理的に分割する。
３．乱数が分類されるバケットに基づいてこの故障したメッセージ（例えば、１つの再試行とＭａｘｉｍｕｍＲｅｔｒｙＣｏｕｎｔとの間の）についてＭａｘｉｍｕｍＲｅｔｒｙＣｏｕｎｔ値を選択する。
【００４１】
これは、一例にすぎない。ランダムに割り付けるアプローチは、様々なやり方で実現されることもある。例えば、アプローチは、別のサーバに対して再接続するコストに基づいて重み付けされる可能性もある。例えば、いくつかのサービスは、初期化される必要がある大量の状態情報、検証される必要があるセキュリティ認証情報、およびシステムにかなりの負荷をかけ、エンド・ユーザに対するサービス配信遅延を増大させる他の懸案事項を有する。いくつかのプロトコルについてのこれらのより高いコストの再接続を補償するために、ランダムに割り付けられた最大再試行カウントは、いくつかの再試行のオプションを除外すること（例えば、常に少なくとも１つの再試行を有すること）によるか、またはそれらのオプションに重み付けすること（例えば、どのようにしてタイムアウトが、指数関数的に重み付けされ得るかなど、最大再試行カウントに指数関数的に重み付けすること）によるかのいずれかで調整されることもある。最大再試行カウントの最小の数は、基礎となっているネットワークの動作と、より低いレイヤとトランスポート・プロトコルとの挙動により影響を受ける可能性があることに注意すべきである。−０−という最大再試行カウントは、いくつかの展開については適切とすることができるが、最大再試行カウントの最小の数は、他の展開では１とすることができる。
【００４２】
さらに、プロトコルによって使用される標準的な最大再試行カウントよりも短い可能性があるランダムに割り付けられた最大再試行カウントを単に設定することに加えて、追加のランダムに割り付けられた、増分のバックオフを使用して、さらにトラフィックを形成することもできる。
【００４３】
別の実施形態においては、故障検出時間は、応答時間についての履歴データと、成功した応答のために必要な再試行の回数とを収集することにより改善される。したがって、ＴＴＩＭＥＯＵＴおよび／または再試行の最大回数は、標準的なプロトコル・タイムアウトおよび再試行の戦略に比べて、より高速に故障を検出し、また回復をトリガするように、適応的に調整されることができる。データを収集すること、およびタイミング・パラメータを適応的に調整することは、様々な技法を使用して達成される得ることを理解すべきである。しかしながら、少なくとも１つの形態においては、データまたは応答時間、および／または再試行の回数は、例えば、日常ベースで、所定の期間にわたって、（例えば、クライアントによって）追跡され、または保持される。そのようなシナリオにおいては、追跡されたデータを使用して、適応できる、または動的な調整を行うことができる。例えば、タイマの調整された値は、例としてその日および／または前日など、与えられた期間にわたって追跡される最長の成功する応答時間よりも高い、一定の割合（例えば、６０％）に設定されることが（例えば、クライアントにより）決定され得る。変形形態においては、それらの値は、ネットワークの必要性に適合するように、例えば、１５分ごとに、１００パケットごとに、…など、定期的に更新されることもある。この履歴データを使用して、予測動作に基づいて調整を実施することもできる。
【００４４】
さらなる例においては、図４を参照して、クライアントとサーバとの間で使用されるプロトコルは、最大３回の再試行を伴う５秒間の標準的なタイムアウトを有する。クライアントＡは、サーバＢ１に対して要求を送信した後に、応答を５秒間待つ。サーバＢ１が、ダウンしているか、または到達できず、タイマの有効期限が切れる場合、クライアントＡは、再試行を送信し、さらに５秒間待つ。もう２回再試行し、各再試行の後に５秒間待ち、初期メッセージと後続の再試行とに対する応答を待つのに全部で２０秒間費やした後に、クライアントＡは、サーバＢ１がダウンしていることを最終的に決定することになる。次いで、クライアントＡは、別のサーバＢ２に対して要求を送信しようと試みる。
【００４５】
しかしながら、図５を参照して、また本記載の実施形態に従って、クライアントＡは、故障検出および回復の時間を短くすることができる。この例においては、クライアントＡは、サーバの応答時間を追跡し続け、２００ｍｓと４００ｍｓとの間にあるサーバの典型的な応答時間を測定する。クライアントＡは、５秒から、例えば、２秒（５倍の最大の観察された応答時間）へとタイマ値を減少させることができ、このことは、実際に観察された動作を使用して回復時間をより短くするような利点を有している。
【００４６】
さらに、クライアントＡは、それが送信するために必要とする再試行の回数を追跡することができる。サーバＢ１が、しばしば、第２または第３の再試行まで応答することがない場合、クライアントは、３回の再試行のプロトコル標準に従い続けるべきである。しかし、サーバＢ１は、常に元の要求に対して応答する可能性があり、したがって任意の再試行を送信することにおいてほとんど価値が存在しない。クライアントＡは、それがただ１回の再試行に２秒間のタイマを使用することができると決定する場合、図５に例証されるように、全体のフェイルオーバー時間を２０秒から４秒へと減少させる。
【００４７】
新しいサーバにフェイルオーバーした後に、１つの形態においては、クライアントＡは、登録のための標準的な、またはデフォルトのプロトコル値に戻り、それがより低い値を正当化するために新しいサーバの上で十分なデータを収集するまで、要求についての標準的な値を使用し続ける。
【００４８】
上記で指摘されるように、プロトコル値を極端に低下させる前に、代替サーバにログオンするために必要とされる処理時間が考慮されるべきである。クライアントが、アプリケーション・セッションを確立し、代替サーバによって認証を受ける必要がある場合、重要でない中断のために（例えば、単純なブレード・フェイルオーバーに起因して、またはＩＰネットワーク再構成をトリガするルータ故障に起因して）サーバの間で前後にはねること（ｂｏｕｎｃｉｎｇ  ｂａｃｋ  ａｎｄ  ｆｏｒｔｈ）を回避することが重要になる。それゆえに、少なくとも１つの形態においては、最小のタイムアウト値が設定され、また少なくとも１回の再試行が常に試みられる。
【００４９】
図６は、本記載の実施形態の別の変形形態を示すものである。これに関しては、サーバの重大な故障と、代替サーバを選択する必要性とを示す傾向が存在するかどうかを決定するために故障メッセージを相互に関連づけることが有利でありうる。クライアントＡが、同時にサーバＢ１に対して多数の要求を送信している場合に、このアプローチは当てはまる。サーバＢ１が、それらの要求（またはその再試行）のうちの１つに応答しない場合、進行中の他の要求に対する応答を待つことはもはや必要でなく、それは、これらの要求は、同様に失敗する可能性が高いからである。クライアントＡは、すべての現在の要求を代替サーバＢ２に対してすぐにフェイルオーバーし、方向づけ、また（例えば、ハートビートを用いて）それが回復したことを示す表示を獲得するまで故障したサーバＢ１にそれ以上の要求を送信しないようにすることができる。例えば、図６に示されるように、クライアントＡは、要求４についての再試行が失敗するときに代替サーバＢ２に対してフェイルオーバーすることができ、また次いで、それは、すぐに要求５および６を代替サーバに対して再試行することができる。クライアントＡは、５および６についての再試行がタイムアウトするまで待つことはない。
【００５０】
上記実施形態においては、クライアントＡは、サーバＢ１が、一連の要求に応答することに失敗するまで、サーバＢ１がダウンしていることを認識しない。これは、少なくとも以下のようにして、サービスに悪影響を及ぼす可能性がある。
・  逆方向トラフィック中断  −  時として、クライアント／サーバ関係は、両方向に機能する（例えば、携帯電話は、モバイル交換センタに対してコールを開始することもでき、モバイル交換センタからコールを受信することもできる）。サーバが、ダウンしている場合、サーバは、クライアントからの要求を処理することはなく、またサーバは、クライアントに対してどのような要求も送信しないことになる。クライアントが、しばらくの間、サーバに対してどのような要求も送信する必要がない場合、そのときには、この間隔中に、クライアントに向かう要求は、失敗することになる。
・  エンド・ユーザ要求の失敗  −  要求は、ＴＴＩＭＥＯＵＴ＊（ＭａｘＲｅｔｒｙＣｏｕｎｔ＋１）だけ遅延させられ、これは、いくつかの場合には、エンド・ユーザ要求の失敗を引き起こすのに十分な長さである。
【００５１】
したがって、別の実施形態においては、この問題に対する解決法は、指定された時刻に、キープアライブ・メッセージと呼ばれる特別なハートビートをサーバに対して送信し、例えば、トラフィックの量に基づいて、キープアライブ・メッセージの送信の間の時間を調整することである。ハートビート・メッセージと、キープアライブ・メッセージとは、類似した機構であるが、ハートビート・メッセージは、冗長サーバの間で使用され、またキープアライブ・メッセージは、クライアントとサーバとの間で使用されることに注意すべきである。キープアライブ・メッセージの間の時間は、ＴＫＥＥＰＡＬＩＶＥである。したがって、本記載の実施形態によれば、ＴＫＥＥＰＡＬＩＶＥの値は、サーバとネットワークとの動作に基づいて、例えば、トラフィック負荷に基づいて、調整されることもある。
【００５２】
クライアントＡが、サーバＢ１からキープアライブ・メッセージに対する応答を受信しない場合、そのときにはクライアントＡは、それが、サーバＢ１が故障しているかどうかを決定するための通常の要求に使用するのと同じタイムアウト／再試行アルゴリズムを使用することができる。その意図は、キープアライブ・メッセージが、動作コマンドがそうする前にサーバの非有用性を検出することができ、その結果、サービスは、実際のユーザ要求が、使用の可能性が高いサーバによって迅速にアドレス指定される適時に、代替サーバ（例えば、Ｂ２）に対して自動的に回復しうる、ということである。これは、クライアントが、クライアントにサービスを行うサーバ能力についての最新の知識を有していないときに、サーバに対して要求を送信するよりも好ましい。
【００５３】
本記載の実施形態を例証するために、図７において、クライアントＡは、低トラフィックの期間中に、定期的なキープアライブ・メッセージを主要なサーバＢ１に対して送信し、また肯定応答を受信することを期待する。しかしながら、主要なサーバＢ１が、この時間中に故障する場合、クライアントＡは、故障したキープアライブ・メッセージによって故障を検出することになる。これに関しては、故障した主要なサーバが、例えば、再試行の最大回数内の調整されたタイムアウト値の範囲内の、キープアライブ、またはその再試行に応答しない場合、クライアントＡは、代替サーバＢ２にフェイルオーバーすることになる。高トラフィックの期間中に、クライアントＡは、通常の過程において要求を送信しており、また応答を受信しているが、キープアライブ・メッセージについての必要性は存在しない。この場合には、要求は決して遅延されないことに留意すべきである。
【００５４】
もちろん、トラフィック負荷は、様々な技法を使用して測定されることも、または予測されることもある。例えば、実際のトラフィック・フローが、測定されることもある。１つの代替案として、１日のうちの時間帯を使用して、トラフィック負荷を予測することもできる。
【００５５】
さらなる機能強化は、あらゆるキープアライブの後ではなくて、あらゆる要求／応答の後にキープアライブ・タイマを再スタートすることである。これは、より高いトラフィックの期間中により少ないキープアライブをもたらすことになるが、サーバを用いた非アクティブの長い期間が存在しないことをも依然として保証している。
【００５６】
別の機能強化は、クライアントが代替サーバにも定期的にキープアライブ・メッセージを送信することであり、それらのステータスを追跡することである。次いで、主要なサーバが故障する場合、クライアントは、代替サーバを単にランダムに選択するよりも使用の可能性が高いサーバに対する迅速で正常な回復の確率を増大させる。
【００５７】
いくつかの形態においては、サーバはまた、キープアライブ・メッセージを監視して、クライアントが依然として動作しているかどうかをチェックすることもできる。サーバが、それがもはやキープアライブ・メッセージ、または他の任意のトラフィックを送信していないことを検出する場合に、サーバは、それをウェイクアップさせるために、それに対してメッセージを送信するか、または少なくとも警告を報告することができる。
【００５８】
他のパラメータと同様に、ＴＫＥＥＰＡＬＩＶＥは、故障を迅速に検出できる程度に短いが、サーバが、クライアントからのキープアライブ・メッセージを処理する過剰な量のリソースを使用しているほどは短くはないように設定されるべきである。クライアントは、サーバと、ＩＰネットワークとの動作に基づいてＴＫＥＥＰＡＬＩＶＥの値を適応させることができる。
【００５９】
ＴＣＬＩＥＮＴは、クライアントが、代替サーバの上でサービスを回復するために必要とされる時間である。それは、以下についての時間を含んでいる。
・  クライアントが、代替サーバを選択すること。
・  代替サーバとプロトコルのネゴシエートをすること。
・  識別情報を提供すること。
・  認証情報を（恐らくは相互に）交換すること。
・  サーバによる認可をチェックすること。
・  サーバにおいて、およびサーバによってセッション・コンテキストを生成すること。
・  サーバによって適切な監査メッセージを生成すること。
【００６０】
これらのファクタのすべては、ターゲット・サーバと、恐らくは他のサーバ（例えば、ＡＡＡサーバ、ユーザ・データベース・サーバなど）との時間およびリソースを消費する。サポートするユーザの識別、認証、認可およびアクセス制御は、多くの場合にＴＣＬＩＥＮＴが、増大することを必要とする。
【００６１】
本記載の実施形態の別の変形形態においては、ＴＣＬＩＥＮＴは、冗長サーバとのあらかじめ構成されたセッション、またはウォーム・セッションをそれらのクライアントに保持させることにより、短縮することができる。すなわち、登録され、またそれらの主要なサーバ（例えば、Ｂ１）からのサービスを取得するときに、クライアントＡは、別のサーバ（例えば、Ｂ２）と接続し、またそのサーバを用いて認証し、その結果、主要なサーバＢ１が故障する場合に、クライアントＡは、すぐに他のサーバＢ２に対して要求の送信を開始することができるようになる。
【００６２】
多数のクライアントが同時に（例えば、サーバまたはネットワーキング設備の故障の後に）サーバに対してログオンしようと試み、かなりのリソースが、登録をサポートするために必要とされる場合、過負荷状況が起こる可能性がある。もちろん、本記載の実施形態の技法が使用される場合、代替サーバに対する過負荷の機会は、大いに低減されることになる。
【００６３】
それにもかかわらず、この可能性がある過負荷は、いくつかの他の追加のやり方で対処可能であり、これらのやり方は、ＴＣＬＩＥＮＴを増大させないことになる。
・  代替サーバに対する回復をトリガするとすぐに、クライアントは、サービスを受けるクライアントの数、またはバックアップ・システムにリダイレクトされる膨大なメッセージの発生を低減させるように取り扱われているトラフィックの量に基づいて、構成可能な期間を待つことができる。クライアントは、代替サーバに対してログオンしようと試みる前に、ランダムな長さの時間を待つことができるが、平均時間は、構成化可能であり、また同時にフェイルオーバーする可能性が高い他のクライアントの数に応じて設定可能である。多数の他のクライアントが存在する場合、平均時間は、より高い値に設定されることもある。
・  代替サーバは、通常の過負荷として登録ストームを取り扱うべきであり、新しいセッション要求をスロットルで調整して、代替サーバに既に登録／接続しているユーザに対して受け入れることができないサービス品質を配信することを回避している。クライアント要求のいくつかは、それらがサーバに対してログオンしようと試みるときに拒絶されることになる。それらは、再試行する前にランダムな期間を待つべきである。
・  登録要求を拒絶するときに、代替サーバは、サーバに対してログオンしようと再試行する前にどれだけ長い間それがバックオフする（待つ）べきかをクライアントに対して積極的に示すことができる。これは、必要な量だけ登録トラフィックを分散するサーバ制御を与える。
・  いくつかのサーバが存在する場合の負荷分散の場合に、サーバは、それらがどれだけ過負荷であるかに応じて、それらのＤＮＳ  ＳＲＶレコードにおける重みを更新することができる。１つのサーバが故障するときに、そのクライアントは、代替サーバを決定するためにＤＮＳの問合せを行うことになり、したがって、それらの大部分は、最もビジーでないサーバに移行することになる。
【００６４】
当業者なら、上記で説明された様々な方法のステップは、プログラムされたコンピュータ（例えば、制御モジュール１０３、１０５または１０７）によって実行され得ることを簡単に認識するであろう。本明細書において、いくつかの実施形態はまた、プログラム・ストレージ・デバイスを、例えば、デジタル・データ・ストレージ媒体を対象として含むようにも意図され、これらのプログラム・ストレージ・デバイスは、マシン読取り可能、またはコンピュータ読取り可能であり、また命令のマシン実行可能プログラム、またはコンピュータ実行可能プログラムを符号化し、そこでは前記命令は、前記上記で説明された方法のステップのうちの一部または全部を実行する。プログラム・ストレージ・デバイスは、例えば、デジタル・メモリ、磁気ディスクおよび磁気テープなどの磁気ストレージ媒体、ハード・ドライブ、または光学的読取り可能デジタル・データ・ストレージ媒体とすることができる。実施形態はまた、上記で説明された方法の前記ステップを実行するようにプログラムされるコンピュータをカバーするようにも意図される。
【００６５】
さらに、クライアントまたはサーバとしてラベル付けされる任意の機能ブロックを含む、図面の中に示される様々な要素についての機能は、専用のハードウェアならびに適切なソフトウェアと関連づけてソフトウェアを実行することができるハードウェアの使用を通して提供されてもよい。プロセッサによって提供されるときに、それらの機能は、単一の専用のプロセッサによって、単一の共用のプロセッサによって、またはそれらのうちのいくつかが共用され得る複数の個別のプロセッサによって提供されてもよい。さらに、用語「プロセッサ」または「コントローラ」の明示的な使用は、ソフトウェアを実行することができるハードウェアだけを排他的に意味するように解釈されるべきではなく、また限定することなく、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ）のハードウェアと、ネットワーク・プロセッサと、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）と、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）と、ソフトウェアを記憶するためのリード・オンリー・メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）と、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）と、不揮発性ストレージとを暗黙のうちに含むことができる。他の既存のおよび／またはカスタムしたハードウェアもまた、含まれる可能性もある。同様に、図面の中に示される任意のスイッチは、概念的なものにすぎない。それらの機能は、プログラム・ロジックのオペレーションを通して、専用のロジックを通して、プログラム制御と専用のロジックとの相互作用を通して、または手動によってさえも実行可能であり、特定の技法は、より具体的に文脈から理解されるように、実装者によって選択可能である。
【００６６】
方法２００を含めて、本記載の実施形態は、様々な環境において使用され得ることもまた、理解すべきである。例えば、本記載の実施形態は、様々なミドルウェア構成、トランスポート・プロトコル、および物理ネットワーキング・プロトコルを用いて使用され得ることを認識すべきである。非ＩＰベースのネットワーキングもまた、使用されることもある。
【００６７】
上記の説明は、単に本発明の特定の実施形態の開示を提供しているにすぎず、本発明をそれだけに限定する目的のために意図されてはいない。したがって、本発明は、上記で説明された実施形態だけに限定されるものではない。むしろ、当業者が本発明の範囲内に含まれる代替の実施形態を考案し得ることが認識される。
【図１】
2013544408.tif 000002
【図２】
2013544408.tif 000003
【図３】
2013544408.tif 000004
【図４】
2013544408.tif 000005
【図５】
2013544408.tif 000006
【図６】
2013544408.tif 000007
【図７】
2013544408.tif 000008
【国際調査報告】
2013544408.tif 000009
2013544408.tif 000010
2013544408.tif 000011