JP2014165560A - サーバおよびプログラム - Google Patents

サーバおよびプログラム Download PDF

Info

Publication number
JP2014165560A
JP2014165560A JP2013032765A JP2013032765A JP2014165560A JP 2014165560 A JP2014165560 A JP 2014165560A JP 2013032765 A JP2013032765 A JP 2013032765A JP 2013032765 A JP2013032765 A JP 2013032765A JP 2014165560 A JP2014165560 A JP 2014165560A
Authority
JP
Japan
Prior art keywords
address
load balancer
server
transmission source
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2013032765A
Other languages
English (en)
Inventor
Hiroshi Noguchi
博史 野口
Masashi Kaneko
雅志 金子
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2013032765A priority Critical patent/JP2014165560A/ja
Publication of JP2014165560A publication Critical patent/JP2014165560A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】複数のサーバを有し、コネクションレス型プロトコルを用いて負荷分散処理を行うクラスタシステムにおいて、クライアント装置からみて、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生するという問題を回避することを課題とする。
【解決手段】本発明のサーバ6は、ロードバランサのアドレスを管理するアドレス管理部(アドレス管理機能621)と、ロードバランサによって振り分けられたリクエストデータを処理して送信元のクライアント装置(対向システム7)にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、アドレス管理部(アドレス管理機能621)が管理するロードバランサのアドレスに設定する送信元アドレス偽装部(送信元アドレス偽装機能622)と、を備える。
【選択図】図6

Description

