SATA RAID-контроллер 3Ware 8500

Введение

Продолжаем разговор о многоканальных SATA RAID-контроллерах. На этот раз, на тестовый стенд к нам угодил экземпляр от 3Ware, фирмы, чьи контроллеры всегда радовали нас своими результатами. Однако, доброе имя фирмы не является абсолютной гарантией совершенства нового изделия, хотя и очень повышает вероятность удачной разработки. Поэтому контроллеру 3WARE 8500-8 Escalade пришлось пройти все положенные испытания на стенде.

Что же представляют собой контроллеры серии 8500? Очевидно, что при разработке этих контроллеров компания 3Ware решила не мудрствовать лукаво и просто оснастила свои ATA RAID-контроллеры мостами-трансляторами от Marvell. Линейка контроллеров Escalade 8500 состоит из трёх моделей, поддерживающих 4, 8 и 12 дисков соответственно. Нам достался восьмиканальный контроллер (количество каналов указывается в последних цифрах названия), но так как дисков у нас было только четыре, то мы тестировали его в режиме четырёхканального.

Контроллер

Контроллер 3Ware8500-8 может поддерживать до восьми Serial ATA/150 устройств и позволяет объёдинять их в массивы уровней 0, 1, 5, 10 и JBOD. Шина обмена с компьютером – 64-х разрядная PCI, работает на частоте 33 МГц. Также на контроллере мы видим два чипа SRAM-памяти, по 1,125 МБ каждый, и, следовательно, объём кэш-памяти контроллера составляет 2,25МБ.

Внешний вид контроллера:

Как мы можем видеть, лицевая сторона контроллера 3Ware8500-8 Escalade практически полностью занята различными микросхемами, начиная от чипа контроллера и заканчивая памятью и BIOSом. Места настолько мало, что даже SATA разъемы приходится устанавливать в два слоя. На фотографиях, правда, разглядеть это нельзя, но уж поверьте – их там не четыре, а восемь. Однако, можно увидеть, что рациональное распределение компонентов по плате позволило оставить место еще для четырех разъемов SATA и соответствующих микросхем-контроллеров и при этом сделать контроллер достаточно компактным (Half-length).

Основные параметры:

Кроме самого контроллера в комплектацию входят CD с драйверами, описание и, что не может не радовать, восемь кабелей SATA150. В общем, первое впечатление о контроллере 3Ware8500-8 Escalade благоприятное, но давайте посмотрим его в деле.

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

Тестовая система

корпус - Intel SC5200
материнская плата – Intel SHG2;
процессор - 2 x Intel Xeon 2.8/400FSB;
память - 2 x 512MB DDR SDRAM PC2100 ECC Registered;
винчестер - IBM DTLA 307015;
видеокарта – onboard ATi Rage XL;
операционная система - Windows 2000 Pro SP4.

Использовались следующие тесты:

WinBench 99 2.0
IOMeter 2003.02.15

В Winbench99 на логическом диске создавался один раздел на весь объём диска. Тесты Winbench проводились по семь раз, выбирался лучший показанный результат.

Для сравнения скорости работы винчестеров при помощи теста IOMeter использовались паттерны Fileserver & Webserver.


Эти паттерны призваны измерить производительность дисковой подсистемы при нагрузке, типичной для file- и web-серверов.

Паттерн Workstation, используемый нами, создан нашим автором Романовым Сергеем aka GReY на основании статистики обращений к диску при работе различных приложений, приведённой в описании SR Testbed3. Статистические данные собраны на файловой системе NTFS5 в режимах работы Office, Hi-End и Boot-up.


Этим паттерном мы будем руководствоваться для оценки привлекательности винчестеров для обычного Windows-пользователя.

Ну и, наконец, была проверена способность винчестеров работать с Sequential-запросами переменного размера на чтение/запись и скорость дисков в паттерне Database, имитирующем работу дисковой подсистемы с SQL-подобными запросами.

В контроллер был прошито firmware 7.6.3, использовались драйвера из того же набора (7.6.3). Для контроля состояния массива и для синхронизации массивов использовалась программа 3DM Disk Management.

Контроллер устанавливался в слот PCI-X/133МГц (хотя контроллер поддерживает только PCI64 33МГц).
Массивы создавались на каналах 1-4, чтобы имитировать работу контроллера 8500-4. Дело в том, что за работу с дисками отвечают чипы AccelerATA, причём каждый отвечает за четыре диска). И если мы последовательно заполняем каналы 1-4, то мы нагружаем только один из чипов AccelerATA. Если же использовать по два канала на каждом чипе, контроллер будет работать быстрее, но... это будет не совсем корректно, ведь мы "якобы" тестируем 8500-4 (ну не было у нас тогда 8 дисков Raptor...).

Диски WD360GD (Raptor) устанавливались в штатные салазки корпуса SC5200 и крепились четырьмя винтами за нижнюю грань.


При выполнении основной программы тестирования отложенная запись для дисков разрешалась, а режим работы кэширования запросов драйвером (WriteBack и WriteThrough) менялся по необходимости.

Результаты тестов

По уже сложившейся традиции начнем наш обзор с тестирования работы со смешанными потоками запросов:

IOMeter: паттерн Database

В этом паттерне мы проверяем способность контроллеров работать со смешанным потоком запросов на чтение и запись блоков данных объемом 8КБ со случайным адресом. Изменяя соотношение запросов на чтение и запись, мы можем выявить качество их сортировки драйвером контроллера.
Начнем с самой большой таблицы - результатов работы контроллера в режиме WriteBack:


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

При линейной нагрузке, в начале графика (режим RandomRead), все массивы показывают очень близкие скорости. Однако, массивы, использующие зеркалирование, RAID1 и RAID10, демонстрируют свое превосходство в скорости благодаря технологии Twinstor, которая позволяет не просто чередовать запросы на чтение между двумя дисками зеркальной пары, но делает это «умно», определяя диск, который обработает этот запрос быстрее, по текущему положению головок чтения/записи (а точнее по истории запросов…).
С ростом числа запросов на запись (в данном случае с ростом вероятности появления такого запроса) скорость работы одиночного диска возрастает. Соответственно количеству дисков в массиве, растет и скорость RAID0, но пропорциональность наблюдается только в режимах с большой долей запросов на запись. Скорости массивов RAID1 и RAID10 тоже растут, но медленнее, а скорость массивов RAID5 снижается, так как запросы на запись очень сильно замедляют их работу, и чем больше доля запросов на запись, тем «тяжелее приходится» контроллеру. Впрочем, при большой доле запросов на запись контроллер даже чуть ускоряется – интересный момент.

Увеличение нагрузки слегка меняет картину распределения скоростей. Зеркальные массивы резко ускоряются в режимах с большой долей запросов на чтение, но теряют в скорости по мере роста доли запросов на запись. Происходит это потому, что скорость чтения запросов со случайным адресом в этих массивах очень высока благодаря работе технологии Twinstor. В идеале, можно получить двукратный выигрыш в скорости чтения.
Тем не менее, массив RAID1 всегда быстрее одиночного диска, а массив RAID10, в свою очередь, быстрее массива RAID0 из двух дисков во всех режимах. В принципе, массивы RAID0 должны быть самыми быстрыми, но, как мы уже объясняли в предыдущем обзоре, случайный выбор дисков при чтении в этих массивах может приводить к перегруженности одних винчестеров и простаиванию других. В то же время, в зеркальных массивах используется чередование запросов по дискам (с учётом статистики обращений), которое обеспечивает равномерную загруженность дисков. Поэтому, при небольшой доле запросов на запись (менее тридцати процентов) массив RAID1 оказывается даже быстрее массива RAID0 из двух дисков, а массив RAID10 обгоняет массивы RAID0 из трех и четырех дисков при доле запросов на запись менее сорока и двадцати процентов соответственно. И, конечно, мы не могли не обратить внимание на небольшой провал в скорости при десяти процентах запросов на запись у массивов RAID0 из трех и четырех дисков. Как мы можем вспомнить, подобный провал уже наблюдался в обзорах контроллеров Intel SRCS14L и Promise FT S150 TX4. Похоже, что и в контроллере 3Ware8500-8 обработка алгоритма отложенной записи отнимает время, которое не компенсируется оптимизацией обработки десяти процентов запросов на запись.

Мы видим, что характер графиков массивов RAID0 повторяет график одиночного диска, что говорит о том, что StorSwitch справляется с сортировкой и передачей запроса на соответствующий винчестер прекрасно. Однако, провалы в графиках массивов RAID0 из трех и четырех дисков в точке с десятью процентами запросов все равно присутствуют. В режиме RandomRead (случайное чтение) и при достаточном количестве запросов в очереди, влияние Twinstor на зеркальные массивы RAID1 и RAID10 максимально, поэтому их скорость превышает скорость работы RAID0 массивов из двух и четырех дисков соответственно.

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


Для сравнения скорости всех RAID-массивов при различных схемах кэширования построим уже ставшую привычной таблицу, в каждой ячейке которой содержится результат деления скорости контроллера в режиме WB на скорость контроллера в режиме WT. Таким образом, по величине содержащегося в ячейке числа мы сможем судить об эффективности работы WB-кэширования в каждом конкретном режиме. Если число будет меньше единицы (такие числа подкрашены красным цветом), то WB-кэширование здесь вредно, а если число будет больше единицы (такие числа подкрашены синим цветом), то WB-кэширование привело к увеличению скорости, т.е. оно полезно. Если же в ячейке мы видим число "1.0", то это означает, что для этого режима что WB, что WT-кэширование одинаково полезны.


Очевидно, что во всех режимах работы массивов включение WB-кэширования в BIOS-е контроллера приводит к увеличению скорости. Даже в режиме RandomRead, при полном отсутствии запросов на запись, ни разу не наблюдается уменьшения скорости, а в режиме RandomWrite скорость увеличивается, в максимуме, шестикратно. Уменьшение скорости наблюдается только в массиве RAID5 при почти недостижимых в реальной жизни очередях в 256 запросов.

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

Массив RAID0 стабильно демонстрирует увеличение скорости при включении кэширования и с ростом числа запросов на запись (достигая шести раз с небольшим). С увеличением числа запросов в очереди разрыв между скоростями в режимах WriteBack и WriteThrough снижается, однако преимущества WB-кэширования обнаруживается всегда, кроме режима RandomRead, где, из-за отсутствия запросов на запись, алгоритмы отложенной записи не влияют на скорость!

Значительное влияние WB-кэширования проявляется при одиночных запросах. Увеличение скорости достигает 137 %. Однако, с ростом очереди, эффективность его резко снижается, а при очередях в 256 запросов WB-кэширование даже приводит к замедлению работы. Потери в скорости достигают десяти процентов.

Поведение эффективности WB-кэширования такое же как и в массиве RAID0, однако по величине эффект от WB-кэширования оказывается меньше и достигает всего (!) 245-ти процентов.

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

IOMeter: паттерны Sequential Read&Write

Тестирование контроллера в режиме последовательного чтения/записи. Как и в прошлом паттерне, тестирование проходило в режиме WriteBack, но, для изучения оптимизации работы в этом режиме, часть массивов мы проверили в режиме WriteThrough. На массив при помощи программы IOMeter подаётся поток запросов на чтение/запись с глубиной очереди команд, равной четырём. Раз в минуту в тесте меняется размер блока данных, так что после окончания теста мы получаем зависимость скорости линейного чтения или записи от размера блока данных. Полученные результаты (зависимость скорости прокачки данных контроллером от размера блока данных) сведены в таблицы.


Для лучшего представления, RAID-массивы разобьем на две подгруппы:


Преимущества RAID–массивов с большим количеством винчестеров начинают сказываться только при больших размерах запрашиваемого блока данных, то есть когда объём запроса достаточно велик, чтобы винчестеры начали работать одновременно (параллельно).


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

Посмотрим, как ведет себя контроллер в режиме WriteThrough и сравним с предыдущими результатами.

Как и следовало ожидать, при отсутствии запросов на запись, различия в результатах очень незначительны. Отключение отложенной записи почти не влияет на поведение графиков.

Переходим к последовательной записи:


А теперь в виде графиков:


А вот и первые потери сегодня. Скорость массива RAID0 из четырех дисков бессовестно занижена при больших запросах. По-видимому, при таких объемах запроса контроллеру не хватает кэш-памяти. Вообще-то ситуация, когда у одного диска объём кэш буфера в четыре раза больше, чем у контроллера выглядит, мягко говоря, странной...


