1C-Bitrix clustering: fault-tolerant cluster turnkey
Imagine: your Bitrix online store crashes on sale day — the server swaps, pages load in 30 seconds, managers lose orders. Even a powerful standalone server hits CPU and I/O limits under thousands of concurrent requests. For scaling an online store on Bitrix, we often see this picture at clients who reach 10,000 visitors per day. The only rescue is horizontal scaling: adding web nodes instead of upgrading a single server. Officially this feature is available starting from the "Small Business" edition. For Bitrix this is not just a "clustering" button — you need to solve three key problems: sessions, cache, and file storage. Our 10 years of experience in Bitrix development and over 100 scaling projects shows: without correct architecture you'll spend weeks debugging, and the result won't give performance gains.
Three bottlenecks to eliminate
| Problem | Essence | Solution |
|---|---|---|
| Sessions | PHP sessions stored on disk. Different nodes lose user session. | Move sessions to Redis (or Memcached). |
| Files | Uploaded files and cache unique to each node. | Shared storage (NFS, GlusterFS or S3) for upload/ and cache directories. |
| Bitrix cache | Managed cache in files — when cleared on one node, others serve stale data. | Use Redis for cache (except HTML cache — it's better on NFS). |
How to configure sessions in Redis for Bitrix?
Bitrix natively supports storing sessions in Redis. Configuration in /bitrix/.settings.php:
'session' => [
'value' => [
'mode' => 'default',
'handlers' => [
'general' => [
'type' => 'redis',
'host' => '127.0.0.1',
'port' => 6379,
'serializer' => \Redis::SERIALIZER_PHP,
],
],
],
],
For high availability we use Redis Sentinel — then if the master fails, sessions are not lost. Configuration is similar, just specify sentinels and master_name. Important: install the PHP redis extension. We prefer Redis over Memcached due to atomic operations and built-in persistence. In one project, sessions in Redis saved 20,000 shopping carts from loss during a balancer switch.
Moving Bitrix cache to Redis
Managed cache (/bitrix/cache/ and /bitrix/managed_cache/) is better stored in Redis. This speeds up reads and eliminates desync between nodes.
'cache' => [
'value' => [
'type' => 'redis',
'redis' => [
'host' => '127.0.0.1',
'port' => 6379,
'serializer' => \Redis::SERIALIZER_IGBINARY,
],
],
],
The igbinary extension compresses data ~40% faster than PHP serialization. For HTML page cache (e.g., bitrix:page.polycore) Redis is inefficient due to object size — cache such pages at the nginx proxy_cache level or leave them on NFS.
Why is MySQL replication important?
With multiple web nodes, database load grows proportionally. A single master cannot handle SELECT queries. The solution is Master-Slave replication with query separation. Configuration in /bitrix/.settings.php:
'connections' => [
'value' => [
'default' => [
'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
'host' => 'mysql-master',
'database' => 'bitrix',
'login' => 'bitrix',
'password' => 'secret',
],
'slave' => [
'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
'host' => 'mysql-slave',
'database' => 'bitrix',
'login' => 'bitrix_ro',
'password' => 'secret_ro',
],
],
],
For transparent request routing we use ProxySQL or a custom Connection Resolver. This reduces master load and increases throughput.
Choosing a file storage
| Criteria | NFS | GlusterFS | S3 (MinIO) |
|---|---|---|---|
| Ease of setup | +++ | + | ++ |
| Fault tolerance | - | ++ | +++ |
| Performance | ++ | ++ | + |
| File locking | + | + | - |
NFS is a simple option for 2-3 nodes: quick to mount and low latency, but it's a single point of failure without replication. GlusterFS is harder to set up but replicates data between nodes and eliminates SPOF. S3-compatible storages (e.g., MinIO) are elastic and don't require physical servers, but latency is higher and the module Bitrix\Main\File\Remote\S3 is needed. For production we most often use GlusterFS — it has already saved more than one project from downtime. Example of NFS mounting:
mount -t nfs nfs-server:/srv/bitrix-shared /var/www/bitrix/upload
Load balancer configuration
Example nginx configuration with least_conn and health check
upstream bitrix_backend {
least_conn;
server web-node-1:80 weight=1 max_fails=3 fail_timeout=30s;
server web-node-2:80 weight=1 max_fails=3 fail_timeout=30s;
server web-node-3:80 weight=1 max_fails=3 fail_timeout=30s;
keepalive 32;
}
server {
listen 443 ssl;
location / {
proxy_pass http://bitrix_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 5s;
proxy_read_timeout 60s;
}
}
With proper session storage in Redis, sticky sessions are not needed — any node can handle any request. Exception: chunked file upload; for that you can enable sticky by IP or use a separate upload endpoint.
Process of work
- Audit — analyze current architecture, load, bottlenecks.
- Design — choose scheme: Redis, storage, balancer, replication.
- Configure Redis — sessions and cache, test fault tolerance.
- Configure file storage — NFS or GlusterFS, synchronize codebase (git/rsync/Ansible).
- Configure balancer — nginx upstream, health check, SSL termination.
- MySQL replication — Master-Slave + ProxySQL.
- Testing — load tests, check behavior when a node is disconnected.
- Documentation and training — hand over scheme and instructions.
What is included in the work
- Architectural cluster diagram and configuration files.
- Configured Redis (sessions + cache) with redundancy via Sentinel.
- Shared file storage (NFS or GlusterFS) with automatic mounting.
- nginx load balancer with health check and SSL termination.
- MySQL replication with ProxySQL for query distribution.
- Load testing and performance report.
- Operations documentation and disaster recovery scheme.
- Training of your team on basic operations.
- Post-production support for one month.
Timelines and cost
Basic setup (2 nodes, Redis, NFS, balancing) takes 2–3 weeks. Production-grade scheme with GlusterFS, Redis Sentinel, monitoring, and automation takes 4–6 weeks. Cost is calculated individually after audit. Savings from avoiding expensive server upgrades can reach 60%. Reduction in server infrastructure costs up to 40% compared to a monolithic solution. Order an audit of your project — our engineers will assess scaling feasibility in 2 days. Get a consultation on choosing the optimal clustering scheme.