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

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

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

Мінімальна відмовостійка конфігурація

Три ноди — мінімум для кворуму: при виходi однієї ноди дві, що залишилися, складають більшість і продовжують роботу. Дві ноди дають split-brain при розриві мережі — кожна вважає себе мастером.

Рекомендований розподіл ролей:

Для великих інсталяцій (>50 млн документів) виділяють окремі dedicated master-ноди без ролі data — вони не беруть участь у пошуку та індексації, лише управляють кластером.

Конфігурація elasticsearch.yml

На кожній ноді налаштовуємо elasticsearch.yml:

# es-01
cluster.name: bitrix-search
node.name: es-01
node.roles: [ master, data ]

network.host: 10.0.0.11
http.port: 9200
transport.port: 9300

discovery.seed_hosts:
  - 10.0.0.11:9300
  - 10.0.0.12:9300
  - 10.0.0.13:9300

cluster.initial_master_nodes:
  - es-01
  - es-02

# Безпека
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12

# Продуктивність
indices.memory.index_buffer_size: 20%
thread_pool.write.queue_size: 500

cluster.initial_master_nodes вказуємо лише при первинному розгортанні. Після формування кластера цей рядок прибираємо — інакше при рестарті можливе розщеплення кластера.

Налаштування шардування індексів Бітрікс

За замовчуванням 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–4 дні залежно від наявності готової інфраструктури.