Stripe size какой выбрать. Больше не значит лучше. Размещение базы, shadow и backup

В интернете есть масса статей с описанием RAID. Например, эта описывает все очень подробно. Но как обычно, читать все не хватает времени, поэтому надо что-нибудь коротенькое для понимания - а надо оно или нет, и что лучше использовать применительно к работе с СУБД (InterBase, Firebird или что то иное - на самом деле все равно). Перед вашими глазами - именно такой материал.

В первом приближении RAID это объединение дисков в один массив. SATA, SAS, SCSI, SSD - неважно. Более того, практически каждая нормальная материнская плата сейчас поддерживает возможность организации SATA RAID. Пройдемся по списку, какие бывают RAID и зачем они. (Хотел бы сразу заметить, что в RAID нужно объединять одинаковые диски. Объединение дисков от разных производителей, от одного но разных типов, или разных размеров - это баловство для человека, сидящего на домашнем компьютере).

RAID 0 (Stripe)

Грубо говоря, это последовательное объединение двух (или более) физических дисков в один "физический" диск. Годится разве что для организации огромных дисковых пространств, например, для тех, кто работает с редактированием видео. Базы данных на таких дисках держать нет смысла - в самом деле, если даже у вас база данных имеет размер 50 гигабайт, то почему вы купили два диска размером по 40 гигабайт, а не 1 на 80 гигабайт? Хуже всего то, что в RAID 0 любой отказ одного из дисков ведет к полной неработоспособности такого RAID, потому что данные записываются поочередно на оба диска, и соответственно, RAID 0 не имеет средств для восстановления в случае сбоев.

Конечно, RAID 0 дает ускорение в работе из-за чередования чтения/записи.

RAID 0 часто используют для размещения временных файлов.

RAID 1 (Mirror)

Зеркалирование дисков. Если Shadow в IB/FB это программное зеркалирование (см. Operations Guide.pdf), то RAID 1 - аппаратное зеркалирование, и ничего более. Упаси вас от использования программного зеркалирования средствами ОС или сторонним ПО. Надо или "железный" RAID 1, или shadow.

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

Насчет производительности - по записи выигрыш 0, по чтению - возможно до 1.5 раз, т. к. чтение может производиться "параллельно" (поочередно с разных дисков) . Для баз данных ускорение мало, в то время как при параллельном обращении к разным (!) частям (файлам) диска ускорение будет абсолютно точно.

RAID 1+0

Под RAID 1+0 имеют в виду вариант RAID 10, когда два RAID 1 объединяются в RAID 0. Вариант, когда два RAID 0 объединяются в RAID 1 называется RAID 0+1, и "снаружи" представляет собой тот же RAID 10.

RAID 2-3-4

Эти RAID являются редкими, т. к. в них используются коды Хэмминга, либо разбиение байт на блоки + контрольные суммы и т. п., но общее резюме таково - эти RAID дают только надежность, при 0-вом увеличении производительности, и иногда даже ее ухудшении.

RAID 5

Для него нужно минимально 3 диска. Данные четности распределяются по всем дискам массива

Обычно говорится, что "RAID5 использует независимый доступ к дискам, так что запросы к разным дискам могут выполняться параллельно". Следует иметь в виду, что речь идет, конечно, о параллельных запросах на ввод-вывод. Если такие запросы идут последовательно (в SuperServer), то конечно, эффекта распараллеливания доступа на RAID 5 вы не получите. Разумеется, RAID5 даст прирост производительности, если с массивом будут работать операционная система и другие приложения (например, на нем будет находиться виртуальная память, TEMP и т. п.).

Вообще RAID 5 раньше был наиболее часто используемым массивом дисков для работы с СУБД. Сейчас такой массив можно организовать и на SATA дисках, причем он получится существенно дешевле, чем на SCSI. Цены и контроллеры вы можете посмотреть в статьях
Причем, следует обратить внимание на объем покупаемых дисков - например, в одной из упомянутых статей RAID5 собирается из 4-х дисков объемом 34 гиг, при этом объем "диска" получается 103 гигабайта.

Тестирование пяти контроллеров SATA RAID - http://www.thg.ru/storage/20051102/index.html .

Adaptec SATA RAID 21610SA в массивах RAID 5 - http://www.ixbt.com/storage/adaptec21610raid5.shtml .

Почему RAID 5 - это плохо - https://geektimes.ru/post/78311/

Внимание! При закупке дисков для RAID5 обычно берут 3 диска, по минимуму (скорее из-за цены). Если вдруг по прошествии времени один из дисков откажет, то может возникнуть ситуация, когда не удастся приобрести диск, аналогичный используемым (перестали выпускаться, временно нет в продаже, и т. п.). Поэтому более интересной идеей кажется закупка 4-х дисков, организация RAID5 из трех, и подключение 4-го диска в качестве резервного (для бэкапов, других файлов и прочих нужд).

Объем дискового массива RAID5 расчитывается по формуле (n-1)*hddsize, где n - число дисков в массиве, а hddsize - размер одного диска. Например, для массива из 4-х дисков по 80 гигабайт общий объем будет 240 гигабайт.

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

Статья RAID-5 must die . И еще о потерях данных на RAID5 .

Примечание. На 05.09.2005 стоимость SATA диска Hitachi 80Gb составляет 60 долларов.

RAID 10, 50

Дальше идут уже комбинации из перечисленных вариантов. Например, RAID 10 это RAID 0 + RAID 1. RAID 50 - это RAID 5 + RAID 0.

Интересно, что комбинация RAID 0+1 в плане надежности оказывается хуже, чем RAID5. В копилке службы ремонта БД есть случай сбоя одного диска в системе RAID0 (3 диска) + RAID1 (еще 3 таких же диска). При этом RAID1 не смог "поднять" резервный диск. База оказалась испорченной без шансов на ремонт.

