Тестирование SAS RAID-контроллера Promise SuperTrak EX8650

Введение

Технический прогресс неумолимо движется вперед: жесткие диски за последнее время ощутимо прибавили в размере и скорости работы, а объемы буферной памяти теперь исчисляются не единицами, а десятками мегабайт. Сменились и интерфейсы: привычные параллельные PATA и SCSI практически полностью уступили место на рынке более совершенным (и более быстрым) последовательным SATA и SAS. И если SATA входил на рынок сравнительно постепенно, то с SAS было несколько по-другому. Одно время он присутствовал практически виртуально: были контроллеры, были накопители, но ни те, ни другие не пользовались большой популярностью. И причиной тому не было несовершенство стандарта – с ним-то как раз все в порядке: в отличие от параллельных интерфейсов, где "настольный" PATA и "серверный" SCSI были несовместимы механически, SAS-контроллеры поддерживают подключение SATA-накопителей, да и сам интерфейс стал гораздо удобнее за счет тонких шлейфов, которые гораздо легче располагать в корпусе, не говоря уж о большей пропускной способности. Нет, проблемой были сравнительно высокие цены на SAS-устройства. В сочетании с консервативностью рынка высокопроизводительных архитектур (а это вызывается, опять же, высокой стоимостью модернизации оборудования и не менее высокой ценой ошибки) и отсутствием действительной необходимости в высокой пропускной способности во времена появления SAS-интерфейса это привело к тому, что некоторое время новинка была несколько незаслуженно обделена вниманием.

Но времена менялись, контроллеры дешевели, жесткие диски прибавляли скорости, а существующий парк устаревал. И вот в один прекрасный момент времени все дошло до критической точки, когда SAS начал стремительно завоевывать рынок. Более того, стало выгодно создавать единые системы с одним общим интерфейсом: оказалось очень удобным строить на одних и тех же RAID-контроллерах с интерфейсом SAS как высокопроизводительные системы, так и отказоустойчивые системы хранения данных с использованием жестких дисков с SATA-интерфейсом, обладающих высоким объемом и малой стоимостью. Впрочем, даже здесь намечается переход на SAS. Например, компания Seagate уже анонсировала терабайтный диск с этим интерфейсом, относящийся к серии ES.2, то есть со скоростью вращения пластин 7200 об./мин, что разительно отличается от привычных SAS-накопителей, делающих обычно десять или пятнадцать тысяч оборотов в минуту.

Но вернемся к контроллерам и их тестированию. Нашей привычной тестовой системы из четырех жестких дисков Western Digital Raptor 2 со скоростью вращения 10000 об./мин стало уже явно не хватать для того, чтобы серьезно нагрузить современные многопортовые контроллеры. И итоговые линейные скорости маловаты, и количество операций в секунду явно незначительное, чтобы создать внушительную нагрузку на процессоры контроллеров. Соответственно, желая идти в ногу со временем, мы решились на ее смену. Так что встречайте новую тестовую систему: основа в ней, как несложно будет заметить чуть ниже, все та же, но вот для теста контроллеров мы теперь используем восемь жестких дисков Fujitsu MBA3073RC со скоростью вращения пластин 15000 об./мин, буферной памятью 16 МБ, емкостью 73,5 ГБ и интерфейсом (конечно же!) SAS. Восемь таких красавцев показывают очень и очень высокие результаты, как мы с вами убедимся чуть позже, и способны очень прилично нагрузить контроллеры.

Давайте познакомимся поближе с тем RAID-контроллером, которому выпало почетное право первым попасть на наш обновленный тестовый стенд. Им стал Promise – 8-портовый SAS RAID-контроллер, относящийся к самой современной серии контроллеров этой компании.

Promise SuperTrak EX8650