本発明は、コネクションレス型プロトコルを用いて負荷分散処理を行うクラスタシステムにおける技術に関する。
従来から、複数のサーバによって負荷分散処理を実現するクラスタシステムにおいては、ロードバランサのNAT(Network Address Translation)機能(以下、単に「NAT」と称する。)を利用して複数のサーバを単一のサーバに見せる方法が一般的である。しかし、図1に示すようにクラスタシステム1の構成要素が広域に存在する場合にNATを利用するには、図2に示すようにVPN(Virtual Private Network)等を利用して異なるセグメント2,3の間を広域L(Layer)2ネットワーク101で接続することが必要となり、クラスタシステム1の規模の拡大が難しいという問題がある。また、NATを利用する場合には、サーバ5,6からのレスポンスが常にロードバランサ4を経由することになり、経路上の無駄が発生することがある。
なお、図1,2において、セグメント2では、ロードバランサ4と複数のサーバ5が配置され、それらがL2スイッチ11aに接続され、L2スイッチ11aがルータ12aを介してネットワーク100に接続されている。また、セグメント3では、複数のサーバ6が配置され、それらがL2スイッチ11bに接続され、L2スイッチ11bがルータ12bを介してネットワーク100に接続されている。また、ネットワーク100には、クライアント装置を含む対向システム7が接続されている。なお、以下では、ロードバランサ4、サーバ5,6、対向システム7の動作説明をする場合に、L2スイッチ11a、11b、ルータ12a、12b、ネットワーク100の動作については適宜省略する。
前記した経路上の無駄を考慮し、広域L2ネットワーク101においてNATを利用することなく、このようなクラスタシステム1に対して通信を行うことを考える。このとき、TCP(Transmission Control Protocol)のようなコネクション型プロトコルを用いて通信を行う場合には、通信経路が確立されるため、対向システム7からみて、リクエスト宛先アドレスとレスポンス送信元アドレスは常に一致する。しかし、UDP(User Datagram Protocol)のようなコネクションレス型プロトコルでは、レスポンスの経路が指定されないため、対向システム7からみて、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生する場合があるという問題がある。
この問題について図3を用いて説明する。対向システム7からクラスタシステム1の構成要素であるロードバランサ4へリクエスト(リクエストデータ)を送信したとき(S31)、その処理がサーバ6で行われる場合、そのリクエストはロードバランサ4からサーバ6に転送される(S32)。そして、サーバ6は、レスポンス(レスポンスデータ)を、対向システム7へ直接送信する(S33)。なお、図3のS31において、「toロードバランサ4」は宛先アドレスが「ロードバランサ4のアドレス」であることを示し、「from対向システム7」は送信元アドレスが「対向システム7のアドレス」であることを示す(図3のS32,S33および図4についても同様)。
この場合、対向システム7からみて、リクエストの宛先であるロードバランサ4とは異なるサーバ6からレスポンスが返ってくることとなり、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合からシステムエラーを引き起こすリスクがある。高速通信を要求される通信事業者のネットワークでは、UDPの利用は非常に有効であり、上記問題の解決が望まれる。
これらの問題に対する解決手法の一つとして、DSR(Direct Server Return)という従来技術がある(非特許文献1)。DSRでは、ロードバランサの外部向けIP(Internet Protocol)アドレスとサーバのループバックアドレスを同一のものに設定し、ロードバランサから各サーバへの振り分けをMAC(Media Access Control)アドレスによって実現するのが一般的である。この方法により、リクエストはロードバランサを経由してサーバに届くが、レスポンスに関しては、ロードバランサを経由せずに、かつ送信元アドレスをロードバランサの外部向けIPアドレスに設定して、直接、対向システムに送信することが可能となる。
みやたひろし、「サーバ負荷分散入門」、ソフトバンククリエイティブ株式会社、2012年6月、p.181−184
しかし、DSRを用いた方法では、ロードバランサからサーバへのパケット転送がMACアドレスによって行われるため、広域L2ネットワークによる接続が前提となる。よって、NATの場合と同様に、クラスタシステムの構成要素が広域に及ぶ場合には接続コストが問題となり、L3転送が必要となる広域ネットワークへの適用には不向きである。以上を踏まえ、DSRのようにクラスタシステム内ネットワークをL2に限定するような方法ではなく、大規模システムの構築に適するスケールアウト可能な方法で上記問題を解決することが望ましい。
そこで、本発明は、上記事情に鑑みてなされたものであり、広域L2ネットワークによる接続が不要で、複数のサーバを有し、コネクションレス型プロトコルを用いて負荷分散処理を行うクラスタシステムにおいて、クライアント装置からみて、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生するという問題(以下、「アドレス不整合問題」とも称する。)を回避することを課題とする。
前記課題を解決するために、本発明は、コネクションレス型プロトコルを用いて、ロードバランサによって振り分けられたクライアント装置からのリクエストデータを処理するサーバであって、前記ロードバランサのアドレスを管理するアドレス管理部と、前記ロードバランサによって振り分けられた前記リクエストデータを処理して送信元の前記クライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、前記アドレス管理部が管理する前記ロードバランサのアドレスに設定する送信元アドレス偽装部と、を備えることを特徴とするサーバである。
これによれば、リクエストデータを処理するサーバが、レスポンスデータの送信元アドレスをロードバランサのアドレスに設定(偽装)するので、そのレスポンスデータを受信したクライアント装置において、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生するという問題を回避することができる。
また、本発明は、前記アドレス管理部が、前記ロードバランサのアドレスのほかに、予備のロードバランサのアドレスも管理しており、前記送信元アドレス偽装部は、前記クラスタシステムにおいて前記ロードバランサから前記予備のロードバランサに切り替えられた場合に、前記予備のロードバランサによって振り分けられた前記リクエストデータを処理して送信元の前記クライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、前記アドレス管理部が管理する前記予備のロードバランサのアドレスに設定することを特徴とする。
これによれば、リクエストデータを処理するサーバは、クラスタシステムにおいてロードバランサから予備のロードバランサに切り替えられた場合でも、レスポンスデータの送信元アドレスをその予備のロードバランサのアドレスに設定(偽装)することで、適切に対応できる。
また、本発明は、コンピュータを、前記サーバとして機能させるための送信元アドレス偽装プログラムとして実現できる。これによれば、コンピュータを、前記サーバとして機能させることができる。
本発明によれば、広域L2ネットワークによる接続が不要で、複数のサーバを有し、コネクションレス型プロトコルを用いて負荷分散処理を行うクラスタシステムにおいて、アドレス不整合問題を回避することができる。
本実施形態および従来技術のクラスタシステムを含む全体構成図である。 従来技術のクラスタシステムを含む全体構成図である。 従来技術におけるデータ送受信のシーケンス図である。 本実施形態におけるデータ送受信のシーケンス図である。 本実施形態におけるサーバの機能概要図である。 本実施形態におけるサーバの機能構成図である。 本実施形態におけるアドレス設定に関するデータ送受信のシーケンス図である。 本実施形態におけるレスポンス送信元データの偽装に関するデータ送受信のシーケンス図である。
以下、本発明を実施するための形態(以下、「実施形態」と称する。)について、図面を適宜参照して説明する。本実施形態のクラスタシステム1の構成は、図1の通りであり、その説明は前記しているので省略する。本実施形態の概要を説明すると、対向システム7(クライアント装置)からクラスタシステム1へUDPのリクエストが送信され、その処理がサーバ6で行われるとき、サーバ6は、レスポンスを対向システム7に送信する際、そのレスポンスの送信元アドレスを自身ではなく本来のリクエスト先であるロードバランサ4のアドレスへと偽装することで、アドレス不整合問題を回避する。以下、詳細に説明する。なお、以下では、サーバ5,6のうち代表してサーバ6について説明するが、サーバ5についても構成や動作はサーバ6と同様である。
図4に示すように(図1も適宜参照)、対向システム7からクラスタシステム1の構成要素であるロードバランサ4へリクエストが送信されたとき(S41)、その処理がサーバ6で行われる場合、そのリクエストはロードバランサ4からサーバ6に転送される(S42)。そして、サーバ6は、レスポンスを対向システム7へ直接送信する際(S33)、そのレスポンスの送信元アドレスをロードバランサ4のアドレスに設定(偽装)する。
この送信元アドレスの偽装は、例えば、図5に示すようにサーバ6のOS(Operating System)61より上位に存在するミドルウェア62によってパケットのヘッダを書き換えることによって実現する。ここでは、図5に示すように、サーバ6がOS61、ミドルウェア62、アプリケーション63を有しているものする。
ミドルウェア62は、ロードバランサ4から、宛先アドレスが「サーバ6(のアドレス。以下同様)」で送信元アドレスが「対向システム7」のリクエストを受ける。そして、ミドルウェア62は、本来(従来技術では)、宛先アドレスが「対向システム7」で送信元アドレスが「サーバ6(自身)」のレスポンスを対向システム7に返信するところであるが、管理システム21から事前に設定された送信元アドレス「ロードバランサ4」を用いて、レスポンスの送信元アドレスを「ロードバランサ4」に書き換え、宛先アドレスが「対向システム7」で送信元アドレスが「サーバ6」ではなく「ロードバランサ4」のレスポンスを対向システム7に返信する。これにより、上記した不整合問題を回避できる。なお、管理システム21は、クラスタシステム1の外部に存在し、クラスタシステム1を管理する機能を有する(詳細は後記)。
サーバ6を中心としたクラスタシステム1の具体的な実現方式について、図6を参照してさらに詳述する。サーバ6のミドルウェア62は、アドレス管理機能621(アドレス管理部)と、送信元アドレス偽装機能622(送信元アドレス偽装部)という二つの機能を有している。また、ミドルウェア62には、アドレス管理機能621に対応したアドレス管理データ623と、送信元アドレス偽装機能622に対応したアドレス管理データ624が記憶されている(詳細は図7の説明で後記)。
また、管理システム21は、コンピュータ装置であり、クラスタ管理機能211を有し、クラスタ管理機能211に対応したアドレス管理データ212を記憶している(詳細は図7の説明で後記)。また、管理システム21には、保守者が使用するコンピュータ装置である保守者端末31が接続されている(詳細は図7の説明で後記)。
アドレスの偽装設定の流れについて、図7を参照して説明する(図1、図6を適宜参照)。まず、保守者は、保守者端末31を用いて、サーバ6から対向システム7に送信するレスポンスの送信元アドレスとして偽装するクラスタシステム1の代表アドレス(ロードバランサ4のアドレス。以下、「偽装アドレス」とも称する。)を設定する。そうすると、保守者端末31はその偽装アドレスをアドレス設定信号によってクラスタ管理機能211に送信し(S71)、クラスタ管理機能211はそのアドレス設定信号によりその偽装アドレスをアドレス管理データ212に設定する。なお、アドレス設定信号には、偽装アドレスとクラスタ管理機能211へのアドレス設定命令が含まれる。
次に、クラスタ管理機能211は偽装アドレスをアドレスデータ信号によってサーバ6のアドレス管理機能621に送信し(S72)、アドレス管理機能621はそのアドレスデータ信号により偽装アドレスをアドレス管理データ623に設定する。なお、アドレスデータ信号には、偽装アドレスとアドレス管理機能621へのアドレス設定命令が含まれる。
次に、アドレス管理機能621は偽装アドレスを偽装アドレス信号によってサーバ6内の送信元アドレス偽装機能622に送信し(S73)、送信元アドレス偽装機能622はその偽装アドレス信号により偽装アドレスをアドレス管理データ624に設定する。なお、偽装アドレス信号には、偽装アドレスと送信元アドレス偽装機能622へのアドレス設定命令が含まれる。
次に、偽装アドレスを用いたレスポンス処理の流れについて、図8を参照して説明する(図1、図6を適宜参照)。まず、サーバ6のアプリケーション63は、レスポンスパケットを生成し、そのレスポンスパケットをパケットデータ信号により送信元アドレス偽装機能622に送信する(S81)。このパケットデータ信号では、送信元アドレスが「サーバ6」となっている。
次に、送信元アドレス偽装機能622は、アドレス管理データ624を参照して、レスポンスパケットにおける送信元アドレスを、「サーバ6」から偽装アドレスに置換し、その置換後のレスポンスパケットをレスポンス信号として対向システム7に送信する(S82)。このような処理を、アプリケーション63が生成するUDPの全パケットに対して行う。
このように、本実施形態のサーバ6によれば、レスポンスデータの送信元アドレスをロードバランサのアドレスに設定(偽装)するので、そのレスポンスデータを受信したクライアント装置において、リクエスト宛先アドレスとレスポンス送信元アドレスの不整合が発生するという問題を回避することができる。その際、広域L2ネットワークによる接続やVPN等が不要で、ヘッダの送信元アドレスを書き換える仕組みを加えるのみで実装することが可能である。また、NATを利用した場合と比較して、無駄のない通信経路を使用して通信を行うことが可能となる。
以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、アドレス管理機能621が、ロードバランサ4のアドレスのほかに、予備のロードバランサのアドレスも管理しており、送信元アドレス偽装機能622は、クラスタシステム1においてロードバランサ4から予備のロードバランサに切り替えられた場合に、その予備のロードバランサによって振り分けられたリクエストデータを処理して送信元のクライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、アドレス管理機能621が管理する予備のロードバランサのアドレスに設定するようにしてもよい。そうすれば、クラスタシステム1においてロードバランサ4から故障等の理由により予備のロードバランサに切り替えられた場合でも、レスポンスデータの送信元アドレスをその予備のロードバランサのアドレスに設定(偽装)することで、適切に対応できる。
また、本発明は、コンピュータを、サーバ6として機能させるための送信元アドレス偽装プログラムとして実現できる。これによれば、コンピュータを、サーバ6として機能させることができる。
また、送信元アドレス偽装機能622は、送信元アドレス偽装機能622以外の機能に対しても偽装アドレスを通知できるようにしてもよく、例えばTCPのようにリクエストと同じ経路でロードバランサ4にレスポンスを返す機能等を実現できるようにしてもよい。
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
1 クラスタシステム
2,3 セグメント
4 ロードバランサ
5,6 サーバ
7 対向システム(クライアント装置)
11a,11b L2スイッチ
12a,12b ルータ
21 管理システム
31 保守者端末
61 OS
62 ミドルウェア
63 アプリケーション
100 ネットワーク
101 広域L2ネットワーク
211 クラスタ管理機能
212 アドレス管理データ
621 アドレス管理機能(アドレス管理部)
622 送信元アドレス偽装機能(送信元アドレス偽装部)
623 アドレス管理データ
624 アドレス管理データ

