Есть прекрасная поговорка «И на старуху бывает проруха». Её можно сделать девизом индустрии: даже хорошо продуманная многоуровневая система защиты от потери данных может пасть жертвой непредвиденного бага или человеческой ошибки. Увы, такие истории не редкость, и сегодня мы хотим рассказать о двух случаях из нашей практики, когда всё пошло не так. Shit happens, как говаривал старина Форрест Гамп.
Случай первый: баги вездесущи
У одного нашего заказчика использовалась система резервирования, спроектированная с целью защиты от аппаратного сбоя. Для обеспечения высокой доступности функционирования уровней инфры и приложений использовалось кластерное решение на базе ПО Veritas Cluster Server. Резервирование данных достигалось с помощью синхронной репликации средствами внешних дисковых массивов. Перед обновлением системы или отдельных ее компонент всегда проводилось длительное тестирование на стенде в соответствии с рекомендациями производителя ПО.
Cистема грамотная, распределенная по нескольким площадкам на случай потери одного дата-центра целиком. Казалось бы, всё хорошо, решение по резервированию прекрасное, автоматизация настроена, ничего страшного произойти не может. Система работала уже много лет, и никаких проблем не возникало — при сбоях всё отрабатывало штатно.
Но вот настал тот миг, когда упал один из серверов. При переключении на резервную площадку обнаружили, что одна из крупнейших файловых систем недоступна. Долго разбирались и выяснили, что мы наступили на программный баг.
Оказалось, незадолго до этих событий накатили обновление системного софта: разработчик добавил новые фичи для повышения производительности. Но одна из этих фич глюканула, и в результате оказались повреждены блоки данных одного из дата-файлов БД. Он весил всего 3 Гб, но вся беда в том, что его пришлось восстанавливать из бэкапа. А последний полный бэкап системы был… почти неделю назад.
Для начала заказчику пришлось достать всю базу из бэкапа недельной давности, а затем применить все архивные логи за неделю. На то, чтобы достать несколько терабайт c лент, ушла куча времени, потому что СРК фактически зависит от текущей нагрузки, свободных приводов и ленточных накопителей, которые в самый нужный момент могут оказаться занятыми другим восстановлением и записью очередного бэкапа.
В нашем случае всё оказалось ещё хуже. Беда не приходит одна, ага. Восстановление из полного бэкапа прошло достаточно быстро, потому что были выделены и ленточки, и приводы. А вот бэкапы архив-логов оказались на одной ленте, так что запустить параллельное восстановление в несколько потоков не получилось. Мы сидели и ждали, пока система находила на ленте нужную позицию, считывала данные, перематывала, снова искала нужную позицию, и так раз за разом по кругу. А поскольку СРК была автоматизированная, то на восстановление каждого файла генерировалось отдельное задание, оно попадало в общую очередь и ожидало в ней освобождения необходимых ресурсов.
В общем, несчастные 3 гигабайта мы восстанавливали 13 часов.
После этой аварии заказчик пересмотрел систему резервирования и задумался над ускорением работы СРК. Решили отказаться от лент, рассмотрели вариант с программной СХД и применением различных распределенных файловых систем. У заказчика уже были на тот момент виртуальные библиотеки, но их количество увеличили, внедрили программные комплексы дедупликации и локального хранения данных для ускорения доступа.
Случай второй: человеку свойственно ошибаться
Вторая история более прозаичная. Подход к построению систем распределенного резервирования был стандартизирован в то время, когда никто не предполагал наличие низкоквалифицированных кадров за консолью управления сервера.
На высокую утилизацию файловой системы сработала система мониторинга, дежурный инженер решил навести порядок и почистить файловую систему на сервере с базой данных. Инженер находит журнал аудита базы данных — как ему кажется! — и удаляет его файлы. Но нюанс в том, что сама база данных тоже называлась «AUDIT». В результате дежурный инженер заказчика перепутал каталоги и лихо удалил саму базу данных.
Но база данных в этот момент работала, и свободное место на диске после удаления не увеличилось. Инженер начал искать другие возможности уменьшить объем файловой системы – нашел их и успокоился, при этом никому не рассказав о проделанном.
Прошло примерно 10 часов, прежде чем от пользователей начали приходить сообщения, что база данных работает медленно, а какие-то операции вообще не проходят. Наши специалисты начали разбираться и выяснили, что файлов-то и нет.
Переключаться на резервную площадку смысла не было, потому что работала синхронная репликация на уровне массива. Все изменения, которые были проделаны на одной стороне, мгновенно отразились на другой. То есть данных не было уже ни на основной площадке, ни на резервной.
Инженера от самоубийства или суда Линча спас опыт наших сотрудников. Дело в том, что файлы базы данных располагались в кроссплатформенной файловой системе vxfs. Благодаря тому, что никто ранее не остановил работу БД, inode удаленных файлов не перешли во freelist, еще не были никем использованы. Если становить приложение и «отпустить» эти файлы, то файловая система доделает «грязное дело», пометит блоки, которые были заняты данными, как свободные, и любое приложение, которое запросит дополнительное место, сможет спокойно их перезаписать.
Чтобы спасти положение, мы на ходу разорвали репликацию. Это не позволило файловой системе на удаленном узле синхронизировать высвобождение блоков. Потом при помощи отладчика файловой системы пробежались по последним изменениям, выяснили, какие inode каким файлам соответствовали, перепривязали их, удостоверились, что файлы базы данных снова появились, и проверили консистентность БД.
Затем предложили заказчику поднять на восстановленных файлах экземпляр базы данных в standby-режиме и таким образом синхронизировать данные на резервной площадке без потери online-данных. Когда всё это было сделано, нам удалось переключиться на резервную площадку без потерь.
По всем расчетам первичный план восстановления при помощи СРК мог растянуться вплоть до недели. В данном случае обошлись деградацией сервиса, а не его полной недоступностью. Человеческая ошибка могла обернуться финансовыми и репутационными потерями, вплоть до потери бизнеса.
Тогда наши инженеры придумали решение. В 90% систем заказчика работают базы данных Oracle. Мы предложили оставить старую систему резервирования, но дополнить её системой резервирования на уровне приложения. То есть к синхронной репликации средствами массивов добавили еще и программную — средствами Oracle Data Guard. Его единственный недостаток в том, что после failover необходимо проделать ряд мероприятий, автоматизировать которые проблематично. Чтобы их избежать мы реализовали переключение экземпляров между площадками средствами кластерного ПО с подменой конфигов БД.
В результате появился дополнительный уровень защиты данных. К тому же новая система резервирования помогла снизить требования к массивам, так что заказчик сэкономил в деньгах, перейдя с массивов уровня Hi-End на СХД среднего уровня.
Вот такой Happy End.
Команда поддержки Enterprise-систем, «Инфосистемы Джет»
Автор: JetHabr
