Netwerkvereisten hosten voor Azure Stack HCI

  • Artikel
  • 12 minuten om te lezen

Van toepassing op: Azure Stack HCI, versies 21H2 en 20H2

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

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

Netwerkverkeerstypen

Azure Stack HCI-netwerkverkeer kan worden geclassificeerd met het beoogde doel:

  • Rekenverkeer: 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.
  • Beheerverkeer: Verkeer dat wordt gebruikt door de beheerder voor het beheer van het cluster, waaronder Extern bureaublad, Windows Admin Center, Active Directory, enzovoort.

Selecteer een netwerkadapter

Voor Azure Stack HCI moet u een netwerkadapter kiezen die de SDDC-certificering (Windows Server Software-Defined Data Center) heeft behaald met de Standard- of Premium Additional Qualification (AQ). Deze adapters ondersteunen de meest geavanceerde platformfuncties en hebben de meeste tests ondergaan door onze hardwarepartners. Dit niveau van controle leidt doorgaans tot een vermindering van hardware- en stuurprogrammagerelateerde kwaliteitsproblemen. Deze adapters voldoen ook aan de netwerkvereisten die zijn vastgesteld voor Opslagruimten Direct.

U kunt een adapter met Standard of Premium AQ identificeren door de Windows Server-catalogusvermelding voor de adapter en de toepasselijke versie van het besturingssysteem te controleren. Hier volgt een voorbeeld van de notatie voor Premium AQ:

Schermopname van windows gecertificeerde opties, met een Premium AQ-optie gemarkeerd.

Overzicht van de belangrijkste netwerkadaptermogelijkheden

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

  • Dynamische virtuele machine met meerdere wachtrijen (dynamische VMMQ of d.VMMQ)
  • Remote Direct Memory Access (RDMA)
  • Gast-RDMA
  • Switch ingesloten Teaming (SET)

Dynamische VMMQ

Alle netwerkadapters met de Premium AQ ondersteunen dynamische VMMQ. Dynamische VMMQ vereist het gebruik van Switch Embedded Teaming.

Toepasselijke verkeerstypen: berekenen

Vereiste certificeringen: 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 netwerkverkeerverwerking naar CPU-kernen, waardoor VM's aan de verwachte doorvoer kunnen voldoen en onderhouden.
  • 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 hoge doorvoer, lage latentie mogelijk, met minimale CPU-resources van de host. Deze CPU-resources van de host kunnen vervolgens worden gebruikt om extra VM's of containers uit te voeren.

Toepasselijke verkeerstypen: hostopslag

Vereiste certificeringen: Standaard

Alle adapters met Standard of Premium AQ ondersteunen RDMA. RDMA is de aanbevolen implementatiekeuze voor opslagworkloads in Azure Stack HCI en kan optioneel worden ingeschakeld voor opslagworkloads (met behulp van SMB) voor VM's. Zie de sectie Gast-RDMA verderop in dit artikel voor meer informatie.