Скорость массива RAID1 почти совпадает со скоростью одиночного диска, а скорость массива RAID10 немного меньше скорости массива RAID0 из двух дисков. Со скоростью записи на массивы RAID5 ситуация несколько сложнее. При малых размерах блока скорость записи на массивы RAID5 выше, чем на одиночный диск или зеркало – срабатывает R5 Fusion (“склеивание” запросов на запись в кэше контроллера). Но при большом размере запроса места в кэше контроллера начинает не хватать…

Отключение отложенной записи приводит к значительной потере в скорости во всех массивах и особенно это критично для RAID5!

IOMeter: Fileserver&Webserver

Паттерны, имитирующие работу дисковой подсистемы файл- и веб-сервера.

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


Наличие всего двадцати процентов запросов на запись приводит к тому, что все массивы демонстрируют очень неплохие результаты, правда, провал на графике массива RAID1 при глубине очереди в 64 запроса не очень понятен.

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


Особенно хочется отметить скорость зеркальных массивов. Благодаря Twinstor массив RAID10 занял почетное второе место, а RAID1 находился бы выше, если бы не уже упомянутый провал на графике.

Режим WriteBack увеличивает скорость работы всех массивов по сравнению с WriteThrough, но незначительно, так как количество запросов на запись, работу с которыми и оптимизирует отложенная запись, в этом тесте невелико (двадцать процентов).


Посмотрим, насколько изменятся результаты в паттерне Webserver, который характерен отсутствием запросов на запись.

Графики массивов RAID0, по сравнению с Fileserver, качественно не изменились, а скорость массивов RAID5 значительно возросла, так как паттерн Webserver, в котором отсутствуют запросы на запись, - это оптимальный для них режим работы. При глубине очереди в 64 запроса не только остался провал в графике массива RAID1, но и появилась «полка» на графике массива RAID10.

В рейтинговой системе, которую мы построили по тем же правилам, что и для Fileserver, места распределились следующим образом:


Массив RAID10 занял-таки первое место. Массивы RAID5 поднялись достаточно высоко, причем производительность массива RAID5 из четырех дисков почти совпала с производительностью RAID0 из четырех дисков. Производительность массива RAID1, как и в паттерне Fileserver, занижена из-за провала в одном из режимов.

Отложенная запись не увеличивает скорости массивов в этом тесте. В отсутствие запросов на запись ей просто нечего оптимизировать.

IOMeter:Workstation

Паттерн Workstation позволяет имитировать интенсивную работу пользователя в различных приложениях на файловой системе NTFS5.
Таблица в режиме WriteBack:


И ее графические представления:

Для массивов RAID0 картина стандартна - чем больше винчестеров в массиве, тем быстрее он обрабатывает запросы. Скорость RAID1 выше скорости одиночного винчестера даже при небольших нагрузках, а массив RAID10 обгоняет даже RAID0 из трех дисков. На их фоне массивы RAID5 выглядят слабовато, что, вообще говоря, неудивительно, так как случайные запросы на запись мелких блоков, коих в этом паттерне предостаточно, изрядно снижают их скорость.
Сравним между собой производительность разных RAID-массивов и составим диаграмму с рейтингами быстродействия массивов. Рейтинг для паттерна Workstation мы считаем по следующей формуле:

Производительность = Total I/O (queue=1)/1 + Total I/O (queue=2)/2 + Total I/O (queue=4)/4 + Total I/O (queue=8)/8 + Total I/O (queue=16)/16 + Total I/O (queue=32)/32


Массивы RAID5 по производительности отстают даже от одиночного диска. Массивы RAID0 выстроились «по росту», т.е. по количеству дисков, RAID10 хоть не намного, но обогнал RAID0 из трех дисков. Массив RAID1 обогнал по производительности массив RAID0 из двух дисков, хотя на графиках все было, в основном, наоборот. Все дело в том, что при расчете производительности рабочей станции мы считаем, что короткие очереди наиболее вероятны, и, следовательно, чем короче очередь, тем больше ее значимость в рейтинге. Поэтому, превосходства массива RAID1 в скорости при коротких очередях достаточно, чтобы обгонять массив RAID0 из двух дисков в рейтинге.

Посмотрим, как влияет состояние отложенной записи на работу массивов в этом паттерне:

Переход в режим WriteThrough не приводит к изменению распределения массивов ни по скоростям, ни по производительностям, но снижает скорость на 25 – 35 процентов (в зависимости от типа массива).

