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:

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?

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

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.

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!