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

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (13)

1. フォールオーバー状態の回復を改善するための方法であって、
   最初はサーバ・ノードと関連付けられていたＩＰアドレスをフォールオーバー・ノードにおいて有効にするステップと、
   クライアント・ノード上で稼働するクライアント・アプリケーションのためのサーバとして機能しているサーバ・ノードの故障の通知を前記クライアント・アプリケーションに送信するステップであって、前記通知は、前記サーバ・ノードのためのバックアップとして機能するフォールオーバー・ノードによって提供される、前記送信するステップと、
   前記フォールオーバー・ノードにおいて前記クライアント・ノードの再送パケットを受信するステップと、
   前記フォールオーバー・ノードにおいてリセット・パケットを構成するステップであって、前記リセット・パケットは、前記再送パケットにおける前記クライアント・ノードのＴＣＰヘッダ情報を取得し、これを用いて構成され、前記クライアント・ノードと前記サーバ・ノードとの間の接続の終了を促す、前記構成するステップと、
   前記リセット・パケットを前記クライアント・ノード上で稼働する前記クライアント・アプリケーションに伝送するステップと、
   を含む方法。
2. 前記クライアント・ノードが前記サーバ・ノードへの接続を終了するステップをさらに含む、請求項１に記載の方法。
3. 前記ヘッダ情報は、パケットのシーケンス番号を含む、請求項１に記載の方法。
4. 前記リセット・パケットの構成はＩＰソケットを用いる、請求項１に記載の方法。
5. 前記クライアント・ノードから前記サーバ・ノードへの接続を終了するステップをさらに含む、請求項１に記載の方法。
6. 前記アプリケーションによって再接続を試みるステップをさらに含む、請求項５に記載の方法。
7. 前記サーバ・ノード及び前記クライアント・ノードは、伝送制御プロトコルを介して通信する、請求項１〜６のいずれかに記載の方法。
8. 前記フォールオーバー・ノードは、前記サーバ・ノードが故障したことを、前記クライアント・ノード上で稼働する前記アプリケーションに知らせる、請求項１〜７のいずれかに記載の方法。
9. 前記フォールオーバー・ノードは、前記フォールオーバー・ノードが前記サーバ・ノードを引き継いだことを前記クライアント・ノードに知らせるように動作可能である、請求項８に記載の方法。
10. 前記サーバ・ノードの故障によって開始される、請求項１〜９のいずれかに記載の方法。
11. 前記通知は、伝送制御プロトコル接続を通して提供される通知より早く提供される、請求項１〜１０のいずれかに記載の方法。
12. クライアント・ノード上で稼働するクライアント・アプリケーションのためのサーバとして機能しているサーバ・ノードの故障の通知を前記クライアント・アプリケーションに送信するためのプログラム命令を、少なくとも３つのノードについてのメモリ内に含む、前記少なくとも３つのノードを含むマルチノード・データ処理システムであって、前記通知は、前記サーバ・ノードのためのバックアップとして機能するフォールオーバー・ノードによって提供されるものであって、前記フォールオーバー・ノードにおいて、前記クライアント・ノードと前記サーバ・ノードとの間の接続の終了を促すリセット・パケットを構成し、前記リセット・パケットを前記クライアント・ノード上で稼働する前記クライアント・アプリケーションに伝送する、マルチノード・データ処理システムにおいて、
    請求項１から請求項１１までのいずれかに記載の方法を行なうように適合されたプログラム命令を含む、マルチノード・データ処理システム。
13. コンピュータ上で稼働するときに、請求項１から請求項１１までのいずれかに記載の方法を行うように適合されたプログラム・コード手段を含む、コンピュータ・プログラム。

Images