Requisiti di rete host per Azure Stack HCI

  • Articolo

Si applica a: Azure Stack HCI, versioni 23H2 e 22H2

Questo argomento illustra le considerazioni e i requisiti di rete host per Azure Stack HCI. Per informazioni sulle architetture del data center e sulle connessioni fisiche tra server, vedere Requisiti di rete fisici.

Per informazioni su come semplificare la rete host usando Network ATC, vedere Semplificare la rete host con Network ATC.

Tipi di traffico di rete

Il traffico di rete di Azure Stack HCI può essere classificato allo scopo previsto:

  • Traffico di gestione: Traffico verso o dall'esterno del cluster locale. Ad esempio, il traffico di replica di archiviazione o il traffico usato dall'amministratore per la gestione del cluster, ad esempio Desktop remoto, Windows Admin Center, Active Directory e così via.
  • Calcolo del traffico: Traffico proveniente da o destinato a una macchina virtuale (VM).
  • Traffico di archiviazione: Traffico con Server Message Block (SMB), ad esempio Spazi di archiviazione diretta o migrazione live basata su SMB. Questo traffico è di livello 2 e non è instradabile.

Importante

La replica di archiviazione usa traffico SMB basato su non RDMA. Questa e la natura direzionale del traffico (Nord-Sud) lo rende strettamente allineato a quello del traffico "di gestione" elencato sopra, simile a quello di una condivisione file tradizionale.

Selezionare una scheda di rete

Le schede di rete sono qualificate dai tipi di traffico di rete (vedere sopra) supportate per l'uso. Quando si esamina il catalogo di Windows Server, la certificazione Windows Server 2022 indica ora uno o più dei ruoli seguenti. Prima di acquistare un server per Azure Stack HCI, è necessario avere almeno una scheda qualificata per la gestione, il calcolo e l'archiviazione in quanto tutti e tre i tipi di traffico sono necessari in Azure Stack HCI. È quindi possibile usare Network ATC per configurare le schede per i tipi di traffico appropriati.

Per altre informazioni su questa qualificazione della scheda di interfaccia di rete basata su ruoli, vedere questo collegamento.

Importante

L'uso di un adattatore esterno al tipo di traffico qualificato non è supportato.

Level Ruolo di gestione Ruolo di calcolo Ruolo di archiviazione
Distinzione basata sul ruolo Gestione Compute Standard Storage Standard
Premio massimo Non applicabile Calcolo Premium Archiviazione Premium

Nota

La qualifica più alta per qualsiasi adattatore nell'ecosistema conterrà le qualifiche Management, Compute Premium e Storage Premium .

Screenshot che mostra le qualifiche

Requisiti del driver

I driver posta in arrivo non sono supportati per l'uso con Azure Stack HCI. Per identificare se l'adattatore usa un driver in arrivo, eseguire il cmdlet seguente. Un adattatore usa un driver in arrivo se la proprietà DriverProvider è Microsoft.

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

Panoramica delle funzionalità della scheda di rete chiave

Le funzionalità importanti della scheda di rete usate da Azure Stack HCI includono:

  • Multi-queue di macchine virtuali dinamiche (VMMQ dinamico o d.VMMQ)
  • RDMA (Remote Direct Memory Access)
  • Guest RDMA
  • Switch Embedded Teaming (SET)

VMMQ dinamica

Tutte le schede di rete con la qualificazione Compute (Premium) supportano dynamic VMMQ. VmMQ dinamica richiede l'uso di Switch Embedded Teaming.

Tipi di traffico applicabili: calcolo

Certificazioni necessarie: Calcolo (Premium)

VmMQ dinamica è una tecnologia intelligente e lato ricezione. Si basa sui suoi predecessori della coda di macchine virtuali (VMQ), il ridimensionamento lato ricezione virtuale (vRSS) e VMMQ, per offrire tre miglioramenti principali:

  • Ottimizza l'efficienza dell'host usando meno core CPU.
  • Ottimizzazione automatica dell'elaborazione del traffico di rete ai core CPU, consentendo così alle macchine virtuali di soddisfare e mantenere la velocità effettiva prevista.
  • Consente ai carichi di lavoro "bursty" di ricevere la quantità prevista di traffico.

Per altre informazioni su Dynamic VMMQ, vedere il post di blog Accelerazioni sintetiche.

RDMA

