LSI MegaRAID SATA 300-8X

Введение

Сегодня мы рассмотрим новый восьмиканальный SATA II RAID контроллер от LSI Logic - MegaRAID SATA 300-8X. Контроллер этот расширяет возможности линейки SATA-контроллеров MegaRAID не только и не столько за счёт поддержки восьми дисков (против шести у старшей модели предыдущего поколения), но и, так сказать, вглубь.
Теперь, благодаря поддержке нового интерфейса SATAII, высокоскоростной шины PCI-X, большого объёма кэш-буфера и возможности использования батареи (для питания микросхем кэша при аварийном отключении питания сервера) контроллер можно смело записывать в высшую лигу...

Впрочем, и количество поддерживаемых дисков имеет очень большое значение. Действительно, количество винчестеров, которые теперь можно использовать на одном контроллере MegaRAID SATA 300-8X, позволяет построить на нём вполне самодостаточную отказоустойчивую дисковую подсистему.
Если на MegaRAID SATA 150-6 мы могли сделать только три массива RAID1 и у нас не оставалось свободных дисков для "запасного" диска, так называемого HotSpare (резервный диск для замены отказавшего в любом из массивов), что не позволяло заложить в дисковую подсистему должного запаса устойчивости к отказу дисков, то теперь мы можем распределить диски так:

Два диска в RAID1 - под систему
три диска в RAID5 - под базу данных
два диска в RAID1 под лог / бекап
Один диск под HotSpare

Конечно, если под базу нам захочется использовать RAID10 (а нам наверняка этого захочется, если процент запросов на запись в базу будет превышать хотя бы... впрочем, мы торопим события...), то придётся совмещать на одном массиве систему и лог:

три диска в RAID5 - под систему, лог / бекап
четыре диска в RAID10 - под базу
Один диск под HotSpare

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

Увеличивается надёжность системы (так как мы уменьшаем количество устройств, которые потенциально могут отказать);
Упрощается сопровождение и обслуживание сервера;
Дисковая подсистема "занимает" только один слот PCI-X.

Что же касается недостатков, то они, вполне логично, проистекают из достоинств. Чем более централизованна дисковая подстистема, тем более она чувствительна к выходу из строя своего краеугольного камня - контроллера. Впрочем, мы пользователи ответственные, и всегда имеем под рукой запасной контроллер. Не так ли? ;)

Но, пора вернуться к MegaRAID SATA 300-8X.

Функциональность контроллера выросла, в том числе, и за счёт поддержки более скоростной шины PCI-X. Так как дисков контроллер теперь поддерживает больше, да и пропускная способность интерфейса каждого из дисков повысилась вдвое, то новая шина приходится как нельзя кстати. Работая на частоте 133МГц шина PCI-X может прокачать в секунду (теоретически, конечно) в два раза больше данных, чем PCI64 66МГц - 1066МБ/сек против 533МБ/сек. В то же время, максимальная пропускная способность шинного интерфейса меньше, чем сумма пропускных способностей всех восьми дисков (8 x 300МБ/сек =2400МБ/сек).

Вдвое против контроллеров предыдущего поколения вырос и объём интегрированной на контроллере кэш-памяти. На контроллере MegaRAID SATA 300-8X установлено 128MB высокоскоростной DDR памяти с поддержкой ECC. К сожалению, не удалось найти в документации на какой скорости работает память, но, судя по маркировке чипов, скорее всего память работает на частоте 166МГц, то есть мы имеем дело с DDR333.

Контроллер поддерживает подключение батареи питания кэш-буфера - LSIiBBU01. При аварийном выключении питания, эта батарея (будучи предварительно заряжена под завязку) будет в течении 72 часов питать микросхемы кэш-памяти, не допуская краха содержащихся там данных.
Но самое интересное заключено в маленькой букве "i", которую мы можем найти в названии этой батарейки. Это, ни много ни мало - сокращение от "intelligent" - батарея совместима со спецификацией "Smart Battery Data Specification" и может сообщать контроллеру информацию о себе и своём текущем заряде.
Также к контроллеру можно подключать “простую” батарейку LSIBBU03 - она не оснащена интеллектом и её хватит только на 32 часа хранения данных в кэше при отключенном питании.
Контроллер поддерживает как SATA150, так и SATA300 диски и может делать из них следующие типы массивов RAID - 0, 1, 10, 5, 50. Контроллер умеет работать с двумя вариантами реализации технологии очереди команд - TCQ и NCQ, так что наши старые добрые Raptor2 не были забыты.

