Производительность и качество работы информационной инфраструктуры, особенно построенной по современной “облачной” архитектуре, в значительной степени зависит от подсистемы хранения данных (СХД). В отличие от вычислительной мощности и объемов памяти, наращиваемых путем добавления серверов, хранилище значительно сложнее поддается масштабированию, что заставляет особенно тщательно подходить к подбору его конфигурации.

Задача выбора конфигурации СХД осложняется тем, что помимо традиционных RAID-массивов и сетей хранения данных (SAN) в последнее время возник целый ряд новых способов организации СХД, с применением гибридных и SSD-носителей, технологий многоуровневого кэширования и трансляции адресов, которые радикально меняют не только скоростные и емкостные характеристики, но и саму функциональность СХД.

В области тестирования ханилищ данных отраслевым, всеми признанным стандартом является бенчмарк SPC (Storage Performance Council), в частности SPC-1, который оценивает производительность системы в IOPS - количестве операций ввода-вывода в секунду. Результаты независимых тестов оборудования различных производителей регулярно публикуются на сайте SPC http://www.storageperformance.org/results/benchmark_results_spc1. К сожалению инструментарий для проведения тестов SPC доступен только членам данной организации, что делает практически невозможным повторение теста с конкретной конфигурацией или оценку влияния на производительность СХД, других элементов инфраструктуры или характера нагрузки, свойственного конкретному потребителю.
В то же время зависимость производительности от характера нагрузки даже для классических СХД типа “дисковый массив” настолько сильна, что для некоторых специфических сфер применения, таких как видеонаблюдение или архивация, выпускаются специализированные СХД, оптимизированные под эти профили нагрузки.

Таким образом, для оценки эффективности прменения той или иной архитектуры СХД или прогноза ее поведения в той или иной конфигурации совместно с другими компонентами инфраструктуры под различными видами нагрузки, требуется возможность тестирования непосредственно потребителем.

Для платформы Windows cуществует множество бенчмарков, ориентированных как на потребности одиночного пользователя-энтузиаста, тестирующего одиночный диск среди прочих характеристик компьютера, так и специализированных программ диагностики. Список кросс-платформенных или работающих исключительно под Unix тестов значительно короче. Наиболее известны утилиты IOZone, Fio и IOMeter. Утилита IOMeter, первоначально разработанная Intel, а затем переданная open source-сообществу, позволяет не только гибко варьировать профиль создаваемой нагрузки, но и обеспечивает возможность проведения распределенного тестирования, когда нагрузка генерируется сразу несколькими машинами, что позволяет приблизить условия теста к реальному информационному пространству. Подробно работа с IOMeter описана, например, на http://itband.ru/2010/01/iometer Результаты тестирования в IOMeter часто фигурируют в обзорах новых накопителей, указываются для сравнения характеристик интернет-магазинами и даже непосредственно производителями накопителей, используются для анализа работы СХД в ведущих отечественных компаниях-интеграторах (http://blog.trinitygroup.ru/search/label/iometer http://habrahabr.ru/post/209422/ http://aboutnetapp.livejournal.com/8525.html) Наиболее часто встречаются результаты синтетических бенчмарков, как правило с размером блока 4кб, применяющиеся для сравнения предельных характеристик СХД при вырожденных профилях нагрузки: 4krr — случайное чтение, 4ksr — последовательное чтение, 4krw — случайная запись, 4ksw — последовательная запись. К сожалению результаты таких тестов мало что говорят в поведении той же самой СХД под реальной нагрузкой, в которой одновременно присутствуют и чтение, и запись, часть запросов имеет случайный характер, часть — последовательный. Один из ведущих производителей СХД, компания NetApp, даже утверждает, что единственным правдивым бенчмарком является тестирование системы на реальной нагрузке и бесплатно предоставляет для этого свои СХД потенциальным заказчикам. Однако синтетические тесты все же способны симулировать реальную нагрузку, смешивая разнотипные операции ввода-вывода в определенных пропорциях, характерных для конкретного приложения. Для тестирования с помощью IOMeter широко применяются паттерны Intel и StorageReview, создающие нагрузку, специфичную для следующий областей применения: файловый сервер, базы данных, веб-сервер, журнал транзакций СУБД и веб-сервера, почтовый сервер, система поддержки принятия решений, потоковое видео и файл подкачки ОС. Учитывая специфику применения СХД в среде UNIX, наиболее интересными типами реалистичной нагрузки для нас будут сервер баз данных, веб-сервер и особенно файловый сервер для средств САПР и научных расчетов.

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

