JP2008510232A - 多数のリモートアクセスサーバにわたる処理整合性を維持する方法 - Google Patents

Abstract

リモートアクセスソリューションにおけるフェールオーバ冗長性を提供するシステムは、バックエンドサーバ上に、少なくとも１つのアプリケーションリソースを含む。該システムは、さらに、多数のゲートウェーサーバを含む。該多数のゲートウェーサーバの１つは、一次ゲートウェーサーバとして指定され、他のサーバは、フェールオーバゲートウェーサーバとして指定される。該多数のゲートウェーサーバのそれぞれは、同じアプリケーションに対して、少なくとも１つの実行中のアプリケーションインスタンスを有するセッションをホストし、該フェールオーバゲートウェーサーバ上の該セッションのそれぞれは、該一次ゲートウェーサーバ上の該セッションと同じ状態で維持される。

Description

（関連出願）
本特許出願は、米国仮特許出願第６０／６０１，４３１号（２００４年８月１３日出願、発明の名称「Ｓｙｓｔｅｍ Ａｎｄ Ｍｅｔｈｏｄ Ｆｏｒ Ａｓｓｕｒｉｎｇ Ｒｅｄｕｎｄａｎｃｙ Ｉｎ Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｓｏｌｕｔｉｏｎｓ」）の利益を主張するものである。

（発明の分野）
本発明の例示的な実施形態は、一般的にリモートアクセスサーバに関する。より特定的には、故障時にリモートアクセスソリューション内の処理整合性（ｔｒａｎｓａｃｔｉｏｎ ｉｎｔｅｇｒｉｔｙ）を維持するシステムおよび方法に関する。

（背景）
リモートアクセスソリューションによって、労働者は会社から離れても、社内ネットワークに安全にアクセスできる。ＩＰＳｅｃ ＶＰＮまたはＳＳＬ ＶＰＮを使用することで、リモートユーザは、社内ネットワークに安全な方法でアクセスできる。クライアントデバイスからのアクセスは、リモートアクセスセッションの維持に利用される１つ以上のゲートウェーサーバを介してルーティングされ得る。従来のリモートアクセスソリューションを使うと、リモートアクセスセッションを維持するゲートウェーサーバにおける故障は、セッションの終了およびデータの損失という結果を招く。

ゲートウェーサーバの故障問題に対処するために、多数の異なる従来技術が、ハードウェアまたはソフトウェアの故障の場合にも、システムリソースの冗長性および完全な利用可能性を確保しようとする試みに適用されてきた。能動／受動サーバアレンジメントにおいて、能動サーバは、多数の実行中の処理およびアプリケーションをホストする。能動サーバは、ＩＰＳｅｃ ＶＰＮベースのセッションまたはＳＳＬベースのセッションをホストし得る。１つ以上の他のサーバは、バックアップまたは「フェールオーバ（ｆａｉｌｏｖｅｒ）」サーバとして指定される。フェールオーバサーバは、能動サーバで実行中のものと同じアプリケーションおよび処理を実行する能力を含むが、フェールオーバサーバは、能動サーバに問題ありと通知されるまで、アプリケーションおよび処理を実行しない。フェールオーバサーバは、このアレンジメントにおいて「受動」サーバとして知られている。なぜなら、フェールオーバサーバは、バックアップサーバがフェールオーバモードで動作する間、能動サーバで実行中のアプリケーションおよび処理を実行するのを静かに待っていると考えられ得るからである。能動サーバに問題があると一旦通知されたら、フェールオーバサーバの１つが、新たな能動サーバとして選択され、以前の「能動」サーバから最後に保存された状態／セッション情報を受信し、以前の能動サーバが、検出された故障／問題が生じる前に実行していた方法で実行を進める。残念ながら、能動／受動アレンジメントでは、第一の能動サーバから新たに指定された能動サーバへの移行の間に、データの損失を招く結果となる。

当然のことであるが、フェールオーバサーバは、同じ物理的ノードまたは離れた物理的ノードのいずれかに位置され得る。同じ物理的ノード上にあるフェールオーバサーバを含むインプリメンテーションは、故障になる危険性を秘めている。その故障は、フェールオーバサーバにもまた影響を与える物理的ノードエレメントに関連する原因となる。離れた物理的リソース（例えば、メモリ、ディスクアレイ、マザーボードなど）を含む物理的に離れたノード上に、フェールオーバサーバを位置させると、単一の物理的エレメントが、能動サーバとフェールオーバサーバとの双方を故障させるリスクを低減するが、ハードウェアの取得と管理との双方で、システム全体のコストを増加させる。

サーバ間の冗長性を提供する別の技術は、能動／能動アレンジメントで、サーバをアレンジすることである。能動／能動アレンジメントにおいて、能動フェールオーバサーバと受動フェールオーバサーバとの双方は、アプリケーションおよび処理の同じセットを実行している。第一の能動サーバが故障すると、第二の能動サーバは、故障したサーバによって以前に取り扱われていたこれらのアプリケーションインスタンスおよび処理にリソースを割り当てる。

残念ながら、能動／受動フェールオーバサーバのアレンジメントも、能動／能動フェールオーバサーバのアレンジメントも、リモートアクセスセッションに対して、セッション状態を保存するのには役立たない。従来のフェールオーバのインプリメンテーションは、既存のセッションを終了させることなく、セッションデータを損失することなく、フェールオーバサーバを移行させ得るように、リモートセッション状態をフェールオーバサーバ内にミラー化させることができない。リモートセッションをホストする能動サーバに影響を与える故障の場合においても、既存のリモートセッションおよびそのセッションデータを保存することができることは、望ましいことである。

（概要）
本発明の例示的な実施形態によって、リモートセッション状態は、一次ゲートウェーサーバと能動フェールオーバサーバとの間を同期化させることが可能になる。クライアントデバイスから送信され、リモートセッションをホストする一次ゲートウェーサーバに入ってくるデータは、ミラーセッションをホストしている能動フェールオーバサーバに送信される。入ってくるデータの受信承認は、データのフェールオーバサーバへの分配が確認されるまで、一次ゲートウェーサーバデバイスからクライアントデバイスに送り返されない。一次ゲートウェーサーバ上のリモートセッションからのアプリケーションリソースに対するリクエストは、許可されるが、その一方で、フェールオーバサーバ上で稼動中のミラーセッションからのアプリケーションリソースに対するリクエストは、アプリケーションリソースのコンフリクトを避けるために、中断（ｉｎｔｅｒｒｕｐｔ）され、処分される。一次ゲートウェーサーバからバックエンドサーバで稼動中のアプリケーションリソースへのリクエストに応答して受信されたデータは、同様に、クライアントデバイスに送信される前に、ミラー化される。その返答は、一次ゲートウェーサーバからクライアントデバイスに転送される。その一方で、フェールオーバサーバ上で稼動中のミラーセッションから中断される。一次ゲートウェーサーバに影響を及ぼす故障の場合、ミラーセッションをホストしているフェールオーバサーバのうちの１つが、一次能動サーバとして選出される。それが許可されると、新たに選出された一次ゲートウェーは、クライアントデバイスおよびアプリケーションリソースとの通信ができるように変更される。

