Requisiti di rete host per Azure Stack HCI
Si applica a: Azure Stack HCI, versioni 22H2 e 21H2
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 .
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 si gestisce o si è scomodi a gestire le opzioni top-of-rack (ToR).
- Non si gestirà la soluzione dopo la distribuzione.
- Sono già disponibili distribuzioni che usano iWARP.
- Non si è certi di quale opzione scegliere.
RoCE
RoCE usa il protocollo UDP (User Datagram Protocol) e richiede PFC e ETS per fornire affidabilità.
Usare RoCE se:
- Sono già disponibili distribuzioni con RoCE nel data center.
- Si è in grado di gestire i 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 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 teaming 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 team della scheda di interfaccia di rete con il bilanciamento del carico/failover precedente. Per altre informazioni su LBFO 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 teaming che consente:
- Teaming di schede RDMA (se necessario).
- RDMA guest.
- VMMQ dinamica.
- Altre funzionalità chiave di Azure Stack HCI (vedere Teaming 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 rileva automaticamente e informa se le schede scelte sono asimmetriche. Il modo più semplice per identificare manualmente se gli adattatori sono simmetrici è se le descrizioni di velocità e 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 per numerale (#):
Nome | Descrizione dell'interfaccia | Velocità di collegamento |
---|---|---|
NIC1 | Scheda di rete #1 | 25 Gbps |
NIC2 | Scheda di rete #2 | 25 Gbps |
NIC3 | Scheda di rete #3 | 25 Gbps |
NIC4 | Scheda di rete #4 | 25 Gbps |
Nota
SET supporta solo la configurazione indipendente dal commutatore usando algoritmi di bilanciamento del carico di porta Dinamici 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 e ETS venga implementata correttamente in ogni porta di rete, inclusi i commutatori di rete. DCB è obbligatorio 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, tra cui la classe di traffico predefinita, nell'infrastruttura e in tutti gli host.
Classe di traffico del cluster
Questa classe di traffico garantisce che sia presente una larghezza di banda sufficiente riservata agli heartbeat del cluster:
- Richiesto: Sì
- PFC abilitato: No
- Priorità del traffico consigliata: 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 che sia disponibile una larghezza di banda sufficiente riservata alle comunicazioni RDMA senza perdita usando SMB Direct:
- 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 tutti gli altri traffico non definiti nelle classi di traffico cluster o RDMA, tra cui il traffico della macchina virtuale e il traffico di gestione:
- Obbligatorio: per impostazione predefinita (nessuna configurazione necessaria nell'host)
- Controllo 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 protocollo di archiviazione per Azure Stack HCI, tra cui SMB Multichannel. SMB Multichannel non è trattato in questo articolo, ma è importante comprendere che il traffico è multiplexed in ogni possibile collegamento che SMB Multichannel può usare.
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 dispone di due porte di archiviazione (lato sinistro e destro). Poiché ogni scheda si trova nella stessa subnet e VLAN, SMB Multichannel distribuirà le connessioni tra tutti i collegamenti disponibili. Pertanto, la porta sul lato sinistro del primo server (192.168.1.1) eseguirà una connessione alla porta lato sinistra 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. Le connessioni simili vengono stabilite per il terzo e 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:
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.
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:
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 ilSet-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 .
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 | Cross-Site Routable |
NodeA1 | Stretch2 | pNIC02 | 174.0.0.1/8 | Cross-Site Routable |
NodeA2 | Stretch2 | pNIC02 | 174.0.0.2/8 | Cross-Site Routable |
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 | Cross-Site Routable |
NodeB2 | Stretch1 | pNIC01 | 175.0.0.2/8 | Cross-Site Routable |
NodeB1 | Stretch2 | pNIC02 | 176.0.0.1/8 | Cross-Site Routable |
NodeB2 | Stretch2 | pNIC02 | 176.0.0.2/8 | Cross-Site Routable |
Passaggi successivi
- Informazioni sui requisiti di rete e di rete fisica. Vedere Requisiti di rete fisici.
- Informazioni su come semplificare la rete host usando Network ATC. Vedere Semplificare la rete host con Network ATC.
- Eseguire il pennello sulle nozioni di base sul clustering di failover.
- Per la distribuzione, vedere Creare un cluster usando Windows Admin Center.
- Per la distribuzione, vedere Creare un cluster usando Windows PowerShell.