О надежности RAID

Я был уверен, что читал про это в известной гугловой бумаге про надежность дисков, однако быстрым просмотром этого не нашел. Значит ветром надуло.

"Это" - такой практический факт, что если у вас вылетел диск в RAID, то шансов словить проблемы с еще одним диском в том же массиве в процессе ребилда - много. Настолько много, что мы в АиП с этим несколько раз сталкивались вживую, несмотря на то что парк серверов у нас - маленький.

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

Я умный, поэтому для рабочих данных использую RAID6. Все-таки вероятность того, что при ребилде вылетит два диска - она сильно меньше. Ну, к примеру, если RAID5 окончательно портятся в 5% случаев ребилда (что явно завышенная оценка), то значит RAID6 так убить получится в 1/400 = 0.25% ребилдов. С учетом бэкапов и всего такого (и реальной частоты ребилдов - ну пусть даже раз в месяц, реально много меньше) - меня это устраивает (а 5% - не устраивает).

Но вчера - чуть не налетел и с RAID6. Естественно, ровно по собственной глупости: у меня в рабочем массиве стоят (стояли) 6 штук старых 1Tb Seagate Barraсuda ES.2. Они греются заметно больше, чем WD RE4, медленнее, да и вообще им уже по 4 года, пора менять (на WD RE4, которых в этом массиве еще два). Ну вот я пару WD RE4 вчера и принес из лабаза, пару сигейтов вытащил, заменил, поставил ребилдиться.

И что вы думаете? Первый - перестроился (Adaptec 5805 их по одному перестраивает), а в процессе перестройки второго - вылетел один из старых сигейтов. На час раньше - и прощай данные. Ну то есть вернуть старый диск - не дали бы, если такой возвращаешь он все едино считается новым, таймстампы то разошлись.

Пойду свечку поставлю. Те 4Tb данных, что на этом массиве лежат, - на 99% дублированы на другой NAS и на 90% в оффлайн, но даже 1% потерять было бы необычайно обидно.

Comments

Вот поэтому более одного за раз менять и не надо. Ну, или заранее держать spare

Да все понятно. Оставшие 4 сигейта буду по одному менять. Снять с полки, развинтить, поменять, свинтить.
У меня же не hotswap и вообщее трудно разобрать-собрать, потому и по два.

Просто вот эти вот вероятности, 1млн часов и все такое - они к реальной жизни совершенно никакого отношения не имеют. И жизнь про это периодически напоминает.

да ладно - на примере пчелайна все было очень похоже - MTBF ~ 300кчасов, ~10к наших (hi-end HP) дисков, вылет - раз в день. вот только raid5 без hot spare - это зло...

У "hi-end HP" MTBF поди миллион часов, а не 300к?

даже больше - 1,2
но с выводом из группы по любому чиху можно смело делить на 4.

Ну так о том и речь - что реальные цифры MTBF и декларируемые - в разы расходятся.

Да это основна проблема, у 5го, с 6-м то да, тупо по одному... ну и каждодневные бекапы и DFS смягчают проблему, конечно.
Дома для архива вообще использую кучу 1-х рейдов, это самое надёжнное вообще, когда нет чего-то типа Adaptec 5805 и скорость не важна.

Ну вроде как общепринято для рейдов брать диски из разных партий, по возможности. Не 100% гарантия, но чуть-чуть проблему уменьшает.

Частнику трудно так.

Тем более - менял я не вылетевший диск, а вылетел - тот, который не менялся. Т.е. в моем случае несколько партий не спасли бы.

Я читал что-то такое авторства времен, когда он был в EMC2.

Это, похоже, вообще общее место. Вот в этой статейке есть про кросс-корреляции: http://static.usenix.org/events/fast07/tech/schroeder/schroeder.pdf

Коэффициент корреляции количества дисков смененных в последовательные недели - 0.79. А при независимости - должен быть ноль.

Если брак, то скорее всего в технологических условиях: химию не так смешали, печку не на ту температуру выставили, у резца юстировка сбилась (что там еще при производстве HDD делают). Вот и внесена во всю партию некоторая потенциальная неисправность. Хорошо если не на этапе проектирования.

Брак же - в первый год (грубо говоря) выявится.

Там интересные графики, что у гугла, что у этих HPC-шников. Нетривиальные.

Мы поэтому зареклись вообще даже по одному менять без двойного бекапу для начала - сначала нужные данные, потом фулл-дамп, just to be on the safe side. "Береженого бог бережет", - сказала монашка, натягивая презерватив на свечку..
ИЧСХ, вот делишься с окружающими "веселым" опытом замены хардов в рейде (за последние лет пять ожидаемых нежданчиков было штук шесть, причем разных, вплоть до отвала башки у контроллера на старых LSI Logic) - и все равно эти "окружающие" потом прибегают с вопросом - ой, у нас все распалось, что делать, как жить дальше.

Отвал башки - это, кстати, влегкую. Я на что-то такое налетал и не раз.

Нагрузка большая, чипы греются.

Наивный вопрос: а не бывает ребилд на пониженной скорости? Чтобы не "быстро как только можно", а в несколько раз медленнее?

У адаптека есть приоритет задачи (ребилда). Но за что он отвечает - не в курсе.

Оно отвечает только за перформанс по обычным операциям i/o в процессе ребилда - чем выше приоритет, тем хуже перформанс по чтению-записи в процессе.
Относительно наших печалей - это все ниачом, т.к. ребилды обычно валятся на плохом/ремапленом секторе, который в обычной жизни никто и никогда не читает - лежит в блоке с этим сектором какой-нибудь файл корейской локали, или гзипованный лог из прошлого века, и до ребилда никому ничем не мешает. Причем чем больше массив, тем больше в нем таких "потаенных уголков".
Я у себя пришел к выводу о необходимости включения Patrol Read или аналогичных по смыслу проверок линейным чтением, которые данный конкретный контроллер умеет. По крайней мере это снижает шанс именно "нежданчика".

А разве не принято в случае вылета диска перед ребилдом сделать бэкап в деградированном режиме? Желательно incremental от последнего другого бэкапа, чтобы было быстрее и не нагружать диски.

Ну, в теории - да, надо.

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

Кстати по вышеуказанному гугловскому документу. Есть все-таки большие подозрения что их неожиданный и неподтвержденный предыдущими исследованиями вывод об отсутствии корреляции между температурой и отказами объясняется практическим отсутствием горячих винтов в ихних дата-центрах. Во всяком случае по графикам в документе не виден учет фактического числа винтов в разных температурах - а ведь в отличие от "пользовательских" условий, в датацентрах все винты примерно в одинаковых условиях охлаждения.
Хотя, конечно, хотелось бы ошибаться - т.к. это был бы слишком очевидный и нелепый прокол.

Add new comment