NSX Logical Routing Architecture — Parte 2

Indice

• Introduzione

• NSX Edge Node: Ruoli e Caratteristiche

  • Ruolo degli Edge Node nel routing e servizi

  • Architettura degli Edge Node e interfacce di rete

  • Form factor disponibili e opzioni di sizing

  • Modelli di connettività: N-VDS multiplo vs unico, SmartNIC (UPT)

• NSX Edge Cluster: Architettura e HA

  • Struttura e high availability di un Edge Cluster

  • Failure domain e best practice di posizionamento

  • Scalabilità e limitazioni di Edge Cluster

• Deployment e Configurazione degli Edge Node

  • Metodi di deployment (OVA/OVF, UI, CLI, ISO, PXE)

  • Prerequisiti prima del deploy (password, NTP, hostname, porte)

  • Join al management-plane (thumbprint e comando di registrazione)

  • Verifiche post-deploy (stato, risorse, TEP, MTU, cluster)

• Conclusione

Introduzione

Nella Parte 1 di questa serie sulla NSX Logical Routing Architecture abbiamo introdotto i concetti di routing logico distribuito e l’architettura dei router logici Tier-0 e Tier-1. In questa Parte 2 ci focalizziamo sugli NSX Edge Node e sugli Edge Cluster, componenti chiave per abilitare la connettività north-south e i servizi centralizzati nello stack di virtual networking di NSX.

Gli Edge Node sono dispositivi (virtuali o fisici) dedicati a svolgere funzioni di routing verso le reti esterne e a fornire servizi di rete stateful (che richiedono mantenimento di stato) come NAT, VPN, load balancing e firewall gateway. Esploreremo nel dettaglio i ruoli e l’architettura degli Edge Node, come vengono raggruppati in cluster per alta disponibilità e scalabilità, e come si procede al loro deployment e configurazione in un ambiente NSX. Al termine, avremo una visione completa di come gli Edge Node si inseriscono nell’architettura di routing logico di NSX e delle best practice per implementarli efficacemente.

NSX Edge Node: Ruoli e Caratteristiche

Ruolo degli Edge Node nel routing e nei servizi

In un deployment NSX, gli Edge Node sono responsabili di tutte le funzioni di routing north-south, ovvero del traffico in entrata e uscita dall’ambiente virtualizzato verso la rete fisica esterna. Mentre il piano di controllo distribuito (il Distributed Router) si occupa del routing east-west locale sugli host hypervisor, gli Edge Node ospitano i Service Router dei gateway Tier-0 e Tier-1 per connettere la rete virtuale all’esterno e gestire i servizi centralizzati. Ciò include funzionalità come routing dinamico (protocolli BGP, OSPF) verso i router fisici upstream e servizi stateful che non possono essere distribuiti sugli host, ad esempio firewall edge, NAT, VPN e bilanciamento del carico (load balancer). In sintesi, un Edge Node funge da gateway che instrada il traffico da/verso le reti esterne e fornisce capacità di servizio centralizzate per l’intero dominio NSX.

Un Edge Node può ospitare contemporaneamente istanze di Tier-0 e Tier-1 Gateway (nelle loro componenti Service Router). Ad esempio, un Tier-0 Gateway in modalità Active/Standby avrà il suo Service Router attivo su un Edge Node e uno standby su un altro Edge Node per alta affidabilità. I Tier-1 Gateway con servizi (es. NAT o load balancer) operano anch’essi in modalità active/standby su coppie di Edge Node facenti parte di un Edge Cluster. Gli Edge Node quindi rappresentano una “pool” di risorse di calcolo dedicata ai servizi di rete centralizzati non distribuiti, assicurando che questi servizi abbiano isolamento e capacità adeguate.

Architettura degli Edge Node e interfacce di rete

Dal punto di vista architetturale, un Edge Node è un transport node speciale dotato di proprie interfacce di rete e di un proprio switch virtuale (N-VDS o equivalente VDS NSX) per connettersi sia all’overlay virtuale sia alla rete fisica. Gli Edge Node sono tipicamente basati su un’appliance Linux con datapath accelerato (DPDK). Ciascun Edge Node ha un’interfaccia dedicata al management (chiamata eth0) e fino a tre interfacce di data plane ad alte prestazioni denominate fp-eth0, fp-eth1, fp-eth2 (dove fp sta per fast path). L’interfaccia eth0 gestisce il traffico di gestione e controllo (connessione al NSX Manager, scambio control-plane, BFD sul management, ecc.), mentre le interfacce fp-ethX sono usate esclusivamente per il traffico dati (trasporto overlay e uplink fisici) e operano in user-space con DPDK per massimizzare le prestazioni di instradamento dei pacchetti.

In una configurazione tipica, un Edge Node utilizza un’interfaccia fp-eth per le connessioni overlay e almeno un’altra fp-eth come uplink verso il Top-of-Rack o router fisico esterno. Ad esempio, fp-eth0 potrebbe essere assegnata al Transport Zone di tipo Overlay (terminando il Tunnel Endpoint Geneve dell’Edge Node), mentre fp-eth1 viene collegata a una Transport Zone VLAN per le reti esterne (instradamento su VLAN verso il TOR). In questo modo l’Edge Node inoltra il traffico tra il mondo virtuale (overlay) e la rete fisica esterna. Lo schema seguente illustra concettualmente questa separazione tra l’interfaccia overlay (TEP) e l’interfaccia uplink VLAN di un Edge Node:

Grazie a questa architettura, l’Edge Node funge da ponte ad alte prestazioni tra l’overlay network virtuale (dove risiedono le subnet delle VM) e l’underlay fisico, garantendo che i pacchetti possano uscire/entrare dall’ambiente NSX. Le interfacce fisiche dell’Edge Node forniscono gli uplink verso l’underlay, collegando il mondo virtuale alla rete fisica. Da notare che, per motivi di isolamento, l’interfaccia di management eth0 non deve mai essere usata per il traffico dati: gli Edge Node richiedono almeno un’interfaccia fast path dedicata al traffico Geneve (overlay) e una per il traffico esterno, oppure la stessa interfaccia logica può gestire entrambi come vedremo più avanti.

