Обращения к неактивным узлам клстера

Добрый день,

Настроен кластер из двух узлов middle tier. Один из них временно отключен.
Web tier часто неуспешно пытается к нему обратиться. В примере ниже - повторное обращение к неактивному узлу через 8 секунд.

11:42:22.867 INFO  c.h.c.c.s.r.ClusteredHttpInvokerRequestExecutor- Invocation of http://vlt-app02:8080/quantum-core/remoting/cuba_TrustedClientService failed: java.net.ConnectException: Connection refused (Connection refused)
11:42:22.868 INFO  c.h.c.c.s.r.ClusteredHttpInvokerRequestExecutor- Trying to invoke the next available URL: http://vlt-app01:8080/quantum-core/remoting/cuba_TrustedClientService
11:42:22.876 INFO  c.h.c.c.s.r.ClusteredHttpInvokerRequestExecutor- Invocation of http://vlt-app02:8080/quantum-core/remoting/cuba_UserSessionService failed: java.net.ConnectException: Connection refused (Connection refused)
11:42:22.876 INFO  c.h.c.c.s.r.ClusteredHttpInvokerRequestExecutor- Trying to invoke the next available URL: http://vlt-app01:8080/quantum-core/remoting/cuba_UserSessionService
11:42:30.160 INFO  c.h.c.c.s.r.ClusteredHttpInvokerRequestExecutor- Invocation of http://vlt-app02:8080/quantum-core/remoting/cuba_TrustedClientService failed: java.net.ConnectException: Connection refused (Connection refused)
11:42:30.160 INFO  c.h.c.c.s.r.ClusteredHttpInvokerRequestExecutor- Trying to invoke the next available URL: http://vlt-app01:8080/quantum-core/remoting/cuba_TrustedClientService

Вопросы: 1) предусмотренна ли какая-то фоновая проверка доступности (health check) улов middleware tier с с web tier с вводом/выводом улов с/из доступных?
2) можно ли как-то настроить, что после неудачного подключения (или Х неудачных подключений) не предпринимать повторные попытки использовать этот узел в течение какого-то времени.

Добрый день,
Нет, средствами CUBA такой возможности нет.

Я скопирую описание текущего механизма из тикета, который сейчас недоступен публично:

Middleware cluster load balancing and customization
Description

  • Load-balancing is encapsulated in the ServerSelector interface
    • Default implementation - StaticServerSelector which must be provided with a static list list of middleware servers
    • For the default cuba_ServerSelector bean which is used in service proxy creators the list is obtained from the cuba.connectionUrlList app property
  • StaticServerSelector (subclass of StickySessionServerSelector) features
    • Sticky sessions - the server is determined on the first remote connection for a user session, and it is fixed for the whole session life time
      • Requests without session are balanced
      • Requests with anonymous session are not sticky
    • Each new session receives a different server for the first try
      • Random server by default - defined by the RandomServerSorter class
      • Another server sorting strategy can be used if the cuba_ServerSorter bean is redefined in the project. For example, NoopServerSorter yields the legacy behaviour (one client - one preferred server).
    • If the server connection fails, another server is selected for connection for all user sessions on this client
    • On each request, the client tries to connect first to previously available servers, next to previously failed
    • If all servers fail for a request, an exception is thrown

Между web-слоем и core-слоем можно поставить балансировщик nginx с round-robin балансированием. Тогда и фоновые проверки доступности будут, и нагрузка будет распределяться абсолютно равномерно. Но в этом случае тоже могут быть сложности, обсуждалось здесь: Проблемы масштабирования приложения

Александр, спасибо.

Попробую предложенный вариант.

В вашем roadmap’е есть что-нибудь на эту тему или вариант с внешним load-balancer’ом останется на продолжительное время?

Нет. Нет смысла тягаться с Nginx, реализовывать то же самое второй раз.

Александр, еще раз спасибо. :slight_smile:

Обратите внимание на этот аддон: https://www.cuba-platform.com/marketplace/zookeeper/
Он позволяет кластеру собирать себя динамически через ZooKeeper.