Тестирование SAS RAID-контроллера LSI MegaRAID SAS 9260-8i

Введение

Корпоративный сектор рынка, а именно он является потребителем столь солидной продукции, как RAID-контроллеры, является очень консервативным. Из-за его специфики, когда любые неполадки и даже незначительные простои грозят крупными финансовыми потерями, большинство потребителей в этом секторе предпочитают исходить из принципа «тише едешь — дальше будешь». За примером далеко ходить не надо: если настольные диски очень быстро сменили интерфейс с параллельного на последовательный (PATA на SATA), то аналогичный переход со SCSI на SAS затянулся надолго — дисковые полки с интерфейсом SCSI 320 и сейчас не являются музейной редкостью. И, все же, настала пора для очередного обновления интерфейсов — на этот раз SAS увеличил свою пропускную способность с 3 Гбит/с до 6 Гбит/с. Попутно в новом стандарте SAS 2.0 произошли еще и некоторые дополнительные изменения — из наиболее явных стоит озвучить снижение интенсивности электромагнитного излучения от проводов, увеличение их максимальной длины (с шести до десяти метров) и уменьшение взаимных наводок, переработанную топологию сложных конфигураций. Впрочем, самой явной и востребованной чертой явно остается удвоение пропускной способности. Естественно, что новый стандарт максимально совместим со старым — в противном случае, переход на него усложнился бы в разы. В целом, в современном мире способов подключения накопителей SAS имеет достаточно стабильную нишу — его "дальность" значительно меньше, чем у конкурирующих FibreChannel и iSCSI, но при этом он заметно дешевле первого и не имеет столь серьезного недостатка, как большее время задержек у второго. «Подтянув» скорость до 6 Гбит/с интерфейс SAS представляет собой весьма удачный способ подключения накопителей, расположенных в нескольких соседних стойках.

В принципе, для тех случаев, когда каждый диск подключается к отдельному порту на RAID-контроллере, пропускной способности 3 Гбит/с (что в теории составляет 300 МБ/с) еще вполне достаточно. Даже лучшие из современных SAS-дисков, модели с 15 000 об/мин и огромной плотностью записи на текущий момент только подбираются к скорости чтения с пластин 200 МБ/с. Так почему же мы говорим о высокой востребованности повышения пропускной способности интерфейса? Да потому что по нему подключаются не только отдельные диски, но и дисковые корзины и отдельные дисковые полки. И в этом случае, когда один канал делят сразу несколько накопителей, пропускной способности 3 Гбит/с оказывается уже недостаточно, ведь их целиком «съедают» всего два современных диска. Опять же, нельзя забывать и о приобретающих все большую популярность твердотельных накопителях (SSD), которые уже сейчас с легкостью демонстрируют скорости в 250—270 МБ/с, то есть уже ограничиваются интерфейсом.

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

Ну что же, давайте знакомиться с первым SAS-RAID-контроллером, поддерживающим SAS 6Гбит/с, попавшим в наши руки. Им стал LSI MegaRAID SAS 9260-8i — представитель новой серии контроллеров этой известной компании.

LSI MegaRAID SAS 9260-8i

Контроллеры LSI нового поколения, которые легко узнать по обозначениям, начинающимся с «92», разделились сразу на три серии: HBA-контроллеры, Value и Feature. В первую, в полном соответствии с названием, вошли модели без XOR-сопроцессора и обеспечивающие создание массивов лишь «простых» типов RAID0, RAID1, RAID1E и RAID10. Впрочем, им и без этого потребовался достаточно мощный процессор PowerPC 440, работающий на частоте 533 Мгц. Для представителей старших серий компания LSI создала новый процессор LSISAS 2108 с частотой 800 Мгц. Впрочем, старшие серии вообще крайне схожи друг с другом, отличает их лишь тип разъемов — в серии Feature контроллеры оснащаются внешними портами SFF-8088, а в серии Value, к которой относится и попавшая к нам модель 9260-8i, на платах расположены лишь внутренние порты SFF-8087. Соответственно, все, что будет сказано ниже, можно смело относить сразу ко всем продуктам двух новых серий.

