Comments 136
Спасибо за статью, наконец-то кто-то разложил по полочкам! Добавил в избранное, буду использовать как референс для тех кто не верит.
BTW. Было бы очень интересно услышать ваше мнение насчёт ZFS'ного dRAID, насколько он эффективен и за счёт чего решает вышеобозначенные проблемы.
Все просто, выбери что то одно - надежно, быстро, дешево.
Хочется скорости, берешь 'дорогой' контроллер (хз какой) и raid1 mirror из трех дисков, и в момент rebuild контроллер сам перераспределит нагрузку таким образом, чтобы деградации не было. Очень жаль что такого функционала (хотя бы ручного указания) - нет ни в mdadm ни в zfs/btrfs.
По теме - если дисков много, не рекомендуется объединять их все в ОДИН большой массив. Лучше делать несколько небольших, например по 4-5 дисков. Тогда rebuild одного не затронет другую часть хранилища.
Судя по статье я счастливчик, у меня недавно ребилдился массив RAID6 из 24 дисков по 14TB и он это сделал. Долго конечно делал.
or an error every 1.25PB
1PB = 1024TB
По моему, в расчётах явно есть ошибка. У меня за 20 лет стажа вырвало только один раз RAID5 во время пересборки. Да такой шанс есть, если старые диски из одной партии, то ребилд может так нагрузить диски, что они не доживут, но об этом в статье и написано. Поэтому лучше такое заранее предвидеть и делать новый массив с дисками заранее.
ZFS по моему безумно дорогая идея с какими-то несоразмерными накладными расходами.
Все подобные расчёты по какой-то удивительной причине исходят из того, что первая же неисправленная ошибка жёсткого диска приведёт к его немедленному и неустранимому отказу, В то время, как на самом деле речь идёт лишь о коррекции ошибок, а есть ещё и обнаружение ошибок. На практике ошибка будет обнаружена и всё закончится повторным чтением блока. Причём обнаружение ошибок есть ещё и на уровне RAID, и даже если ошибка прошла незамеченной на уровне диска, её заметит RAID и и исправит повторным чтением.
В результате уже лет 10 все подобные расчёты убедительно доказывают, что RAID5 работать не может в принципе, но он почему-то работает.
Во время ребилда R5 ничего исправить не может, у него нет в этот момент избыточности.
Речь не про избыточность. А про то, что проблемный сектор диска, в подавляющем большинстве случаев, удаётся перечитать без ошибки.
А во всех остальных, кроме "подавляющего большинства"? Вы реально проектируете IT инфраструктуру хранения исходя из идеи "ну вдруг не накернится сразу, вдруг повезет?"
А я ничего не говорил про проектирование инфраструктур. Я лишь заметил, что вы неверно истолковали комментарий выше.
Что касается хранения данных с избыточностью, уж если Вам так интересно, то в той конторе, где я сейчас работаю, используется RAID 10. Раньше были ещё 50 массивы, но от них отказались, в силу меньшей производительности относительно 10.
В реальной жизни у вас в любом случае в конечном итоге всё и всегда работает исходя из идеи "вдруг повезёт", так как вероятности отказов всегда ненулевые. У вас могут взять и сами испортится любые данные и само по себе произойти вообще любое действие в любой программе, так как у ECC в процессоре тоже имеет вероятность отказа. Вы можете обложиться бэкапами и резервированием, и всё равно обнаружить, что все акутальные данные потеряны. Просто потому, что две заряженные частицы пролетели там, где нужно. Вопрос лишь в вероятности этого драматического события.
Но на практике нужно ещё учитывать вероятность не просто отказа, а вероятность необнаружимого иили критического отказа. А у используемых контрольным сумм вероятность необнаружимой ошибки на несколько порядков ниже вероятности невосстановимой ошибки. Т.е. контрольная сумма не может исправить ошибку, но всё равно показывет её наличие.
В результате при расчёте полной вероятности на вероятность отказа диска накладывается очень небольшая вероятность ошибки чтения при восстановлении. А поверх этого нужно ещё и чтобы ошибка была необнаружимой или критической (отказ диска), что может случиться один раз на несколько тысяч ошибок при восстановлении RAID-5.
В результате неправильные расчёты показывают, что RAID-5 не может работать и должен сыпаться буквально при каждом втором восстановлении, а на практике с учётом всех вероятностей, беда случится только, что-то вроде, один раз на тысячу полных восстановлений и RAID-5 отлично работает.
Как следствие суммарная вероятность фатального отказа RAID-5 вполне себе соответствует вероятности отказа какого-либо другого элемента инфраструктуры и потому не является определяющим фактором.
На многих рейдах, особенно старых, любой ERROR в логе сразу валит массив в degraded. Дома было 5 sas дисков по 16тб и один из распространенных адаптеков - намучался и продал: смарт у дисков чистый, релоков ноль, но периодически в нагрузке лезет degraded с потерей случайного диска, как раз на ошибках чтения/записи. Проверяешь всю поверхность через HBA-адаптер - все отлично, нигде сбоев нет. Собираешь, работает пару месяцев, и хоба - опять degraded.
Контроллеров пачка была, менял - толку чуть. Покупатель поставил диски на рейд 2022 года, какая-то люто дорогущая модель - у него проблемы не всплыло - я рассказал ему о баге при продаже.
за 20 лет стажа вырвало только один раз RAID5 во время пересборки
А сколько у вас, простите, всего было пересборок больших RAID5 за двадцать лет стажа?
У меня было две пересборки весьма пожилых (самому старому диску - около 7 лет) 24-дисковых RAID5E и с десяток немолодых 10-дисковых RAID5. 3-5-дисковых - и не сосчитать. При этом однажды был свидетелем смерти двух дисков в RAID5 с интервалом менее 20 минут (мы даже запасной взамен "отъехавшего" вставить не успели - только-только вкрутили в "салазки", и сервер сказал "adiós!") - было неприятно, но это было в самом начале карьеры... ещё неоднократно видел самопроизвольный отвал исправного по всем диагностикам диска, прям как у комментатора выше, без фатальных последствий, и я продолжаю использовать RAID5/6 там, где риск отказа приемлем (горячие бэкапы, резервируемые "файлопомойки", неучаствующие в бизнес-процессах сервисы), да даже RAID0 иногда себя оправдывает - в тестовых средах, например.
Спасибо, не знал про правило power of 2 и как раз собирался докупить 5-й диск для RaidZ2 :)
Это зависит от реализации. И описание про "power of 2" применимо именно к там, где написано (в данном случае документация на СХД MSA и родственников). Существуют реализации, где такого правила вовсе нет и 3+1 или 7+1 может быть наоборот рекомендованным размером для RAID5 из-за внутренних оптимизаций. Про zfs не скажу.
Расчёты полное говно (что ~50% больших пятых рейдов разваливаются при ребилде). Даже смехотворно, что кто-то всерьез такое накалякал.
p.s. и да, я это всё читал 15 лет назад от других фантастов. там ещё писали бред, что у всего raid5-массива скорость записи == скорости одного диска минус 30%. а у raid6 ещё минус 60. тоже бредни.
Тут классическая ошибка в расчётах - одиночная ошибка диска приравнивается к его отказу.
Есть диски raid edition, разница в параметрах прошивки с такими же, но обычными в том числе в том, чтоб скорей отдать ошибку наружу, а не копошиться с перечитыванием сектора.
Перечитывание всё равно есть, только количество раз сильно меньше.
Но ОС и софт RAID тоже не дураки писали, а потому, если других вариантов восстановления нет, то всё равно будет сброс буферов и повторы чтения уже на высоком уровне.
А так же в том, что время на попытку считать сектор сильно ниже, чем у обычных. Диски raid edition так же сами не будут пытаться исправить ошибку, пока не получат сигнал от raid контроллера
Помню как читал тред на SO где народ долго и упорно искал людей, у которых эта ситуация произошла бы в реальности. Так и не нашли...
Ситуация действительно происходит, но обычно видна только логам (ай-ай-ай, при пересборке RAID была ошибка и пришлось сбросить контроллер перечитать кусок диска_ или в худших случаях лечится, например перезапуском сборки RAID. Очень страшно (ай-ай-ай, у нас RAID с первого раза не собрался!!!), но исход всё равно успешен. Чтобы прямо совсем бесповоротно навернулся при пересборке, нужно быть сильно невезучим, и с тем уже успехом можно на одновременный отказ нескольких диском нарваться или ещё на какую редкую и страшную беду.
Помню как читал тред на SO где народ долго и упорно искал людей, у которых эта ситуация произошла бы в реальности. Так и не нашли...
Терял на ребилде и 5 и 6 рейды, диски 600 гб.
И о чём это должно нам сказать?
А у меня был случай, что за неделю на 5 RAID-е из 5 дисков я поменял на новые 6 дисков из-за выхода их из строя. Но данные все сохранились. Да, диски были ещё небольшого размера, но и шина была ещё SCSI-160 (если не вообще SCSI-2).
Будем из этого какие-то глобальные выводы делать?
А ещё можно было нагнать страха упомянув, что ошибки кроме дисков могут вносить даже кабеля подключения, не считая RAID-контроллеров и/или ПО. Суммарно там вообще дикая "вероятность" ошибки набегает.
Ещё хотелось бы уточнить, знает ли автор, что хранящиеся данные могут делиться на mission critical, business critical и business support со своими требованиями к надёжности их хранения?
Я понял так: мне рассказали что с ростом ёмкости диска надёжность измеряемая числом перезаписей его полного объёма падает катастрофически. Для HDD в это довольно легко поверить и влиять это будет не только на RAID 5. Для SSD, казалось бы, это не должно быть так, производители указывают число перезаписей и оно для маркетинговой линейки есть константа. Но, глядя как падает качество (китайской) NAND, разумно предположить что и контролер не из другого мира, так что не константа и ничем не лучше HDD.
Так может быть для ребилда в настройках рейде выбрать, например, не более 5-10% от ресурса на фоновые операции и ребилды и указать приоритет в зависимости от нагрузки?
Так может если у вас рейд 5 и круглосуточная нагрузка 100%, то рейд-5 не ваш выбор? Рейд 5 вообще больше на чтение, чем на запись, и в идеале вообще для горячих бэкапов, логов и тому подобного, а не для активно рабочей базы данных.
Может просто грамотно пользоваться различными типами рейдов, чтобы не было потом притянутых за уши расчетов, особенно когда
Плюс то вибрация от вращения, то SSD, уж определиться надо..
Предлагаете RAID 10 использовать?
Угу, а потом при отказе диска и пересборке RAID,вы всё равно будете молиться, чтобы все эти петабайты прочитались. Тут главное не думать о том, что в случае ошибки при восстановлении RAID10 вы можете даже не узнать о том, что данные неправильно восстановились, так как никаких дополнительный контрольный сумм на уровне RAID у вас уже нет (муа-ха-ха!).
raid-10 довольно быстро пересобирается.
Объём прочитанных полезных данных в общем случае тот же, что в RAID-5.
RAID-10 по скорости во много раз превосходит RAID-5 в случае с промышленными СХД , а насчёт скорости пересборки, выше коллега правильно написал, а при allflash-конфигурации так и вообще очень быстро. Или мы ещё о механике (HDD) размышляем? Так на дворе уже 2024 год, а не 2016-ый
На SSD без казённых денег ничего дельного не собрать. Боюсь представить, сколько бы стоил мой массив на 30ТБ даже на самых дешевых SSD. Последний раз, когда считал, что-то около половины миллиона (ЕМНИП) выходило только за диски. При этом после исчерпания кеша скорость у этих дисков будет не на уровне HDD (~120-180 мб\с), а на уровне бюджетных SD-карт - около 40 мб\с.
Понимаю, сытый голодного не разумеет...
Не, если вопрос о деньгах не стоит, то можно вообще собираться на NVME, вроде Kioxia CD6. Туда еще для души докинуть EPYC, а-ля 9534, пару сотен гигов DDR5... Но обычно такой вопрос таки стоит.
Можно и так, главное резервироваться при этом всём чаще)
Ну, в принципе, Вы описали более-менее вменяемый NVME-storage. Там, где это оправдано, оно вполне себе применяется. В более бюджетном сегменте тоже есть нормальные решения. И уж совсем "для голодранцев" я собирал software-RAID10 на околобытовых SSD. Но при этом и массивы HDD RAID5 никто не отрицает - петабайты горячих бэкапов особо больше и негде хранить.
В данном случае наоборот: голодный сытого не разумеет.
не энтерпрайз решение, но в мелких продакшенах с НЕкорпоративными SSD на аппаратных контроллерах имел печальный опыт, увы. Не встречал аппаратных RAID-контроллеров, которые умеют пробрасывать TRIM, а без него пул на SSD даже с 60% утилизацией начинает себя вести хуже чем одиночный SSD по IOPS.
Повторяюсь - речь не о корпоративном сегменте SSD. Но от пула в момент инициализации отгрызался 20% кусок в неразмеченную для пользоватя область как раз для "сборщика мусора".
RAID-10 по скорости во много раз превосходит RAID-5 в случае с промышленными СХД
Можно в цифрах - много это сколько ? Например, на AFA \ nvme - задержки на R10 составят, max iops будет - и скриншот из конфигуратора хотя бы.
Скриншота точно не будет, так как тестировалось полгода назад, но по iops расклад следующий: на схд (allflash) одного отечественного производителя по fio (профиль нагрузки не помню) через VM одного западного производителя по FC на чтение LUN в Raid - 10 (около 100 000 iops) , у LUN в Raid - 50 (raid-5 не поддерживается схд) (около 50 000 iops). Просто практические замеры и ничего личного, размер блока на схд 32кб
в общем случае, в raid-10 нужно просто сдублировать парный винт
вот с RAID10 за 11 лет проблем не наблюдал у себя. а с 5ой версией уже нахлебался.
правда, raidz мне понравился - если диски не SMR, то на zfs resilver и scrub идут довольно шустренько, не наблюдались тормоза как при degrade RAID5 и его ребилде.
насущным остаётся вопрос - зачем тогда в нынешних реалиях нужны RAID-контроллеры, если не могут обеспечить целостность данных исходя их математической теории отказа HDD?
На RAID50/60 это конечно не так распространяется, но эти уровни настолько расточительны по расходу дисков, что почти нигде не применяются.
Если данные критичны, и нужна высокая производительность, RAID-10 и хот-своп это нормальный выбор.
Если данные критичны, и нужна высокая производительность, RAID-10 и хот-своп это нормальный выбор.
нет. для современных контроллеров и nvme of тип массива снизу не так важен
nvme вообще не рекомендуют впихивать в стандартные промышленные RAID
nvme вообще не рекомендуют впихивать в стандартные промышленные 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
Дорада это отдельная вселенная, там и объёмами можно подкидывать из отдыхающих дисков (hot spare) в работающее пространство не взирая на тип диска в полке. Контекст же был - соберем из подручного и запилим raid на nvme-дисках?
вероятность отказа на ребилде 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ТБ дисков?
Есть причина проще.
RAID5 без одного диска - это RAID0, но только под предельной нагрузкой (пересборка + прод).
Хотя, если честно - все эти игрища с MSA уже нормально так отдают нафталином. Трехярусный тайринг сейчас есть даже в Storage Spaces, а накладные расходы на его обслуживание стремятся к статистической погрешности.
Я молчу уже про всякие S3-подобные истории типа Minio, где классы отказоустойчивости могут задаваться индивидуально для каждого объекта.
https://habr.com/articles/78311/
Дело в том, и это надо себе трезво уяснить, что на время ребилда RAID-5 вы остаетесь не просто с RAID лишенным отказоустойчивости. Вы получаете на все время ребилда RAID-0,
Собственно это всё, что нужно знать про RAID-5. Если во время ребилда у вас крякнет ещё один диск - вы в жопе.
Вот поэтому бэкапы и делаются. Вообще не вижу проблемы.
Бэкап ещё восстановить нужно, а это время жрёт.
Вы знаете какие-либо волшебные технологии которые 100% гарантируют что никогда ничего не сломается?
Или зачем вообще тогда делаются бекапы, если ими нельзя пользоваться?
Рейд это не замена бэкапов, вообще-то.
Ни разу не замена, спору нет.
Но делать так, чтобы были заметные шансы того, что однажды один-единственный сдохший диск на ходу под живым сервисом поменять не получится, и сервис в итоге ляжет на то время, пока вы данные из бэкапа будете доставать, глупо. Особенно учитывая, что лишние диски, сильно уменьшающие вероятность такой ситуации, стоят, в общем-то копейки.
Если сервис критичный, на него выделяются деньги и обеспечивается отказоустойчивость различными методами. Кластеризация базы, сервиса и так далее.
Если некритичный, то значит пользователи могут подождаьт пока сервис восстанавливают из бэкапа.
Собственно тут дело в том, что в споре один говорит про техническую часть, а другой про организационную, естественно консенсус в таком случае не найдется.
Вот поэтому бэкапы и делаются
А если это был бекап?
Есть raid6, он переживет смерть двух любых дисков.
Используйте диски с URE 10^15 и вероятность ошибки для приведенного примера для R5 судя по калькулятору снизится до 6%.Изначально же речь про MSA шла, а это Энтерпрайз все таки.
резко возрастает нагрузка на чтение
"Нагрузка на чтение" звучит умно и наукообразно, тут не поспоришь. Но проблема в том, что когда диск "ничего не читает", шпиндель всë равно крутится, головки точно так же парят над пластинами, а контроллер точно так же считывает данные в поисках синхрометок, и осуществляет непрерывное позиционирование.
Я давно пытаюсь в понятии BER разобраться, но окончательно так и не получается.
Теория гласит, что у нас на 10^-14 BER действительно будет одна ошибка на 10 терабайт (100 терабит) или около того.
Практика гласит, что ничего такого на практике не происходит. То есть смело можно писать десятки-сотни терабайт и считывать их обратно и сама по себе ошибка "корректировано RAID" очень редкая на практике.
Единственное объяснение я смог придумать такое, исходя из того что параметр BER верный:
считается BER в вероятности битовой ошибки, верно,
но на практике - если мы считали целый сектор с диска и там ошибка - неверным считается весь сектор. ТО есть 16384 бита (для 2к блоков)
В этом случае - у нас если есть ошибка, то сразу в 16к битов. Но встречается она в 16к раз реже, то есть уже с приемлемой не "раз на несколько терабайт" а "раз на сотню петабайт".
Только в этом случае декларируемые BER 10^-14...10^-15 сходятся у меня с реальной практикой.
Практика гласит, что ничего такого на практике не происходит.
Если вероятность какого-либо события равна 0.1, то это вовсе не означает, что в одном из десяти случаев это событие произойдёт. Вероятность означает, что может произойти, а не должно произойти. На практике легко проверить, подбрасывая монетку.
Всё просто.
BER всегда показывает максимальное значение для нормальных условиях эксплуатации. То есть приводится для случая, когда диск перегрет до максимума допустимой температуры, отработал максимум назначенного ресурса и при этом находится в условиях максимальной допустимой вибрации.
На практике горячий ушатанный диск в шумном помещении и правда будет периодически выдавать RAID или ошибки чтения. Которые, кстати, в большинстве случаев будут скорректированы повторным чтением. И это никого не будет удивлять.
А нормальные условия эксплуатации сразу же повышают BER на несколько порядков и всё становится очень хорошо.
Практика гласит, что ничего такого на практике не происходит.
Последняя практика ребилда у меня закончилась 2 сутками размотки кассет
Диски, зачастую, идут из одной партии, имеют одинаковый уровень наработки
классический malpractice
теоретический вопрос: если raid 5/6 на больших дисках это плохо, то что посоветуете?
ну допустим ~30Тб домашнего NAS'a для моих фото и видео проектов, бекапаов, музыки, "облака"?
Просто две копии файла на разных дисках храните. И идеально еще третью где-нибудь на каком-нибудь Amazon Glacier.
вы серьезно?
вопрос был что лучше 5/6 рейда если собирать из 8-12тб дисков?
как себя ведет 5/6 рейд на 3 Тб дисках я знаю.
кто все это будет синхронизировать и проверять, какое нафиг облако на амазоне на 30+ Тб?
Абсолютно серьезно, по опыту почти 20 лет в отрасли энтерпрайзного хранения. )
Ну а что вам не нравится ответ на ваш вопрос - ну извините )
> вопрос был что лучше 5/6 рейда если собирать из 8-12тб дисков?
Ответ был: "что угодно лучше", для вашей задачи RAID-5/6 не предназначен, есть лучше, дешевле и проще варианты.
Никакая технология хранения данных (на одном хранилище) не позволит вам спать спокойно за их сохранность. Хочется таки спать спокойно — три копии на физически и географически разнесённых носителях.
В вашем случае я бы использовал два NAS с RAIDZ + LTO. ZFS предоставляет чертовски удобные инструменты для “синхронизировать и проверять” — checkpoints, snapshots, clones, bookmarks, zfs send/receive.
К тому же, фото/видео/музыка архивы выгодно отличаются тем, что на них редко (да никогда практически) что-то меняется, только добавляется.
Никакая технология хранения данных (на одном хранилище) не позволит
я вообще не говорил про спокойно, вопрос наверное надо сформулировать так как кой массив будет безопаснее при ребилде с 8-12Тб дисками
В вашем случае я бы использовал два NAS с RAIDZ + LTO. ZFS
блин, не как организовать хранение, а какой массив лучше чем raid 5/6
RAIDZ это же с одним избыточным диском?
К тому же, фото/видео/музыка архивы выгодно отличаются тем
у меня ~2/3 данных ro, остальное рабочие, порой большие файлики то самое фото и видео, с версиями и промежуточными результатами.
Если RAIDZ воспринимать как alias для RAIDZ1 — да, это 1-disk parity. А если как обобщение разновидностей RAIDZ, то от 1 до 3.
Сложновато ответить на вопрос “что лучше” без уточнения того, что мы подразумеваем под словом “лучше.” Я, например, считаю, что RAIDZ во всём лучше RAID5/6, кроме одного момента — RAM. На моём позапрошлом “тазике” (Thecus) даже с его убогими 256M вполне себе жил RAID5. Ни о какой ZFS с такой памятью даже и речи быть не может. Но при ценах на RAM это сложно считать хоть сколько-нибудь серьёзным недостатком :)
кто все это будет синхронизировать и проверять
Да robocopy cron-ом в фоне решает 99% домашних задач по "синхронизации и проверке" на разных дисках.
какое нафиг облако на амазоне на 30+ Тб?
Какое хотите. Хотите - используйте и имейте удаленную третью копию, не хотите - не используйте. Я же не знаю, насколько вам там ценны ваши данные.
Я когда этот вопрос изучал, то склонился к зеркалу ZFS. Получается и защита от выхода из строя диска и данные на диске "не прокиснут". Реализовано это на TrueNAS Scale, крутящемся на виртуалке.
Я подумывал над тем, чтобы для схожей цели использовать raid 10. Да, много денег на диски, но при этом неплохие показатели скорость\надежность. Потом, правда, пересмотрел взгляды на то, что и как я собираюсь хранить и решил настроить автокопирование данных между дисками только для выбранных каталогов. Условные фильмы\игры\софт мне не жалко потерять, а вот фотографии и видео - жалко. А совсем важные данные, как заметили выше, можно еще и в облако закинуть.
Фокус в том, что при условии равного полезного объёма с RAID-5 вопрос с надёжностью RAID-10 становится вовсе не так однозначен, так как объём данных, которые нужно прочитать при восстановлении, оказывается в этих случаях равен, а разница в надёжности сводится к вероятности отказа диска в произвольно выбранные, например, 20 часов. Какова вероятность того, что используемый вами диск откажет в следующие 12...20 часов? Вот это и есть разница в надёжности между RAID10 и RAID-5. Зато растёт скорость доступа.
Но для дома RAID-10 просто удобнее.
Посоветую не собирать критичные массивы на больших дисках. Собирайте максимум на восьмерках, а лучше на 3-4. Да, дороже. Да, сложнее впихнуть в корпус и подключить. Но надежнее.
Ну и тут надо думать, что такое "большие диски". 8ТБ - большие? Я за последние 3 дня 2 раза ребилдил (я дурачок) ZRAID-2 на 8ТБ WD Red, при этом один из дисков уже сыпался (правда, в свободных секторах). Все прошло нормально и без ошибок. Но я не особо переживал, у меня реально важные данные каждую ночь делают zfs send на VDS в другой стране.
RAID это способ обеспечения отказоустойчивости, а не сохранности данных.
Что посоветовать, тут вопрос бюджетов и домашнего комфорта. Имея 30тб, я бы уже купил хотя бы lto6 привод и библиотеку под бакапы. А диски в raid6 бы ставил на 4тб.
Многие пытаются экономить на дисках, к тому же тут очевидный перенос практик из эпохи дисков небольшого объёма к современным реалиям.
У меня была ситуация когда качественные диски на делловском сервере при не очень активном I/O были собраны в рэйд5, потом один сдох, а заменить его я уже не успел :-)
С тех пор стараюсь собирать дисковую систему в рэйд0 или рэйд1
... в рэйд5, потом один сдох, а заменить его я уже не успел :-)
С тех пор стараюсь собирать дисковую систему в рэйд0 или рэйд1
А RAID6 не спасет?
RAID0? Серьезно?
А RAID6 не спасет?
RAID6 хорош, но при отказе одного диска лучше данные слить в новый массив.
В случае зеркала это по сути именно то что происходит при замене сбойного диска, то есть оставшийся старый диск ещё поживёт какое-то время и будет заменён, но создавать новый массив не нужно. Чисто в целях оптимизации работы зеркало будет проще. Хотя ZFS это очень хорошо упрощает, так что тут дело вкуса.
RAID0? Серьезно?
Есть разные задачи, под своп можно и нужно страйпы делать - будет быстрее работать.
А там где надёжность важна - там только зеркало (иногда даже из >2 девайсов).
Конечно мне нужно было это уточнить в моём предыдущем комментарии.
Диски могут отваливаться логически (от накопления ошибок i/o на некоторых отечественных системах хранения) и тогда вам не поможет даже схема 4+4 и 4 под горячую замену к этой дисковой группе.
RAID6 в массы!
Если "массы" не пишут активно, а в основном читают - да. Если пишут - боль. Вы никогда не видели как RAID-6 том совсем некосмических размеров ребилдится неделю? Я - видел.
Но вообще уже RAID как идею пора бы закопать и перестать откапывать.
Но вообще уже RAID как идею пора бы закопать и перестать откапывать.
А есть альтернативы?
Да. Тот же RAIDZ, он RAID только "по названию". Да и вообще софтверные решения ситуации с отказоустойчивостью сейчас гораздо интереснее и перспективнее.
А есть альтернативы?
смотря что считать RAID . Потому что кто-то может считать что RAID - это только отдельный аппаратный контроллер
Когда стоит несколько дисков несколько лет, они все уже в предсмертном состоянии. Какой-то умирает первым, вместо него вставляют новый диск и запускают ребилд... И в процессе умирают ещё диски... И велкам ту даталабс)))
5 рейд может работать без одного винта, тоесть в момент аварии, лучше скачать данные и выкинуть уставшие диски. Все..
RAID-5 совершенно не подходит
Так достаточно.
И далее можно в очередной раз напомнить причины, не ограничиваясь нишей ёмких накопителей.
Когда я читаю, что кто-то жалуется, что брендовая хранилка заруинила том, обычно это значит, что за хранилкой не следят и мониторинг не настроен. По моему опыту рабочий энтерпразный диск в хранилке просто так не вылетает. Обычно этому предшествуют ошибки чтения, восстановимые. И дальше такой диск может быть помечен СХД как «Predicted failure». Уже здесь его надо менять.
За последние два года у меня не было не одного сбоя в ребилде дисков в томах RAID 10 и 5 как на серверах, так и на СХД.Хранилки HP и Dell, правда диски не большие 1.2 тб или 1.8 тб, некоторые стоят в работе с 2015-го года.Был только один случай когда на MSA на томе RAID 6 при замене сразу двух дисков при ребилде тома отказал еще один диск.После замены этого диска, том остался рабочим, но с заблокированным одним сектором.Все что нужно удалось перенести на другой том, а этот просто пересобрали.
что означает, что для обычного диска (с его 1/10^-14) в 1 Тб - 1.000.000.000.000 байт (завели моду указывать не честные терабайты, а я страдаю) вероятность отказа на ребилде R5 при 9 дисках в массиве составит 47 %
Это как посчитали? Около 9% вероятность же.
Да, знакомая страшилка с незапамятных времён. Но raid - это всё же про доступность данных, а не сохранность. Вышел из строя диск в raid-5? Да. Данные остались доступны? Да. При ребилде может поломаться железо или что-то пойти не так? Да, но это вопрос сохранности, а именно бекапов. Ну и про ошибки в рассчётах выше уже писали. Самая главная ошибка - хотеть от raid'а и железа того, на что они не рассчитаны или ожидаемое событие приравнять к фейлу.
В этой статье даëтся ссылка на статью 2009го года.
там есть например это
Эта холодная цифра означает, что с 16-20-процентной вероятностью вы получите отказ диска во время ребилда (и, следовательно, потеряете все данные на RAID)
да, я не читал спецификации райда и т.п. но с какого лешего из-за одного сбойного бита или сектора должны быть потеряны данные на всëм райде? очень сильно сомневаюсь. если это вдруг это так, то это вопрос к программе которая выполняет ребилд, почему она не "исправляет" данную ошибку. ведь очевидно что данные почти все в райде живее всех живых, если программа ребилда всë похе.. потеряет из-за одного сбойного сектора, то это проблема этой программы, а не типа райда и не жëстких дисков.
мне кажется в обеих статьях есть не мало допущений.
Всё именно так.
да, я не читал спецификации райда и т.п. но
этого достаточно
если это вдруг это так, то это вопрос к программе которая выполняет ребилд, почему она не "исправляет" данную ошибку
и как она это делает?
грубо говоря забивать нулями то что не восстановлено. будет бито какое-то количество файлов. но ведь остальная информация кроме битого сектора цела же?!
но так да, т.к. я мало знаком с райдом, то я не спорю, просто выглядит очень странно. мне кажется что многое зависит от программы выполяняющий ребилд и потеря одного сектора не повод терять всю информацию на всех дисках. ну совсем не повод.
мне всегда был понятен зеркальный райд. понятно что разные райды были созданы не простот так. и кнч считаю что одним райдом обходиться нельзя. тут где-то писали, три бэкапа в разных местах - вот это просто и понятно. бэкапов много не бывает...
Пора оставить RAID-5 в далеком прошлом