Низкая скорость загрузки для виртуальных машин VMWare, работающих через pfSense
У нас есть серверы ProLiant DL360 Gen8 и Gen9 под управлением VMWare ESXi 6.0 с виртуальными машинами под различными версиями Windows, которые маршрутизируются через pfSense 2.3.4-RELEASE (64-разрядная версия) с пакетом Open-VM-Tools 10.1.0,1.
Виртуальные машины, работающие через pfSense, демонстрируют очень низкую скорость загрузки, например: ping 2ms, загрузка 134 Мбит / с, загрузка 0,25 Мбит / с (кстати, 0,25 Мбит / с - приемлемая скорость для подключений к удаленному рабочему столу, но на практике RDP едва работает, клиент часто останавливается на несколько секунд или происходит обновление в квадратах, для обновления экрана требуется 5-10 секунд, он нестабилен, а иногда даже переподключается - что делает работу через RDP практически невозможной).
Изменения на компьютерах с Windows, на которые влияют, такие как "netsh interface tcp set global autotuninglevel= сильно ограниченный" ничего не изменили.
Виртуальные машины, которые имеют прямое соединение в обход pfSense, не имеют этих проблем - они имеют примерно одинаковую скорость загрузки и выгрузки.
Все виртуальные машины (pfSense, Windows и т. Д. - все) используют адаптер VMXNET3.
Следующие опции не отмечены в pfSense:
[ ] Disable hardware checksum offload
[ ] Disable hardware TCP segmentation offload
[ ] Disable hardware large receive offload
На pfSense нет формы трафика. В чем может быть причина?
Если я проверяю опцию "Отключить аппаратную разгрузку большого приема", она снова становится быстрой, но я не хочу ее отключать, я хочу, чтобы pfSense использовал аппаратную разгрузку большого приема с VMWare VMXNET3.
Обновление: Я обновил VMWare до последней версии 6.5 со всеми исправлениями и pfSense до 3.4.5 BETA, обновил прошивку до последних версий, и это не помогло.
4 ответа
Я решил проблему, отключив "Аппаратную разгрузку большого приема" в настройках pfSense (Система / Дополнительно / Сеть | Сетевые интерфейсы)
Есть флажок "Отключить аппаратные большие приемные разгрузки", и я установил его на "Проверено" (ON).
В описании сказано следующее об этой опции:
Проверка этой опции отключит аппаратную большую разгрузку приема (LRO). Эта разгрузка нарушена в некоторых драйверах оборудования и может повлиять на производительность некоторых конкретных сетевых адаптеров. Это вступит в силу после перезагрузки компьютера или перенастройки каждого интерфейса.
Другие варианты не проверены. Итак, теперь параметры в "Сетевых интерфейсах" следующие:
[ ] Disable hardware checksum offload
[ ] Disable hardware TCP segmentation offload
[✓] Disable hardware large receive offload
Согласно документации HP, сетевые адаптеры Gen8/Gen9 (модель 331 на основе чипсета Broadcom BCM5719) поддерживают стандартные методы разгрузки TCP/IP, включая: - TCP/IP, разгрузку контрольной суммы UDP (TCO) (перемещает разгрузку контрольной суммы TCP и IP от процессора к сетевому адаптеру). - Большая разгрузка отправки (LSO) или разгрузка сегментации TCP (TSO) (позволяет сегментации TCP обрабатываться адаптером, а не центральным процессором).
Вот что пишет pfSense об этих функциях:
Параметры аппаратной разгрузки сегментации TCP (TSO) и аппаратной разгрузки большого приема (LRO) в разделе "Система"> "Дополнительно" на вкладке "Сеть" по умолчанию установлены на флажок (отключен) по уважительной причине. Почти все оборудование / драйверы имеют проблемы с этими настройками, и они могут привести к проблемам пропускной способности. Убедитесь, что параметры проверены. Иногда отключение через sysctl также необходимо.
На самом деле не было проблем с оборудованием / драйверами, но произошла неправильная конфигурация. LRO и TSO никогда не должны быть включены на маршрутизаторе. Только если pfSense настроен как конечная точка (например, DNS-сервер), эти параметры могут быть включены.
Позвольте мне привести цитату из записи об отслеживании ошибок FreeBSD:
Из моего тестирования это не ошибка, и все работает как задумано. Я вижу значительное снижение производительности, когда LRO включен и использует pfSense в качестве шлюза. Это связано с тем, что исходящие пакеты имеют установленный флаг IP DF (не фрагментировать), который затем объединяется в большие пакеты через LRO. Когда этот (больший) пакет должен быть фрагментирован для соответствия другому NIC, ядро FreeBSD видит флаг DF, отбрасывает пакет и затем отправляет обратно сообщение ICMP "недостижимо - нужно фрагментировать" отправителю. Причина, по которой он работает вообще, связана с другим трафиком, который запрещает LRO, и некоторые пакеты пересылаются. Один из тестов, который я проводил, включал LRO и использовал scp для помещения файла на устройство pfSense, что привело к хорошей производительности (не видя такого же падения производительности). Мне было бы интересно, если вы 1) увидите хорошую производительность при включенном LRO и загрузите большой файл в устройство, и 2) увидите, что ICMP "нужно фрагментировать" при включенном LRO и подключите scp к машине на удаленной стороне. Поскольку устройство pfSense используется в качестве шлюза, вы должны оставить LRO выключенным.
Я хочу полностью подтвердить тот же сценарий. Запуск pfSense на VMware, где пропускная способность загрузки была бы очень медленной, в то время как загрузка была в порядке. Для нас это было ТОЛЬКО, если виртуальная машина pfSense и гостевые виртуальные машины находились на одном хосте. Когда виртуальная машина pfSense и виртуальная машина хоста находились на другом хосте, проблема исчезла. При отключении разгрузки на виртуальных машинах pfsense (установите флажки ON) проблемы мгновенно устранились. Я не уверен, что это только сетевые карты VMXNET 3, но именно так настраиваются виртуальные машины pfSense. Я надеюсь, что это поможет другим, поскольку это нигде не задокументировано. Я попытаюсь заставить pfSense обновить страницу конфигурации VMware на их сайте.
Я иногда экспериментировал с этой проблемой, и быстрое решение: перезагрузить компьютер. Управление памятью в Windows - не самое лучшее, и им иногда требуется перезагрузка.
Если перезагрузка не работает, определите проблему. Это серверы или клиент? Серверы в режиме TS или TS только для администрирования? Вы подключаетесь к консоли или к стандартному удаленному сеансу?
Подумайте также, что если они все "новые" машины (серверы, поддерживаемые), они могут получить все то же обновление. Возможно, вам нужно обновление на клиенте для работы с изменениями службы сервера терминалов.
Как прямой ответ, я администрирую группу из 15 серверов более 6 лет. От Windows 2000 до Windows 2012 R2. У меня иногда возникают эти проблемы, но в 90% случаев они решаются перезагрузкой. Еще 10%, с обновлением клиента.
Моя рекомендация по этому поводу - использовать службу WSUS и управлять утверждением всех обновлений, установленных на серверах.
Ps Если вы не можете решить проблему, вы можете использовать утилиту "восстановление системы" для восстановления машины до недели назад, до того, как были установлены обновления. Деинсталляция не перенастраивает, но восстановление системы возвращает всю систему в прежнее состояние (удаление приложения, отмена изменений конфигурации, а также удаление ваших документов или других вещей на машине).
Я РЕШИЛ! ДА! После недели пребывания на интернет-форуме, в сообществе pfsense и других я попытался снять флажок с дополнительной опции. Раньше я пытался изменить тип VM VM с WMNEXT на E1000 и все остальные, которые я нашел в Интернете, и это у меня не сработало. На моей виртуальной машине pfsense Community Edition v.2.6.0 (также была затронута версия 2.5.2) на ESXi 7.x я ОТКЛЮЧИЛ:
фильтрация пакетов в меню «Система-Дополнительно-Брандмауэр и NAT».
Я надеюсь, что это сработает для всех остальных случаев.
Я отключил всю фильтрацию пакетов, потому что я уже нахожусь за корпоративным межсетевым экраном MPLS, и мне нужен был только Captive Portal через Wi-Fi. Сеть Wi-Fi пока отстает от корпоративного прошивки.