ウェブ広告のインフラについて(第2回) 基本構成

まだ二回なのであまり深く突っ込んだ話はしません。

今回は自社DCのNW構成と、その際の注意していることなどを書いていこうと思います。

下の図をご覧ください。

実際はもう少し複雑ですが、LVS-DR構成を利用したシンプルな作りになっています。
入社直後チューニングノウハウがない時期にLVS-NATで運用していましたが、いきなり負荷でLVSがつぶされた経緯があり、現在と比べてかなり小さい規模でしたが思い切ってLVS-DRに切り替えました。
今でもその流れを継いでいます。

このように外から入ってくるギガ線のトラフィックをすべてLVSで受けて、内部のLVSでnginxから各APサーバに分散し、DRでデフォルトゲートウェイのVyattaから投げ返しています。

LVS-DRを表のLBに使ってるとかマジキチと自分でも思うんですが、使い始めると案外なんとかなってしまうもので、高い箱物をアテにしていないので、予算とか読めない事業予測にとらわれないスケーラブル()なインフラが結果的にできてしまいました。
CPUはいい仕事してくれます。

FWどうしてんだよ!とかは次回以降で!

しかしLVS-DR構成もデメリットとまでは言いませんが、運用に工夫が必要です。

スイッチの配置と挙動を考慮する

何も考えずに配線すると簡単にUnicastがFloodingします。
こちらのエントリーを参考にしてください。
2ラックでサーバを両ラックに分割して配置など特に要注意です。
結局スイッチまたぎの問題は解決できず、pingを定期的に実行するサーバを運用しています。

また以下の図のようにスイッチ間のトラフィックも偏りがでないように、実際はL2コアスイッチ的なものを一台はさんで配置しています。

ブロードキャストドメインの制限がある

LVS-DRはブロードキャストドメインの制限のために、スケールに限界があります。
現在は1ブロードキャストドメインにおとなしく納まる台数ですが、今後はもう1セットLVSを用意してDNSで分散するか、LVS-DRを多段にするか、そもそもLVS-DRを捨てるか等考えている最中です。
L2 over L3。。。おっと誰かきたようだ。

リアルサーバでVIPを受けるためにループバックインターフェイスを使っている

リアルサーバでVIPの通信でするためにiptablesを使っている場合が多いと思いますが、数多くある配信サーバでconntrack tableの管理をしたくないため、ループバックインターフェイスを使っています。
うっかりarp_ignore等重要な設定を忘れたりしないために、puppetで管理をしています。
manifestはgithubで公開しているので参考にしてください。

目次の前に書いてある内容程度ですが今日はこの辺で。
細々とやるのが長く続ける秘訣ですね。

次回はLVSとVyattaのチューニングについて書こうと思います。

コメントを残す

メールアドレスが公開されることはありません。


*