JP2014504392A

JP2014504392A - ネットワーク要素のサービス回復のための方法およびシステム

Info

Publication number: JP2014504392A
Application number: JP2013539899A
Authority: JP
Inventors: バウアー，エリック; ユースタス，ダニエル，ダブリュ．; アダムス，ランディ，スーザン
Original assignee: アルカテル−ルーセント
Priority date: 2010-11-17
Filing date: 2011-11-09
Publication date: 2014-02-20
Anticipated expiration: 2031-11-09
Also published as: CN103222253A; CN103222253B; KR20130088172A; KR101513863B1; US20120124413A1; EP2641385A1; US9130967B2; JP5550793B2; WO2012067910A1

Abstract

ネットワーク要素の回復のための方法およびシステムが提供される。１つの形態では、フロントエンド・サーバは、バックエンド・サーバによって返されたエラーまたは利用不可能性のメッセージをインテリジェントにプロキシし、フロントエンド・サーバの障害をシミュレートする。少なくとも１つの形態では、フロントエンド・サーバはまた、代替システムまたはサイトにサービスを回復するためにクライアントを指示することによって、クライアントにとって、より優れたサービス可用性、信頼性、および／または経験の質が保証されることを決定するための知能またはロジックを含む。

Description

本発明は、ネットワーク要素のサービス回復のための方法およびシステムに関する。本発明は、詳細には、ネットワーク・クライアントのサービス回復の分野に関し、したがって、それを特に参照して記述するが、本発明は、他の分野および用途でも有用であることを理解されるであろう。

背景として、現在のシステムの多くは、バックエンド・データベース・サーバと対話するフロントエンドのウェブ・サーバなど、複数のネットワーク要素を統合することによって実装されている。これらのシステムが重要なサービスを提供する場合、多くの場合、特に、ネットワーキング装置または設備の障害、または装置をホスティングしているサイトが利用不可能またはアクセス不能になる他の外的要因によるイベントの後に、サービス可用性を最大限にするために、これらは複数のサイトで複製されている。クライアント・デバイス（たとえばウェブ・ブラウザ）に面するフロントエンド・マシンの障害（たとえば深刻な利用不可能性／非応答性）をクライアントによって自動的に検出し、サービスを代替サイトに自動的に回復するようにクライアントをトリガーできる一方、バックエンド・サーバの障害は、通常、クライアント始動の回復をトリガーしない。たとえば、電子商取引サイトをサポートするデータベース・サーバが利用不可能な場合、通常の実装では、単にクライアントに、サイトは一時的に利用できないので、後で再び試みることを伝えるウェブページを返すだけである。したがって、現在の標準的な技法は、（クライアントと直接的に通信しないバックエンド要素の障害について）複雑で複数の要素のソリューションが記述的なエラーをクライアントに返すことである。

バックエンド・サーバ（データベースなど）に障害が発生した場合、従来の戦略は、地理的に分散された冗長システムを活用することである。その際に、フロントエンド・サーバ（たとえばウェブ・サーバ）は、地理的にリモートにあるサイト上の冗長データベース・サーバにサービスを回復する。しかし、このために、２つの地理的にリモートにあるサイト間でメッセージが送信される。これらのサイトが遠く離れていて、ウェブ・サーバとデータベースとの間で必要とされるメッセージが多くある場合は、これによって、ウェブ・サーバの応答時間が著しく増加し、サイト間でかなりの帯域幅を使用する可能性がある。したがって、このソリューションでは、要素がリモート・サイトに位置する場合、遅延およびネットワーク・トラフィックが増加する場合がある。

ネットワーク要素のサービス回復のための方法およびシステムが提供される。現在の標準的な技法は、自動的なサービス回復をトリガーするためにエラーを操作するのではなく、（クライアントと直接的に通信しないバックエンド要素の障害について）複雑で複数の要素のソリューションが記述的なエラーをクライアントに返すことである。十分に記述的なエラーは、一部の区分のユーザにとって有益であるが、他の多くのユーザは、むしろ自分たちのために（スマート）クライアント・デバイスが自動的にサービスを回復させることを望む。

一実施形態では、本方法は、フロントエンド・サーバによって、ダウンストリームのネットワーク要素のエラーまたは利用不可能性を検出するステップと、クライアントに応答コードを送信して、クライアントがサービスを代替フロントエンド・サーバにリダイレクトするか、または代替フロントエンド・サーバで回復するようにトリガーするステップとを含む。

別の実施形態では、フロントエンド・サーバはウェブ・サーバである。

別の実施形態では、ダウンストリーム・ネットワーク要素はデータベース・サーバである。

別の実施形態では、方法は、クライアントとフロントエンド・サーバとの間のセッションをサスペンドすることをさらに含む。

別の実施形態では、検出は、ダウンストリーム・ネットワーク要素からメッセージを受信するステップ、またはタイムアウトした応答タイマを検出するステップのうちの１つを含む。

別の実施形態では、本方法は、フロントエンド・サーバによって、ダウンストリーム・ネットワーク要素のエラーまたは利用不可能性を検出するステップと、要素回復またはクラスタ回復を実行するべきかどうかを決定するステップと、要素回復が決定された場合、フロントエンド・サーバによって、障害が発生したダウンストリーム・ネットワーク要素に対応する代替ダウンストリーム・ネットワーク要素に切り替えるステップと、クラスタ回復が決定された場合、フロントエンド・サーバによってクライアントに応答コードを送信して、クライアントが代替の冗長フロントエンド・サーバにサービスをリダイレクトするか、または代替の冗長フロントエンド・サーバで回復するようにトリガーするステップとを含む。

別の実施形態では、決定はデータ・トラフィックに基づいている。

別の実施形態では、本システムは、ダウンストリーム・ネットワーク要素のエラーまたは利用不可能性を検出し、クライアントに応答コードを送信して、クライアントがサービスを代替フロントエンド・サーバにリダイレクトするか、または代替フロントエンド・サーバで回復するようにトリガーするフロントエンド・サーバの制御モジュールを含む。

別の実施形態では、フロントエンド・サーバは、ダウンストリーム・ネットワーク要素からメッセージを受信することによって、またはタイムアウトした応答タイマを検出することによってエラーを検出する。

別の態様では、クライアント、フロントエンド・サーバ、ダウンストリーム・ネットワーク要素、代替フロントエンド・サーバ、および代替ダウンストリーム・ネットワーク要素は、ＩＭＳ要素である。

別の実施形態では、本システムは、ダウンストリーム・ネットワーク要素のエラーまたは利用不可能性を検出し、要素回復またはクラスタ回復を実行するべきかどうかを決定し、要素回復が決定された場合、フロントエンド・サーバによって、障害が発生したダウンストリーム・ネットワーク要素に対応する代替ダウンストリーム・ネットワーク要素に切り替え、クラスタ回復が決定された場合、フロントエンド・サーバによって、クライアントに応答コードを送信して、クライアントがサービスを代替フロントエンド・サーバにリダイレクトするか、または代替フロントエンド・サーバで回復するようにトリガーするフロントエンド・サーバの制御モジュールを含む。

別の実施形態では、フロントエンド・サーバの検出はデータ・トラフィックに基づいている。

別の実施形態では、クライアント、フロントエンド・サーバ、ダウンストリーム・ネットワーク要素、代替フロントエンド・サーバ、および代替ダウンストリーム・ネットワーク要素は、ＩＭＳ要素である。

本発明の適用性のさらなる範囲は、以下に提供する詳細な説明から明白になるであろう。しかし、本発明の精神および範囲内の様々な変更形態および修正形態を当業者に明白にするため、詳細な説明および特定の例は、本発明の好適な実施形態を示しているが、例示を目的としてのみ提供されるものであることを理解されたい。

ここで、本発明の実施形態による装置および／または方法の一部の実施形態について、例示のみを目的として、添付図面に関して記述する。

本記載の実施形態を組み込むことができる例示的なシステムのブロック図である。図１のシステムの例示的な動作を示すブロック図である。図１のシステムの例示的な動作を示すブロック図である。本記載の実施形態による例示的な方法を示すフローチャートである。本記載の実施形態による例示的な方法を示すフローチャートである。

本記載の実施形態によると、ネットワークのダウンストリーム要素に障害がある、または利用不可能な場合には、静的なエラー記述または他の端末の応答をクライアントに単に返すだけでなく、フロントエンド・サーバ（たとえばウェブ・サーバ）は、動作可能なシステム／サイト（たとえば冗長または代替の経路またはクラスタ）への自動回復またはリダイレクションを試みるようにクライアントをトリガーする。目的は、障害が発生したまたは利用不可能なサーバが修理または回復される間、より長いサービス停止を回避するために、利用可能なシステム／サイトにサービスを自動的に回復またはリダイレクトすることである。

この点で、本記載の実施形態によると、フロントエンド・サーバは、バックエンド・サーバ（つまり、典型的には直接的にクライアントと対話しないダウンストリーム・サーバ）によって返されたエラー・メッセージをインテリジェントにプロキシし、フロントエンドから遠ざけるようにサービスをリダイレクトするために、状況をシミュレートまたは詐称する（たとえばサーバの障害または過負荷状態）。少なくとも１つの形態では、フロントエンド・サーバはまた、サービスを回復するためにクライアントを代替（つまり地理的に冗長な）システムまたはサイトにリダイレクトすることで、クライアントにとって、より優れたサービス可用性／信頼性／経験の質のうちの少なくとも１つが保証されることを決定するための知能またはロジックを含む。

概して、アプリケーション・プロトコルは全体的には、異なるタイプの応答コードをサポートし、その一部は本質的に終端または記述的であり（たとえば、ウェブページが見つからない、ユーザは許可されていない、ゲートウェイに障害があるなど）、その一部は、同じかまたは異なるサーバへの回復動作を取るようにクライアントをトリガーすることができる（たとえば、一時的に移動、サービスが利用不可能、混み合っている、再試行など）。本記載の実施形態によると、フロントエンド・サーバは、バックエンド・システムからの潜在的に回復可能なエラーまたは欠陥を、クライアントに対して返された応答コードなどのメッセージにマッピングする。これらのマッピングされた応答コードは、代替システム／サイトへのそれらの要求を再試行するようにクライアントをトリガーする。したがって、本記載の実施形態によると、ウェブ・サーバ・フロントエンドが、データベース・サーバの障害または利用不可能な状態を、たとえば、クライアントが表示するべきエラー・ウェブページにマッピングするのではなく、フロントエンド・ウェブ・サーバが、クライアントに完全に動作可能なシステム／サイトにサービスを回復またはリダイレクトさせる状況（たとえば障害）をシミュレートする。

本記載の実施形態を実施するために使用するコードまたはメッセージの例として、上に参照した応答コードのタイプは、用途によって異なる場合があることを理解されたい。たとえば、ダウンストリーム障害がフロントエンド・サーバによって検出された場合、５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅコードなど、深刻な問題を示すコードは、フロントエンド・サーバによって目的変更（ｒｅｐｕｒｐｏｓｅ）され、それ自身の障害をシミュレートするためにフロントエンド・サーバによってクライアントに伝送されて、切替えをトリガーすることができる。同様に、ダウンストリーム過負荷状態（またはダウンストリーム要素を利用不可能にする他の状態）が検出された場合、フロントエンド・サーバは、３０２ＭｏｖｅｄＴｅｍｐｏｒａｒｉｌｙコードなど、リダイレクション応答をクライアントに伝送して、代替クラスタへのリダイレクションをトリガーすることができる。

さらに他の例では、フロントエンド・サーバは、障害または利用不可能な他の状態を含む利用不可能なすべての状況において、３０２ＭｏｖｅｄＴｅｍｐｏｒａｒｉｌｙコードなど、リダイレクション応答を伝送することができる。このシナリオでは、本記載の実施形態を実施するために、深刻な問題（上記の５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅコードなど）を示すコードを使用する必要性がなくなる。

さらに他の例では、５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅコードなど、深刻な問題を示すコードは、障害または利用不可能な他の状態を含む、利用不可能なすべての状況で、フロントエンド・サーバによって目的変更され、それ自身の障害をシミュレートするためにフロントエンド・サーバによってクライアントに伝送されて、切替えをトリガーすることができる。

ここで、図示しているものが例示的な実施形態を示すことのみを目的とするものであり、特許請求の主題を限定することを目的とするものではない図面を参照すると、図１は、本記載の実施形態を組み込むことができるシステム１００を示す図である。図示したように、システム１００は、サービス「Ｂ」を提供する機能エンティティと通信状態にある、またはセッションを実行しているネットワーク要素またはクライアントＡ（１０２）を含む。この機能エンティティは、ネットワーク要素またはサーバＢ１（１０４）、およびネットワーク要素またはサーバＢ２（１０８）を含む。示したサービスＢを提供する機能エンティティは、サービス「Ｃ」を提供する機能エンティティと通信する。この機能エンティティは、ネットワーク要素またはサーバＣ１（１０６）およびネットワーク要素またはサーバＣ２（１１０）を含む。図示するように、これらの要素Ｃ１およびＣ２は、要素Ｂ１およびＢ２に対してダウンストリームである。

