Kategorien
nerding about web

How To Scale Jitsi Meet In Google Cloud [2/x] – Concept

Wir alle sind faul und ich ganz besonders. Und so tippe ich mir im Folgenden meine Rechercheergebnisse darüber zusammen, wie andere Nerds Jitsi skalierbar machen.

Yasen Pramatarov hat für den Youtube-Channel des Jitsi Projekts ein Video über die Skalierung von Jitsi mit Hilfe der AWS veröffentlicht. In den folgenden Abschnitten erläutere ich das Konzept und die Bestandteile der Lösung.

Wie wir bereits wissen, bildet die Jitsi-Videobridge den Dreh- und Angelpunkt für die Videostreams aller Teilnehmer. Jitsi Meet (die WebApp) kann seine Nutzer aber auch auf mehrere Videobridges verteilen und so liegt es nahe, proportional zu den Nutzerzahlen immer mehr Videobridges zu starten. Damit stellt sich uns eine neue

Aufgabe: Wie lassen wir die Google Cloud automatisiert mehr VM-Instanzen starten?

Um die Lösung kümmern wir uns in diesem Post

Das Ergebnis sieht dann so aus:

Sauce: frame out of https://www.youtube.com/watch?v=Jj8a6ZRgehI

Unsere Jitsi-Instanz hat also mehr Puste, wenn es darum geht Videostreams für viele Räume zu behandeln. Doch was ist, wenn die Jitsi Meet WebApp nicht mehr mit den Nutzerfragen hinterher kommt?

Sauce: frame out of https://www.youtube.com/watch?v=Jj8a6ZRgehI

Yasen Pramatarov empfielt an dieser Stelle eine HAProxy-Instanz vor mehrere Jitsi-Meet-Instanzen zu klemmen…

Sauce: frame out of https://www.youtube.com/watch?v=Jj8a6ZRgehI

und gibt uns eine skizzenhafte Konfiguration für den HAProxy mit.

global
	...

defaults
	...

frontend jitsi_meet_frontend
	bind *:433 ssl crt /etc/ssl/certs/meet.nerds.cool.pem
	mode http
	option httpclose
	option forwardfor
	reqadd X-Forwarded-Proto:\ https
	default_backend jitsi_meet

backend jitsi_meet
	mode http
	balance roundrobin
	server shard1 shard1.example.com:443 check
	server shard2 shard2.example.com:443 check

Da ich im Titel ja die Umsetzung mit den Google Cloud Tools versprochen habe, werde ich in den folgenden Abschnitten aufzeigen, was HAProxy eigentlich macht. So können wir im Anschluss die gleiche Funktionalität mit Google nachbilden.

Was macht HAProxy?

HAProxy, which stands for High Availability Proxy, is a popular open source software TCP/HTTP Load Balancer and proxying solution […].

sauce: https://www.digitalocean.com/community/tutorials/an-introduction-to-haproxy-and-load-balancing-concepts

Oder einfacher gesprochen: Mit dem HAProxy stellt ihr einen Proxy-Server vor eure Web-Server, der Anfragen an diese Annimmt und gleichverteilt an diese weiter gibt.

Über die Konfiguration des HAProxy legt ihre fest, wo eure Backend-Server stehen, wie Anfragen auf diese verteilt werden und wie sich der HAProxy im Frontend gegenüber dem Nutzer präsentiert.

Layer 4 Load Balancing
sauce: https://www.digitalocean.com/community/tutorials/an-introduction-to-haproxy-and-load-balancing-concepts

Für tiefergehende Erläuterungen rings um Frontend, Backend und weiteren Bestandteilen des HAProxy, schaut mal hier vorbei.

Wie ist HAProxy konfiguriert?

frontend jitsi_meet_frontend
	bind *:433 ssl crt /etc/ssl/certs/meet.nerds.cool.pem

HAProxy stellt ein Frontentd namens jitsi_meet_frontend, welches an Port 433 gebunden wird und dessen ssl-Zertifikat unter gegebenen Pfad zu finden ist. Damit ist HAProxy die Endstelle für die SSL/TLS-Verschlüsselung, so dass diese Aufgabe nicht mehr bei den Jitsi-Meet Servern im Backend liegt.

	mode http
	option httpclose
	option forwardfor

Im http-Modus kann HAProxy auf Basis der Inhalte ankommender HTTP-Requests entscheiden, wie mit der Anfrage umzugehen ist. Da HTTP im Layer 7 — der Anwendungschicht — des OSI-Modells angesiedelt ist, liest man auch manchmal von Layer-7-Mode.

Das Schlüsselwort option beschreibt Optionen zum konfigurierten Modus: httpclose veranlasst HAProxy dazu, nach jeder beantworteten Anfrage die Verbindung zu schließen. Warum macht man das? Ich weiß es auch nicht.
fordwardfor belässt den originalen X-Forwarded-For header in der HTTP-request und stellt so sicher, dass Jitsi Meet immer weiß, wo der Nutzer denn nun ist.

	reqadd X-Forwarded-Proto:\ https
	default_backend jitsi_meet

Da sich die HAProxy mit den Backend-Server via HTTP unterhält, diese aber aus Gewohnheit HTTPS-Anfragen erwarten, wird der Request ein X-Forwarded-Proto Header angefügt, der den Backend-Servern signalisiert, dass Sie hinter einem load balancer hängen. Als default_backend wird „jitsi_meet“ angegeben, welches hier definiert wird:

backend jitsi_meet
	mode http
	balance roundrobin
	server shard1 shard1.example.com:443 check
	server shard2 shard2.example.com:443 check

Dem Backend sind zwei Server angeschlossen, sie sollen shard1 und shard2 heißen und werden mit dem keyword check von HAProxy auf ihre Gesundheit geprüft.

Was in dieser Skizze einer Konfiguration aber noch fehlt, ist die Entscheidungsgrundlage für HAProxy, welche Anfragen wohin geroutet werden.

Wohin mit den Anfragen?

Da eine einzelte Videobridge weiterhin den Knotenpunkt einer Jitsi-Konferenz bildet, müssen Anfragen für einen konkreten Raum auf die selbe Jitsi-Meet-Instanz geleitet werden. Daraus definiert sich eine neue

Aufgabe: Wie konfigurieren wir den Load Balancer so, dass er in Abhängigkeit des Raumnamens aus der URL arbeitet?

Um die Lösung kümmern wir uns in diesem Post

Solltet ihr eine überregionale Bereitstellung planen, so kann es sinnvoll sein, die Entscheidung von der Region des Anfragenden abhängig zu machen. Doch Achtung: Am Ende landen alle Teilnehmer auf der gleichen Videobridge und so ist mindestens der Raumersteller nah an der Videobridge. Google Cloud versichert uns aber, überregionale Distanzen mit deren Netzwerk abfedern zu können.

Fazit & Ausblick

In diesem Post konntet ihr einen Überblick über die Möglichkeiten zur Leistungssteigerung eurer Jitsi-Instanz gewinnen.
Im nächsten Post dieser Serie gehe ich auf die lastabhängige Bereitstellung zusätzlicher Videobridges in der Google Cloud ein. Stay tuned: folgt uns doch einfach bei Twitter!

Kategorien
nerding about web

How To Scale Jitsi Meet In Google Cloud [1/x] – Intro

In dieser Artikelserie nehme ich euch auf meinem Weg mit, eine hochverfügbare und auto-skalierende Jitsi-Instanz mit Hilfe der Google Cloud Dienste aufzusetzen.

Gegenwärtig sprießen überall im Leben Videokonferenzen aus unseren Endgeräten: Zoom, Skype, MS Teams, Skype for business — Die letzten zwei natürlich untereinander inkompatibel. Sag mal siehst du dich noch, Microsoft? — und auch Jitsi Meet teilen sich den Markt um die Anwender.
Alle? Nunja, nicht ganz. Jitsi ist ein Open Source Projekt und hegt keinen Anspruch auf Lizenzgebühren oder ähnliches. Und so kommt es, dass Jitsi dank seines Hintergrund die datenschutzfreundlichste und einfachste Lösung ist.

Warum nutzen wir denn dann nicht alle Jitsi? Nun, dank big old C ist die ganze Welt auf einmal gezwungen gewesen, sofort belastbare und nutzerfreundliche Videokonferenzsysteme an den Start zu bringen. Unter diesem Zeitdrunk sind Unternehmen mit keinen bis kleinen IT-Abteilungen gezwungen, Dienste wie zoom & co. für Geld — und vor allem für Sicherheit — einzukaufen, da man für das Hosten einer Jitsi-Instanz selber Kraft aufbringen muss.

Wenn ihr also interessiert seit und eine stabile Jitsi-Instanz starten wollt, die euch vor eurem Chef nicht wie ein Hobby-Nerd aussehen lässt, dann bleibt dran.

In Kürze folgt ein Post außerhalb dieser Serie, in dem ich euch das Zusammenspiel aller Jitsi-Projekte erläutere. Damit sollten dann die Grundlagen für das Ziel — Skalierung — geschaffen sein.

Kategorien
Uncategorized

hello world.

„guck mal ob nerds.cool noch frei ist“ forderte Stefan vom Sofa. Und so ists passiert. Here we go!