Контроллер 3Ware 7850

Введение

Как Вы могли заметить, некоторое время назад на нашем сайте появились две статьи "рекламного" характера. Несмотря на то, что с "рекламными" материалами мы боремся (:) ), эти две статьи, на мой взгляд, заслуживают того, чтобы для них было сделано исключение (лишь подтверждающее правило!).
Описываемые в этих статьях технологии StorSwitch и Twinstor составляют основу архитектуры контроллеров 3Ware и потому мне показалось, что перед тем, как вывалить на Вас тонну диаграмм и графиков, неплохо бы ознакомить Вас с подходами 3Ware к построению IDE RAID контроллеров.
Высказываемые в этих статьях тезисы не всегда бесспорны, но зато дают большую пищу для размышлений... Я даже втайне надеялся, что публикация этих статей вызовет шквал возмущённых откликов от поклонников SCSI-интерфейса, но, к моему сожалению, эта маленькая провокация не удалась. И теперь я нахожусь в недоумении - либо всё опубликованное на нашем сайте принимается на веру, либо... наоборот. :)

В этой статье мы рассмотрим новый контроллер 3Ware Escalade 7850, который, по большому счёту, отличается от ранее рассмотренного контроллера 3Ware 7810 только поддержкой больших дисков (>137ГБ) и новой технологией R5 Fusion, призванной улучшить производительность контроллера при работе с RAID5-массивами.
С другой стороны это уже третье поколение контроллеров 3Ware, с которыми нам довелось встретиться, и каждый раз после тестирования контроллеров этой фирмы мне не удавалось скрыть своих восторгов от их скорости и функциональности. Интересно, чем меня покорит этот контроллер? :)

Контроллер

Компания 3Ware прислала нам для тестирования коробочную версию контроллера 7850. Кроме самой платы контроллера в коробке находились восемь двадцатичетырёхдюймовых (!) 80-ти жильных ATA-шлейфа, четыре разветвителя питания и драйвера к контроллеру на компакт-диске и дискетах.
Особый мой интерес вызвали ATA-шлейфы нестандартной длины. Обычные ATA-шлейфы имеют длину 18" (45см.), но 3Ware утверждает, что её шлейфы соответствуют всем требованиям стандарта ATA. Что же, мы скоро проверим их в работе!

Внешний вид контроллера не претерпел больших изменений:

Но, как мы знаем, большое кроется в мелочах. Обратите внимание на микросхемы кэш-памяти:


Это по-прежнему очень быстрая SRAM-память, но объём одного чипа теперь составляет один мегабайт. На контроллере 7850 мы видим два таких чипа, и, следовательно, объём кэш-памяти контроллера составляет 2МБ. Если мы вспомним обзор 3Ware 7810, то у 7810 объём кэш-памяти составлял всего 1,125МБ.
Таким образом, отличие 7850 от 7810 найдено - больший размер кэш-буфера у 7850. Конечно, разница в ёмкости кэш-буферов у этих контроллеров невелика, но мы помним, как 3Ware 7810 вполне успешно конкурировал с Adaptec 2400A с кэш-буфером несоизмеримо большего размера. Так что каждый МБ кэш-буфера на контроллере 3Ware нужно ценить на вес золота.
Для чего же понадобилась контроллеру 7850 дополнительная кэш-память? Немного выше я упоминал, что одним из отличий контроллера 3Ware 7850 от 7810 является поддержка контроллером 7850 некоей технологии R5 Fusion. Что же это за супер-технология?

Технология R5 Fusion значительно улучшает быстродействие контроллера при работе с операциями записи на RAID5-массивах. Причём ускорение работы достигается и при записи больших последовательных блоков данных и при случайных запросах на запись блоков маленького размера.

3Ware заявляет, что использование этой технологии увеличивает устоявшуюся скорость записи на RAID5-массивы до 40-60МБ/сек., и что скорость 3Ware 7850 выше, чем у традиционных решений на SCSI RAID при вдвое меньшей стоимости дисковой подсистемы на ATA RAID по сравнению со SCSI RAID.

Идея отложенной записи, а именно она лежит в основе технологии R5 Fusion, отнюдь не нова и активно используется всеми производителями RAID-контроллеров с поддержкой RAID5. Как мы помним, именно за счёт отложенной записи контроллер Adaptec 2400A обыгрывал 3Ware7810 в нашем предыдущем сравнении аппаратных IDE RAID контроллеров.

