Коли одного сервера перестає вистачати — а це трапляється при 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.