Планирование интеграции сети для Azure Stack Hub

В этой статье приводятся сведения об инфраструктуре сети Azure Stack Hub, которые помогут решить, как лучше всего интегрировать Azure Stack Hub с существующей сетевой средой.

Примечание

Чтобы разрешить внешние DNS-имена из Azure Stack Hub (например, www.bing.com), необходимо предоставить DNS-серверы для пересылки ЗАПРОСОВ DNS. Дополнительные сведения о требованиях к DNS для Azure Stack Hub см. в статье Интеграция DNS центра обработки данных Azure Stack.

Структура физической сети

Чтобы поддерживать выполнение операций и работу служб, решению Azure Stack Hub требуется гибкая и высокодоступная физическая инфраструктура. Для интеграции Azure Stack Hub с сетью требуются восходящие связи от коммутаторов Top-of-Rack (ToR) к ближайшему коммутатору или маршрутизатору, который в этой документации называется Border. ToR можно связать с одной или парой границ. ToR предварительно настраивается с помощью нашего средства автоматизации. Он ожидает как минимум одно подключение между ToR и Border при использовании маршрутизации BGP и не менее двух подключений (по одному на toR) между ToR и Border при использовании статической маршрутизации, при этом не более четырех подключений в любом из вариантов маршрутизации. Эти подключения ограничены носителями SFP+ или SFP28 и имеют не менее одного ГБ скорости. Для обеспечения доступности проверка с поставщиком оборудования изготовителя оборудования (OEM). На следующей схеме представлен рекомендуемый макет.

Распределение пропускной способности

Azure Stack Hub создается с использованием технологий отказоустойчивого кластера Windows Server 2019 и прямых пространств. Часть конфигурации физической сети Azure Stack Hub выполняется для использования разделения трафика и гарантий пропускной способности, чтобы гарантировать, что обмен данными с хранилищем Spaces Direct может соответствовать производительности и масштабу, требуемым для решения. Конфигурация сети использует классы трафика для разделения прямых пространств, RDMA и обмена данными с использованием сети инфраструктурой и (или) клиентом Azure Stack Hub. В соответствии с текущими рекомендациями, определенными для Windows Server 2019, Azure Stack Hub меняется на использование дополнительного класса или приоритета трафика для дальнейшего разделения обмена данными между серверами для поддержки взаимодействия элементов управления отказоустойчивой кластеризации. Это новое определение класса трафика будет настроено для резервирования 2 % от доступной физической пропускной способности. Эта конфигурация резервирования трафика и пропускной способности выполняется путем изменения в коммутаторах верхнего уровня (ToR) решения Azure Stack Hub, а также на узле или серверах Azure Stack Hub. Обратите внимание, что изменения не требуются на пограничных сетевых устройствах клиента. Эти изменения обеспечивают лучшую устойчивость взаимодействия с отказоустойчивого кластера и предназначены для того, чтобы избежать ситуаций, когда пропускная способность сети полностью потребляется и в результате сообщения управления отказоустойчивости кластера прерываются. Обратите внимание, что обмен данными между отказоустойчивыми кластерами является критически важным компонентом инфраструктуры Azure Stack Hub. Если он будет нарушен в течение длительного времени, это может привести к нестабильной работе служб хранилища с прямым доступом к пространствам или другим службам, что в конечном итоге повлияет на стабильность рабочей нагрузки клиента или конечного пользователя.

Примечание

Описанные изменения добавляются на уровне узла системы Azure Stack Hub в выпуске 2008 года. Обратитесь к изготовителю оборудования, чтобы организовать внесение необходимых изменений на сетевых коммутаторах ToR. Это изменение может быть выполнено до обновления до выпуска 2008 или после обновления до версии 2008. Изменение конфигурации параметров ToR необходимо для улучшения взаимодействия отказоустойчивого кластера.

Логические сети

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

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

Логические сети	Описание	Размер
Общедоступный виртуальный IP-адрес	Azure Stack Hub использует в общей сложности 31 адрес из этой сети, а остальные используются виртуальными машинами клиента. Из 31 адреса для небольшого набора служб Azure Stack Hub используется 8 общедоступных IP-адресов. Если вы планируете использовать службу приложений и поставщики ресурсов SQL, потребуется еще 7 адресов. Остальные 16 IP-адресов зарезервированы для будущих служб Azure.	/26 (62 узла) –/22 (1022 узла) Рекомендуется —  /24 (254 узла)
Инфраструктура коммутаторов	IP-адреса типа "точка —точка" для целей маршрутизации, выделенные интерфейсы управления коммутаторами и петлевые адреса, назначенные коммутатору.	/26
Инфраструктура	Используется для обмена данными между внутренними компонентами Azure Stack Hub.	/24
Private	Используется для сети хранения данных, частных ВИРТУАЛЬНЫх IP-адресов, контейнеров инфраструктуры и других внутренних функций. Дополнительные сведения см. в разделе Частная сеть этой статьи.	/20
Контроллер управления основной платой (BMC)	Используется для обмена данными с BMC на физических узлах.	/26

