Highest latency vmware что это

Обновлено: 04.07.2024

Четвертая часть полностью посвящена моментам работы ESXi с дисковой подсистемой и СХД.

VMware vStorage APIs for Array Integration (VAAI)

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

Если SAN, либо NAS массив поддерживает VAAI, ESXi автоматически это определит и начнет использовать предоставленные возможности.

LUN Access Methods

Помимо классической файловой системы VMFS поверх луна, ESXi также поддерживает технологию raw device mapping (RDM), позволяющую подключать лун напрямую в виртуальную машину. Зачастую RDM может использоваться в кластерных системах.

RDM – файл на VMFS, который выступает как прокси для нижележащего блочного устройства (луна).

RDM может работать в двух режимах – virtual compatibility, либо physical compatibility:

  1. Virtual Mode – функции взаимодействия с диском виртуализируются по аналогии с любым диском, располагаемым на VMFS. Данный режим, например, позволяет создавать снапшоты дисков RDM;
  2. Physical mode – минимизирует функции виртуализации и взаимодействия с диском, перекладывая данные функции на виртуальную машину. Снапошты создавать нельзя.

Virtual Disk Modes

Для каждого диска виртуальной машины ESXi поддерживает три режима:

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

Virtual Disk Types

ESXi поддерживает два основных типа дисков – Thick Provisioned и Thin Provisioned.

Thick Provisioned – тип виртуального диска, который сразу резервирует дисковое пространство на хранилище VMFS. Подразделяется на два типа:

  1. Eagerzeroed – при создании виртуального диска, полностью его «зануляет». Увеличивает производительность при первой записи в каждый предварительной зануленный блок, но увеличивает время создания диска (чем больше диск – тем больше время, соответственно). VAAI может ускорить процесс создания таких дисков.
  2. Lazyzeroed – так же резервирует пространство под виртуальный жесткий диск, но зануление блоков происходит только в момент первой записи в них. Диск создается практически моментально, однако, при первой записи будет немного снижена производительность. При последующих записях обладает такой же производительностью, как и eager zeroed диски;
  3. Thinprovisioned – В отличии от Thick provisioned дисков, которые сразу резервируют требуемое пространство на VMFS, пространство под тонкие диски выделяется при записи. Производительность при первой записи в новый блок будет ниже, однако при последующих записях в ранее записанные блоки производительность аналогична eager-zeroed дискам.

Automatic Space Reclamation (UNMAP)

Хранилища VMFS6 (начиная с версии vSphere 6.5) поддерживают автоматическое высвобождение освободившегося пространства для thin provisioned дисков.

Стоит отметить, что VMFS5 так же поддерживает UNMAP, правда только в ручном режиме с помощью esxcli storage vmfs unmap.

Partition Alignment

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

Как и многие другие файловые системы, VMFS может испытывать проблемы с производительностью в случае неправильного выравнивания (misalignment). Начиная с ESXi 5.0 при создании файловой системы через клиента vSphere, VMFS3/5/6 автоматически выравниваются, начиная от границы в 1MB;

Если файловая система VMFS3 создана на более ранней версии гипервизора, чем ESXi5, выравнивание такой FS начинается от границы в 64KB. В случае если файловая система будет обновлена до VMFS5, выравнивание в 64KB так же сохраняется. Единственным решением является пересоздание файловой системы с гипервизора с версией 5 или выше.

Файловые системы VMFS3 и VMFS5 нельзя обновить до VMFS6. Единственный вариант – создание нового datastore на базе VMFS6 и перенос виртуальных машин на него.

Для того, чтобы выровнять VMFS разделы вручную, рекомендуется ознакомиться с документацией производителя СХД, с которой выделяется LUN (в большинстве случаев на выравнивание влияет тип ОС, указанный при создании луна на СХД), ну и, конечно, на рабочей файловой системе такое не делается.

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

SAN Multipathing

Поскольку практически во всех инсталляциях доступ к СХД осуществляется по нескольким путям (через несколько портов HBA и несколько свитчей (в SAN это называется фабрикой)), необходимо использовать специальное ПО, управляющие всеми путями и определяющие использование путей до СХД (Multipathing software). В ESXi за это отвечает PSA – Pluggable Storage Architecture.

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

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

