Project

General

Profile

Feature #8973

distribute stateful interactive sessions across a cluster of FWD servers

Added by Greg Shah about 2 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to Database - Feature #4369: implement stateless FWD server clustering Test

History

#1 Updated by Greg Shah about 2 years ago

  • Related to Feature #4369: implement stateless FWD server clustering added

#2 Updated by Greg Shah about 2 years ago

#4369 is about implementing the core clustering support in a FWD server. This will allow horizontal scaling and some level of high availability. But the concept of #4369 is about enabling this for stateless sessions, which are exclusively systems built using appserver, REST, SOAP.

Interactive systems with a 4GL GUI or ChUI are very stateful and have long lasting sessions. This task is to extend the clustering approach of #4369 to stateful interactive sessions.

A key limitation and assumption is that we will not be replicating/synchronizing the session-level state across the cluster for interactive sessions. The intention is for these sessions to be sticky. Once created in a given server of the cluster, the FWD client will remain connected to that same FWD server for the lifetime of the session.

However:

  • New sessions should be able to be created on any of the FWD servers in the cluster.
  • We should implement some (at least simple) form of load balancing at login, such that we create the new session on the least used FWD server.
  • If a FWD server fails, the entire cluster should not fail.

#3 Updated by Galya B about 2 years ago

At present for web gui / chui the interface with the client is the login page. For desktop gui / chui it's a socket connection / rpc, so the load balancer concept is different. I guess this task is to tackle both types?

#4 Updated by Greg Shah about 2 years ago

I guess this task is to tackle both types?

Correct.

#5 Updated by Galya B about 2 years ago

For web clients the login page server tells the client which host / port / alias to use to connect to the session server via the options, so it's fairly easy to change it. The login server will need to poll regularly information about the state of the infrastructure on which the session servers are running. Do we load balance the load balancer, i.e. the web server for the login page? It's still a single point of failure. Do we need a separate build for a lightweight web server for the login page? It's also important to have a mechanism of replicating the session servers, instead of simply starting them manually: docker images +/- config server is the only reliable way. On top of polling the state of the infrastructure, the login server will need to get the allocated resources / empty ports from the session servers. Actually this is for the client part, that is managed by brokers if needs to be distributed.

#6 Updated by Greg Shah about 2 years ago

These are all good points and questions.

  • I don't want to "recreate the wheel" on load balancing unless there is some aspect that can't be reasonably supported using industry standard external load balancers. The internal knowledge/status of long lived sessions (and maybe even the resources they are using) is a possible reason why we might have to do something ourselves.
  • My initial idea was to leave all of the servers with a working login page. This would remove the single point of failure and actually it could be behind standard load balancing, though that wouldn't necessarily solve the requirement we have. I would expect that we would replicate spawning state (like allocated ports) across the cluster so that each login page could effectively decide where the next session should be.

Also available in: Atom PDF