さらに、各ネットワーク要素は、たとえば制御モジュール１０３、１０５、１０７、１０９、および１１１など、制御モジュールを含むことが示されている。制御モジュールは、ネットワーク要素に機能を提供し、いくつかの実施形態では、本記載の実施形態の機能を実現するために適切なルーチンを収容しかつ／または実行するものと理解される。たとえば、フロントエンド・サーバＢ１（１０４）は、少なくとも１つの形態において、図２〜図５に関連して以下に記述される方法を含んだ本記載の実施形態による方法に対応するルーチンを実行するように動作可能な制御モジュール１０５を含む。

図示の構成では、それぞれネットワーク要素Ｂ１およびＣ１に対して、ネットワーク要素Ｂ２およびＣ２は、代替の冗長要素（代替要素または冗長要素とも呼ぶ）として働くことを理解されたい。この点において、そのような代替サーバもしくは冗長サーバまたは代替の冗長サーバは、それが対応するプライマリ・サーバを必ずしも正確に複製しないことを理解されたい。また、参照しやすくするために、（たとえばＢ１およびＣ１について）１つの対応する代替の冗長要素だけが本明細書に示されているが、ネットワーク要素は、２つ以上の対応する代替の冗長要素を有することができることを理解されたい。図示するように、要素Ｂ１およびＣ１は、地理的に近い要素のクラスタを形成し、要素Ｂ２およびＣ２は、地理的に近い要素のクラスタを形成する。少なくとも１つの例示的な形態では、ネットワーク要素Ｂ１およびＢ２は、ウェブ・サーバなどのフロントエンド・サーバとして機能する一方、ネットワーク要素Ｃ１およびＣ２は、データベース・サーバなどのバックエンド・サーバとして機能する。単一のフロントエンド・サーバ（Ｂ１またはＢ２）が示されているが（参照しやすくするため）、ソリューションでは、必ずしも単一のフロントエンド・サーバだけである必要はないことを理解されたい。複雑なサービス（たとえばＩＰテレビのヘッドエンド）は、サーバ一式全体にわたって実装することができ、論理上、より幅広いソリューション内にあるシステムのより小さなクラスタへと整理することも可能であり得る。それらのより小さなクラスタのそれぞれは、フロントエンド・サーバとして働くシステムを有することもあり得る。これは、異なるフロントエンド・サーバを備えたより大きなクラスタ内にフロントエンド・サーバを備えた、より小さなクラスタを有する再帰的なケースを含む。

もちろん、ＩＰマルチメディア・サブシステム（ＩＭＳ）要素を含む、他のタイプのネットワーク要素を使用することもできる。また、セッション開始プロトコル（ＳＩＰ）を含む、様々な信号プロトコルを使用できることを理解されたい。またさらに、ネットワーク要素は、ある目的のためにはクライアントとして、しかし別の目的のためにはサーバとして働くことを理解されたい。したがって、示された構成は、単に例として理解するべきである。また、これと同じように、図１は、冗長要素Ｃ１およびＣ２を含むが、冗長要素Ｄ１およびＤ２、Ｅ１およびＥ２…など（図示せず）も、システムにある場合があることを理解されたい。少なくとも１つの形態において、主要な要素（Ｂ１、Ｃ１など）のすべては、１つのサイトの第１のクラスタ（クラスタ１）に位置すると想定され、少なくとも１つの形態において、冗長要素（Ｂ２、Ｃ２など）のすべては、第２のサイトの第２のクラスタ（クラスタ２）に位置すると想定される。

典型的には、クライアントと直接対話するクラスタの「エッジ」要素の障害からの回復オプションは１つだけある（たとえば、「Ｂ１」に障害が発生した場合、クライアントは「Ｂ２」に回復する必要がある）。しかし、本記載の実施形態によると、エッジ内の要素の障害に対して２つの回復オプションがある。この点において、場合によっては、より速くより優れた回復を可能にするために、要素のクラスタを回復グループへと整理することができる。

図２を参照すると、要素回復をシステムに使用する技術が示されている。この点において、非エッジ要素Ｃ１の障害は、要素Ｃ２への要素Ｂ１の切替えによって回復することができる。理想的には、要素Ｂ１が、障害を十分に速く検出し、要素Ｃ２を用いて十分なセッション・コンテキストを回復するため、回復はクライアントＡにとって透過的である。分かるように、要素Ａ１は、依然経路１５０で要素Ｂ１と通信するが、要素Ｂ１は、経路１５２で要素Ｃ２と通信する。

