Проверка начальной загрузки

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

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

Существуют некоторые проверки начальной загрузки, которые всегда выполняются, чтобы предотвратить запуск Elasticsearch с несовместимыми настройками. Эти проверки документированы индивидуально.

По умолчанию Elasticsearch привязывается к адресам обратной петли для HTTP и транспортной (внутренней) коммуникации. Это подходит для загрузки и работы с Elasticsearch, а также для повседневной разработки, но бесполезно для производственных систем. Для присоединения к кластеру узел Elasticsearch должен быть доступен через транспортную коммуникацию. Чтобы присоединиться к кластеру по адресу, не являющемуся адресом обратной петли, узел должен привязать транспорт к адресу, не являющемуся адресом обратной петли, и не использовать обнаружение одного узла. Таким образом, мы считаем, что узел Elasticsearch работает в режиме разработки, если он не может сформировать кластер с другим компьютером по адресу, не являющемуся адресом обратной петли, и в противном случае он работает в режиме производства, если он может присоединиться к кластеру по адресам, не являющимся адресами обратной петли.

Обратите внимание, что HTTP и транспорт можно настроить независимо с помощью http.host и transport.host; это может быть полезно для настройки одного узла, доступного по HTTP для целей тестирования, без активации режима производства.

Мы понимаем, что некоторым пользователям необходимо привязать транспорт к внешнему интерфейсу для тестирования использования транспортного клиента. Для этой ситуации мы предоставляем тип обнаружения single-node (настройте его, установив discovery.type на single-node); в этой ситуации узел выберет себя мастером и не присоединится к кластеру с любым другим узлом.

Если вы запускаете один узел в режиме производства, вы можете обойти проверки начальной загрузки (либо не привязывая транспорт к внешнему интерфейсу, либо привязав транспорт к внешнему интерфейсу и установив тип обнаружения на single-node). В этой ситуации вы можете принудительно выполнить проверки начальной загрузки, установив системную переменную es.enforce.bootstrap.checks на true в параметрах JVM. Мы настоятельно рекомендуем это сделать, если вы находитесь в этой конкретной ситуации. Эта системная переменная может использоваться для принудительного выполнения проверок начальной загрузки независимо от конфигурации узла.