RAID массив из старых жёстких дисков
Вступление
Всем привет, это Я. Ранее я уже писал на тему жёстких дисков. В той статье я описывал, как продляю жизнь посыпавшемуся жёсткому диску WD Green ёмкостью 2 Тб. Мой метод оказался настолько будоражащим сознание, что у некоторых 
сдетонировало и они всячески критиковали мои действия. Как оказалось, посторонних, неизвестных мне людей, сохранность моих данных беспокоит больше, чем меня самого. Поразительно! Сегодня будет не менее взрывоопасный контент, ведь мы будем делать RAID 0 из четырёх старых жёстких дисков в 2020 году. Погнали!
Так уж вышло, что в моей системной плате есть встроенный RAID-контроллер, который можно включить в BIOS. С годами у меня накопилось несколько килограмм жёстких дисков. Покоя они мне не давали и я всё думал, как же мне их пристроить, чтоб не лежали без дела. В основном это диски небольшого объёма: 20 Гб, 60 Гб, 80 Гб. В общем вы поняли. Однажды вспомнил я про RAID и решил: «А дай-ка сделаю RAID 0 из завалявшихся дисков». Массив я создал вполне успешно и он работает должным образом, но прежде чем перейти к конечному варианту, покажу, какие диски будут участвовать в RAID.
Что такое RAID 0
Думаю, немного стоит написать про то, что такое RAID. RAID — массив из нескольких физических жёстких дисков, объединённых в один виртуальный носитель. Существует большое количество различных конфигураций RAID, каждый их которых обладает как плюсами, так и минусами. Чаще всего массив из нескольких дисков используется для обеспечения отказоустойчивости путём хранения избыточных данных. Большие массивы, состоящие из множества жёстких дисков, позволяют не допустить потери данных при выходе из строя сразу нескольких физических жёстких дисков.
Самый простой вариант RAID, не обеспечивающий отказоустойчивости, это RAID 0. Его плюсом является повышенная производительность по сравнению с другими реализациями RAID. По сути, всё что делает RAID 0, так это чередует записываемые в массив данные между всеми дисками массива. На входе данные разбиваются на равные блоки и записываются параллельно на все физические диски. Подобный принцип сильно повышает скорость последовательной записи и последовательного чтения. В теории скорость последовательного чтения/записи может быть равна сумме скоростей каждого диска. Хуже обстоит ситуация со случайной записью и случайным чтением мелких файлов. Впрочем, эти скорости также увеличиваются по сравнению с единичным диском, хоть и не так сильно, как в случае с последовательными операциями чтения/записи.
Основные цели, которые я преследовал при создании массива были: объединение ёмкостей дисков и максимальная производительность. Лучший выбор для этого — RAID 0.
Диски, используемые для RAID 0
Как я написал в введении, наш RAID будет состоять из четырёх дисков. Первый диск — Seagate Barracuda 80 Гб с интерфейсом IDE — самый слабенький:
Тем не менее, состояние его вполне нормальное. Сбойных секторов или прочих ошибок нет. На скриншоте ниже SMART и быстродействие этого диска в программе CrystalDiskMark:
Поскольку на моей системной плате нет разъёмов IDE, то подключить этот диск напрямую я не мог. Для этого пришлось использовать плату-контроллер. Так она выглядит:
Не подумайте, что контроллер я купил специально, дабы подключить старый диск. Делать мне нечего. Случайно я вспомнил, что он у меня валяется без дела и решил задействовать. Контроллер этот двусторонний. То есть, с его помощью можно подключить старый IDE диск к современной системной плате, но также можно подключить новый SATA диск к старой плате, у которой нет SATA контроллера. На фотографии ниже показываю, как диск подключается к плате. В разъём IDE вставляется плата-контроллер, а уже к ней подключается SATA шлейф и питание самого контроллера. Питание диска подключается как обычно:
Конечно же первый вопрос, который возникает, при работе с подобными контроллерами: «Насколько он ухудшает скорость работы диска?» Мне тоже хотелось это проверить и я подключил диск к старой плате, имеющей разъём IDE. Ниже скриншот быстродействия, но диск уже подключен напрямую IDE to IDE:
Как видно на сравнительном скриншоте, разницы в производительности почти нет. Она настолько незначительная, что можно сказать в пределах погрешности измерений. Так что хорошая новость, подобный контроллер практически никак не ограничивает быстродействие жёсткого диска. С этим разобрались, переходим к следующему диску.
Следующий диск тоже Seagate Barracuda 80 Гб, но уже с интерфейсом SATA, более современный:
Диск этот хоть и SATA, но тоже далеко не первой свежести. И тем не менее со SMART всё в порядке. Его вы видите на скриншоте ниже вместе с тестом производительности:
Третий диск, используемый мною для создания массива — Maxtor 80 Gb SATA:
SMART и тест быстродействия этого диска:
Четвёртого диска на 80 Гб у меня не было. Но для создания RAID массива совершенно не обязательно использовать диски одинакового объёма. Посему четвёртым диском был выбран Seagate Barracuda 160 Gb SATA:
SMART этого диска показывает 1 сбойный сектор. Появился он уже давно и новых не добавляется, так что всё в порядке. Хотя наработка внушительная — 47 тысяч 300 часов:
В завершение вступительной части покажу, как все эти 4 диска разместились в корпусе компьютера. Прямо перед ними расположен 120 мм вентилятор, продувающий всю «корзину» (между дисками есть расстояние). С охлаждением проблем нет:
Все четыре диска подключены к компьютеру, переходим к созданию RAID:
Создание RAID 0
Первым делом я переключил в BIOS режим работы SATA контроллера с AHCI на RAID. Выяснилось, что настройки встроенного в плату контроллера не такие уж богатые. В настройках можно выбрать размер блока Stripe Block, политику чтения Read Policy и политику записи Write Policy. И всё. Больше менять ничего нельзя. Впрочем, для моих целей и этих настроек вполне достаточно.
Конечно же все имеющиеся настройки могут влиять на скорость работы будущего RAID. Возник вопрос, какая комбинация настроек обеспечит максимальное быстродействие? К счастью настроек не так уж и много, я проверил их все. Начал с того, что выставил Stripe Block 64 КБ. Политику записи — Write Thru. При таком выборе, единственный доступный вариант политики чтения это NA. Я не буду вдаваться в описание значений всех этих параметров, всё это описано задолго до меня и при желании вы можете найти всё в интернете. Единственное, стоит отметить, что политика записи Write Thru по логике должна быть медленнее других. Поскольку при включении данной политики не используется кэш записи.
Производительность RAID 0 в этом режиме представлена на следующем скриншоте:
После, не меняя размер Stripe Block, я установил Read Policy как Read Cache, а Write Policy как Write Back. Эти параметры задействуют кэш, в теории увеличивая производительность. Минус политики Write Back в том, что при внезапном отключении электричества, с данными, которые не были записаны из кэша на носитель, произойдут алаверды. Они 
пропадут.
Производительность RAID 0 в режиме с описанными выше параметрами:
По результатам тестов получается, что разница в производительности между протестированными вариантами не такая уж большая. При смене политики на Write Back ощутимо увеличилась лишь случайная запись блоками по 4 КБ. Последовательное чтение, ровно как и случайное, в скорости не прибавило.
Следующая комбинация настроек для тестирования: Stripe Block 64 KB, политики Read Ahead, Write Back. Результаты на скриншоте:
Результаты не слишком отличаются от предыдущих. Для наглядности объединим их в один скриншот:
Думал я, думал, да и решил, что остановлюсь на варианте Read Policy: Read Ahead, Write Policy: Write Back. Осталось только определиться с размером блока Stripe Block. В настройках контроллера этот параметр можно устанавливать в следующих вариациях: 64 KB, 128 KB, 256 KB. В теории, меньший размер блока позволяет добиться большей производительности при работе с мелкими файлами. Больший размер, наоборот, должен повышать быстродействие при записи и чтении файлов большого объёма. Теория есть теория, но почему бы не проверить на практике? Хоть я изначально и склонялся к варианту в 256 KB, так как использовать RAID планировалось для больших файлов, всё же протестировал все три варианта.
Все дальнейшие тесты будут проводиться с включеными политиками Read Ahead и Write Back. Результаты с размером Stripe Block 64 KB нам уже известны. Тестируем Stripe Block 128 KB:
Разница не особа заметна. Случайная запись по 4 КБ немного снизилась, но вместе с тем немного увеличилась при глубине запросов равной 32. Немного возрасло последовательное чтение. Проверим, что получится, если выбрать Stripe Block 256 KB:
Получается, что относительно Stripe Block 128 KB, незначительно увеличилась скорость последовательного чтения. Случайное чтение по 512 КБ немного уменьшилось, зато возрасла скорость случайной записи по 512 КБ и очень сильно, аж на целых 10 МБ/с. Было 49 МБ/с, стало 59 МБ/с. Это уже что-то. Случайная запись по 4 КБ также заметно увеличилась. В остальном разница минимальна. Объединим результаты в один скриншот:
Мне больше всего понравились результаты с Stripe Block 256 KB. Но я решил убедиться и провести ещё два теста, выставив максимальные настройки в CrystalDiskMark: количество повторений 9, объём теста 4000 MB. Результаты Stripe Block 64 KB:
Тот же самый тест с Stripe Block 256 KB:
Проверять Stripe Block 128 KB я не стал, поскольку выбирал между 64 KB и 256 KB. Объединим результаты:
Полученные результаты окончательно сбили с толку. Где-то лучше Stripe Block 64 KB, где-то лучше 256 KB. Значительная разница в результатах наблюдается в случайной записи по 512 КБ. 34 МБ/с при Stripe Block 64 KB и целых 59 МБ/с при 256 KB. В конечном итоге я остановился на размере Stripe Block равным 256 KB. Ведь, как я уже писал, планируется работать с файлами большого объёма.
Так выглядит финальная версия RAID в настройках контроллера:
Общий объём массива в операционной системе — 294 ГБ. На этом скриншоте я уже успел наполнить RAID файлами:
Сравнение RAID 0, Single HDD, SSD
Под конец самое интересное. Сравним быстродействие получившегося RAID 0 с единичным жёстким диском, который у меня используется как основной и с твердотельным накопителем (SSD), на котором установлена операционная система.
Чувствуете запахло горелым? Это начинает подгорать у тех, кто слишком остро реагирует на скриншоты с плохим SMART. Вот, любуйтесь, это мой основной диск Hitachi на 2 ТБ для хранения данных, в программе Hard Disk Sentinel. Готовы? 3… 2… 1… 
Ignition:
Скриншот с вкладкой SMART в той же программе:
Да, этот диск во всю сыпется. У него была не лёгкая жизнь. Это внешний жёсткий диск, который использовался мной портативно на протяжение нескольких лет. Время наработки у него на тот момент, когда он посыпался, было менее тысячи часов. Сгубило диск то, что я его постоянно возил туда-суда. Но когда он посыпался, я его разобрал, извлёк из корпуса сам диск и по известной методике продлил ему срок службы.
Так этот диск выглядел, пока я его не разобрал:
Непосредственно жёсткий диск, извлечённый из корпуса:
Структура разделов на диске такова: 456 ГБ в начале диска не распределено, именно там находятся заросли бэдов и нестабильных секторов с низкой скоростью доступа. Остальная поверхность в отличном состоянии, там и расположился единственный раздел:
В самом начале отрезано немало пространства. Так я изолировал кучно лежащие бэды и нестабильные сектора. Конечно это существенно сказывается на производительности диска, ведь чем ближе к концу физического пространства, тем ниже скорость чтения/записи. Но это так, к слову.
Что ж, давайте сравним быстродействие RAID 0 из старых жёстких дисков с единичным диском, который уже давно сыпется и с вполне неплохим SSD на MLC чипах. Результаты на скриншоте. Слева RAID 0, по середине HDD Hitachi 2 TB и справа SSD Plextor 128 Gb:
По скорости лидирует SSD с большим отрывом. Было бы странно, будь оно иначе. Но посмотрите на RAID 0 в сравнении с единичным жёстким диском. Тут уже иная картина. RAID 0 показывает куда большие скорости и это при том, что состоит он из старых, можно даже сказать древних дисков, один из которых к тому же имеет интерфейс IDE.
К сожалению не всё так радужно, как хотелось бы. Скорость чтения/записи у жёсткого диска снижается по мере приближения к концу физического пространства. Не лишён этого недостатка и массив из нескольких дисков. На данный момент массив заполнен на 96%. Я решил прогнать тест ещё раз. При такой заполненности результаты совсем печальные:
Поскольку массив заполнен почти до отказа, тест выполнялся в конце физического пространства каждого диска (кроме диска на 160 Гб). Это не могло не сказаться на скорости чтения/записи. В таких условиях скорость RAID 0 уже не так разительно отличается от скорости единичного жёсткого диска.
Итоги
Прежде чем подводить итоги, я хочу дать вам послушать запуск четырёх старых дисков одновременно. Это прикольно звучит. Посмотрите небольшое видео, в нём вы также сможете услышать, как стрекочут все четыре диска при случайном чтении/записи:
Я не хочу перечислять минусы подобного RAID массива из старых дисков, они слишком очевидны. А вот немного о плюсах можно сказать. Во-первых, ощутимо повышается производительность, если конечно не забивать массив под завязку. Скорости старых жёстких объёмом 80 Гб крайне низкие по современным меркам. Создание RAID 0 позволяет дотянуть производительность до уровня современных жёстких дисков. Во-вторых, если использовать диски одинакового размера, то их ёмкости суммируются, это тоже плюс. Иметь в операционной системе четыре отдельных логических диска маленького размера неудобно. Объединив 4 диска на 80 Гб в RAID 0, получаем почти 300 ГБ сплошного дискового пространства. В-третьих, подобная манипуляция позволяет дать старым, забытым «жестянкам» новую жизнь.
Заметна ли разница в производительности невооружённым взглядом, без тестов? Да, заметна. Первое, на что я обратил внимание, что файлы быстрее копируются как в массив, так и из него. Также была замечена существенно возросшая производительности при работе в виртуальной машине. Разместив виртуальный жёсткий диск на RAID 0, я ощутил, как виртуалка «задышала». Загрузка гостевой операционной системы стала быстрее да и вообще отзывчивость виртуальной машины в целом улучшилась.
Предвосхищая будущие комментарии, не могу не сказать об опасности хранения важных данных на подобных массивах. Но ведь это же очевидно, не так ли? Вероятность того, что в любой момент что-нибудь пойдёт не так, слишком высока. RAID 0 сам по себе мягко говоря не блещет отказоустойчивостью. А если создавать его из старых дисков с огромной наработкой, то высоки шансы, что весь массив внезапно накроется медным тазом. Я использовал этот массив для того, чтобы рендерить на него видео. Даже если массив отвалится, то ничего страшного не произойдёт. Всё, что я потеряю, это отрендеренный файл, который можно рендерить снова. Но ничего подобного не произошло. Не скажу, что я долго пользовался этим массивом, но за всё время его работы не было замечено ни единого сбоя. Всё работало как часы.
На этом всё, спасибо за внимание!
Ну ты Отец)
не думал что sata диски с IDE в одном райде уживаются.))
Спасибо за информашку, у меня тоже скопились старые винты — все думал как-бы их с пользой.
Попробую ваш вариант. Спасибо.
Прекрасная и коротенькая статья описывающая работу RAID 0 на любых дисках! Как-то ночью искал самое простое описание рейда и как он будет работать и нашел эту нормальную статью. Чтоб использовать как шпаргалку очень часто докучают вечными вопросами «а почему так, а не этак» всё тут нормально описано. Единственное до чего пользователи не додумываются сами, что при RAID 0 максимальный объем это объем самого маленького диска умноженный на количество дисков. Некоторые RAID позволяют делать RAID 0 с нечетным количеством дисков, а други категорически нет. И насколько помню скорость записи просто складывается.