Этап разработки 1. Подключение тивность с локальными сайтами

Подключение тивность с локальными центрами обработки данных является наиболее важной областью проектирования для Решение Azure VMware сети. Основные требования, которые необходимо устранить, включают:

• Высокая пропускная способность. Миграция из локальных сред vSphere и решений аварийного восстановления требует быстрого перемещения больших объемов данных между локальными сайтами и Решение Azure VMware частными облаками.
• Низкая задержка. Распределенные приложения могут требовать низкой задержки для подключений между Решение Azure VMware виртуальными машинами и локальными системами.
• Прогнозируемость производительности. Для достижения прогнозируемой пропускной способности и задержки критически важные для бизнеса приложения, развернутые на Решение Azure VMware, могут потребоваться выделенные службы подключения (Azure ExpressRoute) между локальными сайтами и сетью Майкрософт.

В этой статье описываются параметры, поддерживаемые Решение Azure VMware для подключения к локальным сайтам:

• Global Reach ExpressRoute
• Vpn-адреса IPSec
• Транзит через частный пиринг ExpressRoute

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

В этой блок-схеме описывается процесс выбора варианта гибридного подключения для Решение Azure VMware:

Global Reach ExpressRoute

ExpressRoute Global Reach — это вариант гибридного подключения по умолчанию, поддерживаемый Решение Azure VMware. Он обеспечивает, с минимальной сложностью, подключение уровня 3 между Решение Azure VMware частным облаком и удаленным сайтом, подключенным к каналу ExpressRoute, управляемому клиентом. Вы также можете использовать канал ExpressRoute, управляемый клиентом, для подключения к собственным службам Azure. Чтобы повысить безопасность или резервную пропускную способность, можно также развернуть отдельный управляемый клиентом канал, предназначенный исключительно для Решение Azure VMware трафика.

На следующей схеме показана топология сети, которая использует Global Reach для подключения к локальным сайтам. Трафик между Решение Azure VMware частными облаками и локальными сайтами не проходит через виртуальные сети Azure.

Примечание.

Для обеспечения максимальной устойчивости следует использовать два управляемых клиентом канала ExpressRoute в разных расположениях пиринга для подключения локальных центров обработки данных к магистрали Майкрософт. В этом случае каждый управляемый клиентом канал ExpressRoute должен иметь подключение Global Reach к частному облаку Решение Azure VMware (а также к azure виртуальная сеть). Ознакомьтесь с этой статьей , чтобы ознакомиться с рекомендациями по реализации устойчивых выражений ExpressRoute.

Инструкции по подключению частного облака Решение Azure VMware к каналу ExpressRoute, управляемому клиентом, с помощью Global Reach, см. в статье "Одноранговые локальные среды" для Решение Azure VMware.

Подключение Global Reach полностью соответствует трем ключевым требованиям:

• Высокая пропускная способность: ExpressRoute позволяет подключаться к сети Майкрософт из локальной среды через выделенные линии (до 10 Гбит/с для ExpressRoute на основе поставщика или 100 Гбит/с для ExpressRoute Direct).
• Низкая задержка: Global Reach позволяет маршрутизировать трафик непосредственно из пограничной сети Майкрософт в Решение Azure VMware кластерах vSphere. Global Reach сводит к минимуму количество сетевых прыжков между локальными сайтами и частными облаками.
• Прогнозируемая производительность. При использовании ExpressRoute Global Reach трафик направляется по ссылкам, которые не испытывают проблем с перегрузкой (до максимально подготовленной емкости). Поэтому время кругового пути между виртуальными машинами, работающими на Решение Azure VMware и локальных узлах, остается постоянным с течением времени.

Вы не можете использовать Global Reach в сценариях, в которых применяются одно или несколько следующих ограничений:

• ExpressRoute Global Reach недоступна в регионе Azure Решение Azure VMware частного облака или расположения канала ExpressRoute, управляемого клиентом. Для этого ограничения не существует обходных решений. Дополнительные сведения о доступности Global Reach в ExpressRoute см. в статье "Глобальный охват ".

• Существуют неотменяемые требования к безопасности сети. Если устройство брандмауэра не может быть развернуто на локальной стороне канала ExpressRoute, управляемого клиентом, с помощью Global Reach предоставляет все Решение Azure VMware сетевые сегменты, включая сети управления (vCenter Server и NSX-T), в всю сеть, подключенную к каналу. Наиболее типичный сценарий, в котором возникает эта проблема, заключается в том, что каналы ExpressRoute, управляемые клиентом, реализуются на основе сетевых служб MPLS (также известных как модель подключения ExpressRoute любой к любому). Этот сценарий показан здесь:

  

  При реализации подключения ExpressRoute поверх IPVPN MPLS невозможно развернуть брандмауэры в одном расположении для проверки всего трафика в Решение Azure VMware. Как правило, организации, использующие сети MPLS, развертывают брандмауэры в крупных центрах обработки данных, а не на всех своих сайтах (которые могут быть небольшими филиалами, офисами или магазинами).

Vpn-адреса IPSec

Вы можете реализовать подключение между Решение Azure VMware частными облаками и локальными сайтами путем маршрутизации трафика через транзитную виртуальную сеть в Azure. Транзитная сеть подключена к Решение Azure VMware частному облаку через управляемый канал ExpressRoute. Транзитная виртуальная сеть подключена к локальному сайту через VPN IPSec, как показано ниже.

Политики безопасности можно применять для подключений между локальными сайтами и частным облаком Решение Azure VMware (дефишированная линия на схеме), перенаправив трафик через брандмауэр, если VPN-устройство не предоставляет функции брандмауэра. Для этой конфигурации требуется azure Виртуальная глобальная сеть с намерением маршрутизации, как описано в разделе "Выбор места размещения виртуальных устройств в Azure" этой статьи.

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

1. Определите, какую сетевую службу следует использовать в качестве подложки для туннеля IPSec. Доступные варианты: подключение к Интернету, пиринг Microsoft ExpressRoute и частный пиринг ExpressRoute.
2. Определите, где размещать виртуальные устройства, завершающие туннель IPSec на стороне Azure. Доступные варианты включают виртуальные сети, управляемые клиентом, и центры Виртуальная глобальная сеть.
3. Определите, какое виртуальное устройство завершает туннель IPSec на стороне Azure. Выбор устройства также определяет необходимую конфигурацию Azure для маршрутизации трафика между туннельом IPSec и управляемым каналом Решение Azure VMware. Доступные варианты — это собственные VPN-шлюз Azure и сторонние NVAs (виртуальные (модуль) сети).

В этой блок-схеме приводится сводка процесса принятия решений:

Критерии принятия этих решений описаны в следующих разделах.

Выбор подложной сетевой службы

Настоятельно рекомендуется рассмотреть три варианта подложки VPN в порядке, представленном здесь:

• Подключение к Интернету. Общедоступный IP-адрес, назначенный VPN-устройству, размещенного в транзитной виртуальной сети, служит удаленной конечной точкой туннеля IPSec. Из-за низкой сложности и стоимости всегда следует проверять и оценивать подключение к Интернету для обеспечения производительности (достижимая пропускная способность IPSec). Этот параметр следует закрыть, только если наблюдаемая производительность слишком низкая или несогласованная. На следующей схеме показан этот параметр.

  

• Пиринг Microsoft ExpressRoute. Этот параметр обеспечивает подключение уровня 3 к общедоступным конечным точкам Azure по выделенным ссылкам. Как и подключения к Интернету, он позволяет получить общедоступный IP-адрес VPN-устройства, который служит удаленной конечной точкой туннеля IPSec и размещается в транзитной виртуальной сети. Этот параметр следует закрыть только в том случае, если требования к маршрутизации пиринга Майкрософт не могут быть выполнены. На следующей схеме показан этот параметр.

  

• Частный пиринг ExpressRoute. Этот параметр обеспечивает подключение уровня 3 между локальным сайтом и виртуальными сетями Azure по выделенным ссылкам. Поэтому он позволяет установить туннель IPSec из локального сайта в частный IP-адрес VPN-устройства, размещенного в виртуальной сети. Частный пиринг ExpressRoute может привести к ограничениям пропускной способности, так как шлюз ExpressRoute находится в пути к данным. Для решения этой проблемы можно использовать ExpressRoute FastPath . Для частного пиринга также требуется более сложная конфигурация маршрутизации на локальной стороне. Дополнительные сведения см. в разделе "Настройка VPN-подключения типа "сеть — сеть" через частный пиринг ExpressRoute. На следующей схеме показан этот параметр.

  

Выбор места размещения виртуальных устройств в Azure

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

• Для Решение Azure VMware подключения следует использовать предварительную сетевую инфраструктуру Azure. Если сеть, управляемая клиентом, уже существует в том же регионе, что и Решение Azure VMware частное облако, следует развернуть устройства завершения IPSec в существующем концентраторе. Если центральная сеть, основанная на Виртуальная глобальная сеть, существует в том же регионе, что и частное облако Решение Azure VMware, следует использовать центр Виртуальная глобальная сеть для завершения IPSec.
• В управляемой клиентом сети концентратора для маршрутизации трафика между туннелом IPSec и управляемым каналом ExpressRoute необходимо развернуть экземпляр сервера Маршрутизации Azure в виртуальной сети концентратора и настроить его для разрешения трафика в филиалах к ветви. Невозможно маршрутизировать трафик между Решение Azure VMware частными облаками и локальными сайтами через устройства брандмауэра, развернутые в виртуальной сети.
• Виртуальная глобальная сеть концентраторы изначально поддерживают маршрутизацию трафика между туннельом IPSec, подключенным к локальному сайту и каналу Решение Azure VMware управляемого ExpressRoute.
• При использовании Виртуальная глобальная сеть можно настроить намерения маршрутизации и политики маршрутизации для проверки трафика. Вы можете использовать Брандмауэр Azure или сторонние решения безопасности, поддерживаемые Виртуальная глобальная сеть. Мы рекомендуем ознакомиться с региональными ограничениями и доступностью намерения маршрутизации.

Определите, какое виртуальное устройство завершает туннель IPSec

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

• В сетевых сетях, управляемых клиентом и концентраторами, которые основаны на Виртуальная глобальная сеть, можно использовать Azure VPN-шлюз для прекращения туннелей IPSec, подключенных к локальным сайтам. Так как они управляются платформой, VPN-шлюзы Azure требуют минимальных усилий по управлению. Вы можете использовать уже существующие шлюзы, даже если они поддерживают другие сценарии подключения. Чтобы узнать о поддерживаемых параметрах и ожидаемой производительности, ознакомьтесь со следующими статьями:

  • VPN-шлюз номера SKU и ожидаемые уровни производительности (автономные)
  • VPN-шлюз требования к шифрованию (автономный)
  • параметры VPN-шлюз (Виртуальная глобальная сеть)
  • требования к шифрованию VPN-шлюз (Виртуальная глобальная сеть)

• Сторонние NVAs обычно используются для завершения туннелей из локальных сайтов в следующих ситуациях:

  • NVA — это CPE (локальное оборудование клиента) решения SDWAN, развернутого как в Azure, так и на локальном сайте.
  • NVA — это брандмауэр, который применяет необходимую политику безопасности для подключений между локальным сайтом и Решение Azure VMware.

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

Транзит через частный пиринг ExpressRoute

Частный пиринг ExpressRoute является наиболее распространенным выбором для подключения локального сайта к виртуальной сети Azure (или центральной сети) в корпоративных сценариях. Виртуальная сеть Azure или виртуальная сеть концентратора в периферийных топологиях содержит шлюз ExpressRoute, настроенный с подключением к каналу ExpressRoute. Эта конфигурация обеспечивает подключение уровня 3 между виртуальной сетью (или всей периферийной сетью концентратора) и сетью локального сайта. Тем не менее, он не предоставляет подключение уровня 3 к Решение Azure VMware частным облакам, которые подключены к одной виртуальной сети (или центральной виртуальной сети) через управляемый канал ExpressRoute. (См. раздел ExpressRoute Global Reach и Решение Azure VMware частных облаках.)

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

Транзит через частный пиринг ExpressRoute может показаться желательным, но он добавляет сложность и влияет на производительность. Следует учитывать это только в том случае, если vpn-адреса ExpressRoute Global Reach и IPSec (описанные в предыдущих разделах) неприменимо.

Существует два варианта реализации:

• Отдельная виртуальная сеть. При использовании этого параметра управляемые клиентом и Решение Azure VMware управляемые каналы подключаются к одному шлюзу ExpressRoute.
• Вспомогательная транзитная виртуальная сеть. При использовании этого параметра канал ExpressRoute, управляемый клиентом, который обеспечивает подключение к локальному сайту, подключен к шлюзу ExpressRoute (обычно уже существующему) в виртуальной сети концентратора. Управляемый канал Решение Azure VMware подключен к другому шлюзу ExpressRoute, развернутному в вспомогательной транзитной виртуальной сети.

В следующих разделах содержатся сведения о двух вариантах реализации, включая следующие:

• Компромисс между производительностью, затратами (необходимыми ресурсами Azure) и затратами на управление.
• Реализация плоскости управления (как маршруты обмениваются между локальным сайтом и частным облаком).
• Реализация плоскости данных (способ маршрутизации сетевых пакетов между локальным сайтом и частным облаком).

Одна виртуальная сеть

При использовании единого подхода к виртуальной сети управляемый канал частного облака Решение Azure VMware и канал, принадлежащий клиенту, подключен к одному шлюзу ExpressRoute, как правило, к центральной сети. Трафик между частным облаком и локальным сайтом можно направлять через NVA брандмауэра, развернутые в центральной сети. Здесь показана архитектура одной виртуальной сети:

Плоскость управления и плоскость данных реализованы, как описано здесь:

• Плоскость управления. Шлюз ExpressRoute, развернутый в виртуальной сети Azure, не может распространять маршруты между управляемым каналом Решение Azure VMware и каналом ExpressRoute, управляемым клиентом. Сервер маршрутизации Azure с включенным параметром "ветвь — ветвь" используется для внедрения в обоих каналах маршрутов для суперсетей, которые включают адресное пространство частного облака Решение Azure VMware (сети управления и сегменты рабочих нагрузок) и локальное адресное пространство.

  Суперсети, а не точные префиксы, составляющие эти адресные пространства, должны быть объявлены, так как точные префиксы уже объявляются в противоположном направлении Решение Azure VMware частного облака и локального сайта. Суперсети можно использовать как префиксы RFC 1918, если они совместимы с конфигурацией сети локальных сайтов. В большинстве случаев следует использовать самые маленькие суперсети, которые включают адресное пространство Решение Azure VMware частного облака и локальное адресное пространство. Это позволяет свести к минимуму риски конфликтов с конфигурацией маршрутизации локальных сайтов.

  Маршруты для суперсетей создаются сетевыми сетями, поддерживаемыми BGP. NVAs настроены для установки сеанса BPG с сервером маршрутизации Azure. NVA являются только частью плоскости управления и не маршрутизируют фактический трафик между локальным сайтом и Решение Azure VMware частным облаком. Реализация плоскости управления представлена пунктирными линиями на предыдущем рисунке.

• Плоскость данных. Реализация плоскости управления, описанная ранее, привлекает следующий трафик к шлюзу ExpressRoute:

  • Трафик из локального сайта, предназначенного для Решение Azure VMware частного облака.
  • Трафик из частного облака Решение Azure VMware, предназначенного для локального сайта.

  Если UDR не применяются к GatewaySubnet, трафик передается непосредственно между локальным сайтом и частным облаком Решение Azure VMware. Трафик можно перенаправить на промежуточный следующий прыжок, применив UDR к GatewaySubnet. NVA брандмауэра, которые применяют политики безопасности сети к подключениям между локальными сайтами и частными облаками, являются типичным примером. Реализация плоскости данных представлена сплошной линией на предыдущем рисунке.

