JP2011518486A - サーバ故障時におけるクライアント・アプリケーションのより速い回復を可能にするための方法 - Google Patents

Abstract

【課題】 サーバ故障が発生した場合の回復時間を改善するためのシステム及び方法を提供する。
【解決手段】 クライアント・ノード上で稼働するクライアント・アプリケーションのためのサーバとして機能しているサーバ・ノードの故障の通知をクライアント・アプリケーションに送信することによって、マルチノード・データ処理システムにおけるフォールオーバー状態の回復時間を改善するためのシステム及び方法が提供される。本発明においては、この通知は、サーバ・ノードのためのバックアップとして機能するフォールオーバー・ノードによって提供される。クライアント・アプリケーションは、サーバからの応答を長時間受信しないときには、サーバが故障したと見なし、再接続を開始する。本発明は、サーバ故障についてクライアント・アプリケーションに積極的に通知するシステム・レベル・ソフトウェアを有することにより、クライアント・アプリケーションによって開始された再接続を早める。これにより、クライアント・アプリケーションのためのより速い回復がもたらされる。
【選択図】 図１

Description

本発明は、一般に、マルチノード・データ処理システム及び方法を対象とする。より具体的には、本発明は、サーバ故障時における回復時間を改善するためのシステム及び方法を対象とする。さらにより具体的には、本発明は、故障ノードによる性能不足に基づく故障の判定を待つのではなく、フォールオーバー・ノードが故障通知を提供するシステムを対象とする。本明細書及び特許請求の範囲において用いられる場合、「ノード」及び「サーバ」という用語は同じ意味で用いられるが、サーバは幾つかのノードを含む場合があることを理解されたい。

ＨＡＣＭＰ（高可用性クラスタ管理プログラム）のようなクラスタウェア・アプリケーションの中には、一次サーバが故障したときにバックアップ・サーバに自動的に再接続するほどインテリジェントなクライアント・アプリケーションが多数存在する。これは、クライアントが対話していた一次サーバのＩＰ（インターネット・プロトコル）アドレスをバックアップ・サーバに動的に移動させることによって可能になる。従って、サーバ故障に応答してクライアント・アプリケーションを打ち切る及び／又は再起動する必要はない。クラスタウェアのこの能力は、本明細書では「フォールオーバー」と呼ぶ。しかしながら、問題は、一次サーバが故障した直後、クライアントとサーバとの間に存在するＴＣＰ（伝送制御プロトコル）接続が終了するまでに、ある程度時間がかかることである。これは、主に、クライアント・アプリケーションがサーバ故障に気付かず、そのため、クライアント・アプリケーションは、ＴＣＰ再送カウンタが満了するまで再送し続け、最後にＴＣＰ接続を終了させるからである。従って、クライアント・アプリケーションが、バックアップ・サーバへの再接続を試みる前に、サーバ故障イベントを認識するのにかなり時間がかかることがわかる。

従って、上記から、当技術分野において、本明細書の上記で説明された欠点及び制約を克服する必要性が存在することがわかる。

上述された遅延は、クライアントに対して適切な時期に故障イベントを通知することによって回避される。クライアントは、サーバ故障についてのこの通知を受信するとすぐに、再接続することが好ましい。本発明は、クライアント・アプリケーションによるクラスタ内の１つ又は複数のバックアップ・サーバへの再接続のプロセスを早めるための機構を提供することが好ましい。サーバ（故障したと推定されるノード）とクライアントとの間に存在するＴＣＰ接続の全てを迅速に終了するために、クライアントは、サーバが故障するとすぐに、そのＴＣＰ接続についてのＲＳＴ（リセット・パケット）を受信することが好ましい。このＲＳＴパケットが期待されるノードが故障したかどうかにかかわらず、本発明の方法は、このＲＳＴパケットを依然として生成することが好ましい。これを実現するために、フォールオーバーが発生するとすぐに、フォールオーバー・ノード（バックアップ・サーバ）がこのＲＳＴパケットをクライアントに送信することが好ましい。実際には、フォールオーバー・ノードは、クライアントに対して故障ノードであるように見せかける。

本発明の一実施形態によると、フォールオーバー状態の回復を改善するための方法は、クライアント・ノード上で稼働するクライアント・アプリケーションのためのサーバとして機能するサーバ・ノードの故障の通知をクライアント・アプリケーションに送信するステップを含む。この通知は、サーバ・ノードのためのバックアップとして機能するフォールオーバー・ノードによって提供される。