図３を参照すると、クラスタ回復をシステムに使用する技術が示されている。この点では、非エッジ要素Ｃ１の障害または利用不可能性は、クラスタ１から離れてクラスタ２にクライアントＡを切り替える、またはリダイレクトすることによって、回復または対処することができる。この場合、クライアントＡは、要素Ｂ２へのサービスの再確立に明示的に関係している。要素Ｃ１の障害または利用不可能性は、要素Ｃ１の障害または利用不可能性に応じて、要素Ｂ１によってクライアントＡに返される深刻な応答コード（たとえば、５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅまたは３０２ＭｏｖｅｄＴｅｍｐｏｒａｒｉｌｙなどのリダイレクション応答）を介してクライアントＡに明示的に通信され、クライアントＡは、代替クラスタへの回復を開始することが期待される。この場合、回復の後に、クライアントＡは、経路１６０で要素Ｂ２と通信し、要素Ｂ２は、経路１６２で要素Ｃ２と通信する。クラスタ回復において、エッジおよび／または他の要素は、自身で回復を試みるのではなく、クライアント（たとえばクライアントＡ）に障害または利用不可能応答を明示的にプロキシして戻すことに注意されたい。次に、クライアントは、代替クラスタにリダイレクトするか切り替える。さらに、暗黙的な障害（たとえばタイムアウト期限切れ、ハートビートの損失）は、同様に、クライアントにプロキシして戻される適切な明示的な障害へと変換されるため、クライアントは、サービスをリダイレクトまたは切り替えることができる。

要素回復とクラスタ回復との違いは、ソリューションの様々な要素において異なるように見える可能性があることに注意されたい。たとえば、要素Ｂ１が、図２のＣ１からＣ２への要素回復を実行する間、クライアントＡは、回復動作が取られたことを認識しない。同様に、図３のサイト１からサイト２へのクラスタ回復は、クライアントＡには、Ｂ１の明白な障害の後に、単にＢ２への要素回復として見える可能性がある。

本記載の実施形態は、様々なやり方で実施できることを理解されたい。たとえば、本記載の実施形態の方法は、受信するエラーまたは他の応答に対するクラスタ回復技術を実行するフロントエンド・サーバの機能を含むことができる。さらなる実施形態では、フロントエンド・サーバは、また、要素回復またはクラスタ回復を特定のエラーまたは応答の検出に関して実施するべきかどうかについて決定を行うために、ロジックを実行するか、または知能を有することができる。いずれの場合でも、本記載の実施形態による方法は、様々なやり方でシステムにおいて実現できることが理解されるであろう。この点において、様々なソフトウェア・ルーチンまたはハードウェア構成を使用することができる。たとえば、本出願の方法を実行するソフトウェア・ルーチンは、フロントエンド・サーバＢ１（１０４）の制御モジュール１０５など、フロントエンド・サーバの制御モジュールによって収容かつ／または実行することができる。もちろん、そのようなルーチンはまた、適切なネットワーク要素においてネットワーク内で分散することができ、その一部は図１に図示していない。

したがって、ここで図４を参照すると、本記載の実施形態による方法２００が示されている。方法２００は、ダウンストリーム・ネットワーク要素からのエラーまたは利用不可能性を検出することを含む（２０２）。そのような検出は、様々な従来のやり方で達成できる場合がある。たとえば、明示的なメッセージまたは暗黙的なインジケータの受信時（たとえば応答タイマのタイムアウト）に、エラーまたは利用不可能性を検出できる場合がある。検出時に、フロントエンド・サーバは、クラスタ回復技術を実行する。すなわち、フロントエンド・サーバは、システムにおいて代替の冗長フロントエンド・サーバにクライアントが切り替えることをトリガーするために、障害またはリダイレクトのメッセージをクライアントに送信する（２０４）。障害またはリダイレクトのメッセージは、様々な形態を取ることができる（たとえば、５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅまたは３０２ＭｏｖｅｄＴｅｍｐｏｒａｒｉｌｙなどのリダイレクション応答）。このようにして、フロントエンド・サーバは、サービスを障害または利用不可能な状態をシミュレートするため、クライアントは、冗長経路に完全に切り替えるか、または冗長経路にリダイレクトする（たとえば、代替の冗長フロントエンド・サーバに切り替えることで、代替クラスタに切り替える）。また、クライアントとオリジナルのフロントエンド・サーバとの間のセッションは、クライアントが代替サーバにサービスをリダイレクトすることを優先してサスペンドされる（２０６）。いくつかの実施形態では、過負荷のサーバは、過負荷の短い期間の間に、代替サーバに少数のサービス要求を単にリダイレクトすることができる。したがって、プライマリ・サーバは、クライアントのトラフィックの大部分を運び続けるが、（過負荷の短い期間の間に品質低下したサービスを伝達するのではなく）サービスの合格品質を保証するために、少数のトランザクションが他のサーバによって扱われる。

