Тестирование массива RAID6 из жестких дисков на трех поколениях контроллеров Adaptec

Тестирование «настоящих» аппаратных RAID-контроллеров является очень непростым занятием. Основных причин тому несколько. Первая – сложность сбора тестового стенда соответствующего уровня. Если делать все «правильно», то потребуется много жестких дисков, соответствующий корпус и достаточно мощная серверная платформа, в некоторых случаях – еще и быстрая сеть и клиенты. Вторая проблема заключается в том, что в большинстве случаев подбор конфигурации СХД – задача под конкретного заказчика и конкретные приложения. При этом вариантов существует слишком много, что бы можно было за разумное время охватить их все. Третий вопрос касается выбора тестовых приложений и сценариев. На практике потребителя интересуют именно его задачи с определенной нагрузкой, тогда как в лаборатории в данном случае обычно удобнее использовать синтетику.

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

Напомним, как и для чего используются RAID-массивы и контроллеры на традиционных винчестерах. Ключевых причин три. Первая – необходимость создания дисковых томов большого объема. Одиночные диски сейчас есть на 12 ТБ, так что если нужно больше – придется использовать несколько дисков. Вторая – требование высокой скорости чтения и записи. Один винчестер способен показать максимально около 200 МБ/с, так что если нужно больше – тоже требуется подключить несколько дисков и обеспечить возможность одновременной работы с ними. Третий момент, непосредственно связанный с первыми двумя, – реализация отказоустойчивого массива. Обратите внимание, что речь идет исключительно о сохранении данных при выходе из строя диска (или дисков), что конечно связано с общим понятием «надежность хранения», но не заменяет такой операции, как создание резервных копий. Именно последняя позволяет обеспечить восстановление в случае таких неприятностей, как удаление или изменение файлов.

Данное тестирование проводилось на сервере с платформой Supermicro X8SIL, процессором Intel Xeon X3430 и 8 ГБ оперативной памяти. Ему уже около десяти лет и конечно он как минимум морально устарел. Но, пожалуй, единственной серьезной претензией здесь может быть отсутствие поддержки PCIe 3.0. С другой стороны, 8 линий PCIe 2.0 – это тоже неплохо для массива из нескольких жестких дисков.

В тестировании принимали участие контроллеры Adaptec 6, 7 и 8-го поколений. К ним одним кабелем на четыре линии SAS подключался бекплейн поколения SAS1 с экспандером. Собственно за хранение данных отвечали восемь винчестеров Seagate Enterprise Capacity 3.5 HDD v4, модель ST6000NM0024 (6 ТБ, 7200 RPM, буфер 128 МБ, SATA, 512e).

Конфигурация массива – RAID6, размер блока 256 КБ. Все кэши для тома на контроллерах включены, остальные параметры по умолчанию, все контроллеры использовали батареи для резервного питания. Напомним, что для данных поколений адаптеров Adaptec можно переносить массивы без потери конфигурации и данных (причем не только «вверх», но и «вниз»), что, безусловно, очень удобно.

Для операционной системы в сервере был выбран Debian 9. Как обычно, со всеми обновлениями на момент проведения тестирования. Драйвера для контроллеров из состава дистрибутива, BIOS обновлены, для удобства управления установлен последний MaxView Storage Manager.

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

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

Файлы конфигурации утилиты имели следующий вид:

[test]
blocksize=256k | 4k
filename=/dev/sda
rw=read | write | randread | randwrite
direct=1
ioengine=libaio
iodepth=1 | 2 | 4 | 8 | 16 | 32 | 64
runtime=180


Где «|» подразумевает выбор одного из значений. Таким образом, исследовались операции последовательного чтения и записи с блоками размером 256 КБ и случайного чтения и записи с блоками по 4 КБ. Все тесты прогонялись с глубиной очереди от 1 до 64 и каждый занимал три минуты. По результатам смотрим на скорости в МБ/с, IOPS и задержки (clat avg в мс). При повторении обязательно перепроверьте имя устройства (filename=/dev/sda). Неверное указание этого параметра на тестах записи может привести к потере данных.

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

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

Сначала стоит сделать замечание об использованном формате диаграмм. На каждом графике приводятся сразу два показателя – производительности и средней задержки в зависимости от параметра iodepth теста. При этом для последовательных операций мы выбрали более привычный показатель в мегабайтах в секунду, а для случайных – iops. В данном конкретном случае с фиксированным размером блока они прямо пропорциональны и равноценны с точки зрения оценки результата.

