最近、何でか色々とLVS絡みの話でちょっとあったり、少し思うところがあったりして。
自分はLinuxをLoadBalancer、ルータとかforwardingする装置として使う場合、必ずppsについて考える。
まぁLVSやiptablesを使えばそういったことが出来るのは当然だから良いとして、問題となるのはパケットの流量について。
多分、測定してみれば分ると思うけど、LVSやらforwardingをさせるとき、どんなにパケットを流してもある上限で頭打ちになると思われ。帯域依存じゃなく、小さいパケットを大量に投げるとすぐこういう現象は起きる。
そのとき、CPUはガラガラ＆余裕しゃくしゃくなはず。もちろん、サーバの帯域もガラガラなのに・・・
通常のシステムの場合、ある程度負荷を与えると、性能限界を迎えてその時のCPUやらLoadAvgは高いものになっている場合が多い。
そういったのは過負荷な状態で、負荷測定の段階でシステム時間（スループットとか）をちゃんと測定して、その上で過負荷な状態の試験を行ったりすると思われ。
少し話は違うけど、よく負荷テストで何をすれば？と聞かれたりするんだけど、システムの近い場所からシステム時間（スループット）を測定して、余裕があればネットワークの別経路からLBを通した試験（ネットワーク時間＋システム時間）のスループットを測定するのを、並列度を変えたりして行えばOKと思っている。（もちろん、その時にvmstatの状況は取得しておくことは必須で）
その上で、シナリオや過負荷な状態の試験を行ったりね。
で、LVSやらforwardingをするLinuxサーバで、どんなにパケットを流しても、ある上限で頭打ちになるのは、
1.SWのバックプレーン
2.サーバのNIC
のどちらかが飽和して、それ以上パケットが捌けない状態になっている可能性が高いと経験的には思う。
1については、例えばCat2960S-24T-Sだと38.7Mppsらしい。（Ciscoの
データシートを見ると)
つまり、Cat2960S-24T-Sにつなげた機器の場合、それ以上パケットを捌けることが出来ない。
普通はある程度大きいMTUで、パケットも大きいサイズでガンガン流れるけど、ショートパケットが大量に流れる場合は、ちゃんとSWの性能も確かめる必要がある。
次に2の場合。LVSやらforwardingさせるサーバで。
これは、実際にサーバに搭載されているNICとPIC(とかの)バスに依存するから、実機でちゃんと測定してみないと分らない。
大抵はサーバのCPUがネックになる以前に、NICの方で頭打ちになって、現在時点のかなり良いスペックのマシンでも数Mppsが上限じゃないかと思われ。
TCPで通信する場合は、SYN/ACK/FIN...とか小さいパケットもちょろちょろと流れるから、サーバのppsを測定してどのくらい捌くことが出来るのか？を知っておくことは何気に大切だったりする。
例えば、5kppsしか捌けないサーバに、1万本のTCPを並列に接続断させて通信を行わせようとすることは、かなりドキドキする。（実際、同時並列に1万パケットが来る可能性は薄いかも知れないけど、それでもやらないよねｗｗｗ）
単純に結構良い複数CPUのマシンでLVSを組んで「やったー、楽勝ロードバランサーだぜ♪」というのも、まぁ確かにアリっちゃアリなんだけど、負荷分散をさせるとき、何でもLVSでパケットを分散させてOKだぜ！！っていう訳じゃないからねー。
もちろん、LVSだけじゃなく上記の例みたいに、普通のシステム・サーバで利用した場合も同じことが言えるから、サーバも一つのネットワーク機器としての観点も持っても良いと思われ。
Webのシステムだとあんまりショートパケットが大量に来るってことは少ないから、そんなにppsが問題になることも無いのかも知れない。けど、実際にサーバにパケットを大量に投げてL2/L3の処理を行わせると、「あれれ？CPUは余裕なのに何でこれ以上流れないの？帯域もまだ全然余裕なのに？」って不思議な現象に遭遇することがあるかも知れないから、そういう時はppsもちょっとは考えてみても良いかも。（帯域が余裕でも、ショートパケットが大量に来る場合は、帯域じゃなくppsで頭打ちになっているのかも知れないから。大きいパケットが多い場合は、サーバのppsはあんまり問題にならないはず。）
あんまりこういうことって見たり、聞かないんだけど、常識だからなのかなぁ・・・
まぁ、何となく少し思ったこと。
Recent Comments