(57)【要約】【課題】複数のサーバを有し、コネクションレス型プロトコルを用いて負荷分散処理を行うクラスタシステムにおいて、クライアント装置からみて、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生するという問題を回避することを課題とする。【解決手段】本発明のサーバ６は、ロードバランサのアドレスを管理するアドレス管理部（アドレス管理機能６２１）と、ロードバランサによって振り分けられたリクエストデータを処理して送信元のクライアント装置（対向システム７）にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、アドレス管理部（アドレス管理機能６２１）が管理するロードバランサのアドレスに設定する送信元アドレス偽装部（送信元アドレス偽装機能６２２）と、を備える。【選択図】図６
2014165560.tif 000002
【特許請求の範囲】
【請求項１】
コネクションレス型プロトコルを用いて、ロードバランサによって振り分けられたクライアント装置からのリクエストデータを処理するサーバであって、
前記ロードバランサのアドレスを管理するアドレス管理部と、
前記ロードバランサによって振り分けられた前記リクエストデータを処理して送信元の前記クライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、前記アドレス管理部が管理する前記ロードバランサのアドレスに設定する送信元アドレス偽装部と、
を備えることを特徴とするサーバ。
【請求項２】
前記アドレス管理部は、前記ロードバランサのアドレスのほかに、予備のロードバランサのアドレスも管理しており、
前記送信元アドレス偽装部は、前記クラスタシステムにおいて前記ロードバランサから前記予備のロードバランサに切り替えられた場合に、
前記予備のロードバランサによって振り分けられた前記リクエストデータを処理して送信元の前記クライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、前記アドレス管理部が管理する前記予備のロードバランサのアドレスに設定する
ことを特徴とする請求項１に記載のサーバ。
【請求項３】
コンピュータを、請求項１または請求項２に記載のサーバとして機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コネクションレス型プロトコルを用いて負荷分散処理を行うクラスタシステムにおける技術に関する。
【背景技術】
【０００２】
従来から、複数のサーバによって負荷分散処理を実現するクラスタシステムにおいては、ロードバランサのＮＡＴ（Network Address Translation）機能（以下、単に「ＮＡＴ」と称する。）を利用して複数のサーバを単一のサーバに見せる方法が一般的である。しかし、図１に示すようにクラスタシステム１の構成要素が広域に存在する場合にＮＡＴを利用するには、図２に示すようにＶＰＮ（Virtual Private Network）等を利用して異なるセグメント２，３の間を広域Ｌ（Layer）２ネットワーク１０１で接続することが必要となり、クラスタシステム１の規模の拡大が難しいという問題がある。また、ＮＡＴを利用する場合には、サーバ５，６からのレスポンスが常にロードバランサ４を経由することになり、経路上の無駄が発生することがある。
【０００３】
なお、図１，２において、セグメント２では、ロードバランサ４と複数のサーバ５が配置され、それらがＬ２スイッチ１１ａに接続され、Ｌ２スイッチ１１ａがルータ１２ａを介してネットワーク１００に接続されている。また、セグメント３では、複数のサーバ６が配置され、それらがＬ２スイッチ１１ｂに接続され、Ｌ２スイッチ１１ｂがルータ１２ｂを介してネットワーク１００に接続されている。また、ネットワーク１００には、クライアント装置を含む対向システム７が接続されている。なお、以下では、ロードバランサ４、サーバ５，６、対向システム７の動作説明をする場合に、Ｌ２スイッチ１１ａ、１１ｂ、ルータ１２ａ、１２ｂ、ネットワーク１００の動作については適宜省略する。
【０００４】
前記した経路上の無駄を考慮し、広域Ｌ２ネットワーク１０１においてＮＡＴを利用することなく、このようなクラスタシステム１に対して通信を行うことを考える。このとき、ＴＣＰ（Transmission Control Protocol）のようなコネクション型プロトコルを用いて通信を行う場合には、通信経路が確立されるため、対向システム７からみて、リクエスト宛先アドレスとレスポンス送信元アドレスは常に一致する。しかし、ＵＤＰ（User Datagram Protocol）のようなコネクションレス型プロトコルでは、レスポンスの経路が指定されないため、対向システム７からみて、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生する場合があるという問題がある。
【０００５】
この問題について図３を用いて説明する。対向システム７からクラスタシステム１の構成要素であるロードバランサ４へリクエスト（リクエストデータ）を送信したとき（Ｓ３１）、その処理がサーバ６で行われる場合、そのリクエストはロードバランサ４からサーバ６に転送される（Ｓ３２）。そして、サーバ６は、レスポンス（レスポンスデータ）を、対向システム７へ直接送信する（Ｓ３３）。なお、図３のＳ３１において、「toロードバランサ４」は宛先アドレスが「ロードバランサ４のアドレス」であることを示し、「from対向システム７」は送信元アドレスが「対向システム７のアドレス」であることを示す（図３のＳ３２，Ｓ３３および図４についても同様）。
【０００６】
この場合、対向システム７からみて、リクエストの宛先であるロードバランサ４とは異なるサーバ６からレスポンスが返ってくることとなり、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合からシステムエラーを引き起こすリスクがある。高速通信を要求される通信事業者のネットワークでは、ＵＤＰの利用は非常に有効であり、上記問題の解決が望まれる。
【０００７】
これらの問題に対する解決手法の一つとして、ＤＳＲ（Direct Server Return）という従来技術がある（非特許文献１）。ＤＳＲでは、ロードバランサの外部向けＩＰ（Internet Protocol）アドレスとサーバのループバックアドレスを同一のものに設定し、ロードバランサから各サーバへの振り分けをＭＡＣ（Media Access Control）アドレスによって実現するのが一般的である。この方法により、リクエストはロードバランサを経由してサーバに届くが、レスポンスに関しては、ロードバランサを経由せずに、かつ送信元アドレスをロードバランサの外部向けＩＰアドレスに設定して、直接、対向システムに送信することが可能となる。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】みやたひろし、「サーバ負荷分散入門」、ソフトバンククリエイティブ株式会社、２０１２年６月、ｐ．１８１−１８４
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、ＤＳＲを用いた方法では、ロードバランサからサーバへのパケット転送がＭＡＣアドレスによって行われるため、広域Ｌ２ネットワークによる接続が前提となる。よって、ＮＡＴの場合と同様に、クラスタシステムの構成要素が広域に及ぶ場合には接続コストが問題となり、Ｌ３転送が必要となる広域ネットワークへの適用には不向きである。以上を踏まえ、ＤＳＲのようにクラスタシステム内ネットワークをＬ２に限定するような方法ではなく、大規模システムの構築に適するスケールアウト可能な方法で上記問題を解決することが望ましい。
【００１０】
そこで、本発明は、上記事情に鑑みてなされたものであり、広域Ｌ２ネットワークによる接続が不要で、複数のサーバを有し、コネクションレス型プロトコルを用いて負荷分散処理を行うクラスタシステムにおいて、クライアント装置からみて、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生するという問題（以下、「アドレス不整合問題」とも称する。）を回避することを課題とする。
【課題を解決するための手段】
【００１１】
前記課題を解決するために、本発明は、コネクションレス型プロトコルを用いて、ロードバランサによって振り分けられたクライアント装置からのリクエストデータを処理するサーバであって、前記ロードバランサのアドレスを管理するアドレス管理部と、前記ロードバランサによって振り分けられた前記リクエストデータを処理して送信元の前記クライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、前記アドレス管理部が管理する前記ロードバランサのアドレスに設定する送信元アドレス偽装部と、を備えることを特徴とするサーバである。
【００１２】
これによれば、リクエストデータを処理するサーバが、レスポンスデータの送信元アドレスをロードバランサのアドレスに設定（偽装）するので、そのレスポンスデータを受信したクライアント装置において、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生するという問題を回避することができる。
【００１３】
また、本発明は、前記アドレス管理部が、前記ロードバランサのアドレスのほかに、予備のロードバランサのアドレスも管理しており、前記送信元アドレス偽装部は、前記クラスタシステムにおいて前記ロードバランサから前記予備のロードバランサに切り替えられた場合に、前記予備のロードバランサによって振り分けられた前記リクエストデータを処理して送信元の前記クライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、前記アドレス管理部が管理する前記予備のロードバランサのアドレスに設定することを特徴とする。
【００１４】
これによれば、リクエストデータを処理するサーバは、クラスタシステムにおいてロードバランサから予備のロードバランサに切り替えられた場合でも、レスポンスデータの送信元アドレスをその予備のロードバランサのアドレスに設定（偽装）することで、適切に対応できる。
【００１５】
また、本発明は、コンピュータを、前記サーバとして機能させるための送信元アドレス偽装プログラムとして実現できる。これによれば、コンピュータを、前記サーバとして機能させることができる。
【発明の効果】
【００１６】
本発明によれば、広域Ｌ２ネットワークによる接続が不要で、複数のサーバを有し、コネクションレス型プロトコルを用いて負荷分散処理を行うクラスタシステムにおいて、アドレス不整合問題を回避することができる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態および従来技術のクラスタシステムを含む全体構成図である。
【図２】従来技術のクラスタシステムを含む全体構成図である。
【図３】従来技術におけるデータ送受信のシーケンス図である。
【図４】本実施形態におけるデータ送受信のシーケンス図である。
【図５】本実施形態におけるサーバの機能概要図である。
【図６】本実施形態におけるサーバの機能構成図である。
【図７】本実施形態におけるアドレス設定に関するデータ送受信のシーケンス図である。
【図８】本実施形態におけるレスポンス送信元データの偽装に関するデータ送受信のシーケンス図である。
【発明を実施するための形態】
【００１８】
以下、本発明を実施するための形態（以下、「実施形態」と称する。）について、図面を適宜参照して説明する。本実施形態のクラスタシステム１の構成は、図１の通りであり、その説明は前記しているので省略する。本実施形態の概要を説明すると、対向システム７（クライアント装置）からクラスタシステム１へＵＤＰのリクエストが送信され、その処理がサーバ６で行われるとき、サーバ６は、レスポンスを対向システム７に送信する際、そのレスポンスの送信元アドレスを自身ではなく本来のリクエスト先であるロードバランサ４のアドレスへと偽装することで、アドレス不整合問題を回避する。以下、詳細に説明する。なお、以下では、サーバ５，６のうち代表してサーバ６について説明するが、サーバ５についても構成や動作はサーバ６と同様である。
【００１９】
図４に示すように（図１も適宜参照）、対向システム７からクラスタシステム１の構成要素であるロードバランサ４へリクエストが送信されたとき（Ｓ４１）、その処理がサーバ６で行われる場合、そのリクエストはロードバランサ４からサーバ６に転送される（Ｓ４２）。そして、サーバ６は、レスポンスを対向システム７へ直接送信する際（Ｓ３３）、そのレスポンスの送信元アドレスをロードバランサ４のアドレスに設定（偽装）する。
【００２０】
この送信元アドレスの偽装は、例えば、図５に示すようにサーバ６のＯＳ（Operating System）６１より上位に存在するミドルウェア６２によってパケットのヘッダを書き換えることによって実現する。ここでは、図５に示すように、サーバ６がＯＳ６１、ミドルウェア６２、アプリケーション６３を有しているものする。
【００２１】
ミドルウェア６２は、ロードバランサ４から、宛先アドレスが「サーバ６（のアドレス。以下同様）」で送信元アドレスが「対向システム７」のリクエストを受ける。そして、ミドルウェア６２は、本来（従来技術では）、宛先アドレスが「対向システム７」で送信元アドレスが「サーバ６（自身）」のレスポンスを対向システム７に返信するところであるが、管理システム２１から事前に設定された送信元アドレス「ロードバランサ４」を用いて、レスポンスの送信元アドレスを「ロードバランサ４」に書き換え、宛先アドレスが「対向システム７」で送信元アドレスが「サーバ６」ではなく「ロードバランサ４」のレスポンスを対向システム７に返信する。これにより、上記した不整合問題を回避できる。なお、管理システム２１は、クラスタシステム１の外部に存在し、クラスタシステム１を管理する機能を有する（詳細は後記）。
【００２２】
サーバ６を中心としたクラスタシステム１の具体的な実現方式について、図６を参照してさらに詳述する。サーバ６のミドルウェア６２は、アドレス管理機能６２１（アドレス管理部）と、送信元アドレス偽装機能６２２（送信元アドレス偽装部）という二つの機能を有している。また、ミドルウェア６２には、アドレス管理機能６２１に対応したアドレス管理データ６２３と、送信元アドレス偽装機能６２２に対応したアドレス管理データ６２４が記憶されている（詳細は図７の説明で後記）。
【００２３】
また、管理システム２１は、コンピュータ装置であり、クラスタ管理機能２１１を有し、クラスタ管理機能２１１に対応したアドレス管理データ２１２を記憶している（詳細は図７の説明で後記）。また、管理システム２１には、保守者が使用するコンピュータ装置である保守者端末３１が接続されている（詳細は図７の説明で後記）。
【００２４】
アドレスの偽装設定の流れについて、図７を参照して説明する（図１、図６を適宜参照）。まず、保守者は、保守者端末３１を用いて、サーバ６から対向システム７に送信するレスポンスの送信元アドレスとして偽装するクラスタシステム１の代表アドレス（ロードバランサ４のアドレス。以下、「偽装アドレス」とも称する。）を設定する。そうすると、保守者端末３１はその偽装アドレスをアドレス設定信号によってクラスタ管理機能２１１に送信し（Ｓ７１）、クラスタ管理機能２１１はそのアドレス設定信号によりその偽装アドレスをアドレス管理データ２１２に設定する。なお、アドレス設定信号には、偽装アドレスとクラスタ管理機能２１１へのアドレス設定命令が含まれる。
【００２５】
次に、クラスタ管理機能２１１は偽装アドレスをアドレスデータ信号によってサーバ６のアドレス管理機能６２１に送信し（Ｓ７２）、アドレス管理機能６２１はそのアドレスデータ信号により偽装アドレスをアドレス管理データ６２３に設定する。なお、アドレスデータ信号には、偽装アドレスとアドレス管理機能６２１へのアドレス設定命令が含まれる。
【００２６】
次に、アドレス管理機能６２１は偽装アドレスを偽装アドレス信号によってサーバ６内の送信元アドレス偽装機能６２２に送信し（Ｓ７３）、送信元アドレス偽装機能６２２はその偽装アドレス信号により偽装アドレスをアドレス管理データ６２４に設定する。なお、偽装アドレス信号には、偽装アドレスと送信元アドレス偽装機能６２２へのアドレス設定命令が含まれる。
【００２７】
次に、偽装アドレスを用いたレスポンス処理の流れについて、図８を参照して説明する（図１、図６を適宜参照）。まず、サーバ６のアプリケーション６３は、レスポンスパケットを生成し、そのレスポンスパケットをパケットデータ信号により送信元アドレス偽装機能６２２に送信する（Ｓ８１）。このパケットデータ信号では、送信元アドレスが「サーバ６」となっている。
【００２８】
次に、送信元アドレス偽装機能６２２は、アドレス管理データ６２４を参照して、レスポンスパケットにおける送信元アドレスを、「サーバ６」から偽装アドレスに置換し、その置換後のレスポンスパケットをレスポンス信号として対向システム７に送信する（Ｓ８２）。このような処理を、アプリケーション６３が生成するＵＤＰの全パケットに対して行う。
【００２９】
このように、本実施形態のサーバ６によれば、レスポンスデータの送信元アドレスをロードバランサのアドレスに設定（偽装）するので、そのレスポンスデータを受信したクライアント装置において、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生するという問題を回避することができる。その際、広域Ｌ２ネットワークによる接続やＶＰＮ等が不要で、ヘッダの送信元アドレスを書き換える仕組みを加えるのみで実装することが可能である。また、ＮＡＴを利用した場合と比較して、無駄のない通信経路を使用して通信を行うことが可能となる。
【００３０】
以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、アドレス管理機能６２１が、ロードバランサ４のアドレスのほかに、予備のロードバランサのアドレスも管理しており、送信元アドレス偽装機能６２２は、クラスタシステム１においてロードバランサ４から予備のロードバランサに切り替えられた場合に、その予備のロードバランサによって振り分けられたリクエストデータを処理して送信元のクライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、アドレス管理機能６２１が管理する予備のロードバランサのアドレスに設定するようにしてもよい。そうすれば、クラスタシステム１においてロードバランサ４から故障等の理由により予備のロードバランサに切り替えられた場合でも、レスポンスデータの送信元アドレスをその予備のロードバランサのアドレスに設定（偽装）することで、適切に対応できる。
【００３１】
また、本発明は、コンピュータを、サーバ６として機能させるための送信元アドレス偽装プログラムとして実現できる。これによれば、コンピュータを、サーバ６として機能させることができる。
【００３２】
また、送信元アドレス偽装機能６２２は、送信元アドレス偽装機能６２２以外の機能に対しても偽装アドレスを通知できるようにしてもよく、例えばＴＣＰのようにリクエストと同じ経路でロードバランサ４にレスポンスを返す機能等を実現できるようにしてもよい。
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００３３】
１      クラスタシステム
２，３  セグメント
４      ロードバランサ
５，６  サーバ
７      対向システム（クライアント装置）
１１ａ，１１ｂ  Ｌ２スイッチ
１２ａ，１２ｂ  ルータ
２１    管理システム
３１    保守者端末
６１    ＯＳ
６２    ミドルウェア
６３    アプリケーション
１００  ネットワーク
１０１  広域Ｌ２ネットワーク
２１１  クラスタ管理機能
２１２  アドレス管理データ
６２１  アドレス管理機能（アドレス管理部）
６２２  送信元アドレス偽装機能（送信元アドレス偽装部）
６２３  アドレス管理データ
６２４  アドレス管理データ
【図１】
2014165560.tif 000003
【図２】
2014165560.tif 000004
【図３】
2014165560.tif 000005
【図４】
2014165560.tif 000006
【図５】
2014165560.tif 000007
【図６】
2014165560.tif 000008
【図７】
2014165560.tif 000009
【図８】
2014165560.tif 000010