JP2006259845A - サーバ装置、サーバシステムおよびサーバシステムの負荷分散方法 - Google Patents

サーバ装置、サーバシステムおよびサーバシステムの負荷分散方法 Download PDF

Info

Publication number
JP2006259845A
JP2006259845A JP2005072990A JP2005072990A JP2006259845A JP 2006259845 A JP2006259845 A JP 2006259845A JP 2005072990 A JP2005072990 A JP 2005072990A JP 2005072990 A JP2005072990 A JP 2005072990A JP 2006259845 A JP2006259845 A JP 2006259845A
Authority
JP
Japan
Prior art keywords
server
node
service
client
packet
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.)
Granted
Application number
JP2005072990A
Other languages
English (en)
Other versions
JP3930516B2 (ja
Inventor
Junichi Nakazato
淳一 中里
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.)
Toshiba Corp
Toshiba Digital Solutions Corp
Original Assignee
Toshiba Corp
Toshiba Solutions 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 Toshiba Corp, Toshiba Solutions Corp filed Critical Toshiba Corp
Priority to JP2005072990A priority Critical patent/JP3930516B2/ja
Publication of JP2006259845A publication Critical patent/JP2006259845A/ja
Application granted granted Critical
Publication of JP3930516B2 publication Critical patent/JP3930516B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】前段に負荷分散装置を設置すること無く、かつ、単一のIPアドレスのみの使用で、複数サーバを論理的に単一のサーバに見せることのできるサーバ装置を提供する。
【解決手段】クライアント−サーバモデルの計算機システムとして、他のノードと協働してクライアントにサービスを提供する本発明の各ノード1は、イーサネット(登録商標)ドライバ12とイーサネット(登録商標)層14との間に仮想イーサネット(登録商標)層13を配置している。そして、仮想イーサネット(登録商標)層13は、サービス用ネットワーク3経由のクライアントからのパケットを制御用ネットワーク4経由で他のノードに転送する機能と、このパケットの転送を行った場合に、他のノードのMACアドレスを送信元MACアドレスとするGratuitousARPをクライアントに送信するようにARP処理部19に指示する機能とを有している。
【選択図】 図2

Description

