Как установить и настроить балансировку нагрузки на VPS

MAATRIX

Когда один бэкенд перестаёт справляться с потоком запросов, ответ очевиден — поставить несколько и распределять нагрузку между ними. Настроить балансировку нагрузки на VPS проще, чем кажется: чаще всего для этого хватает того же Nginx, который у вас уже стоит. Разберём, как поднять upstream-группу, выбрать метод распределения и не потерять пользовательские сессии.

Что такое балансировка и когда она нужна

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

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

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

Подготовка серверов и сети

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

Бэкенды удобно держать в одной приватной сети, чтобы трафик между балансировщиком и ними не выходил в интернет. Публичный IP с чистой репутацией нужен только балансировщику — именно на него смотрит домен. Здесь же играет роль локация: для аудитории в России логичнее RU-площадка с минимальным пингом, для работы с зарубежными сервисами — US, для Европы — UK. У MAATRIX можно взять несколько VPS в одной локации с оплатой из России картой или криптой, что удобно для сборки такой связки.

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

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

Базовый конфиг upstream в Nginx

Балансировка в Nginx описывается блоком upstream, где перечислены адреса бэкендов, и обычным proxy_pass на имя этой группы. Отредактируйте конфиг сайта:

upstream backend {
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000;
}

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;
    }
}

Проверьте синтаксис и примените:

nginx -t && systemctl reload nginx

По умолчанию Nginx распределяет запросы по методу round-robin — по очереди на каждый сервер. Этого достаточно для большинства случаев, когда бэкенды одинаковы по мощности, а запросы примерно равнозначны по стоимости.

Методы распределения нагрузки

Round-robin — не единственный вариант, и выбор метода заметно влияет на равномерность. Разберём основные.

• round-robin (по умолчанию) — запросы идут по кругу. Хорош, когда серверы равны, а запросы однотипны.
• least_conn — запрос уходит на бэкенд с наименьшим числом активных соединений. Полезен, когда запросы разной длительности: медленные не копятся на одном сервере.
• ip_hash — запросы от одного IP всегда идут на один и тот же бэкенд. Простой способ сохранить привязку клиента к серверу.
• weight — вес сервера в группе. Позволяет отдать более мощной машине больше запросов.

Метод и веса задаются прямо в блоке upstream:

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

Здесь первый сервер получает втрое больше запросов как более мощный, а третий помечен backup — он принимает трафик только если основные недоступны. Такой резерв полезен для аварийного узла, который в обычное время простаивает.

Проверки здоровья и вывод сервера из ротации

Балансировщик обязан понимать, какой бэкенд жив, а какой упал, иначе он будет упорно слать запросы на мёртвый узел. В открытой версии Nginx работает пассивная проверка: если бэкенд не ответил, его на время исключают из ротации. Настраивается это параметрами прямо у сервера:

server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;

Здесь после трёх неудачных попыток подряд сервер на 30 секунд выводится из пула, затем Nginx снова пробует его. Пассивной проверки хватает для типовых задач: упавший бэкенд перестаёт получать трафик в течение нескольких запросов.

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

Sticky-сессии и частые нюансы

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

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

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