Четырехканальный SATA RAID-контроллер Intel® SRCS14L

Введение

Чем сильнее чувствуется холодное дыхание зимы, тем всё более заметнее активное проникновение интерфейса SATA на рынок. Кажется, что любая выпускаемая сейчас материнская плата несёт на себе контроллер SATA-RAID, причём, в доброй половине случаев, SATA RAID-контроллер интегрирован в южный мост чипсета. Однако жёстких дисков с интерфейсом SATA пока выпускается значительно меньше, чем дисков с привычным ATA-интерфейсом. Таким образом, можно предположить, что основная масса пользователей ещё предпочитает обычные диски. Другими словами, пока люди не видят смысла в переходе на SATA или считают цену этого перехода неадекватной цене, которую придётся заплатить.
Но есть область применения, где SATA-диски востребованы уже сейчас - это low-end сервера и высокопроизводительные рабочие станции. Там нужна не супервысокая производительность, которую способны обеспечить SCSI-системы, и цена компьютера тоже принимается в расчёт.

Поэтому, мы начинаем серию обзоров многоканальных (то есть 4 и больше) SATA RAID-контроллеров. И первым в нашей серии будет четырехканальный SATA RAID-контроллер Intel SRCS14L.

В предыдущем нашем обзоре, посвящённом двухканальным SATA RAID-контроллерам, мы использовали жёсткие диски Seagate Barracuda SATA V. Вызвано это было двумя причинами. Во-первых, других SATA-дисков тогда у нас на руках просто не было. Во-вторых, и это будет ответом на вопрос "А почему Вы тестировали контроллеры не с дисками Raptor?", мы считаем, что для подавляющего большинства читателей будет интереснее читать сравнение широко распространённых контроллеров на не менее распространённых дисках. То есть мы считаем, что двухканальные контроллеры нужно тестировать с 7200rpm-дисками. Ну а уж контроллеры более серьёзные (с четырьмя каналами и больше) мы тестировали на дисках WD Raptor, благо они теперь у нас есть.

Кстати, о двухканальных контроллерах. Как мы и обещали, повторные тесты контроллеров (на нормальных версиях драйверов) проведены, и результаты скоро будут опубликованы.

Контроллер Intel SRCS14L

Вообще-то говоря, не думали мы, что первым четырёхканальным SATA RAID-контроллером, который нам доведётся тестировать, станет контроллер Intel. Но, так как он появился у нас в руках первым, мы можем сказать, что компания Intel решила серьёзно продвигать SATA-интерйфейс. :)

Поставляется контроллер SRCS14L вот в такой красивой коробочке:

в которой лежит CD с драйверами, планка для установки платы в Low Profile корпуса, описание:

ну и, конечно же, сам контроллер:

Первое, что сразу бросается в глаза как на коробке, так и на контроллере - это процессор ввода/вывода Intel® 80303: 100 MГц с аппаратным выполнением операции XOR для повышения производительности RAID уровней 4/5. Процессор на контроллере берет на себя все задачи по работе с дисками и создаёт из них RAID-массивы различного уровня, тем самым, разгружает центральный процессор и повышает производительность системы. Контроллер Intel SRCS14L поддерживает уровни RAID 0, 1, 4, 5 и 10.
Работа с SATA-дисками ведётся при непосредственном участии двух контроллеров Silicon Image Sil3112A. По два канала на каждом чипе, итого в сумме - 4 SATA-канала. Кэш-память у контроллера встроенная , то есть увеличить её объём не удасться, и выполнена в виде 64МБ PC100 ECC SDRAM.
Сам контроллер выполнен в виде так называемой low-profile (низкопрофильной) PCI-платы. Так как этот контроллер предназначается для самых простых серверов, то вполне логично было сделать его именно в виде low-profile платы.
Интерфейс 64-разрядной 66-MГц шины PCI 2.2, рассчитан на напряжение 3,3 В и 5 В, обратно совместим с интерфейсом 32-разрядной 33-MГц шины. И, наконец, на контроллере присутствует спикер (аварийная сигнализация) и статусные светодиоды.

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

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

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

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

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

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


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

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


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

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

В контроллере было прошито firmware 2.36.02-R048, использовались драйвера 3.05.

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

Управление режимами работы контроллера, работа с массивами и т.п. возможны не только через BIOS-контроллера при перезагрузке компьютера, но и, при помощи Intel RAID Storage Console, прямо из под Windows!


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


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


И, для некоторых тестов, она запрещалась, дабы увидеть разницу в производительности.

