AWS Дисковое пространство кластера Elasticsearch не сбалансировано между экземплярами данных

Question

Фон

У меня есть AWS управляемый кластер Elascsearch v6.0 с 14 экземплярами данных.

Он имеет индексы на основе времени, такие как data-2010-01, ..., data-2020-01.

Проблема

Свободное место для хранения очень несбалансировано между экземплярами, что я вижу в консоли AWS:

Я заметил, что это распределение меняется каждый раз, когда службы AWS проходят через сине-зеленое развертывание. Это происходит при изменении настроек кластера или AWS выпускает обновление.

Иногда сине-зеленый приводит к тому, что в одном из экземпляров полностью не хватает места. Когда это происходит, служба AWS запускает еще один сине-зеленый, и это решает проблему без влияния на клиента. (Тем не менее, это влияет на частоту сердечных сокращений!)

Размер осколка

Размер осколков для наших индексов составляет гигабайт, но ниже рекомендации Elasticsearch из 50GB. Размер осколка зависит от индекса. У многих наших старых индексов есть только несколько документов.

Вопрос

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

Мой вопрос: как алгоритм выбирает, какие сегменты выделить для какого экземпляра, и могу ли я самостоятельно устранить этот дисбаланс?

Answer 1

Я задал этот вопрос поддержки AWS, которая смогла дать мне хороший ответ, поэтому я решил поделиться здесь резюме для других.

Короче:

• AWS Elasticsearch распределяет осколки на основе количества осколков , а не размера осколка , поэтому сохраняйте балансировку размеров ваших осколков, если можете.
• Если у вас настроен кластер Чтобы охватить 3 зоны доступности , сделайте так, чтобы ваш экземпляр данных подсчитывался как , кратный 3 .

Мой случай

Каждый из моих 14 экземпляров получает ~100 shards вместо ~100 GB каждый.

Помните, что у меня много относительно пустых индексов. Это приводит к смешению маленьких и больших осколков, что вызывает дисбаланс, когда AWS Elasticsearch (непреднамеренно) выделяет много больших осколков для экземпляра.

Это еще более усугубляется тем фактом, что у меня установлен кластер быть распределенным по 3 зонам доступности, и количество экземпляров моих данных (14) не делится на 3.

Увеличение количества экземпляров данных до 15 (или уменьшение до 12) решило проблему.

Из AWS Elasticsearch документы на Multi-AZ:

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

Дальнейшее улучшение

Помимо проблемы зоны доступности, Я предлагаю сохранить размеры индексов сбалансированными, чтобы упростить алгоритм AWS.

В моем случае я могу объединить более старые индексы, например, data-2019-01 ... data-2019-12 -> data-2019.