上記のように、フロントエンド・サーバは、また、クラスタ回復または要素回復を使用する適切さを決定するためにロジックまたは知能を含むことができる。この点において、図５を参照すると、方法３００が示されている。方法３００は、ダウンストリーム・ネットワーク要素におけるエラーまたは利用不可能性の検出時に開始される（４０２）。そのようなエラー検出は、様々な従来のやり方で達成できる場合がある。たとえば、明示的なメッセージまたは暗黙的なインジケータの受信時（たとえば応答タイマのタイムアウト）に、エラーまたは利用不可能性を検出できる場合がある。この時点で、フロントエンド・サーバは回復戦略を決定する（３０４）。もちろん、少なくとも１つの形態において、フロントエンド・サーバは、要素回復プロセスまたはクラスタ回復プロセスが実行されるかどうかを決定する。この決定は、様々なやり方で達成できる場合がある。たとえば、フロントエンド・サーバは、障害が発生したか、または利用不可能なサーバと交換するデータの量（またはデータ・トラフィック）を考慮に入れることができる。データ交換速度（またはデータ・トラフィック）が比較的低い場合、適応的に、または定期的に設定できるしきい値に基づいて、またはサブルーチンの実行に基づいて、フロントエンド・サーバは、要素回復がシステムのためにより良いことを決定することができる。他の状況では、同様の基準に基づいて、フロントエンド・サーバは、クラスタ回復が実行されることを決定することができる。

要素回復プロセスが決定される場合、フロントエンド・サーバは、障害が発生したネットワーク要素に対応する代替の冗長なネットワーク要素と通信するために単に切り替える（３０６）。フロントエンド・サーバは、クライアントとのセッションを継続する（３０８）。

しかし、クラスタ回復が実行されることをフロントエンド・サーバが３０４で決定する場合、フロントエンド・サーバは、クライアントに障害またはリダイレクトのメッセージを送信する（３１０）。障害またはリダイレクトのメッセージは、様々な形態を取ることができる（たとえば、５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅまたは３０２ＭｏｖｅｄＴｅｍｐｏｒａｒｉｌｙなどのリダイレクション応答）。もちろん、上記のように、障害またはリダイレクトのメッセージは、冗長な代替のサーバ経路またはクラスタにクライアントがリダイレクトするようにトリガーする。クライアントとフロントエンド・サーバとの間のセッションは、サスペンドされる（３１２）。上記のように、一部の変形形態では、過負荷のサーバは、過負荷の短い期間の間に、代替サーバに少数のサービス要求を単にリダイレクトすることができる。したがって、プライマリ・サーバは、クライアントのトラフィックの大部分を運び続けるが、（過負荷の短い期間の間に品質低下したサービスを伝達するのではなく）サービスの合格品質を保証するために、少数のトランザクションが他のサーバによって扱われる。

本記載の実施形態の他の変形形態では、３つ以上の要素（たとえばＤ１／Ｄ２、Ｅ１／Ｅ２など）によるソリューションは、一部の要素障害は要素回復を通じて緩和され、一部はクラスタ回復を通じて緩和されるハイブリッド回復戦略を展開させる。そのようなシナリオでは、図５に示すものに類似した方法を利用することができる。さらに、回復クラスタは、サイト上のすべてのソリューション要素の一式より小さい場合があるため、サイト１の他の要素がサービスを伝達し続ける間に、サイト１の１つの要素の障害は、サイト２の要素の小さな回復クラスタへと一部のサービスを回復できる場合がある。