Появившаяся в начале 2008 года "шестисотая" серия контроллеров Promise стала для компании шагом на новую ступеньку – до этого среди продукции компании не было контроллеров с поддержкой интерфейса SAS. В серии есть контроллеры на любой вкус: полностью аппаратные (то есть, со встроенным процессором) контроллеры с четырьмя, восемью и шестнадцатью внутренними портами, две модели с внешними портами (на выбор: все восемь внешних или четыре внутренних и четыре внешних) и две простые модели, с программной реализацией массивов RAID0 и RAID1. Отличить их очень просто, по обозначению модели: первая цифра означает общее количество портов, вторая – номер серии, третья отвечает за интерфейс (кстати, у всех моделей серии на этой позиции находится "5", то есть все они используют интерфейс PCI Express), а четвертая равна количеству внешних портов. Модели со встроенным процессором относятся к подсерии SuperTrak EX, в то время как программные – FastTrak TX.

Попавший в наши руки SuperTrak EX8650 не является самой старшей моделью, но, обладая восемью портами и 800-МГц процессором Intel XScale 81348, способен удовлетворить самые разные запросы пользователей. Заметьте, как выросли частоты у процессоров, если раньше мы видели значения на уровне 300-500 МГц, то в данной серии даже младшая, 4-портовая модель оснащена процессором с частотой 667 МГц, а уж 16-портовая модель и контроллеры с внешними портами оснащаются аж 1200 МГц процессором. Вполне логично: возросшее быстродействие накопителей требует и большей производительности XOR-процессора, чтобы скорость работы массива не упиралась именно в него. Тем более, что благодаря все тому же прогрессу столь производительные процессоры стоят уже заметно меньше. Естественно, что греются они весьма ощутимо, поэтому на контроллере чип процессора прикрыт весьма массивным радиатором.

С памятью тоже все в порядке – "на борту" находится 256 МБ DDR2 с коррекцией ошибок. Любопытно, что у моделей с внешним портами (и тем же общим количеством портов) памяти вдвое больше – 512 МБ, как и у 16-портового контроллера. Впрочем, что есть, то есть: важен, как говориться, не только размер, но и умение пользоваться.
В остальном, все достаточно привычно: низкопрофильная плата, интерфейс PCI-Express, два разъема SFF-8087 для подключения накопителей (к каждому такому разъему подключается до четырех дисков при помощи специальных интерфейсных шлейфов). Как и полагается серьезным контроллерам, есть возможность установки BBU – Battery Backup Unit, батареи резервного питания кэш-памяти, но в комплект поставки она не входит.

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

RAID0,
RAID1,
RAID1E,
RAID5,
RAID6,
RAID10;
RAID50;
RAID60.

Три последних типа являются двухуровневыми комбинациями массивов двух типов – получается этакий массив из массивов: из RAID1, RAID5 и RAID6 (а какой именно – смотрите по первой цифре двухуровневого массива) создается страйп.

С поддержкой операционных систем все в порядке: со страницы производителя можно скачать драйвера и полезное ПО под Windows, FreeBSD и Linux.

Методика тестирования

Во время тестирования использовались следующие программы:

IOMeter версии 2003.02.15;
WinBench версии 99 2.0;
FC-Test версии 1.0;

Тестовая система была следующей:

корпус Intel SC5200;
системная плата SuperMicro X6DHT-G;
два процессора Intel Xeon 2,8 ГГц;
2 х 512 МБ регистровой памяти DDR PC3200 ЕСС
жесткий диск IBM DTLA-307075 в качестве системного диска;
видеокарта – встроенное видео ATI Rage XL
операционная система Microsoft Windows 2000 Professional SP4

В контроллер были прошиты самые последние на момент тестирования версии BIOS и использовались самые свежие драйвера. Устанавливался он в слот PCI Express x8 на материнской плате.
Для тестирования использовались жесткие диски Fujitsu MBA3073RC, установленные в штатные салазки корпуса SC5200 и закрепленные в них четырьмя винтами за нижнюю грань. Контроллер тестировался с использованием четырех и восьми жестких дисков в следующих режимах:

RAID0;
RAID10;
RAID5;
RAID6.

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

Для сравнения мы будем везде приводить результаты одиночного диска Fujitsu MBA3073RC, полученные на контроллере LSI SAS3041E-R, считая их неким базовым уровнем производительности.

