Налаштування кластеризації Бітрікс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 (запити одного користувача направляються на один бекенд):

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.ua;

    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.