Claims (3)

  1. コネクションレス型プロトコルを用いて、ロードバランサによって振り分けられたクライアント装置からのリクエストデータを処理するサーバであって、
    前記ロードバランサのアドレスを管理するアドレス管理部と、
    前記ロードバランサによって振り分けられた前記リクエストデータを処理して送信元の前記クライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、前記アドレス管理部が管理する前記ロードバランサのアドレスに設定する送信元アドレス偽装部と、
    を備えることを特徴とするサーバ。
  2. 前記アドレス管理部は、前記ロードバランサのアドレスのほかに、予備のロードバランサのアドレスも管理しており、
    前記送信元アドレス偽装部は、前記クラスタシステムにおいて前記ロードバランサから前記予備のロードバランサに切り替えられた場合に、
    前記予備のロードバランサによって振り分けられた前記リクエストデータを処理して送信元の前記クライアント装置にレスポンスデータを送信する際に、当該レスポンスデータの送信元アドレスを、前記アドレス管理部が管理する前記予備のロードバランサのアドレスに設定する
    ことを特徴とする請求項1に記載のサーバ。
  3. コンピュータを、請求項1または請求項2に記載のサーバとして機能させるためのプログラム。
JP2013032765A 2013-02-22 2013-02-22 サーバおよびプログラム Pending JP2014165560A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013032765A JP2014165560A (ja) 2013-02-22 2013-02-22 サーバおよびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013032765A JP2014165560A (ja) 2013-02-22 2013-02-22 サーバおよびプログラム

