JP2004536406A - セッション複製及びフェイルオーバーのための方法及び装置 - Google Patents

Abstract

本発明によるシステムは、ウェブブラウザーのようなネットワーククライアントからの要求に応じるために、一次サーバーを利用することができる。この一次サーバーは、一団のサーバー又はサーバー群から選ばれることができる。一次サーバーが選択されると、その一次サーバー上でクライアント要求に応じることができる。次に二次セッションサーバーが、例えば一次サーバーによって、選択されることができる。一次サーバーが要求に応答すると、そのセッションに関する情報が、一次サーバーから二次セッションサーバーへ送られる。
また、システムは、ハードウェア又はソフトウェアの何れかを使って、負荷平衡化を利用することができる。一次サーバー上で要求に応じようとする試みがなされ、もし、一次サーバーが要求を受け取る、又は要求に応答することができない場合には、その要求は二次アプリケーションサーバー上で応じられることができる。もし、二次サーバーが要求を受け取るならば、その二次サーバーが新たな一次サーバーとなる。冗長性を維持するため、新たな二次サーバーが選択され、かつ、その新しい一次サーバーからセッション情報を送られることができる。

Description

【技術分野】
【０００１】
本出願は、一般的に、データ複製、特にクライアントネットワークセッションへの冗長性の提供に関するものである。
【０００２】
(優先権の主張)
本出願は、引用により本出願中に組み入れられる2001年7月16日に出願された「サーブレットセッション複製及びフェイルオーバーのための方法及び装置」という名称の米国仮特許出願60/305,992号、2001年10月31日に出願された「セッション複製及びフェイルオーバーのための方法及び装置」という名称の米国特許出願10/000,708号、2001年7月16日に出願された「サーブレットセッション複製のためのハードウェアの負荷を均衡化する装置」という名称の米国仮特許出願60/305,969号、2001年10月31日に出願された「セッション複製のためのハードウェアの負荷を均衡化する装置」という名称の米国特許出願10/000,709号、に基づく優先権を主張するものである。
【０００３】
（著作権表示）
本特許文書の開示の一部には、著作権保護を条件とする題材が含まれている。本特許文書又は特許開示が、特許局及び商標局の特許書類又は記録に掲載される限りでは、何人によるその複製に対しても著作権者に異議はないが、しかしそうでないならば、一切の無断転載を禁ずる。
【背景技術】
【０００４】
クライアントがネットワーク上でサーバーに接続し、かつセッションを開始する時、サーバー上に格納される、そのクライアントセッションに特有な情報が存在し得る。例えば、クライアントのユーザーが仮想買い物かごに品物を入れるとする。それら品物の選択物は、少なくとも一時的にサーバー上に格納されることができる。この例では、他のユーザー又はサーバーはこの情報にアクセスする必要はない。しかしながら、もしセッションデータを格納するサーバーが故障した場合に他のサーバー上のデータを回収することが可能となるように、このデータがネットワーク又はサーバー群全体に渡って大いに利用可能であることが望ましい。
【０００５】
そのような状況におけるデータ復旧を遂行するための一つの方法は、セッションの間、データベース内に情報を格納することであるが、とはいえ、データファイルのような他の手段により格納することもできるかもしれない。データベースへのアクセス権を有するあらゆるサーバーがそのデータにアクセスできるように、セッションデータに変更がなされる度に、最新情報がデータベースに書き込まれる。データは永続的な場所に格納され、かつ他のサーバーにより容易に検索されることができる。
【０００６】
しかしながら、各要求に対してデータベースからセッション情報を取り出すことは相当にコストがかかるという点で、この手法には問題がある。システムのスループットは、サーバーからのデータベースへの接続数に依存することができるため、データベースへの複数の該当は、障害を生み出し、かつ基本的に動作不能な点となるシステムダウンにはまり込ませ得る。また、これらのセッションは情報の形式を含むこともでき、ユーザーはこれにすぐアクセスしたい。いくつかのアプリケーションと共に、何千ものクライアントが同時に動作することが可能であり、それは何千もの並列実行セッションという結果となる。いくつかのサーバーは多くの異なるアプリケーションのホストとして動作することが望まれ、それは更に、それらサーバーをホストとする必要のあり得るセッション数を増やすこととなる。
【０００７】
これら何万ものユーザーがシステムを効果的に使用できるように、そのようなシステムの速度及び効率を高めることが望まれる。そのような障害を避けるための一つの方法は、サーバーが99.9%の時間立ち上がって稼動中であり、かつ、単純に如何なる情報のバックアップもとらないことを想定するものである。これは、最速のユーザー体験を提供するという解決策となり得るが、しかし、データ損失という結果となる0.1%の動作不能時間でさえも、多くのユーザーには容認されないものである。
【０００８】
(要約)
本発明によるシステムは、ウェブブラウザーのようなネットワーククライアントからの要求に応じるために、一次サーバーを利用することができる。この一次サーバーは、一団のサーバー又はサーバー群から選ばれることができる。一次サーバーが選択されると、その一次サーバー上でクライアント要求に応じることができる。次に二次セッションサーバーが、例えば一次サーバーによって、選択されることができる。一次サーバーが要求に応答すると、そのセッションに関する情報が、一次サーバーから二次セッションサーバーへ送られる。これは、セッション上の最初の要求における完全な一連の情報とすることができる、又はただ単に、後に続く要求に応じたセッション中の既存情報への更新とすることもできる。一次及び二次サーバーを特定する情報は、例えばクッキーとして格納される「トークン」のように、クライアント上に格納されることができ、又はトランザクション若しくはセキュリティ状況と同様な手法で標準RMIの最上位に渡されることができる。この識別情報又は「トークン」は、各要求に伴うことができる。
【０００９】
システムは、ハードウェア又はソフトウェアの何れかを使って、負荷平衡化を利用することができる。ソフトウェア平衡化を伴って有用となる処理では、既に一次及び二次セッションサーバーが選択されたセッション上で、要求が受け取られることができる。一次サーバー上で要求に応じようとする試みがなされる。もし、一次サーバーが要求を受け取る、又は要求に応答することができない場合には、その要求は二次アプリケーションサーバー上で応じられることができる。もし、二次サーバーが要求を受け取るならば、その二次サーバーが新たな一次サーバーとなる。冗長性を維持するため、新たな二次サーバーが選択され、かつ、その新しい一次サーバーからセッション情報を送られることができる。
【００１０】
ハードウェア負荷平衡器を伴って有用となる処理では、一次及び二次セッションサーバーが選択されたセッション上で、要求が受け取られる。次に、一次サーバー上で要求に応じようとする試みがなされる。もし、一次サーバーが要求を受け取る、又は要求に応答することができない場合には、二次セッションサーバーを使用するのではなく、ハードウェア負荷平衡器は新たな一次サーバーを選択し、かつ、その新たな一次サーバー上でその要求に応じようと試みることができる。セッション情報は、例えば新しい一次サーバーからの要求に応じて、二次セッションサーバーから新しい一次サーバーに送られることができる。次に、新しい一次サーバーは要求に応答し、かつ更新されたセッション情報を二次サーバーへ送ることができ、その結果、そのセッションについてサーバーが同期することとなる。
【００１１】
(発明の詳細な説明)
本発明は、従来の複製システムの不備の多くを克服する。本発明のある実施形態による一つのシステムでは、クライアントがLAN、イーサーネット(登録商標)、又はインターネットのようなネットワーク上のサーバーに対して要求を作成する時に、セッションが作られる。要求を受け取るセッションサーバーは、例えばアプリケーションサーバー、ウェブサーバー、オブジェクトサーバー、又はサーブレットエンジンのような、セッションにおける情報を格納し、及び/又はセッション要求への応答を作り出すのに使用される如何なるサーバーからも構成されることができる。最終的に要求を受け取るサーバーが、「一次」サーバー、すなわちクライアントがこの後の要求を送るサーバーとなる。次にシステムは、そのセッションにおける「二次」サーバーを選択することができ、これは冗長性のソースとして動作することとなる。
【００１２】
そのセッションの中で更新がなされる度に、その変更は一次サーバー上に格納されることができるだけでなく、例えばリモート呼び出しによって、二次サーバーに送られることもできる。変更がなされる度に、セッションデータの全てを二次サーバーに送る必要はないが、しかし変更のあったデータ又は情報のみを、例えば情報の差分又はパケットで送ることができる。最低限必要な情報を差分で送ることは、システム全体の効率を高めることができる。それがセッションデータ上で動作するという事実を除いて、その複製はミラーリングのように動作する。一例では、サーブレットエンジンを使ったウェブアプリケーションのために、このミラーリングが行われることができる。
【００１３】
クライアントがサーバーに接続する時、クライアント又はユーザーに関連するセッションオブジェクトが作成される。セッションオブジェクトは、セッションの継続時間の間一次サーバー上で保持されることができる、又は指定された時間の後タイムアウトとなることができる。各セッションオブジェクトには、サーバーに対するクライアント及び/又はオブジェクトを特定するための一意の識別子、又は識別番号を与えることができる。要求に応じるために選択されたサーバーは、セッションの継続時間の間、一次サーバーとして動作することができる。一次サーバーは、セッションオブジェクトに対して二次サーバーを選択することができ、その結果オブジェクトが更新される度に、その更新がまた二次サーバー上にも格納されるようになる。システムの効率を高めるために、二次サーバーは、最低限の情報のみを受け取る、又は一括更新を行うように最適化されることができる。
【００１４】
本発明のある実施形態による一つのウェブベースのシステム100が、図1に示されている。このシステムでは、ブラウザ102又はクライアントは、ウェブサーバー104によって受け取られる要求を作成する。ウェブサーバー104が要求を見て、かつ、どのオブジェクトサーバー110がその要求を受け取るべきかを判断するという点で、ウェブサーバー104はプロキシとして動作する。ウェブサーバーはプラグイン又はプラグインAPIを持つことができ、これは要求を認識するものである。プラグインは一般的に、如何なる外部アプリケーションも起動する必要なく追加機能を提供するために、アプリケーションに付加されるオブジェクトである。クライアント102におけるセッションを作成及び収容するのに利用できるオブジェクトサーバー110の間で選択するために、プラグインは、負荷平衡化の決定を行う。ウェブサーバー104は、今度は反対に、選択されたオブジェクトサーバー110に対してプロキシとして動作し、これはアプリケーションサーバー106に収容されることができる。アプリケーションサーバー106の中のサーブレットエンジン108は、要求に応答するために、オブジェクトサーバー110上のオブジェクトを呼び出すサーブレットを実行することができる。その要求に完全に応答するために、オブジェクトサーバー110はまた、データベース112又はデータ記憶装置から情報を引き出す必要もあり得る。オブジェクトサーバー110は、要求を受け取る時にセッションを作り出すことができる。当業者にはよく知られかつ使用されているように、セキュリティを提供するため、アプリケーションサーバー106及びデータベースはファイアウォール114の向こう側に置かれることができる。
【００１５】
この例では、次にオブジェクトサーバーは、そのセッションにおける二次サーバーを選択する。代替の実施形態では、二次サーバーを選択するのにプラグインを使用することができる。プラグインはまた、その決定のために負荷平衡化を使用することもできる。
【００１６】
オブジェクトサーバーは二次サーバーへデータを渡し、かつ、それがバックアップされることを二次サーバーに知らせる。次にオブジェクトサーバーは、クライアントに送られ、及び格納されるクッキーを作り出す。クッキーには、セッションにおいて使用される一次及び二次サーバーの識別表示が含まれている。
【００１７】
クライアントがそれに続く要求を同じセッション上で送る時、どのウェブサーバーがその要求を受け取るかということは全く問題にはならない。ウェブサーバーは、そのセッションにおける一次サーバーを判断するためにクッキーを見て、次に、その一次サーバーに要求を配信する。
【００１８】
図3に示されるような、各々が一次サーバーとして動作する能力のある三つのサーブレットエンジン306、308、及び312を有する例を想定する。もし、セッションが一次サーバー306上で現在稼動中で、しかし一次サーバー306が機能しない場合、ウェブサーバー304は、ブラウザ302からの要求と共に送られてくるクッキー情報を調べることにより、どのサーバーが二次サーバーとして選ばれたかを判断することができる。次にウェブサーバーはその要求を二次サーバー308へ送ろうとすることができ、それにはまたセッション状態情報310が含まれている。ウェブサーバーはブラウザ302へ応答を返すことができ、それはウェブサーバー304により二次サーバー308に送られることのできる他の要求を作成することになるであろう。二次サーバー308は、もし一次サーバー306が要求の受け入れに失敗する場合には、自己のみがウェブサーバーから直接要求を受け取るということを知っているので、もし二次サーバーがその要求を受け取る場合には、自動的に新たな一次サーバーとなることができる。この時点で、二次サーバー308は一次サーバー308となり、新しい二次サーバー312を選択することができる。あるいはそのかわりに、ウェブサーバー304に対するプラグインが新しい二次サーバー312を選択することもできる。通信途絶の可能性のある場所の一つは、第一仮想境界314によって示され、これはブラウザ/クライアント302とウェブサーバー304との間に存在する。第二仮想境界は、ウェブサーバー304とサーブレットエンジン306、308、及び312との間に存在する。
【００１９】
いくつかの実施形態では、一次サーバーの状態を判断するために、二次サーバー又はウェブサーバーが自発的に一次サーバーを監視する。この監視は、例えば、ネットワークに繋がれているか否かを判断するために継続的又は定期的に一次サーバーに「pingをかける」というような適切な方法により行われることができる。もし一次サーバーが要求を受け入れることが出来ないと判断される場合には、二次サーバーが新たな一次サーバーとなることができる。次に新しい二次サーバーが選択されることができる。このような設計の利点は、二重サーバーの障害がセッション状態損失という結果となるかもしれない空白時間が短縮されるということである。いくつかの実施形態では、その空白期間をクライアント要求の率によって定めることが可能であるが、一方この手法では、その空白期間をサーバーにpingをかける率によって定めることが可能となる。
【００２０】
新たな一次及び二次サーバーは同様に、セッションに関する情報を担っている。以前に一次サーバーであったサーバーは、たとえまだそのセッションが動作中に要求を受け入れ及び処理することができるようになったとしても、もはやそのセッションにおける如何なる責務又は情報も持つことはできない。二次サーバーは自動的にその状態を変更することができ、その結果、そのセッションにおける新たな一次サーバーとなるが、しかしその新しい一次サーバーが要求を受け取るまでは、新たな二次サーバーを指定しないようにすることができる。
【００２１】
新たな一次サーバーが他の要求を受け取るか否かわからないので、自発的に新たな二次サーバーを作成する、又は二次サーバー上でセッション情報のバックアップをとることは望まれないであろう。使用されることのない、新たな二次サーバーの作成又は情報のバックアップは、不必要に資源を浪費することとなり得る。あるいはまた、そのセッションが短命で、かつ後に続く要求を受け取るほど長く「存続する」ものではないこともある。各セッションは典型的にタイムアウト値を持っており、その為もしそのセッションが指定された時間のあいだ動作しないような場合には、それは「タイムアウト」または「消滅」し、そのセッションは終了され、及びそのセッションにおいて格納された全てのデータはメモリ保全のため消去されることができる。このような場合には、二次サーバーの作成は資源を浪費するかもしれないというだけでなく、新たな二次サーバーからセッション情報を消去するという不必要な「清掃」作業を要求することにもなり得る。
【００２２】
一次及び/又は二次サーバーはあるアルゴリズムによって選択されることができ、それは例えば、指定されたサーバークラスタ内の如何なるサーバーをも選択肢として持つことができる。各セッションについて一次及び二次サーバーを選択することは、アルゴリズムのために効率的なものとすることができるが、その一方で管理者の入力が望ましいとすることができる場合もある。例えば、複数のサーバーが一つのマシン上に置かれるという可能性もあるだろう。もし負荷に基づくようなアルゴリズムがサーバーを選択しているならば、そのアルゴリズムは同一マシン上で二つのサーバーを選択することができる。マシン故障の場合には、両サーバーとも利用不可能となり得、かつセッションデータは利用不可能及び/又は失われることとなり得る。しかしながら管理者は、異なるマシン上に存在する一次及び二次サーバーを指定することができる。これにより、サーバー間のみならずマシン間にまたがる冗長性についても備えることができる。
【００２３】
あるいはまた、負荷平衡化解析を行っている時に、サーバーが置かれているマシンを考慮に入れるアルゴリズム自身の中で、パラメータを構築することもできるであろう。もし現在最も負荷の低いサーバーが一次サーバーと同じマシン上に存在するならば、アルゴリズムは、他のマシン上に存在する最も負荷の低いサーバーとなるようにすることができる。この手法は、例えば異なる部屋、異なる建物、又は異なる街のサーバーのような、如何なる階層の離隔にも拡張されることができる。
【００２４】
クラスタ内のサーバーが独立して機能することを可能にするため、サーバーは緩く繋がれることができる。この緩い結合を遂行するために、クラスタ内の各サーバーは、あるサーバーがクラスタから離れる時、その動作を受け取ることができるように、自発的に又は非自発的に他のクラスタサーバーの状態を検知するように構成されることができる。ある実施形態では、サーバーは、クラスタサーバーの状態を監視することを、基盤であるOSに依存することができる。他の実施形態では、サーバーが監視を行うことを要求することができる。サーバーの資源はシステム全体のスループットを高めるために利用可能であるため、クラスタサーバーがクラスタ監視に関与する必要のない実施形態のほうが好ましいであろう。
【００２５】
図2は本発明による多層クラスタアーキテクチャ200を示している。システム内の各オブジェクトは、いくつかのサーバーで利用可能なオブジェクトのインスタンスを作成することにより、クラスタ化されることができる。このアーキテクチャは仮想境界を含むことが示されている。「仮想境界」という語は、ネットワーク接続が切れ得る場所を意味している。
【００２６】
図2では、第一の仮想境界212が、ブラウザ202とウェブサーバー204との間に示される。第二の障壁214は、ウェブサーバー204とサーブレットエンジン206との間に示される。第三の障壁216は、サーブレットエンジン206とオブジェクトサーバー208との間に示される。最後に、第四の障壁218が、オブジェクトサーバー208とデータベース210との間に示される。各障壁は通信断絶の可能性のある点を示しており、それはまた、負荷平衡化を利用することもできる。
【００２７】
第一の仮想障壁において、ブラウザが特定のウェブサーバーには至ることができない可能性がある。しかしながら、一次及び二次サーバーに関する情報は既にブラウザのクッキーの中に格納されることができるので、本発明によるシステムにおいてこれは問題にはならないであろう。ブラウザは、どのサーバーが要求を受け取るべきであるかを、クッキーを通してそのウェブサーバーに示すことができるので、ネットワーク上の如何なるウェブサーバーとも連絡をとることができる。このシステムはLAN上で最も効率的であるとすることができるが、如何なる可能なネットワーク上においても、同様の手法を使用することができる。例えば、ブラウザは、第一のウェブサーバーとは離れた建物に置かれているかもしれない第二のウェブサーバー及び/又は終端サーバーと、インターネット越しに連絡をとることも可能であろう。
【００２８】
アプリケーションによって、一次及び二次サーバーはウェブサーバー、サーブレットエンジン、又はEnterpriseJavaBean(「ejb」)エンジンのように、幾つかの異なるサーバー形式となることができる。例えば異なるサーバー形式であるというように、クラスタ内の各サーバーは、さらに独立しかつ特化されることも可能であろうが、しかしまだ一次及び/又は二次サーバーとして動作することもできるであろう。
【００２９】
本発明によるシステム上でクラスタリングが可能であるならば、付加的な一次及び二次サーバーとして動作するように、新たなサーバーをシステムに透過的に付加することが可能であろう。クラスタリングは一般的に、一連のサーバー内に「管理用」サーバーを設けることにより、一連のサーバーの管理を可能にするサーバー管理の手法である。この手法により、クラスタ内のサーバー全体にわたる、潜在的に多様なコンポーネントの配置及び同期を簡単化することができる。クラスタリングは、実質的にシステムの信頼性及び拡張性を高めることができる。
【００３０】
本発明によるシステムにおけるクラスタリングの時には、クラスタ内の各サーバーは、新しいサーバーがクラスタ内に入って来たことを検知し、かつその新しいサーバーを現存の一次サーバーのいずれかに対する二次サーバーとして指定するように構築されることができる。負荷平衡化に使用されるこの方法は、新しいサーバーを一次又は二次サーバーとして即座に指定することができる。
【００３１】
あるいはその代わりに、本発明によるシステムは、入ってくる要求を送るためにハードウェア負荷平衡器を利用することもできる。例えばインターネットの環境下で、ハードウェア負荷平衡器は、IPアドレスを持ち、ネットワーク上に存在することができる。ブラウザ又はクライアントから入ってくる要求は、そのIPアドレスに送られることができる。次にハードウェア負荷平衡器は、他のIPアドレス、すなわち各々IPアドレスを割り当てられ、システム内ではあるがハードウェア負荷平衡器の「向こう側」に置かれている他のサーバーへ、それら要求を転送することができる。このように、ブラウザにはあたかも要求はいつも同じIPアドレスに向かうように見えるが、その時実際には、そのIPアドレスの向こう側にある複数のサーバーに向かうことができるのである。ソフトウェアクラスタリングのような他の方法を利用するのではなく、例えばハードウェア負荷平衡器にサーバーを直結させた結果とすることができるように、ハードウェア負荷平衡器は、ネットワーク内で自分の背後に置かれている全てのサーバーを意識することができる。
【００３２】
ハードウェア負荷平衡器を使用する利点が存在し得る。ハードウェア負荷平衡器は、他の手法よりも、負荷平衡化のためのよりよいアルゴリズムを利用することができる。ハードウェア負荷平衡器はノード障害を検知することができ、その結果それらのノードはアルゴリズムで利用可能なサーバーのリストから抜き取られるであろう。たとえそれら個々のサーバーにまだ要求が送られていなかったかもしれないとしても、このノード除去により、アルゴリズムが、到達不可能なサーバーに向かおうとするのを防ぐことができる。
【００３３】
本発明によるシステムはまた、ドメイン名をいくつかのIPアドレスにマッピングする、すなわちウェブサーバーに送られた要求をいくつかのオブジェクトサーバーに転送するハードウェア負荷平衡器を使用するのではなく、DNSRoundRobinのようなDNSプロトコルを使用することもできる。しかしながら、DNSは典型的に、それらのIPアドレスが実際に「生きている」か否かを判定又は検知しない。
【００３４】
ハードウェア負荷平衡器は、その要求が動的なページ作成を要求するものであるのか、又はその要求が静的なページに対するものであるのかによって、特定のサーバー又はサーバークラスタへのある決まった形式の要求のプロキシに使用されることができる。図4では、負荷平衡器414が、ウェブブラウザ402とウェブサーバー404、408、412との間に示される。
【００３５】
本発明での使用のためにハードウェア負荷平衡器414を最適化することが望ましいとすることができる一方で、負荷平衡器自身に物理的な変更を求めるのは望ましくないとすることができる。また、ハードウェア負荷平衡器がクッキーを読み取り、かつ、もし最初の一次サーバー404が機能しない場合には、ブラウザ402上に格納されたクッキーに示される二次サーバー408にその要求を転送する必要があることを理解しなければならない、ということも望ましくないであろう。しかしながら、負荷平衡器に希望のところに要求を送らせ、そして次にシステムが適切に回復していることを確認させることは望ましいであろう。
【００３６】
そのような手法の一つでは、ハードウェア負荷平衡器414が、ウェブブラウザ上のクッキーに格納されたいくらかの任意の情報に基づいて、ブラウザ402又はクライアントから一つのサーバーへ要求を送る傾向がある。例えば、クッキーは情報の最初の文字列を持つことができ、その後には複製に使用されるセッション識別子だけでなく、一次及び二次サーバーに関連する情報の部分が続く。ハードウェア負荷平衡器414は、情報のこの部分のみを見るように構築されることができる。もし、情報のこの部分が連続したクッキー間で変わらない場合には、負荷平衡器は要求を一次サーバー404に転送し戻し続けることができる。また、このような「セッション粘着性」は、例えばクライアントのIPアドレスを利用できるような他の適切な方式に基づくこともできる。
【００３７】
クッキー中の情報のその部分は、要求が一次サーバーに戻ることができる限りは、同じままでいることができる。もし一次サーバーが何らかの理由で機能しない場合、二次サーバーは自分自身を新たな一次サーバーに指定することができる。次にその新たな一次サーバーは、セグメント中に新しい二次サーバーについての新たな情報を挿入することができ、それは新たな一次サーバー又は負荷平衡化機構により選択されることができる。あるいはその代わりに、ハードウェア負荷平衡器が新たな一次サーバーを選択し、かつ要求をその新しい一次サーバーに転送することもできる。
【００３８】
負荷平衡器で受け取られるセッションの第一の要求は、本来一つのサーバーに行くようにしっかりとコードされることはできない。ある一つのサーバーに「固執する」判断は、第一の要求が作成され、かつそれがオブジェクトサーバー又は他の終端サーバーから戻って来た後に、定められることができる。ハードウェア負荷平衡器は、この「単純な粘着性」を行う、すなわち本質的にその負荷平衡器が接続している指定された一次サーバーに戻るほどには、充分洗練されているとすることができる。
【００３９】
もしクッキーが全く存在しないならば、ハードウェア負荷平衡器は、負荷又は応答時間に基づくような、多数の負荷平衡化方法のいずれかを使用するように構築されることができる。次に負荷平衡器は、例えば適当なクラスタの中で、サーバーを選択し、かつ要求をそのサーバーに送ることができる。一次サーバーは要求に応答する時、一次及び二次サーバーに関する情報の部分を含むクッキーをブラウザに送ることができる。ハードウェア負荷平衡器によって受け取られる、そのブラウザからの次に続く各要求は、それに関連するクッキーを有することができ、そのため負荷平衡器はその要求を一次サーバーと対応付けることができる。
【００４０】
システムはまだ、要求が一次サーバーに行くことを保証することはできないであろう。図4に示されるように、もし一次サーバー404で障害が発生し、かつ他の要求が負荷平衡器414に入ってくる場合には、負荷平衡器はただ単に、異なった負荷平衡化決定を行い、かつ要求を他のサーバー412に送ることができる。その要求は、二次サーバー408に行くことはできない。この手法は、要求が自動的に二次サーバーに行くことができるプラグイン手法について上で述べたものとは異なる。このように、ハードウェア負荷平衡器は上述されたものと同様に、特別なプロキシプラグインに比べると「知的」ではない。
【００４１】
負荷平衡器414によって選択されるサーバー412が二次サーバー408でないならば、選択されたサーバー412は、その要求が自己をホストとしていないセッション上の要求であるということを認識することができる。この場合、選択されたサーバー412は、二次サーバー408を判断するためにクッキーを見ることができる。
【００４２】
選択されたサーバー412が二次サーバー408を突き止めると、その二次サーバー408からセッション状態情報410を要求することができる。次に、選択されたサーバー412は、自分自身をそのセッションにおける新たな一次サーバーに変えることができる。この場合、二次サーバー408は同じままでいることができる。クッキーは、負荷平衡器414が新たな一次サーバー412に要求を導きつづけるように更新される。
【００４３】
負荷平衡器414が、偶然にも二次サーバー408である新しいサーバーに要求を導くことに決める場合には、二次サーバーは自分自身を新たな一次サーバーとして設定することができ、かつ新たな二次サーバーが選択されることができる。
【００４４】
その背後にサーブレットクラスタを有するハードウェア負荷平衡器を持つシステムは、高速データパスを提供することができる。もしウェブサーバーが経路制御を行うならば、要求は、何らかのコードが実行されているソフトウェアの中までやってきて、かつその後ネットワーク上に送り返される必要があるであろう。負荷平衡器/サーブレットクラスタシステムは全てを低プロトコル層で行うため、それは非常に早いものとなることができる。
【００４５】
負荷平衡化アルゴリズムを可能な限り配置させることは、有利となり得る。ハードウェア負荷平衡器の場合、Javaで書かれることのできるソフトウェアのような、サーバー上のソフトウェアが正しく動作していることを確認することだけが必要となり得る。ハードウェア負荷平衡器のないシステムでは、システム内の各ウェブサーバーの特別なプラグインの各々が同様にうまく動作していることを確認しなければならないであろう。
【００４６】
また、異なるプラットフォームのためのプラグインをサポートすることも必要であろう。ハードウェア負荷平衡器は、例えば、NetscapeApplicationServer(NAS)、WebLogicServer(WLS)、MicrosoftInternetInformationServer(IIS)、又はApacheHTTPServerのような異なるプラットフォームに基づくシステムにおいても、同じようにうまく動作することができる。ハードウェア負荷平衡器を用いることで、堤防の一つを取り除くことができるように、システムは複雑さを一段階減らすことができる。これは図4に示されるが、ここではウェブサーバーとサーブレットエンジンは同じプロセス中に存在する。
【００４７】
上述のシステムの幾つかは、ウェブアクセスのためにサーブレットを利用することができる。同様な機構を、状態有りセッションビーン、ある形式のEnterpriseJavaBean(「ejb」)へのアクセスに使用することも出来る。サーブレットはブラウザクライアントからの要求に応じるために使用されることができるが、一方ejbサーバーはJavaクライアントからの要求をサポートするために使用されることができる。
【００４８】
Javaクライアントにおいては、セッションの存続時間の間ずっと、一つの持続的な接続が存在することができる。その時、クッキーの必要(又はサポート)はないであろう。また、持続的な接続が存在しているため、もはや負荷平衡器の必要もないであろう。Javaクライアントは、例えばDNS又は負荷平衡器を用いて、終端サーバーの一つに接続することができる。次に、Javaクライアントは、状態有りセッションへの「ハンドル」を捜すことができる。Javaにおけるハンドルとはポインタと似ており、適切なセッションの位置を捜し出すために使用されることができる。
【００４９】
図5のシステム500に注目すると、Javaクライアント502がハンドルに接続されると、状態有りセッションビーン510が作成されることができる。状態有りセッションビーン510は、セッションにおける情報をキャッシュ又は格納することを扱うのに使用されることができる。状態有りセッションビーンが作成される時、ビーンを収容しているサーバーは一次サーバー508となることができ、それに対してJavaクライアント502は要求を作成することができる。次に一次サーバー506は、二次サーバー510を選択することができる。二次サーバー510はまた、セッション情報をキャッシュ又は格納するために、状態有りセッションビーン512を有することができる。
【００５０】
状態有りセッションビーン508は、クッキーを送るのと同様に、RMIプロトコルを用いてこの情報をJavaクライアント502に返すことができる。トランザクションの状況伝搬が動作する方法と同様に、このクッキーのシミュレーションを動作させるために、付加情報を標準RMIの「最上位」に置くことができる。一次/二次サーバーの識別子のペアは、各応答と共にJavaクライアント502に返されることができる。Javaクライアント502が呼び出しを作成する度に、それは、インターフェース504を通して、セッションにおける一次サーバー506への呼び出しを作成し続けるのに適応した特別なRMIコードの中に呼び出しをかけることができる。もし一次サーバーが動作不能である場合には、Javaクライアント502は二次サーバー510の所在に関する情報を見ることができ、かつその代わりに二次サーバーに対して要求を作成することができる。もし、サーバー特定に関する必須情報のみがRMIの最上位に返されるのであれば、それは効率のために望ましいことであろう。
【００５１】
Javaクライアント502は、どのサーバーが二次サーバー510であるかを常に知ることができる。例えば、もし一次サーバー506が利用不可能である場合には、二次サーバー510に行くことを常にわかっているように、Javaクライアントは、プロキシが所有するかもしれないロジックと同じロジックの多くを持つことができる。Javaクライアントは、要求を利用不可能なサーバーに送らないようにするため、サーバーの状態を監視することができる。二次サーバー510が新しい一次サーバーとなる場合には、さらに新たな二次サーバー504を選択することができる。新しい一次及び/又は二次サーバーを選択するためのロジックは、上述のもの同様なものであるとすることができる。Javaクライアントは即座に、新たな一次/二次サーバーに更新することができる。
【００５２】
上の検討より、上述のものを含む様々な変形が利用され得るけれども、本発明によるシステムは一般的に、二つに分岐している方針の一方を辿ることができる。そのような方針の共通部分が図6に示される。図6の過程600では、一次サーバーが一団のサーバーから選択される602。一次サーバーが選択されると、クライアント要求はその一次サーバーで応じられる604。次に、もしかすると一次サーバーにより、二次サーバーが選択される606。次に、セッション情報が一次サーバーから二次サーバーへ送られる608。一次及び二次サーバーを特定する情報は、例えばクッキー内に格納され、又は標準(又はその他)RMIの最上位に渡されることができる、というようにクライアント上に格納されることができる610。
【００５３】
この点から、処理はソフトウェア負荷平衡化に有用となり得る方針、及びハードウェア負荷平衡化に有用となり得る過程とに分かれる。図7は、ソフトウェア負荷平衡化に有用な過程700を示している。過程700では、一次及び二次サーバーが既に選択されているセッション上で要求が受け取られ、かつクライアント上に格納された情報から一次サーバーの識別情報が作成される702。次に、一次サーバー上で要求に応じようとする試みがなされる704。もし一次サーバーが要求を受け取ることができない場合には、要求は二次サーバー上で応じられる706。二次サーバーが要求を受け取ると、その二次サーバーが新たな一次サーバーとなる708。次に新たな二次サーバーが選択され、かつ新しい一次サーバーからセッション情報が送られる710。
【００５４】
ハードウェア負荷平衡器を有するシステムに有用である、もう一方の方針が図8に示されている。図8の過程800では、既に一次及び二次サーバーが選択されているセッション上で要求が受け取られ、クライアント上に格納された情報から一次サーバーの識別情報が作成される802。次に、一次サーバー上で要求に応じようとする試みがなされる804。もし一次サーバーが要求に応じることができない場合には、ハードウェア負荷平衡器は新たな一次サーバーを選択し、かつその新しい一次サーバー上で要求に応じようと試みる806。次にセッション情報は、例えば新しい一次サーバーからの要求に応じて、二次サーバーからその新しいサーバーに送られる808。次に、新しい一次サーバーは要求に応答し、かつ更新されたセッション情報を二次サーバーに送ることができる810。
【００５５】
本発明の如何なる実施形態においても整合性を保つために、セッションデータにおける変更はバージョン番号に対応付けられることができる。一次及び二次サーバーはそれぞれ、セッションのどのバージョンを自己が格納しているか、知ることができる。サーバーは、もし自己が現在格納しているものよりも後の、又は大きいバージョン番号を持つ要求を受け取った場合に限り、データを修正するように指示されることができる。一次及び二次サーバーは、双方が同じバージョン番号上にあることを確認するために、互いに定期的に調べることができる。バージョン番号は、順番を保証するために数を増やしていく、というのと同じくらい単純な方法を使用することができる。セッション情報における整合性を維持するために、一次及び二次サーバーが同期することが望まれるであろう。バージョン番号の同期がとれない時、一次サーバーは、セッションの同期を回復させるために、二次サーバーへ全セッション情報を送ることに決めることができる。この同期はまた、必要が生じれば、一次と二次の間の役割を切り替えるというサーバーの能力を促進する。
【００５６】
もし一次サーバーが、例えば悪い接続というような理由で、二次サーバー上の情報を更新することが出来ない場合には、一次サーバーは更新し続け、かつ二次サーバーは如何なる更新も認識しないということがあり得るであろう。その時、一次サーバーが二次サーバーよりもいくつかバージョンが先になるということがあり得るであろう。一次サーバーが再び二次サーバーに情報を送ることができるようになると、二つの連続したバージョン間の差分は機能することができない。このような場合、両サーバー間のデータセッションの整合性を取るため、一次サーバーは、新しい一連のセッションデータ全体を二次サーバーに送ることができる。この場合、二次サーバーは、連続したバージョン間の差分を得るか、又はセッション全体における全てのデータを得るかのいずれかとなる。他の実施形態では、二次サーバーを現在のバージョンに達するようにするために、任意のバージョン間の差分を作成することもあり得るであろう。
【００５７】
Javaの状態を辿るためのクッキーのシミュレーションでは、大きい乱数をサーバー識別のために使用することができる。その数は、二つの異なるペアの識別番号の合計が同じになることが極めてないほどに、充分大きいものとすることができる。これら二つの番号をJavaクライアントに送り返すのみということも可能であり、かつ新しい番号を得るためにその二つの番号を足すことによりそのサーバーのペアが特定されるころができる。これにより、たった一つの数を渡すことで二つのサーバーを特定することが可能となり、それは効率を高めることができる。Javaクライアントは特定のサーバーと持続的に接続することが可能であるため、クライアントは、二次サーバーの識別番号を得るために、渡されている合計数から一次サーバーの識別番号を引くことにより二次サーバーを特定することができる。
【００５８】
しかしながら、セッションビーンのようなJavaオブジェクトは、上で考察された持続的な状態とは対照的に、状態なし又は一時的な状態を持つものとすることができる。もしJavaセッションビーンが状態なしの場合には、ビーンは、呼び出し間又は連続した要求間のセッション情報を保持することができないであろう。もし、セッション情報が他のどこかに格納されるならば、状態なしビーンは、要求に応じるために、一時的にセッション情報をロードすることができる。フェ−ルオーバー、すなわち複製されたセッション情報を有する新しい一次サーバーにセッション制御を任せることは、例えば一次サーバーが要求を決して受け取らず、その要求が手続き的でかつ異常終了した、すなわち一回限りの要求であった、というような明らかな呼び出し失敗があったところでのみ、生じることが可能である。これに対して、もしセッションビーンが一時的なものである場合は、インタスタンスは、状態なし負荷平衡化及びフェ−ルオーバーを用いて、状態なしの製造場によって作られることができる。一時的な状態の中のビーンは、メモリ内にバックアップされることができない、又は上で説明したような一次/二次複製を用いてバックアップされることができる、のいずれかである。
【００５９】
一括変更は、失敗の空白期間の増大したシステムのスループットを高めるのに使用されることができる。一括処理又は「箱運搬」の際、効率及び拡張性を高めるため、いくつかの要求が、一つの大きな要求としてまとめて送られる。要求の一括処理は、時間間隔又は要求の数、というような多くの基準のうちのいずれかに基づくことができる。例えばシステムは、10秒毎に、又は100の個々のセッション更新メッセージ毎に対して、一バッチ分の要求を送ることができる。システムはまた、最後の一括処理から10秒経過した時、又は100の要求が受け取られた時に一バッチを送り、双方の基準に対応することもでき、どちらも第一になる。一括処理により、もはやシステムは、同期更新ほど信頼性の高いものではなくなるであろうが、しかしシステム全体の拡張性を高めることができる。
【００６０】
その基準はまた、例えばユーザー又は管理者によって、設定可能なものとすることができる。設定可能な基準は、システムがある決まった時間には大量のトラフィックに直面するが、それ以外の時間には殆どトラフィックがないというような状況に適しているとすることができる。例えば、設定可能な基準により、ピーク時には100メッセージ毎に一括処理し、空いている時間には全く一括処理を行わないということが可能になり、その結果、各要求は適度な時間で送られることとなる。
【００６１】
システム管理者はまた、一次及び二次サーバーとして、クラスタ内の2つのサーバーを組にすることもできる。システム全体の耐故障性を高めるため、管理者の入力が望まれるであろう。例えば、複数のサーバーは一つの物理的なマシン上に置かれることができ、かつ、アルゴリズムが一次及び二次サーバーの両方を同じマシン上に配置することに決めるかもしれない。すると、もしそのマシンが故障する場合には、セッション情報はすっかり失われてしまうこともあるかもしれない。マシン故障からのセッション情報の喪失を防ぐために、管理者は、一次及び二次サーバーそれぞれを、物理的に別個のマシン上に指定することに決めることができる。管理者はまた、様々な負荷平衡化方式に基づいて一次サーバーを選択することもできる。可能性のある方式の例としては、サーバー負荷、接続数、及び物理的な近さに基づくものがある。
【００６２】
本発明のより好ましい実施形態についての上述の説明は、例証及び説明の目的のために提供されたものである。それは網羅的なもの、又は本発明を開示された厳密な形態に限定することを意図したものではない。明らかに、当業者には多くの修正及び変更が明白であろう。本実施形態は、本発明の原理及びその実際の応用を最もよく説明するために、選択され及び説明されたものであり、それゆえ他の当業者は、意図した特定の使用に適した様々実施形態における、かつ様々な修正を伴った本発明を理解することが可能となる。本発明の技術的範囲は、次に続く特許請求の範囲、及びその均等技術によって定められることを意図したものである。
【図面の簡単な説明】
【００６３】
【図１】本発明の一実施形態によるアプリケーションサーバーシステムのダイヤグラムである。
【図２】本発明の一実施形態による複数階層アーキテクチャのダイヤグラムである。
【図３】本発明の一実施形態によるサーブレットエンジンシステムのダイヤグラムである。
【図４】本発明の一実施形態による負荷平衡器システムのダイヤグラムである。
【図５】本発明の一実施形態によるJavaシステムのダイヤグラムである。
【図６】本発明の一実施形態による処理におけるフローチャートである。
【図７】本発明の一実施形態によるソフトウェア負荷平衡器の処理におけるフローチャートである。
【図８】本発明の一実施形態によるハードウェア負荷平衡器の処理におけるフローチャートである。

