Узел

Для обеспечения стабильности кластера важно, чтобы выбранный узел-мастер имел необходимые ресурсы для выполнения своих задач. Если выбранный узел-мастер перегружен другими задачами, кластер будет работать неэффективно. Наиболее надежный способ избежать перегрузки узла-мастера другими задачами — это настройка всех узлов, имеющих право быть мастером, как специализированных узлов, имеющих право быть мастером, которые будут выполнять только роль master, позволяя им сосредоточиться на управлении кластером. Узлы, имеющие право быть мастером, также будут действовать как координирующие узлы, которые перенаправляют запросы от клиентов к другим узлам кластера, но не следует использовать специализированные узлы-мастера для этой цели.

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

Для создания специализированного узла, имеющего право быть мастером, установите:

node.roles: [ master ]

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

Возможно, кажется странным использовать термин «имеющий право быть мастером» для описания узла с правом только голосовать, поскольку такой узел фактически не имеет права стать мастером. Такая терминология — результат исторических причин: узлы, имеющие право быть мастером, — это узлы, которые участвуют в выборах и выполняют определенные задачи во время публикации состояния кластера, а узлы с правом только голосовать выполняют те же задачи, даже если они никогда не могут стать избранным мастером.

Для настройки узла, имеющего право быть мастером, как узла с правом только голосовать, включите master и voting_only в список ролей. Например, для создания узла данных с правом только голосовать:

node.roles: [ data, master, voting_only ]

Для кластеров с высокой доступностью (HA) требуется как минимум три узла, имеющих право быть мастером, причём как минимум два из них не должны быть узлами с правом только голосовать. Такой кластер сможет выбрать узел-мастер даже в случае отказа одного из узлов.

Узлы с правом только голосовать также могут выполнять и другие роли в вашем кластере. Например, узел может быть одновременно узлом данных и узлом с правом только голосовать. Специализированный узел с правом только голосовать — это узел с правом только голосовать, который не выполняет других ролей в кластере. Для создания специализированного узла с правом только голосовать, установите:

node.roles: [ master, voting_only ]

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

Общие узлы данных включаются во все уровни контента.

Для создания выделенного общего узла данных установите:

node.roles: [ data ]

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

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

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

Для создания выделенного узла контента установите:

node.roles: [ data_content ]

Узлы горячих данных являются частью уровня горячих данных. Уровень горячих данных — это входная точка Elasticsearch для данных временных рядов и хранит ваши самые последние и наиболее часто запрашиваемые данные временных рядов. Узлы на уровне горячих данных должны быть быстрыми как для чтения, так и для записи, что требует больше ресурсов аппаратного обеспечения и более быстрого хранения (SSD). Для отказоустойчивости индексы на уровне горячих данных должны быть настроены на использование одного или нескольких реплик.

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

Для создания выделенного узла горячих данных установите:

node.roles: [ data_hot ]

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

Для создания выделенного узла теплых данных установите:

node.roles: [ data_warm ]

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

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

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

Для создания выделенного узла холодных данных установите:

node.roles: [ data_cold ]

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

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

Для создания выделенного узла замороженных данных установите:

node.roles: [ data_frozen ]