Обзор Promise SX6000

Введение

Наконец-то закончено тестирование последнего доступного на текущий момент IDE RAID-контроллера с поддержкой RAID 5-го уровня - Promise SX6000. Из шести подключаемых к этому контроллеру дисков он позволяет создавать RAID-массивы уровней 0,1,01,3,5. Таким образом, количество конфигураций RAID-массивов для тестирования достигло 17-ти вариантов, что, как Вы понимаете, потребовало значительного расхода niknik-о-часов...

В этом обзоре мы подробно рассмотрим скорость и функциональность этого контроллера, а в следующем мы сравним шесть контроллеров (3Ware Escalade 6400, 3Ware Escalade 7810, Adaptec AAA-UDMA, Adaptec 2400A, Promise SuperTRAK100 и Promise SuperTRAK SX6000) между собой.

Если вспомнить первый RAID5-контроллер Promise, который нам довелось тестировать - SuperTRAK100, то он, на наш взгляд, получился не очень удачным. Тем интереснее нам будет оценить то, насколько инженеры Promise сумели выявить недостатки SuperTRAK100, и лишен ли этих недостатков SuperTRAK SX6000.

Контроллер

Контроллер SX6000 поставляется в яркой, достаточно большой коробке.


Внутри этой коробочки есть ещё одна, но на сей раз – белая: :)


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

руководство по эксплуатации контроллера
дискеты с драйверами и утилитами
три разветвителя питания
шесть UDMA100/66-шлейфов
рекламный проспект

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

Не все корпуса, к сожалению, имеют достаточное количество разъёмов питания для инсталляции того количества винчестеров, которые можно подключить к SX6000. Впрочем, мой тюнингованный стенд на базе корпуса SuperMicro SC701D вполне справился с такой проблемой (а разветвители были прикарманены «на чёрный день»).
А теперь позвольте предложить вашему вниманию сам контроллер:

Как видим, расположение элементов на плате несколько отличается от архитектуры SuperTrak100. Главный процессор теперь закрыт радиатором (который мне так и не удалось оторвать, настолько хорошо он был приклеен), разъём для установки кэш-памяти перемещён под IDE-чипы, а те, соответственно, сдвинулись поближе к IDE-разъёмам.


На обратной стороне платы никаких элементов не разведено.


Каждый из расположенных на плате IDE-чипов отвечает за два IDE-канала.


Но чипы-то на контроллере не простые! Судя по маркировке (PDC20276), на контроллере SX6000 установлены новейшие UDMA133 IDE-контроллеры от Promise!


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


посадочное место для крепления backup-батареи для кэш-буфера контроллера! Такой "фичи" у IDE RAID-контроллеров я до сих пор не встречал.
В комплект контроллера, к сожалению, не входит модуль кэш-памяти! Это, конечно, придаёт опытным пользователям возможность не платить за "поставляемый по умолчанию" модуль кэш-памяти, так как он заведомо будет малого объёма для снижения стоимости контроллера, но, с другой, стороны, купленный контроллер без памяти просто не включится! Мне кажется, что имеет смысл всё же комплектовать контроллер модулем кэш-памяти, хотя бы и минимально возможной ёмкости - 16МБ.



Что же, контроллер SX6000 оснащён более скоростным XOR-процессором (i960RM - 100МГц), чем SuperTrak100 (i960RD66 - 66МГц). Он имеет более быструю кэш-память, поддерживает винчестеры с объёмом более 137ГБ (правда, непонятно, почему для него не заявлена поддержка ATA133-винчестеров, ведь чипы PDC20276 поддерживают ATA133 в полном объёме, а не только спецификацию BigDrive).

Контроллер умеет делать HotSpare (автоматическую замену вышедшего из строя винчестера в массиве на резервный), а также HotSwap (при условии, что к контроллеру подключены корзины Promise SuperSwap).

Единственное, что настораживает - отсутствие поддержки PCI 32/66МГц, ведь у Promise уже есть продукты с поддержкой такой шины - Ultra100 TX2, FastTRAK100 TX2, Ultra133 TX2, SX2000...

Дравера и утилиты

На текущий момент (16 января) была доступна только одна версия драйверов для SX6000:

Впрочем, она работоспособна и никаких "приключений" у меня с этим контроллером не было.
К контроллеру прилагается утилита Promise Array Management (PAM),


при помощи которой можно удалённо (или локально) управлять работой массива - создавать, удалять или восстанавливать работоспособность.


Не сказать, что бы её интерфейс был удобным для "неадминистратора", но функции свои она выполняет. Доступ к администрированию массивов предоставляется только по паролю, так что "враг не пройдёт"! :)

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

материнская плата - SuperMicro 370DLE
процессор - Intel Coppermine 600MHz;
память - 2*128Mb SDRAM Micron PC133 ECC Registered;
винчестер - Fujitsu MPG3102AT;
видеокарта - Matrox Milennium 4Mb;
операционная система - Windows 2000 Pro SP2;

Для создания массивов использовались шесть дисков IBM DTLA 307015. Испытать контроллер SX6000 в работе с дисками большой ёмкости (>137ГБ) пока у нас возможности нет (этих дисков пока нет в Москве).

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

Размер stripe-блока при создании массивов устанавливался в 64КБ. Для тестов в WinBench массивы размечались в FAT32 и NTFS одним разделом с размером кластера по умолчанию.
Тесты проводились по четыре раза, результаты усреднялись. Винчестеры между тестами не охлаждались.
Использовались следующие тесты:

WinBench 99 1.2
IOMeter 1999.10.20

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


Исследование влияния размера stripe-блока на производительность проводилось на RAID 0 массиве из четырёх винчестеров. Контроллер тестировался с 32МБ модулем кэш-памяти PC100 SDRAM с таймингами 2-2-2. Проверка зависимости скорости контроллера от объёма кэш-буфера не проводилась.

Результаты WinBench 99

Из всех результатов Winbench99 я привожу только результаты Business Disk Winmark, Hi-End Disk Winmark и скорость линейного чтения в начале и конце диска.


Как видим, максимальная скорость в тестах была достигнута на RAID 0 из четырёх дисков, а при увеличении количества дисков в массиве скорость немного упала. В то же время, нельзя не отметить, что скорость массива меньше, чем скорость одного винчестера IBM DTLA 307015 на обычном UDMA100-контроллере.


Скорость RAID1 практически не отличается от скорости одиночного винчестера, а на RAID3 максимум скорости опять пришёлся на четырёх-винчестерную конфигурацию.
Отметим, что при реализации RAID1 чтение, судя по всему, производится только с одного винчестера из пары.


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

Результаты IOMeter

Результаты IOMeter также будут представлены в наиболее компактном и удобном для анализа виде, – только значения Total I/O (т.е. количество отработанных массивом запросов):


Анализ мы сделаем при помощи диаграмм чуть позже, а сейчас нас ждут результаты RAID1 & RAID3:




А вот теперь построим графики зависимости количества отработанных запросов от количества винчестеров в массиве для каждого паттерна:


Очень интересная картина. Смотрите – RAID1-массив работает со скоростью RAID0 на двух винчестерах! То есть случайные запросы на RAID1-массив контроллер чередует на оба винчестера. Впечатляет также небольшое отставание RAID01 от RAID 0. Непонятным, правда, остаётся поведение массива RAID3 – увеличение скорости при увеличении количества винчестеров в массиве есть, но оно резко замедляется при подключении шестого винчестера.


Практически точное повторение картины предыдущего паттерна, разве что результаты здесь чуть выше. RAID1 немного отстал от RAID 0 на двух винчестерах, RAID 3 опять «насытился» на пяти винчестерах.


Обратите внимание на то, что с RAID3 сделало увеличение доли операций записи до 33 процентов! Рост производительности этого типа массива прекратился уже при подключении пятого винчестера.


Что любопытно, массив RAID1 уже не показывает результатов, заметно превышающих скорость одиночного винчестера. Запросы на запись исполняются для обоих винчестеров в массиве, и никакое «ускорение» невозможно.
С массивами RAID5 и RAID3 творится что-то ужасное... Для RAID3, в силу его организации, вполне дозволительно снизить свою скорость ниже скорости одиночного винчестера, а на RAID 5 контроллеру SX6000 можно было бы быть и чуть быстрее...


Вот пример великолепной работы – прекрасная масштабируемость для всех типов массива. Но абсолютные значения полученной скорости, увы, невелики. Для RAID0 контроллер записывал по 6 МБ/сек на каждый подключенный винчестер! Что уж тут говорить про остальные типы массивов...


Яркой демонстрацией того, что Promise применяет какую-то оптимизацию при работе со случайными запросами на чтение служит работа контроллера в этом паттерне. Взгляните - скорость RAID1 и RAID 01 массивов выше, чем у RAID 0!
Скорость RAID5 аналогична скорости контроллера в RAID0, а скорость RAID3 повторяет график RAID0 со сдвигом на один винчестер (тот самый, который в RAID 3 хранит контрольную сумму).


В этом паттерне мы впервые отчётливо видим, как несколько типов массивов – RAID0, RAID5 и RAID3 выходят на насыщение на четырёх винчестерах. Правда, скорость при этом довольно приличная - 62-68МБ/сек...
Забавно, но RAID1 опять «деградировал» до скорости одиночного винчестера. Видимо, фирмваре контроллера не разрешает чтение с обоих винчестеров в массиве при таком характере запросов. А зря... ;)
При всё при этом, RAID 01 показал очень хорошую скорость. Неужели «то, что позволено Юпитеру, не позволено быку»?

Влияние размера Stripe block

Попробуем разобраться, каков будет прирост (и будет-ли) скорости обработки контроллером запросов при последовательном увеличении размера страйп-блока, и как зависит этот прирост от глубины очереди команд. Для исследования был выбран массив RAID 0 на четырёх винчестерах.

Текущее фирмваре контроллера SX6000 позволяет изменять размер Stripe-блока в интервале 4-64КБ, а вариантов выбора блока не так уж и много - всего пять (4, 8, 16, 32, 64КБ).


В первой диаграмме приведена зависимость скорости обработки контроллером запросов во всех интересующих нас паттернах при глубине очереди команд равной 1.


Очевидно, что лучше всего реагируют на увеличение размера stripe-блока паттерны RandomWrite и SequentialRead. Менее всего увеличение размера stripe-блока влияет на скорость контроллера в паттерне RandomRead.
Отметим, что в двух Sequential-паттернах – SequentialRead и SequentialWrite максимум производительности достигается при размере страйп-блока, равном 64КБ. Что же, всё правильно, ведь у нас массив из четырёх винчестеров, а размер пакета данных в этом паттерне равен 256КБ. Таким образом, при обработке каждого запроса на долю каждого винчестера приходится 64КБ. Контроллер в таком режиме не выполняет дробление пакета на мелкие части, не перегружает свою внутреннюю шину и не усложняет работу винчестерам.



Заметно «оживляются» паттерны Fileserver, Workstation и Database, но еще большую чувствительность к размеру stripe-блока демонстрирует паттерн RandomRead! Что же, при увеличении длины очереди запросов контроллер имеет возможность выбрать наиболее оптимальный порядок их выполнения. При этом некоторые запросы стали выполняться чуть дольше (ибо их «задвигают» в самый конец очереди), но средняя скорость обработки запросов растёт.



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

Надёжность

Для проверки способности контроллера восстанавливать работоспособность массива при отказе одиночного диска были смоделированы аварийные ситуации в массивах уровней 1, 01, 3, 5 (для массивов уровней 01, 3, 5 количество дисков было выбрано равным четырём).
Запускался тест IOMeter, после нескольких минут работы теста одному из дисков отключалось питание, и он вместе с реком извлекался из корзины. Через некоторое время, когда массив дисков начинал устойчиво работать в аварийном режиме, работа теста IOMeter прекращалась, диск устанавливался на своё место, и на него подавалось питание.
Замерялось время, прошедшее с этого момента до полного восстановления функциональности массива.
Время восстановления целостности массивов составило:

RAID1 – 12 минут
RAID01 – 16 минут
RAID3 – 40минут
RAID5 – 45минут

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

Выводы

Контролер Promise SX6000 продемонстрировал неплохую скорость по нашим тестам и значительно превзошёл своего «предка» - контроллер SuperTrak100. Превзошёл по всем статьям, в любой конфигурации и в любом паттерне. Контроллер SX6000 также показал отличную масштабируемость от количества подключаемых дисков (чем SuperTrak100 похвалится никак не мог).
Ещё одним «плюсом» контроллера является отличное соотношение его цены и количества IDE-каналов. Шесть каналов позволяют создать при помощи одного контроллера SX6000 два отказоустойчивых массива, сочетающих скорость и объём (RAID3, RAID5) или три массива RAID1, что увеличивает рыночную нишу этого контроллера.

Из недостатков контроллера SX6000 следует отметить невысокую скорость обработки Sequential-запросов и низкую скорость всех типов массива в тестах WinBench.

Как соотносится скорость работы SX6000 со скоростями его основных соперников – контроллеров 3Ware 7810 и Adaptec 2400A, Вы узнаете из нашего следущего обзора.
Оставайтесь с нами! :)

Благодарим компанию Promise Technology Inc. за предоставленный на тестирование контроллер SX6000.