Модельный ряд RAID контроллеров Adaptec

Информация любезно предоставлена компанией Adaptec by PMC (Россия).

Классификация контроллеров Adaptec.

Поколение	Опция “E” - серверы начального уровня	Базовые опции - серверы «mainstream»	Опция “Q”. Серверы верхнего уровня
6-ое поколение	6450E/6805E	6405, 6805, 6805T, 6445	-*
7-ое поколение	71605E	78165, 72405, 71685, 71605, 7805	7905Q, 71605Q
8-ое поколение	-	8405, 8805, 8885	8885Q, 81605ZQ

Читать дальше ...

Производительность LSI MegaRAID 9361 с SSD

После обновлений микрокода эти контроллеры сильно прибавили шустрости:

Access	Random	RAID	Ctrl cache	Queue size	IOps	avg io time (ms)	max io time (ms)
100% read	100%	RAID0	off	1024	290000	0.77	7.5
67% read	100%	RAID0	off	1024	195000	5.3	23
67% read	100%	RAID0	off	256	195000	1.3	16
67% read	100%	RAID0	off	128	190000	0.67	16
0% read	100%	RAID0	off	128	96000	1.4	100
67% read	100%	RAID0	on	1024	69000	14.6	21
100% read	100%	RAID10	off	1024	290000	0.63	6.5
67% read	100%	RAID10	off	1024	122000	8.3	84
67% read	100%	RAID10	off	256	125000	2.05	20
67% read	100%	RAID10	off	128	120000	1.07	18
67% read	100%	RAID10	on	256	56500	4.5	15
0% read	100%	RAID10	off	128	48000	2.66	18.5
67% read	100%	RAID5	off	128	82000	1.56	26
67% read	100%	RAID5	on	128	35000	3.7	16
0% read	100%	RAID5	on	128	12500	9.8	100
0% read	100%	RAID5	off	128	33000	3.9	25
0% read	0%	RAID1	off	1	11657	0.085
0% read	0%	RAID1	on	1	17220	0.057
0% read	0%	RAID10	on	1	17200	0.057
0% read	0%	RAID10	off	1	11700	0.085

Тестировался контроллер LSI MegaRAID 9361-8i (FW 24.7.0-0026), 6шт SSD Seagate 1200 800GB, подключены через 6G экспандер. Strip 256k, тестовые запросы IOmeter'a по 4к.

Краткая выжимка:
- максимальная производительность на чтении (RAID0) - 290k IOps, на записи - 96k IOps;
- включение кэша контроллера проваливает производительность в 2-3 раза;
- RAID10 практически равен RAID0 на чтении и вдвое медленнее на записи (все по канонам);
- RAID5 в среднем медленнее RAID10 в 1,5-2 раза.
 

Публикуется по результатам теста Максима Мухина.

Читать дальше ...

IBM Flash System - система хранения данных на флэш памяти.

Решение на Flash System 820 уместилось в 2 шкафа против 630 шкафов стандартных массивов.Чтобы заменить 630 шкафов на 2-а шкафа нужно плотность решения увеличить в 300 раз без потери производительности и емкости. Это действительно очень хороший показатель.                                                                                                                              Центр компетенции, Тринити

Как Вы наверно знаете, еще 11 апреля 2013 компания IBM представила свою новую продуктовую линейку в портфеле решений систем хранения данных - IBM Flash System. Почему в блоге о них только сейчас?

Они приехали. Можно тестировать. Тестировать в вашей инфраструктуре.


C чего все начиналось? Естественно с покупки передовых решений :) Вот ССЫЛКА на предысторию.

Итак, что же IBM вывел на рынок и кому это надо?

IBM Flash System - линейка систем хранения, использующая только Flash память в качестве носителя информации. В отличии от традиционных систем хранения, IBM Flash System специально спроектированы под данный тип памяти, что дает высочайшую производительность и больший КПД при использовании этого подхода к хранению.

Читать дальше ...

Еще немного новостей от IBM

Анонсирована прошивка ветки 7.84 для систем IBM DS3500/DSC3700. Вместе с новой прошивкой пришли и новые возможности. Начнем с новых ключей активации (программных опций в новом микрокоде):

• Disaster Recovery Option – ключ дает возможность использовать не только привычное зеркалирование по FC, но и асинхронную репликацию по FC/iSCSI. Для DS3500/DCS3700 поддерживается до 16ти зеркальных пар по FC (ERM) и до 32 пар для асинхронных реплик. Для DCS3700+ (DSC3700 performance module) поддерживается 16 пар ERM и 128 асинхронных пар. Асинхронная репликация работает на базе PiT копий, что дает возможность задавать требуемое значение RPO. Это действительно большой шаг вперед – репликации по IP (без использования FC-IP гейтов) давно не хватало!
• Backup and Restore Option – ключ, включающий максимум доступных “современных” снапшотов (512 для DS3500/DCS3700 и 2048 для DSC3700+). Ключ заменяет комбинацию Enhanced FlashCopy Base + Enhanced FlashCopy Upgrade. Я бы, если честно, рекомендовал бы сразу приобретать комбинацию из Enhanced FlashCopy и VolumeCopy – это может быть полезнее.
• Performance Read Cache - еще одно мега-обновление, которое давно обещали. Это кэширование на SSD, да-да, теперь на системах DS3500/DCS3700 можно использовать SSD не только для хранения “быстрых” томов, но и для увеличения объема кэша. Так как SSD используется только на чтение, то нет никакой нужды делать из них отказоустойчивый массив. Насколько я успел почитать, работа системы с SSD в таком режиме мало чем отличается от работы с кэш-памятью, т.е. нет никаких супер-сложных алгоритмов по анализу нагрузки, а также нет и фоновой миграции данных на SSD. Разумеется, кэширование на SSD работает не всегда – если приложение пишет большие объемы данных или последовательно читает большие объемы, то эффект будет близкий к нулю. Однако для виртуализации (особенно VDI), Exchange, Web, СУБД эффект уже может быть весьма заметным. Можно начать с одной SSD и добавлять по мере необходимости. Кэширование осуществляется “централизованно”, т.е. кэшироваться будут различные тома в различных пулах. Для каждого конкретного луна можно принудительно отключить использование SSD.
• Super Key – ключ полностью соответствует названию :) и включает в себя все вышеописанные возможности. Т.е. если хочется “полный фарш”, то это как раз нужная опция!