Но в технологии R5 Fusion 3Ware пошла дальше банальной отложенной записи. Контроллер не просто откладывает в кэш запрос на запись и выполняет его в "удобный" момент, а некоторое время ждёт "продолжения банкета", т.е. контроллер ждёт, пока в кэше не заполнится данными "полный страйп".
Чтобы понять, какие выгоды сулит применение технологии R5 Fusion, рассмотрим случай, когда она не применяется. :)

В общем случае, при записи блока данных на RAID5-массив контроллер должен:

1. определить, на какой из физических дисков нужно будет записать данные,
   
2. считать блок данных с этого винчестера,
   
3. считать контрольную сумму страйпа,
   
4. сделать XOR блоков данных, полученных на этапах 2 и 3,
   
5. занести исходный блок данных в блок, полученный на этапе 2,
   
6. сделать XOR блоков данных, полученных на этапах 4 и 5
   
7. записать блок данных, полученный на этапе 5
   
8. записать контрольную сумму, полученную на этапе 6.
   

В частном случае если блок данных, который нужно записать на массив меньше по размеру, чем размер страйп-блока, можно читать на этапах 2 и 3 не полный страйп-блок, а только кусок, равный размеру блока, который мы хотим записать на массив. В таком случае контроллер при выполнении такого запроса с'экономит время работы XOR-процессора и время на сам процесс чтения и записи (так как читаются и пишутся блоки меньшего размера).
Но в любом случае каждый запрос на запись в массив RAID5 порождает два запроса к дискам на чтение, две операции XOR и два запроса к дискам на запись (назовём кратким термином "2-2-2").

Представим теперь, что на контроллер поступают запросы на запись блоков данных большого размера (больше, чем N-1*размер страйпа).

Как только в кэш-памяти контроллера из последовательных запросов на запись накапливается блок данных, объём которого равен размеру страйп-блока умножить на N-1 (количество полезных" винчестеров в RAID5-массиве из N-винчестеров), контроллеру не требуется делать операции чтения, так как изменению подлежат все блоки полного страйпа! Ему достаточно подсчитать контрольную сумму и сделать N-записей (N-1 блоков данных и контрольную сумму).
Если быть точнее, то при таком подходе не выполняется:

2*N-1 чтений
N-1 операций XOR
N-2 операций записи

И чем больше дисков в массиве, тем больше контроллер 3Ware 7850 экономит своё время и наши деньги! :)
Так как контроллер 3Ware не нагружает винчестеры лишними запросами, скорость обработки запросов растёт, а это значит, что растёт и скорость записи! И мы в этом скоро убедимся.

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

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

WinBench 99 1.2
IOMeter 1999.10.20

Для сравнения скорости работы контроллера в различных типах RAID-массивов при помощи теста IOMeter использовались новые паттерны StorageReview, анонсированные в третьей редакции их методики тестирования жёстких дисков.


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

На основании проведённого Storagereview исследования о характере нагрузки на дисковую подсистему при работе с обычными Windows-приложениями наш автор, Романов Сергей aka GReY, создал паттерн для теста IOMeter (паттерн создавался по усреднённой статистике IPEAK, приведённой на StorageReview для режимов работы Office, Hi-End и Bootup):


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

Дополнительно проведено сравнение скорости работы контроллера с различными типами RAID-массивов при изменяемом соотношении операций чтения/записи. Был создан паттерн, в котором использовались 100% случайные 8КБ-блоки данных, а соотношение числа чтений/записей менялось от 100/0 до 0/100 c шагом -10/+10.

Ну и, наконец, была проверена способность контроллеров работать с Sequential-запросами переменного размера на чтение и запись в различных типах RAID-массивов.

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

материнская плата - SuperMicro 370DLE
процессор - Intel P3 600E;
память - 2*128Mb SDRAM Micron PC133 ECC Registered;
винчестер - Quantum FB EL 10GB;
видеокарта - Matrox Millennium 4Mb;
операционная система - Windows 2000 Pro SP2;

Контроллер тестировался с firmware 7.5 и на драйверах той же версии. Для создания массивов использовались восемь дисков IBM DTLA 307015. Чтобы разместить с комфортом в тестовой системе восемь дисков, нам потребовался большой и вместительный корпус, оборудованный к тому же корзинами для винчестеров с принудительной вентиляцией. Как нельзя лучше для этих целей подошёл SuperMicro SC901D (Chieftec Dragon Seies):

