Кибер Бэкап. Быстрый старт. Защита платформ виртуализации

Продолжаем рассказывать про то, как быстро и просто начать использовать нашу систему резервного копирования Кибер Бэкап.

В первой части мы обсудили, как развернуть Кибер Бэкап на ОС Linux и создать план резервного копирования. Сегодня поговорим о защите платформ виртуализации.

Введение

Один из самых важных вопросов об СРК: «А что она умеет защищать?» Мы разделяем защищаемое ПО на три класса:

• операционные системы,

• платформы виртуализации,

• приложения (СУБД, коммуникационное ПО и службы каталогов).

Кибер Бэкап поддерживает отечественные, зарубежные, проприетарные и свободно распространяемые системы. По полноте покрытия мы, пожалуй, в числе лидеров. Таким образом мы помогаем компаниям на всех этапах импортозамещения, защищая данные и в существующих системах, и в новых, на которые они переходят.

Поддержка отечественных систем реализуется в тесном сотрудничестве с нашими технологическими партнерами, которых у нас более 50. С частью из них у нас подписаны стратегические соглашения. Мы активно работаем с производителями как программного, так и аппаратного обеспечения.

Мы поддерживаем практически все популярные и востребованные на рынке платформы виртуализации — как зарубежные, так и отечественные. Список поддерживаемых платформ виртуализации растет — мы регулярно получаем заявки и от наших заказчиков, и от наших партнеров. На основе этих обращений мы формируем дорожную карту развития продукта. И да, мы помним про OpenNebula и Proxmox.

Мы умеем защищать платформы виртуализации как на уровне гипервизора, в т. н. безагентном режиме, так и с помощью агентов, устанавливаемых внутри гостевых ОС виртуальных машин. Защита на уровне гипервизора обладает рядом преимуществ (о них скажем ниже), а защита на уровне агентов позволяет нам поддерживать все платформы виртуализации, которые только есть на рынке.

Лицензирование у нас устроено так, что одной лицензии на хост виртуализации достаточно для защиты любого количества гостевых ВМ, которые работают под управлением этого хоста.

Чуть подробнее рассмотрим оба варианта защиты. Отдельно отметим, что эти данные имеют рекомендательный характер.

Резервное копирование на уровне гипервизора

Предпочтительно для работы с виртуальными машинами в общем случае, при следующих условиях:

• Размер ВМ не более 2 ТБ.

• Используется кластерное хранилище (datastore).

• Хранилище не перегружено по операциям ввода/вывода.

• Хранилище имеет много свободного места под снимки дисков.

• Достаточно ежедневной инкрементной копии ВМ.

• На хостах гипервизора есть ресурсы ЦПУ и ОЗУ под агенты Кибер Бэкапа.

• Есть быстрое хранилище для хранения резервных копий.

Резервное копирование агентом внутри ВМ

• Рекомендуется при резервном копировании «тяжелых» ВМ и ограничениях со стороны инфраструктуры, когда резервное копирование может выполняться долго или используются медленные хранилища для резервных копий.

• Размер ВМ более 2 ТБ.

• Хранилища гипервизора перегружены по вводу/выводу.

• Хранилища не имеют запаса свободного места под снимки ВМ.

• Необходимо частое (каждые 6 часов и чаще) создание инкрементной копии ВМ.

• На хостах гипервизора недостаточно ресурсов для развертывания агентов.

• Медленное хранилище для резервных копий или медленный канал подключения к этому хранилищу.

Далее посмотрим, как развернуть агент для платформы виртуализации zVirt (на базе oVirt).

Подготовка к развертыванию

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

Для начала нужно убедиться, что платформа zVirt поддерживается. Для этого открываем соответствующий раздел в документации Кибер Бэкапа и находим нужную нам платформу виртуализации.

Далее смотрим, какой агент нам потребуется. Для этого обращаемся к разделу Компоненты. Там показано, какой агент требуется для защиты платформы виртуализации и куда его установить.