Кроме того, для Performance модулей DCS3700 появилась SAS карта (4 порта 6Gbit), а также iSCSI 10Gbit карта (2 порта). Таким образом, на Performance модуле можно получить следующие комбинации портов: 8*FC, 4*FC+4*SAS, 4*FC+2*iSCSI (в расчете на один контроллер).

Доступность прошивки ожидается к 7 декабря 2012г.

Читать дальше ...

Пополнение у СХД начального уровня IBM–Storwize V3700

На этой неделе в IBM сделали еще один шаг к созданию целостной линейки систем хранения данных. Была анонсирована система хранения IBM Storwize V3700, которая, как явно следует из названия, является более бюджетным вариантом Storwize V7000. Действительно, V7000 или V7000 Unified далеко не всегда могут попасть “в бюджет” заказчику, хотя их функционал и идеально вписывается в проект. Поэтому выпуск более бюджетного варианта является отличным ходом!

Давайте посмотрим, что именно IBM предлагает заказчикам V3700:

• Красивый :) интерфейс! Он уже стал привычным для владельцев таких СХД как V7000, SVC или XIV, теперь можно им пользоваться в системе с ценой меньше 20k$. Интерфейс удобный (если нет желания работать в CLI), если никогда не встречали его раньше, посмотрите ролик в этом посте.
• Виртуализация внутреннего дискового пространства. Вместо традиционных RAID-групп используются дисковые пулы.
• Выделение дискового пространства по мере необходимости – thin provisioning. (Когда же будет доступна рекламация дискового пространства?)
• Функционал FlashCopy в том варианте, в котором он есть в “старших” системах. До 64х снимков на систему.
• Производительность – по формальным показателям V3700 опережает DS3500 (хотя и отстает по максимальному объему дискового пространства).
• Миграция данных с имеющихся систем хранения (по FC). Миграция возможна только в одну сторону – для миграции данных с V3700 куда-нибудь еще придется использовать сторонние средства. Хотя, кто же захочет мигрировать данные на другую систему?!
• Поддержка до 120 дисков 2.5” или до 60 дисков 3.5”. К контроллерной полке можно подключить до 4х полок расширения. И контроллерный модуль и дисковая полка занимают в стойке 2U и поддерживают либо 12 дисков 3.5”, либо 24 диска 2.5”. Миксовать полки можно в любой последовательности.
• Поддержка 4х портов 1Gbit iSCSI “в базе” (по 2 порта на контроллер).
• Дополнительно можно установить в каждый контроллер интерфейсную плату. Это может быть либо 4 порта 1Gbit iSCSI, либо 2 порта 10Gbit iSCSI/FCoE, либо 4 порта 8Gbit FC. Разумеется в оба контроллера нужно устанавливать одинаковые платы.
• Возможность апгрейда кэш памяти – вместо “стандартных” 4GB на контроллер можно поставить 8GB (16GB на систему хранения).

Кстати, обратите внимание, что SAS порты имеют интерфейс mini SAS HD:

Но, помимо стандартных возможностей, есть и перспективы, о которых также было объявлено. Чего стоит ожидать от V3700 в некоторой перспективе (не факт, что все это действительно случится – это только “statement of direction”):

• Поддержка SAS подключения к серверам. Самое интересное, что данная поддержка будет включаться бесплатным апгрейдом микрокода. Сами SAS порты уже есть на контроллере (см. картинку выше) – только один из них используется для подключения дисковых полок, а остальные в настоящее время не задействованы.
• Поддержка Easy Tier – динамическая миграция “горячих” блоков данных с обычных дисков на SSD для повышения производительности системы.
• Поддержка репликации на удаленную СХД. Действительно, сегодня без этого даже система начального уровня выглядит “недоделанной”! Будет ли поддержка репликации на V7000 или на SVC пока не известно, но это стало бы дополнительным плюсом при выборе V3700.
• Поддержка до 2040 снимков (FlashCopy) на систему.

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

Чего же IBM НЕ предлагает владельцам V3700?

• Компрессия – если хочется компрессии, то потребуется либо отдельный appliance (и они у IBM конечно есть), либо V7000 или SVC.
• Виртуализация сторонних СХД. Хотя миграция и поддерживается, но виртуализации в V3700 не будет. Если хочется расти, то можно подключить V3700 к V7000 или SVC.
• Объединение систем в кластер.
• Поддержка NAS – unified системы не ожидается.

Критичны ли эти “не” для малого бизнеса, в котором V3700 будет первой системой хранения данных? Интерес может представлять unified и компрессия, но обе эти возможности далеко не бесплатны, поэтому я не уверен, что они стали бы популярны в связке с V3700.

Система, на мой взгляд, получилась очень интересная, особенно когда все планы по расширению функционала будут реализованы!

Интерфейс V3700 в действии

V3700 доступна к заказу с 23.11.2012 – обращайтесь к нам и наши инженеры помогут подобрать систему с необходимыми характеристиками для ваших задач. Мы можем проанализировать имеющуюся нагрузку на дисковую подсистему (и не только) и поможем правильно выбрать систему, чтобы она оправдала все ожидания!

Читать дальше ...

EMC VNX–что день грядущий нам готовит

Я уже писал про новости в high-end системах EMC, но гораздо более интересным для меня является анонс новых возможностей систем среднего уровня – VNX. И дело не в том, что такие системы гораздо больше распространены и в разы больше продаются. Речь о тех технологических возможностях, которые в них появятся. Да, несмотря на анонс, их пока нет и ждать их стоит во втором полугодии 2012. Так что же было объявлено?

Если кто-то вникал, как именно работают пулы (pools) в VNX, то наверняка обратил внимание на “магические” числа. Это, в частности, число “5” для RAID5 и “8” для RAID-6. Дело в том, что при создании пулов, именно такой размер RAID-группы всегда старается выбрать система. Конечно, если дисков недостаточно, то пул все равно будет создан, но  в одной из RAID-групп дисков будет недостаточно (или слишком много), а это скажется на равномерность нагрузки. Подробности можно прочитать вот в этой замечательной заметке, либо в ее переводе здесь. Таким образом, для RAID5 эффективность использования дискового пространства составляет 80%, а для RAID6 – 75%. В новой версии было принято увеличить размер дисковых групп – для RAID5 он может составлять 8+1 (эффективность 88.9%), а для RAID6 даже 14+2 (эффективность 87.5%). С одной стороны, это позволит несколько повысить эффективность использования дисков. С другой стороны, планирование системы становится еще более творческим занятием. Предположим, что нам нужен пул из NL SAS дисков. Логично использовать RAID6 и, как следствие, мы вынуждены использовать 17 дисков (одна группа 14+2 и пригодится хотя бы 1 hot-spare диск). Если же нужно увеличить объем системы, то дисков нужно уже 33 (а лучше бы 34). И здесь мы сталкиваемся с тем, что уместить 34 диска в дисковые полки по 15 дисков довольно проблематично, а значит потребуется 3я полка, которую мы также не сможем заполнить. В любом случае, выбор “большой” RAID группы накладывает определенные ограничения на апгрейд системы (в плане стоимости такого апгрейда). Конечно, есть полки высокой емкости, но и там диски “ровно” не укладываются.

Такими изменениями производитель нам как бы сам намекает, что оставшееся место самое время заполнить дисками SSD, чтобы использовать все прелести FAST Cache или FAST VP. И здесь мы сталкиваемся с новым изменением – в пул можно будет включать RAID-группы разного типа, т.е. в пул с  RAID6 из NL SAS дисков можно спокойно подключить RAID5 из SSD дисков (сейчас пользователь вынужден использовать только один тип RAID внутри пула, независимо от типа дисков).

Изменения коснулись и технологии FAST VP – в новом релизе данные будут сначала попадать на SSD, а уже потом перемещаться на более медленные диски. Такой подход имеет свои плюсы и минусы, но зато позволяет получить немедленный видимый эффект от использования SSD. И становится заметно проще демонстрировать преимущества от FAST VP заказчику – достаточно немного нагрузить систему. Фактически, технология FAST VP становится более похожей на FAST Cache (хотя отличия, несомненно, остаются).

В упомянутой выше статье было много сказано про недостатки пулов в VNX, связанные с расширением дискового пространства. Похоже, что и эту проблему в EMC не обошли своим вниманнием – помимо уже описанных новшеств, нас ждет еще и автоматическая ребалансировка внутри пула. При добавлении дисковых групп в общий пул, произойдет перераспределение данных по пулу. С одной стороны, это очень хорошо – добавили диски и увеличили производительность, а не только объем. С другой стороны, перераспределение занимает время и нагружает контроллеры. А как обычно происходит? Диски добавляем, когда уже и места нет, и производительность ниже необходимой. Планируйте своевременно апгрейды! (Это правило, кстати, относится не только к EMC, но и ко всем другим системам).

Ну и самое радикальное новшество – на пулах появятся новые снапшоты! Это действительно принципиальное изменение (и я понятия не имею, почему еще все производители, которые так рекламируют thin provisioning, не начали так делать). Появляются снапшоты, работающие по технологии redirect on write. Т.е. больше нам не нужно резервировать отдельное место под мгновенные снимки и системе не нужно копировать “старые” данные в этот резервный пул. В случае redirect on write новый блок данных (после создания снимка) просто записывается в новое место, а LUN “собирается” на основе указателей. Т.е. примерно так, как это реализовано в NetApp или в IBM XIV. А это дает существенные преимущества – до 256 снимков на том, нет потери производительности из-за использования снимков, возможность делать снапшоты снапшотов, доступность снапшотов на запись. Да, да -  извечные противники в плане технологий стали еще ближе друг к другу! Если NetApp выступает своего рода первопроходцем, то EMC идет по намеченному курсу, делая нужные изменения (не факт что в нужный момент, но зато не приходится растрачиваться на рекламу новых фишек – публика уже “подогрета” рассказами NetApp).

Но гонка с NetApp на снапшотах не закончена и у VNX появляется еще один дополнительный программный продукт – AppSync. Он предназначен для защиты приложений (на старте - Exchange и VMware, потом планируются и другие). Пользователь задает уровень доступности  (SLA) для конкретного приложения и может самостоятельно восстанавливать данные в случае сбоя.

Большинство из объявленных новшеств доступны только в системах VNX, а владельцам VNXe придется подождать – из-за особенностей реализации блочных протоколов в VNXe.

Посмотрим, что готовят конкуренты в ответ!

Читать дальше ...

Кэшировать всегда, кэшировать везде!

Уже во время анонса системы IBM XIV Gen3 было объявлено о скорой поддержке SSD внутри модулей. “Скоро” уже настало и вот теперь можно не только заказать новый XIV Gen3 с установленными SSD дисками, но и установить SSD в уже инсталлированную систему XIV Gen3 (процедура не требует остановки – только обновления микрокода). В каждый узел XIV можно установить по одному диску SSD 400GB (суммарно это даст от 2.4ТБ до 6ТБ на систему, размер немного занизили – изначально обещали диски по 500GB). Почему так мало? Потому что это пространство может быть использовано только как кэш чтения, а не для хранения самих данных, а 6ТБ кэш памяти это не так уж и мало. Кэшируются только операции чтения – для кэширования операций записи используется оперативная память узлов XIV (суммарный объем которой достигает 360GB). Чтобы обеспечить для SSD модулей долгое и безоблачное существование под высокой нагрузкой используется специальный механизм оптимизации: изначально в оперативной памяти узла формируются блоки размером по 512КБ и уже именно эти блоки последовательно и циклично записываются на SSD. Таким образом, операции записи на SSD всегда идут последовательно, а ячейки используются равномерно. Обещают неплохой прирост в производительности:

Решение, предложенное в XIV безусловно не является технологическим прорывом – всем уже вспомнился и EMC FastCache, и NetApp FlashCache. Каждое из этих решений имеет и свои плюсы, и свои минусы. От EMC FastCache заказчик получает не только кэширование при чтении, но и кэширование операций записи. Платой за это является существенное сокращение кэша в оперативной памяти SP и сравнительно небольшой объем – для “топового” VNX7500 он составляет 2.1ТБ (при использовании 100GB дисков). В случае с NetApp FlashCache кэшируется только чтение, но зато кэш является дедублицированным и может достигать 16ТБ. Кроме того, FlashCache является PCI-e платой, поэтому “дорога” от кэша до процессора (а значит и до хоста) гораздо короче, чем при использовании SSD дисков. А это, в свою очередь, потенциально позволяет получить довольно низкую латентность. С другой стороны, если мы захотим получить 16ТБ кэша, то на придется задействовать 16 слотов расширения из 24х возможных, что существенно ограничит возможности расширения (как по дискам, так и по используемым протоколам подключения хостов).

EMC тоже отметились и с шумом выкатили свое решение для кэширования VFCache (Very Fast Cache). Что это и как “привязано” к дисковой системе? По факту VFCache это обычная PCI-e плата (как и аналоги у FusionIO, LSI и пр.) 300GB (производства Micron), которая используется не как супер-быстрый диск в операционной системе, но как кэш для операций чтения.

В принципе (насколько я понял из прочитанного/найденного), никто не мешает использовать VFCache с любой дисковой системой (и без нее в т.ч.). Можно даже часть VFCache “отрезать” и использовать как жесткий диск. Среди явных минусов – пока поддерживается только одна карта в сервере, так что использование части VFCache как DAS, не может обеспечить отказоустойчивость. Кроме того, поддержка в VMware серьезно ограничивает такой функционал как vMotion (а точнее он просто не поддерживается). В данном случае решение EMC тоже уникальным не назовешь. Один из пионеров в выпуске PCI-e SSD карт – FusionIO уже некоторое время предлагает аналогичный продукт ioCache (который, кстати, vMotion как раз поддерживает). Есть надежда, что в последующих релизах VFCache будет существенным образом доработан и появится не только более тесная интеграция с VMware, но и с собственными продуктами (FAST Cache/ FAST VP).

Читать дальше ...

LSI: новые контроллеры, новые горизонты

LSI анонсировал два новых контроллера – MegaRAID SAS 9265-8i и 9285-8e. Это представители уже второго поколения контроллеров с поддержкой SAS2 (6Gbps). Оба контроллера построены на одном чипе (RAID on Chip, ROC) – LSISAS2208, работающем на 800МГц и имеющем два ядра. Объем кэша составляет уже 1ГБ (используется память DDR3). Фактически отличие контроллеров только в том, как расположены порты – 9265-8i имеет 8 портов “внутрь”, а 9285-8e 8 портов “наружу”. Отличается и максимально поддерживаемое число дисков (через экспандер) – 128 для 8i  и 240 для 8e. Выпущена и новая модификация батареи для защиты кэша – LSIiBBU09. Новизна состоит в том, что батарея более терпимо относится к повышенным температурам внутри сервера (до 55⁰C). Как и для прошлого поколения, предлагаются опциональные “расширения”: FastPath (оптимизация для работы с SSD), CacheCade (возможность использовать SSD в качестве “умного” кэша), Recovery (снапшоты) и SafeStor (поддержка шифрования на уровне дисков).

Но, конечно же, самое интересное это производительность новых контроллеров (что особенно актуально при использовании SSD дисков). Заявлено, что при использовании технологии FastPath производительность выросла более чем в 3.5 раза по сравнению с прошлым поколением до 465,000 IOPs:

На картинке – сравнение первого и второго поколения 6Гбит контроллеров LSI (внутренние тесты LSI) для вариантов с включенным и отключенным FastPath. подробности (и другие результаты можно найти здесь).

Немного удивляет батарейка вместо ставшими уже привычными (у других производителей) суперконденсаторов и флэш-памяти. А учитывая, что уже наверное пару месяцев назад были вполне предметные разговоры про аналогичную технологию и у LSI (и даже назывались модели контроллеров) это еще более странно. И до сих пор, кроме строчки в списке зарегистрированных торговых марок, никакой официальной информации про это нет. Посмотрим, как это все отразится на PMC-Sierra (Adaptec), у которых сейчас только начинаются продажи первых 6Гбит контроллеров. LSI сделал все возможное (включая прочное сотрудничество с такими производителями серверов как IBM, Dell и Fujitsu), чтобы занять как можно большую долю рынка.

Читать дальше ...

Многопоточный RAID

IBM анонсировали новый RAID контроллер, предназначенный специально для SSD. В отличие от остальных, представленных сейчас в портфеле IBM контроллеров, этот сделан не компанией LSI, а совместно с PMC-Sierra. Так как ServeRAID B5015 предназначен исключительно для SSD, то и выбор уровней RAID довольно скромный – только RAID1 и RAID5, создать можно до 4х логических дисков (LUN) на контроллер. Максимум можно подключить до 8ми дисков SAS 2.0 6Gb/s (замечательно укладывается в концепцию exFlash для серверов IBM x3850X5/x3950X5). Сердце контроллера – три ядра MIPS с поддержкой многопоточности. В стеке maxRAID активно используется эта самая многопоточность для увеличения производительности по сравнению с имеющимися на рынке решениями. Кэша нет, а следовательно нет и необходимости в батарейке. 

Читать дальше ...

6Gbps SAS в серверах IBM

6Gbps SAS диски уже некоторое время доступны к заказу вместе с серверами IBM, но вот сегодня были анонсированы и 6Gbps RAID контроллеры: ServeRAID M5014 и M5015. Оба контроллера имеют по 8 внутренних портов (2 miniSAS разъема) и поддерживают до 32х устройств, подключенных напрямую или через экспандеры. M5015 (на картинке) оснащен 512МБ кэш-памяти и поставляется вместе с батареей (BBU) для защиты кэша; M5014 имеет на борту 256МБ кэша и батарею к нему нужно будет докупать отдельно. Оба они построены на базе 800МГц процессора PowerPC  c контроллером LSI SAS2108 RAID-on-Chip – IBM продолжает использовать контроллеры LSI, в данном случае это, как я понимаю, практически полные аналоги MegaRAID SAS 9260-8i.

На данный момент контроллеры поддерживаются в серверах IBM x3400M2, x3500M2, x3550M2 и x3650M2 (т.е. все новые двухпроцессорные модели на “нехалемах”). Ранее мои коллеги уже приводили результаты тестирования аналогичного контроллера от Intel вместе с SSD и результаты очень впечатляют. Так что если Вам нужна высокая производительность дисковой подсистемы сервера – можно довольно успешно комбинировать новые контроллеры вместе с уже поставляемыми для этих серверов 50GB High IOPS SSD.

Читать дальше ...

Intel SSD x25-e и Intel RAID RS2BL080

Продолжая тему SSD и их работы в RAID, надо отметить что пока что (на мой взгляд) не было контроллера который давал адекватную производительность во всех ситуациях с SSD. Также большой головной болью было то, что при отключении КЭШа SSD дисков производительность системы значительно падала, тогда как его требуется выключать для создания отказоустойчивых конфигураций.

Вот и получается – хочется чтобы все работало быстро, включай КЭШ диска. Но если вдруг выключиться электричество или будет еще какой сбой, все данные находящиеся в этом КЭШе потеряются. С другой стороны выключая КЭШ мы получали просадку по производительности (подробнее можно посмотреть в предыдущем материале про SSD и контроллеры LSI).

Теперь непосредственно, что привело к написанию этого материала. Intel любезно предоставил нам в тест контроллер Intel RAID RS2BL080, который интересен тем, что он рассчитан на 6ГБ SAS (обратная совместимость с SAS 3GB и SATA присутствует), в результате чего имеет полностью переработанную архитектуру. Для начала мы решили посмотреть контроллер в работе с SSD, чтобы посмотреть на что он способен при максимально быстром back-end (дисках), результаты тестов и будут представлены ниже.

Контроллер Intel RAID RS2BL080

Intel RAID RS2BL080 он же LSI MegaRAID 9260-8i

Строго говоря контроллер произведен компанией LSI, Intel же OEMит их. В контроллере 8 портов 6Gb/s SATA/SAS, 512МБ памяти и процессор LSISAS2108 (6Gb/s RAID-on-Chip - 800MHz PowerPC). Выглядит вполне обычно.

Судя по маркетингу LSI максимальная пропускная способность чтения около 2,9ГБ/сек, а записи 1,8ГБ/сек.

Описание на сайте Intel.
Спецификация на сайте Intel.
Спецификация на сайте LSI.

Тесты с SSD

Было решено в первую очередь проверить две разные конфигурации:

1. 8 штук SSD Intel x25-e в RAID 5, КЭШ контроллера включен, КЭШ дисков выключен. Общий смысл данного теста был посмотреть, как себя покажет конфигурация собранная из расчета компромиссного соотношения цена/объем. Также немаловажно и то, что КЭШ дисков был отключен, в реальную работу не стоит ставить диски с включенным КЭШ, слишком велики риски потери информации.

2. 8 штук SSD Intel x25-e в RAID 10, КЭШ контроллера включен, КЭШ дисков выключен. Также было решено проверить R10 для оценки разницы в производительности относительно R5.

Ниже представлены скриншоты настроек.
Тест делался по обычной схеме с Iometer’ом.

Настройки для теста в R5

Настройки для теста в R10

Результаты

Последовательное чтение.

Raid5

Raid10

Чрезвычайно впечатляющее начало 160 000 IOPS на чтение, эти цифры соизмеримы с характеристиками производительности дисковых систем среднего уровня. С той лишь разницей, что на дисковой системе с обычными дисками, таких цифр можно достичь только из чистого КЭШа, а здесь эти цифры получены на LUN в 200GB. Фактически этот результат показывает производительность контроллера, для сравнения LSI 84016E давал в пике около 40 000 IOPS, Adaptec 5805 около 50 000 IOPS, здесь же мы получили 160 000 IOPS на маленьком блоке. Очень круто. Руки чешутся протестировать на нем обычный SAS, чтобы понять даст ли такой контроллер роста производительности с обычными дисками.

Кстати кроме IOPS не менее интересно что контроллер достиг уже 1200 МБ/сек. У предыдущего LSI этот потолок был около 800МБ/сек.

Случайное чтение.

Raid5

 

Raid10

Результат очень достойный, для полностью случайной нагрузки также отличный результат. Тот же потолок в 1200 МБ/сек, достигается здесь несколько позже чем при последовательном чтении, что в общем естественно. Для сравнения IOPS у LSI 84016E было примерно столько же, у Adaptec 5805 в Raid5 чуть больше (правда с включенным КЭШ дисков .) ).

Отличные результаты, на уровне лучших что я видел для такого количества SSD при такой нагрузке.

Последовательная запись.

Raid5

 

Raid10

 

Исключительные результаты, видно что контроллер работает по максимуму и вычислительной мощности ему хватает с лихвой. При всем при этом, что интересно в RAID 5 контроллер пробил планку в 1200МБ/сек и уперся уже в 1400МБ/сек. В RAID 10 такого не наблюдается, видимо по причине меньшего количества конечных дисков на которые ведется запись. Тест опять же наглядно показывает что подопытный контроллер чрезвычайно мощный.

Что интересно, так называемого, RAID 5 penalty не наблюдается. По идее мы должны были бы видеть некоторую просадку по производительности в RAID 5 , относительно RAID 10.

Случайная запись.

Raid5

 

Raid10

Левая часть графиков где отражены IOPS соответствует высоким ожиданиям, динамика графиков с точностью повторяет такую в предыдущих тестах, результаты получаются лучше чем и у LSI 84016E и у Adaptec 5805. Adaptec 5805 проигрывает где то около 20% в RAID5 и около 30% в RAID10, LSI 84016E проигрывает около 20% в RAID10 результатов эквивалентных тестов в RAID5 у меня нету.

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

Также надо отметить, что есть подозрение что такое поведение массива обязано больше не контроллеру а дискам и их собственным алгоритмам записи и выстраивания очереди. Любопытно посмотреть аналогичные результаты при включеном КЭШ дисков (собственно именно эти тесты сейчас у нас и идут).

