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