本記載の実施形態は、特定の例示を用いて示すことができる。この点において、クラスタ回復の優先事項の１つは、最初にローカル・サーバに、ローカル・サーバのいずれも利用可能でない場合はリモート・サーバに、そのサービス要求を送信するように各要素を構成することである。これを達成する１つの方法は、完全修飾ドメイン名（ＦＱＤＮ）プールの各サーバに優先度を割り当てることを可能にする、ＤＮＳＳＲＶレコードを用いることである。この構成を用いると、要素に障害が発生し、サービスがリモート・サイトへ切り替えられる場合、その要素はリモート・サイトにある他の要素にそれ自身の要求を送信する。同じサイト内に発生する要素間のほとんどの通信を用いると、遅延は、簡単な要素の切替えほどには増加しない。

上記の例では、Ｃ１／Ｃ２サーバのＦＱＤＮは、このように実装することができる。典型的には、クライアントがサーバＢ２にフェイルオーバーした場合、サーバＢ２は、ローカル・サーバＣ２を自動的に使用する。しかし、クライアントがサーバＢ１を使用していて、サーバＣ１に障害が発生するか、または利用不可能になった場合、サーバＢ１は、サーバＣ２にその要求を送信し始める。このトラフィックは、地理的にリモートにあるサイト間で流れ、追加の帯域幅が使用され、これらの要求の遅延が増加する。本記載の実施形態によるクラスタのフェイルオーバーを実行するために、たとえば、Ｃサーバの障害を別に扱うために（本明細書に記述したように）、サーバＢ１には特別なソフトウェア・ロジックが必要である。サーバＣ１の障害を検出した後、サーバＢ１は、代替サーバへの回復またはリダイレクションを開始するようにトリガーするために規定されたクライアントに応答コードを明示的に返す必要がある。たとえば、クライアントとＢ１との間のプロトコルがＳＩＰである場合、Ｂ１サーバは、リモート・サイトへのクライアントのフェイルオーバーをトリガーするために、「５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ」または「３０２ＭｏｖｅｄＴｅｍｐｏｒａｒｉｌｙ」応答を返すことができる。

様々な上記方法のステップは、プログラムされたコンピュータ（たとえば、制御モジュール１０３、１０５、１０７、１０９、または１１１）によって実行できることを当業者なら容易に理解されるであろう。本明細書において、一部の実施形態は、また、機械またはコンピュータで読取り可能、およびエンコード装置で実行可能またはコンピュータで実行可能なプログラム命令である、たとえば、デジタル・データ記憶メディアなど、プログラム記憶装置を包含することを意図するものであり、前記命令は、上記の方法のステップの一部またはすべてを実行する。プログラム記憶装置は、たとえば、デジタル・メモリ、磁気ディスクや磁気テープなどの磁気記憶メディア、ハードドライブ、または光学的に読取り可能なデジタル・データ記憶メディアなどでもよい。また、実施形態は、上記方法の前記ステップを実行するようにプログラムされたコンピュータを包含することを意図するものである。

さらに、ネットワーク要素、クライアント、またはサーバと記載された任意の機能ブロックを含む、図に示す様々な要素の機能は、専用ハードウェア、およびソフトウェアを実行することができ、適切なソフトウェアに関連するハードウェアの使用を通じて提供することができる。プロセッサによって提供される場合、機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、またはその一部を共有することができる、複数の個別のプロセッサによって提供することができる。さらに、「プロセッサ」、「コントローラ」、または「コントローラ・モジュール」という用語の明示的な使用は、ソフトウェアを実行できるハードウェアを排他的に指すものと解釈するべきではなく、デジタル・シグナル・プロセッサ（ＤＳＰ）ハードウェア、ネットワーク・プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ソフトウェアを格納するための読取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、および不揮発性記憶装置を限定することなく、暗黙的に含むことができる。従来型および／またはカスタムの他のハードウェアも含むことができる。同様に、図に示すいずれのスイッチも概念のみを示すものである。それらの機能は、プログラム・ロジックの動作を通じて、専用ロジックを通じて、プログラム制御および専用ロジックの対話を通じて、または手動でも、実行することができ、文脈からより明確に理解されるように、特定の技術を実装者が選択可能である。

上記の記述は、本発明の特定の実施形態の開示を単に提供するものであり、それに限定することを目的として意図するものではない。そのため、本発明は上記の実施形態だけに限定されない。むしろ、当業者なら本発明の範囲に入る代替実施形態を着想し得ることが認識されるであろう。

Claims