Claims (74)

1. クライアントセッション中の情報を複製するためのシステムであって、
   ｂ．クライアントセッション中の要求を受け取り、当該要求に応答し、さらに前記クライアントセッションにおけるセッション情報を格納する一次サーバーと、
   ｃ．クライアントセッション中の要求を受け取り、当該要求に応答し、さらに前記クライアントセッションにおけるセッション情報を格納する二次サーバーと、
   ｄ．前記一次及び二次サーバーの識別情報を含むクライアントからの要求を受け取り、前記識別情報を処理し、前記一次サーバー上で前記プロセス要求に応じるウェブサーバーと、
   を備え、前記ウェブサーバーは、さらに前記一次サーバーが要求を処理できない場合に、前記二次サーバー上で当該要求に応じる、
   ことを特徴とするシステム。
2. 前記一次及び二次サーバーと通信するデータベースをさらに備え、前記データベースは要求を処理するのに役立つ情報を格納する、
   請求項1記載のシステム。
3. 前記一次サーバーが、さらに、前記クライアントセッションにおける要求を受け取る度に、前記二次セッションサーバーに格納された前記セッション情報を更新する、
   請求項1記載のシステム。
4. 前記ウェブサーバーが、さらに、前記クライアントセッションにおいて最初の要求が受け取られかつ前記クライアント上に何の識別情報も存在しない時、複数のサーバーから前記一次サーバーを選択する、
   請求項1記載のシステム。
