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

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

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

Примеры предполагают использование Linux-хостов и установку из пакетов или архива. Адаптируйте команды управления службами под вашу среду.

Перед редактированием конфигурации

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

Каждый хост должен иметь:

• Одинаковую версию Elasticsearch.
• Стабильный частный IP-адрес или DNS-имя.
• Транспортное соединение между узлами через порт 9300 по умолчанию.
• HTTP-доступ через порт 9200 с вашего административного хоста или балансировщика нагрузки, если необходимо.
• Достаточно дискового пространства для первичных и реплицированных шардов.
• Синхронизацию времени через NTP или аналогичную службу.
• Настроенный путь к данным на надежном локальном или подключенном хранилище.

Современные дистрибутивы Elasticsearch включают встроенный JDK. Если ваш пакет или версия требует внешнего JDK, используйте поддерживаемую версию Java для этого выпуска Elasticsearch, а не гадайте.

Используйте частные адреса в discovery.seed_hosts. Избегайте публичных IP-адресов, если только у вас нет очень специфической архитектуры и строгих сетевых controls.

Для этого руководства узлы имеют следующие адреса:

node-1  10.0.10.11
node-2  10.0.10.12
node-3  10.0.10.13

Настройка общих параметров кластера

На каждом узле отредактируйте elasticsearch.yml. Расположение файла зависит от способа установки. При установке из пакета обычно используется /etc/elasticsearch/elasticsearch.yml; при установке из архива — config/elasticsearch.yml в извлеченном каталоге.

Установите одинаковое имя кластера на всех трех узлах:

cluster.name: my-three-node-cluster

Установите узлы обнаружения на всех трех узлах:

discovery.seed_hosts:
  - 10.0.10.11:9300
  - 10.0.10.12:9300
  - 10.0.10.13:9300

Установите начальные узлы-мастера только для первой загрузки:

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

Значения должны соответствовать node.name, а не IP-адресам, если только имена ваших узлов не похожи на IP-строки. Этот параметр предназначен только для формирования нового кластера. После успешного формирования кластера удалите cluster.initial_master_nodes со всех узлов и не используйте его при будущих перезапусках. Его наличие может вызвать путаницу при аварийном восстановлении или случайных попытках повторной загрузки.

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

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

Используйте собственный IP-адрес каждого узла для network.host. 0.0.0.0 удобен в примерах, но в производственной среде может открыть Elasticsearch на нежелательных интерфейсах. Если в вашей версии включена автоматическая настройка безопасности, вам также потребуется учесть сертификаты TLS, регистрацию и аутентификацию.

Настройка имени каждого узла

На узле 1:

node.name: node-1
network.host: 10.0.10.11
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

На узле 2:

node.name: node-2
network.host: 10.0.10.12
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

На узле 3:

node.name: node-3
network.host: 10.0.10.13
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Если вы запускаете несколько узлов на одной машине для тестирования, используйте отдельные значения path.data и path.logs. Для реальных кластеров обычно предпочтительнее один узел на хост.

Выбор ролей узлов

Для небольшого трехнодового кластера все три узла могут выполнять стандартные роли:

node.roles: [ master, data, ingest, remote_cluster_client ]

Это дает три узла, имеющих право быть мастерами, поэтому выборы мастера работают по принципу большинства. С тремя такими узлами кластер может потерять один и все равно избрать или сохранить мастера. Если два узла вышли из строя, он не может безопасно принимать решения о состоянии кластера.

Для более крупного кластера часто лучше выделить отдельные узлы-мастера, чтобы тяжелая работа с данными или приемом не мешала выполнению обязанностей мастера. Это уточнение масштабирования, а не требование для данной базовой настройки.

Проверка основ ОС и сети

Перед запуском Elasticsearch проверьте транспортное соединение между каждой парой узлов:

nc -vz 10.0.10.11 9300
nc -vz 10.0.10.12 9300
nc -vz 10.0.10.13 9300

По возможности выполняйте эти команды с каждого узла. Брандмауэры и группы безопасности облака должны разрешать трафик между узлами по транспортному протоколу. HTTP-порт 9200 предназначен для клиентов и административных вызовов; транспортный порт 9300 используется узлами кластера для общения друг с другом.

Также проверьте права собственности на файлы в каталогах данных и журналов. Процесс Elasticsearch должен иметь возможность записи в оба каталога.

Запуск узлов

Для установки из пакета с systemd:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

Для установки из архива при тестировании:

bin/elasticsearch

Запустите все три узла. Они не обязательно должны запускаться в строгом порядке, но следите за журналами. Вы должны увидеть, как кластер формируется один раз, а узлы присоединяются к нему. Если узел сообщает, что не может найти мастера, проверьте node.name, cluster.name, discovery.seed_hosts, транспортное соединение и настройки TLS/безопасности.

После формирования кластера удалите cluster.initial_master_nodes из конфигурации каждого узла и перезапустите позже в запланированное окно, если необходимо. Не удаляйте его, пока вы все еще пытаетесь выполнить первую загрузку.

Проверка работоспособности кластера

С хоста, имеющего доступ к порту 9200:

curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Новый кластер без пользовательских индексов может показывать зеленый статус с нулевым количеством шардов. Поля, которые стоит проверить: status, number_of_nodes и number_of_data_nodes.

Для компактного отображения:

curl -s "http://10.0.10.11:9200/_cat/health?v"

