Hostnetwerkvereisten voor Azure Stack HCI

Van toepassing op: Azure Stack HCI, versies 23H2 en 22H2

In dit onderwerp worden overwegingen en vereisten voor hostnetwerken voor Azure Stack HCI besproken. Zie Vereisten voor fysieke netwerken voor informatie over datacenterarchitecturen en de fysieke verbindingen tussen servers.

Zie Hostnetwerken vereenvoudigen met Netwerk ATC voor informatie over het vereenvoudigen van hostnetwerken met behulp van Netwerk ATC.

Typen netwerkverkeer

Azure Stack HCI-netwerkverkeer kan worden geclassificeerd op basis van het beoogde doel:

• Beheerverkeer: Verkeer naar of van buiten het lokale cluster. Bijvoorbeeld opslagreplicaverkeer of verkeer dat door de beheerder wordt gebruikt voor het beheer van het cluster, zoals Extern bureaublad, Windows Admin Center, Active Directory, enzovoort.
• Verkeer berekenen: Verkeer dat afkomstig is van of bestemd is voor een virtuele machine (VM).
• Opslagverkeer: Verkeer dat gebruikmaakt van Server Message Block (SMB), bijvoorbeeld Opslagruimten Direct of livemigratie op basis van SMB. Dit verkeer is laag 2-verkeer en is niet routeerbaar.

Belangrijk

Opslagreplica maakt gebruik van SMB-verkeer dat niet op RDMA is gebaseerd. Dit en de richtingsgerichte aard van het verkeer (Noord-Zuid) maakt het nauw afgestemd op het 'beheer'-verkeer dat hierboven wordt vermeld, vergelijkbaar met dat van een traditionele bestandsshare.

Een netwerkadapter selecteren

Netwerkadapters worden gekwalificeerd door de netwerkverkeerstypen (zie hierboven) waarmee ze worden ondersteund voor gebruik. Terwijl u de Windows Server-catalogus bekijkt, geeft de Windows Server 2022-certificering nu een of meer van de volgende functies aan. Voordat u een server voor Azure Stack HCI aanschaft, moet u minimaal één adapter hebben die gekwalificeerd is voor beheer, rekenkracht en opslag, omdat alle drie de verkeerstypen vereist zijn op Azure Stack HCI. U kunt vervolgens netwerk-ATC gebruiken om uw adapters te configureren voor de juiste verkeerstypen.

Zie deze koppeling voor meer informatie over deze op rollen gebaseerde NIC-kwalificatie.

Belangrijk

Het gebruik van een adapter buiten het gekwalificeerde verkeerstype wordt niet ondersteund.

Niveau	Beheerrol	Rekenrol	Opslagrol
Onderscheid op basis van rollen	Beheer	Compute Standard	Storage Standard
Maximumprijs	Niet van toepassing	Compute Premium	Storage Premium

Notitie

De hoogste kwalificatie voor elke adapter in ons ecosysteem bevat de kwalificaties Management, Compute Premium en Storage Premium .

Stuurprogrammavereisten

Postvak IN-stuurprogramma's worden niet ondersteund voor gebruik met Azure Stack HCI. Voer de volgende cmdlet uit om te bepalen of uw adapter een stuurprogramma voor Postvak IN gebruikt. Een adapter gebruikt een stuurprogramma voor postvak IN als de eigenschap DriverProviderMicrosoft is.

Get-NetAdapter -Name <AdapterName> | Select *Driver*

Overzicht van de belangrijkste mogelijkheden van de netwerkadapter

Belangrijke netwerkadaptermogelijkheden die door Azure Stack HCI worden gebruikt, zijn onder andere:

• Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ of d.VMMQ)
• Remote Direct Memory Access (RDMA)
• Gast-RDMA
• Switch ingesloten Teaming (SET)

Dynamische VMMQ

Alle netwerkadapters met de kwalificatie Compute (Premium) ondersteunen dynamische VMMQ. Voor dynamische VMMQ is het gebruik van Switch Embedded Teaming vereist.

Toepasselijke verkeerstypen: berekenen

Vereiste certificeringen: Compute (Premium)