Итак, настала пора познакомиться с MegaRAID SATA 300-8X лично!

LSI Logic MegaRAID SATA300-8X

Поставляется контроллер в неброского вида небольшой коробке мрачных чёрно-синих тонов.



Внутри коробки мы обнаруживаем, прежде всего, сам контроллер:


и, конечно, стандартный джентльменский набор:


из набора метровых SATA-кабелей (8 штук по числу дисков), руководства по установке контроллера и программного обеспечения.
Контроллер MegaRAID SATA 300-8X, как заявлено на сайте производителя, может работать в следующих системах:

DOS (уряяяя!!!)
FreeBSD
Netware 5.1, 6.X
Redhat AS 3.0
Redhat AS 4.0
SLES 9
SUSE 9.1
SUSE 9.2
Sco OSR Unix 5.x
UnixWare 7.x
Windows 2000
Windows 2003
Windows Server 2003 (64 bit)
Windows XP

Драйверы, поддерживающие указанные выше операционные системы, или просто более свежие версии драйверов всегда можно найти на сайте производителя.

Рассмотрим поближе два главных чипа контроллера.


Слева у нас чип ввода/вывода (шинный интерфейс, XOR-операции и т.п.), а справа - восьмиканальный SATAII-чип от Marvell (он отвечает за работу с дисками).
Не могу удержаться от соблазна взять чип Intel® IOP331, что называется, крупным планом:


Почти Малевич, не находите? :)
Процессор, согласно документации, почёрпнутой с сайта Intel, может работать на частоте 800МГц, но данных о частоте его работы на контроллере MegaRAID SATA 300-8X на web-сайте LSILogic обнаружить не удалось. Судя по маркировке процессора, частота его работы установлена в 250МГц (также приняты во внимание характеристики контроллера Intel SRCS28X, который является братом-близнецом контроллера MegaRAID SATA300-8X). ;)
Процессор оснащён двухпортовым контроллером памяти DDR SDRAM, максимальный объём которой может достигать 2ГБ. Однако, как мы помним, на контроллере установлено 128МБ кэш-памяти и расширять этот объём, увы, нельзя.
Впрочем, для этого класса контроллеров вполне достаточно и 128МБ кэша.

Чуть выше мы говорили о батарейке, а теперь мы её покажем. Правда, мы её уже установили на контроллер.



Ох и доставила нам эта батарейка хлопот... Но обо всём по порядку!

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

Про контроллер осталось рассказать только одно - на разъёмы для подключения дисков нанесён некий клейкий состав, который должен улучшить сцепление разъёмов контроллера и кабеля SATA и, тем самым, улучшить надёжность контакта. Вспоминая реактивную тягу вентиляторов некоторых корпусов Intel, можно только поапплодировать такой находке.
Однако, такое решение имеет и недостатки. Если Вы откроете фотографию контроллера с присоединённой батарейкой, обратите внимание на SATA-разъёмы. С некоторых из них клейкое покрытие попросту исчезло. Виной тому многократные подключения/отключения кабелей, которые мы, поверьте, проводили без всякого злого умысла.
Мораль сей басни проста - подключили кабели к контроллеру - не трогайте их, если всё работает...

Итак, пора перейти к делу!

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

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

корпус - Intel SC5300Base
материнская плата - Intel SE7520BD2;
процессор - 2 x Intel Xeon 2.8/533FSB;
память - 2 x 512MB DDR SDRAM PC2100 ECC Registered;
винчестер - IBM DTLA 307015;
видеокарта - onboard ATi Rage XL;
операционная система - Windows 2000 Pro SP4.

