Elasticsearch shards что это

Исправляем статус одиночного
сервера ElasticSearch

Почему в полночь карета превратится в тыкву сервер снова станет жёлтым?

• Потому что в ES принято каждые сутки автоматически создавать новый индекс с именем вида “basename-yyyy.mm.dd” из шаблона.
• Поэтому Replication Factor необходимо уменьшить до нуля не только в существующих индексах, но и в шаблонах, из которых будут создаваться новые индексы.
• Это делается так:

curl -XPUT "127.0.0.1:9200/_template/all?pretty=true" -H 'Content-Type: application/json' -d \ ' < "template" : "*" , "settings": < "number_of_replicas": 0 >>' 

Подпишитесь на новые статьи:

Спасибо за Вашу заявку! В скором времени наш менеджер свяжется с Вами.

Бесплатный тест CDN

Размещение данных в CDN, ускорение сайта, онлайн вещание

Заявка на хранение данных

напишите, если знаете примерный объем данных

Заявка на транскодирование

напишите, какие форматы и качества вас интересуют

Бесплатный CDN

укажите ваш логин в «Докере»

Elasticsearch: сайзинг шардов как завещал Elastic + анонс вебинара + предложения по митапу

Каждый индекс Elasticsearch состоит из шардов. Шарды — это логическое и физическое разделение индекса. В этой статье мы расскажем о сайзинге шардов Elasticsearch — важной его части, серьёзно влияющей на производительность кластера. В высоконагруженных системах выбор правильной конфигурации архитектуры хранения позволит серьёзно сэкономить на железе. Бóльшая часть статьи основана на соответствующем разделе документации Elastic. Подробности под катом.

Сайзинг шардов Elasticsearch

Как Elasticsearch работает с шардами

Поисковые запросы обычно попадают в несколько шардов (в продукционных нагруженных средах рекомендуем использовать ноду с ролью coordinating). Каждый шард выполняет поисковый запрос в одном процессорном треде. Если запросов много, пул тредов поиска заканчивается (именно поиска, т.к. есть и другие), что приводит к возникновению очередей, снижению производительности и, как следствие, медленной скорости поиска.

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

Давайте теперь краем глаза взглянем на сегменты (см. картинку ниже). Каждый шард Elasticsearch является индексом Lucene. Максимальное количество документов, которое можно закинуть в индекс Lucene — 2 147 483 519. Индекс Lucene разделен на блоки данных меньшего размера, называемые сегментами. Сегмент — это небольшой индекс Lucene. Lucene выполняет поиск во всех сегментах последовательно. Большинство шардов содержат несколько сегментов, в которых хранятся данные индекса. Elasticsearch хранит метаданные сегментов в JVM Heap, чтобы их можно было быстро извлечь для поиска. По мере роста объёма шарда его сегменты объединяются в меньшее количество более крупных сегментов. Это уменьшает количество сегментов, что означает, что в динамической памяти хранится меньше метаданных (см. также forcemerge, к которому мы вернемся чуть дальше в статье).

Еще стоит сказать о ребалансировке кластера. Если добавляется новая нода или одна из нод выходит из строя, происходит ребалансировка кластера. Ребалансировка сама по себе недешёвая с точки зрения производительности операция. Кластер сбалансирован, если он имеет равное количество шардов на каждой ноде и отсутствует концентрация шардов любого индекса на любой ноде. Elasticsearch запускает автоматический процесс, называемый ребалансировкой, который перемещает шарды между узлами в кластере, чтобы его сбалансировать. При перебалансировке применяются заранее заданные правила выделения сегментов (об allocation awareness и других правилах мы подробнее расскажем в одной из следующих статей). Если вы используете data tiers, Elasticsearch автоматически разместит каждый шард на соответствующем уровне. Балансировщик работает независимо на каждом уровне.

Как заставить Elasticsearch ещё лучше работать с шардами

