about NetApp

Когда я, еще в 2007 году писал небольшой обзор программы IOmeter, которой как раз незадолго до этого измерял показатели производительности некоторых моделей систем хранения NetApp, я не предполагал, что эта небольшая заметка станет с той поры “бестселлером” блога. Неожиданно для себя я обнаружил, что подробного описания работы с таким популярным средством тестирования и измерения на русском языке просто нет. Не так давно коллега track написал гораздо более подробное описание настройки и работы с IOmeter, и c его любезного согласия, я публикую этот текст у себя в блоге.

Программа IOmeter - это популярный тест для тестирования производительности дисковой подсистемы и локальной сети. Тест является “100% синтетикой”.
К сожалению, некоторая неочевидность процесса тестирования в нем, устаревший внешний вид, отсутствие полноценного онлайн-хелпа, и документации, а также русскоязычного описания, часто вызывают затруднения при попытках его использовать. Также в интернете практически отсутствует подробное описание методики работы с ним, и описание используемых терминов и фич.

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

При неоспоримых преимуществах таких “реальных” тестов им присущ и серьезный недостаток, например сложно или практически невозможно создать тест, выходящий за рамки некоторых типовых действий, например офисной работы.
Во-вторых, часто трудно проинтерпретировать результаты, так как методика измерения довольно темна и запутана внутри используемых в имитационном тестировании приложений.

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

Популярный тест IOmeter относится ко второй категории, “синтетических” тестов.

Эта программа изначально была разработана в компании Intel, и впоследствии, когда ее развитие в Intel остановилось, была передана в “опенсорс”, сообщество которого и продолжает ее постепенное развитие.
Несмотря на то, что у программы есть свой вебсайт, я рекомендую скачивать ее со странички проекта на Sourceforge.
Дело в том, что по ссылке Download с офсайта отдается последний Stable, который давно (2006.07.27) застыл, тогда как на Sourceforge последний - Devel 2008.06.22 rc2, котором сделано довольно много существенных изменений и улучшений, поэтому рекомендую пользоваться именно им.

Для этой версии на Sourceforge собраны следующие бинарники:
X86_64, IA64 (native Itanium), Win32 и Linux x86_64. ??з сорцов можно (попробовать) собрать Dynamo под нужную платформу, так, после небольшой рихтовки и шаманства он собрался под нужный мне Solaris 10/SPARC.

??нтересное начнется с самого начала. После установки вы обнаружите в папке программы два исполняемых файла: iometer.exe и Dynamo.exe. Дело в том, что IOmeter построен по “двухкомпонентной” схеме, позволяющей не только отделить тестируемую систему от управляющей, но и управлять сразу множеством тестируемых компьютеров. Iometer.exe это управляющая программа с GUI, а Dynamo.exe - командлайновая утилита под соответствующую платформу.

Такое разделение очень удобно, например, для меня, когда моя тестируемая система находится в датацентре в соседнем здании, где находиться, прямо скажем, не слишком комфортно (шумно, холодно, дует, да и тривиально даже сесть не на что). С помощью такой двухкомпонентной системы тестирования я могу запустить Load Generator (Dynamo.exe) на тестируемых серверах в датацентре, уйти в офис, и уже оттуда подключиться к ним по локальной сети и управлять всеми ими удаленно, получая результаты на свой ноут.

Однако, если у вас не стоит задача делать “распределенное” тестирование, то можно всем этим не заморачиваться, и просто запустить iometer.exe. При этом вы увидите экран GUI-менеджера, и следом запустится локально Dynamo.

?? Dynamo, и IOmeter можно запустить с ключом /? При этом, ожидаемо, вы получите список некоторых полезных ключей запуска.

IOmeter:
Iometer config_file [result_file [timeout_value]]
Iometer [/c config_file][/r result_file][/t timeout_vaue][/p port][/m 1]

