Сетевое подключение в Azure

<ServiceConfiguration serviceName="aCloudService">
  <Role> … </Role>
  <NetworkConfiguration>
    <AddressAssignments>
      <ReservedIPs>
        <ReservedIP name="anIPName"/>
      </ReservedIPs>
    </AddressAssignments>
  </NetworkConfiguration>
</ServiceConfiguration>

Балансировщик нагрузки Azure

VIP, связанные с облачной службой, размещаются в Azure Load Balancer, который анализирует трафик, поступающий на VIP, а затем перенаправляет трафик на соответствующую виртуальную машину в зависимости от объявлений конечных точек для виртуальных машин в облачной службе. Балансировщик нагрузки Azure перенаправляет трафик TCP и UDP только на виртуальные машины в облачной службе. Обратите внимание, что это означает, что невозможно пропинговать виртуальную машину Azure через Azure Load Balancer. Балансировщик нагрузки Azure поддерживает переадресацию портов и балансировку нагрузки на основе хеш-функций для облачных служб PaaS и IaaS. В официальном блоге группы разработчиков Azure есть сообщение с подробным обсуждением балансировщика нагрузки Azure.

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

При балансировке нагрузки на основе хеша Azure Load Balancer создает хэш исходного IP-адреса, исходного порта, IP-адреса назначения, целевого порта и протокола и использует хеш-код для выбора целевой виртуальной машины. Балансировка нагрузки на основе хэширования используется для распределения трафика между набором виртуальных машин без состояния, любая из которых может предоставлять желаемую услугу, например, веб-серверы. Обратите внимание, что распределение нагрузки на основе хеш-функции часто ошибочно описывается как «циклический перебор».

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

Балансировщик нагрузки Azure направляет трафик только на виртуальные машины, которые он считает работоспособными. Он использует настраиваемый датчик работоспособности для периодической проверки связи с виртуальными машинами, по которым он направляет трафик, и через ответ или его отсутствие определяет их состояние работоспособности. И облачные службы IaaS и PaaS поддерживают настраиваемые зонды работоспособности. Если для облачных служб PaaS не предоставлено настраиваемое подтверждение работоспособности, балансировщик нагрузки Azure отправляет эхо-запрос агенту Azure на экземпляр, который отвечает в работоспособном состоянии, когда экземпляр находится в состоянии готовности.

Настраиваемые зонды работоспособности настраиваются путем предоставления конечной точки TCP или HTTP. Балансировщик нагрузки Azure пропингует конечную точку и определяет исправное состояние с помощью TCP ACK или HTTP 200 OK. По умолчанию пинг происходит каждые 15 секунд, и виртуальная машина считается нездоровой, если соответствующий ответ не получен в течение 31 секунды. Приложение может предоставить свой собственный алгоритм при принятии решения, как реагировать на пинг.

Публичные IP-адреса уровня экземпляра

С каждым облачным сервисом, содержащим развертывание, связан один VIP. Azure также поддерживает связь публичного IP-адреса с отдельными виртуальными машинами и экземплярами облачных служб, развернутыми в региональной VNET. Instance-Level Public IP Address (PIP) может быть использован для поддержки услуг , такие как пассивный FTP , которые требуют открытия больших диапазонов портов , которые не возможно с облачным сервисом VIP. В настоящее время существует мягкое ограничение в размере двух PIP для каждой подписки.

Трафик, направленный на PIP, не проходит через стандартный балансировщик нагрузки Azure, а вместо этого направляется непосредственно на виртуальную машину. Это означает, что виртуальная машина подключена к Интернету, поэтому следует позаботиться о том, чтобы брандмауэр был настроен соответствующим образом. Балансировщик нагрузки Azure позволяет только трафику TCP и UDP достигать виртуальной машины. Однако трафик ICMP (т. Е. Ping) может быть успешно отправлен на ВМ с назначенным PIP.

