Недоступность основной инфраструктурной площадки отличается от отказа отдельного сервера или виртуальной машины. В таком сценарии компания может одновременно потерять доступ к вычислительным ресурсам, сети и рабочим системам. Поэтому при проектировании резервирования важно заранее определить, где будут храниться данные, на каких ресурсах можно восстановить сервисы и сколько времени допустим простой.
Если часть систем и данных разрешено размещать за пределами России, резервный контур можно вынести в облачную инфраструктуру за рубежом. При выборе страны учитывают требования к локализации данных, сетевые задержки, пропускную способность каналов и доступ пользователей после переключения.
Когда достаточно резервного копирования
Резервное копирование защищает данные от удаления, повреждения и потери исходной системы. Из копии можно восстановить виртуальную машину, базу данных или отдельные файлы.
Но наличие резервной копии еще не означает быстрое восстановление сервиса. Если рабочая инфраструктура недоступна, сначала нужно выделить новые вычислительные ресурсы, восстановить данные, настроить сеть и вернуть доступ пользователям.
Для систем, которые могут оставаться недоступными несколько часов, такой сценарий приемлем. Чем критичнее сервис и дороже его простой, тем выше требования к скорости восстановления.
Поэтому инфраструктуру обычно разделяют по критичности. Для архивов и части внутренних систем может быть достаточно резервного копирования в облако. Для бизнес-приложений с жесткими требованиями к доступности используют Disaster Recovery или заранее подготовленный резервный контур.
RPO и RTO: сколько данных и времени можно потерять
Требования к восстановлению описывают двумя показателями.
RPO определяет, какой объем данных компания может потерять по времени. Например, RPO в один час означает, что после сбоя допустима потеря изменений, сделанных за последний час.
RTO показывает, за какое время сервис должен снова начать работать.
Эти параметры задают отдельно для разных систем. Архив документов, внутренняя CRM и сервис, через который проходят клиентские операции, обычно имеют разные требования к восстановлению.
Чем ниже допустимые RPO и RTO, тем чаще нужно передавать актуальные данные на резервную площадку и тем больше инфраструктуры должно быть подготовлено заранее.
Где хранить резерв
Резерв, который находится в той же инфраструктуре, что и рабочие системы, может оказаться недоступным одновременно с ними. Поэтому копии выносят за пределы основного контура.
Один из вариантов — резервное копирование данных на удаленной площадке. Рабочая среда и хранилище копий в этом случае физически разделены, поэтому отказ основной площадки не затрагивает резерв.
При выборе географии важен не максимальный километраж, а независимость площадок и качество связи между ними. Если данные активно изменяются и требуется небольшой RPO, канал должен обеспечивать нужную скорость передачи.
Резерв можно разместить в другом городе, регионе или стране. Для международной схемы дополнительно проверяют требования к передаче и хранению данных.
Инфраструктура ITGLOBAL.COM, например, представлена на площадках в Беларуси, Казахстане, Узбекистане, ОАЭ и Бразилии. Это позволяет выбирать географию основного и резервного контуров с учетом требований конкретного проекта.
Когда нужен Disaster Recovery
Если восстановление из резервной копии занимает слишком много времени, используют Disaster Recovery.
При такой схеме рабочие системы реплицируются на резервную площадку. После сбоя виртуальные машины запускаются из подготовленных реплик, поэтому не требуется заново разворачивать всю инфраструктуру и последовательно восстанавливать ее из копий.
DR подходит для систем, где простой измеряется не часами, а минутами или десятками минут. Конкретная архитектура зависит от требуемых RPO и RTO, объема данных и скорости каналов связи.
Для наиболее критичных приложений можно поддерживать отдельный резервный контур с постоянно доступными вычислительными ресурсами. При переключении его масштабируют и переводят на него рабочую нагрузку.
Эти подходы можно сочетать. Архивы восстанавливать из копий, часть корпоративных приложений защищать через Disaster Recovery, а для нескольких наиболее важных систем держать готовую резервную инфраструктуру.
Как проверить готовность к восстановлению
Схему резервирования нужно проверять до реального сбоя.
В зависимости от выбранного сценария тестируют:
-
восстановление данных из резервной копии;
-
запуск виртуальных машин из реплик;
-
доступ сотрудников к системам;
-
сетевую связность между сервисами;
-
переключение DNS и внешних адресов;
-
фактические RPO и RTO.
Тест можно проводить в изолированной среде без остановки рабочих систем. По итогам фиксируют реальное время восстановления и проблемы, которые нужно устранить.
Повторная проверка нужна после существенных изменений инфраструктуры: миграции систем, изменения сетевой схемы, добавления новых приложений или изменения требований к доступности.
Как выбрать схему резервирования
Единой схемы для всей инфраструктуры обычно не требуется. Выбор зависит от критичности конкретной системы.
Если допустимо восстановление в течение нескольких часов, достаточно удаленных резервных копий. Если простой нужно сократить, используют Disaster Recovery. Для систем с минимально допустимым перерывом в работе заранее готовят отдельные вычислительные ресурсы.
Начинать стоит с RPO и RTO, а уже затем выбирать технологию и географию. Такой порядок позволяет не строить избыточный резерв для некритичных систем и одновременно обеспечить нужную скорость восстановления там, где простой напрямую влияет на работу бизнеса.