Для RAID 0+1 требуется 4 диска, а для RAID 5 - 3. Подумайте об этом.

RAID 6

В отличие от RAID 5, который использует четность для защиты данных от одиночных неисправностей, в RAID 6 та же четность используется для защиты от двойных неисправностей. Соответственно, процессор более мощный, чем в RAID 5, и дисков требуется уже не 3, а минимум 5 (три диска данных и 2 диска контроля четности). Причем, количество дисков в raid6 не имеет такой гибкости, как в raid 5, и должно быть равно простому числу (5, 7, 11, 13 и т. д.)

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

По производительности RAID 6 я данных не видел (не искал), но вполне может быть, что из-за избыточного контроля производительность может быть на уровне RAID 5.

Rebuild time

У любого массива RAID, который остается работоспособным при сбое одного диска, существует такое понятие, как rebuild time . Разумеется, когда вы заменили сдохший диск на новый, контроллер должен организовать функционирование нового диска в массиве, и на это потребуется определенное время.

Во время "подключения" нового диска, например, для RAID 5, контроллер может допускать работу с массивом. Но скорость работы массива в этом случае будет весьма низкой, как минимум потому, что даже при "линейном" наполнении нового диска информацией запись на него будет "отвлекать" контроллер и головки диска на операции синхронизации с остальными дисками массива.

Время восстановления функционирования массива в нормальном режиме напрямую зависит от объема дисков. Например, Sun StorEdge 3510 FC Array при размере массива 2 терабайта в монопольном режиме делает rebuild в течение 4.5 часов (при цене железки около $40000). Поэтому, при организации массива и планировании восстановления при сбое нужно в первую очередь думать именно о rebuild time. Если ваша база данных и бэкапы занимают не более 50 гигабайт, и рост в год составляет 1-2 гигабайта, то вряд ли имеет смысл собирать массив из 500-гигабайтных дисков. Достаточно будет и 250-гигабайтных, при этом даже для raid5 это будет минимум 500 гигабайт места для размещения не только базы данных, но и фильмов. Зато rebuild time для 250 гигабайтных дисков будет примерно в 2 раза меньше, чем для 500 гигабайтных.

Резюме

Получается, что самым осмысленным является использование либо RAID 1, либо RAID 5. Однако, самая частая ошибка, которую делают практически все - это использование RAID "подо все". То есть, ставят RAID, на него наваливают все что есть, и... получают в лучшем случае надежность, но никак не улучшение производительности.

Еще часто не включают write cache, в результате чего запись на raid происходит медленнее, чем на обычный одиночный диск. Дело в том, что у большинства контроллеров эта опция по умолчанию выключена, т.к. считается, что для ее включения желательно наличие как минимум батарейки на raid-контроллере, а также наличие UPS.

Текст
В старой статье hddspeed.htmLINK (и в doc_calford_1.htmLINK) показано, как можно получить существенное увеличение производительности путем использования нескольких физических дисков, даже для IDE. Соответственно, если вы организуете RAID - положите на него базу, а остальное (temp, OS, виртуалка) делайте на других винчестерах. Ведь все равно, RAID сам по себе является одним "диском", пусть даже и более надежным и быстродействующим.
признан устаревшим. Все вышеупомянутое вполне имеет право на существование на RAID 5. Однако перед таким размещением необходимо выяснить - каким образом можно делать backup/restore операционной системы, и сколько по времени это будет занимать, сколько времени займет восстановление "умершего" диска, есть ли (будет ли) под рукой диск для замены "умершего" и так далее, т. е. надо будет заранее знать ответы на самые элементарные вопросы на случай сбоя системы.

Я все-таки советую операционную систему держать на отдельном SATA-диске, или если хотите, на двух SATA-дисках, связанных в RAID 1. В любом случае, располагая операционную систему на RAID, вы должны спланировать ваши действия, если вдруг прекратит работать материнская плата - иногда перенос дисков raid-массива на другую материнскую плату (чипсет, raid-контроллер) невозможен из-за несовместимости умолчательных параметров raid.

Размещение базы, shadow и backup

Несмотря на все преимущества RAID, категорически не рекомендуется, например, делать backup на этот же самый логический диск. Мало того что это плохо влияет на производительность, но еще и может привести к проблемам с отсутствием свободного места (на больших БД) - ведь в зависимости от данных файл backup может быть эквивалентным размеру БД, и даже больше. Делать backup на тот же физический диск - еще куда ни шло, хотя самый оптимальный вариант - backup на отдельный винчестер.

Объяснение очень простое. Backup - это чтение данных из файла БД и запись в файл бэкапа. Если физически все это происходит на одном диске (даже RAID 0 или RAID 1), то производительность будет хуже, чем если чтение производится с одного диска, а запись - на другой. Еще больше выигрыш от такого разделения - когда backup делается во время работы пользователей с БД.

То же самое в отношении shadow - нет никакого смысла класть shadow, например, на RAID 1, туда же где и база, даже на разные логические диски. При наличии shadow сервер пишет страницы данных как в файл базы так и в файл shadow. То есть, вместо одной операции записи производятся две. При разделении базы и shadow по разным физическим дискам производительность записи будет определяться самым медленным диском.

