Настройка geo-distributed кластера 1С-Битрикс

Настройка geo-distributed кластера 1С-Битрикс

Единственный датацентр в Москве даёт задержку 80–120 мс для пользователей из Новосибирска и 150–200 мс из Алматы. При highload из нескольких регионов это накапливается: страница с 30+ запросами к API открывается за 3–4 секунды вместо 1. Geo-distributed кластер решает это маршрутизацией пользователя на ближайший узел — но для Битрикс это нетривиально, потому что требует работы с распределённым состоянием.

Архитектура geo-кластера для Битрикс

Типовая схема для двух регионов (Москва + ещё один регион):

           [GeoDNS / Anycast BGP]
          /                       \
   [Region-MSK]               [Region-EKB]
   Web-1, Web-2               Web-3, Web-4
   Redis-1 (master)           Redis-2 (replica)
   [DB Master]      <-->      [DB Replica]
   [File Storage]    rsync    [File Storage Mirror]

Ключевые решения, которые нужно принять:

1. Где мастер БД? — только в одном регионе. Записи всегда идут в мастер, чтения можно распределить.
2. Как синхронизировать файлы? — реалтаймовая репликация дорога, обычно rsync каждые 1–5 минут.
3. Как управлять сессиями? — через Redis с репликацией между регионами.
4. Что делать при разрыве связи между регионами? — определить: работаем только из мастер-региона, или разрешаем расхождение данных?

GeoDNS: маршрутизация пользователей

Самый простой уровень — DNS по геолокации. Cloudflare, AWS Route 53, Яндекс Cloud DNS.

; Пример зоны с геомаршрутизацией
; Пользователи из Европы -> MSK-ноды
@ 300 IN A 185.10.1.100  ; geo: EU, RU-west
@ 300 IN A 195.20.2.100  ; geo: RU-east, KZ

Ограничение GeoDNS: TTL влияет на скорость переключения при аварии. При TTL 300 секунд — 5 минут кэширования у клиента. Для быстрого failover — Anycast BGP (один IP, разные серверы в разных точках, маршрутизация на уровне сети).

Настройка модуля cluster в Битрикс

Битрикс поставляет модуль cluster (Bitrix Web Cluster), который управляет распределёнными узлами. Ключевые настройки находятся в /bitrix/.settings.php:

'connections' => [
    'value' => [
        'default' => [
            'className' => '\\Bitrix\\Main\\DB\\MysqlCommonConnection',
            'host' => '10.0.1.10',      // мастер (MSK)
            'port' => 3306,
            'database' => 'bitrix_db',
            'login' => 'bitrix',
            'password' => '***',
            'options' => 2,
        ],
        'slave' => [
            'className' => '\\Bitrix\\Main\\DB\\MysqlCommonConnection',
            'host' => '10.0.2.10',      // реплика (EKB)
            'port' => 3306,
            'database' => 'bitrix_db',
            'login' => 'bitrix_ro',
            'password' => '***',
            'options' => 2,
        ],
    ],
],

Читающие запросы переводятся на реплику через:

\Bitrix\Main\Application::getConnection('slave')->query("SELECT ...");

Стандартные API Битрикс (D7 ORM, CIBlockElement::GetList) используют соединение default. Для автоматического разделения read/write нужен промежуточный слой — ProxySQL или кастомный враппер.

Репликация БД между регионами

MySQL GTID-репликация через зашифрованный канал (stunnel или WireGuard):

# На мастере (MSK)
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_format = ROW

# На реплике (EKB)
[mysqld]
server-id = 2
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON
relay_log = /var/log/mysql/relay-bin.log

-- На реплике
CHANGE MASTER TO
    MASTER_HOST='10.0.1.10',
    MASTER_USER='replication',
    MASTER_PASSWORD='***',
    MASTER_AUTO_POSITION = 1,
    MASTER_SSL = 1;

START SLAVE;
SHOW SLAVE STATUS\G
-- Seconds_Behind_Master: 0 — репликация догнала мастер

Задержка репликации между регионами (replication lag) — нормально 50–200 мс на канале 100 Мбит/с с задержкой 20–30 мс. Критично: если пользователь создал заказ (запись в мастер), и тут же читает его статус с реплики — при лаге >200 мс он может не увидеть заказ. Решение: операции после write на конкретную сессию направлять на мастер в течение 5–10 секунд.

Синхронизация файлов

Файлы upload/ (медиа, документы) должны быть доступны на всех нодах. Варианты:

Вариант 1: S3-совместимое хранилище (рекомендуется)

Храним upload/ в S3 (Yandex Object Storage, AWS S3, MinIO). Битрикс умеет работать с S3 через модуль bitrix.cloud или через кастомный обработчик файлов. CDN перед S3 раздаёт файлы из ближайшего региона.

Вариант 2: Двусторонний rsync

# Синхронизация MSK -> EKB каждую минуту
*/1 * * * * rsync -az --delete \
    /var/www/bitrix/upload/ \
    ekb-storage:/var/www/bitrix/upload/

# Обратная синхронизация для файлов, загруженных на EKB-ноду
*/1 * * * * rsync -az \
    ekb-storage:/var/www/bitrix/upload/new/ \
    /var/www/bitrix/upload/new/

Проблема двустороннего rsync — конфликты при одновременной загрузке в обоих регионах. Для production лучше запрещать загрузку файлов на региональных нодах — весь upload проксируется на мастер-регион.

Redis: распределённые сессии и кэш

Сессии пользователей в geo-кластере должны быть доступны независимо от того, на какую ноду попадёт следующий запрос:

// /bitrix/.settings.php
'session' => [
    'value' => [
        'mode' => 'separated',
        'handlers' => [
            'general' => [
                'type' => 'redis',
                'host' => '10.0.1.20',  // Redis MSK (мастер)
                'port' => 6379,
            ],
        ],
    ],
],
'cache' => [
    'value' => [
        'type' => 'redis',
        'redis' => [
            'host' => '10.0.1.20',
            'port' => 6379,
        ],
        'sid' => 'bitrix_geo',
    ],
],

Redis Sentinel или Redis Cluster для HA. При geo-распределении — Redis реплицируется асинхронно. Кэш можно хранить локально в каждом регионе (экономит трафик), сессии — только в мастер-регионе или в Redis Cluster с cross-region репликацией.

Разделение трафика: что можно регионализировать, что нельзя

Для Битрикс-магазина это означает: страницы каталога отдаются с ближайшего региона, оформление заказа — всегда проксируется в мастер-регион. Split-routing реализуется на уровне nginx:

location /bitrix/components/bitrix/sale. {
    proxy_pass http://msk_master;  # заказы всегда в MSK
}

location / {
    proxy_pass http://geo_cluster;  # остальное — ближайший узел
}

Сроки настройки