Elasticsearch: Виртуальная машина Java

Вы всегда должны запускать последнюю версию виртуальной машины Java Virtual Machine (JVM), если на сайте Elasticsearch не указано иное. Elasticsearch, и в частности Lucene, является требовательным программным обеспечением.

Создание кластера Elasticsearch из двух нод

Виртуальная машина Java

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

Java 8 предпочтительнее Java 7. Java 6 больше не поддерживается. Можно использовать либо Oracle, либо OpenJDK. Они сопоставимы по производительности и стабильности.

Если ваше приложение написано на Java и вы используете транспортный клиент или клиент узла, убедитесь, что JVM, на которой работает ваше приложение, идентична JVM сервера. В некоторых местах в Elasticsearch используется родная сериализация Java (IP-адреса, исключения и т.д.). К сожалению, известно, что Oracle меняет формат сериализации между небольшими выпусками, что приводит к странным ошибкам. Это случается редко, но лучше всего держать версии JVM одинаковыми между клиентом и сервером.
Пожалуйста, не изменяйте настройки JVM

JVM предоставляет десятки (даже сотни!) настроек, параметров и конфигураций. Они позволяют вам настраивать и регулировать практически все аспекты работы JVM.

Когда попадается ручка, человеческой природе свойственно желание повернуть ее. Мы просим вас подавить это желание и не использовать пользовательские настройки JVM. Elasticsearch - это сложное программное обеспечение, и текущие настройки JVM были настроены в течение многих лет реального использования.

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

Транспортный клиент против узлового клиента

Если вы используете Java, у вас может возникнуть вопрос, когда использовать транспортный клиент, а когда - узловой. Транспортный клиент выступает в качестве коммуникационного уровня между кластером и вашим приложением. Он знает API и может автоматически перебрасывать данные между узлами, анализировать кластер и многое другое. Но он является внешним по отношению к кластеру, подобно клиентам REST.

Клиент узла, с другой стороны, фактически является узлом в кластере (но не хранит данные и не может стать ведущим). Поскольку он является узлом, ему известно все состояние кластера (где находятся все узлы, какие шарды живут в каких узлах и так далее). Это означает, что он может выполнять API с меньшим количеством сетевых переходов.

Для обоих клиентов есть свои сценарии использования:

  • Транспортный клиент идеален, если вы хотите отделить свое приложение от кластера. Например, если ваше приложение быстро создает и уничтожает соединения с кластером, транспортный клиент намного "легче", чем узловой клиент, поскольку он не является частью кластера.
  • Аналогично, если вам нужно создать тысячи соединений, вы не захотите, чтобы тысячи узловых клиентов присоединялись к кластеру. TC будет лучшим выбором.
  • С другой стороны, если вам нужно только несколько долгоживущих, постоянных объектов подключения к кластеру, узловой клиент может быть немного более эффективным, поскольку он знает схему кластера. Но он связывает ваше приложение с кластером, поэтому могут возникнуть проблемы с точки зрения брандмауэра.

Управление конфигурацией

Если вы уже используете управление конфигурацией (Puppet, Chef, Ansible), можете пропустить этот совет.

Если вы еще не используете инструменты управления конфигурацией, то вам стоит это сделать! Управление несколькими серверами с помощью parallel-ssh может работать сейчас, но по мере роста кластера это превратится в кошмар. Практически невозможно вручную отредактировать 30 конфигурационных файлов, не допустив при этом ошибки.

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

Понравилась статья? Поделиться с друзьями:
Добавить комментарий