RDMA è un offload dello stack di rete nella scheda di rete. Consente al traffico di archiviazione SMB di ignorare il sistema operativo per l'elaborazione.

RDMA consente la velocità effettiva elevata, la bassa latenza, l'uso di risorse cpu host minime. Queste risorse cpu host possono quindi essere usate per eseguire macchine virtuali o contenitori aggiuntivi.

Tipi di traffico applicabili: archiviazione host

Certificazioni necessarie: Archiviazione (Standard)

Tutte le schede con archiviazione (Standard) o la qualifica di Archiviazione (Premium) supportano RDMA sul lato host. Per altre informazioni sull'uso di RDMA con carichi di lavoro guest, vedere la sezione "Guest RDMA" più avanti in questo articolo.

Azure Stack HCI supporta RDMA con le implementazioni del protocollo RdMA (Internet Wide Area RDMA Protocol) o RDMA su Converged Ethernet (RoCE).

Importante

Le schede RDMA funzionano solo con altre schede RDMA che implementano lo stesso protocollo RDMA (iWARP o RoCE).

Non tutte le schede di rete dei fornitori supportano RDMA. Nella tabella seguente sono elencati i fornitori (in ordine alfabetico) che offrono schede RDMA certificate. Tuttavia, esistono fornitori di hardware non inclusi in questo elenco che supportano anche RDMA. Per trovare schede con la qualifica Storage (Standard) o Storage (Premium), vedere Il catalogo di Windows Server che richiede il supporto RDMA.

Nota

InfiniBand (IB) non è supportato con Azure Stack HCI.

Fornitore della scheda di interfaccia di rete iWARP RoCE
Broadcom No Sì
Intel Sì Sì (alcuni modelli)
Marvell (Qlogic) Sì Sì
Nvidia No Sì

Per altre informazioni sulla distribuzione di RDMA per l'host, è consigliabile usare Network ATC. Per informazioni sulla distribuzione manuale, vedere il repository GitHub SDN.

iWARP

iWARP usa Il protocollo TCP (Transmission Control Protocol) e può essere facoltativamente migliorato con Il controllo del flusso basato su priorità (PFC) e il servizio di trasmissione avanzata (ETS).

Usare iWARP se:

  • Non si ha esperienza nella gestione delle reti RDMA.
  • Non è possibile gestire o non gestire i commutatori top-of-rack (ToR).
  • Non si gestirà la soluzione dopo la distribuzione.
  • Sono già disponibili distribuzioni che usano iWARP.
  • Non si è certi dell'opzione da scegliere.

RoCE

RoCE usa il protocollo UDP (User Datagram Protocol) e richiede PFC e ETS per garantire l'affidabilità.

Usare RoCE se:

  • Sono già disponibili distribuzioni con RoCE nel data center.
  • Si è a proprio agio nella gestione dei requisiti di rete DCB.

Guest RDMA

RDMA guest consente ai carichi di lavoro SMB per le macchine virtuali di ottenere gli stessi vantaggi dell'uso di RDMA negli host.

Tipi di traffico applicabili: Archiviazione basata su guest

Certificazioni necessarie: Calcolo (Premium)

I vantaggi principali dell'uso di RDMA guest sono:

  • Offload della CPU nella scheda di interfaccia di rete per l'elaborazione del traffico di rete.
  • Latenza estremamente bassa.
  • Velocità effettiva elevata.

Per altre informazioni, scaricare il documento dal repository GitHub SDN.

Switch Embedded Teaming (SET)

SET è una tecnologia di raggruppamento basata su software inclusa nel sistema operativo Windows Server da Windows Server 2016. SET è l'unica tecnologia di creazione dei gruppi supportata da Azure Stack HCI. SET funziona bene con il traffico di calcolo, archiviazione e gestione ed è supportato con fino a otto schede nello stesso team.

Tipi di traffico applicabili: calcolo, archiviazione e gestione

Certificazioni necessarie: Calcolo (Standard) o calcolo (Premium)

SET è l'unica tecnologia di creazione dei gruppi supportata da Azure Stack HCI. SET funziona bene con il traffico di calcolo, archiviazione e gestione.

Importante

Azure Stack HCI non supporta il raggruppamento NIC con il bilanciamento del carico/failover (LBFO) meno recente. Per altre informazioni su LBFO in Azure Stack HCI in Azure Stack HCI, vedere il post di blog Teaming in Azure Stack HCI.

