Hébergement BigBlueButton évolutif expliqué : du serveur unique aux clusters intelligents

Plongée approfondie dans l’infrastructure de visioconférence : comprendre la transition des serveurs monolithiques vers des clusters auto-réparateurs à haute disponibilité.


BigBlueButton s’est imposé comme la solution open source de référence pour les classes virtuelles et les conférences. Cependant, à mesure que les organisations grandissent, elles se heurtent inévitablement à un « mur de performance ». La question passe de « Comment l’installer ? » à « Comment héberger 2 000 utilisateurs simultanés de manière stable ? »

Faire évoluer BigBlueButton ne consiste pas seulement à ajouter de la puissance CPU à une machine (mise à l’échelle verticale) ; cela nécessite un changement fondamental d’architecture (mise à l’échelle horizontale). Ci-dessous, nous expliquons les trois étapes de l’évolution de l’hébergement.

01

La configuration à serveur unique

Dans une installation « monolithique » standard, chaque composant réside sur une seule machine physique ou virtuelle. Cela inclut le client HTML5, le serveur média Kurento/MediaSoup, Redis et la base de données du tableau blanc.

L’analogie : un petit café

Imaginez un serveur unique comme un café de quartier avec un seul barista. Il fonctionne parfaitement pour 50 à 200 clients. Le service est rapide et direct. Mais si 500 personnes essaient d’entrer en même temps, la file sort sur le trottoir, les commandes se mélangent et le système ralentit fortement.

Goulot d’étranglement technique : Node.js, qui alimente le client HTML5 de BigBlueButton, est monothread. Même avec un serveur à 64 cœurs, une seule réunion avec trop d’utilisateurs peut saturer le thread principal, provoquant des latences pour tout le monde. En général, la limite pratique est de 200 à 300 utilisateurs simultanés par serveur.
02

Le cluster open source : Scalelite

Pour contourner la limite du serveur unique, la communauté a développé « Scalelite ». Scalelite est un répartiteur de charge qui s’intercale entre votre frontal (Moodle/Greenlight) et un pool de serveurs BigBlueButton.

Comment fonctionne Scalelite

Scalelite s’appuie sur une pile complexe comprenant une base de données PostgreSQL pour suivre les réunions et Redis pour la mise en cache. Il interroge périodiquement les serveurs enregistrés afin de vérifier leur charge CPU et le nombre d’utilisateurs. Lorsqu’une nouvelle demande de réunion arrive, Scalelite l’oriente vers le serveur le moins chargé.

  • Mise à l’échelle horizontale : Vous pouvez théoriquement ajouter un nombre infini de serveurs au pool.
  • Le cauchemar des enregistrements : Un gros problème avec Scalelite concerne la gestion des enregistrements. Comme les réunions sont dispersées sur différents serveurs, vous devez mettre en place des systèmes de stockage partagé complexes (NFS ou S3) pour agréger les enregistrements. Si un serveur tombe en panne avant le transfert de l’enregistrement, les données sont souvent perdues.
L’analogie : la réception d’hôtel

Scalelite agit comme une réceptionniste d’hôtel. Les clients arrivent à l’accueil, et la réception leur attribue une chambre (serveur). Cependant, tenir la trace des objets trouvés (les enregistrements) provenant de centaines de chambres différentes devient un casse-tête logistique.

La limitation : Scalelite modifie les requêtes API avant de les transmettre aux serveurs. Cela casse souvent la compatibilité avec certaines intégrations tierces qui attendent une connexion directe à une API BigBlueButton standard.
03
Solution recommandée

Le niveau supérieur : équilibrage intelligent bbbserver

Chez bbbserver, nous avons reconnu les limites des configurations Scalelite standard. Nous avons construit une architecture propriétaire d’équilibrage de charge conçue pour une stabilité, une hygiène et une transparence maximales.

Résolu : collecte des enregistrements

Nous avons complètement éliminé le problème des « enregistrements manquants » présent dans les clusters standard. Notre système collecte, traite et centralise automatiquement les enregistrements de tous les nœuds sans nécessiter de montages NFS fragiles. Vous disposez d’un référentiel unique et fiable pour toutes vos données.

Le cycle de réinstallation de 24 heures

Les serveurs BigBlueButton accumulent avec le temps de la « poussière numérique » — fichiers temporaires et fuites de mémoire. Notre protocole unique « Fresh Start » draine automatiquement les serveurs et réinstalle complètement le logiciel toutes les 24 heures. Vous obtenez en pratique un serveur flambant neuf chaque jour.

Compatibilité API à 100 %

Contrairement à Scalelite, qui peut masquer des fonctions de l’API, notre répartiteur intelligent offre une compatibilité transparente à 100 %. Que vous utilisiez un plugin Moodle personnalisé, un LMS d’entreprise ou un script spécialisé, cela fonctionnera exactement comme si vous étiez connecté à un serveur unique.

Infrastructure auto-réparatrice

Si un nœud signale une erreur Kurento ou une latence audio, notre système l’isole instantanément, le bascule en mode maintenance et lance un remplaçant en quelques minutes. Aucune intervention manuelle nécessaire.

L’analogie : le complexe hôtelier de luxe auto-nettoyant

Imaginez un complexe où, après le départ de chaque client, la chambre n’est pas seulement nettoyée — elle est entièrement rénovée. Le concierge (notre répartiteur de charge) veille également à ce que tous les bagages des clients (les enregistrements) soient automatiquement transportés vers le hall principal, afin que rien ne soit jamais laissé dans les chambres.

Foire aux questions sur la mise à l’échelle

Un redémarrage libère la mémoire (RAM), mais il ne corrige pas les dérives de configuration, les fichiers temporaires corrompus ou les dépendances de paquets mises à jour. Une réinstallation complète garantit que la pile logicielle est identique à notre « Golden Image », éliminant 99 %des bogues « aléatoires ».

Non. Contrairement aux configurations Scalelite auto-hébergées où vous devez gérer les montages NFS et les scripts de transfert, bbbserver prend en charge tout le cycle de vie. Nous collectons les données brutes, traitons l’enregistrement et vous le mettons à disposition de manière transparente.

Absolument. Puisque notre système est compatible à 100 % avec l’API, la migration consiste généralement simplement à changer l’« URL de base » et le « Secret » dans votre LMS ou votre application frontale.

Découvrez la stabilité d’un serveur « Fresh »

Cessez de vous soucier des configurations d’équilibrage de charge, de la synchronisation des bases de données et des conflits d’API. Passez à bbbserver pour un environnement de cluster géré et auto-réparateur.

Voir les formules et les tarifs