本発明の一局面において、リモートアクセスソリューションにおけるフェールオーバ冗長性を提供するシステムは、バックエンドサーバ上に、少なくとも１つのアプリケーションリソースを含む。該システムは、さらに、多数のゲートウェーサーバを含む。該多数のゲートウェーサーバの１つは、一次ゲートウェーサーバとして指定され、その一方で、他のサーバは、フェールオーバゲートウェーサーバとして指定される。該多数のゲートウェーサーバのそれぞれは、同じアプリケーションに対して、少なくとも１つの実行中のアプリケーションインスタンスを有するセッションをホストし、該フェールオーバゲートウェーサーバ上の該セッションのそれぞれは、該一次ゲートウェーサーバ上の該セッションと同じ状態で維持される。該一次ゲートウェーサーバは、該ゲートウェーサーバのうちで唯一、該アプリケーションリソースとの通信を許可される。該システムは、さらに、ＶＰＮネットワークを介して一次ゲートウェーサーバと通信するクライアントデバイスを含む。該クライアントデバイスは、該ＶＰＮを介して、該一次ゲートウェーサーバ上の該セッション内で実行中の該少なくとも１つのアプリケーションインスタンスの出力を受信する。該クライアントデバイスは、さらに、該ＶＰＮを介して該一次ゲートウェーサーバに入力も送信する。該受信された出力は、該クライアントデバイスによって、ビューア（ｖｉｅｗｅｒ）上に表示される。

本発明の別の局面において、リモートアクセスソリューションにおけるフェールオーバ冗長性を提供する方法は、バックエンドサーバ上に、少なくとも１つのアプリケーションリソースを提供するステップを含む。該方法は、多数のゲートウェーサーバのうちの１つを一次ゲートウェーサーバとして指定し、その一方で、他のサーバは、フェールオーバゲートウェーサーバとして指定するステップをさらに含む。該多数のゲートウェーサーバのそれぞれは、同じアプリケーションに対して、少なくとも１つの実行中のアプリケーションインスタンスを有するセッションをホストする。該一次ゲートウェーサーバは、該多数のゲートウェーサーバのうちで唯一、該少なくとも１つのアプリケーションリソースとの通信を許可される。該方法は、該フェールオーバゲートウェーサーバ上の該セッションを、該一次ゲートウェーサーバ上の該セッションと同じ状態で維持するステップをさらに含む。追加として、該方法は、ＶＰＮを介して該一次ゲートウェーサーバと通信中のクライアントデバイスで、該一次ゲートウェーサーバ上の該セッションで実行中の該少なくとも１つのアプリケーションインスタンスの出力を受信するステップを含む。該受信された出力は、該クライアントデバイスによって、ビューア上に表示される。

（詳細な説明）
本発明の例示的な実施形態は、能動一次ゲートウェーサーバから能動フェールオーバサーバにセッション状態をミラー化する能力を提供する。クライアントからの受信入力の全てと、アプリケーションリソースから受信された応答の全てとをコピーすることによって、フェールオーバセッションは、クライアントデバイスが通信中の一次ゲートウェーサーバ上のセッションと同じ状態で維持されることが可能になる。故障の場合、既存のセッションは、そのセッションを妨害することなく、データ損失を最小限として、フェールオーバサーバ（これが一次ゲートウェーサーバになる）に移行され得る。

図１は、本発明の例示的な実施形態を実行するのに適切な環境を示す。エージェント１２を含むクライアント１０は、ネットワーク２０を介して、フロントエンドサーバ３０と通信する。フロントエンドサーバ３０は、分配プロセス３２を含む。分配プロセス３２は、クライアントデバイスから受信されたデータをコピーし、一次ゲートウェーサーバ４０上の能動リモートセッション４２、ならびにフェールオーバサーバ５０、６０および７０のミラーフェールオーバセッション５２、６２および７２に分配する。それぞれの能動およびフェールオーバのセッション４２、５２、６２および７２上で稼動中のアプリケーションインスタンス４４、５４、６４および７４は、バックエンドサーバ８０によってホストされるアプリケーションリソース８２からデータをリクエストし得る。実行中のアプリケーションインスタンスのデータリクエストに対するアプリケーションリソース８２からの応答は、能動セッション４２、ならびに、フェールオーバのセッション５２、６２および７２に分配するために、フロントエンドサーバ３０の分配プロセス３２に返却される。

ここで、より詳細に図１を参照すると、クライアント１０は、リモートセッションにＩＰＳｅｃ ＶＰＮまたはＳＳＬ ＶＰＮを確立することによって、一次ゲートウェーサーバ４０上に確立されたリモートセッション（能動セッション４２）に、ネットワーク２０を介して通信中であり得る。クライアントは、バッファ１４を含み得る。このバッファ１４において、エージェント１２が、一次ゲートウェーサーバから承認を受け取るまで、一次ゲートウェーサーバ４０に送られたデータのコピーをバッファする。ネットワーク２０は、インターネット、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、エクストラネット、イントラネット、無線ネットワーク、衛星ネットワーク、あるいは、クライアント１０が一次ゲートウェーサーバ４０上の能動セッション４２と通信することを可能にする何らかの他のタイプのネットワークであり得る。一次ゲートウェーサーバ４０、ならびに、フェールオーバサーバ５０、６０および７０は、ネットワークアドレス翻訳（ＮＡＴ）テーブル４６、５６、６６および７６を含み得る。こうして、サーバは、一次ＶＰＮサーバによってリモートセッションを確立する間に、クライアント１０に割り当てられたＩＰアドレスに対するＮＡＴを実行できる。上述のように、能動セッション４２、ならびに、フェールオーバセッション５２、６２および７２は、バックエンドサーバ８０上のアプリケーションリソース８２からデータをリクエストする実行中のアプリケーションインスタンス４４、５４、６４および７４を含み得る。さらにより詳細に後述されるように、フェールオーバサーバ５０、６０および７０は、フィルタ５６、６６および７６を含む。これらのフィルタは、フェールオーバサーバがフェールオーバモードで機能している間、フェールオーバセッション５２、６２および７２からのアプリケーションリソース８２へのリクエストをフィルタ処理し、処分する。能動セッション４２内で実行中のアプリケーションインスタンス４４からのリクエストに対するアプリケーションリソース８２からの応答は、能動セッションおよびフェールオーバセッション５２、６２および７２に分配するために、分配プロセス３２にルーティングされる。分配プロセス３２の位置は、本発明の範囲内で変動し、そのプロセスが、フロントエンドサーバ上以外の異なるネットワークアクセス可能な位置に位置され、それでも本明細書に記載された機能を実行し得ることは、当業者には認識される。

