Как я писал ранее, недавно случилась авария на одном из моих серверов. Это был такой себе нежданчик и как всегда не вовремя.
Дисковая подсистема сервера представляет собой RAID10 из 4-х дисков, который считается самым надежным типом RAID-массива и какбэ переживает потерю до 50% дисков в массиве. НО! Не все так гладко в королевстве датском…
Как известно, RAID10 есть гибридом RAID1 и RAID0, его схема для 4-х дисков изображена на рисунке:
Теперь представим ситуацию, при которой вышли из строя диски «1» и «3»:
Массив действительно останется в живых потеряв половину дисков и даже будет работать с небольшой потерей производительности (примерно в полтора-два раза) на чтение данных. НО если выйдут из строя 1-й и 2-й диски, или 3-й и 4-й — рейд умрет моментально и навсегда.
Думаю что я не открыл Америку рассказав это, просто многие не учитывают этот момент при построении дисковой подсистемы и я был одним из этих «многих» :)
Я всегда наивно считал RAID10 массивом, выход из строя которого практически невозможен. Но в один прекрасный день, когда посыпались жалобы на недоступность сайтов на сервере меня ждал сюрприз. В дата-центре сказали, что в сервере выгорел винчестер, но сервер в целом «вроде бы работает». После перезагрузки он не поднявшись толком опять упал. Я в непонятках поехал туда и долго пытался вкурить проблему. А случилось там вот что:
3-й винчестер умер полностью, а 4-й оказался тяжело болен (покрылся бэдами) корневая файловая система (ReiserFS) накрылась и Дебиан грузиться категорически отказывался.
Пошел курить в сторону утилит для реанимации ReiserFS. Команда:
$ fsck.reiserfs --check
просила —rebuild-tree при выполнении которой 4-й винчестер отваливался и все окончательно зависало а помогал только «железный» reset. Тяжело сказать как бы все это обернулось будь у меня на корневом разделе не ReiserFS, а допустим, старая проверенная Ext3, но на всяких коммюнити начитался мнений по поводу ReiserFS vs Ext3 в пользу последней в плане надежности. Это отчасти философский вопрос, и все-таки я зарекся не использовать файловые системы не проверенные временем (всякие там ReiserFS, Ext4 и т.п..) на серверах, где требуется высокая надежность.
Далее я решил не торопиться и попробовать заменить 3-й (полностью мертвый) винчестер в надежде что зеркальная пара перестроится а я смогу все-таки восстановить файловую систему на корневом разделе, но мои надежды не оправдались, и после замены 3-го винчестера массив начинал перестраиваться и на 2% REBUILD завершался а у массива устанавливалось состояние «IMPACTED». В общем — фейл.
Т.к. восстановить корневую фс не получилось, острым стал вопрос бэкапов. Бэкапы в общем то были…но были они на этом же массиве :) Благо мне хватило ума сделать отдельные разделы под /var и /backup поэтому загрузившись с LiveCD я смог примонтировать эти разделы и увидеть свои данные.
Мне удалось прочитать все важные данные с небольшими ошибками с этих разделов и слить их в сеть. После чего был заменен глючный (4-й) винчестер и заново построен массив. Далее последовала установка новой ОС…настройка с нуля (все системные файлы были похоронены в корневом разделе)…восстановление сайтов и т.п…в общем кусок работы.
К стати по поводу винчестеров — в сервере стояли 4 штуки Seagate Barracuda 250 GB, за полтора года из 4-х поменял 2…без комментариев :)
Сложно сказать что привело к такой ситуации, в логах объяснений не нашел, а рассуждать можно часами, лично я вижу несколько вариантов:
1. 4-й диск начал глючить от старости, но в целом рейд работал, т.к. 4-й диск стоял в зеркальной паре с нормальным винчестером, а после выхода из строя 3-го массив посыпался (скорее всего)
2. 3-й диск вылетел давно и я этого не заметил, а 4-й от нагрузки начал глючить и случилось то что случилось (вполне возможно)
3. 3-й и 4-й диски вышли из строя одновременно от сбоя питания в дата-центре или по другим необъяснимым причинам (практически нереально)
Интересный момент: в процессе работы с RAID-контроллером (Adaptec модель не помню) он возмущался на неработающие диски противным пронзительным постоянным писком, который слушали я и еще несколько человек в дата-центре на протяжении долгих часов…слушали и тихо ненавидели :))) хотели заклеить динамик скотчем, но динамик оказался спрятан под радиатор :)) в итоге, через пару дней я случайно в официальной документации к контроллеру нашел как отключается этот аларм :))))) мораль сей басни такова…ну вы поняли :)
Из этого всего я сделал несколько (в принципе очевидных) выводов:
1. RAID10 — не панацея и его надежность не так уж высока как может показаться (для 4-х дисков так точно).
2. БЭКАПЫ! Какой бы не была надежной дисковая подсистема, бэкапы баз, файлов, настроек и всего, что можно забэкапить должны делаться хотя бы раз в несколько дней и обязательно куда-нибудь в сеть.
3. Файловые системы не проверенные временем не стоит применять там, где требуется высокая надежность от дисковой подсистемы.
4. Отдельные разделы для /var , /home , /backup . . . это хорошо и правильно.
5. Seagate — расходный материал.
6. Перед тем как начинать работу с капризными и кричащими железками — обязательно читать от корки до корки официальную доку :)
Все это я давно знал…и если бы соблюдал эти элементарные правила — все обошлось бы меньшими нервами и ушло бы меньше времени на восстановление. Буду считать это хорошим уроком для себя.
Надеюсь что данная писанина поможет еще кому-то не наступить одновременно на столько граблей как я :)
Очень познавательная и поучительная история. У себя на серверах ставлю два RAID1 не объединяя их в 10й. На одном RAID живет система и данные на втором RAID живет бэкап. И вот тоже знаю что не хорошо бэкап делать на том же компьютере… перекрестимся :))
дякую