34C3 CDN

Architektur

Die CDN-Kaskade hat 4 Stufen

1. Master-Encoder

Das Master-Encoding entsteht auf dem encoder-cube im Saal aus dem Ausgabesignal des Voctomix. Das Master-Encoding enthält den Mix als 1080p25 in h264 sowie die Slides als 1080p5 in h264 sowie aac von allen 3 Audiospuren. Alle Spuren werden in einem Matroska-Container verpackt.

Das Master-Encoding wird von einem Script erzeugt, welches vom ansible aus folgendem Template erzeugt wird: https://github.com/voc/cm/blob/master/ansible/roles/encoder/templates/voctomix-scripts/streaming-sink-mkvonly.sh.j2

Das Master-Encoding wird auf den lokalen (= auf dem encoder-cube laufenden) Icecast auf Port 7999 gepusht (http://encoderX.lan.c3voc.de:7999/sX). live.lan.c3voc.de pullt diesen und bietet ihn seinerseits auf http://live.lan.c3voc.de:7999/sX an.

2. Transcoder

Das Transcoding läuft im CCL auf den Minions 1, 5 und 6 (die Minions der neusten Generation). Dabei sind die Räume wie folgt auf die Minions verteilt:

minion1: s1

minion2: s2

minion3: s3 & s4

Diese Verteilung wird über Host-Attribute im cm geregelt: https://github.com/voc/cm/blob/master/ansible/event#L41-L44.

Die Transcoding-Scripte holen sich die Master-Streams von http://live.lan.c3voc.de:7999 und erzeugen die fehlenden Formate: vpx-hd/sd/slides, vorbis-audio (für webm), h264-sd sowie mp3/opus-audio.

Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt werden: https://github.com/voc/cm/tree/master/ansible/roles/transcoder/templates/transcoder

Die drei Scripte (h264, vpx, audio) erzeugen aus dem Master-Stream drei Format-Streams: (sXh264, sXwebm, sX_audio), welche wieder gegen live.lan.c3voc.de gepusht werden. Diese Format-Streams sind dann unter folgenden URLs verfügbar:

http://live.lan.c3voc.de:7999/sX_h264

http://live.lan.c3voc.de:7999/sX_vpx und

http://live.lan.c3voc.de:7999/sX_audio

Da jeder Format-Stream aus einem einzelnen ffmpeg-Prozess stammt und in einem Container landet sind die darin enthaltenen Videoströme Zeitsynchron zueinander. Die Trennung nach Formaten soll ermöglichem einzelne Format-Transport-Chains bei Problemen neustarten zu können, ohne die andere zu stören.

Die Pull-Quelle und das Push-Ziel ist über Group-Vars konfigurierbar: https://github.com/voc/cm/blob/master/ansible/group_vars/transcoders

3. Fanout

Diese 3 Format-Streams je Raum werden von der nächsten Stufe auf live.lan.c3voc.de in die finalen Streams in allen für Endnutzer angebotenen Kombinationen auseinander gemuxt (=“fanout”).

Dabei entstehen alle Kombinationen aus sX_[hd|sd|slides]_[native|translated|translated-2] in webm und hls sowie sX_[native|translated|translated-2].[mp3|opus] erzeugt. Die WebM- und die Audio-Streams werden gegen den Icecast auf http://live.lan.c3voc.de:8000/ gepusht, die HLS-Streams werden vom nginx unter http://live.lan.c3voc.de/hls/ angeboten.

Die Scripte dazu werden vom ansible aus folgenden Templates erzeugt werden: https://github.com/voc/cm/tree/master/ansible/roles/relay/templates/fanout.

Zusätzlich werden vom Ansible Master-Playlisten für jede Sprache in jedem Raum aus folgendem Template erzeugt: https://github.com/voc/cm/blob/master/ansible/roles/relay/templates/fanout/hls_master.m3u8.j2. Diese Master-Playlisten erlauben ein nahtloses umschalten auf verschiedene Qualitätsstufen von Kompatiblen Geräten (insb. iOS/macOS).

Die Pull-Quelle und das Push-Ziel sowie der Pfad unter dem die HLS-Schnipsel und Playlisten abgelegt werden ist über Group-Vars konfigurierbar: https://github.com/voc/cm/blob/master/ansible/group_vars/relays#L5

Zu dne Aufgaben der fanout-Scripte gehört auch das übermitteln des h264-Videostroms zu Youtube. Die Stream-Keys dazu kommen aus dem KeePass, die Scripte aus dem oben verlinkten Git-Repo.

4. Transport- und Edge-Nodes

Die (Non-Public) Transport-Nodes ziehen alle Daten via Icecast oder nginx-Proxy-Konfiguration von live.lan.c3voc.de. Die (Public) Edge-Nodes ziehen ihre Daten von den jeweiligen Transport-Nodes.

Testdaten

Streamdump des mkv-multiformat-Streams wie ihn die encoder produzieren werden (mit 2 Video und 3 Audiospuren): https://c3voc.mazdermind.de/volatile/main-plus-slides-with-two-translations-stream.mkv

Für den Teststream vor dem Congress (Codename sXnativehd & co.) wurde speedy.lan.c3voc.de als Transcoder für den Stream sX konfiguriert; live.ber.c3voc.de übernimmt das fanout. Der Teststream wird von einem script in einem screen des voc-Benutzers auf live.ber.c3voc.de zugeliefert.

Alle bereitgestellten Test-URLs lauten:

VPx-HD:

http://cdn.c3voc.de/sX_native_hd.webm

http://cdn.c3voc.de/sX_translated_hd.webm

http://cdn.c3voc.de/sX_translated-2_hd.webm

VPx-SD:

http://cdn.c3voc.de/sX_native_sd.webm

http://cdn.c3voc.de/sX_translated_sd.webm

http://cdn.c3voc.de/sX_translated-2_sd.webm

VPx-Slides:

http://cdn.c3voc.de/sX_native_slides.webm

http://cdn.c3voc.de/sX_translated_slides.webm

http://cdn.c3voc.de/sX_translated-2_slides.webm

h264-HD:

http://cdn.c3voc.de/hls/sX_native_hd.m3u8

http://cdn.c3voc.de/hls/sX_translated_hd.m3u8

http://cdn.c3voc.de/hls/sX_translated-2_hd.m3u8

h264-SD:

http://cdn.c3voc.de/hls/sX_native_sd.m3u8

http://cdn.c3voc.de/hls/sX_translated_sd.m3u8

http://cdn.c3voc.de/hls/sX_translated-2_sd.m3u8

h264-Slides:

http://cdn.c3voc.de/hls/sX_native_slides.m3u8

http://cdn.c3voc.de/hls/sX_translated_slides.m3u8

http://cdn.c3voc.de/hls/sX_translated-2_slides.m3u8

h264-Multi-Qualits:

http://cdn.c3voc.de/hls/sX_native.m3u8

http://cdn.c3voc.de/hls/sX_translated.m3u8

http://cdn.c3voc.de/hls/sX_translated-2.m3u8

Audio-MP3:

http://cdn.c3voc.de/sX_native.mp3

http://cdn.c3voc.de/sX_translated.mp3

http://cdn.c3voc.de/sX_translated-2.mp3

Audio-Opus:

http://cdn.c3voc.de/sX_native.opus

http://cdn.c3voc.de/sX_translated.opus

http://cdn.c3voc.de/sX_translated-2.opus

<note important>Zum Töten des Teststreams:→ https://todo.mazdermind.de/b/9a2QiHPpBnskhrgia/34c3/2TuxeGazbye7oAvjM

auf speedy.lan.c3voc.de:

sudo systemctl stop transcode_sX.target
sudo systemctl disable transcode_sX.target

auf live.ber.c3voc.de:

sudo systemctl stop fanout_sX.target
sudo systemctl disable fanout_sX.target
screen -rd source-for-teststream
:quit

</note>

TLS

Die Zertifikate für TLS auf allen Hosts kommt von Let's Encrypt (“LE”). Damit wir aber nicht von der Verfügbarkeit von LE abhängig sind oder in Rate Limits laufen, generieren wir die benötigten Zertifikate vorher und speichern diese im KeePass, von woher sie via Ansible ausgerollt werden. Nach dem Congress schalten wir zurück auf selbst Verwaltete LE-Zertifikate.

Wir wollen versuche ein Zertifikat mit allen Domain-Namen aller Edge-Relays zu erzeugen. Dazu wollen wir die DNS-Basierte Authorisierungsmethode verwenden. Es gibt dazu im Homedir von mngslave.dus.c3voc.de ein Script, welches ein Zertifikat für alle relevanten CDN-Domains generiert: /home/voc/letsencrypt-cdn-for-34c3/update-cert.sh. Die Domains, für welche das Zertifikat gilt werden in domains.txt konfiguriert, die Ausgabedateien sind jeweils in cdn-all-domains/cdn.c3voc.de/{fullchain,chain,privkey,cert}.pem. Diese müssen jeweils in den Keepas in den Eintrag ansible→ssl→certs→34c3.cdn.c3voc.de unter Advanced in die Additional attributes.

Anschließend muss das neue Cert auf alle LBs und Relays ausgerollt werden:

./ansible-playbook-keepass -u voc --become --become-method=sudo -i cdn site.yml --tags letsencrypt

Relay-Register

Das Relay-Register ist hier zu finden: https://c3voc.de/34c3/register - Der Login liegt im KeePass vor (gleicher Login wie beim 32C3)

Alle Relays melden sich (bzw. werden via Script) beim Relay-Register angemeldet. Dort kann ihnen ein Platz in der Relay-Kaskade zugewiesen werden (z.B. welcher Host ihr Upstream ist) und ob sie nur ICecast, nur HLS oder beide anbieten sollen. Aus dem Relay-Register werden Konfigurationsdateien erzeugt, die von Ansible gelesen und in haproxy/icecast-Config umgesetzt werden.

Unerwartet geschlossene Verbindungen auf *.alb.c3voc.de

Es gibt ein Problem mit dem Router (Juniper?) im Alboin, welches dellinger.alb.c3voc.de und dessen VMs, insbesondere live.alb.c3voc.de und lb.alb.c3voc.de betrifft.Dagegen hilft die erratischen ICMP-Messages mit iptables zu unterdrücken:

sudo iptables -I INPUT 1 -s 185.106.84.33/32 -p icmp -m icmp --icmp-type 3 -j DROP

<note important>Diese Regel ist derzeit auf den og. 3 Hosts in Betrieb, aber noch nicht persistiert oder im cm!→ https://todo.mazdermind.de/b/9a2QiHPpBnskhrgia/34c3/8N9PQpBG8Zjt8ttgt</note>