この発明は、クライアント装置に対するサービスの提供を複数のサーバ装置で行うクライアント−サーバモデルの計算機システムにおける負荷分散技術に関する。
クライアント−サーバモデルにてクライアントにサービスを提供する計算機システムでは、複数のサーバ上で同一のサービスを動作させ、クライアントからの当該サービスへのアクセスをこれら複数のサーバの何れかに振り分ける手法が用いられることが多い。負荷分散、スケーラビリティの確保、信頼性の確保が可能だからである。
このようなメリットがある一方、複数のサーバのうち、どのサーバにアクセスすべきかをクライアントが決定するような仕組みでは、クライアントが行うべきアクセス方法が煩雑になってしまう。よって、クライアントからのアクセスの利便性を考慮すると、物理的に複数のサーバを論理的に単一のサーバであるかのようにクライアントに見せることは必須であり、現在広く使用されているTCP/IPベースのネットワークにおいては、DNSによるサーバの名前解決時に、クライアントに対して異なるIPアドレス(何れかのサーバのIPアドレス)を返す方法や、サーバ群の前段(フロントエンド)に負荷分散装置を設置する方法などが用いられることが多い。
(1)DNSによる名前解決時に異なるIPアドレスをクライアントへ返す方法
複数のサーバはそれぞれ異なるIPアドレスを持っており、一方、これらサーバ群に対する名前(URL)はただ1つとし、それをクライアントに対して公開する。
クライアントは、サーバにアクセスするときに、公開されたサーバの名前(URL)を使用してアクセスすることになるが、DNSによる名前解決を行う時点で、DNSサーバが、サーバの名前解決を問い合わせてきたクライアントに対して、複数存在するサーバのうちの何れかのサーバのIPアドレスを返す。
即ち、異なるクライアントに対して異なるIPアドレスを返すことで、実際には複数サーバ構成でサービスを実現しているが、クライアントに対しては単一のサーバ(名前)であるかのように見せることが出来る。
(2)負荷分散装置を用いる方法
クライアントは負荷分散装置のIPアドレスに対してアクセスを行う。つまり、クライアントからは負荷分散装置がサーバに見えるが、負荷分散装置が、クライアントからのアクセスを各サーバに振り分けることにより、複数サーバによるクライアントへのサービス提供を実現する。
しかしながら、これらの方法には、それぞれに以下のような問題がある。
まず、前者の方法では、複数の(実際に存在するサーバの数だけ)IPアドレスが必要になるため、十分なIPアドレスを用意することが出来ない状況では、クライアントからのアクセス増大に対応すべくサーバを増やすことが容易ではなく、スケーラビリティの確保が難しい。また、DNSサーバに処理が集中するため、DNSサービスの信頼性の確保のための投資も必要となる。
一方、後者の方法では、負荷分散装置に処理が集中するため、負荷分散装置の性能がボトルネックとなり得る。また、負荷分散処理の高信頼化のためには複数の負荷分散装置を用意するための投資も必要である。更に、複数の負荷分散装置を用いる場合は、それぞれの負荷分散装置にIPアドレスが必要になるため、前述のDNSによる方法と同様の問題も生じる。
この発明は、このような事情を考慮してなされたものであり、サーバ群の前段に負荷分散装置を設置すること無く、かつ、単一のIPアドレスのみの使用で、複数サーバを論理的に単一のサーバに見せることを可能としたサーバ装置、サーバシステムおよびサーバシステムの負荷分散方法を提供することを目的とする。
本目的を達成するために、この発明は、単一のIPアドレスを共有する他のサーバ装置と協働してクライアント装置に対するサービスの提供を行うサーバ装置であって、前記クライアント装置からのパケットを前記他のサーバ装置に転送するパケット転送手段と、前記パケット転送手段によるパケットの転送が行われた場合に、前記他のサーバ装置のMACアドレスを送信元MACアドレスとするGratuitousARPを前記クライアント装置に送信するARP処理手段とを具備することを特徴とする。
また、この発明のサーバシステムは、単一のIPアドレスを共有する複数の前記サーバ装置と、前記複数のサーバ装置間を接続するための第1のネットワークと、サービスの提供を受けるクライアント装置と前記複数のサーバ装置との間を接続するための第2のネットワークとを具備することを特徴とする。
また、この発明は、単一のIPアドレスを共有する複数のサーバ装置でクライアント装置に対するサービスの提供を行うサーバシステムの負荷分散方法であって、前記複数のサーバ装置それぞれが、前記クライアント装置からのパケットを前記他のサーバ装置に転送するステップと、前記パケットの転送を行った場合に、前記他のサーバ装置のMACアドレスを送信元MACアドレスとするGratuitousARPを前記クライアント装置に送信するステップとを具備することを特徴とする。
この発明によれば、サーバ群の前段に負荷分散装置を設置すること無く、かつ、単一のIPアドレスのみの使用で、複数サーバを論理的に単一のサーバに見せることを可能としたサーバ装置、サーバシステムおよびサーバシステムの負荷分散方法を提供することができる。
以下、図面を参照してこの発明の一実施形態を説明する。
図1は、本実施形態に係るサーバシステムの全体構成を示す図である。なお、以下の説明では、現在広く普及している、レイヤ2(リンクレベル)にはイーサネット(登録商標)を、レイヤ3にはIP(InternetProtocol)を使用したネットワークを想定している。
図1において、ノード1は、クライアント2に対して各種サービスを提供する計算機、いわゆるクライアント−サーバモデルにおいてサーバと呼ばれるものである。なお、本発明では、ノード数に制限は無い。また、各ノードは一意なノード識別子(0,1,…)を持つ。
サービス用ネットワーク3は、ノード1とクライアント2の双方が接続しているネットワークであり、サーバ1とクライアント2との間の通信に使用される単一イーサネット(登録商標)セグメントである。一方、制御用ネットワーク4は、単一のIPアドレスを共有する全てのノード1が接続され、ノード1間の制御情報等のやり取りや、クライアント2のアクセスをノード1間で転送する場合に使用されるものである。
この制御用ネットワーク4のネットワークの種類は特に制限は無いが、一般的にコスト面で有利なイーサネット(登録商標)が用いられることが想定される。また、制御用ネットワーク4での通信に用いる上位プロトコルは特に制限は無い。つまり、IPを使わない場合は、制御用ネットワーク4に接続しているネットワークインタフェースにはIPアドレスを付与する必要もない。本発明では、この制御用ネットワーク4での具体的な通信手段(プロトコル)には言及しない。
ノード1の種別には、マスタとスレーブがある。制御用ネットワーク4に接続されているノードのうち、ただひとつのノードがマスタとなり、それ以外のノードは全てスレーブとなる。マスタであるノードは特別な役割を持つ(後述)。なお、マスタの選出方法には各種方法が考えられるが、マスタ選出方法は本発明の主旨では無いため、ここでは何らかの方法でただ1つのノードがマスタに選出されることとする。
各ノード1内のサービスとは、ノード1がクライアント2に対して提供するサービスであり、例えば、NFS(Network File System)やCIFS(Common Internet File System)のようなネットワーク越しのファイルシステムサービスを提供するプログラムであったり、あるいは、データベース、Webサービス等を提供するプログラムである。なお、本発明では、サービスの内容に制約は無い。また、各ノード1上では異なるサービスを動作させることも同一のサービスを動作させることもでき、これについても制約は無い。なお、各サービスは、サービスの種別を識別するためのサービス識別子を持つ(同一サービスは同一サービス識別子を持つ)。
また、各ノード1のサービス用ネットワーク3に接続しているネットワークインタフェースは、それぞれ別個のMACアドレスを持つ(MAC-A〜MAC-Z)が、一方で、全て同一のIPアドレスを持つ(IP-A)。
図2は、ノード1の構成を表す図である。このノード1上では、サービス(0)からサービス(N−1)の合計N個のサービス20が動作している。
SSマップ21は、サーバ−サービスマップ(Server-Serviceマップ)の略で、どのノード(サーバ)1でどのサービス20が動作しているかの一覧を保持するテーブルである。各ノード1は、それぞれのノード1上で動作しているサービス20の情報を他ノード1と交換し、各々のSSマップ21を最新の状態に保つ。詳細を図3に示す。
CSマップ22は、クライアント−サービスマップ(Client-Serviceマップ)の略で、どのクライアント2がどのノード1上のどのサービス20にアクセスしているかの一覧を保持するテーブルである。このCSマップ22に関しても、SSマップ21と同様、ノード1間で情報を交換し、各々のCSマップ22の状態を最新の状態に保つ。詳細を図4に示す。
MACアドレステーブル23は、制御用ネットワーク4に接続されている全ノード1について、サービス用ネットワーク3に接続しているNICに付与されているMACアドレスの一覧を保持するテーブルである。このMACアドレステーブル23に関しても、SSマップ21、CSマップ22と同様、ノード1間で情報を交換し、各々のMACアドレステーブル23の状態を最新の状態に保つ。詳細を図5に示す。
次に、ノード1内のネットワーク関連プロトコルを説明する。本来は、下位層から上位層へ、ネットワークインタフェース11,18、イーサネット(登録商標)ドライバ12,17、イーサネット(登録商標)層14、TCP/IP層15というプロトコルスタックとなるのが一般的であるが、本発明では、クライアント2から各ノード1上のサービス20へのアクセスの送信先等を制御する仮想イーサネット(登録商標)層13が、イーサネット(登録商標)ドライバ12とイーサネット(登録商標)層14との間に位置する。以下、個々のプロトコル層について説明する。
イーサネット(登録商標)ドライバ12、および17は、サービス用ネットワーク3、制御用ネットワーク4に接続するネットワークインタフェースそれぞれに対して存在し、ネットワークインタフェースを制御して、実際のイーサネット(登録商標)フレームの送受信処理を行うソフトウェアである。本発明ではイーサネット(登録商標)ドライバには特別な機能は不要であり、一般的な機能を持つものとする。
イーサネット(登録商標)層14は、下位層からイーサネット(登録商標)フレームを受信、あるいは、下位層へイーサネット(登録商標)フレームを送信する等、イーサネット(登録商標)プロトコルの各種処理を行うプロトコル層である。本発明では、仮想イーサネット(登録商標)層13の上位層に位置する(本来であればイーサネット(登録商標)ドライバ12の上位に位置する)ことを除けば、イーサネット(登録商標)層14に特別な機能は不要であり、一般的な機能を持つものとする。
TCP/IP層15は、IP、TCP、UDP等のプロトコル処理を行うプロトコル層であって、本発明では、特別な機能は不要であり、一般的な機能を持つものとする。
そして、仮想イーサネット(登録商標)層13は、本発明において特徴的な処理部であり、イーサネット(登録商標)ドライバ12の上位、イーサネット(登録商標)層14の下位に位置する仮想的なイーサネット(登録商標)プロトコル層である。クライアント2または制御用ネットワーク4経由で他ノード1からサービス20へのアクセスを受信し、その後の動作を決定するための処理を行う。その際、SSマップ21、CSマップ22の情報を利用する。
まず、図6および図7のフローチャートを参照しながら、この仮想イーサネット(登録商標)層13の基本的な動作手順を説明する。なお、以後の説明において、”パケット”とは、ノード1上のサービス20を利用するためのクライアント2からのIPパケット(及びUDPまたはTCPのデータ)を格納したイーサネット(登録商標)フレームを指す。
図6は、仮想イーサネット(登録商標)層13で実行される制御情報の処理フローである。
自ノード1上で新たなサービス20が動作開始したら(ステップA1のYes)、その動作開始したサービス20のサービス識別子と自身のノード識別子との組をSSマップ21に登録する(ステップA2)。また、同サービス識別子およびノード識別子からSSマップ登録メッセージを作成し、制御用ネットワーク4にブロードキャスト(全ての他ノードへの送信)する(ステップA3)。
一方、自ノード1上で動作していたサービス20が終了した場合には(ステップA4のYes)、その動作終了したサービス20のサービス識別子と自身のノード識別子との組に一致するエントリをSSマップ21から削除する(ステップA5)。また、同サービス識別子およびノード識別子からSSマップ削除メッセージを作成し、制御用ネットワーク4にブロードキャストする(ステップA6)。
また、制御用ネットワーク4からイーサネット(登録商標)ドライバ17経由でSSマップ登録メッセージを受信すると(ステップA7のYes)、受け取ったSSマップ登録メッセージに含まれるノード識別子とサービス識別子との組に一致するエントリが自身のSSマップ21に存在するか調べ(ステップA8)、存在しなければ(ステップA8のNo)、それらの情報をSSマップ21に登録する(ステップA9)。既に存在すれば(ステップA8のYes)、ここでは特に何もしない。
一方、制御用ネットワーク4からイーサネット(登録商標)ドライバ12経由でSSマップ削除メッセージを受信すると(ステップA10のYes)、受け取ったSSマップ削除メッセージに含まれるノード識別子とサービス識別子との組に一致するエントリが自身のSSマップ21に存在するか調べ(ステップA11)、存在すれば(ステップA11のYes)、それらの情報をSSマップ21から削除する(ステップA12)。存在しなければ(ステップA11のNo)、ここでは特に何もしない。
さらに、制御用ネットワーク4からイーサネット(登録商標)ドライバ17経由でCSマップ登録メッセージを受け取ると(ステップA13のYes)、受け取ったCSマップ登録メッセージに含まれるクライアント情報、ノード識別子およびサービス識別子の組に一致するエントリが自身のCSマップ22に存在するか調べ(ステップA14)、存在しなければ(ステップA14のNo)、それらの情報をCSマップ22に登録する(ステップA15)。既に存在すれば(ステップA14のYes)、ここでは特に何もしない。
また、図7は、仮想イーサネット(登録商標)層13で実行されるクライアント2からのアクセス(パケット)の処理フローである。
パケットを受信すると、まず、パケットを送信したクライアント2が既知、即ち、CSマップ22に登録されたクライアント2かどうかを調べる(ステップB1)。もし、未知のクライアント2であれば(ステップB1のNo)、SSマップ21を参照し、以下の処理(ステップB2〜ステップB13)を行う。
クライアント2がアクセスしようとしているサービス20が自ノード1上のみで動作している場合(ステップB2のYes)、クライアント2からのパケットを上位層(イーサネット(登録商標)層14)に渡す(ステップB3)。即ち、自ノード1上で動作している該当サービス20へクライアント2からのアクセスを引き渡すことになる。そして、当該クライアント2、当該クライアント2がアクセスしようとしたノード識別子、サービス識別子の組からなる情報をCSマップ22に登録する(ステップB4)。この時、これらの情報からCSマップ登録メッセージを作成し、制御用ネットワーク4にブロードキャストする。
クライアント2がアクセスしようとしているサービス20が他ノード1上のみで動作している場合であって、かつ、ただ1つのノード1上で動作している場合(ステップB5のYes)、このクライアント2からのパケットをサービス20が動作しているノード1へ転送する(ステップB6)。即ち、クライアント2からのパケットの宛先MACアドレスを当該ノード1の制御用ネットワーク4に接続しているネットワークインタフェースのものに置き換え、制御用ネットワーク4側のイーサネット(登録商標)ドライバ17に渡す。また、当該クライアント2のMACアドレス、転送先ノード1のサービス用ネットワーク3側のネットワークインタフェース18のMACアドレスを格納し、“根拠の無いARP(GratuitousARP)”の送信要求をARP処理部19に対して発行する(ステップB7)。以後、当該クライアント2から他ノード1上のサービス20へのアクセスが、自ノード1を経由しないようにするための措置である。そして、その後、ステップB4の手順で、CSマップ22への登録を行う。
クライアント2がアクセスしようとしているサービス20が他ノード1上のみで動作している場合であって、かつ、複数のノード1上で動作している場合(ステップB8のYes)、CSマップ22を参照し、当該サービス20が動作しているノード1の内、クライアント2からのアクセスが最も少ないサービス20が動作しているノード1を選択し(ステップB9)、前述のステップB6〜ステップB7の手順で、当該クライアント2からのパケットを転送し、ステップB4の手順で、CSマップ22への登録を行う。なお、アクセス頻度が同じであれば、転送先ノード1はランダムに選択する。
クライアント2がアクセスしようとしているサービス20が自ノード1および他ノード1の両方で動作している場合(ステップB10のYes)、CSマップ22を参照し、当該サービス20が動作しているノードの内、クライアント2からのアクセスが最も少ないサービス20が動作しているノードを選択する(ステップB11)。そして、そのノード1が自ノード1でなければ(ステップB12のNo)、前述のステップB6〜ステップB7の手順で、当該クライアントからのパケットを転送する。一方、クライアント2からのアクセスが最も少ないサービス20が動作しているノード1が自ノード1であれば(ステップB12のYes)、前述のステップB3〜ステップB4の手順で、自ノード1上の上位層(イーサネット(登録商標)層14)に当該クライアント2からのパケットを渡すと共に、CSマップ22への登録を行う。なお、アクセス頻度が同じであれば自ノード1を選択する。
なお、ステップB2,B5,B8,B10のいずれの条件にも該当しない場合(ステップB10のNo)、そのサービス20はいずれにも存在しないので、クライアント2からのパケットを上位層(イーサネット(登録商標)層14)に渡し、TCP/IP15にエラー処理を実行させる(ステップB13)。
また、クライアント2が既知であった場合(ステップB1のYes)、CSマップを参照し、以下の処理(ステップB14〜ステップB18)を行う。
クライアント2が自ノード1上のサービス20にアクセスしようとしている場合(ステップB14のYes)、このクライアント2からのパケットを上位層(イーサネット(登録商標)層14)に渡す(ステップB15)。即ち、前述のステップB3と同様、自ノード1上で動作している該当サービスへクライアント2からのアクセスを引き渡すことになる。
一方、クライアント2が他ノード1上のサービスにアクセスしようとしている場合(ステップB14のNo)、CSマップ22からアクセス先のノード1を同定し(ステップB16)、当該アクセスをそのノード1へ転送する(ステップB17)。即ち、前述のステップB6と同様、クライアント2からのパケットの宛先MACアドレスを上記選択したノード1の制御用ネットワーク4に接続しているネットワークインタフェースのものに置き換え、制御用ネットワーク4側のイーサネット(登録商標)ドライバ17に渡す。また、前述のステップB7と同様、当該クライアント2のMACアドレス、転送先ノード1のサービス用ネットワーク3側のネットワークインタフェースのMACアドレスを格納し、“根拠の無いARP(GratuitousARP)”の送信要求をARP処理部19に対して発行する(ステップB18)。
以上のように動作する、イーサネット(登録商標)ドライバ12とイーサネット(登録商標)層14との間に介在して設けられる仮想イーサネット(登録商標)層13の働きにより、ノード1群の前段に負荷分散装置を設置すること無く、かつ、単一のIPアドレスのみの使用で、複数ノード1を論理的に単一のノード1に見せることが可能となる。
なお、ARP処理部19は、ARP要求の受信、ARP応答の送信および仮想イーサネット(登録商標)層13からの指示に基づき“根拠の無いARP(GratuitousARP)”の送信を行う部分であり、MACアドレステーブルを利用する。具体的には、以下の処理を行う。
未知のクライアント2、即ち、CSマップ22に登録されていないクライアント2からARP要求を受信すると、自身がマスタならば自身のMACアドレスを送信元MACアドレスフィールドに設定したARP応答をそのクライアント2へ送信する。一方、自身がスレーブならば何もしない。
一方、既知のクライアント2、即ち、CSマップ22に登録されているクライアント2からARP要求を受信すると、当該クライアント2が自ノード1上で動作しているサービス20にアクセスしているのであれば、自身のMACアドレスを送信元MACアドレスフィールドに設定したARP応答をそのクライアント2へ送信する。一方、そうでない場合は何もしない。
また、仮想イーサネット(登録商標)層13から“根拠の無いARP(GratuitousARP)”の送信要求を受け取ると、サービス用ネットワーク3に“根拠の無いARP(GratuitousARP)”を送信する。この時の宛先MACアドレスフィールドおよび送信元MACアドレスフィールドは、仮想イーサネット(登録商標)層13からの指示によるが、送信元MACアドレスフィールドは、クライアント2がアクセスしようとしたサービス20が動作しているノード1のMACアドレスであり、仮想イーサネット(登録商標)層13から受け取ったノード情報からMACアドレステーブル23を参照して取得する。一方、宛先MACアドレスフィールドは、当該ノード1上のサービス20にアクセスしようとしたクライアント2のMACアドレスである。
なお、以上のARP応答、“根拠の無いARP(GratuitousARP)”の送信元IPアドレスフィールドは、すべてノード1群が共有するIPアドレスである。
また、生存確認処理部16は、他ノード1との間の定期的な生存確認メッセージのやり取りを行う。あるノード1との生存確認が途切れた場合、SSマップ21、CSマップ22、MACアドレステーブル23の当該ノード1に関するエントリを全て破棄する。具体的には以下の処理を行う。
ノード1が起動した後、定期的な生存確認メッセージの送信を開始する。つまり、制御用ネットワーク4に生存確認メッセージをブロードキャストする。生存確認メッセージに自身のノード識別子と、サービス用ネットワーク3に接続しているネットワークインタフェースに付与されているMACアドレスとを含める。このようにすることで、他のノード1へ自身のMACアドレスを通知する。
一方、制御用ネットワーク4から生存確認メッセージを受信したら、この生存確認メッセージからノード識別子とMACアドレスを取り出し、これらのエントリがMACアドレステーブル23になければ登録し、既に登録されていれば何もしない。
そして、一定時間以上、あるノード1から生存確認メッセージを受信しなかったら、SSマップ21、CSマップ22、MACアドレステーブル23のそのノード1に関するエントリを全て削除する。
ここで、より具体的な例を挙げて、各クライアント2およびノード1間の相互作用、各種情報の流れを説明する。以下の説明で使用する構成の全体を図8に、その時点での各ノード1のSSマップ21、CSマップ22、MACアドレステーブル23の状態をそれぞれ図9(ノード(0)1の状態)および図10(ノード(1)1の状態)に示す。
図8に示す通り、ここでは、ノード1は2つで、MACアドレスとして、それぞれMAC-A、MAC-Bを持つ。一方、IPアドレスは、192.168.1.1で、2つのノード1はこれを共有している。また、ノード(0)1がマスタである。
また、図9、図10に示す通り、双方のノード1上でNFSサービス20、CIFSサービス20が、ノード(0)1上でHTTPサービス20が、ノード(1)1上でDNSサービス20が動作しており、更に、クライアント(0)2はノード(0)1上のサービス(0)20、即ち、NFSサービス20に、クライアント(1)2はノード(1)1上のサービス(1)20、即ち、CIFSサービス20にアクセスしている状態である。一方、クライアント(2)2、クライアント(3)2は何れのノード1上のサービス20にもアクセスしていない状態である。なお、各サービスの概要は以下の通りである。
(a)NFSサービス(サービス識別子=0)
NFS(Network File System)を提供するサーバプログラム。
(b)CIFSサービス(サービス識別子=1)
CIFS(Common Internet File System)を提供するサーバプログラム。
(c)HTTPサービス(サービス識別子=2)
HTTP(Hyper Text Transfer Protocol)サービスを提供するプログラム。
(d)DNSサービス(サービス識別子=3)
DNS(Domain Name service)サービスを提供するプログラム。
次に、クライアント2からのアクセスに応じたノード(0)1およびノード(1)1の動作手順と生存確認処理部16関連の動作手順とをケース別に説明する。なお、ノード1内の各機能の処理については既述の通りであるので、ここでは詳述しない。
(1)既知のクライアント2からARP要求を受信した場合
クライアント(0)2が192.168.1.1に対するARP要求をサービス用ネットワーク3へブロードキャストした場合、ノード(0)1、ノード(1)1はそれぞれ以下の処理を行う。
(a)ノード(0)1
CSマップ22を参照し、クライアント(0)2が自ノード1上のサービス(0)20にアクセスしていることから、送信元MACアドレスフィールドを自ノードのMACアドレスMAC-Aに、宛先MACアドレスフィールドをクライアント(0)2のMACアドレスに設定し、ARP応答を送信する。
(b)ノード(1)1
CSマップ22を参照し、クライアント(0)が自ノード1上のサービス20にはアクセスしていないことから、何もしない。
(2)未知のクライアント2からARP要求を受信した場合
クライアント(2)2が192.168.1.1に対するARP要求をサービス用ネットワーク3へブロードキャストした場合、ノード(0)1、ノード(1)1はそれぞれ以下の処理を行う。
(a)ノード(0)1
ノード(0)1はマスタなので、送信元MACアドレスフィールドを自ノード1のMACアドレスMAC-Aに、宛先MACアドレスフィールドをクライアント(2)2のMACアドレスに設定し、ARP応答を送信する。
(b)ノード(1)1
ノード(1)はスレーブなので、未知の(CSマップ22に登録されていない)クライアント(2)2からのARP要求を受信しても何もしない。
(3)既知のクライアント2から自ノード1上のサービス20へのパケットを受信した場合
クライアント(0)2のARPテーブル(各クライアント2がARP処理を行うために備えるテーブル)にて、192.168.1.1に対するMACアドレスとしてMAC-Aのエントリがある状態で、クライアント(0)2がサービス(0:NFSサービス)20にアクセスした場合、ノード(0)1がクライアント(0)2からのパケットを受信する。
ノード(0)1はCSマップ22を参照し、クライアント(0)2が自ノード1上のサービス(0)20にアクセス中であることを確認し、当該パケットを自ノード1上のサービス(0)20に送信する。つまり、ノード(0)1がクライアント(0)2に対してサービス(0)20のサービスを提供することとなる。
(4)既知のクライアント2から他ノード1上のサービス20へのパケットを受信した場合
クライアント1のARPテーブルにて、192.168.1.1に対するMACアドレスとしてMAC-Aのエントリがある状態で、クライアント(1)2がサービス(1:CIFSサービス)20にアクセスした場合、ノード(0)1がクライアント(1)2からのパケットを受信する。
ノード(0)1はCSマップ22を参照し、クライアント(1)2がノード(1)1上のサービス(1)20にアクセス中であることを確認し、制御用ネットワーク4経由で当該パケットをノード1に転送する。
また、MACアドレステーブル23からノード(1)1のMACアドレスを読み出し、送信元MACアドレスフィールドをノード(1)1のMACアドレスに、宛先MACアドレスフィールドをクライアント(1)2のMACアドレスに設定し、“根拠の無いARP(GratuitousARP)”を送信する。
このように“根拠の無いARP(GratuitousARP)”を送信することで、次回のクライアント(1)2からの192.168.1.1のサービス(1)20へのパケットはノード(1)1で受信されるはずである。一方、ノード(0)1から、クライアント(1)2からのパケットを転送されたノード(1)1は、そのパケットを自ノード1上のサービス(1)20に送信する。つまり、ノード(1)1がクライアント(1)2に対してサービス(1)20のサービスを提供することとなる。
なお、サービス(1)20からのクライアント(1)2への折り返しのパケットは、ノード(1)1から直接クライアント(1)2に送信し、ノード(0)1への転送は行わない。
(5)未知のクライアント2から自ノード1上のみにあるサービス20へのパケットを受信した場合
クライアント(2)2のARPテーブルにて、192.168.1.1に対するMACアドレスとしてMAC-Aのエントリがある状態で、クライアント(2)2がサービス(2:HTTPサービス)20にアクセスした場合、ノード(0)1がクライアント(2)2からのパケットを受信する。
ノード(0)1は、CSマップ22を参照し、クライアント(2)2は何れのノード1上のサービス20にもアクセス中ではないことを確認する。次に、ノード(0)1は、SSマップ21を参照し、自ノード1上でサービス(2)20が動作していることを確認すると、クライアント(2)2からのパケットをサービス(2)20へ送信する。つまり、ノード(0)1がクライアント(2)2に対してサービス(2)20のサービスを提供することとなる。また、クライアント(2)2、自ノード1のノード識別子、サービス識別子(2)のエントリを自ノード1のCSマップ22に登録すると共に、これらの情報をCSマップ登録メッセージに格納し、制御用ネットワーク4経由で他ノード1に送信する。
制御用ネットワーク4経由でCSマップ登録メッセージを受け取った他ノード1(ここではノード(1)1)は、CSマップ登録メッセージからクライアント、ノード識別子、サービス識別子の情報を取り出し、これらのエントリが自ノード1上のCSマップ22に登録されていなければ登録し、既に登録されていれば登録を行わない。
以上の処理が完了した後のノード(0)1、ノード(1)1双方のCSマップ22は、図11のようになる。
(6)未知のクライアント2から他ノード1上のみにあるサービス20へのパケットを受信した場合
クライアント(3)2のARPテーブルにて、192.168.1.1に対するMACアドレスとしてMAC-Aのエントリがある状態で、クライアント(3)2がサービス(3:DNSサービス)20にアクセスした場合、ノード(0)1がクライアント(3)2からのパケットを受信する。
ノード(0)1は、CSマップ22を参照し、クライアント(3)2は何れのノード1上のサービス20にもアクセス中ではないことを確認する。次に、ノード(0)1は、SSマップ21を参照し、ノード(1)1上でサービス(3)20が動作していることを確認すると、クライアント(3)2からのパケットを制御用ネットワーク4経由でノード(1)1へ転送する。
また、MACアドレステーブルからノード(1)1のMACアドレスを読み出し、送信元MACアドレスフィールドをノード(1)1のMACアドレスに、宛先MACアドレスフィールドをクライアント(3)2のMACアドレスに設定し、“根拠の無いARP(GratuitousARP)”を送信する。
このように“根拠の無いARP(GratuitousARP)”を送信することで、次回のクライアント(3)2からの192.168.1.1のサービス(3)20へのパケットはノード(1)1で受信されるはずである。一方、ノード(0)1から、クライアント(3)2からのパケットを転送されたノード(1)1は、そのパケットを自ノード1上のサービス(3)20に送信する。つまり、ノード(1)1がクライアント(3)2に対してサービス(3)20のサービスを提供することとなる。
なお、サービス(3)20からのクライアント(3)2への折り返しのパケットは、ノード(1)1から直接クライアント(3)2に送信し、ノード(0)1への転送は行わない。更に、ノード(1)1は、クライアント(3)2、自ノード1のノード識別子、サービス識別子(3)のエントリを自ノード1のCSマップ22に登録すると共に、これらの情報をCSマップ登録メッセージに格納し、制御用ネットワーク4経由で他ノード1に送信する。
制御用ネットワーク4経由でCSマップ登録メッセージを受け取った他ノード1(ここではノード(0)1)は、CSマップ登録メッセージからクライアント、ノード識別子、サービス識別子の情報を取り出し、これらのエントリが自ノード1上のCSマップ22に登録されていなければ登録し、既に登録されていれば登録を行わない。
以上の処理が完了した後のノード(0)1、ノード(1)1双方のCSマップ22は、図12のようになる。
(7)未知のクライアント2から自ノード1および他ノード1上にあるサービス20へのパケットを受信した場合であって、かつ、自ノード1上のサービス20へは他のクライアント2がアクセス中である場合
クライアント(4)2のARPテーブルにて、192.168.1.1に対するMACアドレスとしてMAC-Aのエントリがある状態で、クライアント(4)2がサービス(0:NFSサービス)20にアクセスした場合、ノード(0)1がクライアント(4)2からのパケットを受信する。
ノード(0)1は、CSマップ22を参照し、クライアント(4)2は何れのノード1上のサービス20にもアクセス中ではないことを確認する。次に、ノード(0)1は、SSマップ21を参照し、ノード(0)1、ノード(1)1双方でサービス(0)20が動作していることを確認する。更に、ノード(0)1は、CSマップ22を参照し、ノード(0:自ノード)1上のサービス(0)20には既に他のクライアント2(クライアント(0)2)がアクセスしており、一方、ノード(1)1上のサービス(0)20にはクライアント2からのアクセスが無いことを確認する。その結果、ノード(1)1上のサービス(0)20の方がクライアント2からのアクセスが少ないので、クライアント(4)20からのパケットを制御用ネットワーク4経由でノード(1)1へ転送する。
また、MACアドレステーブルからノード(1)1のMACアドレスを読み出し、送信元MACアドレスフィールドをノード(1)のMACアドレスに、宛先MACアドレスフィールドをクライアント(4)2のMACアドレスに設定し、“根拠の無いARP(GratuitousARP)”を送信する。
このように“根拠の無いARP(GratuitousARP)”を送信することで、次回のクライアント(4)2からの192.168.1.1のサービス(0)20へのパケットはノード(1)1で受信されるはずである。一方、ノード(0)1から、クライアント(4)2からのパケットを転送されたノード(1)1は、そのパケットを自ノード1上のサービス(0)20に送信する。つまり、ノード(1)1がクライアント(4)2に対してサービス(0)20のサービスを提供することとなる。
なお、サービス(0)20からのクライアント(4)2への折り返しのパケットは、ノード(1)1から直接クライアント(4)2に送信し、ノード(0)1への転送は行わない。更に、ノード(1)1は、クライアント(4)2、自ノード1のノード識別子、サービス識別子(0)のエントリを自ノード1のCSマップ22に登録すると共に、これらの情報をCSマップ登録メッセージに格納し、制御用ネットワーク4経由で他ノード1に送信する。
制御用ネットワーク4経由でCSマップ登録メッセージを受け取った他ノード1(ここではノード(0)1)は、CSマップ登録メッセージからクライアント、ノード識別子、サービス識別子の情報を取り出し、これらのエントリが自ノード1上のCSマップ22に登録されていなければ登録し、既に登録されていれば登録を行わない。
以上の処理が完了した後のノード(0)1、ノード(1)1双方のCSマップ22は、図13のようになる。
なお、クライアント2からのアクセスを自ノード1のサービス20に送信するか、制御用ネットワーク4経由で他ノード1に転送するかを決定するアルゴリズムとして、上記では、アクセスを受けたサービス20へ既にアクセスしているクライアント2の数を判断基準にしたものを用いているが、他のアルゴリズムも使用可能であり、例えば、単純にラウンドロビンで転送先ノードを決めたり、上記のようなサービス単位のクライアント2からのアクセス数ではなく、ノード1単位のクライアント2からのアクセス数を元に判断することも可能である。
(8)未知のクライアント2から自ノード1および他ノード1上にあるサービス20へのパケットを受信した場合であって、かつ、他ノード1上のサービス20へは他のクライアント2がアクセス中である場合
クライアント(5)2のARPテーブルにて、192.168.1.1に対するMACアドレスとしてMAC-Aのエントリがある状態で、クライアント(5)2がサービス(1:CIFSサービス)20にアクセスした場合、ノード(0)1がクライアント(5)2からのパケットを受信する。
ノード(0)1は、CSマップ22を参照し、クライアント(5)2は何れのノード1上のサービス20にもアクセス中ではないことを確認する。次に、ノード(0)1は、SSマップ21を参照し、ノード(0)1、ノード(1)1双方でサービス(1)20が動作していることを確認する。更に、ノード(0)1は、CSマップ22を参照し、ノード(1:他ノード)1上のサービス(1)20には既に他のクライアント2(クライアント(1)2)がアクセスしており、一方、自ノード1上のサービス(1)20にはクライアント2からのアクセスが無いことを確認する。その結果、自ノード1上のサービス(1)20の方がクライアント2からのアクセスが少ないので、クライアント(5)2からのパケットを自ノード1のサービス(1)20へ送信する。つまり、ノード(0)1がクライアント(5)2に対してサービス(1)20のサービスを提供することとなる。
また、クライアント(5)2、自ノード1のノード識別子、サービス識別子1のエントリを自ノード1のCSマップ22に登録すると共に、これらの情報をCSマップ登録メッセージに格納し、制御用ネットワーク4経由で他ノード1に送信する。
制御用ネットワーク4経由でCSマップ登録メッセージを受け取った他ノード1(ここではノード(1)1)は、CSマップ登録メッセージからクライアント、ノード識別子、サービス識別子の情報を取り出し、これらのエントリが自ノード1上のCSマップ22に登録されていなければ登録し、既に登録されていれば登録を行わない。
以上の処理が完了した後のノード(0)1、ノード(1)1双方のCSマップ22は、図14のようになる。
(9)ノード1がダウンした場合
ノード(0)1は、ノード(1)1からの生存確認メッセージを一定時間以上受信しないため、自身のSSマップ21、CSマップ22、MACアドレステーブル23からノード(1)に関するエントリを全て削除する。
以上の処理が完了した後のノード(0)1のSSマップ21、CSマップ22、MACアドレステーブル23は、図15のようになる。
なお、ノード(1)1ダウン後も、このノード(1)1上のみで動作していたサービス(3)20以外のサービス20については、ノード(0)1にて引き継いでクライアント2に提供することが可能である。
このように、本サーバシステムでは、各ノード(サーバ)1が協働して、クライアント2に対するサービス20の提供を負荷分散し、ノード1群の前段に負荷分散装置を設置すること無く、かつ、単一のIPアドレスのみの使用で、複数ノード1を論理的に単一のノード1に見せることを可能とする。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
本発明の一実施形態に係るサーバシステムの全体構成を示す図 同実施形態のサーバシステムのノード(サーバ)の構成を表す図 同実施形態のサーバシステムのノードが備えるSS(サーバ−サービス)マップの構成を示す図 同実施形態のサーバシステムのノードが備えるCS(クライアント−サービス)マップの構成を示す図 同実施形態のサーバシステムのノードが備えるMACアドレステーブルの構成を示す図 同実施形態のサーバシステムのノードの仮想イーサネット(登録商標)層で実行される制御情報の処理フロー 同実施形態のサーバシステムのノードの仮想イーサネット(登録商標)層で実行されるクライアントからのアクセス(パケット)の処理フロー 同実施形態のサーバシステムにおける各クライアントおよびノード間の相互作用、各種情報の流れを説明するための全体構成図 図8のサーバシステムにおけるノード(0)のSSマップ、CSマップ、MACアドレステーブルの状態を示す図 図9のサーバシステムにおけるノード(1)のSSマップ、CSマップ、MACアドレステーブルの状態を示す図 ノード(0)が未知のクライアント(2)から自ノード(0)上のみにあるサービス(2)へのパケットを受信した場合の処理後のノード(0)、ノード(1)のCSマップの状態を示す図 ノード(0)が未知のクライアント(3)から他ノード(1)上のみにあるサービス(3)へのパケットを受信した場合の処理後のノード(0)、ノード(1)のCSマップの状態を示す図 ノード(0)が未知のクライアント(4)から自ノード(0)および他ノード(1)上にあるサービス(4)へのパケットを受信した場合であって、かつ、自ノード(0)上のサービス(4)へは他のクライアント(0)がアクセス中である場合の処理後のノード(0)、ノード(1)のCSマップの状態を示す図 ノード(0)が未知のクライアント(5)から自ノード(0)および他ノード(1)上にあるサービス(1)へのパケットを受信した場合であって、かつ、他ノード(1)上のサービス(1)へは他のクライアント(1)がアクセス中である場合の処理後のノード(0)、ノード(1)のCSマップの状態を示す図 ノード(1)がダウンした場合におけるノード(0)のSSマップ、CSマップ、MACアドレステーブルの状態を示す図
符号の説明
1…ノード、2…クライアント、3…サービス用ネットワーク、4…制御用ネットワーク、11…ネットワークインタフェース、12…イーサネット(登録商標)ドライバ、13…仮想イーサネット(登録商標)層、14…イーサネット(登録商標)層、15…TCP/IP、16…生存確認処理部、17…イーサネット(登録商標)ドライバ、18…ネットワークインタフェース、19…ARP処理部、20…サービス、21…SSマップ、22…CSマップ、23…MACアドレステーブル。

Claims (16)

  1. 単一のIPアドレスを共有する他のサーバ装置と協働してクライアント装置に対するサービスの提供を行うサーバ装置であって、
    前記クライアント装置からのパケットを前記他のサーバ装置に転送するパケット転送手段と、
    前記パケット転送手段によるパケットの転送が行われた場合に、前記他のサーバ装置のMACアドレスを送信元MACアドレスとするGratuitousARP(Address Resolution Protocol)を前記クライアント装置に送信するARP処理手段と
    を具備することを特徴とするサーバ装置。
  2. 前記IPアドレスを共有するすべてのサーバ装置とそのサーバ装置が提供するサービスとの対応づけを示すマッピング情報を管理するSSマップ管理手段を具備し、
    前記パケット転送手段は、前記クライアント装置が要求するサービスを提供するサーバ装置を前記SSマップ管理手段で管理されるマッピング情報から取得し、そのサーバ装置にパケットを転送することを特徴とする請求項1記載のサーバ装置。
  3. サービスの提供を受けているクライアント装置とそのクライアント装置にサービスを提供するサーバ装置との対応づけを示すマッピング情報を管理するCSマップ管理手段を具備し、
    前記パケット転送手段は、サービスを提供するクライアント装置の総数が最も少ないサーバ装置を前記CSマップ管理手段で管理されるマッピング情報から取得し、そのサーバ装置にパケットを転送することを特徴とする請求項1記載のサーバ装置。
  4. 前記IPアドレスを共有するすべてのサーバ装置とそのサーバ装置が提供するサービスとの対応づけを示すマッピング情報を管理するSSマップ管理手段と、
    サービスの提供を受けているクライアント装置とそのクライアント装置にサービスを提供するサーバ装置との対応づけを示すマッピング情報を管理するCSマップ管理手段と
    を具備し、
    前記パケット転送手段は、前記クライアント装置が要求するサービスを提供するサーバ装置のうち、サービスを提供するクライアント装置の総数が最も少ないサーバ装置を前記SSマップ管理手段で管理されるマッピング情報と前記CSマップ管理手段で管理されるマッピング情報とから取得し、そのサーバ装置にパケットを転送することを特徴とする請求項1記載のサーバ装置。
  5. 他のサーバ装置との間で生存確認メッセージを送受信する生存確認手段を具備し、
    前記SSマップ管理手段は、前記生存確認手段による前記生存確認メッセージの受信が一定期間以上無い他のサーバ装置に関するマッピング情報を削除することを特徴とする請求項2または4記載のサーバ装置。
  6. 他のサーバ装置との間で生存確認メッセージを送受信する生存確認手段を具備し、
    前記CSマップ管理手段は、前記生存確認手段による前記生存確認メッセージの受信が一定期間以上無い他のサーバ装置に関するマッピング情報を削除することを特徴とする請求項3または4記載のサーバ装置。
  7. 前記生存確認手段による前記生存確認メッセージの受信が一定期間以上無い他のサーバ装置が提供していたサービスの提供を引き継ぐサービス引継手段を具備することを特徴とする請求項5または6記載のサーバ装置。
  8. 前記パケット転送手段は、前記パケットを転送する他のサーバ装置をラウンドロビンアルゴリズムを用いて選択することを特徴とする請求項1記載のサーバ装置。
  9. 前記パケット転送手段は、前記パケットを転送する他のサーバ装置をランダムに選択することを特徴とする請求項1記載のサーバ装置。
  10. 他のサーバ装置との間で各サーバ装置の状態を示すパラメータを送受信するパラメータ送受信手段を具備し、
    前記パケット転送手段は、前記パラメータにより示される各サーバ装置の状態により前記パケットを転送する他のサーバ装置を選択することを特徴とする請求項1記載のサーバ装置。
  11. 前記パラメータは、各サーバ装置のCPU負荷を含み、
    前記パケット転送手段は、前記パラメータにより示されるCPU負荷が最も小さいサーバ装置にパケットを転送することを特徴とする請求項10記載のサーバ装置。
  12. 前記パラメータは、各サーバ装置の記憶媒体に対する入出力負荷を含み、
    前記パケット転送手段は、前記パラメータにより示される入出力負荷が最も小さいサーバ装置にパケットを転送することを特徴とする請求項10記載のサーバ装置。
  13. マスタおよびスレーブのうちマスタとして動作する場合、前記ARP処理手段は、未知のクライアント装置からのARP要求に対して、自サーバ装置のMACアドレスを送信元MACアドレスとするARP応答を返送することを特徴とする請求項1、2、3、4、5、6、7、8、9、10、11または12記載のサーバ装置。
  14. 単一のIPアドレスを共有する、請求項1乃至13のいずれかに記載の複数のサーバ装置と、
    前記複数のサーバ装置間を接続するための第1のネットワークと、
    サービスの提供を受けるクライアント装置と前記複数のサーバ装置との間を接続するための第2のネットワークと
    を具備することを特徴とするサーバシステム。
  15. 単一のIPアドレスを共有する、請求項1乃至13のいずれかに記載の複数のサーバ装置と、
    前記複数のサーバ装置間を接続すると共に、サービスの提供を受けるクライアント装置と前記複数のサーバ装置との間を接続するためのネットワークと
    を具備することを特徴とするサーバシステム。
  16. 単一のIPアドレスを共有する複数のサーバ装置でクライアント装置に対するサービスの提供を行うサーバシステムの負荷分散方法であって、
    前記複数のサーバ装置それぞれが、
    前記クライアント装置からのパケットを他のサーバ装置に転送するステップと、
    前記パケットの転送を行った場合に、前記他のサーバ装置のMACアドレスを送信元MACアドレスとするGratuitousARPを前記クライアント装置に送信するステップと
    を具備することを特徴とする負荷分散方法。
