電子書籍の厳選無料作品が豊富!

SE修行中の者です。「Webクライアント-負荷分散装置(以下、LB)-Webサーバー」という構成を考えています。

このとき、サーバーと同じネットワークセグメント内のクライアントからHTTPリクエストが発行された場合、「行き」パケットはLBを経由しても「戻り」パケットはLBを経由せずに直接クライアントに戻ってしまうのではないかと思います(別セグメントのクライアントならば、サーバー側のデフォルトゲートウェイをLBのIPにしておけば「戻り」もLBを通ってくれると思いますが。)

そうなると、TCPのコネクションが確立できない、すなわち通信ができない、ということになるような気がするのです。

このような問題を回避するにはどのようにしたらよいものでしょうか?(ちなみに負荷分散装置はAlteon Application Switchというものらしいです)

A 回答 (4件)

 Alteon Application Switchなるものはさっぱり知らないので申し訳ないが、どのレイヤで分散するかやね。


 例えばゲートウェイタイプなら同一セグメントだろうとLBがなんとかしてくれる。ルータタイプだとそもそもクライアントとサーバが同一セグメントには無いし、仮りにあったとしたらそれはネットワーク設計者がアホすぎる。

 で、本当にそんな状況があったら確かに通信できんよなぁ、でも実際はどうなんやろと思い、「しょぼいルータタイプ(つまり単なる分散DNAT)でクライアントと実サーバが同一セグメントにあったらどうなるか」を試してみた。
 果たしてサーバの80番はSYN_RECVの状態で止まったままだった。面白い事に、ブラウザでF5を連打したらサーバ側の古いSYN_RECVはTIME_WAITに変わった。同じIPアドレスの別ポートからSYNを受け取ると安全の為に古いソケットを破棄するのかも知れない。ちなみにサーバはLinux 2.4.31とApache2.0.??、LBはLinux 2.6.11、クライアントはWindows XP SP2のIE6SP1。

 で、もしそのAASとやらがルータタイプだった場合は、回避策としてはNAPTするしか無いよね。LBで。ただ、その場合負荷を分散させるLBに負荷がかからないか心配。この辺は#1さんのおっしゃる通り、ベンダを呼びつけてデモをさせましょう。
    • good
    • 0
この回答へのお礼

わざわざ確認までして頂いて、どうもありがとうございます。やはり「SYN_RECV」で止まってしまうんですね。。。
実現可能/不可能(これが第一ですが)以外にも「LBの負荷」という観点、おっしゃるとおりだと思います。

お礼日時:2006/02/13 19:36

”[Client]---[AAS]---[Web Server]”


と言うことで、かつ
”AAS のPort にClient とServer が接続されている”
と言うことであれば。
”Clientへの「戻り」はAASを経由せずに直で行くのではないか?”
という事はありえません。

AAS の配下にL2SW があって、そのL2SW にClient とServer が接続されていれば、
話は別ですが・・・。

Web Server から見たSrcIP の如何に関わらず、
AAS のPort に接続されており、AAS にコネクションテーブルがクリエイトされていれば、
必ずそのコネクションテーブルによって通信が処理されます。

SLB の行為が、必ずIP アドレスの変換が伴われると言うわけではありません。

たとえ別セグメントであっても、NAT をしない限りSrcIP が変換されることはありえません。
純粋なルーティング処理を行うSLB は、
SrcMAC アドレスが、Server が接続されたAAS のPort のMAC アドレスに変換するだけで、
IP アドレスの変換処理は行いません。

TCP コネクションの問題を考えるのであれば、
・Client のコネクションテーブル
・Server のコネクションテーブル
そしてL7 でAAS が動作していれば、AAS のコネクションテーブル
この3つが一致しなければ、確かに通信はおかしいと言えます。

検証したわけではないので、あまり強くは断言できませんが、
Server 側でTCPDump などをかけて、
AAS 経由で流れてきたパケットのMAC アドレスなどを確認してみてください。
    • good
    • 0
この回答へのお礼

そうですね。私のほうも実体験なしの想像レベルなので、実機で検証して確認したいと思います。どうもありがとうございました。

お礼日時:2006/02/16 11:13

こんばんは


構成はClient とWeb Server の通信線上に、AAS を介しているような構成なのでしょうか?

例えば、[Client]---[AAS]---[Web Server]や
[Client]---[L2SW]---[AAS]---[Web Server]といった構成でしょうか?

このような構成で多くとられる手法としては、
Virtual Server としてAAS のアドレスにアクセスし、
実際のWeb Server に転送するような方法です。

たとえば、以下のような構成となります。

★[192.168.0.1]---●[192.168.0.10]---◎[192.168.0.100]

★Client、●AAS のVirtual Server Address、◎Real Web Server

この構成で、Client ではAAS の●のアドレスを宛先として指定します。
AAS ではこの●のアドレスは自動的に◎に転送します。
そして、実際のWeb コンテンツは、◎である Real Web Server から提供されます。

以上のようなケースであれば、必ずAAS を介した通信が行われるため、
懸念されているセッションの問題からはフリーとなります。

また、設定によっては、L7(URI)やMAC アドレスでのSLB も可能です。

その通信がAAS を介して通信されているかを確認するには、
CLI やTelnet から”/info/slb/sess/dump”などで、
セッションが記録されているか確認してください。
※この項目で表示されるのは。全セッションのDump 情報です。
    • good
    • 0
この回答へのお礼

イメージは「[Client]---[AAS]---[Web Server]」です。
このときのAASの振る舞いはhttp://www.atmarkit.co.jp/fnetwork/rensai/lb01/l …にあるような感じかなと認識してますが、AASがSrcIPアドレスを書き換えず、そのSrcがWeb Serverにとって同一ネットワークセグメント内だと判断されると、Clientへの「戻り」はAASを経由せずに直で行くのではないか?という気がするのですが・・・(#2で調査していただいた結果もそれを示しているのかな、という気がします)。

お礼日時:2006/02/13 20:07

Alteon は触ったことがありませんが、


通常は、LBをルータみたいに使うというか、
Webサーバ(複数)を別セグメントに置いて、
クライアントはすべてLBを通してアクセスさせるのがセオリーですが、
ClientNATを使ってクライアントもWebサーバとLBを同一セグメントに置く構成も可能でした(別機種の話)。

詳細は、LBのサポート元に問い合わせてみるといいと思います。
当方では、購入前にLB実機を借用して、サポートのヒトに根掘り葉掘り聞きながら、実環境でいろいろ検証しました。
安くないモノなので、その辺のサポート体制はしっかりしていると思いますよ。
    • good
    • 0
この回答へのお礼

ありがとうございます。
その後もいろいろ調べてたらAlteonでは「PIP(Proxy IP Addresses)」という機能があって、もしかしたらそれでいけるのかな・・・なんて思ってます。
ただ、やはり該当製品のサポート窓口へ聞くのが一番ですよね(じつは直接的なパスを持っている人に「そんなのムリムリ」といわれてこちらでご意見を聞いた次第なのですが、なんとかしたいとおもいます)。

お礼日時:2006/02/13 19:27

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!