このエントリーをはてなブックマークに追加

Category Archives: ネットワーク

見えないトラフィック~Unicast Flooding~

どうも、ishinoy@インフラです。

クラウドサービスを利用していると、VM上のトラフィックはCactiとかで
取得してますが、物理ホストのトラフィックはわからないですよね?

通常はクラウドサービス会社さんに監視してもらうと思うのですが、
先日、サーバをクラスタ移動したらやけにトラフィック量が多くなっているらしく、
調査したところUnicastFloodingが発生していたというお話しです。
 
UnicastFloodingとは?
 ユニキャストパケットがブロードキャストされ、回線を逼迫させてしまう現象
 
ちょうど、先日参加したセミナーでも、某大手ポータルサイト様の環境で
同様のことが起き、発表されていました。
 
 
えーと、まずは図を見ていただいたほうがわかりやすいですね!
(↓クリックすると拡大)

unicastflooding_1

WebサーバからDBサーバへ通信する際に、
LVSの負荷軽減のためにDR構成にすることは良くあると思うのですが、
DR構成では非対称ルーティングとなります。(行きと帰りの道が異なる)

WebサーバとDBサーバは直接通信することは無いので、
スイッチ02でWebサーバのMACアドレスは学習されることはなく、
スイッチの仕様として、そのようなパケットは全ポートへ転送してしまうのです。
(スイッチ01,02はスタック構成ではない)

もちろん、Webサーバにもパケットは届くので、
サービスとしては一見、問題なく処理しております。

ちなみに、LVSサーバとDBサーバが逆の場合は発生しません。

WebサーバとDBサーバは同じスイッチに接続している上に、
LVSサーバとDBサーバはヘルスチェックで定期的に通信しているので、
スイッチが学習するのです。
 
 
なるほどですね~
 
 
考えられる対策ですが、実はスマートな方法が見つからず、
サーバ規模と運用面を考えて、下記の案2)としています。
 
 
 案1) WebサーバとDBサーバを同じスイッチ配下に置く
    ⇒どこのスイッチ(=クラスタ)にサーバがあるか管理する必要がある上に、
     クラスタ障害時の冗長性も考えると、複雑怪奇です…

 案2) 定期的にPingを打つ
    ⇒Web/DBサーバ間のみでも良いですが、増減設時の漏れを考えると、
     いっそのことサーバは全てスイッチにPingを打つ仕様の方が
     管理面で楽ですかね…

 案3) LVSのDR構成を止めてNAT構成にする
    ⇒そもそもの主旨とずれますが、LVSに負荷がかかるようになるので、
     負荷分散のためにサーバ増加となりコストアップです…
 
 
 
ふと、前職でMSのNLBとCisco機器の仕様の違いで、
スイッチのMACテーブルが学習されずに
通信ができなかった不具合を思い出したのでした。。。
 
それでは