Добрый день, уважаемые коллеги.
В ближайшее время мы будем рассматривать очередной аспект новой функциональности Windows Azure – виртуальные машины. Виртуальные машины являются новым сервисом, предоставляемым платформой Windows Azure, и они позволяют гораздо проще и гибче переносить локальные инфраструктуры в облако или создавать новые программные решения, которым критично постоянное хранилище (не чистящееся по каждой перезагрузке экземпляра выполнения)
Что вы увидите в этой статье?
1. Отличия нового сервиса от VM-роли
2, Архитектура виртуальных машин
3. Виртуальные сети
4. Доступность виртуальных машин и гарантии
Практика — создание фермы веб-серверов в Windows Azure
Windows Azure Virtual Machines
Виртуальные машины являются новым сервисом, предоставляемым платформой Windows Azure, и они позволяют гораздо проще и гибче переносить локальные инфраструктуры в облако или создавать новые программные решения, которым критично постоянное хранилище (не чистящееся по каждой перезагрузке экземпляра выполнения). По сути, после 7 июня 2012 года Windows Azure сложно назвать SaaS, PaaS или какой бы то ни было платформой, теперь это скорее зонтичный термин, объединяющий под собой множество аббревиатур.
К сценариям использования виртуальных машин в Windows Azure можно отнести практически все типы приложений, которые можно использовать в локальной инфраструктуре: бизнес-приложения, CRM, Active Directory, собственные приложения, а также позволяющие объединить локальную и облачную инфраструктуру, создав гибридное решение.
Отличия нового сервиса от VM-роли
Рис. 1. Отличия 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 или скриптов.
Рис.2. Жизненный цикл виртуальной машины в облаке
Архитектура виртуальных машин
В целом виртуальные машины Windows Azure основаны на сервисной модели, используемой Web/Worker-ролями уже давно, с серьезными модификациями – такими, как постоянное хранилище и один экземпляр=одна роль.
При создании виртуальной машины автоматически создаётся Cloud Service, который выступает в роли контейнера для данной виртуальной машины. При этом, если в Cloud Service есть две ячейки развертывания (Staging/Production), то в случае виртуальной машины она разворачивается только в Production (что означает, что VIP swap недоступен) (рис. 3).
Рис. 3. Cloud Service как контейнер для виртуальных машин
Рис. 4.
Что касается того, где же хранятся виртуальные машины, то это – страничные блобы в хранилище Windows Azure. При создании виртуальной машины VHD кладётся в страничный блоб с возможностью дальнейшей записи. При этом доступно несколько дисков:
- C: — операционная система;
- D: — физические данные на хранилище, которые не резервируются и используются только для временного хранения;
- E: — данные пользователя;
- F: — логи.
Максимальный размер операционной системы может быть до 127 гигабайт, но к виртуальной машине можно прицепить определенное количество (в зависимости от размера виртуальной машины) дополнительных дисков с данными (рис. 8), в том числе во время выполнения виртуальной машины.
Рис. 5. Размеры виртуальной машины
Виртуальные машины, расположенные в пределах одного Cloud Service, имеют прямой канал коммуникаций друг с другом – нет необходимости настраивать что-то отдельно, как в случае с раздельными виртуальными машинами, когда для того, чтобы обеспечить подключение, необходимо открывать порты в сервисной модели. Конечно, нельзя забывать о брандмауэрах на операционных системах. С этим всё понятно – нужно думать только о брандмауэрах и чётко их настраивать (так как на форумах периодически были вопросы о том, почему не «ходит» трафик). Что же, если нужно настроить так называемые конечные точки входа (endpoints)? Здесь также всё просто. Каждая конечная точка входа ассоциируется с виртуальной машиной и указывает, пропускать ли трафик.
К свойствам конечной точки входа относятся:
Имя – логическое имя в системе.
Протокол – tcp/udp
Локальный порт
Публичный порт
Сконфигурировать же порт балансировки нагрузки (рис. 9), т.е. тот, на который будет приходить пользователь и уже потом направляться на одну из виртуальных машин в наборе, можно с помощью определения одной точки входа на всех необходимых виртуальных машинах и специального свойства LoadBalancedEndpointSetName.
Рис. 6. Балансировка нагрузки и конечная точка входа в виртуальную машину
Как вы наверняка уже увидели, здесь есть простор для настройки форвардинга портов. Так как каждый Cloud Service имеет один публичный IP-адрес, но множество виртуальных машин внутри, форвардинг портов именно то, что нужно для того, чтобы извне получать доступ к конкретной машине (рис. 7).
Рис. 7. Форвардинг портов в 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, что достаточно удобно).
Рис. 8. Гибридное решение с использованием виртуальных сетей
Для развертывания виртуальной машины в виртуальную сеть необходимо помнить несколько простых правил:
1) Нельзя перенести уже развернутую виртуальную машину, нужно разворачивать ее прямо в виртуальную сеть.
2) Настройки DNS – если не распланировать всё заранее, можно придти к тому, что для уже развернутой виртуальной машины нельзя будет изменить эти настройки без переразвертывания.
3) Каждой виртуальной сети нужна афинная группа. Кроме этого, аккаунт хранилища должен находиться в том же регионе, что и афинная группа, либо в этой афинной группе.
Доступность виртуальных машин и гарантии
У Cloud Services SLA как был 99.95%, так и остался, учитывая минимальное количество экземпляров приложения (оно равно двум). С виртуальными машинами ситуация немного запутаннее – было решено, что несколько виртуальных машин для большинства приложений не будет нужно, поэтому для одного экземпляра предлагается 99.9% SLA, если же используется Availability Set, то предлагается 99.95%.
Availability Set
Концепция Availability Set аналогична концепции доменов обновлений и доменов ошибок, но несколько расширяет её – виртуальные машины в AS физически расположены в разных реках (racks) и при обновлении хостовой операционной системы обновляются не все виртуальные машины в AS в одно время (рис. 9).
Рис. 9. Объединённая концепция доменов ошибок и обновлений и Availability Set
Рис.10. Наглядное изображение различных сценариев SLA
Что, собственно, позволяет реализовать отказоустойчивость и избыточность на всех уровнях.
Рис. 11. Отказоустойчивость на всех уровнях
Рис. 12. Что включено и что не включено в SLA Windows Azure Virtual Machines
Практика
Есть несколько методов создания виртуальной машины в Windows Azure, и мы рассмотрим все.
Виртуальная машина из образа
Собственно, самый простой и понятный метод – в облаке уже есть галерея образов, в которой на данный момент поддерживается определенный набор ОС (рис. 16). Обратите внимание, что этот список – из Preview-версии, то есть он будет постоянно пополняться даже, возможно, перейдя в Production.
Рис. 13. Галерея образов виртуальных машин
Давайте перейдём к практике. Войдите на портал управления WindowsAzure (http://manage.windowsazure.com), используя учетные данные WindowsLiveID (рис. 14).
Рис. 14. Страница входа в систему
Войдя на портал управления (рис.15), нажмите кнопку New, расположенную в нижнем левом углу страницы, для открытия диалогового окна Newform (рис. 16).
Рис. 15. Портал управления Windows Azure
Выберите в открывшемся диалоге VirtualMachine. Выберите From Gallery (рис. 16).
Рис. 16. New form
Обратите внимание, что в диалоговом окне VMOSSelection есть четыре опции отображения – All (все образа), Platform Images (галерея образов на платформе), My Images (образа, предоставленные клиентом) и My Disks (диски виртуальных машин). Сейчас выберите Windows Server 2008 R2 SP1, July 2012 и нажмите Next.
В диалоговом окне VMConfiguration (рис. 17) введите необходимые данные, выберите размер экземпляра (так как виртуальные машины требуют серьёзных ресурсов, выберите самый маленький экземпляр) и нажмите Next.
Рис. 17. Первоначальная конфигурация виртуальной машины
В диалоговом окне VMMode (рис. 18) выберите StandaloneVirtualMachine, так как у нас нет ни одной виртуальной машины. Введите DNSName и выберите аккаунт хранилища и регион либо афинную группу либо виртуальную сеть. Нажмите Next.
Рис. 18. Первоначальные настройки виртуальной машины
Выберите CreateAvailabilitySet и введите имя. Нажмите Next для начала развертывания виртуальной машины. Через некоторое время виртуальная машина будет запущена.
Теперь давайте подключимся к созданной виртуальной машине по Remote Desktop Connection.
Перейдите на портал управления Windows Azure и выберите созданную виртуальную машину. Нажмите кнопку Connect в панели управления внизу. На самом деле это ссылка на файл подключения к вашей виртуальной машине, и после нажатия должен скачаться файл .rdp с именем виртуальной машины. Запустите его и введите пароль администратора.
Войдя на виртуальную машину, вы увидите интерфейс той ОС, которую сконфигурировали для данной виртуальной машины. Мы конфигурировали Windows Server 2008 R2.
Нажмите AddRoles. Нажмите Next. Выберите роль WebServer (IIS) – мы разместим в виртуальной машине IIS и создадим ферму веб-серверов из двух виртуальных серверов.
Рис. 22.
Нажмите Next и выберите все необходимые компоненты (рис. 19).
Рис. 19.
На этом закончим этот пункт и перейдём к следующему.
Создание из собственного образа
Второй способ создания виртуальной машины: создать собственный образ и развернуть виртуальные машины из него. Всё это можно сделать прямо на платформе – как только вы создали виртуальную машину из преднастроенного образа, вы можете как угодно её кастомизировать, после чего воспользоваться sysprep для Windows и waagent для Linux и нажать Capture, предварительно выключив эту виртуальную машину. Естественно, что осуществить этот процесс можно и в оффлайне, создав VHD и загрузив его с использованием csupload.exe из Windows Azure SDK 1.7.
Поскольку мы уже развернули виртуальную машину, воспользуемся ею.
Перейдите на созданную виртуальную машину по RDP и откройте директорию WindowsSystem32sysprep. Запустите sysprep (рис. 20), выберите опцию generalize
и shutdownв качестве shutdownoptions. Нажмите ОК.
Рис.20. Интерфейс sysprep
После потери подключения к виртуальной машине подождите пару минут до ее выключения – следите за статусом машины на портале управления Windows Azure – после чего выберите виртуальную машину и нажмите на панели управления кнопку Capture.
В появившемся диалоговом окне введите имя образа. Отметьте опцию “I have sysprepped the virtual machine”. Нажмите ОК.
После окончания процесса созданная виртуальная машина будет удалена, но появится новый образ в разделе Images(рис. 21).
Рис. 21. Новый образ виртуальной машины
Теперь можно создать новую виртуальную машину.
Нажмите кнопку New, расположенную в нижнем левом углу страницы, для открытия диалогового окна Newform. Выберите в открывшемся диалоге VirtualMachine. Выберите FromGallery. Выберите ваш образ (рис. 22).
Рис. 22. Галерея образов
На следующих страницах Configuration заполните необходимые поля (рис. 23, 24).
Рис. 23. Первоначальная настройка виртуальной машины
Рис. 24.
На странице Availability Sets выберите Create Availability Set. Нажмите ОК.
Создайте вторую виртуальную машину из того же образа, но на странице VMMode отметьте Connecttoexistingvirtualmachine (рис. 25).
Рис. 25.
На странице AvailabilitySets выберите созданный ранее Set.
После того, как все будет создано и запущено, настройте для обеих машин конечные точки входа. Для этого перейдите на панель управления виртуальной машиной, на вкладку Endpoints. Нажмите AddEndpoint. На странице SpecifyEndpointdetails (рис. 26) введите http, 80,80.
Рис. 27. Настройка конечной точки входа
Повторите настройку для второй виртуальной машины, указав на первой странице настройки Load-balancetrafficonanexistingendpoint и выбрав созданную точку входа.
Дождитесь окончания процессов обновления и нажмите на ссылку в поле DNSName, чтобы убедиться в том, что 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). На новом портале можно посмотреть ключи, перейдя на аккаунт хранилища и нажав ManageKeys.
Рис. 28. Просмотр информации аккаунта хранилища 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:tempourvhd.vhd»
Когда будет выведено сообщение «Disk ‘ourvhd.vhd’ isregisteredsuccessfully», это будет означать, что ваш диск данных загружен в галерею образов.
Обратите внимание, что для загрузки образов виртуальных машин нужно пользоваться другими параметрами. Подробнее про csupload: 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), чем мы и воспользуемся. Для подключения перейдите на панель управления виртуальной машиной и в панели QuickGlance (рис. 29) будут все данные для подключения.
Рис. 29. Панель данных Quick Glance
Теперь запустите Putty и заполните необходимые поля информацией, полученной из панели QuickGlance (рис. 30).
Рис. 30. Интерфейс Putty
Нажмите Open. На предупреждение безопасности нажмите Yes. Собственно, на этом всё – введите свои учетные данные администратора, и вы внутри виртуальной машины.
Для того, чтобы создать образ-болванку из этой виртуальной машины, вам придется воспользоваться Windows Azure Linux Agent (waagent –deprovision). Для этого выполните команду sudo /usr/sbin/waagent –deprovision(рис. 31).
Рис. 31. Генерализация образа
Выключите виртуальную машину, воспользовавшись кнопкой Shutdown на панели управления виртуальной машиной. После выключения нажмите Capture. Все остальные действия идентичны тому, что мы выполняли для Windows-машины. Как вы понимаете, мы можем легко настроить балансировку нагрузки и для Linux-машин.
Резюме
В целом с запуском новой функциональности виртуальных машин и виртуальных сетей стало гораздо больше возможностей по простой миграции существующих локальных инфраструктур в облако, при этом осталась возможность частичной миграции и дальнейшего объединения частей инфраструктуры с помощью виртуальных сетей.
Автор: ahriman
