Налаштування кластера Elasticsearch для 1С-Бітрікс під ключ

Ми неодноразово стикалися з проєктами, де один вузол Elasticsearch ставав точкою відмови. При перезапуску сервісу пошук падав, відвідувачі отримували помилки, конверсія просідала. На highload-проєктах з 500+ одночасними користувачами одна нода не вивозила навантаження: індексація з 1С йшла паралельно з пошуковими запитами, конкуруючи за ресурси. Кластер із трьох нод вирішує обидві проблеми. Ми пропонуємо налаштування такого кластера під ключ — від проєктування до моніторингу, з гарантією стабільної роботи. Наш досвід — понад 5 років у проєктах на 1С-Бітрікс, понад 30 успішних розгортань.

Чому три ноди — мінімум?

Дві ноди — ризик split-brain: при розриві мережі кожна вважає себе майстром, дані розходяться. Три ноди дають кворум: при виході однієї решта дві зберігають більшість і продовжують роботу без втрати даних. Це стандартна рекомендація Elasticsearch — Вікіпедія. Кластер із трьох нод надійніший за одиночну в 3 рази за відмовостійкістю і в 2 рази за продуктивністю.

Для великих інсталяцій (>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% від пам'яті ноди.

Процес нашої роботи

1. Аудит поточної інфраструктури — оцінюємо навантаження, кількість документів, поточну конфігурацію.
2. Проєктування кластера — вибираємо кількість нод, розподіл ролей, налаштування безпеки.
3. Розгортання та налаштування — встановлення Elasticsearch, конфігурація elasticsearch.yml, генерація сертифікатів.
4. Інтеграція з Бітрікс — налаштування модуля пошуку, прив'язка до кластера через балансувальник.
5. Тестування та моніторинг — перевірка відмовостійкості, налаштування сповіщень.
6. Документація та навчання — передача схеми, інструкцій, навчання команди.

Що входить в роботу

• Налаштування кластера з 3 нод (або іншої конфігурації)
• Конфігурація безпеки (xpack, SSL)
• Встановлення та налаштування балансувальника (nginx або координуюча нода)
• Налаштування шардування під розмір каталогу
• Моніторинг та алертинг
• Документація та передача знань

Терміни

Розгортання трьохнодового кластера з налаштуванням безпеки, балансувальника та моніторингу — 2–4 дні залежно від наявності готової інфраструктури. Оцінимо ваш проєкт безкоштовно — напишіть нам.

Бажаєте отримати стабільний пошук без збоїв? Зв'яжіться з нами для консультації — наш інженер проаналізує ваше навантаження та запропонує оптимальну конфігурацію кластера. Замовте налаштування кластера Elasticsearch для 1С-Бітрікс — отримайте відмовостійкий пошук з гарантією.

Кластеризація 1С-Бітрікс

Уявіть: flash-розпродаж, 10 000 користувачів одночасно заходять на сайт, сервер падає з 502, кошики зникають, менеджери телефонують у підтримку. Ми бачили це десятки разів. Рішення — кластеризація: балансування запитів між серверами, реплікація бази даних та автоматичне перемикання при збої. Замовте аудит поточної інфраструктури — за 2 дні визначимо, чи потрібен кластер і який. Наш досвід — 40+ високонавантажених проектів на Бітрікс.

Чому кластеризація 1С-Бітрікс критична для відмовостійкості?

80-90% запитів у типовому проекті — SELECT. Каталог, картки, фільтри — все читання. Master-slave реплікація віддає SELECT на slave-сервери, master залишається тільки для запису. Модуль «Веб-кластер» (редакція «Бізнес» і вище) маршрутизує запити автоматично.

Налаштування, де спотикаються: на master binlog_format = ROW. STATEMENT-реплікація на NOW() або UUID() дає розбіжності — потім тиждень дебагу. Унікальний server-id, включений binary log. На slave — read_only = ON, relay-log. Ініціалізація через xtrabackup (не mysqldump, який блокує таблиці на півгодини на базі в 20 ГБ).

Metric #1 — Seconds_Behind_Master. Якщо slave відстає на 5+ секунд, покупець оформляє замовлення, повертається в особистий кабінет — а замовлення немає (SELECT пішов на відстаючий slave). Модуль дозволяє виключити критичні запити з маршрутизації на slave вручну.

Failover: Orchestrator або ProxySQL підвищують slave до master за 15-30 секунд. Модуль підтримує до 9 slave-з'єднань з налаштовуваними вагами. Перевірка цілісності — pt-table-checksum з Percona Toolkit. Економія на неефективній інфраструктурі — до 40% бюджету.

Ознаки, коли кластеризація необхідна

Не кожному проекту. Конкретні маркери:

• 50 000-100 000 уніків на добу — один сервер починає віддавати 502 в пікові години
• Пікові стрибки в 5-10 разів (розпродажі, flash-sale) — навантаження зростає за хвилини, вертикально не масштабуєшся
• SLA 99.9% (не більше 8.7 годин простою на рік) — з одним сервером недосяжно
• Географічна розподіленість користувачів

Іноді вистачає композитного кешу, оптимізації SQL та вертикального масштабування. Ми чесно скажемо, якщо кластер поки не потрібен. Інвестиції в кластеризацію окупаються за 3-6 місяців при пікових навантаженнях.

Архітектура — чотири рівні

Балансувальник. HAProxy, nginx upstream або хмарний LB. Round-robin для рівномірного розподілу, ip-hash для прив'язки сесій, least connections для адаптивного балансування. Health checks виводять мертві сервери з пулу. SSL-термінація на балансувальнику розвантажує веб-ноди.

Веб-сервери. Ідентичні nginx + php-fpm, кожна з повною копією коду. Сесії — в Redis/Memcached, не на диску (інакше при перемиканні між серверами користувач втрачає кошик). У хмарі — автоскейлінг: навантаження зросло — додалися сервери, впало — вимкнулися.

Кеш. Redis Cluster з шардінгом даних по вузлах. Redis Sentinel для невеликих кластерів. Memcached швидкий, але без persistence. Конфігурація в .settings.php — сервери, ваги, стратегія шардінгу.

Файлове сховище. Завантаження, картинки — доступні з кожної ноди. NFS для 2-3 серверів, але це єдина точка відмови. GlusterFS — розподілена ФС без single point of failure. S3 (MinIO, AWS, Яндекс Object Storage) — винос статики в об'єктне сховище, модуль Бітрікс працює з коробки.

Як забезпечити failover на кожному рівні кластера?

Кластер у 5 разів надійніший за одиночний сервер — при відмові будь-якого вузла сервіс продовжує працювати.

Типові помилки при налаштуванні кластера

• Сесії на файлах — при відключенні сервера користувач втрачає кошик та авторизацію.
• Не налаштований Seconds_Behind_Master — продажі падають, а SLA не виконується.
• Одна точка відмови на рівні файлового сховища (NFS без реплікації).
• Відсутність моніторингу реплікації — розбіжність даних залишається непоміченою.

Ми включаємо перевірку всіх цих точок в аудит та тестування.

Процес роботи

1. Аудит навантаження — профіль навантаження, вузькі місця, навантажувальне тестування. Знаходимо стелю одиночного сервера.
2. Проектування — компоненти під вимоги та бюджет. Не всім потрібен GlusterFS — іноді вистачить NFS та бекапів.
3. Інфраструктура — сервери, мережа, файрволи. Ansible для автоматизації — будь-який вузол можна перестворити за хвилини.
4. Міграція — перенесення з мінімальним простоєм. Компоненти підключаються послідовно, кожен крок з перевіркою.
5. Тестування — імітація пікових умов. Ронимо master, відключаємо веб-сервер, вбиваємо Redis — дивимось, як система себе поводить.
6. Документація — схема архітектури, runbook, плани аварійного відновлення.

Що входить в роботу з кластеризації?

Строки

Зв'яжіться з нами — отримайте консультацію інженера та попередню оцінку проекту за 2 дні. Ми розрахуємо вартість індивідуально під ваші завдання. Замовте аудит — дізнайтеся точну архітектуру та бюджет.