Вспомогательная виртуальная сеть

Вы можете использовать вспомогательную виртуальную сеть для размещения второго шлюза ExpressRoute, подключенного только к управляемому каналу частного облака Решение Azure VMware. При использовании этого подхода управляемый канал частного облака и управляемый клиентом канал подключаются к разным шлюзам ExpressRoute. Два экземпляра сервера маршрутов Azure используются для объявления соответствующих маршрутов в каждом канале и управления распространением маршрутов между частным облаком и локальным сайтом. Вам не нужно объявлять суперсети, так как для параметра одной виртуальной сети, описанного в предыдущем разделе. Затраты на управление для определяемых пользователем ресурсов в GatewaySubnet также сокращаются. Этот подход позволяет маршрутизировать трафик между частным облаком и локальным сайтом через NVAs брандмауэра в центральной виртуальной сети. Реализация вспомогательной виртуальной сети показана на следующей схеме:

Плоскость управления и плоскость данных реализованы, как описано здесь:

• Плоскость управления. Чтобы включить распространение маршрутов между управляемым каналом частного облака Решение Azure VMware и каналом клиента, вам потребуется экземпляр сервера маршрутизации Azure в каждой виртуальной сети. Так как два экземпляра сервера маршрутизации Azure не могут установить связь BGP, для распространения маршрутов между ними требуются сетевые сети, поддерживаемые BGP. Для обеспечения высокой доступности необходимо развернуть по крайней мере два экземпляра NVA. Вы можете добавить дополнительные экземпляры для повышения пропускной способности. Сетевые адаптеры, поддерживающие BGP, должны иметь два сетевых адаптера, подключенные к разным подсетям. Сеансы BGP по двум серверам маршрутизации (в вспомогательной виртуальной сети и виртуальной сети концентратора) должны быть установлены по разным сетевым адаптерам.

  Маршруты, созданные частным облаком Решение Azure VMware и локальным сайтом, изучаются по каналам ExpressRoute. Их пути AS содержат ASN 65515 (зарезервированный AZURE ASN, используемый шлюзами ExpressRoute) и ASN 12076 (asn, принадлежащий Майкрософт, который используется маршрутизаторами Microsoft Enterprise Edge во всех расположениях пиринга). NVA, поддерживающих BGP, должны удалить пути AS, чтобы предотвратить удаление маршрутов с помощью обнаружения цикла BGP. Дополнительные сведения о требуемой конфигурации BGP см. в разделе "Реализация подключения Expressroute для AVS без глобального охвата". Реализация плоскости управления представлена пунктирными линиями на предыдущей схеме.

• Плоскость данных. В вспомогательной виртуальной сети трафик между частным облаком Решение Azure VMware и локальным сайтом направляется через NVAs, поддерживающий BGP. Трафик в Решение Azure VMware частного облака покидает или вводит NVAs через сетевой адаптер, используемый для сеанса BGP с сервером маршрутизации вспомогательной виртуальной сети. Трафик к локальному сайту покидает или вводит NVAs через сетевой адаптер, используемый для сеанса BGP с сервером маршрутизации центральной виртуальной сети. Этот сетевой адаптер подключен к подсети, связанной с пользовательской таблицей маршрутов, которая:

  • Отключает обучение маршрутов BGP с сервера маршрутов (чтобы избежать циклов).
  • Вставляет брандмауэр центральной сети в путь к данным.

  Чтобы обеспечить симметричный маршрутизацию трафика через брандмауэр концентратора, UDR для всех префиксов, используемых в частном облаке Решение Azure VMware, необходимо настроить в шлюзе ШлюзаSubnet концентратора. Дополнительные сведения см. в статье "Реализация подключения Expressroute для AVS без глобального охвата". Реализация плоскости данных представлена сплошной линией на предыдущей схеме.

Следующие шаги

Узнайте о подключении между Решение Azure VMware и виртуальными сетями Azure.

Подключение чувствительность между Решение Azure VMware и виртуальными сетями Azure