JP2005072990A 2005-03-15 2005-03-15 サーバ装置、サーバシステムおよびサーバシステムの負荷分散方法 Expired - Fee Related JP3930516B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005072990A JP3930516B2 (ja) 2005-03-15 2005-03-15 サーバ装置、サーバシステムおよびサーバシステムの負荷分散方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005072990A JP3930516B2 (ja) 2005-03-15 2005-03-15 サーバ装置、サーバシステムおよびサーバシステムの負荷分散方法

Publications (2)

Publication Number Publication Date
JP2006259845A true JP2006259845A (ja) 2006-09-28
JP3930516B2 JP3930516B2 (ja) 2007-06-13

Family

ID=37099073

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005072990A Expired - Fee Related JP3930516B2 (ja) 2005-03-15 2005-03-15 サーバ装置、サーバシステムおよびサーバシステムの負荷分散方法

Country Status (1)

Country Link
JP (1) JP3930516B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008219530A (ja) * 2007-03-06 2008-09-18 Kddi Corp 仮想閉域網にユーザ経路広告を転送するシステム及びプログラム
JP2009130528A (ja) * 2007-11-21 2009-06-11 Toshiba Corp ネットワーク仮想化システム、中継装置、およびプログラム
WO2010064644A1 (ja) * 2008-12-03 2010-06-10 日本電気株式会社 クラスタ制御システム、クラスタ制御方法、及びプログラム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5903934B2 (ja) * 2012-03-01 2016-04-13 日本電気株式会社 情報処理システム、サーバシステム、コントローラ、情報処理方法及びプログラム

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008219530A (ja) * 2007-03-06 2008-09-18 Kddi Corp 仮想閉域網にユーザ経路広告を転送するシステム及びプログラム
JP2009130528A (ja) * 2007-11-21 2009-06-11 Toshiba Corp ネットワーク仮想化システム、中継装置、およびプログラム
JP4498406B2 (ja) * 2007-11-21 2010-07-07 株式会社東芝 ネットワーク仮想化システム、中継装置、およびプログラム
WO2010064644A1 (ja) * 2008-12-03 2010-06-10 日本電気株式会社 クラスタ制御システム、クラスタ制御方法、及びプログラム
JP5381998B2 (ja) * 2008-12-03 2014-01-08 日本電気株式会社 クラスタ制御システム、クラスタ制御方法、及びプログラム
US8782160B2 (en) 2008-12-03 2014-07-15 Nec Corporation Cluster control system, cluster control method, and program

