Отказоустойчивость Битрикс24 On-Premise: настройка под ключ
Представьте: в вашем Битрикс24 On-Premise падает сервер базы данных посреди рабочего дня. Без реплики и автоматического фейловера — 30 минут простоя, потерянные заявки, срыв SLA клиентам. Или внезапно отказывает NFS — все файлы недоступны, сотрудники не могут загрузить документы, работа парализована. Типичный простой в 30 минут стоит бизнесу от $1.8k–2.6k. Мы решаем эти сценарии на этапе проектирования отказоустойчивости. Наш опыт — 10+ лет с Битрикс24, более 50 проектов с нагрузкой до 5000 пользователей. Каждый проект начинается с аудита текущей инфраструктуры — выявляем все SPOF и предлагаем архитектуру, которая минимизирует RTO и RPO. Типовые решения: Keepalived для балансировки VIP, GlusterFS для распределённого хранилища, Orchestrator для автоматического фейловера MySQL. В результате вы получаете SLA 99.99% и уверенность в работе системы.
Почему отказоустойчивость Битрикс24 On-Premise критична?
Без отказоустойчивости каждый компонент — SPOF. Падение одного сервера приводит к полному простою. Например, потеря мастер-ноды MySQL без реплики означает потерю данных за последние минуты и ручное восстановление. С автоматическим фейловером RTO снижается с 30 минут до 2 минут. Это разница между потерей заказов и штатной работой. Отказоустойчивость окупается при первом серьёзном сбое.
Анализ точек отказа (Single Point of Failure)
Прежде чем строить отказоустойчивость, находим все SPOF в вашей инсталляции. Используем таблицу рисков:
| Компонент | Риск | Решение |
|---|---|---|
| Веб-сервер (один) | Полный простой при падении | Active-Active кластер |
| MySQL без реплики | Потеря данных + простой | Master-Slave + автофейловер |
| NFS (один) | Потеря файлов + простой | GlusterFS или S3 |
| Redis (один) | Потеря сессий (logout всех) | Redis Sentinel |
| Балансировщик | Полный простой | Keepalived + VIP |
| DNS | Недоступность по имени | Два DNS-сервера или Anycast |
Почему Keepalived — стандарт для балансировки?
Это решение проверено годами: Keepalived переключает VIP за 2–3 секунды при падении мастера. Ручное переключение DNS заняло бы минуты. Настройка проста — приведём конфиг для MASTER-ноды:
# /etc/keepalived/keepalived.conf — MASTER-нода vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass your_secret } virtual_ipaddress { 192.168.1.100/24 # VIP — этот IP прописан в DNS } track_script { chk_nginx } } vrrp_script chk_nginx { script "killall -0 nginx" interval 2 weight -20 } При падении MASTER Keepalived автоматически переносит VIP на BACKUP-ноду. Переключение занимает 2–3 секунды. Согласно документации Keepalived, такой механизм обеспечивает высокую доступность без участия администратора.
Как работает автофейловер базы данных?
Ручное переключение Master → Slave при аварии — это 15–30 минут downtime. Автоматический фейловер через Orchestrator в 10 раз быстрее — RTO снижается с 30 минут до 2 минут. Orchestrator — наиболее зрелое решение для MySQL/MariaDB.
# Установка и настройка Orchestrator orchestrator-client -c topology -i db-master:3306 # При падении мастера автоматически промоутирует лучшую реплику После смены мастера Битрикс24 должен получить новый адрес БД. Реализуется через ProxySQL — прокси перед MySQL, который прозрачно переключает соединения при смене топологии. Это устраняет необходимость ручного изменения конфигов.
GlusterFS для отказоустойчивого хранилища
NFS — простой и дешёвый вариант, но при его падении весь кластер теряет доступ к файлам. GlusterFS — распределённая файловая система с репликацией, которая продолжает работу при отказе одного узла.
# На обоих узлах хранилища gluster volume create bitrix-files replica 2 \ storage1:/data/bitrix storage2:/data/bitrix gluster volume start bitrix-files # Монтирование на веб-узлах mount -t glusterfs storage1:/bitrix-files /home/bitrix/www/upload При падении одного узла GlusterFS продолжает работать на втором. Записи синхронизируются автоматически при восстановлении.
Health checks и автовосстановление
Мониторинг без автодействий — половина работы. Настройте автоматические реакции:
- nginx health_check с исключением больного backend из пула
- systemd автоперезапуск для nginx, php-fpm, redis при краше
- Cron-проверка репликационного лага с алертом в Telegram при lag > 60 сек
# Автоматическая проверка репликации с алертом mysql -u monitor -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master" | \ awk '{if($2>60) system("curl -s -X POST https://api.telegram.org/bot$TOKEN/sendMessage -d chat_id=$CHAT -d text=REPLICA_LAG_ALERT")}' RTO/RPO для различных сценариев
| Сценарий | RPO (потеря данных) | RTO (время восстановления) |
|---|---|---|
| Падение веб-узла | 0 | < 5 сек (keepalived) |
| Падение мастера БД | < 5 сек | 1–2 мин (Orchestrator) |
| Падение NFS/GlusterFS | 0 (репликация) | < 30 сек |
| Полная потеря датацентра | По RPO бэкапа (1 час) | 2–4 часа |
| Сбой диска на одном узле | 0 | < 1 мин (переключение на реплику) |
Что входит в работу
- Аудит текущей инфраструктуры и выявление SPOF
- Проектирование отказоустойчивой архитектуры с учётом ваших SLA
- Настройка Keepalived, GlusterFS, Orchestrator, Redis Sentinel, ProxySQL
- Интеграция с мониторингом (Zabbix/Prometheus) и алертингом
- План восстановления (DRP) и документация по эксплуатации
- Обучение ваших администраторов
Закажите проектирование отказоустойчивого кластера и получите консультацию. Свяжитесь с нами для аудита вашей инфраструктуры — оценим проект за один день.