La web moderna es casi impensable sin contenido multimedia: casi todas las abuelas tienen un teléfono inteligente, todo el mundo está en las redes sociales y los tiempos de inactividad por mantenimiento son costosos para las empresas. Aquí hay una transcripción de la historia de la empresa. sobre cómo organizó la entrega de fotografías utilizando una solución de hardware, qué problemas de rendimiento encontró en el proceso, qué los causó y cómo se resolvieron estos problemas utilizando una solución de software basada en Nginx, garantizando al mismo tiempo la tolerancia a fallos en todos los niveles (). Agradecemos a los autores de la historia de Oleg. Efimova y Alexandra Dymova, quienes compartieron su experiencia en la conferencia .
— Comencemos con una pequeña introducción sobre cómo almacenamos y almacenamos en caché las fotos. Tenemos una capa donde las almacenamos y una capa donde guardamos en caché las fotos. Al mismo tiempo, si queremos lograr una alta tasa de trucos y reducir la carga de almacenamiento, es importante para nosotros que cada foto de un usuario individual esté en un servidor de caché. De lo contrario, tendríamos que instalar tantas veces más discos como más servidores tengamos. Nuestra tasa de trucos ronda el 99%, es decir, estamos reduciendo la carga de nuestro almacenamiento 100 veces, y para ello, hace 10 años, cuando se estaba construyendo todo esto, teníamos 50 servidores. En consecuencia, para publicar estas fotos, necesitábamos esencialmente 50 dominios externos a los que sirven estos servidores.
Naturalmente, inmediatamente surgió la pregunta: si uno de nuestros servidores deja de funcionar y deja de estar disponible, ¿qué parte del tráfico perdemos? Miramos lo que había en el mercado y decidimos comprar un hardware para que solucionara todos nuestros problemas. La elección recayó en la solución de la empresa de red F5 (que, por cierto, compró recientemente NGINX, Inc): BIG-IP Local Traffic Manager.
Qué hace esta pieza de hardware (LTM): es un enrutador de hierro que genera redundancia de hierro en sus puertos externos y le permite enrutar el tráfico según la topología de la red, en algunas configuraciones, y realiza comprobaciones de estado. Para nosotros era importante que esta pieza de hardware pudiera programarse. En consecuencia, podríamos describir la lógica de cómo se entregaron las fotografías de un usuario específico desde un caché específico. Cómo se ve? Hay una pieza de hardware que busca Internet en un dominio, una IP, descarga SSL, analiza solicitudes http, selecciona un número de caché de IRule, adónde ir y deja que el tráfico vaya allí. Al mismo tiempo, realiza comprobaciones de estado y, en caso de que alguna máquina no esté disponible, en ese momento lo hicimos para que el tráfico fuera a un servidor de respaldo. Desde el punto de vista de la configuración, hay, por supuesto, algunos matices, pero en general todo es bastante sencillo: registramos una tarjeta, correspondemos un determinado número a nuestra IP en la red, decimos que escucharemos en los puertos 80 y 443, decimos que si el servidor no está disponible, entonces es necesario enviar tráfico al de respaldo, en este caso el 35, y describimos un montón de lógica sobre cómo se debe desmontar esta arquitectura. El único problema fue que el idioma en el que estaba programado el hardware era Tcl. Si alguien recuerda esto... este lenguaje es más de solo escritura que un lenguaje conveniente para programar:
¿Qué obtuvimos? Recibimos una pieza de hardware que garantiza una alta disponibilidad de nuestra infraestructura, dirige todo nuestro tráfico, brinda beneficios para la salud y simplemente funciona. Además, funciona desde hace bastante tiempo: en los últimos 10 años no ha habido quejas al respecto. A principios de 2018, ya enviábamos unas 80 fotos por segundo. Esto equivale a alrededor de 80 gigabits de tráfico de nuestros dos centros de datos.
Sin embargo ...
A principios de 2018, vimos un panorama feo en las listas: el tiempo necesario para enviar las fotografías había aumentado claramente. Y dejó de convenirnos. El problema es que este comportamiento sólo era visible durante el pico de tráfico; para nuestra empresa, esta es la noche del domingo al lunes. Pero el resto del tiempo el sistema se comportó como de costumbre, sin signos de fallo.
Sin embargo, había que solucionar el problema. Identificamos posibles cuellos de botella y comenzamos a eliminarlos. En primer lugar, por supuesto, ampliamos los enlaces ascendentes externos, realizamos una auditoría completa de los enlaces ascendentes internos y encontramos todos los posibles cuellos de botella. Pero todo esto no dio un resultado evidente, el problema no desapareció.
Otro posible cuello de botella fue el rendimiento de los propios cachés de fotografías. Y decidimos que quizás el problema sea de ellos. Bueno, ampliamos el rendimiento, principalmente puertos de red en cachés de fotografías. Pero nuevamente no se observó ninguna mejora evidente. Al final, prestamos mucha atención al rendimiento del LTM en sí, y aquí vimos una imagen triste en los gráficos: la carga en todas las CPU comienza a funcionar sin problemas, pero de repente se estanca. Al mismo tiempo, LTM deja de responder adecuadamente a las comprobaciones de estado y a los enlaces ascendentes y comienza a desactivarlos aleatoriamente, lo que provoca una grave degradación del rendimiento.
Es decir, hemos identificado la fuente del problema, identificado el cuello de botella. Queda por decidir qué haremos.
Lo primero y más obvio que podríamos hacer es modernizar de alguna manera el propio LTM. Pero aquí hay algunos matices, porque este hardware es bastante único, no irás al supermercado más cercano a comprarlo. Este es un contrato separado, un contrato de licencia separado, y llevará mucho tiempo. La segunda opción es empezar a pensar por uno mismo, idear su propia solución utilizando sus propios componentes, preferiblemente utilizando un programa de acceso abierto. Todo lo que queda es decidir qué elegiremos exactamente para esto y cuánto tiempo dedicaremos a resolver este problema, porque los usuarios no recibieron suficientes fotos. Por lo tanto, debemos hacer todo esto muy, muy rápido, se podría decir ayer.
Como la tarea sonaba como “hacer algo lo más rápido posible y usando el hardware que tenemos”, lo primero que pensamos fue simplemente quitar algunas máquinas no muy potentes del frente, poner allí Nginx, con el que sabemos cómo trabajar e intentar implementar la misma lógica que solía hacer el hardware. Es decir, de hecho, dejamos nuestro hardware, instalamos 4 servidores más que tuvimos que configurar, creamos dominios externos para ellos, similar a como era hace 10 años... Perdimos un poco en disponibilidad si estas máquinas caían, pero Menos aún solucionaron el problema de nuestros usuarios localmente.
En consecuencia, la lógica sigue siendo la misma: instalamos Nginx, puede realizar descargas SSL, podemos de alguna manera programar la lógica de enrutamiento, realizar comprobaciones de estado en las configuraciones y simplemente duplicar la lógica que teníamos antes.
Sentémonos a escribir configuraciones. Al principio parecía que todo era muy sencillo, pero, lamentablemente, es muy difícil encontrar manuales para cada tarea. Por lo tanto, no recomendamos simplemente buscar en Google "cómo configurar Nginx para fotos": es mejor consultar la documentación oficial, que mostrará qué configuraciones se deben tocar. Pero es mejor que elijas tú mismo el parámetro específico. Bueno, entonces todo es sencillo: describimos los servidores que tenemos, describimos los certificados... Pero lo más interesante es, de hecho, la propia lógica de enrutamiento.
Al principio nos pareció que simplemente describíamos nuestra ubicación, comparando el número de nuestro caché de fotos en ella, usando nuestras manos o un generador para describir cuántos upstreams necesitamos, en cada upstream indicamos el servidor al que debe dirigirse el tráfico. ir, y un servidor de respaldo - si el servidor principal no está disponible:
Pero, probablemente, si todo fuera tan sencillo, simplemente nos iríamos a casa y no diríamos nada. Desafortunadamente, con la configuración predeterminada de Nginx, que, en general, se realizó durante muchos años de desarrollo y no es del todo adecuada para este caso... la configuración se ve así: si algún servidor ascendente tiene un error de solicitud o tiempo de espera, Nginx siempre cambia el tráfico al siguiente. Además, después del primer fallo, en 10 segundos el servidor también se apagará, tanto por error como por tiempo de espera; esto ni siquiera se puede configurar de ninguna manera. Es decir, si eliminamos o restablecemos la opción de tiempo de espera en la directiva upstream, aunque Nginx no procesará esta solicitud y responderá con algún error no muy bueno, el servidor se cerrará.
Para evitar esto, hicimos dos cosas:
a) prohibieron a Nginx hacer esto manualmente y, desafortunadamente, la única forma de hacerlo es simplemente establecer la configuración máxima de falla.
b) recordamos que en otros proyectos utilizamos un módulo que nos permite realizar comprobaciones de estado en segundo plano; en consecuencia, realizamos controles de salud con bastante frecuencia para que el tiempo de inactividad en caso de accidente fuera mínimo.
Desafortunadamente, esto tampoco es todo, porque literalmente las dos primeras semanas de funcionamiento de este esquema mostraron que la verificación del estado de TCP tampoco es confiable: en el servidor ascendente puede que no sea Nginx, o Nginx en estado D, y en En este caso, el kernel aceptará la conexión, la verificación de estado pasará, pero no funcionará. Por lo tanto, reemplazamos inmediatamente esto con http de verificación de salud, creamos uno específico que, si devuelve 200, entonces todo funciona en este script. Puede aplicar lógica adicional; por ejemplo, en el caso de servidores de almacenamiento en caché, verificar que el sistema de archivos esté montado correctamente:
Y esto nos vendría bien, excepto que en este momento el circuito repitió completamente lo que hizo el hardware. Pero queríamos hacerlo mejor. Anteriormente, teníamos un servidor de respaldo, y esto probablemente no sea muy bueno, porque si tiene cien servidores, cuando varios fallan a la vez, es poco probable que un servidor de respaldo pueda hacer frente a la carga. Por lo tanto, decidimos distribuir la reserva entre todos los servidores: simplemente hicimos otro upstream separado, escribimos todos los servidores allí con ciertos parámetros de acuerdo con la carga que pueden soportar, agregamos las mismas comprobaciones de salud que teníamos antes:
Dado que es imposible ir a otro flujo ascendente dentro de un flujo ascendente, era necesario asegurarse de que si el flujo ascendente principal, en el que simplemente registramos el caché de fotos correcto y necesario, no estaba disponible, simplemente íbamos a la página de error para regresar, desde donde fuimos a la copia de seguridad aguas arriba:
Y al agregar literalmente cuatro servidores, esto es lo que obtuvimos: reemplazamos parte de la carga: la eliminamos de LTM a estos servidores, implementamos la misma lógica allí, usando hardware y software estándar, e inmediatamente recibimos la bonificación que estos servidores pueden escalar, porque simplemente se puede suministrar tanto como sea necesario. Bueno, lo único negativo es que hemos perdido alta disponibilidad para usuarios externos. Pero en ese momento tuvimos que sacrificar esto, porque era necesario solucionar el problema de inmediato. Entonces, eliminamos parte de la carga, en ese momento era aproximadamente el 40%, LTM se sintió bien y, literalmente, dos semanas después de que comenzó el problema, comenzamos a enviar no 45 mil solicitudes por segundo, sino 55 mil. De hecho, crecimos un 20%; este es claramente el tráfico que no le dimos al usuario. Y después empezaron a pensar en cómo resolver el problema restante: garantizar una alta accesibilidad externa.
Hicimos una pausa durante la cual discutimos qué solución usaríamos para esto. Hubo propuestas para garantizar la confiabilidad usando DNS, usando algunos scripts caseros, protocolos de enrutamiento dinámico... hubo muchas opciones, pero ya quedó claro que para una entrega de fotos verdaderamente confiable, es necesario introducir otra capa que monitoree esto. . A estas máquinas las llamamos directores de fotografía. El software en el que confiamos fue Keepalived:
Para empezar, ¿en qué consiste Keepalived? El primero es el protocolo VRRP, ampliamente conocido por los usuarios de redes, ubicado en equipos de red que proporciona tolerancia a fallas en la dirección IP externa a la que se conectan los clientes. La segunda parte es IPVS, servidor virtual IP, para equilibrar entre enrutadores de fotografías y garantizar la tolerancia a fallas en este nivel. Y tercero: controles de salud.
Comencemos con la primera parte: VRRP: ¿cómo es? Hay una determinada IP virtual, que tiene una entrada en el dns badoocdn.com, donde se conectan los clientes. En algún momento, tenemos una dirección IP en un servidor. Los paquetes Keepalived se ejecutan entre los servidores utilizando el protocolo VRRP, y si el maestro desaparece del radar (el servidor se ha reiniciado o algo más), entonces el servidor de respaldo selecciona automáticamente esta dirección IP; no se requieren acciones manuales. La diferencia entre maestro y respaldo es principalmente la prioridad: cuanto mayor sea, mayores serán las posibilidades de que la máquina se convierta en maestra. Una gran ventaja es que no necesita configurar direcciones IP en el servidor mismo, es suficiente describirlas en la configuración, y si las direcciones IP necesitan algunas reglas de enrutamiento personalizadas, esto se describe directamente en la configuración, usando el La misma sintaxis que se describe en el paquete VRRP. No encontrarás nada desconocido.
¿Cómo se ve esto en la práctica? ¿Qué pasa si uno de los servidores falla? Tan pronto como el maestro desaparece, nuestra copia de seguridad deja de recibir anuncios y automáticamente se convierte en maestro. Después de un tiempo, reparamos el maestro, reiniciamos, activamos Keepalived: los anuncios llegan con una prioridad más alta que la copia de seguridad y la copia de seguridad regresa automáticamente, elimina las direcciones IP y no es necesario realizar ninguna acción manual.
Por lo tanto, hemos asegurado la tolerancia a fallas de la dirección IP externa. La siguiente parte es equilibrar de alguna manera el tráfico desde la dirección IP externa a los enrutadores de fotografías que ya la están terminando. Todo está bastante claro con los protocolos de equilibrio. Esto es una simple operación por turnos o cosas un poco más complejas, wrr, conexión de lista, etc. Esto se describe básicamente en la documentación, no hay nada especial. Pero el método de entrega... Aquí veremos más de cerca por qué elegimos uno de ellos. Estos son NAT, enrutamiento directo y TUN. El hecho es que planeamos entregar inmediatamente 100 gigabits de tráfico desde los sitios. Si calculas, necesitas tarjetas de 10 gigabits, ¿verdad? 10 tarjetas Gigabit en un servidor ya están más allá del alcance de, al menos, nuestro concepto de “equipamiento estándar”. Y luego recordamos que no solo regalamos algo de tráfico, también regalamos fotos.
¿Qué es especial? — Enorme diferencia entre el tráfico entrante y saliente. El tráfico entrante es muy pequeño y el tráfico saliente es muy grande:
Si miras estos gráficos, puedes ver que en este momento el director recibe alrededor de 200 MB por segundo, este es un día muy normal. Devolvemos 4,500 MB por segundo, nuestra relación es aproximadamente 1/22. Ya está claro que para proporcionar tráfico saliente a 22 servidores trabajadores, solo necesitamos uno que acepte esta conexión. Aquí es donde el algoritmo de enrutamiento directo nos ayuda.
Cómo se ve? Nuestro director de fotografía, según su mesa, transmite conexiones a enrutadores de fotografía. Pero los enrutadores de fotografías envían el tráfico de retorno directamente a Internet, lo envían al cliente, no regresa a través del director de fotografías, por lo que, con un número mínimo de máquinas, garantizamos una total tolerancia a fallas y bombeo de todo el tráfico. En las configuraciones se ve así: especificamos el algoritmo, en nuestro caso es un rr simple, proporcionamos el método de enrutamiento directo y luego comenzamos a enumerar todos los servidores reales, cuántos de ellos tenemos. Lo que determinará este tráfico. Si tenemos uno o dos servidores más allí, o varios servidores, surge esa necesidad; simplemente agregamos esta sección a la configuración y no nos preocupamos demasiado. Desde el lado de los servidores reales, desde el lado del enrutador fotográfico, este método requiere la configuración mínima, está perfectamente descrito en la documentación y no hay trampas allí.
Lo que es especialmente bueno es que esta solución no implica un rediseño radical de la red local; esto era importante para nosotros; teníamos que resolverlo con costos mínimos. Si miras , luego veremos cómo se ve. Aquí tenemos un determinado servidor virtual, en el puerto 443, escucha, acepta la conexión, se enumeran todos los servidores en funcionamiento y puede ver que la conexión es, más o menos, la misma. Si miramos las estadísticas en el mismo servidor virtual, tenemos paquetes entrantes, conexiones entrantes, pero ninguna saliente. Las conexiones salientes van directamente al cliente. Bien, pudimos desequilibrarlo. Ahora bien, ¿qué pasa si falla uno de nuestros enrutadores fotográficos? Después de todo, el hierro es hierro. Puede entrar en pánico en el kernel, puede romperse, la fuente de alimentación puede quemarse. Cualquier cosa. Por eso son necesarios controles sanitarios. Pueden ser tan simples como comprobar cómo está abierto el puerto, o algo más complejo, hasta algunos scripts escritos en casa que incluso comprobarán la lógica empresarial.
Nos detuvimos en algún punto intermedio: tenemos una solicitud https a una ubicación específica, se llama el script, si responde con una respuesta número 200, creemos que todo está bien con este servidor, que está vivo y se puede activar bastante. fácilmente.
¿Cómo se ve esto, nuevamente, en la práctica? Apaguemos el servidor para realizar tareas de mantenimiento, por ejemplo, para actualizar el BIOS. En los registros, inmediatamente tenemos un tiempo de espera, vemos la primera línea, luego, después de tres intentos, se marca como "fallido" y simplemente se elimina de la lista.
También es posible una segunda opción de comportamiento, cuando VS simplemente se establece en cero, pero si se devuelve la foto, esto no funciona bien. Aparece el servidor, Nginx se inicia allí, el control de salud comprende inmediatamente que la conexión está funcionando, que todo está bien, el servidor aparece en nuestra lista e inmediatamente se le comienza a aplicar la carga. No se requieren acciones manuales por parte del administrador de turno. El servidor se reinició por la noche; el departamento de monitoreo no nos llama sobre esto por la noche. Te informan que esto pasó, todo está bien.
Entonces, de una manera bastante simple, con la ayuda de una pequeña cantidad de servidores, resolvimos el problema de la tolerancia a fallas externas.
Todo lo que queda por decir es que todo esto, por supuesto, debe ser supervisado. Por otra parte, cabe señalar que Keepalivede, como software escrito hace mucho tiempo, tiene varias formas de monitorearlo, ambas mediante comprobaciones a través de DBus, SMTP, SNMP y Zabbix estándar. Además, él mismo sabe escribir cartas para casi cada estornudo y, para ser honesto, en algún momento incluso pensamos en apagarlo, porque escribe muchas cartas para cualquier cambio de tráfico, encendido, para cada conexión IP. y así sucesivamente. Por supuesto, si hay muchos servidores, entonces puedes abrumarte con estas cartas. Monitoreamos nginx en enrutadores fotográficos utilizando métodos estándar y el monitoreo de hardware no ha desaparecido. Por supuesto, recomendaríamos dos cosas más: en primer lugar, controles de estado externos y disponibilidad, porque incluso si todo funciona, de hecho, quizás los usuarios no reciban fotos debido a problemas con proveedores externos o algo más complejo. Siempre vale la pena mantener en algún lugar de otra red, en Amazon o en otro lugar, una máquina separada que pueda hacer ping a sus servidores desde el exterior, y también vale la pena usar la detección de anomalías, para aquellos que saben cómo hacer aprendizaje automático complicado, o un monitoreo simple. , al menos para rastrear si las solicitudes han disminuido drásticamente o, por el contrario, han aumentado. También puede resultar útil.
Resumamos: de hecho, reemplazamos la solución férrea, que en algún momento dejó de convenirnos, por un sistema bastante simple que hace todo lo mismo, es decir, proporciona terminación del tráfico HTTPS y un mayor enrutamiento inteligente con el controles sanitarios necesarios. Hemos aumentado la estabilidad de este sistema, es decir, todavía tenemos alta disponibilidad para cada capa, además tenemos la ventaja de que es bastante fácil escalarlo todo en cada capa, porque es hardware estándar con software estándar, es decir. , hemos simplificado el diagnóstico de posibles problemas.
¿Con qué terminamos? Tuvimos un problema durante las vacaciones de enero de 2018. En los primeros seis meses mientras pusimos en funcionamiento este esquema, lo expandimos a todo el tráfico para eliminar todo el tráfico de LTM, crecimos solo en el tráfico en un centro de datos de 40 gigabits a 60 gigabits, y al mismo tiempo para Durante todo el año 2018 pudimos enviar casi tres veces más fotografías por segundo.
Fuente: habr.com