PIP связан с виртуальной машиной IaaS с помощью командлета Set-AzurePublicIP PowerShell. Это изменяет конфигурацию виртуальной машины, которую затем можно использовать с New-AzureVM или Update-AzureVM для создания или обновления виртуальной машины соответственно. Remove-AzurePublicIP используется для удаления PIP из конфигурации VM , который затем должен быть применен к ВМ с Update-AzureVM .

Пипс связан со службой PaaS облака путем добавления PublicIPs тега к AddressAssignments секции конфигурации службы для службы:

<ServiceConfiguration serviceName="aCloudService">
  <Role> … </Role>
  <NetworkConfiguration>
    <AddressAssignments>
      <PublicIPs>
        <PublicIP name="aPublicIPName"/>
      </PublicIPs>
    </AddressAssignments>
   </NetworkConfiguration>
</ServiceConfiguration> 

Фактические PIP, назначенные виртуальным машинам в облачной службе, извлекаются с помощью командлета Get-AzureRole PowerShell следующим образом:

Get-AzureRole -ServiceName «aCloudService» -Slot Production
  -InstanceDetails

DIP для виртуальных машин и экземпляров облачных сервисов

Azure автоматически назначает динамические IP-адреса (DIP) виртуальным машинам в облачных службах IaaS и PaaS. DIP остается связанным с ВМ, пока он выделен. Когда виртуальная машина IaaS отменяется, DIP прекращается и может быть назначена новой виртуальной машине.

DIP, назначенный виртуальной машине, зависит от того, находится ли она в VNET. Если виртуальная машина отсутствует в VNET, DIP выделяется из диапазона DIP, управляемого Azure. Если виртуальная машина находится в сети VNET, DIP выделяется (последовательно) из диапазона DIP, настроенного для подсети, в которой она развернута. DIP выделяется через специальный тип DHCP, который обеспечивает по существу неограниченную аренду.

Виртуальная машина в облачной службе PaaS поддерживает DIP в течение всего времени его развертывания. Виртуальная машина в облачной службе IaaS сохраняет DIP, пока он выделен, но теряет его при отмене выделения. В этом случае DIP может быть назначен другой ВМ, и исходная ВМ может получить другой DIP, когда он снова выделен. Обратите внимание, что виртуальная машина сохраняет DIP, даже если он перенесен на новый физический сервер как часть операции восстановления сервера.

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

Статические IP-адреса для виртуальных машин IaaS Cloud Service

Azure поддерживает назначение статических IP-адресов виртуальным машинам, развернутым в облачной службе IaaS в VNET. Это полезно для виртуальных машин, предоставляющих такие услуги, как контроллер домена и DNS. Общее руководство заключается в том, что статические IP-адреса следует использовать только в случае особой необходимости.

Когда облачные службы IaaS и PaaS развертываются в VNET, необходимо позаботиться о том, чтобы не было шансов наложения между IP-адресами, выделенными экземплярам PaaS, и статическими IP-адресами, используемыми в облачной службе IaaS. Это создает вероятность того, что экземпляру PaaS будет выделен DIP, связанный с выделенной в данный момент виртуальной машиной IaaS. Лучше всего управлять этим путем выделения статического IP-адреса из подсети, содержащей только статические IP-адреса.

Статический IP-адрес связан с виртуальной машиной IaaS с помощью командлета Set-AzureStaticVNetIP PowerShell. Это изменяет конфигурацию виртуальной машины, которую затем можно использовать с New-AzureVM или Update-AzureVM для создания или обновления виртуальной машины соответственно. Remove-AzureStaticVNetIP используется для удаления экземпляра уровня общественной IP — адрес из конфигурации VM , который затем должен быть применен к ВМ с Update-A zureVM. Test-AzureStaticVNetIP командлет PowerShell можно использовать для проверки , является ли конкретный IP — адрес используется в данный момент.

Endpoints

Конечная точка в Azure относится к комбинации номера порта и протокола, настроенного для роли в облачной службе PaaS или виртуальной машины в облачной службе IaaS.