さらに、図１に関して、より詳細に言及すると、多くの実施形態において、クライアント１０、フロントエンドサーバ３０、および、バックエンドサーバ８０は、カリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎまたはテキサス州のＲｏｕｎｄ ＲｏｃｋのＤｅｌｌ Ｃｏｒｐｏｒａｔｉｏｎによって製造されたようなパーソナルコンピュータまたはコンピュータサーバとして提供される。図２Ａおよび図２Ｂは、これらの実施形態において、クライアント１０、フロントエンドサーバ３０、および、バックエンドサーバ８０として有用な典型的なコンピュータ２００のブロック図を示す。図２Ａおよび図２Ｂに示すように、各コンピュータ２００は、中央演算処理装置２０２と、メインメモリユニット２０４とを含む。各コンピュータ２００は、また、１つ以上の入出力デバイス２３０ａ〜２３０ｎ（一般に、参照番号２３０で示す）と、中央演算処理装置２０２と通信中のキャッシュメモリ２４０とのような他のオプションエレメントも含み得る。

中央演算処理装置２０２は、メインメモリユニット２０４から取り出された命令に応答し、処理する任意のロジック回路網である。多数の実施形態において、中央演算処理装置は、マイクロプロセッサユニットによって提供される。例えば、８０８８、８０２８６、８０３８６、８０４８６、Ｐｅｎｔｉｕｍ（登録商標）、Ｐｅｎｔｉｕｍ（登録商標） Ｐｒｏ、Ｐｅｎｔｉｕｍ（登録商標） ＩＩ、ＣｅｌｅｒｏｎまたはＸｅｏｎプロセッサ（いずれもカリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ製）、６８０００、６８０１０、６８０２０、６８０３０、６８０４０、ＰｏｗｅｒＰＣ６０１、ＰｏｗｅｒＰＣ６０４、ＰｏｗｅｒＰＣ６０４ｅ、ＭＰＣ６０３ｅ、ＭＰＣ６０３ｅｉ、ＭＰＣ６０３ｅｖ、ＭＰＣ６０３ｒ、ＭＰＣ６０３ｐ、ＭＰＣ７４０、ＭＰＣ７４５、ＭＰＣ７５０、ＭＰＣ７５５、ＭＰＣ７４００、ＭＰＣ７４１０、ＭＰＣ７４４１、ＭＰＣ７４４５、ＭＰＣ７４４７、ＭＰＣ７４５０、ＭＰＣ７４５１、ＭＰＣ７４５５、ＭＰＣ７４５７プロセッサ（いずれもイリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐｏｒａｔｉｏｎ製）、Ｃｒｕｓｏｅ ＴＭ５８００、Ｃｒｕｓｏｅ ＴＭ５６００、Ｃｒｕｓｏｅ ＴＭ５５００、Ｃｒｕｓｏｅ ＴＭ５４００、Ｅｆｆｉｃｅｏｎ ＴＭ８６００、Ｅｆｆｉｃｅｏｎ ＴＭ８３００またはＥｆｆｉｃｅｏｎ ＴＭ８６２０プロセッサ（カリフォルニア州Ｓａｎｔａ ＣｌａｒａのＴｒａｎｓｍｅｔａ Ｃｏｒｐｏｒａｔｉｏｎ製）、ＲＳ／６０００プロセッサ、ＲＳ６４、ＲＳ６４ ＩＩ、Ｐ２ＳＣ、ＰＯＷＥＲ３、ＲＳ６４ ＩＩＩ、ＰＯＷＥＲ３−ＩＩ、ＲＳ６４ ＩＶ、ＰＯＷＥＲ４、ＰＯＷＥＲ４＋、ＰＯＷＥＲ５またはＰＯＷＥＲ６プロセッサ（いずれもニューヨーク州Ｗｈｉｔｅ ＰｌａｉｎｓのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ製）、あるいは、ＡＭＤ Ｏｐｔｅｒｏｎ、ＡＭＤ Ａｔｈａｌｏｎ ６４ＦＸ、ＡＭＤ ＡｔｈａｌｏｎまたはＡＭＤ Ｄｕｒｏｎプロセッサ（カリフォルニア州ＳｕｎｎｙｖａｌｅのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ製）である。

図２Ａに示す実施形態において、プロセッサ２０２は、システムバス２２０（詳細は後述）を介して、メインメモリ２０４と通信する。図２Ｂは、コンピュータシステム２００の実施形態を示す。ここでは、プロセッサは、メモリポートを介して、メインメモリ２０４と直接通信する。例えば、図２Ｂにおいて、メインメモリ２０４は、ＤＲＤＲＡＭであり得る。

図２Ａおよび図２Ｂは、メインプロセッサ２０２が二次バス（「バックサイドバス」とも称される）を介してキャッシュメモリ２４０と直接的に通信する実施形態を示している。他の実施形態において、メインプロセッサ２０２は、システムバス２２０を用いてキャッシュメモリ２４０と通信する。キャッシュメモリ２４０は、典型的にはメインメモリ２０４よりも速い応答時間を有し、典型的にはＳＲＡＭ、ＢＳＲＡＭ、またはＥＤＲＡＭによって提供される。

図２Ａに示す実施形態において、プロセッサ２０２は、ローカルシステムバス２２０を介して、様々な入出力デバイス２３０と通信する。様々なバスは、中央演算処理装置２０２を入出力デバイス２３０に接続するために使用され得る。これらバスには、ＶＥＳＡ ＶＬバス、ＩＳＡバス、ＥＩＳＡバス、ＭｉｃｒｏＣｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、ＰＣＩバス、ＰＣＩ−Ｘバス、ＰＣＩ−Ｅｘｐｒｅｓｓバス、またはＮｕＢｕｓを含む。入出力デバイスがビデオディスプレイである実施形態において、プロセッサ２０２は、このディスプレイと通信するために、Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）を使用し得る。図２Ｂは、コンピュータシステム２００の実施形態を示す。ここでは、メインプロセッサ２０２は、入出力デバイス２３０ｂと、ＨｙｐｅｒＴｒａｎｓｐｏｒｔ、Ｒａｐｉｄ Ｉ／ＯまたはＩｎｆｉｎｉＢａｎｄを介して、直接通信している。図２Ｂは、また、ローカルバスと直接通信の混合された実施形態を示す。すなわち、プロセッサ２０２は、ローカル相互接続バスを使用して、入出力デバイス２３０ａと通信し、その一方、入出力デバイス２３０ｂと直接通信する。

幅広い多様な入出力デバイス２３０が、コンピュータシステム２００内に存在し得る。入力デバイスは、キーボード、マウス、トラックパッド、トラックボール、マイク、および、ドローイングタブレットを含む。出力デバイスは、ビデオディスプレイ、スピーカ、インクジェットプリンタ、レーザプリンタ、および、昇華型プリンタを含む。入出力デバイスは、コンピュータシステム２００用の大容量ストレージを提供し得る。例えば、ハードディスクドライブ、３．５インチ、５．２５インチディスクまたはＺＩＰディスクのようなフロッピディスクを受けるフロッピディスクドライブ、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒ／ＲＷドライブ、ＤＶＤ−ＲＯＭドライブ、様々な形式のテープドライブ、および、ＵＳＢ Ｆｌａｓｈ ＤｒｉｖｅラインのようなＵＳＢストレージデバイス（カリフォルニア州Ｌｏｓ ＡｌａｍｉｔｏｓのＴｗｉｎｔｅｃｈ Ｉｎｄｕｓｔｒｙ，Ｉｎｃ．製）である。

さらなる実施形態において、入出力デバイス２３０は、システムバス２２０と外部通信バスとの橋渡しになり得る。例えば、ＵＳＢバス、Ａｐｐｌｅ Ｄｅｓｋｔｏｐ Ｂｕｓ、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅバス、ＦｉｒｅＷｉｒｅ ８００バス、Ｅｔｈｅｒｎｅｔ（登録商標）バス、ＡｐｐｌｅＴａｌｋバス、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）バス、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅバス、ＨＩＰＰＩバス、Ｓｕｐｅｒ ＨＩＰＰＩバス、ＳｅｒｉａｌＰｌｕｓバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌバス、または、Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ小型コンピュータシステムインターフェースバスである。

図２Ａおよび図２Ｂに示すような汎用デスクトップコンピュータは、典型的には、オペレーティングシステムの制御下で動作し、このオペレーティングシステムが、タスクのスケジューリングおよびシステムリソースへのアクセスを管理する。典型的なオペレーティングシステムには、とりわけ、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）（ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐ．製）、ＭａｃＯＳ（カリフォルニア州ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ製）、ＯＳ／２（ニューヨーク州ＡｒｍｏｎｋのＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ製）、および、Ｌｉｎｕｘ（ユタ州Ｓａｌｔ Ｌａｋｅ ＣｉｔｙのＣａｌｄｅｒａ Ｃｏｒｐ．より無料で頒布されているオペレーティングシステム）がある。

クライアント１０が、移動体デバイスである実施形態において、クライアントは、ＪＡＶＡ（登録商標）対応の携帯電話であり得る。例えば、ｉ５０ｓｘ、ｉ５５ｓｒ、ｉ５８ｓｒ、ｉ８５ｓ、ｉ８８ｓ、ｉ９０ｃ、ｉ９５ｃ１またはｉｍ１１０００（いずれもイリノイ州ＳｃｈａｕｍｂｕｒｇのＭｏｔｏｒｏｌａ Ｃｏｒｐ．製）、６０３５または７１３５（日本国京都府の京セラ製）、あるいは、ｉ３００またはｉ３３０（韓国ソウルのＳａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ．製）である。クライアント１０が、移動体である他の実施形態において、ＰａｌｍＯＳのオペレーティングシステムの制御下で動作する携帯情報端末（ＰＤＡ）であり得る。例えば、Ｔｕｎｇｓｔｅｎ Ｗ、ＶＩＩ、Ｖｌｌｘ、ｉ７０５（いずれもカリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．製）である。さらなる実施形態において、クライアントデバイス２０は、ＰｏｃｋｅｔＰＣオペレーティングシステムの制御下で動作する携帯情報端末（ＰＤＡ）であり得る。例えば、ｉＰＡＱ ４１５５、ｉＰＡＱ ５５５５、ｉＰＡＱ １９４５、ｉＰＡＱ ２２１５およびｉＰＡＱ ４２５５（いずれもカリフォルニア州Ｐａｌｏ ＡｌｔｏのＨｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｒｐｏｒａｔｉｏｎ製）、ＶｉｅｗＳｏｎｉｃ Ｖ３６（カリフォルニア州ＷａｌｎｕｔのＶｉｅｗＳｏｎｉｃ製）、あるいは、Ｔｏｓｈｉｂａ ＰｏｃｋｅｔＰＣ ｅ４０５（ニューヨーク州Ｎｅｗ ＹｏｒｋのＴｏｓｈｉｂａ Ａｍｅｒｉｃａ，Ｉｎｃ．製）である。さらなる他の実施形態において、クライアントデバイスは、ＰＤＡ／電話デバイスの組み合わせであり得る。例えば、Ｔｒｅｏ １８０、Ｔｒｅｏ ２７０またはＴｒｅｏ ６００（いずれもカリフォルニア州ＭｉｌｐｉｔａｓのｐａｌｍＯｎｅ，Ｉｎｃ．製）である。またさらなる実施形態において、クライアントデバイス２０は、ＰｏｃｋｅｔＰＣオペレーティングシステムの制御下で動作する携帯電話である。例えば、ＭＰｘ２００（Ｍｏｔｏｒｏｌａ Ｃｏｒｐ．製）である。

