Компьютер будущего: массив накопителей

Небольшой экскурс в построение Raid-массивов для домашнего несерверного применения Часть первая: SSD на контроллерах, предназначенных для HDD. Кто кому мешает? (первые впечатления от «true hardware» контроллера) Содержание: О чем пойдет речь To Raid or not to Raid? Выбираем Raid-контроллеры Что и как будем тестировать Результаты тестов Подведение итогов первой части Что будет в продолжении О чем пойдет речь Нужен ли в домашнем компьютере дисковый массив? Наверное, можно обойтись и без него, и для подавляющей массы пользователей ПК такой вопрос даже не встает. Необходимость возникает, если ваш компьютер действительно нуждается в быстрой и надежной дисковой подсистеме, работая в сети или со сп...

Небольшой экскурс в построение Raid-массивов для домашнего несерверного применения

Часть первая: SSD на контроллерах, предназначенных для HDD. Кто кому мешает? (первые впечатления от «true hardware» контроллера)

Содержание:
О чем пойдет речь
To Raid or not to Raid?
Выбираем Raid-контроллеры
Что и как будем тестировать
Результаты тестов
Подведение итогов первой части
Что будет в продолжении

О чем пойдет речь

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

Технологии SSD бурно развиваются и, соответственно, переживают период «болезни роста», когда сырые технологические и инженерные решения, инновационно устанавливаемые на платформы, как минимум, не оптимальные для SSD, обрушиваются на головы простых пользователей, выступающих подопытными кроликами производителей. Но не подготовлены не только производители и пользователи оборудования, но и Microsoft, наша любимая ОС Windows пока по-прежнему пытается раскручивать шпиндель у SSD. Правда, Windows 7 дает робкие надежды на появление первой массовой ОС с «правильной» поддержкой SSD, но как будет на самом деле?

Поэтому, для темы «Компьютер будущего: здравствуй, SSD!» время еще не пришло, но появился практический материал по созданию массива SSD-накопителей. Построением различных видов массивов на нескольких аппаратных платформах и сравнению полученных результатов и посвящена эта статья. Впрочем, оказалось, что одной статьей в этом вопросе не ограничиться...

Некоторое время назад на сайте overclockers.ru Dentarq опубликовал интересную статью по созданию Raid-массивов, уделив много времени созданию массивов размером более 2GB, миграции и экспериментам по повреждениям-восстановлениям. К сожалению, с overclockers.ru автор статью уже убрал и вместе с ней переехал на cohardent, где эту статью и теперь можно обнаружить. Несмотря на наличие некоторых спорных суждений, статья, безусловно, представляет интерес, особенно, если упор делается на серверное применение. В некоторой степени нам будет проще, ибо избыточностью массивов заморачиваться не будем (разве что Raid1 создадим), да и в наличии нет дисков, чтобы на 4 порта набрать больше 2ТB.

To Raid or not to Raid?

Массив SSD, подключенный к контроллерам, рассчитанным на HDD, если рассматривать вопрос с точки быстродействия, а не с точки зрения повышения надежности, выглядит крайне нелепо. Ведь принцип увеличения производительности массива из HDD - это поочередная работа накопителей и попытка ослабить влияние невысокого быстродействия и инерционности механической системы путем размена на временные задержки электронных компонентов. Распараллеливание потоков данных в пределах одной высокоточной механической системы и долговременное поддержание стабильных параметров такой системы— задача дорогая и, в принципе, это тупиковый путь, поэтому и заметно стремление производителей HDD, по возможности, пересесть на меньшее число «блинов». В этом плане SSD выглядят гораздо более привлекательно, их среднее время произвольного доступа к данным в сотни и тысячи раз меньше, поэтому нет никакого смысла в распределении, условно говоря, одного IO канала на несколько поочередно активных накопителей, наоборот, надо создавать специализированный интерфейс для работы по принципу один накопитель — много каналов приема-передачи. Конечно, сегодня «один канал» может предоставить, к примеру, 16 линий PCIe, но само построение HDD контроллеров и существующие интерфейсы не является оптимальным для современных SSD. Что уж говорить о программных контроллерах, да еще и с PCIe x 1, которые толком даже пару приводов HDD SATAI обслужить не могут, тем более SATAII и SSD (пропускная способность одной линии PCIe соответствует пропускной способности интерфейса SATAII).

То, что raid-контроллеры не предоставляют полноценного сервиса для SSD, приводит и к тому,
что производители SSD сами оптимизируют свои накопители за счет создания внутреннего массива по оптимальной для конкретного изделия схеме. Сегодня такой подход видится единственно правильным. И не только в плане быстродействия, но и в плане стоимости, попробуйте набрать россыпью SSD-терабайт и добиться таких же результатов, как и решения от OCZ или Fusion-IO, выполненных в виде отдельного модуля расширения. Хотя, на мой взгляд, это все-таки обособленный класс устройств.

