🥇Анализ на производителността на ВМ в VMware vSphere. Част 3: Съхранение

Част 1. За CPU
Част 2. За паметта

Днес ще разгледаме метриките на дисковата подсистема във 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 е относително нисък, при голям размер на блока може да се наблюдава високо забавяне. Затова обръщайте внимание на този параметър.

Забавяне – най-интригуващият параметър на производителността. Забавянето на входно/изходните операции за виртуалната машина се състои от:

закъснения вътре в хипервизора (KAVG, Средно време на ядро в милисекунди на прочит);
закъснения, причинени от мрежата за предаване на данни и СХД (DAVG, Средно време на драйвера в милисекунди на команда).

Общото закъснение, видимо в гостуващата ОС (GAVG, Средно време на госта в милисекунди на команда), е сумата на KAVG и DAVG.

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

Източник

Нека се спрем по-подробно на KAVG. При нормална работа KAVG трябва да се стреми към нула или поне да бъде значително по-малко от DAVG. Единственият известен случай, когато KAVG е очаквано висок, е ограничението по IOPS на диска на ВМ. В такъв случай при опит за надвишаване на лимита KAVG ще нараства.

Най-значителната съставка на KAVG е QAVG – времето в опашка за обработка вътре в хипервизора. Останалите съставки на KAVG са пренебрежимо малки.

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

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

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

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

За да няма проблеми с производителността, изберете правилната Политика за избор на път (PSP) за вашата СХД. Практически всички съвременни СХД поддържат PSP Round-Robin (с ALUA, Asymmetric Logical Unit Access, или без). Тази политика позволява да се използват всички налични пътища към СХД. В случай на ALUA се използват само пътищата до контролера, който притежава луном. Не за всички СХД на ESXi има дефолтни правила, които установяват политиката Round-Robin. Ако за вашата СХД такова правило няма, използвайте плъгин от производителя на СХД, който ще създаде съответното правило на всички хостове в кластера, или създайте правило сами. Подробности тук.

Също така, част от производителите на СХД препоръчват да промените броя на IOPS на пътя от стандартната стойност 1000 на 1. В нашата практика това позволяваше да „издърпаме“ по-голяма производителност от СХД и значително да намалим времето, необходимо за failover в случай на повреда или обновление на контролерите. Сверете се с препоръките на вендора, и ако нямате противопоказания, опитайте се да промените този параметър. Подробности тук.

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

Бройчиците на производителността на дисковата подсистема в vCenter са събрани в разделите Datastore, Disk, Virtual Disk:

В секцията Datastore тук се намират метрики по дисковите хранилища vSphere (датасторите), на които лежат дисковете на ВМ. Тук ще намерите стандартни бройчици по:

IOPS (среден брой заявки за четене/запис на секунда),
пропускната способност (скорост на четене/запис),
забавяния (четене/запис/най-високо забавяне).

От имената на бройците в принцип всичко е ясно. Още веднъж бих искал да подчертая, че тук статистиката не е за конкретна ВМ (или дискове на ВМ), а обща за целия датастор. На мое мнение, тази статистика е по-удобно да се гледа в ESXTOP, понеже минималният период на измерване там е 2 секунди.

В секцията Disk тук се намират метрики за блокови устройства, които се използват от ВМ. Има бройчици по IOPS тип сумирация (брой операции вход/изход за периода на измерване) и няколко бройчици, свързани с блоков достъп (абортирани команди, нулирания на шина). Според мен, тази информация също е по-удобно да се гледа в ESXTOP.

Дял Virtual Disk – най-полезният от гледна точка на търсене на проблеми с производителността на дисковата подсистема на ВМ. Тук можете да видите производителността на всеки виртуален диск. Тази информация е необходима, за да разберете, дали има проблем с конкретната виртуална машина. Освен стандартните метрики за брой входно/изходни операции, размер на прочит и запис, и забавяния, в този раздел има полезни показатели, които показват размера на блока: размер на заявките за прочит/запис.

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

Метриките за производителност могат също да бъдат прегледани за целия датастор, ако SIOC е включен. Тук е представена основна информация за средната латентност и IOPS. По подразбиране тази информация може да се види само в реално време.

ESXTOP

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

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

NVDISK – това е броят на дисковете на ВМ. За да видите информация за всеки диск, натиснете “e” и въведете GID на интересуващата ви ВМ.

Стойностите на другите параметри на този екран могат да бъдат разбрани от имената им.

Още един полезен екран при търсене на проблеми е – Disk adapter. Актива се с клавиша “d” (на изображението по-долу са избрани полета A,B,C,D,E,G):

NPTH – броят на пътищата до луните, видими от този адаптер. За да получите информация за всеки път на адаптера, натиснете “e” и въведете името на адаптера:

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.

Ако %USD е висок, трябва да обмислите възможността за увеличаване на опашката. Колкото повече команди има в опашката, толкова по-високи ще бъдат QAVG и, съответно, KAVG.

Също така, на екрана Disk device можете да видите дали VAAI (vStorage API за интеграция на масиви) работи на СХД. За целта трябва да изберете полетата A и O.

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

Както е видно на изображението по-горе, VAAI работи на този СХД: активно се използват примитивите Zero и ATS.