Настройка кластера 1С-Битрикс: балансировка, репликация, синхронизация

Вы запускаете рекламу, сайт на 1С-Битрикс захлёстывает 3000+ одновременных посетителей, и сервер ложится. MySQL упирается в 100% CPU, кэш сбрасывается каждые две секунды, пользователи видят 502 Bad Gateway. Знакомая картина? Типовое решение — веб-кластер из трёх нод с балансировкой нагрузки и репликацией базы данных. Правильная настройка такого кластера позволяет выдерживать до 10 000 посетителей, а стоимость владения снижается на 30–50% за счёт дешёвых реплик. Мы настроили уже 50+ кластеров и знаем, где сыпятся грабли.

Модуль «Веб-кластер» в Битрикс — это набор механизмов, которые заставляют несколько серверов работать как единое целое: общий кэш, репликация файлов, единые сессии. Без правильной конфигурации каждого компонента кластер работает непредсказуемо — один узел инвалидирует кэш, другой отдаёт старые данные. Ниже разберём, что входит в модуль, как настроить read/write split и синхронизацию файлов, и какие подводные камни вас ждут.

Что входит в модуль веб-кластера

Модуль cluster (BitrixVM Enterprise или отдельная лицензия) включает:

• Управление узлами — регистрация серверов, мониторинг доступности.
• Балансировка нагрузки — перенаправление запросов между узлами.
• Синхронизация кэша — инвалидация по всем нодам через общий Memcached.
• Репликация файлов — синхронизация upload/ между серверами.
• Репликация БД — настройка read/write split для MySQL.

Официальная документация 1С-Битрикс: «Модуль cluster позволяет объединить несколько серверов в кластер для обеспечения отказоустойчивости и масштабирования».

Как активировать и настроить узлы?

Модуль устанавливается на каждой ноде, но управляется через одну административную панель. Добавление ноды через API:

\Bitrix\Main\Loader::includeModule('cluster');

$result = \Bitrix\Cluster\Node::add([
    'NAME'      => 'web-02',
    'HOST'      => '10.0.0.12',
    'PORT'      => 443,
    'HTTPS'     => 'Y',
    'STATUS'    => 'ACTIVE',
    'SORT'      => 100,
]);

if ($result->isSuccess()) {
    echo 'Нода добавлена: ' . $result->getId();
}

Read/Write Split для базы данных

Самая ценная часть кластера для highload — направление SELECT-запросов на реплики, а INSERT/UPDATE/DELETE на мастер. Снижает нагрузку на мастер на 60–80% при типичном соотношении чтение/запись 10:1.

В .settings.php:

'connections' => [
    'value' => [
        'default' => [
            'className' => '\Bitrix\Main\DB\MysqlConnection',
            'host'      => 'db-master:3306',
            'database'  => 'bitrix',
            'login'     => 'bitrix',
            'password'  => 'secret',
        ],
        'slave'  => [
            'className' => '\Bitrix\Main\DB\MysqlConnection',
            'host'      => 'db-replica:3306',
            'database'  => 'bitrix',
            'login'     => 'bitrix_ro',
            'password'  => 'secret_ro',
        ],
    ],
],

Настройка в модуле кластера указывает, какие запросы идут на какое соединение. Транзакционные запросы принудительно маршрутизируются на мастер вне зависимости от типа операции.

Синхронизация файлов: встроенный модуль vs lsyncd

Встроенный модуль умеет синхронизировать файлы между нодами через HTTP-запросы к агентам. При загрузке файла на ноде-1 модуль автоматически копирует его на ноду-2 и ноду-3. Для защиты агента ограничьте доступ по IP в Nginx: allow 10.0.0.0/24; deny all;.

Альтернатива — inotify + rsync через lsyncd. Работает быстрее и надёжнее для больших объёмов. Пример конфига lsyncd:

sync {
    default.rsync,
    source = "/var/www/bitrix/upload",
    target = "web-02:/var/www/bitrix/upload",
    delay = 1,
    rsync = {
        compress = false,
        owner = true,
        perms = true,
    }
}

Почему сессии нужно хранить в Memcached?

Сессии в файловой системе в кластере неработоспособны — запросы от одного пользователя могут попадать на разные ноды. Переводим на Memcached или Redis. Sticky sessions на балансировщике — временное решение, не рекомендуется: при выходе ноды из строя все её пользователи теряют сессию. Мы всегда настраиваем централизованное хранилище.

Пример конфигурации PHP для Memcached:

session.save_handler = memcached
session.save_path = "10.0.0.30:11211,10.0.0.31:11211"

Сравнение балансировщиков для веб-кластера 1С-Битрикс

Как выполнить проверку работы кластера?

Используйте shell-скрипт для проверки статуса нод и очистки кэша:

# Проверка статуса нод
curl http://admin:[email protected]/bitrix/admin/cluster_nodes.php?ajax=Y

# Очистка кэша на всех нодах
php -r "\Bitrix\Main\Loader::includeModule('cluster'); \Bitrix\Cluster\Cache::clearAll(); echo 'Cache cleared';"

Пошаговая инструкция настройки веб-кластера

1. Установите BitrixVM Enterprise на каждую ноду.
2. Настройте репликацию MySQL: мастер-слейв.
3. В админке Битрикс добавьте ноды в модуль кластера.
4. Настройте read/write split в .settings.php.
5. Выберите способ синхронизации файлов: встроенный или lsyncd.
6. Перенесите сессии на Memcached или Redis.
7. Настройте балансировщик (nginx, haproxy или облачный).
8. Проверьте работоспособность через cluster_nodes.php.

Типичные ошибки при настройке

Чаще всего встречается игнорирование кэширования: без общего Memcached кэш инвалидируется отдельно на каждой ноде, что приводит к неконсистентности данных. Также нередки неправильные права доступа к агентам синхронизации файлов — агент не может прочитать файл или записать его на другую ноду. Отсутствие мониторинга связности нод приводит к тому, что одна нода выпадает, а трафик продолжает на неё направляться. И наконец, использование sticky sessions без централизованного хранилища сессий — при выходе ноды все её пользователи теряют данные.

Подробнее о концепции кластеров читайте в Wikipedia.

Наша команда имеет 5 лет опыта в настройке кластеров 1С-Битрикс. Свяжитесь с нами для аудита вашего кластера — получите план оптимизации под вашу нагрузку. Закажите консультацию, и мы поможем настроить кластер, который выдержит любой пик.

Кластеризация 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% бюджета, что в среднем составляет 300 000 рублей в год для проектов с 50 000+ уникальных посетителей. Подробнее о репликации — MySQL Replication Documentation и Wikipedia: Репликация базы данных.

Признаки, когда кластеризация необходима

Не каждому проекту. Конкретные маркеры:

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

Иногда хватает композитного кэша, оптимизации SQL и вертикального масштабирования. Мы честно скажем, если кластер пока не нужен. Инвестиции в кластеризацию окупаются за 3-6 месяцев при пиковых нагрузках. Средний бюджет проекта — от 150 000 рублей.

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

Балансировщик. 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 дня. Мы рассчитаем стоимость индивидуально под ваши задачи. Закажите аудит — узнайте точную архитектуру и бюджет.