В связи с этим встает вопрос, а как же программные и «настоящие» Raid-контроллеры, толком не приспособленные к объединению к «параллельной» работе SSD, все же работают с ними, и, судя по множеству публикаций, показывают неплохие результаты?
Попробуем разобраться.

Выбираем Raid-контроллеры

В домашнем хозяйстве имелись, имея в виду возможность построения Raid-массива, материнские платы с чипсетами ICH9R, пара чипсетов от NVidia, ULI, внешняя PCIe x1 платка на Sil3132 и, на заброшенной i815E с сокетом 370, неожиданно обнаружился PCI SATAI контроллер на базе чипсета VIA VT6421A (и, к удивлению, на сайте VIA для него нашелся и свежий, датированный декабрем 2008 года, сертифицированный драйвер под Vista 64). Так как он поддерживал одновременно массив и на SATA, и на IDE, то был приобретен еще и переходник 2xCF->IDE, не покупать же еще и раритетные IDE HDD.

Установленный VIA VT6421A
К слову, пришлось разориться и на один диск WD5001AALS, поскольку в награду, как приз за одну из своих статей от сайта overclockers.ru, получил именно такой диск. Сам я, конечно, для себя его не купил бы, но вот пришлось по такому случаю приобретать второй в пару.

Таким образом, появился весьма средненький, но современный оппонент для пары SSD.

Контроллер VT6124A радовал недолго. Несмотря на успешное создание массивов в BIOS контроллера,

BIOS рапортует об успехе

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

Двухпортовый контроллер SATAII на Sil3132 для PCIe x1:

Ничего лишнего. Правда, и необходимого не доложили
Устройство предельно просто (и дешево — 15...25 долларов сейчас, но я покупал дороже) — в наличие контроллер SATA Sil3132, и, под цветным стикером, флэш-память 39VF010 128K x8 от SST, куда прошивается BIOS для работы в Raid или другой вариант BIOS, создающий два независимых порта SATA.
Одна линия PCIe худо-бедно сгодится для HDD, как же он справится с парой SSD?

Будем использовать и raid-контроллер ICH9R, любезно предоставленный материнской платой Asus Blitz Formula:

Установлены шесть накопителей SATA - предел для чипсета P35
Хотя многие тесты делались и на чипсетах Nvidia и Uli, они не приводятся, так как различаются и аппаратные платформы, и ОС. Впрочем, по всем аппаратным платформам проведены экспресс тесты в Windows7 beta build 7000, но смысла пока нет приводить результаты, надо дождаться, по крайней мере, Windows7 RC.

Пора подумать о «настоящем» raid-контроллере. Его также придется приобретать, так как до этого момента нужды в нем не было.

С одной стороны, понимая, что типичные Raid – массивы, без применения режимов резервирования накопителей, попытаются применить к SSD ничего не дающую технику чередования доступа к каналам IO, хотелось взять что-нибудь подешевле. Даже было намерение взять «почти настоящие» HighPoint 2300 (4 порта, PCIe x1) или 2310(4 порта, PCIe x4), без встроенного кэша. Но противоречивые отзывы и скорость, уступающая Intel Matrix (по крайней мере, у 2300), не вдохновили на покупку. Цена контроллеров — примерно, как и у мобо P5Q-EM с ICH9R, и, хотя с контроллерами идут еще и специальные утилиты, экономические предпосылки для покупки в домашний компьютер таких устройств весьма сомнительны. Предыдущее поколение контроллеров серии 1ххх от HighPoint даже не рассматривалось, оставим старичков в покое. Равно как и новое поколение серии 4ххх — они пока начинаются только от 8-ми портов и цена соответствующая.
С другой стороны, самыми дешевыми «true hardware» решениями являются двухпортовые изделия, имеющиеся в арсенале многих известных производителей (Areca, 3Ware, Adaptec и др.), но они имеют интерфейс PCIe x1, в который может упереться прирост производительности, и, кроме того, зачастую и страйп ограничен на уровне 128К. А ввиду того, что контроллер, скорее всего, после окончания экспериментов, отойдет под обычный HDD-массив, так как стоимость гигабайта HDD в десятки раз ниже, то нет никакого смысла рассматривать двухпортовые контроллеры.

