Os centros de datos modernos teñen centos de dispositivos activos cubertos por diferentes tipos de monitorización. Pero mesmo un enxeñeiro perfecto cunha supervisión perfecta na man poderá responder correctamente a un fallo da rede en poucos minutos. Nun informe da conferencia Next Hop 2020, presentei unha metodoloxía de deseño de rede de centros de datos que ten unha característica única: o centro de datos se cura en milisegundos. Máis precisamente, o enxeñeiro soluciona o problema con calma, mentres que os servizos simplemente non o notan.
Para moitos enxeñeiros de rede, a rede do centro de datos comeza, por suposto, con ToR, cun interruptor no rack. ToR adoita ter dous tipos de ligazóns. Os máis pequenos van aos servidores, outros -son N veces máis- van cara ás espiñas de primeiro nivel, é dicir, aos seus enlaces ascendentes. As ligazóns ascendentes adoitan considerarse iguais e o tráfico entre as ligazóns ascendentes é equilibrada en función do hash de 5 tuplas, que inclúe proto, src_ip, dst_ip, src_port, dst_port. Aquí non hai sorpresas.
A continuación, como é a arquitectura dos avións? As espiñas do primeiro nivel non están conectadas entre si, senón que están conectadas por medio de superspins. A letra X será a responsable dos superspins, é case como unha conexión cruzada.
E está claro que, por outra banda, os tori están conectados a todas as espiñas do primeiro nivel. Que é importante nesta imaxe? Se temos interacción dentro do rack, entón a interacción, por suposto, pasa por ToR. Se a interacción vai dentro do módulo, entón a interacción pasa polas espiñas do primeiro nivel. Se a interacción é intermodular, como aquí, ToR 1 e ToR 2, entón a interacción pasará polas columnas tanto do primeiro como do segundo nivel.
Teoricamente, tal arquitectura é facilmente escalable. Se temos capacidade de porto, unha reserva de espazo no centro de datos e unha fibra pre-colocada, entón sempre se pode aumentar o número de avións, aumentando así a capacidade global do sistema. No papel, isto é moi sinxelo de facer. Sería así na vida real. Pero a historia de hoxe non trata diso.
Quero que se saquen as conclusións correctas. Temos moitos camiños dentro do centro de datos. Son condicionalmente independentes. Un camiño dentro do centro de datos só é posible dentro do ToR. Dentro do módulo, temos o mesmo número de camiños que o de planos. O número de camiños entre módulos é igual ao produto do número de planos e do número de superspins en cada plano. Para que quede máis claro, para sentir a escala, darei os números que son válidos para un dos centros de datos de Yandex.
Hai oito avións, cada avión ten 32 superspins. Como resultado, resulta que hai oito camiños dentro do módulo, e coa interacción entre módulos xa hai 256 deles.
É dicir, se estamos a desenvolver un libro de receitas, intentando aprender a construír centros de datos tolerantes a fallos que se curan a si mesmos, entón a arquitectura plana é a opción correcta. Permítelle resolver o problema de escalado e, en teoría, é doado. Hai moitos camiños independentes. A pregunta segue sendo: como sobrevive unha arquitectura así aos fallos? Hai varios accidentes. E discutiremos isto agora.
Que un dos nosos superspins se enferme. Aquí volvín á arquitectura de dous planos. Seguirémonos con eles como exemplo porque simplemente será máis fácil ver o que está a suceder aquí con menos pezas móbiles. Que X11 se enferme. Como afectará isto aos servizos que viven dentro dos centros de datos? Moito depende de como se vexa o fallo.
Se o fallo é bo, queda atrapado no nivel de automatización do mesmo BFD, a automatización pon felizmente as articulacións do problema e illa o problema, entón todo está ben. Temos moitos camiños, o tráfico desvíase ao instante a rutas alternativas e os servizos non notarán nada. Este é un bo escenario.
Un mal escenario é se temos perdas constantes, e a automatización non nota o problema. Para comprender como afecta isto á aplicación, teremos que dedicar un pouco a discutir como funciona o protocolo TCP.
Espero non sorprender a ninguén con esta información: TCP é un protocolo de apretón de mans. É dicir, no caso máis sinxelo, o remitente envía dous paquetes, e recibe unha confirmación acumulada sobre eles: "Recibín dous paquetes".
Despois diso, enviará dous paquetes máis e a situación repetirase. Pido desculpas de antemán por algunha simplificación. Este escenario é correcto se a xanela (número de paquetes en voo) é dúas. Por suposto, este non é necesariamente o caso en xeral. Pero o contexto de reenvío de paquetes non se ve afectado polo tamaño da xanela.
Que pasa se perdemos o paquete 3? Neste caso, o destinatario recibirá os paquetes 1, 2 e 4. E informará expresamente ao remitente mediante a opción SACK: "Xa sabes, viñeron tres, pero perdeuse o medio". El di "Ack 2, SACK 4".
O remitente neste momento repite exactamente o paquete que se perdeu sen ningún problema.
Pero se se perde o último paquete na xanela, a situación será moi diferente.
O destinatario recibe os tres primeiros paquetes e primeiro comeza a esperar. Grazas a algunhas optimizacións na pila TCP do núcleo de Linux, agardará por un paquete emparellado, a non ser que haxa unha indicación explícita nas bandeiras de que este é o último paquete ou algo así. Esperará ata que caduque o tempo de espera de ACK retardado e despois enviará un acuse de recibo para os tres primeiros paquetes. Pero agora o remitente estará esperando. Non sabe se o cuarto paquete se perdeu ou está a piques de chegar. E para non sobrecargar a rede, intentará esperar a que se indique explícitamente que o paquete está perdido ou a expiración do tempo de espera do RTO.
Que é o tempo de espera do RTO? Este é o máximo do RTT calculado pola pila TCP e algunha constante. Cal é esta constante, agora comentaremos.
Pero é importante que se volvemos a ter mala sorte e volvemos a perder o cuarto paquete, entón o RTO dobre. É dicir, cada intento infrutuoso é unha duplicación do tempo morto.
Agora vexamos a que equivale esta base. Por defecto, o RTO mínimo é de 200 ms. Este é o RTO mínimo para paquetes de datos. Para os paquetes SYN, é diferente, 1 segundo. Como podes ver, incluso o primeiro intento de reenviar paquetes levará 100 veces máis que RTT dentro do centro de datos.
Agora volvemos ao noso escenario. Que está a pasar co servizo? O servizo comeza a perder paquetes. Deixa que o servizo teña inicialmente sorte e perda algo no medio da xanela, despois recibe un SACK, reenvía os paquetes perdidos.
Pero se a mala sorte repite, entón temos un RTO. Que é importante aquí? Si, temos moitos camiños na rede. Pero o tráfico TCP dunha conexión TCP en particular continuará pasando pola mesma pila rota. A perda de paquetes, sempre que o noso X11 máxico non se apague por si só, non leva a que o tráfico circule cara a zonas que non son problemáticas. Estamos tentando entregar un paquete a través da mesma pila rota. Isto leva a un fallo en cascada: un centro de datos é un conxunto de aplicacións que interactúan e algunhas das conexións TCP de todas estas aplicacións comezan a degradarse, porque o superspin afecta a todas as aplicacións que están dentro do DC. Como o dito: se non ferras un cabalo, o cabalo coxea; o cabalo manxeou - o informe non foi entregado; a mensaxe non foi entregada - perderon a guerra. Só aquí a conta vai por segundos desde que se produce o problema ata a etapa de degradación que comezan a sentir os servizos. Isto significa que os usuarios poden non recibir algo nalgún lugar.
Hai dúas solucións clásicas que se complementan. O primeiro son os servizos que intentan botar palletas e resolver o problema así: “Imos axustar algo na pila TCP. E fagamos tempo de espera a nivel de aplicación ou sesións TCP de longa duración con comprobacións de saúde internas. O problema é que tales solucións: a) non escalan nada; b) moi mal probado. É dicir, aínda que o servizo configure accidentalmente a pila TCP para que se faga mellor, en primeiro lugar, é improbable que isto sexa aplicable a todas as aplicacións e todos os centros de datos e, en segundo lugar, o máis probable é que non entenda o que se fixo correctamente e que non. É dicir, funciona, pero funciona mal e non escala. E se hai un problema de rede, quen é a culpa? Por suposto NOC. Que fai NOC?
Moitos servizos cren que en NOC, o traballo vai algo así. Pero para ser honesto, non só.
NOC no esquema clásico está implicado no desenvolvemento de moitos seguimento. Trátase tanto de monitorización de caixa negra como de monitorización de caixa branca. Sobre o exemplo da caixa negra de vixilancia de columnas Alexander Klimenko sobre o pasado Next Hop. Por certo, esta vixilancia funciona. Pero incluso un seguimento perfecto terá un desfase de tempo. Normalmente son varios minutos. Despois de que funcione, os enxeñeiros de servizo necesitan tempo para comprobar o seu funcionamento, localizar o problema e despois extinguir a área problemática. É dicir, no mellor dos casos, o tratamento do problema leva 5 minutos, no peor de 20 minutos, se non é inmediatamente evidente onde se producen as perdas. Está claro que durante todo este tempo -5 ou 20 minutos- os nosos servizos seguirán prexudicando, o que probablemente non sexa bo.
Que che gustaría recibir? Temos tantos camiños. E os problemas xorden precisamente porque os fluxos TCP que non teñen sorte seguen a usar a mesma ruta. Necesitamos algo que nos permita utilizar varias rutas dentro dunha única conexión TCP. Parece que temos unha solución. Hai TCP, que se chama así - TCP multiruta, é dicir, TCP para moitos camiños. É certo, foi desenvolvido para unha tarefa completamente diferente: para teléfonos intelixentes que teñen varios dispositivos de rede. Para maximizar a transferencia ou facer o modo principal/copia de seguridade, desenvolveuse un mecanismo que crea de forma transparente varios fíos (sesións) para a aplicación e permite cambiar entre eles en caso de falla. Ou, como dixen, maximizar o ancho de banda.
Pero aquí hai un matiz. Para entender o que é, teremos que ver como se configuran os fluxos.
Os fíos están configurados secuencialmente. O primeiro fluxo instálase primeiro. Os fluxos posteriores establécense entón utilizando a cookie xa acordada nese fío. E aquí está o problema.
O problema é que se o primeiro fío non se instala, o segundo e o terceiro nunca aparecerán. É dicir, o TCP multiruta non resolve a perda do paquete SYN no primeiro fluxo. E se se perde o SYN, o TCP multiruta pasa a ser o TCP normal. Entón, nun ambiente de centro de datos, non nos axudará a resolver o problema das perdas na fábrica e aprender a utilizar varios camiños en caso de falla.
Que nos pode axudar? Algúns de vós xa adiviñades polo nome que o campo importante da nosa historia posterior será o campo de cabeceira da etiqueta de fluxo IPv6. De feito, este é un campo que aparece na v6, non está na v4, leva 20 bits e hai moito tempo que hai polémica sobre o seu uso. Isto é moi interesante: houbo disputas, algo arranxouse no marco do RFC e, ao mesmo tempo, apareceu unha implementación no núcleo de Linux que nunca foi documentada en ningún lado.
Suxiro que me acompañes nunha pequena investigación. Vexamos o que pasou no núcleo de Linux nos últimos anos.
ano 2014. Un enxeñeiro dunha empresa grande e respetable engade á funcionalidade do núcleo de Linux a dependencia do valor da etiqueta de fluxo no hash do socket. Que están intentando arranxar aquí? Isto está relacionado co RFC 6438 que discutiu o seguinte problema. Dentro do centro de datos, IPv4 adoita estar encapsulado en paquetes IPv6, porque a propia fábrica é IPv6, pero o IPv4 debe ser entregado dalgún xeito. Durante moito tempo houbo problemas cos switches que non podían buscar baixo dúas cabeceiras IP para chegar a TCP ou UDP e atopar alí src_ports, dst_ports. Resultou que o hash, se miras as dúas primeiras cabeceiras IP, resultou case corrixido. Para evitar isto, para que o balance deste tráfico encapsulado funcione correctamente, propúxose engadir un hash do paquete encapsulado de 5 tuplas ao valor do campo da etiqueta de fluxo. Aproximadamente o mesmo se fixo para outros esquemas de encapsulación, para UDP, para GRE, neste último usouse o campo GRE Key. Dun xeito ou doutro, os obxectivos aquí están claros. E polo menos naquel momento foron útiles.
En 2015, un novo parche vén do mesmo respectado enxeñeiro. É moi interesante. Di o seguinte: aleatorizaremos o hash en caso dun evento de enrutamento negativo. Que é un evento de enrutamento negativo? Este é o RTO que comentamos anteriormente, é dicir, a perda da cola da xanela é un evento realmente negativo. Verdade, é relativamente difícil adiviñar o que é.
2016, outra empresa respectada, tamén grande. Analiza as últimas muletas e fai que o hash que antes fixeramos aleatoriamente agora cambie en cada retransmisión SYN e despois de cada tempo de espera RTO. E nesta carta, por primeira e última vez, soa o obxectivo final: asegurarse de que o tráfico en caso de perda ou sobrecarga de canles teña a posibilidade de desvío suave, utilizando varios camiños. Por suposto, despois de que houbo moitas publicacións, podes atopalas facilmente.
Aínda que non, non podes, porque non houbo nin unha soa publicación sobre este tema. Pero sabemos!
E se non entendes ben o que se fixo, xa cho contarei.
Que se fixo, que funcionalidades se engadiu ao núcleo de Linux? txhash cambia a un valor aleatorio despois de cada evento RTO. Este é o mesmo resultado negativo de enrutamento. O hash depende deste txhash e a etiqueta de fluxo depende do hash skb. Aquí hai algúns cálculos sobre as funcións, todos os detalles non se poden colocar nunha soa diapositiva. Se alguén ten curiosidade, pode revisar o código do núcleo e comprobar.
Que é importante aquí? O valor do campo da etiqueta de fluxo cambia a un número aleatorio despois de cada RTO. Como afecta isto ao noso desafortunado fluxo TCP?
No caso dun SACK, nada cambiou porque estamos tentando reenviar un paquete perdido coñecido. Ata aquí todo ben.
Pero no caso de RTO, sempre que engadimos unha etiqueta de fluxo á función hash en ToR, o tráfico pode tomar unha ruta diferente. E cantos máis avións, máis probable é que atope un camiño que non se vexa afectado por un accidente nun dispositivo en particular.
Persiste un problema: RTO. Atópase outra ruta, por suposto, pero pásase moito tempo nela. 200 ms son moito. Un segundo é xeralmente salvaxe. Antes, falei dos tempos de espera que configuran os servizos. Entón, un segundo é un tempo de espera que adoita configurar un servizo a nivel de aplicación, e nisto o servizo incluso será relativamente correcto. Ademais, repito, o RTT real dentro dun centro de datos moderno é de aproximadamente 1 milisegundo.
Que se pode facer sobre os tempos de espera do RTO? O tempo de espera que é responsable do RTO en caso de perda de paquetes de datos pódese configurar con relativa facilidade desde o espazo do usuario: hai unha utilidade IP e un dos seus parámetros contén o mesmo rto_min. Tendo en conta que, por suposto, cómpre converter o RTO non globalmente, pero para determinados prefixos, tal mecanismo parece funcionar bastante.
É certo que con SYN_RTO todo é algo peor. Está naturalmente cravado. O valor está fixado no núcleo - 1 segundo, e iso é todo. Non podes acceder a el desde o espazo de usuario. Só hai un camiño.
eBPF vén ao rescate. Para dicilo de forma sinxela, trátase de pequenos programas en C. Pódense inserir en ganchos en diferentes lugares da execución da pila do núcleo e da pila TCP, cos que se pode cambiar un gran número de configuracións. En xeral, eBPF é unha tendencia a longo prazo. En lugar de cortar ducias de novos parámetros sysctl e ampliar a utilidade IP, o movemento vai na dirección de eBPF e amplía a súa funcionalidade. Con eBPF, pode cambiar de forma dinámica os controis de conxestión e outras opcións de TCP.
Pero é importante para nós que coa axuda del podes torcer os valores de SYN_RTO. E hai un exemplo publicado publicamente: . Que se fai aquí? O exemplo está funcionando, pero en si é moi tosco. Suponse aquí que dentro do centro de datos comparamos os primeiros 44 bits, se coinciden, entón atopámonos dentro do DC. E neste caso, cambiamos o valor do tempo de espera SYN_RTO a 4 ms. A mesma tarefa pódese facer con moita máis graza. Pero este sinxelo exemplo mostra o que é a) posible; b) relativamente fácil.
Que sabemos xa? Que a arquitectura plana permite escalar, resulta ser moi útil para nós cando activamos a etiqueta de fluxo en ToR e temos a oportunidade de fluír por áreas problemáticas. A mellor forma de baixar os valores RTO e SYN-RTO é usar programas eBPF. A pregunta segue sendo: é seguro usar a etiqueta de fluxo para o equilibrio? E aquí hai un matiz.
Supoña que tes un servizo na rede que vive en anycast. Desafortunadamente, non teño tempo para entrar en detalles sobre anycast, pero é un servizo distribuído onde hai diferentes servidores físicos dispoñibles no mesmo enderezo IP. E aquí hai un posible problema: o evento RTO pode ocorrer non só cando o tráfico pasa pola fábrica. Tamén pode ocorrer no nivel do búfer ToR: cando se produce un evento de incast, incluso pode ocorrer no host cando o host derrama algo. Cando se produce un evento RTO e cambia a etiqueta de fluxo. Neste caso, o tráfico pode ir a outra instancia anycast. Supoñamos que é un anycast con estado, que contén un estado de conexión; pode ser un equilibrador L3 ou algún outro servizo. Entón xorde un problema, porque despois do RTO, a conexión TCP chega ao servidor, que non sabe nada desta conexión TCP. E se non temos o estado compartido entre servidores anycast, entón o tráfico será eliminado e a conexión TCP romperase.
Que se pode facer aquí? Dentro do seu contorno controlado, no que activa o balance de etiquetas de fluxo, cómpre corrixir o valor da etiqueta de fluxo ao acceder aos servidores anycast. O xeito máis sinxelo é facelo a través do mesmo programa eBPF. Pero aquí hai un punto moi importante: que facer se non opera unha rede de centro de datos, pero é un operador de telecomunicacións? Este tamén é o teu problema: comezando con certas versións de Juniper e Arista, inclúen a etiqueta de fluxo na función hash de forma predeterminada; para ser honesto, por unha razón que non entendo. Isto pode facer que elimines as conexións TCP dos usuarios que pasan pola túa rede. Polo tanto, recomendo encarecidamente comprobar a configuración do seu enrutador neste lugar.
Dun xeito ou doutro, paréceme que estamos preparados para pasar aos experimentos.
Cando activamos a etiqueta de fluxo no ToR, preparamos o eBPF do axente, que agora vive nos anfitrións, decidimos non esperar ao seguinte gran fallo, senón realizar explosións controladas. Tomamos ToR, que ten catro ligazóns ascendentes, e fixemos caídas nun deles. Debuxaron unha regra, dixeron: agora estás perdendo todos os paquetes. Como podes ver á esquerda, temos un seguimento por paquete, que baixou ata o 75%, é dicir, pérdense o 25% dos paquetes. Á dereita están os gráficos dos servizos que viven detrás deste TdR. De feito, estes son gráficos de tráfico de articulacións con servidores dentro do rack. Como podes ver, afundiron aínda máis. Por que afundiron máis, non nun 25%, pero nalgúns casos en 3-4 veces? Se a conexión TCP non ten sorte, segue intentando acceder a través da interface rota. Isto vese agravado polo comportamento típico do servizo dentro do DC: para unha solicitude de usuario, xéranse N solicitudes a servizos internos e a resposta irá ao usuario, xa sexa cando respondan todas as fontes de datos ou cando se desencadee un tempo de espera en o nivel de aplicación, que aínda debe configurarse. É dicir, todo está moi, moi mal.
Agora o mesmo experimento, pero coa etiqueta de fluxo activada. Como podes ver, á esquerda, o noso seguimento de lotes afundiuse nun mesmo 25%. Isto é absolutamente correcto, porque non sabe nada de retransmisións, envía paquetes e simplemente conta a relación entre o número de paquetes entregados e perdidos.
E á dereita está o horario dos servizos. Non atoparás aquí o efecto dunha articulación problemática. Neses mesmos milisegundos o tráfico fluíu desde a zona problemática ata as tres ligazóns ascendentes restantes que non se viron afectadas polo problema. Temos unha rede que se cura a si mesma.
Esta é a miña última diapositiva, hora de facer balance. Agora, espero que saibas como construír unha rede de centros de datos de autocuración. Non necesitarás pasar polo arquivo do núcleo de Linux e buscar alí parches especiais, xa sabes que a etiqueta Flow resolve o problema neste caso, pero tes que abordar este mecanismo con coidado. E insisto de novo en que se es un operador, non debes usar a etiqueta de fluxo como función hash, se non, romperás as sesións dos teus usuarios.
Para os enxeñeiros de rede, é necesario que se produza un cambio conceptual: a rede non comeza con ToR, non cun dispositivo de rede, senón cun host. Un exemplo bastante rechamante é como usamos eBPF tanto para cambiar o RTO como para fixar a etiqueta de fluxo cara aos servizos anycast.
A mecánica de etiquetas de fluxo é certamente adecuada para outros usos dentro do segmento administrativo controlado. Pode tratarse de tráfico entre centros de datos ou pode utilizar este tipo de mecánicas dun xeito especial para controlar o tráfico de saída. Pero disto falarei, espero, a próxima vez. Moitas grazas pola túa atención.
Fonte: www.habr.com