Eine zweite JVB zu Jitsi Meet hinzufügen (Docker)

In der vorherhigen Anleitung habe ich gezeigt wie teamjoin.de angepasst wurde.

Tutorial: Jitsi Meet Docker Instanz anpassen
Tutorial: Eigene Jitsi Meet Instanz installieren (Docker / Ubuntu / Nginx)
Was ist Jitsi Meet?: Videokonferenzen mit Jitsi Meet
Meeting starten: https://teamjoin.de

Nun möchte ich euch zeigen wie eine zweite Jitsi-Videobridge (JVB) eurer bestehenden Jitsi Meet Instanz hinzugefügt werden kann. Dies ermöglicht euch mehr gleichzeitige Teilnehmer auf eurer Jitsi Meet Instanz zu haben.

Vorteile:

  • automatische Lastverteilung der Videostreams auf die einzelnen Videobridges (Round Robin)
  • in die Breite skalierbare Jitsi Meet Instanz
  • ein Zutrittspunkt für die Teilnehmer wie bsp. teamjoin.de
  • Erweiterung durch weitere JVB’s möglich

Was wird benötigt?

  • Eine laufenden Docker Jitsi Meet Instanz (siehe Anleitung)
  • 2 Server mit gleicher Ausstattung an CPU Kernen und Bandbreite
  • Optional: Die beiden Server sind über ein internes Netzwerk verbunden

Offene Ports in der Firewall (extern):

  • 4443/tcp
  • 10000/udp

Offene Ports in der Firewall (host zu host):

  • 2377/tcp
  • 7946/tcp+udp
  • 4789/udp

Punkt 1: Docker Swarm einrichten

Docker liefert ein Orchestrierungswerkzeug namens Swarm mit. Wir benutzen Swarm nur um ein Overlay Netzwerk zwischen Server A und B herzustellen. Die Docker Container starten wir weiterhin über docker-compose. Das hält uns weiterhin nahe am originalen Jitsi Meet Docker.

Im Testsetup habe ich 2 Debian Linux Server mit einem internen Netzwerk 10.10.0.0/16. Es funktioniert aber auch über das öffentliche Internet.

Unseren Server A richten wir als Swarm Manager ein.

Auf unserem zweiten Server (Server B) installieren wir docker und docker-compose nach Anleitung: Eigene Jitsi Meet Instanz installieren (Docker / Ubuntu / Nginx)
Es reicht der Anleitung bis Punkt 2 zu folgen.

Server B wird dann als Worker Node hinzugefügt.

Nun überprüfen wir ob Server A beide Nodes korrekt sieht.

Punkt 2: Overlay Netzwerk anlegen

Auf der Manager Node (Server A) erstellen wir unser Jitsi Meet Overlay Netzwerk.

Punkt 3: restart.sh auf Server A anpassen

Wir fügen die markierten Zeilen unserem restart.sh Script hinzu.

  1. Es wird geprüft ob das Overlay Netzwerk existiert, falls nein wird es erstellt
  2. Es wird der Netzwerkname ausgetauscht. Docker Swarm erlaubt keine Punkte („.“) im Overlay Netzwerknamen
  3. Das Netzwerk muss auf „external“ gestellt werden, ansonsten kann docker-compose nicht das Overlay Netzwerk von Swarm nutzen

Wir starten Jitsi Meet auf Server A mit dem angepassten Script neu.

Punkt 4: Zweite JVB auf Server B einrichten

Wichtig ist ein identisches JVB_AUTH_PASSWORD auf allen JVB Instanzen zu verwenden. Wir nutzen das Passwort von Server A und spielen es auf Server B ein.

Server A:

Server B:

Websockets: Damit die Websockets korrekt funktionieren, muss in die .env noch JVB_WS_SERVER_ID=jvb2 eingefügt werden. Als ID muss die Service-Bezeichnung aus der docker-compose.yml Datei genutzt werden (jvb2).

Wir erstellen docker-compose-jvb2.yml um nur die Jitsi Videobridge (JVB) auf Server B zu starten.

