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