Налаштування geo-distributed кластера 1С-Бітрікс під ключ

Єдиний датацентр у Москві дає затримку 80–120 мс для користувачів з Новосибірська та 150–200 мс з Алмати. При highload із кількох регіонів це накопичується: сторінка з 30+ запитами до API відкривається за 3–4 секунди замість 1. Geo-distributed кластер вирішує це маршрутизацією користувача на найближчий вузол — і скорочує час завантаження у 2–3 рази. Для Бітрікс це нетривіально, оскільки вимагає роботи з розподіленим станом. Наш досвід показує, що правильно спроєктований кластер витримує пікові навантаження без деградації. Економія на хостингу за рахунок geo-кластера досягає 40% порівняно з орендою потужностей у кожному регіоні окремо.

Отримайте консультацію з архітектури вашого кластера — ми оцінимо ваш проєкт протягом двох днів після аудиту.

Яку архітектуру 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]

Ключові рішення:

• Мастер БД розміщується тільки в одному регіоні. Записи йдуть у мастер, читання можна розподілити по репліках.
• Синхронізація файлів — через S3-сумісне сховище (рекомендується) або односторонній rsync з мастера, завантаження на регіональних нодах заборонено.
• Сесії — через Redis з реплікацією між регіонами, сесії записуються в мастер-регіон.
• При розриві зв'язку працюємо тільки з мастер-регіону, щоб уникнути розбіжності даних.

Чому 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 впливає на швидкість перемикання при аварії. Для швидкого 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'). Стандартні 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 з параметрами мастера, і репліка запускається. Затримка реплікації між регіонами (replication lag) зазвичай 50–200 мс на каналі 100 Мбіт/с із затримкою 20–30 мс. Критично: після створення замовлення користувач може не побачити його на репліці при лазі >200 мс. Рішення: операції після write на конкретну сесію направляти на мастер протягом 5–10 секунд.

Синхронізація файлів: S3 vs rsync

Файли upload/ мають бути доступні на всіх нодах. Рекомендуємо S3-сумісне сховище (Yandex Object Storage, AWS S3, MinIO). Бітрікс вміє працювати з S3 через модуль bitrix.cloud або кастомний обробник. CDN перед S3 роздає файли з найближчого регіону. Якщо S3 не підходить, використовуємо односторонній rsync з мастера на репліку */1 * * * * rsync -az --delete /var/www/bitrix/upload/ ekb-storage:/var/www/bitrix/upload/. Завантаження файлів на регіональних нодах заборонено — весь upload проксіюється на мастер-регіон.

При інтеграції з 1С через CommerceML важливо враховувати, що обмін файлами має відбуватися через мастер-регіон.

Redis: розподілені сесії та кеш

Сесії користувачів мають бути доступні на будь-якій ноді. Використовуємо Redis з реплікацією (Sentinel або Cluster). Redis з реплікацією дає затримку читання сесії до 1 мс, тоді як файлові сесії — до 50 мс, тобто у 50 разів швидше. Налаштування в /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 Cluster з cross-region реплікацією.

Що можна регіоналізувати, а що ні?

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

location /bitrix/components/bitrix/sale. {
    proxy_pass http://msk_master;  # замовлення завжди в MSK
}

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

Що входить в роботу?

Налаштування geo-кластера включає: проєктування архітектури, розгортання реплікації БД, Redis-кластера, синхронізації файлів, GeoDNS, балансувальника, проведення навантажувального тестування та аварійної тренування (drill). Також передаємо документацію, доступи та навчання ваших інженерів. Вартість розраховується індивідуально — зв'яжіться з нами для попередньої оцінки вашого проєкту. Ми гарантуємо індивідуальний підхід.

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

Типові проблеми при geo-кластеризації: затримка реплікації > 500 мс (вирішується оптимізацією каналу та налаштуванням MySQL), конфлікт файлів при двосторонній синхронізації (заборонити завантаження на регіональних нодах), Redis split-brain при розриві (моніторинг і ручний failover).

Замовте попередню оцінку вашого проєкту — ми гарантуємо індивідуальний підхід. Налаштування geo-кластера підходить як для сайтів на 1С-Бітрікс, так і для корпоративних порталів Бітрікс24.

Кластеризація 1С-Бітрікс

Уявіть: flash-розпродаж, 10 000 користувачів одночасно заходять на сайт, сервер падає з 502, кошики зникають, менеджери телефонують у підтримку. Ми бачили це десятки разів. Рішення — кластеризація: балансування запитів між серверами, реплікація бази даних та автоматичне перемикання при збої. Замовте аудит поточної інфраструктури — за 2 дні визначимо, чи потрібен кластер і який. Наш досвід — 40+ високонавантажених проектів на Бітрікс.

Чому кластеризація 1С-Бітрікс критична для відмовостійкості?

