Виртуальные машины в Windows Azure

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

Публичные облачные платформы предоставляют возможность пользователям использовать размещенные в них ресурсы для собственных нужд. Подобное предложение называется Infrastructure as a Service (IaaS), и клиенты, использующие это предложение, оплачивают только те ресурсы, которые используют, и не зависят от технического персонала, которому необходимо время на развертывание и поддержку ресурсов.

Windows Azure Virtual Machines – это сервис, который представляет собой предложение Infrastructure-as-a-Service на платформе Windows Azure. Отличие этого метода поставки от остальных заключается в том, что, если пользователь создает виртуальную машину, именно он становится ответственным за все рутинные задачи по обновлению, настройке программного обеспечения, поддержке и т.д., операционной системы, но не низлежащего аппаратного стека и стека виртуализации – эти аспекты по-прежнему находятся под управлением вендора, предоставляющего облачную услугу. Если требуется вмешательство разработчика в процесс миграции или создания инфраструктуры на основе виртуальных машин, то это уже не чистый метод IaaS, но симбиоз IaaS и PaaS. Наиболее распространенными сценариями использования Windows Azure Virtual Machines являются:

Для развертывания виртуальной машины с помощью Windows Azure Virtual Machines можно использовать один из трех методов:

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

Размер экземпляров, выполняющих виртуальные машины, отличается по основным параметрам. Самый маленький экземпляр типа Extra Small разделяет ресурсы центрального процессора с экземплярами других пользователей.

В галерее преднастроенных образов доступен широкий выбор дистрибутивов как Microsoft, так и Linux. В галерее образов на 9.07.2013 доступны образы следующих операционных систем:

Windows Server

SQL Server

BizTalk

SharePoint

Visual Studio

Linux

В приведенном списке присутствует Visual Studio 2013. Ещё один из сценариев для Windows Azure Virtual Machines – использование виртуальной машины для разработки. Вместо того, чтобы устанавливать новый программный продукт, используемый в процессе разработки, программист может за несколько минут получить работающую виртуальную машину и проверить, подходит ли для его задач новая версия.

В 2013 году было представлено новое хранилище образцов виртуальных машин — VM Depot. VM Depot — это проект для сообщества Windows Azure, запущенный командой Microsoft Open Technologies, Inc, ответственной за открытые технологии внутри Microsoft. Содержимое портала, а также настроенные для разных задач виртуальные машины, создаётся и публикуется силами сообщества.

Перенос сервера в облако

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

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

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

Виртуальные машины Windows Azure основаны на сервисной модели, аналогичной той, которую используют Cloud Services, но с определенными контекстными усовершенствованиями – такими, как, например, постоянное хранилище.

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

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

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

Виртуальные машины, расположенные в пределах одного Cloud Service, имеют прямой канал коммуникаций друг с другом, что означает отсутствие необходимости настраивать что-то отдельно, как в случае с раздельными виртуальными машинами, когда для того, чтобы обеспечить подключение, необходимо открывать порты в сервисной модели (и настраивать брандмауэры в операционных системах) Портами в терминологии Windows Azure Virtual Machines можно назвать конечные точки входа.

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

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

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

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

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

Кроме этого, очень важным аспектом конечных точек виртуальных машин Windows Azure является наличие автоматических проб, которые бывают TCP и HTTP и задаются при создании точки. Автоматические пробы берутся балансировщиком нагрузки. По умолчанию тип пробы указан в TCP, что означает, что балансировщик нагрузки будет посылать TCP-пробу на указанный порт и, если ему не будет возвращен соответствующий ответ, то узел будет помечен как недоступный и он будет извлечен из ротации балансировщика, что означает, что трафик маршрутизироваться на этот узел больше не будет (до тех пор, пока узел не станет работоспособным). Аналогичную функциональность предоставляет HTTP-проба, которая даёт также возможность указать свойство ProbePath – относительный HTTP URL на веб-сервере, который будет отвечать кодом HTTP 200, если сервер в порядке, и любым другим, если сервер должен быть извлечен из ротации балансировщика. Использование HTTP-пробы позволяет разместить на веб-сервере специальную страницу со статусом виртуальной машины. Данная страница не должна содержать аутентификацию, так как проба не несёт в себе данных, которые могут использоваться для входа в систему. Все эти действия могут быть также совершены с помощью скриптов Powershell.

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

Виртуальные сети (Virtual Networks) – это функциональность, позволяющая как соединить вашу локальную инфраструктуру с облачной, так и настроить сеть внутри развернутого сервиса. Использование виртуальных сетей внутри развернутого сервиса даёт преимущество постоянного IP (не статического, но постоянного). Данный сценарий полезен тогда, когда, например, необходимо частично перенести инфраструктуру под управлением Active Directory в Windows Azure. Каждая разворачиваемая виртуальная машина, принадлежащая определенной VNET, будет иметь один и тот же IP-адрес вне зависимости от её состояния (перезагрузки, других действий, приводящих к смене IP). Данный IP не является статическим, но выдается DHCP с бесконечным временем аренды-лизинга. Для реализации разрешения доменных имён внутри виртуальной сети есть три способа:

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

Availability Set

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

Выключение виртуальной машины в Windows Azure

Процесс выключения виртуальной машины в Windows Azure несёт в себе несколько особенностей, в частности, от способа выключения зависит, будет ли взиматься оплата за виртуальные машины в состоянии простоя или нет. Доступно три способа выключения виртуальной машины:

Все три способа гарантируют безопасное выключение виртуальной машины.

Выключение с помощью портала управления

Для того, чтобы выключить виртуальную машину с портала управления, достаточно выбрать ее и нажать кнопку Shutdown. После этого виртуальная машина будет безопасно выключена и ресурсы, на которых она расположена, будут освобождены. По этой причине статус виртуальной машины в выключенном с портала управления состоянии является Stopped (Deallocated). Это состояние означает, что виртуальная машина больше не ассоциирована с ресурсами, выделяемыми платформой, и пользователь не оплачивает время, которое виртуальная машина находится в этом состоянии. После возвращения из остановленного состояния виртуальная машина получит другой IP-адрес. Сохранение IP-адреса можно обеспечить с помощью виртуальной сети и, если запускать виртуальные машины в том же порядке, в котором они были изначально развернуты, им будут присвоены исходные IP-адреса.

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

Выключение изнутри

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

Выключение с помощью командлета PowerShell

Для того, чтобы выключить виртуальную машину с помощью PowerShell в одном из двух режимов (деаллокации или простой остановке), необходимо воспользоваться командлетом Stop-AzureVM. В новой версии модуля Windows Azure PowerShell был добавлен специальный параметр – StayProvisioned, который позволяет указать, необходимо ли деаллоцировать виртуальную машину либо выполнить простую остановку.

Гибридная инфраструктура – взаимодействие с корпоративной сетью

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

Для целей обеспечения взаимодействия корпоративной и облачной инфраструктур предназначена часть программного обеспечения Microsoft System Center 2012, называющаяся AppController, с помощью которой можно загружать VHD из локальных ресурсов Hyper-V на платформу Windows Azure, скачивать данные и многое другое.

Заключение

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

Однако ни одна миграция не должна выполняться без предварительного планирования – для этого могут быть использованы как собственные аналитические средства и инструменты, так и инструмент Microsoft Assessment and Planning Toolkit 8, с помощью которого можно логически инвентаризовать ресурсы, которые планируется мигрировать, и получить автоматический отчёт с рекомендациями по процессу миграции.