Можно. Только надо учитывать, что одна нода может использовать столько-же потоков ЦПУ, как и две, так как в ней практически нет ограничений на многопоточность. Единственное, что вы получаете (кроме головной боли с настройкой) - это удвоение хипа. Так что главный вопрос в том, а с хипом ли у вас в данный момент проблемы?
ЦПУ - нода будет использовать столько потоков, сколько ей дадут. Память - предела нет, все что свободно - пойдет под кэш файловой системы и ускорить производительность. Но иметь больше памяти чем размер индекса, наверное, не имеет смысла.
Ограничения в 32ГБ в 7.9 тоже практически нет, это скорее рекомендация в случае с G1. Мы очень сильно оптимизировали использование хипа. Поэтому 32ГБ должно хватать в большинстве случаев (если вы не используете огромный индекс с completions suggester или какие-то другие фичи, которые требуют большое количество хипа). Поэтому если нужно 10ГБ хипа, а вы дадите 40ГБ, то вы не только выкинули 30ГБ, вы еще и замедлили ноду из-за излишнего мусора и несжатых указателей.
Игорь, благодарю! То есть если я имею 3 железных сервера - на каждой более 100 процессоров, и более 200 гб оперативной памяти - но их всего три. Дисков неограниченное количество. Мне нужно индексировать около 20ТБ логов в сутки, и производить по ним постоянно поиск. Мне хватит этих ресурсов? И стоит ли ставить по 2 эластика в роли дата на каждую ноду, или можно обойтись 3, по одному на ноду?
Про канал точно не скажу, но сервера ожидаются топовые, диски NVMe.
Я вообще всегда был сторонником нод 24 CPU 64 MEM - чтобы выделить под хип половину. И таких нод - штук 40.
А как поведет себя эластик если будет держать петабайт логов на каждом сервере, а их всего три? Ведь запросов поиска ожидается очень много. Насколько я знаю, эластик хранит все в оперативной памяти.
Игорь, а вы посоветовали бы на таком мега-сервере отдать все под один Эластик, или нарезать ресурсы для нескольких через докер например, для повышения производительности?
Думаю, порезать было бы лучше для повышения отказоустойчивости (за счет небольшого уменьшения производительности). Проблема тут такая - одна нода может использовать все ресурсы, но для того, чтобы добиться большой пропускной способности при индексации, вам, скорее-всего, придется увеличить количество шард на горячих индексах (потом их надо будет слить для увеличения скорости поиска). Если Вам надо будет кластер перегрузить, то перезагрузка одной ноды будет означать уменьшение возможностей кластера на треть (практически даже больше) и при большом количестве шард, может занимать много времени.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.