raid5/raid6 на дисках современных объёмов

На диски такого размера ставим Ceph или zfs, всё равно их либо под виртуалки, либо под хранение тонны снапшотов.

И… сталкиваемся с той же проблемой. Backfill/resilvering никуда не девались

1. " Как перестать бояться и попробовать lvm raid и zfs raid "

Для домашнего компа этого хватит. На СХД применяются те же принципы (в зеркале только то, что реально аллоцировано), но более удачно реализовано (у них trim/discard сразу позволяет контроллеру выбросить экстент из списка аллоцированных

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

2. ну и бекапы никто не отменял

О каком количестве дисков идёт речь?

С моими условными «до 4 на массив» я вполне успешно за ~10 лет переползал несколько раз raid1 -> raid5 -> raid6 -> raid1 и lvm поверх. В том числе с множественной пересинхронизацией в виду нехватки дисков. и особых проблем не видел.

lvm raid и zfs raid

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

С моими условными «до 4 на массив»

С таким условием raid6 смысла не имеет и никогда не имел, лучше зеркала делать. Более-менее целесообразность raid6 начинается с конфигурации 4 данных + 2 избыточные т.е. 6 дисков. raid5 от 2+1 до 4+1.

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

Это были 20тб диски с постоянной нагрузкой?

Для SOHO синхронная репликация на таких объёмах не оправдана и не нужна. Для дома и семьи: снапшот, send, receive. RTO = время раскатывания снапшота, но данные доступны сразу.

При этом, с типовым MTBF приличного диска ~ 10^6, даже в массиве из 5 дисков вероятность одновременного отказа в пределах часа двух дисков из них составляет 10^−11.

Масштаб проблемы под стать автору.

Рейд6 всегда будет рейдом6, хоть mdadm, хоть zfs, хоть аппаратный рейд

Только в части распределения данных по дисками и расчета контрольных сумм. У тебя и uefi до сих пор bios. В твоей криокамере есть режим разморозки? :)

Подними тестовую ВМ и пощупай разные варианты

• rhel 10: lvm
• rhel 10: вся документация по storage
• arch wiki: zfs

LVM применяется в unix почти всю жизнь unix. И на linux уже больше 20 лет точно

С таким условием raid6 смысла не имеет

верно, поэтому я и откатился на 2 raid1

Это были 20тб диски с постоянной нагрузкой?

Это были 2x12Tb + 2x18Tb. с «небольшой нагрузкой» в виде фоновой записи 2 камер, остальная нагрузка была специально выключена.

Вообще при пересборках raid всегда стараюсь максимально понизить нагрузку на диски

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

Ну и? Что ещё то надо? После замены диска его точно так же надо пересобирать в течение больше суток и точно так же в ходе этой пересборки может случиться/обнаружиться поломка ещё где-то, нет?

А, и еще. Если ты смотришь диски большого объема, то они скорее всего будут SMR («черепичная запись»)

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

Не знаю, сделали ли какой-то workaround для SMR, или они до сих пор остались декоративными

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

Нет :) Только аллоцированные экстенты. Если у тебя занято 50%, то ребилд будет только для этих 50%. Пустые сектора нет смысла синхронизировать

Не, про SMR все давно в курсе и ни для чего существенного их не берут. Не-SMR диски всё ещё производят, и даже много.

Если аллоцировано 50% то зачем было тратиться на такие большие диски, да ещё и с доп. рисками? Разве что занятый объём растёт с заметной скоростью и недавно был плановый апгрейд массива до х2 объёма.

Если ты смотришь диски большого объема, то они скорее всего будут SMR («черепичная запись»)

Не будет. Скорее всего, ТС будет смотреть на ентерпрайзные винты, а не консьюмерские.

Не-SMR диски всё ещё производят, и даже много.

Почти весь аля ентерпрайзный сектор.

Для малых дисков до 1 TB raid-5 (zraid) нормально (критичный для перехода размер вроде был где-то на ~1.4 TB, ЕМНИП).
Для средних дисков до 12 TB raid-6 (zraid2) нормально.
Для больших дисков от 12 TB raid-7 (zraid3) нормально.

Можно, конечно, найти более точные данные по накоплению ошибок, но принципиально это ничего не изменит.

PS:
Вспоминаю каждый раз про недельный ресильверинг 900 GB диска в raid-5 под нагрузкой, очень неприятно было…

А тут 20 TB, да он под нагрузкой может и месяц, а то и 2 ресильвериться… поседеешь на raid-5 и raid-6…
Может всё же zfs draid3 тут лучше? и пусть хоть полгода ресильвериться :)

https://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAID%20Howto.html

Это если поднимать там raid6. А если не поднимать?

Поинт был в том, что всё зависит от характера нагрузки. И бюджета.

Насколько мне известно SMR только до 8Т делали, всё что больше CMR. У меня 18Т WD по спекам CMR, по поведению на SMR тоже не похож.

Зависит от того, что там лежит

Если все 40 Tb занято тем, что нажито непосильным трудом, и все нужное, и ничего не смей трогать и выбрасывать, это печально

А если на те же 40 Тб живет десяток-другой ВМ или временные артефакты сборки, это уже совсем другое. То, что нужно - хранить с заданным уровнем raid’а. То, что не важно - держать в одной копии. и LVM, и вроде бы zfs это позволяют совмещать на одних и тех же дисках

Например, своп резервировать нет смысла. Диски с ОСью тоже. Данные - резервировать. Файлы контейнеров (кроме данных) - одна копия. volume’ы с данными - резервировать

Речь не про свапы и не про разное tmp, разумеется.

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

Это если поднимать там raid6. А если не поднимать?

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

Короче, мы raid6 избегаем, можем себе позволить.

Хоть что там поднимай. Что raid, что zfs, что ceph это способ создания избыточности хранения для сохранения доступности при выходе из строя дисков. При выходе из строя диска избыточность деградирует. При замене диска исправным избыточность надо восстановить, что подразумевает чтения всего объема утраченной информации с других дисков. Что в свою очередь создаёт дополнительную нагрузку на эти самые другие диски. Остаётся только повышать избыточность увеличивая стоимость хранения

Разница есть и она заметная. Дело в том, что если у тебя raid6, пересинхронизация потребует пересчёта контрольных сумм, причём эти суммы потребуются как для обеспечения пересинхронизации, так и для обеспечения собственно процесса работы. Это куда больше нагрузка на диски, чем просто взять готовое с зеркала. Именно поэтому падает производительность массива при деградации.

Если этих данных нет в кэше

Не знаю как у mdadm, а для lvm сделать кэш на ssd/nvme - вообще не проблема

Хватит ли этого кэша - уже зависит от типа нагрузки

Хватит ли этого кэша - уже зависит от типа нагрузки

20 Тб данных. Конечно, не хватит :-)

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

Разница то есть, потому что подходы разные. Если вы решили вспомнить про cpu-интенсивные операции, то давайте вспомним про scrub у цеф и zfs

То, что не важно - держать в одной копии. и LVM, и вроде бы zfs это позволяют совмещать на одних и тех же дисках

В пределах одной группы томов/пула:
LVM - да. ZFS - нет

Да, у ZFS есть в дополнении к mirror/raidz еще параметр copies, который можно задать на каждый dataset свой, но это мягко говоря не то. Потому что ЕМНИП никто тебе не гарантирует, что copies будут храниться на РАЗНЫХ нижележащих устройствах

Причём они не обязательно должны именно сломаться в этот момент, может быть в них например давно уже пачки бэдов, по их никто не читал (с большими дисками шансы этого тоже растут),

вообще по умолчанию раз в неделю Шапка чекает mdadm, процедура долгая и ее можно отключить, выкинуть из крона.

Я делал mirror на smr, ничего mdadm не выкидывал даже на большой тестовой нагрузке. Един. минус там был один очень большое время создания/восстановления, а так работало для дома сносно.

В ZFS и Ceph есть такие штуки как resilvering и deep-scrub. Они вычитывают регулярно все данные и если что то пошло не так то рекаверят с оставшейся копии. Ну и поскольку объекты там сравнительно небольшого размера - то соотвественно рекаверится быстро ибо вероятность что на другом диске будет побит другой блок который точно попадет в тот же объект весьма невелика. Ну и финалочка - в линуксе в mdraid и LVM RAID также есть фоновая проверка массива - вычитать всё и сравнить, да.

Если ты смотришь диски большого объема, то они скорее всего будут SMR

После 8ТБ большинство дисков внезапно (ц) становятся снова CMR. SMR сейчас в основном всякое «для чайников для дома - вот им 4ТБ, задолбаются забивать».

шанс того что во время пересборки слетит и второй (raid5) или даже третий (raid6) становится всё выше.

Я в эти игры больше не играю (после пары просто фееричных фейлов). Даже там где raid5/6 имел бы экономический смысл (PB volumes) у нас RAID10. Точнее linear-LVM over N HW RAID10.

А вы это к чему? Вы отвечали на сообщение, в котором описывается реакция на замену сбойного диска. Deep scrub тут не причем. Он про обнаружение silent data corruption. Resilvering тут как раз в тему, но процесс описанный далее никак с ним не соотносится

Зависит от кол-ва хдд, при 4х 6ка круче 10ки так как при выходе 2х хдд в 6 то пофигу каких. А если в 10 ке выйдут в одном (хз как правильно назвать) пуле то половина инфы туту.