ダウンストリーム・ネットワーク要素に接続されたフロントエンド・サーバとのセッションを実行するように動作可能なクライアントと、代替ダウンストリーム・ネットワーク要素に接続された少なくとも１つの代替フロントエンド・サーバとを含んだネットワークにおけるネットワーク要素のサービス回復のための方法であって、
フロントエンド・サーバによって、ダウンストリーム・ネットワーク要素のエラーまたは利用不可能性を検出するステップと、
応答コードを前記クライアントに送信して、前記クライアントがサービスを代替フロントエンド・サーバにリダイレクトするか、または代替フロントエンド・サーバで回復するようにトリガーするステップと
を含む方法。
前記クライアントと前記フロントエンド・サーバとの間の前記セッションをサスペンドするステップをさらに含む請求項１に記載の方法。
前記検出するステップは、前記ダウンストリーム・ネットワーク要素からメッセージを受信するステップ、またはタイムアウトした応答タイマを検出するステップのうちの１つを含む請求項１に記載の方法。
ダウンストリーム・ネットワーク要素に接続されたフロントエンド・サーバとのセッションを実行するように動作可能なクライアントと、代替ダウンストリーム・ネットワーク要素に接続された少なくとも１つの代替フロントエンド・サーバとを含んだネットワークにおけるネットワーク要素のサービス回復のための方法であって、
前記フロントエンド・サーバによって、ダウンストリーム・ネットワーク要素のエラーまたは利用不可能性を検出するステップと、
要素回復またはクラスタ回復を実行するべきかどうかを決定するステップと、
要素回復が決定された場合、前記フロントエンド・サーバによって、前記障害が発生したまたは利用不可能なダウンストリーム・ネットワーク要素に対応する代替ダウンストリーム・ネットワーク要素に切り替えるステップと、
クラスタ回復が決定された場合、前記フロントエンド・サーバによって応答コードを前記クライアントに送信して、前記クライアントがサービスを代替フロントエンド・サーバにリダイレクトするか、または代替フロントエンド・サーバで回復するかをトリガーするステップと
を含む方法。
前記クライアントと前記フロントエンド・サーバとの間の前記セッションをサスペンドするステップをさらに含む請求項４に記載の方法。
前記検出するステップは、前記ダウンストリーム・ネットワーク要素からメッセージを受信するステップ、またはタイムアウトした応答タイマを検出するステップのうちの１つを含む請求項４に記載の方法。
ダウンストリーム・ネットワーク要素に接続されたフロントエンド・サーバとのセッションを実行するように動作可能なクライアントと、代替ダウンストリーム・ネットワーク要素に接続された少なくとも１つの代替フロントエンド・サーバとを含んだネットワークにおけるネットワーク要素のサービス回復のためのシステムであって、
ダウンストリーム・ネットワーク要素のエラーまたは利用不可能性を検出し、応答コードを前記クライアントに送信して、前記クライアントがサービスを代替フロントエンド・サーバにリダイレクトするか、または代替フロントエンド・サーバで回復するようにトリガーするフロントエンド・サーバの制御モジュール
を備えるシステム。
前記ダウンストリーム・ネットワーク要素からメッセージを受信すること、またはタイムアウトした応答タイマを検出することによって前記フロントエンド・サーバは、前記エラーまたは利用不可能性を検出する請求項７に記載のシステム。
ダウンストリーム・ネットワーク要素に接続されたフロントエンド・サーバとのセッションを実行するように動作可能なクライアントと、代替ダウンストリーム・ネットワーク要素に接続された少なくとも１つの代替フロントエンド・サーバとを含んだネットワークにおけるネットワーク要素のサービス回復のためのシステムであって、
ダウンストリーム・ネットワーク要素のエラーまたは利用不可能性を検出し、要素回復またはクラスタ回復を実行するべきかどうかを決定し、要素回復が決定された場合、前記フロントエンド・サーバによって、前記障害が発生したまたは利用不可能なダウンストリーム・ネットワーク要素に対応する代替ダウンストリーム・ネットワーク要素に切り替え、クラスタ回復が決定された場合、前記フロントエンド・サーバによって応答コードを前記クライアントに送信して、前記クライアントがサービスを代替フロントエンド・サーバにリダイレクトするか、または代替フロントエンド・サーバで回復するかをトリガーするフロントエンド・サーバの制御モジュール
を備えるシステム。
前記フロントエンド・サーバは、前記ダウンストリーム・ネットワーク要素からメッセージを受信すること、またはタイムアウトした応答タイマを検出することによって前記エラーまたは利用不可能性を検出する請求項９に記載のシステム。