好ましくは、フォールオーバー・ノードは、故障の通知を送信するためにサーバ・ノードになりすます。好ましい実施形態によると、データ・パケットが、クライアント・アプリケーションから受信される。このパケットにアクセスして伝送情報を見つけ出し、この伝送情報を用いて、サーバ・ノードの故障の通知をクライアント・アプリケーションに送信する。

好ましい実施形態によると、データ・パケットは、サーバ・ノードに対するデータ・パケットの最初の伝送の確認応答がクライアント・アプリケーションによって受信されなかったときに、クライアント・アプリケーションによって再送されたものである。一実施形態においては、フォールオーバー・ノードは、フォールオーバー・ノードがサーバ・ノードを引き継いだことをクライアント・ノードに知らせる。

さらなる特徴及び利点が、本発明の技術を通して理解される。本発明の他の実施形態及び態様は、本明細書において詳細に説明され、特許請求の範囲に記載される発明の一部とみなされる。

本明細書における本発明の種々の実施形態によって示される好ましい対象の記述は、これらの対象のいずれか又は全てが、本発明の最も一般的な実施形態又は本発明のより特定的な実施形態のいずれかにおいて、個別に又はまとめて本質的な特徴として提示されることを暗示又は示唆することを意味するものではない。

本発明が用いられる基本的なノード構成環境の間の接続を示すブロック図であり、本発明の好ましい実施形態の動作において生じる一連の事象も示す。 本発明の好ましい実施形態のプロセスにおいて典型的に生じる一連のイベントを示すフロー・チャートである。

本発明の好ましい実施形態を、単なる例として図面を参照しながらここで説明する。

前述した通り、クライアントは、例えばＴＣＰプロトコルを用いてサーバと通信することができる。サーバが故障した場合に、クライアントは、故障が発生したことに気付かない場合がある。クライアントが送出したパケットに対する何らかの確認応答がない場合には、クライアントは、ＴＣＰ再送カウンタが満了するまで再送し続けることになる。これは、しばらく時間がかかる場合もある。従って、クライアントとサーバとの間の接続を強制的に終了させてリセットすることが望ましい。ＴＣＰプロトコルは、ＲＥＳＥＴ（ＲＳＴ）オプションを有する。２つの主体（party）が通信しているときに、第１の主体が、他方の主体が通信を停止したことに気付いた場合には、第１の主体は、ＲＳＴを送信して他方の主体に強制的に接続をリセットさせることができる。しかしながら、ここで大事な点は、クライアントは、かなり長い時間、問題が発生していることに気付かない場合があることである。クライアントは、問題が発生していることに最終的に気付いたときに、フォールオーバー・ノードに再接続を試みて、再接続されることになる。

好ましい実施形態によると、本発明は、クライアントが通信しているサーバ・ノードを監視するバックアップ（又はフォールオーバー）サーバを利用する。フォールオーバー・ノードは、サーバ・ノードが故障したことに気付いたときに、サーバ・ノードのアドレスを引き継ぐ。この時点で、バックアップ・サーバは、引き継がれたＩＰアドレス上の全てのトラフィックを見て、どのトラフィックが、サーバ・ノード上で稼働するように用いられていたがＩＰアドレスとともにバックアップ・ノード上で再起動されたアプリケーションに向かう（即ち、アドレス指定される）ものであるかを調べる。バックアップ・サーバは、いずれかのトラフィックを見つけた場合には、サーバ・ノードに「なりすます（masquerades）」。

しかしながら、フォールオーバー・ノードは、サーバ・ノードによって維持されていた接続に関する知識を持っていない。フォールオーバー・ノードは、どれがそれらの接続を維持していたのか、又は、それらがどのようなタイプの接続を維持していたのかを知らない。従って、フォールオーバー・ノードは、サーバ・ノードがどれと接続していたのかを推定し、次に、このようなクライアントに、フォールオーバー・ノードに接続するように（ＲＳＴオプションを用いて）「促す」ことができる必要がある。当然ながら、これは、サーバ・ノードに再接続されていると思っているこのようなクライアントのいずれにとっても透過的である。

このように機能させるためには、クライアントは、ＲＳＴパケットがサーバ・ノードから来ていることを信じる必要がある。ＴＣＰ接続においては、すべてのパケットは、受信機において伝送の最後にデータが適切に並べられることを保証するシーケンス番号及び「ＡＣＫ」番号を有する。いずれかの時点で、ＴＣＰは、正しくないシーケンス番号又はＡＣＫ番号を持つパケットを受信した場合には、直ちにそのパケットを廃棄する。従って、いずれかのアプリケーション「Ａ」が、他の２つのアプリケーション「Ｂ」と「Ｃ」との間に存在するＴＣＰ接続上でパケットを送信することができるように、アプリケーション「Ａ」は、クライアントに送信されるＴＣＰシーケンスにおける次のパケットのためのシーケンス番号、ＡＣＫ番号及びＴＣＰヘッダ情報を見つけ出さなければならない。

