Комментарии 251
Потом очень искренне смеялся над фразой, что ни одна схема резервирования RAID не даёт стопроцентной гарантии сохранности данных.
Сколько раз можно на одни и те же грабли наступать? RAID - средство достижения высокой доступности, а не замена бэкапам.
по сути, для очень важных данных, которые надо хранить долго, единственный реальный бэкап - это всё та же ленточная библиотека, физически находящаяся в другом месте и с носителями, физически извлеченными из tape drive. все остальное - это компромиссы разного уровня
И минимум в двух разнесённых в пространстве копиях.
и из них хотя бы раз получалось пробно восстановить данные )
а если tape drive сразу после считывания зажевывал ленту? :)
если копирование было, как минимум, 3-2-1 - быстро, но без паники, делаем ещё один бекап на новый картридж, если нет, то как говорил главный разраб на моей первой работе, "можете начинать впадать в отчаяние" )
записанные лазером в кристалл*
Я про целевое назначение технологии, а не про надёжность резервирования данных. Её, как и безопасность чего бы то ни было, можно наращивать если не до бесконечности, то по крайней мере до полной нецелесообразности.
а вы не читали про историю с ГАС Правосудие, например? Часть данных утрачена полностью и навсегда. Потому что вот такие "нецелесообразные" бэкапы существовали только по документам.
Или, например, в штатах происходит более 1 инцидента в день, связанных с ransomware только в сфере медицинского обслуживания.
В мире, где данные превратились в один из самых ходовых товаров, некоторые меры по их сохранению уже давно перестали быть избыточными
а вы не читали про историю с ГАС Правосудие, например? Часть данных утрачена полностью и навсегда. Потому что вот такие "нецелесообразные" бэкапы существовали только по документам.
Как связано государственное ворьё и нецелесообразность избыточных мер в реальных задачах?
Или, например, в штатах происходит более 1 инцидента в день, связанных с ransomware только в сфере медицинского обслуживания.
И?
В мире, где данные превратились в один из самых ходовых товаров, некоторые меры по их сохранению уже давно перестали быть избыточными
Какие-то да, какие-то нет. Я не пониманию, к чему это сказано. Я написал, что бэкапы в целом избыточная вещь? Нет, не написал. Но то, что вы описали выше - в 99,95% случаев избыточные неадекватные меры.
Как связано государственное ворьё и нецелесообразность избыточных мер в реальных задачах?
так, что были утрачены как продуктивные данные, так и бэкапы, размещенные на серверах/СХД. Кто-то из админов, видимо, заверил, что этого будет достаточно "в 99,95% случаев".
Я не пониманию, к чему это сказано
вот к этому:
для очень важных данных, которые надо хранить долго
Попробуйте посчитать ваши волшебные проценты, не выкидывая это приложение из контекста. (долговременное хранение, по отраслевым стандартам, это > 10 лет, если что)
А где почитать про ГАС Правосудие и "нецелесообразные" бекапы? Естественно, спрашиваю не про новости в лентах.
Зашифровать и выложить в публичный торрент, всем заинтересованным в сохранении данных скачать на свои домашние компы.
Не раскрыт вопрос хранения бэкапов - зашифрованными или нет.
если у вас там хранятся просто деньги или персональные данные, фотки домашнего архива и пиратский софт - то лучше хранить незашифрованными (а безопасность обеспечивать физически - сейфом итд).
А если данные лучше потерять навсегда (потому что забыл где лежит private key, отпаялась микросхема или космический луч случайно попал), чем иметь шанс что кто-то кроме вас их прочитает (терморектально или аналоги) - то храните зашифрованными.
Может возникнуть ситуация, когда диск вышел из строя и его придётся передавать в чужие руки: будь то в лабораторию по восстановлению данных или возврату по гарантии. Так что шифрование в любом случае желательно
Передавать намеренно зашифрованный диск в лабораторию по восстановлению данных - это сильно...
А разве нельзя просто посекторно восстановить данные, не вдаваясь в их смысл?
Это при условии, что на физическом уровне данные не побились. Например, если сдохла механика или отказал контроллер - ваша задумка удастся. А вот если физически диск читается, но файловая система повреждена...
1)можно собрать цепочку, но как убедиться что там данные правильные?
незашированный файл можно попробовать прочитать, а как вы это видите для зашифрованных данных ?
2) если у вас там большие анонимные деньги или данные, которые вам лучше "потерять" чем чтобы их кто-то увидел - тогда конечно шифруйте.
Это NVMe-RAID?
Нет. У нас везде — SSD: они хорошо соединяются в массивы.
Эмм? Wat? NVME уже не SSD?
Нет, я понимаю, конечно, что nvme по последней версии спецификации не обязан быть строго SSD, и может был HDD (а такие есть вообще на рынке?), но я не думаю что такая уже попала к хостерам
А вы уверены что raid 10 надежнее чем raid 6?
В данной таблице также учитывается ошибка чтения (bit error rate) что многие упускают при построении массивов
у меня данная таблица вызывает некоторые сомнения.
Я же правильно понимаю, что в ней утверждается, что за 5 лет у меня гарантированно развалится 5ый (97%) и почти гарантированно 10ый (82%) рейды?
Не совсем. Расчеты на Bit Error Rate (кстати, он тут приведен для бытовых HDD, для серверных обычно заявляют 10^-15) показывают не вероятность вероятность полного выхода из строя накопителей или развала массива по другим причинам, а вероятность получить битые данные.
При ребилде нужно прочитать данные с оставшихся дисков: объемы большие, так что тут казалось бы ничтожно малый BER начинает играть роль. RAID-5 во время ребилда лишен избыточности — этого желательно избегать и использовать RAID-6. Количество дисков в одном массиве тоже желательно ограничить и разбивать большие дисковые группы (вместо 36x RAID-6 использовать три 12x RAID-60, например).
В этой таблице ещё и AFR учитывается (годовая вероятность отказа) и, видимо, рост AFR по мере выработки ресурса, так что таблица ещё и про полную потерю данных, но методика расчета не указана.
Заметьте, эти вероятности указаны для случая, если у вас 12 дисков по 8Тб каждый ;)
Просто не первый год имею отношение к эксплуатации нескольких сотен десятых рейдов, каждый из которых как минимум вдвое больше, как по количеству шпинделей, так и по объему каждого (как раз 24х16TB as usual). Не то чтобы никогда ничего не разваливалось, но табличка с кучей страшных красных девяток немножко смутила.
Хотя если речь о том, что за несколько лет один из 768 000 000 000 000 бит побьётся - ну да, тут сомнений нет, шансы действительно близки к 100% xD
Да. При заданном BER. На практике BER ниже, так что абсолютные цифры в таблице не особо полезны.
Более того, по таблице он развалится из-за того, что его невозможно прочитать без исправления-ошибок-на-лету. То есть при нормальной эксплуатации каждый scrub с вероятностью ~97% встречает ошибки, но они исправляются за счёт избыточности*, а когда массив degraded, то они ведут к потере данных**.
А если scrub не встречает ошибок? То настоящий URE гораздо ниже заявленного производителем - враньё спрятано в этом месте.
* А одиночные диски как, без массива? Полное чтение 8 ТБ тогда должно встречать ошибку в половине случаев.
** Перечисляют такие варианты:
- Худший: заменили диск, запускается восстановление, контроллер решает прибить массив после встречи битого сектора.
- Чуть лучше: процесс прерывается на битом секторе, успешно завершить без простоев и ручной работы с сыпящимся диском нельзя.
- Лучший: битый сектор пропускается и на уровне массива тоже помечается как нечитаемый.
А одиночные диски как, без массива? Полное чтение 8 ТБ тогда должно встречать ошибку в половине случаев.
А на одиночном диске вы эту ошибку при чтении просто не увидите. Читающее приложение получит некорректные данные, а что там с ними произойдет дальше - зависит от приложения. Если это битый пиксель в текстуре игрушки - никто ничего не заметит, а если кусок ключа шифрования... Silent data corruption это вот оно.
Это заблуждения №1 + №3 по первой ссылке (или здесь в соседней ветке о том, что классическому RAID'у нет дела до тихих ошибок - то есть тоже бы не увидели). URE - частота ошибок, которые не исправились с помощью ECC.
Unrecoverable Error — A read error that cannot be overcome by an ECC scheme or by
rereading the data when host retries are enabled - westerndigital.com
Давайте аналогию с ECC RAM проведём.
Там SECDED ECC обнаруживает и исправляет ошибки в 1 бите.
Обнаруживает ошибки в 2 битах.
А ошибки в 3 и более битах может принимать за однобитные или пропускать. Silent data corruption начинается тут.
У вас получилось так, словно второго этапа не существует. Перескочили на третий пункт, вероятность которого гораздо ниже и отдельно не указывается (URE включает в себя в себя второй).
Неисправимую ошибку вы на одиночном диске увидите, "тихую" нет. А рейд детектирует обе. При этом URE рейд сможет исправить, а "тихую" рейд с избыточностью в одну копию - нет, потому что не знает, где правильные данные. А в две - уже сможет и исправить.
что классическому RAID'у нет дела до тихих ошибок - то есть тоже бы не увидели
Ну очевидно же, что это не так - в рейде не совпадет четность или данные на зеркалах.
И да, реальные вероятности ошибок, возможно, и сильно ниже, чем там на скрине написано, но качественной картины это не меняет.
А рейд детектирует обе.
Только во время scrub'а. А при обычной работе будет выдавать мусор. md: "RAID1 ... Changes are written to all devices in parallel. Data is read from any one device".
Знание, что данные побились месяц назад - не очень полезное. Если данные горячие, то они к моменту scrub'а могли перезаписаться и даже этого знания не будет. Если холодные, то толку как от прикладывания md5 к файлам на одиночном диске (без массива).
А в две - уже сможет и исправить.
Но в том же md не станет. Соседняя ветка комментариев.
Ну очевидно же, что это не так - в рейде не совпадет четность или данные на зеркалах.
Уже который раз пишу - она проверяется только во время scrub'а.
И да, реальные вероятности ошибок, возможно, и сильно ниже, чем там на скрине написано, но качественной картины это не меняет.
Не вижу смысла.
Касательно долей "громких" (бэд-блоки) и "тихих" ошибок в URE: классические RAID'ы и классические файловые системы (без контрольных сумм для данных) ещё существуют, потому что URE в основном состоит из "громких" ошибок.
Диск обычно справляется со своей работой (обнаруживать ошибки) и проблема тихих ошибок становится чем-то вроде проблемы памяти без ECC.
Касательно последствий того, что URE ниже верхней границы заявленного: RAID5 в 2009 не переехал в учебник* к RAID2-4 именно поэтому. Крупные диски без массива удаётся использовать тоже поэтому.
* Тут не нужен virtue signalling на тему опасности RAID5, скрытого подтекста нет, там буквальное "не переехал в учебник".
Знание, что данные побились месяц назад - не очень полезное.
Полезное, бесполезное - это уже решать тому, кто массив эксплуатирует. Учитывая, что scrub как функция присутствует примерно в любом массиве, большинство считает, что все-таки полезное.
Но в том же md не станет.
Это сугубо вопрос конкретной реализации. Если кто-то использует md в корпоративных хранилках или на больших массивах - ну, это его личный выбор.
И еще раз - исходная картинка в целом не про то, что там может или не может md или еще какая-то софтина для организации рейдов. Она про то, что вероятность получить неисправимый косяк на рейде с одиночной четностью или зеркалом значительно выше, чем получить его же на рейде с двойной четностью. Всё. Когда этот косяк будет обнаружен, как конкретно поведет себя массив при его обнаружении - это уже детали реализации.
классические RAID'ы и классические файловые системы (без контрольных сумм для данных) ещё существуют, потому что URE в основном состоит из "громких" ошибок.
Они существуют, потому что общая вероятность получить сбои мала, цена ошибки в общем случае не слишком велика, а организация FS или рейда, при котором эти ошибки могли бы детектироваться онлайн - не бесплатная. И чем быстрее накопители - тем более сильно она не бесплатная.
И еще раз - исходная картинка в целом не про то, что там может или не может md или еще какая-то софтина для организации рейдов. Она про то, что вероятность получить неисправимый косяк на рейде с одиночной четностью или зеркалом значительно выше, чем получить его же на рейде с двойной четностью.
Да при чём тут это, я указал на ошибку составителя картинки - он не смог связать в голове теоретический URE и практическую частоту ошибок, получаемую при scrub'е. Похоже на фейнмановское "Я обнаружил очень странное явление: я задавал вопрос, и студенты отвечали, не задумываясь [не задумываясь брали 10^-14 из даташита]. Но когда я задавал вопрос еще раз - на ту же тему и, как мне казалось, тот же самый вопрос, они вообще не могли ответить! [не понимают последствия числа за пределами сценария degraded RAID]".
Указал, потому что меня задевает религиозно-мифический характер этой ошибки. Имею в виду статью о том, что RAID0 надёжнее, чем RAID5 и исступлённые реакции на неё (в ответ иронизируют: "Using RAID-5 Means the Sky is Falling!").
Да, несмотря на эту ошибку RAID5 опаснее, чем RAID6, нам здесь не о чем спорить. Одно дело, когда мы можем пережить отказ 1 диска. Другое дело, когда 2 диска. Про URE можно не вспоминать - сортировку RAID'ов по надёжности она не меняет.
Потом переключились на обсуждение тихих ошибок.
это уже решать тому, кто массив эксплуатирует
А я откажу ему в таком праве. Начали с того, что RAID при чтении на лету сверяет копии (чётность). Оказалось, что нет. Теперь цепляемся за шанс получить информацию о том, что данные побились в прошлом. Это слишком сомнительный подход, если нас волнуют тихие ошибки и непостоянные ошибки вроде misdirected read он не обнаружит.
большинство считает, что все-таки полезное.
Нет, большинство не считает, что scrub существует для борьбы с тихими ошибками в условиях отсутствия контрольных сумм для данных.
Это сугубо вопрос конкретной реализации.
Ars Technica утверждает, что "most arrays don't check parity by default on every read". Где сделано не так?
Если кто-то использует md в корпоративных хранилках или на больших массивах - ну, это его личный выбор.
В таких условиях могут зародиться контрольные суммы для данных (T10-PI и т.д.), которые и обнаружат тихие ошибки. Обнаружат независимо от RAID'ов, о которых мы говорим.
Они существуют, потому что общая вероятность получить сбои мала
Или потому что она для нас велика, иначе зачем нам вообще RAID. Причём адекватно среагировать классический RAID может только на "громкую" ошибку, о которой сообщит сам диск. Если их не гораздо больше, чем тихих - зачем нам RAID? Мне эта версия кажется более логичной.
он не смог связать в голове теоретический URE и практическую частоту ошибок, получаемую при scrub'е.
С этим я и не спорил.
Другое дело, когда 2 диска. Про URE можно не вспоминать - сортировку RAID'ов по надёжности она не меняет.
Конечно же, меняет. Вот у вас RAID-5, один диск вылетел, пошел ребилд, и бац - ошибка. Или на сохранившейся половине зеркала. Что дальше? А в случае RAID-6?
Начали с того, что RAID при чтении на лету сверяет копии (чётность).
Кто начал? Точно не я. Хотя и такие реализации есть .
Теперь цепляемся за шанс получить информацию о том, что данные побились в прошлом.
Нам, в конечном счете, нужна не только информация о том, что данные побились, но и, крайне желательно, коррекция этих данных. RAID-6 коррекцию "тихих" может обеспечить сам по себе. 5 - нет, вот и всё. Я не понимаю, в чем тут может быть предмет спора. Вы считаете, что такая коррекция бесполезна? Ну, это ваше мнение, имеете право. Но сам факт имеет место быть.
Нет, большинство не считает, что scrub существует для борьбы с тихими ошибками в условиях отсутствия контрольных сумм для данных.
Scrub существует для того, чтобы находить и, по-возможности, корректировать любые возможные проблемы с данными на массиве. Не очень понимаю, почему вы так настаиваете на том, что именно для тихих он бесполезен.
В таких условиях могут зародиться контрольные суммы для данных (T10-PI и т.д.), которые и обнаружат тихие ошибки. Обнаружат независимо от RAID'ов, о которых мы говорим.
Или не обнаружат. Эти меры вероятность снижают, и сильно, но не убирают полностью.
Если их не гораздо больше, чем тихих - зачем нам RAID?
Конечно же, тихих куда меньше, это бесспорно. Но они есть, и я не понимаю, почему сей факт над игнорировать при сравнении надежности рейдов.
>> Про URE можно не вспоминать - сортировку RAID'ов по надёжности она не меняет.
Конечно же, меняет. Вот у вас RAID-5, один диск вылетел, пошел ребилд, и бац - ошибка. Или на сохранившейся половине зеркала. Что дальше? А в случае RAID-6?
Не меняет "RAID6 > RAID5", потому что если забыть про URE, то всё равно остаётся вероятность смерти диска (MTBF/AFR).
В сравнении "RAID6 > RAID10" ненулевой URE играет на пользу RAID6 (в degraded RAID10 у нас degraded-зеркало не защищено от URE), а ненулевой AFR может играть на пользу RAID10 (быстрее ребилд - меньше шанс смерти диска; есть шанс пережить смерть >2 дисков в большом массиве), а может не играть (degraded-зеркало не защищено от потери диска). Тот калькулятор говорит, что последний фактор в разумных условиях (не "2 диска чётности на 100 дисков с данными") перевешивает, то есть "RAID6 > RAID10" независимо от URE.
Кто начал? Точно не я.
"А на одиночном диске вы эту ошибку при чтении просто не увидите. Читающее приложение получит некорректные данные" - это утверждение о том, что в RAID мы её увидим при чтении (а не только при scrub'е).
Нам, в конечном счете, нужна не только информация о том, что данные побились, но и, крайне желательно, коррекция этих данных. RAID-6 коррекцию "тихих" может обеспечить сам по себе. 5 - нет, вот и всё. Я не понимаю, в чем тут может быть предмет спора.
Не знаю, как вы перешли к этому от "Учитывая, что scrub как функция присутствует примерно в любом массиве, большинство считает, что все-таки полезное".
Наверное, мы оба сойдёмся на том, что scrub (тот, который сверка копий или чётности) не должен быть первой линией обороны от тихих ошибок (типа "а между scrub'ами пусть читается мусор").
5 - нет, вот и всё
Кстати, случайно наткнулся на утверждение Dell (habr/archive.org), что они могут: "For example, three drives in a RAID 5 array will be compared to ensure that the data and the parity are using the correct values. If a single error[*] is detected, the remaining data and/or parity will be used to re-write and correct the bad value".
[*] и вокруг уточняется: в том числе "logical error", "logical data errors"; "The physical LBA is good" (у-у-у, физико-логический сектор).
Хотя и такие реализации есть
Спасибо, интересно. Хотя написано так расплывчато и подозрительно, что надо читать диплом с сайта СПбГУ (pdf), чтобы убедиться.
Или не обнаружат.
И за это спасибо. Но там видится два больших подвоха:
Проверка чётности во время scrub'а может обнаружить ошибку, которую в ходе обычного чтения перехватила бы проверка Identity ("Note that data scrubs are unable to validate the extra file system identity information")
Misdirected read не упоминается среди причин. Scrub мог обнаружить непостоянную ошибку, которая связана с запуском scrub'а. В этом случае scrub бесполезен - нет пользы от того, что мы "вышли на себя", поможет только проверка Identity.
UPD: вообще говоря, непонятно, может ли проверка чётности обнаружить хоть какую-то ошибку из тех, которые пропустит проверка Identity. Статья интересна сама по себе, но как доказательство, что "не обнаружат" вроде бы не годится.
Тоже прикинул, взял для примера некоторые дефолтные данные - можно по ссылке посмотреть. В статье явно какая то своя собственная вероятность считается. Спрашивается, зачем народ вводить в заблуждение
Probability of data loss over time:
RAID10 - 0.0000017402781203
RAID5 - 0.0000121801881046
RAID6 - 0.0000000001197614
Упоминание в статье про слабую надежность RAID6 связано с тем, что где то разболтался вентилятор и это убило массив. Но это же просто гипотеза, а RAID-10 он что тогда один единственный выжил, так?
RAID 10 хоть и удваивает стоимость, зато обеспечивает прирост скорости как при чтении, так и при записи. В то же время RAID 6 ускоряет чтение, но заметно замедляет запись. В данном случае важно минимизировать просадку производительности во время ребилда.
Стоит отметить, что при увеличении количества дисков RAID 10 выигрывает в надежности: вероятность одновременного или последовательного выхода из строя накопителей снижается благодаря дублированию данных.
Однако при небольшом количестве дисков RAID 6 оказывается надежнее. Здесь, как и всегда, приходится искать компромисс между надежностью и производительностью.
Почему вообще идёт сравнение RAID 6 и RAID 10? А не, к примеру, RAID 6 и RAID 1? Ну или RAID 60 и RAID 10?
Потому что схемы хранения аналогичны по архитектуре. И там, и там используется 2x2 диска, и там и там отказоустойчивость приближается к n/2. Но если в RAID10 у вас откажут ОБА зеркала разом, можете помахать вашим данным ручкой. В RAID6 у вас могут отказать два ЛЮБЫХ диска, и всё равно есть шансы полностью восстановить данные. При увеличении количества дисков в массиве, надёжность RAID10 стремительно падает (или, точнее, непропорционально медленно растёт), в то время, как надёжность RAID6 почти не снижается.
Про RAID5 даже говорить не стоит, ещё 8 лет назад доказано, что при современных объёмах дисков RAID5 ненадёжен в принципе.
Но зачем собирать зеркала в массив ? Почему нельзя отказаться от raid0 в пользу нескольких raid1? Довольно редко попадаются файлы размером в несколько терабайт
Если у вас 10 дисков и это 5 массивов зеркал, то после выхода из строя первого диска, выход только одного из оставшихся 9 приведет к проблемам.
И там, и там используется 2x2 диска, и там и там отказоустойчивость приближается к n/2.
Но нет же, это в RAID 60 отказоустойчивость приближается к n/2 при соответствующей настройке. А в чистом RAID 6 избыточность всегда составляет ровно 2 диска.
Вот я и спрашиваю - какого фига вообще сравниваются варианты с избыточностью в 2 диска из N, и с избыточностью N/2 дисков из N, да ещё и на бесконечности, и на основании этого делаются выводы о бесполезности RAID 6? Почему до очевидного решения собрать эти RAID 6 в такой же RAID 0 автор не додумался?
Да это неверно то что при увеличении дисков якобы RAID10 становится надежней чем RAID6, вот для примера 16 дисков (выше было 8 дисков):
RAID10 - 0.0000348049869834
RAID6 - 0.0000000119738849
Чем ниже число, тем выше надежность, не наоборот
Вы мухлюете. RAID6, как и RAID10, обеспечивает полное дублирование данных.
Незначительная просадка по скорости при ребилде RAID6 компенсируется наличием CRC, что позволяет нивелировать BER (именно из-за отсутствия контрольных сумм ваш RAID10 ТОЧНО будет выдавать неверные данные при длительной эксплуатации).
А можем ли мы быть уверены в том, что контроллер RAID 6 сверяет контрольные суммы при чтении блока, если ни один из дисков не вернул ошибку? В процессе patrol read - да, безусловно, для того он и предназначен. А вот при обычном чтении?
Вы мухлюете. RAID6, как и RAID10, обеспечивает полное дублирование данных.
Есть массив из 4 дисков. Вынимаем любые два. Предположим, что они исправны. В случае RAID-10 вероятность того, что с них можно снять все данные, которые хранились на массиве - 50%. В случае RAID-6 эта вероятность равна 100%.
И это не мухлёж, а чистая арифметика.
именно из-за отсутствия контрольных сумм ваш RAID10 ТОЧНО будет выдавать неверные данные при длительной эксплуатации
Если реализовать его не на уровне аппаратного контроллера, а программно на уровне ФС (ZFS stripe+mirror, например) - не будет.
Вы три дурацкие ошибки допускаете.
Если бы массивы сверяли содержимое дисков не только время scrub'а, то
они имели бы скорость одного диска, даже на линейном чтении. UPD: я тоже их допускаю, в полной мере замедление касалось бы RAID1.Если бы они это делали, то и на RAID1 и RAID5 - тоже. Потому что иметь ошибку при расхождении данных на дисках лучше, чем иметь неверные данные.
UBER (aka URE) в основном состоит из "громких" ошибок, которые за счёт ECC обнаруживает сам диск. То есть он выдаёт не неверные данные, он выдаёт ошибку.
И одну не дурацкую - термин BER используют в том числе для "сырых" ошибок (RBER), которые штатно исправляются через ECC на диске. UBER/URE точнее.
Ещё к 1: например, для md RAID есть подтверждение, что он игнорирует проблему "тихих" ошибок. "If a mismatch is detected in a RAID-6 configuration, it should be possible to figure out what should be fixed", но это требует допущения, что данные побились только на одном диске и этой возможностью не пользуются. check лишь отмечает, что на дисках есть несоответствие, repair лишь заново считает чётность.
От остальных реализаций логично ждать примерно того же, тихими ошибками занимается другой слой (T10-PI / dm-integrity / zfs-btrfs-bcachefs / никакой).
От остальных реализаций логично ждать примерно того же, тихими ошибками занимается другой слой
Хм, проверка чётности при чтении нашлась в реализации RAID3 у FreeBSD: graid3 -w (verify reading feature). И в комментах выше - в различных заоблачных СХД (RAIDIX, IBM), к ним надо добавить SGI, он рассматривал проверку чётности как альтернативу для T10-DIF/PI: SATASSURE=[PARITY|DATA_INTEGRITY_FIELD].
Стоит отметить, что при увеличении количества дисков RAID 10 выигрывает в надежности
В корне неверно. Вероятность отказа 2-го диска во время ребилда равна как из битой половинки, так и из небитой. Либо пишите сразу что у вас много денег тройное зеркало
А как это вообще читать?
Вот беру 4 drives, иду в колонку raid 5 и вижу какие-то циферки. Но...погодите, а как из 4х дисков сделать raid5 и raid6?
Беру 6 drives и недоумеваю, а как из них сделать raid5 (один лишний, куда его деть?) и raid10 (ему же кратность 4х нужна)?
Уточнение: raid10 нужна кратность 2х.
Кажется вы где-то запутались, в "raid5" и т.д. цифра - это же название типа рейда, а не количество используемых дисков.
raid5 - это любые n дисков фактического объёма +1 избыточный (из 4х дисков это 3+1), raid6 - это n+2.
raid10 из 6 дисков - три пары или два тройных зеркала.
Наверно, вы правы. Я до этого думал, что число дисков там неизменно и соответствует цифре (этакая зафиксированная пропорция данных и избыточности) - и можно только кратно увеличить.
Вообще, при такой вольной интерпретации цифр в raid10 из 6 дисков - теперь название рейда уже не отражает одну конкретную систему, т.к. возможны 2 разные комбинации: мы либо stripe делаем на 3 диска, либо mirror на 3 диска - и это теперь 2 системы с абсолютно разными характеристиками записи, чтения и отказа. Наверно, их бы и называть надо как-то по-разному.
RAID10 читается как "raid one zero" - это синтез RAID1(mirror) и RAID0(stripe).
RAID5 это минимум 3 диска с распределённой контрольной суммой. 4-й диск добавляют редко, его использовать можно либо как hot spare, либо как дополнительное хранилище для контрольной суммы. Но в последнем случае лучше использовать…
RAID6 это 2n дисков (не менее 4) с распределённой И ОТЗЕРКАЛЕННОЙ контрольной суммой.
Так понятнее? И вообще, статья на педивикии достаточно полно раскрывает тему для чайников.
RAID5 - это когда по дискам еще + XOR блок от всех блоков в страйпе. Придуман был в то время когда контроллеры еще слабые и ничего серьезнее посчитать не могли.
RAID6 - это уже + 2 блока к блокам страйпа, но не с контрольной суммой, а с кодами коррекции ошибок, эти коды позволяют восстановить любые два из страйпа.
Интересен стал глупейший вопрос: Теоретически скорость восстановления умерших 2х страйпов (реальные данные) или 2 парити отличаются для контроллера? Или в плане времени ему плевать? Парити в отличие от адапта же физически находится на определенном, выбранном контроллером при инициализации диске?
Честно, предположу что вопрос дикий. Но никогда не вдавался в низкоуровневую приципиальную схему ребилда 6 рейда.
Как и не вдавался, как рейд миграция (конверсия) работает.
Там в любом случае нужно поблочно считать все диски и записать отсутствующие. Если не железе не экономили, то в скорость этих чтения и записи восстановление и упирается, сами расчёты отсутствующих данных не фоне вывода-вывода должны быть незаметны.
Блоки парити не на одном или 2х отдельных дисках. Они перемешаны на разных страйпах, соответственно по дискам. Соответвенно от расположения страйпа в массиве зависит где будут в нем эти блоки парити.
RAID-5 вовсе не означает, что он состоит строго из 5 дисков! В нём может быть и 3, и 5, и 8 дисков... ТО же и для RAID-6, только минимально в нём может быть не 3, а 4 диска.
У меня один раз из-за перебоев с питанием на 10 рейде из 8 дисков умерло 4. Рейд выжил.
Статья понятная и представление у меня уже 15 лет именно такое же. Хотелось бы увидеть аналитику в разрезе (стоимость хранения 1 единицы данных)/(надежность) для разных типов рейда и моделей современных дисков. Тогда можно было бы ответить на вопрос: а какой мне рейд собирать с какими дисками чтобы я мог гарантированно сохранить свои данные N часов с вероятностью Х%.
моделей современных дисков
осталось понять, где взять надежную статистику. даже крупный провайдер инфраструктуры пользуется весьма ограниченной номенклатурой дисков, а производители вряд ли публикуют данные, которые выставят их в невыгодном свете
Фиг с ней со стоимостью хранения, есть куда более интересная метрика IOPS per GB.
Я только не понял - а вы не пробовали подумать про hot spare? Это же практически мгновенная замена вышедшего из строя диска, и нет никаких проблем с "могут ждать замену диска и неделю". Да и вероятность "во время ребилда в массиве умер второй диск" тоже изрядно снижается.
Да, это не диск в ЗИПе, его ресурс расходуется (у меня лично был случай, когда умер именно диск в горячем резерве). Да, он кушает порт. И тем не менее это весьма разумный, и не сказать что избыточно дорогой (кстати, подешевле десятки будет), способ повышения надёжности хранения данных.
вероятность "во время ребилда в массиве умер второй диск" тоже изрядно снижается
Почему снижается, запасной диск же один?
Смотря какой РАЙД и сколько дисков в горячем резерве. Ну и, конечно, время реакции на факт выхода из строя тоже важен. Просто наличие дисков горячего резерва максимально уменьшает время от момента выхода из строя накопителя и до момента завершения ребилда - и, как следствие, понижает вероятность утраты данных при кратном инциденте.
Нет, понятно, что если пробьёт блок питания, и на диски начнёт записываться 220 вольт, никакой горячий резерв не поможет.
Hot-spare не поможет сохранить целостность данных при ребилде RAID-5.
Допустим, у нас есть 12 серверных HDD (c Bit Error Rate = 1E-15) по 12 ТБ.
Вероятность получить с одного HDD при чтении всего объёма что-то не то: 9,6E+13 × 1E-15 = 0,096.
Вероятность для 12 дисков нужно считать через дополнение. Находим вероятность того, что всё будет хорошо для 12 HDD:
(1 - 0,096)^12 = 0,3
Находим обратную: 1 - 0,3 = 0,7. 70% — это уже серьёзно. Так что спасёт нас только RAID-6, при большом количестве дисков — RAID-60 с подгруппами умеренного размера (не больше 10-12 HDD) плюс hot-spare, разумеется.
Иными словами, вы просто не поняли, что я сказал. А я рассматриваю только и исключительно два варианта.
Первый - диск вылетел, контроллер подключил hot spare и запустил ребилд, техник через Х времени пошёл за новым диском на замену, принёс, вставил.
Второй - диск вылетел, техник через Х времени пошёл за новым диском на замену, принёс, вставил, контроллер запустил ребилд.
Всё, больше ничего не рассматривается и ничего не сравнивается.
Hot spare от выхода из строя второго диска во время ребилда не спасает никак. У нас в каждом дата-центре есть оперативный запас дисков и замена происходит очень быстро. В данном случае hot spare мы все равно изучим как мысль, спасибо!
Повторюсь - количество hot spare дисков не обязано быть единичным. Более того, они обычно не привязываются к массиву. То есть грубо - у вас, скажем, есть полка на 48 дисков, из 44 вы собираете 4 райда-шестёрки по 10-12 дисков, и 4 стоят в горячем резерве. В каком бы из массивов какой диск не навернулся, резервный тут же займёт его место. То есть вроде бы по арифметике и по одному диску на массив, а на практике у каждого массива их аж 4.
В том и проблема, что тут же не займёт место. Начнётся ребилд, в этом и есть шанс умереть.
В том и проблема, что тут же не займёт место.
Да? Тогда вопрос - а как ВЫ видите процесс включения диска горячего резерва в работу?
Начнётся ребилд, в этом и есть шанс умереть.
Шанс-то есть всегда, даже когда диск лежит на складе в коробке. Но обоснуйте, почему ребилд, по вашему мнению, повышает вероятность выхода накопителя из строя.
Потому что при ребилде постоянная занятость рейда - прочитать-пересчитать-записать. Нагрузка сильно выше.
Примерно по той же причине по которой "снапшот снижает производительность вм". Количество iops в 2ое больше на каждую операцию.
Запустите в Виктории тест вида read-write-verify. Оцените изменившуюся скорость, температуру, нагрузку на диск :)
По опыту, 10 тоже умирает при потере двух дисков. Если не повезет. По примерно описанному сценарию. Возможно, не все такие случаи в статистике учитываются.
По опыту, 10 тоже умирает при потере двух дисков.
Ну не умирает, а может умереть. Для десятки из 4 дисков это будет 50% - могут помереть одинаковые в парах, а могут и разные, и тогда из оставшихся двух информация поднимается стопроцентно. Не скажу за "средствами контроллера при ребилде", но вручную при отсутствии шифрования - точно.
Была у меня такая история, RAID 5, диск помирает, ставлю другой, ребилд и помирает Raid-контроллер. Купили какой то ноунэйм, пожадничали.
К сожалению, и на вполне приличных неноунейм системах случаются вылеты контроллера или глюки в прошивках с печальными последствиями. Тут только бэкап спасает и нормальная поддержка.
В большинстве случаев бекапы лежат на таких же RAID-массивах, так что к ним применимо всё тоже самое, и вылеты контроллеров, и дисков.
Про них гораздо больше пишут и говорят, чем не то что используют, а хотя бы видели оборудование вживую.
Можно домой купить ленточное оборудование по цене 3-4х 8ТБ дисков. Вот тут и думаешь, а нужна ли лента или можно использовать большие hdd как картриджи для холодного хранения
а хотя бы видели оборудование вживую
Ну, я видел. И не только видел. Если чо, я админом тогда работал, главным.
Кто последний эникей в фирме остался, тот и главный архитектор. Ну знаете сами :D
Весело еще подпихивать в эту ленту периодически чистку головки, вычитывать бэкапы раз в какое то время, подсовывать чистящие касеты, менять вылетевшие ленты, порой смена касеты лагает. И при этом все настолько быстро происходит, что я шатал трубу этого недообразия времен второй мировой.
Имел тоже дело с HPEшной лентой. То ли г4, то ли г3. Та, где вебморда на iLo3 похожа. То количество гемороя с ней в совокупности к убогому Veritas-у (стоял у клиента), вложенному времени и т.п.: проще купить нормальную полку и забыть :D
Я в начале-середине нулевых работал "сисадмином средней руки" у провайдера (они же тогда зачастую и хостерами были). Так вот, был девайс у нас, до которого руки ни у кого не доходили: ленточная библиотека LTO (уже точно не помню какого поколения) с чейнджером на 6 кассет. А основной ОС у провайдеров в то время была FreeBSD. Так вот, одной из первых задач на работе была "разберись и запусти". А на десктопах у нас тоже FreeBSD или Linux стояла. Ну я с ней конкретно помудохался (как сейчас помню, это была Amanda ранних версий) - но завёл на своем компе, о чем и отчитался шефу. На следующий день прихожу на работу - комп выключен. Включаю - загрузка с диска не идет (но в BIOS определяется). Я слегка в шоке. И тут заходит шеф: "Настроил? Все работает? Тогда ВОССТАНАВЛИВАЙ! Включаю таймер, время пошло".
Восстановил. Минут за 40.
Больше зависит от рассматриваемого сегмента экономики и его субъектов. В малом бизнесе лента будет легендой, в среднем скорее тоже, в крупном бизнесе лента используется активно.
В коммерции "купи/продай" с ленточными бэкапами скорее никак, никогда не видел. В промышленности - по всякому, в зависимости от конкретного субъекта.
В госах вообще своя собственная атмосфера...
Прод и бэкап - две независимые системы (рассматриваем случаи грамотного проектирования). Полагаю, не надо объяснять, как считается вероятность отказа двух независимых систем одновременно?
Интересно бы услышать разную статистику по объемам умирающих hdd, ssd, m2.
А разве хорошие серверные NVMe ссд помирают так чтобы совсем? Они же вроде тупо в ридонли уходят, если ресурс закончился или посыпались внезапные ошибки на записи...
SSD - это, очень грубо говоря, плашка памяти с управляющей электроникой. Умершую память никогда не встречали? А материнки и всякие контроллеры?
Конечно помирают. Как и процессоры, материнские платы, etc
У нас пока ни один NWMe не умер, не можем поделиться опытом)
очень даже) да и так, что потом центры восстановления данных с банок ничего прочесть не могут))
Не про полное помирание, но помирание.
Стояли в зеркале два NVMe для NAS (WD Red SN не энтерпрайс решения) и все было хорошо пока раз не обнаружилось через 6-9 месяцев что диск пропал из системы, пока решалось что и как оказалось что обесточивание компьютера возвращает диск в работу, через несколько месяцев повторение ситуации, после этого замена на SATA решения т.к. доступный ассортимент скукоживался в связи с известными событиями. Компьютер никогда не выключается. В англоязычном сегменте для этой модели несколько упоминаний о похожих симптомах. А если бы такое без RAID.
оказалось что обесточивание компьютера возвращает диск в работу, через несколько месяцев повторение ситуации
Аналогичная ситуация была с NVMe SSD HP EX950, думал что проблема только в периодической недоступности диска, а на деле всё оказалось хуже - часть данных на диске "занулилась", ладно данные были не критичные, пришлось "разжаловать" этот диск в внешнюю "переноску" для файлов.
У некоторых от нагрева и времени безсвинцовый припой отлетает и привет, ридонли не поможет.
В R\O уходит только в случае невозможности записи по причине износа или какой-то нефатальной программной ошибки.
Помимо банков флеш памяти есть куча других точек отказа, где устройство просто не сможет инициализироваться.
Помню одну одну историю как один знакомый пытался устроится в рувдс на одну из руководящих должностей. Самый первый вопрос был, чем отличаются TCP от UDP. После первого вопроса поняли что не подходят друг другу. Если по теме, то как правило не хватает всегда дисков и все диски работают на износ. Ни когда не видел, что бы изначально были хоть какие то разумные расчёты.
чем отличаются TCP от UDP.
А руководитель должен это знать? Его задача - координировать действия тех, кто знает, и сделать это (решить проблему): а) с минимально возможными последствиями; б) быстро; в) недорого.
Ваш знакомый отказался или не смог ответить на предварительном собеседовании на один из вопросов по устройству сети. К сожалению, мы не смогли рассмотреть его резюме в дальнейшем.
диски, конечно, — расходники, но при этом недешёвые.
Спорное утверждение, сейчас любая память дешева как никогда. Просто рынок движем мамкиными скупердяями для которы хостинг за 2.99 гораздо более предпочтителен, чем за 5 или 10, хотя по сути разницы нет совсем. И это понятно, большинство задач не чувствительны к потери данных.
Забыли упомянуть, что R10 производительнее R5 в 2 раза и R6 в 3, в общем случае.
Только не везде она нужна. Полка с нормальными контроллерами вполне так неплохо кладет данные на 6-ой рейд.
Ну и опять же кейсы. Бэкап сервер например. 14 дисков по 10 тб. Сильно уверены, что вам на инкрементные бэкапы нужны скорости уровня пушка-гонка в несколько в 5 ГБ/с? Так то такое кол-во шпинделей вполне себе нормально 500-600 МБ/с на запись выдают при условии какого-нибудь PERCа с 8 гб кэша.
Большой красной кнопки с golden решением не существует.
Мы решаем так: Raid6, туда где можно помедленее и позволителен простой, Raid10 - везде, Raid10+HS туда где должно работать максмально шустро.
Остальное на уровне приложений: кластера, реплики, бэкапы
Ваша статья про рейд массивы из NVME дисков датируется 2021 годом. На дворе 2025 . Насколько я знаю рейд контроллер Dell H965i вполне себе позволяет их создавать и просадка в производительности по сравнению с одним диском очень небольшая
У нас всего 3 СХД по 12 дисков в raid 6. За 10 лет был случай одновременного выхода из строя дисков одной партии. В один день. И было 2 случая выхода из строя второго диска при ребилде. Два из трёх СХД отзеркалены и географически разделены. Третий СХД это холодный бекап. Предполагается, что холодный бекап сохранится, если все остальное подвергнется воздействию шифровальщика. Думаю, такой подход достаточно надёжен, чтобы спать спокойно
Никакой подход не позволяет спокойно спать. К сожалению :(.
Ну т.е. либо некий пофигизм, либо "фиг заснёшь". Всегда можно придумать сценарий отказа :(
Предполагается, что холодный бекап сохранится, если все остальное подвергнется воздействию шифровальщика.
А если шифровальщик никак не проявляет себя в течении скажем месяца? Думаю, за это время ваш холодный бэкап уже отравится.
Это вообще как?
Ну вот так - шифровальщик шифрует данные, но расшифровывает налету при запросе из пользовательских программ, так что заражение не заметно. Бекап, если создаётся не на уровне данных программным образом, а например копированием данных "уровнем выше" (копирование файла виртуального диска vps у провайдера)- копирует зашифрованные данные. Восстановление из этого бэкапа приведёт к восстановлению зашифрованного диска, расшифровку которого умеет шифровальщик, но если вы восстановили бэкап - вероятно потому, что шифровальщик уже вымогает с вас денежку и откажется расшифровывать налету после восстановления из бэкапа.
Так ведь состояние шифровальщика тоже будет восстановлено из бэкапа, если бэкап был сделан "уровнем выше".
Холодный бэкап - это, в обсуждаемом контексте, тот, что лежит вне доступа после снятия. Разумная стратегия бэкапа обычно подразумевает хранение неизменяемых копий данных глубиной от месяца до нескольких лет, в зависимости от типа данных и потребностей.
Возьмете более старый бэкап, тут уж ничего не поделать.
При актуализации бекапа сначала запускаем Robocopy в режиме сравнения с записью в лог. Если будут массовые аномалии в виде измененных файлов или метаданных, мы это сразу заметим и запись в бекап только после выяснения причин массового изменения файлов.
Это если вы делаете пофайловый инкрементальный бэкап на программном уровне в самой системе по какому-то сетевому протоколу на не локальное устройство, доступ к которому не может быть перехвачен шифровальщиком, прикидывающимся драйвером. Если бэкап создаётся "выше уровнем" - системой снапшотов диска на уровне провайдера виртуализированного оборудования например, то такие бэкапы будут содержать уже зашифрованные данные. Кстати шифровальщик может оказаться "хитрым" и шифровать файлы постепенно, по мере доступа к ним со стороны программ. Тогда изменения файлов будут совпадать с временем их использования. Я к тому, что проверка бэкапов на валидность должна производиться периодически, чтобы corruption было обнаружено до того, как бэкап таки понадобится прямо здесь и сейчас.
Да, вы верно заметили, я описывал наши действия применительно к файловому резервированию. И организация доступа к СХД с бекапами не подразумевает постоянное включение в сеть и хранение паролей где-либо кроме мозга. Поскольку на СХД есть версионирование, то переполнить его частиичным заспамиванием шифрованными файлами и не вызвать рано или поздно подозрений, я считаю крайне маловероятным.
А ВМ резервируются по другому контуру. Там и содержимое ВМ отдельно, и состояние ВМ отдельно.
В RAID 10 -- резервирование 2N
- ага. но только у везучих.
Почему-то никто не вспомнил про сигейты и муху це-це
Это дела давно минувших дней, меня больше волнует почему никто не вспоминает о проблеме с HP дисками когда они умирали когда у них счетчик отработанных дней переполнялся. https://habr.com/ru/companies/ruvds/articles/681158/
Еще лет 25 назад была проблема с DTLA серией от IBM
В RAID 10 -- резервирование 2N
- ага. но только у везучих
Я же правильно понимаю если брать минимум из 4 дисков.
R10 и R6 Выживают при отказе любого из дисков.
Если при ребилде отказывает диск то в случае R6 это может быть любой диск. А в случае R10 может не повезти и будет потеря данных ?
Было 4 диска, осталось 2. Но в случае RAID10 это могут быть два диска с одной и той же половинкой, и вторую не восстановить. В случае же RAID6 данные восстанавливаются по любым двум из начальных 4.
Так что с формальной точки зрения вы правы. А с практической - в случае 10 всё и так понятно, а в случае 6 ещё неизвестно, как поведёт себя контроллер. Сможет ли он опознать дуплет и отребилдить оба несинхронизированных диска, пусть формально и обязан.
Бредите. Правда. Что значит "сможет-не сможет" ? Это "ну нишмагла я…" что ли?
На практике с дуплетами (не два сразу, а именно один, а во время ребилда второй) не сталкивался. Отчёта о таком инциденте - не видел и не читал.
А вот как раз с ситуациями из разряда "должна я, но не шмогла я" - сталкивался. Пример из жизни: вынули из корзины 3 диска, случайно вставили не в том порядке - и контроллер отказался пересобрать массив. Хорошо, окончилось нефатально - с четвёртого раза порядок угадали.
Блин, сколько уже лет в подобных темах читаю истории про корявые контроллеры. Там же алгоритмы не рокет саенс, за столько лет сколько RAID существуют так и не научились нормально делать?
В аппаратном контроллере, предполагаю, очень упрощённые алгоритмы. Печально.
R740xd. Глючный бекплейт рандомно отрыгивал часть дисков. Каждый раз случайное количество. Все разы массив себя поднимал после power draina.
Фактически, как мне кажется, зависит от глючности FW. Порой ченджлоги встречаются вида "определенное количество команд таймаутов, отрыгивает диск из массива". Но опять же. В некоторых стораджах можно зафорсить диск обратно при определенных ивентах. С огромной 72 шрифтом припиской "только если очень уверены что диск жив".
RAID - это не бэкап. NAT - не фаервол. Сколько можно твердить? Хотя... Без буратин же никуда.
Сюрприз!
Выход из строя двух дисков может убить и десятый рейд. Просто вероятность меньше. Грубо говоря, вероятность смерти рейда при выходе второго диска в десятке из 4 дисков 1/3, из 6 - 1/5. И т.д. 14 - 1/13.
Шестерка же от двух дисков не гибнет.
Может лучше пустить лишние диски на бэкапы, чем почти удваивать количество дисков?
Там ведь ещё и скорость растёт, и диски становятся сравнительно починяемыми, и ребилд есть шанс завершить до смерти админа.
Беда в том, что вероятность не меньше.
Когда диск выйдет - она меньше в N раз. Но вероятность того, что диск вообще выйдет из строя в N раз больше. Больше дисков - больше вероятность.
Грубо говоря у вас есть надёжность каждого диска, вероятность выхода его из строя, и как диски не комбинируй она не меняется.
и во время ребилда в массиве умер второй диск
Пффф. Добро пожаловать в реальный мир, это старо собственно, как и сам RAID5, во время ребилда ещё может и сам контроллер сказать «я устал я ухожу». Вообще, успешный ребилд RAID5 можно получить только в лабораторных условиях.
Ээээ, судя по посту и комментариям у вас там даже hot spare не было?! 30 лет назад, когда я работал на ИВЦ Прив. ЖД у нас там были RAID5 с hot spare и всё было отлично, только вот админы настолько расслабились, что сначала умер диск в рейде, рейд автоматически подхватил hot spare и заребилдил, потом через какое-то время умер ещё один диск... А когда админ наконец-то чухнулся и заменил один из умерших дисков, ребилд шёл очень долго и в его процессе умер таки ещё один диск. Но это потому, что и админ прощёлкал один умерший диск и поставки дисков IBM шли очень долго, их нужно было заказывать заранее и у нас в какой-то момент просто не было дисков на замену.
А ещё у нас был случай (и, кажется, не один), когда в рейде 1 умирал контроллер, похоронив с собой оба диска.
Ну если контроллер использует DDF метод (не проприетарный, где данные о рейде пишутся в DDF), то можно тыркнуть в любой другой схожий и оно подхватит.
По этой причине очень весело незатертые диски пихать в живой сторадж какой, а потом внезапно получать второй массив, где жив один диск. Вынимать этот диск, а массив то не удаляется. Где-то решается ребутом контроллера, потому что удалить ghost рейд-потеряшку, когда он ссылается на занятые диски в прод сторадже - стальные яйца, как минимум :) На днях столкнулся, но сторадж оказался потупее: вынул диск, призрачный массив пропал.
Мораль сей басни такова: трите диски перед тыканием во всякие дырки, дабы не сесть жопой на кактус.
Мы используем системы хранения данных Dell и IBM, обе из которых предлагают технологию ADAPT Distributed RAID. Это намного лучше, чем Raid 6 или Raid 10.
Почитал про него. Такой размазанный не по всем дискам 6й рейд. Но сделать такой в сравнении с обычным 6 рейдом можно только от 12 дисков. И ADAPT рейд сам по себе быстрее и ребилдится тоже быстрее. Логика контроллера сильно сложнее, и мне непонятно где и как хранится карта страйпов в таком рейде.
https://community.spiceworks.com/t/how-does-adapt-distributed-raid-work/701201/2
хех, у нас однажды развалился RAID10. Два диска сразу. Нам категорически повезло, что они сдохли накрест, так что после дня гугления и экспериментов "на кошках" мы нашли, где записана информация о принадлежности дисков, и смогли собрать половинку рейда, после чего за следующие два дня пересобрали его целиком на новых дисках уже. Ночные бэкапы были, конечно, и эти три дня контора работала на "времянке", но хоть не убили сразу.
засетапил RAID500
Сгорел датацентр
Для меня удивительно, что вы вообще используете RAID5, когда примерно во всех местах, где он описывается, предостерегают от его использования именно по причине высокой вероятности умирания еще одного диска при ребилде.
Недавно у нас развалился RAID 5.
Много лет назад, когда я начинал вникать в системное администрирование, случился этап ознакомления с рэйдами и их теоретической базой. Где-то на подкорке записалось "фатальнее raid5, только raid0" (из практически эксплуатируемых). Через несколько лет опыт пополнился закрепом этой информации -- двое суток восстановления клиенту развалившегося raid5 с "матрешкой" -- VMFS, внутри ntfs, на которой БД с данными различных баз 1С. От ребилда отказался, так как весь набор дисков был из одной партии и был высокий риск потерять данные в полном объеме.
По примерным прикидкам, клиент за эти двое суток простоя (+ оплата моего труда) потерял раз в 20 больше, чем сэкономил на эксплуатации raid5.
На протяжении всего времени занятий системным администрированием меня не отпускает предположение, что raid5 с критически важными данными используют люди верящие в чудеса и деда мороза.
p.s.: Выше комментарий в тему оставили, пока я набирал свой.
Совершенно верно. Пятёрку можно только для домашней торрентохранилки на 4 диска исключительно из соображений выглядывающей из-за угла жабы.
К слову о жабах. При отказе двух дисков в RAID5 мы теряем все данные из-за страйпинга, а не только данные одного диска.
Жаба спрашивает: почему бы тогда не выкинуть страйпинг? Но мы всё равно будем терять часть данных на выживших дисках как в JBOD (aka Span) - на живых дисках не будет целой файловой системы и файлы могут простираться между дисками (выживут лишь обрывки). Чтобы этого избежать, нужно объединение на файловом уровне, а не блочном (как mergerfs вместо JBOD/Span).
Жаба спрашивает: почему бы тогда не объединять диски на файловом уровне вместо блочного? В итоге жаба своими вопросами достала людей и они сделали Unraid и SnapRAID.
Дополню, в СХД для резкого сокращения времени перестроения массива, с многих часов и даже суток до пары часов или меньше, и, бонусом, некоторого снижения вероятности возникновения в этот момент ещё одного отказа, применяется технология распределённого резерва, distributed hot spare. При этом вместо отдельного выделенного диска, в скорость и время полной записи которого упирается ребилд, на каждом из дисков массива выделяется резервная область, так, чтобы суммарный объём этого резева со всех дисков был равен одному, для RAID5, или двум, для RAID6, дискам. Это позволяет распределить запись по всем N дискам массива, ускорив её почти в N раз по сравнению с одним диском hot spare (или заменённым). Почти - потому что будут потери времени на позиционирование, диску надо и считать с себя одни блоки, и записать на себя другие, в резервное место. Жаль, что эта технология никак не попадёт в обычные RAID, вероятно из-за патентных ограничений?
Ну и, да, даже обычный hot spare даже при условии присутствия дежурного персонала 24/7 покрывает часть рисков вида "не заметили вовремя / проблемы с поставками / проблемы с совместимостью / etc", но, да, стоит денег и места в сервере или СХД. Мы на делали hot spare только когда в сервере всего 4 слота под диски, и быстродействие требовало RAID 10, в остальных случаях всегда старались сделать. В случае большого количества дисков (10+) даже два hot spare, и потом это очень пригодилось, когда что-то случилось с быстрыми поставками дисков.
Выше уже писали, это ADAPT рейд. Проблемы две тут 1. Он от 12 дисков начинается. 2. Карта страйпов его динамическая, в отличии от статической на обычных рейдах, и если она по какой причине накроется - это накрывается весь рейд без возможности восстановления. Так как невозможно угадать какой блок принадлежит какому страйпу.
Угу. Подтверждаю речь про MSA-DP+ или ADAPT. Проблема одном. Потери дисков в сравнении с классическим raid6
Одна мааааленькая проблема его. Дохрена потерь.
Возьмем 12 дисков по 6 тб. (12-2)*6тб и минус 20% = получаем юзабельные 48 тб. Из 72 raw.
Теперь представьте полку на 24 диска и попытку сделать актив-актив с 2 диск группами. Имеем потери - 4 диска вместо 2х в сравнении с рейд 6. По факту -8 дисков из 24. Нет, конечно если у вас 1-2-3 безмозглых полки дополнительно (экстеншенов), то вы в шоколаде. В ином случае - ну вы поняли. Проще тогда уж гибрид собрать, прикинув размер ссд под горячие данные.
Это правда: ни одна схема резервирования никогда не гарантирует 100 %.
Я свои основные данные храню на нескольких компах плюс нескольких серверах плюс нескольких HDD и часть из них лежит вне дома.
Может глупый вопрос, но тем не менее - а нельзя перед ребилдом запустить бекап данных? Или нагрузка на диски одинакова?
Как ни смешно это звучит, если у вас развалился рейд5 и вы боитесь потерять данные, вам действительно нужно сделать полный бэкап всех дисков. Только не на живой системе, а загрузиться с пустой ОС и по очереди скопировать все диски на новые. Объясню:
Нагрузка на диск при линейном чтении минимальна - есть шанс не угробить данные
Нагрузка на RAID контроллер при линейном чтении минимальна и мы не допустим перегрева из-за постоянного пересчёта контрольных сумм, кэширования, етц
Если вы не смогли в тепличных условиях считать все данные с диска, значит вам ничего не светило при ребилде.
П.С. это только про диски с моторчиком, у ССД все по другому...
Надо иметь куда. В целом нагрузка одинаковая и там и сям надо все данные прочитать.
Другое дело, что если во время чтения всех данных диск выйдет из строя, то это значит что он в общем-то уже вышел. Просто вы об этом еще не знаете. Данных уже не извлечь.
По факту, для этого и нужен патрол чек в фоне.
И кстати бэкап клево, но при условии, что кто-то перед этим хотя бы оставил включенный консистенси чек / проверку чексуммы / <как там ее производители не называют>. А то есть веселый шанс получить набор битых файлов, т.к. они все равно не соберутся красиво в нужные :D
При запуске бэкапа система нагружается, что только увеличивает риск проблем при ребилде.
Меня прям удивляет экономия на спичках^W дисках. Если брать нормальные, ent-grade диски, они умирают крайне редко. Даже под VDS (мы тоже хостер, и таки тоже имеем опыт).
Но RAID5?! Это же максимум домашний NAS, когда данные в принципе жалко, но на четыре диска и RAID10 жалко деняк.
Да даже тут на хабре писали (очень давно!), почему RAID5 нельзя использовать в проде (хоть с hot spare, хоть без...) С тех пор всё стало сильно лучше - диски подешевели (даже флеш), и RAID10 уже не стоит, как крыло от боинга (а если в сервере 8+ дисков, то и "убиваться" они будут медленнее, чем 2-4 бОльшего объёма.
Так для 8 штук при рейд10 можно вытянуть черный билетик, а при рейд6 вроде как нельзя. (при отказе пары). Другое дело, что в рейд10 может из строя выйти 4 штуки без последствий (если повезет) а в рейд 6 только две. А если у вас 4хРейд1, то после смерти 4х дисков, данные начнут потихоньку испаряться, а не все сразу (т.е. если из строя вышли все зеркала 4шт, а потом еще один диск, то три рабочих у вас останется).
4xRAID1 дороговато с т.з. пенальти на запись (хотя если у вас поверх этого какая-то фс или другой способ рандомной записи на каждый чанк, то в целом пойдёт).
Насчёт чёрных билетиков - на восьми дисках как раз RAID10 вылет любых двух переживёт (у вас будет один degraded raid1 и один "здоровый" в RAID0). но при этом при ребилде у вас будет пересчитываться не весь объём целиком (как в RAID6), а лишь половина.
Но не обязательно собирать именно 10. Вы можете собрать 4 отдельных R1 массива в R0 (силами ОС, или если контроллер позволит), либо два R0 в R1 (вот тогда может не повезти, да)
Если два зеркальных диска умрут, то как raid10 переживет ? Не переживет ведь ?
т.к. RAID10 - это RAID0 и двух R1, то на 8 дисках вылететь могут любые два (по одному из каждого R1 или два в одном R1)
В смысле "могут"? Мыж берем худший вариант.... Что будет, когда вылетят два неудачных диска.
Тут еще есть большая неприятность с р0 связанная с тем, что при смерти этих двух дисков весь массив данных будет потерян. И с этой точки зрения, кажется, что в р0 их вообще не надо собирать...
дубль
Да там писать не надо. RAID 5 успешно умер после 2000 года, когда диски стали >1ТБ. Ребилд массива в 1.5 дня - это даже не смешно. А когда диски стареют - это еще более, чем не смешно. Особенно смешно, когда это сторадж с 16+ дисками.
А как так получается ? По идее ведь должен просто прочитать все диски и сбилдиться? Откуда столько времени набегает ?
Хз. 2 последних ребилда дохлого диска заняли больше суток с учетом 100% (или high) приорити. В обоих случаях 5 рейд. Первый синолоджи ds18 чтото там на 8 дисков. 6 дисков по 6 тб сата 7.2к ребилдил больше суток точно. + На всякий пожарный посчитать crc всего массива (нашло пару битых файлов и не смогло восстановить. Дебилушка он. И это все с учетом расписания проверки массива. Выше кидали скрин вероятностей CRC. Я вот вытянул билетик, выходит) - еще около суток.
2ой случай - прошлые выходные. массив. Полка из 16 дисков по 4тб. 7200 сата диски. 1.5 суток ребилда того же 5ого рейда.
Ооочень сильно зависит от реализации со стороны производителя еще.
Оффтоп: На последнем я чисто поржать запустил миграцию в 6ой рейд. Жду: сдохнет или нет (вообще не опечалюсь, если оно сдохнет вместе со всеми данными. За 4 дня пока целых 5% при общей скорости массива в 220~ МБ/с (сколько из них чтения, а сколько записи - хз). При ребилде общая скорость была в районе 400-450 МБ/с
На синолоджи выше этот замечательный процесс занял 28 дней :D у них там какая то уберикривая реализация (впрочем прод энтерпрайза и синолоджи - это антонимы). Выше 6-8 МБ/с на диск не видел при миграции.
З.ы. сам себе отвечу. Чем больше шпинделей для 5-6 рейда, тем труднее и дольше считать парити.
Да как такое может быть:)? Он же на запись не 1мб/с? Ну т.е. штатно когда вы на него что-то пишете совершенно ведь тоже самое что при ребилде должно происходить... исключая элемент чтения с дисков. Т.е. медленно это может быть казалось бы только в случае, когда какому-то из дисков уже очень хреново и он скажем по таймауту ошибки возвращает, а рейд его все переспрашивает и переспрашивает...
У меня скромные хранилища и в основном 10, думаю на 1 переехать при случае, скорость особо не нужна.
И основным аргументом при выборе было то, что 5й я боялся при любых проблемах тупо не пересобрать...
Да как такое может быть:)?
контроллер без кэша
Ну всякое бывает. Можно напихать SMR дисков, которые будут падать в 100%, когда у других будет 30-60%: https://i.imgur.com/SJMnDcZ.png
У стораджа с 8 февраля, например, 14% конверсии RAID5>6. Но там хлам вида: интерфейс SATA2. И ddr2 кэш на 512 МБ его не спасает :D
Еще бывает другой вариант: когда реализация рейда крайне хреновая. И поляна одного из дисков покрыта конским количеством таймаутов или диск весь в пендингах. но RAID не хочет его выплевывать и весь рейд превращается в лагистан и поиск кривого диска. Так был опять же с синолоджи. Просто висло на smart long тесте. Ждал неделю. Плюнул. Вставил в комп. Тонна пендингов. Отрезок поляны просто не читается практически. Как ни странно - оказались софт бэдами. Решилось после множественной перезаписи отрезка.
Смотрите, при классическом RAID, без distributed hot spare, вам, в общем случае, надо полностью записать данными один диск, который установлен на замену отказавшего. С современными объёмами дисков простая линейная запись всего диска легко занимает несколько часов, 4-8-10+ часов только непрерывной линейной записи. Если запись будет не подряд, а с позиционированием, ближе к случайному вводу-выводу, где скорость классических жёстких дисков резко падает, надо ведь головки спозиционировать(а основную нагрузку, в том числе запись, с массива никто не снимал) - будут и сутки, и не одни.
Подождите, вы ещё откроете для себя RAID 50 и RAID60 и хабр увидит статью "Почему мы перешли на RAID 60"
На пальцах обьясните кто-нибудь, в чем профит 60 рейда? С учётом скорости, потери емкости и т.п.
Скорость компенсируется именно 0-м рейдом сверху.
Скорость 0 зависит же от количества устройств из которых он состоит.
На 8 дисках raid10 будет состоять из 4xraid1 со скоростью в 4 попугая, а raid60 из 2xraid6 со скоростью в 2 попугая. При этом полезная емкость будет в обоих вариантах одинакова. Или я не так считаю? (да я помню про рейдовое пенальти, но с другой стороны подсчет контрольки тоже жрет ресурс)
Когда-то давно делал нагрузочное на одном и том же железе с одними и теми же дисками собирая различные конфигурации рейдов (как раз была идея уйти с 10 куда-нить где емкость меньше теряется), точных цифр не помню, но 60 точно не устроил по скорости записи, несмотря на явный выигрыш в объеме.
Софтовый линуксовый raid6 даже в случае механики замечательно разгоняется на запись в 4-7 раз при помощи одной крутилки и выноса bitmap куда-нибудь наружу (например на системные диски). Благо битмап потерять вообще не критично. А если из ssd строить, то там и на порядки можно выжать.
И перед зеркалами всех разнлвидностей у raid6 есть одно важное преимущество: erasure coding в нём - неотъемлемая часть и битовые ошибки исправляются автоматически штатной регулярной проводимой scrub проверкой.
Характеристики не падают при масштабировании.
Уменьшаем fault domain. Большая группа RAID-6 (например, 32 диска) будет ребилдиться очень долго (т.к. обычно это происходит под нагрузкой — в зависимости от объема HDD и нагрузки это может занять недели), а это потеря производительности и рост вероятности отказа второго HDD. RAID-60 в виде 2x 16 HDD уже лучше, хоть и ценой дополнительной потери объёма. В большинстве случаев лучше не делать больше 8-12 HDD в подгруппе, но иногда можно так сильно и не дробить, многое зависит от объема HDD, критичности данных и т.п.
Пользователи заказывают услугу бекапа менее чем в 3 % случаев
Ну так определиться стоит, что вы продаете. Дорого и мало или дофига и много с овербуком стремящимся к 1:7-1:8.
У всех болИе-ЛИ-менее нормальных хостеров услуга бэкапа включена в договор по дефолту. Жрать не просит, успешно интегрируется в цену, легко продается более частый план обьяснением, что между недельным RP и суточным RP разница в 6 дней, 23 часа и 59 минут потери данных. Закрытие месяца делать второй раз весело.
С нетерпением жду следующей статьи под заголовком "Почему мы перешли на RAID1e с far3 layout" или "Почему мы перешли на RAID-Z3" =)
Почему-то все, кто использует классические разновидности зеркальных массивов, упорно забывают, что в реальном мире при использовании многих распространенных ФС, не имеющих на борту контрольных сумм, бывает невероятно прикольно обнаружить, что у вас две копии одного блока немножечко не одинаковые. И потом гадать какая из двух побитая, а какая эталонная.
Почему то думают только об аппаратных RAID, хотя например ZFS решает очень много проблем RAID. C ним нет варианта, когда 1 сектор на диске умер и RAID контроллер лапки понял. Система с ZFS укажет даже какой конкретный файл не удалось восстановить.
Настроить RAID-контроллер того же делла сможет джун по мануалу, и это будет работать с любой ОС.
Правильно приготовить и потом админть ZFS - это уже для квалифицированных специалистов, а если в качестве ОС не линукс, например? У коллег из ruVDS, емнип, бОльшая часть гипервизоров на винде, если не вся
Правильно приготовить и потом админть ZFS - это уже для квалифицированных специалистов
Come on, во-первых не столь уж оно и rocket science для 99% кейсов, там даже крутить вряд ли что-то понадобится. Да, под условный постгрес нужно уметь не устроить себе безумный write amplification, но, опять же, не так уж много у кого и базы настолько нагруженные есть, чтобы реально было прям необходимо заморачиваться превентивно.
Во-вторых все когда-то впервые ZFS видели. Ничего, вроде справились. Значит и другие смогут.
Никогда не понимал этого тейка про "Слишком сложно, тут непременно нужен уберспециалист чтобы умел ман почитать и крутилки покрутить".
Почему бы для особо надежного хранения просто не использовать CoW без всяких вот этих аппаратных заморочек? ZFS избавляет от контроллеров, на лету парирует BER, становятся неактуальными проблемы с поломкой ФС при неожиданном обесточивании.
Всё имеет свои недостатки. Я сам храню всё домашнее добро на ZFS последние лет 15, ещё со времен zfs fuse, но нужно учитывать что под нагрузкой оно часто медленнее обычных ФС на рейде, плюс память кушает прилично, хотя она нынче дешёвая.
Очень сомнительно что RAID10 даст большую надёжность чем RAID6. А RAID5 в проде это для очень экономичных экстремалов.
RAID10 в принципе менее надёжен чем RAID6 т.к. второй допускает смерть любых двух дисков, а первый только из разных пар.
Но вот с иопсами уже всё хуже.
На шпинделях с иопсапи у 6 конечно беда. Но при использовании SSD уже не все так плохо.
т.к. второй допускает смерть любых двух дисков, а первый только из разных пар.
это черрипикинг
Справедливый для массива из 4х дисков, где в обмен на меньшую производительность, невыигрыш в объеме и отрицательной удаче мы получаем большую надежность.
Давайте рассмотрим массив, из 12 дисков, в котором вылетит 3 харда (ну раз уж мы с такой легкостью допускаем вылет двух, да и удача все еще отрицательная).
Может быть я не совсем понимаю теорию вероятностей, но, как мне кажется, шанс одновременного выпадения соседа в одной зеркальной группе не зависит от количества групп.
Ну а шанс выпадения второго диска при ребилде очень высок, особенно с большими дисками нынешними.
Штож, после прочтения комментов в этом посте я решил что настало время снова потыкать R6(0) палочкой. На след неделе тогда постараюсь сделаю стенд из двух идентичных серверов с разными конфигурациями рейдов и могу произвести замеры. Потом с помощью echo $((RANDOM%Х)) пошевелю в них диски, и пусть выживет сильнейший.
Поскольку результаты меня интересуют для возможного реального применения в дальнейшем, нагрузку я дам свою боевую, не синтетику (5R95W 1G/10G). Если у вас есть предложения, желательно с примерами, что проверить еще - пишите, постараюсь прогнать и их.
У вас подмена понятий. Не 10ка такая расчудесная, а дополнительные диски избыточности. В 6ке их 2, но разница в том, что их там всегда 2, а в 10ке как повезет. У меня прям щас развалился работающий 12 лет raidz2 и я спокойно его восстанавливаю, попивая чай.
Почему стоимость VPS: 1cpu, 1Gb и 20 Gb SSD стоит 329 рублей. А добавление +10 Gb SSD сразу поднимает цену до 953 руб? Нету ли ошибки в калькуляторе у вас по дискам?
Ошибки нет, 1-2-20 является готовым тарифом, а на них предлагаются существенные скидки. С другими готовыми тарифами и ценами на них можно ознакомиться здесь.
У меня raid5 (8дисков) 7 лет ещё ни разу не умер (сервер qnap 875)
во как, народ парится с рейдами когда SDS (от же CEPH) широкими шагами топают по Планете...
и да, лайк тем, кто упомянул ZFS
Всё пытался понять, как там вообще оказался 5 рейд?
Ладно там дома, или в нищей конторе из трех дисков собрать. Но когда дисков много? Неужели лишний диск или небольшой выигрыш в производительности стоит этих свеч?
подойти к серверу, вынуть убившийся диск, поставить новый, подождать ребилда и спокойно работать дальше.
Во время ребилда массив доступен для эксплуатации (чтение/запись внешними пользователями)?
Статья оставила ощущение излишней рекламности. Видно красивые лозунги, ок. Но вместе с ними видно и провалы в логике, а так же обрывочные фрагменты обоснований. Добавим к этому неверное жаргонное использование терминов nvme, ssd, диск. И возникает ощущение, что статью писал журналист или рекламщик.
В общем не очень понравилось.
А вот еще пару видео: про железные рейды не берегут данные и как зфс убивает ссд:
Почему мы перешли на RAID 10