(57)【要約】【課題】  単にメモリ上のセッション情報を二重化するだけでは、Web APサーバの障害のタイミングによっては、古いセッション情報を参照して処理を継続してしまうという問題である。また、PC全てに電源を制御する専用のハードウェアを設置するのはコストの面から現実的ではないためである。【解決手段】  本発明では、上記従来技術の問題点を鑑みて、以下の二つの課題を解決することを目的とする。第一に、どのタイミングでWeb APサーバに障害が起きても古いセッション情報を参照してしまうことがないことを保証する。第二に、通信障害による正常系と待機系の不整合を防止する方法をソフトウェアで実現する。【選択図】図１
2005135125.tif 000002
【特許請求の範囲】
【請求項１】
正常系サーバと待機系サーバとを用いたフェイルオーバ処理方法であって、
前記正常系サーバが、第一のリクエストを受信し、当該第一のリクエストの処理で使用した第一のセッション情報を読み出し、前記待機系サーバの記憶装置へ前記第一のセッション情報をコピーして格納し、
前記正常系サーバが、第二のリクエストを受信した場合に、第二のリクエストの処理を開始する前に、前記待機系サーバの記憶装置に格納された前記第一のセッション情報を無効化することを特徴とするフェイルオーバ処理方法。
【請求項２】
WebサーバとWebアプリケーションサーバとデータベースから構成されるオンライン処理システムを、少なくとも一組の正常系Webアプリケーションサーバと待機系Webアプリケーションサーバを運用する冗長構成とし、正常系Web アプリケーションサーバでのリクエスト処理毎にリクエスト処理で使用したメモリ上のセッション情報を待機系Web アプリケーションサーバのメモリ上に二重化し、正常系Web アプリケーションサーバの障害時には待機系Web アプリケーションサーバが処理を引き継ぐフェイルオーバ処理方法であって、正常時の正常系Web アプリケーションサーバのリクエスト処理開始前に、リクエスト処理で使用するセッション情報に対応する待機系Web アプリケーションサーバのメモリ上のセッション情報を無効化することを特徴とする、フェイルオーバ処理方法。
【請求項３】
請求項２記載のフェイルオーバ処理方法において、前記正常系Webアプリケーションサーバは、リクエスト処理開始前にリクエスト処理で使用するセッション情報のセッションIDを指定して、前記待機系Webアプリケーションサーバにセッション情報無効化要求を送信するセッション情報無効化要求送信ステップを有し、前記待機系Webアプリケーションサーバは、該セッション情報無効化要求を受信した場合に、該セッション情報無効化要求で指定されたセッションIDを持つセッション情報を前記待機系Webアプリケーションサーバのメモリ上から無効化するセッション情報無効化ステップを有することを特徴とする、フェイルオーバ処理方法。
【請求項４】
請求項３記載のフェイルオーバ処理方法において、前記正常系Webアプリケーションサーバは、リクエスト処理開始前にリクエスト処理で使用するセッション情報がない場合、リクエスト処理に必要なセッションIDを指定して、前記待機系Webアプリケーションサーバにセッション情報取得要求を送信するセッション情報取得要求送信ステップを有し、前記待機系Webアプリケーションサーバは、該セッション情報取得要求を受信した場合に、該セッション情報取得要求で指定されたセッションIDを持つセッション情報を前記正常系Webアプリケーションサーバに送信した上で、前記待機系Webアプリケーションサーバのメモリ上から無効化するセッション情報回復ステップを有することを特徴とする、フェイルオーバ処理方法。
【請求項５】
請求項４記載のフェイルオーバ処理方法において、前記待機系Webアプリケーションサーバは、前記正常系Webアプリケーションサーバが稼動しているにも関わらず、前記Webサーバからリクエストが転送されてきた場合には、リクエスト処理を辞退することを通知する処理辞退通知を前記Webサーバに送信することを特徴とするフェイルオーバ処理方法。
【請求項６】
請求項５記載のフェイルオーバ処理方法において、前記Webサーバはクライアントから受信したリクエストの宛先に基づき、該リクエストを転送すべき一組の正常系Web アプリケーションサーバと待機系Webアプリケーションサーバを決定するリクエスト転送先ペア決定ステップと、該リクエスト転送先ペア決定ステップで決定した組の片方のWebアプリケーションサーバへリクエストを転送し、その転送が失敗した場合又は処理辞退通知が返信されてきた場合には、もう一方のWebアプリケーションサーバにリクエストを転送する転送先切り替えステップを有することを特徴とする、フェイルオーバ処理方法。
【請求項７】
請求項６記載のフェイルオーバ処理方法において、前記正常系Webアプリケーションサーバと前記待機系Webアプリケーションサーバが稼動している状態から、どちらか一方が停止した後、再起動した場合に、もう一方のWebアプリケーションサーバから再起動したWebアプリケーションサーバへ、二重化されていないセッション情報を全て送信するセッション情報二重化復旧ステップを前記正常系Webアプリケーションサーバと前記待機系Webアプリケーションサーバが有することを特徴とする、フェイルオーバ処理方法。
【請求項８】
WebサーバとWebアプリケーションサーバとデータベースから構成されるオンライン処理システムを、少なくとも一組の正常系Webアプリケーションサーバと待機系Webアプリケーションサーバを運用する冗長構成とし、正常系Web アプリケーションサーバでのリクエスト処理毎にリクエスト処理で使用したメモリ上のセッション情報を待機系Web アプリケーションサーバのメモリ上に二重化し、正常系Web アプリケーションサーバの障害時には待機系Web アプリケーションサーバが処理を引き継ぐフェイルオーバ処理方法であって、前記正常系Web アプリケーションサーバと前記待機系Web アプリケーションサーバ間のセッション情報の二重化のための通信に障害が起きた時に、前記正常系Web アプリケーションサーバと前記待機系Web アプリケーションサーバは、通信障害を検知した場合に前記データベースの特定のレコードに排他的なアクセスを行い、先に該レコードにアクセスできたWeb アプリケーションサーバが稼動を続け、後からアクセスしたWeb アプリケーションサーバが稼動を停止する稼動サーバ判定処理を実行することを特徴とする、フェイルオーバ処理方法。
【請求項９】
請求項８記載のフェイルオーバ処理方法において、前記正常系Web アプリケーションサーバと前記待機系Web アプリケーションサーバは、前記稼動サーバ判定処理において、自身が停止することになった場合、停止するまでに前記Webサーバから転送されてきたリクエストに対してリクエスト処理を行わずに、リクエスト処理を辞退することを通知する処理辞退通知を前記Webサーバに送信することを特徴とするフェイルオーバ処理方法。
【請求項１０】
請求項９記載のフェイルオーバ処理方法において、前記待機系Webアプリケーションサーバは、前記正常系Webアプリケーションサーバが稼動しているにも関わらず、前記Webサーバからリクエストが転送されてきた場合には、リクエスト処理を辞退することを通知する処理辞退通知を前記Webサーバに送信することを特徴とするフェイルオーバ処理方法。
【請求項１１】
請求項１０記載のフェイルオーバ処理方法において、前記Webサーバはクライアントから受信したリクエストの宛先に基づき、該リクエストを転送すべき正常系Web アプリケーションサーバと待機系Webアプリケーションサーバのペアを決定するリクエスト転送先ペア決定ステップと、該リクエスト転送先ペア決定ステップで決定したペアの片方のWebアプリケーションサーバへリクエストを転送し、その転送が失敗した場合又は処理辞退通知が返信されてきた場合には、もう一方のWebアプリケーションサーバにリクエストを転送する転送先切り替えステップを有することを特徴とするフェイルオーバ処理方法。
【請求項１２】
請求項１１記載のフェイルオーバ処理方法において、前記正常系Webアプリケーションサーバと前記待機系Webアプリケーションサーバが稼動している状態から、どちらか一方が停止した後、再起動した場合に、もう一方のWebアプリケーションサーバから再起動したWebアプリケーションサーバへ、二重化されていないセッション情報を全て送信するセッション情報二重化復旧ステップを前記正常系Webアプリケーションサーバと前記待機系Webアプリケーションサーバが有することを特徴とする、フェイルオーバ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、正常系と待機系から成るサーバプログラムの冗長構成により、正常系サーバプログラムの障害時に待機系サーバプログラムが処理を引き継ぐフェイルオーバ処理方法に関する。
【背景技術】
【０００２】
Webで買い物ができるオンラインショッピングサイトのような商用のWebサイトでは、利用者に常にサービスを提供できるように、２４時間３６５日運転を可能とする高可用性が求められている。
【０００３】
このような商用のWebサイトは一般に、Webサーバと、Webサーバと連携動作してアプリケーションプログラムを実行するWebアプリケーションサーバ（Web APサーバ）、そして、アプリケーションプログラムが参照するデータ、又は処理した結果のデータを管理するデータベース管理システム（DBMS）の３層から構成される。
【０００４】
WebブラウザからWebサイトにアクセスすることにより、HTTPリクエストがWebサーバに到着する。Webサーバでは到着したHTTPリクエストの宛先URLを参照して、URLに対応するHTMLファイルや画像ファイルをWebブラウザに返信するか、又はWeb APサーバにリクエストを転送するかどうかを判断する。Web APサーバにリクエストを転送する場合、Web APサーバでは転送されてきたリクエストの宛先URLに対応するアプリケーションプログラムを実行する。オンラインショッピングサイトにおける商品選択・確認・決済といった、ユーザから入力されるデータに基づく処理は、Web APサーバでアプリケーションプログラムを実行することにより行われる。このアプリケーションプログラムは、必要に応じて、DBMSと通信を行い、データベースから必要なデータを検索して取り出したり、処理したデータをデータベースに格納したりする。
【０００５】
このようなWebサーバ、Web APサーバとDBMSから構成されるWebサイトの可用性を高める方法としては、Webサーバ、Web APサーバ、DBMSをそれぞれ冗長に複数起動しておき、いずれかのサーバに障害が起きた場合には、冗長に起動しておいた代わりのサーバで処理を引き継ぐ方法がある。この方法では、一部のサーバの障害がWebサイト全体の停止には繋がらず、Webサイトとしては処理を続けることができる。しかし、Web APサーバに障害が起きた場合には、Webサイト全体の停止には繋がらないものの、以下の理由により、ユーザにはエラーを返すことになってしまう。
【０００６】
Web上で実現されるアプリケーションは一般に、アプリケーションを構成する一連のページを、リンクをたどって順次呼び出すことにより実行される。そして、それぞれのページではユーザにデータを段階的に入力させ、アプリケーションの処理が完了した時点でそれまでに入力されたデータを一括してデータベースに登録する構成を採ることが多い。例えば、ショッピングサイトでは、アプリケーションを構成する個々のページで、まず、購入商品を選択させ、次に、住所やクレジットカードの番号等のデータを入力させ、最後に決済を行った時点で一括してそれらのデータをデータベースに格納する。
【０００７】
この時、データベースに登録するまでに段階的に入力された中間的なデータをクライアントに対応付けて保持している必要がある。市販のWeb APサーバではメモリ上でそれらのデータをクライアントに対応つけて保持する機能を提供している。そのため、Web APサーバに障害が起きるとこのメモリ上のデータが失われてしまい、ユーザがそれまで入力した購入商品や住所などのデータが消えてしまう。よって、冗長に起動しておいた他のWeb APサーバではユーザの処理を引き継ぐことができず、アプリケーションはユーザにエラーを返すことになってしまう。
【０００８】
このメモリ上の中間的なデータをセッション情報と呼ぶ。そして、Web APサーバは、クライアントとセッション情報とを対応付けるために、クライアントに対してセッションIDと呼ぶ識別子を発行し、それに対応付けてセッション情報を管理している。また、Web APサーバがセッションIDを発行する際には、セッションIDにそのクライアントのセッション情報を保持するWeb APサーバを識別するIDを含める。Webサーバでは、リクエストに含まれるセッションIDを元に、同一のクライアントからのリクエストを毎回同じWeb APサーバに転送する。
【０００９】
Web APサーバの障害により個々のユーザがエラーに遭遇してしまう上記の問題を解決するために、メモリ上のセッション情報を二重化し、Web APサーバの障害に備える方法の例として、非特許文献１がある。
【００１０】
この非特許文献１の従来例では、Web APサーバを複数起動しておき、あるWeb APサーバでリクエスト処理に使用したセッション情報を、リクエスト処理後に他のWeb APサーバのメモリ上にバックアップすることにより、セッション情報を二重化している。
【００１１】
上記従来例では、下記に示す問題への配慮がなされているかどうかは開示されていないが、セッション情報を単に二重化するだけでは、Web APサーバに障害が起きるタイミングによっては、古いセッション情報を用いてリクエスト処理を引き継いでしまう場合がある。具体的には、あるWeb APサーバでリクエスト処理を行った後、そのリクエスト処理で更新されたセッション情報をバックアップする前にそのWeb APサーバに障害が起きた場合、バックアップ先であるWeb APサーバには更新された新しいセッション情報がバックアップされず、以前の古いセッション情報が残ってしまう。そして、その後のリクエストでは、代わりのWeb APサーバがその古いセッション情報を用いて処理を行ってしまうという問題が発生する。
【００１２】
さらに、Web APサーバ間のバックアップのための通信に障害が発生した場合、正常時にリクエスト処理を行っているWeb APサーバはバックアップ先のWeb APサーバにセッション情報をバックアップできないまま処理を続ける。すると、その２つのWeb APサーバ間で、保持しているセッション情報のデータの内容が異なってしまう。この状態で正常時にリクエスト処理を行っているWeb APサーバに障害が起きると、バックアップ先のWeb APサーバでは古いバックアップを用いて処理を行ってしまうという問題が発生する。
【００１３】
このような通信障害が原因で起きる２つの系の間の不整合を防止する従来例としては特許文献１における「二重化通信システム」がある。この従来例では、正常時にリクエスト処理を行う正常系ホストと、正常時は正常系ホストの稼動状態を常に監視して正常系ホストに障害が起きたときだけリクエスト処理を行う待機系ホストを設ける。待機系ホストは定期的に正常系ホストと通信を行うことにより稼動監視を行い、正常系ホストが稼動していると判断している間は処理を引き継がない。そして、稼動監視によって正常系ホストが停止していると判断した場合、正常系ホストとの通信路に障害が発生している場合を考慮して、稼動している可能性のある正常系ホストの電源を専用のハードウェアを用いて切断する。これにより、通信障害によって２つの系の間で不整合が起きる前に、どちらか一方の稼動を確実に停止し、もう一方だけで処理を継続する方法を採っている。
【００１４】
【非特許文献１】Scott Hawkins 著、”BEA WebLogic Server Administration Kit”、Prentice Hall Ptr 出版、2003、p.77
【００１５】
【特許文献１】特開２０００−２０３３６号
【発明の開示】
【発明が解決しようとする課題】
【００１６】
上記の従来技術を用いて、２４時間３６５日止まることなくサービスを提供する商用の大規模Webサイトを構築しようとした場合、以下の問題が生じる。
【００１７】
商用のWebサイトでは、可用性に加えて信頼性も必要とされる。また、近年の大規模Webサイトは、安価なPCを大量に購入し、そのPC上でWebサーバやWeb APサーバを起動して負荷分散を行い、高負荷に耐えられるような構成を採っている。
【００１８】
第一の問題は、非特許文献１の従来例で開示されている方法のみで、単にメモリ上のセッション情報を二重化するだけでは、Web APサーバの障害のタイミングによっては、古いセッション情報を参照して処理を継続してしまうという問題である。
【００１９】
第二の問題は、特許文献１の従来例は、近年の大規模Webサイトの構成には適さないという問題である。なぜなら、コストを削減するため安価なPCを大量に設置しているにも関わらず、その全てに電源を制御する専用のハードウェアを設置するのはコストの面から現実的ではないためである。
【００２０】
本発明では、上記従来技術の問題点を鑑みて、以下の二つの課題を解決することを目的とする。第一に、どのタイミングでWeb APサーバに障害が起きても古いセッション情報を参照してしまうことがないことを保証する。第二に、通信障害による２つの系の間の不整合を防止する方法をソフトウェアだけで実現する。
【課題を解決するための手段】
【００２１】
本発明における正常系サーバと待機系サーバとを用いたフェイルオーバ処理方法であって、前記正常系サーバが、第一のリクエストを受信し、当該第一のリクエストの処理で使用した第一のセッション情報を読み出し、前記待機系サーバの記憶装置へ前記第一のセッション情報をコピーして格納し、前記正常系サーバが、第二のリクエストを受信した場合に、第二のリクエストの処理を開始する前に、前記待機系サーバの記憶装置に格納された前記第一のセッション情報を無効化することを特徴とする。
【００２２】
また、本発明は上記の課題を解決するために、正常系Web APサーバと待機系Web APサーバのメモリ上で二重化してあるセッション情報が古くなる場合には、古くなるデータを事前に無効化するようにする。
【００２３】
具体的には、正常系Web APサーバでのリクエスト処理開始前に、待機系Web APサーバにこれから正常系Web APサーバで更新するセッション情報のバックアップを無効化するように要求を行い、それに従って待機系Web APサーバではセッション情報のバックアップを無効化することにする。これにより、正常系Web APサーバでのリクエスト処理を開始してから、リクエスト処理後に待機系Web APサーバにセッション情報を二重化するまでの間は、セッション情報は二重化されていないものの、正常系Web APサーバと待機系Web APサーバとで内容の異なるセッション情報が存在してしまうことがなくなる。これにより、上記第一の課題が解決される。
【００２４】
また、正常系Web APサーバと待機系Web APサーバ間の通信に障害が発生した場合には、双方のサーバは障害を検知した時点で、データベースの特定のレコードに排他的なアクセスを行い、先にアクセスできた方のサーバが稼動を続け、後からアクセスした方のサーバは自発的に停止することにする。これにより、通信障害が起きた場合に確実にどちらか一方のサーバだけで稼動を続けることがソフトウェアだけで実現でき、上記第ニの課題が解決される。
【発明の効果】
【００２５】
本発明によれば、Webアプリケーションサーバに障害が発生しても、処理を引き継ぐWebアプリケーションサーバが古いセッション情報を用いることなく、リクエスト処理を継続することが可能となる。また、セッション情報の二重化のためのWebアプリケーションサーバ間の通信に障害が起きても、古いセッション情報を用いることなく、リクエスト処理を継続することが可能となる。
【発明を実施するための最良の形態】
【００２６】
以下に、本発明の一実施例を図面を用いて詳細に説明する。本発明の一つの目的は、正常系Web APサーバがリクエスト処理を行う毎に、リクエスト処理に使用したセッション情報を待機系Web APサーバに二重化して障害に備えるフェイルオーバ処理方法において、正常系Web APサーバの障害がどのタイミングで発生しても、待機系Web APサーバが古いセッション情報を参照しないように保証しつつ、可能な限りユーザの処理を継続することである。
【００２７】
本発明の他の目的は、正常系Web APサーバと待機系Web APサーバ間の通信に障害が発生した場合に、正常系Web APサーバと待機系Web APサーバ間の系の不整合を生じさせないために、確実にどちらか片方のWeb APサーバだけが稼動を続ける方法をソフトウェアだけで実現することである。
【００２８】
本発明では、上記第一の目的を達成するために、正常系Web APサーバでリクエスト処理を行う前に、待機系Web APサーバにセッション情報無効化要求を送信し、これから正常系Web APサーバでリクエスト処理に使用するセッション情報に対応する待機系Web APサーバ上のセッション情報のバックアップをあらかじめ無効化しておく。これにより、正常系Web APサーバでリクエスト処理を行う間はセッション情報が二重化されていないことになるものの、待機系Web APサーバが古いセッション情報を参照してしまうことを未然に防止している。
【００２９】
また、上記第二の目的を達成するために、正常系Web APサーバと待機系Web APサーバ間で定期的に通信し合うことで互いが稼動していることを監視しておき、ペアとなるWeb APサーバからの通信が途絶えた場合には、あらかじめ用意しておいたリレーショナルデータベースのレコードに先にアクセスできた一方のWeb APサーバだけが稼動を続け、後からアクセスしたもう一方のWeb APサーバは自発的に停止することにしている。これにより、どちらか一方のWeb APサーバのみが稼動を続けることをソフトウェアだけで実現している。
【００３０】
以下ではまず、本発明を利用して、上記目的を達成するための本実施例のシステム構成および動作の概要について説明する。
【００３１】
図２・３には本実施例のシステム構成を示す。本実施例では、図２に示すようにホームページ閲覧者503が操作する端末装置とWebサイト500がネットワーク501を介して接続されている。端末装置502は汎用の計算機と汎用のHTTPクライアントプログラム（以下Webブラウザ504と呼ぶ）から構成され、ホームページ閲覧者503は、端末装置502上でWebブラウザ504を操作することにより、Webサイト500にアクセスする。
【００３２】
図３にはWebサイト500内の構成を示す。Webサイト500は、Webサーバ用計算機510、正常系Web APサーバ用計算機511、待機系Web APサーバ用計算機512、DBMS用計算機513から構成され、それらはネットワークを介して接続されている。これらのWebサイトを構成する計算機はすべて、汎用の計算機で実現可能である。Webサイト管理者505は、Webサーバ用計算機510上ではHTTPサーバプログラム（以下、Webサーバプログラム100と呼ぶ）を、正常系Web APサーバ用計算機511上では正常系Web APサーバプログラム200を、待機系Web APサーバ用計算機512上では待機系Web APサーバプログラム300を、DBMS用計算機513上ではDBMSプログラム400を起動する。
【００３３】
正常系Web APサーバプログラム200は、正常時にリクエスト処理と待機系Web APサーバプログラム300へのセッション情報の二重化を行うWeb APサーバプログラムである。また、待機系Web APサーバプログラム300は正常時にはリクエスト処理は行わず、正常系Web APサーバプログラム200の障害時にリクエスト処理を引き継ぐWeb APサーバプログラムである。正常系Web APサーバプログラム200と待機系Web APサーバプログラム300はペアで起動する。
【００３４】
以降では正常系Web APサーバプログラム200と待機系Web APサーバプログラム300のペアをWeb APサーバペアと呼ぶ。DBMS用計算機513上の二次記憶装置401上には、DBMSプログラム400を介してアクセス可能な、Web APサーバペアの状態を管理するためのリレーショナルデータベースのテーブルであるサーバペア状態管理テーブル402を設け、Web APサーバペア毎に１つのサーバペア状態を格納する。
【００３５】
なお、本実施例では、Web APサーバペアを一組しか起動していないが、ペアとなる正常系と待機系のWeb APサーバプログラムを異なる計算機上で起動すれば、負荷分散のために複数のペアを起動しても構わない。また、本実施例では、本発明とは無関係のため、Webサーバプログラム100とDBMSプログラム400を冗長構成としていないが、Webサイト500全体の可用性を高めるために、Webサーバプログラム100やDBMSプログラム400を複数起動して冗長構成としても構わない。
【００３６】
次に、本実施例の動作手順の概要について説明する。
図１を用いて動作手順を説明する。正常系および待機系Web APサーバプログラムの起動時、Web APサーバペアの正常稼動時、正常系Web APサーバプログラム200障害発生時、待機系Web APサーバプログラム300障害発生時、Web APサーバペア間の通信障害発生時、正常系および待機系Web APサーバプログラム単独稼動時、そして正常系および待機系Web APサーバプログラム再起動時についてそれぞれ説明する。
【００３７】
まず、正常系Web APサーバプログラム200と待機系Web APサーバプログラム300の起動時の動作手順を説明する。正常系Web APサーバプログラム200と待機系Web APサーバプログラム300を起動すると、正常系Web APサーバプログラム200は正常系初期化処理201を、待機系Web APサーバプログラム300は待機系初期化処理301を実行する。正常系Web APサーバプログラム200と待機系Web APサーバプログラム300はペアで機能するため、それぞれの初期化処理では、お互いにペアとなるWeb APサーバプログラムとのコネクションを確立し、互いの稼動が確認できるまでは初期化処理は終了しないようにしている。つまり、ペアとなるWeb APサーバプログラム間において、コネクションの確立をし、互いに稼動確認した後で初期化処理は終了する。
【００３８】
本実施例では、正常系Web APサーバプログラム200は、正常系初期化処理201の中で、待機系Web APサーバプログラム300とコネクションを確立するまで繰り返し待機系Web APサーバプログラム300に対してコネクション確立要求を出す処理を行う。また、待機系Web APサーバプログラム300は、待機系初期化処理301の中で、正常系Web APサーバプログラム200からのコネクション確立要求を受け付ける処理を行い、お互いにコネクションを確立するまでは初期化処理が終了しないようにしている。つまり、コネクションが確立した後で初期化処理を終了させる。
【００３９】
そして、コネクションを確立した場合、正常系Web APサーバプログラム200は、正常系初期化処理201の中で、DBMSプログラム400に対してサーバペア状態更新SQL921を送信し、Web APサーバペアの状態管理に用いるサーバペア状態管理テーブル402のサーバペア状態を、Web APサーバペアが正常に稼動していることを意味する文字列である正常稼動とする。このサーバペア状態に記録されるサーバペアの状態は、Web APサーバプログラムが稼動する上で必要に応じて参照する必要がある。そこで、DBMSプログラム400へのアクセスを極力減らすために、正常系Web APサーバプログラム200と待機系Web APサーバプログラム300は、それぞれサーバペア状態の情報を格納するためのキャッシュをメモリ上に持つことにする。
【００４０】
このキャッシュのことをサーバペア状態キャッシュ208と呼ぶ。サーバペア状態を正常稼動に更新した後、正常系Web APサーバプログラム200と待機系Web APサーバプログラム300は自身のサーバペア状態キャッシュ208を正常稼動とする。以降では、この初期化処理で確立したコネクションを用いて、正常時のセッション情報の二重化（セッション情報をコピーして他のサーバへ格納する処理）のための通信や、正常系Web APサーバプログラム200と待機系Web APサーバプログラム300間の稼動確認のための通信を行う。以上の初期化処理を終えた後、Web APサーバペアは正常に稼動を開始する。
【００４１】
次に、正常時の本実施例の動作手順をWebサーバプログラム100、正常系Web APサーバプログラム200、待機系Web APサーバプログラム300の順に説明する。
【００４２】
Webサーバプログラム100は、Webブラウザ504から到着するHTTPリクエスト901の宛先URLとリクエストに含まれるセッションIDからリクエストを転送すべきWeb APサーバペアを選択し、選択したペアのうち、正常系Web APサーバプログラム200にリクエストを転送する。まず、ホームページ閲覧者503がWebブラウザ504を操作してWebサイト500にアクセスすることによって、HTTPリクエスト901がWebサーバプログラム100に到着する。Webサーバプログラム100ではHTTPリクエスト901を受信した場合、そのHTTPリクエスト901を自身で処理すべきか、又はWeb APサーバペアに転送すべきかどうかを決定するために、リクエスト選択転送処理101を実行する。
【００４３】
リクエスト選択転送処理101では、リクエストの宛先URLから転送先Web APサーバペア群を求める転送先Web APサーバペア群決定テーブル102を用いて、受信したHTTPリクエスト901の宛先URLから、転送先のWeb APサーバペア群を決定する。ここで求まるWeb APサーバペア群は１つ又は複数のWeb APサーバペアである。本実施例では、HTTPリクエストの転送先となるWebサーバプログラムが管理するWeb APサーバペア群決定テーブル102は、Webサイト管理者504によって起動時にWebサーバプログラム100に与えられるものとする。つまり、Web APサーバペア群決定テーブル102は、Webサーバプログラムが稼動するコンピュータの記憶装置へ、管理者によって格納される。
【００４４】
転送先のWeb APサーバペア群が求まらなかった場合には、Webサーバプログラム100でこのリクエストを処理する。転送先Web APサーバペア群が求まった場合、次に、求まったWeb APサーバペア群の中からどのWeb APサーバペアにリクエストを転送するか決定する。この場合には、HTTPリクエスト901にセッションIDが含まれていれば、セッションIDに含まれるWeb APサーバペアIDから転送すべきWeb APサーバペアを決定し、セッションIDが含まれていない場合には、Web APサーバペア群の中からランダムにWeb APサーバペアを決定する。
【００４５】
そして、Web APサーバペアを決定した後、Web APサーバペア名から正常系Web APサーバプログラムのネットワークアドレスと、待機系Web APサーバプログラムのネットワークアドレスを求めるWeb APサーバペア定義テーブル103を用いて、決定したWeb APサーバペアの正常系Web APサーバプログラムのネットワークアドレスを求め、そこにリクエストを転送する。本実施例では、Web APサーバペア定義テーブル103はWebサイト管理者504によって起動時にWebサーバプログラム100に与えられるものとする。
【００４６】
次に、正常時にWebサーバプログラム100からHTTPリクエスト901を受信した正常系Web APサーバプログラム200の動作手順を説明する。正常系Web APサーバプログラム200はWebサーバプログラム100からHTTPリクエスト901を受信した場合、セッション情報無効化要求送信処理202とアプリケーション実行処理203とセッション情報二重化要求送信処理204を順に実行する。まず、セッション情報無効化要求送信処理202では、HTTPリクエスト901に含まれるセッションIDを取得して、セッションIDに対応するセッション情報が自身のメモリ上にあるかどうか確認する。セッション情報が存在すれば、セッションIDをセッション情報無効化要求912に含め、待機系Web APサーバプログラム300に送信する。
【００４７】
セッション情報が存在しない場合は、セッションIDをセッション情報取得要求917に含め、待機系Web APサーバプログラム300に送信する。セッション情報が存在しない状況が発生するのは、典型的には、正常系Web APサーバプログラム200が障害により一旦停止した後、再起動し、後に述べる再接続処理により再び待機系Web APサーバプログラム300と接続を確立し、正常稼動を開始した直後である。この時、再起動した正常系Web APサーバプログラム200は、メモリ上にセッション情報を保持していないため、リクエスト処理に必要なセッション情報を待機系Web APサーバプログラム300から取得する必要がある。そのための取得要求が、セッション情報取得要求917である。
【００４８】
そして、待機系Web APサーバプログラム300からセッション情報無効化応答913又が返信されてきた場合には、次にアプリケーション実行処理203を実行する。また、待機系Web APサーバプログラム300からセッション情報取得応答918が返信されてきた場合には、応答に含まれるセッション情報をメモリ上に保存してからアプリケーション実行処理203を実行する。アプリケーション実行処理203では、HTTPリクエスト901のURLに対応するアプリケーションプログラムを実行する。
【００４９】
アプリケーションプログラムを実行することによって、正常系Web APサーバプログラム200のメモリ上のセッション情報は更新され、Webブラウザ504にはHTTPレスポンス902が返信される。アプリケーション実行処理203は汎用のWeb APサーバプログラムに備わっている機能なので詳細な説明は省略する。そしてアプリケーション実行処理203を実行した後、セッション情報二重化要求送信処理204を実行する。この処理では、アプリケーションの実行により更新されたセッション情報を待機系Web APサーバプログラム300に二重化するために、セッション情報二重化要求914にリクエスト処理に使用したセッション情報とセッションIDを含めて待機系Web APサーバプログラム300へ送信する。以上がリクエスト受信時の正常系Web APサーバプログラム200の処理である。
【００５０】
また、上記のリクエスト受信時の処理とは別に、正常系Web APサーバプログラム200は、待機系Web APサーバプログラム300の状態を監視するために、稼動確認用メッセージ916を送受信する稼動状態監視処理205を一定時間毎に実行する。
【００５１】
次に、待機系Web APサーバプログラム300の正常時の動作手順を説明する。正常時の待機系Web APサーバプログラム300は、セッション情報無効化要求912又はセッション情報取得要求917を正常系Web APサーバプログラム200から受信した場合にはセッション情報無効化処理302を実行する。セッション情報無効化処理302では、セッション情報無効化要求912又はセッション情報取得要求917に含まれるセッションIDを持つセッション情報を無効化する。ただし、セッション情報取得要求917を受信した場合には、無効化する前に、そのセッション情報をセッション情報取得応答918に含めて返信する。
【００５２】
また、正常系Web APサーバプログラム200からセッション情報二重化要求914が送信されてきた場合には、待機系Web APサーバプログラム300は、要求に含まれて送信されてきたセッション情報をメモリ上にバックアップするセッション情報二重化処理304を実行する。また、待機系Web APサーバプログラム300は正常時にはリクエスト処理を行わない。正常系Web APサーバプログラム200の障害により待機系Web APサーバプログラム300が単独稼動している状態から、正常系Web APサーバプログラム200が再起動して正常時に復旧した直後は、Webサーバプログラム100から正常時に待機系Web APサーバプログラム300にHTTPリクエスト901が転送されてくる場合があるが、その場合にはまず、正常系Web APサーバプログラム200の稼動状態を確認するために、引き継ぎ判定処理307を実行する。
【００５３】
この処理では、正常系Web APサーバプログラム200に稼動確認用メッセージ916を送信して、応答があるかどうか稼動状態を確認した上で、正常系Web APサーバプログラム200が稼動している判断した場合には、リクエスト処理は行わず、リクエストを転送してきたWebサーバプログラム100に対して処理辞退通知903を送信する。処理辞退通知903を受け取ったWebサーバプログラム100は、正常系Web APサーバプログラム200にHTTPリクエスト901を転送しなおすようになっている。また、正常系Web APサーバプログラム200と同様に、待機系Web APサーバプログラム300では、正常系Web APサーバプログラム200の状態を監視するために、稼動状態監視処理205を一定時間毎に実行する。
以上が正常時のWebサーバプログラム100、正常系Web APサーバプログラム200、待機系Web APサーバプログラム300の処理手順である。
【００５４】
上記の処理手順により正常時には、必ず正常系Web APサーバプログラム200でリクエスト処理が実行されるようになっている。そして、リクエストを実行する正常系Web APサーバプログラム200では、アプリケーション実行処理203の前に、セッション情報無効化要求送信処理202を実行して、待機系Web APサーバプログラム300にあるセッション情報を無効化することにより、アプリケーション実行処理203の実行直後の正常系Web APサーバプログラム200と待機系Web APサーバプログラム300とでセッション情報のデータの不整合が起きる状態が生じることを未然に防いでいることが、本発明の特徴である。
【００５５】
このため、正常系Web APサーバプログラム200にいつ障害が起きても、待機系Web APサーバプログラム300で古いデータを用いてしまうことがないように保証している。
それでは次に、正常系Web APサーバプログラム200に障害が起きた場合のWebサーバプログラム100、待機系Web APサーバプログラム300の動作手順について説明する。
【００５６】
正常系Web APサーバプログラム200に障害が起きた場合、Webサーバプログラム100は正常系Web APサーバプログラム200と通信を行う時に、通信エラーにより障害を検知する。Webサーバプログラム100は正常系Web APサーバプログラム200の障害を検知した場合、その正常系Web APサーバプログラム200のペアとなっている待機系Web APサーバプログラム300にHTTPリクエスト901を転送し直す。 以上のWebサーバプログラム100の処理により、正常系Web APサーバプログラム200障害時には、待機系Web APサーバプログラム300にHTTPリクエスト901を転送するようになっている。
【００５７】
一方、待機系Web APサーバプログラム300は、以下の二つの方法で正常系Web APサーバプログラム200の障害を検知する。一つは、正常時に定期的に実行している稼動状態監視処理205における正常系Web APサーバプログラム200への稼動確認であり、もう一つは、Webサーバプログラム100からHTTPリクエスト901が転送されてきた際に実行する引き継ぎ判定処理307における正常系Web APサーバプログラム200への稼動確認である。上記のいずれの場合にも、待機系Web APサーバプログラム300が正常系Web APサーバプログラム200と通信が不可能となることにより正常系Web APサーバプログラム200の障害を検知する。
【００５８】
この検知方法では、正常系Web APサーバプログラム200の障害なのか、単に通信障害なのか判定できないため、通信障害の場合も考慮して、確実にどちらか一方だけがリクエスト処理を行うために、稼動を続けるWeb APサーバプログラムをどちらか一方に判定する稼動サーバ判定処理206を実行する。稼動サーバ判定処理206において正常系又は待機系Web APサーバプログラムは、データベースに設けられたサーバペア状態管理テーブル402のサーバペア状態を参照し、ペアとなるWeb APサーバプログラムよりも先に参照できた場合には、サーバペア状態を更新して稼動を続ける。
【００５９】
通信が不可能になった根本の原因が正常系Web APサーバプログラム200の障害であれば、正常系Web APサーバプログラム200はサーバペア状態にアクセスできないため、待機系Web APサーバプログラム300のみがデータベースにアクセスし、待機系Web APサーバ300が稼動を続けることになる。
【００６０】
この時、待機系Web APサーバプログラム300は、サーバペア状態管理テーブル402のサーバペア状態と自身のサーバペア状態キャッシュ208を、待機系だけでリクエスト処理を行っていることを意味する文字列である待機系単独稼動に更新し、引き継ぎ判定処理を終了し、リクエスト処理を実行する。
【００６１】
以上のように、正常系Web APサーバプログラム200の障害時には、待機系Web APサーバプログラム300がサーバペア状態管理テーブル402を待機系単独稼動とした後で、リクエスト処理を引き継ぐ。そして、正常時に正常系Web APサーバプログラム200が行うセッション情報無効化要求送信処理202により、待機系Web APサーバプログラム300に古いセッション情報が残らないことが保証されているため、古いセッション情報を用いて待機系Web APサーバプログラム300が処理を引き継ぐことが防止できる。
【００６２】
次に、待機系Web APサーバプログラム300に障害が起きた場合の、Webサーバプログラム100、正常系Web APサーバプログラム200の動作手順について説明する。
【００６３】
Webサーバプログラム100は、正常系 Web APサーバプログラム200が稼動している限り、待機系Web APサーバプログラム300と通信を行う機会がないため、待機系Web APサーバプログラム300の障害を検知することはない。
【００６４】
正常系Web APサーバプログラム200は、正常時に定期的に実行する稼動状態監視処理205か、リクエスト処理時に実行するセッション情報無効化要求送信処理202か、又は、セッション情報二重化要求送信処理204における待機系Web APサーバプログラム300との通信でエラーが発生することにより、待機系Web APサーバプログラム300の障害を検知する。正常系Web APサーバプログラム200は待機系Web APサーバプログラム300の障害を検知した場合、稼動サーバ判定処理206を実行する。
【００６５】
待機系Web APサーバプログラム300はサーバペア状態管理テーブル402のサーバペア状態にアクセスできないため、正常系Web APサーバプログラム200はサーバペア状態管理テーブル402のサーバペア状態と自身のサーバペア状態キャッシュ208を、正常系Web APサーバプログラム単独でリクエスト処理を行っていることを意味する文字列である正常系単独稼動に更新して、単独で稼動を続ける。以降のリクエストでは、サーバペア状態キャッシュ208が正常系単独稼動となっている限り、待機系Web APサーバプログラム300と通信を行うことなく単独でリクエスト処理を実行する。
【００６６】
以上のように、待機系Web APサーバプログラム300の障害時には、正常系Web APサーバプログラム200が単独でリクエスト処理を行う。
【００６７】
次に、正常系Web APサーバプログラム200と待機系Web APサーバプログラム300間の通信に障害が起きたときの、Webサーバプログラム100、 正常系Web APサーバプログラム200、待機系Web APサーバプログラム300の動作手順について説明する。
【００６８】
この障害の場合、Webサーバプログラム100は障害を検知することができない。よって、正常時と同様に到着したリクエストを正常系Web APサーバプログラム200に転送する。
【００６９】
正常系Web APサーバプログラム200は、障害発生後、はじめて待機系Web APサーバプログラム300に通信を行うタイミングで障害を検知し、稼動サーバ判定処理206を実行する。
【００７０】
一方、待機系Web APサーバプログラム300は稼動状態監視処理205や、正常系Web APサーバプログラム200からの要求に対する応答時に、通信エラーが発生することにより障害を検知し、稼動サーバ判定処理206を実行する。そして、正常系Web APサーバプログラム200と待機系Web APサーバプログラム300のうち、サーバペア状態管理テーブル402のサーバペア状態を先に参照できた方のWeb APサーバプログラムが、サーバペア状態をそのWeb APサーバの単独稼動に更新し、稼動を続けることができる。
【００７１】
一方、後からサーバペア状態を参照した方のWeb APサーバプログラムは、サーバペア状態がペアとなるWeb APサーバプログラムの単独稼動となっているため、その場合には自発的に停止する。自発的に停止するまでの間に、Webサーバプログラム100からリクエストが到着した場合には、そのWebサーバプログラム100に対して、処理辞退通知903を返す。
【００７２】
以上のように、系間の通信障害時には、稼動サーバ判定処理206において、先にサーバペア状態を先に参照できた一方のWeb APサーバプログラムのみが稼動を続けることができるようにしてある。これにより、系間の通信障害時には、確実に一方のWeb APサーバプログラムのみが稼動することをソフトウェアのみで実現できており、本発明の第二の目的が実現できている。
【００７３】
次に、Web APサーバプログラムの障害時や系間の通信障害によって、単独稼動になった正常系Web APサーバプログラム200や待機系Web APサーバプログラム300の動作手順について説明する。
【００７４】
正常系Web APサーバプログラム200の単独稼動の場合、正常系Web APサーバプログラム200は、Webサーバプログラム100からHTTPリクエスト901を受信すると、アプリケーション実行処理203のみを実行する。単独稼動であるかどうかの判断はリクエスト処理毎に、サーバペア状態キャッシュ208を参照して行う。また、リクエスト受信時以外の処理として、再起動してくるであろう待機系Web APサーバプログラム300に対して、定期的にコネクション確立要求911を送信する正常系再接続処理207を実行する。
【００７５】
待機系Web APサーバプログラム300の単独稼動の場合、待機系Web APサーバプログラム300はWebサーバプログラム100からリクエストを受信すると、アプリケーション実行処理203のみを実行する。単独稼動であるかどうかの判断はリクエスト処理毎に、サーバペア状態キャッシュ208を参照して行う。また、リクエスト受信時以外の処理として、再起動してくるであろう正常系Web APサーバプログラム200から送信されてくるコネクション確立要求911を受信する待機系再接続処理を定期的に実行する。
【００７６】
このように、単独稼動時にはセッション情報の二重化を行うことなく、Web APサーバプログラムは到着するリクエストを処理する。そして、再起動してくるであろうペアとのコネクションを再び確立するための処理を定期的に行う。
【００７７】
最後に、正常系Web APサーバプログラム200又は待機系Web APサーバプログラム300の再起動時の動作手順について説明する。
【００７８】
正常系Web APサーバプログラム200の単独稼動の状態から、待機系Web APサーバプログラム300が再起動すると、正常系Web APサーバプログラム200が単独稼動時に行う正常系再接続処理207と、待機系Web APサーバプログラムの待機系初期化処理301により、再びコネクションを確立する。正常系Web APサーバプログラム200は、コネクションを確立すると正常系再接続処理207の中で、サーバペア状態管理テーブル402のサーバペア状態とサーバペア状態キャッシュ208を正常稼動に更新し、以降は正常時の動作を行う。待機系Web APサーバプログラム300は正常系Web APサーバプログラム200とのコネクションを確立すると待機系初期化処理301の中でサーバペア状態キャッシュ208を正常稼動にする。
【００７９】
この時点では、正常系Web APサーバプログラム200に存在するセッション情報は、待機系Web APサーバプログラム300のメモリ上に二重化されていないが、正常系Web APサーバプログラム200でリクエスト処理を行うたびに、リクエスト処理で使用したセッション情報に関しては徐々に待機系Web APサーバプログラム300に二重化されていく。しかし、完全にセッション情報が二重化されるまでに正常系Web APサーバプログラム200に障害が起きた場合、その時点で二重化されていないセッション情報は失われてしまう。
【００８０】
このような事態に備えて、再接続時の処理として、リクエスト処理が行われなくても、正常系Web APサーバプログラム200にのみ存在するセッション情報を、再起動してきた待機系Web APサーバプログラム300へまとめて送信する、セッション情報二重化復旧処理209を行ってもよい。
【００８１】
また、待機系Web APサーバプログラム300の単独稼動の状態から、正常系Web APサーバプログラム200が再起動する場合は、待機系Web APサーバプログラム300が単独稼動時に行っている待機系再接続処理308と正常系Web APサーバプログラムの正常系初期化処理201により、再びコネクションが確立される。コネクションが確立されると、正常系Web APサーバプログラムは正常系初期化処理の中でサーバペア状態管理テーブル402のサーバペア状態とサーバペア状態キャッシュ208を正常稼動とする。
【００８２】
また、待機系Web APサーバプログラムは、コネクションを確立すると、待機系再接続処理の中でサーバペア状態キャッシュ208を正常稼動とする。以降に待機系Web APサーバプログラムに到着したリクエストに関しては、引き継ぎ判定処理307の結果、サーバペア状態キャッシュ208が正常稼動となっていることにより、待機系用Web APサーバプログラムはWebサーバプログラム100に処理辞退通知903を送信し、正常系Web APサーバプログラム200にリクエストが転送されることになる。
【００８３】
この場合にも、再接続をしただけでは、待機系Web APサーバプログラム200に存在するセッション情報は、正常系Web APサーバプログラム300のメモリ上に二重化されていないが、正常系Web APサーバプログラム200でリクエスト処理を行うたびに、リクエスト処理で使用したセッション情報に関しては徐々に二重化されていく。しかし、完全にセッション情報が二重化されるまでに待機系Web APサーバプログラム300に障害が起きた場合、その時点で二重化されていないセッション情報は失われてしまう。
【００８４】
このような事態に備えて、再接続時の処理として、リクエスト処理が行われなくても、待機系Web APサーバプログラム300にのみ存在するセッション情報を、再起動してきた正常系Web APサーバプログラム200へまとめて送信する、セッション情報二重化復旧処理209を行ってもよい。
【００８５】
以上のように、正常系又は待機系のWeb APサーバプログラムの単独稼動の状態から、もう一方のペアのWeb APサーバプログラムが再起動すれば、再び正常稼動に復旧することが可能である。
【００８６】
以上の動作手順により、本発明の目的は達成でき、かつWeb APサーバが再起動することによって、正常時に復旧することができる。
【００８７】
次に、本実施例の構成とその動作について詳細に説明する。
図４には、Webサーバプログラム100がメモリ上に作成する転送先Web APサーバペア群決定テーブル102の構成を示す。転送先Web APサーバペア群決定テーブル102は、Webサーバプログラム100が受信したHTTPリクエスト901の宛先URLから転送先Web APサーバペア群を求めるためのテーブルであり、URLパターン110と転送先Web APサーバペア群111を有する。本テーブルは、リクエストのURLとテーブルのエントリにあるURLパターン110が適合するかどうか調べることによって、リクエストのURLに対応した、転送先Web APサーバペアのIDを１つ又は複数知ることができる。リクエストのURLとURLパターン110との適合を調べる方法は本発明と関係ないので説明を省略する。本テーブルは、典型的にはWebサーバプログラム100起動時にWebサイト管理者505から与えられる。
【００８８】
図５には、Webサーバプログラム100がメモリ上に作成するWeb APサーバペア定義テーブル103の構成を示す。Web APサーバペア定義テーブル103はWeb APサーバペアID120、正常系Web APサーバと通信するためのネットワークアドレスである正常系ネットワークアドレス121、待機系Web APサーバと通信するためのネットワークアドレスである待機系ネットワークアドレス122と、ペアの中で最近リクエスト処理を行ったWeb APサーバを示すアクティブサーバ123を有する。アクティブサーバ123が取る値は、正常系という文字列か待機系という文字列のどちらかである。アクティブサーバ123の値は、Webサーバが、HTTPリクエストをWeb APサーバペアの正常系と待機系のどちらに先にリクエストを転送するか判断するために用いる。
【００８９】
アクティブサーバ123は、Webサーバプログラム100がWeb APサーバプログラムとの通信時に障害を検知するか、又は、処理辞退通知をWeb APサーバプログラムから受け取ったときに、そのWeb APサーバプログラムのペアの系を示す文字列に更新される。これにより、Webサーバプログラム100が極力、リクエスト処理を行えないWeb APサーバプログラムと通信を行ってしまう回数を減らしている。本テーブルは、Web APサーバペアIDから、正常系ネットワークアドレス121、待機系ネットワークアドレス122とアクティブサーバ123を求めることができる。本テーブルのエントリは、典型的にはWebサーバプログラム100起動時にWebサイト505管理者から与えられる。
【００９０】
図６には、DBMSプログラム400を介してDBMS用計算機513の二次記憶401上に作成されるサーバペア状態管理テーブル402の構造を示す。サーバペア状態管理テーブル402はDBMSプログラム400が管理するリレーショナルデータベースのテーブルであり、Web APサーバペアID410とサーバペア状態411を有する。正常系又は待機系のWeb APサーバプログラムは、Web APサーバペアID410をキーにして、サーバペア状態411を更新又は参照するSQLをDBMSに送信し、その結果、本テーブルの該当するエントリが操作される。このテーブルはWeb APサーバペア起動前に、Webサイト管理者505が作成しておく。サーバペア状態411に格納される値は、Web APサーバペアが正常に稼動していることを示す文字列である正常稼動、正常系Web APサーバプログラム200だけが稼動していることを示す文字列である正常系単独稼動、待機系Web APサーバプログラム300だけが稼動していることを示す文字列である待機系単独稼動のいずれかである。
【００９１】
図１６には、Web APサーバプログラムがWebブラウザ504に対して発行するセッションID930の構成を示す。セッションID930はWeb APサーバペア内でセッション情報を一意に識別するためのIDとWeb APサーバペアを一意に識別するためのWeb APサーバペアIDからなる。Webサーバプログラムでは、HTTPリクエストに含まれるセッションID930から、Web APサーバペアIDを取得し、そのリクエストを転送すべきWeb APサーバペアを決定する。
【００９２】
図７には、Webサーバプログラム100がリクエストを受信する度に実行する、リクエスト選択転送処理のPAD図を示す。この処理では、リクエストのURLに基づいて、リクエストの転送を行うか否か判断し、転送を行う場合には、転送先Web APサーバペアを決定して、決定したペアのうち、最近リクエスト処理を行ったWeb APサーバプログラムにリクエストを転送する。また、リクエスト転送時にエラーが発生した場合やWeb APサーバプログラムからのレスポンスとして、処理辞退通知を受け取った場合には、もう一方のペアのWeb APサーバプログラムにリクエストを転送する。
【００９３】
（ステップ130） Webサーバプログラム100はWebブラウザ504から受信したHTTPリクエスト901のURLを参照し、そのURLが転送先Web APサーバペア群決定テーブル102に登録されているエントリのURLパターン110に適合するかどうか調べる。適合するURLパターン110を持つエントリがある場合には、ステップ131を実行する。適合するURLパターン110を持つエントリがない場合にはステップ132を実行する。
【００９４】
（ステップ131） Webサーバプログラム100は、リクエストのURLが適合したURLパターン110を持つエントリのWeb APサーバペア群のサーバペアIDを転送先Web APサーバペア群決定テーブル102から求め、ステップ133を実行する。
【００９５】
（ステップ132） Web サーバプログラム100は、Web APサーバペア群決定テーブル102から転送先Web APサーバペア群を求めることができなかったので、URLに対するHTMLファイルや画像ファイルをWebブラウザに返信する。この処理は汎用のWebサーバに備わっている処理なので、説明は省略する。
【００９６】
（ステップ133） Webサーバプログラム100は、受信したHTTPリクエスト901にセッションID930が含まれているか判断する。セッションID930が含まれている場合には、ステップ134を実行する。セッションID930が含まれていない場合にはステップ136を実行する。
【００９７】
（ステップ134） Webサーバプログラム100は、ステップ131で求めた１つ又は複数のWeb APサーバペアIDのいずれかと、ステップ133で求めたセッションID930に含まれるWeb APサーバペアIDが一致するかどうか判断する。一致する場合には、ステップ135を実行する。一致しない場合には、ステップ136を実行する。
【００９８】
（ステップ135） Webサーバプログラム100は、ステップ134で一致したWeb APサーバペアIDを持つWeb APサーバペアを転送先Web APサーバペアに設定し、ステップ137を実行する。
【００９９】
（ステップ136） Web APサーバプログラム100は、ステップ131で求めた１つ又は複数のWeb APサーバペアIDの中からランダムに１つ選択し、そのIDを持つWeb APサーバペアを転送先Web APサーバペアに設定する。
【０１００】
（ステップ137） Webサーバプログラム100は、ステップ135又はステップ136で決定した転送先Web APサーバペアのIDがWebサーバペア定義テーブル103に登録されているエントリのWeb APサーバペアID120と一致するかどうか調べる。一致する場合には、ステップ138を実行する。一致しない場合には、ステップ139を実行する。
【０１０１】
（ステップ138） Webサーバプログラム100は、転送先Web APサーバペアのIDと一致するWeb APサーバペアID120を持つエントリのアクティブサーバ123をWeb APサーバペア定義テーブル103から求め、ステップ140を実行する。
【０１０２】
（ステップ139） Webサーバプログラム100は、転送先Web APサーバペアに対応するエントリがないため、リクエスト処理をエラーで終了する。
【０１０３】
（ステップ140） Webサーバプログラム100は、ステップ141からステップ14７までの処理を、正常系Web APサーバプログラム200と待機系Web APサーバプログラム300の双方にリクエストを転送するまで繰り返す。ただし、このループを実行中に、リクエストの転送に成功した場合には、このループを抜けてステップ148を実行する。
【０１０４】
（ステップ141）Webサーバプログラム100は、転送先Web APサーバペアのIDと一致するWeb APサーバペアID120を持つエントリのアクティブサーバ123を求める。そして、アクティブサーバの値が正常系であれば、一致したエントリの正常系ネットワークアドレスにリクエストを転送し、アクティブサーバの値が待機系であれば、一致したエントリの待機系ネットワークアドレスにリクエストを転送する。そして、リクエストを転送した後、ステップ142を実行する。
【０１０５】
（ステップ142） Webサーバプログラム100は、リクエストの転送時にエラーが起きた場合には、ステップ143を実行する。エラーが起きなかった場合には、ステップ144を実行する。
【０１０６】
（ステップ143） Webサーバプログラム100は、ステップ138で求めたエントリのアクティブサーバが正常系であれば、そのエントリのアクティブサーバを待機系に設定し、ステップ138で求めたエントリのアクティブサーバが待機系であれば、そのエントリのアクティブサーバを正常系に設定し、ループの先頭に戻る。
【０１０７】
（ステップ144）Webサーバプログラム100は、リクエストを転送したWeb APサーバプログラムからのレスポンスを受信待ちし、受信の時点でエラーが起きた場合には、ステップ145を実行する。また、Web APサーバプログラムからのレスポンスを受信した場合には、ステップ146を実行する。
【０１０８】
（ステップ145） Webサーバプログラム100は、先にリクエストを転送したWeb APサーバプログラムでリクエスト処理がされているかもしれないので、二重処理を避けるために、リクエスト処理をエラーで終了する。
【０１０９】
（ステップ146） Webサーバプログラム100は、Web APサーバプログラムから受信したレスポンスが、処理辞退通知である場合、ステップ143を実行する。処理辞退通知でなければ、ステップ147を実行する。
【０１１０】
（ステップ147）Webサーバプログラム100は、Web APサーバプログラムから受信したHTTPレスポンス902をWebブラウザ504に返信して、ステップ140のループを抜けて、ステップ148を実行する。
【０１１１】
（ステップ148） Webサーバプログラム100は、この時点でWebブラウザにHTTPレスポンス902を返信していないならば、ステップ149を実行する。返信していれば、リクエスト選択転送処理101を終了する。
【０１１２】
（ステップ149） Webサーバプログラム100は、Webブラウザ504にエラーを返信する。
【０１１３】
図８には、正常系Web APサーバプログラム200が起動時に実行する正常系初期化処理201のPAD図を示す。この処理では、待機系Web APサーバプログラム300とのコネクションを確立するまで、待機系Web APサーバ300へのコネクション確立要求911の送信を繰り返し、コネクションを確立したら、サーバペア状態管理テーブル402のサーバペア状態411とサーバペア状態キャッシュ208の値を正常稼動に更新する。
【０１１４】
（ステップ210、211） 正常系Web APサーバプログラム200は、待機系Web APサーバプログラム300とコネクションを確立するまで、コネクション確立要求911を繰り返し送信する。コネクションを確立した場合には、ステップ212を実行する。
【０１１５】
（ステップ212）正常系Web APサーバプログラム200は、コネクションを確立すると、正常に稼動できると判断して、サーバペア状態管理テーブル402のサーバペア状態411を正常稼動に更新するためのサーバペア状態更新SQL921をDBMSプログラム400に送信して、ステップ213を実行する。
【０１１６】
（ステップ213）正常系Web APサーバプログラム200は、DBMSプログラム400との通信でエラーが発生した場合、ステップ214を実行する。エラーが発生しなければステップ215を実行する。
【０１１７】
（ステップ214）正常系Web APサーバプログラム200は、サーバペア状態管理テーブル402のサーバペア状態411を更新できなかったため、初期化処理に失敗して、エラー終了する。
【０１１８】
（ステップ215）正常系Web APサーバプログラム200は、サーバペア状態管理テーブル402のサーバペア状態411のキャッシュであるサーバペア状態キャッシュ208の値を正常稼動に更新して、正常系初期化処理201を終了する。
【０１１９】
図９には、待機系Web APサーバプログラム300が起動時に実行する待機系初期化処理301のPAD図を示す。この処理では、正常系Web APサーバプログラム200とのコネクションを確立するまで、コネクション確立要求911を受信待ちし、コネクションを確立したら、サーバペア状態キャッシュ208の値を正常稼動に更新する。
以上の正常系初期化処理201と待機系初期化処理301により、正常系Web APサーバプログラム200と待機系Web APサーバプログラム300間のコネクションが確立され、正常に稼動する準備が整う。
【０１２０】
図１７には、正常系Web APサーバプログラム200がHTTPリクエスト901を受信した時の処理のPAD図を示す。正常系Web APサーバプログラム200はHTTPリクエスト901をWebサーバプログラム100から受信すると、まず、セッション情報無効化要求送信処理202を実行し、その後、アプリケーション実行処理203、そして、セッション情報に重化要求送信処理204を実行する。
【０１２１】
図１８には、待機系Web APサーバプログラム300がHTTPリクエスト901を受信した時の処理のPAD図を示す。待機系Web APサーバプログラム300はHTTPリクエスト901をWebサーバプログラム100から受信すると、まず、引き継ぎ判定処理307を実行し、その後、アプリケーション実行処理203を実行する。
【０１２２】
図１０には、正常系Web APサーバプログラム200がリクエストを受信後、はじめに実行するセッション情報無効化要求送信処理202のPAD図を示す。
【０１２３】
（ステップ260）正常系Web APサーバプログラム200は、自身のサーバペア状態キャッシュ208を参照して、その値が正常系単独稼動であれば、ステップ261を実行する。そうでなければ、ステップ262を実行する。
【０１２４】
（ステップ261）正常系Web APサーバプログラム200は、単独稼動状態であるため、待機系との通信を行う必要がない。よって、セッション情報無効化要求送信処理202を正常に終了する。
【０１２５】
（ステップ262）正常系Web APサーバプログラム200は、自身のサーバペア状態キャッシュ208を参照して、その値が待機系単独稼動であれば、ステップ263を実行する。そうでなければ、ステップ264を実行する。
【０１２６】
（ステップ263）正常系Web APサーバプログラム200は、自身が停止しつつあり、リクエスト処理ができない状態であるため、Webサーバプログラム100に処理辞退通知903を送信し、リクエスト処理を中断する。
【０１２７】
（ステップ264）正常系Web APサーバプログラム200は受信したHTTPリクエスト901にセッションID930が含まれているかどうか判断する。セッションID930が含まれている場合には、ステップ265を実行する。セッションID930が含まれていない場合にはステップ266を実行する。
【０１２８】
（ステップ265）正常系Web APサーバプログラム200は、HTTPリクエスト901に含まれているセッションID930を取得して、ステップ267を実行する。
【０１２９】
（ステップ266）正常系Web APサーバプログラム200は、HTTPリクエスト901にセッションID930が含まれていなかったため、新しいセッションID930を発行し、セッション情報を新規作成して、セッション情報無効化要求送信処理202を終了する。
【０１３０】
（ステップ267）正常系Web APサーバプログラム200は、ステップ265で取得したセッションID930に対応するセッション情報が正常系Web APサーバプログラムのメモリ上にあるかどうか判断する。メモリ上にある場合にはステップ268を実行し、ない場合にはステップ269を実行する。
【０１３１】
（ステップ268）正常系Web APサーバプログラム200は、ステップ265で取得したセッションID930をセッション情報無効化要求912に含めて、その要求を待機系Web APサーバプログラム300へ送信し、ステップ270を実行する。
【０１３２】
（ステップ269）正常系Web APサーバプログラム200は、ステップ265で取得したセッションID930をセッション情報取得要求917に含めて、その要求を待機系Web APサーバプログラム300へ送信し、ステップ270を実行する。
【０１３３】
（ステップ270）正常系Web APサーバプログラム200は、セッション情報無効化要求912又はセッション情報取得要求917の送信に失敗した場合、稼動サーバ判定処理206を実行後、ステップ262を実行する。送信が成功した場合にはステップ271を実行する。
【０１３４】
（ステップ271）正常系Web APサーバプログラム200は、待機系Web APサーバプログラム300からの応答を受信する。受信時にエラーが起きた場合には、稼動サーバ判定処理206を実行後、ステップ262を実行する。受信に成功した場合、セッション情報無効化要求送信処理202を正常に終了する。
【０１３５】
（ステップ272）正常系Web APサーバプログラム200は、待機系Web APサーバプログラム300から受信した応答が、セッション情報取得応答918かどうか判断し、セッション情報取得応答918であればステップ273を実行する。セッション情報取得応答918でなければ、セッション情報無効化要求送信処理202を終了する。
【０１３６】
（ステップ273）正常系Web APサーバプログラム200は、受信したセッション情報取得応答918に含まれるセッション上を取得し、メモリ上に保存する。そして、セッション情報無効化要求送信処理202を終了する。
【０１３７】
図１１には、待機系Web APサーバプログラム300が、正常系Web APサーバプログラム200からセッション情報無効化要求912又はセッション情報取得要求917を受け取った時に行う、セッション情報無効化処理302のPAD図を示す。
【０１３８】
（ステップ320）待機系Web APサーバプログラム300は、受信した要求がセッション情報無効化要求912であるかセッション情報取得要求917であるかを判断する。セッション情報無効化要求912であれば、ステップ321を実行し、セッション情報取得要求917でれば、ステップ325を実行する。
【０１３９】
（ステップ321）待機系Web APサーバプログラム300は、正常系Web APサーバプログラム200から受信したセッション情報無効化要求912に含まれるセッションID930を取得してステップ322を実行する。
【０１４０】
（ステップ322）待機系Web APサーバプログラム300は、取得したセッションID930を持つセッション情報を検索し、そのセッション情報を削除して、ステップ323を実行する。セッション情報が見つからない場合には何もせずにステップ323を実行する。
【０１４１】
（ステップ323）待機系Web APサーバプログラム300は、セッション情報無効化応答913を正常系Web APサーバプログラム200に送信する。
【０１４２】
（ステップ324）待機系Web APサーバプログラム300は、セッション情報無効化応答913の送信時にエラーが起きた場合には稼動サーバ判定処理206を実行する。
【０１４３】
（ステップ325）待機系Web APサーバプログラム300は、正常系Web APサーバプログラム200から受信したセッション情報取得要求917に含まれるセッションID930を取得してステップ326を実行する。
【０１４４】
（ステップ326）待機系Web APサーバプログラム300は、取得したセッションID930を持つセッション情報を検索し、そのセッション情報を取得して、ステップ327を実行する。
【０１４５】
（ステップ327）待機系Web APサーバプログラム300は、ステップ326で取得したセッション情報をセッション情報取得応答918に含め、正常系Web APサーバプログラム200に送信し、ステップ328を実行する。
【０１４６】
（ステップ328）待機系Web APサーバプログラム300は、セッション情報取得応答918の送信時にエラーが起きた場合には稼動サーバ判定処理206を実行し、ステップ329を実行する。エラーが起きなかった場合にはステップ329を実行する。
【０１４７】
（ステップ329）待機系Web APサーバプログラム300は、ステップ326で取得したセッション情報を削除する。
【０１４８】
正常系Web APサーバプログラム200はリクエスト受信後、セッション情報無効化要求送信処理202を行った後に、アプリケーション実行処理203を実行する。本処理は、汎用のWeb APサーバプログラムに備わっている処理なので詳細は省略する。
【０１４９】
図１２には、正常系Web APサーバプログラム200が、アプリケーション実行処理後にアプリケーションがリクエスト処理で使用したセッション情報を二重化するためのセッション情報二重化要求送信処理204のPAD図を示す。
【０１５０】
（ステップ230）正常系Web APサーバプログラム200は、リクエスト処理に使用したセッション情報とセッションID930をセッション情報二重化要求914に含めて、待機系Web APサーバプログラム200に送信して、ステップ231を実行する。
【０１５１】
（ステップ231）正常系Web APサーバプログラム200は、セッション情報二重化要求914の送信でエラーが起きた場合には、稼動サーバ判定処理206を実行後、ステップ232を実行する。エラーが起きなければステップ234を実行する。
【０１５２】
（ステップ232）正常系Web APサーバプログラム200は、自身のサーバペア状態キャッシュ208を参照して、その値が待機系単独稼動であれば、ステップ233を実行する。
【０１５３】
（ステップ233）正常系Web APサーバプログラム200は、自身が停止しつつあり、リクエスト処理ができない状態であるため、Webサーバプログラム100に処理辞退通知903を送信し、リクエスト処理を中断する。
【０１５４】
（ステップ234）正常系Web APサーバプログラム200は、セッション情報二重化応答915を受信する。受信待ちの際にエラーが起きた場合には、稼動サーバ判定処理206を実行する。セッション情報二重化応答915を受信した後、セッション情報二重化要求送信処理204を正常に終了する。
【０１５５】
図１３には、待機系Web APサーバプログラム300が、正常系Web APサーバプログラム200からセッション情報二重化要求914を受け取った時に行う、セッション情報二重化処理304のPAD図である。
【０１５６】
（ステップ330）待機系Web APサーバプログラム300は、正常系Web APサーバプログラム200から受信したセッション情報二重化要求912に含まれるセッション情報とセッションID930を取得してステップ331を実行する。
【０１５７】
（ステップ331）待機系Web APサーバプログラム300は、ステップ330で取得したセッション情報を取得したセッションID930と対応つけて、メモリ上に保存する。
【０１５８】
（ステップ332）待機系Web APサーバプログラム300は、セッション情報二重化応答913を正常系Web APサーバプログラム200に送信する。
【０１５９】
（ステップ333）待機系Web APサーバプログラム300は、セッション情報二重化応答913の送信時にエラーが起きた場合には稼動サーバ判定処理206を実行する。
図１４には、正常系Web APサーバプログラム200および待機系Web APサーバプログラム300が通信エラーを検知した場合に実行する稼動サーバ判定処理206のPAD図である。
【０１６０】
（ステップ240）Web APサーバプログラムは、サーバペア状態411を取得するために、サーバペア状態参照SQL921をDBMSプログラム400へ送信する。
【０１６１】
（ステップ241）Web APサーバプログラムは、サーバペア状態参照SQL922の送信時にエラーが起きた場合には、ステップ242を実行する。エラーが起きなかった場合には、ステップ243を実行する。
【０１６２】
（ステップ242）Web APサーバプログラムは、DBMSプログラム400との通信ができないため、自身のサーバペア状態キャッシュ208をペアとなるWeb APサーバプログラムの単独稼動として、サーバの稼動を停止する。
【０１６３】
（ステップ243）Web APサーバプログラムは、サーバペア状態411を受信する。
（ステップ244）Web APサーバプログラムは、サーバペア状態411の受信時にエラーが起きた場合、ステップ242を実行する。
【０１６４】
（ステップ245）Web APサーバプログラムは、受信したサーバペア状態411がペアとなるWeb APサーバプログラムの単独稼動の場合、ステップ246を実行する。それ以外ならステップ247を実行する。
【０１６５】
（ステップ246）Web APサーバプログラムは、ペアとなるWeb APサーバプログラムが先にサーバペア状態411にアクセスしたと判断し、自身のサーバペア状態キャッシュ208をペアとなるWeb APサーバプログラムの単独稼動として自身は稼動を停止する。
【０１６６】
（ステップ247）Web APサーバプログラムは、サーバペア状態411を自身の単独稼動にするためのサーバペア更新SQL921をDBMSプログラム400に送信する。
【０１６７】
（ステップ248）Web APサーバプログラムは、サーバペア状態参照SQL921の送信時にエラーが起きた場合には、ステップ242を実行する。
【０１６８】
（ステップ249）Web APサーバプログラムは、自身のサーバペア状態キャッシュ208を自身の単独稼動に更新する。
【０１６９】
図１５には、待機系でリクエスト受信時にはじめに実行する引き継ぎ判定処理307のPAD図である。
【０１７０】
（ステップ340）待機系Web APサーバプログラム300は、自身のサーバペア状態キャッシュ208を参照して、その値が待機系単独稼動であれば、ステップ341を実行する。そうでなければステップ342を実行する。
【０１７１】
（ステップ341）待機系Web APサーバプログラム300は、既にリクエスト処理を実行可能な状態であるため、引き継ぎ判定処理307を正常に終了する。
【０１７２】
（ステップ342）待機系Web APサーバプログラム300は、自身のサーバペア状態キャッシュ208を参照して、その値が正常系単独稼動であれば、ステップ343を実行する。そうでなければステップ344を実行する。
【０１７３】
（ステップ343）待機系Web APサーバプログラム300は、自身が停止しつつあり、リクエスト処理ができない状態であるため、Webサーバプログラム100に処理辞退通知903を送信し、リクエスト処理を中断する。
【０１７４】
（ステップ344）待機系Web APサーバプログラム300は、正常系Web APサーバプログラム200の稼動を確認するために、稼動確認用メッセージ916を正常系Web APサーバプログラム200に送信して、ステップ345を実行する。
【０１７５】
（ステップ345）待機系Web APサーバプログラム300は、稼動確認用メッセージ916の送信時にエラーが起きると、稼動サーバ判定処理206を実行後、ステップ346を実行する。エラーが起きなければ、ステップ347を実行する。
【０１７６】
（ステップ346）待機系Web APサーバプログラム300は、自身のサーバペア状態キャッシュ208を参照して、その値が待機系単独稼動であれば、ステップ341を実行する。そうでなければステップ343を実行する。
【０１７７】
（ステップ347）待機系Web APサーバプログラム300は、正常系Web APサーバプログラム200から送信される稼動確認用メッセージ916を受信して、ステップ348を実行する。
【０１７８】
（ステップ348）待機系Web APサーバプログラム300は、稼動確認用メッセージ916の受信時にエラーが起きると、稼動サーバ判定処理206を実行後、ステップ346を実行する。エラーが起きなければ、ステップ349を実行する。
【０１７９】
（ステップ349）待機系Web APサーバプログラム300は、Web APサーバペアが正常稼動であることを確認したため、自身ではリクエスト処理を実行できないと判断する。そのため、Webサーバプログラム100に処理辞退通知903を送信し、リクエスト処理を中断する。
【０１８０】
また、正常系再接続処理207は正常系初期化処理201と同様の処理で実現可能であり、待機系再接続処理308は待機系初期化処理301と同様の処理で実現可能である。
【０１８１】
以上説明した本実施例によれば、本発明が解決しようとする２つの課題が解決される。すなわち、正常系Web APサーバの障害がどのタイミングで発生しても、待機系Web APサーバが古いセッション情報を参照しないように保証しつつ、可能な限りユーザの処理を継続することができる。
【０１８２】
正常系Web APサーバと待機系Web APサーバ間の通信に障害が発生した場合に、正常系Web APサーバと待機系Web APサーバ間の系の不整合を生じさせないために、確実にどちらか片方のWeb APサーバだけが稼動を続ける方法をソフトウェアだけで実現することができる。
【０１８３】
本実施例では、正常系と待機系から成るサーバプログラムの冗長構成により、正常系サーバプログラムの障害時に待機系サーバプログラムが処理を引き継ぐフェイルオーバ処理方法を説明した。特に、正常時には正常系サーバプログラムのリクエスト処理毎に、リクエスト処理で使用したメモリ上のデータを待機系サーバプログラムのメモリ上に二重化しておき、いずれかのサーバに障害が起きた場合にも、古いデータを参照しないことを保証しつつ、可能な限り処理を引き継ぐフェイルオーバ処理方法が提供できる。
【０１８４】
本実施例は課題を解決するために、正常系Web APサーバと待機系Web APサーバのメモリ上で二重化してあるセッション情報が古くなる場合には、古くなるデータを事前に無効化するようにする。尚、データの無効化する場合には、データを削除してもよいし、データが無効であることを示すフラグや識別子をデータに付与してもよいし、当該データへのアクセス制限をかけてもよいし、その他の方法でもよい。
【０１８５】
具体的には、正常系Web APサーバでのリクエスト処理開始前に、待機系Web APサーバにこれから正常系Web APサーバで更新するセッション情報のバックアップを無効化するように要求を行い、それに従って待機系Web APサーバではセッション情報のバックアップを無効化することにする。これにより、正常系Web APサーバでのリクエスト処理を開始してから、リクエスト処理後に待機系Web APサーバにセッション情報を二重化するまでの間は、セッション情報は二重化されていないものの、正常系Web APサーバと待機系Web APサーバとで内容の異なるセッション情報が存在してしまうことがなくなる。
【０１８６】
また、正常系Web APサーバと待機系Web APサーバ間の通信に障害が発生した場合には、双方のサーバは障害を検知した時点で、データベースの特定のレコードに排他的なアクセスを行い、先にアクセスできた方のサーバが稼動を続け、後からアクセスした方のサーバは自発的に停止することにする。これにより、通信障害が起きた場合に確実にどちらか一方のサーバだけで稼動を続けることがソフトウェアだけで実現できる。
【０１８７】
また、本実施例においては、正常系サーバと待機系サーバとを用いたフェイルオーバ処理方法であって、正常系サーバが、第一のリクエストを受信し、当該第一のリクエストの処理で使用した第一のセッション情報を読み出し、待機系サーバの記憶装置へ第一のセッション情報をコピーして格納し、正常系サーバが、第二のリクエストを受信した場合に、第二のリクエストの処理を開始する前に、前記待機系サーバの記憶装置に格納された前記第一のセッション情報を無効化することが可能となる。
【０１８８】
本実施例によれば、Webアプリケーションサーバにどのタイミングで障害が発生しても、処理を引き継ぐWebアプリケーションサーバが古いセッション情報を用いることなく、リクエスト処理を継続することが可能となる。また、セッション情報の二重化のためのWebアプリケーションサーバ間の通信に障害が起きても、古いセッション情報を用いることなく、リクエスト処理を継続することが可能となる。
【図面の簡単な説明】
【０１８９】
【図１】本実施例のWebサイト500内のシステム構成の詳細図の例である。
【図２】本実施例のシステム構成図の例である。
【図３】本実施例のWebサイト500内のシステム構成の概要図の例である
【図４】Web APサーバペア群決定テーブル102の構成図の例である。
【図５】Web APサーバペア定義テーブル103の構成図の例である。
【図６】サーバペア状態管理テーブル402の構成図の例である。
【図７】リクエスト選択転送処理101のPAD図の例である。
【図８】正常系初期化処理201のPAD図の例である。
【図９】待機系初期化処理301のPAD図の例である。
【図１０】セッション情報無効化要求送信処理202のPAD図の例である。
【図１１】セッション情報無効化処理302のPAD図の例である。
【図１２】セッション情報二重化要求送信処理204のPAD図の例である。
【図１３】セッション情報二重化処理304のPAD図の例である。
【図１４】稼動サーバ判定処理206のPAD図の例である。
【図１５】引き継ぎ判定処理307のPAD図の例である。
【図１６】セッションID930の構成図の例である。
【図１７】正常系Web APサーバプログラム200のリクエスト受信時の処理のPAD図の例である。
【図１８】待機系Web APサーバプログラム300のリクエスト受信時の処理のPAD図の例である。
【符号の説明】
【０１９０】
100…Webサーバプログラム、101…リクエスト選択転送処理、102…転送先Web APサーバペア群決定テーブル、103…Web APサーバペア定義テーブル、200…正常系Web APサーバプログラム、201…正常系初期化処理、202…セッション情報無効化要求送信処理、203…アプリケーション実行処理、204…セッション情報二重化処理、205…稼動状態監視処理、206…稼動サーバ判定処理、207…正常系再接続処理、208…サーバペア状態キャッシュ、300…待機系Web APサーバプログラム、301…待機系初期化処理、302…セッション情報無効化処理、304…セッション情報二重化処理、307…引き継ぎ判定処理、308…待機系再接続処理、400…DBMSプログラム、401…二次記憶装置、402…サーバペア状態管理テーブル、500…Webサイト、501…ネットワーク、502…端末装置、503…ホームページ閲覧者、504…Webブラウザ、505…Webサイト管理者、510…Webサーバ用計算機、511…正常系Web APサーバ用計算機、512…待機系Web APサーバ用計算機、513…DBMS用計算機
【図１】
2005135125.tif 000003
【図２】
2005135125.tif 000004
【図３】
2005135125.tif 000005
【図４】
2005135125.tif 000006
【図５】
2005135125.tif 000007
【図６】
2005135125.tif 000008
【図７】
2005135125.tif 000009
【図８】
2005135125.tif 000010
【図９】
2005135125.tif 000011
【図１０】
2005135125.tif 000012
【図１１】
2005135125.tif 000013
【図１２】
2005135125.tif 000014
【図１３】
2005135125.tif 000015
【図１４】
2005135125.tif 000016
【図１５】
2005135125.tif 000017
【図１６】
2005135125.tif 000018
【図１７】
2005135125.tif 000019
【図１８】
2005135125.tif 000020