Как настроить кластер ElasticSearch с автоматическим масштабированием на Amazon EC2?

Существует большой учебник elasticsearch на ec2 о настройке ES на Amazon EC2. Я изучил его и применил все рекомендации.

Теперь у меня есть AMI и я могу запустить любое количество узлов в кластере из этого AMI. Автоматическое обнаружение настроено, и узлы присоединяются к кластеру, как они действительно должны.

Вопрос: Как настроить кластер таким образом, чтобы я мог автоматически запускать/завершать узлы в зависимости от нагрузки на кластер?

Например, я хочу, чтобы выполнялось только 1 node, когда у нас нет нагрузки и 12 узлов, работающих при максимальной нагрузке. Но подождите, если я завершу 11 узлов в кластере, что произойдет с осколками и репликами? Как убедиться, что я не теряю данные в кластере, если я заканчиваю 11 узлов из 12 узлов?

Мне может понадобиться настроить S3 Gateway для этого. Но все шлюзы, кроме локальных, устарели.

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

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

Ответ 1

Автоматическое масштабирование не имеет большого смысла с ElasticSearch.

Перемещение и перераспределение Shard не является легким процессом, особенно если у вас много данных. Он подчеркивает IO и сеть и может ухудшить производительность ElasticSearch. (Если вы хотите ограничить эффект, вы должны дросселировать восстановление кластера с помощью таких параметров, как cluster.routing.allocation.cluster_concurrent_rebalance, index.recovery.concurrent_streams, index.recovery.max_size_per_sec. Это ограничит влияние, но также замедлит повторное балансирование и восстановление).

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

Еще одна вещь, которую следует помнить, заключается в том, что, хотя вы можете изменить количество реплик, вы не можете изменить количество осколков. Это настраивается при создании индекса и не может быть изменено (если вы хотите больше осколков, вам нужно создать другой индекс и переиндексировать все ваши данные). Таким образом, количество черепов должно учитывать размер данных и размер кластера, учитывая большее количество узлов, которые вы хотите, но также и минимальную настройку (может ли меньшее количество узлов содержать все осколки и обслуживать расчетный трафик?).

Итак, теоретически, если вы хотите иметь 2 узла в низкое время и 12 узлов на пике, вы можете установить для вашего индекса 6 осколков с 1 репликой. Таким образом, в низкое время у вас есть 2 узла, которые содержат по шесть осколков, и на пике у вас есть 12 узлов, каждый из которых содержит по 1 осколка.

Но опять же, я настоятельно рекомендую переосмыслить это и проверить влияние перемещения осколков на производительность вашего кластера.

Ответ 2

В тех случаях, когда эластичность вашего приложения управляется переменной нагрузкой запроса, вы можете настроить узлы ES, сконфигурированные так, чтобы не хранить какие-либо данные (node.data = false, http.enabled = true), а затем вставлять их для автоматическое масштабирование. Эти узлы могут разгрузить все HTTP и обработать обработку конфлиций с ваших основных узлов данных (освобождая их для большего количества индексирования и поиска).

Поскольку эти узлы не будут иметь осколков, распределенных для них, динамически увеличивая их вверх и вниз, не должно быть проблемой, и автообнаружение должно позволить им присоединиться к кластеру.

Ответ 3

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

осколки карты к конкретным томам EBS. Допустим, нам нужно 15 осколков. Нам понадобится 15 EBS Volumes
amazon позволяет монтировать несколько томов, поэтому, когда мы начинаем, мы можем начать с нескольких экземпляров, которые имеют к ним несколько томов
как увеличение нагрузки, мы можем развернуть дополнительный экземпляр - до 15.

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

Ответ 4

У меня возникло бы желание предложить другое решение в AWS. Я не знаю, какие данные ES это или как его обновить и т.д. Сделав много предположений, я бы поставил экземпляр ES за ALB (балансировщик нагрузки приложения), у меня был бы запланированный процесс, который регулярно обновляет AMI (если вы это делаете это часто бывает быстро), а затем, основываясь на загрузке вашего единственного сервера, я вызываю больше экземпляров, которые будут созданы из последнего экземпляра, который у вас есть. Добавьте новые экземпляры в ALB, чтобы передать часть загрузки. Поскольку это тихое, я бы вызвал прекращение экземпляров temp. Если вы идете по этому маршруту, еще несколько вещей, чтобы рассмотреть

Используйте экземпляры пятна, поскольку они дешевле, и если он подходит для вашего использования.
Примеры "T" не подходят здесь, так как им нужно время для создания кредитов
Используйте lambdas для задания включения и выключения, если вы хотите быть фантастическим, вы можете инициировать его на основе webhook для шлюза aws.
Сделав больше предположений о вашем случае использования, подумайте о том, чтобы поставить сервер Varnish перед вашей машиной ES, чтобы вы могли дешевле предоставить масштаб на основе стратегии кеша (множество предположений здесь) на основе стресса, который вы можете набрать в правый TTL для выселения кеша. Ознакомьтесь с функцией мягкой очистки для нашего ES-материала, из которого мы получили много хорошего.
если вы сделаете то, что я предлагаю здесь, обязательно сделайте, чтобы ваши порожденные экземпляры ES сообщали о любых журналах обратно в центральное адресуемое место на постоянной машине ES, чтобы вы не теряли журналы, когда машины умирали.