図１に展開されたアーキテクチャで示されたコンポーネントによって実行される機能は、図３を参照して、さらに説明され得る。図３は、一次ゲートウェーサーバ上の能動セッションに向けられたデータを、フェールオーバサーバのフェールオーバセッションにミラー化する本発明に従う一連のステップの流れ図である。（クライアント１０の認証後）一次ゲートウェーサーバ４０上の初期リモート能動セッション４２の確立、ならびに、フェールオーバサーバ５０、６０および７０上の対応するフェールオーバセッション５２、６２および７２の確立に続き、フロントエンドサーバ３０は、能動セッションに向けられたクライアントからの入力を受信する（ステップ３００）。フロントエンドサーバ３０上の分配プロセス３２は、入力データをコピーし、それらを能動セッション４２ならびにフェールオーバサーバ５２、６２および７２へ分配する（ステップ３０２）。能動セッション４２ならびにフェールオーバセッション５２、６２および７２内のアプリケーションインスタンスは、次いで、受信データを処理する（ステップ３０４）。

分配プロセス３２は、次いで、能動およびフェールオーバセッション４２、５２、６２および７２をクエリし、セッション状態が同期しているかどうかを判断する（ステップ３０６）。同期を確認することが必要なのは、サーバ間での処理速度の変動およびネットワークでの待ち時間遅延が考えられるからである。代替のインプリメンテーションにおいて、一次ゲートウェーサーバ４０およびフェールオーバサーバ４０、５０および６０は、最初にクエリすることなく、分配プロセス３２にそのセッション状態を報告するように構成される。別のインプリメンテーションにおいて、分配プロセス以外の異なるプロセスが、セッション４２、５２、６２および７２の状態の同期を確認する役割を担う。セッション状態が同期していないと判断された場合（ステップ３０７）、遅延が、同期状態を判断する分配プロセスからのさらなるクエリをペンディングしたままインプリメントされ得る（ステップ３０６）。セッション状態が同期していると判断された場合（ステップ３０７）、一次ゲートウェーサーバ４０上の能動セッション４２内のアプリケーションインスタンス４４によって実行される処理の結果が、クライアントに報告される（ステップ３０８）。フェールオーバセッション５２、６２および７２内のアプリケーションインスタンスによる試みは、ネットワークスタック上のそれぞれのフィルタ４６、５６および６６によって、フィルタ処理され、パケットは処分される。

同様のプロセスが、アプリケーションリソースに対するセッションで実行中のアプリケーションインスタンスによるリクエストの間、能動およびフェールオーバセッション状態を同期化して保つために実行される。図４は、アプリケーションリソースからのデータをリクエストし、その応答をフェールオーバセッションにミラー化する本発明の例示的な実施形態に従う一連のステップの流れ図である。シーケンスは、能動セッション４２内のアプリケーションインスタンス４４（ならびに、フェールオーバセッション５２、６２および７２内で対応するアプリケーションインスタンス５４、６４および７４）が、必要とされるアプリケーションリソースを同定するときに開始する（ステップ３２０）。セッションの全てからのアプリケーションインスタンス４４、５４、６４および７４は、次いで、バックエンドサーバ８０からのアプリケーションリソース８２をリクエストする（ステップ３２２）。フェールオーバセッション５２、６２および７２内のアプリケーションインスタンス５４、６４および７４から生じるリクエストは、それぞれのフェールオーバサーバ５０、６０および７０のネットワークスタック上のフィルタ５８、６８および７８によって、フィルタ処理される。フィルタ処理されたパケットは、処分される（ステップ３２４）。能動サーバ４２からのリクエストは、バックエンドサーバ８０上のアプリケーションリソース８２に転送される（ステップ３２６）。リクエストに対する応答は、フロントエンドサーバ上の分配プロセス３２にルーティングされる（ステップ３２８）。一つのインプリメンテーションにおいて、応答は、能動セッション４２を最初はホストしている一次ゲートウェーサーバ４０に送信され、分配プロセス３２に転送される。別のインプリメンテーションにおいて、クライアントから入力データを受け入れるために使用されたものとは異なる別個の分配プロセスは、アプリケーションリソース応答を分配するために使用され得る。

図４を続けると、アプリケーションリソースからの応答の受信に続き、分配プロセスは、応答データを能動およびフェールオーバセッション４２、５２、６２および７２に転送する（ステップ３３０）。能動セッション４２ならびにフェールオーバサーバ５２、６２および７２内のアプリケーションインスタンス４４、５４、６４および７４は、次いで、リソースデータを処理する（ステップ３３２）。クライアントから受信したデータと同様に、クエリは、そのセッション状態が同期しているかどうかを判断するように作成される（ステップ３３３）。その状態が、同期している場合、クエリは、肯定的な回答が受信されるまで繰り返される。セッション状態が、一旦同期すると、能動セッション４２中のアプリケーションインスタンスは、クライアント１０にそのデータ処理の結果を通信する。フェールオーバサーバ上のアプリケーションインスタンス５４、６４および７４は、クライアント１０にその結果を通信しようと試みるが、パケットは、それぞれのフェールオーバサーバ５０、６０および７０上のネットワークフィルタ５８、６８および７８によって、中断され、処分される（ステップ３３４）。

