Skip to content
August 29, 2012 / ahriman hpc mode

Пояснения по нововведениям в Windows Azure: Windows Azure Virtual Machines

Виртуальные машины являются новым сервисом, предоставляемым платформой Windows Azure, и они позволяют гораздо проще и гибче переносить локальные инфраструктуры в облако или создавать новые программные решения, которым критично постоянное хранилище (не чистящееся по каждой перезагрузке экземпляра выполнения). По сути, после 7 июня 2012 года Windows Azure сложно назвать SaaS, PaaS или какой бы то ни было платформой, теперь это скорее зонтичный термин,
объединяющий под собой множество аббревиатур. Это – шаг в IaaS.

clip_image001

Рис. 1. Шаг в IaaS

clip_image003

Рис. 2. Основные характеристики виртуальных машин

clip_image005

Рис. 3. Приложения виртуальных машин

К сценариям использования виртуальных машин в Windows Azure можно отнести практически все типы приложений, которые можно использовать в локальной инфраструктуре: бизнес-приложения, CRM, Active Directory, собственные приложения, а также позволяющие объединить локальную и облачную инфраструктуру, создав гибридное решение.

Отличия нового сервиса от остальных сервисов Windows Azure

Web Sites

Cloud Services

Virtual Machines

Модель использования

SaaS

PaaS

IaaS

Тип приложений

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

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

Сложные серверные приложения – например, SQL Server, Sharepoint Server. Приложения, которым необходимо сохранение состояния (stateful), организация ферм серверов, legacy-приложения.

Модель развертывания

· Quick Create – создание пустого сайта,

· Quick Create with Database – создание пустого сайта и ассоциированной с ним базы данных MySQL/Windows Azure SQL Database,

· Using the Gallery – создание сайта из подготовленного образа галереи образов Windows Azure Web Sites

· Web-роль – слой приложения, выполняющий роль веб-интерфейса, взаимодействующего с пользователем,

· Worker-роль – слой приложения, выполняющий роль обработчика данных.

Виртуальная машина.

Сложность миграции существующего приложения

Низкая. Существующее веб-приложение можно мигрировать в Web Sites без изменений.

Средняя/высокая. В зависимости от ситуации может быть необходимо переосмысление архитектуры существующего приложения для эффективного разделения на Web/Worker-роли.

Низкая. Любое существующее приложение может быть мигрировано в составе подготовленного образа.

Администрирование

Низкая степень контроля – масштабирование сервиса, сервисы FTP, Team Foundation Services, Git. Запуск веб-сайта (например, WordPress или Drupal) можно осуществить в несколько кликов мышкой.

Средняя степень контроля – администраторский доступ, доступ по удаленному рабочему столу RDP к экземплярам ролей, запуск кода с повышенными правами, start-up задачи. Возможна автоматизация администрирования.

Высокая степень контроля – пользователь самостоятельно подготавливает, загружает и обслуживает образ системы.

Возможность развертывания приложений с использованием Git/FTP

Да

Да

Поддержка дополнительных сервисов платформы

Caching, Service Bus, SQL Azure Database, CDN, Identity Federation, Traffic Management

Caching, Service Bus, SQL Azure Database, CDN, Identity Federation, Traffic Management, Connect/Windows Azure Network

Поддержка распространенных языков программирования

IIS-совместимые технологии, ASP.NET, ASP, Node.js, PHP

IIS-совместимые технологии, ASP.NET, ASP, Node.js, PHP

Поддержка MySQL

Встроенная, с использованием портала управления

Есть, но с использованием ClearDB. На портале управления интегрировать сервис с MySQL нельзя.

Ячейки развертывания (тестовая, production)

Нет

Да

Доступ по RDP

Нет

Да

Возможность интеграции сторонних фреймворков

Нет

Да

Ориентировочное время развертывания

Около минуты.

10-20 минут.

10-20 минут (+ задержка, связанная со скоростью интернет-подключения)

ОС

Windows Server

Windows Server

Windows Server/Linux

SLA

Так как функциональность находится в стадии Preview, SLA не предоставляется.

99.95%

99.9%

Отличия нового сервиса от VM-роли

clip_image007

Рис. 4. Отличия VM от VM-роли

