(57)【要約】【課題】  ロードバランサを不要とする低遅延な負荷分散システムを提供することにある。【解決手段】  複数のサーバとネットワークスイッチを有する負荷分散システムであって、前記ネットワークスイッチは、ネットワークからフレームを受信し、前記ネットワークから受信されたフレームを前記複数のサーバへフラッディングにより転送し、前記複数のサーバのそれぞれは、前記ネットワークスイッチからフレームを受信し、前記ネットワークスイッチから受信されたフレームに含まれるフレームの送信元の情報に基づき受け付けて、処理する。【選択図】  図１
2017182138.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバとネットワークスイッチを有する負荷分散システムであって、
前記ネットワークスイッチは、
ネットワークからフレームを受信し、前記ネットワークから受信されたフレームを前記複数のサーバへフラッディングにより転送し、
前記複数のサーバのそれぞれは、
前記ネットワークスイッチからフレームを受信し、前記ネットワークスイッチから受信されたフレームに含まれるフレームの送信元の情報に基づき受け付けて、処理すること
を特徴とする負荷分散システム。
【請求項２】
請求項１に記載の負荷分散システムであって、
前記負荷分散システムは、
アドレス変換部をさらに有し、
前記アドレス変換部は、
前記ネットワークスイッチからフレームを受信し、受信されたフレームに含まれる送信元ＩＰアドレスを維持し、送信元ＭＡＣアドレスを変換したフレームを前記ネットワークへ送信すること
を特徴とする負荷分散システム。
【請求項３】
請求項２に記載の負荷分散システムであって、
前記アドレス変換部は、
送信元ＭＡＣアドレスを前記複数のサーバのＭＡＣアドレスとは異なるＭＡＣアドレスへ変換すること
を特徴とする負荷分散システム。
【請求項４】
請求項３に記載の負荷分散システムであって、
前記ネットワークスイッチは、
前記ネットワークから受信されたフレームに含まれる宛先ＭＡＣアドレスが前記複数のサーバのＭＡＣアドレスではないと、前記複数のサーバへフラッディングにより転送すること
を特徴とする負荷分散システム。
【請求項５】
請求項１に記載の負荷分散システムであって、
前記負荷分散システムは、
アドレス変換部をさらに有し、
前記アドレス変換部は、
前記ネットワークからフレームを受信し、受信されたフレームに含まれる宛先ＩＰアドレスを維持し、宛先ＭＡＣアドレスを変換したフレームを前記ネットワークスイッチへ送信し、
前記ネットワークスイッチは、
前記アドレス変換部からからフレームを受信し、前記アドレス変換部から受信されたフレームを前記複数のサーバへフラッディングにより転送すること
を特徴とする負荷分散システム。
【請求項６】
請求項５に記載の負荷分散システムであって、
前記アドレス変換部は、
宛先ＭＡＣアドレスを前記複数のサーバのＭＡＣアドレスとは異なるＭＡＣアドレスへ変換すること
を特徴とする負荷分散システム。
【請求項７】
請求項６に記載の負荷分散システムであって、
前記ネットワークスイッチは、
前記アドレス変換部から受信されたフレームに含まれる宛先ＭＡＣアドレスが前記複数のサーバのＭＡＣアドレスではないと、前記複数のサーバへフラッディングにより転送すること
を特徴とする負荷分散システム。
【請求項８】
請求項１に記載の負荷分散システムであって、
前記負荷分散システムは、
ルータをさらに有し、
前記ルータは、
前記ネットワークからフレームを受信し、受信されたフレームに含まれる宛先ＩＰアドレスを維持し、宛先ＭＡＣアドレスを前記複数のサーバのＭＡＣアドレスとは異なるＭＡＣアドレスへ変換したフレームを前記ネットワークスイッチへ送信し、
前記ネットワークスイッチは、
前記ネットワークから受信されたフレームに含まれる宛先ＭＡＣアドレスが前記複数のサーバのＭＡＣアドレスではないと、前記複数のサーバへフラッディングにより転送すること
を特徴とする負荷分散システム。
【請求項９】
請求項１に記載の負荷分散システムであって、
前記ネットワークスイッチは、
前記ネットワークから受信されたフレームのヘッダに含まれる情報を条件とした転送の動作が設定されており、前記ネットワークから受信されたフレームのヘッダに含まれる宛先ＩＰアドレスに基づいて、前記複数のサーバへフラッディングにより転送すること
を特徴とする負荷分散システム。
【請求項１０】
請求項１に記載の負荷分散システムであって、
前記負荷分散システムは、
動作が設定されたスイッチをさらに有し、
前記動作が設定されたスイッチは、
前記ネットワークから受信されたフレームのヘッダに含まれる情報を条件としたフレームに対する動作が設定されており、前記ネットワークから受信されたフレームのヘッダに含まれる宛先ＩＰアドレスに基づいて、宛先ＭＡＣアドレスを変更したフレームを前記ネットワークスイッチへ送信し、
前記ネットワークスイッチは、
前記動作が設定されたスイッチから受信されたフレームに含まれる宛先ＭＡＣアドレスが前記複数のサーバのＭＡＣアドレスではないと、前記複数のサーバへフラッディングにより転送すること
を特徴とする負荷分散システム。
【請求項１１】
請求項１から１０のいずれか一項に記載の負荷分散システムであって、
前記複数のサーバのそれぞれは、
前記ネットワークスイッチから受信されたフレームに含まれる送信元ＩＰアドレスを被除数とした剰余算の結果に基づき受け付けて、処理すること
を特徴とする負荷分散システム。
【請求項１２】
請求項１から１０のいずれか一項に記載の負荷分散システムであって、
前記複数のサーバのそれぞれは、独自のサーバ番号を有し、
前記複数のサーバの中の第１のサーバは、
前記ネットワークスイッチから受信されたフレームに含まれる送信元ＩＰアドレスを被除数とした剰余算の結果が、前記第１のサーバのサーバ番号であると判定すると、前記ネットワークスイッチから受信されたフレームを受け付けて処理し、それ以外の結果であると判定すると、前記ネットワークスイッチから受信されたフレームを廃棄すること
を特徴とする負荷分散システム。
【請求項１３】
請求項１から１０のいずれか一項に記載の負荷分散システムであって、
前記複数のサーバのそれぞれは、
前記ネットワークスイッチから受信されたフレームに含まれる送信元ポート番号を被除数とした剰余算の結果に基づき受け付けて、処理すること
を特徴とする負荷分散システム。
【請求項１４】
請求項１から１０のいずれか一項に記載の負荷分散システムであって、
前記複数のサーバのそれぞれは、独自のサーバ番号を有し、
前記複数のサーバの中の第１のサーバは、動作しておらず、
前記複数のサーバの中の第２のサーバは、
前記ネットワークスイッチから受信されたフレームに含まれる送信元ポート番号を被除数とした剰余算の結果が、前記第２のサーバのサーバ番号あるいは前記第１のサーバのサーバ番号であると判定すると、前記ネットワークスイッチから受信されたフレームを受け付けて処理し、それ以外の結果であると判定すると、前記ネットワークスイッチから受信されたフレームを廃棄すること
を特徴とする負荷分散システム。
【請求項１５】
複数のサーバとネットワークスイッチと複数のアドレス変換部を有する負荷分散システムであって、
前記複数のアドレス変換部のそれぞれは、
前記ネットワークスイッチからフレームを受信し、受信されたフレームに含まれる送信元ＩＰアドレスを維持し、送信元ＭＡＣアドレスを前記複数のサーバのＭＡＣアドレスとは異なるＭＡＣアドレスへ変換したフレームを前記ネットワークへ送信し、
前記ネットワークスイッチは、
ネットワークからフレームを受信し、前記ネットワークから受信されたフレームに含まれる宛先ＭＡＣアドレスが前記複数のサーバのＭＡＣアドレスではないと、前記複数のサーバへフラッディングにより転送し、
前記複数のサーバのそれぞれは、
前記ネットワークスイッチからフレームを受信し、前記ネットワークスイッチから受信されたフレームに含まれる送信元ＩＰアドレスを被除数とした剰余算の結果、あるいは宛先ポート番号に基づき受け付けて、処理すること
を特徴とする負荷分散システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、負荷分散システムに関する。
【背景技術】
【０００２】
無線通信技術やネットワーク技術の発展に伴い、ネットワークを介して提供されるサービスは多様化が進んでおり、また近年ではデバイスが自律的にネットワークを介して通信を行うＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）、Ｍ２Ｍ（Ｍａｃｈｉｎｅ  ｔｏ  Ｍａｃｈｉｎｅ）のようなサービスの普及も見込まれており、ネットワークに収容される端末数、通信帯域ともに継続的な大容量化が進んでいる。
【０００３】
現在のネットワークでは、通信規格としてＥｔｈｅｒｎｅｔ（登録商標）が主流であり、
ネットワークの大容量化、処理やサービスの複雑化の背景から、ＳＤＮ（Ｓｏｆｔｗａｒｅ  Ｄｅｆｉｎｅｄ  Ｎｅｔｗｏｒｋ）技術として、Ｏｐｅｎ  Ｎｅｔｗｏｒｋｉｎｇ  Ｆｏｕｎｄａｔｉｏｎ（登録商標）により標準仕様が策定されているＯｐｅｎ  Ｆｌｏｗ（登録商標）が注目されている。
【０００４】
Ｏｐｅｎ  Ｆｌｏｗは、ネットワークを構成する複数のルータやスイッチ機器を、一つの制御機器（Ｏｐｅｎ  Ｆｌｏｗコントローラ）により集中管理し、パケットの処理方法を指定することで、柔軟にネットワーク構成や通信ルートを変更することが可能な技術である。
【０００５】
このように、端末数や通信帯域が増大し、それに対応してネットワーク構成の柔軟な変更が必要となる状況においては、サービスを提供するサーバ装置やネットワークとの接続中継を行うゲートウェイ装置も、柔軟に増設が可能であることが求められ、端末からの接続要求を複数台のサーバ機器に分散して処理を行う負荷分散技術が広く使用されている。
【０００６】
負荷分散技術として一般的に知られている技術として、ＤＮＳラウンドロビンやロードバランシングがある。ＤＮＳラウンドロビンは、対象となるＵＲＬについてＤＮＳサーバのゾーンファイルに複数の分散処理サーバのＩＰアドレスを設定しておき、クライアント端末がそのＵＲＬの名前解決を行う際に、複数サーバのＩＰアドレスを順番に返信することで、クライアントの接続先を複数サーバ機器に分散する技術である。
【０００７】
一方、ロードバランシングは、クライアント端末からの要求（リクエスト）をロードバランサが受信し、指定した分散アルゴリズムに従って複数のサーバに転送する形態の技術である。サーバからのレスポンスもロードバランサが中継してクライアント端末へ送信する。ロードバランサでの負荷分散アルゴリズムとしては、ラウンドロビン、最小接続、重み付け比率等が知られている。
【０００８】
ＤＮＳラウンドロビンの技術は、適用が容易かつ安価であるという利点がある一方で、ある端末から見た場合、サービス要求する毎に接続先サーバが変化するため、パーシステンス（セッション情報の維持）が確保できないことや、ラウンドロビンによる分散であるためにいわゆるヘビーユーザの接続が特定のサーバに集中し、負荷が均一に分散されない可能性があること、分散先の処理サーバが故障した場合でもそのサーバのアドレスを接続先として返信してしまうこと、等の課題が知られている。
【０００９】
ロードバランシングは、前述のようなＤＮＳラウンドロビンの課題を解決することが可能な技術であるが、高度な機能と処理性能が要求されるためにロードバランサの導入コストが高く、多数のクライアント端末からの大量のリクエストを処理するような大容量サービスにおいては、サービス容量の拡張はサーバの性能ではなくロードバランサの性能により制限されることとなる。
【００１０】
ロードバランサに関するこのような課題を解決する技術として、特許文献１には、ロードバランサを設置せずに、「複数のサービス処理サーバをＰ２Ｐネットワークを用いてオーバーレイネットワークで接続し、あるサービス処理サーバへのサービスリクエストをＰ２Ｐアルゴリズムに従いサービス処理サーバ間でルーティングさせ、接続先のサービス処理サーバの負荷状態に応じて、ルーティング途中のサービス処理サーバが接続先のサービス処理サーバに代わってサービスリクエストの処理を実行する」（要約）ことが記載されている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】国際公開第２００９／０３４９９４号
【発明の概要】
【発明が解決しようとする課題】
【００１２】
ロードバランサを用いた負荷分散技術における課題として、導入コスト、サービス拡張（クライアント端末増加やサービスコンテンツ拡大等）におけるロードバランサ処理負荷による制限、が挙げられる。
【００１３】
特許文献１に記載の技術は、ロードバランサを設置せずに分散処理を行う技術であり、これらの課題に対応するものであるが、サーバの負荷状態によって他の代行サーバへリクエストを転送するという手法であるため、リクエスト転送処理によりクライアントへの応答遅延が増加する。ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を使用するアプリケーションにおいてはＲＴＴ（Ｒｏｕｎｄ−Ｔｒｉｐ  Ｔｉｍｅ）の増加は転送スループットの低下に繋がるため、高速転送が必要なサービスにおいてはデメリットとなる。
【００１４】
本発明の目的は、ロードバランサを不要とする低遅延な負荷分散システムを提供することにある。
【課題を解決するための手段】
【００１５】
前記の課題を解決するため、本発明に係る代表的な負荷分散システムは、複数のサーバとネットワークスイッチを有する負荷分散システムであって、前記ネットワークスイッチは、ネットワークからフレームを受信し、前記ネットワークから受信されたフレームを前記複数のサーバへフラッディングにより転送し、前記複数のサーバのそれぞれは、前記ネットワークスイッチからフレームを受信し、前記ネットワークスイッチから受信されたフレームに含まれるフレームの送信元の情報に基づき受け付けて、処理することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、ロードバランサを不要とする低遅延な負荷分散システムを提供することができる。
【図面の簡単な説明】
【００１７】
【図１】送信元ＭＡＣアドレスを変換する負荷分散システムの例を示す図である。
【図２】アドレス変換部の例を示す図である。
【図３】送信元ＭＡＣアドレスが変換されるフレームの例を示す図である。
【図４】サーバ群から送信されるフレーム転送の例を示す図である。
【図５】サーバ群へ送信されるフレーム転送の例を示す図である。
【図６】送信元ＩＰアドレスに基づく受信フレームの選別処理の例を示す図である。
【図７】送信元ポート番号に基づく受信フレームの選別処理の例を示す図である。
【図８】ＶＬＡＮを用いた負荷分散システムの例を示す図である。
【図９Ａ】サーバ群へ送信される上り方向フレームの例を示す図である。
【図９Ｂ】サーバ群から送信される上り方向フレームの例を示す図である。
【図９Ｃ】サーバ群へ送信される下り方向フレームの例を示す図である。
【図１０】静的ＡＲＰエントリを用いた負荷分散システムの例を示す図である。
【図１１】宛先ＭＡＣアドレスを変換する負荷分散システムの一実施例を示す図である。
【図１２】宛先ＭＡＣアドレスが変換されるフレームの例を示す図である。
【図１３】ＯｐｅｎＦｌｏｗを用いた負荷分散システムの例を示す図である。
【図１４】ＯｐｅｎＦｌｏｗでアドレス変換する負荷分散システムの例を示す図である。
【図１５】サーバ状態に基づいて制御する負荷分散システムの例を示す図である。
【図１６】１つのサーバで代行処理を行う場合の選別処理の例を示す図である。
【図１７】複数のサーバで代行処理を行う場合の選別処理の例を示す図である。
【発明を実施するための形態】
【００１８】
以下、図面を用いて本発明の好ましい実施形態の例を説明する。
【実施例１】
【００１９】
図１は、フラッディング転送による負荷分散システムの実施形態の一例である。図１に示した例は、一般的なクライアント−サーバ型の処理システムであり、クライアント端末１１、ネットワーク１２、ルータ１３、アドレス変換部１４、レイヤ２スイッチ１５、サーバ群１６により構成される。サーバ群１６は複数のサーバ１８により構成され、負荷分散システム１７は、アドレス変換部１４、レイヤ２スイッチ１５、サーバ群１６により構成される。
【００２０】
クライアント端末１１は、ネットワークを介してサーバ群１６へリクエストを送信し、サーバ群１６からのレスポンスを受信することでサービスの提供を受ける。サービスの種別は、例えばホームページの閲覧であってもよいし、オンラインゲーム等であってもよい。
【００２１】
ネットワーク１２は、クライアント端末１１を収容するネットワークであり、構内ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やインターネット網、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）等のモバイルネットワークであってもよい。図１は、サーバ群１６へ接続されるネットワーク端に、ゲートウェイルータとしてルータ１３が配置される例を示している。
【００２２】
ルータ１３は、通常のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ルーティング処理を行うルータとして動作し、ネットワーク１２と、サーバ群１６との間で送受するパケットをルーティングテーブルに従い転送する。サーバ群１６とはレイヤ２ネットワークで接続されるため、パケットの転送に際し、ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレスの変換を行う。
【００２３】
アドレス変換部１４は、レイヤ２スイッチ１５からルータ１３へ出力されるＥｔｈｅｒｎｅｔフレームのＭＡＣアドレスを変換する。ＭＡＣアドレス変換の詳細については、後述する。レイヤ２スイッチ１５は、入力されるＥｔｈｅｒｎｅｔフレームの送信元ＭＡＣアドレスをポートに関連付けて学習保持し、宛先ＭＡＣアドレスに基づき出力ポートを切り替える汎用的なスイッチングハブである。
【００２４】
ルータ１３から入力されるリクエストフレームは、レイヤ２スイッチ１５のフラッディング動作によりサーバ群１６の複数のサーバ１８へ共通に転送され、サーバ群１６から入力されるレスポンスフレームは、宛先ＭＡＣアドレスの情報に基づくスイッチング転送によりルータ１３へ転送される。フラッディング動作の詳細については後述する。
【００２５】
サーバ群１６は、Ｎ台のサーバ１８であるサーバ（０）〜サーバ（Ｎ−１）により構成され、クライアント端末１１から送信されたリクエストフレームを、Ｎ台のサーバ１８で選別受信することにより、処理を分散してレスポンスを返信することによりサービスをクライアント端末１１へ提供する。
【００２６】
サーバ１８は、一般的な計算機でもよく、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）、プロセッサ、メモリを備えてもよい。ＮＩＣは、サーバ１８のＩＰアドレスとＭＡＣアドレスが設定され、レイヤ２スイッチ１５とネットワーク接続されてもよい。プロセッサは、メモリに格納されたプログラムとデータを使用して処理を実行し、ＮＩＣを制御してもよい。
【００２７】
負荷分散システム１７におけるＩＰアドレスとＭＡＣアドレスについて、さらに説明する。サーバ群１６のＮ台のサーバ１８は、共通のＩＰアドレスが割り当てられて、分散処理を行い、それぞれに番号として０番〜（Ｎ−１）番の番号が割り付けられる。サーバ群１６の共通のＩＰアドレスは、以下ｉｐＳと記載する。
【００２８】
また、Ｎ台のサーバ１８はそれぞれ異なるＭＡＣアドレスが割り当てられ、このＭＡＣアドレスは、以下「ｍａｃＳ（０）」〜「ｍａｃＳ（Ｎ−１）」と記載する。以下同様に、クライアント端末１１のＩＰアドレスは「ｉｐＣＬＩ」、ＭＡＣアドレスは「ｍａｃＣＬＩ」と記載し、ルータ１３のサーバ群１６側のポート（０）のＭＡＣアドレスは「ｍａｃＲ０」と記載し、ネットワーク１２側のポート（１）のＭＡＣアドレスは「ｍａｃＲ１」と記載する。
【００２９】
アドレス変換部１４は、レイヤ２スイッチ１５からルータ１３へ送出されるフレームに対し、送信元ＭＡＣアドレスをダミーのＭＡＣアドレスである「ｍａｃＤ」に変換を行い、レイヤ２のＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ）再計算結果をフレームのトレーラに付与したうえでルータ１３のポート（０）へ出力する。
【００３０】
アドレス変換部１４の例を図２に示す。図２に示した例では、入力フレームの物理層信号に対して、ＰＨＹ（Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）部２１が、光／電気信号変換、復号化、シリアル／パラレル変換等の必要な物理層処理を行う。ＰＨＹ部２１での処理は、レイヤ２スイッチ１５との接続信号の形式（１００ＢＡＳＥ−ＴＸ、１０００ＢＡＳＥ-ＳＲ等）に応じた処理を行う。
【００３１】
ＰＨＹ部２１で復号化されたフレームデータは、ＦＩＦＯ部２２に格納される一方、ＦＣＳ判定部２３でＦＣＳ計算が行なわれ、フレーム内のデータ誤り有無の判定が行なわれる。読み出し制御部２４は、ＦＣＳエラーが検出されたフレームデータは不要フレームとして読み出し制御を行わずに廃棄し、ＦＣＳエラーが検出されないフレームデータは有効フレームとしてＦＩＦＯ部２２へ読み出し制御を行う。
【００３２】
変換処理部２５は、ＦＩＦＯ部２２から読み出されたフレームデータに対し、送信元ＭＡＣアドレスのフィールドのデータをダミーのＭＡＣアドレスであるｍａｃＤに変更したうえで、変更したフレームデータについてＦＣＳ計算を行い、フレームトレーラのＦＣＳフィールドを計算した結果と差し替えて出力する。ＰＨＹ部２６は、ルータ１３との信号接続形式に応じた物理層処理を行う。処理の例としては、パラレル／シリアル変換、符号化、電気／光信号変換等である。
【００３３】
図３に、アドレス変換部１４での変換前、変換後のフレームの例を示す。変換前フレーム３１は、アドレス変換前のフレームの例である。この変換前フレーム３１は、サーバ（０）が送出したレスポンスフレームの例を示しており、送信元ＭＡＣアドレスはサーバ（０）のＭＡＣアドレスの「ｍａｃＳ（０）」である。
【００３４】
変換後フレーム３２は、アドレス変換後のフレームの例である。送信元ＭＡＣアドレスのデータフィールドはダミーのＭＡＣアドレスである「ｍａｃＤ」に変換され、トレーラにあるＦＣＳフィールドは変換後のフレームデータで計算したデータである「ＦＲＤ」に変更される。
【００３５】
図３に示した例は、サーバ（０）が送出したフレームであるが、他のサーバ１８が送出したフレームの場合でも、同様に送信元ＭＡＣアドレス、ＦＣＳのフィールドが変更される。なお、ダミーのＭＡＣアドレスである「ｍａｃＤ」は、ルータ１３、サーバ群１６の各固有のＭＡＣアドレス、その他システム内で使用されるＭＡＣアドレスと重複しない（システム内で割り当てられていない）ＭＡＣアドレスであれば、特定の値である必要はない。
【００３６】
図４に、サーバ群１６からクライアント端末１１へ送信されるフレームの転送例を示す。サーバ群１６から送信されるフレームは、送信元ＭＡＣアドレスを各々のサーバに固有のＭＡＣアドレスである「ｍａｃＳ（０）」〜「ｍａｃＳ（Ｎ−１）」、送信元ＩＰアドレスを各サーバ１８に共通のＩＰアドレスである「ｉｐＳ」、宛先ＭＡＣアドレスをルータ１３のポート（０）のＭＡＣアドレスである「ｍａｃＲ０」、宛先ＩＰアドレスをクライアント端末のＩＰアドレスである「ｉｐＣＬＩ」、として送信される。
【００３７】
レイヤ２スイッチ１５は、各サーバ１８の固有ＭＡＣアドレスである「ｍａｃＳ（０）」〜「ｍａｃＳ（Ｎ−１）」を、各接続ポートに対応学習したうえで、宛先ＭＡＣアドレスの「ｍａｃＲ０」に従いポート（Ａ０）から出力することにより、ルータ１３へフレームを転送する。
【００３８】
この対応学習は、例えば、ルータ１３のＭＡＣアドレスである「ｍａｃＲ０」とポート（Ａ０）とが対応し、サーバ１８のＭＡＣアドレスである「ｍａｃＳ０」とポート（Ａ１）とが対応するというものである。レイヤ２スイッチ１５が受信したフレームの送信元ＭＡＣアドレスを学習し、それ以外は学習しない。
【００３９】
そして、レイヤ２スイッチ１５とルータ１３との間にあるアドレス変換部１４の処理により、ルータ１３のポート（０）へ入力されるフレームは、送信元ＭＡＣアドレスがダミーのアドレスである「ｍａｃＤ」、送信元ＩＰアドレスがサーバ群１６の共通のＩＰアドレスである「ｉｐＳ」と入力される。
【００４０】
ルータ１３は、このアドレス変換部１４により変換された後のフレームの送信元ＭＡＣアドレスである「ｍａｃＤ」と送信元ＩＰアドレスである「ｉｐＳ」とを対応付けて、動的ＡＲＰ（Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）エントリ４１を内部にキャッシュ保持した上で、ルーティングテーブルに従いポート（１）からネットワーク１２へ転送する。なお、ルータの通常の動作として、ルータ１３から出力されるフレームの送信元ＭＡＣアドレスはルータ１３の「ｍａｃＲ１」と入力される。
【００４１】
また、ルータ１３から出力されるフレームの宛先ＭＡＣアドレスは、ルーティングテーブルに従いクライアント端末１１の「ｍａｃＣＬＩ」と入力される例を示したが、これに限定されるものではなく、ネットワーク１２においてルータ１３からクライアント端末１１までに至る経路上のネットワーク機器のＭＡＣアドレスが入力されてもよい。
【００４２】
図５に、クライアント端末１１からサーバ群１６へ送信されるフレームの転送例を示す。クライアント端末１１から送出されるフレームは、送信元ＭＡＣアドレスを自身のＭＡＣアドレスである「ｍａｃＣＬＩ」、送信元ＩＰアドレスを自身のＩＰアドレスである「ｉｐＣＬＩ」、宛先ＭＡＣアドレスをゲートウェイルータであるルータ１３のポート１のＭＡＣアドレスである「ｍａｃＲ１」、宛先ＩＰアドレスをサーバ群１６の共通ＩＰアドレスである「ｉｐＳ」、として送信される。
【００４３】
ルータ１３は、ルーティングテーブルに従い、このフレームをポート（０）からレイヤ２スイッチ１５へ転送する。この際、内部にキャッシュ保持している動的ＡＲＰエントリ４１に従い、ＩＰアドレスの「ｉｐＳ」に対応するように宛先ＭＡＣアドレスを「ｍａｃＤ」に変換し、送信元ＭＡＣアドレスを自身のＭＡＣアドレスである「ｍａｃＲ０」に変換する。
【００４４】
レイヤ２スイッチ１５は、フレームの宛先ＭＡＣアドレスである「ｍａｃＤ」が、自身の内部に学習保持したＭＡＣアドレステーブルに存在しないため、フラッディング動作によりレイヤ２スイッチ１５の全ポートから転送する。この結果、サーバ群１６の各サーバ１８は、共通にクライアント端末１１から送信されたフレームを受信する。
【００４５】
以上で説明したように、アドレス変換部１４でのＭＡＣアドレス変換処理を行うことで、サーバ群１６の各サーバ１８はクライアント端末１１からのリクエストフレームを共通に受信することとなり、各サーバ１８が適切にリクエストフレームの選別処理を行い、レスポンスを返信することで、複数のサーバ１８で分散処理を行うことが可能となる。フラッディング転送により、サーバ群１６の各サーバ１８はリクエストフレームを受信できるため、ロードバランサなどによる遅延が生じることはなく、ロードバランサなどの装置が不要であるからコストを低減できる。
【００４６】
サーバ群１６の各サーバ１８でのリクエストフレームの選別処理の一例を図６に示す。図６に示した例は、リクエストフレームの送信元ＩＰアドレスを基に選別処理を行う例である。負荷分散を行うサーバ１８の数をＮ台、各サーバの番号を０番〜（Ｎ−１）番とした場合、各サーバ１８は、レイヤ２スイッチ１５からフラッディング転送されるリクエストフレームを受信し（ステップ６１）、リクエストフレームの送信元ＩＰアドレスを被除数、サーバ１８の数Ｎを除数として剰余算を行い、剰余が自サーバ番号と一致するか判定する(ステップ６２)。
【００４７】
各サーバ１８は、ステップ６２で剰余が自サーバ番号と一致すると判定した場合、自サーバ宛のリクエストとして受け付けて処理を行い、クライアント端末１１へレスポンスを返信する（ステップ６３）。ステップ６２で剰余が自サーバ番号と一致しないと判定した場合は、他サーバ宛のリクエストとして、受信したリクエストフレームを廃棄する（ステップ６４）。
【００４８】
一例として、４台のサーバ１８で分散処理を行う場合、各サーバ１８は０番〜３番の番号が付与された上で、各サーバ１８は受信したリクエストフレームの送信元アドレスに対する４の剰余算を行う。剰余算の結果が０のリクエストにはサーバ０番が、結果が１のリクエストにはサーバ１番が、結果が２のリクエストにはサーバ２番が、結果が３のリクエストにはサーバ３番がレスポンスを返信することで、負荷分散処理を行う。
【００４９】
ここで、クライアント端末１１は４台以上であり、各クライアント端末のＩＰアドレスの最下位の値は異なることが好ましい。また、サーバ群１６の各サーバ１８は、受信したフレームの宛先ＩＰアドレスを判定して受信したフレームの宛先ＭＡＣアドレスを無視してもよいし、自身のＭＡＣアドレスである「ｍａｃ（０）」〜「ｍａｃＳ（Ｎ−１）」のいずれか、または「ｍａｃＤ」を宛先ＭＡＣアドレスとするフレームを受信するようにしてもよい。
【実施例２】
【００５０】
第２の実施例として、各サーバ１８が、リクエストフレーム内のＴＣＰレイヤまたはＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）レイヤのヘッダに含まれる送信元ポート番号の剰余算によりサーバ１８での選別処理を行う例を説明する。図１〜５を用いて説明した内容は、実施例１と同じであるので説明を省略する。図７はリクエストフレームの選別処理の一例を示し、実施例１の図６に対応する図である。
【００５１】
負荷分散を行うサーバ１８の数をＮ台、各サーバ１８の番号を０番〜（Ｎ−１）番とした場合、各サーバ１８は、レイヤ２スイッチ１５からフラッディング転送されるリクエストフレームを受信し（ステップ７１）、リクエストフレームの送信元ポート番号を被除数、サーバ１８の数Ｎを除数として剰余算を行い、剰余が自サーバ番号と一致するか判定する（ステップ７２）。
【００５２】
各サーバ１８は、ステップ７２で剰余が自サーバ番号と一致すると判定した場合、自サーバ宛のリクエストとして受け付けて処理を行い、クライアント端末１１へレスポンスを返信する（ステップ７３）。ステップ７２で剰余が自サーバ番号と一致しないと判定した場合は、他サーバ宛のリクエストとして、受信したリクエストフレームを廃棄する（ステップ７４）。
【００５３】
一例として、４台のサーバ１８で分散処理を行う場合、各サーバ１８は０番〜３番の番号が付与された上で、各サーバ１８はリクエストフレームの送信元ポート番号に対する４の剰余算を行う。剰余算の結果が０のリクエストにはサーバ０番が、結果が１のリクエストにはサーバ１番が、結果が２のリクエストにはサーバ２番が、結果が３のリクエストにはサーバ３番がレスポンスを返信することで、負荷分散処理を行う。
【００５４】
実施例１で説明した送信元ＩＰアドレスを対象とした剰余算の場合、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）等を介在して接続するクライアント端末１１が多数存在すると（複数のクライアント端末１１からのリクエストフレームが１つのＩＰアドレスから送信されると）、負荷が一部のサーバ１８に集中する可能性があるが、ＴＣＰ／ＵＤＰレイヤの送信元ポート番号は、一般的にアプリケーションによりランダムに決定されるため、負荷の均一化に寄与できる。
【００５５】
さらに、サーバ１８によって性能に差分がある場合等では、重み付け負荷分散をしてもよい。以上での説明と同様に、サーバ０番〜サーバ３番の４台で分散処理を行う構成において、サーバ３番に他の２倍の処理負荷を配分する場合、各サーバ１８はリクエストフレームの送信元ポート番号を被除数とし、除数を５として剰余算を行う。除数５は、配分したい負荷比率の合算値であり、１＋１＋１＋２ により算出される。
【００５６】
剰余算の結果が０のリクエストにはサーバ０番が、結果が１のリクエストにはサーバ１番が、結果が２のリクエストにはサーバ２番が、結果が３と４のリクエストにはサーバ３番がレスポンスを返信することで、重み付け分散処理を行うことが可能となる。
【実施例３】
【００５７】
実施例３として、サーバ群１６がクライアント端末１１とインターネット８６との接続を中継する例を説明する。図８は、フラッディング転送による中継の負荷分散システムの実施形態の一例である。この例において、サーバ群１６は、クライアント端末１１とインターネット８６との接続を中継するプロキシサーバであり、ＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）ゲートウェイ等であってもよい。そして、クライアント端末１１は、インターネット８６への接続に際してはサーバ群１６をプロキシサーバとして接続を行う。
【００５８】
ルータ１３は、図１に示したルータ１３と同じであるので、同じ符号を付して説明を省略する。ローカルネットワーク８１は、クライアント端末１１をレイヤ２ネットワークで収容する構内ＬＡＮ等である。アドレス変換部８２は、ローカルネットワーク８１とレイヤ２スイッチ１５との間に配置され、レイヤ２スイッチ１５からローカルネットワーク８１へ出力されるＥｔｈｅｒｎｅｔフレームのＭＡＣアドレスを変換する。アドレス変換の動作そのものは、アドレス変換部１４と同じである。
【００５９】
アドレス変換部８５は、ルータ１３とレイヤ２スイッチ１５との間に配置され、レイヤ２スイッチ１５からルータ１３へ出力されるＥｔｈｅｒｎｅｔフレームのＭＡＣアドレスを変換する機能を持つ。アドレス変換の動作そのものは、アドレス変換部１４と同じである。レイヤ２スイッチ１５は、図１に示したレイヤ２スイッチ１５と同じであるが、レイヤ２スイッチ１５内に複数のＶＬＡＮ（Ｖｉｒｔｕａｌ  ＬＡＮ）が設定される。
【００６０】
ＶＬＡＮ＿Ａ８３は、ローカルネットワーク８１とサーバ群１６とを接続するレイヤ２ネットワークであって、仮想ネットワークである。また、ＶＬＡＮ＿Ｂ８４は、ルータ１３とサーバ群１６とを接続するレイヤ２ネットワークであって、仮想ネットワークである。負荷分散システム８７は、アドレス変換部８２、アドレス変換部８５、レイヤ２スイッチ１５、サーバ群１６から構成され、サーバ群１６は複数のサーバ１８から構成される。
【００６１】
レイヤ２スイッチ１５は、ＶＬＡＮ＿Ａ８３とＶＬＡＮ＿Ｂ８４により、クライアント端末１１とサーバ群１６との通信と、インターネット８６とサーバ群１６との通信の２つの通信に分離するため、それぞれの通信について説明する。
【００６２】
アドレス変換部８２は、サーバ群１６からＶＬＡＮ＿Ａ８３を介して受信するフレームについて、送信元ＭＡＣアドレスをダミーのＭＡＣアドレスに変換した上でＦＣＳ再計算を行い、ローカルネットワーク８１へ出力する。ここでの変換の内容は、図２及び図３を用いて説明した内容と同様である。
【００６３】
アドレス変換部８２でのＭＡＣアドレス変換処理により、クライアント端末１１は、サーバ群１６のＩＰアドレスとダミーのＭＡＣアドレスを動的ＡＲＰエントリとしてキャッシュ保持するため、クライアント端末１１からサーバ群１６へ送出されるリクエストフレームは、宛先ＭＡＣアドレスをダミーのＭＡＣアドレスとして送出される。
【００６４】
ダミーのＭＡＣアドレスはレイヤ２スイッチ１５に学習保持されていないので、このリクエストフレームは、レイヤ２スイッチ１５内のＶＬＡＮ＿Ａ８３に属する全ポートにフラッディング動作により転送されるため、サーバ群１６の複数のサーバ１８が共通に受信する。なお、インターネット８６側のアドレス変換部８５が接続されるポートは、ＶＬＡＮ＿Ｂ８４に属し、ＶＬＡＮ＿Ａ８３に属さないため、このフラッディング動作では転送されない。
【００６５】
アドレス変換部８５は、サーバ群１６からＶＬＡＮ＿Ｂ８４を介して受信するフレームについて、送信元ＭＡＣアドレスをダミーのＭＡＣアドレスに変換した上でＦＣＳ再計算を行い、ルータ１３へ出力する。ここでの変換の内容は、図２及び図３を用いて説明した内容と同様である。
【００６６】
アドレス変換部８５でのＭＡＣアドレス変更処理により、ルータ１３は、サーバ群１６のＩＰアドレスとダミーのＭＡＣアドレスを動的ＡＲＰエントリとしてキャッシュ保持するため、ルータ１３がインターネット８６から受信してサーバ群１６へ転送するフレームは、宛先ＭＡＣアドレスをダミーのＭＡＣアドレスとして送出される。
【００６７】
ダミーのＭＡＣアドレスはレイヤ２スイッチ１５に学習保持されていないので、このフレームは、レイヤ２スイッチ１５内のＶＬＡＮ＿Ｂ８４に属するポートにフラッディング動作により転送されるため、サーバ群１６の複数のサーバ１８が共通に受信する。なお、クライアント端末１１側のアドレス変換部８２が接続されるポートは、ＶＬＡＮ＿Ａ８３に属し、ＶＬＡＮ＿Ｂ８４に属さないため、このフラッディング動作では転送されない。
【００６８】
このように、ＶＬＡＮ技術を使用して２つの仮想ネットワークに分離することで、リクエストフレームの受付元と送出先のネットワークが異なる場合でも、フラッディング動作による転送範囲を分離し、複数のサーバ１８が複数のネットワークからの入力を共通に受信することが可能となる。図６または図７を用いて説明した選別処理を各サーバ１８が行うことで、複数のサーバ１８で負荷分散処理を行うことができる。
【００６９】
なお、サーバ群１６での受信フレームを、送信元ＩＰアドレスや送信元ポート番号に基づいて選別処理を行う場合、上り方向（クライアント端末１１からインターネット８６へ送信する方向）の処理をするサーバ１８と、下り方向（インターネット８６からクライアント端末１１へ送信する方向）の処理をするサーバ１８が一致しない場合もある。そこで、上り方向と下り方向とを同一のサーバ１８で処理するための選別受信について、以下に説明する。
【００７０】
以下に説明する例は、クライアント端末１１が、インターネット８６上のアプリケーションサーバへの接続要求のため、プロキシサーバであるサーバ群１６へリクエストを送出し、アプリケーションサーバからのレスポンスは、サーバ群１６により中継されて受信する例である。
【００７１】
サーバ群１６の各サーバ１８は、上り方向のリクエスト送出用の送信元ポート番号を、他のサーバ１８と重複しないように予約されている。例として、サーバ０番〜サーバ３番の４台で負荷分散を行う場合、サーバ０番は１００００番〜１９９９９番、サーバ１番は２００００番〜２９９９９番というように予約されてもよい。このリクエスト送出用の送信元ポート番号を、代表として以下「ｐｒｔＳＢ」と記載する。
【００７２】
図９Ａに示した上り方向のフレーム９１は、クライアント端末１１がサーバ群１６へ送信する上り方向のフレームの例であり、レイヤ４のプロトコルがＴＣＰの例である。クライアント端末１１は、宛先ＭＡＣアドレス、宛先ＩＰアドレス共に、接続を代行するプロキシサーバであるサーバ群１６のアドレスすなわち「ｉｐＳＡ」が設定される。
【００７３】
アドレス変換部８２にて、予めクライアント端末１１へ送出されるフレームの送信元ＭＡＣアドレスはダミーのＭＡＣアドレスである「ｍａｃＤ１」に変換されている。この処理により、クライアント端末１１は、サーバ群１６のＩＰアドレスである「ｉｐＳＡ」と、ダミーのＭＡＣアドレスである「ｍａｃＤ１」とをキャッシュ保持するため、上り方向のフレーム９１の宛先ＭＡＣアドレスは「ｍａｃＤ１」となる。
【００７４】
送信元ポート番号である「ｐｒｔＣＬＩ」は、クライアント端末１１が動的に設定した番号であり、宛先ポート番号である「ｐｒｔＳＡ」は、プロキシサーバであるサーバ群１６が、リクエスト受信用の宛先ポート番号である。プロキシサーバであるサーバ群１６の各サーバ１８は、ＶＬＡＮ＿Ａ８３から受信した上り方向のフレーム９１について、図６、７を用いて説明したように送信元ＩＰアドレスや送信元ポート番号に基づき選別受信を行う。
【００７５】
各サーバ１８は、選別受信した上り方向のフレーム９１について、宛先ＩＰアドレスと宛先ポート番号をインターネット８６の接続要求先のアプリケーションサーバに対応した値である「ｉｐＡＰＬ」と「ｐｒｔＡＰＬ」にそれぞれ設定し、送信元ＩＰアドレスは自身のＩＰアドレスである「ｉｐＳＢ」に設定し、送信元ポート番号は自身の予約番号である「ｐｒｔＳＢ」に設定して、ルータ１３を介してインターネット８６のアプリケーションサーバへ送出する。
【００７６】
上述の処理により、サーバ群１６がインターネット８６のアプリケーションサーバへ送出する上り方向のフレームの例は、図９Ｂに示した上り方向のフレーム９２のようになる。ここで、送信元ＭＡＣアドレス「ｍａｃＳ」は各サーバ１８に固有のＭＡＣアドレスであり、宛先ＭＡＣアドレス「ｍａｃＲ０」は、ルータ１３のポート（０）のＭＡＣアドレスである。
【００７７】
サーバ群１６が、アプリケーションサーバからルータ１３を介して受信する下り方向のフレームの例は、図９Ｃに示した下り方向のフレーム９３である。下り方向のフレーム９３の宛先ＩＰアドレスと宛先ポート番号は、上り方向のフレーム９２の送出時に設定した「ｉｐＳＢ」と「ｐｒｔＳＢ」に設定され、送信元ＩＰアドレスと送信元ポート番号は、接続先のアプリケーションサーバが持つ値である「ｉｐＡＰＬ」と「ｐｒｔＡＰＬ」に設定される。
【００７８】
各サーバ１８は、受信した下り方向のフレーム９３の宛先ポート番号である「ｐｒｔＳＢ」が、自身の予約値であるか否かを判定し、自身の予約値であると判定した場合は受信処理を行い、そうでないと判定した場合は他サーバ宛のフレームとして廃棄することで選別処理を行う。
【００７９】
以上で説明したように、ＴＣＰ（あるいはＵＤＰ）の送信元ポート番号を、各サーバ１８間で重複しないように予約して使用することにより、上り方向と下り方向の通信を同一サーバで処理するように選別し、負荷分散処理を行うことが可能となる。
【実施例４】
【００８０】
実施例４として、ルータ１３に、サーバ群１６のＩＰアドレスに対応した静的な（Ｓｔａｔｉｃな）ＡＲＰエントリが設定されることにより、フラッディング動作を行わせて負荷分散する例を説明する。図１０は、フラッディング転送による負荷分散システムの実施形態の一例であり、図１に示した例に対して、ルータ１３とレイヤ２スイッチ１５とがアドレス変換部１４を介することなく接続されている。図１と同じ構成は同じ符号を付して説明を省略する。
【００８１】
負荷分散システム１０２は、レイヤ２スイッチ１５、サーバ群１６から構成される。ルータ１３は、図１、４、５に示したルータ１３と同じルータであるが、図４、５を用いて説明したような動的ＡＲＰエントリ４１の設定ではなく、静的ＡＲＰエントリが設定される。静的ＡＲＰエントリ１０１として設定される内容は、動的ＡＲＰエントリ４１と同じく、ルータ１３のポート（０）の接続先にはＩＰアドレスが「ｉｐＳ」であるサーバ群１６があり、ＭＡＣアドレスはダミーのＭＡＣアドレスの「ｍａｃＤ」であるという内容である。
【００８２】
静的ＡＲＰエントリ１０１が設定されることにより、クライアント端末１１からサーバ群１６へ送信されるリクエストフレームは、宛先ＩＰアドレスが「ｉｐＳ」であるので、ルータ１３でのルーティング処理時に、静的ＡＲＰエントリ１０１に従い、宛先ＩＰアドレスの「ｉｐＳ」に対して、宛先ＭＡＣアドレスが「ｍａｃＤ」と入力されて、ポート（０）からレイヤ２スイッチ１５へ転送される。
【００８３】
レイヤ２スイッチ１５は、リクエストフレームの宛先ＭＡＣアドレスである「ｍａｃＤ」が、自身の内部に学習保持したＭＡＣアドレステーブルに存在しないため、サーバ群１６の各サーバ１８が接続されている全ポートへフラッディング動作により転送する。
【００８４】
以上で説明したように、サーバ群１６の前段に配置されるゲートウェイルータであるルータ１３に、サーバ１８のＩＰアドレスとダミーのＭＡＣアドレスが静的ＡＲＰエントリとして設定されることにより、複数のサーバ１８が共通にリクエストフレームを受信することが可能となり、各サーバ１８が、図６、７を用いて説明した選別処理を行うことで、複数のサーバ１８で分散処理を行うことが可能となる。
【実施例５】
【００８５】
実施例５として、ルータ１３からレイヤ２スイッチ１５へ出力されるフレームの宛先ＭＡＣアドレスを変換するアドレス変換部１１１を備える例を説明する。図１１は、フラッディング転送による負荷分散システムの実施形態の一例であり、図１に示した例に対して、アドレス変換部１４の代わりにアドレス変換部１１１を有する。図１と同じ構成は同じ符号を付して説明を省略する。
【００８６】
負荷分散システム１１２は、アドレス変換部１１１、レイヤ２スイッチ１５、サーバ群１６から構成される。アドレス変換部１１１は、ルータ１３からレイヤ２スイッチ１５へ送出する方向に配置されており、ルータ１３からレイヤ２スイッチ１５へ送出されるフレームの宛先ＭＡＣアドレスを、ダミーのＭＡＣアドレスに変換したうえで、ＦＣＳの再計算を行う。
【００８７】
図１２に、アドレス変換部１１１での変換前と変換後のフレームの例を示す。変換前フレーム１２１は、アドレス変換部１１１による変換の前のフレームの例であり、宛先ＭＡＣアドレスの「ｍａｃＸ」はサーバ群１６のサーバ１８いずれかのＭＡＣアドレスを示し、送信元ＭＡＣアドレスの「ｍａｃＲ」はルータ１３のポート（０）のＭＡＣアドレスを示し、宛先ＩＰアドレスの「ｉｐＣＬＩ」はクライアント端末１１のＩＰアドレスを示し、送信元ＩＰアドレスの「ｉｐＳ」はサーバ群１６の共通ＩＰアドレスを示す。
【００８８】
変換後フレーム１２２は、アドレス変換部１１１による変換の後のフレームの例であり、宛先ＭＡＣアドレスの「ｍａｃＤ」はダミーのＭＡＣアドレスを示し、変換前フレーム１２１の「ｍａｃＸ」から変換されたＭＡＣアドレスである。また、トレーラであるＦＣＳフィールドは変換後のフレームデータで計算したデータである「ＦＤＲ」に変更される。なお、変換後フレーム１２２におけるダミーのＭＡＣアドレスの「ｍａｃＤ」は、ブロードキャストアドレスであってもよい。
【００８９】
アドレス変換部１１１がダミーのＭＡＣアドレスへの変換を実施することで、クライアント端末１１からサーバ群１６へ送信されるフレームであって、宛先ＩＰアドレスが「ｉｐＳ」であるフレームは、宛先ＭＡＣアドレスが「ｍａｃＤ」へ変換されて、レイヤ２スイッチ１５へ入力される。レイヤ２スイッチ１５は、宛先ＭＡＣアドレスがダミーのアドレスである「ｍａｃＤ」であるため、フラッディング動作によりレイヤ２スイッチ１５の全ポートにフレームを転送する。
【００９０】
以上で説明したように、アドレス変換部１１１をルータ１３からサーバ群１６へ出力される方向に配置し、レイヤ２スイッチ１５へ入力されるフレームの宛先ＭＡＣアドレスを、ダミーのＭＡＣアドレスまたはブロードキャストアドレスへ変換することにより、複数のサーバ１８が共通にフレームを受信することが可能となり、各サーバ１８が、図６、７を用いて説明した選別処理を行うことで、複数のサーバ１８で分散処理を行うことが可能となる。
【実施例６】
【００９１】
実施例６として、ルールやポリシー等と呼べる情報に基づき、受信したフレームのヘッダの情報を判定し、転送するポートを選択したり、ヘッダの情報を変更したりするスイッチを用いた例を説明する。その一つとして、ＳＤＮ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋ）技術であるＯｐｅｎＦｌｏｗを用いた例を説明する。図１３は、ＯｐｅｎＦｌｏｗコントローラ１３１とＯｐｅｎＦｌｏｗスイッチ１３２を備えた負荷分散システム１３４の例を示す。図１と同じ構成は同じ符号を付して説明を省略する。
【００９２】
ＯｐｅｎＦｌｏｗコントローラ１３１は、クライアント端末１１からサーバ群１６へ送信されるリクエストフレームをフラッディング配信するため、フローテーブル１３３の内容を作成して、ＯｐｅｎＦｌｏｗスイッチ１３２へ設定する。ＯｐｅｎＦｌｏｗスイッチ１３２は、設定されたフローテーブル１３３に従い、受信したフレームの処理を行う。
【００９３】
なお、Ｏｐｅｎ Ｆｌｏｗコントローラ１３１とＯｐｅｎ Ｆｌｏｗスイッチ１３２は、それぞれＯｐｅｎ Ｎｅｔｗｏｒｋｉｎｇ Ｆｏｕｎｄａｔｉｏｎにより策定された標準仕様に則り、Ｏｐｅｎ  Ｆｌｏｗプロトコルにより通信を行うものであり、ＯｐｅｎＦｌｏｗスイッチ１３２は、Ｏｐｅｎ ｖＳｗｔｉｃｈ等の、ソフトウェア技術による仮想スイッチであってもよい。
【００９４】
フローテーブル１３３の内容として、ヘッダフィールドの条件は、「Ｉｎｇｒｅｓｓ  ｐｏｒｔ」が「ポート（Ｘ）」、「ＩＰ  ｄｓｔ  ａｄｄｒｅｓｓ」がサーバ群１６の共通ＩＰアドレスである「ｉｐＳ」とし、この条件に合致する受信フレームへのアクションを、「Ｆｏｒｗａｒｄ  ＡＬＬ」とすることで、ネットワーク１２から受信する、サーバ群１６宛てのフレームは、ポート（０）〜ポート（Ｎ−１）から転送される。
【００９５】
すなわち、Ｏｐｅｎ  Ｆｌｏｗスイッチ１３２は、設定されたフローテーブル１３３に従い、ポート（Ｘ）で受信した宛先ＩＰアドレスが「ｉｐＳ」であるフレームを、受信元であるポート（Ｘ）を除く、ポート（０）〜ポート（Ｎ−１）から転送する。これにより、サーバ（０）〜サーバ（Ｎ−１）が、クライアント端末１１から送信されるリクエストを受信することが可能となり、各サーバ１８が、図６、７を用いて説明した選別処理を行うことで、複数のサーバ１８で分散処理を行うことが可能となる。
【００９６】
なお、ＯｐｅｎＦｌｏｗは一例であって、これに限定されるものではない。
【実施例７】
【００９７】
実施例７として、ルールやポリシー等と呼べる情報に基づき、受信したフレームのヘッダの情報を判定し、転送するポートを選択したり、ヘッダの情報を変更したりするスイッチを用いた別の例を説明する。図１４に示した負荷分散システム１４２は、図１３に示した負荷分散システム１３４に対してレイヤ２スイッチ１５を有し、フローテーブル１４１の内容が異なる。図１、１３と同じ構成は同じ符号を付して説明を省略する。
【００９８】
フローテーブル１４１の内容として、ヘッダフィールドの条件は、「Ｉｎｇｒｅｓｓ  ｐｏｒｔ」が「ポート（Ｘ）」、「ＩＰ  ｄｓｔ  ａｄｄｒｅｓｓ」がサーバ群１６の共通ＩＰアドレスである「ｉｐＳ」とし、この条件に合致する受信フレームへのアクションを、「Ｓｅｔ  Ｆｉｅｌｄ」とし、「Ｔｙｐｅ：ｄｅｓｔ＿ｍａｃ」、「Ｖａｌｕｅ：ｍａｃＤ」とすることで、ネットワーク１２から受信する、サーバ群１６宛てのフレームの宛先ＭＡＣアドレスは、ダミーのＭＡＣアドレスである「ｍａｃＤ」に変換される。
【００９９】
すなわち、Ｏｐｅｎ  Ｆｌｏｗスイッチ１３２は、設定されたフローテーブル１４１に従い、ポート（Ｘ）で受信した宛先ＩＰアドレスが「ｉｐＳ」であるフレームの宛先ＭＡＣアドレスを、ダミーのＭＡＣアドレスである「ｍａｃＤ」に変換する。
【０１００】
後段のレイヤ２スイッチ１５は、ＯｐｅｎＦｌｏｗスイッチ１３２から受信したフレームの宛先ＭＡＣアドレスがダミーのアドレスである「ｍａｃＤ」であるため、フラッディング動作により全ポートへフレームを転送する。
【０１０１】
以上で説明したように、複数のサーバ１８が共通にフレームを受信することが可能となり、各サーバ１８が、図６、７を用いて説明した選別処理を行うことで、複数のサーバ１８で分散処理を行うことが可能となる。なお、ＯｐｅｎＦｌｏｗは一例であって、これに限定されるものではない。
【実施例８】
【０１０２】
実施例８として、サーバ群１６のサーバ１８それぞれの状態に応じて分散処理する例を説明する。図１５に示した負荷分散システム１５４は、アドレス変換部１４、レイヤ２スイッチ１５、サーバ群１６、制御部１５１、ネットワークストレージ１５２、バックエンドスイッチ１５３から構成される。図１と同じ構成は同じ符号を付して説明を省略する。
【０１０３】
制御部１５１は、サーバ群１６の各サーバ１８の動作状態や負荷状態を監視し、故障検出時や負荷集中時には、他のサーバへ代行処理を指示する。ネットワークストレージ１５２は、サーバ群１６の各サーバ１８が処理中のクライアント端末１１の情報やサービス状態等を保持するための共有記憶領域である。ネットワークストレージ１５２は、各サーバ１８が共有可能な記憶領域であればよく、例えばサーバ群１６が接続可能な共有メモリ等であってもよい。
【０１０４】
バックエンドスイッチ１５３は、サーバ群１６と制御部１５１とネットワークストレージ１５２とを接続する汎用的なスイッチングハブである。フロントエンドスイッチであるレイヤ２スイッチ１５と、バックエンドスイッチ１５３は、同一のハードウェアをＶＬＡＮ技術により分離して構築してもよい。
【０１０５】
以下、サーバ群１６が既に説明した負荷分散処理を実行中に、サーバ群１６の中のサーバ１８が故障し、他のサーバ１８が代行処理を行う例を説明する。制御部１５１は、サーバ群１６のサーバ１８それぞれに対して、バックエンドスイッチ１５３を介して、死活監視を実施する。死活監視の内容は、例えば、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）による応答監視、ポートスキャンやＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）による動作状態監視、ＣＰＵ（プロセッサ）使用率やメモリ使用率によるリソース使用量監視等の一つまたは複数であってもよい。
【０１０６】
各サーバ１８は、自身が実行中の処理のサービス情報を、バックエンドスイッチ１５３経由でネットワークストレージ１５２に随時に書き込み保存する。ここで、サービス情報とは、接続中のクライアント端末１１のアドレスや位置情報、認証アカウント、サービス履歴情報等、クライアント端末１１に対してサービスを提供するにあたり必要な情報である。
【０１０７】
例として複数のサーバ１８の中のサーバ１番が運用中に故障した場合、制御部１５１がサーバ１番の故障を検出し、他のサーバ１８の中から、ＣＰＵ使用率やメモリ使用率等のリソースに、より余裕のあるサーバ１８を代行サーバとして選定し、サーバ１番の代行処理を指示する。代行処理を指示されたサーバ１８は、ネットワークストレージ１５２から、故障したサーバ１番が書き込んだサービス情報を読み出し、クライアント端末１１へのサービス提供の代行を行う。
【０１０８】
クライアント端末１１へのサービスの代行提供にあたり、代行サーバでのリクエストフレームの選別処理を変更する必要がある。代行サーバでのリクエストフレームの選別処理の一例を図１６に示す。この例は、図７を用いて説明した例と同じく、リクエストフレームの送信元ポート番号を基に選別処理を行う場合の例である。
【０１０９】
代行サーバは、レイヤ２スイッチ１５のフラッディング転送によりリクエストフレームを受信し（ステップ１６１）、受信したリクエストフレームの送信元ポート番号についてサーバ１８の数Ｎの剰余算を行い、その結果を変数Ｘに設定する（ステップ１６２）。代行サーバは、変数Ｘの値が自サーバ番号と一致すると判定した場合（ステップ１６３）、自サーバ宛リクエストとして受け付けて処理を行う（ステップ１６４）。
【０１１０】
代行サーバは、ステップ１６３で変数Ｘの値が自サーバ番号と一致しないと判定した場合、変数Ｘの値が故障サーバの番号と一致するかの判定を行う（ステップ１６５）。代行サーバは、変数Ｘの値が故障サーバの番号と一致すると判定した場合、代行処理リクエストとして受け付けて処理を行い（ステップ１６６）、故障サーバの番号と一致しないと判定した場合は他サーバ宛のリクエストとして廃棄する（ステップ１６７）。なお、これらの代行サーバの処理は、代行サーバのメモリに格納されたプログラムに基づいて代行サーバのプロセッサが実行してもよい。
【０１１１】
制御部１５１により代行サーバに決定されるサーバ１８は１台のサーバ１８ではなく、複数のサーバ１８が代行サーバに決定されてもよい。複数のサーバ１８で代行処理を行う場合の選別処理の一例を図１７に示す。具体例として、サーバ０番〜サーバ３番の４台で分散処理を実行中に、サーバ２番が故障し、その代行処理をサーバ０番、サーバ１番、サーバ３番で均一に分散する場合の選別処理を説明する。
【０１１２】
サーバ０番、サーバ１番、サーバ３番のそれぞれは、同じフローの処理を行うため、サーバ１番を代表として説明する。サーバ１番は、レイヤ２スイッチ１５のフラッディング転送によりリクエストフレームを受信し、受信したリクエストフレームの送信元ポート番号を変数Ｐに設定し、サーバ１８の総数（＝４）を変数Ｎに設定し、自サーバの番号（＝１）を変数ｎに設定し、故障サーバの番号（＝２）を変数ｆに設定する（ステップ１７１）。
【０１１３】
サーバ１番は、送信元ポート番号の変数Ｐについて、サーバ１８の総数である変数Ｎ（＝４）の剰余算を行い、その結果を変数Ｘに設定し（ステップ１７２）、変数Ｘの値が自サーバ番号の変数ｎの値（＝１）と一致すると判定した場合（ステップ１７３）には自サーバ宛のリクエストとして受け付けて処理を行う（ステップ１７４）。
【０１１４】
サーバ１番は、ステップ１７３で変数Ｘの値が自サーバ番号の変数ｎの値と一致しないと判定した場合、故障したサーバ２番宛てのリクエストフレームであるか否かの判定のため、変数Ｘの値と故障サーバ番号である変数ｆの値（＝２）との一致判定を行い（ステップ１７５）、一致しないと判定した場合は、他サーバ宛のリクエストとして廃棄する(ステップ１７６)。
【０１１５】
サーバ１番は、ステップ１７５で変数Ｘの値が故障サーバ番号である変数ｆの値と一致すると判定した場合、さらに自サーバで代行処理するか否かの判定を行うため、以下で説明する変数Ｙと変数Ｚの値を計算する。
【０１１６】
サーバ１番は変数Ｙの値を計算する（ステップ１７７）。ステップ１７７の計算式中の（Ｐ−ｆ）／Ｎの項は、ステップ１７５の判定においてＰとＮの剰余算がｆと一致が成立しているため、必ず整数となる。この（Ｐ−ｆ）／Ｎについて、サーバ１８の総数である変数Ｎの値（＝４）から故障サーバの数である１を減じたＮ−１（＝３）の剰余算を行う。この計算の結果、変数Ｙは０、１、２の３値のいずれかの値となる。
【０１１７】
サーバ１番は、自サーバ番号の変数ｎの値が故障サーバ番号の変数ｆの値より小さいか判定する（ステップ１７８）。サーバ１番の場合は変数ｎの値（＝１）が故障サーバ番号の変数ｆの値（＝２）より小さいため、ステップ１７９へ進み、変数ｎの値である１を変数Ｚに設定する。なお、ステップ１７８で、変数ｎの値が変数ｆの値より小さくないと判定した場合、変数ｎの値から１を減じた値を変数Ｚに設定する（ステップ１８０）。
【０１１８】
サーバ１番は、変数Ｙの値と変数Ｚの値が一致するかを判定し（ステップ１８１）、一致すると判定した場合は、代行処理リクエストとして受け付けて処理を行い（ステップ１８２）、一致しないと判定した場合は、他サーバが代行処理を行うリクエストとして廃棄する（ステップ１８３）ことで、代行処理を３つのサーバ１８へ分散することが可能となる。
【０１１９】
以上では、サーバ１番を主に説明したが、サーバ０番とサーバ３番も同じフローであり、サーバ０番では変数ｎの値が０、変数Ｚの値が０となり、サーバ３番では変数ｎの値が３、変数Ｚの値が２となる。なお、図１５には、ルータ１３、アドレス変換部１４、レイヤ２スイッチ１５の例を示したが、フラッディング転送のための構成は、アドレス変換部１１１やＯｐｅｎＦｌｏｗスイッチ１３２であってもよい。
【０１２０】
以上で説明したように、複数のサーバ１８が共通にフレームを受信することが可能となり、各サーバ１８が選別処理を行うことで、複数のサーバ１８で分散処理を行うことが可能になるとともに、故障サーバの代わりに代行処理を行うことも可能になる。また、分散処理で分散する負荷の比率も制御することが可能となる。
【符号の説明】
【０１２１】
１１    クライアント端末
１２    ネットワーク
１３    ルータ
１４    アドレス変換部
１５    レイヤ２スイッチ
１６    サーバ群
１７    負荷分散システム
【図１】
2017182138.tif 000003
【図２】
2017182138.tif 000004
【図３】
2017182138.tif 000005
【図４】
2017182138.tif 000006
【図５】
2017182138.tif 000007
【図６】
2017182138.tif 000008
【図７】
2017182138.tif 000009
【図８】
2017182138.tif 000010
【図９Ａ】
2017182138.tif 000011
【図９Ｂ】
2017182138.tif 000012
【図９Ｃ】
2017182138.tif 000013
【図１０】
2017182138.tif 000014
【図１１】
2017182138.tif 000015
【図１２】
2017182138.tif 000016
【図１３】
2017182138.tif 000017
【図１４】
2017182138.tif 000018
【図１５】
2017182138.tif 000019
【図１６】
2017182138.tif 000020
【図１７】
2017182138.tif 000021