Ein BBB Lastverteiler für einfache Leute

Wagemutige Tester dürfen mein aktuelles Projekt testen, ein einfacher Lastverteiler für BigBlueButton: GitHub - hmt/tinyscale: A tiny BigBlueButton load balancer

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.

5 Like

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.

In app.tst steht folgende Zeile;

import { createHash } from „https://deno.land/std@0.87.0/hash/mod.ts“;

Wird bei jedem Verbindungsaufbau deno.land konnektiert oder seh ich das falsch?

Hast Du das im BBB-Forum auf Google-Groups mal gestreut? Ich glaube auf so eine Loesung warten viele.

Gruss Harry

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 :slight_smile:

Hallo!

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).

Viele Grüße
Thomas

Gerücht? Ich zitiere aus der Scalelite Readme (GitHub - blindsidenetworks/scalelite: Scalable load balancer for BigBlueButton.)

Minimum Server Requirements

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 :slight_smile:

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 :slight_smile:
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.

2 Like

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.



(Vor den Ferien musste ich Grafana neu aufsetzen, die Zahlen waren ähnlich)

Glaub ich schau mir das jetzt doch mal genauer an, Deinen Ansatz find ich super.
BBB bleibt uns jetzt ja wohl doch noch eine Weile erhalten.

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:

  1. Deno installiert
  2. Das Script in mein root Verzeichnis kopiert
  3. Die Datei „servers.json“ angepasst
  4. 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:

  1. Wie starte ich das am klügsten im Hintergrund? Weil wenn ich jetzt Putty beende, wäre ja auch das Programm beendet

  2. 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 :wink:

Nur da komme ich gerade nicht weiter. Ich brauche dann vermutlich NGINX, Apache oder ähnliches? :frowning:

Ich weiß, leider absolute Anfängerfragen, aber da ich mich da sehr wenig auskenne, komme ich gerade nicht weiter :frowning: Ich würde mich sehr über etwas Hilfe freuen! Vielen Dank
Thomas

Hallo 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 :slight_smile:

3 Like

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!

Vielen Dank!!!

2 Like

Hallo Thomas2,

kannst du den Post der die Lösung brachte bitte als gelöst markieren.

Klick auf die drei Punkte:
asks_lösung_1
Dann:
asks_lösung_2

Beste Grüße

Thorsten

Hallo,

…und wenn dir so sehr gefällt was hmt gemacht hat, dann wäre auch ein Klick auf das Herz eine mögliche Option :slight_smile:
LG

Holger

Hat schon wer für mich erledigt. Das meiste hat sich ja im privatem abgespielt (111 Nachrichten) :smiley: Da waren verdammt viele Danke enthalten. Aber HMT hat ja quasi den Unterricht meiner Schule gerettet :wink: 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

Oh ja!! Er ist der Crack vorm Herrn :innocent:
IMHO

@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 :slight_smile:

VG Andreas

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 :wink: 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 :wink:

Hallo Thomas,
habe es später auch nachgelesen gehabt, sorry.

Eben :wink:

Schreib doch mal eine kleine Zusammenfassung :wink:

VG Andreas

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 :smiley: (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):

  1. lets encrypt installieren
  2. Port Redirect auf 3005 einrichten

Nun konnte ich in Greenlight folgende Werte nutzen:
https://tinyScaleUrl.de/bigbluebutton/ + secret

Zwischenzeitlich habe ich mir auch die Firewall aktiviert.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow https
ufw allow http
ufw enable

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.

1 Like