Dazu legen wir ein passendes restart.sh Script an.

  1. Als erstes wird ein Dummy Container gestartet, da docker-compose aktuell kein Overlay Netzwerk auf den Worker Nodes anlegen kann
  2. Danach wird der JVB Container gestartet

Punkt 5: Zweite JVB starten

Zuerst überwachen wir das Logfile auf Server A.

Dann starten wir auf Server B den JVB Container.
WICHTIG: Es muss immer zuerst die Jitsi Meet Master Instanz (auf Server A) gestartet werden bevor eine JVB Instanz joinen kann!

Im Log sollte nun diese Zeile zu sehen sein.

Fertig! Eine zweite JVB steht eurer Jitsi Meet Instanz nun zur Verfügung.

Als nächstes: Jitsi Meet Grafana Statistiken (Docker)
oder: Jitsi Meet Docker: WelcomePage anpassen

Euer adminForge Team

UnterstützenDas Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende.
0

dominion

Linux Systemadministrator

Das könnte dich auch interessieren …

20 Antworten

  1. 0x02 sagt:

    Vielen Dank für die Anleitung. Ich habe noch eine Verständnisfrage. Müsste Pkt. 4 nicht vor Pkt. 1 erfolgen? Da auf Server 2 noch kein Docker bzw. Docker-compose läuft, dürfte der Worker noch nicht aktiviert werden können oder habe ich einen Denkfehler?

    • Dominion sagt:

      Die Punkte 1-3 spielen sich doch alle auf Server A ab, dort sollte ja bereits Jitsi Meet Docker laufen. Erst in Punkt 4 wird begonnen auf Server B Docker zu installieren und dann die zweite JVB.

  2. 0x02 sagt:

    Hallo Dominion,

    Unter Punkt 1 soll doch der Worker (Test2 – Server B) dem Swarm hinzugefügt werden?

  3. Tobias Kern sagt:

    Hi Dominion,

    wann habt ihr geplant:

    Als nächstes: Tutorial über die Grafana Statistiken stats.adminforge.de

    Euer adminForge Team

    Danke für eure super Hilfe – Jitsi Server läuft wunderbar im Docker nach eurer Anleitung

  4. Dirk sagt:

    Hallo Dominion,
    Danke für die Anleitung.

    Vllt. sollte in die Anleitung etwas zu öffnenden Ports, falls man einen Paketfilter verwendet.

    Fürn ufw:

    ufw allow 2377/tcp
    ufw allow 4789/udp
    ufw allow 7946/tcp
    ufw allow 7946/udp

    VG
    Dirk

  5. Wenn mein Server A mit ./restart.sh neu gestartet wird, bekomme ich einen nginx 502 Bad Gateway-Fehler und nichts geht mehr.
    Meine beiden Server A und Server B sind nicht in einem internen Netzwerk verbunden, sondern sind also 2 VPS mit 2 verschiedenen IP-Adressen vorhanden.
    Vermute, dass der Netzwerknamenstausch von meet.jitsi in jitsi-meet alles durcheinder bringt, oder nicht weitreichend genug ist.

  6. Jonas sagt:

    Hi Dominion, danke für deine Anleitungen. Das hat mir alles sehr geholfen. Ich habe nun nur das Problem, dass meine Nodes das Netzwerk nicht finden. Das join hat zwar geklappt aber wenn ich das restart-Skript ausführe, schlägt es bereits bei dem Dummy Container fehl. Ich bekomme folgende Fehlermeldung:

    docker: Error response from daemon: attaching to network failed, make sure your network options are correct and check manager logs: context deadline exceeded.

    An der Portfreigabe kann es nicht liegen, da es schon mal funktioniert hatte ohne dass ich seitdem etwas an der Portfreigabe geändert habe. Als Nodes habe ich zum einen meinen Docker Daemon auf meinem Mac Rechner sowie eine VM in der Google Cloud probiert. Gestern hatte es funktioniert nachdem ich die Container und das Swarm Netzwerk auf Server A gelöscht habe und dann das restart-Skript ausgeführt habe, doch heute hat das leider nicht geklappt. Hast du eine Idee woran das liegen könnte?

    Vielen Dank im Voraus,
    Jonas

    • Dominion sagt:

      Hi Jonas,

      schwer zu sagen aus der Ferne.
      Du hast geschrieben, dass du das Netzwerk auf Server A gelöscht hast, deinem Swarm Master?
      Prüf mal bitte ob die Netzwerke da sind und ob die Container sich untereinander sehen können.

      Gruß
      Dominion

  7. Janosch sagt:

    Gude 👋🏻 Dominion,

    ich habe alles soweit hin bekommen, auch werden die Nutzer auf die zwei jvb verteilt. Nur meldet sich nach ner Zeit der nginx (als Reverse Proxy vor JitsiMeet) mit error Meldungen (der DockerGW würde Probleme machen), trennt dann Upstream Server und schmeißt irgendwann alle Benutzer raus. Mein Reverse Proxy lasse ich als Docker laufen.

    Hast du ggf nen Tipp für mich?

    Grüße und danke für deine super Artikel 👍🏻

  8. huuu sagt:

    hey laeuft soweit, nur noch ein mini prob zwecks websocket 🙂

    ( BridgeChannel.js:86 WebSocket connection to ‚wss://domain.dm/colibri-ws/jvb2/62dgdfccc746dfde32/6adfdsf9cf?pwd=2fnpdfsdfsdfgi9l11caese45v‘ failed:
    _initWebSocket @ BridgeChannel.js:86
    t @ BridgeChannel.js:105
    Logger.js:154 2021-03-14T18:00:57.514Z [modules/RTC/BridgeChannel.js] : Channel closed by server
    )

    dein rat die bridge noch einzufuegen hab ich auch so umgesetzt ( .env – JVB_WS_SERVER_ID=jvb2 ) – jvb.conf ( websockets {
    enabled = true
    domain = „domain.dm“
    tls = true
    server-id = „jvb2“
    )

    sonst wuerde hier nur die docker ip stehen statt jvb2

    bridges laufen auch soweit (teilnehmer werden auch sauber verteilt )

    nur ist die qualy auf 320 gedroppt 🙁

    hab die bridges wieder ausgehangen und swarm entfernt, da laeuft es mit SD & HD!

    war hier auch schon das thema ( Poor Videoquality with JVB2 on dedicated host: https://community.jitsi.org/t/poor-videoquality-with-jvb2-on-dedicated-host/86560/5 )

    event hat noch wer ein rat, sonst geniale anleitung.. thx !

    greetz

  9. Trace sagt:

    Hi,

    sobald ich Server B mit dem mit dem restart.sh Skript starte, bekomm ich in dem Log jvb2 Log folgende Error-Meldung:

    „The following addresses failed: ‚xmpp.meet.jitsi:522‘ failed because: java.net.UnknownHostException: xmpp.meet.jitsi: Name or service not known“

    Sprich er kann den Dienst von Server A nicht finden. Allerdings habe ich nochmal in der .env nachgechaut und die interne xmpp Addresse, lautet xmpp.meet.jitsi. Hat jemand evtl. eine Idee was ich falsch/anders machen muss?

    • Trace sagt:

      Habe das Problem gelöst^^. Allerdings stell ich mir noch die Frage, wie das Load-Balancing mit der hier beschriebenen Konfiguration funktioniert?

      • Dominion sagt:

        Wie genau hast du das Problem gelöst?

        Die Lastverteilung funktioniert pro Raum und JVB. Anders als beim OCTO Setup wird die Last pro Raum verteilt, bei OCTO wird jeder User per Round Robin auf den einzelnen JVB verteilt.
        Sollten Sehr große Räume so 40+ angestrebt werden, wäre eine OCTO Lastverteilung besser.

        • Jan sagt:

          Ich hatte das gleiche Problem bei Version 8319 und musste im docker-compose file unter prosody das folgende anpassen, weil es sich im upstream repo offenbar geändert hat:
          networks:
          jitsi-meet:
          aliases:
          – ${XMPP_SERVER}

          Generell gibt es viele moving/breaking parts mit jeder dritten neuen jitsi docker version, man muss echt immer direkt die alten und neuen files vergleichen, sonst bricht schnell mal was

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert