Єдиний датацентр у Москві дає затримку 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 реплікацією.
Що можна регіоналізувати, а що ні?
| Операція | Можна на регіональній ноді | Примітка |
|---|---|---|
| Читання каталогу | Так | З репліки БД |
| Сторінка товару, категорії | Так | З кешу або репліки |
| Пошук | Так | Elasticsearch з реплікацією |
| Додавання в кошик | Ні | Тільки мастер |
| Оформлення замовлення | Ні | Тільки мастер + мастер БД |
| Завантаження файлів | Ні | Тільки S3 або мастер-нода |
| Авторизація | Ні | Сесії — мастер Redis |
Для Бітрікс-магазину сторінки каталогу віддаються з найближчого регіону, оформлення замовлення — завжди проксіюється в мастер-регіон. Split-routing реалізується на рівні nginx:
location /bitrix/components/bitrix/sale. { proxy_pass http://msk_master; # замовлення завжди в MSK } location / { proxy_pass http://geo_cluster; # решта — найближчий вузол } Що входить в роботу?
Налаштування geo-кластера включає: проєктування архітектури, розгортання реплікації БД, Redis-кластера, синхронізації файлів, GeoDNS, балансувальника, проведення навантажувального тестування та аварійної тренування (drill). Також передаємо документацію, доступи та навчання ваших інженерів. Вартість розраховується індивідуально — зв'яжіться з нами для попередньої оцінки вашого проєкту. Ми гарантуємо індивідуальний підхід.
Терміни налаштування
| Етап | Зміст | Термін |
|---|---|---|
| Проєктування архітектури | Схема, вибір рішень, узгодження RPO/RTO | 2–3 дні |
| Налаштування реплікації БД | GTID, моніторинг лагу, тест failover | 2–3 дні |
| Налаштування Redis + сесії | Sentinel/Cluster, .settings.php | 1–2 дні |
| Синхронізація файлів | S3 або rsync + конфіги nginx | 1–2 дні |
| GeoDNS + балансувальник | Cloudflare/Route53, split-routing nginx | 1–2 дні |
| Навантажувальне тестування та drill | Перевірка failover, вимірювання latency | 2–3 дні |
Типові проблеми при geo-кластеризації: затримка реплікації > 500 мс (вирішується оптимізацією каналу та налаштуванням MySQL), конфлікт файлів при двосторонній синхронізації (заборонити завантаження на регіональних нодах), Redis split-brain при розриві (моніторинг і ручний failover).
Замовте попередню оцінку вашого проєкту — ми гарантуємо індивідуальний підхід. Налаштування geo-кластера підходить як для сайтів на 1С-Бітрікс, так і для корпоративних порталів Бітрікс24.