Не используется ли балансировщик нагрузки с ElasticSearch?

У меня есть кластер из 3 узлов ElasticSearch, работающих на AWS EC2. Эти узлы настраиваются с помощью OpsWorks/Chef. Я намерен сконструировать этот кластер очень упругий и эластичный (узлы могут входить и выходить, когда это необходимо).

Из всего, что я прочитал об ElasticSearch, кажется, что никто не рекомендует устанавливать балансировку нагрузки перед кластером; вместо этого кажется, что рекомендация состоит в том, чтобы сделать одну из двух вещей:

Укажите ваш клиент по URL/IP одного node, пусть ES выполнит балансировку нагрузки и надеется, что node никогда не опустится.
Скопируйте URL-адреса/IP-адреса всех ваших узлов в клиентское приложение и попросите приложение обработать логику восстановления после сбоя.

Мой фон в основном работает в веб-фермах, где просто разумно создавать огромный пул автономных веб-серверов, бросать перед ним ELB и позволять балансировщику выбирать, какие узлы живы или мертвы. Почему ES, похоже, не поддерживает эту же архитектуру?

Ответ 1

Вам не нужен балансировщик нагрузки - ES уже предоставляет эту функциональность. У вас будет еще один компонент, который может ошибочно работать и который добавит ненужный сетевой хоп.

ES покроет ваши данные (по умолчанию в 5 осколков), которые будут пытаться равномерно распределить между вашими экземплярами. В вашем случае 2 экземпляра должны иметь 2 осколка и 1 только один, но вы можете изменить черепицу на 6 для равного распределения.

По умолчанию для репликации установлено значение "number_of_replicas":1, поэтому одна копия каждого осколка. Предполагая, что вы используете 6 осколков, это может выглядеть примерно так (R - реплицированный осколок):

node0: 1, 4, R3, R6
node1: 2, 6, R1, R5
node2: 3, 5, R2, R4

Предполагая, что узел1 умирает, кластер изменится на следующую настройку:

node0: 1, 4, 6, R3 + новые реплики R5, R2
node2: 3, 5, 2, R4 + новые реплики R1, R6

В зависимости от настроек подключения вы можете подключиться к одному экземпляру (транспортному клиенту) или присоединиться к кластеру (клиент node). С клиентом node вы избежите двойных прыжков, так как вы всегда будете подключаться к правильному осколку/индексу. С транспортным клиентом ваши запросы будут перенаправлены в правильный экземпляр.

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

Ответ 2

Я считаю, что балансировка нагрузки кластера Elasticsearch является хорошей идеей (проектирование отказоустойчивой системы, устойчивой к одиночной ошибке node).

Для создания архива кластера вам понадобятся фон на двух основных функциях Elasticsearch: 1. Написание и обновление документов и 2. Запрос документов.

Дать/индексировать документы в elasticsearch:

Когда новый документ попадает в Elasticsearch для индексирования, Elasticsearch определяет "первичный осколок", документ должен быть назначен на использование "алгоритма маршрутизации осколков"
Процесс Lucene, связанный с осколком, "отображает" поля в документе;
Процесс Lucene добавляет документ к перевернутому индексу Lucene "Люкен"
Любые "осколки (реплики)" затем получают документ; реплика-осколок "отображает" документ и добавляет документ в реперный осколок Lucene "инвертированный индекс"

Запрос документов в Elasticsearch:

По умолчанию, когда запрос отправляется в Elasticsearch, запрос достигает значения node - это становится "запросом node" или "запросом шлюза node" для этого запроса
node транслирует запрос на каждый осколок в индексе (первичная и реплика)
каждый осколок выполняет запрос на локальном перевернутом индексе обломочного осколка.
каждый осколок возвращает верхние 10-20 результатов в "запрос шлюза node"
"запрос шлюза node" затем выполняет сортировку слияния по комбинированным результатам, возвращенным из других осколков,
после завершения сортировки слияния, "запрос шлюза node" и возвращает результаты клиенту
- Слияние-сортировка - это ресурсы центрального процессора и памяти

Архитектор балансировки нагрузки для записи/индексирования/обновлений

Elasticsearch self управляет расположением осколков на узлах. "Мастер node" хранит и обновляет таблицу маршрутизации осколков. "Мастер node" предоставляет копию таблицы маршрутизации осколков на другие узлы кластера.

Как правило, вы не хотите, чтобы ваш мастер node выполнял гораздо больше, чем проверки работоспособности кластера, а также обновлял таблицы маршрутизации и управлял обходами.

Вероятно, лучше всего указать балансировку нагрузки для записи в "узлы данных" (узлы данных - это узлы, которые содержат данные = осколки), и пусть узлы данных используют свои таблицы маршрутизации осколков, чтобы получить записи в правильные осколки.

Архивирование запросов

Elasticsearch создал специальный тип node: "client node", который содержит "нет данных" и не может стать "master node". Клиентская функция node предназначена для выполнения окончательного слияния окончательного ресурса в конце запроса.

Для AWS вы, вероятно, будете использовать тип экземпляра c3 или c4 в качестве "client node"

Лучшей практикой является указать балансировку нагрузки для запросов к клиентским узлам.

Ура!

Литература:

Ответ 3

Вы совершенно правы, чтобы проектировать для "failover", и в AWS, здесь, как я рекомендую вам это сделать.

1) Ограничьте узлы в вашем кластере, которые могут быть выбраны мастером. Для остальных установите node.client: true. Основывайте свой выбор на том, сколько у вас основных настраиваемых узлов на том, сколько вы хотите для восстановления после сбоя.

2) Создайте ELB, который включает только основные выбираемые узлы.

3) В маршруте 53 создайте CNAME для своего кластера со значением, установленным на DNS-имя вашего ELB.