JP4481498B2

JP4481498B2 - 複製サーバのためのプロトコル

Info

Publication number: JP4481498B2
Application number: JP2000571348A
Authority: JP
Inventors: ペール，アンデルスホルムベルイ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 1998-09-24
Filing date: 1999-09-23
Publication date: 2010-06-16
Anticipated expiration: 2019-09-23
Also published as: EP1116115B1; JP2002525748A; CN1213376C; BR9913941A; US6247141B1; EP1116115A2; AU6380499A; CA2344311C; DE69905594D1; WO2000017755A2; WO2000017755A3; KR20010079917A; DE69905594T2; CN1342280A; CA2344311A1; KR100599912B1

Description

【０００１】
（背景技術）
本発明はフォールトトレラント(fault tolerant)サーバシステムに関し、特に冗長サーバ(redundant server)を含むフォールトトレラントサーバシステムに関する。
【０００２】
電気通信システムにおけるサービスの高稼働率はフォールトトレラントコンピュータ又は分散システムアーキテクチャによって実現することができる。しかし、この冗長化利用は、他のシステム特性(property)に悪影響を及ぼしうる。例えば、ハードウェアレベルの冗長化利用はコスト、物理的な大きさ、電力消費、故障率等を増加させる。そのため、システム内において複数レベルの冗長化利用を不可能にしている。
【０００３】
例えば、分散システムは堅牢さを高めるためにコンピュータ間での複製を実現することができる。これらコンピュータの各々がフォールトトレラントである場合、コストは倍増する。さらに、ソフトウェア障害から回復可能とするためにソフトウェア中にバックアップコピーが維持されている場合、フォールトトレラントハードウェアのコスト及び分散システムにおける複数コピーのための追加メモリのコストを増加させる。従って、コストを低く維持するために、複数レベルの冗長化利用は避けることが好ましい。このような設計上の選択が、１レベルのみの冗長化を利用するという結果であるため、可能な限り多くの誤り及び他の外乱をカバーするように選択されねばならない。
【０００４】
外乱はハードウェア欠陥やソフトウェア欠陥によって起こりうる。ハードウエア欠陥は恒久的な物と一時的な物に特徴づけることができる。いずれの場合も、そのような欠陥はフォールトトレラントコンピュータによって補償(cover)することが可能である。コンピュータハードウェアの急速な進歩によって、システム内の集積回路及び／又は集積装置総数は減少を続け、さらに、そのような集積回路及び集積装置のそれぞれの信頼性は引き続き向上するであろう。全体として、今日ハードウェア欠陥はシステム外乱の主要因ではなく、将来的にはさらに少なくなるであろう。従って、単に可能性があるハードウェア誤りを取り扱うためだけに個別の冗長性、すなわちフォールトトレラントコンピュータを持つことを妥当とするのはより困難になっていくであろう。
【０００５】
ソフトウェア誤りに関しては同じことは言えない。ソフトウェアの複雑性は増加を続けており、開発期間短縮の必要性はより複雑化するソフトウェアを可能性のある全ハードウェア構成(configuration)、動作モードなどでテストすることを妨げている。より良いテスト方法としては通常の場合において完全なデバッグを行うことが期待される。非常に特殊な場合にのみ発生する誤り、いわゆる「ハイゼンバグ(Heisenbuggs)」については、可能性もしくは経済性の点から完全なテストは期待できない。替わりに、その種の誤りはシステム内の冗長性によって補償する必要がある。
【０００６】
プロセスの柔軟結合複製(loosely coupled replication)は一時的な誤りを含むほぼ全てのハードウェア及びソフトウェア誤りを補償可能である。例えば、I.Lee及びR.K. Iyerによって「連係保護システムにおけるソフトウェア信頼性(Software Dependability in the Tandem Guardian System)」（IEEE TRANSATIONS ON SOFTWARE ENGINEERING, vol.21, No. 5, May 1995）において、チェックポインティング（checkpointing:すなわち、現在の状態をスタンバイコンピュータにコピーする）及びリスターティング（restarting:すなわち、例えば最後のチェックポイントから起こったトランザクションのログを読むことによって最後にチェックポイントされた状態から、実行を開始し、その後に新しいトランザクションの処理を開始する）が、チェックポインティング手法がハードウェア誤りを補償するためにシステムに組み込まれていたにもかかわらず、ソフトウェア誤りのおおよそ７５％から９６％の間を補償したことが報告されている。この報告での説明はテスト中に見つからなかったソフトウェア誤りが微細であり、非常に特殊な条件が誘因であるとしている。これらの条件（例えば、メモリ状態、タイミング、乱調状態(race conditions)等）は、それらを引き継いだ後では再発生しない。従って、ソフトウェア誤りは再発生しない。
【０００７】
ネットワークにおける複製の問題は、中央リソースの調停といったいくつかのサービスが、自分自身を配分に貸し出さないことにある。この種のサービスは１プロセス中に実装しなければならず、またパフォーマンス上の理由により、サービスのデータをそのスタック及びヒープに保持する必要がある。冗長化を実現するには、この種のプロセスを分散ネットワーク内部で複製しなければならない。高性能な通信制御システムにおいて、この複製は非常に少ないオーバヘッド及び複製のために発生するいかなる遅延もなく実行されねばならない。
【０００８】
（発明の概要）
従って、本発明の目的は、フォールトトレラントクライアントサーバシステムを実装するための方法及び装置を提供することにある。
【０００９】
本発明の１つの見地によれば、上述の、また別の目的はプライマリサーバ、バックアップサーバ及びクライアントを有するフォールトトレラントクライアントサーバシステムによって達成される。クライアントはプライマリサーバにリクエストを送信する。プライマリサーバはリクエストを受信し、処理する。処理にはプライマリサーバによって実行されるバックアップ処理とは独立したクライアントへの応答を含み、この応答はプライマリサーバ状態情報を含んでいる。バックアップ処理とは独立して応答を送信することによって、より高レベルの同時性(concurrence)が達成され、システムをより効率的にする。プライマリサーバはまた、バックアップサーバへの定期的なプライマリサーバ状態情報送信を含むバックアップ処理を実行する。クライアントはプライマリサーバから応答を受信し、プライマリサーバ状態情報をクライアントからバックアップサーバに送信する。
【００１０】
本発明の別の見地によれば、プライマリサーバ状態情報はプライマリサーバからバックアップサーバへの最新のプライマリサーバ状態情報の伝送以来プライマリサーバが取り扱っている全てのリクエスト−応答ペアを含む。
【００１１】
本発明のさらに別の見地によれば、プライマリサーバはプライマリサーバ状態情報を記憶手段に記憶する。プライマリサーバにおけるバックアップ処理の実行は記憶手段が所定量まで満たされたことに応答して実行されても良い。
【００１２】
別の実施例において、プライマリサーバにおけるバックアップ処理の実行は予め定めた時間間隔に基づいて周期的に実行されても良い。
【００１３】
（発明の詳細な説明）
同様の部分には同じ参照数字を付与した図面を参照して、本発明の種々の機能を説明する。
【００１４】
図１は、クライアントサーバアプリケーションにおける冗長サーバ利用を説明するブロック図である。特に、複数のクライアントアプリケーションＣが示されている。プライマリサーバＳ（１０１）は第１のプロセッサ１０３で稼働している。第１のプロセッサ１０３と別個の第２のプロセッサ１０５は、プライマリサーバＳ（１０１）と並列にバックアップサーバＳ’（１０７）を実行している。全体的には、一つが働かなくなった場合にはどのクライアントアプリケーションＣにも問題なく他方が引き継ぎできるよう、プライマリサーバＳ（１０１）及びバックアップサーバＳ’（１０７）はクライアントアプリケーションＣからの任意の特定リクエストの処理後に発生する仮想時間Ｔにおいて、同一の内部状態を有すべきである。（なぜならバックアップサーバＳ’（１０７）はプライマリサーバＳ（１０１）を後追いするため、バックアップサーバＳ’（１０７）はプライマリサーバＳ（１０１）よりも実時間において後にその仮想時間に達するからである。）複製されたサーバプロセスの存在はそのサーバを用いるクライアントアプリケーションＣからは不可視であるべきである。このような方針(strategy)を実装するには、以下の問題を解決する必要がある。
【００１５】
アドレッシング：
サービスがプライマリサーバＳ（１０１）で実行されるかバックアップサーバＳ’（１０７）（もしくは両方）で実行されるかに関わらず、クライアントアプリケーションＣは矛盾のない方法でサーバへのアドレッシングを行う必要がある。
【００１６】
複製及び同期：
故障及び修復通知のみならず、異なるクライアントアプリケーションＣからの入来リクエストはプロセッサ間の物理ネットワークの相違に起因してプライマリサーバＳ（１０１）とバックアップサーバＳ’（１０７）とに異なる順番で到達可能である。しかし、これらのリクエストは同一の順番に並び替えられねばならない。
【００１７】
故障及び修復通知：
サーバプロセスの失敗及び新しいサーバプロセスの開始は依然として稼働しているサーバによって検出されねばならない。
【００１８】
状態の転送：
失敗後のサーバプロセス再開始時、プロセッシングリクエストの開始可能となる前に稼働中のサーバが新しいサーバへ自らの内部状態を転送しなければならない。
【００１９】
上述の問題のアドレッシングにおいて、本発明の好ましい実施例は以下の目標(goals)を満足するように試みる。
・複製の問題を１度だけ解決する。複製の実装は多くの落とし穴(pitfalls)を有し、また認証(verify)するのが困難である。カバーせねばならない起こりうる故障が数多く存在する。
・少ないオーバヘッドのみを付加し、かつオーバヘッドは複製されたプロセスとの通信にのみ付加する。
・故障の場合及び新しいプロセスを再統合(reintegrating)する際の通常動作における最悪の場合の応答時間が事前にわかっており、また許容範囲に維持されること。
【００２０】
・クリティカルタイミングパスにはいかなる追加メッセージも付加しない。従来の多くの実装技術はこの目標を達成していない。例えば、プライマリサーバは第２のサーバへメッセージを送信し、応答をクライアントに送信する前に応答を得ねばならないであろう。このようなことは、付加された冗長性によってシステムの実時間応答時間を遅らせないために、回避することが好ましい。
・多くのクライアント及び動的なクライアントを取り扱う。通信アプリケーションは概して１つのサーバに対して多くの発生しうるクライアントを有する。これは、例えばサーバプロセスが失敗した場合や復旧する場合にクライアント内の情報を更新しなければならないアルゴリズムは使用できないことを意味する。また、一般にクライアントプロセスの生存時間は短い（通話中のみ存在する場合もある）。これは、サーバがクライアントを常に監視する必要のあるアルゴリズムは使用できないことを意味する。
【００２１】
プロトコルをより単純にするため、本発明の好適な実施例はいくつかの制限を課している。これら制限のいくつかはプロトコルをより汎用的にすることによって容易に解除できる。しかしながら、それらを含めることによって、関係する根本的な機構の説明が容易になる。それらの制限は、
・プライマリ及びバックアップの、２つのサーバのみが関係する。
プロトコルをより多くのサーバを含むように拡張することが可能で
あることは本技術分野の当業者には理解されるであろう。
・一時に１つの誤り、すなわち１つのクライアントもしくはサーバ
の故障に対する耐性である。システムは別の誤りが見過ごされうる
より前に、（例えばコールドスタンバイを開始することによって）
復旧せねばならない。
【００２２】
・簡単なネットワーク構成。複雑なネットワーク誤り、例えばネッ
トワークを２つに分割し、それぞれにサーバの片方が存在するよう
な場合は考慮しない。
・小さなメッセージ。バルクデータ転送や類似のデータ転送はバッフ
ァもしくはキューをオーバフローさせるであろう。
・ソフトリアルタイム応答。通常の場合（すなわち、故障したサー
バがない場合）、複製でないサーバを用いるシステムとほぼ同一の
応答時間を保証することが可能である。しかし、より長い応答時間
が故障、復旧及び再統合時には許容されねばならない。これらのよ
り長い応答時間が依然として所定の最大時間を超えないことを保証
することができる。
【００２３】
・サーバの決定論的(deterministic)なオペレーション。以下に詳
細を説明するように、バックアップサーバはプライマリサーバから
周期的に更新メッセージを受信する。バックアップサーバにおける
これらの更新メッセージの処理は、更新メッセージを送信した時点
におけるプライマリサーバの内部状態にバックアップサーバの内部
状態が到達することを保証するため、決定論的でなければならない
。サーバソフトウェアは（コールされた時に応じて異なる値を返す
）日時クロックへのコールの様な、非決定論的なシステムコールを
含むことはできない。なぜならそのようなコールはバックアップサ
ーバの内部状態をプライマリサーバの内部状態と異ならせる原因と
なりうるからである。
【００２４】
従って、バックアップサーバの状態はプライマリサーバからバッ
クアップサーバが受信した情報によって１００％特定されねばなら
ない。これは以下の２つの方法のいずれかによって達成できる。す
なわち、
ａ）プライマリサーバへ供給されるリクエストがさらにバックアッ
プサーバへも転送され、リクエストに対して同一の処理を行うこと
によってプライマリサーバと同一の内部状態に至るか、
ｂ）処理結果（すなわち、サーバの内部状態変化のみならず、プラ
イマリサーバによって生成されるクライアントへの返答）がバック
アップサーバへ送信されるかである。
【００２５】
・簡単なアプリケーションに限定する。以下に説明される独創的な
プロトコルの説明において、複製サーバは他のサーバからのサービ
スを要求できない。そのような場合を取り扱うため、プロトコルを
拡張しなければならないであろう。そのような拡張において、第２
のサーバは複製サーバからのリクエストを検出し、同一の（又は類
似の）プロトコルに従う。
【００２６】
始めに、解決すべき４つの問題について説明する。まず、それらの一つ、すなわち複製及び同期についての独創的な解決策を説明する。好ましい実施例において、複製及び同期はクライアント及びサーバ間で用いられる通信プロトコルの一部として実装される。このようなアプローチの利点は、
・実装はプロトコルの設計時にただ１回行えばよい。
・複製がアプリケーションから不可視となる。プロトコルは複製され
たサーバのアドレッシングを取り扱う。
【００２７】
望ましい複製及び同期の効率的な実装のために設計された独創的なプロトコルは、
１）２つの交換可能な実装が可能である。
ａ）通信方法のエクステンションとして実装する。これはプライマ
リサーバにおいてクライアントからのリクエストを処理するための
余分なシステムコールが不要であることを意味する。
ｂ）交換可能な方法として、プロトコルをプロトコルスタックに統
合することもできる。これはより効率的な実装を可能にする。
フォールトトレラントが既存のＯＳ上のソフトウェアのレイヤとし
て実装されている所謂”ミドルウェア”ソリューションは、第１の
方法（すなわち、交換可能な方法”ａ”）から利益を得るが、第２
の方法（すなわち、交換可能な方法”ｂ”）からは利益を受けない
であろう。
【００２８】
２）サーバ間の複製はリアルタイムクリティカルループの外で行うこと
ができる。クライアントはプライマリサーバＳ（１０１）が応答可
能になり次第応答を取得できる。
３）冗長性を維持するために必要とされる追加情報はオーバヘッドを最
小にするために応答に添付される。
【００２９】
４）バックアップサーバＳ’（１０７）への更新／心拍(Heartbeats)は
、オーバヘッドを最小化し、また障害後の復旧時間が所定の最大時
間を超えないことの保証を可能にするために周期的になされる。プ
ライマリサーバでは処理可能で、バックアップサーバでは処理でき
ないリクエストの数は、２つの周期的更新の間に到達可能な数に制
限される。
５）複製はＩ／Ｏプロセッサがメインプロセッサにオーバヘッドを全く
与えない範囲内でサポート可能である。
【００３０】
プロトコルはリクエストが処理された順番に関する情報及び、処理されたリクエストが２つの分離されたコンピュータにおける２つの独立した場所に常に保持されることを保証する。このストラテジは２つの観察(ovservations)に基づく：
１）プライマリサーバ状態の冗長なコピーは一方でフォールトトレラン
ト性を維持したまま、通常行われるよりも遅れた時間に確立される
。すなわち、従来のシステムにおいて、サーバ状態情報はプライマ
リサーバからバックアップサーバへクライアントへの応答より前に
送信される。しかし、クライアントに応答を送信する前に他のいか
なるプロセッサも結果を見ていないことから、本発明はこれが保守
的なアプローチであると認識している。その結果、リクエストを処
理する前にプライマリサーバクラッシュが起こると考えられていた
。これは、クライアントが応答を受信する時間に依存する場合であ
る。そして、これがフォールトトレラント性を有するようにするた
めにサーバ状態情報の冗長なコピーの存在を確立可能な最後の時間
である。
【００３１】
２）３つの独立したパーティが関与する：サービスをリクエストするク
ライアントアプリケーションＣ、プライマリサーバＳ（１０１）、
バックアップサーバＳ’（１０７）。任意の時間において、２つの
重畳なコピーに重要な情報(critical information)を維持すること
ができる。しかし、それらのコピーは（従来の２フェーズコミット
プロトコルにおけるように）プライマリサーバＳ（１０１）及びバ
ックアップサーバＳ’（１０７）によってのみ維持される必要はな
い。むしろ、クライアントが（一時的な）情報の保持のために使用
可能である。
【００３２】
単純なサーバアプリケーションについてのメッセージフローに基づく複製が図２に示される。クライアントアプリケーションＣがクライアントプロセッサで稼働するプロトコルスタック２０５を介してプライマリサーバ１０１へアクセスする。対応するプロトコルスタック２１５，２１５’もまたプライマリ及びバックアップサーバプロセッサＰＲＯ１，ＰＲＯ２で稼働している。リクエスト２０１がクライアントアプリケーションＣからプライマリサーバＳ（１０１）へ送信される。プライマリサーバＳ（１０１）のプロトコルスタック２１５はリクエストにシーケンス番号(sequence number)を付加し、それからリクエストを処理する。リクエストの処理結果に従って、プライマリサーバＳ（１０１）は応答メッセージ２０３を生成し、直ちにプロトコルスタック２１５を介してクライアントアプリケーションＣへ送信する。本発明の１つの見地によれば、その内容がサーバのプロトコルスタック２１５は、バックアップパス２０９を介してバックアップサーバＳ’（１０７）のプロトコルスタック２１５’と周期的に通信されるキューへ入来リクエスト２０１を記憶するという追加機能を実行する。本発明の別の見地によれば、クライアントＣへの応答メッセージ２０３はまた（最後のフロー(flush)からの）入来リクエストのシーケンスのどの位置においてクライアントのリクエスト２０１が処理されたか（すなわち、シーケンス番号）を示す情報をさらに含む。
【００３３】
クライアントアプリケーションのプロトコルスタック２０５は応答メッセージ２０３を受信すると、２つのことを行う。すなわち、１）応答メッセージ２０３をクライアントアプリケーションＣへパスし、２）応答メッセージ及び元のリクエストを例えば含んでよいメッセージ２０７をバックアップサーバのプロトコルスタック２１５’へ送信する。バックアップサーバのプロトコルスタック２１５’は、メッセージ２０７をバックアップサーバＳ’（１０７）へパスする。いくつかの実施例において、バックアップサーバのプロトコルスタック２１５’はアクノリッジ(acknowledge)メッセージ２１１をクライアントのプロトコルスタック２０５へ送信し、それによってクライアントのメッセージ受信を確認するようにしても良い。
【００３４】
クライアントアプリケーションのプロトコルスタック２０５からのバックアップサーバにおける受信情報に加え、プライマリサーバのプロトコルスタック２１５のキューが所定の値に達した時点で、又は所定時間の経過した時点で、プライマリサーバのプロトコルスタック２１５内のキューはバックアップパス２０９を介してバックアップサーバＳ’（１０７）へフラッシング(flushed)される。重要な冗長情報をバックアップサーバＳ’（１０７）へ供給するのに加え、フラッシングはバックアップサーバＳ’（１０７）にプライマリサーバＳ（１０１）が正常に動作し続けている事を伝える心拍(heartbeat)として機能する。フラッシング／心拍の間隔は故障があった際の復旧に必要な最大時間を設定する。
【００３５】
バックアップサーバＳ’（１０７）はプライマリサーバＳ（１０１）から１回もしくはそれより多い心拍の受信に誌敗すると、実行を肩代わりし、クライアントＣからのリクエスト受信を開始する。
【００３６】
復旧が可能であることを保証するため、バックアップサーバへパスすべき情報は、ａ）元のリクエスト及び、ｂ）応答メッセージに付加されたシーケンス番号である。この情報によって、バックアップサーバは（クラッシュ後に）リクエストをそれらがプライマリサーバによって処理されていたのと同じ順番になるようにソートし、同一の処理を実行することが可能になる。同一の情報がクライアントアプリケーションのプロトコルスタック２０５及びプライマリサーバのプロトコルスタック２１５の両方からバックアップサーバＳ’（１０７）へパスされても良いが、情報がプライマリサーバのプロトコルスタック２１５から入来する場合には、シーケンス番号はあまり重要でない。なぜなら一般に入来リクエストのコピーがそれらが処理された順番にパスされるからである。
【００３７】
（シーケンス番号を含む）プライマリサーバ応答メッセージ全体をバックアップサーバへパスすることによって、バックアップサーバは故障検出を改善することが可能になる。メッセージの順番をソートするためにシーケンス番号を用いることに加え、バックアップサーバＳ’（１０７）は、自分自身の応答をプライマリサーバＳ（１０１）からの応答とを比較することによって、プライマリサーバと同期していることを確かめることも可能である。しかしながら、この目的のためには、応答のチェックサムなどの代替情報をパスすれば十分であることに注意すべきである。
【００３８】
故障検出目的のため、完全な応答情報がソースのいずれかから（すなわち、クライアントＣ又はプライマリサーバＳ（１０１）からの周期的な更新を介して）パスされても、両方からパスされても良い。１つの実施例においては、クライアントのプロトコルスタック２０５を介してより長いパスを伝達されねばならない情報量を最小化するため、完全な応答情報はプライマリサーバのプロトコルスタック２１５からの周期的な更新を介してのみパスされる。
【００３９】
応答メッセージにテキストによってシーケンス情報を付加することのいくつかの代替処理が存在する。その１つは単純に処理されたリクエストのシーケンス番号を付加するというものである。他に、最新の周期的な更新以来のリクエストシーケンス全体を含ませるというものである。これらの代替処理は同一目的に役立ち、それぞれは”サーバ状態情報”と見なすことができる。なぜならそれらはそれぞれバックアップサーバＳ’（１０７）がプライマリサーバＳ（１０１）の状態と同一状態を達成するために行わねばならない行動の順番を定義するからである。
【００４０】
多くの故障事例及び本発明がそれらをどのように取り扱うかについて、以下に説明する。
応答送信前のプライマリサーバクラッシュ
この場合、クライアントＣはアクノリッジ（すなわち応答メッセージ２０３）をプライマリサーバＳ（１０１）から受信しない。それに応答して、クライアントＣのプロトコルスタック２０５は元のリクエストをプライマリ及びセカンダリサーバＳ（１０１）、Ｓ’（１０７）の両方に再送する。それ以外の場合（すなわち、故障でない場合）、クライアントアプリケーションＣはリクエストをプライマリサーバＳ（１０１）にのみ送信する。（一般にクライアントアプリケーションはこのフォールトトレラント活動(activity)に気づかないことに注意すべきである。なぜなら、クライアントアプリケーションＣは１つの論理サーバに対してのみアドレス指定するからである。アドレス変換及び２つのサーバＳ（１０１）、Ｓ’（１０７）への通信は、クライアントプロセッサ内部のプロトコルスタック２０５が行う。）セカンダリサーバＳ’（１０７）がプライマリサーバＳ（１０１）からの心拍を受信し損ねた場合、セカンダリサーバＳ’（１０７）が処理を引き継ぐ。それ以外の場合、セカンダリサーバＳ’（１０７）はクライアントＣからのリクエストを単に破棄する。
【００４１】
応答送信後かつバックアップサーバへ情報をフラッシング前におけるプライマリサーバクラッシュ
最後の応答を送信した時点で存在していた状態にバックアップサーバＳ’（１０７）を更新するのに必要な情報はクライアントのプロトコルスタック２０５’から供給される更新メッセージから読み出すことが可能である。プライマリサーバＳ（１０１）からクライアントＣへの”応答パス”におけるメッセージはバックアップサーバＳ’（１０７）への更新情報のみならずクライアントアプリケーションへの応答も含んでいる。クライアントアプリケーションがクライアントＣから受信する必要のあるのは追加の更新情報ではなく、応答情報のみである。図２に示すように、更新情報はクライアントのプロトコルスタック２０５からバックアップサーバＳ’（１０７）へ（バックアップサーバのプロトコルスタック２１５’を介して）転送される。この更新情報は他の場合にはバックアップサーバＳ’（１０７）がプライマリサーバＳ（１０１）によって直接通信される周期的更新によって受信する情報と同一である。いくらかの余分な情報をすでに存在しているメッセージに付加するコストはそのための余分なメッセージを送信しなければならない場合と比較して小さい。
【００４２】
最初 (initial) のリクエスト送信後のクライアントクラッシュ
この場合、バックアップサーバＳ’（１０７）は自分自身を更新するための情報をプライマリサーバがキューをフラッシングする際に受信する。
【００４３】
プライマリシステムクラッシュ
プライマリサーバＳ（１０１）及び同一のプロセッサ１０３で実行されていた全てのクライアントは失われる。バックアップサーバＳ’（１０７）は最後にフラッシングされたキューから残りのコマンドを実行し、プライマリサーバのプロセッサ１０３の外部で実行されているクライアントへの最後の応答によって与えられた位置までの更新を得る。
【００４４】
メッセージ損失 (loss)
すぐにアクノリッジを得なかったメッセージは受信プロセス（又はプロセッサ）が故障であると見なすより前に、１度もしくは２度再送信される。
【００４５】
以下、図３を用いてクライアントのプロトコルスタック２０５をより詳細に説明する。ステップ３０１において、クライアントアプリケーションの実行がプライマリサーバへ送信されるべきリクエストの要因となる。ステップ３０２で、そのリクエストはプロトコルスタック２０５で処理され、プライマリサーバへ送信される。プロトコルはメッセージ損失に際し再送信を実行し、そのメッセージのコピーを再送信を行うために保持する。ステップ３０３で、プライマリサーバから応答が帰ってくる。応答はクライアントアプリケーションプロセスに遅滞なく送り返される。リクエストのコピーと関連する応答は複製プロトコルのために保持される。この実施例ではプライマリサーバが比較的早く応答すると仮定しているため、プライマリサーバからクライアントへ送信された別個のアクノリッジは存在しない。すなわち、プライマリサーバから返された応答は応答として十分に機能する。比較的遅いプライマリサーバを含む他の実施例においては、プロトコルにプライマリサーバからクライアントへ応答を送信する前に送信される別個のアクノリッジを含ませることが必要であろう。
【００４６】
ステップ３０４において、アプリケーションプロセスは行われるべき複製を待つことなく実行を回復(resume)可能である。ステップ３０５で、プロトコルスタック２０５はリクエスト及びキュー内の応答バックアップサーバへ複製されていないリクエストのために指定された応答を保存する。
【００４７】
ステップ３０６において、クライアントは元のリクエストとバックアップサーバへの応答を含んだメッセージ送信する。これに応答して、クライアントのメッセージが正常受信されたことを確認するため、バックアップサーバはアクノリッジ（ステップ３０７）をクライアントに返信する。ここで、アクノリッジを用いない場合、バックアップサーバから以外の応答は予期されていないため、クライアントは自分のメッセージが受信されたかどうかを知る他の手段がないことに注意すべきである。
【００４８】
本明細書の冒頭において他のいくつかの問題点を説明した。すなわち、故障及び修復通知及び状態送信である。以下、これら問題点に対する本発明の解決方法を説明する。
【００４９】
故障及び修復通知に関して、プライマリサーバ及びセカンダリサーバ間の通信はまた心拍として機能する。セカンダリサーバが規則的に更新されないと、セカンダリサーバは未処理のクライアントタイムアウトを受信するのに十分な時間待ち、それから処理を引き継ぐ。サーバプロセスが再起動した場合、セカンダリサーバはアクティブなプライマリサーバがあるかどうかをチェックする。
【００５０】
状態転送(State Transfer)は、故障したサーバが再起動する際に用いられる。稼働中サーバの状態はそれらのサーバが再びプライマリ／バックアップペアとして作動可能になる前に再起動するサーバへコピーされなければならない。この状態転送とシステムソフトウェア及びハードウェアアップグレード時に必要な種類の状態転送との間には根本的相違はない。また、現代のプロセッサはハードウェア故障の数が少なく、状態転送はシステムアップグレード用に最適化するべきである。
【００５１】
ここで、本発明の１つの見地が、故障及び修復通知だけでなく異なるクライアントからのリクエストが異なる順番でプライマリサーバＳ（１０１）及びバックアップサーバＳ’（１０７）に到達可能であっても、それらを同一の順番に並び替えることを必要としていたことを思い出すであろう。従って、いくつかの実施例において、因果依存(causal dependency)（本明細書では”因果的配列”(causal ordering)とも言う）を実施するための機構を提供することは有益であろう。本質的に、これはメッセージ処理をそれらが受信された厳密な順番ではなく、論理的に発行された順番で参照する。因果的配列についてのより完全な説明は、米国ニューヨーク州Ithacaのコーネル大学によって開発されたISISツールキット(ISIS tool kit)に関して見つけることができるであろう。その説明はIEEE COMPUTER COCIETY PRESSによって1994年に出版された、K.P.Birman及びR.van Renesseによる「ISISツールキットを用いた信頼性の高い分散コンピューティング(Reliable Distributed Computing with the ISIS tool kit)」(ISBN 0-8186-5342-6)に見つけることができる。因果的配列は少ないオーバヘッドで実装可能であり、高度の同時発生(concurrence)を許すことによってシステム効率を向上可能である。
【００５２】
図４ａ及び４ｂはこの効率向上を説明する。図４ａにおいて、プロセッサＰｒｏ１がリソースハンドラであるＰｒｏ２にリソース要求を送信する（ステップ４０１）。基本システム(underlying system)において因果的配列をサポートしない場合、Ｐｒｏ２はリソースＰｒｏ３にそれを初期化するためのメッセージを送信しなければならない（ステップ４０２）。リソースがレディ状態であることを応答してきた（ステップ４０３）後で、Ｐｒｏ２はＰｒｏ１へリソースが利用可能であることを通知する応答の送信を許可される（ステップ４０４）。そして、プロセッサＰｒｏ１はリソースＰｒｏ３にメッセージを送信可能となる（ステップ４０５）。個々のプロセッサの振る舞いが先に送られたメッセージより前に後で送られたメッセージの受信（及び、結果としての処理）を行わないように予定された制限によって強制されていることに気づくであろう。
【００５３】
次に、基本システムが因果的配列をサポートする例を示す図４ｂを参照する。この例もまた、プロセッサＰｒｏ１がリソースの供給をリソースハンドラＰｒｏ２に送信することから開始する（ステップ４０６）。しかし、今回リソースハンドラＰｒｏ２はＰｒｏ３からの応答を待つ必要はない。その替わり、Ｐｒｏ２はリソースが利用可能であることを通知する応答を直ちにＰｒｏ１へ送信する（ステップ４０７）。ほぼ同時に、Ｐｒｏ２はリソースＰｒｏ３に初期化メッセージを送信する（ステップ４０８）。これは同時に行われるため、因果的配列を用いない例（図４ａ）よりもかなり早く、プロセッサＰｒｏ１は自らのメッセージをリソースＰｒｏ３へ送信可能になる（ステップ４０９）。因果的配列はＰｒｏ３がＰｒｏ１からのメッセージを受信する前に初期化メッセージを処理することを保証するため、Ｐｒｏ２からのメッセージが遅れたとしても（ステップ４０８’で示す）何の問題も発生しない。
【００５４】
クライアントが複製されたサーバをコールする限られた事例のために、完全な因果的配列モデルを実装する必要はない。なぜなら、そのような事例においては、シーケンス番号があれば複製されたサーバが正しい順番でリクエストを処理することができるからである。しかし、複製されたサーバに他の複製されたサーバのコールを許すといったように、プロトコルがより汎用的な事例に拡張される場合、完全なモデルが必要である。
【００５５】
本発明を具体的な実施例に関して説明してきたが、本技術分野の当業者は上に説明された好ましい実施例以外の特定の形式において本発明を実施可能であることを容易に理解するであろう。これは本発明の精神から離れることなく実施可能である。好ましい実施例は単なる例証であって、いかなる方法によっても限定的に解釈されるべきではない。本発明の範囲は上述の説明ではなく、添付された請求の範囲によって与えられ、また請求の範囲に含まれる全ての変形物及び等価物は本発明の範囲に含まれることが意図されている。
【図面の簡単な説明】
【図１】クライアントサーバアプリケーションにおける冗長サーバの使用を説明するブロック図である。
【図２】フォールトトレラントクライアントサーバアプリケーションにおけるメッセージフローを説明する図である。
【図３】本発明の１つの見地に従った、クライアント、プライマリサーバ及びバックアップサーバの間におけるメッセージのフローを説明する図である。
【図４ａ】プロセス間通信に因果的配列(causal ordering)を用いることにより達成される効率性の向上を説明する図である。
【図４ｂ】プロセス間通信に因果的配列(causal ordering)を用いることにより達成される効率性の向上を説明する図である。

