Настройка отказоустойчивости Битрикс24 On-Premise

Настройка отказоустойчивости Битрикс24 On-Premise

Отказоустойчивость — это не кластер ради кластера. Это ответ на вопрос: что произойдёт, когда упадёт каждый из компонентов системы, и как быстро она восстановится? Для Битрикс24 On-Premise цели нужно определить заранее: SLA 99.9% (8.7 часов простоя в год) принципиально отличается от SLA 99.99% (52 минуты).

Анализ точек отказа (Single Point of Failure)

Прежде чем строить отказоустойчивость, найдите все SPOF в вашей инсталляции:

Keepalived + Virtual IP для балансировщика

Самое критичное — балансировщик нагрузки сам не должен быть SPOF:

# /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 секунды.

Автофейловер базы данных

Ручное переключение Master → Slave при аварии — это 15–30 минут downtime. Автоматический фейловер через Orchestrator или MHA:

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

Отказоустойчивость стоит денег — минимум удвоение инфраструктуры. Но стоимость одного часа простоя корпоративного портала для 200 сотрудников оправдывает эти затраты. Считайте ROI перед проектированием архитектуры.