Round Robin – политика, позволяющая в некоторых ситуациях улучшить производительность за счет балансировки нагрузки между активными путями, ведущими к СХД, отправляя фиксированное количество I/O запросов на каждый из путей. Не все массивы поддерживают политику Round Robin. Использование неподдерживаемой политики может привести к проблемам с доступом к предоставленным дисковым ресурсам. Рекомендуется обратиться к документации производителя СХД, чтобы получить список поддерживаемых политика.

ALUA (Asymmetric Logical Unit Access) – использование данной политики позволяет увеличить производительность при работе с СХД, которая, собественно, поддерживает ALUA. ALUA информирует ESXi об оптимальных путях до луна (Active Optimized), а так же дополнительных, не оптимальных путях (Active Non-Optimized). В сочетании с Round Robin, ESXi балансирует запросы к СХД между оптимальными путями.

ESXi так же поддерживает сторонние плагины (PSPs), которые могут предоставить наилучшую производительность для конкретных типов хранилищ (обычно поставляются производителем СХД).

Storage I/O Resource Allocation

VMware предоставляет механизмы для динамического управления дисковым вводом-выводом, позволяя критически важным приложениям сохранять их производительность даже во время нехватки ресурсов.

Дисковый ввод-вывод доступный ESXi можно разграничить с помощью Shares, либо Limits:

  1. Часть ввода вывода виртуальных дисков можно разграничить с помощью Shares. В таком случае, каждый виртуальный диск будет иметь часть пропускной способности к хранилищу, в зависимости от выставленной величины Shares;
  2. Максимальное количество I/O доступных виртуальному диску можно ограничить с помощью Limits. Limits выставляются в количестве IOPS. По умолчанию количество IOPS не ограничивается.

Limits и Shares выставляются на уровне виртуального диска в настройках машины.

iSCSI and NFS Recommendations

  1. Если возможно, стоит использовать выделенные сетевые подключения для iSCSI и NFS между сервером и СХД (еще лучше отдельные коммутаторы). Если выделенной сети нет и не предвидится, стоит отделить дисковый трафик хотя бы с помощью VLAN.;
  2. Рекомендованная скорость подключения 10Gb/s и выше. В случае с NFS агрегация сетевых интерфейсов может предоставить большую пропускную способность;
  3. Если возможно – стоит использовать Jumbo frames (MTU 9000).

NVMe/NVMe-oF Recommendations

  1. Для максимальной производительность рекомендуется включить high-performance plug-in (HPP) на хосте ESXi;
  2. Увеличить максимальное количество I/O с параметром Disk.SchedNumReqOutstanding;
  3. Максимальная пропускная способность NVMe может быть достигнута с запуском большого количества виртуальных дисков, либо виртуальных машин, поскольку в NVMe хорошо развит параллелизм;
  4. Необходимо выбирать корректны storage adapter в виртуальной машине. Это может быть, как PVSCSI, так и vNMVe.

vSphere Virtual Machine Encryption Recommendations

Начиная с версии 6.5 vSphere может шифровать виртуальные диски .vmdk, файлы снапшотов .vmsn, NVRAM .nvram, swap .vswp и конфигурационные файлы .vmx.

Шифрация и дешифрация выполняется центральным процессором и, соответственно, потребляет его ресурсы.

  1. При достаточном количестве процессорных ресурсов, в большинстве случаев потеря производительности крайне незначительная. Однако, в случае нехватки ресурсов ЦПУ, могут начаться проблемы с производительностью;
  2. Для минимизации потребления CPU, рекомендуется выбирать процессоры, которые поддерживают инструкции AES-NI;
  3. Необходимо убедиться, что AES-NI в состоянии Enabled в BIOS. Иногда, для этого необходимо обновить версию BIOS;
  4. Поскольку шифрование выполняется непосредственно хостом и СХД видит только зашифрованные данные, это может сказаться на таких показателях как дедупликация и компрессия.

General ESXi Storage Recommendations

Running Storage Latency Sensitive Workloads

С самого начала подсистема дискового ввода-вывода в ESXi сконфигурирована для получения максимальной пропускной способности с минимальными затратами процессорных ресурсов.

Для приложений, чувствительных к дисковым задержкам следует рассмотреть и сконфигурировать следующие моменты:

  1. Host Power Management может влиять на значения Latency дискового ввода-вывода, ввиду чего рекомендуется возможно переключить политику в режим «Maximum Performance», либо отключить Power Management в BIOS. Отключить C1E и прочие C-states в BIOS. Включить Turbo Boost в BIOS;
  2. Если в виртуальной машине используется контроллер LSILogic, либо PVSCSI, можно отрегулировать параметр reqCallThreshold. Данный параметр влияет на скорость прохождения дисковых запросов виртуальной машины, однако может увеличить потребление ресурсов CPU.

На этом часть, посвященная работе с дисковой подсистемой, подходит к концу. В следующей части посмотри более внимательно на работу сетевой подсистемы.

В данной статье мы рассмотрим настройку Fault tolerance и рассмотрим настройку Latency в виртуальных машинах.

Задачей Fault tolerance является обеспечить доступность виртуальной машины при выходе из строя физического сервера ESXI.

При работе Fault tolerance у виртуальной машины создается копия на другом хосте. Данная копия отрезана от сети, и активируется только когда сервер ESXI выйдет из строя.

Минусом данной технологии являются ограничения накладываемые на ресурсы виртуальной машины, в Vsphere 6 это:

Для корректной работы FT требуется кластер HA, как его настроить можно посмотреть в прошлой статье.

Также для корректной работы FT рекомендуется настроить отдельный VMkernel адаптер, настроенный только на использование Fault tolerance.

Добавим VMkernel адаптер.

Открываем VMkernel адаптеры хоста, и добавляем новый.


Нажимаем Add Host Networking, и выбираем vmkernel.



Указываем Fault tolerance.


Далее вводим статический IP и жмем next. На этом настройка vmkernel закончена, делаем аналогичные настройки на втором ESXI хосте.

Теперь включаем FT на виртуальной машине.


После активации FT и запуска VM, в ее свойствах должно появится следующее


Это означает что VM защищена с помощью Fault tolerance.

Перейдем к настройке Latency Sensitivity.

С помощью данной функции производительность VM приближается к нативной.

Для настройки данной функции, откроем нужную VM, перейдем в раздел Manage, далее откроем settings далее vm options, далее раздел Advanced Settings.

В разделе Advanced Settings выбираем пункт Latency Sensitivity


Далее указываем значения Low, High, Medium или Normal.


Рассмотрим как работает данная технология.

Если мы выбираем режим High, хост ESXI определяет возможность предоставления эксклюзивного доступа Vcpu к физическому процессору, рассчитывая реальную загрузку физического процессора.

Также ESXI будет пытаться зарезервировать ресурсы физического процессора для виртуальной машины с включенным Latency Sensitivity.

Также рекомендуется сделать резервирование оперативной памяти для виртуальной машины с включенным Latency Sensitivity.

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

Таким образом, для VM с повышенной нагрузкой лучше использовать механизм Latency Sensitivity.

В следующей статье мы рассмотрим настройку системы резервного копирования Vshpere Data Protection 6.

В этом посте пойдет речь о настройках VM на борту которых работают экстра-чувствительные к задержкам приложения и службы. Что такое эти чувствительные к задержкам приложения? Это высокопроизводительные (HPC) службы, приложения высокочувствительные к сетевой активности и ее задержкам, голосовая телефония, службы торговли и карточной обработки, которые не могут терпеть задержку выше десятков микросекунд. VMware поддерживает часть из этих приложений, хотя совсем недавно виртуализация накладывала достаточно высокий уровень пенальти по производительности и подобные системы не могли быть виртуализированы ввиду этого. Но теперь благодаря развивающимся технологиям в мире виртуализации этим ограничениям пришел конец и сейчас многие подобные, чувствительные приложения могут быть виртуализированы с поддержкой как их вендора так и vSphere. Что бы обеспечить нашу VM ресурсами с низкой задержкой при доставке, необходимо проследовать в VM → Edit Settings → VM Options → Advanced→Latency Sensitivity и выбрать там High. А теперь следует разобраться что же это все значит и как это работает.

