Наиболее распространенные шаблоны проектирования сетей в Azure включают создание топологий виртуальных сетей концентратора и периферийных виртуальных сетей в одном или нескольких регионах Azure, при необходимости подключенных к локальным сетям через Azure ExpressRoute или vpn-туннели типа "сеть — сеть" через общедоступный Интернет.
В большинстве руководств по проектированию основное внимание уделяется трафику приложений для этих виртуальных сетей от пользователей из внутренних локальных сетей или из Интернета (то, что отрасль обычно обозначает северо-южный трафик, так как она часто представлена вертикальными линиями на сетевых схемах). В этой статье рассматриваются различные шаблоны, доступные для трафика на востоке запада. То есть потоки обмена данными между рабочими нагрузками, развернутыми в виртуальных сетях Azure, в одном регионе или в разных регионах.
Чтобы обеспечить производительность, масштабируемость и устойчивость приложений, работающих в Azure, необходимо обеспечить производительность, масштабируемость и устойчивость сетевого дизайна.
Потенциальные варианты использования
Периферийный трафик может быть важным в нескольких сценариях:
- Разные уровни одного приложения находятся в отдельных виртуальных сетях. Например, сетевые серверы периметра (также называемые серверами DMZ) в виртуальной сети периметра взаимодействуют со службами приложений во внутренней виртуальной сети.
- Рабочие нагрузки приложений в разных средах (разработка, промежуточное развертывание, производство) должны реплицировать данные между собой.
- Различные приложения или микрослужбы должны взаимодействовать друг с другом.
- Базы данных должны реплицировать данные в разных регионах, чтобы гарантировать непрерывность бизнес-процессов в случае аварии.
- Пользователи находятся в виртуальных сетях Azure. Например, они используют виртуальный рабочий стол Azure.
Шаблоны и топологии для межсайтового взаимодействия
Существует два основных топологии, которые можно использовать в проектах Azure, которые пересекают несколько виртуальных сетей: традиционный концентратор и периферийный центр и Azure Виртуальная глобальная сеть. В среде Виртуальная глобальная сеть корпорация Майкрософт управляет виртуальной сетью концентратора и всем в ней. В традиционной центральной и периферийной среде вы управляете виртуальной сетью концентратора.
Виртуальная глобальная сеть и высокоуровневые топологии являются примерами архитектур, в которых рабочие нагрузки выполняются в периферийных виртуальных сетях и подключение к локальной сети централизованно в виртуальной сети концентратора. Так много концепций, описанных в этой статье, применяются как к концентратору, так и к Виртуальная глобальная сеть дизайнам.
Существует два основных шаблона подключения периферийных виртуальных сетей друг к другу:
- Периферийные устройства напрямую подключены друг к другу. Пиринги виртуальных сетей или VPN-туннели создаются между периферийными виртуальными сетями, чтобы обеспечить прямое подключение без обхода виртуальной сети концентратора.
- Периферийные устройства взаимодействуют по сетевому устройству. Каждая периферийная виртуальная сеть имеет пиринг для Виртуальная глобальная сеть или виртуальной сети концентратора. Устройство направляет трафик от периферийной к периферийной. Устройство можно управлять корпорацией Майкрософт (как и Виртуальная глобальная сеть) или вами.
Шаблон 1. Периферийные периферийные устройства напрямую подключены друг к другу
Прямые подключения между периферийными устройствами обычно обеспечивают лучшую пропускную способность, задержку и масштабируемость, чем подключения, которые проходят через сетевое виртуальное устройство (NVA) в концентраторе. Отправка трафика через NVAs может добавить задержку в трафик, если NVAs находятся в другой зоне доступности, и при отправке трафика через концентратор необходимо перекрестить по крайней мере два пиринга виртуальной сети. Существует несколько вариантов подключения двух периферийных виртуальных сетей друг к другу напрямую: пиринг между виртуальными сетями, диспетчер виртуальная сеть Azure и VPN-туннели.
Пиринг между виртуальными сетями. Преимущества пиринга прямой виртуальной сети поверх периферийных компонентов:
- Снижение затрат, так как требуется меньше прыжков пиринга между виртуальными сетями.
- Улучшенная производительность, так как трафик не должен проходить через сетевое устройство, которое приводит к задержке или потенциальным узким местам.
Другие сценарии включают подключение между клиентами. Однако может потребоваться проверить трафик между периферийными виртуальными сетями, что может потребовать отправки трафика через централизованные сетевые устройства в виртуальной сети концентратора.
Диспетчер виртуальная сеть Azure. Помимо преимуществ пиринга виртуальных сетей, Azure виртуальная сеть Manager предоставляет службу управления, которая позволяет управлять средами виртуальной сети и создавать подключения в масштабе. С помощью Диспетчера виртуальная сеть Azure можно создать три типа топологий в подписках как для существующих, так и для новых виртуальных сетей:
Концентратор и периферийные устройства, которые не подключены друг к другу.
Концентратор и говорил с спицами, которые напрямую связаны друг с другом, без какого-либо прыжка в середине.
Сетчатая группа виртуальных сетей, которые связаны между собой.
Скачайте все схемы Visio в этой статье.
При создании топологии концентратора и периферийной связи с диспетчером виртуальная сеть Azure, в котором периферийные периферийные серверы подключены друг к другу, прямое подключение между периферийными виртуальными сетями в той же группе сети автоматически создаются двунаправленно. С помощью Диспетчера виртуальная сеть Azure можно статически или динамически создавать члены периферийных виртуальных сетей определенной группы сети, которая автоматически создает подключение для любой виртуальной сети.
Можно создать несколько сетевых групп, чтобы изолировать кластеры периферийных виртуальных сетей от прямого подключения. Каждая сетевая группа обеспечивает одну и ту же область и многорегионную поддержку подключения между периферийными сетями. Не забудьте оставаться ниже максимальных ограничений для диспетчера виртуальная сеть Azure, описанных в разделе "Часто задаваемые вопросы о диспетчере виртуальная сеть Azure".
VPN-туннели, подключающие виртуальные сети. Vpn-службы можно настроить для прямого подключения периферийных виртуальных сетей с помощью VPN-шлюзов Майкрософт или сторонних виртуальных виртуальных сетей VPN. Преимущество этого варианта заключается в том, что периферийные виртуальные сети подключаются между коммерческими и независимыми облаками в пределах одного поставщика облачных служб или подключения между облачными поставщиками. Кроме того, если в каждой периферийной виртуальной сети есть сетевые сети, определяемые программным обеспечением (SD-WAN), эта конфигурация может упростить использование уровня управления стороннего поставщика и набора функций для управления подключением к виртуальной сети.
Этот параметр также поможет вам соответствовать требованиям к шифрованию трафика между виртуальными сетями в одном центре обработки данных Azure, который еще не предоставляется шифрованием MACsec. Но этот вариант поставляется с собственным набором проблем из-за ограничений пропускной способности туннелей IPsec (1,25 Гбит/с на туннель) и ограничений проектирования наличия шлюзов виртуальной сети как в концентраторе, так и в периферийных виртуальных сетях: если у периферийной виртуальной сети есть шлюз виртуальной сети, он не может быть подключен к Виртуальная глобальная сеть или использовать шлюз виртуальной сети концентратора для подключения к локальным сетям.
Шаблон 1. Один регион
Независимо от технологии, используемой для подключения периферийных виртуальных сетей друг к другу, топологии сети будут выглядеть следующим образом для одного региона:
Шаблон 1. Несколько регионов
Проекты, которые подключают все периферийные виртуальные сети друг к другу, также можно расширить в несколько регионов. В этой топологии диспетчер виртуальная сеть Azure еще более важен, чтобы сократить административные расходы на обслуживание требуемого большого количества подключений.
Примечание.
При подключении периферийных виртуальных сетей напрямую в одном регионе или в нескольких регионах рекомендуется использовать периферийные виртуальные сети в одной среде. Например, подключите одну периферийную виртуальную сеть разработки с другой виртуальной сетью разработки. Но не следует подключать виртуальную сеть разработки к периферийной рабочей виртуальной сети.
При непосредственном подключении периферийных виртуальных сетей друг к другу в полностью сетчатой топологии необходимо учитывать потенциально большое количество пирингов виртуальных сетей. На следующей схеме показана эта проблема. В этом сценарии диспетчер виртуальная сеть Azure настоятельно рекомендуется создавать подключения виртуальной сети автоматически.
Шаблон 2. Периферийные устройства, взаимодействующие по сетевому устройству
Вместо подключения периферийных виртуальных сетей напрямую друг к другу можно использовать сетевые устройства для пересылки трафика между периферийными устройствами. Сетевые устройства предоставляют дополнительные сетевые службы, такие как глубокая проверка пакетов и сегментация трафика или мониторинг, но они могут привести к задержке и узким местам производительности, если они неправильно размером. Обычно эти устройства находятся в центральной виртуальной сети, к которым подключаются периферийные устройства. Существует несколько вариантов использования сетевого устройства для пересылки трафика между периферийными устройствами:
маршрутизатор Виртуальная глобальная сеть концентратора. Полностью управляемая корпорацией Майкрософт, Виртуальная глобальная сеть содержит виртуальный маршрутизатор, который привлекает трафик из периферийных устройств и направляет его в другую виртуальную сеть, подключенную к Виртуальная глобальная сеть или к локальным сетям через ExpressRoute или vpn-туннели типа "сеть — сеть" или "точка — сеть". Маршрутизатор Виртуальная глобальная сеть автоматически масштабируется вверх и вниз, поэтому необходимо убедиться, что объем трафика между периферийными узлами остается в пределах Виртуальная глобальная сеть ограничений.
Брандмауэр Azure. Брандмауэр Azure — это сетевое устройство, управляемое корпорацией Майкрософт, и его можно развернуть в центральных виртуальных сетях, управляемых или в Виртуальная глобальная сеть центрах. Он может пересылать IP-пакеты, а также проверять их и применять правила сегментации трафика, определенные в политиках. Он обеспечивает автоматическое масштабирование до Брандмауэр Azure ограничений, чтобы он не стал узким местом. Обратите внимание, что Брандмауэр Azure предоставляет встроенные возможности для нескольких регионов только при использовании с Виртуальная глобальная сеть. Без Виртуальная глобальная сеть необходимо реализовать определяемые пользователем маршруты для достижения межрегиональная связь между периферийными данными.
Сторонние сетевые виртуальные устройства. Если вы предпочитаете использовать сетевое виртуальное устройство от партнера Майкрософт для выполнения маршрутизации и сегментации сети, можно развернуть сетевые виртуальные устройства в концентраторе или в Виртуальная глобальная сеть топологии. Дополнительные сведения см. в статье "Развертывание высокодоступных NVAs" или NVAs в центре Виртуальная глобальная сеть. Необходимо убедиться, что сетевое виртуальное устройство поддерживает пропускную способность, созданную межресресной связью.
Azure VPN-шлюз. Vpn-шлюз Azure можно использовать в качестве типа следующего прыжка определяемого пользователем маршрута, но корпорация Майкрософт не рекомендует использовать шлюзы ВИРТУАЛЬНОй сети VPN для маршрутизации периферийного трафика. Они предназначены для шифрования трафика на локальные сайты или VPN-пользователей. Например, нет гарантии пропускной способности между периферийными узлами, которые VPN-шлюз может маршрутизировать.
ExpressRoute. В определенных конфигурациях шлюз ExpressRoute может объявлять маршруты, которые привлекают связь между периферийными устройствами, отправляя трафик на маршрутизатор Microsoft Edge, где он направляется в целевой периферийный сервер. Корпорация Майкрософт настоятельно не рекомендует этот сценарий, так как она вводит задержку, отправляя трафик на магистральный край Майкрософт и обратно. Поверх этого корпорация Майкрософт не рекомендует этот подход из-за единой точки сбоя и большого радиуса взрыва. Этот сценарий также приводит к нескольким проблемам, вызванным дополнительным давлением на инфраструктуру ExpressRoute (шлюз и физические маршрутизаторы). Это дополнительное давление может вызвать падение пакетов.
В центральной и периферийной сети, которые имеют централизованные NVA, устройство обычно помещается в концентратор. Пиринги виртуальных сетей между концентраторами и периферийными виртуальными сетями необходимо создавать вручную или автоматически с помощью Диспетчера виртуальная сеть Azure:
Пиринги виртуальных сетей вручную. Этот подход достаточно, если у вас небольшое количество периферийных виртуальных сетей, но она создает затраты на управление в большом масштабе.
Диспетчер виртуальная сеть Azure. Как отмечалось ранее, Диспетчер виртуальная сеть Azure предоставляет функции для управления средами виртуальной сети и пирингами в масштабе. Конфигурации пиринга между концентраторами и периферийными виртуальными сетями автоматически настраиваются в двухнаправленном направлении для групп сети.
Диспетчер виртуальная сеть Azure предоставляет возможность статического или динамического добавления членства в виртуальной сети в определенную группу сети, которая автоматически создает пиринговое подключение для новых участников. Периферийные виртуальные сети в группах сети могут использовать vpn-подключение концентратора или шлюзы ExpressRoute. Не забудьте оставаться ниже максимальных ограничений для Диспетчера виртуальная сеть Azure.
Шаблон 2. Один регион
На следующей схеме показана топология с одним регионом, которая отправляет трафик между периферийными узлами через брандмауэр Azure, развернутый в виртуальной сети концентратора. Трафик перенаправляется на централизованное устройство в концентраторе через определяемые пользователем маршруты, применяемые к периферийным подсетям.
В определенных обстоятельствах это может оказаться полезным для разделения сетевых виртуальных устройств, обрабатывающих периферийный и интернет-трафик для масштабируемости. Это разделение можно выполнить следующим образом:
- Настройка таблиц маршрутов в периферийных серверах для отправки частных адресов (тех, которые имеют маршрут для префиксов RFC 1918) в NVA, отвечающий за локальный трафик Azure и Azure в локальную среду (также называемый трафиком на востоке- запад).
- Настройка интернет-трафика (который имеет маршрут 0.0.0.0/0) на второй NVA. Эта NVA отвечает за трафик Azure в Интернет (также называется северо-южным трафиком).
На схеме ниже показана эта конфигурация.
Примечание.
Брандмауэр Azure требует, чтобы в виртуальной сети можно развернуть только один Брандмауэр Azure ресурс. Поэтому для дополнительных Брандмауэр Azure ресурсов требуется отдельная виртуальная сеть концентратора. В сценариях NVA можно использовать одну концентраторную виртуальную сеть для дополнительных развертываний NVA.
Шаблон 2. Несколько регионов
Вы можете расширить одну конфигурацию до нескольких регионов. Например, в макете концентратора и периферийных узлов, использующего Брандмауэр Azure, следует применить дополнительные таблицы маршрутов к подсетям Брандмауэр Azure в каждом концентраторе для периферийных компонентов в удаленном регионе. Эта конфигурация гарантирует, что трафик между регионами можно перенаправить между брандмауэрами Azure в каждой виртуальной сети концентратора. Межрегиональная трафик между периферийными виртуальными сетями затем проходит по обоим брандмауэрам Azure. Дополнительные сведения см. в разделе Брандмауэр Azure маршрутизации много концентратора и периферийной топологии:
Вариант проектирования с отдельными брандмауэрами Azure или сетевыми виртуальными устройствами для трафика на северо-юг и востоке-запад также можно использовать в топологии с несколькими регионами:
Примечание.
Брандмауэр Azure требует, чтобы в виртуальной сети можно развернуть только один Брандмауэр Azure ресурс. Поэтому для дополнительных Брандмауэр Azure ресурсов требуется отдельная виртуальная сеть концентратора. В сценариях NVA можно использовать одну концентраторную виртуальную сеть для дополнительных развертываний NVA.
Виртуальная глобальная сеть создает аналогичную топологию и принимает на себя сложность маршрутизации. Он делает это как в центрах (которым управляет Корпорация Майкрософт), так и в периферийных устройствах (где маршруты можно внедрить и не нужно вручную определять в таблицах маршрутов). Поэтому администратор сети должен подключать только периферийные виртуальные сети к центру Виртуальная глобальная сеть и не беспокоиться о переадресации трафика между регионами.
Гибридные шаблоны
Во многих ситуациях требуется гибридный подход, который объединяет два описанных выше шаблона. В этом подходе трафик между определенными периферийными устройствами должен проходить через прямые подключения, но остальные периферийные устройства взаимодействуют через центральное сетевое устройство. Например, в среде Виртуальная глобальная сеть можно напрямую подключить два конкретных периферийных устройства с высокой пропускной способностью и низкими требованиями к задержке. Другой сценарий включает в себя периферийные виртуальные сети, которые являются частью одной среды. Например, можно разрешить периферийной виртуальной сети разработки подключаться непосредственно к другой периферийной виртуальной сети разработки, но принудительно использовать рабочие нагрузки разработки и рабочей среды для обмена данными через центральное устройство.
Другой распространенный шаблон заключается в подключении периферийных устройств в одном регионе с помощью прямых пирингов виртуальных сетей или подключенных групп диспетчера виртуальная сеть Azure, но позволяет межрегионального трафика пересекать сетевые сети. Основная мотивация этой модели обычно заключается в уменьшении числа пирингов виртуальных сетей в архитектуре. Тем не менее, по сравнению с первой моделью (прямой подключение между периферийными устройствами), одним недостатком, представленным в этой модели, является больше прыжков пиринга виртуальной сети для трафика между регионами. Эти прыжки увеличивают затраты из-за нескольких пирингов виртуальных сетей, пересекающихся. Еще одним недостатком является дополнительная нагрузка на сетевые сети концентратора, чтобы перенаправить весь межрегионарный трафик.
Те же конструкции применимы для Виртуальная глобальная сеть. Однако одно из соображений заключается в том, что прямое подключение между периферийными виртуальными сетями необходимо настроить вручную непосредственно между виртуальными сетями, а не через ресурс Виртуальная глобальная сеть. Диспетчер виртуальная сеть Azure в настоящее время не поддерживает архитектуры, основанные на Виртуальная глобальная сеть. Например:
Примечание.
Для гибридных подходов важно понимать, что прямое подключение через пиринг между виртуальными сетями распространяет системные маршруты для подключения виртуальных сетей, которые часто являются более конкретными, чем пользовательские маршруты, настроенные с помощью таблиц маршрутов. Таким образом, путь пиринга виртуальной сети предпочтителен по пользовательским маршрутам, которые соответствуют самому длинному выбору маршрута префикса.
Однако в менее распространенных сценариях при наличии системного маршрута и пользовательского определяемого пользователем маршрута с одинаковым префиксом адреса определяемый пользователем маршрут имеет приоритет над системными маршрутами (автоматически созданным пирингом виртуальной сети). Это поведение приводит к обходу трафика виртуальной сети между периферийными сетями через виртуальную сеть концентратора, даже если есть прямое подключение через пиринг.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Основные авторы:
- Джей Ли | Старший менеджер по продуктам
- Хосе Морено | Главный инженер клиента
- Аледжандра Паласиос | Старший инженер по инфраструктуре Azure
Другие участники:
- Мик Альбертс | Технический писатель
- Мохамед Хасан | Главный диспетчер PM
- Андреа Майкл | Диспетчер программ
- Ясукуни Морисима | Инженер клиента II
- Jithin PP | Инженер клиента
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Cloud Adoption Framework: топология сети целевой зоны и подключение
- Пиринг виртуальной сети
- Диспетчер виртуальная сеть Azure
- Виртуальная глобальная сеть
- Брандмауэр Azure
- Безопасное сетевое подключение в Azure
- Общие сведения о виртуальная сеть Azure