Хабрахабр

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

Про CPU
Часть 2. Часть 1. Про Memory

Проблема со стораджем – самая частая причина медленной работы виртуальной машины. Сегодня разберем метрики дисковой подсистемы в vSphere. Если в случаях с CPU и RAM траблшутинг заканчивается на уровне гипервизора, то при проблемах с диском, возможно, придется разбираться с сетью передачи данных и СХД.

Тему буду разбирать на примере блочного доступа к СХД, хотя при файловом доступе счетчики примерно те же.

Немного теории

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

  • количество операций ввода/вывода (Input/Output Operations Per Second, IOPS);
  • пропускную способность (Throughput);
  • задержку операций ввода/вывода (Latency).

Количество IOPS обычно важно для нагрузок произвольного характера (random): доступ к блокам на диске, расположенным в разных местах. Примером такой нагрузки могут послужить базы данных, бизнес-приложения (ERP, CRM) и т.д.

Например, такую нагрузку могут генерировать файловые сервера (но не всегда) и системы видеонаблюдения. Пропускная способность важна для нагрузок последовательного характера: доступ к блокам, расположенным друг за другом.

Пропускная способность связана с количеством операций ввода/вывода следующим образом:

Throughput = IOPS * Block size, где Block size – это размер блока.

Современные версии ESXi пропускают блоки размером до 32 767 КБ. Размер блока является довольно важной характеристикой. Не все СХД могут эффективно работать с такими большими блоками, поэтому в Advanced Settings ESXi есть параметр DiskMaxIOSize. Если блок еще больше, он делится на несколько. Рекомендую перед изменением данного параметра проконсультироваться с производителем СХД или хотя бы протестировать изменения на лабораторном стенде.  С помощью него можно уменьшить максимальный размер блока, пропускаемого гипервизором (подробнее здесь).

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

Задержка операций ввода/вывода для виртуальной машины складывается из: Latency – самый интересный параметр производительности.

  • задержки внутри гипервизора (KAVG, Average Kernel MilliSec/Read);
  • задержки, которую дают сеть передачи данных и СХД (DAVG, Average Driver MilliSec/Command).

Общая задержка, которая видна в гостевой ОС (GAVG, Average Guest MilliSec/Command), – это сумма KAVG и DAVG.

GAVG и DAVG измеряются, а KAVG рассчитывается: GAVG–DAVG.


Источник

При нормальной работе KAVG должен стремиться к нулю или, по крайней мере, быть сильно меньше, чем DAVG. Остановимся подробнее на KAVG. В таком случае при попытке превышения лимита будет расти KAVG. Единственный известный мне случай, когда KAVG ожидаемо высокий, – ограничение по IOPS на диске ВМ.

Остальные составляющие KAVG пренебрежимо малы. Самой значительной составляющей KAVG является QAVG – время в очереди на обработку внутри гипервизора.

Для высоконагруженных сред данный размер бывает полезно увеличить. Очередь в драйвере дискового адаптера и очереди к лунам имеет фиксированный размер. Данная настройка работает, когда с луном работает только одна ВМ, что бывает редко.  Если на луне несколько ВМ, необходимо также увеличить параметр Disk. Здесь описано, как увеличить очереди в драйвере адаптера (одновременно увеличится очередь к лунам). Увеличив очередь, вы уменьшаете QAVG и KAVG соответственно. SchedNumReqOutstanding (инструкция  здесь).

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

Он обеспечивает равномерный доступ к луну со стороны всех серверов кластера за счет динамического изменения очереди к луну на серверах. На размер очереди к луну может влиять включение механизма SIOC (Storage I/O Control). Подробнее здесь. То есть, если на каком-то из хостов работает ВМ, которая требует непропорционально много производительности (noisy neighbor VM), SIOC уменьшает длину очереди к луну на данном хосте (DQLEN).

Тут все просто: DAVG – это задержка, которую вносит внешняя среда (сеть передачи данных и СХД). С KAVG разобрались, теперь немного о DAVG. Для анализа проблем с DAVG  имеет смысл смотреть на них. В любой современной и не очень СХД есть свои счетчики производительности. Если же со стороны ESXi и СХД все нормально, проверяйте сеть передачи данных.

Практически все современные СХД поддерживают PSP Round-Robin (с ALUA, Asymmetric Logical Unit Access, или без). Чтобы не было проблем с производительностью, выбирайте правильную Path Selection Policy (PSP) для вашей СХД. В случае с ALUA используются только пути до контроллера, который владеет луном. Данная политика позволяет использовать все доступные пути к СХД. Если для вашего СХД правила нет, используйте плагин от производителя СХД, который создаст соответствующее правило на всех хостах кластера, или создайте правило самостоятельно. Не для всех СХД на ESXi есть дефолтные правила, которые устанавливают политику Round-Robin. Подробности здесь. 