Dynamische VMMQ is een intelligente technologie aan de ontvangstzijde. Het bouwt voort op zijn voorgangers van Virtual Machine Queue (VMQ), Virtual Receive Side Scaling (vRSS) en VMMQ, om drie primaire verbeteringen te bieden:

• Optimaliseert de hostefficiëntie door minder CPU-kernen te gebruiken.
• Automatisch afstemmen van de verwerking van netwerkverkeer op CPU-kernen, zodat VM's aan de verwachte doorvoer kunnen voldoen en behouden.
• Hiermee kunnen 'bursty'-workloads de verwachte hoeveelheid verkeer ontvangen.

Zie het blogbericht Synthetische versnellingen voor meer informatie over dynamische VMMQ.

RDMA

RDMA is een netwerkstack-offload naar de netwerkadapter. Hiermee kan SMB-opslagverkeer het besturingssysteem omzeilen voor verwerking.

RDMA maakt netwerken met een hoge doorvoer en lage latentie mogelijk, met behulp van minimale host-CPU-resources. Deze CPU-resources van de host kunnen vervolgens worden gebruikt om extra VM's of containers uit te voeren.

Toepasselijke verkeerstypen: hostopslag

Vereiste certificeringen: Opslag (Standard)

Alle adapters met de kwalificatie Storage (Standard) of Storage (Premium) ondersteunen RDMA aan de hostzijde. Zie de sectie 'Gast-RDMA' verderop in dit artikel voor meer informatie over het gebruik van RDMA met gastworkloads.

Azure Stack HCI ondersteunt RDMA met de implementaties van het Internet Wide Area RDMA Protocol (iWARP) of RDMA via Geconvergeerd Ethernet (RoCE).

Belangrijk

RDMA-adapters werken alleen met andere RDMA-adapters die hetzelfde RDMA-protocol (iWARP of RoCE) implementeren.

Niet alle netwerkadapters van leveranciers ondersteunen RDMA. De volgende tabel bevat de leveranciers (in alfabetische volgorde) die gecertificeerde RDMA-adapters aanbieden. Er zijn echter hardwareleveranciers die niet in deze lijst zijn opgenomen, die ook RDMA ondersteunen. Zie de Windows Server-catalogus om adapters te vinden met de kwalificatie Storage (Standard) of Storage (Premium) waarvoor RDMA-ondersteuning is vereist.

Notitie

InfiniBand (IB) wordt niet ondersteund met Azure Stack HCI.

NIC-leverancier	iWARP	Roce
Broadcom	Nee	Ja
Intel	Yes	Ja (sommige modellen)
Marvell (Qlogic)	Ja	Ja
Nvidia	Nee	Ja

Voor meer informatie over het implementeren van RDMA voor de host raden we u ten zeerste aan network ATC te gebruiken. Zie de SDN GitHub-opslagplaats voor informatie over handmatige implementatie.

iWARP

iWARP maakt gebruik van Transmission Control Protocol (TCP) en kan optioneel worden uitgebreid met PfC (Priority-Based Flow Control) en Enhanced Transmission Service (ETS).

Gebruik iWARP als:

• U hebt geen ervaring met het beheren van RDMA-netwerken.
• U beheert uw ToR-switches (top-of-rack) niet of voelt zich er niet ongemakkelijk bij.
• U beheert de oplossing niet na de implementatie.
• U hebt al implementaties die gebruikmaken van iWARP.
• U weet niet zeker welke optie u moet kiezen.

Roce

RoCE maakt gebruik van User Datagram Protocol (UDP) en vereist PFC en ETS om betrouwbaarheid te bieden.

Gebruik RoCE als:

• U hebt al implementaties met RoCE in uw datacenter.
• U bent vertrouwd met het beheren van de DCB-netwerkvereisten.

Gast-RDMA

Met gast-RDMA kunnen SMB-workloads voor VM's dezelfde voordelen krijgen van het gebruik van RDMA op hosts.

Toepasselijke verkeerstypen: Opslag op basis van gasten

Vereiste certificeringen: Compute (Premium)

De belangrijkste voordelen van het gebruik van gast-RDMA zijn:

• CPU-offload naar de NIC voor de verwerking van netwerkverkeer.
• Extreem lage latentie.
• Hoge doorvoer.

