Hulpartikel overzicht

/ Building an RTMP re-streaming cluster with NGINX using Heat autoscaling for our Christmas tree project

Ongeveer een week geleden bespraken we hoe we moesten omgaan met het in en uitschakelen van de bewakingsschermen. Dit is een saaie repetitieve taak, dus we waren het er allemaal over eens, het zou zo snel mogelijk moeten worden geautomatiseerd.

Ik heb snel een oude rasperry-pi gevonden. Er deden nog wat collega's mee en we begonnen het project uit te breiden. Iedereen bracht kerstdecoraties, een stroomverdeler, domotica-sets en veel kerstverlichting mee. De volgende avond kreeg onze manager hier lucht van en gaf onmiddellijk een inkooporder om een ​​kerstboom te gaan kopen. Ik kocht het dezelfde avond en zette het de volgende ochtend op. Project Kerstmis was geboren!

De OPS-team manager, Rosco Nap, bouwde een API in GO die SNMP-opdrachten naar de PDU verzendt. Bjarn Bronsveld, onze stagiair, maakte binnen enkele minuten een eerste versie van de twitterbot in NodeJS, zodat de boom zou reageren op tweets die het woord cloud bevatten (wat trouwens veel tweets zijn ...). Het was toen dat we ons realiseerden dat we dit idee via een videostream met de rest van de wereld moesten delen. Natuurlijk is dit al vele malen eerder gedaan, maar wat maakt het uit. Het is leuk om het goed te doen.

Requirements

Omdat we graag groot denken (en bijna onbeperkte middelen tot onze beschikking hebben), heb ik besloten dat we onze eigen re-streaming cluster moeten bouwen.
Enkele vereisten waren;

  • Het belangrijkste is dat het op ons kantoor draait, dus het moet veilig zijn. Zelfs als het zich in een afzonderlijk netwerk bevindt.
  • We kunnen onze interne mac mini die de video vastlegt niet blootleggen
  • De mac mini zal de stream naar een externe server pushen die de stream opnieuw zal verspreiden
  • We willen de GO API niet extern laten zien
  • Dat is waar de NodeJS twitter bot komt
  • Voor het geval dat moet het grote hoeveelheden bezoekers kunnen verwerken
  • Vanzelfsprekend, maar het moet high available zijn
  • Het zou automatisch moeten schalen, afhankelijk van de belasting
  • Het moet een webinterface bevatten voor eenvoudig afspelen

The design

We zouden geen project willen starten zonder een goed ontwerp?
(Maak je geen zorgen, we hebben geen PID geschreven)

Naast het cluster hebben we 4 hoofdcomponenten;

  • De NodeJS twitter bot monitort twitter voor de geselecteerde hashtags of trefwoorden
  • De GO API die de PDU-stopcontacten bestuurt via SNMP
  • Open Broadcaster Software op een Mac, streaming naar onze NGINX Streaming backend
  • De NGINX streaming backend. waardoor streams vanuit ons kantoor kunnen worden gepubliceerd, die stream naar youtube kan worden gepusht en kan worden gespeeld vanuit het cluster

We hebben ervoor gekozen om twee floating ip's te gebruiken op twee afzonderlijke LBaaS-instanties. We geven ze allebei op in het DNS-record om een ​​eenvoudige vorm van HA via DNS te krijgen.


Dit komt omdat heat-updates enigszins storend kunnen zijn als ze niet zorgvuldig worden uitgevoerd. De LBaaS-instances draaien altijd HA bij CloudVPS zonder dat je iets hoeft te doen. Als u de ene echter verwijdert of verkeerd configureert, wordt de andere ook verwijderd of verkeerd geconfigureerd ...