1. оценка производительности хранилища в целом

2. влияние на его производительность отдельных характеристик и режимов работы

3. выработка рекомендаций по выбору оптимальной конфигурации СХД и настроек ее компонентов, сетвого оборудования и рабочих станций для конкретной типа нагрузки.

Для того чтобы представить, какие факторы могут оказывать влияние на результаты измерений и производительность при работе с реальными приложениями, на рис. 1 представлена блок-схема пути прохождения данных в стенде для традиционного измерения производительности диска и в системе с сетевой СХД. Для простоты изображена СХД на базе ОС Linux, в которой отсутствуют такие блоки, как менеджер томов LVM и многоуровневвый гибридный кэш, характерный для систем NetApp/Oracle. Также не рассматриваются варианты с системами виртуализации хранения, при которых в схему добавится еще один слой, сопоставимый по сложности с сервером СХД.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Традиционно, в сравнительных отчетах о производительности дисков детально описывается спецификация испытательного стенда, однако в случае сравнения нескольких различных СХД в нескольких различных рабочих средах как правило отсутствует возможность создания нагрузки с помощью идентичных клиентов. Более реальна ситуация, когда на одной площадке в качестве нагрузки выступает, например, десктоп с 4 ядрами и 8 Гб памяти, а на другой - blade-сервер с 12 ядрами и 48Гб памяти. При работе на машинах различной конфигурации Iometer по умолчанию устанавливает количество генераторов нагрузки (Worker) равным количеству ядер в нагружающей системе. В связи с этим было бы разумно принудительно задавать количество worker равным количеству ядер на самом слабом клиенте, однако анализ журнала работы Iometer показывает, что при наиболее распространенном режиме тестирования (одно блочное устройство или файл за раз) задействуется один единственный Worker. Чтобы не анализировать журнал на предмет количества задействованных Workers каждый раз — при формировании условий теста будем принудительно использовать один генератор нагрузки.

Обычно тестеры стремятся получить результат для установившегося режима (sustain rate) нагрузки, улучшая условия измерения путем увеличения времени тестирования и отбрасыванием результатов за «время разогрева» - период, в течение которого заполняются имеющиеся в системе буфера, кэши и поток ввода-вывода приходит в равновесное состояние. При этом результаты измерений величин IOPS и скорости передачи данных указываются с точностью до сотых долей, т. е. в том виде, в каком они выдаются на экран. Помимо демонстрации результатов тестов в графическом интерфейсе, IOMeter создает файл, где детально указаны примененные режимы нагрузки и полученные значения представлены с еще более высокой точностью. Наблюдение за результатом во время тестирования показывает, что усредненное за время теста значение перестает ощутимо меняться через несколько минут после начала тестирования. (за исключением особых случаев с длительным сбросом буферов), поэтому далее тестирование будет проводиться с длительностью 10 минут и периодом разогрева 15 секунд. Попробуем провести в данных условиях несколько измерений производительности в IOPS дискового массива RAID0 из 3 SAS-дисков при одном и том же профиле нагрузки (4krw). Полученные значения — 43400, 43743, 44315, 44542 (среднее значение 44000) Очевидно, что при разбросе показаний более чем в 1000IOPS бессмысленно приводить результаты с точностью до сотых долей. Гораздо важнее иметь оценку точности измерений, поэтому далее каждое измерение будет производиться минимум дважды и приводиться будут оба результата с отбросом дробной части.