Download het document uit de SDN GitHub-opslagplaats voor meer informatie.

Switch ingesloten Teaming (SET)

SET is een op software gebaseerde teamtechnologie die sinds Windows Server 2016 is opgenomen in het Windows Server-besturingssysteem. SET is de enige teamingtechnologie die wordt ondersteund door Azure Stack HCI. SET werkt goed met reken-, opslag- en beheerverkeer en wordt ondersteund met maximaal acht adapters in hetzelfde team.

Toepasselijke verkeerstypen: rekenkracht, opslag en beheer

Vereiste certificeringen: Compute (Standard) of Compute (Premium)

SET is de enige teamingtechnologie die wordt ondersteund door Azure Stack HCI. SET werkt goed met reken-, opslag- en beheerverkeer.

Belangrijk

Azure Stack HCI biedt geen ondersteuning voor NIC-koppeling met de oudere LBFO (Load Balancing/Failover). Zie het blogbericht Teaming in Azure Stack HCI voor meer informatie over LBFO in Azure Stack HCI.

SET is belangrijk voor Azure Stack HCI omdat dit de enige koppelingstechnologie is die het volgende mogelijk maakt:

• Koppeling van RDMA-adapters (indien nodig).
• Gast-RDMA.
• Dynamische VMMQ.
• Andere belangrijke Azure Stack HCI-functies (zie Teaming in Azure Stack HCI).

SET vereist het gebruik van symmetrische (identieke) adapters. Symmetrische netwerkadapters zijn adapters met dezelfde:

• merk (leverancier)
• Model (versie)
• snelheid (doorvoer)
• configuratie

In 22H2 detecteert netwerk-ATC automatisch of de adapters die u hebt gekozen asymmetrisch zijn. De eenvoudigste manier om handmatig vast te stellen of adapters symmetrisch zijn, is als de snelheden en interfacebeschrijvingen exact overeenkomen. Ze kunnen alleen afwijken in de cijfers die in de beschrijving worden vermeld. Gebruik de Get-NetAdapterAdvancedProperty cmdlet om ervoor te zorgen dat in de gerapporteerde configuratie dezelfde eigenschapswaarden worden vermeld.