Внешне контроллер ничем не выделяется на фоне моделей предыдущих серий — перед нами снова низкопрофильная карта формата MD2, на которой основной чип скрыт игольчатым радиатором. Как и все его собратья (включая четырехпортовые модели) LSI 9260-8i несет на борту 512 МБ оперативной памяти DDR2 с частотой 800 Мгц. Меньше по современным меркам ставить как-то несерьезно, а большие объемы не очень нужны (по крайне мере на конфигурациях, схожих с нашей тестовой). Существенным, хотя и не заметным со стороны, отличием от предыдущих серий стала смена интерфейса взаимодействия не только с накопителями, но и с материнской платой. Да, теперь контроллеры используют PCI-Express версии 2.0, а это значит, что через свои восемь линий они могут пропускать до 64 Гбит/с, чего более чем достаточно для восьми даже полностью нагруженных портов SAS 6 Гбит/с.

С поддерживаемыми типами массивов все привычно: ничего нового пока не изобрели, а все старое, в виде RAID0, 1, 5, 6 и их комбинаций, в настоящее время позволяют создавать буквально все выпускаемые полноценные контроллеры.

Как и полагается, контроллеры новых серий поддерживают установку батареи питания кэша. Причем все контроллеры используют одну и ту же последнюю модель — iBBU07, до этого использовавшуюся лишь на LSI 8880EM2.

Стоит также отметить появившуюся поддержку SSD, хотя она и не является уникальной для этой серии контроллеров, а просто появилась в очередной версии ПО LSI, выходившей почти одновременно с новыми контроллерами. Никаких чудес от этой поддержки ожидать не стоит, но в целом стоит отметить, что контроллеры научились распознавать SSD как отдельный класс накопителей, который радикально отличается от жестких дисков. Понятно, что для них абсолютно бессмысленно проводить такие операции, как, например, патрульное чтение поверхности. Хочется надеяться, что и сброс данных из кэша на накопители в случае работы с SSD происходит по возможности редко, что должно продлевать их срок службы.

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

Во время тестирования использовались следующие программы:

IOMeter версии 2003.02.15;
FC-Test версии 1.0;

Тестовая система была следующей:

корпус Intel SC5200;
системная плата Intel SE7520BD2;
два процессора Intel Xeon 2,8 ГГц на 800-МГц системной шине;
2 х 512 МБ регистровой памяти DDR PC3200 ЕСС
жесткий диск IBM DTLA в качестве системного диска;
восемь жестких дисков Fujitsu MBA3073RC
видеокарта — встроенное видео ATI Rage XL
операционная система Microsoft Windows Server 2008

Время неумолимо и нам пришлось несколько изменить нашу тестовую конфигурацию — мы перешли на использование Windows Server 2008. Причина проста: под древнюю Windows 2000 компания LSI попросту перестала выпускать драйвера.

К сожалению, «железная» часть нашей тестовой системы осталась прежней — мы все также используем материнскую плату со слотом PCI-Express первой версии и диски с интерфейсом SAS 3 Гбит/с. Правда, при используемой нами схеме тестирования, при которой каждый диск подключается к отдельному порту на контроллере, интерфейс и не должен оказывать какого-либо серьезного эффекта на производительность.

В остальном все привычно: контроллер во время тестов устанавливался в слот PCI-Express x8 на материнской плате; для тестирования использовались жесткие диски Fujitsu MBA3073RC, установленные в штатные салазки корпуса SC5200 и закрепленные в них четырьмя винтами за нижнюю грань. Контроллер тестировался с использованием восьми жестких дисков в следующих режимах:

RAID0;
RAID10;
RAID5;
RAID6;
RAID50;

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

Для сравнения мы будем везде приводить результаты одиночного диска Fujitsu MBA3073RC, полученные на контроллере LSI SAS3041E-R, считая их неким базовым уровнем производительности. Сразу оговоримся, что у такого сочетания есть одна хорошо известная нам проблема: его скорость записи в «FileCopy Test» всегда очень мала.

Размер страйпа на массивах всех типов задается равным 64 кБ.

