EvE online adalah game yang menyenangkan. Ini adalah salah satu dari beberapa MMO di mana hanya ada satu "server" untuk masuk, yang berarti bahwa semua orang bermain di dunia logis yang sama. Dia juga memiliki serangkaian peristiwa menarik yang terjadi di dalam permainan, dan dia juga tetap menjadi permainan yang sangat menarik secara visual:
Ada juga peta dunia luas di mana semua pemain ini bisa masuk. Pada puncaknya, EvE memiliki 63.000 pemain online di satu dunia dengan 500.000 langganan terdaftar terdaftar di puncak popularitas, dan meskipun jumlah ini semakin kecil setiap tahun, dunia tetap sangat besar. Ini berarti bahwa transisi dari satu sisi ke sisi lain adalah jumlah waktu yang signifikan (dan juga risiko karena ketergantungan pemain pada fraksi).
Terjemahan didukung oleh EDISON Software , sebuah perusahaan keamanan profesional, dan juga mengembangkan sistem verifikasi medis elektronik .Anda melakukan perjalanan ke berbagai daerah menggunakan mode warp (dalam sistem yang sama), atau melompat ke sistem yang berbeda menggunakan gerbang melompat:
Dan semua sistem ini bergabung untuk membuat peta keindahan dan kompleksitas:
Saya selalu menganggap kartu ini sebagai jaringan, ini adalah jaringan besar sistem yang terhubung satu sama lain sehingga orang dapat melewatinya, dan sebagian besar sistem memiliki lebih dari dua gerbang melompat. Itu membuat saya berpikir tentang apa yang akan terjadi jika Anda benar-benar mengambil ide peta sebagai jaringan? Akan seperti apa sistem Internet EvE?
Untuk melakukan ini, kita perlu memahami cara kerja Internet yang sebenarnya. Internet adalah kumpulan besar penyedia Internet yang semuanya secara numerik diidentifikasi menggunakan nomor penyedia Internet standar dan unik, yang disebut Autonomous System Number atau ASN (atau AS untuk versi yang lebih pendek). AS ini membutuhkan cara untuk bertukar rute satu sama lain, karena mereka akan memiliki rentang alamat IP, dan mereka membutuhkan cara untuk memberi tahu penyedia Internet lainnya bahwa router mereka dapat merutekan alamat IP ini. Untuk melakukan ini, dunia berhenti pada protokol gateway batas atau BGP.
BGP bekerja dengan “memberi tahu” AS lain (dikenal sebagai tuan rumah) rute mereka:
Perilaku standar BGP ketika menerima rute dari host adalah untuk meneruskannya ke semua host lain yang juga terhubung. Ini berarti bahwa node akan secara otomatis berbagi tabel perutean satu sama lain.
Namun, perilaku ini hanya berguna jika Anda menggunakan BGP untuk mengirim rute ke router internal, karena Internet modern memiliki hubungan logis yang berbeda satu sama lain. Alih-alih jaringan, Internet modern terlihat seperti ini:
Namun, EvE online dipasang di masa depan. Siapa tahu kalau Internet mengandalkan skema perutean ini untuk untung. Mari kita bayangkan bahwa ini bukan supaya kita dapat melihat bagaimana BGP berskala di jaringan yang lebih besar.
Untuk melakukan ini, kita perlu mensimulasikan perilaku aktual dari router BGP dan koneksi. Mengingat bahwa EvE memiliki 8000 ~ jumlah sistem yang relatif rendah, dan 13,8 ribu tautan di antaranya. Saya menyarankan bahwa sebenarnya tidak mungkin untuk menjalankan 8000 ~ mesin virtual dengan BGP nyata dan jaringan untuk mencari tahu bagaimana sistem nyata ini terlihat ketika mereka bertindak bersama sebagai sebuah jaringan.
Namun, kami tidak memiliki sumber daya yang tidak terbatas, jadi kami akan perlu menemukan cara untuk membuat citra Linux terkecil baik saat menggunakan ruang disk dan menggunakan memori. Untuk ini, saya menarik perhatian pada sistem tertanam, karena sistem tertanam sering harus bekerja di lingkungan dengan tingkat sumber daya yang sangat rendah. Saya menemukan
Buildroot , dan setelah beberapa jam saya memiliki gambar Linux kecil yang hanya berisi apa yang saya butuhkan untuk proyek ini untuk bekerja.
$ 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
Gambar ini berisi boot linux, yang juga memiliki: *
Bird 2 BGP Daemon *
tcpdump dan My Traceroute (mtr) untuk debugging jaringan *
busybox untuk shell dasar dan utilitas sistem
Gambar ini dapat dengan mudah dijalankan di qemu dengan beberapa opsi:
qemu-system-i386 -kernel ../bzImage \ -hda rootfs.ext2 \ -hdb fat:./30045343/ \ -append "root=/dev/sda rw" \ -m 64
Untuk bekerja di jaringan, saya memutuskan untuk menggunakan fungsi tidak berdokumen dari qemu (dalam versi saya), di mana Anda dapat mengarahkan dua proses qemu satu sama lain dan menggunakan soket UDP untuk mentransfer data di antara mereka. Ini nyaman, karena kami berencana untuk menyediakan sejumlah besar tautan, jadi menggunakan metode adaptor
TUN / TAP yang biasa dapat dengan cepat menimbulkan kebingungan.
Karena fitur ini sebagian tidak berdokumen, ada beberapa masalah dengan operasinya. Butuh waktu lama bagi saya untuk memahami bahwa nama jaringan pada baris perintah harus sama untuk kedua sisi koneksi. Belakangan ternyata fungsi ini sudah terdokumentasi dengan baik, seperti yang biasa terjadi. Perubahan memerlukan waktu untuk sampai ke versi distribusi yang lebih lama.
Segera setelah ini berhasil, kami mendapatkan beberapa mesin virtual yang dapat saling mengirim paket, dan hypervisor mengirimkannya sebagai datagram UDP. Karena kita akan meluncurkan sejumlah besar sistem seperti itu, kita akan memerlukan cara cepat untuk mengkonfigurasinya menggunakan konfigurasi yang dibuat sebelumnya. Untuk melakukan ini, kita dapat menggunakan fungsi qemu yang nyaman, yang memungkinkan Anda untuk mengambil direktori pada hypervisor dan mengubahnya menjadi sistem file virtual FAT32. Ini berguna karena memungkinkan kita untuk membuat direktori untuk setiap sistem yang kita rencanakan untuk mulai, dan setiap proses qemu menunjuk ke direktori ini, yang berarti bahwa kita dapat menggunakan image boot yang sama untuk semua mesin virtual di cluster.
Karena setiap sistem memiliki 64 MB RAM, dan kami berencana untuk menggunakan 8000 ~ VM, kami tentu membutuhkan jumlah RAM yang layak. Untuk ini, saya menggunakan 3 m2.xlarge.x86 dengan packet.net's, karena mereka menawarkan 256 GB RAM dengan 2x Xeon Gold 5120, yang berarti bahwa mereka memiliki jumlah dukungan yang layak.
Saya menggunakan
proyek open source lain untuk membuat peta EvE dalam bentuk JSON, dan kemudian membuat program konfigurasi khusus berdasarkan data ini. Setelah melakukan beberapa uji coba hanya beberapa sistem, saya membuktikan bahwa mereka dapat mengambil konfigurasi dari VFAT dan membuat sesi BGP satu sama lain tentang ini.
Jadi, saya mengambil langkah tegas menuju pemuatan alam semesta:
Pada awalnya saya mencoba untuk memulai semua sistem dalam satu peristiwa besar, tetapi, sayangnya, ini menyebabkan ledakan besar dalam hal memuat sistem, jadi setelah itu saya beralih untuk memulai sistem setiap 2,5 detik dan 48 core sistem akhirnya menangani hal ini.
Selama proses boot, saya menemukan bahwa Anda akan melihat "ledakan" besar penggunaan CPU di semua mesin virtual, kemudian saya menemukan bahwa ini adalah bagian besar dari alam semesta yang terhubung satu sama lain, sehingga menyebabkan sejumlah besar lalu lintas BGP di kedua sisi virtual yang baru terhubung. mobil.
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
Pada akhirnya, kami melihat beberapa jalur BGP yang sangat menakjubkan, karena setiap sistem mengiklankan / 48 alamat IPv6, Anda dapat melihat rute ke setiap sistem dan ke semua sistem lain yang harus dilalui untuk sampai ke sana.
$ 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
Saya mengambil snapshot tabel routing pada setiap router di alam semesta, dan kemudian menggambarkan sistem yang biasa digunakan untuk mengakses sistem lain, namun gambar ini sangat besar. Ini adalah versi kecil dari ini dalam publikasi, jika Anda mengklik gambar, ingatlah
bahwa gambar ini kemungkinan besar akan menyebabkan perangkat Anda kehabisan memori.
Setelah itu, saya pikir, apa lagi yang bisa Anda petakan ke jaringan yang diarahkan BGP? Bisakah Anda menggunakan model yang lebih kecil untuk menguji bagaimana konfigurasi perutean bekerja pada jaringan besar?
Saya menyiapkan file yang menampilkan sistem London Underground untuk memverifikasi ini :
Sistem TFL jauh lebih kecil dan memiliki lebih banyak lompatan yang hanya memiliki satu arah, karena sebagian besar stasiun hanya memiliki satu "jalur" transportasi, namun kita dapat belajar satu hal dari ini, kita dapat menggunakan ini untuk bermain dengan aman dengan
BGP MED .
Namun, ada masalah ketika kita menganggap kartu TFL sebagai jaringan BGP, di dunia nyata waktu / keterlambatan antara setiap perhentian tidak sama, dan oleh karena itu, jika kita mensimulasikan penundaan ini, kita tidak akan berkeliling sistem secepat mungkin, karena kita hanya melihat jumlah stasiun terkecil untuk jalan.
Namun, berkat Freedom of Information Act (FOIA), permintaan yang dikirim ke
TFL memberi kami waktu yang diperlukan untuk berpindah dari satu stasiun ke stasiun lainnya. Mereka dihasilkan dalam konfigurasi router BGP, misalnya:
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; }; }
Dalam
session1 interval waktu antara dua stasiun adalah 1,6 menit, sebaliknya dari stasiun ini adalah 4,86 menit. Nomor ini ditambahkan ke rute untuk setiap stasiun / router yang dilaluinya. Ini berarti bahwa setiap router / stasiun di jaringan tahu bahwa sudah waktunya untuk sampai ke setiap stasiun melalui setiap rute:
Ini berarti bahwa traceroutes menentukan dengan tepat bagaimana Anda dapat berkeliling London, misalnya, ke stasiun Paddington saya:
Kami juga dapat bersenang-senang dengan BGP dengan mensimulasikan pemeliharaan atau insiden di Stasiun Waterloo:
Dan karena seluruh jaringan secara instan memilih rute tercepat berikutnya, dan bukan yang dengan jumlah paling sedikit stasiun yang lewat.
Dan ini adalah keajaiban BGP MED dalam perutean!
Kode untuk semua ini sudah tersedia. Anda dapat membuat struktur jaringan Anda sendiri dengan skema JSON yang cukup sederhana atau cukup gunakan EvE online atau TFL, karena sudah ada dalam repositori.
Anda dapat menemukan semua kode untuk ini di sini