Всем привет!
Пятница, вечер, дождик…
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 не загружался, в консоли висела надпись:
|
1 |
/usr/local/vdr/configure/bin/checkforddrpreset.pl", exit status=0 |
Перезагрузка не помогла, через час все было точно также.
vDP пытались оживить сначала вручную, потом через техподдержку VMware. Третий по счету инженер из EMC смог оживить бэкапы и мы узнали… что последний бэкап сделан год назад. Так как “Retention Policy” требует хранить бэкапы за последние 90 дней…
Тут мой тезка и говорит “у меня есть еще одна система резервного копирования, сохраняющая файлы на сервер в Amazon. Но я залогиниться туда не могу 🙁
В общем, сервер с бэкапами на Amazon оказался заражен каким-то ransomware…
Параллельно была сделана попытка выключить и включить система храения с выдергиванием/втыканием SSD-дисков (потому что она еще и на RAID-контроллер ругалась)…
После включения массива сдохло еще 4 SAS-диска (2 уже не работали), вследствие чего Lun2 ушел следом за Lun3. Как оказалось, MD3220i более 7 лет.
Какие выводы (кроме настройки уведомлений) вы бы сделали из обоих историй?
Какие epic fail были у вас?
> вследствие чего Lun2 ушел следом за Lun2
где то закралась ошибка в цифрах
А про выводы давно сказано – бекапы нужно тестировать! СХД должны быть на мониторинге (хотя бы snmp трапы), тогда спать можно будет спокойно.
>где то закралась ошибка в цифрах
fixed
Все ит-шники делятся на три категории:
1. Кто еще не делает бекап.
2. Кто уже делает.
3. Кто делает и регулярно восстанавливает.
Угу 🙂
Зато 3PAR – огонь:
– в 9:33 пришло письмо о выходе из строя диска;
– в 10:27 приходит письмо с заявкой от HPE о замене диска.
Из фееричного:
Досталась настроенная система бекапа, планировщик бекапа был настроен в виндовом шедулере, шедулер запускал батник с командами на бекап. Работало все годами отлично – был успешный бекап и успешный рестор. В какой то момент надо было что-то отресторить – а бекапа нет (( В результате разбора было выяснено что в винде по дефолту стоит галочка на прекращение работы задания если оно идёт больше трех дней, с годами бекапы выросли и последнее задание не всегда стало успевать выполняться… Галочка кстати в 2003 не на виду была, в Advanced где-то..
Так 3PAR стоит на круг (т.е. со всеми возможными поддержками и SLA) один диск от 3 до 5 млн. руб. Мне считали на 7 Тб один. Еще бы он, сук, не огонь был.
В случае 3par вы еще и получаете бонусом Dedupe+Compression, которая эту сумму (в сравнении с Dell MD со скриншота) “делит” на 2-4 (за счет сжатия).
Мне кажется, что 7ТБ диски у всех midrange-массивов (которые не Dothill) примерно одинаково стоят, или нет?
Диски, возможно, да. У Fujitsu (например dx500) как-то по разумнее цена и дедуп это же не про диск, а функционал полки, который не должен добавлять стоимость к носителю. Да и не столько он стоит в конце концов. Короче, рассматривал 3пар, вышло в круг пизд…ц как дорого. Остановился на фуджи, при том же (почти:) функционале. Но 3пар – топ, это факт.
Мдя почитал, и сразу понятно стало до моего опыта далеко. Диски с одной партии ресурс как минимум одинаковый вот и весь вывод.
Проблема не в дисках.
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 задачи управлять дисками и данные сохранять/отдавать) и с основной задачей оно справляется вот так, решайте сами…
> Как относиться к СХД (у которой всего 2 задачи управлять дисками и данные
> сохранять/отдавать) и с основной задачей оно справляется вот так, решайте сами…
В entry-level никто никому ничего по определению не должен, да и в mid-range уже тоже.
Справедливости ради замечу, что в австралийской налоговой кластер из 3par развалился.
Правда, я не помню, пришлось ли там за бэкапами ходить…
История факапа: как оказалось, 1 хост, на нём esxi, 8 одиночных дисков отформатированы в vmfs, на них расположены NAS_x.vmdk из которых собран ZFS RAIDZ, который доступен по SMB, на который с помощью HandyBackup был сделал в zip бекап, после сделали снимок vmfs через esxi, потом ещё раз бекап handybackup, потом обновили esxi до 7.х и отформатировали все диски.