Condividi tramite

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 dell'host per Azure Stack HCI. Per informazioni sulle architetture dei data center e sulle connessioni fisiche tra server, vedere Requisiti di rete fisici.

Per informazioni su come semplificare la rete host tramite 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 in base allo scopo previsto:

  • Traffico di gestione: traffico da o verso l'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.
  • Traffico di calcolo: il traffico proveniente o destinato a una macchina virtuale.Compute traffic traffic from or destined to a virtual machine (VM).
  • Traffico di archiviazione: traffico con SMB (Server Message Block), ad esempio Spazi di archiviazione diretta o migrazione in tempo reale basata su SMB. Questo traffico è di livello 2 e non è instradabile.

Importante

La replica di archiviazione usa traffico SMB non basato su RDMA. Questo 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) con cui sono supportate. Quando si esamina il catalogo di Windows Server, la certificazione di 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 perché 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 qualifica della scheda di interfaccia di rete basata sui ruoli, vedere questo collegamento.

Importante

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

Level Ruolo di gestione Ruolo di calcolo Ruolo di archiviazione
Distinzione basata sui ruoli Gestione Calcolo Standard Storage Standard
Premio massimo Non applicabile Calcolo Premium Archiviazione Premium

Nota

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

Screenshot che mostra le qualifiche certificate per Windows, incluse le funzionalità Management, Compute Premium e Storage Premium.

Requisiti per i driver

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

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

Panoramica delle funzionalità delle schede di rete chiave

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

  • Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ o d.VMMQ)
  • RDMA (Remote Direct Memory Access)
  • Guest RDMA
  • Switch Embedded Teaming (SET)

VMMQ dinamico

Tutte le schede di rete con qualificazione Calcolo (Premium) supportano DYNAMIC VMMQ. VMMQ dinamico richiede l'uso di Switch Embedded Teaming.

Tipi di traffico applicabili: calcolo

Certificazioni obbligatorie: Calcolo (Premium)

VMMQ dinamico è una tecnologia intelligente sul lato ricezione. Si basa sui predecessori di Virtual Machine Queue (VMQ), Virtual Receive Side Scaling (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 verso 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 una rete a bassa latenza e velocità effettiva elevata, usando risorse cpu host minime. Queste risorse della 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 qualificazione Archiviazione (Standard) o 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 Internet Wide Area RDMA Protocol (iWARP) 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 adattatori RDMA certificati. Tuttavia, ci sono fornitori di hardware non inclusi in questo elenco che supportano anche RDMA. Vedi il Catalogo di Windows Server per trovare gli adattatori con la qualifica Archiviazione (Standard) o Archiviazione (Premium) 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 avanzato (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 ha familiarità con la 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 obbligatorie: 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 a partire 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 obbligatorie: 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, 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 schede RDMA (se necessario).
  • RDMA guest.
  • VMMQ dinamico.
  • 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 rileverà e informerà automaticamente se le schede scelte sono asimmetriche. Il modo più semplice per identificare manualmente se gli adattatori sono simmetrici è se le descrizioni delle velocità e delle interfacce corrispondono esattamente . 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 usando 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 e ETS sia 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, inclusa la classe di traffico predefinita, nell'infrastruttura e in tutti gli host.

Classe di traffico del cluster

Questa classe di traffico garantisce una larghezza di banda sufficiente riservata per gli 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 usando 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 il 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 viene sottoposto a multiplexing in ogni possibile collegamento che può essere usato 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 del 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.

In questo modo, tuttavia, vengono create connessioni non necessarie e si verifica una congestione all'interlink (gruppo di aggregazioni di collegamenti a più chassis o MC-LAG) che connette i commutatori ToR (contrassegnati 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 di 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

La tabella seguente illustra le allocazioni di larghezza di banda di esempio di vari tipi di traffico, usando le velocità comuni delle schede, 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 sulle stesse schede fisiche e vengono raggruppati usando SET.

Poiché questo caso d'uso rappresenta la maggior parte dei vincoli, 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 effettuati i presupposti seguenti:

  • Sono disponibili due adattatori per ogni team.

  • Traffico SBL (Storage Bus Layer), Volume condiviso cluster (CSV) e Hyper-V (Live Migration):

    • Usare gli stessi adattatori fisici.
    • Usare SMB.

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

    • SBL/CSV è il traffico con priorità più alta e riceve il 70% della prenotazione della larghezza di banda SMB.
    • Live Migration (LM) è limitato tramite 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 black-out. 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 voci 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 max live migration % 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 di Live Migration è <di 5 Gbps.

** Il 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 di cluster Azure Stack HCI estesa ha un aspetto simile al seguente:

Diagramma che mostra un cluster esteso.

Requisiti del cluster esteso

Importante

La funzionalità del cluster esteso è disponibile solo in Azure Stack HCI versione 22H2.

I cluster estesi hanno i requisiti e le caratteristiche seguenti:

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

  • I server nello stesso sito devono trovarsi nello stesso rack e nello stesso 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.

  • 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.

  • Adattatori usati per la comunicazione tra siti:

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

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

    • RDMA deve essere disabilitato tramite il Disable-NetAdapterRDMA cmdlet . È consigliabile richiedere esplicitamente a Replica archiviazione di usare interfacce specifiche usando il Set-SRNetworkConstraint cmdlet .

    • Deve soddisfare eventuali requisiti aggiuntivi per Replica di archiviazione.

Passaggi successivi