Настройка кластера Elasticsearch для 1С-Битрикс

Настройка кластера Elasticsearch для 1С-Битрикс

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

Минимальная отказоустойчивая конфигурация

Три ноды — минимум для кворума: при выходе одной ноды оставшиеся две составляют большинство и продолжают работу. Две ноды дают 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 дня в зависимости от наличия готовой инфраструктуры.