Круг сузился. Кандидаты — 3Ware 9650SE 4LP, есть парочка вариантов от LSI, и HighPoint 3510, это из того, что было в наличии. Победил HighPoint 3510, и в немалой степени потому, что в статье «Компьютер будущего: прощай, HDD!» я давал ссылку на тестирование 4-х SSD OCZ, аналогичных моим Silicon Power, которое делалось на базе контроллера HighPoint 3520. А это одно и тоже, только у HighPoint 3510 отсутствует второй разъем для хвоста на 4 дополнительных SATA привода, и не распаяно несколько SMD-элементов.
Соответственно, купив HighPoint 3510, получаем (за ~ 400 долларов) контроллер уже младшего, но серьезного enterprise-решения, оснащенного 800 МГц IO процессором 81341 от Intel, с набортной памятью 256MB DDR2 667 ECC (Qimonda), поддержкой BBU и всего спектра полноценного бизнес- администрирования, включая удаленное конфигурирование и уведомление по e-mail. Кроме того, в отличие от 8-и портового 3520, на коробке 4-х портового 3510 красуется надпись на английском «Самый быстрый в мире 4-х портовый raid-контроллер». Это было правдой почти два года назад, когда эти контроллеры появились в продаже, но сейчас уже есть и 2-х ядерный IO процессор Intel с частотой 1.2ГГц, устанавливаемый в более современные и дорогие решения.

Коробка с надписью о том, что вам достался быстрейший в мире 4-хпортовый контроллер
Интерфейс контроллера PCIe x8. Забегая вперед, отметим, что в разъеме с типоразмером PCIe x16 и одной подключенной линией PCIe контроллер не работает (в BIOS-е все настраивается, массивы создаются, но дальше они не инициализируются и система их не видит). 4 линии подавать не пробовал, с 8-ю линиями, естественно, все нормально.

Вид на радиатор процессора ввода-вывода
На фронтальной стороне платы, под радиатором, скрывается процессор ввода-вывода (он сделан на базе ARM XScale), имеющий шестнадцать программируемых линий IO, килобайт статической памяти, два UART 16550 и еще много чего интересного. Кстати, число выводов процессора — 1357.
HighPoint не стала применять парный к процессору Intel 81341, «родной» SATA-контроллер производства Intel, установив микросхему 88SX6041 от Marvell (на фото справа от процессора). Буфер контроллера — 256МБ, используются пять (так как ECC) микросхем памяти Qimonda HYB18TS512160BF-3S, две на фронтальной и три на тыловой стороне. Intel 81341 поддерживает до 4ГБ памяти.

Оборотная сторона HighPoint 3510

Тыльная сторона обильно усеяна элементной мелочевкой, из «крупного», помимо оперативной памяти, можно отметить в нижнем левом углу (по фото) микроконтроллер NXP LPC921F (на базе неувядающего 80С51, который любят встраивать в «свои» микроконтроллеры многие производители различных микросхем — практически на каждой мобо, если хорошенько покопаться, его, встроенного внутрь другого чипа, можно найти ). Микросхема, которая выглядит посолидней и чуть выше микроконтроллера — банальный 244-й буфер. Правее него, со стикером, судя по 48-выводному корпусу TSOP-1, скорее всего, флэш-память с BIOS. Так как устройство не дешевое и на гарантии, то пока наклейки не будем трогать.

В комплект входит также руководство, CD и кабель-разветвитель на 4 SATA разъема. Кабель длинный, метровый, рассчитанный на пространство серверных башень - в небольших корпусах его придется сворачивать в кольцо.

Прошивка BIOS была старой, одной из первых, еще без опции выбора размера страйпа.
Обновление делалось утилитой из-под Windows Vista 64, как обычно, быстро и без проблем. Также, если создаваемый массив не загрузочный для данной машины, удобнее работать с контроллером через WEB-менеджер, предоставляющий больше возможностей, чем через BIOS, что для данного класса продуктов вполне естественно. Утилита работает гораздо расторопнее WEB-менеджера от Intel для ICH9R.

Кстати, последнее обновление - одинаковое как для 3510, так и 3520, таким образом, судя по BIOS и репортам ОС, после прошивки я получил в своей системе HighPoint 3520. Это подтверждает предположение, что отличие между ними только в отсутствии второго мини-SAS разъема и нескольких пассивных элементов, большей частью блокировочных емкостей. При случае есть возможность превратить этот контроллер в полноценный 8-и портовый HighPoint 3520.

HighPoint 3510 превратился в 3520
В процессе работы максимальная температура поверхности радиатора, по данным ИК-термометра, составляла 58°С.

Что, как и чем будем тестировать

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

SSD будут представлять два MLC накопителя емкостью 32GB от Silicon Power, описанных более подробно в статье «Компьютер будущего: прощай, HDD!» (так пока и не разжился большим числом SSD).
HDD будут представлять пятисотки WD5001AALS.

