Windows Azure Virtual Machines — обзор новой функциональности

В ближайшее время мы будем рассматривать очередной аспект новой функциональности 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. jj215568Каждой виртуальной сети нужна афинная группа. Кроме этого, аккаунт хранилища должен находиться в том же регионе, что и афинная группа, либо в этой афинной группе.

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

У 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