Правильно удалять данные. Если вы удалили документ, из файловой системы он удалится не сразу. Вместо этого, Elasticsearch помечает документ как удаленный на каждом шарде. Отмеченный документ будет продолжать использовать ресурсы, пока он не будет удален во время периодического слияния сегментов. Если нужно физически освободить место, лучше всего сразу удалять индексы целиком, которые в итоге освободят файловую системы.
Создавать шарды размером от 10 до 50 ГБ. Elastic говорит, шарды размером более 50 ГБ потенциально могут снизить вероятность восстановления кластера после сбоя. Из-за той самой ребалансировки, о которой мы говорили в начале статьи. Ну, и большие шарды накладнее передавать по сети. Предел в 50 ГБ выглядит, конечно, как сферический конь в вакууме, поэтому мы сами больше склоняемся к 10 ГБ. Вот тут человек советует 10 ГБ и смотреть на размер документов в следующем плане:

• От 0 до 4 миллионов документов на индекс: 1 шард.
• От 4 до 5 миллионов документов на индекс: 2 шарда.
• Более 5 миллионов документов считать по формуле: (количество документов / 5 миллионов) + 1 шард.

20 или менее шардов на 1 ГБ JVM Heap. Количество шардов, которыми может жонглировать нода, пропорциональны объему JVM Heap ноды. Например, нода с 30 ГБ JVM Heap должна иметь не более 600 шардов. Чем меньше, тем, скорее всего, лучше. Если это пропорция не выполняется можно добавить ноду. Посмотрим сколько там используется JVM Heap на каждой ноде:

А теперь посмотрим сколько шардов на каждой ноде и видим, что с нашим тестовым стендов всё в порядке. Жить будет.

Количество шардов на узле можно ограничить при помощи опции index.routing.allocation.total_shards_per_node, но если их уже много, присмотритесь к Shrink API.

Совсем необязательно создавать индексы размером в 1 день. Часто встречали у заказчиков подход, при котором каждый новый день создавался новый индекс. Иногда это оправдано, иногда можно и месяц подождать. Ролловер ведь можно запускать не только с max_age, но и с max_size или max_docs. На Хабре была статья, в которой Адель Сачков, в ту пору из Яндекс Денег (сейчас уже нет), делился полезным лайфхаком: создавал индексы не в момент наступления новых суток, а заранее, чтобы этот процесс не аффектил на производительность кластера, но у него там были микросервисы.

… каждые сутки создаются новые индексы по числу микросервисов — поэтому раньше каждую ночь эластик впадал в клинч примерно на 8 минут, пока создавалась сотня новых индексов, несколько сотен новых шардов, график нагрузки на диски уходил «в полку», вырастали очереди на отправку логов в эластик на хостах, и Zabbix расцветал алертами как новогодняя ёлка. Чтобы этого избежать, по здравому размышлению был написан скрипт на Python для предварительного создания индексов.

С новогодней ёлкой неплохой каламбурчик получился.

Не пренебрегайте ILM и forcemerge. Индексы должны плавно перетекать между соответствующими нодами согласно ILM. В OpenDistro есть аналогичный механизм.

С индексами, в которые уже не ведется запись можно выполнить forcemerge — слияние меньших по размеру сегментов в более крупные. Это в итоге снизит накладные расходы на эксплуатацию шардов и повысит скорость поиска. Forcemerge требует значительных ресурсов, поэтому лучше это делать к какие-то в непиковые часы. Добавим, что forcemerge это фактические создание нового сегмента из двух старых, поэтому свободное место на диске лишним точно не будет.

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

Анонс вебинара. Elastic приглашает посетить 17 марта в 12 часов по московскому времени вебинар Elastic Telco Day: Applications and operational highlights from telco environments. Эксперты расскажут о применении в решений Elastic в телекоме. Регистрация.

Предложения по митапу. Планируем проведение онлайн-митап по Elastic в апреле. Напишите в комментариях или в личку какие темы вам было бы интересно разобрать, каких спикеров услышать. Если бы вы хотели сами выступить и у вас есть что рассказать, тоже напишите. Вступайте в группу Elastic Moscow User Group, чтобы не пропустить анонс митапа.

Канал в телеге. Подписывайтесь на наш канал Elastic Stack Recipes, там интересные материалы и анонсы мероприятий.

Читайте наши другие статьи:

• Определение объёма кластера Elasticsearch и тестирование производительности в Rally
• Сайзинг Elasticsearch
• Как лицензируется и чем отличаются лицензии Elastic Stack (Elasticsearch)
• Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)
• Elastic под замком: включаем опции безопасности кластера Elasticsearch для доступа изнутри и снаружи