Полигон — платформа на базе материнской платы Asus Blitz Formula (чипсет P35), процессор E6750 (2.66ГГц), 8GB RAM DDR2 800, ОС Windows Vista Home Basic 64 SP1, установленная на встроенный Intel Matrix Raid0 2x320GB Hitachi HDT725032VLA360, полностью установлены все обновления. Также, на отдельном 320GB Hitachi HDT725032VLA360 установлена W7 64 (build 7000), для проверки поведения SSD на этой системе.

В предыдущих материалах не раз было упомянуто, что эра 32-х битных систем для автора закончена, за исключением поддержки старого софта и оборудования, которое не совместимо с новыми ОС. Тем более Windows XP имеет неразвитую систему кэширования и она менее приспособлена для проводимых экспериментов. Для примера, IO в Висте уже не проводится блоками 64КВ, верхнего ограничения нет, типичным можно считать блок в 1МВ. Именно с такими блоками, кстати, работает и своппинг в Висте по упреждающей записи и чтению.

Вспомогательная платформа — Asus M3N78-EM, X2 4850e (2.5ГГц), 8GB RAM DDR2 800, OC W7 64 (build 7000), установленная на 320GB Hitachi HDT725032VLA360.

Дискретные контроллеры — программный, на базе Sil3132, и «настоящий», HighPoint Rocket Raid 3510LF, оба с последними прошивками и ПО для работы в среде Windows Vista 64.

Более конкретный план — проверить, как соотносится производительность одиночного SSD, и работа пары SSD в режимах JBOD, Raid0 (с разным страйпом) и Raid1, с точки зрения физического накопителя и с точки зрения операций ввода-вывода в файловой системе и, в целом, с точки зрения операционной системы (Vista 64 и W7 64), в том числе и влияние размера кластера).

Для этого воспользуемся программным обеспечением в виде встроенных в ОС средств внутреннего мониторинга, программой IOmeter версии 2008-06-22 RС2 для 64-битных систем, бенчмарками HD Tune Pro 3.50.

В качестве быстродействующего индикатора работы «верхнего уровня» дисковой подсистемы будет использоваться CrystalDiskMark22-x64.

В некоторых случаях будут привлекаться и другие программные средства (Lavalys Everest, утилиты Microsoft TechNet и т.д.).

Такое обилие разнообразных программ вызвано тем, что ни одна программа не дает всю полноту необходимой нам информации, к тому же, желательно провести тесты за разумное время. К примеру, мой batch-файл тестов IOmeter содержит шесть десятков тестов, каждый из которых исполняется 10 минут. Вариантов конфигураций могут быть сотни. Итоговое время — несколько месяцев непрерывных тестов, что неприемлемо.

Кроме того, SSD обладают одной неприятной особенностью, имеется в виду необходимость принудительного стирания блоков ячеек, в которые до этого записывалась какая-нибудь информация. Поэтому, в отличие от HDD, где такой проблемы нет, форматирование или удаление раздела накопителя не устраняет необходимость предварительного стирания. Конечно, оно делается в фоне, встроенным в SSD контроллером, но даже 2-х минутный тест записи блоков 512МБ в IOmeter (для проверки, как происходит запись объемом, выше чем встроенный 256МБ кэш контроллера HighPoint 3510) записывает около 5GB на накопитель. Физическое стирание такого объема может растянуться на несколько минут, а если записано больше? И свободное пространство для внутренней работы SSD-контроллера ограничено? Это может привести к неодинаковым стартовым условиям тестов и исказить результат бенчмарков. Насколько эти опасения обоснованы, сказать сложно. Один из путей решения проблемы- после каждого теста с записью на накопитель давать 10 минут на передышку, оставляя SSD под напряжением, чтобы место, занимаемое файлами, удаленными приложениями и ОС, было действительно очищено контроллером SSD. Но тогда тесты не закончатся и за год. Поэтому, будем считать, что такой проблемы нет, имея в виду, что она может проявляться.

В итоге сокращено и время тестов (каждый тест в IOmeter длится 2 минуты), и, вместо автоматического последовательного инкрементного снятия данных со всех вариантов исходных данных, проводился экспресс-анализ бенчмарков для обнаружения тенденций движения параметров, с тем, чтобы не проводить измерения параметров там, где результаты вполне получаются интерполированием.

Результаты тестов

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

Сначала рассмотрим, что дает для Raid0 на SSD изменение размера страйпа, на аппаратном контроллере, который допускает создание 1МВ страйпов. Если задуматься, что дает страйповая сегментация SSD, то, помимо ненужных обращений к накопителям и бестолковому прерыванию их работы, возможно, при записи, проявляется и полезная сторона — простаивающий SSD даст возможность своему внутреннему контроллеру спокойнее произвести физическое стирание логически удаленных блоков данных.

Пройдясь по всей гамме страйпов, попутно форматируя с размером кластера от 512B до 64КВ, оптимальным вариантом, с точки зрения быстродействия, признан страйп 256КВ. Второе место занял страйп 128КВ. Логично предположить, что самый лучший результат на запись мелких файлов даст наибольший страйп, в то же время он снизит результат на больших блоках. Так оно и оказалось, страйп 1МВ победил на мелких, но проиграл на крупных, хотя выигрыш или отставание в некоторых максимумах всего до 10-15%. Что касается форматирования, то наилучшие результаты всегда достигались при 64КВ. Это, правда, неоптимально с точки зрения ресурса SSD, да и разница, к примеру, с 4КВ не превышает 10%, тем не менее, для тестов SSD выбран вариант форматирования с 64KB и страйпом 256КВ. HDD форматировались 4КВ и страйпом 64КВ.

Теперь разберем поведение одиночных накопителей и массивов Raid0 и Raid1, для SSD и HDD, на базе контроллера Intel ICH9R и HighPoint Rocket Raid 3510LF (далее по тексту — HPT).

Шесть линий, уходящих вверх за пределы графика — это итог взаимодействия кэша ОС с кэшем HPT. Если размер блока данных не превышает некоторой величины от размера входного буфера, то, независимо от числа, вида и способа организации накопителей, обеспечиваются предельные скорости чтения — около 1.3GBps при линейном, около 1.2GBps при случайном чтении файлов размером 512КВ, и около 40MBps при произвольном чтении файлов размером 4КВ.

Вот как выглядит буферизованное файловое чтение в HD Tune Pro, верхняя отметка на шкале 1500MB, так как программа отображает только три последних значащих цифры. Ситуация не меняется (вернее, становится несущественно лучше) и при задании File length = 32MB, а дальше, по мере нехватки кэша HPT, результаты уже ухудшаются. Еще раз подчеркну, что это данные будут аналогичны и для HDD, и для массивов.
Кэш контроллера и ОС делают свое дело. Если кэш контроллера выключить по записи, то получается намного более грустная картина:

Впрочем, этого отключения наверняка не делается для домашних компьютеров, да и для серверов — приобретается блок BBU с резервным аккумулятором и схемой управления. Так что, попытки некоторых производителей различных «улучшайзеров» противопоставить свои изобретения, которые сами проводят и кэширование и преобразования в оперативной памяти, «голым» накопителями, неуместны. А такие сравнения приводятся сплошь и рядом. Маркетинг, однако.

File length = 512MB дает следующую картину:

Кроме того, где-то на полпути роста размера блока, на HDD и SSD, в рейдах и без, проявляется вот такой эффект:

То есть, это особенность HighPoint 3510, когда она начинает сказываться и когда заканчивается, нужно определять путем мегабайтного инкремента размера файлов в IОmeter.

SSD на ICH9R

Скорость линейного чтения не зависит от размера блока данных (вероятно, в пределах размера кэширования ОС, для чего используется вся доступная память, не используемая для более приоритетных задач) и находится на типовом для нашего SSD уровне, немногим выше 140MBps.

Интересно видеть, что нет разницы между Raid0 и Raid1. Производительность в этих режимах не зависит от размера блока данных и ровно в два раза превышает производительность одиночного диска.

SSD на HPT

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

WD на ICH9R

В отличие от ICH9R + SSD, одиночный диск и Raid1демонстрируют практически одинаковые результаты, что выглядит более логичным. Встроенный буфер 32MB у HDD оказывает поддержку, дающую прирост 40-50%, при сопоставимых по объему данных, постепенно его эффективность падает, в итоге мы получаем линейное чтение на уровне около 90MBps.

Однако на Raid0 не обошлось без аномалий — при размере блока 50MB производительность более, чем втрое превышает пропускную способность одиночного диска. Вероятно, удвоенный суммарный кэш HDD дает такие преимущества. При неэффективном кэшировании у Raid0 остается только двойное преимущество над одиночным диском.

WD на HPT

Одиночный диск и пара в Raid1 показывают идентичные результаты, существенно превосходящие те, что мы видели на ICH9R. Более того, за счет внутренней связки кэш HPT + кэш HDD, до тех пор, пока эта связка эффективна, в Raid0 HDD обходит SSD.

Локальный итог

