Progettazione dell'infrastruttura di rete fisica per VMware Cloud Foundation

La progettazione della rete fisica del data center comprende la definizione della topologia di rete per il collegamento degli switch fisici e degli host ESXi, la determinazione delle impostazioni delle porte degli switch per le VLAN e l'aggregazione dei collegamenti e la progettazione del routing.

Una rete definita da software (SDN) si integra con e utilizza componenti del data center fisico. SDN si integra con la rete fisica per supportare i transiti est-ovest nel data center e il transito nord-sud da e verso le reti dell'SDDC.

Esistono diverse topologie di distribuzione di reti di data center tipiche:

• Core-Aggregation-Access

• Leaf-spine

• SDN hardware

Nota:

Leaf-Spine è la topologia di distribuzione di rete del data center predefinita utilizzata per VMware Cloud Foundation.

VLAN e subnet per VMware Cloud Foundation

Configurare le VLAN e le subnet in base alle linee guida e ai requisiti per VMware Cloud Foundation.

Quando si progetta la configurazione della VLAN e della subnet per la distribuzione di VMware Cloud Foundation, si tengano presenti le linee guida seguenti:

Tabella 1. Linee guida per la VLAN e la subnet per VMware Cloud Foundation

Tutte le topologie di distribuzione	Più zone di disponibilità	Federazione di NSX tra più istanze di VMware Cloud Foundation	Cluster del dominio del carico di lavoro VI di elaborazione multi-rack
Assicurarsi che le subnet vengano scalate correttamente per consentire l'espansione, perché l'espansione in un secondo momento potrebbe comportare l'interruzione delle attività. Utilizzare l'indirizzo IP dell'interfaccia mobile per VRPP (Virtual Router Redundancy Protocol) o HSRP (Hot Standby) come gateway. Usare lo spazio degli indirizzi IPv4 RFC 1918 per queste subnet e allocare un ottetto per istanza di VMware Cloud Foundation e un altro ottetto per funzione.	Per i segmenti di rete che si estendono tra le zone di disponibilità, l'ID VLAN deve soddisfare i seguenti requisiti: Essere identici in entrambe le zone di disponibilità con gli stessi segmenti di rete di livello 3. Disporre di un gateway di livello 3 al primo hop che disponga di alta disponibilità, in modo da tollerare l'errore di un'intera zona di disponibilità. Per i segmenti di rete dello stesso tipo che non si estendono tra le zone di disponibilità, l'ID VLAN può essere uguale o diverso tra le zone.	Un segmento di rete RTEP deve avere un ID VLAN e un intervallo di livello 3 specifici per l'istanza di VMware Cloud Foundation. In un'istanza di VMware Cloud Foundation con più zone di disponibilità, il segmento di rete RTEP deve essere esteso tra le zone e gli deve essere assegnato lo stesso ID VLAN e intervallo IP. Tutte le reti RTEP dell'Edge devono essere raggiungibili l'una dall'altra.	Usare lo spazio degli indirizzi IPv4 RFC 1918 per queste subnet e allocare un ottetto per rack e un altro ottetto per funzione di rete.

Quando si distribuiscono VLAN e subnet per VMware Cloud Foundation, devono soddisfare i seguenti requisiti in base alla topologia di VMware Cloud Foundation:

Figura 1. Scelta di un modello di VLAN per il traffico dell'host e della macchina virtuale di gestione

Tabella 2. VLAN e subnet per zone di disponibilità e istanze per VMware Cloud Foundation

