Hola Habr! La siguiente es una transcripción del informe de Evgeny
error2407 Bogomazov (ingeniero de I + D de red) y Dmitry
h8r Shemonaev (jefe de NOC) del pasado UPTIMEDAY. Video al final de la publicación.
Hoy nos gustaría hablar sobre qué problemas surgen al construir una red de difusión ilimitada. ¿Por qué nos metimos en esto y qué estamos haciendo allí?
En Qrator Labs, construimos nuestra propia red de difusión ilimitada para resolver problemas especiales que difieren de los de los operadores de telecomunicaciones "comunes". En consecuencia, tenemos puntos de presencia en estas regiones: simplemente olvidamos agregar a Rusia aquí. Y esto significa que tenemos muchas historias sobre cómo y no se debe hacer. Hoy compartiremos con ustedes algunos de ellos.
¿Qué vamos a decir, considerando que el tema es inicialmente voluminoso? Al principio, solo queríamos hacer preguntas y respuestas (preguntas y respuestas), pero aún así nos pidieron leer el informe. Por lo tanto, si no decimos algo, pero definitivamente no tenemos tiempo, pásanos después, al margen.
Como parte de lo planeado, trataremos de hablar sobre la diferencia entre equilibrar usando DNS y BGP. Cómo elegir nuevos sitios y a qué debe prestar atención para evitar el dolor posterior. Cómo apoyar todo esto y cuánto le dirá esta difícil tarea a Dmitry.
Para comenzar, determinemos qué tan familiarizado está con el tema.
- ¿Cuántos saben qué es anycast y por qué es necesario? (aproximadamente un tercio de las manos se levantan en el pasillo)
- ¿Y quién está familiarizado con DNS y configuró el servidor? (aproximadamente el mismo número de manos)
- Y BGP (dos manos en el marco)
Aún mucho
- Bueno, la última pregunta: ¿quién está familiarizado con NOC? ¿Quién tuvo problemas con los proveedores y quién intentó resolverlos? (la mano del administrador del sistema Habr es visible en el marco)
Genial En este caso, espero que lo que vamos a decirte surja.
Antes de pasar a anycast, veamos por qué es necesario. Tiene una aplicación con la que desea procesar las solicitudes de los clientes. Estás alojado en algún lugar, mientras no lo piensas particularmente. Compre el nombre DNS, resuélvalo, etc. Luego firme el certificado, porque HTTPS. Tu aplicación está creciendo.
Primero, debes manejar la carga. Si su aplicación "dispara" al mismo tiempo, es decir, se vuelve muy popular, muchos más usuarios acuden a usted. Debe comprar hierro y equilibrar la carga sobre él.
Además, pueden surgir clientes especialmente exigentes con las palabras: "¡Chicos, deben estar disponibles siempre y en todas partes por ese tipo de dinero!" Lo que lleva al hecho de que está colocando la redundancia de los recursos informáticos no solo para el procesamiento de cargas máximas, sino simplemente como una reserva.
Además, hoy ya se ha mencionado en otras apariencias, no puede colocar las glándulas en un centro de datos; puede ocurrir un desastre natural, lo que significa que la aplicación entrará en inactividad, lo que causará pérdidas financieras y de otro tipo. Por lo tanto, si su aplicación ha crecido lo suficiente, ya debería estar ubicado en varios centros de datos, de lo contrario será malo.
El problema tiene un lado negativo: si su aplicación es urgente, como en el análisis financiero o el comercio, es importante que envíe las solicitudes a sus usuarios lo más rápido posible. La notoria latencia con la que están conectados dos puntos. El primero: si desea enviar una solicitud lo más rápido posible, entonces para esto, el número de solicitudes y respuestas a ellas debe ser lo más pequeño posible. Una vez más, el hecho es que cuando el usuario se conecta contigo por primera vez, todo no funciona y se ve obligado a pasar por todos los círculos del infierno. El segundo punto es la velocidad de la luz. Un paquete de Europa occidental a Rusia no puede ir más rápido que un cierto número de milisegundos, no hay nada que hacer al respecto.
Es necesario estar ubicado en varios centros de datos porque queremos redundancia y necesitamos estar más cerca de los clientes potenciales. Si, por ejemplo, su región principal de clientes es América, entonces colocará su equipo allí para que el tráfico no pase por otros países y partes del mundo.
Resulta que a partir de algún momento tendrás que estar presente en todas partes del mundo en diferentes lugares. Y esto todavía no es de ningún tipo.
Entonces necesitas algunos sitios. De alguna manera, debe elegirlos, ambos inicialmente nuevos, y comprender su capacidad de escalar: durante la sobrecarga, tendrá que comprar hardware adicional.
Si ya tiene varios sitios, debe aprender a distribuir usuarios entre ellos. Hay dos sillas: BGP y DNS.
A partir de dos puntos comenzaremos con el último. Y nuevamente dos enfoques principales. En el primero, hay diferentes sitios que tienen diferentes IP y, en consecuencia, cuando un usuario presenta una solicitud, obtiene la IP de un sitio específico y los asigna.
¿Qué estamos decidiendo aquí? Queremos que un usuario de una determinada región acceda a un sitio ubicado en la misma región. La solución más simple y tonta es usar GeoDNS. Comprende las regiones en las que se encuentran los prefijos: toma estos datos, los inserta en un servidor DNS, asigna los usuarios en consecuencia, si la IP de origen proviene del prefijo correcto, al sitio correcto. Pero hay un problema: los que resuelven. Y alrededor del 15-20% de las solicitudes provienen de solucionadores, es decir, la IP de origen será 8.8.8.8. ¿Dónde poner esto?
Para hacer esto, existe EDNS, que permite, dentro del marco de la solicitud, transferir la subred del cliente original de la que proviene. Como saben, el 1 de febrero de 2019, ocurrió el Día de la Bandera de DNS: desde ese día, todos los servidores DNS deben admitir esta extensión.
En este ejemplo, puede tener uno o varios sitios donde se encuentran servidores DNS que mapean a los usuarios, y los propios servidores se pueden distribuir en todo el mundo. Y ya en el marco de DNS existe la oportunidad de usar anycast; hablaremos de esto un poco más adelante.
En el esquema general, asigna el usuario al sitio más cercano a él, dando la dirección de este sitio en particular. Se usa con menos frecuencia.
El tercer enfoque está relacionado con el hecho de que incluso si el usuario vino de la misma región donde se encuentra el sitio, esto no significa que se haya resuelto el problema de los retrasos. Puede ser aún más rentable transferir al usuario a otro sitio, ya que la región puede sobrecargarse si hay rutas alternativas disponibles. ¿Sería bueno usar esto? Desafortunadamente, casi no hay soluciones actuales para hacer algo similar. Facebook de alguna manera mostró un informe de que hizo esto, pero no hay un cuadro, todo tendrá que hacerse con sus propias manos.
¿Qué tenemos con DNS?
Las ventajas son que a los diferentes usuarios se les pueden dar diferentes direcciones, y un usuario específico se puede enviar a un sitio estrictamente definido, es decir, puede trabajar con usuarios individuales. Bueno, DNS es fácil de configurar.
¿Cuáles son las desventajas? Si realiza un ajuste granular, entonces la configuración crece bastante rápido, lo que es imposible de soportar con sus manos. Necesita automatización. Y si la automatización se realiza incorrectamente, entonces todo se descompondrá: si el DNS miente, entonces la aplicación es inaccesible.
Por otro lado, si realiza el equilibrio de DNS, el usuario se asignará a un sitio específico y su IP se volverá vulnerable. Esta es la razón por la que no utilizamos el equilibrio de DNS en casa, ya que en este caso todo el tráfico del ataque puede fluir exactamente en un punto, deshabilitándolo.
Y como ya se mencionó, DNS no admite el equilibrio de latencia fuera de la caja. Y hacerlo tú mismo es muy difícil.
Lleguemos finalmente a las cosas buenas, a saber, BGP anycast.
Este es exactamente nuestro caso. Cual es el punto? Todos los sitios tienen la misma IP, o mejor dicho, anuncian el mismo prefijo. El usuario se asigna al sitio "más cercano". "Más cercano" desde el punto de vista de BGP: dicho prefijo se anuncia utilizando varias rutas, y si el operador tiene varias rutas para el sitio anunciado, la mayoría de las veces elegirá la más corta. De nuevo desde el punto de vista de BGP. Pronto explicaremos por qué esto es malo.
BGP también funciona con la disponibilidad de prefijos, por lo que siempre opera en una subred y no puede manipular IP individuales.
Como resultado, dado que se anuncia el mismo prefijo en todos los sitios, todos los usuarios de la misma región serán dirigidos al mismo sitio. El atacante no tiene forma de transferir la carga de una región a otra, por lo que debe ganar tanta potencia en cada uno de los lugares como deseaba el operador que eligió esta ruta. Incluso si no puntúa, aún puede protegerse.
Se anuncia el mismo prefijo: ¿qué podría ser más fácil? Pero también hay problemas.
La primera es que debido a la necesidad de anunciar el mismo prefijo en todo el mundo, se ve obligado a comprar direcciones independientes del proveedor, que son varias veces más caras.
El segundo se reduce al hecho de que los usuarios de una región no pueden simplemente ser arrojados a otra, si de repente algunos de ellos son ilegítimos o con el objetivo de diversificar el tráfico de ataques usando otros sitios, porque algunos de ellos duelen. No hay tales bolígrafos.
El tercer problema es que dentro del marco de BGP es muy fácil elegir el sitio "incorrecto" y los proveedores "incorrectos". Te parecerá que tienes redundancia y disponibilidad, pero en realidad no habrá ni lo uno ni lo otro.
Tiene varios sitios entre los cuales desea dispersar usuarios. ¿Cuáles son los controles para restringir una determinada región y atraer a los usuarios a un sitio específico?
Hay Geo Community. ¿Por qué son ellos? Déjame recordarte: eliges la ruta más cercana desde el punto de vista de BGP. Y tiene un operador de nivel 1, por ejemplo, Level3, que tiene su propia troncal en todo el mundo. El cliente de Level3, si está conectado directamente a él, se encuentra en dos esperanzas de usted. Y algún operador local, en tres. En consecuencia, un operador de Estados Unidos estará más cerca de usted que un operador de Rusia o Europa, porque desde el punto de vista de BGP es así.
Con Geo Community, puede limitar la región dentro de la cual un operador tan grande e internacional anunciará su ruta. El problema también es que no siempre están disponibles (Comunidad Geo).
Tenemos varios casos cuando se trata de nosotros mismos. Dim?
(Dmitry Shemonaev toma la palabra)
Fuera de la caja, muchos operadores no proporcionan esto y dicen que, dicen, no restringiremos nada para la neutralidad de la red, la libertad, etc. Tenemos que explicar a los operadores durante mucho tiempo y quiénes somos, por qué lo queremos y por qué es tan importante para nosotros, y también educar por qué esto no se aplica a la neutralidad que tienen en mente. A veces esto funciona, y a veces no, y simplemente nos negamos a cooperar con operadores potencialmente interesantes porque dicha cooperación conducirá a un mayor dolor en la operación de nuestro servicio.
Además, a menudo nos encontramos con el hecho de que hay una serie de operadores que Eugene ya ha mencionado: estos son Tier-1, que no le compran tráfico a nadie y solo intercambian tráfico entre ellos. Pero, además de ellos, hay un par de al menos docenas de operadores que no son Tier-1: compran tráfico, pero al mismo tiempo también tienen redes desplegadas en todo el mundo. No tiene que ir muy lejos: desde lo más cercano a nosotros es Rostelecom o ReTN, un poco más lejos hay maravillosas telecomunicaciones de Taipei, China Unicom, Singtel, etc.
Y en Asia a menudo nos enfrentamos a una situación tal que, al parecer, tenemos varios puntos de presencia en Asia, estamos conectados a varios operadores bastante grandes, desde el punto de vista de esta región. Sin embargo, nos enfrentamos constantemente con el hecho de que el tráfico de Asia va a nuestro sitio a través de Europa o realiza un viaje transatlántico. Desde el punto de vista de BGP, esto es bastante normal en sí mismo, ya que no tiene en cuenta la latencia. Pero la aplicación sufre en tales condiciones, sus usuarios también, en general, todos sufren, pero desde el punto de vista de BGP, todo está bien.
Y tiene que hacer algunos cambios con las manos, hacer ingeniería inversa de cómo se organiza la ruta de este o aquel operador, a veces negociar, preguntar, rogar, arrodillarse. En general, haga cualquier cosa para resolver estos problemas. Con esto, nuestro NOC se enfrenta a una envidiable regularidad.
Como regla general, los operadores satisfacen sus necesidades y, en algunos casos, están listos para proporcionar un determinado conjunto ... Pero, en general, ¿pueden aquellos que trabajaron con BGP a nivel comunitario levantar la mano? (Sonríe) ¡Genial! Es decir, los operadores están listos para proporcionar algún conjunto de gerentes de la comunidad para, por ejemplo, reducir las preferencias locales en una determinada región, o agregar un prefijo, o no anunciar bien o algo más.
En consecuencia, hay dos formas de equilibrar la carga en BGP. El primero es cómo está escrito en la diapositiva, el llamado Precede. Podemos imaginar la ruta a BGP como una pequeña línea que enumera los sistemas autónomos a través de los cuales pasa la ruta del paquete del remitente al destinatario. Puede agregar un enésimo número de sistemas autónomos a esta ruta y, como resultado, la ruta se extenderá y no será muy prioritaria. Este es un método frontal y no funciona para todo: si agrega prepend, no es granular, es decir, todos lo verán en el cono del operador en el que está haciendo esta manipulación.
Por otro lado, también está la comunidad BGP, que está marcando, para entender de dónde viene este o aquel prefijo, de quién es con respecto al operador, es decir, un banquete, cliente o aguas arriba, y también en qué lugar se toma y etc. Y hay administradores de la comunidad que van al enrutador al operador y él toma ciertas acciones con este prefijo.
La mayoría de los operadores tienen comunidades restrictivas. Tomemos, por ejemplo, el operador ruso abstracto, que está conectado a varios operadores rusos en el vacío. Algunos de ellos tienen relaciones entre pares, lo que implica un intercambio de tráfico paritario, y algunos los compran. En consecuencia, proporcionan comunidad para hacer preparativos en esta dirección, extendiendo la ruta AS, o no para anunciar o cambiar las preferencias locales. Si está operando con BGP, mire a la comunidad y sepa qué puede hacer el solicitante para convertirse en su proveedor. A veces, las comunidades están ocultas y debe comunicarse con los administradores de los operadores o con expertos técnicos para mostrarnos un determinado conjunto compatible.
Por defecto, la comunidad, en el caso de la región europea, se describe en RIPE DB. Es decir, usted solicita a whois los números del sistema autónomo y el campo Comentarios generalmente dice lo que el operador tiene en términos de marcado y administración de la comunidad. No todos tienen esto, por lo que a menudo hay que buscar diferentes lugares interesantes.
Tan pronto como comience a operar BGP, en esencia, dice que la red es parte de su aplicación y no algo abstracto, por lo que debe considerar los riesgos.
Por ejemplo, tuvimos un caso con una institución financiera letona, cuyo prefijo, si se incluía a través de nuestra red, no estaba disponible en aproximadamente la mitad de Letonia. Aunque parece que nada ha cambiado, el mismo prefijo que estamos anunciando en los operadores Tier-1, en Europa, parece que todo está allí, incluida la redundancia. Pero ni siquiera podíamos imaginar que aproximadamente la mitad de los operadores letones tenían como dispositivos fronterizos que no podían digerir el volumen completo de la vista completa (toda la tabla de enrutamiento BGP), que en ese momento era de aproximadamente 650 mil prefijos. Se quedaron allí, bueno, si alguien sabe qué es el Catalyst 3550, fue exactamente allí donde estaba, solo podía tener 12,000 prefijos. Bueno, obtuvieron una cierta cantidad de prefijos de IX'a, en los que, por supuesto, no había ningún defecto. Junto con esto, de otro operador: la televisión letona, cuyo prefijo en el IX no era / 24, sino / 22 en el que se encontraba este / 24.
Como resultado, fue a un lugar donde no sabía dónde encaminarlo y todo voló a la tubería. Para solucionar esto, nos llevó unos dos días y una correspondencia persistente con los operadores letones hasta que nos mostraron la salida de su dispositivo de borde y solo notamos el nombre de host allí. Hola a todos, es muy divertido a veces.
Hay muchos operadores con hierro viejo. Hay muchos operadores con una extraña comprensión de cómo debería funcionar la red. Y ahora este también es tu problema si vas a jugar con BGP. Bueno, al final, muchos operadores tienen una sola pierna (un proveedor superior de conectividad), por lo que tienen sus propios conjuntos de muletas.
(Evgeny Bogomazov continúa)
Como puede ver, incluso este tema puede desarrollarse durante mucho tiempo y es difícil mantenerlo en 40 minutos.
Entonces, tienes plumas con las que deseas limitar la región. Ahora veamos qué necesita mirar y qué es importante tener en cuenta cuando desee hospedarse en un sitio nuevo.
El mejor caso no es comprar su hardware, sino estar de acuerdo con una nube de alojamiento. Entonces ya, será posible estar de acuerdo con él en que se conectará independientemente a ciertos proveedores.
Por otro lado, si, sin embargo, siguió este camino, debe comprender aproximadamente qué región, con o sin asas, se unirá a este sitio. Para hacer esto, necesita modelar, o más bien, debe comprender que si hay varias rutas desde diferentes sitios, cuál será la mejor. Para hacer esto, debe tener una idea de cómo funciona BGP y cómo circulan las rutas en la situación actual.
Dos puntos principales son la longitud de la ruta, influenciada por prepuestos y la preferencia local, que dice que las rutas de los clientes son preferibles a las rutas de otros lugares. En principio, estos dos puntos son suficientes para comprender qué región se unirá y dónde levantarse.
Entre otras cosas, hay un par de cosas a considerar, a saber, qué tipo de conectividad tiene su proveedor, además, el hecho de que algunos proveedores no se comunican entre sí (guerras entre pares), e incluso si se conecta al Nivel 1 regional, esto no significa que Todos los usuarios locales te verán.Otra cosa que a menudo se olvida es que la conectividad en IPv4 e IPv6 es completamente diferente, no portátil entre sí.
Y aquí llegamos al punto principal. Respondiendo a la pregunta: "¿Dónde levantarse?" La elección parece ser obvia. Si tienes usuarios en la región, obtienes IX en esta región y no hay nada más en lo que pensar. Hay conectividad, la mayoría de los usuarios, en teoría, deberían estar conectados a ella, y la mayoría de los especialistas en contenido, como compañías como Yandex y otras, primero se conectan a IXs y solo luego a proveedores. Pero los proveedores pueden tener clientes únicos, algunos proveedores no están presentes en IX y, como resultado, no puede redirigir a estos usuarios a usted mismo, lo harán de manera extraña.Al elegir proveedores, no puede volverse loco: tuvimos un par de casos en los que el enfoque incorrecto provocó un problema. Los proveedores son nuestra elección, porque si no tienes muchos recursos para conectarte, si vas a los jugadores regionales más grandes, terminarás con la misma conectividad que en IX.Dime cómo elegir los proveedores correctos, Dima.(y nuevamente Dmitry Shemonaev)Está bien. Imaginemos que tenemos un punto y la región de nuestro interés es Rusia. Tenemos un punto en un centro de datos condicionalmente bueno en Moscú, operamos con nuestro sistema autónomo, nuestro propio conjunto de prefijos y decidimos escalar usando BGP anycast: elegante y de moda.El negocio, junto con colegas técnicos, decidió que desde Vladivostok hasta Moscú hay un RTT muy grande y esto es malo, es decir, no es bueno. Digamos que nos quedaremos en Moscú y pondremos fin a Novosibirsk, todo será mejor, RTT caerá, por supuesto. Apenas dicho que hecho.Esto plantea la cuestión de un sitio para equipos, pero esto está un poco fuera del alcance de nuestra conversación hoy, pero la cuestión de elegir un operador es bastante.Parecería que la elección es obvia: en Moscú estamos conectados con el Moskvatelekom condicional, pegémonos también en Novosibirsk. Sí, en principio, podemos confiar en el enrutamiento interno del proveedor, pero esto no siempre es correcto; en este caso, ponemos todos los huevos en una canasta y debemos entender que el enrutamiento de acuerdo con el IGP del operador puede no ser óptimo, por decir lo menos, porque no siempre está claro lo que lo impulsa A veces es comprensible, a veces no lo es tanto, ahora no se trata de eso, además, la administración me prohibió maldecir, así que no puedo dar algunos ejemplos en detalle.Las tendencias modernas son tales que incluso Moskvatelecom puede decir que ha llegado el momento de SDN y ahora pondremos un controlador maravilloso que controlará la red. Y en un punto, dicho controlador simplemente puede destruir esta red. Por casualidad, no recuerdo tal caso, específicamente con un controlador SDN, pero recientemente en Estados Unidos, un gran operador (CenturyLink) dejó una tarjeta de red al dios de la red y toda la red era inestable en todo Estados Unidos. Debido a una tarjeta de interfaz de red. El NOC de este operador resolvió este problema durante tres o cuatro días. Debido a una tarjeta de red.Si está conectado a un operador, lo felicito sinceramente.Bueno, entonces han decidido: no cooperaremos con un solo operador condicional en Moscú y Novosibirsk. Aquí, con Moskvatelecom, y allá, con Novosibirsktelecom (todas las coincidencias son aleatorias). Los tamaños de los conos del cliente de estas dos telecomunicaciones difieren como una tortuga de un elefante y obtendrá todo su tráfico a donde cae el cono principal del cliente, es decir, a Moskvatelecom con sede en Moscú. Siempre es aconsejable que los operadores sean paritarios y tengan pares entre ellos en el territorio de la región en la que se encuentra su interés. En Rusia, hace varios años, los operadores más grandes, como Rostelecom y TTK, tenían pares en Moscú, San Petersburgo, Nizhny Novgorod, Novosibirsk y, al parecer, en Vladivostok. Por lo tanto, el tráfico pasó entre estos operadores más o menos de manera óptima.Pero el operador aún debe seleccionarse correctamente. Entonces él tiene una comunidad, entonces él tiene un NOC. Todo esto es realmente importante, porque el año pasado hubo un caso maravilloso cuando un operador ruso bastante grande probó algunos de sus servicios y por la noche anunció muchos prefijos de la ciudad de San Petersburgo con la inserción de su sistema autónomo en el segundo servidor de ruta DE-CIX en Frankfurt. Lo anunció allí con una comunidad de agujeros negros.Como resultado, muchos operadores y centros de datos de San Petersburgo enfrentaron la inaccesibilidad de, por ejemplo, la red TTK. Esto también nos afectó, pero pudimos evitar esto, porque entre nuestros puntos tenemos nuestra propia red, en algún lugar superpuesto y en algún lugar físico, y enrutamos el tráfico desde el operador problemático al que no tenía problemas. En general, venció. Pero le digo esto para que sepa que el NOC del operador debe ser adecuado, porque en ese caso el NOC del delincuente no contactó la noche del viernes al sábado, sino que se despertó solo el lunes. Inaccesibilidad parcial de tres días para varios operadores. Mejor piensa tres veces.
Volvamos a NOC. Centro de operaciones de red: un centro de administración de red, esta es la división de la empresa que se dedica a la operación de la red, operaciones de red, etc. Respuestas a una cantidad de tickets recibidos con respecto a la red. ¿Qué quieres agregar? Los especialistas criados en la suma de Aichi en esta sala probablemente sepan todas las cosas buenas sobre el monitoreo. Esto es realmente importante En algunos casos, cosas muy específicas tendrán que ser monitoreadas.
Algunos usuarios pueden quejarse de que "todo es de alguna manera malo" y no pueden proporcionar los diagnósticos necesarios para comenzar a trabajar para corregir la situación. Hay una señal que es mala, y qué y dónde no está claro. En este caso, intentamos interactuar con el NOC del operador en el cono del cliente en el que se encuentra este usuario. Si no funciona, veremos qué correlaciones hay: la posibilidad de un nodo de proyecto RIPE Atlas dentro de este cono. En general, recolectamos como podemos. Estamos listos para lo que no siempre nos pueden dar.En algunos casos, tiene sentido monitorear con qué comunidad este o aquel prefijo viene a su enrutador de borde y recopilar una retrospectiva histórica, perdón por la tautología. Por ejemplo, tomamos tres operadores: Megafon, Rostelecom y Transtelecom. Supongamos que todos ellos están mirando en el territorio de la Federación Rusa, y usted está conectado a un Rostelecom condicional o no importa. Verá los prefijos en los que se encuentran sus usuarios, con algún tipo de comunidad de marcado, en este caso. Se pueden recopilar, registrar y, cuando sucede algo, la comunidad cambiará. Por ejemplo, obtienes un prefijo con la comunidad de que esta es una fiesta en Rusia. Sí, bueno, grabado. Y luego esta comunidad ha cambiado al hecho de que esta es una fiesta en Frankfurt. ¿Qué significa esto?
Que estos operadores rompieron las relaciones entre pares y que usted y Latency no lo están haciendo muy bien, está atravesando el ciclo europeo. En este caso, puede hacer algo de forma proactiva, pero lleva mucho tiempo y requiere determinación, así como otras cualidades.Y si es posible, automatice todo: fue difícil hace 10 años, y ahora hay muchas utilidades, como Ansible, Chef, Puppet, que pueden interactuar con elementos de la red. ¿Por qué es importante la automatización? He estado configurando BGP durante mucho tiempo y la primera regla es algo como esto: "Quienquiera que haya configurado su vecindario BGP, por otro lado, no está configurado por una persona muy agradable". Desde el punto de vista de esa persona, esta regla también se aplica a usted.Personalmente tuve un caso cuando transferí todos los pares de una frontera a otra en un operador de Samara cuyo nombre no nombraremos. Tuve una unión con un proveedor de contenido importante: una sala de cine en línea y tuve una unión con la hija local de Rostelecom. Solo con el administrador de contenido tuve una unión de gigabytes, y con mi hija una de cien megabytes. Y yo, como persona agradable, soporté todo esto por la noche: miro los gráficos, la articulación de cien megabits y pienso: "¡Oh, cómo demonios!" Y luego miro, este en el regimiento, el que está en el regimiento y pienso (me golpeo en la frente), olvidé hacer filtros. Eso se debe excluir de tales acciones, porque todos los demás aceptaron, desde el triple strike solo necesitan ser protegidos por la automatización. La automatización es enemiga de las personas malas y amiga de las buenas.Entonces lo eres, Zhenya.
(Evgeny Bogomazov continúa)Así que discutimos todos los puntos iniciales. Pero en cualquier caso, todo no termina; además de él, debes realizar un seguimiento de otras cosas adicionales.
Veamos que más es. Debe ver qué tan bien se integra la aplicación en la distribución; si hay varios sitios, debe poder dispersar el contenido en estos sitios. Si esto no es posible, no importa cómo se distribuya su sistema, todos los usuarios irán al sitio donde se encuentra realmente la aplicación. Y exactamente RTT no guardará.Por otro lado, si no tiene datos de usuario como tales, puede colocar la aplicación de usuario en ese sitio, simplemente hágalo. Si la aplicación es compatible con todo, utilice nubes de difusión ilimitada, si no desea desarrollar su propia infraestructura, esto generará muchas ganancias.Bueno, si ya tiene varios sitios y el usuario llega a uno de ellos, algo puede suceder allí, digamos que se caerá o los enlaces se romperán, por lo que los usuarios irán a otro sitio. Pero no deberían notarlo. Por lo tanto, debe poder transferir este tráfico lo más rápido posible dentro de la red interna de difusión ilimitada y, en general, debe considerar tal problema como inevitable; por lo tanto, es bueno poner algo en la aplicación para prepararse para tal desarrollo de eventos.Idealmente, si tiene métricas empresariales de aplicaciones, en caso de que caigan, solicite de inmediato la supervisión de la red y genere un informe sobre el estado de la red interna o externa, o mejor ambas. Las métricas comerciales generalmente caen porque algo sucedió en algún lugar, pero esto, por supuesto, es una utopía, incluso si aún no nos hemos acercado a esto.
Tiene una red externa, pero también hay sitios internos: deben comunicarse entre sí. Al mismo tiempo, no necesita tener su propia infraestructura física: puede usar las redes de operadores externos, lo principal es configurar túneles virtuales. Además, debe configurar el enrutamiento de la red interna, porque no todo termina en BGP. Debido a la naturaleza del procesamiento del tráfico, tenemos nuestros propios protocolos, estilo de comunicación y secuencias de comandos.Si tiene bastantes sitios, debería poder actualizar las configuraciones en diferentes lugares al mismo tiempo. Obtiene un nuevo prefijo, tiene que anunciarlo en todas partes, DNS actualizado, lo mismo. En el contexto de los SDN, debe recopilar datos de los sitios y agregarlos en algún lugar, y verter los cambios que ocurrieron debido a estos datos nuevamente en los sitios.
El último elemento es DNS. El ejemplo con Dyn fue indicativo: como recordarán, en 2016 se realizó un ataque contra ellos, al que no pudieron hacer frente y una gran cantidad de recursos populares en los EE. UU. Dejaron de estar disponibles. El DNS también necesita protección, de lo contrario, los usuarios no encontrarán su aplicación en la red. Los cachés de DNS se guardan, en parte, y hay un trabajo interesante sobre este tema en el IETF, pero siempre depende de si ciertos solucionadores de DNS lo admitirán.En cualquier caso, debe tener un DNS seguro. Esta es la primera etapa que debe resolverse para que el usuario se familiarice con su aplicación. Cuando abre la página por primera vez, además del RTT, que ya hemos mencionado, habrá demoras adicionales para las consultas de DNS y debe estar preparado para que, por primera vez, la página del usuario se abra durante mucho tiempo, alguien no lo tolere. Si para usted un primer descubrimiento largo es crítico, también tendrá que acelerar el DNS.En el caso de anycast, puede almacenar en caché las respuestas DNS en sus puntos de presencia, porque ya tiene estos sitios y las respuestas DNS llegarán con la suficiente rapidez.
Cual es el problema Bueno, latencia, bueno, equilibrio.Como ya mencionamos, todavía hay naturaleza. En parte debido a ello, debe ser colocado en diferentes lugares. Esto no debe olvidarse, aunque el riesgo parece pequeño.También hay una persona y un factor de oportunidad. Por lo tanto, debe automatizar todo lo más posible, probar las configuraciones vertidas y monitorear los cambios. Incluso si ha tomado algo, será bueno si puede hacer cambios rápida y localmente.Este es el 90% de los casos. Pero el 10% restante, esto es si los competidores decidieron eliminarlo. En este caso, tienes serios problemas. ¿Por qué se resalta la "Reserva" en una fuente grande separada? Si decide colocar, necesitará una gran cantidad de canales en sus sitios, lo que significa que deberá negociar con una gran cantidad de proveedores. De lo contrario, con el nivel promedio actual de ataques, no puede hacerlo en absoluto.
Por lo tanto, es mejor delegar que comprar su propio hardware. Incluso parte de la funcionalidad que describimos hoy en el marco de anycast y los problemas que surgen son fáciles de resolver de manera incorrecta. Entonces, si existe la oportunidad de no resolver estos problemas y cambiarlos a personas externas, probablemente valga la pena hacerlo. De lo contrario, debe responder con precisión la pregunta de por qué necesita implementar todo esto.Bueno, en caso de un ataque, recurra a esas nubes que se especializan en resolver tales problemas. Bueno, o aún puedes chatear con nosotros.Gracias
Preguntas?