Я хотел бы понять, нужно ли мне, или считается ли это хорошей практикой, иметь балансировщик нагрузки как часть развертывания Elasticsearch.
Насколько я понимаю, клиент отдыха высокого уровня, а также транспортный клиент Elasticsearch могут управлять балансировкой нагрузки между узлами. Таким образом, клиенту нужен список конечных точек, разделенных запятыми, и все.
Есть ли смысл иметь балансировщик нагрузки посередине? В каком случае это может быть полезно? Плюсы и минусы каждого метода?
Обычно внешний балансировщик нагрузки в кластере ES не очень распространен и не требуется, поскольку Elasticsearch уже выполняет балансировку нагрузки, и по умолчанию все узлы данных в кластере ES действуют как координирующая роль, но если вы хотите повысить производительность, вы можете иметь выделенный координирующий узел как хорошо.
Если ваша цель состоит в том, чтобы иметь интеллектуальную балансировку нагрузки, которая повышает производительность, чем если бы вы использовали ES 6.X или выше (по умолчанию включено 7.X), вы получаете его из коробки без какой-либо внешней настройки, путем с помощью адаптивного выбора реплик .
Наличие другого балансировщика нагрузки означает дополнительную настройку и еще один уровень до того, как ваш запрос достигнет ES, поэтому, ИМХО, нет смысла его использовать.
Ответ зависит от вашей архитектуры, а также ваших требований. Вам нужен балансировщик нагрузки для обеспечения высокой доступности? Или по соображениям производительности/масштабируемости? Или оба?
Elasticsearch, как и многие другие распределенные системы, имеет собственные протоколы и семантику для распределения нагрузки между несколькими узлами и управления отказоустойчивостью.
Вы можете использовать эту семантику для настройки узлов таким образом, чтобы узел мог выполнять только роль координатора — эффективно действуя как балансировщик нагрузки для ресурсоемких операций, таких как поисковые запросы или запросы массового индексирования.
Elasticsearch также имеет собственный встроенный протокол для выбора нового главного узла в случае сбоев, что опять же эффективно выполняет роль балансировщика нагрузки.
В общем, я бы порекомендовал вам использовать нативные возможности для достижения ваших целей, а не усложнять, внедряя перед ними другую технологию.
Если вам нужен стабильный URL-адрес для вашего кластера, настройте свой DNS-сервер для достижения этой цели. Кластер, управляемый облачным провайдером, уже должен иметь такую функцию, в противном случае вы можете настроить ее с некоторыми усилиями.
