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

Част 1. За процесора
Част 2. За паметта

Днес ще анализираме показателите на дисковата подсистема във vSphere. Проблем със съхранението е най-честата причина за бавна виртуална машина. Ако в случай на CPU и RAM отстраняването на неизправности приключи на ниво хипервизор, тогава ако има проблеми с диска, може да се наложи да се справите с мрежата за данни и системата за съхранение.

Ще обсъдя темата, използвайки примера за блокиран достъп до системи за съхранение, въпреки че за достъп до файлове броячите са приблизително еднакви.

Малко теория

Когато говорим за производителността на дисковата подсистема на виртуалните машини, хората обикновено обръщат внимание на три взаимосвързани параметъра:

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

Брой IOPS обикновено важно за случайни натоварвания: достъп до дискови блокове, разположени на различни места. Пример за такова натоварване могат да бъдат бази данни, бизнес приложения (ERP, CRM) и др.

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

Пропускателната способност е свързана с броя I/O операции, както следва:

Пропускателна способност = IOPS * Размер на блока, където Block size е размерът на блока.

Размерът на блока е доста важна характеристика. Съвременните версии на ESXi позволяват блокове с размер до 32 767 KB. Ако блокът е още по-голям, той се разделя на няколко. Не всички системи за съхранение могат да работят ефективно с толкова големи блокове, така че има параметър DiskMaxIOSize в разширените настройки на ESXi. Използвайки го, можете да намалите максималния размер на блока, пропускан от хипервайзора (повече подробности тук). Преди да промените този параметър, препоръчвам да се консултирате с производителя на системата за съхранение или поне да тествате промените на лабораторен стенд. 

Големият размер на блока може да има пагубен ефект върху производителността на хранилището. Дори ако броят на IOPS и пропускателната способност са относително малки, могат да се наблюдават големи закъснения при голям размер на блока. Затова обърнете внимание на този параметър.

латентност – най-интересният параметър за ефективност. I/O латентността за виртуална машина се състои от:

• закъснения в хипервайзора (KAVG, Average Kernel MilliSec/Read);
• забавяне, осигурено от мрежата за данни и системата за съхранение (DAVG, Average Driver MilliSec/Command).

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

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

източник

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

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

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

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

Размерът на опашката до Луната може да бъде повлиян от включването на механизма SIOC (Storage I/O Control). Той осигурява еднакъв достъп до луната от всички сървъри в клъстера чрез динамична промяна на опашката до луната на сървърите. Тоест, ако един от хостовете работи с виртуална машина, която изисква непропорционално много производителност (шумна съседна виртуална машина), SIOC намалява дължината на опашката до луната на този хост (DQLEN). Повече информация тук.

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

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

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

Броячи на производителността на основната дискова подсистема на виртуална машина

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

В раздел Хранилище за данни има метрики за vSphere дискови хранилища (datastores), на които се намират VM дисковете. Тук ще намерите стандартни броячи за:

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

По принцип всичко е ясно от имената на броячите. Позволете ми още веднъж да насоча вниманието ви към факта, че статистиката тук не е за конкретна VM (или VM диск), а обща статистика за цялото хранилище за данни. Според мен е по-удобно да се гледат тези статистики в ESXTOP, поне на базата на факта, че там минималният период на измерване е 2 секунди.

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

Раздел Виртуален диск – най-полезният от гледна точка на намиране на проблеми с производителността на VM дисковата подсистема. Тук можете да видите производителността за всеки виртуален диск. Именно тази информация е необходима, за да се разбере дали дадена виртуална машина има проблем. В допълнение към стандартните броячи за броя на I/O операциите, обема на четене/запис и закъсненията, този раздел съдържа полезни броячи, които показват размера на блока: Размер на заявката за четене/запис.

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

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

ESXTOP

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

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

NVDISK е броят на VM дисковете. За да видите информация за всеки диск, натиснете „e“ и въведете GID на интересуващата ви виртуална машина.

Значението на останалите параметри на този екран става ясно от имената им.

Друг полезен екран при отстраняване на проблеми е Дисков адаптер. Извиква се с клавиша “d” (на снимката по-долу са избрани полета A,B,C,D,E,G):

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

АКЛЕН – максимален размер на опашката на адаптера.

Също така на този екран са броячите на забавяне, за които говорих по-горе: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

Екранът Дисково устройство, който се извиква с натискане на клавиш “u”, предоставя информация за отделните блокови устройства – луни (на снимката по-долу са избрани полета A, B, F, G, I). Тук можете да видите състоянието на опашката за луните.

DQLEN – размер на опашка за блоково устройство.
ACTV – брой I/O команди в ядрото на ESXi.
QUED – брой I/O команди в опашката.
%ЩАТСКИ ДОЛАР – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

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

Можете също да видите на екрана на дисковото устройство дали VAAI (vStorage API за интегриране на масиви) работи на системата за съхранение. За да направите това, изберете полета A и O.

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

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

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

• Обърнете внимание на размера на блока.
• Задайте оптималния размер на опашката на HBA.
• Не забравяйте да активирате SIOC на хранилища за данни.
• Изберете PSP в съответствие с препоръките на производителя на системата за съхранение.
• Уверете се, че VAAI работи.

Полезни статии по темата:http://www.yellow-bricks.com/2011/06/23/disk-schednumreqoutstanding-the-story/
http://www.yellow-bricks.com/2009/09/29/whats-that-alua-exactly/
http://www.yellow-bricks.com/2019/03/05/dqlen-changes-what-is-going-on/
https://www.codyhosterman.com/2017/02/understanding-vmware-esxi-queuing-and-the-flasharray/
https://www.codyhosterman.com/2018/03/what-is-the-latency-stat-qavg/
https://kb.vmware.com/s/article/1267
https://kb.vmware.com/s/article/1268
https://kb.vmware.com/s/article/1027901
https://kb.vmware.com/s/article/2069356
https://kb.vmware.com/s/article/2053628
https://kb.vmware.com/s/article/1003469
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/vsphere-esxi-vcenter-server-67-performance-best-practices.pdf

Източник: www.habr.com