Речь сегодня пойдет об отказоустойчивости и даже о катастрофоустойчивости.
Почему вроде бы правильно настроенное архивирование базы данных не всегда помогает спасти систему в случае инцидентов? Этим вопросом я, наверное, многих даже задел за живое. Одних тем, что сама постановка вопроса им кажется абсурдной – у этой группы админов все настроено идеально, работает как часы и они готовы к любым катаклизмам. А кого-то тем, что напоминаю о тех самых инцидентах, когда возвращаться в тот день, даже мысленно, совсем не хочется.
В рамках проектов аудита производительности мы обязательно проверяем систему заказчика на предмет используемых средств отказоустойчивости и катастрофоустойчивости и, если есть основания, обязательно предоставляем рекомендации по улучшениям. Соответствующий раздел в своё время стал обязательным в каждом отчёте аудита не на пустом месте. За долгие годы мы встречались с таким количеством ситуаций, что можно начинать писать книгу :) Сама по себе ситуация краха системы редкая, поэтому вопросы отказоустойчивости далеко не везде в приоритете, а с учетом распространения в последние годы разнообразных ЦОД’ов, появляется большой соблазн снять с себя ответственность за целостность базы данных и непрерывного доступа к ней. Так что, с появлением ЦОД’ов люди совсем расслабились. А зря.
Опишу несколько характерных примеров из нашей практики, с которыми мы столкнулись, причем в роли спасателей клиентской инфраструктуры и данных. Иногда на кону стояло само существование БД, иногда – интервал потерянных данных, иногда – время простоя бизнеса.
У читателя может возникнуть вопрос: почему это Софтпоинт что-то там спасал, разве это в его компетенции?
Дело в том, что во всех описанных ниже примерах, в клиентской инфраструктуре работал наш продукт DB Replication, с соответствующим сервисным контрактом. И только благодаря его наличию и были возможны все спасательные мероприятия.
Все примеры реальные. Но по понятным причинам обезличенные. Это обычные коммерческие компании. Под обычными я понимаю – не ВПК и не финансовые, для которых вопросы безопасности, резервирования и отказоустойчивости стоят всегда на первом месте, и они готовы к разного рода катаклизмам.
Пример 1
Компания: Сеть магазинов техники.
Инцидент: Сгорел ЦОД.
Да, начнем прямо с этого кейса.
В ЦОД’е были базы всех магазинов.
В нем же погибли актуальные бэкапы за последнюю неделю.
Во внешнем периметре "живыми" остались:
Бэкапы магазинов недельной давности. Для розничной сети – это прям совсем тоскливо. И вопрос стоит уже не просто о простое бизнеса, а о потери значимого массива данных.
Дистрибутор репликации – служебный сервер DB Replication – с архивом транзакций за два месяца.
Тут стоит сказать пару слов о том что такое Дистрибутор репликации, т.к. в нашей истории – это главный герой. В рамках продукта DB Replication – это отдельная машина, которая осуществляет координацию пакетов между подписчиками – между базами, подключенными к системе обмена данными. То есть, дистрибутор принимает пакеты изменений, осуществляет ряд служебных проверок – контроль конфликтов, проверка/применение правил фильтрации и др. – и отправляет их по заданному маршруту. Все цепочки транзакций хранятся с определенной глубиной. В нашем случае – два месяца. Да, еще забыл упомянуть, что синхронизация между подписчиками почти мгновенная – единицы секунд. Т.е. если в структуре обмена существует клон продуктивной базы, то он именно клон. Отставание в несколько секунд будет в любом случае нивелировано прокачкой репликационных очередей, формирующихся непрерывно и по мере фиксации изменений данных в каждой базе.
Что сделали:
Подняли бэкапы магазинов из п.1. Для каждого из них из архива Дистрибутора репликации прокачали всю цепочку транзакций, начиная с момента снятия бэкапа. Тем самым, все базы пришли в состояние, актуальное на момент аварии.
Все базы магазинов были восстановлены последовательно в течение нескольких часов.
Пример 2.
Компания: Розничная сеть магазинов. Геораспределенная.
Инцидент: вирус-шифровальщик
Краткая справка по инциденту:
Вирус зашифровал боевой сервер примерно в час ночи.
Почти сразу же начали борьбу, ограничивать периметр и т.п.
Актуальные бэкапы были уничтожены вирусом. За периметром остался бэкап двухнедельной давности.
Оказался непострадавшим гео-удаленный подписчик репликации - фактически клон рабочей базы, находящийся в другом регионе.
Также, чудесным образом, не успел пострадать Дистрибутор репликации с архивом транзакций, находившийся в другом сегменте сети.
До того, как умер сервер СУБД шифровальщик лютовал в периметре уже часов пять и часть второстепенной инфраструктуры успела отвалиться, в том числе сетевой канал до другого региона с гео-удалённым подписчиком репликации. Соответственно на Дистрибуторе репликации скопились десятки тысяч транзакций, соответствующие работе пользователей примерно за 5 часов до момента сбоя в 1:00.
Что сделали:
В ~3:00 приняли решение, что нужно тянуть базу с гео-удалённого подписчика – поставили ее копироваться.
К утру база скопировалась, подняли ее. Но из-за отвалившегося канала связи база отставала от продуктивной на ~5 часов.
Прокачали скопившиеся очереди с Дистрибутора репликации, тем самым привели базу в состояние, полностью актуальное на момент выхода из строя 1:00.
Справедливости ради был похожий случай, с шифровальщиком, когда в закрытом контуре оказался сервер дистрибутора, который пострадал вместе с сервером СУБД, а бэкапы удалось вовремя изолировать и спасти. Поэтому обошлось все штатными средствами. Но ситуация могла пойти и по негативному сценарию.
Пример 3.
Компания: Сфера услуг ЖКХ.
В организации существует два десятка распределенных баз данных 1С. Каждая из информационных систем подключена к своему контуру репликации DB Replication. Т.е. дистрибуторов репликации тоже два десятка. Кроме этого, имеется одна консолидирующая база данных (КБД), в которую доставляются данные от каждой из двадцати контуров.
КБД используется для составления отчетности, в т.ч. консолидированной отчетности по холдингу, а также для аналитики.
Инцидент: Разрушение дисковой системы консолидирующей базы.
Полный бэкап есть только трехдневной давности. Журналов транзакций нет, т.к. модель восстановления БД – SIMPLE.
Получается, данные примерно за 2,5 суток утеряны.
Что сделали:
Было предпринято восстановление информации с помощью архивов репликации.
На каждом из двадцати Дистрибуторов имеется архив репликации за несколько недель. С каждого Дистрибутора для КБД прокачали цепочку транзакций, с момента снятия бэкапа КБД и до текущего момента.
КБД актуализирована и продолжает получать актуальные изменения из двадцати контуров уже в режиме онлайн.
Общее время на восстановительные работы – около суток.
Пример 4.
Компания: Крупная логистическая компания.
Организация имеет распределенную сеть баз данных. Одна из баз в контуре обмена – вспомогательная, используется для выполнения тяжелых регламентных операций (в рамках балансировки нагрузки).
Контур обмена и балансировки нагрузки строится на технологии DB Replication.
Инцидент:
Вспомогательная БД вышла из строя из-за возникновения ошибок данных (dbcc checktable) в нескольких таблицах 1С. Но! База умерла не сразу, а спустя несколько дней.
Сначала ошибки проявились в некритической мере, база еще продолжала быть функциональной, и в ней шла работа. Далее администратор предпринял попытку(и) восстановить битые данные с помощью системных процедур MS SQL, но стало только хуже. База вышла из строя.
Теперь по бэкапам. Бэкапы были, но поднимать свежий бэкап смысла нет, т.к. база развернется с теми же битыми таблицами, ибо работа в базе продолжалась даже после появления ошибок в таблицах. А поднимать более старый бэкап, с небитыми таблицами — значит потерять часть введенных данных.
Что сделали:
Подняли бэкап 5-ти дневной давности, где таблицы были еще не битые.
Из архива Дистрибутора репликации прокачали всю цепочку транзакций за несколько суток, начиная с даты поднятого бэкапа. База пришла в актуальное состояние.
Этот пример очень хорошо показывает, что наличие даже актуальных бэкапов не решает проблемы с битыми таблицами (испорченными данными). И простого и изящного решения без DB Replication, позволившего бы в кратчайшие сроки запустить базу в строй, просто нет.
Выводы
Я привел несколько примеров того, как правильная настройка резервирования могла бы сэкономить кучу нервов и времени техподдержке. Падение продуктивной базы в крупной компании – это не просто ЧП, это стресс и удар по бизнесу. С момента инцидента счет может идти на минуты. Но важно суметь восстановить работоспособность системы не просто оперативно, но при этом еще и не потерять данные. Одно дело, когда потерянные данные измеряются минутами, а совсем другое – днями или неделями. Не всякий бизнес устроит вариант откатить базу данных на два дня назад и уж тем более на неделю.
Так что, основной посыл этой статьи – это обращение к администраторам. Посмотрите на свою систему еще раз с точки зрения резервирования и отказоустойчивости: модель восстановления, периодичность бэкапирования, бэкап лога транзакций, AlwaysOn.
Учитывая, что ситуации, описанные выше, не такие уж редкие, хочу привести несколько рекомендаций, которые подойдут почти всем.
Модель восстановления базы данных переводим в режим FULL (Полная).
Вот теперь нужно настроить легковесные бэкапы лога транзакций с периодичностью несколько раз в час. В случае сбоя это позволит восстановить базу до последней такой копии. Таким образом, пользователи, в самом худшем случае, потеряют лишь несколько минут своей работы.
Разносим по разным дискам файлы базы данных и лога транзакций. Если используете СХД, то там свои настройки отказоустойчивости.
Сохраняем бэкап базы данных и журнала транзакций на другом сервере.
Разворачиваем отказоустойчивый кластер AlwaysOn, в рамках которого вторичная реплика будет обеспечивать наличие актуальной копии рабочей БД.
Более того, в рамках AlwaysOn еще одну дополнительную реплику можно подключить за пределами инфраструктуры продуктивной ИТ-системы – в другом городе, другом регионе, другой стране. При работе кластера в асинхронном режиме это позволит обеспечить хорошую катастрофоустойчивость. Но может потребовать хороших каналов связи и мониторинга актуальности копии, особенно если к каналам связи есть вопросы.
Если критичен "интервал потери данных", то лучше использовать репликацию. Мы, естественно, предлагаем использовать DB Replication.
Ее использование нисколько не отменяет предыдущих пунктов. Это лишь дополнительная страховка, которая как показала практика, может стать вашим последним шансом.
Сформулируйте возможные инциденты, различные сценарии реагирования и восстановления, готовы ли вы к ним в принципе, и каковы ваши действия при возникновении инцидента – пошаговые планы с расчётами времени восстановления.
Ну а тем, кого заинтересовал DB Replication, милости просим на нашу страницу.