Claims

プライマリサーバと、
バックアップサーバ及び、
クライアントを有するフォールトトレラントクライアントサーバシステムであって、
前記クライアントが、
リクエストを前記プライマリサーバに送信する手段と、
前記プライマリサーバからプライマリサーバ状態情報を含む応答を受信する手段と、
前記プライマリサーバ状態情報を前記バックアップサーバに送信する手段とを有し、
前記プライマリサーバが、
前記リクエストを受信し、処理する手段と、
前記リクエストに応答して、バックアップ処理とは独立して前記クライアントに前記プライマリサーバ状態情報を含む応答を送信する手段と、
前記バックアップサーバへの前記プライマリサーバ状態情報の周期的な送信を含むバックアップ処理を実行する手段とを有し、
前記バックアップサーバが、
前記プライマリサーバからの前記プライマリサーバ状態情報を受信する手段と、
前記クライアントから前記プライマリサーバ状態情報を受信する手段とを有することを特徴とするフォールトトレラントクライアントサーバシステム。
前記プライマリサーバ状態情報が、前記プライマリサーバから前記バックアップサーバへ最後にプライマリサーバ状態情報を伝送してから前記プライマリサーバが取り扱いした全てのリクエスト−応答ペアを含むことを特徴とする請求項１記載のフォールトトレラントクライアントサーバシステム。
前記プライマリサーバ状態情報が応答から得たチェックサムを含むことを特徴とする請求項１記載のフォールトトレラントクライアントサーバシステム。
前記プライマリサーバの前記バックアップ処理を実行する手段が、予め定めた時間間隔に基づき周期的に活性化されることを特徴とする請求項１記載のフォールトトレラントクライアントサーバシステム。
前記プライマリサーバが、前記プライマリサーバ状態情報を記憶する手段をさらに有し、
前記プライマリサーバのバックアップ処理を実行する手段が、前記プライマリサーバ状態情報を記憶する手段が予め定めた量満たされたことに応答して活性化されることを特徴とする請求項１記載のフォールトトレラントクライアントサーバシステム。
プライマリサーバと、バックアップサーバ及びクライアントを有するフォールトトレラントクライアントサーバシステムの操作方法であって、
前記クライアントから前記プライマリサーバへリクエストを送信するステップと、
前記プライマリサーバにおいて、前記リクエストを受信し、前記プライマリサーバによって実行される全てのバックアップ処理とは独立して、プライマリサーバ状態情報を含む応答を前記クライアントに送信する処理を含む処理を行うステップと、
前記プライマリサーバにおいて、前記バックアップサーバへの前記プライマリサーバ状態情報の周期的な送信を含むバックアップ処理を実行するステップと、
前記クライアントにおいて、前記プライマリサーバからの前記応答を受信するステップ及び、
前記クライアントから前記バックアッププロセッサへ前記プライマリサーバ状態情報を送信するステップとを有することを特徴とするフォールトトレラントクライアントサーバシステムの操作方法。
前記プライマリサーバ状態情報が、前記プライマリサーバから前記バックアップサーバへ最後にプライマリサーバ状態情報を伝送してから前記プライマリサーバが取り扱いした全てのリクエスト−応答ペアを含むことを特徴とする請求項６記載の方法。
前記プライマリサーバ状態情報が応答から得たチェックサムを含むことを特徴とする請求項６記載の方法。
前記プライマリサーバにおけるバックアップ処理実行ステップが、予め定めた時間間隔に基づき周期的に実行されることを特徴とする請求項６記載の方法。
前記プライマリサーバが、前記プライマリサーバ状態情報を記憶手段に記憶するステップをさらに実行し、
前記プライマリサーバにおけるバックアップ処理実行ステップが、前記記憶手段が予め定めた量満たされたことに応答して実行されることを特徴とする請求項６記載の方法。