[Перевод] Как бы выглядела интернет-система в игре EvE Online
EvE online — увлекательная игра. Это одна из немногих ММО, в которых есть только один «сервер» для входа, что означает, что все играют в одном и том же логическом мире. У нее также был захватывающий набор событий, которые произошли внутри игры, и также она остается очень визуально привлекательной игрой:
Your browser does not support HTML5 video.
Здесь также находится обширная карта мира, на которой могут разместиться все эти игроки. На своем пике у EvE было 63 000 игроков онлайн в одном мире с 500 000 оформленных платных подписок на пике популярности, и, хотя с каждым годом это число становится все меньше, мир остается невероятно большим. Это означает, что переход из одной стороны к другой — это значительное количество времени (а также риск из-за зависимости игрока от фракции).
Перевод выполнен при поддержке компании EDISON Software, которая профессионально занимается безопасностью, а так же разрабатывает системы электронной медицинской проверки.
Вы путешествуете по разным областям, используя варп-режим (в пределах одной и той же системы), или прыгаете в разные системы с помощью прыжковых врат:
И все эти системы объединяются, чтобы создать карту красоты и сложности:
Я всегда рассматривал эту карту как сеть, это большая сеть систем, которые соединяются друг с другом, чтобы люди могли проходить через них, и большинство систем имеют более двух прыжковых врат. Это заставило меня задуматься о том, что произойдет, если вы в буквальном смысле взяли идею карты как сети? Как будет выглядеть интернет-система EvE?
Для этого нам нужно понять, как работает настоящий интернет. Интернет — это большая коллекция интернет-провайдеров, которые все численно идентифицируются с помощью стандартизированного и уникального номера интернет-провайдера, называемого номером автономной системы или ASN (или AS для более короткий вариант). Этим AS требуется способ обмена маршрутами друг с другом, так как им будут принадлежать диапазоны IP-адресов, и им нужен способ сообщить другим интернет-провайдерам, что их маршрутизаторы могут маршрутизировать эти IP-адреса. Для этого мир остановился на протоколе граничного шлюза или BGP.
BGP работает, «сообщая» другим AS (известным как узел) их маршруты:
Стандартное поведение BGP, когда он получает маршрут от узла, состоит в том, чтобы передать его всем другим узлам, к которым он также подключен. Это означает, что узлы автоматически поделятся своими таблицами маршрутизации друг с другом.
Однако это поведение полезно только в том случае, если вы используете BGP для отправки маршрутов во внутренние маршрутизаторы, поскольку современный Интернет имеет различные логические отношения друг с другом. Вместо сети современный интернет выглядит примерно так:
Тем не менее, EvE online установлен в будущем. Кто знает, полагается ли интернет на эту схему маршрутизации для получения прибыли. Давайте представим, что это не так, чтобы мы могли видеть, как BGP масштабируется в более крупных сетях.
Для этого нам нужно смоделировать реальное поведение BGP-роутера и соединения. Учитывая, что EvE имеет относительно низкое 8000~ количество систем, и реззоные 13,8 тыс. связей между ними. Я предположил, что на самом деле будет невозможно запустить 8000~ виртуальных машин с реальным BGP и сетью, чтобы выяснить, как эти реальные системы выглядят, когда действуют вместе как сеть.
Тем не менее, у нас нет неограниченных ресурсов, поэтому нам нужно будет найти способ сделать наименьший образ Linux как при использовании дискового пространства, так и при использовании памяти. Для этого я обратил внимание на встраиваемые системы, поскольку встраиваемые системы часто должны работать в средах с очень низким уровнем ресурсов. Я наткнулся на Buildroot, и через несколько часов у меня был небольшой образ Linux, содержащий только то, что мне нужно для работы этого проекта.
$ 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
Этот образ содержит загрузочную linux, которая также имеет: * Bird 2 BGP Daemon * tcpdump и My Traceroute (mtr) для сетевой отладки * busybox для базовой оболочки и системных утилит
Этот образ можно легко запустить в qemu с небольшим количеством опций:
qemu-system-i386 -kernel ../bzImage \
-hda rootfs.ext2 \
-hdb fat:./30045343/ \
-append "root=/dev/sda rw" \
-m 64
Для работы в сети я решил использовать недокументированную функцию из qemu (в моей версии), в которой вы можете направить два процесса qemu друг на друга и использовать сокеты UDP для передачи данных между ними. Это удобно, так как мы планируем предоставить большое количество ссылок, поэтому использование обычного метода адаптеров TUN/TAP может быстро привести к беспорядку.
Поскольку эта функция отчасти недокументирована, возникли некоторые проблемы с ее работой. Мне потребовалось много времени, чтобы понять, что сетевое имя в командной строке должно быть одинаковым для обеих сторон соединения. Позже выяснилось что эта функция уже хорошо документирована, как это обычно бывает. Изменениям нужно время чтобы добраться в более старые версии дистрибутива.
Как только это сработало, у нас появилось пара виртуальных машин, которые могут отправлять пакеты между собой, а гипервизор передает их как UDP-дейтаграммы. Поскольку мы будем запускать большое количество таких систем, нам потребуется быстрый способ их настройки с использованием предварительно созданной конфигурации. Для этого мы можем использовать удобную функцию qemu, которая позволяет вам взять каталог на гипервизоре и превратить его в виртуальную файловую систему FAT32. Это полезно, поскольку позволяет нам создавать каталог для каждой системы, которую мы планируем запустить, и каждый процесс qemu указывает на этот каталог, что означает, что мы можем использовать один и тот же загрузочный образ для всех виртуальных машин в кластере.
Поскольку каждая система имеет 64 МБ ОЗУ, и мы планируем использовать 8000 ~ ВМ, нам, безусловно, потребуется приличный объем ОЗУ. Для этого я использовал 3 m2.xlarge.x86 с packet.net«s, поскольку они предлагают 256 ГБ оперативной памяти с 2x Xeon Gold 5120, что означает, что они имеют приличное количество поддержки.
Я использовал другой проект с открытым исходным кодом для создания карты EvE в форме JSON, а затем создал программу собственной конфигурации на основе этих данных. Проведя несколько тестовых прогонов всего нескольких систем, я доказал, что они могут брать конфигурацию из VFAT и устанавливать сеансы BGP друг с другом по этому поводу.
Итак, я сделал решающий шаг к загрузке вселенной:
Сначала я попытался запустить все системы в одном большом событии, но, к сожалению, это привело к большому взрыву в отношении загрузки системы, поэтому после этого я переключился на запуск системы каждые 2,5 секунды и 48 ядер системы в итоге позаботились об этом.
Во время процесса загрузки я обнаружил, что вы увидите большие «взрывы» использования ЦП над всеми виртуальными машинами, позже я выяснил, что это были большие части вселенной, соединяющиеся друг с другом, таким образом вызывая большие объемы трафика BGP по обе стороны недавно подключенных виртуальных машин.
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
В итоге мы увидели несколько довольно удивительных путей BGP, поскольку каждая система объявляет /48 адресов IPv6, вы можете видеть маршруты к каждой системе и ко всем другим системам, через которые он должен был бы пройти, чтобы попасть туда.
$ 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
Я сделал снимок таблицы маршрутизации на каждом маршрутизаторе во вселенной, а затем изобразил часто используемые системы для доступа к другим системам, однако это изображение огромное. Вот небольшая версия этого в публикации, если вы нажмете на изображение, имейте в виду, что это изображение, скорее всего, заставит ваше устройство исчерпать память
После этого я подумал, что еще вы можете отобразить в маршрутизируемых сетях BGP? Не могли бы вы использовать модель меньшего размера, чтобы проверить, как работает конфигурация маршрутизации в крупных сетях? Я подготовил файл, который отобразил лондонскую систему метро, чтобы проверить это:
Система TFL намного меньше и имеет намного больше прыжков, которые имеют только одно направление, поскольку большинство станций имеют только одну «линию» транспорта, однако мы можем извлечь из этого одну вещь, мы можем использовать это, чтобы безопасно играть с BGP MED«s.
Однако существует проблема, когда мы рассматриваем карту TFL как сеть BGP, в реальном мире время/задержка между каждой остановкой не одинаковы, и поэтому, если бы мы имитировали эту задержку, мы бы не шли в обход системы так быстро, как мы могли бы, так как мы смотрим только на наименьшее количество станций, чтобы пройти путь.
Однако благодаря Закону о свободе информации (FOIA), запрос, который был отправлен в TFL, предоставил нам время, необходимое для перехода с одной станции на другую. Они были сгенерированы в конфигурации BGP маршрутизаторов, например:
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;
};
}
В session1 временной промежуток между двумя станциями составляет 1,6 минуты, другой путь из этой станции — 4,86 минуты. Этот номер добавляется в маршрут для каждой станции/маршрутизатора, через которую он проходит. Это означает, что каждый маршрутизатор/станция в сети знает, что пришло время добраться до каждой станции через каждый маршрут:
Это означает, что traceroutes точно определяет, как вы можете перемещаться по Лондону, например, на мою станцию в Паддингтон:
Мы также можем повеселиться с BGP, имитируя техническое обслуживание или инцидент на станции Ватерлоо:
И как вся сеть мгновенно выбирает следующий самый быстрый маршрут, а не тот, с наименьшим количеством проходящих станций.
И это магия BGP MED в маршрутизации!
Код для всего этого уже доступен. Вы можете создавать свои собственные сетевые структуры с достаточно простой JSON-схемой или просто использовать EvE онлайн или TFL, поскольку они уже находятся в репозитории.
Вы можете найти весь код для этого здесь
