Question: Load balancer really not supported?

[jeroenhabets]

Hi @jcrodriguez-dis ,

Sorry, to bother you but while scanning the 3.0 manual the following caught my eye on https://vpl.dis.ulpgc.es/documentation/vpl-jail-system-3.0.0/requirements.html#load-balancer

2.3.3. Load balancer

The architecture of the connections of the execution server seems to not allow to use of a load balancer to access a cluster of execution servers. Notice that the execution server that runs a task receive several requests from the Moodle server and the client machine to manage the task.

Is this still a true limitation? I am running a websocket proxy using nginx at home be it with only one node behind it. nginx blog explicitely states they support websocket load balancing: https://www.nginx.com/blog/websocket-nginx/

NGINX has supported WebSocket since version 1.3 and can act as a reverse proxy and do load balancing of WebSocket applications.

I know I could test it and it might work during my smoke test but perhaps my test would miss a limitation known to you.

Thanks! Jeroen

[jeroenhabets]

Question becoming more pressing due to PR https://github.com/jcrodriguez-dis/vpl-xmlrpc-jail/pull/64 as normally you'd run your Docker container(s) behind a (nginx) reverse proxy/load balancer

[jeroenhabets]

FYI: Our VPL client has built-in support to round-robin a set of VPL servers so not a pressing issue for us.

[jcrodriguez-dis]

Hello @jeroenhabets,

Thank you for your meticulous attention to the VPL documentation, and for raising the pertinent question about load balancing.

While it is true that modern load balancers, like the ones managed by NGINX, offer strong support for WebSocket load balancing, it is crucial to underscore some limitations within the VPL architecture itself. Specifically, the way the VPL execution server handles tasks can make it inherently incompatible with typical load balancing strategies.

For instance, consider a scenario where a student has two active sessions and initiates separate 'run' commands from each session. When the second 'run' is invoked, the first 'run' operation is intended to be terminated. To execute this behavior accurately, the Moodle server must be aware of the exact execution server instance that is processing the initial task in order to send a termination command. Consequently, a load balancer that indiscriminately routes incoming requests to any available server in a cluster would disrupt this delicate workflow.

As you mentioned, your VPL client has built-in support for round-robin selection of VPL servers, it's important to consider that this does not alleviate the need for the Moodle server to have explicit knowledge of the specific execution server handling a task, especially for operations that need to be atomically coupled, like 'run' and 'terminate.'

I hope this clarifies why a conventional load balancing approach may not be suitable for the VPL execution server architecture at this moment. Feel free to contribute further to this discussion if you have additional questions or thoughts.

Best regards, Juan Carlos.

[jeroenhabets]

Hello Juan Carlos,

Thank you for your extensive response!

In the meantime through our round robin VPL client we're good so I don't want to take more of your time.

Still if it is something you'd like to pursuit: You could add a unique cookie per server so that sticky sessions (session persistence) could be configured in load balancers that support them.

But that's more of a feature request for other users. For me I shall now close this as my question has been answered.

Thank you again!

Kind regards, Jeroen Habets