Единственный датацентр в Москве даёт задержку 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.