Publications (1)

Publication Number Publication Date
JP2014165560A true JP2014165560A (ja) 2014-09-08

Family

ID=51615831

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013032765A Pending JP2014165560A (ja) 2013-02-22 2013-02-22 サーバおよびプログラム

Country Status (1)

Country Link
JP (1) JP2014165560A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112532534A (zh) * 2020-11-25 2021-03-19 腾讯科技(深圳)有限公司 一种数据传输方法、装置以及计算机可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003122731A (ja) * 2001-10-18 2003-04-25 Fujitsu Ltd ネットワークプロセッサの負荷分散装置
JP2003174473A (ja) * 2001-12-06 2003-06-20 Fujitsu Ltd サーバ負荷分散システム
JP2006277570A (ja) * 2005-03-30 2006-10-12 Toshiba Corp 負荷分散システム、負荷分散装置、実サーバ及び負荷分散方法
JP2012155564A (ja) * 2011-01-27 2012-08-16 Nippon Telegr & Teleph Corp <Ntt> 通信ノードのサーバクラウド化ネットワーク

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003122731A (ja) * 2001-10-18 2003-04-25 Fujitsu Ltd ネットワークプロセッサの負荷分散装置
JP2003174473A (ja) * 2001-12-06 2003-06-20 Fujitsu Ltd サーバ負荷分散システム
JP2006277570A (ja) * 2005-03-30 2006-10-12 Toshiba Corp 負荷分散システム、負荷分散装置、実サーバ及び負荷分散方法
JP2012155564A (ja) * 2011-01-27 2012-08-16 Nippon Telegr & Teleph Corp <Ntt> 通信ノードのサーバクラウド化ネットワーク

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112532534A (zh) * 2020-11-25 2021-03-19 腾讯科技(深圳)有限公司 一种数据传输方法、装置以及计算机可读存储介质
CN112532534B (zh) * 2020-11-25 2024-04-23 腾讯科技(深圳)有限公司 一种数据传输方法、装置以及计算机可读存储介质