Form factor disponibili e opzioni di sizing

NSX Edge Node è disponibile in due form factor principali: appliance virtuale (VM) oppure bare-metal. L’Edge VM viene fornito come OVA/OVF e può essere eseguito solo su host ESXi (non è supportato su KVM). L’Edge bare-metal invece è un’appliance installabile direttamente su un server fisico dedicato (tramite ISO bootabile o provisioning via PXE) e richiede NIC compatibili con DPDK in tale server. Entrambi i form factor offrono le stesse funzionalità di rete, ma differiscono per requisiti e prestazioni.

Bare-Metal Edge Node: Viene installato su un server fisico e tipicamente offre prestazioni superiori e tempi di failover più rapidi rispetto alla VM. Ad esempio, un Edge bare-metal supporta una convergenza sub-secondo in caso di guasto (timer BFD configurabili fino a 300ms, per rilevare un fault in ~0,9s) contro ~3 secondi minimi per un Edge VM (BFD a 1s con 3 retry). Inoltre, un singolo Edge bare-metal può disporre di fino a 16 interfacce fisiche (pNIC) per traffico overlay/uplink, offrendo maggiore capacità di throughput aggregato e possibilità di collegamenti multipli verso la rete (es. multi-homing su più TOR). L’architettura bare-metal prevede un’interfaccia dedicata per il management (anche 1 Gbps va bene per mgmt) e utilizza le restanti NIC per il data plane; è possibile anche la modalità in-band management (usare una NIC fastpath anche per il management, se necessario). In sintesi, i bare-metal Edge sono indicati per ambienti con requisiti di alte prestazioni e bassa latenza, dove dedicare hardware apposito per il ruolo di Edge Node è giustificato.

Edge Node VM: È una macchina virtuale preconfigurata (basata su Photon OS) distribuita via OVA. Supporta fino a 4 vNIC interni: una interfaccia di management (eth0) e tre interfacce dati (fp-eth0..2) collegate al fast path DPDK. La Edge VM è più semplice da distribuire e gestire (si integra in ambienti VMware esistenti su ESXi) ed è adatta alla maggior parte dei casi d’uso, dalle installazioni in ambienti piccoli fino a scenari enterprise standard. Le prestazioni sono comunque elevate (grazie al data plane accelerato) ma l’utilizzo come VM implica condividere le risorse con altri workload ESXi, quindi potrebbe essere opportuno riservare CPU/RAM alla VM Edge in produzione per garantire prestazioni stabili.

Opzioni di Sizing: VMware definisce vari profili di form factor per gli Edge Node virtuali, in modo da adattare le risorse allocate e la capacità di throughput alle esigenze specifiche. I tagli standard sono Small, Medium, Large ed Extra Large, ciascuno con un numero di vCPU, quantità di RAM e dimensionamento disco predeterminati. Di seguito una sintesi dei principali profili di Edge Node e delle relative capacità indicative:

• Small: 4 vCPU, 8 GB RAM, ~120 GB disco, throughput ~2 Gbps – Uso tipico: lab, ambienti di test/POC.

• Medium: 8 vCPU, 32 GB RAM, ~200 GB disco, throughput ~10 Gbps – Uso tipico: piccole produzioni, carichi leggeri.

• Large: 16 vCPU, 64 GB RAM, ~400 GB disco, throughput ~24 Gbps – Uso tipico: ambienti enterprise, più servizi attivi.

• Extra Large: 32 vCPU, 128 GB RAM, ~600 GB disco, throughput ~40+ Gbps – Uso tipico: grandi ambienti con altissimo throughput.

Nota: i valori di throughput sopra indicati sono teorici/stimati. Il dimensionamento effettivo dovrebbe sempre essere validato con traffico reale e tenendo conto dei servizi abilitati (NAT, LB, VPN incidono sulle performance). È buona prassi monitorare l’utilizzo risorse e prestazioni degli Edge Node tramite NSX Manager o Aria Operations, regolando il sizing in base alle esigenze reali.

Modelli di connettività: N-VDS multiplo vs singolo, SmartNIC offload (UPT)

Nel piano dati di NSX, gli Edge Node agiscono come transport node sia per l’overlay Geneve sia per le VLAN di uplink. A livello di virtual switch interno all’Edge, esistono due approcci principali per organizzare la connettività: utilizzare N-VDS separati per overlay e VLAN, oppure un N-VDS unico condiviso.

• Modello a N-VDS multipli: in questo design si crea un N-VDS dedicato al traffico Overlay e uno (o più) N-VDS separati per le VLAN di uplink. Ciò tipicamente comporta l’uso di interfacce fisiche distinte: ad esempio fp-eth0 assegnata in esclusiva all’N-VDS overlay (Transport Zone di tipo Overlay) e fp-eth1 assegnata a un N-VDS differente collegato alla Transport Zone VLAN per l’uplink esterno. Questo modello massimizza l’isolamento e permette di dedicare link fisici separati ai tunnel Geneve e al traffico verso i TOR. Da progetto, due N-VDS distinti non possono condividere la stessa pNIC, quindi ciascun switch virtuale ha le proprie interfacce dedicate. Configurare un Edge in una TZ overlay genera l’installazione di un N-VDS overlay sull’Edge, mentre aggiungerlo a una TZ di tipo VLAN crea un N-VDS separato per quella VLAN sullo stesso Edge.

