Всем добрый день.
Как известно, во время еды приходит аппетит. А по ходу освоения новых сетевых технологий – здоровый инженерный азарт. При этом обычно используются программные симуляторы сетей.
Важным достоинством таких симуляторов является их универсальность (можно одновременно запускать образы устройств от разных вендоров) и низкий порог входа (можно начать работу на полностью бесплатных программных компонентах и домашнем ноутбуке).
Однако, по мере успешного продвижения, сетевые топологии становятся все более «развесистыми», а используемые образы операционных систем сетевых устройств – все более «прожорливыми». Поэтому, рано или поздно текущая аппаратная платформа становится тормозом прогресса.
Введение
В свое время пришлось изучать только входивший в моду протокол LISP (Locator/ID Separation Protocol) от одного «сильно хлопнувшего дверью» сетевого вендора. Использовал домашний ноутбук с его 8 виртуальнами ядрами и 16 Гигабайтами (уже после модернизации) оперативной памяти. При этом удалось запустить всего 3 узла с поддержкой LISP и несколько совсем «легковесных» IOL-узлов в качестве «обвязки». Помнится, с самим протоколом разобраться удалось – но для ноута это оказалось пределом.
Выделенная на работе мощная виртуалка с некоторыми натягами позволила протянуть до завершения проекта (добавились несколько узлов и система управления от другого сетевого вендора, который совсем недавно был куплен HPE).
Тем не менее, уже тогда начало складываться ощущение, что любых ресурсов когда-то окажется недостаточно. А значит, надо заранее как-то планировать стратегии добавления ресурсов. Ну и, естественно, иметь возможность использовать эти дополнительные ресурсы.
Опыт – сын ошибок трудных
Распространенными (и имеющими заслуженную репутацию) симуляторами сетей как минимум являются:
EVE-NG (есть платная версия PRO)
PNETLAB
GNS3
containerlab.dev – упомянута скорее для полноты картины, так как нормальной «рисовалки» нет, каждое соединение нужно с боем протягивать через потроха Docker.
Вообще, симулятор сети – это инструмент, т.е. решение некоторой задачи. Поэтому при мысли «что выбрать?» вспоминается эпизод из «Чебурашки»: «так это Вы угнали компрессор? И как Вы собирались его использовать?». И тут первый очевидный ответ - EVE-NG - не всегда будет бесспорно правильным.
Дело в том, что симулятор сети может быть использован (как минимум) в следующих сценариях:
Изучение новых технологий и приложений
Подготовка к экзамену («письменному» или лабе)
Тестирование идей перед внедрением
С одной стороны, тестирование идей (Proof of Concept) иногда может выполняться даже на виртуальных образах от другого вендора (если целевой вендор не предоставляет виртуализованные образы своих узлов – но при обязательном понимании ограничений целевых устройств). Например, протоколы BGP и OSPF достаточно стандартизованы и работают схоже почти на любых сетевых устройствах.
С другой стороны, первые 2 пункта требований логично взаимосвязаны – при подготовке к экзамену неизбежно приходится изучать новые технологии и приложения (а постигнув технологии – можно и на экзамен замахнуться).
Однако, если в версии 5.1 SP-лабы «того самого» (определенный артикль «the»), «особенно сильно хлопнувшего дверью», вендора используются достаточно ресурсоемкие виртуалки NSO, CSR1000v и IOS-XRv9K (чего они сами даже не пытаются скрывать) – желательно использовать именно эти семейства и версии. Ибо «тот самый» вендор славится тем, что на лабе творчески использует даже ошибки в собственных прошивках и документации.
Плюс, на лабе таких виртуалок может быть запущено много (на самом деле, около 50). При этом, 50 – это заведомо меньше чем даже лицензионные ограничения в 64 узла для EVE-NG Community. Однако, на всех проверенных платформах (см. список выше, кроме containerlab.dev – не проверял) при первых попытках запустить IOS-XRv9K в сколько-нибудь значимом количестве (скажем, 8 экземпляров одновременно) начинались сбои – в лучшем случае с сообщениями об ошибке и перезагрузкой, но чаще – просто зависание при инициализации. Да и простой расчет показывал, что если 50 узлов умножить на 4 vCPU (столько нужно на каждый узел IOS-XRv9K), получится 200 vCPU. А если посмотреть на цены за аренду близкого к этому значению сервера (96 cores / 192 threads) – получится почти запретительная цифра (во всяком случае, 5 лет назад более скромная модернизация домашнего стационарника обошлась мне кратно дешевле, чем просят за месячную аренду этого монстра).
Кто нам мешает – тот нам поможет
И в этой, казалось, безнадежной ситуации, неожиданная подсказка пришла со стороны «того самого» вендора – в списке «лабораторного ПО» глаз зацепился за IOS-XRd. Это – контейнерная версия IOS-XRv9K, требующая в версии control plane много меньше ресурсов (1 vCPU и 2GB RAM) и стартующая стабильнее и намного быстрее (в моем случае версия control plane стартовала за 30 секунд). Понятно, что это потребовало определенных танцев с бубнами, описание которых сильно выходит за тематику данной статьи (но, возможно, опишу в следующей).
Благодаря контейнерам, требования по памяти и ядрам становились не такими пугающими. Однако, нельзя забывать про конкретные ограничения используемой аппаратной платформы. В моем случае это были:
Количество vCPU (80) и RAM(256GB), 2 узла NUMA
Использованная плата SuperMicro X10DRL-i заточена под Windows 10 – так что ESXi даже не пытался пробовать
ОС Windows 10 Pro (есть любители играть в SimCity), поэтому можно использовать либо Hyper-V (на самом деле, нет), либо Vmware Workstation. А значит, больше чем 32 vCPU и 128 GB на виртуалку выделять бесполезно (упремся как в ограничения формата виртуалок, так и ресурсы на каждом узле NUMA). Как и «ставить на железо» - любители игр просто не поймут.
И тут пришла мысль распределить сетевые устройства между несколькими одновременно запущенными виртуалками. Такой подход является естественным для GNS3 (концепция «внешних серверов») и весьма искусственным для EVE-NG/PNETLAB (там тоже можно что-то подобное сделать, но связь между виртуалками должна делаться через множество «облачков»). Архитектура GNS3 приведена на рисунке ниже, сам рисунок взят из он-лайн документации.
Собственно, после осознания этого, все усилия были сосредоточены исключительно на работе с веткой GNS3, а EVE-NG/PNETLAB удалены для экономии ресурсов.
Здесь «COMPUTE NODE» - это виртуалка в среде VmWare Workstation (Linux-машина, на которой есть Docker, QEMU и все остальное), а «CONTROLLER» + «GNS3 GUI» + «GNS3 WEB» - то, что входит в состав «локального сервера» GNS3. В моем случае «COMPUTE NODE» запускались на стационарнике, а «локальный сервер» на ноутбуке, связь через домашний WiFi-router.
Капелька дегтя
При этом нельзя сказать, что GNS3 идеален – в использованной версии 2.2.46 как минимум:
Несколько раз топология просто не открывалась, встроенный сетевой хаб приходилось ручками удалять в текстовом файле топологии и потом снова добавлять через GUI (но это далеко не при каждом запуске, да и лечилось недолго).
Не запускался виртуальный коммутатор ioll2-xe-17-12-01 (но для SP он и не был нужен).
При запуске XRv9K возникало сообщение об ошибке, связанной с портом Calvados AUX (правда, по факту он не использовался, так что подготовке не мешало).
При работе с контейнерами Docker сперва были определенные сложности по сохранению конфигураций и данных приложений (в конце концов, удалось найти вполне рабочий рецепт). Думаю, что это скорее было связано с работой собственно Docker на виртуалке.
Если нужно изменить максимальное число сетевых интерфейсов на уже подключенном в схему узле – придется сперва удалить все его подключения, затем изменить число сетевых интерфейсов и после этого снова выполнить подключения к соседним узлам.
Тем не менее, указанные ограничения и недостатки с лихвой были перекрыты основным достоинством GNS3 – возможностью «горизонтального масштабирования».
Как настроить «горизонтальное масштабирование»
И так, что же нужно сделать для «горизонтального масштабирования»?
1. Спланировать конечный результат – с учетом требуемых ресурсов и количества сетевых узлов, а также возможного влияния одних типов узлов на другие, в результате чего определиться с числом виртуальных машин GNS3 и выделяемых им ресурсов. В моем случае виртуальных машин должно было быть не менее 2 (по числу узлов NUMA), по факту я сделал 3. Не уверен, что это было самым оптимальным решением – но это позволило более полно использовать ресурсы домашнего стационарника, а также взаимно изолировать ресурсы узлов IOS-XRv9K и CSR1000v.
2. Стандартным образом, скачать, настроить и запустить виртуальные машины GNS3. При этом, виртуальные машины должны отличаться хотя бы IP адресами (которые лучше задавать статически, а не полагаться на DHCP). Настройка адресов выполняется через меню Network с редактированием файла конфигурации и последующей перезагрузкой ВМ.
Если нужно изменить номер порта, это можно сделать через меню Configure и редактирование другого файла конфигурации (см. иллюстрации ниже).
3. Добавить получившиеся виртуалки в качестве внешних серверов в меню клиентского приложения GNS3: Edit->Preferences->Server->Remote Servers->Add.
В появившемся окне нужно настроить как минимум сетевой адрес и условное имя сервера (на него будет ссылаться GNS3 при инсталляции образа узла). Название моих виртуальных машин приведено на рисунке, каких-то потаенных смыслов за ними не скрывается. Если будете настраивать аутентификацию – понадобится симметричная настройка на виртуальной машине (я обошелся без аутентификации, так как работал только в домашней сети).
В конечном итоге, на вкладке Servers Summary основного экрана должны появиться все настроенные серверы. Также показывается загрузка выделенных ресурсов (CPU и RAM) на каждом сервере/ВМ. На всех ВМ суммарно использовалось 64 vCPU и около 200 GB RAM (остальное отставил в распоряжение ОС). Верхняя строчка – это «локальный сервер».
4. Добавить образы используемых сетевых устройств. Здесь необходимо явно указать, на какой ВМ будут исполняться экземпляры этого образа. Если предполагается распределить нагрузку между несколькими ВМ, образ придется добавлять несколько раз – по числу ВМ, на которых планируется исполнять экземпляры этого образа.
5. Создать сетевую топологию. При этом GNS3 сам позаботится об обеспечении связности между узлами на разных ВМ, никакие дополнительные объекты (типа «облачков») не понадобятся.
Заключение
В данной статье я попытался описать не очень распиаренную возможность «горизонтального масштабирования» в GNS3, которая в определенных сценариях может оказаться очень полезной и перевесить его недостатки (или позволить смириться с ними на некоторое время – по факту, не так много сценариев требуют одновременного запуска 40-60 достаточно требовательных по ресурсам узлов).