Звездообразная топология сети

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

  • Сокращение затрат и эффективное управление. Централизация служб, которые могут совместно использоваться несколькими рабочими нагрузками, такими как сетевые виртуальные устройства (NVA) и DNS-серверы. Одно расположение для служб позволяет ИТ-отделу минимизировать избыток ресурсов и усилия по управлению.

  • Преодоление ограничения подписок. Большим облачным рабочим нагрузкам может потребоваться больше ресурсов, чем содержится в рамках одной подписки Azure Пиринг рабочей нагрузки виртуальных сетей из различных подписок в центральный концентратор может преодолеть эти ограничения. Дополнительные сведения см. в статье Ограничения подписки Azure.

  • Разделение проблем: можно развертывать отдельные рабочие нагрузки между центральными ИТ-командами и группами рабочих нагрузок.

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

Примечание.

На сайте эталонных архитектур Azure содержатся примеры шаблонов, которые вы можете использовать в качестве основы для реализации собственных звездообразных сетей:

Обзор

Схема, показывающая пример топологии сети концентратора и периферийной сети.

Рис. 1. Пример звездообразной топологии сети.

Как показано на диаграмме, среда Azure поддерживает два типа звездообразного проектирования. Первый тип поддерживает взаимодействие, общие ресурсы и централизованную политику безопасности. Этот тип помечен на диаграмме как VNet Hub. Второй тип основан на виртуальной глобальной сети Azure, которая помечена на диаграмме как Virtual WAN. Этот тип предназначен для крупномасштабных взаимодействий типа "ветвь — ветвь" и "ветвь — Azure".

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

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

  • Служба DNS разрешает имена рабочих нагрузок в периферийных зонах и получает доступ к ресурсам локально и в Интернете, если Azure DNS не используется.
  • Инфраструктура открытых ключей для реализации единого входа в рабочие нагрузки.
  • Управление TCP- и UDP-трафиком осуществляется между зонами периферийных сетей и Интернетом.
  • Управление потоком осуществляется между периферийными зонами и локальными ресурсами.
  • Управление потоком осуществляется между несколькими периферийными зонами (при необходимости).

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

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

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

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

Ограничения подписки и несколько центральных зон

В Azure каждый компонент (независимо от типа) развертывается в подписке Azure. Изоляция компонентов Azure в разных подписках Azure позволяет выполнять требования различных бизнес-приложений, например настройку дифференцированных уровней доступа и авторизации.

Отдельную звездообразную сеть можно масштабировать для большого количества периферийных зон, но, как и в случае с любой ИТ-системой, существуют ограничения платформы. Развертывание концентратора привязано к определенной подписке Azure, которая имеет ограничения, например максимальное количество пирингов между виртуальными сетями. Дополнительные сведения см. в статье Подписка Azure и ограничения службы.

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

  • Пиринг между виртуальными сетями
  • Azure ExpressRoute
  • Виртуальная глобальная сеть Azure
  • VPN типа "сеть-сеть"

Схема, показывающая кластер концентраторов и периферийных компонентов.

Рис. 2. Кластер концентраторов и периферийных зон.

Включение нескольких концентраторов приводит к увеличению затрат и накладных расходов на управление. Это увеличение можно оправдать только:

  • Масштабируемость
  • ограничениями системы;
  • избыточностью и региональной репликацией для производительности пользователей или аварийного восстановления.

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

Взаимодействие между периферийными зонами

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

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

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

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

Рис. 3. Пример периферийных зон, соединяющихся друг с другом и с концентратором.

Периферийные зоны могут также взаимодействовать с периферийной зоной, выполняющей функции концентратора. Такой подход создает двухуровневую иерархию: периферийная зона высокого уровня (уровень 0) становится концентратором подчиненных периферийных зон (уровень 1) иерархии. Периферийные серверы должны переадресовать трафик в центральный концентратор. Суть этого требования — в том, чтобы трафик мог проходить к своей цели в локальной сети либо в общедоступном Интернете. Такая архитектура концентратора представляет сложную маршрутизацию, что сводит на нет преимущества отдельной звездообразной связи.

Примечание.

Azure виртуальная сеть Manager (AVNM) можно использовать для создания новых или подключенных существующих топологий виртуальной сети и периферийных топологий виртуальной сети для централизованного управления подключением и средствами управления безопасностью.

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

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

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

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