Два сервери Бітрікс без балансувальника
П'ять серверів Бітрікс працюють, але сайт гальмує в пік — один сервер бере 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 | nginx upstream |
|---|---|---|
| Продуктивність | до 100k req/s | до 50k req/s |
| Health checks | HTTP, TCP, script | тільки HTTP |
| Статистика | детальна (статуси, черги) | базова (up/down) |
| Складність конфігурації | середня | низька |
Порівняння алгоритмів балансування для Бітрікс
| Алгоритм | Опис | Особливості для Бітрікс |
|---|---|---|
| roundrobin | Запити по колу | Рівномірно розподіляє запити різної тривалості — найкращий вибір |
| leastconn | На сервер з найменшою кількістю з'єднань | Поганий при різному часі виконання: одна нода може завантажитись важким імпортом |
| first | На перший доступний сервер | Використовується для виділених бекендів (push, admin) |
Конфігурація 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 (2 екземпляри з keepalived)
- 2–5 веб-нод з mod_xsendfile
- 1 виділена нода для push-сервера
- 1 мастер-нода для адмінки та завдань агентів
- 1 сервер БД (або кластер MySQL)
Що входить у налаштування балансування
- Аудит поточної архітектури та навантаження
- Вибір балансувальника та алгоритму під завдання
- Конфігурація серверів (HAProxy/nginx, health checks, keepalived)
- Налаштування передачі реального IP та сесій
- Оптимізація завантаження файлів та буферизації
- Інтеграція з push-сервером та адмінкою
- Тестування під піковим навантаженням
- Документація схеми та параметрів
- Навчання команди адмініструванню
- Підтримка 30 днів після запуску
Наш досвід та гарантії
10+ років налаштування кластерів 1С-Бітрікс. Понад 500 реалізованих проєктів — від невеликих магазинів до великих каталогів з мільйоном товарів. Гарантуємо стабільну роботу кластера та надаємо підтримку після впровадження. Отримайте консультацію інженера та детальний аудит поточної архітектури. Замовте налаштування — і ваш сайт витримає будь-які піки.