В контроллер была прошита самая последняя доступная нам на момент тестирования версия BIOS и использовались самые свежие драйвера. Соответственно, мы использовали прошивку 12.0.1-008 и драйвера 4.17.2.64.

Прежде чем перейти непосредственно к результатам тестов хочется поведать о еще одной особенности данного тестирования. Дело в том, что ниже вы в нескольких случаях увидите результаты тестов в виде двух циклов тестирования на абсолютно одинаковых массивах. Причиной этому послужило крайне необычное поведение контроллера. Проведя первую серию тестов, мы беглым взглядом оценили получившиеся результаты и озадачились. Нам действительно было от чего поднять брови в немом вопросе «что это?!!»

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

Но кто ищет — тот всегда найдет. Дело оказалось в последовательности проводимых нами тестов. Стандартная процедура тестирования выглядит так: скрипт по очереди запускает различные типы нагрузки в «IOMeter», после чего мы вручную разбиваем диск и запускаем «FileCopy Test». Последовательность нагрузок в «IOMeter» такова, что сперва идет тест на время доступа (фактически, множество случайных операций с мелкими блоками), потом тесты на случайное чтение и запись с разным размером блока, затем группа тестов с последовательными запросами (в том числе в несколько потоков) и в самом конце — эмуляция серверной работы и «Database». Оказалось, что если первым проводить «FileCopy Test», а в «IOMeter» сперва проводить именно группу тестов с линейной нагрузкой, то результаты получаются принципиально другие. Единственная пришедшая нам в голову версия — контроллер умеет подстраиваться под нагрузку. Но, видимо, для принятия решения об изменении политики кэширования контроллеру требуется либо определённое время, либо определённое количество запросов, что в случае наших относительно коротких тестов контроллер не успевал за нашим темпом смены типа нагрузки.
И еще одно маленькое дополнение: при смене массива необходимо было выключать сервер после удаления предыдущего массива, иначе на новом только что созданном массиве мы снова получали «низкие» скорости записи.

Глубоко исследовать алгоритмы работы контроллера в наши планы не входило, но в этом обзоре мы решили предоставить вам данные сразу двух циклов тестирования: первого, в котором сперва идут случайные нагрузки, и второго, в котором тесты начинаются с линейных операций.
Так что мы сможем оценить скорость контроллера в двух ипостасях — файл-сервер и видео-сервер.

IOMeter: Sequential Read & Write

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

Результаты IOMeter: Sequential Read
Результаты IOMeter: Sequential Write

Заметить различия между двумя циклами тестов крайне сложно — они укладываются в погрешность измерений, последовательность нагрузок на линейное чтение влияния не оказала. Что интересного мы видим на графиках? Во-первых, некоторое снижение скорости на небольших блоках в случае двухуровневых массивов RAID10 и RAID50 — у всех остальных массивов графики прошли чуть выше и плотной группой. Во-вторых, контроллер явно пытается читать данные одновременно с двух дисков в зеркальных парах, правда, лишь на очень больших блоках. С максимальными скоростями у всех массивов все в порядке — они вполне предсказуемы, если исходить из известной скорости одиночного диска и не забывать про небольшие потери. Несколько огорчает, пожалуй, лишь то, что на эти скорости массивы выходят на блоках достаточно больших размеров — в нашем сравнительном тестировании мы видели и более «шустрых».

А вот и та самая диаграмма, после которой мы вздохнули с облегчением — нам все-таки удалось добиться от этого контроллера подобающих скоростей записи. Если все результаты первого цикла расположились где-то внизу, то во втором цикле скорости представляют собой более приличное зрелище. Хотя и далеко не безупречное: массивы RAID5 и RAID50 демонстрируют какие-то странные падения скоростей на блоках средних размеров. Да и у RAID10 «полочка» в районе 16-32 кБ как-то не радует. Но при этом на очень больших блоках максимальные скорости записи расположились на вполне предсказуемых уровнях: RAID0 почти достиг 1000 МБ/с, RAID5 отстает от него на один диск, RAID6 и RAID50 отстают стоят еще одной ступенькой ниже (правильно, ведь в них под запись контрольных сумм «выпадает» уже два диска), ну а RAID10 отстает от лидера почти ровно вдвое.

