Введение
Уже четвёртый (!) четырёхканальный SATA RAID-контроллер прошёл проверку в нашей тестовой лаборатории. На сей раз, в наших руках побывал контроллер Adaptec 2410SA. Компания-производитель позиционирует его как идеальное решение для рабочих станций и небольших серверов, где необходимо создание RAID - массивов и поддержка четырех винчестеров. В данном обзоре мы попробуем оценить, насколько это решение идеально. :)
Контроллер
Контроллер Adaptec Serial ATA RAID 2410SA сделан на базе процессора ввода/вывода Intel® 80302 100 МГц с аппаратным выполнением операции XOR для повышения производительности RAID5. Поддерживаются уровни RAID 0, 1, 5, 10 и JBOD. Работа с SATA-дисками ведётся при помощи двух контроллеров Silicon Image Sil3112A. Каждый чип имеет по два канала, каждый из которых поддерживает скорость передачи до 1.5Гбит/сек. Кэш-память у контроллера встроенная - 64МБ PC100 ECC SDRAM. Интерфейс 64-разрядной 66-MГц шины PCI 2.2, рассчитан на напряжение 3.3 В и 5 В.
Контроллер поставляется в "фирменной" стильной коробке:
В комплект, кроме самого контроллера, входят:
CD с драйверами, планка для установки платы в Low Profile корпуса, в дополнение к стандартной планке, прикрепленной к контроллеру, описание и четыре метровых SATA кабеля:
Сам контроллер выполнен в виде так называемой low-profile (низкопрофильной) PCI-платы, что вполне логично при расчете на применение его в простых серверах. Четыре SATA-разъема располагаются в ряд в вырезе на верхней кромке, чтобы разъемы SATA кабелей не "вылезали за габарит" контроллера. Прямо под ними находятся два контроллера Silicon Image Sil3112A и микросхема flash-BIOS, а процессор Intel® 80302 и две микросхемы памяти расположены справа:
Основные параметры:
Методика тестирования
Тестовая система:
корпус - 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.
Паттерны StorageReview
| File Server | Web Server
|
---|
| 80% Read, 100% Random | 100% Read, 100% Random
|
512b | 10% | 22%
|
1KB | 5% | 15%
|
2KB | 5% | 8%
|
4KB | 60% | 23%
|
8KB | 2% | 15%
|
16KB | 4% | 2%
|
32KB | 4% | 6%
|
64KB | 10% | 7%
|
128KB | 0% | 1%
|
512KB | 0% | 1%
|
Эти паттерны призваны измерить производительность дисковой подсистемы при нагрузке, типичной для file- и web-серверов.
Паттерн Workstation, используемый нами, создан нашим автором Романовым Сергеем aka GReY на основании статистики обращений к диску при работе различных приложений,
приведённой в описании SR Testbed3. Статистические данные собраны на файловой системе NTFS5 в режимах работы Office, Hi-End и Boot-up.
Паттерн Workstation
Transfer Size Request | % of Access Specification | % Reads | % Random
|
---|
Workstation
|
512B | 1 | 0 | 100
|
1KB | 2 | 0 | 100
|
2KB | 1 | 0 | 100
|
4KB | 50 | 60 | 80
|
8KB | 4 | 50 | 100
|
16KB | 6 | 50 | 100
|
20KB | 2 | 50 | 100
|
24KB | 2 | 50 | 100
|
28KB | 1 | 50 | 100
|
32KB | 13 | 70 | 70
|
48KB | 1 | 50 | 100
|
52KB | 1 | 50 | 100
|
64KB | 14 | 80 | 60
|
64KB+512B | 2 | 50 | 100
|
Этим паттерном мы будем руководствоваться для оценки привлекательности винчестеров для обычного Windows-пользователя.
Ну и, наконец, была проверена способность винчестеров работать с Sequential-запросами переменного размера на чтение/запись и скорость дисков в паттерне Database, имитирующем работу дисковой подсистемы с SQL-подобными запросами.
В контроллер было прошито firmware v9964 и использовались драйвера 4.0.0.5694.
Контроллер устанавливался в слот PCI-X/133МГц (хотя контроллер поддерживает только PCI64/66МГц).
Диски WD360GD (Raptor) устанавливались в штатные салазки корпуса SC5200 и крепились четырьмя винтами за нижнюю грань.
Контроллер "по умолчанию" тестировался с включённой отложенной записью в кэш (WriteBack). Также разрешалась отложенная запись для дисков.
Для проверки влияния алгоритмов работы кэша WB/WT были поведены тесты на четырёх-дисковых массивах RAID0, RAID5, RAID10. Как оказалось, алгоритм работы контроллера с кэш-буфером оказывает влияние на скоростные характеристики только в одном специфическом режиме.
К тому же, интерфейс настройки состояния отложенной записи в BIOS-е контроллера сделан таким образом, что при смене режима кэширования для буфера контроллера c WB на WT пользователю по умолчанию предлагается ещё и отключить отложенную запись на дисках. То есть, насколько мы понимаем, предполагается, что если пользователь выключает режим WB, то он хочет получить дисковый массив, максимально устойчивый к отказам. И, потому, нужно запретить дискам отложенную запись. При обратном переходе (с WT на WB) режим работы отложенной записи на дисках не изменяется! Действительно, зачем контроллеру думать за пользователя... ;)
После серии экспериментов мы пришли к выводу, что режим работы контроллера с кэш-буфером значительно в меньшей степени сказывается на скорости массива, чем включение/запрет отложенной записи на дисках. Судите сами.
Для примера мы взяли результаты работы массива RAID10 в паттерне Database. Термины WriteBack/WriteThrough относятся к режиму работы контроллера, а CacheOn/CacheOff - к отложенной записи для дисков.
Как мы можем видеть, состояние отложенной записи контроллера оказывает заметное влияние на результат только в режиме RandomWrite, а влияние режима работы кэша диска велико во всех режимах.
Мы предположили, что Adaptec Serial ATA RAID 2410SA - не единственный контроллер, в котором изменение режима работы отложенной записи контроллера может привести к изменению режима работы кэша диска (отложенной записи). В частности, в обзоре контроллера
3WARE 8500-8 Escalade различие в скоростях в режимах WriteBack и WriteThrough нельзя объяснить влиянием только кэша контроллера, так как его величина всего 2,25МБ. По видимому, при переключении между этими режимами изменялся и режим работы кэша дисков. Поэтому, чтобы не вносить путаницу в обозначения, которые использовались в предыдущих обзорах, в данном тестировании отложенная запись для кэш-буфера контроллера была разрешена всегда, а слова "WriteBack" и "WriteThrough" обозначают включенную и выключенную отложенную запись на дисках.
Результаты тестов
Традиционно, начнем обзор с тестирования работы контроллера в паттерне Database.
IOMeter: паттерн Database В этом паттерне мы посылаем смешанные запросы на чтение и запись блоков данных объемом 8КБ со случайным адресом. Изменяя соотношение запросов, мы можем выявить качество сортировки их драйвером контроллера.
Результаты работы контроллера в режиме WriteBack представлены в следующей таблице:
Рассмотрим их виде графиков. Зависимости скорости передачи данных от удельного веса запросов на запись построим для очередей с глубиной в 1, 16 и 256 запросов. Для большего удобства, разобьем массивы на две группы:
При линейной нагрузке, в режиме RandomRead, все массивы показывают очень близкие скорости. Но, если для массивов RAID0, RAID5 и одиночного диска совпадение скоростей чтения в этом режиме является естественным, то для зеркальных массивов RAID1 и RAID10 это означает, что чередование запросов между дисками зеркальной пары не производится.
С увеличением доли запросов на запись диски могут выполнять отложенную запись более эффективно, поэтому, скорость работы возрастает и у одиночного диска и у массивов. Скорость работы массивов RAID0 растет соответственно количеству дисков в массиве, но только за счёт отложенной записи дисков.
График массива RAID1 практически повторяет график одиночного диска, что говорит об отсутствии алгоритма интеллектуального чередования запросов по дискам при работе массива. График второго массива, содержащего зеркальные пары, - RAID10 менее "гладок". Тем не менее, за счёт того, что зеркальные пары объединены в RAID0, скорость RAID10 при такой нагрузке очень близка к скорости массива RAID0 из двух дисков.
Скорость массивов RAID5 должна снижаться по мере роста доли запросов на запись, так как запросы на запись очень сильно замедляют их работу. Однако, в данном случае, в некоторых режимах скорость массивов увеличивается. Вероятно, дело в том, что каждая операция записи на RAID5 порождает два запроса на запись, то есть средняя нагрузка на диски растёт. И, при таких условиях, эффективность отложенной записи дисков растёт.
Увеличение нагрузки меняет картину распределения скоростей. Зеркальный массив RAID10 показывает очень "ровную" скорость во всех режимах. По всей видимости, в режимах с преобладанием запросов на чтение высокая скорость обеспечивается за счёт чередования запросов между дисками зеркальных пар (именно это мы и наблюдаем в режиме RandomRead - скорость массива RAID10 выше, чем скорость RAID0 из четырех дисков и почти достигает удвоенной скорости RAID0 из двух дисков).
А в режимах с преобладанием запросов на запись "срабатывает" работа RAID0-составляющей массива RAID10.
Что интересно, для массива RAID1 технология чередования запросов между дисками не работает! И график скорости массива от доли запросов на запись практически повторяет график одиночного диска. Совершенно непонятно, почему для массивов RAID1 и RAID10 применены разные алгоритмы...
Для массивов RAID5 увеличение глубины очереди запросов "ввело в игру" все диски - запросы на чтение обрабатываются с той же эффективностью, как и для массивов RAID0. Но, конечно, по мере увеличения доли запросов на запись скорость массивов RAID5 падает.
Массивы RAID0, которые должны быть самыми быстрыми, везде, за исключением режима RandomRead, показывают наиболее высокие скорости из массивов с соответствующим числом дисков. Однако, нельзя не упомянуть о небольшом провале в скорости при десяти процентах запросов на запись у массива RAID0 из четырех дисков. Как мы можем вспомнить, подобный провал уже наблюдался в обзорах контроллеров
Intel SRCS14L,
Promise FT S150 TX4 и
3Ware8500.
Такая хорошая повторяемость "места провала" наводит на мысль, что причина его в алгоритмах отложенной записи используемых винчестеров.
Массивы RAID0 демонстрируют прекрасное масштабирование по количеству дисков. Исчез провал в графике массива из четырех дисков, однако, скорость массивов по сравнению с предыдущим режимом изменилась незначительно. Любопытно, что скорость одиночного диска очень близка к скорости массива RAID0 из двух дисков, в то время как массивы RAID0 из разного количества дисков образовали чёткие "ступеньки". Это говорит о том, что контроллер по-разному работает с одиночным диском и RAID0-массивами.
Что интересно, в режиме RandomRead четырех-дисковые массивы RAID0, RAID5 и RAID10 демонстрируют очень близкие скорости, хотя можно было бы ожидать небольшого преимущества RAID10. При такой нагрузке качество сортировки запросов между дисками уже не даёт массиву с зеркалированием никакого преимущества.
Впрочем, вышесказанное относится только к RAID10, потому что для RAID1 чередование запросов на чтение не производится.
Теперь посмотрим, как выглядят результаты тестирования массивов из четырёх дисков, при отключенной отложенной записи на дисках:
Построим сравнительную таблицу скоростей всех RAID-массивов при различных схемах кэширования. В каждой ее ячейке поместим результат деления скорости массива при включенной отложенной записи диска на скорость массива при выключенной отложенной записи дисков. Таким образом, по величине содержащегося в ячейке числа мы сможем судить о том, насколько снижается скорость работы винчестера при выключенном кэшировании в каждом конкретном режиме. Если число будет меньше единицы (такие числа подкрашены красным цветом), то это означает, что активированная отложенная запись уменьшает скорость массива, а если число будет больше единицы (такие числа подкрашены синим цветом), то отложенная запись привела к увеличению скорости массива, т.е. она полезно. Если же в ячейке мы видим число "1.0", то это означает, что для этого режима состояние отложенной записи дисков не влияет на скорость.
Сразу становится видно, что на все массивы отключение кэширования дисками запросов на запись оказывает только отрицательное влияние, правда степень этого влияния на каждый массив различна. Некоторое снижение скорости массивов в режиме RandomRead легко объясняются отсутствием запросов на запись. В остальных режимах, для всех массивов влияние кэширования увеличивается с ростом числа запросов на запись и, как правило, уменьшается с ростом глубины очереди.
Теперь сравним полученные результаты. Для этого построим графики каждого массива в режиме WriteThrough и WriteBack для очередей из 1, 16 и 256-ти запросов:
Отключение кэширования снижает скорость массива RAID0 во всех режимах кроме RandomRead. Максимальная потеря в скорости составляет 528%. Единственный режим, который вызывает некоторые сомнения – очередь из шестнадцати запросов при десяти процентах запросов на запись. Как уже упоминалось выше, провал в этом режиме при включенном кэшировании наблюдался нами и в других обзорах. Теперь мы, со стопроцентной уверенностью можем утверждать, что ответственным за него является кэш диска.
Отключение кэширования диска снижает скорость работы массива RAID5, так же как и скорость массива RAID0, во всех режимах кроме RandomRead. Абсолютная величина потерь в скорости несколько ниже - максимум 221%. Рост скорости массивов при увеличении числа запросов на запись под линейной нагрузкой, на который мы обращали внимание выше, связан с работой отложенной записи винчестеров. При отключении отложенной записи на дисках скорость массива RAID5 при любой глубине очереди плавно спадает с ростом числа запросов на запись.
Как и для предыдущих массивов, скорость работы RAID10 в значительной мере зависит от режима работы отложенной записи дисков. Максимальные потери в скорости массива при выключении у дисков отложенной записи составляют 226 процентов.
Работа кэш-буфера контроллера проявилась только в режиме RandomWrite - обратите внимание на резкое увеличение скорости массива под линейной нагрузкой при переходе в режим RandomWrite для массива из дисков с отключенной отложенной записью.
IOMeter: паттерны Sequential Read&Write Этот паттерн позволяет исследовать скорость работы контроллера при обработке последовательных потоков запросов на чтение/запись. На массив при помощи программы IOMeter подаётся поток запросов на чтение/запись с глубиной очереди команд, равной четырём. Раз в минуту в тесте меняется размер блока данных, так что после окончания теста мы получаем зависимость скорости линейного чтения или записи от размера блока данных.
Зависимость скорости чтения данных контроллером от размера их блока при активированной отложенной записи для дисков приведены в таблице:
Построим графики, разбив RAID-массивы на две группы:
Преимущества RAID0 массивов с большим количеством винчестеров начинают проявляться только при больших размерах запрашиваемого блока данных, то есть в случаях, когда контроллер может разбивать большие блоки на несколько маленьких и нагружать все винчестеры массива одновременно. Массив RAID0 из двух дисков достигает максимальной скорости только при размере блока в 512Кб. Массивам из трех и четырех дисков для выхода на максимальную скорость оказалось недостаточно даже блока размером в 1Мб.
График зеркального массива RAID1, как и в паттерне Database, практически полностью повторяет график одиночного диска, а график массива RAID10, в свою очередь, повторяет график массива RAID0 из двух дисков вплоть до провала в скорости при чтении блоков размером 128кБ. Из этого следует вполне логичный вывод, что алгоритм оптимизации чтения с зеркала при последовательных запросах не работает.
При отключенной отложенной записи на дисках результаты оказались следующими:
Отсутствие запросов на запись должно приводить к тому, что режим работы отложенной записи не должен оказывать никакого влияния на скорость контроллера. С некоторой натяжкой можно сказать, что так оно и есть. Но для каждого массива найдутся один – два размера блока, при которых разница скоростей массивов на «нормальных» дисках и дисках с отключенной отложенной записью превышает размер погрешности измерения. Логичного объяснения этому факту мы так и не нашли... :(
Теперь, посмотрим на поведение контроллера при последовательной записи.
Опять разобьем массивы на две группы:
Массивы RAID0 ведут себя практически так же, как и в режиме последовательного чтения. Исключением является режим записи блоков размером 256кб, где массив RAID0 из двух дисков работает быстрее всех остальных массивов. График массива RAID1 повторяет график одиночного диска. Для RAID5-массивов потоковые запросы на запись являются самым "некомфортным" с точки зрения производительности режимом, так что неудивительно, что массив из трех дисков при запросах размером 64Кб отстает по скорости от одиночного диска. Впрочем, и RAID10 работает медленнее массива RAID0 из двух дисков.
Сравним полученные результаты с тестированием в режиме с отключенной отложенной записью на дисках:
Наличие 100% запросов на запись является идеальным случаем для демонстрации влияния отложенной записи дисков на скорость массивов. И, действительно, снижение скорости при отключении кэширования происходит во всех массивах, однако, в массивах RAID0 и RAID10 это почти не заметно при размерах блоков менее 16-ти Кб.
IOMeter: Fileserver&Webserver Посмотрим, как контроллер справится режимом, имитирующим дисковые подсистемы файл- и веб-сервера.
Сначала, результаты тестирования контроллера в режиме имитации файл-сервера:
В графическом представлении эта таблица выглядит следующим образом:
Наличие всего двадцати процентов запросов на запись приводит к тому, что все массивы показывают очень неплохие результаты. Массивы RAID0 демонстрируют хорошую масштабируемость по скорости в зависимости от количества винчестеров. Массив RAID5 из четырех дисков почти догоняет массив RAID0 из трех. Скорость массива RAID10 приближается к скорости RAID0 из четырех дисков, и это значит, что в этом режиме алгоритм оптимизации чтения с зеркал работает прекрасно. А вот скорость массива RAID1 немного ниже скорости одиночного диска - в его работе алгоритм оптимизации чтения не используется.
Сравним производительность различных массивов, применив рейтинговую систему. Считая все нагрузки равновероятными, общий балл будем рассчитывать, как среднее значение скорости обработки контроллером запросов при всех вариантах нагрузки:
Массив RAID0 из четырех дисков лидирует, массив RAID10 немного отстал, но занимает почетное второе место. Массивы RАID5 из трех и четырех дисков немного отстают от массивов RAID0 из двух и трех дисков соответственно, А массив RAID1 не спасла и малая доля запросов на запись - он отстал даже от одиночного диска.
Посмотрим, как изменятся результаты при отключении отложенной записи:
Как видим, двадцати процентов запросов на запись оказалось вполне достаточно, чтобы скорость всех массивов с дисками, у которых отложенная запись отключена, была ниже, чем у массивов с "нормальными" дисками.
На производительности это отражается следующим образом:
С отключением кэширования дисками запросов на запись производительность массивов снизилась на 11-17 процентов.
Посмотрим на результаты работы контроллера при имитации файловой системы веб-сервера:
Графики массивов RAID0, по сравнению с Fileserver, качественно не изменились, а вот скорость массивов RAID5 значительно возросла, так как паттерн Webserver, в котором отсутствуют запросы на запись, - это оптимальный для них режим работы.
По этой же причине, зеркальный массив RAID10, в работе которого используется алгоритм оптимизации чтения с зеркал, в некоторых режимах, оказывается быстрее массива RAID0 из четырех дисков. Зеркальный массив RAID1, судя по скорости его работы, как и во всех предыдущих паттернах не использует этот алгоритм.
В рейтинговой системе, которую мы построили по тем же правилам, что и в паттерне Fileserver, места распределились следующим образом:
Массивы RAID10 и RAID5 использовали отсутствие запросов на запись на все сто процентов. Массивы RAID5 не только поднялись в рейтинге на одно место вверх, но и почти достигли производительности массивов RAID0 из соответствующего количества дисков. Массив RAID10 показал самую высокую производительность, а массив RAID1 опять, увы, отстал даже от одиночного диска.
Весьма интересно, что массив RAID10 показал максимальную скорость при нагрузке в 16 запросов, опередив массив RAID0, но при дальнейшем увеличении нагрузки скорость работы контроллера с массивом RAID10 немного падает.
Отложенная запись не должна влиять на скорости массивов в этом тесте, так как в нем отсутствуют запросы на запись, что мы и наблюдаем на графиках.
IOMeter:Workstation Переходим к паттерну Workstation, который позволяет имитировать интенсивную работу пользователя в различных приложениях на файловой системе NTFS5:
Для массивов RAID0 картина стандартна - чем больше винчестеров в массиве, тем быстрее он обрабатывает запросы. Скорость массива RAID1 близка скорости одиночного диска, а массив RAID10 только в некоторых режимах обгоняет RAID0 из трех дисков (если быть честным, то при глубине очереди в четыре запроса он обгоняет и RAID0 из четырех дисков, но это скорее исключение). Массивы RAID5 тоже показывают не самые высокие скорости, а при одиночных запросах работают медленнее, чем одиночный диск. Вообще говоря, это не удивительно, так как в паттерне Workstation много случайных запросов на запись, а они сильно снижают скорость массивов 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 оказалась ниже, чем у одиночного диска, а массив RAID5 из трех дисков отстал даже от массива RAID1. Массивы RAID0 выстроились по ранжиру с строгом соответствии с количеством дисков в массиве. Производительность массива RAID10 из-за большого числа операций записи, получилась ниже производительности массива RAID0 из трех дисков, хотя, как мы помним, скорость работы его, в некоторых режимах, была неплохой.
Посмотрим, как влияет состояние отложенной записи на работу массивов в этом паттерне:
Отключение кэширования запросов на запись дисками не приводит к изменению распределения массивов по скоростям, но заметно снижает "производительность" массивов. В зависимости от типа массива, скорость падает на 30 – 50 процентов.
Winbench99 Завершаем обзор пакетом Winbench, который служит нам измерителем производительности винчестеров в режиме имитации настольного компьютера. Тесты Winbench для каждого типа файловой системы проводилось два раза - на логическом диске размером с полную ёмкость массива, и на логическом диске в 32ГБ.
Сначала рассмотрим результаты тестирования в файловой системе NTFS:
Сравним скорости различных массивов в двух интегральных тестах - Business Disk Winmark и High-End Disk Winmark:
Массивы RAID0 и JBOD расположились по числу дисков в массиве. Массив RAID1, как и во всех предыдущих тестах, немного отстал от одиночного диска. Наличие большого числа операций записи в пакете, привело к тому, что массивы RAID5, которые очень медленно работают при записи, показывают очень низкие результаты. Массив RAID10 так же показал достаточно низкую скорость.
Теперь отключим отложенную запись у дисков и повторим тесты:
Все массивы при отключении кэширования заметно теряют в скорости.
Теперь посмотрим, как будет выглядеть контроллер в файловой системе FAT32:
Скорости работы массивов тестах Business Disk Winmark и High-End Disk Winmark выглядят так:
Распределение по скоростям практически не отличается от того, что мы наблюдали под NTFS, а вот по абсолютным величинам скорости возросли. Приятным исключением стал массив RAID10, который обогнал-таки одиночный диск. Неприятным исключением стал массив RAID1, чья скорость уменьшилась, и он переместился на последнее место.
Сравнивая результаты с измерениями в режиме, когда у дисков была отключена отложенная запись, получаем следующую картину:
Так же, как и в файловой системе NTFS, отключение кэширования оказывает исключительно отрицательное влияние на все массивы.
Скорости линейного чтения одинаковы для обеих файловых систем, поэтому мы приведем один общий график:
При взгляде на него сразу хочется поменять местами массивы RAID0 из трех и четырех винчестеров. Однако, сортировка по скорости чтения в начале диска дает именно такое распределение. При линейном чтении скорость линейно зависит от количества дисков, то есть массивы RAID0 из двух и трех и четырех дисков должны показывать соответственно удвоенную, утроенную и учетверенную скорость одиночного диска. Этого не наблюдается. Но, если в распределении скоростей массивов в конце диска соблюдается хотя бы порядок по количеству винчестеров в массиве, то в начале диска скорость чтения массива RAID0 из четырех винчестеров в начале диска ниже, чем в массиве RAID0 из трех дисков. Зависимость скорости массивов RAID5 от количества дисков наблюдается, но она не пропорциональна количеству дисков в массиве. Скорость линейного чтения с RAID1-массива примерно равна скорости одиночного диска, а RAID10 отстает от массива RAID0 из двух дисков.
Вообще-то, скорость линейного чтения не зависит от состояния отложенной записи, и в большинстве режимов, так и получилось. Интересно, что скорость чтения в начале диска в массиве RAID0 при отключении кэширования увеличилась.
По традиции, графики линейного чтения приводим для каждого массива отдельно:
График линейного чтения 1HDD - JBOD
График линейного чтения 2HDD - RAID0
График линейного чтения 2HDD - RAID1
График линейного чтения 3HDD - RAID0
График линейного чтения 3HDD - RAID5
График линейного чтения 4HDD - RAID0
График линейного чтения 4HDD - RAID5
График линейного чтения 4HDD - RAID10
Отказоустойчивость
Для проверки способности контроллера обеспечивать сохранность данных в массиве при отказе одного из дисков были смоделированы "аварии" одного из дисков в массивах RAID1, RAID5 и RAID10.
Как и в обзоре контроллера Intel SRCS14L отказ жёсткого диска имитировался выдергиванием из диска SATA-разъёма питания. Состояние массива контролировалось при помощи программы Adaptec Storage Manager-Browser Edition.
Восстановление массива под нагрузкой (когда контроллер, помимо проверки целостности данных, и их регенерации в случае необходимости, выполняет запросы от пользователей) - процесс слишком долгий, и я не мог позволить себе дожидаться его окончания. Потому нагрузка с контроллера снималась (т.е. попросту отключался тест), и фиксировалось время, потребовавшееся контроллеру для восстановления массива.
Для восстановления целостности данных контроллеру потребовалось:
RAID1 - 34мин.
RAID5 - 82мин.
RAID10 - 69мин.
Выводы
Итак, по результатам тестов контроллера Adaptec Serial ATA RAID 2410SA мы можем сказать, что, в общем, он показал себя неплохо. Массивы RAID5 и RAID0 демонстрируют хорошее масштабирование скорости массива от количества дисков в нём и приличную скорость работы. Контроллер надёжно сохраняет данные в отказоустойчивых массивах (RAID1, RAID5, RAID10).
Однако, в массиве RAID1 не используется алгоритм оптимизации чтения с зеркала, из-за чего скорость его работы всегда близка к скорости одиночного диска. По этой причине, массив RAID1 в контроллере Adaptec Serial ATA RAID 2410SA можно использовать только для повышения надежности хранения данных. Второй зеркальный массив RAID10, по-видимому, использует некий алгоритм оптимизации чтения с зеркала, причем результаты его тестирования вполне предсказуемы. Это дает надежду, что в следующих версиях драйверов/firmware массив RAID1 тоже начнет использовать этот алгоритм.
К отрицательным сторонам контроллера, а точнее, к недостаткам рассмотренной версии firmware Adaptec 2410SA можно отнести низкое влияние кэш-буфера контроллера на скорость массивов. Из опыта работы с Adaptec 2400A мы можем сказать, что кэш-буфер можно использовать и
более интенсивно...
Тем не менее, для рабочих станций и небольших серверов контроллера Adaptec Serial ATA RAID 2410SA вполне подойдет. Но, будет ли это лучшим решением, мы узнаем, лишь рассмотрев все контроллеры в этой серии, так что... Оставайтесь с нами! :)
Дополнение
Контроллер Adaptec SATA RAID 2410SA, как заявлено на сайте производителя, может работать во всех наиболее распространенных операционных системах. В частности, на диске, прилагающемся к контроллеру, находятся драйвера, поддерживающие следующие системы:
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Server
Microsoft Windows 2000 Professional
Microsoft Windows XP Home Edition
Microsoft Windows XP Professional
Microsoft Windows Server 2003
RedHat Linux 7.3
RedHat Linux 8.0
SuSE Linux 8.0
SuSE Linux 8.1
SCO UnixWare 7.11
Caldera Open Unix 8
Драйверы, поддерживающие неуказанные выше операционные системы, или просто более свежие версии драйверов всегда можно найти на сайте
производителя.
P.S. Честно говоря, драйверов для SCO UnixWare и Caldera Open Unix я там так и не обнаружил:)
Выражаем признательность компании
Adaptec и её Российскому дистрибьютору - компании
Альянс за предоставленный демонстрационный образец.