例示的な実施形態の別の局面において、本発明は、また、「シンクライアント」またはキオスクのアーキテクチャでもインプリメントされ得る。ここで、処理の全ては、サーバ上で行われ、スクリーンデータのみが、リモートセッション４２からクライアント１０に、押し出される。図５は、アプリケーションスクリーンバッファが、シンクライアントまたはキオスクによってリクエストされたリモートセッションに対して、同期し続けるように保つ代替的な実施形態を示す。クライアント４００は、ＰＤＡまたは携帯電話のような限られた処理能力を有するシンクライアントであり得るか、あるいは、ディスプレイおよび入力デバイスを備えた公衆に利用可能なキオスク端末であり得る。クライアントは、ネットワーク４０２を介して、一次ゲートウェーサーバ４１０にリモートセッションを確立する。この接続は、ＲＤＰ（リモートディスプレイプロトコル）（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）、またはＩＣＡ（フロリダ州ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．）であり得る。セッションは、クライアント４００が、一次ゲートウェーサーバに出された安全なウェブＵＲＬを介してログインするときに確立され得る。一次ゲートウェーサーバは、接続リクエストを受け入れ、リモート能動セッション４１２を確立する。例示的な実施形態は、また、フェールオーバサーバ４２０および４３０上のフェールオーバセッション４２２および４３２も確立する。能動セッション４１２、ならびに、フェールオーバセッション４２２および４３２は、同様に取得され、それぞれ実行中のアプリケーションインスタンス４１４、４２４および４３４を含む。アプリケーションインスタンスのそれぞれは、関連スクリーンバッファ４１６、４２６および４３６をそれぞれ有する。一次ゲートウェーサーバ上の分配プロセス４１８は、上述した方法で、クライアント４００から受信した入力データをコピーし、セッション４１２、４２２および４３２のそれぞれに分配する。代替のインプリメンテーションにおいて、分配プロセス４１８は、フロントエンドサーバ上に位置され得る。アプリケーションインスタンス４１４、４２４および４３４は、一次ゲートウェーサーバからのリクエストが送信され、フェールオーバサーバ４２０および４３０からのリクエストが中断および処分されるようにと、アプリケーションリソース４４２をバックエンドサーバ４４０からリクエストし得る。以前のように、実行中のアプリケーションインスタンス４１４、４２４および４３４によって実行される処理に引き続き、クライアント４００への応答は、スクリーンバッファ４１６、４２６および４３６の全てが同じ状態になるまで、遅延される。一次ゲートウェーサーバ上のスクリーンバッファ４１６のコンテンツ（または、最適化技術を使用したときは、変更されたコンテンツ）は、次いで、クライアント４００への接続を介して押し出される。アプリケーションインスタンス４２４および４３４による自身のスクリーンバッファ４２６および４３６のコンテンツをクライアント４００に押し出す試みは、中断され、パケットは処分される。

本発明によって実行されるセッション状態の同期は、リモートセッションを、故障したゲートウェーサーバから交換ゲートウェーサーバへと、リモートセッションを終了させることなく、移行することを可能にし、データ損失の最小化も確保する。エージェント１２は、クライアント１０から送信されたデータのコピーをバッファする（ＴＣＰのような信頼性高いプロトコルが使用された場合）。本発明は、セッション状態の全てが同期化されるまで、クライアントからのデータの受信の承認を返却しない。それゆえ、エージェント１０は、承認が一次ゲートウェーサーバから受信され、次いで、データを処分するまで、任意の送信済みデータのコピーをバッファする。一次ゲートウェーサーバ４０が引き続いて任意の故障となったイベントにおいて、クライアントによって一次ゲートウェーサーバに送信されたデータは、フェールオーバセッションのうちの１つに存在する。同様に、アプリケーションリソースから受信されたデータも、また、それらが同期化されたままであるように、能動セッションとフェールオーバセッションとの双方に分配される。承認が、一次ゲートウェーサーバから受信されない場合、バッファ付きデータは、新たに指定された一次ゲートウェーサーバに再送される。

さらに、リモート接続が、最初に確立されたとき、クライアント１０に割り当てられたＩＰアドレスは、一次ゲートウェーサーバ４０に単に分配されるだけではない。一つのインプリメンテーションにおいて、クライアントに対してのみならず、フェールオーバサーバ５０、６０および７０に対して、ＮＡＴを実行する。一次ゲートウェーサーバ４０の故障が検出されたとき、フェールオーバサーバ５０、６０および７０のうちの１つが、一次ゲートウェーサーバとして選択され、その属性が変更され、その役割を担うことが可能になる。ネットワークスタック上に存在し、フェールオーバサーバ５０、６０および７０がクライアント１０およびアプリケーションリソース８２と通信することを妨げるフィルタ５８、６８および７８は、新たに指定された一次ゲートウェーサーバに対して無効にされる。新たに選択された一次ゲートウェーサーバは、また、以前に送信されたＩＰアドレスおよび新たに選択された一時ゲートウェー上のＮＡＴテーブル５８、６８または７８を用いて、クライアントから受信された通信またはクライアントへ向けた通信のうちの任意の通信を中断する。一次ゲートウェーサーバが故障する前に、フェールオーバサーバによってミラー化セッション状態とクライアントＩＰとの組み合わせに気付くために、新たなリモートセッションを再確立することなく、最小限のデータ損失でスムーズな移行を行うことができる。

一次ゲートウェーサーバ４０の故障の検出は、幾つかの異なる方法で行われ得る。サーバの故障を検出するために使用される方法は、サーバが配備される方法に左右される。例えば、一次サーバおよびゲートウェーサーバは、クラスター型コンピュータシステム内のノードとして配置され得る。クラスター型コンピュータシステムにおけるノードは、民間通信チャネルを介して、互いに「心拍」信号（「応答」または「活性化」信号とも称される）を送信することが多い。心拍信号／トークンは、ノードが活性であるかどうか、クラスター型コンピュータシステム内の他のノードに応答するかどうかを示す。心拍信号は、ノードのそれぞれによって周期的に送信される。それは、１つ以上のノードが、特定の期間内に他のノードから心拍信号を受信しない場合、ノード故障が疑われ得るようにするためである。

ゲートウェーサーバ故障の最終決断は、ゲートウェーサーバを制御するフェールオーバ方針によって決定され得る。フェールオーバ方針は、どのような状況下で、一次ゲートウェーサーバが故障したと考えられ得るかを指示する。例えば、上述のクラスター型コンピュータシステムで、多数のフェールオーバサーバを有するインプリメンテーションにおいて、方針は、少なくとも２つのフェールオーバサーバが、特定の期間内に一次ゲートウェーサーバから心拍トークンを受信しなかったということを要求し得る。代替として、フェールオーバ方針は、全てのフェールオーバノードが、一次ゲートウェーサーバから心拍トークンを受信しなかったということを要求し得る。一次ゲートウェーサーバをピンギング（ｐｉｎｇｉｎｇ）して、その健康状態を判断することなど、幾つかの他の技術も、ゲートウェーサーバの故障を検出するために単独で、あるいは、組み合わせて使用され得ることは、当業者は認識できる。ピンギングは、一次ゲートウェーサーバの故障を検証するために、心拍トークンの受信欠落をフォローすることによって実行され得る。

一次ゲートウェーサーバの故障が一旦検出されると、新たな一次ゲートウェーサーバをフェールオーバサーバから選択する幾つかの異なる方法が、使用され得る。サーバは、名前に基づいて、あるいは、サーバ識別子で実行される数学的操作を介して、選択され得る。代替として、選択は、サーバ処理属性（速度、メモリなど）に基づき得るし、あるいは、次の一次ゲートウェーサーバが、システム管理人によって以前に指定されていることもあり得る。当業者なら、他の可能性も思い浮かぶ。

図６は、一次ゲートウェーサーバ内の故障を検出に対処する本発明に従う一連のステップを示す。このシーケンスは、一次およびフェールオーバゲートウェーサーバが指定されることで開始する（ステップ５００）。フェールオーバサーバの指定は、これらサーバのネットワークスタック上のフィルタを活性化し、ＮＡＴテーブルを無効にする。リモートセッションが確立されると、ＩＰアドレスは、クライアントに割り当てられ、フェールオーバサーバに転送される。一次ゲートウェーサーバは、次いで、その健康状態を判断するために、クエリされる（ステップ５０２）。一次ゲートウェーサーバが、健康であると判断されたら（ステップ５０３）、クエリは、設定された間隔で繰り返される。一次ゲートウェーサーバは、健康でないと判断されたら（ステップ５０３）、新たな一次ゲートウェーサーバが、フェールオーバサーバの中から選択され、その属性は、そのフィルタが無効になるように変更され、クライアントＩＰへ／からの通信を処理し、サーバ上のＮＡＴテーブルは活性化される（ステップ５０４）。

本発明は、製品の１つ以上の品目に具現化された１つ以上のコンピュータ可読プログラムとして提供され得る。製品の品目は、フロッピディスク、ハードディスク、コンパクトディスク、デジタル汎用ディスク、フラッシュメモリカード、ＰＲＯＭ、ＲＡＭ、ＲＯＭまたは磁気テープであり得る。一般に、コンピュータ可読プログラムは、任意のプログラミング言語でインプリメントされ得る。使用され得る言語の例の一部は、Ｃ、Ｃ＋＋、Ｃ＃またはＪＡＶＡ（登録商標）であり得る。ソフトウェアプログラムは、オブジェクトコードとして、製品の１つ以上の品目上または品目内に格納され得る。

特定の変更は、本発明の精神と範囲から逸脱しない範囲で行われ得るので、上記の記載に含まれ、添付図面に示された全ての事項は、例示的なものとして解釈されるべきで、文字通りの意味で解釈されないことが意図される。本明細書に図示され、記載されたシステム構成は、本発明の範囲内に収まる多数の可能性あるシステム構成の中の例であることは、当業者なら認識する。同様に、例示的な流れ図で利用された一連のステップは、例であって、本発明の範囲内で可能な一連のステップを網羅するものではない。同様に、本明細書で述べたデータ構造以外のデータ構造も、本発明の範囲から逸脱することなく、データを保持するために使用され得る。

本発明は、添付の請求項における特徴によって指摘される。上述の本発明の利点、ならびに、本発明のさらなる利点は、以下の記述を添付図面とともに参照することによって、より容易に理解され得る。
図１は、多数のゲートウェーサーバの前にあるフロントエンドサーバを利用する本発明の例示的な実施形態を実行するのに適切な環境を示す。 図２Ａは、本発明で有用な典型的なコンピュータのブロック図である。 図２Ｂは、プロセッサがメモリポートを介してメインメモリと直接通信するコンピュータシステムの実施形態を示す。 図３は、一次ゲートウェーサーバ上の能動セッションに向けられたデータを、フェールオーバサーバのフェールオーバセッションにミラー化する本発明の例示的な実施形態に従う一連のステップの流れ図である。 図４は、アプリケーションリソースからのデータをリクエストし、その応答をフェールオーバセッションにミラー化する本発明の例示的な実施形態に従う一連のステップの流れ図である。 図５は、アプリケーションスクリーンバッファが、シンクライアントまたはキオスクによってリクエストされたリモートセッションに対して、同期し続けるように保たれる代替的な実施形態を示す。 図６は、一次ゲートウェーサーバ内の故障を検出し、フェールオーバサーバから選択された新たな一次ゲートウェーサーバに移行する本発明の例示的な実施形態に従う一連のステップの流れ図である。

Claims (22)

1. リモートアクセスソリューションにおけるフェールオーバ冗長性を提供するシステムであって、
   バックエンドサーバ上の少なくとも１つのアプリケーションリソースと、
   複数のゲートウェーサーバであって、該複数のゲートウェーサーバの１つは、一次ゲートウェーサーバとして指定され、それとともに該複数のゲートウェーサーバの他のサーバは、フェールオーバゲートウェーサーバとして指定され、該複数のゲートウェーサーバのそれぞれは、同じアプリケーションに対して、少なくとも１つの実行中のアプリケーションインスタンスを有するセッションをホストし、該フェールオーバゲートウェーサーバ上の該セッションのそれぞれは、該一次ゲートウェーサーバ上の該セッションと同じ状態で維持され、該一次ゲートウェーサーバは、該複数のゲートウェーサーバのうちで唯一、該少なくとも１つのアプリケーションリソースとの通信を許可される、複数のゲートウェーサーバと、
   ＶＰＮを介して、該一次ゲートウェーサーバと通信するクライアントデバイスであって、該クライアントデバイスは、該ＶＰＮを介して、該一次ゲートウェーサーバ上の該セッション内で実行中の該少なくとも１つのアプリケーションインスタンスの出力を受信し、該ＶＰＮを介して該一次ゲートウェーサーバに入力を送信する、クライアントデバイスと
   を備え、
   該受信された出力は、該クライアントデバイスによって、ビューア上に表示される、システム。
2. 前記フェールオーバゲートウェーサーバのそれぞれに、フィルタをさらに備え、
   該フェールオーバゲートウェーサーバ上の各セッション内で前記実行中のアプリケーションインスタンスによって送信され、前記少なくとも１つのアプリケーションリソースにアドレスされたパケットは、中断および処分される、請求項１に記載のシステム。