Config_file - файл конфига. Должен существовать и быть валидным icf.
Result_file - файл результатов (в формате CSV), дополняется, если не существует - создается.
Timeout_value - число секунд, которые ждем участников для логина.
Port_number - порт, который слушаем для логина.
/m - показать большой gauge при тестировании.

Если заданы и config_file и results_file, то Iometer пытается запуститься в пакетном режиме, без участия человека, запустить и остановить тесты, если запуск определен в Test Setup tab загруженного config_file, записать результаты в result_file, и по окончании работы закрыть iometer.

Возможность пакетного запуска очень удобна и полезна, так как тесты могут в совокупности занимать по многу часов.

Dynamo:
dynamo [/i iometer_computer_name /m manager_computer_name] [/n manager_name] [/c cpu_affinity] [/p login_port_number]

iometer_computer_name - это имя или IP-адрес компьютера с запущенным Iometer, к которому мы будем из Dynamo логиниться. Без этого параметра Dynamo будет искать его на localhost.
manager_name - это имя компьютера с Dynamo, в терминах IOmeter он называется “manager”. По умолчанию это имя хоста. Важно если вы используете его в конфиге IOmeter, например назначаете конкретно ему какую-то задачу в предварительно записанном конфиге.
manager_computer_name - это имя или IP компьютера с Dynamo, с помощью которого будет коммуницировать GUI с этим Dynamo. По умолчанию используется IP-адрес первой сетевой карты
login_port_number - это порт, на котором будет происходить login между Dynamo и GUI. По умолчанию - 1066. Не забудьте его открыть, в случае файрволлов.
cpu_affinity - это номер конкретного CPU, на котором будет исполняться Dynamo в случае многопроцессорной системы. Если не определен, то на первом же CPU.

Таким образом, строка для запуска может быть
track@unixbox> ./dynamo /i 192.168.1.100 /m 192.168.1.10 /n LG1

При этом мы запустим экземпляр Dynamo на машине с IP 192.168.1.10, которая появится в GUI, расположенном по адресу 192.168.1.100 и будет в нем называться LG1

Еще один ключ, не указанный в выводе /? это ключ /force_raw. Этот ключ говорит игнорировать обнаруженные на диске файловые системы, и тестировать его как raw-устройство. БУДЬТЕ ОСТОРОЖНЫ с его использованием, так как с ним сформатированный файловой системой диск будет испорчен при тестировании.

При запуске по сети, процесс логина от удаленных Dynamo занимает несколько секунд, в случае локального запуска все происходит моментально.

Одно из ключевых понятий в IOmeter это “worker”.
Worker это объект, выполняющий задачу тестирования. ??менно ему назначается то или иное действие.
По умолчанию Dynamo (в терминах IOmeter - “manager”, что немного неожиданно, логичнее называть в этой паре менеджером именно GUI, IOmeter.exe) создает Worker-ов в количестве, равном обнаруженным на системе процессорным ядрам. ??мейте ввиду, что в случае наличия Hyperthreading они будут распознаны как два ядра, что может быть не вполне хорошо для запуска на каждом из них интенсивного нагрузочного приложения.
??спользовать можно любое количество воркеров из имеющихся, можно, конечно, назначить тест и только на одного.

??так, запустили IOmeter.

Слева в колонку Topology у нас залогинятся наши Dynamo, на локальной или удаленных машинах.
На моем ноуте Asus 901Go на процессоре Atom N270 нашлось, как вы видите, два ядра и создалось два worker.

Первая закладка называется Disk Targets.
При первом запуске вы увидите в колонке Targets для выбранного слева manager и его worker все те диски, которые он у себя видит (в случае, если вы запускаете Dynamo на удаленной машине, это будут диски, которые он видит там, у себя, на удаленной машине). Желтым цветом будут окрашены диски, имеющие на себе распознанную файловую систему, голубым - raw-партиции, неотформатированные или имеющие нераспознанную данной OS файловую систему.

