Veeam for Azure

by Опубликовано


В конце апреля стал доступен новый продукт Veeam для Microsoft Azure. Если быть честным — это полноценный близнец другого продукта, вышедшего в конце 2019 года — Veeam для Amazon Web Services. Схожесть этих продуктов помогает легко работать с Veeam в публичном облаке, независимо от того Azure это или AWS. А я в очередной раз хочу напомнить — какой бы надёжной не была инфраструктура, сколько бы девяток не обещал провайдер — бекап делать всё равно нужно. Взломы, вирусы-шифровальщики, сбои в работе сервисов — всё это может привести к потере данных, при том что с точки зрения инфраструктуры всё будет работать корректно.

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

Но в целом задача развёртывания не представляет собой каких-то сложностей, нужно по шагам выполнить настройку следующих вещей:

  1. Развернуть Veeam для Microsoft Azure.
  2. Добавить в Veeam свой аккаунт Microsoft Azure.
  3. Сконфигурировать среду резервного копирования:
    1. Репозиторий
    2. Воркеры
  4. Настроить политику резервного копирования
  5. Profit!

И так, начнём по порядку.
На сегодняшний день в Azure поддерживается 2 вида лицензий:

  • Free License, аналог Community Edition на 10 инстансов
  • BYOL (Bring You Own License) License

А вот обычной Paid Edition, как в AWS, в Azure нет.

В документации есть прекрасная статья о том, как развернуть Veeam Backup из маркетплейса, с картинками и уточняющими ссылками на портал Microsoft — Installing Veeam Backup for Microsoft Azure. Теперь остаётся зайти в интерфейс Veeam Backup добавить свой сервисный аккаунт Azure и аккаунт репозитория (это одно из специфичных отличий между Veeam for Azure и Veeam for AWS, которому не нужна дополнительная учётная запись). Далее нам необходимо добавить репозиторий (который по аналогии с AWS может быть только облачным хранилищем Azure — Azure blob storage) и добавить воркеры. Воркеры — это некие аналоги привычных нам прокси, использующихся в классическом VBR, которые и отвечают за передачу данных. Следует учитывать несколько особенностей воркеров:

  1. Каждый воркер одномоментно обрабатывает только одну виртуальную машину. Воркеры могут разворачиваться в автоматическом режиме сервером управления. Количество разворачиваемых воркеров можно установить в разделе Number of workers instances, ограничив их минимальным и максимальным значением.
  2. Каждый воркер имеет время простоя не более 10 минут, после чего будет автоматически удалён сервером управления.

Если опустить конфигурирование дополнительных параметров, то можно сразу перейти к созданию политики РК. Этих базовых настроек достаточно для того, чтобы начать резервное копирование ваших виртуальных машин в облаке Azure.
Теперь же давайте разберёмся — как именно это работает.

Когда вы запускаете свою политику резервного копирования, происходит следующее:

  1. Извлекается конфигурация и виртуальные диски каждой виртуальной машины в политике
  2. Создаются снепшоты и бекапы виртуальных дисков по следующей схеме:
    1. Снимки управляемых виртуальных жестких дисков сохраняются в группе ресурсов исходной виртуальной машины, а конфигурация каждой виртуальной машины сохраняется в базе данных конфигурации Veeam Backup for Microsoft Azure.
    2. Снимки неуправляемых виртуальных жестких дисков сохраняются в учетной записи хранения исходного неуправляемого виртуального жесткого диска, а конфигурация каждой виртуальной машины сохраняется в базе данных конфигурации Veeam Backup for Microsoft Azure.
    3. Резервные копии как управляемых, так и неуправляемых виртуальных жестких дисков сохраняются в хранилище резервных копий (Azure Blob storage). Данные шифруются и сжимаются.

Снепшоты виртуальной машины могут быть двух видов:

  • cloud-native
  • image-level

Данная настройка выбирается при создании политики РК, если вы выбрали Create snapshots, то это будет cloud-native, если Enable backups, то это image-level.
Если вы настроили политику резервного копирования для создания image-level резервных копий, каждый сеанс резервного копирования будет создавать новую резервную копию. Последовательность резервных копий, созданных во время набора сеансов резервного копирования, составляет цепочку резервного копирования, так же как и в классическом VBR. Поддерживается 2 вида резервных копий:

  • Full backups
  • Incremental backups

Если вы настроили политику резервного копирования для создания cloud-native резервных копий, каждый сеанс резервного копирования будет создавать новый снимок для каждой виртуальной машины Microsoft Azure, добавленной в политику резервного копирования. Это обычный снепшот виртуальный машины, который привязан к ней. Для их создания используются собственные возможности Microsoft Azure.

И ещё один важный момент, который нам осталось затронуть — политики хранения, т.е. ретеншн. Есть 3 типа:

  • Snapshot-based — удаляет все точки восстановления (моментальные снимки) в цепочке резервных копий, которые превышают указанный порог хранения.
  • Repository-based — удаляет все точки восстановления (резервные копии) в цепочке резервных копий, которые старше указанного периода хранения.
  • Obsolete snapshot — глобальная настройка, которая применяется к двум видам объектов: снепшоты ВМ и сессии РК, произведённые Veeam из конфигурационной БД, чтобы не увеличивать её размер.

В общем, если по простому — Snapshot-based применяется к cloud-native, Repository-based применяется к image-level.

Теперь что касается восстановления — есть 3 варианта:

  • Восстановление VM
  • Восстановление диска
  • Восстановление отдельных файлов (из ВМ)

И ещё из полезного — Auto-Backup, это возможность настроить резервное копирование самого сервера Veeam. По факту для неё по расписанию будут делаться cloud-native снепшоты.
Также как и в Veeam для AWS, при создании политики РК у вас есть возможность оценить стоимость услуг

Когда мы платим в облаке за каждое движение, такая статистика нам будет крайне полезной. Ну и возможность практически на каждом экране экспортировать данные в Excel/XML тоже может быть полезным.

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

  1. Это конечно же Veeam Explorer’s для гранулярного восстановления данных на уровне приложений.
  2. Интеграция с консолью VBR, для удобного администрирования одновременно on-premise и cloud инфраструктуры.
  3. Возможность хранения резервных копий где-то вне облака. Допустим вы хотели бы хранить какие-то резервные/архивные копии у себя on-prem или воспользоваться другим поставщиком S3 (например, Backblaze теперь поддерживает протокол S3 и предоставляет более дешёвое хранение, нежели AWS/Azure).
  4. Возможность запуска облачных ВМ на собственной инфраструктуре VMware/Hyper-V. Сегодня в VBR уже есть возможность восстановить ваши VMware/Hyper-V VM в Azure или AWS, но могут быть кейсы и в обратную сторону (да, я в том числе намекаю и на блокировку части ресурсов AWS нашим Роскомнадзором в борьбе с Telegram) когда вам потребуется запустить облачные ресурсы на вашей площадке и/или на площадке другого провайдера. Кейс возможно не самый актуальный, но почему бы не дать заказчикам возможность выбора?
 
Помеченные

Опубликовано KorP

Добавить комментарий