Ознакомьтесь со эталонным шаблоном сетевого развертывания развертывания с одним коммутатором с двумя узлами хранилища для Azure Stack HCI.

Статья
03/14/2024

Область применения: Azure Stack HCI версий 23H2 и 22H2

В этой статье описывается шаблон ссылок на сеть коммутатора с одним коммутатором TOR с двумя узлами, который можно использовать для развертывания решения Azure Stack HCI. Сведения, приведенные в этой статье, также помогут определить, подходит ли эта конфигурация для планирования развертывания. Эта статья предназначена для ИТ-администраторов, которые развертывают Azure Stack HCI и управляют ими в своих центрах обработки данных.

Сведения о других сетевых шаблонах см. в статье Шаблоны развертывания сети Azure Stack HCI.

Сценарии

Сценарии для этого сетевого шаблона включают лаборатории, фабрики, розничные магазины и государственные учреждения.

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

Этот шаблон можно масштабировать, но для перенастройки физического подключения к хранилищу и перенастройки сети хранилища требуется простой рабочей нагрузки. Хотя службы SDN L3 полностью поддерживаются для этого шаблона, службы маршрутизации, такие как BGP, должны быть настроены на устройстве брандмауэра поверх коммутатора TOR, если он не поддерживает службы L3. Функции сетевой безопасности, такие как микросегментация и качество обслуживания, не требуют дополнительной настройки на устройстве брандмауэра, так как они реализуются на виртуальном коммутаторе.

Компоненты физического подключения

Как показано на следующей схеме, этот шаблон содержит следующие физические сетевые компоненты:

Один коммутатор TOR для связи между севером и югом.
Два объединенных сетевых порта для обработки трафика управления и вычислений, подключенных к коммутатору L2 на каждом узле
Две сетевые карты RDMA в полной конфигурации сетки для трафика "восток-запад" для хранилища. Каждый узел в кластере имеет избыточное подключение к другому узлу в кластере.
В качестве варианта некоторые решения могут использовать безголовую конфигурацию без карта BMC в целях безопасности.

Сети	Управление и вычисление	Память	Контроллер управления основной платой (BMC)
Скорость компоновки	Не менее 1 Гбит/с. Рекомендуется 10 Гбит/с	Не менее 10 Гбит/с	Обратитесь к производителю оборудования
Тип интерфейса	RJ45, SFP+ или SFP28	SFP+ или SFP28	RJ45
Порты и агрегирование	Два объединяемых порта	Два автономных порта	Один порт

Сетевые намерения ATC

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

Управление и намерение вычислений

Тип намерения: управление и вычисление
Режим намерений: режим кластера
Совместная работа. Да. pNIC01 и pNIC02 объединяются
Виртуальная локальная сеть управления по умолчанию: настроенная виртуальная локальная сеть для адаптеров управления не изменяется
Pa & Вычислительные виртуальные локальные сети и виртуальные сетевые адаптеры. Сетевой ATC является прозрачным для виртуальных сетевых карт pa и VLAN или вычислений виртуальных сетевых адаптеров виртуальных машин и виртуальных локальных сетей

Намерение хранилища

Тип намерения: Хранилище
Режим намерения: режим кластера
Объединение: pNIC03 и pNIC04 используют SMB Multichannel для обеспечения устойчивости и агрегирования пропускной способности.
Виртуальные локальные сети по умолчанию:
- 711 для сети хранения 1
- 712 для сети хранения 2
Подсети по умолчанию:
- 10.71.1.0/24 для сети хранения 1
- 10.71.2.0/24 для сети хранения 2

Дополнительные сведения см. в статье Развертывание сети узла.

Выполните следующие действия, чтобы создать сетевые намерения для этого эталонного шаблона:

Запустите оболочку PowerShell от имени администратора.

Выполните следующую команду:

Add-NetIntent -Name <Management_Compute> -Management -Compute -ClusterName <HCI01> -AdapterName <pNIC01, pNIC02>
Add-NetIntent -Name <Storage> -Storage -ClusterName <HCI01> -AdapterName <pNIC03, pNIC04>