И наш стандартный набор тестов:

FC-Test v1.0 bild 13
IOMeter 2003.02.15

При помощи IOMeter была проверена способность контроллера работать с Sequential-запросами переменного размера на чтение/запись и скорость массивов в паттерне Database, имитирующем работу дисковой подсистемы с SQL-подобными запросами.
Сравнение скорости работы массивов проводилось с использованием паттернов Fileserver, Webserver и Workstation.

Для FC-Test мы использовали наши стандартные пять наборов файлов (Install, ISO, MP3, Programs и Windows) с которыми проводились операции записи (создания файлов на диске), чтения с диска и копирования файлов.

Контроллер тестировался с прошивкой FW_813I и драйверами 5.49. Устанавливался контроллер в слот PCI-X/133МГц.
Диски WD740GD (Raptor) устанавливались в корзину AXX6SATADB (SATA 6-Hot-Swap Drive Bay Upgrade)
Тестирование проводилось только на четырех винчестерах, поэтому массивы RAID50 не исследовались.

Что касается настроек контроллера, то тут есть о чём поговорить. Причём, тем для разговора хватило бы для нескольких статей.
Дело в том, что SATA-контроллеры LSI имеют мощнейший BIOS, содержащий огромное количество настроек. Разобраться с ним было крайне тяжёло даже при наличии документации. Чаще всего загвоздки “тонких мест” разрешались при помощи серии экспериментов, а это отняло уйму, ну просто уйму времени.

В итоге, мы решили остановиться на следующей комбинации настроек:


Итак, для массивов RAID0 и RAID5 "ширину полоски" aka Stripe Size мы выбрали равной 64КБ.
Так как контроллер оснащён кэш-буфером солидного размера, то мы решили дать ему (контроллеру) возможность блеснуть своими способностями в прогнозировании характера запросов к массивам, назначив политику упреждающего чтения как "Adaptive Read Ahead".
Также мы разрешили контроллеру выполнять отложенную запись на массив, используя кэш-память контроллера. Отложенная запись дискам также разрешалась, правда, эти настройки производятся в другом разделе BIOS контроллера.
И, наконец, режим обработки запросов контроллером был выбран "Direct". Впрочем, наши эксперименты показали, что этот пункт не влияет на производительность контроллера (или его влияние ничтожно мало...).

Эти настройки мы назвали для себя "настройками на максимальную производительность", так как нас, за неимением времени ("познание бесконечности требует бесконечного времени" (с) ) интересовали предельные возможности контроллера.
Конечно, для увеличения надёжности дисковой подсистемы лучше запретить отложенную запись дискам, а для увеличения скорости контроллера при работе, например, в режиме веб-сервера лучше поставить политику упреждающего чтения в "Normal", но, как сказали классики "нельзя объять необъятное" (с).

Так что, контроллер мы тестировали с такими настройками и пусть тот, кто может, сделает больше. ;)

Строго говоря, мы провели два полных цикла тестирования. Первое время у нас не было на руках батарейки LSIiBBU01 и контроллер не давал нам использовать Write Policy = Write Back (что крайне мудро с точки зрения надёжности хранения данных на массиве). Однако, руководствуясь поистине иезуитской логикой, контроллер разрешал таки выставить принудительно Write Policy = Write Back, но эти настройки действовали ТОЛЬКО до первой перезагрузки сервера!
Так как наша методика тестирования предусматривает многократные перезагрузки (собственно, тестовый скрипт начинается с команды на перезагрузку ;) ), то несколько дней у нас ушло на попытки выяснить "почему производительность контроллера с WB равна его производительности при WT".

Итак, мы провели два полных цикла теста контроллера, перебрав все возможные типы массивов, которые можно организовать из четырёх дисков.

Режимы с разрешенной и запрещенной отложенной записью винчестера указаны как WriteBack и WriteThrough соответственно. Данные в таблицах приведены для всех режимов, однако графики для режима WriteThrough мы строили только для четырехдисковых массивов и только в тестах IOMeter

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

