Коли одного сервера перестає вистачати — а це трапляється при 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-ів.
| Параметр | nginx ip_hash | nginx sticky module | HAProxy cookie |
|---|---|---|---|
| Залежність від IP | висока | низька | низька |
| Складність налаштування | низька | середня | середня |
| Надійність | середня | висока | висока |
| Рекомендація | для офісу | для мобільних | універсально |
Приклад конфігурації HAProxy для sticky sessions
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 для критичних порталів.
Моніторинг кластера
| Метрика | Інструмент | Поріг тривоги |
|---|---|---|
| Lag реплікації MySQL | Prometheus + mysqld_exporter | > 30 секунд |
| Використання RAM на веб-вузлах | node_exporter + Grafana | > 85% |
| Черга PHP-FPM | php-fpm status | backlog > 10 |
| Disk lag NFS | iostat | await > 20ms |
| Redis hit rate | redis-exporter | < 80% |
Кластер без моніторингу — це кластер, який зламається в п'ятницю ввечері, і ви дізнаєтеся про це від користувачів, а не від системи оповіщення. Додатково рекомендуємо налаштувати алерти в Telegram/Slack.
Процес роботи
- Аудит поточної інфраструктури та навантажень (визначаємо вузькі місця).
- Проектування архітектури кластера (балансувальники, БД, кеш).
- Розгортання балансувальників (nginx/HAProxy) з sticky sessions.
- Налаштування Master-Slave реплікації MySQL з моніторингом лагу.
- Розгортання Redis Sentinel або Cluster для сесій та кешу.
- Організація shared storage (GlusterFS/NFS).
- Налаштування моніторингу (Prometheus + Grafana) з порогами та алертами.
- Документування конфігурацій та runbook-процедур.
- Навчання вашої команди експлуатації кластера.
- Підтримка 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.