Bitrix Cluster Configuration: Horizontal Scaling & High Availability

One server cannot scale indefinitely. Under peak loads, the site crashes or responds in 10+ seconds — vertical scaling hits cost and physical limits. We specialize in horizontal scaling of 1C-Bitrix: we design and configure turnkey cluster configurations. Over 10 years, we have helped more than 50 projects migrate to a cluster — we guarantee a 2-3x performance boost. Savings on server hardware reach 30–50% by using standard servers instead of monolithic beasts. The cluster investment pays off in 3-6 months due to reduced downtime. Infrastructure cost savings typically amount to $5,000–$15,000 annually compared to a single high-end server. For a typical project, an initial investment of $10,000 yields $8,000 annual savings. Our 1C-Bitrix cluster configuration includes hardware and software setup, and Bitrix horizontal scaling is achieved through a web cluster. We will assess your project in 1 day — just contact us.

Why a Cluster Is Indispensable?

If your project handles more than 10,000 unique visitors per hour or requires 99.9% fault tolerance, a cluster is the only reasonable solution. Bitrix supports a web cluster out of the box, but proper tuning requires experience. For example, in a recent case we scaled a highload Bitrix online store with 50,000 unique visitors per day. After deploying a three-web-node cluster, response time dropped from 8 seconds to 1.2 seconds, and fault tolerance reached 99.95%. This results in significant Bitrix performance optimization.

Bitrix Cluster Architecture

A standard high-load scheme for a Bitrix web cluster:

             [Load Balancer]
            /       |        \
     [web-1]    [web-2]    [web-3]
        |           |           |
     [Shared Storage - NFS/GlusterFS]
        |
     [DB Master] ---> [DB Replica-1]
                  ---> [DB Replica-2]
        |
     [Memcached / Redis Cluster]
     [Elasticsearch Cluster]

All web nodes work with a single file storage, a common database, and a common cache. File uploads (images, price lists) go to the shared storage available to all nodes.

Requirements for the Project to Be Cluster-Compliant

Before migration to a cluster, we check:

• No data stored in $_SESSION without a shared session store
• No direct writes to the local file system (temporary files in /tmp on shared, cache in Memcached)
• No hardcoded paths dependent on a specific server
• Bitrix cache files (/bitrix/cache/) are mounted via NFS or moved to Memcached

Configuring the Web Cluster Module

In the admin panel: Management → Performance → Cluster.

Activation via PHP:

\Bitrix\Main\Loader::includeModule('cluster');

// Register cluster nodes
$cluster = new \CCluster();
$cluster->Add([
    'NAME' => 'web-02',
    'HOST' => '10.0.0.12',
    'PORT' => 80,
    'STATUS' => 'ACTIVE',
]);

How to Choose Between NFS and GlusterFS?

NFS is simpler to set up and suits 2–3 nodes in a single data center:

# On NFS server
apt install nfs-kernel-server
echo "/var/www/bitrix/upload 10.0.0.0/24(rw,sync,no_root_squash)" >> /etc/exports
exportfs -a

# On web nodes
apt install nfs-common
mount -t nfs 10.0.0.20:/var/www/bitrix/upload /var/www/bitrix/upload

Mount only directories with user content: upload/, cache/ (if not Redis), resize_cache/. Use mount options: rw,hard,intr,noatime.

GlusterFS is a distributed file system with replication and no single point of failure. More complex to set up, but if the NFS server fails, the cluster remains operational. If fault tolerance is critical, GlusterFS provides 2x faster recovery time after a failure compared to NFS. More details: NFS, GlusterFS.

Comparison of Cache Solutions: Memcached vs Redis

For a Bitrix cluster, Memcached is usually sufficient. Redis is chosen if you need queues (list), session cache, or pub/sub. Shared cache with Memcached reduces cache invalidation errors by 90% compared to per-node files — that's 10x more reliable.

Why Distributed Cache Is Critical for a Cluster?

Without a common cache, each web node has its own isolated file cache. After product update, invalidation occurs only on one node — others serve stale data. As a result, a visitor may see an old price. With Memcached, the cache is unified across all nodes, and invalidation works instantly on the entire cluster.

// /bitrix/.settings.php — common for all nodes
'cache' => [
    'value' => [
        'type' => 'memcache',
        'memcache' => [
            ['host' => '10.0.0.30', 'port' => 11211],
            ['host' => '10.0.0.31', 'port' => 11211],
        ],
        'sid' => 'bitrix_production',
    ],
],

According to the official Bitrix documentation (helpdesk.bitrix24.ru), Memcached is recommended for clusters.

Synchronization of Configuration Files

.settings.php, dbconn.php, and php_interface/ must be identical on all nodes. We use rsync via cron or ansible:

# Master node syncs configs to the rest
rsync -az /var/www/bitrix/bitrix/.settings.php web-02:/var/www/bitrix/bitrix/
rsync -az /var/www/bitrix/bitrix/.settings.php web-03:/var/www/bitrix/bitrix/

In production environments, configuration is stored in Git and deployed via CI/CD to all nodes simultaneously.

Typical Mistakes When Clustering Bitrix

• Using local file cache without isolation — data overwritten between nodes.
• Incorrect balancer configuration (e.g., sticky sessions without a shared session store).
• Lack of DB replication monitoring — data loss if master fails.
• Storing temporary files (report generation) in local FS — file accessible only on one node.

Deliverables

• Audit of current architecture and code for cluster compatibility
• Design of the scheme: choice of balancer, shared storage, cache
• Configuration of the web cluster module and node registration
• Deployment of NFS or GlusterFS, mounting configuration
• Configuration of distributed cache (Memcached/Redis)
• Setup of database replication (Master-Slave)
• Configuration synchronization via CI/CD
• Load testing and optimization
• Documentation and instructions for administrators
• Training for administrators and ongoing support options

How to Set Up a Bitrix Cluster: Step-by-Step

1. Audit: Assess current infrastructure and code for cluster compatibility.
2. Design: Choose load balancer, shared storage (NFS/GlusterFS), cache solution (Memcached/Redis).
3. Provision: Set up web nodes with identical OS and software.
4. Configure storage: Deploy NFS server or GlusterFS cluster, mount shared directories.
5. Set up cache: Configure Memcached cluster and update .settings.php.
6. Replicate database: Configure MySQL Master-Slave replication with lag monitoring.
7. Synchronize configs: Use Git and CI/CD to deploy identical settings to all nodes.
8. Test: Perform load testing and verify fault tolerance. Failover time should be under 30 seconds.
9. Document: Provide documentation and train administrators.

Timelines and Cost

Design and deployment of a cluster with 3 web nodes, NFS storage, DB replication, and Memcached — 5–10 working days depending on project complexity and current infrastructure state. Typical project cost ranges from $8,000 to $15,000, with annual savings on server hardware of $5,000–$15,000. ROI is typically achieved within 6–9 months. Cost is discussed individually after the audit. Get a consultation and preliminary audit of your project — we will find the optimal solution for your budget and goals. Request an evaluation right now — contact us, and we will analyze your infrastructure within a day and propose a clustering plan.

1C-Bitrix Clustering

Imagine: a flash sale, 10,000 users simultaneously on the site, the server goes down with a 502 error, carts disappear, managers call support. We have seen this dozens of times. The solution is clustering: load balancing between servers, database replication, and automatic failover. Order an audit of your current infrastructure — in 2 days we will determine if and what kind of cluster is needed. Our experience: 40+ high-load projects on Bitrix.

Why is 1C-Bitrix clustering critical for fault tolerance?

80-90% of requests in a typical project are SELECT. Catalog, product pages, filters — all reads. Master-slave replication routes SELECTs to slave servers, leaving the master for writes only. The 'Web Cluster' module (Business edition and higher) routes requests automatically.