Но при использовании больших корпусов при установке в них IDE RAID контроллеров и большого числа дисков возникает одна проблема. Эта проблема - недостаточная длина IDE-кабелей. Как правило, в корпусах количество отсеков под 3,5"-устройств невелико, и приходится использовать всевозможные корзины или мобайл-реки, устанавливаемые в 5"-отсеки. Так вот, зачастую, в высоких корпусах длины стандартных IDE-кабелей (18 дюймов или 45см) не хватает, чтобы дотянуться до 5"-отсеков. Хвала 3Ware, что она предусмотрела подобные ситуации и комплектует коробочные версии своих контроллеров IDE-кабелями с большей длиной (24" или 60см). Именно благодаря этому мне удалось так красиво (см. фото выше) уложить шлейфы. :)

Winbench

Первым нашим тестом будет Winbench99. Судя по прошлым тестам, аппаратные IDE RAID контроллеры не показывают высоких результатов в этом тесте. Но мы всегда надеемся на чудо! :)

RAID 0



Как видим, небольшая зависимость скорости массивов от количества винчестеров просматривается, но такой оптимизации, какую имеют под этот тест firmware RAID-контроллеры, у контроллера 3Ware нет и в помине. Наверное, она ему не нужна. :)



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


При линейном чтении максимальная скорость чтения зависит от количества винчестеров линейно же! Обратите внимание на шкалу по оси "X" - разметка на ней нанесена с шагом 36400. Это и будут наши попугаи, а точнее "дятлы", так как именно эту скорость линейного чтения показывает одиночный диск IBM DTLA 307015. Если мы посмотрим на диаграмму, то увидим, что линейная скорость чтения с RAID0-массива из N-дисков равна (или почти равна) N * 36400. Но такая зависимость соблюдается только до массива из пяти винчестеров. К сожалению, при большем количестве винчестеров в массиве пропускная способность контроллера ограничивается либо скоростью работы центрального чипа, либо пропускной способностью шины PCI 64/33МГц. Но, как бы то ни было, контроллер достиг скорости в 194МБ/сек. при линейном чтении.

RAID 5



Как видим, при работе с RAID5-массивами скорость контроллера падает. Что же, ничего удивительного - в тесте Winbench присутствуют и операции записи, а они отрицательно влияют на скорость контроллера, не обладающего большим кэш-буфером.


Размер стандартного кластера для NTFS Win2000 определяет в 4КБ, а так как размер страйп-блока для RAID5-массивов у контроллера 3Ware 7850 составляет неизменные 64КБ, то получается, что при записи контроллер выполняет много "лишней" работы. Соответственно, скорость контроллера уменьшается.

Посмотрим, как повлиял тип RAID-массива на скорость линейного чтения:


Оказывается, скорость линейного чтения с RAID-массива из N-дисков аналогична скорости чтения с RAID0-масива из (N-1)-дисков. И в этом нет ничего удивительного, так как каждый из дисков в RAID5 отдаёт 1/N-ую часть себя под хранение контрольной суммы. И при линейном чтении эти блоки игнорируются контроллером, так как не несут в себе полезной (в данном случае) информации.
Отметим, что "насыщение" скорости линейного чтения наступило при работе с RAID5 значительно раньше, чем при работе с RAID0-массивом.

RAID 1-10



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



То же самое мы наблюдаем и под NTFS.
А вот на диаграмме Disk Transfer Rate нас ждёт нечто интересное:


Посмотрите на скорость линейного чтения с RAID1-массива! Использование технологии Twinstor позволило увеличить скорость чтения с RAID1-массива за счёт интеллектуального чередования запросов на чтение на оба диска зеркальной пары. Однако для RAID10-массивов увеличения скорости не происходит. Скорость чтения с этих массивов равна скорости чтения c RAID0-массива из N/2 дисков, где N - число дисков в RAID10-массиве.
Получается, что технология Twinstor для последовательных запросов внутри RAID10-массива уже не работает?!
Проверим, как контроллер справляется со случайными запросами.

IOMeter: Database

Итак, контроллер бомбардируется запросами на чтение и запись 8КБ блоков данных, адрес которых вычисляется абсолютно случайно. В диаграммах приведены графики зависимости скорости обработки контроллером запросов от доли операций записи при глубине очереди команд в 256 запросов. На диаграммах по оси "X" откладывается доля операций записи в процентах, а по оси "Y" - скорость обработки контроллером запросов (Total I/O) в секунду.


Как видим, характер графиков массивов RAID0 с разным количеством дисков, в целом, одинаков и повторяет график работы одиночного диска. Что говорит о том, что StorSwitch справляется со своей работой (сортировка и передача запроса на соответствующий винчестер) прекрасно.


Массивы, в которых используется зеркалирование, совершенно определённо используют технологию TwinStor, так как при случайном чтении (RandomRead) скорость RAID10-массива превышает скорость работы RAID0-массива! Однако, обратите внимание на график RAID10-массива из восьми винчестеров. Чем больше растёт доля запросов на запись, тем больше скорость этого массива начинает приближаться к скорости работы RAID10-массива на шести винчестерах. Заметьте, что у "лесенки", которую составили три нижних графика в режиме RandomWrite, ступеньки были одинаковой высоты. А вот RAID10-массив "не сдюжил". Может быть, ему банально не хватило объёма кэш-буфера под отложенную запись - всё-таки восемь винчестеров...


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

Сравним скорости работы RAID10 и RAID5-массивов с одинаковым количеством дисков - весьма полезная информация для тех, кто хочет делать RAID-массив для SQL-базы.


Очевидно, что при случайном чтении эти массивы примерно одинаково эффективны. Но как только в потоке запросов появляются запросы на запись, RAID5-массивы очень резко теряют в скорости. Правда, при большой доле операций записи, ухудшение результатов в абсолютных величинах уменьшается, и разрыв между производительностью RAID10 и RAID5-массивов стабилизируется. При этом относительное превосходство в скорости RAID10 над RAID5 растёт.
Так что вопрос о выборе типа массива сводится только к вопросу цена-ёмкость-производительность. Если отбросить фактор объёма (так как объёмы современных дисков достаточно велики), то по соотношению цена/производительность RAID10-массив значительно эффективнее, чем RAID5. К тому же он обеспечивает и большую отказоустойчивость.

IOMeter: SequentialRead

Посмотрим, как контроллер справится с последовательными запросами на чтение. Суть теста состоит в измерении зависимости секундного объёма данных, которые контроллер будет считывать с массива, от размера запрашиваемых блоков. Глубина очереди команд принята равной четырём запросам.



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



С массивами, в которых применяется зеркалирование, всё ещё интереснее - посмотрите на резкое изменение скорости чтения при увеличении размера запрашиваемого блока данных за 64КБ! По всей видимости, это опять срабатывает технология Twinstor.
Например, возьмем массив RAID1 - как только размер запрашиваемого блока становится больше, чем размер страйп-блока, контроллер тут же делит запрос на две части и формирует два запроса к обоим винчестерам массива. При этом, скорость, соответственно, растёт, но вот почему не вдвое - загадка... Любопытно, что на блоке размером 512КБ скорость RAID1-массива даже снижается. По всей видимости, четыре таких запроса (queue=4) не помещаются в кэш контроллера (объём которого 2МБ, но часть этого объёма отведена под служебную информацию - статистику запросов и т.п.).
Примерно так же ведут себя и RAID10-массивы, но у них "порог срабатывания" технологии Twinstor (т.е. размер блока, при котором начинается чтение с обоих винчестеров в зеркальной группе) выше, чем для RAID1-массива. Всё правильно, ведь в RAID10-массивах задействовано большее количество винчестеров.



Что же, мы еще раз убеждаемся, что при чтении RAID5-массивы из N-дисков аналогичны по скорости RAID0-массивам из (N-1) дисков.

IOMeter: SequentialWrite

Посмотрим, как контроллер справится с последовательной записью. Особенно нам интересны результаты в RAID5, ведь в начале статьи я достаточно много времени посвятил "рекламе" 3Ware. Интересно, насколько "реклама" соответствует действительности. :)
Но сначала посмотрим на скорость контроллера в RAID0:



Хм... Вы видите то, что вижу я? Вот этот неожиданный всплеск быстродействия для массивов с количеством винчестеров больше четырёх при размере запрашиваемого блока в 32КБ определённо ставит меня в тупик...
Неужели это опять эффект кэширования в буфере небольшого размера?



Что любопытно, при записи на RAID10-массивы мы тоже можем наблюдать локальный всплеск быстродействия. Но только в этом случае размер блока, при котором происходит небольшойвсплеск скорости, составляет 16КБ, т.е. вполовину меньше, чем для RAID0-массивов. Всё чудесатее и чудесатее, как говорила Алиса...
Обратите внимание, что скорость записи RAID1-массива аналогична скорости записи на одиночный винт (и это правильно), но скорость записи ВСЕХ RAID10-массивов примерно равна скорости записи на RAID0 из двух винчестеров.



При записи на RAID5-массив никаких резких скачков скорости не наблюдается. Судя по всему применяемая технология R5 Fusion за счёт кэширования сглаживает эффект от увеличения размера блока. Скорость работы контроллера с массивом от этого не перестаёт зависеть от размера блока данных, но определённого "сглаживающего" эффекта 3Ware всё-таки достигла.
Как нам и было обещано, контроллер достигает скорости записи в 70МБ/сек. уже на массиве из пяти винчестеров! Отличный результат! И он достигнут на относительно старом винчестере IBM DTLA 307015. Полагаю, что если взять более современный винчестер, то для достижения скорости записи в 70 МБ/сек нам может хватить и четырёх винчестеров (всё-таки цены на контроллеры 3Ware 7850 и 7450 значительно отличаются).

Если мы вернёмся в прошлое на 9 месяцев назад, то в обзоре контроллера 3Ware 7810 мы могли видеть такую картину:

Обратите внимание, что на графике RAID5-массива (зелёный) при пяти винчестерах скорость последовательной записи спонтанно вырастает. Причём, достигнутое на пяти винчестерах значение скорости записи оказалось выше, чем у RAID5-массивов из шести, семи и восьми винчестеров.
Всё оказалось просто - так как тогда для тестов в Sequential-паттернах мы использовали блоки данных по 256КБ, то для RAID5-конфигурации из пяти дисков из 256КБ мы получали полный страйп (4*64КБ) для четырёх "рабочих" винчестеров. Firmware контроллера "поймало" этот момент и скорость записи на массив росла до 50МБ/сек.

Теперь же, благодаря технологии R5 Fusion, скорость записи на RAID5-массив из тех же пяти винчестеров достигает 70МБ/сек.

IOMeter: Workstation

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



Что же мы видим - стандартная картина. Чем больше винчестеров в массиве, тем быстрее он обрабатывает запросы. Однако массивы из шести и семи винчестеров несколько выбиваются из системы. При большой глубине очереди команд прирост скорости на этих массивах меньше, чем на остальных. Неужели контроллер 3Ware не справляется с такими конфигурациями? Однако, на восьмивинчестерном массиве контроллер показывает нормальную скорость! Может быть, полученная нами модель нагрузки плохо сочетается с таким количеством винчестеров в массиве при размере страйп-блока 64КБ? В общем, загадка.



Как видите, при работе с RAID10-массивами такой проблемы не возникает. Массивы с разным количеством винчестеров построились ровной "лесенкой"...
Я специально добавил в эту диаграмму результаты одиночного винчестера, чтобы ещё раз показать Вам действие технологии Twinstor. Очевидно, что скорость работы RAID1-массива выше, чем скорость одиночного винчестера даже при небольших нагрузках.



При работе в RAID5 наблюдается некоторое замедление работы с массивом из восьми винчестеров, но только при больших нагрузках.
Если же мы сравним скорости RAID10 и RAID5-массивов в этом паттерне:


То увидим, что RAID5-массивы потерпели полное фиаско. Неудивительно, ведь в этом паттерне операции записи составляют изрядную долю, а каждая операция записи, да ещё "случайная", изрядно уменьшает скорость работы RAID5-массива.

IOMeter: Fileserver

При работе с паттерном Fileserver мы изменяем диапазон нагрузки, но это не сильно повлияло на поведение контроллера при работе с различными массивами.



Как и в паттерне Workstation мы можем наблюдать небольшое проседание скорости на RAID0-массивах из шести и семи винчестеров.



Массив RAID1 по-прежнему быстрее, чем одиночный диск, а RAID10-массивы прекрасно масштабируются по скорости при увеличении количества винчестеров в массиве.



А при работе с RAID5 никаких видимых затруднений контроллер не испытывает на любом количестве винчестеров.
При сравнении скорости работы RAID10 и RAID5-массивов мы видим, что в этом паттерне массивы RAID5 выглядят намного лучше, чем в паттерне Workstation.


