Балансировка нагрузки 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 реализованных проектов — от небольших магазинов до крупных каталогов с миллионом товаров. Гарантируем стабильную работу кластера и предоставляем поддержку после внедрения. Получите консультацию инженера и детальный аудит текущей архитектуры. Закажите настройку — и ваш сайт выдержит любые пики.

Кластеризация 1С-Битрикс

Представьте: flash-распродажа, 10 000 пользователей одновременно заходят на сайт, сервер падает с 502, корзины пропадают, менеджеры звонят в поддержку. Мы видели это десятки раз. Решение — кластеризация: балансировка запросов между серверами, репликация базы данных и автоматическое переключение при сбое. Закажите аудит текущей инфраструктуры — за 2 дня определим, нужен ли кластер и какой. Наш опыт — 40+ высоконагруженных проектов на Битрикс.

Почему кластеризация 1С-Битрикс критична для отказоустойчивости?

80-90% запросов в типичном проекте — SELECT. Каталог, карточки, фильтры — всё чтение. Master-slave репликация отдаёт SELECT на slave-серверы, master остаётся только для записи. Модуль «Веб-кластер» (редакция «Бизнес» и выше) маршрутизирует запросы автоматически.

Настройка, где спотыкаются: на master binlog_format = ROW. STATEMENT-репликация на NOW() или UUID() даёт расхождения — потом неделя дебага. Уникальный server-id, включённый binary log. На slave — read_only = ON, relay-log. Инициализация через xtrabackup (не mysqldump, который блокирует таблицы на полчаса на базе в 20 ГБ).

Metric #1 — Seconds_Behind_Master. Если slave отстаёт на 5+ секунд, покупатель оформляет заказ, возвращается в личный кабинет — а заказа нет (SELECT ушёл на отстающий slave). Модуль позволяет исключить критичные запросы из маршрутизации на slave вручную.

Failover: Orchestrator или ProxySQL промоутят slave в master за 15-30 секунд. Модуль поддерживает до 9 slave-соединений с настраиваемыми весами. Проверка целостности — pt-table-checksum из Percona Toolkit. Экономия на неэффективной инфраструктуре — до 40% бюджета, что в среднем составляет 300 000 рублей в год для проектов с 50 000+ уникальных посетителей. Подробнее о репликации — MySQL Replication Documentation и Wikipedia: Репликация базы данных.

Признаки, когда кластеризация необходима

Не каждому проекту. Конкретные маркеры:

• 50 000-100 000 уников в сутки — один сервер начинает отдавать 502 в часы пик
• Пиковые скачки в 5-10 раз (распродажи, flash-sale) — нагрузка растёт за минуты, вертикально не масштабируешься
• SLA 99.9% (не более 8.7 часов простоя в год) — с одним сервером недостижимо
• Географическая распределённость пользователей

Иногда хватает композитного кэша, оптимизации SQL и вертикального масштабирования. Мы честно скажем, если кластер пока не нужен. Инвестиции в кластеризацию окупаются за 3-6 месяцев при пиковых нагрузках. Средний бюджет проекта — от 150 000 рублей.

Архитектура — четыре уровня

Балансировщик. HAProxy, nginx upstream или облачный LB. Round-robin для равномерного распределения, ip-hash для привязки сессий, least connections для адаптивной балансировки. Health checks выводят мёртвые серверы из пула. SSL-терминация на балансировщике разгружает веб-ноды.

Веб-серверы. Идентичные nginx + php-fpm, каждая с полной копией кода. Сессии — в Redis/Memcached, не на диске (иначе при переключении между серверами пользователь теряет корзину). В облаке — автоскейлинг: нагрузка выросла — добавились серверы, упала — выключились.

Кэш. Redis Cluster с шардингом данных по узлам. Redis Sentinel для небольших кластеров. Memcached быстр, но без persistence. Конфигурация в .settings.php — серверы, веса, стратегия шардинга.

Файловое хранилище. Загрузки, картинки — доступны с каждой ноды. NFS для 2-3 серверов, но это единая точка отказа. GlusterFS — распределённая ФС без single point of failure. S3 (MinIO, AWS, Яндекс Object Storage) — вынос статики в объектное хранилище, модуль Битрикс работает из коробки.

Как обеспечить failover на каждом уровне кластера?

Кластер в 5 раз надёжнее одиночного сервера — при отказе любого узла сервис продолжает работать.

Типичные ошибки при настройке кластера

• Сессии на файлах — при отключении сервера пользователь теряет корзину и авторизацию.
• Не настроенный Seconds_Behind_Master — продажи падают, а SLA не выполняется.
• Одна точка отказа на уровне файлового хранилища (NFS без репликации).
• Отсутствие мониторинга репликации — расхождение данных остаётся незамеченным.

Мы включаем проверку всех этих точек в аудит и тестирование.

Процесс работы

1. Аудит нагрузки — профиль нагрузки, узкие места, нагрузочное тестирование. Находим потолок одиночного сервера.
2. Проектирование — компоненты под требования и бюджет. Не всем нужен GlusterFS — иногда хватит NFS и бэкапов.
3. Инфраструктура — серверы, сеть, файрволы. Ansible для автоматизации — любой узел можно пересоздать за минуты.
4. Миграция — перенос с минимальным простоем. Компоненты подключаются последовательно, каждый шаг с проверкой.
5. Тестирование — имитация пиковых условий. Роняем master, отключаем веб-сервер, убиваем Redis — смотрим, как система себя ведёт.
6. Документация — схема архитектуры, runbook, планы аварийного восстановления.

Что входит в работу по кластеризации?

Сроки

Свяжитесь с нами — получите консультацию инженера и предварительную оценку проекта за 2 дня. Мы рассчитаем стоимость индивидуально под ваши задачи. Закажите аудит — узнайте точную архитектуру и бюджет.