33% чтение, 100% случайные операции.

Raid5

 

Raid10

 

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

Типовые профили

Raid5

Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	ART (ms)	ART-read (ms)	ART-write (ms)
File Server	7 938,72	6 349,31	1 589,41	85,82	68,62	17,20	4,03	4,78	1,04
Web Server	15 791,47	15 791,47	0,00	242,30	242,30	0,00	2,03	2,03	0,00

Raid10

Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	ART (ms)	ART-read (ms)	ART-write (ms)
File Server	17 184,08	13 750,53	3 433,55	185,72	148,68	37,04	1,86	2,02	1,21
Web Server	20 511,35	20 511,35	0,00	313,48	313,48	0,00	1,56	1,56	0,00

В качестве сравнительной шкалы приведены результаты двух типовых тестов, отметить хочется то, что при очень высоких результатах время ответа (ART) сохраняется на рекордно низком уровне 1-4 ms. В этих же результатах видно что RAID 10 благодаря более высоким результатам на записи показывает лучшие результаты.

Выводы

Что хочется сказать в итоге, контроллер судя по этим результатам получился исключительно мощный, руки чешутся сделать тесты на 15k SAS дисках (я думаю сделаем на следующей неделе), вероятно контроллер и на них даст лучшую производительность чем его текущие конкуренты (тот же Adaptec 5805).

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

Доступность и стоимость контроллера пока не ясна, как я уже писал выше, нам он достался в единственном экземпляре и реальных цен в РФ я не видел. Судя по всему он должен быть в одной ценовой группе с Adaptec 5805 и аналогичными 8 портовыми LSI.

Читать дальше ...

SSD intel x25-E и MegaRAID SAS 84016E

Intel любезно предоставил в тестирование контроллер MegaRAID SAS 84016E чтобы попробовать как на нем заработают SSD, в результате было сделано 2 теста с разными настройками контроллера. в обоих тестах использовались 8 дисков подключенных по 4 в первые два канала контроллера. В обоих случаях диски собирались в RAID 10. Чем отличались тесты? В первом случае тест делался с включенным КЭШем контроллера, во втором с выключенным. Надо отметить что в своих результатах Intel получает наилучшие результаты именно с выключенным КЭШем. Также надо отметить, что Intel рекомендует вместе с отключением КЭШа контроллера включать КЭШ дисков. Также наоборот, при включении КЭШа контроллера – выключать кэш дисков.

Для тестирования была взята платформа как и до этого в тестах с adaptec только вместо контроллера adaptec в неё включался контроллер MegaRAID SAS 84016E. Как уже писалось выше в контроллер включалось по 4 SSD в первый и второй канал. Диски включались напрямую, без корзин.

Настройки контроллера – первый случай:

КЭШ контроллера включен. КЭШ дисков выключен.

КЭШ контроллера отключен. КЭШ дисков включен. Рекомендации Intel.

Какие получились результаты.

Последовательное чтение

Кэш включен

Кэш выключен

Уже привычная по Adaptec и предыдущему тестированию картина странных всплесков и падений. Динамика скорости примерно одинаковая. Потолок в который уперлась скорость в обоих случаях – 845МБ/сек. В случае включенного КЭШа скорее всего просадки вызваны особенностями контроллера, видимо работа идет блоками по 16кб, поэтому после достижения размера блока этого размера скорость работы контроллера с КЭШем перестает быть узким местом. Откуда взялся скачек на блоке в 2кб в случае включенного КЭШа – ума не приложу. Может быть какие то дополнительные внутренние оптимизации.

Последовательная запись

Кэш включен

Кэш выключен

При последовательной записи КЭШ наоборот начинает играть роль, видимо такой результат связан с его алгоритмом работы на запись. Рост производительности при включенном КЭШе идет до блока в 16кб, что скорее всего связано с размером блока КЭШа. Почему абсолютные цифры при последовательной записи (в случае включенного КЭШа) выше чем при последовательном чтении, неясно. Можно предположить что контроллер лучше справляется с алгоритмами кэширования записи, нежели чем с упреждающим чтением.

Случайное чтение

Кэш включен

Кэш выключен

Картина схожа, поскольку все операции на 100% случайны контроллер не может вмешаться алгоритмами упреждающего чтения. Верхняя граница та же 845МБ/сек.

Случайная запись

Кэш включен

Кэш выключен

Поскольку процедура полностью случайная, КЭШ контроллера никак не может повлиять на результат, видны схожие результаты в обоих случаях. Причем результаты записи большим блоком идут очень медленно, результаты требуют разъяснения от производителя. Не очень ясно какие настройки выбраны не корректно. На маленьком блоке результат без КЭШа контроллера предсказуемо лучше.

Запись/чтение 67/33 – 100% случайные

Кэш включен

Кэш выключен

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

Выводы

Нельзя сделать однозначный вывод по результатам теста, поскольку цифры и динамика их изменения не похожа на аналогичные результаты HDD (опять же обычные результаты можно посмотреть в предыдущем материале про SAS и SSD на Adaptec). Можно точно сказать, что пока что результат не оправдывает ожидания, есть подозрение что при отключенном КЭШе нужно попробовать поставить размер блока массива больше чем 256КБ, к примеру те же 1024КБ в случае Adaptec это давало наилучший результат. Сейчас доделываются результаты R0 из 8xssd при размере блока 256КБ и отключенном КЭШе контроллера, я думаю следующим этапом мы попробуем прогнать тест в той же конфигурации только с отключенным КЭШем дисков, выберем наилучший результат и в такой конфигурации повторим тест с максимальным размером блока. Возможно это даст ответ на то насколько сильно влияет кэширование самих дисков на результат и насколько повлияет изменение размера блока в большую сторону на уровне всего массива.

Читать дальше ...

Тестирование Intel® X25-E Extreme SATA Solid-State Drive

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

