Привет всем!

Меня в последнее время много спрашивают о сетевом взаимодействии в Azure и о том, как можно получить статические адреса на виртуальные машины. Ответ по сути своей прост, но я хочу написать отдельную статью на эту тему. В текущей статье я попробую дать чуть более глубокое понимание IP адресов для виртуальных машин и облачных сервисов. Еще раз хочу обратить внимание, все что я буду сейчас говорить, а точнее описывать, будет работать абсолютно одинаково как для виртуальных машин, так и для облачных сервисов (веб/воркер ролей), но настраивать это нужно по разному. Для простоты написания статьи я буду приводить все примеры настройки IP адресов только для виртуальных машин. Если будет необходимость показать примеры для облачных сервисов (веб/воркер ролей), то пишите об этом в комментариях и я это сделаю.

Azure и IP адреса — пролог.

Начнем мы с вами с того, что еще раз посмотрим из чего состоят наши виртуальные машины и облачные сервисы.

Самое важное в этой схеме то, что каждая виртуальная машина или экземпляр облачного сервиса имеют ровно одну сетевую карту. Это правило работает абсолютно для всех вариантов использования разных IP адресов (по крайней мере это было так на момент написания статьи). Следовательно, ваша машина всегда видит только одну сетевую карту и у нее всегда серый IP адрес. Но, на самом деле, подключиться к машине можно любым из трех возможных способов — через внутренний IP адрес, через внешний выделенный IP адрес, через IP адрес балансировщика нагрузки. Вся эта невероятная магия становится нам доступна благодаря разным способам сетевой комутации (хоть данная статья и не совсем об этом).

Начнем с простого — внутренний IP.

Это и правда самый простой для понимания IP адрес. В разных документах его могут называть по разному (Internal IP, Static IP, …), но его суть от этого не меняется. Это тот IP адрес, который висит на внутреннем интерфейсе и который можно увидеть явно в настройках сетевой карты нашей машины. Этот IP адрес всегда выдается из серого диапазона и использовать его можно только для комуникации внутри одного облачного сервиса (если вы не используете виртуальную сеть) или внутри виртуальной сети (если таковая используется). Также, дополнительным преимуществом использования виртуальной сети является то, что вы можете управлять тем, какие именно адреса будет получать каждая машина, другими словами — вы можете влиять на DHCP сервер.

Вот так это можно сделать при помощи PowerShell

Get-AzureVM -ServiceName StaticDemo -Name VM2 `
| Set-AzureStaticVNetIP -IPAddress 192.168.4.7 `
| Update-AzureVM

Таким образом мы можем размещать в облаке ресурсы, которые требуют внутренней статической адресации, например DNS сервера и/или другие подобные им сервисы.

Также привычная вещь — виртуальный IP балансировщика нагрузки.

Эта штука чуть сложнее, но она уже могла стать привычной для пользователей Azure. Всем хорошо известно, что даже при условии единичного экземпляра, любая виртуальная машина стоит за балансировщиком нагрузки. Просто смиритесь с этим фактом. У нашего балансировщика тоже есть свой IP адрес и он выдается из белого диапазона. Этот IP адрес на балансировщике всегда один и все машины, которые стоят за ним, всегда выходят в сеть под этим IP адресом. Но балансировщик коварен и при работе с ним нужно всегда помнить о следующих аспектах:

1. Балансировщик всегда работает в режиме NAT и умеет открывать входящие порты по двум принципам работы:

* Прямой проброс.

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

* Балансировка.

В этом режиме мы вибираем внешний порт и внутренний порт, после чего создается правило (или скорее шлюз) балансировки. После создания шлюза балансировки к нему подлкючаются виртуальные машины. Этот режим удобно использовать для балансировки нагрузки между IIS серверами, которые обслуживают наши сайты. Тут также нужно отметить одну важную деталь — нас никто не заставляет включать все машины из облачного сервиса в это правило балансировки. Допустим у меня есть 2 машины, на которых стоит IIS и еще 2 машины для SQL сервера. Я могу спокойно пробросить порт 80 только на первые две машины. Также нужно добавить, что можно смело создавать подобные правила для одной машины. С первого взгляда это очень похоже на вариант прямого проброса, но это дает нам шанс в будущем добавить еще сервер в ферму и масштабироваться горизонтально.

2. Балансировщик может создать не больше чем 150 правил, другими словами — он не может открыть больше 150 внешних портов одновременно. Это делает, например, создание FTP сервера довольно трудновыполнимой задачей.

3. Балансировщик всегда сохраняет свое доменное имя, НО он далеко не всегда сохраняет свой IP адрес. Это пожалуй самый подлый фортель, который вам может подкинуть балансировщик и о нем очень важно знать.

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

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

Вот так это можно сделать при помощи PowerShell

# сперва резервируем себе IP адрес
New-AzureReservedIP –ReservedIPName “MyReservedIP” –Label “ReservedIPLabel” –Location “East US”

# но его можно использовать только при создании нового облачного сервиса
New-AzureVMConfig -Name "CloudServer1" -InstanceSize “Small” –ImageName “Name_of_image” `
| Add-AzureProvisioningConfig -Windows -AdminUsername “cloudadmin” -Password “ABC123” `
| New-AzureVM -ServiceName "MyCloudServers" –ReservedIPName “MyReservedIP” -Location "East US"

Тут также стоит отметить важную деталь — вы не можете сказать «хочу чтобы этот IP адрес стал зарезервированным», так как временные и постоянные адреса для балансировщика идут из разных диапазонов. Таким образом, как только вы принимаете решение сменить ваш IP адрес на зарезервированный, или наоборот — отказать от него, — вы должны понимать что это обязательно приведет к изменению текущего IP адреса вашего балансировщика.

И на закуску — выделенный публичный IP.

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

При работе с балансировщиком у нас всегда есть ограничение на одновременное использование до 150 входящих портов. И это сейчас, а раньше их было всего 25. Как я уже говорил, это заставляет нас очень сильно страдать при попытке сконфигурировать FTP сервер или что-то похожее. Но тут в игру вступает выделенный публичный IP адрес, который всегда отличный от адреса балансировщика и всегда ходит в обход всех его правил. Весь исходящий трафик для виртуальной машины будет проходить через выделенный публичный IP адрес (если таковой имеется). Также на выделенном публичном IP адресе нет ограничения по количеству открытых портов, что важно для конфигурации нашего FTP сервера.

Для того, чтобы запросить выделенный публичный IP адрес при помощи PowerShell, нужно выполнить

# резервируем выделенный публичный IP адрес
Get-AzureVM -ServiceName FTPInAzure -Name FTPInstance `
| Set-AzurePublicIP -PublicIPName ftpip `
| Update-AzureVM

# но его нельзя увидеть с портала, так что будем смотреть тут
Get-AzureRole -ServiceName FTPInAzure -Slot Production -InstanceDetails

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