Epic fail story

Всем привет!

Пятница, вечер, дождик…

1) В одной компании вышел из строя RAID6 на HP Proliant Gen6, виртуальные машины на VMware ESXi стали частично недоступны.

Пошли за бэкапами на систему хранения QNAP – оказалось, что она тоже потеряла два диска в RAID5, вследствие чего бэкапов тоже нет.

Владелец взял где-то два брендовых SATA-диска IBM, объединил их в программное зеркало (динамический диск MS Windows) и скинул туда данные с сервера Hyper-V. Сервер Hyper-V был переформатирован под ESXi.

Когда через месяц-два он раздобыл новый сервер под Hyper-V, оказалось, что оба IBM-диска неживые.

Я не уточнял у него, как он вышел из этой ситуации.

2) В другой компании внезапно стали недоступными виртуальные машины, находящиеся на одном из RAID-массивов. Как оказалось, LUN3, состоящий из двух SSD-дисков в зеркала, решил что ну его…

У нас же есть бэкапы, заявил мой тезка. Угу-угу, VMware Data Protection 6.1.2 не загружался, в консоли висела надпись:

Перезагрузка не помогла, через час все было точно также.

vDP пытались оживить сначала вручную, потом через техподдержку VMware. Третий по счету инженер из EMC смог оживить бэкапы и мы узнали… что последний бэкап сделан год назад. Так как “Retention Policy” требует хранить бэкапы за последние 90 дней…

Тут мой тезка и говорит “у меня есть еще одна система резервного копирования, сохраняющая файлы на сервер в Amazon. Но я залогиниться туда не могу 🙁

В общем, сервер с бэкапами на Amazon оказался заражен каким-то ransomware…

Параллельно была сделана попытка выключить и включить система храения с выдергиванием/втыканием SSD-дисков (потому что она еще и на RAID-контроллер ругалась)…

После включения массива сдохло еще 4 SAS-диска (2 уже не работали), вследствие чего Lun2 ушел следом за Lun3. Как оказалось, MD3220i более 7 лет.

Какие выводы (кроме настройки уведомлений) вы бы сделали из обоих историй?

Какие epic fail были у вас?

