GetNet

Первый вопрос, который возникает у любой команды: зачем всё это? Для крупного банка ответ складывается из трёх факторов.

Как только дело доходит до замены оборудования, самый первый и логичный шаг — сравнение даташитов. Берётся даташит старого оборудования (Cisco, Juniper, Arista), берётся даташит нового и сравниваются цифры. Но практика показывает: важно не сравнение характеристик, а то, как оборудование ведёт себя под нагрузкой и как оно держит удар.

Чтобы не утонуть в бесконечном потоке тестов, вендоров и производителей, нужна чёткая стратегия. В «Совкомбанк Технологиях» тестирование поставлено на поток: отдел тестирует всё оборудование, которое требуется для дата-центров, — от простых L2-коммутаторов до консольных серверов. Параллельно в других командах идут тесты точек доступа Wi-Fi и контроллеров к ним. Компания сама закрывает все потребности банка.
Наличие методологии превращает результат теста из «нравится / не нравится» в чёткий документ, по которому уже можно что-то оценивать.

Внутри команды обсуждается, какой требуется функционал, производительность, набор протоколов и портов. Отдельно фиксируются эксплуатационные особенности: наличие API, CLI, веб-интерфейса — то, с чем инженеры будут работать каждый день.

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

Реальные требования показываются всем. Даже если чего-то в оборудовании не хватает, важно чётко понимать, что этого функционала нет, и не стесняться это озвучивать: вендоры готовы проводить доработки.
Реальный пример: банку требовался брокер сетевых пакетов, но ни одно решение не поддерживало нужный специфичный протокол. Команда обратилась к вендору с просьбой о доработке, сроки были зафиксированы и выдержаны, брокер попал на тесты и достаточно успешно их прошёл. Спрашивать о том, чего ещё нет, — нормально.

Распространённая уловка: вендор предлагает на тесты один коммутатор или один маршрутизатор. Но для объективного теста нужно собрать архитектурный стенд в миниатюре.

Не стоит соглашаться на тестирование с «идеальными» SFP-модулями от вендора, которые гарантированно совместимы с его оборудованием. Использовать нужно те модули, кабели и патч-корды, которые закупаются постоянно, привычные SSH-клиенты, свои системы мониторинга — всё, что применяется каждый день.
Примеры из тестов:

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

Рано или поздно с любым оборудованием возникнет необходимость обновить ПО. Многие вендоры заявляют обновление с минимальным даунтаймом, особенно для кластерных и стековых решений, но на практике реальные значения иногда оказываются в разы выше.

Не менее важно восстановление после отказов — возврат линков и узлов в фабрику. Пример: одна из VXLAN-фабрик прекрасно отрабатывала потерю линка между лифом и спайном, трафик проходил без проблем. Но при восстановлении линка BFD сначала укладывал работающую сессию и только потом поднимал обе — устройство терялось на десятки секунд.

При тестировании большого бордер-маршрутизатора возник вопрос, чем нагрузить устройство, которое должно держать несколько full view сессий. Просить у оператора отдельный канал ради тестов не потребовалось: содержимое full view можно получить из публичных дампов в интернете, а отдать его в маршрутизатор — с помощью любого виртуального маршрутизатора: FRR, Quagga, RouterOS или любого другого привычного решения.

Однако одних маршрутов недостаточно — важно посмотреть и поведение под трафиком. Здесь помогает бесплатное open source решение Cisco T-Rex. Вместе эти инструменты позволяют под нагрузкой, близкой к реальной, проверить загрузку процессора и памяти, а также конвергенцию — скорость переключения на резервную ноду.

Показательный сценарий: производитель заявляет внушительный размер FIB-таблицы, позволяющий держать full view и отлично с ним работать. Но размер RIB-таблицы указан мелким шрифтом — и с одним full view устройство работает, а принять две копии full view от двух операторов уже не способно.

T-Rex — open source генератор трафика, способный создавать нагрузку от 1 Гбит/с до сотен Гбит/с; всё зависит только от железа, на которое он установлен.

Требования скромные: сервер с Linux, достаточный объём оперативной памяти и процессорных ядер; допускается установка в виртуализации. Главное — DPDK-совместимая сетевая карта. На официальном сайте есть большая таблица поддерживаемых карт, и с картами не из этого списка работа не гарантируется. Выбор достаточно объёмный: от дешёвых гигабитных решений, которые, скорее всего, уже лежат на складе, до карт с пропускной способностью более 100 Гбит/с.

Запуск примитивен: в консоли указывается старт, профиль трафика, порты. Профили есть встроенные в пакет поставки, можно взять готовые из открытых источников (например, на GitHub от сообщества) или написать самостоятельно. Нагрузка задаётся как в пакетах, так и в полосе пропускания.

В одном из тестов на каждый порт создавалась нагрузка более 23 Гбит/с, суммарно 46 Гбит/с, при утилизации всего 9% процессора. Этот трафик приходил и на коммутатор — то есть это не просто цифры в консоли, а реальный iMix-трафик.

Тесты проведены, пределы понятны — но это только половина пути. Как только оборудование будет куплено и установлено в стойку, важно понимать, не останется ли компания с ним один на один в сложной ситуации.

На этом этапе оценивается, как вендор реагирует на выставленные требования, на баг-репорты и результаты тестов (делиться ими с вендором — хороший тон), на вопросы о роадмапе. Знать, как продукт будет развиваться, — нормальное требование. Если вендор не реагирует никак, это тоже результат теста, но скорее негативный.