Мы столкнулись с такой проблемой, что большинство серверов, приобретаемых пользователями наших программ, поставляются с дисковым массивом, сконфигурированным в уровень RAID 5. Впоследствии системные администраторы не хотят тратить время на переконфигурирование, или просто боятся что-то менять в уже настроенном и работающем компьютере. В результате производительность работы с базой данных, установленной на такой сервер, оказывается меньше, чем была на старом, который проработал на предприятии 3-4 года. Наверное, стремление поставщиков сконфигурировать дисковый массив именно в RAID пятого уровня можно объяснить желанием удивить клиента огромным размером дискового пространства. Сисадмины, в свою очередь, часто просто не обладают достаточными знаниями о том как работает RAID массив того или иного уровня. Цель данной статьи дать ответы на два вопроса:

Почему нельзя использовать RAID 5 для сервера базы данных?

Как оптимальным образом сконфигурировать RAID контроллер для размещения базы данных сервера Firebird?

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

Как работает RAID 5?

Рассмотрим упрощенную схему работы массива из четырех дисков. Один из дисков выделяется для хранения контрольной суммы. Три – доступны для размещения данных. На рисунке ниже, диски с полезной информацией названы A, B и C. Диск D хранит контрольные суммы.

Минимальный объем информации, который контроллер считывает или записывает на один диск, называется стрипом (strip). В параметрах большинства контроллеров, с которыми нам приходилось сталкиваться, указывается не размер стрипа, а размер страйпа (stripe) – блока информации, который распределяется на все диски массива. На рисунке ниже один страйп выделен более темным цветом:

Размер страйпа равен размеру стрипа помноженного на количество дисков в массиве. Т.е. в случае с четырьмя дисками и размером страйпа 64К, минимальное количество информации, которое контроллер способен записать или считать с диска, равняется 64 / 4 = 16К.

Контрольная сумма, которая попадает на диск D, рассчитывается по следующей формуле:

D = A xor B xor C

Благодаря транзитивности операции xor в случае выхода из строя одного из дисков с полезной информацией её можно восстановить xor-ированием данных оставшихся дисков, включая диск с контрольной суммой. Например, вышел из строя диск B.

При запросе блока информации с диска B контроллер восстановит его по формуле:

B = A xor C xor D

Сервер Firebird обменивается с дисковой подсистемой страницами данных. Оптимальный размер страницы в большинстве случаев составляет 8К, что намного меньше размера страйпа и в большинстве случаев даже меньше чем размер стрипа. Ситуации, когда на диск записываются последовательно расположенные страницы, также достаточно редки. Таким образом, если в нашем примере происходит запись информации на диск А, то контроллеру придется выполнить следующие операции:

1. Прочитать данные стрипов с дисков B и C. Две операции чтения.
2. Рассчитать новую контрольную сумму. Две операции xor.
3. Запись информацию на диск A и контрольную сумму на диск D. Две операции записи.

Итого, два чтения, две записи и две операции xor. Было бы удивительно, если бы при таком объеме работы, общая производительность не падала. Теперь становится очевидным почему RAID 5 не подходит для размещения файла базы данных.

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

Впрочем, как и у любого правила, у нашего - тоже есть свое исключение. Производительность дискового массива RAID 5 не будет снижаться, если размер энергонезависимой кэш памяти контроллера сопоставим с размером файла базы данных. Например, при размере кэш памяти в 512 Мб вполне можно использовать RAID массив пятого уровня для баз до 1-1,5 Гб. При условии, что сервер выделен только для работы с базой данных и не выполняет других задач.

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

Какой уровень RAID выбрать?

Если RAID 5 не подходит, то какой уровень выбрать для размещения файла базы данных? При количестве дисков меньше четырех единственным вариантом является зеркало (mirror) – RAID 1. Если в массиве от четырех дисков и больше, то оптимальным с точки зрения производительности и надежности является RAID 10 – объединение (RAID 0) нескольких зеркал (RAID 1). Иногда можно встретить написание как RAID 1+0. На рисунке ниже представлен массив RAID 10 из четырех дисков. Темным тоном выделены данные одного страйпа. Штриховка показывает дубликат этого страйпа.

Отметим так же, что если массив RAID 5 способен пережить потерю только одного диска, то RAID 10 из m зеркал по два диска выживет в случае потери от одного до m дисков, при условии, что откажут не более чем по одному диску в каждом зеркале.

Попробуем количественно сравнить массивы RAID 5 и RAID 10, в каждом из которых n дисков. n кратно двум. Примем размер читаемого/записываемого блока данных равным размеру стрипа. В таблице ниже приведено необходимое количество операций чтения/записи и xor-ирования данных.

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

Как настроить RAID контроллер?

Размер кэш памяти

Чем больше – тем лучше. Главное, чтобы контроллер имел батарейку (аккумулятор) для сохранения содержимого памяти при аварийном отключении питания. Во многих контроллерах батарейка не входит в стандартную поставку и ее необходимо заказывать отдельно. Без батарейки кэш на запись будет отключен.

Уровень RAID

RAID 10. Если количество дисков меньше четырех, то RAID 1 (зеркало). Почему? Читайте статью с самого начала.

Размер страйпа

Размер страницы базы данных умноженный на количество зеркал в массиве. Например, если в массиве 8 дисков, объединенных в четыре зеркала по два диска, а размер страницы базы данных равен 8К, то размер страйпа следует выставить в 8 * 4 = 32К.

Упреждающее чтение

Так как последовательное обращение к страницам базы данных весьма редко, да и сами они в результате фрагментации могут находиться в разных местах диска, упреждающее чтение следует отключить, или использовать режим adaptive (упреждающее чтение в случае последовательного обращения к двум подряд идущим страницам).

Политика кэша на запись

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

Резервный (spare) диск

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

