Устранение неполадок нестабильного кластера

Обычно узел покидает кластер только при преднамеренной остановке. Если узел неожиданно покидает кластер, важно разобраться в причине. Кластер, в котором узлы неожиданно покидают его, является нестабильным и может создавать различные проблемы. Например:

Чтобы устранить неполадки в таком состоянии, сначала убедитесь, что кластер имеет стабильного мастера. Затем сосредоточьтесь на узлах, неожиданно покидающих кластер, прежде чем рассматривать другие проблемы. Невозможно решить другие проблемы, пока кластер не будет иметь стабильного узла-мастера и стабильного членства узлов.

Диагностика и статистика обычно не приносят пользы в нестабильном кластере. Эти инструменты предоставляют только представление о состоянии кластера в конкретный момент времени. Вместо этого просмотрите логи кластера, чтобы увидеть закономерности поведения во времени. Особое внимание уделите логам избранного мастера. Когда узел покидает кластер, логи избранного мастера содержат сообщение, подобное этому (с добавлением переносов строк для удобства чтения):

[2022-03-21T11:02:35,513][INFO ][o.e.c.c.NodeLeftExecutor] [instance-0000000000]
    node-left: [{instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{aNlyORLASam1ammv2DzYXA}{172.27.47.21}{172.27.47.21:19054}{m}]
    with reason [disconnected]

Это сообщение говорит о том, что NodeLeftExecutor на избранном мастере (instance-0000000000) обработало задачу node-left, идентифицировав узел, который был удалён, и причину его удаления. Когда узел снова присоединяется к кластеру, логи избранного мастера будут содержать сообщение, подобное этому (с добавлением переносов строк для удобства чтения):

[2022-03-21T11:02:59,892][INFO ][o.e.c.c.NodeJoinExecutor] [instance-0000000000]
    node-join: [{instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{UNw_RuazQCSBskWZV8ID_w}{172.27.47.21}{172.27.47.21:19054}{m}]
    with reason [joining after restart, removed [24s] ago with reason [disconnected]]

Это сообщение говорит о том, что NodeJoinExecutor на избранном мастере (instance-0000000000) обработало задачу node-join, идентифицировав узел, который был добавлен в кластер, и причину задачи.

Другие узлы могут регистрировать подобные сообщения, но сообщать меньше деталей:

[2020-01-29T11:02:36,985][INFO ][o.e.c.s.ClusterApplierService]
    [instance-0000000001] removed {
        {instance-0000000004}{bfcMDTiDRkietFb9v_di7w}{aNlyORLASam1ammv2DzYXA}{172.27.47.21}{172.27.47.21:19054}{m}
        {tiebreaker-0000000003}{UNw_RuazQCSBskWZV8ID_w}{bltyVOQ-RNu20OQfTHSLtA}{172.27.161.154}{172.27.161.154:19251}{mv}
    }, term: 14, version: 1653415, reason: Publication{term=14, version=1653415}

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

Узлы также будут регистрировать сообщение, содержащее master node changed, всякий раз, когда они начинают или прекращают следовать избранному мастеру. Вы можете использовать эти сообщения, чтобы определить представление каждого узла о состоянии мастера во времени.

Если узел перезапускается, он покинет кластер, а затем снова присоединится к нему. При повторном присоединении NodeJoinExecutor будет регистрировать обработку задачи node-join, указывая, что узел joining after restart. Если узел неожиданно перезапускается, обратитесь к логам узла, чтобы узнать причину его выключения.

API Состояния на затронутом узле также предоставит некоторую полезную информацию о ситуации.

Если узел не перезапускался, то следует более тщательно изучить причину его ухода. Для каждой причины существуют различные этапы устранения неполадок, описанные ниже. Возможны три причины:

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

Elasticsearch разработан для работы в относительно надёжной сети. Он открывает ряд TCP-соединений между узлами и ожидает, что эти соединения останутся открытыми бессрочно. Если соединение закрывается, Elasticsearch попытается переподключиться, поэтому случайное прерывание может привести к сбоям некоторых операций, но в целом должно оказывать ограниченное влияние на кластер. В противоположность этому, неоднократное разрыв соединений серьёзно повлияет на его работу.

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

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

logger.org.elasticsearch.transport.TcpTransport: DEBUG
logger.org.elasticsearch.xpack.core.security.transport.netty4.SecurityNetty4Transport: DEBUG

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

Elasticsearch требует, чтобы каждый узел обрабатывал обновления состояния кластера достаточно быстро. Если узел тратит слишком много времени на обработку обновления состояния кластера, это может нанести вред кластеру. Мастер удалит такие узлы с причиной lagging. Справочная информация о параметрах, контролирующих этот механизм, содержится в Настройках обнаружения и формирования кластера.

Запаздывание обычно вызвано проблемами производительности на удалённом узле. Однако узел также может запаздывать из-за серьёзных сетевых задержек. Чтобы исключить сетевые задержки, убедитесь, что net.ipv4.tcp_retries2 настроен правильно. Сообщения логов, содержащие warn threshold, могут предоставить дополнительную информацию о первопричине.

Если вы опытный пользователь, вы можете получить более подробную информацию о том, чем занимался узел во время удаления, настроив следующий логгер:

logger.org.elasticsearch.cluster.coordination.LagDetector: DEBUG

При включённом этом логгере Elasticsearch попытается выполнить API узлов горячие потоки на неисправном узле и сообщит результаты в логах избранного мастера. Результаты сжаты, закодированы и разделены на блоки для предотвращения обрезки:

[DEBUG][o.e.c.c.LagDetector      ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] [part 1]: H4sIAAAAAAAA/x...
[DEBUG][o.e.c.c.LagDetector      ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] [part 2]: p7x3w1hmOQVtuV...
[DEBUG][o.e.c.c.LagDetector      ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] [part 3]: v7uTboMGDbyOy+...
[DEBUG][o.e.c.c.LagDetector      ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] [part 4]: 4tse0RnPnLeDNN...
[DEBUG][o.e.c.c.LagDetector      ] [master] hot threads from node [{node}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] lagging at version [183619] despite commit of cluster state version [183620] (gzip compressed, base64-encoded, and split into 4 parts on preceding log lines)

Для восстановления вывода выполните декодирование данных в base64 и их разархивирование с помощью gzip. Например, в системах Unix-подобных системах:

cat lagdetector.log | sed -e 's/.*://' | base64 --decode | gzip --decompress

Узлы иногда покидают кластер с причиной follower check retry count exceeded при выключении, но если они присоединяются к кластеру без перезапуска, значит, есть другая проблема.

Elasticsearch требует, чтобы каждый узел успешно и достаточно быстро реагировал на сетевые сообщения. Если узел отклоняет запросы или вообще не отвечает, это может нанести вред кластеру. Если достаточно проверок завершатся неудачей, мастер удалит узел с причиной follower check retry count exceeded и укажет в сообщении node-left, сколько последовательных неудачных проверок завершилось ошибкой и сколько из них истекло. Справочная информация о параметрах, контролирующих этот механизм, содержится в Настройках обнаружения и формирования кластера.

Задержки и ошибки могут быть вызваны сетевыми задержками или проблемами производительности на затронутых узлах. Убедитесь, что net.ipv4.tcp_retries2 настроен правильно, чтобы исключить сетевые задержки как возможную причину такой нестабильности. Сообщения логов, содержащие warn threshold, могут дать дополнительные подсказки о причинах нестабильности.

Если последняя проверка завершилась с исключением, то исключение сообщается, и, как правило, указывает на проблему, которую необходимо устранить. Если какие-либо проверки истекли, уточните проблему следующим образом.

По умолчанию проверки фолловеров будут приостановлены через 30 секунд, поэтому, если отключения узлов непредсказуемы, собирайте дампы стека каждые 15 секунд, чтобы убедиться, что хотя бы один дамп стека был получен в нужное время.

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

Чтобы получить больше информации о причинах медленного завершения фрагментов, настройте следующий логгер:

logger.org.elasticsearch.env.NodeEnvironment: DEBUG

При включении этого логгера Elasticsearch будет пытаться запустить API горячих потоков узлов всякий раз, когда он столкнется с ShardLockObtainFailedException. Результаты сжимаются, кодируются и разбиваются на фрагменты для предотвращения усечения:

[DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] [part 1]: H4sIAAAAAAAA/x...
[DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] [part 2]: p7x3w1hmOQVtuV...
[DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] [part 3]: v7uTboMGDbyOy+...
[DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] [part 4]: 4tse0RnPnLeDNN...
[DEBUG][o.e.e.NodeEnvironment    ] [master] hot threads while failing to obtain shard lock for [index][0] (gzip compressed, base64-encoded, and split into 4 parts on preceding log lines)

Для восстановления вывода выполните base64-декодирование данных и распакуйте их с помощью gzip. Например, в системах Unix-подобного типа:

cat shardlock.log | sed -e 's/.*://' | base64 --decode | gzip --decompress

Elasticsearch предназначен для работы в достаточно надежной сети. Он открывает множество TCP-соединений между узлами и ожидает, что эти соединения останутся открытыми вечно. Если соединение закрывается, Elasticsearch попытается повторно подключиться, поэтому случайное прерывание может привести к сбоям некоторых операций в процессе, но в противном случае окажет ограниченное влияние на кластер. В отличие от этого, неоднократные разрывы соединений серьезно повлияют на его работу.

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

[INFO ][o.e.t.ClusterConnectionManager] [node-1] transport connection to [{node-2}{g3cCUaMDQJmQ2ZLtjr-3dg}{10.0.0.1:9300}] closed by remote

Аналогично, после полного установления входящего соединения узел никогда не закрывает его спонтанно, если только узел не завершает работу.

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

logger.org.elasticsearch.transport.TcpTransport: DEBUG
logger.org.elasticsearch.xpack.core.security.transport.netty4.SecurityNetty4Transport: DEBUG

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