Налаштування 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 або кастомний wrapper.

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

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;  # решта — найближчий вузол
}

Терміни налаштування