Применяем Veeam Backup & Replication для тестирования новых систем и приложений перед апгрейдом

Месяц с небольшим тому назад компания Microsoft объявила о выходе новейшей версии Windows Server 2019. Однако после GA (general availability) были обнаружены серьезные недостатки, как и в Windows 10 October 2018 Update (оно же 1809) — установка обновления приводила к потере данных (файлы из My Documents жестоко удалялись, так что их нельзя было восстановить из Windows.old). Производитель был вынужден отменить релиз до устранения проблемы. И вот наконец-то 13 ноября починенная версия увидела свет.

Наряду с этим следует вспомнить, что скоро Microsoft завершит поддержку SQL Server 2008 R2 и Windows Server 2008 R2.

Естественно, что у пользователей возникает множество вопросов по переходу на новые системы:
Переезжать ли в облако Microsoft Azure? Как безопасно повысить функциональный уровень домена? Переходить ли на Azure SQL? Может, надо виртуализировать Windows Server 2008 R2 или перенести в Azure? Надо ли мигрировать на новейший Hyper-V?

Миграция на новую платформу нужна, чтобы обеспечить для критически важных приложений, работающих в ЦОД, наличие системы, поддерживаемой вендором. Поэтому важно, чтобы миграция прошла без сюрпризов. Пользователям Veeam повезло — у них есть хорошие способы минимизировать риски при подобных операциях, чтобы, как говорится,»7 раз отмерить, 1 раз отрезать».

За подробностями добро пожаловать под кат.

qvivchkwjb95lti98-5ijcjkkis.png


Лучшие бэкаповеды практики рекомендуют проверять резервные копии на возможность восстановления, в частности, с помощью «песочницы» Veeam DataLab. Впервые она увидела свет в релизе Veeam Backup & Replication в 2010 году (тогда она называлась Virtual Lab) и с тех пор постоянно обновлялась и развивалась. Сегодня она становится отличной помощницей для тестирования нового ПО перед развертыванием — автономная «песочница» позволяет протестировать планируемые обновления и изменения систем и приложений без риска для продакшена, будь то апгрейд на Windows Server 2019, переход на новую версию SQL или другие операции.

Устройство такой «песочницы» показано на картинке ниже:

jk2hytqgtpjgmy4mgla6hjbikkm.png

Для работы «песочницы» задействуются:

  • Application group («группа для приложения») — это одна или более виртуальных машин, которые обеспечивают работу интересующего вас приложения. Например, это может быть веб-сервер и сервер баз данных для SharePoint или домен-контроллер и сервер Exchange, и т.д.
  • Proxy appliance — вспомогательная машина-прокси, которая служит для изолирования «песочницы» DataLab от производственной инфраструктуры. Она позволяет создать пространство IP-адресов в изолированной сети без пересечения с производственной с помощью маскарадных (masquerade) IP-адресов.


Настройка такой «песочницы» подробно описана в пользовательской документации. Также в ближайшем будущем планируется отдельный документ с примером использования DataLab как раз для тестирования апгрейда на Windows Server 2019, на новый SQL Server, а также для миграции в Azure.

6jrthrr552hu49yew9465-nf190.png


Еще одна полезная технология, реализованная в решении Veeam — это возможность восстановления из резервной копии в Microsoft Azure. Теперь она встроена в Veeam Backup & Replication, что весьма удобно. Вдобавок, можно использовать и эту возможность, чтобы протестировать новые системы и приложения, процесс миграции, сетевые подключения и т.п. — можно ведь поднять тестовую инфраструктуру в облаке Azure. Если все пройдет успешно, то затем повторить аналогичные шаги в ходе плановой миграции продакшена в Azure. Остановимся на этой фиче поподробнее.

Почему именно про Azure?


Компания Microsoft объявила, что Extended Security Updates будут бесплатно доступны в Azure для Windows server 2008 R2 еще в течение 3 лет после окончания поддержки. Пользователи могут переместить свои машины в Azure, не меняя код приложений, и чем раньше они это сделают, тем у них будет больше времени спланировать будущие обновления. Подробнее можно почитать здесь.
Отметим, что с помощью восстановления из резервной копии в облако Azure можно перенести практически все, что умеет бэкапить Veeam: Windows Servers, машины под управлением Linux, виртуальные машины на платформах vSphere и Hyper-V, и прочая, и прочая.

Как это работает?


Для Windows-машин процесс будет идти так:

chaktw3-cgua5skvt9evxbkjbg0.png

  1. Если вы используете Azure-прокси, то Veeam Backup & Replication включит его. Подробнее про этот прокси можно почитать здесь.
  2. Veeam Backup & Replication преобразует диски забэкапленной машины в формат VHD и загружает в хранилище (blob storage) в облаке Microsoft Azure.
  3. Затем эти диски монтируются к серверу Veeam backup server.
  4. Идет подготовка дисков к восстановлению ВМ: активируются правила для работы Remote Desktop, настраиваются правила работы через firewall, готовится почва для установки агента Microsoft Azure, и т.д.
  5. Veeam Backup & Replication размонтирует диски.
  6. Если был использован Azure-прокси, то он автоматически выключается.
  7. Veeam Backup & Replication регистрирует ВМ Microsoft Azure с подготовленными дисками. После этого машина включается, и на нее ставится агент Microsoft Azure.


Восстановление Linux-машин происходит аналогично — только диски при этом монтируются на вспомогательную ВМ (helper appliance). Подробнее см. здесь (на англ. языке).

Для восстановления есть ряд ограничений, а именно:

  • Поддерживаются следующие гостевые ОС:
  • Размер одного диска восстанавливаемой ВМ не должен превышать 4095 GB.
  • Если системный диск исходной машины имеет структуру разделов GPT, то число разделов может быть не более 4. В ходе восстановления такой диск будет преобразован в диск со структурой разделов MBR.
  • Не поддерживается программа Azure Hybrid Use Benefit.


Важно! Проверьте, что на сервере Veeam backup правильно установлено время, иначе возможны ошибки при попытке добавить учетку Microsoft Azure в инфраструктуру Veeam Backup & Replication или при выполнении восстановления.

Добавляем в Veeam Backup & Replication учетную запись Microsoft Azure


Чтобы выполнять восстановление, необходимо, в частности, добавить учетную запись Microsoft Azure в инфраструктуру Veeam Backup & Replication. При этом Veeam Backup & Replication сохраняет в свою базу данные о подписках и ресурсах, ассоциированных с учетной записью, а в ходе восстановления в облако использует их, чтобы зарегистрировать новую ВМ в Microsoft Azure. Для импорта этих данных есть 2 варианта:

  • модель работы с использованием Resource Manager
  • классическая модель работы


Сам провайдер (Microsoft Azure) рекомендует развертывать новые машины в облаке с помощью Resource Manager, поэтому его мы и будем использовать.

До того, как в консоли Veeam Backup добавить учетную запись Microsoft Azure, надо выполнить несколько подготовительных действий:

  1. Убедитесь, что у вас уже есть учетка Microsoft Azure. Мастер настройки умеет только добавлять учетные записи, но не создавать.
  2. [Для тех, у кого серверная Windows ОС] В настройках Internet Explorer нужно выключить Protected Mode, иначе в ходе работы с Мастером настройки вам будет не залогиниться в облако.
  3. Если нет возможности отключить защищенный режим Protected Mode, добавьте в список разрешенных сайтов следующие:
    Возможно, потребуется также отключить Internet Explorer Enhanced Security Configuration в Server Manager.
  4. Проверьте, что на сервере Veeam backup установлено правильное время, соответствующее часовому поясу, в котором расположен сервер.
  5. На машине, где работает консоль Veeam Backup, настоятельно рекомендуется установить Microsoft Azure PowerShell 4.0.2. Если у вас другая версия, могут быть сложности. Если у вас нет вообще никакой версии Microsoft Azure PowerShell, то Veeam Backup предложит установить ее (об этом ниже).
  6. Необходимо настроить HTTP/HTTPS прокси для учетной записи Local System или для учетной записи, под которой работает Veeam Backup Service. Подробнее см. здесь.


Теперь приступаем к добавлению учетной записи Azure. Как договорились, мы будем использовать модель с Resource Manager:

  1. В главном меню Veeam Backup & Replication выбираем пункт Manage Azure Accounts.
  2. В окошке Manage Microsoft Azure Account кликнем Add для запуска мастера.

    w5v-49rx166580pti1qp-tmxasq.png

  3. На шаге Deployment Model (модель развертывания) выбираем опцию Azure Resource Manager.
  4. Из списка Region выбираем нужный регион Microsoft Azure: Global, Germany или China.
  5. После клика на Next Veeam Backup & Replication проверит, есть ли на данной машине Microsoft Azure PowerShell. Если нет, то будет выдано предупреждение со ссылкой на инструкции по установке. После установки нужно будет перезапустить Мастер настройки.

    ewnzuinuilks3ekx2ew4cqwurxq.png

  6. На шаге Subscription нажимаем Configure account. Нужно будет залогиниться на портал Microsoft Azure, введя имеющуюся учетную запись. Veeam Backup & Replication получит информацию о подписках и ресурсах, предоставленных обладателю этой учетки.

    Если вы планируете восстанавливать Linux-машины, то нужно зачекать галочку Enable restore of Linux-based computers. В этом случае Veeam Backup & Replication развернет в облаке вспомогательную машину (helper appliance), необходимую для восстановления.

    4ni6zxiuib0fm_6f0rn91zsdsjg.png

  7. Проходим по шагам Мастера настройки до конца и там жмем Finish.


Подготавливаем бэкапы


Поддерживаются следующие разновидности бэкапов:

  • Бэкапы виртуальных машин (Microsoft Windows и Linux), созданные с помощью Veeam Backup & Replication
  • Бэкапы физических Windows-машин, созданные с помощью Veeam Agent for Windows.
  • Бэкапы физических Linux-машин, созданные с помощью Veeam Agent for Linux.


Примечание: Чтобы восстановить физическую машину в Azure, нужно бэкапить всю ее целиком или делать бэкап томов.

Отметим, что можно восстановить машинку на состояние как в последней точке восстановления или как в любой предыдущей точке в цепочке бэкапов. Цепочка при этом должна храниться в репозитории, входящем в инфраструктуру Veeam Backup. Также можно импортировать имеющийся бэкап.

Выполняем восстановление


Для этого запускаем мастер восстановления Restore to Azure:

  1. В представлении Home разворачиваем узел Backups в дереве слева. Затем в правой панели разворачиваем узел нужного нам бэкапа, выбираем там нужную машину.
  2. Кликая по ней правой кнопкой, выбираем команду Restore to Microsoft Azure и переходим на шаг мастера Deployment Model.

    w5v-49rx166580pti1qp-tmxasq.png

  3. Указываем, какую модель развертывания в Microsoft Azure будем использовать при восстановлении в облако. В нашем случае это будет Azure Resource Manager.

    p7xgv7dnuf_qihqev08eezrew4c.png

  4. На шаге Subscription указываем следующие настройки:
    • В списке Subscription будут показаны все подписки, доступные для учетки, которую мы добавили в Veeam Backup на первом этапе. Выбираем подписку, ресурсами которой хотим воспользоваться.
    • Из списка Locations выбираем регион, в котором хотим разместить восстановленную машинку. Обязательно убедитесь, что для этого региона у учетки (подписки) есть хотя бы одна СХД.
    • Если вы хотите ускорить процесс восстановления в отдаленный регион, советуем использовать Use Azure proxy VM, выбрав Microsoft Azure прокси из списка. Разумно, чтобы прокси находился в том же регионе, куда вы будете восстанавливать машину.

    lz_i2csoqrpp8vjo1z4u1de31fg.png
  5. На шаге VM size указываем размер машины и учетку для СХД, где будут размещены диски восстановленной машины.
    1. Выбираем машину из списка Azure VM Configuration и нажимаем Edit.
    2. Из списка размеров Size выбираем, какого размера будет восстановленная ВМ. (По умолчанию будет выбран минимальный достаточный для имеющегося у ВМ числа дисков).
      Примечание: Здесь нужно иметь в виду, что от размера ВМ будет зависеть число ядер ЦПУ, ресурсы памяти и дискового пространства, которые будут отведены этой ВМ. Подробнее читаем документ от Microsoft.
    3. Из списка Storage account выбираем т.н. «учетную запись хранения» для СХД, на которой хотим хранить диски восстанавливаемой ВМ. (Помним про выбранный размер ВМ.) Если вы указали, что при развертывании ВМ в облаке будете задействовать Azure proxy, то в данном списке отобразятся только general-purpose учетки (учетки для Blob не будут показаны). Про разные типы учеток написано тут.

    sbsmikxnlkbxp3qlzpb_jrjukcw.png
  6. На шаге Resource Group можно указать новое имя для восстанавливаемой ВМ (по умолчанию оно будет совпадать с именем исходной машины). Кликаем Name и указываем новое имя явно, либо задаем правило, по которому оно будет формироваться — путем добавления префикса и\или постфикса к исходному.

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

    • Place VM into the existing resource group (поместить в существующую группу)
    • либо Create a new resource group (создать новую группу)

    jse7kidzkjwq0imqrlfpnzaodvo.png
  7. На шаге Network указываем сеть и подсеть для подключения восстановленной ВМ.

    tywo-jnnwddjxrp5xjfq-u8xi38.png


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

Подробное описание работы мастера восстановления для обоих режимов развертывания (включая Classic mode) можно найти здесь (на англ. языке).


Если вы готовы поделиться своим опытом практического использования «песочницы» или восстановления в Azure из бэкапов Veeam, добро пожаловать в комментарии.

Если вы хотите узнать об этих функциональных возможностях поподробнее, то вам в помощь:

© Habrahabr.ru