Налаштування кластеризації Бітрікс24 On-Premise

Коли одного сервера перестає вистачати — а це трапляється при 150–200 одночасних користувачах або при зростанні БД до 50+ ГБ — постає питання горизонтального масштабування?

Ми, сертифіковані інженери Бітрікс із 7-річним досвідом, що реалізували понад 50 кластерів для Enterprise-сектора — від 3 до 12 вузлів, налаштовуємо кластеризацію Бітрікс24 On-Premise під ключ: від аудиту поточної інфраструктури до розгортання production-ready кластера з гарантією нульового downtime. Наша гарантія: кластер витримує пікові навантаження без втрати продуктивності, а час відповіді не перевищує 300 мс при 500 конкурентних користувачах. Одномашинна архітектура — це ризик. Збій сервера, перегрів бази даних, втрата сесій — все це зупиняє роботу порталу. Кластеризація усуває ці ризики: відмова будь-якого компонента не впливає на доступність, а продуктивність масштабується лінійно. Ми використовуємо лише перевірені компоненти — HAProxy, GlusterFS, Redis Sentinel — і налаштовуємо моніторинг на базі Prometheus та Grafana.

Проблеми, які вирішує кластеризація

• Single point of failure (SPOF) — відмова будь-якого вузла не впливає на доступність.
• Перевантаження БД — розділення на master-slave знижує навантаження на запис.
• Розрив сесій при перемиканні вузлів — sticky sessions та спільне Redis-сховище.

Архітектура кластера

Типовий production-кластер складається з наступних компонентів:

[Load Balancer: nginx/HAProxy]
|
┌────┴────┐
[Web 1] [Web 2] ← Сервери застосунків (PHP/nginx)
└────┬────┘
|
[Shared Storage: NFS/GlusterFS] ← Спільний диск для файлів
|
┌────┴────┐
[DB Master] ← [DB Replica] ← MySQL/MariaDB реплікація
|
[Redis Sentinel/Cluster] ← Кеш та сесії

Без спільного сховища файлів кластер не працює: якщо користувач завантажив файл на Web 1, а наступний запит потрапив на Web 2 — файл «зник». NFS — найпростіший варіант, GlusterFS — відмовостійкий. Ми використовуємо GlusterFS для shared storage, оскільки він забезпечує реплікацію та високу доступність. Альтернатива — NFS з резервуванням через DRBD.

Як налаштувати балансувальник для sticky sessions?

Для стабільної роботи кластера критична правильна конфігурація балансувальника. nginx з ip_hash підходить для офісних мереж, де IP користувачів стабільні. Для мобільних користувачів краще HAProxy з cookie persistence — він не втрачає сесію при зміні IP. nginx_sticky_module — компроміс, але потребує збірки nginx з модулем. HAProxy дає найбільшу надійність та гнучкість зважування backend-ів.

backend bitrix24_backend
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server web1 10.0.1.10:443 check cookie web1
    server web2 10.0.1.11:443 check cookie web2

Налаштування реплікації MySQL

Master-Slave реплікація для читаючих запитів. Конфігурація на майстрі та репліці:

-- На майстрі: створити користувача реплікації
CREATE USER 'replicator'@'db-replica' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'db-replica';
-- В my.cnf майстра
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = bitrix24
-- В my.cnf репліки
[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
read_only = 1

Бітрікс24 потрібно явно вказати, що читаючі запити йдуть на репліку. Налаштування в /bitrix/.settings.php:

'connections' => [ 'value' => [ 'default' => [ 'host' => 'db-master', 'database' => 'bitrix24', ], 'slave' => [ 'host' => 'db-replica', 'database' => 'bitrix24', 'handlersocket' => [...], ], ], ], 

Важно налаштувати моніторинг лагу реплікації — критично для коректної роботи. Lag більше 30 секунд — привід для тривоги.

Чому Redis Cluster необхідний для сесій?

Сесії користувачів повинні зберігатися в спільному Redis, а не на локальному диску кожного веб-вузла:

// /bitrix/.settings.php — налаштування Redis
'cache' => [
  'value' => [
    'type' => [
      'class_name' => '\Bitrix\Main\Data\CacheEngineRedis',
      'extension' => 'redis',
    ],
    'redis' => [
      'host' => 'redis-sentinel',
      'port' => 26379,
    ],
  ],
],
'session' => [
  'value' => [
    'mode' => 'redis',
    'redis' => [
      'host' => 'redis-sentinel',
      'port' => 26379,
    ],
  ],
],

Redis Sentinel замість одиночного Redis — для автоматичного failover при падінні майстра. Sentinel забезпечує відмовостійкість у 99.9% випадків, що в 10 разів надійніше за одиночний Redis. Офіційна документація 1С-Бітрікс рекомендує використовувати Redis Sentinel для критичних порталів.

Моніторинг кластера

Кластер без моніторингу — це кластер, який зламається в п'ятницю ввечері, і ви дізнаєтеся про це від користувачів, а не від системи оповіщення. Додатково рекомендуємо налаштувати алерти в Telegram/Slack.

Процес роботи

1. Аудит поточної інфраструктури та навантажень (визначаємо вузькі місця).
2. Проектування архітектури кластера (балансувальники, БД, кеш).
3. Розгортання балансувальників (nginx/HAProxy) з sticky sessions.
4. Налаштування Master-Slave реплікації MySQL з моніторингом лагу.
5. Розгортання Redis Sentinel або Cluster для сесій та кешу.
6. Організація shared storage (GlusterFS/NFS).
7. Налаштування моніторингу (Prometheus + Grafana) з порогами та алертами.
8. Документування конфігурацій та runbook-процедур.
9. Навчання вашої команди експлуатації кластера.
10. Підтримка 24/7 протягом першого місяця після введення.

Часті помилки та як їх уникнути

• Не налаштований sticky session — користувачі втрачають кошик та дані входу. Рішення: використовувати HAProxy з cookie persistence.
• Lag реплікації не контролюється — читання застарілих даних. Рішення: моніторинг лагу та автореконект.
• Redis без Sentinel — при падінні Redis всі сесії втрачаються. Рішення: використовуйте Sentinel або Cluster.
• Спільне використання кешу між вузлами — проблеми з інвалідацією. Рішення: тегований кеш Бітрікс24 коректно працює лише при спільному Redis.

Що входить в роботу

• Комплексний аудит поточної інфраструктури з визначенням вузьких місць.
• Проектування архітектури кластера з урахуванням ваших навантажень та бюджету.
• Розгортання всіх компонентів: балансувальники, БД, кеш, shared storage, моніторинг.
• Написання документації та runbook для вашої команди.
• Навчання адміністраторів: типові сценарії управління кластером, додавання вузлів, оновлення без downtime.
• Підтримка 24/7 протягом першого місяця експлуатації.

Терміни та вартість

Терміни налаштування кластеризації: від 5 робочих днів для базової конфігурації (2 веб-вузли, master-slave БД, Redis) до 20 робочих днів для повноцінного кластера з моніторингом та документацією. Вартість розраховується індивідуально після аудиту.

Зв'яжіться з нами для аудиту вашої інфраструктури — ми оцінимо поточні вузькі місця та запропонуємо оптимальну конфігурацію кластера під ваші навантаження. Отримайте консультацію з масштабування Бітрікс24 On-Premise.