Я наблюдаю странные сбои нашего кластера Apache Ignite. Версия Ignite 2.13.0 работает с «64-битным сервером OpenJDK VM Zulu11.52+13-CA (сборка 11.0.13+8-LTS, смешанный режим)».
Кластер состоит из 3 базовых серверных узлов с включенной сохраняемостью. Раз в неделю каждый из них перезагружается после получения автоматических обновлений операционной системы.
28.3. в 19:03 сервер №2 был перезагружен, пришел бекап и через 10 минут сервис Ignite рухнул с ошибкой после логирования дампа потока:
[19:13:17,302][SEVERE][sys-stripe-5-#6][] JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to find security context for subject with given ID : 74f979dd-342d-4055-bda4-58535b8ab282]]
При этом сервис Ignite на сервере №3 крашился точно так же:
[19:13:17,606][SEVERE][sys-stripe-5-#6][] JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to find security context for subject with given ID : 74f979dd-342d-4055-bda4-58535b8ab282]]
На данный момент один 1 серверный узел Ignite оставался активным.
Через день сервер номер 3 был автоматически перезагружен заданием по обслуживанию, и когда он вернулся, Ignite снова присоединился к кластеру без повторного сбоя.
Logs server 2:
https://pastebin.com/XJK8kPyU
Logs server 3:
https://pastebin.com/YrWvgL1K
Есть идеи, почему Ignite случайно вылетает?
С уважением, Свен
Обновлять:
Эти сбои привели к тому, что оставшийся узел и даже весь кластер после перезапуска отказавших узлов перешли в непригодное для использования состояние. Наше приложение не смогло работать с Ignite, показывая следующий сбой:
Caused by: org.apache.ignite.IgniteException: Failed to execute the cache operation (all partition owners have left the grid, partition data has been lost) [cacheName=datastructures_ATOMIC_PARTITIONED_1@default-ds-group, partition=299, key=GridCacheQueueItemKey [queueId=d6743312681-6ddd800e-39e6-473f-915a-39c576ef32be, queueName=cluster_processing_6-queue, idx=1322]]
Кажется, внутренний кеш был дефектным из-за потерянных разделов, вызванных сбоями узла. Единственный способ, которым мы смогли найти, чтобы кластер и наше приложение снова работали правильно, — это полностью отключить все серверы и клиенты Ignite, а затем перезапустить все. Мне не удалось выполнить сброс потерянных разделов в этом кеше. Можно ли настроить этот системный кеш так, чтобы он имел 2 резервных копии вместо одной? Это может предотвратить ситуацию в случае, если у нас снова произойдет сбой 2 узлов одновременно.
Такое поведение разрушает идею наличия высокодоступного кластера.
Наблюдаемый сбой узлов связан с известной проблемой. В случае включенной защиты существует вероятность того, что серверный узел получит коммуникационное сообщение от присоединяющегося узла, в то время как моментальный снимок топологии еще не был обновлен, что приведет к отказу серверного узла.
Судя по предоставленным логам, в вашем конкретном случае это было связано с присоединением клиентского узла к id=74f979dd-342d-4055-bda4-58535b8ab282
:
[19:13:16,989][SEVERE][sys-stripe-5-#6][] Critical system error detected. Will be handled accordingly to configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to find security context for subject with given ID : 74f979dd-342d-4055-bda4-58535b8ab282]]
...
[19:13:16,995][INFO][disco-event-worker-#62][GridDiscoveryManager] Added new node to topology: TcpDiscoveryNode [id=74f979dd-342d-4055-bda4-58535b8ab282, consistentId=74f979dd-342d-4055-bda4-58535b8ab282, addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 10.105.178.172, 127.0.0.1], sockAddrs=HashSet [b2bimcpapp2.internal.domain/10.105.178.172:0, 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0], discPort=0, order=1265, intOrder=647, lastExchangeTime=1680023596965, loc=false, ver=2.13.0#20220420-sha1:551f6ece, isClient=true]
Спасибо за информацию, как-то сам не нашел эту тему.