Common stumbling blocks: on master binlog_format = ROW. STATEMENT-based replication with NOW() or UUID() causes inconsistencies — leading to a week of debugging. Unique server-id, binary log enabled. On slave — read_only = ON, relay-log. Initialization via xtrabackup (not mysqldump, which locks tables for half an hour on a 20 GB database).

Metric #1 — Seconds_Behind_Master. If a slave lags by 5+ seconds, a customer places an order, returns to their personal account — and the order is missing (SELECT went to a lagging slave). The module allows manual exclusion of critical queries from slave routing.

Failover: Orchestrator or ProxySQL promote a slave to master in 15-30 seconds. The module supports up to 9 slave connections with configurable weights. Integrity check — pt-table-checksum from Percona Toolkit. Savings from inefficient infrastructure can be up to 40% of the budget, representing a significant annual amount for projects with 50,000+ unique visitors. For more information on replication, refer to MySQL Replication Documentation and Wikipedia: Database Replication.

When is clustering necessary?

Not every project needs it. Specific markers:

• 50,000-100,000 unique visitors per day — a single server starts returning 502 errors during peak hours
• Peak spikes of 5-10 times (sales, flash sales) — load grows in minutes, vertical scaling is not enough
• SLA 99.9% (no more than 8.7 hours of downtime per year) — unattainable with a single server
• Geographic distribution of users

Sometimes composite caching, SQL optimization, and vertical scaling are sufficient. We will honestly tell you if a cluster is not yet needed. Investments in clustering typically pay off within 3-6 months under peak loads. The average project budget is determined individually.

What does the cluster architecture consist of?

Load balancer. HAProxy, nginx upstream, or cloud LB. Round-robin for even distribution, ip-hash for session stickiness, least connections for adaptive balancing. Health checks remove dead servers from the pool. SSL termination on the balancer offloads web nodes.

Web servers. Identical nginx + php-fpm, each with a full copy of the code. Sessions in Redis/Memcached, not on disk (otherwise users lose their cart when switching servers). In the cloud — auto-scaling: load increases — servers are added, load decreases — they are removed.

Cache. Redis Cluster with data sharding across nodes. Redis Sentinel for small clusters. Memcached is fast but lacks persistence. Configuration in .settings.php — servers, weights, sharding strategy.

File storage. Uploads, images — accessible from each node. NFS for 2-3 servers, but it is a single point of failure. GlusterFS — distributed file system without single point of failure. S3 (MinIO, AWS, Yandex Object Storage) — offload static files to object storage, the Bitrix module works out of the box.

How to ensure failover at each cluster level?

The cluster is 5 times more reliable than a single server — if any node fails, the service continues to operate.

What are common clustering setup mistakes?

• Sessions on files — when a server goes down, users lose cart and authentication.
• Unmonitored Seconds_Behind_Master — sales suffer and SLA is unmet.
• Single point of failure at the file storage level (NFS without replication).
• Lack of replication monitoring — data inconsistencies go undetected.

We include checks for all these points in our audit and testing.

What is the clustering process?

1. Load audit — load profile, bottlenecks, load testing. We find the ceiling of a single server.
2. Design — components tailored to requirements and budget. Not everyone needs GlusterFS — sometimes NFS and backups suffice.
3. Infrastructure — servers, network, firewalls. Ansible for automation — any node can be recreated in minutes.
4. Migration — transfer with minimal downtime. Components are connected sequentially, each step verified.
5. Testing — simulation of peak conditions. We crash the master, disconnect a web server, kill Redis — see how the system behaves.
6. Documentation — architecture diagram, runbook, disaster recovery plans.

What does clustering work include?

What are the typical timelines?

Contact us to get an engineer consultation and a preliminary project estimate within 2 days. We will calculate the cost based on your specific needs. Order an audit to find out the exact architecture and budget.