IOMeter: Database

Продолжим мы наиболее интересным с точки зрения поведения контроллера под нагрузкой тестом — «Database», с помощью которого мы выясняем способность контроллеров работать с потоками запросов на чтение и запись 8-кБ блоков данных со случайной адресацией. В ходе тестирования происходит последовательное изменение процентного соотношения запросов на запись от нуля до ста процентов (с шагом 10 %) от общего количества запросов и увеличение глубины очереди команд от 1 до 256.

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

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

Результаты IOMeter: Database, первый цикл
Результаты IOMeter: Database, второй цикл

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

На минимальных нагрузках из алгоритмов работает лишь отложенная запись. И в LSI 9260-8i она работает как и полагается — запросы на запись уходят в память, а производительность тем выше, чем большим суммарным объемом кэша (контроллера и дисков) обладает массив.

Стоит обратить внимание на любопытный факт — производительность RAID50 на записи сравнима со скоростью RAID5 (и даже чуть выше) и заметно больше, чем у RAID6. В этом нет ничего убедительного — в RAID50 нет необходимости одновременно рассчитывать две контрольные суммы, достаточно всего одной. Небольшое превосходство над RAID5 можно объяснить тем, что для контрольных сумм данные приходится брать с вдвое меньшего количества дисков. Так что если вы готовы обменять некоторый запас надежности (все же, RAID6 выдерживает потерю любых двух дисков, а не двух дисков, по одному в каждом из RAID5) на увеличение производительности на записи, то RAID50 может оказаться для вас подходящим вариантом.

В принципе, сравнивать результаты этого контроллера и побывавшего у нас ранее его предшественника LSI 8708EM2 не совсем корректно, поскольку у нас сменилась операционная система, но весьма интересно. У нового контроллера мы видим явно возросшую производительность на записи — массивы всех типов приятно увеличили результаты, в итоге график у RAID5 стал почти горизонтальным, а у RAID10 и вовсе загибается вверх в правой части. Что особенно приятно — контроллер не потерял способности к очень эффективному поиску удачного диска в зеркальной паре: именно за счет этого умения RAID10 при преобладании запросов на чтение очень заметно опережает все остальные массивы.

Заметьте, RAID50 по-прежнему значительно лучше выглядит на записи, чем RAID6, хотя и перестал превосходить RAID5.

Увеличение глубины очереди до огромной приводит к интересному эффекту: RAID50 неожиданно теряет производительность при преобладании операций чтения. Если все остальные массивы дают с восьми дисков примерно равное количество операций чтения (конечно, кроме RAID10, который лучше остальных за счет выборки «удачного» диска), то RAID50 неожиданно от них несколько отстал. В остальном — все очень хорошо, причем по-прежнему наблюдаются весьма высокие результаты на записи.

IOMeter: Disk Response Time

Для измерения времени отклика мы в течении десяти минут при помощи «IOMeter» отправляем на накопитель поток запросов на чтение или запись блоков данных по 512 байт при глубине очереди исходящих запросов, равной единице. Количество запросов, обработанных накопителем, превышает шестьдесят тысяч, так что мы получаем устоявшееся время отклика накопителя, не зависящее от объема буферной памяти.

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

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

IOMeter: Random Read & Write

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

Результаты, полученные при работе со случайной адресацией данных, рассмотрим в двух вариантах. На блоках малого размера построим зависимости количества операций в секунду от размера используемого блока. А на больших блоках вместо количества операций возьмем в качестве критерия производительности скорость в Мегабайтах в секунду. Такой подход позволяет оценить работу массивов сразу в двух типичных случаях нагрузки: работа малыми блоками характерна для баз данных и для нее более важно количество операций в секунду, чем привычная скорость; а вот работа большими и очень большими блоками близка к реальной работе с файлами малых размеров и здесь уже на первый план выходит именно скорость в привычных мегабайтах в секунду.

Начнем с чтения.

Результаты IOMeter: Random Read, операций/с
Результаты IOMeter: Random Write, МБ/с
Результаты IOMeter: Random Write, операций/с
Результаты IOMeter: Random Write, МБ/с

