Хабрахабр

[Перевод] Как бы выглядела интернет-система в игре EvE Online

EvE online — увлекательная игра. Это одна из немногих ММО, в которых есть только один «сервер» для входа, что означает, что все играют в одном и том же логическом мире. У нее также был захватывающий набор событий, которые произошли внутри игры, и также она остается очень визуально привлекательной игрой:

Your browser does not support HTML5 video.

Здесь также находится обширная карта мира, на которой могут разместиться все эти игроки. На своем пике у EvE было 63 000 игроков онлайн в одном мире с 500 000 оформленных платных подписок на пике популярности, и, хотя с каждым годом это число становится все меньше, мир остается невероятно большим. Это означает, что переход из одной стороны к другой — это значительное количество времени (а также риск из-за зависимости игрока от фракции).
Перевод выполнен при поддержке компании EDISON Software, которая профессионально занимается безопасностью, а так же разрабатывает системы электронной медицинской проверки.

Вы путешествуете по разным областям, используя варп-режим(в пределах одной и той же системы), или прыгаете в разные системы с помощью прыжковых врат:

image

И все эти системы объединяются, чтобы создать карту красоты и сложности:

image

Это заставило меня задуматься о том, что произойдет, если вы в буквальном смысле взяли идею карты как сети? Я всегда рассматривал эту карту как сеть, это большая сеть систем, которые соединяются друг с другом, чтобы люди могли проходить через них, и большинство систем имеют более двух прыжковых врат. Как будет выглядеть интернет-система EvE?

Интернет — это большая коллекция интернет-провайдеров, которые все численно идентифицируются с помощью стандартизированного и уникального номера интернет-провайдера, называемого номером автономной системы или ASN (или AS для более короткий вариант). Для этого нам нужно понять, как работает настоящий интернет. Для этого мир остановился на протоколе граничного шлюза или BGP. Этим AS требуется способ обмена маршрутами друг с другом, так как им будут принадлежать диапазоны IP-адресов, и им нужен способ сообщить другим интернет-провайдерам, что их маршрутизаторы могут маршрутизировать эти IP-адреса.

BGP работает, «сообщая» другим AS (известным как узел) их маршруты:

image

Это означает, что узлы автоматически поделятся своими таблицами маршрутизации друг с другом. Стандартное поведение BGP, когда он получает маршрут от узла, состоит в том, чтобы передать его всем другим узлам, к которым он также подключен.

image

Вместо сети современный интернет выглядит примерно так: Однако это поведение полезно только в том случае, если вы используете BGP для отправки маршрутов во внутренние маршрутизаторы, поскольку современный Интернет имеет различные логические отношения друг с другом.

image

Кто знает, полагается ли интернет на эту схему маршрутизации для получения прибыли. Тем не менее, EvE online установлен в будущем. Давайте представим, что это не так, чтобы мы могли видеть, как BGP масштабируется в более крупных сетях.

Учитывая, что EvE имеет относительно низкое 8000~ количество систем, и реззоные 13,8 тыс. Для этого нам нужно смоделировать реальное поведение BGP-роутера и соединения. Я предположил, что на самом деле будет невозможно запустить 8000~ виртуальных машин с реальным BGP и сетью, чтобы выяснить, как эти реальные системы выглядят, когда действуют вместе как сеть. связей между ними.

image

Для этого я обратил внимание на встраиваемые системы, поскольку встраиваемые системы часто должны работать в средах с очень низким уровнем ресурсов. Тем не менее, у нас нет неограниченных ресурсов, поэтому нам нужно будет найти способ сделать наименьший образ 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 указывает на этот каталог, что означает, что мы можем использовать один и тот же загрузочный образ для всех виртуальных машин в кластере. Для этого мы можем использовать удобную функцию qemu, которая позволяет вам взять каталог на гипервизоре и превратить его в виртуальную файловую систему FAT32.

Для этого я использовал 3 m2.xlarge.x86 с packet.net’s, поскольку они предлагают 256 ГБ оперативной памяти с 2x Xeon Gold 5120, что означает, что они имеют приличное количество поддержки. Поскольку каждая система имеет 64 МБ ОЗУ, и мы планируем использовать 8000 ~ ВМ, нам, безусловно, потребуется приличный объем ОЗУ.

image

Проведя несколько тестовых прогонов всего нескольких систем, я доказал, что они могут брать конфигурацию из VFAT и устанавливать сеансы BGP друг с другом по этому поводу. Я использовал другой проект с открытым исходным кодом для создания карты EvE в форме JSON, а затем создал программу собственной конфигурации на основе этих данных.

image

Итак, я сделал решающий шаг к загрузке вселенной:

image

Сначала я попытался запустить все системы в одном большом событии, но, к сожалению, это привело к большому взрыву в отношении загрузки системы, поэтому после этого я переключился на запуск системы каждые 2,5 секунды и 48 ядер системы в итоге позаботились об этом.

image

Во время процесса загрузки я обнаружил, что вы увидите большие «взрывы» использования ЦП над всеми виртуальными машинами, позже я выяснил, что это были большие части вселенной, соединяющиеся друг с другом, таким образом вызывая большие объемы трафика BGP по обе стороны недавно подключенных виртуальных машин.

image

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

Я сделал снимок таблицы маршрутизации на каждом маршрутизаторе во вселенной, а затем изобразил часто используемые системы для доступа к другим системам, однако это изображение огромное. Вот небольшая версия этого в публикации, если вы нажмете на изображение, имейте в виду, что это изображение, скорее всего, заставит ваше устройство исчерпать память

image

Не могли бы вы использовать модель меньшего размера, чтобы проверить, как работает конфигурация маршрутизации в крупных сетях? После этого я подумал, что еще вы можете отобразить в маршрутизируемых сетях BGP? Я подготовил файл, который отобразил лондонскую систему метро, чтобы проверить это:

image

Система TFL намного меньше и имеет намного больше прыжков, которые имеют только одно направление, поскольку большинство станций имеют только одну «линию» транспорта, однако мы можем извлечь из этого одну вещь, мы можем использовать это, чтобы безопасно играть с BGP MED’s.

Однако существует проблема, когда мы рассматриваем карту TFL как сеть BGP, в реальном мире время/задержка между каждой остановкой не одинаковы, и поэтому, если бы мы имитировали эту задержку, мы бы не шли в обход системы так быстро, как мы могли бы, так как мы смотрим только на наименьшее количество станций, чтобы пройти путь.

image

Они были сгенерированы в конфигурации BGP маршрутизаторов, например: Однако благодаря Закону о свободе информации (FOIA), запрос, который был отправлен в TFL, предоставил нам время, необходимое для перехода с одной станции на другую.

protocol bgp session1 ; 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 минуты. Этот номер добавляется в маршрут для каждой станции/маршрутизатора, через которую он проходит. Это означает, что каждый маршрутизатор/станция в сети знает, что пришло время добраться до каждой станции через каждый маршрут:

image

Это означает, что traceroutes точно определяет, как вы можете перемещаться по Лондону, например, на мою станцию в Паддингтон:

image

Мы также можем повеселиться с BGP, имитируя техническое обслуживание или инцидент на станции Ватерлоо:

image

И как вся сеть мгновенно выбирает следующий самый быстрый маршрут, а не тот, с наименьшим количеством проходящих станций.

image

И это магия BGP MED в маршрутизации!

Вы можете создавать свои собственные сетевые структуры с достаточно простой JSON-схемой или просто использовать EvE онлайн или TFL, поскольку они уже находятся в репозитории. Код для всего этого уже доступен.

Вы можете найти весь код для этого здесь

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть