Настройка Elasticsearch кластера для веб-приложения
При переходе от единичного инстанса Elasticsearch к кластеру многие сталкиваются с неочевидными проблемами: split-brain, неправильное распределение шардов, утечка памяти. Мы подготовили пошаговое руководство по настройке production-кластера на 3 узлах — от конфигурации ролей до ILM. Наш опыт показывает, что правильно настроенный кластер окупается уже через месяц работы под нагрузкой.
Почему стоит выбирать кластер из трёх узлов?
Одиночный узел подходит только для разработки. В продакшене нужен кластер: для отказоустойчивости, горизонтального масштабирования и изоляции нагрузок. Кластер из 3 узлов в 10 раз надёжнее одиночного инстанса: он выдерживает отказ одного узла без потери данных и работает на параллельных запросах. Для большинства веб-приложений это оптимальный баланс цены и производительности.
Роли узлов кластера
В Elasticsearch 8.x каждый узел может выполнять несколько ролей. Для небольшого кластера (3–5 узлов) все узлы обычно выполняют все роли. Для кластера от 10 узлов — разделение обязательно.
| Роль | Назначение | Ресурсы |
|---|---|---|
| Master-eligible | Управление состоянием кластера, выборы мастера | Не более 3 узлов, низкие CPU/RAM |
| Data | Хранение шардов, поиск, агрегации | Быстрые диски (NVMe), много RAM |
| Coordinating | Приём запросов, балансировка, сбор результатов | CPU для scatter-gather |
| Ingest | Предобработка документов (парсинг, обогащение) | Средние CPU/RAM |
Master-eligible node — участвует в выборах мастера, управляет cluster state. Минимум 3 master-eligible узла для кворума.
Data node — хранит шарды, выполняет поиск. Самые ресурсоёмкие: нужны быстрые диски (NVMe) и много RAM для JVM heap и файлового кэша OS.
Coordinating node (client node) — принимает запросы от клиентов, распределяет по data-узлам, собирает результаты. Снимает нагрузку с data-узлов на фазе scatter-gather.
Ingest node — обрабатывает документы через ingest pipelines (парсинг, обогащение, трансформация). Конфигурация ролей в elasticsearch.yml:
# Master-only node node.roles: [ master ] # Data node node.roles: [ data, data_content, data_hot, data_warm, data_cold ] # Coordinating only node.roles: [] Минимальная продакшен конфигурация: 3 узла
Все три узла — master-eligible + data. Это даёт кворум (2 из 3) и хранение данных. elasticsearch.yml для узла 1:
cluster.name: myapp-prod node.name: es-node-01 node.roles: [master, data, ingest] network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: - es-node-01:9300 - es-node-02:9300 - es-node-03:9300 cluster.initial_master_nodes: - es-node-01 - es-node-02 - es-node-03 path.data: /var/lib/elasticsearch path.logs: /var/log/elasticsearch xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.keystore.path: elastic-certificates.p12 xpack.security.transport.ssl.truststore.path: elastic-certificates.p12 На узлах 2 и 3 меняется только node.name.
cluster.initial_master_nodes указывается только при первом запуске кластера. После формирования кластера эту строку нужно закомментировать — иначе при перезапуске возможен split-brain.
JVM и память
Elasticsearch по умолчанию берёт 1 GB heap — для продакшена критически мало. Правило: heap = половина доступной RAM, но не более 31 GB (выше 32 GB JVM теряет compressed oops).
В /etc/elasticsearch/jvm.options.d/heap.options:
-Xms16g -Xmx16g Оставшаяся память уходит на файловый кэш OS — Elasticsearch активно использует mmap для чтения сегментов Lucene. На сервере с 64 GB RAM: 31 GB heap + 30+ GB под OS cache = оптимальная конфигурация.
Настройка системы:
# /etc/sysctl.conf vm.max_map_count=262144 vm.swappiness=1 # /etc/security/limits.conf elasticsearch soft memlock unlimited elasticsearch hard memlock unlimited elasticsearch soft nofile 65536 elasticsearch hard nofile 65536 Генерация TLS сертификатов и настройка безопасности
# Генерация CA и сертификатов для кластера /usr/share/elasticsearch/bin/elasticsearch-certutil ca --out /etc/elasticsearch/elastic-ca.p12 /usr/share/elasticsearch/bin/elasticsearch-certutil cert \ --ca /etc/elasticsearch/elastic-ca.p12 \ --out /etc/elasticsearch/elastic-certificates.p12 # Установка пароля elastic пользователя /usr/share/elasticsearch/bin/elasticsearch-setup-passwords auto HTTP TLS (для клиентских подключений) — отдельный сертификат:
xpack.security.http.ssl.enabled: true xpack.security.http.ssl.keystore.path: http.p12 Как настроить ILM для экономии ресурсов?
Для логов и временных данных политика ILM обязательна. Без неё индексы растут бесконечно, забивая диск. Пример политики с четырьмя фазами:
PUT _ilm/policy/logs-policy { "policy": { "phases": { "hot": { "min_age": "0ms", "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" }, "set_priority": { "priority": 100 } } }, "warm": { "min_age": "7d", "actions": { "shrink": { "number_of_shards": 1 }, "forcemerge": { "max_num_segments": 1 }, "set_priority": { "priority": 50 } } }, "cold": { "min_age": "30d", "actions": { "freeze": {}, "set_priority": { "priority": 0 } } }, "delete": { "min_age": "90d", "actions": { "delete": {} } } } } } Пошаговая настройка кластера
- Аналитика: определяем нагрузку, количество данных, нужные роли узлов.
- Проектирование: выбираем количество узлов, размер дисков, настройки JVM.
- Установка: разворачиваем узлы на серверах или в контейнерах, настраиваем сеть.
- Конфигурация безопасности: генерируем TLS, устанавливаем пароли.
- Настройка ILM и шаблонов: создаём политики управления индексами.
- Тестирование: проверяем статус кластера, распределение шардов, отказоустойчивость.
- Деплой: подключаем приложение, включаем мониторинг через Kibana.
Что входит в настройку под ключ
- Развёртывание кластера на bare metal или в облаке
- Настройка TLS и базовой безопасности
- Настройка ILM и шаблонов индексов
- Интеграция с Kibana для мониторинга
- Документация по эксплуатации
- Обучение команды основам администрирования
- 2 недели постаундой поддержки
Проверка состояния кластера
# Статус кластера (green/yellow/red) curl -u elastic:changeme http://localhost:9200/_cluster/health?pretty # Список узлов curl -u elastic:changeme http://localhost:9200/_cat/nodes?v # Неназначенные шарды и причины curl -u elastic:changeme "http://localhost:9200/_cluster/allocation/explain?pretty" Статус yellow означает, что все первичные шарды назначены, но часть реплик — нет. На кластере из 1 узла это нормально. На 3-узловом кластере yellow — сигнал проблемы.
Подключение из приложения
PHP (Laravel / elasticsearch-php):
use Elastic\Elasticsearch\ClientBuilder; $client = ClientBuilder::create() ->setHosts(['https://es-node-01:9200', 'https://es-node-02:9200', 'https://es-node-03:9200']) ->setBasicAuthentication('elastic', 'changeme') ->setCABundle('/path/to/ca.crt') ->build(); Клиент автоматически выполняет sniffing — обнаруживает все узлы кластера и балансирует запросы. При падении узла переключается на оставшиеся.
Python (elasticsearch-py):
from elasticsearch import Elasticsearch es = Elasticsearch( ['https://es-node-01:9200', 'https://es-node-02:9200'], basic_auth=('elastic', 'changeme'), ca_certs='/path/to/ca.crt', retry_on_timeout=True, max_retries=3, ) Сроки и как заказать
Развёртывание 3-узлового кластера с TLS, ILM и мониторингом — от 5 рабочих дней. Миграция существующих данных из одиночного инстанса — ещё 1–2 дня. Точную стоимость рассчитываем индивидуально после аудита. Мы работаем с 2018 года и выполнили более 50 проектов по настройке Elasticsearch. Получите консультацию у наших инженеров — мы расскажем, какая конфигурация оптимальна для ваших задач.