Funzione	Istanze di VMware Cloud Foundation con una singola zona di disponibilità	Istanze di VMware Cloud Foundation con più zone di disponibilità
Gestione macchina virtuale	Necessarie quando la gestione dell'host è separata Gateway ad alta disponibilità all'interno dell'istanza	Necessarie quando la gestione dell'host è separata Deve essere estesa all'interno dell'istanza Gateway ad alta disponibilità nelle zone di disponibilità all'interno dell'istanza
Gestione dell'host - Prima zona di disponibilità	Obbligatorio Gateway ad alta disponibilità all'interno dell'istanza	Obbligatorio Gateway ad alta disponibilità nelle zone di disponibilità all'interno dell'istanza
vSphere vMotion - prima zona di disponibilità	Obbligatorio Gateway ad alta disponibilità all'interno dell'istanza	Obbligatorio Gateway ad alta disponibilità nella prima zona di disponibilità all'interno dell'istanza
vSAN - prima zona di disponibilità	Necessarie per il cluster predefinito del dominio di gestione Gateway ad alta disponibilità all'interno dell'istanza	Obbligatorio Gateway ad alta disponibilità nella prima zona di disponibilità all'interno dell'istanza
Overlay host - prima zona di disponibilità	Obbligatorio Gateway ad alta disponibilità all'interno dell'istanza	Obbligatorio Gateway ad alta disponibilità nella prima zona di disponibilità all'interno dell'istanza
NFS	Necessarie se si utilizza NFS come storage principale nel dominio del carico di lavoro VI	Non supportato
Uplink01	Obbligatorio Gateway facoltativo	Obbligatorio Gateway facoltativo Deve essere estesa all'interno dell'istanza
Uplink02	Obbligatorio Gateway facoltativo	Obbligatorio Gateway facoltativo Deve essere estesa all'interno dell'istanza
Overlay Edge	Obbligatorio Gateway ad alta disponibilità all'interno dell'istanza	Obbligatorio Deve essere estesa all'interno dell'istanza Gateway ad alta disponibilità nelle zone di disponibilità all'interno dell'istanza
Gestione dell'host - Seconda zona di disponibilità	Non necessario	Obbligatorio Gateway ad alta disponibilità nella seconda zona di disponibilità all'interno dell'istanza
vSphere vMotion - seconda zona di disponibilità	Non necessario	Obbligatorio Gateway ad alta disponibilità nella seconda zona di disponibilità all'interno dell'istanza
vSAN - seconda zona di disponibilità	Non necessario	Obbligatorio Gateway ad alta disponibilità nella seconda zona di disponibilità all'interno dell'istanza
Overlay host - seconda zona di disponibilità	Non necessario	Obbligatorio Gateway ad alta disponibilità nella seconda zona di disponibilità all'interno dell'istanza
Edge RTEP	Necessario solo per la federazione di NSX Gateway ad alta disponibilità all'interno dell'istanza	Necessario solo per la federazione di NSX Deve essere estesa all'interno dell'istanza Gateway ad alta disponibilità nelle zone di disponibilità all'interno dell'istanza
Gestione e witness - appliance witness in una terza posizione	Non necessario	Obbligatorio Gateway ad alta disponibilità nella posizione witness

Tabella 3. VLAN e subnet per le distribuzioni multi-rack con VMware Cloud Foundation

Funzione	Istanze di VMware Cloud Foundation con cluster di dominio del carico di lavoro VI di elaborazione multi-rack	Istanze di VMware Cloud Foundation con disponibilità di NSX Edge multi-rack
Gestione macchina virtuale	Non necessarie come sola elaborazione	Necessarie quando la gestione dell'host è separata Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack
Gestione dell'host	Necessarie per ogni rack Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack	Necessarie per ogni rack Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack
vSphere vMotion	Necessarie per ogni rack Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack	Necessarie per ogni rack Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack
vSAN	Necessarie per ogni rack Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack	Necessarie per ogni rack se si utilizza vSAN Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack
Overlay host	Necessarie per ogni rack Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack	Necessarie per ogni rack Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack
NFS	Non supportato	Necessarie se si utilizza NFS come storage principale per i cluster con i nodi NSX Edge.
Uplink01	Non necessario	Necessarie per ogni rack
Uplink02	Non necessario	Necessarie per ogni rack
Overlay Edge	Non necessario	Necessarie per ogni rack Gateway ad alta disponibilità nei nodi commutati ToR o Leaf nel rack

