Відмовостійкість Бітрікс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 у вашій інсталяції. Використовуємо таблицю ризиків:
| Компонент | Ризик | Рішення |
|---|---|---|
| Веб-сервер (один) | Повний простій при падінні | 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) та документація з експлуатації
- Навчання ваших адміністраторів
Замовте проектування відмовостійкого кластера та отримайте консультацію. Зв'яжіться з нами для аудиту вашої інфраструктури — оцінимо проект за один день.