Налаштування стійкості до відмови Бітрікс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 перед проектуванням архітектури.