Контроллер 3Ware 9500S-8 от 3Ware

Введение

Продолжаем тему многоканальных SATA-RAID контроллеров. Сегодня, речь пойдет о не очень новом, но, по своему, революционном контроллере 3Ware 9500S-8 от 3Ware. Революционным контроллер мы назвали не зря. Ведь впервые за много-много лет 3Ware использовала в качестве кэш-памяти не несколько мегабайт SRAM-памяти, а сменный модуль SDRAM (с поддержкой ECC). Наконец-то кэш-память контроллера станет сопоставима с суммарной ёмкостью кэш-буферов жёстких дисков, которые к этому контроллеру можно подключить.

Линейка контроллеров 9000-й серии, как и линейки предыдущих серий состоят из моделей, поддерживающих 4, 8 и 12 дисков соответственно. И, по традиции, для тестирования мы выбрали контроллер из середины этой линейки.
Увеличение объёма кэш-памяти контроллера просто обязано положительно сказаться на скорости работы при больших нагрузках. Кроме того, как сказано на сайте компании, контроллер 3Ware 9500S-8 продемонстрировал скорость чтения в массиве RAID5 до 400МБ/сек, а записи до 100МБ/сек. Понятно, что такую информацию просто необходимо проверить. :)

Контроллер

Контроллер 3Ware 9500S-8, как мы уже упоминали, способен поддерживать до восьми Serial ATA/150 устройств. Он позволяет создавать следующие типы RAID-массивов: - 0, 1, 5, 10, 50 и JBOD. Шина обмена с компьютером – 64-х разрядная PCI, работает на частоте 66 МГц. Объём кэш-памяти контроллера составляет 128 МБ SDRAM с поддержкой ECC, с возможностью увеличения до 256 МБ.
Контроллер выглядит следующим образом:

Контроллер выполнен, как и большинство предыдущих восьмиканальных контроллеров от 3Ware, в уже привычном компактном (Half-length) исполнении и установкой SATA разъемов в два слоя. Лицевая сторона контроллера 3Ware9500S-8 практически полностью занята различными микросхемами, начиная от чипа контроллера и заканчивая памятью и BIOSом. Однако, что рациональное распределение компонентов по плате и перенос части элементов на оборотную сторону позволило оставить место еще для четырех разъемов SATA и соответствующих микросхем-контроллеров.

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

Как обычно, первое впечатление о контроллере от 3Ware неплохое. Давайте посмотрим, останется ли оно, как обычно, неплохим и после тестирования.

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

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

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

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

IOMeter 2003.02.15

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


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

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


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

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

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

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

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

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

IOMeter: паттерн Database

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

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

При линейной нагрузке, в начале графика (режим RandomRead), все массивы показывают очень близкие скорости, так как алгоритмам массивов нечего оптимизировать.
С ростом вероятности появления запроса на запись скорость работы одиночного диска плавно возрастает - работают алгоритмы отложенной записи винчестера. Соответственно количеству дисков в массиве, растет и скорость массивов RAID0, но пропорциональность наблюдается только в режимах с максимальной вероятностью появления запросов на запись.
Скорости массивов RAID5, с увеличением вероятности появления запроса на запись должны падать, так как такие запросы сильно замедляют их работу, однако, мы наблюдаем прямо противоположную картину. Поведение графиков массивов RAID5 очень напоминает графики массивов RAID0 и, по-видимому, тоже обусловлено доминированием отложенной записи дисков. Тем не менее, при малом количестве дисков в массиве и высокой вероятности появления запроса на запись скорости массивов RAID5 снижаются с ростом этой вероятности.
Массив-зеркало RAID1 неприятно удивил - его скорость почти во всех режимах ниже скорости одиночного диска. Неожиданный результат, так как во всех контроллерах от 3Ware для увеличения скорости чтения с зеркальных массивов используется фирменная технология Twinstor, которая позволяет по истории предыдущих запросов определять диск, который обработает текущий запрос быстрее, что заметно увеличивает скорость работы. И, как мы уже неоднократно наблюдали, на предыдущие контроллеры от 3Ware Twinstor влияла исключительно положительно. Будем надеяться, что с увеличением нагрузки этот алгоритм заработает правильно.
Графики скоростей еще одного зеркального массива - RAID10 так же, как и графики массивов RAID0 и RAID5, в основном, отражают влияние отложенной записи дисков.

Переходим к следующей величине нагрузки:

Увеличение нагрузки очень сильно меняет картину распределения скоростей, а вид графиков теперь формируется, в основном, под воздействием алгоритмов массивов, а не алгоритма дисков, как при линейной нагрузке. График одиночного диска практически не изменился, так как он отражает только алгоритмы отложенной записи винчестера.
Графики массива RAID0 повторяют график одиночного диска, соблюдая пропорциональность по количеству дисков в массиве. Однако, в отличие от линейной нагрузки, эта пропорциональность наблюдается уже в режиме RandomRead и, ростом числа запросов на запись, становится только более сильно выраженной. Из общей картины выпадает только график массива из семи дисков, на котором встречаются провалы при нуле и при шестидесяти процентах запросов на запись.
Зеркальные массивы, RAID1 и RAID10 резко увеличивают скорость работы в режиме RandomRead, так как отсутствие запросов на запись и достаточное количество запросов на чтение со случайным адресом позволяют технологии Twinstor максимально полно раскрыть свои возможности. С ростом числа запросов на запись, технология Twinstor начинает работать менее продуктивно, так как Twinstor оптимизирует только с запросы на чтение и ее отдача уменьшается. С другой стороны, при большом количестве запросов на запись становится заметно влияние отложенной записи дисков, поэтому скорость работы массивов RAID10 в режиме RandomWrite даже немного увеличивается. Зависимость скорости работы массивов RAID10 от числа дисков в массиве ярко выражена. В целом, при работе с нагрузкой в шестнадцать запросов, массив RAID1 всегда быстрее одиночного диска, а массив RAID10 из 2n дисков свою очередь, быстрее массива RAID0 из n дисков во всех режимах.
Для массивов RAID5 запросы на чтение обрабатываются с такой же эффективностью, как и для массивов RAID0. Однако с ростом числа запросов на запись скорость массивов RAID5 резко падает. Скорости массива RAID5 прямо пропорциональны количеству дисков в массиве. Только график массива RAID5 из трех дисков не вписывается в общую картину.

Увеличение нагрузки до 256-ти запросов в очереди уже практически не влияет на распределение скоростей. Графики массивов RAID0 практически повторяют график одиночного диска, пропорционально числу дисков в массиве, что говорит о том, что StorSwitch справляется с сортировкой и передачей запроса на соответствующий винчестер прекрасно. Небольшие провалы на графиках массивов из шести и семи дисков не в счет :). Массивы RAID5 и RAID10 демонстрируют высокие скорости работы и пропорциональность по числу дисков в массиве. Как и при нагрузке в шестнадцать запросов график массива RAID5 из трех дисков выпадает из общей картины.

В режиме WriteThrough мы тестировали только четырехдисковые массивы. Таблица результатов приведена ниже:


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


Как и следовало ожидать, во всех режимах работы массивов отключение WB-кэширования в BIOS-e приводит к снижению скорости, однако впервые в наших обзорах мы получили таблицу, в которой совсем нет красных чисел, то есть режим WriteBack контроллера 3Ware 9500S-8 оказывает только положительное влияние на скорость его работы. Однако, результаты сравнения скорости массива RAID10 при разных состояниях КЭШа контроллера в режиме RandomRead выглядят странно - при полном отсутствии запросов на запись скорость его работы не должна зависеть от состояния КЭШа.

Теперь сравним результаты, полученные при тестах массивов при разных состояниях КЭШа на графиках. Для этого построим графики каждого массива в режиме WriteThrough и WriteBack для очередей из 1, 16 и 256-ти запросов:

При отключении КЭШа контроллера массив RAID0 сильно снижает скорость даже при наличии минимального числа запросов на запись. С ростом числа запросов на запись разница в скоростях увеличивается, достигая семи с половиной раз. Увеличение числа запросов в очереди снижает различие между скоростями в режимах WriteBack и WriteThrough, однако преимущества WB - кэширования обнаруживаются во всех режимах, кроме RandomRead, где, из-за отсутствия запросов на запись, алгоритмы отложенной записи не влияют на скорость.

На массив RAID5 отключение КЭШа контроллера оказывает похожее влияние. Максимальные потери в скорости при WT-кэшировании проявляются при линейной нагрузке и достигают 236-ти процентов. С числа запросов в очереди, разница в скоростях при различных типах кэширования начинает сокращаться, но, так же как и в массиве RAID0, влияние WB-кэширования положительно во всех режимах, где встречаются запросы на запись.

Влияние WТ-кэширования на массив RAID10 так же отрицательно во всех режимах, где есть запросы на запись. Максимальные потери скорости составили 353 процента. Однако, как упоминалось выше, отключение КЭШа котроллера снижает скорость работы и в режиме RandomRead, при полном отсутствии запросов на запись – а это уже непорядок.

Итак, для всех массивов включение WT-кэширования приводит к значительному снижению скорости работы. Поэтому, даже сложно сказать, при каком состоянии КЭШа предпочтительнее работать. В режиме WriteThrough, конечно, надежность повыше, но уж очень солидно режим WriteBack увеличивает скорость :).

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

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

Построим график зависимости скорости чтения контроллера от размера блока:

Мда, очевидно, что здесь кто-то перемудрил. :)
Вероятно, алгоритмы упреждающего чтения контроллера вступили в конфликт с нашей нагрузкой...

Сравним скорости последовательного чтения четырехдисковых массивов в режимах WriteBack и WriteThrough:

Переходим к последовательной записи.
Сначала таблица с результатами:

Переходим к тестам, имитирующим реальные устройства.

IOMeter: Fileserver&Webserver

Начнем с паттерна, имитирующего работу дисковой подсистемы файлсервера.
Результат работы контроллера в режиме WriteBack:

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

Массивы RAID0, RAID5 и RAID10 демонстрируют прекрасное масштабирование по количеству дисков в массиве даже при небольшой глубине запросов. Массивы RAID1 и RAID10 из 2n дисков во всех режимах быстрее одиночного диска и массива RAID0 из n дисков соответственно. Так как в паттерне Fileserver 20% всего запросов на запись, то алгоритму Twinstor есть где "развернуться".

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

Как и ожидалось, самая низкая производительность у одиночного диска, а самая высокая у массива RAID0 из восьми дисков. Приятно удивила производительность массива RAID10. Каждый массив RAID10 из 2n дисков оказался быстрее массива RAID0 из n+1 диска соответственно.

Сравним результаты работы четырехдисковых массивов в режимах WriteBack и WriteThrough:

Даже в режиме с двадцатью процентами запросов на запись, отключение КЭШа значительно снижает скорость работы контроллера.


В зависимости от типа массива, производительность в режиме WriteThrough снижается в полтора-два раза. Либо надежность либо скорость…

Переходим к паттерну Webserver. И тоже начнем с результатов в режиме WriteBack:

Графики массивов по сравнению с паттерном Fileserver, качественно не изменились, только при глубине очереди в 64 запроса появился провал в графике массива RAID0 из шести дисков. Однако, благодаря тому, что в паттерне Webserver отсутствуют запросы на запись, скорости массивов RAID5 и RAID10 заметно увеличились.

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

Минимальная скорость, как и в предыдущем паттерне у одиночного диска, а вот в группе лидеров заметные изменения. Наличие 100% запросов на чтение приводит к тому, что при равном количестве дисков, наиболее быстрыми оказались массивы RAID10, а массивы RAID1 наименее производительны.

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

В принципе, при отсутствии запросов на запись, состояние КЭШа никак не может влиять на скорость работы контроллера. Это мы и наблюдаем у массивов RAID5 и RAID0. Однако, скорость массива RAID10 при отключении КЭШа контроллера падает почти вдвое. Такая странность уже наблюдалась нами в паттерне Database, что позволяет предположить некорректность переключения режимов WriteBack/WriteThrough контроллера в массиве RAID10.

IOMeter:Workstation

И последний паттерн на сегодня - имитация интенсивной работы пользователя в различных приложениях на файловой системе NTFS5.
Результат работы контроллера в режиме WriteBack:

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

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

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

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

Графики линейного чтения для каждого массива приведены отдельно.

График линейного чтения Wb_1HDD-JBOD
График линейного чтения Wb_2HDD-RAID0
График линейного чтения Wb_2HDD-RAID1
График линейного чтения Wb_3HDD-RAID0
График линейного чтения Wb_3HDD-RAID5
График линейного чтения Wb_4HDD-RAID0
График линейного чтения Wb_4HDD-RAID5
График линейного чтения Wb_4HDD-RAID10
График линейного чтения Wb_5HDD-RAID0
График линейного чтения Wb_5HDD-RAID5
График линейного чтения Wb_6HDD-RAID0
График линейного чтения Wb_6HDD-RAID5
График линейного чтения Wb_6HDD-RAID10
График линейного чтения Wb_7HDD-RAID0
График линейного чтения Wb_7HDD-RAID5
График линейного чтения Wb_8HDD-RAID0
График линейного чтения Wb_8HDD-RAID5
График линейного чтения Wb_8HDD-RAID10
График линейного чтения WT_4HDD-RAID0
График линейного чтения WT_4HDD-RAID5
График линейного чтения WT_4HDD-RAID10

Выводы

Увеличение объёма кэш-памяти помогло контроллеру 3Ware существенно увеличить производительность в режимах с большой долей записи. Также отметим возросшую мощь контроллера при работе в режиме RAID5. За это стоит благодарить более мощный XOR-процессор, работающий на частоте 150МГц.
Но уже давно на рынке доступен еще более совершенный контроллер от 3Ware - 9550SX. Но о нём мы расскажем в следующий раз...