Requisiti di rete fisici per Azure Stack HCI
Si applica a: Azure Stack HCI, versioni 23H2 e 22H2
Questo articolo illustra considerazioni e requisiti di rete fisici (infrastruttura) per Azure Stack HCI, in particolare per i commutatori di rete.
Nota
I requisiti per le versioni future di Azure Stack HCI possono cambiare.
Commutatori di rete per Azure Stack HCI
Microsoft testa Azure Stack HCI agli standard e ai protocolli 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 di Azure Stack HCI.
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 Stack HCI 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 di Azure Stack HCI per i tipi di ruolo specificati. I fornitori seguenti (in ordine alfabetico) hanno confermato che le opzioni supportano i requisiti di Azure Stack HCI:
Fare clic su una scheda fornitore per visualizzare le opzioni convalidate per ognuno dei tipi di traffico di Azure Stack HCI. 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.
Requisiti del commutatore di rete
Questa sezione elenca gli standard di settore obbligatori per i ruoli specifici dei commutatori di rete usati nelle distribuzioni di Azure Stack HCI. Questi standard consentono di garantire comunicazioni affidabili tra nodi nelle distribuzioni di cluster Azure Stack HCI.
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:
Requisiti del ruolo 23H2
| 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 Stack HCI e sono necessarie in tutti gli scenari.
Standard: IEEE 802.1Qbb
I commutatori Ethernet usati per il traffico di archiviazione di Azure Stack HCI 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 di Azure Stack HCI 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 Stack HCI con un punto di codice DSCP (Differentiated Services Code Point).
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 Stack HCI 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 di Azure Stack HCI devono supportare Border Gateway Protocol (BGP). 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 di Azure Stack HCI 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 Stack HCI può funzionare in varie architetture di data center, tra cui 2 livelli (Spine-Leaf) e 3 livelli (Core-Aggregation-Access). Questa sezione fa riferimento a altri concetti della topologia Spine-Leaf comunemente usata con i carichi di lavoro nell'infrastruttura iperconvergente, ad esempio Azure Stack HCI.
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 nodi del cluster in un sito si trovino fisicamente nello stesso rack e connessi agli stessi commutatori ToR (Top-of-Rack).
Nota
La funzionalità del cluster esteso è disponibile solo in Azure Stack HCI versione 22H2.
Traffico nord-sud per Azure Stack HCI
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 Stack HCI
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 cluster 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 Stack HCI, l'aspetto più importante è il dimensionamento corretto 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 Stack HCI supporta connessioni senza cambio (diretto) per il traffico East-West per tutte le dimensioni del cluster, purché ogni nodo del cluster disponga di una connessione ridondante a ogni nodo del cluster. 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 i cluster di dimensioni 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 cluster.
- 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 le dimensioni del cluster aumentano.
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 cluster, il costo delle schede di rete potrebbe superare il costo dell'uso dei commutatori di rete.
- La scalabilità non supera i cluster 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 cluster è complessa e richiede modifiche alla configurazione hardware e software.
Passaggi successivi
- Vedere Deploy using portale di Azure (Distribuire con portale di Azure).
- Vedere Distribuire usando il modello di Azure Resource Manager.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per