У нас есть серверы 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», ничего не изменили.
Виртуальные машины, которые имеют прямое соединение в обход 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 на VMware, где пропускная способность загрузки была бы очень медленной, а загрузка была в порядке. Для нас это было ТОЛЬКО, если виртуальная машина pfSense и гостевые виртуальные машины были на тем же хост. Когда виртуальная машина pfSense и виртуальная машина хоста находились на другом хосте, проблема исчезла. При отключении разгрузки на виртуальных машинах pfsense (установите флажки ON) проблемы мгновенно устранены. Я не уверен, что это только сетевые карты VMXNET 3, но именно так настраиваются виртуальные машины pfSense. Я надеюсь, что это поможет другим, поскольку это нигде не задокументировано. Я попытаюсь заставить pfSense обновить страницу конфигурации VMware на их сайте.
Я решил проблему, отключив «Аппаратную разгрузку при большом приеме» в настройках 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. Если вы не можете решить проблему, вы можете использовать утилиту «Восстановление системы», чтобы восстановить состояние машины за неделю до установки обновлений. Удаление не перенастраивает, но восстановление системы возвращает всю систему в прошлое состояние (удаление приложения, отмена изменений конфигурации, а также удаление ваших документов или других вещей на машине).