Raid0 на HDD и на ICH9R, и на HPT, при линейном чтении, когда эффективно работает кэш самого HDD и кэш HPT, и с учетом поддержки ОC, показывает лучшие результаты, чем SSD, изначально в полтора раза более быстрый. Неплохое начало для HDD. Переходим к случайному чтению.

SSD на ICH9R

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

SSD на HPT

Спад производительности, по сравнению с линейным чтением, гораздо более резкий у Raid0, а вот у одиночного и Raid1 эффективность случайного чтения превышает эффективность линейного, вплоть до размеров блока 500MB! Поэтому, при снижении эффективности кэширования производительность Raid0 превосходит Raid1 только на 50%. Более того, при значительном превышении размера блока 100MB, уже оба HPT- рейда начинают проигрывать аналогичным режимам ICH9R. Фактически, в этом случае кэш HPT уже никаких полезных функций не выполняет, и фрагментированная запись в него с последующей перезаписью в SSD сводит на нет все преимущества.

Необходимо будет проверить, с помощью IOmeter, как дальше себя ведут эти треды.

WD на ICH9R

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

WD на HPT

Темпы падения такие же, как и при линейном чтении, но глубина — в два раза хуже. Практически, при размере блока выше 100MB, производительность очень быстро стремится к производительности одиночного диска, и при блоках 500MB все графики сливаются в один и одинаковы с результатами ICH9R и одиночного диска.

Локальный итог

HPT+SSD полностью переигрывают HDD. Но, в состязании контроллеров, на больших размерах блоков ICH9R начинает обыгрывать HPT. По-прежнему удивляет инвариантность ICH9R+SSD к размеру блока.
Посмотрим, что изменится при чтении мелких файлов.

SSD на ICH9R

И опять здесь чтение не зависит от размера блока данных. Интересно видеть, что одиночный SSD немного выигрывает у Raid0 и Raid1.

SSD на HPT

В чтении мелких файлов производительность не зависит от числа накопителей и вида Raid — все графики слились в один. Причем на крупных блоках заметен небольшой, но проигрыш всем вариантам ICH9R+SSD.
WD на ICH9R

Известно, что обычные HDD не сильны в этой номинации. Одиночный HDD показывает буферизованное чтение на уровне 1.4-0.95-0.7 MBps для блоков 50-100-500MB, опережая Raid1, который демонстрирует 1.2-0.92-0.7 MBps. Raid0 существенно вырывается вперед, его результаты 6.7-1.3-0.8 MBps.

WD на HPT

HPT, как и в случае с SSD, не позволяет увидеть разницу между числом и способом подключения накопителей. При эффективной работе кэшей разница с ICH9R впечатляет семикратным превосходством даже одиночного HDD над Raid0 на ICH9R, а над одиночным — в тридцать раз. Впрочем, идиллия длится недолго — увеличение блока данных быстро уравнивает производительность любых сочетаний и режимов HDD.

Локальный итог

HPT существенно выигрывает у ICH9R при относительно небольшом размере блока, при его росте преимущество быстро сходит на нет и наблюдается примерный паритет.
Связка ICH9R+SSD верна себе и по-прежнему не показывает зависимости от размера блока.

Переходим к записи.

Общий комментарий

Наконец-то мы видим классическое распределение - все графики с Raid0 полностью разместились в верхнем сегменте производительности, остальные режимы — в нижнем. Впрочем, без аномалий опять не обошлось. И, в отличие от остальных графиков, вертикальная шкала начинается не от нуля, так как хотелось иметь максимальное разрешение по вертикали, слишком уж плотно сбились в кучу графики в районе 90 MBps.

SSD на ICH9R

И запись не зависит от размера блока данных. Одиночный SSD и Raid1 показывают идентичные результаты на уровне 90 MBps, Raid0 — в два раза выше.

SSD на HPT

Результат — полностью аналогичен показанному на ICH9R. Сразу вспоминается фраза «Если нет разницы, зачем платить больше?», хотя этот тест, конечно, не может быть критерием равенства производительности HPT и ICH9R.

WD на ICH9R

Интересно, что одиночный HDD существенно быстрее Raid1, хотя преимущество постепенно тает, также впервые наблюдается разнонаправленный градиент — у одиночного производительность все время падает, у Raid1- растет. Также, с ростом размера блока, растет и производительность Raid0. Непонятно, что сдерживает производительность Raid0 на относительно небольших блоках данных. Поскольку примерно аналогично HDD проявляет себя и на HPT, вероятно это особенность самого HDD.

WD на HPT

