- Текущая конфигурация:
- 16 запущенных модулей, кластер на основе JBoss TCP с обнаружением Google ping.Контейнер развертывается как набор с сохранением состояния в кластере Kubernetes.
- Исходный кластер без нагрузки работает, как и ожидалось, без каких-либо проблем, но при увеличении нагрузки наблюдается следующее поведение:
- Некоторые из модулей становятся недоступными во время управления начальной загрузкой, и в результате этого они автоматически перезапускаются.
- После перезапуска этих модулей они запускаются с новыми IP-адресами, ноте же хосты остаются в файле обнаружения JBoss со старыми IP-адресами.В результате этот файл обнаружения содержит хосты с несколькими IP-адресами.
aaa-ops-stage-0 b6418a02-4db3-0397-ba2b-5a4a3e274560 10.20.0.17:7800 F
aaa-ops-stage-1 d57dc7b7-997f-236e-eb9f-a1604ddafc8f 10.20.0.10:7800 F
aaa-ops-stage-1 63a54371-111e-f9e9-3de5-65c6f6ff9dcd 10.20.0.16:7800 F
aaa-ops-stage-1 2dfeb3d8-6cc4-03e0-719e-b4dbb8a63815 10.20.1.13:7800 T
aaa-ops-stage-0 8053ed47-ba1b-5bb1-fcd2-a2cffb154703 10.20.0.9:7800 F
aaa-ops-stage-0 7068cd6c-ff83-dd5d-1610-e5c03f089605 10.20.0.9:7800 F
aaa-ops-stage-0 6230152a-1bc7-30ed-0073-816224bcdc26 10.20.0.14:7800 F
- Когда это происходит и модуль перезапускается, загрузка этого модуля происходит очень медленно, поскольку он пытается отправить сообщение кластера всем записям из файла обнаружения выше.,Поскольку у aaa-ops-stage-0 есть новый и только один IP, у всех остальных aaa-ops-stage-0 просто время ожидания.Если перезапусков много для pod 0, у нас есть еще записи в файле обнаружения.Это также увеличивает время загрузки, как правило, каждый раз, когда модуль перезапускается, потому что он появляется с новым IP-адресом, а время ожидания становится еще больше.
- В конфигурации модуля реализованы датчики готовности, которые используются для изменения статуса вновь запущенногоpods, и благодаря этому балансировщик нагрузки знает, когда модуль готов к приему запросов.К сожалению, с большим количеством тайм-аутов, описанных выше, модуль никогда не загружается полностью, потому что датчик готовности перезапускает модуль после 60 секунд отсутствия.В результате, в конце концов, все модули застряли в цикле перезапуска, и служба полностью остановилась.
Я считаю, что если у нас есть возможность использовать липкие IP-адреса и когда модуль запускается с 10.20.0.17, он остается сэтот IP во время перезапусков.Делая это, мы избежим поведения, описанного выше, и не будет никаких таймаутов.Никакие тайм-ауты не уменьшат перезапуски, которые полностью срабатывают с датчиков готовности, и служба будет работать и работать без учета нагрузки, которую мы производим.
Вопрос в том, есть ли возможность использовать статические или липкие IP-адреса для запущенных модулей, и возможно ли, чтобы эти IP-адреса сохранялись при перезапуске?Любые другие предложения приветствуются!