Requisiti e consigli per la progettazione delle reti fisiche leaf-spine per VMware Cloud Foundation

Leaf-spine è la topologia di distribuzione di rete del data center predefinita utilizzata per VMware Cloud Foundation. Considerare la larghezza di banda della rete, la configurazione della porta trunk, nonché la configurazione dei jumbo frame e del routing per NSX in una distribuzione con una o più istanze di VMware Cloud Foundation.

Progettazione logica della rete fisica leaf-spine

Ogni host ESXi dispone di connettività ridondante ai commutatori ToR (Top-of-Rack) dell'infrastruttura di rete SDDC da due o più porte con una velocità consigliata di almeno 25 GbE. I commutatori ToR sono configurati per fornire tutte le VLAN necessarie utilizzando un trunk 802.1Q. Queste connessioni ridondanti utilizzano le funzioni di vSphere Distributed Switch e NSX per garantire che nessuna interfaccia fisica venga superata e che vengano utilizzati i percorsi ridondanti disponibili.

Figura 2. Progettazione logica della rete fisica leaf-spine

Requisiti e consigli per la progettazione della rete fisica leaf-spine

I requisiti e i consigli per la configurazione della rete leaf-spine determinano il layout fisico e l'uso delle VLAN. Includono inoltre requisiti e consigli sui jumbo frame e sui requisiti relativi alla rete, come DNS, NTP e il routing.

Tabella 4. Requisiti di progettazione della rete fisica Leaf-Spine per VMware Cloud Foundation

ID requisito	Requisiti di progettazione	Giustificazione	Implicazione
VCF-NET-REQD-CFG-001	Non utilizzare la configurazione EtherChannel (LAG, LACP o vPC) per gli uplink dell'host ESXi.	Semplifica la configurazione dei commutatori Top-of-Rack. Le opzioni di raggruppamento disponibili con vSphere Distributed Switch forniscono bilanciamento del carico e failover. Le implementazioni EtherChannel potrebbero avere limitazioni specifiche del fornitore.	nessuna.
VCF-NET-REQD-CFG-002	Utilizzare le VLAN per separare le funzioni della rete fisica.	Supporta la connettività di rete fisica senza richiedere molte NIC. Isola le diverse funzioni di rete nell'SDDC in modo da poter disporre di servizi differenziati e di traffico prioritario in base alle necessità.	Richiede una configurazione e una presentazione uniformi in tutti i trunk resi disponibili per gli host ESXi.
VCF-NET-REQD-CFG-003	Configurare le VLAN come membri di un trunk 802.1Q.	Tutte le VLAN diventano disponibili nelle stesse schede di rete fisiche degli host ESXi.	Facoltativamente, la VLAN di gestione può fungere da VLAN nativa.
VCF-NET-REQD-CFG-004	Impostare le dimensioni della MTU su almeno 1.700 byte (consigliati 9.000 byte per i jumbo frame) nelle porte dei commutatori fisici, nei vSphere Distributed Switch, nei gruppi di porte dei vSphere Distributed Switch e nei commutatori N-VDS che supportano i seguenti tipi di traffico: Overlay (Geneve) vSAN vSphere vMotion	Migliora la velocità effettiva del traffico. Supporta Geneve aumentando le dimensioni della MTU a un minimo di 1.600 byte. Geneve è un protocollo estendibile. Le dimensioni della MTU potrebbero aumentare con le capacità future. Anche se 1.600 byte sono sufficienti, una MTU di 1.700 byte offre più spazio per aumentare le dimensioni della MTU di Geneve senza dover modificare le dimensioni della MTU dell'infrastruttura fisica.	Quando si regolano le dimensioni del pacchetto della MTU, è necessario configurare anche l'intero percorso di rete (schede di rete VMkernel, commutatori virtuali, commutatori fisici e router) in modo che supporti le stesse dimensioni del pacchetto della MTU. In un ambiente con più zone di disponibilità, la MTU deve essere configurata nell'intero percorso di rete tra le zone.

