Open mguidon opened 1 year ago
Done:
Before on prod (05/31/2023) - all instances of webserver are loaded the same because they are coupled through logs/progress/db handling:
After on master (05/31/2023) - each instance is less coupled, still waiting for the ongoing PR to completely separate them:
Done:
Ongoing:
Done:
Ongoing:
The below schema shows the overall architecture for the on-demand clusters. Some important points here are:
Done:
Ongoing:
--> Running computational service should work for one service at a time, provided they are set up to use a g4dn.xlarge machine type, there is no upscaling of the machines so parallel jobs will have to wait in line (if multiple isolve jobs are sent, they will be executed one after the other).
It is now possible to run computational services on their required AWS instance types. Also child computational job logs show up in the logs of the parent service (e.g. sim4life/jupyterlab starting a computational job). Upscaling is still not implemented.
Computational Backend
Controlling of external clusters:
Sim4life:
E2E:
Refactoring:
Description
With the latest version of sim4life.io, we are introducing an improved computational backend that ensures reliable and efficient job scheduling via the computational backend. Moving forward, all solver jobs will be scheduled via these facilities, enabling users to choose the hardware on which their jobs should run and providing the ability to inspect and operate on the job queue (subject to sufficient permissions).
This robust backend will be capable of handling 100s of concurrent jobs, ensuring that even the busiest periods will not cause any disruptions to service.
Furthermore, the backend functionality will also be made available through the API, allowing for integration with external systems (e.g. the sim4life desktop application) and further expanding the possibilities for users.