Примечание

Оповещение на портале напомнит оператору о необходимости выполнить командлет PEP Set-AzsPrivateNetwork , чтобы добавить новое пространство частных IP-адресов /20. Дополнительные сведения и рекомендации по выбору пространства частных IP-адресов /20 см. в разделе Частная сеть этой статьи.

Инфраструктура сети

Сетевая инфраструктура для Azure Stack Hub состоит из нескольких логических сетей, настроенных на коммутаторах. На следующей схеме показаны эти логические сети и их интеграция с коммутаторами верхнего уровня (TOR), контроллером управления основной платой (BMC) и граничным коммутатором (клиентская сеть).

Сеть BMC

Эта сеть предназначена для подключения всех контроллеров управления основной платой (также называются BMC или служебными процессорами) к сети управления. Например: iDRAC, iLO, iBMC и т. д. Для взаимодействия с любым узлом BMC используется только одна учетная запись BMC. Узел жизненного цикла оборудования (HLH) (при наличии) размещается в этой сети и может предоставлять предназначенное для изготовителей оборудования программное обеспечение для обслуживания или мониторинга оборудования.

Также в HLH размещена виртуальная машина для развертывания (DVM). DVM используется при развертывании Azure Stack Hub и удаляется по завершении развертывания. Для DVM требуется доступ к Интернету в сценариях развертывания с подключением для тестирования, проверки и доступа к нескольким компонентам. Эти компоненты могут находиться внутри и вне корпоративной сети (например, NTP, DNS и Azure). Требования к подключению см. в разделе "Преобразование сетевых адресов" статьи "Интеграция брандмауэра Azure Stack".

Частная сеть

Эта сеть типа /20 (4096 IP-адресов) является частной в регионе Azure Stack Hub (не маршрутизируется через граничные коммутаторы системы Azure Stack Hub) и делится на несколько подсетей. Ниже приведен ряд примеров.

• Сеть хранения. Сеть /25 (128 IP-адресов), используемая для поддержки использования трафика хранилища Spaces Direct и SMB и динамической миграции виртуальных машин.
• Внутренняя виртуальная IP-сеть: сеть /25, выделенная для внутренних виртуальных IP-адресов для программной подсистемы балансировки нагрузки.
• Сеть контейнеров: сеть /23 (512 IP-адресов), предназначенная для внутреннего трафика между контейнерами, на которых выполняются службы инфраструктуры.

Для системы Azure Stack Hub требуется дополнительное /20 частных внутренних IP-адресов. Эта сеть будет частной для системы Azure Stack Hub (не маршрутизируется через граничные коммутаторы системы Azure Stack Hub), и ее можно повторно использовать в нескольких системах Azure Stack Hub в центре обработки данных. Хотя сеть является частной для Azure Stack, она не должна пересекаться с другими сетями в центре обработки данных. Пространство частных IP-адресов /20 делится на несколько сетей, которые позволяют запускать инфраструктуру Azure Stack Hub в контейнерах. Кроме того, это новое пространство частных IP-адресов позволяет постоянно сокращать необходимое пространство маршрутизируемых IP-адресов перед развертыванием. Инфраструктура Azure Stack Hub запускается в контейнерах для оптимизации использования и повышения производительности. Этот диапазон частных IP-адресов (/20) также используется для выполнения текущих операций, чтобы уменьшить требуемый диапазон маршрутизируемых IP-адресов перед развертыванием. Для получения рекомендаций по пространству частных IP-адресов рекомендуется следовать стандарту RFC 1918.

Для систем, развернутых с версиями до 1910, эта подсеть /20 будет дополнительной сетью для ввода в системы после обновления до версии 1910. Дополнительную сеть потребуется предоставить системе с помощью командлета PEP Set-AzsPrivateNetwork.

Примечание

Входные данные /20 служат необходимым условием для следующего обновления Azure Stack Hub после 1910 года. Когда будет выпущено следующее обновление Azure Stack Hub после 1910, попытка его установить приведет к ошибке, если вы не указали значение /20, как описано ниже в разделе с действиями по исправлению. На портале администрирования будет отображается предупреждение, пока вы не выполните соответствующие действия. Сведения о том, как будет использоваться этот новый диапазон частных IP-адресов, см. в руководстве по интеграции сетей центра обработки данных.

Действия по исправлению. Чтобы исправить, следуйте инструкциям, чтобы открыть сеанс PEP. Подготовьте частный внутренний диапазон IP-адресов размером /20 и выполните следующий командлет в сеансе PEP, используя следующий пример: Set-AzsPrivateNetwork -UserSubnet 10.87.0.0/20. Если операция выполнена успешно, вы получите сообщение Azs Internal Network Range добавлен в конфигурацию. В случае успешного завершения оповещение закроется на портале администрирования. Теперь систему Azure Stack Hub можно обновить до следующей версии.

