Развертывание сети
В этом разделе рассматриваются разрешения на доступ к коммутаторам TOR, назначения IP-адресов и другие задачи сетевого развертывания.
Планирование развертывания конфигурации
В следующих разделах рассматриваются разрешения и назначения IP-адресов.
Список управления доступом физического коммутатора
Для защиты решения Azure Stack мы реализовали списки управления доступом (ACL) в коммутаторах TOR. В этом разделе описывается реализация этой безопасности. В таблице ниже приведены источники и назначения каждой сети в решении Azure Stack.
В приведенной ниже таблице ссылки ACL сопоставляются с сетями Azure Stack.
Сеть | Описание |
---|---|
BMC Mgmt Internal | Трафик ограничен только внутренним. |
BMC Mgmt External | ACL разрешает доступ к устройству за пределами границы. |
Средство управления расширенным хранилищем | Выделенные интерфейсы управления для расширенной системы хранения |
Switch Mgmt | Выделенные интерфейсы управления коммутаторами. |
"Инфраструктура Azure Stack" | Ограниченные сети служб инфраструктуры Azure Stack и виртуальных машин |
Общедоступная инфраструктура Azure Stack (PEP/ERCS) | Конечная точка Azure Stack Protected, сервер консоли аварийного восстановления. Клиент может открыть ACL, чтобы разрешить трафик к сети управления центрами обработки данных. |
Tor1,Tor2 RouterIP | Интерфейс замыкания на себя коммутатора, используемого для пиринга BGP между SLB и коммутатором или маршрутизатором. Клиент имеет право по своему усмотрению отключить эти IP-адреса на границе. |
Память | Частные IP-адреса, не перенаправленные за пределы региона |
Внутренние ВИРТУАЛЬНЫЕ IP-адреса | Частные IP-адреса, не перенаправленные за пределы региона |
Общедоступные виртуальные IP-адреса | Адресное пространство сети клиента, управляемое сетевым контроллером. |
Общедоступные Администратор IP-адреса | Небольшое подмножество адресов в пуле клиентов, необходимых для взаимодействия с Internal-VIPs и инфраструктурой Azure Stack |
Разрешенные сети | Определяемая клиентом сеть. |
0.0.0.0 | С точки зрения Azure Stack 0.0.0.0 является пограничным устройством. |
Разрешение | Разрешить трафик включен, но доступ по протоколу SSH заблокирован по умолчанию. |
Нет маршрута | Маршруты не распространяются за пределы среды Azure Stack. |
СПИСОК ACL МУЛЬТИПЛЕКСА | Используются списки управления доступом mux Azure Stack. |
Н/Д | Не является частью списка ACL виртуальной локальной сети. |
Назначения IP-адресов
На листе Развертывания вам будет предложено указать следующие сетевые адреса для поддержки процесса развертывания Azure Stack. Команда развертывания использует средство "Лист развертывания", чтобы разбить IP-сети на все небольшие сети, необходимые системе.
В этом примере мы заполним вкладку Параметры сети листа развертывания следующими значениями:
Сеть BMC: 10.193.132.0 /27
Внутренние виртуальные IP-адреса & сети хранения частной сети: 11.11.128.0 /20
Сеть инфраструктуры: 12.193.130.0 /24
Сеть общедоступного виртуального IP-адреса: 13.200.132.0 /24
Сеть инфраструктуры коммутаторов: 10.193.132.128 /26
При запуске функции Generate средства "Лист развертывания" создаются две новые вкладки в электронной таблице. Первая вкладка — это сводка по подсети, на ней показано, как суперсети были разделены для создания всех сетей, необходимых системе. В приведенном ниже примере на этой вкладке находится только подмножество столбцов. Фактический результат содержит дополнительные сведения о каждой сети:
Стойка | Тип подсети | имя; | IPv4-подсеть | IPv4-адреса |
---|---|---|---|---|
Рамка | Ссылка P2P | P2P_Border/Border1_To_Rack1/TOR1 | 10.193.132.128/30 | 4 |
Рамка | Ссылка P2P | P2P_Border/Border1_To_Rack1/TOR2 | 10.193.132.132/30 | 4 |
Рамка | Ссылка P2P | P2P_Border/Border2_To_Rack1/TOR1 | 10.193.132.136/30 | 4 |
Рамка | Ссылка P2P | P2P_Border/Border2_To_Rack1/TOR2 | 10.193.132.140/30 | 4 |
Рамка | Ссылка P2P | P2P_Rack1/TOR1_To_Rack1/BMC | 10.193.132.144/30 | 4 |
Рамка | Ссылка P2P | P2P_Rack1/TOR2_To_Rack1/BMC | 10.193.132.148/30 | 4 |
Стойка1 | Замыкание на себя | Loopback0_Rack1_TOR1 | 10.193.132.152/32 | 1 |
Стойка1 | Замыкание на себя | Loopback0_Rack1_TOR2 | 10.193.132.153/32 | 1 |
Стойка1 | Замыкание на себя | Loopback0_Rack1_BMC | 10.193.132.154/32 | 1 |
Стойка1 | Ссылка P2P | P2P_Rack1/TOR1-ibgp-1_To_Rack1/TOR2-ibgp-1 | 10.193.132.156/30 | 4 |
Стойка1 | Ссылка P2P | P2P_Rack1/TOR1-ibgp-2_To_Rack1/TOR2-ibgp-2 | 10.193.132.160/30 | 4 |
Стойка1 | Виртуальная локальная сеть | BMCMgmt | 10.193.132.0/27 | 32 |
Стойка1 | Виртуальная локальная сеть | SwitchMgmt | 10.193.132.168/29 | 8 |
Стойка1 | Виртуальная локальная сеть | CL01-RG01-SU01-Storage | 11.11.128.0/25 | 128 |
Стойка1 | Виртуальная локальная сеть | CL01-RG01-SU01-Infra | 12.193.130.0/24 | 256 |
Стойка1 | Другое | CL01-RG01-SU01-VIPS | 13.200.132.0/24 | 256 |
Стойка1 | Другое | CL01-RG01-SU01-InternalVIPS | 11.11.128.128/25 | 128 |
Вторая вкладка — Использование IP-адресов и показывает, как используются IP-адреса:
Сеть BMC
Для суперсети для сети BMC требуется сеть /26 как минимум. Шлюз использует первый IP-адрес в сети, а затем устройства BMC в стойке. Узел жизненного цикла оборудования имеет несколько адресов, назначенных этой сети, и его можно использовать для развертывания, мониторинга и поддержки стойки. Эти IP-адреса распределяются по 3 группам: DVM, InternalAccessible и ExternalAccessible.
- Стойка: Стойка1
- Имя: BMCMgmt
Кому назначено | Адрес IPv4 |
---|---|
Сеть | 10.193.132.0 |
Шлюз | 10.193.132.1 |
HLH-BMC | 10.193.132.2 |
AzS-Node01 | 10.193.132.3 |
AzS-Node02 | 10.193.132.4 |
AzS-Node03 | 10.193.132.5 |
AzS-Node04 | 10.193.132.6 |
ExternalAccessible-1 | 10.193.132.19 |
ExternalAccessible-2 | 10.193.132.20 |
ExternalAccessible-3 | 10.193.132.21 |
ExternalAccessible-4 | 10.193.132.22 |
ExternalAccessible-5 | 10.193.132.23 |
InternalAccessible-1 | 10.193.132.24 |
InternalAccessible-2 | 10.193.132.25 |
InternalAccessible-3 | 10.193.132.26 |
InternalAccessible-4 | 10.193.132.27 |
InternalAccessible-5 | 10.193.132.28 |
CL01-RG01-SU01-DVM00 | 10.193.132.29 |
HLH-OS | 10.193.132.30 |
Широковещательное | 10.193.132.31 |
Сетевое хранилище
Сеть хранения данных является частной сетью и не предназначена для маршрутизации за пределы стойки. Это первая половина суперсети частной сети, которая используется распределенным коммутатором, как показано в таблице ниже. Шлюз является первым IP-адресом в подсети. Вторая половина, используемая для внутренних ВИРТУАЛЬНЫх IP-адресов, представляет собой частный пул адресов, управляемый SLB Azure Stack, не отображается на вкладке Использование IP-адресов. Эти сети поддерживают Azure Stack, а на коммутаторах TOR есть списки ACL, которые не позволяют объявлять эти сети и (или) получать доступ к этим сетям за пределами решения.
- Стойка: Rack1
- Имя: CL01-RG01-SU01-Storage
Назначено | Адрес IPv4 |
---|---|
Сеть | 11.11.128.0 |
Шлюз | 11.11.128.1 |
TOR1 | 11.11.128.2 |
TOR2 | 11.11.128.3 |
Широковещательное | 11.11.128.127 |
Сеть инфраструктуры Azure Stack
Для суперсети инфраструктуры требуется сеть /24, которая по-прежнему будет иметь значение /24 после запуска средства "Лист развертывания". Шлюз будет первым IP-адресом в подсети.
- Стойка: Rack1
- Имя: CL01-RG01-SU01-Infra
Назначено | Адрес IPv4 |
---|---|
Сеть | 12.193.130.0 |
Шлюз | 12.193.130.1 |
TOR1 | 12.193.130.2 |
TOR2 | 12.193.130.3 |
Широковещательное | 12.193.130.255 |
Сеть инфраструктуры коммутаторов
Сеть инфраструктуры разбивается на несколько сетей, используемых инфраструктурой физического коммутатора. Это отличается от инфраструктуры Azure Stack, которая поддерживает только программное обеспечение Azure Stack. Сеть switch Infra Network поддерживает только инфраструктуру физического коммутатора. Ниже перечислены сети, поддерживаемые инфраструктурой.
имя; | Подсеть IPv4 |
---|---|
P2P_Border/Border1_To_Rack1/TOR1 | 10.193.132.128/30 |
P2P_Border/Border1_To_Rack1/TOR2 | 10.193.132.132/30 |
P2P_Border/Border2_To_Rack1/TOR1 | 10.193.132.136/30 |
P2P_Border/Border2_To_Rack1/TOR2 | 10.193.132.140/30 |
P2P_Rack1/TOR1_To_Rack1/BMC | 10.193.132.144/30 |
P2P_Rack1/TOR2_To_Rack1/BMC | 10.193.132.148/30 |
Loopback0_Rack1_TOR1 | 10.193.132.152/32 |
Loopback0_Rack1_TOR2 | 10.193.132.153/32 |
Loopback0_Rack1_BMC | 10.193.132.154/32 |
P2P_Rack1/TOR1-ibgp-1_To_Rack1/TOR2-ibgp-1 | 10.193.132.156/30 |
P2P_Rack1/TOR1-ibgp-2_To_Rack1/TOR2-ibgp-2 | 10.193.132.160/30 |
SwitchMgmt | 10.193.132.168/29 |
Точка — точка (P2P). Эти сети обеспечивают подключение между всеми коммутаторами. Размер подсети — это сеть /30 для каждой P2P. Самый низкий IP-адрес всегда назначается устройству вышестоящий (North) в стеке.
Замыкания на себя: это сети /32, назначенные каждому коммутатору, используемому в стойке. Пограничным устройствам не назначается замыкания на себя, так как они не должны быть частью решения Azure Stack.
Switch Mgmt или Switch Management. Эта сеть /29 поддерживает выделенные интерфейсы управления коммутаторов в стойке. IP-адреса назначаются следующим образом. Эту таблицу также можно найти на вкладке Использование IP-адресов на листе Развертывания:
Стойка: Rack1
Имя: SwitchMgmt
Назначено | Адрес IPv4 |
---|---|
Сеть | 10.193.132.168 |
Шлюз | 10.193.132.169 |
TOR1 | 10.193.132.170 |
TOR2 | 10.193.132.171 |
Широковещательное | 10.193.132.175 |
Подготовка среды
Образ узла жизненного цикла оборудования содержит необходимый контейнер Linux, который используется для создания конфигурации физического сетевого коммутатора.
Последний партнерский набор средств для развертывания включает в себя последнюю версию образа контейнера. Образ контейнера на узле жизненного цикла оборудования можно заменить, если необходимо создать обновленную конфигурацию коммутатора.
Ниже приведены инструкции по обновлению образа контейнера.
Загрузка образа контейнера
Замените образ контейнера в следующем расположении
Создание конфигурации
Здесь мы рассмотрим шаги по созданию JSON-файлов и файлов конфигурации сетевого коммутатора:
Открытие листа развертывания
Заполнение всех обязательных полей на всех вкладках
Вызовите функцию Generate на листе развертывания.
Будут созданы две дополнительные вкладки с созданными IP-подсетями и назначениями.Просмотрите данные и после подтверждения вызовите функцию Export.
Вам будет предложено указать папку, в которой будут сохранены ФАЙЛЫ JSON.Выполните контейнер с помощью Invoke-SwitchConfigGenerator.ps1. Для выполнения этого скрипта требуется консоль PowerShell с повышенными привилегиями и следующие параметры.
ContainerName — имя контейнера, который создаст конфигурации коммутатора.
ConfigurationData — путь к файлу ConfigurationData.json, экспортируемом из листа развертывания.
OutputDirectory — путь к выходному каталогу.
Вне сети — сигнализирует о том, что скрипт выполняется в автономном режиме.
C:\WINDOWS\system32> .\Invoke-SwitchConfigGenerate.ps1 -ContainerName generalonrampacr.azurecr.io/master -ConfigurationData .\ConfigurationData.json -OutputDirectory c:\temp -Offline
По завершении скрипта создается ZIP-файл с префиксом, используемым на листе.
C:\WINDOWS\system32> .\Invoke-SwitchConfigGenerate.ps1 -ContainerName generalonrampacr.azurecr.io/master -ConfigurationData .\ConfigurationData.json -OutputDirectory c:\temp -Offline
Seconds : 2
Section : Validation
Step : WindowsRequirement
Status : True
Detail : @{CurrentImage=10.0.18363.0}
Seconds : 2
Section : Validation
Step : DockerService
Status : True
Detail : @{Status=Running}
Seconds : 9
Section : Validation
Step : DockerSetup
Status : True
Detail : @{CPU=4; Memory=4139085824; OS=Docker Desktop; OSType=linux}
Seconds : 9
Section : Validation
Step : DockerImage
Status : True
Detail : @{Container=generalonrampacr.azurecr.io/master:1.1910.78.1}
Seconds : 10
Section : Run
Step : Container
Status : True
Detail : @{ID=2a20ba622ef9f58f9bcd069c3b9af7ec076bae36f12c5653f9469b988c01706c; ExternalPort=32768}
Seconds : 38
Section : Generate
Step : Config
Status : True
Detail : @{OutputFile=c:\temp\N22R19.zip}
Seconds : 38
Section : Exit
Step : StopContainer
Status : True
Detail : @{ID=2a20ba622ef9f58f9bcd069c3b9af7ec076bae36f12c5653f9469b988c01706c}
Настраиваемая конфигурация
Для конфигурации коммутатора Azure Stack можно изменить несколько параметров среды. Вы можете определить, какие параметры можно изменить в шаблоне. В этой статье описывается каждый из этих настраиваемых параметров и объясняется, как изменения могут повлиять на Azure Stack. Эти параметры охватывают обновление паролей, сервер системного журнала, мониторинг SNMP, аутентификацию и список управления доступом.
При развертывании решения Azure Stack изготовитель оборудования создает конфигурацию коммутатора и применяет ее к точкам выхода TOR и контроллеру BMC. Изготовитель оборудования использует средство автоматизации Azure Stack для проверки правильности настройки требуемых конфигураций на этих устройствах. Конфигурация основывается на данных из листа сведений о развертывании Azure Stack.
Примечание
Не изменяйте конфигурацию без согласия изготовителя оборудования или группы разработчиков Microsoft Azure Stack. Изменение конфигурации сетевого устройства может значительно повлиять на работу или устранение сетевых неполадок в экземпляре Azure Stack. Чтобы получить дополнительные сведения об этих функциях сетевого устройства и о том, как внести изменения, обратитесь к поставщику оборудования от изготовителя оборудования или в службу поддержки Майкрософт. Изготовитель оборудования предоставляет файл конфигурации, созданный средством автоматизации на основе листа сведений о развертывании Azure Stack.
Однако некоторые значения в конфигурации сетевых коммутаторов можно добавлять, удалять или изменять.
Обновление пароля
Оператор может обновить пароль любого пользователя сетевых коммутаторов в любое время. Нет необходимости изменять какие-либо данные в системе Azure Stack или выполнять действия по смене секретов в Azure Stack.
Сервер системного журнала
Операторы могут перенаправлять журналы коммутатора на сервер системного журнала в центре обработки данных. Используйте эту конфигурацию, чтобы журналы для определенной точки во времени можно было использовать для устранения неполадок. По умолчанию журналы хранятся на коммутаторах, а их емкость для хранения журналов ограничена. В разделе Обновления списка управления доступом ознакомьтесь с общими сведениями о настройке разрешений на доступ для управления коммутатором.
Мониторинг SNMP
Оператор может настроить протокол SNMP версии 2 или 3 для мониторинга сетевых устройств и отправки ловушек в приложение мониторинга сети в центре обработки данных. Из соображений безопасности следует использовать протокол SNMP версии 3, так как он более надежный, чем протокол версии 2. Обратитесь к поставщику оборудования от изготовителя оборудования, чтобы получить сведения о MIB и обязательной конфигурации. В разделе Обновления списка управления доступом ознакомьтесь с общими сведениями о настройке разрешений на доступ для управления коммутатором.
Аутентификация
Оператор может настроить RADIUS или TACACS для управления аутентификацией на сетевых устройствах. Обратитесь к поставщику оборудования от изготовителя оборудования, чтобы получить сведения о поддерживаемых методах и обязательной конфигурации. В разделе Обновления списка управления доступом ознакомьтесь с общими сведениями о настройке разрешений на доступ для управления коммутатором.
Обновления списка управления доступом
Оператор может изменить некоторые списки управления доступом (ACL), чтобы разрешить доступ к интерфейсам управления сетевыми устройствами и узлу жизненного цикла оборудования (HLH) из доверенного диапазона номеров сети центра обработки данных. Оператор может выбрать, какой компонент будет доступен и откуда. С помощью списка управления доступом оператор может разрешить виртуальным машинам управления Jumpbox в определенном диапазоне номеров сети доступ к интерфейсу управления коммутатором, а также ОС и BMC узла жизненного цикла оборудования (HLH).
Дополнительные сведения см. в разделе Список управления доступом физического коммутатора.
TACACS, RADIUS и системный журнал
Решение Azure Stack не будет поставляться с решением TACACS или RADIUS для управления доступом к таким устройствам, как коммутаторы и маршрутизаторы, или решением системного журнала для записи журналов коммутаторов, но все эти устройства поддерживают эти службы. Чтобы упростить интеграцию с существующим сервером TACACS, RADIUS и (или) системного журнала в вашей среде, мы предоставим дополнительный файл с конфигурацией сетевого коммутатора, который позволит инженеру на месте настроить коммутатор в соответствии с потребностями клиента.
Дальнейшие действия
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по