LVSの高負荷対策 その3 〜drop entryのサービスへの影響について〜
前回のおさらい
詳しくは前回の記事を見ていただきたいのですが、簡単にまとめると次のようになります。
- drop entryは、IPVSのエントリをランダムに削除する機能。
- SYN_RECV状態とSYNACK状態のエントリについては、1秒おきにIPVSのコネクションハッシュテーブルからランダムに選んだ範囲(全体の32分の1)をスキャンし、その中のエントリを削除する。
- ESTABLISHED状態のエントリについては、「最後のパケットが届いてから60秒以上経過」かつ「最初のパケットが届いてからの受信パケットの合計数が8以下」のエントリのみ削除の対象とする。
- 空きメモリのサイズが設定した閾値を下回ったときに、自動でdrop entryを有効にすることが可能。
- 閾値を大きくすれば、少ないエントリ数でもdrop entryが有効になるようになりLVSの耐性は増すが、その分正規のサービス利用者の通信にも影響が出やすくなる。
前回、『drop entry有効時には、IPVSを経由するどの接続もエントリ削除の影響を受ける可能性がありますが、ロードバランサが落ちてサービス停止してしまうよりはずっと良いのではないか』と締めくくりましたが、実際にどれだけ正規の通信に影響を与えるのか気になります。 drop entryが有効になった時のサービスへの影響の大きさも、閾値を決めるための判断材料として知っておきたかったため、検証環境で調査してみました。
調査
まず、ESTABLISHED状態のエントリについてですが、一般的なWebアプリの通信では、「最後のパケットが届いてから60秒以上経過」かつ「最初のパケットが届いてからの受信パケットの合計数が8以下」となるような(正常な)通信は無いと判断し、調査の対象にしていません。 サービスへの影響が考えられるのは、SYN_RECV状態のエントリが削除されるときのみ(※)なので、その割合を測定しました。 (※KLabではDSR構成にしており、SYNACK状態にはならないためです。以降、DSR構成での調査の紹介になります。) LVS経由でWebサーバと通信する場合、SYN_RECV状態のエントリが削除されると、WebサーバからのSYN,ACKは返ってきますが、クライアントからのACKがWebサーバに届かなくなり、お互いに再送を繰り返し、最終的にtimeoutします。 なので、指定した回数のhttpリクエストを行ってtimeoutになった回数をカウントするスクリプトを作成して、エントリ削除の回数を測りました。 LVSでは、/proc/sys/net/ipv4/vs/drop_entry に3を設定し、drop entry機能を常に有効にしています。検証環境内で、次の図の構成で測定を行いました。
この場合、何度スクリプトを実行してもエントリは削除されず、timeoutは発生しませんでした。
これは、測定用サーバとLVSがネットワーク的に非常に近く、図の�◆銑Δ隆屬僚衢彁�間が0.3ms程度だったため、drop entryの処理に引っかからなかったためと考えられます。
SYN_RECV状態の時間が短い方が、drop entry機能で削除されにくくなることを説明するため、イメージ図1,2を作成しました。
図内の矢印はIPVSのコネクションハッシュテーブル上に存在するSYN_RECV状態のエントリを表し、矢印の長さがSYN_RECV状態である時間です。 また、1秒おきに実行されるdrop entry機能のスキャンと削除の処理を、青の長方形で表しました。 すると、この長方形と重なった矢印(エントリ)が、drop entryで削除されると考えることができます。
図2は、矢印の長さだけを変更したもので、図1の半分にしています。SYN_RECV状態が短いほど、drop entryの処理に引っかかりにくく、削除されにくいことがイメージできると思います。 それでは次に、実際に測定してみます。
遅延を考慮した測定
実際の通信では、パケットは外部の回線を流れるのでその分遅延します。遅延が大きければエントリがSYN_RECV状態である時間が長くなるため、削除される割合が多くなると予想されます。
そこで、測定用サーバ上でtcコマンドを使用して、外部と通信する際に発生する遅延を検証環境内で再現した上で、再度測定してみました。
手元のスマホからLVSへpingすると、往復に100msほどかかっていたので、
50ms,100ms,200msの3通りの遅延時間で、削除されるエントリ数を確認しました。
その結果が次のようになります。
| tcで指定した遅延時間 | 50ms | 100ms | 200ms |
|---|---|---|---|
| エントリ削除回数 / 全リクエスト数 | 37回 / 32000回 | 79回 / 32000回 | 201回 / 32000回 |
| エントリ削除された割合 | 0.115625 % | 0.246875 % | 0.628125 % |
どの遅延の場合もおよそ、80 Requests per Second (計測時間400秒)となるように測定しています。 予想通り、遅延時間が大きいほど削除されるエントリ数が多くなりました。 念のため前回の記事と同様にhpingを使用して、エントリ数が異常に増えた場合のtimeoutの割合も調べましたが、結果はほぼ変わりませんでした。例えば、hpingでSYNパケットを350kppsの頻度で送りつけると、LVSの総エントリ数が1300万程度になりました。その状態で100ms遅延させた測定用サーバから上と同じ測定を行った結果、timeout数は70回(およそ0.22%)でした。 ただし、ppsが大きく、途中経路やLVS,Webサーバでパケロスが発生してしまうほどの場合は、パケットの再送により遅延が大きくなり、削除されるエントリ数が上の結果より多くなると思いますのでご注意ください。
まとめ
調査の結果、通信の遅延時間がエントリ削除の割合に関係していることがわかりました。 遅延はクライアントの通信環境やネットワーク的な距離などにも依るので一概には言えません。 しかし、200ms以下の遅延なら削除される割合は1%に満たなかったので、SYNパケットが大量に到来し始めたら早い段階でdrop entryを有効にし、LVSの耐性を上げることを優先して良いのではないでしょうか。
