Службы резервного копирования
Ничто так не пугает персонал ИТ-отдела, как возможность потери данных. Наиболее эффективной стратегией предотвращения потери данных является резервное копирование томов хранилища, виртуальных машин, баз данных и других систем, в которых хранятся данные, чтобы их можно было восстановить. Поставщики облачных служб предлагают службы резервного копирования именно для этой цели. Как правило, эти службы можно использовать для резервного копирования данных, хранящихся как в локальной среде, так и в облаке, причем резервные копии могут быть реплицированы и географически распределены для защиты от происшествий, приводящих к потере данных во всем центре обработки данных или регионе.
Общедоступное облако позволяет динамически предоставлять большие объемы ресурсов, причем это могут быть не просто отдельные хранилища, а пулы носителей с высоким уровнем масштабируемости. Они не менее, а в некоторых случаях и более универсальны, чем системы хранения резервных копий и ленточные накопители, которые они заменяют. Кроме того, они дают организациям новые возможности по реализации избыточности, отработки отказа и защиты, которые они никак не могли позволить себе в эпоху, когда все ресурсы приобретались из оборотного фонда. Хранилище на базе общедоступного облака выполняет функции, в которых центры обработки данных всегда отчаянно нуждались, но которые до недавних пор было трудно получить.
Облачные службы резервного копирования
Современные службы резервного копирования, предлагаемые поставщиками общедоступных облачных служб, отличает то, как они расширяют возможности инфраструктуры клиентов. До появления таких служб стандартная стратегия резервного копирования организации состояла из двух уровней: резервное копирование томов данных, в которых размещаются базы данных, и резервное копирование образов виртуальных машин, в которых размещаются критически важные рабочие нагрузки. Концепция резервного копирования заключалась в следующем: при отказе системы из-за сбоя сервер становится недоступен. В этом случае необходимо немедленно восстановить состояние сервера из резервного образа.
С появлением облачных инфраструктур старая концепция резервного копирования стала неактуальной. В современных системах серверы состоят из программного обеспечения, а не оборудования. Виртуальные серверы либо размещаются в виртуальной инфраструктуре на основе гипервизора, например VMware NSX, либо собираются из контейнеров и размещаются в виртуализированных операционных системах. В обоих случаях осуществляется непрерывное управление программными образами рабочих нагрузок для приложений и служб, их обновление и защита. Фактически, активные программные компоненты сами являются репликами защищенных главных экземпляров либо, в случае с контейнеризацией, производными от исходных экземпляров, хранящихся в репозиториях контейнеров и автоматически собираемых по мере необходимости. Аппаратный сбой, из-за которого серверный узел выходит из строя, просто делает серверы в этом узле недоступными на некоторое время. Инфраструктура просто перенаправляет трафик в обход узла, тем временем делая все возможное для его замены. Диспетчер инфраструктуры не делает ничего, что он не делал бы раньше в процессе администрирования системы.
Однако, как становится ясно даже при поверхностном ознакомлении с современными центрами обработки данных, не все современные инфраструктуры являются облачными. В локальных центрах обработки данных службы по-прежнему размещаются непосредственно на физическом оборудовании. Все еще распространены клиент-серверные сети, дополненные ПО промежуточного слоя. А в гибридной системе, в которой одна часть, разработанная несколько лет назад, соединена с другой, разработанной в прошлом столетии, сохраняется необходимость в хранении достаточного количества информации о составе системы, чтобы в случае аварии ее можно было оперативно воссоздать в новом расположении с минимальными последствиями для уровней обслуживания. В рамках современных стратегий резервного копирования таким расположением может быть общедоступное облако, даже если восстанавливаемые системы изначально находятся не в облаке.
AWS Backup
В начале 2019 года облачная служба резервного копирования, входящая в состав Amazon Web Services, была переработана под требования гибридных облачных сред клиентов. В центре новой службы AWS Backup, браузерная консоль которой показана на рис. 2, находится обработчик политик, который действует подобно арбитратору в брандмауэре. С помощью этого обработчика администратор резервного копирования создает правила, которые регулируют следующие аспекты:
какие ресурсы в системе требуют резервного копирования;
как должно проводиться каждое резервное копирование и как часто;
где должны храниться образы резервных копий;
как и как часто должна контролироваться целостность резервных образов;
как долго должны храниться резервные образы;
при каких обстоятельствах должно выполняться восстановление.
Все активные политики охватываются планом резервного копирования. Каждое правило ссылается на ресурсы в облаке AWS, требующие резервного копирования, по значению тега, которое представляет собой произвольное имя, заданное администратором. Чтобы включить ресурс, например том Elastic Block Storage (EBS), в план резервного копирования, администратору достаточно присвоить этому ресурсу имя тега, которое будет распознаваться службой AWS Backup. Таким образом, администратору или лицу, ответственному за ресурс AWS, не требуется использовать консоль AWS Backup для включения ресурса в существующий план резервного копирования.
![Рис. 2: консоль резервного копирования AWS. [предоставлено Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
Рис. 2. Консоль резервного копирования AWS. [Предоставлено Amazon]
Локальные ресурсы можно включать в план резервного копирования с помощью шлюза AWS Storage Gateway. Для службы AWS Backup шлюз Storage Gateway выступает в качестве оболочки API вокруг физических томов и устройств хранения, делая их доступными для служб AWS.
Изначально шлюз Storage Gateway позволял заменять существующие физические ресурсы хранения облачными аналогами, поддерживающими тот же интерфейс. Например, локальный том iSCSI можно было инкапсулировать в то, что называется в AWS кэшированным томом. Такая оболочка делает облачное хранилище доступным для существующих локальных приложений без внесения изменений в них. Часто запрашиваемые данные можно по-прежнему хранить на томе iSCSI, выступающем в роли кэша, благодаря чему уменьшается задержка. Кроме того, последние изменения, внесенные в содержимое тома шлюза, можно хранить локально как моментальные снимки. Однако Storage Gateway также поддерживает хранимые тома. В этом случае полная локальная копия тома по-прежнему хранится на локальном устройстве, а ее зеркальная копия создается шлюзом Storage Gateway в облаке. Новая служба AWS Backup использует функцию замены физических томов, предоставляемую шлюзом Storage Gateway, делая локальную копию резервной копией для облачного тома, и в то же время добавляет консоль для централизованного управления политиками, которые регулируют обслуживание обеих реплик.
Одним из важных преимуществ, предоставляемых поставщиками облачных решений в плане аварийного восстановления, является возможность быстрой архивации критически важных данных организации в удаленных расположениях для обеспечения географической избыточности (геоизбыточности). Центры обработки данных AWS работают в самых разных зонах доступности. Заявленная возможность автоматической отработки отказа размещенных на платформе приложений в другие зоны распространяется и на операции резервного копирования данных. Однако, как известно, зоны отработки отказа находятся в одном регионе AWS. В случае чрезвычайной ситуации (возможность которой принимается во внимание страховыми агентствами, а, следовательно, и менеджерами по рискам), например в случае сбоя энергосистемы, смежные зоны доступности могут испытывать перебои в работе.
Разработчик программного обеспечения или пользователь с опытом разработки может создать для организации настраиваемые политики маршрутизации в целях обеспечения геоизбыточности, используя низкоуровневую службу маршрутизации AWS Route 53. Однако для этого требуется немало усилий. Не так давно в AWS была предложена более удобная служба, которая называется AWS Global Accelerator. Это еще один обработчик политик, который направляет трафик и указывает службе Route 53, где должны размещаться службы и хранилище1. Службу Global Accelerator можно также использовать как балансировщик верхнего уровня, который позволяет распределять ресурсы для размещенных приложений (а вместе с ними и критически важные данные) между географически разнесенными зонами доступности.
Специалисты Amazon рекомендуют еще один способ обеспечить хранение резервных данных в достаточно удаленном регионе, который заключается в указании виртуальной группы (контейнера резервного копирования AWS общего назначения) в качестве начального назначения резервного копирования с последующей репликацией этой группы в дополнительное расположение в любой из назначенных зон доступности. AWS предлагает репликацию между регионами (CRR) в качестве отдельной службы2. Стоимость использования службы резервного копирования AWS зависит от объема как сохраняемых, так и восстанавливаемых данных и рассчитывается исходя из гигабайтов.
С точки зрения архитектуры, служба AWS Backup выступает в качестве зеркала для ресурсов AWS. Чтобы включить локальные ресурсы в план, требуется двойной обходной маневр: сначала нужно преобразовать локальные ресурсы в удаленные тома AWS (удаленные с точки зрения Amazon), а затем создать интерфейс резервного копирования с помощью оболочки вокруг этих локальных ресурсов.
Azure Backup
Служба Azure Backup одинаково хорошо справляется с резервным копированием как локальных ресурсов (серверов и виртуальных машин), так и ресурсов, размещенных в Azure. Она не требует изменения существующей политики резервного копирования в центре обработки данных — локальные диски и ленточные накопители просто заменяются облачным хранилищем. Облачное расположение для резервных копий файлов и томов в Azure называется хранилищем Служб восстановления, браузерная консоль которого показана на рис. 3. В процессе установки этого хранилища с портала Azure администратор загружает и устанавливает клиентский агент, известный как агент Служб восстановления Microsoft Azure (MARS). В Windows Server MARS выполняется как приложение, подобно надстройке System Center. (Кроме того, администратор может предпочесть использовать System Center Data Protection Manager, где функции MARS уже встроены.) Администратор находит тома и службы в сети, данные которых требуют резервного копирования, и MARS распределяет агенты по адресам сервера, отвечающим за эти компоненты.
![Рис. 3: консоль хранилища Служб восстановления Azure. [предоставлено Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
Рис. 3. Консоль хранилища служб восстановления Azure. [Предоставлено Майкрософт]
Модель доставки Azure Backup основана на целях уровня обслуживания, связанных с аварийным восстановлением. Они представляют собой показатели, определяющие то, сколько времени организация может выдержать отсутствие доступа к своей бизнес-платформе и каков допустимый объем потери данных в случае аварии. Эти целевые показатели (целевая точка восстановления, целевое время восстановления и срок хранения) рассматриваются в следующем уроке по аварийному восстановлению.
Служба Azure Backup ориентирована исключительно на репликацию данных как средство восстановления, а не на восстановление служб (в отличие от Azure Site Recovery, службы аварийного восстановления Майкрософт). Например, клиент может использовать Azure Backup для создания реплик файлов с образами виртуальных машин (VHD). Однако при восстановлении VHD архивный файл образа просто воссоздается в локальном хранилище, но соответствующий виртуальный сервер не перезапускается.
При использовании Azure Backup оплачивается только потребляемый в месяц объем хранилища. Дополнительная плата за восстановление не взимается. Ценовая модель хранилища зависит от варианта избыточности. В настоящее время Azure предлагает два таких варианта: локально избыточное хранилище (LRS), которое является наименее дорогим и реплицирует данные три раза в центре обработки данных Azure и геоизбыточное хранилище (GRS), которое реплицирует данные в дополнительный регион географически далеко от основного региона.
Резервное копирование в Google Cloud Storage
Компания Google предлагает различные уровни Cloud Storage в зависимости от класса хранимых данных, например хранилище для файлов постоянной доступности, блочное хранилище для образов виртуальных машин или объектное хранилище для видео. Она не предлагает специальные службы резервного копирования для этих уровней, хотя службы хранения данных, безусловно, могут использоваться и используются для резервного копирования и восстановления. Более того, компания Google считает, что резервное копирование — одна из основных причин для инвестиций крупных предприятий в облачные хранилища больших объемов.
![Рис. 4: содержимое группы в Google Cloud Storage. [предоставлено Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
Рис. 4. Содержимое контейнера Google Cloud Storage. [Предоставлено Google]
Так же как и в случае с AWS, Google называет свои контейнеры общего назначения группами. На рис. 4 показан один из шагов процесса импорта данных из локального хранилища в группу Google Cloud Storage (GCS). Так же как и модель доставки Azure, платформа GCS строится на трех ключевых параметрах:
производительность, которая в этом контексте является синонимом доступности (как быстро серверы будут отвечать на запросы чтения данных от клиентов);
срок хранения, который и в этом случае означает ожидаемую длительность хранения данных в облаке клиентом;
схемы доступа, которые связаны с доступностью (как часто клиент будет считывать или извлекать сохраненные данные).
При инициализации группы клиент GCS выбирает класс хранения, который определяет политику репликации. От этого будет зависеть то, насколько широко будут распределяться хранимые данные, когда группа начнет использоваться для хранения резервных копий. В настоящее время GCS предлагает три варианта географического расположения:
региональный — данные хранятся только в одном регионе территории обслуживания Google;
в двух регионах — данные реплицируются между двумя территориями обслуживания;
многорегиональный — данные распределяются избыточно между несколькими территориями обслуживания.
Классы хранения групп GCS далее делятся на подклассы в соответствии с частотой обращения:
Standard/High Availability — данные, которые должны быть мгновенно доступны для приложений и пользователей;
Coldline — позволяет клиентам вместо части ежемесячной платы за хранение платить за доступ к данным и их передачу; этот вариант предназначен для данных, доступ к которым требуется всего несколько раз в год;
Nearline — компромиссный вариант для данных, доступ к которым производится примерно раз в месяц.
Google позиционирует свою облачную инфраструктуру для предприятий как своего рода аппаратную систему, которая не видна клиентам. В связи с этим со стороны Google было бы лишним предлагать как саму инфраструктуру, так и отдельные службы на ее основе. Это все равно что продавать, например, печь, а затем подписку на возможность пользоваться ею в качестве дополнительного компонента.
Таким образом, клиентская организация GCS выбирает инфраструктуру, которая необходима для выполнения стоящих перед ней задач, и параметры этой инфраструктуры как функции устройства. (Как и AWS и Azure, Google предлагает устройство с стойким подключением для центров обработки данных для экспресс-назначения высокой скорости передачи между локальным и облачным хранилищем.) Эти функции могут быть изменены с течением времени в зависимости от способа использования этого хранилища. Например, предположим, что видеопроизводственной компании требовался большой объем хранилища резервных копий для версий монтируемого фильма. В процессе монтажа эти копии могут извлекаться довольно часто, поэтому клиент может выбрать хранилище класса Standard с размещением в одном регионе. Когда фильм будет готов, его копии могут все еще требоваться, пусть и нечасто, в течение следующего года. В этом случае группу можно перевести с уровня Standard на уровень Coldline с размещением на двух территориях в целях архивации и безопасности.
Ссылки
Amazon Web Services, Inc. Управление трафиком с помощью AWS Global Acceleratorhttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/.
Amazon Web Services, Inc. Обзор настройки репликацииhttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html.