ВведениеДублирование устройств и распараллеливание нагрузки – достаточно популярная идея на современном рынке персональных компьютеров. Энтузиасты нередко прибегают к созданию видеоподсистем, в которых используется две или большее количество графических карт, а те пользователи, которые нуждаются в непревзойдённой вычислительной производительности, зачастую делают ставку на многопроцессорные рабочие станции. Подобный подход можно применить и в отношении дисковой подсистемы: достаточно простой способ увеличения скорости её работы – это формирование RAID-массива из пары (или большего количества) жёстких дисков. Массивы уровня 0 (stripe) предполагают дробление всей сохраняемой информации на равные части, которые равномерно распределяются по нескольким физическим накопителям. В результате, за счёт параллельного чтения и записи данных сразу на несколько накопителей скорость работы такой системы по сравнению с одним диском может быть повышена в несколько раз.

Собственно, на заре распространения SSD потребительского класса были достаточно популярны рассуждения о том, RAID-массив из какого количества винчестеров сможет обеспечить производительность, сравнимую со скоростью флэш-накопителя. Конечно, сейчас эти времена уже безвозвратно ушли. Внедрение стандарта SATA 6 Гбит/сек и появление нового поколения контроллеров для твердотельных накопителей привело к тому, что скорости современных SSD ушли слишком далеко от того уровня быстродействия, который могут обеспечить традиционные магнитные диски. Однако возник другой не менее интересный вопрос: можно ли дополнительно увеличить производительность дисковой подсистемы, если в массив RAID 0 собрать несколько SSD?

Действительно, причин, по которым технология RAID не должна оказывать положительный эффект в случае с SSD, на первый взгляд не видно. Твердотельные накопители показывают хорошее быстродействие при работе с небольшими блоками данных, а чипсетные RAID-контроллеры предлагают прямую связь с процессором с пропускной способностью, вполне достаточной для получения скоростей, превосходящих SATA 6 Гбит/сек в несколько раз. Так что существенного увеличения производительности работы можно ожидать и от RAID 0 на базе SSD. Идея кажется особенно привлекательной ещё и потому, что она не сопряжена ни с какими дополнительными затратами. Общая ёмкость массива RAID 0 представляет собой сумму ёмкостей входящих в него накопителей, а стоимость SSD прямо пропорциональна их ёмкости. То есть, если для создания массива пользоваться «бесплатным» RAID-контроллером встроенным в чипсет материнской платы, то в итоге мы получим примерно такую же стоимость хранения гигабайта информации, как и в случае одиночного диска большего размера.

Учитывая кажущуюся привлекательность создания RAID 0 массивов из твердотельных накопителей, мы решили проверить их работу на практике. Компания Kingston любезно согласилась предоставить нам на тесты два 120-гигабайтных и один 240-гигабайтный SSD своей топовой серии HyperX, что и дало возможность прямого сравнения RAID 0 массива из двух дисков с одиночным накопителем аналогичного объёма.

Подробнее о Kingston HyperX SSD

Накопители серии Kingston HyperX SSD – это типичные решения на базе контроллеров SandForce второго поколения, нацеленные на энтузиастов. Они базируются на хорошо знакомом нам чипе SF-2281 и комплектуются 25-нм синхронной NAND-памятью производства компаний Intel или Micron. Проще говоря, накопители HyperX используют производительный вариант актуальной платформы SandForce и по своим внутренностям аналогичны таким популярным моделям как Corsair Force Series GT или OCZ Vertex 3.

Выделяет Kingston HyperX SSD в ряду подобных SandForce-накопителей разве только более броский дизайн корпуса, да и фирменная программа Toolbox, позволяющая просматривать различную информацию о диске, включая значение атрибутов S.M.A.R.T.

Утилита эта поразительно похожа на OCZ Toolbox с вырезанной функцией обновления прошивки (для этого у Kingston предлагается специализированная программа) и без возможности Secure Erase.

Как и у всех других накопителей с контроллерами SandForce, диски Kingston HyperX SSD с ёмкостью 120 и 240 Гбайт отличаются по производительности. В официальных спецификациях это отражается следующим образом:

Причина различий состоит в количестве используемых в составе SSD оконечных NAND-устройств. Так как 25-нм кристаллы MLC флэш-памяти имеют объём 8 Гбайт, 120-гигабайтный диск содержит 16 флэш-устройств, в то время как более ёмкая модификация укомплектована 32 устройствами. Учитывая, что контроллер SandForce SF-2281 имеет восьмиканальную архитектуру, накопители с разной емкостью вынуждены использовать для каждого канала технику чередования обращений к флэш-устройствам с разной кратностью. Так, в случае 120-гигабайтного SSD чередование двукратное, а в случае 240-гигабайтного накопителя – четырёхкратное. Большая кратность чередования гарантирует более высокую производительность, так как вместо ожидания готовности NAND-устройства после очередной операции контроллер имеет возможность перейти к обслуживанию следующего устройства. По сути это похоже на реализацию подхода RAID 0, но внутри накопителя, на уровне контроллера SandForce.

Тестовая система

Для тестирования SSD-накопителей мы собрали специальную систему, построенную на материнской плате с набором логики Intel H67, который, как известно, обладает парой SATA 6 Гбит/сек портов. Именно на этих портах мы и испытываем твердотельные накопители.

В целом, тестовая конфигурация включает следующий набор оборудования:

Процессор – Intel Core i5-2400 (Sandy Bridge, 4 ядра, 3.1 ГГц, технологии EIST и Turbo Boost –отключены);
Материнская плата - Foxconn H67S (версия BIOS A41F1P01);
Память - 2 x 2 GB DDR3-1333 SDRAM DIMM 9-9-9-24-1T;
Системный накопитель – Crucial m4 256 Гбайт (CT256M4SSD2);
Тестовые накопители:

Kingston HyperX 120 Гбайт (SH100S3/120G, прошивка 332);
Kingston HyperX 240 Гбайт (SH100S3/240G, прошивка 332);

Операционная система - Microsoft Windows 7 SP1 Ultimate x64;
Драйверы:

Intel Chipset Driver 9.2.0.1030;
Intel HD Graphics Driver 15.22.1.2361;
Intel Management Engine Driver 7.1.10.1065;
Intel Rapid Storage Technology 10.8.0.1003.

Проблемы конфигурирования RAID 0 из SSD

Для создания массива из SSD-дисков мы решили пользоваться стандартным RAID-контроллером, встраиваемым в современные наборы системной логики. Чипсетные SATA-контроллеры хорошо показывают себя в работе с одиночными SSD, и вполне подходят для наших целей, тем более что врождённая поддержка RAID уже есть в большинстве современных систем, то есть не требует дополнительных финансовых затрат.

Наша стандартная тестовая платформа основывается на LGA1155-процессоре и системной плате с чипсетом H67, SATA-контроллер которого имеет встроенную поддержку RAID-массивов. Для её активации необходима смена режима работы SATA-контроллера с AHCI на RAID в BIOS. Однако простое изменение соответствующей опции в BIOS Setup приведёт скорее всего к неработоспособности операционной системы, выражающейся в возникновении «синего экрана» на этапе загрузки. Причина состоит в том, что драйвер RAID в Windows по умолчанию отключен. Обойти эту проблему можно двумя путями. Либо заново, уже в RAID-режиме, переустановить Windows, и тогда необходимый драйвер автоматически включится при установке. Либо, непосредственно перед изменением настроек SATA-контроллера в BIOS, установить в 0 значение переменной Start, находящейся в системном реестре в ветке HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Iastorv, а затем переустановить драйвер SATA-контроллера Intel Rapid Storage Technology (RST) уже в RAID-режиме.

После включения режима RAID и внедрения в систему необходимых драйверов, можно переходить непосредственно к формированию массива. Он создаётся средствами драйвера Intel RST. В процессе потребуется лишь указать диски для включения в массив и его режим работы – RAID 0.

Всё остальное конфигурирование выполняется автоматически, но при желании можно изменить размер страйп-блока (по умолчанию – 128 Кбайт) и включить встроенное в драйвер кэширование операций записи (может приводить к потере информации при внезапных отключениях системы).

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

И хотя скорость одиночного Kingston HyperX SSD 120 Гбайт при работе с блоками данных растёт при увеличении размера блока, это ещё ничего не значит.

Драйвер Intel Rapid Storage Technology (RST) способен достаточно интеллектуально обращаться с очередью запросов, обеспечивая высокую скорость RAID 0-массива из SSD и при использования небольших страйп-блоков. В доказательство этого мы оценили базовые характеристики производительности RAID 0-массива из пары Kingston HyperX SSD 120 Гбайт с разными размерами страйпа.

Data stripe size = 4 KB:

Data stripe size = 8 KB:

Data stripe size = 16 KB:

Data stripe size = 32 KB:

Data stripe size = 64 KB:

Data stripe size = 128 KB:

Как показывают результаты AS SSD Benchmark, скоростные показатели массива со страйп-блоками разного размера достаточно близки. Тем не менее, зависимость скорости последовательных операций, а также скорости работы с мелкими блоками при высокой глубине очереди от размера страйпа прослеживается. Наилучшее сочетание показателей производительности массива достигается при использовании 32-килобайтных блоков, так что, очевидно, настройки по умолчанию не являются оптимальными. Так как меньший размер страйпа более выгоден при работе с небольшими файлами, в случае использования дисков, основанных на платформе SandForce второго поколения, мы рекомендуем использовать размер блока в 32 Кбайта. Именно с такой настройкой мы создавали и используемый в основной части тестирования массив.

При создании RAID-массивов важно иметь в виду и ещё одну немаловажную деталь. Как только массив сформирован, он начинает рассматриваться системой как единое целое, и прямой доступ к составляющим его накопителям становится невозможен. Это – достаточно неприятный момент, сулящий серьёзные практические неудобства. Имея RAID-массив из SSD дисков, вы не сможете ни обновить их прошивку, ни посмотреть параметры S.M.A.R.T., ни выполнить операцию Secure Erase. Но что самое неприятное, учитывая специфику такого массива, операционная система не сможет передать накопителям команду TRIM, посредством которой возможно эффективное противодействие деградации производительности SSD.

Производительность

Скорость случайного и последовательного чтения/записи «свежего» накопителя

Для измерения скорости случайного и последовательного чтения и записи мы используем тест CrystalDiskMark 3.0.1. Этот бенчмарк удобен тем, что позволяет измерять скоростные характеристики SSD-накопителей как на случайных несжимаемых данных, так и при использовании полностью сжимаемых шаблонных данных. Поэтому, на приводимых далее диаграммах приводится по два числа – максимальная и минимальная скорость работы накопителя. Реальные же показатели, соответственно, будут лежать внутри изображённых диапазонов в зависимости от того, как их сможет уплотнить контроллер SF-2281.

Заметим, что приведенные в этом разделе результаты тестов производительности относятся к «свежему» (FOB - Fresh Out-of-Box) недеградировавшему состоянию накопителя.

С точки зрения практических показателей быстродействия 120-гигабайтный SSD работает существенно медленнее своего 240-гигабайтного собрата. Тем не менее, RAID 0-массив из пары 120-гигабайтных дисков всё же превосходит по скорости единичный накопитель ёмкостью 240 Гбайт. Как видим, технология RAID 0 позволяет получить выигрыш в скорости линейных операций и при работе с небольшими блоками при использовании очереди запросов большой глубины. Обычные случайные же операции с 4-килобайтными блоками не ускоряются, более того, наблюдается даже некоторое замедление, обусловленное задержками на необходимость дополнительного арбитража.

