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