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

Опубликовано: 8 Марта, 2023
Импорт виртуальной машины в Amazon EC2 (часть 1)

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

Введение

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

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

Как насчет стоимости?

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

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

Какие виртуальные машины являются хорошими кандидатами для миграции?

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

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

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

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

Требования к программному обеспечению

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

  • VMware ESX
  • Рабочая станция VMware (образы VMDK)
  • Citrix Xen (образы VHD)
  • Microsoft Hyper-V (только образы VHD, VHDX не поддерживается)

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

  • Windows сервер 2003
  • Windows Server 2003 R2
  • Windows Сервер 2008
  • Windows Server 2008 R2
  • Виндовс Сервер 2012
  • Windows Server 2012 R2
  • Red Hat Enterprise Linux (RHEL) 5.1–6.5 (с использованием облачного доступа)
  • Центос 5.1-6.5
  • Убунту 12.04, 12.10, 13.04, 13.10
  • Дебиан 6.0.0-6.0.8, 7.0.0-7.2.0.

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

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

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

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

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

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

Следует иметь в виду, что механизм лицензирования, о котором я говорил, применим только к виртуальным машинам Windows. Виртуальные машины Linux используют собственную модель лицензирования. Например, Amazon позволяет использовать переносимость лицензий при импорте виртуальных машин Red Hat Enterprise Linux.

Вывод

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

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

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