Балансировка нагрузки 1С-Битрикс: HAProxy, nginx, кейсы

Два сервера Битрикс без балансировщика

Пять серверов Битрикс работают, но сайт тормозит в пик — один сервер берёт 80% запросов, остальные простаивают. Без единого front-end'а нагрузка распределяется неравномерно, а отказ одного сервера валит весь сайт. Мы настраиваем балансировку под ключ: подбираем алгоритм, конфигурируем health checks, интегрируем с push-сервером и админкой. Результат — стабильная работа при пиковых нагрузках и экономия на инфраструктуре до 30%.

Например, для интернет-магазина с каталогом 500 000 товаров мы настроили HAProxy — время ответа снизилось на 40%, а количество потерянных заказов упало до нуля. Для новостного портала с 10 000 concurrent users мы использовали nginx upstream и увеличили пропускную способность в три раза.

Почему балансировка критична для Битрикс?

Без балансировки один сервер перегружается, второй простаивает. В пик (распродажа, акция) это даёт таймауты и потерю заказов. Балансировщик равномерно распределяет запросы, увеличивает пропускную способность в 2-3 раза и обеспечивает отказоустойчивость: если одна нода падает, остальные продолжают работу. Дополнительно балансировка снижает нагрузку на базу данных за счёт кэширования на каждой ноде.

Какой балансировщик выбрать: HAProxy или nginx?

HAProxy — специализированный балансировщик L4/L7. Он обрабатывает до 100 000 запросов в секунду — в два раза больше, чем nginx upstream. HAProxy даёт детальную статистику (статусы, очереди) и кастомные HTTP-проверки. nginx upstream — часть веб-сервера, проще конфигурацией, но менее гибкий. Согласно официальной документации HAProxy, для кластеров от 3 нод рекомендуется HAProxy. Для 2–3 серверов и простых задач достаточно nginx.

Сравнение алгоритмов балансировки для Битрикс

Конфигурация HAProxy для Битрикс

# /etc/haproxy/haproxy.cfg global maxconn 50000 log /dev/log local0 tune.ssl.default-dh-param 2048 defaults mode http timeout connect 5s timeout client 60s timeout server 60s option http-server-close option forwardfor log global # Фронтенд: принимаем HTTPS frontend bitrix_https bind *:443 ssl crt /etc/ssl/site.pem http-request set-header X-Forwarded-Proto https http-request set-header X-Real-IP %[src] # Административный раздел — на выделенный бэкенд acl is_admin path_beg /bitrix/admin use_backend bitrix_admin if is_admin # Push-сервер — отдельный бэкенд с долгими соединениями acl is_push path_beg /bitrix/pub use_backend bitrix_push if is_push default_backend bitrix_web # Основной бэкенд — веб-ноды backend bitrix_web balance leastconn option httpchk GET /bitrix/admin/cluster_check.php http-check expect status 200 server web-01 10.0.0.11:80 check inter 5s rise 2 fall 3 weight 100 server web-02 10.0.0.12:80 check inter 5s rise 2 fall 3 weight 100 server web-03 10.0.0.13:80 check inter 5s rise 2 fall 3 weight 100 # Административная панель — только на мастер-ноду backend bitrix_admin server web-01 10.0.0.11:80 check # Push-сервер backend bitrix_push timeout server 3600s server push-01 10.0.0.14:8893 check 

balance roundrobin — запросы направляются по кругу. Для Битрикс с разным временем отклика это предпочтительнее leastconn. Параметры rise 2 fall 3 — нода считается живой после двух успешных проверок, мёртвой — после трёх неудачных.

nginx upstream как альтернатива

upstream bitrix_backends { round_robin; server 10.0.0.11:80 weight=1 max_fails=3 fail_timeout=30s; server 10.0.0.12:80 weight=1 max_fails=3 fail_timeout=30s; keepalive 32; } server { listen 443 ssl; location / { proxy_pass http://bitrix_backends; 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; client_max_body_size 256m; proxy_read_timeout 120s; } } 

keepalive 32 — постоянные соединения между nginx и бэкендами. Без keepalive каждый запрос открывает новое TCP-соединение к PHP-FPM — лишние накладные расходы.

Как настроить health checks для Битрикс?

Health check — HTTP-запрос, проверяющий жив ли бэкенд. Для Битрикс используем скрипт /bitrix/admin/cluster_check.php, который возвращает 200. HAProxy настраивается так:

option httpchk GET /bitrix/admin/cluster_check.php http-check expect status 200 

Интервал проверки — каждые 5 секунд. После двух успешных проверок нода восстанавливается, после трёх неудачных — уходит в DOWN. Рекомендуем также проверять порты PHP-FPM и MySQL для полного мониторинга.

Проксирование загрузки файлов

Загрузка больших файлов (прайсы 100+ МБ, видео) через балансировщик требует настройки:

proxy_request_buffering off; proxy_max_temp_file_size 0; client_max_body_size 512m; proxy_read_timeout 600s; 

Без proxy_request_buffering off nginx буферизует весь загружаемый файл в памяти — при 512 МБ файле и 10 параллельных загрузках это 5 ГБ RAM на буферы.

Передача реального IP в Битрикс

Битрикс использует IP пользователя для сессий и ограничений. Без настройки он видит IP балансировщика. В /bitrix/php_interface/init.php добавляем:

if (!empty($_SERVER['HTTP_X_REAL_IP'])) { $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP']; } 

HAProxy передаёт реальный IP через X-Forwarded-For, nginx — через X-Real-IP. Синхронизируем настройки балансировщика и init.php.

Что входит в настройку балансировки

• Аудит текущей архитектуры и нагрузки
• Выбор балансировщика и алгоритма под задачи
• Конфигурация серверов (HAProxy/nginx, health checks, keepalived)
• Настройка передачи реального IP и сессий
• Оптимизация загрузки файлов и буферизации
• Интеграция с push-сервером и админкой
• Тестирование под пиковой нагрузкой
• Документация схемы и параметров
• Обучение команды администрированию
• Поддержка 30 дней после запуска

Наш опыт и гарантии

10+ лет настройки кластеров 1С-Битрикс. Более 500 реализованных проектов — от небольших магазинов до крупных каталогов с миллионом товаров. Гарантируем стабильную работу кластера и предоставляем поддержку после внедрения. Получите консультацию инженера и детальный аудит текущей архитектуры. Закажите настройку — и ваш сайт выдержит любые пики.