- PVSM.RU - https://www.pvsm.ru -
В корпоративные блоги принято писать success story — это положительно влияет на образ компании. К сожалению, не всегда в работе инженера всё заканчивается happy end-ом.
Надо сказать, что коллеги уже начинают подшучивать, что я «притягиваю» проблемы. Тем или иным образом я поучаствовал почти во всех проблемных заявках за последнее время. И теперь хочу рассказать одну поучительную историю из своей практики.
История началась с того, что меня попросили проанализировать производительность дискового массива IBM Storwize v7000 gen1, «тормоза» которого парализовали работу целого филиала. Исходная ситуация такая:
Согласно логам производительности массива, «тормоза» возникали не из-за повышенной нагрузки. Я заподозрил, что причиной проблем является вышедший из строя контроллер на виртуализованной СХД HP EVA. Обычно проблемы с производительностью решаются удалённо, но в данном случае решили отправить инженера на место (тогда ещё никто не подозревал, что командировка затянется на две недели).
И тут в ходе анализа производительности начал проявляться «полтергейст»: у томов с массива в интерфейсе vSphere периодически отображается неверный объём (от отрицательного до десятков петабайт), что заказчик расценил как проблему в массиве. При этом пропадал доступ к консолям части виртуальных машин, и возникают другие неприятности. Даже я уже начал нервничать, а заказчик просто в ауте.
И тут начинается просто фейерверк проблем.
Мы нашли баг ESXi, из-за которого могут отображаться неверные размеры томов. Но выясняется, что официального контракта на поддержку VMware нет. Поддержка осуществляется сторонней компанией и только по рабочим дням, а дело происходит в субботу.
Для полного счастья, прошивки двух серверов из трёх и коммутаторов (блейд-шасси) отстают от прошивки модуля управления шасси, что тоже может приводить к самым неожиданным проблемам. Ну и вишенка на торте: на коммутаторах SAN стоят разные версии прошивок, и все позапрошлой мажорной версии (6.x.x, когда доступна 8.0.x).
Напоследок выясняется, что в MS SQL Server Express закончилось свободное место, из-за чего возник «полтергейст» с доступностью консолей VM в vSphere и неверно отображались размеры томов. Так что пока администраторы решали проблемы БД, мы пытались разобраться с СХД.
После некоторых действий основной том вдруг ушёл в оффлайн.
Мы вспоминили про баг в прошивках Storwize версий 7.3, 7.4 и 7.5, из-за которого на сжатых томах после определённого количества обращений могут появиться битые блоки (в этой ситуации не может помочь ни отказоустойвость RAID, ни зеркалирование томов на соседний массив, так как ошибка находится уровнем выше).
И вот тут проявился самый интересный нюанс: оказывается, что СРК у заказчика не работает уже 3 месяца. То есть бэкапы есть, но они не актуальные, и восстанавливаться из них — всё равно, что потерять данные.
Нам удалось перевести том в онлайн (через CLI массива), но при первой же попытке хоста что-то записать, он снова упал. Мы отключили все датасторы на серверах и следующие сутки провели в офисе, почти не дыша копируя все виртуальные машины куда получится — на серверы, USB-диски и ПК.
В результате нам удалось спасти все данные, кроме ВМ, на которой запустили консолидацию снапшотов, так как в процессе консолидации LUN ушёл в оффлайн, и вместо данных ВМ осталась «каша». По закону подлости это оказалась ВМ электронного документооборота. Кроме того, для исключения разных рисков пришлось обновить почти всю инфраструктуру — VMware, Brocade, HP Blade, IBM Storwize.
Какие выводы может сделать из этой истории уважаемый читатель, чтобы не оказаться в подобной ситуации?
Спасибо за внимание, работы вам без сбоев.
Алексей Трифонов Tomatos [1], инженер Сервисного центра компании «Инфосистемы Джет».
Автор: Инфосистемы Джет
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/rezervnoe-kopirovanie/262253
Ссылки в тексте:
[1] Tomatos: https://habrahabr.ru/users/tomatos/
[2] Источник: https://habrahabr.ru/post/335618/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.