Деградация и производительность в устойчивом состоянии

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

Например, если мы будем непрерывно записывать данные на флэш-накопитель, зависимость скорости записи от времени примет примерно следующий вид.

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

Впрочем, картина катастрофического падения скорости, показанная на графике выше, несколько искусственна и характерна лишь для случая непрерывной и безостановочной записи. В реальности же, находясь в состоянии покоя, контроллеры современных SSD-дисков частично восстанавливают производительность, предварительно освобождая неиспользуемые страницы флэш-памяти. На это направлено два ключевых алгоритма: Idle-Time Garbadge Collection (сборка мусора) и TRIM. Однако в случае с массивом RAID 0 ситуация осложняется тем, что операционная система не имеет прямого доступа к SSD, в результате чего технология TRIM не работает. В связи с этим вполне вероятна ситуация, что спустя какое-то время эксплуатации единичный диск может оказаться существенно лучше RAID-массива.

Никто не мешает проверить это предположение. Для получения картины деградации дисков и RAID 0 массива мы, основываясь на методике SNIA SSSI TWG PTS, провели специальные тесты. Их суть состоит в том, что мы последовательно измерили скорость операций записи в четырёх случаях. Вначале - для «свежего» состояния массива и накопителей. Затем – после полного двукратного заполнения информацией накопителей и RAID-массива. Далее – после получасовой паузы, дающей контроллеру возможность частично восстановить производительность накопителя за счёт операции сборки мусора. И в завершение – после подачи команды TRIM.

Измерения выполнялись при помощи синтетического бенчмарка IOMeter 1.1.0 RC1, в котором мы отслеживали скорость случайной записи при работе с выровненными относительно страниц флэш-памяти блоками объёмом 4 Кбайт с глубиной очереди запросов 32 команды. При тестировании использовалось заполнение псевдослучайными данными.

Деградация производительности – это не пустой звук, а реально существующая проблема. Как видим, скорость накопителей действительно снижается в разы. Причём, как это ни прискорбно, но сборка мусора у накопителей на основе контроллера SF-2281 практически не работает. Несмотря на то, что накопители с этой архитектурой имеют резервную область, составляющую примерно 7 % от общей ёмкости, это им совершенно не помогает. Возвращает производительность к более-менее нормальному уровню лишь команда TRIM. Однако так как для RAID-массивов она не работает, в конечном итоге одиночные накопители могут предложить куда лучшее быстродействие на операциях записи, чем составленный из них массив.

Всё это означает, что те скорости записи, которые были приведены на диаграммах в предыдущем разделе, отражают лишь незначительную часть общей картины. На самом же деле, после того, как SSD перейдут из свежего в использованное состояние, соотношение результатов коренным образом поменяется. Скорость записи в этом случае будет совсем иной: результаты её измерения бенчмарком CrystalDiskMark 3.0.1 приводятся на следующих диаграммах.

Как видим, в процессе использования скорость работы RAID 0 массива из SSD снижается до такой степени, что на операциях с 4-килобайтными блоками он становится даже медленнее одиночного 120-гигабайтного накопителя, производительность которого поддерживается на хорошем уровне командой TRIM. Так что в реальной жизни создание массива RAID 0 из SSD оправдывается преимущественно высокими скоростями чтения, которые не подвержены снижению по мере заполнения накопителя данными.

Тесты в Futuremark PCMark 7

Известный тест PCMark 7 включает отдельный бенчмарк для измерения производительности дисковой подсистемы. Причём, он имеет не синтетическую природу, а, напротив, основывается на том, как работают с диском реальные приложения. Этот бенчмарк воспроизводит настоящие сценарии-трассы задействования диска в распространённых задачах и замеряет скорость их выполнения. Причём, воспроизведение потока команд делается не сплошняком, а так, как это происходит в реальности – с определёнными паузами, обусловленными необходимостью обрабатывать поступающие данные. Результатом теста является общий индекс производительности дисковой подсистемы и показатели скорости в отдельных сценариях в мегабайтах в секунду. Заметьте – производительность в сценариях в абсолютном выражении получается относительно невысокой, так как в неё вносят вклад те самые моделируемые паузы между отдельными операциями ввода-вывода. Иными словами, то, что выдаёт PCMark 7, – это скорость дисковой подсистемы со стороны приложения. Такие величины дают нам информацию не столько о чистой производительности накопителей, сколько о том, какой практический выигрыш способен привнести тот или иной SSD при реальной работе.

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

Интегральный показатель PCMark 7 – прекрасный ориентир для тех потребителей, кто не хочет вдаваться в подробности и довольствуется простой иллюстрацией относительной производительности накопителей. И, если верить в полученные рейтинги, массив RAID 0 обладает в целом лучшим быстродействием, чем одиночный диск аналогичной ёмкости. Если принять во внимание, что большинство жизненных сценариев использования дисковой подсистемы предполагает преобладание операций чтения, полученные результаты кажутся вполне логичными и заслуживающими доверия.

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

Как видим, существуют сценарии, для которых RAID-массивы из SSD на платформе SandForce второго поколения противопоказаны. Очевидно, что такая картина наблюдается в случаях, когда от дисковой подсистемы требуется активная работа с небольшими порциями данных. В данном случае это сценарии Gaming и Windows Defender.

Тесты в Intel NAS Performance Toolkit

Intel NASPT – это ещё один основанный на использовании реальных сценариев тест дисковой подсистемы. Также как и PCMark 7, он воспроизводит заранее подготовленные типовые шаблоны дисковой активности, попутно измеряя скорость их прохождения. Данный бенчмарк вместе с PCMark 7 позволяет получить отличную иллюстрацию производительности дисковой подсистемы в реальных задачах. Также как и в предыдущем случае, тестирование мы выполняли с накопителями, находящимися в устоявшемся «использованном» состоянии.

Intel NASPT совершенно однозначно ставит на первое место по производительности RAID 0 массив, состоящий из пары 120-гигабайтных накопителей. Причём, скорость такого двухдискового массива по данным теста превосходит производительность одного SSD почти что вдвое. Впрочем, столь заметный успех технологии RAID способны омрачить некоторые результаты, полученные в индивидуальных подтестах.

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

Выводы

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

Создание массива RAID 0 – это один из традиционных путей для повышения производительности дисковой подсистемы. Этот приём вполне работает и для SSD, объединение в массив пары дисков действительно позволяет нарастить как линейные скорости, так и быстродействие операций над небольшими блоками с глубокой очередью запросов. Так, в процессе тестов нам удалось получить для массива поистине впечатляющие скорости последовательного чтения и записи, существенно превосходящие пропускную способность интерфейса SATA 6 Гбит/сек.

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

В итоге, RAID 0 однозначно выигрывает у одиночного диска лишь на линейных операциях, в то время как случайные запросы обнажают слабые места этого подхода. Иными словами, назвать массив RAID 0 более производительным решением, нежели одиночный флэш-диск, можно лишь с достаточно серьёзными оговорками. Впрочем, в большинстве тестов, основанных на сценариях реального использования дисковой подсистемы, массив показал всё же более высокое быстродействие. То есть, усреднённо RAID 0 себя оправдывает, тем более что он не требует никаких дополнительных финансовых затрат – стоимость за гигабайт в итоговой конфигурации получается одинаковой и для массива, и для одиночного диска.

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

Данная статья подготовлена Николаем Ведяшкиным, экспертом Сервисного центра компании «Инфосистемы Джет».

Представим себе ситуацию: мы добавили на сервер базы данных новый instance БД или новое задание резервного копирования (РК), подключили дополнительный сервер к дисковому массиву и во всех этих случаях обнаружили снижение его производительности. Дальше можно пойти разными путями.

Например, добавить сервер БД и перенести на него экземпляр базы данных, добавить резервных накопителей для ускорения РК, сделать апгрейд процессоров и т.д. Однако стоит помнить, что простое наращивание аппаратных мощностей наименее выгодно с точки зрения материальных и временных затрат. Намного эффективнее решать такие проблемы на уровне логики работы ИТ-решений.

Причины пробуксовки

Проблемы с производительностью массива часто связаны с тем, что при изначальном конфигурировании не учитываются его архитектура, принципы функционирования и существующие ограничения. Например, ахиллесова пята массивов старого поколения – относительно невысокоая пропускная способность внутренних шин – около 200 Мб/сек. Не так давно один из заказчиков попросил нас проанализировать работу его дискового массива и дать рекомендации по оптимизации. По факту массив был не загружен, при этом его скорость периодически оставляла желать лучшего. Анализ выявил неправильную конфигурацию: в целом в течение суток внутренние диски были загружены примерно одинаково, но пики нагрузки распределялись по ним неравномерно. В итоге одна из внутренних шин перегружалась. То есть массив «буксовал» из-за превышения максимально допустимого порога у одной компоненты. Наша рекомендация – переразбить его для равномерной загрузки внутренних шин – помогла увеличить производительность на 30%.

Ошибка может закрасться и при подключении серверов к СХД. Пример – неправильная конфигурация дисковой емкости, которая представляется хостам. Дело в том, что некоторые из современных массивов имеют ограничения по такому параметру, как очередь команд (Queue Depth, QD). Здесь стоит немного углубиться в историю. В стандарте SCSI-I SCSI-драйвер сервера должен был дождаться выполнения одной команды и только после этого отправлять следующую. Со стандарта SCSI-II и выше SCSI-драйвер может отправить SCSI-диску одновременно несколько команд (QD). Максимальное количество параллельно обслуживаемых SCSI-команд – одна из важнейших характеристик диска. Параметр IOPS (Input Output Operation per Second) показывает, сколько запросов (SCSI-команд) в секунду способен выполнить SCSI LUN. Получается, что QD и IOPS могут вступать в непримиримое противоречие друг с другом.

Вполне реальна ситуация, при которой характеристики ввода-вывода на стороне сервера неприемлемы, время отклика на запросы очень большое, а массив не нагружен. Причина кроется в – неправильной настройке очереди команд (выше допустимого) – команды зависают в буфере массива, пока не подойдёт их очередь на исполнение. На сервере же регистрируются большие service time.

Если же QD существенно ниже оптимального значения, производительность также будет хромать. При замечательном времени отклика и не загруженном массиве количество обрабатываемых им запросов будет очень маленьким. Виной всему – длительное ожидание в очереди перед отправкой запросов к СХД.

Ловим IOPS за хвост

Что предпринять, если время отклика зашкаливает, а массив не загружен? Или если просто хочется «выжать» из массива еще чуть-чуть?
Можно:

• заглянуть в настройки Queue Depth на сервере и сравнить максимально допустимую очередь команд с LUN массива. Скорректировать настройки;
• посмотреть на статистику с массива. Возможно, на нем копится очередь команд к LUN;
• разбить один LUN на несколько и соединить на хосте в stripe или хотя бы в конкатенацию в зависимости от конфигурации. Конкатенация полезна в том случае, если нагрузка распределится по всем LUN.
• выбрать размер stripe unit size на массиве и хосте так, чтобы типичная операция со стороны приложения нагружала как можно меньше физических дисков в массиве.

Рис. 1. Stripe Unit Size

Пример из нашего опыта: связка «сервер–массив» у заказчика не показывала заявленный уровень производительности. В результате анализа выяснилось, что серверу был дан очень большой (на несколько терабайт) LUN – работа приложений была неудовлетворительной, а сам LUN был перегружен по очереди команд. Мы рекомендовали разбить этот LUN на несколько и разнести виды нагрузки на разные тома. На сервере «крутились» 4 instance баз данных, в итоге один из них начал работать в 6 раз быстрее, другой – в 2 раза.

Больше не значит лучше

ИТ-специалисты компаний-заказчиков не всегда понимают, какой тип RAID лучше подходит для того или иного профиля нагрузки со стороны приложений. Всем известно, что RAID 10 надежен, устойчив к потере нескольких дисков и показывает хорошую скорость на случайных операциях. Не удивительно, что чаще всего выбирают именно этот, весьма дорогостоящий вариант. Однако если профиль нагрузки приложения подразумевает мало операций случайной записи и много операций чтения или последовательной записи, оптимальнее использовать RAID 5. На том же количестве дисков он может работать в 1,5, а то и в 2 раза быстрее. Одна компания обратилась к нам с просьбой улучшить характеристики дискового ввода/ввода для одного из ее приложений. Приложение создавало много операций чтения и незначительное количество операций записи. На массиве был сконфигурирован RAID 10, а из статистики было видно, что практически половина дисков в RAID-группе простаивает. С переходом на RAID 5 из точно такого же количества физических дисков работа приложения улучшить более чем в 1,5 раза.

Мы будем рады вашим конструктивным комментариям.

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

Накопителя Intel DC S3700 100ГБ, а также тестирование массива RAID-0 на базе двух подобных накопителей, где размер Strip"а был выбран по умолчанию, то есть 128 КБ, но чипсет С226 позволяет изменять данный размер. В теории размер страйпа/полосы должен оказывать влияние на производительность массива - большой strip выгоден для последовательных операций, малый - при работе с маленькими файлами. Но это в теории, проверим это на практике.

RAID-контроллер Intel в чипсете С226 позволяет выбрать следующие размеры полосы: 4, 8, 16, 32, 64 и 128 КБ. Протестируем все возможные режимы.

Тестовый стенд: Intel Xeon E3-1276v3, Supermicro X10SAE, Kingston DDR3-1600 ECC 8GB, Intel DC S3700

Детализация

Процессор: (HT on; TB on);
- Материнская плата: ;
- Оперативная память: 4x (KVR16LE11/8);
- Накопители: 2x ;
- ОС: .

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

CrystalDiskMark v5.1 x64;
- ATTO Disk Benchmark v3.05;
- PCMark 7 v1.4;
- PCMark 8 v2.3.

CrystalDiskMark (500MB)

На последовательную запись без глубокой очереди размер strip"a не оказывает особого влияния - результаты находятся в рамках погрешности, а с последовательным чтением картина несколько иная: наиболее производительным оказываются массивы с размером страйпа 128 и 32 КБ, а наименее - 64 КБ. То есть для последовательных операций чтения всё-таки наиболее предпочтителен большой размер страйпа.

Операции с 4-килобайтными блоками без глубокой очереди не позволяют реализовать весь потенциал как отдельного накопителя, так и RAID-массива. Но главное здесь то, что на скорость записи размер страйпа имеет влияние - 16- и 64- килобайтные полосы показывают наихудшие результаты при чтении, а при записи худший результат за 8-килобайтной. Посмотрим как ситуация изменится с использованием очереди.

Использование очереди уровняло всех - ощутимой разницы между режимами нет: разница между самым быстрым (128 КБ) и самым медленным (8 КБ) режимами составила около 3,5% (что примечательно, наибольшую производительность при последовательных операциях показывает режим с большой полосой, а наименьшую - с малой).

А вот операции с 4-килобайтными блоками показывают иную картину - наибольшую производительность показывает массив с 8-килобайтным страйпом, а наименьшую - 128 (разница составила 5%), но... это касается лишь чтения, операции записи оказались равнодушными к размеру страйпа. То есть в операциях последовательного чтения выгодно смотрится большой размер strip, а в операциях с блоками 4КБ - малый размер strip.

ATTO Disk Benchmark

Бенчмарк ATTO более информативен - он показывает производительность на разных блоках. И здесь можно наблюдать резкие провалы производительности: наиболее стабильные кривые без резких провалов показывают режимы с 4- и 64- килобайтными полосами. Примечательно, что в области от 16 до 128 КБ 64-килобайтная полоса показывает меньшую производительность, чем 4-килобайтная, но отыгрывается после 256КБ.

График записи имеет немного другую зависимость - самым стабильным оказывается режим с 128-килобайтной полосой, который показывает лишь небольшой провал и лишь в области выше 32МБ.

PCMark 7

Бенчамарк PCMark 7 отдает предпочтение 4-килобайтной полосе. Причем данный бенчмарк эмулирует определенные сценарии работы... то есть является менее синтетическим, чем АТТО.

Основной вклад в победу малой полосы внесли сценарии starting applications и Windows Media Center. Но это RAW-результат...

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

PCMark 8

PCMark 8 не заметил изменения параметров массива, уровняв всех в общем зачете. А замеренная пропускная способность отличается - наибольшая у 4-килобайтной полосы.

Заключение

Подводя итог... можно сказать, что в большинстве приложений, как ни странно, показал большую производительность массив с размером полосы 4 КБ. Но по большому счету разница не превысила 10%, то есть размер полосы нет такая уж и критичная величина. По крайней мере это можно сказать про сочетание чипсета C226 и двухдискового RAID-массива из накопителей Intel DC S3700 100 GB в выбранных бенчмарках.
Продолжение следует...
Остальные материалы по RAID-массивам на базе SSD - .