Azure Stack HCI ondersteunt RDMA met behulp van het Internet Wide Area RDMA Protocol (iWARP) of RDMA via geconvergeerde Ethernet-protocolimplementaties (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 Premium-gecertificeerde RDMA-adapters aanbieden. Er zijn echter hardwareleveranciers die niet zijn opgenomen in deze lijst die ook RDMA ondersteunen. Zie de Windows Server-catalogus om RDMA-ondersteuning te controleren.

Notitie

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

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

Voor meer informatie over het implementeren van RDMA downloadt u het document uit de SDN GitHub-opslagplaats.

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 weinig of geen netwerkervaring of u bent ongemakkelijk bij het beheren van netwerkswitches.
  • U bepaalt uw ToR-switches (Top-Of-Rack) niet.
  • U beheert de oplossing niet na de implementatie.
  • U hebt al implementaties die gebruikmaken van iWARP.
  • U weet niet 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 kunt de vereisten voor het DCB-netwerk beheren.

Gast-RDMA

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

Toepasselijke verkeerstypen: Opslag op basis van gasten

Vereiste certificeringen: Premium

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

  • CPU-offload naar de NIC voor netwerkverkeerverwerking.
  • Extreem lage latentie.
  • Hoge doorvoer.

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

SET

SET is een softwaregebaseerde teamtechnologie die sinds Windows Server 2016 is opgenomen in het Windows Server-besturingssysteem. SET is niet afhankelijk van het type netwerkadapters dat wordt gebruikt.

Toepasselijke verkeerstypen: compute, opslag en beheer

Vereiste certificeringen: geen (SET is ingebouwd in het besturingssysteem)

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-koppelingstechnologieën (Load Balancing/Failover) en LACP-koppelingstechnologieën (Link Aggregation Control Protocol). 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 teamtechnologie 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. Koppeling van asymmetrische adapters wordt niet ondersteund. Symmetrische netwerkadapters zijn netwerkadapters die hetzelfde hebben:

  • maken (leverancier)
  • model (versie)
  • snelheid (doorvoer)
  • configuratie

De eenvoudigste manier om te bepalen of adapters symmetrisch zijn, is als de snelheden hetzelfde zijn en de interfacebeschrijvingen overeenkomen. Ze kunnen alleen afwijken in het cijfer dat in de beschrijving wordt vermeld. Gebruik de Get-NetAdapterAdvancedProperty cmdlet om ervoor te zorgen dat de gerapporteerde configuratie dezelfde eigenschapswaarden bevat.

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

Naam Interfacebeschrijving Snelheid van koppeling
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.

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.

Voor gedetailleerde informatie over het implementeren van RDMA downloadt u het document uit de GITHub-opslagplaats SDN.

Voor Op RoCE gebaseerde Azure Stack HCI-implementaties is de configuratie van drie PFC-verkeersklassen vereist, 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
    • 25 GbE of hoger RDMA-netwerken = 1 procent

RDMA-verkeersklasse

Deze verkeersklasse zorgt ervoor dat er voldoende bandbreedte is gereserveerd voor verliesloze RDMA-communicatie met behulp van SMB Direct:

  • Vereist: ja
  • PFC ingeschakeld: Ja
  • Aanbevolen prioriteit voor verkeer: prioriteit 3 of 4
  • Aanbevolen bandbreedtereservering: 50 procent

Standaardverkeersklasse

Deze verkeersklasse bevat alle andere verkeer dat niet is gedefinieerd in de cluster- of RDMA-verkeersklassen, inclusief 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 het opslagprotocol voor Azure Stack HCI, waaronder SMB meerdere kanalen. SMB Meerdere kanalen worden niet behandeld in dit artikel, maar het is belangrijk om te begrijpen dat verkeer wordt gemultixeerd 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 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, verspreidt SMB meerdere kanalen verbindingen over alle beschikbare koppelingen. Daarom maakt de poort aan de linkerkant op de eerste server (192.168.1.1) een verbinding met de poort aan de linkerkant op de tweede server (192.168.1.2). De rechterpoort op de eerste server (192.168.1.12) maakt verbinding met de rechterpoort op de tweede server. Vergelijkbare verbindingen worden tot stand gebracht voor de derde en vierde servers.

Dit creëert echter 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:

Diagram met een cluster met vier knooppunten in hetzelfde subnet.

De aanbevolen methode 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 verkeer aan de linkerkant op TOR1 blijven en het verkeer op de poorten aan de rechterkant op TOR2 blijven staan.

Diagram met een cluster met vier knooppunten op verschillende subnetten.

Toewijzing van verkeersbandbreedte

In de volgende tabel ziet u voorbeeld 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 (compute, opslag en beheer) worden uitgevoerd op dezelfde fysieke adapters en worden gekoppeld met SET.

Omdat deze use case de meeste beperkingen vormt, is het een goede basislijn. Rekening houdend met de permutaties voor het aantal adapters en snelheden, moet dit echter worden beschouwd als een voorbeeld en niet als een ondersteuningsvereiste.

De volgende veronderstellingen worden gemaakt voor dit voorbeeld:

  • Er zijn twee adapters per team.

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

    • Gebruik dezelfde fysieke adapters.
    • Gebruik SMB.

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

    • SBL/CSV is het hoogste prioriteitsverkeer en ontvangt 70 procent van de SMB-bandbreedtereservering.
    • Livemigratie (LM) wordt beperkt door de Set-SMBBandwidthLimit cmdlet te gebruiken 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 de volgende cmdlet om dit te doen:

        Set-VMHost VirtualMachineMigrationPerformanceOption SMB

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

        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 invoer in bytes per seconde (bps) accepteert, terwijl netwerkadapters worden vermeld in bits per seconde (bps). Gebruik de volgende cmdlet om een bandbreedtelimiet van 6 Gbps in te stellen, bijvoorbeeld:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

    Notitie

    750 MBps in dit voorbeeld zijn gelijk aan 6 Gbps.

Hier volgt de voorbeeldtabel voor bandbreedtetoewijzing:

NIC-snelheid Gekoppelde bandbreedte SMB-bandbreedtereservering** SBL/CSV - percentage SBL/CSV-bandbreedte Percentage livemigratie Maximale bandbreedte voor livemigratie Heartbeat % Heartbeatbandbreedte
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 noodgevallen die meerdere datacenters omvatten. In de eenvoudigste vorm ziet een stretched Azure Stack HCI-clusternetwerk er als volgt uit:

Diagram met een uitgerekt cluster.

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 laag-3 grens overschrijden; stretched Layer-2-topologieën worden niet ondersteund.

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

  • 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 zijn gekoppeld aan SET. De adapters moeten ook extra virtuele NIC's hebben 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. We raden u aan om opslagreplica expliciet te vereisen voor het gebruik van specifieke interfaces 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.

Diagram met een voorbeeld van stretched clusteropslag.

Hieronder ziet u de details voor de voorbeeldconfiguratie van een stretched cluster.

Notitie

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

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

Naam van knooppunt 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

Naam van knooppunt vNIC-naam Fysieke NIC (toegewezen) VLAN IP en subnet Verkeersbereik
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Alleen lokale site
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Alleen lokale site
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Alleen lokale site
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Alleen lokale site

SiteA : stretched replication, RDMA disabled, routeerbaar tussen sites

Naam van knooppunt 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 : stretched replication, RDMA disabled, routeerbaar tussen sites

Naam van knooppunt 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 voor meerdere sites
NodeB1 Stretch2 pNIC02 176.0.0.1/8 Routeerbaar voor meerdere sites
NodeB2 Stretch2 pNIC02 176.0.0.2/8 Routeerbaar voor meerdere sites

Volgende stappen