Мы уверены, что аудитории нашего блога нет нужды рассказывать о важности резервного копирования критически важных данных. Однако правильный ответ на вопрос, как именно это делать, уже не выглядит таким однозначным. Резервирование и проверка восстановления сервисов, вне зависимости от того, в какой инфраструктуре они находятся, могут быть выполнены множеством способов. И сегодня мы хотим рассказать о том, как это сделать при помощи нативных инструментов облачной платформы Amazon Web Services (AWS).

Сценарии резервирования и восстановления

Организация системы резервного копирования и восстановления инфраструктуры начинается с выбора подходящего сценария, зависящего от потребностей бизнеса:

·       Первый и самый простой вариант – регулярное создание и локальное хранение бэкапов. В этом случае восстановление будет происходить также на локальную систему. При этом участие облачных сервисов вообще не подразумевается.

·       Второй вариант – хранение бекапов в облаке и восстановление сервисов на собственной инфраструктуре on premise.

·       Третий сценарий применяется тогда, когда и бэкапы хранятся в облаке, и система восстанавливается в публичной облачной инфраструктуре.

·       Наконец, четвертый вариант – организация катастрофоустойчивой инфраструктуры, в которой сервисы дублируются, располагаются на разных удаленных друг от друга площадках.

Выбрать подходящий сценарий поможет ваша текущая архитектура, а также определение максимально возможного периода недоступности сервисов в случае сбоя. Одни организации могут без катастрофических последствий подождать восстановления в течение рабочего дня, для других каждая секунда простоя выливается во вполне ощутимые финансовые потери.

Это подводит нас к двум важным показателям, контроль которых поможет избежать нежелательных последствий или минимизировать их.

·       RTO (Recovery Time Objective) – максимальный период времени, за который могут быть потеряны данные в результате аварии.

·       RPO (Recovery Point Objective) – промежуток времени, в течение которого система может оставаться недоступной после сбоя.

Непрерывность бизнеса имеет решающее значение, но ресурсы, которые компания готова выделить на службы бэкапа и восстановления отнюдь не бесконечны. В этом плане AWS предлагает широкие возможности управления расходами. Так, например, «холодное хранение» бэкапов в архивах существенно дешевле «горячего», но времени на их извлечение уйдет в несколько раз больше, а само скачивание окажется дороже. При редких обращениях любая политика может оказаться экономически более эффективной на каком-то отрезке времени.

Важно отметить, что решение по выбору условий хранения бэкапов не является единоразовым. Текущие потребности необходимо постоянно пересматривать, а ресурсы – оптимизировать. В том числе проверять, нет ли возможности на время отключать неиспользуемые сервисы, тем самым останавливая их оплату.

AWS предоставляет для организации резервного копирования и восстановления несколько собственных инструментов:

·       AWS Storage Gateway – предназначен для реализации двух основных сценариев: хранения в облаке бэкапов локальной инфраструктуры заказчика (on premise в облако) или, наоборот, локального хранения бэкапов облачной инфраструктуры (облако в on premise).

·       AWS Backup – используется в сценариях облако-в-облако и облако-в-on premise.

·       CloudEndure Disaster Recovery – поддерживает все три сценария.

Рассмотрим каждый из них подробнее.

AWS Storage Gateway

AWS Storage Gateway позволяет применять привычные для локальной инфраструктуры протоколы и интерфейсы, используя при этом облачное хранилище Amazon S3. По сути, инструмент является посредником между локальной площадкой и платформой AWS. Внутри AWS Storage Gateway работают три сервиса:

·       Файловый шлюз, который используется для создания и управления файловыми хранилищами на базе протоколов NFS и SMB.

·       Ленточный шлюз, представляющий собой виртуальную ленточную библиотеку, работающую по протоколу iSCSI VTL.

·       Шлюз томов, применяемый для создания и управления виртуальными дисками iSCSI.

Данные, загружаемые через AWS Storage Gateway, хранятся в объектном хранилище S3. При этом прямого доступа к ним у пользователя услуги нет. Все операции с информацией выполняются только посредством API AWS Storage Gateway.

Подключение к сервису локальной инфраструктуры осуществляется с помощью виртуальной машины (одного из вышеперечисленных шлюзов). Эту задачу может выполнять и специальный аппаратный сервер, но в России он, к сожалению, к заказу пока недоступен.

Для изготовления бэкапов можно использовать получение мгновенных снимков состояния Amazon Elastic Block Store или сервис гибкого автоматического резервирования AWS Backup. Помимо предоставленного объема хранилища тарифицируются также передача данных и снимки состояния.

AWS Backup

Несмотря на свое название, AWS Backup заметно отличается от привычных систем резервного копирования. Изначально он задумывался для бэкапа других сервисов AWS, а не локальных нагрузок. В то же время, сервис AWS Storage Gateway как раз сам является таким сервисом и тоже может быть резервирован.

Базовые возможности AWS Backup аналогичны шлюзу томов в AWS Storage Gateway, однако здесь значительно расширены инструменты формирования расписания снимков Amazon Elastic Block Store, включая сложные сценарии с использованием нескольких типов хранилищ, репликаций в другой регион и политик хранения. При работе с AWS Backup тарифицируется объем хранилища резервных копий и, в некоторых случаях, месячный объем восстанавливаемых данных.

CloudEndure Disaster Recovery

Этот сервис репликаций и аварийного восстановления не входит в стандартный набор служб AWS, но он может быть установлен из маркетплейса облачного провайдера. Основной его задачей является непрерывная репликация всех используемых машин, в том числе операционных систем, конфигураций состояния системы, баз данных, приложений и файлов. При его использовании репликация происходит в промежуточную среду в целевом аккаунте AWS и заранее выбранном регионе.

Сервис позволяет реплицировать виртуальные машины с любой платформы виртуализации, из сторонних облаков, с площадки AWS в другом регионе или локальных физических серверов под управлением Windows или Linux. Для этого на целевые системы устанавливаются специальные программные агенты.

В контексте задач катастрофоустойчивости стоит также упомянуть сервис системы доменных имен AWS Route 53. С его помощью можно реализовать сценарии автоматического переключения с основной площадки на реплику, создав маршрутизацию на основе доступности ресурса.

CloudEndure Disaster Recovery предоставляется по подписной модели, причем вне зависимости от размера физического сервера или виртуальной машины стоимость подписки остается постоянной.