Winbench99

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


Сравним скорости различных массивов по двум интегральным подтестам - Business Disk Winmark и High-End Disk Winmark:


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

Как мы видим, наибольшую пользу из отложенной записи извлекает массив RAID10. В режиме WriteThrough он отстает даже от массива RAID5. На остальные массивы режим WriteBack влияет значительно слабее, но всегда положительно.

Посмотрим, что изменится при переходе к тестам на другой файловой системе.

Распределение массивов по скоростям в FAT32 практически не отличается от того, что мы видели под NTFS. Массивы RAID0 сохраняют небольшую зависимость скорости от количества дисков. Скорость RAID5-массива наиболее мала из-за присутствия в тесте Winbench операций записи, которые отрицательно влияют на скорость контроллера, не обладающего большим кэш-буфером. Массив RAID1 едва обгоняет одиночный диск, а массив RAID10 отрывается от них только за счет большого числа винчестеров.

А вот влияние режима WriteBack, в отличие от NTFS, достаточно велико для всех массивов. Распределение их по скоростям не зависит от состояния отложенной записи, хотя сама скорость меняется достаточно сильно.

Скорости линейного чтения одинаковы для обеих файловых систем, поэтому мы приведем один общий график.


При линейном чтении скорость линейно зависит от количества дисков, поэтому массивы RAID0 из двух и трех дисков показывают почти удвоенную и утроенную, соответственно, скорость одиночного диска. У массива RAID0 из четырех дисков такая пропорциональность, к сожалению, нарушается, но это связано либо с недостаточной скоростью работы центрального чипа, либо с нехваткой пропускной способности шины PCI 64/33МГц.
В отличие от контроллера 3Ware 7850 скорость линейного чтения с RAID5-массива из N-дисков не аналогична скорости чтения с RAID0-масива из (N-1)-дисков. Зависимость скорости массивов RAID5 от количества дисков наблюдается, отнюдь не с как 4:3. Cкорость линейного чтения с RAID1-массива отстает от одиночного диска, а скорость RAID10 от массива RAID0 из двух дисков. Похоже технология Twinstor, позволяющая увеличить скорость чтения с зеркальных массивов за счёт интеллектуального чередования запросов на чтение на оба диска зеркальной пары, на контроллере 8500-8 не дает преимуществ при линейном чтении.


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

График линейного чтения 1HDD - JBOD
График линейного чтения 2HDD - RAID1
График линейного чтения 2HDD - RAID0
График линейного чтения 3HDD - RAID0
График линейного чтения 3HDD - RAID5
График линейного чтения 4HDD - RAID0
График линейного чтения 4HDD - RAID5
График линейного чтения 4HDD - RAID10

Выводы

И второе впечатление о контроллере 3Ware8500-8 Escalade тоже благоприятное. Он показал очень неплохие результаты в тестах. Конечно, обнаружились и некоторые недостатки. Например, Twinstor не всегда работает корректно, и, как и у контроллера 3Ware 7850, отсутствует поддержка PCI 64/66МГц, что, с современными дисками критично уже для четырёхканального варианта контроллера.
Однако, среди уже протестированных нами SATA-RAID-контроллеров, он показал самые стабильные и объяснимые результаты. Удержит ли он первенство, мы узнаем в ближайшее время. Оставайтесь с нами.

Дополнение

Драйвера для контроллера 3WARE 8500-8 Escalade всегда можно найти на сайте производителя.
На текущий момент на сайте доступна версия 7.7.0. Этот набор из firmware, драйверов и утилит поддерживает следующие операционные системы: Windows 2003/XP/2000, SuSE 8x Linux, RedHat 8x и 9x Linux и FreeBSD 4.8 Beta. Кстати, это единственный релиз драйверов к Escalade 8500, который поддерживает FreeBSD.
Но зато предыдущие версии поддерживают более старые операционные системы. Например, релиз 7.6.3, на котором проводилось наше тестирование, не поддерживал FreeBSD и RedHat 9x Linux, зато поддерживал RedHat 7x Linux и SuSE 7x Linux. Так что, при необходимости, на сайте 3Ware можно найти драйвер для контроллера 3WARE Escalade 8500, который позволит работать почти с любой из распространённых операционных систем.