Performance Best Practices for VMware vSphere 7.0. Часть 6 – Guest Operating Systems

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

В данной части темы будут касаться работы непосредственно виртуальных машин, которые запускаются на гипервизорах ESXi.

Как и в большинстве случаев, все начинается с общих рекомендаций:

Необходимо использовать поддерживаемую ESXi версию операционной системы. Для этого стоит обратиться к матрице совместимости. Для неподдерживаемых ОС может отсутствовать пакет VMware Tools;
Рекомендуется устанавливать последнюю доступную версию VMware Tools в гостевую ОС и выполнять ее обновление после каждого обновления ESXi. Не стоит забывать, что поддержка Balloon Driver появляется только с установкой VMware Tools;
Стоит отключить заставки экрана и прочую анимацию. В Linux системах стоит отключить X-server (графическую оболочку), если она не используется. Все эти компоненты потребляют дополнительные ресурсы CPU и могут сказываться на производительности виртуальных машин;
Планируйте операции резервного копирования, проверок антивируса и т.п. в периоды минимальной нагрузки на систему. Но и во время минимальной нагрузки не стоит запускать все операции разом, если есть возможность растянуть операции по времени – стоит этим воспользоваться;
Всегда стоит синхронизировать время виртуальной машины с серверами NTP, если таковых нет, можно выполнять синхронизацию времени с помощью VMware Tools. Не стоит использовать два метода синхронизации одновременно.

Measuring Performance in Virtual Machines

Если коротко – измерение текущей производительности непосредственно из виртуальной машины не всегда может быть точным, поскольку данный процесс не учитывает ресурсы ESXi. Самый простой пример, когда в гостевой ОС отображается наличие свободной оперативной памяти, а на хосте ESXi она фактически закончилась и во всю уже используется файл подкачки.

Для корректного мониторинга производительности виртуальной машины следует использовать инструменты такие как клиент vSphere, esxtop, resxtop и т.п.

Guest Operating System CPU Considerations

Side-Channel Vulnerability – защита от подобного рода атак защищает гостевые операционные системы, однако может сказаться на производительности виртуальных систем, особенно, в случае ограниченных ресурсов CPU.

Для уменьшения влияния на работу гостевых систем, следует выбирать процессоры, которые позволяют решить проблемы с данными уязвимостями на аппаратном уровне.

Virtual NUMA (vNUMA)

Virtual NUMA позволяет гостевой операционной системе больше понять о нижележащей архитектуре NUMA хоста ESXi и тем самым более грамотно управлять оперативной памятью и расположением в ней данных.

Использование vNUMA позволяет получить прирост в производительности для «больших» машин, особенно для систем и приложений, сильно зависящих от NUMA.

При использовании vNUMA необходимо иметь ввиду следующие моменты:

Топология vNUMA виртуальной машины базируется на низлежащей топологии NUMA хоста и «пробрасывается» в виртуальную машину только при операциях Power Cycle (включение\выключение виртуальной машины. Перезагрузка с помощью ОС не считается за Power Cycle). В связи с этим, в случае миграции виртуальной машины на хост, архитектура NUMA которого отличается, производительность VM может снизиться. Рекомендуется строить кластеры из хостов с одинаковой NUMA архитектурой;
При выставлении параметров CPU/Memory для виртуальной машины, всегда стоит учитывать топологию NUMA хоста, на которой эта машина будет работать. В некоторых процессорах размер NUMA ноды не всегда может быть равен количеству ядер этого процессора. Такие вещи стоит учитывать;
Для наилучшей производительности, виртуальная машина должна оставаться в рамках одной NUMA ноды. Если размер NUMA ноды – 6 ядер, стоит рассмотреть вопрос, чтобы не выдавать машине количество ядер больше чем 6. Если уместиться в рамках одной NUMA ноды не получается, стоит постараться сконфигурировать машину так, чтобы задействовать минимально возможное количество NUMA нод.
Несмотря на то, что Hyper-Threading добавляет «логические ядра», увеличивая их общее суммарное количество, стоит быть внимательным при выделении виртуальной машине большего количества ядер, чем есть физических ядер на хосте. Хотя это и допустимо, в случае нехватки ресурсов, потенциально могут начаться проблемы;
Начиная с версии vSphere 6.5, изменение значения corespersocket виртуальной машиныбольше не оказывает влияния на vNUMA. В настоящее время данное значение влияет на количество отображаемых процессоров в ОС и может влиять на лицензирование ПО, установленного внутри виртуальной машины. В случае, если необходимо «пробросить» желаемую vNUMA топологию, можно воспользоваться параметром numa.vcpu.followcorespersocket;
По умолчанию vNUMA включается для виртуальных машин с количеством vCPU больше чем 8. Для того, чтобы включить поддержку vNUMA с меньшим количеством vCPU, можно использовать параметр numa.vcpu.min = X в конфигурационном файле vmx виртуальной машины;
Включение возможности CPU HotAdd отключает возможность использования vNUMA для виртуальной машины, в связи с чем гостевая операционная система всегда будет видеть одну NUMA ноду, вне зависимости от физической архитектуры. Учитывая вероятное снижение производительности у виртуальной машины, стоит включать функцию HotAdd только для тех машин, где это будет действительно необходимо. Как альтернативу HotAdd, стоит рассмотреть возможность отключения VM на момент увеличения количества vCPU, что позволит сохранить возможность использования vNUMA и снизить потери в производительности.

