BBB server can handle only a certain amount of concurrent users. The number depends on the number of users sharing the webcam, audio, desktop sharing and of course the available hardware (CPU, network).
There are load balancer solutions out there for BBB (e.g. ScaleLight), however this creates a single point of failure, creates new problems with access to the recordings and it might be difficult to have a mixed setup when new BBB versions come out hat might require updates to the load balancer as well. Another issue when operating many OpenOlat instances is that it might be usefull to have different BBB clusters depending on service level or even client-specific mini-clusters.
All those issues can be solved by implementing a simple load balancer directly within OpenOlat. A drawback of this strategy is that adding a new BBB is not automatically propagated to multiple OpenOlat instances, but this can be solve by later adding a REST endpoint for adding and disabling BBB configurations.
- Implement data model for BBB server:
- Server URL and secret
- Recording server URL (optional, default is same as server URL)
- Server capacity factor: number between 1 and 100. Default is 1.
- Flag to enable / disable the server
- Relation from meeting to server
- Admin UI to add, edit, disable and delete a server
- When deleting a server, all associated meetings must be deleted as well (with dialog)
- Creating a meeting does not yet choose the server (could be an option in the future that admin can pre-select the server, but no need to implement this now)
- When initiating the meeting (press the create/join meeting button), OO performs a load check and then takes the server the server with the lowest load
- The load check does the following (proposition):
- is server available (responds at all)
- get all active meetings and calculate sum of users
- videoCount * 3
- voiceParticipantCount * 2
- listenerCount * 1
- weight the sum of the users of a BBB node with the server capacity
- compare those numbers, server with the smallest number has the lowest load
- The link to the recordings should use the optional recording server url or if not available the server url of the associated meeting server
- Prio C: In the server list the following figures should be displayed:
- Enabled (online/offline) or disabled
- Server capacity factor
- moderatorCount and running=true
- participantCount and running=true
- listenerCount and running=true
- voiceParticipantCount and running=true
- videoCount and running=true
- maxUsers and running=true
- Number of meetings with recording=true and running=true
- Meetings with recording=true and isBreakout=true and running=true
- Calculated load (using the load check
- Prio C: The list is filtered by default to only contain the values of the current OO instance, removing the filter will show the load of the BBB server regardless of which OO instance generated the meeting.
The load check is a first draft