Проблемы масштабирования приложения

Коллеги, есть проблемы при масштабировании приложения,

билдим JAR отдельно для веб-клиента, отдельно middleware,
запускаем в кластере k8s с использованием ZooKeeper,

блок middleware скелится без проблем,
а вот со скелингом блока веб-клиента проблемы, когда инстансов веб-клиента больше одного - сразу на странице авторизации получаем ошибку:

“Время неактивности сессии истекло”

ERROR com.haulmont.cuba.web.AppUI - Unable to init ui
java.lang.RuntimeException: Unable to initialize UI Component - calling afterPropertiesSet for class com.haulmont.cuba.web.gui.components.WebLookupField

Caused by: com.haulmont.cuba.security.global.NoUserSessionException: User session not found

В чем может быть причина?
Логи интстансов прикрепляю.
logs-from-app-in-app-7695774dd5-mq7nh.txt (61.4 КБ)
logs-from-app-in-app-7695774dd5-n6q2v.txt (34.0 КБ)
logs-from-app-in-app-7695774dd5-r9245.txt (13.1 КБ)
logs-from-middleware-in-middleware-7b9f7468c8-hvwdg.txt (13.1 КБ)
logs-from-middleware-in-middleware-7b9f7468c8-k9h44.txt (10.3 КБ)
logs-from-middleware-in-middleware-7b9f7468c8-l2nws.txt (10.2 КБ)

Подскажите хотя бы в какую сторону копать?

А как у вас происходит перенаправление пользователя на конкретный веб-сервер?

стандартный алгоритм nginx-ingress - round robin

Добрый день,
Если используете round-robin балансирование между core узлами, то обязательно включите синхронную репликацию юзер-сессий с помощью свойства

cuba.syncNewUserSessionReplication = true

com.haulmont.cuba.core.app.ServerConfig#getSyncNewUserSessionReplication

Также здесь можете посмотреть другие полезные свойства для кластера:

1 симпатия

Спасибо, пробуем. Отпишусь по результатам, данная информация не попадалась раньше.

Еще важно: на входном балансере должны быть настроены sticky sessions. Иначе у вас пользователей будет кидать по серверам на которых нет их HTTP сессии и соответственно нет UI.

1 симпатия

Благодарю, тоже полезный комментарий.
Есть ли доп. параметры, которые необходимо указывать при сборке uberJar для работы в кластере k8s?

кстати, этого параметра нет в документации, было бы не плохо добавить:

cuba.syncNewUserSessionReplication = true

Sticky sessions помогли решить проблемы с веб-клиентом, теперь можно работать с системой на нескольких инстансах веб-клиента и middleware.

Но проблема осталась при работе с rest api. Подскажете куда копать в этом случае?
Я так понимаю проблема обмена сессиями между инстансами блоков middleware…?

Может ли это быть связано с некорректной работой jGourps?
В логах есть такие записи при инициализации инстансов middleware:

20:32:30.411 WARN org.jgroups.stack.Configurator - JGRP000014: GMS.view_bundling has been deprecated: view bundling is enabled by default
20:32:30.488 WARN org.jgroups.protocols.UDP - JGRP000015: the receive buffer of socket MulticastSocket was set to 500,00KB, but the OS only allocated 212,99KB

А какие у вас ошибки падают с rest api?

Ошибки следующего характера:

  • не найдена сессия для пользователя (в больше степени)
  • eofexception
  • и бывают ошибки разрыва сессии (jetty)

Попробуйте использовать свойство cuba.rest.syncTokenReplication=true для REST клиента. Возможно запросы идут к разным нодам и он не находит нужный токен на новой ноде.

Если же не поможет то можно попробовать использовать DB хранение REST токенов: https://doc.cuba-platform.com/restapi-7.2/?_ga=2.29390079.1791662427.1593255691-886111289.1567750563#cuba.rest.storeTokensInDb

Спасибо, будем пробовать.
А где можно найти список всех возможных параметров? По скольку в документации вот уже второй параметр, который здесь указан, которые не отображены в документации…

Лучший способ - это изучать исходный код, зря что-ли платформа с открытым исходным кодом.
Команда CUBA старается всё описывать, но как видите здесь:


больше 100 незакрытых тикетов, на все времени не хватает.

Упомянутые настройки используются довольно редко, т.к. мало кто разворачивает CUBA приложения раздельно по слоям с round-robin.

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

А какая практика чаще используется для развертывания кластера?

Мне кажется, в большинстве случаев собирают single war или single uber jar, тогда балансировщик между web и core не нужен.

Раздельные слои полезны только тогда, когда вы хотите постоянно пользоваться возможностью обновлять core слой - доставлять мелкие изменения и улучшения без изменения модели данных, при этом не перезапуская web-сервера и не беспокоя пользователей.

1 симпатия

Спасибо за ответ!
Нам необходимо обеспечить 3000 rps, поэтому мы задумались о масштабировании, одна машина к сожалению такой нагрузки не выносит, в первую очередь страдает CPU.

В итоге запустили пока single uberJar на несольких подах,
с балансирощиком, использующим sticky sessions
при наличии времени хотим вернуться к проработке сценария разделенных web-client и mw

Благодарю за помощь!