Начнем с наименее быстрого контроллера Adaptec ASR-6805, который появился на рынке более семи лет назад. Интересно, что, несмотря на его возраст, данная линейка все еще востребована потребителями, как бы странно это не звучало.

Кстати, заодно опишем схему именований – первая цифра показывает поколение, вторая (точнее одна или две – встречается и вариант 16) – число внутренних физических портов (объединенных по четыре в разъёмы SAS различных форматов), третья – число внешних портов, пятая указывает на тип шины (5 – это PCI Express). Дополнительно могут присутствовать суффиксы, указывающие на тип разъемов, сокращенный объем кэшпамяти, наличие дополнительных функций.

Итак, последовательные операции.

На чтении с нашего массива контроллер может обеспечить до 900 МБ/с. Судя по близости последней пары показателей и резкому росту задержек в последней точке, дальнейшего увеличения скорости можно не ждать. Очевидно, что при повышении глубины очереди будут только повышаться задержки, при этом общая скорость останется на указанном уровне.

На операциях записи картина немного иная – максимальное значение в 500 МБ/с достигается сразу на минимальной нагрузке. В дальнейшем мы видим только рост задержек при увеличении глубины очереди.

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

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

На чтении массив не вносит никаких «скрытых» расходов и мы видим рост IOPS при увеличении глубины очереди с одновременным ростом задержек. С этим контроллером я не проверял следующие значения iodepth, но как будет показано далее, IOPS имеют свой предел, после которого будет только расти время отклика с сохранением общей скорости. На график записи лучше не смотреть. Все очень и очень грустно. Накладные расходы RAID6 на операциях записи часто оцениваются как число дисков*IOPS одного диска/6. То есть на одну операцию записи контроллеру требуется по факту провести шесть операций (не считая математических расчетов) – чтение исходного блока, чтение двух блоков четности, пересчет, запись трех измененных блоков.

При случайной записи при любой глубине очереди производительность ограничена на уровне 300 IOPS (примерно 1 МБ/с) и сделать здесь почти ничего нельзя. К счастью, в реальной жизни ситуация необходимости 100% случайного доступа к десяткам терабайт данных случается редко, а кроме того, на помощь приходит кэш операционной системы.

Итак, для ASR-6805 на наших шаблонах мы получили – последовательное чтение и запись на уровне 900 и 500 МБ/с соответственно, случайное чтение и запись – примерно 1000 и 300 IOPS.

Переходим к следующему участнику. Модели ASR-7805 около четырех лет. Ключевые отличия этого поколения от прошлого – увеличение производительности процессора, в два раза больше объем кэшпамяти, шина PCIe 3.0, поддержка режима HBA, работа с ленточными библиотеками.

В целом, зависимость производительности от нагрузки сохраняется, но есть и некоторые отличия. На последовательном чтении можно получить более 900 МБ/с, но только при относительно небольшой глубине очереди, тогда как значения для последних строк существенно ниже. Аналогичная ситуация и с последовательной записью – если нагрузка невелика, то скорость близка к 700 МБ/с, но при росте глубины очереди она падает до 630 МБ/с.

На случайном чтении мы видим те же 1000 IOPS, а вот с записью данный контроллер справляется лучше – он способен обеспечить почти 400 IOPS.

Дополнительно с этим контроллером я протестировал случайное чтение с существенным увеличением глубины очереди.

Как и говорилось выше, на этом шаблоне можно получить и более высокие значения производительности, но цена (рост задержек) все-таки слишком высока. Итого для этой модели максимальные показатели составили – 960 и 680 МБ/с на последовательном чтении и записи, 1100 и 400 IOPS на случайном чтении и записи.

Последняя протестированная модель контроллера – ASR-81605ZQ. В данном материале ее дополнительные возможности (в частности, MaxCache) не использовались, так что результаты будут применимы и к «обычному» представителю серии. Эта линейка является последней актуальной из традиционных продуктов со стеком Adaptec. Более новые решения серии SmartRAID – это уже совершенно другая история. В восьмой серии появилась поддержка 12 Гбит/с SAS, накопителей с секторами 4kn, UEFI BIOS. Все это для данного теста не актуально.

