Monitoring van netwerkpakketverlies en latentie op Roblox Cloud

Het Roblox Network Engineering-team onderhoudt een groot, snelgroeiend netwerk met datacenters en Point of Presence (POP)-locaties verspreid over de hele wereld. Het leveren van een geweldige gebruikerservaring op het Roblox-platform is afhankelijk van de prestaties en betrouwbaarheid van dit netwerk. Het is van cruciaal belang dat netwerkbeheerders problemen in het netwerk kunnen opsporen en oplossen, en inzicht hebben in de netwerkprestaties. Netwerkmonitoring wordt doorgaans gerealiseerd door periodiek apparaatstatistieken, foutstatistieken en syslogs te verzamelen en deze op te slaan in een tijdreeks- of logdatabase. De gegevens worden verzameld met een push- of pull-model met behulp van standaardprotocollen zoals SNMP, Netconf, Rest API's of Streaming Telemetry.

Het opsporen van netwerkstoringen uitsluitend via apparaattelemetrie heeft verschillende tekortkomingen, aangezien het een passieve monitoringtechniek is. Het is afhankelijk van het vermogen van de netwerkknooppunten om afwijkende situaties te identificeren en te rapporteren zodra deze zich voordoen. Het apparaat rapporteert de gegevens mogelijk niet altijd terug of, in sommige gevallen, zijn mogelijk niet alle statusgegevens beschikbaar voor de gebruikelijke telemetrieverzamelmethoden. Bovendien kunnen netwerkapparaten soms foutieve gegevens verstrekken of verkeer stilzwijgend blokkeren. Een belangrijke beperking van apparaattelemetrie is dat deze zeer weinig inzicht biedt in de end-to-end-bereikbaarheid, pakketverlies en latentiegegevens van het netwerk.

Een uitstekende manier om een netwerk actief te monitoren is door regelmatig gesynthetiseerde probes over een mesh te verzenden, zoals weergegeven in de onderstaande afbeeldingen.

Bij het oplossen van storingen in de productie krijgen netwerkbeheerders vaak vragen als: "Verliest het netwerk pakketten?" of "Is er een aanhoudende netwerkstoring die de connectiviteit van de dienst beïnvloedt?" Om dit soort vragen te kunnen beantwoorden zonder toegang tot historische gegevens over pakketverlies en latentie, zouden ze een groot aantal verbindingen en knooppunten binnen het netwerk moeten onderzoeken.

Ontwerpen van een betrouwbaar en schaalbaar netwerkmesh-monitoringsysteem

Om een black-box-netwerkmonitoringsysteem effectief te laten zijn bij het detecteren van pakketverlies of pieken in de latentie, is continu onderzoek van verschillende delen van het netwerk vereist. Datacenternetwerken gebruiken alle verbindingen tussen knooppunten voor gebruikersverkeer. Productienetwerkapparaten draaien BGP en verdelen het verkeer over meerdere paden met gelijke kosten. Veranderingen in de netwerktopologie worden onder normale omstandigheden meestal binnen enkele seconden weerspiegeld door updates van de routeringstabel. Om een nauwkeurige meting van netwerkpakketverlies te krijgen, moeten de testprobes zoveel mogelijk paden afleggen die alle netwerkknooppunten en verbindingen bestrijken. Bij een groot netwerk, zoals het onze, dat zich uitstrekt over meerdere locaties wereldwijd, is het niet schaalbaar om tussen elk paar knooppunten of racks te meten. De duurzamere oplossing die we hebben gekozen, zonder in te boeten aan zichtbaarheid, is het meten van een N²-mesh over de racks binnen elke locatie, samen met een andere N²-mesh over alle locaties.

Waarmee testen we het netwerk?

De testprobes moeten live verkeer emuleren dat door een productienetwerk gaat. Het meeste verkeer op ons netwerk is TCP, UDP of HTTP, en elk van deze kan potentieel worden gebruikt voor probes. Een van de problemen met TCP-probing is dat het niet licht genoeg is om te schalen naar het aantal verbindingen dat nodig is om een groot netwerk te monitoren. Een ander nadeel van TCP is dat de ingebouwde flow-control en op sliding windows gebaseerde transmissies resulteren in een variabele probe-transmissiesnelheid, wat niet ideaal is voor het kwantificeren of detecteren van kortstondige pakketverliezen. ICMP, dat wordt gebruikt door ping en traceroute, is doorgaans snelheidsbeperkt op de servers of netwerkknooppunten. Dit beperkt de totale snelheid van ICMP-probes die kunnen worden gebruikt. HTTP-verzoeken bevinden zich hoger in de applicatielaag en zijn afhankelijk van factoren buiten het netwerk, zoals de prestaties van de server of de applicatie. HTTP voegt een extra variabele factor toe aan de resultaten die moeilijk te isoleren is. Het doel van dit systeem is het monitoren van de prestaties van de onderliggende netwerkinfrastructuur die voornamelijk op OSI-lagen 4 en lager opereert. Om deze redenen hebben we gekozen voor UDP-probes, naast het feit dat dit het primaire transportlaagprotocol op ons netwerk is.

Van waaruit voeren we de probes uit?

Een manier om een hoge totale probe-frequentie te bereiken en ook een groot aantal netwerkpaden te bestrijken, is door zoveel mogelijk rekenknooppunten te gebruiken om de probes te verzenden. Dit heeft twee voordelen: het helpt de belasting te verdelen over de systemen die de probes genereren, en het vergroot het aantal netwerkpoorten dat ze vervoert. Dit vereist echter een agent die zeer stabiel is en zo min mogelijk van de bronnen van het hostsysteem gebruikt. Tegelijkertijd moet de agent in staat zijn om pakketverlies en latentie op meerdere paden nauwkeurig te meten zonder te worden beïnvloed door schommelingen in het CPU-, geheugen- of I/O-gebruik op het hostsysteem. De agent moet voortdurend dit delicate evenwicht tussen lichtgewicht en hoge prestaties in stand houden.

Hoe meten we netwerkverlies en latentie?

Dit lijkt misschien een triviale berekening over een enkele stream van probes, maar er zijn enkele uitdagingen die zich op schaal voordoen en die niet meteen voor de hand liggen. Om op te schalen naar zo'n groot netwerk, moet de agent snel en nauwkeurig het aantal verzonden (Tx) en ontvangen (Rx) pakketten met tijdstempels over talrijke streams tegelijkertijd berekenen. Het is belangrijk dat statistieken over netwerkverlies geen pakketten bevatten die verloren gaan op de host waarop de agent draait wanneer de CPU bezet is of de netwerkbuffers overlopen. Netwerklatentie moet worden berekend op basis van de totale tijd dat de probes op de kabel of tussenliggende netwerkknooppunten waren, terwijl de tijd die wordt besteed aan wachten in I/O-buffers en het agentproces in afwachting van OS-planning buiten beschouwing wordt gelaten.

Het Ping Mesh-systeem van Roblox

De behoefte aan black-box-monitoring van netwerkverlies en latentie bestaat al sinds de groei van publieke en private cloudinfrastructuur. Het bleek moeilijk om een kant-en-klare oplossing te vinden die kan worden geschaald naar ons grote netwerk. Verschillende grote cloudoperators en leveranciers van netwerktools hebben hun eigen oplossingen ontworpen om netwerkverlies en latentie te monitoren. We hebben een aantal openbaar beschikbare tools uitgeprobeerd, maar stuitten op problemen met stabiliteit en schaalbaarheid, terwijl we slechts beperkt inzicht kregen in de netwerkprestaties. Dit bracht ons ertoe ons eigen mesh-monitoringsysteem te bouwen, dat een betere detectie van laagfrequente fouten biedt met lage overhead. Enkele hoogtepunten van ons systeem zijn:

• We hebben gekozen voor Go om alle componenten van ons systeem te implementeren en dat heeft bijgedragen aan het bereiken van een hoog prestatieniveau met minimaal gebruik van systeembronnen.
• Onze agents zijn zeer stabiel en kunnen op een breed scala aan productiehosts draaien, inclusief hosts die kritieke diensten op het Roblox-platform uitvoeren, zoals verkeers-, caching- en applicatieservers.
• De agent is geoptimaliseerd om pakket-I/O-bewerkingen te bundelen met Go-wrapperfuncties bovenop de Linux-systeemaanroepen sendmmsg() en recvmmsg(), waardoor hij een hoge frequentie van probes kan verzenden met lage overhead. Elke agent in onze implementatie verzendt gelijktijdig probes naar maximaal 100 andere hosts, met een snelheid van 100 pakketten per seconde (PPS). De agent verzendt elke seconde pakketbursts naar elke bestemming.
• Probes bevatten verschillende Type-of-Service (TOS)-veldwaarden in de IP-header naar elke bestemming en worden afzonderlijk in aanmerking genomen voor pakketverlies en latentie over het netwerk. Elke pakketburst bevat een mix van meerdere TOS-waarden naar elke andere bestemming. Dit helpt bij het monitoren van de netwerkprestaties voor verschillende Quality-of-Service (QoS)-klassen.
• De agent kan netwerkverliezen detecteren tot 1 op 6000 pakketten per minuut op elk probe-pad. Pakketverlies binnen de kern of rand van het netwerk dat minder dan 1 seconde duurt, kan worden gedetecteerd, zoals tijdens een BGP-flap.
• Grafieken van probe-pakketverlies komen overeen met die van foutpercentages van netwerkapparaatinterfaces wanneer de fouten verantwoordelijk zijn voor het verlies. We hebben bugs in het netwerk kunnen ontdekken die verkeer in een black hole doen verdwijnen en die moeilijk te detecteren zijn.
• De agents gebruiken NIC-kernel-leestijdstempels om een hoge nauwkeurigheid te bereiken bij het meten van netwerklatentie. Er kan een consistente round-trip-latentie binnen de site van 50–100 microseconden worden gemeten, waarbij de planninglatentie van het host-besturingssysteem en de afwijking van de netwerkklok worden uitgesloten.
• Laag CPU-gebruik en geheugenbeslag. De agent gebruikt minder dan 25% van een enkele core bij piekverzend- en ontvangstsnelheden (elk 5 kpps). De meeste geïmplementeerde agents gebruiken slechts ongeveer 5% van een core. Er is slechts 10 MB heap-geheugen nodig om de Tx- en Rx-pakketbuffers en tellers van de agent te beheren. Wanneer het netwerk groeit, kunnen we verticaal of horizontaal schalen door de limieten aan te passen of extra agents toe te voegen.
• De agent ondervindt zelden hinder wanneer het hostsysteem onder druk staat. We hebben nauwkeurige resultaten verkregen, zelfs toen de CPU-belasting van de host bij verschillende gelegenheden 99% benaderde.
• Er wordt telemetrie verzameld van elke agent om de status ervan te controleren. Agenten kunnen problematische situaties identificeren, zoals wanneer het hostsysteem opnieuw opstart, wanneer het agentproces opnieuw start of wanneer pakketten verloren gaan als gevolg van overvolle socketbuffers.

De agents worden met Chef geïmplementeerd op een breed scala aan serverclusters om een groot aantal knooppunten te behouden die deelnemen aan het testen van het netwerk. Het agent-binaire bestand wordt uitgevoerd en beheerd met systemd op Linux, zodat het automatisch opnieuw wordt gestart na een herstart van de host of een upgrade van de agent. De mesh-planner detecteert en past streams dynamisch aan wanneer dat nodig is, wanneer een van de agents uitvalt of er nieuwe bijkomen. Onze scheduler-applicatie peilt periodiek de apparaatinventaris en een service discovery-systeem om nieuwe agents en de serverstatus te detecteren, voordat doelen worden toegewezen voor Intra-Pod-, Intra-Site- en Inter-Site-probing. Er wordt een berichtenbus gebruikt om de lijst met doelhosts door te geven aan elke agent die testprobes verzendt. Individuele streams die beginnen of eindigen bij een specifiek rack, worden verdeeld over alle beschikbare agents binnen dat rack. Dit helpt ons om een groot aantal paden met gelijke kosten binnen onze netwerkstructuur te gebruiken, zoals te zien is in de onderstaande afbeeldingen.

We zijn begonnen met 150 agents bij onze eerste implementatie en hebben dit nu met succes vertienvoudigd. Het mesh-netwerk bestrijkt onze backbone en verbindt 25 locaties verspreid over de hele wereld. Op een van onze primaire datacenterlocaties hebben we een intra-site mesh die meer dan 200 racks bestrijkt met ongeveer 33.000 streams, wat neerkomt op een probe-snelheid van 1,65 Mpps. Elk rack ontvangt 5–10 kpps aan probes van andere racks. De scheduler-applicatie berekent en verdeelt meer dan 35.000 doelen gelijkmatig over al onze agents op verschillende locaties.

Gegevensverzameling en visualisatie

We draaien een aparte collector-applicatie die periodiek alle Ping Mesh-agents pollt voor resultaten over pakketverlies en latentie. Deze data wordt automatisch gefilterd om ongeldige resultaten uit te sluiten op basis van de health-statussen die lokaal bij de collector in de cache zijn opgeslagen. We sluiten bijvoorbeeld resultaten uit van een agent die draait op een server die niet reageerde op health checks of een server die net opnieuw is opgestart. Onze collector kan synchroon resultaten van meer dan 1.500 knooppunten opvragen en filteren en de gegevens vervolgens binnen 2 seconden opnemen in een tijdreeksdatabase.

Zowel geaggregeerde als per stream resultaten worden gevisualiseerd met behulp van Grafana-dashboards. Heatmap-rasters kunnen lastig te gebruiken zijn bij grote datasets, met name voor onze grote datacenterlocatie. We gebruiken een Prometheus topk()-query om de paden met het hoogste individuele pakketverlies te tonen uit duizenden resultaten, wat meestal maar een handvol is. De resultaten worden uitgebreid getoetst aan de hand van de gezondheidsstatistieken van agents en hostsystemen die regelmatig door de collector worden opgevraagd. Dit geeft ons een hoge mate van vertrouwen in elk afzonderlijk resultaat, ongeacht hoe groot de variaties in pakketverlies zijn. De afzonderlijke resultaten kunnen ons, wanneer ze samen worden bekeken, aanwijzingen geven over waar de netwerkstoring zich heeft voorgedaan. Hieronder worden enkele voorbeelden weergegeven van pakketverlies dat door ons mesh-monitoringsysteem is opgemerkt.

Samenvatting en volgende stappen

Ons Ping Mesh-systeem is een krachtig hulpmiddel voor het Network Engineering-team om end-to-end pakketverlies en latentie te monitoren. Deze gegevens kunnen worden gebruikt om direct antwoord te geven op de vraag: "Verliest het netwerk pakketten?" Onze ervaring leert dat grote netwerkincidenten die gevolgen hebben voor klanten, meestal worden gedetecteerd en gemeld door het telemetriebewakingssysteem van het apparaat. Problemen met netwerkbuffering of geïsoleerde black-holing van verkeer die weinig impact hebben maar potentieel problematisch zijn, worden met dit systeem aan het licht gebracht.

Ons systeem kan ook inzicht bieden in de algehele betrouwbaarheid van het Roblox Cloud Network. Op een van onze grote datacenterlocaties hebben we meer dan 100 miljoen probes per minuut die de gezondheid van het netwerk monitoren en we komen zelden uit op een pakketverlies van meer dan 50 per minuut. Dit duidt op een betrouwbaarheid van ongeveer 6 9-en (99,9999%) van ons datacenternetwerk. Heel vaak wordt er geen pakketverlies waargenomen onder de 100 miljoen pakketten. Wanneer er een aanzienlijke hoeveelheid pakketten verloren gaat, biedt dit systeem inzicht in waar en hoe lang het pakketverlies plaatsvond. Een engine voor automatische herstelmaatregelen herstelt het netwerk zelf en voorkomt dat het gebruikersverkeer verdere uitval ondervindt door het via een ander pad in het netwerk om te leiden. Het netwerkteam bij Roblox heeft een uiterst betrouwbaar cloudnetwerk opgebouwd.

In de toekomst zijn we van plan een analyse-engine te gebruiken om gegevens uit apparaattelemetrie, syslogs en andere datasets te correleren. Vervolgens zijn we van plan dat te vergelijken met Ping Mesh-gegevens om te helpen vaststellen waar de netwerkstoring plaatsvond. Naarmate het cloudnetwerk van Roblox blijft uitbreiden en evolueren, zijn we van plan onze testmechanismen te verbeteren door IPv6 en jumbo frames op te nemen, terwijl we meer agents toevoegen om de dekking tussen sites te vergroten.