Резервное копирование с использованием Storage Snapshots – функция, поддерживаемая Veeam уже достаточно долгое время, но написать про то, как это работает и вообще зачем, руки так и не добирались.
Настало время исправить это упущение. Ниже мы посмотрим на то, как Veeam взаимодействует с СХД, как он выполняет процедуру бэкапа, и почему бэкап из снимков крайне удобен, и, в целом, желателен к использованию при возможности.
Процесс организации резервного копирования с помощью снимков СХД можно разбить на несколько основных этапов:
- Установка сетевой связанности между прокси-серверами Veeam и СХД. Если это Fibre Channel, настраиваем зонинг и организуем видимость устройств. Если это iSCSI, либо NFS – организуем сетевую связанность и т.д.;
- Подключаем СХД к системе резервного копирования;
- Настраиваем задачу и запускаем бэкап.
В моем тестовом окружении имеется ряд виртуальных машин, которые располагаются на хранилищах VMware, которые подключены к хостам по iSCSI с симулятора ONTAP v9.4.
На хосте, выполняющем роль Veeam Proxy, я добавил iSCSI-инициатор, MPIO и дополнительный сетевой адаптер, который находится в той же сети, в которой располагаются iSCSI LIF с NetApp (сетевой интерфейс, который обслуживает запросы iSCSI со стороны СХД). Никаких других настроек из разряда добавления IQN и прочего на СХД и хостах я не проводил.
Начнем настройку системы резервного копирования.
В первую очередь необходимо настроить подключение к ONTAP с сервера Veeam Backup and Replication.
Выполняется это в меню Storage Infrastructure – Add Storage:
Как можно догадаться, выбираем NetApp. Далее Veeam предложит указать, какой тип СХД мы будем подключать – ONTAP (FAS/AFF и т.п. системы), либо Element (Soldifire, NetApp HCI). Поскольку симулятор работает именно на ONTAP, выбираем его:
Далее, как и при добавлении всех остальных компонентов Veeam, необходимо указать адрес подключения, логины и пароли для доступа.
В качестве адреса подключения используем NetApp cluster IP и учетную запись с правами подключения к кластеру.
Указав данные подключения, следующей вкладкой будет Access Options, с рядом интересных опций:
Protocol to use – как можно догадаться, с использованием каких протоколов мы будем проводить резервное копирование виртуальных машин, располагаемых на добавляемой СХД.
Veeam определяет, какие SVM и с какими протоколами работают в кластере и предлагает их на выбор. У меня работает две SVM:
Если удалить SVM с протоколом NFS, данная опция станет недоступна в мастере настройки (при этом простой перевод SVM в статус disabled не влияет на результат):
Еще одно интересное поле – Volumes to scan. По умолчанию, Veeam будет искать виртуальные машины на всех томах, но это можно и ограничить. Например, в случае, если некоторые тома используются не для нужд виртуализации, либо нет необходимости в резервном копировании машин на данных томах.
Backup proxies – прокси, который сможет «достучаться» до данной СХД по требуемому протоколу.
Завершаем настройку нажатием Apply, после чего Veeam начнет проводить инвентаризацию СХД. По окончанию данного процесса мы увидим все SVM, тома, снапшоты, которые присутствуют на добавленной СХД:
На этом этап по добавлению СХД окончен, и можно перейти к настройке задач резервного копирования.
Создадим привычную задачу бэкапа виртуальных машин vSphere из меню Home – Jobs – Backup. Этот процесс не отличается ничем, за исключением одного пункта – необходимо проверить Advanced настройки задачи, и, в частности, закладку Integration. Чекбокс «Enable backup from storage snapshots» должен быть обязательно отмечен:
Здесь есть ряд интересных настроек, позволяющий ограничить количество одновременно бэкапируемых машин, а также Failover, в случае неудачи при бэкапе со снапшота СХД.
Теперь дело за малым. СХД у нас подключена, задача резервного копирования создана. Запустим задачу и посмотрим, что будет происходить в инфраструктуре в момент ее выполнения.
Привычным образом создаются снапшоты в vSphere для машин, которые включены в задачу:
Следующий шаг должен заметить администратор хранилища. На СХД начинают создаваться снапшоты томов, на которых располагаются бэкапируемые витуальные машины. Затем, из снапшота тома, создается клон (в примере, виртуальные машины располагаются на двух томах V1 и V3, соответственно):
Далее клоны томов по iSCSI подключаются к прокси-серверу, который занимается обработкой задачи:
Примечание: Ранее я указал, что не занимался никакой настройкой iSCSI на прокси. Veeam сам добавляет iSCSI target на прокси-сервере. Target он получает, непосредственно с СХД и устанавливает связь с одним из iSCSI LIF, выделенным для SVM, которая обслуживает iSCSI трафик со стороны СХД. Также он выполняет процедуру Discovery и получает все доступные для него дисковые ресурсы, а именно клоны томов, которые он создал ранее:
Со стороны NetApp, Veeam создает Initiator-Group, в которую включает IQN инициатора прокси-сервера:
Далее начинается привычный всем процесс бэкапирования, заключающийся в копировании виртуальных машин в репозиторий VBR.
По окончанию бэкапа, Veeam отмонтирует все подключенные к прокси луны и удаляет клоны и снапшоты, созданные ранее на СХД:
Единственное, что Veeam оставляет после себя – созданную группу инициаторов и IQN своих прокси. Зачем при следующем резервном копировании вновь тратить время на ее создание?
Вот так просто выполнился бэкап виртуальных машин с СХД NetApp с использованием технологии Backup from Storage Snapshot. В данном логе задачи можно увидеть три “новые” строки, связанные со Storage Snapshot:
Пытливый читатель может спросить – а в чем же смысл резервного копирования с помощью Storage Snapshots, почему не Direct SAN access, если на первый взгляд эти два метода очень похожи. И там и там используется протокол доступа, по которому работает СХД, и там и там LUN с виртуальными машинами подключается к прокси.
Все бы так, если бы не несколько важных моментов:
Время жизни снапшота vSphere. Это, пожалуй, самый главный момент. В привычной операции резервного копирования, снапшот виртуальной машины существует ровно столько, сколько выполняется ее резервное копирование. Это могут быть минуты, а могут быть часы, либо даже десятки часов. Но если взглянуть на время существования снапшота при методе резервного копирования, описанном в статье, можно удивиться:
Снапшот vSphere просуществовал чуть меньше минуты, при том, что бэкап виртуальной машины шел около 10 минут.
Но что же происходило в эту минуту пока существовал снапшот виртуальной машины? – правильно, в эту минуту создавался снапшот тома на СХД, где расположены виртуальные машины и, соответственно, его клон:
Далее, уже непосредственно клон тома подключается к прокси-серверу и с него производится резервное копирование.
Таким образом, снапшот тома СХД содержит состояние виртуальных машин на момент создания снапшота в vSphere, и процедура резервного копирования в Veeam выполняется привычным образом. При этом, в продуктивной среде у виртуальной машины снимок уже удален, и бэкапирования, как будто и не происходит (по крайней мере с точки зрения виртуальной инфраструктуры).
И, как мы все знаем, снимки на СХД в большинстве случаев оказывают минимальное (либо вообще не оказывают) влияние на производительность дискового ввода-вывода, в отличии от снимков vSphere.
Еще одним немаловажным моментом, на мой взгляд является то, что резервное копирование выполняется не с основного тома, а с его клона, и, в случае каких-либо неполадок, основной том затронут не будет (вспоминаем про случайную инициализацию дисков при Direct SAN access, например).
Ну и последнее, но не менее важное – отсутствие необходимости в ручной настройке СХД, маппинге лунов к прокси-серверам и т.п. Veeam делает все за администратора, исключая возможность в ошибках при настройке маппинга, добавлении инициаторов и т.д.
В качестве заключения:
Использование возможности резервного копирования с помощью снимков на СХД, позволяет уменьшить нагрузку на продуктивную среду за счет значительного сокращения времени жизни снапшотов виртуальных машин. При этом, процедура настройки ничуть не сложнее, чем настройка Direct SAN режима, а в некоторых моментах даже проще, поскольку часть операций в виде подключения\отключения лунов с виртуальными машинами Veeam берет на себя.
