会社では久々に、ロードバランサのDSR(Direct Server Return）について話題になりました。クライアントからのリクエストパケットはロードバランサを通って、戻りパケットはロードバランサを介さずにクライアントに戻る、という方式です。
こちらについても少し調べてみました。http://d.hatena.ne.jp/yamaz/20060817
http://nosa.cocolog-nifty.com/sanonosa/2004/11/l4dsr.html などがわかりやすいかな、と思います。
当然なのですが、L2/L3スイッチなどと比べると、処理しなくてはいけないことが多い分、ロードバランサ（アプリケーションスイッチ）はどうしてもスループットが遅くなります。数Gbpsのスループットのバランサだと1000万超える場合もありますしね・・・。Webサイトの中でもストリーミング通信など、戻りのパケット量が極端に多いような場合には、比較的低スペックなバランサでも高いスペックが得られます。そういえば、以前読んだ記事だと、けっこうメジャーなオンラインゲームのサイトでもこの方式を採用している、という話を聞いたことがあります。単純な振り分けを高速で行ないたい、という場合には非常に有効な方式かと思います。LVSだとサポートが得られないという問題はありますが、確かにLVSのようなフリーのソフトウェアバランサでも高スペックが得られそうです。
けっこうわかりにくいところではあるのですが、バランサでのパケット処理としては「ロードバランサからサーバへのパケットは、宛先はバランサの仮想IPのままで、宛先MACアドレスのみ実サーバのアドレスを使います。サーバにはループバックインターフェイスの設定をしているので、サーバからの戻り通信は送信元IPが仮想IPとなります。「サーバからだから送信元はサーバの実IPじゃないの？」と思われるかもしれませんが、そうなると往復のIPパケットで整合性がとれないため、通信は成り立ちません。
上記のとおり、サーバから「送信元：仮想IP」のレスポンスを返すためには、サーバにループバックの設定が必要です。この部分がわかりづらいのが１つのデメリットかもしれません。Windowsに関してはhttp://d.hatena.ne.jp/yoshifumi1975/20090316/p2 http://nosa.cocolog-nifty.com/sanonosa/2006/03/windows_serverd_14b5.html などに参考となる情報がありました。
Linuxの場合にはループバックの設定だけでなく、「仮想IPあてのARPには応答しない」という設定も必要になります。Windowsの場合にはもともと応答しないようですが、Linuxの場合にはそのままにしておくとループバックインターフェイスに設定した仮想IPあてのARPにも応答してしまうので、「クライアントが実サーバのMACアドレスを覚えてしまい、サーバに直接接続されるので負荷分散にならない」という現象は起きえますね。そのための設定がカーネルバージョンごとに異なるところもやっかいです。そのあたりの情報はhttp://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html
にあります。
それ以外に考えられることとしては、往復のパケットの送信元/宛先IPの整合性はとれますが、送信元/宛先MACアドレスに関しては対称ではありません。行きの宛先MACはロードバランサのIPですが、戻りのパケットの送信元MACはサーバのMACアドレスです。L2層での非対称に関しては基本的には問題がないはずなのですが、まれに「上位のL3スイッチがサーバのMACアドレスを学習してしまう」とか「ファイアウォールで不正な通信としてはじかれてしまう」ことがあるようです。L3スイッチもファイアウォールもこういう動きをするのは好ましくないはずなのですが、DSRに限らずMACアドレスが非対称な場合にはたまに聞く現象です。この場合、その装置にはロードバランサのMACアドレスを静的に登録することで解決する場合もあるようです。
あと、この方式の場合には、最初のパケット（TCPSynなど）が来た時点で振り分けをしなくてはいけないため、HTTPのGetパケットの文字列などをもとにして振り分けることはできません。この場合にはロードバランサでTCP3Wayハンドシェークを肩代わりして、HTTP Getがきた時点で振り分け先のサーバを決定しなくてはいけません。最初のパケットで振り分けなくてはいけないDSRではどうしても無理なわけです。
一回、「HTTPGetのパケットの中身を書き換えてサーバに渡してほしい」みたいな要件も聞いたことがあります。多分、ロードバランサの中でも出来るものは限られてくるとは思いますが、そもそもDSR構成使っているのであればどのロードバランサ使ってても上記と同じ理由で不可能、ということになります。このあたりもTCP/IPわかってない方が相手だとけっこう理解されにくい部分です。
他には、「ロードバランサとサーバは必ず同セグメントにないといけない（パケットの処理上、どロードバランサ→サーバの通信についてはどうしてもセグメントを超えられない）」というのもありますね。
まあ、「DSRでなくてもいいけど、ネットワーク構成変えたくないからワンアーム接続したい」という場合には、サーバからの戻りパケットが必ずロードバランサを通るようにサーバのルーティングテーブルいじるか、ロードバランサからサーバに送るパケットの送信元をロードバランサのIPにNATして、パケットがロードバランサに戻れるようにすればよい、ということになりますね。もちろん「ハードスペック以上のスループットを出す」という目的からは外れますが、これはこれでたまに見かける構成ではあります。特に送信元IPをNATする構成の場合には、サーバが別セグメント、極端な話、インターネットを介して別の場所にあっても負荷分散可能、というメリットはあります。
どのような構成をとるにしても、やはり「適材適所」が大切ですね。
この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)
