Налаштування горизонтального масштабування 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 або нативне Бітрікс slave connection
- Синхронізація кодової бази між вузлами (rsync/git/Ansible)
- Тестування при відключенні одного з вузлів
Терміни: базовий кластер із 2 вузлів із Redis і NFS — 2–3 тижні. Production-готова схема з GlusterFS, HA-Redis і моніторингом — 4–6 тижнів.