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