Tabella 5. Requisiti di progettazione della rete fisica Leaf-Spine per il cluster del dominio del carico di lavoro VI di elaborazione multi-rack per VMware Cloud Foundation

ID requisito	Requisiti di progettazione	Giustificazione	Implicazione
VCF-NET-L3MR-REQD-CFG-001	Per un cluster del dominio del carico di lavoro VI di elaborazione multi-rack, specificare VLAN separate per ogni rack per ciascuna funzione di rete. Gestione dell'host vSAN vSphere vMotion Overlay host	Un'infrastruttura Leaf-Spine di livello 3 ha un limite di livello 3 in corrispondenza dei commutatori Leaf in ogni rack che crea un limite di livello 3 tra i rack.	Richiede VLAN aggiuntive per ogni rack.
VCF-NET-L3MR-REQD-CFG-002	Per un cluster del dominio del carico di lavoro VI di elaborazione multi-rack, le subnet per ogni rete per ciascun rack devono essere instradabili e raggiungibili per i commutatori Leaf negli altri rack. Gestione dell'host vSAN vSphere vMotion Overlay host	Garantisce che il traffico per ogni rete possa passare tra i rack.	Richiede una configurazione di rete fisica aggiuntiva per rendere le reti instradabili tra i rack.

Tabella 6. Requisiti di progettazione della rete fisica Leaf-Spine per la federazione di NSX in VMware Cloud Foundation

ID requisito	Requisiti di progettazione	Giustificazione	Implicazione
VCF-NET-REQD-CFG-005	Impostare le dimensione della MTU su almeno 1.500 byte (preferibilmente 1.700 byte; 9.000 byte consigliati per i jumbo frame) nei componenti della rete fisica tra le istanze di VMware Cloud Foundation per i seguenti tipi di traffico. RTEP di NSX Edge	I jumbo frame non sono necessari tra le istanze di VMware Cloud Foundation. Tuttavia, l'aumento della MTU migliora la velocità effettiva del traffico. L'aumento della MTU RTEP a 1.700 byte riduce al minimo la frammentazione dei pacchetti del carico di lavoro di dimensioni standard tra istanze di VMware Cloud Foundation.	Quando si regolano le dimensioni del pacchetto della MTU, è necessario configurare anche l'intero percorso di rete (ovvero le interfacce virtuali, i commutatori virtuali, i commutatori fisici e i router) in modo che supporti le stesse dimensioni del pacchetto della MTU.
VCF-NET-REQD-CFG-006	Assicurarsi che la latenza tra le istanze di VMware Cloud Foundation connesse in una federazione di NSX sia inferiore a 500 ms.	Per la federazione di NSX è necessaria una latenza inferiore a 500 ms.	nessuna.
VCF-NET-REQD-CFG-007	Fornisce una connessione instradata tra i cluster NSX Manager nelle istanze di VMware Cloud Foundation connesse in una federazione di NSX.	La configurazione della federazione di NSX richiede la connettività tra le istanze di NSX Global Manager, le istanze di NSX Local Manager e i cluster NSX Edge.	È necessario assegnare indirizzi IP instradabili univoci per ogni dominio di errore.

Tabella 7. Consigli per la progettazione della rete fisica Leaf-Spine per VMware Cloud Foundation

ID consiglio	Consigli di progettazione	Giustificazione	Implicazione
VCF-NET-RCMD-CFG-001	Utilizzare due commutatori ToR per ogni rack.	Supporta l'uso di due collegamenti da 10-GbE (consigliati almeno 25-GbE) per ogni server, fornisce ridondanza e riduce la complessità complessiva della progettazione.	Richiede due commutatori ToR per rack che potrebbero aumentare i costi.
VCF-NET-RCMD-CFG-002	Implementare la seguente architettura di rete fisica: Almeno una porta da 25 GbE (almeno 10 GbE) in ogni commutatore ToR per gli uplink degli host ESXi (da host a ToR). Dispositivo di livello 3 che supporta BGP.	Fornisce disponibilità durante un errore del commutatore. Fornisce supporto per il protocollo di routing dinamico BGP	Potrebbe limitare le scelte dell'hardware. Richiede la configurazione del protocollo di routing dinamico nella rete fisica.
VCF-NET-RCMD-CFG-003	Utilizzare una rete fisica configurata per l'adiacenza del routing BGP.	Supporta la flessibilità della progettazione per il routing dei carichi di lavoro multisito e multi-tenancy. BGP è l'unico protocollo di routing dinamico supportato per la federazione di NSX. Supporta il failover tra uplink dell'Edge ECMP.	Richiede la configurazione di BGP nella rete fisica.
VCF-NET-RCMD-CFG-004	Assegnare configurazioni IP persistenti per gli endpoint del tunnel NSX (TEP) che utilizzano pool di IP statici anziché l'indirizzamento dinamico del pool di IP.	Assicura che gli endpoint abbiano un indirizzo IP TEP persistente. In VMware Cloud Foundation, per tutte le topologie è consigliabile l'assegnazione di IP TEP tramite pool di IP statici. Questa configurazione rimuove qualsiasi requisito di servizi DHCP esterni.	Se si aggiungono altri host al cluster, potrebbe essere necessario aumentare i pool di IP statici.
VCF-NET-RCMD-CFG-005	Configurare le porte trunk connesse alle NIC ESXi come trunk PortFast.	Riduce il tempo di transizione delle porte allo stato di inoltro.	Anche se questa progettazione non utilizza STP, STP è in genere configurato nei commutatori per impostazione predefinita.
VCF-NET-RCMD-CFG-006	Configurare VRRP, HSRP o un altro metodo di disponibilità del gateway di livello 3 per queste reti. Gestione Overlay Edge	Assicura che le VLAN che si estendono tra le zone di disponibilità siano connesse a un gateway ad alta disponibilità. In caso contrario, un errore nel gateway di livello 3 causerà un'interruzione delle attività del traffico nella configurazione di SDN.	Richiede la configurazione di una tecnologia ad alta disponibilità per i gateway di livello 3 nel data center.
VCF-NET-RCMD-CFG-007	Utilizzare VLAN separate per le funzioni di rete per ogni cluster.	Riduce le dimensioni del dominio di broadcast di livello 2 a un singolo cluster vSphere.	Aumenta il numero complessivo di VLAN necessarie per un'istanza di VMware Cloud Foundation.

Tabella 8. Consigli per la progettazione della rete fisica Leaf-Spine per la scalabilità e le prestazioni dell'Edge dedicato per VMware Cloud Foundation

ID consiglio	Consigli di progettazione	Giustificazione	Implicazione
VCF-NET-DES-RCMD-CFG-001	Implementare la seguente architettura di rete fisica: Due porte da 100 GbE in ogni commutatore ToR per gli uplink degli host ESXi (da host a ToR). Dispositivo di livello 3 che supporta BGP.	Supporta i requisiti di larghezza di banda elevata e pacchetti al secondo per le distribuzioni su larga scala.	Richiede commutatori di rete da 100 GbE.

Tabella 9. Consigli per la progettazione delle reti fisiche relative alla federazione di NSX in VMware Cloud Foundation

ID consiglio	Consigli di progettazione	Giustificazione	Implicazione
VCF-NET-RCMD-CFG-008	Fornire il routing BGP tra tutte le istanze di VMware Cloud Foundation connesse in una configurazione della federazione di NSX.	BGP è il protocollo di routing supportato per la federazione di NSX.	nessuna.
VCF-NET-RCMD-CFG-009	Assicurarsi che la latenza tra le istanze di VMware Cloud Foundation connesse in una federazione di NSX sia inferiore a 150 ms per la mobilità del carico di lavoro.	Le seguenti funzionalità richiedono una latenza inferiore a 150 ms: vMotion tra vCenter Server	nessuna.