Представьте: ваш интернет-магазин на Битрикс в день распродажи ложится — сервер уходит в своп, страницы грузятся по 30 секунд, менеджеры теряют заказы. Даже мощный standalone-сервер упирается в лимиты CPU и I/O при тысячах параллельных запросов. Для масштабирования интернет-магазина на Битрикс мы часто видим такую картину у клиентов, которые дорастают до 10 000 посетителей в день. Единственное спасение — горизонтальное масштабирование: добавление веб-узлов вместо апгрейда одного сервера. Официально эта возможность доступна начиная с редакции «Малый бизнес». Для Битрикс это не просто кнопка «кластеризовать» — нужно решить три ключевые проблемы: сессии, кеш и файловое хранилище. Наш опыт 10 лет в Битрикс-разработке и более 100 проектов по масштабированию показывает: без правильной архитектуры вы потратите недели на отладку, а результат не даст прироста производительности.
Три узких места, которые нужно устранить
| Проблема | Суть | Решение |
|---|---|---|
| Сессии | PHP-сессии хранятся на диске. Разные узлы теряют сессию пользователя. | Перенос сессий в Redis (или Memcached). |
| Файлы | Загруженные файлы и кеш уникальны для каждого узла. | Общее хранилище (NFS, GlusterFS или S3) для upload/ и каталогов кеша. |
| Кеш Битрикс | Управляемый кеш в файлах — при сбросе на одном узле другие отдают устаревшие данные. | Использовать Redis для кеша (кроме HTML-кеша — он лучше на NFS). |
Как настроить сессии в Redis для Битрикс?
Битрикс поддерживает хранение сессий в Redis нативно. Настройка в /bitrix/.settings.php:
'session' => [ 'value' => [ 'mode' => 'default', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => '127.0.0.1', 'port' => 6379, 'serializer' => \Redis::SERIALIZER_PHP, ], ], ], ], Для высокой доступности используем Redis Sentinel — тогда при отказе мастера сессии не теряются. Настройка аналогична, только указываем sentinels и master_name. Важно установить PHP-расширение redis. Мы предпочитаем Redis, а не Memcached, из-за атомарных операций и встроенной персистентности. В одном проекте сессии в Redis спасли от потери 20 000 корзин во время переключения балансировщика.
Перенос кеша Битрикс в Redis
Управляемый кеш (/bitrix/cache/ и /bitrix/managed_cache/) лучше хранить в Redis. Это ускоряет чтение и устраняет рассинхронизацию между узлами.
'cache' => [ 'value' => [ 'type' => 'redis', 'redis' => [ 'host' => '127.0.0.1', 'port' => 6379, 'serializer' => \Redis::SERIALIZER_IGBINARY, ], ], ], Расширение igbinary сжимает данные на ~40% быстрее PHP-сериализации. Для кеша HTML-страниц (например, bitrix:page.polycore) Redis неэффективен из-за размера объектов — такие страницы кешируем на уровне nginx proxy_cache или оставляем на NFS.
Почему важна репликация MySQL?
При нескольких веб-узлах нагрузка на базу данных растёт пропорционально. Один мастер не справляется с SELECT-запросами. Решение — Master-Slave репликация с разделением запросов. Настройка в /bitrix/.settings.php:
'connections' => [ 'value' => [ 'default' => [ 'className' => '\\Bitrix\\Main\\DB\\MysqlConnection', 'host' => 'mysql-master', 'database' => 'bitrix', 'login' => 'bitrix', 'password' => 'secret', ], 'slave' => [ 'className' => '\\Bitrix\\Main\\DB\\MysqlConnection', 'host' => 'mysql-slave', 'database' => 'bitrix', 'login' => 'bitrix_ro', 'password' => 'secret_ro', ], ], ], Для прозрачного роутинга запросов используем ProxySQL или кастомный Connection Resolver. Это снижает нагрузку на мастер и увеличивает пропускную способность.
Выбор файлового хранилища
| Критерий | NFS | GlusterFS | S3 (MinIO) |
|---|---|---|---|
| Простота настройки | +++ | + | ++ |
| Отказоустойчивость | - | ++ | +++ |
| Производительность | ++ | ++ | + |
| Блокировки файлов | + | + | - |
NFS — простой вариант для 2–3 узлов: быстро монтируется и даёт низкую задержку, но является единой точкой отказа без репликации. GlusterFS сложнее настроить, зато реплицирует данные между узлами и исключает SPOF. S3-совместимые хранилища (например, MinIO) эластичны и не требуют физических серверов, но latency выше, и нужен модуль Bitrix\Main\File\Remote\S3. Для продакшена мы чаще используем GlusterFS — он уже спас не один проект от даунтайма. Пример монтирования NFS:
mount -t nfs nfs-server:/srv/bitrix-shared /var/www/bitrix/upload Конфигурация балансировщика нагрузки
Пример конфигурации nginx с least_conn и health-check
upstream bitrix_backend { least_conn; server web-node-1:80 weight=1 max_fails=3 fail_timeout=30s; server web-node-2:80 weight=1 max_fails=3 fail_timeout=30s; server web-node-3:80 weight=1 max_fails=3 fail_timeout=30s; keepalive 32; } server { listen 443 ssl; location / { proxy_pass http://bitrix_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 5s; proxy_read_timeout 60s; } } При правильной настройке сессий в Redis sticky sessions не нужны — любой узел отвечает на любой запрос. Исключение: загрузка файлов чанками; для неё можно включить sticky по IP или использовать отдельный upload-эндпоинт.
Процесс работы
- Аудит — анализируем текущую архитектуру, нагрузку, узкие места.
- Проектирование — выбираем схему: Redis, хранилище, балансировщик, репликацию.
- Настройка Redis — сессии и кеш, тестирование отказоустойчивости.
- Настройка файлового хранилища — NFS или GlusterFS, синхронизация codebase (git/rsync/Ansible).
- Конфигурация балансировщика — nginx upstream, health-check, SSL termination.
- MySQL репликация — Master-Slave + ProxySQL.
- Тестирование — нагрузочные тесты, проверка при отключении узла.
- Документация и обучение — передача схемы и инструкций.
Что входит в работу
- Архитектурная схема кластера и конфигурационные файлы.
- Настроенные Redis (сессии + кеш) с резервированием через Sentinel.
- Общее файловое хранилище (NFS или GlusterFS) с автоматическим монтированием.
- Балансировщик nginx с health-check и SSL termination.
- Репликация MySQL с ProxySQL для распределения запросов.
- Нагрузочное тестирование и отчёт по производительности.
- Документация по эксплуатации и схема восстановления после сбоев.
- Обучение вашей команды базовым операциям.
- Пост-продакшн поддержка в течение месяца.
Сроки и стоимость
Базовая настройка (2 узла, Redis, NFS, балансировка) занимает 2–3 недели. Продакшн-схема с GlusterFS, Redis Sentinel, мониторингом и автоматизацией — 4–6 недель. Стоимость рассчитывается индивидуально после аудита. Экономия на отказе от дорогостоящего апгрейда сервера может достигать 60%. Снижение затрат на серверную инфраструктуру до 40% по сравнению с монолитным решением. Закажите аудит вашего проекта — наши инженеры оценят возможность масштабирования за 2 дня. Получите консультацию по выбору оптимальной схемы кластеризации.