Настройка Elasti c Поисковый кластер с машинами различной емкости (ЦП, ОЗУ) для непрерывного обновления - PullRequest
0 голосов
/ 28 февраля 2020

Из-за ограничений по стоимости у меня есть только следующие типы машин для настройки кластера ES.

  1. Узел A: экземпляр Lean (относительно ЦП, ОЗУ)
  2. Узел B: экземпляр Beefy (относительно CPU, RAM)
  3. Узел M: "менее чем A "(без ЦП, ОЗУ) Экземпляр

По дискам и A, и B имеют одинаковый размер.

Я планирую настроить Узлы A и Узел B, действующие как Master Допустимый узел данных и узел М в качестве главного узла, имеющего право только на узел (без сохранения данных). Поскольку два узла данных НЕ идентичны, каковы будут последствия?

Я собираюсь сделать его кластером из 3 машин только для возможности циклического обновления (текущий объем данных и ожидаемый рост в течение нескольких лет могут управляться с вертикальным масштабированием и оставлением по умолчанию количества шардов и Реплика позволит мне масштабировать горизонтально, если есть необходимость)

1 Ответ

1 голос
/ 28 февраля 2020

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

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

Обновление:

Что касается распределения нагрузки и сегмента (куда помещать данные), Elasticsearch by по умолчанию будет просто учитывать объем доступного хранилища. Когда вы запускаете экземпляр Elasticsearch, он анализирует оборудование и настраивает свои пулы потоков (количество потоков и размер очереди) для различных задач соответственно. Таким образом, количество доступных потоков для обработки задач может варьироваться. Если я не ошибаюсь, координирующий узел (узел, получающий внешний запрос) будет распределять запросы на индексирование / запись в циклическом порядке, не принимая во внимание нагрузку. В зависимости от вашей версии Elasticsearch это отличается для запросов поиска / чтения, где координирующий узел будет использовать адаптивный выбор реплики, принимая во внимание время загрузки / отклика различных реплик при распределении запросов.

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

Кстати: количество основных шардов по умолчанию было изменено в v7.x Elasticsearch, так как слишком много избыточной защиты было одним из наиболее распространенных проблемы, с которыми сталкивались пользователи Elasticsearch. «Разумный» размер осколка составляет десятки гигабайт.

...