Есть ли недостатки в работе Elasticsearch в многоцелевом (то есть не выделенном) кластере? - PullRequest
Новая
       10

Есть ли недостатки в работе Elasticsearch в многоцелевом (то есть не выделенном) кластере?

0 голосов
/ 27 февраля 2020

Я только что настроил кластер узлов Elasticsearch (ES) 3, используя один щелчок GKE для развертывания конфигураций. Каждый узел имеет тип компьютера n1-standard-4 (4 ВЦП / 15 ГБ ОЗУ). Я всегда запускал ES на кластерах, предназначенных для этой единственной цели (соображения производительности, разделение проблем, облегчая мою жизнь для отладки сбоев машины), и в настоящее время этот кластер GKE одинаков.

Однако у меня есть группа пакетных заданий, которые я хотел бы перенести на кластер GKE. Поскольку он обновляет несколько больших файлов, я хотел бы, чтобы он также работал на кластере с сохранением состояния (так же, как ES), чтобы я мог перемещать обновленные файлы в облако один раз в день, а не выполнять циклическое отключение при каждом запуске. Рассматриваемые пакетные задания выполняются с частотой 5 минут, 15 минут или ежедневно в течение примерно 18 часов каждый день.

Теперь у меня вопрос: как лучше всего развернуть этот пакетный процесс с учетом существующего кластера ES ...

  • Создать совершенно новый кластер?
  • Создать еще один пул узлов?
  • Создать отдельное пространство имен и увеличить автоматическое масштабирование кластера?
  • Какой-то другой подход, которого мне не хватает?

Примечание: у меня несколько дней в использовании GKE и контейнеризации в целом

1 Ответ

1 голос
/ 02 марта 2020

Исходя из моих знаний, я бы go для другого nodepool или autoscaler .

Создать совершенно новый кластер?

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

Создать еще один пул узлов?

Я бы сказал, что это лучший вариант наравне с autoscaler, создайте новый пул узлов только для заданий, которые уменьшатся до 0, если больше нечего делать.

Создать отдельное пространство имен и увеличить автомасштабирование кластера?

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

мой вопрос больше о том, не повлияет ли это на autoscaler в пределах одного кластера каким-либо образом наasticsearch esp со всеми спецификациями ES * c yaml?

Не следует, как я уже говорил выше, вы всегда можете label 3 указанных c узла (пул узлов по умолчанию) работать только сasticsearch, тогда ничто не займет их ресурсы, когда кластер будет перемасштабирован потребуется больше ресурсов для заданий и масштабирование до 3 узлов ES, когда задания заканчивают свою работу в течение 18 часов.

Кроме того, что касается пула узлов 6h, который ничего не делает, я не смогу избежать этого в новом кластере или пуле узлов с минимальным параметром масштабирования, равным нулю?

На основании документации gcp это будет работать для пула узлов, но не для нового кластера.

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

tldr Go для автоматического масштабирования или другого пула узлов, если вы ' Вы беспокоитесь о ресурсах для вашей маркировки ES на трех узлах только для ES.

Я надеюсь, что это ответ на ваш вопрос. Дайте мне знать, если у вас есть еще вопросы.

...