Случайное чтение мелкими блоками проходит предсказуемо — RAID10 впереди, дальше одиночный диск, следом все остальные. И от последовательности тестов оно никак не зависит.

На больших блоках все массивы разошлись по парам — независимо от размеров блока и предшествующей нагрузки чтение проходит стабильно хорошо. Расстановка сил между массивами разных типов вполне логична и соответствует тому, что они демонстрировали в тесте на линейное чтение — RAID0 в лидерах, следом RAID5, хуже всех — RAID10. Да, именно что хуже всех — выбор удачного диска способен дать заметное преимущество при запросе небольших блоков, но когда основным решающим фактором становится линейная скорость (примерно на 2-МБ блоках) — то RAID10 даже с возможностью одновременного чтения с двух дисков в зеркальных парах не в силах догнать другие массивы.

На записи малыми блоками все решает доступное массиву количество кэша и то, надо ли ему рассчитывать и записывать контрольные суммы или нет. Обратите внимание: RAID50 стабильно опережает RAID5, хотя и ненамного — сказывается то, что ему надо сделать меньше обращений к дискам при расчете контрольной суммы. Ну а RAID6 с ним и вовсе не может сравниться на такой нагрузке — вторая контрольная сумма обходится довольно дорого с точки зрения производительности на случайно записи.

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

А вот на записи большими блоками разница двух циклов тестирования вылезает в полный рост. Причем лишь добавляет загадок. Так, большая часть массивов первого цикла тестирования словно «уперлась» в какой-то предел по скорости на больших блоках, умудрившись продемонстрировать даже некоторое снижение скорости при увеличении размера блока. Однако при этом массив RAID0 в первом цикле отработал просто великолепно, а вот во втором цикле, наоборот, продемонстрировал неожиданно низкую скорость, будто бы найдя тот барьер, который достался остальным массивам в первом цикле. Странное, очень странное и необъяснимое поведение.

IOMeter: Multi-thread Read & Write

Данный тест позволяет оценить поведение контроллеров при многопоточной нагрузке. В ходе него эмулируется ситуация, когда с накопителем работает от одного до четырех приложений, причем количество запросов от них изменяется от одного до восьми, а адресные пространства каждого приложения, роли которых выполняют worker-ы в «IOMeter», не пересекаются.

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

Результаты IOMeter: Multi-tread Read, первый цикл
Результаты IOMeter: Multi-tread Read, второй цикл
Результаты IOMeter: Multi-tread Write, первый цикл
Результаты IOMeter: Multi-tread Write, второй цикл

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

К сожалению при одном потоке данных контроллер демонстрирует точно такое же поведение, как и его предшественник — на максимальные скорости он выходит лишь при глубинах очереди больше единицы, то прекрасно видно из таблиц. В результате мы видим довольно забавную картину — все одноуровневые массивы при минимальной глубине (на практике это выглядит как самое обычное чтение одного файла блоками по 64 кБ) демонстрируют равные скорости на уровне чуть выше 400 МБ/с. Двухуровневые RAID10 и RAID50 оказываются несколько медленнее, из-за чего RAID50 проигрывает по скорости RAID6, несмотря на одинаковые результаты в тесте линейного чтения.

Увеличение количества потоков приводит к заметным изменениям. На двух потоках все массивы теряют в скорости, хотя величины потерь у них разные. Хуже всего приходится RAID10 и RAID50 — у них скорость падает почти вдвое. Любопытно при этом поведение RAID10: на трех потоках он резко прибавляет в скорости (один из потоков читается с отдельного набора дисках в зеркальных парах?), но при этом на четырех потоках он снова теряет в скорости. Массив RAID50 же ведет себя при дальнейшем увеличении количества потоков так же, как и остальные массивы — понемногу увеличивает скорость. Похоже, что для этих массивов увеличение числа потоков становится своеобразной заменой большой глубины очереди. Особенно хорошо это заметно в случае RAID0 — при минимальной глубине очереди четыре потока данный массив читает быстрее, чем один.