Если вас интересуют услуги внедрения, администрирования и поддержки Elastic Stack, вы можете оставить заявку в форме обратной связи на специальной странице.

Ну и напоследок напоминаю вам о нашем новом проекте vkserfing bot.

ELK — шарды (shards)

Если вы думали, что документы хранятся в index , то огорчу вас это не так. Документы хранятся в шарды. Index просто отслеживает, где что находится. Index — это абстрактный объект, виртуальное пространство имен, которое указывает на несколько шардов. Каждый index разбивается на шарды. Количество шардов можно указать при создании index.

Шарды могут быть раскиданы на разных узлах кластера.

Типы шардов (shard)

Существует два разных типа шардов:

• Первичный (Primary): исходные сегменты индекса.
• Реплики (Replicas): копии/реплики первичного шарда.

Документы реплицируются между первичным и его шардами-репликами. Каждый тип шардов гарантированно находится на разных узлах, что увеличивает отказоустойчивость. Когда говорите о реплике думайте о нём как о копии первичного шарда, имеющей другой тег.

Количество шардов (shard)

Когда создается индекс, он всегда разбивается на какое-то количество шардов. Шарды- это то место, куда записываются и хранятся документы, которые входят в индекс. По умолчанию во время создания индекса количество первичных шардов, которые будет иметь индекс, равно 1. Но вы можете указать другое значение при создании index.

Рекомендуется назначать количество шардов при создании index, так как изменение этого значения в будущем невозможно. Количество же реплик можно настраивать в любое время.

Количество реплик первичного шарда

По умолчанию также стоит значение 1. Это значит, что в кластере с 3 узлами копия первичного шарда будет находится на одном из двух узлов, где не находится первичный шард. За распределение шардов по хостам отвечает master node.

А где реплика в однонодовом кластере? Реплика в однонодовом кластере не создаётся.

Конфигурация количества первичных шардов

По умолчанию количество первичных шардов для индекса равно 1. Как вы узнали ранее, вы можете указать количество первичных шардов при создании индекса.

PUT my_index  "settings":  "number_of_shards": 3 > > 

В такой реализации в кластере с 3 узлами на каждом узле будет по одному шарду.

Раньше по умолчанию было 5

Например, если у вас есть один ежедневный индекс для 5 различных приложений, и каждое из них имеет по умолчанию пять шардов, вы создавали 25 шардов в день. При этом скоро у вас появятся тысячи шардов, даже если вы индексируете всего несколько гигабайт данных в день. Следующим шагом по сокращению чрезмерного сегментирования было присвоение индексов по умолчанию одному шарду.

В идеале создавайте столько шардов, сколько у вас узлов в кластере.

Конфигурация количества реплик первичных шардов

По умолчанию количество реплик равно 1. Это означает, что у каждого первичного шарда будет 1 копия. Вы можете указать необходимое количество реплик при создании индекса. Для этого используйте параметр number_of_replicas . В отличие от количества первичных шардов, вы можете изменить количество реплик в любое время.

PUT my_index  "settings":  "number_of_shards": 3, "number_of_replicas": 2 > > 

А для чего мне эта реплика?

Конечно, для высокой доступности! С одной репликой вы можете потерять один узел, но данные останутся доступными. С 2 репликами вы можете потерять 2 узла, и данные также останутся доступными. Если узел выходит из строя с основным, реплики повышаются до основных по мере необходимости.

Реплики также позволяют масштабировать данные и лучше использовать ресурсы кластера — пропускную способность чтения. Вместо того, чтобы ваши данные располагались на одном узле, они распределяются по разным узлам. Когда вы выполняете поисковый запрос, вас не волнует, выполняется ли поиск по первичному или реплике шарда, все шарды содержат одни и те же данные.

Состояния шардов

Осколки проходят несколько состояний:

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

UNASSIGNED

Состояние UNASSIGNED описывает шарды, которые существуют в конфигурации кластера, которые не могут быть найдены в самом кластере. Кластер знает, что шарды должны быть там, но кластер не может их выделить. Например, у вас не работает раздел в ОС с этими шардами.

Также такой статус может быть в момент создания самого шарда.

INITIALIZING

Состояние INITIALIZING очень короткое, в зависимости от того, насколько нагружен master node., и является первым шагом при создании шардов. Выполняется сразу после UNASSIGNED.

STARTED

Когда первичный шард завершает INITIALIZING, он переходит в состояние STARTED, и теперь его реплики могут быть переходят в состояние INITIALIZING. Состояние кластера будет желтое , потому что отсутствует один шард реплики, который в настоящее время UNASSIGNED (должен стать STARTED).

Когда состояние и первичных шардов и их реплик STARTED состояние кластера будет зелёным.

RELOCATING

Это состояние, когда шарды переносятся с одного узла на другой, например когда вы добавили еще однин узел в кластер.

Состояние кластера

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

В итоге

• Elasticsearch разделяет данные вашего индекса на несколько частей, называемых шардами.
• Выделение шарда ( Shard allocation ) — это процесс назначения шарда узлу в кластере.

Поделиться: Twitter Facebook
Пожалуйста подпишитесь: Telegram Youtube

О Ynwasg

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

Elasticsearch: сайзинг шардов как завещал Elastic + анонс вебинара + предложения по митапу

Каждый индекс Elasticsearch состоит из шардов. Шарды — это логическое и физическое разделение индекса. В этой статье мы расскажем о сайзинге шардов Elasticsearch — важной его части, серьёзно влияющей на производительность кластера. В высоконагруженных системах выбор правильной конфигурации архитектуры хранения позволит серьёзно сэкономить на железе. Бóльшая часть статьи основана на соответствующем разделе документации Elastic. Подробности под катом.

Сайзинг шардов Elasticsearch

Как Elasticsearch работает с шардами

Поисковые запросы обычно попадают в несколько шардов (в продукционных нагруженных средах рекомендуем использовать ноду с ролью coordinating). Каждый шард выполняет поисковый запрос в одном процессорном треде. Если запросов много, пул тредов поиска заканчивается (именно поиска, т.к. есть и другие), что приводит к возникновению очередей, снижению производительности и, как следствие, медленной скорости поиска.

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

Давайте теперь краем глаза взглянем на сегменты (см. картинку ниже). Каждый шард Elasticsearch является индексом Lucene. Максимальное количество документов, которое можно закинуть в индекс Lucene — 2 147 483 519. Индекс Lucene разделен на блоки данных меньшего размера, называемые сегментами. Сегмент — это небольшой индекс Lucene. Lucene выполняет поиск во всех сегментах последовательно. Большинство шардов содержат несколько сегментов, в которых хранятся данные индекса. Elasticsearch хранит метаданные сегментов в JVM Heap, чтобы их можно было быстро извлечь для поиска. По мере роста объёма шарда его сегменты объединяются в меньшее количество более крупных сегментов. Это уменьшает количество сегментов, что означает, что в динамической памяти хранится меньше метаданных (см. также forcemerge, к которому мы вернемся чуть дальше в статье).

Еще стоит сказать о ребалансировке кластера. Если добавляется новая нода или одна из нод выходит из строя, происходит ребалансировка кластера. Ребалансировка сама по себе недешёвая с точки зрения производительности операция. Кластер сбалансирован, если он имеет равное количество шардов на каждой ноде и отсутствует концентрация шардов любого индекса на любой ноде. Elasticsearch запускает автоматический процесс, называемый ребалансировкой, который перемещает шарды между узлами в кластере, чтобы его сбалансировать. При перебалансировке применяются заранее заданные правила выделения сегментов (об allocation awareness и других правилах мы подробнее расскажем в одной из следующих статей). Если вы используете data tiers, Elasticsearch автоматически разместит каждый шард на соответствующем уровне. Балансировщик работает независимо на каждом уровне.

Как заставить Elasticsearch ещё лучше работать с шардами

Правильно удалять данные. Если вы удалили документ, из файловой системы он удалится не сразу. Вместо этого, Elasticsearch помечает документ как удаленный на каждом шарде. Отмеченный документ будет продолжать использовать ресурсы, пока он не будет удален во время периодического слияния сегментов. Если нужно физически освободить место, лучше всего сразу удалять индексы целиком, которые в итоге освободят файловую системы.

Создавать шарды размером от 10 до 50 ГБ. Elastic говорит, шарды размером более 50 ГБ потенциально могут снизить вероятность восстановления кластера после сбоя. Из-за той самой ребалансировки, о которой мы говорили в начале статьи. Ну, и большие шарды накладнее передавать по сети. Предел в 50 ГБ выглядит, конечно, как сферический конь в вакууме, поэтому мы сами больше склоняемся к 10 ГБ. Вот тут человек советует 10 ГБ и смотреть на размер документов в следующем плане:

• От 0 до 4 миллионов документов на индекс: 1 шард.
• От 4 до 5 миллионов документов на индекс: 2 шарда.
• Более 5 миллионов документов считать по формуле: (количество документов / 5 миллионов) + 1 шард.

А теперь посмотрим сколько шардов на каждой ноде и видим, что с нашим тестовым стендов всё в порядке. Жить будет.

Количество шардов на узле можно ограничить при помощи опции index.routing.allocation.total_shards_per_node, но если их уже много, присмотритесь к Shrink API.

Совсем необязательно создавать индексы размером в 1 день. Часто встречали у заказчиков подход, при котором каждый новый день создавался новый индекс. Иногда это оправдано, иногда можно и месяц подождать. Ролловер ведь можно запускать не только с max_age, но и с max_size или max_docs. На Хабре была статья, в которой Адель Сачков, в ту пору из Яндекс Денег (сейчас уже нет), делился полезным лайфхаком: создавал индексы не в момент наступления новых суток, а заранее, чтобы этот процесс не аффектил на производительность кластера, но у него там были микросервисы.

… каждые сутки создаются новые индексы по числу микросервисов — поэтому раньше каждую ночь эластик впадал в клинч примерно на 8 минут, пока создавалась сотня новых индексов, несколько сотен новых шардов, график нагрузки на диски уходил «в полку», вырастали очереди на отправку логов в эластик на хостах, и Zabbix расцветал алертами как новогодняя ёлка. Чтобы этого избежать, по здравому размышлению был написан скрипт на Python для предварительного создания индексов.

С новогодней ёлкой неплохой каламбурчик получился.

Не пренебрегайте ILM и forcemerge. Индексы должны плавно перетекать между соответствующими нодами согласно ILM. В OpenDistro есть аналогичный механизм.

С индексами, в которые уже не ведется запись можно выполнить forcemerge — слияние меньших по размеру сегментов в более крупные. Это в итоге снизит накладные расходы на эксплуатацию шардов и повысит скорость поиска. Forcemerge требует значительных ресурсов, поэтому лучше это делать к какие-то в непиковые часы. Добавим, что forcemerge это фактические создание нового сегмента из двух старых, поэтому свободное место на диске лишним точно не будет.

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

Анонс вебинара. Elastic приглашает посетить 17 марта в 12 часов по московскому времени вебинар Elastic Telco Day: Applications and operational highlights from telco environments. Эксперты расскажут о применении в решений Elastic в телекоме. Регистрация.

Предложения по митапу. Планируем проведение онлайн-митап по Elastic в апреле. Напишите в комментариях или в личку какие темы вам было бы интересно разобрать, каких спикеров услышать. Если бы вы хотели сами выступить и у вас есть что рассказать, тоже напишите. Вступайте в группу Elastic Moscow User Group, чтобы не пропустить анонс митапа.

Канал в телеге. Подписывайтесь на наш канал Elastic Stack Recipes, там интересные материалы и анонсы мероприятий.

Читайте наши другие статьи:

• Определение объёма кластера Elasticsearch и тестирование производительности в Rally
• Сайзинг Elasticsearch
• Как лицензируется и чем отличаются лицензии Elastic Stack (Elasticsearch)
• Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)
• Elastic под замком: включаем опции безопасности кластера Elasticsearch для доступа изнутри и снаружи

Мы разработали обучающий курс по основам работы с Elastic Stack, который адаптируется под конкретные потребности заказчика. Подробная программа обучения по запросу.

• gals software
• галс софтвэр
• elasticsearch
• elk stack
• elastic stack
• logstash
• kibana
• filebeat
• metricbeat
• elastic sizing
• сайзинг кластера elasticsearch
• shards elasticsearch