3. 前記ＶＰＮを介して、前記クライアントデバイスから前記一次ゲートウェーサーバ上の前記セッションによって受信された前記入力は、前記フェールオーバゲートウェーサーバ上の前記セッションのそれぞれの中で、前記実行中のアプリケーションインスタンスのそれぞれにリレーされる、請求項１に記載のシステム。
4. 前記一次ゲートウェーサーバ上の前記セッション内で前記実行中のアプリケーションインスタンスは、前記少なくとも１つのアプリケーションリソースに対するリクエストへの返答を受信し、該返答は、複製され、各フェールオーバゲートウェーサーバ上の各セッションに転送される、請求項１に記載のシステム。
5. 前記一次ゲートウェーサーバは、前記フェールオーバゲートウェーサーバのそれぞれにおけるセッションが、該一次ゲートウェーサーバと同期化するまで、前記クライアントデバイスへのデータの送信を遅延させる、請求項１に記載のシステム。
6. 前記クライアントデバイスおよび前記一次ゲートウェーサーバは、該クライアントデバイスに割り当てられるＩＰアドレスに対し、ネットワークアドレス翻訳（ＮＡＴ）を実行する、請求項１に記載のシステム。
7. 前記フェールオーバサーバのうちの選択された１つは、故障した一次ゲートウェーサーバと置換するために選択される、請求項６に記載のシステム。
8. 前記故障した一次ゲートウェーサーバと置換するために選択された前記フェールオーバゲートウェーサーバのうちの前記選択された１つは、該故障した一次ゲートウェーサーバに代わって、前記クライアントデバイスＩＰに対し、前記ＮＡＴを実行する、請求項７に記載のシステム。
9. 前記複数のゲートウェーサーバ上の各実行中のアプリケーションインスタンスに対する関連スクリーンバッファをさらに備え、
   該フェールオーバゲートウェーサーバ上の該実行中のアプリケーションインスタンスと関連する該スクリーンバッファは、前記一次ゲートウェーサーバ上の前記実行中のアプリケーションインスタンスに対するスクリーンバッファと、同じ状態で維持される、請求項７に記載のシステム。
10. 前記一次ゲートウェーサーバ上の前記スクリーンバッファ内のコンテンツのコピーは、表示のために、前記クライアントデバイスに転送される、請求項９に記載のシステム。
11. リモートアクセスソリューションにおけるフェールオーバ冗長性を提供する方法であって、
    バックエンドサーバ上に、少なくとも１つのアプリケーションリソースを提供することと、
    複数のゲートウェーサーバのうちの１つを一次ゲートウェーサーバとして指定することであって、該複数のゲートウェーサーバの他のサーバは、フェールオーバゲートウェーサーバとして指定され、該複数のゲートウェーサーバのそれぞれは、同じアプリケーションに対して、少なくとも１つの実行中のアプリケーションインスタンスを有するセッションをホストし、該一次ゲートウェーサーバは、該複数のゲートウェーサーバのうちで唯一、該少なくとも１つのアプリケーションリソースとの通信を許可される、ことと、
    該フェールオーバゲートウェーサーバ上の該セッションを、該一次ゲートウェーサーバ上の該セッションと同じ状態で維持することと、
    ＶＰＮを介して、該一次ゲートウェーサーバと通信中のクライアントデバイスで、該一次ゲートウェーサーバ上の該セッションで実行中の該少なくとも１つのアプリケーションインスタンスの出力を受信することであって、該受信された出力は、該クライアントデバイスによって、ビューア上に表示される、ことと
    を包含する、方法。
12. 前記ＶＰＮを介して前記クライアントデバイスから、前記一次ゲートウェーサーバ上の前記セッションで前記実行中のアプリケーションインスタンスに入力を送信することと、
    該受信された入力をコピーし、該コピーされた入力を前記フェールオーバゲートウェーサーバ上のセッション内で実行中のアプリケーションインスタンスのそれぞれに転送することであって、これによって、該フェールオーバゲートウェーサーバ内の該セッションが、該一次ゲートウェーサーバ上のセッションと同じ状態であることが維持される、ことと
    をさらに包含する、請求項１１に記載の方法。
13. 前記一次ゲートウェーサーバ上の前記セッションで実行中のアプリケーションインスタンスから、リクエストを前記バックエンドサーバ上の前記アプリケーションリソースに送信することと、
    該リクエストに対する返答を、前記一次ゲートウェーサーバで前記アプリケーションリソースから送信することと、
    該返答を該一次ゲートウェーサーバでコピーし、該コピーした返答を前記フェールオーバゲートウェーサーバ上で前記実行中のインスタンスに転送することと
    をさらに包含する、請求項１１に記載の方法。
14. 前記フェールオーバゲートウェーサーバ上で前記実行中のアプリケーションインスタンスから、リクエストを前記バックエンドサーバ上の前記アプリケーションリソースに送信することと、
    該リクエストを該フェールオーバゲートウェーサーバのそれぞれの上で中断することと、
    該リクエストを該アプリケーションリソースに転送することなく、処分することと
    をさらに包含する、請求項１１に記載の方法。
15. 前記一次ゲートウェーサーバは、リモートフレームバッファ（ＲＦＢ）プロトコルを使用して、該一次ゲートウェーサーバ上の前記少なくとも１つのアプリケーションインスタンスと関連するスクリーンバッファにおける変化を、前記クライアントデバイスに送信する、請求項１１に記載の方法。
16. 前記一次ゲートウェーサーバは、リモートディスプレイプロトコル（ＲＤＰ）を使用して、該一次ゲートウェーサーバ上の前記少なくとも１つのアプリケーションインスタンスと関連するスクリーンバッファにおける変化を、前記クライアントデバイスに送信する、請求項１１に記載の方法。
17. 前記一次ゲートウェーサーバは、ＩＣＡ接続を使用して、該一次ゲートウェーサーバ上の前記少なくとも１つのアプリケーションインスタンスと関連するスクリーンバッファにおける変化を、前記クライアントデバイスに送信する、請求項１１に記載の方法。
18. 前記一次ゲートウェーサーバの故障を検出することと、
    新たな一次ゲートウェーサーバとして指定されたフェールオーバサーバを選択することであって、該新たな一次ゲートウェーサーバは、該選択に引き続き、前記少なくとも１つのアプリケーションリソースと通信することが可能である、ことと
    をさらに包含する、請求項１１に記載の方法。
19. 心拍トークンプロトコルを使用して、前記一次ゲートウェーサーバの前記故障を検出することをさらに包含する、請求項１８に記載の方法。
20. 所定の間隔で、前記一次ゲートウェーサーバをピンジングすることによって、前記一次ゲートウェーサーバの前記故障を検出することをさらに包含する、請求項１８に記載の方法。
21. 前記クライアントデバイスに割り当てられたＩＰアドレスに対し、前記一次ゲートウェーサーバで、ネットワークアドレス翻訳（ＮＡＴ）を実行することをさらに包含する、請求項１１に記載の方法。
22. 前記クライアントデバイスに割り当てられた前記ＩＰアドレスに対し、新たな一次ゲートウェーサーバで、ネットワークアドレス翻訳（ＮＡＴ）を実行することをさらに包含する、請求項２１に記載の方法。

Images