Zie de volgende tabel voor een voorbeeld van de interfacebeschrijvingen die alleen afwijken van cijfers (#):

Name	Interfacebeschrijving	Koppelingssnelheid
NIC1	Netwerkadapter 1	25 Gbps
NIC2	Netwerkadapter 2	25 Gbps
NIC3	Netwerkadapter 3	25 Gbps
NIC4	Netwerkadapter 4	25 Gbps

Notitie

SET ondersteunt alleen switchonafhankelijke configuratie met behulp van dynamische of Hyper-V-poorttaakverdelingsalgoritmen. Voor de beste prestaties wordt Hyper-V Port aanbevolen voor gebruik op alle NIC's met minimaal 10 Gbps. Netwerk-ATC maakt alle vereiste configuraties voor SET.

Overwegingen voor RDMA-verkeer

Als u DCB implementeert, moet u ervoor zorgen dat de PFC- en ETS-configuratie correct wordt geïmplementeerd op elke netwerkpoort, inclusief netwerkswitches. DCB is vereist voor RoCE en optioneel voor iWARP.

Download het document vanuit de SDN GitHub-opslagplaats voor gedetailleerde informatie over het implementeren van RDMA.

Op RoCE gebaseerde Azure Stack HCI-implementaties vereisen de configuratie van drie PFC-verkeersklassen, inclusief de standaardverkeersklasse, in de infrastructuur en alle hosts.

Clusterverkeersklasse

Deze verkeersklasse zorgt ervoor dat er voldoende bandbreedte is gereserveerd voor cluster heartbeats:

• Vereist: ja
• PFC-ingeschakeld: Nee
• Aanbevolen verkeersprioriteit: Prioriteit 7
• Aanbevolen bandbreedtereservering:
  • 10 GbE of lagere RDMA-netwerken = 2 procent
  • RDMA-netwerken van 25 GbE of hoger = 1 procent

RDMA-verkeersklasse

Deze verkeersklasse zorgt ervoor dat er voldoende bandbreedte is gereserveerd voor rdma-communicatie zonder verlies met behulp van SMB Direct:

• Vereist: ja
• PFC ingeschakeld: Ja
• Aanbevolen verkeersprioriteit: Prioriteit 3 of 4
• Aanbevolen bandbreedtereservering: 50 procent

Standaardverkeersklasse

Deze verkeersklasse draagt al het andere verkeer dat niet is gedefinieerd in de cluster- of RDMA-verkeersklassen, met inbegrip van VM-verkeer en beheerverkeer:

• Vereist: standaard (geen configuratie vereist op de host)
• Stroombeheer (PFC) ingeschakeld: Nee
• Aanbevolen verkeersklasse: standaard (prioriteit 0)
• Aanbevolen bandbreedtereservering: standaard (geen hostconfiguratie vereist)

Modellen voor opslagverkeer

SMB biedt veel voordelen als opslagprotocol voor Azure Stack HCI, waaronder SMB meerdere kanalen. SMB Meerdere kanalen wordt niet behandeld in dit artikel, maar het is belangrijk om te begrijpen dat verkeer wordt gemultiplexeerd over elke mogelijke koppeling die SMB meerdere kanalen kan gebruiken.

Notitie

U wordt aangeraden meerdere subnetten en VLAN's te gebruiken om opslagverkeer in Azure Stack HCI van elkaar te scheiden.

Bekijk het volgende voorbeeld van een cluster met vier knooppunten. Elke server heeft twee opslagpoorten (links en rechts). Omdat elke adapter zich op hetzelfde subnet en VLAN bevindt, worden verbindingen met SMB Meerdere kanalen verspreid over alle beschikbare koppelingen. Daarom maakt de linkerpoort op de eerste server (192.168.1.1) een verbinding met de linkerpoort op de tweede server (192.168.1.2). De poort aan de rechterkant op de eerste server (192.168.1.12) maakt verbinding met de poort rechts op de tweede server. Vergelijkbare verbindingen worden tot stand gebracht voor de derde en vierde server.

Dit zorgt echter voor onnodige verbindingen en veroorzaakt congestie bij de interlink (multi-chassis linkaggregatiegroep of MC-LAG) die de ToR-switches verbindt (gemarkeerd met Xs). Zie het volgende diagram:

De aanbevolen aanpak is om afzonderlijke subnetten en VLAN's te gebruiken voor elke set adapters. In het volgende diagram gebruiken de rechterpoorten nu subnet 192.168.2.x /24 en VLAN2. Hierdoor kan het verkeer op de poorten aan de linkerkant op TOR1 blijven en het verkeer op de poorten aan de rechterkant op TOR2 blijven.

Toewijzing van verkeersbandbreedte

In de volgende tabel ziet u voorbeelden van bandbreedtetoewijzingen van verschillende verkeerstypen, met behulp van algemene adaptersnelheden, in Azure Stack HCI. Houd er rekening mee dat dit een voorbeeld is van een geconvergeerde oplossing, waarbij alle verkeerstypen (rekenkracht, opslag en beheer) via dezelfde fysieke adapters worden uitgevoerd en worden gekoppeld met behulp van SET.

Omdat deze use case de meeste beperkingen met zich meebrengt, vertegenwoordigt het een goede basislijn. Gezien de permutaties voor het aantal adapters en snelheden moet dit echter worden beschouwd als een voorbeeld en geen ondersteuningsvereiste.

Voor dit voorbeeld worden de volgende veronderstellingen gemaakt:

• Er zijn twee adapters per team.

• SBL-verkeer (Storage Bus Layer), Cluster Shared Volume (CSV) en Hyper-V-verkeer (livemigratie):

  • Gebruik dezelfde fysieke adapters.
  • Gebruik SMB.

• SMB krijgt een bandbreedtetoewijzing van 50 procent met behulp van DCB.

  • SBL/CSV heeft het hoogste prioriteitsverkeer en ontvangt 70 procent van de SMB-bandbreedtereservering.
  • Livemigratie (LM) wordt beperkt met behulp van de Set-SMBBandwidthLimit cmdlet en ontvangt 29 procent van de resterende bandbreedte.

    • Als de beschikbare bandbreedte voor livemigratie = 5 Gbps is >en de netwerkadapters geschikt zijn, gebruikt u RDMA. Gebruik hiervoor de volgende cmdlet:

      Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
      

    • Als de beschikbare bandbreedte voor livemigratie 5 Gbps is < , gebruikt u compressie om black-outtijden te verminderen. Gebruik hiervoor de volgende cmdlet:

      Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
      

• Als u RDMA gebruikt voor livemigratieverkeer, moet u ervoor zorgen dat livemigratieverkeer niet de volledige bandbreedte kan verbruiken die is toegewezen aan de RDMA-verkeersklasse met behulp van een SMB-bandbreedtelimiet. Wees voorzichtig, omdat deze cmdlet invoert in bytes per seconde (bps), terwijl netwerkadapters worden weergegeven in bits per seconde (bps). Gebruik de volgende cmdlet om bijvoorbeeld een bandbreedtelimiet van 6 Gbps in te stellen:

  Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
  

  Notitie

  750 MBps in dit voorbeeld is gelijk aan 6 Gbps.

Hier volgt de voorbeeldtabel voor bandbreedtetoewijzing:

NIC-snelheid	Gekoppelde bandbreedte	Reservering van SMB-bandbreedte**	Percentage SBL/CSV	SBL-/CSV-bandbreedte	Percentage livemigratie	Maximale bandbreedte voor livemigratie	Heartbeat %	Heartbeat-bandbreedte
10 Gbps	20 Gbps	10 Gbps	70%	7 Gbps	**	200 Mbps
25 Gbps	50 Gbps	25 Gbps	70%	17,5 Gbps	29%	7,25 Gbps	1%	250 Mbps
40 Gbps	80 Gbps	40 Gbps	70%	28 Gbps	29%	11,6 Gbps	1%	400 Mbps
50 Gbps	100 Gbps	50 Gbps	70%	35 Gbps	29%	14,5 Gbps	1%	500 Mbps
100 Gbps	200 Gbps	100 Gbps	70%	70 Gbps	29%	29 Gbps	1%	1 Gbps
200 Gbps	400 Gbps	200 Gbps	70%	140 Gbps	29%	58 Gbps	1%	2 Gbps

* Gebruik compressie in plaats van RDMA, omdat de bandbreedtetoewijzing voor livemigratieverkeer 5 Gbps is <.

** 50 procent is een voorbeeld van een bandbreedtereservering.

Stretched clusters

Stretched clusters bieden herstel na noodgeval dat meerdere datacenters omvat. In de eenvoudigste vorm ziet een stretched Azure Stack HCI-clusternetwerk er als volgt uit:

Vereisten voor stretched cluster

Stretched clusters hebben de volgende vereisten en kenmerken:

• RDMA is beperkt tot één site en wordt niet ondersteund op verschillende sites of subnetten.

• Servers op dezelfde site moeten zich in hetzelfde rek en laag-2-grens bevinden.

• Hostcommunicatie tussen sites moet een grens van laag 3 overschrijden; stretched Layer-2-topologieën worden niet ondersteund.

• Over voldoende bandbreedte beschikken om de workloads op de andere site uit te voeren. In het geval van een failover moet op de alternatieve site al het verkeer worden uitgevoerd. U wordt aangeraden sites in te richten met 50 procent van de beschikbare netwerkcapaciteit. Dit is echter geen vereiste als u lagere prestaties kunt tolereren tijdens een failover.

• Replicatie tussen sites (noord-/zuidverkeer) kan dezelfde fysieke NIC's gebruiken als de lokale opslag (oost/west-verkeer). Als u dezelfde fysieke adapters gebruikt, moeten deze adapters worden gekoppeld aan SET. De adapters moeten ook extra virtuele NIC's hebben die zijn ingericht voor routeerbaar verkeer tussen sites.

• Adapters die worden gebruikt voor communicatie tussen sites:

  • Kan fysiek of virtueel zijn (host-vNIC). Als adapters virtueel zijn, moet u één vNIC inrichten in een eigen subnet en VLAN per fysieke NIC.

  • Moet zich op hun eigen subnet en VLAN bevinden die tussen sites kunnen worden gerouteerd.

  • RDMA moet worden uitgeschakeld met behulp van de Disable-NetAdapterRDMA cmdlet. U wordt aangeraden expliciet te vereisen dat Opslagreplica specifieke interfaces gebruikt met behulp van de Set-SRNetworkConstraint cmdlet.

  • Moet voldoen aan eventuele aanvullende vereisten voor Opslagreplica.

Voorbeeld van stretched cluster

In het volgende voorbeeld ziet u een stretched clusterconfiguratie. Gebruik de cmdlet Set-VMNetworkAdapterTeammapping om ervoor te zorgen dat een specifieke virtuele NIC is toegewezen aan een specifieke fysieke adapter.

Hieronder ziet u de details voor de voorbeeldconfiguratie van het stretched-cluster.

Notitie

De exacte configuratie, inclusief NIC-namen, IP-adressen en VLAN's, kan afwijken van wat wordt weergegeven. Dit wordt alleen gebruikt als een referentieconfiguratie die kan worden aangepast aan uw omgeving.

SiteA : lokale replicatie, RDMA ingeschakeld, niet routeerbaar tussen sites

Knooppuntnaam	vNIC-naam	Fysieke NIC (toegewezen)	VLAN	IP en subnet	Verkeersbereik
NodeA1	vSMB01	pNIC01	711	192.168.1.1/24	Alleen lokale site
NodeA2	vSMB01	pNIC01	711	192.168.1.2/24	Alleen lokale site
NodeA1	vSMB02	pNIC02	712	192.168.2.1/24	Alleen lokale site
NodeA2	vSMB02	pNIC02	712	192.168.2.2/24	Alleen lokale site

SiteB : lokale replicatie, RDMA ingeschakeld, niet routeerbaar tussen sites

Knooppuntnaam	vNIC-naam	Fysieke NIC (toegewezen)	VLAN	IP en subnet	Verkeersbereik
KnooppuntB1	vSMB01	pNIC01	711	192.168.1.1/24	Alleen lokale site
KnooppuntB2	vSMB01	pNIC01	711	192.168.1.2/24	Alleen lokale site
KnooppuntB1	vSMB02	pNIC02	712	192.168.2.1/24	Alleen lokale site
KnooppuntB2	vSMB02	pNIC02	712	192.168.2.2/24	Alleen lokale site

SiteA : uitgerekte replicatie, RDMA uitgeschakeld, routeerbaar tussen sites

Knooppuntnaam	vNIC-naam	Fysieke NIC (toegewezen)	IP en subnet	Verkeersbereik
NodeA1	Stretch1	pNIC01	173.0.0.1/8	Routeerbaar op meerdere sites
NodeA2	Stretch1	pNIC01	173.0.0.2/8	Routeerbaar op meerdere sites
NodeA1	Stretch2	pNIC02	174.0.0.1/8	Routeerbaar op meerdere sites
NodeA2	Stretch2	pNIC02	174.0.0.2/8	Routeerbaar op meerdere sites

SiteB: uitgerekte replicatie, RDMA uitgeschakeld, routeerbaar tussen sites

Knooppuntnaam	vNIC-naam	Fysieke NIC (toegewezen)	IP en subnet	Verkeersbereik
NodeB1	Stretch1	pNIC01	175.0.0.1/8	Routeerbaar op meerdere sites
NodeB2	Stretch1	pNIC01	175.0.0.2/8	Routeerbaar op meerdere sites
NodeB1	Stretch2	pNIC02	176.0.0.1/8	Routeerbaar op meerdere sites
NodeB2	Stretch2	pNIC02	176.0.0.2/8	Routeerbaar op meerdere sites

Volgende stappen

• Meer informatie over netwerkswitch en fysieke netwerkvereisten. Zie Vereisten voor fysiek netwerk.
• Meer informatie over het vereenvoudigen van hostnetwerken met behulp van Network ATC. Zie Hostnetwerken vereenvoudigen met Network ATC.
• De basisbeginselen van het netwerk voor failoverclustering opspoetsen.
• Zie Implementeren met behulp van Azure Portal.
• Zie Implementeren met arm-sjabloon.