Речь сегодня пойдет об отказоустойчивости и даже о катастрофоустойчивости.
Почему вроде бы правильно наст��оенное архивирование базы данных не всегда помогает спасти систему в случае инцидентов? Этим вопросом я, наверное, многих даже задел за живое. Одних тем, что сама постановка вопроса им кажется абсурдной – у этой группы админов все настроено идеально, работает как часы и они готовы к любым катаклизмам. А кого-то тем, что напоминаю о тех самых инцидентах, когда возвращаться в тот день, даже мысленно, совсем не хочется.
В рамках проектов аудита производительности мы обязательно проверяем систему заказчика на предмет используемых средств отказоустойчивости и катастрофоустойчивости и, если есть основания, обязательно предоставляем рекомендации по улучшениям. Соответствующий раздел в своё время стал обязательным в каждом отчёте аудита не на пустом месте. За долгие годы мы встречались с таким количеством ситуаций, что можно начинать писать книгу :) Сама по себе ситуация краха системы редкая, поэтому вопросы отказоустойчивости далеко не везде в приоритете, а с учетом распространения в последние годы разнообразных ЦОД’ов, появляется большой соблазн снять с себя ответственность за целостность базы данных и непрерывного доступа к ней. Так что, с появлением ЦОД’ов люди совсем расслабились. А зря.
Опишу несколько характерных примеров из нашей практики, с которыми мы столкнулись, причем в роли спасателей клиентской инфраструктуры и данных. Иногда на кону стояло само существование БД, иногда – интервал потерянных данных, иногда – время простоя бизнеса.
У читателя может возникнуть вопрос: почему это Софтпоинт что-то там спасал, разве это в его компетенции?
Дело в том, что во всех описанных ниже примерах, в клиентской инфраструктуре работал наш продукт 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, милости просим на нашу страницу.
