背景について
私は、高トラフィックの環境で 2 台のサーバーを実行しています。1 台は Ubuntu 12.04 (linux 3.2.0-69-generic)、もう 1 台は Ubuntu 14.04 (linux 3.13.0-52-generic) です。現在、両方のサーバーをセキュリティ保護しようとしています。両方のサーバーには、非常によく似たハードウェア リソースがあります (CPU の数は同じですが、12.04 のサーバーには 8 GB の RAM しかありませんが、14.04 には 16 GB あります)。
ufw ファイアウォールを有効にしたかったのですが、nf_conntrack テーブルがいっぱいになるという問題が発生しました。基本的にパケットがドロップされていました。
タイムアウトを短くし、テーブル サイズとバケットの数を増やすことで、これらの問題の解決策を見つけました。つまり、
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_max = 196608
net.netfilter.nf_conntrack_buckets = 24576
これらの値は適切に更新され、再起動後も保持されます。(このブログ) また、conntrack_count がデフォルト値よりかなり高くなっているのも確認しているので、両方のサーバーでこれが機能していることは間違いありません。値は制限値をはるかに下回っているので、問題ないと思います。
問題
12.04 サーバーは高負荷でも正常に動作しますが、14.04 ではパケットがドロップされ続け、クライアントのタイムアウトが発生します。現在、14.04 の起動時に、kern.log に次の行が表示されます。
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
12.04 では次のようになります:
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
このテーブルは 14.04 のトラフィック量に対して小さすぎる可能性があるため、これがサーバーがパケットをドロップする原因であると思われます。
そこでこのサイズを設定する方法を探してみたところ、パラメータthash_entriesを見つけました。こちらをご覧くださいただし、sysctl では設定できません。
私の質問は次のとおりです。
- この TCP 接続テーブルが本当に問題の原因なのでしょうか? それとも他の場所を調べるべきでしょうか?
- もしそうなら、どのように設定すれば再起動後も維持されるのでしょうか?
ご協力をよろしくお願いいたします。さらにサポートが必要な場合は、遠慮なくお問い合わせください。
PS 私はシステムの専門家というよりは開発者なので、詳しい回答をいただければ幸いです :)
答え1
高いネットワーク スループットを実現するために Linux カーネルを調整することは、バランスに基づいた技術です。
接続トラッカー テーブルを増やすことは問題ありませんが、より多くのソケットが使用される可能性があることを意味し、これはシステムがより多くのファイル記述子を必要とすることを意味し、車輪は回り続けます...
あなたの場合、次のカーネル設定から始めます。
net.core.somaxconn
そして
fs.file-max
最初のものは、カーネルが維持するオープンソケットの数を決定します。 2 番目は、カーネルによってサポートされる使用されるファイル記述子の数を設定するために使用されます。
さらに調整できる SYN バックログもあります。
net.ipv4.tcp_max_syn_backlog
サーバーからの ACK を待機できる接続の量を設定します。
net.ipv4.tcp_syncookies
SYN バックログを機能させるには、TCP SYN クッキーを有効にする必要があります。
最後に、TIME_WAIT 接続の再利用を有効にするなど、いくつかの調整を行うこともできます。
net.ipv4.tcp_tw_reuse
これにより、スパイクを受け取ったときに開かれる「新しい」ソケットの量が減る可能性があります。
これは氷山の一角に過ぎません。大規模な Linux/Unix システムでの私の経験では、適切なバランスを得るまでに数か月間調整する必要があります。
/var/log/kern.logさらにトラブルシューティングを進めるには、と のエラーを確認してください/var/log/messages。