О надежности 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 сигейта буду по одному менять. Сн
Да все понятно. Оставшие 4 сигейта буду по одному менять. Снять с полки, развинтить, поменять, свинтить.
У меня же не hotswap и вообщее трудно разобрать-собрать, потому и по два.
Просто вот эти вот вероятности, 1млн часов и все такое - они к реальной жизни совершенно никакого отношения не имеют. И жизнь про это периодически напоминает.
да ладно - на примере пчелайна все было очень похоже - MTBF
да ладно - на примере пчелайна все было очень похоже - MTBF ~ 300кчасов, ~10к наших (hi-end HP) дисков, вылет - раз в день. вот только raid5 без hot spare - это зло...
У "hi-end HP" MTBF поди миллион часов, а не 300к?
У "hi-end HP" MTBF поди миллион часов, а не 300к?
даже больше - 1,2 но с выводом из группы по любому чиху можн
даже больше - 1,2
но с выводом из группы по любому чиху можно смело делить на 4.
Ну так о том и речь - что реальные цифры MTBF и декларируемы
Ну так о том и речь - что реальные цифры MTBF и декларируемые - в разы расходятся.
Да это основна проблема, у 5го, с 6-м то да, тупо по одному.
Да это основна проблема, у 5го, с 6-м то да, тупо по одному... ну и каждодневные бекапы и DFS смягчают проблему, конечно.
Дома для архива вообще использую кучу 1-х рейдов, это самое надёжнное вообще, когда нет чего-то типа Adaptec 5805 и скорость не важна.
Ну вроде как общепринято для рейдов брать диски из разных па
Ну вроде как общепринято для рейдов брать диски из разных партий, по возможности. Не 100% гарантия, но чуть-чуть проблему уменьшает.
Частнику трудно так. Тем более - менял я не вылетевший диск
Частнику трудно так.
Тем более - менял я не вылетевший диск, а вылетел - тот, который не менялся. Т.е. в моем случае несколько партий не спасли бы.
Я читал что-то такое авторства <lj user=ivlad> времен, когда
Я читал что-то такое авторства времен, когда он был в 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 построена, а в этом случае и полный отвал сервера со всеми массивами не катастрофичен.
Кстати по вышеуказанному
Кстати по вышеуказанному гугловскому документу. Есть все-таки большие подозрения что их неожиданный и неподтвержденный предыдущими исследованиями вывод об отсутствии корреляции между температурой и отказами объясняется практическим отсутствием горячих винтов в ихних дата-центрах. Во всяком случае по графикам в документе не виден учет фактического числа винтов в разных температурах - а ведь в отличие от "пользовательских" условий, в датацентрах все винты примерно в одинаковых условиях охлаждения.
Хотя, конечно, хотелось бы ошибаться - т.к. это был бы слишком очевидный и нелепый прокол.