events:34c3:cdn

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
events:34c3:cdn [2017/12/13 21:18] – mazdermindevents:34c3:cdn [2018/07/19 01:55] (current) – meise
Line 1: Line 1:
 = 34C3 CDN = 34C3 CDN
 +<bootnote important>Diese Dokumentation galt für den 34C3. Für die Zeit danach, siehe [[:cdn|]].</bootnote>
 +
 == Architektur == Architektur
 Die CDN-Kaskade hat 4 Stufen Die CDN-Kaskade hat 4 Stufen
Line 14: Line 16:
   * minion1: s1   * minion1: s1
   * minion2: s2   * minion2: s2
-  * minion3: s3 & s4+  * minion3: s3 
 +  * minion-muc: s4
  
 Diese Verteilung wird über Host-Attribute im cm geregelt: https://github.com/voc/cm/blob/master/ansible/event#L41-L44. Diese Verteilung wird über Host-Attribute im cm geregelt: https://github.com/voc/cm/blob/master/ansible/event#L41-L44.
Line 50: Line 53:
 == Testdaten == 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 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 ''sX_native_hd'' & 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
 +
 +=== WebM Multi-Qualität + Multi-Lang
 +* http://cdn.c3voc.de/dash/sX/manifest.mpd
 +
 +=== 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:
 +<code>
 +sudo systemctl stop transcode_sX.target 
 +sudo systemctl disable transcode_sX.target 
 +</code>
 +
 +auf live.ber.c3voc.de:
 +<code>
 +sudo systemctl stop fanout_sX.target
 +sudo systemctl disable fanout_sX.target
 +
 +screen -rd source-for-teststream
 +:quit
 +</code>
 +</note>
 +
  
 == TLS == 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. 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.+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: 
 +<code> 
 +./ansible-playbook-keepass -u voc --become --become-method=sudo -i cdn site.yml --tags letsencrypt 
 +</code>
  
 == Relay-Register == 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)+Das Relay-Register ist hier zu finden: https://c3voc.de/relayregister/ - 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. 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.
  
 +== Externe Quellen
 +Die Streams der Externe Quellen werden komplett über eine eigene Kiste angewickelt (''dawaschtel.lan.c3voc.de''). Dieser Server übernimmt dann sowohl das ingesting als auch transcoding, fanout und ist user-facing relay. Der Server verfügt über eine 10GE-Anbindung an das Congessnetz und ausreichend CPU-Kapazität.
 +
 +Die Scripte dazu werden aus den gleichen Templates wie die der Haupträume erstellt, aber mit weniger Audiospuren und ohne Slide-Stream.
 +Alle Fanout und Transcoding-Scripte werden per cm angelegt. Zusätzlich wird jeweils ein Ingesting-Script angelegt das aber **by-default deaktiviert** ist. Das ingesting mus manuell überprüft und ggf. angepasst werden. Dazu werden auf dem og. Server Dateien in der Art von `/opt/transcoder/scripts/sfsfe_ingesting.sh` angelegt. Die dazugehörigen systemd-units sind by-default aktiv und sollten innerhalb einiger Sekunden mit dem einlesen und transcoden beginnen.
 +
 +Folgende weiterführende Dokumentation im Wiki:
 +* Anweisungen und Dokumentation für Externe Betreiber: https://c3voc.de/wiki/events:34c3:cdn:external-sources
 +* InterneDokumentation der Abstimmung mit den Betreibern: https://c3voc.de/wiki/intern:events:34c3:cdn:external-sources
 +
 +== 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:
 +<code>
 +sudo iptables -I INPUT 1  -s 185.106.84.33/32 -p icmp -m icmp --icmp-type 3 -j DROP
 +</code>
 +
 +Die Regel ist jetzt auch mit allen anderen IP-Adressen, von denen die Juniper solche Pakete senden könnte im CM.
  • events/34c3/cdn.1513196289.txt.gz
  • Last modified: 2017/12/13 21:18
  • by mazdermind