Elasticsearch-кластер в продакшне: от выбора архитектуры до эксплуатации

Базовый elasticsearch.yml для master-ноды

cluster.name: itfresh-prod
node.name: es-master-01
node.roles: [ master ]

path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

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

discovery.seed_hosts:
  - 10.10.1.11
  - 10.10.1.12
  - 10.10.1.13

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

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/transport.p12
xpack.security.transport.ssl.truststore.path: certs/transport.p12
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: certs/http.p12

На data_hot — меняем роль: node.roles: [ data_hot, data_content, ingest ]. На всех нодах одинаковые discovery.seed_hosts и initial_master_nodes (последнее только при первой инициализации).

Heap и JVM настройки

Heap ≤ 50% ОЗУ и строго ≤ 30–31 ГБ. На машине с 64 ГБ я ставлю 30 ГБ heap. Файл /etc/elasticsearch/jvm.options.d/heap.options:

-Xms30g
-Xmx30g

Почему не больше 31 ГБ: JVM теряет compressed oops, указатели распухают, производительность падает. Если данных много — добавляйте ноды, а не heap.

Лимиты в systemd — /etc/systemd/system/elasticsearch.service.d/override.conf:

[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535

Шардинг и репликация

Главный баланс: шарды не слишком мелкие (много оверхеда), не слишком крупные (медленный recovery). Практический ориентир — 20–50 ГБ на шард.

Для индексов логов используйте ILM (Index Lifecycle Management) с роловером по размеру:

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot":  { "actions": { "rollover": { "max_primary_shard_size": "30gb", "max_age": "7d" } } },
      "warm": { "min_age": "7d",  "actions": { "shrink": { "number_of_shards": 1 }, "forcemerge": { "max_num_segments": 1 } } },
      "cold": { "min_age": "30d", "actions": { "searchable_snapshot": { "snapshot_repository": "s3-backup" } } },
      "delete":{"min_age":"90d", "actions": { "delete": {} } }
    }
  }
}

Реплики (число number_of_replicas) — всегда минимум 1 в продакшне, иначе падение одной data-ноды = потеря данных. Для критичных индексов — 2.

Мониторинг

Без мониторинга кластер — чёрный ящик. Минимальный набор метрик:

• cluster status (green/yellow/red) — алерт при red немедленно.
• unassigned_shards > 0 дольше 10 минут.
• JVM heap > 85% на любой ноде.
• disk.percent > 80% (у ES два watermark: 85% low, 90% high, 95% flood).
• pending_tasks > 10.
• thread_pool queue — индексирующий и поисковой.

Я ставлю Prometheus + elasticsearch-exporter + Grafana. Стандартные дашборды — ID 266 в Grafana library.

Снапшоты и восстановление

Копировать /var/lib/elasticsearch нельзя — файлы меняются, получите повреждённый индекс. Правильно — snapshot API. Настраиваем репозиторий (S3, NFS или локальный):

PUT _snapshot/backup-nfs
{
  "type": "fs",
  "settings": {
    "location": "/mnt/backup/es",
    "compress": true
  }
}

PUT _slm/policy/daily
{
  "schedule": "0 30 2 * * ?",
  "name": "",
  "repository": "backup-nfs",
  "config": { "indices": ["*"], "ignore_unavailable": true },
  "retention": { "expire_after": "30d", "min_count": 7, "max_count": 50 }
}

Раз в квартал тестируйте восстановление на отдельный кластер — иначе бэкапы только кажутся рабочими.

Реальный кейс: логи производственного SCADA

Однажды в 2024 году мы строили кластер для машиностроительного клиента — 220 станков с ЧПУ, SCADA на производственной сети, 80 ГБ логов в день. Задача: держать три года для анализа и быстрого поиска аномалий. Архитектура: 3 master-only на виртуалках 8 vCPU / 32 ГБ, 3 data_hot на физических серверах с NVMe (наши Dell Xeon Platinum 8280), 2 data_cold на СХД с HDD.

За 6 рабочих дней развернули кластер, настроили Filebeat на 11 коллекторах, пайплайны ingest для парсинга SCADA-форматов, ILM с ретенцией 3 года. Стоимость — 280 000 руб. Через 8 месяцев кластер содержит 18 ТБ индексированных логов, поиск по всему объёму — за 3–4 секунды.

Типичные грабли

• Split-brain. Одна или две master-ноды, без кворума. Всегда 3 master.
• Swap включён. ES начинает свопиться, производительность в пол. bootstrap.memory_lock: true.
• Слишком много шардов. 10 000 шардов на ноду — плохо. Консолидируйте, используйте ILM.
• mapping explosion. Динамический mapping создаёт поля на каждое новое имя в JSON — получаете тысячи полей. Используйте strict mapping.
• Забытый snapshot. Работает год, потом нужен — а SLM никто не настроил.
• Незащищённый ES. xpack.security выключена «для простоты» — через день в индексах находят тестовые базы с PII.

FAQ — Elasticsearch в продакшне

Сколько нод минимум для продакшн-кластера?

Три. Это минимум для отказоустойчивости кворума мастеров. Две ноды — split-brain неизбежен. Для малой нагрузки три ноды могут совмещать роли master/data, для средней и большой — выделите отдельные master-only.

Какой heap размер ставить?

Половина ОЗУ, но не больше 30–31 ГБ. Это граница сжатых указателей в JVM. Больший heap даёт хуже производительность. Вторая половина уходит файловому кэшу Lucene.

Сколько шардов делать на индекс?

Ориентир: 20–50 ГБ на шард. Для логового индекса 500 ГБ/день — 10 шардов. Слишком много шардов (тысячи) убивают кластер, слишком мало — нет параллелизма при запросах.

Как бэкапить Elasticsearch?

Только через snapshot API. Копировать data-директорию нельзя — файлы меняются. Регистрируйте репозиторий на S3/NFS/локальной папке и делайте snapshot через SLM (Snapshot Lifecycle Management) с ретенцией.

Нужно ли включать security в 8.x?

Да, с 8.0 security включён по умолчанию. Отключать в продакшне категорически нельзя — открытый ES уже сколько раз попадал в новости с утечками. Настройте TLS и пароли сразу.