Поделиться через

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

  • Статья

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

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

Примечание.

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

В этой статье мы рассмотрим, как решать проблемы, которые могут возникнуть при настройке геоизбыточных путей.

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

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

Схема: рекомендации для локальных сетей малого и среднего размера.

По умолчанию, если вы объявляете маршруты одинаково по всем путям ExpressRoute, Azure распределяет трафик, направленный на локальную сеть, по всем путям ExpressRoute, используя маршрутизацию Equal-cost multi-path (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 два локальных расположения, подключенных через каналы ExpressRoute к двум развертываниям Contoso IaaS в двух разных регионах Azure в различных местах пиринга.

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

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

Сценарий 1

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

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

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

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

Схема каналов ExpressRoute типа

Сценарий 2

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

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

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

Схема: решение 2 с каналами ExpressRoute типа

Внимание

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

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

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