Stripe size какой выбрать raid 10
Обновлено: 03.07.2024
RAID системы, несмотря на весьма долгую по компьютерным меркам историю разработки и применения, продолжают совершенствоваться. Разработчики RAID контроллеров вне зависимости от сфер применения контроллеров часто добавляют новые возможности по их конфигурированию и настройке, но информации по их использованию часто недостаточно для понимания и, тем самым, применения. Как результат в подавляющем большинстве случаев RAID системы не реализуют до конца свои возможности, а пользователь вынужден ограничивать требования к RAID системам.
Мы попытаемся устранить эти "белые пятна" и дать возможность настройки производительности RAID системы в зависимости от тех задач, которые RAID система должна решать.
Разумеется, RAID системы используются для решения множества задач в самых разных областях. Но как бы ни было велико это разнообразие, с точки зрения RAID систем они используются всего в 2 взаимоисключающих ипостасях. Первая - работа с множеством небольших файлов, доступ к каждому из которых почти случаен для RAID контроллера. Примеров такого применения множество, это самая большая сфера деятельности для RAID систем - различные базы данных, web-серверы, почтовые серверы, файловые серверы и т.д. и т.п.
Вторая весьма широкая сфера применения - запись/чтение линейных потоков данных. Самый понятный и известный пример таких данных - видео- аудио- потоки. Действительно, работа с несжатым видео высокого разрешения, например, требует для данных 1920 x 1080/60i 4:2:0 скорости записи не менее 117 MB/s. В реальности скорость RAID массива должна быть раза в два больше для комфортной работы. Обработка оцифрованного кино или данных с видеокамер киноразрешения требует скоростей, превышающих 250 MB/s, а для комфортной работы скорость должна быть под 400 MB/s. Но, кроме кино и видео, существует еще ряд задач, требующих высокой линейной скорости записи. Одна из самых типичных - обработка геофизических данных. Здесь нередки требования к минимальной скорости записи от 200 MB/s. Таким образом, идея второго профиля понятна, это максимально возможная полоса пропускания RAID (Maximum throughput). Понятно, что производительность здесь измеряется в мегабайтах в секунду. Для тестирования производительности подойдет как IOMeter, так и ряд других программ.
Расскажем о настройках RAID, не забывая упоминать, для какого профиля что именно предпочтительнее делать.
Итак, наша задача выжать максимум производительности с RAID с помощью его настроек.
О важности этого параметра и о том, каким его выбирать, очень часто идут споры, в результате которых до сих пор окончательно истина так и не родилась, несмотря на популярность поговорки о полезности споров. Stripe size, параметр, обычно допускающий изменения даже в самых недорогих моделях RAID систем, означает размер блока данных, записываемый на каждый диск RAID массива в каждой stripe. Если, например, у вас RAID из 4 дисков, то задание stripe size в 64 kB принудит RAID контроллер записывать/читать данные блоками по 64 kB на/с каждый диск в массиве.
Исходя из здравого смысла, разумно полагать, что для работы с большими файлами в сотни мегабайт и более, т.е. для потоковых операций, следует выбирать максимально возможный размер stripe size, а для работы с множеством мелких данных выбирать если не минимальный размер, то близкий к минимальному. К сожалению, в данной ситуации надо руководствоваться не только здравым смыслом. Все дело в том, что разработчики RAID контроллеров отрабатывают и тем самым оптимизируют работу RAID практически для одного значения stripe size, и это значение обычно бывает либо 64 kB либо 128 kB.
Поэтому мы рекомендуем в том случае, если у вас нет достаточно большого времени на тестирование производительности RAID системы именно под вашу задачу, оставить значение по умолчанию. Ежели время есть, то только тестирование сможет выявить наилучший размер stripe size для ваших приложений . Разумеется, размеры stripe size меньше 32 kB лучше не тестировать, как правило, 16 kB или 8 kB слишком мало для любых задач.
Определяет размер блока, кратно которому процессор RAID контроллера будет читать/записывать данные в кэш-память контроллера. Этот параметр влияет на производительность очень опосредованно и мы рекомендуем выбирать его равным Stripe Size. Выбирать его значение большим, чем Stripe Size, кстати, запрещено в принципе.
Параметр Read Ahead multiplier (Множитель для упреждающего чтения) определяет, сколько секторов данных RAID контроллер должен заранее считать и положить в свою кэш-память, как бы упреждая запрос со стороны компьютера на считывание данных и тем самым ускоряя ответ на запрос. Правильное определение этого параметра целиком зависит от информации об используемом вами приложении. Понятно, что значение параметра должно быть, по крайней мере, не меньше, чем блок данных, запрашиваемый приложением. Если, например, вы знаете, что приложение считывает данные блоками по 16 байт, например, то значение Read Ahead multiplier надо выставить в 32.
Поскольку упреждать запрос от компьютера есть смысл только при последовательных операциях чтения, надо понимать, что при случайных обращениях к различным мелким данным на массиве, большОе значение Read Ahead multiplier может только замедлить работу системы. Поэтому лучше экспериментально проверить реакцию вашего приложения на изменение параметра, благо для этого не требуется заново инициализировать массив. Если вы настраиваете массив на максимальное количество операций ввода/вывода, то этот параметр правильнее отключать вообще с помощью Read Ahead Policy . Для работы с потоками, наоборот, значение этого параметра следует установить в диапазоне от 8 до 32, подобрав наилучшее значение экспериментально.
Этот параметр определяет, запускать или нет процедуру упреждающего чтения, и, если да, то каким образом. Обычно Read Ahead Policy может принимать три значения:
Always (Всегда) - упреждающее чтение выполняется всегда.
Adaptive (Адаптивно) - контроллер, обнаружив команды на последовательное чтение, сам включает (или выключает) упреждающее чтение.
Off (Выключить) - упреждающее чтение запрещается.
Рекомендуется здесь выбирать Adaptive, если RAID предназначен для решения широкого спектра задач и отдать тем самым принятие решения на откуп RAID контроллеру. Если RAID массив рассчитан на "переваривание" максимально возможного количества IOPS, то этот параметр обычно устанавливается в Off .
Read Log может в зависимости от конкретной модели RAID контроллера иметь другое название, но идея останется той же - параметр фактически позволяет оптимизировать упреждающее чтение в зависимости от количества параллельных запросов на чтение. Иными словами, здесь вы должны задать цифру, чуть большую количества одновременных запросов на чтение. При выборе этого значения надо учитывать, что количество пользователей (задач) всегда как минимум, меньше или равно количеству одновременных запросов, поскольку один запрос пользователя может породить несколько одновременных запросов от программы, использующей систему хранения.
Параметр будет использоваться, разумеется, только при включенном в Adaptive или Always режиме Read Ahead Policy .
Параметр Write cache periodic flush (Периодическая очистка кэш-памяти на запись) определяет, как часто контроллер будет принудительно записывать данные из кэш-памяти на диски, очищая тем самым кэш-память от данных на запись. Смысл этого параметра в попытке управления надежностью системы. Чем чаше содержимое будет сбрасываться на диски, тем меньше вероятность повреждения данных в случае нештатных ситуаций, таких как обрыв питания, например.
Но, если кэш-память системы хранения защищена батареей или есть хотя бы UPS на системе хранения, то вполне можно это время увеличить или вообще ввести 0, тем самым запретив принудительную очистку кэш-памяти. Это приведет к тому, что график записи данных будет практически "плоским", без небольших провалов на время очистки кэш-памяти. Разумно запрещать периодическую очистку кэш-памяти при сбросе видео высокого разрешения, поскольку это, возможно, предотвратит потерю кадров.
Этот параметр может также называться Synchronize Cache. В этом варианте его запрет означает запрет на периодическую очистку кэш-памяти.
Параметр определяет, после какого уровня заполнения кэш-памяти на запись следует принудительно записать содержимое кэш-памяти на диски и измеряется в процентах. Здесь резонно соблюсти тот же подход, что и в Write cache periodic flush - если система достаточно защищена от аварий, то можно увеличить этот процент до 90.
Один из самых интересных параметров, влияющих, как правило, на производительность RAID системы вне зависимости от профиля производительности. Alignment offset (Выравнивающий сдвиг)позволяет сместить реальный стартовый сектор (реальный, разумеется, с точки зрения операционной системы) на требуемое число секторов. Это позволяет исключить "раскалывание" stripe на части и тем самым минимизировать количество внутренних операций ввода/вывода в RAID массиве. Идея Alignment offset иллюстрируется рисунком ниже.
Оптимальное значение этого параметра зависит как от операционной системы, так и от размера stripe size. Для Windows рекомендованные значения 63, Для *nix OS (и Mac) 64, но возможны и другие значения, зависящие от производителя системы хранения и типа конкретной файловой системы. Кроме этого, следует подбирать и размер одного блока данных (allocation unit, cluster и.п.), которым оперирует операционная система, причем этот параметр следует подбирать с учетом основного приложения, использующего RAID. В наших экспериментах прирост производительности за счет сдвига достигал 10%.
Мы планируем по мере появления новой информации корректировать и дополнять эту заметку. Надеемся, что она поможет оптимально использовать возможности современных систем хранения данных.
WD Gold 2TB (WD2005FBYZ): Влияние Strip Size на производительность RAID10
Содержание материала
- WD Gold 2TB (WD2005FBYZ): Влияние Strip Size на производительность RAID10
- CrystalDiskMark
- ATTO Disk Benchmark
- Anvil's Storage Benchmark
- Заключение
- Все страницы
На страницах нашего ресурса уже были материалы, раскрывающие тему влияния размера полосы на производительность массива (здесь), но данные тесты проводились с массивами RAID0. Сегодня же наша редакция проведет тестирование с массивом RAID10 и ответит на вопрос - какой размер полосы является наиболее предпочтительным?
Intel RSTe рекомендует размер полосы (Strip Size) для массива RAID10 из четырех 2-терабайтных накопителей - 64КБ. Проверим насколько оправдан данный размер.
С результатами тестирования WD Gold 2TB (WD2005FBYZ) можно ознакомиться по ссылке, также можно ознакомиться с результатами тестирования RAID10.
Тестовый стенд: Intel Xeon E3-1275v6, Supermicro X11SAE-F, Kingston DDR4-2400 ECC 16GB, WD Gold 2TB, WD2005FBYZ
- CrystalDiskMark v5.2.1 x64;
- ATTO Disk Benchmark v3.05;
- Anvil's Storage Benchmark v1.1.0.
Поскольку жесткий диск базируется на пластинах, то скоростные показатели носителя зависят в значительной мере от того, где находятся данные: чем ближе к внешнему радиусу пластины, тем выше скорость. То есть при наличии нескольких разделов на диске первый будет самым быстрым, а последний - самым медленным. Поэтому целесообразно измерять скоростные показатели как в начале диска, так и в конце - с этой целью массив был разбит на 5 разделов: первый тестовый раздел, промежуточный раздел для заполнения места, второй тестовый раздел, второй промежуточный раздел и третий тестовый раздел. Соответственно, тестовые разделы будут называться: Primary, находящийся в самом начале диска; Middle, находящийся примерно в середине диска; и Final, находящийся в конце диска.
Методика тестирования заключается в следующем: протестировать массив RAID10 на базе WD Gold 2TB (WD2005FBYZ) со всеми возможными размерами полос (Strip Size), которые доступны штатному RAID-контроллеру чипсета Intel C236. Полученные результаты представлены на диаграммах и обозначены соответствующим образом: 4, 8, 16, 32, 64 КБ (тестируемый размер полосы).
RAID 10 не представляет большой сложности для понимания. Это страйп зеркал. Т.е. сначала диски объединяются в зеркала, а потом контроллер разбивает данные на части между зеркалами. Все предельно хорошо, пока количество дисков на один спан (span) равняется 2-м. И тут у многих людей случается конфуз. Что такое спан и почему туда можно добавлять диски. Как вообще начинает работать наш массив RAID 10, когда мы его собираем на большем числе дисков нежели 4?
Рассмотри сначала классический пример массива RAID 10 из 4-х дисков:
На картинке на контроллер поступили данные. Контроллер их поделил на куски с заранее известным размером. Этот размер задается при создании массива и не может быть изменен после. Даже если данные не удается поделить на куски указанного размера, контроллер дополнит их нулевыми байтами для того, чтобы сделать эту операцию возможной. Поэтому правильно выбирайте размер блока. Если вы планируете использовать массив для хранения больших файлов, стоит выбрать размер блока побольше, например 1 МегаБайт. Напротив, если вы храните много мельких файлов, эффективнее будет выбрать размер блока не больше 64 КилоБайт.
После того, как данные были разбиты на куски, а в нашем примере количество кусков кратно 2-м, контроллер записывает левую порцию на первый диск и дублирует ее на второй, правую на третий диск и дублирует ее на четвертом. Конечно, лево/право тут условно. Само собой контроллер оперирует другими понятиями.
Такой сценарий позволяет нам одновременно потерять два диска, но обязательно из разных групп. Если мы потеряем одновременно два диска из одной группы, мы потеряем левую или правую часть данных целиком.
Дальше больше. Что если у нас не 4, а скажем 6 дисков? Смотрим рисунок:
В данном примере поступающие данные делятся уже на три равные части. При таком сценарии массив позволяет нам потерять 3 диска одновременно из разных групп. Можно собрать RAID 10 с зеркалом из 3-х дисков и двумя страйпами? Нет. Зеркало всегда (ВСЕГДА) собирается только из 2-х дисков.
Т.е. все тоже самое, только количество кусков, на которые контроллер будет разбивать данные увеличилось до 4-х. Такой сценарий позволяет нам потерять одновременно 4 диска из разных групп.
И вот наконец пример со спаном. Также 8 дисков:
По сути мы вернулись к первому сценарию. Контроллер разбивает данные на две равный части и дальше записывает левую порцию на диск 1 и дублирует на диск 2, а правую порцию на диск 3 и дублирует на диск 4. А как же диски 5,6,7 и 8, спросите вы? Все просто, они ждут пока первая очередь заполнится. В этом и суть спана. Он логически объединяет диски, увеличивая их объем.
В примере выше диски слева являются частью одного спана, а диски справа другого. При этом диски по прежнему зеркалируются в группах по 2. Т.е., внимание, группа != (не равняется) спан. Если мы еще не перешли границу первого зеркала, то мы можем потенциально потерять одновременно до 6-ти дисков. Но лучше бы вам на это не надеяться. Придерживайтесь теории о том, что потерять одновременно можно по-прежнему только 4 диска из разных групп зеркал.
__________________________________
Нужен лайк👍! Больше про сетевое администрирование - на моем канале . Подпишись!
Цель данного тестирования — выяснить, с какой реальной скоростью смогут работать виртуальные машины в raw файловых образах, если разместить их на 4-х производительных SSD-дисках. Тестирование будет производится в 32 потока, чтобы приблизительно создать условия работы реального гипервизора.
Замеры будем производить при помощи инструмента fio.
Для mdadm+ext4 были выбраны опции --buffered=0 --direct=1. ZFS не умеет работать с этими опциями, поэтому ожидается, что результат ZFS будет несколько выше. Для сравнения я также отключу эти опции в одном из тестов и для варианта с mdadm.
Мы будем проводить тест с файлом размером в 10ГБ. Предположительно, что этого размера достаточно, чтобы оценить производительность файловой системы при выполнении рутинных операций. Разумеется, если увеличить объем тестовых данных, то общие цифры по всем тестам будут значительно ниже, так как мы сведем на нет все дополнительные средства кеширования и предсказания на файловых системах. Но такой цели нет. Нам нужны не сухие цифры синтетического тестирования, а что-то более приближенное к реальной жизни.
В качестве тестового стенда используем следующую конфигурацию:
Производитель:
Supermicro X9DRT-HF+
Процессоры:
2x Intel® Xeon® CPU E5-2690 0 @ 2.90GHz C2
Техпроцесс — 32 нм
Количество ядер — 8
Количество потоков — 16
Базовая частота процессора — 2,90 ГГц
Максимальная турбо частота — 3,80 ГГц
Кэш 20 МБ SmartCache
Скорость шины — 8 GT/s QPI
TDP — 135 Вт
Оперативная память:
16x 16384 MB
Тип: DDR3 Registered (Buffered)
Частота: 1333 MHz
Производитель: Micron
Дисковый контроллер:
LSI SAS 2008 RAID IT mode
Твердотельные диски:
4x 1.92Tb SSD Sandisk CloudSpeed ECO Gen. II
SSD, 2.5", 1920 Гб, SATA-III, чтение: 530 Мб/сек, запись: 460 Мб/сек, MLC
Заявленный IOPS произвольного чтения/записи 76000/14000 IOPS
Время наработки на отказ 2000000 ч.
Версия ZFS:
v0.7.3-1
Планировщик IO:
Тестовый инструмент:
fio-2.16
Параметры сборки массивов
Под arc выделено 1/4 всей памяти или 52 ГБ
Результаты
В тесте на чтение явно видно влияние буфера ARC на работу файловой системы ZFS. ZFS демонстрирует ровную и высокую скорость во всех тестах. Если выключить --buffered=0 --direct=1 скорость на mdadm raid10 + ext4 по ZFS оказывается в 3 раза медленнее и в 10 раз медленнее по части задержек и IOPS.
Наличие дополнительных дисков в zraid не дает существенного прироста скорости для ZFS. ZFS 0+1 — это так же медленно, как и zraid.
Вот тут ARC никак не спасает ZFS. Цифры наглядно показывают положение дел.
Опять же, буферы помогают ZFS давать ровный результат на всех массивах. mdadm raid6 явно пасует перед raid5 и raid10. Буферизированный и кэшированный mdadm raid10 дает вдвое лучший результат через все варианты на ZFS.
Картина аналогичная и по случайному чтению. ZFS не помогают его буферы и кеши. Он сливает со страшной силой. Особенно пугает результат одиночного диска на ZFS и в целом результаты по ZFS отвратительные.
По mdadm raid5/6 все ожидаемо. Raid5 медленный, raid6 еще медленней, а raid10 примерно на 25-30 % быстрее одиночного диска. Raid10 с буферизацией уносит массив в космос.
Выводы
Как всем известно, ZFS не быстр.
Он содержит десятки других важных возможностей и достоинств, но это не отменяет того факта, что он существенно медленнее, чем mdadm+ext4, даже с учетом работы кешей и буферов, систем предсказаний и так далее. По этой части неожиданностей нет.
ZFS версий v0.7.x не стал существенно быстрее.
Возможно, быстрее чем v0.6.x, но далек до mdadm+ext4.
Можно найти информацию, что zraid/2 — это улучшенная версия raid5/6, но не по части производительности.
Использование zraid/2 или 0+1 не позволяет добиться более высокой скорости от массива, чем одиночный диск ZFS.
В лучшем случае, скорость будет не ниже или совсем немного выше. В худшем, наличие дополнительных дисков замедлит общую скорость работы. Raid для ZFS — это средство повышения надежности, но не производительности.
Наличие большого ARC не позволит компенсировать отставание ZFS по производительности относительно того же ext4.
Как вы можете увидеть, даже буфер размером в 50 ГБ не способен существенно помочь ZFS не отставать от младшего брата EXT4. Особенно на операциях случайной записи и чтения.
Читайте также: