Requisiti di rete host per Azure Locale
Si applica a: Azure Local 2311.2 e versioni successive
Questo argomento illustra le considerazioni e i requisiti relativi alla rete host per Azure Locale. Per informazioni sulle architetture dei data center e sulle connessioni fisiche tra computer, vedere Requisiti di rete fisici.
Per informazioni su come semplificare la rete host tramite Network ATC, vedere Semplificare la rete host con Network ATC.
Il traffico di rete locale di Azure può essere classificato in base allo scopo previsto:
- Traffico di gestione: traffico da o verso l'esterno del sistema locale. Ad esempio, il traffico di replica di archiviazione o il traffico usato dall'amministratore per la gestione del sistema, 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.
Le schede di rete sono qualificate in base ai tipi di traffico di rete per cui sono progettate (vedere sopra). 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 computer per l'ambiente locale di Azure, è 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 Locale di Azure. È quindi possibile usare Network ATC per configurare gli adattatori per i tipi di traffico appropriati.
Per ulteriori informazioni su questa qualifica NIC basata sui ruoli, vedere questo articolo del blog Windows Server.
Importante
L'uso di un adattatore all'esterno del tipo di traffico qualificato non è supportato.
| Livello | Ruolo di gestione | Ruolo di calcolo | Ruolo di archiviazione |
|---|---|---|---|
| Distinzione basata sui ruoli | Gestione | Calcolo Standard | Standard di Archiviazione |
| 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 .
I driver posta in arrivo non sono supportati per l'uso con Azure Local. Per identificare se l'adattatore usa un driver posta in arrivo, eseguire il cmdlet seguente. Un adattatore utilizza un driver integrato se la proprietà DriverProvider è Microsoft.
Get-NetAdapter -Name <AdapterName> | Select *Driver*
Le funzionalità importanti della scheda di rete usate da Azure Local includono:
- Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ o d.VMMQ)
- RDMA (Remote Direct Memory Access)
- Guest RDMA
- Switch Embedded Teaming (SET)
Tutte le schede di rete con certificazione Computazione (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 per la ricezione intelligente. 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 impulsivi di ricevere il volume previsto di traffico.
Per ulteriori informazioni su Dynamic VMMQ, vedere il post sul blog Accelerazioni sintetiche.
RDMA è un trasferimento del carico di elaborazione dello stack di rete alla 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)
Tutti gli adattatori con qualificazione Archiviazione (Standard) o Archiviazione (Premium) supportano RDMA 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 Local supporta RDMA con le implementazioni dei protocolli Internet Wide Area RDMA Protocol (iWARP) o RDMA over 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 produttori 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 certificazione Archiviazione (Standard) o Archiviazione (Premium) che richiedono il supporto RDMA.
Nota
InfiniBand (IB) non è supportato con Azure Local.
| Fornitore della scheda di interfaccia di rete | iWARP | Rendimento del Capitale Investito (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 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 gestisci o ti senti a disagio nel gestire i commutatori Top-of-Rack (ToR).
- Non gestirai la soluzione dopo la distribuzione.
- Sono già disponibili distribuzioni che usano iWARP.
- Non si è certi dell'opzione da scegliere.
RoCE usa il protocollo UDP (User Datagram Protocol) e richiede PFC e ETS per garantire l'affidabilità.
Utilizza RoCE se:
- Hai già distribuzioni con RoCE nel tuo data center.
- Hai familiarità con la gestione dei requisiti di rete DCB.
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 ospite
Certificazioni obbligatorie: Calcolo (Premium)
I vantaggi principali dell'uso di RdMA guest sono:
- Scarico della CPU sulla scheda 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.
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 raggruppamento supportata da Azure Local. SET funziona bene con il traffico di elaborazione, archiviazione e gestione e supporta 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 raggruppamento supportata da Azure Local. SET funziona bene con il traffico di calcolo, archiviazione e gestione.
Importante
Azure Local non supporta il teaming delle NIC con le versioni più vecchie di bilanciamento del carico/failover (LBFO). Per ulteriori informazioni su LBFO in Locale di Azure, vedere il post del blog Teaming in Azure Local.
SET è importante per l'ambiente locale di Azure perché è l'unica tecnologia di raggruppamento che consente:
- Raggruppamento di schede RDMA (se necessario).
- Guest RDMA.
- VMMQ dinamico.
- Altre funzionalità principali locali di Azure (vedere Raggruppamento in Locale di Azure).
SET richiede l'uso di adattatori simmetrici (identici). Le schede di rete simmetriche sono quelle con gli stessi attributi di:
- Marca (fornitore)
- Modello (versione)
- Velocità (capacità di trasmissione)
- configurazione
In 22H2, Network ATC rileverà automaticamente e ti informerà se le schede di rete che hai scelto 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.
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 locali di Azure 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.
Questa classe di traffico garantisce una larghezza di banda sufficiente riservata agli heartbeat di sistema:
- 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%
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%
Questa classe di traffico trasporta tutto l'altro traffico non definito nelle classi di traffico di sistema 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)
SMB offre molti vantaggi come il protocollo di archiviazione per Azure Locale, incluso SMB multicanale. SMB Multicanale non è trattato in questo articolo, ma è importante comprendere che il traffico viene multiplexato attraverso ogni possibile collegamento che SMB Multicanale può utilizzare.
Nota
È consigliabile usare più subnet e VLAN per separare il traffico di archiviazione in Locale di Azure.
Si consideri l'esempio seguente di un sistema a quattro nodi. Ogni computer 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 computer (192.168.1.1) effettuerà una connessione alla porta a sinistra sul secondo computer (192.168.1.2). La porta sul lato destro del primo computer (192.168.1.12) si connetterà alla porta sul lato destro del secondo computer. Vengono stabilite connessioni simili per la terza e la quarta macchina.
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:
L'approccio consigliato consiste nell'usare delle subnet e VLAN separate per ogni set di adattatori. 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.
La tabella seguente illustra allocazioni di larghezza di banda di esempio per vari tipi di traffico, usando le velocità comuni degli adattatori, in Azure Local. 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), Volumi condivisi 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-SMBBandwidthLimitcmdlet 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 compatibili con RDMA. Usare il cmdlet seguente per eseguire questa operazione:
Set-VMHost -VirtualMachineMigrationPerformanceOption SMBSe 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 dati 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 750MBNota
750 MBps in questo esempio equivale a 6 Gbps.
Ecco la tabella di allocazione della larghezza di banda di esempio:
| Velocità della scheda 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 Migrazione live | Battito cardiaco % | Larghezza di banda impulso |
|---|---|---|---|---|---|---|---|---|
| 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.
I cluster estesi forniscono il ripristino di emergenza che si estende su più data center. Nel suo formato più semplice, un cluster esteso di Azure Local è simile al seguente:
Importante
La funzionalità del cluster esteso è disponibile solo in Locale di Azure, 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 computer 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 (host vNIC). Se gli adattatori sono virtuali, devi configurare un vNIC nella propria subnet e VLAN per ciascuna 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-NetAdapterRDMAcmdlet . È consigliabile richiedere esplicitamente a Replica di archiviazione di usare interfacce specifiche usando il cmdletSet-SRNetworkConstraint.Deve soddisfare eventuali requisiti aggiuntivi per le Repliche di archiviazione.
- Informazioni sul commutatore di rete e sui requisiti di rete fisici. Vedere Requisiti di rete fisici.
- Informazioni su come semplificare la rete host usando Network ATC. Vedere Semplificare la rete host con Network ATC.
- Nozioni di base sulla rete del clustering di failover.
- Vedere Distribuire utilizzando il portale di Azure.
- Vedere Distribuire usando il modello di Azure Resource Manager.