Дано: Новенький кластер HPE. Физические хосты с сетевыми картами 25 Гбит/с. Виртуальные машины с адаптерами VMXNET3, подключенные через Distributed Switch (vDS).
Проблема: При проверке скорости между ВМ утилита iperf3 показывает унылые 900 Мбит/с(??).
Задача: Понять, куда делись остальные 24 гигабита, и почему скорость ниже, чем на домашнем роутере.
Задача выглядела нетривиально, так как на соседнем кластере (Cisco HX) всё летало «из коробки». В следствии проверок мы прошли все стадии принятия и не малое количество процедур от проверки драйверов до глобальной перестройки сети, и вот как это было.
Этап 1: Проверка базовой гигиены на уровне железяк (ОС и Драйверы).
Первым делом исключил классику: старые драйверы и однопоточность
Проверка адаптера: На ВМ установлен корректный VMXNET3, VMware Tools свежие..
Многопоточный тест: Запустили iperf в 8 потоков, чтобы исключить упор в одно ядро CPU.
iperf3.exe -c 10.10.10.111 -P 8
Результат:
– Sender: ~2.5 Гбит/с
– Receiver: ~80 Мбит/с (!!!)
Катастрофическая разница. Приемник буквально “захлебывался” пакетами. Появилось подозрение на RSS (Receive Side Scaling) — технологию, которая паралелит обработку трафика по ядрам проца.
Проверили RSS в PowerShell:
Get-NetAdapterRss
Получил стандартный вывод: RSS включен, очереди распределены по ядрам. Настройки ОС в норме.
Этап 2: Танцы с бубном (RSC и Interrupt Moderation)
В Windows Server (2019/2022) есть функция RSC (Receive Segment Coalescing). На быстрых картах она часто конфликтует с драйверами VMware, вызывая дропы пакетов.
Отключил RSC:
Disable-NetAdapterRsc -Name "Ethernet*" #Тут имя вашего адаптера
Скорость на приеме выровнялась с отправкой, но общий потолок остался на уровне ~2–2.5 Гбит/с. Провалы исчезли, но скорости нет.
Тогда попробовал отключить модерацию прерываний (Interrupt Moderation) в свойствах сетевой карты. Это заставляет CPU обрабатывать каждый пакет мгновенно.
Эффект: Стабильность повысилась, но скорость не выросла.
Этап 3: Момент хуистины (UDP тест)
Чтобы понять, виноват ли протокол TCP (окна, задержки) или сама «труба» (сеть), запустил UDP-тест. UDP — протокол “глупый“
iperf3.exe -c 10.10.10.111 -u -b 5G
Ровная полка в 1 Гбит/с. И это как раз тот момент когда начинаю что то понимать, ведь, если даже UDP упирается в гигабит, значит, где-то стоит жесткое ограничение.
Го искать? Го!:
Network I/O Control (NIOC) на vDS: Лимитов нет (Unlimited), Shares High.Traffic Shaping: Выключен.
Локальный vSwitch: Создал отдельный стандартный свитч, чтобы исключить баги Distributed Switch. Результат тот же.
Этап 4: Нахожу слона в комнате виновника (MTU)
Сравнил проблемный кластер HPE с работающим Cisco HX. Главное отличие: на Cisco используются кастомные карты с мощным Hardware Offload, а на HPE — стандартные адаптеры.
При стандартном размере пакета MTU 1500 байт, чтобы прокачать 10 Гбит/с, процессору нужно обработать около 800 000 пакетов в секунду. В виртуальной среде накладные расходы слишком велики, и сеть просто упиралась в производительность CPU на обработку прерываний.
Проверка гипотезы: Попытался пропинговать соседнюю ВМ большим пакетом с запретом фрагментации:
ping -f -l 8972 10.10.10.111
Ответ: Packet needs to be fragmented.
Сеть физически не пропускала большие пакеты. Тупо уперлись в “софтовый потолок” ~3 Гбит/с для стандартного фрейма.
Решение: Переход на Jumbo Frames (MTU 9000)
Чтобы получить скорость, нужно уменьшить количество пакетов, увеличив их размер. Реализовал план Swing-миграции, чтобы не уронить прод (изменение MTU на vDS “на живую” может положить сеть):
Подготовка: Вывел один физический аплинк из старого vDS.
Физика: Сетевые инженеры перенастроили порт свитча на MTU 9000.
Новый vDS: Создали новый Distributed Switch сразу с MTU 9000 и добавили туда освобожденный аплинк.
ВМ: Переключил тестовые машины в новый vDS и включил Jumbo Packet: 9000 в свойствах адаптера VMXNET3 внутри Windows.
Контрольный выстрел:
ping -f -l 8900 10.10.10.111
Reply from 10.10.10.111: bytes=8900 time=1ms…
Пинг прошел! Путь чист.
Финал: Замер скорости
Запускаю iperf на новой конфигурации:
iperf3.exe -c 10.10.10.111 -w 4M -P 8 -b 10G
Результат:
[SUM] 0.00-10.00 sec 7.64 GBytes 6.56 Gbits/sec sender
[SUM] 0.00-10.00 sec 7.56 GBytes 6.50 Gbits/sec receiver
Итог: Получаем рост производительности более чем в 2.5 раза (с 2.5 до 6.5+ Гбит/с) и абсолютно стабильный поток данных.
Выводы
MTU 1500 — это узкое горлышко для сетей 10/25 Гбит/с в виртуальной среде. Процессор просто не успевает обрабатывать заголовки.
TCP лжет: Если скорость скачет или падает в ноль, проверяйте UDP. Если там «полка» — ищите лимиты в конфигурации.
Swing-миграция — лучший способ внедрять изменения в сети без простоя. Строим новый «мост» рядом, переводим трафик, сносим старый. Но все же не забываем правило: Read-Only Friday.
Добавить комментарий