EvE online é um jogo divertido. Este é um dos poucos MMOs em que existe apenas um "servidor" para entrada, o que significa que todos jogam no mesmo mundo lógico. Ela também teve um emocionante conjunto de eventos que aconteceram dentro do jogo e também continua sendo um jogo visualmente atraente:
Há também um extenso mapa-múndi no qual todos esses jogadores podem caber. No auge, o EvE tinha 63.000 jogadores on-line em um mundo, com 500.000 assinaturas pagas registradas no auge da popularidade e, embora esse número esteja diminuindo a cada ano, o mundo permanece incrivelmente grande. Isso significa que a transição de um lado para o outro é uma quantidade significativa de tempo (bem como o risco devido à dependência do jogador na fração).
A tradução foi apoiada pela EDISON Software , uma empresa de segurança profissional, e também está desenvolvendo sistemas eletrônicos de verificação médica .Você viaja para áreas diferentes usando o modo de distorção (dentro do mesmo sistema) ou pula para sistemas diferentes usando portas de salto:
E todos esses sistemas se combinam para criar um mapa de beleza e complexidade:
Eu sempre considerei esta placa como uma rede, é uma grande rede de sistemas que se conectam entre si para que as pessoas possam passar por elas, e a maioria dos sistemas tem mais de dois portões de salto. Isso me fez pensar no que aconteceria se você literalmente tomasse a ideia de um mapa como uma rede? Como será o sistema EvE Internet?
Para fazer isso, precisamos entender como a Internet real funciona. A Internet é uma grande coleção de provedores de Internet, todos identificados numericamente usando um número de provedor de Internet padronizado e exclusivo, chamado Número de Sistema Autônomo ou ASN (ou ASN para a versão mais curta). Esses ASs precisam de uma maneira de trocar rotas entre si, porque possuirão intervalos de endereços IP e de informar a outros provedores de Internet que seus roteadores podem rotear esses endereços IP. Para fazer isso, o mundo parou no protocolo de gateway de limite ou BGP.
O BGP trabalha “informando” a outro AS (conhecido como host) suas rotas:
O comportamento padrão do BGP quando ele recebe uma rota de um host é transmiti-lo a todos os outros hosts aos quais também está conectado. Isso significa que os nós compartilharão automaticamente suas tabelas de roteamento entre si.
No entanto, esse comportamento só é útil se você usar o BGP para enviar rotas para roteadores internos, pois a Internet moderna possui diferentes relacionamentos lógicos entre si. Em vez da rede, a Internet moderna se parece com isso:
No entanto, o EvE online está instalado no futuro. Quem sabe se a Internet depende desse esquema de roteamento para obter lucro. Vamos imaginar que isso não ocorra para que possamos ver como o BGP se dimensiona em redes maiores.
Para fazer isso, precisamos simular o comportamento real do roteador BGP e da conexão. Dado que o EvE possui um número relativamente baixo de 8000 ~ de sistemas e 13,8 mil links entre eles. Sugeri que seria realmente impossível executar 8000 ~ máquinas virtuais com BGP real e uma rede para descobrir como esses sistemas reais se parecem quando agem juntos como uma rede.
No entanto, como não temos recursos ilimitados, precisamos encontrar uma maneira de criar a menor imagem do Linux ao usar espaço em disco e usar memória. Para isso, chamei a atenção para sistemas embarcados, já que os sistemas embarcados geralmente precisam trabalhar em ambientes com um nível muito baixo de recursos. Me deparei com o
Buildroot e, depois de algumas horas, tinha uma pequena imagem do Linux contendo apenas o que eu precisava para que este projeto funcionasse.
$ 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 imagem contém o Linux de inicialização, que também possui: *
Bird 2 BGP Daemon *
tcpdump e My Traceroute (mtr) para depuração de rede *
busybox para o shell base e utilitários do sistema
Esta imagem pode ser facilmente executada no qemu com algumas opções:
qemu-system-i386 -kernel ../bzImage \ -hda rootfs.ext2 \ -hdb fat:./30045343/ \ -append "root=/dev/sda rw" \ -m 64
Para trabalhar na rede, decidi usar uma função não documentada do qemu (na minha versão), na qual você pode direcionar dois processos do qemu entre si e usar soquetes UDP para transferir dados entre eles. Isso é conveniente, pois planejamos fornecer um grande número de links; portanto, o uso do método usual do adaptador
TUN / TAP pode levar rapidamente a confusão.
Como esse recurso é parcialmente indocumentado, houve alguns problemas com sua operação. Levei muito tempo para entender que o nome da rede na linha de comando deveria ser o mesmo para os dois lados da conexão. Mais tarde, verificou-se que essa função já está bem documentada, como geralmente acontece. As alterações levam tempo para chegar às versões mais antigas da distribuição.
Assim que isso funcionou, obtivemos algumas máquinas virtuais que podem enviar pacotes uma para a outra, e o hypervisor as envia como datagramas UDP. Como lançaremos um grande número desses sistemas, precisaremos de uma maneira rápida de configurá-los usando uma configuração criada anteriormente. Para fazer isso, podemos usar a conveniente função qemu, que permite pegar um diretório no hipervisor e transformá-lo em um sistema de arquivos virtual FAT32. Isso é útil porque nos permite criar um diretório para cada sistema que planejamos iniciar, e cada processo qemu aponta para esse diretório, o que significa que podemos usar a mesma imagem de inicialização para todas as máquinas virtuais no cluster.
Como cada sistema possui 64 MB de RAM e planejamos usar 8000 ~ VMs, certamente precisaremos de uma quantidade decente de RAM. Para isso, usei 3 m2.xlarge.x86 com o packet.net, pois eles oferecem 256 GB de RAM com o Xeon Gold 5120 2x, o que significa que eles têm uma quantidade razoável de suporte.
Usei
outro projeto de código aberto para criar um mapa EvE na forma de JSON e, em seguida, criei um programa de configuração personalizado com base nesses dados. Após realizar várias execuções de teste de apenas alguns sistemas, eu provei que eles podem pegar a configuração do VFAT e estabelecer sessões de BGP entre si sobre isso.
Então, dei o passo decisivo para carregar o universo:
No começo, tentei iniciar todos os sistemas em um grande evento, mas, infelizmente, isso levou a uma grande explosão em termos de carregamento do sistema; depois disso, mudei para iniciar o sistema a cada 2,5 segundos e 48 núcleos de sistema acabaram cuidando disso.
Durante o processo de inicialização, descobri que você veria grandes "explosões" do uso da CPU em todas as máquinas virtuais; depois descobri que essas eram grandes partes do universo conectadas entre si, causando grandes quantidades de tráfego BGP nos dois lados do recém-conectado virtual. 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
No final, vimos alguns caminhos BGP surpreendentes, já que cada sistema anuncia / 48 endereços IPv6, você pode ver as rotas para cada sistema e para todos os outros sistemas pelos quais precisaria passar para chegar lá.
$ 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
Tirei um instantâneo da tabela de roteamento em cada roteador no universo e, em seguida, descrevi os sistemas comumente usados para acessar outros sistemas, no entanto, essa imagem é enorme. Aqui está uma versão pequena desta publicação, se você clicar em uma imagem, lembre-se de
que essa imagem provavelmente fará com que o dispositivo fique
sem memória
Depois disso, pensei, o que mais você pode mapear para redes roteadas BGP? Você poderia usar um modelo menor para testar como a configuração de roteamento funciona em redes grandes?
Eu preparei um arquivo que exibia o sistema de metrô de Londres para verificar isso :
O sistema TFL é muito menor e tem muito mais saltos que têm apenas uma direção, já que a maioria das estações tem apenas uma "linha" de transporte, no entanto, podemos aprender uma coisa com isso, podemos usá-lo para brincar com segurança com os
BGP MED .
No entanto, há um problema quando consideramos uma placa TFL como uma rede BGP. No mundo real, o tempo / atraso entre cada parada não é o mesmo e, portanto, se simulássemos esse atraso, não percorreríamos o sistema o mais rápido possível, pois apenas olhamos para o menor número de estações a seguir.
No entanto, graças à Lei de Liberdade de Informação (FOIA), a solicitação enviada à
TFL nos forneceu o tempo necessário para passar de uma estação para outra. Eles foram gerados na configuração do roteador BGP, por exemplo:
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; }; }
Na
session1 intervalo de tempo entre duas estações é de 1,6 minutos, e o contrário desta estação é de 4,86 minutos. Este número é adicionado à rota para cada estação / roteador pela qual passa. Isso significa que cada roteador / estação na rede sabe que é hora de chegar a cada estação através de cada rota:
Isso significa que os rastreadores determinam exatamente como você pode viajar por Londres, por exemplo, até minha estação de Paddington:
Também podemos nos divertir com o BGP simulando manutenção ou um incidente na Estação Waterloo:
E como toda a rede escolhe instantaneamente a próxima rota mais rápida, e não aquela com o menor número de estações de passagem.
E essa é a mágica do BGP MED no roteamento!
O código para tudo isso já está disponível. Você pode criar suas próprias estruturas de rede com um esquema JSON bastante simples ou simplesmente usar o EvE online ou o TFL, pois eles já estão no repositório.
Você pode encontrar todo o código para isso aqui