Cette page permet de regrouper des retours d'expérience concernant BigBlueButton, et son intégration à Moodle.
N’hésitez pas à enrichir cette documentation partagée avec les éléments liés à votre établissement, avec autant de détails que possible (et liens vers les outils utilisés).
Installation de serveurs BigBlueButton à l'Université de Strasbourg
Faisant face à la situation de confinement, nous avons mis en place sur nos plate-formes Moodle la solution de classe virtuelle BigBlueButton.
Elle semblait en effet la plus adaptée à un usage pédagogique.
A ces fin, voici ce que nous avons réalisé.
Mise en place pour Moodle
Architecture
- Côté Moodle, le plugin officiel BigBlueButtonBN a été mis en place.
- Côté serveur BigBlueButton, nous avons opté pour l'architecture suivante :
- 1 frontend "Scalelite" avec 8 VCPU et 8 Go de RAM
- 1 frontend "Greenlight" avec 8 VCPU et 8 Go de RAM (non ouvert aux utilisateurs)
- 10 "backend" BigBlueButton avec 12 VCPU et 8 Go de RAM
- 1 volume NFS partagé pour la publication des enregistrements
- 200Go pour l'instant (manque de recul)
- Pour le stockage NFS nous utilisons une baie NETAPP avec des disques mécaniques avec un peu de SSD
- 2 bases de données déportées sur des serveurs mutualisés pour GreenLight et Scalelite
- SGBD postgresql 11 standalone mutualisé avec d'autres applications.(8VCPU / 16Go)
A noter que :
- nos serveurs sont tous virtualisés
- nous utilisons le système de virtualisation "OpenNebula" basé sur KVM mais nous prévoyons de migrer dans OpenStack
- l'infrastructure est mutualisée avec d'autres services
Volumes
Cette infrastructure permet de tenir environ 2 000 utilisateurs en simultané (200 par serveurs).
L'Université de Strasbourg compte environ 54 000 étudiants.
Si jamais nous atteignons cette limite, nous avons la possibilité de déployer extrêmement rapidement de nouveaux backend pour supporter la charge.
Paramétrage côté serveur BigBlueButton
Pour les paramétrages du serveur BigBlueButton dédié à cette instance Moodle, nous avons opté pour les paramétrages suivants pour pouvoir diminuer la charge :
- webcamsOnlyForModerator: 'true'
- muteOnStart: 'true'
- allowModsToUnmuteUsers: 'true'
Version Autonome pour le télétravail
Nous avons également déployé une version "autonome", non connectée à Moodle.
Cette instance est dédiée pour les webconférences des chercheurs et administratifs en télétravail.
Une infrastructure dédiée a été également déployée avec des paramétrages différents sur l’applicatif.
Architecture
- 1 frontend "Scalelite" avec 8 VCPU et 8 Go de RAM
- Nous avons patché l'application Scalelite pour n'autoriser que les personnes à s'y connecter
- 1 frontend "Greenlight" avec 8 VCPU et 8 Go de RAM (non ouvert aux utilisateurs)
- 2 "backend" BigBlueButton avec 12 VCPU et 8 Go de RAM
- 1 volume NFS partagé pour la publication des enregistrements
- 2 bases de données déportées sur des serveurs mutualisés pour GreenLight et Scalelite
Paramétrage côté serveur BigBlueButton
Contrairement à l'instance dédiée à "Moodle", nous avons désactivé les paramètres suivants :
- webcamsOnlyForModerator: 'false'
- muteOnStart: 'false'
- allowModsToUnmuteUsers: 'false'
Pour cette instance, nous avons également proposé un request pull pour permettre au niveau de l'authentification LDAP d'ajouter des filtres avancés.
Nous avons également baissé le bitrate des profils disponibles. L'objectif étant de minimiser l'impact sur la bande passante.
Supervision
Nous avons également consolidé notre installation en mettant en place des outils de supervision.
Chacune de ces instances est supervisée via un script "nagios" qui nous alerte en cas de défaillance d'un nœud.
Nous avons aussi ajouté de la métrologie via un collecteur "Prometheus" et configuré un tableau de bord dans "Grafana".
Installation
Notre playbook Ansible de déploiement est disponible à l'adresse suivante :
https://www.github.com/unistra/bigbluebutton/
Quelques chiffres et retours
- montée à 60 vidéos sur un serveur qui a atteint ainsi visiblement ses limites
- Par défaut 1 flux vidéo et centralisé puis redistribuer vers tous les auditeurs.
- si chaque auditeur active sa caméra les flux sont multipliés
- 1 webinar (1 caméra + 1 partage écran) à destination de 200 personnes => fonctionne bien
- Il faut organiser la répartition des flux, programmer les sessions
- Maximum :constaté 700 personnes connectées avec 15 backends
- suite à cela 5 backend on été ajoutés
- 10 serveurs BBB dédiés à Moodle, 10 serveurs BBB dédiés à l'instance autonome
Contacts
Si vous avez des questions techniques, n'hésitez pas à contacter l’équipe BBB de la Direction du Numérique de l'Université de Strasbourg à l'adresse :
dnum-bbb@unistra.fr
Remerciements
Un grand merci à l'UPEC qui nous a fourni un script ansible de déploiement de BigBlueButton qui nous a servi de base ainsi qu'aux universités de Caen Normandie, polytechnique de Haut de France et du Havre Normandie pour leurs retours d'expériences.