SET è importante per Azure Stack HCI perché è l'unica tecnologia di raggruppamento che consente:

  • Raggruppamento di adattatori RDMA (se necessario).
  • RDMA guest.
  • VMMQ dinamico.
  • Altre funzionalità chiave di Azure Stack HCI (vedere Raggruppamento in Azure Stack HCI).

SET richiede l'uso di schede simmetriche (identiche). Le schede di rete simmetriche sono quelle con gli stessi attributi di:

  • Marca (fornitore)
  • Modello (versione)
  • Velocità (velocità effettiva)
  • configurazione

In 22H2, Network ATC rileverà e informerà automaticamente se le schede scelte sono asimmetriche. Il modo più semplice per identificare manualmente se le schede sono simmetriche è se le velocità e le descrizioni dell'interfaccia sono corrispondenze esatte . Possono deviare solo nel numero elencato nella descrizione. Usare il Get-NetAdapterAdvancedProperty cmdlet per assicurarsi che la configurazione segnalata elenchi gli stessi valori delle proprietà.

Vedere la tabella seguente per un esempio delle descrizioni dell'interfaccia che deviano solo in base al numero (#):

Nome Descrizione dell'interfaccia Velocità di collegamento
NIC1 Scheda di rete n. 1 25 Gbps
NIC2 Scheda di rete n. 2 25 Gbps
NIC3 Scheda di rete n. 3 25 Gbps
NIC4 Scheda di rete n. 4 25 Gbps

Nota

SET supporta solo la configurazione indipendente dal commutatore tramite algoritmi di bilanciamento del carico delle porte dinamiche o Hyper-V. Per prestazioni ottimali, è consigliabile usare la porta Hyper-V in tutte le schede di interfaccia di rete che operano a 10 o più Gbps. Network ATC rende tutte le configurazioni necessarie per SET.

Considerazioni sul traffico RDMA

Se si implementa DCB, è necessario assicurarsi che la configurazione PFC ed ETS sia implementata correttamente in ogni porta di rete, inclusi i commutatori di rete. DCB è necessario per RoCE e facoltativo per iWARP.

Per informazioni dettagliate su come distribuire RDMA, scaricare il documento dal repository GitHub SDN.

Le implementazioni di Azure Stack HCI basate su RoCE richiedono la configurazione di tre classi di traffico PFC, inclusa la classe di traffico predefinita, nell'infrastruttura e in tutti gli host.

Classe di traffico del cluster

Questa classe di traffico garantisce che sia disponibile una larghezza di banda sufficiente riservata agli heartbeat del cluster:

  • Richiesto: Sì
  • PFC abilitato: No
  • Priorità consigliata per il traffico: Priorità 7
  • Prenotazione della larghezza di banda consigliata:
    • 10 GbE o reti RDMA inferiori = 2%
    • 25 GbE o reti RDMA superiori = 1%

Classe di traffico RDMA

Questa classe di traffico garantisce una larghezza di banda sufficiente riservata alle comunicazioni RDMA senza perdita di dati tramite SMB diretto:

  • Richiesto: Sì
  • PFC abilitato: Sì
  • Priorità del traffico consigliata: priorità 3 o 4
  • Prenotazione della larghezza di banda consigliata: 50%

Classe di traffico predefinita

