Пятая и заключительная часть касательно «железа» в vSphere будет полностью про сеть.
Как и в большинстве случаев, все начинается с общих рекомендаций:
- Повышенная утилизация CPU хостов может влиять на производительность сетевой подсистемы. Чем большая производительности сети – тем больше процессорных ресурсов требуется. Недостаточное количество процессорных ресурсов снижают пропускную способность сети. В связи с этим рекомендуется наблюдать за загрузкой CPU на хостах;
- Если сетевое устройство используется несколькими потребителями, будь то виртуальная машина, либо VMKernel, наиболее активные из них могут оказывать влияние на всех остальных. В связи с этим рекомендуется выделять отдельные сетевые адаптеры для особо «интенсивных» потребителей. Добавлю от себя, что стоит подумать на тему того, чтобы вынести трафик iSCSI (если используется), на отдельные сетевые интерфейсы. Также можно использовать NIOC для деления сетевого трафика на классы и резервирования пропускной способности для классов;
- Для установки сетевого соединения двух виртуальных машин в рамках одного хоста, необходимо подключить обе машины к одному виртуальному свитчу. При подключении машин к разным виртуальным свитчам, сетевой трафик будет покидать гипервизор, создавая при этом дополнительную грузку на CPU.
Network I/O Control (NetIOC)
NetIOC позволяет «поделить» доступную пропускную способность сети на пулы. В NetIOC имеется 9 пулов, создаваемых по умолчанию (MGMT, FT, iSCSI, NFS, vSAM, vMotion, Replication, Backup и трафик виртуальных машин), а также имеется возможность создать свои пулы сетевых ресурсов.
Начиная с версии vSphere 6, NIOC версии 3 управляет пропускной способностью на уровне распределенного свитча (dvSwtich), в то время как NIOC v2 работал на уровне физического адаптера.
При создании распределенного свитча (Distibuted Switch) версия 3 используется по умолчанию. При апгрейде версии dvSwitch, NIOC не всегда может быть обновлен с версии 2 до версии 3.
В целом же NetIOC позволяет гарантировать пропускную способность для пулов ресурсов и исключить влияние систем, работающих в пуле на другие пулы.
Начиная с версии vSphere 6.0 DRS учитывает настройки NIOC при подсчете возможностей для миграции виртуальных машин.
При использовании NetIOC пропускная способность сетевых пулов ресурсов может быть поделена с помощью shares, reservations и limits:
- Shares могут быть использованы для выделения сетевому адаптеру, либо пулу, части сетевых ресурсов, по аналогии с Shares для CPU. Чем больше значение Shares – тем больше ресурсов будет выделено в случае их нехватки;
- Bandwidth reservation – гарантия минимальной пропускной способности в Mb/s для пула ресурсов, либо сетевого адаптера VM. Максимально допускается зарезервировать не более 75% от пропускной способности сетевого адаптера. Если пул, либо машина не используют все зарезервированные для них ресурсы, данные ресурсы могут быть использованы остальными потребителями;
- Limits – используются для ограничения максимальной пропускной способности пула, либо vNIC. Лимиты применяются всегда, даже когда нагрузки на сетевые интерфейсы нет и имеется доступная пропускная способность.
DirectPath I/O
vSphere DirectPath I/O позволяет гостевой операционной системе получать доступ к физическому сетевому адаптеру напрямую без использования эмулированных адаптеров E1000, либо, паравиртуальных адаптеров VMXNET. Это позволяет получить большую пропускную способности сети в виртуальной машине при меньших затратах процессорных ресурсов.
Однако, это было бы так прекрасно, если бы не существующие ограничения. DirectPath I/O не совместим с vMotion, снапшотами, операциями suspend/resume, FT, NIOC, и т.п.
В большинстве случаев виртуальные машины не нуждаются в использовании данной функции, однако, для некоторых, крайне активно использующих сеть, DirectPath I/O может быть полезен с учетом ограничений на использование функций виртуализации.
Single Root I/O Virtualization (SR-IOV)
SR-IOV работает по тому же принципу, что и DirectPath I/O. Данная функция предназначена для систем с высокой сетевой нагрузкой, имеет те же ограничения, однако позволяет использовать одно физическое устройство несколькими гостевыми системами одновременно.
SplitRx Mode
Использование SplitRX позволяет задействовать большее количество ядер ЦПУ для обработки сетевого трафика в очереди. Использование данной функции позволяет улучшить сетевую производительность в некоторых случаях:
- Большое количество виртуальных машин на хосте ESXi, каждая из которых получает multicast трафик от одного и того же источника;
- При использовании DVFilter, между двумя машинами в рамках одного ESXi хоста.
Начиная с ESXi 5.1 и выше, данная функция включается по умолчанию для сетевого адаптера VMXNET3 (единственный тип сетевого адаптера, который это поддерживает), в случае, если физический интерфейс сильно утилизирован и получает больше 10000 broadcast/multicast пакетов в секунду.
SplitRX включается автоматически только когда сетевой трафик проходит через физический сетевой интерфейс, не в случаях, когда сетевой трафик проходит внутри ESXi. В случае с сетевым трафиком внутри хоста, SplitRX необходимо включить вручную.
Для включения и отключения SplitRX на уровне хоста необходимо использовать параметр NetSplitRXMode. 0 – функция отключена, 1 – включена.
Включить SplitRX можно так же индивидуально для сетевых адаптеров виртуальной машины. Делается это в файле vmx виртуальной машины параметром ethernetX.emuRxMode.
Receive Side Scaling (RSS)
RSS позволяет выполнять обработку сетевого трафика на нескольких CPU за счет создания множества очередей. Эта функция может помочь увеличить пропускную способность сетевой карты, однако так же может увеличить накладные процессорные расходы.
ESXi позволяет использовать RSS сетевыми адаптерами виртуальных машин, в большинстве случаев тех, которые работают с большим объемом сетевого трафика.
Ввиду возможного увеличения накладных расходов в части потребления процессорных ресурсов, данная функция по умолчанию отключена.
Virtual Network Interrupt Coalescing
Данная функция позволяет уменьшить количество прерываний, что потенциально может снизить утилизацию процессора хоста. С другой стороны, включение Interrupt Coalescing может увеличить сетевые задержки с микросекунд до миллисекунд, однако для большинства систем это мало ощутимо.
По умолчанию данная возможность включена для всех сетевых интерфейсов виртуальных машин на ESXi, однако, при необходимости может быть отключена.
Включение\отключение\настройка производится в файле vmx виртуальной машины параметром ethernetX.coalescingScheme.
Running Network Latency Sensitive Workloads
Изначально ESXi сконфигурирован с целью получения большой пропускной способности с минимальными затратами ЦПУ. И, хотя, эта конфигурация обеспечивает в большинстве случаев лучшее масштабирование и позволяет запускать большее количество машин в рамках хоста, это может сказаться на повышенных сетевых задержках.
vSphere предоставляет различные возможности для конфигурации систем, которые крайне требовательны к сетевым задержкам. Об этом ниже:
- Стоит определить чувствительные к задержкам виртуальные машины и использовать параметр Latency Sensitivity (в свойствах виртуальной машины) в значении High. В этом случае планировщик гипервизора будет пытаться выделять для каждого vCPU виртуальной машины свое физическое ядро. Это так же означает, что на данном ядре не смогут исполняться другие виртуальные машины, а также, например, vmkernel. Если ему это удается, сетевые задержки значительно снижаются. Включение данной функции требует 100% резерв оперативной памяти для VM, а также (в зависимости от VMHardware) 100% резерв CPU;
- Даже если параметр Latency Sensitivity не включен для виртуальной машины, резерв CPU и оперативной памяти может помочь в снижении сетевых задержек;
- Использовать SR-IOV, DirectPath I/O, для придется пожертвовать основными функциями виртуализации, как уже было сказано ранее;
- Перевести Power Management в режим Maximum Performance, либо отключить его в BIOS. Отключить C1E и C-States в BIOS. Включить Turbo Boost.
Host-Wide Performance Tuning
Начиная с версии 6.0 в vSphere появилась функция Host-Wide Performance Tuning, она же Dense Mode, позволяющая оптимизировать хосты ESXi для размещения на них большого количества виртуальных машин.
При использовании Dense Mode, ESXi следит за количеством виртуальных машин, количеством vCPU и общей утилизацией процессора и в случае, если эти значения выше пороговых (количество VM больше количества физических ядер, количество виртуальных процессоров больше физических ядер в два раза и утилизация процессора выше 50%), хост начинает применять ряд оптимизаций в работе.
Поскольку данный режим работы может сказаться на обработке сетевого трафика и в некоторых случаях увеличить сетевые задержки, рекомендуется включать его только на тех хостах, где это действительно необходимо.
Стоит понимать. Что даже если этот режим переведен в «Enabled», активироваться он будет только при достижении пороговых значений, о которых было написано выше.
На этом мы заканчиваем серию постов про ресурсы гипервизора, а следующая тема будет посвящена оптимизации работы виртуальных машин.
Все статьи по данному циклу:
Часть 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.