В процессе тестирования мы выставили контроллер в привычный режим максимальной производительности "Perfomance" – в этом режиме отложенная запись и упреждающее чтение разрешены как для контроллера (в его собственную буферную память при ее наличии) так и для самих дисков. И тут нас ожидал непредвиденный и очень неприятный момент, вызванный тем, что контроллер попал к нам на тесты в базовом комплекте, то есть без батареи резервного питания кэша. Дело в том, что хотя он и дает установить в настройках галочку на отложенной записи ("Write back"), на самом же деле выполнять ее без батарейки отказывается напрочь, о чем честно сообщает каждый раз в логах после перезагрузки сервера. В итоге, вся отложенная запись осуществляется силами буферной памяти самих жестких дисков, без участия кэша контроллера. К каким результатам это привело, вы сможете сами увидеть чуть позже. Удостовериться же в том, что он действительно отключен, несложно, достаточно просто посмотреть на диаграмму скорости чтения из кэша накопителя, взятую из отчета IOMark. Обычно мы не используем его для RAID-массивов, но в данном случае он был очень удобен для проверки (тестировался массив RAID0 из восьми дисков):


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

IOMeter: Database

Как всегда, начнем, пожалуй, с наиболее интересного с точки зрения нагрузки на контроллер теста – "Database", с помощью которого мы выясняем способность контроллеров работать с потоками запросов на чтение и запись 8-кБ блоков данных со случайной адресацией. В ходе тестирования происходит последовательное изменение процентного соотношения запросов на запись от нуля до ста процентов (с шагом 10 %) от общего количества запросов и увеличение глубины очереди команд от 1 до 256.

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

Таблицы с результатами тестирования вы можете посмотреть по следующей ссылке:

Результаты IOMeter: Database, RAID1+RAID10
Результаты IOMeter: Database, RAID5+RAID6

Рассмотрим диаграммы с результатами для глубин очереди команд, равных 1, 16 и 256.

Чтобы излишне не засорять диаграммы линиями, мы будем отдельно рассматривать массивы RAID0 и RAID10 и отдельно – требующие вычисления контрольных сумм RAID5 и RAID6.


В данном случае все достаточно просто: на минимальной нагрузке работает лишь отложенная запись, а от количества дисков в страйпе зависит производительность массива на записи. Интересно, что RAID10 на восьми дисках показывает несколько меньшие результаты, чем RAID0 на четырех дисках – зеркальные пары дисков все же чуть хуже с точки зрения производительности, чем одиночный винчестер, хотя и не сильно.


Приятно видеть, как RAID5 и RAID6 идут, что называется, нога в ногу – графики массивов с одинаковым количеством дисков практически сливаются, а это значит, что дополнительная нагрузка в виде подсчета второй контрольной суммы для контроллера фактически незаметна.

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


Увеличиваем глубину очереди и начинаем наблюдать странное. На нагрузках с преобладанием чтения все в порядке – зеркальные массивы RAID10 читают с обоих дисков в зеркале одновременно и в результате ничем не отличаются от RAID0. Но простите, что у нас произошло с масштабированием производительности? Массивы на восьми дисках никак не вдвое быстрее четырехдисковых, как это должно быть в теории, особенно мало их превосходство при преобладании запросов на чтение.

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


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

Зато появление очереди запросов спасло эти массивы на записи: нет, никаких рекордов скорости, но они хотя бы не выглядят сильно хуже одиночного диска.

Интересно, что если четырехдисковые массивы RAID5 и RAID6 практически одинаковы по производительности, то восьмидисковый RAID6 несколько хуже восьмидискового же RAID5. Интересно, что это: маленькое несовершенство прошивки или все же контроллер с трудом справляется с расчетом двух контрольных сумм для восьмидискового массива?


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

И все же, несмотря на все недостатки, оцените уровень производительности: если на четырех Raptor2 мы в принципе не могли добраться до тысячи операций в секунду, то на Fujitsu с его 15000 об./мин и высокой плотностью записи с этим рубежом проблем у четырехдискового массива нет. Для массивов на восьми дисках разговор идет уже о нескольких тысячах операций в секунду.


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

Судя по ощутимому отставанию RAID6 на восьми дисках от RAID5 – все же мощность процессора для такого количества дисков является несколько недостаточной для расчета двух контрольных сумм.

IOMeter: Disk Response Time

Для измерения времени отклика мы в течении десяти минут при помощи IOMeter отправляем на накопитель поток запросов на чтение или запись блоков данных по 512 байт при глубине очереди исходящих запросов, равной единице. Количество запросов, обработанных накопителем, превышает шестьдесят тысяч, так что мы получаем устоявшееся время отклика накопителя, не зависящее от объема буферной памяти.


Если четырехдисковые массивы практически совпадают по времени отклика на чтении с одиночным диском, то все восьмидисковые массивы заметно хуже. То ли контроллеру дольше приходится "вспоминать", на каком диске какой адрес расположен, то ли ему просто не хватает производительности для обработки такого числа запросов, – но маленький недостаток все же есть.


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

Обратите внимание: в то время как четырехдисковые RAD5 и RAID6 практически не различаются, RAID6 на восьми дисках заметно медленнее – снова вылезает недостаточная мощность процессора.

IOMeter: Random Read & Write

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

Результаты, полученные при работе со случайной адресацией данных, рассмотрим в двух вариантах, в соответствии с обновленной методикой. На блоках малого размера построим зависимость количества операций в секунду от размера используемого блока. А на больших блоках вместо количества операций возьмем в качестве критерия производительности скорость в мегабайтах в секунду. Такой подход позволяет оценить работу массивов сразу в двух типичных случаях нагрузки: работа малыми блоками характерна для баз данных, и для нее более важно количество операций в секунду, чем привычная скорость, а вот работа большими и очень большими блоками близка к реальной работе с файлами малых размеров, и здесь уже на первый план выходит именно скорость в привычных мегабайтах в секунду.

Начнем с чтения.

Результаты IOMeter: Random Read, операций/с
Результаты IOMeter: Random Write, МБ/с

Минимальная глубина очереди на корню душит производительность чтения малыми блоками: массивы на четырех дисках чуть хуже одиночного, а восьмидисковые и вовсе заметно отстают. Забавно, но массивы RAID10 оказываются чуть производительнее RAID0.


На массивах с контрольными суммами также четырехдисковые массивы лучше восьмидисковых. Зато приятно радует глаз близкая производительность массивов RAID5 и RAID6 с равным числом дисков.


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


Такая же ситуация и в этой группе массивов – на производительности RAID6 начинает сказываться то, что у него две контрольных суммы, а не одна, а значит, полезный объем считываемых за фиксированное время данных меньше, чем у RAID5.

Так, а что у нас происходит на записи?

Результаты IOMeter: Random Write, операций/с
Результаты IOMeter: Random Write, МБ/с

Запись мелкими блоками напрямую зависит от буферной памяти – соответственно, и результаты прямо пропорциональны числу дисков в массиве. RAID10 вполне закономерно отстает от RAID0 практически ровно в два раза – для зеркальных пар буфер не объединяется, ведь данные надо писать синхронно на оба диска в паре.


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


А вот на больших блоках, где сказывается линейная скорость записи, уже наблюдаются проблемы с масштабируемостью. Впрочем, это мелочи по сравнению с тем, что демонстрирует четырехдисковый RAID10. Его скорость на больших блоках неожиданно становится меньше, чем у одиночного диска. Что интересно, восьмидисковый RAID10 таких проблем не демонстрирует: видимо, ошибка зависит от сочетания нагрузки и количества дисков в массиве.


А вот для массивов с контрольными суммами зависимость еще и от скоростей линейных операций является практически спасением. Есть возможность писать полными страйпами, что значительно снижает издержки контроллера.

Восьмидисковые RAID5 и RAID6 идут практически вровень, хорошо (закономерно) себя ведет и RAID5 на четырех дисках, а вот RAID6 на четырех дисках неожиданно демонстрирует очень маленькие скорости на больших блоках. Да, у контроллера явно проблема с некоторыми типами массивов как минимум на наборах из четырех дисках.

IOMeter: Sequential Read & Write

Ну что ж, пора оценить способности контроллеров в последовательных операциях. В данном тесте на накопители подается поток запросов с глубиной очереди команд, равной четырем. Раз в минуту размер блока данных увеличивается. В итоге мы получаем возможность проследить зависимость линейных скоростей чтения и записи массивов от размеров используемых блоков данных и оценить максимальные достижимые скорости.

