Как быстро и просто провести тест хранилищ с использованием утилиты IOBlazer. Как быстро и просто провести тест хранилищ с использованием утилиты IOBlazer. Автор: Александр Самойленко Дата: 21/08/2019 Поддержите VM Guru! USDT / TRC20, адрес: TCDP7d9hBM4dhU2mBt5oX2x5REPtq9QdU1 Статья:

Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.

Утилита была выпущена еще в далеком 2011 году, но с тех пор не дорабатывалась, однако этим летом мы увидели ее версию 1.01, и она снова в строю.

Основная фича утилиты для администраторов хранилищ – это возможность тонко кастомизировать параметры нагрузки на хранилище изнутри виртуальной машины, такие как:

• Размер операции ввода-вывода и паттерн нагрузки (IO size and workload pattern)
• Пакетирование / Burstiness (то есть объем исходящих операций ввода-вывода - number of outstanding IOs)
• Временные промежутки между пакетами (Burst interarrival time)
• Микс трафика чтения/записи (Read vs. write mix)
• Буфферизованные или прямые операции ввода-вывода (Buffered vs. direct IO)
• И другое

IOBlazer вырос из минималистичного эмулятора MS SQL Server, который бы сфокусирован на эмуляции только нагрузки по вводу-выводу. Ранее утилита имела очень ограниченные возможности по генерации нагрузки по модели MS SQL Server IO (Asynchronous, Un-buffered, Gather/Scatter), теперь же все стало существенно лучше. Но 2 ограничения все еще остаются:

• Выравнивание доступа к памяти по 4 КБ (страница памяти)
• Выравнивание операций доступа к диску по 512 байт (дисковый сектор)

Надо понимать, что IOBlazer используется для тестирования подсистемы хранения со стороны гостевой ОС виртуальной машины, чтобы проверить показатели качества взаимодействия ВМ и хранилища в терминах Latency, IOPS и Throughput. Эти показатели влияют на скорость выполнения операций внутри гостевой системы при работе ее приложений.

Напомним, что эти метрики значат:

IOPS (input/output operations per second)

Число выдаваемых IOPS зависит как от используемого оборудования для хостов и сетевых компонентов, так и от архитектуры системы. При проведении тестирования число IOPS коррелирует с Latency, так как при увеличении одной операции ввода-вывода (размер блока операции) уменьшается число выдаваемых IOPS, а также увеличивается latency.

Latency

Обычно задержку измеряют в миллисекундах со стороны приложений, которые выполняют определенные операции. При этом, зачастую, нет каких-то референсных значений, их приходится выяснять экспериментальным путем (насколько это устраивает пользователей).

К увеличению задержек при выполнении операций приводят увеличение блока ввода-вывода, соотношение операций чтения и записи, одновременность исполнения операций ввода-вывода со стороны нескольких виртуальных машин и т.п.

Throughput

Пропускная способность важна при выполнении больших операций ввода-вывода, а также при различных паттернах чтения записи (последовательный/случайный). Чем больше размер I/O, тем очевидно больше пропускная способность. С точки зрения объема передаваемых данных одна операция I/O размером 256К равна 64 операциям ввода-вывода по 4К, но вот с точки зрения throughput это будут совершенно разные значения, так как займут разное время.

Использование утилиты

Чтобы начать использование утилиты, нужно скачать ее с VMware Labs и запустить (установка не требуется). Сначала можно запустить ее с ключом -h, чтобы узнать доступные опции для определения характера нагрузки:

Обратите внимание, что у параметров есть дефолтные значения, и если они вас устраивают, то их можно не указывать.

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

