Vmware esxi ошибки

Время на прочтение
7 мин

Количество просмотров 12K

Многие администраторы VMware ESXi сталкивались с такой проблемой, как «фиолетовый экран смерти». Самое неприятное в этой проблеме, что у вас возникает недоверие к своей собственной инфраструктуре. В голове постоянно крутятся мысли о том, что такая же проблема может повториться и на другом сервере.

Что такое PSOD?

PSOD расшифровывается, как Purple Screen of Diagnostics, часто называемый  Purple Screen of Death от более известного  Blue Screen of Death,  встречающегося в Microsoft Windows.

Это диагностический экран, отображаемый VMware ESXi, когда ядро ​​обнаруживает фатальную ошибку, при которой оно либо не может безопасно восстановиться, либо не может продолжать работу.

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

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

Почему появляется PSOD?

PSOD — это сбой в ядре. Все мы знаем, что ESXi не основан на UNIX, но механика сбоя соответствует определению UNIX. Ядро ESXi (vmkernel) запускает эту меру безопасности в ответ на события или ошибки, которые невозможно исправить, это будет означать, что продолжение работы может создать высокий риск для служб и виртуальных машин. Проще говоря: когда хосты ESXi чувствуют, что они повреждены, они совершают «харакири» и, истекая пурпурной кровью, пишут «предсмертную записку» с подробным описанием причин, по которым они это сделали!

Наиболее частые причины PSOD:

1. Аппаратные сбои, в основном связанные с RAM или CPU. Обычно они выдают ошибку «MCE» или «NMI».

«MCE» — исключение проверки компьютера, которое представляет собой механизм в ЦП для обнаружения и сообщения о проблемах с оборудованием. В кодах, отображаемых на фиолетовом экране, есть важные детали для определения основной причины проблемы.

«NMI» — немаскируемое прерывание, то есть аппаратное прерывание, которое не может игнорироваться процессором. Поскольку NMI является очень важным сообщением об отказе HW, ответ по умолчанию, начиная с ESXi 5.0 и более поздних версий, должен запускать PSOD. Более ранние версии просто регистрировали ошибку и продолжали. Как и в случае с MCE, фиолетовый экран, вызванный NMI, предоставляет важные коды,  которые имеют решающее значение для устранения неполадок.

2. Программные ошибки

·         неверное взаимодействие между компонентами ESXi SW (см. KB2105711)

·         условия гонки (см. KB2136430 )

·         из ресурсов: память, динамическая область памяти, буфер (см. KB2034111,  KB2150280)

·         бесконечный цикл + переполнение стека (см. KB2105522 )

·         неверные или неподдерживаемые параметры конфигурации (см. KB2012125,  KB2127997)

3. Некорректно функционирующие драйвера; ошибки в драйверах, которые пытаются получить доступ к некорректному индексу или несуществующему методу (см. KB2146526,  KB2148123)

Какое влияние оказывает PSOD?

Когда возникает сбой, хост выходит из строя и завершает работу всех служб, работающих на нем, вместе со всеми размещенными виртуальными машинами. Виртуальные машины отключаются резко и не завершают свою работу корректно. Если хост является частью кластера и вы настроили HA, эти виртуальные машины будут запущены на других хостах в кластере. Помимо простоя и недоступности виртуальных машин во время их простоя, «грязное» завершение может повлиять на некоторые критически важные приложения, такие как серверы баз данных, очереди сообщений или задания резервного копирования.

Кроме того, все другие службы, предоставляемые хостом, будут прекращены, поэтому, если ваш хост является частью кластера VSAN, PSOD также повлияет на vSAN.

Что делать?

1. Проанализируйте сообщение на фиолетовом экране.

Одна из самых важных вещей, которые нужно сделать при появлении фиолетового экрана — это  сделать снимок экрана. Если вы подключаетесь к консоли удаленно (IMM, iLO, iDRAC, …), будет легко сделать снимок экрана, если нет такой возможности, хотя сфотографируйте экран на телефон. На этом экране много полезной информации о причине сбоя.

2. Обратитесь в службу поддержки VMware.

Прежде чем приступить к дальнейшему исследованию и устранению неполадок, рекомендуется обратиться в службу поддержки VMware, если у вас есть контракт на поддержку. Параллельно с вашим расследованием они смогут помочь вам в проведении корневого анализа причин (RCA).

3. Перезагрузите затронутый хост ESXi.

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

4. Получите coredump

После загрузки сервера вы должны собрать дамп ядра — coredump. Coredump, также называемый vmkernel-zdump, представляет собой файл, содержащий журналы с более подробной информацией, чем та, что отображается на фиолетовом экране диагностики, и будет использоваться при дальнейшем устранении неполадок. Даже если причина сбоя может показаться очевидной из сообщения PSOD, которое вы проанализировали на шаге 1, рекомендуется подтвердить ее, просмотрев журналы из coredump.

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

а. Во временном разделе

b. В виде файла .dump  в одном из хранилищ данных хоста

c. В виде файла .dump  на vCenter — через службу netdump

Coredump становится особенно важным, если конфигурация хоста должна  автоматически сбрасываться после PSOD , и в этом случае вы не увидите сообщение на экране. Вы можете скопировать файл дампа с хоста ESXi с помощью SCP, а затем открыть его с помощью текстового редактора (например, Notepad ++). Он будет вмещать содержимое памяти на момент сбоя, и первые его части будут содержать сообщения, которые вы видели на фиолетовом экране. Служба поддержки VMware может запросить весь файл, но у вас лишь будет возможность извлечь только журнал vmkernel, который более нагляден:

5. Расшифруйте ошибку.

Устранение неполадок и анализ причин позволяют почувствовать себя Шерлоком Холмсом.  Самый важный симптом, с которого вам следует начать, — это сообщение об ошибке, создаваемое фиолетовым экраном. К счастью, количество выдаваемых сообщений об ошибках ограничено: 

Exception Type 0 #DE: Divide Error
Exception Type 1 #DB: Debug Exception
Exception Type 2 NMI: Non-Maskable Interrupt
Exception Type 3 #BP: Breakpoint Exception
Exception Type 4 #OF: Overflow (INTO instruction)
Exception Type 5 #BR: Bounds check (BOUND instruction)
Exception Type 6 #UD: Invalid Opcode
Exception Type 7 #NM: Coprocessor not available
Exception Type 8 #DF: Double Fault
Exception Type 10 #TS: Invalid TSS
Exception Type 11 #NP: Segment Not Present
Exception Type 12 #SS: Stack Segment Fault
Exception Type 13 #GP: General Protection Fault
Exception Type 14 #PF: Page Fault
Exception Type 16 #MF: Coprocessor error
Exception Type 17 #AC: Alignment Check
Exception Type 18 #MC: Machine Check Exception
Exception Type 19 #XF: SIMD Floating-Point Exception
Exception Type 20-31: Reserved
Exception Type 32-255: User-defined (clock scheduler)

Поскольку сбой в ядре обрабатывается процессором, для получения дополнительной информации об этих исключениях см.  Руководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 1: Базовая архитектура  и  Руководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 3A.

Наиболее распространенные случаи описаны в отдельных статьях базы знаний VMware. Поэтому используйте эту таблицу в качестве индекса для ошибок PSOD:

6. Проверьте журналы

Может случиться так, что причина не очень очевидна при просмотре фиолетового сообщения на экране или журнала дампа ядра, поэтому следующее место, где искать подсказки, — это журналы хоста, особенно во временном интервале, непосредственно предшествующем PSOD. Даже если вы чувствуете, что нашли причину, все же рекомендуется подтвердить ее, просмотрев журналы.