Also Published As

Publication number Publication date
JP3930516B2 (ja) 2007-06-13

Similar Documents

Publication Publication Date Title
US6345294B1 (en) Methods and apparatus for remote configuration of an appliance on a network
TWI384812B (zh) 運用暫存管理與資料傳輸負載平衡之點對點代理服務裝置與方法
US8527635B2 (en) Contents delivery system and method, web server and contents provider DNS server thereof
US7899047B2 (en) Virtual network with adaptive dispatcher
EP1303096B1 (en) Virtual network with adaptive dispatcher
JP2004533687A (ja) コンピュータ・ネットワークにおけるサービスの動的配備
US7836142B2 (en) System and method for updating a dynamic domain name server
US20120191769A1 (en) Site-aware distributed file system access from outside enterprise network
CN113364741A (zh) 一种应用访问方法及代理服务器
JP5620881B2 (ja) トランザクション処理システム、トランザクション処理方法、および、トランザクション処理プログラム
US8099506B2 (en) Communication system, node device, node process program and a message transmitting and receiving method
EP2656591B1 (en) DNS proxy service for multi-core platforms
US7965630B1 (en) Load balancing port proxy for dynamically controlling routing of query requests
JP3930516B2 (ja) サーバ装置、サーバシステムおよびサーバシステムの負荷分散方法
US20160226963A1 (en) Load balancing using predictable state partitioning
CN115242882B (zh) 一种基于传输层路由访问k8s容器环境的方法及装置
JP2008065611A (ja) ソフトウェア更新方式及びソフトウェア更新プログラム
JP4223045B2 (ja) Dnsサーバ装置、要求電文処理方法および要求電文処理プログラム
KR20110063083A (ko) 해시를 이용한 게시-구독 네트워크 구성 방법 및 통신 지원 방법
KR20050003598A (ko) 이중화된 도메인 네임 서버를 이용한 도메인 네임 서비스제공 시스템 및 제공 방법
JP2008206081A (ja) マルチホーミング通信システムに用いられるデータ中継装置およびデータ中継方法
JP4202534B2 (ja) Webデータのキャッシュ更新方法およびキャッシュ更新システム
US20040172560A1 (en) Stream server apparatus, program, and NAS device
WO2022206667A1 (zh) 一种路由方法及设备
JP6665620B2 (ja) サーバ装置、端末装置、クライアントサーバシステム、通知方法、および情報取得方法、並びにコンピュータ・プログラム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061212

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070202

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070306

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070308

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100316

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110316

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120316

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130316

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140316

Year of fee payment: 7

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees