Elasticsearch Cluster Setup for 1C-Bitrix Turnkey

We’ve repeatedly encountered projects where a single Elasticsearch node became a single point of failure. On service restart, search went down, visitors got errors, conversion dropped. On highload projects with 500+ concurrent users, one node couldn’t handle the load: indexing from 1C ran in parallel with search queries, competing for resources. A three-node cluster solves both problems. We offer turnkey setup of such a cluster — from design to monitoring, with a guarantee of stable operation. Our experience: more than 5 years in projects on 1C-Bitrix, more than 30 successful deployments.

Why three nodes is the minimum

Two nodes risk split-brain: if the network breaks, each thinks it’s the master, data diverges. Three nodes provide quorum: if one goes down, the remaining two keep the majority and continue without data loss. This is a standard recommendation from Elasticsearch — Wikipedia. A three-node cluster is 3 times more fault-tolerant and 2 times more performant than a single node.

For large installations (>50 million documents), dedicated master-eligible nodes without data role are allocated — they don’t participate in search and indexing, only cluster management.

How to configure sharding for a 1C-Bitrix catalog

By default, Elasticsearch creates 1 primary shard per index. For a catalog with 1+ million documents, that’s insufficient. We configure the required number of shards and replicas:

PUT /bitrix_catalog
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "refresh_interval": "5s"
  }
}

number_of_replicas: 1 means each shard is copied to a second node. When one node fails, replicas are promoted to primary automatically, search continues without interruption.

refresh_interval: 5s instead of the default 1s reduces load during bulk updates from 1C. New documents appear in search with up to 5 seconds delay — acceptable for most catalogs.

Load balancing requests from Bitrix

Bitrix connects to Elasticsearch through one host. To distribute requests across all nodes, we place a load balancer in front of the cluster:

Option 1 — nginx upstream:

upstream elasticsearch {
    least_conn;
    server 10.0.0.11:9200;
    server 10.0.0.12:9200;
    server 10.0.0.13:9200;
}

server {
    listen 9201;
    location / {
        proxy_pass http://elasticsearch;
    }
}

Bitrix connects to localhost:9201. Nginx distributes requests by least connections.

Option 2 — coordinating node (for loads 1000+ rps): a separate node with node.roles: [] accepts all HTTP requests, fans out sub-requests to data nodes, aggregates results. Doesn’t store data, doesn’t participate in master election.

How to monitor cluster state

# Cluster health (green/yellow/red)
curl -s http://10.0.0.11:9200/_cluster/health?pretty

# Shard distribution across nodes
curl -s http://10.0.0.11:9200/_cat/shards?v

# Node load
curl -s http://10.0.0.11:9200/_cat/nodes?v&h=name,heap.percent,cpu,load_1m

Status yellow — some replicas not assigned (normal with one node). Status red — lost primary shards, data partially unavailable, immediate action required. For more on configuring the search module in Bitrix, see the official documentation.

Typical mistakes and how to avoid them

On one project with a catalog of 2 million products, during indexing from 1C every 30 seconds, search stopped for 20 seconds — due to refresh_interval: 1s. After increasing to 5s, indexing no longer blocked search, and the speed of new product appearances remained acceptable. Another common oversight: not setting indices.memory.index_buffer_size — during mass document loading, OutOfMemoryError can occur. We recommend setting 10-20% of node memory.

Our work process

1. Audit of current infrastructure — assess load, document count, current configuration.
2. Cluster design — select number of nodes, role distribution, security settings.
3. Deployment and configuration — install Elasticsearch, configure elasticsearch.yml, generate certificates.
4. Integration with Bitrix — configure search module, connect to cluster via load balancer.
5. Testing and monitoring — verify fault tolerance, set up alerts.
6. Documentation and training — hand over schema, instructions, train team.

What’s included

• Cluster setup of 3 nodes (or alternative configuration)
• Security configuration (xpack, SSL)
• Load balancer installation and configuration (nginx or coordinating node)
• Sharding setup according to catalog size
• Monitoring and alerting
• Documentation and knowledge transfer

Timeframes

Deploying a three-node cluster with security, load balancer, and monitoring — 2–4 days depending on existing infrastructure. We’ll estimate your project for free — message us.

Want stable search without failures? Contact us for a consultation — our engineer will analyze your load and suggest the optimal cluster configuration. Order Elasticsearch cluster setup for 1C-Bitrix — get fault-tolerant search with a guarantee.

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.