Результаты IOMeter: Sequential Read
Результаты IOMeter: Sequential Write

О, а вот по скорости линейного чтения масштабируемость массивов практически идеальная. В итоге от восьмидискового RAID0 мы имеем более 900 МБ/с! Опять же, еще одним подтверждением того, что с линейными операциями все в порядке, является то, что графики RAID10 на восьми дисках и RAID0 на четырех практически слились.

Обратите внимание, что максимальная скорость у многодисковых массивов получается лишь на весьма больших блоках. Так на привычном и стандартном блоке 64 кБ восьмидисковый RAID0 практически не отличается от четырехдискового – он попросту еще не успел набрать скорости. Конечно, никто не ждет, что массивы будут показывать максимальную скорость уже на малых блоках, но все же не забывайте учитывать это явление.

К слову о работе на малых блоках: здесь контроллер несколько разочаровывает, поскольку на совсем малых блоках он проигрывает одиночному диску на LSI.


Все вышесказанное в полной мере относится и к этой группе массивов – честь и хвала компании Promise, в прошлый раз их представитель был не столь идеален.


С записью дела обстоят чуть хуже. С масштабируемостью все достаточно неплохо, но все же восьмидисковый RAID0 за время теста так и не вышел на максимальную скорость – ему явно не хватило блоков еще большего размера. Несколько удивляет и то, что RAID10 на восьми дисках заметно медленнее массива RAID0 на четырех.

Главной же неприятностью стали результаты RAID10 на четырех дисках – они просто никакие. Помните, мы уже выше чуть видели эту ошибку, а теперь вот, похоже, точно знаем, что она была связана с очень низкими линейными скоростями. Интересно, что же такого надо было намудрить в прошивке, чтобы она так избирательно теряла скорость на некоторых массивах?


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

IOMeter: Multi-thread Read & Write

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

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

Результаты IOMeter: Multi-tread Read
Результаты IOMeter: Multi-tread Write

Хм, на одном потоке мы видим нечто непонятно – большинство массивов уперлось в какой-то странный рубеж на уровне порядка 210 МБ/с. Мы честно долго ломали над этим голову, пытаясь найти причину, ведь в тесте на последовательное чтение все было в порядке. А потом нас осенило, и мы полезли в табличку с результатами многопоточного теста. Да-да, в ту самую, что мы привели чуть выше, в ту ее часть, которая обычно лишь бегло просматривается. Догадка оказалась верной: контроллеру просто не хватает глубины очереди. Как только она поднимается – растут и значения. В итоге самые быстрые массивы способны себя проявить в полную силу лишь на больших нагрузках. Так, для RAID0 на четырех дисках зоной для выхода на максимальную скорость становится глубина очереди в четыре запроса, а RAID0 на восьми дисках и при восьми запросах не выходит на максимальную скорость.

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

В целом, ситуация достаточно приличная, лишь RAID6 на четырех дисках неожиданно резко снизил производительность, массивы же других типов снизили скорость менее чем в два раза. Особенно легко пережили второй потоков массивы RAID0 и восьмидисковые массивы всех типов.


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


На записи при одном потоке мы тоже видим упор скорости в непонятный рубеж. Правда, на этот раз цифра еще меньше. Для массивов с контрольными суммами это оказалось просто фатальным – их скорость находится на абсолютно смешном уровне порядка 3 МБ/с, массивы RAID10 тоже работают хуже, чем одиночный диск.

Добавление второго потока для массивов с контрольной суммой не ухудшает, а улучшает положение. Конечно, прирост скорости не бог весть какой, но ведь есть. Что любопытно, RAID0 на восьми дисках также увеличивает производительность, причем весьма заметно. Остальные массивы теряют в скорости, но не так чтобы уж и очень сильно – одиночный диск теряет больше.


Дальнейшее увеличение числа потоков… вызывает рост скорости у всех, кроме RAID10 на четырех дисках (да, снова этот проблемный массив). По всей видимости, несколько потоков создают некий аналог увеличения глубины очереди.

К слову, что касается проблемных массивов: они сохраняют низкие скорости (меньше, чем у одиночного диска) при любых сочетаниях количества потоков и глубины очереди.

IOMeter: Webserver, Fileserver и Workstation

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

