Импорт виртуальной машины в Amazon EC2 (часть 5)

Опубликовано: 7 Марта, 2023

Импорт виртуальной машины в Amazon EC2 (часть 2)
Импорт виртуальной машины в Amazon EC2 (часть 4)
Импорт виртуальной машины в Amazon EC2 (часть 6)

Введение

В предыдущей статье этой серии я рассказал о некоторых вещах, которые вам нужно будет сделать, чтобы импортировать виртуальную машину в Amazon EC2. Большинство подготовительных шагов, которые я обсуждал, были общего назначения, но я упомянул некоторые подготовительные шаги, характерные для операционной системы Linux. В этой статье я хочу продолжить обсуждение, рассказав о том, как подготовить виртуальные машины Windows к процессу миграции.

Прежде чем вы начнете

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

Если в настоящее время вы используете Hyper-V в своем центре обработки данных, возможно, вы уже выполняли динамическую миграцию. Если вы используете VMware, вы, вероятно, привыкли использовать функцию vMotion. В любом случае, нет реального наказания за неудачную миграцию. Худшее, что обычно может случиться, — это сбой миграции, и виртуальная машина остается работать на исходном хосте. Это просто не тот случай, когда вы переносите виртуальную машину Windows в облако Amazon.

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

Прежде чем виртуальную машину можно будет перенести в облако Amazon, ее необходимо рандомизировать. Виртуальные машины Windows содержат ряд элементов, уникальных для этой конкретной виртуальной машины. Сюда входят такие вещи, как IP-адрес, имя компьютера и некоторые идентификаторы, которые использует операционная система. Прежде чем вы сможете перенести виртуальную машину в облако, вам придется использовать утилиту SYSPREP, чтобы удалить все, что однозначно идентифицирует виртуальную машину. При этом большая часть содержимого виртуального жесткого диска остается нетронутой, но операционная система для всех практических целей уничтожается.

Если вы загружаете недавно подготовленную Sysprep машину, вы попадаете в программу установки Windows. В процессе установки вам будет задано несколько основных вопросов, а затем будет развернута операционная система Windows. Этот процесс возвращает Windows в функциональное состояние, но есть большая вероятность, что он сломает все приложения, которые были установлены на машине. Вот почему так важно создать резервную копию перед началом подготовки к миграции.

Начиная

В предыдущем разделе я объяснил, что если вы загрузите виртуальную машину, которая недавно была подготовлена Sysprep, запустится программа установки Windows, и вы увидите обычные подсказки, которые вы обычно видите при установке Windows с нуля. Проблема в том, что мы не устанавливаем Windows с нуля. Мы пытаемся перенести виртуальную машину Windows с локального гипервизора на облачный гипервизор. Нет необходимости выполнять SYSPREP для виртуальной машины. Точно так же невозможно запустить программу установки Windows после того, как виртуальная машина была перемещена на новое место. Однако, поскольку виртуальная машина будет работать в общедоступном облаке, на запросы установки необходимо отвечать определенным образом.

В течение многих лет Microsoft признавала необходимость автоматического развертывания. Основной способ, с помощью которого Microsoft достигает этого, — использование файла ответов. Файл ответов, по сути, содержит ответы на запросы программы установки, чтобы процесс установки Windows мог завершиться самостоятельно, без ручного вмешательства. Поэтому неудивительно, что одним из этапов процесса подготовки является создание файла ответов. Вот текст, который Amazon предоставляет для файла ответов:

<?xml version='1.0' encoding='UTF-8'?>

<параметры pass='oobeSystem'>

</компонент>

<OOBE>

<SkipUserOOBE>истина</SkipUserOOBE>

</OOBE>

</компонент>

</настройки>

</unattend>

Вам нужно будет скопировать этот блок кода в текстовый файл с помощью Блокнота или любого другого текстового редактора. В приведенном выше блоке кода есть два места, где вы увидите фразу «x86 или amd64». Вам нужно будет установить архитектуру процессора на X86 или X64 в обоих этих местах. После этого вам нужно будет сохранить файл в папку C:WindowsPanther. Файл должен называться unattend.xml. Если вы используете любое другое имя файла или местоположение, файл ответов будет проигнорирован.

Когда файл ответов будет на месте, откройте окно командной строки с повышенными привилегиями и выполните следующую команду:

Sysprep /obe /generalize

Другие соображения

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

Я рекомендую продолжить и применить все доступные обновления, прежде чем пытаться экспортировать виртуальную машину. Есть несколько исправлений, которые требуются Amazon, но эти исправления устарели и не требуются, если вы установили все последние обновления. Если вам интересно, требуемые исправления:

https://support.microsoft.com/en-us/kb/2922223

https://support.microsoft.com/en-us/kb/2800213

Возможно, самое важное, что вы можете сделать для подготовки к миграции виртуальной машины, — это спланировать процесс миграции. Это звучит очень очевидно, но у безумия есть метод. Вы не можете просто перенести работающую виртуальную машину с одного хоста на другой, как в случае локального развертывания Hyper-V. Виртуальную машину необходимо отключить в процессе миграции. Здесь в игру вступает планирование.

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

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

Вывод

В этой статье я объяснил, как подготовить виртуальную машину Windows к миграции в облако Amazon. В следующей статье этой серии я покажу вам, как выполнить реальный процесс экспорта, и покажу, как импортировать виртуальную машину в облако Amazon.

Импорт виртуальной машины в Amazon EC2 (часть 2)
Импорт виртуальной машины в Amazon EC2 (часть 4)
Импорт виртуальной машины в Amazon EC2 (часть 6)