Для роли в облачной службе PaaS можно настроить три типа конечных точек :

• Входная конечная точка
• Конечная точка ввода экземпляра
• Внутренняя конечная точка

Оба типа входной конечной точки отображаются через балансировщик нагрузки Azure. Входная конечная точка используется для балансировки нагрузки на основе хеш-функции, а входная конечная точка экземпляра используется для переадресации портов. Внутренняя конечная точка предоставляет порт, адресуемый другими виртуальными машинами в облачной службе. Внутренние конечные точки обеспечивают обнаружение с помощью API среды выполнения Azure как DIP виртуальной машины, так и порта, фактически используемого на отдельных виртуальных машинах. Если это разрешено брандмауэром, любая виртуальная машина в VNET может подключаться к любой другой виртуальной машине в VNET независимо от облачной службы, если известны фактический DIP и номер порта для подключения.

Балансировщик нагрузки Azure предоставляет два типа конечных точек для виртуальной машины в облачной службе IaaS:

• Набор доступности с балансировкой нагрузки
• Перенаправление порта

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

Балансировщик нагрузки Azure направляет трафик на виртуальные машины или экземпляры в облачной службе, если была объявлена ​​соответствующая конечная точка. Обратите внимание, что трафик, отправляемый напрямую в PIP, полностью обходит балансировщик нагрузки. Балансировщик нагрузки Azure предоставляет возможность ACL , которая дополнительно ограничивает трафик, направляемый виртуальным машинам и экземплярам. Функция ACL позволяет настраивать набор правил принятия и отклонения для конечной точки, и балансировщик нагрузки Azure использует эти правила для принятия решения о том, следует ли направлять входящий трафик на виртуальные машины и экземпляры. Например, правило может быть сконфигурировано для маршрутизации трафика, поступающего с одного IP-адреса, например публичного IP-адреса компании.

Внутренний балансировщик нагрузки

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

Следующие командлеты PowerShell используются для управления внутренними балансировщиками нагрузки:

• Надстройка AzureInternalLoadBalancer
• Get-AzureInternalLoadBalancer
• Remove-AzureInternalLoadBalancer

Add-AzureInternalLoadBalancer используется для создания внутреннего балансировщика нагрузки в облачной службе. Внутренний балансировщик нагрузки идентифицируется по имени. Get-AzureInternalLoadBalancer извлекает имя и DIP внутреннего балансировщика нагрузки в облачной службе. Внутренний балансировщик нагрузки, который в данный момент не используется, можно удалить с помощью Remove-AzureInternalLoadBalancer .

Конечные точки с балансировкой нагрузки создаются на виртуальных машинах для балансировки нагрузки с помощью Set-AzureEndpoint в сочетании с New-AzureVM или Update-AzureVM в зависимости от того, существует ли виртуальная машина. Set-AzureEndpoint имеет два параметра для управления внутренним балансировщиком нагрузки: — InternalLoadBalancerName, который указывает используемый внутренний балансировщик нагрузки; и — LBSetName, который предоставляет имя для идентификации набора виртуальных машин, которые должны быть сбалансированы по нагрузке.

VPN

Azure поддерживает два типа VPN:

• Сайт-на-Site

• Точка-сайт

S2S ориентирован на предприятия и использует аппаратный или программный VPN-маршрутизатор на стороне клиента для совместного использования соединения многими пользователями. Azure предоставляет сценарии настройки маршрутизатора для многих стандартных маршрутизаторов Cisco и Juniper VPN.

P2S ориентирован на разработчиков и использует программное обеспечение RAS, которое поставляется с Windows. Аутентификация пользователя обеспечивается с помощью сертификатов X-509. Главный сертификат X.509 загружается на портал Azure и затем используется для создания пользовательских сертификатов X.509, которые затем распределяются индивидуально для каждого пользователя. Поэтому P2S прост в использовании для небольших доверенных групп разработчиков, но плохо масштабируется из-за невозможности отзыва пользовательских сертификатов.