Напомню, что в "Webserver" и "Fileserver" эмулируется работа накопителя в соответствующих серверах, в то время как в "Workstation" мы имитируем работу накопителя в режиме типичной нагрузки для рабочей станции, с ограничением максимальной глубины очереди в 32 запроса. Естественно, что "Webserver" и "Fileserver" – не более чем собирательные названия; первый будет весьма схоже эмулировать нагрузку любого сервера, работающего, фактически, только с запросами на чтение, а второй – сервера с преобладанием запросов на чтение, но при этом с определенной, отличной от нуля долей запросов на запись.

Результаты IOMeter: Fileserver
Результаты IOMeter: Webserver
Результаты IOMeter: Workstation
Результаты IOMeter: Workstation, 32 ГБ

В "Fileserver" все весьма неплохо: хорошая масштабируемость, предсказуемые результаты (RAID10 отстает от RAID0 при таком же количестве дисков из-за присутствия в нагрузке запросов на запись).

Любопытно, что массивы из четырех дисков демонстрируют гораздо меньшую зависимость роста производительности от глубины очереди.


У данной группы массивов все столь же неплохо, как и у предыдущей. Объяснить отставание восьмидискового RAID6 от RAID5 несложно – достаточно вспомнить, что у него мы видели некоторые проблемы на записи, связанные с нехваткой производительности процессора, ну и на чтении сказывается то, что у массива меньше свободных дисков из-за необходимости хранить две контрольные суммы.


Вполне закономерно, что все первые места достаются массивам RAID0 и RAID10.


Исчезновение из нагрузки запросов на запись и умение контроллера читать данные с обоих дисков в зеркальных парах приводит к тому, что массивы RAID0 и RAID10 демонстрируют практически одинаковую производительность.

И снова обращает на себя внимание зависимость роста скорости от глубины очереди у массивов на четырех дисках – после определенной глубины очереди рост скорости попросту прекращается.


На этой нагрузке, без операций записи, RAID6 практически вплотную догоняет RAID5.

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


Итоговый рейтинг ровен и красив и демонстрирует, что на чтении важно лишь количество дисков, а от типа массива зависит очень мало.


И снова скорость RAID10 снижают запросы на запись, как и полагается. Но это как раз предсказуемо, а вот почему масштабируемость у массивов неважная – непонятно.


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

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


Поскольку наш рейтинг дает больший вес результатам при малых глубинах очереди, то массивы RAID5 и RAID6 оказываются хуже, чем одиночный диск. Заметьте, что выигрыш остальных массивов не так уж и велик, чтобы говорить о значительном преимуществе.

При работе с уменьшенной до 32 Гб зоной картина принципиально не меняется, лишь увеличиваются продемонстрированные значения скоростей.


В итоге на уменьшенном объеме "быстрые" массивы уже более заметно отрываются от одиночного диска, особенно RAID0 на восьми дисках.

FC-Test

Следующим в нашей программе идет FileCopy Test. На накопителе создается два раздела по 32 ГБ, размечаемые на двух этапах тестирования сначала в NTFS, а затем в FAT32, после чего на разделе создается определенный набор файлов, считывается, копируется в пределах раздела и копируется с раздела на раздел. Время всех этих операций фиксируется. Напомним, что наборы "Windows" и "Programs" включают в себя большое количество мелких файлов, а для остальных трех ("MP3", "ISO" и "Install") характерно меньшее количество файлов более крупного размера, причем в "ISO" используются самые большие файлы.

Хотелось бы обратить ваше внимание на то, что тест копирования не только говорит о скорости копирования в пределах одного накопителя, но и позволяет судить о его поведении под сложной нагрузкой. Фактически, во время копирования накопитель одновременно работает с двумя потоками, причем один из них на чтение, а второй на запись.
Поскольку результатов довольно много, то мы будем подробно рассматривать лишь значения, достигнутые на наборах файлов "Install", "ISO" и "Programs" в NTFS, являющихся более характерными для обычного использования массивов. Остальные результаты, вы, прижелании, можете узнать из таблиц ниже:

Результаты FC-Test: NTFS
Результаты FC-Test: FAT32

