Posts tagged ‘iometer’

Сборка fio под Windows x64

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

Однако IOmeter достаточно давно затормозился в развитии, и на сегодняшний день имеет stable в версии аж 2006(!) года, а собираемый community имеет версию 1.1RC1 и обновлялся аж летом 2011 года, что никак нельзя назвать приемлемым. К тому же отдельные версии (Linux x64, например) имеют крайне досадные баги, сводящие на нет его применимость под эти платформы.

Поэтому все больше людей для тестирования производительности ищут более современные инструменты. По этой причине несколько месяцев назад мне попался на глаза очень активно развивающийся проект такой утилиты измерения производительности - fio (flexible input-output tester).
О тестировании дисковой подсистемы с помощью fio можно почитать например вот в этой статье.

К сожалению до недавних пор fio существовал только под Linux, поэтому было очень любопытно обнаружить в блоге нетапповского инженера Neto статью о сборке fio под Windows x64.

Нет смысла перепощивать ее сюда, там коротенько и совершенно понятно как и что делать, даже без перевода, так что просто сошлюсь на нее здесь.

Сравнительное тестирование HDS AMS2100 и NetApp FAS2240-2

Нам пишут наши читатели:

Оригнал здесь, перепечатывается оттуда по согласию с автором: http://ua9uqb.livejournal.com/79872.html


Не так давно довелось мне протестировать две системы хранения данных, делюсь результатами. В тесте принимали участие системы начального уровня NetApp FAS2240 и Hitachi AMS2100.
Надо понимать, что системы эти сравнимы довольно условно, так как AMS - обычное, бедное по функционалу блочное хранилище, в отличии от сильно мозговитого, "всё-всё умеющего" NetApp-а. Конфигурации системы, методики тестирования, и прочие тюнинги, были согласованны со специалистами вендоров.

Немного подробностей по методике:
1. Тестирование проводилось программой IOMeter версии 2006.07.27 для Windows.

2. Подключение СХД Hitachi AMS2100 производится посредством FC4G, протокол FC
Cостав LUN и томов СХД
Raid10 8 x 450gb 15k 3.5’ Usable: 1.5Tb Lun: 700Gb
Raid6 8+2 450gb 15k 3.5’ Usable: 3.1Tb Lun: 700Gb

3. Подключение СХД NetApp FAS2240 производится посредством 10Ge, протокол iscsi
Состав LUN и томов СХД
RaidDP 9+2 x 600gb 10k 2.5’ Usable: 4.33Tb Lun: 700Gb

4. Тесты проводится в режиме файловой системы NTFS 4к, выравнивание партишина 64к;

5. Настройки программы IOMeter:
• Worker’s – 4
• Target – 16 (в каждом из Worker’s)
• Disk Size – 200000000 (100Gb)
• Ramp Up Time – 600 сек
• Run Time – 30 мин

6. Фиксация результатов каждого теста для IOMeter длиться 30 минут начиная с 10-й и заканчивая 40-й минутой теста;

7. Профили нагрузок(название профилей условное), используемые для тестирования IOMeter следующие: 
Нагрузка характерная для приложений ORACLE 
• размер блока 8КБ;
• соотношение количества операций чтения/запись 30/70;
• характер нагрузки – 100% случайный доступ;

Нагрузка характерная для VMware:
• размер блока 4КБ;
• соотношение количества операций чтения/запись 40/60;
• характер нагрузки – 45% линейный и 55% случайный доступ;

Нагрузка характерная для операций Backup:
• размер блока 64КБ;
• 100% последовательное чтение;

Итог:

Табличка довольно прозрачная, поэтому никаких выводов делать не буду.
NetApp FAS2240(в центре, где куча вертикальных планочек, и жёлтая наклейка сверху):

 

Hitachi AMS2100

PS. Дополнительно проводилось тестирование программой IOZone, порядок цифр примерно тот же, если будут интересующиеся, выложу результаты.

PPS. Пост навеян коментом френдессы [info]balorus к посту про сервер Sun T4-4 :-)

PPPS. Мой выбор был бы NetApp, если бы Хитача в те же деньги не уложила сильно больше шпинделей. А так же не ещё один сильно политический нюанс, который очень сложно перебить даже теми волшебными, и крайне необходимыми нам штуками, которые NetApp умеет делать очень хорошо, а AMS не умеет в принципе.

Правда ли что производительность хранилища NetApp падает со временем из-за фрагментации?