Если вы администрируете корпоративную среду, вероятно, у вас под рукой есть специализированное решение для управления журналами (например,  VMware Log Insight или SolarWinds LEM ), поэтому их будет легко просматривать, но если у вас нет управления журналами, вы можете легко  экспортировать их .

Наиболее интересные файлы журналов для изучения:

В этой статье мы расскажем, как искать иголку в стоге сена причину проблем с производительностью ВМ на ESXi. Главным способом будет то, что так не любят многие администраторы: планомерная проверка всех ресурсов на утилизацию, сатурацию и ошибки. Мы приведем ключевые метрики, на которые следует обратить внимание, их краткое описание и значения, на которые можно ориентироваться, как на норму. При этом важно понимать, что разные системы имеют разные требования к производительности. Следовательно, то, что приемлемо для одной системы, для другой может являться признаком аварийного состояния.

Кроме собственных наработок, мы использовали материалы из разных англоязычных источников. По некоторым вопросам описания тянут на отдельные статьи, поэтому на них приводим ссылки.

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

Выясняем симптомы проблемы

Вот краткий список ключевых вопросов, на которые нужно ответить:

1. Как проявляются проблемы производительности? Описываем словами, снимками, прикладываем графики.

2. Когда работало хорошо и когда начало работать плохо? Вспоминаем даты и время.

3. Были ли какие-то аппаратные, программные или нагрузочные изменения?

4. Охватывает ли проблема другие системы или только одну, например: ВМ, vApp, группу ВМ, кластер, группу кластеров и т. д.

Часть 1. Базовая проверка

Цель базовой проверки – быстро выяснить направление, в котором находится источник проблем производительности. Учитывайте, что графики в vSphere Client усредняют значения со временем, и лучше собирать максимум информации в любую стороннюю систему мониторинга (Prometeus, Zabbix, VMware vRealize Operation Manager и т. д.). Если такой системы нет, то воспроизводим проблему в реальном времени и наблюдаем за ней со стороны гипервизора. По результатам базовой проверки решаем, нужно ли дальнейшее расследование.

Проверяем ВМ из vSphere Client

1. Triggered Alarms, Tasks и Events не должны содержать событий, коррелирующих с проблемой.
2. CPU

   1. Usage не должен превышать 90%.

      Usage – процент активно задействованных мощностей виртуальных CPU. Это среднее значение загруженности CPU в виртуальной машине. Например, если виртуальная машина с одним виртуальным CPU работает на хосте, имеющем четыре физических CPU, и Usage виртуального CPU составляет 100%, то виртуальная машина полностью использует один физический CPU.

      Usage виртуального CPU = usagemhz / кол-во виртуальных CPU x частота ядра.

   2. Ready не должен превышать 10% на ядро.

      Ready показывает время, в течение которого виртуальная машина была готова к использованию, но не могла быть запущена на физическом CPU из-за нехватки ресурсов. Ready % зависит от количества виртуальных машин на хосте и загруженности их CPU.
3. Memory

   1. Ballooned должен быть равен 0.

      Этот параметр указывает на объем памяти, захваченной драйвером управления памятью ВМ (vmmemctl), который установлен в гостевую ОС вместе с VMware Tools. Данный объем перераспределяется от ВМ к гипервизору в условиях её нехватки. То же самое происходит, когда неверно выставлен Memory Limit на ВМ или ресурсный пул – это тоже ухудшает производительность ВМ.

   2. Swapped должен быть равен 0.

      Это текущий объем гостевой физической памяти, которую  VMkernel выгрузил в файл подкачки ВМ. Выгруженная память остается на диске до тех пор, пока она не понадобится ВМ, либо пока не будет запущен принудительный механизм unswap. Подробнее расписано тут: https://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/