Оба типа VPN подключаются к VPN-шлюзу, настроенному внутри Azure VNET. Этот шлюз полностью управляется Azure и развертывается способом HA. Трафик может маршрутизироваться в любом направлении через VPN, что позволяет выполнять такие вещи, как подключение внешней облачной службы PaaS к локальному SQL Server. Другим важным использованием VPN является возможность выполнять все администрирование системы через VPN без необходимости использования конечных точек SSH и RDP.

Можно настроить VPN между двумя региональными VNET, расположенными в разных регионах. Это делается путем создания VPN-шлюза в каждом регионе и перекрестных ссылок на диапазоны адресов для каждой VNET. VPN-трафик, проходящий через такую ​​VPN, направляется через магистраль Microsoft Azure, а не через общедоступный Интернет.

ExpressRoute

Microsoft работала с различными сетевыми партнерами, чтобы обеспечить прямое частное соединение с Azure с помощью функции ExpressRoute . Это приходит в двух вариантах:

• Биржевой провайдер
• Поставщик сетевых услуг

Поставщик Exchange предлагается такими хостинговыми компаниями, как Equinix и Level 3, в которых они предоставляют своим клиентам прямые подключения к Azure. В качестве альтернативы поставщики сетевых услуг, такие как AT & T и BT, обеспечивают подключение MPLS к Azure.

ExpressRoute обеспечивает прямое подключение к шлюзу Azure VPN, а затем к VNET, где размещается шлюз, и к любым облачным службам, размещенным в VNET. Он также предоставляет доступ к хранилищу Azure, но не к другим службам Azure, таким как база данных SQL Azure. ExpressRoute обеспечивает скорость до 1 Гбит / с во время предварительного просмотра, при этом этот предел увеличивается до 10 Гбит / с при переходе в режим GA.

DNS

Azure предоставляет службы разрешения имен для виртуальных машин в облачных службах IaaS и PaaS. Он также обеспечивает разрешение имен для 100 виртуальных машин в VNET при условии использования их полного доменного имени. В противном случае необходимо предоставить DNS-сервер, если необходимы службы разрешения имен. Это особенно относится к гибридным развертываниям, где локальные серверы должны связываться с виртуальными машинами Azure через VPN. DNS-сервер настраивается в файле конфигурации сети для подписки. DNS-сервер должен быть развернут со статическим DIP.

Azure Traffic Manager

Azure Traffic Manager обеспечивает глобальный трафик маршрутизации по направлениям как в Azure и в других местах. Он работает через динамическое сопоставление недолговечных записей DNS с реальными IP-адресами. Как только профиль Traffic Manager настроен, он предоставляет DNS-имя, такое как mydomain.trafficmanager.net , приложению, которое динамически сопоставляется с соответствующей записью DNS для фактической используемой облачной службы. Диспетчер трафика Azure можно использовать для маршрутизации трафика на веб-сайты за пределами Azure.

Диспетчер трафика предоставляет следующие варианты балансировки нагрузки:

• Производительность
• По-круговой
• Отказоустойчивость

Выбор «Производительность» означает, что приложение развертывается как отдельные облачные службы в нескольких географических местоположениях, например в каждом регионе Azure, и что пользователь, получающий доступ к приложению, должен автоматически перенаправляться в облачную службу с наименьшей задержкой. Внутренне Traffic Manager снабжен таблицами задержки для различных маршрутов через Интернет и использует эти таблицы при выборе маршрута для пользователя.

Выбор циклического перебора означает, что новые пользователи должны быть распределены между нижележащими облачными службами в циклическом порядке.

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

Резюме

Новая возможность Azure для региональных сетей VNET позволяет предоставлять широкий спектр сетевых служб, таких как внутренние балансировщики нагрузки, общедоступные IP-адреса на уровне экземпляров и возможности VNET-to-VNET VPN. В этом посте приведено краткое описание этих функций и описано, как они вписываются в существующие сетевые возможности платформы Azure.