Hyper-V: план переноса виртуальной машины и возврата при неудаче
Как согласовать версию конфигурации, восстановление, испытание приложения и момент переключения на новый хост.
Описать один перенос и его зависимости
План переноса полезно составлять для конкретной виртуальной машины. Запишите её назначение, версию гостевой ОС, приложения, диски, сетевые подключения и внешние зависимости. Отдельно укажите владельца сервиса, администратора и человека, который примет результат. Если приложение обращается к другой базе или службе, её доступность должна входить в испытание.
Согласуйте окно работ, допустимый простой и момент остановки записи данных. До переключения договоритесь, какое состояние будет считаться исходным для возврата. Простая фраза «вернём старый сервер» не описывает судьбу изменений, появившихся после запуска новой системы. План должен объяснять, кто принимает решение о возврате и как сохраняются нужные данные.
Проверить версию и способ импорта
Microsoft указывает, что целевой хост должен поддерживать версию конфигурации импортируемой ВМ. Перенос на более новый Hyper-V обычно возможен, а обратное направление нельзя считать автоматически доступным. Зафиксируйте версии обоих хостов и конфигурации до работ. Не включайте обновление конфигурации в обязательный этап, пока администратор не подтвердит последствия для возврата.
В документации различаются регистрация на месте, восстановление и импорт копии. Они по-разному используют файлы и идентификатор машины. Попросите исполнителя указать выбранный вариант и расположение рабочих файлов после импорта. Это помогает заранее понять, какой комплект сохраняется для повторного восстановления и какие изменения затронут исходный экземпляр.
Репетировать восстановление отдельно
Документация Hyper-V различает резервную копию всей ВМ и копию только данных. Во втором случае восстановление предполагает создание машины, в которую возвращаются данные. Поэтому в плане следует назвать состав копии и процедуру, которую реально умеет выполнить ответственная команда. Наличие файла с данными само по себе не подтверждает готовность полного восстановления сервиса.
Предлагаемый порядок — заранее выполнить репетицию на согласованной тестовой копии в изолированном окружении. Проверяют запуск ОС, приложение, доступ к нужным данным и зависимости. Результат фиксируют с датой, затраченным временем и обнаруженными ограничениями. Для испытания используют согласованные данные; рабочие копии и секреты не пересылают в обычном закупочном запросе.
Определить критерий переключения и возврата
До окна работ подготовьте несколько понятных операций приложения: вход пользователя, чтение документа, тестовую запись и предусмотренное пакетное задание. Для каждой назначьте проверяющего и критерий успеха. Выделите предельное время принятия решения, после которого начинается согласованный возврат. Его выбирают по требованиям сервиса и времени восстановления, а не по универсальному шаблону.
После переключения зафиксируйте результаты проверок и подтверждение владельца приложения. Исходные файлы, копии и журналы сохраняйте до согласованного завершения периода наблюдения. Если новая система уже получила рабочие изменения, возврат требует отдельного решения по этим данным. Итог подготовки — исполнимый план с ответственными и проверенным способом восстановления, который можно включить в объём работ подрядчика.
Серверная инфраструктура. Иллюстративная фотография: Brett Sayles / Pexels.