同様に、バックアップ・サーバ（フォールオーバー・ノード）は、ＲＳＴ（リセット）パケットをクライアントに送信することができるように、ＲＳＴパケットのための適切なＴＣＰヘッダ情報を見つけ出さなければならない。ＴＣＰ接続においては、通信している主体のいずれかが、ＦＩＮパケット（これは、ＴＣＰにおいて伝送の終了を示すために用いられる）又はＲＳＴパケットを送信することによって接続を終了させることなく停止したときには、他方の主体は、再び古いパケットを再送し始める。

好ましい実施形態においては、フォールオーバー・ノードは、サーバのアドレスを引き継いでいる。従って、フォールオーバー・ノードは、故障ノードからＩＰアドレスを（有効にすることにより）獲得するとすぐに、幾つかの再送パケットをクライアントから受信する。バックアップ・サーバ（フォールオーバー・ノード）は、クライアントから受信したばかりの再送パケットを用いて、シーケンスにおける次のパケットのＴＣＰヘッダ情報を取得する。このＴＣＰヘッダ情報によって、バックアップ・サーバは、例えば、ＲＳＴパケットがどのシーケンス番号を用いるべきか、及びＲＳＴパケットはどこへ送信されるべきかを決定することができる。

生のＩＰソケットを用いると、いずれのアプリケーションも、パケットを自作して、２つの異なるアプリケーション間に存在するＴＣＰ接続上でそれを送信することができる。この新たに作られたパケットは、受信機がそのパケットをピア・アプリケーションによって送信されたものであると考えるので、受信機にとっては本物のパケットのように見える。本発明においては、ＨＡＣＭＰのようなクラスタウェアは、生のＩＰソケットを用いてＲＳＴパケットを自作し、それをクライアントに送信する。このＲＳＴパケットは、古いＴＣＰ接続を直ちに中断し、従って、クライアントは、迅速に再接続することができる。

本発明においては、既存のクライアント・アプリケーション又はＴＣＰスタック自体のどちらも変更する必要はない。ＴＣＰ接続が、ＴＣＰ接続の時間切れによって終了するか、ＲＳＴパケットによって終了するかにかかわりなく、クライアント・アプリケーションは、それを突然の終了と見なし、再接続を試みる。

好ましい実施形態によると、図１は、本発明を用いた場合の一連のイベント又は状況を示す。具体的には、円「１」は、クライアント・ノード１００がサーバ・ノード２００と通信している初期状態を示す。円「２」は、サーバ・ノード２００が故障し、フォールオーバー・ノード３００へのフォールオーバーが存在するイベントを示す。円「３」は、フォールオーバー・ノード３００が、クライアント・ノード１００に、サーバ・ノード２００が故障したこと及びフォールオーバー・ノード３００が通信機能を引き継いでいることを伝えるイベントを示す。円「４」は、クライアント・ノード１００が現在はフォールオーバー・ノード３００に接続されている最終状態を示す。例示されたプロセスによって、アプリケーション・レベルのソフトウェアが典型的にはノード故障に気付かないため着信するのに時間がかかる、ノード２００に関する故障の表示を、クライアント・ノード１００上で稼働するアプリケーションが待つ必要がなくなる。システム・レベルの速さ及び優先度で実行されるフォールオーバー・プロセスは、より高速で行われ、ＴＣＰ接続のプロトコル構造に伴うこの事実によって、クライアント・ベースのサーバ・アプリケーションに対するより高速の通知が可能になる。

図２は、本発明のプロセスにおいて行われる典型的な一連のイベントを示す。プロセスは、サーバ・ノード２００の故障によって開始される（ステップ１０１）。システム・レベルのソフトウェアは、相対的に高速にこの故障を検出し、フォールオーバー（又は、バックアップ）ノード３００へフォールオーバーを行う（ステップ１０２）。フォールオーバー・ノード３００は、次に、クライアント・ノード１００に通知を行う（ステップ１０３）。クライアント・ノード１００は、次に、ノード２００への接続を終了する（ステップ１０４）。

本発明はまた、本明細書に記載されたプロセスを実現するための機械可読命令の形態のソフトウェアを含む。さらに、本発明は、記載されたプロセスを実現するためにメモリ内部に配置されたこのような命令を有するデータ処理システムを含む。

本発明は、本発明の特定の好ましい実施形態に従って本明細書において詳細に説明されてきたが、当業者ならば、本発明に多くの修正及び変更をもたらすことができる。従って、特許請求の範囲は、本発明の主旨及び範囲内にあるものとして全てのこうした修正及び変更を含むように意図される。

Claims (42)

1. フォールオーバー状態の回復を改善するための方法であって、
   クライアント・ノード上で稼働するクライアント・アプリケーションのためのサーバとして機能しているサーバ・ノードの故障の通知を前記クライアント・アプリケーションに送信するステップであって、前記通知は、前記サーバ・ノードのためのバックアップとして機能するフォールオーバー・ノードによって提供される、ステップ、
   を含む方法。
2. 前記サーバ・ノードへの接続を終了するステップをさらに含む、請求項１に記載の方法。
3. 最初は前記サーバ・ノードと関連付けられていたＩＰアドレスを前記フォールオーバー・ノードにおいて有効にするステップをさらに含む、請求項１又は請求項２に記載の方法。
4. 前記フォールオーバー・ノードにおいて前記クライアント・ノードの再送パケットを受信するステップをさらに含む、請求項３に記載の方法。
5. 前記フォールオーバー・ノードにおいてＴＣＰヘッダ情報を取得するステップをさらに含む、請求項４に記載の方法。
6. 前記ヘッダ情報は、パケットのシーケンス番号を含む、請求項５に記載の方法。
7. 前記フォールオーバー・ノードにおいてリセット・パケットを構成するステップをさらに含む、請求項５又は請求項６に記載の方法。
8. 前記リセット・パケットの構成は生のソケットを用いる、請求項７に記載の方法。
9. 前記リセット・パケットを前記クライアント・ノード上で稼働する前記アプリケーションに伝送するステップをさらに含む、請求項７又は請求項８に記載の方法。
10. 前記クライアント・ノードから前記サーバ・ノードへの接続を終了するステップをさらに含む、請求項７、請求項８又は請求項９に記載の方法。
11. 前記アプリケーションによって再接続を試みるステップをさらに含む、請求項１０に記載の方法。
12. 前記サーバ・ノード及び前記クライアント・ノードは、伝送制御プロトコルを介して通信する、前記請求項のいずれかに記載の方法。
13. 前記フォールオーバー・ノードは、前記サーバ・ノードが故障したことを、前記クライアント・ノード上で稼働する前記アプリケーションに知らせる、前記請求項のいずれかに記載の方法。
14. 前記フォールオーバー・ノードは、前記フォールオーバー・ノードが前記サーバ・ノードを引き継いだことを前記クライアント・ノードに知らせるように動作可能である、請求項１３に記載の方法。
15. 前記サーバ・ノードの故障によって開始される、前記請求項のいずれかに記載の方法。
16. 前記通知は、伝送制御プロトコル接続を通して提供される通知より早く提供される、前記請求項のいずれかに記載の方法。
17. 前記フォールオーバー・ノードは、前記故障の通知を送信するために前記サーバ・ノードになりすまし、
    前記クライアント・アプリケーションからデータ・パケットを受信するステップと、
    前記データ・パケットにアクセスして伝送情報を見つけ出すステップと、
    を含み、
    故障の通知を送信する前記ステップは、前記伝送情報を用いて前記サーバ・ノードの故障の通知を前記クライアント・アプリケーションに送信するステップを含む、前記請求項のいずれかに記載の方法。