В нашей практике это позволяло «выжать» из СХД больше производительности и значительно сократить время, которое требуется на failover в случае выхода из строя или обновления контроллеров. Также часть производителей СХД рекомендуют менять количество IOPS на путь со стандартного значения 1000 на 1. Подробности здесь. Сверьтесь с рекомендациями вендора, и если противопоказаний нет, то попробуйте изменить данный параметр.

Основные счетчики производительности дисковой подсистемы виртуальной машины

Счетчики производительности дисковой подсистемы в vCenter собраны в разделах Datastore, Disk, Virtual Disk:

Здесь вы найдете стандартные счетчики по: В разделе Datastore находятся метрики по дисковым хранилищам vSphere (датасторам), на которых лежат диски ВМ.

  • IOPS’ам (Average read/write requests per second), 
  • пропускной способности (Read/Write rate), 
  • задержкам (Read/Write/Highest latency).

Из названий счетчиков в принципе все понятно. Еще раз обращу внимание, что здесь статистика не по конкретной ВМ (или диску ВМ), а общая по всему датастору. На мой взгляд, данную статистику удобнее смотреть в ESXTOP, хотя бы исходя из того, что минимальный период измерения там 2 секунды.

Тут есть счетчики по IOPS типа summation (количество операций ввода/вывода за период измерения) и несколько счетчиков, относящихся к блочному доступу (Commands aborted, Bus resets). В разделе Disk находятся метрики по блочным устройствам, которые используются ВМ. Данную информацию, на мой взгляд, также удобнее смотреть в ESXTOP.

Здесь можно посмотреть производительность по каждому виртуальному диску. Раздел Virtual Disk – самый полезный с точки зрения поиска проблем производительности дисковой подсистемы ВМ. Помимо стандартных счетчиков количества операций ввода/вывода, объема чтения/записи и задержек, в данном разделе присутствуют полезные счетчики, которые показывают размер блока: Read/Write request size. Именно эта информация нужна, чтобы понять, есть ли проблема у конкретной виртуальной машины.

На картинке ниже график производительности диска ВМ, на котором можно увидеть количество IOPS, задержки и размер блока. 

Здесь представлена базовая информация по средней Latency и IOPS’ам. Также метрики производительности можно посмотреть по всему датастору, если включен SIOC. По умолчанию данную информацию можно посмотреть только в реальном времени.

ESXTOP

В ESXTOP несколько экранов, на которых представлена информация по дисковой подсистеме хоста в целом, отдельным виртуальным машинам и их дискам.

Экран “Disk VM” вызывается клавишей “v”: Начнем с информации по виртуальным машинам.

Чтобы посмотреть информацию по каждому диску, нажмите “e” и введите GID интересующей ВМ. NVDISK – это количество дисков ВМ.

Значение остальных параметров на данном экране понятно из их названий.

Вызывается клавишей “d” (на картинке ниже выбраны поля A,B,C,D,E,G): Еще один полезный при поиске проблем экран – Disk adapter.

Чтобы получить информацию по каждому пути на адаптере, нажмите “e” и введите название адаптера: NPTH – количество путей к лунам, которые видны с данного адаптера.

AQLEN – максимальный размер очереди на адаптере.

Также на этом экране представлены счетчики задержек, о которых я рассказывал выше: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

Здесь можно увидеть состояние очереди к лунам. На экране Disk device, который вызывается клавишей “u”, представлена информация по отдельным блочным устройствам – лунам (на картинке ниже выбраны поля A, B, F, G, I).

DQLEN – размер очереди для блочного устройства.
ACTV – количество команд ввода/вывода в ядре ESXi.
QUED – количество команд ввода/вывода в очереди.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Чем больше команд в очереди, тем выше QAVG и, соответственно, KAVG. Если %USD высокий, стоит рассмотреть возможность увеличения очереди.

Для этого нужно выбрать поля A и O. Также на экране Disk device можно посмотреть, работает ли на СХД VAAI (vStorage API for Array Integration).

Механизм VAAI позволяет перенести часть работы из гипервизора непосредственно на СХД, например, зануление, копирование блоков или блокировки.

Как видно на картинке выше, на данной СХД VAAI работает: активно используются примитивы Zero и ATS.

Советы по оптимизации работы с дисковой подсистемой на ESXi

  • Обращайте внимание на размер блока.
  • Устанавливайте оптимальный размер очереди на HBA.
  • Не забывайте включать SIOC на датасторах.
  • Выбирайте PSP в соответствии с рекомендациями производителя СХД.
  • Убедитесь, что VAAI работает.

Полезные статьи по теме:

Теги
Показать больше

Похожие статьи

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть