Топология неструктурированных сетей с одной рабочей нагрузкой

Плоская сеть — это простейшая Azure топология сети: одна виртуальная сеть с несколькими подсетями, где размещена одна рабочая нагрузка. В этой статье объясняется, когда следует использовать этот шаблон и как его реализовать.

Описание этой статьи

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

Кто нуждается в этой статье

Ознакомьтесь с этой статьей, если:

• Вы развертываете первую рабочую нагрузку в Azure.
• Одна команда владеет всеми ресурсами и управляет всеми ресурсами.
• Вам не нужны общие сетевые службы (брандмауэр, бастион, шлюз) для нескольких рабочих нагрузок.
• Вам нужна самая простая сеть, которая по-прежнему обеспечивает изоляцию и безопасность на уровне подсети.

Акцент на миграции “как есть”: Одна плоская виртуальная сеть (VNet) с отдельной подсетью для каждого компонента часто становится оптимальным первым шагом при переносе одной рабочей нагрузки в одном регионе.

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

Ориентация на мультиоблачную среду: Используйте плоскую сеть VNet как единую точку присутствия в Azure при миграции между облаками: сначала разверните рабочую нагрузку, а затем спланируйте её адресное пространство и сегментацию, чтобы по мере развития архитектуры её можно было подключить к хабу или Виртуальная глобальная сеть.

Azure службы и функции

Топология неструктурированных сетей использует следующие основные службы Azure:

Service	Роль в этой топологии
Виртуальная сеть Azure	Предоставляет частное изолированное адресное пространство для ваших рабочих нагрузок. Виртуальная сеть ограничена одним регионом Azure.
Подсети + группы безопасности сети (группы безопасности сети)	Подсети разделяют уровни приложений. Группы безопасности сети фильтруют входящий и исходящий трафик на каждой границе подсети. Группы безопасности сети являются состояниезависимыми: обратный трафик для разрешённых соединений разрешается автоматически.
Зона Azure Частная зона DNS	Предоставляет внутреннее разрешение имён для ресурсов в виртуальной сети. Свяжите зону с включенным авторегистрированием, чтобы виртуальные машины автоматически получили записи DNS.
Подсеть шлюза(необязательно)	Размещает VPN-шлюз или шлюз ExpressRoute, если требуется одно подключение к локальной сети.

Как выбрать: оставить плоскую архитектуру или перейти на модель «хаб-спица»?

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

Condition	Recommendation
Отдельная рабочая нагрузка, отдельная команда, без общих служб	Пребывание в квартире: эта статья применяется
Для второй независимой рабочей нагрузки требуется собственная сетевая изоляция	Перейдите на топологию «концентратор — периферия»
Вам нужен общий брандмауэр, VPN-шлюз или Бастион Azure между рабочими нагрузками.	Выпускник топологии концентратора и периферийной топологии
Политики безопасности должны управляться централизованно в нескольких рабочих нагрузках.	Выпускник топологии концентратора и периферийной топологии

Tip

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

Рекомендации по проектированию

Акцент на проектировании плоской сети по модели lift-and-shift

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

Модернизация фокуса на проектировании плоской сети

• Используйте плоскую сеть для раннего пилотного внедрения PaaS или одной модернизированной рабочей нагрузки: поместите уровни приложения в подсети и обеспечьте доступ к Azure PaaS через частные конечные точки в выделенной подсети.
• Заранее резервируйте выделенные подсети для служб платформы, которые вы планируете добавить, таких как Application Gateway и частные конечные точки, чтобы сеть могла расти без перенумерации адресов.
• Применяйте группы безопасности сети (NSG) и группы безопасности приложений на каждом уровне, чтобы сегментация уже была настроена, если впоследствии рабочая нагрузка станет периферийным сегментом в топологии «концентратор — периферия».
• Следите за тем, чтобы адресное пространство не пересекалось с адресными пространствами других регионов и виртуальных сетей, чтобы позже можно было настроить пиринг или перейти на топологию с концентратором без перенумерации адресов.

Фокус на проектировании межоблачной плоской сети

• Используйте плоскую VNet как единую точку входа в Azure при миграции между облаками: сначала перенесите рабочую нагрузку, а затем по мере развития архитектуры подключите сетевую связность через центральный узел.
• Спланируйте адресное пространство плоской виртуальной сети (VNet) так, чтобы оно не пересекалось с VPC в AWS и сетями Google Cloud, чтобы в дальнейшем эту сеть можно было подключить к IPsec или маршрутизации через Interconnect без трансляции адресов.
• Сохраняйте сегментацию по уровням с помощью групп безопасности сети (NSG), чтобы профиль безопасности рабочей нагрузки сохранялся при ее преобразовании в спицу за защищенным концентратором Виртуальная глобальная сеть.
• Стандартизируйте именование подсети и теги для сопоставления с другими облаками, чтобы рабочая нагрузка была легко сопоставить во время и после миграции.

Prerequisites

Перед реализацией этой топологии выполните следующие действия:

• Подписка Azure с разрешениями на создание виртуальных сетей и групп безопасности сети (NSG).
• Планируемое пространство IP-адресов. Адресное пространство /16 предоставляет 65 536 адресов, что является общей отправной точкой для одной рабочей нагрузки. Azure резервирует 5 адресов на подсеть для внутреннего использования. Подробные инструкции см. в разделе "Планирование IP-адресации".
• Понимание уровней приложений (например, веб-приложений и данных) позволяет сопоставить их с подсетями. Руководство по проектированию подсети см. в разделе "Проектирование виртуальных сетей и подсетей".

Макет сети

Топология неструктурированных сетей следует этой структуре:

• Одна виртуальная сеть с одним адресным пространством (например, 10.0.0.0/16).
• Несколько подсетей: один на уровень приложения или компонент:
  • Подсеть веб-уровня (например, 10.0.1.0/24).
  • Подсеть уровня приложений (например, 10.0.2.0/24).
  • Подсеть уровня данных (например, 10.0.3.0/24).
  • Подсеть шлюза (необязательно, например 10.0.255.0/27).
• NSG, назначенные каждой подсети с правилами, разрешающими только тот трафик, который нужен каждому уровню.
• Одна частная зона DNS, связанная с виртуальной сетью с включённой авторегистрацией.

Note

Тщательно спланируйте диапазоны IP-адресов. Если впоследствии вы перейдёте на топологию типа «концентратор — периферия», периферийные виртуальные сети должны иметь диапазоны CIDR, не пересекающиеся с диапазонами концентратора. Выбор хорошо структурированной схемы адресов теперь предотвращает конфликты во время миграции.

Вопросы безопасности

Примените эти методики безопасности к неструктурированной сети:

• Группы безопасности сети в каждой подсети. Начните с базового правила запрета всех входящих подключений и добавьте конкретные разрешающие правила для разрешённого трафика между уровнями. Например, разрешите HTTPS из веб-уровня на уровень приложения и разрешите SQL из уровня приложений на уровень данных.
• На виртуальных машинах нет общедоступных IP-адресов. Публикуйте сервисы через балансировщик нагрузки или Application Gateway. Используйте Бастион Azure для административного доступа.
• Частная зона DNS для внутреннего разрешения. Частные зоны DNS предотвращают раскрытие внутренних имён узлов через общедоступные DNS-запросы.
• Изоляция подсети шлюза. При добавлении VPN или шлюза ExpressRoute поместите его в выделенную подсеть (с именем GatewaySubnet). Группы сетевой безопасности в подсети шлюза не поддерживаются. Связывание NSG с этой подсетью может привести к тому, что шлюз виртуальной сети перестанет работать, как не ожидалось.

Important

При удалении правила NSG, разрешающего соединение, существующие активные соединения продолжаются без прерывания. Блокируются только новые подключения, соответствующие удаленному правилу.

Связанные статьи

В следующих статьях приведены более подробные рекомендации по соответствующим темам:

• Проектирование виртуальных сетей и подсетей: изменение размера и размещения подсети для уровней рабочей нагрузки
• Планирование IP-адресов: планирование адресного пространства и выбор CIDR
• Проектирование групп безопасности сети: проектирование правил NSG и групп безопасности приложений
• Топология концентраторов и периферийных серверов: следующая топология, которая будет применяться при росте сети.
• Защита от атак DDoS: если рабочая нагрузка предоставляет общедоступные конечные точки

Узнать больше

Дополнительные сведения о службах Azure, используемых в этой топологии, см. в следующих статье:

• Что такое Azure Virtual Network?
• Группы безопасности сети (NSG) — обзор
• Что такое Azure Частная зона DNS?
• Планирование виртуальной сети

Дальнейшие действия

Tip

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

Далее в пути лифта и смены:

Спроектируйте топологию «hub-and-spoke»: большинство миграций по модели lift-and-shift быстро перерастают возможности плоской сети. Планирование централизованных общих служб с самого начала.

Далее в пути модернизации:

Спроектируйте топологию «hub-and-spoke»: Модернизированные рабочие нагрузки с несколькими службами, средствами контроля безопасности и командами нуждаются в топологии «hub-and-spoke» с самого начала.

Следующий этап вашего мультиоблачного пути:

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