SATA RAID контроллер Promise FastTrak TX4300

Введение

Как Вы уже догадались по названию обзора, сегодня мы рассмотрим новый четырёхканальный контроллер Promise - FastTrak TX4300. От своего предшественника, контроллера FastTrak TX4200, новая модель отличается, прежде всего, поддержкой большей скорости передачи данных между контроллером и диском - 3Гбит/сек (против 1.5Гбит/сек у FT TX4200).

Контроллер поставляется в коробке уже знакомого нам "фирменного стиля"


А вот сам контроллер оказался на редкость миниатюрным - чуть ли не в половину от размера FT TX4200.


Правда, к сожалению, разъёмы для жёстких дисков уже не "смотрят в одну сторону" - это может затруднить кабелирование в плотных серверах (1U). Выше чипа расположены разъёмы для подключения индикации активности жёстких дисков, подключенных к контроллеру (как индивидуальные, так и объёдинённые) и разъём для подключения информационного кабеля к корзине SuperSwap 4100 (для мониторинга скорости вращения вентилятора в корзине и температуры жёстких дисков).


В комплекте к контроллеру мы можем найти всё необходимое для использования контроллера - четыре SATA-кабеля, переходник питания (необходимость в котором постепенно исчезает в силу появления блоков питания с соответствующими разъёмами), костыль для модификации контроллера в низкопрофильный вариант, руководство по эксплуатации и компакт-диск с драйверами.

Контроллер соответствует спецификации "Serial ATA II Extensions to SATA 1.0a specification" и может поддерживать до четырех SerialATA дисков (поддерживающих передачу данных на скорости в 3Гбит/сек).
Кроме технологии NCQ также поддерживается и TCQ ( о разнице между этими двумя технологиями можно почитать в статье "Вкратце о технологии маршрутизации команд Serial ATA II NCQ (Native Command Queuing)".

Типы поддерживаемых RAID-массивов стандартны – 0, 1, 10, и JBOD. За счет способности контроллера работать в 32бит/66МГц слоте PCI 2.2 максимально возможная теоретическая пропускная способность контроллера составляет 266МБ/c.

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

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

корпус -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.

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

FC-Test v1.0 bild 13
IOMeter 2003.02.15

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


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

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


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

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

Контроллер тестировался с прошивкой 2.00.0.31 и драйверами 1.00.0.36. Контроллер устанавливался в слот PCI-X/133МГц (хотя контроллер поддерживает только PCI64 66МГц). Диски WD740GD (Raptor) устанавливались в штатные салазки корпуса SC5200 и крепились четырьмя винтами за нижнюю грань.

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

Традиционно, начнем обзор с тестирования работы контроллера со смешанными потоками запросов:

IOMeter: паттерн Database

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

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


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


При линейной нагрузке, в режиме RandomRead все массивы показывают очень близкие скорости. С увеличением доли запросов на запись диски могут выполнять отложенную запись более эффективно, поэтому скорость работы массивов возрастает. Максимальные результаты, как и следовало ожидать, достигаются в режиме RandomWrite для всех вариантов RAID-массивов.

График массива-зеркала RAID1 практически повторяет график одиночного диска при низкой доле запросов на запись. По мере увеличения доли запросов на запись скорость работы массива RAID1 становится заметно ниже скорости одиночного диска. Скорость работы второго массива, использующего зеркалирование (RAID10), ниже скорости массива RAID0 из двух дисков почти во всех режимах.


Увеличение нагрузки приводит к тому, что при любом соотношении долей запросов на чтение и запись быстродействие массивов зависит и от типа массива и от количество дисков в массиве.
Обратите внимание, что массивы, использующие зеркалирование, в режиме RandomRead оказываются быстрее, нежели массивы RAID0 из того же числа дисков, но проигрывают им в режиме RandomWrite.
Если при чтении контроллер может жонглировать запросами, выполняя их на наиболее готовом/удобном/отдохнувшем винчестере, добиваясь увеличения скорости работы, то при записи ситуация прямо противоположная. Контроллер, который считает "правильным" гарантировать идентичность данных на обоих дисках зеркальной пары, должен дождаться подтверждения успешной записи от каждого из дисков, что и вызывает дополнительные потери времени (в идеале надо бы еще произвести контрольное чтение, но... это уже паранойя... :) ).


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

Переходим к последовательным чтению/записи.

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

Этот паттерн позволяет исследовать производительность контроллера в режиме последовательного чтения/записи. На массивы при помощи программы IOMeter подаётся поток запросов на чтение/запись с глубиной очереди команд, равной четырём. Раз в минуту в тесте меняется размер блока данных, так что после окончания теста мы получаем зависимость скорости линейного чтения или записи от размера блока данных.
Зависимость скорости чтения данных контроллером от размера их блока приведены в таблице:


Построим графики зависимости скорости работы массива от размера блока данных:


Преимущества RAID0 массивов с большим количеством винчестеров начинают проявляться только при больших размерах запрашиваемого блока данных, то есть в случаях, когда контроллер может разбивать большие блоки на несколько маленьких и использовать винчестеры параллельно. Массивы RAID0 смотрятся очень неплохо – все они достигают максимальной скорости работы уже при размере блока в 64 Кб (а массив из двух дисков уже при 16Кб), масштабируемость скорости чтения по количеству дисков в массиве явно просматривается, а скорость массива из четырех дисков приближается к максимальной пропускной способности шины (266МБ/сек).
Зеркальные массивы RAID1 и RAID10 смотрятся гораздо хуже. Скорость их работы в большинстве режимов ниже скоростей одиночного диска и массива RAID0 из двух дисков соответственно.
Теперь, посмотрим на поведение контроллера при последовательной записи. Скорости прокачки данных контроллером, в зависимости от размера их блока приведены в таблице:


Построим графики зависимости скорости работы массива от размера блока данных:


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

IOMeter: Fileserver&Webserver

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


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


Наличие всего двадцати процентов запросов на запись приводит к тому, что все массивы показывают очень неплохие результаты. Массивы RAID0 демонстрируют хорошую масштабируемость по скорости в зависимости от количества винчестеров. Скорости работы зеркальных массивов RAID1 и RAID 10 заметно превышают скорости работы одиночного диска и массива RAID0 из двух дисков соответственно.
Сравним производительность различных массивов, применив рейтинговую систему. Считая все нагрузки равновероятными, общий балл будем рассчитывать, как среднее значение скорости обработки контроллером запросов при всех вариантах нагрузки:


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

Посмотрим на результаты работы контроллера при имитации файловой системы веб-сервера:

"Душераздирающее зрелище" ( (с) ослик Иа). Графики массива RAID0 из четырех дисков и массива RAID10 демонстрируют объяснимые результаты. Скорость работы одиночного диска и массивов RAID0 из двух и трех дисков очень занижена, а массива RAID1 почти "нормальна".
Первая версия, которая может возникнуть у стороннего наблюдателя - ошибка при тестировании... Однако, мы гневно отвергнем подобные обвинения! Дело в том, что наш тестовый скрипт для IOMeter подразумевает последовательное выполнение подтестов с перезагрузкой между сеансами. Так вот тот самый паттерн Webserver выполняется в одном сеансе с паттерном Fileserver (сначала Fileserver, потом Webserver без перезагрузки между ними).
И, если контроллер с блеском выполняет Fileserver, но "ломается" на Webserver, то вины тестеров в этом нет - между тестами настройки компьютера или RAID-контроллера не производятся... Настройки делаются ДО запуска скрипта, который затем крутит тесты примерно четырнадцать часов без передыху (если не считать короткие паузы на перезагрузку компьютера).

Так что, наверное, причина таких результатов - драйвера контроллера.

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


Производительность массивов RAID0 из четырех дисков и массива RAID10 отличается от результатов в паттерне Fileserver незначительно. Результат работы остальных массивов непонятен.

IOMeter:Workstation

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

Для массивов RAID0 картина стандартна - чем больше винчестеров в массиве, тем быстрее он обрабатывает запросы. Скорости массивов RAID1 и RAID10 c ростом нагрузки изменяются от значений близких скоростям массивов RAID0 из двух и четырех дисков соответственно, до значений близких скоростям одиночного диска и массива RAID0 из двух дисков соответственно.
Сравним между собой производительности разных 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


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

Многопотоковая запись/чтение

В данном паттерне мы исследуем способность контроллера осуществлять многопотоковую последовательную запись/чтение. Так как подобные нагрузки к дискам и контроллерам мы начали применять не так давно, стоит рассказать о принципе работы теста поподробнее.
Итак, есть задача - имитировать одновременную нагрузку на дисковую подсистему со стороны нескольких приложений, затребовавших "большие файлы". Изображать каждое приложение будет специальный тестовый агент программы IOMeter (в терминах IOMeter - Worker) - он будет последовательно читать/писать блоками по 64КБ данные, начиная с некоторого стартового сектора. Назовём этот процесс - thread.

Постепенно мы увеличиваем количество исходящих запросов от Worker-а (от одного до восьми с шагом 1) для исследования способностей диска или контроллера к переупорядочиванию запросов (склеивания нескольких запросов на последовательно расположенные данные в один запрос).
Увеличивая количество одновременно работающих Worker-ов, мы усложняем работу дисковой подсистемы - как и в реальной ситуации несколько одновременно работающих программ конкурируют между собой за доступ к дискам. Каждый Worker работает со своими данными (т.е. адреса запрашиваемых блоков у разных Worker-ов не пересекаются).
Рассматривается два случая - все программы читают данные, и все программы пишут данные. Конечно, комбинаций нагрузок может быть много, но мы пока остановились на таких режимах.

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

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

