Проектирование для аварийного восстановления с помощью частного пиринга 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 с расположением обеих сетей в одной сети общего пользования. Вы выполняете эту задачу с тем же поставщиком или выбираете работу с другим поставщиком услуг для повышения устойчивости. Другое преимущество такого подхода заключается в том, что при отработке отказа приложения, сквозная задержка между локальными приложениями и корпорацией Майкрософт остается приблизительно одинаковой. Тем не менее, если есть стихийные бедствия, такие как землетрясение, подключение к обоим путям больше не может быть доступно.

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

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

Примечание.

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

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

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

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

Diagram of small to medium size on-premises network considerations.

По умолчанию, если вы объявляете маршруты одинаково по всем путям ExpressRoute, azure load-balances on-bound traffics on-bound traffics all the ExpressRoute path using Equal-cost multi-path (ECMP) routing.

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

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

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

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

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

Diagram of influencing path selection using more specific routes.

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

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

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

Screenshot of configuring connection weight via Azure portal.

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

Diagram of influencing path selection using connection weight.

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

Добавление к началу пути автономной системы

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

Diagram of influencing path selection using AS path prepend.

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

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

Важно!

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

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

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

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

Diagram of large distributed on-premises network considerations.

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

Сценарий 1

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

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

Diagram of traffic flow for first scenario.

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

Diagram of active-active ExpressRoute circuits solution 1.

Сценарий 2

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

Diagram of traffic flow for second scenario.

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

Diagram of active-active ExpressRoute circuits solution 2.

Важно!

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

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

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