это зависит от сценария.для случая регистрации вы описываете вариант b, мне кажется более гибким.позвольте мне объяснить мое мнение:
, как вы находитесь в сценарии ведения журнала, затем реализуйте горячую / теплую архитектуру .Вы будете в основном писать и читать последние индексы.в некоторых случаях вы хотите получить доступ к более старым данным и, возможно, захотите уменьшить старые и закрыть даже более старые индексы.
настроить по крайней мере 3 главных подходящих узла, чтобы предотвратить проблемы со слюной.сконфигурируйте те же узлы, что и координирующие узлы (11 узлов слева)
установите 2 узла загрузки для перемещения рабочей нагрузки на выделенные узлы (осталось 9 узлов)
установить 3 горячих узла данных для хранения самых последних индексов (осталось 6 узлов)
установить 6 горячих узлов данных для хранения старых, сокращенных и закрытых индексов.(Осталось 0 узлов)
предыдущая установка является лишь примером.номера узлов / роли должны быть изменены, если
, если вам нужно больше устойчивости.затем добавьте больше главных узлов, увеличьте количество реплик для узлов индекса.это также уменьшит общую емкость.
чем больше старых данных вам нужно иметь для поиска или которые хранятся в уже закрытых индексах, тем более теплые узлы вам понадобятся.затем перебалансируйте количество горячих / теплых узлов в соответствии с вашими потребностями.если вы можете отбросить старые данные раньше, увеличьте количество горячих узлов.
если у вас есть лицензия xpack, рассмотрите возможность установки узлов ml / alertting.добавьте эти роли в главные узлы или уменьшите количество узлов данных в пользу ml / alerttig.
вам нужны кибана / logstash?в зависимости от рабочей нагрузки подготовьте исключительно один / два узла.
при условии, что в обоих вариантах есть одинаковые материнские платы, у вас больше возможностей для быстрого масштабирования 14 блоков, просто добавив больше оперативной памяти /процессор / хранения.3 максимальных узла уже соответствуют спецификациям, вам нужно будет установить новые блоки и присоединить их к кластеру, чтобы увеличить их.но это также дает вам, возможно, более свежее оборудование в вашей стойке с течением времени.
, пожалуйста, также посмотрите на это: https://www.elastic.co/pdf/architecture-best-practices.pdf
, если вам нужна некоторая предыстория по конфигурации шардинга, см. ElasticSearch - Как шардинг влияет на производительность индексации?
Кстати: Томас прав в своем комментарии о размере кучи.пожалуйста, посмотрите на это, если вы хотите знать фон: https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html