Сначала все диски будут перечеркнуты красной линией. Это означает, что на них не найден тестовый файл, необходимый для тестирования на файловой системе (в случае raw-partition это не нужно, и “голубые” диски сразу готовы к тестированию).
Выбрать диск для тестирования можно поставив в чекбоксе крестик.
Тестовый файл iobw.tst создается в корне соответствущего диска при первом запуске, и, ВН??МАН??Е, по умолчанию занимает весь свободный объем диска! Это может быть и долго, и… э-э… неожиданно ;) для приложений или OS, если вы, например, экспериментируете на рабочем компьютере.
Для того, чтобы ограничить его размер, можно задать его размер в поле Maximum disk size, размер указывается в СЕКТОРАХ, размером 512 байт!
Например, 65535 секторов - 32MB.
Starting disk sector может задать стартовый сектор в случае raw-partition.
# of Outstanding IOs это важный параметр, стоящий подробного описания.

Каждая задача, каждая программа, исполняемая на компьютере обычно осуществляет ввод/вывод на диск. Как правило, они делают это не одним потоком, а одновременно записывают и считывают с диска несколько параллельных процессов.
Принято считать, что 4-8 потоков ввода/вывода порождают совсем простые приложения, типа notepad.exe и calc.exe. Крупные программы, уровня MS Word - 32-64 параллельны потока, максимумом можно считать 256, соответствующего крупной enterprise-базе данных типа Oracle, под хорошей нагрузкой.
Количество одновременных потоков ввода/вывода это и есть “# of Outstanding IOs”.
Для того, чтобы протестировать систему на нагрузке, приближенной к боевой, этот параметр нужно активно использовать.
Но сейчас, тут, на этом месте, мы этот параметр трогать не станем, мы зададим работу с ним отдельно позже.

Перейдем на вкладку Network Targets.

С помощью IOmeter можно также тестировать и производительность локальной сети, но я этим никогда не занимался, поэтому тут могу только сказать, что добавить Network Worker-а можно нажав на кнопку на тулбаре, выделив нужного “менеджера” слева.

Следующая вкладка, Access Specification - важная. ??менно на ней создается и задается “тестовый паттерн”, тот профиль тестовой нагрузки который будет нагружать нашу систему.

Выбрав Worker слева, выбираем один из имеющихся у нас профилей нагрузки, и добавляем его кнопкой Add в левую панель. Таким образом мы назначаем тестировочную задачу имеющемуся worker-у. Если у нас планируется запустить параллельно (или последовательно) несколько worker-ов, также добавляем им паттерн нагрузки.
Если слева мы выберем не один конкретный worker, а элемент, включающий их в себя, то назначенный паттерн назначится всем worker-ам ниже по иерархии.
Добавить можно и не один паттерн на воркер.

Паттерны можно создавать самому, а можно воспользоваться уже заданным набором. Когда-то, когда IOmeter еще производился компанией Intel, с ним в комплекте шло несколько разработанных Intel тестировочных паттернов.
Вот тут: iometer2.icf можно скачать конфигурационный файл для IOmeter, с видимым на скриншоте набором тестировочных паттернов нагрузки, с большим или меньшим успехом имитирующих те или иные типовые нагрузки.
Также можно поправить, или даже нарисовать свой собственный. Нажмите New или выберите паттерн и нажмите Edit (или Edit Copy), и откроется окно задания параметров.

Рисуя паттерн мы задаем блоки, которыми будет обращаться тест к системе хранения (или сети, если мы тестируем сетевой интерфейс).
Размер блоков это левая верхняя панель: Transfer Request Size.
Относительное количество таких блоков: Percent of Access Specification. Если вы задаете сложный паттерн, то суммарное количество всех должно равняться 100%.
Крайняя левая - Percent Read/Write Distribution - определяет каково будет соотношение записей и чтений по данному паттерну. Так, например, для File Server задано 80% read и 20% write, а для вебсервера, с которого, обычно, только читают, задано 100% read.
Четвертый важный параметр Percent Random/Sequental Distribution- характер доступа, выбирается между Random и Sequental, случайным и последовательным доступом к тестовому файлу.
Остальные параметры используются редко.

Предпоследняя вкладка - Result Display.
На ней мы будем видеть то, как идет наше тестирование, его результаты по выбранным параметрам.

Два важных контрола на этой вкладке - переключатель Result Since и движок Update Frequency.
Первый определяет то, какие будут выводиться результаты на “градусники” ниже - суммарный с начала теста (Start of Test) или мгновенный, текущий (Last Update).
Регулятор определяет частоту смены показаний на экране.
Обратите внимание, что все это влияет только на отображение в программе, в файл результатов будет записано максимальное достигнутое за время тестов значение.

Для отображения по умолчанию выбрано 6 показателей. ??х можно сменить, нажав на “кнопку” с параметром и выбрав в меню нужный для отображения параметр. Это также влияет только на отображение в программе, в результирующий файл будут записаны они все.

??, наконец, перейдем к настройке процесса тестирования, закладке Test Setup

Для выбранного worker, напоминаю снова, что все действия производятся и назначаются на конкретный объект worker, запишем Test Description, чтобы потом разобраться что за результаты у нас в общем CSV-файле результатов.
Зададим время выполнения теста: Run Time
?? установим “время разгона”, предварительного периода для “прогрева”: Ramp Up Time.

Этим можно было бы и ограничиться, если мы хотели провести один тест. Но, как правило, интересно сделать сразу несколькоd в прием, а не тыкать в кнопочки, дожидаясь окончания каждого. Для этого IOmeter оснащен богатыми возможностями.
В выпадающем списке Cycling Options можно задать условия последовательного выполнения тестов соответствии с определенными условиями и изменениями параметров.

Например, как я уже говорил выше, я предлагаю не устанавливать параметр # of Outstanding IOs, а запустить тесты последовательно, с постепенным увеличением его, с тем, чтобы увидеть в результате, динамику реакции системы хранения на нагрузку ввода/вывода.

Впрочем вариантов выполнения Cycling Options 8 штук, попробуйте разобраться по образцу.

Выбрав указанный на скриншоте вариант, можно установить поля от скольки (1) и до скольки (256) увеличивать количество потоков. В качестве характера прироста рекомендую Exponential Sepping и Power: 2. При этом прирост будет удвоением: 1 - 2 - 4 - 8 - 16…Такой шаг прироста достаточен для оценки нагрузочной способности подсистемы ввода/вывода.

??так, мы добрались до момента старта.
Нажимаем на тулбаре кнопку с зеленым флажком.
Нам предлагается сохранить результаты в файл CSV (Comma Separated Value) с именем по умолчанию results.CSV. Если этот файл уже существует, то он будет ДОП??САН, в начале новых данных будет указано имя теста, заданное нами в Test Setup.
В дальнейшем можно будет этот CSV импортировать в Excel и настроить по его данным красивых графиков.

В первый запуск долгое время ничего видимого не происходит так как для первого запуска создается тестовый файл. Об этом говорит сообщение внизу: Preparing Drives. Когда файл создан, то в Disk Targets исчезает красная зачеркивающая линия. В дальнейших запусках файл не пересоздается, и тест запускается сразу.

В левом нижнем углу отображается название идущего теста.
В правом, сообщение Ramp remaining говорит, что идет процесс “прогрева” перед тестом, а Run 1 of 6, что запущен первый из 6 назначенных в Cycling options тестов.

Для того, чтобы остановить текущий тест (и перейти к следующему) можно нажать кнопку Stop на тулбаре, а чтобы прервать всю последовательность тестов - Stop All.

Теперь перейдем на закладку Test Results.

“Градусники” показывают текущее значение тестов, а цифра посередине него - текущее значение выбранного параметра.
Run remainings: оставшееся время текущего теста.
Суммарное время будет составлять (при ранее указанных параметрах): (30 секунд ramp + 10 минут теста) * 6 тестов.

Во время теста ход его отображается в окне утилиты Dynamo.

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