Настройка кластеризации Битрикс24 On-Premise

Настройка кластеризации Битрикс24 On-Premise

Когда одного сервера перестаёт хватать — а это случается при 150–200 одновременных пользователях или при росте БД до 50+ ГБ — встаёт вопрос горизонтального масштабирования. Битрикс24 Enterprise On-Premise поддерживает кластеризацию «из коробки», но реальная настройка требует понимания архитектуры и нескольких нетривиальных решений.

Архитектура кластера Битрикс24

Типовой 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 — отказоустойчивый.

Настройка балансировщика нагрузки

nginx как балансировщик с sticky sessions (сессии одного пользователя идут на один backend):

upstream bitrix_backends {
    ip_hash;  # sticky sessions по IP клиента
    server web1.internal:80 weight=1;
    server web2.internal:80 weight=1;
    keepalive 32;
}

server {
    listen 443 ssl;
    server_name portal.company.ru;

    location / {
        proxy_pass http://bitrix_backends;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
    }
}

ip_hash — простейший sticky session. Недостаток: при смене IP (мобильные пользователи) сессия рвётся. Более надёжный вариант — sticky cookie через nginx_sticky_module или HAProxy с cookie persistence.

Настройка репликации 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' => [...],
        ],
    ],
],

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 при падении мастера.

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

Кластер без мониторинга — это кластер, который сломается в пятницу вечером, и вы об этом узнаете от пользователей, а не от системы оповещения.

Плановое обслуживание без downtime

Обновление кластера без остановки: выводите узлы по одному из балансировщика, обновляйте, проверяйте, возвращайте. Обновление БД сложнее — требует maintenance window (обычно в нерабочее время). Процедуру зафиксируйте в runbook и отрепетируйте на staging.