Так с агентом или без?

Привет, Хабр! Сегодня я хочу рассказать о том, как решаются вопросы резервного копирования в случаях работы с агентами или без них. В этом посте мы обсудим, какие преимущества даёт безагентная СРК (на примере Кибер Бэкап), поговорим о том, как она работает, а также рассмотрим ситуации, когда Илюха Курякин (см. «Агенты А.Н. К.Л.») всё-таки нужен.

afb8e1a5caa27969f1e0848864ad7e20.jpeg

Когда СРК защищает отдельно взятый компьютер, всё работает достаточно просто — специальная служба следит за изменениями вашей файловой системы и согласно заданным правилам создает резервные копии в выбранном месте. Резервные копии могут передаваться по локальной сети или в облако, сохраняются на внешние накопители, а также в сетевые СХД и программно-определяемые хранилища (например, в Кибер Инфраструктуру — и эта тема заслуживает отдельного поста), в том числе и по схеме 3–2–1. В подобных случаях никакого дополнительного агента не требуется — все компоненты устанавливаются вместе и работают как единый комплекс ПО.

Но при развертывании системы резервного копирования в организации, где необходимо защитить десятки (а может и сотни) физических и виртуальных серверов и рабочих станций, обычно на каждый защищаемый объект устанавливается агент, который отвечает за выполнение задач резервного копирования. Агенты могут работать в различных режимах, создавать локальные или сетевые резервные копии. Управление агентами происходит из центральной консоли Кибер Бэкап. 

97823d77faa1deeec75bc76a0e962bbf.png

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

Схема без агентов

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

Это становится возможным за счет использования API гипервизоров, через которые сервер резервного копирования может передавать команды/задачи. 

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

  1. Кибер Бэкап посылает запрос на создание моментального снимка ВМ;  

  2. Гипервизор создает снапшот и передаёт путь к нему Кибер Бэкапу;

  3. Кибер Бэкап перерабатывает получившийся файл в резервную копию формата Кибер Бэкап (или ее инкрементное обновление) и помещает в хранилище резервных копий.

Восстановление происходит по той же простой схеме. . Например, если требуется восстановление ВМ целиком, выполняются следующие шаги:

  1. Кибер Бэкап получает запрос на восстановление определённой ВМ от администратора;

  2. Кибер Бэкап копирует образ ВМ на нужный носитель;

  3. Кибер Бэкап даёт гипервизору команду создать новую ВМ из образа.

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

6a7a6b2ace089e565f2bbc66bd3e8d07.png

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

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

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

Разгружает админов — не требуется настройка для каждой отдельно взятой виртуальной машины. Можно обеспечить защиту всего кластера с заданными параметрами RTO и RPO — для этого нужно просто установить единые политики резервного копирования и аварийного восстановления. Настройки будут актуальны как для существующих, так и для новых виртуальных машин.

Что же делать агенту?

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

Помимо этого, агенты бывают полезны и в системах виртуализации. Агентный бэкап позволяет особенно тщательно защищать наиболее критичные ресурсы в кластере — об этом рассказывали на Хабре коллеги, которые активно используют Кибер Бэкап в своих проектах.,  

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

Режимы с агентом (agent-based) и без него (agent-less) часто комбинируют, когда снимок ВМ выполняется один  раз в день, а агент внутри машины создает  резервную копию важных данных (например, данных приложений 1С) раз в час, причем в режиме файлов.


Для Кибер Бэкап такая схема является совершенно нормальной. Её настройка и управление происходит из той же самой консоли. 

8e1aef6dbbe0abf8ab4099aacd0ad278.png

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

Поддержка гипервизоров

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

Проекты интеграции с гипервизорами идут долго и требуют глубокого погружения. Мы уже рассказывали, с какими сложностями пришлось столкнуться при включении безагентного резервного копирования для платформы ECP Veil. Однако, судя по отзывам заказчиков, такая возможность оказывается действительно востребованной, и сейчас мы поддерживаем безагентный бэкап для таких гипервизоров, как Кибер Инфраструктура, ECP VeiL, zVirt, ROSA Virtualization, РЕД Виртуализация, Hyper-V, VMware, и ряда других.

© Habrahabr.ru