Latency-Sensitivity Feature

  • Виртуализация ввода-вывода. Ввод-вывод проходит путь внутри гипервизора через несколько уровней. Это VMM (Virtual Machine Monitor) и vmkernel (я дро гипервизора), что добавляет некоторую задержку, так же присутствую различные технологии для уменьшения задействования CPU, например, LRO.
  • Виртуализация CPU. pCPU не дается виртуальной машине в полное пользование и строгий CPU шедулер внимательно следит за процессорным временем, отданным каждой VM, исполняемой на нем и очень часто снимает один vCPU с исполнения в пользу другого, из этого вытекают классические проблемы смены контекста, использования кеша и так далее. Особенно заметны накладные расходы при частом входе-выходе виртуального ядра в HALT состояние.
  • Дополнительные факторы. Это и Power Management и ввод-вывод с хранилища, но это уже за пределами влияния ESXi.

Итак, Latency Sensitive функция действует на виртуальную машину и позволяет обойти некоторые ограничения и задержки в виртуальной среде. Что же она делает? Погнали:

  • Эксклюзивный доступ к физическому оборудованию
  • Обход уровней виртуализации
  • Настройка уровней виртуализации

Эксклюзивный доступ к физическому оборудованию. Дает эксклюзивный доступ к pCPU в случае Reservation 100% у vCPU. Что гарантирует персональное физическое ядро, даже процессы Vmkernel хоста не будут иметь доступа к этому ядру. Но для этого необходимо выставить полную резервацию CPU. Так же рекомендуется зарезервировать весь объем виртуальной памяти у VM, чтобы в случае конкуренции за ресурс памяти, различные механизмы рекламации не отбирали память у чувствительной VM, тем самым ухудшая ее производительность.

Обход уровней виртуализации. Когда персональный доступ к физическому ядру предоставлен, больше нет нужды использовать CPU scheduler для предоставления процессорного времени для vCPU виртуальной машины и vCPU исполняется на уровне VMM (virtual machine monitor), что уменьшает задержки и время переключения на исполнение, но все же переключение между VMM и vCPU остается на этом PCPU и небольшие задержки все же есть, но намного меньше.

Настройка уровней виртуализации. Когда используется VMXNET3 адаптер для VM, interrupt coalescing и LRO (Large Receive Offload) автоматически отключаются, чтобы не добавлять задержек в работе сети. Хотя такие настройки могут помочь в производительности, они могут иметь негативный эффект для чувствительных к сетевым задержкам приложений. Если аппаратное обеспечение поддерживает сквозной механизм, такой как виртуализация ввода-вывода с одним корнем (SR-IOV), и виртуальная машина не нуждается в определенных функциях виртуализации, таких как vMotion, NetIOC и HA, мы рекомендуем использовать pass-through механизм для проброса сетевой карты в VM напрямую. Итак, SR-IOV и VM DirectPath I/O сетевого адаптера могут существенно улучшить жизнь нашим чувствительным приложениям.

Latency-Sensitivity побочные эффекты

Хоть и подобные настройки позволяют получить у VM близкое к 0 время RDY%, у этого есть и свои негативные стороны. VM выдается персональный доступ к физическому ядру и никакая другая VM не сможет им пользоваться, даже если оно idle. Машина превращается в «жадного» единоличника и ограничивает какую-либо активность на своем ядре другим потребителям.

Об авторе

Какой то инженер по виртуализации. В данном контексте это не особо важно. Вы же не за этим сюда пришли, верно?

Примерно 2,5 года назад вышел документ по решению проблем с производительностью в VMware vSphere 4.1.

В начале документа находится схема траблшутинга


