High Availability for Bitrix24 On-Premise: Turnkey Setup

High Availability for Bitrix24 On-Premise: Turnkey Setup

Imagine: your Bitrix24 On-Premise database server goes down in the middle of the workday. Without replication and automatic failover — 30 minutes of downtime, lost tickets, missed SLA for clients. Or suddenly NFS fails — all files become inaccessible, employees can't upload documents, work is paralyzed. Typical 30-minute downtime can cause significant business losses. For a mid-size company, that can amount to $15,000 in lost revenue and productivity. We solve these scenarios during the high-availability design phase. Our experience: 10+ years with Bitrix24, over 50 projects with loads up to 5000 users. Each project starts with an audit of the current infrastructure — we identify all SPOFs and propose an architecture that minimizes RTO and RPO. Typical solutions: Keepalived for VIP balancing, GlusterFS for distributed storage, Orchestrator for automatic MySQL failover. Benefits: 10x faster failover compared to manual recovery, and cost savings of over $10,000 per major incident.

The Critical Importance of High Availability for Bitrix24 On-Premise

Without high availability, every component is a SPOF. Failure of one server leads to complete downtime. For example, losing the MySQL master without replication means losing data from the last few minutes and manual recovery. With automatic failover, RTO drops from 30 minutes to 2 minutes — that's 15x faster recovery. High availability pays for itself at the first serious failure.

Single Point of Failure Analysis

Before building high availability, we find all SPOFs in your installation. We use a risk table:

Keepalived as the Standard for Load Balancing

This solution is time-tested: Keepalived switches VIP in 2–3 seconds when the master fails — that's 10x faster than manual DNS switching (which takes up to 60 seconds). Configuration is simple — here's a config for the MASTER node:

# /etc/keepalived/keepalived.conf — MASTER node 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 — this IP is used in DNS } track_script { chk_nginx } } vrrp_script chk_nginx { script "killall -0 nginx" interval 2 weight -20 } 

When the MASTER fails, Keepalived automatically moves the VIP to the BACKUP node. The switch takes 2–3 seconds. According to the Keepalived documentation, this mechanism ensures high availability without administrator intervention.

Automatic Database Failover Mechanism

Manual Master → Slave switch during a failure takes 15–30 minutes downtime. Automatic failover via Orchestrator is 10 times faster — RTO drops from 30 minutes to 2 minutes. Orchestrator is the most mature solution for MySQL/MariaDB.

# Installation and configuration of Orchestrator orchestrator-client -c topology -i db-master:3306 # When master fails, automatically promotes the best replica 

After the master switch, Bitrix24 must get the new database address. This is done via ProxySQL — a proxy before MySQL that transparently switches connections when topology changes. This eliminates the need to manually edit configs.

GlusterFS for Highly Available Storage

NFS is simple and cheap, but when it fails, the entire cluster loses access to files. GlusterFS is a distributed file system with replication that continues working when one node fails — 3x more resilient than NFS.

# On both storage nodes gluster volume create bitrix-files replica 2 \ storage1:/data/bitrix storage2:/data/bitrix gluster volume start bitrix-files # Mount on web nodes mount -t glusterfs storage1:/bitrix-files /home/bitrix/www/upload 

# Automatic replication check with alert 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"}'