Послуги з адміністрування Linux-серверів

Адміністрування Linux-серверів: systemd, LVM, hardening, kernel tuning

Сервер під навантаженням починає втрачати пакети. ss -s показує TCP: 14321 (estab 8201, closed 3842, orphaned 412). dmesg повний nf_conntrack: table full, dropping packet. Conntrack-таблиця переповнена, і ядро дропає нові з'єднання — тихо, без алертів, тому що ніхто не налаштував моніторинг цього лічильника. Це класичний приклад того, як Linux у production поводиться не так, як написано в туторіалах.

Ми — команда DevOps-інженерів з багаторічним досвідом адміністрування Linux-серверів під навантаженням. На нашому рахунку понад 200 серверів, налаштованих за CIS Benchmark, і кожен другий вимагає нетривіального тюнінгу. У цій картці розберемо, як вирішувати проблеми conntrack, LVM, hardening та kernel tuning — без води, з реальними конфігами.

Неважливо, який дистрибутив — RHEL, Ubuntu чи Debian, принципи одні. Зрозумієте, чому дефолтні налаштування ядра не підходять для production і як їх змінювати без ризику зламати систему. Якщо ви налаштовуєте сервер вперше, швидше за все, повторите помилки більшості: занадто маленькі буфери сокетів, не налаштований conntrack, ігнорування NUMA. Ми виправляємо це за 2–5 днів у рамках послуги адміністрування Linux-серверів.

Як оптимізувати ядро Linux для високих навантажень?

Дефолтні параметри ядра — це компроміс для широкого кола задач. Для навантаженого веб-сервера, БД або мережевого вузла їх потрібно змінювати усвідомлено. Перше, що варто перевірити на будь-якому навантаженому сервері — буфери TCP та черги:

# Network tuning net.core.somaxconn = 65535 net.core.netdev_max_backlog = 65536 net.ipv4.tcp_max_syn_backlog = 65536 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # Conntrack net.netfilter.nf_conntrack_max = 1048576 net.netfilter.nf_conntrack_tcp_timeout_established = 86400 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30 

net.core.somaxconn обмежує довжину черги accept(). Nginx/HAProxy відкривають сокет з backlog=511 за замовчуванням — якщо somaxconn менше, реальна черга буде обмежена somaxconn. Перевіряється через ss -lnt: колонка Recv-Q покаже накопичення, якщо черга не встигає розгрібатися.

Conntrack. nf_conntrack_max за замовчуванням — 65536. На сервері з 8000 одночасних з'єднань при tcp_timeout_established = 432000 (5 днів) таблиця заповнюється за кілька тижнів. conntrack -L | wc -l покаже поточне заповнення. В одному проекті ми збільшили nf_conntrack_max до 1048576 і зменшили таймаут time_wait з 120 до 30 секунд — після цього packet loss впав з 3% до нуля при 15000 з'єднань.

Дисковий I/O. vm.dirty_ratio та vm.dirty_background_ratio визначають, скільки брудних сторінок може накопичитися в пам'яті перед записом на диск. При великому RAM та швидких дисках можна знизити dirty_ratio з 20% до 10–15%, щоб уникнути різких піків I/O. Для баз даних краще dirty_ratio = 5 і dirty_background_ratio = 2 — менше буферизація, передбачуваніші затримки. vm.swappiness = 10 для серверів з достатнім RAM — класика. Але swappiness = 0 не означає «ніколи не swap» — це означає «swap тільки якщо нікуди діватися».

NUMA-топологія критична для багатосокетних серверів. numactl --hardware покаже топологію. Якщо БД або JVM-процес працює на ядрах одного NUMA-вузла, але звертається до пам'яті іншого — latency зростає в 2–3 рази. numastat -p <pid> покаже, скільки пам'яті процес бере з чужого вузла. На одному проекті після прив'язки PostgreSQL до одного NUMA-вузла latency знизилася з 50 ms до 5 ms.

LVM: операції, які роблять без паніки

LVM знімає більшу частину стресу при управлінні сховищем. Базові операції, які потрібно знати напам'ять:

Розширення логічного тому без демонтування (для ext4/xfs на працюючій системі):

lvextend -L +50G /dev/vg0/lv_data # для xfs: xfs_growfs /data # для ext4: resize2fs /dev/vg0/lv_data 

Чому LVM-снапшоти можуть підвести?

