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

В этом разделе рассматриваются разрешения на доступ к коммутаторам TOR, назначения IP-адресов и другие задачи сетевого развертывания.

Планирование развертывания конфигурации

В следующих разделах рассматриваются разрешения и назначения IP-адресов.

Список управления доступом физического коммутатора

Для защиты решения Azure Stack мы реализовали списки управления доступом (ACL) в коммутаторах TOR. В этом разделе описывается реализация этой безопасности. В таблице ниже приведены источники и назначения каждой сети в решении Azure Stack.

Схема списков управления доступом на коммутаторах TOR

В приведенной ниже таблице ссылки 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, который используется для создания конфигурации физического сетевого коммутатора.

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

Ниже приведены инструкции по обновлению образа контейнера.

  1. Загрузка образа контейнера

  2. Замените образ контейнера в следующем расположении

Создание конфигурации

Здесь мы рассмотрим шаги по созданию JSON-файлов и файлов конфигурации сетевого коммутатора:

  1. Открытие листа развертывания

  2. Заполнение всех обязательных полей на всех вкладках

  3. Вызовите функцию Generate на листе развертывания.
    Будут созданы две дополнительные вкладки с созданными IP-подсетями и назначениями.

  4. Просмотрите данные и после подтверждения вызовите функцию Export.
    Вам будет предложено указать папку, в которой будут сохранены ФАЙЛЫ JSON.

  5. Выполните контейнер с помощью 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 и (или) системного журнала в вашей среде, мы предоставим дополнительный файл с конфигурацией сетевого коммутатора, который позволит инженеру на месте настроить коммутатор в соответствии с потребностями клиента.

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

Сетевая интеграция