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.
| Node | Role | Memory | Purpose |
|---|---|---|---|
| es-01 | master, data | 16 GB | Master + data |
| es-02 | master, data | 16 GB | Backup master + data |
| es-03 | data, ingest | 16 GB | Data + preprocessing |
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.
| Parameter | Value | Description |
|---|---|---|
| refresh_interval | 5-10s | Reduces load during bulk indexing |
| number_of_shards | 3-5 | Distributes data across nodes |
| number_of_replicas | 1-2 | Fault tolerance |
Our work process
- Audit of current infrastructure — assess load, document count, current configuration.
- Cluster design — select number of nodes, role distribution, security settings.
- Deployment and configuration — install Elasticsearch, configure elasticsearch.yml, generate certificates.
- Integration with Bitrix — configure search module, connect to cluster via load balancer.
- Testing and monitoring — verify fault tolerance, set up alerts.
- 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.