Хабр, приветствую! Сегодня с вами Дмитрий Михайлов, ИТ-инженер Cloud4Y, и в этой статье я поделюсь с вами опытом проверки производительности виртуальных дисков. Расскажу и покажу, что тут и как, а пощупать всё вживую вы сможете, взяв данные из папки, которую я положил в Nextcloud.  Во-первых, это одна из частых тем обращений в техподдержку. Иногда причина лежит на поверхности: некоторые клиенты запускают что-нибудь из серии CrystalMark и присылают скриншоты замеров, сопровождая их своей интерпретацией. Иные обращаются с общей жалобой на недостаточную производительность ВМ в целом или своего ПО/БД. В этом случае, разумеется, потребуется более глубокая диагностика. Во-вторых, самим интересно :). Так мы можем проверить новые и текущие тома СХД и сравнить системы между собой. Как бы там ни было, методика плюс-минус подходит в обоих случаях. Методика оценивает дисковую подсистему именно в гостевой ОС виртуальной машины. Если в самой ОС всё в порядке, это косвенно позволяет оценить с точки зрения клиента выбранный для диска профиль на соответствие как заявленным параметрам, так и своим требованиям. И можно либо оптимизировать ПО/ОС, либо перейти на более производительный дисковый профиль. Идея заключается в серии замеров утилитой iostat в течении всего времени проверки с периодическим запуском тестовой нагрузки в виде fio. Это позволит сравнить между собой показания "холостого хода" и под нагрузкой. Очень удобно, что iostat умеет сохранять показания в формате json. Это избавляет от костылификации регулярок для парсинга консольного вывода. Полученные json-файлы обрабатываются при помощи библиотек Pandas и MatPlotLib: в JupyterLab строятся графики для дальнейшего анализа. Работа утилит в командной строке и результаты в виде json позволили оптимизировать проведение диагностики. С другой стороны, это сужает применяемость методики до круга *nix-систем. Тестовый стенд представляет собой ВМ с Ubuntu 20.04 в качестве гостевой ОС, CPU 2 ядра, RAM 4 ГБ. Cloud4Y предлагает несколько дисковых политик на выбор, мы попрактикуемся на наиболее популярной из них, vcd-type-med. В конфиге runfio.cfg (можно найти в Приложении к этой статье) отражены её параметры из стандартного договора: гарантируется, в зависимости от размера диска, до 1000 iops на диск с latency менее 30 мс при нагрузке  70% на чтение  30% на запись  блок 4 КБ  при 50% random'е  Т. е. в данном случае мы проверим соответствие реальных значений заявленным. После запуска и обработки тестов результат выглядит так: На графике представлены все ключевые метрики, собранные в гостевой ОС. Тестовая нагрузка похожа на два "верблюжьих горба" и составила 700 операций на чтение и 300 на запись при latency около 1 мс, что ещё очень далеко до оговорённых 30 мс. Утилизация диска ожидаемо согласуется с тестами — 100% при нагрузке и около 0% без неё. Длина очереди под нагрузкой была на уровне 5 КБ. Тест под 100% нагрузкой пройдён. Интересно, а что произойдёт при перегрузке и почему?  x10 означает 1000% от предусмотренного политикой номинала т.е. fio запускалась с конфигом rate_iops=7000,3000, вместо обычных 700,300, Половинная нагрузка ничем принципиально не отличается от полной, интересное начинается при перегрузке. Последние три графика по сути одинаковы. Видно, что утилизация диска в моменты нагрузки также достигает 100%, как и ранее. IOPS'ы подросли немного, примерно на +20% от номинала, и составили 800 на запись и 400 на чтение. А вот длина очереди и latency выросли многократно. Почему так происходит? Дело в том, что когда гостевая ОС выходит из зоны комфорта за рамки дисковой политики, vSphere начинает троттлинг: притормаживает "лишние" IO-операции, помещая их в очередь перед отправкой к СХД так, чтобы вернуть ВМ обратно в заданные границы. Таким образом, попытки сэкономить на дисках приведут лишь к неожиданным значительным "тормозам" ПО by design. В итоге имеем вполне рабочий инструмент для анализа и диагностики дисковой подсистемы, который подойдёт не только для виртуальных машин, но и для "железных" серверов. Длительность измерений можно увеличить довольно сильно, а вместе или вместо тестовой fio-нагрузки включать/выключать боевое ПО. Так диагностика будет глубже и вы сможете точнее локализовать проблему производительности. Кроме того, в случае более сложной архитектуры дисковой системы, видно картину в целом: физические и логические устройства. На практике у нас был кейс, когда клиент столкнулся с низкой производительностью софта по обсчёту кубов данных. Сервер был "железный", без виртуализации. Разработчики ПО отвечали клиенту, что проблема в производительности дисковой подсистемы. Мы провели диагностику, фиксируя метрики на протяжении 24 часов, и дали клиенту подробный отчёт, предоставив ему аргументацию для диалога с разработчиками ПО. Под спойлером ниже — график из этого кейса, в т. ч. как иллюстрация более сложной архитектуры: физические диски были объединены в программный рейд, внутри которого организована LVM-структура томов.  Официальная документация VMWare  Кратко о тротлинге при превышении лимита IOPS  Статья VMWare о механизмах лимитирования  Для чего нужны лимиты  Статья в knowledge base Cloud4Y  Нагрузка включится дважды на 60 секунд с интервалом в 60 секунд, т.е. первая, третья и пятая минуты — холостой ход, а вторая и четвёртая — под нагрузкой. За это время будет сделано 30 замеров с интервалом в 10 секунд, который задан в теле скрипта.      Поскольку приложить к статье json-файлы никак, поиграться и пощупать можно, взяв данные из папки, которую я положил в Nextcloud. Если есть вопросы — задавайте, постараюсь ответить.   Корпоративный облачный провайдер