When one server is no longer enough — and this happens at 150–200 concurrent users or when the database grows beyond 50 GB — the question of horizontal scaling arises.
We, certified Bitrix engineers with 7 years of experience, having implemented over 50 clusters for the Enterprise sector (from 3 to 12 nodes), configure Bitrix24 On-Premise clustering turnkey: from auditing the current infrastructure to deploying a production-ready cluster with a guarantee of zero downtime. Our guarantee: the cluster handles peak loads without performance loss, and response time does not exceed 300 ms with 500 concurrent users. Single-server architecture is a risk. Server failure, database overheating, session loss — all of these stop portal operations. Clustering eliminates these risks: failure of any component does not affect availability, and performance scales linearly. We use only proven components — HAProxy, GlusterFS, Redis Sentinel — and set up monitoring based on Prometheus and Grafana.
Why Clustering? Problems and Architecture
- Single point of failure (SPOF) — failure of any node does not affect availability.
- Database overload — master-slave split reduces write load by up to 40%.
- Session loss when switching nodes — sticky sessions and shared Redis storage.
A typical production cluster consists of the following components:
[Load Balancer: nginx/HAProxy]
|
┌────┴────┐
[Web 1] [Web 2] ← Application servers (PHP/nginx)
└────┬────┘
|
[Shared Storage: NFS/GlusterFS] ← Shared disk for files
|
┌────┴────┐
[DB Master] ← [DB Replica] ← MySQL/MariaDB replication
|
[Redis Sentinel/Cluster] ← Cache and sessions
Without shared file storage, a cluster does not work: if a user uploaded a file to Web 1, and the next request hits Web 2, the file disappears. NFS is the simplest option, GlusterFS is fault-tolerant. We use GlusterFS for shared storage as it provides replication and high availability. The alternative is NFS with DRBD redundancy.
Core Configuration Steps
How to configure the load balancer for sticky sessions?
Proper load balancer configuration is critical for stable cluster operation. nginx with ip_hash works for office networks where user IPs are stable. For mobile users, HAProxy with cookie persistence is better — it does not lose sessions on IP change. The nginx_sticky_module is a compromise but requires building nginx with the module. HAProxy provides the highest reliability and flexibility in weighting backends.
| Parameter | nginx ip_hash | nginx sticky module | HAProxy cookie |
|---|---|---|---|
| IP dependency | high | low | low |
| Setup complexity | low | medium | medium |
| Reliability | medium | high | high |
| Recommendation | for office | for mobile | universal |
Example HAProxy configuration for sticky sessions
backend bitrix24_backend
balance roundrobin
cookie SERVERID insert indirect nocache
server web1 10.0.1.10:443 check cookie web1
server web2 10.0.1.11:443 check cookie web2
Setting up MySQL replication
Master-Slave replication for read queries. Configuration on master and replica:
-- On master: create replication user
CREATE USER 'replicator'@'db-replica' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'db-replica';
-- In my.cnf of master
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = bitrix24
-- In my.cnf of replica
[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
read_only = 1
Bitrix24 needs to be explicitly told that read queries should go to the replica. Configuration in /bitrix/.settings.php:
'connections' => [
'value' => [
'default' => [
'host' => 'db-master',
'database' => 'bitrix24',
],
'slave' => [
'host' => 'db-replica',
'database' => 'bitrix24',
'handlersocket' => [...],
],
],
],
It is important to monitor replication lag — critical for correct operation. Lag above 30 seconds should raise an alarm.
Why Redis Cluster is necessary for sessions?
User sessions must be stored in a shared Redis, not on each web node's local disk:
// /bitrix/.settings.php — Redis configuration
'cache' => [
'value' => [
'type' => [
'class_name' => '\Bitrix\Main\Data\CacheEngineRedis',
'extension' => 'redis',
],
'redis' => [
'host' => 'redis-sentinel',
'port' => 26379,
],
],
],
'session' => [
'value' => [
'mode' => 'redis',
'redis' => [
'host' => 'redis-sentinel',
'port' => 26379,
],
],
],
Redis Sentinel instead of a single Redis — for automatic failover when the master fails. Sentinel ensures 99.9% uptime, which is 10 times more reliable than a single Redis. Official 1C-Bitrix documentation recommends using Redis Sentinel for critical portals.
Cluster monitoring
| Metric | Tool | Alert threshold |
|---|---|---|
| MySQL replication lag | Prometheus + mysqld_exporter | > 30 seconds |
| RAM usage on web nodes | node_exporter + Grafana | > 85% |
| PHP-FPM queue | php-fpm status | backlog > 10 |
| NFS disk lag | iostat | await > 20ms |
| Redis hit rate | redis-exporter | < 80% |
A cluster without monitoring is a cluster that will break on Friday evening, and you will find out from users, not from the alert system. Additionally, we recommend setting up alerts in Telegram/Slack.
Process
- Audit of current infrastructure and loads (identify bottlenecks).
- Design cluster architecture (load balancers, database, cache).
- Deploy load balancers (nginx/HAProxy) with sticky sessions.
- Configure MySQL Master-Slave replication with lag monitoring.
- Deploy Redis Sentinel or Cluster for sessions and cache.
- Organize shared storage (GlusterFS/NFS).
- Set up monitoring (Prometheus + Grafana) with thresholds and alerts.
- Document configurations and runbook procedures.
- Train your operations team on cluster management.
- Provide 24/7 support for the first month after go-live.
Common mistakes and how to avoid them
- Sticky sessions not configured — users lose carts and login data. Solution: use HAProxy with cookie persistence.
- Replication lag not monitored — reading outdated data. Solution: monitor lag and auto-reconnect.
- Redis without Sentinel — if Redis fails, all sessions are lost. Solution: use Sentinel or Cluster.
- Shared cache between nodes — invalidation issues. Solution: Bitrix24's tagged cache works correctly only with shared Redis.
What's Included
- Comprehensive audit of current infrastructure with bottleneck identification.
- Cluster architecture design tailored to your loads and budget.
- Deployment of all components: load balancers, database, cache, shared storage, monitoring.
- Documentation and runbook for your team.
- Administrator training: typical cluster management scenarios, node addition, updates without downtime.
- 24/7 support for the first month of operation.
Timelines and cost
Clustering setup timelines: from 5 business days for a basic configuration (2 web nodes, master-slave DB, Redis) to 20 business days for a full cluster with monitoring and documentation. Cost is determined individually after an audit, but typical projects range from $5,000 to $15,000 depending on complexity. According to official Bitrix documentation, clustering reduces downtime by 99% compared to single-server setups. Get a consultation on scaling Bitrix24 On-Premise.