Также, как и на ICH9R, одиночный HDD быстрее Raid1, правда, характер изменений у них одинаковый — оба падают с ростом размера блока. Что интересно, при малых размерах блока Raid0 показывает результат, почти равный одиночному HDD, впрочем, с ростом блока, статус-кво быстро восстанавливается и результат Raid0 уходит за 200 MBps, опережая Raid0 на SSD.

Локальный итог

И на линейной записи HDD составляют серьезную конкуренцию SSD, выигрывая многие локальные сравнения.
Впрочем, аномалии и нелинейности требуют проверки на IOmeter.
Связка ICH9R+SSD, как обычно, не показывает зависимость производительности от размера блока.

Переходим к случайной записи.

SSD на ICH9R

По сравнению с линейной записью существенных изменений нет.

SSD на HPT

Кэш работает превосходно, когда он работает. Непонятно только, почему он проявляет себя так здорово при случайной записи крупный файлов и не проявляется при линейной записи. Уж слишком большое превосходство в данном случае, также очевидно безоговорочное лидерство в состязании с ICH9R+SSD.

WD на ICH9R

Классический вид, прокомментировать можно только заметное снижение производительности с ростом размера блока, однако, по сравнению со чтением, запись показывает результаты, более, чем в два раза лучше.

WD на HPT

Также классический вид, превосходные результаты, лучше, чем при линейной записи, а на начальном этапе лучше, чем у HPT+SSD. Даже на больших размерах блока HPT существенно опережает ICH9R.

Локальный итог

Аномалия такого отрыва случайной записи в лучшую сторону, причем и на HPT, и на ICH9R, от произвольной, впечатляет, и пока остается без внятного объяснения.
Осталось посмотреть на реальный стресс для систем хранения данных, произвольную запись файлов размером 4КВ.

SSD на ICH9R

По графикам видно некоторое превышение производительности Raid0 над одиночным накопителем и Raid1. В цифрах это будет 2.4-2.4-2.4 MBps для блоков 50-100-500MB, против 2.1-2.1-1.9 MBps.

SSD на HPT

Кэш опять работает превосходно, принося пятикратное преимущество для одиночного накопителя и 7-8 кратное для Raid0 над ICH9R. С ростом блока преимущество одиночного накопителя и Raid1 постепенно исчезает, а Raid0 сохраняет в два раза лучшую производительность.

WD на ICH9R

Одиночный HDD показывает буферизованную запись на уровне 2.4-2.3-1.7 MBps, на удивление, серьезно опережая Raid1, который демонстрирует 1.8-1.6-1.6 MBps. Raid0 существенно вырывается вперед при любых размерах блока, его результаты 4.5-3.6-3.0 MBps.

WD на HPT

В этой номинации связке кэша HDD и кэша HPT нет равных. Впрочем, не будем хвалить только кэш HPT, забывая, что им руководит процессор ввода-вывода от Intel. Тем не менее, на графике пришлось обрезать рекордный результат Raid0 HPT+WD, который, для блоков 50MB, составляет величину более 31 MBps. Сложную динамику в зависимости от размера блока придется уточнять.

Одиночный HDD и Raid1 также сначала показывают результаты, превышающие их показатели на HPT.

Локальный итог

Вообщем, слабенький SSD и средненький HDD победили друг друга. В целом, конечно, Raid0 HPT+SSD выглядит предпочтительней, если не нужна пиковая производительность именно на небольших блоках.

Пара слов о контроллере Silicon Image Sil3132

Во все вышеприведенные графики этот контроллер не попал по тем причинам, что производительности PCIe с одной линией не хватает для организации массива из двух современных накопителей. Для примера, вот бенчмарк Raid0 на базе двух WD5001AALS:

Хорошо видно, что производительность обрезается на уровне 140MBps, хотя для Intel Matrix Raid0 начинаться график будет с отметки выше 180MBps. То же будет касаться и записи.

А если массив на Sil3132 сделать загрузочным, то загибаться он начнет с самого начала. Правда, это зафиксировано на более слабой системе и под Windows 7 build 7000, но это мало что меняет.

Поэтому, этот контроллер наиболее целесообразно использовать, прошив BIOS для нерейдовой работы, получив независимые дополнительные порты SATAII.
К примеру, на Asus Blitz Formula имеется шесть портов SATA, которые могут быть использованы для организации массивов накопителей. Если имеется SATA привод BD/DVD/CD, то его подключать будет некуда и контроллер на базе Sil3132 может пригодиться.

Как Raid-контроллер по полной программе он сможет использоваться для достаточно старых дисков (трех-четырехлетнего возраста), либо если есть реальная необходимость организации массива Raid1.

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

Подведение итогов первой части

Бенчмарки на скорую руку показали несколько неожиданных (по крайней мере, для автора) результатов.

