BigBlueButton an der TU Chemnitz

Im Zusammenhang zur Nutzung von BigBlueButton als Konferenzlösung an der TU Chemnitz erreichten uns nun schon eine ganze Menge Fragen zu Erfahrungswerten und der konkreten Vorgehensweise bei der Umsetzung. Die Antworten darauf möchten wir auf diesem Weg gern transparent machen und ggf. ergänzen.

Frage: Warum habt ihr eine eigene Lösung im Angebot, welche Systeme habt ihr euch angeschaut und warum habt ihr euch letztendlich für BigBlueButton entschieden?

Antwort: Bestehende Cloud-Lösungen sind mit Beginn der Pandemie und der gestiegenen Zahl der Zugriffe innerhalb weniger Tage zusammengebrochen und waren häufig nicht mehr nutzbar. Der Deutsche Forschungsnetz e. V. (DFN) bat deshalb gleich darum, dass die deutschen Hochschulen möglichst selbst alternative Lösungen umsetzen sollten. Gerade in dieser Zeit benötigten wir Möglichkeiten für das wissenschaftliche Personal und die Verwaltung, um in Gruppen an verschiedenen Aufgaben arbeiten zu können. Unser Hauptaugenmerk lag dabei auf einer einfachen Bedienung und einer stabilen Audioverbindung. Erste Versuche fanden auch mit jitsi statt.

Und natürlich war von Beginn an die Einhaltung des Datenschutzes von zentraler Bedeutung. Entschieden haben wir uns schließlich für BigBlueButton, weil es für die digitalen Lehre entworfen wurde und weil es Open-Source und gut dokumentiert ist. Das ermöglicht uns, entsprechende Anpassungen und Integrationen unkompliziert vornehmen zu können, zum Beispiel die zentrale Anmeldung über unser Web-Trust-Center (Shibboleth), oder wichtige, aber fehlende Funktionen selbst zu entwickeln.

Aufgrund der zu erwartenden Nachfrage des Dienstes war für uns außerdem wichtig, den Dienst horizontal skalieren zu können. Das bedeutet: Wenn mehr Leistung benötigt wird, können wir zusätzliche Server bereitstellen.

Frage: Wie seid ihr bei der Umsetzung vorgegangen?

Antwort: Ein Vierer-Team übernimmt die unterschiedlichen Aufgaben im Frontend- und Backend-Bereich. Beim Aufsetzen der Plattform sind wir zweigleisig gefahren. Das heißt, wir haben einen Prototypen installiert, der Nutzerinnen und Nutzern bereits zugänglich gemacht wurde, der aber noch nicht im Detail konfiguriert war. Parallel dazu haben wir begonnen, die Installation zu automatisieren, die Integration in das Web-Trust-Center und die Telefonanlage zu implementieren und die Skalierung mittels Load Balancer umzusetzen. Der Cluster ging nach einer Woche produktiv und wird seitdem stetig weiter verbessert.

Frage: Könntet ihr vielleicht euer Setup etwas dokumentieren, sodass andere Universitäten/Schulen das als Vorbild nutzen können? – besonders hinsichtlich eures Monitorings?

Antwort: Das Setup besteht im Wesentlichen aus drei Komponenten:

