Wer genügend der empfohlenen Hardware-Ressourcen pro Teilnehmer hat, ist fein raus. Wer aber nicht die in obiger Tabelle gezeigten Hardware-Ressourcen bieten kann (wenn man einen leistungsfähigen Server erstellt hat, dürfte der Engpass vor allem in der erforderlichen Bandbreite des Intranets liegen), muss sparen. Tatsächlich dürfte die Last hauptsächlich von der Anzahl gleichzeitiger Teilnehmer abhängen und den angebotenen Features (z.B. Aufzeichnung des Meetings, jeder Teilnehmer wird mit seiner Webcam gezeigt, …). Man muss also an der Anzahl der Teilnehmer sparen und/oder an der Anzahl der angebotenen Features:
Teilnehmer reduzieren
Grundsätzliches
Teilnehmer ist nicht gleich registrierter Nutzer. Denn nur ein Nutzer, der gerade an einem Meeting teilnimmt, kostet auch Ressourcen. Ein Nutzer kann auch gleichzeitig Teilnehmer bei mehreren Konferenzen sein und sogar mehrfacher Teilnehmer der gleichen Konferenz (warum auch immer) -> das erschwert die Lastabschätzung zusätzlich. Vielleicht kann man das auch abschalten?!
Um die Zahl der gleichzeitigen Teilnehmer zu limitieren, kann man die Gesamtzahl der Räume limitieren und die maximalen Teilnehmer je Raum. Da Big Blue Button erstmal auf Freiheit ausgerichtet ist, muss man diese grundsätzliche Freiheit einschränken, und sperren, dass die User eigene Räume erstellen und teilen können:
Anzahl der Räume limitieren
Mit der obigen Einstellung hat man erreicht, dass User keine Räume erstellen können, damit obliegt den Admins, welche Räume dem Unternehmen zur Verfügung gestellt werden.
Teilnehmer pro Raum limitieren
Vorläufig kann man ja per Anweisung verbieten, dass Räume mit mehr als 10 bzw. 15 Teilnehmern gefüllt werden.
Hier ist die Option defaultMaxUsersbeschrieben. Wie und ob man diese für die Administration seiner Big Blue Button Instanz nutzen kann, habe ich noch nicht herausfinden können.
Limitierte Räume optimal nutzen
Wenn die Nachfrage nach Räumen das Angebot an Räumen übersteigt, muss man ein Verfahren finden, die daraus entstehenden Nöte möglichst gering zu halten. Eine Möglichkeit wäre, dass jeder Abteilung zu einer bestimmte Uhrzeit alle Räume zur Verfügung stehen. Der Krisenstab bekäme z.B. alle Räume von 9 bis 10, die IT-Abteilung von 10-11 Uhr usw. Das würde sehr schnell für klare Verhältnisse sorgen. Dem Krisenstab könnte als einziges die Möglichkeit eingeräumt werden, auch Meetings der Abteilungen abzusagen, wenn sie ein eigenes Meeting veranstalten müssen. Für die übrigen Zeiten bietet sich das Raumplanungssystem an, welches im Unternehmen bereits für physische Räume genutzt wird.
Features reduzieren
Aufzeichnungen verbieten
Vermutlich die größte Entlastungen ist es, die Aufzeichnungen zu deaktivieren.
Vorläufig kann man den Moderatoren per Anweisung verbieten, die Möglichkeit der Aufzeichnung zu nutzen. Deren Einhaltung kann man als Admin auch leicht kontrollieren, da die Liste der Aufzeichnungen samt Aufzeichnenden einsehbar ist. Die Aufzeichnung kann gelöscht werden und/oder der Aufzeichnende kann ermahnt werden:
Mein Kollege hat es gerade ausprobiert und der Button zum Aufzeichnen ist tatsächlich verschwunden (Anleitung)
Dies sollte genau überlegt werden, denn Bildschirmfreigaben sind ein wichtiger Bestandteil von effizienten Meetings (z.B. PowerPoint-Präsentationen oder Übersicht über offene Aufgaben im Ticketsystem):
Auf unserem Server gibt es einen ordner „/greenlight“ über
den ja auch alles gestartet wird.
Über folgenden Befehl kommt man auf eine Settings-Datei:
sudo vim
/usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml
Damit öffnet sich die Datei und mit einem Klick auf `i` kann
man diese dann auch bearbeiten. Dort hab ich es zum Beispiel hinbekommen diese
Einstellungen zur Datenvolumeneinsparung direkt anzuschalten schon beim start
des servers (defaultSettings und dann dataSaving und das auf false gesetzt).
Mit Esc und dann :wq! wird das ganze gespeichert. Dann einmal den Befehl sudo
bbb-conf –restart ausführen und dann kann der server mit sudo docker-compose up
–d wieder gestartet werden und die Änderungen sollten übernommen sein.
Hinweis: Dieses Konzept basiert teilweise schon aus echter Erfahrung bei der aktuellen Schnelleinführung von BigBlueButton und teils noch aus Plausibilitätsannahmen, das es gerade Work-In-Progress ist.
Installation & Konfiguration
Idealerweise sollte ein Linux-Admin die Installation vornehmen. Es können auch andere ITler sein – diese werden jedoch deutlich länger benötigen. Grundsätzlich ist BigBlueButton schon ziemlich gut dokumentiert. Die Installation sollte laut offizieller Empfehlung auf einem Linux-Server mit folgenden Hardwarevoraussetzungen BigBlueButton stattfinden. Falls die Hardware-Ressourcen pro kommunizierenden Mitarbeiter nicht ausreichen, können performance-lastige Features (z.B. Aufzeichnungsmöglichkeit und Webcam-Verwendung) erstmal ungenutzt bleiben (Quellen). Leider können wir an dieser Stelle nur die Anleitung für eine (nicht ganz vollständige) Windows-basierte Testinstallation bereitstellen.
Parallel zu Installation & Konfiguration
Um keine unnötige Zeit verstreichen zu lassen, arbeiten sich mindestens zwei IT-Kollegen (sollte nicht der Linux-Admin sein, da dieser ja beschäftigt ist) arbeiten sich intensiver in die Nutzung und Administration von BigBlueButton ein.
Test
Anschließend wird die Performance durch ein reales Meeting und Arbeitschats innerhalb der IT-Abteilung getestet, auch um einen ersten Eindruck zu gewinen (dieser dürfte überwältigend positiv ausfallen). Hierzu wird ein Termin am Folgetag vereinbart und die Hardwarevorraussetzungen kommuniziert (Rechner, Headset (oder wenigstens den Lautsprecher am Rechner), unbegrenztes Datenvolumen beim Internetprovider – weil das Nutzen von Big Blue Button recht viel Datenvolumen kostet). Zusätzlich wird der Link zum Raum kommuniziert und dazu aufgefordert sich zu registrieren.
Prioritäten beim Ausrollen
Ist der Test bei der IT-Abteilung erfolgreich, wird als nächstes der Unternehmens-Krisenstab bzw. die Unternehmensleitung bzgl. Big Blue Button arbeitsfähig gemacht werden. Danach kann ein Ausrollen auf die anderen Abteilungen stattfinden. Da die Hardware-Ressourcen nicht für alle und alles ausreichen werden, sollte man sich frühzeitig mit der Lastreduktion bei Big Blue Button beschäftigen. Dies kann so stattfinden, dass die Abteilungsleiter zwei IT-affine & verfügbare Kollegen aus ihrer Abteilung bestimmen, die dann von den beiden IT-Kollegen, die sich schon eingearbeitet haben, innerhalb einer Big Blue Button-Session mit diesem Tool in den Rollen Nutzer, Präsentator und Moderator vertraut machen. Diese Kollegen können dann in ihren Abteilungen als Multiplikatoren und Moderatoren für die ersten Meetings fungieren. Diese Aufgaben weiterzudelegieren entlastet die IT-Abteilung in der Folgezeit, die mit der Herstellung der HomeOffice-Arbeitsumgebung ohnehin stark belastet ist. Bezüglich Registrierung der neuen Nutzer lies hier.
Kommunikation
Es ist immer mit Rückfragen der Kollegen zu rechnen, was Zeit kostet: „Wie gehe ich damit um, wenn ich dies und das nicht habe? Hat das neue Tool auch Feature XY haben, etc.
Da jede Schnelleinführung eines solchen Systems, die aufgrund der Krise unumgänglich ist, bedeutet Bananen-Software – sie reift beim Kunden. Das sollte man auch so kommunizieren.
