EvE en línea es un juego divertido. Este es uno de los pocos MMO en los que solo hay un "servidor" para ingresar, lo que significa que todos juegan en el mismo mundo lógico. También tuvo un conjunto emocionante de eventos que ocurrieron dentro del juego, y también sigue siendo un juego visualmente atractivo:
También hay un extenso mapa mundial en el que pueden caber todos estos jugadores. En su apogeo, EvE tenía 63,000 jugadores en línea en un mundo con 500,000 suscripciones pagas registradas en la cima de la popularidad, y aunque este número se está reduciendo cada año, el mundo sigue siendo increíblemente grande. Esto significa que la transición de un lado a otro es una cantidad de tiempo significativa (así como el riesgo debido a la dependencia del jugador en la fracción).
La traducción fue respaldada por EDISON Software , una compañía de seguridad profesional, y también está desarrollando sistemas electrónicos de verificación médica .Viaja a diferentes áreas usando el modo warp (dentro del mismo sistema), o salta a diferentes sistemas usando puertas de salto:
Y todos estos sistemas se combinan para crear un mapa de belleza y complejidad:
Siempre vi este mapa como una red, es una gran red de sistemas que se conectan entre sí para que las personas puedan atravesarlos, y la mayoría de los sistemas tienen más de dos puertas de salto. Me hizo pensar en lo que sucedería si literalmente tomaras la idea de un mapa como una red. ¿Cómo será el sistema de Internet EvE?
Para hacer esto, necesitamos entender cómo funciona la Internet real. Internet es una gran colección de proveedores de Internet que se identifican numéricamente utilizando un número de proveedor de Internet único y estandarizado, llamado Número de sistema autónomo o ASN (o AS para la versión más corta). Estos AS necesitan una forma de intercambiar rutas entre ellos, ya que poseerán rangos de direcciones IP, y necesitan una manera de decirles a otros proveedores de Internet que sus enrutadores pueden enrutar estas direcciones IP. Para hacer esto, el mundo se detuvo en el protocolo de puerta de enlace de límite o BGP.
BGP funciona "diciéndole" a otros AS (conocidos como host) sus rutas:
El comportamiento estándar de BGP cuando recibe una ruta de un host es pasarlo a todos los demás hosts a los que también está conectado. Esto significa que los nodos compartirán automáticamente sus tablas de enrutamiento entre sí.
Sin embargo, este comportamiento solo es útil si usa BGP para enviar rutas a enrutadores internos, ya que Internet moderno tiene diferentes relaciones lógicas entre sí. En lugar de la red, la Internet moderna se ve así:
Sin embargo, EvE en línea está instalado en el futuro. Quién sabe si Internet se basa en este esquema de enrutamiento para obtener ganancias. Imaginemos que esto no es así para que podamos ver cómo BGP escala en redes más grandes.
Para hacer esto, necesitamos simular el comportamiento real del enrutador BGP y la conexión. Dado que EvE tiene un número relativamente bajo de 8,000 ~ sistemas, y 13.8 mil enlaces entre ellos. Sugerí que en realidad sería imposible ejecutar 8000 ~ máquinas virtuales con BGP real y una red para descubrir cómo se ven estos sistemas reales cuando actúan juntos como una red.
Sin embargo, no tenemos recursos ilimitados, por lo que necesitaremos encontrar una manera de hacer la imagen de Linux más pequeña tanto cuando usemos espacio en disco como cuando usemos memoria. Para esto, llamé la atención sobre los sistemas integrados, ya que los sistemas integrados a menudo tienen que trabajar en entornos con un nivel muy bajo de recursos. Encontré
Buildroot , y después de unas horas tenía una pequeña imagen de Linux que contenía solo lo que necesitaba para que este proyecto funcionara.
$ ls -alh total 17M drwxrwxr-x 2 ben ben 4.0K Jan 22 22:46 . drwxrwxr-x 6 ben ben 4.0K Jan 22 22:45 .. -rw-r--r-- 1 ben ben 7.0M Jan 22 22:46 bzImage -rw-r--r-- 1 ben ben 10M Jan 22 22:46 rootfs.ext2
Esta imagen contiene boot linux, que también tiene: *
Bird 2 BGP Daemon *
tcpdump y My Traceroute (mtr) para la depuración de la red *
busybox para el shell base y las utilidades del sistema
Esta imagen se puede ejecutar fácilmente en qemu con algunas opciones:
qemu-system-i386 -kernel ../bzImage \ -hda rootfs.ext2 \ -hdb fat:./30045343/ \ -append "root=/dev/sda rw" \ -m 64
Para trabajar en la red, decidí usar una función no documentada de qemu (en mi versión), en la que puede dirigir dos procesos de qemu entre sí y usar sockets UDP para transferir datos entre ellos. Esto es conveniente, ya que planeamos proporcionar una gran cantidad de enlaces, por lo que usar el método habitual de adaptador
TUN / TAP puede generar confusión rápidamente.
Dado que esta característica está parcialmente indocumentada, hubo algunos problemas con su funcionamiento. Me llevó mucho tiempo comprender que el nombre de la red en la línea de comando debería ser el mismo para ambos lados de la conexión. Más tarde resultó que esta función ya está bien documentada, como suele suceder. Los cambios tardan en llegar a versiones anteriores de la distribución.
Tan pronto como esto funcionó, obtuvimos un par de máquinas virtuales que pueden enviarse paquetes entre sí, y el hipervisor las envía como datagramas UDP. Dado que lanzaremos una gran cantidad de tales sistemas, necesitaremos una forma rápida de configurarlos utilizando una configuración creada previamente. Para hacer esto, podemos usar la conveniente función qemu, que le permite tomar un directorio en el hipervisor y convertirlo en un sistema de archivos virtual FAT32. Esto es útil porque nos permite crear un directorio para cada sistema que planeamos iniciar, y cada proceso qemu apunta a este directorio, lo que significa que podemos usar la misma imagen de arranque para todas las máquinas virtuales en el clúster.
Dado que cada sistema tiene 64 MB de RAM, y planeamos usar 8000 ~ VM, ciertamente necesitaremos una cantidad decente de RAM. Para esto, utilicé 3 m2.xlarge.x86 con packet.net, ya que ofrecen 256 GB de RAM con 2x Xeon Gold 5120, lo que significa que tienen una cantidad decente de soporte.
Utilicé
otro proyecto de código abierto para crear un mapa EvE en forma de JSON, y luego creé un programa de configuración personalizado basado en estos datos. Después de realizar varias pruebas de algunos sistemas, probé que pueden tomar la configuración de VFAT y establecer sesiones de BGP entre ellos sobre esto.
Entonces, tomé el paso decisivo para cargar el universo:
Al principio, intenté iniciar todos los sistemas en un gran evento, pero, desafortunadamente, esto provocó una gran explosión en términos de carga del sistema, por lo que luego cambié a iniciar el sistema cada 2.5 segundos y 48 núcleos del sistema finalmente se encargaron de esto.
Durante el proceso de arranque, descubrí que verías grandes "explosiones" del uso de la CPU en todas las máquinas virtuales, luego descubrí que estas eran grandes partes del universo conectadas entre sí, lo que provocaba grandes cantidades de tráfico BGP en ambos lados del virtual recién conectado carros
root@evehyper1:~/147.75.81.189# ifstat -i bond0,lo bond0 lo KB/s in KB/s out KB/s in KB/s out 690.46 157.37 11568.95 11568.95 352.62 392.74 20413.64 20413.64 468.95 424.58 21983.50 21983.50
Al final, vimos algunas rutas BGP bastante sorprendentes, ya que cada sistema anuncia / 48 direcciones IPv6, puede ver las rutas a cada sistema y a todos los demás sistemas por los que tendría que pasar para llegar allí.
$ birdc6 s ro all 2a07:1500:b4f::/48 unicast [session0 18:13:15.471] * (100) [AS2895i] via 2a07:1500:d45::2215 on eth0 Type: BGP univ BGP.origin: IGP BGP.as_path: 3397 3396 3394 3385 3386 3387 2049 2051 2721 2720 2719 2692 2645 2644 2643 145 144 146 2755 1381 1385 1386 1446 1448 849 847 862 867 863 854 861 859 1262 1263 1264 1266 1267 2890 2892 2895 BGP.next_hop: 2a07:1500:d45::2215 fe80::5054:ff:fe6e:5068 BGP.local_pref: 100
Tomé una instantánea de la tabla de enrutamiento en cada enrutador en el universo, y luego describí los sistemas de uso común para acceder a otros sistemas, sin embargo, esta imagen es enorme. Aquí hay una versión pequeña de esto en la publicación, si hace clic en una imagen, tenga en cuenta
que esta imagen probablemente hará que su dispositivo se quede sin memoria
Después de eso, pensé, ¿qué más se puede asignar a las redes enrutadas BGP? ¿Podría usar un modelo más pequeño para probar cómo funciona la configuración de enrutamiento en redes grandes?
Preparé un archivo que mostraba el sistema de metro de Londres para verificar esto :
El sistema TFL es mucho más pequeño y tiene muchos más saltos que tienen una sola dirección, ya que la mayoría de las estaciones tienen solo una "línea" de transporte, sin embargo, podemos aprender una cosa de esto, podemos usar esto para jugar de manera segura con
BGP MED .
Sin embargo, existe un problema cuando consideramos una tarjeta TFL como una red BGP, en el mundo real el tiempo / retraso entre cada parada no es el mismo y, por lo tanto, si simulamos este retraso, no daríamos la vuelta al sistema tan rápido como pudiéramos, ya que solo miramos el menor número de estaciones para seguir el camino.
Sin embargo, gracias a la Ley de Libertad de Información (FOIA), la solicitud que se envió al
TFL nos proporcionó el tiempo necesario para pasar de una estación a otra. Se generaron en la configuración del enrutador BGP, por ejemplo:
protocol bgp session1 { neighbor 2a07:1500:34::62 as 1337; source address 2a07:1500:34::63; local as 1337; enable extended messages; enable route refresh; ipv6 { import filter{ bgp_med = bgp_med + 162; accept; }; export all; }; } protocol bgp session2 { neighbor 2a07:1500:1a::b3 as 1337; source address 2a07:1500:1a::b2; local as 1337; enable extended messages; enable route refresh; ipv6 { import filter{ bgp_med = bgp_med + 486; accept; }; export all; }; }
En la
session1 intervalo de tiempo entre dos estaciones es de 1.6 minutos, el otro camino desde esta estación es de 4.86 minutos. Este número se agrega a la ruta para cada estación / enrutador a través del cual pasa. Esto significa que cada enrutador / estación en la red sabe que es hora de llegar a cada estación a través de cada ruta:
Esto significa que traceroutes determina exactamente cómo puede viajar por Londres, por ejemplo, a mi estación de Paddington:
También podemos divertirnos con BGP simulando mantenimiento o un incidente en la estación de Waterloo:
Y como toda la red elige instantáneamente la siguiente ruta más rápida, y no la que tenga el menor número de estaciones de paso.
¡Y esta es la magia de BGP MED en el enrutamiento!
El código para todo esto ya está disponible. Puede crear sus propias estructuras de red con un esquema JSON bastante simple o simplemente usar EvE en línea o TFL, ya que ya están en el repositorio.
Puedes encontrar todo el código para esto aquí