Налаштування кластера 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
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 тижні після здачі. Отримайте консультацію у наших сертифікованих інженерів — ми розповімо, яка конфігурація оптимальна для ваших завдань.