Відмовостійкість Бітрікс24 On-Premise: налаштування під ключ

Відмовостійкість Бітрікс24 On-Premise: налаштування під ключ

Уявіть: у вашому Бітрікс24 On-Premise падає сервер бази даних посеред робочого дня. Без репліки та автоматичного фейловера — 30 хвилин простою, втрачені заявки, зрив SLA клієнтам. Або раптово відмовляє NFS — усі файли недоступні, співробітники не можуть завантажити документи, робота паралізована. Типовий простій у 30 хвилин коштує бізнесу від 200 000 гривень. Ми вирішуємо ці сценарії на етапі проектування відмовостійкості. Наш досвід — 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) та документація з експлуатації
• Навчання ваших адміністраторів

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