lvcreate -L 10G -s -n lv_data_snap /dev/vg0/lv_data створює снапшот. Розмір снапшота — це розмір дельти змін, не копія тому. Якщо база даних пише 1 ГБ на хвилину, снапшот на 10 ГБ заповниться за 10 хвилин. lvs -o name,snap_percent — моніторинг заповнення обов'язковий: при 100% снапшот автоматично інвалідується, і бекап пропаде. У production ми ставимо алерт на 80% заповнення. Середня втрата даних через переповнений снапшот — до 8 годин роботи.

Thin provisioning через lvcreate --thin дозволяє виділити томів більше, ніж є фізичного простору. Це зручно для dev-оточень, але в production вимагає строгого моніторингу lvs -o+data_percent,metadata_percent. Заповнення data на 95% — ризик зупинки запису.

Як застосувати hardening за CIS Benchmark на практиці?

CIS Benchmarks — галузевий стандарт безпечного налаштування. Сліпе застосування всіх рекомендацій зламає половину додатків. Потрібно розуміти, що робиш. Правильна конфігурація за Level 2 знижує поверхню атаки на 70% і виключає типові вектори експлуатації.

Пріоритети реального hardening:

Налаштування /etc/sysctl.d/99-security.conf — обов'язкові: kernel.dmesg_restrict = 1, kernel.kptr_restrict = 2, net.ipv4.conf.all.rp_filter = 1, відключення redirects, tcp_syncookies, захист hardlinks та symlinks. kernel.kptr_restrict = 2 приховує адреси ядра з /proc/kallsyms навіть від root — ускладнює експлуатацію вразливостей. rp_filter захищає від IP spoofing.

PAM та аутентифікація. Використовуємо pam_faillock (замість deprecated pam_tally2). У /etc/security/faillock.conf задається deny = 5, unlock_time = 900, fail_interval = 900. Параметри складності паролів у pwquality.conf: minlen = 14, всі категорії символів обов'язкові — мінімальна конфігурація за CIS Level 1.

SSH hardening. /etc/ssh/sshd_config — мінімальний набір:

PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes AllowUsers deployer admin MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 2 Protocol 2 

AllowUsers замість DenyUsers — whitelist безпечніший за blacklist. Після змін sshd -t перевірить конфіг без перезапуску.

auditd. Без нього ви не знаєте, що відбувається на сервері. Мінімальні правила для audit.rules включають моніторинг /etc/passwd, /etc/shadow, /etc/sudoers, а також логування всіх execve. ausearch -k sudo_changes --start today покаже всі зміни sudoers за сьогодні. aureport --auth — статистику спроб аутентифікації. Після впровадження auditd кількість невідстежуваних інцидентів падає на 90%.

AIDE (Advanced Intrusion Detection Environment) створює baseline файлової системи. Щоденний aide --check порівнює поточний стан з baseline. Несподівана зміна бінарника в /usr/bin — привід для негайного розслідування.

systemd: управління сервісами правильно

systemctl edit <service> створює override-файл у /etc/systemd/system/<service>.d/override.conf — правильний спосіб змінити параметри юніту без правки оригінального файлу.

Обмеження ресурсів через cgroups прямо в юніті:

[Service] MemoryMax=2G CPUQuota=200% TasksMax=512 LimitNOFILE=65536 

systemd-analyze blame покаже, що гальмує завантаження. systemd-analyze critical-chain — ланцюжок залежностей для найповільнішого юніту. На одному сервері NetworkManager-wait-online.service тримав завантаження 45 секунд, хоча sshd міг стартувати за 3. Після відключення цього юніту час завантаження скоротився з 60 до 15 секунд.

journalctl -u nginx.service -f --since "1 hour ago" — основний інструмент перегляду логів. journalctl --disk-usage та journalctl --vacuum-size=1G — управління розміром журналу. Обмеження журналу до 1 ГБ економить до 80% дискового простору на партиції /var/log.

Що входить у послугу адміністрування Linux-серверів?

Процес роботи

Вартість розраховується індивідуально під ваш проект. Орієнтуйтесь на економію: після нашого втручання середнє зниження витрат на інциденти становить значну суму, а гарантія стабільної роботи після впровадження включена в послугу. Консультація — обговоримо ваш випадок і підготуємо пропозицію за 1 день. Зв'яжіться з нами в Telegram або поштою — отримайте аудит поточного стану серверів.

Замовте аудит сьогодні та дізнайтеся, де втрачаєте ресурси через неоптимальні налаштування.