14 thoughts on “Epic fail story”

  1. А про выводы давно сказано – бекапы нужно тестировать! СХД должны быть на мониторинге (хотя бы snmp трапы), тогда спать можно будет спокойно.

  2. Все ит-шники делятся на три категории:
    1. Кто еще не делает бекап.
    2. Кто уже делает.
    3. Кто делает и регулярно восстанавливает.

  3. Из фееричного:
    Досталась настроенная система бекапа, планировщик бекапа был настроен в виндовом шедулере, шедулер запускал батник с командами на бекап. Работало все годами отлично – был успешный бекап и успешный рестор. В какой то момент надо было что-то отресторить – а бекапа нет (( В результате разбора было выяснено что в винде по дефолту стоит галочка на прекращение работы задания если оно идёт больше трех дней, с годами бекапы выросли и последнее задание не всегда стало успевать выполняться… Галочка кстати в 2003 не на виду была, в Advanced где-то..

  4. Так 3PAR стоит на круг (т.е. со всеми возможными поддержками и SLA) один диск от 3 до 5 млн. руб. Мне считали на 7 Тб один. Еще бы он, сук, не огонь был.

  5. В случае 3par вы еще и получаете бонусом Dedupe+Compression, которая эту сумму (в сравнении с Dell MD со скриншота) “делит” на 2-4 (за счет сжатия).

    Мне кажется, что 7ТБ диски у всех midrange-массивов (которые не Dothill) примерно одинаково стоят, или нет?

  6. Диски, возможно, да. У Fujitsu (например dx500) как-то по разумнее цена и дедуп это же не про диск, а функционал полки, который не должен добавлять стоимость к носителю. Да и не столько он стоит в конце концов. Короче, рассматривал 3пар, вышло в круг пизд…ц как дорого. Остановился на фуджи, при том же (почти:) функционале. Но 3пар – топ, это факт.

  7. Мдя почитал, и сразу понятно стало до моего опыта далеко. Диски с одной партии ресурс как минимум одинаковый вот и весь вывод.

  8. Проблема не в дисках.
    1. Нет мониторинга.
    2. Нет контроля РК, если не тестового восстановления, то как минимум контроля прохождения.

    Когда-то мне на полном серьезе доказывали, что ленточки это плохо, т.к. “у них был опыт”. Но проблема любого РК в том, что за ним надо следить. Надеяться, что РК 1 раз настроенное будет работать годами и в час Ч у Вас будет нужный бэкап – это наивность. Это система которую надо админить и за которой следить. И т.к. Вам пользователь не скажет, что все стало тормозить или упало, то следить надо гораздо внимательнее.

    3PAR в этой системе ничем не спасает, а если речь идет про проактивную поддержку, так это другой разговор. Но не все готовы к тому, чтобы в их сети безконтрольно хозяйничал непонятно кто.

    Из личного опыта могу рассказать как самый “лучший”, а главное самый дешевый СХД MSA теряла данные.
    1. Приходит сообщение от мониторинга сдох диск. Контроль, все верно
    2. Задача локальному спецу заменить диск из ЗИПа
    3. Открытие кейса в HP
    4. Сообщение спеца, что диск заменил, что-то она как-то странно лампочками мигает.
    5. Контроль статуса: 1 диск заменен (добавил как Spare), еще 2 диска FAILED. Слава богу диски пока из разных дисковых групп, хотя 3 диска за 0,5 часа это круто.
    6. Звонок в HP поднятие критичности кейса, требование на связь инженера. Договорились заменить еще 1 диск из ЗИПа (больше в ЗИПе дисков нет)
    7. Локальный инженер меняет еще один диск
    8. Контроль: 1 диск заменен, 1 диск остался failed как был, 2 новых диска failed !!! Одна дисковая группа потеряна. По остальным идет ребилд
    9. Звонок в HP инженер ничего лучшего предложить не смог, как попробовать на сбойных дисках сбросить состояние ошибки. На вопрос не станет ли ей еще хуже, нет не станет.
    10. Сброс ошибки на 1 диске – диск переходит в состояние жив, но не в группе. Еще 2 диска перешли в FAILED. Данных на MSA больше НЕТ!!!
    11. Инженер в трубке мычит и разводит руками.
    12. Срочный поиск места на других СХД, нарезка и презентация LUNов, запуск разворачивания бэкапов. дело было в пятницу – можно сказать повезло
    13. Понедельник – самые критичные данные восстановлены, восстановление продолжается
    14. Среда – восстановлено больше 90% всего, пользователи перестают визжать. Восстановление продолжается.
    15. HP ничего вразумительного сказать не смогла
    16. В одном из больших обновлений микрокода (сильно позже) натыкаюсь на строчку , что исправлена ошибка, которая в каких-то условиях приводила к ошибке адресации дисков!

    Как относиться к СХД (у которой всего 2 задачи управлять дисками и данные сохранять/отдавать) и с основной задачей оно справляется вот так, решайте сами…

  9. > Как относиться к СХД (у которой всего 2 задачи управлять дисками и данные
    > сохранять/отдавать) и с основной задачей оно справляется вот так, решайте сами…

    В entry-level никто никому ничего по определению не должен, да и в mid-range уже тоже.

  10. Справедливости ради замечу, что в австралийской налоговой кластер из 3par развалился.
    Правда, я не помню, пришлось ли там за бэкапами ходить…

  11. История факапа: как оказалось, 1 хост, на нём esxi, 8 одиночных дисков отформатированы в vmfs, на них расположены NAS_x.vmdk из которых собран ZFS RAIDZ, который доступен по SMB, на который с помощью HandyBackup был сделал в zip бекап, после сделали снимок vmfs через esxi, потом ещё раз бекап handybackup, потом обновили esxi до 7.х и отформатировали все диски.

Leave a Reply

Your email address will not be published. Required fields are marked *