Similar Documents

Publication Publication Date Title
US11070447B2 (en) System and method for implementing and managing virtual networks
JP7004405B2 (ja) 仮想ネットワークにおける分散型フロー状態p2p設定のためのシステムおよび方法
US11563758B2 (en) Rule-based network-threat detection for encrypted communications
US9413659B2 (en) Distributed network address and port translation for migrating flows between service chains in a network environment
EP3225014B1 (en) Source ip address transparency systems and methods
US11882199B2 (en) Virtual private network (VPN) whose traffic is intelligently routed
US8667574B2 (en) Assigning a network address for a virtual device to virtually extend the functionality of a network device
US9712649B2 (en) CCN fragmentation gateway
CN102148767A (zh) 一种基于nat的数据路由方法及其装置
JP2011160041A (ja) フロントエンドシステム、フロントエンド処理方法
JPWO2016042587A1 (ja) 攻撃観察装置、及び攻撃観察方法
US20110276673A1 (en) Virtually extending the functionality of a network device
US20070147376A1 (en) Router-assisted DDoS protection by tunneling replicas
JP2014165560A (ja) サーバおよびプログラム
WO2022013908A1 (ja) 通信中継装置、通信中継システム、通信中継方法、および、プログラム
KR101445255B1 (ko) 부하 분산 설정을 자동으로 제공하기 위한 방법, 장치, 시스템 및 컴퓨터 판독 가능한 기록 매체
JP2016015674A (ja) 制御装置、制御方法、および、制御プログラム
KR20140093042A (ko) 통신 방법 및 장치

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20140529

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20141201

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20141209

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20150414