Услуги по кластеризации и масштабированию 1С-Битрикс

Кластеризация 1С-Битрикс

Master-Slave репликация MySQL — ядро всей затеи

Начнём с главного. 80-90% запросов в типичном Битрикс-проекте — это SELECT. Каталог, карточки товаров, фильтры, списки — всё чтение. Master-slave репликация отдаёт эти SELECT на slave-серверы, а master занимается только записью. Модуль «Веб-кластер» (редакция «Бизнес» и выше) маршрутизирует запросы автоматически.

Настройка, где обычно спотыкаются:

На master: binlog_format = ROW. Не STATEMENT — на сложных запросах с NOW(), UUID() или недетерминированными функциями STATEMENT-репликация даёт расхождения между master и slave. Дебажить потом неделю. Плюс обязательно уникальный server-id, включённый binary log.

На slave: read_only = ON, свой server-id, relay-log. Инициализацию делаем через xtrabackup — mysqldump на базе в 20 ГБ заблокирует таблицы на полчаса.

Seconds_Behind_Master — метрика номер один. Если slave отстаёт на 5+ секунд, покупатель оформляет заказ, возвращается в личный кабинет — а заказа там нет, потому что SELECT ушёл на отстающий slave. Модуль «Веб-кластер» позволяет исключать критичные запросы из маршрутизации на slave, но это нужно настраивать руками.

Failover: Orchestrator или ProxySQL промоутят slave в master за 15-30 секунд. Модуль поддерживает до 9 slave-соединений с настраиваемыми весами распределения нагрузки. Проверка целостности — pt-table-checksum из Percona Toolkit, на больших базах без него расхождения неизбежны.

Когда реально нужен кластер

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

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

Иногда хватает композитного кэша, оптимизации SQL и вертикального масштабирования. Мы честно скажем, если кластер пока не нужен.

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

Балансировщик. 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 на каждом уровне

Наш подход

1. Аудит нагрузки — профиль нагрузки, узкие места, нагрузочное тестирование. Находим потолок одиночного сервера.
2. Проектирование — компоненты под требования и бюджет. Не всем нужен GlusterFS — иногда хватит NFS и бэкапов.
3. Инфраструктура — серверы, сеть, файрволы. Ansible для автоматизации — любой узел можно пересоздать за минуты.
4. Миграция — перенос с минимальным простоем. Компоненты подключаются последовательно, каждый шаг с проверкой.
5. Тестирование — имитация пиковых условий. Роняем master, отключаем веб-сервер, убиваем Redis — смотрим, как система себя ведёт.
6. Документация — схема архитектуры, runbook, планы аварийного восстановления.

Сроки