Несколько слов по поводу того, что пост этот случайно появился в понедельник, а затем исчез из блога. Как вы догадываетесь, я не в 8 утра в понедельник пишу посты, они у меня обычно написаны в некотором количестве впрок, обычно на месяц вперед, с “автопостилкой”, которая их “раскрывает” по мере наступления соответствующего дня и времени. Случайно оно взглючило и расскринился пост за четверг. Так что не надо conspiracy theory привлекать, это просто глюки базы блога. Вот вам этот текст, раз уж он все равно в rss-ленту для многих утек.

Любопытный эксперимент провел John Fullbright отвечая на вопрос, являющийся, пожалуй, второй по популярности темой FUD наших конкурентов: “Производительность NetApp (якобы) падает с течением времени, из-за увеличения фрагментации WAFL на дисках, при постоянной случайной записи”.

У него дома стоит сравнительно небольшая система “позапрошлого” поколения – FAS3050, с двумя полками дисков SATA 320GB 5400RPM, которую он использует под домашнюю лабораторию для хранения виртуальных машин MS Hyper-V.

Система эта, к слову, имеет свой собственный твиттер, и пишет туда, с помощью скрипта на Powershell, новости своей жизни :)

Вот каковы были исходные данные:

The Test Platform:

  • FAS3050
  • ONTAP 7.3.4
  • (2) DS14MK2-AT drive shelves – dual looped
  • (28) 320GB Maxtor MaxLine II 5400RPM SATA drives
    • Storage for Checksums ~8%
    • Right-sized (for hot-swap) = ~2% across the industry
    • WAFL Formatted = 26.8 GB per drive (reserved for storage virtualization)
    • 11ms average seek time
    • 2MB buffer
    • Internal data rate 44MBps
    • Drive transfer rate of 133 MBps
  • Storage Efficiency/Virtualization Technologies Employed:
    • Volume-level Deduplication
    • Thin Provisioning
    • RAID-DP
  • RAID-DP RG size = 24
  • Tuning options:
    • optimize_write_once = off
    • read_reallocate = on

Из 28 имеющихся дисков, на 3 расположен root volume, 1 диск hot spare, остальные 24 целиком собраны в одну группу RAID-DP, на которой расположен один aggregate.

Общая usable space системы равна 5,18TB (5.18 TB = 5304 GB = 22 drives * 241.2 GB). Кроме тестовых данных на системе расположены 26 виртуальных машин Hyper-V (показатели дедупликации для данного тома – 78%), а также шара CIFS с образами ISO.

Для теста на пространстве хранения было создано 3 LUN по 1,5TB размером каждый, которые по iSCSI были подключены к трем виртуальным машинам, с запущеным на них IOmeter Dynamo.
Таким образом, пространство хранения системы было заполнено тестировочными LUN-ами примерно на 88%.

В IOmeter был конфигурирован тестовый паттерн с 100% random write блоками по 4KB (также было выставлено выравнивание по границе 4KB, о нужности и смысле чего я писал ранее).
Для тестирования были сконфигурированы три workers, каждый на своей виртуальной машине.

6a00d8341ca27e53ef0148c8700c6b970c-800wi

Каждый worker создал на своем LUN тестовый файл на всю его длину.
Тестирование продолжалось 240 часов (10 суток) для того, чтобы гарантировать полную многократную перезапись содержимого тестового файла.

Спустя 15 часов после начала теста IOmeter демонстрировал следующие результаты:

6a00d8341ca27e53ef0148c87010dd970c-800wi

Вы видите показатель производительности, равный 11248 IOPS при 4,2ms latency.
Довольно неплохо для 24 дисков SATA.

Спустя 60 часов:

6a00d8341ca27e53ef0148c8701996970c-800wi

Результат вырос до 12063 IOPS, а latency незначительно снизилась до 3,97ms.

На протяжении 10 дней тестирования на 4,5TB суммарного объема трех LUN было записано примерно 36TB тестового потока данных. В ходе тестирования был зарегистрирован рост показателя IOPS на 18% при незначительных изменениях latency в районе 4ms.

Общая картина изменений IOPS в ходе тестирования:

6a00d8341ca27e53ef0148c87024dd970c-800wi

По вертикали – IOPS, по горизонтали – часы. В дальнейшем, до конца тестирования, показатели не менялись.

UPD: Также упомяну, что еще в 2008-м году NetApp публиковала в SPC-1 результат 48-hours Sustainability Test системы FAS3040. Результаты и описание можно посмотреть на сайте SPC и по приведенной ссылке на PDF.

IOmeter – параметр Align I/Os

Я уже пару раз писал в этом блоге о чрезвычайно полезной программке IOmeter, предназначенной для нагрузочного тестирования и измерения производительности серверов, систем хранения и сети. К моему удивлению, эти две статьи приводят на мой скромный блог громное количство народу, так как, как оазалось, подробного описания использования IOmeter (а тем более на русском) в интернете просто нет. Программа же не вполне “интуитивно понятна”, и, зачастую, именно этим объясняется то, что такой замечательный, гибкий и удобный, и при этом абслютно бесплатный инструмент тестирования находится в определенном “загоне”.