Сеть инфраструктуры Azure Stack Hub

Эта сеть /24 предназначена для внутренних компонентов Azure Stack Hub, чтобы обеспечить связь и обмен данными между ними. Эта подсеть может быть маршрутизируемой за пределами решения Azure Stack Hub к центру обработки данных. Мы не рекомендуем использовать общедоступные или маршрутизируемые в Интернете IP-адреса в этой подсети. Эту сеть объявлено до границы, но большинство ее IP-адресов защищены Списками управления доступом (ACL). IP-адреса, разрешенные для доступа, находятся в небольшом диапазоне, эквивалентном по размеру сети /27 и службам узла, таким как привилегированная конечная точка (PEP) и Azure Stack Hub Backup.

Открытая сеть VIP

Сеть общедоступного виртуального IP-адреса назначается сетевому контроллеру в Azure Stack. Это не логическая сеть на коммутаторах. SLB использует пул адресов и назначает сети типа /32 для рабочих нагрузок клиента. В таблице маршрутизации коммутатора эти IP-адреса сети типа /32 объявляются как маршруты, доступные по протоколу BGP. Эта сеть содержит доступные внешние или открытые IP-адреса. Инфраструктура Azure Stack Hub резервирует первые 31 адрес из этой общедоступной сети ВИРТУАЛЬНЫх IP-адресов, а остальная часть используется виртуальными машинами клиента. Размер сети в этой подсети может варьироваться от минимум /26 (64 узла) до максимального значения /22 (1022 узла). Рекомендуется планировать сеть размера /24.

Подключение к локальным сетям

Azure Stack Hub использует виртуальные сети для клиентских ресурсов, таких как виртуальные машины, подсистемы балансировки нагрузки и другие.

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

• Используйте общедоступные IP-адреса из общедоступной сети ВИРТУАЛЬНЫх IP-адресов.
• Используйте шлюз виртуальная сеть или виртуальный сетевой модуль (NVA).

Если vpn-туннель S2S используется для подключения ресурсов к локальным сетям или из них, вы можете столкнуться со сценарием, в котором ресурсу также назначен общедоступный IP-адрес, и он больше недоступен через этот общедоступный IP-адрес. Если источник пытается получить доступ к общедоступному IP-адресу в пределах того же диапазона подсети, который определен в маршрутах шлюза локальной сети (шлюз виртуальная сеть) или определяемом пользователем маршруте для решений NVA, Azure Stack Hub пытается направить исходящий трафик обратно в источник через туннель S2S на основе настроенных правил маршрутизации. В возвращаемом трафике используется частный IP-адрес виртуальной машины, а не источник NATed в качестве общедоступного IP-адреса:

Существует два решения этой проблемы:

• Перенаправите трафик, направленный в сеть общедоступных ВИРТУАЛЬНЫх IP-адресов, в Интернет.
• Добавьте устройство NAT в NAT всех IP-адресов подсети, определенных в шлюзе локальной сети, которые направляются в сеть общедоступных виртуальных IP-адресов.

Сеть инфраструктуры коммутаторов

Это подсеть типа /26, содержащая IP-подсети "точка-точка" типа /30 (2 IP-адреса узлов) с поддержкой маршрутизации, и подсети с замыканием на себя, представляющие выделенные подсети типа /32 для управления коммутаторами в основной сети и идентификатора маршрутизатора BGP. Этот диапазон IP-адресов должен маршрутизироваться за пределы решения Azure Stack Hub в центр обработки данных. Это могут быть частные или общедоступные IP-адреса.

Сеть управления коммутаторами

Эта сеть /29 (6 IP-адресов узлов) выделена для подключения портов управления коммутаторами. Она также предоставляет доступ по внештатному каналу для развертывания, управления и устранения неполадок. Она вычисляется на основе сети инфраструктуры коммутаторов, упомянутой выше.

Разрешенные сети

Лист развертывания содержит поле, позволяющее оператору изменить некоторые списки управления доступом (ACL), чтобы разрешить доступ к интерфейсам управления сетевыми устройствами и узлу жизненного цикла оборудования (HLH) из доверенного сетевого диапазона центра обработки данных. После изменения списка управления доступом оператор может разрешить своим виртуальным машинам jumpbox управления в определенном диапазоне сети доступ к интерфейсу управления коммутатором и ОС HLH. Оператор может ввести в этот список одну или несколько подсетей. Если оставить это поле пустым, по умолчанию подсетям будет отказано в доступе. Эта новая функция заменяет необходимость вмешательства вручную после развертывания, описанную в статье Изменение определенных параметров в конфигурации коммутатора Azure Stack.

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

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