Monitoraggio della perdita di pacchetti di rete e della latenza su Roblox Cloud

Il team di ingegneria di rete di Roblox gestisce una rete ampia e in rapida crescita con data center e siti POP (Point of Presence) distribuiti in tutto il mondo. Offrire un'ottima esperienza utente sulla piattaforma Roblox dipende dalle prestazioni e dall'affidabilità di questa rete. È fondamentale che gli operatori di rete siano in grado di risolvere e individuare i problemi nella rete e abbiano visibilità sulle prestazioni della rete. Il monitoraggio della rete viene generalmente effettuato raccogliendo periodicamente statistiche sui dispositivi, metriche di errore e syslog, e memorizzandoli in un database di serie temporali o di log. I dati vengono raccolti con un modello push o pull utilizzando protocolli standard come SNMP, Netconf, API Rest o Streaming Telemetry.

Il rilevamento dei guasti di rete esclusivamente tramite la telemetria dei dispositivi presenta diversi limiti, poiché si tratta di una tecnica di monitoraggio passiva. Dipende dalla capacità dei nodi di rete di identificare e segnalare situazioni anomale non appena si verificano. Il dispositivo potrebbe non riportare sempre i dati o, in alcuni casi, potrebbe non esporre tutte le sue statistiche di integrità ai consueti metodi di raccolta della telemetria. Inoltre, i dispositivi di rete possono talvolta fornire dati errati o bloccare silenziosamente il traffico. Un limite importante della telemetria dei dispositivi è che offre pochissima visibilità sulla raggiungibilità end-to-end, sulla perdita di pacchetti e sulle statistiche di latenza della rete.

Un ottimo modo per monitorare attivamente una rete consiste nel trasmettere regolarmente sonde sintetizzate attraverso una rete mesh, come illustrato nelle figure sottostanti.

Durante la risoluzione dei problemi relativi alle interruzioni di produzione, agli operatori di rete vengono spesso poste domande del tipo: "La rete sta perdendo pacchetti?" o "C'è un guasto di rete in corso che influisce sulla connettività del servizio?". Per rispondere a questo tipo di domande senza avere accesso ai dati storici sulla perdita di pacchetti e sulla latenza, dovrebbero esaminare un ampio insieme di collegamenti e nodi all'interno della rete.

Progettazione di un sistema di monitoraggio della rete mesh affidabile e scalabile

Affinché un sistema di monitoraggio di rete di tipo "black box" sia efficace nel rilevare la perdita di pacchetti o i picchi di latenza, è necessario un monitoraggio continuo su diverse parti della rete. Le reti dei data center utilizzano tutti i collegamenti tra i nodi per il traffico degli utenti. I dispositivi di rete di produzione eseguono il BGP e bilanciano il carico del traffico su più percorsi a costo uguale. In circostanze normali, le modifiche alla topologia di rete si riflettono solitamente in pochi secondi tramite gli aggiornamenti della tabella di routing. Per ottenere una misurazione accurata della perdita di pacchetti di rete, le sonde di test dovrebbero percorrere il maggior numero possibile di percorsi, coprendo tutti i nodi e i collegamenti di rete. Con una rete di grandi dimensioni, come la nostra, che si estende su più siti in tutto il mondo, non è scalabile eseguire sondaggi tra ogni coppia di nodi o rack. La soluzione più sostenibile che abbiamo scelto, che non compromette il livello di visibilità, consiste nel sondare una mesh N² tra i rack all'interno di ciascun sito insieme a un'altra mesh N² tra tutti i siti.

Con cosa sondiamo la rete?

Le sonde di test dovrebbero emulare il traffico live che attraversa una rete di produzione. La maggior parte del traffico sulla nostra rete è TCP, UDP o HTTP, e ciascuno di questi potrebbe potenzialmente essere utilizzato per le sonde. Uno dei problemi del test TCP è che non è abbastanza leggero per scalare al numero di connessioni necessarie per monitorare una rete di grandi dimensioni. Un altro inconveniente del TCP è che il controllo di flusso integrato e le trasmissioni basate su finestre scorrevoli determinano una velocità di trasmissione delle sonde variabile, il che non è l'ideale per quantificare o rilevare cadute momentanee di pacchetti. L'ICMP, utilizzato da ping e traceroute, è tipicamente limitato in termini di velocità sui server o sui nodi di rete. Ciò limita la velocità aggregata delle sonde ICMP che possono essere utilizzate. Le richieste HTTP si trovano più in alto nel livello applicativo e dipendono da alcuni fattori esterni alla rete, come le prestazioni del server o dell'applicazione. L'HTTP aggiunge un ulteriore fattore variabile ai risultati che è difficile da isolare. L'obiettivo di questo sistema è monitorare le prestazioni dell'infrastruttura di rete sottostante che opera principalmente ai livelli OSI 4 e inferiori. Abbiamo scelto le sonde UDP per questi motivi, oltre al fatto che è il protocollo principale del livello di trasporto sulla nostra rete.

Da dove effettuiamo le sonde?

Un modo per ottenere un'elevata frequenza di sondaggio aggregata e coprire anche un gran numero di percorsi di rete è quello di utilizzare il maggior numero possibile di nodi di calcolo per trasmettere i sondaggi. Ciò presenta due vantaggi: aiuta a distribuire il carico sui sistemi che generano i sondaggi e amplia il numero di porte di rete che li trasportano. Tuttavia, ciò richiede un agente molto stabile e che consumi il meno possibile le risorse del sistema host. Allo stesso tempo, l'agente dovrebbe essere in grado di misurare con precisione la perdita di pacchetti e la latenza su più percorsi senza essere influenzato dalle oscillazioni nell'utilizzo della CPU, della memoria o dell'I/O sul sistema host. L'agente deve mantenere costantemente questo delicato equilibrio tra leggerezza e prestazioni elevate.

Come misuriamo la perdita di rete e la latenza?

Questo può sembrare un calcolo banale su un singolo flusso di sonde, tuttavia, su larga scala sorgono alcune sfide che non sono immediatamente evidenti. Per scalare su una rete così estesa, l'agente deve calcolare in modo veloce e accurato il conteggio dei pacchetti trasmessi (Tx) e ricevuti (Rx) con timestamp su numerosi flussi simultaneamente. È importante che le metriche di perdita di rete non includano i pacchetti persi sull'host che esegue l'agente quando la sua CPU è occupata o i suoi buffer di rete sono pieni. La latenza di rete deve essere calcolata in base al tempo totale in cui le sonde sono state sul cavo o sui nodi di rete intermedi, escludendo il tempo trascorso in attesa nei buffer I/O e il processo dell'agente in attesa della pianificazione del sistema operativo.

Il sistema Ping Mesh di Roblox

La necessità di monitorare la perdita di rete e la latenza tramite black box esiste sin dalla crescita delle infrastrutture cloud pubbliche e private. È risultato difficile trovare una soluzione pronta all'uso in grado di adattarsi alla nostra vasta rete. Diversi grandi operatori cloud e fornitori di strumenti di rete hanno progettato le proprie soluzioni per monitorare la perdita di rete e la latenza. Abbiamo provato alcuni strumenti disponibili al pubblico, ma abbiamo riscontrato problemi di stabilità e scalabilità, ottenendo al contempo solo una visibilità limitata sulle prestazioni di rete. Questo ci ha portato a costruire il nostro sistema di monitoraggio mesh, che ha fornito un migliore rilevamento degli errori a bassa frequenza con un overhead ridotto. Alcuni dei punti salienti del nostro sistema sono:

• Abbiamo scelto Go per implementare tutti i componenti del nostro sistema e questo ci ha aiutato a raggiungere un alto livello di prestazioni utilizzando risorse di sistema minime.
• I nostri agenti sono altamente stabili e possono essere eseguiti su un'ampia gamma di host di produzione, compresi quelli che eseguono servizi critici sulla piattaforma Roblox come traffico, caching e server applicativi.
• L'agente è ottimizzato per raggruppare le operazioni di I/O dei pacchetti con funzioni wrapper Go sulle chiamate di sistema sendmmsg() e recvmmsg() di Linux, il che gli consente di trasmettere un'elevata frequenza di sonde con un basso overhead. Ogni agente nella nostra distribuzione trasmette simultaneamente sonde a un massimo di 100 altri host, a una velocità di 100 pacchetti al secondo (PPS). L'agente trasmette raffiche di pacchetti ogni secondo a ciascuna destinazione.
• Le sonde trasportano valori diversi del campo TOS (Type of Service) nell'intestazione IP verso ciascuna destinazione e vengono conteggiate separatamente per la perdita di pacchetti e la latenza sulla rete. Ogni burst di pacchetti include una combinazione di più valori TOS verso ogni altra destinazione. Ciò aiuta a monitorare le prestazioni di rete per diverse classi di QoS (Quality of Service).
• L'agente è in grado di rilevare cali di rete fino a 1 su 6000 pacchetti al minuto su ciascun percorso di sonda. È possibile rilevare la perdita di pacchetti all'interno del core o del perimetro della rete della durata inferiore a 1 secondo, come ad esempio durante un flap BGP.
• I grafici delle perdite di pacchetti delle sonde imitano quelli dei tassi di errore delle interfacce dei dispositivi di rete quando gli errori sono responsabili delle perdite. Siamo stati in grado di individuare bug di black-holing del traffico nella rete che sono difficili da rilevare.
• Gli agenti utilizzano i timestamp di lettura del kernel della scheda di rete (NIC) per ottenere un'elevata precisione nelle misurazioni della latenza di rete. È possibile misurare una latenza intra-sito di andata e ritorno costante di 50–100 microsecondi, escludendo la latenza di scheduling del sistema operativo host e la deriva dell'orologio di rete.
• Basso utilizzo della CPU e ingombro di memoria. L'agente utilizza meno del 25% di un singolo core alle velocità di trasmissione e ricezione di picco (5 kpps ciascuna). La maggior parte degli agenti distribuiti utilizza solo circa il 5% di un core. Sono necessari solo 10 MB di memoria heap per gestire i buffer e i contatori dei pacchetti Tx e Rx dell'agente. Quando la rete cresce, possiamo scalare verticalmente o orizzontalmente modificando i limiti o aggiungendo agenti aggiuntivi.
• L'agente è raramente influenzato quando il sistema host è sotto stress. Abbiamo ottenuto risultati accurati anche quando il carico della CPU dell'host si è avvicinato al 99% in diverse occasioni.
• La telemetria viene raccolta da ciascun agente per monitorarne lo stato di salute. Gli agenti sono in grado di identificare situazioni problematiche, come il riavvio del sistema host, il riavvio del processo dell'agente o la perdita di pacchetti dovuta al traboccamento dei buffer dei socket.

Gli agenti vengono distribuiti con Chef su un'ampia serie di cluster di server per mantenere un numero elevato di nodi che partecipano al rilevamento della rete. Il binario dell'agente viene eseguito e gestito con systemd su Linux in modo che venga riavviato automaticamente dopo un riavvio dell'host o un aggiornamento dell'agente. Lo scheduler mesh rileva e regola dinamicamente i flussi secondo necessità quando uno qualsiasi degli agenti si arresta o ne vengono avviati di nuovi. La nostra applicazione di schedulazione interroga periodicamente l'inventario dei dispositivi e un sistema di rilevamento dei servizi per individuare nuovi agenti e lo stato di salute dei server prima di assegnare le destinazioni per il monitoraggio intra-pod, intra-sito e inter-sito. Viene utilizzato un bus di messaggi per comunicare l'elenco degli host di destinazione a ciascun agente che trasmette i test di sondaggio. I singoli flussi che hanno origine o terminano in un rack specifico vengono distribuiti tra tutti gli agenti disponibili all'interno di quel rack. Questo ci aiuta a esercitare una grande quantità di percorsi a costo uguale all'interno del nostro fabric di rete, come mostrato nelle figure sottostanti.