5. 前記クライアント上に格納されるクッキーをさらに備え、前記クッキーは前記一次及び二次サーバーの識別情報を含む、
   請求項1記載のシステム。
6. 前記一次サーバーが、さらに、前記クライアント上の前記クッキーを作成する、
   請求項5記載のシステム。
7. 前記ウェブサーバーが、前記一次サーバーを選択するのに使用されるアルゴリズムを含むプラグインをさらに備える、
   請求項1記載のシステム。
8. 前記ウェブサーバーが、前記一次及び二次サーバーに要求を送るのに使用されるアルゴリズムを含むプラグインをさらに備える、
   請求項1記載のシステム。
9. 前記アルゴリズムが負荷平衡化アルゴリズムである、
   請求項7記載のシステム。
10. 前記一次サーバーが前記二次サーバーを選択するのに適応した、
    請求項1記載のシステム。
11. 前記一次サーバーが、クライアントからの最初の要求を受け取った時に、前記クライアントセッションを開始する、
    請求項1記載のシステム。
12. 前記二次サーバーが、さらに、前記一次サーバーが処理できなかった要求を受け取る場合に、新たな一次サーバーとなる、
    請求項1記載のシステム。
13. 前記二次サーバーが、さらに、新たな二次サーバーを選択し、当該新たな二次サーバーにセッション情報を送る、
    請求項12記載のシステム。