Затем проверьте состав узлов:

curl -s "http://10.0.10.11:9200/_cat/nodes?v&h=ip,name,roles,master,cpu,heap.percent,ram.percent,disk.used_percent"

Вы должны увидеть все три узла. Один узел будет отмечен как избранный мастер. Все три должны показывать ожидаемые роли.

Создание тестового индекса с репликами

Создайте тестовый индекс для проверки размещения шардов:

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

Проверьте шарды:

curl -s "http://10.0.10.11:9200/_cat/shards/test-data-index?v"

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

Если кластер желтый, выясните причину:

curl -X GET "http://10.0.10.11:9200/_cluster/allocation/explain?pretty"   -H 'Content-Type: application/json'   -d '{}'

Распространенные причины: недостаточно подходящих узлов данных, пороговые значения диска, отключенное выделение или правила осведомленности о выделении, не соответствующие атрибутам ваших узлов.

Тестирование поведения при отказе одного узла

В непроизводственном тесте остановите один узел:

sudo systemctl stop elasticsearch

Проверьте работоспособность с другого узла:

curl -s "http://10.0.10.12:9200/_cluster/health?pretty"

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

sudo systemctl start elasticsearch
curl -s "http://10.0.10.12:9200/_cat/recovery?v&active_only=true"

Этот тест стоит провести до того, как кластер станет важным. Он учит, как выглядит нормальное восстановление, чтобы реальная авария была менее неожиданной.

Несколько производственных рекомендаций

Включите и изучите безопасность для вашей версии Elasticsearch. Не открывайте неаутентифицированный HTTP API в интернет или широкую внутреннюю сеть.

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

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

Поддерживайте умеренное количество шардов. Множество маленьких шардов создают накладные расходы. Базовый кластер может быть перегружен тысячами крошечных индексов, даже если объем данных невелик.

Наконец, задокументируйте настройки начальной загрузки и удалите cluster.initial_master_nodes после формирования. Большинство проблем с настройкой трехнодового кластера возникают из-за мелких несоответствий: имена узлов не совпадают с именами в начальной загрузке, заблокированные транспортные порты, повторно используемые каталоги данных от старых кластеров или предположения о настройках безопасности по умолчанию. Проверьте их в первую очередь, прежде чем менять более экзотические параметры.

Замечания по безопасности для текущих версий Elasticsearch

Многие современные установки Elasticsearch включают функции безопасности во время настройки. Это означает, что HTTP-вызовы могут требовать HTTPS, сертификат CA и учетные данные. Если ваш кластер был автоматически настроен с TLS, проверка работоспособности может выглядеть так:

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

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

TLS на транспортном уровне также может влиять на присоединение узлов. Если узлы не могут присоединиться, а в журналах упоминаются проблемы с доверием сертификатов, несовпадением SAN, сбоем рукопожатия или ошибками удаленного транспорта, проверьте сертификаты, прежде чем менять настройки обнаружения. Идеальный список discovery.seed_hosts не поможет узлам, которые отклоняют друг друга во время TLS-рукопожатия.

Распространенные ошибки при запуске

Если узлы не формируют кластер, сначала проверьте простые вещи.

cluster.name должен совпадать на всех узлах. Узел с другим именем кластера не присоединится только потому, что он указан в списке seed-хостов.

node.name должен соответствовать значениям, используемым в cluster.initial_master_nodes при первой загрузке. Если в конфиге указано node-1, а в начальной загрузке es-node-1, обнаружение может остановиться.

Транспортный порт должен быть доступен между узлами. HTTP-доступа на порту 9200 недостаточно. При необходимости используйте nc, проверку групп безопасности или захват пакетов.

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

Проверки памяти и начальной загрузки имеют значение при привязке к не-loopback адресу. Elasticsearch может проверять лимиты файловых дескрипторов, виртуальной памяти, блокировки памяти и конфигурацию обнаружения. Читайте журнал запуска, а не повторяйте попытки вслепую.

После того, как кластер заработал

Создайте репозиторий для снимков до того, как кластер будет содержать важные данные. Реплики — это не резервные копии. Неправильное удаление, ошибка в маппинге или баг приложения быстро реплицируются на все копии.

Запишите имена узлов, IP-адреса, роли, пути к данным, расположение сертификатов и историю начальной загрузки в вашем runbook. Во время аварии никто не хочет выяснять, должен ли node-2 иметь право быть мастером.

Настройте оповещения о потере узла, красном статусе, длительном желтом статусе, пороговых значениях диска, давлении JVM heap, неудачных снимках и частых выборах мастера. Трехнодовый кластер дает вам возможность пережить один отказ, но только если вы заметите и устраните его до второго отказа.

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

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

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

Простая последовательность:

sudo systemctl restart elasticsearch
curl -s "http://10.0.10.11:9200/_cat/nodes?v"
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Если в кластере есть большие шарды, подумайте, нужно ли настроить отложенное выделение перед запланированными перезапусками. Цель — избежать ненужного перестроения реплик, когда узел вернется через несколько минут. После обслуживания убедитесь, что выделение включено, а временные настройки удалены.

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

Еще одна полезная привычка: храните копию окончательного elasticsearch.yml для каждого узла в системе управления конфигурацией. Ручные правки, сделанные во время настройки, имеют тенденцию расходиться, а расхождение — это именно то, что делает следующую замену узла сложнее, чем нужно.