За последние годы производительность процессоров и памяти выросла в десятки раз, а производительность подсистемы ввода-вывода осталась практически неизменной - вырос только объем дисков. Для увеличения производительности нам приходится постоянно увеличивать количество дисков, докупать к массиву новые дисковые полки, использовать более сложные уровни RAID для увеличения отказоустойчивости - и снова терять производительность.

Компания Intel представила два новых SSD накопителя. Это сверхбыстрые твердотельные накопители Intel X25-M и X25-E. Первый рассчитан на системы среднего уровня, а второй, достоинства и недостатки которого я рассматриваю, рассчитан на корпоративный (High-End) сегмент.

Что же диск из себя представляет?

Диски выполнены в форм-факторе 2,5 дюйма, имеют привычный и интерфейс SATA с пропускной способностью 3.0 Gb/s, практически не греются и устойчивы к вибрациям. Полная спецификация диска доступна на сайте производителя (http://download.intel.com/design/flash/nand/extreme/extreme-sata-ssd-datasheet.pdf).

Явным достоинством дисков X25-E является использование флеш памяти SLC (single-level cell), что обеспечивает высокую производительность, так как имеется прямой доступ к каждому биту данных (в отличие от памяти MLC (multi-level cell), где в каждой ячейке хранится несколько бит данных).

SSD диск Intel X25-E 32 GB

Можно оценить масштаб

Также для повышения производительности используется десятиканальный контроллер памяти работающий с чипами параллельно, то есть вся флеш-память внутри диска объединена в RAID 0. Основное преимущество в использовании SSD дисков – крайне малое время для обращения к случайным секторам, что очень важно в системах хранения (к примеру, для поиска по базе данных). Мы постараемся проследить это в нашем тесте. Главное, что заставляет смотреть в сторону SSD дисков как на перспективное решение хранения – интерфейс SATA и самим фактом работы их с уже существующей инфраструктурой. Нет сомнений, что намного проще постепенно добавлять SSD к системам хранения, начиная от понятной возможности включения их в SATA контроллеры. А в перспективе, возможно, появятся отдельные контроллеры, оптимизированные именно под SSD или отдельные BIOS для существующих контроллеров, которые будут работать с SSD оптимально, а другие BIOS будут для HDD.

Если разобрать – видим на одной стороне 10 чипов памяти SLC, 1 контроллер диска от Intel, 1 чип памяти RAM в роли кэша. На другой стороне 10 чипов памяти.

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

Часто к недостаткам твердотельных дисков относят достаточно высокую цену за 1Mb хранимой информации. Это не совсем верно, более правильно пересчитывать цену за iops. Как правило, нам не требуется огромного объема для хранения базы данных.

Еще одно заблуждение – это невысокая надежность, вызванная ограниченным количеством циклов перезаписи ячеек памяти. Время наработки на отказ (MTBF) у X25-E составляет 2 миллиона часов, к примеру, MTBF жестких дисков Hitachi HUS153014VL300 составляет 1,2 миллиона часов, а у контроллера Adaptec на котором мы проводили тесты всего 873,402 часов.

К этому можно добавить “умный” контроллер, который оптимизирует использование ресурса записи ячеек, т.е. износ памяти происходит равномерно. Для повышения отказоустойчивости, на дисках зарезервировано 6% от объема на случай отказа части ячеек или исчерпания ими ресурса записи. А также вы можете при помощи SMART отслеживать количество уже записанной информации и прогнозировать время жизни каждого диска.

Соответственно если отдельная ячейка перестает работать, вместо неё начинает использоваться резервная. Учитывая природу SSD, это не сказывается на общей производительности, в отличие от аналогичной процедуры remap’а у HDD. Скорость работы SSD не зависит от фрагментации ячеек, как таковое понятие физической последовательности ячеек просто отсутствует в SSD.

А за счет того, что дисковый контроллер организует информацию отказоустойчивым образом, это не влечет за собой ни потери данных, ни ухудшения производительности.

Методика тестирования

Тестовая конфигурация:

Материнская плата	Supermicro X7SBE (f/w 1.2a)
Процессор	Intel Core 2 Quad Q9400 2666 MHz
Оперативная память	2x Kingston 2GB 800 DDR2
RAID контроллер	Adaptec RAID 5805 (f/w 16501) Cache Memory 512MB of DDR2
Дисковая система	Seagate 7200.10, 250Gb –системный - 8x Intel® X25-E 32 Gb - 8x Hitachi HUS153014VL300147Gb 15K rpm
Операционная система	MS Windows Server 2008 Enterprise 6.0.6001 (HotFix KB960735)

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

В своих тестах я использовал контроллер Adaptec как хорошо себя зарекомендовавший для любой нагрузки уровня локальной серверной системы хранения.

Официально Intel валидировала свои SSD под южный мост ICH9R и ICH10R, а Adaptec добавил их в лист совместимости, хотя поддержку конфигураций Adaptec начнет оказывать только с лета.

Эмпирическим путем были выяснены оптимальные настройки контроллера для работы с SSD:

Drivers Write Cache	Enable All (рекомендовано инженерами Intel)
Array Background Consistency Check	Disabled
SATA Native Command Queuing	Enabled (рекомендовано инженерами Intel)
Power Management	Off (как показали другие исследователи, данная опция имеет серьезное влияние на производительность SSD)

Почти таким же путем и параметры массива:

Write cache	Enabled (write-back) when protected by battery (общая рекомендация для RAID)
Read cache	Enabled
Stripe Size RAID 0	1024 kb
Stripe Size RAID 5	256 kb (рекомендовано инженерами Intel)

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

Тест 1-го SSD диска

В начале тестирования, когда я измерял производительность одного диска, он был подключен к южному мосту ICH9R. Результаты получались в 1,5-2 раза ниже официально заявленных и при повторении тестов результаты очень сильно отличались друг от друга. Как выяснилось, проблема оказалась в некорректной поддержке NCQ в ACHI драйвере Microsoft (http://support.microsoft.com/kb/960735/en-us). После установки патча, диск сразу показал производительность близкую к заявленной.

Результаты получились близкие к заявленным, что позволило перейти к дальнейшим тестам дисков в RAID. Именно эти тесты представляют из себя наибольший интерес.

Забегая вперед, отмечу, что получаются чрезвычайно любопытные результаты. Чем же они любопытны? В первую очередь тем, что они ясно показывают всю специфику устройства. Поведение SSD в разных тестах принципиально отличается от поведения классических дисков в тех же ситуациях.

2xSSD – Raid 0, блок 1024kb

В этой конфигурации на пробу были включены 2 SSD диска с целью понять, как оно вообще будет работать в RAID. Естественно ожидаемый прирост производительности относительно 1-го диска 2 раза.

Я прогонял по 10 минут IOmeter в 256 потоков с разными по размеру блоками запроса. Блок меньше 128kb можно соотнести с нагрузкой БД или веб-сервера, блок большего объема к работе с файлами.

Соответственно в графиках ниже, по горизонтали размер блока, по вертикали –IOPS или мегабайты в секунды.

Линейное чтение

Линейная запись

Сначала были выполнены тесты с последовательными чтением и записью. Поскольку, например операции чтения показали скорость больше 1,5 ГБ/сек, у меня нет к ним большого доверия. Это связано с тем, что большую часть запросов обрабатывал кэш контроллеров. В общем и целом линейные результаты получились - «ни о чем».

Случайное чтение

Случайная запись

А вот с операциями случайного доступа, все намного интереснее. Они не зависят от кэша и по ним можно оценить саму скорость диска, поскольку влияние модуля кэширования контроллера в них сводится к минимуму.

Интересен провал производительности в случае записи блоков больше чем 64кб, но об этом мы поговорим чуть ниже, при сравнении SAS и SSD.

Сами цифры для 2-х дисков получились отличные. Для полностью случайной записи по 4 000 IOPS на диск это очень круто.

Чтение 33%, запись 67%

В этом тесте использовалась смешаная нагрузка, наглядно видно, что провал по записи тянет за собой и чтение. Это объясняется одной очредью операций в которой чтение не может опередить запись.

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

В начале лета должна появиться прошивка для контроллера Adaptec которая сможет использовать все преимущества дисков как следствие ожидается улучшение результатов.

8xSSD – Raid 0, блок 1024kb

VS
8xSSD – Raid 5, блок 256kb

VS
8xSAS15k – Raid 5, блок 256kb

Итак сравним напрямую производительность 8 SAS и 8 SSD на одном и том же контроллере Adaptec 5805. Всего в дисковом контроллере было 2 порта по 4 канала, соответственно все порты заняты дисками. Этим обусловлено количество сравниваемых дисков – 8. Еще на выбор в 8 дисков повлияло то что всего у меня было 8 штук SSD для тестов.

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

В наших тестах размер блока чтения/записи 4Кб оказался наиболее приемлемым с точки зрения количества операций в секунду. В пользу того, что такой размер является оптимальным, говорят и официальные данные Intel, где производительность в IOPS также рассчитывается на блоках 4 Кб. Но в реальных задачах часто блоки иные, и мы постарались показать изменение производительности при смене блока. Таким образом, в этих тестах мы выбрали стандартные размеры блоков и проверяли производительность дисковых систем под нагрузкой 256 одновременных потоках IOmeter’а.

Случайное чтение

SSD

SAS

Различия в производительности Raid 0 и Raid 5 у SSD вызваны тем что, во втором случае контроллер RAID выполняет работу по расчетам четности блоков данных, что снижает общую производительность.

Радует что результат линейный и крайне предсказуемый. Также замечательно то, что в пике чтение SSD достигает 1ГБ/сек или 30 000 IOPS. Результаты SAS в 10 раз меньше.

Случайная запись

SSD

SAS

Наиболее показательно то, что SSD на маленьком блоке (512b – 8k) дает результаты почти в 20 раз выше, чем SAS. В общем-то, увидели, что и ожидали. Именно в такого типа нагрузке SSD проявляет себя с самой сильной стороны.

Падение производительности SSD на блоке больше 64кб мы уже видели до этого в RAID 0 из двух SSD дисков. Причины этого падения производительности у SSD не ясны, но можно предположить, что алгоритмы записи SSD диска заточены на блок меньший 64к. Либо алгоритмы работы Adaptec’а каким-то образом влияют на производительность контроллера SSD при блоках больших 64K. Поскольку внутренняя схема работы и алгоритмы контроллера не известны нельзя точно сказать, в чем же дело.

Но даже, несмотря на это падение, худший результат SSD всё равно выше, лучшего результата SAS.

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

70% запись, 30% чтение

SSD

SAS

Графики разделены на чтение и запись, что позволяет детально видеть динамику движения и влияние чтения на запись.

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

Этим объясняется падение производительности SSD на размере блока 64к. Здесь мы видим туже картину, что и в случайной записи. В случайном чтении поведение графика было другое, в тесте со смешанной нагрузкой оно становится как и у записи из-за общей очереди. Опять же про это уже говорили выше.

По результатам наглядно видно превосходство SSD дисков над HDD. На маленьком блоке оно просто огромно! SSD быстрее больше чем в 20 раз.

Время ответа массива при нагрузке 70% запись, 30% чтение

SSD

На графиках: ART – среднее время ответа.

SAS

На графиках: ART – среднее время ответа.

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

Этот параметр критичен, например, для баз данных. БД генерирует огромное количество запросов и естественно долгое ожидание на запрос, тормозит всю очередь.

По графикам видно, что на блоках свойственных БД, SSD в сотни раз превосходит обычные диски. Ситуация начинает портиться при размере блока больше 256кб, но этот тип нагрузки свойственен больше потоковому копированию на котором эта характеристика уже менее актуальна. Есть предположение, что схожая динамика SSD и SAS может быть объяснена дисковым контроллером, но это скорее предположение.

Выводы

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

Итак, если ваша задача требует интенсивного обмена данными с дисковой системой, то твердотельные диски Intel X-25E станут достойной альтернативой многодисковым массивам из традиционных дисков. К примеру, SSD получается отличным решением для баз данных или веб серверов.

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

При появлении в нашей лаборатории других контроллеров с поддержкой SSD (а также новых прошивок для контроллеров) мы проведем дополнительную проверку результатов и сможем проверить высказанные выше гипотезы.

Читать дальше ...