При тестах контроллера SCRS14L мы впервые столкнулись с BIOS контроллеров Intel и кое-что повергло нас в шок. На этом скриншоте Вы можете наблюдать встроенные средства мониторинга нагрузки на контроллер и диски, причём они работают в режиме реального времени!

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

Начнем обсуждение результатов теста с самого “большого” паттерна:

IOMeter: паттерн Database

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


Попробуем получить более наглядное представление:

Так как с увеличением доли запросов на запись диск может выполнять отложенную запись более эффективно, то массив RAID0 демонстрирует рост скорости от увеличения числа винчестеров только с ростом числа запросов на запись. При чтении все массивы демонстрируют одну скорость.

Та же картина наблюдается и с массивами, использующими зеркалирование. RAID10 из четырех дисков достигает двукратного превосходства в скорости над RAID1 из двух дисков только при значительной доле запросов на запись, потому, что массив RAID10 представляет собой два массива RAID1, объединённых в RAID0, а случайная запись на RAID0-массив всегда в два раза быстрее, чем на одиночный диск.

С массивом RAID5 не все так гладко. На примере контроллера 3Ware 7850 мы видели, каким должно быть поведение RAID5, однако в данном случае наблюдаются отклонения от тех результатов. Сначала массивы демонстрируют одинаковый рост производительности, а при возрастании числа запросов на запись, производительность начинает падать одинаково для обоих массивов на каждом шаге по оси х (как и положено для RAID5). Массив из трех дисков демонстрирует более высокую производительность чем массив из четырех дисков, а при малой доле запросов на чтение массив RAID5 из четырёх дисков не быстрее, чем массив из трёх дисков. А должен быть быстрее. В общем, много странностей и непонятностей.

Нагрузка в 16 запросов приводит к восстановлению “справедливости” в распределении скоростей массива RAID5. Поведение графиков становится правильным (падение производительности на каждом шаге по оси Х одинаково для всех массивов и не зависит от количества дисков в массиве), а массив из четырех дисков показывает более высокую производительность, чем массив из трёх дисков. У массивов RAID1, RAID10 и RAID0 из четырех дисков наблюдается интересный провал в скорости при 10% запросов на запись. В этой точке контроллер Intel® SRCS14L уже использует отложенную запись, так как запросы на запись уже есть, но их еще настолько мало, что кэширование не только не ускоряет работу, а напротив, приводит к почти бесполезной потере времени. Однако, уже в точке с 20-ю процентами запросов на запись вклад отложенной записи в производительность становится заметен.

При нагрузке в 256 запросов провал массивов RAID1 и RAID10 в точке 10% запросов на запись еще больше увеличивается, по причине, указанной выше. Особый интерес представляет производительность при случайном чтении (RandomRead). Судя потому, что производительность RAID1 из двух дисков в этой точке практически совпадает с производительностью одиночного диска, контроллер Intel® SRCS14L не использует технологию подобную Twinstor от 3Ware. С другой стороны, если сравнить скорость работы RAID0 из двух винчестеров и RAID1-массив, то можно увидеть, что последний почти так же быстр – но не в точках 0 и 10 – это просто ошибки/недочёты в алгоритмах контроллера, которые чередуют запросы на диски. Т.е. технология чередования у Intel все-таки работает, но нестабильно.

Характер графиков массивов RAID0 практически повторяет график одиночного диска (с учетом поправочного коэффициента на количество винчестеров), что говорит о том, что с этим режимом контроллер справляется прекрасно. Графики массивов RAID5 тоже не вызывают нареканий.

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


Как мы можем видеть, влияние отложенной записи велико при малых очередях и падает их ростом. Однако, в любом случае влияние положительно. Так почему бы не оставить отложенную запись винчестера всегда включенной? Да потому, что в этом случае, при неожиданном отключении питания вся информация, находящаяся в буфере винчестера теряется. Такое вот получается увеличение производительности за счет уменьшения надежности. Всегда приятно иметь свободу выбора – производительность или надежность, кошелек или жизнь:)…

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

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

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


График, для лучшего представления, разобьем на две части:


Масштабируемость скорости работы от количества дисков просматривается, но достигается максимальная скорость чтения только при достаточно больших размерах запроса, то есть тогда, когда контроллер разбивает большой запрос на несколько маленьких, которые выполняются несколькими винчестерами. Видимо поэтому, массив из четырех дисков дает почти такие же результаты, как и массив из трех. С другой стороны, нам известен размер страйпа – 64К. Уже при достижении размера блока в 256К массив из 4-х дисков должен быть в 4 раза быстрее одиночного диска. А мы этого не наблюдаем, и виноват в этом контроллер.


Как мы помним, некоторые производители практикуют чередование запросов на чтение между дисками зеркальной пары. Таким образом, RAID1-массив при чтении уподобляется RAID0-массиву, и скорость чтения с массива (теоретически) может удвоиться! Но как мы убеждаемся на очередном тесте, этот алгоритм в контроллере Intel® SRCS14L не применяется. Скорость чтения с массива RAID0 практически совпадает с RAID1. RAID10 демонстрирует почти идеальное удваивание скорости RAID1. Массивы RAID5 из трех и четырех дисков демонстрируют некоторый рост скорости с увеличением размера блока, однако рост характерный только для RAID5 начинается при размере блока 256КБ. Как мы помним, размер stripe-блока 64КБ, поэтому, рост скорости для массива RAID5 из трех дисков начинается при достижении 192КБ (просто у нас нет такой точки на графике), а для массива RAID5 из четырех дисков при блоке 256КБ. При этом последний массив начинает работать так быстро, что при мегабайтном блоке данных достигает максимальной показанной контроллером Intel® SRCS14L скорости чтения - 180 МБ/сек.

Теперь посмотрим, а вдруг отложенная запись влияет на последовательное чтение:).


Как видим, не влияет. Ну и хорошо:)

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


А теперь в графической интерпретации:


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


А вот при записи массивы RAID1 и RAID10 отстают от одиночного диска на блоках менее 64-х КБ. RAID5-массивы напротив, начинают отставать от одиночного диска при достижении блока 32 КБ.


Отключение отложенная записи винчестеров позволяет очень сильно уменьшить скорость работы. Кстати, такое большое отличие в скорости доказывает, что кэш контроллера Intel® SRCS14L, который всегда включен, уже не справляется с потоком информации и, в позапрошлом абзаце, мы зря заподозрили ни в чем не повинный процессор.

Теперь посмотрим, как поведет себя контроллер в реальной жизни:

IOMeter: Fileserver&Webserver

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

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


Массив RAID5 из четырех дисков уступает RAID10, а RAID5 из трех дисков даже массиву RAID1.


Так как в паттерне Fileserver доля операций записи составляет 20 процентов, то зависимость скорости от состояния отложенной записи невелика. С другой стороны, кэш контроллера Intel® SRCS14L явно внес свою лепту в уменьшение разницы, что особенно заметно в крайних точках графика.

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


Массивы, использующие зеркалирование - RAID1 и RAID10 демонстрируют прекрасные результаты. RAID10-массив обогнал RAID0-массив из трёх дисков. Массив RAID0 из четырёх дисков удержал первое место, но только потому, что в паттерне Fileserver присутствуют операции записи, которые RAID0-массив исполняет быстрее, чем массив RAID10. Массивы RAID5 из N дисков, отстают от массивов RAID0 из N-1 дисков, из-за тех же самых 20-ти процентов операций записи.

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

Характерное отличие от поведения графиков Fileserver’a заключается в том, что график одиночного диска и графики RAID0-массивов стартуют из одной точки. Причиной этого является то, что при линейной нагрузке не срабатывает преимущество RAID0-массивов в параллельной работе винчестеров. Пришедший запрос просто отсылается на соответствующий диск, и винчестеры работают по отдельности (размер запрошенного блока меньше размера страйпа).


Падение производительности RAID10 и RAID1 массивов при большой глубине очереди запросов является фичей (хотя я подозреваю багом) контроллера Intel® SRCS14L.


Как и в режиме последовательного чтения (Sequential Read), никакого влияния на скорость в режиме имитации работы Webserver’а, отложенная запись не оказывает.

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


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

IOMeter:Workstation

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

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


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


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

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

Ну и еще один довольно интересный рейтинг. Графики, показывающие зависимость скорости работы контроллера Intel® SRCS14L от состояния отложенной записи в последних трех паттернах были представлены выше. Здесь мы посмотрим сравнительный рейтинг этих паттернов.


Разница в производительности одного и того же паттерна, обусловлена состоянием отложенной записи винчестера, а разница в производительностях разных паттернов, обусловлена долей запросов на запись, и, в случае отключенной отложенной записи винчестера, влиянием на производительность отложенной записи контроллера (которая всегда включена). Поэтому паттерн Webserver, в котором запросы на запись отсутствуют, демонстрирует разницу в производительности в зависимости от состояния отложенной записи винчестера в пределах погрешности, и, по сравнению с другими паттернами его производительность самая низкая. Паттерн Fileserver с 20-ю процентами запросов на запись занимает второе место и по производительности и по разнице в производительности. Ну и Workstation, с самым высоким числом запросов на запись, занимает почетное первое место.

Winbench99

Завершаем этот обзор пакетом Winbench. Этот тест уже долгие годы служит нам именно в качестве "измерителя" производительности винчестеров при работе с "десктопными" приложениями.
Начнём, пожалуй, в этот раз с NTFS:


Не тратя время на рассматривание огромных серых и скучных таблиц, переходим к сравнению скоростей различных массивов по двум интегральным подтестам - Business Disk Winmark и High-End Disk Winmark:


RAID5-массивы пропустили всех вперед, RAID1-массив обогнал одиночный диск, а RAID10 пропустил вперед RAID0 из трех дисков.


Состояние отложенной записи оказывает значительное влияние.

Так как скорость линейного чтения и Average Access Time одинаковы для NTFS и для FAT32, то приведем по всего два графика для обеих файловых систем:


Как видите, зависимость скорости чтения с массивов от их типа у контроллера Intel несколько необычна (мягко говоря). Лидером по скорости чтения оказался массив RAID10 на четырёх дисках. Причём, достигнутая на нём скорость чтения составляет всего 114МБ/сек. (то есть равна скорости чтения c двух дисков WD Raptor). А что же остальные массивы?

Графики линейного чтения:

1HDD - JBOD
2HDD - RAID0
2HDD - RAID1
3HDD - RAID0
3HDD - RAID5
4HDD - RAID0
4HDD - RAID10
4HDD - RAID5

Заинтересовавшись феноменом неадекватности скорости чтения типу RAID-массива и количеству дисков в нём мы дополнительно провели тесты для RAID уровня 4.

Контроллер Intel SRCS14L поддерживает этот тип массива, но RAID4 используется не так широко, как RAID5, потому мы решили не рассматривать результаты RAID4 в этом обзоре.

3HDD - RAID4
4HDD - RAID4

Как видите, и здесь "не всё так просто...".

Результаты измерения Average Access Time:


Лидерами являются массивы, использующие зеркалирование - RAID1 и RAID10. Остальные массивы не демонстрируют заметной разницы во времени доступа.

Посмотрим на успехи контроллеров под FAT32:

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


Как и в случае NTFS, выключение отложенной записи у винчестеров оказывает значительное влияние на скорость работы массива.

Отказоустойчивость

Для проверки способности контроллера обеспечивать сохранность данных в массиве при отказе одного из дисков были смоделированы "аварии" одного из дисков в массивах RAID1, RAID5, RAID10.

Устроить "аварию" SATA-диску оказалось намного проще, чем диску со старым, добрым PATA-интерйфейсом. Благодаря тому, что питание дисков WD Raptor можно обеспечивать как через старый разъём питания, так и через SATA-разъём, то отказ диска легко сымитировать, выдернув из диска SATA-разъём питания.

Контроллер SRCS14L во всех трёх случаях обнаружил отказ одного из дисков и, после некоторой паузы, начинал процедуру восстановления целостности массива, используя HotSpare-диск (для случаев RAID1 и RAID5). При имитации аварии массива RAID10 мы оключили питания одному из дисков, дождались индикации работы массива в Degraded-режиме, заменили отказавший диск и убедились, что контроллер "подхватил" новый диск и начал процедуру восстановления целостности массива. Необходимо отметить, что "пауза на обдумывание" в последнем случае была намного больше, чем в случае работы с HotSpare-диском. Причём, во время процесса "обдумывания" контроллер не производил никаких дисковых операций...

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

Выводы

Итак, по результатам тестов контроллера Intel SRCS14L мы можем сказать, что со всеми своими функциями он вполне справляется.
Мы наблюдали и масштабирование скорости массива от количества дисков в нём, и то, что контроллер надёжно сохраняет данные в отказоустойчивых массивах (RAID1, RAID5, RAID10).
В то же время, мы наблюдали неудовлетворительную скорость контроллера во многих режимах. Заслуживает упоминания низкая скорость работы массивов RAID5 и RAID10 при малых нагрузках, и низкая скорость чтения с массивов RAID5...

Насколько контроллер Intel будет хорош на фоне конкурентов мы узнаем очень скоро, так что... оставайтесь с нами! :)