Ми неодноразово стикалися з проєктами, де один вузол Elasticsearch ставав точкою відмови. При перезапуску сервісу пошук падав, відвідувачі отримували помилки, конверсія просідала. На highload-проєктах з 500+ одночасними користувачами одна нода не вивозила навантаження: індексація з 1С йшла паралельно з пошуковими запитами, конкуруючи за ресурси. Кластер із трьох нод вирішує обидві проблеми. Ми пропонуємо налаштування такого кластера під ключ — від проєктування до моніторингу, з гарантією стабільної роботи. Наш досвід — понад 5 років у проєктах на 1С-Бітрікс, понад 30 успішних розгортань.
Чому три ноди — мінімум?
Дві ноди — ризик split-brain: при розриві мережі кожна вважає себе майстром, дані розходяться. Три ноди дають кворум: при виході однієї решта дві зберігають більшість і продовжують роботу без втрати даних. Це стандартна рекомендація Elasticsearch — Вікіпедія. Кластер із трьох нод надійніший за одиночну в 3 рази за відмовостійкістю і в 2 рази за продуктивністю.
| Нода | Роль | Пам'ять | Призначення |
|---|---|---|---|
| es-01 | master, data | 16 GB | Майстер + дані |
| es-02 | master, data | 16 GB | Резервний майстер + дані |
| es-03 | data, ingest | 16 GB | Дані + передобробка |
Для великих інсталяцій (>50 млн документів) виділяють окремі dedicated master-ноди без ролі data — вони не беруть участі в пошуку та індексації, тільки керують кластером.
Як налаштувати шардування для каталогу 1С-Бітрікс?
За замовчуванням Elasticsearch створює 1 primary shard на індекс. Для каталогу з 1+ млн документів цього мало. Налаштовуємо потрібну кількість шардів і реплік:
PUT /bitrix_catalog
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1,
"refresh_interval": "5s"
}
}number_of_replicas: 1 означає, що кожен шард копіюється на другу ноду. При виході однієї ноди репліки промотуються в primary автоматично, пошук продовжується без переривання.
refresh_interval: 5s замість дефолтної 1s знижує навантаження на індексацію при масовому оновленні з 1С. Нові документи з'являться в пошуку із затримкою до 5 секунд — для більшості каталогів прийнятно.
Балансування запитів від Бітрікс
Бітрікс підключається до Elasticsearch через один host. Щоб запити розподілялися по всіх нодах, перед кластером ставимо балансувальник:
Варіант 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;
}
}Бітрікс підключається до localhost:9201. Nginx розподіляє запити методом найменших з'єднань.
Варіант 2 — координуюча нода (для навантажень 1000+ rps): окрема нода з node.roles: [] приймає всі HTTP-запити, розсилає підзапити до data-нод, агрегує результати. Не зберігає дані, не бере участі у виборах майстра.
Як моніторити стан кластера?
# Статус кластера (green/yellow/red)
curl -s http://10.0.0.11:9200/_cluster/health?pretty
# Розподіл шардів по нодах
curl -s http://10.0.0.11:9200/_cat/shards?v
# Навантаження на ноди
curl -s http://10.0.0.11:9200/_cat/nodes?v&h=name,heap.percent,cpu,load_1m
Статус yellow — частина реплік не розміщена (при одній ноді це норма). Статус red — втрачені primary shards, частина даних недоступна, потребує негайного втручання. Докладніше про налаштування пошукового модуля в Бітрікс читайте в офіційній документації.
Типові помилки та як їх уникнути
На одному проєкті з каталогом 2 млн товарів при індексації з 1С кожні 30 секунд пошук вимикався на 20 секунд — через refresh_interval: 1s. Після збільшення до 5s індексація перестала блокувати пошук, а швидкість появи нових товарів залишилася прийнятною. Також часто забувають налаштувати indices.memory.index_buffer_size — при масовому завантаженні документів може виникнути OutOfMemoryError. Рекомендуємо ставити 10-20% від пам'яті ноди.
| Параметр | Значення | Опис |
|---|---|---|
| refresh_interval | 5-10s | Знижує навантаження при масовій індексації |
| number_of_shards | 3-5 | Розподіл даних по нодах |
| number_of_replicas | 1-2 | Відмовостійкість |
Процес нашої роботи
- Аудит поточної інфраструктури — оцінюємо навантаження, кількість документів, поточну конфігурацію.
- Проєктування кластера — вибираємо кількість нод, розподіл ролей, налаштування безпеки.
- Розгортання та налаштування — встановлення Elasticsearch, конфігурація elasticsearch.yml, генерація сертифікатів.
- Інтеграція з Бітрікс — налаштування модуля пошуку, прив'язка до кластера через балансувальник.
- Тестування та моніторинг — перевірка відмовостійкості, налаштування сповіщень.
- Документація та навчання — передача схеми, інструкцій, навчання команди.
Що входить в роботу
- Налаштування кластера з 3 нод (або іншої конфігурації)
- Конфігурація безпеки (xpack, SSL)
- Встановлення та налаштування балансувальника (nginx або координуюча нода)
- Налаштування шардування під розмір каталогу
- Моніторинг та алертинг
- Документація та передача знань
Терміни
Розгортання трьохнодового кластера з налаштуванням безпеки, балансувальника та моніторингу — 2–4 дні залежно від наявності готової інфраструктури. Оцінимо ваш проєкт — напишіть нам.
Бажаєте отримати стабільний пошук без збоїв? Зв'яжіться з нами для консультації — наш інженер проаналізує ваше навантаження та запропонує оптимальну конфігурацію кластера. Замовте налаштування кластера Elasticsearch для 1С-Бітрікс — отримайте відмовостійкий пошук з гарантією.