После анонсирования нового сервиса возник вопрос – а чем он отличается от того, что мы видели раньше, а именно VM-роли в ролевой модели Cloud Services (тогда – Hosted Services). Давайте сначала посмотрим, что такое VM-роль.

VM-роль была введена в платформу для использования в тех случаях, когда возможностей Web/Worker-ролей было недостаточно для реализации определенных решений, таких, как, например, перенос сложных приложений в облако (Sharepoint, …). При этом не предоставлялось никаких SLA для операционной системы в виртуальной машине, так как пользователем загружался собственный VHD-диск. Однако SLA на сами виртуальные машины сохранялся – можно было загрузить две виртуальных машины и получить 99.95% SLA на доступность роли.

Однако, допустим, если вы загружали несколько виртуальных машин и с одной из виртуальных машин что-то происходило (например, аппаратный сбой), всё, что было на этой машине, пропадало – все уникальные данные, которые сохранялись на диск и в память, и прочее. Это происходило из-за того, что в ответ на ошибку Windows Azure разворачивало новую виртуальную машину, перед этим делая sysprep на образ, загруженный пользователем.

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

Итак, к отличиям относятся:

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

Типы развертывания. Вы должны были создать локально ваш VHD и загрузить в облако, после чего можно было его использовать. С новым сервисом же вы можете как создать и загрузить VHD, так и воспользоваться как им, так и любым другим доступным в галерее образов.

Настройка сети. Настройки для VM-роли необходимо было делать в сервисной модели, тогда как новый сервис виртуальных машин можно конфигурировать на портале управления Windows Azure и даже автоматизировать с помощью Powershell или скриптов.

clip_image009

Рис. 5. Жизненный цикл развертывания образа в облакоclip_image011

Рис.6. Жизненный цикл виртуальной машины в облаке

Архитектура виртуальных машин

В целом виртуальные машины Windows Azure основаны на сервисной модели, используемой Web/Worker-ролями уже давно, с серьезными модификациями – такими, как постоянное хранилище и один экземпляр=одна роль.

При создании виртуальной машины автоматически создаётся Cloud Service, который выступает в роли контейнера для данной виртуальной машины. При этом, если в Cloud Service есть две ячейки развертывания (Staging/Production), то в случае виртуальной машины она разворачивается только в Production (что означает, что VIP swap недоступен) (рис. 5).

clip_image013

Рис. 5. Cloud Service как контейнер для виртуальных машин

clip_image015

Рис. 6.

clip_image017

Рис. 7.

Что касается того, где же хранятся виртуальные машины, то это – страничные блобы в хранилище Windows Azure. При создании виртуальной машины VHD кладётся в страничный блоб с возможностью дальнейшей записи. При этом доступно несколько дисков:

· C: – операционная система;

· D: – физические данные на хранилище, которые не резервируются и используются только для временного хранения;

· E: – данные пользователя;

· F: – логи.

Максимальный размер операционной системы может быть до 127 гигабайт, но к виртуальной машине можно прицепить определенное количество (в зависимости от размера виртуальной машины) дополнительных дисков с данными (рис. 8), в том числе во время выполнения виртуальной машины.

clip_image018

Рис. 8. Размеры виртуальной машины

Виртуальные машины, расположенные в пределах одного Cloud Service, имеют прямой канал коммуникаций друг с другом – нет необходимости настраивать что-то отдельно, как в случае с раздельными виртуальными машинами, когда для того, чтобы обеспечить подключение, необходимо открывать порты в сервисной модели. Конечно, нельзя забывать о брандмауэрах на операционных системах. С этим всё понятно – нужно думать только о брандмауэрах и чётко их настраивать (так как на форумах периодически были вопросы о том, почему не «ходит» трафик). Что же, если нужно настроить так называемые конечные точки входа (endpoints)? Здесь также всё просто. Каждая конечная точка входа ассоциируется с виртуальной машиной и указывает, пропускать ли трафик.

К свойствам конечной точки входа относятся:

Имя – логическое имя в системе.

Протокол – tcp/udp

Локальный порт

Публичный порт

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

clip_image020

Рис. 9. Балансировка нагрузки и конечная точка входа в виртуальную машину

Как вы наверняка уже увидели, здесь есть простор для настройки форвардинга портов. Так как каждый Cloud Service имеет один публичный IP-адрес, но множество виртуальных машин внутри, форвардинг портов именно то, что нужно для того, чтобы извне получать доступ к конкретной машине (рис. 10).

clip_image022

Рис. 10. Форвардинг портов в Windows Azure Virtual Machines

Например, как на изображении под номером 5, для системы настроен форвардинг портов – внешний клиент, инициируя запрос на 5586, переходит на порт RDP (например) в виртуальную машину №1, инициируя же запрос на 5587, переходит на виртуальную машину №2, и так далее.

Виртуальные сети

Важнейшей функцией стало появление виртуальных сетей. Виртуальные сети (Virtual Networks) – это функциональность, позволяющая как соединить вашу локальную инфраструктуру с облачной, так и настроить сеть внутри развернутого сервиса. Если с первым сценарием всё более-менее понятно (необходимо VPN, поддерживающее Site-To-Site VPN), то какие преимущества даёт использование виртуальных сетей внутри развернутого сервиса? Во-первых, это сценарий постоянного IP (не статического, но постоянного). Когда нужно перенести Active Directory в Windows Azure, не использовать же стандартный режим, когда IP будет меняться? Здесь можно использовать VNET, с помощью которых можно определить общую схему IP-адресации для вашей облачной сети. Вы в этом случае определите адресное пространство, подсети и принадлежность виртуальных машин. Таким образом, каждая разворачиваемая виртуальная машина, принадлежащая определенной VNET, будет иметь один и тот же IP-адрес вне зависимости от её состояния (перезагрузки, других действий, приводящих к смене IP). Нестатическим этот IP является так как он не прописывается статикой (неоспоримый факт), а выдаётся как бы как DHCP с бесконечным временем лизинга. При этом, конечно же, может возникать вопрос о разрешении имён. По умолчанию никакого разрешения имён при помещении виртуальной машины в виртуальную сеть нет – считается, что вы сами этим озаботитесь. Тут есть три варианта разрешения проблемы: настроить DNS вручную на сетевом адаптере для каждой машины (основной недостаток, конечно же, во фразе «настроить для каждой»), определить DNS-сервера в конфигурации сети (что тоже неудобно, так как нет возможности переопределить DNS-сервера без необходимости переразвернуть добавленные виртуальные машины в виртуальную сеть) и указать DNS при первичном развертывании виртуальной машины (например, с помощью Powershell, что достаточно удобно).

clip_image024

Рис. 11. Гибридное решение с использованием виртуальных сетей

Для развертывания виртуальной машины в виртуальную сеть необходимо помнить несколько простых правил:

1) Нельзя перенести уже развернутую виртуальную машину, нужно разворачивать ее прямо в виртуальную сеть.

2) Настройки DNS – если не распланировать всё заранее, можно придти к тому, что для уже развернутой виртуальной машины нельзя будет изменить эти настройки без переразвертывания.

3) Каждой виртуальной сети нужна афинная группа. Кроме этого, аккаунт хранилища должен находиться в том же регионе, что и афинная группа, либо в этой афинной группе.

Доступность виртуальных машин и гарантии

У Cloud Services SLA как был 99.95%, так и остался, учитывая минимальное количество экземпляров приложения (оно равно двум). С виртуальными машинами ситуация немного запутаннее – было решено, что несколько виртуальных машин для большинства приложений не будет нужно, поэтому для одного экземпляра предлагается 99.9% SLA, если же используется Availability Set, то предлагается 99.95%.

Availability Set

Концепция Availability Set аналогична концепции доменов обновлений и доменов ошибок, но несколько расширяет её – виртуальные машины в AS физически расположены в разных реках (racks) и при обновлении хостовой операционной системы обновляются не все виртуальные машины в AS в одно время (рис. 12).

clip_image026

Рис. 12. Объединённая концепция доменов ошибок и обновлений и Availability Set

clip_image028

Рис.13. Наглядное изображение различных сценариев SLA

Что, собственно, позволяет реализовать отказоустойчивость и избыточность на всех уровнях.

clip_image030

Рис. 14. Отказоустойчивость на всех уровнях

clip_image032

Рис. 15. Что включено и что не включено в SLA Windows Azure Virtual Machines

Практика

Есть несколько методов создания виртуальной машины в Windows Azure, и мы рассмотрим все.

Виртуальная машина из образа

