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

В статье рассмотрим, как использование аппаратных моментальных снимков СХД TATLIN.UNIFIED в Кибер Бэкапе 18 снижает влияние резервного копирования на производительность хоста виртуализации VMware и позволяет устранить риски деградации информационных систем.

Как бороться с перегрузкой хоста виртуализации

Чтобы исключить скачки потребления ресурсов, применяются различные подходы:

• Планирование задач. Ограничение количества одновременных заданий и их распределение по времени для избежания пиковых нагрузок. В Кибер Бэкапе это можно сделать с помощью параметра «Планирование» в настройках плана защиты — подробнее в документации.

• Безагентное копирование на уровне гипервизора. Использование Virtual Appliance (VA) исключает установку агентов на ВМ и снижает конкуренцию за ресурсы. Список платформ виртуализации, резервное копирование которых поддерживается на уровне гипервизора также есть в документации. 

• Использование функции Changed Block Tracking (CBT). Фоновая обработка измененных блоков данных позволяет сразу приступать к копированию, сокращая объем передаваемой информации и нагрузку на диски и сеть. 

• Включение режима Lan‑free. Передача данных резервного копирования через выделенную сеть хранения данных (SAN) разгружает основную сеть (LAN) и повышает безопасность. 

• Создание моментальных снимков, или снапшотов. Этот метод мы рассмотрим подробнее.

Типы моментальных снимков: программные vs аппаратные

Моментальные снимки делятся на два типа в зависимости от того, какой компонент инфраструктуры их создает:

• Программные снимки. Создаются гипервизором (например, VMware vSphere).

• Аппаратные снимки. Создаются системой хранения данных (СХД) по запрос��.

Программные снимки в VMware при резервном копировании

Вот порядок работы программных снимков:

1. Создание снимка. Кибер Бэкап инициирует создание согласованного снимка ВМ в VMware.

2. Согласованность данных. Для обеспечения целостности данных (особенно для таких приложений, как SQL Server) может использоваться функция «заморозки» (quiescing), которая временно приостанавливает все операции ввода‑вывода.

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

4. Очистка. После завершения копирования снимок удаляется.

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

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

Аппаратные снимки уровня СХД

Аппаратные снимки решают проблему производительности за счет кардинального сокращения времени жизни снимка уровня виртуализации. Процесс выглядит так:

1. Инициирование. Хост виртуализации создает программный снимок для обеспечения согласованности данных ВМ.

2. Создание снимка уровня СХД. СХД по команде агента создает аппаратны�� снимок всего тома/LUN с ВМ. Эта операция занимает секунды.

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

4. Копирование данных. Агент Кибер Бэкапа считывает данные для резервной копии непосредственно из аппаратного снимка СХД.

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

Больше про технические особенности снапшотов TATLIN.UNIFIED читайте в статье.

Поддержка СХД TATLIN.UNIFIED в Кибер Бэкап 18

До выхода 18-й версии СРК Кибер Бэкап в продукте подд��рживалось создание моментальных снимков оборудования SAN для зарубежных систем — NetApp и Huawei OceanStor (Dorado). В последние годы российские компании ищут отечественные аналоги, которые могли бы предоставить схожую функциональность. 

Особенно важно, чтобы продукты, заместившие зарубежные решения, могли интегрироваться между собой. Так, система резервного копирования должна поддерживать создание бэкапов как зарубежных, так и российских платформ виртуализации, платформа виртуализации — работать с отечественными СХД, а СРК — использовать аппаратные снапшоты этих СХД.

Кибер Бэкап 18 поддерживает создание аппаратных моментальных снимков для системы хранения данных TATLIN.UNIFIED. Это позволяет начинать выстраивать связку «платформа виртуализации — СХД — система резервного копирования» на отечественных решениях, при этом с сохранением ключевой функциональности для снижения нагрузки на инфраструктуру. 

Пример использования интеграции Кибер Бэкапа и TATLIN.UNIFIED

У нас развернут хост виртуализации, на нем — несколько виртуальных машин. Также есть отдельная ВМ с сервером управления Кибер Бэкапа. Агент для VMware развернут в виде виртуального устройства и выполняет резервное копирование на уровне гипервизора. В качестве хранилища данных ВМ используется СХД TATLIN.UNIFIED. Кроме этого, есть отдельный агент для VMware, развернутый на физическом сервере. 

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

При использовании агента резервного копирования, расположенного на физическом сервере и подключенного к СХД, мы выполняем следующие шаги.

Шаг 1. Сначала создадим моментальный снимок уровня гипервизора, который приводит диски виртуальных машин в консистентное состояние и замораживает это состояние на некоторый момент времени. Дальнейшая запись гипервизором будет проводиться в отдельные дельта‑файлы.

Шаг 2. Далее создаем аппаратный снимок LUN СХД, на которых собрано хранилище данных. Делаем клон этого снимка для дальнейшего использования агентом резервного копирования.Таким образом мы получаем независимый дисковый ресурс с копиями дисков виртуальных машин.

Если мы посмотрим на потребление ресурсов на хосте виртуализации, то оно остается таким же. Никаких всплесков, связанных с повышением потребления ресурсов, мы не увидим.

Шаг 3. Моментальные снимки уровня гипервизора нам больше не нужны — удаляем их. Таким образом мы сводим к минимуму время жизни программного моментального снимка. 

Шаг 4. Аппаратные снимки уровня СХД подключаем по SAN к ОС с установленным агентом КиберБэкап и выполняем с них резервное копирование. 

Как видно из графиков, весь трафик переходит на сервер с агентом резервного копирования.

Описанные выше шаги показаны на диаграмме:

Сценарий работы Кибер Бэкапа и TATLIN.UNIFIED мы подробно разобрали в видео. Там же указаны настройки, которые необходимо выполнить на уровне Кибер Бэкапа и СХД. 

Какие задачи решаются с помощью аппаратных снапшотов

Использование аппаратных моментальных снимков уровня СХД (в дополнение к программным) позволяет решить следующие задачи:

• Снизить нагрузку на хост виртуализации. Рабочие системы продолжают быть доступны для всех бизнес-процессов.

• Увеличить частоту создания резервных копий за счет снижения времени создания РК, а это сокращает показатель RPO.

• Уменьшить срок жизни моментальных снимков уровня виртуализации. Место на диске освобождается быстрее.

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

Технические ограничения текущей реализации

В Кибер Бэкапе 18 реализована первая версия поддержки аппаратных моментальных снимков уровня СХД для TATLIN.UNIFIED. В ней есть ряд ограничений:

• Поддерживается только протокол iSCSI.

• Многопутевой (multipath) доступ к моментальным снимкам не поддерживается.

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

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

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

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

• Количество виртуальных машин, для которых выполняется резервное копирование, не должно превышать 40.

• Число аппаратных моментальных снимков не должно превышать 40, если для одной виртуальной машины предполагается наличие нескольких аппаратных моментальных снимков.

Следующие ограничения приведены из расчета на одного агента для VMware (Windows) или на одновременное выполнение резервного копирования виртуальных машин:

• Количество виртуальных машин, для которых выполняется резервное копирование, не должно превышать 10.

• Число аппаратных моментальных снимков не должно превышать 10, если для одной виртуальной машины предполагается наличие нескольких аппаратных моментальных снимков.

Команды для работы с СХД отправляются по API с использованием учетной записи, которая входит в специальную группу «Бэкап на СХД» с ограниченным набором команд.

Заключение

Мы продолжим работать над развитием поддержки аппаратных снапшотов уровня СХД совместно с инженерами YADRO. В следующем году, помимо поддержки платформы виртуализации VMware, мы планируем реализовать аналогичную поддержку для платформы zVirt.