Ознакомьтесь с шаблоном справки по сети развертывания двухузлового хранилища с двумя узлами для Azure Stack HCI.
Область применения: Azure Stack HCI версий 23H2 и 22H2
Из этой статьи вы узнаете о шаблоне сетевого эталона двухузлового хранилища с двумя коммутаторами TOR L3, который можно использовать для развертывания решения Azure Stack HCI. Сведения, приведенные в этой статье, также помогут определить, подходит ли эта конфигурация для планирования развертывания. Эта статья посвящена ИТ-администраторам, которые развертывают Azure Stack HCI и управляют ими в своих центрах обработки данных.
Сведения о других сетевых шаблонах см. в статье Шаблоны развертывания сети Azure Stack HCI.
Сценарии
Сценарии для этого сетевого шаблона включают лаборатории, филиалы и центры обработки данных.
Рассмотрите возможность реализации этого шаблона при поиске экономичного решения с отказоустойчивостью во всех сетевых компонентах. Шаблон можно масштабировать, но для перенастройки физического подключения к хранилищу и перенастройки сети хранилища требуется время простоя рабочей нагрузки. Службы SDN L3 полностью поддерживаются в этом шаблоне. Службы маршрутизации, такие как BGP, можно настроить непосредственно на коммутаторах TOR, если они поддерживают службы L3. Функции сетевой безопасности, такие как микросекции и качество обслуживания, не требуют дополнительной настройки устройства брандмауэра, так как они реализуются на уровне виртуального сетевого адаптера.
Компоненты физического подключения
Как показано на схеме ниже, этот шаблон содержит следующие физические сетевые компоненты:
Для трафика с севера или юга кластеру требуется два коммутатора TOR в конфигурации MLAG.
Две объединенные сетевые карты для обработки трафика управления и вычислений и подключения к коммутаторам TOR. Каждый сетевой адаптер подключен к отдельному коммутатору TOR.
Две сетевые карты RDMA в полной конфигурации сетки для East-West трафика хранилища. Каждый узел в кластере имеет избыточное подключение к другому узлу в кластере.
В качестве варианта некоторые решения могут использовать безголовую конфигурацию без карта 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). При необходимости эти виртуальные локальные сети можно настроить. Кроме того, если подсеть по умолчанию, определенная ATC, недоступна, вы несете ответственность за назначение всех 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.
Дополнительные сведения см. в статье Настройка качества обслуживания для сетевого адаптера виртуальной машины.
Виртуальные сети
Виртуализация сети предоставляет виртуальные сети виртуальным машинам аналогично тому, как виртуализация сервера (гипервизор) предоставляет виртуальные машины операционной системе. Виртуализация сети отделяет виртуальные сети от физической сетевой инфраструктуры и удаляет ограничения виртуальной локальной сети и иерархического назначения 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 можно использовать для:
Создайте безопасные подключения IPsec типа "сеть — сеть" между виртуальными сетями SDN и внешними клиентскими сетями через Интернет.
Создание подключений GRE между виртуальными сетями SDN и внешними сетями. Разница между подключениями типа "сеть — сеть" и GRE заключается в том, что последнее подключение не является зашифрованным.
Дополнительные сведения о сценариях подключения GRE см. в разделе Туннелирование GRE в Windows Server.
Создание подключений уровня 3 (L3) между виртуальными сетями SDN и внешними сетями. В этом случае шлюз SDN просто выступает в качестве маршрутизатора между виртуальной сетью и внешней сетью.
Для шлюза SDN требуется сетевой контроллер SDN. Сетевой контроллер выполняет развертывание пулов шлюзов, настраивает подключения клиентов к каждому шлюзу и переключает потоки сетевого трафика на резервный шлюз в случае сбоя шлюза.
Шлюзы используют протокол пограничного шлюза для объявления конечных точек GRE и установки подключений типа "точка — точка". При развертывании SDN создается пул шлюзов по умолчанию, который поддерживает все типы подключений. В этом пуле можно указать, сколько шлюзов зарезервировано в режиме ожидания в случае сбоя активного шлюза.
Дополнительные сведения см. в статье Что такое шлюз RAS для SDN?
Дальнейшие действия
Узнайте о шаблоне сети без коммутационных коммутаторов хранилища с двумя узлами.