Setting up a 1C-Bitrix web cluster

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages

Web Cluster Configuration for 1C-Bitrix

Web Cluster Configuration for 1C-Bitrix

The "Web Cluster" module in 1C-Bitrix is not a one-click horizontal auto-scaling solution. It is a set of synchronization mechanisms that allow multiple servers to operate as a single unit: shared cache, file replication, unified sessions. Without properly configuring each component, the cluster behaves unpredictably — one node invalidates the cache while another serves stale data.

What the Web Cluster Module Includes

The cluster module (BitrixVM Enterprise or a separate license) provides:

  • Node management — server registration, availability monitoring
  • Load balancing — request routing between nodes
  • Cache synchronization — invalidation across all nodes via shared Memcached
  • File replication — synchronization of upload/ between servers
  • DB replication — read/write split configuration for MySQL

Activating and Configuring Nodes

The module is installed on each node but managed through a single admin panel.

Adding a node via API:

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

$result = \Bitrix\Cluster\Node::add([
    'NAME'      => 'web-02',
    'HOST'      => '10.0.0.12',
    'PORT'      => 443,
    'HTTPS'     => 'Y',
    'STATUS'    => 'ACTIVE',
    'SORT'      => 100,
]);

if ($result->isSuccess()) {
    echo 'Node added: ' . $result->getId();
}

Checking node connectivity:

# Each node must be able to reach the API of the other nodes
curl -k https://10.0.0.12/bitrix/admin/cluster_check.php

Read/Write Split for the Database

The most valuable part of the cluster for high load — routing SELECT queries to replicas while INSERT/UPDATE/DELETE go to the master. Reduces master load by 60–80% with a typical read/write ratio of 10:1.

In .settings.php:

'connections' => [
    'value' => [
        'default' => [
            'className' => '\Bitrix\Main\DB\MysqlConnection',
            'host'      => 'db-master:3306',
            'database'  => 'bitrix',
            'login'     => 'bitrix',
            'password'  => 'secret',
        ],
        'slave'  => [
            'className' => '\Bitrix\Main\DB\MysqlConnection',
            'host'      => 'db-replica:3306',
            'database'  => 'bitrix',
            'login'     => 'bitrix_ro',
            'password'  => 'secret_ro',
        ],
    ],
],

The cluster module configuration specifies which queries go to which connection. Transactional queries are forcefully routed to the master regardless of the operation type.

File Synchronization via the Module

The module can synchronize files between nodes via HTTP requests to agents on each server. When a file is uploaded through the admin interface on node-1, the module automatically copies it to node-2 and node-3.

Configuring the sync agent on each node:

# nginx: restrict the sync agent from public access
location /bitrix/admin/cluster_file_sync.php {
    allow 10.0.0.0/24;  # internal network only
    deny all;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}

An alternative to built-in synchronization — inotify + rsync via lsyncd. Operates independently of PHP and is more reliable for large file volumes:

-- /etc/lsyncd/lsyncd.conf.lua
sync {
    default.rsync,
    source = "/var/www/bitrix/upload",
    target = "web-02:/var/www/bitrix/upload",
    delay = 1,
    rsync = {
        compress = false,
        owner = true,
        perms = true,
    }
}

Session Management in a Cluster

File-based sessions are non-functional in a cluster — requests from the same user may hit different nodes. Move sessions to Memcached or Redis:

; php.ini on all nodes (identical)
session.save_handler = memcached
session.save_path = "10.0.0.30:11211,10.0.0.31:11211"

Sticky sessions on the load balancer are a temporary solution and not recommended: when a node fails, all its users lose their sessions.

Verifying Cluster Operation

# Status of all nodes
curl http://admin:[email protected]/bitrix/admin/cluster_nodes.php?ajax=Y

# Cache invalidation test via API
php -r "
\Bitrix\Main\Loader::includeModule('cluster');
\Bitrix\Cluster\Cache::clearAll();
echo 'Cache cleared on all nodes';
"