Соответственно, есть две дальнейшие диаграммы: базовая и продвинутая.


Возможные проблемы упорядочены по принадлежности (с VMware Tools, CPU, etc) и по их влиянию (от 100% влияния на производительность до возможного).

Проверка VMware Tools.

Если VMware Tools не запущены, необходимо разбираться с гостевой операционной системой. Причина может скрываться в обновлении ядра Linux либо отключенной (кем-то) службе VMware Tools в Windows.

Если VMware Tools устарели, необходимо их обновить из контекстного меню vClient. Как правило, это случается после установки обновлений на хосты ESX/ESXi. После этого зачастую требуется обновить и VMware Tools.

Проверка загрузки процессора в пуле ресурсов (Resource Pool CPU Saturation).

Если используете пулы ресурсов и лимит на процессорные ресурсы пула, то читайте дальше. В противном случае сразу идите в следующий блок Host CPU Saturation.

Проверка CPU Ready:

На следующем рисунке проиллюстрирован этот пример


Проверка загрузки процессора хоста (Host CPU Saturation).

Проверка CPU Ready:

Схему анализа данного раздела также можно посмотреть на следующем рисунке:


Загрузка процессора ВМ (Guest CPU Saturation).

Проверка ВМ на активное использование свопа (Active VM Memory Swapping).

Также можно проверить это значение для конкретной ВМ хоста:

Примечание: если хост является частью DRS-кластера, следует оценить также загрузку по памяти остальных хостов.

Проверка ВМ на использование свопа в прошлом (VM Swap Wait).

Нехватка памяти в прошлом может вызвать выгрузку страниц памяти ВМ на диск сервера (Host Swap). ESXi не осуществляет загрузку неиспользуемой ВМ памяти обратно в память хоста, поэтому вы можете сталкиваться с замедлением в работе ВМ, пока такие страницы будут прочитаны с диска.

Примечание: если ВМ находится в пуле ресурсов DRS-кластера, следует оценить также загрузку остальных хостов.

Проверка перегруженности СХД (Overloaded Storage Device).

Проверка на отброс принимаемых пакетов (Dropped Receive Packets).

Проверка на отброс отправляемых пакетов (Dropped Transmit Packets).

Проверка, что во многопроцессорной ВМ используется только один vCPU (one vCPU in an SMP VM).

Если у ВМ несколько виртуальных процессоров (vCPU), возможно, гостевая ОС некорректно настроена и не использует все vCPU.

Проверка CPU Ready у ВМ на средне-нагруженном хосте.

Если на ВМ нагрузка появляется всплесками, то даже с невысокой средней загрузкой ЦП хоста ВМ может испытывать проблемы производительности.

Проверка медленного или перегруженного СХД.

Проверим наличие задержек на СХД:

Проверка задержки очередей:

Измерение задержек физического устройства:

Проверка пиковых нагрузок на СХД.

Проверка наличия пиков в передаче данных на сеть.

Проверка низкой загрузки процессора ВМ.

Если загрузка процессора ВМ низкая, но ВМ тормозит, могут быть некоторые проблемы с конфигурацией.

Проверка того, что память ВМ в прошлом была помещена в своп (Past VM Memory Swapping).

Проверка нехватки памяти в пуле ресурсов.

Проверяем использование ballooning:

Проверка нехватки памяти на хосте.

Нехватка памяти для гостевой ОС (High Guest Memory Demand).


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

Проверка наличия проблем с прерываниями (High Timer-Interrupt Rates).

Проверяем наличие косяков с NUMA.

Проверка большого времени отклика у ВМ со снапшотами.

Рекомендации по решению проблем ждите в следующей статье/переводе.

Спасибо!
Убедился в своей проблеме с производительностью (СХД).

>>Если да, мы имеем дело с перегруженным по вводу/выводу СХД. Идите в набор решений для СХД (ниже в документе).

Добавить комментарий Отменить ответ

Перейти с Порше на Жигули - такое себе решение!

Мысли в слух " а может перейти на proxmox " Что-то в последняя время ESXi не стабильно стал по обновлениям.…

Читайте также: