多忙と現実逃避により間が開いてしまいましたが4回目です。
下書きの日付が5月付ですね・・・。

さて今回はLVSのチューニングですが、NICやドライバ廻りは前回と同じです。
IPVSのコネクションハッシュテーブルのチューニングが主な内容です。

netfilterのコネクションテーブルと同様にIPVSもコネクションテーブルをハッシュ化して高速に処理しています。
管理しているコネクションはipvsadm -Lncなどのコマンドで一覧が見られます。
この情報を元にすべての通信のコネクションオープンから、クローズまたはタイムアウトまでの処理が行われています。

デフォルト値だとこのハッシュテーブルが少なすぎるため、ハッシュの衝突が発生しどの程度かは未検証ですがパフォーマンスが低下します。
デフォルトだと大体10万コネクション程度が目安のようです。

衝突と聞いてどきっとするかもしれませんが、コネクションテーブルハッシュはチェイニングスキームを使用しているため、ハッシュが衝突したからといって直ちに影響はありません。
また単純にハッシュテーブルを広げるだけで衝突する確率を大幅に下げることができます。

ハッシュテーブルサイズを大きくするためにカーネルを再構築する必要があります。
昔のLVSを使うためにカーネルを再構築していた時代がありましたね・・・。
自社では運悪く入社早々カーネルのリビルドを押し付けた押し付けられた人がいました。

対象のメニューは以下のとおりです。
適切な値はハッシュテーブルは1コネクションあたり128byte、ハッシュエントリは8byteのメモリを要するとドキュメントにはありますので、必要なメモリ量が逆算できます。

Networking Support ->
Networking Options ->
[*] Network packet filtering framework (Netfilter) ->
IP virtual server support ->
(20) IPVS connection table size (the Nth power of 2)

また以下のようにnetfilterと同様にタイムアウトを短くすることでコネクション数を削減することができます。

ipvsadm --set tcp tcpfin udp(TTL/sec)

LVS自体シンプルにできているのでチューニングすべき箇所はあまりありません。
自身で一番こまったのは、この3つです（一つじゃない）。

• weightを変えてreloadしてもweightが変わらないため野良パッチをあてたdebを作った
• スイッチ跨ぎで発生するunicast floodingを美しく解決する方法がなく悩まされている
• DRだとL2前提になりNW設計に制限がでる

自社ではDRを主に利用していますが、入り口と出口が分けられるという特徴を利用して、L3スイッチの負荷分散や、トラフィックのバランスが調整できたりと以外なところでも活用しています。

次回はLinuxのTCP再送アルゴリズムの実装と広告配信の相性の悪さについてです。

秋ぐらいに・・・。