• Modello a N-VDS singolo: in questo scenario più recente, un unico switch logico sull’Edge Node viene connesso sia alla Transport Zone overlay sia a una (o più) TZ VLAN. In pratica lo stesso N-VDS gestisce contemporaneamente i segmenti overlay (Geneve) e le reti VLAN, generalmente utilizzando un team di due uplink (es. fp-eth0 e fp-eth1 in teaming attivo/standby) sullo stesso switch. NSX consente a un N-VDS di collegarsi a un’Overlay TZ e a una VLAN TZ contemporaneamente, purché il nome dell’N-VDS sia lo stesso in entrambe le TZ. Ci sono però delle restrizioni: un singolo N-VDS può partecipare a una sola Overlay TZ e a una sola VLAN TZ; se un Edge deve collegarsi a più VLAN TZ, saranno necessari N-VDS aggiuntivi (uno per ciascuna TZ VLAN extra). Il modello a N-VDS unico semplifica la configurazione (meno switch da gestire) e riduce il numero di vNIC utilizzate, ma concentra overlay e uplink sugli stessi link fisici, il che va valutato in base al throughput disponibile e alle policy di QoS.

Entrambi i modelli possono coesistere a seconda del design. Ad esempio, in NSX 3.x era comune usare N-VDS separati per overlay e VLAN per ragioni di performance e semplicità concettuale, mentre con NSX 4.x su vSphere 7/8 si tende a utilizzare l’integrazione con il vSphere VDS (tramite NVDS-T/ENS) che di fatto opera come switch unico multi-trasporto. In ogni caso, un Edge Node può appartenere al massimo a una Transport Zone overlay e a una o più TZ VLAN (una per N-VDS).

Un discorso a parte merita l’avvento delle SmartNIC (DPU) e dell’offload hardware in NSX. Con vSphere 8 e NSX 4.x è stata introdotta la possibilità di delegare parte del data plane di NSX a dispositivi SmartNIC (progetto Monterey). In pratica, grazie a una modalità detta UPT (Unified Passthrough), le VM degli Edge Node (o anche i carichi di lavoro sugli host) possono inoltrare il traffico di rete direttamente alla DPU bypassando lo stack software tradizionale. Questo consente allo SmartNIC di gestire in hardware funzioni come l’instradamento e l’elaborazione del traffico delle interfacce vmxnet3, riducendo la latenza e liberando cicli di CPU sul server. Ad esempio, NSX 4.0.1.1 supporta l’offload completo del traffico di routing sul BlueField-2 (NVIDIA) in modalità UPT v2 (in anteprima tecnica). In futuro, anche servizi di sicurezza come la Distributed Firewall potranno essere offloadati sulla DPU (feature al momento in Tech Preview). Per sfruttare UPT, l’Edge Node (o host transport node) deve essere configurato con un vSwitch compatibile con l’accelerazione hardware (Enhanced Data Path) e schede SmartNIC supportate. Dal punto di vista architetturale, con le SmartNIC si torna a un approccio con un singolo VDS per host/edge che gestisce due uplink (quelli fisici sulla DPU) su cui viaggiano sia i segmenti overlay sia VLAN, ma con la differenza che l’elaborazione dei pacchetti viene effettuata direttamente dalla CPU del NIC invece che dalla CPU x86 dell’host. In sintesi, l’offload via SmartNIC e UPT permette di incrementare throughput e ridurre la latenza del fabric NSX spostando il data plane nell’hardware specializzato. Questo è un aspetto avanzato da considerare in ambienti che richiedono prestazioni estreme o densità elevata di carichi, tenendo presente che l’ecosistema di SmartNIC supportate (es. NVIDIA BlueField-2, AMD Pensando) è in continua evoluzione.

NSX Edge Cluster: Architettura e HA

Struttura e high availability di un Edge Cluster

Un NSX Edge Cluster è un gruppo logico di Edge Node che lavorano assieme per fornire connettività north-south altamente disponibile e scalabile. Analogamente a un cluster vSphere che raggruppa host per distribuzione carico e failover, un Edge Cluster offre una “pool” ridondante di risorse di rete: multipli Edge Node vengono usati in cooperazione per supportare i gateway logici e servizi, assicurando che il guasto di un singolo nodo non interrompa la connettività esterna.

All’interno di un Edge Cluster, i gateway Tier-0 e Tier-1 consumano le risorse degli Edge Node per implementare le loro funzioni di Service Router. In base alla configurazione, un Tier-0 Gateway può operare in modalità Active/Active (entrambe le istanze su due Edge instradano traffico simultaneamente, tipicamente usato per ECMP senza servizi stateful) oppure Active/Standby (un’istanza attiva su un Edge e una in standby su un altro, pronta a subentrare; usato quando sono attivi servizi NAT, VPN, etc. che richiedono stato). I Tier-1 Gateway con servizi funzionano in Active/Standby. In ogni caso, l’Edge Cluster garantisce che per ogni servizio/gateway ci sia sempre almeno un altro Edge Node pronto a farsi carico del traffico in caso di fault del nodo primario.

Gli Edge Cluster abilitano l’HA (High Availability) tramite meccanismi di failover rapido. Gli Edge Node all’interno del cluster monitorano costantemente lo stato reciproco attraverso heartbeat (sia sul network di management che sull’overlay TEP) usando protocolli come BFD (Bi-directional Forward Detection). In uno scenario Active/Standby, l’istanza standby del Service Router Tier-0/1 risiede su un Edge diverso da quello attivo; se quest’ultimo dovesse guastarsi, il secondo Edge rileva la mancata risposta ai heartbeat BFD entro pochi secondi e assume il ruolo di attivo, ripristinando la connettività north-south con un’interruzione minima (nell’ordine dei secondi o meno, a seconda della configurazione). Nel caso di Tier-0 in Active/Active con ECMP, tutti gli Edge del cluster possono instradare traffico contemporaneamente (fino a un massimo di 8 Edge attivi per lo stesso Tier-0, come vedremo) e in caso di perdita di un nodo il traffico viene semplicemente redistribuito sugli Edge restanti (riconvergenza delle rotte BGP/OSPF con i percorsi rimanenti).

Di seguito è illustrato un esempio semplificato di Edge Cluster con due Edge Node in HA Active/Standby, distribuiti su domini di failure differenti, che utilizzano BFD per il rilevamento dei guasti:

Nell’esempio, il Tier-0 Service Router attivo risiede su Edge Node 1 (nel dominio di failure 1), mentre lo standby risiede su Edge Node 2 (dominio 2). I pacchetti BFD tra i due Edge consentono di rilevare rapidamente un eventuale failure di Edge Node 1, causando l’immediato failover del Tier-0 attivo su Edge Node 2.

Oltre all’HA, raggruppare più Edge Node in cluster fornisce anche scalabilità orizzontale (scale-out). Si possono distribuire diversi gateway su nodi differenti o usare l’Active/Active (ECMP) per aumentare il throughput aggregato verso l’esterno sfruttando più Edge in parallelo. In pratica, un Edge Cluster consente di sommare la capacità di inoltro di più appliance e di distribuire il carico dei servizi su di esse, superando i limiti di un singolo Edge Node. Ad esempio, un cluster con 4 Edge Node potrebbe ospitare due Tier-0 Active/Active in ECMP (ognuno usando 2 Edge ciascuno), oppure più Tier-1 attivi su Edge diversi, migliorando sia la resilienza che la banda disponibile.

Failure domain e best practice di posizionamento

Quando si configura un Edge Cluster, è fondamentale considerare il concetto di failure domain. Un failure domain è una suddivisione logica dei nodi Edge del cluster che tipicamente riflette separazioni fisiche (ad es. diversi rack, diversi blade chassis, diversi availability zone). Lo scopo è garantire che le istanze attiva e standby di uno stesso servizio/gateway non risiedano nello stesso domain di failure, prevenendo che un singolo evento catastrofico (es. guasto di un intero rack o host) possa impattare contemporaneamente sia l’istanza primaria che quella di backup.

NSX permette di definire failure domain per un Edge Cluster assegnando ad esempio Domain A ad un primo gruppo di Edge e Domain B ad altri. In fase di deployment di un Tier-1 o Tier-0 in HA, NSX assegnerà automaticamente l’istanza attiva e standby a Edge in domain differenti, assicurando la resilienza geografica/logica. Introdotto inizialmente in NSX-T 2.5, il supporto dei failure domain è oggi parte integrante delle best practice di design: in ambienti con 4+ Edge, si può bilanciare i nodi in due o più domain per tollerare anche il fallimento simultaneo di interi domini senza perdere completamente i servizi (ovviamente con capacità ridotta).

Dal punto di vista dell’implementazione pratica, molte best practice di posizionamento rispecchiano il concetto di failure domain anche senza definirli esplicitamente. Ad esempio, non collocare mai i due Edge Node di una coppia HA sullo stesso host ESXi o nello stesso rack. In un ambiente vSphere, è consigliato usare regole DRS anti-affinity per assicurarsi che gli Edge Node di un cluster stiano sempre su host fisici differenti. Inoltre, distribuire gli Edge su rack differenti minimizza l’impatto di failure a livello di alimentazione o switch TOR. Anche in cluster a 3 o più nodi, bisognerebbe evitare che più di un Edge per cluster risieda nello stesso rack.

Altre best practice includono: dedicare, per quanto possibile, host e risorse esclusivamente agli Edge Node (isolarli dai carichi di lavoro generici) e fornire connettività ridondata a ogni Edge. Ad esempio, assegnare uplink fisici dedicati (o vDS dedicati) agli Edge Node per il traffico overlay/uplink, separandoli dai vDS usati dagli host compute. Ciò garantisce che il traffico degli Edge (solitamente consistente) non competi con quello delle VM normali sugli stessi NIC fisici. È inoltre buona norma configurare gli uplink Edge verso coppie di switch TOR ridondati e utilizzare LACP o tecniche di teaming quando possibile, in modo che la failure di uno switch o di un link non isoli completamente l’Edge. In sintesi, progettare con intelligenza la collocazione degli Edge Node è essenziale per ottenere la massima robustezza: “lo scopo è assicurarsi che nessun singolo guasto di hardware o rack possa interrompere tutti i servizi edge”.

Va ricordato che per ambienti di produzione il cluster Edge dovrebbe avere almeno 2 nodi, e idealmente 3 o più. VMware consiglia un minimo di due Edge Node per garantire HA o ECMP, e considera 3+ Edge una best practice così da avere ridondanza N+1 (es. in un cluster a 3, uno può fallire mantenendo comunque una coppia HA funzionante). In scenari mission-critical, cluster di 4-6 Edge distribuiti su più domain possono fornire tolleranza N+2 e capacità di manutenzione senza downtime.

Scalabilità e limitazioni di Edge Cluster

Un singolo Edge Cluster NSX può contenere fino a 10 Edge Node al suo interno. Questo rappresenta il limite massimo di nodi configurabili in un gruppo cluster. Dal punto di vista del routing, NSX supporta un massimo di 8 percorsi ECMP paralleli per un Tier-0 Gateway. Ciò significa che, sebbene si possano avere ad esempio 10 Edge in un cluster, un singolo Tier-0 in Active/Active utilizzerà al massimo 8 di quegli Edge contemporaneamente per instradare traffico (gli ulteriori Edge potrebbero rimanere inattivi o essere usati per altri servizi/gateway). In pratica 8 è il fan-out massimo di Edge attivi per un dato gateway in ECMP.

Altre limitazioni architetturali importanti: un Edge Node può ospitare una sola istanza attiva di Tier-0 alla volta. Questo vincolo assicura che se ci sono più Tier-0 Gateways, essi verranno distribuiti su Edge diversi anziché competere sullo stesso nodo (un Edge potrebbe comunque avere un Tier-0 attivo e uno standby di un altro Tier-0, ma non due attivi simultaneamente). I Tier-1 Gateway invece, essendo meno pesanti, possono coesistere in numero multiplo sullo stesso Edge Node (purché ci siano risorse). Bisogna comunque tenere presente la capacità totale di un Edge: anche se tecnicamente potremmo collocare molti Tier-1 su un Edge, tutti condivideranno le stesse CPU/RAM/throughput, quindi è bene dimensionare di conseguenza o distribuire i Tier-1 tra più Edge se il carico diventa elevato.

Dal punto di vista prestazionale, abbiamo già menzionato come gli Edge bare-metal possano fornire tempi di failover più rapidi grazie a BFD con timer più aggressivi. In generale, anche i throughput massimi supportati aumentano passando da form factor Small a X-Large e ancor più utilizzando bare-metal o SmartNIC offload. Tuttavia, l’effettiva scalabilità dipende dal tipo di traffico: ad esempio, traffico solo routing (L3 stateless) scalea linearmente meglio rispetto a traffico che richiede elaborazione stateful (NAT, VPN, firewall, che vincolano il flusso a un Edge specifico per via dell’affinità di sessione).

Riassumendo le principali limitazioni e caratteristiche di scalabilità di un Edge Cluster NSX:

• Max Edge per cluster: 10 Edge Node ragruppati.

• Max ECMP per Tier-0: 8 Edge attivi in parallelo per instradare traffico (8 percorsi equivalenti).

• Tier-0 per Edge: 1 solo Tier-0 attivo per Edge Node (un secondo Tier-0 verrà assegnato ad un altro Edge).

• Tier-1 per Edge: possono essercene molteplici per Edge (compatibilmente con le risorse).

• BFD Heartbeat: Edge VM supporta BFD min 1s (failover ~3s), Edge bare-metal supporta BFD min 300ms (failover ~0.9s).

• Failover automatico: in Active/Standby avviene a livello cluster (NSX Manager coordina il ruolo standby->attivo su altro Edge). In Active/Active avviene tramite riconvergenza routing (eventi di withdraw BGP, ecc.).

• Multicluster: è possibile avere più Edge Cluster separati (es. per tenant diversi o isolare Tier-1 in cluster dedicati), ma un singolo Tier-0/1 può essere associato a un solo Edge Cluster alla volta.

In pratica, un cluster con 2 Edge è sufficiente per garantire l’HA base (Active/Standby). Aggiungendo un terzo Edge si ottiene una riserva (N+1) o la possibilità di Active/Active/Standby. Con 4 o più Edge si possono sia eseguire più istanze attive contemporaneamente (ECMP su 2-8 nodi) sia tollerare la caduta di più di un nodo senza perdita di servizi, se opportunamente distribuiti in failure domain. Oltre 8 Edge, i nodi aggiuntivi servono principalmente come backup ulteriori o per segmentare carichi differenti (ad esempio assegnare specifici Tier-1 a Edge meno carichi). In fase di design è importante bilanciare il numero di Edge per cluster con il carico previsto: cluster troppo piccoli potrebbero diventare il collo di bottiglia della banda north-south, mentre cluster molto grandi offrono più ridondanza ma aumentano la complessità (e comunque un singolo gateway non può usarne più di 8 attivi).

Deployment e Configurazione degli Edge Node

Metodi di deployment degli Edge Node

VMware NSX mette a disposizione diversi metodi per effettuare il deployment degli NSX Edge Node a seconda dell’ambiente e del form factor scelto. Di seguito riepiloghiamo le opzioni principali:

• Deploy via NSX Manager (OVA/OVF): È la modalità più semplice per Edge VM su ESXi. Tramite l’interfaccia NSX Manager (se registrato con vCenter) è possibile avviare la procedura guidata di aggiunta Edge, che distribuisce automaticamente l’appliance OVA sull’host o cluster ESXi selezionato. In questa modalità, l’NSX Manager si occupa di fare il deploy dell’OVF template sull’infrastruttura vSphere e al termine l’Edge VM viene già parzialmente configurata (hostname, IP management, form factor, ecc. sono richiesti nel wizard). In alternativa, se non si usa l’integrazione, è possibile deployare manualmente l’OVA/OVF tramite vCenter o utilizzando strumenti come ovftool, e poi procedere alla configurazione iniziale dell’Edge. Da notare che l’Edge VM è supportata ufficialmente solo su hypervisor ESXi (non su KVM o altri), quindi questo metodo presuppone un ambiente vSphere.

• Deploy da CLI/API: In contesti automatizzati (infrastructure-as-code) o su piattaforme senza vCenter, si può utilizzare l’API di NSX Manager per registrare un nuovo Edge Node e fornire un payload JSON con i parametri, orchestrando il deploy via script. Ad esempio, esistono playbook Ansible e moduli Terraform che automatizzano la creazione di Edge Node e Edge Cluster. In pratica questi metodi richiamano le API REST di NSX (endpoint /api/v1/transport-nodes etc.) per creare la definizione di Edge e abbinarla a una VM esistente. In alternativa, VMware mette a disposizione anche un Edge Node CLI (accessibile in console dell’appliance) per configurazioni iniziali in modalità interattiva o batch.

• Installazione Bare Metal via ISO/PXE: Per Edge Node in form factor bare-metal, il deployment avviene installando il sistema NSX Edge OS direttamente su server fisico. VMware fornisce un’immagine ISO bootabile contenente l’installer: avviando il server dall’ISO, si segue un processo di installazione guidato (simile a una installazione di un sistema operativo Linux appliance) in cui impostare i parametri di base (IP management, DNS, ecc.). In alternativa, per installazioni mass-scale, è possibile usare il provisioning di rete via PXE: il file ISO può essere montato in modalità non interattiva o in kickstart automatizzato. L’uso di PXE consente di distribuire molteplici Edge su bare-metal in parallelo senza intervento manuale, fornendo preventivamente un file di risposta contenente configurazioni come password cifrate, IP, hostname, ecc. Indipendentemente dal metodo (ISO o PXE), al termine dell’installazione l’Edge bare-metal avvierà i suoi servizi base ed esporrà la console CLI per procedere poi al join con NSX Manager.

• Altri metodi e considerazioni: In alcuni ambienti è possibile utilizzare anche il modello di deploy OVA su host esistente senza vCenter (ad esempio tramite ESXi Embedded Host Client o import OVA via ovftool) per Edge VM standalone. Tuttavia, questa modalità richiede poi di configurare manualmente networking e join. Importante: come già sottolineato, Edge VM non è supportato su KVM; quindi in infrastrutture solo-KVM l’unica opzione è usare Edge bare-metal (o eventualmente eseguire l’appliance Edge come VM su KVM a proprio rischio, ma non è una configurazione supportata ufficialmente).

In sintesi, il percorso di deployment più comune in ambienti vSphere è utilizzare l’NSX Manager UI per distribuire Edge VM con pochi clic. In scenari cloud o automatizzati, le API/CLI offrono flessibilità per integrare il provisioning nel proprio workflow. E per esigenze di performance massime, l’opzione bare-metal con ISO/PXE consente di mettere in produzione Edge Node su hardware dedicato.

Prerequisiti prima del deploy

Prima di procedere al deployment di un Edge Node è importante soddisfare alcuni prerequisiti di configurazione e raccogliere le informazioni necessarie. Ecco un elenco dei principali aspetti da curare:

• Credenziali iniziali: Durante l’installazione (sia via OVA che ISO) verranno impostate le password per l’utente admin (CLI) e l’utente root. Assicurarsi di definire password forti che soddisfino i criteri richiesti: almeno 12 caratteri includendo maiuscole, minuscole, numeri e caratteri speciali, senza parole comuni o sequenze ripetitive. Queste credenziali saranno usate per il primo accesso alla CLI dell’Edge.

• Hostname e DNS: Scegliere un nome host univoco per l’Edge Node, rispettando le regole dei nomi DNS. Non usare caratteri non consentiti (ad es. l’underscore _ non è valido nei nomi host) poiché l’Edge potrebbe ignorare un hostname non valido e settarsi di default come localost. Idealmente, registrare gli Edge Node nel DNS aziendale e predisporre i record necessari (forward e reverse) per gli indirizzi IP di management.

• Indirizzamento IP (Management): Pianificare gli indirizzi IP di management da assegnare a ciascun Edge Node. Si può optare per configurazione static (consigliata in produzione) oppure DHCP se l’infrastruttura lo consente. In ambienti con reti di management multiple, potrebbe essere necessario configurare rotte statiche aggiuntive sulla VM Edge post-deploy per raggiungere NSX Manager. Annotare gateway, subnet, VLAN di management e server DNS/NTP da utilizzare.

• Server NTP sincronizzati: Avere servizi NTP affidabili è fondamentale. Configurare l’NTP su tutti gli Edge Node (e Manager) puntando a server comuni, così che gli orologi siano allineati. Timestamp coerenti aiutano nella diagnostica e sono critici per protocolli come BFD. L’installer Edge chiederà di specificare un NTP server (o lo erediterà se deploy via NSX Manager).

• Porte di rete e firewall: Verificare che tutte le porte necessarie alla comunicazione tra Edge e NSX Manager/Controller e tra Edge e host transport node siano aperte. In particolare, l’Edge Node dovrà raggiungere l’NSX Manager sul piano di management (HTTPS API sulla porta 443, e altri servizi di controllo) e gli host ESXi/KVM sui Tunnel Endpoint (porta UDP 6081 per Geneve overlay). Inoltre, protocolli come BFD, routing dinamico (BGP/OSPF) e servizi (VPN, etc.) potrebbero avere porte aggiuntive. Fare riferimento alla documentazione NSX Ports and Protocol e assicurarsi che eventuali firewall (fisici o locali sulle VM) non blocchino tali comunicazioni.

• VMware Tools (per Edge VM): L’appliance Edge per ESXi include VMware Tools preinstallato per migliorare l’integrazione con l’hypervisor. È importante non rimuovere né aggiornare manualmente VMware Tools all’interno della VM Edge, onde evitare problemi di compatibilità. Gli update verranno gestiti attraverso gli upgrade di NSX Edge forniti da VMware.

• Requisiti hardware: Accertarsi che l’host ESXi designato abbia risorse sufficienti (vCPU, RAM, spazio disco) per ospitare l’Edge Node con il sizing scelto. Inoltre, se l’Edge VM richiede ad esempio CPU con istruzioni AES-NI (per IPSec VPN) o altri requisiti particolari, verificare che siano soddisfatti. Per gli Edge bare-metal, controllare la compatibilità delle NIC (vedi VMware Compatibility Guide per NIC DPDK supportate) e che il server abbia almeno due interfacce 10GbE (consigliato) libere per l’uso dell’Edge. Anche il BIOS/UEFI del server va configurato abilitando la virtualizzazione (VT-x/VT-d) se richiesto dall’OS NSX Edge.

• Parametri di installazione: Se si usa il metodo OVA/OVF, preparare in anticipo i parametri da inserire nel wizard: nome dell’appliance, cluster/host di destinazione, datastore, rete di management (portgroup), form factor (Small/Medium/Large/XL), credenziali admin/root, IP management (o DHCP), netmask, gateway, DNS, NTP, e password enable SSH (se richiesta). Nel caso di installazione ISO bare-metal, questi parametri verranno chiesti interattivamente durante il setup oppure passati via file di kickstart in caso di automazione PXE.

Prendersi cura di questi prerequisiti prima del deploy assicura un’installazione fluida e riduce la necessità di interventi manuali post-install. Ad esempio, un errore comune è dimenticare di aprire le comunicazioni verso NSX Manager, causando un Edge Node “isolato” al primo avvio. Oppure inserire un hostname invalido e trovarsi con nodi nominati localhost, complicando l’identificazione. Pianificazione e preparazione sono dunque passi fondamentali.

Join al management-plane di NSX

Una volta che un Edge Node è stato deployato e avviato, il passo successivo è registrarlo presso l’NSX Manager, cioè effettuare il join dell’Edge al management plane. Questo permette all’Edge di essere gestito centralmente, ricevere configurazioni e partecipare al fabric NSX come transport node.

Se l’Edge Node è stato distribuito tramite l’UI di NSX Manager (metodo OVA guidato), di solito il join avviene automaticamente: al termine del wizard l’Edge prova a contattare il manager e si registra. In caso di deploy manuale (OVA standalone, ISO bare-metal, etc.), è necessario eseguire manualmente il comando di join dalla console dell’Edge.

Come effettuare il join manuale: Innanzitutto, assicurarsi che l’Edge Node abbia connettività IP verso l’NSX Manager sulla rete di management. Poi, recuperare l’impronta digitale (thumbprint) del certificato dell’NSX Manager: questo identificativo unico serve per autenticare la connessione. Si può ottenere accedendo alla CLI di NSX Manager e usando il comando API apposito (es. get certificate api thumbprint), oppure tramite interfaccia NSX Manager sotto System > Appliances. Ottenuto il thumbprint (una stringa esadecimale), ci si logga sulla console dell’Edge Node (con l’utente admin configurato durante l’installazione) e si esegue il comando di join:

Questo comando, come mostrato nell’esempio seguente, indica all’Edge di collegarsi al manager specificato. Dopo averlo lanciato, il sistema richiederà la password dell’utente admin dell’NSX Manager (ovvero la password amministratore utilizzata per accedere all’NSX Manager), in modo da autenticare la registrazione. Una volta fornita la password corretta, l’Edge Node completerà il processo di trust enrollment: si scambieranno certificati e l’Edge verrà registrato come nuovo nodo controllato dal Manager.

Se tutto è andato a buon fine, sul manager l’Edge comparirà nell’elenco dei fabric nodes. Il comando get managers eseguito sulla CLI dell’Edge mostrerà l’NSX Manager a cui è connesso (stato Up). In ambienti con NSX Manager cluster (3 nodi manager), è sufficiente effettuare il join verso uno dei manager e la comunicazione verrà estesa al cluster intero.

Importante: Ripetere il comando di join su ogni Edge Node distribuito. Ogni Edge va registrato singolarmente al management plane (non basta farlo su uno solo). Inoltre, accertarsi di utilizzare IP address e non hostname nel comando di join, a meno che il DNS per il manager sia configurato sull’Edge – in caso contrario, potrebbe fallire la risoluzione del nome (è un dettaglio menzionato spesso nelle guide NSX).

Una volta che l’Edge Node risulta connesso al management plane, NSX Manager potrà orchestrare su di esso le configurazioni aggiuntive: ad esempio l’attach alle Transport Zone, la creazione degli N-VDS/vDS, l’assegnazione a un Edge Cluster, ecc. Questi step possono essere automatici (se l’Edge è stato creato via UI NSX Manager, spesso viene richiesto di selezionare già il transport node profile durante il wizard) oppure manuali post-registrazione.

Verifiche e configurazioni post-deploy

Dopo aver registrato con successo un Edge Node al management plane, occorre finalizzare la sua configurazione come transport node e verificare che il tutto sia funzionante correttamente. Ecco le principali operazioni di post-deployment da effettuare:

• Convertire l’Edge in Transport Node (se necessario): Su NSX Manager, navigare su Fabric > Nodes > Edge Transport Nodes. Se l’Edge appare con stato “Pending” o “Not Configured”, selezionarlo e scegliere Configure NSX. Bisognerà assegnare all’Edge le Transport Zone a cui deve partecipare (almeno una Overlay TZ per i tunnel Geneve, e le VLAN TZ per le reti uplink che utilizzerà) e specificare i parametri dell’N-VDS/vDS: nome switch, profilo uplink da usare, IP per il TEP overlay (statico o da IP Pool) e interfacce fisiche da associare. Questi passi configurano effettivamente il dataplane dell’Edge. Una volta applicata la config, lo stato dell’Edge Transport Node dovrebbe passare a Success (e NSX Manager installerà i componenti di trasporto necessari). In caso di errore, ricontrollare che l’Edge abbia le NIC corrette assegnate e che i profili (uplink, IP pool) siano stati creati e selezionati adeguatamente.

• Verifica dello stato del nodo: Controllare dalla UI di NSX Manager che l’Edge Node appena aggiunto risulti Up e connesso. In particolare, le colonne Node Status e Tunnel Status dovrebbero indicare Up/Success una volta che l’Edge è stato configurato come transport node e ha avviato i servizi di overlay. Il Tunnel Status: Up conferma che il Tunnel Endpoint (TEP) dell’Edge riesce a comunicare con i TEP degli host transport node (Geneve overlay attivo). Se il tunnel risulta Down, è indice di un problema di connettività overlay (es. VLAN Transport sbagliata, MTU non adeguata o firewall in mezzo). Dal lato Edge CLI, comandi utili sono get tunnel status o get interfaces per vedere indirizzi e MTU delle interfacce.

• Validazione connettività di management e overlay: Eseguire test di ping mirati per assicurarsi che l’Edge veda gli altri componenti:

  • Dall’Edge, pingare l’IP di default gateway della rete di management e l’IP dell’NSX Manager – questo verifica routing e reachability base.

  • Dall’Edge, pingare uno degli host ESXi transport node (IP di management o TEP, se raggiungibile) – per assicurarsi che ci sia connettività IP adeguata (se su reti separate, potrebbe servire una static route sulla tabella management dell’Edge).

  • Pingare i server DNS e NTP configurati, per verificare che l’Edge abbia accesso ai servizi infrastrutturali necessari.

  • Test MTU: uno step spesso trascurato ma cruciale è verificare l’MTU end-to-end per l’overlay. Dall’Edge Node, utilizzare il comando ping ++netstack=vxlan -d -s 1600 <IP_TEP_host> per effettuare un ping DF-bit Set di dimensione 1600 bytes verso il TEP di un host ESXi. Se il ping passa senza frammentazione, significa che la rete fisica supporta il MTU necessario (Geneve overhead ~160 bytes oltre i 1440 standard). In caso contrario (ping che non risponde), aumentare l’MTU sui segmenti fisici (tipicamente 1700 o 9000 bytes) e nei profili uplink NSX finché il test non ha successo. MTU errato è causa frequente di problemi di tunnel instabili o pacchetti drop.