Традиционно, начнем обзор с тестирования работы контроллера со смешанными потоками запросов:

IOMeter: паттерн Database

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


Рассмотрим их виде графиков. Зависимости скорости обработки контроллером запросов от удельного веса запросов на запись построим для очередей с глубиной в 1, 16 и 256 запросов, а, для большего удобства анализа результатов, разобьем массивы на две группы:


При линейной нагрузке, в режиме RandomRead, все массивы показывают очень близкие скорости. С увеличением доли запросов на запись жёсткие диски могут выполнять отложенную запись более эффективно, поэтому, скорость работы одиночного диска возрастает.
Скорость работы массивов RAID0 тоже растет соответственно количеству дисков в массиве, однако пропорциональность скоростей количеству дисков в массиве не наблюдается даже в режиме RandomWrite (обратите внимание на неравномерность ступеньки между двух- и трёх-дисковым массивом).


Массивы, содержащие зеркальные пары (RAID1 и RAID10) явно используют алгоритм чередования запросов между дисками внутри зеркала - это видно по увеличению производительности (по сравнению с JBOD и RAID0 из двух дисков) в режимах с преобладанием запросов на чтение. Однако, в режимах с большой долей запросов на запись алгоритм чередования запросов теряет свою эффективность. Это заметно на примере массива RAID1 - при доле запросов 70-90 процентов быстродействие массива неожиданно резко снижается.

Согласно теории, скорость массивов RAID5 должна снижаться по мере увеличения доли запросов на запись. Однако, в данном случае, в скорость обоих массивов практически не меняется во всех режимах. Кроме того, производительность массивов RAID5 из трёх и четырёх дисков практически не отличается...

Увеличим нагрузку на массивы:


Увеличение нагрузки приводит к тому, что пропорциональность скоростей количеству дисков в массивах RAID0 становится заметна уже в режиме со ста процентами запросов на чтение. Однако, в режимах с большой долей запросов на запись картина выглядит нелогичной. Налицо различное поведение двух групп массивов (из одного-двух и трёх-четырёх дисков) - как будто они исповедуют различную политику кэширования. Может быть дело в различной квоте на использование кэш-буфера?
Вполне логичное предположение, ведь кэш-буфер можно делить либо пропорционально количеству дисков, подключенных к контроллеру, либо пропорционально количеству и типу массивов.
В данном случае, так как мы видим более агрессивное использование отложенной записи для массивов из малого количества дисков, можно предположить, что используется первый подход.

Сделаем маленькое лирическое отступление...

<---начало лирического отступления---

Возможно, что обнаруженный эффект, как бы это сказать по-деликатнее, тесно связан с практикуемой нами методикой тестирования RAID-контроллеров.

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

В реальной же жизни велика вероятность того, что к контроллеру сразу подключат максимально возможное количество дисков, которое контроллер поддерживает (а иначе зачем ещё выбрали именно этот контроллер).
Соответственно, если наша догадка верна, то быстродействие массивов будет отличаться от того, которое получилось в наших тестах.
Что же, согласно старой присказке "Чем дальше в лес, тем толще партизаны"... ;)

---конец лирического отступления--->

Посмотрим, чем нас удивят массивы RAID5 и RAID10.


Очевидно, что массивы RAID5 при такой нагрузке оказались намного более медленными, нежели массивы, использующие зеркалирование. Конечно, по мере увеличения запросов на запись, производительность всех массивов постепенно снижается, но мы никак не ожидали, что быстродействие массива RAID1 будет сопоставимо с быстродействием RAID5 из трёх дисков.
В режимах с преобладанием запросов на чтением массивы RAID1 и RAID10 быстрее за счёт интеллектуального выбора оптимального (для выполнения конкретного запроса) диска из зеркальной пары. Но вот почему так медленны массивы RAID5 при записи?
Судя по тому, что мы опять наблюдаем, а, точнее, не наблюдаем особой разницы в производительности RAID5-массивов из различного количества дисков в режимах с большой долей запросов на запись, то, пожалуй, стоит подумать о недостаточной вычислительной мощности XOR-процессора.
Всё говорит о том, что узкое место - расчёт контрольных сумм...

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



Увеличение нагрузки до 256-ти запросов в очереди уже не приводит к существенным изменениям в поведении графиков массивов.

Для истинных ценителей приводим результаты контроллера при Write Policy = WriteThrough.

Сравним "эффективность покупки батарейки", используя нашу любимую форму представления данных - таблицу.
Цифра в каждой ячейке таблицы отражает отношение скорости массивов, полученной в режиме WriteBack и скорости того же массива, полученной в режиме WriteThrough. Чем больше цифра, тем более оправданно совместное использование батареи и WriteBack-политики кэширования.


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

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




Отключение кэширования запросов на запись, как и следовало ожидать, снижает скорость массива RAID0 во всех режимах кроме RandomRead. Максимальная потеря в скорости при отказе от WriteBack наблюдается при линейной нагрузке и составляет 478%.




На скорость массива RAID5 отключение кэширования запросов на запись влияет неоднозначно. При низких нагрузках это влияние отрицательно и приводит к снижению скорости работы. При высоких нагрузках это влияние положительно и может увеличить скорость. Однако, если максимальная потеря в скорости составляет 165%, то максимальный прирост - всего 15%.
С чем связано падение производительности на массивах RAID5 при использовании отложенной записи - сказать трудно.




Скорость работы массива RAID10 при отключении кэширования диска всегда снижается по мере увеличения доли запросов на запись.

Таким образом, можно сказать, что использование политики WriteBack (на всякий случай напомним, что наличие батареи при этом - обязательно) может существенно увеличить скорость обработки запросов записи. Исключение составляет работа массива RAID5 при крайне высоких нагрузках (практически недостижимых в нормальной работе).

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

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


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


Преимущества RAID0 массивов с большим количеством винчестеров начинают проявляться только при больших размерах запрашиваемого блока данных, то есть в случаях, когда контроллер может разбивать большие блоки на несколько маленьких и использовать винчестеры параллельно. В данном случае, массивы RAID0 показали себя неплохо. Массивы из двух и трех дисков достигли максимальной скорости уже при размере запроса в 64 КБ, а массив из четырех дисков при 128 КБ. При этом, масштабируемость скорости чтения по количеству дисков в массиве почти идеальна.


Зеркальные массивы RAID1 и RAID10 смотрятся гораздо хуже. Скорость их работы в большинстве режимов близка к скорости одиночного диска и массива RAID0 из двух дисков соответственно, Однако в некоторых режимах (особенно при больших размерах блока), скорости чтения зеркальных массивов значительно ниже скоростей массивов, составляющих зеркала.
Массивы RAID5 тоже выглядят не лучшим образом. Если в режимах с размером блока 64КБ и менее поведение их скорости еще объяснимо, то уже при блоке в 128КБ падение скорости чтения превосходит все разумные границы.
В режиме WriteThrough результаты оказались следующими.

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


Отсутствие запросов на запись должно приводить к тому, что влияние кэширования должно быть не заметно. С некоторой натяжкой можно сказать, что так оно и есть. В большинстве режимов влияния кэширования нет, но для каждого массива найдутся один – два размера блока, при которых разница скоростей в режимах WriteBack и WriteThrough превышает размер погрешности.

Теперь посмотрим на поведение контроллера при последовательной записи. Скорости прокачки данных контроллером, в зависимости от размера их блока в режиме WriteBack приведены в таблице:


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


Так же как и в случае последовательного чтения преимущества RAID0 массивов с большим количеством винчестеров начинают проявляться только при больших размерах запрашиваемого блока данных. Однако, если массив RAID0 из двух дисков достиг максимальной скорости при запросах в 64КБ, то массив из трех дисков только при запросе в 256КБ, а четырехдисковый массив не достиг максимальной скорости даже при запросе в 1024КБ (упёрлись в максимальную скорость работы I/O-процессора?).


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

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


Наличие 100% запросов на запись является идеальным случаем для демонстрации влияния кэширования на скорость массивов. И, действительно, снижение скорости при отключении кэширования происходит для всех массивов. И какое снижение! 8)

IOMeter: Fileserver&Webserver

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


В графическом представлении эта таблица выглядит следующим образом:



Наличие всего двадцати процентов запросов на запись приводит к тому, что все массивы показывают очень неплохие результаты. Массивы RAID0 демонстрируют очень хорошую масштабируемость по скорости в зависимости от количества винчестеров. Скорости массивов RAID1 и RAID10 приближаются к скоростям массивов RAID0 из двух и четырех дисков соответственно, и это значит, что в этом режиме алгоритм оптимизации чтения с зеркал работает прекрасно. Только массив RAID5 из четырех дисков при глубине очереди в 256 запросов выбивается из общей картины. Что-то неладное творится с этим массивом при высоких нагрузках во всех паттернах.
Сравним производительность различных массивов, применив рейтинговую систему. Считая все нагрузки равновероятными, общий балл будем рассчитывать, как среднее значение скорости


Массив RAID0 из четырех дисков лидирует с большим отрывом. Массив RAID10 немного отстал, но занимает почетное второе место. Массивы RАID5 из трех и четырех дисков немного отстают от массивов RAID0 из двух и трех дисков соответственно. Массив RAID1 занимает предпоследнее место, однако отрыв его от одиночного диска значителен.
Посмотрим, как изменятся результаты в режиме WriteThrough и сравним их с предыдущими:



Даже двадцати процентов запросов на запись оказалось вполне достаточно, чтобы скорость всех массивов в режиме WriteBack заметно отличалась от их скорости в режиме WriteThrough. Массив RAID5 при очереди в 256 запросов уже привычно отличился.

На средневзвешенной производительности это отражается следующим образом:


Очевидно, что в режимах с наличием запросов на запись отключение WriteBack кэширования приводит к снижению производительности.

Посмотрим на результаты работы контроллера при имитации файловой системы веб-сервера:





Графики массивов RAID0, по сравнению с Fileserver, качественно не изменились, но скорость их стала ниже. Скорости массивов RAID5 значительно возросли, так как паттерн Webserver, в котором отсутствуют запросы, на запись - это их оптимальный режим работы. По этой же причине, зеркальные массивы RAID1 и RAID10, в работе которых используется алгоритм оптимизации чтения с зеркал, во всех режимах, оказываются быстрее массивов RAID0 двух и четырех дисков соответственно.
В рейтинговой системе, которую мы построили по тем же правилам, что и в паттерне Fileserver, места распределились следующим образом:


Массивы RAID10 и RAID5 использовали отсутствие запросов на запись на все сто процентов. Массивы RAID5 не только поднялись в рейтинге на одно место вверх, но и почти достигли производительности массивов RAID0 из соответствующего количества дисков. Массив RAID10 показал самую высокую производительность, а массив RAID1 прилично оторвался от массива RAID0 из двух дисков.
Результаты работы контроллера в режиме WriteThrough:



Данные графики весьма наглядно демонстрируют нам, что никакого влияния на производительность массивов при работе в таком режиме (отсутствие запросов на запись) включение отложенной записи не оказывает!
Также хотелось бы отметить блестящие результаты массива RAID10 - на всех на вариантах нагрузки массив RAID10 быстрее RAID0!


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

IOMeter:Workstation

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


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



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

Посмотрим, как влияет состояние отложенной записи на работу массивов в этом паттерне:





Отключение кэширования заметно снижает скорость, а производительность падает почти на треть.

Многопотоковое чтение/запись

В данном паттерне мы исследуем способность контроллера осуществлять многопотоковую последовательную запись/чтение, имитируя одновременную нагрузку на дисковую подсистему со стороны нескольких приложений, затребовавших "большие файлы". Специальный тестовый агент программы IOMeter (в терминах IOMeter - Worker), изображая каждое приложение, последовательно читает/пишет блоками по 64КБ данные, начиная с некоторого стартового сектора. Увеличивая количество исходящих запросов от Worker-а (от одного до восьми с шагом 1) мы исследуем способности диска или контроллера к переупорядочиванию запросов (склеивания нескольких запросов на последовательно расположенные данные в один запрос). Увеличивая количество одновременно работающих Worker-ов, мы усложняем работу дисковой подсистемы - как и в реальной ситуации несколько одновременно работающих программ конкурируют между собой за доступ к дискам. Каждый Worker работает со своими данными (т.е. адреса запрашиваемых блоков у разных Worker-ов не пересекаются).





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


При нагрузке в один запрос на одном потоке мы не получили уверенного масштабирования скорости чтения от количества дисков ни в массиве RAID0 ни в массиве RAID5. Скорость одиночного диска оказалась выше скорости массива RAID1, а вот зато массив RAID10 показал наиболее высокие результаты. Судя по тому, что с массива RAID0 не удалось вытянуть больше, агрессивного упреждающего чтения ни контроллер, ни диски не производят.
На двух одновременно выполняемых потоках массив RAID1 оказался на высоте (идеальный случай - каждый диск отдаёт "свои" данные). А вот скорость всех остальных массивов неожиданно резко снизилась, хотя и проявилась масштабируемость скорости от количества дисков в массивах RAID0 и RAID5. Конечно, при двух потоках головкам жёстких дисков приходится постоянно перемещаться между двумя рабочими зонами, так что о достижении скорости линейного чтения с массива можно забыть.
Используемые для тестов диски имеют оптимизацию для использования в серверах, то есть упор сделан на малое время доступа. Поэтому, ожидать упреждающего чтения от них не стоит. Однако, почему контроллер не делает упреждающего чтения - непонятно. Ведь мы ясно поставили в настройках системы кэширования - Adaptive Read Ahead! И где, собственно, адаптивность алгоритма?

Дальнейший рост числа потоков приводит к росту скоростей массивов RAID0 и RAID5 и к падению скорости зеркальных массивов.

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


А при записи у нас немного, но "провалились" по скорости массивы, использующие зеркалирование - они почти во всех режимах медленнее одиночного диска и массива RAID0 из двух дисков. А вот массивы RAID5 подобная нагрузка практически “похоронила”. Правда, при обработке одного потока, массив RAID5 из четырех дисков показал себя неплохо, но это был единственный всплеск разума...

Массивы RAID0 тоже отличились. Если массивы из двух и четырех дисков довольно хорошо справились с обработкой одного и двух потоков, то массив из трех дисков “умудрился” отстать от всех. При трёх и четырёх одновременно исполняемых потоках мы вновь наблюдаем масштабирование скорости массивов RAID0 из двух и четырех дисков от количества дисков в массиве и бессовестное отставание от всех массива из трех дисков.
Для особо интересующихся, приводим результаты тестирования контроллера в режиме WriteTrough без анализа:






FC-test

А теперь попробуем испытать контроллер в "однопользовательском" режиме при помощи теста, работающего не с секторами, а с файлами.

Мы применяем FC-Test по нашей стандартной методике - на массиве создавалось два логических диска по 32 GB, и они размечались сначала в NTFS и, затем, в FAT32. На первом логическом диске создавался набор файлов, затем этот набор файлов читался с диска, затем набор файлов копировался в директорию, созданную на первом логическом диске (т.е. производилось копирование внутри одного раздела), и завершало цикл тестов копирование первого набора файлов на второй логический диск.
Между каждым тестом проводится перезагрузка компьютера, тем самым мы исключаем влияние файлового кэша операционной системы на результаты тестов.
Всего мы используем пять наборов файлов:

Install - 414 файлов общим объёмом 575МБ;
ISO - три файла общим объёмом 1.6ГБ;
MP3 - 271 файл общим объёмом 1ГБ;
Programs - 8504 файла общим объёмом 1.4ГБ;
Windows - 9006 файлов общим объёмом 1.06ГБ.

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


