Низкая скорость загрузки для виртуальных машин 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 2 мс, загрузка 134 Мбит / с, загрузка 0,25 Мбит / с (кстати, 0,25 Мбит / с - приемлемая скорость для подключений к удаленному рабочему столу, но на практике RDP почти не работает, клиент часто зависает на несколько секунд или обновление происходит квадратами, обновление экрана занимает 5-10 секунд, работает нестабильно или иногда даже повторно подключается, что делает работу через RDP практически невозможной).
Твики на затронутых машинах Windows, такие как «netsh interface tcp set global autotuninglevel = highrestricted» didn ' Ничего не менять.
Виртуальные машины, которые имеют прямое соединение в обход 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, обновил прошивку до последних версий, и это не помогло.
Я решил проблему, отключив «Аппаратную разгрузку при большом приеме» в настройках pfSense (Система / Дополнительно / Сеть | Сетевые интерфейсы)
Есть флажок «Отключить разгрузку аппаратного большого приема», и я установил его на «Проверено» (ВКЛ).
В описании этой опции сказано следующее:
Установка этой опции отключит аппаратный большой прием разгрузка (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. Когда этот (более крупный) пакет необходимо фрагментировать для соответствия другому сетевому адаптеру, ядро FreeBSD видит флаг DF, отбрасывает пакет и затем отправляет обратно ICMP-сообщение «недоступен - необходимо фрагментировать» отправителю. Причина, по которой он вообще работает, связана с другим трафиком, который запрещает выполнение LRO, и некоторые пакеты пересылаются. В одном из тестов я включил LRO и использовал scp для размещения файла на устройстве pfSense, что привело к хорошей производительности (без такого же падения производительности). Мне было бы интересно, если вы 1) увидите хорошую производительность с включенным LRO и scp большого файла на устройство и 2) увидите ICMP «нужно фрагментировать» с включенным LRO и scp на машину на удаленной стороне. Поскольку устройство pfSense используется в качестве шлюза, вы должны оставить LRO выключенным.
Я иногда экспериментировал с этой проблемой, и самое быстрое решение: перезагрузите машину. Управление памятью Windows не самое лучшее, и иногда им требуется перезагрузка.
Если перезагрузка не работает, определите проблему. Серверы или клиент? Серверы находятся в режиме TS или TS только для администрирования? Вы подключаетесь к консоли или к стандартному удаленному сеансу?
Подумайте также, если все они «новые» машины (сервверы, поддерживаемые), они могут получить все те же обновления. Возможно, вам понадобится обновление клиента, чтобы работать с изменениями службы терминального сервера.
В качестве прямого ответа я администрирую группу из 15 серверов более 6 лет. От Windows 2000 до Windows 2012 R2. Иногда у меня возникают эти проблемы, но в 90% случаев они решаются перезагрузкой. Еще 10%, с обновлением клиента.
Моя рекомендация по этому поводу, используйте службу WSUS и управляйте утверждением всех обновлений, установленных на серверах.
P.s. Если вы не можете решить проблему, вы можете использовать утилиту «Восстановление системы», чтобы восстановить состояние машины за неделю до установки обновлений. Удаление не перенастраивает, но восстановление системы возвращает всю систему в предыдущее состояние (удаление приложения, отмена изменений конфигурации, а также удаление ваших документов или других вещей на машине).
Я хочу подтвердить абсолютно тот же сценарий. Запуск pfSense на VMware, где пропускная способность загрузки будет мучительно медленной, а загрузка будет в порядке. Для нас это было ТОЛЬКО в том случае, если виртуальная машина pfSense и гостевые виртуальные машины находились на одном хосте. Когда виртуальная машина pfSense и виртуальная машина хоста находились на другом хосте, проблема исчезала. При отключении разгрузки на виртуальных машинах pfsense (установите флажки ON) это мгновенно устранило проблемы. Я не уверен, что это только сетевые карты VMXNET 3, но так же настроены виртуальные машины pfSense. Я надеюсь, что это поможет другим, так как это нигде не задокументировано. Я попытаюсь заставить pfSense обновить страницу конфигурации VMware на их сайте.