Dezelfde problemen doen zich voor bij de autoscaling-groepen (groepen van VPS's). Als je ze verkeerd configureert met heat, gaat alles naar, uhm, naar beneden.

Building the cluster with heat

Dus nu hadden we een backend waar we de stream uit kunnen halen. Het enige dat we nu nodig hadden, was een aantal instanties die de frontend konden verwerken en de RTMP-stream opnieuw streamen. Alle scripts die we hebben gebruikt voor het autoscaling-cluster zijn beschikbaar op onze Github.

Unattended installation met een user data script

We zijn begonnen met het maken van een gebruikersgegevensscript voor openstack. Kortom, het is een bash-script dat wordt uitgevoerd wanneer een instantie voor het eerst wordt gestart.
Op die manier zullen onze instanties statusloos zijn en geen handmatige configuratie vereisen. Dit is een vereiste voor het autoscaling-gedeelte.
Als u het exemplaar handmatig zou moeten configureren, werkt automatisch schalen niet.

Als u kijkt naar het user data script ziet u dat deze een aantal stappen doorloopt;

  • De apt-cache bijwerken en de vereiste packages installeren
  • Downloaden, uitpakken en bouwen van een versie van NGINX die de RTMP-module bevat
  • Downloaden van de frontend html. De onze is vrij eenvoudig, maar je kunt je app natuurlijk uit git halen.
  • Het NGINX-configuratiebestand maken
  • NGINX opnieuw opstarten om de configuratie toe te passen

Defining heat resources

In 00_registry.yaml hebben we bepaald welke bronnen we zullen gebruiken in onze master.yml. Dit omvat het definiëren van de LBaaS-bron en twee instances.

Eén instance met een zwevend IP-adres voor onze implementatieserver. De implementatieserver wordt alleen gebruikt als hulpmiddel voor probleemoplossing, maar kan ook worden gebruikt om nieuwe commits van uw toepassing naar de app-servers te implementeren.
Het andere type omvat de app-instanties in een LBaaS-pool. Dit zorgt ervoor dat LBaaS weet waar het verkeer naartoe kan doorsturen zodra het aantal instances is geschaald.

Putting it all together

Eindelijk hebben we het allemaal in elkaar gezet in 01_master.yaml. We zijn begonnen met het definiëren van alle parameters die nodig zijn om het autoscaling-cluster te implementeren. We hebben enkele standaardwaarden gedefinieerd, die mogelijk niet voor u werken. Maak je geen zorgen, je kunt ze ook wijzigen wanneer je de opdracht uitvoert. De parameters hebben allemaal beschrijvingen, of zijn vrijwel vanzelfsprekend.

Daarna is het tijd om resources te creëren. We zijn begonnen met het maken van security groups die alleen de noodzakelijke poorten toestaan.
We kiezen ervoor om het interne netwerk niet verder te beveiligen. Als uw gegevens gevoeliger zijn dan een openbaar beschikbare RTMP-stream, wilt u misschien meer beveiligingsgroepen toevoegen.
Hierna volgen het interne netwerk, het subnet en de router, zodat alle instances intern verbinding met elkaar kunnen maken. Alle instances kunnen nu worden bereikt via de LBaaS-instances die we vervolgens maken. We gebruiken hetzelfde brontype dat we eerder hebben gedefinieerd met verschillende parameters.

Nu we beveiligingsgroepen, een netwerk en loadbalancers hebben, is het tijd om de werkelijke instances te maken. We maken de instances door ze in een AutoScalingGroup te nesten en de gemeenschappelijke parameters te definiëren. We vertellen welke poort wordt toegevoegd aan welke LBaaS-pool. Dit zorgt ervoor dat aan elke instance die wordt gestart via de AutoScalingGroup een http-, https- en RTMP-poort wordt toegevoegd aan de LBaaS-instance. OpenStack zorgt voor alle saaie dingen zoals naamgeving en IP-nummering.

Zonder iets toe te voegen zou OpenStack Heat een set van instanties creëren die nooit up of down zou scalen. Daarvoor moeten we een up scaling en een down scaling beleid toevoegen. In dit cluster hebben we gedefinieerd dat het beleid voor het up scalen en down scalen telkens 1 instance toevoegt of verwijdert.

Het beleid wordt geactiveerd door een Ceilometer-alarm (het OpenStack-meetcomponent). Het door ons gedefinieerde alarm is een CPU-gebruiksalarm. Als het gebruik 80% bereikt, wordt een extra exemplaar uitgezet. Als het onder de 15% komt, wordt er een verwijderd.

We hebben dit nog niet getest, dus jullie moeten allemaal bewijzen of dit voldoende is voor onze workload ;)

Finally we deploy a single instance with an floating IP that will function as a deploy server and an entrypoint for us to debug the autoscaling cluster.

Challenges we encountered

Vooral het integreren van de RTMP-stroom in een webinterface (zonder flash natuurlijk) is een behoorlijke uitdaging gebleken.
RTMP speelt niet leuk met HTML5. Onze collega Huib is erin geslaagd om een ​​transcoder naar HLS op te zetten en die te integreren in een html5-pagina. Transcoding naar HLS introduceert veel vertraging vanwege het ontwerp van HLS dat de videostream buffert in downloadbare chucks.

Naast de vertraging zagen we veel (mobiele) browsers die de HTML 5-videotag niet volledig  ondersteunden.
Dus, aangezien we ops jongens zijn, hebben we besloten om niet te proberen dat zelf te bouwen. In plaats daarvan hebben we de stream naar YouTube doorgestuurd en hun speler geïntegreerd.

We hebben het RTMP-streamingcluster behouden, omdat we dat kunnen. Ook hosten de NGINX-instanties de webapp met de YouTube-stream.

Wannahaves for version 2.0

  • Laat de API en de twitterbot op een HA-setup draaien. De API kan eenvoudig met 2 pi's HA worden gemaakt en bewaard worden. De twitterbot zou een grotere uitdaging zijn, omdat deze twee keer zou worden geactiveerd als we hem twee keer uitvoeren. Dit vereist zoiets als Corosync / Pacemaker
  • Het moet een SSL-certificaat bevatten ( shame on me)
  • De resources moeten worden verdeeld over beschikbaarheidszones (dit is inbegrepen, maar werkt nog niet)
  • Ondersteuning voor ipv6 toevoegen
  • Loadtest met jmeter of tsung

How can we see this amazing christmas tree?

Ga naar http://kerstcloud.nl/ of open rtmp: //kerstcloud.nl/live/cloudvpstree met je favoriete speler zoals VLC als netwerkstream voor een nog lagere latentie!

CloudVPS wenst iedereen prettige kerstdagen en een gelukkig nieuwjaar!

P.s.Tot op de dag van vandaag werkt de IR-zender voor de tv nog steeds niet ...

Deel dit artikel