14. 前記ウェブサーバーが新たな二次サーバーを選択する、
    請求項12記載のシステム。
15. 前記二次サーバーが、さらに、前記一次サーバーが要求を受け取ることができるか否かを判定するために前記一次サーバーを監視する、
    請求項1記載のシステム。
16. 前記二次サーバーが、さらに、前記一次サーバーが要求を受け取ることができない場合に、新たな一次サーバーとなる、
    請求項1記載のシステム。
17. 前記一次及び二次サーバーの一つが、ウェブサーバー、サーブレットエンジン、及びenterprise Java beanエンジンからなるグループから選択される、
    請求項1記載のシステム。
18. Javaクライアントセッション中の情報を複製するためのシステムであって、
    ａ．クライアントセッション中でJavaクライアントからの要求を受け取り、当該要求に応答し、さらに、前記クライアントセッションにおけるセッション情報を格納する一次サーバーと、
    ｂ．クライアントセッション中で要求を受け取り、当該要求に応答し、さらに、前記クライアントセッションにおけるセッション情報を格納する二次サーバーと、
    ｃ．前記クライアントセッションにおける情報を保持し、かつ前記一次及び二次サーバーの識別情報をクライアントに送り返すのに使用される、前記一次サーバー上の状態有りセッションビーンと、
    を備えることを特徴とするシステム。
19. クライアントからの要求を受け取り、かつ前記一次サーバーを選択する負荷平衡器をさらに備える、
    請求項18記載のシステム。
20. 前記一次サーバーが、さらに、前記クライアントセッションの間、Javaクライアントとの持続的な接続を維持する、
    請求項18記載のシステム。
21. 前記ウェブサーバーが、さらに、前記一次サーバーへの要求を一括で送る、
    請求項1記載のシステム。
22. クライアントセッション中に冗長性を提供するための方法であって、
    ａ．複数のセッションサーバーから一次サーバーを選択するために、クライアントセッション中のクライアントからの最初の要求に対して負荷平衡化の決定を行うステップと、
    ｂ．前記一次サーバー上で前記要求に応じるステップと、
    ｃ．二次サーバーを選択するステップと、
    ｄ．前記一次サーバーから前記二次サーバーへ、前記クライアントセッションにおけるセッション情報を送るステップと、
    ｅ．前記クライアントセッションで要求が受け取られる度に、前記一次及び二次サーバー上のセッション情報を更新するステップと、
    を含むことを特徴とする方法。
23. 前記クライアント上のクッキー内に前記情報を格納するステップをさらに含む、
    請求項22記載の方法。
24. 前記一次サーバーが要求を処理できない場合に、前記二次サーバー上で当該要求に応じるステップをさらに含む、
    請求項22記載の方法。
25. 新たな二次サーバーを選択するステップをさらに含む、
    請求項24記載の方法。
26. 前記一次サーバーへの要求に一括で応じるステップをさらに含む、
    請求項22記載の方法。
27. 前記一次サーバーから前記二次サーバーへ、前記クライアントセッションにおけるセッション情報を一括で送るステップをさらに含む、
    請求項22記載の方法。
28. 状態有りセッションビーン内にセッション情報を保持するステップをさらに含む、
    請求項22記載の方法。
29. バージョン番号を、要求に応じた前記セッション情報への各更新に対応付けるステップをさらに含む、
    請求項22記載の方法。
30. 前記一次サーバーから前記二次サーバーへ前記クライアントセッションにおけるセッション情報を送るステップが、前記セッション情報内の変更を含む情報の差分を送ることを含む、
    請求項22記載の方法。
31. 前記一次及び二次サーバー各々に識別番号を割り当てるステップをさらに含む、
    請求項22記載の方法。
32. 前記一次及び二次サーバーの両方を表す一つの番号を得るために、前記一次及び二次サーバーの識別番号を足すステップをさらに含む、
    請求項31記載の方法。
33. クライアントセッション中の情報を複製するためのシステムであって、
    ａ．複数のセッションサーバーと、
    ｂ．クライアントセッション中の要求を受け取り、当該要求に応答し、さらに、当該クライアントセッションにおけるセッション情報を格納し、かつ前記一次サーバーに関する情報を含むクッキーを作成し、当該クッキーをセッションクライアントに送る、前記複数のセッションサーバー内の一次サーバーと、
    ｃ．前記一次サーバーから前記セッション情報を受け取り、当該セッション情報を格納し、さらに、クライアントセッション中の要求を受け取り、当該要求に応答する、前記一次サーバーにより選択される、前記複数のセッションサーバー内の二次サーバーと、
    ｄ．前記一次及び二次サーバーの識別情報を含むクライアントからの要求を受け取り、前記識別情報を処理し、かつ前記一次サーバー上で前記プロセス要求に応じるウェブサーバーと、
    を備え、前記ウェブサーバーはさらに、前記一次サーバーが要求を処理できない場合に、前記二次サーバー上で当該要求に応じる、
    ことを特徴とするシステム。
34. クライアントセッション中に冗長性を提供するための方法であって、
    ａ．複数のセッションサーバーから一次サーバーを選択するために、クライアントセッション中のクライアントからの最初の要求に対する負荷平衡化の決定を行うステップと、
    ｂ．前記一次サーバー上で前記要求に応じるステップと、
    ｃ．前記一次サーバーから当該一次サーバーにより選択される二次サーバーに、前記クライアントセッションにおけるセッション情報を送るステップと、
    ｄ．前記一次及び二次サーバーを特定する情報を含むクッキーをセッションクライアント上に格納するステップと、
    ｅ．前記クライアントセッションで要求が受け取られる度に、前記一次及び二次サーバー上のセッション情報を更新するステップと、
    を含むことを特徴とする方法。
35. 前記クライアントセッション内で受け取られた要求の中の識別情報を読み取り、かつ前記一次サーバー上で前記要求に応じるステップをさらに含む、
    請求項34記載の方法。
36. クライアントセッション中の情報を複製するためのシステムであって、
    ａ．複数のセッションサーバーと、
    ｂ．クライアントセッション中の要求を受け取り、当該要求に応答するのに適応し、さらに前記クライアントセッションにおけるセッション情報を格納するし、かつ、前記一次サーバーに関する情報を含むクッキーを作成し、当該クッキーをセッションクライアントに送る、前記複数のセッションサーバー内の一次サーバーと、
    ｃ．前記一次サーバーから前記セッション情報を受け取り、当該セッション情報を格納し、さらに、クライアントセッション中の要求を受け取り、当該要求に応答する、前記一次サーバーにより選択される、前記複数のセッションサーバー内の二次サーバーと、
    ｄ．クライアントから最初の要求を受け取り、当該要求を前記一次サーバーに送り、さらに、前記一次及び二次サーバーの識別情報を含むクライアントからの次に続く要求を受け取り、かつ前記識別情報を処理し、前記一次サーバー上で前記プロセス要求に応じる、前記一次サーバーを選択するための負荷平衡化ロジックを含むウェブサーバーと、
    を備え、前記ウェブサーバーはさらに、前記一次サーバーが要求を処理できない場合に、前記二次サーバー上で当該要求に応じる、
    ことを特徴とするシステム。
37. クライアントセッション中に冗長性を提供するための方法であって、
    ａ．複数のセッションサーバーから一次サーバーを選択するために、クライアントセッション中のクライアントからの最初の要求に対する負荷平衡化の決定を行うステップと、
    ｂ．前記一次サーバー上で前記要求に応じるステップと、
    ｃ．前記一次サーバーから当該一次サーバーにより選択された二次サーバーへ、前記クライアントセッションにおけるセッション情報を送るステップと、
    ｄ．セッションクライアント上にクッキーを格納するステップであって、当該クッキーが前記一次及び二次サーバーを特定する情報を含む当該ステップと、
    ｅ．前記クライアントセッション中の、次に続くいずれかの要求と共に受け取られる前記識別情報を読み取り、かつ前記一次サーバー上で当該次に続く要求に応じるステップと、
    ｆ．前記クライアントセッションにおいて、次に続く要求が前記一次サーバー上で応じられる度に、前記一次及び二次サーバー上のセッション情報を更新するステップと、
    を含むことを特徴とする方法。
38. クライアントセッション中に冗長性を提供するための方法であって、
    ａ．クライアントからの最初の要求に応じて、複数のセッションサーバーから一次サーバーを選択するステップと、
    ｂ．クライアントセッションを開始するために、前記一次サーバー上で前記要求に応じるステップと、
    ｃ．二次サーバーを選択するステップと、
    ｄ．前記一次サーバーから前記二次サーバーへ、前記クライアントセッションにおけるセッション情報を送るステップと、
    ｅ．前記クライアントセッションで要求が受け取られる度に、前記一次及び二次サーバー上のセッション情報を更新するステップと、
    を含むことを特徴とする方法。
39. 前記クライアント上のクッキー内に前記情報を格納するステップをさらに含む、
    請求項38記載の方法。
40. 前記一次サーバーが要求を処理できない場合に、前記二次サーバー上で当該要求に応じるステップをさらに含む、
    請求項38記載の方法。
41. 新たな二次サーバーを選択するステップをさらに含む、
    請求項40記載の方法。
42. 前記一次サーバーへの要求に一括で応じるステップをさらに含む、
    請求項38記載の方法。
43. 前記一次サーバーから前記二次サーバーへ、前記クライアントセッションにおけるセッション情報を一括で送るステップをさらに含む、
    請求項38記載の方法。
44. クライアントセッション中の情報を複製するためのシステムであって、
    ａ．複数のサーバーと、
    ｂ．クライアントセッション中の要求を受け取り、当該要求に応答し、さらに、前記クライアントセッションにおけるセッション情報を格納する、前記複数のサーバー内の一次サーバーと、
    ｃ．クライアントセッション中の要求を受け取り、当該要求に応答し、さらに、前記クライアントセッションにおけるセッション情報を格納する、前記複数のサーバー内の二次サーバーと、
    ｄ．前記一次及び二次サーバーの識別情報を含むクライアントからの要求を受け取り、前記識別情報を含む要求の該当部分を調べるハードウェア負荷平衡器と、
    を備え、前記ハードウェア負荷平衡器がさらに、当該部分が前の要求以来変更されていない場合には、前記一次サーバー上で前記プロセス要求に応じ、当該部分が変更されていた場合には、前記複数のサーバーから新たな一次サーバーを選択する、
    ことを特徴とするシステム。
45. クライアント上に格納されるクッキーをさらに備え、前記クッキーは、前記一次及び二次サーバーの識別情報を含む、
    請求項44記載のシステム。
46. 前記クッキーが、前記一次サーバーに対する番号、及び前記二次サーバーに対する番号を含む、
    請求項45記載のシステム。
47. 前記クッキーが、前記一次サーバーに対する番号と前記二次サーバーに対する番号との合計である番号を含む、
    請求項45記載のシステム。
48. 前記ハードウェア負荷平衡器が、さらに、前記一次サーバーが要求を処理できない場合に、前記複数のサーバーから新たな一次サーバーを選択する、
    請求項44記載のシステム。
49. 前記一次サーバーが、自己をホストとしないあるクライアントセッション上の要求を受け取る時に、前記二次サーバーから前記クライアントセッションにおけるセッション情報を要求し、前記二次サーバー上に格納されている前記クライアントセッションにおける情報を要求する、
    請求項44記載のシステム。
50. 前記一次サーバーが、さらに、クライアントセッションにおいて受け取られる要求に関連するクッキーを読み取り、かつ前記一次サーバーが当該クライアントセッションのホストとして働いているか否かを判定する、
    請求項44記載のシステム。
51. 前記ハードウェア負荷平衡器が、さらに、前記一次サーバーへの要求を一括で送る、
    請求項44記載のシステム。
52. クライアントセッション中に冗長性を提供するための方法であって、
    ａ．複数のサーバーから一次サーバーを選択するために、クライアントセッション中のクライアントからの最初の要求に対する負荷平衡化の決定を、ハードウェア負荷平衡器内のアルゴリズムを使って行うステップと、
    ｂ．前記一次サーバー上で前記要求に応じるステップと、
    ｃ．前記一次サーバーを使って二次サーバーを選択するステップと、
    ｄ．前記一次サーバーから前記二次サーバーへ、前記クライアントセッションにおけるセッション情報を送るステップと、
    ｅ．前記クライアントセッションで要求が受け取られる度に、前記一次及び二次サーバー上のセッション情報を更新するステップと、
    を含むことを特徴とする方法。
53. 前記クライアント上のクッキー内に前記情報を格納するステップをさらに含む、
    請求項52記載の方法。
54. 前記一次サーバーが要求を処理できない場合に、前記ハードウェア負荷平衡器を使って新たな一次サーバーを選択するステップをさらに含む、
    請求項52記載の方法。
55. 前記新たな一次サーバー上で要求に応じるステップをさらに含む、
    請求項54記載の方法。
56. 新たな二次サーバーを選択するステップをさらに含む、
    請求項54記載の方法。
57. 前記一次サーバーへの要求に一括で応じるステップをさらに含む、
    請求項52記載の方法。
58. 前記一次サーバーから前記二次サーバーへ、前記クライアントセッションにおけるセッション情報を一括で送るステップをさらに含む、
    請求項52記載の方法。
59. バージョン番号を、要求に応じた前記セッション情報への各更新に対応付けるステップをさらに含む、
    請求項52記載の方法。
60. 前記一次サーバーから前記二次サーバーへ前記クライアントセッションにおけるセッション情報を送るステップが、前記セッション情報内の変更を含む情報の差分を送ることを含む、
    請求項52記載の方法。
61. 前記一次及び二次サーバー各々に識別番号を割り当てるステップをさらに含む、
    請求項52記載の方法。
62. 前記一次及び二次サーバーの両方を表す一つの番号を得るため、前記一次サーバーに対する識別番号と前記二次サーバーに対する識別番号を足すステップをさらに含む、
    請求項52記載の方法。
63. クライアントセッション中の情報を複製するためのシステムであって、
    ａ．複数のサーバーと、
    ｂ．クライアントセッション中の要求を受け取り、当該要求に応答し、さらに、前記クライアントセッションにおけるセッション情報を格納し、かつ前記一次サーバーに関する情報を含むクッキーを作成し、当該クッキーをセッションクライアントに送る、前記複数のサーバー内の一次サーバーと、
    ｃ．前記一次サーバーから前記セッション情報を受け取り、当該セッション情報を格納し、さらに、クライアントセッション中の要求を受け取り、当該要求に応答する、前記一次サーバーによって選択される、前記複数のサーバー内の二次サーバーと、
    ｄ．前記一次及び二次サーバーの識別情報を含むクライアントからの要求を受け取り、ウェブサーバーが前記識別情報を処理しかつ前記一次サーバー上で前記プロセス要求に応じる、ハードウェア負荷平衡器と、
    を備え、前記ハードウェア負荷平衡器は、前記一次サーバーが要求を処理できない場合に、新たな一次サーバー上で当該要求に応じる、
    ことを特徴とするシステム。
64. クライアントセッション中に冗長性を提供するための方法であって、
    ａ．複数のサーバーから一次サーバーを選択するために、クライアントセッション中のクライアントからの最初の要求に対する負荷平衡化の決定を、ハードウェア負荷平衡器内のアルゴリズムを使って行うステップと、
    ｂ．前記一次サーバー上で前記要求に応じるステップと、
    ｃ．前記一次サーバーから当該一次サーバーにより選択される二次サーバーへ、前記クライアントセッションにおけるセッション情報を送るステップと、
    ｄ．前記一次及び二次サーバーを特定する情報を含むクッキーをセッションクライアント上に格納するステップと、
    ｅ．前記クライアントセッションで要求が受け取られる度に、前記一次及び二次サーバー上のセッション情報を更新するステップと、
    を含むことを特徴とする方法。
65. 前記クライアントセッション中で受け取られる要求に対する識別情報を含むクッキーの一部分を処理し、かつ前記一次サーバー上で当該要求に応じるステップをさらに含む、
    請求項64記載の方法。
66. クライアントセッション中の情報を複製するためのシステムであって、
    ａ．複数のサーバーと、
    ｂ．クライアントセッション中の要求を受け取り、当該要求に応答し、さらに、前記クライアントセッションにおけるセッション情報を格納し、かつ前記一次サーバーに関する情報を含むクッキーを作成し、当該クッキーをセッションクライアントに送る、前記複数のサーバー内の一次サーバーと、
    ｃ．前記一次サーバーから前記セッション情報を受け取り、当該セッション情報を格納し、さらに、クライアントセッション中で要求を受け取り、当該要求に応答する、前記一次サーバーによって選択される、前記複数のサーバー内の二次サーバーと、
    ｄ．クライアントからの最初の要求を受け取り、当該要求を前記一次サーバーに送り、さらに、前記一次及び二次サーバーの識別情報を含むクライアントからの次に続く要求を受け取り、かつ、前記識別情報を処理し、前記一次サーバー上で前記プロセス要求に応じる、前記一次サーバーを選択するための負荷平衡化ロジックを含むハードウェア負荷平衡器と、
    を備え、前記ハードウェア負荷平衡器はさらに、前記一次サーバーが要求を処理できない場合に、新たな一次サーバーを選択し、当該新たな一次サーバー上で当該要求に応じる、
    ことを特徴とするシステム。
67. クライアントセッション中に冗長性を提供するための方法であって、
    ａ．複数のサーバーから一次サーバーを選択するために、クライアントセッション中のクライアントからの最初の要求に対する負荷平衡化の決定を、ハードウェア負荷平衡器内のアルゴリズムを使って行うステップと、
    ｂ．前記一次サーバー上で前記要求に応じるステップと、
    ｃ．前記一次サーバーから当該一次サーバーにより選択された二次サーバーへ、前記クライアントセッションにおける情報を送るステップと、
    ｄ．前記セッションクライアント上に、前記一次及び二次サーバーを特定するための情報を含むクッキーを格納するステップと、
    ｅ．前記クライアントセッション中の、次に続くいずれかの要求と共に受け取られる前記識別情報を読み取り、かつ前記一次サーバー上で当該次に続く要求に応じるステップと、
    ｆ．前記クライアントセッションにおいて、次に続く要求が前記一次サーバー上で応じられる度に、前記一次及び二次サーバー上のセッション情報を更新するステップと、
    を含むことを特徴とする方法。
68. クライアントセッション中に冗長性を提供するための方法であって、
    ａ．クライアントからの最初の要求に応じて、複数のサーバーから一次サーバーを、ハードウェア負荷平衡器内の負荷平衡化ロジックを使って選択するステップと、
    ｂ．クライアントセッションを開始するために、前記一次サーバー上で前記要求に応じるステップと、
    ｃ．二次サーバーを選択するステップと、
    ｄ．前記一次サーバーから前記二次サーバーへ、前記クライアントセッションにおけるセッション情報を送るステップと、
    ｅ．前記クライアントセッションで要求が受け取られる度に、前記一次及び二次サーバー上のセッション情報を更新するステップと、
    を含むことを特徴とする方法。
69. 前記クライアント上のクッキー内に前記情報を格納するステップをさらに含む、
    請求項68記載の方法。
70. 前記一次サーバーが要求を処理できない場合に、新たな一次サーバー上で当該要求に応じるステップをさらに含む、
    請求項68記載の方法。
71. 前記ハードウェア負荷平衡器内の負荷平衡化ロジックを使って、新たな一次サーバーを選択するステップをさらに含む、
    請求項68記載の方法。
72. 新たな二次サーバーを選択するステップをさらに含む、
    請求項68記載の方法。
73. 前記一次サーバーへの要求に一括で応じるステップをさらに含む、
    請求項68記載の方法。
74. 前記一次サーバーから前記二次サーバーへ、前記クライアントセッションにおけるセッション情報を一括で送るステップをさらに含む、
    請求項68記載の方法。

Images