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

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

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

Миграция виртуальной машины на AWS EC2 основана на экспорте/импорте. Если вы когда-либо работали с некоторыми из более ранних версий Microsoft Hyper-V, то вы, возможно, знакомы с концепцией экспорта виртуальной машины и ее последующего импорта на другой хост Hyper-V. Миграция виртуальной машины в AWS работает аналогично, за исключением того, что вы должны экспортировать виртуальную машину из локального гипервизора, а затем импортировать виртуальную машину в AWS.

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

Как я уже говорил в предыдущей статье, процесс экспорта/импорта универсален. Windows, Linux и Mac OS X поддерживаются в качестве гостевых операционных систем (хотя существуют некоторые ограничения, зависящие от версии). Также поддерживаются распространенные гипервизоры, такие как VMware, Hyper-V и Citrix.

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

Установка необходимых инструментов

Как я упоминал в первой статье этой серии, есть несколько инструментов, которые вам понадобятся для работы в процессе миграции. Поскольку я буду работать в среде Windows, мне нужно будет использовать что-то, называемое интерфейсом командной строки Amazon EC2 (или просто CLI для краткости).

Инструменты Amazon CLI основаны на Java и инкапсулированы в ZIP-файл. Одна из действительно приятных особенностей инструментов заключается в том, что их не нужно устанавливать. Вы можете просто скачать файл, разархивировать его и использовать инструменты. Однако вам необходимо установить Java, чтобы инструменты работали. Вы можете скачать Java с https://java.com/en/download/. Вы можете загрузить Amazon CLI Tools по адресу: https://aws.amazon.com/developertools/351.

После загрузки инструментов CLI вам нужно будет установить переменную среды JAVA_HOME. Инструменты CLI обращаются к этой переменной среды, чтобы найти среду выполнения Java.

Чтобы установить переменную времени выполнения JAVA_HOME, щелкните правой кнопкой мыши «кнопку запуска» компьютера, а затем выберите команду «Система» в контекстном меню. Когда Windows отобразит диалоговое окно «Система», щелкните ссылку «Дополнительные параметры системы». Это заставит Windows открыть диалоговое окно «Свойства системы».

На этом этапе вам нужно будет выбрать вкладку «Дополнительно» диалогового окна и нажать кнопку «Переменные среды», как показано на рисунке A.

Рисунок A. Нажмите кнопку «Переменные среды».

Теперь Windows отобразит диалоговое окно «Переменные среды». Как вы можете видеть на рис. B, это диалоговое окно разделено на раздел «Переменные пользователя» и раздел «Системные переменные». Вам нужно будет нажать кнопку «Создать», прикрепленную к разделу «Пользовательские переменные».

Рисунок B: Нажмите кнопку «Создать», соответствующую разделу «Пользовательские переменные».

Теперь вам будет предложено ввести имя для переменной среды, которую вы создаете. Имя должно быть JAVA_HOME. Вы должны ввести это имя заглавными буквами.

Далее вам нужно будет ввести значение переменной. Значение должно быть установлено так, чтобы оно отражало путь к домашней папке Java. Вы должны убедиться, что вы не включаете папку BIN в путь. В противном случае инструменты CLI не будут работать. Фактический путь, который вы будете использовать, зависит от того, как вы установили Java. Если предположить, что Java была установлена в папку по умолчанию, путь будет C:Program Files (x86)Javajre <номер версии>. Вы можете увидеть, как это выглядит на рисунке C. Нажмите OK три раза, чтобы завершить процесс.

Рисунок C: Вы должны ввести путь к домашней папке Java.

Теперь, когда переменная среды установлена, рекомендуется протестировать переменную, чтобы убедиться, что она работает правильно. Это на удивление легко сделать, и эта техника, вероятно, будет знакома тем из вас, кто вырос с DOS, как и я.

Чтобы дать вам краткий курс древней истории, в старой операционной системе DOS есть собственный язык сценариев, который часто называют пакетным программированием. Хотя возможности пакетного программирования были намного скромнее, чем у PowerShell, у него было множество применений. Один из распространенных методов пакетного программирования включал использование переменных среды как способа определения констант. На эти переменные можно ссылаться в пакетном файле, помещая знак процента до и после имени переменной. Мы можем использовать тот же метод для ссылки на только что созданную переменную среды, потому что командная строка Windows в значительной степени обратно совместима с версиями DOS, выпущенными более 30 лет назад.

Итак, хватит с урока истории. Давайте посмотрим, как работает переменная окружения. Для этого откройте окно командной строки и введите следующую команду:

Эхо %JAVA_HOME%

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

Рисунок D: Ввод Echo %JAVA_HOME% должен привести к тому, что Windows отобразит путь к домашней странице Java.

Как только вы подтвердите, что переменная среды %JAVA_HOME% действительно содержит путь к домашнему каталогу Java, вам необходимо убедиться, что Java работает и доступна из командной строки. Самый простой способ сделать это — выполнить проверку версии Java. Для этого введите следующую команду:

«%JAVA_HOME%»injava –версия

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

Рисунок E: Если отображается информация о версии Java, переменная среды настроена правильно.

Как вы знаете, все исполняемые файлы Java находятся в папке BIN Java. В этом случае Amazon рекомендует добавить папку Bin в системный путь. Для этого откройте диалоговое окно «Система», как вы это делали ранее, выберите вкладку «Дополнительно» и нажмите кнопку «Переменные среды». Теперь найдите переменную Path, содержащуюся в разделе «Системные переменные». Выберите переменную Path и нажмите кнопку Edit.

Переменная Path содержит несколько различных путей. Переместите курсор в начало списка путей и введите %JAVA_HOME%in; Убедитесь, что вы случайно не перезаписали какое-либо из существующих значений пути в процессе. Нажмите OK несколько раз, а затем перезагрузите сервер.

Когда сервер перезагрузится, введите следующую команду:

Эхо% путь%

Проверьте наличие кода, который вы только что добавили в путь.

Теперь просто введите:

Java – версия

Теперь вы должны увидеть отображаемую версию Java, как показано на рисунке F. Это доказывает, что Java доступна по пути по умолчанию, и мы можем двигаться дальше с инструментами Amazon CLI.

Рисунок F. Теперь Java должен быть доступен по пути по умолчанию.

Вывод

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

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