Основная сложность с IOmeter заключается как раз в многочисленности и неочевидности его настроек, дающих ту самую гибкость, вдобавок нынешняя версия IOmeter приходит без каких-либо настроек по умолчанию. Я в предыдущей статье сделал попытку составить некий элементарный файл пресетов профилей нагрузок (“сервер баз данных OLTP”, “файл-сервер”, “веб-сервер”, и т.д.), который можно брать и пользоваться им в качестве основы для ваших тестирований. Однако многие параметры генерации нагрузки, и их смысл, все равно оставались для меня довольно туманными.

Недавно я пролистывал чрезвычайно полезный сам по себе блог Антонио Хосе Родригеса Нето, системного инженера бразильского отделения NetApp, специализрующегося на вопросах использования систем хранения NetApp и баз данных Oracle. В одном из постов я углядел любопытную рекомендацию относительно установки и использования параметра Align I/Os, которую обычно всегда оставлял по умолчанию. Этот параметр устанавливает смещение паттернов ввода-вывода, и значение по умолчанию его – 512 байт (sector boundary).

image

Neto справедливо указывает, что для современных систем хранения имеет смысл устанавливать его значение в 4096 байт, как более соответствующего структурам и нормам работы дискового хранилища, обычно располагающегося не на физическом диске как таковом, а на RAID-группе, имеющей более крупный размер элемента данных. В частности, в случае NetApp это блок WAFL, как раз и имеющий размер 4KB.

Кстати, по ссылке Neto демонстрирует тест FAS3140A на 96 дисках FC 300G 15K, при трех серверах load-generator под RedHat Linux, подключенных по 4Gb FC, и показывающего свыше 100K IOPS на нагрузке 4KB блоками и 100% random write. Очень впечатляющий результат.

Тестирование с помощью программы IOmeter

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

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

IOmeter file access patterns

Here a basic sample patterns for IOmeter testing evaluation.
Database and Fileserver patterns taken from Intel’s IOmeter distribution (prior it’s opensourse development), Workstation – from StorageReview.com website, Webserver – it’s an “empirical” pattern from some real webserver load.
Up-to-date IOmeter can be downloaded from SourceForge website (not from iometer.org, which still give you outdated “2006” version, latest (currently) is a 2008-rc2 for Windows32-64/IA64/Linux, with many improvements).

 

Database pattern (Intel/StorageReview.com)

Block size

% of size

% of read

% of random

8192b

100

67

100

 

Fileserver pattern (Intel)

Block size

% of size

% of read

% of random

512

10

80

100

1024

5

80

100

2048

5

80

100

4096

60

80

100

8192

2

80

100

16384

4

80

100

32768

4

80

100

65535

10

80

100

 

Workstation pattern (StorageReview.com)

Block size

% of size

% of read

% of random

8192

100

80

80

 

Webserver pattern

Block size

% of size

% of read

% of random

512

22

100

100

1024

15

100

100

2048

8

100

100

4096

23

100

100

8192

15

100

100

16384

2

100

100

32768

6

100

100

65535

7

100

100

131072

1

100

100

524288

1

100

100

Ready to use iometer settings file is here: iometer.icf

UPD: Slightly extended list of workloads in iometer settings file is here: iometer2.icf
Thanks to: Tony Voyellm, and http://vmind.ru/

(Моим русскоязычным читателям: пост сделан по просьбе некоторых “нерусскоязычных” людей, которые приходят сюда по ссылкам с поисковиков, на статью о тестировании с помощью IOmeter. К сожалению, параметры тестовых паттернов для IOmeter часто приходится искать по интернету отдельно, в существующем дистрибутиве они не включены, поэтому выложил их сюда).

О измерении производительности.

Любопытный отчет о тестировании систем NetApp с помощью iometer.
Подробно рассмотрены некоторые важные аспекты процесса, в том числе приведен паттерн, на которых проводилось тестирование (симулировалась загрузка типа производимой Exchange 2003).
В целом все довольно схоже с моими результатами, которые я делал в прошлом году, да и выбранная методика в целом похожа.

Часть 1.

Часть 2.

Тестировались FAS3070 и FAS2050.
Обратите внимание, что автор специально готовил фрагментированные разделы, чтобы приблизить результаты к реальным условиям эксплуатации.
Измерены и приведены результаты для различных показателей фрагментации.

Тестирование с помощью IOmeter

Одним из наиболее популярных т.н. “синтетических” тестов является программа 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 и запустить новый цикл.

20/0.170

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.