Не клади все данные в одно облако

При выборе облака для размещения сервисов и приложений обычно изучают доступную информацию о том, как устроена инфраструктура провайдера. Дублированные вводы питания и сеть, дизель-генераторы, SLA с множеством девяток, надёжные СХД, сертификаты Uptime Institute – всё это успокаивает при оценке рисков. Это впечатление во многом справедливо: облачные провайдеры обычно уделяют много внимания надёжности ЦОДов. Но надёжность площадки и сохранность данных клиента – не одно и то же. В облаке ответственность разделена: провайдер отвечает за доступность платформы, а защита приложений и аварийное восстановление (DR) остаются за клиентом. Риски при этом те же, что на собственной площадке: отказы оборудования, вредоносное ПО, ошибки администраторов. Компенсация по публичному SLA провайдера, как правило, ограничена стоимостью услуги и не покрывает потери от простоя сервиса и утраты данных.

Резервное копирование средствами провайдера защищает от многих проблем, но не от всех: копии хранятся в том же облаке, что и основные данные, и могут оказаться с ними в одном домене отказа. Домен отказа – это набор ресурсов, которые выходят из строя одновременно из-за одного события. В облаке таким доменом может оказаться не стойка и не машинный зал, а целый ЦОД, облако провайдера или один клиентский аккаунт. Если основные данные и копии находятся в одном домене отказа, одно событие затрагивает их одновременно.

Вопрос в том, где хранится резервная копия: внутри облака провайдера или за его пределами?

В этой статье разберём основные риски по зонам ответственности, посмотрим и сравним три способа хранить резервную копию и организовать аварийное восстановление вне облака, на своей инфраструктуре.

Какие риски остаются на стороне клиента вне зоны ответственности провайдера

Риски разделим по зонам ответственности: часть возникает на стороне клиента, часть – на стороне инфраструктуры провайдера. Сначала разберём каждый из них, затем сведём их в таблицу и отметим, какие варианты хранения копий от них защищают.

Ошибки конфигурации. В мае 2024 года из-за ошибки сотрудников Google Cloud была удалена облачная подписка пенсионного фонда UniSuper, включая копии в двух регионах. Фонд, в котором более 640 тысяч участников, восстанавливал работу сервисов около двух недель. Данные удалось восстановить только благодаря резервным копиям, которые хранились в другом облаке.

Однотипное оборудование. В системах хранения часто используются накопители из одной партии и одной версии прошивки. Дефект, общий для партии, проявляется у многих устройств одновременно: в 2019 году HPE выпустила бюллетень о сбое прошивки ряда SAS SSD после 32 768 часов работы. Механизмы отказоустойчивости (RAID, репликация) рассчитаны на независимые отказы, и от одновременного отказа они защищают не всегда. Пока копия лежит на таком же оборудовании, она делит риск с основными данными. Если основная и резервная СХД собраны на однотипных накопителях и введены в эксплуатацию одновременно, то подобный дефект может уничтожить обе копии сразу.

Изъятие оборудования. Когда правоохранительные органы изымают серверы провайдера, страдают и клиенты, которые к делу никакого отношения не имеют. Известны случаи, когда изымали сотни серверов (Хабр). При изъятии оборудования клиент может разом лишиться доступа и к основным данным, и к резервным копиям, если те хранятся у того же провайдера.

Организационные причины. Изменение условий договора, приостановка доступа по требованиям регуляторов, уход провайдера с рынка. Инфраструктура остаётся исправной, но доступ к ней ограничен на время или насовсем. Доступ к копиям в той же учётной записи ограничивается вместе с доступом к основным данным. Такие риски реализовались весной 2022 года у клиентов, которые пользовались услугами облачных провайдеров прекративших работу на территории РФ.

Хакерские атаки

• Шифровальщик внутри ВМ.

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

• Взлом самого провайдера: через инсайдера или уязвимость в платформе.

Копия вне облачной учётной записи остаётся доступной, даже если клиентская учётная запись скомпрометирована.

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

У всех этих случаев общая черта: основные данные и копии находились в одном домене отказа – на однотипном оборудовании, под управлением одного провайдера или в одном аккаунте. Одно событие затрагивает их одновременно. Снизить такие риски можно, только вынеся копию за пределы этого домена отказа – к другому провайдеру или на свою инфраструктуру.

Как хранить копии и организовать DR вне облака провайдера

Для защиты приложений и сервисов за пределы облака провайдера рассмотрим три наиболее известных, на наш взгляд, способа защиты: встроенные средства резервного копирования самих приложений; внешняя система резервного копирования (СРК), развёрнутая на резервной площадке; гостевая репликация с помощью агента внутри облачной ВМ. Разберём сильные и слабые стороны каждого.

Способ 1. Средства резервного копирования на уровне приложения

Используются возможности самого приложения, работающего в облаке: встроенные механизмы создания резервных копий (дампы, журналы транзакций, штатные утилиты). Такие механизмы есть у всех популярных СУБД, поэтому подход применим практически к любой базе данных.

Плюсы:

• Консистентность. Копия гарантированно целостна на уровне приложения.

• Цена. Как правило, такой способ не требует покупки лицензий.

  Минусы:

• Ограниченная применимость. Не каждое приложение имеет встроенные инструменты для создания резервных копий или реплик без остановки.

• Не включает весь набор данных. Сделать копию облачной ВМ целиком таким способом нельзя. Настройки ОС и окружения приходится копировать отдельно. Часто только при аварийном восстановлении обнаруживается, что отсутствует какой-то важный файл конфигурации: о нём забыли, когда настраивали регулярное резервное копирование.

• Сложное аварийное восстановление. Восстановление нельзя выполнить, не имея глубокого понимания механики работы этого приложения. Шагов много, автоматизации почти нет: нужно восстановить данные из копии, настроить сеть, обеспечить правильный порядок запуска сервисов.

• Нет универсальности. Каждое приложение копируется и восстанавливается по-разному, разными инструментами со своими особенностями.

Примеры ПО со встроенными средствами резервного копирования: PostgreSQL, MySQL/MariaDB, Oracle Database, MS SQL Server, MongoDB, ClickHouse, GitLab (gitlab-backup).

Способ 2. Внешняя СРК на резервной площадке
Публичное облако не даёт клиенту доступа к гипервизору, поэтому безагентное копирование через API гипервизора здесь недоступно. Внешней СРК остаётся агентский способ: в каждую облачную ВМ устанавливается агент резервного копирования, который копирует:

1. прикладное ПО – через модули интеграции;

2. все данные на дисках ВМ – блочным способом, с возможностью восстановления ВМ на другую платформу (так умеют не все СРК).

   

Плюсы:

• Консистентность. Модули интеграции с прикладным ПО позволяют получать консистентные копии приложений.

• Включает полный набор данных. Некоторые СРК умеют агентским способом делать полные копии ВМ, включая данные ОС, которые можно восстановить на другой платформе (Veeam, Кибер Бэкап).

• Централизация. Если резервные копии делаются уже развёрнутой на своей площадке СРК, то получаем единую точку управления и мониторинга резервного копирования собственной инфраструктуры и части, вынесенной в облако.

  Минусы:

• Нет автоматизации восстановления. При аварии данные восстанавливаются из бэкапа, сетевые параметры перенастраиваются вручную, сервисы вручную запускаются в правильном порядке.

• Время восстановления. Процесс восстановления данных (копирования из хранилища резервных копий) сам по себе может занимать часы, а если нужно восстановить одновременно много объектов инфраструктуры – дни.

Примеры ПО: Veeam Backup & Replication, Кибер Бэкап, RuBackup, NetBackup, Commvault и другие.

Способ 3. Аварийное восстановление с гостевой репликацией
В качестве примера решения для автоматизированного аварийного восстановления с агентской репликацией возьмём MIND Guard #guest.

Исходная ВМ работает в публичном облаке, а резервная ВМ находится на инфраструктуре клиента или в другом облаке. На резервной площадке разворачивается контроллер (специальная ВМ для управления), через который настраивается репликация из облака. В исходную ВМ устанавливается агент MIND Guard. Он делает моментальные снимки дисков ВМ и отправляет их по сети на резервную площадку, поддерживая постоянно актуальную копию. Из облака через интернет передаются изменения с момента последней синхронизации, поэтому объём трафика равен объёму изменившихся данных.

Плюсы:

• Консистентность. Благодаря снапшотам копия данных ВМ как минимум crash-consistent. Используя возможности запуска пользовательских скриптов до и после снятия снапшота, можно получить application-consistent копию.

• Включает полный набор данных. Реплика содержит полную копию всех дисков облачной ВМ.

• Универсальность. Таким методом можно реализовать аварийное восстановление любых приложений. Единообразие подхода важно для средних и крупных инфраструктур.

• Автоматизация восстановления. Переключение на резервную площадку, настройка сетевых параметров резервных машин и запуск ВМ в правильном порядке с учётом зависимостей автоматизируются с помощью планов аварийного восстановления. Достаточно запустить план – дальше всё происходит без ручных операций.

• Время переключения. Резервная инфраструктура – это асинхронные реплики защищаемых ВМ, готовые к запуску. Во время аварийного восстановления не нужно копировать большие объёмы данных, как это происходит при восстановлении из резервной копии. Достижимое время восстановления сокращается до минут.

• Тестовое переключение без влияния на источник. Резервную ВМ можно запустить в тестовом режиме и убедиться, что репликация работает как ожидается, не дожидаясь аварии.

• Обратное переключение (failback). После восстановления работоспособности инфраструктуры публичного облака репликацию можно развернуть в обратном направлении и вернуть нагрузку.

• Точки восстановления. На приёмнике хранится до 12 точек – состояний ВМ на разные моменты времени. Если на источнике случилась логическая ошибка (повреждение или удаление данных, атака шифровальщика) и она уже успела реплицироваться, приёмник можно откатить к точке до инцидента и переключиться на неё.

• Контроль RPO. В веб-интерфейсе контроллера видны реальный и целевой RPO. Можно настроить уведомления при превышении RPO (например, если изменения перестали успевать передаваться по сети на приёмник).
  Минусы:

• Нужны постоянно работающие ВМ на резервной площадке, которые принимают изменения с источников. Это плата за быстрое аварийное восстановление.

• Зависимость от драйверов. Агенту нужны драйверы под конкретный дистрибутив и версию ядра. Обновить ОС можно только после того, как производитель выпустит под неё новые драйверы.

Вывод:
Облачный провайдер отвечает за то, чтобы ВМ работала и была доступна по сети, а сохранность данных и восстановление после аварии остаются за клиентом. Копии внутри того же облака закрывают часть рисков, но не те, при которых основные данные и копии оказываются в одном домене отказа: ошибки на стороне провайдера, изъятие оборудования, блокировку или взлом аккаунта. Поэтому хотя бы одна копия должна храниться за пределами облака провайдера – на своей инфраструктуре или в облаке другого провайдера.

Самый простой способ получить такую копию – средства резервного копирования самих приложений. Как правило, они не требуют лицензий и дают консистентную копию, но не захватывают ОС и окружение, а восстановление сложное и требует ручной работы.

Внешняя СРК копирует облачные ВМ агентским способом и даёт единую точку управления для всей инфраструктуры. Но аварийное восстановление на другую площадку по-прежнему выполняется вручную и может занимать часы, а при массовой аварии – дни.

Гостевая репликация при помощи MIND Guard держит на резервной площадке готовые к запуску реплики ВМ, а переключение выполняется по плану аварийного восстановления. Время восстановления сокращается до минут, но на резервной площадке нужны постоянно работающие ВМ-приёмники. Для одной-двух ВМ или отдельных баз данных чаще всего достаточно средств приложения или СРК. Если в облаке много связанных ВМ или приоритетна скорость восстановления, то лучше подойдёт MIND Guard.