• Assegnazione dell’Edge Node a un Edge Cluster: Se non già fatto durante la creazione, occorre posizionare l’Edge dentro il cluster logico appropriato. Tramite NSX Manager, sezione Networking > Edge Clusters, aggiungere il nuovo Edge Node al cluster desiderato (o crearne uno nuovo se appropriato). Un Edge Node può appartenere ad un solo Edge Cluster alla volta. Dopo l’aggiunta, l’Edge parteciperà ai meccanismi HA di quel cluster. Verificare eventualmente che i failure domain siano impostati correttamente (se usati) assegnando il nuovo Edge a Domain A/B come pianificato.

• Verifica risorse e prestazioni: Controllare da vCenter che la VM Edge abbia effettivamente le risorse (vCPU, RAM) previste dal sizing scelto e che queste risorse siano possibilmente riservate (per garantire performance costanti). Monitorare via NSX Manager o vCenter l’utilizzo CPU/RAM dell’Edge in idle per assicurarsi che sia stabile. È normale che un Edge Node appena acceso consumi un certo quantitativo di RAM (es. 8-10 GB per Medium) e un po’ di CPU per i demoni di controllo; questi valori dovrebbero poi stabilizzarsi. Se si notano utilizzi anomali, indagare sui processi attivi via CLI (get process monitor).

• Edge Node settings aggiuntivi: Considerare eventuali configurazioni post-deploy come: abilitare l’SSH sull’Edge (di default potrebbe essere disabilitato per sicurezza – si abilita da NSX Manager > Settings sul nodo Edge, se necessario, o via CLI enable ssh temporaneamente), configurare banner di accesso, attivare log forwarding (si può impostare un Syslog server per log dell’Edge Node), oppure impostare parametri come l’FIPS mode se richiesto dalle policy di sicurezza (NSX Edge può operare in modalità FIPS compatibile). Inoltre, verificare lo stato di VMware Tools sulla VM Edge da vCenter – deve risultare Running (Current); in caso contrario, reinstallare l’open-vm-tools compatibile.

• Backup e snapshot: Prima di mettere in produzione l’Edge Node, può essere utile prendere uno snapshot (se VM) o assicurarsi di avere il backup della configurazione corrente. In generale gli Edge Node non conservano uno stato di configurazione pesante (sono gestiti centralmente), ma in contesti di change management può essere comodo poter ripristinare rapidamente un Edge appena configurato qualora qualcosa andasse storto.

Completati questi step, l’Edge Node dovrebbe essere completamente operativo e integrato nel fabric NSX. È ora pronto per ospitare servizi – ad esempio possiamo associare un Tier-0 Gateway a questo Edge Cluster e iniziare a instanziare uplink verso il mondo esterno (segmenti VLAN) e stabilire peer BGP/OSPF. Ogni volta che si aggiunge un Edge Node, ripetere la procedura di verifica: uno dei vantaggi dell’approccio NSX è che la postura di rete risulta consistente su tutti i nodi (tramite i profili e le policy), ma è comunque responsabilità dell’amministratore assicurarsi che ogni nuovo elemento sia allineato e funzionante.

Conclusione

In questa seconda parte abbiamo esplorato in profondità l’architettura e l’operatività degli NSX Edge Node e degli Edge Cluster, componenti fondamentali per il routing logico centralizzato in NSX. Gli Edge Node svolgono il ruolo di gateway tra il mondo virtuale e la rete fisica, fornendo capacità di instradamento north-south, terminazione di protocolli di routing dinamico, nonché l’esecuzione di servizi stateful avanzati (NAT, VPN, Load Balancing, etc.). Abbiamo visto come gli Edge possano essere implementati come appliance virtuali su ESXi o come macchine bare-metal dedicate, con diverse opzioni di sizing per adattarsi alle esigenze di throughput e resilienza dell’ambiente. Sul piano della connettività, abbiamo discusso i modelli di utilizzo delle interfacce (management vs fastpath) e le possibili topologie di switch virtuale (N-VDS unico vs multiplo), fino alle più recenti evoluzioni con SmartNIC e offload hardware (UPT).

Si è poi analizzato il concetto di Edge Cluster, ovvero come gruppi di Edge Node lavorano insieme per garantire alta disponibilità (HA) e scalabilità. Attraverso meccanismi come l’Active/Standby con failover BFD sub-secondo e l’Active/Active con ECMP, un Edge Cluster assicura che i servizi di rete restino sempre raggiungibili anche in caso di fault di uno o più nodi. Abbiamo sottolineato l’importanza dei failure domain e delle best practice di posizionamento (separazione fisica dei nodi, anti-affinity, uplink ridondati) per costruire un’infrastruttura robusta e priva di single point of failure Inoltre, sono stati evidenziati i limiti e le capacità massime (fino a 10 Edge per cluster, 8-way ECMP, ecc.) da tenere in considerazione nel design.

Infine, abbiamo guidato attraverso il ciclo di vita di un Edge Node, dalla preparazione (prerequisiti di installazione) al deployment con vari metodi (UI, CLI, ISO), fino alla fase cruciale di join al management plane e alle configurazioni post-deploy. Questi passaggi operativi – impostazione di password robuste, configurazione di NTP, verifica di connettività e MTU, aggiunta al cluster – assicurano che ogni Edge Node entri in funzione correttamente integrato nel fabric NSX e pronto a svolgere il suo compito.

Con la conclusione di questa seconda parte, disponiamo ora di una visione completa dell’architettura di routing logico NSX, includendo sia la componente distribuita (host transport nodes con i router logici) sia la componente centralizzata (Edge Node e cluster). Questa conoscenza è fondamentale per progettare, implementare e gestire infrastrutture network virtualization basate su NSX in ambienti di produzione, garantendo sia l’efficienza del traffico east-west intra-datacenter che la connettività affidabile verso l’esterno (north-south). Nei prossimi approfondimenti, potremmo esplorare aspetti ulteriori come l’ottimizzazione delle performance, il tuning dei protocolli di routing, o l’integrazione multi-site con Tier-0 in HA geografica – temi che costruiscono sui fondamenti trattati in queste prime due parti.