Если вы когда-нибудь задавались вопросом – «А рабочие ли у меня бэкапы?», «А запустится ли ОС и приложения из crash consistent резервной копии?», а возможно уже тестируете свои резервные копии на регулярной основе, и при этом основным средством резервного копирования у вас является Veeam, то, скорее всего, вы слышали про SureBackup.
Veeam SureBackup – это отличный помощник в проверке ваших резервных копий на их пригодность, который автоматизирует процесс запуска виртуальных машин напрямую из файлов бэкапов в изолированной среде, выполняет базовую проверку доступности систем и формирует отчет по результатам тестирования.
Это своеобразное переиздание оригинальной статьи, которую я написал еще в 2016 году на Хабре, и которая пользуется определенным успехом в поисковой выдаче Google, но уже с поправкой на 11-ю версию VBR.
Начать стоит с того, а что вообще может случиться с моими резервными копиями, ведь бэкап делается каждый день/неделю/месяц и Veeam каждый раз ставит зеленые галочки. Разве это не гарантия? – К сожалению, нет.
- Незаметно для глаза, ранее созданные копии могут быть повреждены, в случае с проблемами на носителе, на котором они располагаются (это, конечно, мало касается современных СХД);
- В случае с crash consistent резервными копиями, бэкап содержит в себе виртуальную машину, у которой просто «выключили питание, ничего не спросив». В таком случае крайне легко получить ошибки файловой системы и потребуется дополнительная проверка и восстановление;
- А запускаются ли вообще приложения в виртуальной машине после запуска ОС?
На большинство подобных вопросов сможет ответить SureBackup, который только и делает, что запускает виртуальные машины и проверяет их доступность после восстановления из резервной копии, избавляя от лишней ручной работы администраторов систем резервного копирования.
SureBackup работает по следующему принципу:
- На площадке виртуализации создается виртуальная лаборатория. Это может быть как отдельный хост, так и целый кластер, в котором запускаются для проверки виртуальные машины. Все они подключены к изолированной сети и не оказывают влияния на продуктивную среду;
- Далее, по аналогии с механизмом работы Instant Recovery, выбранные для проверки виртуальные машины автоматически запускаются в изолированной среде непосредственно из резервных копий;
- SureBackup выполняет ряд заранее указанных проверок запущенных резервных копий;
- Отправляется отчет по результатам тестового восстановления.
В качестве автоматических тестов SureBackup может проверять:
- OS Heartbeat – проверка состояния VMware Tools в гостевой ОС. Если VMTools в рабочем состоянии, данный тест считается пройденным;
- Ping Test – здесь все просто, если ping виртуальной машины по сети успешен, тест также считается пройденным;
- Проверка доступности определенных приложений с помощью специальных скриптов, в большинстве случаев заключающейся в проверке определенного порта, на котором работает приложение.
Проверки Heartbeat и Ping нуждаются в наличии VMware Tools, поэтому данный компонент должен быть установлен в ОС (очень странно, если это по какой-то причине не было сделано), иначе эти проверки будут пропущены.
Теперь, когда мы разобрались с базовой теорией, перейдем непосредственно к настройке.
Начать необходимо, как уже было сказано ранее, с создания виртуальной лаборатории в меню Backup Infrastructure – SureBackup – Virtual Labs.
Нажатием правой кнопкой мыши по Virtual Labs, запускаем процедуру создания новой лаборатории.
Начинаем, как всегда, с названия:
На следующей вкладке необходимо указать хост, на котором будет развернута лаборатория и где будут запускаться виртуальные машины. На этом хосте также будет создан пул ресурсов, для ограничения влияния соседние (продуктивные) виртуальные машины:
Следующий пункт настройки предлагает указать Datastore, на котором будут храниться все изменения, сделанные виртуальными машинами во время запуска проверок. По умолчанию это vPower NFS сервер.
Если дисковый ввод-вывод виртуальных машин, участвующих в тестовых восстановлениях небольшой, можно оставить как есть. В случае, если виртуальные машины очень много пишут, стоит предварительно позаботиться о размере этого самого vPower NFS, чтобы ему всегда хватало места, либо выбрать другое хранилище:
Следующим шагом выполняется настройка Proxy Appliance. Это небольшая виртуальная машина, являющаяся шлюзом между продуктивной средой и изолированной сетью с виртуальными машинами. Через Proxy мы получаем доступ в изолированную сеть с виртуальными машинами и выполняем соответствующие проверки.
Также стоит отметить, что Proxy не является обязательным компонентом, но без него выполнять автоматические проверки просто не представляется возможным, поэтому снимать галку «Use proxy appliance in this virtual lab» я бы не стал.
На экране настройки мы можем задать хранилище, где данная VM будет расположена, выбрать продуктивную сеть, к которой будет подключен прокси, указать IP и DNS (либо, использовать DHCP, как в моем случае):
Также, данный прокси может выступать в качестве привычного интернет прокси-сервера, для виртуальных машин в изолированной сети.
Дальше начинается интересное. Переходим к этапу Networking. Здесь нам предлагается выбрать один из трех вариантов:
- Basic single-host – Для небольших инсталляций, где используется всего одна сеть. Конфигурация сети будет выполнена автоматически с параметрами, аналогичными сети, в которой размещен Proxy Appliance и будет создана всего одна изолированная сеть;
- Advanced single-host – Для сетей побольше. Когда виртуальные машины находятся в разных сетях, с разными номерами VLAN. Требуется ручная настройка и создание нескольких изолированных сетей;
- Advanced multi-host – Для виртуальных лабораторий, разнесенных на несколько хостов, например, для тестирования реплик. Требует наличие Distributed vSwitch, и, соответственно Enterprise Plus лицензию vSphere.
Поскольку в моей инфраструктуре несколько виртуальных машин, расположенных в разных сетях, я выбираю второй пункт:
Можно обратить внимание, что после выбора второго, либо третьего пункта, меню настройки расширяется и появляется еще несколько этапов конфигурации сети для будущей лаборатории.
На следующей закладке Isolated Network мы указываем соответствие между продуктивной сетью и будущей изолированной сетью.
Здесь нужно понимать, что изолированные сети еще не созданы и будут созданы только по окончанию процедуры настройки виртуальной лаборатории.
Далее, виртуальные машины, которые участвуют в проверках, будут подключаться к изолированной сети, на основании продуктивной сети к которой они были подключены на момент выполнения резервного копирования.
Изначально, будет создана одна изолированная сеть, в которой размещен Proxy Appliance:
Добавим еще одну сеть, с помощью кнопки Add. Появится окно Network Mapping, в котором необходимо выбрать продуктивную сеть и указать название изолированной сети:
Номер VLAN будет выбран автоматически, аналогично продуктивной сети. Останется только указать название изолированной сети:
Таким образом мы указали необходимость в создании двух изолированных сетей, по аналогии с продуктивными сетями, в которых располагаются виртуальные машины:
Следующий пункт настройки Network Settings является, пожалуй, самым интересным.
В данном пункте мы настраиваем Proxy Appliance в качестве шлюза для виртуальных машин в изолированных сетях. А также настраиваем маскарадинг, для доступа к виртуальным машинам в изолированной сети извне:
Чуть более подробно – ранее, мы уже добавили две сети (в моем случае это сети 10.10.122.0/24 в VLAN 122 – DPG-Infra и 10.10.123.0/24 в VLAN 123 – DPG-TestVMs).
Представим, что мы тестируем восстановление виртуальных машин, которые располагаются в разных сетях и им нужно взаимодействовать между собой. Например, DNS сервер в одной сети и виртуальная машина, которой необходим доступ к DNS – в другой.
В обычной ситуации, эти виртуальные машины могут взаимодействовать между собой с помощью маршрутизаторов, которые располагаются в их сетях. В моем случае это 10.10.122.1 и 10.10.123.1. Однако, из изолированных сетей доступа к этим маршрутизаторам, конечно же, не будет. Тут в дело вступает Proxy Appliance, который будет представлять из себя маршрутизатор, для данных виртуальных машин с реальными, пусть и недоступными извне, IP-адресами.
Теперь немного про маскарадинг. Proxy Appliance позволяет нам получить доступ к виртуальным машинам в изолированной сети, через заранее указанный маскарадный адрес.
Работает это просто, возьмем для примера сеть 10.10.122.0/24, сеть класса C. В настойках Proxy Appliance (об этом далее) мы указываем, что для сети 10.10.122.0/24 необходимо использовать маскарадную сеть 192.168.122.0/24.
Далее, в процессе запуска процедуры тестирования, Veeam определяет реальный адрес виртуальной машины и маскирует его, тем самым, предоставляя доступ к машине извне по маскированному адресу.
Например, если у виртуальной машины адрес 10.10.122.54, мы сможем получить к ней доступ по адресу 192.168.122.54 (либо по другому адресу, который определит Veeam). Для этого необходимо будет обновить свою таблицу маршрутизации, указав, что для сети 192.168.122.0/24 шлюзом является адрес нашего Proxy Appliance. У сервера VBR таблица маршрутизации обновляется автоматически.
Займемся настройкой и все встанет на свои места. Изначально, мастер настройки создает интерфейс vNIC1, настройки которого отличны от необходимых мне, поэтому данный интерфейс я удаляю нажатием кнопки Remove и создаю новый, нажатием кнопки Add:
В первую очередь мы указываем изолированную сеть, для которой хотим настроить шлюз и маскарадинг.
Далее мы указываем, с каким IP адресом в данной сети будет присутствовать Proxy Appliance (напомню, что он будет являться маршрутизатором для данной сети).
Ну а последним пунктом мы указываем сеть, которая будет использоваться для маскарадинга.
Опционально можно включить DHCP в данной сети.
Аналогично, я создаю настройки для второй сети и как итог получаю два vNIC:
Для маршрутизации между сетями, необходимо включить переключатель «Route network traffic between vNICs».
Переходим в следующий пункт настройки Static Mapping:
На данном этапе мы можем настроить доступ извне к адресу из изолированной сети по заранее заданному адресу из продуктивной сети, который будет поднят на Proxy Appliance. Зачем это нужно, если есть маскарадинг? Ну, например, чтобы не менять таблицу маршрутизации у нескольких клиентов.
Настройка крайне проста – мы указываем реальный адрес виртуальной машины, которая запущена в изолированной сети и реальный, но свободный адрес из нашей продуктивной среды. Предварительно необходимо включить «Define static IP address mapping»:
Правило добавилось:
На этом настройка виртуальной лаборатории закончена. Переходим на этап Ready To Apply и сверяем настройки:
Нажатием кнопки Apply запускаем создание виртуальной лаборатории.
Дальше начинается процесс создания vLab:
На выбранном в начале хосте создается пул ресурсов с названием виртуальной лаборатории, а в данном пуле размещается Proxy Appliance:
На выбранном хосте создается новый виртуальный свитч (vSwitch):
Сразу можно заметить, что на данном свитче созданы изолированные сети с номерами VLAN, указанными еще на этапе инсталляции. Также, данный свитч не имеет никаких физических аплинков, что гарантирует отсутствие связи виртуальных машин из изолированной среды с реальным миром.
Если посмотреть в свойства Proxy Appliance, мы увидим, что он подключен к трем сетям:
Первая сеть – подключение к продуктивной среде, для связи с внешним миром, а также для доступа к изолированной сети из продуктивной.
Вторая и третья сети – для связи с виртуальными машинами в изолированной сети.
В консоли VBR у нас отображается новая виртуальная лаборатория:
Если необходимо внести какие-то изменения в настройки, добавить новые сети, либо, наоборот, удалить – сделать это можно через пункт меню Edit Virtual Lab.
В качестве заключения:
В первой части мы подробно рассмотрели процесс настройки и конфигурации виртуальной лаборатории для тестирования резервных копий, а в следующей займемся непосредственным тестированием.
Изначально, я планировал уложиться в рамках одной статьи, но уж слишком много получилось картинок.
