IOPS, VDI, IOMETER — Часть 2

Так вы заставляете людей рассчитывать дисковую подсистему исходя из требуемых IOPS? Это жестоко. Это вообще рушит картину мира и ведет к психологическим проблемам. Гигов должно быть много и точка. А все иопсы — от лукавого.

IOmeter

Как мы и планировали в прошлой статье, будем тестировать инфраструктуру. Идеально для этого подойдет IOmeter, хотя, многие советуют переходить на fio, т.к. есть мнение, что IOmeter, иногда, считает неверно.

Устанавливаем максимальный размер тестового файла — «Maximum Disk Size» (0 означает все свободное пространство на диске), значение задаётся в секторах, к примеру, 4 194 304 сектора (где один сектор равен 512 байт) будут равны 2GB.

*Небольшое отступление, данные числа справедливы для классических дисков отформатированных в 512 байт на сектор. Существуют 520- и 528-байтные сектора для дополнительного контроля целостности данных (Data Integrity Field). Например, такое используется у NetApp.

Это я все к чему? Начиная с 2010 года некоторые диски выпускаются в 4kN Advanced Format, с размером сектора в 4096 байт (512*8). Т.е. когда мы зададим значение 4 194 304 секторов, то мы получим тестовый файл размером не 2GB, а 16GB!

Чего, куда, откуда, зачем и какие плюсы и минусы 4kn, можно прочитать в отличной статье, вот тут. Если брать харды 4kN — да, размер файла будет в 8 раз больше, если брать харды 512e, то зависит от того, как отформатированы, по умолчанию, утилита, типа hdparm, покажет 512 — physical block size и 4k — logical, в этом случае IOmeter будет считать, что размер сектора 512.

Отдельный вопрос к выбора размера секторов для SSD дисков. Оно очень сильно отличается в зависимости от модели, фирмы производителя и положений звезд на небе во время разработки на заводе. Обычно, это значения между 256 KB и 4 MB, как видите, разброс очень приличный. Читайте документацию к своей железке!

И еще, немаловажно, если то хранилище, на котором вы проводите тесты, обладает кешом (raid-контроллер и тд.), то надо делать размер тестового файла больше, чем этот кеш, иначе, у вас будет неверное представление о производительности (т.к. будут cache-hit’ы).

Окей, с размером тестового файла разобрались, погнали дальше!

Задаём тип нагрузки в поле — Write IO Data Pattern — Full Random.
*IOMeter умеет работать с блочным устройством. При работе с блочным устройством «напрямую», создание тестового файла не требуется, IOMeter сразу начнет тестирование. На практике, не все так отлично, при тестировании современных СХД в блочных тестах, можно получить странные результаты, скорее всего, из-за современных технологий кэширования на стороне СХД. К этому накладывается то, что при эмуляции нагрузки СХД простаивает, т.к. как каким-то образом понимает, что на самом деле, никаких запросов к несуществующим данным не происходит. Поэтому, мы этот метод откладываем в сторону, но знаем, что такое тоже существует. Наши тесты будут идти поверх файловой системы, для этого IOMeter’у необходимо создать тестовый файл. В зависимости от размера этого файла (задается в поле Maximum Disk Size), данная операция может занять некоторое время. В случае тестов на файловой системе, мы получим результаты, более близкие к реальности.

Переходим на следующую вкладку, Access Specifications. Это паттерны нагрузки, симуляция реальной нагрузки. В зависимости от типа ВМ, нам надо выбрать свой паттерн (VDI, DB, Webserver, Workstation). Но, как таковых, готовых паттернов в программе нет, а те что есть, чисто для примера. Либо можно искать их на просторах интернета, либо сделать самому. Чтобы сделать самому, надо понимать реальную нагрузку вашей инфраструктуры. Для этого нам понадобятся счетчики I/O, мы их разбирали в прошлой статье. По ним понимаем сколько % у нас операции чтения занимают, сколько записи.

Создадим новый профиль нагрузки, дадим ему имя, выберем % чтения\записи, процентность рандомного доступа (в 99% случаев это будет 100% Random). Align блоков в 2019, вроде, уже не имеет смысла обсуждать, так что, оставляем как есть (относительные новые ОС уже идут сразу с нормальным alignment). Важным пунктом будет выбор блока, которым будет идти тест. Это отдельная тема для разговора, т.к. большинство профилей основаны на маленьких (4KB, 8KB IOPS), в то время, как средний размер блока в процессе работы пользователей обычно составляет от 32 до 64KB . Менее 5% пользователей используют блоки менее 10KB. Менее 15% пользователей используют блоки менее 20KB.

Добавляем наш профиль в план нагрузки и переходим на следущую вкладку Results Display.

Меняем справа Update Frequency (seconds) на 1, иначе, вы увидите только статичную картинку, а при значении 1, картина нагрузки будет изменяться раз в секунду. Жмем зеленый флажок, ждем пока создастся файл (снизу будет надпись — Preparing Drive вместо Run 1 of 1).

Все, вы великолепны, так вы получите значение IOPS которое вам может отдать СХД при той нагрузке, которой вам надо. Дальше уже можно создавать больше Workers (у вас же не одна ВМ будет на СХД)? Выдавать им разные паттерны и тд. Количество workers советуют выставлять равным количеству vCPU виртуальной машины которую мы симулируем. Также, стоит поэкспериментировать с количеством workers, т.к. 2-4 потока могут не полностью «нагнуть» вашу СХД.

Большое значение IOPS это все прекрасно, но есть нюанс. О нем — в следующей статье.