A web moderna é case impensable sen contido multimedia: case todas as avoas teñen un teléfono intelixente, todo o mundo está nas redes sociais e o tempo de inactividade no mantemento é custoso para as empresas. Aquí tes unha transcrición da historia da empresa sobre como organizou a entrega de fotos mediante unha solución de hardware, que problemas de rendemento atopou no proceso, que os causou e como se solucionaron estes problemas mediante unha solución de software baseada en Nginx, ao tempo que se garante a tolerancia a fallos a todos os niveis (). Agradecemos aos autores da historia de Oleg Efimova e Alexandra Dymova, que compartiron a súa experiencia na conferencia .
— Comecemos cunha pequena introdución sobre como almacenamos e almacenamos as fotos na caché. Temos unha capa onde as almacenamos, e unha capa onde almacenamos as fotos na caché. Ao mesmo tempo, se queremos conseguir unha alta taxa de trucos e reducir a carga do almacenamento, é importante para nós que cada foto dun usuario individual estea nun servidor de caché. En caso contrario, teriamos que instalar tantas veces máis discos como servidores teñamos. A nosa taxa de trucos rolda o 99%, é dicir, estamos reducindo 100 veces a carga do noso almacenamento e, para iso, hai 10 anos, cando se construíu todo isto, tiñamos 50 servidores. En consecuencia, para poder servir estas fotos, necesitábamos esencialmente 50 dominios externos aos que serven estes servidores.
Por suposto, inmediatamente xurdiu a pregunta: se un dos nosos servidores falla e non está dispoñible, que parte do tráfico perdemos? Miramos o que había no mercado e decidimos mercar unha peza de hardware para que solucione todos os nosos problemas. A elección recaeu na solución da empresa de rede F5 (que, por certo, comprou recentemente NGINX, Inc): BIG-IP Local Traffic Manager.
O que fai esta peza de hardware (LTM): é un enrutador de ferro que fai redundancia de ferro dos seus portos externos e permite enrutar o tráfico en función da topoloxía da rede, nalgunhas configuracións e realiza comprobacións de saúde. Era importante para nós que esta peza de hardware puidese ser programada. En consecuencia, poderiamos describir a lóxica de como as fotografías dun usuario específico foron servidas desde unha caché específica. Que aspecto ten? Hai unha peza de hardware que mira a Internet nun dominio, unha IP, descarga ssl, analiza as solicitudes http, selecciona un número de caché de IRule, onde ir e deixa que o tráfico vaia alí. Ao mesmo tempo, fai comprobacións de saúde e, no caso de que algunha máquina non estea dispoñible, nese momento fixemos que o tráfico pasase a un servidor de copia de seguridade. Desde o punto de vista da configuración, hai, por suposto, algúns matices, pero en xeral todo é bastante sinxelo: rexistramos unha tarxeta, correspondencia dun determinado número coa nosa IP na rede, dicimos que escoitaremos nos portos 80. e 443, dicimos que se o servidor non está dispoñible, entón cómpre enviar tráfico ao backup, neste caso o 35, e describimos unha morea de lóxica sobre como se debe desmontar esta arquitectura. O único problema foi que a linguaxe na que se programaba o hardware era Tcl. Se alguén lembra isto... esta linguaxe é máis de só escritura que unha linguaxe conveniente para a programación:
Que conseguimos? Recibimos un hardware que garante a alta dispoñibilidade da nosa infraestrutura, encamiña todo o noso tráfico, proporciona beneficios para a saúde e só funciona. Ademais, funciona durante bastante tempo: nos últimos 10 anos non houbo queixas respecto diso. A principios de 2018, xa estabamos enviando preto de 80 fotos por segundo. Isto supón uns 80 gigabits de tráfico dos nosos dous centros de datos.
Sen embargo…
A principios de 2018, vimos unha imaxe fea nas listas: o tempo que tardaba en enviar fotos aumentara claramente. E deixou de cabernos. O problema é que este comportamento só era visible durante o pico de tráfico: para a nosa empresa esta é a noite de domingo a luns. Pero o resto do tempo o sistema comportouse como sempre, sen signos de fracaso.
Con todo, o problema tiña que ser resolto. Identificamos posibles colos de botella e comezamos a eliminalos. Primeiro de todo, por suposto, ampliamos as ligazóns ascendentes externas, realizamos unha auditoría completa das ligazóns ascendentes internas e atopamos todos os posibles pescozos de botella. Pero todo isto non deu un resultado obvio, o problema non desapareceu.
Outro posible pescozo de botella foi a realización dos propios cachés de fotos. E decidimos que quizais o problema resida neles. Ben, ampliamos o rendemento, principalmente os portos de rede nas cachés de fotos. Pero de novo non se viu ningunha mellora evidente. Ao final, prestamos moita atención ao rendemento do propio LTM, e aquí vimos unha imaxe triste nos gráficos: a carga de todas as CPU comeza a ir sen problemas, pero de súpeto chega a unha meseta. Ao mesmo tempo, LTM deixa de responder adecuadamente ás comprobacións de saúde e ás ligazóns ascendentes e comeza a desactivalas aleatoriamente, o que leva a unha grave degradación do rendemento.
É dicir, identificamos a orixe do problema, identificamos o pescozo de botella. Queda por decidir o que imos facer.
O primeiro, o máis obvio que poderiamos facer é modernizar dalgún xeito o propio LTM. Pero hai algúns matices aquí, porque este hardware é bastante único, non vai ir ao supermercado máis próximo e mercalo. Este é un contrato separado, un contrato de licenza separado, e levará moito tempo. A segunda opción é comezar a pensar por ti mesmo, crear a túa propia solución utilizando os teus propios compoñentes, preferiblemente mediante un programa de acceso aberto. Só queda decidir que escolleremos exactamente para iso e canto tempo dedicaremos a solucionar este problema, porque os usuarios non estaban a recibir fotos suficientes. Polo tanto, hai que facer todo isto moi, moi rápido, poderíase dicir onte.
Dado que a tarefa soaba como "facer algo o máis rápido posible e usando o hardware que temos", o primeiro que pensamos foi simplemente eliminar algunhas máquinas non moi potentes da parte frontal, poñer alí Nginx, co que sabemos como traballar e tentar implementar a mesma lóxica que facía o hardware. É dicir, de feito, deixamos o noso hardware, instalamos 4 servidores máis que tiñamos que configurar, creamos dominios externos para eles, como hai 10 anos... Perdemos un pouco de dispoñibilidade se caían estas máquinas, pero aínda menos, solucionaron o problema dos nosos usuarios a nivel local.
En consecuencia, a lóxica segue a ser a mesma: instalamos Nginx, pode facer a descarga SSL, podemos programar dalgún xeito a lóxica de enrutamento, comprobacións de saúde nas configuracións e simplemente duplicar a lóxica que tiñamos antes.
Sentámonos a escribir as configuracións. Ao principio parecía que todo era moi sinxelo, pero, por desgraza, é moi difícil atopar manuais para cada tarefa. Polo tanto, non recomendamos simplemente buscar en Google "como configurar Nginx para fotos": é mellor consultar a documentación oficial, que mostrará cales son as opcións que se deben tocar. Pero é mellor escoller un parámetro específico. Pois todo é sinxelo: describimos os servidores que temos, describimos os certificados... Pero o máis interesante é, de feito, a propia lóxica de enrutamento.
Nun primeiro momento pareceunos que simplemente estabamos describindo a nosa localización, facendo coincidir o número da nosa caché de fotos nela, usando as nosas mans ou un xerador para describir cantas augas arriba necesitamos, en cada augas arriba indicamos o servidor ao que debe o tráfico. go, e un servidor de copia de seguridade - se o servidor principal non está dispoñible:
Pero, probablemente, se todo fose tan sinxelo, simplemente iríamos a casa e non diríamos nada. Desafortunadamente, coa configuración predeterminada de Nginx, que, en xeral, realizouse ao longo de moitos anos de desenvolvemento e non son totalmente adecuadas para este caso... a configuración ten o seguinte aspecto: se algún servidor upstream ten un erro de solicitude ou tempo de espera, Nginx sempre cambia o tráfico ao seguinte. Ademais, despois do primeiro fallo, dentro de 10 segundos, o servidor tamén se apagará, tanto por erro como por tempo de espera, nin sequera se pode configurar de ningún xeito. É dicir, se eliminamos ou restablecemos a opción de tempo de espera na directiva upstream, aínda que Nginx non procesará esta solicitude e responderá con algún erro non moi bo, o servidor apagarase.
Para evitar isto, fixemos dúas cousas:
a) prohibiron a Nginx facelo manualmente e, por desgraza, a única forma de facelo é simplemente establecer a configuración de fallos máximos.
b) Lembramos que noutros proxectos utilizamos un módulo que nos permite facer controis de saúde de antecedentes -en consecuencia, fixemos controis de saúde bastante frecuentes para que o tempo de inactividade en caso de accidente fose mínimo.
Desafortunadamente, isto tampouco é todo, porque literalmente as dúas primeiras semanas de funcionamento deste esquema mostraron que a comprobación de saúde de TCP tampouco é algo fiable: no servidor upstream pode non ser Nginx, ou Nginx en estado D, e en estado D. neste caso, o núcleo aceptará a conexión, a comprobación de saúde pasará, pero non funcionará. Polo tanto, inmediatamente substituímos isto por http de verificación de saúde, fixemos un específico que, se devolve 200, todo funciona neste script. Podes facer lóxica adicional, por exemplo, no caso dos servidores de caché, comprobe que o sistema de ficheiros está montado correctamente:
E isto conviríanos, salvo que de momento o circuíto repetiu por completo o que fixo o hardware. Pero queriamos facelo mellor. Anteriormente, tiñamos un servidor de copia de seguridade, e probablemente non sexa moi bo, porque se tes cen servidores, cando varios fallan á vez, é improbable que un servidor de copia de seguranza faga fronte á carga. Por iso, decidimos distribuír a reserva en todos os servidores: simplemente fixemos outra separada upstream, escribimos alí todos os servidores con determinados parámetros de acordo coa carga que poidan servir, engadimos as mesmas comprobacións de saúde que tiñamos antes:
Dado que é imposible ir a outro río arriba dentro dun río ascendente, era necesario asegurarse de que se non estaba dispoñible o fluxo ascendente principal, no que simplemente gravamos a caché de fotos correcta e necesaria, simplemente pasamos pola páxina de erro para a alternativa, desde onde fomos á copia de seguranza río arriba:
E ao engadir literalmente catro servidores, isto é o que obtivemos: substituímos parte da carga: quitámola de LTM a estes servidores, implementamos a mesma lóxica alí, usando hardware e software estándar e recibimos inmediatamente a bonificación que poden estes servidores. escalar, porque simplemente se poden subministrar tanto como sexa necesario. Pois o único negativo é que perdemos alta dispoñibilidade para usuarios externos. Pero nese momento tivemos que sacrificar isto, porque era necesario solucionar o problema de inmediato. Entón, eliminamos parte da carga, era preto do 40% nese momento, LTM sentíase ben e, literalmente, dúas semanas despois de que comezase o problema, comezamos a enviar non 45k solicitudes por segundo, senón 55k. De feito, crecemos un 20 %; este é claramente o tráfico que non demos ao usuario. E despois diso comezaron a pensar en como resolver o problema restante: garantir unha alta accesibilidade externa.
Tivemos unha pausa, durante a cal discutimos que solución usaríamos para iso. Houbo propostas para garantir a fiabilidade mediante DNS, coa axuda dalgúns scripts escritos na casa, protocolos de enrutamento dinámico... había moitas opcións, pero xa quedou claro que para unha entrega de fotos verdadeiramente fiable é preciso introducir outra capa que supervisará isto. Chamámoslles a estas máquinas directores de fotografía. O software no que confiamos foi Keepalived:
Para comezar, en que consiste Keepalived? O primeiro é o protocolo VRRP, moi coñecido polos usuarios de rede, situado en equipos de rede que proporciona tolerancia a fallos ao enderezo IP externo ao que se conectan os clientes. A segunda parte é IPVS, servidor virtual IP, para equilibrar entre enrutadores fotográficos e garantir a tolerancia a fallos neste nivel. E terceiro - controis de saúde.
Comecemos coa primeira parte: VRRP: como é? Hai unha IP virtual determinada, que ten unha entrada no dns badoocdn.com, onde se conectan os clientes. Nalgún momento, temos un enderezo IP nun servidor. Os paquetes Keepalived execútanse entre os servidores mediante o protocolo VRRP, e se o mestre desaparece do radar (o servidor reiniciou ou outra cousa), entón o servidor de copia de seguranza recolle automaticamente este enderezo IP; non se precisan accións manuais. A diferenza entre mestre e copia de seguridade é principalmente prioritaria: canto maior sexa, maior será a posibilidade de que a máquina se converta nun mestre. Unha vantaxe moi grande é que non precisa configurar enderezos IP no propio servidor, é suficiente describilos na configuración, e se os enderezos IP precisan algunhas regras de enrutamento personalizadas, descríbese directamente na configuración, usando o mesma sintaxe que se describe no paquete VRRP. Non atoparás cousas descoñecidas.
Como se ve isto na práctica? Que pasa se un dos servidores falla? En canto o mestre desaparece, a nosa copia de seguranza deixa de recibir anuncios e convértese automaticamente en mestre. Despois dun tempo, reparamos o mestre, reiniciamos e levantamos Keepalived: os anuncios chegan cunha prioridade máis alta que a copia de seguranza, e a copia de seguranza volve automaticamente, elimina os enderezos IP, non é necesario facer accións manuais.
Así, garantimos a tolerancia a fallos do enderezo IP externo. A seguinte parte é equilibrar dalgún xeito o tráfico desde o enderezo IP externo ata os enrutadores fotográficos que xa o están a finalizar. Todo está bastante claro cos protocolos de equilibrio. Este é un simple round-robin ou cousas un pouco máis complexas, wrr, conexión de listas, etc. Isto descríbese basicamente na documentación, non hai nada especial. Pero o método de entrega... Aquí analizaremos máis de cerca por que escollemos un deles. Estes son NAT, Direct Routing e TUN. O caso é que planeamos de inmediato entregar 100 gigabits de tráfico dos sitios. Se estimas, necesitas tarxetas de 10 gigabit, non? As tarxetas 10 gigabit nun servidor xa están fóra do alcance, polo menos, do noso concepto de "equipo estándar". E logo lembramos que non só regalamos algo de tráfico, regalamos fotos.
Que hai de especial? — Enorme diferenza entre o tráfico entrante e saínte. O tráfico de entrada é moi pequeno, o de saída é moi grande:
Se observas estes gráficos, podes ver que neste momento o director está a recibir uns 200 MB por segundo, este é un día moi normal. Devolvemos 4,500 MB por segundo, a nosa relación é de aproximadamente 1/22. Xa está claro que para proporcionar o tráfico saínte completo a 22 servidores traballadores só necesitamos un que acepte esta conexión. Aquí é onde o algoritmo de enrutamento directo vén na nosa axuda.
Que aspecto ten? O noso director fotográfico, segundo a súa táboa, transmite conexións aos routers fotográficos. Pero os enrutadores fotográficos envían o tráfico de retorno directamente a Internet, envíano ao cliente, non volve polo director de fotos, polo que, cun número mínimo de máquinas, aseguramos unha total tolerancia a fallos e o bombeo de todo o tráfico. Nas configuracións vese así: especificamos o algoritmo, no noso caso é un simple rr, proporcionamos o método de enrutamento directo e despois comezamos a enumerar todos os servidores reais, cantos deles temos. O que determinará este tráfico. Se temos un ou dous servidores máis alí, ou varios servidores, xorde esa necesidade: só engadimos esta sección á configuración e non te preocupes demasiado. Desde o lado dos servidores reais, desde o lado do enrutador fotográfico, este método require a configuración máis mínima, está perfectamente descrito na documentación e non hai trampas alí.
O que é especialmente agradable é que esa solución non implica un redeseño radical da rede local; isto foi importante para nós; tivemos que solucionalo cuns custos mínimos. Se miras , entón veremos como queda. Aquí temos un determinado servidor virtual, no porto 443, escoita, acepta a conexión, todos os servidores que funcionan están listados, e podes ver que a conexión é igual. Se miramos as estatísticas do mesmo servidor virtual, temos paquetes entrantes, conexións entrantes, pero absolutamente ningunha saída. As conexións de saída van directamente ao cliente. Vale, puidemos desequilibralo. Agora, que pasa se un dos nosos routers fotográficos falla? Despois de todo, o ferro é ferro. Pode entrar en pánico do núcleo, pode romperse, a fonte de alimentación pode queimarse. Calquera cousa. Por iso son necesarios controis de saúde. Poden ser tan sinxelos como comprobar como está aberto o porto, ou algo máis complexo, ata algúns scripts escritos na casa que incluso comprobarán a lóxica empresarial.
Paramos nalgún lugar no medio: temos unha solicitude https a unha localización específica, o script chámase, se responde cunha resposta número 200, cremos que todo está ben con este servidor, que está vivo e pódese activar bastante. facilmente.
Como se ve isto, de novo, na práctica? Imos apagar o servidor para realizar o mantemento - flashear a BIOS, por exemplo. Nos rexistros inmediatamente temos un tempo de espera, vemos a primeira liña, despois de tres intentos márcase como "fallido" e simplemente elimínase da lista.
Tamén é posible unha segunda opción de comportamento, cando VS simplemente se establece en cero, pero se se devolve a foto, isto non funciona ben. O servidor aparece, Nginx comeza alí, Health-check entende inmediatamente que a conexión funciona, que todo está ben e que o servidor aparece na nosa lista e a carga comeza a aplicarse inmediatamente. Non se requiren accións manuais do administrador de servizo. O servidor reiniciouse pola noite; o departamento de vixilancia non nos chama por isto pola noite. Infórmanvos de que isto pasou, todo está ben.
Entón, dun xeito bastante sinxelo, coa axuda dun pequeno número de servidores, resolvemos o problema da tolerancia a fallos externos.
O único que queda por dicir é que todo isto, por suposto, hai que vixiar. Por separado, hai que ter en conta que Keepalivede, como software escrito hai moito tempo, ten unha morea de formas de supervisalo, tanto usando comprobacións a través de DBus, SMTP, SNMP e Zabbix estándar. Ademais, el mesmo sabe escribir letras para case todos os espirros, e para ser sincero, nalgún momento mesmo pensamos en desactivalo, porque escribe moitas cartas para calquera cambio de tráfico, aceso, para cada conexión IP. e así por diante. Por suposto, se hai moitos servidores, podes abrumarte con estas letras. Monitorizamos nginx en enrutadores fotográficos mediante métodos estándar e o seguimento do hardware non desapareceu. Por suposto, recomendaríamos dúas cousas máis: en primeiro lugar, controles de saúde externos e dispoñibilidade, porque aínda que todo funcione, de feito, quizais os usuarios non reciban fotos por problemas con provedores externos ou algo máis complexo. Sempre paga a pena manter nalgún lugar doutra rede, en Amazon ou noutro lugar, unha máquina separada que poida facer ping aos teus servidores desde fóra, e tamén paga a pena usar a detección de anomalías, para aqueles que saben como facer unha aprendizaxe automática complicada, ou un seguimento sinxelo. , polo menos para comprobar se as solicitudes baixaron moito ou, pola contra, aumentaron. Tamén pode ser útil.
Sintetizamos: substituímos, de feito, a solución férrea, que nalgún momento non nos conveña, por un sistema bastante sinxelo que fai todo o mesmo, é dicir, que proporciona a terminación do tráfico HTTPS e un enrutamento intelixente adicional co revisións sanitarias necesarias. Incrementamos a estabilidade deste sistema, é dicir, aínda temos alta dispoñibilidade para cada capa, ademais temos a vantaxe de que é bastante fácil escalalo todo en cada capa, porque é hardware estándar con software estándar, é dicir. , simplificamos o diagnóstico de posibles problemas.
Con que acabamos? Tivemos un problema durante as vacacións de xaneiro de 2018. Nos primeiros seis meses, mentres puxemos en funcionamento este esquema, expandímolo a todo o tráfico para eliminar todo o tráfico de LTM, só crecemos o tráfico nun centro de datos de 40 a 60 gigabits, e ao mesmo tempo para todo o ano 2018 puideron enviar case tres veces máis fotos por segundo.
Fonte: www.habr.com