Хорошо известно
Хорошо известно, что RAID-6[3]значительно медленнее RAID-1. Многие сейчас вдумчиво покачали головами, мол да, разумеется, в шестом пенальти на запись равно шести, а в десятом двум, это же в три раза меньше IOPSов. Некоторые даже вспомнят, что расчет двух четностей - задача нетривиальная, требующая сложных и "дорогостоящих" вычислений.
"По сравнению с RAID 10 и RAID 5 технология RAID 6 представляет собой уровень RAID с самой низкой производительностью. Хотя при нормальных условиях скорость чтения для всех этих уровней примерно одинакова, продолжительность записи сильно отличается."
"...повысив надежность, данный массив существенно потерял в производительности настолько, что многие поставщики не рекомендуют его использование кроме как для хранения холодных данных."
Ну да. Такое.
Ожидания
"Что делает RAID-контроллер, когда RAID-контроллер делает запись"
© Х.Мураками
А делает контроллер вот что:
Write Penalty |
RAID-0 |
RAID-1 |
RAID-5 |
RAID-6 |
1 |
Записать данные |
Записать данные |
Считать данные |
Считать данные |
2 |
Записать данные еще раз |
Считать четность |
Считать четность №1 |
|
3 |
Записать данные |
Считать четность №2 |
||
4 |
Записать четность |
Записать данные |
||
5 |
Записать четность №1 |
|||
6 |
Записать четность №2 |
NB: Четность №1 != Четность №2
Если второй блок четности будет копией первого, то RAID-6 не сможет пережить отказ двух дисков. Ведь потеряв два бита данных невозможно восстановить их с помощью одного бита четности, пусть и продублированного. Поэтому в RAID-6 четность считается довольно хитрым образом.
Understanding RAID-6 With Junior High Math (oracle.com)
тут описан P+Q, один из возможных методов реализации RAID-6, но есть и другие, такие как двойная четность, например
Запись в RAID идет блоками фиксированного размера, стрипами[4]. Стрипы одной RAID-группы образуют страйп. Стрипы в страйпе "складываются" специальным образом, что дает в результате блок четности. Изменение стрипа порождает необходимость перерасчета четности. А для этого нужно считать старую четность, считать старые данные, "вычесть" старые данные из старой четности, "прибавить" к ней новые данные, и записать измененные блоки обратно.
Вот вам и шесть операций вместо одной.
Про стрипы и страйпы
Оба слова, стрип (strip) и страйп (stripe), переводятся на русский как "полоска". Но есть нюанс. Полосы на флаге России - это страйпы. Если же флаг порезать на три цветные части, то страйпы станут стрипами.
УК РФ ст. 329, Надругательство над Государственным гербом Российской Федерации или Государственным флагом Российской Федерации наказывается ограничением свободы на срок до одного года, либо принудительными работами на тот же срок, либо арестом на срок от трех до шести месяцев, либо лишением свободы на срок до одного года.
Честно, это знание никак не облегчает понимание терминологии RAID, даже для носителей языка. Особенно тяжело китайцам.
-- У нас есть 14 несовместимых между собой стандартов, нужно изобрести один универсальный!
(через некоторое время)
-- У нас есть 15 несовместимых между собой стандартов!
HP |
HP/HPE |
DELL/EMC |
Huawei |
|
Блок |
stripe |
strip |
strip |
data block |
Размер блока |
stripe size |
strip size |
strip size |
stripe depth |
Набор блоков |
full stripe |
stripe |
stripe |
stripe |
Количество блоков в наборе |
set size |
set size |
- |
configuration |
Количество блоков в наборе |
- |
- |
stripe width |
- |
Получается, что при заметной доли операций записи RAID-6 будет всегда медленнее своих конкурентов. Ощутимо медленнее. Логично? Логично.
Реальность
В реальности производительность RAID1, RAID5 и RAID6 на одном и том же наборе дисков зачастую оказывается довольно близкой, и вот по каким причинам[5]:
Операции чтения и записи в массиве происходят параллельно (данные и четность);
Операции записи могут быть отложены (хост получает подтверждение уже после попадания данных в кэш);
Кэширование, откладывание записи и параллелизация операций (и/или просто удачное совпадение размеров блока) дают возможность работать "полным страйпом";
Технологии "распределенного RAID" позволяют лучше распределять ввод-вывод по дискам.
В качестве примера рассмотрим что-то полезное в быту. Например, имитацию операции Merge в Veeam B&R на одном и том же наборе дисков, но с разным уровнем RAID.
Параметры теста
IO pattern:
random 50/50;
block size 512KB, full random fill;
alignment 4KB;
Backend:
24x6TB NL-SAS
Название массива говорить не буду, этo не рекламный пост, сравнимые цифры можно получить на любой entry-level железке от нормального вендора.
Формулы[7] обещают, что RAID1 будет на 28% быстрее (что само по себе не особо и круто) и это даже без учета сложностей расчета четности:
Functional IOPS = (Raw IOPS * Write % / RAID Penalty) + (Raw IOPS * Read %)
Raw IOPS = Disk Speed IOPS * Number of disks
А на практике разница исчезающе мала, всего около 5%[6] (нагрузка в обоих случаях уперлась в производительность backend, т.е. единичных дисков):
RAID10 |
RAID6 |
|
IOPS |
39 |
37 |
Bandwidth (MB/s) |
20 |
19 |
Latency (ms) |
25 |
27 |
Про окно бэкапа
Отсюда следует, что при восьмичасовом окне мерджинга (рабочий день, когда задания резервного копирования точно не выполняются) и с описанным массивом в роли точки хранения резервных копий, можно позволить себе минимум (без учета сжатия/дедупликации) 500ГБ новых данных в сутки.
Выводы делайте сами.
Оговорки
Я знаю, что такое worst case. Я даже видел вживую один массив, честно собранный в расчете на worst case. В нем было три слоя: SSD, SAS и NL-SAS, а так же лицензия на автотиринг. И, когда этот автотиринг включили, обнаружилось, что данные НИКОГДА не покидают слой NL-SAS. Им и так хорошо. Вот это по настоящему worst case был.
Я знаю, что RAID10 всё равно быстрее. И иногда критично быстрее.
Везде в тексте статьи под RAID1 и RAID6 подразумевается их расширение до RAID10 и RAID6+ в том или ином виде.
В тексте используется терминология, принятая в DELL и HPE.
Вопрос скорости восстановления тут не затрагивается, хотя и он решается, благодаря распределенному RAID (когда spare-диск физически отсутствует, а его ёмкость распределяется по всем дискам в пуле).
При произвольной 100% записи блоком 64к разница заметнее, но и там преимущество RAID10 составило всего 20% против расчетных 300%.
Возможно корректнее было бы сделать расчет для каждой RAID-6 группы в массиве и сложить результаты вместе, но так никто не делает.
Комментарии (27)
bvbr
25.11.2021 19:33+1Хотите убить производительность RAID6 - пишите в него рандомно мелкими (меньше страйпа блоками)
в остальных случаях производительность из-за кешей и записей полными страйпами страдает не так сильно.
современное железо может считать четности очень быстро и кешей имеет достаточно, чтобы в общих случаях не ронять производительность слишком сильно.
основная современная проблема - это именно ребилды массивов при замене диска.
за последние 10-15 лет объёмы дисков выросли в десятки и более раз, а скорость чтения/записи - максимум в разы
это сделало время ребилда неприлично большим и шансы того что в это время откажет следующий диск в массиве неприлично высокими.
greefon Автор
25.11.2021 19:50См. оговорку #6, размер стрипа во всех случаях 128к
См. оговорку #5
bvbr
25.11.2021 20:27>#6
попробуйте писать блоками 4KiB, и если у вас нет большого кеша на запись все станет заметно хуже (4KiB - до сих пор defaul block size для большинства файловых систем)
>#5
это важный пункт и если его не рассматривать, то можно больно удариться
уже давно производительность RAID5/6 - это не главная претензияgreefon Автор
25.11.2021 21:56>#6
Сначала "пишите мелкими (меньше страйпа) блоками", теперь блоками по 4KB, что дальше, Transaction Logs MS SQL с блоками от 512 байт? Сразу анекдот вспомнился:Прислали лесорубам бензопилу чтобы валить лес. Все стоят вокруг - смотрят. Положили доску:
-Р-р-р-р-р, - сказала бензопила.
-У-у-у-у, блин, - сказали лесорубы.
Положили бревно:
-Р-р-р-р-р, - сказала бензопила.
-У-у-у-у, блин, - сказали лесорубы.
Положили бетонный столб:
-Р-р-р-р-р, кха-кха-бздык, - сказала бензопила.
-Ага, блин, - сказали лесорубы и пошли валить лес двуручными пилами.
Если серьезно, мы говорим про массивы, кэш на запись там есть всегда. И, относительно размера стрипа и даже страйпа, кэш большой. А есть массивы, который используют фиксированный размер стрипа в 4КБ и вы его не испугаете.
Переполнение кэша - тот самый worst case из оговорки №1 и означает это просто некорректный сайзинг, или использование инструмента для того, для чего его использовать не нужно. Никто не ставит себе целью "убить" тот или иной RAID, интереснее найти рациональное решение задачи.
>#5
Хотите отдельно про распределенные RAID расскажу в отдельном посте и как они помогают с проблемой долгого ребилда?bvbr
26.11.2021 05:43Запись блоками в 4К - один из самых распространённых use case в этом мире)) что касается Transaction Logs MS SQL - это официально рекомендуют хранить на дисках с allocation unit size 64к (хотя там тоже есть нюансы) )
peace, без обид, но сейчас эта статья выглядит как "говорят что RAID6 тормозит, смотрите, а у меня не тормозит" заканчивается многозначительным "выводы делайте сами" и кучей оговорок
Хотите расскажу
Да, хочу))) Думаю, что статья "RAID-1 vs RAID-6 в мире крови, пота и боли" с описанием того, почему полученные результаты расходятся с теорией, подводных камней и как с ними бороться была бы весьма занимательной и полезной
greefon Автор
26.11.2021 11:02сейчас эта статья выглядит
Как раз такого отношения хотелось избежать, обращая внимания последовательно на исходный посыл о "пенальти", потом объясняя, что даже в чистом виде на обычных нагрузках этот "пенальти" не так уж и ужасен, и в конце концов на живом примере показав, что инженеры знают о слабых местах RAID6 и давно научились их компенсировать. И практический пример в доказательтво.
Что касается "оговорок", смотрите, они все пригодились. Ведь это не извинения какие-то, а дополнительная информация, не совсем укладывающаяся в тему поста.Запись блоками в 4К - один из самых распространённых use case в этом мире
Это не совсем правда. В то время как больше половины IO операций действительно выполняются блоками <8КБ, больше половины ДАННЫХ пишется/читается блоками >64К. Т.е. картины со стороны объема данных и количества операций кардинально отличаются.
Transaction Logs MS SQL ... официально рекомендуют
Во-первых речь в рекомендациях идет исключительно об NTFS, а не о массивах. Во-вторых, нюансы, - это слабо сказано:
RStarun
25.11.2021 20:10Перед вводом в эксплуатацию, при наличии свободного времени, проверял нагрузочными тестами различные конфигурации и DAS и SAN. Raid 10 всегда выигрывал со значительным отрывом, минимум 50%. При соотношении R/W 70/30. Последний раз года 3 назад.
Может я что не так тестил, может что изменилось за последнее время.
greefon Автор
25.11.2021 21:58Возможно и то и другое, и третье (вам встречались ну очень простые массивы).
RStarun
26.11.2021 09:52Ок, значит можно исходить из того что для массивов до 30 дисков R10 по прежнему превосходит R6.
greefon Автор
26.11.2021 11:07Нельзя, потому что совершенно непонятно, что значит "превосходит".
Скажем если вы берете All-Flash массив, то его сырая производительность на 30 дисках упрется скорее всего в контроллер, вне зависимости от типа RAID. Зато RAID6 даст значительную экономию пространства и повысит надежность массива.
Если вы берете шпиндели под резервное копирование, как в примере выше, для вам опять же предпочтительнее будет R6, потому что дешевле, больше места, надежнее, а производительность на типовых операциях практически та же (особенно с учетом особенностей ReFS).
Сравнивать производительность RAID в отрыве от решаемой задачи в принципе некорректно. Более того, я уже и не помню когда в последний раз предлагал кому-то собрать диски в зеркало, если это не касалось довольно специфичных задач, ну и банальности типа загрузочных томовRStarun
27.11.2021 15:54Совершенно понятно в чем превосходит. Вы же в самой статье говорите о iops. Вот по iops в рамках latency и превосходит. Это не касается full flash на 30 дисках. Тут ничего сказать не могу, не тестил. Предполагаю что да, здесь упремся в другие узкие места.
Как от производительности мы перешли к "решаемым задачам"? Статья о производительности. Да, решение о конфигурации принимается исходя из задачи. И для бэкапов в большинстве случаев предпочтительней r6 и далее. Особенно для многоуровневых бэкапов, где уровнем выше лежит слой побыстрее.
На данный момент я встречаю много кейсов где в погоне за ёмкостью поднимают r5 - r6 и страдают потом из-за жадности.
greefon Автор
27.11.2021 16:13Как от производительности мы перешли к "решаемым задачам"?
Есть задача, смотрим на её паттерн, видим большой процент записи, вспоминаем "мантру" про пенальти в шестом рейде (в лучшем случае считаем по формулам), принимаем решение в пользу RAID10, например, жертвуя при этом бюджетом и надежностью. Какой смысл вообще в принципе говорить о производительности в отрыве от задачи?
Статья о производительности.
Внезапно, нет. Статья о том, что о RAID-пенальти знаете не только вы, но и разработчики железа. И последние давно научились минимизировать влияние пенальти на реальных задачах.
Ее можно было бы изложить так:
1. Всем известно, что у человека нет шерсти и тонкая жировая прослойка, что не позволяет ему длительное время переносить низкие температуры.
2. Вот смотрите, человек при такой то температуре должен издохнуть за столько то минут
3. И это все правильно и прекрасно, вот только легкая промышленность уже довольно давно наладила выпуск пуховичков и разных там меховых накидок, благодаря которым человек издыхает при указанной температуре гораздо медленнее
И если вы считаете, что это был рассказ про температуру, а не реклама меховых накидок, то я уж и не знаю как еще объяснить.Вот по iops в рамках latency и превосходит.
Нет, не всегда. Точнее превосходство зачастую гораздо ниже ожидаемого и находится в рамках допустимой погрешности. И это как раз зависит от задачи и от инструмента. А не только от цифры, обозначающей рейд.
Кроме того, превосходство может быть измерено так же по надежности, емкости, бюджету, и, комплексно, соответствию решаемой задаче
dartraiden
25.11.2021 20:24+1По сравнению с RAID 10 и RAID 5 технология RAID 6 представляет собой уровень RAID с самой низкой производительностью.
Зато RAID-6 не превращается в RAID-0 на время ребилда.bvbr
25.11.2021 20:45+1парные отказы дисков - не так редки как хотелось бы
выше уже писал, проблема в том что у современных дисков объёмы выросли чуть ли не в сотню раз, а скорость чтения/записи - всего в 2-3 раза, соответственно время перестроения массива пропорционально возросло, т.е. время которое массив находится в уязвимом состоянии стало важным фактором, которым опасно пренебрегать.
emashev
Хм, а для raid1 сейчас уже все контроллеры умеют читать данные параллельно с двух дисков? Я имею ввиду классический raid1 из двух дисков. Вроде даже mdadm не умел.
greefon Автор
Вы имеете ввиду "читать разные данные"?
emashev
Допустим есть база в raid1. Интересует - увеличивается ли производительность при чтении с ssd raid1 в сравнении с одиночным диском. Этот вопрос скорее не имеет отношения к статье, задал чисто из любопытства. Помню, что раньше были нюансы и где-то это работало, а где-то нет.
greefon Автор
Я не знаю, кто умеет, а кто нет. Читать разные данные с двух дисков в паре возможно, но требует отдельной очереди и кэша для реорганизации операций ввода вывода для каждой пары. Кроме того, раздельные операции чтения на шпинделях (не на ssd) технически могут занимать разное время (выполняться с разной задержкой), что в свою очередь повлечет изменение (рассинхрон) задержки при операциях двойной записи. Не уверен, что оно того стоит.
Попробую тесты сделать, проверим.
arheops
linux mdraid умеет чередовать чтение с дисков.
Использовать дешевые контроллеры вместо софтового рейда — плохая идея, имеет смысл только дорогие с батарейкой.
greefon Автор
Насколько я помню (поправьте меня, если не прав, желательно со ссылкой) в linux именно для RAID-1 mdadm не делает полноценный round-robin, а преимущественно использует первый свободный idle диск, которым в 90% случаев оказывается диск №1. А вот вырожденный RAID-10 из двух дисков с layout=far2 может, ценой некоторой потери скорости записи.
arheops
mdadm еще где-то с 12го года(ну могу ошибаться на пару лет) работает в режиме уменьшения задержек. Причем именно задержек, а не пропускной способности.
Тоесть если у вас есть два диска с iops 200, у вас будет 350+ iops на рейд1.
Если нагрузка в один поток — да, будет читать с одного диска. А вот второй поток уже будет прыгать и при 3-4потоках нагрузка будет более-менее равномерная.
Когда появилися SSD туда вписали и round-robin если хотя бы один из дисков в массиве — SSD.
У меня были диски которые пишут в смарт TotalLBARead и там видно хорошо, что количество чтений одинаково+-.
Собственно SSD всегда это пишут, ниже взял пару выводов для nvme дисков в raid1.
greefon Автор
спасибо
arheops
Вот типичная картина дисков NVME, которые никогда не стояли вне рейда1.
[root@vdb ]# smartctl -a /dev/nvme1n1|grep Write
Host Write Commands: 6,345,771,261
И да, там нету raid0 ну вот вообще. Настройки по умолчанию. Нагрузка низкая для этих дисков, потому первый получает больше iops. Но как видите, разница процентов 30.
Вот на новом сервере, еще более одинаково нагрузка распределена. И там и там размер дисков около 1Тб.
Host Write Commands: 1,714,962,112
[root@dbA tmp]# smartctl -a /dev/nvme1n1|grep Write
Host Write Commands: 1,726,974,923
[root@dbA tmp]# smartctl -a /dev/nvme1n1|grep Read
Data Units Read: 29,447,200 [15.0 TB]
Host Read Commands: 128,380,256
[root@dbA tmp]# smartctl -a /dev/nvme0n1|grep Read
Data Units Read: 35,767,640 [18.3 TB]
Host Read Commands: 223,398,731
greefon Автор
Очень странные цифры для дисков, находящихся в зеркале. Почему в первом случае запись отличается на треть? А во втором запись примерно равна, зато чтение отличается в два раза, разве это более одинаковое распределение нагрузки? Можете прокомментировать?
arheops
Во втором чтение в байтах и операциях отличается мало ;) (15vs 18). Оличается количество операций хоста. Возможно, разные диски?(проверил — одинаковы INTEL SSDPE2ME012T4). Или операции из кэша не считаются?
Почему отличается запись я не в курсе. Я же это не мониторю, вот взял первые два попавшиеся сервера и выдал вам с них данные.
Но в любом случае из данных следует, что чтение ведется с двух дисков.
Учтите, что это диски выданные датацентром, один мог быть не новый, к примеру.
greefon Автор
Если один диск может быть не новым и этим вы объясняете разницу в их показаниях, то как вы одновременно делаете вывод об одновременном чтении с двух дисков, если один из них опять же может быть не новым? Может быть все совпадения случайны? :)
arheops
Проверил, диски имеют одинаковое количество часов.
В первом случае я не помню, какая конфигурация была два года назад. Могло быть сначало поставлено на 1. Но он уже минимум года полтора стоит в рейде. Всего там 4500часов.
Во втором диски 100% новые и только в такой конфигурации стояли и так и было с инсталяции.