Во-первых, реально порадовала производительность Intel ICH9R. Нужно хотеть от дисковой системы очень много, чтобы появились стимулы для приобретения дорогостоящего аппаратного контроллера. В принципе, ICH9R должна обеспечить почти полноценную работу Raid0 из шести SSD-накопителей, обеспечивающих типичные для SSD-контроллера JMF602 скорости передачи.
Четверке SSD типа OCZ Vertex этого по чтению уже не хватит, хотя и того что останется, весьма немало по сегодняшним меркам.

Очевидно, что ICH9R использует свой алгоритм по разному для HDD и SSD, даже возникает чувство, что ICH9R умеет определять наличие SSD в системе.

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

В третьих, пока за кадром остались несколько вопросов, например, как контроллеры используют выделенную память. То есть, делится ли набортная память 256MB статически между каналами IO или она динамически перераспределяется процессором ввода-вывода в зависимости от числа накопителей или текущей нагрузки. Пока создается впечатление, что эта память изначально и навсегда поделена поровну на 8 PCIe линий.
Ну и, наконец, все-таки следует признать, что пока контроллеры общего назначения не рассчитаны на SSD, тем более на их новые модели, режим Raid0 с выбором страйпа для них — это анахронизм. Не случайно Fusion-IO пошла по своему пути, реализовав внутренний рейд и в своих SSD Duo показывает наилучшие для отрасли результаты быстродействия. Многие производители SSD с интерфейсом SATA также организуют внутренний Raid0, убирая логику контроллеров, не умеющих по-настоящему работать с SSD.

Высказывания вроде того, что HDD хуже по надежности, чем SSD, поэтому избыточные массивы с использованием SSD не нужны, на мой взгляд некорректны. В теории это так, но нас интересует практическая сторона дела. Заявленные MTBF сопоставимы, но, в отличие от SSD, по HDD наработан колоссальный производственный и эксплуатационный опыт, есть масса статистической информации, и мероприятия по предотвращению потерь информации можно эффективно планировать и претворять в жизнь. Массивам на SSD до этого еще надо дожить, и по первым шагам видно, что путь их не такой уж прямой и гладкий. Но и нет сомнений в том, что со временем они полностью вытеснят своих механических собратьев из наших компьютеров.

Время инициализации BIOS, сканирования портов и инициализации накопителей у HighPoint 3510 составляет около 10 секунд, ICH9R управляется за 3-4 секунды. Упомянутой во вступлении карте на чипсете VIA 6421А требовалось до 40 секунд.

Можно упомянуть и о том, что, если режимом работы накопителей в BIOS материнской платы выбран Raid, то совместная работа с контроллером Sil3132 (с Raid-BIOS) становится невозможна. После перезагрузки Intel Matrix Raid становится недоступным в BIOS и ОС его не видит.
Если режим - AHCI или SATA, то проблем не возникает. Совместно с контроллером HighPoint 3510 Intel Matrix Raid работает корректно. Создается впечатление, что система не позволяет создавать два программных рейда одновременно.

Корпуса из алюминиевого сплава использованных SSD на открытом воздухе (не установленные и не прикрученные к корзине) нельзя назвать холодными - они прогреваются до 37°С, в то же время, также без установки, WD5001AALS прогреваются до 57°С, при окружающей температуре 24°С.

Что будет в продолжении

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

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

Также попробуем взглянуть на проблему одновременного старта дисковых накопителей. На Blitz Formula (чипсет P35) старт не одновременный (8-10 секунд), как и положено. И еще есть ряд моментов, требующих нашего внимания.

Например, как влияют изменения частот процессоров, шины PCIe, НT, оперативной памяти на производительность дисковой подсистемы и рассмотрим вопросы оптимизации.

Памятуя о статье "Прощай, HDD!" и схватке MFT+SSD vs SSD, устроим очную схватку между массивами HDD и SSD, с участием аппаратного контроллера и без него.

Все это планируется осветить во второй части.

Также собирается материал по настройке и оптимизации работы SSD в среде ОС Windows, особенно интересно, что нового и как это новое проявляется в W7. Тут интересен даже не сам массив, а подключение одиночного диска и новая система кэширования и управления накопителями. На первый взгляд, быстродействие SSD в W7 возросло, но надо дождаться RC.

Хочется, чтобы итоговый вывод не диссонировал с планируемым названием этой статьи «Компьютер будущего: здравствуй, SSD!».

Высказаться по существу вопроса можно тут .

Специально для www.overclockers.ru,
zauropod аkа Zaurozavr, 31 марта 2009 года

Перейти к полной версии

Компьютер будущего: массив накопителей

Лента материалов