Elasticsearch поставляется с очень хорошими настройками по умолчанию, особенно когда речь идет о настройках и опциях, связанных с производительностью.
Если есть сомнения, просто оставьте настройки в покое!!
Мы были свидетелями того, как бесчисленные десятки кластеров были разрушены из-за неправильных настроек, потому что администратор думал, что он может изменить настройки и получить 100-кратное улучшение.
Другие базы данных могут потребовать настройки, но Elasticsearch, по большому счету, нет. Если вы столкнулись с проблемами производительности, решением обычно является улучшение схемы расположения данных или увеличение количества узлов. В Elasticsearch очень мало "волшебных ручек".
Тем не менее, есть некоторые логистические конфигурации, которые следует изменить для производства. Эти изменения необходимы либо для того, чтобы облегчить вам жизнь, либо потому, что нет возможности установить хорошее значение по умолчанию (поскольку оно зависит от схемы кластера).
Имя кластера
Elasticseach по умолчанию запускает кластер с именем elasticsearch. Разумно переименовать ваш кластер во что-то другое, просто чтобы предотвратить несчастные случаи, когда чей-то ноутбук присоединяется к кластеру. Простое изменение на elasticsearch_production может спасти от душевной боли.
Это можно изменить в файле elasticsearch.yml:
| 1 | cluster.name: elasticsearch_production |
Аналогичным образом целесообразно изменить имена узлов. Как вы, вероятно, уже заметили, при запуске Elasticsearch присваивает узлам случайное имя супергероя Marvel. Это мило при разработке, но не так мило, когда на часах 3 часа ночи, и вы пытаетесь вспомнить, на какой физической машине был Tagak the Leopard Lord.
Более того, поскольку эти имена генерируются при запуске, каждый раз, когда вы перезапускаете узел, он получает новое имя. Это может внести путаницу в журналы, поскольку имена всех узлов постоянно меняются.
Как бы это ни было скучно, мы рекомендуем вам дать каждому узлу имя, которое имеет для вас смысл - простое, описательное имя. Это также настраивается в файле elasticsearch.yml:
| 1 | node.name: elasticsearch_005_data |
Пути
По умолчанию Elasticsearch помещает подключаемые модули, журналы и - что самое важное - ваши данные в каталог установки. Это может привести к несчастным случаям, когда каталог установки случайно перезаписывается новой установкой Elasticsearch. Если вы не будете осторожны, вы можете стереть все свои данные.
Лучше всего перенести каталог данных за пределы места установки. При желании вы можете также переместить каталоги подключаемых модулей и журналов.
Это можно изменить следующим образом:
| 1 2 3 4 5 6 7 | path.data: /path/to/data1,/path/to/data2 # Path to log files: path.logs: /path/to/logs # Path to where plugins are installed: path.plugins: /path/to/plugins |
Обратите внимание, что вы можете указать более одного каталога для данных, используя списки, разделенные запятыми.
Данные могут быть сохранены в нескольких каталогах, и если каждый каталог смонтирован на отдельном жестком диске, это простой и эффективный способ создания программного RAID 0. Elasticsearch будет автоматически распределять данные между различными каталогами, повышая производительность.
Безопасность и производительность нескольких путей передачи данных
Как и в любой конфигурации RAID 0, на жестких дисках сохраняется только одна копия ваших данных. Если вы потеряете жесткий диск, вы гарантированно потеряете часть данных на этой машине. Если повезет, у вас есть копии в других местах кластера, которые могут восстановить данные, и/или недавняя резервная копия.
Elasticsearch пытается минимизировать степень потери данных путем чередования целых шардов на диске. Это означает, что шард 0 будет полностью размещен на одном диске. Elasticsearch не будет разбивать шард на несколько дисков, поскольку потеря одного диска приведет к повреждению всего шарда.
Это имеет последствия для производительности: если вы добавляете несколько дисков для повышения производительности одного индекса, это вряд ли поможет, поскольку на большинстве узлов будет только один шард, а значит, один активный диск. Несколько путей данных помогают только в том случае, если на одном узле расположено много индексов/шардов.
Множественные пути данных - это хорошая удобная функция, но в конечном итоге Elasticsearch - это не программный RAID. Если вам нужна более сложная конфигурация, надежность и гибкость, мы рекомендуем вам использовать настоящие программные пакеты RAID вместо функции нескольких путей данных.
Минимальное количество мастер нод
Параметр minimum_master_nodes чрезвычайно важен для стабильности вашего кластера. Этот параметр помогает предотвратить "split brains" - существование двух мастеров в одном кластере.
При наличии "split brains" кластер подвергается опасности потери данных. Поскольку мастер считается "верховным правителем" кластера, он решает, когда можно создавать новые индексы, как перемещать осколки и так далее. Если у вас два мастера, целостность данных становится опасной, поскольку у вас есть два узла, которые считают себя главными.
Этот параметр указывает Elasticsearch не выбирать мастера, пока не будет достаточно узлов, имеющих право быть мастером. Только тогда выборы состоятся.
Этот параметр всегда должен быть настроен на кворум (большинство) узлов, имеющих право быть ведущими. Кворум равен (количество узлов, имеющих право на участие в выборах мастера / 2) + 1. Вот несколько примеров:
Если у вас десять обычных узлов (могут хранить данные, могут стать ведущими), кворум равен 6.
Если у вас три выделенных мастер-узла и сто узлов данных, кворум равен 2, так как вам нужно считать только те узлы, которые имеют право стать мастером.
Если у вас есть два обычных узла, вы окажетесь в затруднительном положении. Кворум будет равен 2, но это означает, что потеря одного узла сделает ваш кластер неработоспособным. Значение 1 позволит вашему кластеру функционировать, но не защитит от раздвоения мозга. В подобных ситуациях лучше всего иметь как минимум три узла.
Этот параметр можно настроить в файле elasticsearch.yml:
| 1 | discovery.zen.minimum_master_nodes: 2 |
Но поскольку кластеры Elasticsearch являются динамическими, вы можете легко добавлять или удалять узлы, что приведет к изменению кворума. Было бы крайне неприятно, если бы вам пришлось проталкивать новые конфигурации на каждый узел и перезапускать весь кластер только для того, чтобы изменить настройки.
По этой причине minimum_master_nodes (и другие параметры) можно настроить с помощью динамического вызова API. Вы можете изменить настройку, пока ваш кластер находится в режиме онлайн:
| 1 2 3 4 5 6 | PUT /_cluster/settings { "persistent" : { "discovery.zen.minimum_master_nodes" : 2 } } |
Это станет постоянной настройкой, которая будет иметь приоритет над любой статической конфигурацией. Вы должны изменять эту настройку всякий раз, когда добавляете или удаляете узлы с правами мастера.
Настройки восстановления
Несколько настроек влияют на поведение восстановления шардов при перезапуске кластера. Сначала нужно понять, что произойдет, если ничего не настраивать.
Представьте, что у вас десять узлов, и каждый узел содержит один шард - либо основной, либо реплику - в индексе 5 основных / 1 реплика. Вы отключаете весь кластер от сети для технического обслуживания (например, для установки новых дисков). При перезапуске кластера так получилось, что пять узлов подключились к сети раньше, чем остальные пять.
Возможно, коммутатор на остальных пяти узлах работает нестабильно, и они не сразу получили команду перезапуска. Какова бы ни была причина, у вас есть пять узлов в сети. Эти пять узлов будут общаться друг с другом, выбирать мастера и формировать кластер. Они замечают, что данные больше не распределены равномерно, поскольку в кластере отсутствуют пять узлов, и немедленно начинают реплицировать новые осколки между собой.
Наконец, остальные пять узлов включаются и присоединяются к кластеру. Эти узлы видят, что их данные реплицируются на другие узлы, поэтому они удаляют свои локальные данные (поскольку они теперь избыточны и могут быть устаревшими). Затем кластер начинает еще больше перебалансироваться, поскольку размер кластера только что увеличился с пяти до десяти.
Во время всего этого процесса узлы перегружают диск и сеть, перемещая данные без всякой причины. Для больших кластеров с терабайтами данных эта бесполезная перетасовка данных может занять очень много времени. Если бы все узлы просто ждали, пока кластер подключится к сети, все данные были бы локальными и ничего не нужно было бы перемещать.
Теперь, когда мы знаем о проблеме, мы можем настроить несколько параметров для ее решения. Во-первых, нам нужно задать Elasticsearch жесткое ограничение:
| 1 | gateway.recover_after_nodes: 8 |
Это не позволит Elasticsearch начать восстановление, пока не будет присутствовать по крайней мере восемь узлов (данные или мастер). Значение этого параметра - вопрос личных предпочтений: сколько узлов вы хотите иметь, прежде чем считать кластер работоспособным? В данном случае мы установим значение 8, что означает, что кластер будет неработоспособен, если в нем не будет по крайней мере восьми узлов.
Затем мы указываем Elasticsearch, сколько узлов должно быть в кластере, и как долго мы хотим ждать, пока все эти узлы появятся:
| 1 2 | gateway.expected_nodes: 10 gateway.recover_after_time: 5m |
Это означает, что Elasticsearch будет делать следующее:
- Подождать, пока не появятся восемь узлов
- Начнет восстановление через 5 минут или после того, как к кластеру присоединятся десять узлов, в зависимости от того, что наступит раньше.
Эти три настройки позволяют избежать чрезмерной замены шардов, которая может произойти при перезапуске кластера. Это может буквально заставить восстановление занимать секунды, а не часы.
Эти параметры могут быть установлены только в файле config/elasticsearch.yml или в командной строке (они не обновляются динамически) и актуальны только во время полного перезапуска кластера.
Выбирайте одноадресную рассылку многоадресной
Elasticsearch настроен на использование одноадресного обнаружения из коробки, чтобы предотвратить случайное присоединение узлов к кластеру. Только узлы, работающие на одной машине, будут автоматически формировать кластер.
Хотя многоадресная рассылка все еще предоставляется в качестве плагина, ее никогда не следует использовать в производственной среде. Последнее, чего вы хотите, это чтобы узлы случайно присоединились к вашей производственной сети, просто потому что они получили ошибочный многоадресный пинг. В многоадресной рассылке как таковой нет ничего плохого. Просто многоадресная рассылка приводит к глупым проблемам и может быть более хрупкой (например, сетевой инженер возится с сетью, не предупредив вас, и вдруг узлы не могут найти друг друга).
Чтобы использовать одноадресную рассылку, вы предоставляете Elasticsearch список узлов, с которыми он должен попытаться связаться. Когда узел связывается с членом одноадресного списка, он получает полное состояние кластера, в котором перечислены все узлы в кластере. Затем он связывается с ведущим узлом и присоединяется к кластеру.
Это означает, что ваш одноадресный список не обязательно должен включать все узлы в кластере. В нем просто должно быть достаточно узлов, чтобы новый узел мог найти того, с кем можно поговорить. Если вы используете выделенные мастера, просто перечислите три выделенных мастера.
Этот параметр настраивается в файле elasticsearch.yml:
| 1 | discovery.zen.ping.unicast.hosts: ["host1", "host2:port","host3"]. |