На последовательном чтении уже нет такого эффекта, как у седьмой серии и при любой нагрузке можно получить около 1000 МБ/с. Запись также дает более стабильные результаты на уровне 700 МБ/с. Обратим также внимание на то, что задержки при той же нагрузке меньше, чем у прошлой модели.

На операциях случайного чтения все упирается в диски и мы снова видим те же 1100 IOPS в сочетании с 60 мс откликом. Да и запись тоже мало отличается от прошлой модели – около 400 IOPS.

По итогам тестирования можно сделать  несколько выводов. Прежде всего, напомним, что касаются они исключительно протестированной конфигурации дискового массива. Во-первых, 6-я серия все еще может быть интересна для реальной работы. Во-вторых, более современные поколения хотя и показывают результаты выше, говорить о каком-то существенном их превосходстве пожалуй не стоит. Особенно это заметно на сравнении серий 7 и 8. Так что если в вашем сервере или СХД применяются массивы из относительно небольшого количества SATA винчестеров, можно обеспечить их эффективное (насколько это возможно) использование на любом из данных контроллеров. Но если встают вопросы производительности на случайных операциях в сочетании с томом большого объема, то к ним нужно подходить более внимательно. Привычный RAID6 на базе жестких дисков не способен здесь показать высокие результаты даже на современных аппаратных контроллерах. Да и случайное чтение тоже является непростой задачей для такой конфигурации.

 

 

 

 

+3 0 7463 28
Автор Kirill Kochetkov Рейтинг +4.84 Сила 11.18
Блог HDD, SSD, флешки, прочие носители информации 59 65 RSS

28 комментариев

VitalyOFF
Вторая половина графиков показывается наполовину. Не лезет в ширину колонки похоже.

Концептуально по материалу — по-моему, создание СХД на базе собственно сервера с рейд-контроллером уже уходит в прошлое. По причине недостаточной производительности и надежности, по сравнению со специализированными СХД, подключаемыми по Fibre Channel. А сервер представляет собой блейд с кучей процессоров и памяти, подключенный к какому-нибудь HP XP7 SAN массиву, на котором лежат бешеные тыщи виртуалок или контейнеров )))
Kirill Kochetkov
На FullHD нормально показывается. Плюс можно кликать на картинках, будут отображаться полностью во всплывающем окошке.

