(57)【要約】【課題】クライアントにサービスを継続して提供する。【解決手段】ルータ１７は、クライアント１５からのパケットを複数のｓＬＢ１００に送信する。複数のｓＬＢ１００は、複数のｓＬＢ１００間で同一の振り分け論理に基づいて、クライアント１５からのパケットをカプセル化して、複数のサーバ２０のいずれかに送信する。複数のサーバ２０は、クライアント１５からのパケットをデカプセル化して、クライアント１５にサービスに対応した処理を行う。複数のｓＬＢ１００は、相互にデータ通信を実行し、いずれかのｓＬＢ１００の故障を検出した場合に、故障したｓＬＢ１００の情報をルータ１７に通知する。ルータ１７は、故障したロードバランサを振り分け対象から除外する。【選択図】図１
2018148537.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと、前記クライアントにサービスを提供する複数のサーバと、前記複数のサーバに処理を割り振る複数のロードバランサと、前記複数のロードバランサに前記クライアントからのパケットを割り振るスイッチとを含む通信制御システムであって、
前記スイッチは、前記クライアントからのパケットを前記複数のロードバランサのいずれかに送信し、
前記複数のロードバランサは、前記複数のロードバランサ間で同一の振り分け論理に基づいて、前記クライアントからのパケットをカプセル化して、前記複数のサーバのいずれかに送信し、
前記複数のサーバは、前記カプセル化されたパケットをデカプセル化し、前記デカプセル化したパケットに基づいて前記サービスに対応した処理を行い、
前記複数のロードバランサは、相互にデータ通信し、いずれかのロードバランサの故障を検出した場合に、故障したロードバランサの情報を前記スイッチに通知し、前記通知を受けたスイッチは、前記故障したロードバランサを振り分け対象から除外する
ことを特徴とする通信制御システム。
【請求項２】
前記複数のロードバランサは、サーバの数が増加または減少した場合に、前記振り分け論理を変更し、変更後の振り分け論理を共有することを特徴とする請求項１に記載の通信制御システム。
【請求項３】
前記振り分け論理は、前記クライアントから送信されるパケットの値に基づくハッシュ値と、パケットの振り分け先となるサーバとを対応付けた振り分け情報、および、前記パケットの値と、振り分け先となるサーバとを対応付けたフロー情報を有し、前記複数のロードバランサは、前記クライアントからのパケットの値が、前記フロー情報に存在しない場合に、前記振り分け情報に基づいて、パケットの振り分け先となるサーバを判定することを特徴とする請求項１または２に記載の通信制御システム。
【請求項４】
前記振り分け論理は、前記サーバが提供するサービス種別毎に異なる振り分け情報が対応付けられていることを特徴とする請求項３に記載の通信制御システム。
【請求項５】
前記通信制御システムは、通信制御装置を更に含み、前記スイッチは、経路情報に基づいて、前記クライアントからのパケットを前記複数のロードバランサのいずれかに送信し、前記ロードバランサは、通信制御装置から停止要求を受け付けた場合には、停止対象のロードバランサを経由する経路の削除要求を、前記スイッチに送信することを特徴とする請求項１〜４のいずれか一つに記載の通信制御システム。
【請求項６】
前記通信制御装置は、停止中のロードバランサを起動させた場合には、前記複数のロードバランサと、起動したロードバランサとの間で、同一の振り分け論理を共有させることを特徴とする請求項５に記載の通信制御システム。
【請求項７】
前記通信制御装置は、サービス種別、日時または曜日に対応付けて起動させるロードバランサを定義した起動定義情報を保持し、前記起動定義情報を基にして、ロードバランサの起動または停止を制御することを特徴とする請求項５または６に記載の通信制御システム。
【請求項８】
前記通信制御装置は、前記複数のロードバランサが共有する同一の振り分け論理の情報を取得して、記憶装置に格納し、全てのロードバランサが故障して復旧した後に、前記記憶装置に格納した振り分け論理の情報を前記ロードバランサに通知することを特徴とする請求項５、６または７に記載の通信制御システム。
【請求項９】
コンピュータに、
クライアントからのパケットを、複数のロードバランサのいずれかに送信するスイッチから受信した場合に、複数のロードバランサ間で同一の振り分け論理に基づいて、受信したパケットをカプセル化して、前記クライアントにサービスを提供する複数のサーバのうちいずれかのサーバに送信し、
複数のロードバランサとの間でデータ通信し、いずれかのロードバランサの故障を検出した場合に、故障したロードバランサの情報を前記スイッチに通知し、故障したロードバランサを振り分け対象から除外する
処理を実行させることを特徴とする通信制御プログラム。
【請求項１０】
クライアントと、前記クライアントにサービスを提供する複数のサーバと、前記複数のサーバに処理を割り振る複数のロードバランサと、複数のロードバランサに前記クライアントからの通信を割り振るスイッチとを含む通信制御システムの制御方法であって、
前記スイッチは、前記クライアントからのパケットを前記複数のロードバランサのいずれかに送信し、
前記複数のロードバランサは、前記複数のロードバランサ間で同一の振り分け論理に基づいて、前記クライアントからのパケットをカプセル化して、前記複数のサーバのいずれかに送信し、
前記複数のサーバは、前記カプセル化されたパケットをデカプセル化し、前記デカプセル化したパケットに基づいて前記サービスに対応した処理を行い、
前記複数のロードバランサは、相互にデータ通信し、いずれかのロードバランサの故障を検出した場合に、故障したロードバランサの情報を前記スイッチに通知し、前記通知を受けたスイッチは、前記故障したロードバランサを振り分け対象から除外する
ことを特徴とする通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御システム等に関する。
【背景技術】
【０００２】
仮想化技術の進展に伴い、サービスの需要に応じてサーバをスケールアウトまたはスケールインし、サーバにサービスを提供させるシステムが浸透している。図３５は、従来のシステムの一例を示す図である。図３５に示すように、このシステムは、クライアント１と、ルータ３と、ＬＢ（LoadBalancer）５ａ、５ｂと、サーバ１０ａ、１０ｂ、・・・、１０ｃとを有する。以下の説明では、適宜、ＬＢ５ａ、５ｂをまとめて、ＬＢ５と表記する。サーバ１０ａ〜１０ｃをまとめて、サーバ１０と表記する。クライアント１およびルータ３は、インターネット２を介して、相互に接続される。ルータ３と、ＬＢ５とは、図示しないネットワークを介して、相互に接続される。ＬＢ５と、サーバ１０とは、図示しないネットワークを介して、相互に接続される。
【０００３】
図３５に示すモデルを採用するクラウド環境では、特定のサーバ１０への負荷集中を防止するために、サーバ１０の前段にＬＢ５を配置して、負荷分散を行っている。
【０００４】
従来のＬＢ５では、ＬＢ５から見てインターネット２側など外部のインタフェースに、ユーザリクエストを受け付けるＶＩＰ（Virtual  IP）を付与する構成が一般的である。ＶＩＰは、サービスを代表するＩＰアドレスであり、クライアント１は、ＶＩＰを指定することで、ＬＢ５宛にパケットを送信する。図３５に示す例では、クライアント１から送信されたパケットは、ネットワーク１、ルータ３を介して、ＬＢ５に到達する。
【０００５】
ＬＢ５は、クライアント１から受信したパケットのヘッダの情報を基にして、固有の振り分け論理に基づき、振り分け先のサーバを決定する。ＬＢ５は、パケットのヘッダを再構築した後、振り分け先のサーバにパケットを転送する。再構築後のパケットのヘッダには、宛先ＩＰとして、振り分け先のサーバのＩＰが設定される。また、送信元ＩＰとして、ＬＢ５のＩＰが設定される。例えば、ＬＢ５ａがクライアント１からのパケットを、サーバ１０ｃに振り分ける場合には、ＬＢ５ａは、パケットのヘッダの宛先ＩＰとして、サーバ１０ｃのＩＰが設定し、送信元ＩＰに、ＬＢ５ａのＩＰが設定する。上記のように、ＬＢ５は、パケットの終端点の役割を担っている。
【０００６】
ここで、従来技術では、ＬＢ５における耐障害性を考慮して、二重化による冗長構成を取ることがある。このため、サービス運用で予想される最大負荷量に対応可能な性能を持つＬＢ５を、二重化構成で配置することが基本的なＬＢ５の配置方法となる。図３５に示す例では、ＬＢ５ａ、ＬＢ５ｂを配置することで障害対策を行っている。以下の説明では、二重化による冗長構成を、ＡＣＴ−ＳＢＹ構成と表記する。
【０００７】
しかし、ＡＣＴ−ＳＢＹ構成では、急なサービス需要の高まりによりトラフィック量が増加し、ＬＢ５に性能以上の負荷が掛かった場合には、ＬＢ５は、正常に負荷分散を行うことができず、サービスへ影響が出てしまう場合がある。一方、トラフィック量が少ない場合には、システム上に余剰なリソースを、常時確保することになる。また、ＡＣＴ−ＳＢＹ構成では、一方のＬＢ５が稼働している間は、他方のＬＢ５が待機状態となるため、システムとしての稼働率が低くなってしまう。
【０００８】
上記課題に対して、Ｎ−ＡＣＴ構成で、ＬＢ５を動作させる従来技術がある。Ｎ−ＡＣＴ構成では、全ＬＢ５を同時に稼働さるため、ＡＣＴ−ＳＢＹ構成と比較して、システムの稼働率を高めることができる。また、Ｎ−ＡＣＴ構成では、適宜、ＬＢ５をスケールアウト、スケールインすることができるため、トラフィック量の変動に対応することができる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００３−１７４４７３号公報
【特許文献２】特開２００６−１７２２４１号公報
【特許文献３】特表２０１２−５２８５５１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、上述した従来技術では、パケットを転送するＬＢが変更されると、クライアントにサービスを継続して提供することができないという問題がある。
【００１１】
図３６は、従来技術の問題を説明するための図である。例えば、ＬＢ５ａに故障が発生する前の段階において、クライアント１から送信されるパケットは、ＬＢ５ａを介して、サーバ１０ｃに転送されていたとする。ここで、ＬＢ５ａに障害が発生すると、ルータ３は、クライアント１から送信されるパケットを、ＬＢ５ｂに切り替えるため、クライアント１から送信されるパケットの送信元が、ＬＢ５ａの故障前と異なってしまい、サーバ１０ｃは、パケットのフローを一意に特定できず、セッションが切断され、サービスを継続出来ない。
【００１２】
また、Ｎ−ＡＣＴ構成では、各ＬＢ５が、固有の振り分け論理に基づき、パケットの振り分けを行う。このため、クライアント１から送信されたパケットであっても、スケールイン、スケールアウトにより、ＬＢ５が切り替わると、送信元ＩＰが変化し、サーバ１０は、フローを一意に特定できなくなる。
【００１３】
１つの側面では、本発明は、クライアントにサービスを継続して提供することができる通信制御システム、通信制御プログラムおよび通信制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
第１の案では、通信制御システムは、クライアントと、ロードバランサと、スイッチと、通信制御装置を有する。スイッチは、クライアントからのパケットを複数のロードバランサのいずれかに送信する。複数のロードバランサは、複数のロードバランサ間で同一の振り分け論理に基づいて、クライアントからのパケットをカプセル化して、複数のサーバのいずれかに送信する。複数のサーバは、カプセル化されたパケットをデカプセル化し、デカプセル化したパケットに基づいてサービスに対応した処理を行い、複数のロードバランサは、相互にデータ通信し、いずれかのロードバランサの故障を検出した場合に、故障したロードバランサの情報をスイッチに通知する。通知を受けたスイッチは、故障したロードバランサを振り分け対象から除外する。
【発明の効果】
【００１５】
パケットを転送するＬＢが変更されても、クライアントにサービスを継続して提供することができる。
【図面の簡単な説明】
【００１６】
【図１】図１は、本実施例に係るシステムの構成を示す図である。
【図２】図２は、システムの正常時の処理を説明するための図である。
【図３】図３は、パケットのデータ構造の一例を示す図である。
【図４】図４は、フローテーブルのデータ構造の一例を示す図である。
【図５】図５は、振り分けテーブルのデータ構造の一例を示す図である。
【図６】図６は、ｓＬＢパケットのデータ構造の一例を示す図である。
【図７】図７は、レスポンスパケットのデータ構造の一例を示す図である。
【図８】図８は、システムのｓＬＢのスケールイン時の処理を説明するための図である。
【図９】図９は、システムの初期化動作（１）の一例を示す図である。
【図１０】図１０は、起動処理（ステップＳ５１）の一例を示すフローチャートである。
【図１１】図１１は、システムの初期化動作（２）の一例を示す図である。
【図１２】図１２は、起動処理（ステップＳ７１）の一例を示すフローチャートである。
【図１３】図１３は、更新処理（ステップＳ７２）および通知処理（ステップＳ７３）の一例を示すフローチャートである。
【図１４】図１４は、サーバをスケールアウトする処理の一例を示す図である。
【図１５】図１５は、サーバ増設処理（ステップＳ１０３）および通知処理（ステップＳ１０５）の一例を示すフローチャートである。
【図１６】図１６は、更新処理（ステップＳ１０４）の一例を示すフローチャートである。
【図１７】図１７は、サーバをスケールインする処理の一例を示す図である。
【図１８】図１８は、サーバ減設処理（ステップＳ１３１）および通知処理（ステップＳ１３３）の一例を示すフローチャートである。
【図１９】図１９は、更新処理（ステップＳ１３２）の一例を示すフローチャートである。
【図２０】図２０は、ｓＬＢをスケールインする処理の一例を示す図である。
【図２１】図２１は、ｓＬＢ減設処理（ステップＳ１７２）の一例を示すフローチャートである。
【図２２】図２２は、検知処理（ステップＳ１７４）の一例を示すフローチャートである。
【図２３】図２３は、更新処理（ステップＳ１７５）および通知処理（ステップＳ１７６）の一例を示すフローチャートである。
【図２４】図２４は、サーバの故障を検知した場合の処理の一例を示す図である。
【図２５】図２５は、検知処理（ステップＳ２１１）および通知処理（ステップＳ２１３）の一例を示すフローチャートである。
【図２６】図２６は、更新処理（ステップＳ２１２）の一例を示すフローチャートである。
【図２７】図２７は、ｓＬＢの故障を検知した場合の処理の一例を示す図である。
【図２８】図２８は、検知処理（ステップＳ２４１）および通知処理（ステップＳ２４３）の一例を示すフローチャートである。
【図２９】図２９は、更新処理（ステップＳ２４２）の一例を示すフローチャートである。
【図３０】図３０は、本実施例に係るｓＬＢの構成を示す機能ブロック図である。
【図３１】図３１は、ｓＬＢがパケットを送信する処理を示すフローチャートである。
【図３２】図３２は、本実施例に係る保守ノードの構成を示す機能ブロック図である。
【図３３】図３３は、ｓＬＢと同様の機能を実現するコンピュータのハードウェア構成の一例を示す図である。
【図３４】図３４は、保守ノードと同様の機能を実現するコンピュータのハードウェア構成の一例を示す図である。
【図３５】図３５は、従来のシステムの一例を示す図である。
【図３６】図３６は、従来技術の問題を説明するための図である。
【発明を実施するための形態】
【００１７】
以下に、本願の開示する通信制御システム、通信制御プログラムおよび通信制御方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例】
【００１８】
図１は、本実施例に係るシステムの構成を示す図である。図１に示すように、このシステムは、クライアント１５と、ルータ１７ａ、１７ｂと、サーバ２０ａ、２０ｂ、２０ｃと、ｓＬＢ（Scalable  Software  LoadBalancer）１００ａ、１００ｂ、１００ｃと、保守ノード２００とを有する。以下の説明では、適宜、ルータ１７ａ、１７ｂをルータ１７と表記する。サーバ２０ａ〜２０ｃを、サーバ２０と表記する。ｓＬＢ１００ａ〜１００ｃを、ｓＬＢ１００と表記する。クライアント１５は、インターネット（広域イーサネット（登録商標））１６を介して、ルータ１７に接続される。ルータ１７は、ｓＬＢ１００に接続される。サーバ２０、ｓＬＢ１００、保守ノード２００は、ネットワーク１８を介して、相互に接続される。ネットワーク１８は、レイヤ２／レイヤ３のネットワークに対応する。なお、保守ノード２００は、ルータ１７に接続されていても良い。
【００１９】
クライアント１５は、サービス種別に対応するＶＩＰ（Virtual  IP）を宛先アドレスに指定したパケットを送信することで、サービス提供を要求する装置である。クライアント１５が送信するパケットは、ＨＴＴＰコネクションを確立するための、TCP  SYN  Requestに対応する。
【００２０】
ルータ１７は、自身の保持するルーティング情報を確認し、クライアント１５から受信したパケットの転送先となるｓＬＢ１００を決定し、決定したｓＬＢ１００にパケットを転送する装置である。ルータ１７はスイッチに対応する。
【００２１】
サーバ２０は、ルータ１７およびｓＬＢ１００を介してクライアント１５からパケットを受信した場合に、クライアント１５に対してサービスを提供するサービスサーバである。後述するように、パケットは、ＧＲＥ（Generic  Routing  Encapsulation）によりカプセリング（カプセルか）されているため、サーバ２０は、パケットをデカプセリング（デカプセル化）した後に、各処理を実行する。
【００２２】
例えば、サーバ２０は、アプリケーションのパケット処理が完了した後に、レスポンスパケットをクライアント１５に送信する。レスポンスパケットは、ＨＴＴＰコネクションを確立するための、TCP  SYN/ACK  Responseに対応する。レスポンスパケットには、クライアント１５のＩＰが設定されるため、レスポンスパケットは、ｓＬＢ１００を経由せずに、クライアント１５に到達する。
【００２３】
ｓＬＢ１００は、稼働中の全ｓＬＢ１００で共通の振り分け論理に基づいて、クライアント１５から受信したパケットの振り分け先となるサーバ２０を決定し、決定したサーバ２０にパケットを送信する装置である。ｓＬＢ１００が利用する振り分け論理は、後述するフローテーブルおよび振り分けテーブルに対応する。ｓＬＢ１００は、ＧＲＥに基づき、パケットのカプセリングした後に、パケットをサーバ２０に送信する。
【００２４】
保守ノード２００は、ルータ１７、サーバ２０、ｓＬＢ１００を管理する装置である。保守ノード２００は、通信制御装置に対応する。本実施例に係るｓＬＢ１００は、スケール性を有している。保守ノード２００は、増設対象となるｓＬＢ１００に対して、増設命令を通知することで、ｓＬＢ１００のスケールアウトを行う。保守ノード２００は、減設対象となるｓＬＢ１００に対して、減設命令を通知することで、ｓＬＢ１００のスケールインを行う。
【００２５】
本実施例に係るサーバ２０は、スケール性を有している。保守ノード２００は、増設対象となるサーバ２０に対して、起動命令を通知することで、サーバ２０のスケールアウトを行う。保守ノード２００は、減設対象となるサーバ２０に対して、停止命令を通知することで、サーバ２０のスケールインを行う。
【００２６】
続いて、本実施例に係るシステムの正常時の処理について説明する。図２は、システムの正常時の処理を説明するための図である。ここでは便宜的に、ｓＬＢ１００ｃの図示を省略する。
【００２７】
クライアント１５は、パケットの宛先アドレスのＶＩＰを指定して、パケットを送信することで、パケットは、ルータ１７ａに到達する（ステップＳ１０）。
【００２８】
図３は、パケットのデータ構造の一例を示す図である。図３に示すように、パケットは、ether_typeと、src_ipと、dst_ipと、src_portと、dst_portと、protocolと、dataとを有する。
【００２９】
図３において、ether_typeは、イーサネットの種別を識別する情報である。protocolは、伝送するパケットの通信プロトコルを識別する情報である。src_ipは、送信元となるクライアント１５のＩＰアドレスである。dst_ipは、「ＶＩＰ」が設定される。src_portは、送信元となるクライアント１５のポート番号（TCP/UDP送信元ポート番号）である。dst_portは、送信先なるサーバ２０のポート番号（TCP/UDP送信先ポート番号）である。dataは、各種のユーザ情報を有する。以下の説明では、パケット３０に含まれる「src_port、src_ip、dst_port、dst_ip、protocol」の組を「5tuple情報」と定義する。
【００３０】
ルータ１７ａは、ルーティング情報と、パケットの宛先アドレス（dst_ip）とを比較して、転送先のｓＬＢ１００を決定する。ここでは便宜上、転送先のｓＬＢ１００を、ｓＬＢ１００ａとして説明する。ルータ１７ａは、ｓＬＢ１００ａに対して、パケットを転送する（ステップＳ１１）。
【００３１】
ｓＬＢ１００ａは、パケットの5tuple情報と、フローテーブルとを比較して、パケットの5tuple情報に対応するエントリが登録されているか否かを判定する。ｓＬＢ１００ａは、エントリが登録されている場合には、5tuple情報に対応するサーバ２０を決定する（ステップＳ１２ａ）。ステップＳ１２ａで決定したサーバ２０が、パケットの転送先のサーバ２０となる。
【００３２】
図４は、フローテーブルのデータ構造の一例を示す図である。図４に示すように、このフローテーブル１４０ａは、5tuple情報と、サーバＩＰとを対応付ける。サーバＩＰは、パケットの振り分け先となるサーバ２０固有のＩＰアドレスであり、ＶＩＰとは異なる。例えば、パケットの5tuple情報が「src_port=1234、src_ip=10.20.30.40、dst_port=80、dst_ip=11.21.31.41、protocol=tcp」である場合には、サーバＩＰは「サーバ２０ａのＩＰ」となる。
【００３３】
一方、ｓＬＢ１００ａは、パケットの5tuple情報に対応するエントリがフローテーブル１４０ａに登録されていない場合には、振り分けテーブルを利用して、振り分け先となるサーバ２０を決定する。
【００３４】
図５は、振り分けテーブルのデータ構造の一例を示す図である。図５に示すように、この振り分けテーブル１４０ｂは、サービス種別（ＶＩＰ）と、ハッシュ値と、サーバＩＰとを対応付ける。サービス種別は、クライアントに要求されるサービス種別を一意に識別する情報であり、例えば、ＶＩＰに対応する。ハッシュ値は、5tuple情報をハッシュ化した値に対応する。サーバＩＰは、パケットの振り分け先となるサーバ２０固有のＩＰアドレスであり、ＶＩＰとは異なる。
【００３５】
ｓＬＢ１００ａは、パケットの5tuple情報のハッシュ値と、振り分けテーブル１４０ｂのハッシュ値とを比較し、パケットの5tuple情報のハッシュ値と同一のハッシュ値を有する振り分けテーブル１４０ｂのエントリを特定する。例えば、ｓＬＢ１００ａが比較するハッシュ値は、パケットに設定されたＶＩＰに対応するハッシュ値とする。ｓＬＢ１００ａは、特定したエントリに含まれるサーバＩＰを決定する。ｓＬＢ１００ａは、パケットの5tuple情報と、決定したサーバＩＰとを対応付けて、フローテーブル１４０ｂに登録する（ステップＳ１２ｂ）。ステップＳ１２ｂで決定したサーバＩＰを宛先アドレスとするサーバ２０が、パケットの転送先のサーバ２０となる。
【００３６】
ｓＬＢ１００ａは、ステップＳ１２ａまたはステップＳ１２ｂにより、転送先のサーバ２０を決定した後に、次の処理を実行する。一例として、転送先のサーバ２０を、サーバ２０ｃとして説明を行う。ｓＬＢ１００ａは、パケットをＧＲＥによりカプセリングした後に、パケットをサーバ２０ｃに転送する（ステップＳ１３）。以下の説明では、カプセリングしたパケットを、カプセリング前のパケットと区別するべく、適宜、「ｓＬＢパケット」と表記する。
【００３７】
図６は、ｓＬＢパケットのデータ構造の一例を示す図である。図６に示すように、ｓＬＢパケットは、ether_typeと、GRE_src_ipと、GRE_dst_ipと、GER  Headerと、src_ipと、dst_ipと、src_portと、dst_portと、protocolと、dataとを有する。このうち、ether_type、src_ip、dst_ip、src_port、dst_port、protocol、dataに関する説明は、図３で行ったether_type、src_ip、dst_ip、src_port、dst_port、protocol、dataに関する説明と同様である。
【００３８】
GRE_src_ipは、ｓＬＢパケットを転送したｓＬＢ１００のＩＰアドレスである。GRE_dst_ipは、ステップＳ１２ａ，１２ｂにより決定されたサーバ２０のＩＰアドレスである。GER  Headerは、各種の制御情報を格納する。
【００３９】
サーバ２０ｃは、ｓＬＢパケットを受信すると、ｓＬＢパケットをデカプセリングすることで、パケットの情報を取り出し、アプリケーション処理を実行する。ｓＬＢパケットをデカプセリングすると、パケットのヘッダ情報には、送信元ＩＰアドレスとして、クライアント１５のＩＰアドレスが指定されている（ステップＳ１４）。
【００４０】
サーバ２０ｃは、アプリケーション処理が完了すると、クライアント１５のＩＰアドレスを宛先アドレスに指定したレスポンスパケットを、クライアント１５宛に送信する（ステップＳ１５）。レスポンスパケットは、ｓＬＢ１００を経由せずに、クライアント１５に到達する。
【００４１】
図７は、レスポンスパケットのデータ構造の一例を示す図である。図７に示すように、このレスポンスパケットは、ether_typeと、src_ipと、dst_ipと、src_portと、dst_portと、protocolと、dataとを有する。
【００４２】
図７において、ether_typeは、イーサネットの種別を識別する情報である。protocolは、伝送するパケットの通信プロトコルを識別する情報である。src_ipは、「ＶＩＰ」が設定される。dst_ipは、宛先となるクライアント１５のＩＰアドレスである。src_portは、送信元となるサーバ２０のポート番号（TCP/UDP送信元ポート番号）である。dst_portは、送信先なるクライアント１５のポート番号（TCP/UDP送信先ポート番号）である。dataは、各種のユーザ情報を有する。
【００４３】
続いて、本実施例に係るシステムのｓＬＢ１００のスケールイン時の処理について説明する。図８は、システムのｓＬＢのスケールイン時の処理を説明するための図である。ここでは便宜的に、ｓＬＢ１００ｃの図示を省略する。
【００４４】
保守ノード２００は、ｓＬＢ１００ａに対して減設通知を行う（ステップＳ２０）。ｓＬＢ１００ａは、前段のルータ１７に対して経路情報を広報することで、ｓＬＢ１００ａを経由する経路の削除依頼を行う（ステップＳ２１）。ルータ１７は、経路情報を受信した場合に、ルーティング情報から、ｓＬＢ１００ａを経由する経路を削除する（ステップＳ２２）。
【００４５】
クライアント１５は、パケットの宛先アドレスのＶＩＰを指定して、パケットを送信することで、パケットは、ルータ１７ａに到達する（ステップＳ２３）。パケットのデータ構造は、図３に示すものとなる。
【００４６】
ルータ１７ａは、ルーティング情報と、パケットの宛先アドレス（dst_ip）とを比較して、転送先のｓＬＢ１００を決定する。ｓＬＢ１００ａを経由する経路はルーティング情報から削除されているため、ルータ１７ａは、ｓＬＢ１００ａ以外のｓＬＢ１００を転送先として特定する。ここでは便宜上、転送先のｓＬＢ１００を、ｓＬＢ１００ｂとして説明する。ルータ１７ａは、ｓＬＢ１００ｂに対して、パケットを転送する（ステップＳ２４）。
【００４７】
ｓＬＢ１００ｂは、パケットの5tuple情報と、フローテーブル１４０ａとを比較して、パケットの5tuple情報に対応するエントリが登録されているか否かを判定する。ｓＬＢ１００ｂは、エントリが登録されている場合には、5tuple情報に対応するサーバ２０を決定する（ステップＳ２５ａ）。ステップＳ２５ａで決定したサーバ２０が、パケットの転送先のサーバ２０となる。フローテーブル１４０ａは、ｓＬＢ１００ａのフローテーブル１４０ａと同一のフローテーブルとなる。
【００４８】
一方、ｓＬＢ１００ｂは、パケットの5tuple情報に対応するエントリがフローテーブル１４０ａに登録されていない場合には、振り分けテーブル１４０ｂを利用して、振り分け先となるサーバ２０を決定する。
【００４９】
ｓＬＢ１００ｂは、パケットの5tuple情報のハッシュ値と、振り分けテーブル１４０ｂのハッシュ値とを比較し、パケットの5tuple情報のハッシュ値と同一のハッシュ値を有する振り分けテーブル１４０ｂのエントリを特定する。例えば、ｓＬＢ１００ｂが比較するハッシュ値は、パケットに設定されたＶＩＰに対応するハッシュ値とする。ｓＬＢ１００ｂは、特定したエントリに含まれるサーバＩＰを決定する。ｓＬＢ１００ｂは、パケットの5tuple情報と、決定したサーバＩＰとを対応付けて、フローテーブル１４０ｂに登録する（ステップＳ２５ｂ）。ステップＳ２５ｂで決定したサーバＩＰを宛先アドレスとするサーバ２０が、パケットの転送先のサーバ２０となる。
【００５０】
ｓＬＢ１００ｂは、ステップＳ２５ａまたはステップＳ２５ｂにより、転送先のサーバ２０を決定した後に、次の処理を実行する。一例として、転送先のサーバ２０を、サーバ２０ｃとして説明を行う。ｓＬＢ１００ｂは、パケットをＧＲＥによりカプセリングした後に、ｓＬＢパケットをサーバ２０ｃに転送する（ステップＳ２６）。
【００５１】
サーバ２０ｃは、ｓＬＢパケットを受信すると、ｓＬＢパケットをデカプセリングすることで、パケットの情報を取り出し、アプリケーション処理を実行する。ｓＬＢパケットをデカプセリングすると、パケットのヘッダ情報には、送信元ＩＰアドレスとして、クライアント１５のＩＰアドレスが指定されている（ステップＳ２７）。
【００５２】
サーバ２０ｃは、アプリケーション処理が完了すると、クライアント１５のＩＰアドレスを宛先アドレスに指定したレスポンスパケットを、クライアント１５宛に送信する（ステップＳ２８）。レスポンスパケットは、ｓＬＢ１００を経由せずに、クライアント１５に到達する。
【００５３】
図７および図８で説明したように、クライアント１５から送信されるパケットは、正常時には、ｓＬＢ１００ａを介して、サーバ２０ｃに到達するが、ｓＬＢ１００ａがスケールインすると、ｓＬＢ１００ｂを介して、サーバ２０ｃに到達する。ここで、正常時にｓＬＢ１００ａから転送されるｓＬＢパケットの送信元アドレスはクライアント１５のＩＰアドレスである。また、スケールイン後にｓＬＢ１００ｂから転送されるｓＬＢパケットの送信元アドレスは、クライアント１５のＩＰアドレスである。このため、サーバ２０ｃは、パケットの送信元を継続して認識できるため、セッションを切断すること無く、継続して、クライアント１５にサービスを提供することができる。
【００５４】
また、サーバ２０がデカプセル化したパケットにはクライアント１５のＩＰアドレスが含まれており、サーバ２０はセッションを認識する。例えば、ｓＬＢ１００が変わっても、サーバ２０はこのセッションを認識できるので、セッション断とみなさないことになる。
【００５５】
続いて、本実施例に係るシステムの各種の処理動作の一例について説明する。まず、システムの初期化動作（１）の一例について説明する。初期化動作（１）では、最初に増設するｓＬＢ１００を、クラスタマスタとする。ここでは一例として、ｓＬＢ１００ａを増設する場合について説明する。
【００５６】
図９は、システムの初期化動作の一例を示す図である。図９に示すように、保守ノード２００は、ｓＬＢ１００ａに対して、ｓＬＢ起動命令を送信する（ステップＳ５０）。ｓＬＢ１００ａは、起動処理を実行する（ステップＳ５１）。ｓＬＢ１００ａは、起動完了通知を、保守ノード２００に送信する（ステップＳ５２）。
【００５７】
図９のステップＳ５１に示した起動処理の一例について説明する。図１０は、起動処理（ステップＳ５１）の一例を示すフローチャートである。図１０に示すように、ｓＬＢ１００ａは、保守ノード２００からｓＬＢ起動命令を受信すると、ＯＳを起動する（ステップＳ６１）。ｓＬＢ１００ａは、振り分けテーブル１４０ｂ、フローテーブル１４０ａ、クラスタ構成情報を初期化する（ステップＳ６２）。ここで、クラスタ構成情報は、例えば、クラスタを構成する複数のｓＬＢ１００の情報と、クラスタマスタとなるｓＬＢ１００を示す情報を含む。
【００５８】
ｓＬＢ１００ａは、保守ノード２００に対して、クラスタ構成情報を要求する（ステップＳ６３）。ｓＬＢ１００ａは、保守ノード２００から、クラスタ構成情報を受信し、クラスタ構成情報を更新する（ステップＳ６４）。ｓＬＢ１００ａは、保守ノード２００に対して、起動完了（増設完了）を通知する（ステップＳ６５）。
【００５９】
次に、システムの初期化動作（２）の一例について説明する。初期動作（２）は、クラスタマスタ以外のｓＬＢ１００を新たに起動させる場合の動作である。ここでは一例として、起動済みのクラスタマスタをｓＬＢ１００ａとし、増設対象のｓＬＢ１００を、ｓＬＢ１００ｂとする。また、クラスタメンバに含まれるｓＬＢ１００ａ、１００ｂ以外のｓＬＢ１００を、単にｓＬＢ１００と表記する。
【００６０】
図１１は、システムの初期化動作（２）の一例を示す図である。図１１に示すように、保守ノード２００は、ｓＬＢ１００ｂに対して、ｓＬＢ起動命令を送信する（ステップＳ７０）。
【００６１】
ｓＬＢ１００ｂは、起動処理を実行する（ステップＳ７１）。ｓＬＢ１００ａは、更新処理を実行する（ステップＳ７２）。ｓＬＢ１００ｂが起動処理を行い、ｓＬＢ１００ａが更新処理を実行している間に、ｓＬＢ１００ｂは、ｓＬＢ１００ａに増設要求を行い、応答を受信する。また、ｓＬＢ１００ａは、ｓＬＢ１００ｂおよびその他のｓＬｂ１００に対して、メンバ情報通知を行い、応答を受信する。ｓＬＢ１００ａは、通知処理を行う（ステップＳ７３）。ｓＬＢ１００ａの通知処理では、ｓＬＢ１００ａが、保守ノード２００に、増設完了を通知する。
【００６２】
図１１のステップＳ７１に示した起動処理の一例について説明する。図１２は、起動処理（ステップＳ７１）の一例を示すフローチャートである。図１２に示すように、ｓＬＢ１００ｂは、保守ノード２００からｓＬＢ起動命令を受信すると、ＯＳを起動する（ステップＳ８１）。ｓＬＢ１００ｂは、振り分けテーブル１４０ｂ、フローテーブル１４０ａ、クラスタ構成情報を初期化する（ステップＳ８２）。
【００６３】
ｓＬＢ１００ｂは、保守ノード２００に対して、クラスタ構成情報を要求する（ステップＳ８３）。ｓＬＢ１００ｂは、保守ノード２００から、クラスタ構成情報を受信し、クラスタ構成情報を更新する（ステップＳ８４）。ｓＬＢ１００ａは、クラスタマスタ（ｓＬＢ１００ａ）に対して、増設要求を送信する（ステップＳ８５）。
【００６４】
ｓＬＢ１００ｂは、クラスタマスタから、振り分け情報と、クラスタメンバ情報を受信する（ステップＳ８６）。振り分け情報は、図５に示した振り分けテーブル１４０ｂの情報である。クラスタメンバ情報は、クラスタメンバに含まれる全ｓＬＢ１００の情報である。
【００６５】
ｓＬＢ１００ｂは、クラスタメンバ情報を更新する（ステップＳ８７）。ｓＬＢ１００ｂは、振り分け情報に基づき、振り分けテーブル１４０ｂを更新する（ステップＳ８８）。ｓＬＢ１００ｂは、クラスタマスタに処理完了を通知する（ステップＳ８９）。
【００６６】
図１１のステップＳ７２に示した更新処理およびステップＳ７３に示した通知処理の一例について説明する。図１３は、更新処理（ステップＳ７２）および通知処理（ステップＳ７３）の一例を示すフローチャートである。図１３に示すように、クラスタマスタ（ｓＬＢ１００ａ）は、増設されたｓＬＢ１００ｂから、増設要求を受信する（ステップＳ９０）。
【００６７】
クラスタマスタは、振り分け情報と、クラスタメンバ情報を更新する（ステップＳ９１）。クラスタメンバ情報は、クラスタに含まれる全ｓＬＢ１００の情報と、振り分け先の全サーバ２０の情報を含む。例えば、ステップＳ９１において、クラスタマスタは、現クラスタメンバに、増設されたｓＬＢ１００ｂを追加することで、クラスタメンバ情報を更新する。また、クラスタマスタは、クラスタメンバ情報と、振り分け情報とを対応付けた更新テーブルを保持しており、現クラスタメンバ情報に対応する振り分け情報を特定し、特定した振り分け情報により、振り分け情報を更新する。
【００６８】
クラスタマスタは、クラスタメンバに含まれる全ｓＬＢ１００に対して振り分け情報と、クラスタメンバ情報を送信する（ステップＳ９２）。クラスタマスタは、各ｓＬＢ１００からの応答待ちを行う（ステップＳ９３）。クラスタマスタは、クラスタメンバの全ｓＬＢ１００から応答を受け付けると、保守ノード２００に対して、増設完了を通知する（ステップＳ９４）。
【００６９】
次に、システムがサーバ２０をスケールアウトする場合の動作の一例について説明する。ここでは、スケールアウトするサーバ２０をサーバ２０ａとし、クラスタマスタをｓＬＢ１００ａとする。また、クラスタマスタ以外のクラスタメンバをｓＬＢ１００と表記する。
【００７０】
図１４は、サーバをスケールアウトする処理の一例を示す図である。図１４に示すように、保守ノード２００は、サーバ２０ａに対して、起動命令を送信する（ステップＳ１００）。サーバ２０ａは、起動命令を受信すると、起動処理を実行する（ステップＳ１０１）。
【００７１】
保守ノード２００は、ｓＬＢ１００ａ（クラスタマスタ）に対して、サーバ起動を通知する（ステップＳ１０２）。ｓＬＢ１００ａは、サーバ増設処理を実行し（ステップＳ１０３）、ｓＬＢ１００（クラスタメンバ）は、更新処理を実行する（ステップＳ１０４）。ｓＬＢ１００ａがサーバ増設処理を行い、ｓＬＢ１００が更新処理を実行している間に、ｓＬＢ１００ａは、メンバ情報通知を行い、応答を受信する。ｓＬＢ１００ａは、通知処理を行う（ステップＳ１０５）。ｓＬＢ１００ａの通知処理では、ｓＬＢ１００ａが、保守ノード２００に、増設完了を通知する。
【００７２】
図１４のステップＳ１０３に示したサーバ増設処理およびステップＳ１０５に示した通知処理の一例について説明する。図１５は、サーバ増設処理（ステップＳ１０３）および通知処理（ステップＳ１０５）の一例を示すフローチャートである。図１５に示すように、クラスタマスタ（ｓＬＢ１００ａ）は、保守ノード２００から、増設したサーバ２０ａの情報を受信する（ステップＳ１１１）。
【００７３】
クラスタマスタは、振り分け情報と、クラスタメンバ情報を更新する（ステップＳ１１２）。例えば、ステップＳ１１２において、クラスタマスタは、現クラスタメンバに、増設されたサーバ２０ａを追加することで、クラスタメンバ情報を更新する。また、クラスタマスタは、クラスタメンバ情報と、更新テーブルとの比較により、振り分け情報を特定し、特定した振り分け情報により、振り分け情報を更新する。
【００７４】
クラスタマスタは、クラスタメンバ情報のサーバ数が、０から１に変化したか否かを判定する（ステップＳ１１３）。クラスタマスタは、変化していない場合には（ステップＳ１１４，Ｎｏ）、ステップＳ１１６に移行する。
【００７５】
一方、クラスタマスタは、変化した場合には（ステップＳ１１４，Ｙｅｓ）、ルータ１７に対して、ＶＩＰの経路情報をルーティングプロトコルで広報する（ステップＳ１１５）。
【００７６】
クラスタマスタは、全てのクラスタメンバに振り分け情報と、クラスタメンバ情報を送信する（ステップＳ１１６）。クラスタマスタは、全てのクラスタメンバから応答を待つ（ステップＳ１１７）。クラスタマスタは、全てのクラスタメンバから応答を受け付けると、保守ノード２００に対して、増設完了を通知する（ステップＳ１１８）。
【００７７】
図１４のステップＳ１０４に示した更新処理の一例について説明する。図１６は、更新処理（ステップＳ１０４）の一例を示すフローチャートである。図１６に示すように、クラスタメンバのｓＬＢ１００は、クラスタマスタ（ｓＬＢ１００ａ）から振り分け情報とクラスタメンバ情報を受信する（ステップＳ１２０）。
【００７８】
ｓＬＢ１００は、振り分け情報に基づき、振り分けテーブル１４０ｂを更新する（ステップＳ１２１）。ｓＬＢ１００は、クラスタメンバ情報のサーバ数が０から１に変化したか否かを判定する（ステップＳ１２２）。ｓＬＢ１００は、変化していない場合には（ステップＳ１２３，Ｎｏ）、ステップＳ１２５に移行する。
【００７９】
一方、ｓＬＢ１００は、変化した場合には（ステップＳ１２３，Ｙｅｓ）、ルータ１７に対して、ＶＩＰの経路情報をルーティングプロトコルで広報する（ステップＳ１２４）。ｓＬＢ１００は、クラスタマスタへ処理完了を通知する（ステップＳ１２５）。
【００８０】
次に、システムがｓＬＢ１００をスケールアウトする場合の動作の一例について説明する。かかるｓＬＢ１００のスケールアウトは、図１１で説明した処理と同様であるため、説明を省略する。図１１では、ｓＬＢ１００ｂをスケールアウト（増設）する場合を説明した。
【００８１】
次に、システムがサーバ２０をスケールイン（減設）する場合の動作の一例について説明する。ここでは、スケールインするサーバ２０をサーバ２０ａとし、クラスタマスタをｓＬＢ１００ａとする。また、クラスタマスタ以外のクラスタメンバをｓＬＢ１００と表記する。
【００８２】
図１７は、サーバをスケールインする処理の一例を示す図である。図１７に示すように、保守ノード２００は、ｓＬＢ１００ａ（クラスタマスタ）に対して、サーバ停止情報を通知する（ステップＳ１３０）。サーバ停止情報には、減設するサーバ２０ａの情報が含まれる。
【００８３】
ｓＬＢ１００ａは、サーバ減設処理を実行し（ステップＳ１３１）、ｓＬＢ１００は、更新処理を実行する（ステップＳ１３２）。ｓＬＢ１００ａがサーバ減設処理を行い、ｓＬＢ１００が更新処理を実行している間に、ｓＬＢ１００ａは、メンバ情報通知を行い、応答を受信する。ｓＬＢ１００ａは、通知処理を行う（ステップＳ１３３）。ｓＬＢ１００ａの通知処理では、ｓＬＢ１００ａが、保守ノード２００に、サーバ停止処理完了を通知する。
【００８４】
サーバ２０ａは、各装置からの信号受信を終了する（ステップＳ１３４）。保守ノード２００は、サーバ２０ａにサーバ停止命令を送信する（ステップＳ１３５）。サーバ２０ａは、保守ノード２００からのサーバ停止命令によりサーバを停止する（ステップＳ１３６）。
【００８５】
図１７のステップＳ１３１に示したサーバ減設処理およびステップＳ１３３に示した通知処理の一例について説明する。図１８は、サーバ減設処理（ステップＳ１３１）および通知処理（ステップＳ１３３）の一例を示すフローチャートである。図１８に示すように、クラスタマスタ（ｓＬＢ１００ａ）は、保守ノード２００からサーバ停止情報を受信する（ステップＳ１４０）。
【００８６】
クラスタマスタは、振り分け情報と、クラスタメンバ情報を更新する（ステップＳ１４１）。例えば、ステップＳ１４１において、クラスタマスタは、現クラスタメンバから、減設されたサーバ２０ａを削除することで、クラスタメンバ情報を更新する。また、クラスタマスタは、クラスタメンバ情報と、更新テーブルとの比較により、振り分け情報を特定し、特定した振り分け情報により、振り分け情報を更新する。
【００８７】
クラスタマスタは、クラスタメンバ情報のサーバ数が、１から０に変化したか否かを判定する（ステップＳ１４２）。クラスタマスタは、変化していない場合には（ステップＳ１４３，Ｎｏ）、ステップＳ１４５に移行する。
【００８８】
一方、クラスタマスタは、変化した場合には（ステップＳ１４３，Ｙｅｓ）、ルータ１７に対して、ＶＩＰ（減設したサーバ２０ａに対応するＶＩＰ）の経路情報をルーティングプロトコルで削除依頼する（ステップＳ１４４）。
【００８９】
クラスタマスタは、全てのクラスタメンバに振り分け情報と、クラスタメンバ情報を送信する（ステップＳ１４５）。クラスタマスタはタイマを起動する（ステップＳ１４６）。クラスタマスタは、全てのクラスタメンバからサーバ停止完了の通知を受信するまで待機する（ステップＳ１４７）。
【００９０】
クラスタマスタは、タイマ満了済みでない場合には（ステップＳ１４８，Ｎｏ）、タイマ満了まで待機し（ステップＳ１４９）、ステップＳ１５０に移行する。
【００９１】
一方、クラスタマスタは、タイマ満了済みの場合には（ステップＳ１４８，Ｙｅｓ）、保守ノード２００に対して、サーバ停止処理完了を通知する（ステップＳ１５０）。
【００９２】
図１７のステップＳ１３２に示した更新処理の一例について説明する。図１９は、更新処理（ステップＳ１３２）の一例を示すフローチャートである。図１９に示すように、クラスタメンバのｓＬＢ１００は、クラスタマスタ（ｓＬＢ１００ａ）から振り分け情報とクラスタメンバ情報を受信する（ステップＳ１６０）。
【００９３】
ｓＬＢ１００は、振り分け情報に基づき、振り分けテーブル１４０ｂを更新する（ステップＳ１６１）。ｓＬＢ１００は、タイマを起動する（ステップＳ１６２）。ｓＬＢ１００は、クラスタメンバ情報のサーバ数が１から０に変化したか否かを判定する（ステップＳ１６３）。ｓＬＢ１００は、変化していない場合には（ステップＳ１６４，Ｎｏ）、ステップＳ１６６に移行する。
【００９４】
一方、ｓＬＢ１００は、変化した場合には（ステップＳ１６４，Ｙｅｓ）、ルータ１７に対して、ＶＩＰ（減設したサーバ２０ａに対応するＶＩＰ）の経路情報をルーティングプロトコルで削除依頼する（ステップＳ１６５）。ｓＬＢ１００は、クラスタマスタへサーバ停止完了を通知する（ステップＳ１６６）。
【００９５】
次に、システムがｓＬＢ１００をスケールイン（減設）する場合の動作の一例について説明する。ここでは、スケールインするｓＬＢ１００をｓＬＢ１００ｂとし、クラスタマスタをｓＬＢ１００ａとする。また、クラスタマスタ以外のクラスタメンバをｓＬＢ１００と表記する。
【００９６】
図２０は、ｓＬＢをスケールインする処理の一例を示す図である。図２０に示すように、保守ノード２００は、減設対象となるｓＬＢ１００ｂに対してｓＬＢ停止事前通知を送信する（ステップＳ１７１）。ｓＬＢ１００ｂは、ｓＬＢ減設処理を実行する（ステップＳ１７２）。保守ノード２００は、ｓＬＢ１００ｂにｓＬＢ停止を通知する（ステップＳ１７３）。
【００９７】
ｓＬＢ１００は、検知処理を実行し（ステップＳ１７４）、ｓＬＢ１００ａは、更新処理を実行する（ステップＳ１７５）。ｓＬＢ１００は、検知処理により、減設したｓＬＢ１００ｂの不在を検知して、ｓＬＢ１００ａに通知する。ｓＬＢ１００ａは、メンバ情報をｓＬＢ１００に通知する。ｓＬＢ１００ａは、通知処理により、ｓＬＢ停止処理完了を通知する（ステップＳ１７６）。保守ノード２００は、クラスタ管理情報を更新する（ステップＳ１７７）。
【００９８】
図２０のステップＳ１７２に示したｓＬＢ減設処理の一例について説明する。図２１は、ｓＬＢ減設処理（ステップＳ１７２）の一例を示すフローチャートである。ｓＬＢ１００ｂは、保守ノード２００からｓＬＢ停止事前通知を受信する（ステップＳ１８１）。
【００９９】
ｓＬＢ１００ｂは、ルータ１７に対して、減設するｓＬＢ１００ｂを経由する経路情報をルーティングプロトコルで削除依頼する（ステップＳ１８２）。
【０１００】
ｓＬＢ１００ｂは、信号受信を終了する（ステップＳ１８３）。ｓＬＢ１００ｂは、保守ノード２００からｓＬＢ停止を受信すると、停止する（ステップＳ１８４）。
【０１０１】
図２０のステップＳ１７４に示した検知処理の一例について説明する。図２２は、検知処理（ステップＳ１７４）の一例を示すフローチャートである。図２２に示すように、ｓＬＢ１００は、クラスタメンバ間の自律監視により、ｓＬＢ１００ｂの不在を検知する（ステップＳ１９０）。
【０１０２】
ｓＬＢ１００は、不在となるｓＬＢ１００ｂの情報をクラスタマスタ（ｓＬＢ１００ａ）に通知する（ステップＳ１９１）。ｓＬＢ１００は、クラスタマスタから振り分け情報とクラスタメンバ情報を受信する（ステップＳ１９２）。
【０１０３】
ｓＬＢ１００は、振り分け情報に基づき、振り分けテーブル１４０ｂを更新する（ステップＳ１９３）。ｓＬＢ１００は、クラスタマスタに、ｓＬＢ停止処理完了を通知する（ステップＳ１９４）。
【０１０４】
図２０のステップＳ１７５に示した更新処理およびステップＳ１７６に示した通知処理の一例について説明する。図２３は、更新処理（ステップＳ１７５）および通知処理（ステップＳ１７６）の一例を示すフローチャートである。図２３に示すように、クラスタマスタ（ｓＬＢ１００ａ）は、不在となるｓＬＢ１００ｂの情報の通知を受け付ける（ステップＳ２００）。
【０１０５】
クラスタマスタは、振り分け情報と、クラスタメンバ情報を更新する（ステップＳ２０１）。例えば、ステップＳ２０１において、クラスタマスタは、現クラスタメンバから、減設されたｓＬＢ１００ｂを削除することで、クラスタメンバ情報を更新する。また、クラスタマスタは、クラスタメンバ情報と、更新テーブルとの比較により、振り分け情報を特定し、特定した振り分け情報により、振り分け情報を更新する。
【０１０６】
クラスタマスタは、全てのクラスタメンバに振り分け情報と、クラスタメンバ情報を送信する（ステップＳ２０２）。クラスタマスタは、全てのクラスタメンバからｓＬＢ停止処理完了の通知を受信するまで待機する（ステップＳ２０３）。クラスタマスタは、保守ノード２００へ、ｓＬＢ停止処理完了を通知する（ステップＳ２０４）。
【０１０７】
次に、システムがサーバ２０の故障を検知した場合の動作の一例について説明する。ここでは、故障の発生するサーバ２０をサーバ２０ａとする。クラスタマスタをｓＬＢ１００ａとし、クラスタマスタ以外のクラスタメンバをｓＬＢ１００と表記する。
【０１０８】
図２４は、サーバの故障を検知した場合の処理の一例を示す図である。図２４に示すように、例えば、サーバ２０ａにおいて故障が発生する（ステップＳ２１０）。
【０１０９】
ｓＬＢ１００ａ（クラスタマスタ）は、検知処理を実行し（ステップＳ２１１）、ｓＬＢ１００（クラスタメンバ）は、更新処理を実行する（ステップＳ２１２）。ｓＬＢ１００ａが検知処理を実行し、ｓＬＢ１００が更新処理を実行する間に、ｓＬＢ１００ａは、ｓＬＢ１００にメンバ情報通知を行い、応答を受信する。ｓＬＢ１００ａは、通知処理を行う（ステップＳ２１３）。ｓＬＢ１００ａの通知処理では、ｓＬＢ１００ａが、保守ノード２００に、サーバ停止処理完了を通知する。
【０１１０】
保守ノード２００は、故障中のサーバ２０ａに対してサーバ停止命令を送信する（ステップＳ２１４）。サーバ２０ａは、停止する（ステップＳ２１５）。
【０１１１】
図２４のステップＳ２１１に示した検知処理およびステップＳ２１３に示した通知処理の一例について説明する。図２５は、検知処理（ステップＳ２１１）および通知処理（ステップＳ２１３）の一例を示すフローチャートである。図２５に示すように、クラスタマスタ（ｓＬＢ１００ａ）は、クラスタメンバ間の自律監視により、サーバ２０ａの故障を検知する（ステップＳ２２０）。
【０１１２】
クラスタマスタは、振り分け情報と、クラスタメンバ情報を更新する（ステップＳ２２１）。例えば、ステップＳ２２１において、クラスタマスタは、現クラスタメンバから、故障したサーバ２０ａを削除することで、クラスタメンバ情報を更新する。また、クラスタマスタは、クラスタメンバ情報と、更新テーブルとの比較により、振り分け情報を特定し、特定した振り分け情報により、振り分け情報を更新する。
【０１１３】
クラスタマスタは、全てのクラスタメンバに振り分け情報と、クラスタメンバ情報を送信する（ステップＳ２２２）。クラスタマスタは、全てのクラスタメンバからサーバ停止処理完了の通知を受信するまで待機する（ステップＳ２２３）。クラスタマスタは、保守ノード２００へサーバ停止処理完了を通知する（ステップＳ２２４）。
【０１１４】
図２４のステップＳ２１２に示した更新処理の一例について説明する。図２６は、更新処理（ステップＳ２１２）の一例を示すフローチャートである。図２６に示すように、ｓＬＢ１００は、クラスタマスタ（ｓＬＢ１００ａ）から振り分け情報とクラスタメンバ情報を受信する（ステップＳ２３０）。
【０１１５】
ｓＬＢ１００は、振り分け情報に基づいて、振り分けテーブル１４０ｂを更新する（ステップＳ２３１）。ｓＬＢ１００は、クラスタマスタへサーバ停止処理完了を通知する（ステップＳ２３２）。
【０１１６】
次に、システムがｓＬＢ１００の故障を検知した場合の動作の一例について説明する。ここでは、故障の発生するｓＬＢ１００をｓＬＢ１００ｂとする。クラスタマスタをｓＬＢ１００ａとし、クラスタマスタおよびｓＬＢ１００ｂ以外のクラスタメンバをｓＬＢ１００と表記する。
【０１１７】
図２７は、ｓＬＢの故障を検知した場合の処理の一例を示す図である。図２７に示すように、例えば、ｓＬＢ１００ｂにおいて故障が発生する（ステップＳ２４０）。
【０１１８】
ｓＬＢ１００ａ（クラスタマスタ）は、検知処理を実行し（ステップＳ２４１）、ｓＬＢ１００（クラスタメンバ）は、更新処理を実行する（ステップＳ２４２）。ｓＬＢ１００ａが検知処理を実行し、ｓＬＢ１００が更新処理を実行する間に、ｓＬＢ１００ａは、ｓＬＢ１００にメンバ情報通知を行い、応答を受信する。ｓＬＢ１００ａは、通知処理を行う（ステップＳ２４３）。ｓＬＢ１００ａの通知処理では、ｓＬＢ１００ａが、保守ノード２００に、ＬＢ停止処理完了を通知する。
【０１１９】
保守ノード２００は、故障中のｓＬＢ１００ｂに対してＬＢ停止命令を送信する（ステップＳ２４４）。ｓＬＢ１００ｂは、停止する（ステップＳ２１５）。
【０１２０】
図２７のステップＳ２４１に示した検知処理およびステップＳ２４３に示した通知処理の一例について説明する。図２８は、検知処理（ステップＳ２４１）および通知処理（ステップＳ２４３）の一例を示すフローチャートである。図２８に示すように、クラスタマスタ（ｓＬＢ１００ａ）は、クラスタメンバ間の自律監視により、ｓＬＢ１００ｂの故障を検知する（ステップＳ２５０）。
【０１２１】
クラスタマスタは、振り分け情報と、クラスタメンバ情報を更新する（ステップＳ２５１）。例えば、ステップＳ２５１において、クラスタマスタは、現クラスタメンバから、故障したｓＬＢ１００ｂを削除することで、クラスタメンバ情報を更新する。また、クラスタマスタは、クラスタメンバ情報と、更新テーブルとの比較により、振り分け情報を特定し、特定した振り分け情報により、振り分け情報を更新する。
【０１２２】
クラスタマスタは、全てのクラスタメンバに振り分け情報と、クラスタメンバ情報を送信する（ステップＳ２５２）。クラスタマスタは、全てのクラスタメンバからＬＢ停止処理完了の通知を受信するまで待機する（ステップＳ２５３）。クラスタマスタは、保守ノード２００へＬＢ停止処理完了を通知する（ステップＳ２５４）。
【０１２３】
図２７のステップＳ２４２に示した更新処理の一例について説明する。図２９は、更新処理（ステップＳ２４２）の一例を示すフローチャートである。図２９に示すように、ｓＬＢ１００は、クラスタマスタ（ｓＬＢ１００ａ）から振り分け情報とクラスタメンバ情報を受信する（ステップＳ２６０）。
【０１２４】
ｓＬＢ１００は、振り分け情報に基づいて、振り分けテーブル１４０ｂを更新する（ステップＳ２６１）。ｓＬＢ１００は、クラスタマスタへＬＢ停止処理完了を通知する（ステップＳ２６２）。
【０１２５】
次に、本実施例に係るｓＬＢ１００の構成の一例について説明する。図３０は、本実施例に係るｓＬＢの構成を示す機能ブロック図である。図３０では、ｓＬＢ１００ａの構成について説明するが、その他のｓＬＢ１００の構成は、ｓＬＢ１００ａと同様であるため説明を省略する。図３０に示すように、このｓＬＢ１００ａは、通信部１１０と、記憶部１４０と、制御部１５０とを有する。
【０１２６】
通信部１１０は、図示しないネットワークを介してルータ１７とデータ通信を実行する。また、通信部１１０は、ネットワーク１８を介して、サーバ２０および保守ノード２００とデータ通信を実行する。後述する制御部１５０は、通信部１１０を介して、ルータ１７、サーバ２０、保守ノード２００とデータ通信を実行する。通信部１１０は、通信装置に対応する。
【０１２７】
記憶部１４０は、フローテーブル１４０ａと、振り分けテーブル１４０ｂと、クラスタ構成情報１４０ｃと、クラスタメンバ情報１４０ｄと、更新テーブル１４０ｅとを有する。記憶部１４０は、ＲＡＭ（Random  Access  Memory）、ＲＯＭ（Read  Only  Memory）、フラッシュメモリ（Flash  Memory）などの半導体メモリ素子や、ＨＤＤ（Hard  Disk  Drive）などの記憶装置に対応する。
【０１２８】
フローテーブル１４０ａは、5tuple情報と、サーバＩＰとを対応付けた情報を保持するテーブルである。フローテーブル１４０ａのデータ構造に関する説明は、図４を用いて説明したフローテーブル１４０ａに関する説明と同様である。
【０１２９】
振り分けテーブル１４０ｂは、サービス種別（ＶＩＰ）と、ハッシュ値と、サーバＩＰとを対応付けた情報を保持するテーブルである。振り分けテーブル１４０ｂに関する説明は、図５を用いて説明した振り分けテーブル１４０ｂに関する説明と同様である。
【０１３０】
クラスタ構成情報１４０ｃは、保守ノード２００から通知される情報である。例えば、クラスタ構成情報１４０ｃは、クラスタを構成する複数のｓＬＢ１００の情報と、クラスタマスタとなるｓＬＢ１００を示す情報を含む。例えば、クラスタ構成情報１４０ｃに含まれるクラスタマスタが「ｓＬＢ１００ａ」である場合には、ｓＬＢ１００ａがクラスタマスタとして動作する。クラスタ構成情報１４０ｃに含まれるクラスタマスタが「自装置ではない他のｓＬＢ１００」である場合には、ｓＬＢ１００ａはクラスタメンバとして動作する。
【０１３１】
クラスタメンバ情報１４０ｄは、クラスタを構成する全てのｓＬＢ１００と、サーバ２０との情報を有する。ｓＬＢ１００およびサーバ２０が減設・故障すると、該当するｓＬＢ１００およびサーバ２０の情報が、クラスタメンバ情報１４０ｄから除去される。
【０１３２】
更新テーブル１４０ｅは、クラスタメンバ情報１４０ｄと振り分け情報とを対応付けるテーブルである。例えば、クラスタメンバ情報１４０ｄが更新されると、更新テーブル１４０ｅに基づき、更新後のクラスタメンバ情報１４０ｄに対応する振り分け情報が特定される。
【０１３３】
制御部１５０は、パケット処理部１５０ａと、振り分け機能部１５０ｂと、クラスタ管理部１５０ｃとを有する。制御部１５０は、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）などによって実現できる。また、制御部１５０は、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）などのハードワイヤードロジックによっても実現できる。
【０１３４】
パケット処理部１５０ａは、ルータ１７からクライアント１５のパケットを受信した場合に、パケットに含まれる5tuple情報と、フローテーブル１４０ａとを比較して、サーバＩＰを決定する。パケット処理部１５０ａは、パケットから5tuple情報に該当する情報を抽出し、並べた文字列を5tuple情報として利用する。パケットのデータ構造は、図３で説明したデータ構造に対応する。パケット処理部１５０ａは、パケットをＧＲＥによりカプセリングすることで、ｓＬＢパケットを生成し、宛先となるサーバ２０にｓＬＢパケットを転送する。ｓＬＢパケットのデータ構造は、図６で説明したデータ構造に対応する。
【０１３５】
ここで、パケット処理部１５０ａは、パケットに含まれる5tuple情報に対応するエントリが、フローテーブル１４０ａに存在しない場合には、振り分け機能部１５０ｂに対して、振り分け先抽出依頼を行い、5tuple情報を振り分け機能部１５０ｂに出力する。パケット処理部１５０ａが、振り分け先抽出依頼を行うことで、5tuple情報に対応するエントリが、フローテーブル１４０ａに登録される。
【０１３６】
振り分け機能部１５０ｂは、パケット処理部１５０ａから振り分け先抽出依頼を受け付けた場合に処理を実行する。振り分け機能部１５０ｂは、パケット処理部１５０ａから5tuple情報を取得し、5tuple情報を所定のハッシュ関数に代入することで、5tuple情報のハッシュ値を算出する。振り分け機能部１５０ｂは、算出したハッシュ値と、振り分けテーブル１４０ｂのエントリと比較することで、ハッシュ値に対応するサーバＩＰを特定する。
【０１３７】
ここで、図５で説明したように、振り分けテーブル１４０ｂは、サービス種別毎に各ハッシュ値が対応付けられている。例えば、振り分け機能部１５０ｂは、5tuple情報の「dst_ip（ＶＩＰ）」に対応するサービス種別を特定し、特定したサービス種別に対応する各ハッシュ値と、5tuple情報のハッシュ値とを比較することで、ハッシュ値に対応するサーバＩＰを特定する。
【０１３８】
振り分け機能部１５０ｂは、ハッシュ値に対応するサーバＩＰを特定すると、5tuple情報と、特定したサーバＩＰとを対応付けて、フローテーブル１４０ａに登録する。
【０１３９】
クラスタ管理部１５０ｃは、クラスタを管理する処理、広報を行う処理、クラスタに含まれるｓＬＢ１００、サーバ２０を監視する処理等を実行する処理部である。
【０１４０】
クラスタ管理部１５０ｃが実行するクラスタを管理する処理の一例について説明する。クラスタ管理部１５０ｃは、ｓＬＢ１００ａが起動した場合に、記憶部１４０に記憶された情報の初期化を行う。クラスタ管理部１５０ｃは、保守ノード２００にクラスタ構成情報１４０ｃを要求し、保守ノード２００から、クラスタ構成情報１４０ｃを取得する。クラスタ管理部１５０ｃは、取得したクラスタ構成情報１４０ｃを記憶部１４０に格納する。また、クラスタ管理部１５０ｃは、保守ノード２００から、増設・減設したサーバ２０の情報を受信した場合には、サーバ２０の増設・減設に応じて、クラスタ構成情報１４０ｃを更新する。
【０１４１】
ここで、クラスタ管理部１５０ｃは、ｓＬＢ１００ａがクラスタマスタである場合に起動するマスタ機能と、ｓＬＢ１００ａがクラスタマスタでない場合に起動するメンバ機能とを有する。クラスタ管理部１５０ｃは、クラスタ構成情報１４０ｃを参照することで、ｓＬＢ１００ａがクラスタマスタであるか否かを判定する。
【０１４２】
クラスタ管理部１５０ｃのマスタ機能について説明する。マスタ機能は、クラスタメンバのｓＬＢ１００、サーバ２０とデータ通信を実行して、クラスタメンバ情報１４０ｄを更新する処理を実行する。マスタ機能は、クラスタメンバ情報１４０ｄが更新されると、更新されたクラスタメンバ情報１４０ｄと、更新テーブル１４０ｅとを比較することで、新たな振り分け情報を特定し、振り分け情報を更新する。マスタ機能は、更新したクラスタメンバ情報と、更新した振り分け情報を、クラスタメンバの全ｓＬＢ１００に通知することで、クラスタメンバ間の振り分けテーブル１４０ｂの内容を同一の情報にする。
【０１４３】
クラスタ管理部１５０ｃのメンバ機能について説明する。メンバ機能は、クラスタマスタから更新されたクラスタメンバ情報１４０ｄと更新された振り分け情報とを受信する。メンバ機能は、クラスタメンバ情報１４０ｄを、記憶部１４０に登録する。メンバ機能は、更新された振り分け情報により、振り分けテーブル１４０ｂを更新する。
【０１４４】
続いて、クラスタ管理部１５０ｃが広報を行う処理の一例について説明する。クラスタ管理部１５０ｃは、クラスタメンバ情報１４０ｄが更新されると、サーバ２０の合計台数が、０台から１台に変化したか否かを判定する。クラスタ管理部１５０ｃは、サーバ２０の合計台数が０台から１台に変化した場合には、削除されたサーバ２０に対応するＶＩＰを宛先とする経路を削除する要求を、ルータ１７に対して広報する。
【０１４５】
クラスタ管理部１５０ｃは、保守ノード２００から、ｓＬＢ１００ａ（自装置）に対して、減設要求を受け付けた場合には、ｓＬＢ１００ａを経由する経路を削除する要求を、ルータ１７に対して広報する。
【０１４６】
続いて、クラスタ管理部１５０ｃがｓＬＢ１００、サーバ２０を監視する処理の一例について説明する。クラスタ管理部１５０ｃは、クラスタメンバのｓＬＢ１００とデータ通信を定期的に実行し、信号を送信した後に応答の無いｓＬＢ１００に故障が発生したと判定（不在であると判定）する。また、クラスタ管理部１５０ｃは、クラスタメンバのサーバ２０とデータ通信を定期的に実行し、信号を送信した後に応答の無いサーバ２０に故障が発生したと判定（不在であると判定）する。
【０１４７】
クラスタ管理部１５０ｃは、ｓＬＢ１００ａ（自装置）がクラスタマスタである場合には、クラスタメンバ情報１４０ｄから、故障の発生したｓＬＢ１００、サーバ２０を削除することで、クラスタメンバ情報１４０ｄを更新する。クラスタ管理部１５０ｃは、クラスタメンバ情報１４０ｄを更新した後の処理は、上記のマスタ機能の処理と同様の処理を実行する。
【０１４８】
クラスタ管理部１５０ｃは、ｓＬＢ１００ａ（自装置）がクラスタマスタでない場合には、故障の発生したｓＬＢ１００、サーバ２０の情報を、クラスタマスタに通知する。
【０１４９】
続いて、本実施例に係るｓＬＢ１００がパケットを送信する場合の処理手順の一例について説明する。図３１は、ｓＬＢがパケットを送信する処理を示すフローチャートである。図３１に示すように、ｓＬＢ１００のパケット処理部１５０ａは、クライアントから受信した5tuple情報から文字列を生成する（ステップＳ３０１）。
【０１５０】
ｓＬＢ１００ａの振り分け機能部１５０ｂは、5tuple情報の文字列からハッシュ値を算出する（ステップＳ３０２）。パケット処理部１５０ａは、フローテーブル１４０ａのエントリを検索し、既にエントリが存在するか否かを判定する（ステップＳ３０３）。
【０１５１】
パケット処理部１５０ａは、エントリが存在する場合には（ステップＳ３０４，Ｙｅｓ）、エントリ内容に従い、サーバへｓＬＢパケットを転送する（ステップＳ３０５）。一方、パケット処理部１５０ａは、エントリが存在しない場合には（ステップＳ３０４，Ｎｏ）、ステップＳ３０６に移行する。
【０１５２】
振り分け機能部１５０ｂは、ハッシュ値と振り分けテーブル１４０ｂとを比較して、転送先のサーバを決定する（ステップＳ３０６）。パケット処理部１５０ａは、決定したサーバへｓＬＢパケットを転送する（ステップＳ３０７）。振り分け機能部１５０ｂは、フローテーブル１４０ａにエントリを追加する（ステップＳ３０８）。
【０１５３】
次に、本実施例に係る保守ノード２００の構成について説明する。図３２は、本実施例に係る保守ノードの構成を示す機能ブロック図である。図３２に示すように、この保守ノード２００は、通信部２１０と、入力部２２０と、表示部２３０と、記憶部２４０と、制御部２５０とを有する。
【０１５４】
通信部２１０は、ルータ１７、ｓＬＢ１００、サーバ２０とデータ通信を実行する処理部である。後述する制御部２５０は、通信部２１０を介して、ルータ１７、ｓＬＢ１００、サーバ２０とデータ通信を実行する。通信部２１０は、通信装置に対応する。
【０１５５】
入力部２２０は、各種の情報を保守ノード２００に入力するための入力装置である。入力部２２０は、キーボードやマウス、タッチパネル等に対応する。
【０１５６】
表示部２３０は、各種の情報を表示するための表示装置である。表示部２３０は、液晶ディスプレイやタッチパネル等に対応する。
【０１５７】
記憶部２４０は、クラスタ構成情報２４０ａ、スケジュール情報２４０ｂ、振り分け情報２４０ｃを有する。記憶部２４０は、ＲＡＭ、ＲＯＭ、フラッシュメモリなどの半導体メモリ素子や、ＨＤＤなどの記憶装置に対応する。
【０１５８】
クラスタ構成情報２４０ａは、クラスタを構成するｓＬＢ１００の情報、サーバ２０の情報を有する。また、クラスタ構成情報２４０ａでは、クラスタマスタに指定するｓＬＢ１００の情報が含まれる。
【０１５９】
スケジュール情報２４０ｂは、曜日と対応付けて、稼働させるｓＬＢ１００、サーバ２０を定義する情報である。なお、スケジュール情報２４０ｂは、曜日の代わりに、サービス種別または日時と、稼働させるｓＬＢ１００、サーバ２０とを対応付けて定義しても良い。
【０１６０】
振り分け情報２４０ｃは、保守ノード２００が管理するクラスタのｓＬＢ１００が利用する最新の振り分け情報を示す。
【０１６１】
制御部２５０は、クラスタ管理部２５０ａと、振り分け情報管理部２５０ｂとを有する。制御部２５０は、ＣＰＵやＭＰＵなどによって実現できる。また、制御部２５０は、ＡＳＩＣやＦＰＧＡなどのハードワイヤードロジックによっても実現できる。
【０１６２】
クラスタ管理部２５０ａは、保守ノード２００が管理するｓＬＢ１００、サーバ２０に対して、増設・減設の命令を送信する処理部である。クラスタ管理部２５０ａは、ｓＬＢ１００、サーバ２０の増設・減設、故障などにより、クラスタの構成が更新されると、かかる更新に対応して、クラスタ管理情報２４０ａを更新する。クラスタ管理部２５０ａは、ｓＬＢ１００から、クラスタ構成情報の要求を受け付けた場合には、クラスタ管理情報を基にして、クラスタ構成情報を、要求元のｓＬＢ１００に通知する。
【０１６３】
また、クラスタ管理部２５０ａは、入力部２２０を介して、管理者から増設・減設対象となるｓＬＢ１００、サーバ２０の指示を受けた場合には、該当するｓＬＢ１００、サーバ２０に対して、増設・減設の命令を送信する。また、クラスタ管理部２５０ａは、スケジュール情報２４０ｂを基にして、減設・増設するｓＬＢ１００、サーバ２０を判定し、ｓＬＢ１００、サーバ２０に対して、増設・減設の命令を送信する。
【０１６４】
振り分け情報管理部２５０ｂは、定期的に、クラスタマスタとなるｓＬＢ１００から振り分け情報を要求し、クラスタマスタから受信した振り分け情報２４０ｃを、記憶部２４０に格納する。上述したｓＬＢ１００のクラスタ管理部１５０ｃは、保守ノード２００のクラスタ管理部２５０ａから振り分け情報の要求を受け付けた場合に、振り分け情報を保守ノード２００に通知するものとする。
【０１６５】
例えば、全ｓＬＢ１００に障害が発生し、障害から復旧した場合に、振り分け情報管理部２５０ｂは、復旧後のクラスタマスタ、クラスタメンバに対して、振り分け情報２４０ｃを通知することで、障害発生前の振り分け情報によるパケット転送を容易に実現することができる。
【０１６６】
次に、本実施例に係るシステムの効果について説明する。本実施例に係るシステムでは、ルータ１７から受信するパケットを、同一の振り分け論理に基づいてサーバ２０に振り分ける複数のｓＬＢ１００のうちいずれかのｓＬＢ１００が故障した場合に、ルータ１７のパケットの送信先から故障したｓＬＢ１００を除外する。このため、複数のｓＬＢ１００のうち、いずれか一台が故障しても、故障したｓＬＢ１００が扱っていたセッションが切断されることを抑止され、ユーザは、セッション（ＴＣＰセッション）を用いたサービスを継続して利用することができる。
【０１６７】
具体的には、図７および図８で説明したように、例えば、クライアント１５から送信されるパケットは、正常時には、ｓＬＢ１００ａを介して、サーバ２０ｃに到達するが、ｓＬＢ１００ａがスケールインすると、ｓＬＢ１００ｂを介して、サーバ２０ｃに到達する。ここで、正常時にｓＬＢ１００ａから転送されるｓＬＢパケットの送信元アドレスはクライアント１５のＩＰアドレスである。また、スケールイン後にｓＬＢ１００ｂから転送されるｓＬＢパケットの送信元アドレスは、クライアント１５のＩＰアドレスである。このため、サーバ２０ｃは、パケットの送信元を継続して認識できるため、セッションを切断すること無く、継続して、クライアント１５にサービスを提供することができる。
【０１６８】
また、各ｓＬＢ１００が利用する振り分け論理（フローテーブル１４０ａ、振り分けテーブル１４０ｂ）は同一ものである。このため、クライアント１５から送信したパケットは、ｓＬＢ１００の減設されることで転送されるｓＬＢ１００が切り替わったとしても、転送先のサーバ２０が同一となり、セッションを切断すること無く、継続して、クライアント１５にサービスを提供することができる。
【０１６９】
また、本実施例に係るシステムでは、上記のように、ｓＬＢ１００を減設しても、継続サービスを実行できるため、トラフィック量に応じてｓＬＢ１００を増設・減設させることで、トラフィック増加時の性能ボトルネックを回避することが可能である。また、従来とは異なり、トラフィックに応じた効率的なｓＬＢ１００の設備のリソース使用が可能となる。従来では、ｓＬＢ１００の最大トラフィック性能を前提とした設備リソース設計が必要で、ｓＬＢ１００として余剰能力を常時確保しておく必要があった。
【０１７０】
ところで、本実施例に係るシステムでは、ｓＬＢ１００が、振り分け情報を相互に通知することで、振り分けテーブル１４０ｂを同一のものに更新していたが、これに限定されるものではない。たとえが、クラスタマスタとなるｓＬＢ１００が、クラスタメンバに、フローテーブル１４０ａを通知することで、各ｓＬＢ１００のフローテーブル１４０ａが同一になるような通信処理を実行しても良い。
【０１７１】
次に、上記実施例に示したｓＬＢ１００、保守ノード２００と同様の機能を実現するコンピュータのハードウェア構成の一例について説明する。図３３は、ｓＬＢと同様の機能を実現するコンピュータのハードウェア構成の一例を示す図である。
【０１７２】
図３３に示すように、コンピュータ３００は、各種演算処理を実行するＣＰＵ３０１と、ユーザからのデータの入力を受け付ける入力装置３０２と、ディスプレイ３０３とを有する。また、コンピュータ３００は、記憶媒体からプログラム等を読み取る読み取り装置３０４と、ネットワークを介して他のコンピュータとの間でデータの授受を行うインタフェース装置３０５とを有する。また、コンピュータ３００は、各種情報を一時記憶するＲＡＭ３０６と、ハードディスク装置３０７とを有する。そして、各装置３０１〜３０７は、バス３０８に接続される。
【０１７３】
ハードディスク装置３０７は、パケット処理プログラム３０７ａ、振り分け機能プログラム３０７ｂ、クラスタ管理プログラム３０７ｃを有する。ＣＰＵ３０１は、パケット処理プログラム３０７ａ、振り分け機能プログラム３０７ｂ、クラスタ管理プログラム３０７ｃを読み出してＲＡＭ３０６に展開する。
【０１７４】
パケット処理プログラム３０７ａは、パケット処理プロセス３０６ａとして機能する。振り分け機能プログラム３０７ｂは、振り分け機能プロセス３０６ｂとして機能する。クラスタ管理プログラム３０７ｃは、クラスタ管理プロセス３０６ｃとして機能する。
【０１７５】
パケット処理プロセス３０６ａの処理は、パケット処理部１５０ａの処理に対応する。振り分け機能プロセス３０６ｂの処理は、振り分け機能部１５０ｂの処理に対応する。クラスタ管理プロセス３０６ｃの処理は、クラスタ管理部１５０ｃの処理に対応する。
【０１７６】
なお、各プログラム３０７ａ〜３０７ｃについては、必ずしも最初からハードディスク装置３０７に記憶させておかなくても良い。例えば、コンピュータ３００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させておく。そして、コンピュータ３００が各プログラム３０７ａ〜３０７ｃを読み出して実行するようにしても良い。
【０１７７】
図３４は、保守ノードと同様の機能を実現するコンピュータのハードウェア構成の一例を示す図である。コンピュータ４００は、各種演算処理を実行するＣＰＵ４０１と、ユーザからのデータの入力を受け付ける入力装置４０２と、ディスプレイ４０３とを有する。また、コンピュータ４００は、記憶媒体からプログラム等を読み取る読み取り装置４０４と、ネットワークを介して他のコンピュータとの間でデータの授受を行うインタフェース装置４０５とを有する。また、コンピュータ４００は、各種情報を一時記憶するＲＡＭ４０６と、ハードディスク装置４０７とを有する。そして、各装置４０１〜４０７は、バス４０８に接続される。
【０１７８】
ハードディスク装置４０７は、クラスタ管理プログラム４０７ａ、振り分け情報管理プログラム４０７ｂを有する。ＣＰＵ４０１は、クラスタ管理プログラム４０７ａ、振り分け情報管理プログラム４０７ｂを読み出してＲＡＭ４０６に展開する。
【０１７９】
クラスタ管理プログラム４０７ａは、クラスタ管理プロセス４０６ａとして機能する。振り分け情報管理プログラム４０７ｂは、振り分け情報管理プロセス４０６ｂとして機能する。
【０１８０】
クラスタ管理プロセス４０６ａの処理は、クラスタ管理部２５０ａの処理に対応する。振り分け情報管理プロセス４０６ｂの処理は、振り分け情報管理部２５０ｂの処理に対応する。
【０１８１】
なお、各プログラム４０７ａ，４０７ｂについては、必ずしも最初からハードディスク装置４０７に記憶させておかなくても良い。例えば、コンピュータ４００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させておく。そして、コンピュータ４００が各プログラム４０７ａ，４０７ｂを読み出して実行するようにしても良い。
【０１８２】
以上の各実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１８３】
（付記１）クライアントと、前記クライアントにサービスを提供する複数のサーバと、前記複数のサーバに処理を割り振る複数のロードバランサと、前記複数のロードバランサに前記クライアントからのパケットを割り振るスイッチとを含む通信制御システムであって、
前記スイッチは、前記クライアントからのパケットを前記複数のロードバランサのいずれかに送信し、
前記複数のロードバランサは、前記複数のロードバランサ間で同一の振り分け論理に基づいて、前記クライアントからのパケットをカプセル化して、前記複数のサーバのいずれかに送信し、
前記複数のサーバは、前記カプセル化されたパケットをデカプセル化し、前記デカプセル化したパケットに基づいて前記サービスに対応した処理を行い、
前記複数のロードバランサは、相互にデータ通信し、いずれかのロードバランサの故障を検出した場合に、故障したロードバランサの情報を前記スイッチに通知し、前記通知を受けたスイッチは、前記故障したロードバランサを振り分け対象から除外する
ことを特徴とする通信制御システム。
【０１８４】
（付記２）前記複数のロードバランサは、サーバの数が増加または減少した場合に、前記振り分け論理を変更し、変更後の振り分け論理を共有することを特徴とする付記１に記載の通信制御システム。
【０１８５】
（付記３）前記振り分け論理は、前記クライアントから送信されるパケットの値に基づくハッシュ値と、パケットの振り分け先となるサーバとを対応付けた振り分け情報、および、前記パケットの値と、振り分け先となるサーバとを対応付けたフロー情報を有し、前記複数のロードバランサは、前記クライアントからのパケットの値が、前記フロー情報に存在しない場合に、前記振り分け情報に基づいて、パケットの振り分け先となるサーバを判定することを特徴とする付記１または２に記載の通信制御システム。
【０１８６】
（付記４）前記振り分け論理は、前記サーバが提供するサービス種別毎に異なる振り分け情報が対応付けられていることを特徴とする付記３に記載の通信制御システム。
【０１８７】
（付記５）前記通信制御システムは、通信制御装置を更に含み、前記スイッチは、経路情報に基づいて、前記クライアントからのパケットを前記複数のロードバランサのいずれかに送信し、前記ロードバランサは、通信制御装置から停止要求を受け付けた場合には、停止対象のロードバランサを経由する経路の削除要求を、前記スイッチに送信することを特徴とする付記１〜４のいずれか一つに記載の通信制御システム。
【０１８８】
（付記６）前記通信制御装置は、停止中のロードバランサを起動させた場合には、前記複数のロードバランサと、起動したロードバランサとの間で、同一の振り分け論理を共有させることを特徴とする付記５に記載の通信制御システム。
【０１８９】
（付記７）前記通信制御装置は、サービス種別、日時または曜日に対応付けて起動させるロードバランサを定義した起動定義情報を保持し、前記起動定義情報を基にして、ロードバランサの起動または停止を制御することを特徴とする付記５または６に記載の通信制御システム。
【０１９０】
（付記８）前記通信制御装置は、前記複数のロードバランサが共有する同一の振り分け論理の情報を取得して、記憶装置に格納し、全てのロードバランサが故障して復旧した後に、前記記憶装置に格納した振り分け論理の情報を前記ロードバランサに通知することを特徴とする付記５、６または７に記載の通信制御システム。
【０１９１】
（付記９）コンピュータに、
クライアントからのパケットを、複数のロードバランサのいずれかに送信するスイッチから受信した場合に、複数のロードバランサ間で同一の振り分け論理に基づいて、受信したパケットをカプセル化して、前記クライアントにサービスを提供する複数のサーバのうちいずれかのサーバに送信し、
複数のロードバランサとの間でデータ通信し、いずれかのロードバランサの故障を検出した場合に、故障したロードバランサの情報を前記スイッチに通知し、故障したロードバランサを振り分け対象から除外する
処理を実行させることを特徴とする通信制御プログラム。
【０１９２】
（付記１０）クライアントと、前記クライアントにサービスを提供する複数のサーバと、前記複数のサーバに処理を割り振る複数のロードバランサと、複数のロードバランサに前記クライアントからの通信を割り振るスイッチとを含む通信制御システムの制御方法であって、
前記スイッチは、前記クライアントからのパケットを前記複数のロードバランサのいずれかに送信し、
前記複数のロードバランサは、前記複数のロードバランサ間で同一の振り分け論理に基づいて、前記クライアントからのパケットをカプセル化して、前記複数のサーバのいずれかに送信し、
前記複数のサーバは、前記カプセル化されたパケットをデカプセル化し、前記デカプセル化したパケットに基づいて前記サービスに対応した処理を行い、
前記複数のロードバランサは、相互にデータ通信し、いずれかのロードバランサの故障を検出した場合に、故障したロードバランサの情報を前記スイッチに通知し、前記通知を受けたスイッチは、前記故障したロードバランサを振り分け対象から除外する
ことを特徴とする通信制御方法。
【０１９３】
（付記１１）前記複数のロードバランサは、サーバの数が増加または減少した場合に、前記振り分け論理を変更し、変更後の振り分け論理を共有することを特徴とする付記１０に記載の通信制御方法。
【０１９４】
（付記１２）前記振り分け論理は、前記クライアントから送信されるパケットの値に基づくハッシュ値と、パケットの振り分け先となるサーバとを対応付けた振り分け情報、および、前記パケットの値と、振り分け先となるサーバとを対応付けたフロー情報を有し、前記複数のロードバランサは、前記クライアントからのパケットの値が、前記フロー情報に存在しない場合に、前記振り分け情報に基づいて、パケットの振り分け先となるサーバを判定することを特徴とする付記１０または１１に記載の通信制御方法。
【０１９５】
（付記１３）前記振り分け論理は、前記サーバが提供するサービス種別毎に異なる振り分け情報が対応付けられていることを特徴とする付記１２に記載の通信制御方法。
【０１９６】
（付記１４）前記通信制御システムは、通信制御装置を更に含み、前記ロードバランサは、前記通信制御装置から停止要求を受け付けた場合には、停止対象のロードバランサを経由する経路の削除要求を、前記スイッチに送信することを特徴とする付記１０〜１３のいずれか一つに記載の通信制御方法。
【０１９７】
（付記１５）前記通信制御装置は、停止中のロードバランサを起動させた場合には、前記複数のロードバランサと、起動したロードバランサとの間で、同一の振り分け論理を共有させることを特徴とする付記１４に記載の通信制御方法。
【０１９８】
（付記１６）前記通信制御装置は、サービス種別、日時または曜日に対応付けて起動させるロードバランサを定義した起動定義情報を保持し、前記起動定義情報を基にして、ロードバランサの起動または停止を制御することを特徴とする付記１４または１５に記載の通信制御方法。
【０１９９】
（付記１７）前記通信制御装置は、前記複数のロードバランサが共有する同一の振り分け論理の情報を取得して、記憶装置に格納し、全てのロードバランサが故障して復旧した後に、前記記憶装置に格納した振り分け論理の情報を前記ロードバランサに通知することを特徴とする付記１４、１５または１６に記載の通信制御方法。
【符号の説明】
【０２００】
１５  クライアント
１６  インターネット
１７ａ，１７ｂ  ルータ
１８  ネットワーク
２０ａ，２０ｂ  サーバ
１００ａ，１００ｂ，１００ｃ  ｓＬＢ
２００  保守ノード
【図１】
2018148537.tif 000003
【図２】
2018148537.tif 000004
【図３】
2018148537.tif 000005
【図４】
2018148537.tif 000006
【図５】
2018148537.tif 000007
【図６】
2018148537.tif 000008
【図７】
2018148537.tif 000009
【図８】
2018148537.tif 000010
【図９】
2018148537.tif 000011
【図１０】
2018148537.tif 000012
【図１１】
2018148537.tif 000013
【図１２】
2018148537.tif 000014
【図１３】
2018148537.tif 000015
【図１４】
2018148537.tif 000016
【図１５】
2018148537.tif 000017
【図１６】
2018148537.tif 000018
【図１７】
2018148537.tif 000019
【図１８】
2018148537.tif 000020
【図１９】
2018148537.tif 000021
【図２０】
2018148537.tif 000022
【図２１】
2018148537.tif 000023
【図２２】
2018148537.tif 000024
【図２３】
2018148537.tif 000025
【図２４】
2018148537.tif 000026
【図２５】
2018148537.tif 000027
【図２６】
2018148537.tif 000028
【図２７】
2018148537.tif 000029
【図２８】
2018148537.tif 000030
【図２９】
2018148537.tif 000031
【図３０】
2018148537.tif 000032
【図３１】
2018148537.tif 000033
【図３２】
2018148537.tif 000034
【図３３】
2018148537.tif 000035
【図３４】
2018148537.tif 000036
【図３５】
2018148537.tif 000037
【図３６】
2018148537.tif 000038