18. 前記データ・パケットは、前記サーバ・ノードに対する前記データ・パケットの最初の伝送の確認応答が前記クライアント・アプリケーションによって受信されなかったときに、前記クライアント・アプリケーションによって再送されたものである、請求項１７に記載の方法。
19. クライアント・ノード上で稼働するクライアント・アプリケーションのためのサーバとして機能しているサーバ・ノードの故障の通知を前記クライアント・アプリケーションに送信するためのプログラム命令を、少なくとも３つのノードについてのメモリ内に含む、前記少なくとも３つのノードを含むマルチノード・データ処理システムであって、前記通知は、前記サーバ・ノードのためのバックアップとして機能するフォールオーバー・ノードによって提供される、システム。
20. 前記サーバ・ノードへの接続を終了するための手段をさらに含む、請求項１９に記載のシステム。
21. 最初は前記サーバ・ノードと関連付けられていたＩＰアドレスを前記フォールオーバー・ノードにおいて有効にするための手段をさらに含む、請求項１９又は請求項２０に記載のシステム。
22. 前記フォールオーバー・ノードにおいて前記クライアント・ノードの再送パケットを受信するための手段をさらに含む、請求項２１に記載のシステム。
23. 前記フォールオーバー・ノードにおいてＴＣＰヘッダ情報を取得するための手段をさらに含む、請求項２２に記載のシステム。
24. 前記ヘッダ情報は、パケットのシーケンス番号を含む、請求項２３に記載のシステム。
25. 前記フォールオーバー・ノードにおいてリセット・パケットを構成するための手段をさらに含む、請求項２３又は請求項２４に記載のシステム。
26. 前記リセット・パケットの構成は生のソケットを用いる、請求項２５に記載のシステム。
27. 前記リセット・パケットを前記クライアント・ノード上で稼働する前記アプリケーションに伝送するための手段をさらに含む、請求項２５又は請求項２６に記載のシステム。
28. 前記クライアント・ノードから前記サーバ・ノードへの接続を終了するための手段をさらに含む、請求項２５、請求項２６又は請求項２７に記載のシステム。
29. 前記アプリケーションによって再接続を試みるための手段をさらに含む、請求項２８に記載のシステム。
30. 前記サーバ・ノード及び前記クライアント・ノードは、伝送制御プロトコルを介して通信する、請求項１９から請求項２９までのいずれかに記載のシステム。
31. 前記フォールオーバー・ノードは、前記サーバ・ノードが故障したことを、前記クライアント・ノード上で稼働する前記アプリケーションに知らせる、請求項１９から請求項２９までのいずれかに記載のシステム。
32. 前記フォールオーバー・ノードは、前記フォールオーバー・ノードが前記サーバ・ノードを引き継いだことを前記クライアント・ノードに知らせるための手段を含む、請求項３１に記載のシステム。
33. 前記方法は、前記サーバ・ノードの故障によって開始される、請求項１９から請求項３２までのいずれかに記載のシステム。
34. 前記通知は、伝送制御プロトコル接続を通して提供される通知より早く提供される、請求項１９から請求項３３までのいずれかに記載のシステム。
35. 前記フォールオーバー・ノードは、前記故障の通知を送信するために前記サーバ・ノードになりすまし、
    前記クライアント・アプリケーションからデータ・パケットを受信するための手段と、
    前記データ・パケットにアクセスして伝送情報を見つけ出すための手段と、
    を含み、
    故障の通知を送信するための前記手段は、前記伝送情報を用いて前記サーバ・ノードの故障の通知を前記クライアント・アプリケーションに送信するための手段を含む、請求項１９から請求項３４までのいずれかに記載のシステム。
36. 前記データ・パケットは、前記サーバ・ノードに対する前記データ・パケットの最初の伝送の確認応答が前記クライアント・アプリケーションによって受信されなかったときに、前記クライアント・アプリケーションによって再送されたものである、請求項３５に記載のシステム。
37. 前記サーバ・ノードと、前記クライアント・ノード上で稼働する前記アプリケーションとは、最初は伝送制御プロトコル接続を通して接続される、請求項１９から請求項３６までのいずれかに記載のシステム。
38. クライアント・ノード上で稼働するクライアント・アプリケーションのためのサーバとして機能しているサーバ・ノードの故障の通知を前記クライアント・アプリケーションに送信するための命令を含む機械可読媒体であって、前記通知は、前記サーバ・ノードのためのバックアップとして機能するフォールオーバー・ノードによって提供される、機械可読媒体。
39. 前記サーバ・ノードと、前記クライアント・ノード上で稼働する前記アプリケーションとは、最初は伝送制御プロトコル接続を通して接続される、請求項３８に記載の機械可読媒体。
40. 前記フォールオーバー・ノードは、前記故障の通知を送信するために前記サーバ・ノードになりすまし、
    前記クライアント・アプリケーションからデータ・パケットを受信するための命令と、
    前記データ・パケットにアクセスして伝送情報を見つけ出すための命令と、
    を含み、
    故障の通知を送信するための前記命令は、前記伝送情報を用いて前記サーバ・ノードの故障の通知を前記クライアント・アプリケーションに送信するための命令を含む、請求項３８又は請求項３９に記載の機械可読媒体。
41. 前記データ・パケットは、前記サーバ・ノードに対する前記データ・パケットの最初の伝送の確認応答が前記クライアント・アプリケーションによって受信されなかったときに、前記クライアント・アプリケーションによって再送されたものである、請求項４０に記載の機械可読媒体。
42. コンピュータ上で稼働するときに、請求項１から請求項１８までのいずれかに記載の方法を行うように適合されたプログラム・コード手段を含む、コンピュータ・プログラム。

Images