Что касается специализированных СХД — вопрос цены и требований. И несмотря на движение в сторону виртуалок, задачи хранения миллионов файлов для сотен пользователей тоже встречаются.
VitalyOFF
В Хроме нормально показываются в статье, но с уменьшением.
В IE11 и Edge показывается в статье левая часть графика и половина правой части.
При клике на картинку во всех 3 браузерах показывается график слегка обрезанный справа.
Хотя нет ))) в Edge после просмотра полноразмера стало показывать в статье нормально. Мистика какая-то )))
Последний раз редактировалось
bb9e551bc0530beb@liveid
В последних стабильных Firefox и Edge всё OK.
Loggus66
Желающие сэкономить будут всегда. Стоит хотя бы почитать откровения разработчика Badoo. Были СХД дешевле (даже не NAS, а SAN) — перешли на SAN. Стали жёсткие диски больше — сказали «к чёрту ваши SAN, давайте обратно на HDD в серверах».
Согласен с комментом Кирилла ниже. Посмотрел спеки этой XP7 — 7PB форматированный объём, явно не каждому заказчику такая пригодится. Потыкать веточкой в такую мощь, конечно, здорово.
XR3
СХД FC не всегда уместна. В большинстве случаев недорогие внешние СХД — не слишком производительны, у них слабые процессоры (Pentium,
а не 8-ми ядерный Xeon) и небольшой кэш (16-32 ГБ вместо 128+ ГБ в сервере).
Намного эффективнее во многих случаях
собрать программную СХД в виде сервера (без RAID-контроллера — все программно) или группы серверов в кластере.
Будет и производительно и надежно при разумной стоимости владения.
agentapple
Грустный результат в 400 IOPS при случайной записи. Жаль, что не было возможности старший контроллер протестировать в RAID6 с 8 дисками 10к. Может быть тут ограничение по дискам вылезает, поскольку при сайзинге на диски 7200 закладывается около 80 IOPS, что близко к полученному результату.
Kirill Kochetkov
Да, скорее всего вопрос к дискам и конфигурации. Скоро добавлю два контроллера с 36-ю дисками в RAID60. Но тоже пока SATA и 7200.
Последний раз редактировалось
Loggus66
RAID10 в таких статьях будет тестироваться? 5 и 6 хороши на дисках небольшого объёма, поскольку ребилд идёт быстро.
Kirill Kochetkov
Не очень понятна мысль. Речь о том, что на дисках большого объема рекомендуется использовать RAID10?
Loggus66
Да, что при объёмах больше пары терабайт использовать RAID5 опасно. Про 6 можно подумать, но RAID10 предлагает устойчивость при вылете до половины дисков, потому привык к его использованию на удалённых объектах.
Kirill Kochetkov
Про RAID5 на больших дисках уже давно разговоры идут. С RAID10 сложность в том, что именно «до половины не любых дисков». Ну и дорого для больших объемов использовать зеркало.
Rimlyanin
А какой практический смысл ставить в 6 уровень восемь SATA дисков?
И вообще, к статье очень много вопросов…
Seth[EZ]
4K блок = «сферический конь в вакууме».
Kirill Kochetkov
Не совсем. Популярные файловые системы для Linux имеют как раз базовый блок для данных размером 4К. Ну а в целом указанное замечание касается конечно любой синтетики.
Последний раз редактировалось
xawari
Было бы очень интересно посмотреть как эта конфигурация поведет себя с SAS-хардами при одновременном чтении с записью…
Ну и жаль, что только Adaptec — чаще в обиходе встречаются LSI и HP, имхо.
Kirill Kochetkov
SAS есть, правда для тестов доступны только маленькие и не очень свежие. LSI один есть. Может и успею на нем прогнать тест.
ClawFingerRUS
Ковыряюсь с домашним NAS, по полной оттестировал Nas4Free, FreeNAS, сейчас хочу попробовать OpenMediaVault. Nas4Free показался кривоватым и сыроватым несмотря на большую свободу, чем у FreeNAS. FreeNAS понравился большей стабильностью и удобством (видимо сказываются коммерческие рельсы), уже более полугода полет нормальный — там же крутятся 3 джейла — Zabbix, Plex, Transmission. Встал вопрос по дисковой подсистеме — потихоньку привожу харды к общему знаменателю (сейчас сборная солянка из трешек и четверок, обзавелся Adaptec 6805. Но встал вопрос насчет ZFS — всем она мне нравится и за время экспериментов я с ней освоился, но проблема, в том что этот Adaptec не поддерживает HBA режим… На OpenMediaVault как я понял, при необходимости можно и ZFS прикрутить, но все-же ее нельзя использовать нормально с аппаратным контроллером, а заморачиваться и делать отдельные массивы по отдельным хардам и объединять на уровне ZFS в ZRaid очень не хочется. Вот и собственно вопрос к автору: если есть возможность добавить к тому же тесту работу этих же хардов хотя бы на 7 Adaptec'e в HBA режиме на ZFS ZRaid. Уж очень интересна скорость массива на этой платформе.
P.S. Тесты одиночных хардов и Raid0 против ZFS видел, но это все же не совсем то…
P.P.S. Автору большое спасибо, т.к. крутился вопрос насчет разницы поколений Adaptec'ов и целесообразности покупки более свежих.
P.P.P.S. Ну и может быть у кого-то будут мысли по поводу ZFS или аппаратного рейда? ZFS хочется оставить из-за отвязанности от аппаратной платформы.
Kirill Kochetkov
Да, HBA у 6-й серии нет, есть у 7-й и 8-й. Думал попробовать ZFS. Делать одиночные массивы и потом из них собирать RAIDZ конечно странно. В данном случае можно было бы поискать б/у HBA.
ClawFingerRUS
Так почему на 7-ке не включить HBA режим и потестить? Представлять диски системе он должен так же как и простой HBA контроллер, и кеш свой по идее не должен пользовать.
Kirill Kochetkov
Не просто «должен», а именно так и делает. Причем можно иметь несколько дисков в RAID, а несколько в RAW одновременно.
Просто все сразу в одной статье не перетестировать.
Последний раз редактировалось
ClawFingerRUS
Понял, спасибо за ответ, буду ждать с нетерпением! :)
Alex Karabuto
Спасибо автору за материал: лишний раз убедился, что правильно сделал, когда несколько лет назад навсегда отказался от адаптеков в пользу LSI. )) RAID6 на восьми дисках даже на стареньком 9260 бегает существенно лучше. Кстати, еще бывает, что скорость лимитирует ЦП (несмотря на «аппаратный» RAID) — операции с диском идут на одном ядре, и если оно слабо по частоте, то это может влиять (когда скорость в районе 1000 и выше). И еще: помимо random на 4K стоит добавить и Random на 64K (популярный размер блоков у многих приложений — по 4K пишут-читают только динозавры). Ну и RW-конкуренцию не помешает прогнать хотя бы для соотношений 50-50 и 25-75.
Последний раз редактировалось
Kirill Kochetkov