Очевидно, что при нагрузке в один запрос мы не получили уверенного масштабирования скорости чтения от количества дисков в массиве на одном потоке (приложении). Скорость одиночного диска и массива RAID1 оказалась равной, а вот зато массив RAID10 обогнал даже массив RAOD0 из четырёх дисков... Не потому, что RAID10 успешно читал со всех дисков массива сразу, а потому что с массива RAID0 не удалось вытянуть больше. Очевидно, агрессивного упреждающего чтения ни контроллер, ни диски не производят.
Зато на двух одновременно выполняемых потоках нас ждал сюрприз - "выстрелил" массив RAID1!
Два потока идеально разложились на два диска массива, и скорость чтения выросла почти вдвое. А вот скорость всех остальных массивов неожиданно резко снизилась. Конечно, при двух потоках головкам жёстких дисков приходится постоянно перемещаться между двумя рабочими зонами, так что о достижении скорости линейного чтения с массива можно забыть. Но, а как же упреждающее чтение, ведь именно для этого оно и придумано... Увы, используемые для тестов диски имеют оптимизацию для использования в серверах, то есть упор сделан на малое время доступа. А, очевидно, чем более большими кусками жёсткий диск будет "проглатывать" в себя данные при каждом запросе на чтение, тем более медленно он будет обрабатывать случайные запросы.
Если обратиться к таблицам с результатами, то станет ясно, что при нагрузке, большей, чем один исходящий запрос, скорость работы массивов резко растёт - срабатывает либо оптимизация запросов контроллером, либо TCQ у дисков. Характер запросов к дискам становится больше похож на линейное чтение.

На трёх и четырёх одновременно запущенных потоках мы видим чёткое масштабирование скорости массивов RAID0 от количества дисков в них.
Посмотрим, что у нас получилось при записи:


А при записи у нас "провалились" по скорости массивы, использующие зеркалирование - они почти во всех режимах значительно медленнее одиночного диска и массива RAID0 из двух дисков.

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

FC-test

А теперь попробуем испытать контроллер FastTrak TX4300 в "однопользовательском" режиме.

Мы применяем FC-Test по нашей стандартной методике - на диске создавалось два логических диска по 32 GB, и они размечались сначала в NTFS и, затем, в FAT32. На первом логическом диске создавался набор файлов, затем этот набор файлов читался с диска, затем набор файлов копировался в директорию, созданную на первом логическом диске (т.е. производилось копирование внутри одного раздела), и завершало цикл тестов копирование первого набора файлов на второй логический диск.
Между каждым тестом проводится перезагрузка тестовой системы, тем самым мы исключаем влияние кэша операционной системы на результаты тестов. Всего мы используем пять наборов файлов:

Install - 414 файлов общим объёмом 575МБ;
ISO - три файла общим объёмом 1.6ГБ;
MP3 - 271 файл общим объёмом 1ГБ;
Programs - 8504 файла общим объёмом 1.4ГБ;
Windows - 9006 файлов общим объёмом 1.06ГБ.

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

NTFS


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

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

Посмотрим на режим чтения:

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

Посмотрим, что будет со скоростью копирования.

Копирование, по сути, есть работа двух потоков - одного на чтение, другого на запись. И, как оказалось, массивы RAID0 справляются с такой работой лучше всех. Причём, явно проглядывается масштабируемость от количества дисков.

Второй цикл тестов на скорость копирования не приносит никаких сюрпризов. Массивы RAID0 - впереди, а массивы, использующие зеркалирование, немного уступают по скорости одиночному диску и массиву RAID0 из двух дисков.
Укрупним кластер! :)

FAT32

Мне кажется, или скорость выросла? Да, скорость массивов действительно стала повыше.

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

Зато копирование файлов опять прошло "на ура".
Итак, тесты RAID-массива в FC-Test также были весьма поучительны. Осталось только проверить какой-нибудь другой контроллер и сравнить результаты... Или дождаться следующей версии драйверов контроллера.

Тесты Winbench по полной программе решено было не проводить. Мы ограничились только снятием графиков линейного чтения.

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

Выводы

Итак, по результатам тестов контроллера Promise FastTrak TX4300 мы можем сказать, что, в общем, он показал себя неплохо. Массивы RAID0 демонстрируют хорошее масштабирование скорости массива от количества дисков в нём и приличную скорость работы.
В некоторых тестах контроллер показал не очень стабильные результаты, однако, на наш взгляд, стоит дождаться новой версии драйверов.
Также, необходимо сказать, что в результатах некоторых наших новых тестов мы ещё и сами до конца не уверены, так как не накопили ещё достаточного количества фактического материала для объявления глубокомысленных выводов.

Если оценивать количество инноваций в контроллере, то стоит признать, что FastTrak TX4300 не очень далеко ушёл от FastTrak TX4200. Так что тем, кто уже имеет TX4200 и диски, менять контроллер не имеет смысла. Ну а если Вы рассматриваете кандидатуру на "усиление" дисковой подсистемы своего компьютера, то контроллер Promise FastTrak TX4300 - хороший вариант.
Некоторые читатели справедливо полагают, что современные материнские платы обладают достаточным количеством портов SATA и способны объединять подключенные к ним диски в RAID-массивы. Однако, при современных темпах миграции компьютерного оборудования реализация RAID-массива на чипсетных контроллерах может затруднить процесс переноса накопленного программного обеспечения со старого компьютера на новый. В таких случаях обладание внешним RAID-контроллером с нестареющим PCI-интерфейсом может сослужить неплохую службу.
Хотя, если Вы любите переустанавливать Windows и приложения раз в месяц, то... ;)