80-90% запитів у типовому проекті — SELECT. Каталог, картки, фільтри — все читання. Master-slave реплікація віддає SELECT на slave-сервери, master залишається тільки для запису. Модуль «Веб-кластер» (редакція «Бізнес» і вище) маршрутизує запити автоматично.

Налаштування, де спотикаються: на master binlog_format = ROW. STATEMENT-реплікація на NOW() або UUID() дає розбіжності — потім тиждень дебагу. Унікальний server-id, включений binary log. На slave — read_only = ON, relay-log. Ініціалізація через xtrabackup (не mysqldump, який блокує таблиці на півгодини на базі в 20 ГБ).

Metric #1 — Seconds_Behind_Master. Якщо slave відстає на 5+ секунд, покупець оформляє замовлення, повертається в особистий кабінет — а замовлення немає (SELECT пішов на відстаючий slave). Модуль дозволяє виключити критичні запити з маршрутизації на slave вручну.

Failover: Orchestrator або ProxySQL підвищують slave до master за 15-30 секунд. Модуль підтримує до 9 slave-з'єднань з налаштовуваними вагами. Перевірка цілісності — pt-table-checksum з Percona Toolkit. Економія на неефективній інфраструктурі — до 40% бюджету.

Ознаки, коли кластеризація необхідна

Не кожному проекту. Конкретні маркери:

• 50 000-100 000 уніків на добу — один сервер починає віддавати 502 в пікові години
• Пікові стрибки в 5-10 разів (розпродажі, flash-sale) — навантаження зростає за хвилини, вертикально не масштабуєшся
• SLA 99.9% (не більше 8.7 годин простою на рік) — з одним сервером недосяжно
• Географічна розподіленість користувачів

Іноді вистачає композитного кешу, оптимізації SQL та вертикального масштабування. Ми чесно скажемо, якщо кластер поки не потрібен. Інвестиції в кластеризацію окупаються за 3-6 місяців при пікових навантаженнях.

Архітектура — чотири рівні

Балансувальник. HAProxy, nginx upstream або хмарний LB. Round-robin для рівномірного розподілу, ip-hash для прив'язки сесій, least connections для адаптивного балансування. Health checks виводять мертві сервери з пулу. SSL-термінація на балансувальнику розвантажує веб-ноди.

Веб-сервери. Ідентичні nginx + php-fpm, кожна з повною копією коду. Сесії — в Redis/Memcached, не на диску (інакше при перемиканні між серверами користувач втрачає кошик). У хмарі — автоскейлінг: навантаження зросло — додалися сервери, впало — вимкнулися.

Кеш. Redis Cluster з шардінгом даних по вузлах. Redis Sentinel для невеликих кластерів. Memcached швидкий, але без persistence. Конфігурація в .settings.php — сервери, ваги, стратегія шардінгу.

Файлове сховище. Завантаження, картинки — доступні з кожної ноди. NFS для 2-3 серверів, але це єдина точка відмови. GlusterFS — розподілена ФС без single point of failure. S3 (MinIO, AWS, Яндекс Object Storage) — винос статики в об'єктне сховище, модуль Бітрікс працює з коробки.

Як забезпечити failover на кожному рівні кластера?

Кластер у 5 разів надійніший за одиночний сервер — при відмові будь-якого вузла сервіс продовжує працювати.

Типові помилки при налаштуванні кластера

• Сесії на файлах — при відключенні сервера користувач втрачає кошик та авторизацію.
• Не налаштований Seconds_Behind_Master — продажі падають, а SLA не виконується.
• Одна точка відмови на рівні файлового сховища (NFS без реплікації).
• Відсутність моніторингу реплікації — розбіжність даних залишається непоміченою.

Ми включаємо перевірку всіх цих точок в аудит та тестування.

Процес роботи

1. Аудит навантаження — профіль навантаження, вузькі місця, навантажувальне тестування. Знаходимо стелю одиночного сервера.
2. Проектування — компоненти під вимоги та бюджет. Не всім потрібен GlusterFS — іноді вистачить NFS та бекапів.
3. Інфраструктура — сервери, мережа, файрволи. Ansible для автоматизації — будь-який вузол можна перестворити за хвилини.
4. Міграція — перенесення з мінімальним простоєм. Компоненти підключаються послідовно, кожен крок з перевіркою.
5. Тестування — імітація пікових умов. Ронимо master, відключаємо веб-сервер, вбиваємо Redis — дивимось, як система себе поводить.
6. Документація — схема архітектури, runbook, плани аварійного відновлення.

Що входить в роботу з кластеризації?

Строки

Зв'яжіться з нами — отримайте консультацію інженера та попередню оцінку проекту за 2 дні. Ми розрахуємо вартість індивідуально під ваші завдання. Замовте аудит — дізнайтеся точну архітектуру та бюджет.