ぢろーらものおもちゃ箱:引っ越し後

写真付きで日記や趣味を書くならgooブログ

負荷分散装置:DSR(Direct Server Return)方式

2010-11-17 19:59:45 | IT(ネットワーク&セキュリティ)

会社では久々に、ロードバランサの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」のレスポンスを返すためには、サーバにループバックの設定が必要です。この部分がわかりづらいのが1つのデメリットかもしれません。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する構成の場合には、サーバが別セグメント、極端な話、インターネットを介して別の場所にあっても負荷分散可能、というメリットはあります。

どのような構成をとるにしても、やはり「適材適所」が大切ですね。


この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

ブログランキング・にほんブログ村へ

最新の画像もっと見る

コメントを投稿