Отказоустойчивость Битрикс24 On-Premise: настройка под ключ

Отказоустойчивость Битрикс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 в вашей инсталляции. Используем таблицу рисков:

Почему 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 для различных сценариев

Что входит в работу

• Аудит текущей инфраструктуры и выявление SPOF
• Проектирование отказоустойчивой архитектуры с учётом ваших SLA
• Настройка Keepalived, GlusterFS, Orchestrator, Redis Sentinel, ProxySQL
• Интеграция с мониторингом (Zabbix/Prometheus) и алертингом
• План восстановления (DRP) и документация по эксплуатации
• Обучение ваших администраторов

Закажите проектирование отказоустойчивого кластера и получите консультацию. Свяжитесь с нами для аудита вашей инфраструктуры — оценим проект за один день.