В настоящее время Veeam Backup & Replication v8 поддерживает аппаратные снапшоты на хранилищах HP и NetApp. В последнее время наc часто спрашивают — «а с какими еще хранилищами будут интегрироваться продукты Veeam?» В этой статье будет рассказано про интеграцию будущей версии Veeam Availability Suite v9, которая выйдет в этом году, с системами хранения данных корпорации EMC.

Поддержка будет включать сразу две линейки дисковых массивов EMC и многочисленные варианты их конфигурации. Поддерживаются как системы EMC VNX, так и VNXe. Будет доступно восстановление с помощью Veeam Explorer for Storage Snapshots, который входит во все редакции Veeam Backup & Replication, включая Free Edition) и резервное копирование с использованием аппаратных снимков.



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

Рассмотрим подробнее как всё устроено: Veeam Backup & Replication может просматривать аппаратные снимки VNX и VNXe. Снапшоты могут создаваться как по расписанию на массиве, так и через интерфейс Veeam Backup & Replication. Сразу после получения снимка вы сможете просматривать его содержимое и использовать эффективные опции восстановления.


Использование аппаратных снапшотов обеспечивает минимальные показатели RPO. Тем не менее, в случае аппаратного сбоя диска, снапшоты скорее всего «погибнут» вместе с данными, поэтому разумно делать резервную копию данных снапшотов и хранить ее в другом месте относительно оригинальных данных. В Veeam Backup для этой цели есть специальная опция: «Backup from Storage Snapshots».

Благодаря использованию аппаратных снимков можно создавать резервные копии в любое время даже на самых загруженных виртуальных машинах. Перед выполнением резервного копирования, виртуальную машину необходимо к этому подготовить, создав снапшот на уровне виртуальной машины средствами гипервизора VMware (это операция обеспечивает сброс на диск всех расположенных в памяти буферов данных, за счет чего обеспечивается целостность данных приложений в резервной копии). После этого создается уже аппаратный снапшот, а снимок VMware удаляется. Дальше интереснее. Veeam Backup Proxy переносит данные прямо из аппаратного снимка. Больше не потребуется вручную регистрировать VM или инициализировать ESXi datastore. Благодаря нашей запатентованной технологии доступна опция VMware CBT — а значит, что инкрементные копии можно создавать очень быстро. По окончании резервного копирования аппаратный снимок автоматически удаляется. На рисунке ниже представлены этапы резервного копирования с использованием аппаратных снапшотов.


Veeam Availability Suite v9 выйдет в этом году. Скорее всего будут доступны бета- и превью-версии, так что вы в числе первых сможете оценить интересные возможности новой версии. По ссылкам ниже вы можете найти дополнительную информацию:

Комментарии (2)


  1. ultral
    01.07.2015 19:31

    звучит интересно, но кмк, вы немного не договариваете или не могли прояснить:
    1) вы делаете снапшот средствами vmware, после чего делаете снапшот на хранилище… это понятно, но насколько я знаю операцию удаления снапшота vmware весьма ресурсоемкая, плюс по окончанию мерджа вм фризится от пары секунд до десятка. такая проблема присутсвует в вашем решение?
    2) если я захочу делать снапшоты каждые 5 минут, то насколько сильно это скажется на виртуальной машине?


    1. sysmetic Автор
      01.07.2015 23:47

      По п.1: обычный (без использования аппаратных снапшотов) бэкап выполняется примерно по следующему алгоритму:
      1) Инициируется VMware снапшот. Диск переводится гипервизором в read-only режим. Все изменения на диске начинают записываться в «дельта-файл».
      2) Начинается процесс копирования данных с диска в резервную копию (в общем случае) через сеть. Это не быстрый процесс. Все это время операции записи на исходный диск фактически производятся в дельта-файл.
      3) После заверешения копирования данных, дается команда на удаление снапшота. При этом выполняется запись всех данных дельта-файла на сам диск, который был все это время в read only режиме. На время этого процесса как раз и происходит фриз — чем больше получился дельта-файл, тем более заметен фриз.

      В случае же аппаратных снапшотов алгоритм работы другой:
      1) Такой же: инициируется VMware снапшот. Диск переводится гипервизором в read-only режим. Все изменения на диске начинают записываться в «дельта-файл».
      2) Инициируется аппаратный снапшот. А это, в отличие от п.2 в предыдущем варианте, быстрый процесс, так как он происходит локально на том же самом дисковом массиве с с оригинальными данными. На время этого процесса, все записи идут в дельта-файл. Дельта файл получается небольшим.
      3) Снапшот VMware удаляется. Данные небольшого дельта-файла быстро записываются в основной диск. Дальнейшая работа по копированию данных идет уже с использованием аппаратного снапшота, и без участия виртуальной машины.

      Из-за разницы в алгоритмах получается, что фриз во втором случае занимает гораздо меньше времени, чем в первом.

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