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

Статья
04/23/2024

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

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

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

Введение

Развертывания с одним сервером предоставляют преимущества с затратами и пространством, а также помогают модернизировать инфраструктуру и переносить гибридные вычисления Azure в расположения, которые могут обеспечить устойчивость одного сервера. Azure Stack HCI, работающий на одном сервере, ведет себя аналогично Azure Stack HCI в кластере с несколькими узлами: он обеспечивает встроенную интеграцию Azure Arc, возможность добавления серверов для масштабирования кластера и включает те же преимущества Azure.

Она также поддерживает те же рабочие нагрузки, такие как Виртуальный рабочий стол Azure (AVD) и AKS в Azure Stack HCI, и так же поддерживается и оплачивается.

Сценарии

Используйте шаблон хранилища с одним сервером в следующих сценариях:

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

Хотя службы SDN уровня 3 (L3) полностью поддерживаются в этом шаблоне, может потребоваться настройка таких служб маршрутизации, как протокол BGP, для устройства брандмауэра на коммутаторе top-of-Rack (TOR).

Функции сетевой безопасности, такие как микросегментация и качество обслуживания (QoS), не требуют дополнительной настройки устройства брандмауэра, так как они реализуются на уровне виртуального сетевого адаптера. Дополнительные сведения см. в статье Микросегментация с помощью Azure Stack HCI.

Примечание

Отдельные серверы должны использовать только один тип диска: энергонезависимые диски Memory Express (NVMe) или Solid-State (SSD).

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

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

Для трафика с севера или юга кластер Azure Stack HCI реализуется с помощью одного коммутатора TOR L2 или L3.
Два объединенных сетевых порта для обработки трафика управления и вычислений, подключенных к коммутатору.
Два отключенных сетевых адаптера RDMA, которые используются только при добавлении второго сервера в кластер для горизонтального масштабирования. Это означает отсутствие дополнительных затрат на кабели или физические порты коммутатора.
(Необязательно) Карта BMC можно использовать для удаленного управления средой. В целях безопасности некоторые решения могут использовать безголовую конфигурацию без карта BMC.

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

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

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

В шаблоне с одним сервером используется только одно намерение ATC network для управления и вычислительного трафика. Сетевые интерфейсы RDMA являются необязательными и отключенными.

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

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

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

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

Намерение хранилища имеет следующие характеристики:

Тип намерения: None
Режим намерения: нет
Объединение: pNIC03 и pNIC04 отключены
Виртуальные локальные сети по умолчанию: нет
Подсети по умолчанию: Нет

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

Запустите PowerShell от имени администратора.

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

Add-NetIntent -Name <management_compute> -Management -Compute -ClusterName <HCI01> -AdapterName <pNIC01, pNIC02>

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

Компоненты логической сети

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

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

Необязательно. Для этого шаблона не требуется сеть хранения.

Сеть OOB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Узнайте о шаблонах развертывания сети Azure Stack HCI с двумя узлами.

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