Диаграммы построим только для трех наиболее интересных наборов:




Как и следовало ожидать, массивы RAID0 демонстрируют наиболее высокие результаты. Массивы RAID5 в наборах Install и ISO работают сравнительно быстро, и только в наборе Programs их скорость оказывается очень низкой (мелкие файлы!). Тем не менее, и у массивов RAID0 и у массивов RAID5 масштабирование скорости от количества дисков в массиве просматривается во всех наборах.
Скорость записи на массив RAID1 ниже, чем на одиночный диск, да и массив RAID10 не блеснул скоростью записи.

Переходим к режиму чтения:





Результат чтения файлов достаточно странен. Скорости трех- и четырехдисковых массивов RAID0 и RAID5 очень близки и, мягко говоря, разочаровывают... Неужели, опять нас огорчает Adaptive Read Ahead?

Лучшие результаты показывают по очереди массив RAID0 из двух дисков и массив RAID10 (при последовательном чтении, читай, - тот же RAID0 из двух дисков). Скорость чтения с массива RAID1 почти аналогична скорости чтения с одиночного диска.

Посмотрим на скорость копирования:






С копированием массив RAID0 справляется лучше всех и демонстрирует прекрасное масштабирование скорости от количества дисков в массиве. Правда, скорость-то всё равно невелика. Сейчас даже одиночные диски для настольных систем копируют внутри себя данные быстрее...
Массивы RAID5 несколько медленнее, однако масштабирование скорости от количества дисков в массиве проявляется и у них. Зеркальные массивы только в наборе Programs заметно превосходят одиночный диск и массив RAID0 из двух дисков соответственно.





Результаты второго цикла копирования не отличаются принципиально от результатов предыдущего цикла.

Переходим к системе FAT32:





По сравнению с системой NTFS скорость работы немного выросла. Исключение составляет непонятный провал скорости массива RAID0 из двух дисков в наборе Install.





Скорость чтения массива RAID1 практически не отличается от скорости одиночного диска.
Остальные массивы демонстрируют практически равные скорости.









К копированию файлов никаких претензий.

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










Winbench99

Из тестов Winbench теперь мы ограничиваемся только снятием графиков линейного чтения:

График линейного чтения 1HDD-JBOD
График линейного чтения 2HDD-RAID1
График линейного чтения 2HDD-RAID0
График линейного чтения 3HDD-RAID0
График линейного чтения 3HDD-RAID5
График линейного чтения 4HDD-RAID0
График линейного чтения 4HDD-RAID5
График линейного чтения 4HDD-RAID10

По графикам линейного чтения никаких претензий нет. :)

Выводы

Итак, по результатам тестов контроллера MegaRAID SATA 300-8X мы можем сказать, что, в общем, он показал себя неплохо. Особенно хотелось бы отметить работу контроллера в паттернах, имитирующих нагрузку на файл- и веб-сервер.

Прекрасно показали себя массивы с использованием зеркалирования, а вот с массивами RAID5 не всё так хорошо... То ли из-за низкой скорости работы XOR-процессора, то ли ещё по какой причине, скорость массивов RAID5 в режимах с большой долей запросов на запись не зависит от количества дисков в массиве. Жаль, что у нас было всего четыре диска и мы не смогли исследовать этот эффект поподробнее...
Единственное объяснение, которое приходит нам в голову - контроллер предназначался для работы с SATA-дисками, имеющими частоту вращения шпинделя 7200об/мин и мощность I/O процессора подбиралась под их время доступа. При работе с низкоскоростными дисками узким местом было бы большое время доступа дисков, а не малая вычислительная мощность XOR-процессора.

Итак, наши рекомендации - используйте контроллер для RAID1/RAID10 и обязательно приобретайте батарейку LSIiBBU01!

P.S. Кстати, статью, которую Вы сейчас, наконец-то, дочитали до конца, выдал сервер на контроллере MegaRAID SATA 300-8X. Нужны ли Вам еще какие-нибудь рекомендации? :)