Если SAS-диски на контроллере LSI всегда показывают в этом тесте низкую скорость записи, и мы к этому уже привыкли, то вот результаты Promise без батарейки откровенно разочаровывают. Так, о результатах RAID5 и RAID6 говорить просто грустно, настолько они малы. Впрочем, один интересный момент они все же дают: обратите внимание, что максимальная скорость достигнута не в "ISO", где создаются самые большие файлы, а в "Install", а это значит, что эти массивы очень сильно зависят от размера файлов, причем эта зависимость не является прямо пропорциональной.

Обратите внимание, что RAID10 на восьми дисках проигрывает во всех случаях массиву RAID0 на четырех, в полном соответствии с тестом на последовательное чтение. Не так чтобы это отставание было ощутимым, но все же оно заметно.


А вот чтение явно уперлось в то, что мы видели на многопоточном тесте – малые скорости при малой глубине очереди. В итоге получилось весьма забавно: на больших файлах большинство массивов работает с одинаковыми скоростями, заметно отстает лишь RAID5 на четырех дисках.

При снижении размера файлов скорости ощутимо падают. Причем особенно заметно это на массивах из восьми дисков – их производительность ниже, чем у одиночных дисков. А самым быстрым массивом неожиданно стал RAID10 из четырех дисков. Странно, очень странно.


А вот на копировании в пределах раздела все почти прилично. "Почти" – потому что очень сильно сказываются проблемы с записью на массивах RAID5 и RAID6, вызванные отключенным кэшем контроллера. Да и RAID10 на четырех дисках очень уж медлителен и проигрывает даже одиночному диску – похоже, что у него тоже проблемы с записью.


Картина повторяется и на копировании с раздела на раздел – только скорости еще уменьшились, да неожиданно плохо на больших файлах выступил еще и восьмидисковый RAID10. Впрочем, говоря откровенно, результаты массивов RAID0 также не радуют – их преимущество над одиночным диском весьма незначительно. Эх, а казалось бы, всего-то нет батарейки, какая малость…

WinBench 99

Ну и в завершение – привычные графики чтения в "WinBench 99".

График чтения 1 диска Fujitsu_MBA3073RC на LSI

Графики чтения RAID-массивов на Promise SuperTrak EX8650:

График чтения RAID0, 4 диска
График чтения RAID0, 8 дисков
График чтения RAID10, 4 диска
График чтения RAID10, 8 дисков
График чтения RAID5, 4 диска
График чтения RAID5, 8 дисков
График чтения RAID6, 4 диска
График чтения RAID6, 8 дисков

Сравним накопители по продемонстрированным скоростям чтения в начале и конце получившихся разделов:


Скорости чтения весьма хорошо соотносятся с теорией, кроме одного момента: восьмидисковые массивы как-то весьма мало отличаются по скорости от RAID0 на четырех дисках.

Подведение итогов

Ну, что же, попробуем подвести итог. Если говорить совсем кратко, то в целом Promise SuperTrak EX8650 – достаточно неплохой контроллер, но использовать его без батареи резервного питания кэша можно только в том случае, если скорость записи на массивы для вас абсолютно не важна. Если же говорить чуть подробнее, то в достоинствах этой модели окажутся весьма приличные результаты на серверных нагрузках, хорошее чтение зеркальных массивов и достаточно хорошая реализация работы в RAID5 и RAID6.
К сожалению, не обошлось и без недостатков: так, нас достаточно сильно огорчила не лучшая масштабируемость массивов из большого числа дисков, разочаровали низкие скорости работы с файлами, вызванные тем, что контроллер лучше работает при большом количестве запросов в очереди, и расстроило наличие необъяснимого снижения скорости записи на некоторых сочетаниях типа массива и количества дисков в нем. Так что для компании Promise время почивать на лаврах еще не настало, им есть над чем поработать.
Со своей стороны мы обязуемся повторить тесты контроллера Promise SuperTrak EX8650, когда в нашу глушь таки привезут BBU для него…

Другие материалы по данной теме

Сравнительное тестирование RAID-контроллеров HighPoint RR3220 и Promise EX3850
Сравнительное тестирование RAID-контроллеров Adaptec
Тестирование RAID-контроллера 3Ware 9650SE