Большая потеря пакетов на виртуальной машине ESXI

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз мы с вами устраняли проблему, когда операционная система не обнаруживала библиотеку vcruntime140.dll, которая используется в огромном количестве игр и программ, написанных с помощью библиотек NetFramework. В сегодняшней публикации я вам покажу, как можно устранить и диагностировать потерю пакетов в гостевой ОС на виртуальной машине ESXI 6.5 и выше.

Описание проблемы

От системы мониторинга Zabbix пришло уведомление, что на одном из виртуальных серверов есть потеря сетевых пакетов в размере 33%, а потом 66%, через пол минуты все нормализовывалось. Если посмотреть график, то ситуация выглядела так. Внутри крутится операционная система Windows Server 2019.

Как устранять потерю пакетов у виртуальной машины

Первое с чего следует начать диагностику, это посмотреть текущую загрузку ESXI хоста на котором располагается ваша виртуальная машина. Может быть ситуация, что на хосте все ресурсы утилизируются по максимуму и он вам об этом пишет "Host CPU usage и host memory usage".

Если на уровне хоста все хорошо и другие виртуальные машины работаю корректно и за ними не замечено потери пакетов, то проверяем уже саму виртуальную машину. Я вам советую открыть командную строку и запустить постоянный пинг через утилиту ping -t. Это нужно для того, чтобы сразу смотреть изменения при нашей диагностике.

Перейдем теперь к самой гостевой операционной системе, тут вам нужно проверить две вещи:

• Первая это нагрузка на CPU. Если она под 100%, то вас сетевой интерфейс будет не успевать обрабатывать пакеты, тем более если вы используете устаревший вид интерфейса E1000. Сделать это можно в диспетчере задач. Для этого нажмите одновременно CTRL+SHIFT+ESC. Перейдите на вкладку производительности и выберите пункт "ЦП (CPU)". Убедитесь, что здесь нет всплеском под 100%, если они есть, то перейдите на вкладку "Процессы".

На данной вкладке произведите фильтрацию по загрузке CPU, для этого один раз щелкните по столбцу. В самом верху посмотрите, что за процесс потребляет ваши мощности, если он не нужен, то завершите его, если нужен, то нужно наращивать ресурсов или оптимизировать ПО, которое за него отвечает.

• Далее так же посмотрите нагрузку на вашу дисковую подсистему. Для этого запустите монитор ресурсов из диспетчера процессов.

Перейдите на вкладку "Диск", тут вам нужно посмотреть два параметра:

• Длина очереди, которая не должна быть больше единицы
• Время ответов, которое для ssd не должно быть более 20 и для HDD не более 100.

Если у вас значения выше или существенно выше, то нужно искать проблему низкой производительности дисков или самого датастора на котором лежит виртуальная машина.

Настройка параметров VMXNET3 в Windows

Ранее мы с вами уже имели проблему, когда зависала виртуальная машина, у нее так же пропадала сеть. Там проблема решалась тем, что мы в настройках виртуальной машины имели не совсем правильный тип сетевого интерфейса, я говорю про E1000, который в процессе обмена трафиком еще задействует CPU, и там мы меняли тип на VMXNET3. Поэтому первым делом уточните, что за тип у вас ,если E1000, то меняем его на VMXNET3.

Далее начиная с ESXI 6.5 и выше (может быть и ниже, но проверить уже не могу) есть такая ситуация, когда в какой-то момент происходит всплеск сетевой активности, в результате чего может уже не хватать буфера приема и передачи пакетов.

Чтобы решить эту проблему, постепенно увеличивайте количество буферов в гостевой операционной системе. В гостевой ОС откройте панель управления и найдите в списке оборудования сетевой интерфейс vmxnet3. (Напоминаю, что в диспетчер устройств можно попасть через меню пуск или панель управления). Щелкните по нему правым кликом и выберите свойства.

Переходите на вкладку дополнительно (Advanced) и найдите там параметр "Small Rx Buffers"  и увеличьте значение. Значение по умолчанию - 512, максимальное - 8192.

Так же измените параметр "Rx Ring #1 Size" и увеличьте значение. Значение по умолчанию - 1024, максимальное - 4096.

• Эти изменения будут происходить на лету, поэтому перезагрузка не требуется. Однако любое приложение, чувствительное к прерыванию сеанса TCP, скорее всего, выйдет из строя, и его придется перезапустить. Это относится к RDP, поэтому лучше выполнять эту работу в окне консоли.
• Эта проблема наблюдается в гостевой операционной системе Windows с vNIC VMXNET3. Это может произойти с версиями, от 2008 R2 до 2019.
• Важно постепенно увеличивать значение Small Rx Buffers и Rx Ring #1, чтобы избежать резкого увеличения нагрузки на память на хосте и возможного возникновения проблем с производительностью, если ресурсы близки к емкости.
• Если эта проблема возникает только на 2-3 виртуальных машинах, установите значение Small Rx Buffers и Rx Ring # 1 на максимальное значение. Следите за производительностью виртуальной машины, чтобы узнать, решит ли это проблему.
• В Small Rx Buffers и Rx Ring #1 переменные влияют на не jumbo frame трафик.

Настройка параметров VMXNET3 в Linux

Для драйвера виртуальной сети E1000 и VMXNET3 в гостевой операционной системе Linux Rx-буферы могут быть изменены из гостевой операционной системы точно так же, как и на физической машине. Значение по умолчанию - 256, а максимальное значение, которое можно настроить вручную, - 4096. Определите подходящий параметр, поэкспериментируя с различными размерами буфера. Чтобы определить подходящий параметр, выполните команду:

Где X относится к идентификатору интерфейса Ethernet в гостевой операционной системе, а  значение  относится к новому значению размера Rx. Кроме того, виртуальная машина Linux, на которой включена функция большой разгрузки приема "Large Receive Offload (LRO)" на устройстве VMXNET3, может испытывать отбрасывание пакетов на стороне получателя, когда Rx ring #2 не хватает памяти. Это происходит, когда виртуальная машина обрабатывает пакеты, созданные LRO.

Начиная с версии ESXi 5.1 Update 3, Rx ring #2 можно настроить с помощью параметра rx-jumbo в ethtool. Максимальный размер кольца для этого параметра - 2048.

Где X относится к идентификатору интерфейса Ethernet в гостевой операционной системе, а  значение  относится к новому значению для Rx ring #2.

Как через vsish выяснить наличие потерь пакетов

Ранее я вас рассказывал про утилиту vsish, которую можно за место esxtop. Запускать ее нужно через ssh. Для начала нам нужно знать имя группы портов и идентификатор порта, к которому подключена виртуальная машина. Запустите esxtop  и переключитесь на отображение сети (n), чтобы получить эту информацию. В этом случае мы будем использовать виртуальную машину Windows 10 с идентификатором порта 50331658 в группе портов DvSPortset-0

Теперь выйдите из esxtop (q) и запустите vsish. Использование vsish похоже на навигацию по дереву файловой системы Unix: cd для перехода к другим папкам, ls для вывода списка содержимого и cat для отображения содержимого. Выбираем порты виртуальной машины Windows 10, набрав

Используйте cat status, чтобы показать некоторые подробности конфигурации порта. Эта виртуальная машина использует адаптер E1000 на этом порту. Теперь мы используем cat stats для отображения статистики порта.

Посмотрите какое огромное количество пакетов было отброшено в пункте "droppedRx"

Вот более подробный вывод:

Вот пример команды для адаптеров VMXNET3:

На этом у меня все. Мы с вами разобрали, как можно сократить и убрать потерю пакетов в виртуальных машинах ESXI 6.5 и выше. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.