about NetApp

Одним из наиболее популярных т.н. “синтетических” тестов является программа IOmeter. ??значально эту программу разработали в Intel, но когда процесс разработки остановился, то были открыты исходные коды и в настоящий момент тест поддерживается энтузиастами OpenSource. ??зредка программа обновляется. В настоящий момент основные вебсайты программы это www.iometer.org и страница разработки на SourceForge.

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

Описания методики тестирования системы хранения с помощью программы IOmeter (версия 2006.07.27)

Программа состоит из GUI-фронтенда iometer.exe (есть только под windows) и генератора нагрузки dynamo.exe (бывает под windows, linux, solaris, netware), управляемого из GUI по сети.

Запускаем на сервере, к которому подключен тестируемый раздел на системе хранения, программу dynamo из комплекта поставки iometer, она будет осуществлять нагрузку для тестирования.
dynamo бывает под windows, linux, может быть собрана под solaris.

Ключи запуска выводятся по /?

Указывается компьютер (имя или ip), на котором установлен GUI frontend IOmeter. (/i )

Указывается имя “менеджера”, на котором запущен dynamo (/n ), будет показано в GUI.

Указывается имя (ip-адрес) компьютера “менеджера” для коммуникации с ним по сети. (/m )

Указывается номер порта для связи dynamo и GUI, если не указан, то будет взят по умолчанию 1066. Должен быть свободно пропущен через межсетевые экраны и файрволлы для обеспечения взаимодействия dynamo и IOmeter GUI.

Если небходимо, можно назначить исполнение на конкретном CPU (см. подсказку по /?).

Пример:

dynamo /i testadmin /m 192.168.0.10 /n generator001

testadmin - имя (или ip-адрес) компьютера где будет работать iometer
192.168.0.1 - адрес (можно dns-имя) сервера нагрузки (где исполняется dynamo)
generator001 - произвольное имя генератора нагрузки, показываемое в iometer GUI.

Если dynamo уже запущен, то при старте Iometer тот найдет присутствующие в сети Managers, покажет их и разрешит использование. При отсутствии удаленных dynamo будет запущен локальный dynamo, для тестирования локальных ресурсов.

Каждый процессор менеджера тестирования с запущенным dynamo представлен отдельным worker. На каждый worker можно назначить свой тест.
Worker это процесс, который будет исполнять тест. По умолчанию количество workers равно количеству процессоров (ядер, HyperThreading pseudo-CPUs). Но можно создать дополнительные workers кнопкой на тулбаре.
Дополнительно могут быть добавлены workers для тестирования интерфейсов локальной сети (см. тулбар).
Сброс workers и реконнект к менеджерам там же, на тулбаре.

В Iometer открываем конфигурационный файл, отключаем в параметрах открытия Managers and Workers, чтобы не искало чужих managers, настроенных в конфигурационном файле. В дальнейшем, если записать конфигурационный файл на своей тестировочной инфраструктуре, можно открывать и с настройками workers.

Выбираем нужного нам manager и его worker
В закладке Disk Targets выбираем объект, например смонтированный LUN системы хранения.
Желтым цветом показаны логические дисковые разделы с файловой системой, ДОСТУПНЫЕ НА ЗАП??СЬ.
Голубым - физические разделы без партиции на них.
Перечеркнутый значок означает, что на диске не найден тестовый файл.
Отмечаем нужный крестиком слева. На данном LUNе (в случае использования файловой системы) будет при первом запуске создан тестовый файл iobw.tst. Операции при тестировании будут проводиться с ним.
ВН??МАН??Е: по умолчанию этот файл будет занимать все свободное место на диске!
Это может занять продолжительное время при первом запуске. Ожидайте. По завершении создания файла начнется тест. При необходимости тестовый файл может быть обычным образом скопирован на другие разделы, чтобы не создавать его там заново.

Для того, чтобы ограничить размер тестирования введите размер файла в 512b-блоках в поле Maximum Disk Size. Например: “16777216″ sectors (8GiB).

Starting disk Sector, Outstanding IOs и Test Connection rate оставляем в состоянии по умолчанию.

В закладке Access Specifications в правой панели перечислены импортированные из конфигурационного файла преконфигурированные паттерны.
Выбираем worker у менеджера и добавляем для него из правой в левую панель необходимый паттерн.
Патернов одновременно может быть назначено несколько.
Каждый worker может иметь свои паттерны.
В конкретном случае добавляем только один только одному worker-у.

На закладке Results Display будем наблюдать ход теста.
Варианты вывода: Start of test - накопительный, или Last Update - последний замер. Период замера показывает движок Update Frequency (от 1 секунды до “бесконечности”). В случае “бесконечности” результаты отображаться не будут.
ВН??МАН??Е: это влияет только на отображение результатов, само тестирование непрерывно и в записанном результате будет показано наивысшее значение.

В группе Display назначены по умолчанию 6 индикаторов (от Total I/O per second до Interrupts per second). ??ндикаторы могут быть изменены нажатием на кнопку их имени. Оставим по умолчанию.

В закладке Test Setup указываем имя теста в поле Test Description (это будет занесено в лог тестирования для опознания результатов). Например ‘fc dbpattern’.
Поле Run Time - время исполнения теста. Если тест состоит из нескольких запусков, то это длительность ОДНОГО запуска. Устанавливаем 1 минута.
Поле Ramp Up Time это время “разгона” системы перед началом замера. Устанавливаем 15 секунд.
Остальные поля оставляем по умолчанию.

В Cycling Option выбираем из выпадающего списка
“Cycle # Outstanding IOs — …”
Это установит тестирование с прогрессивно увеличивающимся количеством потоков выполнения (Outstanding IOs).
В поле # of Outstanding IOs указываем
Start:1 End:256 Power:2 Exponential Stepping.
При этом количество потоков будет увеличиваться экспоненциально: 1,2,4 … 128,256.
Значение Outstanding IOs от 1 до 8 относится к очень “легким” программам, 128 и 256 - очень “тяжелым”. Целиком тест покажет нагрузочную способность в зависимости от интенсивности ввода-вывода от сервера.
Также можно увеличивать количество параллельно работающих workers, не забудьте предварительно их создать и назначить им паттерны нагрузки!
При выборе соответствующих вариантов тестирования становятся доступны поля ввода значений для этих режимов.
Каждый из таких потоков будет исполняться 1 минуту, итого 9 минут (+15 секунд ramp up на каждый тест) на полный тест паттерна.

Все готово.

Нажимаем на Start Tests (зеленый флажок в тулбаре). Если тестовый файл не был создан, то ожидаем, пока он будет создан, после чего начнется тестирование. Будет запрошено имя и раcположение файла результатов (по умолчанию results.csv). Желательно дать имя соответствующее профилю тестирования, например ‘fc dbpattern.csv’ для упрощения дальнейшего разбора.
Запустив тест пожно пойти посмотреть текущие результаты на “градусниках” в закладке Results Display.
В statusbar внизу программы отображается прогресс выполнения группы тестов.

По завершению тестирования одного паттерна перейти в Access Specifications и поменять паттерн. ??зменить описание теста в Test Setup и запустить новый цикл.