Налаштування кластера Elasticsearch для веб-застосунку

Налаштування кластера Elasticsearch для веб-застосунку

При переході від одиничного інстансу Elasticsearch до кластера багато хто стикається з неочевидними проблемами: split-brain, неправильний розподіл шардів, витік пам'яті. Ми підготували покрокове керівництво з налаштування production-кластера на 3 вузлах — від конфігурації ролей до ILM. Наш досвід понад 50 проектів показує, що правильно налаштований кластер окупається вже через місяць роботи під навантаженням. Наприклад, при обсязі логів 1 ТБ впровадження ILM може заощаджувати до $300 на місяць завдяки автоматичному переміщенню даних на холодне зберігання. Вартість налаштування під ключ — від $500, гарантія 2 тижні підтримки.

Чому варто обирати кластер із трьох вузлів?

Одиночний вузол підходить лише для розробки. В продакшені потрібен кластер: для відмовостійкості, горизонтального масштабування та ізоляції навантажень. Кластер із 3 вузлів у 10 разів надійніший за одиночний інстанс: він витримує відмову одного вузла без втрати даних і працює на паралельних запитах, збільшуючи продуктивність на 40%. Для більшості веб-застосунків це оптимальний баланс ціни та продуктивності.

Використання ILM дозволяє зменшити вартість зберігання в 2.5 рази порівняно з традиційним підходом.

Ролі вузлів кластера

У Elasticsearch 8.x кожен вузол може виконувати декілька ролей. Для невеликого кластера (3–5 вузлів) всі вузли зазвичай виконують всі ролі. Для кластера від 10 вузлів — розділення обов'язкове.

Master-eligible node — бере участь у виборах майстра, керує cluster state. Мінімум 3 master-eligible вузли для кворуму.

Data node — зберігає шарди, виконує пошук. Найресурсоємніші: потрібні швидкі диски (NVMe) та багато RAM для JVM heap і файлового кешу ОС.

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 

Решта пам'яті йде на файловий кеш ОС — 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 - memlock unlimited elasticsearch - nofile 65536 

Безпека: TLS та автентифікація

Генерація TLS сертифікатів для транспорту:

/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 /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 обов'язкова. Без неї індекси ростуть нескінченно, забиваючи диск. Приклад політики з чотирма фазами, яка скорочує витрати на зберігання до 60%:

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": {} } } } } } 

Покрокове налаштування кластера

Моніторинг та перевірка стану

Перевірка стану кластера

# Статус кластера (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 — сигнал проблеми.

Моніторинг через Kibana

Після налаштування Kibana автоматично відображає метрики кластера: швидкість запитів, використання диска, навантаження на вузли.

Підключення із застосунку

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(); 

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, ) 

Клієнт автоматично виконує sniffing — виявляє всі вузли кластера та балансує запити. При падінні вузла переключається на інші.

Що входить в налаштування кластера

• Аудит поточної інфраструктури та навантаження
• Проектування архітектури (ролі, кількість вузлів, диски)
• Розгортання та конфігурація всіх вузлів (JVM, система, мережа)
• Налаштування безпеки (TLS, автентифікація, RBAC)
• Створення ILM політик та шаблонів індексів
• Інтеграція з вашим застосунком (надання прикладів коду для PHP, Python, Java)
• Написання документації з архітектури та експлуатації
• Навчання вашої команди (2-годинний воркшоп)
• Технічна підтримка 2 тижні після здачі

Терміни та вартість

Розгортання 3-вузлового кластера з TLS, ILM та моніторингом — від 5 робочих днів. Міграція наявних даних з одиночного інстансу — ще 1–2 дні. Вартість налаштування під ключ починається від $500. Ми маємо досвід понад 50 проектів з налаштування Elasticsearch та надаємо гарантію 2 тижні після здачі. Отримайте консультацію у наших сертифікованих інженерів — ми розповімо, яка конфігурація оптимальна для ваших завдань.