Тестирование массива 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 на базе жестких дисков не способен здесь показать высокие результаты даже на современных аппаратных контроллерах. Да и случайное чтение тоже является непростой задачей для такой конфигурации.