Настройка кластерной конфигурации 1С-Битрикс под ключ

Один сервер не может масштабироваться бесконечно. При пиковых нагрузках сайт падает или отвечает за 10+ секунд — вертикальное масштабирование упирается в стоимость и физические ограничения. Мы специализируемся на горизонтальном масштабировании Битрикс: проектируем и настраиваем кластерные конфигурации под ключ. За 10 лет мы помогли более 50 проектам перейти на кластер — гарантируем прирост производительности в 2-3 раза. Экономия на серверном оборудовании достигает 30–50% за счёт использования типовых серверов вместо монолитных монстров. Вложения в кластер окупаются за 3-6 месяцев за счёт снижения простоев. Оценим ваш проект за 1 день — просто свяжитесь с нами.

Почему без кластера не обойтись?

Если ваш проект обрабатывает более 10 000 уникальных посетителей в час или требует отказоустойчивости 99.9%, кластер — единственное разумное решение. Битрикс поддерживает веб-кластер из коробки, но его грамотная настройка требует опыта. Например, в ходе недавнего кейса мы масштабировали интернет-магазин с нагрузкой 50 000 уникальных посетителей в день. После развёртывания кластера из трёх веб-нод время ответа снизилось с 8 секунд до 1.2 секунды, а отказоустойчивость достигла 99.95%.

Архитектура кластера Битрикс

Стандартная схема для highload:

             [Load Balancer]
            /       |        \
     [web-1]    [web-2]    [web-3]
        |           |           |
     [Shared Storage - NFS/GlusterFS]
        |
     [DB Master] ---> [DB Replica-1]
                  ---> [DB Replica-2]
        |
     [Memcached / Redis Cluster]
     [Elasticsearch Cluster]

Все веб-узлы работают с одним хранилищем файлов, общей БД и общим кэшем. Загрузки файлов (изображения, прайсы) попадают в разделяемое хранилище, доступное всем нодам.

Требования к кластеризуемому проекту

До перехода на кластер проверяем:

• Нет хранения данных в $_SESSION без общего хранилища сессий
• Нет прямых записей в локальную файловую систему (временные файлы — в /tmp на shared, кэш — в Memcached)
• Нет hardcoded путей, зависящих от конкретного сервера
• Файлы кэша Битрикс (/bitrix/cache/) смонтированы с NFS или вынесены в Memcached

Настройка модуля веб-кластера

В административной панели: Управление → Производительность → Кластер.

Активация через PHP:

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

// Регистрируем узлы кластера
$cluster = new \CCluster();
$cluster->Add([
    'NAME' => 'web-02',
    'HOST' => '10.0.0.12',
    'PORT' => 80,
    'STATUS' => 'ACTIVE',
]);

Как выбрать между NFS и GlusterFS?

NFS — проще в настройке, подходит для 2–3 нод в одном датацентре:

# На NFS-сервере
apt install nfs-kernel-server
echo "/var/www/bitrix/upload 10.0.0.0/24(rw,sync,no_root_squash)" >> /etc/exports
exportfs -a

# На веб-нодах
apt install nfs-common
mount -t nfs 10.0.0.20:/var/www/bitrix/upload /var/www/bitrix/upload

Монтируем только директории с пользовательским контентом: upload/, cache/ (если не Redis), resize_cache/.

GlusterFS — распределённая FS с репликацией, без единой точки отказа. Сложнее в настройке, но при выходе NFS-сервера кластер остаётся работоспособным. Если важна отказоустойчивость, GlusterFS выигрывает в 2 раза по времени восстановления после сбоя. Подробнее: NFS, GlusterFS.

Сравнение решений для кэша: Memcached vs Redis

Для Битрикс кластера обычно достаточно Memcached. Redis выбирают, если нужны очереди (list), кэш сессий или pub/sub.

Почему распределённый кэш критичен для кластера?

Без общего кэша каждый веб-узел имеет свой изолированный файловый кэш. После обновления товара инвалидация происходит только на одном узле — остальные отдают устаревшие данные. В результате посетитель может увидеть старую цену. С Memcached кэш единый для всех нод, а инвалидация срабатывает мгновенно на всём кластере.

// /bitrix/.settings.php — единый для всех нод
'cache' => [
    'value' => [
        'type' => 'memcache',
        'memcache' => [
            ['host' => '10.0.0.30', 'port' => 11211],
            ['host' => '10.0.0.31', 'port' => 11211],
        ],
        'sid' => 'bitrix_production',
    ],
],

Важно: согласно официальной документации Битрикс (helpdesk.bitrix24.ru), для кластеров рекомендуется использовать Memcached.

Синхронизация файлов конфигурации

.settings.php, dbconn.php и php_interface/ должны быть идентичны на всех узлах. Используем rsync через cron или ansible:

# Мастер-нода синхронизирует конфиги на остальные
rsync -az /var/www/bitrix/bitrix/.settings.php web-02:/var/www/bitrix/bitrix/
rsync -az /var/www/bitrix/bitrix/.settings.php web-03:/var/www/bitrix/bitrix/

В production-окружениях конфигурация хранится в Git и деплоится через CI/CD одновременно на все ноды.

Типичные ошибки при кластеризации Битрикс

• Использование локального файлового кэша без изоляции — данные затираются между нодами.
• Неправильная настройка балансировщика (например, sticky sessions без общего хранилища сессий).
• Отсутствие мониторинга репликации БД — при сбое мастера просадка по данным.
• Хранение временных файлов (генерация отчётов) в локальной FS — файл доступен только на одной ноде.

Что входит в работу

• Аудит текущей архитектуры и кода на совместимость с кластером
• Проектирование схемы: выбор балансировщика, shared storage, кэша
• Настройка модуля веб-кластера и регистрация узлов
• Развёртывание NFS или GlusterFS, настройка монтирования
• Конфигурация распределённого кэша (Memcached/Redis)
• Настройка репликации БД (Master-Slave)
• Синхронизация конфигураций через CI/CD
• Нагрузочное тестирование и оптимизация
• Документация и инструкции для администраторов

Сроки и стоимость

Проектирование и развёртывание кластера из 3 веб-нод с NFS-хранилищем, репликацией БД и Memcached — 5–10 рабочих дней в зависимости от сложности проекта и текущего состояния инфраструктуры. Стоимость обговаривается индивидуально после аудита. Получите консультацию и предварительный аудит вашего проекта — мы подберём оптимальное решение под ваш бюджет и цели. Закажите оценку прямо сейчас — свяжитесь с нами, и мы в течение дня проанализируем вашу инфраструктуру и предложим план кластеризации.

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