BigBlueButton-Serveranforderungen: Ein praktischer Leitfaden zur Dimensionierung für 500 gleichzeitige Benutzer

Beispielszenario: Stellen Sie sich ein fiktives Community College vor, das 500 Personen gleichzeitig online in fünf Kursen mit jeweils etwa 100 Teilnehmenden erwartet. Dies ist ein Planungsbeispiel, kein Benchmark, keine Kundenreferenz und kein Testergebnis. Die wichtigste Designentscheidung ist die Dimensionierung für mehrere Meetings, die auf mehrere Server verteilt sind; ein sehr großes Meeting mit 500 Personen birgt ein anderes Risikoprofil.

Welche offiziellen Anforderungen stellt BigBlueButton?

Die aktuelle Installationsanleitung von BigBlueButton nennt folgende Mindestanforderungen für einen dedizierten Server im Produktivbetrieb: Ubuntu 22.04 64-Bit, 8 CPU-Kerne mit hoher Single-Thread-Leistung, 16 GB Arbeitsspeicher mit aktiviertem Swap-Speicher und mindestens 250 Mbit/s symmetrische Bandbreite. Für die Speicherung von Aufzeichnungen werden mindestens 500 GB freier Festplattenspeicher benötigt, andernfalls 50 GB ohne Aufzeichnung. Die Anleitung erfordert außerdem die öffentlichen TCP-Ports 80 und 443, die UDP-Ports 16384–32768, einen Hostnamen und ein gültiges SSL-Zertifikat sowie IPv4- und IPv6-Unterstützung. Dies sind Mindestanforderungen für die Serverinstallation; sie garantieren keine Kapazität für eine bestimmte Meeting-Zusammensetzung. Bitte prüfen Sie die Installationsseite der von Ihnen geplanten Version, da sich die Anforderungen an Betriebssystem und Pakete ändern können.

In den Projekt-FAQs wurde in der Vergangenheit eine maximale Serverkapazität von etwa 200 gleichzeitigen Nutzern als Richtwert für die Erfüllung der Mindestanforderungen genannt. Dies dient als grober Planungsmaßstab und ist weder eine Garantie für die Servicequalität noch ein allgemeingültiges Limit pro Knoten. BigBlueButton weist selbst darauf hin, dass Server-CPU, Arbeitsspeicher, Bandbreite, Nutzung von Webcam und Bildschirmfreigabe, Konfiguration und Softwareversion das Ergebnis beeinflussen können. Betrachten Sie die Angabe von 200 Nutzern daher als erste Annahme, die Sie anhand Ihrer eigenen Arbeitslast überprüfen müssen.

Ein praktischer Ausgangspunkt für 500 gleichzeitige Benutzer

Für das fiktive College bietet sich als erste Architektur zur Evaluierung ein BigBlueButton-Cluster mit vier Knoten an. Jeder Media-Knoten erfüllt oder übertrifft die aktuellen Mindestanforderungen für die Produktion und verfügt über eine dedizierte, hochfrequente CPU. Bei 500 gleichmäßig verteilten Teilnehmern ergibt das einen Durchschnitt von 125 Teilnehmern pro Knoten. Der vierte Knoten ermöglicht eine flexible Planung von Meetings mit ungleichmäßiger Verteilung und Wartung; er bietet jedoch keinen automatischen Schutz für Meetings, die bereits auf einem ausgefallenen Server laufen.

Die Empfehlung von vier Knoten ist ein technischer Ausgangspunkt, der sich aus der offiziellen Mindestkonfiguration und der älteren Faustregel von 200 Benutzern ableitet. BigBlueButton veröffentlicht keine universelle Spezifikation, die vier bestimmte Server für jede Arbeitslast von 500 Benutzern zertifiziert. Wenn beispielsweise ein Server ausfällt, können die verbleibenden drei Server im Durchschnitt nur etwa 167 der 500 Benutzer bedienen, vorausgesetzt, Besprechungen können neu zugewiesen werden oder Benutzer können sich wieder verbinden und die verbleibenden Server bleiben innerhalb ihrer getesteten Grenzen. Eine aktive Besprechung auf einem ausgefallenen Knoten wird nicht automatisch auf einen anderen Knoten migriert. Wenn die Verfügbarkeit während eines Knotenausfalls zwingend erforderlich ist, testen Sie das Wiederherstellungsverfahren und ziehen Sie zusätzliche Kapazität über dieses einfache Modell hinaus in Betracht.

Warum fünf Kurse mit je 100 Teilnehmern sich von einem Treffen mit 500 Teilnehmern unterscheiden

BigBlueButton-Cluster verteilen Meetings auf mehrere Server. Sie fassen nicht mehrere Knoten zu einem gemeinsamen Medienprozessor für ein einzelnes Meeting zusammen. Fünf Gruppen mit je 100 Teilnehmern können als vollständige Meetings auf vier Server verteilt werden, während eine einzelne Gruppe mit 500 Teilnehmern weiterhin auf einem BigBlueButton-Server läuft. Die FAQ des Projekts rät davon ab, ein einzelnes Meeting mit über 200 Teilnehmern als normale, unterstützte Nutzung zu behandeln. Falls ein Meeting mit 500 Teilnehmern erforderlich ist, sollte das genaue Design mit dem BigBlueButton-Team oder einem qualifizierten Anbieter abgestimmt werden. Es ist zu prüfen, ob die Veranstaltung in kleinere interaktive Räume aufgeteilt oder als separate Übertragung mit eingeschränkter Teilnehmerinteraktion bereitgestellt werden kann.

Die Zusammensetzung der fiktiven Kursgruppe ist ebenfalls wichtig. Wenn die meisten Studierenden Audio hören und Folien ansehen, während nur die Dozenten ihre Webcams freigeben, kann die Medienlast deutlich geringer sein als in einer Besprechung, in der viele Teilnehmer ihre Kameras und Bildschirme freigeben. In seinen FAQs bietet BigBlueButton beispielhafte Webcam-Bitraten nach Auflösung sowie eine Methode zur Schätzung des Server-Ein- und -Ausgangs anhand der Anzahl der aktiven Webcams und Zuschauer. Nutzen Sie dieses Modell für eine erste Bandbreitenschätzung, berücksichtigen Sie dabei aber Audio, Signalisierung, Bildschirmfreigabe, erneute Übertragungen und Protokoll-Overhead. Multiplizieren Sie nicht einfach 500 mit einer geschätzten Bitrate und bezeichnen Sie das Ergebnis als Kapazitätsplan.

Netzwerk, Räume und Aufzeichnungen, die in die Planung einbezogen werden sollen

Geben Sie dem Medienverkehr einen direkten Weg

Verwenden Sie ein Netzwerkdesign, das es Browserclients ermöglicht, jeden zugewiesenen Medienknoten über die erforderlichen TCP- und UDP-Ports zu erreichen. Die Dokumentation des Cluster-Proxys von BigBlueButton erklärt, dass Medienstreams und WebSocket-Verbindungen direkt mit dem Server ausgetauscht werden, der die Konferenz hostet; der gemeinsame Proxy leitet hauptsächlich die Client-Schnittstelle und zugehörige Webressourcen weiter. Ein Reverse-Proxy, der versehentlich alle Medien über ein einziges kleines Gateway leitet, kann zum Flaschenhals werden. Überprüfen Sie vor dem Lasttest Firewall-Regeln, öffentliche Adressen, DNS, Zertifikate und Bandbreite in beide Richtungen.

Die Größe der Speicherkapazität wird anhand der Aufbewahrungsfrist ermittelt, nicht anhand der Teilnehmerzahl.

Schätzen Sie für das Beispielcollege die Anzahl und Dauer der aufgezeichneten Lehrveranstaltungen pro Tag und messen Sie anschließend die Größe repräsentativer Aufnahmen aus der tatsächlichen Version und den Einstellungen. Multiplizieren Sie die erwartete tägliche Produktionsmenge mit der Aufbewahrungsdauer und addieren Sie einen Sicherheitszuschlag. Die im Installationshandbuch empfohlenen 500 GB freier Speicherplatz stellen ein Mindestbedürfnis dar und garantieren nicht, dass eine bestimmte Aufbewahrungsrichtlinie erfüllt wird. Überwachen Sie den freien Speicherplatz und die Warteschlangen für die Aufzeichnungsverarbeitung und verschieben Sie archivierte Dateien nur über einen getesteten Workflow.

Wie man die Kostenschätzung vor dem Start validiert

1. Beschreiben Sie die Arbeitslast. Erfassen Sie die erwartete Anzahl gleichzeitiger Nutzer, Meetings, Nutzer pro Meeting, Webcam-Nutzer (Publisher und Viewer), Bildschirmfreigaben, Audionutzung, Aufzeichnungsrichtlinie, Sitzungsdauer und Beitrittsspitzen. Verwenden Sie das Beispiel mit den fünf Klassen nur, wenn es Ihrem tatsächlichen Muster entspricht.
2. Wählen Sie produktionsnahe Knoten. Achten Sie auf die Abstimmung von CPU-Generation und Taktverhalten, Arbeitsspeicher, Betriebssystem, Netzwerkpfad, Speicher und BigBlueButton-Version. Gemeinsam genutzte oder CPU-gedrosselte Instanzen können sich anders verhalten als dedizierte Rechenressourcen.
3. Testen Sie die Belastung schrittweise. Beginnen Sie mit einer kleinen Gruppe und erhöhen Sie die Teilnehmerzahl schrittweise, während Sie realistische Kameras, Audio, Präsentationsfolien, Bildschirmfreigaben und Aufzeichnungen nutzen. Integrieren Sie eine synchronisierte Beitrittsphase anstelle einer reinen Dauersitzung.
4. Beobachten Sie gleichzeitig benutzerseitig sichtbare Signale und Servermetriken. Verfolgen Sie die CPU-Auslastung und die Ausführungswarteschlange, den Speicherdruck und den Auslagerungsspeicher, den Netzwerkdurchsatz und Paketverlust, den Festplattenspeicher und die E/A, Dienstneustarts sowie Meeting-Symptome wie verzögerte oder unterbrochene Audioausgabe, eingefrorenes Video, fehlgeschlagene Freigaben oder Verbindungsschleifen.
5. Wiederholen Sie die Spitzen- und Erholungstests. Halten Sie die erwartete Spitzenlast lange genug, um thermische oder Speicherauslastung zu ermitteln, und testen Sie dann, was passiert, wenn ein Knoten ausfällt. Stellen Sie sicher, dass neue Meetings an funktionierende Knoten weitergeleitet werden und dokumentieren Sie, wie betroffene Benutzer wieder beitreten.
6. Legen Sie eine sichere Betriebsgrenze fest. Die veröffentlichte Höchstzahl gleichzeitiger Nutzer sollte auf wiederholbaren Tests mit ausreichender Kapazität basieren, nicht auf dem ersten erfolgreichen Durchlauf. Führen Sie nach Software-Upgrades, Änderungen der Webcam-Richtlinien, der Aufzeichnungskonfiguration oder der Host-Hardware erneute Tests durch.

Fazit für eine Bereitstellung mit 500 Benutzern

Für 500 gleichzeitige Teilnehmer in mehreren regulären Meetings beginnen Sie die Evaluierung mit vier dedizierten BigBlueButton-Medienknoten, wobei jedes Meeting die offizielle Mindestteilnehmerzahl für die Produktion aufweist, und einer robusten, meetingfähigen Clusterarchitektur. Planen Sie die Netzwerkkapazität großzügig ein, berücksichtigen Sie den Speicherbedarf für Aufzeichnungen anhand der ermittelten Aufbewahrungsanforderungen und testen Sie die optimale Kombination aus Räumen und Medien. Dieses Design dient der Dimensionierung und ist kein Beweis dafür, dass eine beliebige Cloud-Instanz 500 Benutzer unterstützen kann. Ein einzelner Raum mit 500 Personen stellt eine andere Arbeitslast dar und sollte nicht von der Gesamtanzahl der Cluster-Teilnehmer abgeleitet werden.

Offizielle Referenzen

• Installationsvoraussetzungen für BigBlueButton
• Häufig gestellte Fragen zu BigBlueButton 2.5: Hinweise zur Parallelverarbeitung und zu Workload-Variablen
• BigBlueButton 4.0 – Häufig gestellte Fragen: Bandbreitenhinweise und Beispiele für Webcam-Bandbreiten (Version 4.0 ist in der Dokumentation als Entwicklungsversion gekennzeichnet)
• BigBlueButton-Cluster-Proxy-Konfiguration