В нашем примере нам потребуется агент для oVirt, который будем устанавливать на хост oVirt.

Теперь смотрим, каким образом этот агент развертывается — это описано в разделе Развертывание агента для oVirt.

Обратите внимание, что поддерживается два варианта развертывания: автоматический и ручной. В автоматическом режиме все действия выполняются прямо из консоли Кибер Бэкапа — именно так мы и поступим. Развертывание вручную предполагает, что мы берем OVA‑шаблон и развертываем его как новую виртуальную машину.

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

Для работы нам будет достаточно порта 443, по которому агент будет связываться непосредственно с гипервизором и передавать ему команды. Получается, что источником команд всегда будет агент. Агент — это некое виртуальное устройство (virtual appliance) в виде виртуальной машины, которая и будет находиться внутри гипервизора, общаться с ним по API и выполнять резервное копирование через снимки ВМ (об этом расскажем ниже).

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

Следующий шаг — загрузка агента для oVirt.

Загрузка и установка агента

Для начала нам потребуется дистрибутив агента, потому что до этого мы только развернули наш сервер управления. Мы не сможем развернуть агент, так как его пока еще нет в репозитории сервера управления. На странице продукта нажимаем кнопку Пробная версия.

Заполняем форму и нажимаем кнопку Получить пробную версию. На странице загрузки выбираем Пакет установки агента для oVirt.

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

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

Если сервер управления развернут на ОС Windows:

C:\ProgramData\Acronis\VaDeployer\va-images

Если сервер управления развернут на ОС Linux:

/var/lib/Acronis/VaDeployer/va-images

Из этой папки агент и будет передаваться на гипервизор.

Обратите внимание, что в этой папке может находиться только один пакет установки для oVirt. Почему это важно знать? Например, если мы сейчас обновим сервер управления до следующей версии, то пакет установки для oVirt останется прежний. Если в следующий раз уже на новом, обновленном, сервере управления мы будем развертывать этот агент, то развернется у нас старый агент, который лежал в данной папке. Поэтому обновлять его нужно вручную, после обновления сервера управления. В будущих релизах мы автоматизируем этот процесс.

После того как пакет с агентом перемещен в нужную папку, заходим в консоль сервера управления.

• Открываем раздел Устройства > Все устройства.

• Нажимаем кнопку Добавить.

• В окне Добавить устройства в разделе Хосты виртуализации выбираем zVirt.

В открывшемся окне указываем параметры сервера:

• имя или IP‑адрес сервера zVirt,

• имя пользователя и пароль доступа к серверу виртуализации,

• доменное имя или IP‑адрес сервера управления Кибер Бэкапа.

Если мы нажмем кнопку Развернуть, начнется автоматическое развертывание агента. Если же нажать кнопку Параметры, откроется панель, где можно посмотреть, сколько у нас узлов, сколько агентов развертывается и т. п. Здесь же мы можем присвоить нашему агенту (виртуальному устройству) имя, выбрать кластер, домен и сеть, с которыми будет взаимодействовать виртуальное устройство. В общем случае можно оставить все параметры, кроме имени агента, со значениями по умолчанию, а настройки получать через DHCP‑сервер.

Нажимаем кнопку Развернуть. Начинается процесс передачи данных на платформу виртуализации. По окончании передачи создается виртуальная машина и ее диск.

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

Также здесь есть кнопки Turn Off и Reboot, которые выключают и перезагружают наше виртуальное устройство.

Ресурсы виртуального устройства

Обратите внимание, что по умолчанию виртуальному устройству выделено 4 ГБ оперативной памяти. Это минимальный набор.

Если мы говорим про многопоточную работу, про 4, 6, 8, 10 потоков параллельного резервного копирования ВМ, то необходимо увеличить оперативную память. Исходите из расчета 1 ГБ оперативной памяти на каждый терабайт диска виртуальной машины.

Например, одновременно выполняется резервное копирование 10 машин. У каждой из них все диски на 4 ТБ. Получается 40 ТБ, значит нужно выделить 40 ГБ оперативной памяти для работы нашего агента. Если оперативной памяти будет не хватать, то скорость операций будет падать. Если будет сильно не хватать, это может повлиять на некоторые процессы, вплоть до отказа одного из заданий.

Лицензирование

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

Допустим, в кластере 10 хостов виртуализации, а у нас 9 лицензий. В итоге мы ничего не сможем лицензировать, никакие задания резервного копирования выполняться не будут в принципе. Эти лицензии даже не применятся ни на один хост, потому что они либо применяются на весь кластер сразу, либо не применяются совсем. Отдельно отметим, что хосты виртуализации, которые не входят в кластер, можно лицензировать по одному. В базе знаний у нас есть отдельная статья про то, какие лицензии у нас используются для определенных систем виртуализации.

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

Резервное копирование

Создание плана защиты для платформ виртуализации в общих чертах не отличается от создания плана для других объектов защиты. В этом заключается одно из основных преимуществ использования СРК Кибер Бэкап: по мере добавления инфраструктурного ПО и данных вы продолжаете использовать уже знакомые элементы защиты. Но, как говорится, «дьявол кроется в деталях».

Создадим простой план резервного копирования:

• Выбор данных: вся машина.

• Место сохранения: узел хранения.

• Расписание: выключено.

  • По умолчанию используется схема Всегда инкрементное.

• Срок хранения: неограниченное время.

Примечание. При выборе схемы Всегда инкрементное только один раз создается полная копия, все остальные копии будут инкрементными. Длина цепочки резервных копий ограничивается сроком хранения. Используемый в Кибер Бэкапе формат архива Archive 3 позволяет очень быстро создавать инкрементные копии и так же очень быстро их восстанавливать. Определенный набор метаданных позволяет восстановить всю цепочку копий за один проход. Подробнее о формате архива см. в нашей статье на Хабре.

Поддержка технологии Changed Block Tracking

Самое интересное скрыто в настройках плана резервного копирования. Именно здесь для платформ виртуализации на базе oVirt мы можем включить поддержку технологии Changed Block Tracking (CBT), что позволит ускорить создание инкрементных резервных копий. Поддержка CBT для платформ на базе oVirt появилась в Кибер Бэкапе 17.1.

Говоря простым языком, если опция Использовать CBT включена, перед началом резервного копирования агент будет запрашивать у гипервизора изменения для конкретной виртуальной машины и в процессе формирования резервной копии будет анализировать только эти данные. Когда опция отключена, агент будет анализировать весь диск. По нашим тестам, скорость создания инкрементных резервных копий при использовании CBT увеличивается в 4–8 раз.

Для поддержки резервного копирования с использованием технологии CBT нам необходимо указать у дисков виртуальной машины специальную опцию. Это можно сделать в консоли управления zVirt. Выбираем виртуальную машину, заходим в раздел Диски, нажимаем Изменить и активируем опцию Включить инкрементное резервное копирование.

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

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

Резервное копирование и восстановление тегов

Еще одной новинкой в Кибер Бэкапе 17.1 стала поддержка резервного копирования и восстановления тегов и меток виртуальных машин. Это освобождает администратора от ручной настройки свойств ВМ после восстановления. В настоящий момент резервное копирование и восстановление тегов и меток поддерживается для oVirt 4.5 и выше, zVirt 4.1 и выше, zVirt Max, ROSA Virtualization 2.1 и выше.

Дальнейшее развитие поддержки oVirt

У нас обширные планы по развитию поддержки платформы oVirt и систем на ее основе. Защита на уровне гипервизора была реализована уже довольно давно. Как мы уже отметили выше, в Кибер Бэкапе 17.1 мы представили отслеживание изменений в блоках (Changed Block Tracking) и резервное копирование тегов и атрибутов, что приближает возможности защиты систем на базе oVirt к возможностям защиты VMware.

Мы смотрим в сторону управления планами защиты на основе тегов, которые назначены на виртуальную машину. Пока еще мы не можем создавать планы на основе тегов, а можем только делать их резервные копии и восстанавливать значения тегов. Но в одном из следующих релизов мы представим функциональность по управлению резервным копированием с помощью тегов как на VMware, так и на oVirt.

Также в планах у нас реализация мгновенного восстановления, но пока сложно сказать, когда это будет. А еще мы сейчас работаем над реализацией возможности резервного копирования без использования локальной сети (LAN‑free). Тут выделим отдельный вектор взаимодействия на уровне технологического партнерства с такой известной компанией, как Yadro: мы планируем реализовать поддержку аппаратных моментальных снимков.

Миграция ВМ

Скажем несколько слов о различных вариантах восстановления и миграции, поддерживаемых Кибер Бэкапом. Сюда относится миграция физической машины в виртуальную (P2V), виртуальной в физическую (V2P), а также миграция ВМ с одной платформы виртуализации на другую, что может быть полезно в ряде сценариев импортозамещения.

Из всех доступных вариантов миграции в рамках сегодняшнего рассказа нам интересен сценарий миграции virtual to virtual (V2V), который позволит решить задачу смены платформы виртуализации. Этот сценарий можно описать так: миграция ВМ через создание ее резервной копии и последующее восстановление на платформе, отличной от исходной. Подробнее о миграции ВМ можно прочитать в статье на Хабре.

На что нужно обращать внимание при миграции виртуальных машин?

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

• Совместимость на уровне гостевых операционных систем. Если гостевая операционная система виртуальной машины не поддерживается новой платформой, то миграция может быть затруднена или вовсе невозможна. Перед миграцией необходимо убедиться, что операционная система будет работать на новой платформе.

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

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

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

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

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

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

Резервный четверг. Руководство по быстрому старту

В августе этого года в рамках уже традиционного «Резервного четверга» мы запустили серию вебинаров «Руководство по быстрому старту», которые состоят из непродолжительной теоретической части и подробной демонстрации.

Первый вебинар был посвящен вопросам развертывания Кибер Бэкапа на ОС Linux. Мы рассмотрели следующие темы:

• Ключевые возможности СРК Кибер Бэкап.

• Защита операционных систем семейства Linux.

• Подготовка ИТ‑системы к развертыванию Кибер Бэкапа.

• Развертывание и настройка системы резервного копирования.

• Активация пробной версии продукта.

• Создание плана резервного копирования.

Рекомендуем это мероприятие всем, кто интересуется возможностями Кибер Бэкапа и планирует проверить их на практике. Запись вебинара и демо доступна на странице мероприятия.

Второе мероприятие было посвящено защите платформ виртуализации. Обсудили темы:

• Защита платформ виртуализации.

• Отличия резервного копирования на уровне гипервизора и с помощью агентов внутри ВМ.

• Поддержка платформ на базе oVirt (zVirt).

• Принцип работы и преимущества использования технологии Changed Block Tracking.

• Миграция ВМ с платформы на платформу (V2V).

• Новые возможности по защите виртуализации в Кибер Бэкапе 17.1 и планы на будущее.

Информация будет полезна тем, кто хочет узнать больше о защите платформ виртуализации с помощью Кибер Бэкапа. Запись вебинара и демо есть на странице мероприятия.

Мы планируем продолжать мероприятия из серии «Руководство по быстрому старту». Следите за анонсами на нашем сайте.

Если есть какие‑то темы, например хранилища или работа с ленточными устройствами, защита СУБД и т. п., которые вы хотели бы услышать на наших будущих вебинарах, пожалуйста, напишите в комментариях.

Спасибо и до новых встреч!