Guest Operating System Storage Considerations

Storage Adapter, добавленный в виртуальную машину может оказывать влияние на производительность дисковой системы, так же как это может делать драйвер, его настройки и т.п. Следует придерживаться общих рекомендаций:

Для большинства гостевых ОС, дисковым адаптером по умолчанию будет LSI Logic Parallel, либо LSI Logic SAS, в зависимости от выбранной операционной системы и версии оборудования vHardware. ESXi так же позволяет использовать адаптер PVSCSI, который в большинстве случае снижает нагрузку на CPU и потенциально увеличивает пропускную способность. Данный адаптер является наилучшим выбором для машин с высоким дисковым вводом-выводом. Стоит учесть, что не все операционные системы поддерживают загрузку с дисков, подключенных к данному адаптеру;
Начиная с vSphere 6.5 появилась поддержка адаптеров NVMe (vNVME). Поскольку vNMVE рассчитан на работу с flash устройствами и устройствами NVMe, данный тип контроллера не лучший выбор при работе с обычными дисковыми подсистемами;
Значение глубины очереди дисковой подсистемы, или же Queue Depth может значительно влиять на производительность дискового ввода-вывода, например, слишком маленькое значение может крайне ограничивать ввод-вывод виртуальных машин. Следует свериться с документацией производителя на предмет оптимальных значений Queue Depth для их оборудования;
В некоторых случаях большие дисковые запросы на ввод-вывод могут разбиваться драйвером дисковой подсистемы на более мелкие, тем самым увеличивая общее количество операций. Имеет смысл сконфигурировать размер блоков в операционной системе;
В случае, если дисковая подсистема использует диски 4KB native (4Kn), либо 512B emulation (512e), получить наилучшую производительность можно при использовании приложений, которые выравнивают свой ввод-вывод блоками по 4К (изначально использовались блоки размером в 512 байт).

Guest Operating System Networking Considerations

При создании виртуальной машины, ESXi позволяет выбрать один из нескольких типов сетевых адаптеров (vNIC). Выбор зависит от выбранной гостевой операционной системы и версии vHardware.

В случаях, если операционная система не имеет встроенных драйверов для выбранного типа сетевого адаптера, они могут быть установлены в систему вместе с пакетом VMware Tools.

Types of Virtual Network Adapters

Существует три основных типа адаптеров: emulated, paravirtualized и hybrid.

К emulated, либо эмулированным адаптерам относятся:

Vlance – который эмулирует AMD 79C970 PCnet32 NIC. Драйвера для данного устройства присутствуют в большинстве 32 битных ОС;
E1000 – эмулирует Intel 82545EM NIC. Драйвера доступны в большинстве свежих ОС;
E1000e – он же Intel 82574EM NIC. Драйвера для данного типа адаптера менее распространены среди современных ОС.

Следующей категорией идут паравиртуализованные сетевые адаптеры VMXNET, которые в большинстве случав обеспечивают лучшую производительность, чем эмулированные адаптеры из группы выше. Для наилучшей производительности, данные сетевые адаптеры должны быть использованы в каждой гостевой операционной системе, которая их поддерживает.

Таких адаптеров 3:

VMXNET;
VMXNET2 – основан на базе адаптера VMXNET, добавляет ряд улучшений по сравнению со своим предшественником;
VMXNET3 –поддерживает все функции, а так же ряд других улучшений относительно двух адаптеров выше.

Последний тип адаптеров – Flexible. Это сетевой адаптер, который может эмулировать Vlance, а также может функционировать как адаптер VMXNET в зависимости от выбранного драйвера.

