Raid массив это тест
Тестирование «настоящих» аппаратных RAID-контроллеров является очень непростым занятием. Основных причин тому несколько. Первая – сложность сбора тестового стенда соответствующего уровня. Если делать все «правильно», то потребуется много жестких дисков, соответствующий корпус и достаточно мощная серверная платформа, в некоторых случаях – еще и быстрая сеть и клиенты. Вторая проблема заключается в том, что в большинстве случаев подбор конфигурации СХД – задача под конкретного заказчика и конкретные приложения. При этом вариантов существует слишком много, что бы можно было за разумное время охватить их все. Третий вопрос касается выбора тестовых приложений и сценариев. На практике потребителя интересуют именно его задачи с определенной нагрузкой, тогда как в лаборатории в данном случае обычно удобнее использовать синтетику.
Тем не менее, когда появилась возможность в некотором приближении разобраться с первой проблемой, захотелось вернуться к этому вопросу и попробовать провести для начала несколько тестов. Безусловно, выбранные конфигурации и бенчмарки, вызовут множество вопросов у читателей, особенно если они являются профессионалами в данной области. Но просьба отнестись к этому материалу как попытке возрождения обсуждения темы и в комментариях предложить идеи (желательно конструктивные), как, что и почему было бы интересно исследовать в рамках данного направления. Двигаться есть куда, но направлений слишком много и выбрать интересные можно только с вашей помощью.
Напомним, как и для чего используются RAID-массивы и контроллеры на традиционных винчестерах. Ключевых причин три. Первая – необходимость создания дисковых томов большого объема. Одиночные диски сейчас есть на 12 ТБ, так что если нужно больше – придется использовать несколько дисков. Вторая – требование высокой скорости чтения и записи. Один винчестер способен показать максимально около 200 МБ/с, так что если нужно больше – тоже требуется подключить несколько дисков и обеспечить возможность одновременной работы с ними. Третий момент, непосредственно связанный с первыми двумя, – реализация отказоустойчивого массива. Обратите внимание, что речь идет исключительно о сохранении данных при выходе из строя диска (или дисков), что конечно связано с общим понятием «надежность хранения», но не заменяет такой операции, как создание резервных копий. Именно последняя позволяет обеспечить восстановление в случае таких неприятностей, как удаление или изменение файлов.
Данное тестирование проводилось на сервере с платформой Supermicro X8SIL, процессором Intel Xeon X3430 и 8 ГБ оперативной памяти. Ему уже около десяти лет и конечно он как минимум морально устарел. Но, пожалуй, единственной серьезной претензией здесь может быть отсутствие поддержки PCIe 3.0. С другой стороны, 8 линий PCIe 2.0 – это тоже неплохо для массива из нескольких жестких дисков.
Конфигурация массива – 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 на базе жестких дисков не способен здесь показать высокие результаты даже на современных аппаратных контроллерах. Да и случайное чтение тоже является непростой задачей для такой конфигурации.
Введение
Мнение касаемо различных VS у меня давно сложилось — все зависит от задач. Но нет, нет, да возникает желание копнуть глубже, узнать кто все таки сильнее — Брюс Ли или Джеки Чан, Сталоне или Шварцнегер, mdadm или gmirror.
Тест не претендует на абсолютную объективность, скорее он даже субъективен в разрезе используемого аппаратного обеспечения. Но так или иначе, цифры есть цифры.
Кого заинтересовал, пожалуйте под кат.
Тестовый стенд
Материнская плата: ECS 865GV-M
Процессор: Intel® Celeron® CPU 2.00GHz
HDD 1(система): SATA-II 160Gb Western Digital WD1600AAJS (подключен к «мамке»)
HDD 2,3(RAID): SATA-II 1,5Tb Western Digital [WD15EARS] (подключены к Promise)
SATA контроллер: Promise SATA300 TX4 PCI, 4-port SATA300
RAM: 1280Mb
*не Бог весть какая конфигурация, но, как говорится, чем богаты, тем и рады.
Тестируемые ОС:
1.FreeBSD 8.0 RELEASE i386
2.Debian Lenny 5.0.5 i386
*признаюсь, в Linux мне так и неудалось получить читаемый html, поэтому подправил результат html из FreeBSD
На скриншотах мы видим результат работы команды, пойдем по порядку.
Size 2512M — RAM*2
Sequential Output(Последовательный Вывод) Sequential Input(Посл. Ввод)
Per Char
это результаты записи чтения по одному байту. Демонстрируют способность ОС буферизовать такие операции.
Block
чтение-запись блоками размера 8192 байта.
Rewrite
думаю не нуждается в объяснении
Random Seeks(случайные операции чтения)
Seeks — число случайных операций чтения
Sequential Create (последовательное создание файлов)
Random Create(произвольное/случайное создание файлов)
Думаю что теперь читателю не понятны лишь строки заполненные символами +++ — тест завершился настолько быстро, что программа не может отобразить результат.
Ваводы:
Как видно результаты работы программы разбиты для лучшего восприятия. Запуск программы с настройками по умолчанию я оставлю без внимания, сосредоточимся на последних четырех скриншотах.
Sequential Output(Последовательный Вывод)
Как видно в «побайтном» Per Char тесте Linux уносится в точку настолько быстро, что FreeBSD со своим 169 KB/s не успевает дойти даже до процесса начальной загрузки. 22183 KB/s в Linux против 169 KB/s в FreeBSD. Загрузка CPU отличается минимально.
В тесте где размер записи равен 8192 B FreeBSD побеждает практически с двойным отрывом. 48840 KB/s в FreeBSD против 28895 KB/s в Linux. Но FreeBSD загрузила CPU в два раза больше.
Тест Rewrite показал незначительную разницу, 23306 KB/s в FreeBSD против 18529 KB/s в Linux. Из чего можно сделать вывод что механизмы кеширования тестируемых ОС примерно равны по эффективности.
Sequential Input(Посл. Ввод)
Здесь победа явно за Linux. Per Char 350 KB/s в FreeBSD против 26435 KB/s в Linux. Блоками в 8192 b, 67290 KB/s FreeBSD против 86610 KB/s в Linux.
Random Seeks(случайные операции чтения)
Linux выигрывает этот тест, 165.1с в FreeBSD против 148.5с в Linux.
Перейдем к последним двум скринам
Sequential Create (последовательное создание)
В этом тесте производится последовательное создание/чтение/удаление файлов. Напомню читателю что мы создаем 100 файлов в 20-ти поддиректориях произвольного размера от 0 до 16 KB.
Скорость измеряется в файлах в секунду. Создание, FreeBSD 103 файла/с против 3099 файлов/с у Linux, так же прошу обратить ваше внимание на загрузку CPU. Чтение, 1556 файлов/с у FreeBSD против 34204 файлов/с у Linux. Удаление 12206 файлов/с у FreeBSD против 14121 файлов/с у Linux. Linux, с огромным отрывом от преследователя, разрывает финишную ленту.
Random Create(произвольное/случайное создание)
И здесь Linux бесспорный лидер. Создание, FreeBSD 100 файлов/с против 20187 файлов/с у Linux. Чтение, 166 файлов/с у FreeBSD против 3299 файлов/с у Linux. Удаление 9139 файлов/с у FreeBSD против 11638 файлов/с у Linux
Подводя черту под результатами bonnie++ можно заметить что Linux, за некоторым исключением, одержал уверенную победу. Операции по созданию большого количества файлов небольшого размера происходят в разы быстрее чем в FreeBSD. Но советую читателю не спешить с окончательными выводами, не все так очевидно. Идем дальше.
Для наглядности результаты я приведу в графиках. С указанными ключами программа создает довольно таки увесистый файл отчета, в графиках я выделил наиболее интересные, на мой взгляд, результаты.
Первым будет тест на запись.
Результаты отображенные на первом графике не оставляют FreeBSD никакого шанса. При создании файла размером 16Mb блоками от 4-х килобайт до 16 мегабайт среднее значение Linux равно ~204 MB/s, FreeBSD 44.7 MB/s.
Файл размером 128 MB, при досижении размера блока 128KB картина резко меняется и FreeBSD уверенно вырывается вперед. Средние значения таковы: Linux ~47.8 MB/s, FreeBSD 48.3 MB/s.
Файл размером в 1Gb. FreeBSD держит ту же скорость что и с двумя предыдущими файлами. Linux же, напротив, сильно сбавил обороты. Средние значения таковы: Linux ~33 MB/s, FreeBSD 48.5 MB/s.
Как видно с более мелкими файлами Linux справляется значительно быстрее, как мы уже могли заметить. С файлом размером в 1Gb FreeBSD берет реванш. Так же показательно то, что FreeBSD выдерживает одну и ту же скорость вне зависимости от размера файла.
Следущим по списку у нас идет чтение.
Превым на растерзание отдаем файл размером 16 Mb. Соревнующиеся идут почти корпус в корпус.
Средние значения: Linux ~534 MB/s, FreeBSD ~538 MB/s.
Файл 128 Mb. Со старта Linux уходит с прошлифовкой, но уже на чекпоинте в 64 KB оппонент его доганяет и начинается ожесточенная борьба, к финишу первым успевает все же Linux. Средние значения: Linux ~515 MB/s, FreeBSD ~380 MB/s.
Добравшись до нашего тяжеловеса тестируемые ОС порыкивают на старте.
Файл размером 1Gb. Linux оставив FreeBSD глотать дым на старте уходит в отрыв, как видно, скорость достигает 1Gb/s. После контрольной точки(начиная с размера блока в 128KB) FreeBSD держится в хвосте с небольшим отставанием от лидера. Средние значения: Linux ~553 MB/s, FreeBSD ~369 MB/s.
В скорости чтения Linux гораздо быстрее чем FreeBSD. Независимо от размера файла.
Рандомная(случайная) запись
Файл 16 Mb. Результаты говорят сами за себя, у Linux мы наблюдаем плавную кривую, FreeBSD от чего-то уходит на питстоп после чекпоинта 1Mb и еле еле дотягивает до финиша. Средние результаты: Linux ~356.8 MB/s, FreeBSD ~255.5 MB/s.
Файл 128 Mb. FreeBSD очевидно так и не оклемалась и показывает удручающие результаты, Linux к финишу тоже почувствовал себя неладно, разница между размерами блока в 8 Mb и 16 Mb разительна. Средние результаты: Linux ~6 MB/s, FreeBSD ~3.8 MB/s.
Файл 1 Gb. Как и при последовательном создании файла большого размера FreeBSD уверенно выходит вперед, Linux нагоняет соперника только к финишу. Средние результаты: Linux ~12 MB/s, FreeBSD ~26 MB/s.
Рандомное(случайное) чтение
Первый график, Linux лишь немного вырвался вперед, но был настигнут уже на чекпоинте 32 KB. Далее соперники двигались вровень, с очень незначительным приемуществом FreeBSD. Средние результаты: Linux ~523 MB/s, FreeBSD ~458 MB/s.
Картинка с результатами теста файла размером 128 Mb отличается от первой очень незначительно, с той лишь разницей, что явного лидера, начиная с размера блока в 64 KB, так и не обозначилось. Средние результаты: Linux ~476 MB/s, FreeBSD ~362 MB/s.
Последний график дает нам четкое понимание, что Linux далеко в авангарде, при операциях чтения файлов большого размера. Средние результаты: Linux ~523 MB/s, FreeBSD ~274 MB/s.
Под занавес итоги теста всем извесной утилитой DD.
Создадим файл размером 1 Gb из блоков размером 4 KB
FreeBSD: 49,02 MB/s
Linux: 23,9 MB/s
Читаем этот файл блоками по 4 KB
FreeBSD: 342,7 MB/s
Linux: 788 MB/s
Создадим файл размером 1 Gb из блоков размером 64 KB
FreeBSD: 48,64 MB/s
Linux: 35,0 MB/s
Читаем этот файл блоками по 64 KB
FreeBSD: 350,14 MB/s
Linux: 617 MB/s
Создадим файл размером 1 Gb из блоков размером 1 Mb
FreeBSD: 47,98 MB/s
Linux: 23,9 MB/s
Читаем этот файл блоками по 4 KB
FreeBSD: 348,51 MB/s
Linux: 460 MB/s
Создадим файл размером 1000 Mb из блоков размером 100 Mb
FreeBSD: 44,24 MB/s
Linux: 37,7 MB/s
Читаем этот файл блоками по 4 KB
FreeBSD: 308,61 MB/s
Linux: 459 MB/s
Создадим файл размером 100 Gb из блоков размером 1 Gb
FreeBSD: 31,7 MB/s
Linux: 14,7 MB/s
Читаем этот файл блоками по 4 KB
FreeBSD: 57,48 MB/s
Linux: результат получить не удалось
FreeBSD явно быстрее Linux при создании файлов. Linux более силен в чтении файлов.
262144+0 записей считано
262144+0 записей написано
скопировано 1073741824 байта (1,1 GB), 45,0159 c, 23,9 MB/c
262144+0 записей считано
262144+0 записей написано
скопировано 1073741824 байта (1,1 GB), 1,36295 c, 788 MB/c
16384+0 записей считано
16384+0 записей написано
скопировано 1073741824 байта (1,1 GB), 28,2238 c, 38,0 MB/c
16384+0 записей считано
16384+0 записей написано
скопировано 1073741824 байта (1,1 GB), 1,73935 c, 617 MB/c
1024+0 записей считано
1024+0 записей написано
скопировано 1073741824 байта (1,1 GB), 30,711 c, 35,0 MB/c
1024+0 записей считано
1024+0 записей написано
скопировано 1073741824 байта (1,1 GB), 2,33447 c, 460 MB/c
10+0 записей считано
10+0 записей написано
скопировано 1048576000 байт (1,0 GB), 27,8344 c, 37,7 MB/c
10+0 записей считано
10+0 записей написано
скопировано 1048576000 байт (1,0 GB), 2,28437 c, 459 MB/c
100+0 записей считано
100+0 записей написано
скопировано 107374182400 байт (107 GB), 7315,88 c, 14,7 MB/c
0+0 записей считано
0+0 записей написано
скопировано 0 байт (0 B), 7,5694e-05 c, 0,0 kB/c
Эпилог
Идея провести тест, как я уже писал, родилась спонтанно. Изначально просто хотелось собрать Software RAID под backup'ы на бюджетной машинке, а затем уже влез этот VS, мать его чтоб его. Для меня выбор очевиден — FreeBSD, она бастрее при создании файлов, особенно при создании файлов большого размера. Как раз то, что мне нужно. Проведя этот тест я лишь еще раз убедился в правильности занятой позиции касаемо разных holly war'ов — все зависит от задач.
Хотя я снова не договариваю всей правды. Выбор в пользу FreeBSD был сделан еще до теста. Так как эту ОС я просто знаю намного лучше нежели Linux, и нравится она мне много больше. Если же взглянуть на результаты объективно, то победу я, абсолютно заслуженно, отдам Linux'у. Вновь пробежавшись по результатам тестов в этом не остается сомнений.
Кто то может справедливо заметить, а зачем же ты столько «заморачивался» с этими тестами, уже bonnie++ тебе все сказал, но нет. Я привык ко всему подходить вдумчиво, с чувством, с толком. Да и появившееся свободное время позволяло поэкспериментировать.
Насколько грамотен и информативен мой отчет решать вам, я не профессионал в *nix, мой путь в этот увлекательный мир начался сравнительно недавно.
Спасибо тем кто осилил.
Всем известны параметры производительности дисковых подсистем в теории. Но что на практике? Многие задают этот вопрос, некоторые строят свои гипотезы. Я решил провести серию тестов и определить «Who is who». Приступил к тестированию всеми известными утилитами dd, hdparm, далее перешел к fio, sysbench. Также был произведен ряд тестов используя UnixBench и несколько других аналогов. Было построено ряд графиков, но по мере дальнейшего тестирования было обнаружено что большинство этого ПО непригодно для адекватного сравнения разных дисков.
С помощью fio можно было составить сравнительную таблицу или график для SAS, SATA, но при тестировании SSD оказалось, что полученные результаты вовсе непригодны. Я конечно уважаю разработчиков этого всего софта, но в этот момент было принято решение создать ряд не синтетических тестов, а более близких к реальной обстановке.
Сразу скажу, что параметры теста и сами машинки были подобраны таким образом, чтобы результаты теста не были искажены типом процессора, его частотой или другими параметрами.
Тест 1
Создание файлов
В течении восьми циклов генерировалось создание небольших файлов с хаотическим содержанием и с постепенным ростом количества файлов на цикл. По каждому циклу измерялось время выполнения.
Из графика видно что большую скорость создания файлов имеют SSD KINGSTON SV300S3 и почти не зависят от их количества. Также стоит отметить что именно эти диски имеют более прямолинейную шкалу
По SAS дискам в Hardware RAID видно что скорость зависит от типа рейда, но совсем не зависит от количества дисков.
Но больше времени тратится не на создание файлов, как оказалось, а на их перезапись. По этому перейдем к второму тесту.
Тест 2
Перезапись файлов
Повторялись те что операции что в первом тесте, но файлы не создавались новые каждый раз, а использовался один и тот же файл, в который записывалась каждый раз новая информация.
Сразу бросается в глаза ужасная картина по дискам SATA 7,200 rpm MB2000GCVBR. Медленная запись и по 2x 300GB SAS SEAGATE. По этому решил выбросить их из графика для наглядности по остальным.
Самой быстрой подсистемой оказался одиночный SSD KINGSTON. Второе и третье место заняли 8x SEAGATE ST3300657SS и 4x SEAGATE ST3300657SS. Также видим что с ростом количества SSD в массиве скорость немного падает.
Тест 3
MySQL. Комбинирование sql-запросов INSERT, SELECT, UPDATE, DELETE
Была создана InnoDB таблица со следующей структурой:
CREATE TABLE `table` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`time` int(11) NOT NULL,
`uid` int(11) NOT NULL,
`status` varchar(32) NOT NULL,
PRIMARY KEY (`id`),
FULLTEXT KEY `status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251;
Одновременно генерировалось несколько запросов:
— INSERT;
— UPDATE с выборкой по PRIMARY KEY;
— UPDATE с выборкой по FULLTEXT (поиск по 4 символам из 24-х): WHERE `status` LIKE '%(string)%';
— DELETE FROM с выборкой по PRIMARY KEY;
— DELETE FROM с выборкой без использования ключа: WHERE `time`>(int);
— SELECT с выборкой без использования ключа: WHERE `time`>(int);
— SELECT с выборкой по PRIMARY KEY;
— SELECT с выборкой по FULLTEXT (поиск по 4 символам из 24-х): WHERE `status` LIKE '%(string)%';
— SELECT с выборкой без использования ключа: WHERE `uid`>(int).
И снова наблюдаем ту же картину что во втором тесте.
В следующих тестах использую утилиту sysbench, которая генерирует файлы большого объема:
128 файлов, общим размером 10 Гб, 30 Гб и 50 Гб.
Размер блока 4 Кб.
Сразу хочу обратить внимание, что на некоторых графиках, по некоторым серверам нету данных на 10 Гб. Это связано с тем что на данных машинах имеется оперативной памяти более 10 Гб и выполняется кэширование данных. Отсутствие некоторых результатов на 50 Гб обусловлено нехваткой дискового пространства, в случае с SSD KINGSTON SV300S3.
Тест 4
Линейная запись (создание файлов)
Видно что лучшие показатели имеются у всех вариациях с SSD KINGSTON SV300S3, а также у 8x SEAGATE ST3300657SS в RAID10. Очень хорошо просматривается рост скорости с увеличение количества дисков SAS.
Здесь тот самый момент, где отлично видно что SSD совершенно разные бывают. Разница в 4 раза!
Тест 5
Линейная запись (перезапись файлов)
Лидеры все те же. Если сравнивать 2x SSD от INTEL и 2x SAS разницы практически никакой.
Тест 6
Линейное чтение
Здесь же видим чуть иную картину. Лидируют 4x SSD KINGSTON RAID10, с минимальным изменением результатов при увеличении объема файлов, и 8x SEAGATE в RAID10, с постепенным спадом скорости, на скоростях 700 Мбит/сек и 600 Мбит/сек.
Линии по 1x SSD KINGSTON и 2x SSD KINGSTON RAID1 совпали. Проще говоря для линейного чтения лучше брать или RAID10 или одиночный диск. Использование RAID1 не оправдано.
Хорошо видно что показали 2x SAS RAID1 и 4x SAS RAID10 очень похожи. Но при увеличении количества дисков в два раза просматривается огромный прирост скорости.
2x SSD Intel RAID1 имеет не малое падение скорости на промежутке 10 Гб — 30 Гб, а далее идут на одной скорости с SATA RAID1.
Тест 7
Рандомное чтение
В лидерах все SSD:
— 4x KINGSTON RAID10;
— 2x KINGSTON RAID1, 2x INTEL RAID1;
— 1 KINGSTON.
Всех остальных скопировал на следующий график для наглядности.
Наивысшую скорость среди этих имеет естественно 8x SAS RAID10, но скорость резко падает. Но исходя из данных по 2x SAS и 4x SAS предположу что с дальнейшем ростом объемом скорость стабилизируется.
Тест 8
Рандомная запись
Отличные показатели имеет 2x 120GB SSD INTEL SSDSC2CT12 Hardware RAID1 SAS1068E со стабильной скоростью 30 Мбит/сек. По KINGSTON с ростом количества дисков скорость, как ни странно, падает. На четвертом месте 8x SAS SEAGATE.
Тест 9
Комбинированные операции рандомного чтения и записи
Все мы знаем, что ни на одном сервере нету только чтения или только записи. Всегда выполняются обе операции. И в большинстве случаев это как раз рандомные операции, а не линейные. И так, посмотрим, что у нас получилось.
За счет отличной скорости записи с большим отрывом идет 2x SSD INTEL, за которым следует SSD KINGSTON. Третье место разделили 2x SSD KINGSTON и 8x SAS SEAGATE.
Тест 10
После проведения всех этих тестов я решил что будет удобно вывести зависимость скорости от соотношения операций рандомного чтения и рандомной записи.
У кого рост скорости, у кого падение, а у 8x SAS RAID10 прямая линия.
Тест 11
Произвел также сравнение больших массивов из SAS дисков, по которому видно, что от скорости диска больше зависит, чем от их количества.
- С ростом количества SAS дисков в массиве все показатели только улучшаются.
- Для MySQL медленные подсистемы это SATA RAID1 и SAS RAID1. По остальным отличия есть, но они не столь существенны.
- Для линейно записи хороши как большие массивы из SAS дисков в RAID10, так и SSD. Смысла использовать массивы из SSD нет. Стоимость растет, а производительность на месте.
- Для линейного чтения хороши любые большие массивы. Но на практике лин. чтение без записи у нас почти не встретить.
- Рандомное чтение за SSD одиночными или в Software RAID.
- Для рандомной записи лучше использовать Hardware RAID из SSD, хотя не сильно поступаются и одиночные SSD.
- Рандомные чтение/запись, то есть один из самых важных показателей, имеют лучшие результаты на Hardware RAID из SSD.
- Обобщая все вышесказанное, для большинства задач лучше использовать большие массивы (>=8) из SAS или Hardware RAID из SSD. Но для некоторых задач корректнее будет использовать одинарные SSD.
- Исходя из объемов SSD, которые преимущественно предлагаются на нашем рынке, под VDS-ноды стоит использовать максимальной производительности процессоры в паре с большими SAS массивами или же средненькие процессоры и одинарные SSD. Считаю что использование hw raid для двух SSD будет дороговато.
- Если вам необходима быстрая система и нет необходимости в большом дисковом пространстве 2x SSD в Hardware RAID будет лучшим выбором. Если желаете немного сэкономить в ущерб производительности, тогда можно взять одинарный SSD или два SSD в софтовом рейде.
- Что происходит при увеличении количества SSD в Hardware RAID?
- Что дешевле под виртуальные сервера: дорогие машинки и один большой массив из SAS или же несколько средненьких серверов с одинарными SSD? В этом вопросе также следует учесть надежность/долговечность SAS и SSD, так как по последним ходят разные слухи.
Кроме перечисленных тестов и серверов было еще множество, но они не попали в результаты, так как на них проводилась «калибровка» тестов и многие их них были признаны некорректными.
Также производилось тестирование RAMDisk. Показатели были довольно хорошие, но не лучшие. Вероятно из-за того что это была виртуальная машина.
Все тесты, кроме последнего, производились только на выделенных серверах.
В первых персональных компьютерах винчестеров вообще не было. Чуть позднее они стали штатным оборудованием. Еще позднее в основном были решены проблемы совместимости, мешающие использованию одновременно и поддерживаемой в теории пары устройств, а к концу 90-х годов прошлого века конфигурация среднестатистического компьютера потенциально могла включать в себя уже и четыре винчестера. С этого момента многие пользователи заинтересовались уже использованием накопителей не по-отдельности, а в составе единого массива — как во «взрослых системах». В последних, впрочем, чаще всего применялся SCSI-интерфейс, доступный и владельцу обычной «персоналки», но излишне дорогой — требовались дешевые решения. И они появились в виде контроллеров IDE RAID.
Заметим, что наиболее часто используемым вариантом был RAID0, строго говоря, к «RAID-массивам» не относящийся, поскольку избыточность данных он не обеспечивает. Надежность хранения сравнительно с одиночным диском даже снижает. Но иногда было просто некуда деваться, поскольку винчестеры тех лет были слишком медленными для некоторых сфер применения, а альтернативных решений с более высокой производительностью не было вовсе. Использование же чередования позволяло их заметно «пришпорить». Но применялись (да и сейчас применяются) и «зеркала» (RAID1) — для повышения надежности. А наиболее обеспеченные граждане могли объединить достоинства обоих подходов посредством создания массива RAID10, что позволяло повысить и скорость, и надежность. Других режимов в те времена в массовых контроллерах «не водилось»: слишком сложными были для программной реализации — с учетом вычислительных возможностей систем того времени.
Через некоторое время дискретные RAID-контроллеры начали устанавливать и на топовые системные платы — надо же было чем-то выделяться их производителям. В итоге к массивам стали приглядываться и пользователи, ранее о них не задумывавшиеся — раз уж возможность есть. В итоге идею подхватили сами производители чипсетов, так что возможность создания RAID-массивов стала стандартной для последних. Как минимум — для старших модификаций. Причем к числу возможных вариантов добавился и RAID5, на первый взгляд выглядящий очень привлекательно: более экономным расходованием дискового пространства, чем у RAID10, но при обеспечении необходимой для надежности хранения избыточности.
А позднее начались новые времена — винчестеры перестали быть основным и единственным типом накопителей, применяющихся в компьютере. Внедрение твердотельных накопителей прервало эволюцию, оказавшись революционным шагом с точки зрения производительности. Правда было оно достаточно медленным — просто потому, что и стоимость хранения информации первое время была очень высокой. Довольно быстро снижалась, но и сейчас до паритета с винчестерами еще далеко — особенно если рассматривать «настольные» модели. Да и с абсолютной емкостью тоже пока все не просто: теоретически флэш-памяти в стандартный корпус «напихать» можно очень много, а практически это будет слишком уж дорого. Собственно, поэтому до сих пор подавляющее большинство компьютеров продается лишь с одним-единственным винчестером в качестве накопителя «для всего»: и для программ, и для данных. В принципе, даже устройств этого класса минимальной на сегодня емкости достаточно для того, чтобы полностью закрыть все потребности среднестатистического пользователя, поэтому в бюджетном сегменте такой вариант долго еще будет преобладающим, несмотря на низкую производительность. А вот чуть выше решений минимальной стоимости у покупателя есть выбор, часто приводящий его к одному из гибридных вариантов системы хранения данных. Самым дешевым (но пока до конца не изученным и освоенным) способом является кэширование посредством технологии Optane Memory. Более дорогим, но предсказуемым и совместимым со старыми системами — использование SSD невысокой емкости для операционной системы и приложений в паре с тихоходным, но очень емким винчестером для хранения данных. В итоге про RAID-массивы в бытовых персоналках все как-то и забыли. Хотя некоторые пользователи считают, что зря — все-таки и емкость самая большая (в пределах фиксированного бюджета), и производительность должна быть более высокой, чем у одиночного накопителя. Пусть, даже, и не на столько, как обеспечивают твердотельные накопители, но ведь дешево же — а вдруг и этого хватит на практике. Поэтому мы сегодня решили немного отклониться от основной линейки тестов и посмотреть — как ведут себя лучшие винчестеры в т. ч. и в массивах из двух-трех дисков, сравнительно с разными твердотельными накопителями.
Участники тестирования
Поскольку в наших руках оказалось одновременно три не совсем идентичных, но почти идентичных винчестера Seagate, они и выступили в роли «подопытных кроликов». Было бы сразу четыре — можно было бы и RAID10 организовать, а так пришлось ограничиться RAID0 из двух и RAID5 из трех дисков (три-четыре диска в RAID0 это уже за границей добра и зла, которую без необходимости мы стараемся не переступать), имеющие одинаковый объем в 20 ТБ. Собственно, чем RAID5 многим и кажется привлекательным — «пропадает» всего один накопитель в массиве, а не половина, как в «зеркалах» (RAID1, 10 и подобных). RAID0 еще «гуманнее», но ценой потенциальных проблем с надежностью. Сами же винчестеры — одни из лучших на сегодняшний день: модели на 10 ТБ со скоростью вращения 7200 об/мин, использующие заполнение гермоблока гелием. Понятно, что в роли системного и единственного накопителя даже один такой винчестер выглядит странно (мягко говоря), однако дает оценку сверху того, что вообще можно получить от массивов. Недорогие устройства малой емкости просто медленнее, в чем мы уже не раз убеждались.
С кем будем сравнивать? Во-первых, интересна разница в пределах группы. Во-вторых, для части тестов мы отобрали следующую четверку твердотельных накопителей:
-
— медленный бюджетный SATA — чуть более «серьезный» накопитель, но тоже недорогой и тоже SATA — бюджетная реализация NVMe-устройства — похоже, но не бюджетно
Можно было бы ограничиться и меньшим количеством, но мы решили пойти навстречу читателям, жалующимся на то, что в статьях сайта редко сравниваются твердотельные накопители разных классов или, тем более, твердотельные с механическими. Просили? Сами виноваты :)
Тестирование
Методика тестирования
Методика подробно описана в отдельной статье. Там можно познакомиться с используемым аппаратным и программным обеспечением. Для данной статьи нам ее пришлось, немного доработать, поскольку участие в тестировании сегодня принимают и винчестеры, и твердотельные накопители, но касается это в основном использования результатов (благо тестовые программы в основном пересекаются) и их группировки.
Последовательные операции
Для начала начнем с «чисто винчестерных» тестов, в которых твердотельные накопители по понятным причинам не участвуют — для них нет зависимости скорости от конкретной области данных.
Как и предполагается априори, скорость чтения удваивается. Точнее, для RAID0 из двух дисков это очевидно. Для RAID5 на трех дисках — в общем-то тоже: для данных используется то же самое чередование. В итоге даже минимальная скорость чтения оказалась выше средней одиночного диска, а средняя — выше максимальной. Идеальный случай.
Потому что при записи все уже не так просто. Точнее, для RAID0 — по-прежнему просто и быстро, на что любят упирать «любители» этого типа массивов (который, строго говоря, RAID-массивом и не является, как уже было сказано выше). Все также работает чередование блоков с данными, так что два винчестера (или большее их количество) работают, по сути параллельно.
А вот ситуация с RAID5 печальна. Однако легко объяснима: специфика организации этого типа массивов такова, что практически любая операция записи превращается в две операции чтения и две записи, которые должны «отработать» практически одновременно. Итоговая производительность в случае «чипсетного» контроллера, фактически лишенного собственных «мозгов», так что реализующего всю необходимую функциональность на базе программного драйвера, оказывается удручающе низкой. «Нормальный аппаратный» контроллер способен ослабить проблему, но не решить ее полностью — RAID5 все равно остается одним из самых медленных типов массивов в любых условиях. Радикальным способом решения проблемы (да и практически единственно-возможным для программной реализации) является использование RAID10, сочетающего в себе и производительность, и отказоустойчивость, но. Но ценой потери уже половины потенциального пространства, т. е. для создания массива в те же 20 ТБ потребуется уже не три, а четыре диска по 10 ТБ, о чем было сказано в начале статьи. Впрочем, можно «выжать» и из чипсетного RAID5 немного больше: подбором размера блока чередования и кластера файловой системы, чем мы не занимались, оставив значения по-умолчанию. Однако повысить скорость записи до уровня хотя бы одиночного винчестера и это не позволяет — в отличие от RAID10, обеспечивающего ее удвоение (пусть и высокой ценой). В лучшем случае получается повысить скорость примерно до 100 МБ/с, т. е. RAID5 на практике даже при тонкой настройке снижает производительность операций записи. Где-нибудь в NAS это не важно: данные записываются редко, а читаются часто, да и лимитирует производительность сам по себе сетевой интерфейс (как раз значениями в районе сотни мегабайт в секунду, а то и меньше), так что высокая емкость и отказоустойчивость выходят на первый план. А вот в персональном компьютере или рабочей станции массивы такого типа просто не интересны. Точнее, интересны еще меньше, чем RAID0 или RAID1. А ведь и у первых уже появились серьезные конкуренты, но об этом чуть ниже.
Время доступа
Если при чтении данных латентность практически неизменна, то при записи в массиве RAID0 она резко снижается. В чем, впрочем, заслуга, скорее, не его, а алгоритмов кэширования, применяемых контроллером для массивов. Но, как видим, RAID5 и это никак не помогает. Даже наоборот, что вполне согласуется с логикой его работы.
Последовательные операции (Crystal Disk Mark)
Поскольку HD Tune Pro при тестировании твердотельных накопителей мы не используем, а вот Crystal Disk Mark «прогоняется» везде, посмотрим на его результаты.
Как и положено, производительность при чтении данных примерно удваивается. Забавный результат в многопоточном режиме связан с тем, что при использовании ограниченной области данных (в программе, напомним, мы используем лишь 2 ГБ) и современных алгоритмов внутреннего кэширования винчестеров, вкупе с нынешними емкостями кэш-памяти, данные зачастую в ней и будут оказываться еще до соответствующего запроса. Остается только передать нужный блок по интерфейсу, что происходит очень быстро. Это позволяет с легкостью опережать SATA SSD (поскольку их сдерживает именно интерфейс), да и в однопоточном режиме от них практически не отставать. Но только в «тепличных условиях» — внешние дорожки (на внутренних скорость вдвое ниже, что уже было показано выше), небольшие объемы данных. Что бывает в более сложных случаях — посмотрим чуть позже.
С записью же все намного хуже: чем-то подстегнуть многопоточный режим не получается, так что он не только медленнее однопоточного, но и удвоения скорости сравнительно с одиночным накопителем уже не наблюдается. Но в один поток потягаться с SATA SSD хотя бы можно. Во всяком случае, при использовании RAID0 из двух дисков. Если бы мы объединили в такой массив три имеющихся винчестера — было бы еще быстрее, хотя и слишком перпендикулярно здравому смыслу. А с RAID5 все традиционно плохо. Поэтому в последующих тестах мы его использовать не будем — и без того картина ясна.
Работа с большими файлами
Как и следовало ожидать на основании низкоуровневых тестов, в однопоточном режиме хотя бы на внешних дорожках скорость чтения сравнима с SATA SSD. Но если нужно считать 32 ГБ в 32-х файлах по 1 ГБ, производительность резко падает почти до уровня одиночного винчестера (кэширование же при таких объемах ничем помочь уже не может). Для твердотельных же накопителей, напротив, это идеальный случай. А если они не ограничены интерфейсом — тем более.
Чем, все-таки, до сих пор привлекательны механические накопители — симметричностью производительности при записи и чтении, чего для флэш-памяти и близко нет. Соответственно, на операциях записи даже некоторые NVMe-накопители могут оказаться медленнее одиночного современного винчестера. Двух — тем более. Но если не рассматривать самые медленные из устройств, то опять ничего похожего на «честную конкуренцию» не наблюдается.
А запись одновременно с чтением — хороший случай для большинства SSD и плохой для винчестеров. Причем твердотельным накопителям и (псевдо)случайный режим «жизнь не портит», в отличие от. Таким образом, быстро прочитать или записать большой объем данных современные винчестеры могут — если есть куда или откуда. Объединенными в массив RAID0 сделают это быстрее. Но поскольку обработка данных предполагает обычно и запись, и чтение, и далеко не всегда последовательные — для этой цели уже лучше использовать твердотельные накопители. Если, конечно, объемы позволяют. А вот хранить данные лучше там, где это обходится дешевле.
Производительность в приложениях
Но основной темой сегодняшней статьи было вовсе не исследование вопросов хранения и обработки больших массивов данных, хотя и это тоже интересно. Еще важнее — оценить перспективность использования RAID0 для ускорения обычной работы за компьютером. Когда-то это позволяло что-то выиграть сравнительно с одиночным винчестером, но тогда и программы были другими, да и операционные системы тоже. Да и сравнивать сейчас уже нужно не только «механику с механикой». Вот и сравним :)
Тестируя SSD, мы временами жаловались на то, что с точки зрения тестов высокого уровня они слишком похожи. Тестируя винчестеры — аналогично. Но они «по-разному похожи»: это два непересекающихся мира. А одиночный винчестер и RAID0 из винчестеров — один мир. Совсем один. Потенциальное ускорение от чередования к настоящему моменту по сути рассосалось: современные операционные системы и с одиночным винчестером работают настолько эффективно, насколько он позволяет (чему сильно помогает развитое кэширование данных в оперативной памяти, радикально улучшившееся в современных версиях Windows — пусть это и вызывает жалобы некоторых пользователей, привыкших к примитивной Windows XP и более ранним, на «расход памяти»). Снижение задержек пригодилось бы, но его при чтении данных (что важно для тестов высокого уровня) как раз и нет.
И даже по низкоуровневому баллу появляются различия между разными моделями твердотельных накопителей, но не более того. Винчестеры (что с ними не делай) намного медленнее. Причем в этом случае и порядки-то величин разные, что «замаскировать» получается лишь потому, что реальная работа приложений «упирается» и в другие компоненты компьютера. А иногда и в самого пользователя, что и не всегда позволяет реализовать потенциальные возможности накопителей. Твердотельных. У «механики» таковых и не водится.
Кстати, и предыдущая версия тестового пакета ведет себя аналогично. Когда-то, кстати, PCMark на массивы реагировал хорошо — но это было под управлением других ОС и на трассах, имитирующих другие приложения. А сейчас уже так. Подробные результаты, думаем, уже не нужны.
Рейтинги
Как видим, с точки зрения тестов низкого уровня, ориентированных в первую очередь на SSD (так что изобилующими операциями со случайным доступом) сравнивать «механику» (что с ней не делай) и SSD большого смысла нет. Но и ничего удивительного в этом тоже уже нет — для винчестеров лучший сценарий это однопоточный последовательный, однако, как уже было показано выше, и в этом случае о прямой конкуренции говорить не всегда приходится. Иногда при записи, разве что, но и при этом «потолок» винчестеров (и массивов из них) сопоставим лишь с «полом» твердотельных накопителей с SATA-интерфейсом (eMMC-модули — отдельная история; но они и используются чаще всего там, куда никакие другие накопители просто «не лезут»).
Да и «подмешивание» к оценке результатов тестов высокого уровня не слишком меняет картину. По совокупности разные SSD при этом отличаются друг от друга примерно вдвое, поскольку мы взяли один из самых медленных и один из самых быстрых из протестированных накопителей, радикально различающихся конструктивно. Однако при этом и «самый медленный» быстрее массива RAID0 из пары топовых винчестеров даже не в два, а в два с половиной раза. Комментарии излишни.
Итого
В общем и целом, картина понятная. Равно как понятно и то, почему тема RAID-массивов в персональных компьютерах практически сошла на нет. Во всяком случае, в их «винчестерной» ипостаси — с массивами из SSD некоторые энтузиасты продолжают баловаться, чему способствуют производители, реализовав, в частности, возможность создания RAID из NVMe-устройств. Да и в топовых ноутбуках нет-нет да и встречаются RAID0 из пары твердотельных накопителей — в основном, конечно, чтобы блистать в обзорах. На этом всё. В тех сферах, где технология RAID-массивов зарождалась, она по-прежнему является нужной и полезной, но в ПК ей делать особо нечего. С одной стороны, современные ОС способны и из одиночного винчестера «выжимать» все, на что он способен, так что улучшением части характеристик «подстегнуть» производительность не получится. С другой — доступными стали более быстрые накопители. В том числе, существенно более быстрые в тех сценариях, ради которых до сих пор имеет смысл использовать RAID-массивы с увеличением производительности (благодаря чередованию). А «настоящие» RAID (т. е. с избыточностью хранения данных) по-прежнему полезны, но в бюджетном исполнении силами программного обеспечения они могут заметно понизить производительность. Кроме того, RAID в любом случае не заменяет резервного копирования данных, так что начинать надо с него, а не наоборот.
Недавно мы попробовали «поиграть» с массивами RAID0 из пары NVMe-накопителей и пришли к выводу, что это лишено практического смысла. Точнее, смысл может быть лишь в том случае, когда массив создается из двух одинаковых топовых устройств, а возможность просто купить аналогичное устройство соответствующей емкости физически отсутствует. Да и то речь, скорее всего, будет идти только о «набивании попугаев», поскольку для прикладного программного обеспечения скоростные возможности даже бюджетных твердотельных накопителей избыточны. И даже если вдруг окажется, что старого маленького медленного SSD уже как-то не хватает, его проще заменить на новый большой и быстрый, а не пытаться докупить второй старый маленький медленный, дабы объединить их в RAID-массив.
С другой стороны, такой подход не всегда реализуем. Возьмем, например, старый SATA SSD: очевидным путем его модернизации является переход на NVMe, но в старой системе он не всегда возможен. Кроме того, менять, например, полтерабайта MLC с SATA-интерфейсом на терабайт TLC под PCIe не всем понравится, а вот покупка еще одного SSD, аналогичного имеющемуся, может оказаться куда менее затратным и более простым мероприятием. Да и никакой пугающей новизны в данном случае нет, о проблемах пропускной способности PCIe при использовании нескольких устройств можно не думать, да и вообще — подобный массив можно собирать на очень многих платформах, в то время как NVMe RAID без серьезных плясок с бубном создается только на самых «свежих», и то не на всех.
В общем, смысл вроде бы прослеживается. Но что получится на практике? Во всяком случае, интересно посмотреть — чем мы сегодня и займемся.
Методика и объекты тестирования
Методика подробно описана в отдельной статье, там же можно познакомиться с используемым аппаратным и программным обеспечением.
Основным рабочим телом нам послужит Silicon Power Velox V85 480 ГБ: уже пожилое устройство на базе контроллера Phison PS3110-S10 и 15-нанометровой MLC-памяти Toshiba. Второго в точности такого не нашлось, но такой же емкости и построенный на идентичной платформе — без проблем. Это еще один плюс идеи SATA RAID0: симметричность обеспечить очень легко.
Из прошлого материала мы взяли также результаты Intel SSD 600p и WD Black первого поколения по 512 ГБ — поодиночке и в массиве. Пусть массив получился бестолковым с практической точки зрения, но для сравнения он нам подойдет. Также возьмем Intel Optane SSD 800P 118 ГБ и два Optane SSD 800P в массиве RAID0, благо в свое время мы такой массив собирали. Три немножко разных массива RAID0 дадут нам в сумме немного больше информации о собственно RAID0 на современных платформах. И это важно, поскольку основная наша задача сегодня — все-таки исследовательская, а не практическая :)
Поскольку сегодняшнее тестирование достаточно специфично, мы не стали заносить результаты тестов в общую таблицу: они доступны в отдельном файле в формате Microsoft Excel. Так что желающие покопаться в цифрах (тем более, что не все они попадают на диаграммы) могут скачать его и удовлетворить любопытство.
Производительность в приложениях
Два симметричных массива работают чуть быстрее, чем накопители, из которых они построены — асимметричный наоборот. С другой стороны, разброс производительности здесь настолько не велик, чтобы об этом вообще стоило задумываться. Причина озвучена неоднократно — и самого медленного из испытуемых уже достаточно для того, чтобы производительность определялась не им.
Да и потенциальный выигрыш не так уж велик — даже когда он есть. Это для Optane 800p фактическое удвоение ширины интерфейса и степени чередования полезно, но в случае SATA и протокола AHCI (а другой тут неприменим) много уже не наработаешь. Даже Intel SSD 600p (один из самых медленных накопителей в своем классе) и то заметно быстрее в этом тесте, а попытка использовать его в паре с еще одним «неторопливым» SSD результат только уменьшает — но все равно не до уровня «увеличенного» SATA RAID0.
Предыдущая версия пакета, оперирующая более «легкими» нагрузками, более благосклонна к любым массивам. Однако не менее очевидно, что какой-то внятный прирост можно увидеть только на паре маленьких, но шустреньких «опташ», да и то — в синтетическом режиме. SATA RAID же медленнее одиночного (и медленного же) NVMe-накопителя. Такие дела.
Последовательные операции
Окончательно убеждаемся в том, что этой программе «сносит крышу» дополнительное кэширование силами драйвера при использовании RAID-массивов. Во всяком случае, на операциях чтения — запись-то выглядит правдоподобно. И показывает нам, что пропускную способность интерфейса действительно можно удвоить при помощи создания массива RAID0. Но сейчас этим уже заниматься не нужно (чаще всего), поскольку появилась уже возможность мигрировать на еще более быстрый интерфейс.
Случайный доступ
Как видим, все сценарии ведут себя по-разному — это тот случай, когда на производительность могут влиять любые факторы. Объединение накопителей в массив с чередованием — еще один дополнительный. Который может скорость как повысить (например, если при исходных данных немного «не хватает» пропускной способности интерфейса и/или степени внутреннего параллелизма), так и наоборот. В любом случае, «сменить класс» устройства этим способом не выйдет. Т. е., например, скорость чтения с единичной длиной очереди команд (что как раз и наиболее значимо на практике) зависит только от задержек самой памяти — и поэтому любые Optane здесь вне конкуренции. А никакой сменой протоколов или интерфейсов это не изменить. Тем более, объединением устройств в массив RAID0.
Работа с большими файлами
В принципе, это в первую очередь задача на интерфейс — а он в настоящее время может быть и куда более быстрым, нежели «дабл сата». В итоге прирост производительности в массиве-то «сверхлинейный», но на фоне других устройств (в т. ч. и медленных в своем классе) эффект просто теряется.
Очень многое зависит от памяти, так что SATA-накопитель на «быстрой» MLC может с легкостью обгонять PCIe на медленной TLC, а в массиве удвоить свою производительность. Но, опять же, на сегодняшний день это уже не имеет особого значения, поскольку быстрые NVMe-устройства уходят далеко за гигабайт в секунду и в одиночестве.
Аналогичный случай. Хотя и это «удобный сценарий» для массивов, но, фактически, они чем-то «помогают» лишь тем накопителям, производительность которых искусственно ограничена интерфейсом (не только SATA600 — у Optane 800p аналогичная проблема из-за всего двух линий PCIe). Но после внедрения PCIe 3.0 x4 в этот сегмент подобное случается крайне редко.
Рейтинги
Жизненное наблюдение: ранее к нам на тестирование регулярно привозили ноутбуки с RAID0 из пары SATA SSD, причем часто такие модели предназначались специально для тестовых лабораторий, а в розницу эти же модели, как правило, поступали с одиночным твердотельным накопителем либо с одним SSD и одним винчестером, а иногда и вовсе с одним только винчестером. После внедрения NVMe подобная практика прекратилась мгновенно, и причина хорошо видна на диаграммах: массив из пары SATA-накопителей способен побороться с одиночным «медленным» NVMe-устройством, но вот быстрый NVMe SSD в любых «попугаях» длиннее. Поэтому в случае современных платформ незачем и возиться. Владельцы же «старых» платформ (без поддержки NVMe) могут извлечь какую-то практическую пользу из SATA RAID0 и сейчас — но небольшую и не всегда.
Итого
На этом, как нам кажется, тему RAID-массивов в применении к массовым конфигурациям можно закрывать, благо мы рассмотрели уже почти все основные варианты. За кадром остались только связки из пары одинаковых топовых устройств (Optane SSD 800P все-таки на такое не совсем тянет), но и с ними тоже все уже ясно: где-то производительность увеличится, где-то — нет, но за пределы синтетики все эти отличия не выйдут. Во времена винчестеров, когда не хватало иногда даже последовательных скоростей, никаким способом хоть что-то ускорить пренебрегать было нельзя. Сейчас же есть более простые способы, иногда оказывающиеся и более дешевыми (можно сэкономить на платформе, да и цена твердотельных накопителей с ростом емкости увеличивается не линейно). Со всеми вытекающими.
Читайте также: