Веб-кластер 1С-Битрикс — это набор технологий модуля cluster, позволяющий распределить нагрузку между несколькими серверами и обеспечить отказоустойчивость. Разберём его архитектуру по слоям: веб, кеш, база данных и общие данные.
Из чего состоит кластер
Модуль cluster объединяет четыре независимых механизма, которые можно включать по отдельности. В административной панели они сгруппированы в разделе Настройки → Веб-кластер:
- Группа веб-серверов — несколько идентичных веб-нод (nginx + PHP-FPM + ядро Битрикс) за балансировщиком.
- Репликация БД — MySQL master-slave: запись на мастер, чтение распределяется по репликам.
- Memcached — общий распределённый кеш и хранилище сессий для всех веб-нод.
- Шардинг — вертикальный (модули в отдельные БД) и горизонтальный (данные по серверам).
Веб-слой и балансировка
Все веб-ноды должны быть идентичны: одна версия ядра, одинаковый код и конфигурация. Перед ними ставится балансировщик — nginx (upstream) или HAProxy. Он распределяет входящие запросы и выводит из ротации упавшие узлы.
Ключевое требование к веб-слою — отсутствие локального состояния. Нода не должна хранить у себя ничего уникального: ни сессии, ни загруженные файлы, ни локальный кеш, который расходится с соседями. Иначе при переключении пользователя на другую ноду он «потеряет» авторизацию или корзину.
upstream bitrix_web {
server 10.0.0.11:80;
server 10.0.0.12:80;
server 10.0.0.13:80;
}Для сохранения привязки к ноде допустима ip_hash или sticky-сессии, но правильнее вынести состояние наружу и балансировать без липкости.
Слой базы данных
Битрикс использует MySQL-репликацию master-slave. Все INSERT/UPDATE/DELETE идут на мастер, а SELECT ядро автоматически направляет на реплики через модуль cluster. Разработчик подключает реплику в панели, и API сам маршрутизирует запросы.
Для операций, где важна консистентность сразу после записи, есть механизм фиксации чтения на мастере:
global $DB;
$DB->StartUsingMasterOnly();
// ... чтение свежих данных с мастера ...
$DB->StopUsingMasterOnly();По умолчанию Битрикс и сам держит соединение на мастере в рамках запроса после операций записи, но для сложной логики явное управление надёжнее.
Кеш и сессии
В кластере кеш и сессии нельзя хранить локально на ноде — они должны быть общими. Битрикс поддерживает несколько бэкендов:
| Данные | Где хранить в кластере |
|---|---|
| Кеш управляемый | memcached (кластер) или Redis |
| Сессии | БД или memcached/Redis |
| Загруженные файлы | Общее хранилище / синхронизация |
Бэкенд кеша задаётся в bitrix/.settings.php в секции cache. Для memcached указывается пул серверов, ключи распределяются по ним хешированием.
Синхронизация файлов
Загруженные пользователями файлы (/upload/) должны быть доступны всем нодам одинаково. Варианты:
- Общее сетевое хранилище — NFS/GlusterFS, смонтированное на все ноды. Просто, но добавляет сетевую задержку и точку отказа.
- Двусторонняя репликация —
csync2,lsyncdили встроенный механизм модуля для копирования файлов между нодами. - Внешнее объектное хранилище — S3-совместимое облако через модуль
clouds, тогда файлы вообще не лежат на нодах.
/bitrix/managed_cache/ и /bitrix/stack_cache/ при локальном хранении. Их держат либо в memcached, либо синхронизируют, иначе ноды отдают разный контент.Мониторинг состояния кластера
Битрикс показывает состояние узлов в разделе Веб-кластер: доступность реплик, отставание (Seconds_Behind_Master), процент распределения нагрузки чтения. Ноду можно временно отключить от балансировки чтений прямо из панели — удобно для обслуживания.
- Следите за отставанием реплик: большое отставание ведёт к чтению устаревших данных.
- Контролируйте hit rate memcached — низкий процент попаданий обесценивает распределённый кеш.
- На уровне балансировщика настройте health-check, чтобы упавшая нода мгновенно выпадала из ротации.
Итог
Архитектура веб-кластера Битрикс строится на разделении состояния: веб-ноды остаются stateless, база масштабируется репликацией, кеш и сессии выносятся в общий memcached/БД, а файлы — в общее хранилище. Модуль cluster связывает эти слои и даёт единую панель управления.
Мы разворачиваем такие конфигурации под ключ: подбираем схему репликации и балансировки, выносим сессии и кеш, настраиваем синхронизацию файлов и мониторинг. Если проект перерастает один сервер — поможем спроектировать кластер, который масштабируется добавлением нод.
Частые вопросы
Можно ли включить только репликацию, без остального кластера?
Да. Компоненты модуля cluster независимы: можно развернуть только master-slave для распределения чтений, а memcached и балансировку добавить позже.
Обязательно ли все веб-ноды делать одинаковыми?
Да. Ноды должны иметь идентичный код, версию ядра и конфигурацию. Иначе при балансировке пользователь получит разное поведение на разных узлах.
Как обеспечить чтение свежих данных сразу после записи?
Использовать принудительное чтение с мастера через StartUsingMasterOnly()/StopUsingMasterOnly() для критичных операций, чтобы обойти отставание реплик.
Где хранить сессии в кластере?
В общем хранилище — в базе данных или в memcached/Redis. Локальные файловые сессии на ноде в кластере использовать нельзя, они сломают авторизацию при переключении узлов.
Что делать с загруженными файлами?
Вынести на общее хранилище (NFS/GlusterFS), настроить репликацию между нодами или использовать облачное объектное хранилище через модуль clouds.
Как балансировать веб-ноды?
Обычно nginx upstream или HAProxy перед нодами с health-check. При stateless-нодах липкость сессий не нужна; при необходимости применяют ip_hash.
Как понять, что реплика отстаёт?
В разделе «Веб-кластер» и в статусе MySQL смотрят Seconds_Behind_Master. Большое отставание означает риск чтения устаревших данных с реплики.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.