Недавно у нас развалился RAID 5. Один диск на первом году своей жизни умер сам от естественных причин. Такое может быть и в период трёхлетней гарантии — нечасто, но может. Мы вынули его, поставили на его место диск из горячего резерва — и во время ребилда в массиве умер второй диск. Данные умерли вместе с ним.
Один из пользователей, чьи данные там были, очень живо интересовался тем, что за конфигурация у нас была. Вплоть до моделей дисков, дат их производства и серийных номеров. Он, вероятно, считал, что там стоит какое-то старьё, и до последнего не верил, что так бывает на новом железе. Потом очень искренне смеялся над фразой, что ни одна схема резервирования RAID не даёт стопроцентной гарантии сохранности данных.
Это правда: ни одна схема резервирования никогда не гарантирует 100 %. Случается всякое. Диски из одной партии могут умереть в один день: у нас такое было только один раз несколько лет тому назад, но было. Разболтавшийся кулер может вызвать резонансные вибрации, которые убьют два массива целиком: такое было больше пяти лет тому назад, и мы долго расследовали ту ситуацию.
Бывает всё.
В России не очень принято выплачивать компенсации за простои и потерю данных. В прошлом году мы поняли, что это важно делать, и включили такие пункты в соглашение.
Это привело к целой цепочке последствий, в частности, к тому, что мы перешли на RAID 10 как на новый для нас стандарт хранения данных.
▍ Как было раньше
Чаще всего у нас идёт речь про восемь физических дисков в сервере (но местами есть где пять, а есть где десять) — это один контроллер. Плюс второй контроллер — для дисков с ОС. Плюс отдельно от этих массивов — для бекапа.
Раньше всё хранилось в RAID 5 (в абсолютном большинстве случаев) и в RAID 6.
RAID 5 — это один из относительно недорогих и достаточно эффективных способов хранения данных с резервированием, с защитой от отказа одного диска. Там резерв — N+1, то есть на пять физических дисков вам доступен объём четырёх дисков. Если один диск вылетает, то можно восстановить данные по избыточности с остальных: подойти к серверу, вынуть убившийся диск, поставить новый, подождать ребилда и спокойно работать дальше.
В большинстве случаев это рабочая ситуация. То есть делаешь тикет, меняешь диск из резерва, и все счастливы. Более того, в пределе такие массивы могут ждать замену диска и неделю (на клиентах мы не проверяли, но на личной машине для резерва сайта у нас был случай, что диска для него с ходу не нашлось, но провести замену всё равно успели). Но иногда бывает не так.
В RAID 6 резерв — уже N+2, то есть на четыре диска по объёму вам надо шесть дисков.
В RAID 10 — резервирование 2N: это два RAID 1, объединённых в RAID 0. То есть он быстрый и дублирует данные полностью. Статистически считается, что практическая вероятность выхода его из строя до потери данных настолько мала, что встретится всего пару раз за время работы хостинга на всех машинах во всех ЦОДах во всех странах.
Ещё надёжнее — RAID 51 (два RAID 5 в массиве RAID 1), конечно, но тут мы переходим уже к экономическим обоснованиям.
▍ Экономическое обоснование
Фактически переход на RAID 10 означает плюс два или плюс три диска в каждый сервер. Это дорого: диски, конечно, — расходники, но при этом недешёвые.
Потери данных хостинга по факту случались у нас шесть раз за всю историю из-за разваливания RAID. Пользователи теряли данные и по другими причинам (например, сами накатывали не тот бекап), но это уже такой вид развлечений, где пользователь волен делать что хочет. Сам.
По железу отказов было относительно мало. Даже с учётом SLA и выплат компенсаций дополнительный расход на диски не окупает эту историю. В смысле мы понимаем, что будем выплачивать меньше в перспективе нескольких лет, но это всё равно не окупается.
Остаётся разница, которую мы для себя объяснили репутацией.
Дело вот в чём: если часть машин хостинга ляжет, потому что городские электрики бахнули друг за другом две подстанции, а потом админы зажимали руками патрубок дизеля (такое у нас было) — это простой. Потом можно подняться и продолжить работу.
Если же мы потеряем данные пользователя, то это залёт. Потом нельзя продолжить работу просто так. Это очень больно бьёт по репутации, даже если это отдельная машина.
Поэтому — RAID 10.
▍ Редеплой сервера
Ещё одна особенность экономики — это замена дисков при редеплое сервера. Если по каким-то причинам нам надо вынуть сервер, поковыряться в нём и вернуть в ЦОД, то мы меняем в нём все диски на новые. Это прямо обязательное условие.
Сами диски сначала уходят в резерв резерва (они ещё рабочие, и если в hot swap лежит два новых диска, а потом вендор заменяет их за один рабочий день, то третий или четвёртый рабочие диски будут нелишними на всякий случай, чтобы потом заменить их на вендорские новые через день). Затем постепенно они списываются. Диски у нас довольно редко находятся в работе больше четырёх лет — разве что на промотарифах, которые когда-то были по 30 рублей.
▍ Но ведь… бекап?
Да, мы предлагаем делать бекап всем. Естественно, на машине, где крутится какой-то сервис, который, например, пережимает видео или обеспечивает коннект с каким-то API, делать бекап не надо. Он накатывается из образа и легко перезапускается. А вот если там сервис, где хранятся те же финансовые транзакции или бухгалтерия, — данные надо беречь.
Пользователи заказывают услугу бекапа менее чем в 3 % случаев. Да, у некоторых есть свой собственный внутри системы, но всё равно статистика показательная.
Пользователи, которые делают геораспределение, — их ещё меньше.
Казалось бы, ни одна система не может быть надёжной, и ответственные вещи всегда нужно хостить в нескольких разных местах — но нет. Практика — другая.
Поэтому потеря данных — это проблема хостинга, а не пользователя. В смысле можно хоть 100 раз говорить про важность бекапа и всего прочего, но всё равно виноват хостинг, даже если он ничего не гарантировал.
А мы гарантируем на уровне выплаты компенсаций за отказы и понимаем, что не хотим плодить недовольных пользователей.
▍ Это NVMe-RAID?
Нет. У нас везде — SSD: они хорошо соединяются в массивы.
NVMe, как мы писали, очень плохо соединяются в RAID: потеря производительности такая, что смысла в массивах уже и нет. Соответственно, хостеры, которые используют NVMe, практически не могут использовать RAID, если только у них не очень специфическое дорогое железо. Либо они банально приукрашивают.
Машины с NVMe у нас без RAID, но с регулярным бекапом (бесплатным, невидимым пользователю) на HDD/SSD. При развале NVMe пользователь получает машину в последнем забекапленном состоянии.
▍ Почему у вас хранение внутри сервера, а не в кластере в отдельной хранилке?
Кластер — это другой хороший отказоустойчивый подход. Но там уже сам кластер становится точкой отказа, и практика показывает, что не такой уж и редкой. Мы обмениваемся данными с коллегами и знаем, что и как бывает.
Поэтому архитектурное решение — много независимых нод с резервированием внутри них. Это решение минимизирует риски для нас и наших конкретных подходов. Кластеры могут оказаться лучше или дешевле для других условий. Это не религия, а взвешенное решение: возможно, если мы вырастем в 10 раз, то перейдём на кластеры.
Но с сегодняшней точки зрения отказ одного сервера гораздо менее болезненный, и легче решается, чем отказ кластера. Более того, при потере данных многим клиентам важнее скорее запустить новую виртуалку с возможностью накатить туда бекап из личных запасов клиента и потом подключить диск. Если удаётся считать данные с части дисков, то их восстановление на отдельном сервере происходит быстрее, чем в кластере, где процесс может быть сложнее из-за распределённого характера хранения.
Негативный опыт был и с RAID-схемами, и с кластерами. Если вы погуглите название любого хостера со словами «Потеря данных», то увидите, что такое было почти у каждого. Но самый страшный случай сферы — это когда пару лет назад один зарубежный хостер развалил хранилку с шифрованием. Тогда данные у них потерял не один клиент, а сразу много, и это было очень больно.
Схема с большим количеством независимых узлов более устойчива ещё и к человеческому фактору: кластер же не прощает ошибок админов. Когда мы говорим про очень маленькие вероятности, это становится важным.
▍ Случаи, когда RAID 5 и 6 выходили из строя
Первая ситуация — равномерный износ дисков одной партии с одной датой производства. Если один умер на втором году жизни, то есть шансы, что его соседи находятся в таком же состоянии. На практике это оказалось известной городской легендой, потому что не подтверждается статистикой. На ребилд обычно времени хватает: речь идёт про разницу в месяцы, а не часы. Но, естественно, такие совпадения бывают, и обычно они легендарны, поэтому и запоминаются. У нас такое было.
Вторая ситуация — общий фактор. У нас однажды разболталось крепление системы охлаждения, и в течение нескольких дней на сервер подавалась равномерная вибрация. В конечном счёте это убило RAID 6, что до этого мы считали крайне маловероятным событием. Ещё из общих факторов были скачки питания, перевозка серверов (такое часто бывало у коллег) и так далее.
Самая тупая ситуация за время работы нашего VDS-хостинга — это когда лично я вытащил не тот диск во время ребилда в 2017 году. Сразу скажу, что я повёл себя, как сказочный идиот.
Я был на площадке по другим делам. В это время в одном из серверов вылетел диск из рейда. Чтобы не терять времени на создание тикетов, админ решил поиграть мной в «Аватара» и попросил заменить диск, раз уж я на месте.
Пошёл, забрал диск в ЗИПе, принёс к серверу, вынул проблемный диск, поставил новый. Начался ребилд. Я пошел дальше по своим делам.
Затем снова звонит админ и просит на всякий случай заменить ещё один диск. Почему-то я решил, что речь идёт о том же массиве. Я и сейчас не админ, хотя вникаю во все аспекты работы, а тогда опыта и вовсе было меньше. Не вдаваясь в подробности, я пошёл и вытащил во время ребилда второй диск.
Дальше результат понятен. Хорошо, что на сервере было немного клиентов и почти у всех были бекапы.
С тех пор, какие бы косячные решения ни принимались во время аварий, я прекрасно понимаю, что за них нельзя ругать. Во время аварии, когда надо принимать много ответственных решений в очень сжатые сроки, вы не взлетаете на крыльях адреналина до сверхэффективности, а деградируете до уровня тренировок. Если поведение у вас не отработано многократными повторами, то, скорее всего, вы потеряетесь. Я вот потерялся даже без аварии. И мне до сих пор стыдно.
▍ Гарантирует ли RAID 10 безопасность данных?
Нет.
Ещё раз: никакой рейд не может гарантировать сохранности данных ни при каких обстоятельствах.
Есть только более безопасные и менее безопасные.
Этот — более безопасный. Но всё равно случается всякое. Другое дело, что мы считаем: с введением RAID 10 другие риски становятся выше — от перегрева в ЦОДе до критического сбоя железа. Ну и человеческий фактор.
▍ Итак, основная причина, почему RAID 10
Просто потому, что мы жадные. Других причин, как обычно, нет!
© 2025 ООО «МТ ФИНАНС»
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
Комментарии (100)
KonstantinTokar
11.02.2025 07:54Не раскрыт вопрос хранения бэкапов - зашифрованными или нет.
vassabi
11.02.2025 07:54если у вас там хранятся просто деньги или персональные данные, фотки домашнего архива и пиратский софт - то лучше хранить незашифрованными (а безопасность обеспечивать физически - сейфом итд).
А если данные лучше потерять навсегда (потому что забыл где лежит private key, отпаялась микросхема или космический луч случайно попал), чем иметь шанс что кто-то кроме вас их прочитает (терморектально или аналоги) - то храните зашифрованными.
Aelliari
11.02.2025 07:54Это NVMe-RAID?
Нет. У нас везде — SSD: они хорошо соединяются в массивы.
Эмм? Wat? NVME уже не SSD?
Нет, я понимаю, конечно, что nvme по последней версии спецификации не обязан быть строго SSD, и может был HDD (а такие есть вообще на рынке?), но я не думаю что такая уже попала к хостерам
Aelliari
11.02.2025 07:54Хотя в целом, некорректно. Ибо NVMe - это интерфейс, а SSD - тип накопителя не содержащий механических частей. И SSD может быть как SATA, так и NVMe, или даже SAS.
Manrus
11.02.2025 07:54
А вы уверены что raid 10 надежнее чем raid 6?
В данной таблице также учитывается ошибка чтения (bit error rate) что многие упускают при построении массивов
CherryPah
11.02.2025 07:54у меня данная таблица вызывает некоторые сомнения.
Я же правильно понимаю, что в ней утверждается, что за 5 лет у меня гарантированно развалится 5ый (97%) и почти гарантированно 10ый (82%) рейды?
quartz64
11.02.2025 07:54Не совсем. Расчеты на Bit Error Rate (кстати, он тут приведен для бытовых HDD, для серверных обычно заявляют 10^-15) показывают не вероятность вероятность полного выхода из строя накопителей или развала массива по другим причинам, а вероятность получить битые данные.
При ребилде нужно прочитать данные с оставшихся дисков: объемы большие, так что тут казалось бы ничтожно малый BER начинает играть роль. RAID-5 во время ребилда лишен избыточности — этого желательно избегать и использовать RAID-6. Количество дисков в одном массиве тоже желательно ограничить и разбивать большие дисковые группы (вместо 36x RAID-6 использовать три 12x RAID-60, например).
В этой таблице ещё и AFR учитывается (годовая вероятность отказа) и, видимо, рост AFR по мере выработки ресурса, так что таблица ещё и про полную потерю данных, но методика расчета не указана.
boulder
11.02.2025 07:54Заметьте, эти вероятности указаны для случая, если у вас 12 дисков по 8Тб каждый ;)
CherryPah
11.02.2025 07:54Просто не первый год имею отношение к эксплуатации нескольких сотен десятых рейдов, каждый из которых как минимум вдвое больше, как по количеству шпинделей, так и по объему каждого (как раз 24х16TB as usual). Не то чтобы никогда ничего не разваливалось, но табличка с кучей страшных красных девяток немножко смутила.
Хотя если речь о том, что за несколько лет один из 768 000 000 000 000 бит побьётся - ну да, тут сомнений нет, шансы действительно близки к 100% xD
edo1h
11.02.2025 07:54Да. При заданном BER. На практике BER ниже, так что абсолютные цифры в таблице не особо полезны.
sdy
11.02.2025 07:54Тоже прикинул, взял для примера некоторые дефолтные данные - можно по ссылке посмотреть. В статье явно какая то своя собственная вероятность считается. Спрашивается, зачем народ вводить в заблуждение
Probability of data loss over time:
RAID10 - 0.0000017402781203
RAID5 - 0.0000121801881046
RAID6 - 0.0000000001197614Упоминание в статье про слабую надежность RAID6 связано с тем, что где то разболтался вентилятор и это убило массив. Но это же просто гипотеза, а RAID-10 он что тогда один единственный выжил, так?
ntsaplin Автор
11.02.2025 07:54RAID 10 хоть и удваивает стоимость, зато обеспечивает прирост скорости как при чтении, так и при записи. В то же время RAID 6 ускоряет чтение, но заметно замедляет запись. В данном случае важно минимизировать просадку производительности во время ребилда.
Стоит отметить, что при увеличении количества дисков RAID 10 выигрывает в надежности: вероятность одновременного или последовательного выхода из строя накопителей снижается благодаря дублированию данных.
Однако при небольшом количестве дисков RAID 6 оказывается надежнее. Здесь, как и всегда, приходится искать компромисс между надежностью и производительностью.
mayorovp
11.02.2025 07:54Почему вообще идёт сравнение RAID 6 и RAID 10? А не, к примеру, RAID 6 и RAID 1? Ну или RAID 60 и RAID 10?
AnrDaemon
11.02.2025 07:54Потому что схемы хранения аналогичны по архитектуре. И там, и там используется 2x2 диска, и там и там отказоустойчивость приближается к n/2. Но если в RAID10 у вас откажут ОБА зеркала разом, можете помахать вашим данным ручкой. В RAID6 у вас могут отказать два ЛЮБЫХ диска, и всё равно есть шансы полностью восстановить данные. При увеличении количества дисков в массиве, надёжность RAID10 стремительно падает (или, точнее, непропорционально медленно растёт), в то время, как надёжность RAID6 почти не снижается.
Про RAID5 даже говорить не стоит, ещё 8 лет назад доказано, что при современных объёмах дисков RAID5 ненадёжен в принципе.
sdy
11.02.2025 07:54Да это неверно то что при увеличении дисков якобы RAID10 становится надежней чем RAID6, вот для примера 16 дисков (выше было 8 дисков):
RAID10 - 0.0000348049869834
RAID6 - 0.0000000119738849
Чем ниже число, тем выше надежность, не наоборот
AnrDaemon
11.02.2025 07:54Вы мухлюете. RAID6, как и RAID10, обеспечивает полное дублирование данных.
Незначительная просадка по скорости при ребилде RAID6 компенсируется наличием CRC, что позволяет нивелировать BER (именно из-за отсутствия контрольных сумм ваш RAID10 ТОЧНО будет выдавать неверные данные при длительной эксплуатации).
bazanovv
11.02.2025 07:54А можем ли мы быть уверены в том, что контроллер RAID 6 сверяет контрольные суммы при чтении блока, если ни один из дисков не вернул ошибку? В процессе patrol read - да, безусловно, для того он и предназначен. А вот при обычном чтении?
Akina
11.02.2025 07:54Вы мухлюете. RAID6, как и RAID10, обеспечивает полное дублирование данных.
Есть массив из 4 дисков. Вынимаем любые два. Предположим, что они исправны. В случае RAID-10 вероятность того, что с них можно снять все данные, которые хранились на массиве - 50%. В случае RAID-6 эта вероятность равна 100%.
И это не мухлёж, а чистая арифметика.
mixsture
11.02.2025 07:54А как это вообще читать?
Вот беру 4 drives, иду в колонку raid 5 и вижу какие-то циферки. Но...погодите, а как из 4х дисков сделать raid5 и raid6?
Беру 6 drives и недоумеваю, а как из них сделать raid5 (один лишний, куда его деть?) и raid10 (ему же кратность 4х нужна)?
gluki
11.02.2025 07:54Кажется вы где-то запутались, в "raid5" и т.д. цифра - это же название типа рейда, а не количество используемых дисков.
raid5 - это любые n дисков фактического объёма +1 избыточный (из 4х дисков это 3+1), raid6 - это n+2.
raid10 из 6 дисков - три пары или два тройных зеркала.mixsture
11.02.2025 07:54Наверно, вы правы. Я до этого думал, что число дисков там неизменно и соответствует цифре (этакая зафиксированная пропорция данных и избыточности) - и можно только кратно увеличить.
Вообще, при такой вольной интерпретации цифр в raid10 из 6 дисков - теперь название рейда уже не отражает одну конкретную систему, т.к. возможны 2 разные комбинации: мы либо stripe делаем на 3 диска, либо mirror на 3 диска - и это теперь 2 системы с абсолютно разными характеристиками записи, чтения и отказа. Наверно, их бы и называть надо как-то по-разному.
AnrDaemon
11.02.2025 07:54RAID10 читается как "raid one zero" - это синтез RAID1(mirror) и RAID0(stripe).
RAID5 это минимум 3 диска с распределённой контрольной суммой. 4-й диск добавляют редко, его использовать можно либо как hot spare, либо как дополнительное хранилище для контрольной суммы. Но в последнем случае лучше использовать…
RAID6 это 2n дисков (не менее 4) с распределённой И ОТЗЕРКАЛЕННОЙ контрольной суммой.
Так понятнее? И вообще, статья на педивикии достаточно полно раскрывает тему для чайников.
Akina
11.02.2025 07:54RAID-5 вовсе не означает, что он состоит строго из 5 дисков! В нём может быть и 3, и 5, и 8 дисков... ТО же и для RAID-6, только минимально в нём может быть не 3, а 4 диска.
m_sinelnikov
11.02.2025 07:54Статья понятная и представление у меня уже 15 лет именно такое же. Хотелось бы увидеть аналитику в разрезе (стоимость хранения 1 единицы данных)/(надежность) для разных типов рейда и моделей современных дисков. Тогда можно было бы ответить на вопрос: а какой мне рейд собирать с какими дисками чтобы я мог гарантированно сохранить свои данные N часов с вероятностью Х%.
uuger
11.02.2025 07:54моделей современных дисков
осталось понять, где взять надежную статистику. даже крупный провайдер инфраструктуры пользуется весьма ограниченной номенклатурой дисков, а производители вряд ли публикуют данные, которые выставят их в невыгодном свете
outlingo
11.02.2025 07:54Фиг с ней со стоимостью хранения, есть куда более интересная метрика IOPS per GB.
Akina
11.02.2025 07:54Я только не понял - а вы не пробовали подумать про hot spare? Это же практически мгновенная замена вышедшего из строя диска, и нет никаких проблем с "могут ждать замену диска и неделю". Да и вероятность "во время ребилда в массиве умер второй диск" тоже изрядно снижается.
Да, это не диск в ЗИПе, его ресурс расходуется (у меня лично был случай, когда умер именно диск в горячем резерве). Да, он кушает порт. И тем не менее это весьма разумный, и не сказать что избыточно дорогой (кстати, подешевле десятки будет), способ повышения надёжности хранения данных.
sintech
11.02.2025 07:54вероятность "во время ребилда в массиве умер второй диск" тоже изрядно снижается
Почему снижается, запасной диск же один?
Akina
11.02.2025 07:54Смотря какой РАЙД и сколько дисков в горячем резерве. Ну и, конечно, время реакции на факт выхода из строя тоже важен. Просто наличие дисков горячего резерва максимально уменьшает время от момента выхода из строя накопителя и до момента завершения ребилда - и, как следствие, понижает вероятность утраты данных при кратном инциденте.
Нет, понятно, что если пробьёт блок питания, и на диски начнёт записываться 220 вольт, никакой горячий резерв не поможет.
quartz64
11.02.2025 07:54Hot-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, разумеется.
Akina
11.02.2025 07:54Иными словами, вы просто не поняли, что я сказал. А я рассматриваю только и исключительно два варианта.
Первый - диск вылетел, контроллер подключил hot spare и запустил ребилд, техник через Х времени пошёл за новым диском на замену, принёс, вставил.
Второй - диск вылетел, техник через Х времени пошёл за новым диском на замену, принёс, вставил, контроллер запустил ребилд.
Всё, больше ничего не рассматривается и ничего не сравнивается.
NoOne
11.02.2025 07:54Шанс вылета больше не во время ожидания, пока техник вставит диск, а во время самого ребилда. Поэтому время ожидания запасного диска хоть и увеличивает шанс проблем, но это не основной фактор
ntsaplin Автор
11.02.2025 07:54Hot spare от выхода из строя второго диска во время ребилда не спасает никак. У нас в каждом дата-центре есть оперативный запас дисков и замена происходит очень быстро. В данном случае hot spare мы все равно изучим как мысль, спасибо!
Akina
11.02.2025 07:54Повторюсь - количество hot spare дисков не обязано быть единичным. Более того, они обычно не привязываются к массиву. То есть грубо - у вас, скажем, есть полка на 48 дисков, из 44 вы собираете 4 райда-шестёрки по 10-12 дисков, и 4 стоят в горячем резерве. В каком бы из массивов какой диск не навернулся, резервный тут же займёт его место. То есть вроде бы по арифметике и по одному диску на массив, а на практике у каждого массива их аж 4.
NoOne
11.02.2025 07:54В том и проблема, что тут же не займёт место. Начнётся ребилд, в этом и есть шанс умереть.
in11w
11.02.2025 07:54По опыту, 10 тоже умирает при потере двух дисков. Если не повезет. По примерно описанному сценарию. Возможно, не все такие случаи в статистике учитываются.
Akina
11.02.2025 07:54По опыту, 10 тоже умирает при потере двух дисков.
Ну не умирает, а может умереть. Для десятки из 4 дисков это будет 50% - могут помереть одинаковые в парах, а могут и разные, и тогда из оставшихся двух информация поднимается стопроцентно. Не скажу за "средствами контроллера при ребилде", но вручную при отсутствии шифрования - точно.
in11w
11.02.2025 07:54По личному опыту, помирают в парах - такие случаи были. Единичные. Но лично я их вероятность ничтожной не считаю.
AlexSpirit
11.02.2025 07:54По личному же опыту. Не надо собирать RAID на дисках из одной партии. А ещё лучше что бы они были разных производителей (я не про наклейку на диске, если что)
saag
11.02.2025 07:54Была у меня такая история, RAID 5, диск помирает, ставлю другой, ребилд и помирает Raid-контроллер. Купили какой то ноунэйм, пожадничали.
NikNikolson
11.02.2025 07:54К сожалению, и на вполне приличных неноунейм системах случаются вылеты контроллера или глюки в прошивках с печальными последствиями. Тут только бэкап спасает и нормальная поддержка.
AntonLarinLive
11.02.2025 07:54В большинстве случаев бекапы лежат на таких же RAID-массивах, так что к ним применимо всё тоже самое, и вылеты контроллеров, и дисков.
Lazhu
11.02.2025 07:54
AntonLarinLive
11.02.2025 07:54Про них гораздо больше пишут и говорят, чем не то что используют, а хотя бы видели оборудование вживую.
buldo
11.02.2025 07:54Можно домой купить ленточное оборудование по цене 3-4х 8ТБ дисков. Вот тут и думаешь, а нужна ли лента или можно использовать большие hdd как картриджи для холодного хранения
ildarz
11.02.2025 07:54Прод и бэкап - две независимые системы (рассматриваем случаи грамотного проектирования). Полагаю, не надо объяснять, как считается вероятность отказа двух независимых систем одновременно?
AntonLarinLive
11.02.2025 07:54В теории - да. На практике бекапы могут лежать на той же СХД, на том же сервере. Каждый экономит на своих спичках.
kenomimi
11.02.2025 07:54А разве хорошие серверные NVMe ссд помирают так чтобы совсем? Они же вроде тупо в ридонли уходят, если ресурс закончился или посыпались внезапные ошибки на записи...
ildarz
11.02.2025 07:54SSD - это, очень грубо говоря, плашка памяти с управляющей электроникой. Умершую память никогда не встречали? А материнки и всякие контроллеры?
Okeu
11.02.2025 07:54очень даже) да и так, что потом центры восстановления данных с банок ничего прочесть не могут))
pnetmon
11.02.2025 07:54Не про полное помирание, но помирание.
Стояли в зеркале два NVMe для NAS (WD Red SN не энтерпрайс решения) и все было хорошо пока раз не обнаружилось через 6-9 месяцев что диск пропал из системы, пока решалось что и как оказалось что обесточивание компьютера возвращает диск в работу, через несколько месяцев повторение ситуации, после этого замена на SATA решения т.к. доступный ассортимент скукоживался в связи с известными событиями. Компьютер никогда не выключается. В англоязычном сегменте для этой модели несколько упоминаний о похожих симптомах. А если бы такое без RAID.
kmosolov
11.02.2025 07:54оказалось что обесточивание компьютера возвращает диск в работу, через несколько месяцев повторение ситуации
Аналогичная ситуация была с NVMe SSD HP EX950, думал что проблема только в периодической недоступности диска, а на деле всё оказалось хуже - часть данных на диске "занулилась", ладно данные были не критичные, пришлось "разжаловать" этот диск в внешнюю "переноску" для файлов.
uranik
11.02.2025 07:54У некоторых от нагрева и времени безсвинцовый припой отлетает и привет, ридонли не поможет.
Alexandro_Live
11.02.2025 07:54Помню одну одну историю как один знакомый пытался устроится в рувдс на одну из руководящих должностей. Самый первый вопрос был, чем отличаются TCP от UDP. После первого вопроса поняли что не подходят друг другу. Если по теме, то как правило не хватает всегда дисков и все диски работают на износ. Ни когда не видел, что бы изначально были хоть какие то разумные расчёты.
ABRogov
11.02.2025 07:54диски, конечно, — расходники, но при этом недешёвые.
Спорное утверждение, сейчас любая память дешева как никогда. Просто рынок движем мамкиными скупердяями для которы хостинг за 2.99 гораздо более предпочтителен, чем за 5 или 10, хотя по сути разницы нет совсем. И это понятно, большинство задач не чувствительны к потери данных.
Lazhu
11.02.2025 07:54Забыли упомянуть, что R10 производительнее R5 в 2 раза и R6 в 3, в общем случае.
Mnemonic0
11.02.2025 07:54Мы решаем так: Raid6, туда где можно помедленее и позволителен простой, Raid10 - везде, Raid10+HS туда где должно работать максмально шустро.
Остальное на уровне приложений: кластера, реплики, бэкапы
Selavi2018
11.02.2025 07:54Ваша статья про рейд массивы из NVME дисков датируется 2021 годом. На дворе 2025 . Насколько я знаю рейд контроллер Dell H965i вполне себе позволяет их создавать и просадка в производительности по сравнению с одним диском очень небольшая
Black_Spirit
11.02.2025 07:54У нас всего 3 СХД по 12 дисков в raid 6. За 10 лет был случай одновременного выхода из строя дисков одной партии. В один день. И было 2 случая выхода из строя второго диска при ребилде. Два из трёх СХД отзеркалены и географически разделены. Третий СХД это холодный бекап. Предполагается, что холодный бекап сохранится, если все остальное подвергнется воздействию шифровальщика. Думаю, такой подход достаточно надёжен, чтобы спать спокойно
rm76
11.02.2025 07:54В RAID 10 -- резервирование 2N
- ага. но только у везучих.
vdudouyt
11.02.2025 07:54Истину глаголите, самолично неоднократно видел развалившиеся как RAID 5, так и RAID 10 (те самые, вероятность падения которых вроде как теоретически составляет 2^-100500). Кроме того, если после закупки 2x места экономика у вас все еще сходится, не будет ли более целесообразно отдать его под бэкап?
aluminic
11.02.2025 07:54Почему-то никто не вспомнил про сигейты и муху це-це
Magnum72
11.02.2025 07:54Это дела давно минувших дней, меня больше волнует почему никто не вспоминает о проблеме с HP дисками когда они умирали когда у них счетчик отработанных дней переполнялся. https://habr.com/ru/companies/ruvds/articles/681158/
Arxitektor
11.02.2025 07:54В RAID 10 -- резервирование 2N
- ага. но только у везучих
Я же правильно понимаю если брать минимум из 4 дисков.
R10 и R6 Выживают при отказе любого из дисков.
-
Если при ребилде отказывает диск то в случае R6 это может быть любой диск. А в случае R10 может не повезти и будет потеря данных ?
Akina
11.02.2025 07:54Было 4 диска, осталось 2. Но в случае RAID10 это могут быть два диска с одной и той же половинкой, и вторую не восстановить. В случае же RAID6 данные восстанавливаются по любым двум из начальных 4.
Так что с формальной точки зрения вы правы. А с практической - в случае 10 всё и так понятно, а в случае 6 ещё неизвестно, как поведёт себя контроллер. Сможет ли он опознать дуплет и отребилдить оба несинхронизированных диска, пусть формально и обязан.
AnrDaemon
11.02.2025 07:54Бредите. Правда. Что значит "сможет-не сможет" ? Это "ну нишмагла я…" что ли?
Sadok
11.02.2025 07:54RAID - это не бэкап. NAT - не фаервол. Сколько можно твердить? Хотя... Без буратин же никуда.
305mm
11.02.2025 07:54Сюрприз!
Выход из строя двух дисков может убить и десятый рейд. Просто вероятность меньше. Грубо говоря, вероятность смерти рейда при выходе второго диска в десятке из 4 дисков 1/3, из 6 - 1/5. И т.д. 14 - 1/13.
Шестерка же от двух дисков не гибнет.
Может лучше пустить лишние диски на бэкапы, чем почти удваивать количество дисков?
atd
11.02.2025 07:54и во время ребилда в массиве умер второй диск
Пффф. Добро пожаловать в реальный мир, это старо собственно, как и сам RAID5, во время ребилда ещё может и сам контроллер сказать «я устал я ухожу». Вообще, успешный ребилд RAID5 можно получить только в лабораторных условиях.
CrazyElf
11.02.2025 07:54Ээээ, судя по посту и комментариям у вас там даже hot spare не было?! 30 лет назад, когда я работал на ИВЦ Прив. ЖД у нас там были RAID5 с hot spare и всё было отлично, только вот админы настолько расслабились, что сначала умер диск в рейде, рейд автоматически подхватил hot spare и заребилдил, потом через какое-то время умер ещё один диск... А когда админ наконец-то чухнулся и заменил один из умерших дисков, ребилд шёл очень долго и в его процессе умер таки ещё один диск. Но это потому, что и админ прощёлкал один умерший диск и поставки дисков IBM шли очень долго, их нужно было заказывать заранее и у нас в какой-то момент просто не было дисков на замену.
А ещё у нас был случай (и, кажется, не один), когда в рейде 1 умирал контроллер, похоронив с собой оба диска.
Heilgecht
11.02.2025 07:54Мы используем системы хранения данных Dell и IBM, обе из которых предлагают технологию ADAPT Distributed RAID. Это намного лучше, чем Raid 6 или Raid 10.
TheOldGrouch
11.02.2025 07:54хех, у нас однажды развалился RAID10. Два диска сразу. Нам категорически повезло, что они сдохли накрест, так что после дня гугления и экспериментов "на кошках" мы нашли, где записана информация о принадлежности дисков, и смогли собрать половинку рейда, после чего за следующие два дня пересобрали его целиком на новых дисках уже. Ночные бэкапы были, конечно, и эти три дня контора работала на "времянке", но хоть не убили сразу.
ilyamodder
11.02.2025 07:54Для меня удивительно, что вы вообще используете RAID5, когда примерно во всех местах, где он описывается, предостерегают от его использования именно по причине высокой вероятности умирания еще одного диска при ребилде.
karavan_750
11.02.2025 07:54Недавно у нас развалился RAID 5.
Много лет назад, когда я начинал вникать в системное администрирование, случился этап ознакомления с рэйдами и их теоретической базой. Где-то на подкорке записалось "фатальнее raid5, только raid0" (из практически эксплуатируемых). Через несколько лет опыт пополнился закрепом этой информации -- двое суток восстановления клиенту развалившегося raid5 с "матрешкой" -- VMFS, внутри ntfs, на которой БД с данными различных баз 1С. От ребилда отказался, так как весь набор дисков был из одной партии и был высокий риск потерять данные в полном объеме.
По примерным прикидкам, клиент за эти двое суток простоя (+ оплата моего труда) потерял раз в 20 больше, чем сэкономил на эксплуатации raid5.
На протяжении всего времени занятий системным администрированием меня не отпускает предположение, что raid5 с критически важными данными используют люди верящие в чудеса и деда мороза.
p.s.: Выше комментарий в тему оставили, пока я набирал свой.
Ziptar
Сколько раз можно на одни и те же грабли наступать? RAID - средство достижения высокой доступности, а не замена бэкапам.
uuger
по сути, для очень важных данных, которые надо хранить долго, единственный реальный бэкап - это всё та же ленточная библиотека, физически находящаяся в другом месте и с носителями, физически извлеченными из tape drive. все остальное - это компромиссы разного уровня
Rsa97
И минимум в двух разнесённых в пространстве копиях.
uuger
и из них хотя бы раз получалось пробно восстановить данные )
novoselov
а если tape drive сразу после считывания зажевывал ленту? :)
uuger
если копирование было, как минимум, 3-2-1 - быстро, но без паники, делаем ещё один бекап на новый картридж, если нет, то как говорил главный разраб на моей первой работе, "можете начинать впадать в отчаяние" )
beerchaser
Зажеванную ленту, если ее не порвало в лоскуты, можно аккуратно прогладить теплым утюгом :). при некоторой удаче она вполне прочитается. Плотность записи на магнитной ленте ниже, чем на жестком диске, а избыточное кодирование также присутствует.
nixtonixto
Ключевое слово - тёплым, потому что можно ненароком достичь точки Кюри и вообще размагнитить ленту.
beerchaser
Утюг, разогретый до температуры Кюри для ферромагнетиков 8-0... Вы страшный человек :))) Там скорее основа (лавсан) поплавиться. Но таки да, гладить лучше отключенным от сети утюгом.
Ziptar
записанные лазером в кристалл*
Я про целевое назначение технологии, а не про надёжность резервирования данных. Её, как и безопасность чего бы то ни было, можно наращивать если не до бесконечности, то по крайней мере до полной нецелесообразности.
uuger
а вы не читали про историю с ГАС Правосудие, например? Часть данных утрачена полностью и навсегда. Потому что вот такие "нецелесообразные" бэкапы существовали только по документам.
Или, например, в штатах происходит более 1 инцидента в день, связанных с ransomware только в сфере медицинского обслуживания.
В мире, где данные превратились в один из самых ходовых товаров, некоторые меры по их сохранению уже давно перестали быть избыточными
Ziptar
Как связано государственное ворьё и нецелесообразность избыточных мер в реальных задачах?
И?
Какие-то да, какие-то нет. Я не пониманию, к чему это сказано. Я написал, что бэкапы в целом избыточная вещь? Нет, не написал. Но то, что вы описали выше - в 99,95% случаев избыточные неадекватные меры.
uuger
так, что были утрачены как продуктивные данные, так и бэкапы, размещенные на серверах/СХД. Кто-то из админов, видимо, заверил, что этого будет достаточно "в 99,95% случаев".
вот к этому:
Попробуйте посчитать ваши волшебные проценты, не выкидывая это приложение из контекста. (долговременное хранение, по отраслевым стандартам, это > 10 лет, если что)
Ziptar
Короче говоря, вы сами не понимаете, с чем спорите, вам важен процесс спора. Ок, но без меня.
mgnskydiver
А где почитать про ГАС Правосудие и "нецелесообразные" бекапы? Естественно, спрашиваю не про новости в лентах.
MountainGoat
Зашифровать и выложить в публичный торрент, всем заинтересованным в сохранении данных скачать на свои домашние компы.
uuger
Поздравляю, вы приняты на работу в Яндекс.Go