Одним из важнейших параметров теста производительности является количество одновременных операций ввода-вывода (в интерфейсе IOMeter он называется «# of outstanding IO», в файле отчета - «queue depth», в опубликованных результатах тестов чаще употреблют термин «глубина очереди»). Обычно для тестирования выбирается значение, характерное для конкретного типа нагрузки (например, 4 - простое приложение, 256 - высоконагруженная база данных), либо, для получения более полной картины, параметр перебирается от 1 до 256 с удвоением значения на каждом шаге. Область применения СХД подразумевает высокое количество параллельных обращений от множества клиентов.

 

Приведенные выше результаты измерения производительности локального хранилища (RAID0 из 3 дисков SAS) с увеличением количества потоков от 1 до 256 показывают, что увеличение количества потоков выше 128 практически не приводит к увеличению результатов, хотя в случае последовательной записи может вызывать и падение производительности. Оценивая производительность сетевой СХД, также имеет смысл учитывать следующую рекомендацию по настройке NFS-серверов: количество параллельных потоков nfs (экземпляров демона nfsd) должно быть не меньше, чем количество процессов на рабочих станциях в сети, одновременно обращающихся к диску. Видно, что значение 128 хорошо подходит для моделирования активности в сети из ~100 машин, на каждой из который имеется приложение, активно работающее с файлом, расположенным на СХД, поэтому для дальнейших измерений целесообразно принять «# of outstanding IO» равным 128.

Итак, мы определили интересующий нас набор профилей нагрузки и условия проведения измерений. Анализируя приведенную выше схему пути прохождения данных от приложения к непосредственно накопителям, мы видим, что первым звеном, влияющим на результаты теста является файловая система и ее кэш. Для исключения этого влияния IOMeter позволяет обращаться напрямую к блочному устройству, но к сожалению при работе с сетевой СХД в наиболее интересном для нам режиме NFS-сервера это невозможно — приложение вынуждено работать с файлом iobw.tst (работа СХД в режиме экспорта отдельных блочных устройств по протоколам iSCSI, FC, FСoE является темой отдельного исследования). При оценке производительности дисковой подсистемы сетевых СХД для исключения влияния кэша обычно, рекомендуют проводить измерения, используя тестовый набор, заведомо не умещающийся в кэш. К сожалению в Linux (в частности RedHat Enterprise Linux 4-6) под кэш файловой системы отводится вся свободная оперативная память и отсутствуют внятные механизмы его лимитирования, в результате, чего на современных машинах, объем памяти которых достигает 256Гб, могут возникнуть проблемы с созданием тестового файла надлежащего размера. Кроме того, в Linux существуют возможность принудительного сброса кэша, например, следующая команда заставляет сбрасывать кэш каждые 5 секунд: while [ a = a ]; do echo 3 > /proc/sys/vm/drop_caches ;sleep 5; done

Попробуем оценить эффективность этих мер на тестовой машине следующей конфигурации: 24 ядра, 32Гб оперативной памяти, аппаратный RAID0 из трех дисков с интерфейсом SAS, варьируя размер тестового файла от заведомо укладывающегося в кэш до заведомо не укладывающегося.

 

	4krr	4ksr	4krw	4ksw
1GB
1GB со сбросом	7476-7524	10585-11136	142580-143990	146365-146454
10GB	750-754	11007-11009	80622-81424	115403-115951
10GB со сбросом	83-84	11084-11088	7612-8282	27984-28114
300GB	272-389	14695-15703	44573-44735	97956-96958
300GB со сбросом	39-40	16827-16993	4682-4988	27445-27453

 

Практически одинаковые показатели для случайного и последовательного режима доступа для малого размера тестового файла говорят о том, что устройство не имеет перемещающихся головок, т. е. речь идет либо об SSD-накопителе, либо о Flash-ускорителе, либо о полной буферизации в оперативной памяти или RAID-контроллере. Зная состав тестовой машины, можно утверждать, что речь идет об оперативной памяти, причем принудительный сброс кэша не снижает результаты. Это неудивительно, если учесть, что при производительности кэша порядка 220000 IOPS (замерено путем генерации тестового файла размером 4Гб на устройстве tmpfs), данный тестовый набор полностью закачивается в кэш за период между двумя сбросами. Увеличение резмера тестового файла весьма незначительно влияет на оценку последовательных режимов доступа. В то время, как сброс кэша сразу «пробивает» последовательную запись и гораздо эффективнее воздействует на измерение при случайных режимах доступа, чем рост тестового файла. Таким образом дальнейшие измерения производительности мы будем производить с принудительным сбросом кэша вышеописанным способом. Это особенно полезно в случае тестирования систем, находящихся под реальной нагрузкой, где могут возникнуть сложности с поиском свободного пространства, вдесятеро превышающего размер кэша и в случае несопоставимых по размеру оперативной памяти клиентов.

 

Следующее усложнение пути прохождения данных происходит при переходе к сетевому доступу к СХД. Теперь необходимо дополнительно принимать во внимание влияние следующих факторов:

• настройки NFS-клиента

• настройки транспортного протокола (в подавляющем большинстве случаев TCP/IP) клиента

• настройки и конфигурацию сетевого оборудования

• настройки транспортного протокола сервера

• настройки NFS-клиента

В Linux клиентская часть NFS позволяет настраивать размер блока NFS, кэширование атрибутов, обновление служебной информации о файлах, выбирать несущий протокол tcp или udp и режим доступа синхронный/асинхронный. В следующих тестах мы рассмотрим влияние этих параметров на производительность, используя следующую тестовую инфрастуктуры: генератор нагрузки — сервер с 24 логическими ядрами, 48Гб памяти и сетевой интерфейс 1Гбит/с. NFS-сервер - сервер с логическими 24 ядрами, 32Гб памяти, сетевым интерфейсом 1Гбит/с и дисковым массивом RAID0 из 3 дисков с интерфейсом SAS. Операционные системы и сервера и клиента — Linux.

Ожидается, что асинхронность вывода может улучшить производительность записи, т.к. в этом режиме приложение не ожидает ответа СХД перед тем, как разместить следующий запрос. Также ожидается, что результаты доступа по сети не могут превышать показатели локального доступа к тому же хранилищу.

 

Чтобы убедиться в валидности получаемых результатов оценим, насколько эффективно нейтрализует влияние кэшей изменение размера тестового файла и команды принудительного сброса, выполняемые на стороне клиента и сервера и сравним с результатами локального запуска IOMeter на файл-сервере.

 

№	Режим измерения	4krr	4ksr	4krw	4ksw
1	10Gb local nodrc	750-754	11007-11009	80622-81242	115403-115951
2	10Gb local drc	83-84	11084-11088	7612-8282	27984-28114
3	10 Gb sync nfs nodrc	13175-25794	25443-25902	1919-2009	4526-4613
4	10Gb sync nfs drc	25408-25489	25476-25663	1936-2000	4611-4640
5	10Gb async nfs nodrc	25077-25229	25224-25440	1962-2023	4610-4684
6	10Gb async nfs drc	25554-25662	25740-25719	1976-2038	4582-4739
7	10Gb server sync async nfs drc	458-905	4258-7656	764-779	781-783
8	300Gb local nodrc	272-389	14695-15703	44573-44735	96958-97956
9	300Gb local drc	39-40	16827-16993	4682-4988	27445-27453
10	300Gb sync nfs nodrc	532-31?	4293-1362?	1179-1180	9799-9868
11	300Gb sync nfs drc	44-78	11935-13956	1065-1145	7872-9834
12	300Gb async nfs nodrc	3254-3264	10747-11238	992-1123	4902-5301
13	300Gb async nfs drc	198-3308?	11819-13011	1052-1055	3443-4715
14	300Gb async nfs dualdrc	285-285	4478-4587	133-134	2949-2997
15	300Gb sync nfs dualdrc	284-285	4399-4445	129-134	2864-2891

 

Последовательная запись в тестах 1 и 8 показывает аномально высокий результат, сопоставимый с производительностью оперативной памяти. Аналогичные замеры со сбросом кэша (2, 9) приводят к более реалистичным значениям, причем не зависящим от размеров тестового файла.

Сравним результаты случайного и последовательного чтения в случаях 3, 4, 5 и 6: отсутствие разницы в результатах говорит о том, что носитель имеет немеханическую природу, т. е. используется кэш.

Также обращает на себя внимание совпадение результатов 3, 4, 5, 6 случайного и последовательного чтения около 25500 IOPS - в пересчете на абсолютные показатели это составляет 102МБ/с или 85% от теоретической пропускной способности Gigabit Ethernet. Учитывая, что сетевой доступ (3, 4, 5, 6) показывает более высокий результат, чем локальный (1, 2), можно считать что в данном случае тест пытался измерять не столько производительность диска, сколько производительность кэша, ограниченную производительностью сетевого интерфейса. Дальнейший интерес могут представляют тесты на более производительных интерфейсах 10Gbit Ethernet или IPoIB, либо тесты с использованием агрегирования интерфейсов на стороне сервера при увеличенном количестве клиентов.