Contesto
Le CDN e i provider di servizi cloud forniscono grandi volumi di traffico su Internet e utilizzano strumenti di monitoraggio completi per garantire prestazioni e affidabilità. Questi includono strumenti che coprono vari livelli di distribuzione del traffico, ad esempio rete, server, applicazioni, ecc. TCP/IP rappresenta la maggior parte di questo traffico (mentre il QUIC basato su UDP è in aumento a livello globale, è ancora una piccola frazione del traffico totale rispetto al TCP).
I socket sono astrazioni del sistema operativo che collegano la connessione client e server su cui vengono trasmessi i dati. I problemi di rete, quindi, si riflettono direttamente nei dati memorizzati con ogni socket. Ad esempio, la congestione nella rete può comportare tempi di risposta lenti e un aumento dei tempi di andata e ritorno (RTT). È anche possibile che la larghezza di banda della rete sia disponibile, ma l’applicazione è sovraccarica di troppe richieste e non è in grado di riempire il buffer con dati sufficienti per utilizzare completamente la larghezza di banda disponibile, con conseguente anomalia limitata dell’applicazione. Spesso i server gestiscono più socket contemporaneamente, il che può portare a conflitti di risorse che mettono sotto pressione le risorse di sistema come CPU e memoria.
Pertanto, il monitoraggio delle prestazioni dei socket TCP su larga scala può fornire una comprensione critica dei comportamenti del traffico, come tempi di risposta lenti o interruzioni delle connessioni, e identificare i casi in cui è possibile apportare miglioramenti.
Strumenti esistenti
L’utility “ss” in Linux è uno strumento comune utilizzato per ottenere statistiche socket. Simile a “netstat”, ss fornisce un meccanismo più rapido e flessibile per ottenere informazioni consentendo filtri su stati socket, protocolli e indirizzi. Abbiamo iniziato il nostro percorso di monitoraggio delle prese anche con ss. Sebbene sia uno strumento potente per ottenere rapidamente un elenco di socket e metriche pertinenti, la sfida principale di ss è che può consumare risorse significative, soprattutto se utilizzato su sistemi con un gran numero di socket. Ciò può influire sulle prestazioni del sistema e rallentare altri processi. Inoltre, l’output ss non è ideale per l’analisi, a causa della chiave incoerente: Utilizzo del valore e complica significativamente la capacità di trasmettere dati raccolti da migliaia di server.
La nostra prima versione della raccolta socket che utilizzava ss era uno script bash in esecuzione su server cache selezionati che esportavamo l’output di “ss –tcp –info” in un file. Questo file viene quindi rsync-ed a un host Bastion da cui uno script Python lo legge, lo analizza e lo inserisce in Elasticsearch. Questo ha portato a termine il lavoro, ma non era affatto vicino alla scala di cui avevamo bisogno. La successiva iterazione di questo lavoro fu quella di avere uno script Python attivo sui server cache che sarebbe stato richiamato da un’interfaccia HTTP e restituito le statistiche aggregate per essere inserite nel cluster Elasticsearch. Questo metodo ha scalato il collo di bottiglia di analisi da una posizione centrale di back-Office al singolo server di cache, ma ha comportato un elevato utilizzo della memoria nei server con un numero significativamente elevato di socket. Infine, abbiamo riconosciuto la necessità di una sostituzione leggera della parte ss del sistema.
I nostri requisiti principali per questo nuovo strumento erano che fosse leggero e scalabile al gran numero di socket di cui dispongono i nostri server CDN e che fosse in grado di trasmettere i dati tramite un meccanismo efficiente come i buffer di protocollo. Lo strumento TCP-info di MeasurementLab è una grande utility implementata in Golang. Tuttavia, è progettato per il tracciamento degli stessi connettori femmina nel tempo. Dato l’elevato volume di collegamenti femmina, abbiamo scelto di non tenere traccia dei singoli connettori femmina. Al contrario, ogni ciclo di polling deve essere indipendente, fornendo un’istantanea dello stato corrente dei socket aperti. L’obiettivo principale è monitorare le prestazioni complessive del sistema e non i singoli socket.
XTCP
Per risolvere queste sfide, introduciamo xTCP open-source (Extract, Export, Xray TCP). XTCP è un’utility Golang per acquisire e trasmettere dati socket su larga scala. XTCP utilizza NetLink per acquisire informazioni socket, comprimere i dati in protobufs e inviarli tramite una porta UDP (da inviare a Kafka, ecc.) o scrivere a NSQ.
NetLink fornisce un’interfaccia generica per la comunicazione tra lo spazio utente e lo spazio kernel. Gli strumenti di monitoraggio socket ss, tcp-info utilizzano NETLINK_INET_DIAG, parte della famiglia di protocolli NetLink, per ottenere informazioni socket dal kernel nello spazio utente (nota dalla pagina man: NETLINK_INET_DIAG è stato introdotto in Linux 2.6.14 e supporta solo i socket AF_INET e AF_INET6. In Linux 3,3, è stato rinominato NETLINK_SOCK_DIAG ed esteso per supportare i socket AF_UNIX.)
XTCP estrae i dati TCP INET_DIAG del kernel a velocità elevate ed esporta tali dati tramite protobufs. Su un computer con circa 120 socket, i messaggi NetLink sono circa 5-6 MB, tuttavia l’output ASCII di ss è di circa 60 MB. Inoltre, ss legge dal kernel in blocchi di ~3 KB per impostazione predefinita. XTCP legge i frammenti da 32 KB e quindi riduce al minimo le chiamate di sistema. XTCP legge contemporaneamente i dati del socket NetLink utilizzando più dipendenti per scaricare la coda il più velocemente possibile e analizza contemporaneamente i messaggi NetLink per lo streaming. Tutte queste ottimizzazioni riducono l’ingombro di xTCP per l’esecuzione sui server cache di produzione.
Uso in Edgio
Utilizziamo in modo massiccio i dati xTCP per analizzare le prestazioni dei client. In genere, teniamo traccia di RTT e ritrasmettiamo aggregati per punto di presenza (POP) e ASN.
A differenza della velocità di invecchiamento, TTL consente di modificare la capacità cache di un particolare elemento. Per la durata impostata utilizzando la funzione TTL, un elemento non invecchia mentre è sul disco, quindi è meno probabile (anche molto improbabile) essere sfrattato. Dopo la scadenza del TTL, l’articolo può iniziare a invecchiare in modo tradizionale LRU o con invecchiamento rapido o lento (a seconda di come l’operatore lo configura). Nella figura seguente, TTL con invecchiamento lento ha mantenuto un elemento su disco al punto in cui non ha superato la soglia di sfratto della cache. All’estremità opposta, TTL assicurava che un flusso video live fosse memorizzato nella cache almeno per la durata dell’evento, ma in seguito è stato rimosso rapidamente dal disco utilizzando il fast aging.
Un esempio di dashboard xTCP che mostra RTT, ritrasmissioni e numero di socket campionati per POP AGA e CHB per un grande provider statunitense.
In un precedente post del blog, abbiamo presentato la nostra pipeline per la messa a punto del controllo dinamico della congestione per abilitare automaticamente il BBR per i clienti con prestazioni inferiori e in cui sappiamo che il meccanismo di BBR sarebbe più utile. I dati xTCP sono la fonte principale per l’analisi.
Siamo costantemente alla ricerca di nuovi modi per utilizzare i dati xTCP per rispondere a domande complesse come l’impatto della congestione e l’apprendimento automatico per prevedere le prestazioni e rilevare le anomalie. Prevediamo di riferire su tale analisi dei dati socket in un prossimo post sul blog.
Oggi xTCP si unisce a vFlow (sflow, netflow, ipfix collector) nella nostra suite di strumenti di monitoraggio di rete open source. Ci auguriamo che ciò serva alla comunità di monitoraggio delle prestazioni dell’infrastruttura per la raccolta dei dati socket e attendiamo con ansia una partecipazione attiva per portare avanti questo strumento.
Conferma
Il successo e l’ampia usabilità di xTCP sono il risultato del contributo di singoli individui e team di Edgio. Vorremmo ringraziare in particolare David Seddon, che è lo sviluppatore iniziale di xTCP. Un ringraziamento speciale a tutti i revisori e collaboratori del codice interno per aver testato, inserito, dashboard e feedback su xTCP.
