Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps

Руководство по настройке отказоустойчивого кластера Elasticsearch

Настройте отказоустойчивый кластер Elasticsearch с ролями узлов, обнаружением, репликами, настройкой JVM и проверками работоспособности.

Руководство по настройке отказоустойчивого кластера Elasticsearch

Elasticsearch может оставаться доступным при сбоях узлов, но только если вы правильно спланируете выборы мастера, размещение данных, реплики и обнаружение. Одноузловой кластер может работать в разработке, но он не защитит вашу поисковую нагрузку от отказа хоста.

Это руководство покажет вам, как настроить отказоустойчивый кластер Elasticsearch с выделенными узлами, имеющими право на роль мастера, узлами данных, репликами шардов и базовыми командами проверки.

Понимание отказоустойчивости в Elasticsearch

Отказоустойчивость в Elasticsearch достигается с помощью нескольких ключевых механизмов:

  • Распределенная архитектура: Elasticsearch изначально распределяет данные и операции по нескольким узлам.
  • Роли узлов: Разные узлы могут выполнять разные функции, что позволяет специализировать распределение ресурсов и изолировать сбои.
  • Репликация шардов: Каждый индекс делится на шарды, и каждый первичный шард может иметь одну или несколько реплик, хранящихся на разных узлах.
  • Выборы мастер-узла: Надежный процесс выборов гарантирует, что мастер-узел всегда доступен для управления состоянием кластера.
  • Zen Discovery (Zen2): Этот модуль отвечает за обнаружение узлов и выборы мастера, обеспечивая надежное обнаружение узлов друг друга и формирование кластера.

Основные роли узлов

В отказоустойчивой конфигурации понимание ролей узлов имеет решающее значение. Основные роли для отказоустойчивости:

  • Узлы, имеющие право на роль мастера: Эти узлы отвечают за управление состоянием кластера, включая создание/удаление индексов, отслеживание узлов и распределение шардов. Они не хранят данные и не обрабатывают поисковые/индексные запросы напрямую, если у них также нет роли data. Для отказоустойчивости у вас должно быть нечетное количество (обычно 3) выделенных узлов, имеющих право на роль мастера, для формирования кворума.
  • Узлы данных: Эти узлы хранят ваши проиндексированные данные в шардах и выполняют операции, связанные с данными, такие как поиск, агрегация и индексация. Они являются рабочей лошадкой вашего кластера.
  • Только координирующие узлы: (Необязательно) Эти узлы могут использоваться для маршрутизации запросов, обработки фаз сокращения поиска и управления массовой индексацией. Они не хранят данные или состояние кластера, но могут разгрузить узлы данных и мастера.

Шарды и реплики

Elasticsearch хранит ваши данные в шардах. Каждый индекс состоит из одного или нескольких первичных шардов. Для обеспечения отказоустойчивости следует настроить одну или несколько реплик шардов для каждого первичного шарда. Реплики шардов — это копии первичных шардов. Если узел, на котором находится первичный шард, выходит из строя, реплика на другом узле может быть повышена до нового первичного шарда, что гарантирует отсутствие потери данных и продолжение работы.

Предварительные требования для настройки отказоустойчивого кластера

Прежде чем приступить к настройке, убедитесь, что ваша среда соответствует следующим базовым требованиям:

  • Пакеты или архивы Elasticsearch: Официальные пакеты включают встроенную JDK в последних версиях Elasticsearch. Если ваша установка использует отдельную JDK, убедитесь, что она совместима с вашей версией Elasticsearch.
  • Системные ресурсы: Выделите достаточный объем ОЗУ (например, 8-32 ГБ), ядер ЦП и дискового пространства с быстрым вводом/выводом (рекомендуется SSD) для каждого узла, особенно для узлов данных.
  • Сетевая конфигурация: Все узлы должны иметь возможность взаимодействовать друг с другом через определенные порты (по умолчанию 9300 для межузлового взаимодействия, 9200 для HTTP API). Убедитесь, что брандмауэры настроены соответствующим образом.
  • Операционная система: Для производственных развертываний обычно предпочтительна стабильная версия Linux (например, Ubuntu, CentOS, RHEL).