Abbiamo iniziato con 150 agenti nella nostra prima implementazione e ora siamo riusciti a espanderci di 10 volte. La rete mesh copre la nostra dorsale interconnettendo 25 siti sparsi in tutto il mondo. In uno dei nostri principali data center disponiamo di una rete mesh interna che copre oltre 200 rack con circa 33.000 flussi, per un tasso di sondaggio complessivo di 1,65 Mpps. Ogni rack riceve 5-10 kpps di sondaggi da altri rack. L'applicazione di pianificazione calcola e distribuisce uniformemente oltre 35.000 target tra tutti i nostri agenti nei diversi siti.

Raccolta e visualizzazione dei dati

Eseguiamo un'applicazione di raccolta dati separata che interroga periodicamente tutti gli agenti Ping Mesh per ottenere i risultati relativi alla perdita di pacchetti e alla latenza. Questi dati vengono filtrati automaticamente per escludere i risultati non validi in base agli stati di integrità memorizzati localmente nel collettore. Ad esempio, escludiamo i risultati provenienti da un agente in esecuzione su un server che non ha risposto ai controlli di integrità o da un server appena riavviato. Il nostro collettore è in grado di interrogare e filtrare in modo sincrono i risultati provenienti da oltre 1.500 nodi e quindi inserire i dati in un database di serie temporali entro 2 secondi.

Sia i risultati aggregati che quelli per flusso vengono visualizzati con l'ausilio delle dashboard di Grafana. Le griglie delle mappe di calore possono essere difficili da utilizzare con grandi insiemi di dati, in particolare per il nostro grande sito di data center. Utilizziamo una query topk() di Prometheus per visualizzare i percorsi con la più alta perdita di pacchetti individuale tra migliaia di risultati, che in genere sono solo una manciata. I risultati vengono ampiamente verificati rispetto alle statistiche di integrità dell'agente e del sistema host che vengono frequentemente rilevate dal collettore. Questo ci offre un alto livello di affidabilità su ogni singolo risultato, indipendentemente dall'entità delle variazioni di perdita di pacchetti. I singoli risultati, se osservati nel loro insieme, possono fornirci indizi su dove si è verificato il guasto di rete. Di seguito sono riportati alcuni esempi di perdita di pacchetti rilevati dal nostro sistema di monitoraggio mesh.

Sintesi e prossimi passi

Il nostro sistema Ping Mesh è stato uno strumento potente per il team di ingegneria di rete per monitorare la perdita di pacchetti e la latenza end-to-end. Questi dati possono essere utilizzati per rispondere istantaneamente alla domanda: "La rete sta perdendo pacchetti?" In base alla nostra esperienza, i principali incidenti di rete che hanno un impatto sui clienti vengono solitamente rilevati e segnalati dal sistema di monitoraggio della telemetria dei dispositivi. Questo sistema mette in luce problemi di basso impatto ma potenzialmente problematici, come il buffering di rete o il black-holing isolato del traffico.

Il nostro sistema è inoltre in grado di fornire informazioni dettagliate sull'affidabilità complessiva della rete cloud di Roblox. In uno dei nostri principali data center, disponiamo di oltre 100 milioni di sonde al minuto che monitorano lo stato della rete e raramente registriamo un numero di pacchetti persi superiore a 50 al minuto. Ciò indica un livello di affidabilità pari a circa 6 nove (99,9999%) dalla rete del nostro data center. Molto spesso, non si nota alcuna perdita di pacchetti tra i 100 milioni di pacchetti. Quando si verifica una perdita significativa di pacchetti, questo sistema fornisce informazioni su dove e per quanto tempo si è verificata la perdita. Un motore di riparazione automatica ripristina la rete e impedisce che il traffico degli utenti subisca ulteriori perdite reindirizzandolo attraverso un percorso diverso nella rete. Il team di networking di Roblox ha costruito una rete cloud estremamente affidabile.

In futuro, intendiamo utilizzare un motore di analisi per correlare i dati provenienti dalla telemetria dei dispositivi, dai syslog e da altri set di dati. Successivamente, prevediamo di confrontarli con i dati di Ping Mesh per aiutare a isolare il punto in cui si è verificato il guasto di rete. Man mano che la rete cloud di Roblox continua ad espandersi ed evolversi, prevediamo di potenziare i nostri meccanismi di rilevamento per includere IPv6 e jumbo frame, aggiungendo al contempo più agenti per aumentare la copertura tra i siti.