Ответ Alex Karabuto на комментарий
RAID6 на восьми дисках даже на стареньком 9260 бегает существенно лучше

— конкретные цифры есть?

Ответ Alex Karabuto на комментарий
Кстати, еще бывает, что скорость лимитирует ЦП (несмотря на «аппаратный» RAID) — операции с диском идут на одном ядре, и если оно слабо по частоте, то это может влиять

Какие операции с диском идут на процессоре? Есть конкретные примеры? Сравнивал несколько Xeon, существенной разницы не заметил. Тут скорее может играть роль шина PCIe и правильное распределение прерываний от контроллера.

Ответ Alex Karabuto на комментарий
И еще: помимо random на 4K стоит добавить и Random на 64K (популярный размер блоков у многих приложений — по 4K пишут-читают только динозавры).

М… ну в общем случае хорошо бы конечно разные блоки смотреть, но вопрос выбора наиболее популярных размеров непростой. И надо еще учитывать, что между блочным устройством и приложениями есть еще файловая система. И тут тоже все очень непросто.
Alex Karabuto

Ответ Kirill Kochetkov на комментарий
конкретные цифры есть?

Ну рандомные иопсы на 7К-дисках тут обсуждать смысла никакого, а вот по последовательным явный провал у адаптеков: восемь этих дисков в рэйде 6 должны давать примерно 6х218=1300 Мбайт/с, адаптеки же их безбожно режут до 900-1000 (и 500-700 на напись), а LSI 9260 это легко делает (у него до 2800 МБ/с на чтение и 1800 на запись, на практике у меня они легко добивали 1200 и выше (под виндами), более быстрых дисков просто не было под рукой — причем, и на чтение, и на запись(!!!) в шестерке. Из опубликованного есть только старенький //www.ixbt.com/storage/lsi-sas9260-8i.shtml, остальное вне паблика — железо уже древнее, обсасывать его неактуально, да и мощнее уже полно новинок.


Ответ Kirill Kochetkov на комментарий
Какие операции с диском идут на процессоре?

Ну вообще-то все тесты исполняются процессором. )) И что при этом операции с диском идут по DMA, сути не меняет. Я в свое время частенько подмечал, что с мощными рэйдами (выше 1 ГБ/с) и даже с одиночными мощными SSD (за 2 ГБ/с) результаты процессорозависимы, если система слабовата (и дело не в многоядерности).

Впрочем, между виндой и линухом м.б. разночтения.
Kirill Kochetkov
Ну это не серьезно… сравнивать цифры реальных тестов с «должны» и спецификациями от производителя :)
В статье по ссылке нет конфигурации из большого числа дисков.
Кроме того, замечу, что в обсуждаемом тесте использовался бекплейн SAS1, что тоже сказалось на результатах. Сейчас нашел SAS диски (хотя и не очень свежие) и SAS3 бекплейн.

Про процессор — нужны цифры. Да, конечно все работает на нем, но формально даже у X3430 память на 21 ГБ/с и DMI на 2,5 ГТ/с. Так что не очень понятно, как и насколько может влиять частота ядер в данном случае.
Alex Karabuto

Ответ Kirill Kochetkov на комментарий
Сейчас нашел SAS диски (хотя и не очень свежие) и SAS3 бекплейн.

Заодно достань 9260 или 9280 и сравни. ;) Только прошивку посвежее залей. А еще лучше — на SSD это проделай для чистоты. ;)

X3430 у меня тоже где-то валяется — будет время и если проснется интерес, погоняю с 9260 и SSD. )))
Последний раз редактировалось
Kirill Kochetkov
9260 нет, есть 9361 в работе. один том свободный для теста на нем пока есть.
Не вижу смысла в
Ответ Alex Karabuto на комментарий
А еще лучше — на SSD это проделай для чистоты. ;)

в данном случае.
Последний раз редактировалось

Добавить комментарий