Я использую два сервера с высоким трафиком: один с ubuntu 12.04 (linux 3.2.0-69-generic) и один с ubuntu 14.04 (linux 3.13.0-52-generic). Сейчас я пытаюсь обезопасить и то, и другое. У них обоих очень похожие аппаратные ресурсы (одинаковое количество CPUS, но 12.04 имеет только 8 ГБ ОЗУ, тогда как 14.04 получил 16 ГБ).
Я хотел включить брандмауэр 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.2019.
Поэтому я попытался найти способ установить этот размер и нашел параметр thash_entries посмотреть здесь для объяснения). Однако я не могу установить его с помощью sysctl.
Итак, вот мои вопросы:
Заранее благодарим за любую помощь и не стесняйтесь спрашивать меня, нужна ли вам дополнительная помощь.
P.S. Я больше разработчик, чем системный эксперт, поэтому буду признателен за подробный ответ :)
Настройка ядра Linux для обеспечения высокой пропускной способности сети - это искусство, основанное на балансе.
Увеличение таблицы отслеживания подключений - это нормально, но это означает, что потенциально может использоваться больше сокетов, а это, в свою очередь, означает, что системе требуется больше файловых дескрипторов, и колесо продолжает движение ...
В вашем случае я бы начал со следующих настроек ядра:
net.core.somaxconn
и
fs.file-max
Первый определяет количество открытых сокетов, которое будет поддерживать ядро. Второй используется для установки количества используемых файловых дескрипторов, которые будут поддерживаться ядром.
Затем есть бэклог SYN, который можно дополнительно настроить.
net.ipv4.tcp_max_syn_backlog
Устанавливает количество соединений, которые могут ожидать ACK от вашего сервера.
net.ipv4.tcp_syncookies
Для работы SYN Backlog необходимо включить файлы cookie TCP SYN.
Наконец, есть также некоторые настройки, которые можно сделать, например, включить повторное использование соединения TIME_WAIT.
net.ipv4.tcp_tw_reuse
Это потенциально может уменьшить количество «новых» сокетов, которые будут открываться при получении всплеска.
Это только верхушка айсберга, мой опыт работы с системами Linux / Unix большого объема показывает, что вы будете настраивать ее в течение пары месяцев, прежде чем получите правильный баланс.
Убедитесь, что вы смотрите на ошибки в /var/log/kern.log
и /var/log/messages
чтобы помочь в дальнейшем устранении неполадок.
Руководство администратора для высокопроизводительных вычислений