Пошаговое руководство по настройке отказоустойчивого кластера

В этом разделе описывается процесс установки и настройки многопользовательского кластера Elasticsearch.

Шаг 1: Установка Elasticsearch на всех узлах

Установите Elasticsearch на каждом сервере, который будет частью вашего кластера. Вы можете использовать менеджеры пакетов (APT для Debian/Ubuntu, YUM для RHEL/CentOS) или загрузить архив напрямую.

Пример (Debian/Ubuntu через APT):

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt update
sudo apt install elasticsearch

После установки включите и запустите службу (хотя сначала мы ее настроим).

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch

Шаг 2: Настройка elasticsearch.yml на каждом узле

Файл elasticsearch.yml, обычно расположенный в /etc/elasticsearch/, определяет настройки вашего кластера. Отредактируйте этот файл на каждом узле с соответствующими конфигурациями.

Общая конфигурация для всех узлов

  1. cluster.name: Должен быть одинаковым для всех узлов, которые вы хотите объединить в один кластер.

    cluster.name: my-ha-cluster

  2. node.name: Уникальное имя для каждого узла, полезное для идентификации.

    node.name: node-1

  3. network.host: Привязывает Elasticsearch к определенному сетевому интерфейсу. Используйте 0.0.0.0 для привязки ко всем доступным интерфейсам или конкретный IP-адрес.

    network.host: 0.0.0.0
# или конкретный IP-адрес для безопасности/конфигураций с несколькими сетевыми картами
# network.host: 192.168.1.101

  4. http.port: Порт для HTTP-взаимодействия с клиентом (по умолчанию 9200).

    http.port: 9200

  5. transport.port: Порт для межузлового взаимодействия (по умолчанию 9300). Должен быть согласованным.

    transport.port: 9300

Настройки обнаружения (критически важны для отказоустойчивости)

Эти настройки сообщают узлам, как найти друг друга и сформировать кластер.

  1. discovery.seed_hosts: Список адресов узлов, имеющих право на роль мастера в вашем кластере. Таким образом узлы обнаруживают начальные узлы, имеющие право на роль мастера. Укажите IP-адреса или имена хостов всех ваших узлов, имеющих право на роль мастера.

    discovery.seed_hosts: ["192.168.1.101", "192.168.1.102", "192.168.1.103"]

  2. cluster.initial_master_nodes: Используется только при начальной загрузке совершенно нового кластера в первый раз. Этот список должен содержать node.name узлов, имеющих право на роль мастера, которые будут участвовать в первых выборах мастера. После формирования кластера этот параметр игнорируется.

    cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]
    • Важный совет: Удалите или закомментируйте cluster.initial_master_nodes после успешного формирования кластера. Не устанавливайте его снова для перезапусков или добавления новых узлов.

Конфигурация ролей узлов

Укажите роль (роли) для каждого узла. Типичная отказоустойчивая конфигурация включает 3 выделенных мастер-узла и несколько узлов данных.

  • Узлы, имеющие право на роль мастера (например, node-1, node-2, node-3):
    node.roles: [master]
  • Узлы данных (например, node-4, node-5, node-6):
    node.roles: [data]
  • Узлы со смешанными ролями (не рекомендуется для крупных производственных отказоустойчивых систем):
    node.roles: [master, data]
    • Рекомендация: Для истинной отказоустойчивости и стабильности в производстве выделите отдельные узлы для ролей мастера и данных. Это изолирует критические процессы мастера от ресурсоемких операций с данными.

Шаг 3: Настройка размера кучи JVM

Отредактируйте /etc/elasticsearch/jvm.options, чтобы установить размер кучи JVM. Хорошее практическое правило — выделять 50% доступной оперативной памяти, но никогда не превышать 30-32 ГБ. Например, если на сервере 16 ГБ ОЗУ, выделите 8 ГБ:

-Xms8g
-Xmx8g

Шаг 4: Системные настройки

Для производства увеличьте vm.max_map_count и ulimit для открытых файлов на всех узлах. Добавьте эти строки в /etc/sysctl.conf и примените (sudo sysctl -p).

