Тестирование производительности VMXNet3. Часть 2: RouterOS Cloud Hosted Router

Всем привет, это снова я – krokokot. В первой статье я тестировал производительность «сферического коня в вакууме», т.е. насколько быстро две виртуальные машины с ОС Windows 2012R2 могут обмениваться данными посредством паравиртуальных сетевых адаптеров VMXNET3 через виртуальный коммутатор гипервизора VMWare ESXi 6.5 u1. Поставленный с помощью «молотка и такой-то матери» рекорд составил 29 гигабит в секунду при MTU=9000.

Сегодня мы протестируем аналогичного «коня», но на примере Linux-based операционной системы. Поскольку сборок Linux великое множество, чтобы никого не обидеть (а еще – потому что я не очень хорошо разбираюсь в этом вашем Линуксе 🙂 я выбрал в качестве подопытной RouterOS Cloud Hosted Router от Microtik. Это специальная версия RouterOS для виртуальных сред. Поддерживается ESXi, Hyper-V и еще что-то там, список тут – https://wiki.mikrotik.com/wiki/Manual:CHR. Для нашего теста главное – в CHR есть встроенный драйвер VMXNET3.

Я применяю RouterOS CHR в качестве виртуального маршрутизатора на standalone хостах с ESXi, когда нужно просто выставить ВМ из них в интернет. Также можно быстро поднять IP-IP или Ethernet-Over-IP туннели до отдельных ВМ или их групп, поднять VPN сервер, опубликовать порты и многое другое, что умеет RouterOS. В общем, мне очень нравится этот роутер, и сегодня попробуем с его помощью побить мой предыдущий рекорд – 29 гиг/сек.

Для корректности сравнения используем тот же самый хост. Напомню его характеристики: материнская плата ASUS X99-E, процессор Intel Xeon E5-2620 v4 2.1 ГГц, заведомо достаточное количество RAM DDR4 2133. Версия гипервизора ESXi 6.5.0 Update 1 (Build 5969303).

Создаем две ВМ с характеристиками: 2 vCPU, 1024 Mb RAM (All locked), по 2 паравиртуальных сетевых адаптера VMXNET3. Диск приделываем к контроллеру IDE – это требование к загрузочному диску RouterOS CHR. Остальные диски могут быть на паравиртуальном SCSI. Первый адаптер с каждой ВМ включаем в дефолтный виртуальный коммутатор с подключенной к нему сетевой картой Intel I218-V с MTU 1500. Вторые адаптеры – в вновь созданный и никуда не подключенный виртуальный коммутатор с MTU 9000:Установка системы состоит в скачивании с сайта https://mikrotik.com/download из раздела Cloud Hosted Router vmdk–файла свежей версии CHR (на дату написания статьи это 6.40.4) и присовыванию этого файла в качестве диска в ВМ при её создании.

После запуска ВМ входим через консоль под admin без пароля. Далее можно настроить роутер из командной строки, либо настроить только IP-адрес на одном интерфейсе. Далее подключиться к нему с помощью специальной программы winbox, из которой уже настраивать все остальное. Производитель раздает бесплатный триал на 2 месяца, достаточно зарегистрироваться на сайте. При активации триала нужно указать уровень лицензирования, ограничивающий максимальную скорость на интерфейсах. Нас интересует, конечно же, unlimited. В сети куча информации по лицензированию CHR и мануалов по настройке, так что повторяться не будем.

Приступаем! В RouterOS встроен замечательный инструмент по тестированию пропускной способности – Bandwidth test. Это модуль, который цепляется по IP-адресу из одной RouterOS к другой, авторизуется там и начинает гонять данные в указанном направлении до тех пор, пока ему не скажут Stop. И в модуле, и в окнах свойств интерфейсов есть счетчики, которые в реальном времени показывают скорость передачи по интерфейсу. С помощью всего этого мы и будем тестировать пропускную способность между двумя ВМ сначала через виртуальный коммутатор с MTU 1500, а затем через второй виртуальный коммутатор с MTU 9000. И сегодня, в отличие от прошлого раза, никакой академичности. Что мне покажет winbox – то я и заскриню в статью.

Первый тест – tcp в 2 потока между интерфейсами ether1 каждой ВМ. По умолчанию выставлено 20, но мы поставим 2 и посмотрим, что получится. CHR01 слева, CHR02 справа.

Замечаем нечто странное… Меняем в тесте send на receive и запускаем еще раз:

Понимаем, что весьма странно то, что отправляющая и приемная сторона показывают пусть немного, но разные скорости. А еще – количество пакетов в секунду на стороне передачи много меньше, чем количество на стороне приема. Для проверки смотрим одновременно в esxtop – n:

Что-ж, сдаваться санитарам еще рано: две совершенно разные софтины показывают одно и то же: CHR02 отправляет ~34k пакета в секунду (packet per second, PPS) со скоростью 17229 Мб/сек, а CHR01 принимает ~1500k PPS на скорости 17996 Мб/сек. И средний размер пакета (PSZTX), отправляемого CHR02 ~ 64 килобайта. А принимаемого (PSZRX) CHR01 ~ 1500, как и сказано в MTU виртуального коммутатора vSwitch0. Как-то так… Только почему CHR отправляет пакеты размером в 64 килобайта, хотя на интерфейсе четко сказано:

MTU 1500 – непонятно. Но оно работает. И это хорошо.

Пробуем тест по udp:

Разворачиваем:

Никаких фокусов, 16 гигабит в секунду и 1350k PPS с обоих сторон. Esxtop подтверждает:

Средний размер пакета ~ 1500 и на приеме и на передаче, как и указано в тесте.
Теперь попробуем погонять трафик между интерфейсами Ether2 через виртуальный коммутатор с MTU 9000. На каждом интерфейсе обеих CHR также прописан MTU 9000, хотя, судя по тому, что мы видели только что, это еще ничего не гарантирует. 🙂

В интерфейсе winbox везде где есть графики загруженности – есть удобная измерительная линеечка – показываю её на этом скриншоте в правом нижнем углу. Разворачиваем тест:

Я увидел небольшие провалы на тесте, остановил и увеличил количество потоков до 10. Получилось 28 гигабит в секунду, что близко к полученному нами в прошлом тестировании ВМ с Windows. Esxtop подтвержадет:

Вновь видим тот же фокус с пакетами под 64к. Но получатель на этот раз получает пакет с MTU 9000, так что по крайней мере виртуальный коммутатор ESXi работает как ожидалось. 🙂

Пробуем udp:

Разворачиваем:

Esxtop:

Дамы и господа, поздравляю вас с подтвержденным результатом в 42 гигабита в секунду! :))