А получилось так потому, что в паттерне Fileserver доля операций записи составляет всего 20 процентов, тогда как в паттерне Workstation она составляет примерно 40 процентов.

IOMeter: Webserver

В паттерне Webserver запросы на запись отсутствуют, как класс, и потому можно ожидать, что RAID5-массив покажет примерно ту же скорость, что и RAID0. Что же, проверим! :)



Упс! Массив из восьми винчестеров смог доказать свою состоятельность только при больших значениях нагрузок. Неужели контроллеру не хватает быстродействия? Или, наоборот, диски тормозят контроллер...




Что интересно, в RAID10 никаких проблем с восьмидисковой конфигурацией не наблюдается. Не менее интересно и то, что в этом паттерне преимущество в скорости RAID1-массива над одиночным диском не такое явное, как в паттерне Fileserver или Workstation. Это весьма странно, ведь, когда в паттерне присутствуют только операции чтения, технология Twinstor должна давать максимальный эффект!

Посмотрим, есть ли эффект от Twinstor на RAID10-массивах. Для этого сравним скорость RAID10 и RAID0-массивов из восьми винчестеров:


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



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

Заключительным аккордом нашего обзора (на этом месте многие, наверное, вздохнут с облегчением) станет сравнение скорости работы в паттерне Webserver массивов RAID0, RAID5 и RAID10 из четырёх, шести, и восьми винчестеров.


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

Выводы

Контроллер 3Ware и в этот раз сумел меня удивить и порадовать. При работе с последовательными запросами на чтение и запись контроллер 3Ware 7850 не имеет себе равных среди IDE RAID-контроллеров.

Достигнутая контроллером скорость записи при работе с RAID5-массивом в 70МБ/сек. делает его реальным конкурентом SCSI RAID-контроллеров в задачах, связанных с обработкой больших потоков информации (например, при работе с высококачественным видео).

Прекрасная реализация работы с RAID10-массивами делает контроллер 3Ware 7850 хорошим выбором для File- и Web-серверов «бюджетного» уровня.

Высокая скорость работы контроллера с RAID5-массивами при случайном чтении делает его неплохим выбором для создания систем хранения данных с произвольным доступом.

По традиции, перечислим все плюсы и минусы контроллера

Плюсы:

Высокая скорость RAID5 при последовательных запросах на запись (>60МБ/сек. на четырёх винчестерах и >70МБ/сек. на пяти винчестерах)
Отличная масштабируемость контроллера в RAID0 при любом характере нагрузки
Отличная реализация RAID1 и RAID10-массивов

Минусы:

Отсутствие поддержки PCI 64/66МГц. Так как современные винчестеры способны выдать уже 50МБ/сек. при линейном чтении, то четыре таких винчестера полностью утилизируют пропускную способность PCI 64/33МГц. А если на контроллере восемь IDE-каналов, а заявленная пропускная способность StorSwitch составляет 800МБ/сек., то узким местом контроллера становится пропускная способность шинного интерфейса.

Сравнение контроллера 3Ware7850 с контроллерами конкурентов (в том числе и SCSI RAID-контроллерами) мы проведём в одной из наших следующих статей.

Непонятки

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

1. При создании RAID10-массивов больше чем на 4 диска BIOS контроллера «зависал» в режиме инициализации массива (дупликации зеркальных пар). Как правило, это происходило на 45-м проценте работы. После ресета контроллер считал массив полностью рабочим и готовым к работе, но как только я приступал к тестам, контроллер обнаруживал «некорректность» массива и заново активировал процесс инициализации массива. После завершения этого процесса под Windows массив был полностью готов к работе и никаких проблем в дальнейшем не вызывал.

2. Второй непонятный момент – то, что при создании RAID5-массива нельзя менять размер страйп-блока. Он всегда будет равен 64КБ, хотим мы этого или нет. Я полагаю, что фиксация размера страйп-блока связано с особенностями реализации технологии R5 Fusion, но если это не «баг», а «фича», то… предупреждать надо. :)

3. Неожиданные “проседания” в скорости работы контроллера на массивах с большим числом дисков.

Как видите, ничего смертельно-опасного мне при работе не встретилось, а еще раз проверить все эти проблемы мне предстоит в ближайшем будущем, так как у меня в руках уже находится...


P.S. Это не фейк, поверьте :)