EvE en ligne est un jeu amusant. C'est l'un des rares MMO dans lesquels il n'y a qu'un seul «serveur» pour l'entrée, ce qui signifie que tout le monde joue dans le même monde logique. Elle a également eu un ensemble passionnant d'événements qui se sont produits dans le jeu, et elle reste également un jeu très attrayant sur le plan visuel:
Il existe également une vaste carte du monde sur laquelle tous ces joueurs peuvent s'insérer. À son apogée, EvE comptait 63 000 joueurs en ligne dans un monde avec 500 000 abonnements payants enregistrés au sommet de sa popularité, et bien que ce nombre diminue chaque année, le monde reste incroyablement grand. Cela signifie que la transition d'un côté à l'autre est un temps important (ainsi que le risque en raison de la dépendance du joueur à la fraction).
La traduction a été prise en charge par EDISON Software , une société de sécurité professionnelle, et développe également des systèmes de vérification médicale électronique .Vous voyagez dans différentes zones en utilisant le mode de distorsion (au sein du même système), ou sautez vers différents systèmes en utilisant des portes sautantes:
Et tous ces systèmes se combinent pour créer une carte de la beauté et de la complexité:
J'ai toujours considéré cette carte comme un réseau, c'est un grand réseau de systèmes qui se connectent les uns aux autres afin que les gens puissent les traverser, et la plupart des systèmes ont plus de deux portes de saut. Cela m'a fait penser à ce qui se passerait si vous preniez littéralement l'idée d'une carte comme réseau? À quoi ressemblera le système Internet EvE?
Pour ce faire, nous devons comprendre comment fonctionne le véritable Internet. Internet est une grande collection de fournisseurs Internet qui sont tous identifiés numériquement à l'aide d'un numéro de fournisseur Internet standardisé et unique, appelé numéro de système autonome ou ASN (ou AS pour la version plus courte). Ces AS ont besoin d'un moyen d'échanger des itinéraires les uns avec les autres, car ils possèdent des plages d'adresses IP, et ils ont besoin d'un moyen de dire aux autres fournisseurs Internet que leurs routeurs peuvent router ces adresses IP. Pour ce faire, le monde s'est arrêté sur le protocole de passerelle de frontière ou BGP.
BGP fonctionne en «disant» à d'autres AS (appelés hôtes) leurs itinéraires:
Le comportement standard de BGP lorsqu'il reçoit un itinéraire d'un hôte est de le transmettre à tous les autres hôtes auxquels il est également connecté. Cela signifie que les nœuds partageront automatiquement leurs tables de routage entre eux.
Cependant, ce comportement n'est utile que si vous utilisez BGP pour envoyer des routes aux routeurs internes, car Internet moderne a des relations logiques différentes entre elles. Au lieu du réseau, l'Internet moderne ressemble à ceci:
Cependant, EvE en ligne est installé à l'avenir. Qui sait si Internet compte sur ce schéma de routage pour le profit. Imaginons que ce ne soit pas pour que nous puissions voir comment BGP évolue dans des réseaux plus grands.
Pour ce faire, nous devons simuler le comportement réel du routeur BGP et de la connexion. Étant donné qu'EvE a un nombre relativement faible de 8 000 ~ systèmes et 13,8 mille liaisons entre eux. J'ai suggéré qu'il serait en fait impossible d'exécuter 8000 ~ machines virtuelles avec un BGP réel et un réseau pour comprendre à quoi ressemblent ces systèmes réels lorsqu'ils agissent ensemble en tant que réseau.
Cependant, nous n'avons pas de ressources illimitées, nous devrons donc trouver un moyen de créer la plus petite image Linux à la fois lors de l'utilisation de l'espace disque et de la mémoire. Pour cela, j'ai attiré l'attention sur les systèmes embarqués, car les systèmes embarqués doivent souvent fonctionner dans des environnements avec un niveau de ressources très faible. Je suis tombé sur
Buildroot , et après quelques heures, j'avais une petite image Linux contenant uniquement ce dont j'avais besoin pour que ce projet fonctionne.
$ 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
Cette image contient boot linux, qui a Ă©galement: *
Bird 2 BGP Daemon *
tcpdump et My Traceroute (mtr) pour le débogage réseau *
busybox pour le shell de base et les utilitaires système
Cette image peut être facilement exécutée dans qemu avec quelques options:
qemu-system-i386 -kernel ../bzImage \ -hda rootfs.ext2 \ -hdb fat:./30045343/ \ -append "root=/dev/sda rw" \ -m 64
Pour travailler sur le réseau, j'ai décidé d'utiliser une fonction non documentée de qemu (dans ma version), dans laquelle vous pouvez diriger deux processus qemu l'un vers l'autre et utiliser des sockets UDP pour transférer des données entre eux. C'est pratique, car nous prévoyons de fournir un grand nombre de liens, donc l'utilisation de la méthode d'adaptateur
TUN / TAP habituelle peut rapidement conduire Ă la confusion.
Cette fonctionnalité étant partiellement non documentée, son fonctionnement a rencontré quelques problèmes. Il m'a fallu beaucoup de temps pour comprendre que le nom du réseau sur la ligne de commande devrait être le même pour les deux côtés de la connexion. Plus tard, il s'est avéré que cette fonction est déjà bien documentée, comme cela arrive généralement. Les modifications prennent du temps pour accéder aux anciennes versions de la distribution.
Dès que cela a fonctionné, nous avons obtenu quelques machines virtuelles qui peuvent s'envoyer des paquets, et l'hyperviseur les envoie sous forme de datagrammes UDP. Étant donné que nous lancerons un grand nombre de ces systèmes, nous aurons besoin d'un moyen rapide de les configurer à l'aide d'une configuration créée précédemment. Pour ce faire, nous pouvons utiliser la fonction qemu pratique, qui vous permet de prendre un répertoire sur l'hyperviseur et de le transformer en un système de fichiers virtuel FAT32. Ceci est utile car il nous permet de créer un répertoire pour chaque système que nous prévoyons de démarrer, et chaque processus qemu pointe vers ce répertoire, ce qui signifie que nous pouvons utiliser la même image de démarrage pour toutes les machines virtuelles du cluster.
Étant donné que chaque système dispose de 64 Mo de RAM et que nous prévoyons d'utiliser 8000 ~ VM, nous aurons certainement besoin d'une quantité décente de RAM. Pour cela, j'ai utilisé 3 m2.xlarge.x86 avec packet.net, car ils offrent 256 Go de RAM avec 2x Xeon Gold 5120, ce qui signifie qu'ils ont un support décent.
J'ai utilisé
un autre projet open source pour créer une carte EvE sous la forme de JSON, puis j'ai créé un programme de configuration personnalisé basé sur ces données. Après avoir effectué plusieurs tests de quelques systèmes, j'ai prouvé qu'ils pouvaient prendre la configuration de VFAT et établir des sessions BGP entre eux à ce sujet.
J'ai donc franchi une étape décisive vers le chargement de l'univers:
Au début, j'ai essayé de démarrer tous les systèmes en un seul grand événement, mais malheureusement, cela a conduit à une grande explosion en termes de chargement du système.Après cela, je suis passé au démarrage du système toutes les 2,5 secondes et 48 cœurs de système se sont finalement occupés de cela.
Au cours du processus de démarrage, j'ai découvert que vous verriez de grandes «explosions» d'utilisation du processeur sur toutes les machines virtuelles, plus tard, j'ai découvert qu'il s'agissait de grandes parties de l'univers se connectant les unes aux autres, provoquant ainsi de grandes quantités de trafic BGP des deux côtés du virtuel nouvellement connecté. voitures.
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
À la fin, nous avons vu des chemins BGP assez étonnants, puisque chaque système publie / 48 adresses IPv6, vous pouvez voir les routes vers chaque système et vers tous les autres systèmes qu'il faudrait traverser pour y arriver.
$ 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
J'ai pris un instantané de la table de routage sur chaque routeur de l'univers, puis j'ai décrit les systèmes couramment utilisés pour accéder à d'autres systèmes, mais cette image est énorme. Voici une petite version de ceci dans la publication, si vous cliquez sur une image, gardez à l'esprit
que cette image entraînera très probablement un manque de mémoire sur votre appareil
Après cela, j'ai pensé, que pouvez-vous mapper d'autre aux réseaux routés BGP? Pourriez-vous utiliser un modèle plus petit pour tester le fonctionnement de la configuration de routage sur les grands réseaux?
J'ai préparé un fichier qui affiche le système du métro de Londres pour vérifier cela :
Le système TFL est beaucoup plus petit et a beaucoup plus de sauts qui n'ont qu'une seule direction, car la plupart des stations n'ont qu'une seule «ligne» de transport, mais nous pouvons en tirer une leçon, nous pouvons l'utiliser pour jouer en toute sécurité avec les
BGP MED .
Cependant, il y a un problème lorsque nous considérons une carte TFL comme un réseau BGP, dans le monde réel, le temps / retard entre chaque arrêt n'est pas le même, et donc, si nous simulions ce retard, nous ne ferions pas le tour du système aussi vite que possible, car nous ne regardons que le plus petit nombre de stations pour suivre le chemin.
Cependant, grâce au Freedom of Information Act (FOIA), la demande adressée au
TFL nous a donné le temps nécessaire pour passer d'une station à une autre. Ils ont été générés dans la configuration du routeur BGP, par exemple:
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; }; }
Dans la
session1 intervalle de temps entre deux stations est de 1,6 minutes, l'autre sens depuis cette station est de 4,86 ​​minutes. Ce numéro est ajouté à l'itinéraire pour chaque station / routeur par lequel il passe. Cela signifie que chaque routeur / station sur le réseau sait qu'il est temps de se rendre à chaque station par chaque itinéraire:
Cela signifie que traceroutes détermine exactement comment vous pouvez vous déplacer dans Londres, par exemple, jusqu'à ma gare de Paddington:
Nous pouvons Ă©galement nous amuser avec BGP en simulant la maintenance ou un incident Ă la gare de Waterloo:
Et comme l'ensemble du réseau choisit instantanément le prochain itinéraire le plus rapide, et non celui avec le moins de stations qui passent.
Et c'est la magie de BGP MED en routage!
Le code pour tout cela est déjà disponible. Vous pouvez créer vos propres structures de réseau avec un schéma JSON assez simple ou simplement utiliser EvE en ligne ou TFL, car elles sont déjà dans le référentiel.
Vous pouvez trouver tout le code pour cela ici