Пробуем увеличить количество vCPU. Ставим по 4 в обе ВМ.

Как видим – небольшое падение. Было 28.3, стало 27.6. Думаю, что это следствие того же феномена, который мы исследовали в предыдущей статье: количество vCPU активных ВМ сравнялось с количеством физических ядер процессора и шедулер хоста не знает, куда девать поток, обрабатывающий виртуальный коммутатор. Проверяем. Ставим обеим ВМ Sheduler affinity на физические ядра. Наша задача – не выделить виртуальным машинам больше ресурса, а заставить шедулер вынести обработку виртуального коммутатора не на ядра, занятые ВМ. Поэтому Reservation CPU или Latency Sensitivity – High нас не спасут.



На короткое время, когда шедулер работает так как нам хотелось, мы получаем 30 с копейками гигабит. В остальное – увы – те же 27.6 Гб/с. Пробуем предпоследний фокус – уменьшаем количество vCPU, но оставляем Affinity: 0,2 для CHR01 и 8,10 для CHR02. Запускаем тест – неуспех. Даже скриншот приводить не буду – он такой же, кратковременные подъемы до 30 гиг. Убираем Affinity и просто «на посмотреть» включаем Latency Sensitivity – High. Оно включилось:

4 ядра полностью отданы двум ВМ. Но вот результат… :

Как видим, для нашей CHR отключение «Interrupt coalescing and LRO», которое произошло при включении «Latency Sensitivity – High» дало обратный эффект: vCPU хоть и безраздельно используют физические ядра процессора, однако нагрузились прерываниями от каждого полученного сетевого пакета, и общая пропускная способность снизилась почти вдвое.

Вместо заключения: VMXNEТ3 – действительно жутко быстро и запредельно рядом. Две пары виртуалок под разными ОС показали близкие скорости передачи по tcp: 29 гигабит в секунду. Думаю, что на процессоре с большей частотой этот показатель еще увеличится. CHR по udp показала 40 с лишним гигабит, однако сравнивать не с чем, так как тестирование udp iperf’ом под Windows – та еще песня, и петь её мне совсем не хочется. Заодно мы узнали, что CHR 6.40.4 при тестировании пропускной способности умеет посылать, а виртуальный коммутатор ESXi 6.5 u1 – принимать пакеты размером аж до 64 килобайт, и корректно их обрабатывать.