I moderni data center hanno centinaia di dispositivi attivi installati, coperti da diversi tipi di monitoraggio. Ma anche un ingegnere ideale con un monitoraggio perfetto a portata di mano sarà in grado di rispondere correttamente a un guasto della rete in pochi minuti. In un rapporto alla conferenza Next Hop 2020, ho presentato una metodologia di progettazione di reti DC che ha una caratteristica unica: il data center si autoripara in millisecondi. Più precisamente, l'ingegnere risolve con calma il problema, mentre i servizi semplicemente non se ne accorgono.
Per molti ingegneri di rete, la rete di un data center inizia, ovviamente, con ToR, con uno switch nel rack. ToR solitamente ha due tipi di collegamenti. Quelli piccoli vanno ai server, altri - sono N volte di più - vanno verso le spine del primo livello, cioè verso i suoi uplink. Gli uplink sono generalmente considerati uguali e il traffico tra uplink è bilanciato in base a un hash da 5 tuple, che include proto, src_ip, dst_ip, src_port, dst_port. Nessuna sorpresa qui.
Successivamente, come si presenta l’architettura del piano? Le spine del primo livello non sono collegate tra loro, ma sono collegate tramite superspine. La lettera X sarà responsabile delle superspine; è quasi come una connessione incrociata.
Ed è chiaro che, d'altronde, i tori sono collegati a tutte le spine del primo livello. Cosa è importante in questa immagine? Se abbiamo un'interazione all'interno del rack, l'interazione, ovviamente, passa attraverso ToR. Se l'interazione avviene all'interno del modulo, allora l'interazione avviene attraverso le spine di primo livello. Se l'interazione è intermodulare - come in questo caso ToR 1 e ToR 2 - allora l'interazione passerà attraverso le spine sia del primo che del secondo livello.
In teoria, tale architettura è facilmente scalabile. Se disponiamo di capacità portuale, spazio libero nel data center e fibra pre-posata, è sempre possibile aumentare il numero di corsie, aumentando così la capacità complessiva del sistema. Questo è molto facile da fare su carta. Sarebbe così nella vita. Ma la storia di oggi non riguarda questo.
Voglio che si traggano le giuste conclusioni. Abbiamo molti percorsi all'interno del data center. Sono condizionatamente indipendenti. Un percorso all'interno del data center è possibile solo all'interno di ToR. All'interno del modulo abbiamo il numero di percorsi pari al numero di corsie. Il numero di percorsi tra i moduli è uguale al prodotto del numero di piani e del numero di superspine in ciascun piano. Per renderlo più chiaro, per avere un'idea delle dimensioni, fornirò numeri validi per uno dei data center Yandex.
Ci sono otto aerei, ogni aereo ha 32 superspine. Di conseguenza, si scopre che ci sono otto percorsi all'interno del modulo e con l'interazione tra moduli ce ne sono già 256.
Cioè, se stiamo sviluppando Cookbook, cercando di imparare come costruire data center tolleranti ai guasti che si autoriparano, allora l’architettura planare è la scelta giusta. Risolve il problema del ridimensionamento e in teoria è facile. Ci sono molti percorsi indipendenti. La domanda rimane: come fa un’architettura del genere a sopravvivere ai fallimenti? Ci sono vari fallimenti. E di questo ne discuteremo adesso.
Lasciamo che una delle nostre superspine “si ammali”. Qui sono tornato all'architettura a due piani. Li utilizzeremo come esempio perché sarà semplicemente più semplice vedere cosa sta succedendo con meno parti in movimento. Lascia che X11 si ammali. In che modo ciò influirà sui servizi che risiedono all'interno dei data center? Molto dipende da come si presenta effettivamente il fallimento.
Se il guasto è buono, viene rilevato a livello di automazione dello stesso BFD, l'automazione posiziona felicemente i giunti problematici e isola il problema, quindi va tutto bene. Abbiamo molti percorsi, il traffico viene immediatamente reindirizzato su percorsi alternativi e i servizi non si accorgono di nulla. Questa è una buona sceneggiatura.
Uno scenario negativo è quello in cui abbiamo perdite costanti e l’automazione non si accorge del problema. Per capire come ciò influisce su un'applicazione, dovremo dedicare un po' di tempo a discutere come funziona TCP.
Spero di non scioccare nessuno con questa informazione: TCP è un protocollo di conferma della trasmissione. Cioè, nel caso più semplice, il mittente invia due pacchetti e riceve su di essi un riscontro cumulativo: "Ho ricevuto due pacchetti".
Successivamente invierà altri due pacchetti e la situazione si ripeterà. Mi scuso in anticipo per qualche semplificazione. Questo scenario è corretto se la finestra (il numero di pacchetti in volo) è due. Naturalmente nel caso generale non è necessariamente così. Ma la dimensione della finestra non influisce sul contesto di inoltro dei pacchetti.
Cosa succede se perdiamo il pacchetto 3? In questo caso, il destinatario riceverà i pacchetti 1, 2 e 4. E dirà esplicitamente al mittente utilizzando l’opzione SACK: “Sai, ne sono arrivati tre, ma il mezzo è andato perso”. Dice: "Ack 2, SACK 4".
In questo momento, il mittente ripete senza problemi esattamente il pacchetto perso.
Ma se l'ultimo pacchetto nella finestra viene perso, la situazione apparirà completamente diversa.
Il destinatario riceve i primi tre pacchetti e innanzitutto inizia ad attendere. Grazie ad alcune ottimizzazioni nello stack TCP del kernel Linux, attenderà un pacchetto accoppiato a meno che i flag non indichino esplicitamente che si tratta dell'ultimo pacchetto o qualcosa di simile. Aspetterà fino alla scadenza del timeout di ACK ritardato e quindi invierà un riconoscimento sui primi tre pacchetti. Ma ora il mittente aspetterà. Non sa se il quarto pacco è andato smarrito o sta per arrivare. E per non sovraccaricare la rete, cercherà di attendere un'indicazione esplicita che il pacchetto è perso o che scada il timeout RTO.
Cos'è il timeout RTO? Questo è il massimo dell'RTT calcolato dallo stack TCP e da alcune costanti. Di che tipo di costante si tratta, discuteremo ora.
Ma la cosa importante è che se siamo ancora sfortunati e il quarto pacchetto viene perso di nuovo, allora l'RTO raddoppia. Cioè, ogni tentativo fallito significa raddoppiare il timeout.
Ora vediamo a quanto equivale questa base. Per impostazione predefinita, l'RTO minimo è 200 ms. Questo è l'RTO minimo per i pacchetti di dati. Per i pacchetti SYN è diverso, 1 secondo. Come puoi vedere, anche il primo tentativo di inviare nuovamente i pacchetti richiederà 100 volte più tempo dell'RTT all'interno del data center.
Ora torniamo al nostro scenario. Cosa sta succedendo con il servizio? Il servizio inizia a perdere pacchetti. Lascia che il servizio sia inizialmente fortunato e perda qualcosa nel mezzo della finestra, quindi riceve un SACK e invia nuovamente i pacchetti persi.
Ma se la sfortuna si ripete, allora abbiamo un RTO. Cosa è importante qui? Sì, abbiamo molti percorsi nella nostra rete. Ma il traffico TCP di una particolare connessione TCP continuerà a passare attraverso lo stesso stack interrotto. Le perdite di pacchetti, a condizione che questo nostro magico X11 non si spenga da solo, non portano il traffico a confluire in aree non problematiche. Stiamo cercando di consegnare il pacchetto attraverso lo stesso stack rotto. Ciò porta a un guasto a cascata: un data center è un insieme di applicazioni interagenti e alcune delle connessioni TCP di tutte queste applicazioni iniziano a deteriorarsi, perché Superspine influisce su tutte le applicazioni esistenti all'interno del data center. Come dice il proverbio: se non ferravi un cavallo, il cavallo diventava zoppo; il cavallo è diventato zoppo - il rapporto non è stato consegnato; il rapporto non è stato consegnato: abbiamo perso la guerra. Solo che qui il conteggio è in secondi, dal momento in cui si presenta il problema allo stadio di degrado che i servizi cominciano ad avvertire. Ciò significa che gli utenti potrebbero perdere qualcosa da qualche parte.
Esistono due soluzioni classiche che si completano a vicenda. Il primo sono i servizi che stanno cercando di risolvere il problema in questo modo: “Modifichiamo qualcosa nello stack TCP. Effettuiamo timeout a livello di applicazione o sessioni TCP di lunga durata con controlli di integrità interni." Il problema è che tali soluzioni: a) non sono affatto scalabili; b) sono controllati molto male. Cioè, anche se il servizio configura accidentalmente lo stack TCP in modo da renderlo migliore, in primo luogo, è improbabile che sia applicabile a tutte le applicazioni e a tutti i data center e, in secondo luogo, molto probabilmente non capirà cosa è stato fatto correttamente e cosa no. Cioè, funziona, ma funziona male e non è scalabile. E se c’è un problema di rete, di chi è la colpa? Naturalmente, NOC. Cosa fa il NOC?
Molti servizi credono che nel lavoro NOC avvenga qualcosa del genere. Ma a dire il vero, non solo.
NOC nello schema classico è impegnata nello sviluppo di numerosi sistemi di monitoraggio. Si tratta sia di monitoraggio a scatola nera che a scatola bianca. Informazioni su un esempio di monitoraggio della colonna vertebrale della scatola nera Alexander Klimenko all'ultimo Next Hop. A proposito, questo monitoraggio funziona. Ma anche il monitoraggio ideale avrà un ritardo. Di solito sono necessari pochi minuti. Dopo che si è spento, gli ingegneri in servizio hanno bisogno di tempo per ricontrollarne il funzionamento, localizzare il problema e quindi estinguere l'area problematica. Cioè, nel migliore dei casi, il trattamento del problema richiede 5 minuti, nel peggiore dei casi 20 minuti, se non è immediatamente evidente dove si verificano le perdite. È chiaro che per tutto questo tempo – 5 o 20 minuti – i nostri servizi continueranno a soffrire, il che probabilmente non è positivo.
Cosa ti piacerebbe davvero ricevere? Abbiamo tanti modi. E i problemi sorgono proprio perché i flussi TCP sfortunati continuano a utilizzare la stessa rotta. Abbiamo bisogno di qualcosa che ci permetta di utilizzare più percorsi all'interno di una singola connessione TCP. Sembrerebbe che abbiamo una soluzione. Esiste il TCP, chiamato TCP multipercorso, ovvero TCP per percorsi multipli. È vero, è stato sviluppato per un compito completamente diverso: per smartphone con diversi dispositivi di rete. Per massimizzare il trasferimento o la modalità primaria/backup, è stato sviluppato un meccanismo che crea più thread (sessioni) in modo trasparente per l'applicazione e consente di passare da uno all'altro in caso di errore. Oppure, come ho detto, massimizza la serie di vittorie.
Ma qui c'è una sfumatura. Per capire di cosa si tratta, dovremo vedere come vengono stabiliti i thread.
I thread vengono installati in sequenza. Il primo thread viene installato per primo. I thread successivi vengono quindi impostati utilizzando il cookie che è già stato concordato all'interno di quel thread. Ed ecco il problema.
Il problema è che se il primo thread non si afferma, il secondo e il terzo thread non sorgeranno mai. Cioè, il TCP multipercorso non risolve la perdita di un pacchetto SYN nel primo flusso. E se il SYN viene perso, il TCP multipath si trasforma in TCP normale. Ciò significa che in un ambiente data center non ci aiuterà a risolvere il problema delle perdite in fabbrica e imparare a utilizzare più percorsi in caso di guasto.
Cosa può aiutarci? Alcuni di voi hanno già intuito dal titolo che un campo importante nella nostra storia successiva sarà il campo dell'intestazione dell'etichetta del flusso IPv6. In effetti, questo è un campo che appare nella v6, non lo è nella v4, occupa 20 bit e da molto tempo c'è polemica sul suo utilizzo. Questo è molto interessante: ci sono state controversie, qualcosa è stato risolto all'interno della RFC e allo stesso tempo è apparsa un'implementazione nel kernel Linux, che non era documentata da nessuna parte.
Ti invito ad accompagnarmi in una piccola indagine. Diamo un'occhiata a cosa è successo nel kernel Linux negli ultimi anni.
anno 2014. Un ingegnere di una grande e rispettata azienda aggiunge alla funzionalità del kernel Linux la dipendenza del valore dell'etichetta del flusso dall'hash del socket. Cosa stavano cercando di sistemare qui? Ciò è correlato alla RFC 6438, che discuteva il seguente problema. All'interno del data center, IPv4 è spesso incapsulato in pacchetti IPv6, perché la fabbrica stessa è IPv6, ma IPv4 deve in qualche modo essere fornito all'esterno. Per molto tempo ci sono stati problemi con gli switch che non riuscivano a cercare sotto due intestazioni IP per raggiungere TCP o UDP e trovare lì src_ports, dst_ports. Si è scoperto che l'hash, se guardi le prime due intestazioni IP, era quasi fisso. Per evitare ciò, affinché il bilanciamento di questo traffico incapsulato funzioni correttamente, è stato proposto di aggiungere l'hash del pacchetto incapsulato da 5 tuple al valore del campo etichetta di flusso. Più o meno la stessa cosa è stata fatta per altri schemi di incapsulamento, per UDP, per GRE, quest'ultimo ha utilizzato il campo GRE Key. In un modo o nell'altro, gli obiettivi qui sono chiari. E almeno in quel momento erano utili.
Nel 2015, una nuova patch arriva dallo stesso rispettato ingegnere. È molto interessante. Dice quanto segue: randomizzeremo l'hash in caso di un evento di routing negativo. Cos'è un evento di routing negativo? Questo è l'RTO di cui abbiamo parlato prima, ovvero la perdita della coda della finestra è un evento veramente negativo. È vero, è relativamente difficile indovinare che sia proprio così.
2016, un'altra azienda rispettabile, anche grande. Smonta le ultime stampelle e fa in modo che l'hash, che prima rendevamo casuale, ora cambi ad ogni ritrasmissione SYN e dopo ogni timeout RTO. E in questa lettera, per la prima e ultima volta, viene dichiarato l'obiettivo finale: garantire che il traffico in caso di perdite o congestione del canale possa essere reindirizzato dolcemente e utilizzare percorsi multipli. Naturalmente, dopo questo ci sono state molte pubblicazioni, puoi trovarle facilmente.
Anche se no, non puoi, perché non c'è stata una sola pubblicazione su questo argomento. Ma lo sappiamo!
E se non capisci appieno cosa è stato fatto, te lo dirò ora.
Cosa è stato fatto, quali funzionalità sono state aggiunte al kernel Linux? txhash cambia in un valore casuale dopo ogni evento RTO. Questo è il risultato molto negativo del routing. L'hash dipende da questo txhash e l'etichetta del flusso dipende dall'hash skb. Qui ci sono alcuni calcoli sulle funzioni; tutti i dettagli non possono essere inseriti in una diapositiva. Se qualcuno è curioso, può leggere il codice del kernel e controllare.
Cosa è importante qui? Il valore del campo dell'etichetta del flusso cambia in un numero casuale dopo ciascun RTO. In che modo ciò influisce sul nostro sfortunato flusso TCP?
Se si verifica un SACK, non cambia nulla perché stiamo tentando di inviare nuovamente un pacchetto perduto noto. Fin qui tutto bene.
Ma nel caso di RTO, a condizione che abbiamo aggiunto un'etichetta di flusso alla funzione hash su ToR, il traffico potrebbe prendere un percorso diverso. E maggiore è il numero di corsie, maggiore è la possibilità di trovare un percorso che non sia influenzato da un guasto su un particolare dispositivo.
Rimane un problema: l'RTO. Naturalmente c'è un'altra strada, ma su questa si perde molto tempo. 200 ms sono tanti. Un secondo è assolutamente selvaggio. In precedenza ho parlato dei timeout di configurazione dei servizi. Quindi, il secondo è un timeout, che di solito viene configurato dal servizio a livello di applicazione, e in questo il servizio sarà anche relativamente corretto. Inoltre, ripeto, il vero RTT all'interno di un moderno data center è di circa 1 millisecondo.
Cosa puoi fare con i timeout RTO? Il timeout, responsabile dell'RTO in caso di perdita di pacchetti di dati, può essere configurato in modo relativamente semplice dallo spazio utente: esiste un'utilità IP e uno dei suoi parametri contiene lo stesso rto_min. Considerando che l'RTO, ovviamente, deve essere modificato non a livello globale, ma per determinati prefissi, un tale meccanismo sembra abbastanza praticabile.
È vero, con SYN_RTO tutto è un po' peggio. È naturalmente inchiodato. Il kernel ha un valore fisso di 1 secondo e il gioco è fatto. Non puoi raggiungerlo dallo spazio utente. C'è solo un modo.
eBPF viene in soccorso. In parole povere, si tratta di piccoli programmi C. Possono essere inseriti negli hook in punti diversi nell'esecuzione dello stack del kernel e dello stack TCP, con i quali è possibile modificare un numero molto elevato di impostazioni. In generale, l’eBPF è una tendenza a lungo termine. Invece di tagliare dozzine di nuovi parametri sysctl ed espandere l’utilità IP, il movimento si sta spostando verso eBPF e espandendo le sue funzionalità. Utilizzando eBPF, puoi modificare dinamicamente i controlli di congestione e varie altre impostazioni TCP.
Ma per noi è importante che possa essere utilizzato per modificare i valori SYN_RTO. Inoltre, c'è un esempio pubblicato pubblicamente: . Cosa è stato fatto qui? L'esempio funziona, ma di per sé è molto approssimativo. Qui si presuppone che all'interno del data center confrontiamo i primi 44 bit; se corrispondono, allora siamo all'interno del data center. E in questo caso modifichiamo il valore di timeout SYN_RTO su 4ms. Lo stesso compito può essere svolto in modo molto più elegante. Ma questo semplice esempio dimostra che ciò è a) possibile; b) relativamente semplice.
Cosa sappiamo già? Il fatto che l'architettura del piano consenta il ridimensionamento si rivela estremamente utile per noi quando abilitiamo l'etichetta del flusso su ToR e otteniamo la possibilità di scorrere attorno alle aree problematiche. Il modo migliore per ridurre i valori RTO e SYN-RTO è utilizzare i programmi eBPF. La domanda rimane: è sicuro utilizzare un'etichetta di flusso per il bilanciamento? E qui c'è una sfumatura.
Supponiamo che tu abbia un servizio sulla tua rete che risiede in anycast. Purtroppo non ho tempo per entrare nei dettagli su cosa sia anycast, ma si tratta di un servizio distribuito con diversi server fisici accessibili tramite lo stesso indirizzo IP. Ed ecco un possibile problema: l'evento RTO può verificarsi non solo quando il traffico attraversa la struttura. Può verificarsi anche a livello del buffer ToR: quando si verifica un evento incast, può verificarsi anche sull'host quando l'host versa qualcosa. Quando si verifica un evento RTO che modifica l'etichetta del flusso. In questo caso, il traffico può essere indirizzato a un'altra istanza anycast. Supponiamo che si tratti di un anycast con stato, che contenga uno stato di connessione: potrebbe essere un bilanciatore L3 o qualche altro servizio. Quindi sorge un problema, perché dopo l'RTO la connessione TCP arriva al server, che non sa nulla di questa connessione TCP. E se non disponiamo di condivisione dello stato tra server anycast, tale traffico verrà interrotto e la connessione TCP verrà interrotta.
Che cosa si può fare qui? All'interno del tuo ambiente controllato, in cui abiliti il bilanciamento delle etichette di flusso, devi registrare il valore dell'etichetta di flusso quando accedi ai server anycast. Il modo più semplice è farlo tramite lo stesso programma eBPF. Ma ecco un punto molto importante: cosa fare se non gestisci una rete di data center, ma sei un operatore di telecomunicazioni? Questo è anche il tuo problema: a partire da alcune versioni di Juniper e Arista, includono un'etichetta di flusso nelle loro funzioni hash per impostazione predefinita, francamente, per un motivo che non mi è chiaro. Ciò potrebbe causare l'interruzione delle connessioni TCP da parte degli utenti che passano attraverso la rete. Quindi ti consiglio vivamente di controllare le impostazioni del tuo router qui.
In un modo o nell'altro, mi sembra che siamo pronti per passare agli esperimenti.
Quando abbiamo abilitato l'etichetta del flusso su ToR, preparato l'agente eBPF, che ora risiede sugli host, abbiamo deciso di non aspettare il prossimo grande fallimento, ma di condurre esplosioni controllate. Abbiamo preso ToR, che ha quattro uplink, e abbiamo impostato i drop su uno di essi. Hanno tracciato una regola e hanno detto: ora stai perdendo tutti i pacchetti. Come puoi vedere a sinistra, abbiamo il monitoraggio per pacchetto, che è sceso al 75%, ovvero il 25% dei pacchetti viene perso. Sulla destra ci sono i grafici dei servizi che stanno dietro questo ToR. Essenzialmente si tratta di grafici del traffico delle interfacce con i server all'interno del rack. Come puoi vedere, sono affondati ancora più in basso. Perché sono scesi più in basso, non del 25%, ma in alcuni casi di 3-4 volte? Se la connessione TCP è sfortunata, continua a tentare di raggiungere la giunzione interrotta. Ciò è aggravato dal comportamento tipico del servizio all'interno del controller di dominio: per una richiesta dell'utente, vengono generate N richieste ai servizi interni e la risposta verrà inviata all'utente quando tutte le origini dati rispondono o quando si verifica un timeout nell'applicazione livello, che deve ancora essere configurato. Cioè, tutto è molto, molto brutto.
Ora lo stesso esperimento, ma con il valore dell'etichetta del flusso abilitato. Come puoi vedere, a sinistra il monitoraggio dei batch è diminuito dello stesso 25%. Questo è assolutamente corretto, perché non sa nulla delle ritrasmissioni, invia pacchetti e conta semplicemente il rapporto tra il numero di pacchetti consegnati e quelli persi.
E sulla destra c'è il programma di servizio. Qui non troverai l'effetto di una canna problematica. In quegli stessi millisecondi, il traffico fluiva dall'area problematica ai tre uplink rimanenti che non erano interessati dal problema. Abbiamo una rete che guarisce se stessa.
Questa è la mia ultima diapositiva, è il momento di riassumere. Ora, spero che tu sappia come costruire una rete di data center in grado di autoripararsi. Non avrai bisogno di sfogliare l'archivio del kernel Linux e cercare lì patch speciali; sai che l'etichetta Flow in questo caso risolve il problema, ma devi affrontare questo meccanismo con attenzione. E sottolineo ancora una volta che se sei un operatore di telecomunicazioni, non dovresti utilizzare l'etichetta di flusso come funzione hash, altrimenti interrompi le sessioni dei tuoi utenti.
Gli ingegneri di rete devono subire un cambiamento concettuale: la rete non inizia con il ToR, non con il dispositivo di rete, ma con l’host. Un esempio abbastanza sorprendente è il modo in cui utilizziamo eBPF sia per modificare l'RTO sia per fissare l'etichetta di flusso verso i servizi anycast.
La meccanica delle etichette di flusso è sicuramente adatta per altre applicazioni nel settore amministrativo controllato. Può trattarsi di traffico tra data center oppure è possibile utilizzare tali meccanismi in modo speciale per gestire il traffico in uscita. Ma di questo ve ne parlerò, spero, la prossima volta. Grazie per la vostra attenzione.
Fonte: habr.com