Das stimmt so fast - zum besseren Verständnis hilft aber vielleicht folgende Formulierung:
Pro Meeting das man startet erhält man vom Scalelite-Server einen BBB-Server im dahinter liegenden Pool zugeteilt. Alle die nach dem Start des Meetings dazu kommen, werden in die gleiche Session auf dem gleichen BBB-Server vermittelt. Wenn das Meeting beendet wird (man beachte da als Moderator auch den Unterschied zwischen „Meeting beenden“ und „Ausloggen“) wird diese Zuordnung gelöst und der Meetingraum aufgelöst.
Startet man mit der gleichen Klasse, mit der Moodle-Aktivität, irgendwann wieder ein Meeting, kann es sein man kommt auf einen ganz anderen BBB-Server.
Und Aufzeichnungen würde ich administrativ deaktivieren. Last, Plattenplatz, … und man muss dann alle BBB-Server und den vorgeschalteten Scalelite noch mit einem gemeinsamen Dateishare versehen. Geht, aber ob es den Aufwand lohnt? Möglich sind NFS, einer hat es aber auch schon per SSHFS gemacht.
So wie ich Frank verstanden habe, wird das Aufnehmen beim Lastverteiler direkt auf den BBB-Clients abgeschaltet - geht man über den Scalelite-Lastverteiler, kann man aber weiterhin aufnehmen und diese Aufnahmen sind ja auch in der Datenbank (erstmal egal, wo sie liegen).
Das generelle Abschalten würde BBB eines für uns zentralen Feature berauben. Es sind selten mal alle SuS da - und eine Sitzung aufzeichnen und bei Moodle anschauen können, ist doch eine ziemlich nette Sache.
Wenn ich direkt auf einem BBB-Server arbeite, werden ja meine „Räume“ in der Datenbank gespeichert - das muss doch bei Scalelite immer noch so sein, um eine Zuordnung Raum<->Aufnahme zu erhalten. Ist dann nur die „Realisierung“ des Raums dynamisch auf den Clients?
Wenn ich das richtig verstanden habe, werden die Aufnahmen mit Scalelite eben nicht auf den BBB Instanzen gespeichert, sondern auf dem SL Server - dann bekommt der zu tun. Ich denke ohne Aufnahmen ist ein LoadBalancer für BBB ein eher einfaches Stück Software, ich hatte da schon angefangen das selber zu programmieren, der leitet eigentlich nur weier und merkt sich, wo die Räume sind. Aber Andreas war schneller mit dem Scalelite und es gibt genug zu tun…
wir haben den Scalelite als VM installiert. Installation genau so wie es von dessen Schaffern beschrieben ist. Die Anleitung ist ein wenig dünne, aber mit ein wenig Geduld kommt man damit hin. Die einzelnen Komponenten werden auch im Scalelite als Docker-Container aufgesetzt. Bei uns also ein normales Debian 10 als Basis, und dann nach Anleitung die einzelnen Komponenten in diesem System installiert und kombiniert. Zum Schluss also eine VM, die die Komponenten als zusammenspielende Docker-Container hat. Geht.
Und das heiß diskutierte Recording haben wir als „nice to have“ nicht implementiert. Wenn man eine Aufzeichnung braucht, kann die auch von der Lehrkraft auch gleich lokal auf dem PC mitgeschnitten werden.
Wer kann mir weiterhelfen?
Ich habe drei BBB Server mit Greenlight am Laufen. Habe nun 4. Server mit scalelite installiert. Die drei Server sind dort auch eingebunden. Per Status-Abfrage bekomme ich die korrekten Sitzungsdaten angezeigt. Gut.
Jetzt möchte ich, dass ich von einer Greenlight Instanz eine Sitzung starte, die von scalelite auf einen der drei Server verteilt wird. Dazu habe ich in der greenlight .env bei BIGBLUEBUTTON_ENDPOINT= htps://xxxxxxx/bigbluebutton/api/ und beim BIGBLUEBUTTON_SECRET=xxxxxxxxxx das LOADBALANCER_SECRET von scalelite eingetragen.
Wenn ich nun über diese Greenlight Oberfläche eine oder mehrere Sitzung starte, laufen diese immer nach alle auf nur diesem einen BBB Server. Sie werden also nicht verteilt. Was mache ich falsch?
Ich bitte um Hilfe!
- zum besseren Verständnis hilft aber vielleicht folgende Formulierung: