Проектирование системы аварийного восстановления с использованием частного пиринга ExpressRoute

ExpressRoute предназначен для обеспечения высокого уровня доступности для обеспечения подключения частной сети уровня оператора к Microsoft ресурсам. Иными словами, по пути ExpressRoute в сети Майкрософт нет единой точки отказа. Рекомендации по проектированию для максимальной доступности канала ExpressRoute см. в статье "Проектирование обеспечения высокой доступности с помощью ExpressRoute " и Well-Architected Framework.

Тем не менее, принимая во внимание популярную поговорку Мёрфи (если что-то может пойти не так, оно пойдёт не так), эта статья посвящена решениям, которые позволяют справляться со сбоями, выходящими за пределы возможностей одного канала ExpressRoute. В нем рассматриваются аспекты сетевой архитектуры при построении надежной сетевой связности серверной части для аварийного восстановления с использованием геоизбыточных каналов ExpressRoute.

Примечание.

Основные понятия, описанные в этой статье, справедливы для создания канала ExpressRoute в Виртуальной глобальной сети или за ее пределами.

Необходимость решения для избыточного подключения

Точки пиринга ExpressRoute или весь региональный сервис могут ухудшиться. Масштабный сбой в работе сервиса на уровне региона может быть вызван стихийным бедствием. Планирование аварийного восстановления для обеспечения непрерывности бизнес-процессов и критически важных приложений.

Примечание.

Если необходимо реализовать проект аварийного восстановления в ситуации с учетом времени, например для обеспечения непрерывности бизнес-процессов во время стихийных бедствий, следует учитывать следующие факторы:

  • В этом документе даются рекомендации по реализации надёжного плана аварийного восстановления для нескольких каналов ExpressRoute, настроенных в различных точках пиринга. В этом сценарии предполагается, что у вас достаточно времени и ресурсов для настройки каналов ExpressRoute.
  • Если вам нужно быстро настроить проект аварийного восстановления для одного канала ExpressRoute, который не является геоизбыточным, можно использовать следующие варианты:

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

Если вы полагаетесь на подключение ExpressRoute между локальной сетью и Корпорацией Майкрософт, необходимо рассмотреть следующее, чтобы спланировать аварийное восстановление через ExpressRoute:

Сложности при использовании нескольких каналов ExpressRoute

При взаимном подключении одного и того же набора сетей с использованием нескольких соединений создаются параллельные пути между сетями. Дублирующие пути, если они спроектированы неправильно, могут стать причиной асимметричной маршрутизации. Если у вас есть сущности с состоянием, например NAT или брандмауэр на маршруте, асимметричная маршрутизация может заблокировать поток трафика. Как правило, в частном пиринге ExpressRoute вы не сталкиваетесь с активными компонентами, такими как NAT или брандмауэры. Поэтому асимметричная маршрутизация через частный пиринг ExpressRoute не обязательно блокирует поток трафика.

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

Избыточность с помощью каналов ExpressRoute в одном и том же мегаполисе

Многие городские районы имеют две точки присутствия ExpressRoute. Примером будет Амстердам и Амстердам2. При проектировании резервирования можно создать два параллельных пути к Azure, с местоположением обоих в одной метрополии. Вы выполняете эту задачу с тем же поставщиком или выбираете работу с другим поставщиком услуг для повышения устойчивости. Другое преимущество этого дизайна заключается в том, что при срабатывании отказоустойчивости приложения сквозная задержка между локальными приложениями и Microsoft остается примерно такой же. Тем не менее, если есть природная катастрофа, например землетрясение, подключение к обоим путям может быть недоступно.

Избыточность с помощью цепей ExpressRoute в разных столичных городах

При использовании разных метро для избыточности следует выбрать дополнительное расположение в одном и том же геополитическом регионе. Чтобы выбрать расположение за пределами геополитического региона, необходимо использовать премиальный SKU для обеих цепей в параллельных цепях. Преимущество этой конфигурации в том, что вероятность того, что природное бедствие приведет к выходу из строя обоих каналов, ниже, но это сопровождается увеличением задержки по всей цепочке передачи.

Примечание.

Включение BFD для каналов ExpressRoute поможет ускорить обнаружение сбоев связи между устройствами Microsoft Enterprise Edge (MSEE) и маршрутизаторами Edge клиента или партнера. Однако общая отказоустойчивость и переключение на резервный сайт может занять до 180 секунд в некоторых условиях сбоя, и вы можете столкнуться с увеличением задержки или снижением производительности в течение этого времени.

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

Рекомендации для малых и средних локальных сетей

Рассмотрим пример сети, показанной на следующей схеме. В этом примере создается геоизбыточное подключение ExpressRoute между локальной инфраструктурой Contoso и виртуальной сетью Contoso в регионе Azure. На схеме сплошная синяя линия обозначает предпочтительный путь (через ExpressRoute 1), а пунктирная — резервный путь (через ExpressRoute 2).

Схема небольших и средних параметров локальной сети.

По умолчанию, если вы объявляете маршруты одинаково по всем путям ExpressRoute, Azure распределяет локальный трафик по максимум четырем каналам ExpressRoute, используя маршрутизацию с равной стоимостью по нескольким путям (ECMP).

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

Можно повлиять на Azure, отдавая предпочтение одному каналу ExpressRoute в отличие от другого, используя один из следующих методов (перечислены в порядке эффективности):

  • реклама более конкретного маршрута по предпочтительному каналу ExpressRoute по сравнению с другими каналами ExpressRoute
  • Настройка более высокого приоритета подключения для связи виртуальной сети с предпочтительным каналом связи ExpressRoute.
  • объявление маршрутов через менее предпочтительный канал ExpressRoute с более длинным путем в системе AS (добавление префиксов AS Path)