Собственно, самый простой и понятный метод – в облаке уже есть галерея образов, в которой на данный момент поддерживается определенный набор ОС (рис. 16). Обратите внимание, что этот список – из Preview-версии, то есть он будет постоянно пополняться даже, возможно, перейдя в Production.

clip_image034

Рис. 16. Галерея образов виртуальных машин

Давайте перейдём к практике. Войдите на портал управления Windows Azure (http://manage.windowsazure.com), используя учетные данные Windows Live ID (рис. 17).

clip_image036Рис. 17. Страница входа в систему

Войдя на портал управления (рис.18), нажмите кнопку New, расположенную в нижнем левом углу страницы, для открытия диалогового окна New form (рис. 19).

clip_image038

Рис. 18. Портал управления Windows Azure

Выберите в открывшемся диалоге Virtual Machine. Выберите From Gallery (рис. 19).clip_image040

Рис. 19. New form

Обратите внимание, что в диалоговом окне VM OS Selection есть четыре опции отображения – All (все образа), Platform Images (галерея образов на платформе), My Images (образа, предоставленные клиентом) и My Disks (диски виртуальных машин). Сейчас выберите Windows Server 2008 R2 SP1, July 2012 и нажмите Next.

В диалоговом окне VM Configuration (рис. 20) введите необходимые данные, выберите размер экземпляра (так как виртуальные машины требуют серьёзных ресурсов, выберите самый маленький экземпляр) и нажмите Next.

clip_image042

Рис. 20. Первоначальная конфигурация виртуальной машины

В диалоговом окне VM Mode (рис. 21) выберите Standalone Virtual Machine, так как у нас нет ни одной виртуальной машины. Введите DNS Name и выберите аккаунт хранилища и регион либо афинную группу либо виртуальную сеть. Нажмите Next.

clip_image044

Рис. 21. Первоначальные настройки виртуальной машины

Выберите Create Availability Set и введите имя. Нажмите Next для начала развертывания виртуальной машины. Через некоторое время виртуальная машина будет запущена.

Теперь давайте подключимся к созданной виртуальной машине по Remote Desktop Connection.

Перейдите на портал управления Windows Azure и выберите созданную виртуальную машину. Нажмите кнопку Connect в панели управления внизу. На самом деле это ссылка на файл подключения к вашей виртуальной машине, и после нажатия должен скачаться файл .rdp с именем виртуальной машины. Запустите его и введите пароль администратора.

Войдя на виртуальную машину, вы увидите интерфейс той ОС, которую сконфигурировали для данной виртуальной машины. Мы конфигурировали Windows Server 2008 R2.

Нажмите Add Roles. Нажмите Next. Выберите роль Web Server (IIS) – мы разместим в виртуальной машине IIS и создадим ферму веб-серверов из двух виртуальных серверов.

clip_image046

Рис. 22.

Нажмите Next и выберите все необходимые компоненты (рис. 23).

clip_image048

Рис. 23.

На этом закончим этот пункт и перейдём к следующему.

Создание из собственного образа
Второй способ создания виртуальной машины: создать собственный образ и развернуть виртуальные машины из него. Всё это можно сделать прямо на платформе – как только вы создали виртуальную машину из преднастроенного образа, вы можете как угодно её кастомизировать, после чего воспользоваться sysprep для Windows и waagent для Linux и нажать Capture, предварительно выключив эту виртуальную машину. Естественно, что осуществить этот процесс можно и в оффлайне, создав VHD и загрузив его с использованием csupload.exe из Windows Azure SDK 1.7.

Поскольку мы уже развернули виртуальную машину, воспользуемся ею.

Перейдите на созданную виртуальную машину по RDP и откройте директорию Windows\System32\sysprep. Запустите sysprep (рис. 24), выберите опцию generalize

и shutdown в качестве shutdown options. Нажмите ОК.

clip_image049

Рис.24. Интерфейс sysprep

После потери подключения к виртуальной машине подождите пару минут до ее выключения – следите за статусом машины на портале управления Windows Azure – после чего выберите виртуальную машину и нажмите на панели управления кнопку Capture.

В появившемся диалоговом окне введите имя образа. Отметьте опцию “I have sysprepped the virtual machine”. Нажмите ОК.

После окончания процесса созданная виртуальная машина будет удалена, но появится новый образ в разделе Images (рис. 25).

clip_image051

Рис. 25. Новый образ виртуальной машины

Теперь можно создать новую виртуальную машину.

Нажмите кнопку New, расположенную в нижнем левом углу страницы, для открытия диалогового окна New form. Выберите в открывшемся диалоге Virtual Machine. Выберите From Gallery. Выберите ваш образ (рис. 26).

clip_image053

Рис. 26. Галерея образов

На следующих страницах Configuration заполните необходимые поля (рис. 27, 28).

clip_image055

Рис. 27. Первоначальная настройка виртуальной машины

clip_image057

Рис. 28.

На странице Availability Sets выберите Create Availability Set. Нажмите ОК.

Создайте вторую виртуальную машину из того же образа, но на странице VM Mode отметьте Connect to existing virtual machine (рис. 29).

clip_image059

Рис. 29.

На странице Availability Sets выберите созданный ранее Set.

После того, как все будет создано и запущено, настройте для обеих машин конечные точки входа. Для этого перейдите на панель управления виртуальной машиной, на вкладку Endpoints. Нажмите Add Endpoint. На странице Specify Endpoint details (рис. 30) введите http, 80,80.

clip_image061

Рис. 30. Настройка конечной точки входа

Повторите настройку для второй виртуальной машины, указав на первой странице настройки Loadbalance traffic on an existing endpoint и выбрав созданную точку входа.

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

Загрузка собственного VHD

Третьей, и уже давно имеющейся в Windows Azure, опцией является загрузка существующей виртуальной машины в VHD-формате с использованием csupload.exe либо VHDupload из комплекта Windows Azure Training Kit. Мы воспользуемся первой опцией.

Откройте консоль Disk Management: в меню Start наберите в строке поиска diskmgmt.msc и нажмите Enter.

В консоли Disk Management откройте меню Action и выберите Create VHD.

В диалоговом окне Create and Attach Virtual Hard Disk нажмите Browse, укажите расположение и имя будущего диска, после чего нажмите Save. Укажите размер диска Virtual hard disk size как 16 MB, Virtual hard disk format как Fixed size, после чего нажмите OK для создания и подсоединения виртуального жесткого диска. Обратите внимание на размер диска – мы не будем в данном пункте создавать диск для операционной системы, мы создадим его как диск с данными, загрузим в облако, подключим к виртуальной машине и просмотрим его содержимое. Если же вы хотите создать диск с ОС, нет ничего проще – создайте диск большего размера, отформатируйте его в NTFS и загрузите в облако.

Перед использованием нового диска вы должны инициализировать его: щелкните правой кнопкой мыши на иконке диска для созданного диска в нижней панели Disk Management и нажмите Initialize Disk.

В диалоговом окне Initialize Disk убедитесь, что выбран диск, соответствующий подсоединенному VHD, укажите MBR (Master Boot Record) и нажмите OK.

Щелкните правой кнопкой мыши на неразмеченной Unallocated области подсоединенного виртуального жесткого диска и нажмите New Simple Volume. В New Simple Volume Wizard нажмите Next. На следующей странице оставьте значение Simple volume size таким же—оно должно совпадать с Maximum disk space—и нажмите Next. Назначьте букву диска и нажмите Next. Выберите тип форматирования новой партиции. Укажите File system как NTFS, оставьте стандартное значение Allocation unit size и определите Volume label как OurVHD. Убедитесь, что вы включили опцию Perform a quick format и оставили выключенной Enable file and folder compression. Нажмите Next.

Проверьте информацию на странице Summary и нажмите Finish для создания нового тома.

Дождитесь окончания форматирования, которое должно занять несколько секунд. При включенном AutoPlay вам будет задан вопрос, необходимо ли просмотреть подсоединенный диск. В этом случае нажмите Open folder to view files. Если вопрос задан не будет, щелкните правой кнопкой мыши на томе в консоли Disk Management и нажмите Open. Оставьте окно открытым. Скопируйте туда какие-нибудь файлы.

Переключитесь в консоль Disk Management, щелкните правой кнопкой мыши на подсоединенном диске— щелкните на диске, а не на области партиции – и нажмите Detach VHD.

В диалоговом окне Detach Virtual Hard Disk убедитесь, что опция Delete the virtual hard disk file after removing the disk отключена, после чего нажмите OK.

Теперь вам необходимо загрузить виртуальный жесткий диск (VHD) в хранилище Windows Azure. Напомню, что виртуальные жесткие диски хранятся в страничных блобах в Windows Azure, а также то, что загрузить или создать жесткий диск можно с помощью API библиотеки хранилища.

Перед загрузкой VHD вам необходимо определить имя и ключ доступа к аккаунту – для этого зайдите на портал управления и выберите подписку, в которой будет развернуто ваше приложение. Выберите сервис хранилища из списка сервисов и запишите значения имени name (первый сегмент URL точки входа) и ключ доступа Primary Access Key, нажав на кнопку View (для копирования ключа в буфер используйте кнопку Copy to Clipboard). На новом портале можно посмотреть ключи, перейдя на аккаунт хранилища и нажав Manage Keys.

clip_image063

Рис. 31. Просмотр информации аккаунта хранилища Windows Azure

Откройте с правами администратора Windows Azure Command Prompt и перейдите в папку bin – там будет утилита csupload, которой мы и воспользуемся для загрузки диска в облако.

Создайте сертификат с использованием утилиты makecert либо используя соответствующую оснастку в Visual Studio либо IIS.

makecert -sky exchange -r -n "CN=<CertificateName>" -pe -a sha1 -len 2048 -ss My "<CertificateName>.cer"

Загрузите его с использованием старого портала управления Windows Azure в хранилище сертификатов Management Certificates. Скопируйте thumbnail загруженного сертификата.Таким образом у вас должны быть следующие данные: ID подписки, thumbnail сертификата, ключ для хранилища и имя аккаунта хранилища.

Выполните последовательно следующие команды:

csupload Set-Connection "SubscriptionID=<Subscriptionid>;CertificateThumbprint=<Thumbprint>;ServiceManagementEndpoint=https://management.core.windows.net"

csupload.exe Add-Disk -Destination “http://[accountname].blob.core.windows.net/mydisks/mydisk.vhd" -Label ourvhd -LiteralPath "c:\temp\ourvhd.vhd"

Когда будет выведено сообщение «Diskourvhd.vhdis registered successfully», это будет означать, что ваш диск данных загружен в галерею образов.

Обратите внимание, что для загрузки образов виртуальных машин нужно пользоваться другими параметрами. Подробнее про csupload: http://msdn.microsoft.com/en-us/library/windowsazure/gg466228.aspx

Перейдите обратно на новый портал управления Windows Azure на панель управления какой-либо виртуальной машиной. Нажмите Attach и подсоедините диск из хранилища, после чего войдите на виртуальную машину по RDP и обратите внимание на увеличившееся количество дисков. Эта функция позволяет быстро загружать в облако огромные объемы данных, а также производить миграцию данных как в облако, так и из облака в локальную инфраструктуру.

Linux

А теперь давайте создадим виртуальную машину с Linux и подключимся к ней по SSH. Нет ничего проще. Повторите последовательность действий по созданию образа из галереи образов, но на этот раз выберите openSUSE 12.1. Не отмечайте различные дополнительные опции типа Upload SSH Keys.

Подключиться к свежесозданной виртуальной машине просто – по ssh, vnc или с использованием putty (Windows), чем мы и воспользуемся. Для подключения перейдите на панель управления виртуальной машиной и в панели Quick Glance (рис. 32) будут все данные для подключения.

clip_image065

Рис. 32. Панель данных Quick Glance

Теперь запустите Putty и заполните необходимые поля информацией, полученной из панели Quick Glance (рис. 33).

clip_image067

Рис. 33. Интерфейс Putty

Нажмите Open. На предупреждение безопасности нажмите Yes. Собственно, на этом всё – введите свои учетные данные администратора, и вы внутри виртуальной машины.

Для того, чтобы создать образ-болванку из этой виртуальной машины, вам придется воспользоваться Windows Azure Linux Agent (waagent –deprovision). Для этого выполните команду sudo /usr/sbin/waagentdeprovision (рис. 34).

clip_image069

Рис. 34. Генерализация образа

Выключите виртуальную машину, воспользовавшись кнопкой Shutdown на панели управления виртуальной машиной. После выключения нажмите Capture. Все остальные действия идентичны тому, что мы выполняли для Windows-машины. Как вы понимаете, мы можем легко настроить балансировку нагрузки и для Linux-машин.

Резюме

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: