Si applica a: Locale di Azure, versioni 23H2 e 22H2
Questo articolo illustra le considerazioni e i requisiti di rete fisici (infrastruttura) per Azure Local, in particolare per i commutatori di rete.
Nota
I requisiti per le versioni future locali di Azure possono cambiare.
Commutatori di rete per Azure Locale
Microsoft testa gli standard e i protocolli di Azure locali identificati nella sezione Requisiti del commutatore di rete seguente. Anche se Microsoft non certifica i commutatori di rete, microsoft collabora con i fornitori per identificare i dispositivi che supportano i requisiti locali di Azure.
Importante
Anche se altri commutatori di rete che usano tecnologie e protocolli non elencati qui potrebbero funzionare, Microsoft non può garantire che funzioni con Azure locale e potrebbe non essere in grado di facilitare la risoluzione dei problemi che si verificano.
Quando si acquistano commutatori di rete, contattare il fornitore del commutatore e assicurarsi che i dispositivi soddisfino i requisiti locali di Azure per i tipi di ruolo specificati. I fornitori seguenti (in ordine alfabetico) hanno confermato che le opzioni supportano i requisiti locali di Azure:
Fare clic su una scheda fornitore per visualizzare le opzioni convalidate per ognuno dei tipi di traffico locale di Azure. Queste classificazioni di rete sono disponibili qui.
Importante
Questi elenchi vengono aggiornati man mano che i fornitori di commutatori di rete sono informati delle modifiche.
Se il commutatore non è incluso, contattare il fornitore del commutatore per assicurarsi che il modello switch e la versione del sistema operativo del commutatore supporti i requisiti nella sezione successiva.
Broadcom Advanced Enterprise SONiC OS 4.2.1 o versione successiva
✓
✓
✓
✓
Nota
RdMA guest richiede sia Calcolo (Standard) che Archiviazione.
Requisiti del commutatore di rete
Questa sezione elenca gli standard di settore obbligatori per i ruoli specifici dei commutatori di rete usati nelle distribuzioni locali di Azure. Questi standard consentono di garantire comunicazioni affidabili tra nodi nelle distribuzioni locali di Azure.
Nota
Le schede di rete usate per il traffico di calcolo, archiviazione e gestione richiedono Ethernet. Per altre informazioni, vedere Requisiti di rete host.
Ecco gli standard e le specifiche IEEE obbligatori:
RdMA guest richiede sia Calcolo (Standard) che Archiviazione.
Standard: IEEE 802.1Q
I commutatori Ethernet devono essere conformi alla specifica IEEE 802.1Q che definisce le VLAN. Le VLAN sono necessarie per diversi aspetti di Azure Local e sono necessarie in tutti gli scenari.
Standard: IEEE 802.1Qbb
I commutatori Ethernet usati per il traffico di archiviazione locale di Azure devono essere conformi alla specifica IEEE 802.1Qbb che definisce il controllo del flusso di priorità (PFC). PFC è obbligatorio in cui viene usato Il data center Bridging (DCB). Poiché DCB può essere usato in entrambi gli scenari RoCE e iWARP RDMA, 802.1Qbb è necessario in tutti gli scenari. Sono necessarie almeno tre priorità di classe di servizio (CoS) senza eseguire il downgrade delle funzionalità del commutatore o delle velocità delle porte. Almeno una di queste classi di traffico deve fornire comunicazioni senza perdita di dati.
Standard: IEEE 802.1Qaz
I commutatori Ethernet usati per il traffico di archiviazione locale di Azure devono essere conformi alla specifica IEEE 802.1Qaz che definisce Enhanced Transmission Select (ETS). ETS è obbligatorio in cui viene usato DCB. Poiché DCB può essere usato in entrambi gli scenari RoCE e iWARP RDMA, 802.1Qaz è necessario in tutti gli scenari.
Sono necessarie almeno tre priorità coS senza eseguire il downgrade delle funzionalità del commutatore o della velocità delle porte. Inoltre, se il dispositivo consente di definire le tariffe QoS in ingresso, è consigliabile non configurare le frequenze di ingresso o configurarle con lo stesso valore delle tariffe in uscita (ETS).
Nota
L'infrastruttura iperconvergente ha un'elevata dipendenza dalla comunicazione est-ovest-layer-2 all'interno dello stesso rack e quindi richiede ETS. Microsoft non testa Azure Local with Differentiated Services Code Point (DSCP).
Standard: IEEE 802.1AB
I commutatori Ethernet devono essere conformi alla specifica IEEE 802.1AB che definisce il protocollo LLDP (Link Layer Discovery Protocol). LLDP è necessario per Azure Local e consente la risoluzione dei problemi delle configurazioni di rete fisica.
La configurazione dei valori di tipo LLDP (TLV) deve essere abilitata in modo dinamico. I commutatori non devono richiedere una configurazione aggiuntiva oltre all'abilitazione di un TLV specifico. Ad esempio, l'abilitazione della sottotipo 802.1 3 dovrebbe annunciare automaticamente tutte le VLAN disponibili sulle porte switch.
Requisiti TLV personalizzati
LLDP consente alle organizzazioni di definire e codificare i propri TLV personalizzati. Questi valori sono denominati TLV specifici dell'organizzazione. Tutti i TLV specifici dell'organizzazione iniziano con un valore di tipo TLV LLDP pari a 127. La tabella seguente mostra i sottotipi TLV personalizzati (TLV Tipo 127) specifici dell'organizzazione necessari.
Organizzazione
Sottotipo TLV
IEEE 802.1
ID VLAN della porta (sottotipo = 1)
IEEE 802.1
Nome VLAN (sottotipo = 3) Minimo 10 VLANS
IEEE 802.1
Aggregazione collegamento (sottotipo = 7)
IEEE 802.1
Configurazione ETS (sottotipo = 9)
IEEE 802.1
Raccomandazione ETS (sottotipo = A)
IEEE 802.1
Configurazione PFC (sottotipo = B)
IEEE 802.3
Dimensioni massime frame (sottotipo = 4)
Unità di trasmissione massima
L'unità di trasmissione massima (MTU) è il frame o il pacchetto di dimensioni maggiori che possono essere trasmessi attraverso un collegamento dati. Per l'incapsulamento SDN è necessario un intervallo compreso tra 1514 e 9174.
Border Gateway Protocol
I commutatori Ethernet usati per il traffico di calcolo SDN locale di Azure devono supportare Il protocollo BGP (Border Gateway Protocol). BGP è un protocollo di routing standard usato per scambiare informazioni di routing e raggiungibilità tra due o più reti. Le route vengono aggiunte automaticamente alla tabella di route di tutte le subnet con propagazione BGP abilitata. Questa operazione è necessaria per abilitare i carichi di lavoro del tenant con SDN e peering dinamico. RFC 4271: Border Gateway Protocol 4
Agente di inoltro DHCP
I commutatori Ethernet usati per il traffico di gestione locale di Azure devono supportare l'agente di inoltro DHCP. L'agente di inoltro DHCP è qualsiasi host TCP/IP usato per inoltrare richieste e risposte tra il server DHCP e il client quando il server è presente in una rete diversa. È necessario per i servizi di avvio PXE. RFC 3046: DHCPv4 o RFC 6148: DHCPv4
Requisiti del ruolo 22H2
Requisito
Gestione
Storage
Calcolo (Standard)
Calcolo (SDN)
LANS virtuale
✓
✓
✓
✓
Controllo del flusso di priorità
✓
Selezione trasmissione avanzata
✓
ID VLAN della porta LLDP
✓
Nome VLAN LLDP
✓
✓
✓
Aggregazione collegamento LLDP
✓
✓
✓
✓
Configurazione di LLDP ETS
✓
Raccomandazione LLDP ETS
✓
Configurazione PFC LLDP
✓
LLDP Maximum Frame Size
✓
✓
✓
✓
Unità di trasmissione massima
✓
Border Gateway Protocol
✓
Agente di inoltro DHCP
✓
Nota
RdMA guest richiede sia Calcolo (Standard) che Archiviazione.
Standard: IEEE 802.1Q
I commutatori Ethernet devono essere conformi alla specifica IEEE 802.1Q che definisce le VLAN. Le VLAN sono necessarie per diversi aspetti di Azure Local e sono necessarie in tutti gli scenari.
Standard: IEEE 802.1Qbb
I commutatori Ethernet usati per il traffico di archiviazione locale di Azure devono essere conformi alla specifica IEEE 802.1Qbb che definisce il controllo del flusso di priorità (PFC). PFC è obbligatorio in cui viene usato Il data center Bridging (DCB). Poiché DCB può essere usato in entrambi gli scenari RoCE e iWARP RDMA, 802.1Qbb è necessario in tutti gli scenari. Sono necessarie almeno tre priorità di classe di servizio (CoS) senza eseguire il downgrade delle funzionalità del commutatore o delle velocità delle porte. Almeno una di queste classi di traffico deve fornire comunicazioni senza perdita di dati.
Standard: IEEE 802.1Qaz
I commutatori Ethernet usati per il traffico di archiviazione locale di Azure devono essere conformi alla specifica IEEE 802.1Qaz che definisce Enhanced Transmission Select (ETS). ETS è obbligatorio in cui viene usato DCB. Poiché DCB può essere usato in entrambi gli scenari RoCE e iWARP RDMA, 802.1Qaz è necessario in tutti gli scenari.
Sono necessarie almeno tre priorità coS senza eseguire il downgrade delle funzionalità del commutatore o della velocità delle porte. Inoltre, se il dispositivo consente di definire le tariffe QoS in ingresso, è consigliabile non configurare le frequenze di ingresso o configurarle con lo stesso valore delle tariffe in uscita (ETS).
Nota
L'infrastruttura iperconvergente ha un'elevata dipendenza dalla comunicazione est-ovest-layer-2 all'interno dello stesso rack e quindi richiede ETS. Microsoft non testa Azure Local with Differentiated Services Code Point (DSCP).
Standard: IEEE 802.1AB
I commutatori Ethernet devono essere conformi alla specifica IEEE 802.1AB che definisce il protocollo LLDP (Link Layer Discovery Protocol). LLDP è necessario per Azure Local e consente la risoluzione dei problemi delle configurazioni di rete fisica.
La configurazione dei valori di tipo LLDP (TLV) deve essere abilitata in modo dinamico. I commutatori non devono richiedere una configurazione aggiuntiva oltre all'abilitazione di un TLV specifico. Ad esempio, l'abilitazione della sottotipo 802.1 3 dovrebbe annunciare automaticamente tutte le VLAN disponibili sulle porte switch.
Requisiti TLV personalizzati
LLDP consente alle organizzazioni di definire e codificare i propri TLV personalizzati. Questi valori sono denominati TLV specifici dell'organizzazione. Tutti i TLV specifici dell'organizzazione iniziano con un valore di tipo TLV LLDP pari a 127. La tabella seguente mostra i sottotipi TLV personalizzati (TLV Tipo 127) specifici dell'organizzazione necessari.
Organizzazione
Sottotipo TLV
IEEE 802.1
ID VLAN della porta (sottotipo = 1)
IEEE 802.1
Nome VLAN (sottotipo = 3) Minimo 10 VLANS
IEEE 802.1
Aggregazione collegamento (sottotipo = 7)
IEEE 802.1
Configurazione ETS (sottotipo = 9)
IEEE 802.1
Raccomandazione ETS (sottotipo = A)
IEEE 802.1
Configurazione PFC (sottotipo = B)
IEEE 802.3
Dimensioni massime frame (sottotipo = 4)
Unità di trasmissione massima
Nuovo requisito nella versione 22H2
L'unità di trasmissione massima (MTU) è il frame o il pacchetto di dimensioni maggiori che possono essere trasmessi attraverso un collegamento dati. Per l'incapsulamento SDN è necessario un intervallo compreso tra 1514 e 9174.
Border Gateway Protocol
Nuovo requisito nella versione 22H2
I commutatori Ethernet usati per il traffico di calcolo SDN locale di Azure devono supportare Il protocollo BGP (Border Gateway Protocol). BGP è un protocollo di routing standard usato per scambiare informazioni di routing e raggiungibilità tra due o più reti. Le route vengono aggiunte automaticamente alla tabella di route di tutte le subnet con propagazione BGP abilitata. Questa operazione è necessaria per abilitare i carichi di lavoro del tenant con SDN e peering dinamico. RFC 4271: Border Gateway Protocol 4
Agente di inoltro DHCP
Nuovo requisito nella versione 22H2
I commutatori Ethernet usati per il traffico di gestione locale di Azure devono supportare l'agente di inoltro DHCP. L'agente di inoltro DHCP è qualsiasi host TCP/IP usato per inoltrare richieste e risposte tra il server DHCP e il client quando il server è presente in una rete diversa. È necessario per i servizi di avvio PXE. RFC 3046: DHCPv4 o RFC 6148: DHCPv4
Traffico di rete e architettura
Questa sezione è prevalentemente destinata agli amministratori di rete.
Azure Local può funzionare in varie architetture di data center, tra cui 2 livelli (Spine-Leaf) e 3 livelli (Core-Aggregation-Access). Questa sezione si riferisce maggiormente ai concetti della topologia Spine-Leaf comunemente usata con i carichi di lavoro nell'infrastruttura iperconvergente, ad esempio Locale di Azure.
Modelli di rete
Il traffico di rete può essere classificato in base alla relativa direzione. Gli ambienti SAN (Storage Area Network) tradizionali sono molto a nord-sud, dove il traffico passa da un livello di calcolo a un livello di archiviazione attraverso un limite IP (Layer-3). L'infrastruttura iperconvergente è più pesantemente est-ovest, dove una parte sostanziale del traffico rimane all'interno di un limite VLAN (Layer-2).
Importante
È consigliabile che tutti i computer locali di Azure in un sito si trovino fisicamente nello stesso rack e connessi agli stessi commutatori top-of-rack (ToR).
Nota
La funzionalità del cluster esteso è disponibile solo in Locale di Azure, versione 22H2.
Traffico a nord-sud per Azure locale
Il traffico nord-sud presenta le caratteristiche seguenti:
Il traffico esce da un interruttore ToR alla colonna vertebrale o da una colonna vertebrale a un interruttore ToR.
Il traffico lascia il rack fisico o supera un limite di livello 3 (IP).
Include la gestione (PowerShell, Windows Admin Center), il calcolo (VM) e il traffico del cluster esteso tra siti.
Usa un commutatore Ethernet per la connettività alla rete fisica.
Traffico east-west per Azure locale
Il traffico est-ovest presenta le caratteristiche seguenti:
Il traffico rimane all'interno dei commutatori ToR e del limite di livello 2 (VLAN).
Include il traffico di archiviazione o il traffico di Live Migration tra nodi nello stesso sistema e (se si usa un cluster esteso) all'interno dello stesso sito.
Può usare un commutatore Ethernet (commutato) o una connessione diretta (senza commutatore), come descritto nelle due sezioni successive.
Uso delle opzioni
Il traffico nord-sud richiede l'uso di commutatori. Oltre a usare un commutatore Ethernet che supporta i protocolli necessari per Azure Local, l'aspetto più importante è il dimensionamento appropriato dell'infrastruttura di rete.
È fondamentale comprendere la larghezza di banda dell'infrastruttura "non bloccante" che i commutatori Ethernet possono supportare e ridurre al minimo (o preferibilmente eliminare) l'oversubscription della rete.
I punti di congestione e l'oversubscription comuni, ad esempio il gruppo di aggregazioni collegamento a più chassis usato per la ridondanza del percorso, possono essere eliminati usando correttamente subnet e VLAN. Vedere anche Requisiti di rete host.
Collaborare con il fornitore di rete o il team di supporto della rete per assicurarsi che i commutatori di rete siano stati ridimensionati correttamente per il carico di lavoro che si intende eseguire.
Uso di switchless
Azure Local supporta connessioni senza cambio (diretto) per il traffico East-West per tutte le dimensioni del sistema, purché ogni nodo del sistema disponga di una connessione ridondante a ogni nodo del sistema. Si tratta di una connessione "full-mesh".
Coppia di interfacce
Subnet
VLAN
Scheda di interfaccia di rete virtuale dell'host Mgmt
Specifici del cliente
Specifici del cliente
SMB01
192.168.71.x/24
711
SMB02
192.168.72.x/24
712
SMB03
192.168.73.x/24
713
Nota
I vantaggi delle distribuzioni senza cambio diminuiscono con sistemi superiori a tre nodi a causa del numero di schede di rete necessarie.
Vantaggi delle connessioni senza cambio
Non è necessario alcun acquisto switch per il traffico East-West. Per il traffico nord-sud è necessario un commutatore. Ciò può comportare costi di spesa in conto capitale (CAPEX) inferiori, ma dipende dal numero di nodi nel sistema.
Poiché non è presente alcun commutatore, la configurazione è limitata all'host, che può ridurre il numero potenziale di passaggi di configurazione necessari. Questo valore diminuisce man mano che aumentano le dimensioni del sistema.
Svantaggi delle connessioni senza cambio
Per gli schemi di indirizzamento IP e subnet è necessaria una pianificazione maggiore.
Fornisce solo l'accesso all'archiviazione locale. Il traffico di gestione, il traffico delle macchine virtuali e altro traffico che richiede l'accesso nord-sud non può usare queste schede.
Man mano che aumenta il numero di nodi nel sistema, il costo delle schede di rete potrebbe superare il costo dell'uso dei commutatori di rete.
La scalabilità non supera i sistemi a tre nodi. Altri nodi comportano un cablaggio e una configurazione aggiuntivi che possono superare la complessità dell'uso di un commutatore.
L'espansione del sistema è complessa e richiede modifiche alla configurazione hardware e software.