Web-Frontend Greenlight
- (https://github.com/bigbluebutton/greenlight)
- eigene Anpassung für Shibboleth
  - https://github.com/bigbluebutton/greenlight/pull/1138
Load-Balancer: Scalelite (https://github.com/blindsidenetworks/scalelite)
Mehrere Backends: BigBlueButton-Server
- Standard Installation mit http://docs.bigbluebutton.org/2.2/install.html
- Anpassung der Einstellungen
  - Anpassung der Standard-Folie
- Telefoneinwahl:
  - http://docs.bigbluebutton.org/2.2/customize.html#add-a-phone-number-to-the-conference-bridge
  - Pro Backend-Server eine eigene Rufnummer
  - Von der Telefonanlage ein SIP-Trunk zum jedem Backend-Server
  - Auf dem Backend-Server im Freeswitch zusätzliche ACL um den eingehenden SIP-Trunk nur von der Telefonanlage zu erlauben:
    - /opt/freeswitch/etc/freeswitch/autoload_configs/acl.conf.xml
```
<list name="owntk" default="deny">
   <node type="allow" cidr="10.0.0.1/32" />
   <node type="allow" cidr="10.0.0.2/32" />
   <node type="allow" cidr="10.0.0.3/32" />
</list>
```
    - /opt/freeswitch/etc/freeswitch/sip_profiles/external.xml
```
<param name="apply-inbound-acl" value="local_ip"/>
<param name="apply-inbound-acl" value="owntk"/>
```
    - https://freeswitch.org/confluence/pages/viewpage.action?pageId=3965687
  - Bei Bedarf Call-Detail-Records für Debugging einschalten:
    - /opt/freeswitch/etc/freeswitch/autoload_configs/modules.conf.xml
```
<load module="mod_xml_cdr"/>
```
    - https://freeswitch.org/confluence/display/FREESWITCH/mod_xml_cdr
    - https://freeswitch.org/confluence/display/FREESWITCH/CDR

Das Monitoring machen wir mit Cacti. Im Scalelite schauen wir, welche Server aktiv sind und rufen die Zahlen dann per BigBlueButton API ab. Da alle Daten dokumentiert und zugreifbar sind, konnten mittels einfacher Python-Skripte diverse Dinge verknüpft und automatisiert werden. So konnten wir z. B. das Monitoring der Backend-Server optimieren und verbessern.

Frage: Wie skalierbar ist BBB?

Antwort: Wir hatten schon Konferenzen mit deutlich über 100 Personen. Jeder Server hat ungefähr die Kapazität für 300 gleichzeitig Teilnehmende in Summe über alle Konferenzen auf dem Server. Eine Lastverteilung verteilt die Konferenzen auf unterschiedliche Server. Aktuell setzen wir sieben virtuelle Server mit jeweils zwölf CPUs und 16 GB RAM ein. Wenn wir mehr Server benötigen, können wir kurzfristig weitere Server installieren, da wir die Installation komplett automatisiert haben.

Frage: Was waren/sind die größten Herausforderungen?

Antwort: Die größte Herausforderung ist die Fehlersuche. Hier sind wir zunächst einmal sehr dankbar für die vielen Rückmeldungen, die uns über die Feedback-Funktion im BigBlueButton oder unsere Support-Adresse erreichen. Das System produziert allerdings unglaublich viele Logdaten in unterschiedlichen Formaten, sodass wir auch hier an Werkzeugen arbeiten, die es uns ermöglichen, die Fehlersuche effizienter zu gestalten.

Frage: Wie sind die Rückmeldungen der Nutzerinnen und Nutzer, welche Fehler sind aufgetreten?

Antwort: Es geht sehr viel positives Feedback bei uns ein. Gemeldeten Problemen liegen sehr häufig schlechte Internetverbindungen oder die Verwendung veralteter Hardware zugrunde. Das Wichtigste ist, dass Audio funktioniert. Hier ist die Telefoneinwahl sehr hilfreich, die alternativ genutzt werden kann, wenn die Internetverbindung eines Teilnehmers oder einer Teilnehmerin instabil ist. Vor Kurzem haben wir das Logging im Freeswitch (die Komponente, die sich um Audio kümmert) auf eine größere Detailstufe gestellt, sodass wir bei Audio-Problemen mehr Details sehen und Qualitätsstatistiken erstellen können.

Auf unserer BigBlueButton-Webseite gibt es Hinweise für Moderierende und Teilnehmende sowie einen FAQ-Bereich. Außerdem halten wir in unserem Blog Handlungshinweise zur Verbesserung der Qualität bereit.