Балансировку нагрузки на Ubuntu 24.04: пошаговая установка

MAATRIX

Один сервер приложения перестал справляться с потоком запросов, время ответа растёт под пиками, а обновления приходится выкатывать с простоем. Настроить балансировку нагрузки на Ubuntu 24.04 проще, чем кажется: чаще всего хватает того же Nginx. Ниже — пошаговая установка балансировщика с готовыми командами: от подготовки серверов до рабочего пула бэкендов с HTTPS и проверками здоровья.

Шаг 1. Схема и подготовка серверов

Прежде чем перейти к командам, коротко о сути. Балансировщик — это точка входа, которая принимает все запросы и раскидывает их по нескольким одинаковым бэкендам. Снаружи клиент видит один адрес, а за ним прячется пул серверов приложения. Такая схема решает сразу две задачи: увеличивает пропускную способность, потому что запросы делятся между процессами, и повышает отказоустойчивость, потому что при падении одного узла остальные продолжают отвечать. Сигнал, что балансировка действительно нужна, — стабильно высокая загрузка процессора на единственном бэкенде, рост времени ответа под пиками и желание выкатывать обновления без простоя.

Классическая схема балансировки — отдельный небольшой VPS под балансировщик и несколько VPS под бэкенды с одинаковым приложением. Балансировщик нетребователен: 1–2 ядра и 2 ГБ RAM держат большой поток, потому что он только перекладывает запросы. Ресурсы уходят на бэкенды, и их подбирают под приложение.

Бэкенды удобно держать в одной приватной сети, чтобы трафик между балансировщиком и ними не выходил в интернет, а публичный IP с чистой репутацией нужен только балансировщику — на него смотрит домен. Обновите систему на всех узлах:

apt update && apt upgrade -y

Локация здесь важна для минимизации задержек: все узлы лучше держать в одной локации, чтобы между балансировщиком и бэкендами не было трансграничного пинга. Для российской аудитории логична RU-площадка, для зарубежной — US или UK. У MAATRIX можно взять несколько VPS в одной локации с оплатой из России картой или криптой, что удобно для сборки такой связки.

Шаг 2. Проверка доступности бэкендов

Перед настройкой балансировщика убедитесь, что каждый бэкенд реально отвечает по своему адресу и порту. Это избавит от путаницы, когда позже часть узлов окажется вне ротации. С самого балансировщика проверьте каждый узел:

curl -I http://10.0.0.11:3000
curl -I http://10.0.0.12:3000
curl -I http://10.0.0.13:3000

Каждый должен вернуть ответ приложения. Если какой-то узел недоступен, разберитесь с этим до настройки балансировки: причина обычно в том, что приложение слушает только localhost вместо приватного интерфейса, либо порт закрыт внутренним фаерволом. Балансировщик не починит мёртвый бэкенд — он лишь распределяет трафик между работающими.

Шаг 3. Установка Nginx на балансировщик

На узле-балансировщике поставьте Nginx из штатного репозитория Ubuntu 24.04:

apt install nginx -y
systemctl enable --now nginx

Проверьте, что сервис работает:

systemctl status nginx

Nginx здесь выступает балансировщиком уровня приложения (L7): он видит HTTP-запросы, умеет смотреть на URL, заголовки и куки и распределять их по бэкендам осмысленно. Это то, что нужно для веба. Балансировка уровня соединений (L4) для TCP и UDP — отдельная задача, для неё используют другой модуль, но подавляющему большинству сайтов и API нужен именно L7, который мы и настроим.

Шаг 4. Конфиг upstream и распределение

Балансировка описывается блоком upstream со списком бэкендов и обычным proxy_pass на имя группы. Отредактируйте конфиг сайта в /etc/nginx/sites-available/lb.conf:

upstream backend {
    least_conn;
    server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.13:3000 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Здесь выбран метод least_conn — запрос уходит на бэкенд с наименьшим числом активных соединений, что хорошо, когда запросы разной длительности. По умолчанию Nginx использует round-robin (по очереди), а для привязки клиента к серверу есть ip_hash. Выбор метода зависит от вашего приложения: для однотипных быстрых запросов достаточно round-robin, для смеси быстрых и долгих операций точнее распределяет least_conn, а для приложений с сессиями в памяти процесса выручает ip_hash. Не забывайте и про блок проброса заголовков — без X-Real-IP и X-Forwarded-For бэкенды увидят у всех посетителей один адрес балансировщика, и сломаются геолокация, ограничение частоты и баны по IP. Включите сайт и примените:

ln -s /etc/nginx/sites-available/lb.conf /etc/nginx/sites-enabled/
rm -f /etc/nginx/sites-enabled/default
nginx -t && systemctl reload nginx

Шаг 5. Веса, резерв и проверки здоровья

Если бэкенды разной мощности, распределяйте нагрузку пропорционально через параметр weight, а аварийный узел помечайте backup — он примет трафик только когда основные недоступны:

upstream backend {
    server 10.0.0.11:3000 weight=3;
    server 10.0.0.12:3000 weight=1;
    server 10.0.0.13:3000 backup;
}

Параметры max_fails и fail_timeout из предыдущего шага включают пассивную проверку здоровья: после трёх неудачных попыток подряд бэкенд на 30 секунд выводится из пула, затем Nginx снова пробует его. Этого достаточно, чтобы упавший узел перестал получать запросы в течение нескольких обращений. Для планового обслуживания сервер удобно выводить вручную, пометив его down в конфиге и перечитав Nginx, — тогда обновление пройдёт незаметно для пользователей. Активные проверки с отдельным health-эндпоинтом доступны в коммерческой версии, но для большинства проектов хватает пассивного механизма плюс внешнего мониторинга.

Шаг 6. HTTPS, сессии и проверка

Терминируйте HTTPS на балансировщике — тогда шифрование настраивается в одном месте, а бэкенды получают уже расшифрованный трафик по приватной сети. Выпустите сертификат через certbot:

apt install certbot python3-certbot-nginx -y
certbot --nginx -d example.com

Отдельно продумайте сессии. Если приложение хранит их в памяти конкретного процесса, round-robin будет разлогинивать пользователей, кидая их на разные бэкенды. Надёжное решение — вынести сессии в общее хранилище вроде Redis, чтобы любой узел знал о любом пользователе; временное — привязать клиента методом ip_hash. Проверьте, что распределение работает, добавив в лог имя апстрима и посмотрев, как раскидываются запросы:

tail -f /var/log/nginx/access.log

Помните, что балансировщик — единая точка отказа, и для критичных систем его дублируют. А ещё, что общая база данных за бэкендами рано или поздно станет узким местом раньше, чем само приложение. Если проект дорос до балансировки, это хороший момент оценить следующий потолок и заранее взять серверы с запасом ресурсов — несколько VPS в одной локации у MAATRIX с оплатой из России картой или криптой собираются в такую связку без лишней возни.

Частые вопросы