Skip to content
Все статьи
СХД и дата-центры

Как мы тестируем VNF: vCPU, SR-IOV и шумный сосед

Alexander Zemskov 4 мин чтения
Как мы тестируем VNF: vCPU, SR-IOV и шумный сосед

В даташите виртуального firewall написано 20 Gbit/s. Цифру сняли на хосте вендора: SR-IOV, закрепленные ядра, сетевая карта, подобранная под тест. Ваша платформенная команда собирает хосты по своему стандарту, часто с virtio и vSwitch, и в типовом проекте тот же образ дает там 6 Gbit/s. Кластер считают по throughput на один vCPU вашего хоста, его мы и меряем.

Стенд

Функция работает на гипервизоре лаборатории, KVM или VMware, или как CNF в нашем кластере Kubernetes. Хост собираем по вашему стандарту платформы: число vCPU и схема привязки, память и huge pages, узел NUMA, модель NIC и число ее очередей. Образ или Helm chart и боевая конфигурация ваши. Если функция живет только в вашем тенанте или кластере, стенд подключается к ней по выделенному каналу.

Нагрузка идет с 2 сторон. Порты L2-3 генератора на 100G шлют кадры на line rate, вплоть до 64 байт, по путям DPDK и SR-IOV. Движки L4-7 на 200G и выше воспроизводят смесь приложений с сессиями и TLS. Счетчики хоста пишутся весь тест: загрузка каждого vCPU, дропы NIC по очередям, память. Сам прогон идет по нашей методике нагрузочного тестирования.

Что проверяем

  • На vCPU: Gbit/s на вашей смеси приложений и pps на 64 байтах для каждого числа vCPU в плане, плюс latency p50 и p99 на заданных нагрузках
  • Путь данных: тот же образ и тот же трафик на virtio, потом на SR-IOV или DPDK, и разница в гигабитах и в ядрах
  • Размещение: закрепленные ядра против плавающих, NIC на своем и на чужом узле NUMA, huge pages включены и выключены
  • Потолок: нагрузка, на которой функция перестает расти, и ресурс, который кончился первым: ядра, очереди NIC или память
  • Масштабирование: 1, 2 и 4 экземпляра на одном хосте, потом на нескольких хостах, против прямой от первого экземпляра
  • Шумный сосед: вторая нагрузка, запущенная намеренно на тех же ядрах, кэше и NIC, и падение throughput функции в %
  • События под трафиком: живая миграция, рестарт, перенос пода, drain узла; для каждого окно потерь от последнего пакета до первого вернувшегося

У каждого пункта есть критерий из вашего дизайна, заданный до первого пакета. Остальные классы, вплоть до облачных сервисов и веб-порталов, собраны на странице облака и NFV.

Что обычно ломается

Путь данных. На virtio каждый пакет стоит хосту CPU в программном коммутаторе. В проекте из первого абзаца поставленный хост дал 6 Gbit/s, 2 vCPU стояли на 100 %. Тот же образ на том же хосте с SR-IOV дал 17 Gbit/s. Кластер, посчитанный по первому прогону, потребовал бы почти в 3 раза больше хостов.

NUMA. Сетевая карта стоит в слоте PCIe процессора 1, планировщик сажает VM на ядра процессора 0, и каждый пакет ходит между сокетами. Throughput падает, latency расползается, а изнутри VM причины не видно. Привязка vCPU к сокету сетевой карты это лечит, и схема привязки входит в каждый отчет.

NIC хоста. Типовой прогон масштабирования: 1 экземпляр дает 6 Gbit/s, 2 дают 11,5, 4 дают 17, а прямая обещала бы 24. Потолок задают NIC хоста и ядра, которые экземпляры делят между собой. Новые экземпляры на этом хосте добавляют vCPU и почти не добавляют гигабит; дизайну нужна вторая карта или второй хост.

Что в отчете

Таблицу результатов на каждый прогон, в шапке профиль хоста: гипервизор и его сборка, модель сервера и CPU, число vCPU и схема привязки, узел NUMA, модель NIC, очереди и путь данных. Без такой шапки цифра в гигабитах в отчете не появляется. Ниже: Gbit/s и pps на vCPU для каждого пути данных, потолок и ресурс за ним, коэффициент масштабирования от 1 до N экземпляров, падение от шумного соседа в %, окно потерь по каждому событию в миллисекундах. К таблице приложены статистика движков, счетчики хоста, захваты трафика и выгрузки конфигураций. Новая сборка гипервизора, драйвер NIC или версия образа означают повторный прогон тех же пунктов и разницу по каждому KPI. Образ может остаться на стенде между релизами как hosted DUT, и для повторного прогона ничего не нужно загружать заново.

С чего начать

Пришлите нам образ, профиль хоста, на котором собираетесь его запускать, и смесь трафика. Мы ответим черновиком тест-плана: пункты проверки, схема стенда и сроки. Отчет остается у вас, его можно показать вендору. Напишите нам или посмотрите, что еще умеет стенд.

Автор

Alexander Zemskov

Эксперт по тестированию сетей и безопасности, продажи (19+ лет) | Performance & Load Testing | IXIA | Spirent | Keysight | Xena | Xinertel и другое

Блог

Читайте также

СХД и дата-центры

Как мы тестируем гиперконвергентные кластеры: отказ узла и p99

Сайзинг HCI отвечает на один вопрос: сколько VM поместится на 4 узла, если один держать в резерве. Считают его на здоровом кластере. Заказчик читает «N+1» и ждет, что отк…

Alexander Zemskov 4 мин чтения
СХД и дата-центры

Как мы тестируем NAS: NFS, SMB, метаданные и отказ контроллера

В даташите NAS одна цифра: последовательное чтение в GB/s, снятое на больших файлах с нескольких клиентов. На ресурсе с домашними каталогами или на сборочной ферме сотни …

Alexander Zemskov 4 мин чтения