Компоненты логического подключения

Как показано на схеме ниже, этот шаблон содержит следующие компоненты логической сети:

Виртуальные локальные сети хранения данных

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

Адаптеры хранилища работают в разных IP-подсетях. Чтобы включить конфигурацию без переключения, каждый подключенный узел поддерживает соответствующую подсеть своего соседа. Каждая сеть хранения по умолчанию использует предопределенные виртуальные локальные сети ATC (711 и 712). Однако при необходимости эти виртуальные локальные сети можно настроить. Кроме того, если подсети по умолчанию, определенные в network ATC (10.71.1.0/24 и 10.71.2.0/24), недоступны, вы несете ответственность за назначение всех IP-адресов хранилища в кластере.

Дополнительные сведения см. в статье Общие сведения о сетевых ATC.

Сеть OOB

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

Для сети управления требуется доступ к интерфейсу BMC с помощью порта UDP 623.

Сеть OOB изолирована от вычислительных рабочих нагрузок и является необязательной для развертываний, не основанных на решениях.

Виртуальная локальная сеть управления

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

DHCP-сервер может автоматически назначать IP-адреса для сети управления или вручную назначать статические IP-адреса. Если DHCP является предпочтительным методом назначения IP-адресов, рекомендуется использовать резервирования DHCP без истечения срока действия.

Сеть управления поддерживает следующие конфигурации виртуальной локальной сети:

Собственная виртуальная локальная сеть — вам не требуется предоставлять идентификаторы виртуальных ЛС. Это необходимо для установки на основе решений.
Виртуальная локальная сеть с тегами — вы предоставляете идентификаторы виртуальной ЛС во время развертывания.

Сеть управления поддерживает весь трафик, используемый для управления кластером, включая удаленный рабочий стол, Windows Admin Center и Active Directory.

Дополнительные сведения см. в статье Планирование инфраструктуры SDN: управление и поставщик HNV.

Вычисление виртуальных ЛС

В некоторых сценариях не требуется использовать виртуальные сети SDN с инкапсуляцией виртуальной расширяемой локальной сети (VXLAN). Вместо этого можно использовать традиционные виртуальные локальные сети для изоляции рабочих нагрузок клиента. Эти виртуальные локальные сети настраиваются на порте коммутатора TOR в режиме магистрали. При подключении новых виртуальных машин к этим виртуальным локальным сетям соответствующий тег виртуальной ЛС определяется в виртуальном сетевом адаптере.

Сеть HNV Provider Address (PA)

Сеть адресов поставщика (PA) для виртуализации сети Hyper-V (HNV) служит базовой физической сетью для трафика клиента "Восток-Запад" (внутренний трафик), трафика клиента "Север/Юг" (внешний-внутренний) и для обмена данными пиринга BGP с физической сетью. Эта сеть требуется только в том случае, если необходимо развернуть виртуальные сети с помощью инкапсуляции VXLAN для другого уровня изоляции и мультитенантности сети.

Дополнительные сведения см. в статье Планирование инфраструктуры SDN: управление и поставщик HNV.

Варианты сетевой изоляции

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

Виртуальные локальные сети (IEEE 802.1Q)

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

Дополнительные сведения см. в статье Общие сведения об использовании виртуальных сетей и виртуальных локальных сетей.

Политики доступа к сети и микросегментация по умолчанию

Политики доступа к сети по умолчанию гарантируют, что все виртуальные машины в кластере Azure Stack HCI по умолчанию защищены от внешних угроз. С помощью этих политик мы заблокируем входящий доступ к виртуальной машине по умолчанию, предоставляя возможность включить выборочные входящие порты и тем самым защитить виртуальные машины от внешних атак. Это применение доступно с помощью средств управления, таких как Windows Admin Center.

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

Политики доступа к сети и микросегментация по умолчанию реализуются в виде правил брандмауэра с отслеживанием состояния с пятью кортежами (префикс исходного адреса, исходный порт, префикс адреса назначения, порт назначения и протокол) в кластерах Azure Stack HCI. Правила брандмауэра также называются Группы безопасности сети (NSG). Эти политики применяются на портах vSwitch каждой виртуальной машины. Политики передаются через уровень управления, и сетевой контроллер SDN распространяет их на все применимые узлы. Эти политики доступны для виртуальных машин в традиционных виртуальных локальных сетях и в сетях наложения SDN.

Дополнительные сведения см. в статье Что такое брандмауэр центра обработки данных?

Качество обслуживания для сетевых адаптеров виртуальных машин

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

Дополнительные сведения см. в статье Настройка QoS для сетевого адаптера виртуальной машины.

Виртуальные сети

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

Дополнительные сведения см. в статье Виртуализация сети Hyper-V.

Параметры сетевых служб L3

Доступны следующие варианты сетевой службы L3:

Пиринг между виртуальными сетями

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

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

Дополнительные сведения см. в статье Пиринг между виртуальными сетями.

Программная подсистема балансировки нагрузки SDN

Поставщики облачных служб (CSP) и предприятия, развертывающие программно-определяемую сеть (SDN), могут использовать Load Balancer программного обеспечения (SLB) для равномерного распределения сетевого трафика клиента между ресурсами виртуальной сети. SLB позволяет размещать одну и ту же рабочую нагрузку на нескольких серверах, что обеспечивает высокий уровень доступности и масштабирования. Он также используется для предоставления входящих служб преобразования сетевых адресов (NAT) для входящего доступа к виртуальным машинам и исходящих служб NAT для исходящего подключения.

С помощью SLB можно масштабировать возможности балансировки нагрузки с помощью виртуальных машин SLB на том же вычислительном сервере Hyper-V, что и для других рабочих нагрузок виртуальных машин. SLB поддерживает быстрое создание и удаление конечных точек балансировки нагрузки, необходимых для операций CSP. Кроме того, SLB поддерживает десятки гигабайт на кластер, предоставляет простую модель подготовки и легко масштабируется. SLB использует протокол пограничного шлюза для объявления виртуальных IP-адресов в физической сети.

Дополнительные сведения см. в статье Что такое SLB для SDN?

VPN-шлюзы SDN

Шлюз SDN — это программный маршрутизатор с поддержкой протокола BGP, предназначенный для поставщиков облачных служб и предприятий, на которых размещаются мультитенантные виртуальные сети с использованием виртуализации сети Hyper-V (HNV). Шлюз RAS можно использовать для маршрутизации сетевого трафика между виртуальной сетью и другой сетью, локальной или удаленной.

Шлюз SDN можно использовать для:

Create безопасные подключения IPsec типа "сеть — сеть" между виртуальными сетями SDN и внешними клиентскими сетями через Интернет.
Create подключения GRE между виртуальными сетями SDN и внешними сетями. Разница между подключениями типа "сеть — сеть" и подключениями GRE заключается в том, что последние не являются зашифрованными.

Дополнительные сведения о сценариях подключения GRE см. в разделе Туннелирование GRE в Windows Server.
Create подключения уровня 3 (L3) между виртуальными сетями SDN и внешними сетями. В этом случае шлюз SDN просто выступает в качестве маршрутизатора между виртуальной сетью и внешней сетью.

Для шлюза SDN требуется сетевой контроллер SDN. Сетевой контроллер выполняет развертывание пулов шлюзов, настраивает подключения клиентов к каждому шлюзу и переключает потоки сетевого трафика в резервный шлюз в случае сбоя шлюза.

Шлюзы используют протокол пограничного шлюза для объявления конечных точек GRE и установления подключений типа "точка — точка". Развертывание SDN создает пул шлюзов по умолчанию, который поддерживает все типы подключений. В этом пуле можно указать, сколько шлюзов зарезервировано в режиме ожидания в случае сбоя активного шлюза.

Дополнительные сведения см. в статье Что такое шлюз RAS для SDN?

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

Сведения о двухузловом сетевом шаблоне без коммутационного хранилища с двумя коммутаторами

Поделиться через