Requisiti di rete fisica per Azure Stack HCI

  • Articolo

Si applica a: Azure Stack HCI, versioni 23H2 e 22H2

Questo articolo illustra le considerazioni e i 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 possono funzionare, Microsoft non può garantire che funzionino con Azure Stack HCI e potrebbero 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 vengono informati delle modifiche da parte dei fornitori dei commutatori di rete.

Se il commutatore non è incluso, contattare il fornitore del commutatore per assicurarsi che il modello switch e la versione del sistema operativo del commutatore supportino 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.

Di seguito sono riportati gli standard IEEE obbligatori e le specifiche:

Requisiti del ruolo 23H2

Requisito Gestione Archiviazione Calcolo (Standard) Calcolo (SDN)
LANS virtuale ✓ ✓ ✓ ✓
Controllo del flusso di priorità ✓
Selezione trasmissione avanzata ✓
ID VLAN della porta LLDP ✓
Nome VLAN LLDP ✓ ✓ ✓
Aggregazione di collegamenti LLDP ✓ ✓ ✓ ✓
Configurazione di LLDP ETS ✓
Raccomandazione LLDP ETS ✓
Configurazione PFC LLDP ✓
Dimensioni massime del frame LLDP ✓ ✓ ✓ ✓
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 reti virtuali 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 HCI di Azure Stack 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, è necessario 802.1Qbb in tutti gli scenari. Sono necessarie almeno tre priorità di servizio (CoS) senza ridurre le funzionalità del commutatore o le velocità delle porte. Almeno una di queste classi di traffico deve fornire comunicazioni senza perdita.

Standard: IEEE 802.1Qaz

I commutatori Ethernet usati per il traffico di archiviazione HCI di Azure Stack devono essere conformi alla specifica IEEE 802.1Qaz che definisce La selezione di trasmissione avanzata (ETS). ETS è obbligatorio in cui viene usato DCB. Poiché DCB può essere usato sia negli scenari RoCE che iWARP RDMA, è necessario 802.1Qaz in tutti gli scenari.

È necessario un minimo di tre priorità coS senza ridurre le funzionalità del commutatore o la velocità della porta. Inoltre, se il dispositivo consente di definire le tariffe QoS in ingresso, è consigliabile non configurare le tariffe in ingresso o configurarle con lo stesso valore delle tariffe in uscita (ETS).

Nota

L'infrastruttura iperconvergente ha un'elevata dipendenza dalle comunicazioni di livello 2 East-West all'interno dello stesso rack e quindi richiede ETS. Microsoft non testa Azure Stack HCI con il punto di codice dei servizi differenziati (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 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. Le opzioni non devono richiedere una configurazione aggiuntiva oltre all'abilitazione di un TLV specifico. Ad esempio, l'abilitazione di 802.1 Sottotipo 3 deve annunciare automaticamente tutte le VLAN disponibili nelle porte switch.

Requisiti TLV personalizzati

LLDP consente alle organizzazioni di definire e codificare le proprie TLV personalizzate. Questi sono denominati TLV specifici dell'organizzazione. Tutte le TLV specifiche dell'organizzazione iniziano con un valore di tipo TLV LLDP pari a 127. La tabella seguente mostra i sottotipi TLV personalizzati specifici dell'organizzazione (TLV Type 127) necessari.

Organizzazione Sottotipo TLV
IEEE 802.1 ID VLAN della porta (Sottotipo = 1)
IEEE 802.1 Nome VLAN (sottotipo = 3)
Minimo di 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 del frame (sottotipo = 4)

Unità di trasmissione massima

L'unità di trasmissione massima (MTU) è la cornice o il pacchetto di dimensioni più grandi che possono essere trasmessi in un collegamento dati. Un intervallo di 1514 - 9174 è necessario per l'incapsulamento SDN.

Border Gateway Protocol

I commutatori Ethernet usati per il traffico di calcolo SDN di Azure Stack HCI 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 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 si riferisce più ai 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 North-South in cui il traffico passa da un livello di calcolo a un livello di archiviazione attraverso un limite IP (Layer-3). L'infrastruttura iperconvergente è più pesantemente East-West in cui una parte sostanziale del traffico rimane entro 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).

North-South traffico per Azure Stack HCI

North-South traffico presenta le caratteristiche seguenti:

  • Il traffico passa da un commutatore ToR alla spina dorsale o dalla colonna vertebrale a un commutatore ToR.
  • Il traffico lascia il rack fisico o attraversa 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.

East-West traffico per Azure Stack HCI

East-West traffico 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 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 di commutatori

North-South traffico 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 ridimensionamento appropriato dell'infrastruttura di rete.

È imperativo 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 comuni e l'oversubscription, ad esempio il gruppo di aggregazioni collegamento multi-chassis usato per la ridondanza del percorso, possono essere eliminati tramite l'uso appropriato di subnet e VLAN. Vedere anche Requisiti di rete host.

Collaborare con il fornitore di rete o il team di supporto di rete per assicurarsi che i commutatori di rete siano stati ridimensionati correttamente per il carico di lavoro che si intende eseguire.

Uso di senza cambio

Azure Stack HCI supporta connessioni senza cambio (diretto) per East-West traffico per tutte le dimensioni del cluster, purché ogni nodo del cluster abbia una connessione ridondante a ogni nodo del cluster. Si tratta di una connessione "full-mesh".

Diagramma che mostra la connettività senza commutatori full-mesh

Coppia di interfacce Subnet VLAN
Scheda di interfaccia di rete host Mgmt Specifica del cliente Specifica 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 commutatori diminuiscono con cluster maggiori di tre nodi a causa del numero di schede di rete necessarie.

Vantaggi delle connessioni senza cambio

  • Nessun acquisto switch è necessario per East-West traffico. Per North-South traffico è necessario un commutatore. Ciò può comportare costi di spesa in capitale (CAPEX) inferiori, ma dipende dal numero di nodi nel cluster.
  • Poiché non esiste alcuna opzione, la configurazione è limitata all'host, che può ridurre il numero potenziale di passaggi di configurazione necessari. Questo valore diminuisce quando 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 della macchina virtuale e altro traffico che richiedono North-South accesso non può usare queste schede.
  • Man mano che il numero di nodi nel cluster aumenta, il costo delle schede di rete potrebbe superare il costo dell'uso di commutatori di rete.
  • Non ridimensiona ben oltre 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, richiedendo modifiche alla configurazione hardware e software.

Passaggi successivi