Questa classe di traffico trasporta tutto l'altro traffico non definito nelle classi di traffico cluster o RDMA, incluso il traffico della macchina virtuale e il traffico di gestione:

  • Obbligatorio: per impostazione predefinita (nessuna configurazione necessaria nell'host)
  • Controllo del flusso (PFC) abilitato: No
  • Classe di traffico consigliata: per impostazione predefinita (Priorità 0)
  • Prenotazione della larghezza di banda consigliata: per impostazione predefinita (nessuna configurazione host richiesta)

Modelli di traffico di archiviazione

SMB offre molti vantaggi come il protocollo di archiviazione per Azure Stack HCI, tra cui SMB multicanale. SMB multicanale non è trattato in questo articolo, ma è importante comprendere che il traffico è multiplexing tra tutti i collegamenti possibili che possono essere usati da SMB multicanale.

Nota

È consigliabile usare più subnet e VLAN per separare il traffico di archiviazione in Azure Stack HCI.

Si consideri l'esempio seguente di un cluster a quattro nodi. Ogni server ha due porte di archiviazione (lato sinistro e destro). Poiché ogni scheda si trova nella stessa subnet e nella stessa VLAN, SMB multicanale distribuirà le connessioni tra tutti i collegamenti disponibili. Di conseguenza, la porta sul lato sinistro sul primo server (192.168.1.1) effettuerà una connessione alla porta sul lato sinistro sul secondo server (192.168.1.2). La porta sul lato destro del primo server (192.168.1.12) si connetterà alla porta sul lato destro del secondo server. Vengono stabilite connessioni simili per il terzo e il quarto server.

Tuttavia, ciò crea connessioni non necessarie e causa la congestione all'interlink (gruppo di aggregazioni collegamento multi-chassis o MC-LAG) che connette le opzioni ToR (contrassegnate con Xs). Vedere il diagramma seguente:

Diagramma che mostra un cluster a quattro nodi nella stessa subnet.

L'approccio consigliato consiste nell'usare subnet e VLAN separate per ogni set di schede. Nel diagramma seguente le porte a destra usano ora la subnet 192.168.2.x /24 e VLAN2. Ciò consente al traffico sulle porte sul lato sinistro di rimanere su TOR1 e il traffico sulle porte sul lato destro per rimanere su TOR2.

Diagramma che mostra un cluster a quattro nodi in subnet diverse.

Allocazione della larghezza di banda del traffico

Nella tabella seguente vengono illustrate le allocazioni di larghezza di banda di esempio di vari tipi di traffico, usando velocità di adattatore comuni in Azure Stack HCI. Si noti che si tratta di un esempio di soluzione convergente, in cui tutti i tipi di traffico (calcolo, archiviazione e gestione) vengono eseguiti tramite SET.

Poiché questo caso d'uso pone i vincoli più importanti, rappresenta una linea di base valida. Tuttavia, considerando le permutazioni per il numero di adattatori e velocità, questo deve essere considerato un esempio e non un requisito di supporto.

Per questo esempio vengono effettuate le ipotesi seguenti:

  • Esistono due adattatori per ogni team.

  • Livello del bus di archiviazione (SBL), Volume condiviso cluster (CSV) e traffico Hyper-V (Live Migration):

    • Usare gli stessi adattatori fisici.
    • Usare SMB.

  • SMB viene assegnata un'allocazione della larghezza di banda del 50% usando DCB.

    • SBL/CSV è il traffico con priorità più alta e riceve il 70% della prenotazione della larghezza di banda SMB.
    • Live Migration (LM) è limitato usando il Set-SMBBandwidthLimit cmdlet e riceve il 29% della larghezza di banda rimanente.

      • Se la larghezza di banda disponibile per Live Migration è >= 5 Gbps e le schede di rete sono in grado di usare RDMA. Usare il cmdlet seguente per eseguire questa operazione:

        Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

      • Se la larghezza di banda disponibile per Live Migration è < di 5 Gbps, usare la compressione per ridurre i tempi di interruzione. Usare il cmdlet seguente per eseguire questa operazione:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

  • Se si usa RDMA per il traffico Live Migration, assicurarsi che il traffico di Live Migration non possa utilizzare l'intera larghezza di banda allocata alla classe di traffico RDMA usando un limite di larghezza di banda SMB. Prestare attenzione, perché questo cmdlet accetta la voce in byte al secondo (Bps), mentre le schede di rete sono elencate in bit al secondo (bps). Usare il cmdlet seguente per impostare un limite di larghezza di banda di 6 Gbps, ad esempio:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

    Nota

    750 MBps in questo esempio equivale a 6 Gbps.

Ecco la tabella di allocazione della larghezza di banda di esempio:

Velocità della scheda di interfaccia di rete Larghezza di banda in team Prenotazione della larghezza di banda SMB** SBL/CSV % Larghezza di banda SBL/CSV % Migrazione in tempo reale Larghezza di banda massima della migrazione in tempo reale Heartbeat % Larghezza di banda heartbeat
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

* Usare la compressione anziché RDMA, perché l'allocazione della larghezza di banda per il traffico live migration è <di 5 Gbps.

** 50% è una prenotazione di larghezza di banda di esempio.

Cluster estesi

I cluster estesi forniscono il ripristino di emergenza che si estende su più data center. Nella forma più semplice, una rete cluster HCI estesa di Azure Stack ha un aspetto simile al seguente:

Diagramma che mostra un cluster esteso.

Requisiti del cluster estesi

I cluster estesi hanno i requisiti e le caratteristiche seguenti:

  • RDMA è limitato a un singolo sito e non è supportato in siti o subnet diversi.

  • I server nello stesso sito devono risiedere nello stesso rack e nel limite di livello 2.

  • La comunicazione host tra siti deve superare un limite di livello 3; le topologie di livello 2 estese non sono supportate.

  • Avere una larghezza di banda sufficiente per eseguire i carichi di lavoro nell'altro sito. In caso di failover, il sito alternativo dovrà eseguire tutto il traffico. È consigliabile effettuare il provisioning dei siti al 50% della capacità di rete disponibile. Questo non è tuttavia un requisito, se è possibile tollerare prestazioni inferiori durante un failover.

  • La replica tra siti (traffico nord/sud) può usare le stesse schede di interfaccia di rete fisiche dell'archiviazione locale (traffico est/ovest). Se si usano gli stessi adattatori fisici, è necessario eseguire il team di queste schede con SET. Le schede devono avere anche schede di interfaccia di rete virtuali aggiuntive di cui è stato effettuato il provisioning per il traffico instradabile tra i siti.

  • Adattatori usati per la comunicazione tra i siti:

    • Può essere fisica o virtuale (vNIC host). Se le schede sono virtuali, è necessario effettuare il provisioning di una scheda di interfaccia di rete virtuale nella propria subnet e VLAN per scheda di interfaccia di rete fisica.

    • Deve essere nella propria subnet e VLAN che può instradare tra i siti.

    • RDMA deve essere disabilitato usando il Disable-NetAdapterRDMA cmdlet. È consigliabile richiedere esplicitamente la replica di archiviazione per usare interfacce specifiche usando il Set-SRNetworkConstraint cmdlet.

    • Deve soddisfare eventuali requisiti aggiuntivi per la replica di archiviazione.

Esempio di cluster esteso

Nell'esempio seguente viene illustrata una configurazione del cluster estesa. Per assicurarsi che una scheda di interfaccia di rete virtuale specifica venga mappata a una scheda fisica specifica, usare il cmdlet Set-VMNetworkAdapterTeammapping .

Diagramma che mostra un esempio di archiviazione cluster estesa.

Di seguito vengono illustrati i dettagli relativi alla configurazione del cluster estesa di esempio.

Nota

La configurazione esatta, inclusi i nomi della scheda di interfaccia di rete, gli indirizzi IP e le reti virtuali, potrebbe essere diversa da quella visualizzata. Questa operazione viene usata solo come configurazione di riferimento che può essere adattata all'ambiente.

SiteA : replica locale, abilitata per RDMA, non instradabile tra siti

Nome nodo Nome della scheda di interfaccia di rete virtuale Scheda di interfaccia di rete fisica (mappata) VLAN IP e subnet Ambito del traffico
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Solo sito locale
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 Solo sito locale
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 Solo sito locale
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 Solo sito locale

SiteB : replica locale, abilitata per RDMA, non instradabile tra siti

Nome nodo Nome della scheda di interfaccia di rete virtuale Scheda di interfaccia di rete fisica (mappata) VLAN IP e subnet Ambito del traffico
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Solo sito locale
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Solo sito locale
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Solo sito locale
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Solo sito locale

SiteA : replica estesa, RDMA disabilitata, instradabile tra siti

Nome nodo Nome della scheda di interfaccia di rete virtuale Scheda di interfaccia di rete fisica (mappata) IP e subnet Ambito del traffico
NodeA1 Stretch1 pNIC01 173.0.0.1/8 Cross-Site Routable
NodeA2 Stretch1 pNIC01 173.0.0.2/8 Intersito instradabile
NodeA1 Stretch2 pNIC02 174.0.0.1/8 Intersito instradabile
NodeA2 Stretch2 pNIC02 174.0.0.2/8 Intersito instradabile

SiteB: replica estesa, RDMA disabilitata, instradabile tra siti

Nome nodo Nome della scheda di interfaccia di rete virtuale Scheda di interfaccia di rete fisica (mappata) IP e subnet Ambito del traffico
NodeB1 Stretch1 pNIC01 175.0.0.1/8 Intersito instradabile
NodeB2 Stretch1 pNIC01 175.0.0.2/8 Intersito instradabile
NodeB1 Stretch2 pNIC02 176.0.0.1/8 Intersito instradabile
NodeB2 Stretch2 pNIC02 176.0.0.2/8 Intersito instradabile

Passaggi successivi