Приветствую всех, уважаемые гик-ридеры!
Сегодня хочется рассказать про что-нибудь виртуальное, виртуально-машинное — и желательно публичное.
А раз так — то вариантов у меня особо не много — так что речь пойдет про виртуальные машины Windows Azure, а точнее про создание кастомных виртуальных машин, а также про механизмы которые в этом принимают участие.
Ну что же — давайте погружаться!
Диски и образы
Когда речь заходит про виртуальные машины в публичном облаке, у многих загораются глаза и появляются вполне себе логичные мысли: «А могу ли я засунуть свою виртуалку в облако, уже настроенную, чтобы она жила ТАМ, а НЕ ЗДЕСЬ?».
Вопрос, как я уже сказал, вполне себе справедливый и заслуживающий внимание — давайте с ним разберемся.
Действительно, Windows Azure Virtual Machines позволяет не только создавать ВМ из готовых образов, но и импортировать уже преднастроенные VHD-диски для их дальнейшей работы уже в публичном облаке Windows Azure. Это говорит о том, что вы можете полностью сконфигурировать и настроить виртуальную машину с необходимым вам ПО на гипервизоре Hyper-V локально в вашем ЦОДе — и уже в дальнейшем продолжить работы, что называется, «из вне».
И тут у любого опытного специалиста возникнет еще один, вполне себе, интересный вопрос: «ОК, я загрузил кастомный VHD, все работает — все огонь! Ну а если мне таких ВМ нужно залить 100 или 1000 — мне что их клонировать что ли и загружать их потом!? Вот если я сервак виртуальный sysprep'ом обработаю и загружу, смогу ли я потом этот диск из библиотеки клонировать?»
И вот тут возникает интересный момент: если вы «пропускаете» VHD-диск с предустановленной ОС и софтом, генерализируйте ОС — то фактически, с точки зрения Windows Azure не диск, но образ для развертывания следующих экземпляров ОС. Есть несколько моментов, которые следует учесть, если вы хотите импортировать не диск, а именно образ в Windows Azure:
1) Генерализация с помощью sysprep обязательна;
2) Ни в коем случае не делайте автоматическую установку с помощью файла unattended.xml — .т.е. просто не размещайте этот файл на целевом диске;
3) Не устанавливайте компоненты интеграции Windows Azure Integration Components внутрь VHD с ОС;
4) Не устанавливайте агента Windows Azure (Windows Azure Agent).
Чтобы было проще запомнить, предлагаю простую картинку:
Еще один важный момент — диски для импорта должны быть фиксированными (fixed), с точки зрения их размера и свойств расширяемости.
Проще говоря проще говорить и не получается — все действительно просто и интересно, если запомнить небольшие правила, про которые я вам сегодня рассказал. Единственное, что следует упомянуть — это то, что ровно так же как вы загружаете диски из ЦОД в публичное облако — вы также можете спокойно скачать VHD-диск и использовать его для работы в Hyper-V.
Наблюдательный читатель и гик спросит: «Стоп, а почему VHD, а не VHDX? Ведь формат-то более новый и перспективный?»
Ответ будет таким: на сегодняшний день мы можем предложить только импорт и экспорт VHD-дисков, но не VHDX. Со временем, конечно же, появиться и такая возможность.
При загрузке виртуального диска с помощью команды CSUpload вы можете произвести конвертацию диска в формат VHD при загрузке VM.
Ну что же, коллеги — на сегодня это все.
Надеюсь было лаконично и полезно!
Хорошей вам недели.
С уважением,
человек-огонь,
Георгий А. Гаджиев
Эксперт по информационной инфраструктуре
Microsoft Corporation.
Автор: GeorgyGadzhiev