Во долез до ближайшего сервака …

0 9 * * Sun root /usr/sbin/raid-check

это к вопросу:

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

raid6 начинается с конфигурации 4 данных + 2 избыточные 20тб диски

Интерестно, а куда и когда сливать full backup с такого массива? Если он забит и всё время загружен и ещё check раз в неделю делает...

Зависит от кол-ва хдд, при 4х 6ка круче 10ки так как при выходе 2х хдд в 6 то пофигу каких.

Это в теории. А на практике rebuild degraded raid5/6 существенно более сложен чем «оклонировать dirty zones выжившего диска пары», и можно нарваться на баги прошивки / драйвера и потерять весь массив при довольно штатной на бумаге ситуации. Что у нас и произошло, причём не на «наколеночном» raid, и на вполне себе reputable серверном железе.

check раз в неделю делает

А он чек за неделю точно успеет? Сдаётся мне на 20Тб дисках чек массива идёт несколько суток, под нагрузкой.

я делаю мдм зеркало и если что-то случается то не пересобираю его а делаю новое зеркало на новых дисках и копирую на него с живого из старого зеркала

поясню в чем смысл:

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

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

По поводу мдм тут логика крайне простая - кроме выхода из строя дисков есть вполне весомый шанс выхода из строя «сервера» - райд контроллера, материнской платы или еще чего-то что привяжет аппаратно-зависимый райд к подпрыгиванию с поиском запасного контроллера/полки.
С мдм - любой компьютер его примет и прочитает хоть с лайв-сд его загрузи линухом

и можно нарваться на баги прошивки

Ну так как повезет, можно нарваться на такие баги что все хдд улетят …

Помню у нас как то сломалась плата контроллера, кучу хдд поменяли во время переписки с сервисом ХП, потом приехал парнишка из ХП и заменил плату.

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

При синхронизации массив остаётся доступен все время

это в теории

на практике возможны варианты:

• у тебя массивы по много Тб потому что ты пишешь МНОГО - в таком случае при пересборке твой массив встанет раком ибо и синхронизироваться и продолжать писать МНОГО хдд не может физически ввиду того что МНОГО можно только линейно а синхронизация точно не будет линейна с новыми данными т.е. тебе в любом случае массив выводить из эксплуатации, однако можно попробовать писать много на новый массив параллельно копированию на него данных ибо тут есть шанс заиметь линейность в размен на фрагментацию
• у тебя массивы по много Тб потому что ты читаешь МНОГО - в таком случае ты не можешь продолжать читать с «живого» диска параллельно копированию на новый массив так же как и читать параллельно синхронизации ибо аналогично это будут не линейные операции. но если у тебя есть механизм црц на данных или фс или еще чего то ты можешь продолжать эксплуатировать живой диск паралелльно копируя данные на новый массив с деградировавшего - это позволит тебе перенести 99% данных быстро и вывести из эксплуатации массив на время переноса только дефектной информации
• у тебя долгое хранение с малым темпом записи - просто переткни запись на новый массив и копируй на него старое параллельно

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

Не знаю, мне про такие массивы страшно думать :) Но, так, не успеет за неделю, ведь следущий check ведь просто не начнётся, пока старый не завершится, значит будет проверка раз в две недели.

имея физическую деградацию одного из дисков шанс на деградацию его брата в обозримом будущем

Не знаю как сейчас, раньше мне такое очень редко встречалось. У SSD может быть, а у НЖМД разве что из-за багов прошивки.

То есть было, что выход из строя одного НЖМД давал повод заменить все диски. Всё одно с массивом возиться, так повод на большую ёмкость перейти, а то за 5-7 лет эти уже устарели. Но потом эти, отработавшие много лет в массиве НЖМД ещё где-то мучались, работали и дохли на заметно разном числе часов или вобще убирались в сейф, никому не нужен 36 Гб SAS...

По хорошему, 20Тб нужны когда нужны очень большие объемы, и если брать хдд менее 20Тб то нужный объем просто не влезет в сервер-полку. Ну там 12 хдд по 20Тб.

А если весь объем нужен только 20-40тб то (по моему мнению) лучше его набрать из хучи хдд меньшего объема. И дешевле и быстрее будет работать и менять будет быстро.

А если весь объем нужен только 20-40тб то (по моему мнению) лучше его набрать из хучи хдд меньшего объема. И дешевле и быстрее будет работать и менять будет быстро.

Дешевле не будет. HDD на 16 и 20 ТБ сейчас самые дешёвые по цене в рублях за терабайт. 24 и больше или 12 и меньше — уже дороже выходят. Но да, больше дисков могут положительно сказаться на надёжности и скорости в некоторых случаях.