Более конкретный маршрут

На следующей схеме показано, как более точное рекламирование маршрута влияет на выбор пути ExpressRoute. На иллюстрируемом примере в локальной сети Contoso диапазон IP-адресов /24 анонсируется как два диапазона /25 через предпочтительный путь (ExpressRoute 1) и как /24 через резервный путь (ExpressRoute 2).

Схема влияния на выбор пути с помощью более конкретных маршрутов.

Поскольку адрес /25 является более конкретным по сравнению с /24, Azure отправляет трафик, предназначенный для диапазона 10.1.11.0/24, через ExpressRoute 1 в обычном состоянии. Если оба подключения ExpressRoute 1 выходят из строя, виртуальная сеть будет видеть объявление маршрута 10.1.11.0/24 только через ExpressRoute 2, и поэтому резервная линия используется в этой ситуации сбоя.

Вес соединения

На следующем снимке экрана показано, как настроить вес соединения ExpressRoute с помощью портала Azure.

Снимок экрана: настройка веса подключения с помощью портала Azure.

На следующей схеме показано влияние на выбор пути ExpressRoute в зависимости от веса соединения. Значение веса соединения по умолчанию равно 0. В следующем примере вес подключения для ExpressRoute 1 настраивается как 100. Когда виртуальная сеть получает префикс маршрута, объявленный через несколько каналов ExpressRoute, она предпочитает подключение с наибольшим весом.

Схема влияния на выбор пути с помощью веса подключения.

Если оба подключения ExpressRoute 1 выходят из строя, виртуальная сеть будет видеть объявление маршрута 10.1.11.0/24 только через ExpressRoute 2, и поэтому резервная линия используется в этой ситуации сбоя.

Добавление префиксов в путь AS

На следующей схеме показано, как добавление префикса к пути AS влияет на выбор маршрута ExpressRoute. На схеме объявление маршрута через ExpressRoute 1 указывает на поведение eBGP по умолчанию. В объявлении маршрута через ExpressRoute 2 ASN локальной сети дополнительно добавляется на маршруте AS. Когда один и тот же маршрут получен через несколько каналов ExpressRoute, в соответствии с процессом выбора маршрута eBGP, виртуальная сеть предпочтёт маршрут с самым коротким путем AS.

Схема влияния на выбор пути с использованием AS path prepend.

Если оба подключения ExpressRoute 1 вышли из строя, виртуальная сеть будет видеть объявление маршрута 10.1.11.0/24 только через ExpressRoute 2. Следовательно, более длинный путь AS станет неуместным. Поэтому резервная цепь будет использоваться в этом случае сбоя.

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

Внимание

При использовании определенных каналов ExpressRoute в режиме резерва необходимо активно осуществлять управление ими и периодически проверять процесс отказоустойчивости.

Крупная распределенная корпоративная сеть

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

Рассмотрим пример, показанный на следующей схеме. В этом примере у Contoso есть две локальные площадки, подключенные к двум развертываниям IaaS Contoso в двух разных регионах Azure через каналы ExpressRoute в двух разных точках пиринга.

Схема рекомендаций по распределенной локальной сети.

То, как вы проектируете аварийное восстановление, влияет на то, как маршрутизируется трафик при переходе из межрегиональной в межлокационную схему (из регион1/регион2 в локация2/локация1). Рассмотрим две архитектуры аварийного восстановления, которые по-разному маршрутизируют трафик между площадками в разных регионах.

Сценарий 1

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

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

Схема потока трафика для первого сценария.

Этот сценарий можно спроектировать, используя вес соединения, чтобы виртуальные сети предпочитали подключение к локальной точке пиринга ExpressRoute для трафика, направляемого в локальную сеть. Чтобы завершить реализацию решения, необходимо обеспечить симметричный обратный поток трафика. Вы можете использовать атрибут local preference в сеансе iBGP между вашими BGP-маршрутизаторами, на которых каналы ExpressRoute завершаются на стороне локальной инфраструктуры, чтобы отдать предпочтение каналу ExpressRoute. Решение показано на приведенной ниже схеме.

Схема решения 1 для активно-активных каналов ExpressRoute.

Сценарий 2

Сценарий 2 показан на схеме ниже. На схеме зелеными линиями обозначены пути для потока трафика между виртуальной сетью 1 и локальными сетями. На схеме синими линиями обозначены пути для потока трафика между виртуальной сетью 2 и локальными сетями. В устойчивом состоянии весь трафик между виртуальными сетями и локальными расположениями обычно используется магистралью Microsoft. Он проходит через соединение между локальными расположениями только в состоянии сбоя, которое обозначено пунктирными линиями на схеме ExpressRoute.

Схема потока трафика для второго сценария.

Решение показано на приведенной ниже схеме. Как показано на рисунке, эту схему можно построить либо с помощью более конкретного маршрута (вариант 1), либо с помощью AS-path prepend (вариант 2), чтобы повлиять на выбор маршрута виртуальной сети. Чтобы повлиять на выбор локального сетевого маршрута для трафика, направляемого в Azure, необходимо настроить подключение к локальной площадке как менее предпочтительное. Как предпочтительно настроить канал межсетевого взаимодействия, зависит от протокола маршрутизации, используемого в локальной сети. Можно использовать локальные предпочтения с помощью iBGP или метрику с помощью IGP (OSPF или IS-IS).

Схема активно-активных каналов ExpressRoute, решение 2.

Внимание

Если один или несколько каналов ExpressRoute подключены к нескольким виртуальным сетям, трафик из одной виртуальной сети в другую виртуальную сеть можно направить через ExpressRoute. Однако это делать не рекомендуется. Чтобы включить подключение виртуальной сети к виртуальной сети, настройте пиринг виртуальных сетей.

Связанный контент

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

  • Last updated on