Архитектура кластера ElasticSearch

Здравствуйте, коллеги.
Проконсультируйте, пожалуйста.

В настоящий момент я собираю кластер ElasticSearch.
Получается следующая схема (HA):

Площадка 1(основная):
1хMaster node
3хData node(hot)

Площадка 2(резервная - копия данных основной):
1хMaster node
3хData node (hot)

Диски SSD.

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

Безусловно Logstash должен продолжать лить данные на доступную площадку.

В связи с этим у меня есть ряд вопросов:
Правильно ли я понимаю, то что включение настройки
master.node: true обеспечивают данный результат ? если нет то подскажите, как настроить или куда посмотреть.

Как в этой ситуации необходимо настраивать Logstash output? Необходимо настроить отправку в master на обе площадки или есть другие решения, чтобы не нагружать канал между площадками?

Заранее спасибо за ответ

Не совсем.

если нет то подскажите, как настроить или куда посмотреть.

Зависит от того, распеределены ли площадки географически или нет. Если нет - то лучше добавить еще одну площадку (хотя бы маленькую с одним voting-only master-eligible узлом) объеденить все в один кластер, и смотреть надо тут
Discovery and cluster formation | Elasticsearch Guide [8.11] | Elastic и Cluster-level shard allocation and routing settings | Elasticsearch Guide [8.11] | Elastic особенно на forced awareness в вашем случае.

Если одна площадка в Москве а другая на Сахалине, то надо все ноды сделать master-eligible, оставить два отдельных кластера и смотреть тут - Cross-cluster replication | Elastic Stack Overview [7.4] | Elastic

Игорь, приветствую. Рад слышать) У меня в проекте две географически разделенные площадки.
Насколько я понимаю ccr входит в состав X-pack и распространяется под Platinum лицензию. Скорее всего это следующий шаг и да, спасибо за ссылку.

А если исходить от базовой лицензии. У меня в каждом кластере есть +1 одна Ingest node и Logstash. В итоге, Ingets node\logstash разливают данные по data nodes, а Beats отправляет данные на ingets nodes на обе площадки. Как по вашему мнению такая конфигурация жизнеспособна? И каких сюрпризов от нее можно ожидать на первых этапах проекта? Или вообще отказаться от какого то куска?

Срок хранения данных на первом этапе планируется 1-2 месяца.
Затем планируется масштабирование.

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

Игорь, Спасибо, за ответы.

Скажите,
Правильно ли я понимаю:
Все Beat будут идти у меня с настройкой loadbalancer: true на две ноды logstash, расположенные по одному на площадке 1 и 2. Конфигурация logstash output должна включать в себя все ноды кластера elastic или logstash должен отправлять данные только в свои data node расположенные на той же площадке?

Ко всему прочему, к кластеру я планирую подключить Cordinate node и подключить к ней кибану и Grafana, это нормальная практика?

И Игорь, подскажите, по версии elastic 7.3. Правильно ли я понимаю, что в версии 7.3 голосующую ноду можно включить на любой другой data node на площадке?
И насколько я слышал в версии 7.3 представлена возможность включения парольной защиты кластера(в базовой лицензии), где можно найти информацию по этому вопросу?

Заранее большое спасибо за оказанную поддержку и помощь!

На сколько я понимаю, loadbalance разделяет нагрузку по нескольким logstash-ам, а не дублицирует ее, а вам надо как раз наоборот?

Конфигурация logstash output должна включать в себя все ноды кластера elastic или logstash должен отправлять данные только в свои data node расположенные на той же площадке?

Вы не могли более подробно описать свой план. Судя по этим вопросам, я не правильно себе представляю, что вы хотите сделать.

Ко всему прочему, к кластеру я планирую подключить Cordinate node и подключить к ней кибану и Grafana, это нормальная практика?

Это нормальная практика для больших кластеров. Для вашего кластера, я думаю, это пока делать рановато.

Правильно ли я понимаю, что в версии 7.3 голосующую ноду можно включить на любой другой data node на площадке?

Для выборов нужен кворум. Если Вы разместите ноду на одной из 2 площадок, то если эта площадка упадет - то вторая не сможет провести выборы, так как у нее одной кворума не будет.

И насколько я слышал в версии 7.3 представлена возможность включения парольной защиты кластера(в базовой лицензии), где можно найти информацию по этому вопросу?

Заранее большое спасибо за оказанную поддержку и помощь!

Рад помочь! Кстати, если интересно, то у нас будут курсы в Москве в середине октября. Читать их, скорее всего, буду я, но в любом случае мы там многие эти и другие вопросы будем подробно обсуждать.

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

А если представить, то что все ноды (на двух площадках являются одним большим кластером). То есть Beats балансирует данные на оба logstash (на площадке 1 и 2), а дальше logstash разливает данные по data nodes. Я уменьшаю нагрузку на канал и в случае если площадка упадет, то нагрузку на себя примет доступный Logstash. Нужно ли вводить мастер ноду в этой ситуации?

То есть мне необходимо подключать Kibana и Grafana в этой ситуации к master
node, а она отдаст информацию от всего кластера?

Да, этот момент я прорабатывал, в итоге пришел к выводу, что можно через VirtualIP реализовать.

Здорово, буду иметь ввиду и постараюсь быть. Спасибо еще раз за содействие и заранее простите за возможно базовые вопросы!

Я думаю, было бы неплохо подробно изучить весь раздел Discovery And cluster formation нашей документации. Одна мастер нода в кластере это не хорошо, потому что если эта нода накрывается, кластер становиться неработоспособным. Выделенные мастер ноды, если их 3, увеличивают устойчивость кластера, но если на них посылать трафик из кибаны, но весь толк от их выделения пропадает.

Хорошо, третью мастер ноду я размещу в другой стойке, для устойчивости кластера при падении серверов, понимаю, что это не застрахует от падения площадки полностью, но это следующие шаги. А как же быть с подключением Кибана и Графана, есть ли рекомендации по этому поводу?

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

Игорь, спасибо большое за консультацию.
Кластер собран=)

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.