vm.max_map_count=262144

И в /etc/security/limits.conf (или /etc/security/limits.d/99-elasticsearch.conf):

elasticsearch - nofile 65536
elasticsearch - memlock unlimited

Шаг 5: Запуск служб Elasticsearch

Запустите службу Elasticsearch на всех настроенных узлах. Часто рекомендуется сначала запускать узлы, имеющие право на роль мастера, но с современным обнаружением порядок менее критичен, если discovery.seed_hosts настроен правильно.

sudo systemctl start elasticsearch

Проверьте статус службы и журналы на наличие ошибок:

sudo systemctl status elasticsearch
sudo journalctl -f -u elasticsearch

Шаг 6: Проверка работоспособности кластера

После запуска всех узлов проверьте работоспособность кластера с помощью API Elasticsearch. Вы можете запросить любой узел в кластере.

curl -X GET "localhost:9200/_cat/health?v&pretty"

Ожидаемый вывод:

epoch      timestamp cluster        status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1678886400 12:00:00  my-ha-cluster  green      6          3       0    0    0    0        0             0                  -                 100.0%
  • status: Должен быть green (все первичные шарды и реплики распределены) или yellow (все первичные шарды распределены, но некоторые реплики еще нет). red указывает на серьезную проблему.
  • node.total: Должен соответствовать общему количеству запущенных узлов.
  • node.data: Должен соответствовать количеству узлов данных.

Проверьте узлы, чтобы убедиться, что все они присоединились к кластеру:

curl -X GET "localhost:9200/_cat/nodes?v&pretty"

Ожидаемый вывод (пример для 3 мастер-узлов, 3 узлов данных):

ip         heap.percent ram.percent cpu load_1m load_5m load_15m node.role   master name
192.168.1.101          21          87   0    0.00    0.01     0.05 m           *      node-1
192.168.1.102          20          88   0    0.00    0.01     0.05 m           -      node-2
192.168.1.103          22          86   0    0.00    0.01     0.05 m           -      node-3
192.168.1.104          35          90   1    0.10    0.12     0.11 d           -      node-4
192.168.1.105          32          89   1    0.11    0.13     0.10 d           -      node-5
192.168.1.106          30          91   1    0.12    0.10     0.09 d           -      node-6

Это показывает node-1 как выбранного мастера (* в столбце master) и другие узлы как часть кластера.

Шаг 7: Настройка шардирования и репликации индексов

Для вновь созданных индексов Elasticsearch по умолчанию использует один первичный шард и одну реплику (index.number_of_shards: 1, index.number_of_replicas: 1). Для отказоустойчивости обычно требуется как минимум одна реплика, что означает, что ваши данные существуют как минимум на двух разных узлах. Это гарантирует, что если один узел выйдет из строя, реплика будет доступна в другом месте.

При создании индекса укажите эти настройки:

curl -X PUT "localhost:9200/my_ha_index?pretty" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "index": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }
}'

Если включена безопасность, используйте HTTPS и учетные данные или ключ API в вашей команде curl. Например:

curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic "https://localhost:9200/_cluster/health?pretty"

Эксплуатационные проверки

После того как кластер перейдет в состояние green, проверьте поведение при сбоях, прежде чем производственный трафик будет зависеть от него:

  • Остановите один узел данных и убедитесь, что реплики повышены, а первичные шарды остаются доступными.
  • Остановите выбранный мастер-узел и убедитесь, что выбран другой узел, имеющий право на роль мастера.
  • Проверьте _cat/shards?v на наличие неназначенных шардов после стабилизации кластера.
  • Убедитесь, что клиенты подключаются через несколько узлов или балансировщик нагрузки, а не через одну конечную точку HTTP.

Заключительный вывод

Высокая доступность Elasticsearch достигается за счет трех практических решений: поддержание надежного кворума мастеров, размещение реплик шардов на разных узлах и обеспечение устойчивости клиентов к потере узлов. Начните с трех выделенных узлов, имеющих право на роль мастера, достаточного количества узлов данных для хранения первичных шардов и реплик, а также протестированной процедуры восстановления для перезапусков и сбоев узлов.