4. Virtual Disk
   1. Нормально, если отсутствуют мгновенные снимки старше 24 часов.

   2. Highest latency не должен превышать приемлемых для приложения значений.

      Это наибольшее значение задержки среди всех дисков, используемых ВМ. Измеряет время, необходимое для обработки команды SCSI, которое гостевая ОС предоставила виртуальной машине. Задержка ядра – это время, которое требуется VMkernel для обработки запроса ввода/вывода. Задержка устройства – это время, которое требуется оборудованию для обработки запроса.

      Есть прямая зависимость от размера блока ввода/вывода (Write request size и Read request size) с временем задержки, за которое этот блок будет обработан подсистемой хранения.

   3. Write request size и Read request size не должны коррелировать с Highest latency.

      Важным нюансом этой метрики является то, что vSphere не отображает размеры блока более 512 КБ: вы увидите рост задержек вследствие роста размера блока выше 512 КБ, но при этом не будете видеть рост размера самого блока. Увидеть его можно только через утилиту хоста ESXi vscsiStats.

      Подробнее о vscsiStats здесь: https://communities.vmware.com/t5/Storage-Performance/Using-vscsiStats-for-Storage-Performance-Analysis/ta-p/2796805

      Здесь можно превратить вывод команды в гистограмму: https://www.virten.net/vmware/vscsistats-grapher/

   4. Average commands issued per second не должен превышать IOPS Limit.
   5. Commands aborted и Bus resets должны равняться 0.
5. Network

   1. Usage не должен достигать предела (vmnic хоста, политик коммутирующего оборудования или маршрутизатора).

      Этот параметр отображает объем данных, переданных и полученных всеми виртуальными сетевыми картами, подключенными к виртуальной машине.

   2. Receive packets dropped и Transmit packets dropped должен равняться 0.
   3. Packets received и Packets transmitted не должны содержать скачков, коррелирующих с проблемой в разбивке по типам Broadcast, Unicast и Multicast.

Проверяем хост из vSphere Client

1. Triggered Alarms, Tasks и Events не должны содержать событий, коррелирующих с проблемой.
2. CPU
   1. Usage по всему хосту не должен превышать 80%.
   2. Ready не должен превышать 10% на ядро (как перевести из summation в проценты подробно читайте тут: https://kb.vmware.com/s/article/2002181).
3. Memory

   1. Balloned должен равняться 0.

      Это сумма значений vmmemctl для всех включенных ВМ и служб vSphere на хосте. Если целевой размер balloon (дословно переводится как «шар») больше, чем текущий, VMkernel «раздувает» balloon внутри ВМ, в результате чего освобождается больше памяти хоста. Если целевой размер balloon меньше, чем текущий,  VMkernel «сдувает» balloon, что позволяет процессам внутри ВМ при необходимости использовать больше памяти. Подробнее про ballooning тут: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-resource-management/GUID-2B1086F3-B3F5-426C-9162-3C3CDD23A5DF.html

   2. Swap consumed должен быть равен 0.

      Это объем памяти, которая используется для подкачки всех включенных ВМ и служб vSphere на хосте.

   3. Page-fault latency должно равняться 0.

      Это время ожидания виртуальной машиной доступа к сжатой памяти или файлу подкачки.

4. Storage adapter
   1. Write rate и Read rate не должны превышать пропускную способность vmhba, коммутирующего оборудования до хранилища или пропускной способности хранилища.

   2. Write latency и Read latency должны примерно равняться по всем активным vmhba.

      Если какая-то из vmhba сильно выбивается по задержкам или нагрузке, то следует удостовериться, что политика мультипасинга выставлена корректно. Подробнее о политиках тут: https://kb.vmware.com/s/article/1011340. Большинство современных хранилищ позволяют применять политику Round Robin. После проверки политики стоит обратить внимание на качество соединения.

5. Network

   1. Usage не должен превышать пределов vmnic

      Это суммарный объем данных, которые передают и получают все физические сетевые карты, подключенные к хосту.

   2. Receive packets dropped и Transmit packets dropped должны равняться 0.
   3. Packets received и Packets transmitted недолжны содержать скачков, коррелирующих с проблемой в разбивке по типам Broadcast, Unicast и Multicast.

Часть 2. Расширенная проверка

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

Проверяем ВМ и хост

Здесь большая часть метрик берется из утилиты хоста ESXi esxtop. Очень кстати вывод esxtop можно записывать в csv-файл. Формат csv позволяет открыть его, к примеру, в PerfMon на Windows и проанализировать не только мгновенные значения, но и их изменение во времени.

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

esxtop -a  -b -d 2 -n 1000 > esxtop-output.csv

1. Должны отсутствовать ошибки в vmware.log ВМ, vmkernel.log хоста, в журнале IPMI хоста и во внешних системах журналирования по объектам, релевантным проблеме.
2. CPU в esxtop (клавиша ‘c’)

   1. CPU load average не должен превышать 1.

      Это среднее арифметическое значение загрузки CPU за 1 минуту, 5 минут и 15 минут, основанное на 6-секундных выборках.

   2. %USED не должен превышать 90 на ядро.

      Это процент физического процессорного времени, приходящийся на world. В эту величину входит метрика %RUN, обозначающая процент времени, когда world вычислялся на физическом CPU. Дополнительно сюда засчитывается %SYS, обозначающая процент времени, при котором VMkernel обрабатывал прерывания и выполнял иные системные действия для данного world. Метрика же %OVRLP вычитается из данной и отражает процент времени, которое world провел в очереди на выполнение, ожидая завершения системных действий в отношении других world.

      %USED = %RUN + %SYS — %OVRLP.

   3. %RDY не должен превышать 10.

      Это процент времени, в течение которого world был готов к запуску.

      Поясню: world, который стоит в очереди, ожидает, пока планировщик разрешит ему запуск на физическом CPU. %RDY – процент от этого времени, поэтому он всегда меньше 100%.

      Если в настройках ресурсов ВМ установлен CPU Limit, то планировщик не станет размещать ВМ на физическом CPU, когда она израсходует выделенный ей ресурс CPU. Это может произойти даже при наличии большого количества свободных тактов CPU. Время, в течение которого планировщик намеренно удерживает ВМ, отображается в параметре %MLMTD, который мы опишем дальше. Обратите внимание, что параметр %RDY включает в себя %MLMTD. Для определения задержки процессора мы будем использовать формулу: %RDY – %MLMTD. Поэтому, если показатель %RDY – %MLMTD высокий, например больше 10%, вы можете столкнуться с проблемой нехватки мощностей CPU.

      Рекомендуемый порог зависит от обстоятельств. Для пробы можно начать с 10%. Если скорость работы приложения в ВМ в порядке, то оставьте порог как есть. В противном случае – снизьте порог.

      Закономерный вопрос: а что составляет 100% времени?

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

      100% = %RUN + %RDY + %CSTP + %WAIT.

   4. %CSTP не должен превышать 3.

      Это процент времени, в течение которого world находится в состоянии co-schedule. Состояние co-schedule применимо только для многопроцессорных виртуальных машин. Планировщик CPU ESXi намеренно переводит виртуальный CPU в это состояние, если этот виртуальный CPU опережает в вычислениях другие виртуальные CPU данной ВМ.

      Высокий показатель %CSTP означает, что ВМ неравномерно использует виртуальные CPU. Приложение использует CPU с высоким %CSTP внутри ВМ гораздо чаще, чем остальные её CPU.

   5. %MLMTD должен равняться 0.

      Это процент времени, в течение которого world был готов к запуску, но не запущен планировщиком из-за настроек CPU Limit.

      Обратите внимание, что параметр %MLMTD уже учтен в расчете %RDY. Показатель %MLMTD высок, когда ВМ не может быть запущена из-за настройки CPU Limit. Если вы хотите повысить производительность этой ВМ, то увеличьте этот лимит. В целом, использование CPU Limit не рекомендуется.

   6. %SWPWT должен равняться 0.

      Это процент времени, в течение которого world ожидает, пока VMkernel завершит подкачку памяти. Время %SWPWT (ожидание подкачки) включено в %WAIT.

3. Memory в esxtop (клавиша ‘m’)
   1. Memory хоста в состоянии High. Про memory state подробно написано здесь: https://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/.

   2. MCTLSZ должен равняться 0.

      Это объем гостевой физической памяти, перераспределенной balloon-драйвером.

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

      Как тогда узнать, что виртуальная машина работает в режиме ballooning? Если показатель MCTLSZ изменяется, balloon-драйвер активно освобождает память хоста, раздувая «шар памяти» в ВМ. Скорость ballooning в краткосрочной перспективе можно оценить по изменению MCTLSZ в какую-либо сторону.

   3. SWCUR должно равняться 0.

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

      Для ВМ это текущий объем гостевой физической памяти, выгруженной в зарезервированное хранилище. Обратите внимание, что эта статистика относится к своппингу VMkernel, а не к своппингу гостевой ОС внутри ВМ.

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

   4. N%L должен быть больше 80.

      Это процент объема виртуальной памяти ВМ, который находится в локальной для её виртуальных CPU NUMA Node. Низкий процент N%L означает, что, с высокой вероятностью, какие-то запросы виртуальных процессоров ВМ используют данные оперативной памяти ВМ через межпроцессорное соединение.

      Подробнее об этом можно почитать в цикле статей от Frank Denneman: https://frankdenneman.nl/2016/07/06/introduction-2016-numa-deep-dive-series/.

4. Disk ВМ в esxtop (клавиша ‘v’)
   1. LAT/rd и LAT/wr не должны превышать приемлемых для приложения значений.
   2. CMDS/s не должен достигать IOPS Limit.
   3. MBREAD/s + MBWRTN/s не должна достигать пределов vmhba.
5. Disk Adapter в esxtop (клавиша ‘d’)

   1. QAVG/cmd должно быть около 0 и не превышать KAVG/cmd.

      Это среднее время ожидания в очереди.

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

   2. GAVG/cmd, KAVG/cmd и DAVG/cmd не должны превышать приемлемые значения для данного хранилища данных.

      • GAVG – это круговая задержка для всех запросов ввода/вывода, которые гостевая система отправляет на виртуальное устройство хранения. Параметр GAVG = KAVG + DAVG.

      • KAVG – этот параметр отслеживает задержки, связанные с работой VMkernel.

        Значение KAVG должно быть намного меньше значения DAVG и близко к нулю. Когда в ESXi много очередей, KAVG может быть таким же высоким или даже выше, чем DAVG. Если это произошло, проверьте статистику очередей и лимиты политики хранения или виртуального диска.

      • DAVG – это задержка, наблюдаемая на уровне драйвера устройства. Она включает в себя время приема-передачи между HBA и хранилищем.

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

   3. MBREAD/s + MBWRTN/s не должна достигать пределов vmhba.

   4. FCMDS/s, ABRTS/s, RESETS/s должны равняться 0.

      • FCMDS/s – это количество команд в секунду, завершившихся ошибкой. Может указывать на проблемы с контроллером хранения, состоянием соединения до хранилища или непосредственно с хранилищем.
      • ABRTS/s – это количество прерванных команд в секунду. Параметр может указывать на то, что система хранения данных не удовлетворяет требованиям гостевой ОС. Гостевая система прерывает обработку команды, если хранилище не отвечает в течение приемлемого времени (может быть настроено в гостевой ОС, в том числе и в результате установки VMware Tools). Кроме того, гостевая ОС может прервать все команды, выполняемые на ее виртуальном SCSI-адаптере.
      • RESETS/s – это количество сброшенных команд в секунду. Указывает на число отброшенных команд в результате сброса состояния адаптера. Сброс может быть вызван драйвером как реакция на какие-либо события в сети хранения данных.
6. FC
   1. Вывод команды esxcli storage san fc stats get не должен содержать ошибок.
   2. Мониторинг портов сети хранения данных не должен содержать ошибок.
7. Disk device в esxtop (клавиша ‘u’)
   1. QAVG/cmd должно быть около 0 и не превышать KAVG/cmd.
   2. KAVG/cmd должно быть около 0.
   3. DAVG/cmd, GAVG/cmd не должны превышать приемлемых для приложения значений.

   4. DQLEN должен быть более 32 (кроме устройств USB и CDROM).

      Глубина очереди (queue depth) – одна из ключевых характеристик подсистемы ввода/вывода, особенно в виртуализации, где требуется высокий параллелизм операций. Глубина очереди определяет число команд ввода/вывода, которые подсистема может осуществлять одновременно. На глубину очереди влияют протоколы, аппаратные возможности устройств, прошивки и драйверы.

      Регулируется, как минимум, в следующих местах:

      • в драйвере HBA глобально на хост: https://kb.vmware.com/s/article/1267
      • на каждом LUN есть два параметра: https://kb.vmware.com/s/article/1268
        • Device Max Queue Depth наследуется от Queue Depth драйвера HBA (предыдущий шаг). Однако может быть занижено такими технологиями, как SIOCv1 (включается в vSphere Client на Datastore) и Adaptive Queue Depth (подробнее тут: https://kb.vmware.com/s/article/1008113), которая включается расширенными настройками QFullSampleSize и QFullThreshold.
        • No of outstanding IOs with competing worlds (DSNRO) по умолчанию равняется 32. Это глубина очереди к LUN, если с ним одновременно работают более одной ВМ.
      • на контроллере и диске ВМ: https://kb.vmware.com/s/article/2053145.

      Важно: если параллелизм операций с хостов ESXi превысит допустимый параллелизм нижележащих HBA, SAN или СХД, то есть совокупная глубина очереди выполняемых в настоящий момент операций ВМ превысит глубину очереди инфраструктуры, то хост будет получать SCSI-примитивы QFULL или BUSY, и в журнале vmkernel.log будут регистрироваться такие события:

      • H:0x0 D:0x28 P:0x0 Valid sense data: 0x## 0x## 0x##
      • H:0x0 D:0x08 P:0x0 Valid sense data: 0x## 0x## 0x##
      • H:0x0 D:0x8 P:0x0 Valid sense data: 0x## 0x## 0x##

   5. QUED должно равняться 0.

      Это количество команд VMkernel, которые находятся в очереди. Статистика применима только к world и LUN.

      Большое количество команд в очереди может быть признаком того, что система хранения перегружена. Постоянно высокое значение счетчика QUED сигнализирует об узком месте (bottleneck, дословно – «бутылочное горлышко») в системе хранения, которое в некоторых случаях можно устранить, увеличив глубину очереди. После увеличения глубины очереди проверьте, что LOAD меньше 1. Это должно увеличить количество обработанных команд в секунду и повысить производительность.

   6. %USD не должно превышать 60.

      Это процент глубины очереди, используемой активными командами VMKernel. Эта статистика применима только к world и LUN.

      %USD = ACTV / QLEN * 100%

      Чтобы рассчитать статистику по world, в качестве знаменателя используйте WQLEN. Для статистики LUN (устройства) в качестве знаменателя используйте LQLEN.

      %USD показывает, сколько доступных слотов очереди команд задействованы. Высокие значения говорят о возможности образования очередей. Тогда вам потребуется настроить глубину очередей для HBA, если QUED также постоянно больше 1. Размеры очередей можно настроить в нескольких местах на пути ввода/вывода. Это помогает смягчить проблемы с производительностью, вызванные большими задержками.

   7. FCMDS/s, ABRTS/s, RESETS/s должны равняться 0.

   8. ATSF должен быть значительно меньше ATS.

      Примитив VAAI Atomic Test and Set позволяет ускорить ряд операций с подсистемой хранения. Ниже приведены две статьи, подробно объясняющие каждую операцию. Множество неудавшихся операций ATS могут стать причиной проблем в работе подсистемы хранения.

      Про ATS heartbeat: https://kb.vmware.com/s/article/2113956.

      Про ATS lock: https://kb.vmware.com/s/article/2146451.

   9. Политика мультипасинга должна быть рекомендована вендором СХД.
   10. No of outstanding IOs with competing worlds (DSNRO) должно равняться Queue Depth.
8. Network в esxtop (клавиша ‘n’)

   1. MbTX/s, MbRX/s не должны превышать vmnic.

      Это мегабиты, передаваемые (MbTX) или принимаемые (MbRX) в секунду.

      В зависимости от рабочей нагрузки MbRX/s может не совпадать с PKTRX/s, потому что размер пакетов может быть разным. Средний размер пакета можно рассчитать по формуле: средний размер пакета = MbRX/s / PKTRX/s. Увеличение размера пакетов может повысить эффективность обработки пакетов процессором. Однако потенциально это также может увеличить задержку.

   2. %DRPTX, %DRPRX должны равняться 0.

      %DRPTX – это процент потерянных исходящих пакетов.

      %DRPTX = потерянные исходящие пакеты / (успешно отправленные исходящие пакеты + потерянные исходящие пакеты).

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

      %DRPRX – это процент потерянных входящих пакетов. Вычисляется по формуле: %DRPRX = потерянные входящие пакеты / (успешные принятые входящие пакеты + потерянные входящие пакеты).

      Высокое значение %DRPRX обычно указывает на проблемы с приемом входящего трафика. Стоит выделить больше ресурсов CPU для затронутой ВМ или увеличить размер ring buffer.

9. Network
   1. Вывод команды esxcli network nic stats get -n vmnicX не должен содержать ошибок.

   2. Статистика релевантных портов vsish не должна содержать ошибок и дропов.

      Бывает так, что ВМ испытывает резкие скачки входящего трафика, способные переполнить Rx Ring Buffers. Расследовать такие ситуации можно, выяснив PORT-ID сетевой карточки ВМ через раздел network утилиты esxtop или командой esxcli network vm list -> посмотреть World ID нужной ВМ -> esxcli network vm port list -w <World ID>.

      Затем в vsish:

      cd/net/portsets/<vSwitch-NAME>/ports/<PORT-ID>/
      cat stats
      packet stats {
         pktsTx:823080899
         pktsTxMulticast:18571
         pktsTxBroadcast:1908
         pktsRx:961804917
         pktsRxMulticast:48602
         pktsRxBroadcast:1947286
         droppedTx:0
         droppedRx:27314
      }

      Ненулевое значение droppedRx может означать превышение Rx Ring Buffers. Расследуем дальше:

      cd  /net/portsets/vSwitch0/ports/<PORT-ID>/vmxnet3
      cat rxSummary
      stats of a vmxnet3 vNICrx queue {
         ...
         1st ring size:1024
         2nd ring size:64
         # of times the 1st ring is full:349
         # of times the 2nd ring is full:0
         ...
      }

      Здесь мы видим размеры ring buffers и сколько раз они были переполнены. Ненулевое значение – хороший повод увеличить ring size. Там же есть директория rxqueues, в которой может быть одна или более поддиректорий. Если включена NetQueue или RSS, то в данных директориях можно посмотреть статистику каждой очереди по отдельности.

   3. Вывод команды arp-scan подсети не должен содержать дубликатов IP и MAC-адресов.
   4. Запись трафика в момент воспроизведения проблемы не должна содержать аномалий. Об этом подробнее тут: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-C1CEBDDF-1E6E-42A8-A026-0C067DD16AE7.html.

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

• Анализ производи­тель­ности ВМ в VMware vSphere. Часть 1: CPU
• Анализ производительности ВМ в VMware vSphere. Часть 2: Memory
• Анализ производи­тельности ВМ в VMware vSphere. Часть 3: Storage