Коллеги, добрый день!
У нас кластер из 10-дата нод, 3 мастера.
Нагрузка порядка 5-30 тыс.записей в секунду. Мы хотим ввести координэйшен-ноду поскольку не хотим более нагружать напрямую дата-ноды пользовательскими запросами. Т.е. запись на LS оставить пока что напрямую на data-ноды, а пользовательские запросы из kibana и grafana увести на coordination node.
Вопрос как нам расчитать какие ресурсы нужно выделить для ноды? Есть ли какие-то best-практики по этому поводу?
Заранее спасибо.
Нагрузка на узел координации будет, в основном, определяться нагрузкой на кибану и графану. То есть, если ими никто пользоваться не будет - то этот узел ничего делать не будет. А если у вас куча графиков и людей, которые эти графики перегружают, то нагрузка будет заметной. Узлы координации выполняют роль распределения запросов по шардам, и последующей обработки результатов. Например, если вам надо сумму какого-то значения рассчитать, то сумма будет сначала рассчитана на каждой шарде, а потом сумма с каждой шарды будет сложена на узле координации. Как видно из этого примера, узел координации, обычно, гораздо менее загружен, чем узлы данных. То есть самая большая нагрузка будет на сеть, потом на ЦПУ (для агрегирования результатов), в какой-то степени на память (для хранения промежуточных результатов). Диск использоваться практически не будет, за исключением сохранения изменений состояния кластера.
Не зная ничего о вашем кластере, я бы начал с вашей типичной машины, которую вы используете для данных (можно без хорошего диска) и посмотрел бы как она работает под максимальной пользовательской нагрузкой. Думаю, что после этого, скорее всего, вы сможете заменить ее на что-нибудь послабее, если все будет работать нормально. Количество памяти, которое потребуется на узле координации определить еще сложнее, так как оно будет определяться количеством и сложностью одновременно запущенных пользовательских запросов.
Игорь, огромное спасибо за быстрый ответ!
Да, у нас очень высокая нагрузка от кибаны и графаны. Я уже писал вам, что нам даже пришлось ограничить максимальное кол-во search.max_buckets с 10000 до 5000 (спасибо вам за этот совет), поскольку некоторые пользовательские запросы на вывод информации просто останавливали на некоторое время кластер загружая все дата-ноды до 90% cpu. Плюс в последнее время фиксировались массовые 429 ошибки. Опять же , спасибо Вам, по вашим рекомендация уменьшили кол-во шардов по некоторым инексам и размер потоков на LS с 14 до 12 используемых ядер. Теперь ошибок нет.
Всё это и подвело нас к тому, что пора вводить coordination ноду.
Но очень не хотелось бы сделать узким звеном ноду координации. Поэтому и есть задача сделать отказоустойчивое решение, которое обеспечит наилучшее быстродействие...
Это нагрузка, в основном, на шардах. Скорее всего большая часть этой нагрузки так и останется на узлах данных.
Игорь, поможет ли в нашем случае тогда нода координации? Т.е.после ввода ноды координации мы ожидаем, что часть нагрузки (в части распределения запросов и аггрегации данных ) будет на ноде координации, что сделает нагрузку более равномерной на дата-ноды, разгрузит дата-ноды и ещё уменьшит возможные 429 ошибки, поскольку не будет использоваться слот под запросы, верно?
координации мы ожидаем, что часть нагрузки
Это все верно. Вопрос только в том, насколько большая эта часть? И на этот вопрос не экспериментально ответить сложно.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.