Настройка горизонтального масштабирования 1С-Битрикс
Горизонтальное масштабирование — добавление узлов вместо увеличения ресурсов одного сервера. Для 1С-Битрикс это означает запуск нескольких веб-серверов за балансировщиком нагрузки при общей базе данных и общем файловом хранилище. Лицензионно это легально только для редакций «Малый бизнес» и выше; «Старт» и «Стандарт» не поддерживают кластер.
Типичный триггер: пиковая нагрузка (распродажи, рекламные кампании), при которой один сервер уходит в своп или упирается в CPU, а простой горизонтальный scale-out не работает из-за несогласованного состояния между узлами.
Что нужно решить для горизонтального масштабирования
Три ключевые проблемы:
- Сессии — PHP-сессии по умолчанию хранятся на диске. Если запросы одного пользователя балансируются на разные серверы, сессия теряется.
- Файлы — загруженные пользователями файлы, генерируемые кешем файлы должны быть доступны всем узлам.
-
Кеш Битрикс — управляемый кеш (
/bitrix/cache/) хранится на диске. При сбросе кеша на одном узле остальные продолжают отдавать устаревшие данные.
Схема инфраструктуры
Internet
→ Load Balancer (nginx / HAProxy / облачный LB)
├─ Web Node 1 (nginx + php-fpm)
├─ Web Node 2 (nginx + php-fpm)
└─ Web Node N (nginx + php-fpm)
↓ общие ресурсы
├─ MySQL Master (запись) + MySQL Slave (чтение)
├─ Redis Cluster (сессии + кеш Битрикс)
└─ NFS / GlusterFS / S3 (общий файловый том)
Сессии в Redis
Битрикс поддерживает хранение сессий в Memcached и Redis нативно. Настройка в /bitrix/.settings.php:
return [
'session' => [
'value' => [
'mode' => 'default',
'handlers' => [
'general' => [
'type' => 'redis',
'host' => '127.0.0.1', // или Redis Sentinel/Cluster адрес
'port' => 6379,
'serializer' => \Redis::SERIALIZER_PHP,
],
],
],
],
];
Для Redis Sentinel (высокая доступность):
'general' => [
'type' => 'redis',
'sentinels' => [
['host' => 'sentinel-1', 'port' => 26379],
['host' => 'sentinel-2', 'port' => 26379],
['host' => 'sentinel-3', 'port' => 26379],
],
'master_name' => 'mymaster',
],
Кеш Битрикс в Redis
Переносим управляемый кеш из файловой системы в Redis:
// /bitrix/.settings.php — секция cache
'cache' => [
'value' => [
'type' => 'redis',
'redis' => [
'host' => '127.0.0.1',
'port' => 6379,
'serializer' => \Redis::SERIALIZER_IGBINARY, // быстрее PHP serializer
],
],
],
igbinary требует установленного PHP-расширения igbinary. Даёт сжатие данных ~40% по сравнению с PHP serialize и быстрее на десериализации.
Для кеша HTML-страниц (составной кеш, bitrix:page.polycore) Redis менее эффективен — там объекты большие. Лучше оставить на NFS или использовать nginx proxy_cache на уровне балансировщика.
Общий файловый том
Директории, которые должны быть общими:
-
/upload/— все загруженные пользователями файлы -
/bitrix/cache/— если кеш файловый (не Redis) -
/bitrix/managed_cache/— то же -
/bitrix/html_pages/— HTML-кеш страниц
NFS — самый простой вариант. На выделенном сервере или NAS:
# На NFS-сервере
echo "/srv/bitrix-shared 10.0.0.0/24(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
exportfs -ra
# На каждом веб-узле
mount -t nfs nfs-server:/srv/bitrix-shared /var/www/bitrix/upload
Запись в /etc/fstab:
nfs-server:/srv/bitrix-shared /var/www/bitrix/upload nfs rw,sync,hard,intr,timeo=30 0 0
GlusterFS — для production: реплицируется между узлами, нет единой точки отказа:
gluster volume create bitrix-shared replica 2 \
node1:/data/gluster node2:/data/gluster
gluster volume start bitrix-shared
S3-совместимое хранилище — для облачных сред. Битрикс поддерживает S3 для хранения файлов через модуль Bitrix\Main\File\Remote\S3. Настройка в /bitrix/.settings.php секция file_storage.
MySQL: репликация чтения
При нескольких веб-узлах нагрузка на БД кратно возрастает. Настраиваем read replica:
// /bitrix/.settings.php — секция connections
'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',
],
],
],
Направляем SELECT-запросы на slave через кастомный Connection Resolver или используем ProxySQL для прозрачного роутинга на уровне драйвера.
Балансировщик нагрузки: nginx upstream
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;
server_name example.com;
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_set_header X-Forwarded-Proto https;
proxy_connect_timeout 5s;
proxy_read_timeout 60s;
}
}
Sticky sessions: нужны ли?
При правильно настроенных сессиях в Redis sticky sessions не нужны. Любой узел обслуживает любой запрос. Исключение — загрузка файлов через uploader.php Битрикс: если файл загружается частями (чанками), все части должны попасть на один узел. Решение — sticky session для PUT/POST-запросов на /upload/ или использование отдельного upload-эндпоинта.
Состав работ
- Аудит текущей архитектуры, план перехода без даунтайма
- Настройка Redis: сессии + кеш Битрикс
- Настройка NFS/GlusterFS для общего хранилища файлов
- Конфигурация nginx upstream и health-checks
- MySQL Master-Slave + ProxySQL или native Битрикс slave connection
- Синхронизация codebase между узлами (rsync/git/Ansible)
- Тестирование при отключении одного из узлов
Сроки: базовый кластер из 2 узлов с Redis и NFS — 2–3 недели. Продакшн-готовая схема с GlusterFS, HA-Redis и мониторингом — 4–6 недель.