Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается проектирование программно-определенных WAN (SD-WANs), которые подключают локальные центры обработки данных друг к другу и с Azure. Она представляет архитектуру, которая позволяет клиентам Azure использовать имеющиеся вложения в платформу, создавая эффективные глобальные оверлейные сети SD-WAN поверх магистральной сети Microsoft.
Применимые сценарии
Рекомендации в этой статье не зависят от поставщика и применимы к технологиям SD-WAN, которые соответствуют двум основным предварительным требованиям:
Туннели, использующие Transmission Control Protocol (TCP) или User Datagram Protocol (UDP) в качестве базового транспорта, такие как ESP IPsec в туннельном режиме с обходом NAT, реализуют оверлей SD-WAN.
Протокол BGP версии 4 обменивается маршрутами между пограничными устройствами SD-WAN и сетями, подключенными к SD-WAN. Не делается никаких предположений о протоколе маршрутизации, который пограничные устройства SD-WAN используют для обмена маршрутной информацией.
Для достижения следующих целей можно использовать SD-WAN продукты, соответствующие этим предварительным требованиям:
Подключите Azure центральные и периферийные сети к SD-WANs, охватывающим облачные и локальные объекты, с динамическим обменом маршрутами между виртуальными сетями Azure и SD-WAN пограничными устройствами.
Оптимизируйте подключение к Azure и локальным центрам обработки данных для филиалов, имеющих локальные интернет-прорывы. Масштаб магистральной сети Microsoft в сочетании с её пропускной способностью, отказоустойчивостью и политикой маршрутизации cold potato может сделать её высокопроизводительной базовой сетью для глобальных сетей SD-WAN.
Используйте основную сеть Майкрософт для всех взаимодействий между Azure (в регионах и между географическими областями).
Используйте существующие сети многопротокольного переключения меток (MPLS) как высокопроизводительные подложки.
Переход с сетей MPLS на подключение к Интернету в поэтапном подходе, который сводит к минимуму влияние на бизнес.
В следующих разделах предполагается, что вы знакомы с основами парадигмы SD-WAN и архитектурой магистральной сети Microsoft. Магистральная сеть Майкрософт соединяет Azure регионы друг с другом и с общедоступным Интернетом.
Architecture
Организации с глобальным присутствием и мультирегиональной инфраструктурой в Azure используют несколько служб сетевого подключения для построения своих корпоративных сетей и подключения к магистральной сети Microsoft.
Выделенные службы подключения, такие как IPLS IP-виртуальные частные сети (IPVPNs), обычно развертываются на крупнейших сайтах.
каналы Azure ExpressRoute подключают магистраль Microsoft к центрам обработки данных с помощью модели подключения "точка — точка" или непосредственно к сети MPLS с помощью модели подключения "любой к любому".
Филиалы, имеющие только подключение к Интернету, могут использовать виртуальные сети IPsec для подключения к ближайшему локальному центру обработки данных и использовать подключение ExpressRoute центра обработки данных для доступа к ресурсам Azure. Или они могут использовать VPN-соединения IPsec для прямого подключения к сетям Azure по топологии «концентратор — периферия».
SD-WAN проекты могут отличаться в службах подключения, которые они намерены заменить. Некоторые организации могут продолжать использовать выделенные ссылки или MPLS для крупных объектов и развертывать SD-WAN только для замены устаревших виртуальных сетей IPsec в Интернете на небольших сайтах. Другие организации могут потребовать расширения SD-WAN на подключенные к MPLS сайты и использовать существующую сеть MPLS в качестве высокопроизводительной подложки. Некоторые организации также могут вывести из эксплуатации свою сеть MPLS и построить всю свою корпоративную сеть в виде логического оверлея поверх общедоступных или совместно используемых underlay-сетей, таких как общедоступный Интернет и магистральная сеть Microsoft.
Архитектура поддерживает все области в этой статье и основана на следующих принципах:
Устройства SD-WAN развертываются как сетевые виртуальные устройства (NVA) в топологии «ступица и спицы» каждого региона Azure и настраиваются как узлы SD-WAN, которые терминируют туннели от локальных площадок.
Устройства SD-WAN в Azure настроены на установление туннелей друг с другом, чтобы создать полносвязную оверлейную сеть между узлами-концентраторами, обеспечивающую эффективную передачу трафика между регионами Azure. Эта оверлейная сеть также передает трафик между географически удаленными локальными площадками через магистральную сеть Microsoft.
Устройства SD-WAN развертываются на всех локальных площадках, которые охватываются решением SD-WAN, и настраиваются для установления туннелей до виртуальных сетевых устройств (NVA) SD-WAN в ближайшем регионе Azure или ближайших регионах Azure. Различные площадки могут использовать разные службы транспортной сети underlay, например общедоступный интернет или подключение ExpressRoute.
Трафик с сайта маршрутизируется через SD-WAN NVA в ближайшем регионе Azure независимо от того, находится ли конечный узел в Azure или на другой локальной площадке. Затем трафик проходит через оверлейную сеть между концентраторами.
SD-WAN продукты могут использовать собственные протоколы и функции для создания прямых туннелей между двумя сайтами и повышения производительности, чем ретрансляция трафика через SD-WAN NVAs в Azure.
На следующей схеме показана архитектура верхнего уровня глобальной сети SD-WAN, в которой магистральная сеть Microsoft, общедоступный интернет и выделенные подключения ExpressRoute используются в качестве подложки.
Скачайте файл PowerPoint данной архитектуры.
Подключение Azure центральных и периферийных сетей к SD-WANs
В этом разделе приведены рекомендации по развертыванию SD-WAN пограничных устройств в качестве NVAs в существующей сети Azure концентратора и периферийных устройств.
NVAs SD-WAN в виртуальной сети концентратора
Мы рекомендуем топологию концентратора и периферийных узлов для создания масштабируемых сетей в регионе Azure с помощью управляемых клиентом виртуальных сетей. Виртуальная сеть концентратора размещает общие компоненты, такие как NVAs и собственные службы, предоставляющие сетевые функции, такие как брандмауэр, балансировка нагрузки и подключение к локальным сайтам через виртуальные сети типа "сеть — сеть" или ExpressRoute. Виртуальная сеть концентратора — это логическое расположение для SD-WAN виртуальных сетей, так как она централизованно выполняет общие сетевые функции и обеспечивает согласованный доступ к удаленным сетям. Эти NVA — шлюзы, не относящиеся к Microsoft, которые соединяют центральный узел с этими удаленными сетями.
Разверните SD-WAN NVA в центральных виртуальных сетях следующим образом:
Используйте один сетевой контроллер (сетевой адаптер) для всего SD-WAN трафика. Вы можете добавить другие сетевые адаптеры, например адаптер управления, чтобы соответствовать требованиям безопасности и нормативного соответствия либо соблюдать рекомендации поставщика для развертываний в Azure.
Подключите сетевой адаптер, используемый для SD-WAN трафика в выделенную подсеть. Определите размер подсети на основе количества развернутых виртуальных сетевых устройств SD-WAN (NVA), необходимых для обеспечения высокой доступности (HA) и выполнения требований к масштабируемости или пропускной способности. Дополнительные сведения см. в статьях Подключение сетей Azure типа "центр — периферия" к SD-WAN и Ограничения и рекомендации по проектированию для Azure Route Server.
Свяжите группы безопасности сети (NSG) с сетевым адаптером трафика SD-WAN напрямую или на уровне подсети, чтобы разрешить подключения с удаленных локальных сайтов через порты TCP/UDP, которые использует решение SD-WAN.
Включите IP-пересылку на сетевой адаптер, используемый для SD-WAN трафика.
Сервер маршрутизации в виртуальной сети концентратора
Route Server автоматизирует обмен маршрутами между виртуальными сетевыми устройствами SD-WAN и стеком программно определяемой сети (SDN) Azure. Сервер маршрутизации поддерживает BGP в качестве протокола динамической маршрутизации. Путем установления связей BGP между сервером маршрутизации и SD-WAN NVAs:
Сервер маршрутизации добавляет маршруты для всех локальных площадок, подключенных к SD-WAN, в таблицы маршрутов виртуальной сети, и все виртуальные машины Azure получают сведения об этих маршрутах.
Сервер маршрутизации распространяет маршруты для всех префиксов IP-адресов в адресном пространстве виртуальных сетей на все подключенные к SD-WAN сайты.
Настройте сервер маршрутизации со следующими требованиями:
Разверните сервер маршрутизации в выделенной подсети в виртуальной сети концентратора. Задайте емкость сервера маршрутизации на основе количества виртуальных машин в центральной и периферийной сети.
Чтобы включить динамический обмен маршрутами для всех периферийных виртуальных сетей, настройте пиринг виртуальных сетей, чтобы позволить периферийным виртуальным сетям использовать шлюз виртуальной сети концентратора и сервер маршрутизации. Дополнительные сведения см. в разделе "Вопросы и ответы о сервере маршрутизации".
Route Server и виртуальные сетевые устройства SD-WAN (NVA) подключены к разным подсетям, поэтому настройте сеансы BGP между Route Server и устройствами SD-WAN (NVA) с использованием поддержки eBGP multihop. Поддерживается любое количество переходов от двух до максимального числа, поддерживаемого SD-WAN NVA. Дополнительные сведения о том, как настроить смежности BGP для Route Server, см. в статье Создание и настройка Route Server с помощью портала Azure.
Настройте два
/32статических маршрута на SD-WAN NVA для конечных точек BGP, предоставляемых сервером маршрутизации. Эта конфигурация гарантирует, что таблица маршрутов NVA всегда содержит маршруты для многоступенчатых BGP-партнеров (не подключенных напрямую).
Сервер маршрутизации не участвует в обработке данных. Это компонент плоскости управления, который распространяет маршруты между SD-WAN NVAs и стеком SDN виртуальной сети. Стек Azure SDN обеспечивает фактическую пересылку трафика между виртуальными сетевыми устройствами (NVA) SD-WAN и виртуальными машинами в виртуальной сети, как показано на следующем рисунке. Чтобы обеспечить такое поведение маршрутизации, сервер маршрутизации внедряет все маршруты, которые он узнает из SD-WAN NVAs, задав следующий прыжок на адрес NVA.
Сервер маршрутизации не поддерживает IPv6. Эта архитектура используется только для IPv4.
Высокий уровень доступности для NVAs SD-WAN с помощью сервера маршрутизации
Сервер маршрутов имеет встроенную функцию высокой доступности. Для одного экземпляра Route Server используются два вычислительных ресурса, и Azure развертывает эти вычислительные ресурсы в разных зонах доступности (в регионах с зонами доступности) или в одном наборе доступности (в регионах без зон доступности). В результате экземпляр сервера маршрутизации предоставляет две конечные точки BGP, одну конечную точку для каждого вычислительного ресурса. Вы обеспечиваете высокую доступность для виртуальных сетевых устройств SD-WAN, развернув несколько экземпляров в разных зонах доступности или в одном наборе доступности. Каждый SD-WAN NVA устанавливает два сеанса BGP, по одному сеансу для каждой конечной точки, предоставляемой сервером маршрутизации.
Эта архитектура не зависит от подсистем балансировки нагрузки Azure. Оно имеет следующие характеристики.
Общедоступные подсистемы балансировки нагрузки не предоставляют конечные точки туннеля SD-WAN. Каждая NVA SD-WAN предоставляет собственную конечную точку туннеля. Удаленные одноранговые узлы устанавливают несколько туннелей с одним туннелем для каждого SD-WAN NVA в Azure.
Для распределения трафика от виртуальных машин Azure между несколькими пограничными устройствами SD-WAN в Azure внутренние балансировщики нагрузки не требуются. Route Server и стек SDN в Azure поддерживают маршрутизацию по нескольким путям равной стоимости (ECMP). Если несколько пограничных устройств объявляют маршрут для одного назначения, сервер маршрутизации внедряет несколько маршрутов в таблицу маршрутов виртуальной сети с одним маршрутом для каждого пограничного устройства, которое объявило о назначении. В таблице маршрутов виртуальной сети каждый маршрут имеет свой следующий переход, соответствующий IP-адресу пограничного устройства, которое его объявило. Затем стек SDN распределяет трафик к этому узлу назначения между всеми доступными следующими переходами.
На следующем рисунке показана полученная архитектура высокой доступности.
N-активный и активный резервный высокий уровень доступности
При использовании нескольких виртуальных сетевых устройств SD-WAN и соединении их с сервером маршрутизации, BGP управляет переключением при отказе. Если NVA SD-WAN переходит в автономный режим, он останавливает объявление маршрутов на сервер маршрутизаторов. Затем сервер маршрутов удаляет маршруты, полученные с этого устройства из таблицы маршрутов виртуальной сети. В результате, если SD-WAN NVA больше не обеспечивает подключение к удалённым узлам SD-WAN из-за сбоя устройства или базовой сети, он больше не отображается в таблице маршрутов виртуальной сети как возможный следующий переход до этих узлов. Весь трафик переходит к оставшимся работоспособным устройствам. Дополнительные сведения о распространении маршрутов между SD-WAN NVA и сервером маршрутов см. в разделе Маршруты, анонсируемые BGP-пиром серверу маршрутов.
На следующей схеме показано поведение при аварийном переключении.
Переключение при отказе на основе BGP и маршрутизация ECMP позволяют реализовать N-active-архитектуры высокой доступности с N устройствами, которые одновременно обрабатывают трафик. Кроме того, можно реализовать активные пассивные архитектуры, так как сервер маршрутизации учитывает атрибуты пути BGP AS. Если разные пограничные устройства SD-WAN объявляют маршруты к одним и тем же сетям назначения с разной длиной AS Path, то пограничное устройство SD-WAN, объявляющее маршруты с наименьшей длиной AS Path, становится предпочтительным следующим узлом. Если это устройство выходит из строя или отзывает часть своих маршрутов, сервер маршрутов распространяет маршруты с более длинными значениями AS Path, объявленные другими устройствами. Единственный атрибут BGP, который SD-WAN NVAs может использовать для выражения степени предпочтения маршрутов, которые они объявляют в Route Server, — AS Path.
Мы рекомендуем архитектуры высокой доступности (HA) типа N-active, поскольку они обеспечивают оптимальное использование ресурсов без резервных SD-WAN NVA и горизонтальную масштабируемость. Чтобы увеличить пропускную способность, несколько виртуальных сетевых устройств могут работать параллельно, вплоть до максимального числа BGP-пиров, которое поддерживает Route Server. Для модели N-active HA требуется, чтобы SD-WAN NVAs действовали как не сохраняющие состояние маршрутизаторы 3-го уровня. Если существует несколько туннелей на сайт, система может перенаправить tcp-подключения асимметрично. Исходные и ответные потоки одного и того же TCP-подключения можно направлять через разные туннели и разные NVA. На следующем рисунке показан пример асимметричного перенаправленного TCP-подключения. Эти асимметрии маршрутизации возможны для tcp-подключений, инициированных в виртуальной сети или локальном сайте.
Рассматривайте архитектуры высокой доступности по схеме «активный-пассивный» только в тех случаях, когда SD-WAN NVA в Azure выполняют сетевые функции, требующие симметрии маршрутизации, такие как проверка состояния брандмауэром. Избегайте этого подхода из-за его последствий масштабируемости. Выполнение дополнительных сетевых функций на виртуальных машинах SD-WAN увеличивает потребление ресурсов. Архитектуры высокой доступности (HA) типа active-passive позволяют только одному NVA обрабатывать трафик в любой момент времени. В результате весь уровень SD-WAN можно масштабировать только вертикально — до максимального поддерживаемого размера виртуальной машины Azure, но не горизонтально. Развертывайте сетевые функции с отслеживанием состояния, требующие симметричной маршрутизации, в отдельных кластерах NVA, использующих Azure Load Balancer для высокой доступности в конфигурации n-active.
Рекомендации по подключению ExpressRoute
Эта архитектура поддерживает полноценный подход SD-WAN, поэтому вы можете построить корпоративную сеть в виде логической оверлейной сети поверх публичного интернета и магистральной сети Microsoft. Вы также можете использовать выделенные каналы ExpressRoute для решения конкретных сценариев, описанных в следующих разделах.
Сценарий #1. Сосуществование ExpressRoute и SD-WAN
Решения SD-WAN могут сосуществовать с подключением ExpressRoute при развертывании устройств SD-WAN только в подмножестве сайтов. Например, некоторые организации могут развертывать SD-WAN решения в качестве замены традиционных виртуальных сетей IPsec на сайтах, имеющих только подключение к Интернету, и использовать службы MPLS и каналы ExpressRoute для крупных сайтов и центров обработки данных, как показано на следующем рисунке.
В этом сценарии сосуществования требуется SD-WAN NVAs, развернутые в Azure для маршрутизации трафика между сайтами, подключенными к SD-WAN и сайтам, подключенным к каналам ExpressRoute.
Сервер маршрутов можно настроить для распространения маршрутов между шлюзами виртуальной сети ExpressRoute и SD-WAN NVAs в Azure, включив эту функциюAllowBranchToBranch. Распространение маршрутов между шлюзом виртуальной сети ExpressRoute и SD-WAN NVAs происходит через BGP. Сервер маршрутизации устанавливает сеансы BGP со шлюзом виртуальной сети ExpressRoute и с виртуальными сетевыми устройствами (NVA) SD-WAN и передает каждому пиринговому узлу маршруты, полученные от другого пирингового узла. Платформа управляет сеансами BGP между сервером маршрутизации и шлюзом виртуальной сети ExpressRoute. Пользователям не нужно явно настраивать эти сеансы. Они должны включить AllowBranchToBranch флаг только при развертывании сервера маршрутов.
Этот сценарий сосуществования SD-WAN и ExpressRoute позволяет переносить сети MPLS в SD-WAN. Он предоставляет путь между устаревшими сайтами MPLS и недавно перенесенными SD-WAN сайтами и устраняет необходимость маршрутизации трафика через локальные центры обработки данных. Используйте этот шаблон во время миграции и в сценариях, происходящих от слияний и приобретений компании, для объединения разрозненных сетей.
Сценарий #2. ExpressRoute в качестве SD-WAN подложной сети
Если ваши локальные площадки имеют подключение ExpressRoute, вы можете настроить устройства SD-WAN для установки туннелей к NVA-концентратору SD-WAN, работающему в Azure через ExpressRoute. Вы можете использовать частный пиринг ExpressRoute и Microsoft пиринг.
Частный пиринг
Когда в качестве базовой сети используется частный пиринг ExpressRoute, все локальные площадки SD-WAN устанавливают туннели к виртуальным сетевым модулям (NVA) концентратора SD-WAN в Azure. В этом сценарии не требуется распространение маршрутов между виртуальными сетевыми устройствами (NVA) SD-WAN и шлюзом виртуальной сети ExpressRoute, поэтому необходимо настроить Route Server, установив для флага AllowBranchToBranch значение false.
Этот подход требует надлежащей конфигурации BGP на маршрутизаторах на стороне клиента или поставщика, которые завершают подключение ExpressRoute. Маршрутизаторы Microsoft Enterprise Edge (MSEEs) объявляют все маршруты для виртуальных сетей, подключённых к каналу напрямую или через пиринг между виртуальными сетями. Чтобы перенаправить трафик, предназначенный для виртуальных сетей через туннель SD-WAN, локальный сайт должен узнать эти маршруты с устройства SD-WAN, а не из канала ExpressRoute.
В результате маршрутизаторы на стороне клиента или поставщика, которые завершают подключение ExpressRoute, должны отфильтровать маршруты, полученные из Azure. Единственные маршруты в базовой сети должны обеспечивать локальным устройствам SD-WAN доступ к виртуальным сетевым устройствам (NVA) узла SD-WAN в Azure. Клиенты, которые планируют использовать частный пиринг ExpressRoute в качестве SD-WAN подложной сети, должны убедиться, что их устройства маршрутизации поддерживают эту конфигурацию. Это требование особенно важно для клиентов, которые не контролируют пограничные устройства, используемые для ExpressRoute, например, когда оператор MPLS предоставляет канал ExpressRoute на вершине службы IPVPN.
Сетевой пиринг Майкрософт
Вы также можете использовать пиринг Microsoft ExpressRoute в качестве подложной сети для SD-WAN туннелей. В этом сценарии виртуальные сетевые устройства (NVA) центрального узла SD-WAN в Azure предоставляют только общедоступные конечные точки туннелей, которые использует оборудование клиента на его площадке (CPE) для SD-WAN как на площадках, подключенных к Интернету, так и на площадках, подключенных через ExpressRoute. Пиринг ExpressRoute Microsoft имеет более сложные предварительные требования, чем частный пиринг, но мы рекомендуем использовать этот параметр в качестве подложной сети по следующим двум причинам:
Для этого не требуются шлюзы виртуальной сети ExpressRoute в центральной виртуальной сети. Она удаляет сложность, снижает затраты и позволяет масштабировать решение SD-WAN за пределы пропускной способности шлюза, если вы не используете ExpressRoute FastPath.
Такой подход обеспечивает чёткое разделение между оверлейными и андерлейными маршрутами. MSEEs анонсируют клиентскому или операторскому пограничному маршрутизатору только публичные префиксы сети Microsoft. Эти маршруты можно поместить в отдельный экземпляр виртуальной маршрутизации и переадресации (VRF) и распространять их только на периметральный сегмент локальной сети сайта. Устройства SD-WAN распространяют маршруты для корпоративной сети клиента в оверлейной сети, включая маршруты для виртуальных сетей. Клиенты, которые рассматривают этот подход, должны убедиться, что они могут настроить свои устройства маршрутизации соответствующим образом или запросить соответствующую службу от оператора MPLS.
Рекомендации по MPLS
Миграция из традиционных корпоративных сетей MPLS в более современные сетевые архитектуры на основе парадигмы SD-WAN требует значительных усилий и времени. Используйте эту архитектуру для реализации поэтапной миграции из MPLS в SD-WAN. В следующих разделах описаны два типичных сценария миграции.
Поэтапный вывод из эксплуатации MPLS
Клиенты, которые хотят развернуть SD-WAN поверх общедоступного Интернета и магистральной сети Microsoft и полностью отказаться от MPLS IPVPN или других выделенных служб подключения, могут использовать сценарий сосуществования ExpressRoute и SD-WAN во время миграции. В этом сценарии сайты, подключенные к SD-WAN, могут получать доступ к сайтам, подключенным к устаревшим MPLS. После переноса сайта на SD-WAN и развертывания устройств CPE можно вывести из эксплуатации ссылку MPLS. Сайт может получить доступ ко всей корпоративной сети через свои туннели SD-WAN к ближайшим регионам Azure.
Когда все сайты будут перенесены, можно вывести из эксплуатации MPLS IPVPN вместе с каналами ExpressRoute, которые подключают его к магистральной сети Microsoft. Вам больше не нужны шлюзы виртуальной сети ExpressRoute и их можно отменить. В каждом регионе виртуальные сетевые устройства (NVA) концентратора SD-WAN становятся единственной точкой входа в сеть типа «концентратор — периферия» этого региона.
Интеграция MPLS
Организации, не доверяющие общедоступным и общим сетям, чтобы обеспечить необходимую производительность и надежность, могут решить использовать существующую сеть MPLS в качестве наложения корпоративного класса для определенных сайтов или приложений.
Сценарий ExpressRoute в качестве SD-WAN подложки поддерживает интеграцию SD-WAN и MPLS. Отдавайте предпочтение пирингу Microsoft в ExpressRoute перед частным пирингом. При использовании Microsoft пиринга сеть MPLS и общедоступный Интернет становятся функционально эквивалентными наложениями. Они обеспечивают доступ ко всем конечным точкам туннелей SD-WAN, которые предоставляют виртуальные сетевые модули (NVA) концентратора SD-WAN в Azure. SD-WAN CPE, развернутый на сайте с подключением к Интернету и MPLS, может установить несколько туннелей к центрам SD-WAN в Azure на обоих подложках. Затем CPE может направлять разные соединения через разные туннели на основе политик на уровне приложений, которые задаются плоскостью управления SD-WAN.
Параметры маршрутизации сервера маршрутов
В обоих сценариях MPLS в предыдущих двух разделах некоторые сайты филиалов можно подключить как к IPVPN MPLS, так и к SD-WAN. В результате экземпляры сервера маршрутизации, развернутые в центральных виртуальных сетях, могут узнать те же маршруты из шлюзов ExpressRoute и SD-WAN NVAs.
Используйте параметр предпочтения маршрутизации Route Server, чтобы управлять тем, какой маршрут следует предпочесть и распространить в таблицах маршрутов виртуальных сетей.
Предпочтения маршрутизации полезны, если не удается использовать предустановку пути AS. Примером являются службы MPLS IPVPN, которые не поддерживают пользовательские конфигурации BGP. В зависимости от того, как сеть MPLS агрегирует маршруты, от уровня контроля над атрибутами ваших маршрутов MPLS, а также от того, чему вы отдаёте предпочтение во время миграции — SD-WAN или MPLS, — может потребоваться принудительно настроить Route Server так, чтобы он предпочитал маршруты MPLS маршрутам SD-WAN или маршруты SD-WAN маршрутам MPLS.
Ограничения сервера маршрутизации и рекомендации по проектированию
Сервер маршрутизации является центральным для этой архитектуры. Он распространяет маршруты между виртуальными сетевыми устройствами SD-WAN, развернутыми в виртуальных сетях, и базовым стеком SDN Azure. Предусмотрен подход с использованием BGP для развертывания нескольких виртуальных сетевых устройств SD-WAN (NVA) с целью обеспечения высокой доступности и горизонтального масштабирования. При разработке крупных SD-WANs на основе этой архитектуры следует учитывать ограничения масштабируемости сервера маршрутов.
В следующих разделах приводятся рекомендации по максимальной масштабируемости и обработке каждого ограничения.
Маршруты, объявленные одноранговым узлом BGP серверу маршрутизации
Сервер маршрутов не определяет явное ограничение количества маршрутов, которые можно объявить шлюзам виртуальной сети ExpressRoute при установке флага AllowBranchToBranch . Однако шлюзы ExpressRoute далее распространяют маршруты, которые они получают от Route Server, в каналы ExpressRoute, с которыми они соединены.
Azure ограничивает количество маршрутов, которые шлюзы ExpressRoute могут объявлять каналам ExpressRoute через частный пиринг. При разработке решений SD-WAN на основе рекомендаций, приведенных в этой статье, убедитесь, что SD-WAN маршруты не достигают этого ограничения. Если достигнут предел, сеансы BGP между шлюзами ExpressRoute и каналами ExpressRoute удаляются, а подключение между виртуальными сетями и удаленными сетями, подключенными через ExpressRoute, теряется.
Общее количество маршрутов, объявляемых шлюзами ExpressRoute для каналов связи, представляет собой сумму маршрутов, которые они получают от Route Server, и префиксов, образующих адресное пространство сети Azure по топологии «концентратор — периферия». Чтобы избежать сбоев из-за разрыва BGP-сеансов, мы рекомендуем следующие меры по снижению риска:
Используйте собственные функции устройства SD-WAN (суммирование маршрутов и фильтрацию), чтобы ограничить количество маршрутов, объявленных на сервер маршрутизации, если оно доступно.
Используйте оповещения Azure Monitor для упреждающего обнаружения пиков в количестве маршрутов, которые объявляют шлюзы ExpressRoute. Отслеживайте метрику количество маршрутов, объявленных соседу.
Одноранговые узлы BGP
Сервер маршрутизации может устанавливать сеансы BGP с максимальным числом BGP-пиров. Это ограничение определяет, сколько SD-WAN NVAs может устанавливать подключения BGP с помощью сервера маршрутизации. Он также определяет максимальную агрегированную пропускную способность, которую можно поддерживать во всех SD-WAN туннелях. Ожидается, что только крупные сети SD-WAN достигнут этого ограничения. Обходной путь не существует, помимо создания нескольких центральной и периферийных сетей, каждый из которых имеет собственные шлюзы и серверы маршрутов.
Участвующие виртуальные машины
Шлюзы виртуальной сети ExpressRoute и Route Server настраивают маршруты, которые они получают от удалённых одноранговых узлов, для всех виртуальных машин в своей виртуальной сети и в виртуальных сетях, связанных прямым пирингом. Чтобы защитить сервер маршрутизации от чрезмерного потребления ресурсов от маршрутизации обновлений на виртуальные машины, Azure определяет ограничение количества виртуальных машин в одной сети концентратора и периферийной сети. Настройте емкость сервера маршрутизации на основе ожидаемого количества виртуальных машин в центральной виртуальной сети, содержащей сервер маршрутизации и во всех прямых пиринговых виртуальных сетях.
Contributors
Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.
Основные авторы:
- Федерико Геррини | Старший архитектор облачных решений
- Хуш Кавирадж | Архитектор облачных решений
Чтобы увидеть непубличные профили в LinkedIn, войдите в LinkedIn.