Для ЛЛ: RAID-5 совершенно не подходит для современных массивов из дисков на 5-10 Тб по нескольким причинам.
Вчера хорошие знакомые прислали ссылку на чат криптоаналитиков. Я очень удивился, поскольку криптовалюты от меня достаточно далеки, но - пошел, почитал. Оказывается, с одним человеком случилась беда, однако, по непонятным для меня причинам, он пошел жаловаться не в отдел технической поддержки согласно SLA, а в первый попавшийся чат.
Жалоба была интересная, цитата:
Вопрос MSA-шникам.
Есть MSA 2040 - голова и 3 полки.
Все разбито по разным пулам и отдано по FC 8 Gb.
Сдох диск в одной полке, отребилдился на GHS.
Все без замечаний, все ок, но на ряде томов - просадка по отдаче до 30 МВ\s, вне зависимости от пула.
Тома и распределены по разным дискам, но где-то задействованы диски из отребилдившейся полки и часть норм работает, а часть никак..
..
Началось после замены хромающего диска.
Групп по 5 на каждый пул. Группы в рэйд-5. В каждой группе штук по 8 дисков.
На каждом пуле по 5 vdg, каждая vdg из 8-ми дисков в 5-м рэйде.
Дальше дискуссия была не такая интересная, потому что главная проблема была понятна – это тот человек, который собрал R5, и пошел с проблемой в крипточат.
Почему RAID-5 на любых современных дисках – это плохо, хоть на SSD, хоть на механике.
Проблема 1, простая и понятная
Как все помнят, RAID-5 – это N дисков с данными и один диск с четностью (точнее, четность размазывается туда и сюда - RAID 5 consists of block-level striping with distributed parity.)
Как следствие, RAID-5 может пережить выход из строя 1 жесткого диска без потери данных.
Проблемы с R5 начинаются не при выходе из строя жесткого диска, а при ребилде.
Проблема номер 1
На любом современном контроллере все жесткие диски постоянно (или по расписанию) проходят фоновое обслуживание, scrubbing – то есть контроллер как-то проактивно пытается понять, умерли ли блоки на жестком диске, или нет. Однако, пытаться то он пытается, но не гарантирует.
И вот у нас 9 жестких дисков, пусть даже сконфигурированных по документации, со всей ее силой “the power of 2” , а не как у страдальца, цитата:
For optimal write sequential performance, parity-based disk groups (RAID 5 and RAID 6) should be created with “the power of 2” method. This method means that the number of data drives (nonparity) contained in a disk group should be a power of 2. See Table 2 for details. MAN page 18
и весь занятый объем этих дисков (или весь объем ?, я так и не изучил этот вопрос) начинает считываться со всех дисков, все и сразу.
Диски, зачастую, идут из одной партии, имеют одинаковый уровень наработки, в часах и .. и ваши шансы на то, что фоновая проверка не успела найти еще хотя бы один диск, с количеством плохих секторов больше предела SMART, резко возрастают. При этом у вас еще и резко возрастает нагрузка на чтение, поскольку рабочих операций никто не отменял, так что диски чуть больше двигают головками, чуть иначе вибрируют, чуть больше греются, и.
И вы не можете потерять еще один диск, но вы его теряете.
Raid 6 в таких случаях, кстати, не всегда помогает – падает и R6, только реже, а почему – будет написано ниже.
Это было не так критично, пока диски были 72-146-300-600 Гб и на 10-15 к оборотов, они зачастую успевали пройти ребилд на R5, но на 5-10 Тб диске 7200 – у вас будут неприятности, потому что:
Проблема вторая, математика и статистика
Поскольку дело связано с простой математикой, то ей в той или иной степени подвержена и механика, и SSD.
Давно (с 1973) существовала Shugart Associates, от которой осталось очень мало – она представила Shugart Associates System Interface, из которого к 1981 году вырос SCSI - Small Computer System Interface. Вся история нам не очень интересна, но все эти годы American National Standards Institute (ANSI) и InterNational Committee on Information Technology Standards (INCITS, pronounced "insights") боролись за звание дома высокой культуры быта и низкое число ошибок передачи данных – все эти CRC, Data Integrity и прочие достижения Technical Committee T10 вплоть до T10 DIF/DIX , но это другая история, а этот абзац здесть только чтобы похвастаться, что такая продвинутая нейросеть как я, может писать не только про самолеты и орбиты (с сахаром и без). СР!
Существует такое явление, как Unrecoverable read error rate, и его частота находится где-то в районе 1/100.000.000.000.000 – 1/100.000.000.000.000.000 , или, более понятным языком, где-то между 1/10^-14 для обычных пользовательских дисков (typical consumer grade hard drive ) до 1/10^-17 (Consumer SSD error rates are 10^16 bits or an error every 1.25PB. Enterprise SSD error rates are 10^17 bits ) – что означает, что для обычного диска (с его 1/10^-14) в 1 Тб - 1.000.000.000.000 байт (завели моду указывать не честные терабайты, а я страдаю) вероятность отказа на ребилде R5 при 9 дисках в массиве составит 47 %. Для R6 при тех же вводных – 20%. 20 % отказов, 80% успеха. Хороший повод собирать массивы из дисков поменьше.
Формула расчета тут, калькуляторы тут и тут.
Кстати, 1 из 10 массивов R6 из дисков с URE (Unrecoverable Read Error) с хорошим 1*10**(-15) на 10 дисков по 5 Тб тоже развалится, имейте в виду.
Для кассет (LTO) текущий показатель - 10^19, про что можно читать lto.org .
Очень важно внимательно читать раздел со звездочкой, там где пишут про запыление, температуру и влажность.
Про эту самую надежность (UER) уже писали на Хабре минимум 15 лет назад, в 2009 году, в комментариях, но все равно – пришло 15 лет, а кто-то собирает R5.
Не надо так.
Комментарии (116)
rPman
09.06.2024 19:15+2Все просто, выбери что то одно - надежно, быстро, дешево.
Хочется скорости, берешь 'дорогой' контроллер (хз какой) и raid1 mirror из трех дисков, и в момент rebuild контроллер сам перераспределит нагрузку таким образом, чтобы деградации не было. Очень жаль что такого функционала (хотя бы ручного указания) - нет ни в mdadm ни в zfs/btrfs.
По теме - если дисков много, не рекомендуется объединять их все в ОДИН большой массив. Лучше делать несколько небольших, например по 4-5 дисков. Тогда rebuild одного не затронет другую часть хранилища.
5exi
09.06.2024 19:15+11Судя по статье я счастливчик, у меня недавно ребилдился массив RAID6 из 24 дисков по 14TB и он это сделал. Долго конечно делал.
or an error every 1.25PB
1PB = 1024TB
По моему, в расчётах явно есть ошибка. У меня за 20 лет стажа вырвало только один раз RAID5 во время пересборки. Да такой шанс есть, если старые диски из одной партии, то ребилд может так нагрузить диски, что они не доживут, но об этом в статье и написано. Поэтому лучше такое заранее предвидеть и делать новый массив с дисками заранее.
ZFS по моему безумно дорогая идея с какими-то несоразмерными накладными расходами.
Sap_ru
09.06.2024 19:15+32Все подобные расчёты по какой-то удивительной причине исходят из того, что первая же неисправленная ошибка жёсткого диска приведёт к его немедленному и неустранимому отказу, В то время, как на самом деле речь идёт лишь о коррекции ошибок, а есть ещё и обнаружение ошибок. На практике ошибка будет обнаружена и всё закончится повторным чтением блока. Причём обнаружение ошибок есть ещё и на уровне RAID, и даже если ошибка прошла незамеченной на уровне диска, её заметит RAID и и исправит повторным чтением.
В результате уже лет 10 все подобные расчёты убедительно доказывают, что RAID5 работать не может в принципе, но он почему-то работает.
olegkrutov
09.06.2024 19:15Во время ребилда R5 ничего исправить не может, у него нет в этот момент избыточности.
red_dragon
09.06.2024 19:15+2Речь не про избыточность. А про то, что проблемный сектор диска, в подавляющем большинстве случаев, удаётся перечитать без ошибки.
romxx
09.06.2024 19:15А во всех остальных, кроме "подавляющего большинства"? Вы реально проектируете IT инфраструктуру хранения исходя из идеи "ну вдруг не накернится сразу, вдруг повезет?"
red_dragon
09.06.2024 19:15А я ничего не говорил про проектирование инфраструктур. Я лишь заметил, что вы неверно истолковали комментарий выше.
Что касается хранения данных с избыточностью, уж если Вам так интересно, то в той конторе, где я сейчас работаю, используется RAID 10. Раньше были ещё 50 массивы, но от них отказались, в силу меньшей производительности относительно 10.
Sap_ru
09.06.2024 19:15+1В реальной жизни у вас в любом случае в конечном итоге всё и всегда работает исходя из идеи "вдруг повезёт", так как вероятности отказов всегда ненулевые. У вас могут взять и сами испортится любые данные и само по себе произойти вообще любое действие в любой программе, так как у ECC в процессоре тоже имеет вероятность отказа. Вы можете обложиться бэкапами и резервированием, и всё равно обнаружить, что все акутальные данные потеряны. Просто потому, что две заряженные частицы пролетели там, где нужно. Вопрос лишь в вероятности этого драматического события.
Но на практике нужно ещё учитывать вероятность не просто отказа, а вероятность необнаружимого иили критического отказа. А у используемых контрольным сумм вероятность необнаружимой ошибки на несколько порядков ниже вероятности невосстановимой ошибки. Т.е. контрольная сумма не может исправить ошибку, но всё равно показывет её наличие.
В результате при расчёте полной вероятности на вероятность отказа диска накладывается очень небольшая вероятность ошибки чтения при восстановлении. А поверх этого нужно ещё и чтобы ошибка была необнаружимой или критической (отказ диска), что может случиться один раз на несколько тысяч ошибок при восстановлении RAID-5.
В результате неправильные расчёты показывают, что RAID-5 не может работать и должен сыпаться буквально при каждом втором восстановлении, а на практике с учётом всех вероятностей, беда случится только, что-то вроде, один раз на тысячу полных восстановлений и RAID-5 отлично работает.
Как следствие суммарная вероятность фатального отказа RAID-5 вполне себе соответствует вероятности отказа какого-либо другого элемента инфраструктуры и потому не является определяющим фактором.
kenomimi
09.06.2024 19:15На многих рейдах, особенно старых, любой ERROR в логе сразу валит массив в degraded. Дома было 5 sas дисков по 16тб и один из распространенных адаптеков - намучался и продал: смарт у дисков чистый, релоков ноль, но периодически в нагрузке лезет degraded с потерей случайного диска, как раз на ошибках чтения/записи. Проверяешь всю поверхность через HBA-адаптер - все отлично, нигде сбоев нет. Собираешь, работает пару месяцев, и хоба - опять degraded.
Контроллеров пачка была, менял - толку чуть. Покупатель поставил диски на рейд 2022 года, какая-то люто дорогущая модель - у него проблемы не всплыло - я рассказал ему о баге при продаже.
hogstaberg
09.06.2024 19:15+3за 20 лет стажа вырвало только один раз RAID5 во время пересборки
А сколько у вас, простите, всего было пересборок больших RAID5 за двадцать лет стажа?
FreeNickname
09.06.2024 19:15Спасибо, не знал про правило power of 2 и как раз собирался докупить 5-й диск для RaidZ2 :)
JustANickName
09.06.2024 19:15Это зависит от реализации. И описание про "power of 2" применимо именно к там, где написано (в данном случае документация на СХД MSA и родственников). Существуют реализации, где такого правила вовсе нет и 3+1 или 7+1 может быть наоборот рекомендованным размером для RAID5 из-за внутренних оптимизаций. Про zfs не скажу.
kilgor-trout
09.06.2024 19:15+20Расчёты полное говно (что ~50% больших пятых рейдов разваливаются при ребилде). Даже смехотворно, что кто-то всерьез такое накалякал.
p.s. и да, я это всё читал 15 лет назад от других фантастов. там ещё писали бред, что у всего raid5-массива скорость записи == скорости одного диска минус 30%. а у raid6 ещё минус 60. тоже бредни.
Sap_ru
09.06.2024 19:15+4Тут классическая ошибка в расчётах - одиночная ошибка диска приравнивается к его отказу.
olegkrutov
09.06.2024 19:15+1Есть диски raid edition, разница в параметрах прошивки с такими же, но обычными в том числе в том, чтоб скорей отдать ошибку наружу, а не копошиться с перечитыванием сектора.
Sap_ru
09.06.2024 19:15Перечитывание всё равно есть, только количество раз сильно меньше.
Но ОС и софт RAID тоже не дураки писали, а потому, если других вариантов восстановления нет, то всё равно будет сброс буферов и повторы чтения уже на высоком уровне.
atomnijpchelovek
09.06.2024 19:15А так же в том, что время на попытку считать сектор сильно ниже, чем у обычных. Диски raid edition так же сами не будут пытаться исправить ошибку, пока не получат сигнал от raid контроллера
pda0
09.06.2024 19:15+2Помню как читал тред на SO где народ долго и упорно искал людей, у которых эта ситуация произошла бы в реальности. Так и не нашли...
Sap_ru
09.06.2024 19:15Ситуация действительно происходит, но обычно видна только логам (ай-ай-ай, при пересборке RAID была ошибка и пришлось сбросить контроллер перечитать кусок диска_ или в худших случаях лечится, например перезапуском сборки RAID. Очень страшно (ай-ай-ай, у нас RAID с первого раза не собрался!!!), но исход всё равно успешен. Чтобы прямо совсем бесповоротно навернулся при пересборке, нужно быть сильно невезучим, и с тем уже успехом можно на одновременный отказ нескольких диском нарваться или ещё на какую редкую и страшную беду.
Grigory_Otrepyev Автор
09.06.2024 19:15Помню как читал тред на SO где народ долго и упорно искал людей, у которых эта ситуация произошла бы в реальности. Так и не нашли...
Терял на ребилде и 5 и 6 рейды, диски 600 гб.
Qetzlcoatl
09.06.2024 19:15И о чём это должно нам сказать?
А у меня был случай, что за неделю на 5 RAID-е из 5 дисков я поменял на новые 6 дисков из-за выхода их из строя. Но данные все сохранились. Да, диски были ещё небольшого размера, но и шина была ещё SCSI-160 (если не вообще SCSI-2).
Будем из этого какие-то глобальные выводы делать?
А ещё можно было нагнать страха упомянув, что ошибки кроме дисков могут вносить даже кабеля подключения, не считая RAID-контроллеров и/или ПО. Суммарно там вообще дикая "вероятность" ошибки набегает.
Ещё хотелось бы уточнить, знает ли автор, что хранящиеся данные могут делиться на mission critical, business critical и business support со своими требованиями к надёжности их хранения?
ParaMara
09.06.2024 19:15+2Я понял так: мне рассказали что с ростом ёмкости диска надёжность измеряемая числом перезаписей его полного объёма падает катастрофически. Для HDD в это довольно легко поверить и влиять это будет не только на RAID 5. Для SSD, казалось бы, это не должно быть так, производители указывают число перезаписей и оно для маркетинговой линейки есть константа. Но, глядя как падает качество (китайской) NAND, разумно предположить что и контролер не из другого мира, так что не константа и ничем не лучше HDD.
saboteur_kiev
09.06.2024 19:15+10Так может быть для ребилда в настройках рейде выбрать, например, не более 5-10% от ресурса на фоновые операции и ребилды и указать приоритет в зависимости от нагрузки?
Так может если у вас рейд 5 и круглосуточная нагрузка 100%, то рейд-5 не ваш выбор? Рейд 5 вообще больше на чтение, чем на запись, и в идеале вообще для горячих бэкапов, логов и тому подобного, а не для активно рабочей базы данных.
Может просто грамотно пользоваться различными типами рейдов, чтобы не было потом притянутых за уши расчетов, особенно когда
Плюс то вибрация от вращения, то SSD, уж определиться надо..
DM_man
09.06.2024 19:15Предлагаете RAID 10 использовать?
Sap_ru
09.06.2024 19:15Угу, а потом при отказе диска и пересборке RAID,вы всё равно будете молиться, чтобы все эти петабайты прочитались. Тут главное не думать о том, что в случае ошибки при восстановлении RAID10 вы можете даже не узнать о том, что данные неправильно восстановились, так как никаких дополнительный контрольный сумм на уровне RAID у вас уже нет (муа-ха-ха!).
saboteur_kiev
09.06.2024 19:15raid-10 довольно быстро пересобирается.
Sap_ru
09.06.2024 19:15Объём прочитанных полезных данных в общем случае тот же, что в RAID-5.
DM_man
09.06.2024 19:15+1RAID-10 по скорости во много раз превосходит RAID-5 в случае с промышленными СХД , а насчёт скорости пересборки, выше коллега правильно написал, а при allflash-конфигурации так и вообще очень быстро. Или мы ещё о механике (HDD) размышляем? Так на дворе уже 2024 год, а не 2016-ый
nidalee
09.06.2024 19:15На SSD без казённых денег ничего дельного не собрать. Боюсь представить, сколько бы стоил мой массив на 30ТБ даже на самых дешевых SSD. Последний раз, когда считал, что-то около половины миллиона (ЕМНИП) выходило только за диски. При этом после исчерпания кеша скорость у этих дисков будет не на уровне HDD (~120-180 мб\с), а на уровне бюджетных SD-карт - около 40 мб\с.
Grigory_Otrepyev Автор
09.06.2024 19:15RAID-10 по скорости во много раз превосходит RAID-5 в случае с промышленными СХД
Можно в цифрах - много это сколько ? Например, на AFA \ nvme - задержки на R10 составят, max iops будет - и скриншот из конфигуратора хотя бы.
DM_man
09.06.2024 19:15Скриншота точно не будет, так как тестировалось полгода назад, но по iops расклад следующий: на схд (allflash) одного отечественного производителя по fio (профиль нагрузки не помню) через VM одного западного производителя по FC на чтение LUN в Raid - 10 (около 100 000 iops) , у LUN в Raid - 50 (raid-5 не поддерживается схд) (около 50 000 iops). Просто практические замеры и ничего личного, размер блока на схд 32кб
saboteur_kiev
09.06.2024 19:15+1Если данные критичны, и нужна высокая производительность, RAID-10 и хот-своп это нормальный выбор.
Grigory_Otrepyev Автор
09.06.2024 19:15Если данные критичны, и нужна высокая производительность, RAID-10 и хот-своп это нормальный выбор.
нет. для современных контроллеров и nvme of тип массива снизу не так важен
DM_man
09.06.2024 19:15nvme вообще не рекомендуют впихивать в стандартные промышленные RAID
Grigory_Otrepyev Автор
09.06.2024 19:15nvme вообще не рекомендуют впихивать в стандартные промышленные RAID
кто именно и где не рекомендует ?
Вот вам дорада - https://e.huawei.com/hk/products/storage/all-flash-storage/dorado-5000-6000-v6 с ее вариантами -
1.92TB/3.84TB/7.68TB/15.36TB/30.72TB palm-sized NVMe SSD
DM_man
09.06.2024 19:15Дорада это отдельная вселенная, там и объёмами можно подкидывать из отдыхающих дисков (hot spare) в работающее пространство не взирая на тип диска в полке. Контекст же был - соберем из подручного и запилим raid на nvme-дисках?
Firz
09.06.2024 19:15+13вероятность отказа на ребилде R5 при 9 дисках в массиве составит 47 %. Для R6 при тех же вводных – 20%. 20 % отказов, 80% успеха.
Ок, с R5 вроде понятно, сдох один диск, мы ребилдим его с остальных, и если ловим Unrecoverable Read Error, то считай словили битые данные. А с R6 откуда взялись 20%? поправьте если не прав, но чтобы словить битые данные в R6(с одним умершим диском, который мы ребилдим) нужно не просто поймать случайный Unrecoverable Read Error как в случае R5, а поймать его на двух разных дисках в одном и том же бите данных. Какой там шанс словить Unrecoverable Read Error на двух дисках в одном и том же бите данных, даже если предположить что на каждом из двух дисков мы 100% словим битый байт в процессе ребилда, 8 × 10^-14 для 10ТБ дисков?
Grigory_Otrepyev Автор
09.06.2024 19:15А с R6 откуда взялись 20%?
В статье две ссылки на калькуляторы и ссылка на методику.
Firz
09.06.2024 19:15+2Вопрос то не в том откуда вы скопировали эту цифру, вопрос откуда вообще такая цифра взялась.
artemlight
09.06.2024 19:15+3Есть причина проще.
RAID5 без одного диска - это RAID0, но только под предельной нагрузкой (пересборка + прод).
Хотя, если честно - все эти игрища с MSA уже нормально так отдают нафталином. Трехярусный тайринг сейчас есть даже в Storage Spaces, а накладные расходы на его обслуживание стремятся к статистической погрешности.
Я молчу уже про всякие S3-подобные истории типа Minio, где классы отказоустойчивости могут задаваться индивидуально для каждого объекта.
dartraiden
09.06.2024 19:15https://habr.com/articles/78311/
Дело в том, и это надо себе трезво уяснить, что на время ребилда RAID-5 вы остаетесь не просто с RAID лишенным отказоустойчивости. Вы получаете на все время ребилда RAID-0,
Собственно это всё, что нужно знать про RAID-5. Если во время ребилда у вас крякнет ещё один диск - вы в жопе.
Apv__013
09.06.2024 19:15+2Вот поэтому бэкапы и делаются. Вообще не вижу проблемы.
hogstaberg
09.06.2024 19:15Бэкап ещё восстановить нужно, а это время жрёт.
saboteur_kiev
09.06.2024 19:15+1Вы знаете какие-либо волшебные технологии которые 100% гарантируют что никогда ничего не сломается?
Или зачем вообще тогда делаются бекапы, если ими нельзя пользоваться?
Рейд это не замена бэкапов, вообще-то.hogstaberg
09.06.2024 19:15Ни разу не замена, спору нет.
Но делать так, чтобы были заметные шансы того, что однажды один-единственный сдохший диск на ходу под живым сервисом поменять не получится, и сервис в итоге ляжет на то время, пока вы данные из бэкапа будете доставать, глупо. Особенно учитывая, что лишние диски, сильно уменьшающие вероятность такой ситуации, стоят, в общем-то копейки.
saboteur_kiev
09.06.2024 19:15Если сервис критичный, на него выделяются деньги и обеспечивается отказоустойчивость различными методами. Кластеризация базы, сервиса и так далее.
Если некритичный, то значит пользователи могут подождаьт пока сервис восстанавливают из бэкапа.
Собственно тут дело в том, что в споре один говорит про техническую часть, а другой про организационную, естественно консенсус в таком случае не найдется.
Ava256
09.06.2024 19:15+2Используйте диски с URE 10^15 и вероятность ошибки для приведенного примера для R5 судя по калькулятору снизится до 6%.Изначально же речь про MSA шла, а это Энтерпрайз все таки.
SergeyMax
09.06.2024 19:15+5резко возрастает нагрузка на чтение
"Нагрузка на чтение" звучит умно и наукообразно, тут не поспоришь. Но проблема в том, что когда диск "ничего не читает", шпиндель всë равно крутится, головки точно так же парят над пластинами, а контроллер точно так же считывает данные в поисках синхрометок, и осуществляет непрерывное позиционирование.
Sap_ru
09.06.2024 19:15Ну, не совсем там. Диск довольно быстро сначала отводит головку в сервисную зону. Но крутится он и правда всё время (в случае серверного применения), а потому износ у него не меняется.
SergeyMax
09.06.2024 19:15"Довольно быстро" — это в случае серверного оборудования означает "никогда"
lexa
09.06.2024 19:15Я давно пытаюсь в понятии BER разобраться, но окончательно так и не получается.
Теория гласит, что у нас на 10^-14 BER действительно будет одна ошибка на 10 терабайт (100 терабит) или около того.
Практика гласит, что ничего такого на практике не происходит. То есть смело можно писать десятки-сотни терабайт и считывать их обратно и сама по себе ошибка "корректировано RAID" очень редкая на практике.Единственное объяснение я смог придумать такое, исходя из того что параметр BER верный:
считается BER в вероятности битовой ошибки, верно,
но на практике - если мы считали целый сектор с диска и там ошибка - неверным считается весь сектор. ТО есть 16384 бита (для 2к блоков)
В этом случае - у нас если есть ошибка, то сразу в 16к битов. Но встречается она в 16к раз реже, то есть уже с приемлемой не "раз на несколько терабайт" а "раз на сотню петабайт".
Только в этом случае декларируемые BER 10^-14...10^-15 сходятся у меня с реальной практикой.
kekoz
09.06.2024 19:15+1Практика гласит, что ничего такого на практике не происходит.
Если вероятность какого-либо события равна 0.1, то это вовсе не означает, что в одном из десяти случаев это событие произойдёт. Вероятность означает, что может произойти, а не должно произойти. На практике легко проверить, подбрасывая монетку.
Sap_ru
09.06.2024 19:15+1Всё просто.
BER всегда показывает максимальное значение для нормальных условиях эксплуатации. То есть приводится для случая, когда диск перегрет до максимума допустимой температуры, отработал максимум назначенного ресурса и при этом находится в условиях максимальной допустимой вибрации.
На практике горячий ушатанный диск в шумном помещении и правда будет периодически выдавать RAID или ошибки чтения. Которые, кстати, в большинстве случаев будут скорректированы повторным чтением. И это никого не будет удивлять.
А нормальные условия эксплуатации сразу же повышают BER на несколько порядков и всё становится очень хорошо.
Grigory_Otrepyev Автор
09.06.2024 19:15+1Практика гласит, что ничего такого на практике не происходит.
Последняя практика ребилда у меня закончилась 2 сутками размотки кассет
Lazhu
09.06.2024 19:15Диски, зачастую, идут из одной партии, имеют одинаковый уровень наработки
классический malpractice
Manrus
09.06.2024 19:15+9
adante
09.06.2024 19:15+1А поясните магию, почему 10 это так ужасно? Там же тоже должны умереть два диска подряд для потери данных.
Причем не любые два.
Manrus
09.06.2024 19:15+2Потому что смерть двух дисков в одном зеркале это менее надежно чем смерть двух любых дисков. Собственно поэтому надежность raid10 находится между raid5 и raid6
SergeyMax
09.06.2024 19:15+1Собственно поэтому надежность raid10 находится между raid5 и raid6
Вообще нахождение надёжностей друг относительно друга зависит от объёма дисковой группы
noanswer
09.06.2024 19:15теоретический вопрос: если raid 5/6 на больших дисках это плохо, то что посоветуете?
ну допустим ~30Тб домашнего NAS'a для моих фото и видео проектов, бекапаов, музыки, "облака"?romxx
09.06.2024 19:15+2Просто две копии файла на разных дисках храните. И идеально еще третью где-нибудь на каком-нибудь Amazon Glacier.
noanswer
09.06.2024 19:15+1вы серьезно?
вопрос был что лучше 5/6 рейда если собирать из 8-12тб дисков?
как себя ведет 5/6 рейд на 3 Тб дисках я знаю.
кто все это будет синхронизировать и проверять, какое нафиг облако на амазоне на 30+ Тб?romxx
09.06.2024 19:15Абсолютно серьезно, по опыту почти 20 лет в отрасли энтерпрайзного хранения. )
Ну а что вам не нравится ответ на ваш вопрос - ну извините )
> вопрос был что лучше 5/6 рейда если собирать из 8-12тб дисков?Ответ был: "что угодно лучше", для вашей задачи RAID-5/6 не предназначен, есть лучше, дешевле и проще варианты.
kekoz
09.06.2024 19:15Никакая технология хранения данных (на одном хранилище) не позволит вам спать спокойно за их сохранность. Хочется таки спать спокойно — три копии на физически и географически разнесённых носителях.
В вашем случае я бы использовал два NAS с RAIDZ + LTO. ZFS предоставляет чертовски удобные инструменты для “синхронизировать и проверять” — checkpoints, snapshots, clones, bookmarks, zfs send/receive.
К тому же, фото/видео/музыка архивы выгодно отличаются тем, что на них редко (да никогда практически) что-то меняется, только добавляется.
noanswer
09.06.2024 19:15Никакая технология хранения данных (на одном хранилище) не позволит
я вообще не говорил про спокойно, вопрос наверное надо сформулировать так как кой массив будет безопаснее при ребилде с 8-12Тб дисками
В вашем случае я бы использовал два NAS с RAIDZ + LTO. ZFS
блин, не как организовать хранение, а какой массив лучше чем raid 5/6
RAIDZ это же с одним избыточным диском?К тому же, фото/видео/музыка архивы выгодно отличаются тем
у меня ~2/3 данных ro, остальное рабочие, порой большие файлики то самое фото и видео, с версиями и промежуточными результатами.
kekoz
09.06.2024 19:15Если RAIDZ воспринимать как alias для RAIDZ1 — да, это 1-disk parity. А если как обобщение разновидностей RAIDZ, то от 1 до 3.
Сложновато ответить на вопрос “что лучше” без уточнения того, что мы подразумеваем под словом “лучше.” Я, например, считаю, что RAIDZ во всём лучше RAID5/6, кроме одного момента — RAM. На моём позапрошлом “тазике” (Thecus) даже с его убогими 256M вполне себе жил RAID5. Ни о какой ZFS с такой памятью даже и речи быть не может. Но при ценах на RAM это сложно считать хоть сколько-нибудь серьёзным недостатком :)
romxx
09.06.2024 19:15кто все это будет синхронизировать и проверять
Да robocopy cron-ом в фоне решает 99% домашних задач по "синхронизации и проверке" на разных дисках.
какое нафиг облако на амазоне на 30+ Тб?
Какое хотите. Хотите - используйте и имейте удаленную третью копию, не хотите - не используйте. Я же не знаю, насколько вам там ценны ваши данные.
AlexanderS
09.06.2024 19:15Я когда этот вопрос изучал, то склонился к зеркалу ZFS. Получается и защита от выхода из строя диска и данные на диске "не прокиснут". Реализовано это на TrueNAS Scale, крутящемся на виртуалке.
atomnijpchelovek
09.06.2024 19:15Я подумывал над тем, чтобы для схожей цели использовать raid 10. Да, много денег на диски, но при этом неплохие показатели скорость\надежность. Потом, правда, пересмотрел взгляды на то, что и как я собираюсь хранить и решил настроить автокопирование данных между дисками только для выбранных каталогов. Условные фильмы\игры\софт мне не жалко потерять, а вот фотографии и видео - жалко. А совсем важные данные, как заметили выше, можно еще и в облако закинуть.
Sap_ru
09.06.2024 19:15Фокус в том, что при условии равного полезного объёма с RAID-5 вопрос с надёжностью RAID-10 становится вовсе не так однозначен, так как объём данных, которые нужно прочитать при восстановлении, оказывается в этих случаях равен, а разница в надёжности сводится к вероятности отказа диска в произвольно выбранные, например, 20 часов. Какова вероятность того, что используемый вами диск откажет в следующие 12...20 часов? Вот это и есть разница в надёжности между RAID10 и RAID-5. Зато растёт скорость доступа.
Но для дома RAID-10 просто удобнее.
nidalee
09.06.2024 19:15Посоветую не собирать критичные массивы на больших дисках. Собирайте максимум на восьмерках, а лучше на 3-4. Да, дороже. Да, сложнее впихнуть в корпус и подключить. Но надежнее.
Ну и тут надо думать, что такое "большие диски". 8ТБ - большие? Я за последние 3 дня 2 раза ребилдил (я дурачок) ZRAID-2 на 8ТБ WD Red, при этом один из дисков уже сыпался (правда, в свободных секторах). Все прошло нормально и без ошибок. Но я не особо переживал, у меня реально важные данные каждую ночь делают zfs send на VDS в другой стране.
DGN
09.06.2024 19:15RAID это способ обеспечения отказоустойчивости, а не сохранности данных.
Что посоветовать, тут вопрос бюджетов и домашнего комфорта. Имея 30тб, я бы уже купил хотя бы lto6 привод и библиотеку под бакапы. А диски в raid6 бы ставил на 4тб.
erley
09.06.2024 19:15Многие пытаются экономить на дисках, к тому же тут очевидный перенос практик из эпохи дисков небольшого объёма к современным реалиям.
У меня была ситуация когда качественные диски на делловском сервере при не очень активном I/O были собраны в рэйд5, потом один сдох, а заменить его я уже не успел :-)
С тех пор стараюсь собирать дисковую систему в рэйд0 или рэйд1
vagon333
09.06.2024 19:15... в рэйд5, потом один сдох, а заменить его я уже не успел :-)
С тех пор стараюсь собирать дисковую систему в рэйд0 или рэйд1А RAID6 не спасет?
RAID0? Серьезно?
erley
09.06.2024 19:15А RAID6 не спасет?
RAID6 хорош, но при отказе одного диска лучше данные слить в новый массив.
В случае зеркала это по сути именно то что происходит при замене сбойного диска, то есть оставшийся старый диск ещё поживёт какое-то время и будет заменён, но создавать новый массив не нужно. Чисто в целях оптимизации работы зеркало будет проще. Хотя ZFS это очень хорошо упрощает, так что тут дело вкуса.RAID0? Серьезно?
Есть разные задачи, под своп можно и нужно страйпы делать - будет быстрее работать.
А там где надёжность важна - там только зеркало (иногда даже из >2 девайсов).
Конечно мне нужно было это уточнить в моём предыдущем комментарии.vagon333
09.06.2024 19:15Есть разные задачи, под своп можно и нужно страйпы
Статья про надежность массивов дисков.
Мы же не игровую систему обсуждаем.erley
09.06.2024 19:15Да это понятно, мой комментарий как раз про опыт с надёжным хранением данных, а про рэйд0 я упомянул в самом конце, в последней строчке, просто как то, что вообще используется.
DM_man
09.06.2024 19:15Диски могут отваливаться логически (от накопления ошибок i/o на некоторых отечественных системах хранения) и тогда вам не поможет даже схема 4+4 и 4 под горячую замену к этой дисковой группе.
vagon333
09.06.2024 19:15+2RAID6 в массы!
romxx
09.06.2024 19:15Если "массы" не пишут активно, а в основном читают - да. Если пишут - боль. Вы никогда не видели как RAID-6 том совсем некосмических размеров ребилдится неделю? Я - видел.
Но вообще уже RAID как идею пора бы закопать и перестать откапывать.nidalee
09.06.2024 19:15Но вообще уже RAID как идею пора бы закопать и перестать откапывать.
А есть альтернативы?
romxx
09.06.2024 19:15Да. Тот же RAIDZ, он RAID только "по названию". Да и вообще софтверные решения ситуации с отказоустойчивостью сейчас гораздо интереснее и перспективнее.
Grigory_Otrepyev Автор
09.06.2024 19:15А есть альтернативы?
смотря что считать RAID . Потому что кто-то может считать что RAID - это только отдельный аппаратный контроллер
nidalee
09.06.2024 19:15Потому что кто-то может считать что RAID - это только отдельный аппаратный контроллер
Ошибаться имеет право каждый, но аббревиатура "RAID" к аппаратным контроллерам вообще никакого отношения не имеет: Redundant Array of Inexpensive Disks \ Redundant Array of Independent Disks.
romxx
09.06.2024 19:15Вот именно, что "array" и "independent disks". Это ключевое свойство RAID в их определении. Но организовать избыточность можно и не делая array из independent disks. Есть много вариантов уже.
datalabs
09.06.2024 19:15+1Когда стоит несколько дисков несколько лет, они все уже в предсмертном состоянии. Какой-то умирает первым, вместо него вставляют новый диск и запускают ребилд... И в процессе умирают ещё диски... И велкам ту даталабс)))
5 рейд может работать без одного винта, тоесть в момент аварии, лучше скачать данные и выкинуть уставшие диски. Все..
karavan_750
09.06.2024 19:15RAID-5 совершенно не подходит
Так достаточно.
И далее можно в очередной раз напомнить причины, не ограничиваясь нишей ёмких накопителей.
Ava256
09.06.2024 19:15Когда я читаю, что кто-то жалуется, что брендовая хранилка заруинила том, обычно это значит, что за хранилкой не следят и мониторинг не настроен. По моему опыту рабочий энтерпразный диск в хранилке просто так не вылетает. Обычно этому предшествуют ошибки чтения, восстановимые. И дальше такой диск может быть помечен СХД как «Predicted failure». Уже здесь его надо менять.
За последние два года у меня не было не одного сбоя в ребилде дисков в томах RAID 10 и 5 как на серверах, так и на СХД.Хранилки HP и Dell, правда диски не большие 1.2 тб или 1.8 тб, некоторые стоят в работе с 2015-го года.Был только один случай когда на MSA на томе RAID 6 при замене сразу двух дисков при ребилде тома отказал еще один диск.После замены этого диска, том остался рабочим, но с заблокированным одним сектором.Все что нужно удалось перенести на другой том, а этот просто пересобрали.DM_man
09.06.2024 19:15Полностью соглашаюсь, но создалось ощущение, что многие комментаторы не используют промышленные СХД, а используют сервер+диски и скорее всего некие гиперконвергентные системы виртуализации.
Ava256
09.06.2024 19:15Сервер + диски тоже надо уметь правильно готовить. Кто-то собирает raid на аппаратном контроллере, я бы предпочел собрать ZFS из отдельных дисков. А там дальше можно все настроить и кэши и мониторинг.
notwithstanding
09.06.2024 19:15что означает, что для обычного диска (с его 1/10^-14) в 1 Тб - 1.000.000.000.000 байт (завели моду указывать не честные терабайты, а я страдаю) вероятность отказа на ребилде R5 при 9 дисках в массиве составит 47 %Это как посчитали? Около 9% вероятность же.
Ava256
09.06.2024 19:15Это при 1/10^-15 вероятность 9 %
VitohA
09.06.2024 19:15Да, знакомая страшилка с незапамятных времён. Но raid - это всё же про доступность данных, а не сохранность. Вышел из строя диск в raid-5? Да. Данные остались доступны? Да. При ребилде может поломаться железо или что-то пойти не так? Да, но это вопрос сохранности, а именно бекапов. Ну и про ошибки в рассчётах выше уже писали. Самая главная ошибка - хотеть от raid'а и железа того, на что они не рассчитаны или ожидаемое событие приравнять к фейлу.
Grigory_Otrepyev Автор
09.06.2024 19:15+1Ну и про ошибки в рассчётах выше уже писали.
Я не увидел расчета от писавших. Такое впечатление, что они забыли и тервер, и по ссылкам не ходили - вспомнить формулу или хотя бы погонять калькулятор
FoxWMulder
09.06.2024 19:15+1В этой статье даëтся ссылка на статью 2009го года.
там есть например это
Эта холодная цифра означает, что с 16-20-процентной вероятностью вы получите отказ диска во время ребилда (и, следовательно, потеряете все данные на RAID)
да, я не читал спецификации райда и т.п. но с какого лешего из-за одного сбойного бита или сектора должны быть потеряны данные на всëм райде? очень сильно сомневаюсь. если это вдруг это так, то это вопрос к программе которая выполняет ребилд, почему она не "исправляет" данную ошибку. ведь очевидно что данные почти все в райде живее всех живых, если программа ребилда всë похе.. потеряет из-за одного сбойного сектора, то это проблема этой программы, а не типа райда и не жëстких дисков.
мне кажется в обеих статьях есть не мало допущений.
kvaps
Спасибо за статью, наконец-то кто-то разложил по полочкам! Добавил в избранное, буду использовать как референс для тех кто не верит.
BTW. Было бы очень интересно услышать ваше мнение насчёт ZFS'ного dRAID, насколько он эффективен и за счёт чего решает вышеобозначенные проблемы.
pfsenses
dRAID, если я верно понял принцип его работы, уменьшает время ребилда, т.к. в случае его нет бутылочного горлышка spare диска. Это, к слову, не единственная реализация подобного.
DM_man
ZFS этот то что Аэродиск использует в своей логике?
pfsenses
Честно, не интересовался, что именно они используют. Но вполне возможно, ZFS вполне применяется в коммерческих стораджах, в том числе и от Oracle.
Grigory_Otrepyev Автор
нет, у них свой кусок продукта вторичного.
Grigory_Otrepyev Автор
В другой раз.