Балансировка нагрузки позволяет распределить трафик highload-проекта на Битрикс между несколькими веб-нодами, когда одна перестаёт справляться. Но просто поставить балансировщик недостаточно: сессии, кэш и файлы должны стать общими, иначе ноды будут работать вразнобой.
Когда нужна балансировка
Балансировка — это горизонтальное масштабирование веб-слоя. Её вводят, когда проверены другие резервы:
- код и кэш уже оптимизированы, профилирование не находит лёгких побед;
- одна нода упирается в CPU на пике трафика, а не в БД или диск;
- нужна отказоустойчивость — падение одной ноды не должно ронять сайт.
Если узкое место — база данных, балансировка веб-нод не поможет: все они всё равно ходят в одну БД. Сначала диагностика, потом решение. Балансировка отвечает на нехватку PHP-мощности и на требование отказоустойчивости, а не лечит медленный код.
cluster в редакциях Битрикс Бизнес и выше даёт штатную поддержку веб-кластера: общий кэш, репликацию БД и мониторинг нод из админки.Балансировщик: nginx, HAProxy, облако
Перед веб-нодами ставится балансировщик, распределяющий входящие запросы. Варианты:
| Решение | Особенности |
|---|---|
| nginx (upstream) | Простой L7-балансинг, часто уже есть в стеке BitrixVM |
| HAProxy | Гибкие алгоритмы, health-check, L4/L7 |
| Облачный LB | Управляемый, автоскейлинг, интеграция с провайдером |
Типовая конфигурация nginx — блок upstream со списком backend-нод и проксирование на него:
upstream bitrix_backend { server 10.0.0.11; server 10.0.0.12; }location / { proxy_pass http://bitrix_backend; }
Алгоритм распределения выбирают по задаче: round-robin по умолчанию, least_conn при неравномерных запросах, ip_hash для привязки клиента к ноде.
Общие сессии и кэш
Главная проблема нескольких нод — состояние. Если сессии хранятся в файлах локально, пользователь, попавший на другую ноду, окажется разлогинен. Решение — вынести состояние в общее хранилище.
- Сессии — в Redis (общий для всех нод), задаётся в
/bitrix/.settings.php; - Кэш — тоже в Redis/Memcached, единый для кластера, иначе каждая нода греет свой;
- Тегированный кэш — общий, чтобы сброс по тегу инвалидировал кэш на всех нодах сразу.
ip_hash позволяет держать сессии локально, но ломает равномерность распределения и отказоустойчивость: при падении ноды её пользователи теряют сессию. Правильнее — общие сессии в Redis.Синхронизация файлов между нодами
Загружаемый контент (/upload/), кэш композита и служебные файлы должны быть согласованы между нодами. Иначе картинка, загруженная через одну ноду, не откроется через другую. Подходы:
- Общее сетевое хранилище — NFS или GlusterFS, монтируемое на все ноды;
- Объектное хранилище — S3-совместимое для медиа через модуль
clouds; - Синхронизация —
lsyncd/csync2для реплики upload-каталога.
Ядро и код Битрикс раскатываются на все ноды одинаково через пайплайн деплоя. А вот пользовательский /upload/ и кэш требуют отдельной стратегии — это частый источник ошибок «файл есть на одной ноде, но не на другой».
Отказоустойчивость и health-check
Балансировка ценна не только распределением, но и отказоустойчивостью. Балансировщик должен проверять живость нод и выводить упавшие из ротации:
- health-check — периодический запрос на служебный URL ноды (например, лёгкая страница-проба);
- автоматическое исключение ноды при таймауте или ошибке 5xx;
- возврат в ротацию после восстановления.
Для настоящей отказоустойчивости резервируют и сам балансировщик (пара nginx/HAProxy с keepalived и виртуальным IP), и БД (master + реплики с механизмом переключения). Иначе балансировщик или master становятся единой точкой отказа, обесценивая кластер.
Масштабирование и автоскейлинг
В облаке балансировка открывает путь к автоскейлингу: число веб-нод меняется под нагрузку автоматически. При росте трафика поднимаются новые ноды, при спаде — гасятся.
| Сценарий | Подход |
|---|---|
| Предсказуемые пики (акции, распродажи) | Плановое ручное добавление нод заранее |
| Неравномерный трафик | Автоскейлинг по метрике CPU/RPS |
| Стабильная нагрузка | Фиксированное число нод за LB |
Условие автоскейлинга — stateless веб-ноды: всё состояние (сессии, кэш, файлы) вынесено наружу. Тогда новую ноду можно поднять из образа за минуты, и она сразу включится в работу без ручной настройки.
Итог
Балансировка нагрузки в Битрикс — это не только балансировщик перед нодами, но и перевод веб-слоя в stateless: общие сессии и кэш в Redis, единое хранилище для /upload/, репликация БД и health-check с резервированием балансировщика. Вводить её стоит после оптимизации кода и кэша, когда узкое место — именно PHP-мощность или требование отказоустойчивости.
Мы в B2Bsite проектируем и разворачиваем веб-кластеры на Битрикс: настраиваем балансировку, выносим состояние в Redis, синхронизируем файлы и строим отказоустойчивую схему с резервированием. Если проект перерос одну ноду — поможем масштабировать его горизонтально без простоев.
Частые вопросы
Когда балансировка не поможет?
Когда узкое место — база данных или медленный код. Все веб-ноды ходят в одну БД, поэтому добавление нод не разгрузит её. Сначала оптимизируйте код и кэш, затем масштабируйте веб-слой.
Почему нельзя хранить сессии в файлах при балансировке?
При нескольких нодах пользователь может попасть на другую ноду, где его файловой сессии нет, и окажется разлогинен. Сессии нужно выносить в общий Redis, доступный всем нодам кластера.
Что такое sticky sessions и почему это костыль?
Это привязка клиента к одной ноде через ip_hash, чтобы держать сессию локально. Она ломает равномерность распределения и отказоустойчивость: при падении ноды её пользователи теряют сессию. Лучше общий Redis.
Как синхронизировать загруженные файлы между нодами?
Через общее сетевое хранилище (NFS, GlusterFS), объектное S3-хранилище с модулем clouds или репликацию каталога /upload/ инструментами вроде lsyncd. Иначе файл с одной ноды не откроется через другую.
Балансировщик не станет ли сам точкой отказа?
Станет, если он один. Для отказоустойчивости резервируют пару nginx или HAProxy с keepalived и виртуальным IP, а также БД через master и реплики. Иначе кластер держится на единой точке отказа.
Что нужно для автоскейлинга веб-нод?
Stateless-ноды: сессии, кэш и файлы вынесены во внешние хранилища. Тогда новую ноду поднимают из образа за минуты, и она сразу включается в работу. Если состояние локальное, автоскейлинг невозможен.
Какой алгоритм балансировки выбрать в nginx?
Round-robin подходит для равномерных запросов, least_conn — когда запросы разной тяжести, ip_hash привязывает клиента к ноде. Для highload с общими сессиями обычно берут least_conn без привязки.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.