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

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

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

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

Рис. 15.3. Архитектура Cloud Service

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

• C: - операционная система;
• D: - физические данные на хранилище, которые не резервируются и используются только для временного хранения;
• E: - данные пользователя;
• F: - логи.

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

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

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

• Имя – логическое имя в системе.
• Протокол – tcp/udp.
• Локальный порт – порт внутри Windows Azure.
• Публичный порт – внешний порт, используемый клиентами.

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

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

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

Рис. 15.4. Перенаправление запросов

Например, для системы может быть настроено перенаправление портов – внешний клиент, инициируя запрос на 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 с бесконечным временем аренды-лизинга. Для реализации разрешения доменных имён внутри виртуальной сети есть три способа:

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

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

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

Availability Set

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