Els centres de dades moderns tenen instal·lats centenars de dispositius actius, coberts per diferents tipus de monitorització. Però fins i tot un enginyer ideal amb un seguiment perfecte a la mà serà capaç de respondre correctament a una fallada de la xarxa en només uns minuts. En un informe a la conferència Next Hop 2020, vaig presentar una metodologia de disseny de xarxa de centres de dades, que té una característica única: el centre de dades es cura en mil·lisegons. Més precisament, l'enginyer soluciona el problema amb calma, mentre que els serveis simplement no ho noten.
Per a molts enginyers de xarxa, una xarxa de centres de dades comença, per descomptat, amb ToR, amb un interruptor al bastidor. ToR sol tenir dos tipus d'enllaços. Els petits van als servidors, els altres -n'hi ha N vegades més- van cap a les espines del primer nivell, és a dir, als seus uplinks. Els enllaços ascendents solen considerar-se iguals i el trànsit entre enllaços ascendents s'equilibra en funció d'un hash de 5 tuples, que inclou proto, src_ip, dst_ip, src_port, dst_port. Aquí no hi ha sorpreses.
A continuació, com és l'arquitectura del pla? Les espines del primer nivell no estan connectades entre si, sinó que estan connectades a través de superspines. La lletra X serà responsable de les superspines; és gairebé com una connexió creuada.
I és evident que, en canvi, els tori estan connectats a totes les espines del primer nivell. Què és important en aquesta imatge? Si tenim interacció dins del bastidor, llavors la interacció, per descomptat, passa per ToR. Si la interacció es produeix dins del mòdul, llavors la interacció es produeix a través de les espines del primer nivell. Si la interacció és intermodular, com aquí, ToR 1 i ToR 2, la interacció passarà per les espines del primer i segon nivell.
En teoria, aquesta arquitectura és fàcilment escalable. Si tenim capacitat de port, espai lliure al centre de dades i fibra prèviament col·locada, sempre es pot augmentar el nombre de carrils, augmentant així la capacitat global del sistema. Això és molt fàcil de fer en paper. Seria així a la vida. Però la història d'avui no tracta d'això.
Vull que s'extreguin les conclusions correctes. Tenim molts camins dins del centre de dades. Són condicionalment independents. Un camí dins del centre de dades només és possible dins del ToR. Dins del mòdul, tenim el nombre de camins igual al nombre de carrils. El nombre de camins entre mòduls és igual al producte del nombre de plans i el nombre de superespines de cada pla. Per fer-ho més clar, per tenir una idea de l'escala, donaré números vàlids per a un dels centres de dades Yandex.
Hi ha vuit avions, cada avió té 32 superespines. Com a resultat, resulta que dins del mòdul hi ha vuit camins, i amb la interacció entre mòduls ja n'hi ha 256.
És a dir, si estem desenvolupant Cookbook, intentant aprendre a construir centres de dades tolerants a errors que es curen a si mateixos, aleshores l'arquitectura plana és l'opció correcta. Soluciona el problema de l'escala i, en teoria, és fàcil. Hi ha molts camins independents. La pregunta segueix sent: com sobreviu aquesta arquitectura als fracassos? Hi ha diversos fracassos. I ara parlarem d'això.
Que una de les nostres superespines "emmalalteixi". Aquí vaig tornar a l'arquitectura de dos plans. Ens quedarem amb aquests com a exemple perquè simplement serà més fàcil veure què passa amb menys peces mòbils. Que X11 emmalalteixi. Com afectarà això als serveis que viuen dins dels centres de dades? Molt depèn de com es vegi realment el fracàs.
Si la fallada és bona, queda atrapada al nivell d'automatització del mateix BFD, l'automatització posa feliçment les articulacions problemàtiques i aïlla el problema, aleshores tot està bé. Tenim molts camins, el trànsit es redirigeix instantàniament a rutes alternatives i els serveis no notaran res. Aquest és un bon guió.
Un mal escenari és si tenim pèrdues constants, i l'automatització no nota el problema. Per entendre com això afecta una aplicació, haurem de dedicar una mica de temps a discutir com funciona TCP.
Espero no sorprendre ningú amb aquesta informació: TCP és un protocol de confirmació de transmissió. És a dir, en el cas més senzill, el remitent envia dos paquets i rep una confirmació acumulada sobre ells: "He rebut dos paquets".
Després d'això, enviarà dos paquets més i la situació es repetirà. Demano disculpes per endavant per alguna simplificació. Aquest escenari és correcte si la finestra (el nombre de paquets en vol) és dos. Per descomptat, en el cas general no és necessàriament així. Però la mida de la finestra no afecta el context de reenviament de paquets.
Què passa si perdem el paquet 3? En aquest cas, el destinatari rebrà els paquets 1, 2 i 4. I li dirà explícitament al remitent mitjançant l'opció SACK: "Ja saps, n'han arribat tres, però el mig s'ha perdut". Diu: "Ack 2, SACK 4".
En aquest moment, el remitent repeteix sense cap problema exactament el paquet que s'ha perdut.
Però si es perd l'últim paquet de la finestra, la situació es veurà completament diferent.
El destinatari rep els tres primers paquets i primer de tot comença a esperar. Gràcies a algunes optimitzacions a la pila TCP del nucli de Linux, esperarà un paquet aparellat tret que els indicadors indiquin explícitament que és l'últim paquet o alguna cosa semblant. Esperarà fins que caduqui el temps d'espera d'ACK retardat i després enviarà un reconeixement als tres primers paquets. Però ara el remitent esperarà. No sap si el quart paquet s'ha perdut o està a punt d'arribar. I per no sobrecarregar la xarxa, intentarà esperar una indicació explícita que s'ha perdut el paquet o que caduqui el temps d'espera RTO.
Què és el temps d'espera RTO? Aquest és el màxim de l'RTT calculat per la pila TCP i alguna constant. Quin tipus de constant és això, ara parlarem.
Però l'important és que si tornem a tenir mala sort i es torna a perdre el quart paquet, llavors el RTO es duplica. És a dir, cada intent sense èxit significa duplicar el temps mort.
Ara vegem a què és igual aquesta base. Per defecte, el RTO mínim és de 200 ms. Aquest és el RTO mínim per als paquets de dades. Per als paquets SYN és diferent, 1 segon. Com podeu veure, fins i tot el primer intent de reenviar paquets trigarà 100 vegades més que el RTT dins del centre de dades.
Ara tornem al nostre escenari. Què està passant amb el servei? El servei comença a perdre paquets. Que el servei tingui sort condicionalment al principi i perdi alguna cosa al mig de la finestra, després rep un SACK i torna a enviar els paquets que s'han perdut.
Però si la mala sort es repeteix, llavors tenim un RTO. Què és important aquí? Sí, tenim molts camins a la nostra xarxa. Però el trànsit TCP d'una connexió TCP concreta continuarà passant per la mateixa pila trencada. Les pèrdues de paquets, sempre que aquest X11 màgic nostre no s'apaga per si sol, no condueix al trànsit a zones que no són problemàtiques. Estem intentant lliurar el paquet a través de la mateixa pila trencada. Això condueix a una fallada en cascada: un centre de dades és un conjunt d'aplicacions que interactuen i algunes de les connexions TCP de totes aquestes aplicacions comencen a degradar-se, perquè la superspine afecta totes les aplicacions que existeixen dins del centre de dades. Com diu la dita: si no ferraves un cavall, el cavall anava coix; el cavall va quedar coix: no es va lliurar l'informe; l'informe no es va lliurar: vam perdre la guerra. Només aquí el recompte és en segons des que sorgeix el problema fins a l'etapa de degradació que comencen a sentir els serveis. Això vol dir que els usuaris poden estar perdent alguna cosa en algun lloc.
Hi ha dues solucions clàssiques que es complementen. El primer són els serveis que intenten posar palletes i resoldre el problema així: "Ajustem alguna cosa a la pila TCP. Fem temps d'espera a nivell d'aplicació o sessions TCP de llarga durada amb comprovacions internes de salut". El problema és que aquestes solucions: a) no s'escala gens; b) estan molt mal controlats. És a dir, fins i tot si el servei configura accidentalment la pila TCP d'una manera que la millori, en primer lloc, és poc probable que sigui aplicable a totes les aplicacions i a tots els centres de dades i, en segon lloc, el més probable és que no entengui que es va fer. correctament, i què no. És a dir, funciona, però funciona malament i no escala. I si hi ha un problema de xarxa, qui té la culpa? Per descomptat, NOC. Què fa NOC?
Molts serveis creuen que al NOC el treball passa una cosa així. Però, sincerament, no només això.
NOC en l'esquema clàssic està compromès en el desenvolupament de molts sistemes de monitorització. Aquests són dos monitors de caixa negra i caixa blanca. Sobre un exemple de monitorització de la columna vertebral de caixa negra Alexander Klimenko a l'últim Next Hop. Per cert, aquest seguiment funciona. Però fins i tot el seguiment ideal tindrà un retard. Normalment això són uns minuts. Després que s'apagui, els enginyers de servei necessiten temps per comprovar-ne el funcionament, localitzar el problema i després extingir l'àrea del problema. És a dir, en el millor dels casos, tractar el problema triga 5 minuts, en el pitjor dels casos, 20 minuts, si no és immediatament evident on es produeixen les pèrdues. Està clar que durant tot aquest temps -5 o 20 minuts- els nostres serveis seguiran patint, cosa que probablement no és bona.
Què t'agradaria rebre realment? Tenim tantes maneres. I els problemes sorgeixen precisament perquè els fluxos TCP que tenen mala sort continuen utilitzant la mateixa ruta. Necessitem alguna cosa que ens permeti utilitzar diverses rutes dins d'una única connexió TCP. Sembla que tenim una solució. Hi ha TCP, que s'anomena TCP multipath, és a dir, TCP per a múltiples camins. És cert que es va desenvolupar per a una tasca completament diferent: per a telèfons intel·ligents que tenen diversos dispositius de xarxa. Per maximitzar la transferència o fer el mode primari/còpia de seguretat, es va desenvolupar un mecanisme que crea múltiples fils (sessions) de manera transparent a l'aplicació i us permet canviar entre ells en cas d'error. O, com he dit, maximitzar la ratxa.
Però aquí hi ha un matís. Per entendre què és, haurem de mirar com s'estableixen els fils.
Els fils s'instal·len seqüencialment. El primer fil s'instal·la primer. Els fils posteriors es configuren mitjançant la galeta que ja s'ha acordat dins d'aquest fil. I aquí està el problema.
El problema és que si el primer fil no s'estableix, el segon i el tercer mai sorgiran. És a dir, el TCP multicamí no resol la pèrdua d'un paquet SYN al primer flux. I si es perd el SYN, el TCP multipath es converteix en TCP normal. Això vol dir que en un entorn de centre de dades no ens ajudarà a resoldre el problema de les pèrdues a la fàbrica i aprendre a utilitzar múltiples camins en cas de fallada.
Què ens pot ajudar? Alguns de vosaltres ja heu endevinat pel títol que un camp important en la nostra història posterior serà el camp de capçalera de l'etiqueta de flux IPv6. Efectivament, aquest és un camp que apareix a la v6, no és a la v4, ocupa 20 bits i fa temps que hi ha polèmica sobre el seu ús. Això és molt interessant: hi va haver disputes, es va solucionar alguna cosa dins de l'RFC i, al mateix temps, va aparèixer una implementació al nucli de Linux, que no estava documentada enlloc.
Et convido a acompanyar-me en una petita investigació. Fem una ullada al que ha passat al nucli Linux durant els últims anys.
any 2014. Un enginyer d'una empresa gran i respectada afegeix a la funcionalitat del nucli Linux la dependència del valor de l'etiqueta de flux del hash del sòcol. Què estaven intentant arreglar aquí? Això està relacionat amb RFC 6438, que tractava el problema següent. Dins del centre de dades, IPv4 sovint s'encapsula en paquets IPv6, perquè la pròpia fàbrica és IPv6, però IPv4 s'ha de donar d'alguna manera fora. Durant molt de temps hi va haver problemes amb commutadors que no podien buscar sota dues capçaleres IP per arribar a TCP o UDP i trobar-hi src_ports, dst_ports. Va resultar que el hash, si ens fixem en les dues primeres capçaleres IP, va resultar gairebé arreglat. Per evitar-ho, perquè l'equilibri d'aquest trànsit encapsulat funcioni correctament, es va proposar afegir el hash del paquet encapsulat de 5 tuples al valor del camp de l'etiqueta de flux. Aproximadament es va fer el mateix per a altres esquemes d'encapsulació, per UDP, per GRE, aquest últim va utilitzar el camp Clau GRE. D'una manera o altra, els objectius aquí són clars. I almenys en aquell moment eren útils.
El 2015, un nou pegat ve del mateix enginyer respectat. Ell és molt interessant. Diu el següent: aleatoritzarem el hash en cas d'un esdeveniment d'encaminament negatiu. Què és un esdeveniment d'encaminament negatiu? Aquest és el RTO que hem comentat anteriorment, és a dir, la pèrdua de la cua de la finestra és un esdeveniment realment negatiu. És cert que és relativament difícil endevinar que això és tot.
2016, una altra empresa de renom, també gran. Desmunta les darreres crosses i fa que el hash, que abans vam fer aleatori, ara canvia per a cada retransmissió SYN i després de cada temps d'espera RTO. I en aquesta carta, per primera i última vegada, s'indica l'objectiu final: garantir que el trànsit en cas de pèrdues o congestió del canal tingui la capacitat de ser reencaminat suaument i utilitzar múltiples camins. Per descomptat, després d'això hi va haver moltes publicacions, les podeu trobar fàcilment.
Encara que no, no es pot, perquè no hi ha hagut una sola publicació sobre aquest tema. Però ho sabem!
I si no enteneu del tot el que es va fer, ara us ho diré.
Què es va fer, quina funcionalitat es va afegir al nucli de Linux? txhash canvia a un valor aleatori després de cada esdeveniment RTO. Aquest és el resultat molt negatiu de l'encaminament. El hash depèn d'aquest txhash i l'etiqueta de flux depèn del hash skb. Hi ha alguns càlculs sobre funcions aquí; tots els detalls no es poden col·locar en una diapositiva. Si algú té curiositat, pot revisar el codi del nucli i comprovar-ho.
Què és important aquí? El valor del camp de l'etiqueta de flux canvia a un nombre aleatori després de cada RTO. Com afecta això al nostre desafortunat flux TCP?
Si es produeix un SACK, no canvia res perquè estem intentant tornar a enviar un paquet perdut conegut. Fins ara, tot bé.
Però en el cas de RTO, sempre que hàgim afegit una etiqueta de flux a la funció hash del ToR, el trànsit pot prendre una ruta diferent. I com més carrils, major serà la possibilitat que trobi un camí que no es vegi afectat per una fallada en un dispositiu específic.
Hi ha un problema: RTO. Per descomptat, hi ha una altra ruta, però en això es perd molt de temps. 200 ms són molts. Un segon és absolutament salvatge. Anteriorment, vaig parlar dels temps d'espera que es configuren els serveis. Per tant, un segon és un temps d'espera, que normalment el configura el servei a nivell d'aplicació, i en això el servei fins i tot serà relativament correcte. A més, repeteixo, l'RTT real dins d'un centre de dades modern és d'un mil·lisegon.
Què pots fer amb els temps d'espera de RTO? El temps d'espera, responsable del RTO en cas de pèrdua de paquets de dades, es pot configurar amb relativa facilitat des de l'espai d'usuari: hi ha una utilitat IP i un dels seus paràmetres conté el mateix rto_min. Tenint en compte que RTO, per descomptat, s'ha d'ajustar no globalment, sinó per a prefixos determinats, aquest mecanisme sembla força viable.
És cert que amb SYN_RTO tot és una mica pitjor. Està clavat de forma natural. El nucli té un valor fix d'1 segon, i això és tot. No hi podeu accedir des de l'espai d'usuari. Només hi ha una manera.
eBPF ve al rescat. Per dir-ho simplement, es tracta de petits programes en C. Es poden inserir en ganxos en diferents llocs de l'execució de la pila del nucli i la pila TCP, amb els quals podeu canviar un nombre molt gran de configuracions. En general, eBPF és una tendència a llarg termini. En lloc de tallar desenes de nous paràmetres sysctl i ampliar la utilitat IP, el moviment s'està avançant cap a eBPF i ampliant la seva funcionalitat. Amb eBPF, podeu canviar dinàmicament els controls de congestió i altres configuracions de TCP.
Però és important per a nosaltres que es pugui utilitzar per canviar els valors SYN_RTO. A més, hi ha un exemple publicat públicament: . Què s'ha fet aquí? L'exemple funciona, però en si mateix és molt aspre. Aquí se suposa que dins del centre de dades comparem els primers 44 bits; si coincideixen, llavors estem dins del centre de dades. I en aquest cas canviem el valor del temps d'espera SYN_RTO a 4 ms. La mateixa tasca es pot fer de manera molt més elegant. Però aquest exemple senzill mostra que això és a) possible; b) relativament simple.
Què sabem ja? El fet que l'arquitectura del pla permet escalar, resulta ser extremadament útil per a nosaltres quan activem l'etiqueta de flux al ToR i obtenim la capacitat de fluir per les àrees problemàtiques. La millor manera de reduir els valors RTO i SYN-RTO és utilitzar programes eBPF. La pregunta segueix sent: és segur utilitzar una etiqueta de flux per equilibrar? I aquí hi ha un matís.
Suposem que teniu un servei a la vostra xarxa que viu a anycast. Malauradament, no tinc temps d'entrar en detall sobre què és anycast, però és un servei distribuït amb diferents servidors físics accessibles mitjançant la mateixa adreça IP. I aquí hi ha un possible problema: l'esdeveniment RTO pot ocórrer no només quan el trànsit passa pel teixit. També pot ocórrer al nivell de memòria intermèdia ToR: quan es produeix un esdeveniment d'incast, fins i tot pot ocórrer a l'amfitrió quan l'amfitrió vessa alguna cosa. Quan es produeix un esdeveniment RTO i canvia l'etiqueta de flux. En aquest cas, el trànsit pot anar a una altra instància anycast. Suposem que es tracta d'un anycast amb estat, que conté un estat de connexió; podria ser un equilibrador L3 o algun altre servei. Aleshores sorgeix un problema, perquè després de RTO la connexió TCP arriba al servidor, que no sap res sobre aquesta connexió TCP. I si no tenim l'estat compartit entre els servidors anycast, aquest trànsit s'eliminarà i la connexió TCP es trencarà.
Què pots fer aquí? Dins del vostre entorn controlat, on activeu l'equilibri d'etiquetes de flux, heu d'enregistrar el valor de l'etiqueta de flux quan accediu als servidors anycast. La manera més senzilla és fer-ho mitjançant el mateix programa eBPF. Però aquí hi ha un punt molt important: què fer si no opereu una xarxa de centre de dades, però sou un operador de telecomunicacions? Aquest també és el vostre problema: a partir de determinades versions de Juniper i Arista, inclouen una etiqueta de flux a les seves funcions hash de manera predeterminada, francament, per un motiu que no em queda clar. Això pot fer que elimineu les connexions TCP dels usuaris que passen per la vostra xarxa. Per tant, us recomano que comproveu la configuració del vostre encaminador aquí.
D'una manera o altra, em sembla que estem preparats per passar als experiments.
Quan vam habilitar l'etiqueta de flux al ToR, vam preparar l'agent eBPF, que ara viu als amfitrions, vam decidir no esperar el següent gran error, sinó fer explosions controlades. Vam agafar el ToR, que té quatre enllaços ascendents, i vam configurar drops en un d'ells. Van dibuixar una regla i van dir: ara estàs perdent tots els paquets. Com podeu veure a l'esquerra, tenim un seguiment per paquet, que ha baixat al 75%, és a dir, es perden el 25% dels paquets. A la dreta hi ha gràfics dels serveis que hi ha darrere d'aquest TdR. Essencialment, es tracta de gràfics de trànsit de les interfícies amb servidors dins del bastidor. Com podeu veure, es van enfonsar encara més. Per què van baixar, no en un 25%, però en alguns casos en 3-4 vegades? Si la connexió TCP no té sort, continua intentant arribar a través de la unió trencada. Això s'agreuja pel comportament típic del servei dins del DC: per a una sol·licitud d'usuari, es generen N sol·licituds als serveis interns i la resposta anirà a l'usuari quan responguin totes les fonts de dades o quan es produeixi un temps d'espera a l'aplicació. nivell, que encara s'ha de configurar. És a dir, tot és molt, molt dolent.
Ara el mateix experiment, però amb el valor de l'etiqueta de flux activat. Com podeu veure, a l'esquerra el nostre seguiment per lots va baixar el mateix 25%. Això és absolutament correcte, perquè no sap res de retransmissions, envia paquets i simplement compta la relació entre el nombre de paquets lliurats i perduts.
I a la dreta hi ha l'horari del servei. Aquí no trobareu l'efecte d'una articulació problemàtica. En aquests mateixos mil·lisegons, el trànsit va fluir des de l'àrea problemàtica als tres enllaços amunt restants que no es van veure afectats pel problema. Tenim una xarxa que es cura a si mateixa.
Aquesta és la meva darrera diapositiva, moment de resumir. Ara, espero que sàpigues com crear una xarxa de centres de dades d'autocuració. No haureu de passar per l'arxiu del nucli de Linux i buscar-hi pedaços especials; ja sabeu que l'etiqueta Flow en aquest cas resol el problema, però heu d'abordar aquest mecanisme amb cura. I recalco una vegada més que si sou un operador de telecomunicacions, no hauríeu d'utilitzar l'etiqueta de flux com a funció hash, en cas contrari interrompreu les sessions dels vostres usuaris.
Els enginyers de xarxa han de patir un canvi conceptual: la xarxa no comença amb el ToR, no amb el dispositiu de xarxa, sinó amb l'amfitrió. Un exemple bastant sorprenent és com fem servir eBPF tant per canviar el RTO com per arreglar l'etiqueta de flux cap als serveis anycast.
Sens dubte, la mecànica d'etiquetes de flux és adequada per a altres aplicacions dins del segment administratiu controlat. Pot ser trànsit entre centres de dades o podeu utilitzar aquests mecanismes d'una manera especial per gestionar el trànsit de sortida. Però t'ho parlaré, espero, la propera vegada. Moltes gràcies per la seva atenció.
Font: www.habr.com