Когда на единственном сервере Битрикс24 происходит сбой, это может привести к остановке работы всей компании. Представьте, что одновременно работают сотни пользователей, а сервер выходит из строя. Восстановление из бэкапа займёт минимум несколько часов, и часть данных за последние сутки будет потеряна. Это не вымысел — так поступают компании, которые экономят на инфраструктуре.
Почему важна настройка кластера для Битрикс24?
Пик нагрузки — это не редкость. Пятница, конец месяца: отдел продаж закрывает сделки, бухгалтерия выгружает отчёты, HR проводит собеседования через видеозвонки. И в этот момент падает диск на единственном сервере. Всё встало. Кластерная схема спасает от таких ситуаций через избыточность: если один узел выходит из строя, остальные продолжают работу без остановки. А это критично для бизнеса.
Горизонтальное масштабирование позволяет распределять нагрузку между несколькими серверами. Например, при пиковом трафике, когда на систему нагрузка возрастает до 80%, кластер не роняет систему, а распределяет запросы. Разница в отклике интерфейса между одиночным сервером и кластером ощутима. И это меняет всё.
Плановые работы тоже проще. На одиночном сервере обновление или перезагрузка — это всегда окно недоступности. В кластере можно обновлять узлы поочерёдно, не прерывая работу системы.
Что нужно для настройки кластера?
Минимальная конфигурация для кластера Битрикс24 — три сервера: два веб-узла и один балансировщик нагрузки, плюс отдельный узел для базы данных с репликой. На практике к этому добавляется сервер для хранилища (GlusterFS или NFS) и Redis-кластер для сессий. Итого получается от пяти до семи машин даже в минимальной схеме. Виртуальные машины подойдут, но для продакшена лучше смотреть в сторону выделенных серверов или хотя бы виртуалок на гипервизоре с гарантированными ресурсами.
По железу: каждый веб-узел должен тянуть не менее 8 ядер CPU и 16 ГБ RAM. База данных требует ещё больше. Например, для CRM с большими историями сделок и задач лучше 32 ГБ RAM. Диски для MySQL — только SSD, желательно NVMe. Сеть между узлами — гигабит как минимум; для синхронизации файлового хранилища лучше выделить отдельный интерфейс.
По лицензиям: кластерная схема доступна в коробочном Битрикс24 редакции «Энтерпрайз». Без этой редакции встроенные инструменты управления кластером просто не активируются. Операционная система — CentOS 7/8 или Ubuntu 20.04 LTS, на них официально поддерживается установщик Битрикс.
Как правильно настроить кластер для Битрикс24?
Весь процесс логично разбивается на несколько слоёв: сначала файловое хранилище, потом база данных, затем веб-узлы, и только в конце балансировщик. Попытка делать всё одновременно почти всегда приводит к тому, что что-то работает не так, а найти причину сложно.
Файловое хранилище и база данных
Начните с общего файлового хранилища. Оптимальный вариант для Битрикс — GlusterFS с репликацией между двумя нодами. Все веб-серверы монтируют один и тот же том, поэтому загруженные файлы и сгенерированный кеш видны на каждом узле. Настройка занимает около двух-трёх часов: установка пакетов, создание brick-каталогов, инициализация тома с типом replica 2, монтирование на клиентских машинах через fstab. Точки монтирования — /home/bitrix/www и /home/bitrix/ext_www. После монтирования проверьте, что запись и чтение работают с каждого веб-узла, а не только с первого.
База данных — отдельная история. MySQL с репликацией master-slave закрывает минимальные требования по доступности. Для серьёзных нагрузок смотрите в сторону Percona XtraDB Cluster или Galera — они дают multi-master репликацию. А ещё автоматически выводят упавший узел из кластера без ручного вмешательства. В конфиге MySQL обязательно выставьте innodb_buffer_pool_size на 60-70% от объёма RAM сервера базы, включите slow query log с порогом в одну секунду — это потом сильно помогает при диагностике.
Веб-узлы и балансировщик
Веб-узлы настраиваются через BitrixVM — официальный образ на базе CentOS с уже настроенным стеком. На первом узле разворачиваете полноценную установку Битрикс24, прогоняете мастер установки, подключаете общий том и базу. Второй узел добавляется через меню управления кластером в административной панели — система сама синхронизирует конфигурацию PHP, nginx и Apache. Сессии пользователей должны храниться в Redis, а не в файлах. Иначе при переключении между узлами пользователей будет выбрасывать из системы. Это один из самых частых промахов при первой настройке.
Балансировщик нагрузки — nginx или HAProxy. nginx проще в конфигурации и хорошо интегрируется в экосистему BitrixVM. Принципиальный момент: настройте health check для backend-узлов, чтобы балансировщик автоматически убирал упавший сервер из ротации. Алгоритм балансировки — least_conn работает лучше round-robin при неравномерных запросах. SSL-терминацию выносите на балансировщик; веб-узлам не нужно тратить ресурсы на шифрование.
Как обеспечить стабильную работу кластера?
Запуск кластера — это только начало. Работа переходит в режим постоянного наблюдения. Zabbix или Prometheus с Grafana закроют большинство задач мониторинга: CPU, RAM, дисковая активность, сетевые интерфейсы, статус репликации MySQL, размер очередей Redis. Критичные метрики — задержка репликации базы данных и заполненность тома GlusterFS. Задержка больше нескольких секунд говорит о том, что реплика не успевает. И в случае падения мастера можно потерять транзакции. Полный том хранилища роняет сайт мгновенно и без предупреждений.
Алерты настраивайте заранее. Порог в 85% заполнения диска — это уже тревога, 95% — критично. На каждый узел поставьте мониторинг доступности HTTP, а не просто пинг: сервер может отвечать на ping, но nginx при этом упавший.
Регулярное обслуживание включает проверку бэкапов. Это не просто факт создания, а успешное восстановление. Раз в квартал стоит прогнать учебный failover: принудительно отключить один веб-узел и убедиться, что балансировщик убрал его из ротации, а пользователи продолжают работать. Многие узнают о том, что автоматическое переключение не работает, только в момент реального сбоя.
Основные выводы по настройке кластера для Битрикс24
Кластер для коробочного Битрикс24 — это не разовая задача, а архитектурное решение. Несколько вещей, на которые стоит обратить внимание в первую очередь:
- Редакция «Энтерпрайз» — обязательное условие для использования встроенного кластерного функционала Битрикс24
- Redis для сессий — без него балансировщик будет создавать проблемы с авторизацией пользователей
- Мониторинг репликации базы данных — задержка репликации должна быть в алертах с первого дня
- Тестирование failover — плановая проверка переключения раз в квартал, а не надежда на то, что само сработает
Дальнейшее развитие кластера обычно идёт в сторону добавления CDN для статики, вынесения поиска на отдельный Sphinx-узел и настройки репликации между площадками для географически распределённого резервирования. Каждый из этих шагов даёт реальный прирост производительности, но требует отдельного планирования. Если хотите, чтобы кластер настроили быстро и без ошибок с первого раза, обратитесь к технической поддержке и сопровождению Битрикс24.