А вот на записи снова есть повод рассмотреть оба цикла тестирования. В первом цикле даже при одном потоке на запись скорости крайне низкие — все массивы медленнее одиночного диска. А вот вторые цикл ведет себя не в пример лучше — скорости записи всех массивов находятся около 400 МБ/с. Причем из них заметно выделяется RAID0 — не только самой большой скоростью, но и тем, что он единственный из массивов, чья скорость возрастает при увеличении глубины очереди. Несмотря на то, что скорости далеки от теоретических, этот контроллер все же лучше предшественника — у того с записью все было гораздо хуже.

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

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

IOMeter: Webserver, Fileserver и Workstation

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

Напомню, что в «Webserver» и «Fileserver» эмулируется работа накопителя в соответствующих серверах, в то время как в «Workstation» мы имитируем работу накопителя в режиме типичной нагрузки для рабочей станции, с ограничением максимальной глубины очереди в 32 запроса. Естественно, что «Webserver» и «Fileserver» — не более чем собирательные названия; первый будет весьма схоже эмулировать нагрузку любого сервера, работающего, фактически, только с запросами на чтение, а второй — сервера с преобладанием запросов на чтение, но при этом с определенной, заметно отличной от нуля долей запросов на запись.

Результаты IOMeter: Fileserver
Результаты IOMeter: Webserver
Результаты IOMeter: Workstation
Результаты IOMeter: Workstation, 32 ГБ

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

В случае нагрузки, состоящей лишь из запросов на чтение, как в данном тесте, все решает количество дисков в массиве. Если, конечно, нет особых дополнительных факторов. Последними в данном тесте стал алгоритм выборки удачного диска в RAID10, выведший его на первое место и какие-то проблемы в RAID50 на глубинах очереди более 16, приведшие к его заметному отставанию.

В случае смешанной нагрузки, как в этом тесте, расстановка сил уже не столь легко предсказуема. Так, RAID10 лидирует на малых нагрузках, но пропускает вперед RAID0 на больших. Но наш рейтинг все же отдает победу RAID10. На малых нагрузках массивы RAID5, RAID6 и RAID50 идут практически вровень, но с ростом нагрузки RAID5 выбивается в лидеры, а RAID6 немного, но отстает от RAID50.

Нагрузка, характерная для рабочих станций, имеет еще более сложный характер, кроме того, здесь мы не рассматриваем глубины очереди более 32 команд. В результате RAID10 снова безоговорочно занимает место лидера, а RAID50 чуть-чуть, но обгоняет RAID5, а оба они заметно отрываются от RAID6 — при большом количестве записей расчет сразу двух контрольных сумм печально сказывается на его производительности.

Если для той же нагрузки использовать не всю зону массива из восьми дисков, а лишь первые 32 ГБ, то результаты заметно возрастают. Более того, поскольку используемая зона, если ее рассматривать как область на дисковых пластинах, получается очень узкой, то алгоритмы выборки удачного диска в RAID10 уже не приносят столь существенного прироста и на первое место выбирается RAID0.

FC-Test

Завершает нашу программу «FileCopy Test». На накопителе создается два раздела по 32 ГБ, размечаемые в NTFS, после чего на разделе создается определенный набор файлов, считывается, копируется в пределах раздела и копируется с раздела на раздел. Время всех этих операций фиксируется. Напомним, что наборы «Windows» и «Programs» включают в себя большое количество мелких файлов, а для остальных трех паттернов («MP3», «ISO» и «Install») характерно меньшее количество файлов более крупного размера, причем в «ISO» используются самые большие файлы.

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

В данном случае нам снова становятся интересны результаты обоих циклов тестирования.

Результаты записи особенно впечатляют и рассматривать их стоит по группам.

Начнем с шаблона «ISO». В нем файлы настолько велики, что не могут поместиться в буферную память. В результате в первом цикле все массивы демонстрируют крайне невысокие скорости — если бы не проблема с прошивкой LSI SAS3041E-R, то одиночный диск вполне имел бы шансы обогнать своих восьмидисковых конкурентов. А вот во втором цикле скорости в 3-4 раза выше. В теории, правда, должно быть еще больше, но и это уже хорошо, у предшественника LSI 8708EM2 мы лишь у RAID0 видели более 200 МБ/с. Но все равно компании еще есть над чем поработать в прошивке — все же, RAID0 не должен проигрывать RAID50 и быть лишь чуть быстрее остальных массивов.

