Man ersetze mit diesen Lastverteiler die BBB-Api-Schnittstellenadresse, er wird sich um alles kümmern. Dabei geht er folgendermaßen vor: Bei creates wid geprüft, ob der Raum existiert, wenn ja, nichts tun, wenn nein, neuen auf einem der freien Server anlegen (einfach immer im Kreis der nächste Server wird genommen). Alle anderen Anfragen, die eine MeetingID mitgeben, prüfen, ob sie schon existieren, ansonsten wird einfach wieder an den nächsten Server geschickt.
Aufnahmen gehen nicht oder wurden nicht getestet. Ich habe grob mit NextCloud und Moodle getestet. Scheint zu funktionieren.
Warum das ganze? tinyscale kann man auf einem Toaster laufen lassen, sofern man Deno darauf installieren kann. Scalelite braucht einen großen Server. Das sehe ich irgendwie nicht ein, zumal mir nicht einleuchtet, was scalelite so anspruchsvolles anstellt.
Idee finde ich saugut, ist nur schwierig zu testen, da Bugs unter Umstaenden halt dann gleich mal den gesamten Unterricht lahmlegen. In der Praxis duerfte das Konzept einwandfrei tun, sind ja in der Regel ganze Klassen, die da in einem Raum rumhaengen und nur wenn’s ganz dumm laeuft wird die Belastung asymmetrisch.
Nein, deno hat kein „npm“ o.ä. mehr, die Pakete haben zwar urls, aber die werden nur einmal beim ersten Start heruntergeladen und dann lokal abgelegt, ähnlich wie das node_modules-Verzeichnis unter node.
Ich hab noch nichts im BBB-Forum gestreut, wollte erstmal selber testen. Bis jetzt scheint es fehlerfrei zu laufen, allerdings haben wir heute einen BFT und nur wenig Betrieb. Außerdem habe ich hier doch ein ganzes Forum mit Frewilligen, die ganz scharf darauf sind tinyscale auszuprobieren
Ich verstehe immer noch nicht, warum sich im Forum hartnäckig das Gerücht hält, ein scalelite müsse ein „großer Server“ sein. Wie Du schreibst macht Scalelite selbst ja fast nichts. Das Einzige, was ihn etwas „größer“ macht, ist, dass er als Docker Container verteilt wird. Aber der Server selbst benötigt ansonsten minimale Ressourcen (und wenn man eh noch etwas Platz für eine virtuelle Maschine hat)…
Was die Aufnahmen angeht, ist das nett, wenn die auf dem Scalelite liegen, weil man dann die BBBs nach Lust und Laune löschen/neu aufsetzen kann, ohne alte Aufnahmen zu verlieren. Aber auch dann benötigt halt höchstens etwas mehr Speicherplatz…
Was wir beim Scalelite noch nutzen, ist die Gewichtung der Server, da unsere Server unterschiedlich stark ausgestattet sind. Aber normalerweise hat man vermutlich doch eher heterogene BBB-Serverstrukturen eingekauft.
Auf jeden Fall ein cooles Projekt! Auch den Code zu sehen (bei scalelite bin ich tiefer als bis zum docker-container nie gedrungen).
For the Scalelite Server, the minimum recommended server requirements are:
4 CPU Cores
8 GB Memory
For each BigBlueButton server, the minimum requirements can be found here.
For the external Postgres Database, the minimum recommended server requirements are:
2 CPU Cores
2 GB Memory
20 GB Disk Space (should be good for tens of thousands of recordings)
For the external Redis Cache, the minimum recommended server requirements are:
2 CPU Cores
0.5GB Memory
Persistence must be enabled
tinyscale ist stateless, es wird keine DB benötigt, jeder Api-Ruf wird durchgereicht, wenn es nicht gerade ein create ist. Die Aufnahmen könnte man im Prinzip auch mit abfangen, aber dann habe ich das gleiche Problem wie auch bei den Statistiken, ich müsste immer alle Serverergebnisse als xml zusammenfassen und zurückgeben. Das sprengt momentan den Rahmen dessen, was ich selber brauche.
Theoretisch könnte man auch intelligent verteilen, indem man vor jedem create alle Server nach Auslastung abfragt und dementsprechend gewichtet entscheidet. Man könnte auch prozentual verteilen. Alles kein Problem, ich brauche es aber nicht, weil bei mir alle Server gleich sind
Ich habe mich noch nicht ausführlich damit beschäftigt, aber man müsste theoretisch auch per Docker den Service ohne weitere Installation starten können, wenn man einem deno-Container die Adresse des Repos mitgibt und den Rest als Umgebungsvariable. Das werde ich vielleicht mal testen, weil es interessant klingt und praktisch ohne Updates auskommt.
Die vollständige Scalelite-Installation braucht schon etwas mehr als einen Toaster - wir haben damals mit einem virtuellen Server getestet (2 CPU Cores, 4 GB Speicher) und das Verteilen der Konferenzen lief einwandfrei. Vermutlich ist das jetzt eine Perspektivfrage, wo „große Server“ losgehen
Ich vermute, das Hauptproblem sind dann tatsächlich die Aufnahmen, etc. die den Datenbankkram notwendig machen (wo stünde sonst, wo die Aufnahmen einer längst vergessenen Konferenz liegen).
Deine Lösung füllt halt perfekt die Lücke, wo all das nicht gebraucht wird.
Den Praxistest hat tinyscale heute bestanden. Die letzen beiden Tage waren BFT bei uns, heute wieder voller Betrieb und keine Ausfälle. Mit der Verteilung hat es auch ganz gut geklappt. Man sollte allerdings einen Puffer haben, da manche Konferenzen länger dauern als andere und dadurch die Verteilung etwas durcheinander kommt.
Wen es interessiert, zwei Monate später hatte ich keinen einzigen Ausfall, beide Server bewegen sich im Mittel, es gibt immer mal Abweichungen zwischen Teilnehmern und Räumen, die um die 5% betragen.
Manchmal kommt es vor, dass auf Server 1 zehn Räume offen sind, auf Server 2 vielleicht drei. Dann sind aber drei Minuten später die Verhältnisse gemischt. Es gab keinen Ausrutscher, wo ein Server schlapp macht under der andere nichts zu tun hat. Ich denke, dass ein komplizierter Algorithmus das nicht hätte besser machen können, denn der weiß ja auch nicht, wie viele Teilnehmer wie lange in einem Raum aukreuzen, wenn der Raum erstellt wird. Stumpfe A/B-Verteilung scheint also gut zu klappen.
Hallo zusammen,
da ich noch einen virtuellen Server frei habe, wäre das Script von @hmt die perfekte Lösung für mich. Wir haben nämlich zwei BBB-Server.
BBB1 ist für Jhrg 1-10 + Moodle
BBB2 ist für die Oberstufe (Greenlight)
(Aufnahmen sind bei beiden Servern komplett deaktiviert)
Leider war heute BBB1 mit 460 Teilnehmern etwas überlastet und BBB2 hat sich gelangweilt
Leider fehlt es mir an Erfahrung mit Linux.
Ich habe nun auf einem frischem Ubuntu 20.04 folgendes gemacht:
Deno installiert
Das Script in mein root Verzeichnis kopiert
Die Datei „servers.json“ angepasst
Folgenden Befehl ausgeführt: TINYSCALE_SECRET=beliebig deno run --allow-net --allow-read --allow-env https://deno.land/x/tinyscale@v1.1.2/mod.ts
Nun steht da „listening on port 3005“ und das Script wurde gestartet.
Nun meine Noob-Fragen:
Wie starte ich das am klügsten im Hintergrund? Weil wenn ich jetzt Putty beende, wäre ja auch das Programm beendet
Wie richte ich jetzt meine Domain ein, damit das funktioniert
Rufe ich nun meineDomain.de:3005 auf erhalte ich in Putty für jeden Aufruf der URL ein 404: listening on port 3005 404 /
Vermutlich fehlt mir dieser Schritt noch:
„you will have to set up your reverse proxy so that it can pick up requests or you leave it on that port.“
Und bbb-conf --setip mit der neuen Domain muss ich wohl auch noch. So langsam gehen mir immer mehr Lichter auf
Nur da komme ich gerade nicht weiter. Ich brauche dann vermutlich NGINX, Apache oder ähnliches?
Ich weiß, leider absolute Anfängerfragen, aber da ich mich da sehr wenig auskenne, komme ich gerade nicht weiter Ich würde mich sehr über etwas Hilfe freuen! Vielen Dank
Thomas
der Reihe nach. Du kannst das Script mit eine & am Ende des Befehls im Hintergrund starten, aber dann siehst Du keine logs. Ich empfehle tmux oder screen zu verwenden, eine virtuelle Konsole, die immer an bleibt, auch wenn Du Putty beendest. Mini-Einführung:
# in der Shell:
% sudo apt install tmux
% tmux
# tmux wird nun geöffnet
# Du kannst mit strg-b + a weitere shells starten, mit strg-b + d gehst Du aus tmux wieder raus (läuft aber im Hintergrund weiter)
# loggst Du Dich wieder ein, dann mit tmux a an die bestehende Konsole anhängen
#
# in tmux startest Du wie oben angegeben das Script
Du brauchst das Script bei Verwendung des Befehls gar nicht herunterladen, es wird von deno dynamisch geladen. Es wird lediglich die servers.json benötigt.
Bei Aufruf Deiner Domain mit Port 3005 passiert natürlich nichts, weil bbb unter / ja auch keinen Dienst zur Verfügung stellt. Es wird nur die API angeboten. tinyscale funktioniert tatsächlich nur wie die BBB-API. Es stellt keine Oberfläche etc zur Verfügung. Am besten testest Du das ganze, indem Du in Moodle oder was auch immer Du als Endpunkt verwendest die tinyscale Adresse eingibst, inklusive Port und Secret. Dann reicht tinyscale alle Anfragen an die in der servers.json eingetragenen BBB-Server weiter. Oder Du nimmst den Apimate, der in der bbb-config --secret angezeigt wird. Dort kannst Du auch den tinyscale für verwenden. Die Logs sollten dann anzeigen, was passiert.
Der Reverse Proxy ist nur dann nötig, wenn man z.B. eine schöne-Adresse für tinyscale verwenden möchte. Ansonsten ist kein Webserver nötig. Tut mir leid, wenn das nicht ganz eindeutig formuliert wurde.
Du musst übrigens kein bbb-conf --setip machen. Warum? Die IP des BBB bleibt ja gleich, tinyscale reicht die Anfragen nur weiter an die BBB-Server.
Du kannst mir gerne auch eine PN schicken, wenn es irgendwo hakt
So jetzt muss ich wirklich mal @hmt in den aller größten Tönen loben.
Sowas von hilfsbereit, hat er mir nicht nur geholfen, dass Script bei mir zu installieren, sondern es dazu noch weiter entwickelt, so dass es nun einen „Strict Modus“ hat und Greenlight unterstützt. Richtig cool!!!
Jetzt habe ich quasi einen Scalelite der wenig Resourcen kosten und das im Prinzip super einfach. Es handelt sich dabei um genau die Lösung, nach der ich gesucht habe!
Egal ob die KollegInnen nun per Greenlight1, Greenlight2 oder Moodle einen BBB aufmachen, sie werden immer abwechselnd auf meine zwei Server verteilt! Genial!
Ich habe auf dem neuen Server Apache2 mit lets encrypt und falls das hier wer lesen sollte, der sich auch eher weniger auskennt, gebe ich mein Anfänger-Wissen gerne weiter!
Hat schon wer für mich erledigt. Das meiste hat sich ja im privatem abgespielt (111 Nachrichten) Da waren verdammt viele Danke enthalten. Aber HMT hat ja quasi den Unterricht meiner Schule gerettet Von daher war die Lösung ja eher das in den Privatnachrichten besprochene.
Ich habe jetzt auch noch mal ganz oben das Herz geklickt! Ich hoffe jetzt sind alle zufrieden :D:D
@Thomas2@hmt :
Generell interessiert mich die Lösung sehr, aber habe im Moment wenig Zeit dafür.
Wie verhält es sich mit Aufzeichnungen?
Werden die zentral gespeichert? @Thomas2: Ansonsten TOP und Danke für deinen praktizierten Einsatz
Bei uns sind Aufzeichnungen jeglicher Form deaktiviert. Das macht es einfach. Und einen Turnserver habe ich auch nicht (hätte ich aber gerne). Von daher kann ich da nicht helfen!
Ich habe ja nichts gemacht Wobei praktizierter Einsatz trifft dennoch irgendwo zu. Aber die Arbeit hat ja @hmt gehabt. Aber falls du das „Herz“ meinst, was ich ganz oben beim ersten Beitrag vergeben habe (nach Aufforderung), dann sehr gerne
Naja gerne. Die meisten Dinge beschreibt er ja schon perfekt. Bei mir ging es eher um viel drum herum, da ich mich mit vielem nicht auskannte (Apache2, Screen/tmux, SSL, PortRedirect). Meine Vorgehensweise war folgende; auf einem angeblich leerem Server, auf dem aber z.B. schon Apache2 lief (Ubuntu 20.04)
sudo apt update && sudo apt upgrade
sudo apt install curl
//Deno installieren
curl -fsSL https://deno.land/x/install/install.sh | sh
//Dann habe ich folgende 2 Befehle in meine .bashrc geschrieben
export DENO_INSTALL="/root/.deno"
export PATH="$DENO_INSTALL/bin:$PATH"
//putty neustarten
//Ordner Tinyscale anlegen und da rein nur eine Datei namens servers.json
// in die Datei dann genau der Inhalt, wie es auch in der Anleitung steht. Bei mir steht es so drinnen (kein bigbluebutton, kein api etc anhängen)
[
{
"host": "https://bbb1.de",
"secret": "secret1"
},
{
"host": "https://bbb2.de",
"secret": "secret2"
}
]
####
//dann kann es gestartet werden. Dieser Befehl startet jetzt die neueste Version 1.5.0.... Ich weiß aber zum Beispiel, dass in Kürze 1.5.1 raus kommen könnte :D:D:D
cd tinyscale
TINYSCALE_SECRET=beliebiges_secret deno run --allow-net --allow-read --allow-env https://deno.land/x/tinyscale@v1.5.0/mod.ts
Dann kann man es bereits per http nutzen.
Dazu einfach in Moodle oder Greenlight (.env) folgende Werte eintragen: http://tinyScaleUrl.de:3005/bigbluebutton/
sowie das secret, mit dem TinyScale gestartet wurde.
Über HTTP habe ich es dann genutzt und mich an SSL gemacht (wo ich auch Anfängerprobleme hatte):
Ich habe soeben v1.6.0 freigegeben. Ich teste es zur Sicherheit erstmal auf meinem eigenen Server, aber denke, dass es funktioniert. Zumindest unter meinen Testbedingungen konnte ich nun mehrere Creates mit der gleichen MeetingID verhindern. Kommen zwei Anfragen mit der gleichen ID an, dann wartet tinyscale die erste ab und lässt dann die nächste ihre Anfrage starten.
Da waren verdammt viele Danke enthalten. Aber HMT hat ja quasi den Unterricht meiner Schule gerettet 