• -a: задает паттерн операций ввода вывода, будет ли он случайный (random) или последовательный (sequential). Последовательный, конечно же, отрабатывает быстрее, чем случайный. Хранилища также по-разному реагируют на эти типы нагрузки. Дорогие хранилища лучше отрабатывают случайные операции, чем дешевые (при этом скорости последовательных операций у них могут несильно отличаться).
• -b: определяет размер буффера памяти, который будет источником для записи и целью для чтений.
• -B: контролирует, будут ли операции IO буфферизованы на уровне файловой системы, либо пойдут напрямую в хранилище.
• -c: если задан, то вычисляется псевдо-контрольная сумма для данных перед записью на диск, либо сразу после чтения. Это эмулирует процесс тяжелой нагрузки, где операции идут через кэш процессора.
• -d: этот параметр определяет устройство для тестирования (если тест будет на уровне сырого устройства) или путь к создаваемому файлу (если тест будет на уровне файловой системы). Например, в Windows для файлового доступа нужно указать так: <drive>:\path\to\file, а для доступа на уровне диска - \\.\PhisicalDrive<x>, где x – номер устройства, например, PhysicalDrive1.
• -f: размер тестового файла или размер порции от сырого устройства, которое будет использовано для теста.
• -F: заполнение тестового файла случайными данными перед инициированием операций ввода-вывода (по умолчанию файл не заполняется).
• -g: пакетирование (Burst inter-arrival time) в микросекундах. Это среднее время, если опция -G указывает равномерное распределение между пакетами.
• -G: определяет, будет ли время Burst inter-arrival time фиксированным или равномерно распределено со среднем временем, указанным в предыдущей опции (-g).
• -i: размер операции ввода-вывода в байтах. Это средний размер, если опция -l задает равномерное распределение.
• -l (большая i): определяет, будет ли размер операции ввода-вывода фиксированным, или он будет равномерно распределен со средним значением, определенным в параметре -i. Либо этот размер будет формироваться в соответствии с бимодальным распределением.  В последнем случае модами будут размеры 8 КБ (для чтения и записи), а также 128 КБ для записи и 1 МБ для чтения. Вероятность появления больших IO в этом случае – 1%. Эти значения были взяты не с потолка, а путем наблюдения за сервером MS SQL Server и его особенностями работы с хранилищами (соответственно, для него лучше использовать паттерн с бимодальным распределением).
• -I (маленькая L): задает пороговое значение в миллисекундах, которое вызывает алерт, если latency последнего выполненного IO превысит этот порог.
• -o: размер пакета (Burst size) в числе исходящих операций ввода-вывода. Этот параметр также называется Outstanding IOs. Этот размер является средним значением, если параметр -O задает равномерное распределение.
• -O: определяет, будет ли размер пакета фиксированным значением или подчиняться закону равномерного распределения.
• -p: задает формат вывода результатов:
• Обычный формат командной строки (Free format)
• Comma Separated Values (CSV), он удобен для постпроцессинга в Excel
• CSV без заголовка – для добавления результатов в файлы с уже имеющимися данными прошлых запусков.
• -P: дает возможность указать trace-файл утилиты vscsiStats (об этом ниже).
• -r: доля операций чтения в общем объеме сгенерированных операций ввода-вывода (например, 0.5 = 50%).
• -R: указывает, читать ли данные напрямую с устройства (raw device access).
• -t: длительность теста в секундах.
• -w: Число воркеров (каждый из них запускается в отдельном треде). Каждый тред совершает процессы ввода-вывода независимо от других в собственный файл или устройство.

Как мы видим IOBlazer дает самые широкие возможности по генерации паттернов нагрузки, чтобы приблизить тестирование к реальным условиям. Давайте посмотрим на некоторые примеры использования утилиты:

Тест 1.

Запускаем утилиту под Windows и выполняем тест в течение 10 секунд с дефолтными параметрами для двух устройств \\.\PhysicalDrive1 и \\.\PhysicalDrive2 (2 воркера).

C:\Users\Administrator\Desktop>IOBlazer.exe -t 10 -d \\.\PhysicalDrive1 -R -w 2

Пример полученных результатов:

Тест 2.

Запускаем утилиту на Linux и выполняем буфферизованные операции ввода-вывода в тестовый файл. В этом случае мы генерируем пакет (Burst) размером в 8 операций чтения с указанным средним временем между пакетами (average inter-arrival time) 10 секунд.

vmware@vmware src> ./ioblazer -a r -t 10 -r 1 -o 8  -g 10000 -G u -B

Результаты будут такими:

Тест 3.

В третьем примере мы запускаем IOBlazer на Mac OS и выполняем заданное число небуферризованных случайных чтений с целью измерить latency диска на чтение, которое по итогу теста составляет около 7 секунд.

vmware@vmware src> ./ioblazer -a r -t 10 -r 1 -o 1 -d /tmp/disk0 -f 3000

IOBlazer также может "проигрывать" записанные логи VSCSI, которые были получены за счет использования утилиты vscsiStats (это очень старый инструмент по работе с хранилищами, выпущенный еще в 2009 году). В качестве метрик производительности можно получить пропускную способность в IOPS и в мегабайтах в секунду, а также задержки ввода-вывода (IO latency).

Если вы сгенерировали trc-файл с помощью vscsiStats (trace file), то с помощью IOBlazer вы сможете отправить его на «воспроизведение» следующим образом:

vmware@vmware src> ./ioblazer -P exchange.trc

В этом все параметры паттерна нагрузки и самого теста будут взяты из trace-файла (параметры командной строки будут игнорированы). Результатом будет стандартный вывод IOBlazer.