Стоит так же понимать, что скорость сетевого интерфейса, который отображается в гостевой ОС не является скоростью интерфейса гипервизора. Так, например, при использовании сетевого адаптера VMXNET3, в операционной системе скорость подключения будет 10GB/s, в то время как сам ESXi подключен к сети линками на скорости 1гигабит.

Selecting Virtual Network Adapters

Для получения наилучшей производительности, всегда стоит использовать адаптер VMXNET3, если он поддерживается операционной системой. Для этого требуется виртуальная машина версии 7 и выше, а также, установка пакета VMware Tools в некоторых случаях (в большинстве случаев это касается ОС семейства Windows).

В системах, в которых адаптер VMXNET3 не поддерживается, рекомендуется использовать адаптер E1000e.

Если же и E1000e не поддерживается системой, использование Flexible адаптера может помочь.

Virtual Network Adapter Features and Configuration

В случае, если две виртуальные машины подключены к одному vSwitch ESXi, передача сетевого трафика между ними происходит в рамках хоста и не задействует сетевые адаптеры, тем самым, не ограничивая их скорость;
Сетевые адаптеры E1000, E1000e, VMXNET2, VMXNET3 поддерживают Jumbo Frames. Для включения данной функции, необходимо выставить значение MTU=9000 в драйвере сетевого интерфейса. Все остальные устройства на пути сетевого трафика, включая vSwitch, должны так же быть сконфигурированы с поддержкой Jumbo Frames;
TCP Segmentation Offload (TSO) включается автоматически и поддерживается сетевыми адаптерами E1000, E1000e, VMXNET2, VMXNET3. TSO может улучшить производительность даже в случаях, если низлежащее устройство его не поддерживает;
По аналогии с TSO, по умолчанию включается так же Large Receive Offload (LRO), но поддерживается данная функция только адаптерами VMXNET2 и VMXNET3. LRO поддерживается большинством Linux систем, однако для систем Windows должен быть соблюден ряд условий – vHardware 11+, VMXNET3, Windows Server 2012+, VMXNET driver 1.6.6.0 и выше, включенная поддержка Receive Segment Coalescing (RSC) в ОС;
В некоторых ситуациях, низкая пропускная способность сети в виртуальной машине может быть связана с недостаточным количеством буферов для приема сетевых пакетов. В случае, если данного буфера недостаточно, сетевые пакеты будут отброшены на уровне VMKernel, а производительность сети будет снижена. Для VMXNET количество буферов на прием и передачу по 100 в каждую сторону с максимально возможным количеством – 128. Для VMXNET2 – 150 и 256, с максимальным количеством буферов для входящего трафика в 512. Отрегулировать данные параметры можно в vmx файле виртуальной машины. Для адаптеров E1000, E1000e и VMXNET3 максимальное количество буферов контролируется драйвером ОС и может максимально составлять 4096;
Множественные очереди приема и передачи (RSS или scalable I/O) позволяют обрабатывать сетевые пакеты на нескольких CPU одновременно. Без данной технологии, весь сетевой трафик обрабатывается только на одном CPU, что, соответственно, медленней и в некоторых случаях может стать узким местом. Сетевые адаптеры E1000e и VMXNET3 поддерживают данную функцию, для большинства операционных систем, начиная от Windows 2003. Начиная с версии ESXi 5.0 и последующих версий VMware Tools, драйвера для VMXNET3 автоматически включают поддержку RSS и множественные очереди. Количество очередей может быть 1,2,4, либо 8, в зависимости от количества vCPU виртуальной машины.

В качестве заключения:

На этом часть про конфигурацию виртуальных машин подходит к концу. На основании предложенных рекомендаций стоит отметить, что конфигурация виртуальной машины – это крайне важный процесс. Следует с понимаем подходить к вопросу выделения ресурсов VM таких как CPU и оперативная память, принимать в расчет конфигурацию NUMA хостов, где будет работать данная машина. Так же следует выбирать правильный дисковый контроллер для виртуальной машины, а также наиболее «современный» из доступных сетевых адаптеров.

Все статьи по данному циклу:

Часть 1 – Hardware for Use with VMware vSphere;

Часть 2 – ESXi General Considerations и CPU;

Часть 3 – ESXi General Considerations и оперативная память;

Часть 4 – ESXi Storage Considerations;

Часть 5 – ESXi Networ Considerations;

Часть 6 – Guest Operating Systems.