В наборах «Install» и «MP3» мы видим принципиально иную картину. Очевидно, поскольку размеры файлов гораздо меньше, то часть файлов может «проваливаться» в буферную память. Эффект получается весьма любопытным — контроллер на массивах демонстрирует скорости, схожие с теми, что мы видели на «ISO». Более того, между результатами первого и второго цикла разница есть, но она не столь уж и высока, причем более чем в половине случаев массивы из первого цикла тестирования оказываются чуть быстрее. Такое впечатление, что большое количество случайной нагрузки как-то все же сказывается на механизмах кэширования, что приводит к огромному падению скорости на больших файлах, но способно дать некоторый прирост на маленьких. Если это так, то такое поведение контроллера сложно назвать хорошим — слишком уж непредсказуемыми становятся его результаты.

Наконец, третья группа — «Programs» и «Windows». Здесь мы работаем лишь с небольшими файлами. Результатом становится то, что разница между массивами становится почти незаметна. Очень схожие скорости демонстрируют как массивы разных типов, так и массивы одного типа, но из разных циклов тестирования. Честно говоря, после этого проблески надежды на понимание того, что происходит в массиве, пропадает начисто.

На чтении необъяснимое продолжает прорываться в результаты. Казалось бы, все предыдущие результаты говорят о том, что чтение одинаково происходит в обоих циклах, но здесь мы видим в двух случаях из 25 разницу результатов, которую невозможно списать на погрешность измерения.

Снова мы не видим высоких скоростей в «ISO» — ни один массив не смог шагнуть за черту 400 МБ/с. В «Install» и «MP3» появляется хоть какая-то заметная разница между массивами — двухуровневые массивы RAID10 и RAID50 отстают от остальных. Так и вспоминаются результаты многопоточного теста, где на одном потоке мы видели точно такую же расстановку сил. На остальных двух наборах скорости снова примерно равные у всех массивов.

Кстати, обратите внимание — скорость чтения двух последних наборов заметно ниже, чем скорость записи. Очевидно, причиной тому являются кэширование — конечно, полностью наша тестовая нагрузка не может «провалиться» в память, но все же влияние кэша объемом 512 МБ стоит учитывать при рассмотрении результатов.

Скорость копирования файлов, в большинстве случаев определяется результатами на записи. Именно из-за них мы видим столь высокое превосходство массивов из второго цикла в наборе «ISO». Схожий, но не настолько сильно выраженный результат мы видим и в «MP3». Правда, одно весомое отличие есть: в «ISO» неожиданно слишком уж медленно выступает RAID0, в то время как в «MP3» состав отстающих более привычен — ими снова стали двухуровневые массивы RAID10 и RAID50.

На наборах мелких файлов «Programs» и «Windows» мы опять видим постоянство результатов и их независимость от характера предыдущей нагрузки.

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

Подведение итогов

Итак, сегодня мы познакомились с контроллером LSI нового поколения, главной «фишкой» которого является поддержка нового стандарта SAS 6 Гбит/с. Контроллер продемонстрировал явный прогресс по сравнению с предшественниками и обладает отличной производительностью в случае работы с базами данных (особенно ему удается работа с зеркальными массивами). С другой стороны, новый стандарт SAS будет наиболее востребован в случае потоковых нагрузок, а именно здесь мы и не увидели каких-то особенно уж потрясающих результатов — конкуренты на SAS 3 Гбит/с порой демонстрировали лучшие результаты.

Но больше всего мы запомним этот трюк с адаптивной системой кэширования контроллера — это отличная идея для реального мира, но чертовски сильная головная боль для тестеров. ;)

Другие материалы по данной теме

Сравнительный обзор шести SAS RAID-контроллеров
Тестирование SAS RAID-контроллера Areca ARC-1680ix-16
Тестирование SAS RAID-контроллера LSI MegaRAID SAS 8708EM2